* Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru
From: Heiko Stübner @ 2016-12-22 16:09 UTC (permalink / raw)
To: Brian Norris
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Caesar Wang, Doug Anderson,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chris Zhong
In-Reply-To: <13721273.q1HcHZAhdQ@phil>
Am Dienstag, 13. Dezember 2016, 18:48:50 schrieb Heiko Stuebner:
> Am Mittwoch, 7. Dezember 2016, 09:09:17 CET schrieb Brian Norris:
> > Hi Heiko,
> >
> > On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote:
> > > Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
> > > > We need to add regulators to the CPU nodes, so cpufreq doesn't think
> > > > it
> > > > can crank up the clock speed without changing the voltage. However, we
> > > > don't yet have the DT bindings to fully describe the Over Voltage
> > > > Protection (OVP) circuits on these boards. Without that description,
> > > > we
> > > > might end up changing the voltage too much, too fast.
> > > >
> > > > Add the pwm-regulator descriptions and associate the CPU OPPs, but
> > > > leave
> > > > them disabled.
> > > >
> > > > Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > >
> > > is there a specific reason for keeping this change separate?
> >
> > Maybe not a great one. I figured they were somewhat controversial, so I
> > at least wanted to split the "cpufreq patches" (i.e., this and the
> > previous) from the main DTS(I) additions. I also figured we typically
> > like to keep the base SoC changes separate from the board DTS(I)
> > changes.
>
> I was scratching my head for a bit where this was affecting the evb, until I
> found the include at the end of patch5 :-) .
>
> > > While it is nice for documentation reasons, as it stands now the
> > > previous
> > > patch introduces a regression (cpufreq trying to scale without
> > > regulators)
> > > and immediately fixes it here.
> >
> > Right. Additionally, as noted on the previous patch, we might do the
> > same with EVB. But I don't know what the regulators are like for EVB.
> > This is probably a bigger deal, since EVB has been working (allegedly)
> > upstream for a while now.
>
> Yep, it was at least booting :-) . I guess I should wire it up again. My
> shiny new Gru somehow did take up its space recently.
>
> > There's no way to split these up without either breaking compilation or
> > breaking bisectability. For Kevin/Gru, they don't function at all before
> > this series, so I figured some "settle" time wasn't a huge deal.
> >
> > > So if you're ok with it, I'd like to merge this one back into the
> > > previous
> > > patch when applying.
> >
> > That'd be OK with me, as long as we're also confident about EVB.
>
> That somehow sounds unrelated, as this patch only touches gru stuff anyway.
> So if the evb breaks, it would do so after patch5 already.
>
> > Maybe at a minimum, I should just patch in some empty regulator nodes,
> > so cpufreq doesn't think there's no need to handle voltage.
>
> So I guess going forward we could do, describe the evb pwm regulators (in
> disabled state), add general OPPs, add gru with pwm regulators?
>
> I'll try to hook up my evb and check on the pwm-regulators in the schematics
> this week.
Now I remember why I retired my evb ... ES1 silicon.
Anyway, I was able to describe the rk808 pmic that is used in some basic way
and was able to see a bit of cpu-scaling on the little cluster, but the big
cluster never was able to scale in a stable way and always hung the system.
I don't think that we should care about ES1 chips as they never reached any
public but that leaves me without the ability to test.
In another issue I read that Caesar also is using a rk3399evb sometimes, so
maybe he can give that a try on real ES2 silicon and I've thus Cc'ed him.
@Caesar I don't know how much the power rails differ between evb versions, so
maybe you can also provide the necessary rk808 devicetree nodes please?
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] ARM64: zynqmp: Fix i2c node's compatible string
From: Moritz Fischer @ 2016-12-22 16:26 UTC (permalink / raw)
To: Michal Simek
Cc: Moritz Fischer, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Moritz Fischer,
Sören Brinkmann, U-Boot List, Rob Herring
In-Reply-To: <d1e69302-8367-7c57-ecd7-f72861c3a49e-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
Hi Michal,
On Wed, Dec 21, 2016 at 11:35 PM, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
I keep getting that wrong .. .damn ... :) Will resubmit.
> The same of course for u-boot where also p14 should be added to the driver.
Yeah, I realized that part after submitting...
Thanks
--
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 5/6] Documentation: bindings: add documentation for ir-spi device driver
From: Rob Herring @ 2016-12-22 16:40 UTC (permalink / raw)
To: Andi Shyti
Cc: Mauro Carvalho Chehab, Sean Young, Mark Rutland, Richard Purdie,
Jacek Anaszewski, Heiner Kallweit, linux-media, devicetree,
linux-leds, linux-kernel, Andi Shyti
In-Reply-To: <20161218111138.12831-6-andi.shyti@samsung.com>
On Sun, Dec 18, 2016 at 08:11:37PM +0900, Andi Shyti wrote:
> Document the ir-spi driver's binding which is a IR led driven
> through the SPI line.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Sean Young <sean@mess.org>
> ---
> .../devicetree/bindings/leds/irled/spi-ir-led.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
From: Laurent Pinchart @ 2016-12-22 17:05 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA, crope-X3B1VOXEql0,
chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1482307838-47415-7-git-send-email-ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Hi Ramesh,
Thank you for the patch.
On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
> Add binding documentation for Renesas R-Car Digital Radio Interface
> (DRIF) controller.
>
> Signed-off-by: Ramesh Shanmugasundaram
> <ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> ---
> .../devicetree/bindings/media/renesas,drif.txt | 202 ++++++++++++++++++
> 1 file changed, 202 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode
> 100644
> index 0000000..1f3feaf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> @@ -0,0 +1,202 @@
> +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> +------------------------------------------------------------
> +
> +R-Car Gen3 DRIF is a SPI like receive only slave device. A general
> +representation of DRIF interfacing with a master device is shown below.
> +
> ++---------------------+ +---------------------+
> +| |-----SCK------->|CLK |
> +| Master |-----SS-------->|SYNC DRIFn (slave) |
> +| |-----SD0------->|D0 |
> +| |-----SD1------->|D1 |
> ++---------------------+ +---------------------+
> +
> +As per datasheet, each DRIF channel (drifn) is made up of two internal
> +channels (drifn0 & drifn1). These two internal channels share the common
> +CLK & SYNC. Each internal channel has its own dedicated resources like
> +irq, dma channels, address space & clock. This internal split is not
> +visible to the external master device.
> +
> +The device tree model represents each internal channel as a separate node.
> +The internal channels sharing the CLK & SYNC are tied together by their
> +phandles using a new property called "renesas,bonding". For the rest of
> +the documentation, unless explicitly stated, the word channel implies an
> +internal channel.
> +
> +When both internal channels are enabled they need to be managed together
> +as one (i.e.) they cannot operate alone as independent devices. Out of the
> +two, one of them needs to act as a primary device that accepts common
> +properties of both the internal channels. This channel is identified by a
> +new property called "renesas,primary-bond".
> +
> +To summarize,
> + - When both the internal channels that are bonded together are enabled,
> + the zeroth channel is selected as primary-bond. This channels accepts
> + properties common to all the members of the bond.
> + - When only one of the bonded channels need to be enabled, the property
> + "renesas,bonding" or "renesas,primary-bond" will have no effect. That
> + enabled channel can act alone as any other independent device.
> +
> +Required properties of an internal channel:
> +-------------------------------------------
> +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> R8A7795 SoC.
> + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> device.
> + When compatible with the generic version, nodes must list the
> + SoC-specific version corresponding to the platform first
> + followed by the generic version.
> +- reg: offset and length of that channel.
> +- interrupts: associated with that channel.
> +- clocks: phandle and clock specifier of that channel.
> +- clock-names: clock input name string: "fck".
> +- dmas: phandles to the DMA channels.
> +- dma-names: names of the DMA channel: "rx".
> +- renesas,bonding: phandle to the other channel.
> +
> +Optional properties of an internal channel:
> +-------------------------------------------
> +- power-domains: phandle to the respective power domain.
> +
> +Required properties of an internal channel when:
> + - It is the only enabled channel of the bond (or)
> + - If it acts as primary among enabled bonds
> +--------------------------------------------------------
> +- pinctrl-0: pin control group to be used for this channel.
> +- pinctrl-names: must be "default".
> +- renesas,primary-bond: empty property indicating the channel acts as
> primary
> + among the bonded channels.
> +- port: child port node of a channel that defines the local and remote
> + endpoints. The remote endpoint is assumed to be a third party tuner
> + device endpoint.
> +
> +Optional properties of an internal channel when:
> + - It is the only enabled channel of the bond (or)
> + - If it acts as primary among enabled bonds
> +--------------------------------------------------------
> +- renesas,syncmd : sync mode
> + 0 (Frame start sync pulse mode. 1-bit width pulse
> + indicates start of a frame)
> + 1 (L/R sync or I2S mode) (default)
> +- renesas,lsb-first : empty property indicates lsb bit is received
> first.
> + When not defined msb bit is received first (default)
> +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for low/high
> + respectively. The default is 1 (active high)
> +- renesas,dtdl : delay between sync signal and start of reception.
> + The possible values are represented in 0.5 clock
> + cycle units and the range is 0 to 4. The default
> + value is 2 (i.e.) 1 clock cycle delay.
> +- renesas,syncdl : delay between end of reception and sync signal
> edge.
> + The possible values are represented in 0.5 clock
> + cycle units and the range is 0 to 4 & 6. The default
> + value is 0 (i.e.) no delay.
Most of these properties are pretty similar to the video bus properties
defined at the endpoint level in
Documentation/devicetree/bindings/media/video-interfaces.txt. I believe it
would make sense to use OF graph and try to standardize these properties
similarly.
> +
> +Example
> +--------
> +
> +SoC common dtsi file
> +
> + drif00: rif@e6f40000 {
> + compatible = "renesas,r8a7795-drif",
> + "renesas,rcar-gen3-drif";
> + reg = <0 0xe6f40000 0 0x64>;
> + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 515>;
> + clock-names = "fck";
> + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
> + dma-names = "rx", "rx";
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + renesas,bonding = <&drif01>;
> + status = "disabled";
> + };
> +
> + drif01: rif@e6f50000 {
> + compatible = "renesas,r8a7795-drif",
> + "renesas,rcar-gen3-drif";
> + reg = <0 0xe6f50000 0 0x64>;
> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 514>;
> + clock-names = "fck";
> + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
> + dma-names = "rx", "rx";
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + renesas,bonding = <&drif00>;
> + status = "disabled";
> + };
> +
> +
> +Board specific dts file
> +
> +(1) Both internal channels enabled, primary-bond = 0
> +-----------------------------------------------------
> +
> +When interfacing with a third party tuner device with two data pins as
> shown +below.
> +
> ++---------------------+ +---------------------+
> +| |-----SCK------->|CLK |
> +| Master |-----SS-------->|SYNC DRIFn (slave) |
> +| |-----SD0------->|D0 |
> +| |-----SD1------->|D1 |
> ++---------------------+ +---------------------+
> +
> +pfc {
> + ...
> +
> + drif0_pins: drif0 {
> + groups = "drif0_ctrl_a", "drif0_data0_a",
> + "drif0_data1_a";
> + function = "drif0";
> + };
> + ...
> +}
> +
> +&drif00 {
> + pinctrl-0 = <&drif0_pins>;
> + pinctrl-names = "default";
> + renesas,syncac-active = <1>;
> + renesas,primary-bond;
> + status = "okay";
> + port {
> + drif0_ep: endpoint {
> + remote-endpoint = <&tuner_ep>;
> + };
> + };
> +};
> +
> +&drif01 {
> + status = "okay";
> +};
> +
> +(2) Internal channel 1 alone is enabled:
> +----------------------------------------
> +
> +When interfacing with a third party tuner device with one data pin as shown
> +below.
> +
> ++---------------------+ +---------------------+
> +| |-----SCK------->|CLK |
> +| Master |-----SS-------->|SYNC DRIFn (slave) |
> +| | |D0 (unused) |
> +| |-----SD-------->|D1 |
> ++---------------------+ +---------------------+
> +
> +pfc {
> + ...
> +
> + drif0_pins: drif0 {
> + groups = "drif0_ctrl_a", "drif0_data1_a";
> + function = "drif0";
> + };
> + ...
> +}
> +
> +&drif01 {
> + pinctrl-0 = <&drif0_pins>;
> + pinctrl-names = "default";
> + renesas,syncac-active = <0>;
> + status = "okay";
> + port {
> + drif0_ep: endpoint {
> + remote-endpoint = <&tuner_ep>;
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
--
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] ARM64: zynqmp: Fix i2c node's compatible string
From: mdf @ 2016-12-22 17:19 UTC (permalink / raw)
To: devicetree
Cc: linux-kernel, linux-arm-kernel, Moritz Fischer, Michal Simek,
Sören Brinkmann, Rob Herring
From: Moritz Fischer <mdf@kernel.org>
The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core
which fixes some silicon bugs that needed software workarounds
in Version 1.0 that was used on Zynq systems.
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
Cc: Rob Herring <robh+dt@kernel.org>
---
Changes from v1:
- Added fall through case to cdns,i2c-r1p10
Cheers,
Moritz
---
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 68a90833..ee86d02 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -175,7 +175,7 @@
};
i2c0: i2c@ff020000 {
- compatible = "cdns,i2c-r1p10";
+ compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 17 4>;
@@ -185,7 +185,7 @@
};
i2c1: i2c@ff030000 {
- compatible = "cdns,i2c-r1p10";
+ compatible = "cdns,i2c-r1p14", "cdns,i2c-r1p10";
status = "disabled";
interrupt-parent = <&gic>;
interrupts = <0 18 4>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] ARM64: zynqmp: Fix i2c node's compatible string
From: Sören Brinkmann @ 2016-12-22 17:27 UTC (permalink / raw)
To: mdf; +Cc: devicetree, Rob Herring, linux-kernel, linux-arm-kernel,
Michal Simek
In-Reply-To: <1482427165-8951-1-git-send-email-mdf@kernel.org>
On Thu, 2016-12-22 at 09:19:25 -0800, mdf@kernel.org wrote:
> From: Moritz Fischer <mdf@kernel.org>
>
> The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core
> which fixes some silicon bugs that needed software workarounds
> in Version 1.0 that was used on Zynq systems.
>
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
> Cc: Rob Herring <robh+dt@kernel.org>
Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Sören
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/2] power: supply: add sbs-charger driver
From: Sebastian Reichel @ 2016-12-22 18:04 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1482247874-28713-1-git-send-email-nicolas.saenz-gbiq2sxWoaasTnJN9+BGXg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]
Hi,
On Tue, Dec 20, 2016 at 04:31:12PM +0100, Nicolas Saenz Julienne wrote:
> This series adds support for all SBS compatible battery chargers, as defined
> here: http://sbs-forum.org/specs/sbc110.pdf.
>
> [...]
>
> Nicolas Saenz Julienne (2):
> power: supply: add sbs-charger driver
> dt-bindings: power: add bindings for sbs-charger
>
> .../bindings/power/supply/sbs_sbs-charger.txt | 23 ++
> drivers/power/supply/Kconfig | 6 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/sbs-charger.c | 274 +++++++++++++++++++++
> 4 files changed, 304 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/sbs_sbs-charger.txt
> create mode 100644 drivers/power/supply/sbs-charger.c
Thanks for your patchset. We are currently in the merge
window and your patchset will appear in linux-next once
4.10-rc1 has been tagged by Linus Torvalds.
Until then I queued it into this branch:
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/log/?h=for-next-next
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding
From: Rob Herring @ 2016-12-22 18:14 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, linaro-kernel, linux-pm, linux-kernel,
Stephen Boyd, Nishanth Menon, Vincent Guittot, Mark Rutland,
Kevin Hilman, Ulf Hansson, Lina Iyer, devicetree, Nayak Rajendra
In-Reply-To: <cover.1481539827.git.viresh.kumar@linaro.org>
On Mon, Dec 12, 2016 at 04:26:17PM +0530, Viresh Kumar wrote:
> Hello,
>
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
>
> We had some discussions about it in the past on the PM list [1], which is
> followed by discussions during the LPC. The outcome of all that was that we
> should extend Power Domain framework to support active state power management
> as well.
>
> The power-domains until now were only concentrating on the idle state
> management of the device and this needs to change in order to reuse the
> infrastructure of power domains for active state management.
>From a h/w perspective, are idle states really different from
performance states?
>
> To get a complete picture of the proposed plan, following is what we
> need to do:
> - Create DT bindings to get domain performance state information for the
> platforms.
I would do this last so you can evolve things if you're not certain
about what the bindings should look like. You can always start with
things in the kernel and add to DT later.
While in theory we should be able to just "describe the h/w" in DT and
develop the Linux side independently, this feels too much like the
bindings are just evolving with Linux needs.
Rob
^ permalink raw reply
* Re: [2/3] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx
From: David Lechner @ 2016-12-22 18:16 UTC (permalink / raw)
To: Franklin S Cooper Jr, Greg Kroah-Hartman, Rob Herring,
Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Axel Haslam, Kevin Hilman,
Sekhar Nori, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Bartosz Golaszewski, Alexandre Bailon,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Jiri Slaby,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <306c9ce3-4003-84b9-fd0f-34232399f1aa-l0cyMroinI0@public.gmane.org>
On 12/22/2016 09:21 AM, Franklin S Cooper Jr wrote:
>
>
> On 12/20/2016 02:23 PM, David Lechner wrote:
>> This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx. These
>> SoCs have standard 8250 registers plus some extra non-standard registers.
>>
>> The UART will not function unless the non-standard Power and Emulation
>> Management Register (PWREMU_MGMT) is configured correctly. This is
>> currently handled in arch/arm/mach-davinci/serial.c for non-device-tree
>> boards. Making this part of the UART driver will allow UART to work on
>> device-tree boards as well and the mach code can eventually be removed.
>>
>> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
>> ---
>> drivers/tty/serial/8250/8250_of.c | 1 +
>> drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
>> include/uapi/linux/serial_core.h | 3 ++-
>> include/uapi/linux/serial_reg.h | 8 ++++++++
>> 4 files changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
>> index d25ab1c..5281252 100644
>> --- a/drivers/tty/serial/8250/8250_of.c
>> +++ b/drivers/tty/serial/8250/8250_of.c
>> @@ -332,6 +332,7 @@ static const struct of_device_id of_platform_serial_table[] = {
>> .data = (void *)PORT_ALTR_16550_F128, },
>> { .compatible = "mrvl,mmp-uart",
>> .data = (void *)PORT_XSCALE, },
>> + { .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
>> { /* end of list */ },
>> };
>> MODULE_DEVICE_TABLE(of, of_platform_serial_table);
>> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
>> index fe4399b..ea854054 100644
>> --- a/drivers/tty/serial/8250/8250_port.c
>> +++ b/drivers/tty/serial/8250/8250_port.c
>> @@ -273,6 +273,15 @@ static const struct serial8250_config uart_config[] = {
>> .rxtrig_bytes = {1, 4, 8, 14},
>> .flags = UART_CAP_FIFO,
>> },
>> + [PORT_DA830] = {
>> + .name = "TI DA8xx/OMAPL13x/AM17xx/AM18xx",
>> + .fifo_size = 16,
>> + .tx_loadsz = 16,
>> + .fcr = UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO |
>> + UART_FCR_R_TRIG_10,
>> + .rxtrig_bytes = {1, 4, 8, 14},
>> + .flags = UART_CAP_FIFO | UART_CAP_AFE,
>> + },
>> };
>
>
> Any reason why the fcr and flags fields are changed when compared
> against PORT_16550A?
The AM1808 TRM says to "always enable" the DMA bit. I figured setting it
now could save someone trouble later if they wanted to add DMA support.
It does not matter if it is set even if you are not using DMA.
Since we are using the special reset register that resets the state
machine, setting UART_FCR_CLEAR_RCVR and UART_FCR_CLEAR_XMIT seems
redundant.
And in my testing with an AM1808, UART_CAP_AFE is not automatically
detected even though the chip has this capability, so it needs to be
manually specified.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding
From: Rob Herring @ 2016-12-22 18:34 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd, Nishanth Menon,
Vincent Guittot, Mark Rutland, Kevin Hilman, Ulf Hansson,
Lina Iyer, devicetree-u79uwXL29TY76Z2rM5mHXA, Nayak Rajendra
In-Reply-To: <dd95df02a1c3efd00bd4890f8aceeb717ad38788.1481539827.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Dec 12, 2016 at 04:26:18PM +0530, Viresh Kumar wrote:
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
>
> The power-domains until now were only concentrating on the idle state
> management of the device and this needs to change in order to reuse the
> infrastructure of power domains for active state management.
>
> This patch adds binding to describe the performance states of a power
> domain.
>
> If the consumers don't need the capability of switching to different
> domain performance states at runtime, then they can simply define their
> required domain performance state in their node directly. Otherwise the
> consumers can define their requirements with help of other
> infrastructure, for example the OPP table.
>
> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/power/power_domain.txt | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 723e1ad937da..a456e0dc04e0 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -38,6 +38,40 @@ phandle arguments (so called PM domain specifiers) of length specified by the
> domain's idle states. In the absence of this property, the domain would be
> considered as capable of being powered-on or powered-off.
>
> +- domain-performance-states : A phandle of the performance states node, which
> + defines all the performance states associated with a power
> + domain.
> + The domain-performance-states property reflects the performance states of this
> + PM domain and not the performance states of the devices or sub-domains in the
> + PM domain. Devices and sub-domains have their own performance states, which
> + are dependent on the performance state of the PM domain.
> +
> +* PM domain performance states node
> +
> +This describes the performance states of a PM domain.
> +
> +Required properties:
> +- compatible: Allow performance states to express their compatibility. It should
> + be: "domain-performance-state".
> +
> +- Performance state nodes: This node shall have one or more "Performance State"
> + nodes.
> +
> +* Performance state node
> +
> +Required properties:
> +- performance-level: A positive integer value representing the performance level
> + associated with a performance state. The integer value '1' represents the
> + lowest performance level and the highest value represents the highest
> + performance level.
> +
> +Optional properties:
> +- domain-microvolt: voltage in micro Volts.
> +
> + A single regulator's voltage is specified with an array of size one or three.
> + Single entry is for target voltage and three entries are for <target min max>
> + voltages.
> +
> Example:
>
> power: power-controller@12340000 {
> @@ -118,4 +152,39 @@ The node above defines a typical PM domain consumer device, which is located
> inside a PM domain with index 0 of a power controller represented by a node
> with the label "power".
>
> +Optional properties:
> +- domain-performance-state: A phandle of a Performance state node.
> +
> +Example:
> +
> + parent: power-controller@12340000 {
> + compatible = "foo,power-controller";
> + reg = <0x12340000 0x1000>;
> + #power-domain-cells = <0>;
> + domain-performance-states = <&domain_perf_states>;
> + };
> +
> + domain_perf_states: performance_states {
If you want to have performance states for a domain in DT, then you need
to actually have a node for the domain in DT. Then this should be a
child of the domain. I wouldn't think non-CPU domain performance states
will be common across domains.
> + compatible = "domain-performance-state";
> + domain_perf_state1: pstate@1 {
A unit address should have a reg property.
> + performance-level = <1>;
> + domain-microvolt = <970000 975000 985000>;
> + };
> + domain_perf_state2: pstate@2 {
> + performance-level = <2>;
> + domain-microvolt = <1000000 1075000 1085000>;
> + };
> + domain_perf_state3: pstate@3 {
> + performance-level = <3>;
> + domain-microvolt = <1100000 1175000 1185000>;
> + };
> + }
> +
> + leaky-device@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&power 0>;
> + domain-performance-state = <&domain_perf_state2>;
domain-performance-state and domain-performance-states are too similar
in name. The property here should probably reflect the mode needed and
perhaps specific to the device. I assume a device will need multiple
states/modes.
Also, since you refer to the performance state node directly, I'm not
sure why you need the performance-level property.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: add bindings for rk3328 clock controller
From: Rob Herring @ 2016-12-22 18:39 UTC (permalink / raw)
To: Elaine Zhang
Cc: heiko, mturquette, sboyd, xf, mark.rutland, linux-clk,
linux-arm-kernel, devicetree, huangtao, xxx, cl, linux-rockchip,
linux-kernel
In-Reply-To: <1482112573-11613-3-git-send-email-zhangqing@rock-chips.com>
On Mon, Dec 19, 2016 at 09:56:11AM +0800, Elaine Zhang wrote:
> Add devicetree bindings for Rockchip cru which found on
> Rockchip SoCs.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> .../bindings/clock/rockchip,rk3328-cru.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.txt
> new file mode 100644
> index 000000000000..20053494d49f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.txt
> @@ -0,0 +1,57 @@
> +* Rockchip RK3328 Clock and Reset Unit
> +
> +The RK3328 clock controller generates and supplies clock to various
> +controllers within the SoC and also implements a reset controller for SoC
> +peripherals.
> +
> +Required Properties:
> +
> +- compatible: should be "rockchip,rk3328-cru"
The example shows other compatibles. IMO, I would drop them rather than
add them here.
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- #clock-cells: should be 1.
> +- #reset-cells: should be 1.
> +
> +Optional Properties:
> +
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> + If missing pll rates are not changeable, due to the missing pll lock status.
> +
> +Each clock is assigned an identifier and client nodes can use this identifier
> +to specify the clock which they consume. All available clocks are defined as
> +preprocessor macros in the dt-bindings/clock/rk3328-cru.h headers and can be
> +used in device tree sources. Similar macros exist for the reset sources in
> +these files.
> +
> +External clocks:
> +
> +There are several clocks that are generated outside the SoC. It is expected
> +that they are defined using standard clock bindings with following
> +clock-output-names:
> + - "xin24m" - crystal input - required,
> + - "clkin_i2s" - external I2S clock - optional,
> + - "gmac_clkin" - external GMAC clock - optional
> + - "phy_50m_out" - output clock of the pll in the mac phy
> +
> +Example: Clock controller node:
> +
> + cru: clock-controller@ff440000 {
> + compatible = "rockchip,rk3328-cru", "rockchip,cru", "syscon";
> + reg = <0x0 0xff440000 0x0 0x1000>;
> + rockchip,grf = <&grf>;
> +
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> +Example: UART controller node that consumes the clock generated by the clock
> + controller:
> +
> + uart0: serial@ff120000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0xff120000 0x100>;
> + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&cru SCLK_UART0>;
> + };
> --
> 1.9.1
>
>
^ permalink raw reply
* Re: [PATCH v3 2/2] crypto: mediatek - add DT bindings documentation
From: Rob Herring @ 2016-12-22 18:41 UTC (permalink / raw)
To: Ryder Lee
Cc: Herbert Xu, David S. Miller, Matthias Brugger,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sean Wang,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Roy Luo,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1482114045-18716-3-git-send-email-ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Mon, Dec 19, 2016 at 10:20:45AM +0800, Ryder Lee wrote:
> Add DT bindings documentation for the crypto driver
>
> Signed-off-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/crypto/mediatek-crypto.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Rob Herring @ 2016-12-22 18:45 UTC (permalink / raw)
To: Changming Huang
Cc: balbi, mark.rutland, catalin.marinas, will.deacon, linux,
devicetree, linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <1482139554-13618-2-git-send-email-jerry.huang@nxp.com>
On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote:
> New property "snps,incr-burst-type-adjustment = <x>, <y>" for USB3.0 DWC3.
> Field "x": 1/0 - undefined length INCR burst type enable or not;
> Field "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type.
>
> While enabling undefined length INCR burst type and INCR16 burst type,
> get better write performance on NXP Layerscape platform:
> around 3% improvement (from 364MB/s to 375MB/s).
>
> Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> ---
> Changes in v3:
> - add new property for INCR burst in usb node.
>
> Documentation/devicetree/bindings/usb/dwc3.txt | 5 +++++
> arch/arm/boot/dts/ls1021a.dtsi | 1 +
> arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 ++
> 4 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index e3e6983..8c405a3 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -55,6 +55,10 @@ Optional properties:
> fladj_30mhz_sdbnd signal is invalid or incorrect.
>
> - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated.
> + - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
> + register, undefined length INCR burst type enable and INCRx type.
> + First field is for undefined length INCR burst type enable or not.
> + Second field is for largest INCRx type enabled.
Why do you need the first field? Is the 2nd field used if the 1st is 0?
If not, then just use the presence of the property to enable or not.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Rob Herring @ 2016-12-22 18:48 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, Mark Rutland, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Greer,
Justin Bronder
In-Reply-To: <CAO7Z3WKmEbJCN_=srxTVKXvtz84vHGi41RS+9T7fmkmhRB6nEw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Dec 19, 2016 at 5:23 PM, Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org> wrote:
> I can make that change, however, I worry that it may be a bit
> misleading, since there are only two supported clock frequencies, but
> a number like that to me implies that it could be set to any number
> you want. I'm new at this, and so I'll go ahead and change it as you
> request, but I'd like to hear your thoughts on my concern.
Then the binding doc just needs to state what are the 2 valid frequencies.
Rob
--
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 0/4 v2] of/overlay: sysfs based ABI for dt overlays
From: Frank Rowand @ 2016-12-22 19:00 UTC (permalink / raw)
To: Heinrich Schuchardt, Pantelis Antoniou, Rob Herring, Mark Rutland
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161220190455.25115-1-xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
Hi Heinrich,
On 12/20/16 11:04, Heinrich Schuchardt wrote:
> Currently the kernel only supplies an internal API for creating
> and destroying device tree overlays.
>
> For some boards vendor specific kernel modules exist for
> managing device tree overlays but they have not been
> upstreamed or upstreaming stalled.
> https://lkml.org/lkml/2015/6/12/624
> https://lkml.org/lkml/2013/1/7/366
>
> This patch series provides a sysfs based ABI for creation and
> destruction of dt overlays in /sys/firmware/devicetree/overlays.
>
> The following files are provided:
>
> load: This is a write only file.
> A string written to it is interpreted as the path to a
> flattened device tree overlay file. It is used to create
> and apply the contained overlays.
>
> loaded: This is a read only file.
> It provides the count of loaded overlays as a decimal
> number.
>
> unload: This is a write only file.
> If a positive number n is wrtten to this file the n
> most recent overlays are destroyed.
> If a negative number is written to this file all
> overlays are destroyed.
This patch series follows a _somewhat_ similar approach to what
was first proposed two years ago, and does not address the
issues that were brought up at that time. See:
From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
Date: Wed, 3 Dec 2014 13:23:28 +0200
Subject: [PATCH] OF: DT-Overlay configfs interface (v3)
But just responding directly to the two year old issues would not
be a productive approach, since there has been a lot of subsequent
discussion on how to load overlays (you point to two of the many
threads above). The latest discussions are based on the concept
of describing the overlay attachment points as connectors.
Please join in pushing the connectors discussion along to make
sure that it meets your needs.
-Frank
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
>
> version 2:
> change sysfs path to
> /sys/firmware/devicetree/overlays
>
> Fix errors indicated by kbuild robot:
> Add missing inline attribute to of_overlay_count
> in patch 1.
> Add 'select CONFIG_OF_EARLY_FLATTREE' to Kconfig
> in patch 2.
>
> Change unit test cases to check new functions
> of_overlay_count and of_overlay_destroy_last.
>
> Heinrich Schuchardt (4):
> of/overlay: add API function to count and pop last
> of/overlay: sysfs based ABI for dt overlays
> of/overlay: documentation for sysfs ABI
> of/overlay: test count and destroy_last
>
> .../ABI/testing/sysfs-firmware-devicetree-overlays | 24 +++
> Documentation/devicetree/overlay-notes.txt | 7 +-
> drivers/of/Kconfig | 15 ++
> drivers/of/Makefile | 2 +
> drivers/of/base.c | 1 +
> drivers/of/ov_sysfs.c | 223 +++++++++++++++++++++
> drivers/of/overlay.c | 50 +++++
> drivers/of/unittest.c | 15 +-
> include/linux/of.h | 12 ++
> 9 files changed, 346 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-devicetree-overlays
> create mode 100644 drivers/of/ov_sysfs.c
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding
From: Geert Uytterhoeven @ 2016-12-22 19:05 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ramesh Shanmugasundaram, Rob Herring, Mark Rutland,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Antti Palosaari, Chris Paterson, Geert Uytterhoeven,
Linux Media Mailing List, devicetree@vger.kernel.org,
Linux-Renesas
In-Reply-To: <11494368.ZdobxT7gGY@avalon>
Hi Laurent,
On Thu, Dec 22, 2016 at 6:05 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
>> Add binding documentation for Renesas R-Car Digital Radio Interface
>> (DRIF) controller.
>>
>> Signed-off-by: Ramesh Shanmugasundaram
>> <ramesh.shanmugasundaram@bp.renesas.com> ---
>> .../devicetree/bindings/media/renesas,drif.txt | 202 ++++++++++++++++++
>> 1 file changed, 202 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
>> b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode
>> 100644
>> index 0000000..1f3feaf
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
>> +Optional properties of an internal channel when:
>> + - It is the only enabled channel of the bond (or)
>> + - If it acts as primary among enabled bonds
>> +--------------------------------------------------------
>> +- renesas,syncmd : sync mode
>> + 0 (Frame start sync pulse mode. 1-bit width pulse
>> + indicates start of a frame)
>> + 1 (L/R sync or I2S mode) (default)
>> +- renesas,lsb-first : empty property indicates lsb bit is received
>> first.
>> + When not defined msb bit is received first (default)
>> +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for low/high
>> + respectively. The default is 1 (active high)
>> +- renesas,dtdl : delay between sync signal and start of reception.
>> + The possible values are represented in 0.5 clock
>> + cycle units and the range is 0 to 4. The default
>> + value is 2 (i.e.) 1 clock cycle delay.
>> +- renesas,syncdl : delay between end of reception and sync signal
>> edge.
>> + The possible values are represented in 0.5 clock
>> + cycle units and the range is 0 to 4 & 6. The default
>> + value is 0 (i.e.) no delay.
>
> Most of these properties are pretty similar to the video bus properties
> defined at the endpoint level in
> Documentation/devicetree/bindings/media/video-interfaces.txt. I believe it
> would make sense to use OF graph and try to standardize these properties
> similarly.
Note that the last two properties match the those in
Documentation/devicetree/bindings/spi/sh-msiof.txt.
We may want to use one DRIF channel as a plain SPI slave with the
(modified) MSIOF driver in the future.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: Uwe Kleine-König @ 2016-12-22 19:11 UTC (permalink / raw)
To: M'boumba Cedric Madianga
Cc: wsa, robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1482413704-17531-4-git-send-email-cedric.madianga@gmail.com>
Hello,
On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
> @@ -337,6 +350,16 @@
> slew-rate = <2>;
> };
> };
> +
> + i2c1_pins_b: i2c1@0 {
> + pins1 {
> + pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
> + drive-open-drain;
> + };
> + pins2 {
> + pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
> + };
the second doesn't need the open-drain property? Why?
> + };
> };
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [RFC PATCH 1/4] dt-bindings: mdm9615: Add ADM DMA engine
From: Zoran Markovic @ 2016-12-22 20:05 UTC (permalink / raw)
To: linux-kernel
Cc: Zoran Markovic, Andy Gross, David Brown, Rob Herring,
Mark Rutland, Russell King, linux-arm-msm, linux-soc, devicetree,
linux-arm-kernel
In-Reply-To: <1482437139-29329-1-git-send-email-zmarkovic@sierrawireless.com>
Add configuration for ADM DMA engine on MDM9615, used by the EBI2
NAND controller. This commit requires the ADM DMA patches from
Andy Gross:
https://lkml.org/lkml/2015/3/17/19
Cc: Andy Gross <andy.gross@linaro.org>
Cc: David Brown <david.brown@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-soc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Zoran Markovic <zmarkovic@sierrawireless.com>
---
arch/arm/boot/dts/qcom-mdm9615.dtsi | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-mdm9615.dtsi b/arch/arm/boot/dts/qcom-mdm9615.dtsi
index 5ae4ec5..fbc7d68 100644
--- a/arch/arm/boot/dts/qcom-mdm9615.dtsi
+++ b/arch/arm/boot/dts/qcom-mdm9615.dtsi
@@ -336,7 +336,24 @@
};
};
- sdcc1bam: dma@12182000{
+ adm_dma: dma@18300000 {
+ compatible = "qcom,adm";
+ reg = <0x18300000 0x100000>;
+ interrupts = <0 170 0>;
+ #dma-cells = <1>;
+
+ clocks = <&gcc ADM0_CLK>, <&gcc ADM0_PBUS_CLK>;
+ clock-names = "core", "iface";
+
+ resets = <&gcc ADM0_RESET>,
+ <&gcc ADM0_C0_RESET>,
+ <&gcc ADM0_C1_RESET>,
+ <&gcc ADM0_C2_RESET>;
+ reset-names = "clk", "c0", "c1", "c2";
+ qcom,ee = <0>;
+ };
+
+ sdcc1bam:dma@12182000{
compatible = "qcom,bam-v1.3.0";
reg = <0x12182000 0x8000>;
interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 2/4] clk: mdm9615: Add EBI2 clock
From: Zoran Markovic @ 2016-12-22 20:05 UTC (permalink / raw)
To: linux-kernel
Cc: Zoran Markovic, Andy Gross, David Brown, Michael Turquette,
Stephen Boyd, Rob Herring, Mark Rutland, Neil Armstrong,
linux-arm-msm, linux-soc, linux-clk, devicetree
In-Reply-To: <1482437139-29329-1-git-send-email-zmarkovic@sierrawireless.com>
Add definition of EBI2 clock used by MDM9615 NAND controller.
Cc: Andy Gross <andy.gross@linaro.org>
Cc: David Brown <david.brown@linaro.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-soc@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Zoran Markovic <zmarkovic@sierrawireless.com>
---
drivers/clk/qcom/gcc-mdm9615.c | 30 ++++++++++++++++++++++++++
include/dt-bindings/clock/qcom,gcc-mdm9615.h | 3 +++
2 files changed, 33 insertions(+)
diff --git a/drivers/clk/qcom/gcc-mdm9615.c b/drivers/clk/qcom/gcc-mdm9615.c
index 581a17f..e9e98b1 100644
--- a/drivers/clk/qcom/gcc-mdm9615.c
+++ b/drivers/clk/qcom/gcc-mdm9615.c
@@ -1563,6 +1563,34 @@ enum {
},
};
+static struct clk_branch ebi2_clk = {
+ .hwcg_reg = 0x2664,
+ .hwcg_bit = 6,
+ .halt_reg = 0x2fcc,
+ .halt_bit = 23,
+ .clkr = {
+ .enable_reg = 0x2664,
+ .enable_mask = BIT(6)|BIT(4),
+ .hw.init = &(struct clk_init_data){
+ .name = "ebi2_clk",
+ .ops = &clk_branch_ops,
+ },
+ },
+};
+
+static struct clk_branch ebi2_aon_clk = {
+ .halt_reg = 0x2fcc,
+ .halt_bit = 23,
+ .clkr = {
+ .enable_reg = 0x2664,
+ .enable_mask = BIT(8),
+ .hw.init = &(struct clk_init_data){
+ .name = "ebi2_always_on_clk",
+ .ops = &clk_branch_ops,
+ },
+ },
+};
+
static struct clk_hw *gcc_mdm9615_hws[] = {
&cxo.hw,
};
@@ -1637,6 +1665,8 @@ enum {
[PMIC_ARB1_H_CLK] = &pmic_arb1_h_clk.clkr,
[PMIC_SSBI2_CLK] = &pmic_ssbi2_clk.clkr,
[RPM_MSG_RAM_H_CLK] = &rpm_msg_ram_h_clk.clkr,
+ [EBI2_CLK] = &ebi2_clk.clkr,
+ [EBI2_AON_CLK] = &ebi2_aon_clk.clkr,
};
static const struct qcom_reset_map gcc_mdm9615_resets[] = {
diff --git a/include/dt-bindings/clock/qcom,gcc-mdm9615.h b/include/dt-bindings/clock/qcom,gcc-mdm9615.h
index 9ab2c40..57cdca6 100644
--- a/include/dt-bindings/clock/qcom,gcc-mdm9615.h
+++ b/include/dt-bindings/clock/qcom,gcc-mdm9615.h
@@ -323,5 +323,8 @@
#define CE3_H_CLK 305
#define USB_HS1_SYSTEM_CLK_SRC 306
#define USB_HS1_SYSTEM_CLK 307
+#define EBI2_CLK 309
+#define EBI2_AON_CLK 310
+
#endif
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 3/4] dt-bindings: mdm9615: Add NAND controller
From: Zoran Markovic @ 2016-12-22 20:05 UTC (permalink / raw)
To: linux-kernel
Cc: Zoran Markovic, Andy Gross, David Brown, Rob Herring,
Mark Rutland, Russell King, linux-arm-msm, linux-soc, devicetree,
linux-arm-kernel
In-Reply-To: <1482437139-29329-1-git-send-email-zmarkovic@sierrawireless.com>
Add dt description of NAND controller on MDM9615.
Cc: Andy Gross <andy.gross@linaro.org>
Cc: David Brown <david.brown@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-soc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Zoran Markovic <zmarkovic@sierrawireless.com>
---
arch/arm/boot/dts/qcom-mdm9615.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-mdm9615.dtsi b/arch/arm/boot/dts/qcom-mdm9615.dtsi
index fbc7d68..6d42ff3 100644
--- a/arch/arm/boot/dts/qcom-mdm9615.dtsi
+++ b/arch/arm/boot/dts/qcom-mdm9615.dtsi
@@ -373,6 +373,22 @@
qcom,ee = <0>;
};
+ nand0: nand@1b400000 {
+ compatible = "qcom,ipq806x-nand";
+ reg = <0x1b400000 0x800>;
+ clocks = <&gcc EBI2_CLK>,
+ <&gcc EBI2_AON_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = <&adm_dma 3>;
+ dma-names = "rxtx";
+ qcom,cmd-crci = <15>;
+ qcom,data-crci = <3>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
amba {
compatible = "arm,amba-bus";
#address-cells = <1>;
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 4/4] dt-bindings: wp8548: Add on-board NAND flash
From: Zoran Markovic @ 2016-12-22 20:05 UTC (permalink / raw)
To: linux-kernel
Cc: Zoran Markovic, Andy Gross, David Brown, Rob Herring,
Mark Rutland, Russell King, linux-arm-msm, linux-soc, devicetree,
linux-arm-kernel
In-Reply-To: <1482437139-29329-1-git-send-email-zmarkovic@sierrawireless.com>
Add description of NAND flash on Sierra Wireless WP8548 module
(and MangOH board).
Cc: Andy Gross <andy.gross@linaro.org>
Cc: David Brown <david.brown@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-soc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Zoran Markovic <zmarkovic@sierrawireless.com>
---
arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi | 50 ++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi b/arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi
index 7869898..a4d1158 100644
--- a/arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi
+++ b/arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi
@@ -54,6 +54,56 @@
};
};
+&nand0 {
+ nandcs@0 {
+ compatible = "qcom,nandcs";
+ reg = <0>;
+
+ linux,mtd-name = "micron,mt29f4g08";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ bootloader@0x051c0000 {
+ reg = <0x51c0000 0x100000>;
+ read-only;
+ };
+
+ kernel@0x052c0000 {
+ reg = <0x52c0000 0x1400000>;
+ read-only;
+ };
+
+ rootfs@0x066c0000 {
+ reg = <0x66c0000 0x3140000>;
+ read-only;
+ };
+
+ user0@0x09800000 {
+ reg = <0x9800000 0x2780000>;
+ };
+
+ user1@0x0bf80000 {
+ reg = <0xbf80000 0x8B80000>;
+ };
+
+ user2@0x14b00000 {
+ reg = <0x14b00000 0x500000>;
+ };
+
+ user3@0x15000000 {
+ reg = <0x15000000 0x200000>;
+ };
+ };
+ };
+};
+
&msmgpio {
pinctrl-0 = <&reset_out_pins>;
pinctrl-names = "default";
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v10 8/8] dt-bindings: mmc: Add Cavium SOCs MMC bindings
From: Rob Herring @ 2016-12-22 20:32 UTC (permalink / raw)
To: Jan Glauber
Cc: Ulf Hansson, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Daney, Steven J . Hill,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161219121552.18316-9-jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
On Mon, Dec 19, 2016 at 01:15:52PM +0100, Jan Glauber wrote:
> Add description of Cavium Octeon and ThunderX SOC device tree bindings.
>
> CC: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> Signed-off-by: Jan Glauber <jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/mmc/octeon-mmc.txt | 59 ++++++++++++++++++++++
Perhaps cavium-mmc.txt would be more appropriate now.
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/octeon-mmc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/octeon-mmc.txt b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
> new file mode 100644
> index 0000000..aad02eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
> @@ -0,0 +1,59 @@
> +* Cavium Octeon & ThunderX MMC controller
> +
> +The highspeed MMC host controller on Caviums SoCs provides an interface
> +for MMC and SD types of memory cards.
> +
> +Supported maximum speeds are the ones of the eMMC standard 4.41 as well
> +as the speed of SD standard 4.0. Only 3.3 Volt is supported.
> +
> +Required properties:
> + - compatible : should be one of:
> + * "cavium,octeon-6130-mmc"
> + * "cavium,octeon-6130-mmc-slot"
> + * "cavium,octeon-7890-mmc"
> + * "cavium,octeon-7890-mmc-slot"
> + * "cavium,thunder-8190-mmc"
> + * "cavium,thunder-8190-mmc-slot"
> + * "cavium,thunder-8390-mmc"
> + * "cavium,thunder-8390-mmc-slot"
> + - reg : mmc controller base registers
Following PCI addressing?
> + - clocks : phandle
> +
> +Optional properties:
> + - for cd, bus-width and additional generic mmc parameters
> + please refer to mmc.txt within this directory
> + - "cavium,cmd-clk-skew" : number of coprocessor clocks before sampling command
> + - "cavium,dat-clk-skew" : number of coprocessor clocks before sampling data
> +
> +Deprecated properties:
> +- spi-max-frequency : use max-frequency instead
> +- "cavium,bus-max-width" : use bus-width instead
Drop the quotes.
> +
> +Examples:
> + - Within .dtsi:
Don't show the division between files in the example.
> + mmc_1_4: mmc@1,4 {
> + compatible = "cavium,thunder-8390-mmc";
> + reg = <0x0c00 0 0 0 0>; /* DEVFN = 0x0c (1:4) */
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&sclk>;
> + };
> +
> + - Within dts:
> + mmc-slot@0 {
Need to show this is a child node.
> + compatible = "cavium,thunder-8390-mmc-slot";
> + reg = <0>;
> + voltage-ranges = <3300 3300>;
> + max-frequency = <42000000>;
> + bus-width = <4>;
> + cap-sd-highspeed;
> + };
> + mmc-slot@1 {
> + compatible = "cavium,thunder-8390-mmc-slot";
> + reg = <1>;
> + voltage-ranges = <3300 3300>;
> + max-frequency = <42000000>;
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + non-removable;
> + };
> --
> 2.9.0.rc0.21.g7777322
>
--
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] gpio: of: Add support for multiple GPIOs in a single GPIO hog
From: Rob Herring @ 2016-12-22 20:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Alexandre Courbot, Mark Rutland, linux-gpio,
devicetree
In-Reply-To: <1482171694-18237-1-git-send-email-geert@linux-m68k.org>
On Mon, Dec 19, 2016 at 07:21:34PM +0100, Geert Uytterhoeven wrote:
> When listing multiple GPIOs in the "gpios" property of a GPIO hog, only
> the first GPIO is affected. The user is left clueless about the
> disfunctioning of the other GPIOs specified.
>
> Fix this by adding and documenting support for specifying multiple
> GPIOs in a single GPIO hog.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Documentation/devicetree/bindings/gpio/gpio.txt | 8 +++----
> drivers/gpio/gpiolib-of.c | 31 ++++++++++++++++---------
> 2 files changed, 24 insertions(+), 15 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] clk: hi3660: Clock driver support for Hisilicon hi3660 SoC
From: Stephen Boyd @ 2016-12-22 20:51 UTC (permalink / raw)
To: zhangfei
Cc: Rob Herring, Arnd Bergmann, haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A,
guodong Xu, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <fc7bebd2-ad03-6479-d6e7-42f5d724216c-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 12/22, zhangfei wrote:
> On 2016年12月22日 07:25, Stephen Boyd wrote:
> >On 12/15, Zhangfei Gao wrote:
> >>Signed-off-by: Zhangfei Gao <zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >
> >>+
> >>+ switch (type) {
> >>+ case HI3660_CRGCTRL:
> >>+ hi3660_clk_crgctrl_init(np);
> >>+ break;
> >>+ case HI3660_PCTRL:
> >>+ hi3660_clk_pctrl_init(np);
> >>+ break;
> >>+ case HI3660_PMUCTRL:
> >>+ hi3660_clk_pmuctrl_init(np);
> >>+ break;
> >>+ case HI3660_SCTRL:
> >>+ hi3660_clk_sctrl_init(np);
> >>+ break;
> >>+ case HI3660_IOMCU:
> >>+ hi3660_clk_iomcu_init(np);
> >>+ break;
> >This "multi-device" driver design is sort of odd. Why not have
> >different files and struct drivers for the different devices in
> >the system that are clock controllers? I don't really understand
> >why we're controlling the devices with one struct driver
> >instance. Is something shared between the devices?
> Do you mean put in different .c / drivers?
Yes.
> They have to be put in the same file, since the parent / child
> relate to each other.
We handle clk parent/child relationships through strings. So why
does that mean we need to put these in the same file with the
same struct driver?
> They are for the same chip, but some put in different region for
> privilege control.
Ok.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/21] MIPS memblock: Unpin dts memblock sanity check method
From: Rob Herring @ 2016-12-22 20:57 UTC (permalink / raw)
To: Serge Semin
Cc: Ralf Baechle, Paul Burton, rabinv-VrBV9hrLPhE,
matt.redfearn-1AXoQHu6uovQT0dZR+AlfA, James Hogan,
Alexander Sverdlin, Frank Rowand,
Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA, Linux-MIPS,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1482113266-13207-2-git-send-email-fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sun, Dec 18, 2016 at 8:07 PM, Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> It's necessary to check whether retrieved from dts memory regions
> fits to page alignment and limits restrictions. Sometimes it is
> necessary to perform the same checks, but ito add the memory regions
s/ito/to/
> into a different subsystem. MIPS is going to be that case.
>
> Signed-off-by: Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/of/fdt.c | 47 +++++++++++++++++++++++---------
> include/linux/of_fdt.h | 1 +
> 2 files changed, 35 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 1f98156..1ee958f 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -983,44 +983,65 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
> #define MAX_MEMBLOCK_ADDR ((phys_addr_t)~0)
> #endif
>
> -void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
> +int __init sanity_check_dt_memory(phys_addr_t *out_base,
> + phys_addr_t *out_size)
As kbuild robot found, you don't want to use phys_addr_t here.
phys_addr_t varies with kernel config such as LPAE on ARM and the DT
does not.
> {
> + phys_addr_t base = *out_base, size = *out_size;
> const u64 phys_offset = MIN_MEMBLOCK_ADDR;
>
> if (!PAGE_ALIGNED(base)) {
> if (size < PAGE_SIZE - (base & ~PAGE_MASK)) {
> - pr_warn("Ignoring memory block 0x%llx - 0x%llx\n",
> + pr_err("Memblock 0x%llx - 0x%llx isn't page aligned\n",
These are not errors. The page alignment is an OS restriction. h/w
(which the DT describes) generally has little concept of page size
outside the MMUs.
Too many unrelated changes in this patch. Add the error return only
and make anything else a separate patch (though I would just drop
everything else).
I've not looked at the rest of the series, but why can't MIPS migrate
to using memblock directly and using the default DT functions using
memblock?
Rob
--
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
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