- 05 Dec, 2017 40 commits
-
-
Ville Syrjälä authored
commit 9271c0ca upstream. Apparently some sinks look at the YQ bits even when receiving RGB, and they get somehow confused when they see a non-zero YQ value. So we can't just blindly follow CEA-861-F and set YQ to match the RGB range. Unfortunately there is no good way to tell whether the sink designer claims to have read CEA-861-F. The CEA extension block revision number has generally been stuck at 3 since forever, and even a very recently manufactured sink might be based on an old design so the manufacturing date doesn't seem like something we can use. In lieu of better information let's follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0. The alternative would of course be to always set YQ=0. And if we ever encounter a HDMI 2.0+ sink with this bug that's what we'll probably have to do. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Eric Anholt <eric@anholt.net> Cc: Neil Kownacki <njkkow@gmail.com> Reported-by:
Neil Kownacki <njkkow@gmail.com> Tested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171108152504.12596-1-ville.syrjala@linux.intel.comAcked-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Laurent Pinchart authored
commit daee5426 upstream. Since commit 4a97a3da ("drm: Don't update property values for atomic drivers") atomic drivers must not update property values as properties are read from the state instead. To catch remaining users, the drm_object_property_set_value() function now throws a warning when called by atomic drivers on non-immutable properties, and we hit that warning when creating connectors. The easy fix is to just remove the drm_object_property_set_value() as it is used here to set the initial value of the connector's DPMS property to OFF. The DPMS property applies on top of the connector's state crtc pointer (initialized to NULL) that is the main connector on/off control, and should thus default to ON. Fixes: 4a97a3da ("drm: Don't update property values for atomic drivers") Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Maarten Lankhorst authored
commit 52dd0650 upstream. Some drivers like i915 start with crtc's enabled, but with deferred fbcon setup they were no longer disabled as part of fbdev setup. Headless units could no longer enter pc3 state because the crtc was still enabled. Fix this by calling restore_fbdev_mode when we would have called it otherwise once during initial fbdev setup. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: ca91a275 ("drm/fb-helper: Support deferred setup") Reported-by:
Thomas Voegtle <tv@lio96.de> Tested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171128111603.62757-1-maarten.lankhorst@linux.intel.comSigned-off-by:
-
Rex Zhu authored
commit 8d8258bd upstream. resulted in unexpected data truncation Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Signed-off-by:
-
Christian König authored
commit 4d98e5ee upstream. When the mutex is locked just in the moment we copy it we end up with a warning that we release a locked mutex. Fix this by properly reinitializing the mutex. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Peter Griffin authored
commit a2f04243 upstream. This patch fixes the following soft lockup: BUG: soft lockup - CPU#0 stuck for 23s! [weston:307] On weston idle-timeout the IP is powered down and reset asserted. On weston resume we get a massive vblank IRQ storm due to the LDI registers having lost some state. This state loss is caused by ade_crtc_atomic_begin() not calling ade_ldi_set_mode(). With this patch applied resuming from Weston idle-timeout works well. Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Tested-by:
John Stultz <john.stultz@linaro.org> Reviewed-by:
Xinliang Liu <xinliang.liu@linaro.org> Signed-off-by:
-
Jonathan Liu authored
commit f3621a8e upstream. During panel removal or system shutdown panel_simple_disable() is called which disables the panel backlight but the panel is still powered due to missing calls to panel_simple_unprepare(). Fixes: d02fd93e ("drm/panel: simple - Disable panel on shutdown") Signed-off-by:
Jonathan Liu <net147@gmail.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170807115545.27747-1-net147@gmail.comSigned-off-by:
-
Roman Kapl authored
commit 4f626a4a upstream. The function for byteswapping the data send to/from atombios was buggy for num_bytes not divisible by four. The function must be aware of the fact that after byte-swapping the u32 units, valid bytes might end up after the num_bytes boundary. This patch was tested on kernel 3.12 and allowed us to sucesfully use DisplayPort on and Radeon SI card. Namely it fixed the link training and EDID readout. The function is patched both in radeon and amd drivers, since the functions and the fixes are identical. Signed-off-by:
Roman Kapl <rka@sysgo.com> Signed-off-by:
-
Jyri Sarha authored
commit ce99f720 upstream. We need the total frame refresh time to check if we are too close to vertical sync when updating the two framebuffer DMA registers and risk a collision. This new method is more accurate that the previous that based on mode's vrefresh value, which itself is inaccurate or may not even be initialized. Reported-by:
Kevin Hao <kexin.hao@windriver.com> Fixes: 11abbc9f ("drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled") Signed-off-by:
Jyri Sarha <jsarha@ti.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Ville Syrjälä authored
commit a111fbc4 upstream. Since commit 632c6e4e ("drm/vblank: Fix flip event vblank count") even drivers that don't implement accurate vblank timestamps will end up using drm_crtc_accurate_vblank_count(). That leads to a WARN every time drm_crtc_arm_vblank_event() gets called. The could be as often as every frame for each active crtc. Considering drm_crtc_accurate_vblank_count() is never any worse than the drm_vblank_count() we used previously, let's just skip the WARN unless DRM_UT_VBL is enabled. That way people won't be bothered by this unless they're debugging vblank code. And let's also change it to WARN_ONCE() so that even when you're debugging vblank code you won't get drowned by constant WARNs. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: "Szyprowski, Marek" <m.szyprowski@samsung.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Reported-by:
Andrzej Hajda <a.hajda@samsung.com> Fixes: 632c6e4e ("drm/vblank: Fix flip event vblank count") Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by:
-
Ville Syrjälä authored
commit 632c6e4e upstream. On machines where the vblank interrupt fires some time after the start of vblank (or we just manage to race with the vblank interrupt handler) we will currently stuff a stale vblank counter value into the flip event, and thus we'll prematurely complete the flip. Switch over to drm_crtc_accurate_vblank_count() to make sure we have an up to date counter value, crucially also remember to add the +1 so that the delayed vblank interrupt won't complete the flip prematurely. Cc: Daniel Vetter <daniel@ffwll.ch> Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Michel Dänzer authored
commit e1fc12c5 upstream. Fixes a use-after-free due to a race condition in ttm_bo_cleanup_refs_and_unlock, which allows one task to reserve a BO and destroy its ttm_resv while another task is waiting for it to signal in reservation_object_wait_timeout_rcu. v2: * Always initialize bo->ttm_resv in ttm_bo_init_reserved (Christian König) Fixes: 0d2bd2ae "drm/ttm: fix memory leak while individualizing BOs" Reviewed-by: Chunming Zhou <david1.zhou@amd.com> # v1 Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Christian König authored
commit 2642cf11 upstream. Otherwise somebody could try to evict it at the same time and try to use half torn down structures. Signed-off-by:
-
Christian König authored
commit 39e16ba1 upstream. Stop requiring that the src reservation object is locked for this operation. Acked-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
-
Christian König authored
commit 378e2d5b upstream. With shared reservation objects __ttm_bo_reserve() can easily fail even on destroyed BOs. This prevents correct handling when we need to individualize the reservation object. Fix this by individualizing the object before even trying to reserve it. Signed-off-by:
-
Ken Wang authored
commit ab6613b7 upstream. Fixes vbios fetching on certain headless boards. Signed-off-by:
Ken Wang <Ken.Wang@amd.com> Acked-by:
-
ozeng authored
commit c5066129 upstream. v1: Properly allocate TLB invalidation engine to avoid conflict. v2: Added comments to codes Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
-
Christian König authored
commit a695e437 upstream. The bo structure is freed up in case of an error, so we can't do any accounting if that happens. Signed-off-by:
-
Ken Wang authored
commit 76d6172b upstream. Old value from bringup was wrong. Signed-off-by:
-
Dan Carpenter authored
commit 78aa02c7 upstream. After commit ea09729c ("drm/amdgpu: rework page directory filling v2") then it becomes a lot harder to verify that "r" is initialized. My static checker complains and so I've reviewed the code. It does look like it might be buggy... Anyway, it doesn't hurt to set "r" to zero at the start. Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Dan Carpenter authored
commit 40a9960b upstream. We shifted some code around in commit 9cca0b8e ("drm/amdgpu: move amdgpu_cs_sysvm_access_required into find_mapping") and now my static checker complains that "r" might not be initialized at the end of the function. I've reviewed the code, and that seems possible, but it's also possible I may have missed something. Reviewed-by:
-
Alex Deucher authored
commit 18c437ca upstream. Fixes distorted colors on some cards on resume from suspend. This reverts commit b9729b17. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98832 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99163 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=107001Reviewed-by:
-
Jeff Lien authored
commit 8c97eecc upstream. And increase the existing delay to cover this device as well. Signed-off-by:
Jeff Lien <jeff.lien@wdc.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Peter Rosin authored
commit 68615eb0 upstream. With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver is not always capable of avoiding the 25-35 ms timeout as specified by the SMBUS protocol. This may cause silent corruption of the last bit of any transfer, e.g. a one is read instead of a zero if the sensor chip times out. This also affects the eeprom half of the nxp-se97 chip, where this silent corruption was originally noticed. Other I2C adapters probably suffer similar issues, e.g. bit-banging comes to mind as risky... The SMBUS register in the nxp chip is not a standard Jedec register, but it is not special to the nxp chips either, at least the atmel chips have the same mechanism. Therefore, do not special case this on the manufacturer, it is opt-in via the device property anyway. Signed-off-by:
Peter Rosin <peda@axentia.se> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Rui Hua authored
commit e393aa24 upstream. When we send a read request and hit the clean data in cache device, there is a situation called cache read race in bcache(see the commit in the tail of cache_look_up(), the following explaination just copy from there): The bucket we're reading from might be reused while our bio is in flight, and we could then end up reading the wrong data. We guard against this by checking (in bch_cache_read_endio()) if the pointer is stale again; if so, we treat it as an error (s->iop.error = -EINTR) and reread from the backing device (but we don't pass that error up anywhere) It should be noted that cache read race happened under normal circumstances, not the circumstance when SSD failed, it was counted and shown in /sys/fs/bcache/XXX/internal/cache_read_races. Without this patch, when we use writeback mode, we will never reread from the backing device when cache read race happened, until the whole cache device is clean, because the condition (s->recoverable && (dc && !atomic_read(&dc->has_dirty))) is false in cached_dev_read_error(). In this situation, the s->iop.error(= -EINTR) will be passed up, at last, user will receive -EINTR when it's bio end, this is not suitable, and wield to up-application. In this patch, we use s->read_dirty_data to judge whether the read request hit dirty data in cache device, it is safe to reread data from the backing device when the read request hit clean data. This can not only handle cache read race, but also recover data when failed read request from cache device. [edited by mlyle to fix up whitespace, commit log title, comment spelling] Fixes: d59b2379 ("bcache: only permit to recovery read error when cache device is clean") Signed-off-by:
Hua Rui <huarui.dev@gmail.com> Reviewed-by:
Michael Lyle <mlyle@lyle.org> Reviewed-by:
Coly Li <colyli@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Coly Li authored
commit d59b2379 upstream. When bcache does read I/Os, for example in writeback or writethrough mode, if a read request on cache device is failed, bcache will try to recovery the request by reading from cached device. If the data on cached device is not synced with cache device, then requester will get a stale data. For critical storage system like database, providing stale data from recovery may result an application level data corruption, which is unacceptible. With this patch, for a failed read request in writeback or writethrough mode, recovery a recoverable read request only happens when cache device is clean. That is to say, all data on cached device is up to update. For other cache modes in bcache, read request will never hit cached_dev_read_error(), they don't need this patch. Please note, because cache mode can be switched arbitrarily in run time, a writethrough mode might be switched from a writeback mode. Therefore checking dc->has_data in writethrough mode still makes sense. Changelog: V4: Fix parens error pointed by Michael Lyle. v3: By response from Kent Oversteet, he thinks recovering stale data is a bug to fix, and option to permit it is unnecessary. So this version the sysfs file is removed. v2: rename sysfs entry from allow_stale_data_on_failure to allow_stale_data_on_failure, and fix the confusing commit log. v1: initial patch posted. [small change to patch comment spelling by mlyle] Signed-off-by:
Arne Wolf <awolf@lenovo.com> Reviewed-by:
-
Huacai Chen authored
commit cf33c1ee upstream. This patch try to fix the building error on MIPS. The reason is MIPS has already defined the PTR macro, which conflicts with the PTR macro in include/uapi/linux/bcache.h. [fixed by mlyle: corrected a line-length issue] Signed-off-by:
Huacai Chen <chenhc@lemote.com> Reviewed-by:
-
Vaibhav Jain authored
commit 12841f87 upstream. During an eeh a kernel-oops is reported if no vPHB is allocated to the AFU. This happens as during AFU init, an error in creation of vPHB is a non-fatal error. Hence afu->phb should always be checked for NULL before iterating over it for the virtual AFU pci devices. This patch fixes the kenel-oops by adding a NULL pointer check for afu->phb before it is dereferenced. Fixes: 9e8df8a2 ("cxl: EEH support") Signed-off-by:
Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Acked-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Acked-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Hans de Goede authored
commit 6e0c9507 upstream. On Apollo Lake devices the BIOS does not set up IRQ routing for the i801 SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED. Detect this and do not try to use the irq in this case silencing: i801_smbus 0000:00:1f.1: Failed to allocate irq -2147483648: -107 BugLink: https://communities.intel.com/thread/114759Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Heiner Kallweit authored
commit d9bcd462 upstream. So far we completely rely on the caller to provide valid arguments. To be on the safe side perform an own sanity check. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
-
Bartosz Golaszewski authored
commit 5478e478 upstream. There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6, making it impossible to read it all. Fix it by manually adjusting the value in probe(). This patch contains a temporary fix that is suitable for stable branches. Eventually we'll probably remove the call to ilog2() while converting the magic values to actual structs. Fixes: 0b813658 ("eeprom: at24: add support for at24mac series") Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
commit 644a1f19 upstream. Chip datasheet mentions that word addresses other than the actual start position of the MAC delivers undefined results. So fix this. Current implementation doesn't work due to this wrong offset. Fixes: 0b813658 ("eeprom: at24: add support for at24mac series") Signed-off-by:
-
Lv Zheng authored
commit a64a62ce upstream. On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an ACPI device. Thus the following commit actually removed post-resume acpi_ec_enable_event() invocation for such platforms, and triggered a regression on them that after being resumed, EC (actually should be ECDT) driver stops handling EC events: Commit: c2b46d67 Subject: ACPI / EC: Add PM operations to improve event handling for resume process Notice that the root cause actually is "ECDT is not an ACPI device" rather than "the timing of acpi_ec_enable_event() invocation", this patch fixes this issue by enumerating ECDT EC as an ACPI device. Due to the existence of the noirq stage, the ability of tuning the timing of acpi_ec_enable_event() invocation is still meaningful. This patch is a little bit different from the posted fix by moving acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make sure that EC event handling won't be stopped as long as the ACPI EC driver is bound. Thus the following sequence shouldn't disable EC event handling: unbind,suspend,resume,bind. Fixes: c2b46d67 (ACPI / EC: Add PM operations to improve event handling for resume process) Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847Reported-by:
Luya Tshimbalanga <luya@fedoraproject.org> Tested-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Bastian Stender authored
commit c892b0d8 upstream. The sysfs entry "ocr" was missing the 0x prefix to identify it as hex formatted. Fixes: 5fb06af7 ("mmc: core: Extend sysfs with OCR register") Signed-off-by:
Bastian Stender <bst@pengutronix.de> [Ulf: Amended change to also cover SD-cards] Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Bastian Stender authored
commit 80a780a1 upstream. The sysfs entry "pre_eol_info" was missing the 0x prefix to identify it as hex formatted. Fixes: 46bc5c40 ("mmc: core: Export device lifetime information through sysfs") Signed-off-by:
-
Adrian Hunter authored
commit f9f0da98 upstream. The card is not necessarily being removed, but the debugfs files must be removed when the driver is removed, otherwise they will continue to exist after unbinding the card from the driver. e.g. # echo "mmc1:0001" > /sys/bus/mmc/drivers/mmcblk/unbind # cat /sys/kernel/debug/mmc1/mmc1\:0001/ext_csd [ 173.634584] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [ 173.643356] IP: mmc_ext_csd_open+0x5e/0x170 A complication is that the debugfs_root may have already been removed, so check for that too. Fixes: 627c3ccf ("mmc: debugfs: Move block debugfs into block module") Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Adrian Hunter authored
commit ebe7dd45 upstream. The block driver must be resumed if the mmc bus fails to suspend the card. Signed-off-by:
-
Adrian Hunter authored
commit fb8e456e upstream. blk_get_request() can fail, always check the return value. Fixes: 0493f6fe ("mmc: block: Move boot partition locking into a driver op") Fixes: 3ecd8cf2 ("mmc: block: move multi-ioctl() to use block layer") Fixes: 614f0388 ("mmc: block: move single ioctl() commands to block requests") Fixes: 627c3ccf ("mmc: debugfs: Move block debugfs into block module") Signed-off-by:
-
Adrian Hunter authored
commit 34c089e8 upstream. Ensure blk_get_request() is paired with blk_put_request(). Fixes: 0493f6fe ("mmc: block: Move boot partition locking into a driver op") Fixes: 627c3ccf ("mmc: debugfs: Move block debugfs into block module") Signed-off-by:
-
Ulf Hansson authored
commit 250dcd11 upstream. The commit de3ee99b ("mmc: Delete bounce buffer handling") deletes the bounce buffer handling, but also causes the max_req_size for sdhci to be increased, in case when max_segs == 1. This causes errors for sdhci-pci Ricoh variant, about the swiotlb buffer to become full. Fix the issue, by taking IO_TLB_SEGSIZE and IO_TLB_SHIFT into account when deciding the max_req_size for sdhci. Reported-by:
Jiri Slaby <jslaby@suse.cz> Fixes: de3ee99b ("mmc: Delete bounce buffer handling") Signed-off-by:
-
