On Tue, 26 Jan 2016, Laxman Dewangan wrote:

On Tuesday 26 January 2016 08:28 PM, Lee Jones wrote:

quoted

On Mon, 25 Jan 2016, Laxman Dewangan wrote:

quoted

Hmm. I describe the boolean and tristate only. Do I need to define
type for integer,string also?

I wouldn't describe any of them.  It's normally pretty obvious which
properties are boolean by the lack of required cell description.

Rob suggested to use the type also for Boolean and tristate. I think
it is good to have for all places that what type of values are
valid.

It's fine, and some people do describe them.  I've just never seen the
point, especially if you have a nice example of their use in the
document.  But if you insist, please ensure you are consistent, so
*all* bools need to be described.  That is not currently the case.

quoted

quoted

quoted

quoted

+The property for fps child nodes as:
+Required properties:
+	-reg: FPS number like 0, 1, 2 for FPS0, FPS1 and FPS2 respectively.

I'm surprised Rob Acked this.  We don't usually do device numbers in DT.

What is best way to make the child node for FPS and differentiate FPS0,1, 2?
What is your suggestion here?

There are lots of ways you can solve this and so many examples of
others doing so.  I suggest you have a look at some DTS files and
figure it out.  One possible solution is to use different compatible
strings.

Here, I think I can go similar to regulators where child node name
identifies the regulators.

    fps-config {
        fps0 {
            maxim,fps-time-period-us = <1280>;
            maxim,fps-enable-input = <FPS_EN_SRC_EN0>;
        };

        fps1 {
            maxim,fps-time-period-us = <2560>;
            maxim,fps-enable-input = <FPS_EN_SRC_EN1>;
        };

        fps2 {
            maxim,fps-time-period-us = <640>;
            maxim,fps-enable-input = <FPS_EN_SRC_SW>;
        };
    };

So node name gives the FPS name.

That is also an acceptable means to solve the issue.

As I said, there are many ways to skin a cat.

quoted

quoted

quoted

+Pinmux and GPIO:
+===============
I think this whole section needs moving to ../pinctrl and needs to be
reviewed by Linus W.

Is this mean I need to create DT binding doc for the each subsystem
differently?
Actually during AS3722, I had different understanding to have single file.

Yes, that way you have each of the the subsystem experts review your
documentation.  You can then link to them from this document.

OK, I will add different dt binding doc in respective driver and
squash that with respected submodule drivers.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html