* Re: [PATCH v6 3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
From: Simon Horman @ 2016-11-15 17:54 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <29562553.JmvzVUkhx3-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
On Mon, Oct 31, 2016 at 10:55:39PM +0300, Sergei Shtylyov wrote:
> Describe [H]SCIF{|A|B} ports in the R8A7743 device tree.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
I have queued this up after updating the indentation to use
tabs where possible.
--
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 v6 0/7] Add R8A7743/SK-RZG1M board support
From: Simon Horman @ 2016-11-15 17:54 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-renesas-soc, robh+dt, mark.rutland, devicetree, magnus.damm,
linux, linux-arm-kernel
In-Reply-To: <1746536.qobnGdHRfV@wasted.cogentembedded.com>
On Mon, Oct 31, 2016 at 10:52:25PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> Here's the set of 7 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20161031-v4.9-rc3' tag. I'm adding the device tree support for
> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
> seems identical to the R8A7791/Porter board. The device tree patches depend on
> the R8A7743 CPG/MSSR driver series in order to compile and work. Already merged
> patches from this series won't be re-posted.
>
> [1/7] ARM: dts: r8a7743: initial SoC device tree
> [2/7] ARM: dts: r8a7743: add SYS-DMAC support
> [3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
> [4/7] ARM: dts: r8a7743: add Ether support
> [5/7] ARM: dts: r8a7743: add IRQC support
> [6/7] ARM: dts: sk-rzg1m: initial device tree
> [7/7] ARM: dts: sk-rzg1m: add Ether support
Thanks, I have queued this up.
^ permalink raw reply
* Re: [PATCH v3 00/11] soc: renesas: Identify SoC and register with the SoC bus
From: Simon Horman @ 2016-11-15 17:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, Arnd Bergmann, Rob Herring, Mark Rutland, Dirk Behme,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479148637-5399-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
On Mon, Nov 14, 2016 at 07:37:06PM +0100, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> Some Renesas SoCs may exist in different revisions, providing slightly
> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> (errate and quirks). This needs to be catered for by drivers and/or
> platform code. The recently proposed soc_device_match() API is a good
> fit to handle this.
>
> This patch series implements the core infrastructure to provide SoC and
> revision information through the SoC bus for Renesas ARM SoCs.
For the record I have queued this up.
--
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/2] pinctrl: sunxi: Support the interrupt debouncing
From: Maxime Ripard @ 2016-11-15 17:50 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot
Cc: linux-gpio, devicetree, Rob Herring, Chen-Yu Tsai
In-Reply-To: <cover.fa554eb1146d18ec75bf44863543fec4fa4fd3ae.1479156725.git-series.maxime.ripard@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
On Mon, Nov 14, 2016 at 09:53:02PM +0100, Maxime Ripard wrote:
> Hi,
>
> The Allwinner pin controllers can setup a different debouncing period based
> on two clocks and a prescaler.
>
> This debouncing is applied to the whole IRQ bank, which prevents us from
> using the per-pin property that is usually used.
>
> Let me know what you think,
> Maxime
Applied the second patch.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] ARM: dts: sun7i: BPI-M1+ USB support
From: Maxime Ripard @ 2016-11-15 17:42 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161115135106.438-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
On Tue, Nov 15, 2016 at 09:51:03PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> These are the remaining patches of my BPI-M1+ fixes series from July.
>
> Changes since v1:
>
> - Split out USB PHY enable patch.
>
> - Dropped custom OPP table. Tested the A20 default one with
> cpufreq-ljt-stress-test and it seemed stable.
>
> - Dropped voltage range for cpu supply regulator to normal 1.0V ~ 1.4V.
>
> - Dropped pinmux setting for OTG ID pin.
Applied all three, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
From: Bartosz Golaszewski @ 2016-11-15 17:36 UTC (permalink / raw)
To: Jyri Sarha
Cc: linux-drm, linux-devicetree, David Airlie, daniel-/w4YWyX8dFk,
Tomi Valkeinen, Laurent Pinchart,
robdclark-Re5JQEeQqe8AvxtiuMwx3w, Kevin Hilman, Benoit Cousson
In-Reply-To: <12cd62cc9ea0f79d0f399c76bfa715125a0816ce.1479142062.git.jsarha-l0cyMroinI0@public.gmane.org>
2016-11-14 17:54 GMT+01:00 Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>:
> Adds drm bride support for attaching drm bridge drivers to tilcdc. The
> decision whether a video port leads to an external encoder or bridge
> is made simply based on remote device's compatible string. The code
> has been tested with BeagleBone-Black with and without BeagleBone
> DVI-D Cape Rev A3 using ti-tfp410 driver.
>
> Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
> ---
Hi Jyri,
thanks a lot for doing this.
One issue I see with this patch is that tilcdc doesn't seem to support
deferred probe correctly (if modules are built-in). The following
happens on my setup:
The dump-vga-dac module is loaded first, but the i2c0 is not ready yet
- probe returns EPROBE_DEFER and it's propagated to tilcdc probe.
[drm] Initialized
dumb-vga-dac vga_bridge: Couldn't retrieve i2c bus
Then the i2c bus is initialized and dump-vga-dac probe succeeds, but
the second probe of tilcdc gives me:
[drm:drm_debugfs_init] *ERROR* Cannot create /sys/kernel/debug/dri/64
[drm:drm_minor_register] *ERROR* DRM: Failed to initialize
/sys/kernel/debug/dri.
tilcdc: probe of da8xx_lcdc.0 failed with error -1
I was able to work around this issue by loading modules in correct order.
I then tried testing the patch with a da850-lcdk, but I don't get
anything on the display (no signal), even though the LCDC seems to
work fine (modetest and dmesg messages work just like when using the
tilcdc panel). Also: I see the EDID info is correctly retrieved from
the display.
Could you take a look at my DT[1] and see if you find it correct?
Best regards,
Bartosz Golaszewski
[1] http://pastebin.com/dfUX7PyL
--
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 1/9] doc: DT: vidc: binding document for Qualcomm video driver
From: Stanimir Varbanov @ 2016-11-15 17:15 UTC (permalink / raw)
To: Rob Herring, Stanimir Varbanov
Cc: Mauro Carvalho Chehab, Hans Verkuil, Andy Gross, Bjorn Andersson,
Stephen Boyd, Srinivas Kandagatla, linux-media, linux-kernel,
linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20161114170410.56izii5gcwpofvc4@rob-hp-laptop>
Hi Rob,
Thanks for the comments!
On 11/14/2016 07:04 PM, Rob Herring wrote:
> On Mon, Nov 07, 2016 at 07:33:55PM +0200, Stanimir Varbanov wrote:
>> Add binding document for Venus video encoder/decoder driver
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>> ---
>> .../devicetree/bindings/media/qcom,venus.txt | 98 ++++++++++++++++++++++
>> 1 file changed, 98 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> new file mode 100644
>> index 000000000000..b2af347fbce4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> @@ -0,0 +1,98 @@
>> +* Qualcomm Venus video encode/decode accelerator
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Value should contain one of:
>> + - "qcom,venus-msm8916"
>> + - "qcom,venus-msm8996"
>
> The normal ordering is <vendor>,<soc>-<block>
OK.
>
>> +- reg:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: Register ranges as listed in the reg-names property.
>> +- reg-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain following entries:
>> + - "venus" Venus register base
>> +- reg-names:
>
> I'd prefer these grouped as one entry for reg-names.
>
>> + Usage: optional for msm8996
>
> Why optional?
The Venus hw block can work without internal video memory in which case
just performance will be impacted.
>
>> + Value type: <stringlist>
>> + Definition: Should contain following entries:
>> + - "vmem" Video memory register base
>> +- interrupts:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: Should contain interrupts as listed in the interrupt-names
>> + property.
>> +- interrupt-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain following entries:
>> + - "venus" Venus interrupt line
>> +- interrupt-names:
>> + Usage: optional for msm8996
>> + Value type: <stringlist>
>> + Definition: Should contain following entries:
>> + - "vmem" Video memory interrupt line
>> +- clocks:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: A List of phandle and clock specifier pairs as listed
>> + in clock-names property.
>> +- clock-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain the following entries:
>> + - "core" Core video accelerator clock
>> + - "iface" Video accelerator AHB clock
>> + - "bus" Video accelerator AXI clock
>> +- clock-names:
>> + Usage: required for msm8996
>
> Plus the 3 above?
Yes, 'required' without 'for xxx' means that the clocks are required for
all hw versions (SoCs) and msm8996 needs the extra clocks below.
>
>> + Value type: <stringlist>
>> + Definition: Should contain the following entries:
>> + - "subcore0" Subcore0 video accelerator clock
>> + - "subcore1" Subcore1 video accelerator clock
>> + - "mmssnoc_axi" Multimedia subsystem NOC AXI clock
>> + - "mmss_mmagic_iface" Multimedia subsystem MMAGIC AHB clock
>> + - "mmss_mmagic_mbus" Multimedia subsystem MMAGIC MAXI clock
>> + - "mmagic_video_bus" MMAGIC video AXI clock
>> + - "video_mbus" Video MAXI clock
>> +- clock-names:
>> + Usage: optional for msm8996
>
> Clocks shouldn't be optional unless you failed to add in an initial
> binding.
These clocks are needed by video memory block which I noted as
'optional'. There is another way to model this video memory hw block
i.e. by a child node of the venus node. Is that sounds better?
<snip>
--
regards,
Stan
^ permalink raw reply
* Re: [PATCH 1/2] regulator: pwm: DT: Add ramp delay for exponential voltage transition
From: Laxman Dewangan @ 2016-11-15 17:13 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Brown, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Douglas Anderson, Aleksandr Frid
In-Reply-To: <CAL_Jsq+=oyRC7ZPcva_B6CB_vCquzpRw0UU=nfdjxEbzkKjiVw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tuesday 15 November 2016 07:57 PM, Rob Herring wrote:
> On Tue, Nov 15, 2016 at 5:42 AM, Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On Monday 14 November 2016 09:18 PM, Rob Herring wrote:
>>> On Fri, Nov 04, 2016 at 11:07:54PM +0530, Laxman Dewangan wrote:
>>>>
>>>> regulator
>>>> +- pwm-regulator-voltage-ramp-time-us: Integer, voltage ramp time in
>>> This is a really long name. Drop the 'pwm-regulator-' part as it is
>>> redundant. The fact that it is PWM reg specific is captured as it is
>>> documented that way.
>>>
>> We already have the regulator-ramp-delay from the regulator core.
>> Just wanted to make this (pwm-regulator-voltage-ramp-time-us) for pwm
>> specific.
> Neither of these are very clear that one is linear and one is
> exponential. Maybe you should use the existing property to express the
> time and just add a boolean property like "voltage-ramp-exponential"?
OK, this can work.
--
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/5] pinctrl: core: Use delayed work for hogs
From: Tony Lindgren @ 2016-11-15 17:08 UTC (permalink / raw)
To: Linus Walleij
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161115154124.GI4082@atomide.com>
* Tony Lindgren <tony@atomide.com> [161115 07:42]:
> * Linus Walleij <linus.walleij@linaro.org> [161114 22:53]:
> > On Tue, Nov 15, 2016 at 1:47 AM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > > 8< --------------------------------
> > > From tony Mon Sep 17 00:00:00 2001
> > > From: Tony Lindgren <tony@atomide.com>
> > > Date: Tue, 25 Oct 2016 08:33:35 -0700
> > > Subject: [PATCH] pinctrl: core: Use delayed work for hogs
> > >
> > > Having the pin control framework call pin controller functions
> > > before it's probe has finished is not nice as the pin controller
> > > device driver does not yet have struct pinctrl_dev handle.
> > >
> > > Let's fix this issue by adding deferred work for late init. This is
> > > needed to be able to add pinctrl generic helper functions that expect
> > > to know struct pinctrl_dev handle. Note that we now need to call
> > > create_pinctrl() directly as we don't want to add the pin controller
> > > to the list of controllers until the hogs are claimed. We also need
> > > to pass the pinctrl_dev to the device tree parser functions as they
> > > otherwise won't find the right controller at this point.
> > >
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > This looks a lot better!
> >
> > So if I understand correctly, we can guarantee that the delayed
> > work will not execute until the device driver probe() has finished,
> > and it *will* execute immediately after that?
> >
> > So:
> > - Device driver probes
> > - Delayed work is called
> > - Next initcall
> >
> > I'm not 100% familiar with how delayed work works... :/
>
> Yeah well the delayed work gets scheduled for next jiffy but may
> be pre-empted as it runs in process context.
>
> So in the worst case it could that we still may need to fix few
> drivers to support -EPROBE_DEFER. I wonder if we should check for
> hogs in probe already and only defer if hogs are defined?
Below is a version using delayed_work only if pinctrl_dt_has_hogs().
Not sure if testing only for pinctrl-0 is enough there though?
Regards,
Tony
8< --------------------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 25 Oct 2016 08:33:35 -0700
Subject: [PATCH] pinctrl: core: Use delayed work for hogs
Having the pin control framework call pin controller functions
before it's probe has finished is not nice as the pin controller
device driver does not yet have struct pinctrl_dev handle.
Let's fix this issue by adding deferred work for late init. This is
needed to be able to add pinctrl generic helper functions that expect
to know struct pinctrl_dev handle. Note that we now need to call
create_pinctrl() directly as we don't want to add the pin controller
to the list of controllers until the hogs are claimed. We also need
to pass the pinctrl_dev to the device tree parser functions as they
otherwise won't find the right controller at this point.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/pinctrl/core.c | 90 ++++++++++++++++++++++++++++----------------
drivers/pinctrl/core.h | 2 +
drivers/pinctrl/devicetree.c | 28 +++++++++++---
drivers/pinctrl/devicetree.h | 12 +++++-
4 files changed, 93 insertions(+), 39 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -720,7 +720,8 @@ static struct pinctrl_state *create_state(struct pinctrl *p,
return state;
}
-static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
+static int add_setting(struct pinctrl *p, struct pinctrl_dev *pctldev,
+ struct pinctrl_map const *map)
{
struct pinctrl_state *state;
struct pinctrl_setting *setting;
@@ -744,7 +745,11 @@ static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
setting->type = map->type;
- setting->pctldev = get_pinctrl_dev_from_devname(map->ctrl_dev_name);
+ if (pctldev)
+ setting->pctldev = pctldev;
+ else
+ setting->pctldev =
+ get_pinctrl_dev_from_devname(map->ctrl_dev_name);
if (setting->pctldev == NULL) {
kfree(setting);
/* Do not defer probing of hogs (circular loop) */
@@ -800,7 +805,8 @@ static struct pinctrl *find_pinctrl(struct device *dev)
static void pinctrl_free(struct pinctrl *p, bool inlist);
-static struct pinctrl *create_pinctrl(struct device *dev)
+static struct pinctrl *create_pinctrl(struct device *dev,
+ struct pinctrl_dev *pctldev)
{
struct pinctrl *p;
const char *devname;
@@ -823,7 +829,7 @@ static struct pinctrl *create_pinctrl(struct device *dev)
INIT_LIST_HEAD(&p->states);
INIT_LIST_HEAD(&p->dt_maps);
- ret = pinctrl_dt_to_map(p);
+ ret = pinctrl_dt_to_map(p, pctldev);
if (ret < 0) {
kfree(p);
return ERR_PTR(ret);
@@ -838,7 +844,7 @@ static struct pinctrl *create_pinctrl(struct device *dev)
if (strcmp(map->dev_name, devname))
continue;
- ret = add_setting(p, map);
+ ret = add_setting(p, pctldev, map);
/*
* At this point the adding of a setting may:
*
@@ -899,7 +905,7 @@ struct pinctrl *pinctrl_get(struct device *dev)
return p;
}
- return create_pinctrl(dev);
+ return create_pinctrl(dev, NULL);
}
EXPORT_SYMBOL_GPL(pinctrl_get);
@@ -1738,6 +1744,46 @@ static int pinctrl_check_ops(struct pinctrl_dev *pctldev)
}
/**
+ * pinctrl_late_init() - finish pin controller device registration
+ * @work: work struct
+ */
+static void pinctrl_late_init(struct work_struct *work)
+{
+ struct pinctrl_dev *pctldev;
+
+ pctldev = container_of(work, struct pinctrl_dev, late_init.work);
+
+ pctldev->p = create_pinctrl(pctldev->dev, pctldev);
+ if (!IS_ERR(pctldev->p)) {
+ kref_get(&pctldev->p->users);
+ pctldev->hog_default =
+ pinctrl_lookup_state(pctldev->p, PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(pctldev->hog_default)) {
+ dev_dbg(pctldev->dev,
+ "failed to lookup the default state\n");
+ } else {
+ if (pinctrl_select_state(pctldev->p,
+ pctldev->hog_default))
+ dev_err(pctldev->dev,
+ "failed to select default state\n");
+ }
+
+ pctldev->hog_sleep =
+ pinctrl_lookup_state(pctldev->p,
+ PINCTRL_STATE_SLEEP);
+ if (IS_ERR(pctldev->hog_sleep))
+ dev_dbg(pctldev->dev,
+ "failed to lookup the sleep state\n");
+ }
+
+ mutex_lock(&pinctrldev_list_mutex);
+ list_add_tail(&pctldev->node, &pinctrldev_list);
+ mutex_unlock(&pinctrldev_list_mutex);
+
+ pinctrl_init_device_debugfs(pctldev);
+}
+
+/**
* pinctrl_register() - register a pin controller device
* @pctldesc: descriptor for this pin controller
* @dev: parent device for this pin controller
@@ -1766,6 +1812,7 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
pctldev->driver_data = driver_data;
INIT_RADIX_TREE(&pctldev->pin_desc_tree, GFP_KERNEL);
INIT_LIST_HEAD(&pctldev->gpio_ranges);
+ INIT_DELAYED_WORK(&pctldev->late_init, pinctrl_late_init);
pctldev->dev = dev;
mutex_init(&pctldev->mutex);
@@ -1800,32 +1847,10 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
goto out_err;
}
- mutex_lock(&pinctrldev_list_mutex);
- list_add_tail(&pctldev->node, &pinctrldev_list);
- mutex_unlock(&pinctrldev_list_mutex);
-
- pctldev->p = pinctrl_get(pctldev->dev);
-
- if (!IS_ERR(pctldev->p)) {
- pctldev->hog_default =
- pinctrl_lookup_state(pctldev->p, PINCTRL_STATE_DEFAULT);
- if (IS_ERR(pctldev->hog_default)) {
- dev_dbg(dev, "failed to lookup the default state\n");
- } else {
- if (pinctrl_select_state(pctldev->p,
- pctldev->hog_default))
- dev_err(dev,
- "failed to select default state\n");
- }
-
- pctldev->hog_sleep =
- pinctrl_lookup_state(pctldev->p,
- PINCTRL_STATE_SLEEP);
- if (IS_ERR(pctldev->hog_sleep))
- dev_dbg(dev, "failed to lookup the sleep state\n");
- }
-
- pinctrl_init_device_debugfs(pctldev);
+ if (pinctrl_dt_has_hogs(pctldev))
+ schedule_delayed_work(&pctldev->late_init, 0);
+ else
+ pinctrl_late_init(&pctldev->late_init.work);
return pctldev;
@@ -1848,6 +1873,7 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
if (pctldev == NULL)
return;
+ cancel_delayed_work_sync(&pctldev->late_init);
mutex_lock(&pctldev->mutex);
pinctrl_remove_device_debugfs(pctldev);
mutex_unlock(&pctldev->mutex);
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -33,6 +33,7 @@ struct pinctrl_gpio_range;
* @p: result of pinctrl_get() for this device
* @hog_default: default state for pins hogged by this device
* @hog_sleep: sleep state for pins hogged by this device
+ * @late_init: delayed work for pin controller to finish registration
* @mutex: mutex taken on each pin controller specific action
* @device_root: debugfs root for this device
*/
@@ -47,6 +48,7 @@ struct pinctrl_dev {
struct pinctrl *p;
struct pinctrl_state *hog_default;
struct pinctrl_state *hog_sleep;
+ struct delayed_work late_init;
struct mutex mutex;
#ifdef CONFIG_DEBUG_FS
struct dentry *device_root;
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -100,11 +100,12 @@ struct pinctrl_dev *of_pinctrl_get(struct device_node *np)
return get_pinctrl_dev_from_of_node(np);
}
-static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
+static int dt_to_map_one_config(struct pinctrl *p,
+ struct pinctrl_dev *pctldev,
+ const char *statename,
struct device_node *np_config)
{
struct device_node *np_pctldev;
- struct pinctrl_dev *pctldev;
const struct pinctrl_ops *ops;
int ret;
struct pinctrl_map *map;
@@ -121,7 +122,8 @@ static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
/* OK let's just assume this will appear later then */
return -EPROBE_DEFER;
}
- pctldev = get_pinctrl_dev_from_of_node(np_pctldev);
+ if (!pctldev)
+ pctldev = get_pinctrl_dev_from_of_node(np_pctldev);
if (pctldev)
break;
/* Do not defer probing of hogs (circular loop) */
@@ -166,7 +168,22 @@ static int dt_remember_dummy_state(struct pinctrl *p, const char *statename)
return dt_remember_or_free_map(p, statename, NULL, map, 1);
}
-int pinctrl_dt_to_map(struct pinctrl *p)
+bool pinctrl_dt_has_hogs(struct pinctrl_dev *pctldev)
+{
+ struct device_node *np;
+ struct property *prop;
+ int size;
+
+ np = pctldev->dev->of_node;
+ if (!np)
+ return false;
+
+ prop = of_find_property(np, "pinctrl-0", &size);
+
+ return prop ? true : false;
+}
+
+int pinctrl_dt_to_map(struct pinctrl *p, struct pinctrl_dev *pctldev)
{
struct device_node *np = p->dev->of_node;
int state, ret;
@@ -233,7 +250,8 @@ int pinctrl_dt_to_map(struct pinctrl *p)
}
/* Parse the node */
- ret = dt_to_map_one_config(p, statename, np_config);
+ ret = dt_to_map_one_config(p, pctldev, statename,
+ np_config);
of_node_put(np_config);
if (ret < 0)
goto err;
diff --git a/drivers/pinctrl/devicetree.h b/drivers/pinctrl/devicetree.h
--- a/drivers/pinctrl/devicetree.h
+++ b/drivers/pinctrl/devicetree.h
@@ -20,8 +20,10 @@ struct of_phandle_args;
#ifdef CONFIG_OF
+bool pinctrl_dt_has_hogs(struct pinctrl_dev *pctldev);
+
void pinctrl_dt_free_maps(struct pinctrl *p);
-int pinctrl_dt_to_map(struct pinctrl *p);
+int pinctrl_dt_to_map(struct pinctrl *p, struct pinctrl_dev *pctldev);
int pinctrl_count_index_with_args(const struct device_node *np,
const char *list_name);
@@ -32,7 +34,13 @@ int pinctrl_parse_index_with_args(const struct device_node *np,
#else
-static inline int pinctrl_dt_to_map(struct pinctrl *p)
+static inline bool pinctrl_dt_has_hogs(struct pinctrl_dev *pctldev)
+{
+ return false;
+}
+
+static inline int pinctrl_dt_to_map(struct pinctrl *p,
+ struct pinctrl_dev *pctldev)
{
return 0;
}
--
2.10.2
^ permalink raw reply
* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Florian Fainelli @ 2016-11-15 17:03 UTC (permalink / raw)
To: Andrew Lunn, Jerome Brunet
Cc: netdev, devicetree, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161115163036.GB23231@lunn.ch>
On 11/15/2016 08:30 AM, Andrew Lunn wrote:
> On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote:
>> On some platforms, energy efficient ethernet with rtl8211 devices is
>> causing issue, like throughput drop or broken link.
>>
>> This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root
>> cause is not fully understood yet, disabling EEE advertisement prevent auto
>> negotiation from enabling EEE.
>>
>> This patch provides options to disable 1000T and 100TX EEE advertisement
>> individually for the realtek phys supporting this feature.
>
> Looking at the code, i don't see anything specific to RealTek
> here. This all seems generic. So should it be in phy.c and made a
> generic OF property which can be applied to any PHY which supports
> EEE.
Agreed. Just to be sure, Jerome, you did verify that with EEE no longer
advertised, ethtool --set-eee fails, right? The point is that you may be
able to disable EEE on boot, but if there is a way to re-enable it later
on, we would want to disable that too.
--
Florian
^ permalink raw reply
* Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-15 16:36 UTC (permalink / raw)
To: Rob Herring, Olof Johansson
Cc: Sudeep Holla, Neil Armstrong,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-amlogic
In-Reply-To: <4e31f1d9-61b9-53a9-bd0c-dd5e452faece@arm.com>
On 11/11/16 14:19, Sudeep Holla wrote:
>
>
> On 11/11/16 13:34, Rob Herring wrote:
>> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
[...]
>>>
>>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>>
>> That's still meaningless. Convince me that multiple implementations
>> are identical, then we can have a common property. For example, how
>> many releases did ARM make before 1.0.
>>
>
> None officially, so I tend to agree with you on this.
>
> But so far we have seen some commonality between Rockchip and Amlogic
> implementations, which in fact shares some commonality with early
> release of SCPI from ARM (there are based on the same SCP code base,
> which is closed source and released to partners only). ARM improved the
> specification and the code base before the official release but by then
> it was adopted(as usual we were late ;))
>
> IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
> and platform specific "amlogic,meson-gxbb-scpi"
>
Rob and Olof, is it convincing enough reason to have generic compatible?
Or you prefer to drop it ?
I prefer to have "arm,scpi-pre-1.0". IMO it's useful, let me know. I
need to send PR as it's getting late now.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Andrew Lunn @ 2016-11-15 16:30 UTC (permalink / raw)
To: Jerome Brunet
Cc: netdev, devicetree, Florian Fainelli, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <1479220154-25851-2-git-send-email-jbrunet@baylibre.com>
On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote:
> On some platforms, energy efficient ethernet with rtl8211 devices is
> causing issue, like throughput drop or broken link.
>
> This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root
> cause is not fully understood yet, disabling EEE advertisement prevent auto
> negotiation from enabling EEE.
>
> This patch provides options to disable 1000T and 100TX EEE advertisement
> individually for the realtek phys supporting this feature.
Looking at the code, i don't see anything specific to RealTek
here. This all seems generic. So should it be in phy.c and made a
generic OF property which can be applied to any PHY which supports
EEE.
Andrew
^ permalink raw reply
* Re: [PATCH v4 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Stanimir Varbanov @ 2016-11-15 16:30 UTC (permalink / raw)
To: Srinivas Kandagatla, linux-pci-u79uwXL29TY76Z2rM5mHXA,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8d0e9b19-5d6f-8be5-84be-d102817a6b21-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 11/15/2016 06:10 PM, Srinivas Kandagatla wrote:
>
>
> On 15/11/16 15:08, Stanimir Varbanov wrote:
>>>> I don't like MSM8996_ prefix. Could you invent a macro which depending
>>>> >> on controller selects proper offset?
>>> >
>>> > maybe some like this ??
>>> >
>>> > #define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2 0x1A8
>> No, I wanted to preserve the name of the register offset. By that way in
>> the next pcie controller version we do not need to have
>> PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V3.
>>
>> I was thinking for something like
>>
>> PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT(ver) \
>> ((ver) == VERSION_1 ? 0x178 : 0x1A8)
>>
>> But you will need to extend qcom_pcie_ops with new member to store the
>> version.
>>
>> It's up to you ... or we can fix it when new version of the controller
>> appear.
> TBH, I don't want to add this just for this one case, looks bit over do.
> So I skipped to using V2 Suffix.
> We can fix later if required.
OK, sounds good.
regards,
Stan
--
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] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Tejun Heo @ 2016-11-15 16:21 UTC (permalink / raw)
To: Rameshwar Sahu
Cc: Olof Johansson, linux-scsi, linux-ide, Devicetree List, linux-arm,
Don Dutile, Jon Masters, patches
In-Reply-To: <CAFd313ycmpdp7wHCVRJrigJV31hLwBGOo=FNENwgFnNKyVkQBA@mail.gmail.com>
Hello, Rameshwar.
On Fri, Nov 11, 2016 at 01:36:28PM +0530, Rameshwar Sahu wrote:
> Hi Tejun,
>
> On Wed, Nov 9, 2016 at 10:15 PM, Tejun Heo <tj@kernel.org> wrote:
> > Hello,
> >
> > On Wed, Sep 14, 2016 at 04:15:00PM +0530, Rameshwar Sahu wrote:
> >> > @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device
> >> > *pdev)
> >> > dev_warn(&pdev->dev, "%s: Error reading
> >> > device info. Assume version1\n",
> >> > __func__);
> >> > version = XGENE_AHCI_V1;
> >> > - } else if (info->valid & ACPI_VALID_CID) {
> >> > - version = XGENE_AHCI_V2;
> >
> > Can you please explain this part a bit? Everything else looks good to
> > me.
>
> Here we should not assume XGENE_AHCI_V2 always in case of having valid
> _CID in ACPI table.
> I need to remove this assumption because V1_1 has also valid _CID for
> backward compatibly with v1.
Can you please repost with the above explanation added to the commit
message?
Thanks!
--
tejun
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: hisi: hip06 SAS device tree fixes
From: Wei Xu @ 2016-11-15 16:12 UTC (permalink / raw)
To: John Garry
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Hi John,
On 2016/11/7 16:44, John Garry wrote:
> This patchset resolves some hip06 SAS device tree issues.
>
Series applied to the hisilicon soc tree.
Thanks!
Best Regards,
Wei
> John Garry (3):
> arm64: dts: hisi: fix hip06 sas am-max-trans quirk
> arm64: dts: hisi: disable sas0 and sas2 for d03
> arm64: dts: hisi: add refclk node to hip06 dts files for SAS
>
> arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 --------
> arch/arm64/boot/dts/hisilicon/hip06.dtsi | 11 ++++++++++-
> 2 files changed, 10 insertions(+), 9 deletions(-)
>
--
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 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Srinivas Kandagatla @ 2016-11-15 16:10 UTC (permalink / raw)
To: Stanimir Varbanov, linux-pci-u79uwXL29TY76Z2rM5mHXA,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <ea5858f3-19d6-c746-2e95-a64d6a436b38-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
On 15/11/16 15:08, Stanimir Varbanov wrote:
>>> I don't like MSM8996_ prefix. Could you invent a macro which depending
>>> >> on controller selects proper offset?
>> >
>> > maybe some like this ??
>> >
>> > #define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2 0x1A8
> No, I wanted to preserve the name of the register offset. By that way in
> the next pcie controller version we do not need to have
> PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V3.
>
> I was thinking for something like
>
> PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT(ver) \
> ((ver) == VERSION_1 ? 0x178 : 0x1A8)
>
> But you will need to extend qcom_pcie_ops with new member to store the
> version.
>
> It's up to you ... or we can fix it when new version of the controller
> appear.
TBH, I don't want to add this just for this one case, looks bit over do.
So I skipped to using V2 Suffix.
We can fix later if required.
--srini
--
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 v7 2/5] mm: remove x86-only restriction of movable_node
From: Reza Arbab @ 2016-11-15 15:57 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, linuxppc-dev, linux-mm, devicetree,
Bharata B Rao, Nathan Fontenot, Stewart Smith, Alistair Popple,
Balbir Singh, linux-kernel
In-Reply-To: <87lgwlb4u1.fsf@linux.vnet.ibm.com>
On Tue, Nov 15, 2016 at 12:35:42PM +0530, Aneesh Kumar K.V wrote:
>Considering that we now can mark memblock hotpluggable, do we need to
>enable the bottom up allocation for ppc64 also ?
No, we don't, because early_init_dt_scan_memory() marks the memblocks
hotpluggable immediately when they are added. There is no gap between
the addition and the marking, as there is on x86, during which an
allocation might accidentally occur in a movable node.
--
Reza Arbab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 2/2] ARM: zynq: Fix W=1 dtc 1.4 warnings
From: Julia Cartwright @ 2016-11-15 15:46 UTC (permalink / raw)
To: Michal Simek
Cc: linux-arm-kernel, S?ren Brinkmann, devicetree, monstr,
Steffen Trumtrar, linux-kernel, Peter Crosthwaite, Rob Herring,
Rob Herring, Mark Rutland, Russell King
In-Reply-To: <90eca8dfcdcef68ce5fe39f2329c4b61d2662598.1479218844.git.michal.simek@xilinx.com>
On Tue, Nov 15, 2016 at 03:07:27PM +0100, Michal Simek wrote:
> The patch removes these warnings reported by dtc 1.4:
> Warning (unit_address_vs_reg): Node /pmu has a reg or ranges property,
> but no unit name
> Warning (unit_address_vs_reg): Node /fixedregulator@0 has a unit name,
> but no reg property
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges
> property, but no unit name
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Julia Cartwright <julia@ni.com>
>
> ---
>
> arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
> arch/arm/boot/dts/zynq-parallella.dts | 2 +-
> arch/arm/boot/dts/zynq-zc702.dts | 2 +-
> arch/arm/boot/dts/zynq-zc706.dts | 2 +-
> arch/arm/boot/dts/zynq-zed.dts | 2 +-
> arch/arm/boot/dts/zynq-zybo.dts | 2 +-
> 6 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
> index f47a6c1cc752..402b5bbe3b5b 100644
> --- a/arch/arm/boot/dts/zynq-7000.dtsi
> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> @@ -42,14 +42,14 @@
> };
> };
>
> - pmu {
> + pmu@f8891000 {
> compatible = "arm,cortex-a9-pmu";
> interrupts = <0 5 4>, <0 6 4>;
> interrupt-parent = <&intc>;
> reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
Style nit: we should drop the space before/after '<' and '>'; and,
perhaps separate the entries to be a bit more readable:
reg = <0xf8891000 0x1000>,
<0xf8893000 0x1000>;
Thanks,
Julia
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding
From: Thierry Reding @ 2016-11-15 15:46 UTC (permalink / raw)
To: Stephen Warren
Cc: Joseph Lo, Rob Herring, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
MLongnecker-DDmLM1+adcrQT0dZR+AlfA,
sivaramn-DDmLM1+adcrQT0dZR+AlfA,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA, Stephen Warren
In-Reply-To: <20160719191442.15439-3-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]
On Tue, Jul 19, 2016 at 01:14:42PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
> HW devices, such as the I2C controller for the power management I2C bus.
> Software running on other CPUs must perform IPC to the BPMP in order to
> execute transactions on that I2C bus. This binding describes an I2C bus
> that is accessed in such a fashion.
>
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
I ended up cherry-picking this commit from U-Boot, which already had
both of the comments addressed that were discussed here. I also took the
liberty of adding Jon's Acked-by from this thread since it's effectively
the same commit.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ARM: zynq: Remove skeleton.dtsi
From: Julia Cartwright @ 2016-11-15 15:43 UTC (permalink / raw)
To: Michal Simek
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
S?ren Brinkmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
monstr-pSz03upnqPeHXe+LvDLADg, Steffen Trumtrar,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Peter Crosthwaite,
Rob Herring, Rob Herring, Mark Rutland, Russell King
In-Reply-To: <2d42e25d7dd03e562e12e71fd037837737115940.1479218844.git.michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
On Tue, Nov 15, 2016 at 03:07:26PM +0100, Michal Simek wrote:
> Based on
> "ARM: dts: explicitly mark skeleton.dtsi as deprecated"
> (sha1: 9c0da3cc61f1233c2782e2d3d91e3d0707dd4ba5)
> skeleton.dtsi is deprecated.
> Move address and size-cells directly to zynq-7000.dtsi.
>
> Signed-off-by: Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Julia Cartwright <julia-acOepvfBmUk@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: [PATCH v3 2/2] arm64: dts: rockchip: add usb2-phy otg-port support for rk3399
From: Heiko Stuebner @ 2016-11-15 15:43 UTC (permalink / raw)
To: William Wu
Cc: kishon-l0cyMroinI0, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frank.wang-TNX95d0MmH7DzftRWevZcw,
huangtao-TNX95d0MmH7DzftRWevZcw, dianders-hpIqsD4AKlfQT0dZR+AlfA,
briannorris-hpIqsD4AKlfQT0dZR+AlfA, groeck-hpIqsD4AKlfQT0dZR+AlfA
In-Reply-To: <1478520529-8869-3-git-send-email-wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Montag, 7. November 2016, 20:08:49 CET schrieb William Wu:
> Add otg-port nodes for both u2phy0 and u2phy1. The otg-port can
> be used for USB2.0 part of USB3.0 OTG controller.
>
> Signed-off-by: William Wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> Changes in v3:
> - None
>
> Changes in v2:
> - None
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index b65c193..ea2df51 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1095,6 +1095,17 @@
> clock-output-names = "clk_usbphy0_480m";
> status = "disabled";
>
> + u2phy0_otg: otg-port {
> + #phy-cells = <0>;
> + interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH 0>,
> + <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH 0>,
> + <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH 0>;
> + interrupt-names = "otg-bvalid", "otg-id",
> + "linestate";
> + status = "disabled";
> + };
> +
> +
applied to my dts64 branch after removing that double empty line and also
switching host and otg sub nodes to get alphabetical sorting.
Thanks
Heiko
--
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 2/3] dt-bindings: allow child nodes inside the Tegra BPMP
From: Thierry Reding @ 2016-11-15 15:42 UTC (permalink / raw)
To: Stephen Warren
Cc: Joseph Lo, Rob Herring, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
MLongnecker-DDmLM1+adcrQT0dZR+AlfA,
sivaramn-DDmLM1+adcrQT0dZR+AlfA,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA, Stephen Warren
In-Reply-To: <20160719191442.15439-2-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> The BPMP implements some services which must be represented by separate
> nodes. For example, it can provide access to certain I2C controllers, and
> the I2C bindings represent each I2C controller as a device tree node.
> Update the binding to describe how the BPMP supports this.
>
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../bindings/firmware/nvidia,tegra186-bpmp.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
Applied, with bpmp-i2c changed to i2c as per Rob's comment.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Tony Lindgren @ 2016-11-15 15:41 UTC (permalink / raw)
To: Linus Walleij
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <CACRpkdZ=pifhHrH_-466f2x3Ev4GKW0CCnTj1hL5Hfpdj5p-1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161114 22:53]:
> On Tue, Nov 15, 2016 at 1:47 AM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
>
> > 8< --------------------------------
> > From tony Mon Sep 17 00:00:00 2001
> > From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > Date: Tue, 25 Oct 2016 08:33:35 -0700
> > Subject: [PATCH] pinctrl: core: Use delayed work for hogs
> >
> > Having the pin control framework call pin controller functions
> > before it's probe has finished is not nice as the pin controller
> > device driver does not yet have struct pinctrl_dev handle.
> >
> > Let's fix this issue by adding deferred work for late init. This is
> > needed to be able to add pinctrl generic helper functions that expect
> > to know struct pinctrl_dev handle. Note that we now need to call
> > create_pinctrl() directly as we don't want to add the pin controller
> > to the list of controllers until the hogs are claimed. We also need
> > to pass the pinctrl_dev to the device tree parser functions as they
> > otherwise won't find the right controller at this point.
> >
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>
> This looks a lot better!
>
> So if I understand correctly, we can guarantee that the delayed
> work will not execute until the device driver probe() has finished,
> and it *will* execute immediately after that?
>
> So:
> - Device driver probes
> - Delayed work is called
> - Next initcall
>
> I'm not 100% familiar with how delayed work works... :/
Yeah well the delayed work gets scheduled for next jiffy but may
be pre-empted as it runs in process context.
So in the worst case it could that we still may need to fix few
drivers to support -EPROBE_DEFER. I wonder if we should check for
hogs in probe already and only defer if hogs are defined?
Regards,
Tony
--
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: add power domains to Tegra BPMP firmware
From: Thierry Reding @ 2016-11-15 15:39 UTC (permalink / raw)
To: Stephen Warren
Cc: Joseph Lo, Rob Herring, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
MLongnecker-DDmLM1+adcrQT0dZR+AlfA,
sivaramn-DDmLM1+adcrQT0dZR+AlfA,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA, Stephen Warren
In-Reply-To: <20160719191442.15439-1-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]
On Tue, Jul 19, 2016 at 01:14:40PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> The Tegra186 BPMP is also a provider of power domains. Enhance the device
> tree binding to describe this.
>
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> These patches all build on top of Joseph Lo's baseline BPMP binding patches[1]
> and enhance them to represent a few more features of the firmware.
>
> [1] https://lkml.org/lkml/2016/7/19/280
> "[PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox"
>
> .../bindings/firmware/nvidia,tegra186-bpmp.txt | 10 ++++--
> include/dt-bindings/power/tegra186-powergate.h | 39 ++++++++++++++++++++++
> 2 files changed, 46 insertions(+), 3 deletions(-)
> create mode 100644 include/dt-bindings/power/tegra186-powergate.h
Applied, thanks.
One small comment below...
> diff --git a/include/dt-bindings/power/tegra186-powergate.h b/include/dt-bindings/power/tegra186-powergate.h
> new file mode 100644
> index 000000000000..388d6e228dc8
> --- /dev/null
> +++ b/include/dt-bindings/power/tegra186-powergate.h
> @@ -0,0 +1,39 @@
> +/*
> + * Copyright (c) 2015-2016, NVIDIA CORPORATION. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
> +#define _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
> +
> +#define TEGRA186_POWER_DOMAIN_AUD 0
> +#define TEGRA186_POWER_DOMAIN_DFD 1
> +#define TEGRA186_POWER_DOMAIN_DISP 2
> +#define TEGRA186_POWER_DOMAIN_DISPB 3
> +#define TEGRA186_POWER_DOMAIN_DISPC 4
> +#define TEGRA186_POWER_DOMAIN_ISPA 5
> +#define TEGRA186_POWER_DOMAIN_NVDEC 6
> +#define TEGRA186_POWER_DOMAIN_NVJPG 7
> +#define TEGRA186_POWER_DOMAIN_MPE 8
> +#define TEGRA186_POWER_DOMAIN_PCX 9
> +#define TEGRA186_POWER_DOMAIN_SAX 10
> +#define TEGRA186_POWER_DOMAIN_VE 11
> +#define TEGRA186_POWER_DOMAIN_VIC 12
> +#define TEGRA186_POWER_DOMAIN_XUSBA 13
> +#define TEGRA186_POWER_DOMAIN_XUSBB 14
> +#define TEGRA186_POWER_DOMAIN_XUSBC 15
> +#define TEGRA186_POWER_DOMAIN_GPU 43
> +#define TEGRA186_POWER_DOMAIN_MAX 44
It's slightly odd that these are named TEGRA186_POWER_DOMAIN_* since
power domain is a Linuxism. All documentation that I've seen calls these
powergates.
I guess since this is now ABI there is not much we can do to rectify it.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH v3 6/6] ARM: dts: stm32f429: enable adc on eval board
From: Fabrice Gasnier @ 2016-11-15 15:31 UTC (permalink / raw)
To: linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, lars-Qo5EllUWu/uELgA04lAiVw,
knaack.h-Mmb7MZpHnFY, pmeerw-jW+XmwGofnusTnJN9+BGXg,
fabrice.gasnier-qxv4g6HH51o
In-Reply-To: <1479223861-21747-1-git-send-email-fabrice.gasnier-qxv4g6HH51o@public.gmane.org>
Enable analog to digital converter on stm32f429i-eval board.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>
---
arch/arm/boot/dts/stm32429i-eval.dts | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 6bfc595..c144735 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -65,6 +65,20 @@
serial0 = &usart1;
};
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_vref: regulator@0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+ regulator-name = "vref";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
green {
@@ -123,3 +137,14 @@
pinctrl-names = "default";
status = "okay";
};
+
+&adc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&adc3_in8_pin>;
+ vref-supply = <®_vref>;
+ status = "okay";
+ adc3: adc@200 {
+ st,adc-channels = <8>;
+ status = "okay";
+ };
+};
--
1.9.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
^ 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