From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <20140704163119.GB7106@leverpostej> References: <1404367277-12003-1-git-send-email-gshark.jeong@gmail.com> <1404367277-12003-3-git-send-email-gshark.jeong@gmail.com> <20140703090447.GC29837@leverpostej> <20140704163119.GB7106@leverpostej> Date: Mon, 7 Jul 2014 10:19:34 +0900 Message-ID: Subject: Re: [RFC v4 2/2] backlight: device tree: add new tps611xx backlight binding From: Daniel Jeong Content-Type: multipart/alternative; boundary=089e012949869a2c1004fd90447f To: Mark Rutland Cc: Jingoo Han , Bryan Wu , Lee Jones , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , "grant.likely@linaro.org" , Rob Herring , Randy Dunlap , Daniel Jeong , "linux-kernel@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" List-ID: --089e012949869a2c1004fd90447f Content-Type: text/plain; charset=UTF-8 Hi. 2014-07-05 1:31 GMT+09:00 Mark Rutland : > > > +- rfa-enable: enable request for acknowledge. > > > + If RFA is enabled, the data byte includes the RFA bit and > device will > > wait > > > + and check acknowledge from device. > > > > You didn't answer my question as to why this should be in the DT. > > > > > > According to the RFA enable, the easy scale pin works differently. > > This value should be set before the first data transfer. > > Sure, things works differently if this is set. That I understood. > > What I haven't heard is a rationale as to why this configuration option > shuold be in the DT. > > Can I enable this on all implementations, or not? > > When would I enable this and when would I not? > > The property reads like a switch to turn a feature on, rather than the > description of the presence of a feature. > > Mark. > If you want to check whether tps611xx receive data, enable RFA and disable it if you don't want to check. If you enable RFA tps611xx returns ACK signal and driver should check it. Driver can change this value if we create a file using the function, device_create_file but usually, we set the protocol at initial time and don't change the protocol at run time. It's the thing very like hsync-active or vsync-active properties of display-timing bindings. I think it is better to describe RFA as an optional property. Daniel. --089e012949869a2c1004fd90447f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi.

2014-07-05 1:31 GMT+09:00 Mark = Rutland <mark.rutland@arm.com>:
> =C2= =A0 =C2=A0 > +- rfa-enable: enable request for acknowledge.
> =C2=A0 =C2=A0 > + =C2=A0If RFA is enabled, the data byte includes t= he RFA bit and device will
> =C2=A0 =C2=A0 wait
> =C2=A0 =C2=A0 > + =C2=A0and check acknowledge from device.
>
> =C2=A0 =C2=A0 You didn't answer my question as to why this should = be in the DT.
>
>
> According to the RFA enable, the easy scale pin works differently.
> This value should be set before the first data transfer.

Sure, things works differently if this is set. That I understood.

What I haven't heard is a rationale as to why this configuration option=
shuold be in the DT.

Can I enable this on all implementations, or not?

When would I enable this and when would I not?

The property reads like a switch to turn a feature on, rather than the
description of the presence of a feature.

Mark.
If you want to check whether tps611xx rece= ive data, enable RFA and
disable it if you don't want to check. If y= ou enable RFA tps611xx returns
ACK signal and driver should check it.
Driver can change this value if we create = a file using the function,
device_creat= e_file but usually, we set the protocol at initial time and
don't c= hange the protocol at run time. It's the thing very like
hsync-active or vsync-active properties of display-timing
bindings.

I think it is better to describe RFA as an optional property.

Daniel.
=
--089e012949869a2c1004fd90447f--