On 2019/11/7 下午9:50, Michael S. Tsirkin wrote:
On Thu, Nov 07, 2019 at 09:32:29PM +0800, Jason Wang wrote:
On 2019/11/7 下午9:08, Michael S. Tsirkin wrote:
On Thu, Nov 07, 2019 at 08:43:29PM +0800, Jason Wang wrote:
On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
On Thu, Nov 07, 2019 at
https://bugs.freedesktop.org/show_bug.cgi?id=112226
Eero Tamminen changed:
What|Removed |Added
Summary|[HadesCanyon] GPU hangs |[HadesCanyon/regression]
From: Mikita Lipski
Patches are based of amd-staging-drm-next, the follow up
set of patches will be sent for drm-tip
This set of patches is a continuation of DSC enablement
patches for AMDGPU. This set enables DSC on MST. It also
contains implementation of both encoder and connector
atomic
From: Mikita Lipski
Adding PBN attribute to drm_dp_vcpi_allocation structure to
keep track of how much bandwidth each Port requires.
Adding drm_dp_mst_atomic_check_bw_limit to verify that
state's bandwidth needs doesn't exceed available bandwidth.
The funtion is called in drm_dp_mst_atomic_check
psbfb_probe performs an evaluation of the required size from the stolen
GTT memory, but gets it wrong in two distinct ways:
- The resulting size must be page-size-aligned;
- The size to allocate is derived from the surface dimensions, not the fb
dimensions.
When two connectors are connected
From: Mikita Lipski
Adding a helper function to be called by
drivers outside of DRM to enable DSC on
the MST ports.
Function is called to recalculate VCPI allocation
if DSC is enabled and raise the DSC flag to enable.
In case of disabling DSC the flag is set to false
and recalculation of VCPI
From: David Francis
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate
From: David Francis
This field on drm_dp_mst_branch was never filled
It is initialized to zero when the port is kzallocced.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.
v2: remember to decrement on port removal
v3: don't
From: David Francis
Rework the dm_helpers_write_dsc_enable callback to
handle the MST case.
Use the cached dsc_aux field.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19 ++-
1 file changed, 18 insertions(+), 1
From: Mikita Lipski
Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
support virtual DPCD registers, but do support DSC.
The DSC caps can be read from the physical aux,
like in SST DSC. These hubs have many different
DEVICE_IDs. Add a new quirk to detect this case.
Reviewed-by: Wenjing Liu
From: David Francis
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Reviewed-by: Nicholas Kazlauskas
From: David Francis
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for
From: David Francis
During MST mode enumeration, if a new dc_sink is created,
populate it with dsc caps as appropriate.
Use drm_dp_mst_dsc_aux_for_port to get the raw caps,
then parse them onto dc_sink with dc_dsc_parse_dsc_dpcd.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
On 2019-11-07 10:17 a.m., Ville Syrjala wrote:
> From: Ville Syrjälä
>
> This thing can get called several thousand times per LUT
> so seems like we want to inline it to:
> - avoid the function call overhead
> - allow constant folding
>
> A quick synthetic test (w/o any hardware interaction)
On Thu, Nov 07, 2019 at 11:11:03PM +0800, Jason Wang wrote:
> Hi all:
>
> There are hardwares that can do virtio datapath offloading while
> having its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is
On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
> > On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
> > > This sample driver creates mdev device that simulate virtio net device
> > > over virtio mdev transport. The device
On 2019/11/7 下午8:43, Jason Wang wrote:
On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
This sample driver creates mdev device
On Mon, 04 Nov 2019, Jani Nikula wrote:
> Hi all, I'd really appreciate some (non-Intel) acks or reviews on this
> series. Don't feel comfortable merging it otherwise. It should be fairly
> straightforward stuff as long as you have some DSI specs handy.
Thanks for the reviews. I've pushed the
Hi,
On Wed 06 Nov 19, 16:23, Patrik Jakobsson wrote:
> On Wed, Nov 6, 2019 at 10:44 AM Paul Kocialkowski
> wrote:
> >
> > This adds a missing call to drm_crtc_vblank_on to the common DPMS helper
> > (used by poulsbo and cedartrail), which is called in the CRTC enable path.
> >
> > With that
On Wed, Nov 06, 2019 at 07:35:36AM -0800, Devarsh Thakkar wrote:
> For the scenario where user may require to modeset with a mode
> supporting a fractional value for vertical refresh-rate,
> appropriate mode can be selected by searching for mode
> having matching fractional vertical refresh rate
On Thu, Nov 7, 2019 at 12:24 PM Ville Syrjälä
wrote:
>
> On Sun, Oct 20, 2019 at 08:21:32PM +0200, Hans de Goede wrote:
> > Fastboot is not working on an Asus T100HA, it gives the following
> > relevant messages / errors:
> >
> > dsi pll div 000201e6, ctrl 80080100
> > fastset mismatch in
Hi Thomas ; Thank you for reaching out.
See inline:
> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann wrote:
>
> Hi John,
>
> apparently the vgaarb was not the problem.
>
> Am 07.11.19 um 03:29 schrieb John Donnelly:
>> Hi,
>>
>> I am investigating an issue where we lose video activity
On Sun, Oct 20, 2019 at 08:21:32PM +0200, Hans de Goede wrote:
> Fastboot is not working on an Asus T100HA, it gives the following
> relevant messages / errors:
>
> dsi pll div 000201e6, ctrl 80080100
> fastset mismatch in dsi_pll.ctrl (expected 0x80100100, found 0x80080100)
> fastset mismatch
On Thu, Nov 07, 2019 at 08:43:29PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
> > On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
> > > On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
> > > > On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
>
On Thu, Nov 07, 2019 at 08:47:06PM +0800, Jason Wang wrote:
>
> On 2019/11/7 下午8:43, Jason Wang wrote:
> >
> > On 2019/11/7 下午7:21, Michael S. Tsirkin wrote:
> > > On Thu, Nov 07, 2019 at 06:18:45PM +0800, Jason Wang wrote:
> > > > On 2019/11/7 下午5:08, Michael S. Tsirkin wrote:
> > > > > On Wed,
Hi John
Am 07.11.19 um 14:12 schrieb John Donnelly:
> Hi Thomas ; Thank you for reaching out.
>
> See inline:
>
>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann wrote:
>>
>> Hi John,
>>
>> apparently the vgaarb was not the problem.
>>
>> Am 07.11.19 um 03:29 schrieb John Donnelly:
>>> Hi,
From: Ville Syrjälä
We have a few places where we want to reset a crtc state to its
default values. Let's add a helper for that. We'll need the new
__drm_atomic_helper_crtc_state_reset() helper for this to allow
us to just reset the state itself without clobbering the
crtc->state pointer.
And
From: Ville Syrjälä
We already have alloc/free helpers for planes, add the same for
crtcs. The main benefit is we get to move all the annoying state
initialization out of the main crtc_init() flow.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 74
From: Ville Syrjälä
For the sake of symmetry with the crtc stuff let's add
a helper to reset the plane state to sane default values.
For the moment this only gets caller from the plane init.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 15
From: Ville Syrjälä
Annoyingly __drm_atomic_helper_crtc_reset() does two
totally separate things:
a) reset the state to defaults values
b) assign the crtc->state pointer
I just want a) without the b) so let's split out part
a) into __drm_atomic_helper_crtc_state_reset(). And
of course we'll do
From: Ville Syrjälä
Let's get rid of the redundant intel_ prefix on our variables.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 32 ++--
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=112226
--- Comment #2 from Eero Tamminen ---
Created attachment 145908
--> https://bugs.freedesktop.org/attachment.cgi?id=145908=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
Mdev bus only supports vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
the first driver could be virtio-mdev. This means we need to add
device class id support in bus match method to pair the mdev device
and mdev driver correctly.
Add support to parse mdev class id table.
Reviewed-by: Parav Pandit
Reviewed-by: Cornelia Huck
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/vfio_mdev.c | 2 ++
scripts/mod/devicetable-offsets.c | 3 +++
scripts/mod/file2alias.c | 11 +++
3 files changed, 16
On Thu, Nov 07, 2019 at 03:31:28PM +, Kazlauskas, Nicholas wrote:
> On 2019-11-07 10:17 a.m., Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > This thing can get called several thousand times per LUT
> > so seems like we want to inline it to:
> > - avoid the function call overhead
> > -
Hi,
2019. 11. 07. 10:43 keltezéssel, Thomas Zimmermann írta:
Udl's GEM implementation is mostly SHMEM and we should attempt to
replace it with the latter.
Patches #1 and #2 update udl to simplify the conversion. In patch #3
the udl code is being replaced by SHMEM. The GEM object's mmap() and
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and
From: Mikita Lipski
Since for DSC MST connector's PBN is claculated differently
due to compression, we have to recalculate both PBN and
VCPI slots for that connector.
The function iterates through all the active streams to
find, which have DSC enabled, then recalculates PBN for
it and calls
From: David Francis
Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
register might have to be written on the leaf port's DPCD,
its parent's DPCD, or the MST manager's DPCD. This function
finds the correct aux for the job.
As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual
From: David Francis
If there is limited link bandwidth on a MST network,
it must be divided fairly between the streams on that network
Implement an algorithm to determine the correct DSC config
for each stream
The algorithm:
This
[ ] ( )
represents the range of
On Thu, 7 Nov 2019 23:11:09 +0800
Jason Wang wrote:
> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented through vringh
> and workqueue. A device specific dma ops is to make sure HVA is used
> directly as the IOVA. This
From: David Francis
Instead of having drm_dp_dpcd_read/write and
drm_dp_mst_dpcd_read/write as entry points into the
aux code, have drm_dp_dpcd_read/write handle both.
This means that DRM drivers can make MST DPCD read/writes.
v2: Fix spacing
v3: Dump dpcd access on MST read/writes
v4: Fix
From: Sean Paul
Hey all,
I'm back with another trace events patchset. My first attempt [1] went
better than expected, with enthusiasm for the idea and distain for the
implementation.
As promised, I went through and added proper trace events.
Before I get _too_ far, I wanted to post this set to
From: Sean Paul
Mirror some atomic debug messages which track a state through
allocation/clear/check/commit/free
Change-Id: I0387ddf4b2f1d84137a5b471e347878c04c6d0af
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic.c | 19 +---
drivers/gpu/drm/drm_trace.h | 84
From: Sean Paul
This patch is the first step in expanding trace events in drm. It
introduces a new enum used to classify trace events as well as a couple
helper macros to issue trace events from around drm.
It's a bit of a toy right now since we're just converting one class
(vblank) and there
From: Sean Paul
We can use an event class to remove some boilerplate for the event
queued/delivered trace events.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_trace.h | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git
From: Sean Paul
Add tracing which tracks important crtc_state events through the atomic
core.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic.c | 14 +
drivers/gpu/drm/drm_trace.h | 109 +++
2 files changed, 123 insertions(+)
diff --git
On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
>
> > >
> > > Extra credit: IMHO, this clearly deserves to all be in a new
> > > mmu_range_notifier.h
> > > header file, but I know that's extra work. Maybe later as
From: Sean Paul
Add tracing which tracks important plane_state events through the atomic
core.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic.c | 16 +++-
drivers/gpu/drm/drm_trace.h | 143 +++
2 files changed, 158 insertions(+), 1 deletion(-)
diff
From: Sean Paul
Add tracing which tracks important connector_state events through the atomic
core.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic.c | 12 -
drivers/gpu/drm/drm_trace.h | 101 +++
2 files changed, 112 insertions(+), 1 deletion(-)
Hi Fabrizio,
Thank you for the patch.
On Wed, Aug 28, 2019 at 07:36:37PM +0100, Fabrizio Castro wrote:
> Helper to provide bus timing information.
You may want to expand this a bit. And actually fix it too, as the
helper you introduce isn't related to timings (same for the subject
line).
>
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to haro41 from comment #4)
> Yes, your patch works and has the same effect, apparently.
>
> What confused me and the reason why i prefered to leave the
> vega10_update_avfs()
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:11:01PM +, Fabrizio Castro wrote:
> Add connector type for the etm0700g0dh6 from Emerging Display
> Technologies (EDT).
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v2->v3:
> * New patch
> ---
>
On 11/7/19 12:06 PM, Jason Gunthorpe wrote:
...
Also, it is best moved down to be next to the new MNR structs, so that all the
MNR stuff is in one group.
I agree with Jerome, this enum is part of the 'struct
mmu_notifier_range' (ie the description of the invalidation) and it
doesn't really
From: Bjorn Helgaas
Add definitions for these PCIe Link Control 2 register fields:
Enter Compliance
Transmit Margin
and use them in amdgpu and radeon.
NOTE: This is a functional change because "7 << 9" looks like it might be a
typo. That mask includes the high order bit of Transmit
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descript PCI_EXP_LNKCTL2
definitions. No functional change intended.
---
drivers/gpu/drm/amd/amdgpu/cik.c | 8
drivers/gpu/drm/amd/amdgpu/si.c | 8
drivers/gpu/drm/radeon/cik.c | 8
From: Bjorn Helgaas
amdgpu and radeon do a bit of mucking with the PCIe Link Control 2
register, some of it using hard-coded magic numbers. The idea here is to
replace those with #defines.
I haven't signed off on these because the first one actually changes the
bits involved because the
On Thu, Nov 07, 2019 at 05:49:14PM +, Brian Starkey wrote:
> Hi Daniel,
>
> On Thu, Nov 07, 2019 at 06:32:01PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=205393
--- Comment #6 from har...@gmx.de ---
(In reply to Alex Deucher from comment #5)
> (In reply to haro41 from comment #4)
> > Yes, your patch works and has the same effect, apparently.
> >
> > What confused me and the reason why i prefered to
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:10:59PM +, Fabrizio Castro wrote:
> In an effort to repurpose lvds-encoder.c to also serve the
> function of LVDS decoders, we ended up defining a new "generic"
> compatible string, therefore adapt the dt-bindings to fit the
>
> On Nov 7, 2019, at 10:13 AM, John Donnelly wrote:
>
>
>
>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote:
>>
>> Hi John
>>
>> Am 07.11.19 um 14:12 schrieb John Donnelly:
>>> Hi Thomas ; Thank you for reaching out.
>>>
>>> See inline:
>>>
On Nov 7, 2019, at 1:54 AM,
On Thu, Nov 7, 2019 at 5:21 PM Bjorn Helgaas wrote:
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 29d6e93fd15e..03446be8a7be 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -673,6 +673,8 @@
> #define
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> lvds-encoder.c implementation is also suitable for LVDS decoders,
> not just LVDS encoders.
> Instead of creating a new driver for addressing support for
> transparent LVDS decoders,
Hi Fabrizio,
(CC'ing Sam)
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:11:00PM +, Fabrizio Castro wrote:
> The existing DRM_MODE_CONNECTOR_ definitions don't seem to
> describe the connector for RGB/Parallel embedded displays,
> hence add DRM_MODE_CONNECTOR_PARALLEL.
Please, no. We
Hi Fabrizio,
On Thu, Nov 07, 2019 at 08:02:25PM +, Fabrizio Castro wrote:
> Hi Jacopo,
>
> Thank you for your feedback!
>
> > From: Jacopo Mondi
> > Sent: 07 November 2019 18:19
> > Subject: Re: [PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
> >
> > Hi Fabrizio,
> > thanks for the
On Thu, Nov 07, 2019 at 09:26:21PM +0200, Laurent Pinchart wrote:
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Wed, Aug 28, 2019 at 07:36:37PM +0100, Fabrizio Castro wrote:
> > Helper to provide bus timing information.
>
> You may want to expand this a bit. And actually fix it too, as the
Hi Fabrizio,
Thank you for the patch.
On Wed, Aug 28, 2019 at 07:36:38PM +0100, Fabrizio Castro wrote:
> The driver doesn't support dual-link LVDS displays, and the way
> it identifies bridges won't allow for dual-LVDS displays to be
> connected. Also, it's not possible to swap even and odd
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:10:57PM +, Fabrizio Castro wrote:
> Convert the lvds-transmitter binding to DT schema format using
> json-schema.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v2->v3:
> * Extracted conversion to dt-schema as per Rob's
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:11:02PM +, Fabrizio Castro wrote:
> The iwg20d comes with a 7" capacitive touch screen, therefore
> add support for it.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v2->v3:
> * No change
> v1->v2:
> * No change
> ---
>
Hi Fabrizio,
Thank you for the patch.
On Thu, Nov 07, 2019 at 08:11:03PM +, Fabrizio Castro wrote:
> The iwg20d comes with an LCD panel from Emerging Display
> Technologies Corporation (EDT), therefore enable what's
> required to support it.
>
> Signed-off-by: Fabrizio Castro
>
> ---
>
https://bugzilla.kernel.org/show_bug.cgi?id=205393
tempel.jul...@gmail.com changed:
What|Removed |Added
CC||tempel.jul...@gmail.com
---
19. 8. 1. 오전 1:58에 Andrzej Pietrasiewicz 이(가) 쓴 글:
> Switch to using the ddc provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Sam Ravnborg
> Reviewed-by: Emil Velikov
Acked-by: Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 270209307880ec946cfe9b98a6a58d285dbc5a2e
commit: f2157ab0fa53831e3575bfcbf0e92448c6943b9e [717/721] drm/sched: Use
completion to wait for sched->thread idle v2.
config: sh-allmodconfig (attached as .config)
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #39 from Shmerl ---
With kernel 5.4-rc6 I'm now seeing such errors once in 20 minutes or so:
[37947.927301] WARNING: CPU: 5 PID: 992 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:2806
From: Thomas Hellstrom
Similar to write-coherent resources, make sure that from the user-space
point of view, GPU rendered contents is automatically available for
reading by the CPU.
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
From: Thomas Hellstrom
Without the lock, anybody modifying a pte from within this function might
have it concurrently modified by someone else.
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Jérôme Glisse
Cc:
From: Thomas Hellstrom
With emulated coherent memory we need to be able to quickly look up
a resource from the MOB offset. Instead of traversing a linked list with
O(n) worst case, use an RBtree with O(log n) worst case complexity.
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc:
From: Thomas Hellstrom
Add the callbacks necessary to implement emulated coherent memory for
surfaces. Add a flag to the gb_surface_create ioctl to indicate that
surface memory should be coherent.
Also bump the drm minor version to signal the availability of coherent
surfaces.
Cc: Andrew Morton
From: Thomas Hellstrom
This infrastructure will, for coherent resources, make sure that
from the user-space point of view, data written by the CPU is immediately
automatically available to the GPU at resource validation time.
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter
From: Thomas Hellström
Graphics APIs like OpenGL 4.4 and Vulkan require the graphics driver
to provide coherent graphics memory, meaning that the GPU sees any
content written to the coherent memory on the next GPU operation that
touches that memory, and the CPU sees any content written by the
On Wed, Nov 06, 2019 at 03:05:42PM +0800, Jason Wang wrote:
> Hi all:
>
> There are hardwares that can do virtio datapath offloading while
> having its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is
On Thu, Nov 7, 2019 at 9:31 AM Daniel Vetter wrote:
>
> On Wed, Nov 06, 2019 at 04:24:59PM +0100, Patrik Jakobsson wrote:
> > On Wed, Nov 6, 2019 at 10:44 AM Paul Kocialkowski
> > wrote:
> > >
> > > Legacy (non-atomic) page flip support is added to the driver by using the
> > > mode_set_base
On Wed, Nov 06, 2019 at 09:35:31PM +0800, Jason Wang wrote:
> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented through vringh
> and workqueue. A device specific dma ops is to make sure HVA is used
> directly as the IOVA.
On Wed, Nov 06, 2019 at 09:35:25PM +0800, Jason Wang wrote:
> Hi all:
>
> There are hardwares that can do virtio datapath offloading while
> having its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is
On Thu, Nov 7, 2019 at 10:08 AM Patrik Jakobsson
wrote:
>
> On Thu, Nov 7, 2019 at 9:31 AM Daniel Vetter wrote:
> >
> > On Wed, Nov 06, 2019 at 04:24:59PM +0100, Patrik Jakobsson wrote:
> > > On Wed, Nov 6, 2019 at 10:44 AM Paul Kocialkowski
> > > wrote:
> > > >
> > > > Legacy (non-atomic) page
On Thu, Nov 07, 2019 at 09:34:03AM +0100, Thomas Zimmermann wrote:
> The cursor plane uses an internal format of ARGB. To userspace, we
> announce ARGB and do the transformation internally.
>
> v2:
> * don't set plane call-back functions to NULL explicitly
> * define plane
On Thu, Nov 07, 2019 at 09:34:01AM +0100, Thomas Zimmermann wrote:
> Like the original mode-setting code, the primary plane supports XRGB888,
> RGB565 and C8. The plane itself only pins BOs and sets the base address
> and scanline offset. The mode-setting code will be located in the CRTC's
>
Am 06.11.19 um 18:51 schrieb Andrey Grodzovsky:
> This reverts commit 3cdf9bd0089723c468d5f6240e54d1afa52e9a04.
>
> We will do a proper fix in next patch.
>
> Signed-off-by: Andrey Grodzovsky
The order of this one and patch #2 needs to be swapped, or otherwise we
have the bug in between those
On Tue, Nov 05, 2019 at 11:00:06AM -0800, John Hubbard wrote:
> On 11/5/19 5:10 AM, Mike Rapoport wrote:
> ...
> >> ---
> >> Documentation/vm/index.rst | 1 +
> >> Documentation/vm/pin_user_pages.rst | 212 ++
> >
> > I think it belongs to Documentation/core-api.
>
On Wed, Nov 06, 2019 at 02:24:30PM +, Chris Wilson wrote:
> As drm now exports a method to create an anonymous struct file around a
> drm_device for internal use, make use of it to avoid our horrible hacks.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/Kconfig.debug
Hi Dave, Daniel,
Here's this week PR for drm-misc-fixes.
Thanks!
Maxime
drm-misc-fixes-2019-11-07-1:
- Some new documentation for GEM shmem madvise helpers
- Fix for a state dereference in atomic self-refresh helpers
- One compilation fix for c2p fbdev helpers
The following changes since
On Wed, Nov 06, 2019 at 01:45:05PM +0100, Andrzej Pietrasiewicz wrote:
> Hi Daniel,
>
> Thank you for review,
>
> W dniu 05.11.2019 o 10:22, Daniel Vetter pisze:
> > On Mon, Nov 04, 2019 at 11:12:25PM +0100, Andrzej Pietrasiewicz wrote:
> > > These are useful for other users of afbc, e.g.
On Wed, Nov 06, 2019 at 02:24:29PM +, Chris Wilson wrote:
> Sometimes we need to create a struct file to wrap a drm_device, as it
> the user were to have opened /dev/dri/card0 but to do so anonymously
> (i.e. for internal use). Provide a utility method to create a struct
> file with the
On Wed, Nov 06, 2019 at 04:24:59PM +0100, Patrik Jakobsson wrote:
> On Wed, Nov 6, 2019 at 10:44 AM Paul Kocialkowski
> wrote:
> >
> > Legacy (non-atomic) page flip support is added to the driver by using the
> > mode_set_base CRTC function, that allows configuring a new framebuffer for
> >
In ast_set_ext_reg() sets several framebuffer options and CRT threshold
parameters. The former is mostly state of the primary plane; the latter
is constant. Hence, split the function in two and make it work with
atomic modesetting.
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
On Wed, Nov 06, 2019 at 10:50:23AM +0100, Wolfram Sang wrote:
> Move from the deprecated i2c_new_probed_device() to the new
> i2c_new_scanned_device(). Make use of the new ERRPTR if suitable.
>
> Signed-off-by: Wolfram Sang
Ack for merging through whatever tree you think this should best land
As the CRTC code has already been prepared for a split between mode
setting and plane handling, most of the CRTC's atomic modesetting is
build upon primitives of the non-atomic implementation.
Signed-off-by: Thomas Zimmermann
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/ast/ast_mode.c | 105
This commit sets the remaining atomic-modesetting helpers and the flag
DRIVER_ATOMIC. Legacy cursor functions are removed in favor of the cursor
plane. For power management, atomic helpers replace the indvidual
operations that the driver currently runs.
Atomic modesetting is enabled with this
The implementation of ast_set_vbios_mode() converts a DRM display mode
and framebuffer into an adjusted mode and stores information for the
video BIOS to several scratch regsiters.
Here we split the function into individual functions that do the
conversion, set the VBIOS mode information and
Like the original mode-setting code, the primary plane supports XRGB888,
RGB565 and C8. The plane itself only pins BOs and sets the base address
and scanline offset. The mode-setting code will be located in the CRTC's
atomic helpers.
v2:
* don't set plane call-back functions to NULL
101 - 200 of 217 matches
Mail list logo
