On Mon, Oct 24, 2016 at 08:00:10AM +0200, Daniel Vetter wrote:
> On Sat, Oct 22, 2016 at 05:46:30PM +0300, Ville Syrjälä wrote:
> > On Sat, Oct 22, 2016 at 04:01:14PM +0200, Daniel Vetter wrote:
> > > On Sat, Oct 22, 2016 at 10:47:25AM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 21, 2016 at 0
The names were wrong.
Signed-off-by: Grazvydas Ignotas
---
drivers/gpu/drm/amd/scheduler/sched_fence.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/scheduler/sched_fence.c
b/drivers/gpu/drm/amd/scheduler/sched_fence.c
index 6b63bea..3653b5a 100644
It's done in amd_sched_hw_job_reset(), but not in normal job processing.
Leak reported by CONFIG_SLUB_DEBUG.
Signed-off-by: Grazvydas Ignotas
---
CONFIG_SLUB_DEBUG reports more leaks related to ioctls,
but I was unable to track them down...
drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 2 ++
Looks like .last_flush reference is left at teardown.
Leak reported by CONFIG_SLUB_DEBUG.
Fixes: 41d9eb2c5a2a ("drm/amdgpu: add a fence after the VM flush")
Signed-off-by: Grazvydas Ignotas
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu
To free fences, call_rcu() is used, which calls amd_sched_fence_free()
after a grace period. During teardown, there is no guarantee all
callbacks have finished, so sched_fence_slab may be destroyed before
all fences have been freed. If we are lucky, this results in some slab
warnings, if not, we ge
To free fences, call_rcu() is used, which calls amdgpu_fence_free()
after a grace period. During teardown, there is no guarantee all
callbacks have finished, so amdgpu_fence_slab may be destroyed before
all fences have been freed. If we are lucky, this results in some slab
warnings, if not, we get
Rather than storing the DPMS mode (which will always be on or off) use a
boolean to store this instead.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
tda998x_audio_get_eld() is needlessly complex - the connector associated
with the encoder is always our own priv->connector. Remove this
complexity, but ensure that there are no races when copying out the ELD.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 23 +-
Group the TDA998x audio functions together rather than split between
two different locations in the file, keeping like code together.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 278 +++---
1 file changed, 140 insertions(+), 138 deletions(-
Separate out the connector initialisation from the rest of the drivers
initialisation.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 58 +--
1 file changed, 32 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
Group the TDA998x connector functions and funcs structures together
before the encoder support, rather than scattered amongst the rest of
the file. This keeps like code together.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 316 +++---
1 fi
The naming of tda998x_encoder_set_config() is a left-over from when
TDA998x was a slave encoder. Since this is part of the initialisation,
drop the _encoder from the name, and move it near tda998x_bind().
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 40 +++
Correct two references to tda998x_connector_get_modes() which were
incorrectly referring to tda998x_encoder_get_modes().
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/
Avoid a racy access to the mode clock by storing the current mode clock
during a mode set under the audio mutex. This allows us to access it
from the audio path in a safe way.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 18 +++---
1 file changed, 7 insertions
We must not configure the audio path when the sink is a DVI device, as
DVI has no capability to receive HDMI audio. HDMI audio is a HDMI only
feature, requiring HDMI infoframes.
There's a question concerning how to handle a DVI connected device when
the audio device is opened - we save the audio
As priv->audio_params can now be changed at run time, we need to be more
careful about how we deal with a mode set. We must take the audio lock
while checking if there's a valid audio configuration.
However, it's slightly worse than that - during mode set, we mute the
audio, and it must not be un
As part of the discussion about converting tda998x to a bridge, here's
some preparatory work for that, which includes a bunch of fixes. I'm
sending this out _early_ as I'm not going to be working on any kernel
stuff next week (it's likely I won't even be reading email.) So it may
be a little roug
achments/20161023/44f384cb/attachment.html>
Hello,
I sent the patch below a few weeks ago. I got some comments (cf. [1])
which looked good, but the patch has not been merged in linux-next yet.
Do I need to fix something (like rewrite the commit message) in order to
get it merged?
Thanks,
Nicolas
[1] https://patchwork.freedesktop.org/patch
On Sun, Oct 23, 2016 at 06:55:58PM +0200, Nicolas Iooss wrote:
> Hello,
>
> I sent the patch below a few weeks ago. I got some comments (cf. [1])
> which looked good, but the patch has not been merged in linux-next yet.
> Do I need to fix something (like rewrite the commit message) in order to
> g
;t work well either. Tried with csgo
nine and it fails too.
--
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/20161023/299f5621/attachment.html>
ood
Tested on verde, juniper and haswell.
--
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/20161023/6c8a4009/attachment.html>
On Sun, 23 Oct 2016 09:33:16 +0800
Chen-Yu Tsai wrote:
> > Note: This driver is closed to the sun4i-i2s except that:
> > - it handles the H3
>
> If it's close to sun4i-i2s, you should probably rework that one to support
> the newer SoCs.
>
> > - it creates the sound card (with sun4i-i2s, the so
On Sat, Oct 22, 2016 at 9:28 PM, Jean-Francois Moine wrote:
> This patchset series adds HDMI audio and video support to the Allwinner
> sun8i SoCs which include the display engine 2 (DE2).
>
> A first submission in January for video on the H3 could not enter into
> the mainline kernel due to the l
On Sun, 23 Oct 2016 09:38:04 +0800
Chen-Yu Tsai wrote:
> > Recently, an announce about Tina OS for the R series
> > https://www.youtube.com/watch?v=h7KD-6HblAU
> > was followed by the upload of a new linux-3.4 source tree
> > https://github.com/tinalinux/linux-3.4
> > with files c
Hi,
On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine wrote:
> This patch adds I2S support to sun8i SoCs as the A83T and H3.
>
> Signed-off-by: Jean-Francois Moine
> ---
> Note: This driver is closed to the sun4i-i2s except that:
> - it handles the H3
If it's close to sun4i-i2s, you should p
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161023/5083354d/attachment.html>
I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first. The eDP_AVDD_1V8 more
likely to be applied to eDP phy, but I have no time to confirmed
it yet.
Signed-off-by: Randy Li
---
The current default of always using the performance power state leads
to increased power consumption of mobile devices, which have a dedicated
battery power state. Switch between the performance and battery power
state automatically, dpending on the current AC power status, when the
user asked for
29 matches
Mail list logo