{"push_id":823488651,"size":294,"distinct_size":294,"ref":"refs/heads/brcmstb-4.2-stable","head":"ce1489a957156f4bfbedc75460dcc69db630602c","before":"7bc7280be1c22bc3abd5e40d2d20911c8cdeb605","commits":[{"sha":"71f778cf274775aa562fed413d3fb258c358241a","author":{"email":"e85aef63a1a9803b668741313e484162be52f7bd@redhat.com","name":"Stephen Chandler Paul"},"message":"DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd\n\ncommit 924f92bf12bfbef3662619e3ed24a1cea7c1cbcd upstream.\n\nMost of the time this isn't an issue since hotplugging an adaptor will\ntrigger a crtc mode change which in turn, causes the driver to probe\nevery DisplayPort for a dpcd. However, in cases where hotplugging\ndoesn't cause a mode change (specifically when one unplugs a monitor\nfrom a DisplayPort connector, then plugs that same monitor back in\nseconds later on the same port without any other monitors connected), we\nnever probe for the dpcd before starting the initial link training. What\nhappens from there looks like this:\n\n\t- GPU has only one monitor connected. It's connected via\n\t  DisplayPort, and does not go through an adaptor of any sort.\n\n\t- User unplugs DisplayPort connector from GPU.\n\n\t- Change in HPD is detected by the driver, we probe every\n\t  DisplayPort for a possible connection.\n\n\t- Probe the port the user originally had the monitor connected\n\t  on for it's dpcd. This fails, and we clear the first (and only\n\t  the first) byte of the dpcd to indicate we no longer have a\n\t  dpcd for this port.\n\n\t- User plugs the previously disconnected monitor back into the\n\t  same DisplayPort.\n\n\t- radeon_connector_hotplug() is called before everyone else,\n\t  and tries to handle the link training. Since only the first\n\t  byte of the dpcd is zeroed, the driver is able to complete\n\t  link training but does so against the wrong dpcd, causing it\n\t  to initialize the link with the wrong settings.\n\n\t- Display stays blank (usually), dpcd is probed after the\n\t  initial link training, and the driver prints no obvious\n\t  messages to the log.\n\nIn theory, since only one byte of the dpcd is chopped off (specifically,\nthe byte that contains the revision information for DisplayPort), it's\nnot entirely impossible that this bug may not show on certain monitors.\nFor instance, the only reason this bug was visible on my ASUS PB238\nmonitor was due to the fact that this monitor using the enhanced framing\nsymbol sequence, the flag for which is ignored if the radeon driver\nthinks that the DisplayPort version is below 1.1.\n\nSigned-off-by: Stephen Chandler Paul <cpaul@redhat.com>\nReviewed-by: Jerome Glisse <jglisse@redhat.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/71f778cf274775aa562fed413d3fb258c358241a"},{"sha":"197765d90d79d26ed4a57c01b4efa7dbcce7ae6d","author":{"email":"fbd5edba1988036c8923f0cca0cce6ac4811db29@intel.com","name":"Imre Deak"},"message":"drm/i915: apply the PCI_D0/D3 hibernation workaround everywhere on pre GEN6\n\ncommit 54875571bbfde00fc63741715c531cbb5246c3b2 upstream.\n\ncommit da2bc1b9db3351addd293e5b82757efe1f77ed1d\nAuthor: Imre Deak <imre.deak@intel.com>\nDate:   Thu Oct 23 19:23:26 2014 +0300\n\n    drm/i915: add poweroff_late handler\n\nintroduced a regression on old platforms during hibernation. A workaround was\nadded in\n\ncommit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb\nAuthor: Imre Deak <imre.deak@intel.com>\nDate:   Mon Mar 2 13:04:41 2015 +0200\n\n    drm/i915: gen4: work around hang during hibernation\n\nusing an explicit blacklist for the GENs/BIOS vendors where the issue was\nreported. Later there we had reports of the same failure on platforms not on\nthis list.\n\nTo my best knowledge the correct thing to do is still to put the device to PCI\nD3 state during hibernation, see [1] and [2] for the reasons. This also aligns\nwith our future plans to unify more the runtime and system suspend/resume\npaths. Since an exact blacklist seems to be impractical (multiple GENs and\nBIOS vendors are affected) apply the workaround on everything pre GEN6.\n\n[1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/060710.html\n[2] https://lkml.org/lkml/2015/6/22/274\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=95061\nReported-by: Ilya Tumaykin <itumaykin@gmail.com>\nReported-by: Dirk Griesbach <spamthis@freenet.de>\nReported-by: Pavel Machek <pavel@ucw.cz>\nReported-by: Mikko Rapeli <mikko.rapeli@iki.fi>\nTested-by: Mikko Rapeli <mikko.rapeli@iki.fi>\nReported-by: Paul Bolle <pebolle@tiscali.nl>\nSigned-off-by: Imre Deak <imre.deak@intel.com>\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/197765d90d79d26ed4a57c01b4efa7dbcce7ae6d"},{"sha":"529c5643147ef78e1cc8f366a0b0a49e2dedbe67","author":{"email":"cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","name":"Ville Syrjälä"},"message":"drm/i915: Check DP link status on long hpd too\n\ncommit d14e7b6d1d8747826cb900db852351c550e00fdd upstream.\n\nWe are no longer checkling the DP link status on long hpd. We used to do\nthat from the .hot_plug() handler, but it was removed when MST got\nintroduced.\n\nIf there's no userspace we now fail to retrain the link if the sink\npower is toggled (or cable yanked and replugged), meaning the user is\nleft staring at a blank screen. With the retraining put back that should\nbe fixed.\n\nAlso remove the leftover comment that referred to the old retraining\nfrom .hot_plug().\n\nFixes a regression introduced in:\ncommit 0e32b39ceed665bfa4a77a4bc307b6652b991632\nAuthor: Dave Airlie <airlied@redhat.com>\nDate:   Fri May 2 14:02:48 2014 +1000\n\n    drm/i915: add DP 1.2 MST support (v0.7)\n\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453\nTested-by: Palmer Dabbelt <palmer@dabbelt.com>\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641\nCc: Dave Airlie <airlied@redhat.com>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/529c5643147ef78e1cc8f366a0b0a49e2dedbe67"},{"sha":"14d98e461e0c70e5b85b25bddd6ca8947e950881","author":{"email":"cd6e8d405ca90be3a03d5427c5b24fbd2d68dcc4@linux.intel.com","name":"Ville Syrjälä"},"message":"drm/radeon/atom: Send out the full AUX address\n\ncommit 3f8340cc72c9a1a4b49bce7802afd7f248400ef5 upstream.\n\nAUX addresses are 20 bits long. Send out the entire address instead of\njust the low 16 bits.\n\nCc: Alex Deucher <alexander.deucher@amd.com>\nCc: \"Christian König\" <christian.koenig@amd.com>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/14d98e461e0c70e5b85b25bddd6ca8947e950881"},{"sha":"b11b8de427d0fa915f8f0421fa91bd75402775bd","author":{"email":"08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","name":"Alex Deucher"},"message":"drm/amdgpu/atom: Send out the full AUX address\n\ncommit e39daf2c63518a8ce92e3ad5caa04097524b3585 upstream.\n\nAUX addresses are 20 bits long. Send out the entire address instead of\njust the low 16 bits.\n\nPort of:\ndrm/radeon/atom: Send out the full AUX address\nto amdgpu\n\nReviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>\nReviewed-by: Christian König <christian.koenig@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/b11b8de427d0fa915f8f0421fa91bd75402775bd"},{"sha":"9aaf23566d3f726962862bb37e20197daa8f3332","author":{"email":"08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","name":"Alex Deucher"},"message":"drm/radeon/native: Send out the full AUX address\n\ncommit 7040c399aea2b0213a9aefd73e507369a6d641d6 upstream.\n\nAUX addresses are 20 bits long. Send out the entire address instead of\njust the low 16 bits.\n\nPort of:\ndrm/radeon/atom: Send out the full AUX address\nto radeon non-atom aux path\n\nReviewed-by: Christian König <christian.koenig@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/9aaf23566d3f726962862bb37e20197daa8f3332"},{"sha":"c5a3c45b29f7efece508802a093b5a88b560827f","author":{"email":"08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","name":"Alex Deucher"},"message":"drm/radeon: fix HDMI quantization_range for pre-DCE5 asics\n\ncommit 86b7709d48f0df8796bddd7e1ce45c6fb7a7c6ec upstream.\n\nSupport for output_csc is only available on DCE5 and newer so\ndon't mess with the HDMI quantization_range on pre-DCE5 asics.\n\nbug:\nhttps://bugs.freedesktop.org/show_bug.cgi?id=83226\n\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/c5a3c45b29f7efece508802a093b5a88b560827f"},{"sha":"b2a109867f4d17ceb9e77cf1ffeb7aaa7a26fa4d","author":{"email":"302958b3037f7fa601b11152090f51ed851f29fd@amd.com","name":"Jammy Zhou"},"message":"drm/amdgpu: fix one warning message\n\ncommit 21df89a5667de5fcd061753d3833e7dfcf5509d3 upstream.\n\nIn function 'amdgpu_uvd_cs_pass2':\nwarning: 'min_ctx_size' may be used uninitialized in this function\n  buf_sizes[0x4] = min_ctx_size;\n                 ^\nnote: 'min_ctx_size' was declared here\n  unsigned image_size, tmp, min_dpb_size, num_dpb_buffer, min_ctx_size;\n                                                          ^\nSigned-off-by: Jammy Zhou <Jammy.Zhou@amd.com>\nReviewed-by: Christian König <christian.koenig@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/b2a109867f4d17ceb9e77cf1ffeb7aaa7a26fa4d"},{"sha":"a93dd14f3cefffc46e49e55fc907b7323053cf09","author":{"email":"08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","name":"Alex Deucher"},"message":"drm/amdgpu: Don't link train DisplayPort on HPD until we get the dpcd\n\ncommit a887adadb7b9ef9eb4ee48e4ad575aefcfd1db14 upstream.\n\nThis is a port of:\nDRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd\nto amdgpu.\n\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/a93dd14f3cefffc46e49e55fc907b7323053cf09"},{"sha":"0abcb8a6c1ede6322d64f6a46333b38282a00fc4","author":{"email":"08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","name":"Alex Deucher"},"message":"drm/amdgpu: fix IH ring allocation for bus addresses (v2)\n\ncommit 52293c67f1e7542a6dc61037d83c266e216bef27 upstream.\n\nUse pci_alloc_consistent rather than kzalloc since we\nneed 256 byte aligned memory for the ring buffer.\n\nv2: fix copy paste typo in free function noticed\nby Jammy.\n\nbug:\nhttps://bugs.freedesktop.org/show_bug.cgi?id=91749\n\nReviewed-by: Christian König <christian.koenig@amd.com>\nReviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/0abcb8a6c1ede6322d64f6a46333b38282a00fc4"},{"sha":"5ee5204400b16c30151928b3d6e845717e11d888","author":{"email":"08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","name":"Alex Deucher"},"message":"drm/amdgpu: fix typo in dce11 watermark setup\n\ncommit 99a092383794e07d60644b449a01656da112eb1f upstream.\n\nUsing the wrong watermwark value for the secondary\nwatermark.  Copy paste typo.  Noticed by Mykola.\n\nReviewed-by: Harry Wentland <harry.wentland@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/5ee5204400b16c30151928b3d6e845717e11d888"},{"sha":"b17595564244237fdc08965b7e2dc2c7e31710a9","author":{"email":"08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","name":"Alex Deucher"},"message":"drm/amdgpu: fix typo in dce10 watermark setup\n\ncommit be9fd2e978939ab3e59ee4164fa0893e70359557 upstream.\n\nUsing the wrong watermwark value for the secondary\nwatermark.  Copy paste typo.  Noticed by Mykola.\n\nReviewed-by: Harry Wentland <harry.wentland@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/b17595564244237fdc08965b7e2dc2c7e31710a9"},{"sha":"c4764645a1c292c82f8bde5f98956052be5a4ac1","author":{"email":"65adda4326914576405c9e3a62f4904d96573863@wunner.de","name":"Lukas Wunner"},"message":"drm/i915: Preserve SSC earlier\n\ncommit 69f92f67b68ab7028ffe15f0eea76b59f8859383 upstream.\n\nCommit 92122789b2d6 (\"drm/i915: preserve SSC if previously set v3\")\nadded code to intel_modeset_gem_init to override the SSC status read\nfrom VBT with the SSC status set by BIOS.\n\nHowever, intel_modeset_gem_init is invoked *after* intel_modeset_init,\nwhich calls intel_setup_outputs, which *modifies* SSC status by way of\nintel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init\ndoesn't preserve the SSC status set by BIOS but whatever\nintel_init_pch_refclk decided on.\n\nThis is a problem on dual gpu laptops such as the MacBook Pro which\nrequire either a handler to switch DDC lines, or the discrete gpu\nto proxy DDC/AUX communication: Both the handler and the discrete\ngpu may initialize after the i915 driver, and consequently, an LVDS\nconnector may initially seem disconnected and the SSC therefore\nis disabled by intel_init_pch_refclk, but on reprobe the connector\nmay turn out to be connected and the SSC must then be enabled.\n\nDue to 92122789b2d6 however, the SSC is not enabled on reprobe since\nit is assumed BIOS disabled it while in fact it was disabled by\nintel_init_pch_refclk.\n\nAlso, because the SSC status is preserved so late, the preserved value\nonly ever gets used on resume but not on panel initialization:\nintel_modeset_init calls intel_init_display which indirectly calls\nintel_panel_use_ssc via multiple subroutines, *before* the BIOS value\noverrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc\nis the sole user of dev_priv->vbt.lvds_use_ssc).\n\nFix this by moving the code introduced by 92122789b2d6 from\nintel_modeset_gem_init to intel_modeset_init before the invocation\nof intel_setup_outputs and intel_init_display.\n\nAdd a DRM_DEBUG_KMS as suggested way back by Jani:\nhttp://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115\nTested-by: Paul Hordiienko <pvt.gord@gmail.com>\n    [MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]\nTested-by: William Brown <william@blackhats.net.au>\n    [MBP  8,2 2011  intel SNB + amd turks     pre-retina]\nTested-by: Lukas Wunner <lukas@wunner.de>\n    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]\nTested-by: Bruno Bierbaumer <bruno@bierbaumer.net>\n    [MBP 11,3 2013  intel HSW + nvidia GK107  retina -- work in progress]\nFixes: 92122789b2d6 (\"drm/i915: preserve SSC if previously set v3\")\nSigned-off-by: Lukas Wunner <lukas@wunner.de>\nReviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/c4764645a1c292c82f8bde5f98956052be5a4ac1"},{"sha":"9648e7a7c73ecf873afbf2e566258115140740ae","author":{"email":"c7254805a17bd5c41e24c3a278fcbf3afcdfb0fa@redhat.com","name":"Jonathon Jongsma"},"message":"drm/qxl: validate monitors config modes\n\ncommit bd3e1c7c6de9f5f70d97cdb6c817151c0477c5e3 upstream.\n\nDue to some recent changes in\ndrm_helper_probe_single_connector_modes_merge_bits(), old custom modes\nwere not being pruned properly. In current kernels,\ndrm_mode_validate_basic() is called to sanity-check each mode in the\nlist. If the sanity-check passes, the mode's status gets set to to\nMODE_OK. In older kernels this check was not done, so old custom modes\nwould still have a status of MODE_UNVERIFIED at this point, and would\ntherefore be pruned later in the function.\n\nAs a result of this new behavior, the list of modes for a device always\nincludes every custom mode ever configured for the device, with the\nlargest one listed first. Since desktop environments usually choose the\nfirst preferred mode when a hotplug event is emitted, this had the\nresult of making it very difficult for the user to reduce the size of\nthe display.\n\nThe qxl driver did implement the mode_valid connector function, but it\nwas empty. In order to restore the old behavior where old custom modes\nare pruned, we implement a proper mode_valid function for the qxl\ndriver. This function now checks each mode against the last configured\ncustom mode and the list of standard modes. If the mode doesn't match\nany of these, its status is set to MODE_BAD so that it will be pruned as\nexpected.\n\nSigned-off-by: Jonathon Jongsma <jjongsma@redhat.com>\nSigned-off-by: Dave Airlie <airlied@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/9648e7a7c73ecf873afbf2e566258115140740ae"},{"sha":"2c5417aecde9955cc3a48a39946344a22cda522c","author":{"email":"57d7670cd3ba6c6bdc1f4d87dfd208f6d77f3ca8@intel.com","name":"Gaurav K Singh"},"message":"drm/i915: Allow DSI dual link to be configured on any pipe\n\ncommit 824257857fd81f5e749831ff9cd63566b5a86abe upstream.\n\nJust like single link MIPI panels, similarly for dual link panels, pipe\nto be configured is based on the DVO port from VBT Block 2. In hardware,\nPort A is mapped with Pipe A and Port C is mapped with Pipe B.\n\nThis issue got introduced in -\n\ncommit 7e9804fdcffc650515c60f524b8b2076ee59e710\nAuthor: Jani Nikula <jani.nikula@intel.com>\nDate:   Fri Jan 16 14:27:23 2015 +0200\n\n    drm/i915/dsi: add drm mipi dsi host support\n\nSigned-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>\nReviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/2c5417aecde9955cc3a48a39946344a22cda522c"},{"sha":"f962a1efb5d690fbb0b061eb944d6b92953cb8cd","author":{"email":"711c73f64afdce07b7e38039a96d2224209e9a6c@chris-wilson.co.uk","name":"Chris Wilson"},"message":"drm/i915: Always mark the object as dirty when used by the GPU\n\ncommit 51bc140431e233284660b1d22c47dec9ecdb521e upstream.\n\nThere have been many hard to track down bugs whereby userspace forgot to\nflag a write buffer and then cause graphics corruption or a hung GPU\nwhen that buffer was later purged under memory pressure (as the buffer\nappeared clean, its pages would have been evicted rather than preserved\nand any changes more recent than in the backing storage would be lost).\nIn retrospect this is a rare optimisation against memory pressure,\nalready the slow path. If we always mark the buffer as dirty when\naccessed by the GPU, anything not used can still be evicted cheaply\n(ideal behaviour for mark-and-sweep eviction) but we do not run the risk\nof corruption. For correct read serialisation, userspace still has to\nnotify when the GPU writes to an object. However, there are certain\nsituations under which userspace may wish to tell white lies to the\nkernel...\n\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nCc: Daniel Vetter <daniel.vetter@ffwll.ch>\nCc: Kristian Høgsberg <krh@bitplanet.net>\nCc: Jesse Barnes <jbarnes@virtuousgeek.org>\nCc: \"Goel, Akash\" <akash.goel@intel.co>\nCc: Michał Winiarski <michal.winiarski@intel.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/f962a1efb5d690fbb0b061eb944d6b92953cb8cd"},{"sha":"f3bfd56b350b9ece3336deecbc44a03e3d9ca600","author":{"email":"711c73f64afdce07b7e38039a96d2224209e9a6c@chris-wilson.co.uk","name":"Chris Wilson"},"message":"drm/i915: Limit the number of loops for reading a split 64bit register\n\ncommit acd29f7b22262d9e848393b9b6ae13eb42d22514 upstream.\n\nIn I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit\nreads. Due to the nature of the registers we try to read in this manner,\nthey may increment between the two instruction (e.g. a timestamp\ncounter). To keep the result accurate, we repeat the read if we detect\nan overflow (i.e. the upper value varies). However, some hardware is just\nplain flaky and may endless loop as the the upper 32bits are not stable.\nJust give up after a couple of tries and report whatever we read last.\n\nv2: Use the most recent values when erring out on an unstable register.\n\nReported-by: russianneuromancer@ya.ru\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91906\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nCc: Michał Winiarski <michal.winiarski@intel.com>\nCc: Daniel Vetter <daniel.vetter@ffwll.ch>\nCc: Jani Nikula <jani.nikula@linux.intel.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/f3bfd56b350b9ece3336deecbc44a03e3d9ca600"},{"sha":"303b47e5346c6b528c2cc6d4c102eae1ec22326c","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"drm/i915: Fix CSR MMIO address check\n\ncommit 982b0b2dd590c00f089fc6fe915bd0cb302a7f5c upstream.\n\nFix a wrong logical AND (&&) used for the range check of CSR MMIO.\n\nSpotted nicely by gcc -Wlogical-op flag:\n  drivers/gpu/drm/i915/intel_csr.c: In function ‘finish_csr_load’:\n  drivers/gpu/drm/i915/intel_csr.c:353:41: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op]\n\nFixes: eb805623d8b1 ('drm/i915/skl: Add support to load SKL CSR firmware.')\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nReviewed-by: Animesh Manna <animesh.manna@intel.com>\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/303b47e5346c6b528c2cc6d4c102eae1ec22326c"},{"sha":"eb9edaae432b0bbe88072dc95aee0237072b574b","author":{"email":"52616596d8f5df0d597e85ab515377f92f939c68@de.ibm.com","name":"Martin Schwidefsky"},"message":"s390/setup: fix novx parameter\n\ncommit 89b1145e93771d727645c96e323539c029b63f1c upstream.\n\nThe novx parameter disables the vector facility but the HWCAP_S390_VXRS\nbit in the ELf hardware capabilies is always set if the machine has\nthe vector facility. If the user space program uses the \"vx\" string\nin the features field of /proc/cpuinfo to utilize vector instruction\nit will crash if the novx kernel paramter is set.\n\nConvert setup_hwcaps to an arch_initcall and use MACHINE_HAS_VX to\ndecide if the HWCAPS_S390_VXRS bit needs to be set.\n\nReported-by: Ulrich Weigand <uweigand@de.ibm.com>\nReviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/eb9edaae432b0bbe88072dc95aee0237072b574b"},{"sha":"8acfac8b0a70930a9f2d9f651bc76d8fbb3dd5ef","author":{"email":"b9e0f7aed71fa470d5913fb2df2da788a8fb0eb2@pengutronix.de","name":"Markus Pargmann"},"message":"iio: bmg160: IIO_BUFFER and IIO_TRIGGERED_BUFFER are required\n\ncommit 06d2f6ca5a38abe92f1f3a132b331eee773868c3 upstream.\n\nThis patch adds selects for IIO_BUFFER and IIO_TRIGGERED_BUFFER. Without\nIIO_BUFFER, the driver does not compile.\n\nSigned-off-by: Markus Pargmann <mpa@pengutronix.de>\nReviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>\nSigned-off-by: Jonathan Cameron <jic23@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/22ktv/linux/commits/8acfac8b0a70930a9f2d9f651bc76d8fbb3dd5ef"}]}