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] spi-pxa2xx.c: modify the chip selection timing when spi
 transfer
To:     xiao jin <jin.xiao@intel.com>, daniel@zonque.org,
        haojian.zhuang@gmail.com, robert.jarzmik@free.fr,
        broonie@kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
        yanmin.zhang@intel.com
Cc:     "he, bo" <bo.he@intel.com>
References: <20190306030519.10746-1-jin.xiao@intel.com>
From:   Jarkko Nikula <jarkko.nikula@linux.intel.com>
Message-ID: <ed09063c-00cc-a1a5-2a93-2b3361d531bf@linux.intel.com>
Date:   Wed, 6 Mar 2019 09:52:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <20190306030519.10746-1-jin.xiao@intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi

On 3/6/19 5:05 AM, xiao jin wrote:
> From: "he, bo" <bo.he@intel.com>
> 
> We find spi can't work on board. More debug shows it's related
> to the following patch that changed the chip selection assert and
> deassert timing.
> 
^^ timing caught my attention. More below.

> @@ -610,6 +596,7 @@ static void int_transfer_complete(struct driver_data *drv_data)
>   	if (!pxa25x_ssp_comp(drv_data))
>   		pxa2xx_spi_write(drv_data, SSTO, 0);
>   
> +	cs_deassert(drv_data);
>   	spi_finalize_current_transfer(drv_data->master);

This

> @@ -1070,6 +1057,7 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *master,
>   			pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
>   	}
>   
> +	cs_assert(drv_data);

and this is not correct with core message loop. It will cause the chip 
select is toggled with each transfer in PIO mode. If there is no 
cs_change flag set then there shouldn't be CS toggling between the 
transfers if SPI message consists of multiple transfers.

More over this patch also will regress with DMA mode since there won't 
be CS deassert at all.

Timing reminded me I've seen two cases where there was a timing related 
glitch in CS output:

d0283eb2dbc1 ("spi: pxa2xx: Add output control for multiple Intel LPSS 
chip selects")
7a8d44bc89e5 ("spi: pxa2xx: Fix too early chipselect deassert")

Do you have a possibility to measure with an oscilloscope what goes 
wrong with the CS after d5898e19c0d7 ("spi: pxa2xx: Use core message 
processing loop")?

Can you share your setup if I can reproduce it here? E.g. SPI clock 
frequency, single or multiple CS, frequency of occurrence, etc

-- 
Jarkko