1. 03 Jul, 2015 6 commits
  2. 02 Jul, 2015 3 commits
  3. 01 Jul, 2015 6 commits
    • Hui Wang's avatar
      ALSA: hda - adding a DAC/pin preference map for a HP Envy TS machine · 61947e8d
      Hui Wang authored
      [ Upstream commit 6ab42ff4 ]
      
      On a HP Envy TouchSmart laptop, there are 2 speakers (main speaker
      and subwoofer speaker), 1 headphone and 2 DACs, without this fixup,
      the headphone will be assigned to a DAC and the 2 speakers will be
      assigned to another DAC, this assignment makes the surround-2.1
      channels invalid.
      
      To fix it, here using a DAC/pin preference map to bind the main
      speaker to 1 DAC and the subwoofer speaker will be assigned to another
      DAC.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      61947e8d
    • Nicolas Ferre's avatar
      clk: at91: fix h32mx prototype inclusion in pmc header · eb01a7c9
      Nicolas Ferre authored
      [ Upstream commit 28df9c2f ]
      
      Trivial fix that prevents to compile this pmc clock driver if h32mx clock is
      present but smd clock isn't.
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Fixes: bcc5fd49 ("clk: at91: add a driver for the h32mx clock")
      Cc: <stable@vger.kernel.org> # 3.18+
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      eb01a7c9
    • Boris Brezillon's avatar
      clk: at91: pll: fix input range validity check · 66b03714
      Boris Brezillon authored
      [ Upstream commit 6c7b03e1 ]
      
      The PLL impose a certain input range to work correctly, but it appears that
      this input range does not apply on the input clock (or parent clock) but
      on the input clock after it has passed the PLL divisor.
      Fix the implementation accordingly.
      
      Cc: <stable@vger.kernel.org> # v3.14+
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Reported-by: default avatarJonas Andersson <jonas@microbit.se>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      66b03714
    • Steve Cornelius's avatar
      crypto: caam - fix RNG buffer cache alignment · 6429e706
      Steve Cornelius authored
      [ Upstream commit 412c98c1 ]
      
      The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx)
      allocated in one DMA-tagged region. While the kernel's heap allocator
      should place the overall struct on a cacheline aligned boundary, the 2
      buffers contained within may not necessarily align. Consenquently, the ends
      of unaligned buffers may not fully flush, and if so, stale data will be left
      behind, resulting in small repeating patterns.
      
      This fix aligns the buffers inside the struct.
      
      Note that not all of the data inside caam_rng_ctx necessarily needs to be
      DMA-tagged, only the buffers themselves require this. However, a fix would
      incur the expense of error-handling bloat in the case of allocation failure.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: default avatarVictoria Milhoan <vicki.milhoan@freescale.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6429e706
    • Steve Cornelius's avatar
      crypto: caam - improve initalization for context state saves · 431685c8
      Steve Cornelius authored
      [ Upstream commit 6fd4b156 ]
      
      Multiple function in asynchronous hashing use a saved-state block,
      a.k.a. struct caam_hash_state, which holds a stash of information
      between requests (init/update/final). Certain values in this state
      block are loaded for processing using an inline-if, and when this
      is done, the potential for uninitialized data can pose conflicts.
      Therefore, this patch improves initialization of state data to
      prevent false assignments using uninitialized data in the state block.
      
      This patch addresses the following traceback, originating in
      ahash_final_ctx(), although a problem like this could certainly
      exhibit other symptoms:
      
      kernel BUG at arch/arm/mm/dma-mapping.c:465!
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = 80004000
      [00000000] *pgd=00000000
      Internal error: Oops: 805 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
      PC is at __bug+0x1c/0x28
      LR is at __bug+0x18/0x28
      pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
      sp : e423fd98  ip : 60000013  fp : 0000001c
      r10: e4191b84  r9 : 00000020  r8 : 00000009
      r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
      r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c53c7d  Table: 1000404a  DAC: 00000015
      Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
      Stack: (0xe423fd98 to 0xe4240000)
      fd80:                                                       11807fd1 80048544
      fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
      fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
      fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
      fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
      fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
      fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
      fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
      fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
      fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
      fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
      ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
      ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
      ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
      ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
      ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
      ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
      ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
      ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
      [<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
      [<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
      [<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
      [<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
      [<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
      [<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
      [<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
      [<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
      [<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
      [<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
      Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
      ---[ end trace d52a403a1d1eaa86 ]---
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: default avatarVictoria Milhoan <vicki.milhoan@freescale.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      431685c8
    • Konstantin Khlebnikov's avatar
      lib/rhashtable: fix race between rhashtable_lookup_compare and hashtable resize · fcd7e9af
      Konstantin Khlebnikov authored
      Hash value passed as argument into rhashtable_lookup_compare could be
      computed using different hash table than rhashtable_lookup_compare sees.
      
      This patch passes key into rhashtable_lookup_compare() instead of hash and
      compures hash value right in place using the same table as for lookup.
      
      Also it adds comment for rhashtable_hashfn and rhashtable_obj_hashfn:
      user must prevent concurrent insert/remove otherwise returned hash value
      could be invalid.
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Fixes: e341694e ("netlink: Convert netlink_lookup() to use RCU protected hash table")
      Link: http://lkml.kernel.org/r/20150514042151.GA5482@gondor.apana.org.au
      Cc: Stable <stable@vger.kernel.org> (v3.17 .. v3.19)
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fcd7e9af
  4. 29 Jun, 2015 2 commits
    • Frank Praznik's avatar
      HID: sony: Add support for the third-party SMK PS3 Bluetooth Remote · b038a203
      Frank Praznik authored
      [ Upstream commit 68a49e51 ]
      
      Add vid/pid for the SMK branded third-party PS3 Bluetooth remote and enable
      support in the hid-sony driver.
      Signed-off-by: default avatarFrank Praznik <frank.praznik@oh.rr.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b038a203
    • Kenneth Graunke's avatar
      drm/i915: Make sample_c messages go faster on Haswell. · fe206a6b
      Kenneth Graunke authored
      [ Upstream commit 94411593 ]
      
      Haswell significantly improved the performance of sampler_c messages,
      but the optimization appears to be off by default.  Later platforms
      remove this bit, and apparently always enable the optimization.
      
      Improves performance in "Counter Strike: Global Offensive" by 18%
      at default settings on Iris Pro.
      
      This may break sampling of paletted formats (P8/A8P8/P8A8).  It's
      unclear whether it affects sampling of paletted formats in general,
      or just the sample_c message (which is never used).
      
      While libva does have support for using paletted formats (primarily
      for OSDs), that support appears to have been broken for at least a
      year, so I couldn't observe a regression from this:
      
      I tried to get libva-intel to use paletted formats, and observe a
      regression...but the only thing I found that used it was mplayer's OSD
      (on screen display).  Even without my patch, the colors were totally
      wrong with that, and it's according to a few distro wikis, that's been
      the case for over a year.
      
      If libva's code for paletted formats /is/ broken, they could always
      add code to disable this bit using the command validator when fixing
      it.
      
      Further investigation from Haihao shows that libva mplayer OSD seems
      to work at least on his setup (still unclear what's wron with Ken's),
      and that it's not affected by this patch. Quoting the discussion
      between Haihao and Ken:
      
      > > > If you use "-vo gl" or "-vo xv", the OSD is solid white text with a black
      > > > border around it.  I presume that it's supposed to be white with vaapi as
      > > > well, but I guess I'm not entirely sure.
      > > >
      > > > It's possible that the optimization doesn't affect the palette as long as
      > > > you never use sample_c with the paletted textures.
      > >
      > > I verified the palette takes effect in the following way:
      > >
      > > 1. Only support P8A8 format in the driver
      > >
      > > 2. ran the above command and I saw white OSD text
      > >
      > > 3. Only support P4A4 format in the driver and don't use
      > > 3DSTATE_SAMPLER_PALETTE_LOAD0 to load the value to the texture palette,
      > > so the palette keeps unchanged.
      > >
      > > 4. ran the above command and I saw black OSD text.
      > >
      > > 5. Load the right value to the texture palette and ran the above command
      > > again, I saw white OSD text.
      > >
      > > Hence I think sample_c with the paletted textures is used in the driver.
      >
      > That sounds like the palette is actually working, then.  Great :)
      >
      > I doubt that libva would use sample_c - sampling with a shadow comparison?
      > It looks like it just uses sample and sample+killpix.
      
      You are right, libva driver doesn't use sample_c message.
      
      > I'm pretty sure the sample_c optimization just uses the palette memory as
      > storage for some stuff, so it's quite possible it just works if you're
      > only using sample and sample+killpix.
      
      Thanks for the explanation, it makes sense to me.
      Signed-off-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      [danvet: Add wa name from Ville's review to the comment and copypaste
      the explanation why we don't care about libva (already broken) from
      Ken. Also add conclusion from libva devs that&why this is all fine.]
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Cc: "Xiang, Haihao" <haihao.xiang@intel.com>
      Cc: libva@lists.freedesktop.org
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fe206a6b
  5. 28 Jun, 2015 23 commits