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;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Fri, 28 Feb 2020 12:46:01 +0100
From:   Michael Walle <michael@walle.cc>
To:     Rob Herring <robh+dt@kernel.org>
Cc:     Li Yang <leoyang.li@nxp.com>,
        "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>, linux-kernel@vger.kernel.org,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@lists.infradead.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Shawn Guo <shawnguo@kernel.org>, Jiri Slaby <jslaby@suse.com>,
        Peng Fan <peng.fan@nxp.com>,
        Vabhav Sharma <vabhav.sharma@nxp.com>
Subject: Re: [PATCH v2 3/9] tty: serial: fsl_lpuart: handle EPROBE_DEFER for
 DMA
In-Reply-To: <CAL_JsqKMNFFG5H4gPQwRdcTpfHynqZWo2A2db-oL7EmvTNqNkQ@mail.gmail.com>
References: <20200221174754.5295-1-michael@walle.cc>
 <20200221174754.5295-4-michael@walle.cc>
 <CAL_JsqL8QGKARtRAfjCMyk4Pp7EWhFMV8JQpveHoJ2OyH5kBPA@mail.gmail.com>
 <CADRPPNR1n1sviJnhq_zuUFJcMYqsVKy0O7NOF1pxF_4VH+dasg@mail.gmail.com>
 <CAL_JsqKMNFFG5H4gPQwRdcTpfHynqZWo2A2db-oL7EmvTNqNkQ@mail.gmail.com>
Message-ID: <639a1df72fbeda77436b282a99f17995@walle.cc>
User-Agent: Roundcube Webmail/1.3.10
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Rob, Hi Leo,

Am 2020-02-28 00:03, schrieb Rob Herring:
> On Thu, Feb 27, 2020 at 4:49 PM Li Yang <leoyang.li@nxp.com> wrote:
>> 
>> On Thu, Feb 27, 2020 at 4:35 PM Rob Herring <robh+dt@kernel.org> 
>> wrote:
>> >
>> > On Fri, Feb 21, 2020 at 11:48 AM Michael Walle <michael@walle.cc> wrote:
>> > >
>> > > The DMA channel might not be available at the first probe time. This is
>> > > esp. the case if the DMA controller has an IOMMU mapping.
>> > >
>> > > Use the new dma_request_chan() API and handle EPROBE_DEFER errors. Also
>> > > reorder the code a bit, so that we don't prepare the whole UART just to
>> > > determine that the DMA channel is not ready yet and we have to undo all
>> > > the stuff. Try to map the DMA channels earlier.
>> >
>> > Changing this means you never probe successfully if you boot a kernel
>> > with the DMA driver disabled (or it's IOMMU disabled). Some other
>> > drivers request DMA in open() and can work either way.

Oh, I see.

>> We got this exact issue previously with another driver.  When the

What driver is it? I've been working on the i2c-mxs.c driver which has
the same problem. Ie. its not working with DMA when the IOMMU is 
enabled.
Now that I've learned that dma_request_chan() will return EPROBE_DEFER
if the actual DMA driver is not available, I don't think there is any
trick like this there. There is no function which would be called late
except you'd do something like on the first master_xfer() try to request
the DMA channels. But I don't think that would be the way to go.

-michael

>> required DMA driver is disabled, the DMA framework cannot figure out
>> this situation and keeps returning EPROBE_DEFER.  I'm wondering if we
>> should update the DMA framework to use your deferred probe timeout
>> mechanism.  Is it still only used for debug purpose?
> 
> It's undergoing some rework ATM to not just be for debug. However,
> it's not really going to help you if you care about the console
> because waiting for the timeout will be too late to register the
> console.