From: Conor Dooley <conor@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Conor Dooley <conor.dooley@microchip.com>,
linux-spi@vger.kernel.org, linux-fpga@vger.kernel.org,
Vladimir Georgiev <v.georgiev@metrotek.ru>,
Moritz Fischer <mdf@kernel.org>, Wu Hao <hao.wu@intel.com>,
Xu Yilun <yilun.xu@intel.com>, Tom Rix <trix@redhat.com>,
valentina.fernandezalanis@microchip.com
Subject: Re: [BUG] microchip-spi programming issue
Date: Wed, 7 Jun 2023 17:48:30 +0100 [thread overview]
Message-ID: <20230607-pacemaker-subtitle-90abc2aaffc0@spud> (raw)
In-Reply-To: <6a01d7c9-8773-4206-bf8a-1f67cfe1dbb0@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
On Tue, Jun 06, 2023 at 01:04:51PM +0100, Mark Brown wrote:
> On Tue, Jun 06, 2023 at 01:01:01PM +0100, Conor Dooley wrote:
> > On Tue, Jun 06, 2023 at 12:55:58PM +0100, Mark Brown wrote:
>
> > > It is obviously going to corrupt the transfer if we deassert chip select
> > > without being asked, it is only valid to change it during a message if
> > > cs_change is set.
>
> > So, reading between the lines, I shouldn't have doubted myself and this
> > is an issue in the SPI controller or its driver?
>
> Yes. Note that it may be that the hardware is limited and can't do
> whatever it's being asked to do.
Yah, looks like they were using the ecspi on an imx8mp & there are
apparently known issues there with the generation of CS on it.
GPIO CS seems to do the job for them though, so one problem less for me
to worry about :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2023-06-07 16:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 11:30 [BUG] microchip-spi programming issue Conor Dooley
2023-06-06 11:55 ` Mark Brown
2023-06-06 12:01 ` Conor Dooley
2023-06-06 12:04 ` Mark Brown
2023-06-07 16:48 ` Conor Dooley [this message]
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=20230607-pacemaker-subtitle-90abc2aaffc0@spud \
--to=conor@kernel.org \
--cc=broonie@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=hao.wu@intel.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=mdf@kernel.org \
--cc=trix@redhat.com \
--cc=v.georgiev@metrotek.ru \
--cc=valentina.fernandezalanis@microchip.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 read-only IMAP folder(s) and NNTP newsgroup(s).