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;
IronPort-SDR: jQXFCqjRieCb7k89dSJUs7dk2aK3dg/U7sIt28ziFJy7PplBNy7fQDlZrXhJVRnc1UcUVLEVL0
 WW8FlmNRme6hgqI2GJLjSXn1cvhygYj2JhoGtZeFEuy+HybNUWFU9LyiCyAI/bqMYFEqoVv80L
 30tIA/hkHCBEeWU5VJZ0r08d7yZVp3meXhNet/DBfx9IyGCCU8LE7PkF+JLzoaeLq+RDJqFFzC
 vMGUlJJzlau1RbJMN3fS/IGkXcEvF4a4yDnSTX6Vxo/2B0VrkthedaTWs6LUUlWmTD55L2iYWl
 +/c=
IronPort-SDR: 74gmj+cYDEgk0e9qj2hMNWee9DTqE0mcv8+Bp3zHQOoKWGSYjKk3Kz/yL7o+wu/7jWeC316yLs
 z+ICd4Ye8EAHf9ooF6u383zhguu0oHd8SgnnCkDwAxSV4bNrNLm8qhjE4c8/NDTCtaPbGMAnzg
 vJcibrHnApuxkMgrqUDiBMYKb+1ZDEJQoGTx+TnUDwbZsIQ4v0+lC47o2NWo6aDQm3lZ2LEXiR
 vlG8eWAhMdqMOD55fhSYK68YxTkMkxMvH0lyieN5coxtGXkRHd83jpCUEJNjLViek8B1h4ozXV
 jFM=
Message-ID: <7a59492e46f34d213b83f7182c7db73954c5a9c7.camel@ew.tq-group.com>
Subject: Re: (EXT) Re: (EXT) Re: [PATCH 2/2] ARM: dts: imx6qdl: tqma6: minor
 fixes
From:   Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
To:     Fabio Estevam <festevam@gmail.com>
Cc:     Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        NXP Linux Team <linux-imx@nxp.com>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Date:   Tue, 25 Aug 2020 16:40:23 +0200
In-Reply-To: <CAOMZO5DYrkEb_G+EYAGrc+qjSsbjRdeBUU3tJUfkU6tjgNm_7g@mail.gmail.com>
References: <20200824091013.20640-1-matthias.schiffer@ew.tq-group.com>
         <20200824091013.20640-2-matthias.schiffer@ew.tq-group.com>
         <CAOMZO5DSX1pf3xxo=CGvgPmHcjMJoWFx74grVJBckSmjtF-RGg@mail.gmail.com>
         <4b7d57738ce8e2130c4740a0f3f973fbaf60a7cf.camel@ew.tq-group.com>
         <CAOMZO5DYrkEb_G+EYAGrc+qjSsbjRdeBUU3tJUfkU6tjgNm_7g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 2020-08-25 at 11:24 -0300, Fabio Estevam wrote:
> Hi Matthias,
> 
> On Tue, Aug 25, 2020 at 4:22 AM Matthias Schiffer
> <matthias.schiffer@ew.tq-group.com> wrote:
> 
> > Hmm, unless I'm overlooking something, this is not going to work:
> > 
> > - spi_get_gpio_descs() sets num_chipselect to the maximum of the
> > num_chipselect set in the driver and the number of cs-gpios
> > 
> > - spi_imx_probe() sets num_chipselect to 3 if not specified in the
> > device tree
> > 
> > So I think we would end up with 3 instead of 1 chipselect.
> 
> Oh, this has changed recently in 8cdcd8aeee281 ("spi: imx/fsl-lpspi:
> Convert to GPIO descriptors"):
> ....
> 
> -       } else {
> -               u32 num_cs;
> -
> -               if (!of_property_read_u32(np, "num-cs", &num_cs))
> -                       master->num_chipselect = num_cs;
> -               /* If not preset, default value of 1 is used */
> 
> Initially, if num-cs was not present the default value for
> num_chipselect was 1.
> 
> -       }
> +       /*
> +        * Get number of chip selects from device properties. This
> can be
> +        * coming from device tree or boardfiles, if it is not
> defined,
> +        * a default value of 3 chip selects will be used, as all the
> legacy
> +        * board files have <= 3 chip selects.
> +        */
> +       if (!device_property_read_u32(&pdev->dev, "num-cs", &val))
> +               master->num_chipselect = val;
> +       else
> +               master->num_chipselect = 3;
> 
> Now it became 3.
> 
> I think this is a driver issue and we should fix the driver instead
> of
> requiring to pass num-cs to the device tree.
> 
> 
> num-cs is not even documented in the spi-imx binding.

Makes sense. Does the following logic sound correct?

- If num-cs is set, use that (and add it to the docs)
- If num-cs is unset, use the number of cs-gpios
- If num-cs is unset and no cs-gpios are defined, use a driver-provided 
default


I'm not sure if 3 is a particularly useful default either, but it seems
it was chosen to accommodate boards that previously set this via
platform data. All SoCs I've checked (i.MX6Q/DL, i.MX6UL, i.MX7) have 4
internal CS pins per ECSPI instance, so maybe the driver should use
that as its default instead?