Re: [PATCH 07/15] dmaengine: dw: revisit data_width property
On Sun, Jan 24, 2016 at 07:21:54PM +, Mans Rullgard wrote: > From: Andy Shevchenko > > There are several changes are done here: > > - Convert the property to be in bytes > >Much more convenient than keeping encoded value. > > - Use one value for all AHB masters for now > >It seems in practice we have no controllers where masters have different >data bus width, we still might return to distinct values when there is a > use >case. > > - Rename data_width to data-width in the device tree bindings. > > - While here, replace dwc_fast_ffs() by __ffs(). > > Signed-off-by: Andy Shevchenko > Signed-off-by: Mans Rullgard > --- > This patch changes the DT binding, so it should probably be amended for > compatibility with old device trees. I've included it as is since I think > the change as such is good. Just because you update the dts files, it doesn't make the change okay. I'm fine with the DT change, but the driver would have to support both old and new property names. Doesn't really seem worth doing to me. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/9] ARC: [dts] Introduce Timer bindings
On Tue, Feb 02, 2016 at 04:28:52PM +0530, Vineet Gupta wrote:
> ARC Timers have historically been probed directly.
> As precursor to start probing Timers thru DT introduce these bindings
>
> Cc: Daniel Lezcano
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Vineet Gupta
> ---
> .../devicetree/bindings/timer/snps,arc-timer0.txt | 23
> ++
> .../devicetree/bindings/timer/snps,arc-timer1.txt | 17
> .../devicetree/bindings/timer/snps,archs-gfrc.txt | 14 +
> .../devicetree/bindings/timer/snps,archs-rtc.txt | 14 +
> arch/arc/boot/dts/abilis_tb10x.dtsi| 12 +++
> arch/arc/boot/dts/skeleton.dtsi| 12 +++
> arch/arc/boot/dts/skeleton_hs.dtsi | 12 +++
> arch/arc/boot/dts/skeleton_hs_idu.dtsi | 12 +++
> 8 files changed, 116 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/timer/snps,arc-timer0.txt
> create mode 100644
> Documentation/devicetree/bindings/timer/snps,arc-timer1.txt
> create mode 100644
> Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
> create mode 100644 Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/snps,arc-timer0.txt
> b/Documentation/devicetree/bindings/timer/snps,arc-timer0.txt
> new file mode 100644
> index ..ceb80c72a90b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/snps,arc-timer0.txt
> @@ -0,0 +1,23 @@
> +Synopsys ARC Local Timer with Interrupt Capabilities
> +- Found on all ARC CPUs (ARC700/ARCHS)
> +- Mandatory clockevent provider
> +
> +Required properties:
> +
> +- compatible : should be "snps,arc-timer0"
timer0 and timer1 are different h/w blocks, not just different
instances?
> +- interrupts : single Interrupt going into parent intc
> +(16 for ARCHS cores, 3 for ARC700 cores)
> +- clocks : phandle to the source clock
> +
> +Optional properties:
> +
> +- interrupt-parent : phandle to parent intc
> +
> +Example:
> +
> + timer0: timer_clkevt {
just "timer" for node name. clkevt is a Linuxism.
> + compatible = "snps,arc-timer0";
> + interrupts = <3>;
> + interrupt-parent = <&core_intc>;
> + clocks = <&timer0_clk>;
> + };
> diff --git a/Documentation/devicetree/bindings/timer/snps,arc-timer1.txt
> b/Documentation/devicetree/bindings/timer/snps,arc-timer1.txt
> new file mode 100644
> index ..4886192ce2f2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/snps,arc-timer1.txt
> @@ -0,0 +1,17 @@
> +Synopsys ARC Free Running Local 32-bit Timer
> +- Found on all ARC CPUs (ARC700/ARCHS)
> +- Mandatory clocksource provider on ARC700
> +- Optional clocksource provider on UP ARC HS CPUs
> + (and if better timer archs-rtc not available in SoC)
> +
> +Required properties:
> +
> +- compatible : should be "snps,arc-timer1"
> +- clocks : phandle to the source clock
No interrupt because it doesn't have one or you use this as a
clocksource and don't need it?
> +
> +Example:
> +
> + timer1: timer_clksrc {
> + compatible = "snps,arc-timer1";
> + clocks = <&timer0_clk>;
> + };
> diff --git a/Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
> b/Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
> new file mode 100644
> index ..cce60e16aa0d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
> @@ -0,0 +1,14 @@
> +Synopsys ARC Free Running 64-bit Global Timer for ARC HS CPUs
> +- clocksourc provider for SMP SoC
> +
> +Required properties:
> +
> +- compatible : should be "snps,archs-gfrc"
> +- clocks : phandle to the source clock
> +
> +Example:
> +
> + timer1: timer_clksrc {
> + compatible = "snps,archs-gfrc";
> + clocks = <&timer0_clk>;
> + };
> diff --git a/Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
> b/Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
> new file mode 100644
> index ..f3b49938812b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
> @@ -0,0 +1,14 @@
> +Synopsys ARC Free Running 64-bit Local Timer for ARC HS CPUs
> +- clocksourc provider for UP SoC
local timer on a UP processor?
> +
> +Required properties:
> +
> +- compatible : should be "snps,archs-rtc"
> +- clocks : phandle to the source clock
> +
> +Example:
> +
> + timer1: timer_clksrc {
> + compatible = "snps,arc-rtc";
> + clocks = <&timer0_clk>;
> + };
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/9] ARC: [dts] Introduce Timer bindings
On Wed, Feb 3, 2016 at 2:04 AM, Vineet Gupta wrote:
> Hi Rob,
>
> On Wednesday 03 February 2016 03:33 AM, Rob Herring wrote:
>> On Tue, Feb 02, 2016 at 04:28:52PM +0530, Vineet Gupta wrote:
>>> +Required properties:
>>> +
>>> +- compatible : should be "snps,arc-timer0"
>>
>> timer0 and timer1 are different h/w blocks, not just different
>> instances?
>
> Functionality wise they are identical (only the address of aux regs used to
> program them are different). Either can be configured to interrupt-on-limit or
> free-run-and-wrap-around. So we can indeed consider them 2 instances. ARC
> Linux
> uses timer0 for tick handling, timer1 for gtod.
>
> Do you prefer they not be differentiated as timer0 and timer1 ?
>
> So we have
>
> CLOCKSOURCE_OF_DECLARE(arc_clkevt, "snps,arc-timer0", arc_clockevent_setup);
> CLOCKSOURCE_OF_DECLARE(arc_timer1, "snps,arc-timer1", arc_cs_setup_timer1);
>
> I don't know how to achieve above, by keeping the DT names the same.
You just need a single CLOCKSOURCE_OF_DECLARE which will be called
twice. On the first call, setup one timer and on the 2nd call setup
the other one. IIRC the sp804 timer has something similar.
You'll need a unit address in the node name to distinguish them.
>
>>
>>> +- interrupts : single Interrupt going into parent intc
>>> + (16 for ARCHS cores, 3 for ARC700 cores)
>>> +- clocks : phandle to the source clock
>>> +
>>> +Optional properties:
>>> +
>>> +- interrupt-parent : phandle to parent intc
>>> +
>>> +Example:
>>> +
>>> +timer0: timer_clkevt {
>>
>> just "timer" for node name. clkevt is a Linuxism.
>
> OK. So to document that this is for clockevent, change the label ?
That shouldn't be documented in the DT at all.
>
> timer_clkevent: timer {
>
>>
>>> +compatible = "snps,arc-timer0";
>>> +interrupts = <3>;
>>> +interrupt-parent = <&core_intc>;
>>> +clocks = <&timer0_clk>;
>>> +};
>>> diff --git a/Documentation/devicetree/bindings/timer/snps,arc-timer1.txt
>>> b/Documentation/devicetree/bindings/timer/snps,arc-timer1.txt
>>> new file mode 100644
>>> index ..4886192ce2f2
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/timer/snps,arc-timer1.txt
>>> @@ -0,0 +1,17 @@
>>> +Synopsys ARC Free Running Local 32-bit Timer
>>> +- Found on all ARC CPUs (ARC700/ARCHS)
>>> +- Mandatory clocksource provider on ARC700
>>> +- Optional clocksource provider on UP ARC HS CPUs
>>> + (and if better timer archs-rtc not available in SoC)
>>> +
>>> +Required properties:
>>> +
>>> +- compatible : should be "snps,arc-timer1"
>>> +- clocks : phandle to the source clock
>>
>> No interrupt because it doesn't have one or you use this as a
>> clocksource and don't need it?
>
> Latter !
Then you should have the interrupt in the DT anyway.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/4] drm: Add DT bindings documentation for ARC PGU display controller
On Fri, Feb 19, 2016 at 04:03:52PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
>
> Signed-off-by: Alexey Brodkin
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> ---
> .../devicetree/bindings/display/snps,arcpgu.txt| 74
> ++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
>
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..c8382fb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,74 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> + - compatible: "snps,arcpgu"
Seems like this should be more specific. Is there some sort or
versioning with ARC blocks?
> + - reg: Physical base address and length of the controller's registers.
> + - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> + - clock-names: A list of clock names. For ARC PGU it should contain:
> + - "pxlclk" for the clock feeding the output PLL of the controller.
> + - encoder-slave: Phandle of encoder chip.
This is unnecessary with the OF graph.
> +
> +Required sub-nodes:
> + - port: The PGU connection to an encoder chip. The connection is modelled
> +using the OF graph bindings specified in
> +Documentation/devicetree/bindings/graph.txt.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@0x {
Unit address should not have '0x'
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <&clock_node>;
> + clock-names = "pxlclk";
> + encoder-slave = <&encoder_node>;
> +
> + port {
> + pgu_output: endpoint {
> + remote-endpoint = <&hdmi_enc_input>;
> + };
> + };
> + };
> +
> + /* HDMI encoder on I2C bus */
> + i2c@0x {
> + compatible = "...";
> +
> + encoder_node:encoder_node@0x{
I2C addresses would be 8-bit only.
> + compatible="...";
> +
> + ports {
> + port@0 {
> + reg = <0>;
> + hdmi_enc_input:endpoint {
> + remote-endpoint = <&pgu_output>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + hdmi_enc_output:endpoint {
> + remote-endpoint =
> <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> + }
> +
> + hdmi0: connector {
> + compatible = "hdmi-connector";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_enc_output>;
> + };
> + };
> + };
> +};
> --
> 2.5.0
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/4 v2] drm: Add DT bindings documentation for ARC PGU display controller
On Thu, Mar 03, 2016 at 05:39:14PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
>
> Signed-off-by: Alexey Brodkin
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> ---
>
> Changes v1 -> v2:
> * Clean-up
Not really useful. What we like to see is what changed. Maintainers have
short memories and don't remember what they said previously (unless
comments are ignored).
>
> .../devicetree/bindings/display/snps,arcpgu.txt| 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
>
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..57f3bc8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,33 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> + - compatible: "snps,arcpgu"
> + - reg: Physical base address and length of the controller's registers.
> + - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> + - clock-names: A list of clock names. For ARC PGU it should contain:
> + - "pxlclk" for the clock feeding the output PLL of the controller.
> +
> +Required sub-nodes:
> + - port: The PGU connection to an encoder chip. The connection is modelled
> +using the OF graph bindings specified in
> +Documentation/devicetree/bindings/graph.txt.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@ {
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <&clock_node>;
> + clock-names = "pxlclk";
Where's the port? Didn't you previously say it was optional?
> + };
> +
> + ...
> +};
> --
> 2.5.0
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/4] drm: Add DT bindings documentation for ARC PGU display controller
On Thu, Mar 3, 2016 at 7:58 AM, Alexey Brodkin wrote: > Hi Rob, > > On Tue, 2016-02-23 at 14:38 -0600, Rob Herring wrote: >> On Fri, Feb 19, 2016 at 04:03:52PM +0300, Alexey Brodkin wrote: >> > >> > This add DT bindings documentation for ARC PGU display controller. >> > >> > Signed-off-by: Alexey Brodkin >> > Cc: Rob Herring >> > Cc: Pawel Moll >> > Cc: Mark Rutland >> > Cc: Ian Campbell >> > Cc: Kumar Gala >> > Cc: devicet...@vger.kernel.org >> > Cc: linux-snps-arc@lists.infradead.org >> > --- >> > .../devicetree/bindings/display/snps,arcpgu.txt| 74 >> > ++ >> > 1 file changed, 74 insertions(+) >> > create mode 100644 >> > Documentation/devicetree/bindings/display/snps,arcpgu.txt >> > >> > diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt >> > b/Documentation/devicetree/bindings/display/snps,arcpgu.txt >> > new file mode 100644 >> > index 000..c8382fb >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt >> > @@ -0,0 +1,74 @@ >> > +ARC PGU >> > + >> > +This is a display controller found on several development boards produced >> > +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a >> > +framebuffer and sends it to a single digital encoder (usually HDMI). >> > + >> > +Required properties: >> > + - compatible: "snps,arcpgu" >> Seems like this should be more specific. Is there some sort or >> versioning with ARC blocks? > > Well as of today there's only one and only version of PGU. > So is there a real need for "snps,arcpgu-1.0"? > >> > >> > + - reg: Physical base address and length of the controller's registers. >> > + - clocks: A list of phandle + clock-specifier pairs, one for each >> > +entry in 'clock-names'. >> > + - clock-names: A list of clock names. For ARC PGU it should contain: >> > + - "pxlclk" for the clock feeding the output PLL of the controller. >> > + - encoder-slave: Phandle of encoder chip. >> This is unnecessary with the OF graph. > > Do you mean I may drop "encoder-slave" from bindings description? Yes, you should drop it. > I actually thought about that because in case of simulation platform where > this device is also used there's no encoder as well as no connector - we're > dealing with memory area which is read by host and then displayed on host's > display. > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/9] ARC: [dts] Introduce Timer bindings
On Tue, Mar 08, 2016 at 05:56:05PM +0530, Vineet Gupta wrote:
> ARC Timers have historically been probed directly.
> As precursor to start probing Timers thru DT introduce these bindings
> Note that to keep series bisectable, these bindings are not yet used in
> code.
>
> Cc: Daniel Lezcano
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Vineet Gupta
> ---
> Changes v1 -> v2
> - snps,arc-timer[0-1] folded into single snps-arc-timer [Rob]
> - Node name in DT example fixed: [Rob]
> "timer1: timer_clksrc {" -> timer@1 {
> - Introduced 64bit RTC in skeleton_hs.dtsi [Vineet]
>
> v1:
> -
> http://lists.infradead.org/pipermail/linux-snps-arc/2016-February/000447.html
>
> Signed-off-by: Vineet Gupta
> ---
> .../devicetree/bindings/timer/snps,arc-timer.txt | 26
> ++
> .../devicetree/bindings/timer/snps,archs-gfrc.txt | 14
> .../devicetree/bindings/timer/snps,archs-rtc.txt | 14
> arch/arc/boot/dts/abilis_tb10x.dtsi| 14
> arch/arc/boot/dts/skeleton.dtsi| 14
> arch/arc/boot/dts/skeleton_hs.dtsi | 20 +
> arch/arc/boot/dts/skeleton_hs_idu.dtsi | 14
> 7 files changed, 116 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/snps,arc-timer.txt
> create mode 100644
> Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
> create mode 100644 Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/snps,arc-timer.txt
> b/Documentation/devicetree/bindings/timer/snps,arc-timer.txt
> new file mode 100644
> index ..9e02be24e805
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/snps,arc-timer.txt
> @@ -0,0 +1,26 @@
> +Synopsys ARC Local Timer with Interrupt Capabilities
> +- Found on all ARC CPUs (ARC700/ARCHS)
> +- Can be optionally programmed to interrupt on Limit
> +- Two idential copies TIMER0 and TIMER1 exist in ARC cores and historically
> + TIMER0 used as clockevent provider (true for all ARC cores)
> + TIMER1 used for clocksource (mandatory for ARC700, optional for ARC HS)
> +
> +Required properties:
> +
> +- compatible : should be "snps,arc-timer"
> +- interrupts : single Interrupt going into parent intc
> +(16 for ARCHS cores, 3 for ARC700 cores)
> +- clocks : phandle to the source clock
> +
> +Optional properties:
> +
> +- interrupt-parent : phandle to parent intc
> +
> +Example:
> +
> + timer@0 {
Use of unit addresses without reg property is going to start generating
warnings. I would just use "timer0" in this case.
> + compatible = "snps,arc-timer0";
s/timer0/timer/
> + interrupts = <3>;
> + interrupt-parent = <&core_intc>;
> + clocks = <&core_clk>;
> + };
> diff --git a/Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
> b/Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
> new file mode 100644
> index ..aaab100f54e7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
> @@ -0,0 +1,14 @@
> +Synopsys ARC Free Running 64-bit Global Timer for ARC HS CPUs
> +- clocksource provider for SMP SoC
> +
> +Required properties:
> +
> +- compatible : should be "snps,archs-gfrc"
> +- clocks : phandle to the source clock
> +
> +Example:
> +
> + timer@1 {
> + compatible = "snps,archs-gfrc";
> + clocks = <&core_clk>;
> + };
> diff --git a/Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
> b/Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
> new file mode 100644
> index ..13f756fa1d6d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
> @@ -0,0 +1,14 @@
> +Synopsys ARC Free Running 64-bit Local Timer for ARC HS CPUs
> +- clocksource provider for UP SoC
> +
> +Required properties:
> +
> +- compatible : should be "snps,archs-rtc"
> +- clocks : phandle to the source clock
> +
> +Example:
> +
> + timer@1 {
rtc {
And then similar updates in the dts files.
> + compatible = "snps,arc-rtc";
> + clocks = <&core_clk>;
> + };
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3] ARC: [dts] Introduce Timer bindings
On Fri, Mar 18, 2016 at 10:56:29AM +0530, Vineet Gupta wrote:
> ARC Timers have historically been probed directly.
> As precursor to start probing Timers thru DT introduce these bindings
> Note that to keep series bisectable, these bindings are not yet used in
> code.
>
> Cc: Daniel Lezcano
> Cc: Rob Herring
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Vineet Gupta
> ---
> v3:
> - Renamed Node name to avoid new warnings when unit address used w/o regs
> [Rob]
> v2:
> - http://lists.infradead.org/pipermail/linux-snps-arc/2016-March/000653.html
> - snps,arc-timer[0-1] folded into single snps-arc-timer [Rob]
> - Node name in DT example fixed: [Rob]
> "timer1: timer_clksrc {" -> timer@1 {
> - Introduced 64bit RTC in skeleton_hs.dtsi [Vineet]
> v1:
> -
> http://lists.infradead.org/pipermail/linux-snps-arc/2016-February/000447.html
> ---
> .../devicetree/bindings/timer/snps,arc-timer.txt | 32
> ++
> .../devicetree/bindings/timer/snps,archs-gfrc.txt | 14 ++
> .../devicetree/bindings/timer/snps,archs-rtc.txt | 14 ++
> arch/arc/boot/dts/abilis_tb10x.dtsi| 14 ++
> arch/arc/boot/dts/skeleton.dtsi| 14 ++
> arch/arc/boot/dts/skeleton_hs.dtsi | 20 ++
> arch/arc/boot/dts/skeleton_hs_idu.dtsi | 14 ++
> 7 files changed, 122 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/timer/snps,arc-timer.txt
> create mode 100644
> Documentation/devicetree/bindings/timer/snps,archs-gfrc.txt
> create mode 100644 Documentation/devicetree/bindings/timer/snps,archs-rtc.txt
Acked-by: Rob Herring
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/4 v3] drm: Add DT bindings documentation for ARC PGU display controller
On Fri, Mar 11, 2016 at 06:42:37PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
>
> Signed-off-by: Alexey Brodkin
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> ---
>
> Changes v2 -> v3:
> * Reverted back to initial larger version of example
>with minor fixes (thanks Rob for spotting those).
>
> Changes v1 -> v2:
> * Removed everything except PGU node itself.
>
> .../devicetree/bindings/display/snps,arcpgu.txt| 72
> ++
> 1 file changed, 72 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
>
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..b130924
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,72 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> + - compatible: "snps,arcpgu"
> + - reg: Physical base address and length of the controller's registers.
> + - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> + - clock-names: A list of clock names. For ARC PGU it should contain:
> + - "pxlclk" for the clock feeding the output PLL of the controller.
> + - encoder-slave: Phandle of encoder chip.
Drop this as discussed.
> +
> +Required sub-nodes:
> + - port: The PGU connection to an encoder chip.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@ {
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <&clock_node>;
> + clock-names = "pxlclk";
> + encoder-slave = <&encoder_node>;
> +
> + port {
> + pgu_output: endpoint {
> + remote-endpoint = <&hdmi_enc_input>;
> + };
> + };
> + };
> +
> + /* HDMI encoder on I2C bus */
> + i2c@ {
> + compatible = "...";
> +
> + encoder_node:encoder_node@0xXX{
Don't use underscores in node names. Just "hdmi@xx"
> + compatible="...";
> +
> + ports {
> + port@0 {
> + reg = <0>;
> + hdmi_enc_input:endpoint {
> + remote-endpoint = <&pgu_output>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + hdmi_enc_output:endpoint {
> + remote-endpoint =
> <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> + }
> +
> + hdmi0: connector {
> + compatible = "hdmi-connector";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_enc_output>;
> + };
> + };
> + };
> +};
> --
> 2.5.0
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/5 v4] drm: Add DT bindings documentation for ARC PGU display controller
On Thu, Mar 24, 2016 at 07:48:33PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
>
> Signed-off-by: Alexey Brodkin
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> ---
>
> Changes v3 -> v4: (addressing Rob's comments)
> * Removed "encoder-slave" from required properties
> * Removed "0x" from node names
>
> Changes v2 -> v3:
> * Reverted back to initial larger version of example
>with minor fixes (thanks Rob for spotting those).
>
> Changes v1 -> v2:
> * Removed everything except PGU node itself.
>
> .../devicetree/bindings/display/snps,arcpgu.txt| 71
> ++
> 1 file changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
>
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..b126577
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,71 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> + - compatible: "snps,arcpgu"
> + - reg: Physical base address and length of the controller's registers.
> + - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> + - clock-names: A list of clock names. For ARC PGU it should contain:
> + - "pxlclk" for the clock feeding the output PLL of the controller.
> +
> +Required sub-nodes:
> + - port: The PGU connection to an encoder chip.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@ {
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <&clock_node>;
> + clock-names = "pxlclk";
> + encoder-slave = <&encoder_node>;
Still in the example...
Otherwise,
Acked-by: Rob Herring
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2 v5] clk/axs10x: Add I2S PLL clock driver
On Tue, Apr 12, 2016 at 10:14:22AM +0100, Jose Abreu wrote:
> The ARC SDP I2S clock can be programmed using a
> specific PLL.
>
> This patch has the goal of adding a clock driver
> that programs this PLL.
>
> At this moment the rate values are hardcoded in
> a table but in the future it would be ideal to
> use a function which determines the PLL values
> given the desired rate.
>
> Signed-off-by: Jose Abreu
> ---
>
> Changes v4 -> v5:
> * Documentation update (as suggested by Alexey Brodkin)
> * Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by
> Alexey Brodkin)
>
> Changes v3 -> v4:
> * Added binding document (as suggested by Stephen Boyd)
> * Minor code style fixes (as suggested by Stephen Boyd)
> * Use ioremap (as suggested by Stephen Boyd)
> * Implement round_rate (as suggested by Stephen Boyd)
> * Change to platform driver (as suggested by Stephen Boyd)
> * Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
>
> Changes v2 -> v3:
> * Implemented recalc_rate
>
> Changes v1 -> v2:
> * Renamed folder to axs10x (as suggested by Alexey Brodkin)
> * Added more supported rates
>
> .../bindings/clock/axs10x-i2s-pll-clock.txt| 17 ++
Acked-by: Rob Herring
> drivers/clk/Makefile | 1 +
> drivers/clk/axs10x/Makefile| 1 +
> drivers/clk/axs10x/i2s_pll_clock.c | 217
> +
> 4 files changed, 236 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
> create mode 100644 drivers/clk/axs10x/Makefile
> create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2 v5] ASoC: dwc: Update DOCUMENTATION for I2S Driver
On Tue, Apr 12, 2016 at 01:56:28PM +0100, Jose Abreu wrote: > This patch updates documentation for the Designware I2S > driver. > > Signed-off-by: Jose Abreu > --- > > Changes v4 -> v5: > * interrupts is now required property > * Drop 'snps-use-dmaengine' property > > This patch was only introduced in v4. > > Documentation/devicetree/bindings/sound/designware-i2s.txt | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) Acked-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [RESEND PATCH 1/2 v6] clk/axs10x: Add I2S PLL clock driver
On Mon, May 02, 2016 at 10:39:05AM +0100, Jose Abreu wrote:
> The ARC SDP I2S clock can be programmed using a
> specific PLL.
>
> This patch has the goal of adding a clock driver
> that programs this PLL.
>
> At this moment the rate values are hardcoded in
> a table but in the future it would be ideal to
> use a function which determines the PLL values
> given the desired rate.
>
> Signed-off-by: Jose Abreu
> ---
>
> Changes v5 -> v6:
> * Use parent clock to determine PLL input rate instead of using hardcoded
> values
> * Documentation update (added 'clocks' field)
>
> Changes v4 -> v5:
> * Documentation update (as suggested by Alexey Brodkin)
> * Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by
> Alexey Brodkin)
>
> Changes v3 -> v4:
> * Added binding document (as suggested by Stephen Boyd)
> * Minor code style fixes (as suggested by Stephen Boyd)
> * Use ioremap (as suggested by Stephen Boyd)
> * Implement round_rate (as suggested by Stephen Boyd)
> * Change to platform driver (as suggested by Stephen Boyd)
> * Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
>
> Changes v2 -> v3:
> * Implemented recalc_rate
>
> Changes v1 -> v2:
> * Renamed folder to axs10x (as suggested by Alexey Brodkin)
> * Added more supported rates
>
> Cc: Carlos Palminha
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian Campbell
> Cc: Kumar Gala
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: Alexey Brodkin
> Cc: Vineet Gupta
> Cc: linux-snps-arc@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
>
> .../bindings/clock/axs10x-i2s-pll-clock.txt| 25 +++
Acked-by: Rob Herring
> drivers/clk/Makefile | 1 +
> drivers/clk/axs10x/Makefile| 1 +
> drivers/clk/axs10x/i2s_pll_clock.c | 228
> +
> 4 files changed, 255 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
> create mode 100644 drivers/clk/axs10x/Makefile
> create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 4/4 v7] ASoC: dwc: Add irq parameter to DOCUMENTATION
On Mon, May 23, 2016 at 11:02:25AM +0100, Jose Abreu wrote: > A parameter description for the interruptions of the > I2S controller was added. This interrupt parameter > should only be set when I2S does not have DMA support. > > Signed-off-by: Jose Abreu > Cc: Carlos Palminha > Cc: Mark Brown > Cc: Liam Girdwood > Cc: Jaroslav Kysela > Cc: Takashi Iwai > Cc: Rob Herring > Cc: Alexey Brodkin > Cc: linux-snps-arc@lists.infradead.org > Cc: alsa-de...@alsa-project.org > Cc: devicet...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > --- > > Changes v6 -> v7: > * interrupts is now optional property > > No changes v5 -> v6. > > Changes v4 -> v5: > * interrupts is now required property > * Drop 'snps-use-dmaengine' property > > This patch was only introduced in v4. > > Documentation/devicetree/bindings/sound/designware-i2s.txt | 4 > 1 file changed, 4 insertions(+) Acked-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 4/4] Update device tree Synopsys DW DMAC documentation
On Wed, Nov 16, 2016 at 12:08 PM, Andy Shevchenko wrote: > On Wed, 2016-11-16 at 17:01 +, Eugeniy Paltsev wrote: >> On Wed, 2016-11-16 at 17:10 +0200, Andy Shevchenko wrote: >> > Overall, since we are going to expose some properties to the Device >> > Tree >> > I would really think twice about naming. Better if we reuse >> > something >> > existing already. >> > >> > So, what I can see is >> > >> > dmacap,private >> > dmacap,memcpy >> > >> > Here is a selling point as well, i.e. standardization. >> > >> >> As I can see these property name used only in "mv_xor" driver. And >> they are marked as deprecated. >> So, I'm not sure if I should used these names. > > Oh, good catch! So, then I leave this to DT experienced guys to decide. > Rob? Well, maybe they were deprecated for a reason? This all seems like user configuration to me. So either they don't belong in DT or should be common if they do. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2] dt-bindings: Document the Synopsys DW AXI DMA bindings
On Wed, Jan 25, 2017 at 06:34:16PM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> DesignWare AXI DMA controller.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> .../devicetree/bindings/dma/snps,axi-dw-dmac.txt | 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt
> b/Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt
> new file mode 100644
> index 000..21318a7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt
> @@ -0,0 +1,33 @@
> +* Synopsys DesignWare AXI DMA Controller
> +
> +Required properties:
> +- compatible: "snps,axi-dma"
Too generic. This needs an IP version at least.
> +- reg: Address range of the DMAC registers. This should include
> + all of the per-channel registers.
> +- interrupt: Should contain the DMAC interrupt number.
> +- interrupt-parent: Should be the phandle for the interrupt controller
> + that services interrupts for this device.
> +- dma-channels: Number of channels supported by hardware.
> +- dma-masters: Number of AXI masters supported by the hardware.
> +- data-width: Maximum AXI data width supported by hardware.
> + (0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)
> +- priority: Priority of channel. Array property. Priority value must be
> + programmed within [0:dma-channels-1] range. (0 - minimum priority)
> +- block-size: Maximum block size supported by the controller channel. Array
> + property.
Array size equal to the number of dma-channels?
Other than dma-channels, all these either need vendor prefix.
> +
> +Example:
> +
> +dmac: dmac@8 {
dma-controller@...
> + compatible = "snps,axi-dma";
> + reg = <0x8 0x400>;
> + clocks = <&core_clk>;
> + interrupt-parent = <&intc>;
> + interrupts = <27>;
> +
> + dma-channels = <4>;
> + dma-masters = <2>;
> + data-width = <3>;
> + block-size = <4096 4096 4096 4096>;
> + priority = <0 1 2 3>;
> +};
> --
> 2.5.5
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v1 1/2] dt-bindings: Document the Synopsys DW AXI DMA bindings
On Tue, Feb 21, 2017 at 11:38:03PM +0300, Eugeniy Paltsev wrote: > This patch adds documentation of device tree bindings for the Synopsys > DesignWare AXI DMA controller. > > Signed-off-by: Eugeniy Paltsev > --- > .../devicetree/bindings/dma/snps,axi-dw-dmac.txt | 34 > ++ > 1 file changed, 34 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/snps,axi-dw-dmac.txt Acked-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arc: Add "include chroot" for DT bindings
On Tue, May 30, 2017 at 8:22 AM, Alexey Brodkin
wrote:
> Basically this extends
> c58299aa8754 "kbuild: create an "include chroot" for DT bindings" for
> ARC where we extensively use Device Tree and there're good reasons
> to use DT bindings, especially if those are required.
>
> Otherwise on attempt to compile .dts with something like:
> >8-
> #include
> >8-
>
> we inevitably see this compilation failure:
> >8-
> arch/arc/boot/dts/hsdk.dts:16:40: fatal error: dt-bindings/net/ti-dp83867.h:
> No such file or directory
> #include
> ^
> compilation terminated.
> ---->8-
>
> Signed-off-by: Alexey Brodkin
> Cc: Stephen Warren
> Cc: Rob Herring
> ---
> arch/arc/boot/dts/include/dt-bindings | 1 +
> 1 file changed, 1 insertion(+)
> create mode 12 arch/arc/boot/dts/include/dt-bindings
I believe commit d5d332d3f7e8 ("devicetree: Move include prefixes from
arch to separate directory") does what you want.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board
On Mon, Jun 26, 2017 at 10:11 AM, Eugeniy Paltsev
wrote:
> From: Alexey Brodkin
>
> This initial port adds support of ARC HS Development Kit board with some
> basic features such serial port, USB, SD/MMC and Ethernet.
>
> Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
> heavily use IO Coherency for speeding-up DMA-aware peripherals.
>
> Note as opposed to other ARC boards we link Linux kernel to
> 0x9000_ intentionally because cores 1 and 3 configured with DCCM
> situated at our more usual link base 0x8000_. We still can use
> memory region starting at 0x8000_ as we reallocate DCCM in our
> platform code.
>
> Note that PAE remapping for DMA clients does not work due to an RTL bug,
> so CREG_PAE register must be programmed to all zeroes, otherwise it will
> cause problems with DMA to/from peripherals even if PAE40 is not used.
>
> Signed-off-by: Alexey Brodkin
> Signed-off-by: Eugeniy Paltsev
> ---
> Documentation/devicetree/bindings/arc/hsdk.txt | 7 ++
> arch/arc/Kconfig | 1 +
> arch/arc/Makefile | 1 +
> arch/arc/boot/dts/hsdk.dts | 150
> +
> arch/arc/configs/hsdk_defconfig| 75 +
> arch/arc/kernel/devtree.c | 5 +-
> arch/arc/plat-hsdk/Kconfig | 12 ++
> arch/arc/plat-hsdk/Makefile| 9 ++
> arch/arc/plat-hsdk/platform.c | 79 +
> 9 files changed, 337 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arc/hsdk.txt
> create mode 100644 arch/arc/boot/dts/hsdk.dts
> create mode 100644 arch/arc/configs/hsdk_defconfig
> create mode 100644 arch/arc/plat-hsdk/Kconfig
> create mode 100644 arch/arc/plat-hsdk/Makefile
> create mode 100644 arch/arc/plat-hsdk/platform.c
>
> diff --git a/Documentation/devicetree/bindings/arc/hsdk.txt
> b/Documentation/devicetree/bindings/arc/hsdk.txt
> new file mode 100644
> index 000..be50654
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arc/hsdk.txt
> @@ -0,0 +1,7 @@
> +Synopsys DesignWare ARC HS Development Kit Device Tree Bindings
> +---
> +
> +ARC HSDK Board with quad-core ARC HS38x4 in silicon.
> +
> +Required root node properties:
> +- compatible = "snps,hsdk";
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 75e5276..825a112 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -101,6 +101,7 @@ source "arch/arc/plat-tb10x/Kconfig"
> source "arch/arc/plat-axs10x/Kconfig"
> #New platform adds here
> source "arch/arc/plat-eznps/Kconfig"
> +source "arch/arc/plat-hsdk/Kconfig"
>
> endmenu
>
> diff --git a/arch/arc/Makefile b/arch/arc/Makefile
> index 44ef35d..55ca925 100644
> --- a/arch/arc/Makefile
> +++ b/arch/arc/Makefile
> @@ -111,6 +111,7 @@ core-$(CONFIG_ARC_PLAT_SIM) += arch/arc/plat-sim/
> core-$(CONFIG_ARC_PLAT_TB10X) += arch/arc/plat-tb10x/
> core-$(CONFIG_ARC_PLAT_AXS10X) += arch/arc/plat-axs10x/
> core-$(CONFIG_ARC_PLAT_EZNPS) += arch/arc/plat-eznps/
> +core-$(CONFIG_ARC_PLAT_HSDK) += arch/arc/plat-hsdk/
>
> ifdef CONFIG_ARC_PLAT_EZNPS
> KBUILD_CPPFLAGS += -I$(srctree)/arch/arc/plat-eznps/include
> diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
> new file mode 100644
> index 000..6a4e471
> --- /dev/null
> +++ b/arch/arc/boot/dts/hsdk.dts
> @@ -0,0 +1,150 @@
> +/*
> + * Copyright (C) 2017 Synopsys, Inc. (www.synopsys.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * Device Tree for ARC HS Development Kit
> + */
> +/dts-v1/;
> +
> +/include/ "skeleton_hs_idu.dtsi"
> +
> +#include
> +
> +/ {
> + model = "snps,hsdk";
> + compatible = "snps,hsdk";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + chosen {
> + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8
> console=ttyS0,115200n8 debug print-fatal-signals=1";
Use stdout-path for the console. Really, the bootargs should be blank
and populated by the bootloader especially debug options.
> + };
> +
> + cpu {
'cpu' is for cpu nodes, so need something different.
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
There are no reg properties, so these aren't needed. This doesn't look
like a simple-bus either.
Probably these child nodes should just be moved up to root level.
> + interrupt-parent = <&core_intc>;
> +
> + core_clk: core_clk {
core-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <10>;
> +
Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board
On Mon, Jun 26, 2017 at 04:25:35PM +, Alexey Brodkin wrote:
> Hi Rob,
>
> On Mon, 2017-06-26 at 10:51 -0500, Rob Herring wrote:
> > On Mon, Jun 26, 2017 at 10:11 AM, Eugeniy Paltsev
> > wrote:
> > >
> > > From: Alexey Brodkin
> > >
>
> [snip]
>
> > > +
> > > + chosen {
> > > + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8
> > > console=ttyS0,115200n8 debug print-fatal-signals=1";
> >
> > Use stdout-path for the console. Really, the bootargs should be blank
> > and populated by the bootloader especially debug options.
>
> Agree but in case of devboards we quite often disable bootloader and
> load Linux image in memory via JTAG. So in that case bootargs make perfect
> sense IMHO.
Okay if you want to leave debug options, but regardless you should use
stdout-path instead.
[...]
> > > + #clock-cells = <0>;
> > > + compatible = "fixed-clock";
> > > + clock-frequency = <10>;
> > > + };
> > > +
> > > + core_intc: archs-intc@cpu {
> >
> > cpu is not a valid unit-address. How are these interrupt controllers
> > addressed?
>
> We have per-core INTC so each core communicates to its own INTC and there's
> no way
> for any core to talk with INTC of another core.
>
> But then we have the next level INTC which is IDU (Interrupt Distribution
> Unit)
> which dispatches "common" IRQs to different upstream per-core INTC, see below
> its node.
Okay, I'd just do "cpu-interrupt-controller" for the node name then.
There doesn't seem to be an easy way to use just "interrupt-controller"
since you have 2 nodes at the same level and no unit-address (i.e. a
reg property).
[...]
> > > + ohci@6 {
> > > + compatible = "generic-ohci";
> >
> > This should have an SoC specific compatible.
>
> But why? We don't have any SoC-specific extensions.
> This essentially applies to EHCI as well.
Because they are all broken in unique ways across different
implementations and SoC integrations. Even IP licensed from the same
vendor has differences.
> > > +++ b/arch/arc/kernel/devtree.c
> > > @@ -29,8 +29,9 @@ static void __init arc_set_early_base_baud(unsigned
> > > long dt_root)
> > > {
> > > if (of_flat_dt_is_compatible(dt_root, "abilis,arc-tb10x"))
> > > arc_base_baud = 1; /* Fixed 166.6MHz clk
> > > (TB10x) */
> > > - else if (of_flat_dt_is_compatible(dt_root, "snps,arc-sdp"))
> > > - arc_base_baud = ; /* Fixed 33MHz clk
> > > (AXS10x) */
> > > + else if (of_flat_dt_is_compatible(dt_root, "snps,arc-sdp") ||
> > > +of_flat_dt_is_compatible(dt_root, "snps,hsdk"))
> > > + arc_base_baud = ; /* Fixed 33MHz clk
> > > (AXS10x & HSDK) */
> >
> > You should get this info from DT. You don't need to address that now though.
>
> For normal UART we indeed don't need that. But this is really required for
> early
> console otherwise how may we start outputting stuff even before we have .dtb
> unflattened.
earlycon gets the register address from the flattened tree. You could
get the clock frequency too using the "clock-frequency" property.
>
> The only thing I may think of early platform code that extracts this value
> from .dtb
> image but:
> 1) I'm not sure it is more elegant
> 2) Still it will be a bit too late - now we start printing very-very early.
You are running C code here and reading the FDT, it's not that early.
For 5 boards, what you have works fine. When you have 10? 100? 1000? Not
so much.
>
> > >
> > > else if (of_flat_dt_is_compatible(dt_root, "ezchip,arc-nps"))
> > > arc_base_baud = 8; /* Fixed 800MHz clk (NPS)
> > > */
> > > else
> > > diff --git a/arch/arc/plat-hsdk/Kconfig b/arch/arc/plat-hsdk/Kconfig
> > > new file mode 100644
> > > index 000..29dffed
> > > --- /dev/null
> > > +++ b/arch/arc/plat-hsdk/Kconfig
> > > @@ -0,0 +1,12 @@
> > > +#
> > > +# Copyright (C) 2017 Synopsys, Inc. (www.synopsys.com)
> > > +#
> > > +# This program is free software; you can redistribute it and/or modify
> > > +# it unde
Re: [PATCH 3/3 v7] ARC: hsdk: initial port for HSDK board
On Mon, Jul 03, 2017 at 07:51:09PM +0300, Eugeniy Paltsev wrote:
> From: Alexey Brodkin
>
> This initial port adds support of ARC HS Development Kit board with some
> basic features such serial port, USB, SD/MMC and Ethernet.
>
> Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
> heavily use IO Coherency for speeding-up DMA-aware peripherals.
>
> Note as opposed to other ARC boards we link Linux kernel to
> 0x9000_ intentionally because cores 1 and 3 configured with DCCM
> situated at our more usual link base 0x8000_. We still can use
> memory region starting at 0x8000_ as we reallocate DCCM in our
> platform code.
>
> Note that PAE remapping for DMA clients does not work due to an RTL bug,
> so CREG_PAE register must be programmed to all zeroes, otherwise it will
> cause problems with DMA to/from peripherals even if PAE40 is not used.
>
> Signed-off-by: Alexey Brodkin
> Signed-off-by: Eugeniy Paltsev
> ---
> Changes v6 -> v7:
> * DTS: get rid of skeleton.dts, move cpus nodes to hsdk.dts
> * DTS: style fixes
> * Enable loadable modules, module unloading and NFS client as defaults
> * Get rid of ARC_PLAT_HSDK board config option
>
> Documentation/devicetree/bindings/arc/hsdk.txt | 7 +
> arch/arc/Makefile | 1 +
> arch/arc/boot/dts/hsdk.dts | 189
> +
> arch/arc/configs/hsdk_defconfig| 78 ++
> arch/arc/kernel/devtree.c | 5 +-
> arch/arc/plat-hsdk/Makefile| 9 ++
> arch/arc/plat-hsdk/platform.c | 79 +++
> 7 files changed, 366 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arc/hsdk.txt
> create mode 100644 arch/arc/boot/dts/hsdk.dts
> create mode 100644 arch/arc/configs/hsdk_defconfig
> create mode 100644 arch/arc/plat-hsdk/Makefile
> create mode 100644 arch/arc/plat-hsdk/platform.c
>
> diff --git a/Documentation/devicetree/bindings/arc/hsdk.txt
> b/Documentation/devicetree/bindings/arc/hsdk.txt
> new file mode 100644
> index 000..be50654
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arc/hsdk.txt
> @@ -0,0 +1,7 @@
> +Synopsys DesignWare ARC HS Development Kit Device Tree Bindings
> +---
> +
> +ARC HSDK Board with quad-core ARC HS38x4 in silicon.
> +
> +Required root node properties:
> +- compatible = "snps,hsdk";
> diff --git a/arch/arc/Makefile b/arch/arc/Makefile
> index 44ef35d..e67397e 100644
> --- a/arch/arc/Makefile
> +++ b/arch/arc/Makefile
> @@ -111,6 +111,7 @@ core-$(CONFIG_ARC_PLAT_SIM) += arch/arc/plat-sim/
> core-$(CONFIG_ARC_PLAT_TB10X)+= arch/arc/plat-tb10x/
> core-$(CONFIG_ARC_PLAT_AXS10X) += arch/arc/plat-axs10x/
> core-$(CONFIG_ARC_PLAT_EZNPS)+= arch/arc/plat-eznps/
> +core-y += arch/arc/plat-hsdk/
>
> ifdef CONFIG_ARC_PLAT_EZNPS
> KBUILD_CPPFLAGS += -I$(srctree)/arch/arc/plat-eznps/include
> diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts
> new file mode 100644
> index 000..33872f1
> --- /dev/null
> +++ b/arch/arc/boot/dts/hsdk.dts
> @@ -0,0 +1,189 @@
> +/*
> + * Copyright (C) 2017 Synopsys, Inc. (www.synopsys.com)
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * Device Tree for ARC HS Development Kit
> + */
> +/dts-v1/;
> +
> +#include
> +
> +/ {
> + model = "snps,hsdk";
> + compatible = "snps,hsdk";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + chosen {
> + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8
> console=ttyS0,115200n8 debug print-fatal-signals=1";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "snps,archs38";
> + reg = <0>;
> + clocks = <&core_clk>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "snps,archs38";
> + reg = <1>;
> + clocks = <&core_clk>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "snps,archs38";
> + reg = <2>;
> + clocks = <&core_clk>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "snps,archs38";
> + reg = <3>;
> + clocks = <&core_clk>;
> + };
> +
Move all the below to root level and out of the cpus node.
> +
Re: [PATCH 3/3 v8] ARC: hsdk: initial port for HSDK board
On Wed, Jul 12, 2017 at 12:40:23PM +0300, Eugeniy Paltsev wrote:
> From: Alexey Brodkin
>
> This initial port adds support of ARC HS Development Kit board with some
> basic features such serial port, USB, SD/MMC and Ethernet.
>
> Essentially we run Linux kernel on all 4 cores (i.e. utilize SMP) and
> heavily use IO Coherency for speeding-up DMA-aware peripherals.
>
> Note as opposed to other ARC boards we link Linux kernel to
> 0x9000_ intentionally because cores 1 and 3 configured with DCCM
> situated at our more usual link base 0x8000_. We still can use
> memory region starting at 0x8000_ as we reallocate DCCM in our
> platform code.
>
> Note that PAE remapping for DMA clients does not work due to an RTL bug,
> so CREG_PAE register must be programmed to all zeroes, otherwise it will
> cause problems with DMA to/from peripherals even if PAE40 is not used.
>
> Signed-off-by: Alexey Brodkin
> Signed-off-by: Eugeniy Paltsev
> ---
> Changes v7 -> v8:
> * DTS: move cpu_intc, idu_intc, arcpct, timer, gfrc nodes to root
>level and out of the cpus node.
> * DTS: add vendor-specific compatible for ohci and ehci nodes.
> * DTS: style fixes
Acked-by: Rob Herring
> + ohci@6 {
> + compatible = "snps,hsdk-v1.0-ohci", "generic-ohci";
> + reg = <0x6 0x100>;
> + interrupts = <15>;
> + };
> +
> + ehci@4 {
> + compatible = "snps,hsdk-v1.0-ehci", "generic-ehci";
> + reg = <0x4 0x100>;
> + interrupts = <15>;
> + };
Of course, now these compatibles need to be documented. You can do that
in a separate follow-up patch.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer
On Mon, Jul 31, 2017 at 08:11:00AM -0700, Alex wrote: > Hi David, > > On 07/28/2017 07:01 PM, David Miller wrote: > > From: Alexandru Gagniuc > > Date: Fri, 28 Jul 2017 15:07:03 -0700 > > > > > Before the GMAC on the Anarion chip can be used, the PHY interface > > > selection must be configured with the DWMAC block in reset. > > > > > > This layer covers a block containing only two registers. Although it > > > is possible to model this as a reset controller and use the "resets" > > > property of stmmac, it's much more intuitive to include this in the > > > glue layer instead. > > > > > > At this time only RGMII is supported, because it is the only mode > > > which has been validated hardware-wise. > > > > > > Signed-off-by: Alexandru Gagniuc > > > > I don't see how this fits into any patch series at all. If this is > > part of a series you posted elsewhere, you should keep netdev@ on > > all such postings so people there can review the change in-context. > > I used the --cc-cmd option to send-email. I'll be sure to CC netdev@ on > [PATCH v2]. The problem is your series spans several subsystems and it's not clear who you intend to apply these. There aren't really any hard dependencies between the patches, so they could all go thru different trees. But you need to state that at least implicitly by sending the patches TO who should apply them and CC the rest (and get_maintainers.pl doesn't really help with that aspect). Or just don't send them in a series if there's not an inter-dependency of the patches. Normally bindings and a driver do go together and I'll ack the binding. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/5] of: Add vendor prefix for Adaptrum, Inc.
On Sat, Jul 29, 2017 at 04:48:28PM +0200, Andreas Färber wrote: > Hi Alexandru, > > Am 29.07.2017 um 00:07 schrieb Alexandru Gagniuc: > > Signed-off-by: Alexandru Gagniuc > > --- > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > > 1 file changed, 1 insertion(+) > > Not sure why I'm CC'ed here, but it looks sane, so > > Reviewed-by: Andreas Färber > > If this patch gets respun, please add a sentence about your company to > the commit message. I also think "dt-bindings:" is a more common prefix? Please respin with the above and just send by itself. This can go separately as there's no need to merge via the same tree just in the name of satisfying checkpatch. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 3/5] net: stmmac: Add Adaptrum Anarion GMAC glue layer
On Fri, Jul 28, 2017 at 03:07:03PM -0700, Alexandru Gagniuc wrote: > Before the GMAC on the Anarion chip can be used, the PHY interface > selection must be configured with the DWMAC block in reset. > > This layer covers a block containing only two registers. Although it > is possible to model this as a reset controller and use the "resets" > property of stmmac, it's much more intuitive to include this in the > glue layer instead. > > At this time only RGMII is supported, because it is the only mode > which has been validated hardware-wise. > > Signed-off-by: Alexandru Gagniuc > --- > .../devicetree/bindings/net/anarion-gmac.txt | 25 The binding looks fine, but please split to separate patch. > drivers/net/ethernet/stmicro/stmmac/Kconfig| 9 ++ > drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + > .../net/ethernet/stmicro/stmmac/dwmac-anarion.c| 151 > + > 4 files changed, 186 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/anarion-gmac.txt > create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-anarion.c ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] earlycon: initialise baud field of earlycon device structure
On Tue, Aug 15, 2017 at 12:21 PM, Eugeniy Paltsev
wrote:
> For now baud field of earlycon structure device is't initialised at all
> in of_setup_earlycon (in oppositе to register_earlycon).
>
> So when I use stdout-path to point earlycon device
> (like stdout-path = &serial or stdout-path = "serial:115200n8")
> baud field of earlycon device structure remains uninitialised and
> earlycon initialization is not performed correctly as
> of_setup_earlycon is used.
Because the console driver is supposed to parse the option string.
That allows in theory for the options to be specific for each console.
Maybe your earlycon driver is failing to do that.
> When pass all arguments via bootargs
> (like bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8")
> initialization is performed correctly as register_earlycon is used.
>
> So initialise baud field of earlycon device structure by baud value
> from device tree or from options (if they exist) when we use
> of_setup_earlycon
>
> Signed-off-by: Eugeniy Paltsev
> ---
> drivers/tty/serial/earlycon.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index c365154..6c2e2b6 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -240,6 +240,7 @@ int __init of_setup_earlycon(const struct earlycon_id
> *match,
> {
> int err;
> struct uart_port *port = &early_console_dev.port;
> + unsigned long baud;
> const __be32 *val;
> bool big_endian;
> u64 addr;
> @@ -282,7 +283,15 @@ int __init of_setup_earlycon(const struct earlycon_id
> *match,
> }
> }
>
> + val = of_get_flat_dt_prop(node, "baud", NULL);
No, we already have a defined way to set the baud, we don't need a
property in addition. Plus you didn't document it.
> + if (val)
> + early_console_dev.baud = be32_to_cpu(*val);
> +
> if (options) {
> + err = kstrtoul(options, 10, &baud);
> + if (!err)
> + early_console_dev.baud = baud;
This seems fine to do here, but then we should also parse the other
standard options here too. And we should make sure we're not doing it
twice.
> +
> strlcpy(early_console_dev.options, options,
> sizeof(early_console_dev.options));
> }
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] earlycon: initialise baud field of earlycon device structure
On Wed, Aug 16, 2017 at 6:52 AM, Eugeniy Paltsev
wrote:
> Hi Rob,
>
> On Tue, 2017-08-15 at 14:26 -0500, Rob Herring wrote:
>> On Tue, Aug 15, 2017 at 12:21 PM, Eugeniy Paltsev
>> wrote:
>> > [snip]
>> > @@ -282,7 +283,15 @@ int __init of_setup_earlycon(const struct
>> > earlycon_id *match,
>> > }
>> > }
>> >
>> > + val = of_get_flat_dt_prop(node, "baud", NULL);
>>
>> No, we already have a defined way to set the baud, we don't need a
>> property in addition. Plus you didn't document it.
>
> I guess by defined way to set the baud you mean setting baud after
> device alias
> in stdout-path property (like stdout-path = "serial:115200n8"), right?
>
> The idea was to reuse "baud" property from serial node to set the
> earlycon baud:
>
> chosen {
> ...
> stdout-path = &serial;
> };
>
> serial: uart@... {
> ...
> baud = <115200>; /* Get baud from here */
"current-speed" is already defined for this purpose. If you want to
add that, that's fine.
> };
>
>> > + if (val)
>> > + early_console_dev.baud = be32_to_cpu(*val);
>> > +
>> > if (options) {
>> > + err = kstrtoul(options, 10, &baud);
>> > + if (!err)
>> > + early_console_dev.baud = baud;
>>
>> This seems fine to do here, but then we should also parse the other
>> standard options here too. And we should make sure we're not doing it
>> twice.
> I added only baud parsing here because we parse only baud from standard
> options
> when register_earlycon is used. (see parse_options function which is
> called
> from register_earlycon)
>
> But I can add other standard options parsing here (probably using
> uart_parse_options + uart_set_options).
> What do you think?
That seems fine as long as consoles can still have their own options.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] OF: move extern declarations of entry pointers inside ifdef
On Fri, Aug 25, 2017 at 10:00 AM, Eugeniy Paltsev
wrote:
> Move extern declarations of "of_root", "of_chosen", "of_aliases",
> "of_stdout" pointers inside "CONFIG_OF" ifdef to be able to get rid
> of "CONFIG_OF" ifdef in their usage places.
>
> Suggested-by: Steven Rostedt
>
> Signed-off-by: Eugeniy Paltsev
> ---
> For example see: https://lkml.org/lkml/2017/8/25/337
>
> include/linux/of.h | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/of.h b/include/linux/of.h
> index cfc3411..d117bf1 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -131,11 +131,6 @@ static inline struct device_node *of_node_get(struct
> device_node *node)
> static inline void of_node_put(struct device_node *node) { }
> #endif /* !CONFIG_OF_DYNAMIC */
>
> -/* Pointer for first entry in chain of all nodes. */
> -extern struct device_node *of_root;
> -extern struct device_node *of_chosen;
> -extern struct device_node *of_aliases;
> -extern struct device_node *of_stdout;
Just move what you need. Some of these I'd like to see be internal to
the DT code.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] OF: move extern declarations of of_stdout inside ifdef
On Fri, Aug 25, 2017 at 11:56 AM, Eugeniy Paltsev wrote: > Move extern declarations of "of_stdout" pointer inside "CONFIG_OF" > ifdef to be able to get rid of "CONFIG_OF" ifdef in its usage places. > > Suggested-by: Steven Rostedt > > Signed-off-by: Eugeniy Paltsev > --- > For example see: https://lkml.org/lkml/2017/8/25/337 > > Changes v1->v2: > * Move only "of_stdout" declarations instead of all entry pointers >declarations > > include/linux/of.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Acked-by: Rob Herring Merge this with the console change needing it. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Setting CPU clock frequency on early boot
On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin wrote: > Hello, > > I'd like to get some feedback on our idea as well as check > if somebody faces similar situations and if so what would be the best > way to implement some generic solution that suits everyone. > > So that's our problem: > 1. On power-on hardware might start clocking CPU with either >too high frequency (such that CPU may get stuck at some point) >or too low frequency. > >That all sounds stupid but let me elaborate a bit here. >I'm talking about FPGA-based devboards firmware for which >(here I mean just image loaded in FPGA with CPU implementation >but not some software yet) might not be stable or be even experimental. > >For example we may deal with dual-core or quad-core designs. >Former might be OK running @100MHz and latter is only usable >@75MHz and lower. The simplest solution might be to use some safe >value before something like CPUfreq kicks in. But we don't yet have >CPUfreq for ARC (we do plan to get it working sometime soon) which >means simple change of CPU frequency once time-keeping infrastructure >was brought-up is not an option... I.e. we'll end up with the system > running >much slower compared what could have been possible. > > 2. Up until now we used to do dirty hacks in early platform init code. >Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c): > 1) Read CPU's "clock-frequency" from .dtb (remember we're on very early >boot stage still so no expanded DevTree yet exists). > 2) Check how many cores we have and which freq is usable > 3) Update PLL settings right in place if new freq != existing in PLL. > >Even though it is proven to work but with more platforms in the pipeline >we'll need to copy-paste pretty much the same stuff across all affected >plats. Which is not nice. > >Moreover back in the day we didn't have a proper clk driver for CPU's PLL. >Thus acting on PLL registers right in place was the only thing we were able >to do. Now with introduction of normal clk driver >(see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to utilize >it and have a cleaner and more universal solution to the problem. > >That's how it could be done - http://patchwork.ozlabs.org/patch/801240/ >Basically in architecture's time_init() we check if there's explicitly >specified "clock-frequency" parameter in cpu's node in Device Tree and >if there's one we set it via just instantiated clk driver. The patch looks generally okay. I'd move all the logic to the clock driver unless perhaps how to set the cpu freq is defined by the architecture. > We may indeed proceed with mentioned solution for ARC but if that makes > sense for somebody else it might worth getting something similar in generic > init code. Any thoughts? If any ARM platforms are doing something similar, then it's done in their clock driver via of_clk_init. Or they just wait for cpufreq to kick in and expect the bootloader has initialized things to a reasonable frequency. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Setting CPU clock frequency on early boot
On Wed, Sep 6, 2017 at 8:51 AM, Alexey Brodkin wrote: > Hi Vineet, Rob, > > On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote: >> On 09/05/2017 03:04 PM, Rob Herring wrote: >> > >> > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin >> > wrote: >> > > >> > > Hello, >> > > >> > > I'd like to get some feedback on our idea as well as check >> > > if somebody faces similar situations and if so what would be the best >> > > way to implement some generic solution that suits everyone. >> > > >> > > So that's our problem: >> > > 1. On power-on hardware might start clocking CPU with either >> > > too high frequency (such that CPU may get stuck at some point) >> > > or too low frequency. >> > > >> > > That all sounds stupid but let me elaborate a bit here. >> > > I'm talking about FPGA-based devboards firmware for which >> > > (here I mean just image loaded in FPGA with CPU implementation >> > > but not some software yet) might not be stable or be even >> > > experimental. >> > > >> > > For example we may deal with dual-core or quad-core designs. >> > > Former might be OK running @100MHz and latter is only usable >> > > @75MHz and lower. The simplest solution might be to use some safe >> > > value before something like CPUfreq kicks in. But we don't yet have >> > > CPUfreq for ARC (we do plan to get it working sometime soon) >> >> But even if we had cpufreq driver going - I don't think it would be usable >> for >> doing large freq switches, since in current implementations of SoCs (or >> fpga), the >> clk/pll etc driving core (and all timers etc) are not fixed like say ARM. >> And as >> discussed before (and pointed to by tglx), timer subsys can't tolerate (on >> purpose) such large drifts. > > Essentially cpufreq only makes sense for "compatible" systems and > unfortunately > most of our current boards are not capable due to missing constant [decoupled > from > CPU frequency] clock source. But looking forward we are planning to improve > on that > so that hopefully even our FPGA-based boards will be usable with cpufreq. > >> > > which >> > > means simple change of CPU frequency once time-keeping infrastructure >> > > was brought-up is not an option... I.e. we'll end up with the system >> > > running >> > > much slower compared what could have been possible. >> > > >> > > 2. Up until now we used to do dirty hacks in early platform init code. >> > > Namely (see axs103_early_init() in arch/arc/plat-axs10x/axs10x.c): >> > > 1) Read CPU's "clock-frequency" from .dtb (remember we're on very >> > > early >> > > boot stage still so no expanded DevTree yet exists). >> > > 2) Check how many cores we have and which freq is usable >> > > 3) Update PLL settings right in place if new freq != existing in >> > > PLL. >> > > >> > > Even though it is proven to work but with more platforms in the >> > > pipeline >> > > we'll need to copy-paste pretty much the same stuff across all >> > > affected >> > > plats. Which is not nice. >> > > >> > > Moreover back in the day we didn't have a proper clk driver for >> > > CPU's PLL. >> > > Thus acting on PLL registers right in place was the only thing we >> > > were able >> > > to do. Now with introduction of normal clk driver >> > > (see drivers/clk/axs10x/pll_clock.c in linux-next) we'd like to >> > > utilize >> > > it and have a cleaner and more universal solution to the problem. >> > > >> > > That's how it could be done - >> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_patch_801240_&d=DwICAg&c=DPL6_X_6JkXF >> > > x7AXWqB0tg&r=c14YS-cH- >> > > kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=wuUcceY8Cz5EhVklWLAgj7RzU3rvpanujvQ3qTJK0Gw&s=N5IBjq_eCyOf_GRkZskzqGhczBPTbxLJW_MUfauKvuA&e= >> > > Basically in architecture's time_init() we check if there's >> > > explicitly >> > > specified "clock-frequency" parameter in cpu's node in Device Tree >> > > an
Re: Setting CPU clock frequency on early boot
On Wed, Sep 6, 2017 at 11:22 AM, Alexey Brodkin
wrote:
> Hi Rob,
>
> On Wed, 2017-09-06 at 10:25 -0500, Rob Herring wrote:
>> On Wed, Sep 6, 2017 at 8:51 AM, Alexey Brodkin
>> wrote:
>> >
>> > Hi Vineet, Rob,
>> >
>> > On Tue, 2017-09-05 at 16:40 -0700, Vineet Gupta wrote:
>> > >
>> > > On 09/05/2017 03:04 PM, Rob Herring wrote:
>> > > >
>> > > >
>> > > > On Tue, Sep 5, 2017 at 10:37 AM, Alexey Brodkin
>> > > > wrote:
>
> [snip]
>
>> > Yeah, that's an interesting question. We may indeed move more smarts to
>> > the clock driver
>> > but:
>> > 1. We'll have duplicate code in different clock drivers. Even today that
>> > kind of clock
>> > setup is applicable to AXS10x and HSDK platforms (and they use
>> > different clock drivers).
>>
>> No, you could provide a common, shared function to call. Then each
>> platform can opt-in. If you can make something that applies to every
>> single platform now or in the future, then I'd put it in arch. If you
>> have plans to decouple the timer and cpu clocks, then sounds like you
>> can't.
>
> Right so we'll implement a function which is called by a platform if required.
> That way we escape copy-pasting while keeping enough flexibility for current
> and future platforms.
>
>> IMO, if it's not part of the defined CPU architecture, then don't put
>> it in arch/. That's how we end up with multiple copies of the same
>> thing done arbitrarily different ways because few people look across
>> architectures.
>
> So do you propose to have the function [that reads "clock-frequency" from say
> CPU node and passes its value to CPU's parent clock driver] in generic
> [i.e. architecture agnostic] code somewhere in "init/main.c"?
No, just like you said above and have the platform's clock driver
initialize frequencies.
I haven't seen anyone else want such a thing as generally the
bootloader should initialize things to something reasonable.
>> > 2. Print out of CPU frequency which is used during boot process for us is
>> > important as well
>> > especially during bring-up of new HW.
>> >
>> > 3. If there's no dedicated "clock-frequency" parameter in CPU node we
>> > won't
>> > change anything so that non-affected platforms will live as they used
>> > to.
>> >
>> > That said IMHO proposed implementation is what we want to kep for now.
>> >
>> > >
>> > > Also note that this code is using a new / adhoc DT binding cpu-freq in
>> > > cou node to
>> > > do the override - is that acceptable ?
>>
>> No, I meant to point that out.
>
> Sorry, but for me it's not clear what did you mean here.
> Care to elaborate a bit more?
I noticed the same thing and meant to highlight that in my first
reply. Use clock-frequency, don't invent something new.
>> > I think we'll switch to more common "clock-frequency" in the next respin.
>> > Indeed "cpu-freq" might be a bit misleading.
>>
>> Ideally, you'd use the clock binding eventually.
>
> Again I'm probably missing something :)
"clock-frequency" property and the clock bindings (i.e. clocks =
<&phandle>) are generally mutually exclusive at least within clock
consumer side. There's the assigned-clocks binding which provides the
ability to set both parent clocks and frequency.
> I meant we will have both clock phandle and "clock-frequency" at the same
> time.
> Something like this:
> >8---
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> cpu@0 {
> device_type = "cpu";
> compatible = "snps,archs38";
> reg = <0>;
> clocks = <&core_clk>;
> clock-frequency = <1>; <-- That's where we
> want to set desired value
> };
> ...
> }
>
> core_clk: core-clk@80 {
> compatible = "snps,axs10x-arc-pll-clock";
> reg = <0x80 0x10>, <0x100 0x10>;
> #clock-cells = <0>;
> clocks = <&input_clk>;
> };
> >8---
>
> Or alternatively we may move "clock-frequency" right to the clock's node and
> have
> it like that:
> >8---
> core_clk: core-clk@80 {
> compatible = "snps,axs10x-arc-pll-clock";
> reg = <0x80 0x10>, <0x100 0x10>;
>
> #clock-cells = <0>;
> clocks = <&input_clk>;
> clock-frequency = <1>; <-- That's where we want to
> set desired value
I think this is how it should be done if you use clock-frequency prop.
This is inline with how fixed-clock binding is done.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arc: dts: Remove leading 0x and 0s from bindings notation
On Thu, Dec 14, 2017 at 10:53 AM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading
> "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e
> "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1
> \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings
> separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x
> from bindings notation")
>
> Reported-by: David Daney
> Suggested-by: Rob Herring
> Signed-off-by: Mathieu Malaterre
> ---
For the series,
Reviewed-by: Rob Herring
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys DW AXI DMA bindings
On Mon, Mar 05, 2018 at 11:02:56AM +0530, Vinod Koul wrote:
> On Fri, Mar 02, 2018 at 08:32:20AM +, Alexey Brodkin wrote:
> > Hi Vinod,
> >
> > On Fri, 2018-03-02 at 13:44 +0530, Vinod Koul wrote:
> > > On Mon, Feb 26, 2018 at 05:56:28PM +0300, Eugeniy Paltsev wrote:
> > > > This patch adds documentation of device tree bindings for the Synopsys
> > > > DesignWare AXI DMA controller.
> > > >
> > > > Signed-off-by: Eugeniy Paltsev
> > > > ---
> > > > .../devicetree/bindings/dma/snps,dw-axi-dmac.txt | 41
> > > > ++
> > > > 1 file changed, 41 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > > b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > > new file mode 100644
> > > > index 000..f237b79
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
> > > > @@ -0,0 +1,41 @@
> > > > +Synopsys DesignWare AXI DMA Controller
> > > > +
> > > > +Required properties:
> > > > +- compatible: "snps,axi-dma-1.01a"
> > > > +- reg: Address range of the DMAC registers. This should include
> > > > + all of the per-channel registers.
> > > > +- interrupt: Should contain the DMAC interrupt number.
> > > > +- interrupt-parent: Should be the phandle for the interrupt controller
> > > > + that services interrupts for this device.
> > > > +- dma-channels: Number of channels supported by hardware.
> > > > +- snps,dma-masters: Number of AXI masters supported by the hardware.
> > > > +- snps,data-width: Maximum AXI data width supported by hardware.
> > > > + (0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)
> > > > +- snps,priority: Priority of channel. Array size is equal to the
> > > > number of
> > > > + dma-channels. Priority value must be programmed within
> > > > [0:dma-channels-1]
> > > > + range. (0 - minimum priority)
> > > > +- snps,block-size: Maximum block size supported by the controller
> > > > channel.
> > > > + Array size is equal to the number of dma-channels.
> > > > +
> > > > +Optional properties:
> > > > +- snps,axi-max-burst-len: Restrict master AXI burst length by value
> > > > specified
> > > > + in this property. If this property is missing the maximum AXI burst
> > > > length
> > > > + supported by DMAC is used. [1:256]
> > > > +
> > > > +Example:
> > > > +
> > > > +dmac: dma-controller@8 {
> > > > + compatible = "snps,axi-dma-1.01a";
> > >
> > > do we need "snps here..?
> >
> > Synopsys is this IP-block vendor so shouldn't we put it that way?
>
> Not a DT expert but why should vendor name come here, you can read the
> properties from device node, vendor name seems redundant to me
I don't follow...
In any case, yes, it must have a vendor prefix. It should also have a
compatible for the vendor(s) that integrate the block because they all
break it in different ways. Speaking of which, we already have
snps-dma.txt and at least Analog Devices binding using a Synopsys DMA.
What's the difference?
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys DW AXI DMA bindings
On Tue, Mar 06, 2018 at 02:46:15PM +0300, Eugeniy Paltsev wrote: > This patch adds documentation of device tree bindings for the Synopsys > DesignWare AXI DMA controller. > > Signed-off-by: Eugeniy Paltsev > --- > Changes v2->v3: > * None. > > .../devicetree/bindings/dma/snps,dw-axi-dmac.txt | 41 > ++ > 1 file changed, 41 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 0/8] Devicetree build consolidation
This series addresses a couple of issues I have with building dts files. First, the ability to build all the dts files in the tree. This has been supported on most arches for some time with powerpc being the main exception. The reason powerpc wasn't supported was it needed a change in the location built dtb files are put. Secondly, it's a pain to acquire all the cross-compilers needed to build dtbs for each arch. There's no reason to build with the cross compiler and the host compiler is perfectly fine as we only need the pre-processor. I started addressing just those 2 problems, but kept finding small differences such as target dependencies and dtbs_install support across architectures. Instead of trying to align all these, I've consolidated the build targets moving them out of the arch makefiles. I'd like to take the series via the DT tree. Rob Rob Herring (8): powerpc: build .dtb files in dts directory nios2: build .dtb files in dts directory nios2: use common rules to build built-in dtb nios2: fix building all dtbs c6x: use common built-in dtb support kbuild: consolidate Devicetree dtb build rules powerpc: enable building all dtbs c6x: enable building all dtbs Makefile | 30 ++ arch/arc/Makefile | 6 arch/arm/Makefile | 20 +--- arch/arm64/Makefile| 17 +-- arch/c6x/Makefile | 2 -- arch/c6x/boot/dts/Makefile | 17 +-- arch/c6x/boot/dts/linked_dtb.S | 2 -- arch/c6x/include/asm/sections.h| 1 - arch/c6x/kernel/setup.c| 4 +-- arch/c6x/kernel/vmlinux.lds.S | 10 -- arch/h8300/Makefile| 11 +-- arch/microblaze/Makefile | 4 +-- arch/mips/Makefile | 15 + arch/nds32/Makefile| 2 +- arch/nios2/Makefile| 11 +-- arch/nios2/boot/Makefile | 22 -- arch/nios2/boot/dts/Makefile | 6 arch/nios2/boot/linked_dtb.S | 19 arch/powerpc/Makefile | 3 -- arch/powerpc/boot/Makefile | 49 ++ arch/powerpc/boot/dts/Makefile | 6 arch/powerpc/boot/dts/fsl/Makefile | 4 +++ arch/xtensa/Makefile | 12 +--- scripts/Makefile | 1 - scripts/Makefile.lib | 2 +- 25 files changed, 87 insertions(+), 189 deletions(-) delete mode 100644 arch/c6x/boot/dts/linked_dtb.S create mode 100644 arch/nios2/boot/dts/Makefile delete mode 100644 arch/nios2/boot/linked_dtb.S create mode 100644 arch/powerpc/boot/dts/Makefile create mode 100644 arch/powerpc/boot/dts/fsl/Makefile -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 6/8] kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Cc: Masahiro Yamada Cc: Michal Marek Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Yoshinori Sato Cc: Michal Simek Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: Ley Foon Tan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Chris Zankel Cc: Max Filippov Cc: linux-kbu...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-m...@linux-mips.org Cc: nios2-...@lists.rocketboards.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-xte...@linux-xtensa.org Signed-off-by: Rob Herring --- Makefile | 30 ++ arch/arc/Makefile| 6 -- arch/arm/Makefile| 20 +--- arch/arm64/Makefile | 17 + arch/c6x/Makefile| 2 -- arch/h8300/Makefile | 11 +-- arch/microblaze/Makefile | 4 +--- arch/mips/Makefile | 15 +-- arch/nds32/Makefile | 2 +- arch/nios2/Makefile | 7 --- arch/nios2/boot/Makefile | 4 arch/powerpc/Makefile| 3 --- arch/xtensa/Makefile | 12 +--- scripts/Makefile | 1 - scripts/Makefile.lib | 2 +- 15 files changed, 38 insertions(+), 98 deletions(-) diff --git a/Makefile b/Makefile index c13f8b85ba60..6d89e673f192 100644 --- a/Makefile +++ b/Makefile @@ -1212,6 +1212,30 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +dtstree := $(wildcard arch/$(SRCARCH)/boot/dts) + +ifdef CONFIG_OF_EARLY_FLATTREE + +%.dtb %.dtb.S %.dtb.o: | dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs +dtbs: | dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: dtbs + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +all: dtbs + +dtc: + $(Q)$(MAKE) $(build)=scripts/dtc + +endif + # --- # Modules @@ -1425,6 +1449,12 @@ help: @echo ' kselftest-merge - Merge all the config dependencies of kselftest to existing' @echo '.config.' @echo '' + @$(if $(dtstree), \ + echo 'Devicetree:'; \ + echo '* dtbs- Build device tree blobs for enabled boards'; \ + echo ' dtbs_install- Install dtbs to $(INSTALL_DTBS_PATH)'; \ + echo '') + @echo 'Userspace tools targets:' @echo ' use "make tools/help"' @echo ' or "cd tools; make help"' diff --git a/arch/arc/Makefile b/arch/arc/Makefile index 6c1b20dd76ad..cbfb7a16b570 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz $(boot_targets): vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ -%.dtb %.dtb.S %.dtb.o: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@ - -dtbs: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts - archclean: $(Q)$(MAKE) $(clean)=$(boot) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index e7d703d8fac3..7f02ef8dfdb2 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -308,12 +308,7 @@ else KBUILD_IMAGE := $(boot)/zImage endif -# Build the DT binary blobs if we have OF configured -ifeq ($(CONFIG_USE_OF),y) -KBUILD_DTBS := dtbs -endif - -all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTBS) +all: $(notdir $(KBUILD_IMAGE)) archheaders: @@ -340,17 +335,6 @@ $(BOOT_TARGETS): vmlinux $(INSTALL_TARGETS): $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@ -%.dtb: | scripts - $(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@ - -PHONY += dtbs dtbs_install - -dtbs: prepare scripts - $(Q)$(MAKE) $(build)=$(boot)/dts - -dtbs_install: -
Re: [PATCH 6/8] kbuild: consolidate Devicetree dtb build rules
On Sat, Aug 25, 2018 at 9:06 PM Masahiro Yamada wrote: > > Hi Rob, > > > 2018-08-22 6:55 GMT+09:00 Rob Herring : > > There is nothing arch specific about building dtb files other than their > > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > > The dependencies and supported targets are all slightly different. > > Also, a cross-compiler for each arch is needed, but really the host > > compiler preprocessor is perfectly fine for building dtbs. Move the > > build rules to a common location and remove the arch specific ones. This > > is done in a single step to avoid warnings about overriding rules. > > > > The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > > These pull in several dependencies some of which need a target compiler > > (specifically devicetable-offsets.h) and aren't needed to build dtbs. > > All that is really needed is dtc, so adjust the dependencies to only be > > dtc. > > > > This change enables support 'dtbs_install' on some arches which were > > missing the target. > > > > Cc: Masahiro Yamada > > Cc: Michal Marek > > Cc: Vineet Gupta > > Cc: Russell King > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Yoshinori Sato > > Cc: Michal Simek > > Cc: Ralf Baechle > > Cc: Paul Burton > > Cc: James Hogan > > Cc: Ley Foon Tan > > Cc: Benjamin Herrenschmidt > > Cc: Paul Mackerras > > Cc: Michael Ellerman > > Cc: Chris Zankel > > Cc: Max Filippov > > Cc: linux-kbu...@vger.kernel.org > > Cc: linux-snps-arc@lists.infradead.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: uclinux-h8-de...@lists.sourceforge.jp > > Cc: linux-m...@linux-mips.org > > Cc: nios2-...@lists.rocketboards.org > > Cc: linuxppc-...@lists.ozlabs.org > > Cc: linux-xte...@linux-xtensa.org > > Signed-off-by: Rob Herring > > --- > > Makefile | 30 ++ > > arch/arc/Makefile| 6 -- > > arch/arm/Makefile| 20 +--- > > arch/arm64/Makefile | 17 + > > arch/c6x/Makefile| 2 -- > > arch/h8300/Makefile | 11 +-- > > arch/microblaze/Makefile | 4 +--- > > arch/mips/Makefile | 15 +-- > > arch/nds32/Makefile | 2 +- > > arch/nios2/Makefile | 7 --- > > arch/nios2/boot/Makefile | 4 > > arch/powerpc/Makefile| 3 --- > > arch/xtensa/Makefile | 12 +--- > > scripts/Makefile | 1 - > > scripts/Makefile.lib | 2 +- > > 15 files changed, 38 insertions(+), 98 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index c13f8b85ba60..6d89e673f192 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1212,6 +1212,30 @@ kselftest-merge: > > $(srctree)/tools/testing/selftests/*/config > > +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig > > > > +# > > --- > > +# Devicetree files > > + > > +dtstree := $(wildcard arch/$(SRCARCH)/boot/dts) BTW, there's an error here too. It doesn't work right with KBUILD_OUTPUT set and should be: ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) dtstree := arch/$(SRCARCH)/boot/dts endif > > + > > +ifdef CONFIG_OF_EARLY_FLATTREE > > + > > +%.dtb %.dtb.S %.dtb.o: | dtc > > I think the pipe operator is unnecessary > because Kbuild will descend to $(dtstree) anyway. The pipe means 'order-only', right? So it is just a weaker dependency for things which are not input files as dtc is not. The 'dtc' here is just the dtc rule below, not the actual executable. Or am I missing something? > > + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > > + > > +PHONY += dtbs > > +dtbs: | dtc > > Ditto. > > > > + $(Q)$(MAKE) $(build)=$(dtstree) > > + > > +dtbs_install: dtbs > > + $(Q)$(MAKE) $(dtbinst)=$(dtstree) > > + > > +all: dtbs > > + > > +dtc: > > + $(Q)$(MAKE) $(build)=scripts/dtc > > + > > +endif > > + > > > arch/*/boot/dts/ are not only directories that > require dtc. Ah yes, of course... > > diff --git a/scripts/Makefile b/scripts/Makefile > > index 61affa300d25..a716a6b10954 100644 > > --- a/scripts/Makefile > > +++ b/scripts/Makefile > > @@ -39,7 +39,6 @@ build_unifdef: $(obj)/unifdef > > subdir-$(CONFIG_MODVERSIONS) += genksyms > > subdir-y += mod > > subdir-$(CONFIG_SECURITY_SELINUX) += selinux > > -subdir-$(CONFIG_DTC) += dtc > > subdir-$(CONFIG_GDB_SCRIPTS) += gdb > > > > # Let clean descend into subdirs Looks like I need to leave this line to fix the above and cleaning. Thanks for the review. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys GPIO via CREG bindings
On Tue, Aug 28, 2018 at 02:27:21PM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> GPIO via CREG driver.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> .../devicetree/bindings/gpio/snps,creg-gpio.txt| 49
> ++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> b/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> new file mode 100644
> index ..eb022d44ccda
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt
> @@ -0,0 +1,49 @@
> +GPIO via CREG (Control REGisers) driver
REGisters?
Bindings don't describe drivers.
> +
> +This is is single-register MMIO GPIO driver to control such strangely mapped
> +outputs:
> +
> +31118 75 0 < bit number
> +| || || |
> +[ not used | gpio-1 | shift-1 | gpio-0 | shift-0 ] < 32 bit MMIO
> register
> + ^ ^
> + | |
> + | write 0x2 == set output to "1" (on)
> + | write 0x3 == set output to "0" (off)
> + |
> +write 0x1 == set output to "1" (on)
> +write 0x4 == set output to "0" (off)
What kind of crazy h/w designer designed this?
> +Required properties:
> +- compatible : "snps,creg-gpio"
> +- reg : Exactly one register range with length 0x4.
> +- #gpio-cells : Should be one - the pin number.
> +- gpio-controller : Marks the device node as a GPIO controller.
> +- snps,ngpios: Number of GPIO pins.
> +- snps,bit-per-line: Number of bits per each gpio line (see picture).
> + Array the size of "snps,ngpios"
> +- snps,shift: Shift (in bits) of the each GPIO field from the previous one in
> + register (see picture). Array the size of "snps,ngpios"
> +- snps,on-val: Value should be set in corresponding field to set
> + output to "1" (see picture). Array the size of "snps,ngpios"
> +- snps,off-val: Value should be set in corresponding field to set
> + output to "0" (see picture). Array the size of "snps,ngpios"
Convince me we need to parameterize all this. We try to avoid describing
h/w like this.
> +
> +Optional properties:
> +- snps,default-val: default output field values. Array the size of
> "snps,ngpios"
> +
> +Example (see picture):
> +
> +gpio: gpio@f00014b0 {
> + compatible = "snps,creg-gpio";
> + reg = <0xf00014b0 0x4>;
> + gpio-controller;
> + #gpio-cells = <1>;
> + snps,ngpios = <2>;
> + snps,shift = <5 1>;
> + snps,bit-per-line = <2 3>;
> + snps,on-val = <2 1>;
> + snps,off-val = <3 4>;
> + snps,default-val = <2 1>;
> +};
> --
> 2.14.4
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 0/9] Devicetree build consolidation
This series addresses a couple of issues I have with building dts files. First, the ability to build all the dts files in the tree. This has been supported on most arches for some time with powerpc being the main exception. The reason powerpc wasn't supported was it needed a change in the location built dtb files are put. Secondly, it's a pain to acquire all the cross-compilers needed to build dtbs for each arch. There's no reason to build with the cross compiler and the host compiler is perfectly fine as we only need the pre-processor. I started addressing just those 2 problems, but kept finding small differences such as target dependencies and dtbs_install support across architectures. Instead of trying to align all these, I've consolidated the build targets moving them out of the arch makefiles. I'd like to take the series via the DT tree. Rob v2: - Fix $arch/boot/dts path check for out of tree builds - Fix dtc dependency for building built-in dtbs - Fix microblaze built-in dtb building - Add dtbs target for microblaze Rob Herring (9): powerpc: build .dtb files in dts directory nios2: build .dtb files in dts directory nios2: use common rules to build built-in dtb nios2: fix building all dtbs c6x: use common built-in dtb support kbuild: consolidate Devicetree dtb build rules powerpc: enable building all dtbs c6x: enable building all dtbs microblaze: enable building all dtbs Makefile | 32 +++ arch/arc/Makefile | 6 arch/arm/Makefile | 20 +--- arch/arm64/Makefile| 17 +-- arch/c6x/Makefile | 2 -- arch/c6x/boot/dts/Makefile | 17 +-- arch/c6x/boot/dts/linked_dtb.S | 2 -- arch/c6x/include/asm/sections.h| 1 - arch/c6x/kernel/setup.c| 4 +-- arch/c6x/kernel/vmlinux.lds.S | 10 -- arch/h8300/Makefile| 11 +-- arch/microblaze/Makefile | 4 +-- arch/microblaze/boot/dts/Makefile | 4 +++ arch/mips/Makefile | 15 + arch/nds32/Makefile| 2 +- arch/nios2/Makefile| 11 +-- arch/nios2/boot/Makefile | 22 -- arch/nios2/boot/dts/Makefile | 6 arch/nios2/boot/linked_dtb.S | 19 arch/powerpc/Makefile | 3 -- arch/powerpc/boot/Makefile | 49 ++ arch/powerpc/boot/dts/Makefile | 6 arch/powerpc/boot/dts/fsl/Makefile | 4 +++ arch/xtensa/Makefile | 12 +--- scripts/Makefile.lib | 2 +- 25 files changed, 93 insertions(+), 188 deletions(-) delete mode 100644 arch/c6x/boot/dts/linked_dtb.S create mode 100644 arch/nios2/boot/dts/Makefile delete mode 100644 arch/nios2/boot/linked_dtb.S create mode 100644 arch/powerpc/boot/dts/Makefile create mode 100644 arch/powerpc/boot/dts/fsl/Makefile -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Cc: Masahiro Yamada Cc: Michal Marek Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Yoshinori Sato Cc: Michal Simek Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: Ley Foon Tan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Chris Zankel Cc: Max Filippov Cc: linux-kbu...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-m...@linux-mips.org Cc: nios2-...@lists.rocketboards.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-xte...@linux-xtensa.org Signed-off-by: Rob Herring --- Please ack so I can take the whole series via the DT tree. v2: - Fix $arch/boot/dts path check for out of tree builds - Fix dtc dependency for building built-in dtbs - Fix microblaze built-in dtb building Makefile | 32 +++ arch/arc/Makefile | 6 -- arch/arm/Makefile | 20 +-- arch/arm64/Makefile | 17 +--- arch/c6x/Makefile | 2 -- arch/h8300/Makefile | 11 +-- arch/microblaze/Makefile | 4 +--- arch/microblaze/boot/dts/Makefile | 2 ++ arch/mips/Makefile| 15 +-- arch/nds32/Makefile | 2 +- arch/nios2/Makefile | 7 --- arch/nios2/boot/Makefile | 4 arch/powerpc/Makefile | 3 --- arch/xtensa/Makefile | 12 +--- scripts/Makefile.lib | 2 +- 15 files changed, 42 insertions(+), 97 deletions(-) diff --git a/Makefile b/Makefile index 2b458801ba74..bc18dbbc16c5 100644 --- a/Makefile +++ b/Makefile @@ -1212,6 +1212,32 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) +dtstree := arch/$(SRCARCH)/boot/dts +endif + +ifdef CONFIG_OF_EARLY_FLATTREE + +%.dtb %.dtb.S %.dtb.o: | dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs +dtbs: | dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: dtbs + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +all: dtbs + +dtc: + $(Q)$(MAKE) $(build)=scripts/dtc + +endif + # --- # Modules @@ -1421,6 +1447,12 @@ help: @echo ' kselftest-merge - Merge all the config dependencies of kselftest to existing' @echo '.config.' @echo '' + @$(if $(dtstree), \ + echo 'Devicetree:'; \ + echo '* dtbs- Build device tree blobs for enabled boards'; \ + echo ' dtbs_install- Install dtbs to $(INSTALL_DTBS_PATH)'; \ + echo '') + @echo 'Userspace tools targets:' @echo ' use "make tools/help"' @echo ' or "cd tools; make help"' diff --git a/arch/arc/Makefile b/arch/arc/Makefile index fb026196aaab..5c7bc6d62f43 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz $(boot_targets): vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ -%.dtb %.dtb.S %.dtb.o: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@ - -dtbs: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts - archclean: $(Q)$(MAKE) $(clean)=$(boot) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index d1516f85f25d..161c2df6567e 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -307,12 +307,7 @@ else KBUILD_IMAGE := $(boot)/zImage endif -# Build the DT binary blobs if we have OF configured -ifeq ($(CONFIG_USE_OF),y) -KBUILD_DTBS := dtbs -endif - -all: $(notdir $(KBUILD_IMAGE)) $(KBUILD_DTB
Re: [PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules
On Fri, Sep 7, 2018 at 5:33 AM Masahiro Yamada wrote: > > 2018-09-06 8:53 GMT+09:00 Rob Herring : > > There is nothing arch specific about building dtb files other than their > > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > > The dependencies and supported targets are all slightly different. > > Also, a cross-compiler for each arch is needed, but really the host > > compiler preprocessor is perfectly fine for building dtbs. Move the > > build rules to a common location and remove the arch specific ones. This > > is done in a single step to avoid warnings about overriding rules. > > > > The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > > These pull in several dependencies some of which need a target compiler > > (specifically devicetable-offsets.h) and aren't needed to build dtbs. > > All that is really needed is dtc, so adjust the dependencies to only be > > dtc. > > > > This change enables support 'dtbs_install' on some arches which were > > missing the target. > > > > Cc: Masahiro Yamada > > Cc: Michal Marek > > Cc: Vineet Gupta > > Cc: Russell King > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Yoshinori Sato > > Cc: Michal Simek > > Cc: Ralf Baechle > > Cc: Paul Burton > > Cc: James Hogan > > Cc: Ley Foon Tan > > Cc: Benjamin Herrenschmidt > > Cc: Paul Mackerras > > Cc: Michael Ellerman > > Cc: Chris Zankel > > Cc: Max Filippov > > Cc: linux-kbu...@vger.kernel.org > > Cc: linux-snps-arc@lists.infradead.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: uclinux-h8-de...@lists.sourceforge.jp > > Cc: linux-m...@linux-mips.org > > Cc: nios2-...@lists.rocketboards.org > > Cc: linuxppc-...@lists.ozlabs.org > > Cc: linux-xte...@linux-xtensa.org > > Signed-off-by: Rob Herring > > --- > > Please ack so I can take the whole series via the DT tree. > > > > v2: > > - Fix $arch/boot/dts path check for out of tree builds > > - Fix dtc dependency for building built-in dtbs > > - Fix microblaze built-in dtb building > > > This breaks parallel building > because two threads could descend into scripts/dtc > at the same time. > > 'all' depends on both 'scripts' and 'dtc'. > > * 'scripts' target -- descends into scripts/, then scripts/dtc > * 'dtc' target -- descents into scripts/dtc directly Any suggestions for how to fix given the problem with depending on scripts? I suppose I could make scripts depend on dtc instead, but I'd be back to needing to fix cleaning. Or I could just skip removing the cross compiler dependency for now. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules
On Sun, Sep 9, 2018 at 6:28 PM Masahiro Yamada wrote: > > 2018-09-06 8:53 GMT+09:00 Rob Herring : > > There is nothing arch specific about building dtb files other than their > > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > > The dependencies and supported targets are all slightly different. > > Also, a cross-compiler for each arch is needed, but really the host > > compiler preprocessor is perfectly fine for building dtbs. Move the > > build rules to a common location and remove the arch specific ones. This > > is done in a single step to avoid warnings about overriding rules. > > > > The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > > These pull in several dependencies some of which need a target compiler > > (specifically devicetable-offsets.h) and aren't needed to build dtbs. > > All that is really needed is dtc, so adjust the dependencies to only be > > dtc. > > > > This change enables support 'dtbs_install' on some arches which were > > missing the target. > > > > Cc: Masahiro Yamada > > Cc: Michal Marek > > Cc: Vineet Gupta > > Cc: Russell King > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Yoshinori Sato > > Cc: Michal Simek > > Cc: Ralf Baechle > > Cc: Paul Burton > > Cc: James Hogan > > Cc: Ley Foon Tan > > Cc: Benjamin Herrenschmidt > > Cc: Paul Mackerras > > Cc: Michael Ellerman > > Cc: Chris Zankel > > Cc: Max Filippov > > Cc: linux-kbu...@vger.kernel.org > > Cc: linux-snps-arc@lists.infradead.org > > Cc: linux-arm-ker...@lists.infradead.org > > Cc: uclinux-h8-de...@lists.sourceforge.jp > > Cc: linux-m...@linux-mips.org > > Cc: nios2-...@lists.rocketboards.org > > Cc: linuxppc-...@lists.ozlabs.org > > Cc: linux-xte...@linux-xtensa.org > > Signed-off-by: Rob Herring > > --- > > Please ack so I can take the whole series via the DT tree. > > > > v2: > > - Fix $arch/boot/dts path check for out of tree builds > > - Fix dtc dependency for building built-in dtbs > > - Fix microblaze built-in dtb building > > > > Makefile | 32 +++ > > arch/arc/Makefile | 6 -- > > arch/arm/Makefile | 20 +-- > > arch/arm64/Makefile | 17 +--- > > arch/c6x/Makefile | 2 -- > > arch/h8300/Makefile | 11 +-- > > arch/microblaze/Makefile | 4 +--- > > arch/microblaze/boot/dts/Makefile | 2 ++ > > arch/mips/Makefile| 15 +-- > > arch/nds32/Makefile | 2 +- > > arch/nios2/Makefile | 7 --- > > arch/nios2/boot/Makefile | 4 > > arch/powerpc/Makefile | 3 --- > > arch/xtensa/Makefile | 12 +--- > > scripts/Makefile.lib | 2 +- > > 15 files changed, 42 insertions(+), 97 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index 2b458801ba74..bc18dbbc16c5 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1212,6 +1212,32 @@ kselftest-merge: > > $(srctree)/tools/testing/selftests/*/config > > +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig > > > > +# > > --- > > +# Devicetree files > > + > > +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) > > +dtstree := arch/$(SRCARCH)/boot/dts > > +endif > > + > > +ifdef CONFIG_OF_EARLY_FLATTREE > > + > > +%.dtb %.dtb.S %.dtb.o: | dtc > > + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > > > Hmm, I was worried about '%.dtb.o: | dtc' > but seems working. > > Compiling %.S -> %.o requires objtool for x86, > but x86 does not support DT. Well, x86 does support DT to some extent. There's 2 platforms and the DT unittests build and run on x86. Actually, we can remove "%.dtb.S %.dtb.o" because we don't need those as top-level build targets. Must have been a copy-n-paste relic from before having common rules. > > If CONFIG_MODVERSIONS=y, scripts/genksyms/genksyms is required, > %.dtb.S does not contain EXPORT_SYMBOL. Okay, but that shouldn't affect any of this. We only build *.dtb.S when doing built-in dtbs. > BTW, 'dtc' should be a PHONY target. Right, I found that too. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v3 0/9] Devicetree build consolidation
This series addresses a couple of issues I have with building dts files. First, the ability to build all the dts files in the tree. This has been supported on most arches for some time with powerpc being the main exception. The reason powerpc wasn't supported was it needed a change in the location built dtb files are put. Secondly, it's a pain to acquire all the cross-compilers needed to build dtbs for each arch. There's no reason to build with the cross compiler and the host compiler is perfectly fine as we only need the pre-processor. I started addressing just those 2 problems, but kept finding small differences such as target dependencies and dtbs_install support across architectures. Instead of trying to align all these, I've consolidated the build targets moving them out of the arch makefiles. I'd like to take the series via the DT tree. Rob v3: - Rework dtc dependency to avoid 2 entry paths to scripts/dtc/. Essentially, I copied 'scripts_basic'. - Add missing scripts_basic dependency for dtc and missing PHONY tag. - Drop the '|' order only from dependencies - Drop %.dtb.S and %.dtb.o as top-level targets - PPC: remove duplicate mpc5200 dtbs from image-y targets v2: - Fix $arch/boot/dts path check for out of tree builds - Fix dtc dependency for building built-in dtbs - Fix microblaze built-in dtb building - Add dtbs target for microblaze Rob Herring (9): powerpc: build .dtb files in dts directory nios2: build .dtb files in dts directory nios2: use common rules to build built-in dtb nios2: fix building all dtbs c6x: use common built-in dtb support kbuild: consolidate Devicetree dtb build rules powerpc: enable building all dtbs c6x: enable building all dtbs microblaze: enable building all dtbs Makefile | 35 ++- arch/arc/Makefile | 6 arch/arm/Makefile | 20 +-- arch/arm64/Makefile| 17 + arch/c6x/Makefile | 2 -- arch/c6x/boot/dts/Makefile | 17 - arch/c6x/boot/dts/linked_dtb.S | 2 -- arch/c6x/include/asm/sections.h| 1 - arch/c6x/kernel/setup.c| 4 +-- arch/c6x/kernel/vmlinux.lds.S | 10 -- arch/h8300/Makefile| 11 +- arch/microblaze/Makefile | 4 +-- arch/microblaze/boot/dts/Makefile | 4 +++ arch/mips/Makefile | 15 +--- arch/nds32/Makefile| 2 +- arch/nios2/Makefile| 11 +- arch/nios2/boot/Makefile | 22 arch/nios2/boot/dts/Makefile | 6 arch/nios2/boot/linked_dtb.S | 19 --- arch/powerpc/Makefile | 3 -- arch/powerpc/boot/Makefile | 55 ++ arch/powerpc/boot/dts/Makefile | 6 arch/powerpc/boot/dts/fsl/Makefile | 4 +++ arch/xtensa/Makefile | 12 +-- scripts/Makefile | 3 +- scripts/Makefile.lib | 2 +- scripts/dtc/Makefile | 2 +- 27 files changed, 100 insertions(+), 195 deletions(-) delete mode 100644 arch/c6x/boot/dts/linked_dtb.S create mode 100644 arch/nios2/boot/dts/Makefile delete mode 100644 arch/nios2/boot/linked_dtb.S create mode 100644 arch/powerpc/boot/dts/Makefile create mode 100644 arch/powerpc/boot/dts/fsl/Makefile -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Acked-by: Will Deacon Acked-by: Paul Burton Acked-by: Ley Foon Tan Cc: Masahiro Yamada Cc: Michal Marek Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Yoshinori Sato Cc: Michal Simek Cc: Ralf Baechle Cc: James Hogan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Chris Zankel Cc: Max Filippov Cc: linux-kbu...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-m...@linux-mips.org Cc: nios2-...@lists.rocketboards.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-xte...@linux-xtensa.org Signed-off-by: Rob Herring --- Makefile | 35 ++- arch/arc/Makefile | 6 -- arch/arm/Makefile | 20 +- arch/arm64/Makefile | 17 +-- arch/c6x/Makefile | 2 -- arch/h8300/Makefile | 11 +- arch/microblaze/Makefile | 4 +--- arch/microblaze/boot/dts/Makefile | 2 ++ arch/mips/Makefile| 15 + arch/nds32/Makefile | 2 +- arch/nios2/Makefile | 7 --- arch/nios2/boot/Makefile | 4 arch/powerpc/Makefile | 3 --- arch/xtensa/Makefile | 12 +-- scripts/Makefile | 3 +-- scripts/Makefile.lib | 2 +- scripts/dtc/Makefile | 2 +- 17 files changed, 46 insertions(+), 101 deletions(-) diff --git a/Makefile b/Makefile index 19948e556941..c43859eba70f 100644 --- a/Makefile +++ b/Makefile @@ -1071,7 +1071,7 @@ include/config/kernel.release: $(srctree)/Makefile FORCE # Carefully list dependencies so we do not try to build scripts twice # in parallel PHONY += scripts -scripts: scripts_basic asm-generic gcc-plugins $(autoksyms_h) +scripts: scripts_basic scripts_dtc asm-generic gcc-plugins $(autoksyms_h) $(Q)$(MAKE) $(build)=$(@) # Things we need to do before we recursively start building the kernel @@ -1215,6 +1215,33 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) +dtstree := arch/$(SRCARCH)/boot/dts +endif + +ifdef CONFIG_OF_EARLY_FLATTREE + +%.dtb : scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs dtbs_install +dtbs: scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: dtbs + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +all: dtbs + +endif + +PHONY += scripts_dtc +scripts_dtc: scripts_basic + $(Q)$(MAKE) $(build)=scripts/dtc + # --- # Modules @@ -1424,6 +1451,12 @@ help: @echo ' kselftest-merge - Merge all the config dependencies of kselftest to existing' @echo '.config.' @echo '' + @$(if $(dtstree), \ + echo 'Devicetree:'; \ + echo '* dtbs- Build device tree blobs for enabled boards'; \ + echo ' dtbs_install- Install dtbs to $(INSTALL_DTBS_PATH)'; \ + echo '') + @echo 'Userspace tools targets:' @echo ' use "make tools/help"' @echo ' or "cd tools; make help"' diff --git a/arch/arc/Makefile b/arch/arc/Makefile index fb026196aaab..5c7bc6d62f43 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz $(boot_targets): vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ -%.dtb %.dtb.S %.dtb.o: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@ - -dtbs: scripts - $(Q)$(MAKE) $(build)=$(boot)/dts - archclean: $(Q)$(MAKE)
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
On Mon, Sep 10, 2018 at 10:04 AM Rob Herring wrote: > > There is nothing arch specific about building dtb files other than their > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > The dependencies and supported targets are all slightly different. > Also, a cross-compiler for each arch is needed, but really the host > compiler preprocessor is perfectly fine for building dtbs. Move the > build rules to a common location and remove the arch specific ones. This > is done in a single step to avoid warnings about overriding rules. > > The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > These pull in several dependencies some of which need a target compiler > (specifically devicetable-offsets.h) and aren't needed to build dtbs. > All that is really needed is dtc, so adjust the dependencies to only be > dtc. > > This change enables support 'dtbs_install' on some arches which were > missing the target. [...] > @@ -1215,6 +1215,33 @@ kselftest-merge: > $(srctree)/tools/testing/selftests/*/config > +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig > > +# --- > +# Devicetree files > + > +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) > +dtstree := arch/$(SRCARCH)/boot/dts > +endif > + > +ifdef CONFIG_OF_EARLY_FLATTREE This can be true when dtstree is unset. So this line should be this instead to fix the 0-day reported error: ifneq ($(dtstree),) > + > +%.dtb : scripts_dtc > + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > + > +PHONY += dtbs dtbs_install > +dtbs: scripts_dtc > + $(Q)$(MAKE) $(build)=$(dtstree) > + > +dtbs_install: dtbs > + $(Q)$(MAKE) $(dtbinst)=$(dtstree) > + > +all: dtbs > + > +endif ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Get rid of toolchain check
On Thu, Sep 13, 2018 at 3:24 PM Alexey Brodkin wrote: > > This check is very naive: we simply test if GCC invoked without > "-mcpu=XXX" has ARC700 define set. In that case we think that GCC > was built with "--with-cpu=arc700" and has libgcc built for ARC700. > > Otherwise if ARC700 is not defined we think that everythng was built > for ARCv2. > > But in reality our life is much more interesting. > > 1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu" >it may generate code for any ARC core). > > 2. libgcc might be built with explicitly specified "--mcpu=YYY" > > That's exactly what happens in case of multilibbed toolchains: > - GCC is configured with default settings > - All the libs built for many different CPU flavors > > I.e. that check gets in the way of usage of multilibbed > toolchains. And even non-multilibbed toolchains are affected. > OpenEmbedded also builds GCC without "--with-cpu" because > each and every target component later is compiled with explicitly > set "-mcpu=ZZZ". > > Signed-off-by: Alexey Brodkin > --- > arch/arc/Makefile | 14 -- > 1 file changed, 14 deletions(-) +1 for this. Removing it also helps with my work to be able to build all the .dts files with only a host compiler. That also needs the hunk setting CROSS_COMPILE removed and not having a built-in dtb by default, but this is a step in the right direction. Acked-by: Rob Herring Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys GPIO via CREG bindings
On Tue, 11 Sep 2018 18:09:25 +0300, Eugeniy Paltsev wrote: > This patch adds documentation of device tree bindings for the Synopsys > GPIO via CREG driver. > > Signed-off-by: Eugeniy Paltsev > --- > .../devicetree/bindings/gpio/snps,creg-gpio.txt| 18 > ++ > 1 file changed, 18 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
On Sun, Sep 23, 2018 at 06:31:14AM -0400, Masahiro Yamada wrote: > 2018-09-13 11:51 GMT-04:00 Geert Uytterhoeven : > > Hi Yamada-san, > > > > On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada > > wrote: > >> 2018-09-12 0:40 GMT+09:00 Rob Herring : > >> > On Mon, Sep 10, 2018 at 10:04 AM Rob Herring wrote: > >> >> There is nothing arch specific about building dtb files other than their > >> >> location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > >> >> The dependencies and supported targets are all slightly different. > >> >> Also, a cross-compiler for each arch is needed, but really the host > >> >> compiler preprocessor is perfectly fine for building dtbs. Move the > >> >> build rules to a common location and remove the arch specific ones. This > >> >> is done in a single step to avoid warnings about overriding rules. > >> >> > >> >> The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > >> >> These pull in several dependencies some of which need a target compiler > >> >> (specifically devicetable-offsets.h) and aren't needed to build dtbs. > >> >> All that is really needed is dtc, so adjust the dependencies to only be > >> >> dtc. > >> >> > >> >> This change enables support 'dtbs_install' on some arches which were > >> >> missing the target. > >> > > >> > [...] > >> > > >> >> @@ -1215,6 +1215,33 @@ kselftest-merge: > >> >> $(srctree)/tools/testing/selftests/*/config > >> >> +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig > >> >> > >> >> +# > >> >> --- > >> >> +# Devicetree files > >> >> + > >> >> +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) > >> >> +dtstree := arch/$(SRCARCH)/boot/dts > >> >> +endif > >> >> + > >> >> +ifdef CONFIG_OF_EARLY_FLATTREE > >> > > >> > This can be true when dtstree is unset. So this line should be this > >> > instead to fix the 0-day reported error: > >> > > >> > ifneq ($(dtstree),) > >> > > >> >> + > >> >> +%.dtb : scripts_dtc > >> >> + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > >> >> + > >> >> +PHONY += dtbs dtbs_install > >> >> +dtbs: scripts_dtc > >> >> + $(Q)$(MAKE) $(build)=$(dtstree) > >> >> + > >> >> +dtbs_install: dtbs > >> >> + $(Q)$(MAKE) $(dtbinst)=$(dtstree) > >> >> + > >> >> +all: dtbs > >> >> + > >> >> +endif > >> > >> > >> Ah, right. > >> Even x86 can enable OF and OF_UNITTEST. > >> > >> > >> > >> Another solution might be, > >> guard it by 'depends on ARCH_SUPPORTS_OF'. > >> > >> > >> > >> This is actually what ACPI does. > >> > >> menuconfig ACPI > >> bool "ACPI (Advanced Configuration and Power Interface) Support" > >> depends on ARCH_SUPPORTS_ACPI > >> ... > > > > ACPI is a real platform feature, as it depends on firmware. > > > > CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform, > > even if it has ACPI ;-) > > > > OK, understood. Any other comments on this? I'd like to get the series into linux-next soon. There was one other problem 0-day reported when building with CONFIG_OF=n while setting CONFIG_OF_ALL_DTBS=y on the kernel command line. The problem is dtc is not built as setting options on the command line doesn't invoke kconfig select(s). This can be fixed by also adding CONFIG_DTC=y to the command line, always building dtc regardless of Kconfig, or making 'all' conditionally dependent on 'dtbs'. I've gone with the last option as that is how this problem was avoided before. So the hunk in question with the 2 fixes now looks like this: @@ -1215,6 +1215,35 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) +dtstree := arch/$(SRCARCH)/boot/dts +endif + +ifneq ($(dtstree),) + +%.dtb : scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs dtbs_install +dtbs: scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: dtbs + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +ifdef CONFIG_OF_EARLY_FLATTREE +all: dtbs +endif + +endif + +PHONY += scripts_dtc +scripts_dtc: scripts_basic + $(Q)$(MAKE) $(build)=scripts/dtc + # --- # Modules ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
On Fri, Sep 28, 2018 at 12:21 PM Andreas Färber wrote: > > Hi Geert, > > Am 13.09.18 um 17:51 schrieb Geert Uytterhoeven: > > On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada > > wrote: > >> Even x86 can enable OF and OF_UNITTEST. > >> > >> Another solution might be, > >> guard it by 'depends on ARCH_SUPPORTS_OF'. > >> > >> This is actually what ACPI does. > >> > >> menuconfig ACPI > >> bool "ACPI (Advanced Configuration and Power Interface) Support" > >> depends on ARCH_SUPPORTS_ACPI > >> ... > > > > ACPI is a real platform feature, as it depends on firmware. > > > > CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform, > > even if it has ACPI ;-) > > How would loading a DT overlay work on an ACPI platform? I.e., what > would it overlay against and how to practically load such a file? The DT unittests do just that. I run them on x86 and UM builds. In this case, the loading source is built-in. > I wonder whether that could be helpful for USB devices and serdev... How to load the overlays is pretty orthogonal to the issues to be solved here. It would certainly be possible to move forward with prototyping this and just have the overlay built-in. It may not even need to be an overlay if we can support multiple root nodes. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
On Mon, Oct 1, 2018 at 12:49 AM Masahiro Yamada wrote: > > Hi Rob, > > > 2018年9月29日(土) 0:43 Rob Herring : > > > +# > > --- > > +# Devicetree files > > + > > +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) > > +dtstree := arch/$(SRCARCH)/boot/dts > > +endif > > + > > +ifneq ($(dtstree),) > > + > > +%.dtb : scripts_dtc > > %.dtb: prepare3 prepare I assume you didn't mean to drop scripts_dtc as that doesn't work. Why "prepare" here and not on dtbs? > because we need to make sure KERNELRELEASE > is correctly defined before dtbs_install happens. Yes, indeed. With prepare3 added I get: cp: cannot create regular file '/boot/dtbs/4.19.0-rc3-9-g0afba9b7b2ea-dirty': No such file or directory vs. with it: cp: cannot create regular file '/boot/dtbs/': Not a directory > > > > + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ > > + > > +PHONY += dtbs dtbs_install > > +dtbs: scripts_dtc > > > dtbs: prepare3 scripts_dtc > > > > > + $(Q)$(MAKE) $(build)=$(dtstree) > > + > > +dtbs_install: dtbs > > > Please do not have dtbs_install to depend on dtbs. > > No install targets should ever trigger building anything > in the source tree. > > > For the background, see the commit log of > 19514fc665ffbce624785f76ee7ad0ea6378a527 Okay, thanks. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v4 0/9] Devicetree build consolidation
This series addresses a couple of issues I have with building dts files. First, the ability to build all the dts files in the tree. This has been supported on most arches for some time with powerpc being the main exception. The reason powerpc wasn't supported was it needed a change in the location built dtb files are put. Secondly, it's a pain to acquire all the cross-compilers needed to build dtbs for each arch. There's no reason to build with the cross compiler and the host compiler is perfectly fine as we only need the pre-processor. I started addressing just those 2 problems, but kept finding small differences such as target dependencies and dtbs_install support across architectures. Instead of trying to align all these, I've consolidated the build targets moving them out of the arch makefiles. I'd like to take the series via the DT tree. PPC maintainers, really need you review/ack on this especially patch 1. Rob v4: - Make dtbs and %.dtb rules depend on arch/$ARCH/boot/dts path rather than CONFIG_OF_EARLY_FLATTREE - Fix install path missing kernel version for dtbs_install - Fix "make CONFIG_OF_ALL_DTBS=y" for arches like ARM which selectively enable CONFIG_OF (and therefore dtc) v3: - Rework dtc dependency to avoid 2 entry paths to scripts/dtc/. Essentially, I copied 'scripts_basic'. - Add missing scripts_basic dependency for dtc and missing PHONY tag. - Drop the '|' order only from dependencies - Drop %.dtb.S and %.dtb.o as top-level targets - PPC: remove duplicate mpc5200 dtbs from image-y targets v2: - Fix $arch/boot/dts path check for out of tree builds - Fix dtc dependency for building built-in dtbs - Fix microblaze built-in dtb building - Add dtbs target for microblaze Rob Herring (9): powerpc: build .dtb files in dts directory nios2: build .dtb files in dts directory nios2: use common rules to build built-in dtb nios2: fix building all dtbs c6x: use common built-in dtb support kbuild: consolidate Devicetree dtb build rules powerpc: enable building all dtbs c6x: enable building all dtbs microblaze: enable building all dtbs Makefile | 37 +++- arch/arc/Makefile | 6 arch/arm/Makefile | 20 +-- arch/arm64/Makefile| 17 + arch/c6x/Makefile | 2 -- arch/c6x/boot/dts/Makefile | 17 - arch/c6x/boot/dts/linked_dtb.S | 2 -- arch/c6x/include/asm/sections.h| 1 - arch/c6x/kernel/setup.c| 4 +-- arch/c6x/kernel/vmlinux.lds.S | 10 -- arch/h8300/Makefile| 11 +- arch/microblaze/Makefile | 4 +-- arch/microblaze/boot/dts/Makefile | 4 +++ arch/mips/Makefile | 15 +--- arch/nds32/Makefile| 2 +- arch/nios2/Makefile| 11 +- arch/nios2/boot/Makefile | 22 arch/nios2/boot/dts/Makefile | 6 arch/nios2/boot/linked_dtb.S | 19 --- arch/powerpc/Makefile | 3 -- arch/powerpc/boot/Makefile | 55 ++ arch/powerpc/boot/dts/Makefile | 6 arch/powerpc/boot/dts/fsl/Makefile | 4 +++ arch/xtensa/Makefile | 12 +-- scripts/Makefile | 3 +- scripts/Makefile.lib | 2 +- scripts/dtc/Makefile | 2 +- 27 files changed, 102 insertions(+), 195 deletions(-) delete mode 100644 arch/c6x/boot/dts/linked_dtb.S create mode 100644 arch/nios2/boot/dts/Makefile delete mode 100644 arch/nios2/boot/linked_dtb.S create mode 100644 arch/powerpc/boot/dts/Makefile create mode 100644 arch/powerpc/boot/dts/fsl/Makefile -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v4 6/9] kbuild: consolidate Devicetree dtb build rules
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Acked-by: Will Deacon Acked-by: Paul Burton Acked-by: Ley Foon Tan Cc: Masahiro Yamada Cc: Michal Marek Cc: Vineet Gupta Cc: Russell King Cc: Catalin Marinas Cc: Yoshinori Sato Cc: Michal Simek Cc: Ralf Baechle Cc: James Hogan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Chris Zankel Cc: Max Filippov Cc: linux-kbu...@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-h8-de...@lists.sourceforge.jp Cc: linux-m...@linux-mips.org Cc: nios2-...@lists.rocketboards.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-xte...@linux-xtensa.org Signed-off-by: Rob Herring --- v4: - Make dtbs and %.dtb rules depend on arch/$ARCH/boot/dts path rather than CONFIG_OF_EARLY_FLATTREE - Fix install path missing kernel version for dtbs_install - Fix "make CONFIG_OF_ALL_DTBS=y" for arches like ARM which selectively enable CONFIG_OF (and therefore dtc) Makefile | 37 ++- arch/arc/Makefile | 6 - arch/arm/Makefile | 20 + arch/arm64/Makefile | 17 +- arch/c6x/Makefile | 2 -- arch/h8300/Makefile | 11 + arch/microblaze/Makefile | 4 +--- arch/microblaze/boot/dts/Makefile | 2 ++ arch/mips/Makefile| 15 + arch/nds32/Makefile | 2 +- arch/nios2/Makefile | 7 -- arch/nios2/boot/Makefile | 4 arch/powerpc/Makefile | 3 --- arch/xtensa/Makefile | 12 +- scripts/Makefile | 3 +-- scripts/Makefile.lib | 2 +- scripts/dtc/Makefile | 2 +- 17 files changed, 48 insertions(+), 101 deletions(-) diff --git a/Makefile b/Makefile index 6c3da3e10f07..251875470c5b 100644 --- a/Makefile +++ b/Makefile @@ -1061,7 +1061,7 @@ include/config/kernel.release: $(srctree)/Makefile FORCE # Carefully list dependencies so we do not try to build scripts twice # in parallel PHONY += scripts -scripts: scripts_basic asm-generic gcc-plugins $(autoksyms_h) +scripts: scripts_basic scripts_dtc asm-generic gcc-plugins $(autoksyms_h) $(Q)$(MAKE) $(build)=$(@) # Things we need to do before we recursively start building the kernel @@ -1205,6 +1205,35 @@ kselftest-merge: $(srctree)/tools/testing/selftests/*/config +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig +# --- +# Devicetree files + +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),) +dtstree := arch/$(SRCARCH)/boot/dts +endif + +ifneq ($(dtstree),) + +%.dtb: prepare3 scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@ + +PHONY += dtbs dtbs_install +dtbs: prepare3 scripts_dtc + $(Q)$(MAKE) $(build)=$(dtstree) + +dtbs_install: + $(Q)$(MAKE) $(dtbinst)=$(dtstree) + +ifdef CONFIG_OF_EARLY_FLATTREE +all: dtbs +endif + +endif + +PHONY += scripts_dtc +scripts_dtc: scripts_basic + $(Q)$(MAKE) $(build)=scripts/dtc + # --- # Modules @@ -1414,6 +1443,12 @@ help: @echo ' kselftest-merge - Merge all the config dependencies of kselftest to existing' @echo '.config.' @echo '' + @$(if $(dtstree), \ + echo 'Devicetree:'; \ + echo '* dtbs- Build device tree blobs for enabled boards'; \ + echo ' dtbs_install- Install dtbs to $(INSTALL_DTBS_PATH)'; \ + echo '') + @echo 'Userspace tools targets:' @echo ' use "make tools/help"' @echo ' or "cd tools; make help"' diff --git a/arch/arc/Makefile b/arch/arc/Makefile index 99cce77ab98f..caece8866080 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefi
Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli wrote: > > Hi all, > > While investigating why ARM64 required a ton of objects to be rebuilt > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was > because we define __early_init_dt_declare_initrd() differently and we do > that in arch/arm64/include/asm/memory.h which gets included by a fair > amount of other header files, and translation units as well. I scratch my head sometimes as to why some config options rebuild so much stuff. One down, ? to go. :) > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build > systems that generate two kernels: one with the initramfs and one > without. buildroot is one of these build systems, OpenWrt is also > another one that does this. > > This patch series proposes adding an empty initrd.h to satisfy the need > for drivers/of/fdt.c to unconditionally include that file, and moves the > custom __early_init_dt_declare_initrd() definition away from > asm/memory.h > > This cuts the number of objects rebuilds from 1920 down to 26, so a > factor 73 approximately. > > Apologies for the long CC list, please let me know how you would go > about merging that and if another approach would be preferable, e.g: > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or > something like that. There may be a better way as of 4.20 because bootmem is now gone and only memblock is used. This should unify what each arch needs to do with initrd early. We need the physical address early for memblock reserving. Then later on we need the virtual address to access the initrd. Perhaps we should just change initrd_start and initrd_end to physical addresses (or add 2 new variables would be less invasive and allow for different translation than __va()). The sanity checks and memblock reserve could also perhaps be moved to a common location. Alternatively, given arm64 is the only oddball, I'd be fine with an "if (IS_ENABLED(CONFIG_ARM64))" condition in the default __early_init_dt_declare_initrd as long as we have a path to removing it like the above option. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
On Wed, Oct 24, 2018 at 3:01 PM Florian Fainelli wrote: > > On 10/24/18 12:55 PM, Rob Herring wrote: > > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli > > wrote: > >> > >> Hi all, > >> > >> While investigating why ARM64 required a ton of objects to be rebuilt > >> when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was > >> because we define __early_init_dt_declare_initrd() differently and we do > >> that in arch/arm64/include/asm/memory.h which gets included by a fair > >> amount of other header files, and translation units as well. > > > > I scratch my head sometimes as to why some config options rebuild so > > much stuff. One down, ? to go. :) > > > > This one was by far the most invasive one due to its include chain, but > yes, there would be many more that could be optimized. > > >> Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build > >> systems that generate two kernels: one with the initramfs and one > >> without. buildroot is one of these build systems, OpenWrt is also > >> another one that does this. > >> > >> This patch series proposes adding an empty initrd.h to satisfy the need > >> for drivers/of/fdt.c to unconditionally include that file, and moves the > >> custom __early_init_dt_declare_initrd() definition away from > >> asm/memory.h > >> > >> This cuts the number of objects rebuilds from 1920 down to 26, so a > >> factor 73 approximately. > >> > >> Apologies for the long CC list, please let me know how you would go > >> about merging that and if another approach would be preferable, e.g: > >> introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or > >> something like that. > > > > There may be a better way as of 4.20 because bootmem is now gone and > > only memblock is used. This should unify what each arch needs to do > > with initrd early. We need the physical address early for memblock > > reserving. Then later on we need the virtual address to access the > > initrd. Perhaps we should just change initrd_start and initrd_end to > > physical addresses (or add 2 new variables would be less invasive and > > allow for different translation than __va()). The sanity checks and > > memblock reserve could also perhaps be moved to a common location. > > > > Alternatively, given arm64 is the only oddball, I'd be fine with an > > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default > > __early_init_dt_declare_initrd as long as we have a path to removing > > it like the above option. > > OK, let me cook a patch doing that and meanwhile I will look at how much > work is involved to implement the above option you outlined, which also > sounds entirely reasonable. BTW, I would suspect that initrd_below_start_ok being 1 is not okay for most arches. I'm not sure how that would work. min_low_pfn is typically based on the start of memory. arm64 is not even setting it. Rob > -- > Florian ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
+Ard
On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport wrote:
>
> On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli
> > wrote:
> > >
> > > Hi all,
> > >
> > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > because we define __early_init_dt_declare_initrd() differently and we do
> > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > amount of other header files, and translation units as well.
> >
> > I scratch my head sometimes as to why some config options rebuild so
> > much stuff. One down, ? to go. :)
> >
> > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > > systems that generate two kernels: one with the initramfs and one
> > > without. buildroot is one of these build systems, OpenWrt is also
> > > another one that does this.
> > >
> > > This patch series proposes adding an empty initrd.h to satisfy the need
> > > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > > custom __early_init_dt_declare_initrd() definition away from
> > > asm/memory.h
> > >
> > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > factor 73 approximately.
> > >
> > > Apologies for the long CC list, please let me know how you would go
> > > about merging that and if another approach would be preferable, e.g:
> > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > something like that.
> >
> > There may be a better way as of 4.20 because bootmem is now gone and
> > only memblock is used. This should unify what each arch needs to do
> > with initrd early. We need the physical address early for memblock
> > reserving. Then later on we need the virtual address to access the
> > initrd. Perhaps we should just change initrd_start and initrd_end to
> > physical addresses (or add 2 new variables would be less invasive and
> > allow for different translation than __va()). The sanity checks and
> > memblock reserve could also perhaps be moved to a common location.
> >
> > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > __early_init_dt_declare_initrd as long as we have a path to removing
> > it like the above option.
>
> I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> Something like this might be just all we need (completely untested,
> probably it won't even compile):
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9d9582c..e9ca238 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>
> #ifdef CONFIG_BLK_DEV_INITRD
> +
> +static phys_addr_t initrd_start_phys, initrd_end_phys;
> +
> static int __init early_initrd(char *p)
> {
> unsigned long start, size;
> @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> if (*endp == ',') {
> size = memparse(endp + 1, NULL);
>
> - initrd_start = start;
> - initrd_end = start + size;
> + initrd_start_phys = start;
> + initrd_end_phys = end;
> }
> return 0;
> }
> @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> }
>
> - if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> + if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
> + (initrd_start || initrd_start_phys)) {
> + /*
> +* FIXME: ensure proper precendence between
> +* early_initrd and DT when both are present
Command line takes precedence, so just reverse the order.
> +*/
> + if (initrd_start) {
> + initrd_start_phys = __phys_to_virt(initrd_start);
> + initrd_end_phys = __phys_to_virt(initrd_end);
AIUI, the original issue was doing the P2V translation was happening
too early and the VA could be wrong if the linear range is adjusted.
So I don't think this would work.
I suppose you could convert the VA back to a PA before any adjustments
and then back to a VA again after. But that's kind of hacky. 2 wrongs
making a right.
>
Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD
On Thu, Oct 25, 2018 at 12:30 PM Mike Rapoport wrote:
>
> On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
> > +Ard
> >
> > On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport wrote:
> > >
> > > On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > > > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli
> > > > wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > > > because we define __early_init_dt_declare_initrd() differently and we
> > > > > do
> > > > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > > > amount of other header files, and translation units as well.
> > > >
> > > > I scratch my head sometimes as to why some config options rebuild so
> > > > much stuff. One down, ? to go. :)
> > > >
> > > > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with
> > > > > build
> > > > > systems that generate two kernels: one with the initramfs and one
> > > > > without. buildroot is one of these build systems, OpenWrt is also
> > > > > another one that does this.
> > > > >
> > > > > This patch series proposes adding an empty initrd.h to satisfy the
> > > > > need
> > > > > for drivers/of/fdt.c to unconditionally include that file, and moves
> > > > > the
> > > > > custom __early_init_dt_declare_initrd() definition away from
> > > > > asm/memory.h
> > > > >
> > > > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > > > factor 73 approximately.
> > > > >
> > > > > Apologies for the long CC list, please let me know how you would go
> > > > > about merging that and if another approach would be preferable, e.g:
> > > > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > > > something like that.
> > > >
> > > > There may be a better way as of 4.20 because bootmem is now gone and
> > > > only memblock is used. This should unify what each arch needs to do
> > > > with initrd early. We need the physical address early for memblock
> > > > reserving. Then later on we need the virtual address to access the
> > > > initrd. Perhaps we should just change initrd_start and initrd_end to
> > > > physical addresses (or add 2 new variables would be less invasive and
> > > > allow for different translation than __va()). The sanity checks and
> > > > memblock reserve could also perhaps be moved to a common location.
> > > >
> > > > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > > > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > > > __early_init_dt_declare_initrd as long as we have a path to removing
> > > > it like the above option.
> > >
> > > I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> > > Something like this might be just all we need (completely untested,
> > > probably it won't even compile):
> > >
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > index 9d9582c..e9ca238 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> > > phys_addr_t arm64_dma_phys_limit __ro_after_init;
> > >
> > > #ifdef CONFIG_BLK_DEV_INITRD
> > > +
> > > +static phys_addr_t initrd_start_phys, initrd_end_phys;
> > > +
> > > static int __init early_initrd(char *p)
> > > {
> > > unsigned long start, size;
> > > @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> > > if (*endp == ',') {
> > > size = memparse(endp + 1, NULL);
> > >
> > > - initrd_start = start;
> > > - initrd_end = start + size;
> > > + initrd_start_phys = start;
> > > + initrd_end_phys = end;
> > > }
> > > return 0;
> > > }
> > > @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> > >
Re: [PATCH v2 5/6] of/fdt: Remove custom __early_init_dt_declare_initrd() implementation
On Tue, Oct 30, 2018 at 6:07 PM Florian Fainelli wrote:
>
> Now that ARM64 uses phys_initrd_start/phys_initrd_size, we can get rid
> of its custom __early_init_dt_declare_initrd() which causes a fair
> amount of objects rebuild when changing CONFIG_BLK_DEV_INITRD. In order
> to make sure ARM64 does not produce a BUG() when VM debugging is turned
> on though, we must avoid early calls to __va() which is what
> __early_init_dt_declare_initrd() does and wrap this around to avoid
> running that code on ARM64.
>
> Signed-off-by: Florian Fainelli
> ---
> arch/arm64/include/asm/memory.h | 8
> drivers/of/fdt.c| 9 +++--
> 2 files changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b96442960aea..dc3ca21ba240 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -168,14 +168,6 @@
> #define IOREMAP_MAX_ORDER (PMD_SHIFT)
> #endif
>
> -#ifdef CONFIG_BLK_DEV_INITRD
> -#define __early_init_dt_declare_initrd(__start, __end) \
> - do {\
> - initrd_start = (__start); \
> - initrd_end = (__end); \
> - } while (0)
> -#endif
> -
> #ifndef __ASSEMBLY__
>
> #include
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index e34cb49231b5..f2b5becae96a 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -892,15 +892,20 @@ const void * __init of_flat_dt_match_machine(const void
> *default_match,
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -#ifndef __early_init_dt_declare_initrd
> static void __early_init_dt_declare_initrd(unsigned long start,
>unsigned long end)
> {
> + /* ARM64 would cause a BUG to occur here when CONFIG_DEBUG_VM is
> +* enabled since __va() is called too early. ARM64 does make use
> +* of phys_initrd_start/phys_initrd_size so we can skip this
> +* conversion.
> +*/
> +#if (!IS_ENABLED(CONFIG_ARM64))
Use 'if' not '#if'. Use C code rather than preprocessor whenever possible.
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> initrd_below_start_ok = 1;
> -}
> #endif
> +}
>
> /**
> * early_init_dt_check_for_initrd - Decode initrd location from flat tree
> --
> 2.17.1
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 4/6] arm64: Utilize phys_initrd_start/phys_initrd_size
On Wed, Oct 31, 2018 at 12:28:41PM -0700, Florian Fainelli wrote:
> ARM64 is the only architecture that re-defines
> __early_init_dt_declare_initrd() in order for that function to populate
> initrd_start/initrd_end with physical addresses instead of virtual
> addresses. Instead of having an override we can leverage
> drivers/of/fdt.c populating phys_initrd_start/phys_initrd_size to
> populate those variables for us.
>
> Signed-off-by: Florian Fainelli
> ---
> arch/arm64/mm/init.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3cf87341859f..00ef2166bb73 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -72,8 +72,8 @@ static int __init early_initrd(char *p)
> if (*endp == ',') {
> size = memparse(endp + 1, NULL);
>
> - initrd_start = start;
> - initrd_end = start + size;
> + phys_initrd_start = start;
> + phys_initrd_size = size;
> }
> return 0;
> }
> @@ -408,14 +408,14 @@ void __init arm64_memblock_init(void)
> memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> }
>
> - if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> + if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {
> /*
>* Add back the memory we just removed if it results in the
>* initrd to become inaccessible via the linear mapping.
>* Otherwise, this is a no-op
>*/
> - u64 base = initrd_start & PAGE_MASK;
> - u64 size = PAGE_ALIGN(initrd_end) - base;
> + u64 base = phys_initrd_start & PAGE_MASK;
> + u64 size = PAGE_ALIGN(phys_initrd_size);
>
> /*
>* We can only add back the initrd memory if we don't end up
> @@ -460,12 +460,11 @@ void __init arm64_memblock_init(void)
>*/
> memblock_reserve(__pa_symbol(_text), _end - _text);
> #ifdef CONFIG_BLK_DEV_INITRD
> - if (initrd_start) {
> - memblock_reserve(initrd_start, initrd_end - initrd_start);
> -
> + if (phys_initrd_size) {
Since we're touching the if anyways, perhaps convert the #ifdef to a C
IS_ENABLED().
> /* the generic initrd code expects virtual addresses */
> - initrd_start = __phys_to_virt(initrd_start);
> - initrd_end = __phys_to_virt(initrd_end);
> + initrd_start = __phys_to_virt(phys_initrd_start);
> + initrd_end = initrd_start + phys_initrd_size;
> + initrd_below_start_ok = 0;
> }
> #endif
>
> --
> 2.17.1
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 0/6] arm64: Get rid of __early_init_dt_declare_initrd()
On Wed, Oct 31, 2018 at 12:28:37PM -0700, Florian Fainelli wrote: > Hi all, > > Changes in v3: > > - use C conditionals in drivers/of/fdt.c > - added check on phys_initrd_size in arch/arm64/mm/init.c to determine > whether initrd_start must be populated > - fixed a build warning with ARC that was just missing an (unsigned > long) cast > > Changes in v2: > > - get rid of ARCH_HAS_PHYS_INITRD and instead define > phys_initrd_start/phys_initrd_size in init/do_mounts_initrd.c > > - make __early_init_dt_declare_initrd() account for ARM64 specific > behavior with __va() when having CONFIG_DEBUG_VM enabled > > - consolidate early_initrd() command line parsing into > init/do_mounts_initrd.c > > Because phys_initrd_start/phys_initrd_size are now compiled in > ini/do_mounts_initrd.c which is only built with CONFIG_BLK_DEV_INITRD=y, > we need to be a bit careful about the uses throughout architecture > specific code. > > Previous discussions/submissions list here: > > v3: > https://www.spinics.net/lists/arm-kernel/msg683566.html > v2: > https://lkml.org/lkml/2018/10/25/4 > > Florian Fainelli (6): > nds32: Remove phys_initrd_start and phys_initrd_size > arch: Make phys_initrd_start and phys_initrd_size global variables > of/fdt: Populate phys_initrd_start/phys_initrd_size from FDT > arm64: Utilize phys_initrd_start/phys_initrd_size > of/fdt: Remove custom __early_init_dt_declare_initrd() implementation > arch: Move initrd= parsing into do_mounts_initrd.c This all looks good to me. I can take it via the DT if you want. I'll give folks some more time to review though. Rob > > arch/arc/mm/init.c | 25 + > arch/arm/mm/init.c | 28 ++-- > arch/arm64/include/asm/memory.h | 8 > arch/arm64/mm/init.c| 33 +++-- > arch/nds32/mm/init.c| 2 -- > arch/unicore32/mm/init.c| 24 +--- > drivers/of/fdt.c| 17 - > include/linux/initrd.h | 3 +++ > init/do_mounts_initrd.c | 20 > 9 files changed, 54 insertions(+), 106 deletions(-) > > -- > 2.17.1 > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 0/6] arm64: Get rid of __early_init_dt_declare_initrd()
On Mon, Nov 12, 2018 at 12:32:50PM -0800, Florian Fainelli wrote: > On 11/6/18 6:06 AM, Mike Rapoport wrote: > > On Mon, Nov 05, 2018 at 02:54:25PM -0800, Florian Fainelli wrote: > >> Hi all, > >> > >> Changes in v4: > >> > >> - dropped initrd_below_start_ok assignment in ARM64, not necessary at > >> all (Ard) > >> - replace #ifdef CONFIG_BLK_DEV_INITRD with if > >> (IS_ENABLED(CONFIG_BLK_DEV_INITRD) for consistency with other parts > >> of arm64_memblock_init() (Rob) > >> > >> Changes in v3: > >> > >> - use C conditionals in drivers/of/fdt.c > >> - added check on phys_initrd_size in arch/arm64/mm/init.c to determine > >> whether initrd_start must be populated > >> - fixed a build warning with ARC that was just missing an (unsigned > >> long) cast > >> > >> Changes in v2: > >> > >> - get rid of ARCH_HAS_PHYS_INITRD and instead define > >> phys_initrd_start/phys_initrd_size in init/do_mounts_initrd.c > >> > >> - make __early_init_dt_declare_initrd() account for ARM64 specific > >> behavior with __va() when having CONFIG_DEBUG_VM enabled > >> > >> - consolidate early_initrd() command line parsing into > >> init/do_mounts_initrd.c > >> > >> Because phys_initrd_start/phys_initrd_size are now compiled in > >> ini/do_mounts_initrd.c which is only built with CONFIG_BLK_DEV_INITRD=y, > >> we need to be a bit careful about the uses throughout architecture > >> specific code. > >> > >> Previous discussions/submissions list here: > >> > >> v3: > >> https://www.spinics.net/lists/arm-kernel/msg683566.html > >> v2: > >> https://lkml.org/lkml/2018/10/25/4 > >> > >> Florian Fainelli (6): > >> nds32: Remove phys_initrd_start and phys_initrd_size > >> arch: Make phys_initrd_start and phys_initrd_size global variables > >> of/fdt: Populate phys_initrd_start/phys_initrd_size from FDT > >> arm64: Utilize phys_initrd_start/phys_initrd_size > >> of/fdt: Remove custom __early_init_dt_declare_initrd() implementation > >> arch: Move initrd= parsing into do_mounts_initrd.c > > > > For the series: > > > > Reviewed-by: Mike Rapoport > > Thanks Mike, Rob, do you want to merge that series through the OF tree? Sure, some arch maintainer acks would be nice. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v4 0/6] arm64: Get rid of __early_init_dt_declare_initrd()
On Mon, Nov 12, 2018 at 06:22:16PM -0600, Rob Herring wrote: > On Mon, Nov 12, 2018 at 12:32:50PM -0800, Florian Fainelli wrote: > > On 11/6/18 6:06 AM, Mike Rapoport wrote: > > > On Mon, Nov 05, 2018 at 02:54:25PM -0800, Florian Fainelli wrote: > > >> Hi all, > > >> > > >> Changes in v4: > > >> > > >> - dropped initrd_below_start_ok assignment in ARM64, not necessary at > > >> all (Ard) > > >> - replace #ifdef CONFIG_BLK_DEV_INITRD with if > > >> (IS_ENABLED(CONFIG_BLK_DEV_INITRD) for consistency with other parts > > >> of arm64_memblock_init() (Rob) > > >> > > >> Changes in v3: > > >> > > >> - use C conditionals in drivers/of/fdt.c > > >> - added check on phys_initrd_size in arch/arm64/mm/init.c to determine > > >> whether initrd_start must be populated > > >> - fixed a build warning with ARC that was just missing an (unsigned > > >> long) cast > > >> > > >> Changes in v2: > > >> > > >> - get rid of ARCH_HAS_PHYS_INITRD and instead define > > >> phys_initrd_start/phys_initrd_size in init/do_mounts_initrd.c > > >> > > >> - make __early_init_dt_declare_initrd() account for ARM64 specific > > >> behavior with __va() when having CONFIG_DEBUG_VM enabled > > >> > > >> - consolidate early_initrd() command line parsing into > > >> init/do_mounts_initrd.c > > >> > > >> Because phys_initrd_start/phys_initrd_size are now compiled in > > >> ini/do_mounts_initrd.c which is only built with CONFIG_BLK_DEV_INITRD=y, > > >> we need to be a bit careful about the uses throughout architecture > > >> specific code. > > >> > > >> Previous discussions/submissions list here: > > >> > > >> v3: > > >> https://www.spinics.net/lists/arm-kernel/msg683566.html > > >> v2: > > >> https://lkml.org/lkml/2018/10/25/4 > > >> > > >> Florian Fainelli (6): > > >> nds32: Remove phys_initrd_start and phys_initrd_size > > >> arch: Make phys_initrd_start and phys_initrd_size global variables > > >> of/fdt: Populate phys_initrd_start/phys_initrd_size from FDT > > >> arm64: Utilize phys_initrd_start/phys_initrd_size > > >> of/fdt: Remove custom __early_init_dt_declare_initrd() implementation > > >> arch: Move initrd= parsing into do_mounts_initrd.c > > > > > > For the series: > > > > > > Reviewed-by: Mike Rapoport > > > > Thanks Mike, Rob, do you want to merge that series through the OF tree? > > Sure, some arch maintainer acks would be nice. I've now applied the series. Thanks, Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: Remove 0x prefix from unit-address of node names
On Sat, Dec 8, 2018 at 1:01 AM Alexey Brodkin
wrote:
>
> Done automatically with help of:
> --->8
> sed -i 's/@0x/@/g' arch/arc/boot/dts/*.dts*
> --->8
>
> Inspired by [1] and the like.
>
> [1] http://kisskb.ellerman.id.au/kisskb/buildresult/13612017/
>
> Signed-off-by: Alexey Brodkin
> Cc: Rob Herring
>
> Signed-off-by: Alexey Brodkin
> ---
> arch/arc/boot/dts/abilis_tb10x.dtsi | 4 ++--
> arch/arc/boot/dts/axc001.dtsi | 6 +++---
> arch/arc/boot/dts/axc003.dtsi | 14 +++---
> arch/arc/boot/dts/axc003_idu.dtsi | 14 +++---
> arch/arc/boot/dts/axs10x_mb.dtsi | 22 +++---
> arch/arc/boot/dts/vdk_axc003.dtsi | 4 ++--
> arch/arc/boot/dts/vdk_axc003_idu.dtsi | 4 ++--
> arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 14 +++---
> 8 files changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arc/boot/dts/abilis_tb10x.dtsi
> b/arch/arc/boot/dts/abilis_tb10x.dtsi
> index 3121536b25a3..77ac1368a65b 100644
> --- a/arch/arc/boot/dts/abilis_tb10x.dtsi
> +++ b/arch/arc/boot/dts/abilis_tb10x.dtsi
> @@ -178,7 +178,7 @@
> clocks = <&ahb_clk>;
> };
>
> - spi0: spi@0xFE01 {
> + spi0: spi@FE01 {
This should be lowercase too.
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
[...]
> @@ -119,7 +119,7 @@
> * This node is intentionally put outside of MB above becase
> * it maps areas outside of MB's 0xEz-0xFz.
> */
> - uio_ev: uio@0xD000 {
> + uio_ev: uio@D000 {
lowercase
> compatible = "generic-uio";
> reg = <0xD000 0x2000 0xD100 0x2000 0x9000
> 0x1000 0xC000 0x1000>;
> reg-names = "ev_gsa", "ev_ctrl", "ev_shared_mem",
> "ev_code_mem";
> --
> 2.16.2
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 08/21] memblock: drop __memblock_alloc_base()
On Wed, Jan 16, 2019 at 7:45 AM Mike Rapoport wrote: > > The __memblock_alloc_base() function tries to allocate a memory up to the > limit specified by its max_addr parameter. Depending on the value of this > parameter, the __memblock_alloc_base() can is replaced with the appropriate > memblock_phys_alloc*() variant. > > Signed-off-by: Mike Rapoport > --- > arch/sh/kernel/machine_kexec.c | 3 ++- > arch/x86/kernel/e820.c | 2 +- > arch/x86/mm/numa.c | 12 > drivers/of/of_reserved_mem.c | 7 ++- > include/linux/memblock.h | 2 -- > mm/memblock.c | 9 ++--- > 6 files changed, 11 insertions(+), 24 deletions(-) Acked-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()
On Wed, Jan 16, 2019 at 7:46 AM Mike Rapoport wrote:
>
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
> ---
> arch/alpha/kernel/core_cia.c | 3 +++
> arch/alpha/kernel/core_marvel.c | 6 ++
> arch/alpha/kernel/pci-noop.c | 11 ++-
> arch/alpha/kernel/pci.c | 11 ++-
> arch/alpha/kernel/pci_iommu.c | 12
> arch/arc/mm/highmem.c | 4
> arch/arm/kernel/setup.c | 6 ++
> arch/arm/mm/mmu.c | 14 +-
> arch/arm64/kernel/setup.c | 9 ++---
> arch/arm64/mm/kasan_init.c| 10 ++
> arch/c6x/mm/dma-coherent.c| 4
> arch/c6x/mm/init.c| 3 +++
> arch/csky/mm/highmem.c| 5 +
> arch/h8300/mm/init.c | 3 +++
> arch/m68k/atari/stram.c | 4
> arch/m68k/mm/init.c | 3 +++
> arch/m68k/mm/mcfmmu.c | 6 ++
> arch/m68k/mm/motorola.c | 9 +
> arch/m68k/mm/sun3mmu.c| 6 ++
> arch/m68k/sun3/sun3dvma.c | 3 +++
> arch/microblaze/mm/init.c | 8 ++--
> arch/mips/cavium-octeon/dma-octeon.c | 3 +++
> arch/mips/kernel/setup.c | 3 +++
> arch/mips/kernel/traps.c | 3 +++
> arch/mips/mm/init.c | 5 +
> arch/nds32/mm/init.c | 12
> arch/openrisc/mm/ioremap.c| 8 ++--
> arch/powerpc/kernel/dt_cpu_ftrs.c | 5 +
> arch/powerpc/kernel/pci_32.c | 3 +++
> arch/powerpc/kernel/setup-common.c| 3 +++
> arch/powerpc/kernel/setup_64.c| 4
> arch/powerpc/lib/alloc.c | 3 +++
> arch/powerpc/mm/hash_utils_64.c | 3 +++
> arch/powerpc/mm/mmu_context_nohash.c | 9 +
> arch/powerpc/mm/pgtable-book3e.c | 12 ++--
> arch/powerpc/mm/pgtable-book3s64.c| 3 +++
> arch/powerpc/mm/pgtable-radix.c | 9 -
> arch/powerpc/mm/ppc_mmu_32.c | 3 +++
> arch/powerpc/platforms/pasemi/iommu.c | 3 +++
> arch/powerpc/platforms/powermac/nvram.c | 3 +++
> arch/powerpc/platforms/powernv/opal.c | 3 +++
> arch/powerpc/platforms/powernv/pci-ioda.c | 8
> arch/powerpc/platforms/ps3/setup.c| 3 +++
> arch/powerpc/sysdev/msi_bitmap.c | 3 +++
> arch/s390/kernel/setup.c | 13 +
> arch/s390/kernel/smp.c| 5 -
> arch/s390/kernel/topology.c | 6 ++
> arch/s390/numa/mode_emu.c | 3 +++
> arch/s390/numa/numa.c | 6 +-
> arch/s390/numa/toptree.c | 8 ++--
> arch/sh/mm/init.c | 6 ++
> arch/sh/mm/numa.c | 4
> arch/um/drivers/net_kern.c| 3 +++
> arch/um/drivers/vector_kern.c | 3 +++
> arch/um/kernel/initrd.c | 2 ++
> arch/um/kernel/mem.c | 16
> arch/unicore32/kernel/setup.c | 4
> arch/unicore32/mm/mmu.c | 15 +--
> arch/x86/kernel/acpi/boot.c | 3 +++
> arch/x86/kernel/apic/io_apic.c| 5 +
> arch/x86/kernel/e820.c| 3 +++
> arch/x86/platform/olpc/olpc_dt.c | 3 +++
> arch/x86/xen/p2m.c| 11 +--
> arch/xtensa/mm/kasan_init.c | 4
> arch/xtensa/mm/mmu.c | 3 +++
> drivers/clk/ti/clk.c | 3 +++
> drivers/macintosh/smu.c | 3 +++
> drivers/of/fdt.c | 8 +++-
> drivers/of/unittest.c | 8 +++-
Acked-by: Rob Herring
> drivers/xen/swiotlb-xen.c | 7 +--
> kernel/power/snapshot.c | 3 +++
> lib/cpuma
Re: [PATCH v2 19/21] treewide: add checks for the return value of memblock_alloc*()
On Mon, Jan 21, 2019 at 10:04:06AM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
> Reviewed-by: Guo Ren # c-sky
> Acked-by: Paul Burton# MIPS
> Acked-by: Heiko Carstens # s390
> Reviewed-by: Juergen Gross # Xen
> ---
> arch/alpha/kernel/core_cia.c | 3 +++
> arch/alpha/kernel/core_marvel.c | 6 ++
> arch/alpha/kernel/pci-noop.c | 13 +++--
> arch/alpha/kernel/pci.c | 11 ++-
> arch/alpha/kernel/pci_iommu.c | 12
> arch/arc/mm/highmem.c | 4
> arch/arm/kernel/setup.c | 6 ++
> arch/arm/mm/mmu.c | 14 +-
> arch/arm64/kernel/setup.c | 8 +---
> arch/arm64/mm/kasan_init.c| 10 ++
> arch/c6x/mm/dma-coherent.c| 4
> arch/c6x/mm/init.c| 3 +++
> arch/csky/mm/highmem.c| 5 +
> arch/h8300/mm/init.c | 3 +++
> arch/m68k/atari/stram.c | 4
> arch/m68k/mm/init.c | 3 +++
> arch/m68k/mm/mcfmmu.c | 6 ++
> arch/m68k/mm/motorola.c | 9 +
> arch/m68k/mm/sun3mmu.c| 6 ++
> arch/m68k/sun3/sun3dvma.c | 3 +++
> arch/microblaze/mm/init.c | 8 ++--
> arch/mips/cavium-octeon/dma-octeon.c | 3 +++
> arch/mips/kernel/setup.c | 3 +++
> arch/mips/kernel/traps.c | 3 +++
> arch/mips/mm/init.c | 5 +
> arch/nds32/mm/init.c | 12
> arch/openrisc/mm/ioremap.c| 8 ++--
> arch/powerpc/kernel/dt_cpu_ftrs.c | 5 +
> arch/powerpc/kernel/pci_32.c | 3 +++
> arch/powerpc/kernel/setup-common.c| 3 +++
> arch/powerpc/kernel/setup_64.c| 4
> arch/powerpc/lib/alloc.c | 3 +++
> arch/powerpc/mm/hash_utils_64.c | 3 +++
> arch/powerpc/mm/mmu_context_nohash.c | 9 +
> arch/powerpc/mm/pgtable-book3e.c | 12 ++--
> arch/powerpc/mm/pgtable-book3s64.c| 3 +++
> arch/powerpc/mm/pgtable-radix.c | 9 -
> arch/powerpc/mm/ppc_mmu_32.c | 3 +++
> arch/powerpc/platforms/pasemi/iommu.c | 3 +++
> arch/powerpc/platforms/powermac/nvram.c | 3 +++
> arch/powerpc/platforms/powernv/opal.c | 3 +++
> arch/powerpc/platforms/powernv/pci-ioda.c | 8
> arch/powerpc/platforms/ps3/setup.c| 3 +++
> arch/powerpc/sysdev/msi_bitmap.c | 3 +++
> arch/s390/kernel/setup.c | 13 +
> arch/s390/kernel/smp.c| 5 -
> arch/s390/kernel/topology.c | 6 ++
> arch/s390/numa/mode_emu.c | 3 +++
> arch/s390/numa/numa.c | 6 +-
> arch/sh/mm/init.c | 6 ++
> arch/sh/mm/numa.c | 4
> arch/um/drivers/net_kern.c| 3 +++
> arch/um/drivers/vector_kern.c | 3 +++
> arch/um/kernel/initrd.c | 2 ++
> arch/um/kernel/mem.c | 16
> arch/unicore32/kernel/setup.c | 4
> arch/unicore32/mm/mmu.c | 15 +--
> arch/x86/kernel/acpi/boot.c | 3 +++
> arch/x86/kernel/apic/io_apic.c| 5 +
> arch/x86/kernel/e820.c| 3 +++
> arch/x86/platform/olpc/olpc_dt.c | 3 +++
> arch/x86/xen/p2m.c| 11 +--
> arch/xtensa/mm/kasan_init.c | 4
> arch/xtensa/mm/mmu.c | 3 +++
> drivers/clk/ti/clk.c | 3 +++
> drivers/macintosh/smu.c | 3 +++
> drivers/of/fdt.c | 8 +++-
> drivers/of/unittest.c | 8 +++-
Acked-by: Rob Herrin
Re: [PATCH v2] ARC: [scripted] fix node name and address spelling
On Thu, Jan 24, 2019 at 6:17 AM Alexey Brodkin wrote: > > From: Alexey Brodkin > > 1. Remove "0x" prefix from unit-address of node names > --->8 > sed -i 's/@0x/@/g' arch/arc/boot/dts/*.dts* > --->8 > > 2. Make all hex addresses lowercase: > --->8 > sed -i 's/@\([0-9A-Za-z]*\)/@\L\1/g' arch/arc/boot/dts/*.dts* > sed -i 's/0x\([0-9A-Za-z]*\)/0x\L\1/g' arch/arc/boot/dts/*.dts* > --->8 > > Inspired by [1] and the like. > > [1] http://kisskb.ellerman.id.au/kisskb/buildresult/13612017/ > > Signed-off-by: Alexey Brodkin > Cc: Rob Herring > --- > > Changes v1 -> v2: > > * Convert all hex addresses to lower-case [Rob] > > arch/arc/boot/dts/abilis_tb100.dtsi| 58 > arch/arc/boot/dts/abilis_tb100_dvk.dts | 14 > arch/arc/boot/dts/abilis_tb101.dtsi| 58 > arch/arc/boot/dts/abilis_tb101_dvk.dts | 14 > arch/arc/boot/dts/abilis_tb10x.dtsi| 60 > +- > arch/arc/boot/dts/axc001.dtsi | 6 ++-- > arch/arc/boot/dts/axc003.dtsi | 16 - > arch/arc/boot/dts/axc003_idu.dtsi | 16 - > arch/arc/boot/dts/axs10x_mb.dtsi | 22 ++--- > arch/arc/boot/dts/hsdk.dts | 4 +-- > arch/arc/boot/dts/vdk_axc003.dtsi | 4 +-- > arch/arc/boot/dts/vdk_axc003_idu.dtsi | 4 +-- > arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 18 +- > 13 files changed, 147 insertions(+), 147 deletions(-) Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/12] of: select OF_RESERVED_MEM automatically
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig wrote: > > The OF_RESERVED_MEM can be used if we have either CMA or the generic > declare coherent code built and we support the early flattened DT. > > So don't bother making it a user visible options that is selected > by most configs that fit the above category, but just select it when > the requirements are met. > > Signed-off-by: Christoph Hellwig > --- > arch/arc/Kconfig | 1 - > arch/arm/Kconfig | 1 - > arch/arm64/Kconfig | 1 - > arch/csky/Kconfig| 1 - > arch/powerpc/Kconfig | 1 - > arch/xtensa/Kconfig | 1 - > drivers/of/Kconfig | 5 ++--- > 7 files changed, 2 insertions(+), 9 deletions(-) Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/12] of: mark early_init_dt_alloc_reserved_memory_arch static
On Mon, Feb 11, 2019 at 7:36 AM Christoph Hellwig wrote: > > This function is only used in of_reserved_mem.c, and never overridden > despite the __weak marker. > > Signed-off-by: Christoph Hellwig > --- > drivers/of/of_reserved_mem.c| 2 +- > include/linux/of_reserved_mem.h | 7 --- > 2 files changed, 1 insertion(+), 8 deletions(-) Reviewed-by: Rob Herring Looks like this one isn't a dependency, so I can take it if you want. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability
On Mon, Feb 11, 2019 at 7:37 AM Christoph Hellwig wrote: > > This API is primarily used through DT entries, but two architectures > and two drivers call it directly. So instead of selecting the config > symbol for random architectures pull it in implicitly for the actual > users. Also rename the Kconfig option to describe the feature better. > > Signed-off-by: Christoph Hellwig > --- > arch/arc/Kconfig| 1 - > arch/arm/Kconfig| 2 +- > arch/arm64/Kconfig | 1 - > arch/csky/Kconfig | 1 - > arch/mips/Kconfig | 1 - > arch/riscv/Kconfig | 1 - > arch/sh/Kconfig | 2 +- > arch/unicore32/Kconfig | 1 - > arch/x86/Kconfig| 1 - > drivers/mfd/Kconfig | 2 ++ > drivers/of/Kconfig | 3 ++- > include/linux/device.h | 2 +- > include/linux/dma-mapping.h | 8 > kernel/dma/Kconfig | 2 +- > kernel/dma/Makefile | 2 +- > 15 files changed, 13 insertions(+), 17 deletions(-) > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > index 3607fd2810e4..f8c66a9472a4 100644 > --- a/drivers/of/Kconfig > +++ b/drivers/of/Kconfig > @@ -43,6 +43,7 @@ config OF_FLATTREE > > config OF_EARLY_FLATTREE > bool > + select DMA_DECLARE_COHERENT Is selecting DMA_DECLARE_COHERENT okay on UML? We run the unittests with UML. Maybe we should just get rid of OF_RESERVED_MEM. If we support booting from DT, then it should always be enabled anyways. > select OF_FLATTREE > > config OF_PROMTREE > @@ -83,7 +84,7 @@ config OF_MDIO > config OF_RESERVED_MEM > bool > depends on OF_EARLY_FLATTREE > - default y if HAVE_GENERIC_DMA_COHERENT || DMA_CMA > + default y if DMA_DECLARE_COHERENT || DMA_CMA > > config OF_RESOLVE > bool ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability
On Wed, Feb 13, 2019 at 12:24 PM Christoph Hellwig wrote: > > On Tue, Feb 12, 2019 at 02:40:23PM -0600, Rob Herring wrote: > > > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig > > > index 3607fd2810e4..f8c66a9472a4 100644 > > > --- a/drivers/of/Kconfig > > > +++ b/drivers/of/Kconfig > > > @@ -43,6 +43,7 @@ config OF_FLATTREE > > > > > > config OF_EARLY_FLATTREE > > > bool > > > + select DMA_DECLARE_COHERENT > > > > Is selecting DMA_DECLARE_COHERENT okay on UML? We run the unittests with > > UML. > > No, that will fail with undefined references to memunmap. > > I gues this needs to be > > select DMA_DECLARE_COHERENT if HAS_DMA > > > Maybe we should just get rid of OF_RESERVED_MEM. If we support booting > > from DT, then it should always be enabled anyways. > > Fine with me. Do you want me to respin the series to just remove > it? Either now or it can wait. I don't want to hold this up any. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/3] dt-bindings: IDU-intc: Clean up documentation
On Wed, 24 Jul 2019 14:04:35 +0200, Mischa Jonker wrote: > * Some lines exceeded 80 characters. > * Clarified statement about AUX register interface > > Signed-off-by: Mischa Jonker > --- > .../bindings/interrupt-controller/snps,archs-idu-intc.txt| 9 > + > 1 file changed, 5 insertions(+), 4 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v2 3/3] dt-bindings: IDU-intc: Add support for edge-triggered interrupts
On Wed, 24 Jul 2019 14:04:36 +0200, Mischa Jonker wrote: > This updates the documentation for supporting an optional extra interrupt > cell to specify edge vs level triggered. > > Signed-off-by: Mischa Jonker > --- > .../interrupt-controller/snps,archs-idu-intc.txt | 19 > ++- > 1 file changed, 14 insertions(+), 5 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH 4/7] dt-bindings: chosen: Add clocksource and clockevent selection
On Wed, Sep 11, 2019 at 07:18:07AM +, claudiu.bez...@microchip.com wrote:
>
>
> On 11.09.2019 03:03, Linus Walleij wrote:
> > External E-Mail
> >
> >
> > On Tue, Sep 10, 2019 at 4:11 PM Alexandre Belloni
> > wrote:
> >> On 10/09/2019 16:08:26+0100, Sudeep Holla wrote:
> >>> On Tue, Sep 10, 2019 at 02:51:50PM +, claudiu.bez...@microchip.com
> >>> wrote:
> >
> >>> In that case, why can't we identify capability that with the compatibles
> >>> for this timer IP ?
> >>>
> >>> IOW, I don't like the proposal as it's hardware limitation.
> >>
> >> To be clear, bot timers are exactly the same but can't be clocksource
> >> and clockevent at the same time. Why would we have different compatibles
> >> for the exact same IP?
> >
> > In that case why not just pick the first one you find as clocksource
> > and the second one as clock event? As they all come to the
> > same timer of init function two simple local state variables can
> > solve that:
> >
> > static bool registered_clocksource;
> > static bool registered_clockevent;
> >
> > probe(timer) {
> >if (!registered_clocksource) {
> >register_clocksource(timer);
> >registrered_clocksource = true;
> >return;
> >}
> >if (!registered_clockevent) {
> >register_clockevent(timer);
> >registered_clockevent = true;
> >return;
> >}
> >pr_info("surplus timer %p\n", timer);
> > }
> >
>
> That was also my proposal for the driver I'm sending this series for (see
> [1]) but it has been proposed to implement a mechanism similar to this one
> in this series (see [2] and [3]).
This comes up over and over, and the answer is still no. Either each
block is identical and doesn't matter which one is used for what or
there is some h/w difference that you should describe.
If you want something that would even be considered to put into DT,
then define something BSD or other OS's could use too. (That's not a
suggestion to respin this with generalized names.)
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings
On Tue, 14 Apr 2020 17:44:02 +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> .../display/bridge/snps,arc-dw-hdmi.yaml | 131 ++
> 1 file changed, 131 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.example.dt.yaml:
example-0: 'hdmi@0x1' does not match any of the regexes: '.*-names$',
'.*-supply$', '^#.*-cells$', '^#[a-zA-Z0-9,+\\-._]{0,63}$',
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}$',
'^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+(,[0-9a-fA-F]+)*$', '^__.*__$',
'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.example.dt.yaml:
hdmi@0x1: 'interrupts' does not match any of the regexes: 'pinctrl-[0-9]+'
See https://patchwork.ozlabs.org/patch/1270389
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
--upgrade
Please check and re-submit.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys ARC HDMI TX bindings
On Wed, Apr 15, 2020 at 02:29:29AM +0300, Eugeniy Paltsev wrote:
> This patch adds documentation of device tree bindings for the Synopsys
> HDMI 2.0 TX encoder driver for ARC SoCs.
You're going to need to base this on top of Laurent's conversion of
dw_hdmi.txt to schema.
>
> Acked-by: Sam Ravnborg
> Signed-off-by: Eugeniy Paltsev
> ---
> .../display/bridge/snps,arc-dw-hdmi.yaml | 136 ++
> 1 file changed, 136 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> new file mode 100644
> index ..9b2fdfecd5b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/snps,arc-dw-hdmi.yaml
> @@ -0,0 +1,136 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings please:
(GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/snps,arc-dw-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare HDMI 2.0 TX encoder driver
Bindings are for h/w blocks, not drivers.
> +
> +maintainers:
> + - Eugeniy Paltsev
> +
> +description: |
> + The HDMI transmitter is a Synopsys DesignWare HDMI 2.0 TX controller IP
> + with a companion of Synopsys DesignWare HDMI 2.0 TX PHY IP.
Sounds like 2 blocks?
> +
> + These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> + Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> + with the following device-specific properties.
> +
> +properties:
> + compatible:
> +const: snps,arc-dw-hdmi-hsdk
> +
> + reg:
> +maxItems: 1
> +description: |
> + Memory mapped base address and length of the DWC HDMI TX registers.
Can drop.
> +
> + clocks:
> +items:
> + - description: The bus clock for AHB / APB
> + - description: The internal register configuration clock
> +
> + clock-names:
> +items:
> + - const: iahb
> + - const: isfr
> +
> + interrupts:
> +maxItems: 1
> +description: Reference to the DWC HDMI TX interrupt
Can drop.
> +
> + reg-io-width:
> +allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [1, 4]
> +description: |
> + Width of the registers specified by the reg property. The
> + value is expressed in bytes and must be equal to 1 or 4 if
> specified.
> + The register width defaults to 1 if the property is not present.
default: 1
The description is pretty much a plain text version of the constraints,
so all but the first sentence can be dropped.
> +
> + ports:
> +type: object
> +description: |
> + A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
Can drop. That's all 'ports'.
> +
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
> +type: object
> +description: |
> + Video input endpoints of the controller.
> + Usually it is associated with ARC PGU.
> +
> + port@1:
> +type: object
> +description: |
> + Output endpoints of the controller. HDMI connector.
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - interrupts
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +hdmi@1 {
> +compatible = "snps,arc-dw-hdmi-hsdk";
> +reg = <0x1 0x1>;
> +reg-io-width = <4>;
> +interrupts = <14>;
> +clocks = <&apbclk>, <&hdmi_pix_clk>;
> +clock-names = "iahb", "isfr";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +hdmi_enc_input: endpoint {
> +remote-endpoint = <&pgu_output>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +hdmi_enc_out: endpoint {
> +remote-endpoint = <&hdmi_con>;
> +};
> +};
> +};
> +};
> +
> +hdmi-out {
> +port {
> +hdmi_con: endpoint {
> +remote-endpoint = <&hdmi_enc_out>;
> +};
> +};
> +};
> +
> +pgu {
> +port_o: port {
> +pgu_output: endpoint {
> +remote-endpoint = <&hdmi_enc_input>;
> +};
> +};
> +};
> --
> 2.21.1
>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 3/4] ARC: [plat-hsdk-4xd] initial port for HSDK-4xD board
On Thu, Jun 4, 2020 at 11:39 AM Eugeniy Paltsev
wrote:
>
Need to cc the DT list.
> This initial port adds support of ARC HS4x/HS4xD Development Kit board
> with some basic features such serial port, USB, SD/MMC, SPI flash,
> Ethernet and others.
>
> The HSDK-4xD board has much in common with its predecessor - HSDK board.
> However HSDK-4xD has some differences in comparison with its predecessor:
> * based on quad core ARC HS48/HS47D processor (instead of quad core
>ARC HS38)
> * has ThinkSilicon GPU (instead of Vivante GPU)
> * has ARC PGU and HDMI output
> * has separate SDIO controller for WiFi module
> * has additional timers with clocksource independent from CPU clocksource
>(required for DVFS)
> * has performance counters interrupt
> * other minor stuff
>
> NOTE:
> HSDK-4xD and HSDK may share part of DTS so we can move this common part
> to one .dtsi file (as we have done it in U-boot). However we have quite
> enough out of the tree patches for tweaking HSDK DTS (patches in out
> Linux kernel verification flow, patches for run in simulation, etc...),
> so I'd prefer to keep HSDK DTS untouched. That's why HSDK-4xD DTS is
> created as an separate file.
>
> Cc: Rob Herring
> Signed-off-by: Eugeniy Paltsev
> ---
> arch/arc/boot/dts/hsdk-4xd.dts | 322
Please check this using W=1 and also build 'dtbs_check' (which needs
dt-schema installed).
> arch/arc/configs/hsdk_4xd_defconfig | 98 +
> arch/arc/kernel/devtree.c | 1 +
> arch/arc/plat-hsdk/Kconfig | 3 +-
> arch/arc/plat-hsdk/platform.c | 1 +
> 5 files changed, 424 insertions(+), 1 deletion(-)
> create mode 100644 arch/arc/boot/dts/hsdk-4xd.dts
> create mode 100644 arch/arc/configs/hsdk_4xd_defconfig
>
> diff --git a/arch/arc/boot/dts/hsdk-4xd.dts b/arch/arc/boot/dts/hsdk-4xd.dts
> new file mode 100644
> index ..2b7f76a01e3e
> --- /dev/null
> +++ b/arch/arc/boot/dts/hsdk-4xd.dts
> @@ -0,0 +1,322 @@
> +// SPDX-License-Identifier: GPL-2.0-only
Don't care about non-GPL OS's?
> +/*
> + * Copyright (C) 2020 Synopsys, Inc. (www.synopsys.com)
> + */
> +
> +/*
> + * Device Tree for ARC HS4x/HS4xD Development Kit
> + */
> +/dts-v1/;
> +
> +#include
> +#include
> +
> +/ {
> + model = "snps,hsdk-4xd";
> + compatible = "snps,hsdk-4xd";
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + chosen {
> + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8
> console=ttyS0,115200n8 debug print-fatal-signals=1";
You shouldn't really put debug options here like 'earlycon'. Also, use
'stdout-path' instead for the console.
> + };
> +
> + aliases {
> + ethernet = &gmac;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
Not documented.
> + reg = <0>;
> + clocks = <&core_clk>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
> + reg = <1>;
> + clocks = <&core_clk>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
> + reg = <2>;
> + clocks = <&core_clk>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
> + reg = <3>;
> + clocks = <&core_clk>;
> + };
> + };
> +
> + input_clk: input-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <>;
> + };
> +
> + reg_5v0: regulator-5v0 {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "5v0-supply";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + cpu_intc:
Re: [PATCH v5 4/6] dt-bindings: dw-apb-ictl: support hierarchy irq domain
On Fri, 18 Sep 2020 19:22:00 +0800, Zhen Lei wrote: > Add support to use dw-apb-ictl as primary interrupt controller. > > Signed-off-by: Zhen Lei > --- > .../bindings/interrupt-controller/snps,dw-apb-ictl.txt | 14 > +- > 1 file changed, 13 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v5 5/6] dt-bindings: dw-apb-ictl: convert to json-schema
On Fri, Sep 18, 2020 at 07:22:01PM +0800, Zhen Lei wrote:
> Convert the Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> binding to DT schema format using json-schema.
>
> Signed-off-by: Zhen Lei
> ---
> .../interrupt-controller/snps,dw-apb-ictl.txt | 43 -
> .../interrupt-controller/snps,dw-apb-ictl.yaml | 75
> ++
> 2 files changed, 75 insertions(+), 43 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> deleted file mode 100644
> index 2db59df9408f4c6..000
> ---
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> -
> -Synopsys DesignWare provides interrupt controller IP for APB known as
> -dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> with
> -APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
> -controller in some SoCs, e.g. Hisilicon SD5203.
> -
> -Required properties:
> -- compatible: shall be "snps,dw-apb-ictl"
> -- reg: physical base address of the controller and length of memory mapped
> - region starting with ENABLE_LOW register
> -- interrupt-controller: identifies the node as an interrupt controller
> -- #interrupt-cells: number of cells to encode an interrupt-specifier, shall
> be 1
> -
> -Additional required property when it's used as secondary interrupt
> controller:
> -- interrupts: interrupt reference to primary interrupt controller
> -
> -The interrupt sources map to the corresponding bits in the interrupt
> -registers, i.e.
> -- 0 maps to bit 0 of low interrupts,
> -- 1 maps to bit 1 of low interrupts,
> -- 32 maps to bit 0 of high interrupts,
> -- 33 maps to bit 1 of high interrupts,
> -- (optional) fast interrupts start at 64.
> -
> -Example:
> - /* dw_apb_ictl is used as secondary interrupt controller */
> - aic: interrupt-controller@3000 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x3000 0xc00>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - interrupt-parent = <&gic>;
> - interrupts = ;
> - };
> -
> - /* dw_apb_ictl is used as primary interrupt controller */
> - vic: interrupt-controller@1013 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x1013 0x1000>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - };
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> new file mode 100644
> index 000..70c12979c843bf0
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> @@ -0,0 +1,75 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/interrupt-controller/snps,dw-apb-ictl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> +
> +maintainers:
> + - Marc Zyngier
Usually this would be an owner for this IP block, not the subsystem
maintainer.
> +
> +description:
> + Synopsys DesignWare provides interrupt controller IP for APB known as
> + dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> + with APB bus, e.g. Marvell Armada 1500. It can also be used as primary
> + interrupt controller in some SoCs, e.g. Hisilicon SD5203.
> +
> +allOf:
> + - $ref: /schemas/interrupt-controller.yaml#
You can drop this, it's already applied based on node name.
> +
> +properties:
> + compatible:
> +const: snps,dw-apb-ictl
> +
> + interrupt-controller: true
> +
> + reg:
> +description:
> + Physical base address of the controller and length of memory mapped
> + region starting with ENABLE_LOW register.
Need to define how many reg regions (maxItems: 1).
> +
> + interrupts:
> +description:
> + Interrupt reference to primary interrupt controller.
> +
> + The interrupt sources map to the corresponding bits in the interrupt
> + registers, i.e.
> + - 0 maps to bit 0 of low interrupts,
> + - 1 maps to bit 1 of low interrupts,
> + - 32 maps to bit 0 of high interrupts,
> + - 33 maps to bit 1 of high interrupts,
> + - (optional) fast interrupts start at 64.
> +minItems: 1
> +maxItems: 65
65 connections to the primary interrupt controller? I think this is for
the child interrupts? If so, move to #interrupt
Re: [PATCH v6 5/6] dt-bindings: dw-apb-ictl: convert to json-schema
On Thu, Sep 24, 2020 at 03:17:53PM +0800, Zhen Lei wrote:
> Convert the Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> binding to DT schema format using json-schema.
>
> Signed-off-by: Zhen Lei
> ---
> .../interrupt-controller/snps,dw-apb-ictl.txt | 43 -
> .../interrupt-controller/snps,dw-apb-ictl.yaml | 74
> ++
> 2 files changed, 74 insertions(+), 43 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> deleted file mode 100644
> index 2db59df9408f4c6..000
> ---
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> -
> -Synopsys DesignWare provides interrupt controller IP for APB known as
> -dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> with
> -APB bus, e.g. Marvell Armada 1500. It can also be used as primary interrupt
> -controller in some SoCs, e.g. Hisilicon SD5203.
> -
> -Required properties:
> -- compatible: shall be "snps,dw-apb-ictl"
> -- reg: physical base address of the controller and length of memory mapped
> - region starting with ENABLE_LOW register
> -- interrupt-controller: identifies the node as an interrupt controller
> -- #interrupt-cells: number of cells to encode an interrupt-specifier, shall
> be 1
> -
> -Additional required property when it's used as secondary interrupt
> controller:
> -- interrupts: interrupt reference to primary interrupt controller
> -
> -The interrupt sources map to the corresponding bits in the interrupt
> -registers, i.e.
> -- 0 maps to bit 0 of low interrupts,
> -- 1 maps to bit 1 of low interrupts,
> -- 32 maps to bit 0 of high interrupts,
> -- 33 maps to bit 1 of high interrupts,
> -- (optional) fast interrupts start at 64.
> -
> -Example:
> - /* dw_apb_ictl is used as secondary interrupt controller */
> - aic: interrupt-controller@3000 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x3000 0xc00>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - interrupt-parent = <&gic>;
> - interrupts = ;
> - };
> -
> - /* dw_apb_ictl is used as primary interrupt controller */
> - vic: interrupt-controller@1013 {
> - compatible = "snps,dw-apb-ictl";
> - reg = <0x1013 0x1000>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> - };
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
>
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> new file mode 100644
> index 000..1b05d36b5f7b943
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/interrupt-controller/snps,dw-apb-ictl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
> +
> +maintainers:
> + - Sebastian Hesselbarth
> +
> +description: |
> + Synopsys DesignWare provides interrupt controller IP for APB known as
> + dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs
> + with APB bus, e.g. Marvell Armada 1500. It can also be used as primary
> + interrupt controller in some SoCs, e.g. Hisilicon SD5203.
> +
> + The interrupt sources map to the corresponding bits in the interrupt
> + registers, i.e.
> + - 0 maps to bit 0 of low interrupts,
> + - 1 maps to bit 1 of low interrupts,
> + - 32 maps to bit 0 of high interrupts,
> + - 33 maps to bit 1 of high interrupts,
> + - (optional) fast interrupts start at 64.
> +
> +allOf:
> + - $ref: /schemas/interrupt-controller.yaml#
Don't need this. It's already selected based on node name.
> +
> +properties:
> + compatible:
> +const: snps,dw-apb-ictl
> +
> + interrupt-controller: true
> +
> + reg:
> +description: |
> + Physical base address of the controller and length of memory mapped
> + region starting with ENABLE_LOW register.
> +maxItems: 1
> +
> + interrupts:
> +description: Interrupt reference to primary interrupt controller.
May not be primary. Could be another level in the middle. In any case,
it's outside the scope of this binding, so just drop description.
> +maxItems: 1
> +
> + "#interrupt-cells":
> +description: Number of cells to encode an interrupt-specifier.
Can drop this.
> +const: 1
> +
> +requ
Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property
On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote: > The host controller device might be designed to work for the particular > products or applications. In that case its DT node is supposed to be > equipped with the tpl-support property. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/it'/its" > - Discard '|' from the property description, since we don't need to preserve > the text formatting. > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++ > 1 file changed, 6 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: Traceback (most recent call last): File "/usr/local/bin/dt-extract-example", line 45, in binding = yaml.load(open(args.yamlfile, encoding='utf-8').read()) File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line 343, in load return constructor.get_single_data() File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", line 111, in get_single_data node = self.composer.get_single_node() File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node File "_ruamel_yaml.pyx", line 724, in _ruamel_yaml.CParser._compose_document File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node File "_ruamel_yaml.pyx", line 891, in _ruamel_yaml.CParser._compose_mapping_node File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event ruamel.yaml.scanner.ScannerError: mapping values are not allowed in this context in "", line 27, column 14 make[1]: *** [Documentation/devicetree/bindings/Makefile:20: Documentation/devicetree/bindings/usb/usb-hcd.example.dts] Error 1 make[1]: *** Deleting file 'Documentation/devicetree/bindings/usb/usb-hcd.example.dts' make[1]: *** Waiting for unfinished jobs ./Documentation/devicetree/bindings/usb/usb-hcd.yaml:27:14: [error] syntax error: mapping values are not allowed here (syntax) make[1]: *** [Documentation/devicetree/bindings/Makefile:59: Documentation/devicetree/bindings/processed-schema-examples.json] Error 123 make: *** [Makefile:1366: dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1382001 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 09/20] dt-bindings: usb: Convert DWC USB3 bindings to DT schema
On Wed, 14 Oct 2020 13:13:51 +0300, Serge Semin wrote: > DWC USB3 DT node is supposed to be compliant with the Generic xHCI > Controller schema, but with additional vendor-specific properties, the > controller-specific reference clocks and PHYs. So let's convert the > currently available legacy text-based DWC USB3 bindings to the DT schema > and make sure the DWC USB3 nodes are also validated against the > usb-xhci.yaml schema. > > Note we have to discard the nodename restriction of being prefixed with > "dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes > are supposed to be named as "^usb(@.*)". > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' from the descriptions, since we don't need to preserve > the text formatting in any of them. > - Drop quotes from around the string constants. > - Fix the "clock-names" prop description to be referring the enumerated > clock-names instead of the ones from the Databook. > --- > .../devicetree/bindings/usb/dwc3.txt | 125 > .../devicetree/bindings/usb/snps,dwc3.yaml| 295 ++ > 2 files changed, 295 insertions(+), 125 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt > create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml > My bot found errors running 'make dt_binding_check' on your patch: ./Documentation/devicetree/bindings/usb/snps,dwc3.yaml:44:4: [warning] wrong indentation: expected 4 but found 3 (indentation) /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/qcom,dwc3.example.dt.yaml: dwc3@a60: $nodename:0: 'dwc3@a60' does not match '^usb(@.*)?' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.example.dt.yaml: usb@ff50: snps,quirk-frame-length-adjustment: True is not of type 'array' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/snps,dwc3.yaml See https://patchwork.ozlabs.org/patch/1382003 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 20/20] arch: dts: Fix DWC USB3 DT nodes name
On Wed, Oct 14, 2020 at 9:37 AM Serge Semin
wrote:
>
> On Wed, Oct 14, 2020 at 05:09:37PM +0300, Felipe Balbi wrote:
> >
> > Hi Serge,
> >
> > Serge Semin writes:
> > > In accordance with the DWC USB3 bindings the corresponding node name is
> > > suppose to comply with Generic USB HCD DT schema, which requires the USB
> >
>
> > DWC3 is not a simple HDC, though.
>
> Yeah, strictly speaking it is equipped with a lot of vendor-specific stuff,
> which are tuned by the DWC USB3 driver in the kernel. But after that the
> controller is registered as xhci-hcd device so it's serviced by the xHCI
> driver,
> which then registers the HCD device so the corresponding DT node is supposed
> to be compatible with the next bindings: usb/usb-hcd.yaml, usb/usb-xhci.yaml
> and usb/snps,dwc3,yaml. I've created the later one so to validate the denoted
> compatibility.
>
> >
> > > nodes to have the name acceptable by the regexp: "^usb(@.*)?" . But a lot
> > > of the DWC USB3-compatible nodes defined in the ARM/ARM64 DTS files have
> > > name as "^dwc3@.*" or "^usb[1-3]@.*" or even "^dwusb@.*", which will cause
> > > the dtbs_check procedure failure. Let's fix the nodes naming to be
> > > compatible with the DWC USB3 DT schema to make dtbs_check happy.
> > >
> > > Note we don't change the DWC USB3-compatible nodes names of
> > > arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} since the
> > > in-source comment says that the nodes name need to be preserved as
> > > "^dwusb@.*" for some backward compatibility.
> >
>
> > interesting, compatibility with what? Some debugfs files, perhaps? :-)
>
> Don't really know.) In my experience the worst type of such compatibility is
> connected with some bootloader magic, which may add/remove/modify properties
> to nodes with pre-defined names.
I seriously doubt anyone is using the APM machines with DT (even ACPI
is somewhat doubtful). I say change them. Or remove the dts files and
see what happens. Either way it can always be reverted.
Rob
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property
On Wed, Oct 14, 2020 at 08:27:10PM +0300, Serge Semin wrote: > On Wed, Oct 14, 2020 at 08:27:56AM -0500, Rob Herring wrote: > > On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote: > > > The host controller device might be designed to work for the particular > > > products or applications. In that case its DT node is supposed to be > > > equipped with the tpl-support property. > > > > > > Signed-off-by: Serge Semin > > > > > > --- > > > > > > Changelog v2: > > > - Grammar fix: "s/it'/its" > > > - Discard '|' from the property description, since we don't need to > > > preserve > > > the text formatting. > > > --- > > > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > Traceback (most recent call last): > > File "/usr/local/bin/dt-extract-example", line 45, in > > binding = yaml.load(open(args.yamlfile, encoding='utf-8').read()) > > File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/main.py", line > > 343, in load > > return constructor.get_single_data() > > File "/usr/local/lib/python3.8/dist-packages/ruamel/yaml/constructor.py", > > line 111, in get_single_data > > node = self.composer.get_single_node() > > File "_ruamel_yaml.pyx", line 706, in _ruamel_yaml.CParser.get_single_node > > File "_ruamel_yaml.pyx", line 724, in > > _ruamel_yaml.CParser._compose_document > > File "_ruamel_yaml.pyx", line 775, in _ruamel_yaml.CParser._compose_node > > File "_ruamel_yaml.pyx", line 891, in > > _ruamel_yaml.CParser._compose_mapping_node > > File "_ruamel_yaml.pyx", line 904, in > > _ruamel_yaml.CParser._parse_next_event > > ruamel.yaml.scanner.ScannerError: mapping values are not allowed in this > > context > > in "", line 27, column 14 > > make[1]: *** [Documentation/devicetree/bindings/Makefile:20: > > Documentation/devicetree/bindings/usb/usb-hcd.example.dts] Error 1 > > make[1]: *** Deleting file > > 'Documentation/devicetree/bindings/usb/usb-hcd.example.dts' > > make[1]: *** Waiting for unfinished jobs > > ./Documentation/devicetree/bindings/usb/usb-hcd.yaml:27:14: [error] syntax > > error: mapping values are not allowed here (syntax) > > make[1]: *** [Documentation/devicetree/bindings/Makefile:59: > > Documentation/devicetree/bindings/processed-schema-examples.json] Error 123 > > make: *** [Makefile:1366: dt_binding_check] Error 2 > > > > > > See https://patchwork.ozlabs.org/patch/1382001 > > > > If you already ran 'make dt_binding_check' and didn't see the above > > error(s), then make sure dt-schema is up to date: > > > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > > --upgrade > > > > Please check and re-submit. > > Hm, that's weird. Of course I did the dt_binding_check before submission, but > even after the dt-schema repo update I failed to see the error: > > $ make -j8 ARCH=mips CROSS_COMPILE=mipsel-baikal-linux- dt_binding_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/usb/usb-hcd.yaml > CHKDT Documentation/devicetree/bindings/usb/usb-hcd.yaml > SCHEMA Documentation/devicetree/bindings/processed-schema-examples.yaml > DTC Documentation/devicetree/bindings/usb/usb-hcd.example.dt.yaml > CHECK Documentation/devicetree/bindings/usb/usb-hcd.example.dt.yaml > > Rob, any idea why has the bot got mad at me? Humm, I'm not sure. We'll see if it happens again when you send v2. Note that yamllint is also run now and that's the line with '[error]'. So neither yamllint nor ruamel are happy (could be the same parser code ultimately). Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 01/20] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
On Wed, 14 Oct 2020 13:13:43 +0300, Serge Semin wrote: > The generic USB HCD properties have been described in the legacy bindings > text file: Documentation/devicetree/bindings/usb/generic.txt . Let's > convert it' content into the USB HCD DT schema properties so all USB DT > nodes would be validated to have them properly utilized. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' in all the new properties, since we don't need to preserve > the text formatting. > - Convert abbreviated form of the "maximum-speed" enum restriction into > the multi-lined version of the list. > - Drop quotes from around the string constants. > --- > .../devicetree/bindings/usb/generic.txt | 57 > .../devicetree/bindings/usb/usb-hcd.yaml | 88 +++ > 2 files changed, 88 insertions(+), 57 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/20] dt-bindings: usb: usb-hcd: Add "otg-rev" property restriction
On Wed, 14 Oct 2020 13:13:44 +0300, Serge Semin wrote: > There are only four OTG revisions are currently supported by the kernel: > 0x0100, 0x0120, 0x0130, 0x0200. Any another value is considered as > invalid. > > Signed-off-by: Serge Semin > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/20] dt-bindings: usb: usb-hcd: Add "ulpi/serial/hsic" PHY types
On Wed, 14 Oct 2020 13:13:45 +0300, Serge Semin wrote: > Aside from the UTMI+ there are also ULPI, Serial and HSIC PHY types > that can be specified in the phy_type HCD property. Add them to the > enumeration of the acceptable values. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/PHY types can be/PHY types that can be" > - Drop quotes from around the string constants. > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 05/20] dt-bindings: usb: usb-hcd: Add generic "usb-phy" property
On Wed, 14 Oct 2020 13:13:47 +0300, Serge Semin wrote: > Even though the Generic PHY framework is the more preferable way of > setting the USB PHY up, there are still many dts-files and DT bindings > which rely on having the legacy "usb-phy" specified to attach particular > USB PHYs to USB cores. Let's have the "usb-phy" property described in > the generic USB HCD binding file so it would be validated against the > nodes in which it's specified. Mark the property as deprecated to > discourage the developers from using it. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Discard '|' from the property description, since we don't need to preserve > the text formatting. > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 7 +++ > 1 file changed, 7 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/20] dt-bindings: usb: usb-hcd: Add "tpl-support" property
On Wed, 14 Oct 2020 13:13:46 +0300, Serge Semin wrote: > The host controller device might be designed to work for the particular > products or applications. In that case its DT node is supposed to be > equipped with the tpl-support property. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/it'/its" > - Discard '|' from the property description, since we don't need to preserve > the text formatting. > --- > Documentation/devicetree/bindings/usb/usb-hcd.yaml | 6 ++ > 1 file changed, 6 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 08/20] dt-bindings: usb: renesas-xhci: Refer to the usb-xhci.yaml file
On Wed, 14 Oct 2020 13:13:50 +0300, Serge Semin wrote: > With minor peculiarities (like uploading some vendor-specific firmware) > these are just Generic xHCI controllers fully compatible with its > properties. Make sure the Renesas USB xHCI DT nodes are also validated > against the Generic xHCI DT schema. > > Signed-off-by: Serge Semin > --- > Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/20] dt-bindings: usb: Convert xHCI bindings to DT schema
On Wed, 14 Oct 2020 13:13:48 +0300, Serge Semin wrote: > Currently the DT bindings of Generic xHCI Controllers are described by means > of the legacy text file. Since such format is deprecated in favor of the > DT schema, let's convert the Generic xHCI Controllers bindings file to the > corresponding yaml files. There will be two of them: a DT schema for the > xHCI controllers on a generic platform and a DT schema validating a generic > xHCI controllers properties. The later will be used to validate the xHCI > controllers, which aside from some vendor-specific features support the > basic xHCI functionality. > > An xHCI-compatible DT node shall support the standard USB HCD properties > and custom ones like: usb2-lpm-disable, usb3-lpm-capable, > quirk-broken-port-ped and imod-interval-ns. In addition if a generic xHCI > controller is being validated against the DT schema it is also supposed to > be equipped with mandatory compatible string, single registers range, > single interrupts source, and is supposed to optionally contain up to two > reference clocks for the controller core and CSRs. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Add explicit "additionalProperties: true" to the usb-xhci.yaml schema, > since additionalProperties/unevaluatedProperties are going to be mandary > for each binding. > --- > .../devicetree/bindings/usb/generic-xhci.yaml | 63 +++ > .../devicetree/bindings/usb/usb-xhci.txt | 41 > .../devicetree/bindings/usb/usb-xhci.yaml | 42 + > 3 files changed, 105 insertions(+), 41 deletions(-) > create mode 100644 Documentation/devicetree/bindings/usb/generic-xhci.yaml > delete mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt > create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.yaml > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 07/20] dt-bindings: usb: xhci: Add Broadcom STB v2 compatible device
On Wed, 14 Oct 2020 13:13:49 +0300, Serge Semin wrote: > For some reason the "brcm,xhci-brcm-v2" compatible string has been missing > in the original bindings file. Add it to the Generic xHCI Controllers DT > schema since the controller driver expects it to be supported. > > Signed-off-by: Serge Semin > --- > Documentation/devicetree/bindings/usb/generic-xhci.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 10/20] dt-bindings: usb: dwc3: Add interrupt-names property support
On Wed, 14 Oct 2020 13:13:52 +0300, Serge Semin wrote: > The controller driver supports two types of DWC USB3 devices: with a > common interrupt lane and with individual interrupts for each mode. Add > support for both these cases to the DWC USB3 DT schema. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/both of these cases support/support for both these cases" > - Drop quotes from around the string constants. > --- > Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 11 +++ > 1 file changed, 11 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 11/20] dt-bindings: usb: dwc3: Add synopsys,dwc3 compatible string
On Thu, Oct 15, 2020 at 12:35:54AM +0300, Serge Semin wrote: > On Wed, Oct 14, 2020 at 10:18:18PM +0200, Krzysztof Kozlowski wrote: > > On Wed, Oct 14, 2020 at 01:13:53PM +0300, Serge Semin wrote: > > > The DWC USB3 driver and some DTS files like Exynos 5250, Keystone k2e, etc > > > expects the DWC USB3 DT node to have the compatible string with the > > > "synopsys" vendor prefix. Let's add the corresponding compatible string to > > > the controller DT schema, but mark it as deprecated seeing the Synopsys, > > > Inc. is presented with just "snps" vendor prefix. > > > > > Instead of adding deprecated schema just correct the DTSes to use snps. > > The "synopsys" is not even in vendor prefixes. > > Yeah, it's not, but the driver and some dts'es use it this way. I am not sure > that the solution suggested by you is much better than mine. So let's hear the > Rob'es opinion out in this matter. @Rob, what do you think? I think we should fix the dts files given there's only 5. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 12/20] dt-bindings: usb: dwc3: Add Tx De-emphasis restrictions
On Wed, 14 Oct 2020 13:13:54 +0300, Serge Semin wrote: > In accordance with the driver comments the PIPE3 de-emphasis can be tuned > to be either -6dB, -2.5dB or disabled. Let's add the de-emphasis > property restriction so the DT schema would make sure the controller DT > node is equipped with correct value. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/tunned/tuned" > - Grammar fix: remove redundant "or" conjunction. > --- > Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 4 ++++ > 1 file changed, 4 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 13/20] dt-bindings: usb: dwc3: Add Frame Length Adj restrictions
On Wed, 14 Oct 2020 13:13:55 +0300, Serge Semin wrote: > In accordance with the IP core databook the > snps,quirk-frame-length-adjustment property can be set within [0, 0x3F]. > Let's make sure the DT schema applies a correct restriction on the > property. > > Signed-off-by: Serge Semin > --- > Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 14/20] dt-bindings: usb: meson-g12a-usb: Fix FL-adj property value
On Wed, 14 Oct 2020 13:13:56 +0300, Serge Semin wrote: > An empty snps,quirk-frame-length-adjustment won't cause any change > performed by the driver. Moreover the DT schema validation will fail, > since it expects the property being assigned with some value. So set > fix the example by setting a valid FL-adj value in accordance with > Neil Armstrong comment. > > Link: > https://lore.kernel.org/linux-usb/20201010224121.12672-16-sergey.se...@baikalelectronics.ru/ > Signed-off-by: Serge Semin > Acked-by: Neil Armstrong > > --- > > Note the same problem is in the DT source file > arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi . > --- > .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml| 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 17/20] dt-bindings: usb: qcom, dwc3: Validate DWC3 sub-node
On Wed, 14 Oct 2020 13:13:59 +0300, Serge Semin wrote:
> Qualcomm msm8996/sc7180/sdm845 DWC3 compatible DT nodes are supposed to
> have a DWC USB3 compatible sub-node to describe a fully functioning USB
> interface. Let's use the available DWC USB3 DT schema to validate the
> Qualcomm DWC3 sub-nodes.
>
> Note since the generic DWC USB3 DT node is supposed to be named as generic
> USB HCD ("^usb(@.*)?") one we have to accordingly fix the sub-nodes name
> regexp and fix the DT node example.
>
> Signed-off-by: Serge Semin
>
> ---
>
> Changelog v2:
> - Discard the "^dwc3@[0-9a-f]+$" nodes from being acceptable as sub-nodes.
> ---
> Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
Reviewed-by: Rob Herring
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 16/20] dt-bindings: usb: keystone-dwc3: Validate DWC3 sub-node
On Wed, 14 Oct 2020 13:13:58 +0300, Serge Semin wrote: > TI Keystone DWC3 compatible DT node is supposed to have a DWC USB3 > compatible sub-node to describe a fully functioning USB interface. > Since DWC USB3 has now got a DT schema describing its DT node, let's make > sure the TI Keystone DWC3 sub-node passes validation against it. > > Signed-off-by: Serge Semin > > --- > > Changelog v2: > - Grammar fix: "s/it'/its" > --- > Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 15/20] dt-bindings: usb: meson-g12a-usb: Validate DWC2/DWC3 sub-nodes
On Wed, 14 Oct 2020 13:13:57 +0300, Serge Semin wrote: > Amlogic G12A USB DT sub-nodes are supposed to be compatible with the > generic DWC USB2 and USB3 devices. Since now we've got DT schemas for > both of the later IP cores let's make sure that the Amlogic G12A USB > DT nodes are fully evaluated including the DWC sub-nodes. > > Signed-off-by: Serge Semin > Reviewed-by: Neil Armstrong > > --- > > Changelog v2: > - Use "oneOf: [dwc2.yaml#, snps,dwc3.yaml#]" instead of the bulky "if: > properties: compatibe: ..." statement. > --- > .../devicetree/bindings/usb/amlogic,meson-g12a-usb-ctrl.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
