Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_pm.c
between commit:
1186fa85eb9b ("drm/i915/gen9: minimum scanlines for Y tile is not always 4")
from the drm-intel tree and commit:
bd2ef25d921c ("drm: Add drm_rotation_90_or_270()")
f
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/gpu/drm/i915/intel_drv.h:32:0,
from drivers/gpu/drm/i915/intel_display.c:36:
drivers/gpu/drm/i915/intel_display.c: In function 'intel_primary_pl
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/intel_display.c | 9 +
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c2a8df968b03..89d7
On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> 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
Reviewed-by: Chunming Zhou
> ---
> drive
---
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/da9235fe/attachment-0001.html>
Acked-by: Chunming Zhou
On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> 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 fen
On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> 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 tra
Acked-by: Chunming Zhou
On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
> 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 fence
On 10/22/2016 12:13 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote:
>>
>>
>> On 10/20/2016 02:45 PM, Russell King - ARM Linux wrote:
>>> On Thu, Oct 20, 2016 at 02:38:25PM +0530, Archit Taneja wrote:
On 10/20/2016 01:50 PM, Laure
On 10/21/2016 11:39 PM, Russell King - ARM Linux wrote:
> On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote:
>> 3) Rough conversion to bridge:
>
> So I thought I might give this a try, and see what's needed to complete
> the patch, but...
>
> I thought we'd got past the dark ages of e
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 04:45:39PM -0700, Manasi Navare wrote:
> > > > This function provides a
A recent change to the mm code in:
87744ab3832b83ba71b931f86f9cfdb000d07da5
mm: fix cache mode tracking in vm_insert_mixed()
started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this
This fixes a regression in all these drivers since the cache
mode tracking was fixed for mixed mappings. It uses the new
arch API to add the VRAM range to the PAT mapping tracking
tables.
Fixes: 87744ab3832 (mm: fix cache mode tracking in vm_insert_mixed())
Signed-off-by: Dave Airlie
---
drivers
On 24 October 2016 at 16:03, Dave Airlie wrote:
> I messed up one of the mailing lists last time (copied ancient
> address from another script).
>
Oops ignore both of those sets, forgot a git add, will repost once it
finish rebuild/boot cycle.
Dave.
On 10/22/2016 03:25 PM, Russell King - ARM Linux wrote:
> On Fri, Oct 21, 2016 at 09:04:39PM +0200, Jean-Francois Moine wrote:
>> On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
>> (sorry, I lost your original mail)
>> DRM bridges indeed don't create encoders. That
This is the working set, I messed up a git add on CONFIG_PAT vs
CONFIG_X86_PAT. This set of changes fixes a regression since
the change to the pfn_insert_mixed code to use the memtype tracking
code.
All the GPU drivers using TTM need to insert the VRAM mapping
into the memtype table so don't get U
As per Ingo's request I've cc'ed a bunch more x86/PAT people.
Dave.
This fixes a regression in all these drivers since the cache
mode tracking was fixed for mixed mappings. It uses the new
arch API to add the VRAM range to the PAT mapping tracking
tables.
Fixes: 87744ab3832 (mm: fix cache mode tracking in vm_insert_mixed())
Signed-off-by: Dave Airlie
---
drivers
On Sun, Oct 23, 2016 at 11:12:31PM -0700, Manasi Navare wrote:
> 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 1
I messed up one of the mailing lists last time (copied ancient
address from another script).
Dave.
A recent change to the mm code in:
87744ab3832b83ba71b931f86f9cfdb000d07da5
mm: fix cache mode tracking in vm_insert_mixed()
started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this
A recent change to the mm code in:
87744ab3832b83ba71b931f86f9cfdb000d07da5
mm: fix cache mode tracking in vm_insert_mixed()
started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this
On Mon, Oct 24, 2016 at 11:58:00AM +0530, Archit Taneja wrote:
> On 10/22/2016 03:25 PM, Russell King - ARM Linux wrote:
> > On Fri, Oct 21, 2016 at 09:04:39PM +0200, Jean-Francois Moine wrote:
> > > > > > > On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
> > > (sorry, I lost yo
On Mon, Oct 24, 2016 at 9:00 AM, Manasi Navare
wrote:
>> I guess we just need to do some additional work on top to make sure the
>> vblank ioctl can't see invalid state. Which would then again make upfront
>> link trainig possible ...
>
> Could you share some more details on what work would need t
Hi Dave,
First -misc pull for 4.10:
- drm_format rework from Laurent
- reservation patches from Chris that missed 4.9.
- aspect ratio support in infoframe helpers and drm mode/edid code
(Shashank Sharma)
- rotation rework from Ville (first parts at least)
- another attempt at the CRC debugfs in
ge tag 'topic/drm-misc-2016-10-11' of
git://anongit.freedesktop.org/drm-intel into drm-next (2016-10-12 06:07:38
+1000)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-10-24
for you to fetch changes up to 9558e74c26d2d63b9395f4d4153faa05f
hed to see the desktop running faster actually. ;)
--
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/20161024/e8b708d1/attachment.html>
Hi guys,
I'm getting a NULL ptr deref splat when hibernating my box with
4.9-rc1+. All I got so far is an ugly camera shot from the splat which
I'm typing in by hand.
Any ideas or already a fix?
The callstack looks like this:
unable to handle kernel NULL pointer dereference at 00...0890 (I thin
On 24/10/16 04:34 PM, Borislav Petkov wrote:
> Hi guys,
>
> I'm getting a NULL ptr deref splat when hibernating my box with
> 4.9-rc1+. All I got so far is an ugly camera shot from the splat which
> I'm typing in by hand.
>
> Any ideas or already a fix?
>
> The callstack looks like this:
>
> un
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/610c05a7/attachment.html>
Hello:
I am going to implement a EGL and DRM display for Rockchip VA-API
driver. We do have a EGL implementation in Rockchip VA-API driver, but
it is implemented in the standard way, we did that as a X11 display.
I didn't see the usage of struct VADriverVTableEGL in gstreamer, and
I have n
rthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/95fe196d/attachment.sig>
On Mon, Oct 24, 2016 at 9:25 AM, Daniel Vetter
wrote:
> Hi Dave,
>
> drm-intel-next-2016-10-24:
> - first slice of the gvt device model (Zhenyu et al)
> - compression support for gpu error states (Chris)
> - sunset clause on gpu errors resulting in dmesg noise telling users
> how to report them
On Mon, Oct 24, 2016 at 04:46:30PM +0900, Michel Dänzer wrote:
> Should be fixed in -rc2, specifically these commits:
>
> https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=b0c80bd5d2e317f7596fe2badc1a3379fb3211e5
> https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous
prototype for 'nvbios_fan_table' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:56:1: warning: no previous
prototype for 'nvbios_fan_entry' [-Wmiss
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous
prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous
prototype for 'nvkm_firmware_put' [-Wmissin
On Mon, Oct 24, 2016 at 08:33:10AM +0200, Daniel Vetter wrote:
> On Sun, Oct 23, 2016 at 11:12:31PM -0700, Manasi Navare wrote:
> > 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 0
* Dave Airlie wrote:
> On 24 October 2016 at 16:03, Dave Airlie wrote:
> > I messed up one of the mailing lists last time (copied ancient
> > address from another script).
> >
>
> Oops ignore both of those sets, forgot a git add, will repost once it
> finish rebuild/boot cycle.
Could you plea
ial nvidia/chip/
> directory
> > --
> > 2.7.4
> >
> > ___
> > Nouveau mailing list
> > Nouveau at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/c56ef8f4/attachment-0001.html>
ent was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/35494b47/attachment-0001.sig>
On Thu, Oct 20, 2016 at 03:22:12PM +0300, Jani Nikula wrote:
> Different subsystems and drivers have different preferences for where to
> file bugs and what information to include. Add "B:" entry for specifying
> the URI for the bug tracker directly, a web page for detailed info on
> filing bugs, o
Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).
Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.
Signed-off-by: Bartosz Golaszewski
---
v1 -> v2:
2016-10-21 19:14 GMT+02:00 Bartosz Golaszewski :
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev
2016-10-21 19:14 GMT+02:00 Bartosz Golaszewski :
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev
Op 21-10-16 om 16:17 schreef Ville Syrjälä:
> On Fri, Oct 21, 2016 at 05:05:16PM +0300, Ville Syrjälä wrote:
>> On Wed, Oct 19, 2016 at 03:55:36PM +0200, Maarten Lankhorst wrote:
>>> The only user was i915, which is now gone.
>>>
>>> Signed-off-by: Maarten Lankhorst
>> cc: dri-devel missing
>
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/0ae7d338/attachment.html>
Interesting catch, patch is Reviewed-by: Christian König
.
Am 24.10.2016 um 04:34 schrieb zhoucm1:
> Acked-by: Chunming Zhou
>
> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>> To free fences, call_rcu() is used, which calls amdgpu_fence_free()
>> after a grace period. During teardown,
Reviewed-by: Christian König
Am 24.10.2016 um 04:34 schrieb zhoucm1:
> Acked-by: Chunming Zhou
>
> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>> To free fences, call_rcu() is used, which calls amd_sched_fence_free()
>> after a grace period. During teardown, there is no guarantee all
>
Am 24.10.2016 um 04:32 schrieb zhoucm1:
>
>
> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>> 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 Ign
Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).
Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.
Signed-off-by: Bartosz Golaszewski
---
v1 -> v2:
Am 24.10.2016 um 04:25 schrieb zhoucm1:
>
>
> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>> 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 le
2016-10-24 10:43 GMT+02:00 Bartosz Golaszewski :
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev
>
>> /**
>> - * amd_sched_fence_release_scheduled - drop extra reference
>> + * amd_sched_fence_release_finished - drop extra reference
>>*
>>* @f: fence
>>*
>>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.fr
Am 24.10.2016 um 08:31 schrieb Dave Airlie:
> This fixes a regression in all these drivers since the cache
> mode tracking was fixed for mixed mappings. It uses the new
> arch API to add the VRAM range to the PAT mapping tracking
> tables.
>
> Fixes: 87744ab3832 (mm: fix cache mode tracking in vm_i
On 10/24/16 11:43, Bartosz Golaszewski wrote:
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev1
|--- |INVALID
--
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/20161024/99ecb00a/attachment.html>
sktop.org/archives/dri-devel/attachments/20161024/6066e100/attachment.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/6a33008e/attachment.html>
On Mon, Oct 24, 2016 at 6:35 AM, Qu, Jim wrote:
> I did observed the issue when replace kernel module use DKMS, and it maybe
> get error at reboot, got calltrace:
>
> [ 3529.525360]
> =
> [ 3529.525361] BUG amd_sched_fen
Am 22.10.2016 um 10:48 schrieb Baoyou Xie:
> We get a few warnings when building kernel with W=1:
> drivers/gpu/drm/amd/amdgpu/atombios_crtc.c:38:6: warning: no previous
> prototype for 'amdgpu_atombios_crtc_overscan_setup' [-Wmissing-prototypes]
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c:661:6: warn
On Mon, Oct 24, 2016 at 12:13 PM, Christian König
wrote:
> Am 24.10.2016 um 04:25 schrieb zhoucm1:
>>
>>
>>
>> On 2016å¹´10æ24æ¥ 02:31, Grazvydas Ignotas wrote:
>>>
>>> It's done in amd_sched_hw_job_reset(), but not in normal job processing.
>>> Leak reported by CONFIG_SLUB_DEBUG.
>>>
>>> Sign
Am 23.10.2016 um 01:05 schrieb Lucas Stach:
> 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 t
2016-10-24 11:25 GMT+02:00 Jyri Sarha :
> On 10/24/16 11:43, Bartosz Golaszewski wrote:
>> Revision 1 of the IP doesn't work if we don't load the palette (even
>> if it's not used, which is the case for the RGB565 format).
>>
>> Add a function called from tilcdc_crtc_enable() which performs all
>>
We need to explicitly disable our planes, so don't set the flag which
would otherwise skip the plane disable when the CRTC is disabled.
Signed-off-by: Brian Starkey
---
drivers/gpu/drm/arm/malidp_drv.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/m
On Mon, Oct 24, 2016 at 10:52:28AM +0100, Brian Starkey wrote:
> We need to explicitly disable our planes, so don't set the flag which
> would otherwise skip the plane disable when the CRTC is disabled.
>
> Signed-off-by: Brian Starkey
Acked-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/malidp_
ts job properly, the IP will get reset
when the IP is suspended. I'm quite sure it won't retain any palettes.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/5e3e6a0e/attachment-0001.sig>
Hi Ville,
On 10/22/2016 12:52 AM, 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.
I was trying to test this on msm/drm using modetest. The 180 rotation
works fine, but drm r
t all modes coming
from the EDID even have actual detailed timing descriptors.
--
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/
On Saturday, October 22, 2016 5:17:45 PM CEST Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/msm/msm_debugfs.c:141:5: warning: no previous prototype for
> 'msm_debugfs_init' [-Wmissing-prototypes]
> drivers/gpu/drm/msm/msm_debugfs.c:158:6: warning: no previo
On Saturday, October 22, 2016 5:14:42 PM CEST Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/gpu/drm/i2c/tda998x_drv.c:1292:5: warning: no previous prototype for
> 'tda998x_audio_digital_mute' [-Wmissing-prototypes]
>
> In fact, this function is only used in the fil
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/4e633fcc/attachment.html>
On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:
> Hi Ville,
>
> On 10/22/2016 12:52 AM, 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.
>
>
> I was tr
On Saturday, October 22, 2016 5:13:01 PM CEST Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/arm/malidp_planes.c:49:25: warning: no previous prototype for
> 'malidp_duplicate_plane_state' [-Wmissing-prototypes]
> drivers/gpu/drm/arm/malidp_planes.c:66:6: war
On 10/24/2016 03:45 PM, Ville Syrjälä wrote:
> On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:
>> Hi Ville,
>>
>> On 10/22/2016 12:52 AM, ville.syrjala at linux.intel.com wrote:
>>> From: Ville Syrjälä
>>>
>>> The global mode_config.rotation_property is going away, switch over
On Mon, Oct 24, 2016 at 03:52:09PM +0530, Archit Taneja wrote:
>
>
> On 10/24/2016 03:45 PM, Ville Syrjälä wrote:
> > On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:
> >> Hi Ville,
> >>
> >> On 10/22/2016 12:52 AM, ville.syrjala at linux.intel.com wrote:
> >>> From: Ville Syrjäl
On 10/24/2016 03:55 PM, Ville Syrjälä wrote:
> On Mon, Oct 24, 2016 at 03:52:09PM +0530, Archit Taneja wrote:
>>
>>
>> On 10/24/2016 03:45 PM, Ville Syrjälä wrote:
>>> On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:
Hi Ville,
On 10/22/2016 12:52 AM, ville.syrjala
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/471d5d74/attachment.html>
Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).
Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.
Signed-off-by: Bartosz Golaszewski
---
v1 -> v2:
2016-10-24 11:13 GMT+02:00 Bartosz Golaszewski :
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev
On 21 October 2016 at 18:12, Eric Anholt wrote:
> glxgears was spamming this 12 times at startup because of Mesa's
> probing of the DRM device code, which doesn't support platform
> devices.
>
Better option is to add support for platform devices. Can we get
anyone interested in that ?
If we drop (
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/619e663c/attachment.html>
Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
intermediate edid reads. This causes transient failures in CI which
flags up the sporadic EDID read failures, which are recovered by
rereading the EDID automatically. This patch combines the reporting done
by drm_do_get_edid() it
On Mon, Oct 24, 2016 at 12:33:41PM +0100, Chris Wilson wrote:
> for (j = 1; j <= edid[0x7e]; j++) {
> - u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
> + u8 *block = edid + j * EDID_LENGTH;
>
> for (i = 0; i < 4; i++) {
>
Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
intermediate edid reads. This causes transient failures in CI which
flags up the sporadic EDID read failures, which are recovered by
rereading the EDID automatically. This patch combines the reporting done
by drm_do_get_edid() it
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/d7794822/attachment.html>
Am Freitag, den 21.10.2016, 16:49 +0800 schrieb Ying Liu:
> On Fri, Oct 21, 2016 at 4:18 PM, Philipp Zabel
> wrote:
> > Am Freitag, den 21.10.2016, 13:45 +0800 schrieb Ying Liu:
> >> On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel
> >> wrote:
> >> > Am Donnerstag, den 20.10.2016, 16:51 +0800 sch
Hi David,
I am currently investigating:
https://bugs.freedesktop.org/show_bug.cgi?id=96572
Martin Peres suggested that your patches:
https://lists.freedesktop.org/archives/dri-devel/2014-September/thread.html#67984
could solve the xf86-video-modesetting backlight issues.
I have rebased your patc
From: David Herrmann
Use static initializers instead of setting up global variables during
runtime. This reduces code size and execution time.
Signed-off-by: David Herrmann
---
drivers/video/backlight/backlight.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/driv
From: David Herrmann
There is really no reason to use a mutex to protect a simple list. Convert
the list-lock to a simple spinlock instead.
The spin-locks prepare for a backlight_find() helper, which should
preferably be usable from atomic context. A mutex would prevent that, so
use an irq-save
From: David Herrmann
So far backlights have only been controlled via sysfs. However, sysfs is
not a proper user-space API for runtime modifications, and never was
intended to provide such. The DRM drivers are now prepared to provide
such a backlight link so user-space can control backlight via DR
From: David Herrmann
Backlight devices have always been managed independently of display
controllers. They're often controlled via different hardware interfaces
and their relationship to display-controllers varies vastly between
different boards. However, display brightness is obviously a propert
The brightness property was set with the incoming value
instead of the calculated value.
Signed-off-by: Marta Lofstedt
---
drivers/gpu/drm/drm_backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_backlight.c b/drivers/gpu/drm/drm_backlight.c
index 9
Use the drm backlight class.
Signed-off-by: Marta Lofstedt
---
drivers/gpu/drm/i915/intel_panel.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index be4b4d5..0765b4c 100644
--- a/drivers/gpu/drm/i915/intel_panel
https://bugzilla.kernel.org/show_bug.cgi?id=178421
--- Comment #3 from Jouni Mettälä ---
Created attachment 242511
--> https://bugzilla.kernel.org/attachment.cgi?id=242511&action=edit
recent picture of panic
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 10/19/16 13:28, Russell King wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King
Acked-by: Jyri Sarha
Reviewed-by: Jyri Sarha
However, the patch description is a bit brief. It took me this mail
thread to fully understand why simple c
https://bugzilla.kernel.org/show_bug.cgi?id=178421
--- Comment #4 from Jouni Mettälä ---
I still get oops on 4.9-rc2. Picture is attached. It looks different than
already fixed bug, for me at least.
Kevin, you have probably different bug. Reboot doesn't work for me. What is
last known good ker
Hi Russell,
On Sat, Oct 22, 2016 at 02:40:22PM +0100, Russell King - ARM Linux wrote:
>On Wed, Oct 19, 2016 at 10:46:48AM +0100, Brian Starkey wrote:
>> Hi Jyri,
>>
>> I believe this will break mali-dp and hdlcd, unless something changed
>> while I wasn't looking. Please see this previous thread w
On Mon, Oct 24, 2016 at 12:14:14PM +0200, Arnd Bergmann wrote:
> On Saturday, October 22, 2016 5:14:42 PM CEST Baoyou Xie wrote:
> > We get 1 warning when building kernel with W=1:
> > drivers/gpu/drm/i2c/tda998x_drv.c:1292:5: warning: no previous prototype
> > for 'tda998x_audio_digital_mute' [-W
Connectors shouldn't be registered until the rest of the whole device
is set up, so that consistent state is presented to userspace.
As such, remove the calls to drm_connector_register() and
drm_connector_unregister() from tda998x, as these are now handled by
drm_dev_(un)register() itself.
To wor
On Mon, Oct 24, 2016 at 12:13:40PM +0200, Arnd Bergmann wrote:
> On Saturday, October 22, 2016 5:17:45 PM CEST Baoyou Xie wrote:
> > We get 2 warnings when building kernel with W=1:
> > drivers/gpu/drm/msm/msm_debugfs.c:141:5: warning: no previous prototype for
> > 'msm_debugfs_init' [-Wmissing-pr
1 - 100 of 175 matches
Mail list logo
