On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec wrote:
> Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
>> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> wrote:
>> > This series adds support for R40 HDMI pipeline. It is a bit special
>> > than other already supported pi
Changes in current patchset:
- Use presence of refclk to determine if continuous dsi clock is required or
not.
- Update media/video-interface.txt documentatio for DSI and DP interface.
Sandeep Panda (5):
drm/bridge: add support for sn65dsi86 bridge driver
dt-bindings: drm/bridge: Document s
On 06/15/2018 09:46 AM, Juergen Gross wrote:
On 15/06/18 08:32, Oleksandr Andrushchenko wrote:
Please note, that this will need a change (attached) while
applying to the mainline kernel because of API changes [1].
Unfortunately, current Xen tip kernel tree is v4.17-rc5 based,
so I cannot make t
Please note, that this will need a change (attached) while
applying to the mainline kernel because of API changes [1].
Unfortunately, current Xen tip kernel tree is v4.17-rc5 based,
so I cannot make the change in this patch now.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
[...]
> >>+ /*
> >>+* wake_up_process() paired with set_current_state() inserts
> >>+* sufficient barriers to make sure @owner either sees it's
> >>+* wounded or has a wakeup pending to re-read the wounded
> >>+* state.
> >IIUC, "sufficient
Hi Jordan,
On Mon, Jun 11, 2018 at 11:56 PM, Jordan Crouse wrote:
> Now that the IOMMU is the master of it's own power we don't need to bring
> up the GPU to do IOMMU operations. This is good because bringing up a6xx
> requires the GMU so calling pm_runtime_get_sync() too early in the process
> g
Hi Thomas,
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
> The current Wound-Wait mutex algorithm is actually not Wound-Wait but
> Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait
> is, contrary to Wait-Die a preemptive algorithm and is known to generate
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c i
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
Reviewed-by: Sean Paul
---
drivers/gpu/drm/p
Properties like data-lanes, clock-noncontinuous and lane-polarities
are applicable to DSI and DisplayPort interface also. So update the
documentation to mention the same.
Signed-off-by: Sandeep Panda
---
Documentation/devicetree/bindings/media/video-interfaces.txt | 10 ++
1 file changed
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp pa
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
Reviewed-by: Sean Paul
---
drivers/gpu/drm/p
On 06/14/2018 02:47 AM, Oleksandr Andrushchenko wrote:
> Hi, Boris!
>
> It seems that I have resolved all the issues now which
> were mainly cleanup and code movement and 5 of 9 patches
> already have r-b's. Do you, as the primary reviewer of the
> series, think I can push (hopefully) the final ver
On Thu, Jun 14, 2018 at 01:09:01PM -0300, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro
@@ -548,6 +632,17 @@ static int gntdev_open(struct inode *inode, struct
file *flip)
}
flip->private_data = priv;
+#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
+ priv->dma_dev = gntdev_miscdev.this_device;
+
+ /*
+* The device is not spawn from a device tree, so arch_setup_
On 15/06/18 08:32, Oleksandr Andrushchenko wrote:
> Please note, that this will need a change (attached) while
> applying to the mainline kernel because of API changes [1].
>
> Unfortunately, current Xen tip kernel tree is v4.17-rc5 based,
> so I cannot make the change in this patch now.
I don't
Some adapters need to be prepared/unprepared before bitbanging the bus.
Do this for the initial STOP, too.
Signed-off-by: Wolfram Sang
---
Ok, another idea to fix the regression. I'm not 100% sure if the placement is
perfect, but it should serve well enough as a proof of concept to see if this
i
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c i
On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec wrote:
> This series adds support for R40 HDMI pipeline. It is a bit special
> than other already supported pipelines because it has additional unit
> called TCON TOP responsible for relationship configuration between
> mixers, TCONs and HDMI. Additi
Properties like data-lanes, clock-noncontinuous and lane-polarities
are applicable to DSI and DisplayPort interface also. So update the
documentation to mention the same.
Change-Id: I544bdf178bd6b207fa9e2e2e4aad819da320be3b
Signed-off-by: Sandeep Panda
---
Documentation/devicetree/bindings/media
Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
wrote:
> > This series adds support for R40 HDMI pipeline. It is a bit special
> > than other already supported pipelines because it has additional unit
> > called TCON TOP res
On Mon, Jun 4, 2018 at 10:47 AM, Souptick Joarder wrote:
> On Sun, May 27, 2018 at 6:15 AM, Souptick Joarder
> wrote:
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>
Dne četrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
> On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec
wrote:
> > Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> >
> > wrote:
> >> > This series adds
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as do
Changes in current patchset:
- Read DPPLL_SRC register to determine if continuous dsi clock needed or not.
- Reorder the patchsets.
Sandeep Panda (5):
dt-bindings: media: extend interface documentation for DSI and DP
drm/bridge: add support for sn65dsi86 bridge driver
dt-bindings: drm/brid
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c i
On Thu, Jun 14, 2018 at 01:54:15PM +0200, Thomas Hellstrom wrote:
> On 06/14/2018 01:36 PM, Peter Zijlstra wrote:
> > Currently you don't allow mixing WD and WW contexts (which is not
> > immediately obvious from the above code), and the above hard relies on
> > that. Are there sensible use cases f
Before we get too happy to merge things, I ran the CTS tests and there are
some failures... I've attached a fixup patch that fixes three bugs I found:
1) We weren't setting planeReorderPossible at all and we were using 0
instead of VK_FALSE (they're the same but we should use the enum) for
persi
https://bugs.freedesktop.org/show_bug.cgi?id=106879
--- Comment #1 from javcasalc ---
Hi,
no comments? did I miss any log/attachment?
Thanks.
J.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
co
From: Oleksandr Andrushchenko
This is in preparation for adding support of DMA buffer
functionality: make map/unmap related code and structures, used
privately by gntdev, ready for dma-buf extension, which will re-use
these. Rename corresponding structures as those become non-private
to gntdev no
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other dom
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only v
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also from buffers allocated with
dma_alloc_xxx.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrov
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
symbo
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in that proper memory reservation is made by
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 54 +-
From: Oleksandr Andrushchenko
Only gnttab_{alloc|free}_pages are exported as EXPORT_SYMBOL
while all the rest are exported as EXPORT_SYMBOL_GPL, thus
effectively making it not possible for non-GPL driver modules
to use grant table module. Export gnttab_{alloc|free}_pages as
EXPORT_SYMBOL_GPL so a
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed soluti
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #12 from cerg2010cerg2...@mail.ru ---
Teset this, but it did not help.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel
On 06/15/2018 06:22 AM, YoungJun Cho wrote:
Dear Dan,
Your mail flashes back to my memory 5 years ago.
Back then, I had cleaned up the exynos driver.
And the replacement IS_ERR was one of items.
IMHO it is still better to modify those two functions,
drm_gem_cma_prime_get_sg_table and xen_drm_
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.19-wip
head: 0198cd6030f1f4bddc2fceb47971bfcbaa616db5
commit: 30e85debc13f1b8aaac16906441ee66645db10ed [121/126] drm/amd/pp: Remove
SAMU support in powerplay
reproduce:
# apt-get install sparse
git checkout 30e85deb
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #11 from Wolfram Sang (w...@the-dreams.de) ---
I have sent another patch, let's hope it really is this issue:
http://patchwork.ozlabs.org/patch/929798/
--
You are receiving this mail because:
You are watching the assignee of the bug
Hi Linus,
Just a single set of AMD fixes for stuff in -next for -rc1.
Thanks,
Dave.
drm-next-2018-06-15:
amd fixes for 4.18-rc1
The following changes since commit 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5:
Merge tag 'drm-intel-next-fixes-2018-06-08-2' of
git://anongit.freedesktop.org/drm/drm-i
Currenty the VCO rate in the 10nm PLL driver relies
on the parent rate which is not configured.
Configure the VCO rate to 19.2 Mhz as required by
the 10nm PLL driver.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletio
Dear Dan,
Your mail flashes back to my memory 5 years ago.
Back then, I had cleaned up the exynos driver.
And the replacement IS_ERR was one of items.
IMHO it is still better to modify those two functions,
drm_gem_cma_prime_get_sg_table and xen_drm_front_gem_get_sg_table.
Thank you.
Best regard
Here's a couple of reasonably straightforward extensions implemented
for both anv and radv drivers.
VK_EXT_display_surface_counter is a very simple extension which
adds an API, vkGetPhysicalSurfaceCapabilities2EXT, to extend the
existing vkGetPhysicalDeviceSurfaceCapabilitiesKHR and
vkGetPhysicalD
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
v2: Adopt Jason Ekstrand's coding conventions
Declare variables at first use, eliminate extra whitespace be
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
v2:
Rework fence integration into the driver so that waiting for
any of a mixture of fence types (wsi, d
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
v2:
Add extension to list in alphabetical order
Suggested-by: Jason Ekstrand
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py | 1
Handle the case where the set of fences to wait for is not all of the
same type by either waiting for them sequentially (waitAll), or
polling them until the timer has expired (!waitAll). We hope the
latter case is not common.
While the current code makes sure that it always has fences of only
one
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
v2: Thanks to kisak
Fix spelling of VkSurfaceCapabilities2EXT in wsi_common_wayland.c,
it was using ext instead of EXT.
Fix spelling of VK_STRUCTURE_TYPE_SUR
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
v2: Remove DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT flag. This has
been removed from the proposed kernel API.
Add NULL
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi.c | 12
2 files changed, 13 insertions(+)
diff -
Jason Ekstrand writes:
> Looks good to me. With this properly sprinkled on the appropriate patches,
> the entire series is
>
> Reviewed-by: Jason Ekstrand
Thanks so much! I've rebased the series onto current master and pushed
it back to my gitlab repo here
https://gitlab.freedesktop.o
Looks good to me. With this properly sprinkled on the appropriate patches,
the entire series is
Reviewed-by: Jason Ekstrand
On Thu, Jun 14, 2018 at 5:57 PM, Keith Packard wrote:
> We sorted out what 'vscan' means and are trying to use it correctly.
>
> vscan = 0 is the same as vscan = 1, whic
We sorted out what 'vscan' means and are trying to use it correctly.
vscan = 0 is the same as vscan = 1, which is slightly annoying; we use
MAX2(vscan, 1) everywhere.
randr doesn't pass vscan at all, so we set wsi mode vscan = 0.
The doublescan flag doubles the vscan value, so we don't need to d
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #38 from Samuel Sieb (samuel-kb...@sieb.net) ---
https://bugzilla.redhat.com/show_bug.cgi?id=1558023
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dr
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #7 from Ricardo Ribalda ---
BTW: Are you aware of anyway that I can validate that a video is properly
encoded, besides playing it?
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #6 from Ricardo Ribalda ---
I tried this combinations with gstreamer:
sw encoding + sw decoding (libva): works
sw encoding + omx decoding: works
omx encoding + sw decoding (libva): works
omx encoding + omx decoding : fails
I ha
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #5 from Julien Isorce ---
Can you try gstreamer-vaapi ? to compare with another hw decoder. And with sw
decoders in gstreamer it works ? And other players ?
I am trying to determine if the issue is only in the omx decoder.
--
You a
On Thu, Jun 14, 2018 at 06:43:40PM +0200, Thomas Hellstrom wrote:
> Overall, I think this looks fine. I'll just fix up the FLAG_WAITERS setting
> and affected comments and do some torture testing on it.
Thanks!
> Are you OK with adding the new feature and the cleanup in the same patch?
I suppose
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #24 from djip.per...@free.fr ---
look like LVDS is not see as attached...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@list
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #23 from djip.per...@free.fr ---
Created attachment 140167
--> https://bugs.freedesktop.org/attachment.cgi?id=140167&action=edit
dmesg from kernel 4.17.1 with attachment 138831 applied
recompile 4.17.1 kernel with patch an debug mo
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #4 from Ricardo Ribalda ---
I do not know. It is the first time that I use this configuration: omx for
encoding and decoding.
The only thing that I know for sure is that the effect gets worse and worse if
I increase the frequency of
https://bugs.freedesktop.org/show_bug.cgi?id=106919
Julien Isorce changed:
What|Removed |Added
CC||boyuan.zh...@amd.com,
Quoting Bloomfield, Jon (2018-06-14 17:36:29)
> > -Original Message-
> > From: Chris Wilson
> > Sent: Thursday, June 14, 2018 9:07 AM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Chris Wilson
> > ;
> > Bloomfield, Jon ; Joonas Lahtinen
> > ; Matthew Aul
https://bugs.freedesktop.org/show_bug.cgi?id=106921
--- Comment #2 from sam.ps...@gmail.com ---
Created attachment 140166
--> https://bugs.freedesktop.org/attachment.cgi?id=140166&action=edit
another dmesg w/mesa 18.0.2-1.fc28
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=106921
--- Comment #1 from sam.ps...@gmail.com ---
Created attachment 140165
--> https://bugs.freedesktop.org/attachment.cgi?id=140165&action=edit
dmesg w/mesa 18.2.0-0.11.git41dabdc.fc28
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=106921
Bug ID: 106921
Summary: System lockup with Vega10 amdgpu:
[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
timeout
Product: DRI
Version: unspecified
On 06/14/2018 04:42 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 01:48:39PM +0200, Thomas Hellstrom wrote:
The literature makes a distinction between "killed" and "wounded". In our
context, "Killed" is when a transaction actually receives an -EDEADLK and
needs to back off. "Wounded" is when
> -Original Message-
> From: Chris Wilson
> Sent: Thursday, June 14, 2018 9:07 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Chris Wilson ;
> Bloomfield, Jon ; Joonas Lahtinen
> ; Matthew Auld
> ; David Herrmann
>
> Subject: [PATCH v2] drm/i915: Prevent w
On Thu, 14 Jun 2018 18:09:01 +0200,
Mauro Carvalho Chehab wrote:
>
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro Ca
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #23 from sam.ps...@gmail.com ---
(In reply to Michel Dänzer from comment #22)
> (In reply to sam.psylo from comment #20)
> > I am still suffering from this issue, even with latest firmware from comment
> > 15.
>
> Please file your ow
On Thu, 14 Jun 2018 13:08:49 -0300
Mauro Carvalho Chehab wrote:
> +++ b/Documentation/trace/events.rst
> @@ -8,7 +8,7 @@ Event Tracing
> 1. Introduction
> ===
>
> -Tracepoints (see Documentation/trace/tracepoints.txt) can be used
> +Tracepoints (see Documentation/trace/tracepoints
On Thu, 2018-06-14 at 13:09 -0300, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro Carv
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Thursday, June 14, 2018 6:21 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala, Vi
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix
Manually checked if the produced result is valid, removing a few
false-positives.
Acked-by: Takashi Iwai
Acked-by: Masami Hiramatsu
Acked-by: Stephen B
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix
Manually checked that produced results are valid.
Signed-off-by: Mauro Carvalho Chehab
---
.../devicetree/bindings/clock/st/st,clkgen.txt | 8
The script:
./scripts/documentation-file-ref-check --fix-rst
Gives multiple hints for broken references on some files.
Manually use the one that applies for some files.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/obsolete/sysfs-gpio | 2 +-
.../devicet
On Thu, Jun 14, 2018 at 12:30:35PM +0530, Vivek Gautam wrote:
> Hi Jordan,
>
> On Mon, Jun 11, 2018 at 11:56 PM, Jordan Crouse
> wrote:
> > Now that the IOMMU is the master of it's own power we don't need to bring
> > up the GPU to do IOMMU operations. This is good because bringing up a6xx
> > r
If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.
Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least r
On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> Switch to state based resource management. This patch
> overhauls the resource manager and HW allocation methods by
> maintaining the global resource pool and allocated hw
> blocks in respective drm component states.
>
> Global r
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #10 from cerg2010cerg2...@mail.ru ---
Here is the output:
[ 23.056329] (null): initial SCL state 1
[ 23.056330] (null): initial SDA state 1
[ 23.056532] (null): initial SCL state 1
[ 23.056534] (null): initial SDA state 1
https://bugs.freedesktop.org/show_bug.cgi?id=106872
Michel Dänzer changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|dri-devel@l
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #22 from Michel Dänzer ---
(In reply to sam.psylo from comment #20)
> I am still suffering from this issue, even with latest firmware from comment
> 15.
Please file your own report. This report is resolved.
> Firmware: 20180525-85
On Tue, Jun 12, 2018 at 06:17:43PM -0700, Jeykumar Sankaran wrote:
> This patchset introduces drm private object in KMS to manage HW
> resource management. It modifies the resource manager by
> introducing API's to do per DRM object resource allocation/cleanups.
>
> The patchset is based on: https
On Wed, Jun 13, 2018 at 12:01:21PM -0700, Jeykumar Sankaran wrote:
> On 2018-06-13 09:44, Jordan Crouse wrote:
> > On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> > > Switch to state based resource management. This patch
> > > overhauls the resource manager and HW allocation me
On Tue, May 15, 2018 at 11:18:50AM +0100, Alexandru Gheorghe wrote:
> Status register contains a lot of bits for reporting internal errors
> inside Mali DP. Currently, we just silently ignore all of the errors,
> that doesn't help when we are investigating different bugs, especially
> on the FPGA m
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #9 from Wolfram Sang (w...@the-dreams.de) ---
Created attachment 276551
--> https://bugzilla.kernel.org/attachment.cgi?id=276551&action=edit
print initial states to allow further debug
Thanks for testing the patches, pity it didn't
On Tue, Jun 12, 2018 at 05:49:03PM -0700, Abhinav Kumar wrote:
> Seamless modes are ones which do not require a display
> to be turned OFF/ON between mode switches.
>
> Remove support for seamless modes from DPU for now.
>
> This will be added later based on additional requirements.
>
> This cha
On Mon, Jun 11, 2018 at 02:13:17PM -0700, Jeykumar Sankaran wrote:
> Submitting a series of patches to further clean up DPU driver by stripping
> down a list of custom properties supporting proprietary features. It
> removes the property installers/handlers and cleans up relevant files of
> of som
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #21 from sam.ps...@gmail.com ---
Created attachment 140159
--> https://bugs.freedesktop.org/attachment.cgi?id=140159&action=edit
dmesg w/mesa 18.2.0-0.11.git41dabdc.fc28
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #20 from sam.ps...@gmail.com ---
Created attachment 140158
--> https://bugs.freedesktop.org/attachment.cgi?id=140158&action=edit
dmesg w/mesa 18.0.2-1.fc28
I am still suffering from this issue, even with latest firmware from commen
Hello,
Please pull the generic drm_writeback patches into drm-misc-next. They
have been reviewed on the mailing lists for a while, and we have the
userspace and individual kernel driver's implementations using it.
The following changes since commit 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5:
Mer
On Thu, Jun 14, 2018 at 03:43:04PM +0200, Thomas Hellstrom wrote:
> It's intended to be enforced by storing the algorithm choice in the
> WW_MUTEX_CLASS which must be common for an acquire context and the
> ww_mutexes it acquires. However, I don't think there is a check that that
> holds. I guess w
On Thu, Jun 14, 2018 at 01:48:39PM +0200, Thomas Hellstrom wrote:
> The literature makes a distinction between "killed" and "wounded". In our
> context, "Killed" is when a transaction actually receives an -EDEADLK and
> needs to back off. "Wounded" is when someone (typically another transaction)
>
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #2 from Ricardo Ribalda ---
Created attachment 140156
--> https://bugs.freedesktop.org/attachment.cgi?id=140156&action=edit
Sluttering (how do I see the video with omx decode)
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #1 from Ricardo Ribalda ---
Created attachment 140154
--> https://bugs.freedesktop.org/attachment.cgi?id=140154&action=edit
Original file encoded with omx (one keyframe per second)
--
You are receiving this mail because:
You are
Hello YoungJun Cho,
The patch 7e3d88f9cce3: "drm/prime: replace NULL with error value in
drm_prime_pages_to_sg" from Jun 24, 2013, leads to the following
static checker warning:
drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL
drivers/gpu/drm/drm
1 - 100 of 171 matches
Mail list logo
