https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #13 from Jimi ---
That's interesting. My pwm1_enable returns 1, and trying to change it to 0 or 2
does nothing, but my pwm1 value does indeed change on its own, and I've never
seen it be 0. It sounds like I don't have this bug but do
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #14 from Jimi ---
I should mention, my pwm1_min is 0 and pwm1_max is 255.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Fix some comment faults in gtt.c.
Signed-off-by: Jiang Biao
---
drivers/gpu/drm/gma500/gtt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 8f69225..9f9f588 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/dr
Fix some comment faults in gtt.c.
Signed-off-by: Jiang Biao
---
drivers/gpu/drm/gma500/gtt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 8f69225..9f9f588 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/dr
Fix some comment faults in gtt.c.
Signed-off-by: Jiang Biao
---
drivers/gpu/drm/gma500/gtt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 8f69225..9f9f588 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/d
arameters. */
After that speed was 'normal'.
--
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/20160810/b100e30f/attachment.html>
drivers/devfreq/rk3399_dmc.c:393:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Lin Huang
Signed-off-by: Fengguang Wu
---
rk3399_dmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/devfreq/rk3399_dmc.c
/linux/commits/Lin-Huang/rk3399-support-ddr-frequency-scaling/20160810-114433
coccinelle warnings: (new ones prefixed by >>)
>> drivers/devfreq/rk3399_dmc.c:393:2-3: Unneeded semicolon
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure
ou 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/20160810/e8d32ae8/attachment.html>
/commits/Lin-Huang/rk3399-support-ddr-frequency-scaling/20160810-114433
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #15 from Stas Sergeev ---
> I should mention, my pwm1_min is 0 and pwm1_max is 255.
Same here.
IMHO pwm1_min should contain the value that
keeps the fan rotating at a minimal safe speed.
Putting 0 there makes it entirely useless.
--
Hi CK,
On Fri, 2016-08-05 at 18:24 +0800, CK Hu wrote:
> Hi, YT:
>
> On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> > From: shaoming chen
> >
> > add dsi interrupt control
> >
> > Signed-off-by: shaoming chen
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 76
> > +++
Hi CK,
On Fri, 2016-08-05 at 18:08 +0800, CK Hu wrote:
> Hi, YT:
>
> On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> > From: shaoming chen
> >
> > add dsi read/write commands for transfer function
> >
> > Signed-off-by: shaoming chen
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 261
Hi CK,
On Fri, 2016-08-05 at 14:36 +0800, CK Hu wrote:
> Hi, YT:
>
> On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> > This patch add support for the Mediatek MT2701 DISP subsystem.
> > There is only one OVL engine in MT2701.
> >
> > Signed-off-by: YT Shen
> > ---
> > drivers/gpu/drm/media
Hi CK,
On Fri, 2016-08-05 at 14:18 +0800, CK Hu wrote:
> Hi, YT:
>
> On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> > This patch adds the device nodes for the DISP function blocks for MT2701
> >
> > Signed-off-by: YT Shen
> > ---
> > arch/arm/boot/dts/mt2701.dtsi | 86
> > +
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160810/eb72e0a7/attachment.html>
Hi Ville,
On Fri, 22 Jul 2016 18:47:01 +0300
ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> The global mode_config.rotation_property is going away, switch over to
> per-plane rotation_property.
>
> v2: Propagate error upwards (Boris)
>
> Cc: Boris Brezillon
> Signed-off-
On Wed, Aug 10, 2016 at 11:35:14AM +0800, jiang.biao2 at zte.com.cn wrote:
>
> Fix some comment faults in gtt.c.
>
> Signed-off-by: Jiang Biao
Sending the same patch 3 times in just one hour doesn't help - people
sometimes sleep, or are busy. Please let at least a few days pass until
you ping (
On Tue, Aug 09, 2016 at 02:52:43PM -0500, Scot Doyle wrote:
> On Tue, 9 Aug 2016, Daniel Vetter wrote:
> > On Tue, Aug 9, 2016 at 9:28 PM, Scot Doyle wrote:
> > > On Tue, 9 Aug 2016, Daniel Vetter wrote:
> > >> So if you want the kernel to VT-switch, then imo just enable CONFIG_VT.
> > >> It
> >
On Tue, Aug 09, 2016 at 07:45:40PM +0200, Noralf Trønnes wrote:
> This adds a way for in-kernel users to iterate over the available
> DRM minors. The implementation is oops safe so the panic code
> can safely use it.
>
> Signed-off-by: Noralf Trønnes
Why iterate over minors? I'd kinda have exp
Daniel Vetter wrote on 2016/08/10 16:35:29:
> Daniel Vetter
> From: Daniel Vetter
>
> 2016/08/10 16:35
>
>
> jiang.biao2 at zte.com.cn,
>
>
> Re: [RESEND PATCH] drm/gma500: Fix comments in gtt.c
>
> On Wed, Aug 10, 2016 at 11:35:14AM +0800, jiang.biao2 at zte.com.cn wrote:
> >
> > Fix some co
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #16 from Jimi ---
Not necessarily. Less fans means less power usage means money saved, and as we
can see with my computer, you can keep the card cool without its own fans. I
have 4 case fans that are plugged directly into power and so
/commits/Lin-Huang/rk3399-support-ddr-frequency-scaling/20160810-114433
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by
/commits/Lin-Huang/rk3399-support-ddr-frequency-scaling/20160810-114433
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by
On Wed, Aug 10, 2016 at 10:35:22AM +0200, Boris Brezillon wrote:
> Hi Ville,
>
> On Fri, 22 Jul 2016 18:47:01 +0300
> ville.syrjala at linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > The global mode_config.rotation_property is going away, switch over to
> > per-plane rotation_propert
On Tue, Aug 09, 2016 at 07:45:41PM +0200, Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> The drivers that supports it, provides a framebuffer that the
> messages can be rendered on.
>
> Signed-off-by: Noralf Trønnes
Thinking about how we should implement
On Wed, Aug 10, 2016 at 11:15:29AM +0200, Daniel Vetter wrote:
> On Tue, Aug 09, 2016 at 07:45:41PM +0200, Noralf Trønnes wrote:
> > This adds support for outputting kernel messages on panic().
> > The drivers that supports it, provides a framebuffer that the
> > messages can be rendered on.
> >
On Wed, Aug 10, 2016 at 04:52:53PM +0800, jiang.biao2 at zte.com.cn wrote:
>
>
> Daniel Vetter wrote on 2016/08/10 16:35:29:
>
> > Daniel Vetter
> > From: Daniel Vetter
> >
> > 2016/08/10 16:35
> >
> >
> > jiang.biao2 at zte.com.cn,
> >
> >
> > Re: [RESEND PATCH] drm/gma500: Fix comments in g
On Wed, 10 Aug 2016 12:09:41 +0300
Ville Syrjälä wrote:
> On Wed, Aug 10, 2016 at 10:35:22AM +0200, Boris Brezillon wrote:
> > Hi Ville,
> >
> > On Fri, 22 Jul 2016 18:47:01 +0300
> > ville.syrjala at linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > The global mode_confi
These pixel formats are supported by format_check() from drm_crtc.c, so
provide there depth and bpp.
Signed-off-by: Fabien Dessenne
---
drivers/gpu/drm/drm_fourcc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index
it's OK for Alex.
--
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/20160810/d222a267/attachment.html>
On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
> These pixel formats are supported by format_check() from drm_crtc.c, so
> provide there depth and bpp.
>
> Signed-off-by: Fabien Dessenne
Why? Who's going to use this?
-Daniel
> ---
> drivers/gpu/drm/drm_fourcc.c | 11 +
When generating events for a atomic commit involving multiple crtc's
it's not possible to distinguish which crtc belongs to which page flip event.
Solve this by putting crtc_id in the reserved member of page_flip_event.
I've checked weston, and the following ddx: modesetting (xserver), i915,
nouve
When doing a atomic commit affecting multiple crtc's, multiple events
are generated. The user_data member does not allow you to distinguish,
because they all have the same pointer.
I've chosen to use crtc_id, because using pipe would create ambiguity
when pipe = 0. A test for != 0 is easier to imp
Add a page_flip_handler2 member to drmEventContext and bump
DRM_EVENT_CONTEXT.
To make sure that the new api works as intended, modetest is
changed to use it.
Signed-off-by: Maarten Lankhorst
Cc: David Airlie
Cc: Daniel Stone
---
include/drm/drm.h | 2 +-
tests/modetest/modetest.c |
lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20160810/f7adadd9/attachment.html>
On 08/10/2016 12:35 PM, Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
>> These pixel formats are supported by format_check() from drm_crtc.c, so
>> provide there depth and bpp.
>>
>> Signed-off-by: Fabien Dessenne
> Why?
At least for consistency between f
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160810/7331416e/attachment.html>
On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> On Wed, 10 Aug 2016 12:09:41 +0300
> Ville Syrjälä wrote:
>
> > On Wed, Aug 10, 2016 at 10:35:22AM +0200, Boris Brezillon wrote:
> > > Hi Ville,
> > >
> > > On Fri, 22 Jul 2016 18:47:01 +0300
> > > ville.syrjala at linux.intel.
On Wed, 10 Aug 2016 14:41:52 +0300
Ville Syrjälä wrote:
> On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> > On Wed, 10 Aug 2016 12:09:41 +0300
> > Ville Syrjälä wrote:
> >
> > > On Wed, Aug 10, 2016 at 10:35:22AM +0200, Boris Brezillon wrote:
> > > > Hi Ville,
> > > >
On Wed, 10 Aug 2016 13:52:45 +0200
Boris Brezillon wrote:
> On Wed, 10 Aug 2016 14:41:52 +0300
> Ville Syrjälä wrote:
>
> > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> > > On Wed, 10 Aug 2016 12:09:41 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Wed, Aug
On 08/09/2016 04:08 PM, Daniel Vetter wrote:
> On Tue, Aug 9, 2016 at 3:59 PM, Thomas Hellstrom
> wrote:
>> Hmm.
>>
>> I don't have a strong opinion on this, but IMO the original idea of
>> allowing a user-space driver to optimize away the dirty calls isn't a
>> bad one.
>> Since the xf86-video-v
By request forwarded patch
This is also
Reviewed-by: Thomas Hellstrom
/Thomas
Forwarded Message
Subject:[PATCH] kref: prefer atomic_inc_not_zero to atomic_add_unless
Date: Sat, 10 Oct 2015 12:56:34 +0200
From: Jason A. Donenfeld
To: Dave Airlie , Thomas Hells
https://bugzilla.kernel.org/show_bug.cgi?id=151831
--- Comment #6 from Alex Deucher ---
Bisecting is a process for determining which specific commit in a project
caused a regression. Google for "linux kernel git bisect howto".
--
You are receiving this mail because:
You are watching the assign
On Wed, Aug 10, 2016 at 01:52:45PM +0200, Boris Brezillon wrote:
> On Wed, 10 Aug 2016 14:41:52 +0300
> Ville Syrjälä wrote:
>
> > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> > > On Wed, 10 Aug 2016 12:09:41 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Wed, Aug
On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
>
> On 08/10/2016 12:35 PM, Daniel Vetter wrote:
> > On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
> >> These pixel formats are supported by format_check() from drm_crtc.c, so
> >> provide there depth and bpp.
> >>
On Wed, Aug 10, 2016 at 12:46:23PM +0200, Maarten Lankhorst wrote:
> When doing a atomic commit affecting multiple crtc's, multiple events
> are generated. The user_data member does not allow you to distinguish,
> because they all have the same pointer.
>
> I've chosen to use crtc_id, because usin
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> While reviewing docs I spotted that we have a few functions that
> really just don't fit into their containing helper library section.
> Extract them and shovel them all into a new library for random one-off
> aux stuff.
>
> Signed-off-by: Dan
Den 10.08.2016 10:43, skrev Daniel Vetter:
> On Tue, Aug 09, 2016 at 07:45:40PM +0200, Noralf Trønnes wrote:
>> This adds a way for in-kernel users to iterate over the available
>> DRM minors. The implementation is oops safe so the panic code
>> can safely use it.
>>
>> Signed-off-by: Noralf Trø
Rebased version of https://patchwork.freedesktop.org/series/10276/ . No changes
Lyude (5):
drm/i915/skl: Add support for the SAGV, fix underrun hangs
drm/i915/skl: Update plane watermarks atomically during plane updates
drm/i915/skl: Ensure pipes with changed wms get added to the state
drm
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: stable at vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: R
Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for sta
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_
Rebased version of https://patchwork.freedesktop.org/series/10276/ . No changes
Lyude (5):
drm/i915/skl: Add support for the SAGV, fix underrun hangs
drm/i915/skl: Update plane watermarks atomically during plane updates
drm/i915/skl: Ensure pipes with changed wms get added to the state
drm
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: stable at vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: R
Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for sta
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_
On Wed, Aug 10, 2016 at 4:27 PM, Noralf Trønnes wrote:
> Den 10.08.2016 10:43, skrev Daniel Vetter:
>>
>> On Tue, Aug 09, 2016 at 07:45:40PM +0200, Noralf Trønnes wrote:
>>>
>>> This adds a way for in-kernel users to iterate over the available
>>> DRM minors. The implementation is oops safe so t
On Wed, Aug 10, 2016 at 4:23 PM, Sean Paul wrote:
> Is there a reason we create drm_kms_helper.c/h in patch 2 and then
> rename it in patch 3? Could you squash this?
My own incompetence ;-) It's already squashed here in my tree.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> Also start with drm_modeset.h with the core bits, since we need
> to untangle this mess somehow. That allows us to move the drm_modes.h
> include to the right spot, except for the temporary connector status
> enum. That will get fixed as soon
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> - Move the intro section into a DOC comment, and update it slightly.
> - kernel-doc for struct drm_framebuffer!
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 26 +--
> drivers/gpu/drm/drm_framebuffer.c
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> Pulls in quite a lot of connector related structures (cmdline mode,
> force/status enums, display info), but I think that all makes perfect
> sense.
>
> Also had to move a few more core kms object stuff into drm_modeset.h.
>
> And as a first c
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> They're only used internally within the dp helpers. Also nuke the
> kerneldoc (we only document the driver interface in the drm shared
> functions). And move the header file from the public include/
> directory to the source files into drm_crt
We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common under
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> - Shuffle docs from drm-kms.rst into the structure docs where it makes
> sense.
> - Put the remaining bits into a new overview section.
>
> One thing I've changed is around probing: Old docs says that you
> _must_ use the probe helpers, whic
On Tue, Aug 09, 2016 at 03:41:23PM +0200, Daniel Vetter wrote:
> - Move the intro section into a DOC comment, and update it slightly.
> - kernel-doc for struct drm_framebuffer!
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/drm-kms.rst | 26 +--
> drivers/gpu/drm/drm_fram
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> We seem to have a bit a mess in how to describe the bus formats, with
> a multitude of competing ways. Might be best to consolidate it all and
> use MEDIA_BUS_FMT_ also for the hdmi color formats and high color
> modes.
>
> Also move all the d
On Tue, Aug 9, 2016 at 9:50 AM, Daniel Vetter wrote:
> Move the documentation into Documentation/gpu, link it up and pull in
> the kernel doc.
>
> No actual text changes except that I did polish the kerneldoc a bit,
> especially for vga_client_register().
>
> v2: Remove some rst from vga-switchero
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> First part is just a bit of rst fallout to make drm doc builds warning free.
> But
> then I started to split out parts of drm_crtc into their own files.
> framebuffers
> and connectors are done, next up on my plans are encoders, and then the
On 08/10/2016 04:12 PM, Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
>> On 08/10/2016 12:35 PM, Daniel Vetter wrote:
>>> On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
These pixel formats are supported by format_check() from drm_crt
On Wed, 10 Aug 2016 16:04:37 +0200
Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 01:52:45PM +0200, Boris Brezillon wrote:
> > On Wed, 10 Aug 2016 14:41:52 +0300
> > Ville Syrjälä wrote:
> >
> > > On Wed, Aug 10, 2016 at 11:25:03AM +0200, Boris Brezillon wrote:
> > > > On Wed, 10 Aug 2016
0-day has been annoying me lately with a constant trickle of build failures with
a few drivers when DRM_FBDEV_EMULATION is not set. This series here should fix
them all I hope.
-Daniel
Daniel Vetter (5):
drm/fb-helper: Add a dummy remove_conflicting_framebuffers
drm: Remove superflous linux/fb
Lots of drivers don't properly compile without this when CONFIG_FB=n.
It's kinda a hack, but since CONFIG_FB doesn't stub any fucntions when
it's disabled I think it makes sense to add it to drm_fb_helper.h.
Long term we probably need to rethink all the logic to unload firmware
framebuffer drivers
Everyone who uses the fbdev emulation helpers doesn't need to include
fb.h directly. Remove it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 1 -
drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c| 1 -
drivers/gpu/drm/amd/powerplay/hwm
vmwgfx doesn't actually build without that.
It would be great if vmwgfx could switch over to the fbdev emulation
helpers, since those will take care of all this already. I guess one
reason to not do that was lack of defio support in the helpers, but
that's fixed now. If there's any other hold-up,
Seems to at least compile fine, only change needed was to use
the fb_set_suspend helper.
Cc: alexander.deucher at amd.com
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Kconfig| 8
drivers/gpu/drm/radeon/radeon_fb.c | 2 +-
2 files changed, 1 insertion(+), 9 deletions(-)
For reasons that entirely elude me fb.h exposes all the structures,
even when it is not enabled. Except for special stuff like fb_defio.
Which means all the drivers which haven't yet switched over to the
defio support in the helpers and still roll their own, will fail
to compile when fbdev emulati
On Wed, Aug 10, 2016 at 5:26 PM, Fabien DESSENNE
wrote:
> On 08/10/2016 04:12 PM, Daniel Vetter wrote:
>> On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
>>> On 08/10/2016 12:35 PM, Daniel Vetter wrote:
On Wed, Aug 10, 2016 at 11:21:56AM +0200, Fabien Dessenne wrote:
> T
On Wed, Aug 10, 2016 at 06:57:02PM +0200, Daniel Vetter wrote:
> On Wed, Aug 10, 2016 at 5:26 PM, Fabien DESSENNE
> wrote:
> > On 08/10/2016 04:12 PM, Daniel Vetter wrote:
> >> On Wed, Aug 10, 2016 at 01:04:54PM +0200, Fabien DESSENNE wrote:
> >>> On 08/10/2016 12:35 PM, Daniel Vetter wrote:
> >>
Hello Shuah,
On 08/08/2016 07:48 PM, Shuah Khan wrote:
> Fix unsupported GEM memory type error message to include the memory type
> information.
>
> Signed-off-by: Shuah Khan
> ---
> Changes since v1:
> -- Comment changed to read clearly
>
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +++---
>
Hi Dave,
A few fixes for 4.8:
- revert temporary workarounds for PX now that the d3cold stuff as landed
- fix bugs in a couple of error paths
The following changes since commit 36e9d08b58f44c3a02974c405ccaaa6ecfaf05b8:
drm/cirrus: Fix NULL pointer dereference when registering the fbdev
(2016-
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160810/68bd6cbf/attachment.html>
On Tue, Aug 9, 2016 at 7:30 AM, Wolfram Sang
wrote:
> The core will do this for us now.
>
> Signed-off-by: Wolfram Sang
Applied patches 1, 5.
Thanks,
Alex
> ---
> drivers/gpu/drm/radeon/radeon_i2c.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/
On Wed, Aug 10, 2016 at 12:52 PM, Daniel Vetter
wrote:
> 0-day has been annoying me lately with a constant trickle of build failures
> with
> a few drivers when DRM_FBDEV_EMULATION is not set. This series here should fix
> them all I hope.
> -Daniel
>
> Daniel Vetter (5):
> drm/fb-helper: Add
s 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/20160810/d40971b8/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=119211
--- Comment #17 from Stas Sergeev ---
> Not necessarily. Less fans means less power usage means money saved
You can set up fancontrol or put 0 into pwm1 manually
to stop the fan. But putting 0 into pwm1_min is IMHO
quite useless, it can as well
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160810/aac43116/attachment.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160810/3753d7be/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160810/fdbf8d08/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160810/217e18c0/attachment.html>
--
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/20160810/d3a794f4/attachment-0001.html>
the attachment. I see eight
Tuxes and and a couple lines output but it won't go further. :/
--
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/archiv
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160810/f7616a67/attachment.html>
On Tue 2016-08-09 08:04:54, Daniel Vetter wrote:
> On Sun, Jul 24, 2016 at 05:00:31PM +0200, Pavel Machek wrote:
> > On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote:
> > > 2016-08-07 Pavel Machek :
> > >
> > > > On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> > > > > On Mon, Jul 18, 2016
1 - 100 of 138 matches
Mail list logo
