||
--
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/20160208/df976822/attachment.html>
ext part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/d8709bab/attachment.html>
/archives/dri-devel/attachments/20160208/30e42aa9/attachment-0001.html>
On Mon, Feb 8, 2016 at 10:44 PM, wrote:
> On Fri, 29 Jan 2016 22:35:18 +0100, "Rafael J. Wysocki" said:
>> > One more test unveils this one
>> >
>> > # modprobe -r sdhci-acpi
>> > [ 1289.909441] [ cut here ]
>> > [ 1289.918205] WARNING: CPU: 1 PID: 4374 at
>> >
ists.freedesktop.org/archives/dri-devel/attachments/20160208/b978225a/attachment.sig>
On 02/08/2016 04:22 PM, Heiko Stuebner wrote:
> Hi Archit,
>
> Am Montag, 8. Februar 2016, 15:42:04 schrieb Archit Taneja:
>> On 01/06/2016 09:33 AM, Chris Zhong wrote:
>>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
>>> IP. This series adds support for a Synopsys
Le 2016-02-08 15:51, Matthew Dawson a écrit :
>> Yeah, 1s works as well. But that 100ms shouldn't be enough sounds like
>> another bug to me.
> Probably, but it has a tendency to crash my entire system, so I'm not
> sure how
> to debug it further. Netconsole maybe? I probably won't be able to
https://bugzilla.kernel.org/show_bug.cgi?id=109101
--- Comment #1 from Real Name ---
Some news:
- Tested with the current stable kernel (4.4.1). Same issue.
- The turbo frequencies are reached only if I disable DPM (dpm=0) and enable
BAPM, but then I lose GPU performance. It's either one or
On Fri, 29 Jan 2016 22:35:18 +0100, "Rafael J. Wysocki" said:
> > One more test unveils this one
> >
> > # modprobe -r sdhci-acpi
> > [ 1289.909441] [ cut here ]
> > [ 1289.918205] WARNING: CPU: 1 PID: 4374 at
> > /home/andy/prj/linux-otc/drivers/base/power/common.c:150
>
t;pciep_wreg = _pciep_wreg;
> > }
> > +#else
> > + if (rdev->family >= CHIP_R600) {
> > + rdev->pciep_rreg = _pciep_rreg;
> > + rdev->pciep_wreg = _pciep_wreg;
> > + }
> > +#endif
> > }
> >
> > static int radeon_invalid_get_allowed_info_register(struct
> radeon_device *rdev,
> > @@ -2023,6 +2030,8 @@ static struct radeon_asic si_asic = {
> > },
> > };
> >
> > +#ifdef CONFIG_DRM_RADEON_CIK
> > +
> > static const struct radeon_asic_ring ci_gfx_ring = {
> > .ib_execute = _ring_ib_execute,
> > .ib_parse = _ib_parse,
> > @@ -2303,6 +2312,8 @@ static struct radeon_asic kv_asic = {
> > },
> > };
> >
> > +#endif
> > +
> > /**
> >* radeon_asic_init - register asic specific callbacks
> >*
> > @@ -2573,6 +2584,7 @@ int radeon_asic_init(struct
> radeon_device *rdev)
> > break;
> > }
> > break;
> > +#ifdef CONFIG_DRM_RADEON_CIK
> > case CHIP_BONAIRE:
> > case CHIP_HAWAII:
> > rdev->asic = _asic;
> > @@ -2679,6 +2691,7 @@ int radeon_asic_init(struct
> radeon_device *rdev)
> > }
> > rdev->has_uvd = true;
> > break;
> > +#endif
> > default:
> > /* FIXME: not supported yet */
> > return -EINVAL;
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/e9d9079b/attachment-0001.html>
On 02/06/2016 08:54 AM, Xinliang Liu wrote:
> Add crtc funcs and helper funcs for ADE.
>
> v4: None.
> v3:
> - Make ade as the master driver.
> - Use port to connect with encoder.
> - A few cleanup.
> v2:
> - Remove abtraction layer.
>
> Signed-off-by: Xinliang Liu
> ---
>
This gets us functional GPU reset again, like we had until a refactor
at merge time. Tested with a little patch to stuff in a broken binner
job every 100 frames.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_drv.h | 6 +-
drivers/gpu/drm/vc4/vc4_gem.c | 26
This may actually get us a feature that the closed driver didn't have:
turning off the GPU in between rendering jobs, while the V3D device is
still opened by the client.
There may be some tuning to be applied here to use autosuspend so that
we don't bounce the device's power so much, but in
We were tracking the "where are the head pointers pointing" globally,
so if another job reused the same BOs and execution was at the same
point as last time we checked, we'd stop and trigger a reset even
though the GPU had made progress.
Signed-off-by: Eric Anholt
---
Here's a series to re-add GPU reset, which I cut out of the driver in
8483d152db61c5baf5452b844ef65b96ee9a6cfb to deal with a build
regression. Along the way, I found a bug in hang detection that
seemed to be exacerbated by runtime PM.
My preference would be to get this in -fixes, since without
Hi,
On 02/06/2016 08:54 AM, Xinliang Liu wrote:
> Add ADE display controller binding doc.
> Add DesignWare DSI Host Controller v1.20a binding doc.
>
> v4:
> - Describe more specific of clocks and ports.
> - Fix indentation.
> v3:
> - Make ade as the drm master node.
> - Use assigned-clocks to set
Hi,
On 01/06/2016 09:33 AM, Chris Zhong wrote:
>
> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
> controller DRM driver.
>
> The MIPI DSI feature is tested on rk3288 evb board, backport them to
>
art --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/f25db708/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/58ba8fb9/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/b4766ae8/attachment.html>
op.org/archives/dri-devel/attachments/20160208/d11aa04b/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=112061
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1
deon/radeon_asic.c
>> b/drivers/gpu/drm/radeon/radeon_asic.c
>> > index 7d5a36d..2f4beff 100644
>> > --- a/drivers/gpu/drm/radeon/radeon_asic.c
>> > +++ b/drivers/gpu/drm/radeon/radeon_asic.c
>> > @@ -126,6 +126,7 @@ static void radeon_register_accessor_init(struct
>> radeon_device *rdev)
>> > rdev->mc_wreg = _mc_wreg;
>> > }
>> >
>> > +#ifdef CONFIG_DRM_RADEON_CIK
>> > if (rdev->family >= CHIP_BONAIRE) {
>> > rdev->pciep_rreg = _pciep_rreg;
>> > rdev->pciep_wreg = _pciep_wreg;
>> > @@ -133,6 +134,12 @@ static void radeon_register_accessor_init(struct
>> radeon_device *rdev)
>> > rdev->pciep_rreg = _pciep_rreg;
>> > rdev->pciep_wreg = _pciep_wreg;
>> > }
>> > +#else
>> > + if (rdev->family >= CHIP_R600) {
>> > + rdev->pciep_rreg = _pciep_rreg;
>> > + rdev->pciep_wreg = _pciep_wreg;
>> > + }
>> > +#endif
>> > }
>> >
>> > static int radeon_invalid_get_allowed_info_register(struct
>> radeon_device *rdev,
>> > @@ -2023,6 +2030,8 @@ static struct radeon_asic si_asic = {
>> > },
>> > };
>> >
>> > +#ifdef CONFIG_DRM_RADEON_CIK
>> > +
>> > static const struct radeon_asic_ring ci_gfx_ring = {
>> > .ib_execute = _ring_ib_execute,
>> > .ib_parse = _ib_parse,
>> > @@ -2303,6 +2312,8 @@ static struct radeon_asic kv_asic = {
>> > },
>> > };
>> >
>> > +#endif
>> > +
>> > /**
>> >* radeon_asic_init - register asic specific callbacks
>> >*
>> > @@ -2573,6 +2584,7 @@ int radeon_asic_init(struct radeon_device *rdev)
>> > break;
>> > }
>> > break;
>> > +#ifdef CONFIG_DRM_RADEON_CIK
>> > case CHIP_BONAIRE:
>> > case CHIP_HAWAII:
>> > rdev->asic = _asic;
>> > @@ -2679,6 +2691,7 @@ int radeon_asic_init(struct radeon_device *rdev)
>> > }
>> > rdev->has_uvd = true;
>> > break;
>> > +#endif
>> > default:
>> > /* FIXME: not supported yet */
>> > return -EINVAL;
>>
>>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/5640d707/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/36813eef/attachment-0001.html>
|Mesa
--
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/20160208/bd83a569/attachment.html>
On Sat, Feb 06, 2016 at 11:24:48AM +0800, Xinliang Liu wrote:
> Add ADE display controller binding doc.
> Add DesignWare DSI Host Controller v1.20a binding doc.
One comment, otherwise:
Acked-by: Rob Herring
> +Board specific:
> + {
> + status = "ok";
> +
> + ports
The drivers current default configuration drives the pixel data
on rising edge of the pixel clock. However, most display sample
data on rising edge... This leads to color shift artefacts visible
especially at edges.
This patch changes the relevant defines to be useful and actually
set the bits,
Introduce bus_flags to specify display bus properties like signal
polarities. This is useful for parallel display buses, e.g. to
specify the pixel clock or data enable polarity.
Suggested-by: Thierry Reding
Signed-off-by: Stefan Agner
---
include/drm/drm_crtc.h | 9 +
1 file changed, 9
The current default configuration is as follows:
- Invert VSYNC signal (active LOW)
- Invert HSYNC signal (active LOW)
The mode flags allow to specify the required polarity per
mode. Furthermore, none of the current driver settings is
actually a standard polarity.
This patch applies the current
Hi,
This is a new & split out version of the last patch of my
"drm/fsl-dcu: fixes and enhancements" patchset:
https://lkml.org/lkml/2015/11/18/949
Instead of using struct drm_display_mode to convey the pixel clock
polarity information, this patchset introduces a new field called
bus_flags stored
Hi Javier,
On 2016-02-08 13:03, Javier Martinez Canillas wrote:
> Hello Inki,
>
> On 01/29/2016 12:09 PM, Javier Martinez Canillas wrote:
>> Commit a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support
>> for panel") made the Exynos DP DT binding more consistent since the OF
>> graph
Hi.
With Linux 4.4 external HDMI-attached monitor in not discovered by i915
driver. Here is boot log related to drm and i915 for Linux 4.4/4.4.1
kernel:
===
kernel: [drm] Initialized drm 1.1.0 20060810
kernel: [drm] Memory usable by graphics device = 2048M
kernel: [drm] Replacing VGA console
Hi Archit,
Am Montag, 8. Februar 2016, 15:42:04 schrieb Archit Taneja:
> On 01/06/2016 09:33 AM, Chris Zhong wrote:
> > The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
> > IP. This series adds support for a Synopsys DesignWare MIPI DSI host
> > controller DRM driver.
> >
>
Hi Dave,
First drm-misc pull req for 4.6. Big one is the drm_event cleanup, which
is also prep work for adding android fence support to kms (Gustavo is
planning to do that). Otherwise random small bits all over.
Cheers, Daniel
The following changes since commit
I haven't seen this get picked up. Is there something wrong with the
patch or was it just lost in the noise?
On Thu, 3 Dec 2015 10:46:07 + John Keeping wrote:
> On Wed, 18 Nov 2015 13:58:23 +0100, Daniel Vetter wrote:
>
> > On Wed, Nov 18, 2015 at 11:17:25AM +, John Keeping wrote:
>
Hi Marek,
On 3 February 2016 at 12:42, Marek Szyprowski
wrote:
> Hello all,
>
> This patch series is a set of various fixes to get Exynos DRM working on
> Exynos 5433 SoCs and 64bit ARM64 architecture.
>
As you mentioned "64bit Exynos" devices, I'm wondering if you'll have
some input on the
On 02/08/2016 02:58 AM, Mario Kleiner wrote:
Now i just need to actually code and test it first.
>>>
>>> Ping, any news? :)
>>>
>
> Ok, so that series "drm vblank regression fixes for Linux 4.4+" i just
> sent out should hopefully fix this bug and related bugs.
Thanks, I'll test on Wed
Am 08.02.2016 um 03:45 schrieb Mike Lothian:
> This will allow us to disable CIK support in the radeon driver, so both
> radeon and amdgpu can be around at the same time without conflicting
>
> Signed-of-by: Mike Lothian
> ---
>
> I've tested this on my Kabini system radeon doesn't initalise when
|RESOLVED
--
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/20160208/aa759a48/attachment-0001.html>
On Mon, Feb 8, 2016 at 4:38 AM, Christian König
wrote:
> Am 07.02.2016 um 22:51 schrieb Matthew Dawson:
>>
>> When the radeon driver resets a gpu, it attempts to test whether all the
>> rings can successfully handle an IB. If these rings fail to respond, the
>> process will wait forever.
Am 07.02.2016 um 22:51 schrieb Matthew Dawson:
> When the radeon driver resets a gpu, it attempts to test whether all the
> rings can successfully handle an IB. If these rings fail to respond, the
> process will wait forever. Another gpu reset can't happen at this point,
> as the current reset
Hi Dave,
Back from lca, time to start the 4.6 release train! I'll follow up with
some drm-misc pull, too.
drm-intel-next-2016-01-24:
- support for v3 vbt dsi blocks (Jani)
- improve mmio debug checks (Mika Kuoppala)
- reorg the ddi port translation table entries and related code (Ville)
- reorg
egister_accessor_init(struct
> radeon_device *rdev)
> > rdev->pciep_rreg = _pciep_rreg;
> > rdev->pciep_wreg = _pciep_wreg;
> > }
> > +#else
> > + if (rdev->family >= CHIP_R600) {
> > + rdev->pciep_rreg = _pciep_rreg;
> > + rdev->pciep_wreg = _pciep_wreg;
> > + }
> > +#endif
> > }
> >
> > static int radeon_invalid_get_allowed_info_register(struct
> radeon_device *rdev,
> > @@ -2023,6 +2030,8 @@ static struct radeon_asic si_asic = {
> > },
> > };
> >
> > +#ifdef CONFIG_DRM_RADEON_CIK
> > +
> > static const struct radeon_asic_ring ci_gfx_ring = {
> > .ib_execute = _ring_ib_execute,
> > .ib_parse = _ib_parse,
> > @@ -2303,6 +2312,8 @@ static struct radeon_asic kv_asic = {
> > },
> > };
> >
> > +#endif
> > +
> > /**
> >* radeon_asic_init - register asic specific callbacks
> >*
> > @@ -2573,6 +2584,7 @@ int radeon_asic_init(struct radeon_device *rdev)
> > break;
> > }
> > break;
> > +#ifdef CONFIG_DRM_RADEON_CIK
> > case CHIP_BONAIRE:
> > case CHIP_HAWAII:
> > rdev->asic = _asic;
> > @@ -2679,6 +2691,7 @@ int radeon_asic_init(struct radeon_device *rdev)
> > }
> > rdev->has_uvd = true;
> > break;
> > +#endif
> > default:
> > /* FIXME: not supported yet */
> > return -EINVAL;
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/31ad885a/attachment-0001.html>
On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote:
> Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5.
>
> The main obstacle on these machines is that the panel mode in VBIOS
> is bogus. Fortunately gmux can switch DDC independently from the
> display, thereby
On Mon, Feb 01, 2016 at 09:11:51AM +0100, Patrik Jakobsson wrote:
> On Fri, Jan 29, 2016 at 8:37 PM, Alan wrote:
> > From: Alan Cox
> >
> > This is a left over from the great clean ups in the past. It's confusing as
> > it returns an int, yet has one caller that never uses it. The caller already
On Sat, Feb 06, 2016 at 06:09:13PM +0100, Patrik Jakobsson wrote:
> On Tue, Feb 2, 2016 at 7:05 AM, Sudip Mukherjee
> wrote:
> > We were getting build warning about:
> > drivers/gpu/drm/gma500/mdfld_dsi_output.c:407:2: warning: initialization
> > from incompatible pointer type
> >
> > The
On Wed, Feb 03, 2016 at 03:39:22PM +0100, Maarten Lankhorst wrote:
> Op 03-02-16 om 14:25 schreef Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > Turn sync_fence_info into __u64 type enable us to extend the struct in the
> > future without breaking the ABI.
> >
> > v2: use type __u64 for
dri-devel/attachments/20160208/20c90747/attachment.html>
ve lock sooner or later in
> radeon as well, but that really is a long term project.
>
> If you're really bored I can give you tons of input where to start with
> that.
That sounds like a good project to learn more about the driver, so I'd be
interested. I don't have a lot of time right now to play with it though. I
do want to finish off the tf2 crasher first as well. Once I have time I'll
poke the list to get started.
Thanks for the reviews!
--
Matthew
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/1729e5d3/attachment.sig>
Hello Marek,
On 02/08/2016 09:38 AM, Marek Szyprowski wrote:
> Hi Javier,
>
> On 2016-02-08 13:03, Javier Martinez Canillas wrote:
>> Hello Inki,
>>
>> On 01/29/2016 12:09 PM, Javier Martinez Canillas wrote:
>>> Commit a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support
>>> for panel")
Hello Inki,
On 01/29/2016 12:09 PM, Javier Martinez Canillas wrote:
> Commit a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support
> for panel") made the Exynos DP DT binding more consistent since the OF
> graph could be used to lookup either a panel or a bridge device node.
>
> Before
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160208/a0e57192/attachment.html>
On 02/07/2016 12:59 PM, Mario Kleiner wrote:
> I have a few simple patches which after testing seem to work well
> enough and fix additional similar problems with nouveau. Got
> distracted with other stuff last week. I'll try to send them out later
> today when i'm at the machine.
>
> -mario
>
>
>
This will allow us to disable CIK support in the radeon driver, so both
radeon and amdgpu can be around at the same time without conflicting
Signed-of-by: Mike Lothian
---
I've tested this on my Kabini system radeon doesn't initalise when compiled in
but
I do get these messages in my dmesg:
Make sure that drm_vblank_get/put() stay balanced in
case drm_vblank_get fails, by skipping the corresponding
put.
Signed-off-by: Mario Kleiner
Cc: michel at daenzer.net
Cc: dri-devel at lists.freedesktop.org
Cc: alexander.deucher at amd.com
Cc: christian.koenig at amd.com
---
The changes to drm_update_vblank_count() in Linux 4.4 added a
method to emulate a hardware vblank counter by use of high
precision vblank timestamps if a kms driver supports those,
but doesn't suppport hw vblank counters.
That method assumes that the old timestamp from a previous
invocation is
drm_vblank_offdelay can have three different types of values:
< 0 is to be always treated the same as dev->vblank_disable_immediate
= 0 is to be treated as "never disable vblanks"
> 0 is to be treated as disable immediate if kms driver wants it
that way via dev->vblank_disable_immediate.
Changes to drm_update_vblank_count() in Linux 4.4 broke the
behaviour of the pre/post modeset functions as the new update
code doesn't deal with hw vblank counter resets inbetween calls
to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it
should.
This causes mistreatment of such hw counter
This fixes a regression introduced by the new drm_update_vblank_count()
implementation in Linux 4.4:
Restrict the bump of the software vblank counter in drm_update_vblank_count()
to a safe maximum value of +1 whenever there is the possibility that
concurrent readers of vblank timestamps could be
Otherwise if a kms driver calls into drm_vblank_off() more than once
before calling drm_vblank_on() again, the redundant calls to
vblank_disable_and_save() will call drm_update_vblank_count()
while hw vblank counters and vblank timestamping are in a undefined
state during modesets, dpms off etc.
Here is the series of patches with fixes for regressions in vblank
counting/timestamping caused by the rewrite of drm_update_vblank_count
in Linux 4.4. These are all meant for stable 4.4 and later.
I have tested them on radeon-kms and nouveau-kms by unplugging/replugging
displays, manual dpms
61 matches
Mail list logo
