1. 21 5月, 2019 2 次提交
    • Y
      drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platform · df2ea3c2
      Yan Zhao 提交于
      for restore-inhibit context, hardware will not load in-context mmios
      (engine context part) to hardware, but hardware will save the mmio
      values in hardware back to context image. So, in order to save correct
      values of vGPU back to context image, values of vGPU mmios have to be
      loaded into hardware first for restore-inhibit context.
      
      In this patch, the mechanism is applied to all gen9 platform.
      
      The reason excluding gen8 platforms is only because of lacking of testing
      on those platforms.
      
      v3: for mocs registers, goto in-context mmios save-restore path for skl
      platform as well (weinan li)
      v2: update vreg when scanning indirect context for inhibit context for
      gen9
      
      Cc: Weinan Li <weinan.z.li@intel.com>
      Acked-by: NWeinan Li <weinan.z.li@intel.com>
      Signed-off-by: NYan Zhao <yan.y.zhao@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      df2ea3c2
    • W
      drm/i915/gvt: emit init breadcrumb for gvt request · a8c2d5ab
      Weinan 提交于
      "To track whether a request has started on HW, we can emit a breadcrumb at
      the beginning of the request and check its timeline's HWSP to see if the
      breadcrumb has advanced past the start of this request." It means all the
      request which timeline's has_init_breadcrumb is true, then the
      emit_init_breadcrumb process must have before emitting the real commands,
      otherwise, the scheduler might get a wrong state of this request during
      reset. If the request is exactly the guilty one, the scheduler won't
      terminate it with the wrong state. To avoid this, do emit_init_breadcrumb
      for all the requests from gvt.
      
      v2: cc to stable kernel
      
      Fixes: 85474441 ("drm/i915: Identify active requests")
      Cc: stable@vger.kernel.org
      Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: NWeinan <weinan.z.li@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      a8c2d5ab
  2. 20 5月, 2019 5 次提交
    • C
      drm/i915: Truly bump ready tasks ahead of busywaits · a491cc8e
      Chris Wilson 提交于
      In commit b7404c7e ("drm/i915: Bump ready tasks ahead of
      busywaits"), I tried cutting a corner in order to not install a signal
      for each of our dependencies, and only listened to requests on which we
      were intending to busywait. The compromise that was made was that
      instead of then being able to promote the request with a full
      NOSEMAPHORE like its non-busywaiting brethren, as we had not ensured we
      had cleared the semaphore chain, we settled for only using the NEWCLIENT
      boost. With an over saturated system with multiple NEWCLIENTS in flight
      at any time, this was found to be an inadequate promotion and left us
      with a much poorer scheduling order than prior to using semaphores.
      
      The outcome of this patch, is that all requests have NOSEMAPHORE
      priority when they have no dependencies and are ready to run and not
      busywait, restoring the pre-semaphore ordering on saturated systems.
      
      We can demonstrate the effect of poor scheduling order by oversaturating
      the system using gem_wsim on a system with multiple vcs engines
      (i.e running the same workloads across more clients than required for
      peak throughput, e.g. media_load_balance_17i7.wsim -c4 -b context):
      
      x v5.1 (normalized)
      + tip
      * fix
      +------------------------------------------------------------------------+
      |                                                                    x   |
      |                                                                    x   |
      |                                                                    x   |
      |                                                                    x   |
      |                                                                   %x   |
      |                                                                  %%x   |
      |                                                                  %%x   |
      |                                                                  %%x   |
      |                                                                  %%x   |
      |                                                                  %%x   |
      |                                                                  %%x   |
      |                                                                  %%x   |
      |                                                                  %%x   |
      |                                                                  %%x   |
      |                                                                  %%x   |
      |                                                                  %#x   |
      |                                                                  %#x   |
      |                                                                  %#x   |
      |                                                                  %#x   |
      |                                                                  %#x   |
      |         +                                                        %#xx  |
      |         +                                                        %#xx  |
      |         +                                                       %%#xx  |
      |         +                                                       %%#xx  |
      |         +                                                       %%#xx  |
      |         +                                                       %%#xx  |
      |         +                                                       %%##x  |
      |         +++                                                     %%##x  |
      |         +++                                                     %%##x  |
      |         +++                                                     %%##x  |
      |        ++++                                                     %%##x  |
      |        ++++                                                     %%##x  |
      |        ++++                                                     %%##xx |
      |        ++++                                                     %###xx |
      |        ++++                                                     %###xx |
      |        ++++                                                     %###xx |
      |        ++++                                                     %###xx |
      |        ++++ +                                                   %#O#xx |
      |        ++++ +                                                   %#O#xx |
      |        ++++++ +                                                 %#O#xx |
      |       ++++++++++                                                %OOOxxx|
      |       ++++++++++       +                                       %#OOO#xx|
      |     + ++++++++++++ ++ +++++    +                        ++    @@OOOO#xx|
      |                                                                   |A_| |
      ||__________M_______A____________________|                               |
      |                                                                 |A_|   |
      +------------------------------------------------------------------------+
          N           Min           Max        Median           Avg        Stddev
      x 120       0.99456       1.00628      0.999985     1.0001545  0.0024387139
      + 120      0.873021       1.00037      0.884134    0.90148752   0.039190862
      Difference at 99.5% confidence
      	-0.098667 +/- 0.0110762
      	-9.86517% +/- 1.10745%
      	(Student's t, pooled s = 0.0277657)
      % 120      0.990207       1.00165     0.9970265    0.99699748     0.0021024
      Difference at 99.5% confidence
      	-0.003157 +/- 0.000908245
      	-0.315651% +/- 0.0908105%
      	(Student's t, pooled s = 0.00227678)
      
      Fixes: b7404c7e ("drm/i915: Bump ready tasks ahead of busywaits")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
      Cc: Dmitry Ermilov <dmitry.ermilov@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190515130052.4475-2-chris@chris-wilson.co.uk
      (cherry picked from commit 17db337f)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      a491cc8e
    • C
      drm/i915: Downgrade NEWCLIENT to non-preemptive · c80274bb
      Chris Wilson 提交于
      Commit 1413b2bc ("drm/i915: Trim NEWCLIENT boosting") had the
      intended consequence of not allowing a sequence of work that merely
      crossed into a new engine the privilege to be promoted to NEWCLIENT
      status. It also had the unintended consequence of actually making
      NEWCLIENT effective on heavily oversubscribed transcode machines and
      impacting upon their throughput.
      
      If we consider a client packet composed of (rcsA, rcsB, vcs) and 30 of
      those clients, using the NEWCLIENT boost that will be scheduled as
      
      	rcsA x 30, (rcsB, vcs) x 30
      
      where as before it would have been
      
      	(rcsA, rcsB, vcs) x 30
      
      That is with NEWCLIENT only boosting the first request of each client,
      we would execute all rcsA requests prior to running on the vcs engines;
      acruing a lot of dead time as compared to the previous case where the
      vcs engine would be started in parallel to processing the second client.
      
      The previous patch has the effect of delaying submission until it is
      required by a third party (either the user with an explicit wait, or by
      another client/engine). We reduce the NEWCLIENT bump to a mere WAIT,
      which has the effect of removing its preemptive grant and reducing it to
      the same level as any other user interaction -- that it will not be
      promoted above the interengine dependencies, and so preventing NEWCLIENTS
      from starving other engines. This a large nerf to the rrul properties of
      the current NEWCLIENT, but it still does give prioritised submission to
      new requests from light workloads.
      
      References: b16c7651 ("drm/i915: Priority boost for new clients")
      Fixes: 1413b2bc ("drm/i915: Trim NEWCLIENT boosting") # customer impact
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
      Cc: Dmitry Ermilov <dmitry.ermilov@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190515130052.4475-4-chris@chris-wilson.co.uk
      (cherry picked from commit 68fc728b)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      c80274bb
    • C
      drm/i915: Bump signaler priority on adding a waiter · 9981927c
      Chris Wilson 提交于
      The handling of the no-preemption priority level imposes the restriction
      that we need to maintain the implied ordering even though preemption is
      disabled. Otherwise we may end up with an AB-BA deadlock across multiple
      engine due to a real preemption event reordering the no-preemption
      WAITs. To resolve this issue we currently promote all requests to WAIT
      on unsubmission, however this interferes with the timeslicing
      requirement that we do not apply any implicit promotion that will defeat
      the round-robin timeslice list. (If we automatically promote the active
      request it will go back to the head of the queue and not the tail!)
      
      So we need implicit promotion to prevent reordering around semaphores
      where we are not allowed to preempt, and we must avoid implicit
      promotion on unsubmission. So instead of at unsubmit, if we apply that
      implicit promotion on adding the dependency, we avoid the semaphore
      deadlock and we also reduce the gains made by the promotion for user
      space waiting. Furthermore, by keeping the earlier dependencies at a
      higher level, we reduce the search space for timeslicing without
      altering runtime scheduling too badly (no dependencies at all will be
      assigned a higher priority for rrul).
      
      v2: Limit the bump to external edges (as originally intended) i.e.
      between contexts and out to the user.
      
      Testcase: igt/gem_concurrent_blit
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190515130052.4475-3-chris@chris-wilson.co.uk
      (cherry picked from commit 6e7eb7a8)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      9981927c
    • C
      drm/i915: Pass i915_sched_node around internally · f312c23f
      Chris Wilson 提交于
      To simplify the next patch, update bump_priority and schedule to accept
      the internal i915_sched_ndoe directly and not expect a request pointer.
      
      add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7)
      Function                                     old     new   delta
      i915_schedule_bump_priority                  109     113      +4
      i915_schedule                                 50      54      +4
      __i915_schedule                              922     907     -15
      
      v2: Adopt node for the old rq local, since it no longer is a request but
      the origin node.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190513120102.29660-2-chris@chris-wilson.co.uk
      (cherry picked from commit 52c76fb1)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      f312c23f
    • C
      drm/i915: Rearrange i915_scheduler.c · 06b2b1a4
      Chris Wilson 提交于
      To avoid pulling in a forward declaration in the next patch, move the
      i915_sched_node handling to after the main dfs of the scheduler.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190513120102.29660-1-chris@chris-wilson.co.uk
      (cherry picked from commit 5ae87063)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      06b2b1a4
  3. 18 5月, 2019 5 次提交
  4. 17 5月, 2019 3 次提交
    • A
      fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types · f8585539
      Ard Biesheuvel 提交于
      The following commit:
      
        38ac0287 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB")
      
      updated the EFI framebuffer code to use memory mappings for the linear
      framebuffer that are permitted by the memory attributes described by the
      EFI memory map for the particular region, if the framebuffer happens to
      be covered by the EFI memory map (which is typically only the case for
      framebuffers in shared memory). This is required since non-x86 systems
      may require cacheable attributes for memory mappings that are shared
      with other masters (such as GPUs), and this information cannot be
      described by the Graphics Output Protocol (GOP) EFI protocol itself,
      and so we rely on the EFI memory map for this.
      
      As reported by James, this breaks some x86 systems:
      
        [ 1.173368] efifb: probing for efifb
        [ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf800000
        [ 1.173395] Trying to free nonexistent resource <00000000cf800000-00000000cf9d4bff>
        [ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5
      
      The problem turns out to be that the memory map entry that describes the
      framebuffer has no memory attributes listed at all, and so we end up with
      a mem_flags value of 0x0.
      
      So work around this by ensuring that the memory map entry's attribute field
      has a sane value before using it to mask the set of usable attributes.
      Reported-by: NJames Hilliard <james.hilliard1@gmail.com>
      Tested-by: NJames Hilliard <james.hilliard1@gmail.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: <stable@vger.kernel.org> # v4.19+
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: James Morse <james.morse@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 38ac0287 ("fbdev/efifb: Honour UEFI memory map attributes when ...")
      Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      f8585539
    • A
      tty: Don't force RISCV SBI console as preferred console · f91253a3
      Anup Patel 提交于
      The Linux kernel will auto-disables all boot consoles whenever it
      gets a preferred real console.
      
      Currently on RISC-V systems, if we have a real console which is not
      RISCV SBI console then boot consoles (such as earlycon=sbi) are not
      auto-disabled when a real console (ttyS0 or ttySIF0) is available.
      This results in duplicate prints at boot-time after kernel starts
      using real console (i.e. ttyS0 or ttySIF0) if "earlycon=" kernel
      parameter was passed by bootloader.
      
      The reason for above issue is that RISCV SBI console always adds
      itself as preferred console which is causing other real consoles
      to be not used as preferred console.
      
      Ideally "console=" kernel parameter passed by bootloaders should
      be the one selecting a preferred real console.
      
      This patch fixes above issue by not forcing RISCV SBI console as
      preferred console.
      
      Fixes: afa6b1cc ("tty: New RISC-V SBI console driver")
      Cc: stable@vger.kernel.org
      Signed-off-by: NAnup Patel <anup.patel@wdc.com>
      Reviewed-by: NAtish Patra <atish.patra@wdc.com>
      Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
      f91253a3
    • D
      soc: ixp4xx: qmgr: Fix an NULL vs IS_ERR() check in probe · c180d710
      Dan Carpenter 提交于
      The devm_ioremap_resource() function doesn't retunr NULL, it returns
      error pointers.
      
      Fixes: ecc133c6 ("soc: ixp4xx: qmgr: Pass resources")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      c180d710
  5. 16 5月, 2019 7 次提交
    • S
      8454fca4
    • M
      dm crypt: print device name in integrity error message · f710126c
      Milan Broz 提交于
      This message should better identify the DM device with the integrity
      failure.
      Signed-off-by: NMilan Broz <gmazyland@gmail.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      f710126c
    • M
      dm crypt: move detailed message into debug level · 7a1cd723
      Milan Broz 提交于
      The information about tag size should not be printed without debug info
      set. Also print device major:minor in the error message to identify the
      device instance.
      
      Also use rate limiting and debug level for info about used crypto API
      implementaton.  This is important because during online reencryption
      the existing message saturates syslog (because we are moving hotzone
      across the whole device).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMilan Broz <gmazyland@gmail.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      7a1cd723
    • H
      dm ioctl: fix hang in early create error condition · 0f41fcf7
      Helen Koike 提交于
      The dm_early_create() function (which deals with "dm-mod.create=" kernel
      command line option) calls dm_hash_insert() who gets an extra reference
      to the md object.
      
      In case of failure, this reference wasn't being released, causing
      dm_destroy() to hang, thus hanging the whole boot process.
      
      Fix this by calling __hash_remove() in the error path.
      
      Fixes: 6bbc923d ("dm: add support to directly boot to a mapped device")
      Cc: stable@vger.kernel.org
      Signed-off-by: NHelen Koike <helen.koike@collabora.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      0f41fcf7
    • S
      clk: Remove io.h from clk-provider.h · 62e59c4e
      Stephen Boyd 提交于
      Now that we've gotten rid of clk_readl() we can remove io.h from the
      clk-provider header and push out the io.h include to any code that isn't
      already including the io.h header but using things like readl/writel,
      etc.
      
      Found with this grep:
      
        git grep -l clk-provider.h | grep '.c$' | xargs git grep -L 'linux/io.h' | \
        	xargs git grep -l \
      	-e '\<__iowrite32_copy\>' --or \
      	-e '\<__ioread32_copy\>' --or \
      	-e '\<__iowrite64_copy\>' --or \
      	-e '\<ioremap_page_range\>' --or \
      	-e '\<ioremap_huge_init\>' --or \
      	-e '\<arch_ioremap_pud_supported\>' --or \
      	-e '\<arch_ioremap_pmd_supported\>' --or \
      	-e '\<devm_ioport_map\>' --or \
      	-e '\<devm_ioport_unmap\>' --or \
      	-e '\<IOMEM_ERR_PTR\>' --or \
      	-e '\<devm_ioremap\>' --or \
      	-e '\<devm_ioremap_nocache\>' --or \
      	-e '\<devm_ioremap_wc\>' --or \
      	-e '\<devm_iounmap\>' --or \
      	-e '\<devm_ioremap_release\>' --or \
      	-e '\<devm_memremap\>' --or \
      	-e '\<devm_memunmap\>' --or \
      	-e '\<__devm_memremap_pages\>' --or \
      	-e '\<pci_remap_cfgspace\>' --or \
      	-e '\<arch_has_dev_port\>' --or \
      	-e '\<arch_phys_wc_add\>' --or \
      	-e '\<arch_phys_wc_del\>' --or \
      	-e '\<memremap\>' --or \
      	-e '\<memunmap\>' --or \
      	-e '\<arch_io_reserve_memtype_wc\>' --or \
      	-e '\<arch_io_free_memtype_wc\>' --or \
      	-e '\<__io_aw\>' --or \
      	-e '\<__io_pbw\>' --or \
      	-e '\<__io_paw\>' --or \
      	-e '\<__io_pbr\>' --or \
      	-e '\<__io_par\>' --or \
      	-e '\<__raw_readb\>' --or \
      	-e '\<__raw_readw\>' --or \
      	-e '\<__raw_readl\>' --or \
      	-e '\<__raw_readq\>' --or \
      	-e '\<__raw_writeb\>' --or \
      	-e '\<__raw_writew\>' --or \
      	-e '\<__raw_writel\>' --or \
      	-e '\<__raw_writeq\>' --or \
      	-e '\<readb\>' --or \
      	-e '\<readw\>' --or \
      	-e '\<readl\>' --or \
      	-e '\<readq\>' --or \
      	-e '\<writeb\>' --or \
      	-e '\<writew\>' --or \
      	-e '\<writel\>' --or \
      	-e '\<writeq\>' --or \
      	-e '\<readb_relaxed\>' --or \
      	-e '\<readw_relaxed\>' --or \
      	-e '\<readl_relaxed\>' --or \
      	-e '\<readq_relaxed\>' --or \
      	-e '\<writeb_relaxed\>' --or \
      	-e '\<writew_relaxed\>' --or \
      	-e '\<writel_relaxed\>' --or \
      	-e '\<writeq_relaxed\>' --or \
      	-e '\<readsb\>' --or \
      	-e '\<readsw\>' --or \
      	-e '\<readsl\>' --or \
      	-e '\<readsq\>' --or \
      	-e '\<writesb\>' --or \
      	-e '\<writesw\>' --or \
      	-e '\<writesl\>' --or \
      	-e '\<writesq\>' --or \
      	-e '\<inb\>' --or \
      	-e '\<inw\>' --or \
      	-e '\<inl\>' --or \
      	-e '\<outb\>' --or \
      	-e '\<outw\>' --or \
      	-e '\<outl\>' --or \
      	-e '\<inb_p\>' --or \
      	-e '\<inw_p\>' --or \
      	-e '\<inl_p\>' --or \
      	-e '\<outb_p\>' --or \
      	-e '\<outw_p\>' --or \
      	-e '\<outl_p\>' --or \
      	-e '\<insb\>' --or \
      	-e '\<insw\>' --or \
      	-e '\<insl\>' --or \
      	-e '\<outsb\>' --or \
      	-e '\<outsw\>' --or \
      	-e '\<outsl\>' --or \
      	-e '\<insb_p\>' --or \
      	-e '\<insw_p\>' --or \
      	-e '\<insl_p\>' --or \
      	-e '\<outsb_p\>' --or \
      	-e '\<outsw_p\>' --or \
      	-e '\<outsl_p\>' --or \
      	-e '\<ioread8\>' --or \
      	-e '\<ioread16\>' --or \
      	-e '\<ioread32\>' --or \
      	-e '\<ioread64\>' --or \
      	-e '\<iowrite8\>' --or \
      	-e '\<iowrite16\>' --or \
      	-e '\<iowrite32\>' --or \
      	-e '\<iowrite64\>' --or \
      	-e '\<ioread16be\>' --or \
      	-e '\<ioread32be\>' --or \
      	-e '\<ioread64be\>' --or \
      	-e '\<iowrite16be\>' --or \
      	-e '\<iowrite32be\>' --or \
      	-e '\<iowrite64be\>' --or \
      	-e '\<ioread8_rep\>' --or \
      	-e '\<ioread16_rep\>' --or \
      	-e '\<ioread32_rep\>' --or \
      	-e '\<ioread64_rep\>' --or \
      	-e '\<iowrite8_rep\>' --or \
      	-e '\<iowrite16_rep\>' --or \
      	-e '\<iowrite32_rep\>' --or \
      	-e '\<iowrite64_rep\>' --or \
      	-e '\<__io_virt\>' --or \
      	-e '\<pci_iounmap\>' --or \
      	-e '\<virt_to_phys\>' --or \
      	-e '\<phys_to_virt\>' --or \
      	-e '\<ioremap_uc\>' --or \
      	-e '\<ioremap\>' --or \
      	-e '\<__ioremap\>' --or \
      	-e '\<iounmap\>' --or \
      	-e '\<ioremap\>' --or \
      	-e '\<ioremap_nocache\>' --or \
      	-e '\<ioremap_uc\>' --or \
      	-e '\<ioremap_wc\>' --or \
      	-e '\<ioremap_wc\>' --or \
      	-e '\<ioremap_wt\>' --or \
      	-e '\<ioport_map\>' --or \
      	-e '\<ioport_unmap\>' --or \
      	-e '\<ioport_map\>' --or \
      	-e '\<ioport_unmap\>' --or \
      	-e '\<xlate_dev_kmem_ptr\>' --or \
      	-e '\<xlate_dev_mem_ptr\>' --or \
      	-e '\<unxlate_dev_mem_ptr\>' --or \
      	-e '\<virt_to_bus\>' --or \
      	-e '\<bus_to_virt\>' --or \
      	-e '\<memset_io\>' --or \
      	-e '\<memcpy_fromio\>' --or \
      	-e '\<memcpy_toio\>'
      
      I also reordered a couple includes when they weren't alphabetical and
      removed clk.h from kona, replacing it with clk-provider.h because
      that driver doesn't use clk consumer APIs.
      Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Chen-Yu Tsai <wens@csie.org>
      Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Acked-by: NTero Kristo <t-kristo@ti.com>
      Acked-by: NSekhar Nori <nsekhar@ti.com>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Acked-by: NMark Brown <broonie@kernel.org>
      Cc: Chris Zankel <chris@zankel.net>
      Acked-by: NMax Filippov <jcmvbkbc@gmail.com>
      Acked-by: NJohn Crispin <john@phrozen.org>
      Acked-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      62e59c4e
    • S
      drm/msm: Upgrade gxpd checks to IS_ERR_OR_NULL · 2b117451
      Sean Paul 提交于
      dev_pm_domain_attach_by_name() can return NULL, so we should check for
      that case when we're about to dereference gxpd.
      
      Fixes: 9325d426 ("drm/msm/gpu: Attach to the GPU GX power domain")
      Cc: Jordan Crouse <jcrouse@codeaurora.org>
      Cc: Rob Clark <robdclark@chromium.org>
      Reviewed-by: NJordan Crouse <jcrouse@codeauorora.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190515170104.155525-1-sean@poorly.run
      2b117451
    • S
      26359dc5
  6. 15 5月, 2019 18 次提交