* Re: [PATCHv4 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Chris Packham @ 2017-01-19 21:12 UTC (permalink / raw)
To: Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Kalyan Kinthada, Linus Walleij, Rob Herring, Mark Rutland,
Thomas Petazzoni, Laxman Dewangan,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9996b6a215f944e1a47fa6239d8de21f@svr-chch-ex1.atlnz.lc>
On 14/01/17 20:50, Chris Packham wrote:
> On 13/01/17 22:54, Sebastian Hesselbarth wrote:
>> On 13.01.2017 10:12, Chris Packham wrote:
>>> From: Kalyan Kinthada <kalyan.kinthada-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
>>>
>>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>>> from Marvell.
>>>
>>> Signed-off-by: Kalyan Kinthada <kalyan.kinthada-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
>>> Signed-off-by: Chris Packham <chris.packham-6g8wRflRTwXFdCa3tKVlE6U/zSkkHjvu@public.gmane.org>
>>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>>
>>> Notes:
>>> Changes in v2:
>>> - include sdio support for the 98DX4251
>>> Changes in v3:
>>> - None
>>> Changes in v4:
>>> - Correct some discrepencies between binding and driver.
>>
>> Well, unfortunately I still see differences between the "gpio" in
>> the binding and "gpo" in the driver.
>>
>> Please go back to that list I sent you yesterday and fix them all.
>>
>
> I think you may have missed my initial reply [1]. Or I have missed your
> response to it. Long story short "gpo" is intentional because some of
> those pins can't be used as inputs. But if you still want me to change
> it I will.
>
> [1] - https://lkml.org/lkml/2017/1/12/117
>
Hi Sebastian,
Did you get a chance to consider this. Do you still want me to change
gpo -> gpio given the information above?
--
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 1/2] mailbox: Add driver for Broadcom FlexRM ring manager
From: Scott Branden @ 2017-01-19 21:23 UTC (permalink / raw)
To: Anup Patel, Jassi Brar, Rob Herring
Cc: Mark Rutland, Ray Jui, Scott Branden, Pramod KUMAR, Rob Rice,
Device Tree, Linux Kernel, Linux ARM Kernel, BCM Kernel Feedback
In-Reply-To: <CAALAos8RVRenZXeLg6ARPqJNteHKQ2d0n9cnfFfsp2MV4sj3Bg@mail.gmail.com>
Hi Anup,
On 17-01-18 07:15 PM, Anup Patel wrote:
> Hi All,
>
> Any comments on this patch ??
>
> Regards,
> Anup
>
Looks good to me.
Jassi, can you pickup this patchset?
Scott
^ permalink raw reply
* Re: [PATCH v3 1/3] input: pwm-beeper: add feature to set volume via sysfs
From: Dmitry Torokhov @ 2017-01-19 21:29 UTC (permalink / raw)
To: Frieder Schrempf
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ,
luis-HiykPkW1eAzzDCI4PIEvbQC/G2K4zDHf,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <49b6d7788399142ecd01f4f5dcf263ce96eb13f1.1484838551.git.frieder.schrempf-wPoT/lNZgHizQB+pC5nmwQ@public.gmane.org>
Hi Frieder,
On Thu, Jan 19, 2017 at 04:24:08PM +0100, Frieder Schrempf wrote:
> Make the driver accept switching volume levels via sysfs.
> This can be helpful if the beep/bell sound intensity needs
> to be adapted to the environment of the device.
>
> The volume adjustment is done by changing the duty cycle of
> the pwm signal.
>
> This patch adds the sysfs interface with 5 default volume
> levels (0 - mute, 4 - max. volume).
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf-wPoT/lNZgHizQB+pC5nmwQ@public.gmane.org>
> ---
> Changes in v3:
> - update date
>
> .../ABI/testing/sysfs-class-input-pwm-beeper | 17 ++++++
> drivers/input/misc/pwm-beeper.c | 71 +++++++++++++++++++++-
> 2 files changed, 87 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/ABI/testing/sysfs-class-input-pwm-beeper
>
> diff --git a/Documentation/ABI/testing/sysfs-class-input-pwm-beeper b/Documentation/ABI/testing/sysfs-class-input-pwm-beeper
> new file mode 100644
> index 0000000..c878a1d
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-input-pwm-beeper
> @@ -0,0 +1,17 @@
> +What: /sys/class/input/input(x)/volume
Only generic (i.e. applicable to all input devices) attributes can be
present in /sys/class/input/input(x)/, and volume certainly isn't such
attribute. Please move them to the pwm-beeper platform device itself.
> +Date: January 2017
> +KernelVersion:
> +Contact: Frieder Schrempf <frieder.schrempf-wPoT/lNZgHizQB+pC5nmwQ@public.gmane.org>
> +Description:
> + Control the volume of this pwm-beeper. Values
> + are between 0 and max_volume_level. This file will also
> + show the current volume level stored in the driver.
> +
> +What: /sys/class/input/input(x)/max_volume_level
> +Date: January 2017
> +KernelVersion:
> +Contact: Frieder Schrempf <frieder.schrempf-wPoT/lNZgHizQB+pC5nmwQ@public.gmane.org>
> +Description:
> + This file shows the maximum volume level that can be
> + assigned to volume.
> +
> diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
> index 5f9655d..3ed21da 100644
> --- a/drivers/input/misc/pwm-beeper.c
> +++ b/drivers/input/misc/pwm-beeper.c
> @@ -1,5 +1,9 @@
> /*
> * Copyright (C) 2010, Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
> + *
> + * Copyright (C) 2016, Frieder Schrempf <frieder.schrempf-wPoT/lNZgHizQB+pC5nmwQ@public.gmane.org>
> + * (volume support)
> + *
> * PWM beeper driver
> *
> * This program is free software; you can redistribute it and/or modify it
> @@ -27,16 +31,77 @@ struct pwm_beeper {
> struct pwm_device *pwm;
> struct work_struct work;
> unsigned long period;
> + unsigned int volume;
> + unsigned int volume_levels[] = {0, 8, 20, 40, 500};
Does this actually work? Anyway, you are not allowing to set differentr
values in for different beepers, so take the array out of the structure.
> + unsigned int max_volume_level;
> };
>
> #define HZ_TO_NANOSECONDS(x) (1000000000UL/(x))
>
> +static ssize_t beeper_show_volume(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct pwm_beeper *beeper = dev_get_drvdata(dev);
> +
> + return sprintf(buf, "%d\n", beeper->volume);
> +}
> +
> +static ssize_t beeper_show_max_volume_level(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct pwm_beeper *beeper = dev_get_drvdata(dev);
> +
> + return sprintf(buf, "%d\n", beeper->max_volume_level);
> +}
> +
> +static ssize_t beeper_store_volume(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t count)
> +{
> + int rc;
> + struct pwm_beeper *beeper = dev_get_drvdata(dev);
> + unsigned int volume;
> +
> + rc = kstrtouint(buf, 0, &volume);
> + if (rc)
> + return rc;
> +
> + rc = -ENXIO;
Why? There are no failures below.
> + if (volume > beeper->max_volume_level)
> + volume = beeper->max_volume_level;
Return -EINVAL maybe?
> + pr_debug("set volume to %u\n", volume);
> + if (beeper->volume != volume)
> + beeper->volume = volume;
Why?
> + rc = count;
> +
> + return rc;
> +}
> +
> +static DEVICE_ATTR(volume, 0644, beeper_show_volume, beeper_store_volume);
> +static DEVICE_ATTR(max_volume_level, 0644, beeper_show_max_volume_level, NULL);
Drop "level", it is cleaner.
> +
> +static struct attribute *bp_device_attributes[] = {
pwm_beeper_atttributes
> + &dev_attr_volume.attr,
> + &dev_attr_max_volume_level.attr,
> + NULL,
> +};
> +
> +static struct attribute_group bp_device_attr_group = {
pwm_beeper_attribute_group
> + .attrs = bp_device_attributes,
> +};
> +
> +static const struct attribute_group *bp_device_attr_groups[] = {
> + &bp_device_attr_group,
> + NULL,
> +};
> +
> static void __pwm_beeper_set(struct pwm_beeper *beeper)
> {
> unsigned long period = beeper->period;
>
> if (period) {
> - pwm_config(beeper->pwm, period / 2, period);
> + pwm_config(beeper->pwm,
> + period / 1000 * beeper->volume_levels[beeper->volume],
> + period);
> pwm_enable(beeper->pwm);
> } else
> pwm_disable(beeper->pwm);
> @@ -123,6 +188,8 @@ static int pwm_beeper_probe(struct platform_device *pdev)
>
> INIT_WORK(&beeper->work, pwm_beeper_work);
>
> + beeper->max_volume_level = ARRAY_SIZE(beeper->volume_levels) - 1;
> +
> beeper->input = input_allocate_device();
> if (!beeper->input) {
> dev_err(&pdev->dev, "Failed to allocate input device\n");
> @@ -146,6 +213,8 @@ static int pwm_beeper_probe(struct platform_device *pdev)
>
> input_set_drvdata(beeper->input, beeper);
>
> + beeper->input->dev.groups = bp_device_attr_groups;
> +
> error = input_register_device(beeper->input);
> if (error) {
> dev_err(&pdev->dev, "Failed to register input device: %d\n", error);
> --
> 2.7.4
>
Thanks.
--
Dmitry
--
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 v3 3/3] input: pwm-beeper: add devicetree bindings to set volume levels
From: Dmitry Torokhov @ 2017-01-19 21:30 UTC (permalink / raw)
To: Frieder Schrempf
Cc: robh, pawel.moll, ijc+devicetree, galak, luis, linux-input,
devicetree, linux-kernel
In-Reply-To: <2e483f697e1cd37b56c596b3979ccf1484c8be42.1484838551.git.frieder.schrempf@exceet.de>
On Thu, Jan 19, 2017 at 04:24:10PM +0100, Frieder Schrempf wrote:
> This patch adds the devicetree bindings to set the volume levels
> and the default volume level.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
> ---
> Changes in v3:
> - none
>
> drivers/input/misc/pwm-beeper.c | 49 ++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
> index 3ed21da..a7f9d70 100644
> --- a/drivers/input/misc/pwm-beeper.c
> +++ b/drivers/input/misc/pwm-beeper.c
> @@ -32,7 +32,7 @@ struct pwm_beeper {
> struct work_struct work;
> unsigned long period;
> unsigned int volume;
> - unsigned int volume_levels[] = {0, 8, 20, 40, 500};
> + unsigned int *volume_levels;
> unsigned int max_volume_level;
> };
>
> @@ -161,8 +161,11 @@ static void pwm_beeper_close(struct input_dev *input)
> static int pwm_beeper_probe(struct platform_device *pdev)
> {
> unsigned long pwm_id = (unsigned long)dev_get_platdata(&pdev->dev);
> + struct device_node *np = pdev->dev.of_node;
> struct pwm_beeper *beeper;
> - int error;
> + struct property *prop;
> + int error, length;
> + u32 value;
>
> beeper = kzalloc(sizeof(*beeper), GFP_KERNEL);
> if (!beeper)
> @@ -188,7 +191,47 @@ static int pwm_beeper_probe(struct platform_device *pdev)
>
> INIT_WORK(&beeper->work, pwm_beeper_work);
>
> - beeper->max_volume_level = ARRAY_SIZE(beeper->volume_levels) - 1;
> + /* determine the number of volume levels */
> + prop = of_find_property(np, "volume-levels", &length);
Please use generic device properties, not OF-specific ones.
> + if (!prop) {
> + dev_dbg(&pdev->dev, "no volume levels specified, using max volume\n");
> + beeper->max_volume_level = 1;
> + } else
> + beeper->max_volume_level = length / sizeof(u32);
> +
> + /* read volume levels from DT property */
> + if (beeper->max_volume_level > 0) {
> + size_t size = sizeof(*beeper->volume_levels) *
> + beeper->max_volume_level;
> +
> + beeper->volume_levels = devm_kzalloc(&(pdev->dev), size,
> + GFP_KERNEL);
> + if (!beeper->volume_levels)
> + return -ENOMEM;
> +
> + if (prop) {
> + error = of_property_read_u32_array(np, "volume-levels",
> + beeper->volume_levels,
> + beeper->max_volume_level);
> +
> + if (error < 0)
> + return error;
> +
> + error = of_property_read_u32(np, "default-volume-level",
> + &value);
> +
> + if (error < 0) {
> + dev_dbg(&pdev->dev, "no default volume specified, using max volume\n");
> + value = beeper->max_volume_level - 1;
> + }
> + } else {
> + beeper->volume_levels[0] = 500;
> + value = 0;
> + }
> +
> + beeper->volume = value;
> + beeper->max_volume_level--;
> + }
>
> beeper->input = input_allocate_device();
> if (!beeper->input) {
> --
> 2.7.4
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] usb: dwc3: add quirk to handle DWC_USB3_NUM == DWC_USB3_NUM_IN_EPS
From: Bryan O'Donoghue @ 2017-01-19 21:34 UTC (permalink / raw)
To: Felipe Balbi, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, John Youn
In-Reply-To: <87mvemx0so.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Thanks for the quick feedback Felipe, appreciated, I'll take on-board
those changes.
---
bod
--
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 v3 0/3] input: pwm-beeper: add feature to set volume level
From: Dmitry Torokhov @ 2017-01-19 21:37 UTC (permalink / raw)
To: Frieder Schrempf
Cc: robh, pawel.moll, ijc+devicetree, galak, luis, linux-input,
devicetree, linux-kernel, David Lechner
In-Reply-To: <cover.1484838551.git.frieder.schrempf@exceet.de>
On Thu, Jan 19, 2017 at 04:24:07PM +0100, Frieder Schrempf wrote:
> Make the driver accept switching volume levels via sysfs.
> This can be helpful if the beep/bell sound intensity needs
> to be adapted to the environment of the device.
>
> The number of volume levels available and their values can
> be specified via device tree (similar to pwm-backlight).
>
> The volume adjustment is done by changing the duty cycle of
> the pwm signal.
I wonder how this all will mesh up with beepers that have dedicated
amplifiers (support is being added by David Lechner).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCHv2] dt: bindings: Add support for CSI1 bus
From: Sakari Ailus @ 2017-01-19 21:37 UTC (permalink / raw)
To: Baruch Siach
Cc: Pavel Machek, robh+dt, devicetree, ivo.g.dimitrov.75, sre,
pali.rohar, linux-media
In-Reply-To: <20170112120603.6gwtpwhyuaynvlj3@tarshish>
Hi Baruch,
On Thu, Jan 12, 2017 at 02:06:03PM +0200, Baruch Siach wrote:
> Hi Pavel,
>
> On Wed, Jan 11, 2017 at 11:53:35PM +0100, Pavel Machek wrote:
> > From: Sakari Ailus <sakari.ailus@iki.fi>
> >
> > In the vast majority of cases the bus type is known to the driver(s)
> > since a receiver or transmitter can only support a single one. There
> > are cases however where different options are possible.
> >
> > The existing V4L2 OF support tries to figure out the bus type and
> > parse the bus parameters based on that. This does not scale too well
> > as there are multiple serial busses that share common properties.
> >
> > Some hardware also supports multiple types of busses on the same
> > interfaces.
> >
> > Document the CSI1/CCP2 property strobe. It signifies the clock or
> > strobe mode.
> >
> > Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> >
> > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > index 9cd2a36..08c4498 100644
> > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> > @@ -76,6 +76,11 @@ Optional endpoint properties
> > mode horizontal and vertical synchronization signals are provided to the
> > slave device (data source) by the master device (data sink). In the master
> > mode the data source device is also the source of the synchronization signals.
> > +- bus-type: data bus type. Possible values are:
> > + 0 - MIPI CSI2
> > + 1 - parallel / Bt656
>
> Why not have separate values for parallel and BT.656?
The current implementation of V4L2 OF support digs the information from
other properties (hsync-active, vsync-active and field-even-active). If any
of them are present, the bus is considered to be a regular parallel bus ---
the Bt.656 has no such signals.
CSI-2 bus is assumed if CSI-2 specific properties can be found. However,
explicit bus type is needed as the type of the bus isn't anymore implicitly
determinable with the addition of CSI-1 and CCP2 busses: they use the same
properties.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy
From: Stephen Boyd @ 2017-01-19 21:42 UTC (permalink / raw)
To: Vivek Gautam
Cc: Bjorn Andersson, Kishon Vijay Abraham I, robh+dt, linux-kernel,
devicetree, mark.rutland, srinivas.kandagatla, linux-arm-msm
In-Reply-To: <5cee25c5-434b-6e73-301e-3942dedd16fa@codeaurora.org>
On 01/19, Vivek Gautam wrote:
>
> On 01/19/2017 06:10 AM, Stephen Boyd wrote:
> >>
> >Didn't we already move away from subnodes for lanes in an earlier
> >revision of these patches? I seem to recall we did that because
> >lanes are not devices and the whole "phy as a bus" concept not
> >making sense.
>
> Yea, we started out without having any sub-nodes and we
> argued that we don't require them since the qmp device is
> represented by the qmp node itself.
> The lanes otoh are representative of gen_phys and related properties.
>
> In the driver -
> "struct qmp_phy " represents the lanes and holds "struct phy",
> "struct qcom_qmp" represents the qmp block as a whole and holds
> "struct device"
> Does this make lanes qualify to be childs of qmp ?
Hmm... maybe I was recalling the DSI phy binding. I think there
are lanes there too but we decided to just have one node.
>
> "phy as a bus" (just trying to understand here) -
> let's say a usb phy controller has one HSIC phy port and one USB2 phy port.
> So, should this phy controller be a bus providing two ports (and so
> we will have
> couple of child nodes to the phy controller) ?
>
Typically in DT a subnode or collection of subnodes means there's
some sort of bus involved. Usually each node corresponds to a
struct device, and the parent node corresponds to the bus or
controller for the logical bus.
In this case (only PCIe though? not UFS or USB?) it seems like we
have multiple phys that share a common register space, but
otherwise they have their own register space and power
management. Would you have each PCIe controller point to a
different subnode for their associated phy? I'm trying to
understand the benefit of the subnodes if they aren't treated as
struct devices.
At the least, please get DT reviewers to ack the new binding
before rewriting the code.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCHv2] dt: bindings: Add support for CSI1 bus
From: Sakari Ailus @ 2017-01-19 21:49 UTC (permalink / raw)
To: Pavel Machek
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
sre-DgEjT+Ai2ygdnm+yROfE0A, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170111225335.GA21553@amd>
Hi Pavel,
On Wed, Jan 11, 2017 at 11:53:35PM +0100, Pavel Machek wrote:
> From: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
>
> In the vast majority of cases the bus type is known to the driver(s)
> since a receiver or transmitter can only support a single one. There
> are cases however where different options are possible.
>
> The existing V4L2 OF support tries to figure out the bus type and
> parse the bus parameters based on that. This does not scale too well
> as there are multiple serial busses that share common properties.
>
> Some hardware also supports multiple types of busses on the same
> interfaces.
>
> Document the CSI1/CCP2 property strobe. It signifies the clock or
> strobe mode.
>
> Signed-off-by: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
>
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index 9cd2a36..08c4498 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -76,6 +76,11 @@ Optional endpoint properties
> mode horizontal and vertical synchronization signals are provided to the
> slave device (data source) by the master device (data sink). In the master
> mode the data source device is also the source of the synchronization signals.
> +- bus-type: data bus type. Possible values are:
> + 0 - MIPI CSI2
> + 1 - parallel / Bt656
> + 2 - MIPI CSI1
> + 3 - CCP2
Actually, thinking about this again --- we only need to explictly specify
busses if we're dealing with either CCP2 or CSI-1. The vast majority of the
actual busses are and continue to be CSI-2 or either parallel or Bt.656. As
they can be implicitly detected, we would have an option to just drop values
0 and 1 from above, i.e. only leave CSI-1 and CCP2. For now, specifying
CSI-2 or parallel / Bt.656 adds no value as the old DT binaries without
bus-type will need to be supported anyway.
> - bus-width: number of data lines actively used, valid for the parallel busses.
> - data-shift: on the parallel data busses, if bus-width is used to specify the
> number of data lines, data-shift can be used to specify which data lines are
> @@ -112,7 +117,8 @@ Optional endpoint properties
> should be the combined length of data-lanes and clock-lanes properties.
> If the lane-polarities property is omitted, the value must be interpreted
> as 0 (normal). This property is valid for serial busses only.
> -
> +- strobe: Whether the clock signal is used as clock or strobe. Used
> + with CCP2, for instance.
How about the "ti,strobe-clock-inv" I proposed? No-one seems to know what
this really truly means... or just drop it if it's not really needed.
--
Cheers,
Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
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: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Ray Jui @ 2017-01-19 21:55 UTC (permalink / raw)
To: Florian Fainelli, Scott Branden, Rob Herring, Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <efabd5cc-eafb-0887-852e-24b0f52019cf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 1/19/2017 12:17 PM, Florian Fainelli wrote:
> On 01/19/2017 12:07 PM, Scott Branden wrote:
>> Hi Florian,
>>
>> On 17-01-19 11:40 AM, Florian Fainelli wrote:
>>> On 01/19/2017 11:30 AM, Scott Branden wrote:
>>>> Hi Rob,
>>>>
>>>> On 17-01-19 09:36 AM, Rob Herring wrote:
>>>>> On Tue, Jan 17, 2017 at 01:35:07PM +0530, Raviteja Garimella wrote:
>>>>>> This patch adds device tree bindings documentation for Synopsys
>>>>>> USB device controller platform driver.
>>>>>
>>>>> Bindings describe h/w, not drivers.
>>>>>>
>>>>>> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>>>>> ---
>>>>>> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 27
>>>>>> ++++++++++++++++++++++
>>>>>> 1 file changed, 27 insertions(+)
>>>>>> create mode 100644
>>>>>> Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>>> b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..0c18327
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>>> @@ -0,0 +1,27 @@
>>>>>> +Synopsys USB Device controller.
>>>>>> +
>>>>>> +The device node is used for Synopsys Designware Cores AHB
>>>>>> +Subsystem Device Controller (UDC).
>>>>>> +
>>>>>> +This device node is used by UDCs integrated it Broadcom's
>>>>>> +Northstar2 and Cygnus SoC's.
>>>>>
>>>>> You need compatible strings for these in addition.
>>>>>
>>>> We don't need compatibility strings when an IP block is integrated into
>>>> an SoC. Otherwise each time we add the IP block to a new SoC we would
>>>> need to update ever linux driver that supports that SoC. That doesn't
>>>> make sense?
>>>
>>> You probably do need such a thing, here is how the compatible strings
>>> for IP blocks integrated into SoCs could be used:
>>>
>>> - provide a compatible strings which describes exactly the integration
>>> of this peripheral into a given SoC, e.g: brcm,udc-ns2, the reason for
>>> that is that you want to be able to capture the specific IP block
>>> integration into a specific SoC and all its quirks
>>>
>>> - if the block has its own revision scheme (and it can be relied on),
>>> provide it: brcm,udc-v1.2 and that is probably the most meaningful
>>> compatible string for a client program here
>>>
>>> - have a some kind of fallback/catchall compatible string that describes
>>> the block: brcm,udc which may also work just fine, although is not
>>> preferred
>>>
>>> Defining compatible strings is meant to avoid making (possibly
>>> incompatible) Device Tree binding changes in the future, and you always
>>> have the liberty as a client program (OS, bootloader) to match only the
>>> compatible strings you care about, from the most specific (which
>>> includes the exact SoC) to the least specific.
>>>
>>> The key thing is that, if the full set of compatible strings are present
>>> and available, you can retroactively fix your driver to be more
>>> specific, very much less so your Device Tree blob (although there is
>>> disagreement).
>>>
>> The driver stands alone from the SoC and does not need compatibility
>> strings per SoC. New SoCs will use the exact same block.
>
> Even if you take the exact same block and put it in a different SoC,
> that's still an integration work that 99% of the time goes just fine
> because the validation worked great, and the 1% of the time where you
> need to capture an integration bug, you are glad this SoC-specific
> compatible string exists such that you can work around it in the driver.
That's a very conservative estimate. Based on my experience, it's more
like 50/50, i.e., roughly half of the time we found SoC integration
specific quirks or workaround are needed.
>
> One way to solve that is to use SoC specific compatible strings because
> that presents itself as a self-contained and standardized way, or you
> can have your driver call into a piece of code that reads the SoC
> type/revision, but AFAICT this seems to be frowned upon because it
> presents some kind of layering violation.
>
>>
>> We don't add compatibility strings to any other drivers when we add the
>> same block to a new SoC.
>
> Ideally we would define new compatible strings for each new SoC we tape
> out, yet don't necessarily match them in client programs, but just
> define them as a safeguard in case something went wrong at the
> integration stage that is discovered after the fact.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 v3 0/8] ARM: dts: Switch to new DSA binding
From: Florian Fainelli @ 2017-01-19 22:26 UTC (permalink / raw)
To: linux-arm-kernel, Gregory Clement
Cc: Mark Rutland, Andrew Lunn, Jason Cooper,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
vivien.didelot, Russell King, open list, Rob Herring,
Sebastian Hesselbarth
In-Reply-To: <20170117182224.32212-1-f.fainelli@gmail.com>
On 01/17/2017 10:22 AM, Florian Fainelli wrote:
> Hi all,
>
> This patch series converts the in-tree users to utilize the new (relatively)
> DSA binding that was introduced with commit 8c5ad1d6179d ("net: dsa: Document
> new binding"). The legacy binding node is kept included, but is marked
> disabled.
>
> Changes in v3:
>
> - collected tags from Andrew and Russell
> - added missing change to arch/arm/boot/dts/kirkwood-rd88f6281-a.dts
>
> Changes in v2:
>
> - patch 1: Use an hexadecimal reg property
> - patch 2: fixed the subject
> - patch 3: s/okay/disabled/ for the legacy DSA node
> - patches 7/8: fixed a stray whitespace
>
> In about 2-3 releases we may consider removing the old DSA binding entirely
> from the kernel.
Gregory, all patches have been reviewed/tested now, can you take this
for an upcoming 4.11 pull request? Thanks!
--
Florian
^ permalink raw reply
* [PATCH 1/2] ARM: dts: exynos: Add CLK_ACLK432_SCALER clock to gsc_pd for Exynos5800
From: Javier Martinez Canillas @ 2017-01-19 22:29 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Javier Martinez Canillas, Shuah Khan, Andi Shyti, Russell King,
Inki Dae, Andrzej Hajda, Kukjin Kim, Krzysztof Kozlowski,
linux-arm-kernel, Marek Szyprowski
On Exynos5800 SoC the SCALER block uses 2 input clocks: CLK_ACLK_300_GSCL
and CLK_ACLK432_SCALER, so both needs to be ungated in order to access it.
The SoC manual say the CLK_ACLK432_SCALER is needed to access the internal
buses, so add this clock as another asynchronous bridges (ASB) clock.
The Exynos5420 only has the CLK_ACLK_300_GSCL clock defined. So just using
this definition from exynos5420.dtsi in Exynos5800 leads to the following:
[ 227.008559] Unhandled fault: imprecise external abort (0x1c06) at 0x00048e14
[ 227.015116] pgd = ed5dc000
[ 227.017213] [00048e14] *pgd=b17c6835
[ 227.020889] Internal error: : 1c06 [#1] PREEMPT SMP ARM
...
[ 227.241585] [<bf2429bc>] (gsc_wait_reset [exynos_gsc]) from [<bf24009c>] (gsc_runtime_resume+0x9c/0xec [exynos_gsc])
[ 227.252331] [<bf24009c>] (gsc_runtime_resume [exynos_gsc]) from [<c042e488>] (genpd_runtime_resume+0x120/0x1d4)
[ 227.262294] [<c042e488>] (genpd_runtime_resume) from [<c04241c0>] (__rpm_callback+0xc8/0x218)
domain status slaves
/device runtime status
----------------------------------------------------------------------
power-domain@100440C0 on
/devices/platform/soc/14450000.mixer active
/devices/platform/soc/14530000.hdmi active
power-domain@10044120 on
power-domain@10044060 off-0
power-domain@10044020 on
power-domain@10044000 on
/devices/platform/soc/13e00000.video-scaler suspended
/devices/platform/soc/13e10000.video-scaler resuming
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/exynos5800.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800.dtsi b/arch/arm/boot/dts/exynos5800.dtsi
index 8213016803e5..4847abbf7a92 100644
--- a/arch/arm/boot/dts/exynos5800.dtsi
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -134,3 +134,11 @@
&mfc {
compatible = "samsung,mfc-v8";
};
+
+&gsc_pd {
+ clocks = <&clock CLK_FIN_PLL>,
+ <&clock CLK_MOUT_USER_ACLK300_GSCL>,
+ <&clock CLK_GSCL0>, <&clock CLK_GSCL1>,
+ <&clock CLK_ACLK432_SCALER>;
+ clock-names = "oscclk", "clk0", "asb0", "asb1", "asb2";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: exynos: Use correct mfc_pd async-bridge clock for Exynos5420
From: Javier Martinez Canillas @ 2017-01-19 22:29 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Javier Martinez Canillas, Shuah Khan, Andi Shyti, Russell King,
Inki Dae, Andrzej Hajda, Kukjin Kim, Krzysztof Kozlowski,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <1484864995-10679-1-git-send-email-javier@osg.samsung.com>
Commit 94aed538e032 ("ARM: dts: exynos: Add async-bridge clock to MFC
power domain for Exynos5420") fixed an imprecise external abort error
when the MFC registers were tried to be accessed and the needed clock
for the asynchronous bridges were gated.
But according to the Exynos5420 manual the "Gating AXI clock for MFC"
is not CLK_ACLK333 but CLK_MFC.
The end effect is the same because CLK_ACLK333 is a parent of CLK_MFC
but the correct clock should be used instead.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm/boot/dts/exynos5420.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 906a1a42a7ea..ffb148ea91d6 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -294,7 +294,7 @@
reg = <0x10044060 0x20>;
clocks = <&clock CLK_FIN_PLL>,
<&clock CLK_MOUT_USER_ACLK333>,
- <&clock CLK_ACLK333>;
+ <&clock CLK_MFC>;
clock-names = "oscclk", "clk0","asb0";
#power-domain-cells = <0>;
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 3/3] Input: pwm-beeper: add optional amplifier regulator
From: Dmitry Torokhov @ 2017-01-19 22:34 UTC (permalink / raw)
To: David Lechner
Cc: linux-input, devicetree, Rob Herring, Mark Rutland, linux-kernel
In-Reply-To: <b3c4003d-6cbb-e7c5-1f90-3dda7aa1a7f9@lechnology.com>
On Sun, Jan 15, 2017 at 07:04:09PM -0600, David Lechner wrote:
> On 01/15/2017 06:34 PM, Dmitry Torokhov wrote:
> >On Sun, Jan 15, 2017 at 06:12:29PM -0600, David Lechner wrote:
> >>On 01/14/2017 01:19 PM, Dmitry Torokhov wrote:
> >>>On Wed, Jan 11, 2017 at 02:02:01PM -0600, David Lechner wrote:
> >>>>This adds an optional regulator to the pwm-beeper device. This regulator
> >>>>acts as an amplifier. The amplifier is only enabled while beeping in order
> >>>>to reduce power consumption.
> >>>>
> >>>>Tested on LEGO MINDSTORMS EV3, which has a speaker connected to PWM through
> >>>>an amplifier.
> >>>>
> >>>>Signed-off-by: David Lechner <david@lechnology.com>
> >>>>---
> >>>>drivers/input/misc/pwm-beeper.c | 29 ++++++++++++++++++++++++++++-
> >>>>1 file changed, 28 insertions(+), 1 deletion(-)
> >>>>
> >>>>diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
> >>>>index 30ac227..708e88e 100644
> >>>>--- a/drivers/input/misc/pwm-beeper.c
> >>>>+++ b/drivers/input/misc/pwm-beeper.c
> >>>>@@ -14,6 +14,7 @@
> >>>> */
> >>>>
> >>>>#include <linux/input.h>
> >>>>+#include <linux/regulator/consumer.h>
> >>>>#include <linux/module.h>
> >>>>#include <linux/kernel.h>
> >>>>#include <linux/of.h>
> >>>>@@ -25,8 +26,10 @@
> >>>>struct pwm_beeper {
> >>>> struct input_dev *input;
> >>>> struct pwm_device *pwm;
> >>>>+ struct regulator *reg;
> >>>> struct work_struct work;
> >>>> unsigned long period;
> >>>>+ bool reg_enabled;
> >>>>};
> >>>>
> >>>>#define HZ_TO_NANOSECONDS(x) (1000000000UL/(x))
> >>>>@@ -38,8 +41,20 @@ static void __pwm_beeper_set(struct pwm_beeper *beeper)
> >>>> if (period) {
> >>>> pwm_config(beeper->pwm, period / 2, period);
> >>>> pwm_enable(beeper->pwm);
> >>>>- } else
> >>>>+ if (beeper->reg) {
> >>>>+ int error;
> >>>>+
> >>>>+ error = regulator_enable(beeper->reg);
> >>>>+ if (!error)
> >>>>+ beeper->reg_enabled = true;
> >>>>+ }
> >>>>+ } else {
> >>>>+ if (beeper->reg_enabled) {
> >>>>+ regulator_disable(beeper->reg);
> >>>>+ beeper->reg_enabled = false;
> >>>>+ }
> >>>> pwm_disable(beeper->pwm);
> >>>>+ }
> >>>>}
> >>>>
> >>>>static void pwm_beeper_work(struct work_struct *work)
> >>>>@@ -82,6 +97,10 @@ static void pwm_beeper_stop(struct pwm_beeper *beeper)
> >>>>{
> >>>> cancel_work_sync(&beeper->work);
> >>>>
> >>>>+ if (beeper->reg_enabled) {
> >>>>+ regulator_disable(beeper->reg);
> >>>>+ beeper->reg_enabled = false;
> >>>>+ }
> >>>> if (beeper->period)
> >>>> pwm_disable(beeper->pwm);
> >>>>}
> >>>>@@ -111,6 +130,14 @@ static int pwm_beeper_probe(struct platform_device *pdev)
> >>>> return error;
> >>>> }
> >>>>
> >>>>+ beeper->reg = devm_regulator_get_optional(&pdev->dev, "amp");
> >>>
> >>>If you do not use optional regulator then you will not have to check if
> >>>you have it or not everywhere: regulator core will give you a dummy that
> >>>you can toggle to your heart's content.
> >>
> >>Some months ago, I learned that if you are not using device tree and
> >>you do not call regulator_has_full_constraints(), then you do not
> >>get a dummy regulator. And here, we are only checking if the
> >>regulator exists in one place. We will still need the checks for
> >>beeper->reg_enabled to keep calls to regulator_enable() and
> >>regulator_disable() balanced.
> >
> >Why? You do not have checks for calls to pwm_enable() and pwm_disable(),
> >(or rather beeper->period is used as such flag) why regulator would be
> >any different?
>
> regulator_enable() has a __must_check attribute on it, so we get
> compiler warnings if we do not check the return value. Also, if
> enabling the regulator fails and returns an error, then calling
> regulator_disable() later would cause an imbalance.
>
> pwm_enable() and pwm_disable() work differently because they don't
> count how many times they have been called. regulator_enable() and
> regulator_disable(), on the other hand, work like reference
> counting.
Ah, you are right, but it is more than that. It is possible to receive
multiple SND_BELL/SND_TONE events with non-0 value. You need to check if
regulator is already enabled before trying to enable it second time, or
your counting will be off.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Scott Branden @ 2017-01-19 22:36 UTC (permalink / raw)
To: Ray Jui, Florian Fainelli, Rob Herring, Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87d20899-9e79-5d10-f6c0-c443f586c2e6-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 17-01-19 01:55 PM, Ray Jui wrote:
>
>
> On 1/19/2017 12:17 PM, Florian Fainelli wrote:
>> On 01/19/2017 12:07 PM, Scott Branden wrote:
>>> Hi Florian,
>>>
>>> On 17-01-19 11:40 AM, Florian Fainelli wrote:
>>>> On 01/19/2017 11:30 AM, Scott Branden wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On 17-01-19 09:36 AM, Rob Herring wrote:
>>>>>> On Tue, Jan 17, 2017 at 01:35:07PM +0530, Raviteja Garimella wrote:
>>>>>>> This patch adds device tree bindings documentation for Synopsys
>>>>>>> USB device controller platform driver.
>>>>>>
>>>>>> Bindings describe h/w, not drivers.
>>>>>>>
>>>>>>> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>>>>>> ---
>>>>>>> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 27
>>>>>>> ++++++++++++++++++++++
>>>>>>> 1 file changed, 27 insertions(+)
>>>>>>> create mode 100644
>>>>>>> Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>>>> b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>>>> new file mode 100644
>>>>>>> index 0000000..0c18327
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>>>>>>> @@ -0,0 +1,27 @@
>>>>>>> +Synopsys USB Device controller.
>>>>>>> +
>>>>>>> +The device node is used for Synopsys Designware Cores AHB
>>>>>>> +Subsystem Device Controller (UDC).
>>>>>>> +
>>>>>>> +This device node is used by UDCs integrated it Broadcom's
>>>>>>> +Northstar2 and Cygnus SoC's.
>>>>>>
>>>>>> You need compatible strings for these in addition.
>>>>>>
>>>>> We don't need compatibility strings when an IP block is integrated into
>>>>> an SoC. Otherwise each time we add the IP block to a new SoC we would
>>>>> need to update ever linux driver that supports that SoC. That doesn't
>>>>> make sense?
>>>>
>>>> You probably do need such a thing, here is how the compatible strings
>>>> for IP blocks integrated into SoCs could be used:
>>>>
>>>> - provide a compatible strings which describes exactly the integration
>>>> of this peripheral into a given SoC, e.g: brcm,udc-ns2, the reason for
>>>> that is that you want to be able to capture the specific IP block
>>>> integration into a specific SoC and all its quirks
>>>>
>>>> - if the block has its own revision scheme (and it can be relied on),
>>>> provide it: brcm,udc-v1.2 and that is probably the most meaningful
>>>> compatible string for a client program here
>>>>
>>>> - have a some kind of fallback/catchall compatible string that describes
>>>> the block: brcm,udc which may also work just fine, although is not
>>>> preferred
>>>>
>>>> Defining compatible strings is meant to avoid making (possibly
>>>> incompatible) Device Tree binding changes in the future, and you always
>>>> have the liberty as a client program (OS, bootloader) to match only the
>>>> compatible strings you care about, from the most specific (which
>>>> includes the exact SoC) to the least specific.
>>>>
>>>> The key thing is that, if the full set of compatible strings are present
>>>> and available, you can retroactively fix your driver to be more
>>>> specific, very much less so your Device Tree blob (although there is
>>>> disagreement).
>>>>
>>> The driver stands alone from the SoC and does not need compatibility
>>> strings per SoC. New SoCs will use the exact same block.
>>
>> Even if you take the exact same block and put it in a different SoC,
>> that's still an integration work that 99% of the time goes just fine
>> because the validation worked great, and the 1% of the time where you
>> need to capture an integration bug, you are glad this SoC-specific
>> compatible string exists such that you can work around it in the driver.
>
> That's a very conservative estimate. Based on my experience, it's more
> like 50/50, i.e., roughly half of the time we found SoC integration
> specific quirks or workaround are needed.
>
50% is an exaggeration for sure. Maybe a driver you are has that issue
but that is not the case with most drivers. We have many IP blocks in
the SoC - both internal and externally sourced IP. We integrate SP805
timer driver into many SoCs and never specify a SoC specific
compatibility string with it (nor should we).
That being said - if your driver needs to know SoC specifics is should
not need to have an SoC specific compatibility string added per driver.
Why can your driver just not query that information from the upper level
SoC specific info already present in device tree?
Each SoC is already specified in device tree at the upper level already.
Example:
arch/arm/boot/dts/bcm7445.dtsi has this compatibility info already
present in its device tree:
compatible = "brcm,bcm7445", "brcm,brcmstb";
If needed, a driver should query this info rather than adding SoC
specific compatibility strings to every single device tree entry.
We should only add driver revision numbers as needed, not SoC specific
names. That way drivers don't change when the (same revision) of the IP
block is added to a new SoCs. And then if a SoC specific workaround is
needed the upper level compatibility string can be queried should be
utilized. It already exists today and is available for use to all drivers.
>>
>> One way to solve that is to use SoC specific compatible strings because
>> that presents itself as a self-contained and standardized way, or you
>> can have your driver call into a piece of code that reads the SoC
>> type/revision, but AFAICT this seems to be frowned upon because it
>> presents some kind of layering violation.
>>
>>>
>>> We don't add compatibility strings to any other drivers when we add the
>>> same block to a new SoC.
>>
>> Ideally we would define new compatible strings for each new SoC we tape
>> out, yet don't necessarily match them in client programs, but just
>> define them as a safeguard in case something went wrong at the
>> integration stage that is discovered after the fact.
>>
--
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] of: Export __of_find_all_nodes()
From: Frank Rowand @ 2017-01-19 22:42 UTC (permalink / raw)
To: Alexander Sverdlin; +Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d9525715-be49-1cfa-f623-084237e44b4c-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
On 01/19/17 01:43, Alexander Sverdlin wrote:
> Hi!
>
> On 18/01/17 22:33, Frank Rowand wrote:
>>> This is necessary for for_each_of_allnodes() to work in the modules.
>>>
>>> Signed-off-by: Alexander Sverdlin <alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> ---
>>> drivers/of/base.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>>> index 2eb4dea62b84..f576c33e0b84 100644
>>> --- a/drivers/of/base.c
>>> +++ b/drivers/of/base.c
>>> @@ -270,6 +270,7 @@ struct device_node *__of_find_all_nodes(struct device_node *prev)
>>> }
>>> return np;
>>> }
>>> +EXPORT_SYMBOL_GPL(__of_find_all_nodes);
>>>
>>> /**
>>> * of_find_all_nodes - Get next node in global list
>>>
>> Quoting Rob from the last request for this:
>>
>> "What driver needs this? This isn't really a function I'd expect drivers to use."
>
> This one and the one from previous patch/mail are used in a module which reads DT overlays
If I understand correctly, that was a request to be able to use of_node_init() directly.
Is that correct?
> from pluggable extension boards, eventually performs some sanity checks/corrections and
> applies these overlays. This eventual corrections require low-level access to DT.
Are you saying that you want to modify the device tree data structure after the overlay
is applied?
The idea of sanity checks is one that I am very interested in. Could the sanity checks
be done statically, either with the overlay source, or with the compiled overlay source?
The idea behind that question is whether the checks could be done while the overlay is
being developed, instead of at run time.
I am also curious about what sort of corrections are made and how it is determined what
corrections to make.
> I cannot judge, how relevant this usecase is for the community, but I was driven by the fact,
> that the functions which require the functions I export are defined statically in .h files
> and therefore are exposed to the modules.
>
--
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 v3 0/8] ARM: dts: Switch to new DSA binding
From: Gregory CLEMENT @ 2017-01-19 22:48 UTC (permalink / raw)
To: Florian Fainelli
Cc: Mark Rutland, Andrew Lunn, Jason Cooper,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
vivien.didelot, Russell King, open list, Rob Herring,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <633afd2c-75e4-adeb-f3a0-b59b5f47f1a7@gmail.com>
Hi Florian,
On jeu., janv. 19 2017, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 01/17/2017 10:22 AM, Florian Fainelli wrote:
>> Hi all,
>>
>> This patch series converts the in-tree users to utilize the new (relatively)
>> DSA binding that was introduced with commit 8c5ad1d6179d ("net: dsa: Document
>> new binding"). The legacy binding node is kept included, but is marked
>> disabled.
>>
>> Changes in v3:
>>
>> - collected tags from Andrew and Russell
>> - added missing change to arch/arm/boot/dts/kirkwood-rd88f6281-a.dts
>>
>> Changes in v2:
>>
>> - patch 1: Use an hexadecimal reg property
>> - patch 2: fixed the subject
>> - patch 3: s/okay/disabled/ for the legacy DSA node
>> - patches 7/8: fixed a stray whitespace
>>
>> In about 2-3 releases we may consider removing the old DSA binding entirely
>> from the kernel.
>
> Gregory, all patches have been reviewed/tested now, can you take this
> for an upcoming 4.11 pull request? Thanks!
All the series applied on mvebu/dt
Thanks,
Gregory
> --
> Florian
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 0/8] ARM: dts: Switch to new DSA binding
From: Florian Fainelli @ 2017-01-19 22:49 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/
In-Reply-To: <878tq67jjy.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On 01/19/2017 02:48 PM, Gregory CLEMENT wrote:
> Hi Florian,
>
> On jeu., janv. 19 2017, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On 01/17/2017 10:22 AM, Florian Fainelli wrote:
>>> Hi all,
>>>
>>> This patch series converts the in-tree users to utilize the new (relatively)
>>> DSA binding that was introduced with commit 8c5ad1d6179d ("net: dsa: Document
>>> new binding"). The legacy binding node is kept included, but is marked
>>> disabled.
>>>
>>> Changes in v3:
>>>
>>> - collected tags from Andrew and Russell
>>> - added missing change to arch/arm/boot/dts/kirkwood-rd88f6281-a.dts
>>>
>>> Changes in v2:
>>>
>>> - patch 1: Use an hexadecimal reg property
>>> - patch 2: fixed the subject
>>> - patch 3: s/okay/disabled/ for the legacy DSA node
>>> - patches 7/8: fixed a stray whitespace
>>>
>>> In about 2-3 releases we may consider removing the old DSA binding entirely
>>> from the kernel.
>>
>> Gregory, all patches have been reviewed/tested now, can you take this
>> for an upcoming 4.11 pull request? Thanks!
>
>
> All the series applied on mvebu/dt
Awesome, merci !
--
Florian
--
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] usb: dwc3: add quirk to handle DWC_USB3_NUM == DWC_USB3_NUM_IN_EPS
From: John Youn @ 2017-01-19 22:49 UTC (permalink / raw)
To: Felipe Balbi, Bryan O'Donoghue,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, John Youn
In-Reply-To: <87mvemx0so.fsf@linux.intel.com>
On 1/19/2017 12:17 PM, Felipe Balbi wrote:
>
> Hi,
>
> Bryan O'Donoghue <pure.logic-SyKdqv6vbfZdzvEItQ6vdLNAH6kLmebB@public.gmane.org> writes:
>> - DWC_USB3_NUM indicates the number of Device mode single directional
>> endpoints, including OUT and IN endpoint 0.
>>
>> - DWC_USB3_NUM_IN_EPS indicates the maximum number of Device mode IN
>> endpoints active at any time, including control endpoint 0.
>>
>> It's possible to configure RTL such that DWC_USB3_NUM_EPS is equal to
>> DWC_USB3_NUM_IN_EPS.
>
> in that case, isn't it so you really don't have OUT eps? Why was your HW
> configured like this? Is this is silicon already or in FPGA or something
> early development-only part?
>
>> dwc3-core calculates the number of OUT endpoints as DWC_USB3_NUM minus
>> DWC_USB3_NUM_IN_EPS. If RTL has been configured with DWC_USB3_NUM_IN_EPS
>
> correctly so.
>
>> equal to DWC_USB3_NUM then dwc3-core will calculate the number of OUT
>> endpoints as zero.
>
> right
>
>> For example a from dwc3_core_num_eps() shows:
>> [ 1.565000] /usb0@f01d0000: found 8 IN and 0 OUT endpoints
>>
>> This patch fixes this case by adding a snps,num_in_eps quirk and an
>
> "This patch works around this case" would've been better here.
>
>> over-ride value for DWC_USB3_NUM_IN_EPS snps,num_in_eps_override. When the
>> quirk is declared then snps,num_in_eps_override will be used instead of
>> DWC_USB3_NUM_IN_EPS as the value of the number active IN endpoints.
>
> you don't need two values. A read of a non-existing property will return
> 0, IIRC.
>
>> The minimum value specified for DWC_USB3_NUM_IN_EPS in the Designware
>> data-book is two, if snps,num_in_eps_quirk is declared but
>> snps,num_in_eps_override is omitted, then the minimum value will be used as
>> the default.
>>
>> Signed-off-by: Bryan O'Donoghue <pure.logic-SyKdqv6vbfZdzvEItQ6vdLNAH6kLmebB@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++
>> drivers/usb/dwc3/core.c | 11 +++++++++++
>> drivers/usb/dwc3/core.h | 6 ++++++
>> 3 files changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
>> index e3e6983..bb383bf 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>> @@ -55,6 +55,9 @@ Optional properties:
>> fladj_30mhz_sdbnd signal is invalid or incorrect.
>>
>> - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated.
>> + - snps,num_in_eps_quirk: when set core will over-ride the num_in_eps value.
>> + - snps,num_in_eps_override: the value that will be used for num_in_eps when
>> + num_in_eps_quirk is true
>
> please declare these on the section above. Not below the one deprecated
> property.
>
> And as I said, you only need one property.
>
>> This is usually a subnode to DWC3 glue to which it is connected.
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 369bab1..d5e472a 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -398,6 +398,8 @@ static void dwc3_core_num_eps(struct dwc3 *dwc)
>> struct dwc3_hwparams *parms = &dwc->hwparams;
>>
>> dwc->num_in_eps = DWC3_NUM_IN_EPS(parms);
>> + if (dwc->num_in_eps_quirk)
>> + dwc->num_in_eps = dwc->num_in_eps_override;
>> dwc->num_out_eps = DWC3_NUM_EPS(parms) - dwc->num_in_eps;
>> }
>>
>> @@ -908,6 +910,7 @@ static void dwc3_get_properties(struct dwc3 *dwc)
>> struct device *dev = dwc->dev;
>> u8 lpm_nyet_threshold;
>> u8 tx_de_emphasis;
>> + u8 num_in_eps_override;
>> u8 hird_threshold;
>>
>> /* default to highest possible threshold */
>> @@ -922,6 +925,9 @@ static void dwc3_get_properties(struct dwc3 *dwc)
>> */
>> hird_threshold = 12;
>>
>> + /* default value of 2 is the minimum RTL parameter value */
>> + num_in_eps_override = 2;
>> +
>> dwc->maximum_speed = usb_get_maximum_speed(dev);
>> dwc->dr_mode = usb_get_dr_mode(dev);
>> dwc->hsphy_mode = of_usb_get_phy_mode(dev->of_node);
>> @@ -981,9 +987,14 @@ static void dwc3_get_properties(struct dwc3 *dwc)
>> &dwc->hsphy_interface);
>> device_property_read_u32(dev, "snps,quirk-frame-length-adjustment",
>> &dwc->fladj);
>> + dwc->num_in_eps_quirk = device_property_read_bool(dev,
>> + "snps,num_in_eps_quirk");
>> + device_property_read_u8(dev, "snps,num_in_eps_override",
>> + &num_in_eps_override);
>
> avoid the quirk flag and try like this:
>
> device_property_read_u8(...);
>
>
> num_in_eps = NUM_IN_EPS();
> num_out_eps = total - num_in_eps;
>
> if (num_out_eps == 0) {
> num_in_eps = dwc->override;
> num_out_eps = total - num_in_eps;
> }
>
> John, does this look correct to you, btw? I don't have my documentation
> right now (@home)
>
Hi Felipe, Bryan,
All endpoints as specified in DWC_USB3_NUM_EPS are bidirectional and
can be used as either IN or OUT within USB spec limits and
requirements.
DWC_USB3_NUM_IN_EPS specifies the number of EPs that can be *active*
IN EPs at any *one time*. This is limited by the number of TX FIFOs
you have instantiated in your design since each IN EP needs its own TX
FIFO.
So it is valid to have say, DWC_USB3_NUM_EPS=8 and
DWC_USB3_NUM_IN_EPS=8. Even though it is not possible to use all 8 EPs
as IN since you need at least one of them to be a control OUT. So you
could have a configuration of EP0 IN and OUT plus 6 IN EPs (total 1
OUT, 7 IN). Or EP0 IN and OUT plus any other combination of IN/OUT for
the remaining 6 EPs.
With the above in mind, you can probably just redo the endpoint number
logic in dwc3 to handle all cases without any quirks at all.
All that said, there is one further complication which is with the
DWC_USB3_EN_LOG_PHYS_EP_SUPT parameter. This is recommended to be
enabled and it is enabled by default.
If it is disabled, it will fix the physical and logical EP number and
direction of the available EPs to meet timings for FPGA designs. This
shouldn't be used in final designs for ASICS but we don't know for
sure whether it has made it to any final designs or not.
And unfortunately, whether this is set or not is not visible to the
software so it will require a quirk.
Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: [RFC v2 4/5] DT bindings documentation for Synopsys UDC platform driver
From: Florian Fainelli @ 2017-01-19 22:56 UTC (permalink / raw)
To: Scott Branden, Ray Jui, Florian Fainelli, Rob Herring,
Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4e086b59-fdca-729a-149f-85967604310f-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 01/19/2017 02:36 PM, Scott Branden wrote:
>>>> The driver stands alone from the SoC and does not need compatibility
>>>> strings per SoC. New SoCs will use the exact same block.
>>>
>>> Even if you take the exact same block and put it in a different SoC,
>>> that's still an integration work that 99% of the time goes just fine
>>> because the validation worked great, and the 1% of the time where you
>>> need to capture an integration bug, you are glad this SoC-specific
>>> compatible string exists such that you can work around it in the driver.
>>
>> That's a very conservative estimate. Based on my experience, it's more
>> like 50/50, i.e., roughly half of the time we found SoC integration
>> specific quirks or workaround are needed.
>>
> 50% is an exaggeration for sure. Maybe a driver you are has that issue
> but that is not the case with most drivers. We have many IP blocks in
> the SoC - both internal and externally sourced IP. We integrate SP805
> timer driver into many SoCs and never specify a SoC specific
> compatibility string with it (nor should we).
Well, that's a good example where in premise, each SoC vendor
integrating such a peripheral from a third party should actually have
defined its own SoC/vendor compatible string to document the
integration. And you can sometimes see some vendors having to workaround
such essential peripherals and ending-up documenting compatible strings
(or close enough in the example at [1]).
[1]: http://www.spinics.net/lists/devicetree/msg159585.html
It's a bad example though in that it's an IP that came from ARM, so the
confidence level in getting the integration right is just higher
(typically above level 9000), because ripping apart a third party is
governed by strict architecture licensing agreements that usually
prevents people suffering from the Not Invented Here syndrome from
making damage.
>
> That being said - if your driver needs to know SoC specifics is should
> not need to have an SoC specific compatibility string added per driver.
> Why can your driver just not query that information from the upper level
> SoC specific info already present in device tree?
You could do that, but that just does not happen to be a common or
recommended practice AFAICT, although I could be just wrong here of course.
>
> Each SoC is already specified in device tree at the upper level already.
> Example:
> arch/arm/boot/dts/bcm7445.dtsi has this compatibility info already
> present in its device tree:
>
> compatible = "brcm,bcm7445", "brcm,brcmstb";
>
> If needed, a driver should query this info rather than adding SoC
> specific compatibility strings to every single device tree entry.
Or you could just put it in the compatible string list for a given
peripheral, and yes, this is a repetition of information that is already
there at a higher level from that particular node, but, it has the
advantage of making all this information self contained within that
node's context, and that's a good design goal.
>
> We should only add driver revision numbers as needed, not SoC specific
> names. That way drivers don't change when the (same revision) of the IP
> block is added to a new SoCs. And then if a SoC specific workaround is
> needed the upper level compatibility string can be queried should be
> utilized. It already exists today and is available for use to all drivers.
The point is to plan ahead for information that you *may*, but *wish*
you did not need.
Quite frankly, I don't think you are going to win any argument where you
don't add a SoC compatible string to the binding, because there are tons
of precedents and good practices that suggest doing it. You might as
well just do it, it's documented, it's there, if you end up using it or
not, that's totally up to the driver author.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 v5 5/5] i2c: mux: pca954x: Add irq-mask-enable to delay enabling irqs
From: Peter Rosin @ 2017-01-19 22:56 UTC (permalink / raw)
To: Phil Reid, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <61c38233-abf2-df31-6f7c-c4214f4103aa-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
On 2017-01-19 08:48, Phil Reid wrote:
> On 18/01/2017 20:19, Peter Rosin wrote:
>> On 2017-01-17 09:00, Phil Reid wrote:
>>> Unfortunately some hardware device will assert their irq line immediately
>>> on power on and provide no mechanism to mask the irq. As the i2c muxes
>>> provide no method to mask irq line this provides a work around by keeping
>>> the parent irq masked until enough device drivers have loaded to service
>>> all pending interrupts.
>>>
>>> For example the the ltc1760 assert its SMBALERT irq immediately on power
>>> on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
>>> device is registered irq are enabled and fire continuously as the second
>>> device driver has not yet loaded. Setting this parameter to <1 1> will
>>> delay the irq being enabled until both devices are ready.
>>>
>>> Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
>>> ---
>>> drivers/i2c/muxes/i2c-mux-pca954x.c | 33 ++++++++++++++++++++++++++++++---
>>> 1 file changed, 30 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
>>> index f55da88..012b2ef 100644
>>> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
>>> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
>>> @@ -76,6 +76,19 @@ struct chip_desc {
>>> } muxtype;
>>> };
>>>
>>> +/*
>>> + * irq_mask_enable: Provides a mechanism to work around hardware that asserts
>>> + * their irq immediately on power on. It allows the enabling of the irq to be
>>> + * delayed until the corresponding bits in the the irq_mask are set thru
>>> + * irq_unmask.
>>> + * For example the ltc1760 assert its SMBALERT irq immediately on power on.
>>> + * With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
>>> + * device is registered irq are enabled and fire continuously as the second
>>> + * device driver has not yet loaded. Setting this parameter to 0x3 while
>>> + * delay the irq being enabled until both devices are ready.
>>> + * This workaround will not work if two devices share an interrupt on the
>>> + * same bus segment.
>>
>> It will also not work if something shares the interrupt with the pca954x mux,
>> on the parent side of the mux, so to speak. Then that other driver may
>> potentially enable the irq "behind the back" of the pca954x driver.
>>
>>> + */
>>> struct pca954x {
>>> const struct chip_desc *chip;
>>>
>>> @@ -84,7 +97,9 @@ struct pca954x {
>>> struct i2c_client *client;
>>>
>>> struct irq_domain *irq;
>>> + unsigned int irq_mask_enable;
>>> unsigned int irq_mask;
>>> + bool irq_enabled;
>>> spinlock_t lock;
>>> };
>>>
>>> @@ -266,8 +281,10 @@ static void pca954x_irq_mask(struct irq_data *idata)
>>> spin_lock_irqsave(&data->lock, flags);
>>>
>>> data->irq_mask &= ~BIT(pos);
>>> - if (!data->irq_mask)
>>> + if (data->irq_enabled && !data->irq_mask) {
>>> disable_irq(data->client->irq);
>>> + data->irq_enabled = false;
>>> + }
>>
>> When irq_mask_enable is non-zero, I think the parent irq should be masked
>> when the first irq from the set in irq_mask_enable is masked. For symmetry.
>>
>> Like so (untested):
>>
>> if (data->irq_enabled) {
>> if (!data->irq_mask ||
>> (data->irq_mask & mask_enable) != mask_enable) {
>> disable_irq(data->client->irq);
>> data->irq_enabled = false;
>> }
>> }
> Yeap this make sense.
>
>>
>> Hmm, this whole thing is fiddly and while it solves your problem it doesn't
>> allow for solving the more general problem when there are "problematic"
>> devices mixed with other devices. At least, I don't see it. And the
>> limitations we are walking into with tracking number of enables etc suggests
>> that we are attacking this at the wrong level. Maybe you should try to work
>> around the hw limitations not in the pca954x driver, but in the irq core?
>
> I'm looking at the option of getting the hardware changed to not route
> the irq for my chips thru the i2c mux. Fortunately the hardware is going thru a
> revision for some other changes. Messing with the irq core sounds dangerous
> with my level of knowledge.
Yeah, but I bet you'd get some attention from people with more irq
experience. That can't be bad :-)
> The other way I think I can tackle it after reading the datasheet for the ltc1760 is that
> it'll deassert it's irq (smbalert) line when the host sends a ARA request on the bus segment.
> There's a driver in the kernel for this already, but it's not DT enable and doesn't
> handle multiple bus segments. I'll have a look at that as well.
> Pretty sure it would need the mux to become an irq parent as per patch 1-3 of this series.
> This would be so the system can figure out which segment to do the poll on.
Yeah sounds neater. It has the slight drawback that it may not work
for pure i2c buses since it an SMB thing??
BTW, why do you need special treatment for multiple segments? Will it not
simply have an ARA appear on whatever i2c bus the device sits on? And if
something requests to send an ARA message on a bus that happens to be a
muxed segment, my mental picture is that the mux will be operated as usual
so that the ARA appears on the muxed segment. Maybe I'm missing something?
> But p4-5 could be dropped which is where we're stuck I think.
Yes, I dislike to add a workaround for a specific case that might get
in the way for anybody wishing to fix a bigger, more generic, problem...
> Looking at this approach it shouldn't matter if the ltc1760 driver has registered yet or not.
> This approach possibly has a lot more generic appeal I think.
>
> Thoughts on just submitting p1-3 for now while I figure out the SMB alert approach?
Yes, looks like a plan. Thanks in advance!
>> I.e. have the irq core check, for each irq, for a property that specifies
>> the depth at which each irq should be unmasked. This new property should
>> probably be located in the interrupt-controller node? Then the code can
>> unmask interrupts when the depth hits this mark, instead of always unmasking
>> the interrupt when the depth changes from zero to one. You are then adding
>> the workaround at a level where there is enough information to fix the
>> more general problem. I think?
>>
>> But, once again, I'm no irq expert and would desperately like a second
>> opinion on this stuff...
>>
>>>
>>> spin_unlock_irqrestore(&data->lock, flags);
>>> }
>>> @@ -275,14 +292,18 @@ static void pca954x_irq_mask(struct irq_data *idata)
>>> static void pca954x_irq_unmask(struct irq_data *idata)
>>> {
>>> struct pca954x *data = irq_data_get_irq_chip_data(idata);
>>> + unsigned int mask_enable = data->irq_mask_enable;
>>> unsigned int pos = idata->hwirq;
>>> unsigned long flags;
>>>
>>> spin_lock_irqsave(&data->lock, flags);
>>>
>>> - if (!data->irq_mask)
>>> - enable_irq(data->client->irq);
>>> data->irq_mask |= BIT(pos);
>>> + if (!data->irq_enabled
>>> + && (data->irq_mask & mask_enable) == mask_enable) {
>>
>> I think the coding standard says that the && should be at the end of the
>> first line. Didn't checkpatch complain?
>
> No it didn't complain. and I wasn't sure which way to do this.
Ah, you need the --strict option for that to show up...
Cheers,
peda
--
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] arm64: dts: marvell: Add DT for MACCHIATOBin board
From: Gregory CLEMENT @ 2017-01-19 23:07 UTC (permalink / raw)
To: Russell King
Cc: Rabeeh Khoury, Jon Nettleton, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cTRlf-0005dY-L8-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Hi Russell,
On mar., janv. 17 2017, Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> Add a cut-down version of the DTS file for the community board
> MACCHIATOBin from SolidRun based on Marvell Armada 8040 SoC to suit
> the current mainlined Armada 8040 state.
>
> This brings support for mainly SATA, SPI flash and UART. The USB
> descriptions are included but are not tested in this form due to the
> lack of mainline GPIO.
>
> Signed-off-by: Konstantin Porotchkin <kostap-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
> Acked-by: Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Applied on mvebu/dt
Thanks!
> ---
> This is derived from a version from Marvell, but severly cut down,
> cleaned up, re-organised and added to to suit mainline kernels. The
> only common parts are the header comment, top level model and compatible
> strings, the rest has been changed by me in some way.
>
> I'm planning to submit further patches as the mainline Armada 8k support
> moves forward.
>
> This is submitted with Rabeeh's confirmation and ack that he (as Solid
> Run's CTO) is happy for this to be upstreamed.
>
> Note - the license text is rather "interesting" but matches that which
> is already on other ARM64 Marvell-based platforms. I suspect someone at
> Free Electrons needs to talk to Marvell to correct the "library" thing,
> and clear up the "GPLv2" vs "GPLv2+" confusion in there.
Actually the "library" thing is pretty common in the
arch/arm64/boot/dts. One of the first device tree file introduced in
arm64 came with this error and then most of the people copy and paste
it. We also find it on the arm directory but the ratio is lower:
git grep "This library is free software" arch/arm/boot/dts/ | wc -l
20
git grep "This library is free software" arch/arm64 | wc -l
56
For the "GPLv2" vs "GPLv2+" confusion it is less common but not not only
on the ARM64 Marvell-based platforms some freescale are also
impacted. Actually it was first introduce from freescale where "the GPL
or the X11 license" part became "the GPLv2 or the X11 license".
I am pretty sure that this change were not intend from Marvell. But I
will clarify this with them to be able to fix it.
Gregory
>
> arch/arm64/boot/dts/marvell/Makefile | 1 +
> arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 138 ++++++++++++++++++++++
> 2 files changed, 139 insertions(+)
> create mode 100644 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
>
> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
> index 1690883b931a..3e6ce6c15a74 100644
> --- a/arch/arm64/boot/dts/marvell/Makefile
> +++ b/arch/arm64/boot/dts/marvell/Makefile
> @@ -7,6 +7,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
> +dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> new file mode 100644
> index 000000000000..b7298429ffa1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> @@ -0,0 +1,138 @@
> +/*
> + * Copyright (C) 2016 Marvell Technology Group Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/*
> + * Device Tree file for MACCHIATOBin Armada 8040 community board platform
> + */
> +
> +#include "armada-8040.dtsi"
> +
> +/ {
> + model = "Marvell 8040 MACHIATOBin";
> + compatible = "marvell,armada8040-mcbin", "marvell,armada8040",
> + "marvell,armada-ap806-quad", "marvell,armada-ap806";
> +
> + memory@00000000 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x80000000>;
> + };
> +
> + /* Regulator labels correspond with schematics */
> + v_3_3: regulator-3-3v {
> + compatible = "regulator-fixed";
> + regulator-name = "v_3_3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + status = "okay";
> + };
> +
> + v_vddo_h: regulator-1-8v {
> + compatible = "regulator-fixed";
> + regulator-name = "v_vddo_h";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + status = "okay";
> + };
> +
> + v_5v0_usb3_hst_vbus: regulator-usb3-vbus0 {
> + compatible = "regulator-fixed";
> + regulator-name = "v_5v0_usb3_hst_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + /* actually GPIO controlled, but 8k has no GPIO support yet */
> + regulator-always-on;
> + status = "okay";
> + };
> +
> + usb3h0_phy: usb3_phy0 {
> + compatible = "usb-nop-xceiv";
> + vcc-supply = <&v_5v0_usb3_hst_vbus>;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&cpm_i2c0 {
> + clock-frequency = <100000>;
> + status = "okay";
> +};
> +
> +&cpm_sata0 {
> + /* CPM Lane 0 - U29 */
> + status = "okay";
> +};
> +
> +&cpm_usb3_0 {
> + /* J38? - USB2.0 only */
> + status = "okay";
> +};
> +
> +&cpm_usb3_1 {
> + /* J38? - USB2.0 only */
> + status = "okay";
> +};
> +
> +&cps_sata0 {
> + /* CPS Lane 1 - U32 */
> + /* CPS Lane 3 - U31 */
> + status = "okay";
> +};
> +
> +&cps_spi1 {
> + status = "okay";
> +
> + spi-flash@0 {
> + compatible = "st,w25q32";
> + spi-max-frequency = <50000000>;
> + reg = <0>;
> + };
> +};
> +
> +&cps_usb3_0 {
> + /* CPS Lane 2 - CON7 */
> + usb-phy = <&usb3h0_phy>;
> + status = "okay";
> +};
> --
> 2.7.4
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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
* [PATCH v2 1/3] ARM: dts: imx6qdl: Fix "ERROR: code indent should use tabs where possible"
From: Jagan Teki @ 2017-01-19 23:09 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree, Matteo Lisi, linux-kernel, Jagan Teki,
Michael Trimarchi, linux-arm-kernel
From: Jagan Teki <jagan@amarulasolutions.com>
Fixed code indent tabs in respetcive imx6qdl dtsi files and
also add space on imx6qdl-icore-rqs.dtsi on usdhc bus-width nodes.
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- none
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi | 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index b6078b1..91991d6 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -235,7 +235,7 @@
/* VDD_1P8 (1+R1/R2 = 2.505): GPS/VideoIn/ENET-PHY */
reg_1p8v: sw2 {
- regulator-name = "vdd1p8";
+ regulator-name = "vdd1p8";
regulator-min-microvolt = <1033310>;
regulator-max-microvolt = <2004000>;
lltc,fb-voltage-divider = <301000 200000>;
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 19cf036..a208e7e 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -227,7 +227,7 @@
/* VDD_1P8 (1+R1/R2 = 2.505): GPS/VideoIn/ENET-PHY */
reg_1p8v: sw2 {
- regulator-name = "vdd1p8";
+ regulator-name = "vdd1p8";
regulator-min-microvolt = <1033310>;
regulator-max-microvolt = <2004000>;
lltc,fb-voltage-divider = <301000 200000>;
diff --git a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
index 90200fa..67613dd 100644
--- a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
@@ -162,7 +162,7 @@
/* VDD_1P8 (1+R1/R2 = 2.505): ENET-PHY */
reg_1p8v: sw2 {
- regulator-name = "vdd1p8";
+ regulator-name = "vdd1p8";
regulator-min-microvolt = <1033310>;
regulator-max-microvolt = <2004000>;
lltc,fb-voltage-divider = <301000 200000>;
diff --git a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
index d5c3aa8..6e29d8b 100644
--- a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
@@ -223,7 +223,7 @@
pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
vmcc-supply = <®_sd3_vmmc>;
cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
- bus-witdh=<4>;
+ bus-witdh = <4>;
no-1-8-v;
status = "okay";
};
@@ -234,7 +234,7 @@
pinctrl-1 = <&pinctrl_usdhc4_100mhz>;
pinctrl-2 = <&pinctrl_usdhc4_200mhz>;
vmcc-supply = <®_sd4_vmmc>;
- bus-witdh=<8>;
+ bus-witdh = <8>;
no-1-8-v;
non-removable;
status = "okay";
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: imx6ul: Add Engicam Is.IoT MX6UL eMMC initial support
From: Jagan Teki @ 2017-01-19 23:09 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel, devicetree, linux-kernel, Matteo Lisi,
Michael Trimarchi, Jagan Teki
In-Reply-To: <1484867375-22411-1-git-send-email-jagan@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Engicam Is.IoT MX6UL has separate module for eMMC, so add emmc dts
file for imx6ul-isiot.dtsi, usdhc2 node represent eMMC.
dmesg:
-----
mmc1: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
mmc1: new DDR MMC card at address 0001
mmcblk1: mmc1:0001 M62704 3.53 GiB
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Cc: Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Newly added with the reference of '[PATCH 1/2] ARM: dts: imx6ul-isiot: Add eMMC node'
arch/arm/boot/dts/Makefile | 2 +-
arch/arm/boot/dts/imx6ul-isiot-emmc.dts | 77 ++++++++++++++++++++++
.../dts/{imx6ul-isiot.dts => imx6ul-isiot.dtsi} | 3 -
3 files changed, 78 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/imx6ul-isiot-emmc.dts
rename arch/arm/boot/dts/{imx6ul-isiot.dts => imx6ul-isiot.dtsi} (97%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fa68843..f2c9545 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -435,7 +435,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
imx6ul-geam-kit.dtb \
- imx6ul-isiot.dtb \
+ imx6ul-isiot-emmc.dtb \
imx6ul-liteboard.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-isiot-emmc.dts b/arch/arm/boot/dts/imx6ul-isiot-emmc.dts
new file mode 100644
index 0000000..f5b4228
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-isiot-emmc.dts
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6ul-isiot.dtsi"
+
+/ {
+ model = "Engicam Is.IoT MX6UL eMMC Starter kit";
+ compatible = "engicam,imx6ul-isiot", "fsl,imx6ul";
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ cd-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>;
+ bus-width = <8>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x17070
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x10070
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17070
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17070
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17070
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17070
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17070
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17070
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17070
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17070
+ MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x17070
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ul-isiot.dts b/arch/arm/boot/dts/imx6ul-isiot.dtsi
similarity index 97%
rename from arch/arm/boot/dts/imx6ul-isiot.dts
rename to arch/arm/boot/dts/imx6ul-isiot.dtsi
index 077bc26..edfa0ab 100644
--- a/arch/arm/boot/dts/imx6ul-isiot.dts
+++ b/arch/arm/boot/dts/imx6ul-isiot.dtsi
@@ -47,9 +47,6 @@
#include "imx6ul.dtsi"
/ {
- model = "Engicam Is.IoT MX6UL Starter kit";
- compatible = "engicam,imx6ul-isiot", "fsl,imx6ul";
-
memory {
reg = <0x80000000 0x20000000>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: imx6ul: Add Engicam Is.IoT MX6UL NAND initial support
From: Jagan Teki @ 2017-01-19 23:09 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel, devicetree, linux-kernel, Matteo Lisi,
Michael Trimarchi, Jagan Teki
In-Reply-To: <1484867375-22411-1-git-send-email-jagan@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Engicam Is.IoT MX6UL has separate module for NAND, so add nand dts
file for imx6ul-isiot.dtsi.
dmesg:
-----
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAH4
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
gpmi-nand 1806000.gpmi-nand: driver registered.
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Cc: Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Newly added patch
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-isiot-nand.dts | 79 +++++++++++++++++++++++++++++++++
2 files changed, 80 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-isiot-nand.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f2c9545..f7340ce 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -436,6 +436,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
imx6ul-geam-kit.dtb \
imx6ul-isiot-emmc.dtb \
+ imx6ul-isiot-nand.dtb \
imx6ul-liteboard.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-isiot-nand.dts b/arch/arm/boot/dts/imx6ul-isiot-nand.dts
new file mode 100644
index 0000000..de15e1c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-isiot-nand.dts
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6ul-isiot.dtsi"
+
+/ {
+ model = "Engicam Is.IoT MX6UL NAND Starter kit";
+ compatible = "engicam,imx6ul-isiot", "fsl,imx6ul";
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_gpmi_nand: gpmi-nand {
+ fsl,pins = <
+ MX6UL_PAD_NAND_CLE__RAWNAND_CLE 0xb0b1
+ MX6UL_PAD_NAND_ALE__RAWNAND_ALE 0xb0b1
+ MX6UL_PAD_NAND_WP_B__RAWNAND_WP_B 0xb0b1
+ MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B 0xb000
+ MX6UL_PAD_NAND_CE0_B__RAWNAND_CE0_B 0xb0b1
+ MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B 0xb0b1
+ MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B 0xb0b1
+ MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00 0xb0b1
+ MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01 0xb0b1
+ MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02 0xb0b1
+ MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03 0xb0b1
+ MX6UL_PAD_NAND_DATA04__RAWNAND_DATA04 0xb0b1
+ MX6UL_PAD_NAND_DATA05__RAWNAND_DATA05 0xb0b1
+ MX6UL_PAD_NAND_DATA06__RAWNAND_DATA06 0xb0b1
+ MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07 0xb0b1
+ >;
+ };
+};
--
1.9.1
^ permalink raw reply related
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