[RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs

Maxime Ripard maxime.ripard at free-electrons.com
Thu Nov 24 12:44:15 PST 2016


On Thu, Nov 24, 2016 at 11:15:42AM +0000, Andre Przywara wrote:
> On 24/11/16 10:55, Maxime Ripard wrote:
> > On Thu, Nov 24, 2016 at 05:30:45PM +0800, Chen-Yu Tsai wrote:
> >> On Thu, Nov 24, 2016 at 5:16 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> >>> Hi,
> >>>
> >>> On 24/11/16 04:16, Chen-Yu Tsai wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> >>>>> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
> >>>>> have arm64 capable cores. Add the generic sunxi config symbol to allow
> >>>>> the driver to be selected by arm64 Kconfigs, which don't feature
> >>>>> SoC specific MACH_xxxx configs.
> >>>>>
> >>>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> >>>>> ---
> >>>>>  drivers/dma/Kconfig | 2 +-
> >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> >>>>> index af63a6b..003c284 100644
> >>>>> --- a/drivers/dma/Kconfig
> >>>>> +++ b/drivers/dma/Kconfig
> >>>>> @@ -157,7 +157,7 @@ config DMA_SUN4I
> >>>>>
> >>>>>  config DMA_SUN6I
> >>>>>         tristate "Allwinner A31 SoCs DMA support"
> >>>>> -       depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
> >>>>> +       depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
> >>>>
> >>>> AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
> >>>> (And I don't have to add MACH_SUN9I later :) )
> >>>
> >>> Sure, admittedly it was just a quick hack to get things going.
> >>> Actually I don't know why we had a *depend* on those MACH_s before. I
> >>> think technically it does not depend on a certain SoC (having the
> >>> COMPILE_TEST in there hints on that). So what about:
> >>
> >> It was really because this DMA engine only comes with the later
> >> SoCs. We have dma-sun4i for the older one.
> > 
> > Indeed.
> > 
> >> But yes, there's no reason why you can't build it for the earlier
> >> SoC. It just doesn't get used.
> > 
> > I'm still in favor of keeping the depends on. There's no point of
> > compiling something we know have zero chance of running.
> > 
> > (But that would be (ARCH_SUNXI && ARM64))
> 
> I am OK with that, just wondering if there is a definition of what
> "depends" really means. My impression what that it's a about code
> dependencies (requires a certain subsystem, for instance), not really if
> it's useful in a particular configuration.

My understanding is that it's a hard dependency that prevents
configuration that make no sense, ie being able to compile a driver
that has no chance of being useful in the system, or a driver missing
its framework of choice.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/1a161529/attachment-0001.sig>


More information about the linux-arm-kernel mailing list