Hi Nicolas.
On Sat, Jan 25, 2020 at 01:02:56PM +0800, Nicolas Boichat wrote:
> The datasheet suggests 60 for tHFP, so let's adjust the number
> accordingly.
>
> This also makes the framerate be 60Hz as intended:
> 159916.0 * 1000 / ((1200 + 80 + 24 + 60)*(1920 + 20 + 4 + 10))
> => 60.00 Hz
>
> S
The datasheet suggests 60 for tHFP, so let's adjust the number
accordingly.
This also makes the framerate be 60Hz as intended:
159916.0 * 1000 / ((1200 + 80 + 24 + 60)*(1920 + 20 + 4 + 10))
=> 60.00 Hz
Signed-off-by: Nicolas Boichat
---
This also matches the values that we use in our chromeos-
https://bugzilla.kernel.org/show_bug.cgi?id=206299
Ilia Mirkin (imir...@alum.mit.edu) changed:
What|Removed |Added
CC||imir...@alum.mit.edu
https://bugzilla.kernel.org/show_bug.cgi?id=206299
Bug ID: 206299
Summary: [nouveau/xen] RTX 20XX instant reboot
Product: Drivers
Version: 2.5
Kernel Version: 5.4.X
Hardware: x86-64
OS: Linux
Tree: Mainline
Hi,
On Fri, Jan 24, 2020 at 4:07 AM Harigovindan P wrote:
>
> Add display, DSI hardware DT nodes for sc7180.
>
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v1:
> -Added display DT nodes for sc7180
> Changes in v2:
> -Renamed node names
> -Corrected code alignments
On Tue, 2020-01-07 at 14:11 +0100, Benjamin Gaignard wrote:
> Le ven. 20 déc. 2019 à 15:03, Benjamin Gaignard
> a écrit :
> > Le lun. 16 déc. 2019 à 09:28, Benjamin Gaignard
> > a écrit :
> > > Le mer. 4 déc. 2019 à 17:47, Jani Nikula a
> > > écrit :
> > > > On Thu, 28 Nov 2019, Benjamin Gaignar
On Fri, 2020-01-24 at 16:46 -0500, Lyude Paul wrote:
> On Fri, 2020-01-24 at 14:20 -0500, Mikita Lipski wrote:
> > On 1/24/20 2:10 PM, Lyude Paul wrote:
> > > Disabling a display on MST can potentially happen after the entire MST
> > > topology has been removed, which means that we can't communicat
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #44 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
On Fri, Jan 24, 2020 at 09:24:57PM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=206231
>
> --- Comment #43 from Alex Deucher
On Fri, Jan 24, 2020 at 09:24:57PM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=206231
>
> --- Comment #43 from Alex Deucher (alexdeuc...@gmail.com) ---
> The first time you run the game the shaders are not cached and you may see
> large compile
On Fri, 2020-01-24 at 14:20 -0500, Mikita Lipski wrote:
> On 1/24/20 2:10 PM, Lyude Paul wrote:
> > Disabling a display on MST can potentially happen after the entire MST
> > topology has been removed, which means that we can't communicate with
> > the topology at all in this scenario. Likewise, th
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #43 from Alex Deucher (alexdeuc...@gmail.com) ---
The first time you run the game the shaders are not cached and you may see
large compile times. The next time you run the game the shaders are cached and
you avoid the compiling delays
Hi Ville
On 2020-01-24 06:36, Ville Syrjälä wrote:
On Thu, Jan 23, 2020 at 02:40:45PM -0800, Abhinav Kumar wrote:
From: Uma Shankar
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.
Why?
[Abhinav] The display driver for MSM chipse
For largely legacy reasons, a global mutex (drm_global_mutex) is taken
around open/close of the drm_device, including serialising the filp
release. For drivers with their own fine grained locking, such global
coordination is a hindrance, albeit off the common hot paths.
References: 7a2c65dd32b1 ("
For largely legacy reasons, a global mutex (drm_global_mutex) is taken
around open/close of the drm_device, including serialising the filp
release. For drivers with their own fine grained locking, such global
coordination is a hindrance, albeit off the common hot paths.
References: 7a2c65dd32b1 ("
On 1/24/20 7:39 PM, Chris Wilson wrote:
Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47)
On 1/24/20 2:01 PM, Chris Wilson wrote:
Since drm_global_mutex is a true global mutex across devices, we don't
want to acquire it unless absolutely necessary. For maintaining the
device local open_co
From: Ville Syrjälä
I don't understand what the DispID CEA data block revision
means. The spec doesn't say. I guess some DispID must have
a value of >= 3 in there or else we generally wouldn't
even parse the CEA data blocks. Or does all this code
actually not do anything?
Cc: Andres Rodriguez
S
From: Ville Syrjälä
Let's introduce is_detailed_timing_descritor() as the opposite
counterpart of is_display_descriptor().
Cc: Allen Chen
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 42 ++
1 file changed, 24 insertions(+), 18 deletions(-)
From: Ville Syrjälä
Nuke some whitespace that shouldn't be there.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d6bce58b27ac..3df5744026b0 10064
From: Ville Syrjälä
CEA-861 says :
"d = offset for the byte following the reserved data block.
If no data is provided in the reserved data block, then d=4.
If no DTDs are provided, then d=0."
So let's not look for DTDs when d==0. In fact let's just make that
<4 since those values would just me
From: Ville Syrjälä
After much head scratching I managed to convince myself that
for_each_displayid_db() has already done the bounds checks for
the DispID CEA data block. Which is why we don't need to repeat
them in cea_db_offsets(). To avoid having to go through that
pain again in the future add
From: Ville Syrjälä
Let's try to make a lot more stuff const in the edid parser.
The "downside" is that we can no longer mangle the EDID in the
middle of the parsing to apply quirks (drm_mode_detailed()).
I don't really think mangling the blob itself is such a great
idea anyway so I won't miss t
From: Ville Syrjälä
Currently we assume any 18 byte descriptor to be a display descritor
if only the tag byte matches the expected value. But for detailed
timing descriptors that same byte is just the lower 8 bits of
hblank, and as such can match any display descriptor tag. To
properly validate t
From: Ville Syrjälä
I'm curious if there are any bogus 18 byte descriptors around.
Let's dump them out if we encounter them.
Not sure we'd actually want this, but at least I get to see
if our CI has anything that hits this :)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 22 ++
On 1/24/20 2:10 PM, Lyude Paul wrote:
Disabling a display on MST can potentially happen after the entire MST
topology has been removed, which means that we can't communicate with
the topology at all in this scenario. Likewise, this also means that we
can't properly update payloads on the topology
Disabling a display on MST can potentially happen after the entire MST
topology has been removed, which means that we can't communicate with
the topology at all in this scenario. Likewise, this also means that we
can't properly update payloads on the topology and as such, it's a good
idea to ignore
On Fri, 2020-01-24 at 11:39 -0500, Mikita Lipski wrote:
>
> On 1/24/20 9:55 AM, Harry Wentland wrote:
> > On 2020-01-23 7:06 p.m., Lyude Paul wrote:
> > > Disabling a display on MST can potentially happen after the entire MST
> > > topology has been removed, which means that we can't communicat
Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47)
> On 1/24/20 2:01 PM, Chris Wilson wrote:
> > Since drm_global_mutex is a true global mutex across devices, we don't
> > want to acquire it unless absolutely necessary. For maintaining the
> > device local open_count, we can use atomic operati
On Fri, Jan 24, 2020 at 05:50:11PM +0530, Akhil P Oommen wrote:
> Highest bank bit configuration is different for a618 gpu. Update
> it with the correct configuration which is the reset value incidentally.
>
> Signed-off-by: Akhil P Oommen
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm
Hi Andy.
On Fri, Jan 24, 2020 at 07:31:34PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 24, 2020 at 05:42:33PM +0100, Sam Ravnborg wrote:
> > On Wed, Jan 22, 2020 at 12:54:00PM +0200, Andy Shevchenko wrote:
> > > There is one OF call in the driver that limits its area of use.
> > > Replace it to g
The pull request you sent on Fri, 24 Jan 2020 16:03:04 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-01-24
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/274adbff45e3c26c65b2e103581d2ab5834b0b7c
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
Hi Andy.
On Wed, Jan 22, 2020 at 12:54:01PM +0200, Andy Shevchenko wrote:
> The spi_register_driver() will set the ->owner member to THIS_MODULE.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Sam Ravnborg
Any chance you will update the remaining 3 drivers in drm/tiny/
that has the same unes
Hi Andy.
On Wed, Jan 22, 2020 at 12:54:00PM +0200, Andy Shevchenko wrote:
> There is one OF call in the driver that limits its area of use.
> Replace it to generic device_get_match_data() and get rid of OF dependency.
>
> While here, cast SPI driver data to certain enumerator type.
>
> Signed-o
Sorry for the delay, change LGTM.
Reviewed-by: Leo Li
, and applied.
Thanks!
Leo
On 2020-01-24 5:18 a.m., Dor Askayo wrote:
> On Fri, Jan 17, 2020 at 12:59 PM Dor Askayo wrote:
>>
>> On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote:
>>>
>>> This allocation isn't required and can fail when re
On 1/24/20 9:55 AM, Harry Wentland wrote:
On 2020-01-23 7:06 p.m., Lyude Paul wrote:
Disabling a display on MST can potentially happen after the entire MST
topology has been removed, which means that we can't communicate with
the topology at all in this scenario. Likewise, this also means tha
On Fri, 24 Jan 2020 17:25:50 +0100
Sam Ravnborg wrote:
> On Thu, Jan 23, 2020 at 10:53:31AM +0100, Boris Brezillon wrote:
> > So that the previous bridge element in the chain knows which input
> > format the panel bridge expects.
> >
> > Signed-off-by: Boris Brezillon
>
> Subject: [PATCH v8
On Thu, Jan 23, 2020 at 10:53:31AM +0100, Boris Brezillon wrote:
> So that the previous bridge element in the chain knows which input
> format the panel bridge expects.
>
> Signed-off-by: Boris Brezillon
Subject: [PATCH v8 10/12] drm/bridge: panel: Propage bus format/flags
s/Propage/Propagate/
?
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #42 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
WOW: I did reproduce with dirt rally. I could not see it because the game must
not be restarted to "uncripple" the renderer. I used the number or rendered
frames
and I go from
WOW: I did reproduce with dirt rally. I could not see it because the game must
not be restarted to "uncripple" the renderer. I used the number or rendered
frames
and I go from an horrible 3000-5000 frames to a wooping 11000 frames, not to
mention
the game is now ~playable to max/ultra settings. I
On 23/01/2020 10:53, Boris Brezillon wrote:
> So that the previous bridge element in the chain knows which input
> format the panel bridge expects.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v7:
> * Set atomic state hooks explicitly
>
> Changes in v3:
> * Adjust things to match the ne
On 23/01/2020 10:53, Boris Brezillon wrote:
> This is needed to pass a bridge state to all atomic hooks, if we don't
> do that, the core can't duplicate/create bridge states.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v7:
> * New patch
> ---
> drivers/gpu/drm/bridge/analogix/analogix_
On 23/01/2020 10:53, Boris Brezillon wrote:
> One of the last remaining objects to not have its atomic state.
>
> This is being motivated by our attempt to support runtime bus-format
> negotiation between elements of the bridge chain.
> This patch just paves the road for such a feature by adding a
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #41 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) ---
The core version of Dead or Alive 5 is free :
https://store.steampowered.com/app/311730/DEAD_OR_ALIVE_5_Last_Round_Core_Fighters/
The game works well, but as I report
On Fri, Jan 24, 2020 at 5:50 AM Akhil P Oommen wrote:
>
> Highest bank bit configuration is different for a618 gpu. Update
> it with the correct configuration which is the reset value incidentally.
>
> Signed-off-by: Akhil P Oommen
> Signed-off-by: Sharat Masetty
Thanks, this fixes the UBWC iss
On 2020-01-23 7:06 p.m., Lyude Paul wrote:
> Disabling a display on MST can potentially happen after the entire MST
> topology has been removed, which means that we can't communicate with
> the topology at all in this scenario. Likewise, this also means that we
> can't properly update payloads on t
Yep. this looks like a real critical software and/or hardware bug. Like the one
you did show it the tomb raider vid.
If you could reproduce with a free game, that would be better for the amd devs.
I'll fool around a bit more with dirt rally (don't forget to restart the game
each time
you change
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #40 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
Yep. this looks like a real critical software and/or hardware bug. Like the one
you did show it the tomb raider vid.
If you could reproduce with a free game, that would be bet
On 2020-01-23 8:07 p.m., Lyude Paul wrote:
> These are some very loud debug statements that get printed on every
> vblank when driver level debug printing is enabled in DRM, and doesn't
> really tell us anything that isn't related to vblanks. So let's move
> this over to the proper debug flag to be
Hi Andrzej,
On 24/01/2020 16.27, Andrzej Hajda wrote:
>> +static void tc358768_write(struct tc358768_priv *priv, u32 reg, u32 val)
>> +{
>> +size_t count = 2;
>> +
>> +if (priv->error)
>> +return;
>> +
>> +/* 16-bit register? */
>> +if (reg < 0x100 || reg >= 0x600)
>> +
On Thu, Jan 23, 2020 at 02:40:45PM -0800, Abhinav Kumar wrote:
> From: Uma Shankar
>
> CEA 861.3 spec adds colorimetry data block for HDMI.
> Parsing the block to get the colorimetry data from
> panel.
Why?
>
> This was posted by Uma Shankar at
> https://patchwork.kernel.org/patch/10861327/
>
From: Christian König
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.
In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.
The patch
From: Christian König
That is not used any more.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 114 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 33 +++--
include/dr
Hi guys,
I've already send this out in September last year, but only got a response from
Daniel.
Could you guys please test this and tell me what you think about it?
Basically I'm trying to remove all driver specific features from TTM which
don't need to be inside the framework.
Thanks,
Chris
On 24.01.2020 11:55, Peter Ujfalusi wrote:
> Add basic support for the Toshiba TC358768 RGB to DSI bridge.
> Not all the features of the TC358768 is implemented by the initial driver:
> MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.
>
> Only write is implemented for mipi_
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #39 from Jacques Belosoukinski (kentos...@whiteninjastudio.com) ---
I did different tests and there is a real bug.
With Dirt Rally in ultra, if I use 8mxsaa, I have miserable performance. If I
set 0mxsaa in game, the performance is +
Quoting Thomas Hellström (VMware) (2020-01-24 13:37:47)
> On 1/24/20 2:01 PM, Chris Wilson wrote:
> > Since drm_global_mutex is a true global mutex across devices, we don't
> > want to acquire it unless absolutely necessary. For maintaining the
> > device local open_count, we can use atomic operati
On 1/24/20 2:01 PM, Chris Wilson wrote:
Since drm_global_mutex is a true global mutex across devices, we don't
want to acquire it unless absolutely necessary. For maintaining the
device local open_count, we can use atomic operations on the counter
itself, except when making the transition to/from
Since drm_global_mutex is a true global mutex across devices, we don't
want to acquire it unless absolutely necessary. For maintaining the
device local open_count, we can use atomic operations on the counter
itself, except when making the transition to/from 0. Here, we tackle the
easy portion of de
The file is not part of the global drm resource and can be released
prior to take the global mutex to drop the open_count (and potentially
close) the drm device. As the global mutex is indeed global, not only
within the device but across devices, a slow file release mechanism can
bottleneck the ent
Since drm_global_mutex is a true global mutex across devices, we don't
want to acquire it unless absolutely necessary. For maintaining the
device local open_count, we can use atomic operations on the counter
itself, except when making the transition to/from 0. Here, we tackle the
easy portion of de
On 1/23/20 11:21 PM, Chris Wilson wrote:
The file is not part of the global drm resource and can be released
prior to take the global mutex to drop the open_count (and potentially
close) the drm device. As the global mutex is indeed global, not only
within the device but across devices, a slow fi
On Fri, 20 Dec 2019, Rajat Jain wrote:
> Lookup and attach ACPI nodes for intel connectors. The lookup is done
> in compliance with ACPI Spec 6.3
> https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
> (Ref: Pages 1119 - 1123).
>
> This can be useful for any connector specific
Quoting Dan Carpenter (2020-01-24 10:31:23)
> On Fri, Jan 24, 2020 at 10:20:56AM +, Chris Wilson wrote:
> > Quoting Dan Carpenter (2020-01-24 10:13:12)
> > > This is always called with IRQs disabled and we don't actually want to
> > > enable IRQs at the end.
> > >
> > > Fixes: a6aa8fca4d79 ("d
On Fri, 20 Dec 2019, Rajat Jain wrote:
> Move the code that populates the ACPI device ID for devices, into
> more appripriate intel_acpi.c. This is done in preparation for more
> users of this code (in next patch).
Sorry for the delay, thanks for the patch, pushed to
drm-intel-next-queued.
BR,
J
Hi,
Changes since v1:
DT bindings document:
- Removed MaxItems for the regulators
- additionalProperties: false added to port@1
Driver:
- Year is now 2020
- Includes shorted
- The three letter members of the private struct documented 0 they are named as
in the datasheet
- Error handling for the
TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
Signed-off-by: Peter Ujfalusi
---
.../display/bridge/toshiba,tc358768.yaml | 158 ++
1 file changed, 158 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
diff --
Add basic support for the Toshiba TC358768 RGB to DSI bridge.
Not all the features of the TC358768 is implemented by the initial driver:
MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.
Only write is implemented for mipi_dsi_host_ops.transfer.
Signed-off-by: Peter Ujfalus
Dear Thomas,
Thank you for your patch,
For this stm part,
Acked-by: Philippe Cornu
Philippe :-)
On 1/23/20 2:59 PM, Thomas Zimmermann wrote:
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm
> over
Dear Thomas,
Thank you for your patch,
For this stm part,
Acked-by: Philippe Cornu
Philippe :-)
On 1/23/20 2:59 PM, Thomas Zimmermann wrote:
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert stm over.
>
> Signed-off-by: Thom
On Fri, Jan 24, 2020 at 10:20:56AM +, Chris Wilson wrote:
> Quoting Dan Carpenter (2020-01-24 10:13:12)
> > This is always called with IRQs disabled and we don't actually want to
> > enable IRQs at the end.
> >
> > Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known
>
Quoting Dan Carpenter (2020-01-24 10:13:12)
> This is always called with IRQs disabled and we don't actually want to
> enable IRQs at the end.
>
> Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known
> context")
> Signed-off-by: Dan Carpenter
> ---
> drivers/dma-buf/sync_
This is always called with IRQs disabled and we don't actually want to
enable IRQs at the end.
Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known
context")
Signed-off-by: Dan Carpenter
---
drivers/dma-buf/sync_debug.c | 5 +++--
1 file changed, 3 insertions(+), 2 deleti
From: Thomas Hellstrom
Using huge page-table entries requires that the physical address of the
start of a buffer object is huge page size aligned.
Make a special version of the TTM range manager that accomplishes this,
but falls back to a smaller page size alignment (PUD->PMD, PMD->NORMAL)
to avo
From: Thomas Hellstrom
The vma argument is only dereferenced for reading.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by:
From: Thomas Hellstrom
With vmwgfx dirty-tracking we need a specialized huge_fault
callback. Implement and hook it up.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
S
From: Thomas Hellstrom
For graphics drivers needing to modify the page-protection, add
huge page-table entries counterparts to vmf_insert_prn_prot().
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christ
From: Thomas Hellstrom
Support huge (PMD-size and PUD-size) page-table entries by providing a
huge_fault() callback.
We still support private mappings and write-notify by splitting the huge
page-table entries on write-access.
Note that for huge page-faults to occur, either the kernel needs to be
From: Thomas Hellstrom
Start using the helpers that align buffer object user-space addresses and
buffer object vram addresses to huge page boundaries.
This is to improve the chances of allowing huge page-table entries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kiri
From: Thomas Hellstrom
Unaligned virtual addresses makes it unlikely that huge page-table entries
can be used.
So align virtual buffer object address huge page boundaries to the
underlying physical address huge page boundaries taking buffer object
sizes into account to determine when it might be
From: Thomas Hellstrom
For VM_PFNMAP and VM_MIXEDMAP vmas that want to support transhuge pages
and -page table entries, introduce vma_is_special_huge() that takes the
same codepaths as vma_is_dax().
The use of "special" follows the definition in memory.c, vm_normal_page():
"Special" mappings do
From: Thomas Hellstrom
We currently only do COW and write-notify on the PTE level, so if the
huge_fault() handler returns VM_FAULT_FALLBACK on wp faults,
split the huge pages and page-table entries. Also do this for huge PUDs
if there is no huge_fault() handler and the vma is not anonymous, simil
In order to reduce TLB misses and CPU usage this patchset enables huge-
and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm code
take the same path as DAX when splitting huge- and giant page table entries,
(
Hi Russel,
On Wed, Jan 22, 2020 at 10:35:53AM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 22, 2020 at 11:30:34AM +0100, Guido Günther wrote:
> > Hi,
> > On Tue, Jan 21, 2020 at 08:05:27PM +0100, Arnd Bergmann wrote:
> > > On Tue, Jan 21, 2020 at 5:10 PM Lucas Stach
> > > wrote:
> >
This patch set implements the MSM_WAIT_IOVA ioctl which lets
userspace sleep until the value at a given iova reaches a certain
condition. This is needed in turnip to implement the
VK_QUERY_RESULT_WAIT_BIT flag for vkGetQueryPoolResults.
First, we add a GPU-wide wait queue that is signaled on all I
Add UBWC global configuration for display on
SC7180 target.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 58 +++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/ms
On Fri, Dec 13, 2019 at 01:56:02PM -0800, Niranjana Vishwanathapura wrote:
Shared Virtual Memory (SVM) allows the programmer to use a single virtual
address space which will be shared between threads executing on CPUs and GPUs.
It abstracts away from the user the location of the backing memory, a
On 1/23/20 11:49 AM, Sam Ravnborg wrote:
> Hi Randy.
>
> Thanks - I think (kidding, this has bugged of for a long time).
>
> On Thu, Jan 23, 2020 at 12:44:25AM -0800, Randy Dunlap wrote:
>> On 1/22/20 10:21 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20200122:
>>>
>>
>>
>> on i3
On Mon, Jan 20, 2020 at 10:02 AM Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
> Add bindings for the following 3 to be added display panels manufactured
> by Logic Technologies Limited:
>
> - LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display
> 7" Parallel [1]
> - LT161010-
Le 23/01/2020 à 19:02, Linus Torvalds a écrit :
On Thu, Jan 23, 2020 at 4:59 AM Christophe Leroy
wrote:
On 32 bits powerPC (book3s/32), only write accesses to user are
protected and there is no point spending time on unlocking for reads.
Honestly, I'm starting to think that 32-bit ppc just
Add display, DSI hardware DT nodes for sc7180.
Changes in v1:
-Added display DT nodes for sc7180
Changes in v2:
-Renamed node names
-Corrected code alignments
-Removed extra new line
Signed-off-by: Harigovindan P
---
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 57
Add display, DSI hardware DT nodes for sc7180.
Changes in v1:
-Added display DT nodes for sc7180
Changes in v2:
-Renamed node names
-Corrected code alignments
-Removed extra new line
-Added DISP AHB clock for register access
under display_subsystem n
On Mon, Jan 20, 2020 at 10:02 AM Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
> Add display timings for the following 3 display panels manufactured by
> Logic Technologies Limited:
>
> - LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display
> 7" Parallel [1]
> - LT161010-2NH
This wait queue is signaled on all IRQs for a given GPU and will be
used as part of the new MSM_WAIT_IOVA ioctl so userspace can sleep
until the value at a given iova reaches a certain condition.
Signed-off-by: Brian Ho
---
drivers/gpu/drm/msm/msm_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu.h |
On Thu 23 Jan 04:15 PST 2020, Harigovindan P wrote:
> Add display, DSI hardware DT nodes for sc7180.
>
> Changes in v1:
> -Added display DT nodes for sc7180
> Changes in v2:
> -Renamed node names
> -Corrected code alignments
> -Removed extra new line
Please keep the chang
Implements an ioctl to wait until a value at a given iova is greater
than or equal to a supplied value.
This will initially be used by turnip (open-source Vulkan driver for
QC in mesa) for occlusion queries where the userspace driver can
block on a query becoming available before continuing via
vk
On 32 bits powerPC (book3s/32), only write accesses to user are
protected and there is no point spending time on unlocking for reads.
On 64 bits powerpc (book3s/64 at least), access can be granted
read only, write only or read/write.
Add an argument to user_access_begin() to tell when it's for wr
From: Chris Wilson
> Sent: 15 January 2020 20:53
>
> Since we may try and flush the cachelines associated with large buffers
> (an 8K framebuffer is about 128MiB, even before we try HDR), this leads
> to unacceptably long latencies (when using a voluntary CONFIG_PREEMPT).
> If we call cond_resche
On Fri, 24 Jan 2020 10:25:05 +0200
Pekka Paalanen wrote:
> On Tue, 21 Jan 2020 08:51:26 -0600
> Matt Hoosier wrote:
>
> > On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen wrote:
> >
> > > On Fri, 17 Jan 2020 10:51:45 -0600
> > > Matt Hoosier wrote:
> > >
> > > > Hi all,
> > > >
> > > > I
On Tue, 21 Jan 2020 08:51:26 -0600
Matt Hoosier wrote:
> On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen wrote:
>
> > On Fri, 17 Jan 2020 10:51:45 -0600
> > Matt Hoosier wrote:
> >
> > > Hi all,
> > >
> > > I'm confronting a situation where the hardware with which I work is
> > capable
>
98 matches
Mail list logo
