According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
belongs to a CMP-V chipset. Based on the same docs the programming of
the PCH is compatible with that of KBP. Fix up my previous wrong
assumption accordingly using the SPT programming which in turn is the
basis for KBP.
The original bug reporter verified that this is the correct PCH
identification (the only way we'll program valid DDC pin-pair values to
the GMBUS register) and the Windows team uses the same identification
(that is using the KBP programming model for this PCH).
I filed the necessary Bspec update requests (BSpec/33734).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051
Fixes: 37c92dc303dd ("drm/i915: Add new CNL PCH ID seen on a CML platform")
Reported-and-tested-by: Cyrus <email address hidden>
Cc: Cyrus <email address hidden>
Cc: Timo Aaltonen <email address hidden>
Cc: José Roberto de Souza <email address hidden>
Signed-off-by: Imre Deak <email address hidden>
Reviewed-by: José Roberto de Souza <email address hidden>
(backported from https://patchwork.freedesktop.org/patch/340416)
Signed-off-by: You-Sheng Yang <email address hidden>
Atm we don't detect a PCH with PCI ID 0xA3C1 which showed up now on a CML
platform. We don't have the official assignment of the PCH PCI IDs, but
this looks like a CNP which was already used on CML platforms. Let's add
the new ID->PCH type mapping accordingly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051
Reported-and-tested-by: Cyrus <email address hidden>
Cc: Cyrus <email address hidden>
Signed-off-by: Imre Deak <email address hidden>
Reviewed-by: José Roberto de Souza <email address hidden>
Link: https://patchwork<email address hidden>
(backported from commit 37c92dc303dd0977134d1c8501f057de407473ec https://anongit.freedesktop.org/git/drm-tip.git)
Signed-off-by: You-Sheng Yang <email address hidden>
This commit simplifies how shiftfs open files, both regular files an
directories.
In the first iteration, we implemented a kmem cache for struct
shiftfs_file_info which stashed away a struct path and the struct file
for the underlay. The path however was never used anywhere so the struct
shiftfs_file_info and therefore the whole kmem cache can go away.
Instead we move to the same model as overlayfs and just stash away the
struct file for the underlay in file->private_data of the shiftfs struct
file.
Addtionally, we split the .open method for files and directories.
Similar to overlayfs .open for regular files uses open_with_fake_path()
which ensures that it doesn't contribute to the open file count (since
this would mean we'd count double). The .open method for directories
however used dentry_open() which contributes to the open file count.
The basic logic for opening files is unchanged. The main point is to
ensure that a reference to the underlay's dentry is kept through struct
path.
Various bits and pieces of this were cooked up in discussions Seth and I
had in Paris.
Signed-off-by: Christian Brauner <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
scale_up wakes up waiters after scaling up. But after scaling max, it
should not wake up more waiters as waiters will not have anything to
do. This patch fixes this by making scale_up (and also scale_down)
return when threshold is reached.
This bug causes increased fdatasync latency when fdatasync and dd
conv=sync are performed in parallel on 4.19 compared to 4.14. This
bug was introduced during refactoring of blk-wbt code.
Fixes: a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt")
Cc: <email address hidden>
Cc: Josef Bacik <email address hidden>
Signed-off-by: Harshad Shirwadkar <email address hidden>
Signed-off-by: Jens Axboe <email address hidden>
(cherry picked from commit b84477d3ebb96294f87dc3161e53fa8fe22d9bfd )
Signed-off-by: Khalid Elmously <email address hidden>
Acked-by: Connor Kuehl <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
On platfroms with gen10+ display, driver must set the enable bit of
AUDIO_PIN_BUF_CTL register before transactions with the HDA controller
can proceed. Add setting this bit to the audio power up sequence.
Failing to do this resulted in errors during display audio codec probe,
and failures during resume from suspend.
Note: We may also need to disable the bit afterwards, but there are
still unresolved issues with that.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111214
Signed-off-by: Kai Vehmanen <email address hidden>
Signed-off-by: Jani Nikula <email address hidden>
Link: https://patchwork<email address hidden>
(backported from commit 1580d3cdddbba4a5ef78a04a5289e32844e6af24
git://anongit.freedesktop.org/drm-intel)
Signed-off-by: Hui Wang <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
