devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@codeaurora.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: dmaengine <dmaengine@vger.kernel.org>,
	timur@codeaurora.org, cov@codeaurora.org, jcm@redhat.com,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Vinod Koul <vinod.koul@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	devicetree <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 3/3] dma: add Qualcomm Technologies HIDMA channel driver
Date: Wed, 4 Nov 2015 21:22:45 -0500	[thread overview]
Message-ID: <563ABD75.5080608@codeaurora.org> (raw)
In-Reply-To: <CAHp75Vc65zSXXEgHHoxRsap5+HEuRzjH24xnXQWmsFXpB=h4tQ@mail.gmail.com>


>> /*
>> * We are posting descriptors to the hardware as soon as
>> * they are ready, so this function does nothing.
>> */
>
> So, the Freescale driver was written before change went effective. I
> guess in 2011 DMA Engine drivers should use issue pending.
> Please, refactor since this behaviour is expected.
>

done

>>>> +/*
>>>> + * Submit descriptor to hardware.
>>>> + * Lock the PM for each descriptor we are sending.
>>>> + */
>>>> +static dma_cookie_t hidma_tx_submit(struct dma_async_tx_descriptor *txd)
>>>> +{
>>>> +       struct hidma_chan *mchan = to_hidma_chan(txd->chan);
>>>> +       struct hidma_dev *dmadev = mchan->dmadev;
>>>> +       struct hidma_desc *mdesc;
>>>> +       unsigned long irqflags;
>>>> +       dma_cookie_t cookie;
>>>> +
>>>> +       if (!hidma_ll_isenabled(dmadev->lldev))
>>>> +               return -ENODEV;
>>>> +
>>>> +       pm_runtime_get_sync(dmadev->ddev.dev);
>>>
>>>
>>> No point to do it here. It should be done on the function that
>>> actually starts the transfer (see issue pending).
>>>
>> comment above
>
> See above as well.

done

>
>>>> +static int hidma_probe(struct platform_device *pdev)
>>>> +{
>>>> +       struct hidma_dev *dmadev;
>>>> +       int rc = 0;
>>>> +       struct resource *trca_resource;
>>>> +       struct resource *evca_resource;
>>>> +       int chirq;
>>>> +       int current_channel_index = atomic_read(&channel_ref_count);
>>>> +
>
>>>> +       /* Set DMA mask to 64 bits. */
>>>> +       rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>>>> +       if (rc) {
>>>> +               dev_warn(&pdev->dev, "unable to set coherent mask to
>>>> 64");
>>>> +               rc = dma_set_mask_and_coherent(&pdev->dev,
>>>> DMA_BIT_MASK(32));
>>>> +       }
>>>> +       if (rc)
>>>> +               goto dmafree;
>
> Maybe move these two lines inside previous condition?

ok

>
>>>> +
>>>> +       dmadev->lldev = hidma_ll_init(dmadev->ddev.dev,
>>>> +                               dmadev->nr_descriptors, dmadev->dev_trca,
>>>> +                               dmadev->dev_evca, dmadev->evridx);
>>>> +       if (!dmadev->lldev) {
>>>> +               rc = -EPROBE_DEFER;
>>>> +               goto dmafree;
>>>> +       }
>>>> +
>>>> +       rc = devm_request_irq(&pdev->dev, chirq, hidma_chirq_handler, 0,
>>>> +                             "qcom-hidma", &dmadev->lldev);
>>>
>>>
>>> Better to use request_irq().
>>>
>>
>> why? I thought we favored managed functions over standalone functions in
>> simplify the exit path.
>
> IRQ is slightly different in workflow. In most cases, unfortunately,
> there is no achievement by devm_ variant.
> At least I know two for now. One of them is DMA Engine slave drivers,
> though I didn't notice if you are using tasklet's here.
> Otherwise it's okay.
>
I'm keeping it as it is for maintenance reasons.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

      reply	other threads:[~2015-11-05  2:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1446444460-21600-1-git-send-email-okaya@codeaurora.org>
2015-11-02  6:07 ` [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya
     [not found]   ` <1446444460-21600-2-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-11-02 15:57     ` Rob Herring
     [not found]       ` <CAL_Jsq+XCkaPD_Bop_BaTfEVP2YuOQ+=ChFvyLN47jps2NcZSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-11-02 16:20         ` Sinan Kaya
2015-11-02 17:26           ` Timur Tabi
     [not found]             ` <56379CD6.5020807-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-11-02 17:42               ` Rob Herring
2015-11-02 17:48                 ` Timur Tabi
     [not found]                   ` <5637A1EB.9080002-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-11-02 18:25                     ` Rob Herring
2015-11-02 18:30                       ` Timur Tabi
2015-11-05 14:31                         ` Rob Herring
2015-11-05 14:43                           ` Timur Tabi
2015-11-06 13:13                             ` Rob Herring
2015-11-02 18:49                 ` Sinan Kaya
2015-11-02 22:00                   ` Arnd Bergmann
2015-11-03  5:18       ` Sinan Kaya
2015-11-03 10:22     ` Andy Shevchenko
2015-11-04  0:47       ` Sinan Kaya
2015-11-02  6:07 ` [PATCH V2 3/3] dma: add Qualcomm Technologies HIDMA channel driver Sinan Kaya
     [not found]   ` <1446444460-21600-4-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-11-03 10:10     ` Andy Shevchenko
2015-11-04  0:07       ` Sinan Kaya
     [not found]         ` <56394C37.4060603-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-11-04 17:44           ` Andy Shevchenko
2015-11-05  2:22             ` Sinan Kaya [this message]

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=563ABD75.5080608@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=cov@codeaurora.org \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jcm@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=timur@codeaurora.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 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).