[PATCH RFC 1/3] Devicetree: Add pl353 smc controller devicetree binding information

[Rob Herring]

On Mon, Apr 7, 2014 at 11:19 AM, punnaiah choudary kalluri
<punnaia at xilinx.com> wrote:
> On Fri, Mar 28, 2014 at 3:13 PM, punnaiah choudary kalluri
> <kalluripunnaiahchoudary at gmail.com> wrote:
>> On Fri, Mar 28, 2014 at 2:28 PM, Gupta, Pekon <pekon at ti.com> wrote:
>>>>From: Punnaiah Choudary Kalluri [mailto:punnaiah.choudary.kalluri at xilinx.com]
>>>>
>>>>Add pl353 static memory controller devicetree binding information.

[...]

>>>>+Mandatory timing properties for child nodes:
>>>>+- arm,nand-cycle-t0   : Read cycle time(t_rc).
>>>>+- arm,nand-cycle-t1   : Write cycle time(t_wc).
>>>>+- arm,nand-cycle-t2   : re_n assertion delay(t_rea).
>>>>+- arm,nand-cycle-t3   : we_n de-assertion delay(t_wp).
>>>>+- arm,nand-cycle-t4   : Status read time(t_clr)
>>>>+- arm,nand-cycle-t5   : ID read time(t_ar)
>>>>+- arm,nand-cycle-t6   : busy to re_n(t_rr)
>>>>+
>>>
>>> It would be good to have DT-bindings with meaningful names,
>>> and suffixed with timing units like "ns" | "ps".
>>
>> Ok.  I will add this information.
>>
>>> Also, as many of these timing parameters are common across NAND device
>>> vendors, so why not get them added to  generic NAND bindings list.
>>>         Documentation/devicetree/bindings/mtd/nand.txt
>>>
>>
>> Let me check on this and I will get back to you.
>
> Ok. I think the timing parameters defined in ONFI-1.0 spec can be added to the
> generic NAND binding list. So that the NAND controllers which have provision for
> configuring any of these timing parameters can use the generic binding info
> for accessing the NAND device.
>
> I will update accordingly and send v2 patches soon.
>

This came up not too long ago and I thought the conclusion was none of
this timing information needs to be in DT because the controller
should be able to use default timing values and query the ONFI
compliant device to get the device's timing parameters.

Rob