> I started by splitting Alexei's SKL PCI ID fix into
> logical chunks, and then ocd kicked in a bit...
Thank you for picking it up. Please do not forget
https://lists.freedesktop.org/archives/intel-gfx/2020-April/237944.html
Alexei
>
> Cc: Alexei Podtelezhnikov
>
>
: Alexei Podtelezhnikov
---
include/drm/i915_pciids.h | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 1d2c1221..ec6c6ff0 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -344,36
Reclassify 0x0426 as GT3 (GT2+) according to specifications and the second
least significant digit.
Signed-off-by: Alexei Podtelezhnikov
---
include/drm/i915_pciids.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index
Hi all,
What follows are small changes to Haswell and Skylake lists. Some of
the changes are purely semantic because some devices are not even
tracked in the current Windows driver. Do they even exist? Perhaps, at
some point the discontinued lines can be cleaned. I also learned that,
from Haswell
On Wed, Apr 29, 2020 at 7:41 AM Alexei Podtelezhnikov
wrote:
>
> Add three new devices 0x1913, 0x1915, and 0x1917 also known as
> iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. Reclassify 0x1923, 0x1927,
> and 0x192A according to specifications. Of note, the second to last
> digit seem
On Wed, 29 Apr 2020, Ville Syrjälä wrote:
> On Tue, Apr 28, 2020 at 11:27:50PM -0400, Alexei Podtelezhnikov wrote:
>> Add three new devices 0x1513, 0x1515, and 0x1517 also known as
>
> typo 0x15 vs. 0x19
>
>> iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. Reclassify 0x192
Add three new devices 0x1913, 0x1915, and 0x1917 also known as
iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. Reclassify 0x1923, 0x1927,
and 0x192A according to specifications. Of note, the second to last
digit seems to correspond to GT#.
Signed-off-by: Alexei Podtelezhnikov
---
include/drm
Add three new devices 0x1513, 0x1515, and 0x1517 also known as
iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. Reclassify 0x1923, 0x1927,
and 0x192A according to specifications.
Signed-off-by: Alexei Podtelezhnikov
---
include/drm/i915_pciids.h | 19 +++
1 file changed, 11
On Tue, Apr 28, 2020 at 7:43 AM Chris Wilson wrote:
>
> Give a small bump for our tolerance on comparing the expected vs
> measured clock ticks/time from 10% to 12.5% to accommodate a bad result
> on Sandybridge that was off by 10.3%. Hopefully, that is the worst we
> will see.
> -
> > These devices are also known as iSKLULTGT15 and iSKLDTGT15.
>
> We also seem to be missing 0x1915 from the ulx list.
Indeed, iSKLULXGT15 can be found.
> Another odd things I noticed in our SKL PCI ID lists is that
> that 0x1923 and 0x1927 are potentially miscategorized. They
> are listed as U
0x0155 is rather Ivy Bridge PCI-E Root Port.
0x0157 from the same commit ff049b6ce21d2814451afd4a116d001712e0116b
is likely wrong too. Nowhere is it independetly confirmed or mentioned.
Signed-off-by: Alexei Podtelezhnikov
---
include/drm/i915_pciids.h | 4 +---
1 file changed, 1 insertion
These devices are also known as iSKLULTGT15 and iSKLDTGT15.
Signed-off-by: Alexei Podtelezhnikov
---
include/drm/i915_pciids.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/i915_pciids.h b/src/i915_pciids.h
index 1d2c1221..a9c88eab 100644
--- a/include/drm
On Mon, Apr 27, 2020 at 10:45 AM Chris Wilson wrote:
>
> Quoting Alexei Podtelezhnikov (2020-04-27 15:40:42)
> > >
> > > These do not exist. They are fake PCI-ID for Windows95 multi monitor.
> > > The single device appears twice on the bus as a second function. We
>
> These do not exist. They are fake PCI-ID for Windows95 multi monitor.
> The single device appears twice on the bus as a second function. We
> never had that restriction and could do multiple monitors on the single
> device.
Windows 10 drivers list them, they do show up on lspci and I'll quote
In reverse order:
- Add SKL GT1.5
- Remove wrong and non-existant devices
- Add Gen3/Gen4 twin IGDs
- Amend historic records
Signed-off-by: Alexei Podtelezhnikov
---
src/i915_pciids.h | 72 +--
1 file changed, 49 insertions(+), 23 deletions
back to the CPU and so not allow ourselves to keep the dirty cache of
> the CPU bo.
>
> Signed-off-by: Chris Wilson
> Cc: Alexei Podtelezhnikov
The failed assertion is gone.
Tested-by: Alexei Podtelezhnikov
> ---
> src/sna/sna_accel.c | 12 ++--
> 1 file ch
From: Alexei Podtelezhnikov
Once a typo is fixed, the debug build triggers an assertion failure.
Given that the normal build is just fine, the assert might be wrong.
Signed-off-by: Alexei Podtelezhnikov
---
src/sna/compiler.h | 2 +-
src/sna/sna_accel.c | 2 +-
2 files changed, 2 insertions
>> Fix double-free crashes.
>> See https://bugzilla.redhat.com/show_bug.cgi?id=1808767
>
> It should be impossible to get here, so this is just papering over a
> bug.
You sound certain that locking is airtight and pthread.so just happened to be
there. The crashes are quite random but seem to
Fix double-free crashes.
See https://bugzilla.redhat.com/show_bug.cgi?id=1808767
Signed-off-by: Alexei Podtelezhnikov
---
src/sna/kgem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 6a35067c..76bb1599 100644
--- a/src/sna/kgem.c
+++ b/src/sna
Fix double-free crashes.
See https://bugzilla.redhat.com/show_bug.cgi?id=1808767
Signed-off-by: Alexei Podtelezhnikov
---
src/sna/kgem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/sna/kgem.c b/src/sna/kgem.c
index 6a35067c..9865a912 100644
--- a/src/sna/kgem.c
+++ b/src/sna
20 matches
Mail list logo
