On 29 August 2016 at 07:35, Linus Torvalds
wrote:
> On Sun, Aug 28, 2016 at 2:31 PM, Linus Torvalds
> wrote:
>>
>> Anyway, the real problem was that this was in my spam-box. Which I've
>> learnt to check religiously, so I noticed almost immediately.
>
> Btw, on a totally unrelated issue: you make
On 26/08/16 06:16 PM, Michal Marek wrote:
> On 2016-08-26 04:20, Michel Dänzer wrote:
>> On 26/08/16 02:10 AM, Michal Marek wrote:
>>> amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that
>>> userspace knows that amdgpu needs amdkfd in the initrd.
>>>
>>> Reported-and-tested-by: Ma
On 26/08/16 11:52 PM, Alex Deucher wrote:
> From: satsahu
>
> Signed-off-by: Alex Deucher
> ---
> tests/util/kms.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/util/kms.c b/tests/util/kms.c
> index 650b23b..c20134e 100644
> --- a/tests/util/kms.c
> +++ b/tests/util/kms.c
> @@
On 27/08/16 05:07 AM, Mario Kleiner wrote:
> On 08/18/2016 04:32 AM, Michel Dänzer wrote:
>> On 18/08/16 08:51 AM, Mario Kleiner wrote:
>>>
>>> and the offload gpu imports those and renders into them. That saves
>>> one extra copy, so should be somewhat more efficient.
>>
>> Using two shared buffe
On 27/08/16 04:57 AM, Mario Kleiner wrote:
> On 08/18/2016 04:23 AM, Michel Dänzer wrote:
>> On 18/08/16 01:12 AM, Mario Kleiner wrote:
>
> One thing that confuses me so far is that visual results and measurment
> suggest it works nicely, properly serializing the rendering/detiling
> blit and the
On 08/25/2016 05:46 PM, Daniel Vetter wrote:
> On Thu, Aug 25, 2016 at 11:04:32AM +0200, Andrea Merello wrote:
>> Up to now, once a bridge has been attached to a DRM device, it cannot
>> be undone.
>>
>> In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
>> because the bridg
On 08/25/2016 02:34 PM, Andrea Merello wrote:
> drm_simple_display_pipe_init() pretends to attach a connector
> to the display pipe.
>
> In case a drm bridge has to be used, then it's the bridge that
> takes care of connectors.
>
> This patch makes the connector parameter optional for
> drm_simpl
On 08/25/2016 02:34 PM, Andrea Merello wrote:
> Introduce drm_simple_display_pipe_attach_bridge() and
> drm_simple_display_pipe_detach_bridge() in order to make it possible to use
> drm encoders with the simple display pipes managed by simple_kms_helpers
>
> Suggested-by: Daniel Vetter
> Signed-
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/123304cd/attachment.html>
Hi Thorsten,
On Sun, Aug 28, 2016 at 6:17 PM, Thorsten Leemhuis
wrote:
> Lo! Dave, below report made it to the list of regression for 4.8, but
> afaics nothing happened after the initial report. Was it discussed (and
> maybe even fixed?) elsewhere? Or is there some reason why it shouldn't
> be on
On Sun, Aug 28, 2016 at 01:30:04PM +0200, Dmitry Vyukov wrote:
> Hello,
>
> I've got the following WARNING while running syzkaller fuzzer:
This should be fixed in linux-next, can you pls confirm?
Also I'm somewhat suprised that syzkaller can't reproduce this reliably,
at least in the latest code
On Sun, Aug 28, 2016 at 04:32:55PM +0200, Dmitry Vyukov wrote:
> Hello,
>
> The following program causes a WARNING in idr_remove:
Again under the assumption that you're running this with the vgem driver:
linux-next has it fixed.
-Daniel
>
> [ cut here ]
> WARNING: CPU: 3
On Sun, Aug 28, 2016 at 07:36:59PM +0200, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers WARNING in ioremap_wc:
Yup, that should also be fixed in linux-next. Probably better to not
report more for 4.8-rc kernels for now ;-)
If you have some time to test, you need to cherry pick
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
This variant of fence_get_rcu() takes an RCU protected pointer to a
fence and carefully returns a reference to the fence ensuring that it is
not reallocated as it does. This is required when mixing fences and
SLAB_DESTROY_BY_RCU - although it serves a more pedagogical function atm
Signed-off-by: C
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical
With the seqlock now extended to cover the lookup of the fence and its
testing, we can perform that testing solely under the seqlock guard and
avoid the effective locking and serialisation of acquiring a reference to
the request. As the fence is RCU protected we know it cannot disappear
as we test
Currently we install a callback for performing poll on a dma-buf,
irrespective of the timeout. This involves taking a spinlock, as well as
unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
multiple threads.
We can query whether the poll will block prior to installing the
cal
On Sun, 28 Aug 2016, Andrea Arcangeli wrote:
> Skylake was already singled out, but it doesn't cover the XPS 13 L332X
> model which is based on IvyBridge.
>
> The commit that introduced the regression is
> 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
That's a merge commit, the real one is
commit a05
Write DMA base and ceiling address with a single instruction, if
available. This should make it more unlikely that LCDC would fetch the
DMA addresses in the middle of an update. Having bad combination of
addresses in dma base and ceiling (e.g base > ceiling) can cause
unpredictaple behavior in LCDC
It's deprecated and only should be used by drivers which still use
drm_platform_init, not by anyone else.
And indeed it's entirely unused and can be nuked.
This required a bit more fudging, but I guess kirin_dc_ops really
wants to operate on the platform_device, not something else. Also
bonus poi
>Sent: Saturday, August 27, 2016 8:07 PM
>To: Tomi Valkeinen ; Tony Lindgren atomide.com>;
>Sean Paul ; Peter Chen ;
>Andrey Utkin
>Cc: David Airlie ; Peter Ujfalusi ti.com>; Dave
>Airlie ; Rob Clark ; Dr. H.
>Nikolaus
>Schaller ; Andrew Bradford ;
>kernel at pyra-handheld.com; Discussions about
Tried 4.8-rc4 on my i5-2400 PC, got this warning:
[ 14.579557] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[ 15.847321] [ cut here ]
[ 15.847346] WARNING: CPU: 0 PID: 208 at drivers/gpu/drm/i915/intel_pm.c:7866
sandybridge_pcode_write+0x109/0x1f0 [i915]
[
On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote:
> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
> of the helper drm_atomic_helper_commit_planes() if the relevant display
> controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
> when the CRTC
Same treatment as before. Only hiccup is drm_crtc_mask, which
unfortunately can't be resolved until drm_crtc.h is less of a monster.
Untangle the header loop with a forward declaration for that static
inline.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.
- Move missing bits into struct drm_encoder docs.
- Explain that encoders are 95% internal and only 5% uapi, and that in
general the uapi part is broken.
- Remove verbose comments for functions not exposed to drivers.
v2: Review from Archit:
- Appease checkpatch in the moved code.
- Make it clea
Just for the struct drm_mode_object base class. The header file was
already partially extracted to help untangle the include loops.
v2:
- Also move the generic get/set property ioctls. At first this seemed
like a bad idea since it requires making drm_mode_crtc_set_obj_prop
non-static. But even
It's only used in drm_mode_object_get_properties, and we can compute
it there directly with a bit of code shuffling.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_object.c | 31 ---
include/drm/drm_mode_object.h | 2 +-
2 f
It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.
Cc: Laurent Pinchart
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 43 ---
drivers/gpu/drm/drm_fourcc.c | 43 +++
They work exactly the same now, after the refcounting unification a bit
ago. The only reason they're distinct is backwards compat with existing
userspace.
Cc: Daniel Stone
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_property.c | 23 +--
1
- remove kerneldoc for drm-internal functions
- drm_property_replace_global_blob isn't actually atomic, and doesn't
need to be. Update docs&comments to match
- document all the types and try to link things a bit better
- nits all over
v2: Appease checkpatch in the moved code (Archit)
Reviewed-b
I figured an overview section here is overkill, and better
to just document the 2 structures themselves well enough.
v2: Review from Archit:
- Appease checkpatch in moved code.
- Spelling fixes in the kerneldoc.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mo
This just contains the base property classes and all the code to
handle blobs. I think for any kind of standardized/shared properties
it's better to have separate files - this is fairly big already as-is.
v2: resurrect misplaced hunk (Daniel Stone)
Cc: Daniel Stone
Reviewed-by: Archit Taneja
Si
Am 29.08.2016 um 09:08 schrieb Chris Wilson:
> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> need to handle such conversion in the caller. The only challenge are
> those callers that wish to different
/dri-devel/attachments/20160829/71f5e05a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/569aafd9/attachment.html>
Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> According to basic tests, it looks there is no issue if we don't wait for
> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that,
> either. This patch is needed to avoid the annoying warning caused by a
> timeout on wa
On Mon, Aug 29, 2016 at 4:25 PM, Daniel Vetter wrote:
> On Fri, Aug 26, 2016 at 03:30:40PM +0800, Liu Ying wrote:
>> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
>> of the helper drm_atomic_helper_commit_planes() if the relevant display
>> controllers(e.g., IPUv3 for
My Dell XPS 13 9350 laptop just got a buffer underrun:
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A
FIFO underrun
I'm seeing this very occasionally, and they don't come in groups -- I
seem to get one underrun with a black flash and that's it. This is
with just the laptop s
https://bugzilla.kernel.org/show_bug.cgi?id=153121
Kontantin Ivanov changed:
What|Removed |Added
Severity|low |normal
--
You are receiving this mai
Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
of the helper drm_atomic_helper_commit_planes() if the relevant display
controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
when the CRTC is disabled. The helper would skip the ->atomic_disable
call for a
On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
wrote:
> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> According to basic tests, it looks there is no issue if we don't wait for
>> DMFC FIFO to clear when disabling DMFC channel. NXP BSP doesn't do that,
>> either. This patch is nee
Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
> wrote:
> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> >> According to basic tests, it looks there is no issue if we don't wait for
> >> DMFC FIFO to clear when disabling DM
Don't leave the bridge attached to a stale driver instance when
unbinding, to allow reattachment on a rebind.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-ldb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 3
Don't leave any bridge or panel attached to a stale driver instance
when unbinding, to allow reattachment on a rebind.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/parallel-display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/imx/parallel-display.c
b/driver
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/25d8573f/attachment.html>
On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel
wrote:
> Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
>> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
>> wrote:
>> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> >> According to basic tests, it looks there is no issue
Am Montag, den 29.08.2016, 17:57 +0800 schrieb Ying Liu:
> On Mon, Aug 29, 2016 at 5:46 PM, Philipp Zabel
> wrote:
> > Am Montag, den 29.08.2016, 17:36 +0800 schrieb Ying Liu:
> >> On Mon, Aug 29, 2016 at 4:46 PM, Philipp Zabel
> >> wrote:
> >> > Am Freitag, den 26.08.2016, 15:30 +0800 schrieb
Add defines for the memory reset bits and export the memory reset
function to IPU modules.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 17 +
drivers/gpu/ipu-v3/ipu-prv.h| 24
2 files changed, 37 insertions(+), 4 deletions(-)
di
Reset the write FIFO memories after disabling the DMFC
to make sure no stale data is kept around.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-dmfc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c
in
Am Freitag, den 26.08.2016, 17:10 +0100 schrieb Russell King - ARM
Linux:
> On Fri, Aug 26, 2016 at 05:49:54PM +0200, Lucas Stach wrote:
> > The devicetree documentation states that those are required properties,
> > so the driver should refuse to probe if those are absent to be
> > consistent. Thi
Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> This patch adds active plane reconfiguration support for imx-drm.
> This may fixes some mode setting failure issues which were introduced
> by imx-drm atomic conversion patch set. The main idea is to disable the
> plane in question in CRT
Am Donnerstag, den 11.08.2016, 11:18 +0200 schrieb Lucas Stach:
> When the destroy path is called the plane should already be
> disabled. If not, this is a core bug and should not be worked
> around in the driver.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/imx/ipuv3-plane.c | 1 -
>
When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
in which some DRM drivers are built-in, but the framebuffer core is a
loadable module. This results in a link error, such as:
drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe':
radeon_kfd.c:(.text.radeon_pci_probe
from Vedran MiletiÄ ---
Can you try a newer kernel? 4.7 at least.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160
On Mon, Aug 29, 2016 at 02:34:07PM +0200, Arnd Bergmann wrote:
> When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
> in which some DRM drivers are built-in, but the framebuffer core is a
> loadable module. This results in a link error, such as:
>
> drivers/gpu/drm/radeon/radeo
On Mon, Aug 29, 2016 at 05:12:03PM +0800, Liu Ying wrote:
> Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
> of the helper drm_atomic_helper_commit_planes() if the relevant display
> controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
> when the CRTC
Both amdgpu and radeon load amdkfd via symbol_request(). Add a softdep
hint so that userspace knows that each of them needs amdkfd in the
initrd.
Reported-and-tested-by: Martin Jambor [amdgpu]
Reported-by: Michel Dänzer [radeon]
Signed-off-by: Michal Marek
---
v2: Also patch radeon
drivers/g
On Mon, Aug 29, 2016 at 12:50:22PM +0300, Peter Ujfalusi wrote:
> drm_kms_helper_poll_enable_locked() should check if we have delayed event
> pending and if we have, schedule the work to run without delay.
>
> Currently the output_poll_work is only scheduled if any of the connectors
> have DRM_CON
On 2016-08-29 03:37, Michel Dänzer wrote:
> On 26/08/16 06:16 PM, Michal Marek wrote:
>> It's a soft dependency, so it will be silently ignored. /sbin/modprobe
>> --show-depends amdgpu will only list amdgpu.ko and its hard depedencies.
>
> Thanks for the clarification.
>
> The radeon driver prob
On 08/29/2016 01:57 PM, Daniel Vetter wrote:
> - remove kerneldoc for drm-internal functions
> - drm_property_replace_global_blob isn't actually atomic, and doesn't
>need to be. Update docs&comments to match
> - document all the types and try to link things a bit better
> - nits all over
>
R
> -Original Message-
> From: Michel Dänzer [mailto:michel at daenzer.net]
> Sent: Sunday, August 28, 2016 11:17 PM
> To: Mario Kleiner
> Cc: dri-devel at lists.freedesktop.org; jglisse at redhat.com;
> bskeggs at redhat.com; Deucher, Alexander; airlied at redhat.com
> Subject: Re: "Fixes"
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/2216ebd8/attachment.html>
On Mon, Aug 29, 2016 at 06:44:46PM +0530, Archit Taneja wrote:
>
>
> On 08/29/2016 01:57 PM, Daniel Vetter wrote:
> > - remove kerneldoc for drm-internal functions
> > - drm_property_replace_global_blob isn't actually atomic, and doesn't
> >need to be. Update docs&comments to match
> > - docu
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks.
Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel:
> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
> > This patch adds active plane reconfiguration support for imx-drm.
> > This may fixes some mode setting failure issues which were introduced
> > by imx-drm atomic conversion
rg/archives/dri-devel/attachments/20160829/ff05218c/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160829/4fec402d/attachment.html>
On Mon, 29 Aug 2016, Andrea Arcangeli wrote:
> On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote:
>> If it's an Iybridge, there's no low vswing, and that explanation is
>> false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2
>> on an unpatched kernel.
>
> What I should
dri-devel/attachments/20160829/5e8abd78/attachment.html>
dri-devel/attachments/20160829/8138f61a/attachment.html>
On Mon, 29 Aug 2016, Lyude wrote:
> i915 sometimes needs to disable planes in the middle of an atomic
> commit, and then reenable them later in the same commit. Because of
> this, we can't make the assumption that the state of the plane actually
> changed. Since the state of the plane hasn't actua
dri-devel/attachments/20160829/14bd2532/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160829/aab84dbb/attachment.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/78c15ac6/attachment.html>
On Mon, Aug 29, 2016 at 4:59 PM, Philipp Zabel
wrote:
> Am Montag, den 29.08.2016, 12:53 +0200 schrieb Philipp Zabel:
>> Am Freitag, den 26.08.2016, 15:30 +0800 schrieb Liu Ying:
>> > This patch adds active plane reconfiguration support for imx-drm.
>> > This may fixes some mode setting failure i
On Wed, Aug 24, 2016 at 08:46:37AM +0300, Vladimir Zapolskiy wrote:
> The change adds support of internal HDMI I2C master controller, this
> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>
> The main purpose of this functionality is to support reading EDID from
> an HDMI m
The atomic conversion lost the notification to let the DRM core
know about the current state of the CRTC vblank interrupts. This
regressed the ability of the core to reject page flip attempts
on currently disabled CRTCs. Add back the notifications.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/
i915 sometimes needs to disable planes in the middle of an atomic
commit, and then reenable them later in the same commit. Because of
this, we can't make the assumption that the state of the plane actually
changed. Since the state of the plane hasn't actually changed, neither
have it's watermarks.
Hi all,
On 24 August 2016 at 06:46, Vladimir Zapolskiy
wrote:
> MODULE_AUTHOR("Sascha Hauer ");
> MODULE_AUTHOR("Andy Yan ");
> MODULE_AUTHOR("Yakir Yang ");
> +MODULE_AUTHOR("Vladimir Zapolskiy ");
Don't meant to start a flame-war or alike but to educate myself:
Where does one draw the line
The ttm_mem_type_manager.move tracks the fence for the last migration on
the memory manager. Currently it is accessed under its own spinlock to
ensure that the fence doesn't disappear from underneath it. We can
translate the reader to acquire a reference to the fence using
fence_get_rcu_safe() whic
Am 29.08.2016 um 18:57 schrieb Chris Wilson:
> The ttm_mem_type_manager.move tracks the fence for the last migration on
> the memory manager. Currently it is accessed under its own spinlock to
> ensure that the fence doesn't disappear from underneath it. We can
> translate the reader to acquire a r
dri-devel/attachments/20160829/11ad4aef/attachment-0001.html>
If we being polled with a timeout of zero, a nonblocking busy query,
we don't need to install any fence callbacks as we will not be waiting.
As we only install the callback once, the overhead comes from the atomic
bit test that also causes serialisation between threads.
Signed-off-by: Chris Wilson
Hi Chris,
2016-08-29 Chris Wilson :
> If we being polled with a timeout of zero, a nonblocking busy query,
> we don't need to install any fence callbacks as we will not be waiting.
> As we only install the callback once, the overhead comes from the atomic
> bit test that also causes serialisation
Hi Emil,
On 08/29/2016 07:41 PM, Emil Velikov wrote:
> Hi all,
>
> On 24 August 2016 at 06:46, Vladimir Zapolskiy
> wrote:
>
>> MODULE_AUTHOR("Sascha Hauer ");
>> MODULE_AUTHOR("Andy Yan ");
>> MODULE_AUTHOR("Yakir Yang ");
>> +MODULE_AUTHOR("Vladimir Zapolskiy ");
> Don't meant to start a fla
https://bugzilla.kernel.org/show_bug.cgi?id=117581
--- Comment #7 from Elmar Stellnberger ---
I guess it would already be resolved but Bug 155511 inhibits me from testing
that out correctly.
--
You are receiving this mail because:
You are watching the assignee of the bug.
known about it... ;-).
The base OS was Fedora 24/x86_64 with LLVM 3.8.0.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/1e187f11/attachment.html>
drm/i915/vlv: Make intel_crt_reset() per-encoder:
4570d833390b10043d082fe535375d4a0e071d9c
drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init():
4c732e6ee9e71903934d75b12a021eb3520b6197
drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug():
21842ea84f161ae37ba25f0250c377fd19c5b307
d
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
https://github.com/anholt/linux drm-vc4-fixes-2016-08-29
for you to fetch changes up to 552416c146fadc67cd9b53ef7adf88d3381c43a6:
drm/vc4: Fix oops when userspace hands in a bad BO. (2016-08-19 19:17:39
-07
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
https://github.com/anholt/linux tags/drm-vc4-next-2016-08-29
for you to fetch changes up to 67f13690f447841fb3d2f952a6e49b2b28ae379b:
drm/vc4: Don't force new binner overflow allocation per draw. (2016-08-19
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160829/22518200/attachment-0001.html>
This is another swing at getting the adv7511 hdmi bridge
audio support reviewed.
I've taken the core audio work done by Lars-Peter Clausen, and
adapted by Srinivas Kandagatla and Archit Taneja, and tried to
rework it to use the hdmi-codec sound driver.
This patchset, along with the i2s driver and
From: Archit Taneja
This patch moves the adv7511 data structure to header file so that the
audio driver file could use it.
Cc: David Airlie
Cc: Archit Taneja
Cc: Laurent Pinchart
Cc: Wolfram Sang
Cc: Srinivas Kandagatla
Cc: "Ville Syrjälä"
Cc: Boris Brezillon
Cc: Andy Green
Cc: Dave Lo
1 - 100 of 128 matches
Mail list logo
