* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 10:27 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 10:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Randy Dunlap, The etnaviv authors, Linux Kernel Mailing List,
dri-devel, Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Masahiro Yamada, Mike Rapoport
On 08.04.21 12:20, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> Random drivers should not override a user configuration of core knobs
>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>> dependencies and manual overrides.
>>
>> "This is similar to "select" as it enforces a lower limit on another
>> symbol except that the "implied" symbol's value may still be set to n
>> from a direct dependency or with a visible prompt."
>>
>> Implying DRM_CMA should be sufficient, as that depends on CMA.
>>
>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>> instead - but I assume the driver can work without CMA just fine --
>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
>
> 'imply' is almost never the right solution, and it tends to cause more
> problems than it solves.
I thought that was the case with "select" :)
>
> In particular, it does not prevent a configuration with 'DRM_CMA=m'
I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
> and 'DRMA_ASPEED_GFX=y', or any build failures from such
> a configuration.
I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
> If you want this kind of soft dependency, you need
> 'depends on DRM_CMA || !DRM_CMA'.
Seriously? I think the point of imply is "please enable if possible and
not prevented by someone else". Your example looks more like a NOP - no?
Or will it have the same effect?
--
Thanks,
David / dhildenb
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 10:27 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 10:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On 08.04.21 12:20, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> Random drivers should not override a user configuration of core knobs
>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>> dependencies and manual overrides.
>>
>> "This is similar to "select" as it enforces a lower limit on another
>> symbol except that the "implied" symbol's value may still be set to n
>> from a direct dependency or with a visible prompt."
>>
>> Implying DRM_CMA should be sufficient, as that depends on CMA.
>>
>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>> instead - but I assume the driver can work without CMA just fine --
>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
>
> 'imply' is almost never the right solution, and it tends to cause more
> problems than it solves.
I thought that was the case with "select" :)
>
> In particular, it does not prevent a configuration with 'DRM_CMA=m'
I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
> and 'DRMA_ASPEED_GFX=y', or any build failures from such
> a configuration.
I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
> If you want this kind of soft dependency, you need
> 'depends on DRM_CMA || !DRM_CMA'.
Seriously? I think the point of imply is "please enable if possible and
not prevented by someone else". Your example looks more like a NOP - no?
Or will it have the same effect?
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 10:27 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 10:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On 08.04.21 12:20, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> Random drivers should not override a user configuration of core knobs
>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>> dependencies and manual overrides.
>>
>> "This is similar to "select" as it enforces a lower limit on another
>> symbol except that the "implied" symbol's value may still be set to n
>> from a direct dependency or with a visible prompt."
>>
>> Implying DRM_CMA should be sufficient, as that depends on CMA.
>>
>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>> instead - but I assume the driver can work without CMA just fine --
>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
>
> 'imply' is almost never the right solution, and it tends to cause more
> problems than it solves.
I thought that was the case with "select" :)
>
> In particular, it does not prevent a configuration with 'DRM_CMA=m'
I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
> and 'DRMA_ASPEED_GFX=y', or any build failures from such
> a configuration.
I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
> If you want this kind of soft dependency, you need
> 'depends on DRM_CMA || !DRM_CMA'.
Seriously? I think the point of imply is "please enable if possible and
not prevented by someone else". Your example looks more like a NOP - no?
Or will it have the same effect?
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 10:27 ` David Hildenbrand
(?)
(?)
@ 2021-04-08 10:36 ` David Hildenbrand
-1 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 10:36 UTC (permalink / raw)
To: linux-aspeed
On 08.04.21 12:27, David Hildenbrand wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
>> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> Random drivers should not override a user configuration of core knobs
>>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>>> dependencies and manual overrides.
>>>
>>> "This is similar to "select" as it enforces a lower limit on another
>>> symbol except that the "implied" symbol's value may still be set to n
>>> from a direct dependency or with a visible prompt."
>>>
>>> Implying DRM_CMA should be sufficient, as that depends on CMA.
>>>
>>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>>> instead - but I assume the driver can work without CMA just fine --
>>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
>>
>> 'imply' is almost never the right solution, and it tends to cause more
>> problems than it solves.
>
> I thought that was the case with "select" :)
>
>>
>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
>
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
>
>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>> a configuration.
>
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
>>
>> If you want this kind of soft dependency, you need
>> 'depends on DRM_CMA || !DRM_CMA'.
>
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else". Your example looks more like a NOP - no?
> Or will it have the same effect?
I just tried (remove CONFIG_DMA_CMA from .config followed by make) and
the default will be set to "N" (when querying the user). So it indeed
looks like a NOP - unless I am missing something.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 10:36 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 10:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Randy Dunlap, The etnaviv authors, Linux Kernel Mailing List,
dri-devel, Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Masahiro Yamada, Mike Rapoport
On 08.04.21 12:27, David Hildenbrand wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
>> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> Random drivers should not override a user configuration of core knobs
>>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>>> dependencies and manual overrides.
>>>
>>> "This is similar to "select" as it enforces a lower limit on another
>>> symbol except that the "implied" symbol's value may still be set to n
>>> from a direct dependency or with a visible prompt."
>>>
>>> Implying DRM_CMA should be sufficient, as that depends on CMA.
>>>
>>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>>> instead - but I assume the driver can work without CMA just fine --
>>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
>>
>> 'imply' is almost never the right solution, and it tends to cause more
>> problems than it solves.
>
> I thought that was the case with "select" :)
>
>>
>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
>
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
>
>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>> a configuration.
>
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
>>
>> If you want this kind of soft dependency, you need
>> 'depends on DRM_CMA || !DRM_CMA'.
>
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else". Your example looks more like a NOP - no?
> Or will it have the same effect?
I just tried (remove CONFIG_DMA_CMA from .config followed by make) and
the default will be set to "N" (when querying the user). So it indeed
looks like a NOP - unless I am missing something.
--
Thanks,
David / dhildenb
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 10:36 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 10:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On 08.04.21 12:27, David Hildenbrand wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
>> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> Random drivers should not override a user configuration of core knobs
>>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>>> dependencies and manual overrides.
>>>
>>> "This is similar to "select" as it enforces a lower limit on another
>>> symbol except that the "implied" symbol's value may still be set to n
>>> from a direct dependency or with a visible prompt."
>>>
>>> Implying DRM_CMA should be sufficient, as that depends on CMA.
>>>
>>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>>> instead - but I assume the driver can work without CMA just fine --
>>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
>>
>> 'imply' is almost never the right solution, and it tends to cause more
>> problems than it solves.
>
> I thought that was the case with "select" :)
>
>>
>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
>
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
>
>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>> a configuration.
>
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
>>
>> If you want this kind of soft dependency, you need
>> 'depends on DRM_CMA || !DRM_CMA'.
>
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else". Your example looks more like a NOP - no?
> Or will it have the same effect?
I just tried (remove CONFIG_DMA_CMA from .config followed by make) and
the default will be set to "N" (when querying the user). So it indeed
looks like a NOP - unless I am missing something.
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 10:36 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 10:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On 08.04.21 12:27, David Hildenbrand wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
>> On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> Random drivers should not override a user configuration of core knobs
>>> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
>>> dependencies and manual overrides.
>>>
>>> "This is similar to "select" as it enforces a lower limit on another
>>> symbol except that the "implied" symbol's value may still be set to n
>>> from a direct dependency or with a visible prompt."
>>>
>>> Implying DRM_CMA should be sufficient, as that depends on CMA.
>>>
>>> Note: If this is a real dependency, we should use "depends on DMA_CMA"
>>> instead - but I assume the driver can work without CMA just fine --
>>> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
>>
>> 'imply' is almost never the right solution, and it tends to cause more
>> problems than it solves.
>
> I thought that was the case with "select" :)
>
>>
>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
>
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
>
>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>> a configuration.
>
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
>>
>> If you want this kind of soft dependency, you need
>> 'depends on DRM_CMA || !DRM_CMA'.
>
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else". Your example looks more like a NOP - no?
> Or will it have the same effect?
I just tried (remove CONFIG_DMA_CMA from .config followed by make) and
the default will be set to "N" (when querying the user). So it indeed
looks like a NOP - unless I am missing something.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 10:27 ` David Hildenbrand
(?)
(?)
@ 2021-04-08 10:44 ` Arnd Bergmann
-1 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 10:44 UTC (permalink / raw)
To: linux-aspeed
On Thu, Apr 8, 2021 at 12:29 PM David Hildenbrand <david@redhat.com> wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> Random drivers should not override a user configuration of core knobs
> >> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> >> dependencies and manual overrides.
> >>
> >> "This is similar to "select" as it enforces a lower limit on another
> >> symbol except that the "implied" symbol's value may still be set to n
> >> from a direct dependency or with a visible prompt."
> >>
> >> Implying DRM_CMA should be sufficient, as that depends on CMA.
> >>
> >> Note: If this is a real dependency, we should use "depends on DMA_CMA"
> >> instead - but I assume the driver can work without CMA just fine --
> >> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
> >
> > 'imply' is almost never the right solution, and it tends to cause more
> > problems than it solves.
>
> I thought that was the case with "select" :)
Yes, but that's a different set of problems
> >
> > In particular, it does not prevent a configuration with 'DRM_CMA=m'
>
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
Ok, at least that makes it easier.
> > and 'DRMA_ASPEED_GFX=y', or any build failures from such
> > a configuration.
>
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
I thought you were trying to solve the problem where DRMA_ASPEED_GFX
can optionally link against CMA but would fail to build when the CMA code
is in a loadable module.
If the problem you are trying to solve is a different one, you need a different
solution, not what I posted above.
> > If you want this kind of soft dependency, you need
> > 'depends on DRM_CMA || !DRM_CMA'.
>
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else".
That used to be the meaning, but it changed a few years ago. Now
it means "when a used manually turns on this symbol, turn on the
implied one as well, but let them turn it off again if they choose".
This is pretty much a NOP.
> Your example looks more like a NOP - no?
> Or will it have the same effect?
The example I gave is only meaningful if both are tristate, which is
not the case here as you explain.
It is a somewhat awkward way to say "prevent this symbol from
being =y if the dependency is =m".
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 10:44 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 10:44 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Randy Dunlap, The etnaviv authors, Linux Kernel Mailing List,
dri-devel, Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Masahiro Yamada, Mike Rapoport
On Thu, Apr 8, 2021 at 12:29 PM David Hildenbrand <david@redhat.com> wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> Random drivers should not override a user configuration of core knobs
> >> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> >> dependencies and manual overrides.
> >>
> >> "This is similar to "select" as it enforces a lower limit on another
> >> symbol except that the "implied" symbol's value may still be set to n
> >> from a direct dependency or with a visible prompt."
> >>
> >> Implying DRM_CMA should be sufficient, as that depends on CMA.
> >>
> >> Note: If this is a real dependency, we should use "depends on DMA_CMA"
> >> instead - but I assume the driver can work without CMA just fine --
> >> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
> >
> > 'imply' is almost never the right solution, and it tends to cause more
> > problems than it solves.
>
> I thought that was the case with "select" :)
Yes, but that's a different set of problems
> >
> > In particular, it does not prevent a configuration with 'DRM_CMA=m'
>
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
Ok, at least that makes it easier.
> > and 'DRMA_ASPEED_GFX=y', or any build failures from such
> > a configuration.
>
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
I thought you were trying to solve the problem where DRMA_ASPEED_GFX
can optionally link against CMA but would fail to build when the CMA code
is in a loadable module.
If the problem you are trying to solve is a different one, you need a different
solution, not what I posted above.
> > If you want this kind of soft dependency, you need
> > 'depends on DRM_CMA || !DRM_CMA'.
>
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else".
That used to be the meaning, but it changed a few years ago. Now
it means "when a used manually turns on this symbol, turn on the
implied one as well, but let them turn it off again if they choose".
This is pretty much a NOP.
> Your example looks more like a NOP - no?
> Or will it have the same effect?
The example I gave is only meaningful if both are tristate, which is
not the case here as you explain.
It is a somewhat awkward way to say "prevent this symbol from
being =y if the dependency is =m".
Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 10:44 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 10:44 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 12:29 PM David Hildenbrand <david@redhat.com> wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> Random drivers should not override a user configuration of core knobs
> >> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> >> dependencies and manual overrides.
> >>
> >> "This is similar to "select" as it enforces a lower limit on another
> >> symbol except that the "implied" symbol's value may still be set to n
> >> from a direct dependency or with a visible prompt."
> >>
> >> Implying DRM_CMA should be sufficient, as that depends on CMA.
> >>
> >> Note: If this is a real dependency, we should use "depends on DMA_CMA"
> >> instead - but I assume the driver can work without CMA just fine --
> >> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
> >
> > 'imply' is almost never the right solution, and it tends to cause more
> > problems than it solves.
>
> I thought that was the case with "select" :)
Yes, but that's a different set of problems
> >
> > In particular, it does not prevent a configuration with 'DRM_CMA=m'
>
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
Ok, at least that makes it easier.
> > and 'DRMA_ASPEED_GFX=y', or any build failures from such
> > a configuration.
>
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
I thought you were trying to solve the problem where DRMA_ASPEED_GFX
can optionally link against CMA but would fail to build when the CMA code
is in a loadable module.
If the problem you are trying to solve is a different one, you need a different
solution, not what I posted above.
> > If you want this kind of soft dependency, you need
> > 'depends on DRM_CMA || !DRM_CMA'.
>
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else".
That used to be the meaning, but it changed a few years ago. Now
it means "when a used manually turns on this symbol, turn on the
implied one as well, but let them turn it off again if they choose".
This is pretty much a NOP.
> Your example looks more like a NOP - no?
> Or will it have the same effect?
The example I gave is only meaningful if both are tristate, which is
not the case here as you explain.
It is a somewhat awkward way to say "prevent this symbol from
being =y if the dependency is =m".
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 10:44 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 10:44 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 12:29 PM David Hildenbrand <david@redhat.com> wrote:
> On 08.04.21 12:20, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> Random drivers should not override a user configuration of core knobs
> >> (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect
> >> dependencies and manual overrides.
> >>
> >> "This is similar to "select" as it enforces a lower limit on another
> >> symbol except that the "implied" symbol's value may still be set to n
> >> from a direct dependency or with a visible prompt."
> >>
> >> Implying DRM_CMA should be sufficient, as that depends on CMA.
> >>
> >> Note: If this is a real dependency, we should use "depends on DMA_CMA"
> >> instead - but I assume the driver can work without CMA just fine --
> >> esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now.
> >
> > 'imply' is almost never the right solution, and it tends to cause more
> > problems than it solves.
>
> I thought that was the case with "select" :)
Yes, but that's a different set of problems
> >
> > In particular, it does not prevent a configuration with 'DRM_CMA=m'
>
> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
Ok, at least that makes it easier.
> > and 'DRMA_ASPEED_GFX=y', or any build failures from such
> > a configuration.
>
> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
I thought you were trying to solve the problem where DRMA_ASPEED_GFX
can optionally link against CMA but would fail to build when the CMA code
is in a loadable module.
If the problem you are trying to solve is a different one, you need a different
solution, not what I posted above.
> > If you want this kind of soft dependency, you need
> > 'depends on DRM_CMA || !DRM_CMA'.
>
> Seriously? I think the point of imply is "please enable if possible and
> not prevented by someone else".
That used to be the meaning, but it changed a few years ago. Now
it means "when a used manually turns on this symbol, turn on the
implied one as well, but let them turn it off again if they choose".
This is pretty much a NOP.
> Your example looks more like a NOP - no?
> Or will it have the same effect?
The example I gave is only meaningful if both are tristate, which is
not the case here as you explain.
It is a somewhat awkward way to say "prevent this symbol from
being =y if the dependency is =m".
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 10:44 ` Arnd Bergmann
(?)
(?)
@ 2021-04-08 11:00 ` David Hildenbrand
-1 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 11:00 UTC (permalink / raw)
To: linux-aspeed
>>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
>>
>> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
>
> Ok, at least that makes it easier.
>
>>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>>> a configuration.
>>
>> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
>> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
> I thought you were trying to solve the problem where DRMA_ASPEED_GFX
> can optionally link against CMA but would fail to build when the CMA code
> is in a loadable module.
Yes. I was trying to say: it works with this patch just fine. The issue
you described does not seem to apply (DRM_CMA=m).
>
>> Your example looks more like a NOP - no?
>> Or will it have the same effect?
>
> The example I gave is only meaningful if both are tristate, which is
> not the case here as you explain.
Okay, thanks.
>
> It is a somewhat awkward way to say "prevent this symbol from
> being =y if the dependency is =m".
What would be the right thing to do in the case here then to achieve the
"if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
One approach could be to have for DMA_CMA
default y if DRMA_ASPEED_GFX
but it feels like the wrong way to tackle this.
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 11:00 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 11:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Randy Dunlap, The etnaviv authors, Linux Kernel Mailing List,
dri-devel, Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Masahiro Yamada, Mike Rapoport
>>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
>>
>> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
>
> Ok, at least that makes it easier.
>
>>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>>> a configuration.
>>
>> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
>> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
> I thought you were trying to solve the problem where DRMA_ASPEED_GFX
> can optionally link against CMA but would fail to build when the CMA code
> is in a loadable module.
Yes. I was trying to say: it works with this patch just fine. The issue
you described does not seem to apply (DRM_CMA=m).
>
>> Your example looks more like a NOP - no?
>> Or will it have the same effect?
>
> The example I gave is only meaningful if both are tristate, which is
> not the case here as you explain.
Okay, thanks.
>
> It is a somewhat awkward way to say "prevent this symbol from
> being =y if the dependency is =m".
What would be the right thing to do in the case here then to achieve the
"if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
One approach could be to have for DMA_CMA
default y if DRMA_ASPEED_GFX
but it feels like the wrong way to tackle this.
Thanks!
--
Thanks,
David / dhildenb
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 11:00 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 11:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
>>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
>>
>> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
>
> Ok, at least that makes it easier.
>
>>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>>> a configuration.
>>
>> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
>> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
> I thought you were trying to solve the problem where DRMA_ASPEED_GFX
> can optionally link against CMA but would fail to build when the CMA code
> is in a loadable module.
Yes. I was trying to say: it works with this patch just fine. The issue
you described does not seem to apply (DRM_CMA=m).
>
>> Your example looks more like a NOP - no?
>> Or will it have the same effect?
>
> The example I gave is only meaningful if both are tristate, which is
> not the case here as you explain.
Okay, thanks.
>
> It is a somewhat awkward way to say "prevent this symbol from
> being =y if the dependency is =m".
What would be the right thing to do in the case here then to achieve the
"if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
One approach could be to have for DMA_CMA
default y if DRMA_ASPEED_GFX
but it feels like the wrong way to tackle this.
Thanks!
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 11:00 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 11:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
>>> In particular, it does not prevent a configuration with 'DRM_CMA=m'
>>
>> I assume you meant "DRM_CMA=n" ? DRM_CMA cannot be built as a module.
>
> Ok, at least that makes it easier.
>
>>> and 'DRMA_ASPEED_GFX=y', or any build failures from such
>>> a configuration.
>>
>> I don't follow. "DRM_CMA=n" and 'DRMA_ASPEED_GFX=y' is supposed to work
>> just fine (e.g., without HAVE_DMA_CONTIGUOUS) or what am I missing?
>
> I thought you were trying to solve the problem where DRMA_ASPEED_GFX
> can optionally link against CMA but would fail to build when the CMA code
> is in a loadable module.
Yes. I was trying to say: it works with this patch just fine. The issue
you described does not seem to apply (DRM_CMA=m).
>
>> Your example looks more like a NOP - no?
>> Or will it have the same effect?
>
> The example I gave is only meaningful if both are tristate, which is
> not the case here as you explain.
Okay, thanks.
>
> It is a somewhat awkward way to say "prevent this symbol from
> being =y if the dependency is =m".
What would be the right thing to do in the case here then to achieve the
"if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
One approach could be to have for DMA_CMA
default y if DRMA_ASPEED_GFX
but it feels like the wrong way to tackle this.
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 11:00 ` David Hildenbrand
(?)
(?)
@ 2021-04-08 11:44 ` Arnd Bergmann
-1 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 11:44 UTC (permalink / raw)
To: linux-aspeed
On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
> >
> > It is a somewhat awkward way to say "prevent this symbol from
> > being =y if the dependency is =m".
>
> What would be the right thing to do in the case here then to achieve the
> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>
> One approach could be to have for DMA_CMA
>
> default y if DRMA_ASPEED_GFX
>
> but it feels like the wrong way to tackle this.
I'm still not sure what you are trying to achieve. Is the idea only to provide
a useful default for DMA_CMA depending on which drivers are enabled?
This is something you could do using a hidden helper symbol like
config DRMA_ASPEED_GFX
bool "Aspeed display driver"
select DRM_WANT_CMA
config DRM_WANT_CMA
bool
help
Select this from any driver that benefits from CMA being enabled
config DMA_CMA
bool "Use CMA helpers for DRM"
default DRM_WANT_CMA
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 11:44 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 11:44 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Randy Dunlap, The etnaviv authors, Linux Kernel Mailing List,
dri-devel, Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Masahiro Yamada, Mike Rapoport
On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
> >
> > It is a somewhat awkward way to say "prevent this symbol from
> > being =y if the dependency is =m".
>
> What would be the right thing to do in the case here then to achieve the
> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>
> One approach could be to have for DMA_CMA
>
> default y if DRMA_ASPEED_GFX
>
> but it feels like the wrong way to tackle this.
I'm still not sure what you are trying to achieve. Is the idea only to provide
a useful default for DMA_CMA depending on which drivers are enabled?
This is something you could do using a hidden helper symbol like
config DRMA_ASPEED_GFX
bool "Aspeed display driver"
select DRM_WANT_CMA
config DRM_WANT_CMA
bool
help
Select this from any driver that benefits from CMA being enabled
config DMA_CMA
bool "Use CMA helpers for DRM"
default DRM_WANT_CMA
Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 11:44 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 11:44 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
> >
> > It is a somewhat awkward way to say "prevent this symbol from
> > being =y if the dependency is =m".
>
> What would be the right thing to do in the case here then to achieve the
> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>
> One approach could be to have for DMA_CMA
>
> default y if DRMA_ASPEED_GFX
>
> but it feels like the wrong way to tackle this.
I'm still not sure what you are trying to achieve. Is the idea only to provide
a useful default for DMA_CMA depending on which drivers are enabled?
This is something you could do using a hidden helper symbol like
config DRMA_ASPEED_GFX
bool "Aspeed display driver"
select DRM_WANT_CMA
config DRM_WANT_CMA
bool
help
Select this from any driver that benefits from CMA being enabled
config DMA_CMA
bool "Use CMA helpers for DRM"
default DRM_WANT_CMA
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 11:44 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 11:44 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
> >
> > It is a somewhat awkward way to say "prevent this symbol from
> > being =y if the dependency is =m".
>
> What would be the right thing to do in the case here then to achieve the
> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>
> One approach could be to have for DMA_CMA
>
> default y if DRMA_ASPEED_GFX
>
> but it feels like the wrong way to tackle this.
I'm still not sure what you are trying to achieve. Is the idea only to provide
a useful default for DMA_CMA depending on which drivers are enabled?
This is something you could do using a hidden helper symbol like
config DRMA_ASPEED_GFX
bool "Aspeed display driver"
select DRM_WANT_CMA
config DRM_WANT_CMA
bool
help
Select this from any driver that benefits from CMA being enabled
config DMA_CMA
bool "Use CMA helpers for DRM"
default DRM_WANT_CMA
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 11:44 ` Arnd Bergmann
(?)
(?)
@ 2021-04-08 12:00 ` David Hildenbrand
-1 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 12:00 UTC (permalink / raw)
To: linux-aspeed
On 08.04.21 13:44, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> It is a somewhat awkward way to say "prevent this symbol from
>>> being =y if the dependency is =m".
>>
>> What would be the right thing to do in the case here then to achieve the
>> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>>
>> One approach could be to have for DMA_CMA
>>
>> default y if DRMA_ASPEED_GFX
>>
>> but it feels like the wrong way to tackle this.
>
> I'm still not sure what you are trying to achieve. Is the idea only to provide
> a useful default for DMA_CMA depending on which drivers are enabled?
"Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n)."
Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to
set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with
e.g., DRMA_ASPEED_GFX=y because it will always override my (user!)
setting -- even though it doesn't really always need it. Using "select"
is the problem here.
>
> This is something you could do using a hidden helper symbol like
>
> config DRMA_ASPEED_GFX
> bool "Aspeed display driver"
> select DRM_WANT_CMA
>
> config DRM_WANT_CMA
> bool
> help
> Select this from any driver that benefits from CMA being enabled
>
> config DMA_CMA
> bool "Use CMA helpers for DRM"
> default DRM_WANT_CMA
>
> Arnd
>
That's precisely what I had first, with an additional "WANT_CMA" -- but
looking at the number of such existing options (I was able to spot 1 !)
I wondered if there is a better approach to achieve the same; "imply"
sounded like a good candidate.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 12:00 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 12:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Randy Dunlap, The etnaviv authors, Linux Kernel Mailing List,
dri-devel, Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Masahiro Yamada, Mike Rapoport
On 08.04.21 13:44, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> It is a somewhat awkward way to say "prevent this symbol from
>>> being =y if the dependency is =m".
>>
>> What would be the right thing to do in the case here then to achieve the
>> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>>
>> One approach could be to have for DMA_CMA
>>
>> default y if DRMA_ASPEED_GFX
>>
>> but it feels like the wrong way to tackle this.
>
> I'm still not sure what you are trying to achieve. Is the idea only to provide
> a useful default for DMA_CMA depending on which drivers are enabled?
"Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n)."
Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to
set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with
e.g., DRMA_ASPEED_GFX=y because it will always override my (user!)
setting -- even though it doesn't really always need it. Using "select"
is the problem here.
>
> This is something you could do using a hidden helper symbol like
>
> config DRMA_ASPEED_GFX
> bool "Aspeed display driver"
> select DRM_WANT_CMA
>
> config DRM_WANT_CMA
> bool
> help
> Select this from any driver that benefits from CMA being enabled
>
> config DMA_CMA
> bool "Use CMA helpers for DRM"
> default DRM_WANT_CMA
>
> Arnd
>
That's precisely what I had first, with an additional "WANT_CMA" -- but
looking at the number of such existing options (I was able to spot 1 !)
I wondered if there is a better approach to achieve the same; "imply"
sounded like a good candidate.
--
Thanks,
David / dhildenb
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 12:00 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 12:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On 08.04.21 13:44, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> It is a somewhat awkward way to say "prevent this symbol from
>>> being =y if the dependency is =m".
>>
>> What would be the right thing to do in the case here then to achieve the
>> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>>
>> One approach could be to have for DMA_CMA
>>
>> default y if DRMA_ASPEED_GFX
>>
>> but it feels like the wrong way to tackle this.
>
> I'm still not sure what you are trying to achieve. Is the idea only to provide
> a useful default for DMA_CMA depending on which drivers are enabled?
"Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n)."
Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to
set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with
e.g., DRMA_ASPEED_GFX=y because it will always override my (user!)
setting -- even though it doesn't really always need it. Using "select"
is the problem here.
>
> This is something you could do using a hidden helper symbol like
>
> config DRMA_ASPEED_GFX
> bool "Aspeed display driver"
> select DRM_WANT_CMA
>
> config DRM_WANT_CMA
> bool
> help
> Select this from any driver that benefits from CMA being enabled
>
> config DMA_CMA
> bool "Use CMA helpers for DRM"
> default DRM_WANT_CMA
>
> Arnd
>
That's precisely what I had first, with an additional "WANT_CMA" -- but
looking at the number of such existing options (I was able to spot 1 !)
I wondered if there is a better approach to achieve the same; "imply"
sounded like a good candidate.
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 12:00 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 12:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On 08.04.21 13:44, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
>>>
>>> It is a somewhat awkward way to say "prevent this symbol from
>>> being =y if the dependency is =m".
>>
>> What would be the right thing to do in the case here then to achieve the
>> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
>>
>> One approach could be to have for DMA_CMA
>>
>> default y if DRMA_ASPEED_GFX
>>
>> but it feels like the wrong way to tackle this.
>
> I'm still not sure what you are trying to achieve. Is the idea only to provide
> a useful default for DMA_CMA depending on which drivers are enabled?
"Random drivers should not override a user configuration of core knobs
(e.g., CONFIG_DMA_CMA=n)."
Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to
set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with
e.g., DRMA_ASPEED_GFX=y because it will always override my (user!)
setting -- even though it doesn't really always need it. Using "select"
is the problem here.
>
> This is something you could do using a hidden helper symbol like
>
> config DRMA_ASPEED_GFX
> bool "Aspeed display driver"
> select DRM_WANT_CMA
>
> config DRM_WANT_CMA
> bool
> help
> Select this from any driver that benefits from CMA being enabled
>
> config DMA_CMA
> bool "Use CMA helpers for DRM"
> default DRM_WANT_CMA
>
> Arnd
>
That's precisely what I had first, with an additional "WANT_CMA" -- but
looking at the number of such existing options (I was able to spot 1 !)
I wondered if there is a better approach to achieve the same; "imply"
sounded like a good candidate.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 12:00 ` David Hildenbrand
(?)
(?)
@ 2021-04-08 12:12 ` Arnd Bergmann
-1 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 12:12 UTC (permalink / raw)
To: linux-aspeed
On Thu, Apr 8, 2021 at 2:00 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 08.04.21 13:44, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
> >>>
> >>> It is a somewhat awkward way to say "prevent this symbol from
> >>> being =y if the dependency is =m".
> >>
> >> What would be the right thing to do in the case here then to achieve the
> >> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
> >>
> >> One approach could be to have for DMA_CMA
> >>
> >> default y if DRMA_ASPEED_GFX
> >>
> >> but it feels like the wrong way to tackle this.
> >
> > I'm still not sure what you are trying to achieve. Is the idea only to provide
> > a useful default for DMA_CMA depending on which drivers are enabled?
>
> "Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n)."
>
> Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to
> set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with
> e.g., DRMA_ASPEED_GFX=y because it will always override my (user!)
> setting -- even though it doesn't really always need it. Using "select"
> is the problem here.
I agree on the part of removing the 'select' if we don't need it. The
part I couldn't figure out was what the 'imply' is supposed to help with.
Most other users that added imply tried (and failed) to fix a build problem.
> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> > bool "Aspeed display driver"
> > select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> > bool
> > help
> > Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> > bool "Use CMA helpers for DRM"
> > default DRM_WANT_CMA
> >
> > Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" -- but
> looking at the number of such existing options (I was able to spot 1 !)
> I wondered if there is a better approach to achieve the same; "imply"
> sounded like a good candidate.
I can probably find a couple more, but regardless of how many others
exist, this would be a much clearer way of doing it than 'imply' since it
has none of the ambiguity and misuse problems.
I think the reason we don't see more is that generally speaking, those
defaults are widely ignored anyway. You almost always start out with
a defconfig file that contains everything you know you need, and then
you add bits to that. Having the default in any form only helps to
make that defconfig file one line shorter, while requiring other users
to add another line to turn it off when they do not want it.
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 12:12 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 12:12 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Randy Dunlap, The etnaviv authors, Linux Kernel Mailing List,
dri-devel, Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Masahiro Yamada, Mike Rapoport
On Thu, Apr 8, 2021 at 2:00 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 08.04.21 13:44, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
> >>>
> >>> It is a somewhat awkward way to say "prevent this symbol from
> >>> being =y if the dependency is =m".
> >>
> >> What would be the right thing to do in the case here then to achieve the
> >> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
> >>
> >> One approach could be to have for DMA_CMA
> >>
> >> default y if DRMA_ASPEED_GFX
> >>
> >> but it feels like the wrong way to tackle this.
> >
> > I'm still not sure what you are trying to achieve. Is the idea only to provide
> > a useful default for DMA_CMA depending on which drivers are enabled?
>
> "Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n)."
>
> Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to
> set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with
> e.g., DRMA_ASPEED_GFX=y because it will always override my (user!)
> setting -- even though it doesn't really always need it. Using "select"
> is the problem here.
I agree on the part of removing the 'select' if we don't need it. The
part I couldn't figure out was what the 'imply' is supposed to help with.
Most other users that added imply tried (and failed) to fix a build problem.
> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> > bool "Aspeed display driver"
> > select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> > bool
> > help
> > Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> > bool "Use CMA helpers for DRM"
> > default DRM_WANT_CMA
> >
> > Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" -- but
> looking at the number of such existing options (I was able to spot 1 !)
> I wondered if there is a better approach to achieve the same; "imply"
> sounded like a good candidate.
I can probably find a couple more, but regardless of how many others
exist, this would be a much clearer way of doing it than 'imply' since it
has none of the ambiguity and misuse problems.
I think the reason we don't see more is that generally speaking, those
defaults are widely ignored anyway. You almost always start out with
a defconfig file that contains everything you know you need, and then
you add bits to that. Having the default in any form only helps to
make that defconfig file one line shorter, while requiring other users
to add another line to turn it off when they do not want it.
Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 12:12 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 12:12 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 2:00 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 08.04.21 13:44, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
> >>>
> >>> It is a somewhat awkward way to say "prevent this symbol from
> >>> being =y if the dependency is =m".
> >>
> >> What would be the right thing to do in the case here then to achieve the
> >> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
> >>
> >> One approach could be to have for DMA_CMA
> >>
> >> default y if DRMA_ASPEED_GFX
> >>
> >> but it feels like the wrong way to tackle this.
> >
> > I'm still not sure what you are trying to achieve. Is the idea only to provide
> > a useful default for DMA_CMA depending on which drivers are enabled?
>
> "Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n)."
>
> Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to
> set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with
> e.g., DRMA_ASPEED_GFX=y because it will always override my (user!)
> setting -- even though it doesn't really always need it. Using "select"
> is the problem here.
I agree on the part of removing the 'select' if we don't need it. The
part I couldn't figure out was what the 'imply' is supposed to help with.
Most other users that added imply tried (and failed) to fix a build problem.
> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> > bool "Aspeed display driver"
> > select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> > bool
> > help
> > Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> > bool "Use CMA helpers for DRM"
> > default DRM_WANT_CMA
> >
> > Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" -- but
> looking at the number of such existing options (I was able to spot 1 !)
> I wondered if there is a better approach to achieve the same; "imply"
> sounded like a good candidate.
I can probably find a couple more, but regardless of how many others
exist, this would be a much clearer way of doing it than 'imply' since it
has none of the ambiguity and misuse problems.
I think the reason we don't see more is that generally speaking, those
defaults are widely ignored anyway. You almost always start out with
a defconfig file that contains everything you know you need, and then
you add bits to that. Having the default in any form only helps to
make that defconfig file one line shorter, while requiring other users
to add another line to turn it off when they do not want it.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 12:12 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 12:12 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Linus Walleij, Michal Simek, Masahiro Yamada, Randy Dunlap,
Peter Collingbourne, linux-aspeed, dri-devel, Linux ARM,
The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 2:00 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 08.04.21 13:44, Arnd Bergmann wrote:
> > On Thu, Apr 8, 2021 at 1:00 PM David Hildenbrand <david@redhat.com> wrote:
> >>>
> >>> It is a somewhat awkward way to say "prevent this symbol from
> >>> being =y if the dependency is =m".
> >>
> >> What would be the right thing to do in the case here then to achieve the
> >> "if DRMA_ASPEED_GFX is enabled, also enable DMA_CMA id possible"?
> >>
> >> One approach could be to have for DMA_CMA
> >>
> >> default y if DRMA_ASPEED_GFX
> >>
> >> but it feels like the wrong way to tackle this.
> >
> > I'm still not sure what you are trying to achieve. Is the idea only to provide
> > a useful default for DMA_CMA depending on which drivers are enabled?
>
> "Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n)."
>
> Let's assume I'm a distribution and want to set CONFIG_CMA=n or want to
> set CONFIG_DMA_CMA=n with CONFIG_CMA=y; there is no way to do that with
> e.g., DRMA_ASPEED_GFX=y because it will always override my (user!)
> setting -- even though it doesn't really always need it. Using "select"
> is the problem here.
I agree on the part of removing the 'select' if we don't need it. The
part I couldn't figure out was what the 'imply' is supposed to help with.
Most other users that added imply tried (and failed) to fix a build problem.
> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> > bool "Aspeed display driver"
> > select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> > bool
> > help
> > Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> > bool "Use CMA helpers for DRM"
> > default DRM_WANT_CMA
> >
> > Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" -- but
> looking at the number of such existing options (I was able to spot 1 !)
> I wondered if there is a better approach to achieve the same; "imply"
> sounded like a good candidate.
I can probably find a couple more, but regardless of how many others
exist, this would be a much clearer way of doing it than 'imply' since it
has none of the ambiguity and misuse problems.
I think the reason we don't see more is that generally speaking, those
defaults are widely ignored anyway. You almost always start out with
a defconfig file that contains everything you know you need, and then
you add bits to that. Having the default in any form only helps to
make that defconfig file one line shorter, while requiring other users
to add another line to turn it off when they do not want it.
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 12:00 ` David Hildenbrand
(?)
(?)
@ 2021-04-08 12:49 ` Linus Walleij
-1 siblings, 0 replies; 92+ messages in thread
From: Linus Walleij @ 2021-04-08 12:49 UTC (permalink / raw)
To: linux-aspeed
On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> > bool "Aspeed display driver"
> > select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> > bool
> > help
> > Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> > bool "Use CMA helpers for DRM"
> > default DRM_WANT_CMA
> >
> > Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" -- but
> looking at the number of such existing options (I was able to spot 1 !)
If you do this it probably makes sense to fix a few other drivers
Kconfig in the process. It's not just a problem with your driver.
"my" drivers:
drivers/gpu/drm/mcde/Kconfig
drivers/gpu/drm/pl111/Kconfig
drivers/gpu/drm/tve200/Kconfig
certainly needs this as well, and pretty much anything that is
selecting DRM_KMS_CMA_HELPER or
DRM_GEM_CMA_HELPER "wants" DMA_CMA.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 12:49 ` Linus Walleij
0 siblings, 0 replies; 92+ messages in thread
From: Linus Walleij @ 2021-04-08 12:49 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Arnd Bergmann, Bartlomiej Zolnierkiewicz, David Airlie,
Andrew Jeffery, Masahiro Yamada, Randy Dunlap,
The etnaviv authors, Linux Kernel Mailing List, dri-devel,
Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Mike Rapoport
On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> > bool "Aspeed display driver"
> > select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> > bool
> > help
> > Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> > bool "Use CMA helpers for DRM"
> > default DRM_WANT_CMA
> >
> > Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" -- but
> looking at the number of such existing options (I was able to spot 1 !)
If you do this it probably makes sense to fix a few other drivers
Kconfig in the process. It's not just a problem with your driver.
"my" drivers:
drivers/gpu/drm/mcde/Kconfig
drivers/gpu/drm/pl111/Kconfig
drivers/gpu/drm/tve200/Kconfig
certainly needs this as well, and pretty much anything that is
selecting DRM_KMS_CMA_HELPER or
DRM_GEM_CMA_HELPER "wants" DMA_CMA.
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 12:49 ` Linus Walleij
0 siblings, 0 replies; 92+ messages in thread
From: Linus Walleij @ 2021-04-08 12:49 UTC (permalink / raw)
To: David Hildenbrand
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> > bool "Aspeed display driver"
> > select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> > bool
> > help
> > Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> > bool "Use CMA helpers for DRM"
> > default DRM_WANT_CMA
> >
> > Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" -- but
> looking at the number of such existing options (I was able to spot 1 !)
If you do this it probably makes sense to fix a few other drivers
Kconfig in the process. It's not just a problem with your driver.
"my" drivers:
drivers/gpu/drm/mcde/Kconfig
drivers/gpu/drm/pl111/Kconfig
drivers/gpu/drm/tve200/Kconfig
certainly needs this as well, and pretty much anything that is
selecting DRM_KMS_CMA_HELPER or
DRM_GEM_CMA_HELPER "wants" DMA_CMA.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 12:49 ` Linus Walleij
0 siblings, 0 replies; 92+ messages in thread
From: Linus Walleij @ 2021-04-08 12:49 UTC (permalink / raw)
To: David Hildenbrand
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
> > This is something you could do using a hidden helper symbol like
> >
> > config DRMA_ASPEED_GFX
> > bool "Aspeed display driver"
> > select DRM_WANT_CMA
> >
> > config DRM_WANT_CMA
> > bool
> > help
> > Select this from any driver that benefits from CMA being enabled
> >
> > config DMA_CMA
> > bool "Use CMA helpers for DRM"
> > default DRM_WANT_CMA
> >
> > Arnd
> >
>
> That's precisely what I had first, with an additional "WANT_CMA" -- but
> looking at the number of such existing options (I was able to spot 1 !)
If you do this it probably makes sense to fix a few other drivers
Kconfig in the process. It's not just a problem with your driver.
"my" drivers:
drivers/gpu/drm/mcde/Kconfig
drivers/gpu/drm/pl111/Kconfig
drivers/gpu/drm/tve200/Kconfig
certainly needs this as well, and pretty much anything that is
selecting DRM_KMS_CMA_HELPER or
DRM_GEM_CMA_HELPER "wants" DMA_CMA.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 12:49 ` Linus Walleij
(?)
(?)
@ 2021-04-08 13:19 ` Arnd Bergmann
-1 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 13:19 UTC (permalink / raw)
To: linux-aspeed
On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>
> > > This is something you could do using a hidden helper symbol like
> > >
> > > config DRMA_ASPEED_GFX
> > > bool "Aspeed display driver"
> > > select DRM_WANT_CMA
> > >
> > > config DRM_WANT_CMA
> > > bool
> > > help
> > > Select this from any driver that benefits from CMA being enabled
> > >
> > > config DMA_CMA
> > > bool "Use CMA helpers for DRM"
> > > default DRM_WANT_CMA
> > >
> > > Arnd
> > >
> >
> > That's precisely what I had first, with an additional "WANT_CMA" -- but
> > looking at the number of such existing options (I was able to spot 1 !)
>
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
>
> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig
>
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
Are there any that don't select either of the helpers and
still want CMA? If not, it would be easy to just add
default DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER
and skipt the extra symbol.
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 13:19 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 13:19 UTC (permalink / raw)
To: Linus Walleij
Cc: Linux ARM, Linux Fbdev development list, Randy Dunlap,
linux-aspeed, David Hildenbrand, David Airlie, Andrew Jeffery,
Masahiro Yamada, Bartlomiej Zolnierkiewicz, The etnaviv authors,
Linux Kernel Mailing List, dri-devel, Michal Simek, Linux-MM,
Joel Stanley, Russell King, Peter Collingbourne, Mike Rapoport
On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>
> > > This is something you could do using a hidden helper symbol like
> > >
> > > config DRMA_ASPEED_GFX
> > > bool "Aspeed display driver"
> > > select DRM_WANT_CMA
> > >
> > > config DRM_WANT_CMA
> > > bool
> > > help
> > > Select this from any driver that benefits from CMA being enabled
> > >
> > > config DMA_CMA
> > > bool "Use CMA helpers for DRM"
> > > default DRM_WANT_CMA
> > >
> > > Arnd
> > >
> >
> > That's precisely what I had first, with an additional "WANT_CMA" -- but
> > looking at the number of such existing options (I was able to spot 1 !)
>
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
>
> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig
>
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
Are there any that don't select either of the helpers and
still want CMA? If not, it would be easy to just add
default DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER
and skipt the extra symbol.
Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 13:19 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 13:19 UTC (permalink / raw)
To: Linus Walleij
Cc: David Hildenbrand, Linux Kernel Mailing List, Linux-MM,
Joel Stanley, David Airlie, Daniel Vetter, Andrew Jeffery,
Lucas Stach, Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>
> > > This is something you could do using a hidden helper symbol like
> > >
> > > config DRMA_ASPEED_GFX
> > > bool "Aspeed display driver"
> > > select DRM_WANT_CMA
> > >
> > > config DRM_WANT_CMA
> > > bool
> > > help
> > > Select this from any driver that benefits from CMA being enabled
> > >
> > > config DMA_CMA
> > > bool "Use CMA helpers for DRM"
> > > default DRM_WANT_CMA
> > >
> > > Arnd
> > >
> >
> > That's precisely what I had first, with an additional "WANT_CMA" -- but
> > looking at the number of such existing options (I was able to spot 1 !)
>
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
>
> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig
>
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
Are there any that don't select either of the helpers and
still want CMA? If not, it would be easy to just add
default DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER
and skipt the extra symbol.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 13:19 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 13:19 UTC (permalink / raw)
To: Linus Walleij
Cc: David Hildenbrand, Linux Kernel Mailing List, Linux-MM,
Joel Stanley, David Airlie, Daniel Vetter, Andrew Jeffery,
Lucas Stach, Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>
> > > This is something you could do using a hidden helper symbol like
> > >
> > > config DRMA_ASPEED_GFX
> > > bool "Aspeed display driver"
> > > select DRM_WANT_CMA
> > >
> > > config DRM_WANT_CMA
> > > bool
> > > help
> > > Select this from any driver that benefits from CMA being enabled
> > >
> > > config DMA_CMA
> > > bool "Use CMA helpers for DRM"
> > > default DRM_WANT_CMA
> > >
> > > Arnd
> > >
> >
> > That's precisely what I had first, with an additional "WANT_CMA" -- but
> > looking at the number of such existing options (I was able to spot 1 !)
>
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
>
> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig
>
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
Are there any that don't select either of the helpers and
still want CMA? If not, it would be easy to just add
default DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER
and skipt the extra symbol.
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 13:19 ` Arnd Bergmann
(?)
(?)
@ 2021-04-09 8:07 ` David Hildenbrand
-1 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-09 8:07 UTC (permalink / raw)
To: linux-aspeed
On 08.04.21 15:19, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>>
>>>> This is something you could do using a hidden helper symbol like
>>>>
>>>> config DRMA_ASPEED_GFX
>>>> bool "Aspeed display driver"
>>>> select DRM_WANT_CMA
>>>>
>>>> config DRM_WANT_CMA
>>>> bool
>>>> help
>>>> Select this from any driver that benefits from CMA being enabled
>>>>
>>>> config DMA_CMA
>>>> bool "Use CMA helpers for DRM"
>>>> default DRM_WANT_CMA
>>>>
>>>> Arnd
>>>>
>>>
>>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>>> looking at the number of such existing options (I was able to spot 1 !)
>>
>> If you do this it probably makes sense to fix a few other drivers
>> Kconfig in the process. It's not just a problem with your driver.
>> "my" drivers:
>>
>> drivers/gpu/drm/mcde/Kconfig
>> drivers/gpu/drm/pl111/Kconfig
>> drivers/gpu/drm/tve200/Kconfig
>>
>> certainly needs this as well, and pretty much anything that is
>> selecting DRM_KMS_CMA_HELPER or
>> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
>
> Are there any that don't select either of the helpers and
> still want CMA? If not, it would be easy to just add
>
> default DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER
>
> and skipt the extra symbol.
That sounds like a reasonable thing to do. I'll look into that.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-09 8:07 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-09 8:07 UTC (permalink / raw)
To: Arnd Bergmann, Linus Walleij
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Masahiro Yamada, Randy Dunlap, The etnaviv authors,
Linux Kernel Mailing List, dri-devel, Michal Simek, Linux-MM,
Joel Stanley, Russell King, Peter Collingbourne, Mike Rapoport
On 08.04.21 15:19, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>>
>>>> This is something you could do using a hidden helper symbol like
>>>>
>>>> config DRMA_ASPEED_GFX
>>>> bool "Aspeed display driver"
>>>> select DRM_WANT_CMA
>>>>
>>>> config DRM_WANT_CMA
>>>> bool
>>>> help
>>>> Select this from any driver that benefits from CMA being enabled
>>>>
>>>> config DMA_CMA
>>>> bool "Use CMA helpers for DRM"
>>>> default DRM_WANT_CMA
>>>>
>>>> Arnd
>>>>
>>>
>>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>>> looking at the number of such existing options (I was able to spot 1 !)
>>
>> If you do this it probably makes sense to fix a few other drivers
>> Kconfig in the process. It's not just a problem with your driver.
>> "my" drivers:
>>
>> drivers/gpu/drm/mcde/Kconfig
>> drivers/gpu/drm/pl111/Kconfig
>> drivers/gpu/drm/tve200/Kconfig
>>
>> certainly needs this as well, and pretty much anything that is
>> selecting DRM_KMS_CMA_HELPER or
>> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
>
> Are there any that don't select either of the helpers and
> still want CMA? If not, it would be easy to just add
>
> default DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER
>
> and skipt the extra symbol.
That sounds like a reasonable thing to do. I'll look into that.
--
Thanks,
David / dhildenb
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-09 8:07 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-09 8:07 UTC (permalink / raw)
To: Arnd Bergmann, Linus Walleij
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Michal Simek, Masahiro Yamada, Randy Dunlap, Peter Collingbourne,
linux-aspeed, dri-devel, Linux ARM, The etnaviv authors,
Linux Fbdev development list
On 08.04.21 15:19, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>>
>>>> This is something you could do using a hidden helper symbol like
>>>>
>>>> config DRMA_ASPEED_GFX
>>>> bool "Aspeed display driver"
>>>> select DRM_WANT_CMA
>>>>
>>>> config DRM_WANT_CMA
>>>> bool
>>>> help
>>>> Select this from any driver that benefits from CMA being enabled
>>>>
>>>> config DMA_CMA
>>>> bool "Use CMA helpers for DRM"
>>>> default DRM_WANT_CMA
>>>>
>>>> Arnd
>>>>
>>>
>>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>>> looking at the number of such existing options (I was able to spot 1 !)
>>
>> If you do this it probably makes sense to fix a few other drivers
>> Kconfig in the process. It's not just a problem with your driver.
>> "my" drivers:
>>
>> drivers/gpu/drm/mcde/Kconfig
>> drivers/gpu/drm/pl111/Kconfig
>> drivers/gpu/drm/tve200/Kconfig
>>
>> certainly needs this as well, and pretty much anything that is
>> selecting DRM_KMS_CMA_HELPER or
>> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
>
> Are there any that don't select either of the helpers and
> still want CMA? If not, it would be easy to just add
>
> default DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER
>
> and skipt the extra symbol.
That sounds like a reasonable thing to do. I'll look into that.
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-09 8:07 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-09 8:07 UTC (permalink / raw)
To: Arnd Bergmann, Linus Walleij
Cc: Linux Kernel Mailing List, Linux-MM, Joel Stanley, David Airlie,
Daniel Vetter, Andrew Jeffery, Lucas Stach, Russell King,
Christian Gmeiner, Mike Rapoport, Bartlomiej Zolnierkiewicz,
Michal Simek, Masahiro Yamada, Randy Dunlap, Peter Collingbourne,
linux-aspeed, dri-devel, Linux ARM, The etnaviv authors,
Linux Fbdev development list
On 08.04.21 15:19, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 2:50 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>>
>>>> This is something you could do using a hidden helper symbol like
>>>>
>>>> config DRMA_ASPEED_GFX
>>>> bool "Aspeed display driver"
>>>> select DRM_WANT_CMA
>>>>
>>>> config DRM_WANT_CMA
>>>> bool
>>>> help
>>>> Select this from any driver that benefits from CMA being enabled
>>>>
>>>> config DMA_CMA
>>>> bool "Use CMA helpers for DRM"
>>>> default DRM_WANT_CMA
>>>>
>>>> Arnd
>>>>
>>>
>>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>>> looking at the number of such existing options (I was able to spot 1 !)
>>
>> If you do this it probably makes sense to fix a few other drivers
>> Kconfig in the process. It's not just a problem with your driver.
>> "my" drivers:
>>
>> drivers/gpu/drm/mcde/Kconfig
>> drivers/gpu/drm/pl111/Kconfig
>> drivers/gpu/drm/tve200/Kconfig
>>
>> certainly needs this as well, and pretty much anything that is
>> selecting DRM_KMS_CMA_HELPER or
>> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
>
> Are there any that don't select either of the helpers and
> still want CMA? If not, it would be easy to just add
>
> default DRM_KMS_CMA_HELPER || DRM_GEM_CMA_HELPER
>
> and skipt the extra symbol.
That sounds like a reasonable thing to do. I'll look into that.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 12:49 ` Linus Walleij
(?)
(?)
@ 2021-04-08 16:44 ` David Hildenbrand
-1 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 16:44 UTC (permalink / raw)
To: linux-aspeed
On 08.04.21 14:49, Linus Walleij wrote:
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>
>>> This is something you could do using a hidden helper symbol like
>>>
>>> config DRMA_ASPEED_GFX
>>> bool "Aspeed display driver"
>>> select DRM_WANT_CMA
>>>
>>> config DRM_WANT_CMA
>>> bool
>>> help
>>> Select this from any driver that benefits from CMA being enabled
>>>
>>> config DMA_CMA
>>> bool "Use CMA helpers for DRM"
>>> default DRM_WANT_CMA
>>>
>>> Arnd
>>>
>>
>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>> looking at the number of such existing options (I was able to spot 1 !)
>
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
>
:) I actually wanted to convert them to "depends on DMA_CMA" but ran
into recursive dependencies ...
> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig
I was assuming these are "real" dependencies. Will it also work without
DMA_CMA?
>
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
"wants" as in "desires to use but can life without" or "wants" as in
"really needs it". ?
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 16:44 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 16:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Arnd Bergmann, Bartlomiej Zolnierkiewicz, David Airlie,
Andrew Jeffery, Masahiro Yamada, Randy Dunlap,
The etnaviv authors, Linux Kernel Mailing List, dri-devel,
Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Mike Rapoport
On 08.04.21 14:49, Linus Walleij wrote:
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>
>>> This is something you could do using a hidden helper symbol like
>>>
>>> config DRMA_ASPEED_GFX
>>> bool "Aspeed display driver"
>>> select DRM_WANT_CMA
>>>
>>> config DRM_WANT_CMA
>>> bool
>>> help
>>> Select this from any driver that benefits from CMA being enabled
>>>
>>> config DMA_CMA
>>> bool "Use CMA helpers for DRM"
>>> default DRM_WANT_CMA
>>>
>>> Arnd
>>>
>>
>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>> looking at the number of such existing options (I was able to spot 1 !)
>
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
>
:) I actually wanted to convert them to "depends on DMA_CMA" but ran
into recursive dependencies ...
> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig
I was assuming these are "real" dependencies. Will it also work without
DMA_CMA?
>
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
"wants" as in "desires to use but can life without" or "wants" as in
"really needs it". ?
--
Thanks,
David / dhildenb
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 16:44 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 16:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On 08.04.21 14:49, Linus Walleij wrote:
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>
>>> This is something you could do using a hidden helper symbol like
>>>
>>> config DRMA_ASPEED_GFX
>>> bool "Aspeed display driver"
>>> select DRM_WANT_CMA
>>>
>>> config DRM_WANT_CMA
>>> bool
>>> help
>>> Select this from any driver that benefits from CMA being enabled
>>>
>>> config DMA_CMA
>>> bool "Use CMA helpers for DRM"
>>> default DRM_WANT_CMA
>>>
>>> Arnd
>>>
>>
>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>> looking at the number of such existing options (I was able to spot 1 !)
>
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
>
:) I actually wanted to convert them to "depends on DMA_CMA" but ran
into recursive dependencies ...
> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig
I was assuming these are "real" dependencies. Will it also work without
DMA_CMA?
>
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
"wants" as in "desires to use but can life without" or "wants" as in
"really needs it". ?
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 16:44 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-08 16:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On 08.04.21 14:49, Linus Walleij wrote:
> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>
>>> This is something you could do using a hidden helper symbol like
>>>
>>> config DRMA_ASPEED_GFX
>>> bool "Aspeed display driver"
>>> select DRM_WANT_CMA
>>>
>>> config DRM_WANT_CMA
>>> bool
>>> help
>>> Select this from any driver that benefits from CMA being enabled
>>>
>>> config DMA_CMA
>>> bool "Use CMA helpers for DRM"
>>> default DRM_WANT_CMA
>>>
>>> Arnd
>>>
>>
>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>> looking at the number of such existing options (I was able to spot 1 !)
>
> If you do this it probably makes sense to fix a few other drivers
> Kconfig in the process. It's not just a problem with your driver.
> "my" drivers:
>
:) I actually wanted to convert them to "depends on DMA_CMA" but ran
into recursive dependencies ...
> drivers/gpu/drm/mcde/Kconfig
> drivers/gpu/drm/pl111/Kconfig
> drivers/gpu/drm/tve200/Kconfig
I was assuming these are "real" dependencies. Will it also work without
DMA_CMA?
>
> certainly needs this as well, and pretty much anything that is
> selecting DRM_KMS_CMA_HELPER or
> DRM_GEM_CMA_HELPER "wants" DMA_CMA.
"wants" as in "desires to use but can life without" or "wants" as in
"really needs it". ?
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 16:44 ` David Hildenbrand
(?)
(?)
@ 2021-04-08 20:29 ` Arnd Bergmann
-1 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 20:29 UTC (permalink / raw)
To: linux-aspeed
On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david@redhat.com> wrote:
> On 08.04.21 14:49, Linus Walleij wrote:
> > On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
> >
> >>> This is something you could do using a hidden helper symbol like
> >>>
> >>> config DRMA_ASPEED_GFX
> >>> bool "Aspeed display driver"
> >>> select DRM_WANT_CMA
> >>>
> >>> config DRM_WANT_CMA
> >>> bool
> >>> help
> >>> Select this from any driver that benefits from CMA being enabled
> >>>
> >>> config DMA_CMA
> >>> bool "Use CMA helpers for DRM"
> >>> default DRM_WANT_CMA
> >>>
> >>> Arnd
> >>>
> >>
> >> That's precisely what I had first, with an additional "WANT_CMA" -- but
> >> looking at the number of such existing options (I was able to spot 1 !)
> >
> > If you do this it probably makes sense to fix a few other drivers
> > Kconfig in the process. It's not just a problem with your driver.
> > "my" drivers:
> >
>
> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
> into recursive dependencies ...
>
> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig
Right, this is the main problem caused by using 'select' to
force-enable symbols that other drivers depend on.
Usually, the answer is to be consistent about the use of 'select'
and 'depends on', using the former only to enable symbols that
are hidden, while using 'depends on' for anything that is an
actual build time dependency.
> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?
I think in this case, it is fairly likely to work without DMA_CMA when the
probe function gets called during a fresh boot, but fairly likely to fail if
it gets called after the system has run for long enough to fragment the
free memory.
The point of DMA_CMA is to make it work reliably.
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 20:29 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 20:29 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Randy Dunlap, The etnaviv authors, Linux Kernel Mailing List,
dri-devel, Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Masahiro Yamada, Mike Rapoport
On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david@redhat.com> wrote:
> On 08.04.21 14:49, Linus Walleij wrote:
> > On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
> >
> >>> This is something you could do using a hidden helper symbol like
> >>>
> >>> config DRMA_ASPEED_GFX
> >>> bool "Aspeed display driver"
> >>> select DRM_WANT_CMA
> >>>
> >>> config DRM_WANT_CMA
> >>> bool
> >>> help
> >>> Select this from any driver that benefits from CMA being enabled
> >>>
> >>> config DMA_CMA
> >>> bool "Use CMA helpers for DRM"
> >>> default DRM_WANT_CMA
> >>>
> >>> Arnd
> >>>
> >>
> >> That's precisely what I had first, with an additional "WANT_CMA" -- but
> >> looking at the number of such existing options (I was able to spot 1 !)
> >
> > If you do this it probably makes sense to fix a few other drivers
> > Kconfig in the process. It's not just a problem with your driver.
> > "my" drivers:
> >
>
> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
> into recursive dependencies ...
>
> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig
Right, this is the main problem caused by using 'select' to
force-enable symbols that other drivers depend on.
Usually, the answer is to be consistent about the use of 'select'
and 'depends on', using the former only to enable symbols that
are hidden, while using 'depends on' for anything that is an
actual build time dependency.
> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?
I think in this case, it is fairly likely to work without DMA_CMA when the
probe function gets called during a fresh boot, but fairly likely to fail if
it gets called after the system has run for long enough to fragment the
free memory.
The point of DMA_CMA is to make it work reliably.
Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 20:29 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 20:29 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linus Walleij, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david@redhat.com> wrote:
> On 08.04.21 14:49, Linus Walleij wrote:
> > On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
> >
> >>> This is something you could do using a hidden helper symbol like
> >>>
> >>> config DRMA_ASPEED_GFX
> >>> bool "Aspeed display driver"
> >>> select DRM_WANT_CMA
> >>>
> >>> config DRM_WANT_CMA
> >>> bool
> >>> help
> >>> Select this from any driver that benefits from CMA being enabled
> >>>
> >>> config DMA_CMA
> >>> bool "Use CMA helpers for DRM"
> >>> default DRM_WANT_CMA
> >>>
> >>> Arnd
> >>>
> >>
> >> That's precisely what I had first, with an additional "WANT_CMA" -- but
> >> looking at the number of such existing options (I was able to spot 1 !)
> >
> > If you do this it probably makes sense to fix a few other drivers
> > Kconfig in the process. It's not just a problem with your driver.
> > "my" drivers:
> >
>
> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
> into recursive dependencies ...
>
> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig
Right, this is the main problem caused by using 'select' to
force-enable symbols that other drivers depend on.
Usually, the answer is to be consistent about the use of 'select'
and 'depends on', using the former only to enable symbols that
are hidden, while using 'depends on' for anything that is an
actual build time dependency.
> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?
I think in this case, it is fairly likely to work without DMA_CMA when the
probe function gets called during a fresh boot, but fairly likely to fail if
it gets called after the system has run for long enough to fragment the
free memory.
The point of DMA_CMA is to make it work reliably.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 20:29 ` Arnd Bergmann
0 siblings, 0 replies; 92+ messages in thread
From: Arnd Bergmann @ 2021-04-08 20:29 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linus Walleij, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david@redhat.com> wrote:
> On 08.04.21 14:49, Linus Walleij wrote:
> > On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
> >
> >>> This is something you could do using a hidden helper symbol like
> >>>
> >>> config DRMA_ASPEED_GFX
> >>> bool "Aspeed display driver"
> >>> select DRM_WANT_CMA
> >>>
> >>> config DRM_WANT_CMA
> >>> bool
> >>> help
> >>> Select this from any driver that benefits from CMA being enabled
> >>>
> >>> config DMA_CMA
> >>> bool "Use CMA helpers for DRM"
> >>> default DRM_WANT_CMA
> >>>
> >>> Arnd
> >>>
> >>
> >> That's precisely what I had first, with an additional "WANT_CMA" -- but
> >> looking at the number of such existing options (I was able to spot 1 !)
> >
> > If you do this it probably makes sense to fix a few other drivers
> > Kconfig in the process. It's not just a problem with your driver.
> > "my" drivers:
> >
>
> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
> into recursive dependencies ...
>
> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig
Right, this is the main problem caused by using 'select' to
force-enable symbols that other drivers depend on.
Usually, the answer is to be consistent about the use of 'select'
and 'depends on', using the former only to enable symbols that
are hidden, while using 'depends on' for anything that is an
actual build time dependency.
> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?
I think in this case, it is fairly likely to work without DMA_CMA when the
probe function gets called during a fresh boot, but fairly likely to fail if
it gets called after the system has run for long enough to fragment the
free memory.
The point of DMA_CMA is to make it work reliably.
Arnd
^ permalink raw reply [flat|nested] 92+ messages in thread* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 20:29 ` Arnd Bergmann
(?)
(?)
@ 2021-04-09 8:09 ` David Hildenbrand
-1 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-09 8:09 UTC (permalink / raw)
To: linux-aspeed
On 08.04.21 22:29, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david@redhat.com> wrote:
>> On 08.04.21 14:49, Linus Walleij wrote:
>>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>>>
>>>>> This is something you could do using a hidden helper symbol like
>>>>>
>>>>> config DRMA_ASPEED_GFX
>>>>> bool "Aspeed display driver"
>>>>> select DRM_WANT_CMA
>>>>>
>>>>> config DRM_WANT_CMA
>>>>> bool
>>>>> help
>>>>> Select this from any driver that benefits from CMA being enabled
>>>>>
>>>>> config DMA_CMA
>>>>> bool "Use CMA helpers for DRM"
>>>>> default DRM_WANT_CMA
>>>>>
>>>>> Arnd
>>>>>
>>>>
>>>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>>>> looking at the number of such existing options (I was able to spot 1 !)
>>>
>>> If you do this it probably makes sense to fix a few other drivers
>>> Kconfig in the process. It's not just a problem with your driver.
>>> "my" drivers:
>>>
>>
>> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
>> into recursive dependencies ...
>>
>>> drivers/gpu/drm/mcde/Kconfig
>>> drivers/gpu/drm/pl111/Kconfig
>>> drivers/gpu/drm/tve200/Kconfig
>
> Right, this is the main problem caused by using 'select' to
> force-enable symbols that other drivers depend on.
>
> Usually, the answer is to be consistent about the use of 'select'
> and 'depends on', using the former only to enable symbols that
> are hidden, while using 'depends on' for anything that is an
> actual build time dependency.
>
>> I was assuming these are "real" dependencies. Will it also work without
>> DMA_CMA?
>
> I think in this case, it is fairly likely to work without DMA_CMA when the
> probe function gets called during a fresh boot, but fairly likely to fail if
> it gets called after the system has run for long enough to fragment the
> free memory.
>
> The point of DMA_CMA is to make it work reliably.
Right, and even at runtime there is no guarantee that DMA_CMA will do
anything -- especially if we don't reserve a CMA region (e.g., "cma=X").
So this really sounds like a
"desires DMA_CMA"
and achieving that via an additional symbol or via "default y if ..."
for DMA_CMA sounds reasonable.
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-09 8:09 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-09 8:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Bartlomiej Zolnierkiewicz, David Airlie, Andrew Jeffery,
Randy Dunlap, The etnaviv authors, Linux Kernel Mailing List,
dri-devel, Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Masahiro Yamada, Mike Rapoport
On 08.04.21 22:29, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david@redhat.com> wrote:
>> On 08.04.21 14:49, Linus Walleij wrote:
>>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>>>
>>>>> This is something you could do using a hidden helper symbol like
>>>>>
>>>>> config DRMA_ASPEED_GFX
>>>>> bool "Aspeed display driver"
>>>>> select DRM_WANT_CMA
>>>>>
>>>>> config DRM_WANT_CMA
>>>>> bool
>>>>> help
>>>>> Select this from any driver that benefits from CMA being enabled
>>>>>
>>>>> config DMA_CMA
>>>>> bool "Use CMA helpers for DRM"
>>>>> default DRM_WANT_CMA
>>>>>
>>>>> Arnd
>>>>>
>>>>
>>>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>>>> looking at the number of such existing options (I was able to spot 1 !)
>>>
>>> If you do this it probably makes sense to fix a few other drivers
>>> Kconfig in the process. It's not just a problem with your driver.
>>> "my" drivers:
>>>
>>
>> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
>> into recursive dependencies ...
>>
>>> drivers/gpu/drm/mcde/Kconfig
>>> drivers/gpu/drm/pl111/Kconfig
>>> drivers/gpu/drm/tve200/Kconfig
>
> Right, this is the main problem caused by using 'select' to
> force-enable symbols that other drivers depend on.
>
> Usually, the answer is to be consistent about the use of 'select'
> and 'depends on', using the former only to enable symbols that
> are hidden, while using 'depends on' for anything that is an
> actual build time dependency.
>
>> I was assuming these are "real" dependencies. Will it also work without
>> DMA_CMA?
>
> I think in this case, it is fairly likely to work without DMA_CMA when the
> probe function gets called during a fresh boot, but fairly likely to fail if
> it gets called after the system has run for long enough to fragment the
> free memory.
>
> The point of DMA_CMA is to make it work reliably.
Right, and even at runtime there is no guarantee that DMA_CMA will do
anything -- especially if we don't reserve a CMA region (e.g., "cma=X").
So this really sounds like a
"desires DMA_CMA"
and achieving that via an additional symbol or via "default y if ..."
for DMA_CMA sounds reasonable.
Thanks!
--
Thanks,
David / dhildenb
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-09 8:09 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-09 8:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On 08.04.21 22:29, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david@redhat.com> wrote:
>> On 08.04.21 14:49, Linus Walleij wrote:
>>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>>>
>>>>> This is something you could do using a hidden helper symbol like
>>>>>
>>>>> config DRMA_ASPEED_GFX
>>>>> bool "Aspeed display driver"
>>>>> select DRM_WANT_CMA
>>>>>
>>>>> config DRM_WANT_CMA
>>>>> bool
>>>>> help
>>>>> Select this from any driver that benefits from CMA being enabled
>>>>>
>>>>> config DMA_CMA
>>>>> bool "Use CMA helpers for DRM"
>>>>> default DRM_WANT_CMA
>>>>>
>>>>> Arnd
>>>>>
>>>>
>>>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>>>> looking at the number of such existing options (I was able to spot 1 !)
>>>
>>> If you do this it probably makes sense to fix a few other drivers
>>> Kconfig in the process. It's not just a problem with your driver.
>>> "my" drivers:
>>>
>>
>> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
>> into recursive dependencies ...
>>
>>> drivers/gpu/drm/mcde/Kconfig
>>> drivers/gpu/drm/pl111/Kconfig
>>> drivers/gpu/drm/tve200/Kconfig
>
> Right, this is the main problem caused by using 'select' to
> force-enable symbols that other drivers depend on.
>
> Usually, the answer is to be consistent about the use of 'select'
> and 'depends on', using the former only to enable symbols that
> are hidden, while using 'depends on' for anything that is an
> actual build time dependency.
>
>> I was assuming these are "real" dependencies. Will it also work without
>> DMA_CMA?
>
> I think in this case, it is fairly likely to work without DMA_CMA when the
> probe function gets called during a fresh boot, but fairly likely to fail if
> it gets called after the system has run for long enough to fragment the
> free memory.
>
> The point of DMA_CMA is to make it work reliably.
Right, and even at runtime there is no guarantee that DMA_CMA will do
anything -- especially if we don't reserve a CMA region (e.g., "cma=X").
So this really sounds like a
"desires DMA_CMA"
and achieving that via an additional symbol or via "default y if ..."
for DMA_CMA sounds reasonable.
Thanks!
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-09 8:09 ` David Hildenbrand
0 siblings, 0 replies; 92+ messages in thread
From: David Hildenbrand @ 2021-04-09 8:09 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On 08.04.21 22:29, Arnd Bergmann wrote:
> On Thu, Apr 8, 2021 at 6:45 PM David Hildenbrand <david@redhat.com> wrote:
>> On 08.04.21 14:49, Linus Walleij wrote:
>>> On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand <david@redhat.com> wrote:
>>>
>>>>> This is something you could do using a hidden helper symbol like
>>>>>
>>>>> config DRMA_ASPEED_GFX
>>>>> bool "Aspeed display driver"
>>>>> select DRM_WANT_CMA
>>>>>
>>>>> config DRM_WANT_CMA
>>>>> bool
>>>>> help
>>>>> Select this from any driver that benefits from CMA being enabled
>>>>>
>>>>> config DMA_CMA
>>>>> bool "Use CMA helpers for DRM"
>>>>> default DRM_WANT_CMA
>>>>>
>>>>> Arnd
>>>>>
>>>>
>>>> That's precisely what I had first, with an additional "WANT_CMA" -- but
>>>> looking at the number of such existing options (I was able to spot 1 !)
>>>
>>> If you do this it probably makes sense to fix a few other drivers
>>> Kconfig in the process. It's not just a problem with your driver.
>>> "my" drivers:
>>>
>>
>> :) I actually wanted to convert them to "depends on DMA_CMA" but ran
>> into recursive dependencies ...
>>
>>> drivers/gpu/drm/mcde/Kconfig
>>> drivers/gpu/drm/pl111/Kconfig
>>> drivers/gpu/drm/tve200/Kconfig
>
> Right, this is the main problem caused by using 'select' to
> force-enable symbols that other drivers depend on.
>
> Usually, the answer is to be consistent about the use of 'select'
> and 'depends on', using the former only to enable symbols that
> are hidden, while using 'depends on' for anything that is an
> actual build time dependency.
>
>> I was assuming these are "real" dependencies. Will it also work without
>> DMA_CMA?
>
> I think in this case, it is fairly likely to work without DMA_CMA when the
> probe function gets called during a fresh boot, but fairly likely to fail if
> it gets called after the system has run for long enough to fragment the
> free memory.
>
> The point of DMA_CMA is to make it work reliably.
Right, and even at runtime there is no guarantee that DMA_CMA will do
anything -- especially if we don't reserve a CMA region (e.g., "cma=X").
So this really sounds like a
"desires DMA_CMA"
and achieving that via an additional symbol or via "default y if ..."
for DMA_CMA sounds reasonable.
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 92+ messages in thread
* [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
2021-04-08 16:44 ` David Hildenbrand
(?)
(?)
@ 2021-04-08 21:45 ` Linus Walleij
-1 siblings, 0 replies; 92+ messages in thread
From: Linus Walleij @ 2021-04-08 21:45 UTC (permalink / raw)
To: linux-aspeed
On Thu, Apr 8, 2021 at 6:44 PM David Hildenbrand <david@redhat.com> wrote:
> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig
>
> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?
It will mostly work but that is only because the reservations are
mostly contiguous anyway because they are done early and
are small. The hardware requires contiguous buffers in all
three cases. I'm not sure I always got it right.
> > certainly needs this as well, and pretty much anything that is
> > selecting DRM_KMS_CMA_HELPER or
> > DRM_GEM_CMA_HELPER "wants" DMA_CMA.
>
> "wants" as in "desires to use but can life without" or "wants" as in
> "really needs it". ?
I don't know the exact semantics of using DRM_KMS_CMA*
without actually using DMA_CMA. I suspect small allocations
will be contiguous and big allocations will start to fragment?
but it's just my guess. I guess "really need it"?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 21:45 ` Linus Walleij
0 siblings, 0 replies; 92+ messages in thread
From: Linus Walleij @ 2021-04-08 21:45 UTC (permalink / raw)
To: David Hildenbrand
Cc: Linux ARM, Linux Fbdev development list, linux-aspeed,
Arnd Bergmann, Bartlomiej Zolnierkiewicz, David Airlie,
Andrew Jeffery, Masahiro Yamada, Randy Dunlap,
The etnaviv authors, Linux Kernel Mailing List, dri-devel,
Michal Simek, Linux-MM, Joel Stanley, Russell King,
Peter Collingbourne, Mike Rapoport
On Thu, Apr 8, 2021 at 6:44 PM David Hildenbrand <david@redhat.com> wrote:
> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig
>
> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?
It will mostly work but that is only because the reservations are
mostly contiguous anyway because they are done early and
are small. The hardware requires contiguous buffers in all
three cases. I'm not sure I always got it right.
> > certainly needs this as well, and pretty much anything that is
> > selecting DRM_KMS_CMA_HELPER or
> > DRM_GEM_CMA_HELPER "wants" DMA_CMA.
>
> "wants" as in "desires to use but can life without" or "wants" as in
> "really needs it". ?
I don't know the exact semantics of using DRM_KMS_CMA*
without actually using DMA_CMA. I suspect small allocations
will be contiguous and big allocations will start to fragment?
but it's just my guess. I guess "really need it"?
Yours,
Linus Walleij
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 21:45 ` Linus Walleij
0 siblings, 0 replies; 92+ messages in thread
From: Linus Walleij @ 2021-04-08 21:45 UTC (permalink / raw)
To: David Hildenbrand
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 6:44 PM David Hildenbrand <david@redhat.com> wrote:
> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig
>
> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?
It will mostly work but that is only because the reservations are
mostly contiguous anyway because they are done early and
are small. The hardware requires contiguous buffers in all
three cases. I'm not sure I always got it right.
> > certainly needs this as well, and pretty much anything that is
> > selecting DRM_KMS_CMA_HELPER or
> > DRM_GEM_CMA_HELPER "wants" DMA_CMA.
>
> "wants" as in "desires to use but can life without" or "wants" as in
> "really needs it". ?
I don't know the exact semantics of using DRM_KMS_CMA*
without actually using DMA_CMA. I suspect small allocations
will be contiguous and big allocations will start to fragment?
but it's just my guess. I guess "really need it"?
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 92+ messages in thread
* Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
@ 2021-04-08 21:45 ` Linus Walleij
0 siblings, 0 replies; 92+ messages in thread
From: Linus Walleij @ 2021-04-08 21:45 UTC (permalink / raw)
To: David Hildenbrand
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux-MM, Joel Stanley,
David Airlie, Daniel Vetter, Andrew Jeffery, Lucas Stach,
Russell King, Christian Gmeiner, Mike Rapoport,
Bartlomiej Zolnierkiewicz, Michal Simek, Masahiro Yamada,
Randy Dunlap, Peter Collingbourne, linux-aspeed, dri-devel,
Linux ARM, The etnaviv authors, Linux Fbdev development list
On Thu, Apr 8, 2021 at 6:44 PM David Hildenbrand <david@redhat.com> wrote:
> > drivers/gpu/drm/mcde/Kconfig
> > drivers/gpu/drm/pl111/Kconfig
> > drivers/gpu/drm/tve200/Kconfig
>
> I was assuming these are "real" dependencies. Will it also work without
> DMA_CMA?
It will mostly work but that is only because the reservations are
mostly contiguous anyway because they are done early and
are small. The hardware requires contiguous buffers in all
three cases. I'm not sure I always got it right.
> > certainly needs this as well, and pretty much anything that is
> > selecting DRM_KMS_CMA_HELPER or
> > DRM_GEM_CMA_HELPER "wants" DMA_CMA.
>
> "wants" as in "desires to use but can life without" or "wants" as in
> "really needs it". ?
I don't know the exact semantics of using DRM_KMS_CMA*
without actually using DMA_CMA. I suspect small allocations
will be contiguous and big allocations will start to fragment?
but it's just my guess. I guess "really need it"?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 92+ messages in thread