Devicetree
 help / color / mirror / Atom feed
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 v11 2/3] fpga: microchip-spi: add Microchip MPF FPGA manager
Date: Wed, 11 May 2022 11:36:33 +0000	[thread overview]
Message-ID: <f1557776-36c9-083f-2101-db84ca9a9cfa@microchip.com> (raw)
In-Reply-To: <20220511081532.7gkmz3uumzxgwfaf@h-e2.ddg>

On 11/05/2022 09:15, Ivan Bornyakov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Tue, May 10, 2022 at 12:29:54PM +0100, Conor Dooley wrote:
>> On 09/05/2022 19:56, Conor Dooley wrote:
>>> On 09/05/2022 18:16, Ivan Bornyakov wrote:
>>>> On Mon, May 09, 2022 at 11:41:18AM +0000, Conor.Dooley@microchip.com wrote:
>>>>> Hey Ivan, one comment below.
>>>>> Thanks,
>>>>> Conor.
>>>>>
>>>>> On 07/05/2022 08:43, Ivan Bornyakov wrote:
>>>>>> ... snip ...
>>>>>> +static int mpf_read_status(struct spi_device *spi)
>>>>>> +{
>>>>>> +       u8 status, status_command = MPF_SPI_READ_STATUS;
>>>>>> +       struct spi_transfer xfer = {
>>>>>> +               .tx_buf = &status_command,
>>>>>> +               .rx_buf = &status,
>>>>>> +               .len = 1,
>>>>>> +       };
>>>>>> +       int ret = spi_sync_transfer(spi, &xfer, 1);
>>>>>> +
>>>>>> +       if ((status & MPF_STATUS_SPI_VIOLATION) ||
>>>>>> +           (status & MPF_STATUS_SPI_ERROR))
>>>>>> +               ret = -EIO;
>>>>>> +
>>>>>> +       return ret ? : status;
>>>>>> +}
>>>>>> +
>>>>>> ... snip ...
>>>>>> +
>>>>>> +static int poll_status_not_busy(struct spi_device *spi, u8 mask)
>>>>>> +{
>>>>>> +       int status, timeout = MPF_STATUS_POLL_TIMEOUT;
>>>>>> +
>>>>>> +       while (timeout--) {
>>>>>> +               status = mpf_read_status(spi);
>>>>>> +               if (status < 0 ||
>>>>>> +                   (!(status & MPF_STATUS_BUSY) && (!mask || (status & mask))))
>>>>>> +                       return status;
>>>>>> +
>>>>>> +               usleep_range(1000, 2000);
>>>>>> +       }
>>>>>> +
>>>>>> +       return -EBUSY;
>>>>>> +}
>>>>>
>>>>> Is there a reason you changed this from the snippet you sent me
>>>>> in the responses to version 8:
>>>>> static int poll_status_not_busy(struct spi_device *spi, u8 mask)
>>>>> {
>>>>>          u8 status, status_command = MPF_SPI_READ_STATUS;
>>>>>          int ret, timeout = MPF_STATUS_POLL_TIMEOUT;
>>>>>          struct spi_transfer xfer = {
>>>>>                  .tx_buf = &status_command,
>>>>>                  .rx_buf = &status,
>>>>>                  .len = 1,
>>>>>          };
>>>>>
>>>>>          while (timeout--) {
>>>>>                  ret = spi_sync_transfer(spi, &xfer, 1);
>>>>>                  if (ret < 0)
>>>>>                          return ret;
>>>>>
>>>>>                  if (!(status & MPF_STATUS_BUSY) && (!mask || (status & mask)))
>>>>>                          return status;
>>>>>
>>>>>                  usleep_range(1000, 2000);
>>>>>          }
>>>>>
>>>>>          return -EBUSY;
>>>>> }
>>>>>
>>>>> With the current version, I hit the "Failed to write bitstream
>>>>> frame" check in mpf_ops_write at random points in the transfer.
>>>>> Replacing poll_status_not_busy with the above allows it to run
>>>>> to completion.
>>>>
>>>> In my eyes they are equivalent, aren't they?
>>>>
>>>
>>> I was in a bit of a rush today & didn't have time to do proper
>>> debugging, I'll put some debug code in tomorrow and try to find
>>> exactly what is different between the two.
>>>
>>> Off the top of my head, since I don't have a board on me to test,
>>> the only difference I can see is that with the snippet you only
>>> checked if spi_sync_transfer was negative whereas now you check
>>> if it has a value at all w/ that ternary operator.
>>>
>>> But even that seems like it *shouldn't* be the problem, since ret
>>> should contain -errno or zero, right?
>>> Either way, I will do some digging tomorrow.
>>
>> I put a printk("status %x, ret %d", status, ret); into the failure
>> path of mpf_read_status() & it looks like a status 0xA is being
>> returned - error & ready? That seems like a very odd combo to be
>> getting back out of it. It shouldn't be dodgy driver/connection
>> either, b/c that's what I see if I connect my protocol analyser:
>> https://i.imgur.com/VbjgfCk.png
>>
>> That's mosi (hex), ss, sclk, mosi, miso (hex), miso in descending
>> order.
>>
>> I think what was happening was with the snippet you returned one
>> of the following: -EBUSY, ret (aka -errno) or status. Since status
>> is positive, the checks in mpf_spi_write.*() saw nothing wrong at
>> all and programming continued despite there being a problem.
>>
>> The new version fixes this by returning -EIO rather than status from
>> poll_status_not_busy().
>>
>> I wish I had a socketable PolarFire so I could investigate further,
>> but this looks like it might a be hardware issue somewhere on my
>> end?
>>
>> So ye, sorry for the noise and carry on! I'll try tofind what is to
>> blame for it.
>>
>> Thanks,
>> Conor.
>>
> 
> Hi, Conor.
> 
> I've just noticed in SPI-DirectC User Guide [1] ch. 9 SmartFusion2 and
> IGLOO2 SPI-Slave Programming Waveform Analysis, that hw status checked
> two times every time. Does MPF family also need double check hw status?
> Does adding second mpf_read_status() to poll_status_not_busy() routine
> help with your issue?

Hey Ivan,
Tried your suggestion. Previously I was failing quite consistently at
transfer 34 of 590k, and sometimes making it a further. With your
suggestion, I was making it significantly further (100k+) but still
running into some of the 0xA status.
Decided to move the double check into mpfs_read_status (see the below
diff) did not run into any the 0xA statuses.
It's worth pointing out that this is the *first* time I have seen
Flash Pro Express report that the FPGA array has been enabled after
programming!

Seems like at the very least this (hacky) diff is not harmful?
Please give it a try yourself and check that things still work for
you.

diff --git a/drivers/fpga/microchip-spi.c b/drivers/fpga/microchip-spi.c
index 63b75dff2522..183cdfc05c4a 100644
--- a/drivers/fpga/microchip-spi.c
+++ b/drivers/fpga/microchip-spi.c
@@ -47,18 +47,30 @@ struct mpf_priv {
  static int mpf_read_status(struct spi_device *spi)
  {
         u8 status, status_command = MPF_SPI_READ_STATUS;
+       u8 status_repeat;
         struct spi_transfer xfer = {
                 .tx_buf = &status_command,
                 .rx_buf = &status,
                 .len = 1,
         };
+       struct spi_transfer xfer_repeat = {
+               .tx_buf = &status_command,
+               .rx_buf = &status_repeat,
+               .len = 1,
+       };
         int ret = spi_sync_transfer(spi, &xfer, 1);
+       int ret_repeat = spi_sync_transfer(spi, &xfer_repeat, 1);
+
+       if (ret || ret_repeat)
+               return -EIO;
  
-       if ((status & MPF_STATUS_SPI_VIOLATION) ||
-           (status & MPF_STATUS_SPI_ERROR))
+       if (status != status_repeat)
+               printk("status disagreement %x %x", status, status_repeat);
+       if ((status_repeat & MPF_STATUS_SPI_VIOLATION) ||
+           (status_repeat & MPF_STATUS_SPI_ERROR))
                 ret = -EIO;
  
-       return ret ? : status;
+       return ret ?: status_repeat;
  }
  
  static enum fpga_mgr_states mpf_ops_state(struct fpga_manager *mgr)


  parent reply	other threads:[~2022-05-11 11:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-07  7:43 [PATCH v11 0/3] Microchip Polarfire FPGA manager Ivan Bornyakov
2022-05-07  7:43 ` [PATCH v11 1/3] fpga: fpga-mgr: support bitstream offset in image buffer Ivan Bornyakov
2022-05-07  7:43 ` [PATCH v11 2/3] fpga: microchip-spi: add Microchip MPF FPGA manager Ivan Bornyakov
2022-05-09 11:41   ` Conor.Dooley
2022-05-09 17:16     ` Ivan Bornyakov
2022-05-09 18:56       ` Conor Dooley
2022-05-10 11:29         ` Conor Dooley
2022-05-11  8:15           ` Ivan Bornyakov
2022-05-11  8:18             ` Ivan Bornyakov
2022-05-11 11:36             ` Conor.Dooley [this message]
2022-05-11 11:46               ` Ivan Bornyakov
2022-05-07  7:43 ` [PATCH v11 3/3] dt-bindings: fpga: add binding doc for microchip-spi fpga mgr Ivan Bornyakov
2022-05-09 11:04   ` Conor.Dooley

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=f1557776-36c9-083f-2101-db84ca9a9cfa@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