All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Yuehaibing <yuehaibing@huawei.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: devel@driverdev.osuosl.org, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	yong.zhi@intel.com, hverkuil-cisco@xs4all.nl, mchehab@kernel.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled
Date: Wed, 24 Jul 2019 17:09:54 +0300	[thread overview]
Message-ID: <491dbca1-8a58-b26e-cf56-a1a419da288f@gmail.com> (raw)
In-Reply-To: <0c08bdae-facc-0f28-0e58-17a65172587a@huawei.com>

24.07.2019 17:03, Yuehaibing пишет:
> On 2019/7/24 21:49, Robin Murphy wrote:
>> On 24/07/2019 11:30, Sakari Ailus wrote:
>>> Hi Yue,
>>>
>>> On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
>>>> If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA to m.
>>>> But for many drivers, they use "select IOMMU_IOVA if IOMMU_SUPPORT"
>>>> in the Kconfig, for example, CONFIG_TEGRA_VDE is set to y but IOMMU_IOVA
>>>> is m, then the building fails like this:
>>>>
>>>> drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
>>>> iommu.c:(.text+0x41): undefined reference to `alloc_iova'
>>>> iommu.c:(.text+0x56): undefined reference to `__free_iova'
>>>>
>>>> Reported-by: Hulk Robot <hulkci@huawei.com>
>>>> Fixes: 7fc7af649ca7 ("media: staging/intel-ipu3: Add imgu top level pci device driver")
>>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>>> ---
>>>>   drivers/staging/media/ipu3/Kconfig | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/staging/media/ipu3/Kconfig b/drivers/staging/media/ipu3/Kconfig
>>>> index 4b51c67..b7df18f 100644
>>>> --- a/drivers/staging/media/ipu3/Kconfig
>>>> +++ b/drivers/staging/media/ipu3/Kconfig
>>>> @@ -4,7 +4,7 @@ config VIDEO_IPU3_IMGU
>>>>       depends on PCI && VIDEO_V4L2
>>>>       depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
>>>>       depends on X86
>>>> -    select IOMMU_IOVA
>>>> +    select IOMMU_IOVA if IOMMU_SUPPORT
>>>
>>> This doesn't seem right: the ipu3-cio2 driver needs IOMMU_IOVA
>>> independently of IOMMU_SUPPORT.
>>>
>>> Looking at tegra-vde, it seems to depend on IOMMU_SUPPORT but that's not
>>> declared in its Kconfig entry. I wonder if adding that would be the right
>>> way to fix this.
>>>
>>> Cc'ing the IOMMU list.
IOMMU_SUPPORT is optional for the Tegra-VDE driver.

>> Right, I also had the impression that we'd made the IOVA library completely standalone. And what does the IPU3 driver's Kconfig have to do with some *other* driver failing to link anyway?

I can see it failing if IPU3 is compiled as a loadable module, while
Tegra-VDE is a built-in driver. Hence IOVA lib should be also a kernel
module and thus the IOVA symbols will be missing during of linkage of
the VDE driver.

> Oh, I misunderstand that IOMMU_IOVA is depend on IOMMU_SUPPORT, thank you for clarification.
> 
> I will try to fix this in tegra-vde.

Probably IOVA could be selected independently of IOMMU_SUPPORT, but IOVA
library isn't needed for the VDE driver if IOMMU_SUPPORT is disabled.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Yuehaibing <yuehaibing@huawei.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: devel@driverdev.osuosl.org, linux-media@vger.kernel.org,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, hverkuil-cisco@xs4all.nl,
	mchehab@kernel.org, yong.zhi@intel.com
Subject: Re: [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled
Date: Wed, 24 Jul 2019 17:09:54 +0300	[thread overview]
Message-ID: <491dbca1-8a58-b26e-cf56-a1a419da288f@gmail.com> (raw)
In-Reply-To: <0c08bdae-facc-0f28-0e58-17a65172587a@huawei.com>

24.07.2019 17:03, Yuehaibing пишет:
> On 2019/7/24 21:49, Robin Murphy wrote:
>> On 24/07/2019 11:30, Sakari Ailus wrote:
>>> Hi Yue,
>>>
>>> On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
>>>> If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA to m.
>>>> But for many drivers, they use "select IOMMU_IOVA if IOMMU_SUPPORT"
>>>> in the Kconfig, for example, CONFIG_TEGRA_VDE is set to y but IOMMU_IOVA
>>>> is m, then the building fails like this:
>>>>
>>>> drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
>>>> iommu.c:(.text+0x41): undefined reference to `alloc_iova'
>>>> iommu.c:(.text+0x56): undefined reference to `__free_iova'
>>>>
>>>> Reported-by: Hulk Robot <hulkci@huawei.com>
>>>> Fixes: 7fc7af649ca7 ("media: staging/intel-ipu3: Add imgu top level pci device driver")
>>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>>> ---
>>>>   drivers/staging/media/ipu3/Kconfig | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/staging/media/ipu3/Kconfig b/drivers/staging/media/ipu3/Kconfig
>>>> index 4b51c67..b7df18f 100644
>>>> --- a/drivers/staging/media/ipu3/Kconfig
>>>> +++ b/drivers/staging/media/ipu3/Kconfig
>>>> @@ -4,7 +4,7 @@ config VIDEO_IPU3_IMGU
>>>>       depends on PCI && VIDEO_V4L2
>>>>       depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
>>>>       depends on X86
>>>> -    select IOMMU_IOVA
>>>> +    select IOMMU_IOVA if IOMMU_SUPPORT
>>>
>>> This doesn't seem right: the ipu3-cio2 driver needs IOMMU_IOVA
>>> independently of IOMMU_SUPPORT.
>>>
>>> Looking at tegra-vde, it seems to depend on IOMMU_SUPPORT but that's not
>>> declared in its Kconfig entry. I wonder if adding that would be the right
>>> way to fix this.
>>>
>>> Cc'ing the IOMMU list.
IOMMU_SUPPORT is optional for the Tegra-VDE driver.

>> Right, I also had the impression that we'd made the IOVA library completely standalone. And what does the IPU3 driver's Kconfig have to do with some *other* driver failing to link anyway?

I can see it failing if IPU3 is compiled as a loadable module, while
Tegra-VDE is a built-in driver. Hence IOVA lib should be also a kernel
module and thus the IOVA symbols will be missing during of linkage of
the VDE driver.

> Oh, I misunderstand that IOMMU_IOVA is depend on IOMMU_SUPPORT, thank you for clarification.
> 
> I will try to fix this in tegra-vde.

Probably IOVA could be selected independently of IOMMU_SUPPORT, but IOVA
library isn't needed for the VDE driver if IOMMU_SUPPORT is disabled.

  reply	other threads:[~2019-07-24 14:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22 13:47 [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled YueHaibing
2019-07-24 10:30 ` Sakari Ailus
2019-07-24 10:30   ` Sakari Ailus
2019-07-24 13:49   ` Robin Murphy
2019-07-24 13:49     ` Robin Murphy
2019-07-24 14:03     ` Yuehaibing
2019-07-24 14:03       ` Yuehaibing
2019-07-24 14:09       ` Dmitry Osipenko [this message]
2019-07-24 14:09         ` Dmitry Osipenko
2019-07-24 14:23         ` Robin Murphy
2019-07-24 14:23           ` Robin Murphy
2019-07-24 14:28           ` Dmitry Osipenko
2019-07-24 14:28             ` Dmitry Osipenko
2019-07-25  2:41             ` [PATCH] media: staging: tegra-vde: Fix build error YueHaibing
2019-07-25  2:41               ` YueHaibing
2019-07-25  2:41               ` YueHaibing
2019-07-25  7:19               ` Dmitry Osipenko
2019-07-25  7:19                 ` Dmitry Osipenko
2019-09-20 19:32                 ` Arnd Bergmann
2019-09-20 19:32                   ` Arnd Bergmann
2019-09-20 22:26                   ` Dmitry Osipenko
2019-09-20 22:26                     ` Dmitry Osipenko
2019-09-20 22:26                     ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=491dbca1-8a58-b26e-cf56-a1a419da288f@gmail.com \
    --to=digetx@gmail.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=yong.zhi@intel.com \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.