Thread (17 messages) 17 messages, 5 authors, 2015-03-02

Re: [PATCH v2 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver

From: Jonathan Richardson <hidden>
Date: 2015-02-11 18:45:40
Also in: linux-arm-kernel, linux-devicetree, lkml

Pinging maintainers... Am I ok to go ahead with the current rotation
implementation? I haven't heard anything further. Any feedback on naming
conventions from DT people?

Thanks!

On 15-01-15 11:51 AM, Jonathan Richardson wrote:
Hi Dmitry,

On 15-01-14 10:07 PM, Dmitry Torokhov wrote:
quoted
On Wed, Jan 14, 2015 at 09:44:39PM -0800, Scott Branden wrote:
quoted
On 15-01-14 05:02 PM, Dmitry Torokhov wrote:
quoted
Hi Jonathan,

On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
quoted
+	if (of_property_read_u32(np, "scanning_period", &val) >= 0) {
+		if (val < 1 || val > 256) {
+			dev_err(dev, "scanning_period must be [1-256]\n");
+			return -EINVAL;
+		}
+		priv->cfg_params.scanning_period = val;
+	}
+
+	if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
+		if (val < 0 || val > 255) {
+			dev_err(dev, "debounce_timeout must be [0-255]\n");
+			return -EINVAL;
+		}
+		priv->cfg_params.debounce_timeout = val;
+	}
+
+	if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
+		if (val < 0 || val > 11) {
+			dev_err(dev, "settling_timeout must be [0-11]\n");
+			return -EINVAL;
+		}
+		priv->cfg_params.settling_timeout = val;
+	}
+
+	if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
+		if (val < 0 || val > 255) {
+			dev_err(dev, "touch_timeout must be [0-255]\n");
+			return -EINVAL;
+		}
+		priv->cfg_params.touch_timeout = val;
+	}
+
+	if (of_property_read_u32(np, "average_data", &val) >= 0) {
+		if (val < 0 || val > 8) {
+			dev_err(dev, "average_data must be [0-8]\n");
+			return -EINVAL;
+		}
+		priv->cfg_params.average_data = val;
+	}
+
+	if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
+		if (val < 0 || val > 31) {
+			dev_err(dev, "fifo_threshold must be [0-31]\n");
+			return -EINVAL;
+		}
+		priv->cfg_params.fifo_threshold = val;
+	}
I think these are dveice specific and thus should have "brcm," prefix.
I'm confused as to why we need the brcm prefix?  Other device tree
bindings we have for other drivers do not need such prefix.
Properties that are not standard on the system (reg, interrupts,
clkocks, etc) or subsystem level customarily carry the vendor prefix so
that they do not clash with newly added global or subsystem properties.
quoted
 Is this
convention documented somewhere?
Not sure. I glanced through Documentation/devicetree and do not see it
spelled out. Device tree overlords, what say you?
Let me know. I haven't seen this before either. I will change the
entries to use dashes though instead of underscores but will wait until
these other issues are decided on before sending out another patch.
quoted
quoted
quoted
quoted
+
+	priv->ts_rotation = TS_ROTATION_0;
+	if (of_property_read_u32(np, "ts-rotation", &val) >= 0) {
+		priv->ts_rotation = val;
+		dev_dbg(dev, "ts rotation [%d] degrees\n",
+			90 * priv->ts_rotation);
+	}
This I am not quite sure about - if we want rotation or swap+invert. You
are CCed on another email (tsc2007) that talks about need of generic
touchscreen transforms in input core/of bindings.
Does such generic binding exist today?  If not, I would like to go
with this implementation and update to the new binding if/when it
exists?
Not yet but there several people interested. I think we have enough time
till 3.20 to hash it out properly.
I think the rotation is simpler personally. Everyone would understand
rotation refers to how it's oriented but I'm not sure everyone would
immediately know how it is wired. Let me know what is decided and I'll
make any changes required.

Thanks,
Jon

quoted
Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help