Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] media: rcar_drif: Use dma_request_chan() instead
 dma_request_slave_channel()
To:     Geert Uytterhoeven <geert@linux-m68k.org>
CC:     Mauro Carvalho Chehab <mchehab@kernel.org>,
        Ramesh Shanmugasundaram <rashanmu@gmail.com>,
        Vinod <vkoul@kernel.org>,
        Linux Media Mailing List <linux-media@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux-Renesas <linux-renesas-soc@vger.kernel.org>
References: <20191217104025.23318-1-peter.ujfalusi@ti.com>
 <CAMuHMdUPhabZrXJ3UqSVTdy2aWf6VG27q287MizKJ5q5tyRnwA@mail.gmail.com>
 <c7eedf72-aa00-8ffe-8c8f-4946a4f54fa7@ti.com>
 <CAMuHMdXU9_WY54iU5DY6UHZHmyaR06pW7X0nnyCWHA=R3GtcJA@mail.gmail.com>
From:   Peter Ujfalusi <peter.ujfalusi@ti.com>
Message-ID: <f2bc1bea-c844-8627-4480-8174259be0a4@ti.com>
Date:   Mon, 20 Jan 2020 14:43:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAMuHMdXU9_WY54iU5DY6UHZHmyaR06pW7X0nnyCWHA=R3GtcJA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 20/01/2020 14.36, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Mon, Jan 20, 2020 at 1:09 PM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>> On 20/01/2020 14.05, Geert Uytterhoeven wrote:
>>> On Tue, Dec 17, 2019 at 11:41 AM Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>>>> dma_request_slave_channel() is a wrapper on top of dma_request_chan()
>>>> eating up the error code.
>>>>
>>>> By using dma_request_chan() directly the driver can support deferred
>>>> probing against DMA.
>>>>
>>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>>
>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>
>>> One comment below.
>>>
>>>> --- a/drivers/media/platform/rcar_drif.c
>>>> +++ b/drivers/media/platform/rcar_drif.c
>>>> @@ -275,10 +275,10 @@ static int rcar_drif_alloc_dmachannels(struct rcar_drif_sdr *sdr)
>>>>         for_each_rcar_drif_channel(i, &sdr->cur_ch_mask) {
>>>>                 struct rcar_drif *ch = sdr->ch[i];
>>>>
>>>> -               ch->dmach = dma_request_slave_channel(&ch->pdev->dev, "rx");
>>>> -               if (!ch->dmach) {
>>>> +               ch->dmach = dma_request_chan(&ch->pdev->dev, "rx");
>>>> +               if (IS_ERR(ch->dmach)) {
>>>>                         rdrif_err(sdr, "ch%u: dma channel req failed\n", i);
>>>
>>> Now there is an error code, you might (1) want to print it, and (2) only
>>> do so when it is not due to probe deferral:
>>>
>>>         if (PTR_ERR(ch->dmach) != -EPROBE_DEFER)
>>>                 rdrif_err(sdr, "ch%u: dma channel req failed %pe\n",
>>> i, ch->dmach);
>>
>> Yes, this is true.
>>
>>>
>>>> -                       ret = -ENODEV;
>>>> +                       ret = PTR_ERR(ch->dmach);
>>
>> if (ret != -EPROBE_DEFER)
>>         rdrif_err(sdr, "ch%u: dma channel req failed (%d)\n", i, ret);
>>
>> might be simpler.
> 
> Sure, checking ret is simpler.
> But printing ch->dmach means you can use the new %pe format specifier
> to pretty-print the error code.

Ah, I was not aware of this, but there is another issue with the patch:
I need to set the ch->dmach to NULL before jumping to dmach_error..

I'll send v3 in a minute.

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki