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: <4FF8F58FAA9D5D4193D4E554E4352C5902C52798@XAP-PVEXMBX02.xlnx.xilinx.com>
Date:	Wed, 20 Jan 2016 05:21:24 +0000
From:	Lakshmi Sai Krishna Potthuri 
	<lakshmi.sai.krishna.potthuri@...inx.com>
To:	Chen-Yu Tsai <wens@...e.org>
CC:	Michal Simek <michals@...inx.com>,
	Soren Brinkmann <sorenb@...inx.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Kevin Hao <haokexin@...il.com>,
	"Emil P. Lenchak" <emill@...inx.com>,
	Tobias Klauser <tklauser@...tanz.ch>,
	"Sudeep Holla" <Sudeep.Holla@....com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Jisheng Zhang <jszhang@...vell.com>,
	"Ivan T. Ivanov" <ivan.ivanov@...aro.org>,
	Scott Branden <sbranden@...adcom.com>,
	Vincent Yang <vincent.yang.fujitsu@...il.com>,
	Haibo Chen <haibo.chen@...escale.com>,
	Marek Vasut <marex@...x.de>,
	"ludovic.desroches@...el.com" <ludovic.desroches@...el.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"Suman Tripathi" <stripathi@....com>,
	Shawn Lin <shawn.lin@...k-chips.com>,
	devicetree <devicetree@...r.kernel.org>,
	Harini Katakam <harinik@...inx.com>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Anirudha Sarangi <anirudh@...inx.com>,
	Punnaiah Choudary Kalluri <punnaia@...inx.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [LINUX PATCH 1/5] mmc: Workaround for the issue in auto tuning
 mode.

Hi,

> -----Original Message-----
> From: Chen-Yu Tsai [mailto:wens@...e.org]
> Sent: Tuesday, January 19, 2016 8:32 PM
> To: Lakshmi Sai Krishna Potthuri
> Cc: Michal Simek; Soren Brinkmann; Ulf Hansson; Kevin Hao; Emil P. Lenchak;
> Tobias Klauser; Sudeep Holla; Adrian Hunter; Jisheng Zhang; Ivan T. Ivanov;
> Scott Branden; Vincent Yang; Haibo Chen; Marek Vasut;
> ludovic.desroches@...el.com; Rob Herring; Pawel Moll; Mark Rutland; Ian
> Campbell; Kumar Gala; Suman Tripathi; Shawn Lin; devicetree; Harini
> Katakam; linux-mmc@...r.kernel.org; linux-kernel; Lakshmi Sai Krishna
> Potthuri; Anirudha Sarangi; Punnaiah Choudary Kalluri; linux-arm-kernel
> Subject: Re: [LINUX PATCH 1/5] mmc: Workaround for the issue in auto
> tuning mode.
>
> Hi,
>
> On Tue, Jan 19, 2016 at 10:17 PM, P L Sai Krishna
> <lakshmi.sai.krishna.potthuri@...inx.com> wrote:
> > During the auto tuning mode of SDR104, a couple of transactions on
> > rx_tap_value which are not incremental or decremental by 1.
> > Since the DLL supports only increment/decrement by 1 during dynamic
> > change, observed unexpected delays during both these transactions.
> > The first transaction occurs when the tap value reached 0x1F, it will
> > reset to 0x0 and go till 0x7. This transaction can be avoided by
> > changing the corecfg_dis1p5xtuningcnt to 1'b1 which is currently tied
> > to 1'b0 in the RTL.
> > The second transaction occurs after the tuning is completed.
> > Once the tuning is done, the tuning fsm in the host controller
> > calculates the average pattern match and will write the value on the
> > rx tap value. Therefore observed a transaction from 0x7 to the final
> > value which need not be a increment/decrement value.
> > Because of this issue DLL tuning will not be accurate and SDR50,
> > SDR104 & HS200 modes may not work.
> >
> > This patch adds workaround to change the SD clock after tuning done to
> > provide accurate DLL tuning for SDR50,
> > SD104 & HS200 modes.
> >
> > After receiving the tuning done, program "SDCLK Frequency Select"
> > of clock control register with a value different from the desired
> > value. Wait for the "Internal Clock Stable" bit of the clock control
> > register and program the desired frequency.
>
> Does this series apply to any non-Arasan or non-sdhci mmc hosts?
> The subject does not indicate a specific platform.

This series is applicable only for Zynq Ultrascal+ MPSoC which
uses Arasan SDHCI.
Sorry, I will change the description to indicate the same.
The DT property used is made generic but the tuning used is
Specific to this SoC.

Regards
Sai Krishna


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ