linux-kernel - Re: atmel_spi clock polarity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080218.231243.41197917.anemo@mba.ocn.ne.jp>
Date:	Mon, 18 Feb 2008 23:12:43 +0900 (JST)
From:	Atsushi Nemoto <anemo@....ocn.ne.jp>
To:	hskinnemoen@...el.com
Cc:	david-b@...bell.net, spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: atmel_spi clock polarity

On Mon, 18 Feb 2008 12:42:37 +0100, Haavard Skinnemoen <hskinnemoen@...el.com> wrote:
> > Here is my quick workaround for this problem.  It makes all CSRn.CPOL
> > match for the transfer before activating chipselect.  I'm not quite
> > sure my analysis is correct, and there might be better solution.
> > Could you give me any comments?
> 
> I'm not sure if I fully understand what problem you're seeing. Is the
> clock state wrong when the chip select is activated?

Yes.

> If so, does the patch below help?

Hmm... It might fix my problem.  But IIRC the clock state follows
CSRn.CPOL just before the real transfer.  Like this (previous transfer
was MODE 0, new transfer is MODE 3):

           T0                T1 T2

CS      ~~~|________________________________________________

CLK     ______________________|~|___|~~~|___|~~~|___|~~~|___

SO      ~~~~~~~~~~~~~~~~~~~~~~~~~~|___|~~~|___|~~~|___|~~~|_
                                   MSB

T0-T1 was relatively longer then T1-T2.  I suppose T1 is not the
point of updating MR register, but the point of starting DMA transfer.

Anyway, I will try your patch in a few days.

---
Atsushi Nemoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/