dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Clément Léger" <clement.leger@bootlin.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dmaengine: at_xdmac: use module_platform_driver
Date: Wed, 28 Jul 2021 09:38:31 +0200	[thread overview]
Message-ID: <20210728093831.27430737@fixe.home> (raw)
In-Reply-To: <YQD/skGeS0rzYS5P@matsya>

Le Wed, 28 Jul 2021 12:26:50 +0530,
Vinod Koul <vkoul@kernel.org> a écrit :

> On 25-06-21, 11:00, Clément Léger wrote:
> > The driver was previously probed with platform_driver_probe. This
> > does not allow the driver to be probed again later if probe function
> > returns -EPROBE_DEFER. This patch replace the use of
> > platform_driver_probe with module_platform_driver which allows that.
> > 
> > Signed-off-by: Clément Léger <clement.leger@bootlin.com>
> > ---
> >  drivers/dma/at_xdmac.c | 6 +-----
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> > 
> > diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> > index 64a52bf4d737..109a4c0895f4 100644
> > --- a/drivers/dma/at_xdmac.c
> > +++ b/drivers/dma/at_xdmac.c
> > @@ -2238,11 +2238,7 @@ static struct platform_driver
> > at_xdmac_driver = { }
> >  };
> >  
> > -static int __init at_xdmac_init(void)
> > -{
> > -	return platform_driver_probe(&at_xdmac_driver,
> > at_xdmac_probe); -}
> > -subsys_initcall(at_xdmac_init);
> > +module_platform_driver(at_xdmac_driver);  
> 
> You are also changing the init call here, there is a reason why
> dmaengine drivers are subsys_initcall.. have you tested this?
> 

I understood that the subsys initcall was there to probe the DMA driver
earlier than other drivers (at least I guess this was the reason). I
also tested it and can confirm you this works as expected on my
platform (sama5d2_xplained and sama5d27_som1).

In my configuration, the clocks are provided using SCMI and the SCMI
driver probes them later than other drivers. 

With the current subsys_initcall, platform_driver_probe calls
__platform_driver_probe which will eventually calls platform_probe.
This one will fails because SCMI clocks are not available at this time.
And as said in the kernel doc, __platform_driver_probe is incompatible
with deferred probing. This leads to failure of all drivers that needs
DMA channels provbided by at_xdmac.

With module_platform_driver, the at_xdmac driver is correctly probed
again later and all drivers that depends on DMA channels provided by
this one are also correctly probed. The deferred probing mechanism seems
to do its job correctly (at least in my case).



  reply	other threads:[~2021-07-28  7:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25  9:00 Clément Léger
2021-07-28  6:56 ` Vinod Koul
2021-07-28  7:38   ` Clément Léger [this message]
2021-07-28  8:23     ` Vinod Koul
2021-07-28  8:37       ` Clément Léger

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20210728093831.27430737@fixe.home \
    --to=clement.leger@bootlin.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ludovic.desroches@microchip.com \
    --cc=tudor.ambarus@microchip.com \
    --cc=vkoul@kernel.org \
    --subject='Re: [PATCH] dmaengine: at_xdmac: use module_platform_driver' \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).