u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: Dhruva Gole <d-gole@ti.com>
To: Tom Rini <trini@konsulko.com>
Cc: Vaishnav Achath <vaishnav.a@ti.com>, Nishanth Menon <nm@ti.com>,
	Dhruva Gole <d-gole@ti.com>,
	Vignesh Raghavendra <vigneshr@ti.com>, <u-boot@lists.denx.de>
Subject: [PATCH] spi: spi-mem: ease checks in dtr_supports_op()
Date: Thu, 20 Oct 2022 14:04:24 +0530	[thread overview]
Message-ID: <20221020083424.86848-1-d-gole@ti.com> (raw)

Remove the extra conditions that cause some cases to fail prematurely
like if the data number of bytes is odd. The controller can handle odd
number of bytes data read in DTR Mode. Don't fail supports op for this
condition.

Signed-off-by: Dhruva Gole <d-gole@ti.com>
---

For a deeper context, refer to a cover letter from an earlier patch
series:
https://lore.kernel.org/u-boot/20221019064759.493607-1-d-gole@ti.com/T/#m3fd93bdcc30b3b5faada6abe45a4104388afc300
Here, I am trying to boot from OSPI Flash present on board the AM62-SK
EVM. However, despite enabling the necessary configs and DT nodes, my
boot flow seemed to be failing. I then came to know that the condition
causing this failure was that my generated DTB was of odd number of
bytes.
So, while loading the dtb from the Octal SPI NOR Flash to the memory,
the data.nbytes was odd which made the supports_op
function return false. This check feels a little too strict at the
spi-mem stage and we should let the controller decide what to do in case
of odd bytes in DTR. After applying this patch, I was able to
succesfully boot the AM62SK EVM without any issues.

I would also like to justify this patch by pointing the community to the
equivalent code in the linux kernel, in drivers/spi/spi-mem.c, where this check
is absent as well.

The controller does work with odd number of bytes and I have not seen
any sort of bugs in the absence of this supports_op check. Hence, feel
that it is safe enough to discard this check from here.

 drivers/spi/spi-mem.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 8e8995fc537f..eecc13bec90d 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -181,10 +181,6 @@ bool spi_mem_dtr_supports_op(struct spi_slave *slave,
 	if (op->dummy.nbytes && op->dummy.buswidth == 8 && op->dummy.nbytes % 2)
 		return false;
 
-	if (op->data.dir != SPI_MEM_NO_DATA &&
-	    op->dummy.buswidth == 8 && op->data.nbytes % 2)
-		return false;
-
 	return spi_mem_check_buswidth(slave, op);
 }
 EXPORT_SYMBOL_GPL(spi_mem_dtr_supports_op);
-- 
2.25.1


             reply	other threads:[~2022-10-20  8:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20  8:34 Dhruva Gole [this message]
2022-10-20  8:48 ` [PATCH] spi: spi-mem: ease checks in dtr_supports_op() Dhruva Gole
2022-10-23  5:29 ` Jagan Teki

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=20221020083424.86848-1-d-gole@ti.com \
    --to=d-gole@ti.com \
    --cc=nm@ti.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=vaishnav.a@ti.com \
    --cc=vigneshr@ti.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).