linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thor Thayer <tthayer@opensource.altera.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
	Grant Likely <grant.likely@linaro.org>,
	Jiri Kosina <jkosina@suse.cz>, Pawel Moll <pawel.moll@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	ijc+devicetree <ijc+devicetree@hellion.org.uk>,
	dinguyen <dinguyen@opensource.altera.com>,
	Linux Documentation List <linux-doc@vger.kernel.org>,
	<linux-spi@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Thor Thayer <tthayer.linux@gmail.com>,
	Axel Lin <axel.lin@ingics.com>, baruch <baruch@tkos.co.il>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Jingoo Han <jg1.han@samsung.com>,
	Kumar Gala <galak@codeaurora.org>
Subject: Re: [RFC/PATCHv2 3/3] spi: dw-spi: Pointers select 16b vs. 32b DesignWare access
Date: Tue, 10 Mar 2015 17:22:09 -0500	[thread overview]
Message-ID: <54FF6E91.1010704@opensource.altera.com> (raw)
In-Reply-To: <CAHp75VcgX8WWPkHVH80eQXGAG76xSG1YpDfb24E6aWA7GZ3OZg@mail.gmail.com>



On 03/10/2015 03:44 PM, Andy Shevchenko wrote:
> On Tue, Mar 10, 2015 at 10:34 PM, Thor Thayer
> <tthayer@opensource.altera.com> wrote:
>> On 03/09/2015 03:02 PM, Andy Shevchenko wrote:
>>>
>>> On Mon, Mar 9, 2015 at 9:47 PM, Thor Thayer
>>> <tthayer@opensource.altera.com> wrote:
>>>>
>>>> On 03/09/2015 01:54 PM, Andy Shevchenko wrote:
>>>
>>>
>>>> Yes, I just need the 32 bit write. I was trying to remain consistent but
>>>> I
>>>> agree that only changing only writes would minimize the changes.
>>>
>>>
>>> Which is still makes me anxious.
>>>
>>> I have briefly read a chapter for SPI in pdf you sent link to. I
>>> didn't find anything except SPI supports 32 bit data width.
>>>
>>> It would be nice if you ping your HW engineers and clarify what
>>> exactly is happening there.
>>>
>>
>> I confirmed with our HW engineer that writes are required to be 32 bits. We
>> are in the process of updating our documentation to explicitly say this.
>>
>> Since there are no byte enables on our 32 bit APB interface, writing only 1
>> or 2 bytes could corrupt the other bytes in the 32 bit word. The 32 bit
>> write enforces requiring an explicit read/modify/write for less than 32 bit
>> writes.
>>
>> Since reads are non-destructive (nothing is being written back into the
>> register), it is safe for all reads to get promoted to 32 bit reads.
>
> Thanks for detailed explanation!
>
>> Is it preferable to have both 32 bit reads and writes for consistency?
>>
>> Or is it preferable to make the minimal number of changes which would be to
>> only add a 32 bit write function?
>
> Both I think just to be more clear.
>
> However, I'm now considering what if we just replace
> dw_{write/read}w() by l-variants without any additional DT property
> and accessor functions?
> Would it work for both your cases (old chip, new chip)?
> On my side I may test this on Intel MID.
>

Yes, this would be the simplest solution. The l-variant certainly works 
on our legacy SoCs. I'll be curious to hear your testing results.

The data sheet mentions that registers are addressed at 32-bit 
boundaries to remain consistent with the AHB bus (Section 6.1 of 
dw_apb_ssi_db.pdf).  Additionally unused bits are reserved for writes 
and 0 for reads so this seems like a good solution.

My concern is the presence of legacy devices that I have no way of 
testing. Is a Request For Test in the body of the patch sufficient?

  reply	other threads:[~2015-03-10 22:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-06 23:46 [RFC/PATCHv2 0/3] spi: spi-dw: Select 16b or 32b register access tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
     [not found] ` <1425685594-26595-1-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-06 23:46   ` [RFC/PATCHv2 1/3] spi: dw-spi: Single Register read to clear IRQs tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2015-03-07 19:46     ` Andy Shevchenko
2015-03-09 18:43     ` Mark Brown
2015-03-06 23:46   ` [RFC/PATCHv2 2/3] dt-binding: spi: spi-dw: Select 16b or 32b access for Designware SPI tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2015-03-07 19:58     ` Andy Shevchenko
2015-03-09 18:11       ` Thor Thayer
     [not found]         ` <54FDE250.3050705-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-09 18:19           ` Mark Brown
     [not found]             ` <20150309181936.GU28806-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-03-09 18:25               ` Thor Thayer
2015-03-06 23:46   ` [RFC/PATCHv2 3/3] spi: dw-spi: Pointers select 16b vs. 32b DesignWare access tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
     [not found]     ` <1425685594-26595-4-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-07 19:52       ` Andy Shevchenko
2015-03-09 18:01         ` Thor Thayer
     [not found]           ` <54FDDFE6.8010109-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-09 18:54             ` Andy Shevchenko
     [not found]               ` <CAHp75Vf6dgobzZyJxu8eiqGgC7FRrwLCmyMf5Agk6S3jHDj4bw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-09 19:47                 ` Thor Thayer
2015-03-09 20:02                   ` Andy Shevchenko
     [not found]                     ` <CAHp75VcmNOaiyRNLFzQT7nKS6piZzpYSoS785J86rKtNXx6KNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-10 20:34                       ` Thor Thayer
2015-03-10 20:40                         ` Mark Brown
     [not found]                         ` <54FF556A.3020408-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-10 20:44                           ` Andy Shevchenko
2015-03-10 22:22                             ` Thor Thayer [this message]
     [not found]                               ` <54FF6E91.1010704-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-11 10:27                                 ` Andy Shevchenko

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=54FF6E91.1010704@opensource.altera.com \
    --to=tthayer@opensource.altera.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=axel.lin@ingics.com \
    --cc=baruch@tkos.co.il \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dinguyen@opensource.altera.com \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jg1.han@samsung.com \
    --cc=jkosina@suse.cz \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=tthayer.linux@gmail.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).