* Re: [PATCH 4/6] rpmsg: glink: Expose rpmsg name attr for glink
From: Stephen Boyd @ 2017-12-18 22:48 UTC (permalink / raw)
To: Chris Lew, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A
Cc: aneela-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513634534-22861-5-git-send-email-clew-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 12/18/2017 02:02 PM, Chris Lew wrote:
> Expose the name field as an attr so clients listening to uevents for
> rpmsg can identify the edge the events correspond to.
>
> Signed-off-by: Chris Lew <clew-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/rpmsg/qcom_glink_native.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
> index 786f2eca01f1..a897ccea3098 100644
> --- a/drivers/rpmsg/qcom_glink_native.c
> +++ b/drivers/rpmsg/qcom_glink_native.c
> @@ -1558,6 +1558,22 @@ static void qcom_glink_work(struct work_struct *work)
> }
> }
>
> +static ssize_t rpmsg_name_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> + struct qcom_glink_device *gdev = to_glink_device(rpdev);
> +
> + return snprintf(buf, RPMSG_NAME_SIZE, "%s\n", gdev->glink->name);
> +}
> +static DEVICE_ATTR_RO(rpmsg_name);
> +
> +static struct attribute *qcom_glink_attrs[] = {
const?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver
From: Tim Harvey @ 2017-12-18 22:21 UTC (permalink / raw)
To: Fabio Estevam
Cc: devicetree@vger.kernel.org, alsa-devel, Shawn Guo, linux-kernel,
Hans Verkuil, Mauro Carvalho Chehab, Philipp Zabel,
Steve Longerbeam, Hans Verkuil, linux-media
In-Reply-To: <CAOMZO5BUyF_E3aQByD2=4CxB-+DP189QAXMUA=AgOnq99wzmRg@mail.gmail.com>
On Sat, Dec 16, 2017 at 11:32 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Tim,
>
> On Thu, Nov 9, 2017 at 4:45 PM, Tim Harvey <tharvey@gateworks.com> wrote:
>
>> +static int tda1997x_set_power(struct tda1997x_state *state, bool on)
>> +{
>> + int ret = 0;
>> +
>> + if (on) {
>> + ret = regulator_bulk_enable(TDA1997X_NUM_SUPPLIES,
>> + state->supplies);
>> + msleep(300);
>
> Didn't you miss a 'return ret' here?
>
> Otherwise regulator_bulk_disable() will always be called below.
>
Fabio,
Yes thanks for catching that. I'll fix in the next revision.
Tim
^ permalink raw reply
* [PATCH 6/6] rpmsg: glink: Add get_rproc_name device op
From: Chris Lew @ 2017-12-18 22:02 UTC (permalink / raw)
To: bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A
Cc: aneela-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, clew-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1513634534-22861-1-git-send-email-clew-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Add support for clients to query the edge name for the glink device
their channel is registered for.
Signed-off-by: Chris Lew <clew-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/rpmsg/qcom_glink_native.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
index a897ccea3098..4748dea0748e 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1346,6 +1346,14 @@ static struct device_node *qcom_glink_match_channel(struct device_node *node,
return NULL;
}
+static const char *qcom_glink_get_rproc_name(struct rpmsg_device *rpdev)
+{
+ struct glink_channel *channel = to_glink_channel(rpdev->ept);
+ struct qcom_glink *glink = channel->glink;
+
+ return glink->name;
+}
+
static const struct rpmsg_device_ops glink_chrdev_ops = {
.create_ept = qcom_glink_create_ept,
};
@@ -1353,6 +1361,7 @@ static struct device_node *qcom_glink_match_channel(struct device_node *node,
static const struct rpmsg_device_ops glink_device_ops = {
.create_ept = qcom_glink_create_ept,
.announce_create = qcom_glink_announce_create,
+ .get_rproc_name = qcom_glink_get_rproc_name,
};
static const struct rpmsg_endpoint_ops glink_endpoint_ops = {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 5/6] rpmsg: Introduce rpmsg_get_rproc_name
From: Chris Lew @ 2017-12-18 22:02 UTC (permalink / raw)
To: bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A
Cc: aneela-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, clew-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1513634534-22861-1-git-send-email-clew-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Add support for client's to query the edge name their channel is
registered for. This is useful for clients who share the same channel
identifier across different remote procs.
Signed-off-by: Chris Lew <clew-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/rpmsg/rpmsg_core.c | 21 +++++++++++++++++++++
drivers/rpmsg/rpmsg_internal.h | 3 +++
include/linux/rpmsg.h | 10 ++++++++++
3 files changed, 34 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index dffa3aab7178..d6ebd678b089 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -78,6 +78,27 @@ struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
}
EXPORT_SYMBOL(rpmsg_create_ept);
+
+/**
+ * rpmsg_get_rproc_name() - Return the name of the rproc for this device
+ * @rpdev: rpmsg channel device
+ *
+ * Expose the rproc name for clients who open the same channel across different
+ * rprocs and need to differentiate during their probe.
+ *
+ * Returns char string on success and NULL on failure.
+ */
+const char *rpmsg_get_rproc_name(struct rpmsg_device *rpdev)
+{
+ if (WARN_ON(!rpdev))
+ return NULL;
+
+ if (!rpdev->ops->get_rproc_name)
+ return NULL;
+
+ return rpdev->ops->get_rproc_name(rpdev);
+}
+
/**
* rpmsg_destroy_ept() - destroy an existing rpmsg endpoint
* @ept: endpoing to destroy
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index 0cf9c7e2ee83..83a028b6883f 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -31,6 +31,7 @@
* @create_ept: create backend-specific endpoint, requried
* @announce_create: announce presence of new channel, optional
* @announce_destroy: announce destruction of channel, optional
+ * @get_rproc_name: return name of the rproc for this device, optional
*
* Indirection table for the operations that a rpmsg backend should implement.
* @announce_create and @announce_destroy are optional as the backend might
@@ -43,6 +44,8 @@ struct rpmsg_device_ops {
int (*announce_create)(struct rpmsg_device *ept);
int (*announce_destroy)(struct rpmsg_device *ept);
+
+ const char *(*get_rproc_name)(struct rpmsg_device *rpdev);
};
/**
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 10d6ae8bbb7d..167982dc5b4f 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -160,6 +160,8 @@ int rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst,
unsigned int rpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp,
poll_table *wait);
+const char *rpmsg_get_rproc_name(struct rpmsg_device *dev);
+
#else
static inline int register_rpmsg_device(struct rpmsg_device *dev)
@@ -267,6 +269,14 @@ static inline unsigned int rpmsg_poll(struct rpmsg_endpoint *ept,
return 0;
}
+static inline const char *rpmsg_get_rproc_name(struct rpmsg_device *rpdev)
+{
+ /* This shouldn't be possible */
+ WARN_ON(1);
+
+ return NULL;
+}
+
#endif /* IS_ENABLED(CONFIG_RPMSG) */
/* use a macro to avoid include chaining to get THIS_MODULE */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 4/6] rpmsg: glink: Expose rpmsg name attr for glink
From: Chris Lew @ 2017-12-18 22:02 UTC (permalink / raw)
To: bjorn.andersson, robh+dt, andy.gross, david.brown
Cc: aneela, linux-arm-msm, linux-remoteproc, linux-soc, devicetree,
linux-kernel, clew
In-Reply-To: <1513634534-22861-1-git-send-email-clew@codeaurora.org>
Expose the name field as an attr so clients listening to uevents for
rpmsg can identify the edge the events correspond to.
Signed-off-by: Chris Lew <clew@codeaurora.org>
---
drivers/rpmsg/qcom_glink_native.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
index 786f2eca01f1..a897ccea3098 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1558,6 +1558,22 @@ static void qcom_glink_work(struct work_struct *work)
}
}
+static ssize_t rpmsg_name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct rpmsg_device *rpdev = to_rpmsg_device(dev);
+ struct qcom_glink_device *gdev = to_glink_device(rpdev);
+
+ return snprintf(buf, RPMSG_NAME_SIZE, "%s\n", gdev->glink->name);
+}
+static DEVICE_ATTR_RO(rpmsg_name);
+
+static struct attribute *qcom_glink_attrs[] = {
+ &dev_attr_rpmsg_name.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(qcom_glink);
+
static void qcom_glink_device_release(struct device *dev)
{
struct rpmsg_device *rpdev = to_rpmsg_device(dev);
@@ -1597,6 +1613,8 @@ struct qcom_glink *qcom_glink_native_probe(struct device *dev,
return ERR_PTR(-ENOMEM);
glink->dev = dev;
+ glink->dev->groups = qcom_glink_groups;
+
glink->tx_pipe = tx;
glink->rx_pipe = rx;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 3/6] rpmsg: glink: Add support for rpmsg glink chrdev
From: Chris Lew @ 2017-12-18 22:02 UTC (permalink / raw)
To: bjorn.andersson, robh+dt, andy.gross, david.brown
Cc: aneela, linux-arm-msm, linux-remoteproc, linux-soc, devicetree,
linux-kernel, clew
In-Reply-To: <1513634534-22861-1-git-send-email-clew@codeaurora.org>
RPMSG provides a char device interface to userspace. Probe the rpmsg
chrdev channel to enable the rpmsg_ctrl device creation on glink
transports.
Signed-off-by: Chris Lew <clew@codeaurora.org>
---
drivers/rpmsg/qcom_glink_native.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
index 179132226dc2..786f2eca01f1 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -132,6 +132,13 @@ enum {
GLINK_STATE_CLOSING,
};
+struct qcom_glink_device {
+ struct rpmsg_device rpdev;
+ struct qcom_glink *glink;
+};
+
+#define to_glink_device(_x) container_of(_x, struct qcom_glink_device, rpdev)
+
/**
* struct glink_channel - internal representation of a channel
* @rpdev: rpdev reference, only used for primary endpoints
@@ -1339,6 +1346,10 @@ static struct device_node *qcom_glink_match_channel(struct device_node *node,
return NULL;
}
+static const struct rpmsg_device_ops glink_chrdev_ops = {
+ .create_ept = qcom_glink_create_ept,
+};
+
static const struct rpmsg_device_ops glink_device_ops = {
.create_ept = qcom_glink_create_ept,
.announce_create = qcom_glink_announce_create,
@@ -1547,6 +1558,30 @@ static void qcom_glink_work(struct work_struct *work)
}
}
+static void qcom_glink_device_release(struct device *dev)
+{
+ struct rpmsg_device *rpdev = to_rpmsg_device(dev);
+ struct qcom_glink_device *gdev = to_glink_device(rpdev);
+
+ kfree(gdev);
+}
+
+static int qcom_glink_create_chrdev(struct qcom_glink *glink)
+{
+ struct qcom_glink_device *gdev;
+
+ gdev = kzalloc(sizeof(*gdev), GFP_KERNEL);
+ if (!gdev)
+ return -ENOMEM;
+
+ gdev->glink = glink;
+ gdev->rpdev.ops = &glink_chrdev_ops;
+ gdev->rpdev.dev.parent = glink->dev;
+ gdev->rpdev.dev.release = qcom_glink_device_release;
+
+ return rpmsg_chrdev_register_device(&gdev->rpdev);
+}
+
struct qcom_glink *qcom_glink_native_probe(struct device *dev,
unsigned long features,
struct qcom_glink_pipe *rx,
@@ -1605,6 +1640,10 @@ struct qcom_glink *qcom_glink_native_probe(struct device *dev,
if (ret)
return ERR_PTR(ret);
+ ret = qcom_glink_create_chrdev(glink);
+ if (ret)
+ dev_err(glink->dev, "failed to register chrdev\n");
+
return glink;
}
EXPORT_SYMBOL_GPL(qcom_glink_native_probe);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 2/6] rpmsg: glink: Store edge name for glink device
From: Chris Lew @ 2017-12-18 22:02 UTC (permalink / raw)
To: bjorn.andersson, robh+dt, andy.gross, david.brown
Cc: aneela, linux-arm-msm, linux-remoteproc, linux-soc, devicetree,
linux-kernel, clew
In-Reply-To: <1513634534-22861-1-git-send-email-clew@codeaurora.org>
Channels may need to identify the edge their channel was probed for.
Store the edge name by reading the label property from device tree or
default to the node name.
Signed-off-by: Chris Lew <clew@codeaurora.org>
---
drivers/rpmsg/qcom_glink_native.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
index cd9d643433d3..179132226dc2 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -101,6 +101,8 @@ struct glink_core_rx_intent {
struct qcom_glink {
struct device *dev;
+ const char *name;
+
struct mbox_client mbox_client;
struct mbox_chan *mbox_chan;
@@ -1575,6 +1577,10 @@ struct qcom_glink *qcom_glink_native_probe(struct device *dev,
idr_init(&glink->lcids);
idr_init(&glink->rcids);
+ ret = of_property_read_string(dev->of_node, "label", &glink->name);
+ if (ret < 0)
+ glink->name = dev->of_node->name;
+
glink->mbox_client.dev = dev;
glink->mbox_chan = mbox_request_channel(&glink->mbox_client, 0);
if (IS_ERR(glink->mbox_chan)) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 1/6] dt-bindings: soc: qcom: Add label for GLINK bindings
From: Chris Lew @ 2017-12-18 22:02 UTC (permalink / raw)
To: bjorn.andersson, robh+dt, andy.gross, david.brown
Cc: aneela, linux-arm-msm, linux-remoteproc, linux-soc, devicetree,
linux-kernel, clew
In-Reply-To: <1513634534-22861-1-git-send-email-clew@codeaurora.org>
Add a label property to identify the edge this node represents.
Signed-off-by: Chris Lew <clew@codeaurora.org>
---
Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
index 9663cab52246..0b8cc533ca83 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
@@ -10,6 +10,11 @@ edge.
Value type: <stringlist>
Definition: must be "qcom,glink-rpm"
+- label:
+ Usage: optional
+ Value type: <string>
+ Definition: should specify the subsystem name this edge corresponds to.
+
- interrupts:
Usage: required
Value type: <prop-encoded-array>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 0/6] Add chrdev and name query support for GLINK
From: Chris Lew @ 2017-12-18 22:02 UTC (permalink / raw)
To: bjorn.andersson, robh+dt, andy.gross, david.brown
Cc: aneela, linux-arm-msm, linux-remoteproc, linux-soc, devicetree,
linux-kernel, clew
Add support for GLINK rpmsg transport to register a rpmsg chrdev to
create the rpmsg_ctrl nodes for userspace clients to open rpmsg epts.
Create a label property to identify the glink node with. This label
will be used as a name attr for GLINK devices. Expose this name through
a new API - rpmsg_get_rproc_name() for kernel clients.
Chris Lew (6):
dt-bindings: soc: qcom: Add label for GLINK bindings
rpmsg: glink: Store edge name for glink device
rpmsg: glink: Add support for rpmsg glink chrdev
rpmsg: glink: Expose rpmsg name attr for glink
rpmsg: Introduce rpmsg_get_rproc_name
rpmsg: glink: Add get_rproc_name device op
.../devicetree/bindings/soc/qcom/qcom,glink.txt | 5 ++
drivers/rpmsg/qcom_glink_native.c | 72 ++++++++++++++++++++++
drivers/rpmsg/rpmsg_core.c | 21 +++++++
drivers/rpmsg/rpmsg_internal.h | 3 +
include/linux/rpmsg.h | 10 +++
5 files changed, 111 insertions(+)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v3 3/3] DT: leds: Add Qualcomm Light Pulse Generator binding
From: Bjorn Andersson @ 2017-12-18 20:49 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Richard Purdie, Pavel Machek, Rob Herring, Mark Rutland,
linux-kernel, linux-leds, linux-arm-msm, devicetree, Fenglin Wu
In-Reply-To: <72744adc-6ad4-a51f-51c0-2f5bc2fac8bd@gmail.com>
On Wed 22 Nov 12:42 PST 2017, Jacek Anaszewski wrote:
> On 11/20/2017 10:45 PM, Bjorn Andersson wrote:
> > On Mon 20 Nov 12:35 PST 2017, Jacek Anaszewski wrote:
> >
> >> On 11/20/2017 08:58 PM, Bjorn Andersson wrote:
> >>> On Sun 19 Nov 13:35 PST 2017, Jacek Anaszewski wrote:
> >>>
> >>>> Hi Bjorn,
> >>>>
> >>>> Thanks for the update.
> >>>>
> >>>> On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
> >>>>> This adds the binding document describing the three hardware blocks
> >>>>> related to the Light Pulse Generator found in a wide range of Qualcomm
> >>>>> PMICs.
> >>>>>
> >>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> >>>>> ---
> >>>>>
> >>>>> Changes since v2:
> >>>>> - Squashed all things into one node
> >>>>> - Removed quirks from the binding, compatible implies number of channels, their
> >>>>> configuration etc.
> >>>>> - Binding describes LEDs connected as child nodes
> >>>>> - Support describing multi-channel LEDs
> >>>>> - Change style of the binding document, to match other LED bindings
> >>>>>
> >>>>> Changes since v1:
> >>>>> - Dropped custom pattern properties
> >>>>> - Renamed cell-index to qcom,lpg-channel to clarify its purpose
> >>>>>
> >>>>> .../devicetree/bindings/leds/leds-qcom-lpg.txt | 66 ++++++++++++++++++++++
> >>>>> 1 file changed, 66 insertions(+)
> >>>>> create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
> >>>>> new file mode 100644
> >>>>> index 000000000000..9cee6f9f543c
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
> >>>>> @@ -0,0 +1,66 @@
> >>>>> +Binding for Qualcomm Light Pulse Generator
> >>>>> +
> >>>>> +The Qualcomm Light Pulse Generator consists of three different hardware blocks;
> >>>>> +a ramp generator with lookup table, the light pulse generator and a three
> >>>>> +channel current sink. These blocks are found in a wide range of Qualcomm PMICs.
> >>>>> +
> >>>>> +Required properties:
> >>>>> +- compatible: one of:
> >>>>> + "qcom,pm8916-pwm",
> >>>>> + "qcom,pm8941-lpg",
> >>>>> + "qcom,pm8994-lpg",
> >>>>> + "qcom,pmi8994-lpg",
> >>>>> + "qcom,pmi8998-lpg",
> >>>>> +
> >>>>> +Optional properties:
> >>>>> +- qcom,power-source: power-source used to drive the output, as defined in the
> >>>>> + datasheet. Should be specified if the TRILED block is
> >>>>> + present
> >>>>
> >>>> Range of possible values is missing here.
> >>>>
> >>>
> >>> There seems to be a 4-way mux in all variants, but the wiring is
> >>> different in the different products. E.g. in pm8941 1 represents VPH_PWR
> >>> while in pmi8994 this is pulled from a dedicated pin named VIN_RGB.
> >>>
> >>> Would you like me to list the 4 options for each compatible?
> >>
> >> Could you please explain why user would prefer one power source
> >> over the other? Is it that they have different max current limit?
> >>
> >
> > The mux in pm8941 is connected to ground (0V), vph_pwr (3.6V), internal
> > 5V and min(5V, charger). In pmi8994 it's ground, vdd_rgb (a dedicated
> > pin) and 4.2V. PMI8998 is a slight variation of PMI8994 and I expect
> > there to be more variants.
> >
> > So it's different voltage level and, potentially, current limit.
>
> I'd replace this property with led-max-microamp
> (see Documentation/devicetree/bindings/leds/common.txt) and let
> the driver to decide which power source to choose, basing on that limit.
>
Unfortunately I don't think specifying this in uA is possible, at least
some of these inputs does not have a knows (at least not platform
defined) current limit.
Like in the case on PM8941, the knobs this property tweaks is: "should
we output 3.6V or 5V" and both values depend on external power-supplies.
For most cases specifying this as led-microvolt would be possible, but
then there are the levels that are min(5V, charger).
One thing we've done in some other drivers with similar "enum" like
types is to provide an dt-bindings include file with these constants.
This makes the dts self documented and doesn't require additional
translation of the values.
> > [..]
> >> One more question regarding TRILED - in your design it will be
> >> exposed as a single LED class device with one brightness file,
> >> right? Does it mean that all three LEDs will be applied the
> >> same brightness after writing it to the sysfs file?
> >>
> >
> > Correct, each LED described in DT will become one LED and can have more
> > than one (any number of) physical channel associated. The current
> > implementation applies the same brightness (and pattern) to all channels
> > associated with a LED.
>
> The rgb DT node name would be a bit misleading in this case, since
> RGB usually implies the possibility of having different intensity
> of each color.
>
In the sense of the devicetree this is exactly what it describes, the
fact that we haven't figured out a way to implement this is, in my view,
a separate topic.
> > The open question is still how to pass a color from user space, the
> > brightness_set and pattern_set would need to be modified to map a list
> > of brightnesses to the individual channels or to adapt the brightness by
> > some color-modifier(?).
>
> Pavel made and attempt of reworking Heiner Kallweit's HSV approach
> few months ago [0]. You can take a look and share your opinion
> or even continue this effort.
>
I did not consider using HSV to get around the problem of everything
operating on "brightness", but this seems like a quite nice solution.
In the case of lpg_brightness_set() this would map nicely into the case
where a LED is either a single channel or three channels, and until we
land those patches the driver would just implement H = S = 0.
And for the pattern setting, we can retain the proposed interface of
pattern being a sequence of brightness/delay values and then map this in
the driver as we apply the patterns.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Baruch Siach @ 2017-12-18 20:35 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171218143643.7714-5-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Miquèl,
On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal wrote:
> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
>
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
[...]
> + /*
> + * Legacy DT bindings only described "control1" register (also referred
> + * as "control MSB" on old documentation). New bindings cover
> + * "control0/control LSB" and "control1/control MSB" registers within
> + * the same resource, which is then of size 8 instead of 4.
> + */
> + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> + /* ->control0 unavailable in this configuration */
> + priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> + } else {
> + priv->control0 = control + CONTROL0_OFFSET;
> + priv->control1 = control + CONTROL1_OFFSET;
> + }
The needs_control0 field that you mentioned in the cover page is missing here.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 01/12] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Baruch Siach @ 2017-12-18 20:33 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171218143643.7714-2-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Miquèl,
On Mon, Dec 18, 2017 at 03:36:32PM +0100, Miquel Raynal wrote:
> From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
>
> Add compatible strings for AP806 and CP110 that are part of the Armada
> 8k/7k line of SoCs.
>
> Add a note on the differences in the size of the control area in
> different bindings. This is an existing difference between the Armada
> 375 binding and the other boards already supported. The new AP806 and
> CP110 bindings are similar to the existing Armada 375 in this regard.
>
> Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: reword, additional details]
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/thermal/armada-thermal.txt | 24 +++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> index 24aacf8948c5..9b7b2c03cc6f 100644
> --- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> @@ -7,17 +7,31 @@ Required properties:
> marvell,armada375-thermal
> marvell,armada380-thermal
> marvell,armadaxp-thermal
> + marvell,armada-ap806-thermal
> + marvell,armada-cp110-thermal
>
> - reg: Device's register space.
> Two entries are expected, see the examples below.
> - The first one is required for the sensor register;
> - the second one is required for the control register
> - to be used for sensor initialization (a.k.a. calibration).
> + The first one points to the status register (4B).
> + The second one points to the control registers (8B).
> + Note: with legacy bindings, the second entry pointed
> + only to the so called "control MSB" ("control 1"), was
> + 4B wide and did not let the possibility to reach the
> + "control LSB" ("control 0") register. This is only
> + allowed for compatibility reasons in Armada
> + 370/375/38x/XP DT nodes.
"allowed" is not the right term, IMO. Legacy compatibles MUST point to the MSB
control register to preserve compatibility with existing DTs.
The original patch had a list of legacy and non-legacy compatibles. I think we
need to keep them.
baruch
> -Example:
> +Examples:
>
> + /* Legacy bindings */
> thermal@d0018300 {
> compatible = "marvell,armada370-thermal";
> - reg = <0xd0018300 0x4
> + reg = <0xd0018300 0x4
> 0xd0018304 0x4>;
> };
> +
> + ap_thermal: thermal@6f8084 {
> + compatible = "marvell,armada-ap806-thermal";
> + reg = <0x6f808C 0x4>,
> + <0x6f8084 0x8>;
> + };
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Arnd Bergmann @ 2017-12-18 20:24 UTC (permalink / raw)
To: Ludovic Barre
Cc: Russell King, Rob Herring, Linus Walleij, Maxime Coquelin,
Alexandre Torgue, Gerald Baeza, Linux ARM,
Linux Kernel Mailing List, DTML
In-Reply-To: <1513610272-7824-4-git-send-email-ludovic.Barre@st.com>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> This patch prepares the STM32 machine for the integration of Cortex-A
> based microprocessor (MPU), on top of the existing Cortex-M
> microcontroller family (MCU). Since both MCUs and MPUs are sharing
> common hardware blocks we can keep using ARCH_STM32 flag for most of
> them. If a hardware block is specific to one family we can use either
> ARM_SINGLE_ARMV7M or ARCH_MULTI_V7 flag.
>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Looks good overall. Two more small comments:
>
> +if ARCH_STM32
> +
> config MACH_STM32F429
> - bool "STMicrolectronics STM32F429"
> - depends on ARCH_STM32
> + bool "STMicroelectronics STM32F429"
> + depends on ARM_SINGLE_ARMV7M
> default y
Instead of the explicit dependency for each board, I'd leave the surrounding
'if ARM_SINGLE_ARMV7M'. I think you had in v1.
> diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
> index bd0b7b5..5940af1 100644
> --- a/arch/arm/mach-stm32/Makefile
> +++ b/arch/arm/mach-stm32/Makefile
> @@ -1 +1 @@
> -obj-y += board-dt.o
> +obj-$(CONFIG_ARM_SINGLE_ARMV7M) += board-mcu-dt.o
> diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-mcu-dt.c
> similarity index 100%
> rename from arch/arm/mach-stm32/board-dt.c
> rename to arch/arm/mach-stm32/board-mcu-dt.c
Why the rename? I don't expect the new machines to have any notable
contents in a board file, if any at all, so just use one file for both.
I see the board-dt.c file refers to armv7m_restart, we can either put
that in an #ifdef, or find a way to make it the default for all armv7-m
platforms that don't provide any other restart method.
Arnd
^ permalink raw reply
* [PATCH v5 6/6] leds: lp8860: Various fixes to align with LED framework
From: Dan Murphy @ 2017-12-18 20:23 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy
In-Reply-To: <20171218202307.4913-1-dmurphy-l0cyMroinI0@public.gmane.org>
Update the driver to conform with the LED framework.
Use devm_led_classdev_register
Destroy mutex on exit
Remove dependency on CONFIG_OF in the driver and move
to the Kconfig
Update the MODULE_LICENSE to GPL v2
Remove setting of MAX brightness as the LED framework
does this.
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
---
v5 - No changes
v4 - No changes
v3 - no changes - https://patchwork.kernel.org/patch/10093747/
v2 - no changes
drivers/leds/Kconfig | 2 +-
drivers/leds/leds-lp8860.c | 13 +++++--------
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 318a28fd58fe..ac4d9d8bf96b 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -347,7 +347,7 @@ config LEDS_LP8788
config LEDS_LP8860
tristate "LED support for the TI LP8860 4 channel LED driver"
- depends on LEDS_CLASS && I2C
+ depends on LEDS_CLASS && I2C && OF
select REGMAP_I2C
help
If you say yes here you get support for the TI LP8860 4 channel
diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
index bb1d7bbc928c..c7716f774431 100644
--- a/drivers/leds/leds-lp8860.c
+++ b/drivers/leds/leds-lp8860.c
@@ -399,7 +399,6 @@ static int lp8860_probe(struct i2c_client *client,
led->client = client;
led->led_dev.name = led->label;
- led->led_dev.max_brightness = LED_FULL;
led->led_dev.brightness_set_blocking = lp8860_brightness_set;
mutex_init(&led->lock);
@@ -426,7 +425,7 @@ static int lp8860_probe(struct i2c_client *client,
if (ret)
return ret;
- ret = led_classdev_register(&client->dev, &led->led_dev);
+ ret = devm_led_classdev_register(&client->dev, &led->led_dev);
if (ret) {
dev_err(&client->dev, "led register err: %d\n", ret);
return ret;
@@ -440,8 +439,6 @@ static int lp8860_remove(struct i2c_client *client)
struct lp8860_led *led = i2c_get_clientdata(client);
int ret;
- led_classdev_unregister(&led->led_dev);
-
if (led->enable_gpio)
gpiod_direction_output(led->enable_gpio, 0);
@@ -452,6 +449,8 @@ static int lp8860_remove(struct i2c_client *client)
"Failed to disable regulator\n");
}
+ mutex_destroy(&led->lock);
+
return 0;
}
@@ -461,18 +460,16 @@ static const struct i2c_device_id lp8860_id[] = {
};
MODULE_DEVICE_TABLE(i2c, lp8860_id);
-#ifdef CONFIG_OF
static const struct of_device_id of_lp8860_leds_match[] = {
{ .compatible = "ti,lp8860", },
{},
};
MODULE_DEVICE_TABLE(of, of_lp8860_leds_match);
-#endif
static struct i2c_driver lp8860_driver = {
.driver = {
.name = "lp8860",
- .of_match_table = of_match_ptr(of_lp8860_leds_match),
+ .of_match_table = of_lp8860_leds_match,
},
.probe = lp8860_probe,
.remove = lp8860_remove,
@@ -482,4 +479,4 @@ module_i2c_driver(lp8860_driver);
MODULE_DESCRIPTION("Texas Instruments LP8860 LED driver");
MODULE_AUTHOR("Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
--
2.15.0.124.g7668cbc60
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v5 5/6] leds: lp8860: Add DT parsing to retrieve the trigger node
From: Dan Murphy @ 2017-12-18 20:23 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
In-Reply-To: <20171218202307.4913-1-dmurphy@ti.com>
Add the ability to parse the DT and set the default
trigger mode for the LED.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v5 - No changes
v4 - No changes
v3 - no changes - https://patchwork.kernel.org/patch/10093751/
v2 - no changes
drivers/leds/leds-lp8860.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
index 46578fbc36be..bb1d7bbc928c 100644
--- a/drivers/leds/leds-lp8860.c
+++ b/drivers/leds/leds-lp8860.c
@@ -372,6 +372,10 @@ static int lp8860_probe(struct i2c_client *client,
return -ENOMEM;
for_each_available_child_of_node(np, child_node) {
+ led->led_dev.default_trigger = of_get_property(child_node,
+ "linux,default-trigger",
+ NULL);
+
ret = of_property_read_string(child_node, "label", &name);
if (!ret)
snprintf(led->label, sizeof(led->label), "%s:%s",
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* [PATCH v5 4/6] dt: bindings: lp8860: Add trigger binding to the lp8860
From: Dan Murphy @ 2017-12-18 20:23 UTC (permalink / raw)
To: robh+dt, mark.rutland, rpurdie, jacek.anaszewski, pavel
Cc: devicetree, linux-kernel, linux-leds, Dan Murphy
In-Reply-To: <20171218202307.4913-1-dmurphy@ti.com>
Add a default trigger optional node to the child node.
This will allow the driver to set the trigger for a backlight.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v5 - No changes
v4 - No changes
v3 - Removed optional and rebased - https://patchwork.kernel.org/patch/10093755/
v2 - Moved binding changes to first patch in the series.
Documentation/devicetree/bindings/leds/leds-lp8860.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
index 77ddd22c20dc..5f0e892ad759 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
@@ -21,6 +21,8 @@ Required child properties:
Optional child properties:
- label : see Documentation/devicetree/bindings/leds/common.txt
+ - linux,default-trigger :
+ see Documentation/devicetree/bindings/leds/common.txt
Example:
@@ -35,6 +37,7 @@ led-controller@2d {
led@0 {
reg = <0>;
label = "white:backlight";
+ linux,default-trigger = "backlight";
};
}
--
2.15.0.124.g7668cbc60
^ permalink raw reply related
* [PATCH v5 3/6] leds: lp8860: Update the dt parsing for LED labeling
From: Dan Murphy @ 2017-12-18 20:23 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy
In-Reply-To: <20171218202307.4913-1-dmurphy-l0cyMroinI0@public.gmane.org>
Update the DT parsing for the label node so that
the label is retrieved from the device child as
opposed to being part of the parent.
This will align this driver with the LED
binding documentation
Documentation/devicetree/bindings/leds/common.txt
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
---
v5 - no changes
v4 - Fix checkpatch warning for code indentation - https://patchwork.kernel.org/patch/10108157/
v3 - Changed the label generation to pull the name from the i2c device id
as opposed to pulling the id from the parent dt node since that will just be
led-controller - https://patchwork.kernel.org/patch/10093753/
v2 - no changes
drivers/leds/leds-lp8860.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
index 3e70775a2d54..46578fbc36be 100644
--- a/drivers/leds/leds-lp8860.c
+++ b/drivers/leds/leds-lp8860.c
@@ -22,6 +22,7 @@
#include <linux/of_gpio.h>
#include <linux/gpio/consumer.h>
#include <linux/slab.h>
+#include <uapi/linux/uleds.h>
#define LP8860_DISP_CL1_BRT_MSB 0x00
#define LP8860_DISP_CL1_BRT_LSB 0x01
@@ -86,8 +87,6 @@
#define LP8860_CLEAR_FAULTS 0x01
-#define LP8860_DISP_LED_NAME "display_cluster"
-
/**
* struct lp8860_led -
* @lock - Lock for reading/writing the device
@@ -107,7 +106,7 @@ struct lp8860_led {
struct regmap *eeprom_regmap;
struct gpio_desc *enable_gpio;
struct regulator *regulator;
- const char *label;
+ char label[LED_MAX_NAME_SIZE];
};
struct lp8860_eeprom_reg {
@@ -365,19 +364,21 @@ static int lp8860_probe(struct i2c_client *client,
int ret;
struct lp8860_led *led;
struct device_node *np = client->dev.of_node;
+ struct device_node *child_node;
+ const char *name;
led = devm_kzalloc(&client->dev, sizeof(*led), GFP_KERNEL);
if (!led)
return -ENOMEM;
- led->label = LP8860_DISP_LED_NAME;
-
- if (client->dev.of_node) {
- ret = of_property_read_string(np, "label", &led->label);
- if (ret) {
- dev_err(&client->dev, "Missing label in dt\n");
- return -EINVAL;
- }
+ for_each_available_child_of_node(np, child_node) {
+ ret = of_property_read_string(child_node, "label", &name);
+ if (!ret)
+ snprintf(led->label, sizeof(led->label), "%s:%s",
+ id->name, name);
+ else
+ snprintf(led->label, sizeof(led->label),
+ "%s::display_cluster", id->name);
}
led->enable_gpio = devm_gpiod_get_optional(&client->dev,
--
2.15.0.124.g7668cbc60
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v5 2/6] dt: bindings: lp8860: Update DT label binding
From: Dan Murphy @ 2017-12-18 20:23 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy
In-Reply-To: <20171218202307.4913-1-dmurphy-l0cyMroinI0@public.gmane.org>
Update the lp8860 label binding to the LED
standard as documented in
Documentation/devicetree/bindings/leds/common.txt
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
---
v5 - Renamed label to just white:backlight - https://patchwork.kernel.org/patch/10108361
Comment was made on patch 4 https://patchwork.kernel.org/patch/10108351/
v4 - No changes
v3 - Added address and size cells, updated label with color and inserted spaces
around the reg node - https://patchwork.kernel.org/patch/10093749/
v2 - Added reg to child node and made it required
Documentation/devicetree/bindings/leds/leds-lp8860.txt | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
index b9d09acbaa73..77ddd22c20dc 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
@@ -9,20 +9,33 @@ Required properties:
- compatible :
"ti,lp8860"
- reg : I2C slave address
- - label : Used for naming LEDs
+ - #address-cells : 1
+ - #size-cells : 0
Optional properties:
- enable-gpios : gpio pin to enable (active high)/disable the device.
- vled-supply : LED supply
+Required child properties:
+ - reg : 0
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+
Example:
led-controller@2d {
compatible = "ti,lp8860";
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0x2d>;
- label = "display_cluster";
enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
vled-supply = <&vbatt>;
+
+ led@0 {
+ reg = <0>;
+ label = "white:backlight";
+ };
}
For more product information please see the link below:
--
2.15.0.124.g7668cbc60
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v5 1/6] dt: bindings: lp8860: Update bindings for lp8860
From: Dan Murphy @ 2017-12-18 20:23 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Dan Murphy
Update the lp8860 bindings to fix various issues
found. Rename enable-gpio to enable-gpios,
update the node name to the device name and
indent the node example.
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
---
v5 - Update commit message to remove address and size cells - https://patchwork.kernel.org/patch/10108357/
v4 - No changes
v3 - Indicatd enable-gpios is active high, moved address and size cells to child
node patch and updated parent DT node name - https://patchwork.kernel.org/patch/10093745/
v2 - New patch
Documentation/devicetree/bindings/leds/leds-lp8860.txt | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
index aad38dd94d4b..b9d09acbaa73 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
@@ -6,22 +6,22 @@ current sinks that can be controlled by a PWM input
signal, a SPI/I2C master, or both.
Required properties:
- - compatible:
+ - compatible :
"ti,lp8860"
- - reg - I2C slave address
- - label - Used for naming LEDs
+ - reg : I2C slave address
+ - label : Used for naming LEDs
Optional properties:
- - enable-gpio - gpio pin to enable/disable the device.
- - supply - "vled" - LED supply
+ - enable-gpios : gpio pin to enable (active high)/disable the device.
+ - vled-supply : LED supply
Example:
-leds: leds@6 {
+led-controller@2d {
compatible = "ti,lp8860";
reg = <0x2d>;
label = "display_cluster";
- enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
vled-supply = <&vbatt>;
}
--
2.15.0.124.g7668cbc60
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
From: Daniel Thompson @ 2017-12-18 20:21 UTC (permalink / raw)
To: Doug Anderson
Cc: Enric Balletbo Serra, Enric Balletbo i Serra, Jingoo Han,
Richard Purdie, Jacek Anaszewski, Pavel Machek, Rob Herring,
Brian Norris, Guenter Roeck, Lee Jones, Alexandru Stan,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel
In-Reply-To: <CAD=FV=VEakDGqfEkOZbuiq=FvUw46=6u9rTOgTk5FyJ9_2Rh4A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Dec 18, 2017 at 08:46:09AM -0800, Doug Anderson wrote:
> Hi,
>
> On Mon, Dec 18, 2017 at 5:31 AM, Daniel Thompson
> <daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > I think two different values on the userspace side should always map to
> > different values on the kernel side.
>
> This is what I thought originally, but I believe I've convinced myself
> that this contradicts other goals and therefore needs to be relaxed.
> Specifically:
>
> Goal #1: A linear adjustment in the number exposed to userspace should
> result in a linear increase in human perceived brightness.
>
> Goal #2: Don't needlessly throw away precision available to the
> hardware. For instance, if the hardware only supports 64, 128 or 256
> levels, it seems like a worthy goal to make sure that userspace can
> access each of these brightness levels.
>
>
> So if we accept that #1 and #2 are goals,
I'm not sure that I accept goal #1 for highly constrained hardware that
is physically capable only of a very few steps.
I think adopting Goal #1 favours the slider use-case too much over the
hot-key use case. If you linearise a tiny space then the hot-key risks
doing nothing then pressed.
It's not that I don't think this is a real problem but I think it is
one that must be solved in the ABI (e.g. by communicating the typical
curve to userspace and revealing true hardware steps).
> the only solution is to
> expose a larger "virtual" space and have more than one user-exposed
> value map to the same actual brightness. As a very simple example,
> let's say we have a backlight that allows 8 levels:
>
> 0 = black
> 1 = 20% user brightness
> 2 = 40% user brightness
> 3 = 60% user brightness
> 4 = 75% user brightness
> 5 = 85% user brightness
> 6 = 90% user brightness
> 7 = 95% user brightness
> 8 = 100% user brightness
Note that these patches are for the PWM backlight; these steps seem
unlikely even for an 8-bit PWM.
That leads us to a difficult question. When presented with a low-bit PWM
then are automatic curves the right tool? With such low steps we
probably need to compromise linearity to some extent (and maybe the DT
author may be forced to tune for slider versus hotkey depending on what
our form-factor is).
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board
From: Arnd Bergmann @ 2017-12-18 20:20 UTC (permalink / raw)
To: Ludovic Barre
Cc: Russell King, Rob Herring, Linus Walleij, Maxime Coquelin,
Alexandre Torgue, Gerald Baeza, Linux ARM,
Linux Kernel Mailing List, DTML
In-Reply-To: <1513610272-7824-10-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre-qxv4g6HH51o@public.gmane.org> wrote:
=
> +
> +/ {
> + model = "STMicroelectronics STM32MP157C eval daughter";
> + compatible = "st,stm32mp157c-ed1", "st,stm32mp157";
> +
> + chosen {
> + bootargs = "earlyprintk console=ttySTM3,115200 root=/dev/ram";
> + stdout-path = "serial3:115200n8";
> + };
I'd remove the bootargs here and let the boot loader take care of
that, in particular
since all three arguments are rather old-school: earlycon is preferred over
earlyprintk, console= should not be needed if you set stdout-path, and
/dev/ram is obsoleted by initramfs.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection
From: Boris Brezillon @ 2017-12-18 19:46 UTC (permalink / raw)
To: Mark Rutland
Cc: Alexandre Belloni, devicetree-u79uwXL29TY76Z2rM5mHXA,
marc.zyngier-5wv7dgnIgG8, Daniel Lezcano,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Thomas Gleixner,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171215113242.skmh5nzr7wqdmvnw-agMKViyK24J5pKCnmE3YQBJ8xKzm50AiAL8bYrjMMd8@public.gmane.org>
On Fri, 15 Dec 2017 11:32:42 +0000
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi,
>
> On Wed, Dec 13, 2017 at 07:53:11PM +0100, Alexandre Belloni wrote:
> > The clocksource and clockevent timer are probed early in the boot process.
> > At that time it is difficult for linux to know whether a particular timer
> > can be used as the clocksource or the clockevent or by another driver,
> > especially when they are all identical or have similar features.
>
> I think that to solve this problem, we need to stop treating
> clocksources and clockevent devices as completely separate device types,
> and instead treat them as particular cases of a more general clock
> device.
>
> That way, a driver can register a single device, with flags saying
> whether it is:
>
> * a clocksource only
> * a clockevent device only
> * both a clocksource and clockevent device
> * both, but mutually exclusive at runtime
>
> ... and thus drivers don't have to make an impossible decision up-front
> as to how the device should be used.
>
> As more devices get registered, the core timekeeping code can improve on
> its choices and re-assign devices.
I'm coming back to the Atmel TCB use case. Say you have 2 'timers' one
has been assigned 2 channels (a channel is what I call TC in my
previous explanation) and the other one only one channel. Both timers
are capable of acting as a clockevent or a clocksource device (not
both at the same time). Now, the question is, how do you decide which
one is assigned the clocksource role and which one is assigned the
clkevent role. Do you plan to pass the expected clocksource/clkevent
properties (precision, max value, wraparound period, ...) through the
device tree so that the framework can decide which timer is best suited
for a specific feature?
>
> That doesn't solve the case where a clock device may use resources we
> want for something else, but I think we can solve that separately.
>
> Thanks,
> Mark.
>
> > Until now, multiple strategies have been used to solve that:
> > - use Kconfig option as MXC_USE_EPIT or ATMEL_TCB_CLKSRC_BLOCK
> > - use a kernel parameter as the "clocksource" early_param in mach-omap2
> > - registering the first seen timer as a clockevent and the second one as
> > a clocksource as in rk_timer_init or dw_apb_timer_init
> >
> > Add a linux,clocksource and a linux,clockevent node in chosen with a timer
> > property pointing to the timer to use. Other properties, like the targeted
> > precision may be added later.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/chosen.txt | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> > index e3b13ea7d2ae..c7ee3ecb5276 100644
> > --- a/Documentation/devicetree/bindings/chosen.txt
> > +++ b/Documentation/devicetree/bindings/chosen.txt
> > @@ -120,3 +120,23 @@ e.g.
> > While this property does not represent a real hardware, the address
> > and the size are expressed in #address-cells and #size-cells,
> > respectively, of the root node.
> > +
> > +linux,clocksource and linux,clockevent
> > +--------------------------------------
> > +
> > +Those nodes have a timer property. This property is a phandle to the timer to be
> > +chosen as the clocksource or clockevent. This is only useful when the platform
> > +has multiple identical timers and it is not possible to let linux make the
> > +correct choice.
> > +
> > +/ {
> > + chosen {
> > + linux,clocksource {
> > + timer = <&timer0>;
> > + };
> > +
> > + linux,clockevent {
> > + timer = <&timer1>;
> > + };
> > + };
> > +};
> > --
> > 2.15.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: opp: Introduce ti-opp-supply bindings
From: Dave Gerlach @ 2017-12-18 19:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, Rob Herring, linux-arm-kernel,
Linux OMAP Mailing List, Linux PM, devicetree@vger.kernel.org,
Tony Lindgren, Nishanth Menon
In-Reply-To: <CAJZ5v0iRg0Sncqt4s3M5+E0h=HJiEDQ4vnB3=6mFhECCv_Lnng@mail.gmail.com>
Rafael,
On 12/16/2017 04:52 AM, Rafael J. Wysocki wrote:
> On Fri, Dec 15, 2017 at 3:29 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Fri, Dec 15, 2017 at 5:25 AM, Dave Gerlach <d-gerlach@ti.com> wrote:
>>> Document the devicetree bindings that describe Texas Instruments
>>> opp-supply which allow a platform to describe multiple regulators and
>>> additional information, such as registers containing data needed to
>>> program aforementioned regulators.
>>>
>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>
>> I need an ACK from Rob on this one.
>
> Actually, how this (and the next patch) is related to the [1-2/4]?
>
The main goal of this series is to add support for scaling the multiple
regulators needed for the CPU on these TI platforms. The OPP core supports
multiple regulators but only to the point that it can associate a list of
regulators to a device. It still by default only scales the normal vdd regulator
when doing a rate transition. Because of this, we must define our own method of
doing rate transitions to take the references to our regulators held in the OPP
core and scale them in the proper sequence depending on what the platform needs.
So to describe the purpose of each patch and their relation to each other:
Patch 1: We must be able to defer the ti-cpufreq driver now that we look for
regulators during probe as they likely won't be ready when we probe.
Patch 2: Tell the OPP core about regulators needed for TI CPUFreq operation
using the OPP core. This doesn't actually do anything besides place them in a
list at this point because the OPP core can't know how TI platforms needs them
scaled in relation to each other. Placing the regulator definition in ti-cpufreq
driver ensures they are registered with opp core before cpufreq-dt probes (which
is triggered at the end of ti-cpufreq probe) and actually makes the opp core get
the regulators.
Patch 3: Binding doc for patch 4 driver.
Patch 4: TI OPP supply driver which understands how to actually make use of the
two regulators that the OPP core now has a reference to. This overrides the
standard opp_set_rate function to let us scale frequency and voltage as needed
for TI platforms.
Regards,
Dave
^ permalink raw reply
* [PATCH v3 1/1] eeprom: at24: convert magic numbers to structs.
From: Sven Van Asbroeck @ 2017-12-18 18:30 UTC (permalink / raw)
To: svendev, wsa, brgl, nsekhar, sakari.ailus, javier,
divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c
In-Reply-To: <1513621828-6641-1-git-send-email-svendev@arcx.com>
Fundamental properties such as capacity and page size differ
among at24-type chips. But these chips do not have an id register,
so this can't be discovered at runtime.
Traditionally, at24-type eeprom properties were determined in two ways:
- by passing a 'struct at24_platform_data' via platform_data, or
- by naming the chip type in the devicetree, which passes a
'magic number' to probe(), which is then converted to
a 'struct at24_platform_data'.
Recently a bug was discovered because the magic number rounds down
all chip sizes to the lowest power of two. This was addressed by
a work-around, with the wish that magic numbers should over time
be converted to structs.
commit 5478e478eee3 ("eeprom: at24: correctly set the size for at24mac402")
This patch replaces the magic numbers with 'struct at24_chip_data'.
Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
---
drivers/misc/eeprom/at24.c | 219 ++++++++++++++++++++-------------------------
1 file changed, 99 insertions(+), 120 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index b44a3d2b..afa0f93 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -105,16 +105,6 @@ struct at24_data {
module_param_named(write_timeout, at24_write_timeout, uint, 0);
MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 25)");
-#define AT24_SIZE_BYTELEN 5
-#define AT24_SIZE_FLAGS 8
-
-#define AT24_BITMASK(x) (BIT(x) - 1)
-
-/* create non-zero magic value for given eeprom parameters */
-#define AT24_DEVICE_MAGIC(_len, _flags) \
- ((1 << AT24_SIZE_FLAGS | (_flags)) \
- << AT24_SIZE_BYTELEN | ilog2(_len))
-
/*
* Both reads and writes fail if the previous write didn't complete yet. This
* macro loops a few times waiting at least long enough for one entire page
@@ -132,113 +122,108 @@ struct at24_data {
op_time ? time_before(op_time, tout) : true; \
usleep_range(1000, 1500), op_time = jiffies)
+struct at24_chip_data {
+ /*
+ * these fields mirror their equivalents in
+ * struct at24_platform_data
+ */
+ u32 byte_len;
+ u8 flags;
+};
+
+#define AT24_CHIP_DATA(_name, _len, _flags) \
+ static const struct at24_chip_data _name = { \
+ .byte_len = _len, .flags = _flags, \
+ }
+
+/* needs 8 addresses as A0-A2 are ignored */
+AT24_CHIP_DATA(at24_data_24c00, 128 / 8, AT24_FLAG_TAKE8ADDR);
+/* old variants can't be handled with this generic entry! */
+AT24_CHIP_DATA(at24_data_24c01, 1024 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs01, 16, AT24_FLAG_SERIAL |
+ AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c02, 2048 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs02, 16, AT24_FLAG_SERIAL |
+ AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24mac402, 48 / 8, AT24_FLAG_MAC |
+ AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24mac602, 64 / 8, AT24_FLAG_MAC |
+ AT24_FLAG_READONLY);
+/* spd is a 24c02 in memory DIMMs */
+AT24_CHIP_DATA(at24_data_spd, 2048 / 8, AT24_FLAG_READONLY |
+ AT24_FLAG_IRUGO);
+AT24_CHIP_DATA(at24_data_24c04, 4096 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs04, 16, AT24_FLAG_SERIAL |
+ AT24_FLAG_READONLY);
+/* 24rf08 quirk is handled at i2c-core */
+AT24_CHIP_DATA(at24_data_24c08, 8192 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs08, 16, AT24_FLAG_SERIAL |
+ AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c16, 16384 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs16, 16, AT24_FLAG_SERIAL |
+ AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c32, 32768 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24cs32, 16, AT24_FLAG_ADDR16 |
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c64, 65536 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24cs64, 16, AT24_FLAG_ADDR16 |
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c128, 131072 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24c256, 262144 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24c512, 524288 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24c1024, 1048576 / 8, AT24_FLAG_ADDR16);
+/* identical to 24c08 ? */
+AT24_CHIP_DATA(at24_data_INT3499, 8192 / 8, 0);
+
static const struct i2c_device_id at24_ids[] = {
- /* needs 8 addresses as A0-A2 are ignored */
- { "24c00", AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR) },
- /* old variants can't be handled with this generic entry! */
- { "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
- { "24cs01", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) },
- { "24cs02", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24mac402", AT24_DEVICE_MAGIC(48 / 8,
- AT24_FLAG_MAC | AT24_FLAG_READONLY) },
- { "24mac602", AT24_DEVICE_MAGIC(64 / 8,
- AT24_FLAG_MAC | AT24_FLAG_READONLY) },
- /* spd is a 24c02 in memory DIMMs */
- { "spd", AT24_DEVICE_MAGIC(2048 / 8,
- AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
- { "24c04", AT24_DEVICE_MAGIC(4096 / 8, 0) },
- { "24cs04", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- /* 24rf08 quirk is handled at i2c-core */
- { "24c08", AT24_DEVICE_MAGIC(8192 / 8, 0) },
- { "24cs08", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24c16", AT24_DEVICE_MAGIC(16384 / 8, 0) },
- { "24cs16", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24c32", AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16) },
- { "24cs32", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_ADDR16 |
- AT24_FLAG_SERIAL |
- AT24_FLAG_READONLY) },
- { "24c64", AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16) },
- { "24cs64", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_ADDR16 |
- AT24_FLAG_SERIAL |
- AT24_FLAG_READONLY) },
- { "24c128", AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16) },
- { "24c256", AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16) },
- { "24c512", AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16) },
- { "24c1024", AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16) },
+ { "24c00", (kernel_ulong_t)&at24_data_24c00 },
+ { "24c01", (kernel_ulong_t)&at24_data_24c01 },
+ { "24cs01", (kernel_ulong_t)&at24_data_24cs01 },
+ { "24c02", (kernel_ulong_t)&at24_data_24c02 },
+ { "24cs02", (kernel_ulong_t)&at24_data_24cs02 },
+ { "24mac402", (kernel_ulong_t)&at24_data_24mac402 },
+ { "24mac602", (kernel_ulong_t)&at24_data_24mac602 },
+ { "spd", (kernel_ulong_t)&at24_data_spd },
+ { "24c04", (kernel_ulong_t)&at24_data_24c04 },
+ { "24cs04", (kernel_ulong_t)&at24_data_24cs04 },
+ { "24c08", (kernel_ulong_t)&at24_data_24c08 },
+ { "24cs08", (kernel_ulong_t)&at24_data_24cs08 },
+ { "24c16", (kernel_ulong_t)&at24_data_24c16 },
+ { "24cs16", (kernel_ulong_t)&at24_data_24cs16 },
+ { "24c32", (kernel_ulong_t)&at24_data_24c32 },
+ { "24cs32", (kernel_ulong_t)&at24_data_24cs32 },
+ { "24c64", (kernel_ulong_t)&at24_data_24c64 },
+ { "24cs64", (kernel_ulong_t)&at24_data_24cs64 },
+ { "24c128", (kernel_ulong_t)&at24_data_24c128 },
+ { "24c256", (kernel_ulong_t)&at24_data_24c256 },
+ { "24c512", (kernel_ulong_t)&at24_data_24c512 },
+ { "24c1024", (kernel_ulong_t)&at24_data_24c1024 },
{ "at24", 0 },
{ /* END OF LIST */ }
};
MODULE_DEVICE_TABLE(i2c, at24_ids);
static const struct of_device_id at24_of_match[] = {
- {
- .compatible = "atmel,24c00",
- .data = (void *)AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR)
- },
- {
- .compatible = "atmel,24c01",
- .data = (void *)AT24_DEVICE_MAGIC(1024 / 8, 0)
- },
- {
- .compatible = "atmel,24c02",
- .data = (void *)AT24_DEVICE_MAGIC(2048 / 8, 0)
- },
- {
- .compatible = "atmel,spd",
- .data = (void *)AT24_DEVICE_MAGIC(2048 / 8,
- AT24_FLAG_READONLY | AT24_FLAG_IRUGO)
- },
- {
- .compatible = "atmel,24c04",
- .data = (void *)AT24_DEVICE_MAGIC(4096 / 8, 0)
- },
- {
- .compatible = "atmel,24c08",
- .data = (void *)AT24_DEVICE_MAGIC(8192 / 8, 0)
- },
- {
- .compatible = "atmel,24c16",
- .data = (void *)AT24_DEVICE_MAGIC(16384 / 8, 0)
- },
- {
- .compatible = "atmel,24c32",
- .data = (void *)AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c64",
- .data = (void *)AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c128",
- .data = (void *)AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c256",
- .data = (void *)AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c512",
- .data = (void *)AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c1024",
- .data = (void *)AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16)
- },
- { },
+ { .compatible = "atmel,24c00", .data = &at24_data_24c00 },
+ { .compatible = "atmel,24c01", .data = &at24_data_24c01 },
+ { .compatible = "atmel,24c02", .data = &at24_data_24c02 },
+ { .compatible = "atmel,spd", .data = &at24_data_spd },
+ { .compatible = "atmel,24c04", .data = &at24_data_24c04 },
+ { .compatible = "atmel,24c08", .data = &at24_data_24c08 },
+ { .compatible = "atmel,24c16", .data = &at24_data_24c16 },
+ { .compatible = "atmel,24c32", .data = &at24_data_24c32 },
+ { .compatible = "atmel,24c64", .data = &at24_data_24c64 },
+ { .compatible = "atmel,24c128", .data = &at24_data_24c128 },
+ { .compatible = "atmel,24c256", .data = &at24_data_24c256 },
+ { .compatible = "atmel,24c512", .data = &at24_data_24c512 },
+ { .compatible = "atmel,24c1024", .data = &at24_data_24c1024 },
+ { /* END OF LIST */ },
};
MODULE_DEVICE_TABLE(of, at24_of_match);
static const struct acpi_device_id at24_acpi_ids[] = {
- { "INT3499", AT24_DEVICE_MAGIC(8192 / 8, 0) },
- { }
+ { "INT3499", (kernel_ulong_t)&at24_data_INT3499 },
+ { /* END OF LIST */ }
};
MODULE_DEVICE_TABLE(acpi, at24_acpi_ids);
@@ -516,8 +501,8 @@ static unsigned int at24_get_offset_adj(u8 flags, unsigned int byte_len)
static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
- struct at24_platform_data chip;
- kernel_ulong_t magic = 0;
+ struct at24_platform_data chip = { 0 };
+ const struct at24_chip_data *cd = NULL;
bool writable;
struct at24_data *at24;
int err;
@@ -535,28 +520,22 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
*/
if (client->dev.of_node &&
of_match_device(at24_of_match, &client->dev)) {
- magic = (kernel_ulong_t)
- of_device_get_match_data(&client->dev);
+ cd = of_device_get_match_data(&client->dev);
} else if (id) {
- magic = id->driver_data;
+ cd = (void *)id->driver_data;
} else {
const struct acpi_device_id *aid;
aid = acpi_match_device(at24_acpi_ids, &client->dev);
if (aid)
- magic = aid->driver_data;
+ cd = (void *)aid->driver_data;
}
- if (!magic)
+ if (!cd)
return -ENODEV;
- chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
- magic >>= AT24_SIZE_BYTELEN;
- chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
-
+ chip.byte_len = cd->byte_len;
+ chip.flags = cd->flags;
at24_get_pdata(&client->dev, &chip);
-
- chip.setup = NULL;
- chip.context = NULL;
}
if (!is_power_of_2(chip.byte_len))
--
1.9.1
^ permalink raw reply related
* [PATCH v3 0/1] eeprom: at24: convert magic numbers to structs.
From: Sven Van Asbroeck @ 2017-12-18 18:30 UTC (permalink / raw)
To: svendev, wsa, brgl, nsekhar, sakari.ailus, javier,
divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c
v3:
rebase against maintainer's latest devel branch
removed macros from struct {i2c,of,acpi}_device_id for easy grepping
applied newline, formatting, tab suggestions
v2:
use struct at24_chip_data instead of struct at24_platform_data
(which decreases code size)
explicitly write out of compatible nodes, e.g. "atmel,24c04"
(which allows grepping for of compatible nodes)
v1:
first shot
Sven Van Asbroeck (1):
eeprom: at24: convert magic numbers to structs.
drivers/misc/eeprom/at24.c | 219 ++++++++++++++++++++-------------------------
1 file changed, 99 insertions(+), 120 deletions(-)
--
1.9.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox