linux-kernel - Re: [PATCH 2/2] memory: ti-aemif: add bindings for AEMIF driver

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: <5298ADD1.7050203@ti.com>
Date:	Fri, 29 Nov 2013 10:08:01 -0500
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	Grygorii Strashko <grygorii.strashko@...com>
CC:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	"ivan.khoronzhuk" <ivan.khoronzhuk@...com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Rob Landley <rob@...dley.net>,
	Russell King <linux@....linux.org.uk>,
	Mark Rutland <mark.rutland@....com>,
	<devicetree@...r.kernel.org>, Pawel Moll <pawel.moll@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	<gregkh@...uxfoundation.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...nel.crashing.org>,
	Rob Herring <rob.herring@...xeda.com>,
	<linux-kernel@...r.kernel.org>, <linux-mtd@...ts.infradead.org>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/2] memory: ti-aemif: add bindings for AEMIF driver

On Friday 29 November 2013 09:56 AM, Grygorii Strashko wrote:
> Hi Jean-Christophe,
> 
> On 11/22/2013 08:42 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 21:03 Wed 20 Nov     , ivan.khoronzhuk wrote:
>>> On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> +				the chip select signal.
>>>>> +				Minimum value is 1 (0 treated as 1).
>>>>> +
>>>>> +- ti,cs-wsetup:		write setup width, ns
>>>>> +				Time between the beginning of a memory cycle
>>>>> +				and the activation of write strobe.
>>>>> +				Minimum value is 1 (0 treated as 1).
>>>>> +
>>>>> +- ti,cs-wstrobe:	write strobe width, ns
>>>>> +				Time between the activation and deactivation of
>>>>> +				the write strobe.
>>>>> +				Minimum value is 1 (0 treated as 1).
>>>>> +
>>>>> +- ti,cs-whold:		write hold width, ns
>>>>> +				Time between the deactivation of the write
>>>>> +				strobe and the end of the cycle (which may be
>>>>> +				either an address change or the deactivation of
>>>>> +				the chip select signal.
>>>>> +				Minimum value is 1 (0 treated as 1).
>>>>> +
>>>>> +If any of the above parameters are absent, current parameter value will be taken
>>>>> +from the corresponding HW reg.
>>>>> +
>>>>> +The name for cs node must be in format csN, where N is the cs number.
>>>>
>>>> this is wired we should use reg instead to represent the cs as done for SPI
>>>> or a an other property
>>>>
>>>> Best Regards,
>>>> J.
>>>>
>>>
>>> Ok, I will add new property cs-chipselect like following :
>>>
>>> ti,cs-chipselect:	number of chipselect. Indicates on the
>>> 			aemif driver which chipselect is used
>>> 			for accessing the memory.
>>> 			For compatibles "ti,davinci-aemif" and
>>> 			"ti,keystone-aemif" it can be in range [0-3].
>>> 			For compatible "ti,omap-L138-aemif" range is [2-5].
>>>
>>> Is it OK?
>>
>> yes
>>
>> I just have one issue the whole memory concept
>>
>> for me we should do as done on pinctrl have a phandle on the device that
>> require it and handle it at device core level
>>
>> as the memory controller is not necessarely on the same bus as the memory
>> device them selves
> 
> Could you clarify your point a bit, pls?
> Are you talking about external ASRAM, NOR and NAND chips wired to CS interface?
> 
Thats probably what he means.
The mtd devices can be interface with different memory controllers having different
layouts to set-up timing registers. If these layouts were standard, then it would
have been possible to manage the information at the core layers.

Regards,
Santosh


--
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/