Sorry for late.
2014-12-17 16:54 GMT+09:00 Thierry Reding :
> On Mon, Dec 01, 2014 at 05:16:17PM +0100, Tobias Jakobi wrote:
>> On 2014-12-01 16:54, Thierry Reding wrote:
>> >On Sun, Nov 30, 2014 at 01:35:25AM +0100, tjakobi at math.uni-bielefeld.de
>> >wrote:
>> >>From: Tomasz Stanislawski
>> >
Hi Philipp,
On 12/19/2014 06:17 PM, Philipp Zabel wrote:
> Hi Liu,
>
> Am Freitag, den 19.12.2014, 13:53 +0800 schrieb Liu Ying:
> [...]
+ mipi_dsi: mipi at 021e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
On 12/21/2014 06:10 PM, Christian König wrote:
> Am 21.12.2014 um 17:03 schrieb Oded Gabbay:
>>
>>
>> On 12/21/2014 05:57 PM, Christian König wrote:
There should be, but when the modules are compiled in, they are loaded
based on
link order only, if they are in the same group, an
> There should be, but when the modules are compiled in, they are loaded
> based on
> link order only, if they are in the same group, and the groups are
> loaded by a
> pre-defined order.
Is that really still up to date? I've seen effort to change that
something l
https://bugzilla.kernel.org/show_bug.cgi?id=88921
Aaron Lu changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
On 12/22/2014 09:40 AM, Dave Airlie wrote:
>> There should be, but when the modules are compiled in, they are loaded
>> based on
>> link order only, if they are in the same group, and the groups are
>> loaded by a
>> pre-defined order.
>
> Is that really still up to da
Am 22.12.2014 um 08:43 schrieb Oded Gabbay:
>
>
> On 12/22/2014 09:40 AM, Dave Airlie wrote:
>>> There should be, but when the modules are compiled in, they are
>>> loaded
>>> based on
>>> link order only, if they are in the same group, and the groups are
>>> loaded by a
>>
On 12/22/2014 10:57 AM, Christian König wrote:
> Am 22.12.2014 um 08:43 schrieb Oded Gabbay:
>>
>>
>> On 12/22/2014 09:40 AM, Dave Airlie wrote:
There should be, but when the modules are compiled in, they are loaded
based on
link order only, if they are in the same gro
On 12/22/2014 11:26 AM, Oded Gabbay wrote:
>
>
> On 12/22/2014 10:57 AM, Christian König wrote:
>> Am 22.12.2014 um 08:43 schrieb Oded Gabbay:
>>>
>>>
>>> On 12/22/2014 09:40 AM, Dave Airlie wrote:
> There should be, but when the modules are compiled in, they are loaded
> based o
This small patch-set, was created to solve the bug described at
https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when
trying use amdkfd driver on Kaveri). It replaces the previous patch-set called
[PATCH 0/3] Use workqueue for device init in amdkfd
(http://lists.freedesktop.org/ar
AMD GPU devices are dependent on AMD IOMMU controller functionality to allow
the GPU to access a process's virtual memory address space, without the need
for pinning the memory.
This patch changes the order in the drivers makefile, so iommu/ subsystem is
linked before gpu/ subsystem. That way, if
When amdkfd and radeon are compiled inside the kernel image (not as modules),
radeon will load before amdkfd, which will cause a bug when radeon will probe
the GPUs.
When the two drivers are compiled as modules, amdkfd is loaded after radeon is
loaded but before radeon starts probing the GPUs. Thi
amdkfd driver can be compiled only in 64-bit kernel. Therefore, there is no
point in trying to initialize amdkfd in 32-bit kernel.
In addition, in case of specific configuration of 32-bit kernel, no modules and
random kernel base, the symbol_request function doesn't work as expected - It
doesn't r
For this series: Reviewed-by: Christian König
Am 22.12.2014 um 12:07 schrieb Oded Gabbay:
> This small patch-set, was created to solve the bug described at
> https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when
> trying use amdkfd driver on Kaveri). It replaces the previous patch
On Sun, Dec 21, 2014 at 11:43 AM, Bruno Prémont
wrote:
> On !SMP systems spinlocks do not exist. Thus checking of they
> are active will always fail.
>
> Use
> assert_spin_locked(lock);
> instead of
> BUG_ON(!spin_is_locked(lock));
> to not BUG() on all UP systems.
>
Thanks, I have this queu
.
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141222/bc4dae0b/attachment.sig>
On Sun, Dec 21, 2014 at 11:43 AM, Bruno Prémont
wrote:
> On !SMP systems spinlocks do not exist. Thus checking of they
> are active will always fail.
>
> Use
> assert_spin_locked(lock);
> instead of
> BUG_ON(!spin_is_locked(lock));
> to not BUG() on all UP systems.
>
> Signed-off-by: Bruno Pr
On Mon, 22 Dec 2014 08:46:48 -0500 Rob Clark wrote:
> On Sun, Dec 21, 2014 at 11:43 AM, Bruno Prémont wrote:
> > On !SMP systems spinlocks do not exist. Thus checking of they
> > are active will always fail.
> >
> > Use
> > assert_spin_locked(lock);
> > instead of
> > BUG_ON(!spin_is_locked(lo
Hi,
next try for v3.20. After the merge window we have a few new users of
of_graph_get_next_endpoint, could I please get some acks from the respective
maintainers for this to go in through Grant's tree?
This series converts all existing users of of_graph_get_next_endpoint that pass
a non-NULL pre
Decrementing the reference count of the previous endpoint node allows to
use the of_graph_get_next_endpoint function in a for_each_... style macro.
All current users of this function that pass a non-NULL prev parameter
(that is, soc_camera and imx-drm) are changed to not decrement the passed
prev a
Note that while of_graph_get_next_endpoint decrements the reference count
of the child node passed to it, of_node_put(child) still has to be called
manually when breaking out of the loop.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
include/linux/of_graph.h | 11 +++
1 fi
This patch adds a function to get a port device tree node by port id,
or reg property value.
Signed-off-by: Philipp Zabel
Acked-by: Laurent Pinchart
---
drivers/of/base.c| 26 ++
include/linux/of_graph.h | 7 +++
2 files changed, 33 insertions(+)
diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=88921
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay wrote:
> amdkfd driver can be compiled only in 64-bit kernel. Therefore, there is no
> point in trying to initialize amdkfd in 32-bit kernel.
>
> In addition, in case of specific configuration of 32-bit kernel, no modules
> and
> random kernel base, th
On Sun, Dec 21, 2014 at 3:05 PM, Siavash Eliasi
wrote:
> Hello, are these patches merged yet? or are they on the queue for Linux
> kernel 3.19?
>
> And how they (shader/memory clocks) should be queried?
They are not merged yet. There were some changes I wanted to make to
them before going upstr
is 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/20141222/a01e25ba/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/20141222/ab2a2c75/attachment.html>
.
--
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/20141222/e7832515/attachment.html>
On 12/22/2014 09:00 PM, Andi Kleen wrote:
> On Mon, Dec 22, 2014 at 10:49:40AM -0800, Andi Kleen wrote:
>> On Mon, Dec 22, 2014 at 11:58:43AM -0500, Alex Deucher wrote:
>>> On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay wrote:
amdkfd driver can be compiled only in 64-bit kernel. Therefore, th
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141222/e363f9dc/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/20141222/e3336bb1/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141222/c5c6592a/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141222/50877884/attachment.html>
Hi Russell,
On Sat, Dec 20, 2014 at 03:52:54PM +, Russell King - ARM Linux wrote:
> On Thu, Dec 18, 2014 at 06:00:23PM -0800, Steve Longerbeam wrote:
> > Ask the IPU display interface, via ipu_di_adjust_videomode(), to
> > adjust a video mode to meet any DI restrictions. The function takes
> >
Since commit ab78029ecc34 (drivers/pinctrl: grab default handles from device
core), we can rely on device core for setting the default pins.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 7 ---
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 7 ---
drivers/gpu/drm/til
Hi Russell,
On Sun, Dec 21, 2014 at 03:58:19PM +, Russell King wrote:
> We do not need to track the state of the IPU DI's clock flags by having
> each display bridge calling back into imx-drm-core, and then back out
> into ipuv3-crtc.c.
>
> ipuv3-crtc can instead just scan the list of encoder
On Mon, Dec 22, 2014 at 11:58:43AM -0500, Alex Deucher wrote:
> On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay wrote:
> > amdkfd driver can be compiled only in 64-bit kernel. Therefore, there is no
> > point in trying to initialize amdkfd in 32-bit kernel.
> >
> > In addition, in case of specific co
On Mon, Dec 22, 2014 at 10:49:40AM -0800, Andi Kleen wrote:
> On Mon, Dec 22, 2014 at 11:58:43AM -0500, Alex Deucher wrote:
> > On Mon, Dec 22, 2014 at 6:11 AM, Oded Gabbay wrote:
> > > amdkfd driver can be compiled only in 64-bit kernel. Therefore, there is
> > > no
> > > point in trying to init
On 22 December 2014 at 08:11, Philipp Zabel wrote:
> Decrementing the reference count of the previous endpoint node allows to
> use the of_graph_get_next_endpoint function in a for_each_... style macro.
> All current users of this function that pass a non-NULL prev parameter
> (that is, soc_camera
39 matches
Mail list logo
