All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.