Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 08 5月, 2015 2 次提交
  3. 30 4月, 2015 22 次提交
  5. 29 4月, 2015 4 次提交
  7. 28 4月, 2015 4 次提交
  9. 27 4月, 2015 1 次提交
  11. 25 4月, 2015 2 次提交
    • D
      platform/chrome: chromeos_laptop - instantiate Atmel at primary address · 96cba9b0
      由 Dmitry Torokhov 提交于 
      The new Atmel MXT driver expects i2c client's address contain the
primary (main address) of the chip, and calculates the expected
bootloader address form the primary address. Unfortunately chrome_laptop
does probe the devices and if touchpad (or touchscreen, or both) comes
up in bootloader mode the i2c device gets instantiated with the
bootloader address which confuses the driver.

To work around this issue let's probe the primary address first. If the
device is not detected at the primary address we'll probe alternative
addresses as "dummy" devices. If any of them are found, destroy the
dummy client and instantiate client with proper name at primary address
still.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      96cba9b0
    • H
      toshiba_acpi: Do not register vendor backlight when acpi_video bl is available · 358d6a2c
      由 Hans de Goede 提交于 
      commit a39f46df ("toshiba_acpi: Fix regression caused by backlight extra
check code") causes the backlight to no longer work on the Toshiba Z30,
reverting that commit fixes this but restores the original issue fixed
by that commit.

Looking at the toshiba_acpi backlight code for a fix for this I noticed that
the toshiba code is the only code under platform/x86 which unconditionally
registers a vendor acpi backlight interface, without checking for acpi_video
backlight support first.

This commit adds the necessary checks bringing toshiba_acpi in line with the
other drivers, and fixing the Z30 regression without needing to revert the
commit causing it.

Chances are that there will be some Toshiba models which have a non working
acpi-video implementation while the toshiba vendor backlight interface does
work, this commit adds an empty dmi_id table where such systems can be added,
this is identical to how other drivers handle such systems.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1206036
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=86521Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-and-tested-by: NAzael Avalos <coproscefalo@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      358d6a2c
  13. 24 4月, 2015 5 次提交
    • G
      crypto: img-hash - CRYPTO_DEV_IMGTEC_HASH should depend on HAS_DMA · 8c98ebd7
      由 Geert Uytterhoeven 提交于 
      If NO_DMA=y:

    drivers/built-in.o: In function `img_hash_write_via_dma_stop':
    img-hash.c:(.text+0xa2b822): undefined reference to `dma_unmap_sg'
    drivers/built-in.o: In function `img_hash_xmit_dma':
    img-hash.c:(.text+0xa2b8d8): undefined reference to `dma_map_sg'
    img-hash.c:(.text+0xa2b948): undefined reference to `dma_unmap_sg'

Also move the "depends" section below the "tristate" line while we're at
it.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8c98ebd7
    • R
      ACPI / scan: Add a scan handler for PRP0001 · 7d284352
      由 Rafael J. Wysocki 提交于 
      If the special PRP0001 device ID is present in the given device's list
of ACPI/PNP IDs and the device has a valid "compatible" property in
the _DSD, it should be enumerated using the default mechanism,
unless some scan handlers match the IDs preceding PRP0001 in the
device's list of ACPI/PNP IDs.  In addition to that, no scan handlers
matching the IDs following PRP0001 in that list should be attached
to the device.

To make that happen, define a scan handler that will match PRP0001
and trigger the default enumeration for the matching devices if the
"compatible" property is present for them.

Since that requires the check for platform_id and device->handler
to be removed from acpi_default_enumeration(), move the fallback
invocation of acpi_default_enumeration() to acpi_bus_attach()
(after it's checked if there's a matching ACPI driver for the
device), which is a better place to call it, and do the platform_id
check in there too (device->handler is guaranteed to be unset at
the point where the function is looking for a matching ACPI driver).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
      7d284352
    • R
      ACPI / scan: Annotate physical_node_lock in acpi_scan_is_offline() · 4c533c80
      由 Rafael J. Wysocki 提交于 
      acpi_scan_is_offline() may be called under the physical_node_lock
lock of the given device object's parent, so prevent lockdep from
complaining about that by annotating that instance with
SINGLE_DEPTH_NESTING.

Fixes: caa73ea1 (ACPI / hotplug / driver core: Handle containers in a special way)
Reported-and-tested-by: NXie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: NToshi Kani <toshi.kani@hp.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4c533c80
    • I
      drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT reg · b5f1c97f
      由 Imre Deak 提交于 
      Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across
suspend/resume, so fix this.

This was introduced in

commit ddeea5b0
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon May 5 15:19:56 2014 +0300

    drm/i915: vlv: add runtime PM support

I noticed this only by reading the code. To my knowledge it shouldn't
cause any real problems at the moment, since the power well backing this
register remains on across a runtime s/r. This may change once
system-wide s0ix functionality is enabled in the kernel.

v2:
- resend after a missing git add -u :/

Cc: stable@vger.kernel.org
Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      b5f1c97f
    • M
      drm/i915: Workaround to avoid lite restore with HEAD==TAIL · 53292cdb
      由 Michel Thierry 提交于 
      WaIdleLiteRestore is an execlists-only workaround, and requires the driver
to ensure that any context always has HEAD!=TAIL when attempting lite
restore.

Add two extra MI_NOOP instructions at the end of each request, but keep
the requests tail pointing before the MI_NOOPs. We may not need to
executed them, and this is why request->tail is sampled before adding
these extra instructions.

If we submit a context to the ELSP which has previously been submitted,
move the tail pointer past the MI_NOOPs. This ensures HEAD!=TAIL.

v2: Move overallocation to gen8_emit_request, and added note about
sampling request->tail in commit message (Chris).

v3: Remove redundant request->tail assignment in __i915_add_request, in
lrc mode this is already set in execlists_context_queue.
Do not add wa implementation details inside gem (Chris).

v4: Apply the wa whenever the req has been resubmitted and update
comment (Chris).

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NThomas Daniel <thomas.daniel@intel.com>
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      53292cdb