On 10/18/2016 03:49 PM, Rob Herring wrote:
On Mon, Oct 17, 2016 at 09:58:26AM +0200, Jacek Anaszewski wrote:
On 10/15/2016 02:00 PM, Matt Ranostay wrote:
On Fri, Oct 14, 2016 at 7:20 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
* Jacek Anaszewski <j.anaszewski@xxxxxxxxxxx> [161013 23:37]:
On 10/13/2016 04:20 PM, Matt Ranostay wrote:
On Thu, Oct 13, 2016 at 4:05 PM, Jacek Anaszewski
<j.anaszewski@xxxxxxxxxxx> wrote:
Why DT property? Is it somehow dependent on the board configuration?
How this period-scale value is calculated? Is it inferred empirically?
We empirically discovered and verified this with an logic analyzer on
multiple batches of this part.
Reason for the DT entry is we aren't 100% sure that it is always going
to be the same with different board revs.
Could be that parts clock acts differently with supply voltage. This
has been calculated by setting it an expected value, and measuring the
actual result with the logic analyzer.
I'd like to have DT maintainer's ack for this.
Cc Rob and Mark.
How about do this based on the compatible property instead? If there
are multiple manufacturers for this part and only a certain
parts have this issue we should have multiple compatible properties.
I could only find that NXP as the manufacturer of that part. It is
possible since the clock is internal to the chipset that the vdd of
2.5V is doing something undefined.
Then if it turns out all of them need this scaling there's no need
to update the binding.
Understandable.
Since at present we can't guarantee that all produced devices
are affected, then we should strive to avoid breaking any existing
users of the possible non-affected devices.
In view of that the addition of a new "compatible" proposed by Tony
seems most reasonable.
Still, DT maintainer's opinion is required.
Seems like a quirk of this board, so I think the added property is fine.
It could be existing users just didn't notice the rate being off. 30% is
probably not all that noticeable to the human eye.
Thanks for the feedback. I infer that you wouldn't mind if
I added your ack to this commit then?
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
