The read is taking a considerable amount of time (about 50us on this
machine). The register does not ever hold anything other than the ring
ID that is updated in this exact function, so there is no need for
the read modify write cycle.
This chops off a big chunk of the time spent in hardirq disabl
Am Montag, den 24.10.2016, 12:41 -0400 schrieb Alex Deucher:
> On Mon, Oct 24, 2016 at 5:46 AM, Christian König
> wrote:
> >
> > Am 23.10.2016 um 01:05 schrieb Lucas Stach:
> > >
> > >
> > > The current default of always using the performance power state
> > > leads
> > > to increased power co
From: Colin Ian King
Fix trivial spelling mistake cant't -> can't and add KERN_WARNING to
printk messages.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c | 4 ++--
drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 4 ++--
drivers/gpu/drm/amd/powerpl
On Sat, Oct 22, 2016 at 10:48:13AM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 04:45:40PM -0700, Manasi Navare wrote:
> > This work struct will be used to schedule a uevent on a separate
> > thread. This will be scheduled after a link train failure during modeset
> > to indicate a modeset
On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote:
> @@ -1341,7 +1341,7 @@ int smu7_disable_dpm_tasks(struct pp_hwmgr *hwmgr)
> return result;
> }
>
> -int smu7_reset_asic_tasks(struct pp_hwmgr *hwmgr)
> +static int smu7_reset_asic_tasks(struct pp_hwmgr *hwmgr)
> {
>
>
[Detailed post, but please give it a quick scan.]
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> > start.
>
> That would be between v4.7 and v4.8. (I gues
On Monday, October 24, 2016 8:07:16 PM CEST Deucher, Alexander wrote:
> > > > In fact, these functions are only used in the file in which they are
> > > > declared and don't need a declaration, but can be made static.
> > > > So this patch marks these functions with 'static'.
> > > >
> > > > Signed
On Mon, Oct 24, 2016 at 4:52 PM, Brian Starkey wrote:
>>
>>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
>>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>>> index f4315bc..6e6fca2 100644
>>> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
>>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>>> @@ -1369,7 +1369,6 @@ co
On Monday, October 24, 2016 12:36:52 PM CEST Alex Deucher wrote:
> On Sat, Oct 22, 2016 at 4:56 AM, Baoyou Xie wrote:
> > We get a few warnings when building kernel with W=1:
> > drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:162:5:
> > warning: no previous prototype for 'fiji_setup
In the loop on .timings, we should check .num_timings to see if it's the
only mode specified, not .num_modes, which should be used with .modes.
Fixes: cda553725c92 ("drm/panel: simple: Set appropriate mode type")
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file
On Mon, Oct 24, 2016 at 03:57:10PM -0400, Rob Clark wrote:
> Signed-off-by: Rob Clark
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
https://bugzilla.kernel.org/show_bug.cgi?id=181401
--- Comment #1 from blesk2 at gmail.com ---
Created attachment 242601
--> https://bugzilla.kernel.org/attachment.cgi?id=242601&action=edit
Photo of display
xrandr --output DisplayPort-0 --mode 2560x2880 --right-of DisplayPort-1
--output Display
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/9e7b806a/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=181401
Bug ID: 181401
Summary: Radeon and 5k resolution 5120x2880
Product: Drivers
Version: 2.5
Kernel Version: 4.8.4
Hardware: All
OS: Linux
Tree: Mainline
op.org/archives/dri-devel/attachments/20161024/5779a78b/attachment.html>
On Mon, 24 Oct 2016, Imre Deak wrote:
> This check is open-coded in a few places, so it makes sense to simplify
> things by having a helper for it similar to the rest of DPCD feature
> helpers.
>
> v2: (Jani)
> - Move the helper to drm_dp_helper.h.
> - Split out this change to a separate patch.
>
sy way to test this locally?
--
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/c8d5d939/attachment-0001.html>
> -Original Message-
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Monday, October 24, 2016 3:49 PM
> To: Alex Deucher
> Cc: Baoyou Xie; Deucher, Alexander; Dave Airlie; Zhu, Rex; Zhou, Jammy;
> Huang, JinHuiEric; StDenis, Tom; Edward O'Callaghan; Prosyak, Vitaly; Yang,
> Eric; Ya
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/3489534f/attachment.html>
On 20/10/16 23:22, 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, or a mailto: URI.
>
> Cc
This check is open-coded in a few places, so it makes sense to simplify
things by having a helper for it similar to the rest of DPCD feature
helpers.
v2: (Jani)
- Move the helper to drm_dp_helper.h.
- Split out this change to a separate patch.
Cc: Jani Nikula
Cc: dri-devel at lists.freedesktop.o
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/28aabf7e/attachment.html>
g/archives/dri-devel/attachments/20161024/8d21fbf2/attachment.html>
On Mon, Oct 24, 2016 at 12:18:37PM +0200, Arnd Bergmann wrote:
> 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'
Create a new driver for the da8xx DDR2/mDDR controller and implement
support for writing to the Peripheral Bus Burst Priority Register.
Signed-off-by: Bartosz Golaszewski
---
.../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++
drivers/memory/Kconfig | 8 +
This is a follow-up for the series[1] adding new bus and memory drivers
to better support the TI LCD controller on the da850-lcdk board.
The general consensus of the discussion that followed was that DT is
not the right tool for this kind of SoC performance tweaks.
In order to avoid committing to
On Mon, Oct 24, 2016 at 10:35:30AM -0700, Kevin Hilman wrote:
> Hi Mark,
>
> Mark Rutland writes:
> > On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
> >> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
> >> +{
> >> + const struct da8xx_ddrctl_config_knob *knob;
Use unload to handle initialization failures instead of complex goto
label mess. To do this the initialization sequence needed slight
reordering and some unload functions needed to become conditional.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 10 ++--
drivers/gpu/drm/
Stop using struct drm_driver load() and unload() callbacks. The
callbacks should not be used anymore. Instead of using load the
drm_device is allocated with drm_dev_alloc() and registered with
drm_dev_register() only after the driver is completely initialized.
The deinitialization is done directly
Remove obsolete drm_connector_register() calls from tilcdc_panel.c and
tilcdc_tfp410.c. All connectors are registered when drm_dev_register()
is called.
Signed-off-by: Jyri Sarha
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 --
drivers/gpu/drm/tilcdc/tilcdc_tfp41
This series depends on tda998x dropping the drm_connector_register().
Please keep me in loop so that I know when it gets merged so that I
know when it is safe send a pull request for these.
Since first version of this series:
- Dropped "drm/i2c: tda998x: Remove obsolete drm_connector_register() ca
Hi Daniel,
> -Original Message-
> From: linux-snps-arc [mailto:linux-snps-arc-bounces at lists.infradead.org]
> On Behalf Of Alexey Brodkin
> Sent: 19 окÑÑбÑÑ 2016 г. 12:33
> To: dri-devel at lists.freedesktop.org; architt at codeaurora.org;
> Eugeniy.Paltsev at synopsys.com
> Cc
On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> .../memory-controllers/ti-da8xx-ddrctl.t
On Mon, Oct 24, 2016 at 02:55:26PM +, Deucher, Alexander wrote:
> It was working in drm-next. It appears something regressed in the
> meantime. See kernel bug 178421.
Thanks Alex, I've added myself to CC.
Ping me if you need me to test patches or need more debugging info.
--
Regards/Gruss,
.
--
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/ed4db725/attachment.html>
uhh, that function looks so odd, ... yeah. Change looks fine.
Reviewed-By: Karol Herbst
2016-10-24 17:30 GMT+02:00 Arnd Bergmann :
> gcc-4.9 notices that the validate_init() function returns unintialized
> data when called with a zero 'nr_buffers' argument, when called with the
> -Wmaybe-uniniti
2016-10-24 9:13 GMT+02:00 Baoyou Xie :
>
>
> On 23 October 2016 at 01:32, Karol Herbst wrote:
>>
>> I think it would be better to squash those commits:
>> 1. for the includes
>> 2. for static declerations
>>
> OK, I have resent new patch that squash those commits.
>
thanks, this is much easier to
gcc-4.9 notices that the validate_init() function returns unintialized
data when called with a zero 'nr_buffers' argument, when called with the
-Wmaybe-uninitialized flag:
drivers/gpu/drm/nouveau/nouveau_gem.c: In function âvalidate_init.isra.6â:
drivers/gpu/drm/nouveau/nouveau_gem.c:457:5: er
Am 24.10.2016 um 16:59 schrieb Alex Deucher:
> On Mon, Oct 24, 2016 at 10:40 AM, Christian König
> wrote:
>> From: Christian König
>>
>> This way the driver can decide if it is valuable to evict a BO or not.
>>
>> The current implementation is added as default to all existing drivers.
>>
>> v2:
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>
Hi Dave,
please consider merging this tag containing a few fixes for the recently
merged active plane reconfiguration support, a label hidden to remove a
build warning, a fixed error path, and fixes to handling of planes with
chroma subsampling or alpha channel.
regards
Philipp
The following cha
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
On Fri, Sep 23, 2016 at 5:28 PM, Stephen Boyd wrote:
> On 09/23/2016 05:13 PM, John Stultz wrote:
>> arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
>> b/arch/arm/boo
From: Christian König
This way we can correctly check split VRAM buffers as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
From: Christian König
This way the driver can decide if it is valuable to evict a BO or not.
The current implementation is added as default to all existing drivers.
v2: fix some typos found during internal testing
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |
From: Christian König
A few 80chars issues and spaces at wrong places.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_driver.h | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm
; > + DRM_FORMAT_ARGB,
> > + DRM_FORMAT_ARGB1555,
> > + DRM_FORMAT_RGBA5551,
> > + DRM_FORMAT_RGBA,
> > DRM_FORMAT_RGB888,
> > + DRM_FORMAT_RGB565,
> > DRM_FORMAT_XRGB,
>
> Could you explain in the commit log why these 2 aren't the same?
Yep, I will.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/66862cae/attachment.sig>
On Mon, Oct 24, 2016 at 03:27:59PM +0100, Brian Starkey wrote:
> 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 td
On Mon, Oct 24, 2016 at 04:08:47PM +0300, Marta Lofstedt wrote:
> 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
> co
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
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
As per Ingo's request I've cc'ed a bunch more x86/PAT people.
Dave.
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
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 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
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
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
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.
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
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
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
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
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
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
On Mon, 2016-10-24 at 23:30 +0100, Colin King wrote:
> From: Colin Ian King
>
> Fix trivial spelling mistake cant't -> can't and add KERN_WARNING to
> printk messages.
trivia:
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
[]
Hi,
On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> engine, DE2.
> This patch adds a DRM video driver for this device.
>
> Signed-off-by: Jean-Francois Moine
Output from checkpatch:
total: 0 errors, 20
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
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
I messed up one of the mailing lists last time (copied ancient
address from another script).
Dave.
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
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
Signed-off-by: Rob Clark
---
Hmm, looks like I forgot to send this..
drivers/dma-buf/fence.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 4d51f9e..cc05ddd 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -68,6
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
Hi Daniel,
On Mon, Oct 24, 2016 at 04:36:27PM +0200, Daniel Vetter wrote:
>On Mon, Oct 24, 2016 at 03:27:59PM +0100, Brian Starkey wrote:
>> 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
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
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
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
s
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attach
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>
On Mon, Oct 24, 2016 at 09:12:35AM +0200, Daniel Vetter wrote:
> 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 pos
> -Original Message-
> From: Borislav Petkov [mailto:bp at alien8.de]
> Sent: Monday, October 24, 2016 4:19 AM
> To: Michel Dänzer
> Cc: Deucher, Alexander; Koenig, Christian; lkml; dri-
> devel at lists.freedesktop.org
> Subject: Re: radeon_connector_unregister NULL ptr deref
>
> On Mon,
On Mon, Oct 24, 2016 at 7:38 AM, Chris Wilson
wrote:
> 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.
On Mon, Oct 24, 2016 at 3:12 AM, Daniel Vetter wrote:
> 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 ...
>
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161024/953e2f06/attachment.sig>
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
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
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
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 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 Mon, Oct 17, 2016 at 1:00 PM, Sean Paul wrote:
> On Fri, Oct 14, 2016 at 7:55 PM, Rob Clark wrote:
>> Sometimes it is nice not to duplicate equivalent printk() and
>> seq_printf() code.
>>
>> Signed-off-by: Rob Clark
>> ---
>> drivers/gpu/drm/Makefile| 3 ++-
>> drivers/gpu/drm/drm_prin
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>
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
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:
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
On Mon, Oct 24, 2016 at 5:46 AM, Christian König
wrote:
> 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
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++) {
>
On Sat, Oct 22, 2016 at 4:56 AM, Baoyou Xie wrote:
> We get a few warnings when building kernel with W=1:
> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:162:5: warning:
> no previous prototype for 'fiji_setup_pwr_virus' [-Wmissing-prototypes]
> drivers/gpu/drm/amd/amdgpu/../powerp
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
1 - 100 of 175 matches
Mail list logo
