All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Florian Meier <florian.meier@koalo.de>
Cc: devicetree <devicetree@vger.kernel.org>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Vinod Koul <vinod.koul@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	linux-rpi-kernel <linux-rpi-kernel@lists.infradead.org>,
	dmaengine <dmaengine@vger.kernel.org>,
	Stephen Warren <swarren@nvidia.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCHv9] dmaengine: Add support for BCM2835
Date: Sun, 5 Jan 2014 15:06:03 +0100	[thread overview]
Message-ID: <201401051506.03481.arnd@arndb.de> (raw)
In-Reply-To: <CABDT8WzhpH2yX=HD9wsx+bN17Qp0hLX45-VMF0a3RAiwWx7F4Q@mail.gmail.com>

On Saturday 04 January 2014, Florian Meier wrote:
> On 02.01.2014 19:03, Arnd Bergmann wrote:
> > On Thursday 02 January 2014 18:49:23 Florian Meier wrote:
> >> Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
> >> Currently it only supports cyclic DMA.
> >
> > Looks very nice. Just a few details I noticed:
> >
> >> +#if defined(CONFIG_OF)
> >> +static const struct of_device_id bcm2835_dma_of_match[] = {
> >> + { .compatible = "brcm,bcm2835-dma", },
> >> + {},
> >> +};
> >> +MODULE_DEVICE_TABLE(of, bcm2835_dma_of_match);
> >> +#endif
> >
> > I doubt we are going to see non-DT versions of this driver, so the #ifdef
> > can just get removed here.
> 
> As already explained in previous versions of this patch thread, there is
> a non-DT version in a downstream kernel and the more I make this patch
> incompatible with non-DT, the harder it gets to upstream the remaining
> stuff. I hope this is not something that blocks this driver from getting
> accepted.

In this case, that's certainly not an excuse unless you are worried about
400 bytes of .rodata in one driver and there are no side-effects of having
the device ID listed when it's not used. Even if it made a real difference
to another project, you'd need a much better excuse -- if you are worried
about compatibility between mainline and some downstream kernel, how about
changing that downstream kernel to use DT?

> > [...]
> > This can now be simplified using the dma_get_any_slave_channel() interface
> > taht Stephen Warren introduced.
> > [...]
> > dma_set_mask_and_coherent()
> 
> Sigh, the API is developing faster than I can keep track with updating
> this patch. I hope some day I will be faster....
> When Russell told me about the second one before, it hoped that I can
> avoid merging different trees on my own, but it seems that you want me
> to do that ;-)

The dma_get_any_slave_channel() change is probably my fault. I suggested
both the initial dma_get_slave_channel() API and this one because the
original approach turned out too complicated. If dma_set_mask_and_coherent().

I don't think you have to merge other trees, to get both APIs, they should
already be part of the dma-slave tree that your patch would get merged
into. If not, we can probably come up with a different solution. The
dma_set_mask_and_coherent() suggestion is not as important as the
dma_get_any_slave_channel() one, if you have to choose between them.

> >> + if (pdev->dev.of_node) {
> >> + /* Device-tree DMA controller registration */
> >> + rc = of_dma_controller_register(pdev->dev.of_node,
> >> + bcm2835_dma_xlate, od);
> >> + if (rc) {
> >> + dev_err(&pdev->dev, "Failed to register DMA controller\n");
> >> + goto err_no_dma;
> >> + }
> >> + }
> >
> > If pdev->dev.of_node isn't set, you didn't get here, so the if() can be removed.
> 
> Why not? (In the case of non-DT initialization)

The code I quoted is right after these lines:

+       /* Request DMA channel mask from device tree */
+       if (of_property_read_u32(pdev->dev.of_node,
+                       "brcm,dma-channel-mask",
+                       &chans_available)) {
+               dev_err(&pdev->dev, "Failed to get channel mask\n");
+               rc = -EINVAL;
+               goto err_no_dma;
+       }

If DT is disabled or not used, you return -EINVAL here.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv9] dmaengine: Add support for BCM2835
Date: Sun, 5 Jan 2014 15:06:03 +0100	[thread overview]
Message-ID: <201401051506.03481.arnd@arndb.de> (raw)
In-Reply-To: <CABDT8WzhpH2yX=HD9wsx+bN17Qp0hLX45-VMF0a3RAiwWx7F4Q@mail.gmail.com>

On Saturday 04 January 2014, Florian Meier wrote:
> On 02.01.2014 19:03, Arnd Bergmann wrote:
> > On Thursday 02 January 2014 18:49:23 Florian Meier wrote:
> >> Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
> >> Currently it only supports cyclic DMA.
> >
> > Looks very nice. Just a few details I noticed:
> >
> >> +#if defined(CONFIG_OF)
> >> +static const struct of_device_id bcm2835_dma_of_match[] = {
> >> + { .compatible = "brcm,bcm2835-dma", },
> >> + {},
> >> +};
> >> +MODULE_DEVICE_TABLE(of, bcm2835_dma_of_match);
> >> +#endif
> >
> > I doubt we are going to see non-DT versions of this driver, so the #ifdef
> > can just get removed here.
> 
> As already explained in previous versions of this patch thread, there is
> a non-DT version in a downstream kernel and the more I make this patch
> incompatible with non-DT, the harder it gets to upstream the remaining
> stuff. I hope this is not something that blocks this driver from getting
> accepted.

In this case, that's certainly not an excuse unless you are worried about
400 bytes of .rodata in one driver and there are no side-effects of having
the device ID listed when it's not used. Even if it made a real difference
to another project, you'd need a much better excuse -- if you are worried
about compatibility between mainline and some downstream kernel, how about
changing that downstream kernel to use DT?

> > [...]
> > This can now be simplified using the dma_get_any_slave_channel() interface
> > taht Stephen Warren introduced.
> > [...]
> > dma_set_mask_and_coherent()
> 
> Sigh, the API is developing faster than I can keep track with updating
> this patch. I hope some day I will be faster....
> When Russell told me about the second one before, it hoped that I can
> avoid merging different trees on my own, but it seems that you want me
> to do that ;-)

The dma_get_any_slave_channel() change is probably my fault. I suggested
both the initial dma_get_slave_channel() API and this one because the
original approach turned out too complicated. If dma_set_mask_and_coherent().

I don't think you have to merge other trees, to get both APIs, they should
already be part of the dma-slave tree that your patch would get merged
into. If not, we can probably come up with a different solution. The
dma_set_mask_and_coherent() suggestion is not as important as the
dma_get_any_slave_channel() one, if you have to choose between them.

> >> + if (pdev->dev.of_node) {
> >> + /* Device-tree DMA controller registration */
> >> + rc = of_dma_controller_register(pdev->dev.of_node,
> >> + bcm2835_dma_xlate, od);
> >> + if (rc) {
> >> + dev_err(&pdev->dev, "Failed to register DMA controller\n");
> >> + goto err_no_dma;
> >> + }
> >> + }
> >
> > If pdev->dev.of_node isn't set, you didn't get here, so the if() can be removed.
> 
> Why not? (In the case of non-DT initialization)

The code I quoted is right after these lines:

+       /* Request DMA channel mask from device tree */
+       if (of_property_read_u32(pdev->dev.of_node,
+                       "brcm,dma-channel-mask",
+                       &chans_available)) {
+               dev_err(&pdev->dev, "Failed to get channel mask\n");
+               rc = -EINVAL;
+               goto err_no_dma;
+       }

If DT is disabled or not used, you return -EINVAL here.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Florian Meier <florian.meier@koalo.de>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Vinod Koul <vinod.koul@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	devicetree <devicetree@vger.kernel.org>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	"linux-rpi-kernel" <linux-rpi-kernel@lists.infradead.org>,
	dmaengine <dmaengine@vger.kernel.org>,
	Stephen Warren <swarren@nvidia.com>
Subject: Re: [PATCHv9] dmaengine: Add support for BCM2835
Date: Sun, 5 Jan 2014 15:06:03 +0100	[thread overview]
Message-ID: <201401051506.03481.arnd@arndb.de> (raw)
In-Reply-To: <CABDT8WzhpH2yX=HD9wsx+bN17Qp0hLX45-VMF0a3RAiwWx7F4Q@mail.gmail.com>

On Saturday 04 January 2014, Florian Meier wrote:
> On 02.01.2014 19:03, Arnd Bergmann wrote:
> > On Thursday 02 January 2014 18:49:23 Florian Meier wrote:
> >> Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
> >> Currently it only supports cyclic DMA.
> >
> > Looks very nice. Just a few details I noticed:
> >
> >> +#if defined(CONFIG_OF)
> >> +static const struct of_device_id bcm2835_dma_of_match[] = {
> >> + { .compatible = "brcm,bcm2835-dma", },
> >> + {},
> >> +};
> >> +MODULE_DEVICE_TABLE(of, bcm2835_dma_of_match);
> >> +#endif
> >
> > I doubt we are going to see non-DT versions of this driver, so the #ifdef
> > can just get removed here.
> 
> As already explained in previous versions of this patch thread, there is
> a non-DT version in a downstream kernel and the more I make this patch
> incompatible with non-DT, the harder it gets to upstream the remaining
> stuff. I hope this is not something that blocks this driver from getting
> accepted.

In this case, that's certainly not an excuse unless you are worried about
400 bytes of .rodata in one driver and there are no side-effects of having
the device ID listed when it's not used. Even if it made a real difference
to another project, you'd need a much better excuse -- if you are worried
about compatibility between mainline and some downstream kernel, how about
changing that downstream kernel to use DT?

> > [...]
> > This can now be simplified using the dma_get_any_slave_channel() interface
> > taht Stephen Warren introduced.
> > [...]
> > dma_set_mask_and_coherent()
> 
> Sigh, the API is developing faster than I can keep track with updating
> this patch. I hope some day I will be faster....
> When Russell told me about the second one before, it hoped that I can
> avoid merging different trees on my own, but it seems that you want me
> to do that ;-)

The dma_get_any_slave_channel() change is probably my fault. I suggested
both the initial dma_get_slave_channel() API and this one because the
original approach turned out too complicated. If dma_set_mask_and_coherent().

I don't think you have to merge other trees, to get both APIs, they should
already be part of the dma-slave tree that your patch would get merged
into. If not, we can probably come up with a different solution. The
dma_set_mask_and_coherent() suggestion is not as important as the
dma_get_any_slave_channel() one, if you have to choose between them.

> >> + if (pdev->dev.of_node) {
> >> + /* Device-tree DMA controller registration */
> >> + rc = of_dma_controller_register(pdev->dev.of_node,
> >> + bcm2835_dma_xlate, od);
> >> + if (rc) {
> >> + dev_err(&pdev->dev, "Failed to register DMA controller\n");
> >> + goto err_no_dma;
> >> + }
> >> + }
> >
> > If pdev->dev.of_node isn't set, you didn't get here, so the if() can be removed.
> 
> Why not? (In the case of non-DT initialization)

The code I quoted is right after these lines:

+       /* Request DMA channel mask from device tree */
+       if (of_property_read_u32(pdev->dev.of_node,
+                       "brcm,dma-channel-mask",
+                       &chans_available)) {
+               dev_err(&pdev->dev, "Failed to get channel mask\n");
+               rc = -EINVAL;
+               goto err_no_dma;
+       }

If DT is disabled or not used, you return -EINVAL here.

	Arnd

  reply	other threads:[~2014-01-05 14:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-02 17:49 [PATCHv9] dmaengine: Add support for BCM2835 Florian Meier
2014-01-02 17:49 ` Florian Meier
2014-01-02 17:49 ` Florian Meier
     [not found] ` <52C5A6A3.8000405-oZ8rN/sblLk@public.gmane.org>
2014-01-02 18:03   ` Arnd Bergmann
2014-01-02 18:03     ` Arnd Bergmann
2014-01-02 18:03     ` Arnd Bergmann
2014-01-04 15:27     ` Florian Meier
2014-01-04 15:27       ` Florian Meier
2014-01-04 15:27       ` Florian Meier
2014-01-05 14:06       ` Arnd Bergmann [this message]
2014-01-05 14:06         ` Arnd Bergmann
2014-01-05 14:06         ` Arnd Bergmann
2014-01-05 15:06         ` Florian Meier
2014-01-05 15:06           ` Florian Meier
2014-01-05 18:52           ` Arnd Bergmann
2014-01-05 18:52             ` Arnd Bergmann
2014-01-05 18:52             ` Arnd Bergmann
2014-01-05 19:05             ` Florian Meier
2014-01-05 19:05               ` Florian Meier
2014-01-05 19:05               ` Florian Meier

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=201401051506.03481.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=florian.meier@koalo.de \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    --cc=vinod.koul@intel.com \
    /path/to/YOUR_REPLY

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

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