About DT binding of reset control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, Rob, DT folks,

I am trying to add the reset control into
the Denali NAND controller driver:
Documentation/devicetree/bindings/mtd/denali-nand.txt
drivers/mtd/nand/raw/denali_dt.c

I'd like to get some advice about the DT binding
before the detailed implementation.



The IP datasheet clearly says
two separate reset lines, like this:

rst_n :           controller core reset
reg_rst_n:     register flip-flop reset


But, in actual SoC integration,
the two reset signals are often tied up together, and
the reset controller only provides 1-bit control.

(The upstream platforms, SoCFPGA, UniPhier,
 both are this case.)


In this case, which is more preferred for the
DT binding?


[1] Define two resets explicitly according to the IP spec

Optional properties:
  reset-names :  contain "nand", "reg"
  resets: phandles to the controller core reset, the register reset

Example:

   nand {
         ....
         reset-names = "nand", "reg";
         resets = <&nand_rst>, <&nand_rst>;
         ...
   };



[2] Allow arbitrary number of reset lines


Optional properties:
     resets: phandle(s) to reset(s)

   The number of reset lines is SoC-dependent.


Examples:

      nand {

               resets = <&nand>;
                ...
       };





I guess [1] is more precise as the hardware specification.
But, DT files will end up with giving the same phandle
to both of the two resets.
I think it is OK, but anyway better to ask
before proceeding.

Thanks.

--
Best Regards
Masahiro Yamada



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux