Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 26 Aug 2020 22:56:49 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     kuldip dwivedi <kuldip.dwivedi@puresoftware.com>,
        Mark Brown <broonie@kernel.org>,
        linux-spi <linux-spi@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Qiang Zhao <qiang.zhao@nxp.com>,
        Pankaj Bansal <pankaj.bansal@nxp.com>,
        Varun Sethi <V.Sethi@nxp.com>,
        tanveer <tanveer.alam@puresoftware.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] spi: spi-fsl-dspi: Add ACPI support
Message-ID: <20200826195649.g6k574y6ofzbagnm@skbuf>
References: <20200821131029.11440-1-kuldip.dwivedi@puresoftware.com>
 <20200822183342.6sdhp6yq6i7yvdia@skbuf>
 <CAHp75VeNXy1jWNWMuZc0bfXruKc3=0H4ezwpE8jbj6GLYk5QBA@mail.gmail.com>
 <CAHp75VetYbnOHv3LQhq4Gvs1CFe8LnZPzFAVoNmBi5DyAmZ9Jg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHp75VetYbnOHv3LQhq4Gvs1CFe8LnZPzFAVoNmBi5DyAmZ9Jg@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Aug 26, 2020 at 10:36:15PM +0300, Andy Shevchenko wrote:
> On Wed, Aug 26, 2020 at 10:34 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Sat, Aug 22, 2020 at 9:37 PM Vladimir Oltean <olteanv@gmail.com> wrote:
> > > On Fri, Aug 21, 2020 at 06:40:29PM +0530, kuldip dwivedi wrote:
> >
> > > Just noticed this now.
> > > So for device tree, spi-fsl-dspi supports the following compatibles:
> > >
> > > fsl,vf610-dspi
> > > fsl,ls1021a-v1.0-dspi
> > > fsl,ls1012a-dspi
> > > fsl,ls1028a-dspi
> > > fsl,ls1043a-dspi
> > > fsl,ls1046a-dspi
> > > fsl,ls2080a-dspi
> > > fsl,ls2085a-dspi
> > > fsl,lx2160a-dspi
> > >
> > > Depending on the compatible string, the driver knows whether to use DMA
> > > or XSPI mode, and what the FIFO size is.
>
> FIFO size can be read from the property

My personal preference is for the driver to hold the expert information
about the hardware parameters, and not the device tree. Today you need
to know only about this set of parameters, tomorrow you need something
new, but you also need to work with old DT blobs... It's a mess.

> (or better if you can derive it directly from HW, like DesignWare
> does).

Nope, can't do that. This IP block doesn't even have an ID or revision
register.

> DMA is just defined by FixedDMA resources (your platform with DMA
> provides them, otherwise no such resources).
>

This is a case of knowing that tomatoes are fruit, but being wise enough
to not put them in a fruit salad.

I would not be happy to see this driver make the decision to use DMA
based just on the presence of DMA channels in the firmware blob. On some
platforms, there are DMA channels but due to an erratum they don't work.
While on other platforms, using the DMA channels would simply cause a
performance downgrade.
Same thing about interrupts, in fact. The firmware blob tells the driver
what the interrupt line is, but it doesn't mean that the driver has to
use it.

Thanks,
-Vladimir