On Fri, Jan 9, 2015 at 1:50 PM, Jani Nikula wrote:
> I have a slightly uneasy feeling about handing out drm_panel pointers
> (both from here and of_drm_find_panel) without refcounting. If the panel
> driver gets removed, whoever called the find functions will have a
> dangling pointer. I supposed
On 01/12/2015 07:31 AM, Rickard Strandqvist wrote:
> Remove the function nouveau_bo_rd16() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
nouveau_bo_wr16() being presumably used (since it is not removed by this
patch), it sounds
In booting, we can see a below message.
[3.241728] exynos-mixer 1445.mixer: Unbalanced pm_runtime_enable!
Already pm_runtime_enable is called by probe function. Remove
pm_runtime_enable/disable from mixer_bind and mixer_unbind.
Signed-off-by: Joonyoung Shim
---
I'm not sure whether it's
When the timeout value passed to reservation_object_wait_timeout_rcu
is zero, no wait should be done if the fences are not signaled.
Return '1' for idle and '0' for busy if the specified timeout is '0'
to keep consistent with the case of non-zero timeout.
v2: call fence_put if not signaled in the
On Wed, Dec 10, 2014 at 4:48 PM, Andrzej Hajda wrote:
> The patch moves Device Tree parsing logic to separate
> function.
>
> Signed-off-by: Andrzej Hajda
I think this patch need to be rebased on the GPIO devel branch, but
looks like it makes things cleaner so can stand on its own merits.
We mo
Hey,
Can't you simply add if (!timeout) return
!reservation_object_test_signaled_rcu(obj, wait_all); to the beginning instead?
Waiting with timeout = 0 is not really defined. Look at fence_default_wait for
example. It returns timeout
if the fence is signaled, but since this is 0 you can't distin
At Mon, 12 Jan 2015 23:47:42 +0100,
Daniel Vetter wrote:
>
> Hi Takashi,
>
> So here's the stable tag with Imre's i915/hda componentized refactoring,
> based upon 3.19-rc4. I'll pull in the same tag into drm-intel-next.
Great, I pulled the branch now. Thanks!
Takashi
>
> Cheers, Daniel
>
>
On 11.01.2015 10:58, Federico wrote:
> Hi.
> I always get a soft lockup when booting since I bought a Cape Verde XT
> [Radeon HD 7770/8760 / R7 250X].
>
> In this bug report you can find screenshots of the softlockup and the
> kernel panic generated by using softlockup_panic=1
>
> https://bugs.la
On Sun, 11 Jan 2015 23:03:14 +0200
Jyri Sarha wrote:
> Some more comments based on my - finally successful - attempt to use
> this code with BBB HDMI audio.
>
> On 01/07/2015 12:51 PM, Jean-Francois Moine wrote:
> > This patch adds a CODEC to the NXP TDA998x HDMI transmitter.
[snip]
> >
Hi Dave,
Two fixes for -rc5 :
- Remove the interrupt SW ring buffer impl. as it is not used by any module
in amdkfd.
- Fix a sparse warning
Thanks,
Oded
The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115:
linux 3.19-rc4 (2015-01-11 12:44:53 -0800)
are av
Op 13-01-15 om 08:59 schreef Zhou, Jammy:
> Hi Maarten,
>
>> Can't you simply add if (!timeout) return
>> !reservation_object_test_signaled_rcu(obj, wait_all); to the beginning
>> instead?
> Hmm, after looking into it, I think that can achieve the same purpose. I will
> update the patch with thi
Hi Maarten,
> Can't you simply add if (!timeout) return
> !reservation_object_test_signaled_rcu(obj, wait_all); to the beginning
> instead?
Hmm, after looking into it, I think that can achieve the same purpose. I will
update the patch with this.
> Also why do you need this? Why not simply retu
Restore the nv50 cursor bo on resume, and load the lut in
nv50_display_display_init
so it gets set on resume too.
Tested on a fermi and a curie.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index f804243
From: Ben Goz
This patch rewrites destroy_queue_nocpsch() as the current logic that is
implemented in the function is completely flawed.
This function is used only in non-HWS mode.
Signed-off-by: Ben Goz
Signed-off-by: Oded Gabbay
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 36 +
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index 29b9220ec399..3d201e937571 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -257,6 +257,7 @@ static int radeonfb_create(struct
> You can't anyway when calling with timeout = 0.
For consistency, we can always return 0 for busy (not signaled), and return
'>0' for idle (signaled). This rule should be common for
reservation_object_wait_timeout_rcu. So in my previous patch, '1' is returned
for signaled case when specified ti
From: Ben Goz
This patch rewrites destroy_queue_nocpsch() as the current logic that is
implemented in the function is completely flawed.
This function is used only in non-HWS mode.
Signed-off-by: Ben Goz
Signed-off-by: Oded Gabbay
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 36 +
Instead of creating a BUG if trying to free a NULL GART sub-allocation object,
just return 0 (success).
This is done to mirror behavior of kfree.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/driver
Op 13-01-15 om 10:36 schreef Jammy Zhou:
> When the timeout value passed to reservation_object_wait_timeout_rcu
> is zero, no wait should be done if the fences are not signaled.
>
> Return '1' for idle and '0' for busy if the specified timeout is '0'
> to keep consistent with the case of non-zero t
When the timeout value passed to reservation_object_wait_timeout_rcu
is zero, no wait should be done if the fences are not signaled.
Return '1' for idle and '0' for busy if the specified timeout is '0'
to keep consistent with the case of non-zero timeout.
v2: call fence_put if not signaled in the
> but where do you need this?
With the new upcoming amdgpu driver, we would like to use 'timeout==0' to check
if the fences are signaled or not (without waiting).
Besides, the jiffies accuracy is not enough for UMDs if the specified timeout
is nsecs or usecs, and then nsecs_to_jiffies/usecs_to_
Am 13.01.2015 um 10:04 schrieb Maarten Lankhorst:
> Op 13-01-15 om 10:36 schreef Jammy Zhou:
>> When the timeout value passed to reservation_object_wait_timeout_rcu
>> is zero, no wait should be done if the fences are not signaled.
>>
>> Return '1' for idle and '0' for busy if the specified timeout
On Fri, 09 Jan 2015 17:39:08 +
Andrew Jackson wrote:
> > + snd_pcm_hw_constraint_minmax(runtime,
> > + SNDRV_PCM_HW_PARAM_CHANNELS,
> > + 1, sad[SAD_MX_CHAN_I]);
>
> In the light of our discussions elsewhere [1], shouldn't t
From: Ben Goz
This patch fixes a minor bug in allocate_hqd(), where the loop run from the
next-to-allocate pipe until the number of pipes.
This is wrong because we need to consider the possibility where
next-to-allocate pipe is not 0, and thus, the for-loop only checks part of the
pipes and does
https://bugzilla.kernel.org/show_bug.cgi?id=90851
--- Comment #4 from Michel Dänzer ---
(In reply to Christoph Haag from comment #3)
> radeon: mmap failed, errno: 12
That's ENOMEM, so it looks like the kernel runs out of memory. Maybe a leak
somewhere.
(In reply to Christoph Haag from comment
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150113/ee6f/attachment.html>
Op 13-01-15 om 10:22 schreef Christian König:
> Am 13.01.2015 um 10:04 schrieb Maarten Lankhorst:
>> Op 13-01-15 om 10:36 schreef Jammy Zhou:
>>> When the timeout value passed to reservation_object_wait_timeout_rcu
>>> is zero, no wait should be done if the fences are not signaled.
>>>
>>> Return
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/96fd1086/attachment-0001.html>
This patch-set continues to prepare amdkfd so it could support VI APU. it
prepares DQM and KQ modules to support more than one ASIC.
Note: there is no change in the IOCTLs.
Oded
Ben Goz (2):
drm/amdkfd: Add initial VI support for DQM
drm/amdkfd: Add initial VI support for KQ
Oded G
This patch does some re-org on the device_queue_manager structure. It takes out
all the function pointers from the structure and puts them in a new structure,
called device_queue_manager_ops. Then, it puts an instance of that structure
inside device_queue_manager.
This re-org is done to prepare th
From: Ben Goz
This patch starts to add support for the VI APU in the DQM module.
Because most (more than 90%) of the DQM code is shared among AMD's APUs, we
chose a design that performs most/all the code in the shared DQM file
(kfd_device_queue_manager.c). If there is H/W specific code to be exe
This patch does some re-org on the kernel_queue structure. It takes out
all the function pointers from the structure and puts them in a new structure,
called kernel_queue_ops. Then, it puts an instance of that structure
inside kernel_queue.
This re-org is done to prepare the KQ module to support m
From: Ben Goz
This patch starts to add support for the VI APU in the KQ (kernel queue)
module.
Because most (more than 90%) of the KQ code is shared among AMD's APUs, we
chose a design that performs most/all the code in the shared KQ file
(kfd_kernel_queue.c). If there is H/W specific code to be
- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/90074b46/attachment-0001.sig>
Am Montag, den 12.01.2015, 17:57 + schrieb Russell King - ARM Linux:
> On Mon, Jan 12, 2015 at 06:13:41PM +0100, Jean-Francois Moine wrote:
> > On Mon, 12 Jan 2015 14:04:56 +
> > Russell King - ARM Linux wrote:
> > > On Mon, Jan 12, 2015 at 02:59:57PM +0100, Philipp Zabel wrote:
> > > > No
+. Might that suggest
a timing issue?
--
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/20150113/77bfaa6d/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/13f24d29/attachment.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/20150113/8c86db52/attachment.html>
On Tue, Jan 13, 2015 at 01:21:58PM +0100, Philipp Zabel wrote:
> I wonder if it wouldn't be nicer to have the AP# and type in the device
> tree and then calculate the register value from that in the driver.
>
> port at 1 {
> reg = <1>; /* AP1 */
> nxp,audio-port =
On Tue, Jan 13, 2015 at 01:14:17PM +0100, Thierry Reding wrote:
> On Tue, Dec 09, 2014 at 03:39:26PM +0100, Luc Verhaegen wrote:
> > On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote:
> > > Hi,
> > >
> > > At FOSDEM on the 31st of january and the 1st of February 2015, there
> > > will
This adds another parameter rotation to drm_plane_helper_check_update.
This will enable this function to do to size updations based upon the rotation
if any.
Updated the calls to this function in i915 and drm. Rockchip driver also needs
to be updated.
Sonika Jindal (2):
drm: Adding rotation to d
Taking rotation into account while checking the plane
and adjusting the sizes accordingly.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/drm_plane_helper.c | 79 ++--
include/drm/drm_plane_helper.h |3 +-
2 files changed, 77 insertions(+), 5 deletions
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_display.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f40288f..d19ed4b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote:
> Taking rotation into account while checking the plane
> and adjusting the sizes accordingly.
>
> Signed-off-by: Sonika Jindal
> ---
> drivers/gpu/drm/drm_plane_helper.c | 79
> ++--
> include/drm/
On Tue, Jan 13, 2015 at 3:55 AM, Oded Gabbay wrote:
> From: Ben Goz
>
> This patch rewrites destroy_queue_nocpsch() as the current logic that is
> implemented in the function is completely flawed.
>
> This function is used only in non-HWS mode.
>
> Signed-off-by: Ben Goz
> Signed-off-by: Oded Ga
On Tue, Jan 13, 2015 at 4:27 AM, Oded Gabbay wrote:
> From: Ben Goz
>
> This patch fixes a minor bug in allocate_hqd(), where the loop run from the
> next-to-allocate pipe until the number of pipes.
>
> This is wrong because we need to consider the possibility where
> next-to-allocate pipe is not
On Tue, Jan 13, 2015 at 3:40 AM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhorst
Does this fix anything or is it purely cosmetic?
Alex
> ---
> diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
> b/drivers/gpu/drm/radeon/radeon_fb.c
> index 29b9220ec399..3d201e937571 100644
> --- a/d
Op 13-01-15 om 15:51 schreef Alex Deucher:
> On Tue, Jan 13, 2015 at 3:40 AM, Maarten Lankhorst
> wrote:
>> Signed-off-by: Maarten Lankhorst
> Does this fix anything or is it purely cosmetic?
It gets rid of unnecessarily switching to the suspend console, resulting in no
longer having a xorg vt s
On Tue, Jan 13, 2015 at 9:55 AM, Maarten Lankhorst
wrote:
> Op 13-01-15 om 15:51 schreef Alex Deucher:
>> On Tue, Jan 13, 2015 at 3:40 AM, Maarten Lankhorst
>> wrote:
>>> Signed-off-by: Maarten Lankhorst
>> Does this fix anything or is it purely cosmetic?
> It gets rid of unnecessarily switching
On 01/13/2015 12:08 AM, Daniel Vetter wrote:
> On Fri, Jan 9, 2015 at 1:50 PM, Jani Nikula wrote:
>> I have a slightly uneasy feeling about handing out drm_panel pointers
>> (both from here and of_drm_find_panel) without refcounting. If the panel
>> driver gets removed, whoever called the find fun
On Tue, 13 Jan 2015 12:27:15 +
Russell King - ARM Linux wrote:
> On Tue, Jan 13, 2015 at 01:21:58PM +0100, Philipp Zabel wrote:
> > I wonder if it wouldn't be nicer to have the AP# and type in the device
> > tree and then calculate the register value from that in the driver.
> >
> > port
From: Rob Clark
libdrm_freedreno currently supports two backends, 'msm' for the upstream
drm/msm driver, and 'kgsl' which supports (to some extent), the android/
downstream kgsl driver plus a sort of drm shim nonsense to get flink
names.
However, kgsl support is strictly on a best-effort basis.
From: Rob Clark
Now that enabling freedreno doesn't automatically enable kgsl, lets
enable it by default. The drm/msm driver has been upstream for a
while now, and it's ABI is locked. So I don't think we need to keep
calling it experimental.
Signed-off-by: Rob Clark
---
configure.ac | 8
On Tue, Jan 13, 2015 at 04:54:11PM +0100, Jean-Francois Moine wrote:
> 4 streams on 4 different APs (sources) should work, but 4 streams from
> a same source should be detailed.
I'd like to know how you intend to wire up four different I2S sources
to the TDA998x.
Remember, an I2S source produces
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #6 from Andy Furniss ---
(In reply to Alex Deucher from comment #5)
> Does forcing the GPU clocks to high help? E.g., as root:
> echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
Doesn't help for me.
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #7 from Alex Deucher ---
If you are using CPU governor, does forcing the CPU power state to a stable
state help?
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #8 from Andy Furniss ---
(In reply to Alex Deucher from comment #7)
> If you are using CPU governor, does forcing the CPU power state to a stable
> state help?
No, I've tried many things as recorded in the FDO bug I linked.
It's cert
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #9 from Christian Birchinger ---
"make -j8" gets usable sound here too.
In my case it's an Intel i7-4770 system.
The only hardware i swaped out was a 5570 for a R9 280X.
--
You are receiving this mail because:
You are watching the
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/cik.c | 3 +-
drivers/gpu/drm/radeon/dce6_afmt.c| 54 -
drivers/gpu/drm/radeon/evergreen.c| 3 +-
driv
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 35 +++-
drivers/gpu/drm/radeon/dce6_afmt.c | 34 +++-
drivers/gpu/drm/radeon/evergreen_hdmi.c | 38 -
drivers/gpu/drm/radeo
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 49 ++-
drivers/gpu/drm/radeon/dce6_afmt.c | 50 ---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 54 ++---
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce6_afmt.c | 16 +
drivers/gpu/drm/radeon/evergreen_hdmi.c | 33 --
drivers/gpu/drm/radeon/radeon_audio.c | 62 +
drivers/gp
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce6_afmt.c | 9 +--
drivers/gpu/drm/radeon/radeon.h| 3 +
drivers/gpu/drm/radeon/radeon_audio.c | 96 +-
drivers/gpu/drm/radeon/rade
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 2 +-
drivers/gpu/drm/radeon/evergreen_hdmi.c | 3 +--
drivers/gpu/drm/radeon/r600_hdmi.c | 3 ++-
drivers/gpu/drm/radeon/radeon_audio.c | 19 +
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 6 +-
drivers/gpu/drm/radeon/radeon_audio.c | 11 +++
drivers/gpu/drm/radeon/radeon_audio.h | 2 ++
3 files changed, 14 insertions(+), 5 deletions(-)
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cik.c | 2 +-
drivers/gpu/drm/radeon/dce6_afmt.c| 13 -
drivers/gpu/drm/radeon/evergreen.c| 4 ++--
drivers/gpu/drm/radeon/ni.c | 5 +
drivers
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 56 +++-
drivers/gpu/drm/radeon/dce6_afmt.c | 39 ++
drivers/gpu/drm/radeon/evergreen_hdmi.c | 92 -
dri
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 38 +--
drivers/gpu/drm/radeon/evergreen_hdmi.c | 46 ++---
drivers/gpu/drm/radeon/r600_hdmi.c | 117 +---
drivers/gpu
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 9 +
drivers/gpu/drm/radeon/evergreen_hdmi.c | 20
drivers/gpu/drm/radeon/r600_hdmi.c | 17 -
drivers/gpu/drm/radeon/r
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 3 ---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c
b/drivers/gpu/drm/radeon/dce3
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 2 +
drivers/gpu/drm/radeon/evergreen_hdmi.c | 69 +
drivers/gpu/drm/radeon/r600_hdmi.c | 1 +
drivers/gpu/drm/radeon/radeon_audio
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 2 +-
drivers/gpu/drm/radeon/evergreen_hdmi.c | 16 +---
drivers/gpu/drm/radeon/r600_hdmi.c | 14 --
drivers/gpu/drm/radeon/radeon_audio.c
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 4 ++--
drivers/gpu/drm/radeon/dce6_afmt.c | 2 +-
drivers/gpu/drm/radeon/evergreen_hdmi.c | 18 --
drivers/gpu/drm/radeon/r600_hdmi.c | 9 +
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 22 +++--
drivers/gpu/drm/radeon/evergreen_hdmi.c | 34 --
drivers/gpu/drm/radeon/r600_hdmi.c | 31
dri
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 6 --
drivers/gpu/drm/radeon/evergreen_hdmi.c | 6 --
drivers/gpu/drm/radeon/r600_hdmi.c | 6 --
3 files changed, 18 deletions(-)
diff --git a/drivers/
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 21 +++--
drivers/gpu/drm/radeon/radeon_asic.c | 14 --
drivers/gpu/drm/radeon/radeon_asic.h | 2 --
drivers/gpu/drm/radeon/r
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 56 ++
drivers/gpu/drm/radeon/evergreen_hdmi.c | 84
drivers/gpu/drm/radeon/r600_hdmi.c | 85 +-
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/dce3_1_afmt.c| 15 ---
drivers/gpu/drm/radeon/evergreen_hdmi.c | 17 +
drivers/gpu/drm/radeon/r600_hdmi.c | 16
drivers/gpu/drm/radeon
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 4 +-
drivers/gpu/drm/radeon/dce3_1_afmt.c | 41 -
drivers/gpu/drm/radeon/evergreen_hdmi.c| 41 -
drivers/gpu/drm/radeon/r6
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_audio.c | 78 +++
1 file changed, 43 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_audio.c
b/drivers/gpu/drm/radeon/rad
From: Slava Grigorev
Signed-off-by: Slava Grigorev
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 6
drivers/gpu/drm/radeon/dce6_afmt.c | 35 +++
drivers/gpu/drm/radeon/evergreen_hdmi.c| 54 ++
drivers/
This patch set cleans up the radeon audio handling
and also adds support for DP audio on all supported
asics.
Alex Deucher (1):
drm/radeon: whitespace clean up in radeon_audio.c
Slava Grigorev (23):
radeon/audio: consolidate audio_init() functions
radeon/audio: defined initial audio interfa
Clean up some formatting in radeon_audio.c to be
more consistent with the rest of the driver.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_audio.c | 70 +--
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rad
On Tue, Jan 13, 2015 at 06:03:38PM +0530, Sonika Jindal wrote:
> This adds another parameter rotation to drm_plane_helper_check_update.
> This will enable this function to do to size updations based upon the rotation
> if any.
> Updated the calls to this function in i915 and drm. Rockchip driver al
a smaller console font?
>
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/385f92a5/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/7643d95e/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/59e82671/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/6d3b5569/attachment.html>
On Tue, 13 Jan 2015 16:03:13 +
Russell King - ARM Linux wrote:
> On Tue, Jan 13, 2015 at 04:54:11PM +0100, Jean-Francois Moine wrote:
> > 4 streams on 4 different APs (sources) should work, but 4 streams from
> > a same source should be detailed.
>
> I'd like to know how you intend to wire u
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/20150113/d60d35bb/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/f2a3b7a8/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/860f26d0/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150113/aaf5429a/attachment-0001.html>
On Tue, Jan 13, 2015 at 08:02:52PM +0100, Jean-Francois Moine wrote:
> On Tue, 13 Jan 2015 16:03:13 +
> Russell King - ARM Linux wrote:
>
> > On Tue, Jan 13, 2015 at 04:54:11PM +0100, Jean-Francois Moine wrote:
> > > 4 streams on 4 different APs (sources) should work, but 4 streams from
> > >
/ilH6em3eIrY
>
> The link says the video is private.
try now
--
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/20150113/60ad8e7f/attachment.html>
Instead of reporting BUG_ON when resources arrays are not
dimensioned correctly, this patch does a dynamic allocation of
these arrays. This is needed for the following patches that add a
regulator for a new target.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 28 +++
On Tue, Jan 13, 2015 at 09:41:01PM +0200, Jyri Sarha wrote:
> On 01/13/2015 09:26 PM, Russell King - ARM Linux wrote:
> >SCLK: _~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_~_
> > WS: __~
> >I2S1: llmm.
c.
--
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/20150113/b43d3206/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=90861
--- Comment #7 from Jon Arne Jørgensen ---
I retried some kernels, and it seems like the problem was introduced in the
3.18 merge window.
In v3.17 I can't reproduce the panic, while in v3.18-rc1 and later I can
reproduce the panic.
I'm trying t
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150113/c5fd70e2/attachment.html>
1 - 100 of 134 matches
Mail list logo
