[PATCH] drm/amdgpu: Add amdkfd softdep

2016-08-29 Thread Michal Marek
On 2016-08-29 03:37, Michel Dänzer wrote:
> On 26/08/16 06:16 PM, Michal Marek wrote:
>> It's a soft dependency, so it will be silently ignored. /sbin/modprobe
>> --show-depends amdgpu will only list amdgpu.ko and its hard depedencies.
> 
> Thanks for the clarification.
> 
> The radeon driver probably needs this as well?

You are right. I sent a v2 covering radeon as well.

Thanks,
Michal


[PATCH v2] amdgpu, radeon: Add amdkfd softdep

2016-08-29 Thread Michal Marek
Both amdgpu and radeon load amdkfd via symbol_request(). Add a softdep
hint so that userspace knows that each of them needs amdkfd in the
initrd.

Reported-and-tested-by: Martin Jambor  [amdgpu]
Reported-by: Michel Dänzer  [radeon]
Signed-off-by: Michal Marek 
---
v2: Also patch radeon

 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
 drivers/gpu/drm/radeon/radeon_drv.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 9aa533cf4ad1..9c469cd311ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
+MODULE_SOFTDEP("pre: amdkfd");
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index c01a7c6abb49..0a60125c0138 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -617,3 +617,4 @@ module_exit(radeon_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
+MODULE_SOFTDEP("pre: amdkfd");
-- 
2.6.6



[PATCH] drm/amdgpu: Add amdkfd softdep

2016-08-26 Thread Michal Marek
On 2016-08-26 04:20, Michel Dänzer wrote:
> On 26/08/16 02:10 AM, Michal Marek wrote:
>> amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that
>> userspace knows that amdgpu needs amdkfd in the initrd.
>>
>> Reported-and-tested-by: Martin Jambor 
>> Signed-off-by: Michal Marek 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index 9aa533cf4ad1..9c469cd311ca 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
>>  MODULE_AUTHOR(DRIVER_AUTHOR);
>>  MODULE_DESCRIPTION(DRIVER_DESC);
>>  MODULE_LICENSE("GPL and additional rights");
>> +MODULE_SOFTDEP("pre: amdkfd");
> 
> Will this work if amdkfd isn't built (CONFIG_HSA_AMD=n)?

It's a soft dependency, so it will be silently ignored. /sbin/modprobe
--show-depends amdgpu will only list amdgpu.ko and its hard depedencies.

Michal



[PATCH] drm/amdgpu: Add amdkfd softdep

2016-08-25 Thread Michal Marek
amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that
userspace knows that amdgpu needs amdkfd in the initrd.

Reported-and-tested-by: Martin Jambor 
Signed-off-by: Michal Marek 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 9aa533cf4ad1..9c469cd311ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
+MODULE_SOFTDEP("pre: amdkfd");
-- 
2.6.6



[PATCH v2 05/11] Kbuild: don't add obj tree in additional includes

2016-07-18 Thread Michal Marek
On Wed, Jun 15, 2016 at 05:45:47PM +0200, Arnd Bergmann wrote:
> When building with separate object directories and driver specific
> Makefiles that add additional header include paths, Kbuild adjusts
> the gcc flags so that we include both the directory in the source
> tree and in the object tree.
> 
> However, due to another bug I fixed earlier, this did not actually
> include the correct directory in the object tree, so we know that
> we only really need the source tree here. Also, including the
> object tree sometimes causes warnings about nonexisting directories
> when the include path only exists in the source.
> 
> This changes the logic to only emit the -I argument for the srctree,
> not for objects. We still need both $(srctree)/$(src) and $(obj)
> though, so I'm adding them manually.
> 
> Signed-off-by: Arnd Bergmann 

Hi Arnd,

I applied the series up to this patch to kbuild.git#kbuild. The rest
seem to be related but not dependent patches, so I'll leave it up to the
respective maintainers to pick them up. Is that OK with you?

Thanks,
Michal


[PATCH 3/3] Revert "drm: Hack around CONFIG_AGP=m build failures"

2015-10-28 Thread Michal Marek
Dne 28.10.2015 v 20:27 Jani Nikula napsal(a):
> On Wed, 28 Oct 2015, Toralf Förster  wrote:
>>> From: Michal Marek 
>>
>>> Kbuild now supports -m variables.
>>
>>> This reverts commit 8fa884dc355ffd0caa964a284a530bf747df5c77.
>>
>> Which is not in mainline, or ?
> 
> It's in drm-next.
> 
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=8fa884dc355ffd0caa964a284a530bf747df5c77

Right, but this revert cannot be applied before the preceding patches
are merged, i.e. after the merge window.

Michal



[PATCH 3/3] Revert "drm: Hack around CONFIG_AGP=m build failures"

2015-10-28 Thread Michal Marek
From: Michal Marek <mma...@suse.com>

Kbuild now supports -m variables.

This reverts commit 8fa884dc355ffd0caa964a284a530bf747df5c77.

Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Michal Marek 
---
 drivers/gpu/drm/Makefile | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e814517..f458d6e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -21,8 +21,6 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o

-drm-y += $(drm-m)
-
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-- 
1.9.2



[PATCH] drm: Hack around CONFIG_AGP=m build failures

2015-10-01 Thread Michal Marek
On 2015-10-01 16:50, Michal Marek wrote:
> On 2015-10-01 12:17, Daniel Vetter wrote:
>> On Thu, Oct 01, 2015 at 11:58:32AM +0200, Michal Marek wrote:
>>> On 2015-10-01 10:19, Jani Nikula wrote:
>>>> On Thu, 01 Oct 2015, Daniel Vetter  wrote:
>>>>> Surprisingly kbuild can't cope with tristates in the
>>>>> -$(CONFIG_FOO) pattern. This patch hacks up a solution.
>>>>
>>>> Given that it's two distinct Makefile variables (foo-y and foo-m) being
>>>> assigned to, I don't really find this surprising. Maybe this could be
>>>> made to work as a convenience, but there might be other, more surpising
>>>> consequences.
>>>
>>> I actually think that kbuild should be able to handle this. The likely
>>> reason why it is not doing it right now is that in an ideal world,
>>> modules are modules can be built out of tree against just the kernel and
>>> their static dependencies. In real world, we sometimes have features in
>>> modules that are enabled if other modules are enabled. I'll post a patch
>>> later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in
>>> built-in code, which is a similar case.
>>
>> Cool. I'll keep this hack in drm-misc then. Please cc me on the proper
>> solution so I know when I can revert it again.
> 
> It's not as trivial as it seemed, because there are at least three
> Makefiles that rely on the current behavior:
> 
> init/Makefile
> drivers/misc/ibmasm/Makefile
> fs/logfs/Makefile

drivers/usb/chipidea is also on the list.

Michal


[PATCH] drm: Hack around CONFIG_AGP=m build failures

2015-10-01 Thread Michal Marek
On 2015-10-01 12:17, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 11:58:32AM +0200, Michal Marek wrote:
>> On 2015-10-01 10:19, Jani Nikula wrote:
>>> On Thu, 01 Oct 2015, Daniel Vetter  wrote:
>>>> Surprisingly kbuild can't cope with tristates in the
>>>> -$(CONFIG_FOO) pattern. This patch hacks up a solution.
>>>
>>> Given that it's two distinct Makefile variables (foo-y and foo-m) being
>>> assigned to, I don't really find this surprising. Maybe this could be
>>> made to work as a convenience, but there might be other, more surpising
>>> consequences.
>>
>> I actually think that kbuild should be able to handle this. The likely
>> reason why it is not doing it right now is that in an ideal world,
>> modules are modules can be built out of tree against just the kernel and
>> their static dependencies. In real world, we sometimes have features in
>> modules that are enabled if other modules are enabled. I'll post a patch
>> later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in
>> built-in code, which is a similar case.
> 
> Cool. I'll keep this hack in drm-misc then. Please cc me on the proper
> solution so I know when I can revert it again.

It's not as trivial as it seemed, because there are at least three
Makefiles that rely on the current behavior:

init/Makefile
drivers/misc/ibmasm/Makefile
fs/logfs/Makefile

While ibmasm and logfs can and probably should be fixed to work with
modular 8250 and mtd, respectively, init/Makefile would need a
workaround to only pick up do_mounts_rd.o and do_mounts_md.o if the
respective block drivers are built-in. So we would be trading one hack
for another.

Michal


[PATCH] drm: Hack around CONFIG_AGP=m build failures

2015-10-01 Thread Michal Marek
On 2015-10-01 10:19, Jani Nikula wrote:
> On Thu, 01 Oct 2015, Daniel Vetter  wrote:
>> Surprisingly kbuild can't cope with tristates in the
>> -$(CONFIG_FOO) pattern. This patch hacks up a solution.
> 
> Given that it's two distinct Makefile variables (foo-y and foo-m) being
> assigned to, I don't really find this surprising. Maybe this could be
> made to work as a convenience, but there might be other, more surpising
> consequences.

I actually think that kbuild should be able to handle this. The likely
reason why it is not doing it right now is that in an ideal world,
modules are modules can be built out of tree against just the kernel and
their static dependencies. In real world, we sometimes have features in
modules that are enabled if other modules are enabled. I'll post a patch
later. We also have lots of tests fo CONFIG_FOO || CONFIG_FOO_MODULE in
built-in code, which is a similar case.

Michal