{"push_id":1242768579,"size":57,"distinct_size":23,"ref":"refs/heads/uniphier-next","head":"1bf33c2d622334a8927ffc80f329c0ce417f3c26","before":"e6c8d1d4806c32520acaa98203cb9216106d093a","commits":[{"sha":"3b2c1710fac7fb278b760d1545e637cbb5ea5b5b","author":{"name":"Ville Syrjälä","email":"97bbb7c58ba09bd338b1646c9fa52af32290a230@linux.intel.com"},"message":"drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL\n\nBspec tells us to keep bashing the PCU for up to 3ms when trying to\ninform it about an upcoming change in the cdclk frequency. Currently\nwe only keep at it for 15*10usec (+ whatever delays gets added by\nthe sandybridge_pcode_read() itself). Let's change the limit to 3ms.\n\nI decided to keep 10 usec delay per iteration for now, even though\nthe spec doesn't really tell us to do that.\n\nCc: stable@vger.kernel.org\nFixes: 5d96d8afcfbb (\"drm/i915/skl: Deinit/init the display at suspend/resume\")\nCc: David Weinehall <david.weinehall@intel.com>\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/1468416723-23440-1-git-send-email-ville.syrjala@linux.intel.com\nTested-by: David Weinehall <david.weinehall@intel.com>\nReviewed-by: Chris Wilson <chris@chris-wilson.co.uk>\n(cherry picked from commit 848496e5902833600f7992f4faa82dc1546051ba)\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/3b2c1710fac7fb278b760d1545e637cbb5ea5b5b"},{"sha":"a7b4667a00025ac28300737c868bd4818b6d8c4d","author":{"name":"Ville Syrjälä","email":"97bbb7c58ba09bd338b1646c9fa52af32290a230@linux.intel.com"},"message":"drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB\n\nSNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck\nin an infinite batch buffer loop. The GPU apparently hogs something\ncritical and CPUs start to lose interrupts and whatnot. We can keep\nthe system limping along by unmasking some interrupts in\nGEN6_PMINTRMSK. The EI up interrupt has been previously chosen for\nthat task, so let's never mask it.\n\nv2: s/gen6_rps_pm_mask/gen6_sanitize_rps_pm_mask/ (Chris)\n\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93122\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nReviewed-by: Chris Wilson <chris@chris-wilson.co.uk>\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nLink: http://patchwork.freedesktop.org/patch/msgid/1464014568-4529-1-git-send-email-ville.syrjala@linux.intel.com\nCc: stable@vger.kernel.org\n(cherry picked from commit 12c100bfa5d9103b6c4d43636fee09c31e75605a)\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/a7b4667a00025ac28300737c868bd4818b6d8c4d"},{"sha":"7f555c8e5a84b348c2b76f4ca78eae7222354c03","author":{"name":"Alex Deucher","email":"a78d72677105f78f4b18925c366b6f577763ca59@amd.com"},"message":"drm/amdgpu/gmc7: add missing mullins case\n\nLooks like this got missed when we ported the code from radeon.\n\nReviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nCc: stable@vger.kernel.org","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/7f555c8e5a84b348c2b76f4ca78eae7222354c03"},{"sha":"903f75c8958e21f0fba2520467c11eaca824226d","author":{"name":"Alex Deucher","email":"a78d72677105f78f4b18925c366b6f577763ca59@amd.com"},"message":"drm/amdgpu/ci: add mullins to default case for smc ucode\n\nIt's already covered by the default case, but add it for\nconsistency.\n\nReviewed-by: Alexandre Demers <alexandre.f.demers@gmail.com>\nReviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/903f75c8958e21f0fba2520467c11eaca824226d"},{"sha":"4f7ec157cb6dfb1e2cd18abf21e6cb1107842c5f","author":{"name":"Eric Huang","email":"c022825cec3c00aa7480ea91734b314ab30a1e1b@amd.com"},"message":"drm/amd/amdgpu: change pptable output format from ASCII to binary\n\nReviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>\nReviewed-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Eric Huang <JinHuiEric.Huang@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/4f7ec157cb6dfb1e2cd18abf21e6cb1107842c5f"},{"sha":"fe85f07f582751da0a65d4ba7e3b36ebcbe55019","author":{"name":"Huang Rui","email":"36c602cf7858180bb4e235877d5b1b89d8b31880@amd.com"},"message":"drm/amdgpu: update golden setting of iceland\n\nSigned-off-by: Huang Rui <ray.huang@amd.com>\nReviewed-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/fe85f07f582751da0a65d4ba7e3b36ebcbe55019"},{"sha":"3a494b588f724fde00ae3ca0aa1c7e6cef1d0d51","author":{"name":"Huang Rui","email":"36c602cf7858180bb4e235877d5b1b89d8b31880@amd.com"},"message":"drm/amdgpu: update golden setting of carrizo\n\nSigned-off-by: Huang Rui <ray.huang@amd.com>\nReviewed-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/3a494b588f724fde00ae3ca0aa1c7e6cef1d0d51"},{"sha":"9761bc53c8e1c52f3f0aa4334f38fd87b0cf1613","author":{"name":"Huang Rui","email":"36c602cf7858180bb4e235877d5b1b89d8b31880@amd.com"},"message":"drm/amdgpu: update golden setting of polaris11\n\nSigned-off-by: Huang Rui <ray.huang@amd.com>\nReviewed-by: Alex Deucher <alexander.deucher@amd.com>\nReviewed-by: Ken Wang <Qingqing.Wang@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/9761bc53c8e1c52f3f0aa4334f38fd87b0cf1613"},{"sha":"6d51c813b172b4374fe7a6b732b6666f8d77bfea","author":{"name":"Huang Rui","email":"36c602cf7858180bb4e235877d5b1b89d8b31880@amd.com"},"message":"drm/amdgpu: update golden setting of stoney\n\nSigned-off-by: Huang Rui <ray.huang@amd.com>\nReviewed-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/6d51c813b172b4374fe7a6b732b6666f8d77bfea"},{"sha":"a5a5e3084ec457f234298392dfa2c55db47b603f","author":{"name":"Huang Rui","email":"36c602cf7858180bb4e235877d5b1b89d8b31880@amd.com"},"message":"drm/amdgpu: update golden setting of polaris10\n\nSigned-off-by: Huang Rui <ray.huang@amd.com>\nReviewed-by: Ken Wang <Qingqing.Wang@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/a5a5e3084ec457f234298392dfa2c55db47b603f"},{"sha":"c45eb4fed12d278d3619f1904885bd0d7bcbf036","author":{"name":"Chris Wilson","email":"4181b934c2715a2bba60cdb3cc1b35b2777d1c23@chris-wilson.co.uk"},"message":"drm/i915/fbdev: Check for the framebuffer before use\n\nIf the fbdev probing fails, and in our error path we fail to clear the\ndev_priv->fbdev, then we can try and use a dangling fbdev pointer, and\nin particular a NULL fb. This could also happen in pathological cases\nwhere we try to operate on the fbdev prior to it being probed.\n\nReported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nCc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nCc: Daniel Vetter <daniel.vetter@ffwll.ch>\nCc: Mika Kuoppala <mika.kuoppala@intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/1468431285-28264-2-git-send-email-chris@chris-wilson.co.uk\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nReviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>\n(cherry picked from commit 6bc265424df02f8162f4a17a37e4982e1c64460e)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/c45eb4fed12d278d3619f1904885bd0d7bcbf036"},{"sha":"34b58355ad1d9987267f071265a7de6c8e00662a","author":{"name":"Michel Dänzer","email":"04e02e363b23f600e6da8ae785c28c5ce9396c71@amd.com"},"message":"drm/ttm: Wait for a BO to become idle before unbinding it from GTT\n\nFixes hangs under memory pressure, e.g. running the piglit test\ntex3d-maxsize concurrently with other tests.\n\nFixes: 17d33bc9d6ef (\"drm/ttm: drop waiting for idle in ttm_bo_evict.\")\nReviewed-by: Christian König <christian.koenig@amd.com>\nSigned-off-by: Michel Dänzer <michel.daenzer@amd.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/34b58355ad1d9987267f071265a7de6c8e00662a"},{"sha":"29986cc8a66fcc4b8ea8a01216a72f06b865360b","author":{"name":"Laurent Pinchart","email":"dfff9eab8dcd6d9d1934c4f057d73aa60e445f37@ideasonboard.com"},"message":"drm: rcar-du: Link HDMI encoder with bridge\n\nThe conversion of the rcar-du driver from the I2C slave encoder to the\nDRM bridge API left the HDMI encoder's bridge pointer NULL, preventing\nthe bridge from being handled automatically by the DRM core. Fix it.\n\nFixes: 1d926114d8f4 (\"drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder\")\nSigned-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>\nSigned-off-by: Dave Airlie <airlied@redhat.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/29986cc8a66fcc4b8ea8a01216a72f06b865360b"},{"sha":"5c6c201ccbaf9d3901f829441d457293f7ca8ef4","author":{"name":"Daniel Vetter","email":"4f5189bfa310957cda373dea5355a767cfa5df2f@ffwll.ch"},"message":"drm: Paper over locking inversion after registration rework\n\ndrm_connector_register_all requires a few too many locks because our\nconnector_list locking is busted. Add another FIXME+hack to work\naround this. This should address the below lockdep splat:\n\n======================================================\n[ INFO: possible circular locking dependency detected ]\n4.7.0-rc5+ #524 Tainted: G           O\n-------------------------------------------------------\nkworker/u8:0/6 is trying to acquire lock:\n (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120\n\nbut task is already holding lock:\n ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #1 ((fb_notifier_list).rwsem){++++.+}:\n       [<ffffffff810df611>] lock_acquire+0xb1/0x200\n       [<ffffffff819a55b4>] down_write+0x44/0x80\n       [<ffffffff810abf91>] blocking_notifier_chain_register+0x21/0xb0\n       [<ffffffff814c7448>] fb_register_client+0x18/0x20\n       [<ffffffff814c6c86>] backlight_device_register+0x136/0x260\n       [<ffffffffa0127eb2>] intel_backlight_device_register+0xa2/0x160 [i915]\n       [<ffffffffa00f46be>] intel_connector_register+0xe/0x10 [i915]\n       [<ffffffffa0112bfb>] intel_dp_connector_register+0x1b/0x80 [i915]\n       [<ffffffff8159dfea>] drm_connector_register+0x4a/0x80\n       [<ffffffff8159fe44>] drm_connector_register_all+0x64/0xf0\n       [<ffffffff815a2a64>] drm_modeset_register_all+0x174/0x1c0\n       [<ffffffff81599b72>] drm_dev_register+0xc2/0xd0\n       [<ffffffffa00621d7>] i915_driver_load+0x1547/0x2200 [i915]\n       [<ffffffffa006d80f>] i915_pci_probe+0x4f/0x70 [i915]\n       [<ffffffff814a2135>] local_pci_probe+0x45/0xa0\n       [<ffffffff814a349b>] pci_device_probe+0xdb/0x130\n       [<ffffffff815c07e3>] driver_probe_device+0x223/0x440\n       [<ffffffff815c0ad5>] __driver_attach+0xd5/0x100\n       [<ffffffff815be386>] bus_for_each_dev+0x66/0xa0\n       [<ffffffff815c002e>] driver_attach+0x1e/0x20\n       [<ffffffff815bf9be>] bus_add_driver+0x1ee/0x280\n       [<ffffffff815c1810>] driver_register+0x60/0xe0\n       [<ffffffff814a1a10>] __pci_register_driver+0x60/0x70\n       [<ffffffffa01a905b>] i915_init+0x5b/0x62 [i915]\n       [<ffffffff8100042d>] do_one_initcall+0x3d/0x150\n       [<ffffffff811a935b>] do_init_module+0x5f/0x1d9\n       [<ffffffff81124416>] load_module+0x20e6/0x27e0\n       [<ffffffff81124d63>] SYSC_finit_module+0xc3/0xf0\n       [<ffffffff81124dae>] SyS_finit_module+0xe/0x10\n       [<ffffffff819a83a9>] entry_SYSCALL_64_fastpath+0x1c/0xac\n\n-> #0 (&dev->mode_config.mutex){+.+.+.}:\n       [<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260\n       [<ffffffff810df611>] lock_acquire+0xb1/0x200\n       [<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0\n       [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120\n       [<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80\n       [<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50\n       [<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]\n       [<ffffffff814c13c6>] fbcon_init+0x586/0x610\n       [<ffffffff8154d16a>] visual_init+0xca/0x130\n       [<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0\n       [<ffffffff8154eaf6>] do_take_over_console+0x116/0x180\n       [<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0\n       [<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750\n       [<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0\n       [<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70\n       [<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20\n       [<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20\n       [<ffffffff814c86b1>] register_framebuffer+0x251/0x330\n       [<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0\n       [<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]\n       [<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150\n       [<ffffffff810a3947>] process_one_work+0x1e7/0x750\n       [<ffffffff810a3efb>] worker_thread+0x4b/0x4f0\n       [<ffffffff810aad4f>] kthread+0xef/0x110\n       [<ffffffff819a85ef>] ret_from_fork+0x1f/0x40\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  lock((fb_notifier_list).rwsem);\n                               lock(&dev->mode_config.mutex);\n                               lock((fb_notifier_list).rwsem);\n  lock(&dev->mode_config.mutex);\n\n *** DEADLOCK ***\n\n6 locks held by kworker/u8:0/6:\n #0:  (\"events_unbound\"){.+.+.+}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750\n #1:  ((&entry->work)){+.+.+.}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750\n #2:  (registration_lock){+.+.+.}, at: [<ffffffff814c8487>] register_framebuffer+0x27/0x330\n #3:  (console_lock){+.+.+.}, at: [<ffffffff814c86ce>] register_framebuffer+0x26e/0x330\n #4:  (&fb_info->lock){+.+.+.}, at: [<ffffffff814c78dd>] lock_fb_info+0x1d/0x40\n #5:  ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70\n\nstack backtrace:\nCPU: 2 PID: 6 Comm: kworker/u8:0 Tainted: G           O    4.7.0-rc5+ #524\nHardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0138.B33.1606250842 06/25/2016\nWorkqueue: events_unbound async_run_entry_fn\n 0000000000000000 ffff8800758577f0 ffffffff814507a5 ffffffff828b9900\n ffffffff828b9900 ffff880075857830 ffffffff810dc6fa ffff880075857880\n ffff88007584d688 0000000000000005 0000000000000006 ffff88007584d6b0\nCall Trace:\n [<ffffffff814507a5>] dump_stack+0x67/0x92\n [<ffffffff810dc6fa>] print_circular_bug+0x1aa/0x200\n [<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260\n [<ffffffff810df611>] lock_acquire+0xb1/0x200\n [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120\n [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120\n [<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0\n [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120\n [<ffffffff810fa85f>] ? rcu_read_lock_sched_held+0x7f/0x90\n [<ffffffff81208218>] ? kmem_cache_alloc_trace+0x248/0x2b0\n [<ffffffff815afdc5>] ? drm_modeset_lock_all+0x25/0x120\n [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120\n [<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80\n [<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50\n [<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]\n [<ffffffff814c13c6>] fbcon_init+0x586/0x610\n [<ffffffff8154d16a>] visual_init+0xca/0x130\n [<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0\n [<ffffffff8154eaf6>] do_take_over_console+0x116/0x180\n [<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0\n [<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750\n [<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0\n [<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70\n [<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20\n [<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20\n [<ffffffff814c86b1>] register_framebuffer+0x251/0x330\n [<ffffffff815b7e8d>] ? vga_switcheroo_client_fb_set+0x5d/0x70\n [<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0\n [<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]\n [<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150\n [<ffffffff810a3947>] process_one_work+0x1e7/0x750\n [<ffffffff810a38c9>] ? process_one_work+0x169/0x750\n [<ffffffff810a3efb>] worker_thread+0x4b/0x4f0\n [<ffffffff810a3eb0>] ? process_one_work+0x750/0x750\n [<ffffffff810aad4f>] kthread+0xef/0x110\n [<ffffffff819a85ef>] ret_from_fork+0x1f/0x40\n [<ffffffff810aac60>] ? kthread_stop+0x2e0/0x2e0\n\nv2: Rebase onto the right branch (hand-editing patches ftw) and add more\nreporters.\n\nReported-by: Imre Deak <imre.deak@intel.com>\nCc: Imre Deak <imre.deak@intel.com>\nCc: Chris Wilson <chris@chris-wilson.co.uk>\nAcked-by: Chris Wilson <chris@chris-wilson.co.uk>\nReported-by: Jiri Kosina <jikos@kernel.org>\nCc: Jiri Kosina <jikos@kernel.org>\nSigned-off-by: Daniel Vetter <daniel.vetter@intel.com>\nSigned-off-by: Dave Airlie <airlied@redhat.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/5c6c201ccbaf9d3901f829441d457293f7ca8ef4"},{"sha":"e8285cec4e6d6500d1ac25ec81ced56deffdb1fb","author":{"name":"Dave Airlie","email":"bb4fc8ee23048f808a4e317631d81d4f55a4e4cb@redhat.com"},"message":"Merge tag 'drm-intel-next-fixes-2016-08-05' of git://anongit.freedesktop.org/drm-intel into drm-next\n\n3 intel fixes.\n\n* tag 'drm-intel-next-fixes-2016-08-05' of git://anongit.freedesktop.org/drm-intel:\n  drm/i915/fbdev: Check for the framebuffer before use\n  drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB\n  drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/e8285cec4e6d6500d1ac25ec81ced56deffdb1fb"},{"sha":"4872850a19bffe486d79cccde6b0a433a2f03d1f","author":{"name":"Dave Airlie","email":"bb4fc8ee23048f808a4e317631d81d4f55a4e4cb@redhat.com"},"message":"Merge branch 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux into drm-next\n\nA few fixes for amdgpu and ttm for 4.8\n- fix a ttm regression caused by the new pipelining code\n- fixes for mullins on amdgpu\n- updated golden settings for amdgpu\n\n* 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux:\n  drm/ttm: Wait for a BO to become idle before unbinding it from GTT\n  drm/amdgpu: update golden setting of polaris10\n  drm/amdgpu: update golden setting of stoney\n  drm/amdgpu: update golden setting of polaris11\n  drm/amdgpu: update golden setting of carrizo\n  drm/amdgpu: update golden setting of iceland\n  drm/amd/amdgpu: change pptable output format from ASCII to binary\n  drm/amdgpu/ci: add mullins to default case for smc ucode\n  drm/amdgpu/gmc7: add missing mullins case","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/4872850a19bffe486d79cccde6b0a433a2f03d1f"},{"sha":"65a97a67a7d7b7a953492573d5740d32510b9daa","author":{"name":"Pali Rohár","email":"35dd7115003ef55531a0c6a60341622d38a388f1@gmail.com"},"message":"dell-wmi: Ignore WMI event 0xe00e\n\nWMI event 0xe00e is received when battery was removed or inserted.\n\nSigned-off-by: Pali Rohár <pali.rohar@gmail.com>\nSigned-off-by: Darren Hart <dvhart@linux.intel.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/65a97a67a7d7b7a953492573d5740d32510b9daa"},{"sha":"e10aec652f31ec61d6a0b4d00d8ef8d2b66fa0fd","author":{"name":"Mario Kleiner","email":"495ab40d8fe74e37e68dfcbd2e249c1f738eb4cf@gmail.com"},"message":"drm/edid: Add 6 bpc quirk for display AEO model 0.\n\nBugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331\nreports that the \"AEO model 0\" display is driven with 8 bpc\nwithout dithering by default, which looks bad because that\npanel is apparently a 6 bpc DP panel with faulty EDID.\n\nA fix for this was made by commit 013dd9e03872\n(\"drm/i915/dp: fall back to 18 bpp when sink capability is unknown\").\n\nThat commit triggers new regressions in precision for DP->DVI and\nDP->VGA displays. A patch is out to revert that commit, but it will\nrevert video output for the AEO model 0 panel to 8 bpc without\ndithering.\n\nThe EDID 1.3 of that panel, as decoded from the xrandr output\nattached to that bugzilla bug report, is somewhat faulty, and beyond\nother problems also sets the \"DFP 1.x compliant TMDS\" bit, which\naccording to DFP spec means to drive the panel with 8 bpc and\nno dithering in absence of other colorimetry information.\n\nTry to make the original bug reporter happy despite the\nfaulty EDID by adding a quirk to mark that panel as 6 bpc,\nso 6 bpc output with dithering creates a nice picture.\n\nTested by injecting the edid from the fdo bug into a DP connector\nvia drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering\nis selected.\n\nThis patch should be backported to stable.\n\nSigned-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>\nCc: stable@vger.kernel.org\nCc: Jani Nikula <jani.nikula@intel.com>\nCc: Ville Syrjälä <ville.syrjala@linux.intel.com>\nCc: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Dave Airlie <airlied@redhat.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/e10aec652f31ec61d6a0b4d00d8ef8d2b66fa0fd"},{"sha":"196f954e250943df414efd3d632254c29be38e59","author":{"name":"Mario Kleiner","email":"495ab40d8fe74e37e68dfcbd2e249c1f738eb4cf@gmail.com"},"message":"drm/i915/dp: Revert \"drm/i915/dp: fall back to 18 bpp when sink capability is unknown\"\n\nThis reverts commit 013dd9e03872\n(\"drm/i915/dp: fall back to 18 bpp when sink capability is unknown\")\n\nThis commit introduced a regression into stable kernels,\nas it reduces output color depth to 6 bpc for any video\nsink connected to a Displayport connector if that sink\ndoesn't report a specific color depth via EDID, or if\nour EDID parser doesn't actually recognize the proper\nbpc from EDID.\n\nAffected are active DisplayPort->VGA converters and\nactive DisplayPort->DVI converters. Both should be\nable to handle 8 bpc, but are degraded to 6 bpc with\nthis patch.\n\nThe reverted commit was meant to fix\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331\n\nA followup patch implements a fix for that specific bug,\nwhich is caused by a faulty EDID of the affected DP panel\nby adding a new EDID quirk for that panel.\n\nDP 18 bpp fallback handling and other improvements to\nDP sink bpc detection will be handled for future\nkernels in a separate series of patches.\n\nPlease backport to stable.\n\nSigned-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>\nAcked-by: Jani Nikula <jani.nikula@intel.com>\nCc: stable@vger.kernel.org\nCc: Ville Syrjälä <ville.syrjala@linux.intel.com>\nCc: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Dave Airlie <airlied@redhat.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/196f954e250943df414efd3d632254c29be38e59"},{"sha":"210a021dab639694600450c14b877bf3e3240adc","author":{"name":"Mario Kleiner","email":"495ab40d8fe74e37e68dfcbd2e249c1f738eb4cf@gmail.com"},"message":"drm/edid: Set 8 bpc color depth for displays with \"DFP 1.x compliant TMDS\".\n\nAccording to E-EDID spec 1.3, table 3.9, a digital video sink with the\n\"DFP 1.x compliant TMDS\" bit set is \"signal compatible with VESA DFP 1.x\nTMDS CRGB, 1 pixel / clock, up to 8 bits / color MSB aligned\".\n\nFor such displays, the DFP spec 1.0, section 3.10 \"EDID support\" says:\n\n\"If the DFP monitor only supports EDID 1.X (1.1, 1.2, etc.)\n without extensions, the host will make the following assumptions:\n\n 1. 24-bit MSB-aligned RGB TFT\n 2. DE polarity is active high\n 3. H and V syncs are active high\n 4. Established CRT timings will be used\n 5. Dithering will not be enabled on the host\"\n\nSo if we don't know the bit depth of the display from additional\ncolorimetry info we should assume 8 bpc / 24 bpp by default.\n\nThis patch adds info->bpc = 8 assignement for that case.\n\nSigned-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>\nCc: Jani Nikula <jani.nikula@intel.com>\nCc: Ville Syrjälä <ville.syrjala@linux.intel.com>\nCc: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Dave Airlie <airlied@redhat.com>","distinct":false,"url":"https://api.github.com/repos/masahir0y/linux-yamada/commits/210a021dab639694600450c14b877bf3e3240adc"}]}
{"actor":{"display_login":"masahir0y"}}