Am Mi., 19. Dez. 2018 um 15:45 Uhr schrieb Lucas Stach :
>
> Keep the page at address 0 as faulting to catch any potential state
> setup issues early.
>
> Signed-off-by: Lucas Stach
I like this idea.. but I am unsure about Guido's GC7000 problem.
Reviewed-by: Christian Gmeiner
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=60879
--- Comment #174 from EmilyBrown ---
Thanks for coming with detailed bug which you faced while starting X server and
what happened after few minutes within screenshots for better reference to find
a solution for other users and experts of it.
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.1-wip
head: 8054c54a6169ca26157d2bed0b52f63d472dbd34
commit: 308176d6f625bc782a34ec316beaefcfa7ad75f3 [17/212] drm/amdgpu: Remove
kgd2kfd function pointers
reproduce:
# apt-get install sparse
git checkout
On Thu, Jan 31, 2019 at 11:04:31AM -0800, Gurchetan Singh wrote:
> On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann wrote:
> >
> > There is no need to wait for completion here.
> >
> > The host will process commands in submit order, so commands can
> > reference the new resource just fine even when
Hi Dave, Daniel,
More stuff for 5.1. Mostly bug fixes.
ttm:
- Replace ref/unref naming with get/put
amdgpu:
- Revert DC clang fix, causes a segfault with some compiler versions
- SR-IOV fix
- PCIE fix for vega20
- Misc DC fixes
The following changes since commit
https://bugs.freedesktop.org/show_bug.cgi?id=109524
Mickey changed:
What|Removed |Added
URL||http://www.onedollarwebhost
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 3f287cb6d4ae4689eb7c53e4c25f0fba3df16438
commit: 0a2fe4901d16d28bb8ad5f7032e9579f85e7e594 [891/897] Merge
remote-tracking branch 'drm/drm-next' into drm-tip
config: riscv-allmodconfig (attached as .config)
compiler:
Hi Dave, Daniel,
Sorry this is a bit late. I had Internet issues yesterday.
A few fixes for 5.0:
- Fix radeon crash on SI with VM passthrough
- Fencing fix for shared buffers
- Fix power hwmon reporting on APUs
- Powerplay fix for APUs
The following changes since commit
Reviewed-by: Deepak Rawat
On Thu, 2019-01-31 at 10:52 +0100, Thomas Hellstrom wrote:
> if vmw_execbuf_fence_commands() fails, The handle value will be
> uninitialized and a bogus fence handle might be copied to user-space.
>
> Fixes: 2724b2d54cda: ("drm/vmwgfx: Use new validation interface for
Reviewed-by: Deepak Rawat
On Thu, 2019-01-31 at 11:07 +0100, Thomas Hellstrom wrote:
> The function was unconditionally returning 0, and a caller would have
> to
> rely on the returned fence pointer being NULL to detect errors.
> However,
> the function vmw_execbuf_copy_fence_user() would expect
Atomic checks should never modify anything outside of the state that
they're passed in. Unfortunately this appears to be exactly what we're
doing in nv50_msto_atomic_check() where we update mstc->pbn every time
the function is called. This hasn't caused any bugs yet, but it needs to
be fixed in
This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.
This time around, we use a slightly different but much less complicated
approach for fixing said issues.
Cc: Daniel Vetter
Lyude Paul (4):
Since
commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
connectors harder")
We've been failing atomic checks if they try to enable new displays on
unregistered connectors. This is fine except for the one situation that
breaks atomic assumptions: suspend/resume. If a
In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call
drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we
never successfully allocated VCPI to it. This is contrary to what we do
in drm_dp_mst_allocate_vcpi(), where we only call
drm_dp_mst_get_port_malloc() on the
Since we now have an easy way of refcounting drm_dp_mst_port structs and
safely accessing their contents, there isn't any good reason to keep
validating ports here. It doesn't prevent us from performing modesets on
branch devices that have been removed either, and we already disallow
enabling new
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:160:9:
warning: #pragma pack (pop) encountered without matching #pragma pack (push)
[-Wpragmas]
#pragma pack(pop)
Many users of drm_gem_object embed a struct reservation_object into
their subclassed struct, so let's add one to struct drm_gem_object.
This will allow removing the reservation object from the subclasses
and removing the ->gem_prime_res_obj callback.
With the addition, add a
Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.
Cc: Eric Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
drivers/gpu/drm/vc4/vc4_bo.c| 15 +--
Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.
Cc: Eric Anholt
Cc: Daniel Vetter
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
drivers/gpu/drm/v3d/v3d_bo.c | 14 +-
Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.
We can't use the drm_gem_reservation_object_wait() helper for MSM
because (in theory) msm_gem_cpu_prep() will also do some cache
maintenance on the GEM object.
Cc: Rob Clark
Cc: David Airlie
This series implements the todo to add reservation_object to
drm_gem_object. I converted the easy drivers, but not Intel or AMD. The
series is build tested only.
Rob
Rob Herring (5):
drm: Add reservation_object to drm_gem_object
drm: etnaviv: Switch to use drm_gem_object reservation_object
Now that the base struct drm_gem_object has a reservation_object, use it
and remove the private BO one.
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: David Airlie
Cc: Daniel Vetter
Cc: etna...@lists.freedesktop.org
Signed-off-by: Rob Herring
---
Hi all,
In commit
a93587b31e34 ("drm/amd/display: Only get the connector state for VRR when
toggled")
Fixes tag
Fixes: 3cc22f281318 ("drm/amdgpu: Set FreeSync state using drm VRR
properties")
has these problem(s):
- Target SHA1 does not exist
Maybe instead:
FIxes: bb47de736661
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
https://bugs.freedesktop.org/show_bug.cgi?id=109526
Bug ID: 109526
Summary: [CARRIZO] amdgpu fails to resume from S3, atombios
stuck executing C554 (len 629, WS 0, PS 0)
Product: DRI
Version: unspecified
Hardware: Other
We are seeking nominations for candidates for election to the X.Org Foundation
Board of Directors. All X.Org Foundation members are eligible for election to
the board.
Nominations for the 2019 election are now open and will remain open until 23:59
UTC on 14 February 2019.
The Board consists
On Thu, Jan 31, 2019 at 10:03:12PM +0100, Sam Ravnborg wrote:
> Hi Sean.
>
> > Hey Sam,
> > Thanks for the patchset, this will make dmesg grepping easier! One comment,
> > and
> > you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?
> >
> > When I introduced DRM_DEV, it was to
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #7 from grak...@gmail.com ---
Can confirm that removing raven_dmcu.bin allows amdgpu to load. Note that
kernel 4.20 also requires iommu=pt kernel option.
--
You are receiving this mail because:
You are the assignee for the
Hi Sean.
> Hey Sam,
> Thanks for the patchset, this will make dmesg grepping easier! One comment,
> and
> you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?
>
> When I introduced DRM_DEV, it was to cover the case where there are multiple
> instances of the same driver (ie:
https://bugs.freedesktop.org/show_bug.cgi?id=109524
Bug ID: 109524
Summary: "Invalid glsl version in shading_language_version()"
when trying to run directX games using wine
Product: Mesa
Version: 18.2
Hardware: x86 (IA32)
On Thu, Jan 31, 2019 at 11:55:35AM -0800, Andrew Morton wrote:
> On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse wrote:
>
> > Andrew what is your plan for this ? I had a discussion with Peter Xu
> > and Andrea about change_pte() and kvm. Today the change_pte() kvm
> > optimization is
Thank you, Nathan. I applied your patch to amd-staging-drm-next.
Sorry for the late response. I'm catching up with my email backlog after
a vacation.
Regards,
Felix
On 2019-01-21 6:52 p.m., Nathan Chancellor wrote:
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:866:5:
On Thu, Jan 31, 2019 at 08:26:00PM +0100, Sam Ravnborg wrote:
> Hi Thierry et al.
>
> While reviewing a number of new panel drivers there was a
> certain pattern in the feedback:
> - the now deprecated drmP.h file was used
> - dev_err() and friends was used
>
> This patch-set address the above
On Thu, 31 Jan 2019 11:10:06 -0500 Jerome Glisse wrote:
> Andrew what is your plan for this ? I had a discussion with Peter Xu
> and Andrea about change_pte() and kvm. Today the change_pte() kvm
> optimization is effectively disabled because of invalidate_range
> calls. With a minimal couple
On Thu, Jan 31, 2019 at 07:02:15PM +, Jason Gunthorpe wrote:
> On Thu, Jan 31, 2019 at 09:13:55AM +0100, Christoph Hellwig wrote:
> > On Wed, Jan 30, 2019 at 03:52:13PM -0700, Logan Gunthorpe wrote:
> > > > *shrug* so what if the special GUP called a VMA op instead of
> > > > traversing the
Hi all.
On Thu, Jan 31, 2019 at 08:26:00PM +0100, Sam Ravnborg wrote:
> Hi Thierry et al.
>
> While reviewing a number of new panel drivers there was a
> certain pattern in the feedback:
> - the now deprecated drmP.h file was used
> - dev_err() and friends was used
>
> This patch-set address
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
.../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 22 ++
1 file changed, 14
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Stefan Mavrodiev
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 26 +-
1 file
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-simple.c | 19 ---
1 file changed, 12 insertions(+), 7
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 10 ++
1 file changed, 6 insertions(+), 4
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-lg-lg4573.c | 20 +++-
1 file changed, 11 insertions(+), 9
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-samsung-ld9040.c | 12 +--
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
Cc: Stefan Mavrodiev
---
drivers/gpu/drm/panel/panel-truly-nt35597.c | 2 +-
1 file changed, 1 insertion(+), 1
The num_supplies variable is not used, delete it.
Build tested.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 64 ++
1 file changed, 34
Hi Thierry et al.
While reviewing a number of new panel drivers there was a
certain pattern in the feedback:
- the now deprecated drmP.h file was used
- dev_err() and friends was used
This patch-set address the above items in the panel
drivers in drm/panel/
The hope is that new panel drivers
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 63 -
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 14 --
1 file changed, 8 insertions(+), 6
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-lvds.c | 38 ++
1 file changed, 22
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
Cc: Stefan Mavrodiev
---
drivers/gpu/drm/panel/panel-arm-versatile.c | 18 ++
1 file changed, 10
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 16 ++--
1 file changed, 10 insertions(+),
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 12 +++-
1 file changed, 7 insertions(+), 5
Introduce use of DRM_DEV* for logging.
This makes logging in the drm subsystem more consistent.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 93 +++
Use of drmP.h is discouraged and yet we see new panel
drivers utilising drmP.h.
Remove usage of drmP.h from current panel drivers to set a good
example for new drivers.
While touching list of include files sort them.
Build tested on arm/x86.
Signed-off-by: Sam Ravnborg
Cc: Linus Walleij
Cc:
On Mon, Jan 28, 2019 at 04:05:34PM -0800, Matthias Kaehlcke wrote:
> Hi,
>
> this series has gone through multiple rounds of review and there are
> no outstanding comments. It seems it should be ready to land, or is
> there anything left that needs to be addressed?
From the drm side, I think
On Tue, Jan 29, 2019 at 02:26:29PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Drivers shouldn't be using these values, add a TODO so someone removes
> them.
>
> Changes in v2:
> - Add drm_display_mode.vrefresh removal (Ville)
> - Add Sam's R-b and bonus points
> Changes in v3:
> - Add hsync
On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann wrote:
>
> There is no need to wait for completion here.
>
> The host will process commands in submit order, so commands can
> reference the new resource just fine even when queued up before
> completion.
Does virtio_gpu_execbuffer_ioctl also wait
https://bugzilla.kernel.org/show_bug.cgi?id=202449
Haxk20 (haxk...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=108487
--- Comment #14 from magiblot ---
Created attachment 143267
--> https://bugs.freedesktop.org/attachment.cgi?id=143267=edit
Stderr output of weston when run on i915 (with patch from comment #13)
(In reply to Daniel Stone from comment #13)
On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote:
> On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, they can now return error values if
> > something went wrong. If that happens, return a NULL as a *dentry to
> > the relay core
On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, they can now return error values if
> something went wrong. If that happens, return a NULL as a *dentry to
> the relay core instead of passing it an illegal pointer.
>
> The relay core should be
Hi DRM maintainers,
This pull includes the new Arm "komeda" DRM driver. It is currently hosted
in the same repo as the other "mali-dp" driver because it is the next
iteration of the IP.
Please note that due to changes in the DRM framework, after merging the
tree you will need to apply the
Hi Neil,
On Thu, Jan 31, 2019 at 02:25:30PM +0100, Neil Armstrong wrote:
> On 15/01/2019 13:33, Neil Armstrong wrote:
> > This patchset aims to add support for the following HDMI2.0 4k60 modes:
> > - 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for
> > RGB/YUV4:4:4
> > - 297MHz
On 2019-01-29 5:00 p.m., Mamta Shukla wrote:
> Replace memset(vaddr_out + src_offset + 24, 0, 8) with
> memset(vaddr_out + src_offset + 3, 0, 1) because memset fills
> memory in bytes and not in bits.
>
> Signed-off-by: Mamta Shukla
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> No
Andrew what is your plan for this ? I had a discussion with Peter Xu
and Andrea about change_pte() and kvm. Today the change_pte() kvm
optimization is effectively disabled because of invalidate_range
calls. With a minimal couple lines patch on top of this patchset
we can bring back the kvm
https://bugs.freedesktop.org/show_bug.cgi?id=109403
--- Comment #3 from Andrey Grodzovsky ---
Hey, can you check if adding amdgpu.vm_debug=1 makes the VMC page faults
disappear ?
Regarding the hang you see while doing GPU reset - please provide dmesg for
this but with command line parameter
On 31/01/2019 14:29, Neil Armstrong wrote:
> Add the bindings for the Bifrost family of ARM Mali GPUs.
>
> The Bifrost GPU architecture is similar to the Midgard family,
> but with a different Shader Core & Execution Engine structures.
>
> Bindings are based on the Midgard family bindings, but
On 31/01/2019 15:13, Andrzej Hajda wrote:
> On 31.01.2019 14:25, Neil Armstrong wrote:
>> Hi Andrzej, Laurent,
>>
>> On 15/01/2019 13:33, Neil Armstrong wrote:
>>> This patchset aims to add support for the following HDMI2.0 4k60 modes:
>>> - 594Mhz TMDS frequency needing TMDS Scramling and 1/40
On Thu, Jan 31, 2019 at 09:13:55AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 03:52:13PM -0700, Logan Gunthorpe wrote:
> > > *shrug* so what if the special GUP called a VMA op instead of
> > > traversing the VMA PTEs today? Why does it really matter? It could
> > > easily change to
On Thu, Jan 31, 2019 at 09:05:01AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 08:44:20PM +, Jason Gunthorpe wrote:
> > Not really, for MRs most drivers care about DMA addresses only. The
> > only reason struct page ever gets involved is because it is part of
> > the GUP, SGL and
On Thu, Jan 31, 2019 at 09:02:03AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 01:50:27PM -0500, Jerome Glisse wrote:
> > I do not see how VMA changes are any different than using struct page
> > in respect to userspace exposure. Those vma callback do not need to be
> > set by
Component framework is extended to support multiple components for
a struct device. These will be matched with different masters based on
its sub component value.
We are introducing this, as I915 needs two different components
with different subcomponent value, which will be matched to two
Someone owes me a beer ...
While typing these I think doing an s/component_master/aggregate/
would be useful:
- it's shorter :-)
- I think component/aggregate is much more meaningful naming than
component/puppetmaster or something like that. At least to my
English ear "aggregate" emphasizes
On 31.01.2019 14:25, Neil Armstrong wrote:
> Hi Andrzej, Laurent,
>
> On 15/01/2019 13:33, Neil Armstrong wrote:
>> This patchset aims to add support for the following HDMI2.0 4k60 modes:
>> - 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for RGB/YUV4:4:4
>> - 297MHz TMDS frequency
On 1/31/2019 1:26 PM, Daniel Vetter wrote:
On Thu, Jan 31, 2019 at 12:29:23PM +0530, Ramalingam C wrote:
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.
On
On 1/31/2019 1:47 PM, Daniel Vetter wrote:
On Thu, Jan 31, 2019 at 12:29:22PM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
Op 29-01-2019 om 15:22 schreef Hans de Goede:
> We really want to have fastboot enabled by default to avoid an ugly
> modeset during boot.
>
> Currently we are enabling fastboot by default on gen9+ (Skylake and newer).
> The intention is to enable it on older generations after it has seen more
>
Add the bindings for the Bifrost family of ARM Mali GPUs.
The Bifrost GPU architecture is similar to the Midgard family,
but with a different Shader Core & Execution Engine structures.
Bindings are based on the Midgard family bindings, but the inner
architectural changes makes it a separate
When initializing clocks, a reference to the TCON channel 0 clock is
obtained. However, the clock is never prepared and enabled later.
Switching from simplefb to DRM actually disables the clock (that was
usually configured by U-Boot) because of that.
On the V3s, this results in a hang when
Hi Andrzej, Laurent,
On 15/01/2019 13:33, Neil Armstrong wrote:
> This patchset aims to add support for the following HDMI2.0 4k60 modes:
> - 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for RGB/YUV4:4:4
> - 297MHz TMDS frequency with YUV4:2:0 encoding
>
> The first mode uses the
On Thu, 31 Jan 2019 13:13:22 +
Peter Rosin wrote:
> On 2019-01-27 09:27, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 15:10:28 +
> > Peter Rosin wrote:
> >
> >> Hi!
> >>
> >> I found an unfortunate issue while recoding plane handling to use
> >>
When calling debugfs functions, they can now return error values if
something went wrong. If that happens, return a NULL as a *dentry to
the relay core instead of passing it an illegal pointer.
The relay core should be able to handle an illegal pointer, but add this
check to be safe.
Cc: Jani
On Thu, Jan 31, 2019 at 09:08:04AM +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 12:29:34PM +0530, Ramalingam C wrote:
> > Implements the
> > Waitqueue is created to wait for CP_IRQ
> > Signaling the CP_IRQ arrival through atomic variable.
> > For applicable DP HDCP2.2 msgs
Hi,
First of all, thanks for your patch :)
I tested your patch against the tests that you implemented in the IGT
[1]. All the alpha tests passed, but there was a weird warning that
says:
$ sudo IGT_FORCE_DRIVER=vkms ./tests/kms_cursor_crc --run-subtest
cursor-alpha-opaque
IGT-Version:
Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder:
> On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner wrote:
> >
> > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder:
> > > Previouly drivers have their own way of mapping range of
> > > kernel pages/memory
On Wed, Jan 30, 2019 at 06:11:16PM -0800, Matt Roper wrote:
> On Wed, Jan 30, 2019 at 11:01:25PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> > > Some display controllers can be programmed to present non-black colors
> > > for pixels not covered by
Hi,
On 30/01/2019 13:03, Damian Kos wrote:
> Hello!
>
> This is the series of patches that will add support for the Cadence's DPI/DP
> bridge. Please note that this is a preliminary version of the driver and there
> will be more patches in the future with updates, fixes and improvements.
>
Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be
Am Donnerstag, 31. Januar 2019, 04:10:40 CET schrieb Souptick Joarder:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
hmm, I'm missing a changelog here between v1 and v2.
Nevertheless I managed to test v1 on Rockchip hardware
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #46 from Przemek ---
(In reply to Pontus Gråskæg from comment #43)
> (In reply to Przemek from comment #42)
> > Good news,
> > on amd-staging-drm-next (5.0.0-rc1+) vga connector works without a hitch. I
> > don't have dvi connector
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Specifically call virtio_gpu_object_create() before ttm_bo_init(), so
> the object is already created when ttm calls the
> virtio_gpu_ttm_tt_bind() callback (which in turn calls
> virtio_gpu_object_attach()).
>
> With that in place
On Wed, Jan 30, 2019 at 06:18:44PM +, Russell King - ARM Linux admin wrote:
> On Wed, Jan 30, 2019 at 03:53:04PM +, Brian Starkey wrote:
> > Hi Russell,
> >
> > On Fri, Jan 25, 2019 at 09:43:29AM +, Russell King wrote:
> > >
> > > - /* set color matrix bypass flag: */
> > > -
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> There is no need to wait for completion here.
>
> The host will process commands in submit order, so commands can
> reference the new resource just fine even when queued up before
> completion.
>
> On the guest side there is no need to wait for
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Add 3d resource parameters to virtio_gpu_object_params struct. With
> that in place we can use it for virtio_gpu_cmd_resource_create_3d()
> calls.
>
> Signed-off-by: Gerd Hoffmann
> ---
You don't remove the struct virtio_gpu_resource_create_3d
https://bugs.freedesktop.org/show_bug.cgi?id=107990
--- Comment #10 from John ---
Hey Timothy,
is this something fairly easy to get into for someone with no knowledge of
OpenGL or Mesa (I've had a patch 5 years ago, so pretty much the same as no
knowledge)? If so, unless John wants to do it, I
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Create virtio_gpu_object_params, use that to pass object parameters to
> virtio_gpu_object_create. This is just the first step, followup patches
> will add more parameters to the struct. The plan is to use the struct
> for all object parameters.
>
Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> Add format, width and height fields to the virtio_gpu_object_params
> struct. With that in place we can use the parameter struct for
> virtio_gpu_cmd_create_resource() calls too.
>
> Signed-off-by: Gerd Hoffmann
> ---
Acked-by: Noralf Trønnes
1 - 100 of 161 matches
Mail list logo
