https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #6 from thedribbleo...@gmail.com ---
(In reply to Samuel Pitoiset from comment #4)
> Okay, that makes more sense. I only have a RX480, so I definitely can't help
> here.
>
> If you get a chance, can you try recording an apitrace which
On 02/24/2017 01:20 AM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Mon, Jan 30, 2017 at 09:03:07PM +0100, Thierry Reding wrote:
From: Thierry Reding
The gk20a implementation of instance memory uses vmap()/vunmap() to map
memory regions into the kernel's virtual address space. The
On Fri, Feb 24, 2017 at 7:44 AM, Thomas Hellstrom wrote:
> On 02/22/2017 08:04 PM, Daniel Vetter wrote:
>> On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom
>> wrote:
>>> vmware tools has a daemon that gets layout information from the GUI and
>>> forwards it to DRM so that the modesetting code c
Tested-by: Y.C. Chen
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, February 24, 2017 6:54 AM
To: dri-devel@lists.freedesktop.org
Cc: YC Chen ; airl...@redhat.com; e...@suse.come;
linuxppc-...@ozlabs.org
Subject: [PATCH 12/12] drm/ast: Ca
Tested-by: Y.C. Chen
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, February 24, 2017 6:54 AM
To: dri-devel@lists.freedesktop.org
Cc: YC Chen ; airl...@redhat.com; e...@suse.come;
linuxppc-...@ozlabs.org
Subject: [PATCH 11/12] drm/ast: Fi
Tested-by: Y.C. Chen
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, February 24, 2017 6:54 AM
To: dri-devel@lists.freedesktop.org
Cc: YC Chen ; airl...@redhat.com; e...@suse.come;
linuxppc-...@ozlabs.org
Subject: [PATCH 09/12] drm/ast: Re
Tested-by: Y.C. Chen
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, February 24, 2017 6:54 AM
To: dri-devel@lists.freedesktop.org
Cc: YC Chen ; airl...@redhat.com; e...@suse.come;
linuxppc-...@ozlabs.org
Subject: [PATCH 08/12] drm/ast: Fa
Tested-by: Y.C. Chen
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, February 24, 2017 6:54 AM
To: dri-devel@lists.freedesktop.org
Cc: YC Chen ; airl...@redhat.com; e...@suse.come;
linuxppc-...@ozlabs.org
Subject: [PATCH 07/12] drm/ast: Fi
Tested-by: Y.C. Chen
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, February 24, 2017 6:54 AM
To: dri-devel@lists.freedesktop.org
Cc: YC Chen ; airl...@redhat.com; e...@suse.come;
linuxppc-...@ozlabs.org
Subject: [PATCH 05/12] drm/ast: Fi
Tested-by: Y.C. Chen
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, February 24, 2017 6:54 AM
To: dri-devel@lists.freedesktop.org
Cc: YC Chen ; airl...@redhat.com; e...@suse.come;
linuxppc-...@ozlabs.org
Subject: [PATCH 02/12] drm/ast: Ha
Tested-by: Y.C. Chen
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, February 24, 2017 6:54 AM
To: dri-devel@lists.freedesktop.org
Cc: YC Chen ; airl...@redhat.com; e...@suse.come;
linuxppc-...@ozlabs.org
Subject: [PATCH 01/12] drm/ast: Fi
On 02/22/2017 08:04 PM, Daniel Vetter wrote:
> On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom
> wrote:
>> vmware tools has a daemon that gets layout information from the GUI and
>> forwards it to DRM so that the modesetting code can set preferred connector
>> locations and modes. This daemon w
https://bugs.freedesktop.org/show_bug.cgi?id=99628
yann changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail because:
Y
https://bugs.freedesktop.org/show_bug.cgi?id=99488
--- Comment #9 from nixscrip...@gmail.com ---
Thanks for your continued work on this.
I've been fighting with Arch Linux packaging for a week of quiet frustration.
It's also really slow to try and fix it, because the debug build seems to be
10x t
The ast driver configures a window to enable access into BMC
memory space in order to read some configuration registers.
If this window is disabled, which it can be from the BMC side,
the ast driver can't function.
Closing this window is a necessity for security if a machine's
host side and BMC s
On Fri, 2017-02-24 at 12:54 +1030, Joel Stanley wrote:
> On Fri, Feb 24, 2017 at 9:23 AM, Benjamin Herrenschmidt
> wrote:
> > Some braces were missing causing an incorrect calculation.
> >
> > Y.C. Chen from Aspeed provided me with the right formula
> > which I tested on AST2400 and 2500.
>
> Y.
On Fri, 2017-02-24 at 12:51 +1030, Joel Stanley wrote:
>
> Are these properties supposed to repeat the prefix "ast,ast"?
>
> We've chosen aspeed as the vendor prefix for Aspeed stuff.
Sent my reply too early ... so yes, I can change that, our FW hasn't
merge the FW side yet. I'll respin now.
>
On Fri, 2017-02-24 at 12:51 +1030, Joel Stanley wrote:
> Are these properties supposed to repeat the prefix "ast,ast"?
>
> We've chosen aspeed as the vendor prefix for Aspeed stuff.
Argh no, that's a typo... must have worked in my tests bcs
the defaults are fine. I'll update.
Cheers,
Ben.
_
On Thu, Feb 23, 2017 at 5:44 PM, Linus Torvalds
wrote:
>
> AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED
> YESTERDAY?
.. and a slightly less annoying piece of crap in this pull request:
that "PRIME_NUMBERS" config thing is utter garbage too.
Why would you ask a user about
On Thu, Feb 23, 2017 at 4:01 PM, Dave Airlie wrote:
>
> This is the main drm pull request for v4.11.
>
> Nothing too major, the tinydrm and mmu-less support should make writing
> smaller drivers easier for some of the simpler platforms, and there are
> a bunch of documentation updates.
The tinydr
I see that I forgot cc'ing Dave Airlie on this, and I just realised
that the backlight problem isn't just a warning, but it actually causes
a build failure if backlight is built as a module.
I missed this in my hurry to get this out the door, sorry.
Den 23.02.2017 14.29, skrev Noralf Trønnes:
D
Hi,
On Tue, Feb 21, 2017 at 11:45 PM, Nickey Yang
wrote:
> "I2C Master Interface Extended Read Mode" implements a segment
> pointer-based read operation using the Special Register configuration.
>
> This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned
> "The current implementation
Hi Emil,
On Thu, Feb 23, 2017 at 05:44:54PM +, Emil Velikov wrote:
> On 22 February 2017 at 15:18, Icenowy Zheng wrote:
> > Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes
> > in a new "Display Engine" (mixers instead of old backends and
> > frontends).
> >
> > Add su
On 2017年02月24日 02:01, Sean Paul wrote:
On Thu, Feb 23, 2017 at 10:03:23AM +0800, Mark yao wrote:
On 2017年02月23日 00:09, Sean Paul wrote:
On Tue, Feb 21, 2017 at 7:54 PM, Mark yao wrote:
Hi Dave
Some fixes, looks good to me.
Hi Mark,
As we discussed, rockchip patches should now go through -m
The way drm_of_find_possible_crtcs is it tries to match the
remote-endpoint of the given node's various endpoints to all the
crtc's .port field. Thus we need to set drm_crtc.port to the output
port node of the underlying TCON.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_crtc.c |
On Fri, 2017-02-24 at 09:53 +1100, Benjamin Herrenschmidt wrote:
> From: "Y.C. Chen"
>
> (Get better description from Aspeed)
And this should have been:
<<
The test to see if VGA was already enabled is doing an unnecessary
second test from a register that may or may not have been initialized
to
Now that the crtcs have their .port field set properly, we can use
drm_of_find_possible_crtcs to find the connected crtcs, instead of
hardcoding the first crtc as usable. The new code also defers binding
when the upstream crtc hasn't been registered yet.
This makes it easier to support multiple tc
To support multiple display pipelines, we would have multiple crtcs,
with one or more planes bound to them. Obviously having hardcoded
values for the drm_plane .possible_crtcs field is not going to work.
For primary and cursor planes, the value is set by
drm_crtc_init_with_planes. We just need to
On Thu, 2017-02-23 at 17:41 +, Emil Velikov wrote:
> On 23 February 2017 at 17:18, Joe Perches wrote:
> > On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> > > On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches wrote:
> > > > There are ~4300 uses of pr_warn and ~250 uses of the older
> > > >
On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches wrote:
> > There are ~4300 uses of pr_warn and ~250 uses of the older
> > pr_warning in the kernel source tree.
> >
> > Make the use of pr_warn consistent across all kernel files.
> >
> > This ex
sun4i_crtc controls the backend and tcon hardware blocks of the display
pipeline. Instead of doing so through the master drm structure, leave
pointers to the corresponding backend and tcon in itself.
Also drop the drm_device pointer, since it is no longer needed.
The next step forward would be to
On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning
sunxi_rgb2yuv_coef is a table of RGB-to-YUV conversion coefficients.
They are programmed into the hardware, and can be declared constant.
Reported-by: Priit Laes
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
The number of defined planes in sun4i_layer is unknown to other parts
of the sun4i drm driver. Since the return value of sun4i_layers_init
is a list of layers, make it return 1 more empty layer as an end of
list guard value.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 2
This patch moves the sun4i_layers_init call from sun4i_drv_bind to
sun4i_crtc_init, and the layers pointer from struct sun4i_drv to
struct sun4i_crtc.
The layers are bound to a specific crtc, and they are not directly
used once initiated. They are used through their included drm_plane
structures.
The tcon provides part of the functionality of the crtc, and also
provides the device node for the output port of the crtc. To be able
to use drm_of_find_possible_crtcs(), all crtc must be initialized before
any downstream encoders. The other part of the crtc is the display
backend.
The Rockchip D
Hi Nickey,
On 22-02-2017 11:11, Nickey.Yang wrote:
> Read EDID func is drm_do_probe_ddc_edid(in
> drivers/gpu/drm/drm_edid.c Line:1215)
> when block = 3 means &msgs[3].addr = DDC_SEGMENT_ADDR(0x30)
> ,but in dw_hdmi_i2c_xfer
> line 299 msgs[i].addr != addr (0x50), it will printk
> "uns
在 2017年02月23日 19:40, Nickey.Yang 写道:
Hi Jose,
在 2017年02月23日 18:17, Jose Abreu 写道:
Hi Nickey,
On 22-02-2017 11:11, Nickey.Yang wrote:
Read EDID func is drm_do_probe_ddc_edid(in
drivers/gpu/drm/drm_edid.c Line:1215)
when block = 3 means &msgs[3].addr = DDC_SEGMENT_ADDR(0x30)
,but
On 23 February 2017 at 17:18, Joe Perches wrote:
> On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
>> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches wrote:
>> > There are ~4300 uses of pr_warn and ~250 uses of the older
>> > pr_warning in the kernel source tree.
>> >
>> > Make the use of pr_w
Hi Maxime,
This is the second bunch of fixes for the sun4i drm driver. This is part
of the cleanup I am doing towards making the driver support multiple
display pipelines.
This part mainly aims to get detection of crtcs working with of_graph,
and moving data structure pointers around for a more l
The RGB encoder represents channel 0 of the TCON. Instead of fetching
the pointer to its TCON from the main sun4i_drv structure, pass it in
as part of the init call, save it, and use it directly in the encoder
and connector callbacks.
We can also drop the otherwise unused sun4i_drv pointer.
Signe
Hi Jose,
在 2017年02月23日 18:17, Jose Abreu 写道:
Hi Nickey,
On 22-02-2017 11:11, Nickey.Yang wrote:
Read EDID func is drm_do_probe_ddc_edid(in
drivers/gpu/drm/drm_edid.c Line:1215)
when block = 3 means &msgs[3].addr = DDC_SEGMENT_ADDR(0x30)
,but in dw_hdmi_i2c_xfer
line 299 msgs[i].add
sun4i_layer only controls the backend hardware block of the display
pipeline. Instead of getting a pointer to the underlying backend
through the drm_device structure, leave one in itself.
Also drop the drm_device pointer, since it is no longer needed.
The next step forward would be to pass the po
The current layer init code keeps a pointer to the primary plane layer
in sun4i_drv. When we eventually support multiple display pipelines,
this would force us to keep track of primary planes for all crtcs. And
these pointers only get used at bind time.
Instead, have the crtc init code iterate thr
Hi,
On Fri, Feb 17, 2017 at 08:39:33PM +, Emil Velikov wrote:
> As I feared things have taken a turn for the bitter end :-]
>
> It seems that this is a heated topic, so I'l kindly ask that we try
> the following:
>
> - For people such as myself/Tobias/others who feel that driver and DT
> bi
From: Clint Taylor
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.
P012 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane,
From: "Y.C. Chen"
(Get better description from Aspeed)
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_post.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
The function does more than initializing the DRAM and in turns
calls other functions to do the actual init. This will keeping
things more consistent with the upcoming AST2500 POST code.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_post.c | 6 +++---
1 file changed, 3 inserti
From: "Y.C. Chen"
Add detection and mode setting updates for AST2500 generation chip,
code originally from Aspeed and slightly reworked for coding style
mostly by Ben. This doesn't contain the BMC DRAM POST code which
is in a separate patch.
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herr
There's a some duplication for what's essentially copies of
two loops, so factor it. The upcoming AST2500 POST code adds
more of them. Also cleanup return types for the test functions,
most of them return a boolean, some return a u32.
Signed-off-by: Benjamin Herrenschmidt
--
v2. - Keep the split
Note: The whole series with the fixed cset comment for patch 11
can be also found there:
https://github.com/ozbenh/linux-ast/commits/master
Cheers,
Ben.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li
From: "Y.C. Chen"
open_key enables access the registers used by enable_mmio
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_post.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/as
From: "Y.C. Chen"
This is used when the BMC isn't running any code and thus has
to be initialized by the host.
The code originates from Aspeed (Y.C. Chen) and has been cleaned
up for coding style purposes by BenH.
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herrenschmidt
--
v2. - Fix bu
On Mon, Feb 20, 2017 at 01:35:50PM +0100, Michal Hocko wrote:
> On Mon 13-02-17 14:44:16, Maxime Ripard wrote:
> > Hi Michal,
> >
> > On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote:
> > > [CC CMA people]
> > >
> > > On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> > > > Modules migh
From: "Y.C. Chen"
The default value of VGA scratch may incorrect.
Should initial h/w before get vram info.
Signed-off-by: Y.C. Chen
---
drivers/gpu/drm/ast/ast_main.c | 6 +++---
drivers/gpu/drm/ast/ast_post.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
Some braces were missing causing an incorrect calculation.
Y.C. Chen from Aspeed provided me with the right formula
which I tested on AST2400 and 2500.
The MCLK isn't currently used by the driver (it will eventually
to filter modes) so the issue isn't catastrophic.
Also make the printed value a
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 36932a3..718c15b 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@
From: Russell Currey
The ast driver configures a window to enable access into BMC
memory space in order to read some configuration registers.
If this window is disabled, which it can be from the BMC side,
the ast driver can't function.
Closing this window is a necessity for security if a machin
From: "Y.C. Chen"
The current POST code for the AST2300/2400 family doesn't work properly
if the chip hasn't been initialized previously by either the BMC own FW
or the VBIOS. This fixes it.
Signed-off-by: Y.C. Chen
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_post.c | 38
And fix some comment alignment & space/tabs while at it
Signed-off-by: Benjamin Herrenschmidt
---
drivers/gpu/drm/ast/ast_drv.h| 4 +-
drivers/gpu/drm/ast/ast_mode.c | 8 +--
drivers/gpu/drm/ast/ast_tables.h | 106 +++
3 files changed, 59 insertions(
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #34 from Pierre-Loup A. Griffais ---
You can use this link:
https://www.dropbox.com/request/mk4YGOBOp4oqX0TKciu7
When you're done uploading the trace I'll post the link to the trace in this
bug report. Thanks!
--
You are receivin
https://bugs.freedesktop.org/show_bug.cgi?id=97590
--- Comment #13 from Alex Deucher ---
I've queued the patch for upstream. I'll close it once the patch makes it into
Linus' tree.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=97590
--- Comment #12 from Adam Bolte ---
Good to know it doesn't matter for testing purposes. In that case, I'm happy
for this to be marked as fixed - unless the policy on doing that is to wait
until the patch is accepted upstream?
--
You are receiv
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #33 from Matthew Fox ---
Hi,
With runpm enabled & radeon.audio=0, the computer locks up requiring a hard
shutdown.
With runpm enabled & radeon.audio=0 & xorg.conf workaround, ditto. Except
sometimes instead the computer will lock up
Op 23-02-17 om 16:03 schreef Sean Paul:
> On Tue, Feb 21, 2017 at 02:51:40PM +0100, Maarten Lankhorst wrote:
>> It seems that nouveau requires this, so best to do this in the helper.
>> This allows nouveau to use the atomic suspend helper.
> Pardon the stupid question, but why can't nouveau just do
Hi Dave,
Just a few fixes for 4.11.
The following changes since commit 9ca70356a9260403c1bda40d942935e55d00c11c:
Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000)
are available in the git repository at:
git://people.freedesktop.org/~agd5f/linux drm-next-4.11
for you
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #33 from siyia ---
ok but do you have a fileserver where i can upload it?
--
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=99679
--- Comment #2 from Levente Abrok ---
It might sound lame, but since then I haven't encountered the situation. Maybe
it was an update or I don't really know.
For now, let's call this solved, hopefully it was truly something already
fixed.
Sorry f
On Wed, Feb 22, 2017 at 12:47:37PM +0100, Andrzej Hajda wrote:
> devm_request_threaded_irq result should be checked for errors.
>
> Signed-off-by: Andrzej Hajda
Applied to -misc
Thanks,
Sean
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --
On Wed, Feb 22, 2017 at 02:59:28PM +0200, Ander Conselvan de Oliveira wrote:
> Handle DRM_DP_DUAL_MODE_LSPCON in drm_dp_get_dual_mode_type_name(),
> otherwise a call to that function can theoretically trigger a WARN.
>
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Shas
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #23 from saunders...@wright.edu ---
I was able to get back to the machine in question sooner than I thought.
The version you have for download in Comment 2, (0086 ) does not work on
4.10, and has the same crash issue.
--
You are
On Thu, Feb 23, 2017 at 04:05:43PM +0800, Chen-Yu Tsai wrote:
> sun4i_crtc controls the backend and tcon hardware blocks of the display
> pipeline. Instead of doing so through the master drm structure, leave
> pointers to the corresponding backend and tcon in itself.
>
> Also drop the drm_device p
On Thu, Feb 23, 2017 at 04:05:38PM +0800, Chen-Yu Tsai wrote:
> The current layer init code keeps a pointer to the primary plane layer
> in sun4i_drv. When we eventually support multiple display pipelines,
> this would force us to keep track of primary planes for all crtcs. And
> these pointers onl
On Thu, Feb 23, 2017 at 04:05:37PM +0800, Chen-Yu Tsai wrote:
> The tcon provides part of the functionality of the crtc, and also
> provides the device node for the output port of the crtc. To be able
> to use drm_of_find_possible_crtcs(), all crtc must be initialized before
> any downstream encode
On Thu, Feb 23, 2017 at 04:05:36PM +0800, Chen-Yu Tsai wrote:
> This patch moves the sun4i_layers_init call from sun4i_drv_bind to
> sun4i_crtc_init, and the layers pointer from struct sun4i_drv to
> struct sun4i_crtc.
>
> The layers are bound to a specific crtc, and they are not directly
> used o
On Thu, Feb 23, 2017 at 04:05:35PM +0800, Chen-Yu Tsai wrote:
> The number of defined planes in sun4i_layer is unknown to other parts
> of the sun4i drm driver. Since the return value of sun4i_layers_init
> is a list of layers, make it return 1 more empty layer as an end of
> list guard value.
>
>
On Thu, Feb 23, 2017 at 04:05:34PM +0800, Chen-Yu Tsai wrote:
> The way drm_of_find_possible_crtcs is it tries to match the
Aren't you missing "works" here ^
> remote-endpoint of the given node's various endpoints to all the
> crtc's .port field. Thus we need to set drm_crtc.port to the outpu
On Thu, Feb 23, 2017 at 04:05:33PM +0800, Chen-Yu Tsai wrote:
> sunxi_rgb2yuv_coef is a table of RGB-to-YUV conversion coefficients.
> They are programmed into the hardware, and can be declared constant.
>
> Reported-by: Priit Laes
> Signed-off-by: Chen-Yu Tsai
Applied, thanks!
Maxime
--
Maxi
On Thu, Feb 23, 2017 at 10:03:23AM +0800, Mark yao wrote:
> On 2017年02月23日 00:09, Sean Paul wrote:
> >On Tue, Feb 21, 2017 at 7:54 PM, Mark yao wrote:
> >>Hi Dave
> >>
> >>Some fixes, looks good to me.
> >>
> >Hi Mark,
> >As we discussed, rockchip patches should now go through -misc. Since
> >4.10
https://bugs.freedesktop.org/show_bug.cgi?id=99628
mohsen2120habibik...@gmail.com changed:
What|Removed |Added
Resolution|--- |FIXED
Status
On 22 February 2017 at 15:18, Icenowy Zheng wrote:
> Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes
> in a new "Display Engine" (mixers instead of old backends and
> frontends).
>
> Add support for the mixer on Allwinner V3s SoC; it's the simplest one.
>
> Signed-off-by:
On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula
wrote:
> On Wed, 22 Feb 2017, Stéphane Marchesin
> wrote:
> > On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
> > wrote:
> >> If the KMS property exposes a fixed number of steps (say 100), it
> becomes
> >> easy for the userspace to express the wanted
Hi Dave,
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.11-rc1
for you to fetch changes up to eaeebffa90f35e0f9265
Hi Dave,
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.11-rc1
for you to fetch changes up to 7b1d4185050d204d6381
On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula
wrote:
> On Wed, 22 Feb 2017, Stéphane Marchesin wrote:
>> On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
>> wrote:
>>> If the KMS property exposes a fixed number of steps (say 100), it becomes
>>> easy for the userspace to express the wanted brightne
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #5 from thedribbleo...@gmail.com ---
(In reply to Samuel Pitoiset from comment #4)
> Okay, that makes more sense. I only have a RX480, so I definitely can't help
> here.
>
> If you get a chance, can you try recording an apitrace which
https://bugs.freedesktop.org/show_bug.cgi?id=99917
--- Comment #2 from Leonid ---
Correct. What I needed: 1) update kernel; 2) update firmware; 3) update initrd;
4) reboot. Just in that sequence. This fixed the problem. Thank you for the
helpful hint.
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #4 from Samuel Pitoiset ---
Okay, that makes more sense. I only have a RX480, so I definitely can't help
here.
If you get a chance, can you try recording an apitrace which reproduces? That
might other devs.
Thanks.
--
You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #22 from saunders...@wright.edu ---
Okay, assuming I'm reading this right with hexdump... On an RX 460 (4 GB):
Old Committed Version (0080 ): Works on 4.9 and 4.10.
New Committed Version, Now Uncommitted (0083 ): Does not work
On Tue, Feb 14, 2017 at 10:31:51PM +0100, Arnd Bergmann wrote:
> The newly added DP driver links against the extcon core, which fails when
> extcon is a module and this driver is not:
>
> drivers/gpu/drm/rockchip/cdn-dp-core.o: In function `cdn_dp_get_port_lanes':
> cdn-dp-core.c:(.text.cdn_dp_get
On Mon, Feb 20, 2017 at 08:08:15AM +0100, Christophe JAILLET wrote:
> It is likely that both 'clk_disable_unprepare()' should be called if
> 'pm_runtime_get_sync()' fails.
>
> Add a new label for that, because 'err_set_rate' is not meaningful in this
> case.
>
> Add a missing call to 'pm_runtime_
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:454:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Signed-off-by: Fengguang Wu
---
tinydrm-helpers.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/tinyd
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 53a95c930ad728b11cc2b21e42b4bd9dcd306400
commit: 9f69eb5c36a644571cca6b2f8dc5f6a7cba04a8b [1827/1945] drm/tinydrm: Add
helper functions
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/tinydrm/core/tinydr
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #3 from thedribbleo...@gmail.com ---
(In reply to Samuel Pitoiset from comment #2)
> Can you provide the following information, please.
>
> - Which mesa-git version?
> - Which LLVM version?
> - Which graphics settings in Hitman?
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #21 from Alex Deucher ---
(In reply to saunders.52 from comment #19)
> Are there some version numbers I can refer to these by to make this less
> insanely confusing?
The 5th dword in each binary is the version.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #19 from saunders...@wright.edu ---
Well, the one you linked above didn't work in 4.9. The one shipping in the
repos that is getting reverted (20170217.12987ca-1) didn't work in 4.9 and
4.10. The oldest of the three (the one shipped or
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #20 from saunders...@wright.edu ---
And I didn't check the one you linked in 4.10. I think.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing li
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #18 from saunders...@wright.edu ---
(In reply to Alex Deucher from comment #17)
> (In reply to saunders.52 from comment #16)
> >
> > The GIT commit reversion should be similar enough to a manual change I tried
> > with both 4.9 and 4.
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #17 from Alex Deucher ---
(In reply to saunders.52 from comment #16)
>
> The GIT commit reversion should be similar enough to a manual change I tried
> with both 4.9 and 4.10 I can almost certainly say it would work (trying the
> old
https://bugs.freedesktop.org/show_bug.cgi?id=99907
--- Comment #16 from saunders...@wright.edu ---
(In reply to Alex Deucher from comment #15)
> (In reply to saunders.52 from comment #14)
> > Which new firmware? The one you linked earlier in the discussion, or the new
> > setup with the one git co
1 - 100 of 147 matches
Mail list logo
