run radeon.dpm=0 (it was needed
too for the radeon HD 7970 I had in the past).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/a
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/fe12c242/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/50ad47d1/attachment-0001.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/8fc3b046/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/fcf108eb/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=106291
--- Comment #3 from Michel Dänzer ---
Does this still happen with a 4.3(-rc) kernel?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=106341
--- Comment #1 from Michel Dänzer ---
Can you further narrow down which kernel version between 3.16 and 4.1
introduced the problem?
--
You are receiving this mail because:
You are watching the assignee of the bug.
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/05f95d61/attachment.html>
On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki
> wrote:
> > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki
> >> wrote:
> >> > On Monday, October 19, 2015 10:58:2
On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote:
>
> --7fVr/IRGAG9sAW4J
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> > On Tue, 20 Oct 2015, Tomeu
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/85bdc389/attachment.html>
On Mon, Oct 19, 2015 at 04:33:30PM +, Insu Yun wrote:
> drm_property_create_range can be failed in memory pressure
> Therefore, check return value and handle an error
>
> Signed-off-by: Insu Yun
There's also other drm_property_create_* functions, and we miss error
handling for a bunch more o
gt; What has been done for bindings so far is all over the map though.
>>
>> You say hpd-gpios is deprectated, but that I should use the
>> hdmi-connector binding that uses hpd-gpios. Which one is it? If
>> hpd-gpios deprecated, what is supposed to be used instead?
>
> No, I said "hpd-gpio" with no "s" is deprecated. In other words,
> always use -gpios whether it is 1 or more gpio.
Fixed.
> The connector part is a separate issue of the location of these
> properties. If you think about it, the gpio line and I2C bus have
> nothing to do with the HDMI node. That's different than cases of HDMI
> bridges which have a HPD signal and dedicated I2C controller. Most
> examples in the kernel have not followed this and do as you have. I
> only have a desire to have common binding and code to handle
> connectors at this point, but that is the direction I want to go.
If you come up with common code that makes driver development easier
instead of harder, I'll be interested to see.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/9c9be481/attachment-0001.sig>
On Tue, 20 Oct 2015, Vinod Koul wrote:
> On Tue, Oct 20, 2015 at 09:08:00AM +0100, Russell King - ARM Linux wrote:
>> > > Currently i915/audio component works as you described. The audio is
>> > > optional and HDMI graphics works without audio, while HDMI HD-audio
>> > > mandates i915 graphics.
>
https://bugzilla.kernel.org/show_bug.cgi?id=60533
Jani Nikula changed:
What|Removed |Added
CC||dri-devel at lists.freedesktop
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dri-devel at lists.free
version 5 changes:
- rebased on kernel 4.3-rc6
- rework locking schema and make handle status use an atomic_t
- add a fake secure module to allow performing tests without trusted
environment
version 4 changes:
- rebased on kernel 4.3-rc3
- fix missing EXPORT_SYMBOL for smaf_create_handle()
Secure Memory Allocation Framework goal is to be able
to allocate memory that can be securing.
There is so much ways to allocate and securing memory that SMAF
doesn't do it by itself but need help of additional modules.
To be sure to use the correct allocation method SMAF implement
deferred allocat
SMAF CMA allocator implement helpers functions to allow SMAF
to allocate contiguous memory.
match() each if at least one of the attached devices have coherent_dma_mask
set to DMA_BIT_MASK(32).
For allocation it use dma_alloc_attrs() with DMA_ATTR_WRITE_COMBINE and not
dma_alloc_writecombine to be
This module is allow testing secure calls of SMAF.
Signed-off-by: Benjamin Gaignard
---
drivers/smaf/Kconfig | 6 +++
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-fakesecure.c | 92 ++
3 files changed, 99 insertions(+)
create mode 1
On Tue, Oct 20, 2015 at 07:31:48PM +0530, Vinod Koul wrote:
> On Tue, Oct 20, 2015 at 09:08:00AM +0100, Russell King - ARM Linux wrote:
> > > > Currently i915/audio component works as you described. The audio is
> > > > optional and HDMI graphics works without audio, while HDMI HD-audio
> > > > ma
Sorry to enter this thread a bit late.
About the number of probe deferred messages, I proposed a simple patch to
reduce them:
https://lkml.org/lkml/2013/8/20/218
I was wondering how many messages this patch could save...
--
Ken ar c'hentañ| ** Breizh ha Linux atav!
Hi Rafael,
On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki wrote:
> On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
>> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki
>> wrote:
>> > ACPI uses platform devices too. In fact, ACPI device objects are
>> > enumerated as
>> > plat
Quoting Sylwester Nawrocki (2015-10-20 04:17:35)
> On 20/10/15 12:34, Michael Turquette wrote:
> >> diff --git a/include/dt-bindings/clock/exynos5433.h
> >> b/include/dt-bindings/clock/exynos5433.h
> >> > index 5bd80d5..4f0d566 100644
> >> > --- a/include/dt-bindings/clock/exynos5433.h
> >> > +++
On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> >> Hi Russell,
> >>
> >> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> >> wrote:
> > Wh
On Wed, Oct 14, 2015 at 07:28:53PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Add a few helpers to get the dimensions of the chroma plane(s).
>
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Ville Syrjälä
> ---
> include/drm/drm_crtc.h | 12 +++
achments/20151021/41b61f01/attachment.sig>
Am Dienstag, den 20.10.2015, 10:22 -0400 schrieb Akshay Bhat:
> Hi,
>
> We are trying to use IPU2 DI0 for LVDS and IPU1 DI0 for HDMI on a iMX6Q
> based board. Below is the ldb entry in device tree and with these
> settings the LVDS is still being mapped to IPU1. Is there something
> missing/inc
t available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/64706bed/attachment-0001.sig>
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/e7d4e384/attachment.sig>
On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote:
> > There is no point in keeping backwards compatibility to older
> > kernel versions in a driver destined to mainline.
>
> You are correct, however the reposito
On Fri, Sep 25, 2015 at 01:57:52PM +0200, Lucas Stach wrote:
> From: Christian Gmeiner
>
> This is very useful for debugging issues regarding command
> buffer processing.
>
> Signed-off-by: Christian Gmeiner
Applied, thanks.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kb
On Fri, Sep 25, 2015 at 01:57:53PM +0200, Lucas Stach wrote:
> From: Christian Gmeiner
>
> etnaviv_buffer_init() creates a very simple command buffer
> to be able to start the FE. FE fetches 'prefetch' number of 64 bit
> words via DMA and starts to execute the read buffer.
>
> This is a very sim
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151021/eb842d8e/attachment.html>
On Wed, Oct 21, 2015 at 10:53:31AM +0100, Eric Anholt wrote:
> Dave suggested it was time to just send a pull request on the driver, so
> here goes:
Given I suggested the same:
Acked-by: Daniel Vetter
>
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>
> Linux
Am Mittwoch, den 21.10.2015, 12:35 +0100 schrieb Russell King - ARM
Linux:
> On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote:
> > > There is no point in keeping backwards compatibility to older
> > > kernel ve
On Wed, Oct 21, 2015 at 02:37:16PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 21.10.2015, 12:35 +0100 schrieb Russell King - ARM
> Linux:
> > On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote:
> > > On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote:
> > > > There
On Wed, 21 Oct 2015 11:27:44 +0200,
Russell King - ARM Linux wrote:
>
> On Tue, Oct 20, 2015 at 07:31:48PM +0530, Vinod Koul wrote:
> > On Tue, Oct 20, 2015 at 09:08:00AM +0100, Russell King - ARM Linux wrote:
> > > > > Currently i915/audio component works as you described. The audio is
> > > > >
On Wed, Oct 21, 2015 at 03:41:44PM +0200, Takashi Iwai wrote:
> On Wed, 21 Oct 2015 11:27:44 +0200,
> Russell King - ARM Linux wrote:
> >
> > On Tue, Oct 20, 2015 at 07:31:48PM +0530, Vinod Koul wrote:
> > > On Tue, Oct 20, 2015 at 09:08:00AM +0100, Russell King - ARM Linux wrote:
> > > > > > Curr
On Wed, 21 Oct 2015 16:03:07 +0200,
Russell King - ARM Linux wrote:
>
> On Wed, Oct 21, 2015 at 03:41:44PM +0200, Takashi Iwai wrote:
> > On Wed, 21 Oct 2015 11:27:44 +0200,
> > Russell King - ARM Linux wrote:
> > >
> > > On Tue, Oct 20, 2015 at 07:31:48PM +0530, Vinod Koul wrote:
> > > > On Tue,
On 15 October 2015 at 06:55, Mikko Rapeli wrote:
> Fixes userspace compile error since list_head is not exported to userspace
> headers.
>
> Suggested by Emil Velikov at
> https://lkml.org/lkml/2015/6/3/792
>
> Signed-off-by: Mikko Rapeli
We're safe as the only users of the struct already includ
On Wed, 21 Oct 2015 16:10:31 +0200,
Takashi Iwai wrote:
>
> On Wed, 21 Oct 2015 16:03:07 +0200,
> Russell King - ARM Linux wrote:
> >
> > On Wed, Oct 21, 2015 at 03:41:44PM +0200, Takashi Iwai wrote:
> > > On Wed, 21 Oct 2015 11:27:44 +0200,
> > > Russell King - ARM Linux wrote:
> > > >
> > > >
On Wed, Oct 21, 2015 at 04:10:31PM +0200, Takashi Iwai wrote:
> On Wed, 21 Oct 2015 16:03:07 +0200,
> Russell King - ARM Linux wrote:
> > It's only the point if you can code it up properly, which from what I
> > read in that file, it isn't.
>
> An idea can fly without coding, too :)
>
> > Build t
On 15 October 2015 at 06:55, Mikko Rapeli wrote:
> Fixes userspace compile error:
>
> drm/sis_drm.h:68:19: error: field âobj_listâ has incomplete type
> struct list_head obj_list;
>
> Suggested by Emil Velikov at
> https://lkml.org/lkml/2015/6/3/792
>
> Signed-off-by: Mikko Rapeli
> ---
An
https://bugzilla.kernel.org/show_bug.cgi?id=60533
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #39 f
On Fri, Sep 25, 2015 at 01:57:57PM +0200, Lucas Stach wrote:
> There is no point in having a context restore buffer, as the need for tracking
> GPU hardware state in userspace and the fact that we need to submit all states
> that reference memory buffers anyway to ensure proper patching of the
> re
On Fri, Sep 25, 2015 at 01:57:58PM +0200, Lucas Stach wrote:
> This rewrites the submit interface to copy the command stream from user
> memory. This mitigates a potential attack vector of the old interface
> where userspace could submit a command buffer that would be validated by
> the kernel, but
On Fri, Sep 25, 2015 at 01:57:59PM +0200, Lucas Stach wrote:
> Instead of using a GEM buffer for the kernel internal ring buffer
> use the newly introduced cmdbuf object. This removes the last remaining
> user of the CMDSTREAM GEM flag.
>
> Signed-off-by: Lucas Stach
Applied, thanks.
--
FTTC b
Am Mittwoch, den 21.10.2015, 14:37 +0100 schrieb Russell King - ARM
Linux:
> On Wed, Oct 21, 2015 at 02:37:16PM +0200, Lucas Stach wrote:
> > Am Mittwoch, den 21.10.2015, 12:35 +0100 schrieb Russell King - ARM
> > Linux:
> > > On Fri, Sep 25, 2015 at 01:18:48PM +0100, Russell King - ARM Linux wrote
g.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/c4783b98/attachment-0001.html>
On 15 October 2015 at 06:55, Mikko Rapeli wrote:
> Fixes compiler error:
>
> drm/via_drm.h:36:27: fatal error: via_drmclient.h: No such file or directory
>
> Signed-off-by: Mikko Rapeli
> ---
> include/uapi/drm/via_drm.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/include/uapi/drm
Hi Alex,
On 15 October 2015 at 14:48, Mikko Rapeli wrote:
> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
>> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli wrote:
>> > Fixes userspace compilation error:
>> >
>> > drm/drm_mode.h:472:2: error: unknown type name âuint32_tâ
>> >
>
On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> In addition to the last-in/first-out stack for accessing drm_mm nodes,
> we occasionally and in the future often want to find a drm_mm_node by an
> address. To do so efficiently we need to track the nodes in an interval
> tree - lookup
On Wed, Oct 21, 2015 at 04:53:50PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 21.10.2015, 14:37 +0100 schrieb Russell King - ARM
> Linux:
> > On Wed, Oct 21, 2015 at 02:37:16PM +0200, Lucas Stach wrote:
> > > Am Mittwoch, den 21.10.2015, 12:35 +0100 schrieb Russell King - ARM
> > > Linux:
> > > >
Hi
On Wed, Oct 21, 2015 at 5:11 PM, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
>> In addition to the last-in/first-out stack for accessing drm_mm nodes,
>> we occasionally and in the future often want to find a drm_mm_node by an
>> address. To do so effic
Hi Daniel,
On Tuesday 20 October 2015 09:32:13 Daniel Vetter wrote:
> On Tue, Oct 20, 2015 at 01:51:54AM +0300, Laurent Pinchart wrote:
> > The drm driver .load() operation is prone to race conditions as it
> > initializes the driver after registering the device nodes. Its usage is
> > deprecated,
On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov
wrote:
> Hi Alex,
>
> On 15 October 2015 at 14:48, Mikko Rapeli wrote:
>> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
>>> On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli
>>> wrote:
>>> > Fixes userspace compilation error:
>>> >
>>>
On Fri, Sep 25, 2015 at 01:57:55PM +0200, Lucas Stach wrote:
> This redefines how we do cache handling in the following way:
>
> All buffer are pushed into the GPU domain initially, this will only
> be done when populating the buffers backing store, but for simplicity
> userspace can assume that t
On Fri, Sep 25, 2015 at 01:57:56PM +0200, Lucas Stach wrote:
> This makes sure that we are satifying the cache handling rules outlined
> in the previous commit. Cached buffers are pulled into the CPU domain
> before access and pushed to the GPU again when the CPU is done.
>
> Signed-off-by: Lucas
https://bugzilla.kernel.org/show_bug.cgi?id=106431
Bug ID: 106431
Summary: dmesg is flooded with error messages
Product: Drivers
Version: 2.5
Kernel Version: 4.3rc6
Hardware: All
OS: Linux
Tree: Mainline
On Fri, Sep 25, 2015 at 01:58:00PM +0200, Lucas Stach wrote:
> Neither userspace nor the kernel internal functions use the CMDSTREAM
> GEM type anymore. Remove it from the public API and clean up all related
> functions.
>
> Signed-off-by: Lucas Stach
Applied, thanks.
--
FTTC broadband for 0.8
On Wed, Oct 21, 2015 at 03:36:22PM +0100, Emil Velikov wrote:
> On 15 October 2015 at 06:55, Mikko Rapeli wrote:
> > Fixes userspace compile error since list_head is not exported to userspace
> > headers.
> >
> > Suggested by Emil Velikov at
> > https://lkml.org/lkml/2015/6/3/792
> >
> > Signed-o
Hi Dave,
Just a crash fix for radeon and amdgpu if the user has forcibly disabled
dpm and tries to access the pwm sysfs controls.
The following changes since commit f6c7aba47bcc0b1cc2085c8d8af80f8c02f28269:
drm/amdgpu: Keep the pflip interrupts always enabled v7 (2015-10-15 10:04:50
-0400)
a
On Wed, Oct 21, 2015 at 03:39:07PM +0100, Emil Velikov wrote:
> On 15 October 2015 at 06:55, Mikko Rapeli wrote:
> > Fixes userspace compile error:
> >
> > drm/sis_drm.h:68:19: error: field âobj_listâ has incomplete type
> > struct list_head obj_list;
> >
> > Suggested by Emil Velikov at
>
2015-10-21 16:32 GMT+02:00 James Morris :
> On Wed, 21 Oct 2015, Benjamin Gaignard wrote:
>
>> Secure Memory Allocation Framework goal is to be able
>> to allocate memory that can be securing.
>> There is so much ways to allocate and securing memory that SMAF
>> doesn't do it by itself but need hel
Hi,
this is v10 of an attempt to make it easier for devices to remain in
runtime PM when the system goes to sleep, mainly to reduce the time
spent resuming devices.
For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors are
Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume tha
On Wed, Oct 21, 2015 at 04:37:07PM +0200, Takashi Iwai wrote:
> On Wed, 21 Oct 2015 16:10:31 +0200,
> Takashi Iwai wrote:
> >
> > On Wed, 21 Oct 2015 16:03:07 +0200,
> > Russell King - ARM Linux wrote:
> > >
> > > On Wed, Oct 21, 2015 at 03:41:44PM +0200, Takashi Iwai wrote:
> > > > On Wed, 21 Oc
On Wed, Oct 21, 2015 at 06:16:08PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tuesday 20 October 2015 09:32:13 Daniel Vetter wrote:
> > On Tue, Oct 20, 2015 at 01:51:54AM +0300, Laurent Pinchart wrote:
> > > The drm driver .load() operation is prone to race conditions as it
> > > initializ
On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
< snip >
>>> +
>>> static bool driver_deferred_probe_enable = false;
>>> +
>>> /**
>>> * driver_deferred_probe_trigg
On Fri, Sep 25, 2015 at 01:57:54PM +0200, Lucas Stach wrote:
> Not bullet proof yet, as this possibly shoots down more submits than
> necessary. However it allows for fairly rapid turnarounds during
> userspace development.
>
> Signed-off-by: Lucas Stach
Applied, thanks.
--
FTTC broadband for
Hi Dave,
I forgot to include these two patches in my last pull request, sorry about
that.
The following changes since commit affa0e033b04996700434312c76df3c78f683870:
Merge tag 'topic/drm-misc-2015-10-19' of git://anongit.freedesktop.org/drm-
intel into drm-next (2015-10-20 09:01:49 +1000)
a
2015-10-21 16:34 GMT+02:00 James Morris :
> On Wed, 21 Oct 2015, Benjamin Gaignard wrote:
>
>>
>> The outcome of the previous RFC about how do secure data path was the need
>> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>>
>
> Have you addressed all the questions raised by Ala
This patch set adds support for the new Stoney APU. Stoney
is a new VI-based APU from AMD.
Samuel Li (10):
drm/amdgpu: add Stoney chip family
drm/amdgpu: add GMC support for Stoney
drm/amdgpu: Update SMC/DPM for Stoney
drm/amdgpu: add DCE support for Stoney
drm/amdgpu: add SDMA support
From: Samuel Li
Stoney is GMC 8.x.
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 42b5ff8..72e
From: Samuel Li
Stoney is based on Carrizo with some IP upgrades.
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
drivers/gpu/drm/amd/include/amd_shared.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amd
From: Samuel Li
Stoney is SDMA 3.x.
v2: update to latest golden register settings
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_
From: Samuel Li
Stoney is GFX 8.1.
v2: update to latest golden settings
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 400 --
1 file changed, 382 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/am
From: Samuel Li
Stoney is SMC 8.x.
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 21 ++---
drivers/gpu/drm/amd/amdgpu/cz_smc.c | 60 +
2 files changed, 65 insertions(+), 16 deletions(-)
diff --git a/
From: Samuel Li
Stoney is UVD 6.x.
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index d0312364..53f98
From: Samuel Li
Stoney is VCE 3.x single.
v2: Stoney is single pipe like Fiji
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 5 +
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 5 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff
From: Samuel Li
Add core VI enablement for Stoney.
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/vi.c| 36 +-
include/uapi/drm/amdgpu_drm.h | 2 +-
From: Samuel Li
Stoney is DCE 11.x.
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/dce_
From: Samuel Li
Signed-off-by: Samuel Li
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6134b1e..c3216be 100644
--- a/drivers/
On Wed, Oct 21, 2015 at 12:11:08PM +0300, Jani Nikula wrote:
> On Tue, 20 Oct 2015, Vinod Koul wrote:
> > On Tue, Oct 20, 2015 at 09:08:00AM +0100, Russell King - ARM Linux wrote:
> >> > > Currently i915/audio component works as you described. The audio is
> >> > > optional and HDMI graphics work
On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> On 18 October 2015 at 21:53, Mark Brown wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote
On Wed, Oct 21, 2015 at 03:37:47PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 04:10:31PM +0200, Takashi Iwai wrote:
> > On Wed, 21 Oct 2015 16:03:07 +0200,
> > Russell King - ARM Linux wrote:
> > > It's only the point if you can code it up properly, which from what I
> > > rea
On 21 October 2015 at 16:18, Alex Deucher wrote:
> On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov
> wrote:
>> Hi Alex,
>>
>> On 15 October 2015 at 14:48, Mikko Rapeli wrote:
>>> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
On Thu, Oct 15, 2015 at 1:55 AM, Mikko Rapeli
>>
On 21 October 2015 at 16:33, Daniel Vetter wrote:
> On Wed, Oct 21, 2015 at 03:36:22PM +0100, Emil Velikov wrote:
>> On 15 October 2015 at 06:55, Mikko Rapeli wrote:
>> > Fixes userspace compile error since list_head is not exported to userspace
>> > headers.
>> >
>> > Suggested by Emil Velikov
On Wed, Oct 21, 2015 at 12:21 PM, Emil Velikov
wrote:
> On 21 October 2015 at 16:18, Alex Deucher wrote:
>> On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov
>> wrote:
>>> Hi Alex,
>>>
>>> On 15 October 2015 at 14:48, Mikko Rapeli wrote:
On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deuche
On Wed, 21 Oct 2015 17:36:01 +0200,
Daniel Vetter wrote:
>
> On Wed, Oct 21, 2015 at 04:37:07PM +0200, Takashi Iwai wrote:
> > On Wed, 21 Oct 2015 16:10:31 +0200,
> > Takashi Iwai wrote:
> > >
> > > On Wed, 21 Oct 2015 16:03:07 +0200,
> > > Russell King - ARM Linux wrote:
> > > >
> > > > On Wed,
On Wed, 21 Oct 2015 18:46:23 +0200,
Takashi Iwai wrote:
>
> Below is a test patch I cooked quickly. This is the third patch
> applied after other two more patches: a cleanup patch and a patch for
> deferred probe of HD-audio with component.
And this is the patch to defer the probe.
-- 8< --
Fro
On Wed, 21 Oct 2015 18:48:06 +0200,
Takashi Iwai wrote:
>
> On Wed, 21 Oct 2015 18:46:23 +0200,
> Takashi Iwai wrote:
> >
> > Below is a test patch I cooked quickly. This is the third patch
> > applied after other two more patches: a cleanup patch and a patch for
> > deferred probe of HD-audio w
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/23b8972f/attachment.html>
bugs in the proper components.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151021/1028d582/attachment.html>
On Tue, Oct 20, 2015 at 11:36:27AM +0200, Daniel Vetter wrote:
> On Fri, Sep 11, 2015 at 04:10:10PM +0200, Lucas Stach wrote:
> > Hey all,
> >
> > this is a new posting of the Etnaviv DRM driver for Vivante embedded GPUs.
> > This time I've squashed all patches to the DRM driver itself into a sing
https://bugzilla.kernel.org/show_bug.cgi?id=106431
RussianNeuroMancer changed:
What|Removed |Added
Summary|dmesg is flooded with error |On ASUS A8JN laptop with
.org/archives/dri-devel/attachments/20151021/eeb1eff7/attachment.html>
On Wed, Oct 21, 2015 at 09:49:28PM +0530, Vinod Koul wrote:
> On Wed, Oct 21, 2015 at 03:37:47PM +0100, Russell King - ARM Linux wrote:
> > In any case, this doesn't (and can't) solve the CEC problem, so it's not
> > a solution to the problem at hand.
>
> Sorry am not sure I follow the reasons for
Hi all,
In a recent test performed with fbterm and an adapter that uses the ast
driver, fbterm is currently segfaulting in the mainline kernel.
The crash happens when the code attempts to do a write to the frame
buffer, which is an mmap'ed region. The size of the mmap is determined
by the smem_le
1 - 100 of 128 matches
Mail list logo
