From: <Conor.Dooley@microchip.com>
To: <i.bornyakov@metrotek.ru>
Cc: <mdf@kernel.org>, <hao.wu@intel.com>, <yilun.xu@intel.com>,
<trix@redhat.com>, <robh+dt@kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>, <linux-fpga@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<system@metrotek.ru>
Subject: Re: [PATCH v13 2/3] fpga: microchip-spi: add Microchip MPF FPGA manager
Date: Mon, 30 May 2022 14:26:18 +0000 [thread overview]
Message-ID: <95c44458-aeff-e356-1e32-c8f735570c3a@microchip.com> (raw)
In-Reply-To: <20220530120701.sedwn3qeohlnj52e@x260>
On 30/05/2022 13:07, Ivan Bornyakov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Mon, May 30, 2022 at 11:22:26AM +0000, Conor.Dooley@microchip.com wrote:
>> On 26/05/2022 19:13, Ivan Bornyakov wrote:
>>> +static int mpf_read_status(struct spi_device *spi)
>>> +{
>>> + u8 status = 0, status_command = MPF_SPI_READ_STATUS;
>>> + /*
>>> + * Two identical SPI transfers are used for status reading.
>>> + * The reason is that the first one can be inadequate.
>>> + * We ignore it completely and use the second one.
>>> + */
>>> + struct spi_transfer xfers[] = {
>>> + [0 ... 1] = {
>>> + .tx_buf = &status_command,
>>> + .rx_buf = &status,
>>> + .len = 1,
>>> + .cs_change = 1,
>>> + }
>>> + };
>>
>> Hmm, I don't think that this is correct, or at least it is not
>> correct from the polarfire /soc/ perspective. I was told that
>> there was nothing different other than the envm between the
>> programming for both devices - but this is another situation
>> where I start to question that.
>>
>> When I run this code, ISC enable /never/ passes - failing due
>> to timing out. I see something like this picture here:
>> https://i.imgur.com/EKhd1S3.png
>> You can see the 0x0B ISC enable coming through & then a status
>> check after it.
>>
>> With the current code, the value of the "status" variable will
>> be 0x0, given you are overwriting the first MISO value with the
>> second. According to the hw guys, the spi hw status *should*
>> only be returned on MISO in the first byte after SS goes low.
>>
>> If this is not the case for a non -soc part, which, as I said
>> before, I don't have a board with the SPI programmer exposed
>> for & I have been told is not the case then my comments can
>> just be ignored entirely & I'll have some head scratching to
>> do...
>>
>> Thanks,
>> Conor.
>>
>
> If I understood correctly, SS doesn't alter between two status reading
> transactions despite .cs_change = 1. May be adding some .cs_change_delay
> to spi_transfer struct can help with that?
D-oh - bug in the spi controller driver :)
LGTM now, successfully programmed my PolarFire SoC with v12.
I'd almost suggest adding a compatible for it too - but since
the envm programming doesn't work I don't think that would be
correct.
Tested-by: Conor Dooley <conor.dooley@microchip.com>
With a small comment about why it's using spi_sync_transfer():
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>
>>> + int ret = spi_sync_transfer(spi, xfers, 2);
>>> +
>>> + if ((status & MPF_STATUS_SPI_VIOLATION) ||
>>> + (status & MPF_STATUS_SPI_ERROR))
>>> + ret = -EIO;
>>> +
>>> + return ret ? : status;
>>> +}
>
next prev parent reply other threads:[~2022-05-30 15:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 18:13 [PATCH v13 0/3] Microchip Polarfire FPGA manager Ivan Bornyakov
2022-05-26 18:13 ` [PATCH v13 1/3] fpga: fpga-mgr: support bitstream offset in image buffer Ivan Bornyakov
2022-05-29 12:27 ` Xu Yilun
2022-05-26 18:13 ` [PATCH v13 2/3] fpga: microchip-spi: add Microchip MPF FPGA manager Ivan Bornyakov
2022-05-29 12:39 ` Xu Yilun
2022-05-29 13:03 ` Conor.Dooley
2022-05-29 18:51 ` Ivan Bornyakov
2022-05-29 19:27 ` Conor.Dooley
2022-05-30 11:22 ` Conor.Dooley
2022-05-30 12:07 ` Ivan Bornyakov
2022-05-30 14:26 ` Conor.Dooley [this message]
2022-05-30 14:26 ` Ivan Bornyakov
2022-05-30 15:36 ` Conor.Dooley
2022-05-31 10:53 ` Conor.Dooley
2022-05-31 14:01 ` Ivan Bornyakov
2022-05-26 18:13 ` [PATCH v13 3/3] dt-bindings: fpga: add binding doc for microchip-spi fpga mgr Ivan Bornyakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=95c44458-aeff-e356-1e32-c8f735570c3a@microchip.com \
--to=conor.dooley@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=hao.wu@intel.com \
--cc=i.bornyakov@metrotek.ru \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdf@kernel.org \
--cc=robh+dt@kernel.org \
--cc=system@metrotek.ru \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).