Re: [RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock

[Heiko Stübner]

Hi Xing,

Am Dienstag, 29. Dezember 2015, 10:34:09 schrieb Xing Zheng:
> On 2015年12月29日 09:59, Yakir Yang wrote:
> > On 12/28/2015 08:41 PM, Heiko Stübner wrote:
> >> Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:
> >>> Due to referred old version TRM, there is incorrect emac clock node,
> >>> we should fix it. The SEL_21_9 is the parent of SEL_21_4.
> >>> 
> >>> In the emac driver, we need to refer HCLK_MAC, and because There are
> >>> only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
> >>> GPLL, and it is unable to provide the accurate rate for mac_ref which
> >>> need to 50MHz probability, we should let it under the APLL and are
> >>> able to set the freq which integer multiples of 50MHz, so we add these
> >>> emac node for reference.
> >> 
> >> I don't really follow here. While I do understand that the emac needs
> >> 50MHz, I
> >> don't think using the APLL as source is helpful.
> >> 
> >> The APLL is the main clocksource for the cpu-cores, including frequency
> >> scaling, and while it currently only lists 816MHz as sole frequency,
> >> you're
> >> pretty much guaranteed to not get your correct multiple of 50MHz from
> >> there
> >> either. And limiting the cpu to just do 600MHz to get the mac working
> >> sounds
> >> pretty bad ;-) .
> >> 
> >> 
> >> In the rk3036 cru-node the gpll gets set to 594MHz. Is there a
> >> special reason
> >> why it needs to be 594MHz and cannot be a round 600MHz? Because that
> >> would
> >> also provide your 50MHz-multiple nicely.
> > 
> > Yes, this magic 594MHz would help to support the standard HDMI
> > resolutions, here are the math:
> > 
> > 1920x1080-60Hz DCLK = 148.5MHz = 594MHz / 4
> > 1280x720-60Hz DCLK = 74.25MHz = 594MHz / 8
> > 720x480-60Hz DCLK = 27MHz = 594MHz / 22
> > 
> > Thanks,
> > - Yakir
> 
> Thanks Yakir.
> 
> Hi Heiko,
>  From the above, do you have better idea for the RK3036's emac without
> ext-oscillator?

During the last days I did play a bit with the clock framework. As I don't 
have a Kylin (or any rk3036) board, I did build a test-case with pclk_cpu on 
the rk3188 (which can be affected by the armclk if not reparented to the 
gpll), which got sucessfully adapted to get back to (or near) the originally 
requested frequency.

So ideally you could roll back your mux/div split here and try the attached 
diff. In theory it should help :-) .
As can be seen by the FIXMEs, not fully finished, but I'd like to determine if 
it fixes the issue at least.


Heiko
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 7bbb0fd..83a7234 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1423,6 +1423,9 @@ static struct clk_core *clk_propagate_rate_change(struct clk_core *core,
 	return fail_clk;
 }
 
+static int clk_core_set_rate_nolock(struct clk_core *core,
+unsigned long req_rate);
+
 /*
  * walk down a subtree and set the new rates notifying the rate
  * change on the way
@@ -1438,6 +1441,7 @@ static void clk_change_rate(struct clk_core *core)
 
 	old_rate = core->rate;
 
+printk("%s: %s requested %lu, new %lu\n", __func__, core->name, core->req_rate, core->new_rate);
 	if (core->new_parent)
 		best_parent_rate = core->new_parent->rate;
 	else if (core->parent)
@@ -1507,6 +1511,12 @@ static void clk_change_rate(struct clk_core *core)
 	/* handle the new child who might not be in core->children yet */
 	if (core->new_child)
 		clk_change_rate(core->new_child);
+
+	/* FIXME: add flag to limit to specific clocks? */
+	if (core->req_rate && core->new_rate != old_rate) {
+		printk("\t\ttrying to adapt %s\n", core->name);
+		clk_core_set_rate_nolock(core, core->req_rate);
+	}
 }
 
 static int clk_core_set_rate_nolock(struct clk_core *core,
@@ -1520,8 +1530,10 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
 		return 0;
 
 	/* bail early if nothing to do */
-	if (rate == clk_core_get_rate_nolock(core))
+	if (rate == clk_core_get_rate_nolock(core)) {
+		core->req_rate = req_rate;
 		return 0;
+	}
 
 	if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
 		return -EBUSY;
@@ -1612,9 +1624,14 @@ int clk_set_rate_range(struct clk *clk, unsigned long min, unsigned long max)
 	clk_prepare_lock();
 
 	if (min != clk->min_rate || max != clk->max_rate) {
+		unsigned long rate = clk->core->req_rate;
+
+		if (!rate)
+			rate = clk->core->rate;
+
 		clk->min_rate = min;
 		clk->max_rate = max;
-		ret = clk_core_set_rate_nolock(clk->core, clk->core->req_rate);
+		ret 

Re: [PATCH] ARM: dts: rockchip: Adding LEDs handling via leds-gpio for the Radxa Rock2 Square

[Heiko Stübner]

Am Mittwoch, 30. Dezember 2015, 17:07:54 schrieb Romain Perier:
> Hi all,
> 
> I agree with Sjoerd, that's more useful to keep these LEDs in sync
> with the default vendor behaviour than put their default state to off
> and ask the user to manipulate them explicitly... in the worst case,
> he can still change the default state from sysfs...
> 
> 2015-12-30 16:53 GMT+01:00 Heiko Stübner :
> >> > even a oneliner is generally preferred, compared to no commit message
> >> > at all
> >> > ;-)
> 
> Well, lack of inspiration :P
> No, just kidding, I agree.
> 
> >> > > Signed-off-by: Romain Perier 
> >> > > ---
> >> > > 
> >> > >  arch/arm/boot/dts/rk3288-rock2-square.dts | 17 +
> >> > >  1 file changed, 17 insertions(+)
> >> > > 
> >> > > diff --git a/arch/arm/boot/dts/rk3288-rock2-square.dts
> >> > > b/arch/arm/boot/dts/rk3288-rock2-square.dts index c5453a0..a33020f
> >> > > 100644
> >> > > --- a/arch/arm/boot/dts/rk3288-rock2-square.dts
> >> > > +++ b/arch/arm/boot/dts/rk3288-rock2-square.dts
> >> > > @@ -56,6 +56,23 @@
> >> > > 
> >> > >   pinctrl-0 = <&ir_int>;
> >> > >   
> >> > >   };
> >> > > 
> >> > > + gpio-leds {
> >> > > + compatible = "gpio-leds";
> >> > > +
> >> > > + heartbeat {
> >> > > + gpios = <&gpio7 15 GPIO_ACTIVE_LOW>;
> >> > > + label = "rock2:green:heartbeat";
> >> > > + linux,default-trigger = "heartbeat";
> >> > > + };
> >> > > +
> >> > > + mmc {
> >> > > + gpios = <&gpio0 11 GPIO_ACTIVE_LOW>;
> >> > > + label = "rock2:blue:mmc";
> >> > > + linux,default-trigger = "mmc0";
> >> > > + };
> >> > 
> >> > the rock2 core schematics seem to not list these leds at all
> >> > (especially when
> >> > looking at the gpio-side). But looking at the schematics my guess
> >> > would be
> >> > led_state1 and led_state2, so the naming should reflect that
> >> > (rock2:green:state1 ...).
> 
> I used the schematic and the vendor devicetree to retrieve these
> informations.
> > Anybody opposed to me adding the following commit message?
> > 
> > 
> > Describe the two user-controllable LEDs on Rock2-square boards.
> > The default-triggers mimic the behaviour of the vendor-kernel to
> > keep functionalities in sync.
> > 
> 
> +1
> Please do.
> 
> Do you want a v2 patch ? (the label of these leds is wrong)

yep, bringing everything together makes sense :-)


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: rockchip: Adding LEDs handling via leds-gpio for the Radxa Rock2 Square

[Heiko Stübner]

Am Mittwoch, 30. Dezember 2015, 16:45:43 schrieb Sjoerd Simons:
> On Wed, 2015-12-30 at 16:20 +0100, Heiko Stübner wrote:
> > Am Mittwoch, 30. Dezember 2015, 12:16:59 schrieb Romain Perier:
> > 
> > even a oneliner is generally preferred, compared to no commit message
> > at all 
> > ;-)
> > 
> > > Signed-off-by: Romain Perier 
> > > ---
> > >  arch/arm/boot/dts/rk3288-rock2-square.dts | 17 +
> > >  1 file changed, 17 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/rk3288-rock2-square.dts
> > > b/arch/arm/boot/dts/rk3288-rock2-square.dts index c5453a0..a33020f
> > > 100644
> > > --- a/arch/arm/boot/dts/rk3288-rock2-square.dts
> > > +++ b/arch/arm/boot/dts/rk3288-rock2-square.dts
> > > @@ -56,6 +56,23 @@
> > >   pinctrl-0 = <&ir_int>;
> > >   };
> > > 
> > > + gpio-leds {
> > > + compatible = "gpio-leds";
> > > +
> > > + heartbeat {
> > > + gpios = <&gpio7 15 GPIO_ACTIVE_LOW>;
> > > + label = "rock2:green:heartbeat";
> > > + linux,default-trigger = "heartbeat";
> > > + };
> > > +
> > > + mmc {
> > > + gpios = <&gpio0 11 GPIO_ACTIVE_LOW>;
> > > + label = "rock2:blue:mmc";
> > > + linux,default-trigger = "mmc0";
> > > + };
> > 
> > the rock2 core schematics seem to not list these leds at all
> > (especially when 
> > looking at the gpio-side). But looking at the schematics my guess
> > would be 
> > led_state1 and led_state2, so the naming should reflect that 
> > (rock2:green:state1 ...).
> > 
> > Also I'd like to refrain from encoding user-specific configurations
> > in the 
> > devicetree - aka please do a default trigger of "off" for those
> > generic leds.
> 
> Seems a grey area. The vendor kernel configures these LEDs with the
> same default triggers as Romains patch does, so one could argue these
> are the intended usages for those LEDs (as such it's hardware
> description not use-specific configuration?). 
> 
> In any case having sensible default triggers (e.g. having the default
> mainline behaviour act the same as the vendor behaviour) seems quite a
> lot more useful then keeping these LEDs off and forcing usespace to set
> them up.

I only looked at the schematics, so missed that. While personally I'd still 
like having the "christmas-tree" off by default, Sjoerd's argument for the 
trigger-choice sounds sensible.
Hint for next time: Describing that makes a good commit message

Anybody opposed to me adding the following commit message?


Describe the two user-controllable LEDs on Rock2-square boards.
The default-triggers mimic the behaviour of the vendor-kernel to
keep functionalities in sync.



Heiko

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: rockchip: Adding LEDs handling via leds-gpio for the Radxa Rock2 Square

[Heiko Stübner]

Hi Romain,

Am Mittwoch, 30. Dezember 2015, 12:16:59 schrieb Romain Perier:

even a oneliner is generally preferred, compared to no commit message at all 
;-)

> Signed-off-by: Romain Perier 
> ---
>  arch/arm/boot/dts/rk3288-rock2-square.dts | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-rock2-square.dts
> b/arch/arm/boot/dts/rk3288-rock2-square.dts index c5453a0..a33020f 100644
> --- a/arch/arm/boot/dts/rk3288-rock2-square.dts
> +++ b/arch/arm/boot/dts/rk3288-rock2-square.dts
> @@ -56,6 +56,23 @@
>   pinctrl-0 = <&ir_int>;
>   };
> 
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + heartbeat {
> + gpios = <&gpio7 15 GPIO_ACTIVE_LOW>;
> + label = "rock2:green:heartbeat";
> + linux,default-trigger = "heartbeat";
> + };
> +
> + mmc {
> + gpios = <&gpio0 11 GPIO_ACTIVE_LOW>;
> + label = "rock2:blue:mmc";
> + linux,default-trigger = "mmc0";
> + };

the rock2 core schematics seem to not list these leds at all (especially when 
looking at the gpio-side). But looking at the schematics my guess would be 
led_state1 and led_state2, so the naming should reflect that 
(rock2:green:state1 ...).

Also I'd like to refrain from encoding user-specific configurations in the 
devicetree - aka please do a default trigger of "off" for those generic leds.


Thanks
Heiko

> + };
> +
> +
>   sound {
>   compatible = "simple-audio-card";
>   simple-audio-card,name = "SPDIF";

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[Heiko Stübner]

Hi Dave,

Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
> You have to submit this series properly, the same problem happend twice
> now.
> 
> When you submit a series you should:
> 
> 1) Make it clear which tree you expect these changes to be applied
>to.  Here it is completely ambiguous, do you want it to go into
>my networking tree or some other subsystem tree?
> 
> 2) You MUST keep all parties informed about all patches for a series
>like this.  That means you cannot drop netdev from patch #4 as
>you did both times.  Doing this aggravates the situation for
>#1 even more, because if a patch is not CC:'d to netdev it does
>not enter patchwork.  And if it doesn't go into patchwork, I'm
>not looking at it.

I guess that is some unfortunate result of git send-email combined with 
get_maintainer.pl . In general I also prefer to see the whole series, but have 
gotten such partial series from other maintainers as well in the past, so it 
seems to be depending on preferences somewhat.

For the series at hand, the 4th patch is the devicetree addition, which the 
expected way is me picking it up, after you are comfortable with the code-
related changes.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 0/6] misc: add reboot mode driver

[Heiko Stübner]

Am Montag, 28. Dezember 2015, 16:28:55 schrieb Arnd Bergmann:
> On Wednesday 23 December 2015 17:31:45 Andy Yan wrote:
> > +{ .compatible = "rockchip,reboot-mode-nvram",
> > +.data = (void *)&reboot-mode-nvram },
> > +{},
> > +};
> 
> nvram is a complex topic by itself, because there are so many ways to do it.
> I think what you are referring to here is a battery-backed memory that uses
> one or more bytes at a fixed offset to store a particular piece of
> information, as the drivers/char/nvram.c driver does. Maybe we should put
> the reboot mode into that driver then?
> 
> There are other nvram drivers at various places in the kernel, and each may
> be slightly different, or completely different, like the EFIVARs driver on
> UEFI firmware or the key/value store on Open Firmware, these probably need
> their own methods and not share the generic driver.

actually we now have drivers/nvmem/* that does that byte-wise addressing for 
eeproms, efuses, etc in a generic way.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock

[Heiko Stübner]

Hi,

Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:
> Due to referred old version TRM, there is incorrect emac clock node,
> we should fix it. The SEL_21_9 is the parent of SEL_21_4.
> 
> In the emac driver, we need to refer HCLK_MAC, and  because There are
> only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
> GPLL, and it is unable to provide the accurate rate for mac_ref which
> need to 50MHz probability, we should let it under the APLL and are
> able to set the freq which integer multiples of 50MHz, so we add these
> emac node for reference.

I don't really follow here. While I do understand that the emac needs 50MHz, I 
don't think using the APLL as source is helpful.

The APLL is the main clocksource for the cpu-cores, including frequency 
scaling, and while it currently only lists 816MHz as sole frequency, you're 
pretty much guaranteed to not get your correct multiple of 50MHz from there 
either. And limiting the cpu to just do 600MHz to get the mac working sounds 
pretty bad ;-) .


In the rk3036 cru-node the gpll gets set to 594MHz. Is there a special reason 
why it needs to be 594MHz and cannot be a round 600MHz? Because that would 
also provide your 50MHz-multiple nicely.

> Signed-off-by: Xing Zheng 
> ---
> 
>  drivers/clk/rockchip/clk-rk3036.c  |   11 ++-
>  include/dt-bindings/clock/rk3036-cru.h |2 ++
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3036.c
> b/drivers/clk/rockchip/clk-rk3036.c index 7420cbe..7863c4d 100644
> --- a/drivers/clk/rockchip/clk-rk3036.c
> +++ b/drivers/clk/rockchip/clk-rk3036.c
> @@ -328,13 +328,14 @@ static struct rockchip_clk_branch
> rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2, MFLAGS,
> 2, 5, DFLAGS,
>   RK2928_CLKGATE_CON(10), 5, GFLAGS),
> 
> - COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
> - RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 4, 5, DFLAGS),
> + MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
> + RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
> + DIV(0, "mac_pll_src", "mac_pll_pre", 0,
> + RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
>   MUX(SCLK_MACREF, "mac_clk_ref", mux_mac_p, CLK_SET_RATE_PARENT,
>   RK2928_CLKSEL_CON(21), 3, 1, MFLAGS),
> -
>   COMPOSITE_NOMUX(SCLK_MAC, "mac_clk", "mac_clk_ref", 0,
> - RK2928_CLKSEL_CON(21), 9, 5, DFLAGS,
> + RK2928_CLKSEL_CON(21), 4, 5, DFLAGS,
>   RK2928_CLKGATE_CON(2), 6, GFLAGS),
> 
>   MUX(SCLK_HDMI, "dclk_hdmi", mux_dclk_p, 0,
> @@ -389,7 +390,7 @@ static struct rockchip_clk_branch rk3036_clk_branches[]
> __initdata = { GATE(HCLK_OTG1, "hclk_otg1", "hclk_peri", CLK_IGNORE_UNUSED,
> RK2928_CLKGATE_CON(7), 3, GFLAGS), GATE(HCLK_I2S, "hclk_i2s", "hclk_peri",
> 0, RK2928_CLKGATE_CON(7), 2, GFLAGS), GATE(0, "hclk_sfc", "hclk_peri",
> CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 14, GFLAGS), -  GATE(0,
> "hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 15,
> GFLAGS), +GATE(HCLK_MAC, "hclk_mac", "hclk_peri", 0,
> RK2928_CLKGATE_CON(3), 5, GFLAGS),
> 
>   /* pclk_peri gates */
>   GATE(0, "pclk_peri_matrix", "pclk_peri", CLK_IGNORE_UNUSED,
> RK2928_CLKGATE_CON(4), 1, GFLAGS), diff --git
> a/include/dt-bindings/clock/rk3036-cru.h
> b/include/dt-bindings/clock/rk3036-cru.h index ebc7a7b..de44109 100644
> --- a/include/dt-bindings/clock/rk3036-cru.h
> +++ b/include/dt-bindings/clock/rk3036-cru.h
> @@ -54,6 +54,7 @@
>  #define SCLK_PVTM_VIDEO  125
>  #define SCLK_MAC 151
>  #define SCLK_MACREF  152
> +#define SCLK_MACPLL  153
>  #define SCLK_SFC 160
> 
>  /* aclk gates */
> @@ -92,6 +93,7 @@

please separate the hclk addition into two separate patches:
patch1: add the clock-id to the dt-binding header
patch2: use the clock in the clock-driver

>  #define HCLK_SDMMC   456
>  #define HCLK_SDIO457
>  #define HCLK_EMMC459
> +#define HCLK_MAC 460
>  #define HCLK_I2S 462
>  #define HCLK_LCDC465
>  #define HCLK_ROM 467


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 5/6] ARM: dts: rockchip: add reboot-mode node

[Heiko Stübner]

Hi Andy,

Am Dienstag, 22. Dezember 2015, 17:16:52 schrieb Andy Yan:
> Add reboot mode driver DT node for rk3xxx,rk3288 platform

in general, I like that concept a lot :-) . Below some small issues.


> Signed-off-by: Andy Yan 
> 
> ---
> 
> Changes in v1:
> - correct the maskrom magic number
> - use macro defined in rockchip_boot-mode.h for reboot-mode DT node
> 
>  arch/arm/boot/dts/rk3288.dtsi | 26 ++
>  arch/arm/boot/dts/rk3xxx.dtsi | 26 ++
>  2 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 04ea209..c6ea207 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -45,6 +45,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "skeleton.dtsi"
> 
>  / {
> @@ -170,6 +171,31 @@
>   };
>   };
> 
> + reboot_mode {

nodes are commonly written with a dash "-" instead of an underscore "_".


> + compatible = "rockchip,reboot-mode";
> + rockchip,regmap = <&pmu>;

I do believe this should be a sub-node of the pmu, similar to the power-
domains. Due to the "simple-mfd" compatible of the pmu, it will get probed 
automatically and the driver can than get the regmap via

parent = dev->parent;
regmap = syscon_node_to_regmap(parent->of_node);

as the power-domains do and therefore also doesn't need the rockchip,regmap 
property.


> + offset = <0x94>;
> + loader {
> + linux,mode = "loader";
> + linux,magic = ;

linux,mode seems correct, but the magic value is actually not linux-specific 
but instead firmware-specific, so I'm not sure about that linux-prefix there

But I guess that would be for the dt-people :-)


> + };
> +
> + maskrom {
> + linux,mode = "maskrom";
> + linux,magic = ;
> + };

Just for my understanding, while I expect the bootloader to interpret the 
other values, does the maskrom read and handle this one?


> +
> + recovery {
> + linux,mode = "recovery";
> + linux,magic = ;
> + };
> +
> + fastboot {
> + linux,mode = "fastboot";
> + linux,magic = ;
> + };
> + };
> +
>   reserved-memory {
>   #address-cells = <1>;
>   #size-cells = <1>;

I do believe rk3288-veyron.dtsi would need some sort of special handling.
I don't think coreboot interprets most of those handles, but I guess only the 
maskrom one would be handled by the maskrom?


Heiko

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] ARM: dts: add the wifi/bt regulator for kylin board

[Heiko Stübner]

Hi Caesaer,

Am Dienstag, 22. Dezember 2015, 17:33:52 schrieb Caesar Wang:
> Without this the wifi/bluetooth module doesn't work
> properly at bootup.
> 
> Signed-off-by: Caesar Wang 
> 
> Patchset: Rockchip kylin board Patch[6/6], bring up kylin board.
> We need add the wifi regulator to control the power.
> 
> (am https://patchwork.kernel.org/patch/7873721/)
> ---
> 
>  arch/arm/boot/dts/rk3036-kylin.dts | 43
> +- 1 file changed, 42 insertions(+), 1
> deletion(-)
> 
> diff --git a/arch/arm/boot/dts/rk3036-kylin.dts
> b/arch/arm/boot/dts/rk3036-kylin.dts index 2ef38be..ed0466f 100644
> --- a/arch/arm/boot/dts/rk3036-kylin.dts
> +++ b/arch/arm/boot/dts/rk3036-kylin.dts
> @@ -76,6 +76,32 @@
>   regulator-always-on;
>   regulator-boot-on;
>   };
> +
> + bt_regulator: bt-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&bt_rst_l>;
> + regulator-name = "bt_regulator";
> + };
> +
> + wifi_regulator: wifi-regulator {
> + /*
> +  * On the module itself this is one of these (depending
> +  * on the actual card populated):
> +  * - SDIO_RESET_L_WL_REG_ON
> +  * - PDN (power down when low)
> +  */
> +
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio0 26 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_enable_h>;
> + regulator-name = "wifi_regulator";
> + vin-supply = <&bt_regulator>;
> + };
>  };
> 
>  &acodec {
> @@ -303,12 +329,13 @@
>   sd-uhs-sdr50;
>   sd-uhs-sdr104;
>   cap-sdio-irq;
> + card-external-vcc-supply = <&wifi_regulator>;

as I said in our chat, that concept didn't make it into the kernel. mmc-power-
sequences are the new thing. Please look into the sdio-pwrseq node in rk3288-
veyron.dtsi for examples.


Heiko

>   default-sample-phase = <90>;
>   keep-power-in-suspend;
>   non-removable;
>   num-slots = <1>;
>   pinctrl-names = "default";
> - pinctrl-0 = <&sdio_clk &sdio_cmd &sdio_bus4>;
> + pinctrl-0 = <&sdio_clk &sdio_cmd &sdio_bus4 &bt_wake_h>;
>  };
> 
>  &uart2 {
> @@ -330,6 +357,20 @@
>   };
>   };
> 
> + sdio {
> + wifi_enable_h: wifienable-h {
> + rockchip,pins = <0 26 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + bt_rst_l: bt-rst-l {
> + rockchip,pins = <2 9 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + bt_wake_h: bt-wake-h {
> + rockchip,pins = <2 8 RK_FUNC_GPIO &pcfg_pull_default>;
> + };
> + };
> +
>   sleep {
>   global_pwroff: global-pwroff {
>   rockchip,pins = <2 7 RK_FUNC_1 &pcfg_pull_none>;

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dt-bindings: sound: add devicetree document for rt5616

[Heiko Stübner]

Am Montag, 21. Dezember 2015, 21:18:14 schrieb Caesar Wang:
> Add the description for rt5616 codec.
> 
> Signed-off-by: Caesar Wang 
> ---
> 
>  Documentation/devicetree/bindings/sound/rt5616.txt | 38
> ++ 1 file changed, 38 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/rt5616.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/rt5616.txt
> b/Documentation/devicetree/bindings/sound/rt5616.txt new file mode 100644
> index 000..af96207
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/rt5616.txt
> @@ -0,0 +1,38 @@
> +RT5616 audio CODEC
> +
> +This device supports I2C only.
> +
> +Required properties:
> +
> +- compatible : "realtek,rt5616".
> +
> +- reg : The I2C address of the device.
> +
> +Optional properties:

you don't have optional properties, so that headline should probably also not 
be here.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 0/6] Support the rk3036 Kylin board

[Heiko Stübner]

Hi Caesar,

Am Sonntag, 20. Dezember 2015, 20:49:14 schrieb Caesar Wang:
> Hi Heiko,
> 
> 在 2015年12月20日 01:16, Heiko Stübner 写道:
> > Hi Caesar,
> > 
> > Am Donnerstag, 17. Dezember 2015, 22:21:46 schrieb Caesar Wang:
> >> Kylin-board is based on RK3036 SOCs, add the initiation
> >> version for working.
> > 
> > I've applied:
> > - patch1 (please include the "rockchip:" part in dts subjects)
> > - patch3 (dito)
> > - patch4 (after merging in patch6 and dropping the hdmi+lcdc parts)
> 
> Okay, thanks!
> 
> Sync to the rockchip github
> <https://github.com/rockchip-linux/kernel/commits/develop4.4>.
> 
> > Please resubmit the missing parts (audio + graphics) against my dts-branch
> > [0] after the relevant maintainers have added the code-parts to their
> > trees.
> For codec:
> RT5616 is existing  in
> https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=for-ne
> xt now.

that seems to be missing the devicetree-parts. I think you can just send a 
patch to Mark adding
- of_device_id match table
- of_match_table assignment
- binding-documentation (it seems to have only compatible and reg propeties)


Heiko

> For 3036 vop:
> I would like wait a moment from Mark Yao updating the driver.
> 
> > Thanks
> > Heiko
> > 
> > [0]
> > https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log
> > /?h=v4.5-armsoc/dts32> 
> >> This series patches have the following decriptions:
> >> 
> >> PATCH[1/6]:
> >> ARM: dts: fix the correct pinctrl control for rk3036
> >> 
> >> The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs
> >> can't set the status in the internal.
> >> ---
> >> 
> >> PATCH[2/6]:
> >> ARM: dts: add the lcdc and hdmi node for rk3036
> >> 
> >> Add the devices is related to display.
> >> Based on the series patches of Mark Yao's
> >> ---
> >> 
> >> PATCH[3/6]:
> >> ARM: dts: add the sdio/sdmmc node for rk3036
> >> 
> >> Add the wifi/sd card work for kylin board.
> >> ---
> >> 
> >> PATCH[4/6]:
> >> ARM: dts: rockchip: add the kylin board for rk3036
> >> 
> >> Add the dts for kylin board.
> >> ---
> >> 
> >> PATCH[5/6]:
> >> ARM: dts: add the sound codec for kylin board
> >> 
> >> Make the codec rt5616 working on kylin board.
> >> The realteak have been upstream for Mark Brown,
> >> I guess need some days to review.
> >> 
> >> ---
> >> 
> >> PATCH[6/6]:
> >> ARM: dts: add the sdio node for kylin board
> >> 
> >> Enable the sdio for kylin board.
> >> ---
> >> 
> >> Caesar Wang (6):
> >>ARM: dts: fix the correct pinctrl control for rk3036
> >>ARM: dts: add the lcdc and hdmi node for rk3036
> >>ARM: dts: add the sdio/sdmmc node for rk3036
> >>ARM: dts: rockchip: add the kylin board for rk3036
> >>ARM: dts: add the sound codec for kylin board
> >>ARM: dts: add the sdio node for kylin board
> >>   
> >>   Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
> >>   arch/arm/boot/dts/Makefile |   1 +
> >>   arch/arm/boot/dts/rk3036-kylin.dts | 345
> >> 
> >> + arch/arm/boot/dts/rk3036.dtsi 
> >> |
> >> 167 -- 4 files changed, 498 insertions(+), 19 deletions(-)
> >> 
> >>   create mode 100644 arch/arm/boot/dts/rk3036-kylin.dts
> > 
> > ___
> > Linux-rockchip mailing list
> > linux-rockc...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 0/6] Support the rk3036 Kylin board

[Heiko Stübner]

Hi Caesar,

Am Donnerstag, 17. Dezember 2015, 22:21:46 schrieb Caesar Wang:
> Kylin-board is based on RK3036 SOCs, add the initiation
> version for working.

I've applied:
- patch1 (please include the "rockchip:" part in dts subjects)
- patch3 (dito)
- patch4 (after merging in patch6 and dropping the hdmi+lcdc parts)

Please resubmit the missing parts (audio + graphics) against my dts-branch [0]
after the relevant maintainers have added the code-parts to their trees.


Thanks
Heiko

[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.5-armsoc/dts32

> 
> This series patches have the following decriptions:
> 
> PATCH[1/6]:
> ARM: dts: fix the correct pinctrl control for rk3036
> 
> The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs
> can't set the status in the internal.
> ---
> 
> PATCH[2/6]:
> ARM: dts: add the lcdc and hdmi node for rk3036
> 
> Add the devices is related to display.
> Based on the series patches of Mark Yao's
> ---
> 
> PATCH[3/6]:
> ARM: dts: add the sdio/sdmmc node for rk3036
> 
> Add the wifi/sd card work for kylin board.
> ---
> 
> PATCH[4/6]:
> ARM: dts: rockchip: add the kylin board for rk3036
> 
> Add the dts for kylin board.
> ---
> 
> PATCH[5/6]:
> ARM: dts: add the sound codec for kylin board
> 
> Make the codec rt5616 working on kylin board.
> The realteak have been upstream for Mark Brown,
> I guess need some days to review.
> 
> ---
> 
> PATCH[6/6]:
> ARM: dts: add the sdio node for kylin board
> 
> Enable the sdio for kylin board.
> ---
> 
> 
> 
> Caesar Wang (6):
>   ARM: dts: fix the correct pinctrl control for rk3036
>   ARM: dts: add the lcdc and hdmi node for rk3036
>   ARM: dts: add the sdio/sdmmc node for rk3036
>   ARM: dts: rockchip: add the kylin board for rk3036
>   ARM: dts: add the sound codec for kylin board
>   ARM: dts: add the sdio node for kylin board
> 
>  Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
>  arch/arm/boot/dts/Makefile |   1 +
>  arch/arm/boot/dts/rk3036-kylin.dts | 345
> + arch/arm/boot/dts/rk3036.dtsi  |
> 167 -- 4 files changed, 498 insertions(+), 19 deletions(-)
>  create mode 100644 arch/arm/boot/dts/rk3036-kylin.dts

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v11 0/19] Add Analogix Core Display Port Driver

[Heiko Stübner]

Hi Yakir,

Am Mittwoch, 16. Dezember 2015, 11:20:18 schrieb Yakir Yang:
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM

I'm really sorry for not thinking of this earlier, but I think we'll be doing 
the atomic modesetting conversion of the drm/kms driver first - see v3 series 
from Mark Yao.

Could you handle necessary changes to make it apply and work _after_ the 
atomic modesetting conversion please?


Thanks
Heiko


> But  there are still three light registers setting differents bewteen
> exynos and rk3288.
> 1. RK3288 have five special pll resigters which not indicata in exynos
>dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>register).
> 
> This series have been well tested on Rockchip platform with eDP panel on
> Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have
> tested on Samsung Snow and Peach Pit Chromebooks, and thanks to
> Javier@Samsung help to retest the whole series on Samsung Exynos5800 Peach
> Pi Chromebook, glad to say that things works rightlly.
> 
> Thanks,
> - Yakir
> 
> 
> Changes in v11:
> - Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
> - Correct the title of this rockchip dp phy document(Rob)
> - Add the ack from Rob Herring
> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
> - Add the ack from Rob Herring
> - Revert parts of Gustavo Padovan's changes in commit:
>   drm/exynos: do not start enabling DP at bind() phase
>   Add dp phy poweron function in bind time.
> - Move the panel prepare from get_modes time to bind time, and move
>   the panel unprepare from bridge->disable to unbind time. (Heiko)
> 
> Changes in v10:
> - Add the ack from Rob Herring
> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
> (Heiko) - Add the ack from Rob Herring
> - Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
> BIT(4) -> BIT(20)
> - Remove the surplus "plat_data" check. (Heiko)
> -   switch (dp->plat_data && dp->plat_data->dev_type) {
> +   switch (dp->plat_data->dev_type) {
> 
> Changes in v9:
> - Document more details for 'ports' property.
> - Removed the unused the variable "res" in probe function. (Heiko)
> - Removed the unused head file.
> 
> Changes in v8:
> - Correct the right document path of display-timing.txt (Heiko)
> - Correct the misspell of 'from' to 'frm'. (Heiko)
> - Modify the commit subject name. (Heiko)
> - Fix the mixed spacers on macro definitions. (Heiko)
> - Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
> - Remove the specific address in the example node name. (Heiko)
> 
> Changes in v7:
> - Back to use the of_property_read_bool() interfacs to provoid backward
>   compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
>   to avoid -EOVERFLOW error (Krzysztof)
> - Simply the commit message. (Kishon)
> - Symmetrical enable/disbale the phy clock and power. (Kishon)
> - Simplify the commit message. (Kishon)
> 
> Changes in v6:
> - Fix the Kconfig recursive dependency (Javier)
> - Fix Peach Pit hpd property name error:
> -   hpd-gpio = <&gpx2 6 0>;
> +   hpd-gpios = <&gpx2 6 0>;
> 
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
>   the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
>   attch function. Cause once platform failed at attach, core driver should
>   still failed, so no need to init connector before platform attached
> (Krzysztof) - Keep code style no changes with the previous exynos_dp_code.c
> in this patch, and update commit message about the new export symbol
> (Krzysztof) - Gather the device type patch (v4 11/16) into this one.
> (Krzysztof) - leave out the connector registration to analogix platform
> driver. (Thierry) - Resequence this patch after analogix_dp driver have
> been split
>   from exynos_dp code, and rephrase reasonable commit message, and
>   remove some controversial style (Krzysztof)
> - analogix_dp_write_byte_to_dpcd(
> - dp, DP_TEST_RESPONSE,
> + analogix_dp_write_byte_to_dpcd(dp,
> + DP_TEST_RESPONSE,
>   DP_TEST_EDID_CHECKSUM_WRITE);
> - Switch video timing type to "u32", so driver could use
> "of_property_read_u32" to get the backword timing values. Krzysztof suggest
> me that driver could use the "of_property_read_bool" to get backword timing
> values, but that interfacs wo

Re: [PATCH v1 0/6] Support the rk3036 Kylin board

[Heiko Stübner]

Hi Caesar, Kees,

Am Donnerstag, 17. Dezember 2015, 11:45:06 schrieb Kees Cook:
> On Thu, Dec 17, 2015 at 6:21 AM, Caesar Wang  wrote:
> > Kylin-board is based on RK3036 SOCs, add the initiation
> > version for working.
> > 
> > This series patches have the following decriptions:
> > 
> > PATCH[1/6]:
> > ARM: dts: fix the correct pinctrl control for rk3036
> > 
> > The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs
> > can't set the status in the internal.
> > ---
> > 
> > PATCH[2/6]:
> > ARM: dts: add the lcdc and hdmi node for rk3036
> > 
> > Add the devices is related to display.
> > Based on the series patches of Mark Yao's
> > ---
> > 
> > PATCH[3/6]:
> > ARM: dts: add the sdio/sdmmc node for rk3036
> > 
> > Add the wifi/sd card work for kylin board.
> > ---
> > 
> > PATCH[4/6]:
> > ARM: dts: rockchip: add the kylin board for rk3036
> > 
> > Add the dts for kylin board.
> > ---
> > 
> > PATCH[5/6]:
> > ARM: dts: add the sound codec for kylin board
> > 
> > Make the codec rt5616 working on kylin board.
> > The realteak have been upstream for Mark Brown,
> > I guess need some days to review.
> > 
> > ---
> > 
> > PATCH[6/6]:
> > ARM: dts: add the sdio node for kylin board
> > 
> > Enable the sdio for kylin board.
> > ---
> 
> Thanks for sending this!
> 
> Reviewed-by: Kees Cook 
> 
> Some thoughts: maybe collapse 4, 5, and 6 together, since it's a new file?

@Caesar, no need to resend, I can do that merging myself.
After we clarified the authorship of patch1 ;-) .

Except the audio patch, as we're missing the realtek codec driver.
I'll also drop the lcdc+hdmi parts for now, as the relevant parts aren't in
any maintainer-tree yet. The ordering is for this:

- atomic conversion
- rk3036 vop
- inno-hdmi driver
- dts changes last

The driver for the Innosilicon hdmi driver is from November, had one comment 
from me and Caesar+ Yakir should make sure it works with the atomic 
modesetting variant of the drm/kms driver please. (And probably resend the 
series fixing that one tiny comment).


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 5/6] ARM: dts: add the sound codec for kylin board

[Heiko Stübner]

Am Donnerstag, 17. Dezember 2015, 22:21:51 schrieb Caesar Wang:
> Support the rt5616 codec for kylin board, but we need
> enable the i2s firstly.
> 
> Signed-off-by: Caesar Wang 
> ---
> 
>  arch/arm/boot/dts/rk3036-kylin.dts | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3036-kylin.dts
> b/arch/arm/boot/dts/rk3036-kylin.dts index 69b1e1e..296139b 100644
> --- a/arch/arm/boot/dts/rk3036-kylin.dts
> +++ b/arch/arm/boot/dts/rk3036-kylin.dts
> @@ -46,6 +46,28 @@
>   model = "Rockchip RK3036 KylinBoard";
>   compatible = "rockchip,rk3036-kylin", "rockchip,rk3036";
> 
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,name = "rockchip,rt5616-codec";
> + simple-audio-card,mclk-fs = <64>;
> + simple-audio-card,widgets =
> + "Microphone", "Microphone Jack",
> + "Headphone", "Headphone Jack";
> + simple-audio-card,routing =
> + "MIC1", "Microphone Jack",
> + "MIC2", "Microphone Jack",
> + "Microphone Jack", "micbias1",
> + "Headphone Jack", "HPOL",
> + "Headphone Jack", "HPOR";
> + simple-audio-card,cpu {
> + sound-dai = <&i2s>;
> + };
> + simple-audio-card,codec {
> + sound-dai = <&rt5616>;
> + };
> + };
> +
>   vcc_sys: vsys-regulator {
>   compatible = "regulator-fixed";
>   regulator-name = "vcc_sys";
> @@ -261,6 +283,17 @@
> 
>  &i2c2 {
>   status = "okay";
> +
> + rt5616: rt5616@1b {
> + #sound-dai-cells = <0>;
> + compatible = "rt5616";
> + reg = <0x1b>;
> + };

I don't see that codec in the asoc-tree [0]. And the compatible
would of course also need to be "realtek,rt5616".


[0] 
https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/tree/sound/soc/codecs?h=for-next


> +};
> +
> +&i2s {
> + #sound-dai-cells = <0>;
> + status = "okay";
>  };
> 
>  &lcdc {

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/6] ARM: dts: fix the correct pinctrl control for rk3036

[Heiko Stübner]

Am Donnerstag, 17. Dezember 2015, 22:21:47 schrieb Caesar Wang:
> The pinctrl gpio pull up/down is incorrect since the rk3036 SoCs
> can't set the status in the internal.
> 
> We should keep the default status for enable the gpio status,
> In fact, the pull_none is the disable the gpio pull up/down.
> 
> Signed-off-by: Xing Zheng 
> Signed-off-by: Caesar Wang 

>From the signed-off-by's I guess this change was created by Xing (author), 
right?


Heiko

> ---
> 
>  arch/arm/boot/dts/rk3036.dtsi | 34 +++---
>  1 file changed, 15 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
> index f8758bf..620e6e0 100644
> --- a/arch/arm/boot/dts/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rk3036.dtsi
> @@ -427,12 +427,8 @@
>   #interrupt-cells = <2>;
>   };
> 
> - pcfg_pull_up: pcfg-pull-up {
> - bias-pull-up;
> - };
> -
> - pcfg_pull_down: pcfg-pull-down {
> - bias-pull-down;
> + pcfg_pull_default: pcfg_pull_default {
> + bias-pull-pin-default;
>   };
> 
>   pcfg_pull_none: pcfg-pull-none {
> @@ -473,18 +469,18 @@
>   };
> 
>   emmc_cmd: emmc-cmd {
> - rockchip,pins = <2 1 RK_FUNC_2 &pcfg_pull_none>;
> + rockchip,pins = <2 1 RK_FUNC_2 
> &pcfg_pull_default>;
>   };
> 
>   emmc_bus8: emmc-bus8 {
> - rockchip,pins = <1 24 RK_FUNC_2 
> &pcfg_pull_none>,
> - <1 25 RK_FUNC_2 
> &pcfg_pull_none>,
> - <1 26 RK_FUNC_2 
> &pcfg_pull_none>,
> - <1 27 RK_FUNC_2 
> &pcfg_pull_none>,
> - <1 28 RK_FUNC_2 
> &pcfg_pull_none>,
> - <1 29 RK_FUNC_2 
> &pcfg_pull_none>,
> - <1 30 RK_FUNC_2 
> &pcfg_pull_none>,
> - <1 31 RK_FUNC_2 
> &pcfg_pull_none>;
> + rockchip,pins = <1 24 RK_FUNC_2 
> &pcfg_pull_default>,
> + <1 25 RK_FUNC_2 
> &pcfg_pull_default>,
> + <1 26 RK_FUNC_2 
> &pcfg_pull_default>,
> + <1 27 RK_FUNC_2 
> &pcfg_pull_default>,
> + <1 28 RK_FUNC_2 
> &pcfg_pull_default>,
> + <1 29 RK_FUNC_2 
> &pcfg_pull_default>,
> + <1 30 RK_FUNC_2 
> &pcfg_pull_default>,
> + <1 31 RK_FUNC_2 
> &pcfg_pull_default>;
>   };
>   };
> 
> @@ -522,12 +518,12 @@
> 
>   uart0 {
>   uart0_xfer: uart0-xfer {
> - rockchip,pins = <0 16 RK_FUNC_1 &pcfg_pull_up>,
> + rockchip,pins = <0 16 RK_FUNC_1 
> &pcfg_pull_default>,
>   <0 17 RK_FUNC_1 
> &pcfg_pull_none>;
>   };
> 
>   uart0_cts: uart0-cts {
> - rockchip,pins = <0 18 RK_FUNC_1 &pcfg_pull_up>;
> + rockchip,pins = <0 18 RK_FUNC_1 
> &pcfg_pull_default>;
>   };
> 
>   uart0_rts: uart0-rts {
> @@ -537,7 +533,7 @@
> 
>   uart1 {
>   uart1_xfer: uart1-xfer {
> - rockchip,pins = <2 22 RK_FUNC_1 
> &pcfg_pull_none>,
> + rockchip,pins = <2 22 RK_FUNC_1 
> &pcfg_pull_default>,
>   <2 23 RK_FUNC_1 
> &pcfg_pull_none>;
>   };
>   /* no rts / cts for uart1 */
> @@ -545,7 +541,7 @@
> 
>   uart2 {
>   uart2_xfer: uart2-xfer {
> - rockchip,pins = <1 18 RK_FUNC_2 
> &pcfg_pull_none>,
> + rockchip,pins = <1 18 RK_FUNC_2 
> &pcfg_pull_default>,
>   <1 19 RK_FUNC_2 
> &pcfg_pull_none>;
>   };
>   /* no rts / cts for uart2 */

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/6] Add mipi dsi support for rk3288

[Heiko Stübner]

Hi Chris,

Am Mittwoch, 16. Dezember 2015, 18:10:10 schrieb Chris Zhong:
> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
> controller DRM driver.
> 
> The MIPI DSI feature is tested on rk3288 evb board, backport them to
> chrome os kernel chrome_v3.14, and it can display normally.
> 
> This patchset is base on the patchset from ying@freescale.com.
> 
> 
> According to the suggestion from Thierry, I have get rid of the bridge,
> and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c.

from my point it looks good (although I cannot really speak on the drm-related 
internals).

But I do think we'll be doing atomic modesetting conversion first (last 
version posted from Mark today), so you should probably make sure your dsi 
driver still works after that conversion and make changes if needed.


Heiko

> 
> 
> Changes in v6:
> - update the document, since the bridge device has been deleted.
> - Do not use bridge driver (Thierry Reding)
> - Optimization the phy init sequence
> 
> Changes in v5:
> - modify the clk name to SCLK_MIPIDSI_24M
> - add a blank line befor lcd_en
> 
> Changes in v4:
> - use clk_round_rate to check the clock rate in vop_crtc_mode_fixup
> 
> Changes in v3:
> - move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
> 
> Chris Zhong (5):
>   drm/rockchip: return a true clock rate to adjusted_mode
>   Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
>   drm: rockchip: Support Synopsys DW MIPI DSI
>   ARM: dts: rockchip: add rk3288 mipi_dsi nodes
>   ARM: dts: rockchip: add support mipi panel tv080wum-nl0
> 
> Liu Ying (1):
>   drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
> 
>  .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   60 +
>  arch/arm/boot/dts/rk3288-evb.dtsi  |   20 +-
>  arch/arm/boot/dts/rk3288.dtsi  |   39 +
>  drivers/gpu/drm/rockchip/Kconfig   |   10 +
>  drivers/gpu/drm/rockchip/Makefile  |1 +
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1200
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  
>  8 +
>  include/drm/drm_mipi_dsi.h |   14 +
>  8 files changed, 1351 insertions(+), 1 deletion(-)
>  create mode 100644
> Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
> create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] clk: rockchip: rk3036: enable the CLK_IGNORE_UNUSED flag for aclk_vio

[Heiko Stübner]

Am Mittwoch, 16. Dezember 2015, 16:27:18 schrieb Caesar Wang:
> From: Yakir Yang 
> 
> ACLK_VIO is the noc bus clock for display module, display cann't
> read data from ddr without this clock enabled.
> 
> Due to it shouldn't belong to any driver, but we need it enabled,
> so just mark it as the CLK_IGNORE_UNUSED flag.
> 
> Signed-off-by: Yakir Yang 
> Signed-off-by: Caesar Wang 

applied to my clk-branch for 4.5


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] ARM: config: Add the rk3036 configure for kylin board

[Heiko Stübner]

Hi Caesar,

Am Mittwoch, 16. Dezember 2015, 16:27:21 schrieb Caesar Wang:
> Add RK3036-specific configuration for Kylin board.
> 
> Signed-off-by: Caesar Wang 

I don't think we generally do per-board defconfigs in the mainline kernel 
anymore. If you are missing specific functionality, please add them as patch 
to the multi_v7_defconfig (ideally as module).


Heiko

> 
> ---
> 
>  arch/arm/configs/rk3036_kylin_defconfig | 230
>  1 file changed, 230 insertions(+)
>  create mode 100644 arch/arm/configs/rk3036_kylin_defconfig
> 
> diff --git a/arch/arm/configs/rk3036_kylin_defconfig
> b/arch/arm/configs/rk3036_kylin_defconfig new file mode 100644
> index 000..692c393
> --- /dev/null
> +++ b/arch/arm/configs/rk3036_kylin_defconfig
> @@ -0,0 +1,230 @@
> +CONFIG_CROSS_COMPILE="arm-linux-gnueabi-"
> +# CONFIG_LOCALVERSION_AUTO is not set
> +CONFIG_DEFAULT_HOSTNAME="radxarock"
> +CONFIG_SYSVIPC=y
> +# CONFIG_USELIB is not set
> +CONFIG_AUDIT=y
> +CONFIG_IRQ_DOMAIN_DEBUG=y
> +CONFIG_BLK_DEV_INITRD=y
> +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> +CONFIG_PERF_EVENTS=y
> +# CONFIG_COMPAT_BRK is not set
> +CONFIG_SLAB=y
> +CONFIG_JUMP_LABEL=y
> +CONFIG_MODULES=y
> +CONFIG_MODULE_FORCE_LOAD=y
> +CONFIG_MODULE_UNLOAD=y
> +CONFIG_PARTITION_ADVANCED=y
> +# CONFIG_IOSCHED_CFQ is not set
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_PL310_ERRATA_588369=y
> +CONFIG_PL310_ERRATA_727915=y
> +CONFIG_ARM_ERRATA_720789=y
> +CONFIG_ARM_ERRATA_754322=y
> +CONFIG_SMP=y
> +CONFIG_NR_CPUS=2
> +CONFIG_PREEMPT_VOLUNTARY=y
> +CONFIG_AEABI=y
> +CONFIG_HIGHMEM=y
> +# CONFIG_COMPACTION is not set
> +CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
> +CONFIG_CLEANCACHE=y
> +CONFIG_FRONTSWAP=y
> +CONFIG_ZBOOT_ROM_TEXT=0x0
> +CONFIG_ARM_APPENDED_DTB=y
> +CONFIG_ARM_ATAG_DTB_COMPAT=y
> +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
> +CONFIG_CPU_FREQ=y
> +CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y
> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> +CONFIG_CPUFREQ_DT=y
> +CONFIG_CPU_IDLE=y
> +CONFIG_VFP=y
> +CONFIG_NEON=y
> +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
> +CONFIG_PM_WAKELOCKS=y
> +CONFIG_PM_DEBUG=y
> +CONFIG_NET=y
> +CONFIG_PACKET=y
> +CONFIG_UNIX=y
> +CONFIG_INET=y
> +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
> +# CONFIG_INET_XFRM_MODE_TUNNEL is not set
> +# CONFIG_INET_XFRM_MODE_BEET is not set
> +# CONFIG_INET_LRO is not set
> +# CONFIG_INET_DIAG is not set
> +# CONFIG_IPV6 is not set
> +CONFIG_CFG80211_WEXT=y
> +CONFIG_RFKILL=y
> +CONFIG_DEVTMPFS=y
> +CONFIG_DEVTMPFS_MOUNT=y
> +# CONFIG_FIRMWARE_IN_KERNEL is not set
> +CONFIG_BLK_DEV_LOOP=y
> +CONFIG_BLK_DEV_RAM=y
> +CONFIG_BLK_DEV_RAM_COUNT=1
> +CONFIG_BLK_DEV_RAM_SIZE=16384
> +CONFIG_SRAM=y
> +CONFIG_SCSI=y
> +# CONFIG_SCSI_PROC_FS is not set
> +CONFIG_BLK_DEV_SD=y
> +# CONFIG_SCSI_LOWLEVEL is not set
> +CONFIG_NETDEVICES=y
> +# CONFIG_NET_CADENCE is not set
> +# CONFIG_NET_VENDOR_BROADCOM is not set
> +# CONFIG_NET_VENDOR_CIRRUS is not set
> +# CONFIG_NET_VENDOR_FARADAY is not set
> +# CONFIG_NET_VENDOR_INTEL is not set
> +# CONFIG_NET_VENDOR_MARVELL is not set
> +# CONFIG_NET_VENDOR_MICREL is not set
> +# CONFIG_NET_VENDOR_NATSEMI is not set
> +# CONFIG_NET_VENDOR_SAMSUNG is not set
> +# CONFIG_NET_VENDOR_SEEQ is not set
> +# CONFIG_NET_VENDOR_SMSC is not set
> +CONFIG_STMMAC_ETH=y
> +# CONFIG_NET_VENDOR_VIA is not set
> +# CONFIG_NET_VENDOR_WIZNET is not set
> +CONFIG_SMSC_PHY=y
> +# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
> +CONFIG_INPUT_MOUSEDEV_SCREEN_X=800
> +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=600
> +CONFIG_INPUT_EVDEV=y
> +# CONFIG_KEYBOARD_ATKBD is not set
> +CONFIG_KEYBOARD_GPIO=y
> +CONFIG_KEYBOARD_GPIO_POLLED=y
> +# CONFIG_INPUT_MOUSE is not set
> +CONFIG_INPUT_TOUCHSCREEN=y
> +CONFIG_INPUT_MISC=y
> +# CONFIG_SERIO is not set
> +# CONFIG_LEGACY_PTYS is not set
> +# CONFIG_DEVKMEM is not set
> +CONFIG_SERIAL_8250=y
> +CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_8250_DW=y
> +# CONFIG_HW_RANDOM is not set
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_GPIO=y
> +CONFIG_I2C_RK3X=y
> +CONFIG_GPIO_DWAPB=y
> +CONFIG_POWER_SUPPLY=y
> +CONFIG_POWER_RESET=y
> +CONFIG_SENSORS_IIO_HWMON=y
> +CONFIG_THERMAL=y
> +CONFIG_CPU_THERMAL=y
> +CONFIG_WATCHDOG=y
> +CONFIG_SOFT_WATCHDOG=y
> +CONFIG_MFD_RK808=y
> +CONFIG_MFD_TPS65910=y
> +CONFIG_REGULATOR_DEBUG=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> +CONFIG_REGULATOR_ACT8865=y
> +CONFIG_REGULATOR_FAN53555=y
> +CONFIG_REGULATOR_RK808=y
> +CONFIG_DRM=y
> +CONFIG_DRM_ROCKCHIP=y
> +CONFIG_ROCKCHIP_DW_HDMI=y
> +CONFIG_ROCKCHIP_INNO_HDMI=y
> +CONFIG_DRM_PANEL_SIMPLE=y
> +CONFIG_FB_MODE_HELPERS=y
> +CONFIG_BACKLIGHT_LCD_SUPPORT=y
> +CONFIG_LCD_CLASS_DEVICE=y
> +CONFIG_BACKLIGHT_CLASS_DEVICE=y
> +# CONFIG_BACKLIGHT_GENERIC is not set
> +CONFIG_BACKLIGHT_PWM=y
> +CONFIG_SOUND=y
> +CONFIG_SND=y
> +CONFIG_SND_SOC=y
> +CONFIG_SND_SOC_ROCKCHIP=y
> +CONFIG_SND_SOC_ROCKCHIP_I2S=y
> +CONFIG_SND_SIMPLE_CARD=y
> +CONFIG_USB=y
> +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> +CONFIG_USB_OTG=y
> +CONFIG_USB_MON=y
> +CONFIG_USB_STORAGE=y
> +CONFIG_USB_DWC2=y
> +CONFIG_USB_DWC2_PLATFOR

Re: [PATCH 3/5] ARM: dts: rockchip: update the core dts for rk3036

[Heiko Stübner]

Hi Caesar,

Am Mittwoch, 16. Dezember 2015, 16:27:19 schrieb Caesar Wang:
> Update the core dts for rk3036 SoCs.
> 
> 1) Add the display (lcdc, hdmi, vop...) device node.
> 2) modify the i2s name to i2s0 and i2s1.
>Although there is only one i2s IP inside the rk3036,
>we need use all of the gpios of i2s0 and i2s1.
>So, we add the i2s1 IP is the same with i2s0 to support the
>different gpios.
> 3) Add sdio for wifi module, sdmmc for sd card.

if you need a list to describe changes, it is a good indication that this 
needs to be split into separate patches.


> Signed-off-by: Caesar Wang 
> ---
> 
>  arch/arm/boot/dts/rk3036.dtsi | 225
> +- 1 file changed, 221
> insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
> index f8758bf..574c56c 100644
> --- a/arch/arm/boot/dts/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rk3036.dtsi
> @@ -55,6 +55,7 @@
>   i2c1 = &i2c1;
>   i2c2 = &i2c2;
>   mshc0 = &emmc;
> + mshc1 = &sdmmc;
>   serial0 = &uart0;
>   serial1 = &uart1;
>   serial2 = &uart2;
> @@ -145,6 +146,63 @@
>   };
>   };
> 
> + lcdc_mmu: iommu@10118300 {
> + compatible = "rockchip,iommu";
> + reg = <0x10118300 0x100>;
> + interrupts = ;
> + interrupt-names = "lcdc_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + lcdc: lcdc@10118000 {
> + compatible = "rockchip,rk3036-lcdc";
> + reg = <0x10118000 0x19c>;
> + interrupts = ;
> + clocks = <&cru ACLK_LCDC>, <&cru SCLK_LCDC>, <&cru HCLK_LCDC>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_LCDC1_A>, <&cru SRST_LCDC1_H>, <&cru 
> SRST_LCDC1_D>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&lcdc_mmu>;
> +
> + status = "disabled";
> +
> + lcdc_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lcdc_out_hdmi: endpoint@0 {
> + reg = <1>;
> + remote-endpoint = <&hdmi_in_lcdc>;
> + };
> + };
> + };

please only add nodes for things _after_ they are posted and applied by the 
maintainer (Mark Yao in this case)


> + hdmi: hdmi@20034000 {
> + compatible = "rockchip,rk3036-inno-hdmi";
> + reg = <0x20034000 0x4000>;
> + interrupts = ;
> + clocks = <&cru  PCLK_HDMI>;
> + clock-names = "pclk";
> + rockchip,grf = <&grf>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_ctl>;
> + status = "disabled";
> +
> + hdmi_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + hdmi_in_lcdc: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&lcdc_out_hdmi>;
> + };
> + };
> + };

same as above


> +
> + display-subsystem {
> + compatible = "rockchip,display-subsystem";
> + ports = <&lcdc_out>;
> + };
> +
>   gic: interrupt-controller@10139000 {
>   compatible = "arm,gic-400";
>   interrupt-controller;
> @@ -158,6 +216,21 @@
>   interrupts = ;
>   };
> 
> + usbphy: phy {
> + compatible = "rockchip,rk3036-usb-phy";
> + rockchip,grf = <&grf>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> +
> + usbphy0: usb-phy0 {
> + #phy-cells = <0>;
> + reg = <0x17c>;
> + clocks = <&cru SCLK_OTGPHY0>;
> + clock-names = "phyclk";
> + };
> + };
> +

same as above - no driver. With the addition, that the usbphy on rk3036, 
rk3368 (and probably more) is a new IP (Innosilicon it seems instead of the 
DWC picophy) and includes a whole additional set of function registers 
(GRF_USBPHYx_CONy...) to control the phy block, so this should definitly also 
be a separate driver.

Especially also as I'm not yet clear on the clock situation.

On rk3036 sclk_otgphy0 seems to be supplying the phyblock directly (and both 
the HOST and OTG phys).
On rk3228 the phy block has two supplying clocks for 1 OTG and 3 HOSTs (and I 
haven't been able to figure out which is supplying which usb block yet)

etc.

>   usb_otg: usb@1018 {
>   compatible = "rockchip,rk3288-usb", "rockchip,rk3066-usb",
>   "snps,dwc2";

you probably want something like

compatible = "rockchip,rk3036-usb", "rockchip

Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver

[Heiko Stübner]

Am Dienstag, 15. Dezember 2015, 17:34:00 schrieb Arnd Bergmann:
> On Tuesday 15 December 2015 17:31:22 Thierry Reding wrote:
> > On Mon, Dec 14, 2015 at 12:39:44PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 18 November 2015 17:56:22 Andy Yan wrote:
> > > > rockchip platform have a protocol to pass the kernel reboot
> > > > mode to bootloader by some special registers when system reboot.
> > > > By this way the bootloader can take different action according
> > > > to the different kernel reboot mode, for example, command
> > > > "reboot loader" will reboot the board to rockusb mode, this is
> > > > a very convenient way to get the board enter download mode.
> > > > 
> > > > Signed-off-by: Andy Yan 
> > > 
> > > Adding John Stultz to Cc
> > > 
> > > I just saw this thread pop up again, and had to think of John's recent
> > > patch to unify this across platforms.
> > > 
> > > John, can you have a look at this driver too, and see how it fits in?
> > > I think this is yet another variant, using an MMIO register rather than
> > > RAM (as HTC / NVIDIA does) or SRAM (as Qualcomm does), but otherwise
> > > it conceptually fits in with what you had.
> > 
> > FWIW, Tegra typically does use an MMIO register as well. See
> > drivers/soc/tegra/pmc.c:tegra_pmc_restart_notify(). I don't know what
> > HTC does, but if it's writing somewhere in RAM it isn't using the
> > standard way of resetting the SoC. There's early boot ROM code which I
> > think evaluates the PMC_SCRATCH0 register on Tegra to determine which
> > mode to boot into. That's before even any firmware gets the chance of
> > doing anything.
> 
> HTC apparently uses a separate RAM area to pass the reboot reason,
> and they have a driver to store that, which is separate from the
> driver that they use for actually rebooting the machine.

same on Rockchip. The general restart handling doesn't care about any reason, 
it is merely an agreement between kernel and bootloader to store a reason 
value in some reboot-safe register of the soc.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 0/17] Add Analogix Core Display Port Driver

[Heiko Stübner]

Hi Yakir,

Am Montag, 7. Dezember 2015, 14:37:19 schrieb Yakir Yang:
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM

so it looks like the hotplug works nicely now. I was able to test it 
sucessfully on both a Jerry and a Minnie device without needing to force 
hotplug :-) .

As I needed to adapt some patches when applying the lastest ones, I think it 
would be good for a full send of the latest version as v11.

When going over the patches before sending, please also fix the indentation 
issues in analogix_dp_core.h - both newly added elements to analogix_dp_device 
use spaces between type and name, where the rest uses tabs.
[This should of course be fixed in the patches adding these lines :-) ]


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: modify rk3288 jaq backlight-level

[Heiko Stübner]

Hi Caesar,

Am Montag, 7. Dezember 2015, 21:11:08 schrieb Caesar Wang:
> the panel which jaq use require the pwm duty cycle larger than 3%,
> when the backlight status from power off to power on, otherwise the
> backlight will flush, so we modify the second brightness-level to 8,
> and when the backlight from power off to power on the pwm duty cycle
> will larger than 3%.
> 
> Signed-off-by: Caesar Wang 

I've merged the two patches and included them in my series for the veyron edp 
devicetree changes [0].


Heiko

[0] 
https://github.com/mmind/linux-rockchip/commit/45e3abed0a86c7ee5cea0b35492b65890b928175

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] ARM: dts: rockchip: add eFuse node for rk3066a SoCs

[Heiko Stübner]

Am Montag, 14. Dezember 2015, 14:06:06 schrieb Heiko Stübner:
> Hi srini,
> 
> Am Montag, 14. Dezember 2015, 09:57:02 schrieb Srinivas Kandagatla:
> > Heiko,
> > 
> > Can you take the DT patches in this series via your tree.
> > 
> > I picked up nvmem patches from this series.
> 
> yep that was my plan ... just needed to wait for the nvmem parts to be
> picked.

after looking at the patch-series as a whole, I just noticed, that they don't 
even depend on each other ... so I could've picked them earlier easily.

Anyway, I'll do that now.

> > thanks,
> > srini
> > 
> > On 11/11/15 07:34, Caesar Wang wrote:
> > > This patch add the eFuse dt node for rk3066a SoCs.
> > > 
> > > Signed-off-by: Caesar Wang 
> > > ---
> > > 
> > >   arch/arm/boot/dts/rk3066a.dtsi | 13 +
> > >   1 file changed, 13 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/rk3066a.dtsi
> > > b/arch/arm/boot/dts/rk3066a.dtsi index 946f187..f61bb8a 100644
> > > --- a/arch/arm/boot/dts/rk3066a.dtsi
> > > +++ b/arch/arm/boot/dts/rk3066a.dtsi
> > > @@ -153,6 +153,19 @@
> > > 
> > >   clock-names = "timer", "pclk";
> > >   
> > >   };
> > > 
> > > + efuse: efuse@2001 {
> > > + compatible = "rockchip,rockchip-efuse";
> > > + reg = <0x2001 0x4000>;
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + clocks = <&cru PCLK_EFUSE>;
> > > + clock-names = "pclk_efuse";
> > > +
> > > + cpu_leakage: cpu_leakage {
> > > + reg = <0x17 0x1>;
> > > + };
> > > + };
> > > +
> > > 
> > >   timer@20038000 {
> > >   
> > >   compatible = "snps,dw-apb-timer-osc";
> > >   reg = <0x20038000 0x100>;

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] ARM: dts: rockchip: add eFuse node for rk3066a SoCs

[Heiko Stübner]

Hi srini,

Am Montag, 14. Dezember 2015, 09:57:02 schrieb Srinivas Kandagatla:
> Heiko,
> 
> Can you take the DT patches in this series via your tree.
> 
> I picked up nvmem patches from this series.

yep that was my plan ... just needed to wait for the nvmem parts to be picked.


Thanks for the notifying me :-)
Heiko


> 
> thanks,
> srini
> 
> On 11/11/15 07:34, Caesar Wang wrote:
> > This patch add the eFuse dt node for rk3066a SoCs.
> > 
> > Signed-off-by: Caesar Wang 
> > ---
> > 
> >   arch/arm/boot/dts/rk3066a.dtsi | 13 +
> >   1 file changed, 13 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/rk3066a.dtsi
> > b/arch/arm/boot/dts/rk3066a.dtsi index 946f187..f61bb8a 100644
> > --- a/arch/arm/boot/dts/rk3066a.dtsi
> > +++ b/arch/arm/boot/dts/rk3066a.dtsi
> > @@ -153,6 +153,19 @@
> > 
> > clock-names = "timer", "pclk";
> > 
> > };
> > 
> > +   efuse: efuse@2001 {
> > +   compatible = "rockchip,rockchip-efuse";
> > +   reg = <0x2001 0x4000>;
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   clocks = <&cru PCLK_EFUSE>;
> > +   clock-names = "pclk_efuse";
> > +
> > +   cpu_leakage: cpu_leakage {
> > +   reg = <0x17 0x1>;
> > +   };
> > +   };
> > +
> > 
> > timer@20038000 {
> > 
> > compatible = "snps,dw-apb-timer-osc";
> > reg = <0x20038000 0x100>;

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] arm64: dts: rockchip: Add the needed timer for RK3368 SoC

[Heiko Stübner]

Am Freitag, 25. September 2015, 10:14:58 schrieb Caesar Wang:
> There is a need of a broadcast timer in this case to ensure proper
> wakeup when the cpus are in sleep mode and a timer expires.
> 
> Signed-off-by: Caesar Wang 

applied this patch to my dts64 branch for 4.5 .

The Kconfig option will probably need to wait for 4.6 though, due to the 
clocksource change going through Daniel's tree. Or I'll try to submit that 
post 4.5-rc1 as "fix" ... we'll see.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] ARM: dts: rockchip: add core rk3228 dtsi

[Heiko Stübner]

Am Freitag, 11. Dezember 2015, 12:25:32 schrieb Heiko Stübner:
> Hi Jeffy,
> 
> Am Freitag, 11. Dezember 2015, 09:30:51 schrieb Jeffy Chen:
> > Initial release for rk3228 shared dtsi.
> > 
> > Signed-off-by: Jeffy Chen 
> 
> Booth dts look good now, just need to wait on Linus Walleij picking up the
> pinctrl patch first.

as the pinctrl change got picked up, I've now also applied the two dts 
patches. I've added the missing entry for 
Documentation/devicetree/bindings/arm/rockchip.txt myself now, please keep 
that in mind for future boards :-) .


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: dts: rockchip: Fix typo in rk32288 sdmmc card detect pin name

[Heiko Stübner]

Hi Matthias,

Am Freitag, 11. Dezember 2015, 15:45:58 schrieb Matthias Brugger:
> The card detect pin is currently called sdmcc-cd.
> This patch fixes the typo and renames the pin to sdmmc-cd.
> 
> Signed-off-by: Matthias Brugger 

applied to my dts32 branch for 4.5, after fixing the rk32288 in the subject


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/5] Add reboot notifier driver for rockchip platform

[Heiko Stübner]

Am Mittwoch, 18. November 2015, 17:47:24 schrieb Andy Yan:
> rockchip platform have a protocol to pass the kernel reboot
> mode to bootloader by some special registers when system reboot.
> By this way the bootloader can take different action according
> to the different kernel reboot mode, for example, command
> "reboot loader" will reboot the board to rockusb mode, this is
> a very convenient way to get the board enter download mode.
> And Android system also use this protocol to pass "recovery"、
> “fastboot” reboot mode to bootloader. In upstream land, We found
> tegra platform also use this mechanism.
> 
> Before this version, I have sent two Series, which can be found
> at [0] [1]
> [0] https://patchwork.kernel.org/patch/7140751/
> [1] https://patchwork.kernel.org/patch/7153531/

just so it doesn't get lost, this ties into a slightly more generic approach, 
John Stultz is doing for the android reboot reasons:

http://thread.gmane.org/gmane.linux.kernel/2103447

The only difference is that we'd need to use the pmu syscon for it.



> Changes in v3:
>  - rename a pinctrl node in rk3288-veyron, the original name will be
>used in the incoming reboot notifier driver
>  - add dt binding
>  - move from mach-rockchip to drivers/soc/rockchip, as the tegra does
>  - use dts pass the related register
>  - add DT node
> 
> Changes in v2:
>   - check cpu dt node
>   - remove a unnecessary of_put_node in function rockchip_get_pmu_regmap
>   - fix a align issue
>   - use reboot_notifier instead of restart_handler
> 
> Andy Yan (5):
>   ARM: dts: rockchip: rk3288-veyron: rename pinctrl node reboot to reset
>   dt-bindings: soc: add document for rockchip reboot notifier driver
>   soc: rockchip: add reboot notifier driver
>   ARM: dts: rockchip: add reboot node
>   ARM64: dts: rockchip: add reboot node
> 
>  .../bindings/soc/rockchip/rockchip-reboot.txt  | 18 
>  arch/arm/boot/dts/rk3288-veyron.dtsi   |  2 +-
>  arch/arm/boot/dts/rk3288.dtsi  |  6 ++
>  arch/arm/boot/dts/rk3xxx.dtsi  |  6 ++
>  arch/arm64/boot/dts/rockchip/rk3368.dtsi   |  6 ++
>  drivers/soc/rockchip/Kconfig   |  7 ++
>  drivers/soc/rockchip/Makefile  |  1 +
>  drivers/soc/rockchip/loader.h  | 22 +
>  drivers/soc/rockchip/reboot.c  | 98
> ++ 9 files changed, 165 insertions(+), 1 deletion(-)
>  create mode 100644
> Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt create
> mode 100644 drivers/soc/rockchip/loader.h
>  create mode 100644 drivers/soc/rockchip/reboot.c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: dts: Fix typo in rk3368 card detect binding

[Heiko Stübner]

Hi Matthias,

Am Freitag, 11. Dezember 2015, 14:22:19 schrieb Matthias Brugger:
> The card detect pin is called sdmcc-cd.
> This patch fixes the typo and renames the pin to sdmmc-cd.
> 
> Signed-off-by: Matthias Brugger 

applied to my arm64 dts branch, after fixing up the subject.


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] arm64: dts: rockchip: change the correct voltage range for rk3368 evb board

[Heiko Stübner]

Hi Caesar,

Am Mittwoch, 2. Dezember 2015, 19:12:20 schrieb Caesar Wang:
> In general, the logic voltage is affected by ddr frequency factors.
> We should fix the correct voltage range since assuemd that we have the
> ddr frequency driver in mainline.
> 
> AFAIK, the 1.8v voltage is used by the SD3.0 card.
> 
> Signed-off-by: Caesar Wang 

applied both patches to the 32 and 64 bit dts branches for 4.5


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: rockchip: correct the name of REG8 for rk3288-evb-act8846

[Heiko Stübner]

Hi Chris

Am Donnerstag, 10. Dezember 2015, 13:46:37 schrieb Chris Zhong:
> According to the schematic, the name of REG8 should be vcc_tp, rather
> than vcca_tp.
> 
> Signed-off-by: Chris Zhong 

applied all 3 to my dts32 branch for 4.5
[after making ARM in patch3 upper case ;-) ]


Thanks for keeping both board variants in sync
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/4] ARM: dts: rockchip: add core rk3228 dtsi

[Heiko Stübner]

Hi Jeffy,

Am Freitag, 11. Dezember 2015, 09:30:51 schrieb Jeffy Chen:
> Initial release for rk3228 shared dtsi.
> 
> Signed-off-by: Jeffy Chen 

Booth dts look good now, just need to wait on Linus Walleij picking up the 
pinctrl patch first.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 7/8] ARM: dts: rockchip: add core rk3228 dtsi

[Heiko Stübner]

Hi Jeffy,

Am Freitag, 11. Dezember 2015, 09:53:59 schrieb Jeffy Chen:
> On 2015-12-10 8:32, Heiko Stuebner wrote:
> > Am Mittwoch, 9. Dezember 2015, 17:04:12 schrieb Jeffy Chen:
> >> Initial release for rk3228 shared dtsi.
> >> 
> >> Signed-off-by: Jeffy Chen 
> >> ---
> >> 
> >>   arch/arm/boot/dts/rk3228.dtsi | 478
> >>   ++ 1 file changed, 478
> >>   insertions(+)
> >>   create mode 100644 arch/arm/boot/dts/rk3228.dtsi
> >> 
> >> diff --git a/arch/arm/boot/dts/rk3228.dtsi
> >> b/arch/arm/boot/dts/rk3228.dtsi
> >> new file mode 100644
> >> index 000..d6b3e40
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/rk3228.dtsi
> >> @@ -0,0 +1,478 @@
> >> +/*
> >> + * This file is dual-licensed: you can use it either under the terms
> >> + * of the GPL or the X11 license, at your option. Note that this dual
> >> + * licensing only applies to this file, and not this project as a
> >> + * whole.
> >> + *
> >> + *  a) This file is free software; you can redistribute it and/or
> >> + * modify it under the terms of the GNU General Public License as
> >> + * published by the Free Software Foundation; either version 2 of
> >> the
> >> + * License, or (at your option) any later version.
> >> + *
> >> + * This file is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * Or, alternatively,
> >> + *
> >> + *  b) Permission is hereby granted, free of charge, to any person
> >> + * obtaining a copy of this software and associated documentation
> >> + * files (the "Software"), to deal in the Software without
> >> + * restriction, including without limitation the rights to use,
> >> + * copy, modify, merge, publish, distribute, sublicense, and/or
> >> + * sell copies of the Software, and to permit persons to whom the
> >> + * Software is furnished to do so, subject to the following
> >> + * conditions:
> >> + *
> >> + * The above copyright notice and this permission notice shall be
> >> + * included in all copies or substantial portions of the Software.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> >> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> >> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> >> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> >> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> >> + * OTHER DEALINGS IN THE SOFTWARE.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include "skeleton.dtsi"
> >> +
> >> +/ {
> >> +  compatible = "rockchip,rk3228";
> >> +
> >> +  interrupt-parent = <&gic>;
> >> +
> >> +  aliases {
> >> +  serial0 = &uart0;
> >> +  serial1 = &uart1;
> >> +  serial2 = &uart2;
> >> +  };
> >> +
> >> +  memory {
> >> +  device_type = "memory";
> >> +  reg = <0x6000 0x4000>;
> >> +  };
> > 
> > The amount of memory is a property of the board
> 
> done.
> 
> >> +
> >> +  cpus {
> >> +  #address-cells = <1>;
> >> +  #size-cells = <0>;
> > 
> > no enable-method?
> > 
> > As the rk3228 also does not have a pmu, does the newly created
> > "rockchip,rk3036-smp" work for you?
> 
> unlucky, that doesn't work...and our 3.10 kernel is using psci for
> rk3228's smp ops, maybe i should check that too, but i know nothing
> about psci for now :(

Using PSCI on more rockchip socs will make the ARM people very happy ;-) .

So definitly no argument from me against it. I guess you should only need the 
enable-method and psci node you should already have in your 3.10 dts, to 
actually enable it.

cpu@xxx {
enable-method = "psci";
};

psci {
compatible = "arm,psci-0.2";
...
};


But we can of course add that in a later patch as well.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 0/17] Add Analogix Core Display Port Driver

[Heiko Stübner]

Hi Yakir,

Am Mittwoch, 9. Dezember 2015, 11:49:10 schrieb Yakir Yang:
> Thanks a lot for great debugging.
> 
> On 12/08/2015 11:33 PM, Heiko Stübner wrote:
> > Hi Yakir,
> > 
> > Am Montag, 7. Dezember 2015, 14:37:19 schrieb Yakir Yang:
> >> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> >> 
> >> share the same IP, so a lot of parts can be re-used. I split the common
> >> code into bridge directory, then rk3288 and exynos only need to keep
> >> some platform code. Cause I can't find the exact IP name of exynos dp
> >> controller, so I decide to name dp core driver with "analogix" which I
> >> find in rk3288 eDP TRM
> > 
> > [...]
> > 
> >> Changes in v10:
> >> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
> >> (Heiko) - Fix the wrong macro value of
> >> GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(4) -> BIT(20)
> >> - Remove the surplus "plat_data" check. (Heiko)
> >> -   switch (dp->plat_data && dp->plat_data->dev_type) {
> >> +   switch (dp->plat_data->dev_type) {
> >> 
> >> - Revert parts of Gustavo Padovan's changes in commit:
> >>drm/exynos: do not start enabling DP at bind() phase
> >>
> >>Add dp phy poweron function in bind time.
> > 
> > The hotplug issue is still present, but I think I found the cause. When
> > the first detect call happens, the display simply is still off. I just did
> > some very basic tracing [0] and it seems the display simply is not enabled
> > when it is supposed to get detected.
> 
> Aha, thanks, make a lot of sense.
> 
> > And it seems injecting a drm_panel_prepare early for _testing_ [1] really
> > did make the hotplug work on both my jerry and minnie.
> > 
> > So I guess we should somehow make sure the panel is actually powered when
> > detection is running. Although I'm not sure yet, how that should look
> > like.
> 
> Agree, panel should be powered up before DP controller start to detect
> hotplug signal.
> 
> > Intuition suggests, making drm_panel calls nestable (similar to
> > clk_prepare/unprepare, etc) and simply wrapping the detection code
> > in a prepare-unprepare calls, but I'm not sure if Thierry might have other
> > ideas ;-)
> 
> Due to the panel power status would influence the hotplug status, so I
> think we don't
> need to unprepared the panel unless in driver enter into suspend time.
> Things I want:
> 
> 1. Prepared the panel in driver *bind time*
> 2. Enable the panel in driver *bridge->enable time*
> 3. Disable the panel in driver *bridge->disable time*
> 4. Unprepared the panel in driver*suspend time *
> 5. Re-prepared the panel in driver *resume time*
6. Unprepare the panel in driver at *unbind time*

otherwise going that way looks nice.


> > Also my "log" below suggests some sort of mismatch between
> > prepare/unprepare calls, as there are a lot more of the prepare-side.
> 
> Yes, it's a typo too. I shouldn't place the panel->prepare in
> connector->get_modes,
> cause userspace would try to call get_modes once it receive the hotplug
> event, so
> there wouldn't have a match between panel prepare/unprepare.
> 
> Previously, I just want to ensure that panel should be power-up when
> driver try to
> read the EDID from panel, so for now must remove the prepare from
> get_modes time  :)
> 
> > And the locking issue also seems to be still there [2].
> 
> Hmm, I haven't meet this dead lock on my chromebook (ChromeOS + 4.4-rc3
> Kernel)
> 
> After look at the dead lock trace, I guess this dead lock would happened
> when hotplug
> event happened in bridge->disable time, not sure.  Would try to find
> more in trace log
> and try to reproduce this.

It is not an actual deadlock, but a warning that a deadlock might happen.
So you need to have LOCKDEP on. My kernels are currently running with

CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_ATOMIC_SLEEP=y

and I see this mostly when changing between X11, console and back to X11.


Heiko

> > Heiko
> > 
> > 
> > [0]
> > [2.797383] analogix_dp_reset
> > [2.800709] analogix_dp_init_hpd
> > [2.803960] analogix_dp_init_video
> > [2.807653] rockchip-drm display-subsystem: bound ff97.dp (ops
> > rockchip_dp_component_ops) [2.817176] [drm] Supports vblank timestamp
> > caching Rev 2 (21.10.2013). [2.823799] [drm] No driver support for
>

Re: [PATCH v1 1/8] pinctrl: rockchip: add support for the rk3228

[Heiko Stübner]

Hi Jeffy,

Am Mittwoch, 9. Dezember 2015, 17:04:06 schrieb Jeffy Chen:
> The pinctrl of rk3228 is much the same as rk3288's, but
> without pmu.
> 
> Signed-off-by: Jeffy Chen 

After verifying the offset and register-layout values with the TRM

Reviewed-by: Heiko Stuebner 


I just love how that still seems to fit for new socs ;-)


Thanks
Heiko


> ---
> 
>  .../bindings/pinctrl/rockchip,pinctrl.txt  |  3 +-
>  drivers/pinctrl/pinctrl-rockchip.c | 53
> ++ 2 files changed, 55 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
> 391ef4b..0cd701b 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> @@ -21,7 +21,8 @@ defined as gpio sub-nodes of the pinmux controller.
>  Required properties for iomux controller:
>- compatible: one of "rockchip,rk2928-pinctrl",
> "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl",
> "rockchip,rk3188-pinctrl"
> -"rockchip,rk3288-pinctrl", "rockchip,rk3368-pinctrl"
> +"rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
> +"rockchip,rk3368-pinctrl"
>- rockchip,grf: phandle referencing a syscon providing the
>"general register files"
> 
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> b/drivers/pinctrl/pinctrl-rockchip.c index a065112..faab36e 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -614,6 +614,40 @@ static void rk3288_calc_drv_reg_and_bit(struct
> rockchip_pin_bank *bank, }
>  }
> 
> +#define RK3228_PULL_OFFSET   0x100
> +
> +static void rk3228_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
> + int pin_num, struct regmap **regmap,
> + int *reg, u8 *bit)
> +{
> + struct rockchip_pinctrl *info = bank->drvdata;
> +
> + *regmap = info->regmap_base;
> + *reg = RK3228_PULL_OFFSET;
> + *reg += bank->bank_num * RK3188_PULL_BANK_STRIDE;
> + *reg += ((pin_num / RK3188_PULL_PINS_PER_REG) * 4);
> +
> + *bit = (pin_num % RK3188_PULL_PINS_PER_REG);
> + *bit *= RK3188_PULL_BITS_PER_PIN;
> +}
> +
> +#define RK3228_DRV_GRF_OFFSET0x200
> +
> +static void rk3228_calc_drv_reg_and_bit(struct rockchip_pin_bank *bank,
> + int pin_num, struct regmap **regmap,
> + int *reg, u8 *bit)
> +{
> + struct rockchip_pinctrl *info = bank->drvdata;
> +
> + *regmap = info->regmap_base;
> + *reg = RK3228_DRV_GRF_OFFSET;
> + *reg += bank->bank_num * RK3288_DRV_BANK_STRIDE;
> + *reg += ((pin_num / RK3288_DRV_PINS_PER_REG) * 4);
> +
> + *bit = (pin_num % RK3288_DRV_PINS_PER_REG);
> + *bit *= RK3288_DRV_BITS_PER_PIN;
> +}
> +
>  #define RK3368_PULL_GRF_OFFSET   0x100
>  #define RK3368_PULL_PMU_OFFSET   0x10
> 
> @@ -2143,6 +2177,23 @@ static struct rockchip_pin_ctrl rk3188_pin_ctrl = {
>   .pull_calc_reg  = rk3188_calc_pull_reg_and_bit,
>  };
> 
> +static struct rockchip_pin_bank rk3228_pin_banks[] = {
> + PIN_BANK(0, 32, "gpio0"),
> + PIN_BANK(1, 32, "gpio1"),
> + PIN_BANK(2, 32, "gpio2"),
> + PIN_BANK(3, 32, "gpio3"),
> +};
> +
> +static struct rockchip_pin_ctrl rk3228_pin_ctrl = {
> + .pin_banks  = rk3228_pin_banks,
> + .nr_banks   = ARRAY_SIZE(rk3228_pin_banks),
> + .label  = "RK3228-GPIO",
> + .type   = RK3288,
> + .grf_mux_offset = 0x0,
> + .pull_calc_reg  = rk3228_calc_pull_reg_and_bit,
> + .drv_calc_reg   = rk3228_calc_drv_reg_and_bit,
> +};
> +
>  static struct rockchip_pin_bank rk3288_pin_banks[] = {
>   PIN_BANK_IOMUX_FLAGS(0, 24, "gpio0", IOMUX_SOURCE_PMU,
>IOMUX_SOURCE_PMU,
> @@ -2220,6 +2271,8 @@ static const struct of_device_id
> rockchip_pinctrl_dt_match[] = { .data = (void *)&rk3066b_pin_ctrl },
>   { .compatible = "rockchip,rk3188-pinctrl",
>   .data = (void *)&rk3188_pin_ctrl },
> + { .compatible = "rockchip,rk3228-pinctrl",
> + .data = (void *)&rk3228_pin_ctrl },
>   { .compatible = "rockchip,rk3288-pinctrl",
>   .data = (void *)&rk3288_pin_ctrl },
>   { .compatible = "rockchip,rk3368-pinctrl",

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 0/17] Add Analogix Core Display Port Driver

[Heiko Stübner]

Hi Yakir,

Am Montag, 7. Dezember 2015, 14:37:19 schrieb Yakir Yang:
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM

[...]

> Changes in v10:
> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
> (Heiko) - Fix the wrong macro value of
> GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(4) -> BIT(20)
> - Remove the surplus "plat_data" check. (Heiko)
> -   switch (dp->plat_data && dp->plat_data->dev_type) {
> +   switch (dp->plat_data->dev_type) {
> - Revert parts of Gustavo Padovan's changes in commit:
>   drm/exynos: do not start enabling DP at bind() phase
>   Add dp phy poweron function in bind time.

The hotplug issue is still present, but I think I found the cause. When
the first detect call happens, the display simply is still off. I just did
some very basic tracing [0] and it seems the display simply is not enabled
when it is supposed to get detected.

And it seems injecting a drm_panel_prepare early for _testing_ [1] really
did make the hotplug work on both my jerry and minnie.

So I guess we should somehow make sure the panel is actually powered when
detection is running. Although I'm not sure yet, how that should look like.


Intuition suggests, making drm_panel calls nestable (similar to
clk_prepare/unprepare, etc) and simply wrapping the detection code
in a prepare-unprepare calls, but I'm not sure if Thierry might have other
ideas ;-)


Also my "log" below suggests some sort of mismatch between
prepare/unprepare calls, as there are a lot more of the prepare-side.


And the locking issue also seems to be still there [2].


Heiko


[0]
[2.797383] analogix_dp_reset
[2.800709] analogix_dp_init_hpd
[2.803960] analogix_dp_init_video
[2.807653] rockchip-drm display-subsystem: bound ff97.dp (ops 
rockchip_dp_component_ops)
[2.817176] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.823799] [drm] No driver support for vblank timestamp query.
[2.829947] analogix_dp_detect
[2.833015] analogix_dp_get_plug_in_status: hpd status 0
...
[2.893425] analogix_dp_get_plug_in_status: hpd status 0
[2.893456] rockchip-dp ff97.dp: failed to get hpd plug status, try to 
force hpd
[2.893458] analogix_dp_force_hpd
[2.893464] analogix_dp_get_plug_in_status: hpd status 112
[2.893470] panel_simple_prepare
[2.952183] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[2.961727] panel_simple_get_modes
[3.432154] analogix_dp_detect
[3.432158] analogix_dp_get_plug_in_status: hpd status 120
[3.432160] panel_simple_prepare
[3.433731] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[3.443268] panel_simple_get_modes
[3.444668] panel_simple_prepare
[3.444755] analogix_dp_reset
[3.445078] analogix_dp_init_hpd
[3.445096] panel_simple_disable
[3.455349] analogix_dp_init_video
[3.558323] rockchip-dp ff97.dp: Timeout of video streamclk ok
[3.558326] rockchip-dp ff97.dp: unable to config video
[3.558328] panel_simple_enable
[3.573915] analogix_dp_detect
[3.573919] analogix_dp_get_plug_in_status: hpd status 72
[3.573921] panel_simple_prepare


[1]
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 3990951..0c2dca5 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -399,6 +399,8 @@ static int rockchip_dp_probe(struct platform_device *pdev)
 
dp->plat_data.panel = panel;
 
+drm_panel_prepare(dp->plat_data.panel);
+
/*
 * We just use the drvdata until driver run into component
 * add function, and then we would set drvdata to null, so


[2]
[   11.971277] panel_simple_get_modes
[  OK  ] Started LSB: X display manager for KDE.
[  OK  ] Started LSB: Speech Dispatcher.
[   12.007120] panel_simple_disable
[   12.012323] 
[   12.013820] ==
[   12.019993] [ INFO: possible circular locking dependency detected ]
[   12.026250] 4.4.0-rc3+ #2755 Not tainted
[   12.030165] ---
[  12.036417] Xorg/793 is trying to acquire lock:
[   12.040855]  ((&dp->hotplug_work)){+.+...}[   12.040870] 
[   12.040870] but task is already holding lock:
[   12.040871]  (crtc_ww_class_mutex){+.+.+.}, at: [] 
drm_modeset_lock+0x84/0x104
[   12.040881] 
[   12.040881] which lock already depends on the new lock.
[   12.040881] 
[   12.040882] 
[   12.040882] the existing dependency chain (in reverse order) is:
[   12.040883] 
[   12.040883] -> #2 (crtc_ww_class_m

Re: [PATCH 0/3] Add the rk3368 evb board with the act8846 pmic

[Heiko Stübner]

Hi Caesar,

Am Dienstag, 1. Dezember 2015, 17:13:23 schrieb Caesar Wang:
> This series pacthes try to add the evb dts for rk3368 SoCs,
> This's similar with the rj3288 evb board.
> 
> On the moment, pwm/backlight/usb/thermal/emmc stuff can work for this
> board, I add the base version for the future firstly.
applied all 3 to relevant branches for 4.5, with some small changes:

> PATCH [1/3]: Force rk3368 PWM clock (and its parents) On
> That's similar HACK way to work.
shortened the comment in the code a bit

> PATCH [2/3]: Add the RK3368 EVB board for with the act8846 pmic for dtsi
Moved some minor stuff around a bit (ordering, etc)

> PATCH [3/3]: Add the PWM node info for rk3368 core.
this now comes before the addition of the evb files


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] dt-bindings: soc: add document for rockchip reboot notifier driver

[Heiko Stübner]

Hi Andy,

Am Dienstag, 1. Dezember 2015, 23:10:15 schrieb Andy Yan:
> 2015-11-23 21:15 GMT+08:00 Andy Yan :
> > 2015-11-20 9:58 GMT+08:00 Rob Herring :
> >> On Thu, Nov 19, 2015 at 7:16 PM, Andy Yan 
> >> 
> >> wrote:
> >> > On 2015年11月19日 12:35, Heiko Stuebner wrote:
> >> >> Am Donnerstag, 19. November 2015, 09:17:37 schrieb Andy Yan:
> >> >>> On 2015年11月19日 06:59, Rob Herring wrote:
> >>  On Wed, Nov 18, 2015 at 05:53:30PM +0800, Andy Yan wrote:
> >> > Add devicetree binding document for rockchip reboot nofifier driver
> >>  
> >>  Just reading the subject this is way too specific to the Linux
> >>  driver
> >>  needs rather than a h/w description. Please don't create fake DT
> >> 
> >> nodes
> >> 
> >>  just to bind to drivers. Whatever &pmu is is probably what should
> >> 
> >> have
> >> 
> >>  the DT node. Let the driver for it create child devices if you need
> >>  that.
> >>  
> >> >>>   This is note a fake DT nodes, we really need it to tell the
> >> 
> >> driver
> >> 
> >> >>>which register to use to store the reboot mode. Because
> >> 
> >> rockchip
> >> 
> >> >>>use different register file to store the reboot mode on
> >> 
> >> different
> >> 
> >> >>>platform, on rk3066,rk3188, rk3288,it use  one of the PMU
> >> >>> 
> >> >>> register, on
> >> >>> 
> >> >>>the incoming RK3036, it use one of the GRF register, and it
> >> >>>use
> >> >>> 
> >> >>> one  of
> >> >>> 
> >> >>>the PMUGRF register for arm64 platform rk3368. On the other
> >> 
> >> hand,
> >> 
> >> >>> the
> >> >>> 
> >> >>>PMU/GRF/PMUGRF register file are mapped as "syscon", then
> >> >>> 
> >> >>> referenced
> >> >>> 
> >> >>>by other DT nodes by phandle. So maybe let it as a separate DT
> >> >>> 
> >> >>> node here
> >> >>> 
> >> >>>is better.
> >> >> 
> >> >> or alternatively we could do something similar to what the bl-switcher
> >> >> cupfreq-driver does. Take a look at
> >> >> 
> >> >> drivers/cpufreq/arm_big_little.c
> >> >> drivers/clk/clk-mb86s7x.c
> >> >> 
> >> >> We already have the core restart-handler code in the clock-tree, so
> >> 
> >> could
> >> 
> >> >> maybe simply do the
> >> >> 
> >> >> platform_device_register_simple("rockchip-reboot", -1, NULL,
> >> 
> >> 0);
> >> 
> >> >> in that common code?
> >> >> 
> >> >> Though I'm not yet sure how to get the platform-data. I guess one
> >> 
> >> option
> >> 
> >> >> would
> >> >> be to do things like the 3288 suspend code does
> >> >> (arch/arm/mach-rockchip/pm.c
> >> >> at the bottom), by having the per-soc-data in the driver and then
> >> 
> >> matching
> >> 
> >> >> against the pmu. Because the pmu is not part of the clock controller
> >> >> binding
> >> >> (and probably also shouldn't be).
> >> >> 
> >> >Thanks for your suggestion.
> >> >
> >> > I have read the code you list above, if we implement the reboot
> >> 
> >> notifier
> >> 
> >> > driver like this, the driver need to add much more code to find the
> >> > 
> >> > platform
> >> > 
> >> > data(like arch/arm/mach-rockhcip/pm.c), what's more, if we have a
> >> 
> >> new
> >> 
> >> > soc
> >> > 
> >> > in the future and the soc use a different register here, we need
> >> 
> >> modify
> >> 
> >> > the
> >> > 
> >> > driver to add a new platform data again, this will bring additional
> >> > 
> >> > work.
> >> > 
> >> > Use the DT node pass the register will make the driver code simple
> >> 
> >> and
> >> 
> >> > clear.
> >> > 
> >> > Is there any hurt to put this information in the DT?
> >> 
> >> Add the data you need to the PMU node. Then the PMU driver can get it
> >> and pass to the child driver.
> >> 
> >> Rob
> >> --
> >> 
> > Do you mean I should implement the DT node like this？
> >
> >diff --git a/arch/arm/boot/dts/rk3xxx.dtsi
> > 
> > b/arch/arm/boot/dts/rk3xxx.dtsi
> > index 7b14d7a..1735d09 100644
> > --- a/arch/arm/boot/dts/rk3xxx.dtsi
> > +++ b/arch/arm/boot/dts/rk3xxx.dtsi
> > @@ -103,12 +103,6 @@
> > 
> > };
> > 
> > };
> > 
> > -   reboot {
> > -   compatible = "rockchip,reboot";
> > -   rockchip,regmap = <&pmu>;
> > -   offset = <0x40>;
> > -   };
> > -
> > 
> > xin24m: oscillator {
> > 
> > compatible = "fixed-clock";
> > clock-frequency = <2400>;
> > 
> > @@ -249,7 +243,11 @@
> > 
> > pmu: pmu@20004000 {
> > 
> > compatible = "rockchip,rk3066-pmu", "syscon";
> > 
> > -   reg = <0x20004000 0x100>;
> > +  reg = <0x20004000 0x100>;
> > +  reboot {
> > +   compatible = "rockchip,reboot";
> > +   offset = <0x40>;
> > +   };
> > 
> > };
> > 
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> > index cd02229..8a9837a 100644
> > --

Re: [PATCH v5 4/4] ARM: dts: rockchip: Add Crypto node for rk3288

[Heiko Stübner]

Am Mittwoch, 25. November 2015, 13:43:33 schrieb Zain Wang:
> Add Crypto node for rk3288 including crypto controller and dma clk.
> 
> Signed-off-by: Zain Wang 
> Tested-by: Heiko Stuebner 

applied to my dts32 branch for 4.5 .

Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

[Heiko Stübner]

Am Mittwoch, 28. Oktober 2015, 16:56:01 schrieb Yakir Yang:
> There are some IP limit on rk3288 that only support 4 physical lanes
> of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 
> ---

[...]

> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
> 6307060..563ffb1d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device
> *dp) return;
>   }
> 
> - ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> -  dp->video_info.link_rate);
> + ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
> +  dp->video_info.max_link_rate);
>   if (ret) {
>   dev_err(dp->dev, "unable to do link train\n");
>   return;
> @@ -1156,16 +1156,25 @@ static int analogix_dp_dt_parse_pdata(struct
> analogix_dp_device *dp) struct device_node *dp_node = dp->dev->of_node;
>   struct video_info *video_info = &dp->video_info;
> 
> - if (of_property_read_u32(dp_node, "samsung,link-rate",
> -  &video_info->link_rate)) {
> - dev_err(dp->dev, "failed to get link-rate\n");
> - return -EINVAL;
> - }
> -
> - if (of_property_read_u32(dp_node, "samsung,lane-count",
> -  &video_info->lane_count)) {
> - dev_err(dp->dev, "failed to get lane-count\n");
> - return -EINVAL;
> + switch (dp->plat_data && dp->plat_data->dev_type) {

drivers/gpu/drm/bridge/analogix/analogix_dp_core.c: In function 
‘analogix_dp_dt_parse_pdata’:
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1191:10: warning: switch 
condition has boolean value [-Wswitch-bool]
  switch (dp->plat_data && dp->plat_data->dev_type) {
  ^

As I think we always will need to distinguish between implementations,
I guess it should be safe to exit with an error, it that implementation-data
is not available, like just doing before the switch a:

if (!dp->plat_data)
return -EINVAL;


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Heiko Stübner]

Hi Yakir,

Am Freitag, 27. November 2015, 09:20:44 schrieb Yakir Yang:
> Hi Heiko,
> 
> Thanks you for feedback, I do see some conflicts in Exynos Make/Kconfig
> file [02/17] and dtsi file [07/17] when I try to apply this series on
> 4.4-rc1
> branch.
> 
> Hmm... Due to I have update some patches to version 10 already, this
> series may be become harder to reviewed, should I just send the whole
> series out that update the version to v10.

yes, that might make sense, also because people are generally reluctant to 
fixup patches when simply reviewing/testing.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 08/17] drm: rockchip: dp: add rockchip platform dp driver

[Heiko Stübner]

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:27:45 schrieb Yakir Yang:
> Rockchip have three clocks for dp controller, we leave pclk_edp
> to analogix_dp driver control, and keep the sclk_edp_24m and
> sclk_edp in platform driver.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 
> ---

> diff --git a/drivers/gpu/drm/rockchip/Kconfig
> b/drivers/gpu/drm/rockchip/Kconfig index 35215f6..c2ba945 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
> for the Synopsys DesignWare HDMI driver. If you want to
> enable HDMI on RK3288 based SoC, you should selet this
> option.
> +
> +config ROCKCHIP_ANALOGIX_DP
> +tristate "Rockchip specific extensions for Analogix DP driver"
> +depends on DRM_ROCKCHIP
> +select DRM_ANALOGIX_DP
> +help

the indentation should probably be tabs here, ROCKCHIP_DW_HDMI also does it 
wrong it seems, but DRM_ROCKCHIP looks correct :-)


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Heiko Stübner]

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:21:59 schrieb Yakir Yang:
> Split the dp core driver from exynos directory to bridge directory,
> and rename the core driver to analogix_dp_*, rename the platform
> code to exynos_dp.
> 
> Beside the new analogix_dp driver would export four hooks.
> "analogix_dp_bind()" and "analogix_dp_unbind()"
> "analogix_dp_detect()" and "analogix_dp_get_modes()"
> 
> The bind/unbind symbols is used for analogix platform driver to connect
> with analogix_dp core driver. And the detect/get_modes is used for analogix
> platform driver to init the connector.
> 
> They reason why connector need register in helper driver is rockchip drm
> haven't implement the atomic API, but Exynos drm have implement it, so
> there would need two different connector helper functions, that's why we
> leave the connector register in helper driver.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 

[...]

> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index bd1a415..5f74f80 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -55,8 +55,9 @@ config DRM_EXYNOS_DSI
> This enables support for Exynos MIPI-DSI device.
> 
>  config DRM_EXYNOS_DP
> - bool "EXYNOS DRM DP driver support"
> + bool "EXYNOS specific extensions for Analogix DP driver"
>   depends on DRM_EXYNOS && (DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON)
> + select DRM_ANALOGIX_DP
>   default DRM_EXYNOS
>   select DRM_PANEL
>   help

This doesn't apply anymore to 4.4-rc due to other changes in there. The 
exynos/Makefile is affected as well.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 01/11] clk: rockchip: add id for mipidsi sclk on rk3288

[Heiko Stübner]

Hi Chris,

Am Donnerstag, 26. November 2015, 15:50:15 schrieb Chris Zhong:
> Adds a new id for the sclk supplying the mipidsi on rk3288 socs.
> 
> Signed-off-by: Chris Zhong 

applied this patch to my clock-branch for 4.5, after fixing the numbering to 
not conflict with the new crypto-clock.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] dt-bindings: rockchip-thermal: Support the RK3228/RK3399 SoCs compatible

[Heiko Stübner]

Am Mittwoch, 25. November 2015, 15:59:35 schrieb Caesar Wang:
> This patchset attempts to new compatible for thermal founding
> on RK3228/RK3399 SoCs.
> 
> Signed-off-by: Caesar Wang 
> ---
> 
>  Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index
> 0dfa60d..af5f802 100644
> --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> @@ -2,8 +2,10 @@
> 
>  Required properties:
>  - compatible : should be "rockchip,-tsadc"
> +   "rockchip,rk3228-tsadc": found on RK3228 SoCs
> "rockchip,rk3288-tsadc": found on RK3288 SoCs
> "rockchip,rk3368-tsadc": found on RK3368 SoCs
> +   "rockchip,rk3368-tsadc": found on RK3399 SoCs

copy'n'paste error, should proably be 
 "rockchip,rk3399-tsadc": found on RK3399 SoCs

>  - reg : physical base address of the controller and length of memory mapped
> region.
>  - interrupts : The interrupt number to the cpu. The interrupt specifier
> format

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/4] clk: rockchip: set an ID for crypto clk

[Heiko Stübner]

Hi Zain,

Am Mittwoch, 25. November 2015, 13:43:31 schrieb Zain Wang:
> Set an ID for crypto clk, so that it can be called in other part.
> 
> Signed-off-by: Zain Wang 
> Acked-by: Michael Turquette 
> Tested-by: Heiko Stuebner 

I've already taken this patch, so no need to resubmit on further version.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 0/6] Build and support rk3036 SoC platform

[Heiko Stübner]

Hi Xing Zheng,

Am Donnerstag, 5. November 2015, 15:33:54 schrieb Xing Zheng:
> Hi,
>   We need to support rk3036 soc platform via upstream, there are
> some primary parts for the initial release of minimum system: dts,
> clk-pll, smp, and clock tree for rk3036, and additional, we can use
> these startup and run to init processs.

[...]

after talking with Mike and agreeing that I'm again taking the regular
clock patches to them, I've applied all of this to appropriate branches.
I did some cosmetics, as explained below.


> Xing Zheng (6):
>   dt-bindings: add documentation of rk3036 clock controller
>   clk: rockchip: add dt-binding header for rk3036
>   clk: rockchip: add new pll-type for rk3036 and similar socs
- wrapped some overly long lines, otherwise this is similar to what
  Stephen already took for the rk3066-pll-type.


>   clk: rockchip: add clock controller for rk3036
>   ARM: dts: rockchip: add core rk3036 dts
- split off the evb into a separate patch
- reordered some nodes (please order by the address (the @)
- reordered some properties
- fixed the gic cpu masks


>   ARM: dts: enable smp for rk3036
folded into the core dtsi addition


Please take a final look at [0] to make sure I didn't mess up anything.


Thanks
Heiko


[0]
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.5-clk/next
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=v4.5-armsoc/dts32
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/4] clk: rockchip: set an ID for crypto clk

[Heiko Stübner]

Hi Zain,

Am Dienstag, 17. November 2015, 12:00:45 schrieb Zain Wang:
> Set an ID for crypto clk, so that it can be called in other part.
> 
> Signed-off-by: Zain Wang 
> Acked-by: Michael Turquette 
> Tested-by: Heiko Stuebner 

I've split this into the header and clk-rk3288.c changes and applied it to my 
clk-ids and clock branch for 4.5


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 01/13] clk: rockchip: add id for mipidsi sclk on rk3288

[Heiko Stübner]

Hi Chris,

Am Freitag, 20. November 2015, 16:15:27 schrieb Chris Zhong:
> Adds a new id for the sclk supplying the mipidsi on rk3288 socs.
> 
> Signed-off-by: Chris Zhong 
> 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> add the mipi clk id in a single patch
> 
>  include/dt-bindings/clock/rk3288-cru.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/dt-bindings/clock/rk3288-cru.h
> b/include/dt-bindings/clock/rk3288-cru.h index c719aac..b07cdd3 100644
> --- a/include/dt-bindings/clock/rk3288-cru.h
> +++ b/include/dt-bindings/clock/rk3288-cru.h
> @@ -86,6 +86,7 @@
>  #define SCLK_USBPHY480M_SRC  122
>  #define SCLK_PVTM_CORE   123
>  #define SCLK_PVTM_GPU124
> +#define SCLK_MIPI_24M125

in the TRM (and therefore in the clock-controller) this is labeled as
sclk_mipidsi_24m, so I'd think the clock-id shouls also contain the
DSI part as well, making it SCLK_MIPIDSI_24M


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: rockchip: Add IR receiver to Radxa Rock 2 Square

[Heiko Stübner]

Am Montag, 23. November 2015, 15:36:28 schrieb Sjoerd Simons:
> Add support for the IR receiver as present on the Radxa Rock 2 Square
> board.
> 
> Signed-off-by: Sjoerd Simons 

applied to my dts32 branch for 4.5.


Thanks
Heiko

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/3] ARM: dts: rockchip: Add the OTP gpio pinctrl

[Heiko Stübner]

Am Freitag, 23. Oktober 2015, 08:25:08 schrieb Doug Anderson:
> On Fri, Oct 23, 2015 at 4:25 AM, Caesar Wang  wrote:
> > Add the "init" anf "sleep" pinctrl as the OTP gpio state.
> > We need the OTP pin is gpio state before resetting the TSADC controller,
> > since the tshut polarity will generate a high signal.
> > 
> > "init" pinctrl property is defined by Doug's Patch[0].
> > 
> > Patch[0]:
> > https://patchwork.kernel.org/patch/7454311/
> > 
> > Signed-off-by: Caesar Wang 
> > Reviewed-by: Douglas Anderson 
> > ---
> > 
> > Changes in v4: None
> > 
> > Changes in v3:
> >   - Add the "sleep" pinctrl as the gpio state in PATCH[3/3]
> > 
> > Changes in v2:
> >   - Add some commits for more obvious in PATCH[2/2]
> > 
> > Changes in v1:
> >   - As the Doug comments, drop the thermal driver patchs since
> >   
> > we can with pinctrl changing to work.
> >   
> >   - As the Doug's patch to add the 'init' property.
> >  
> >  arch/arm/boot/dts/rk3288.dtsi | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> I realized that the subject of this patch should probably contain the
> word rk3288, but I presume Heiko would rather add that himself than
> for you to spin this again.  ;)

yep :-) ... no need to respin for such an easy change.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] Patches to fix remote wakeup on rk3288 dwc2 "host" port

[Heiko Stübner]

Am Freitag, 23. Oktober 2015, 11:28:07 schrieb Douglas Anderson:
> The "host1" port (AKA the dwc2 port that isn't the OTG port) on rk3288
> has a hardware errata that causes everything to get confused when we get
> a remote wakeup.  It appears that the "port reset" bit that's in the USB
> phy (located in the rk3288 GRF) fixes things up and appears safe to do.
> 
> This series of patches exports the "port reset" from the PHY and then
> hooks it up to dwc2 through a quirk.
> 
> I've tested this series atop a bit of a conglomeration of Heiko's github
> "somewhat stable" branch (v4.3-rc3-876-g6509232) but with Greg KH's
> usb-next merged in.

I've been involved in the earlier revisions already, so this version already 
implements the review-comments I had. I've also gave this a spin on 4.3-rc6 
with usb-next merged in on a rk3288-firefly, so

Reviewed-by: Heiko Stuebner 
Tested-by: Heiko Stuebner 


If the first two patches get picked up, I'll pick the two dts patches 
afterwards.


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] dt-bindings: Consolidate SRAM bindings from all vendors

[Heiko Stübner]

Am Freitag, 23. Oktober 2015, 10:39:19 schrieb Krzysztof Kozlowski:
> SRAM bindings for various SoCs, using the mmio-sram genalloc
> API, are spread over different places - per SoC vendor. Since all of
> these are quite similar (they depend on mmio-sram) move them to a common
> place.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Cc: Heiko Stuebner 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Kukjin Kim 
> Suggested-by: Rob Herring 
> 
> ---
> 
> Changes since v2:
> 1. Update paths to sram.txt.
> 
> Changes since v1:
> 1. New patch. Extended suggestion from Rob.
> ---

> .../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt} 
> .../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt} 

for the Rockchip parts
Acked-by: Heiko Stuebner 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/8] Add SPDIF support for rockchip

[Heiko Stübner]

Am Donnerstag, 8. Oktober 2015, 15:31:11 schrieb Sjoerd Simons:
> This patchset adds support for the Rockchip SPDIF transceiver as present
> on RK3066, RK3188 and RK3288 boards and enables it on a Radxa rock pro.
> Tested on a Radxa Rock Pro board and Radxa Rock 2 Square board.
> 
> Quite a few changes since v3 (mostly based on review comment). One
> important addition is proper RK3288 SoC support; While according to the
> documentation it has 2 SPDIF "solutions" with the default being the old
> one, this variation doesn't actually work.. So support has been added
> to switch to the new SPDIF solution on RK3288.

[...]

> Sjoerd Simons (8):
>   ASoC: dt-bindings: add rockchip tranceiver bindings
>   ASoC: rockchip: Add rockchip SPDIF transceiver driver
>   ARM: dts: rockchip: Add SPDIF transceiver for RK3188
>   ARM: dts: rockchip: Add SPDIF optical out on Radxa Rock
>   clk: rockchip: Allow the RK3288 SPDIF clocks to change their parent
>   ARM: dts: rockchip: Add SPDIF transceiver for RK3288
>   ARM: dts: rockchip: Add SPDIF optical out on Radxa Rock2 Square
>   ARM: multi_v7_defconfig: Add rockchip audio support

After Mark took the two ASoC-specific patches, I've now picked up the 4 dts 
patches, after removing the #address- and #size-cells lines from them.

Sjoerd, are you sending a followup patch to Mark to also drop them from the 
binding doc?

Hopefully the clock patch will also find its way into the clock tree, together 
with the base series for the frac dividers.

And I guess we'll need to prod the armsoc-guys to take the defconfig change 
too :-)


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2][UPDATE] ARM: dts: replace gpio-key,wakeup with wakeup-source property

[Heiko Stübner]

Am Dienstag, 13. Oktober 2015, 15:38:53 schrieb Sudeep Holla:
> Keyboard driver for GPIO buttons(gpio-keys) checks for the legacy
> "gpio-key,wakeup" boolean property to enable gpio buttons as wakeup
> source.
> 
> Few dts files assign value "1" to gpio-key,wakeup and in one instance a
> value "0" is assigned probably assuming it won't be enabled as a wakeup
> source. Since the presence of the boolean property indicates it is
> enabled, value of "0" have no value.
> 
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property which inturn fixes the above mentioned issue.
> 
> Cc: Heiko Stuebner 
> Cc: linux-rockc...@lists.infradead.org
> Cc: Viresh Kumar 
> Signed-off-by: Sudeep Holla 
> ---
>  arch/arm/boot/dts/rk3066a-bqcurie2.dts  | 3 +--
>  arch/arm/boot/dts/rk3066a-rayeager.dts  | 2 +-
>  arch/arm/boot/dts/rk3188-radxarock.dts  | 2 +-
>  arch/arm/boot/dts/rk3288-evb.dtsi   | 2 +-
>  arch/arm/boot/dts/rk3288-firefly.dtsi   | 2 +-
>  arch/arm/boot/dts/rk3288-popmetal.dts   | 2 +-
>  arch/arm/boot/dts/rk3288-r89.dts| 2 +-
[...]
>  arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 2 +-

Reviewed-by: Heiko Stuebner 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 10/17] phy: Add driver for rockchip Display Port PHY

[Heiko Stübner]

Am Montag, 12. Oktober 2015, 20:32:47 schrieb Kishon Vijay Abraham I:
> Hi,
> 
> On Saturday 10 October 2015 09:25 PM, Yakir Yang wrote:
> > This phy driver would control the Rockchip DisplayPort module
> > phy clock and phy power, it is relate to analogix_dp-rockchip
> > dp driver. If you want DP works rightly on rockchip platform,
> > then you should select both of them.
> 
> Add phy driver for the Rockchip DisplayPort PHY module. This is required
> to get DisplayPort working in Rockchip SoCs.
> 
> > Signed-off-by: Yakir Yang 
> > ---
> > Changes in v6: None
> > Changes in v5:
> > - Remove "reg" DT property, cause driver could poweron/poweroff phy via
> > 
> >   the exist "grf" syscon already. And rename the example DT node from
> >   "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> > 
> > - Add deivce_node at the front of driver, update phy_ops type from "static
> > 
> >   struct" to "static const struct". And correct the input paramters of
> >   devm_phy_create() interfaces. (Heiko)
> > 
> > Changes in v4:
> > - Add commit message, and remove the redundant rockchip_dp_phy_init()
> > 
> >   function, move those code to probe() method. And remove driver .owner
> >   number. (Kishon)
> > 
> > Changes in v3:
> > - Suggest, add rockchip dp phy driver, collect the phy clocks and
> > 
> >   power control. (Heiko)
> > 
> > Changes in v2: None
> > 
> >  drivers/phy/Kconfig   |   7 ++
> >  drivers/phy/Makefile  |   1 +
> >  drivers/phy/phy-rockchip-dp.c | 151
> >  ++ 3 files changed, 159
> >  insertions(+)
> >  create mode 100644 drivers/phy/phy-rockchip-dp.c
> > 
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 47da573..8f2bc4f 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
> > 
> > help
> > 
> >   Enable this to support the Rockchip USB 2.0 PHY.
> > 
> > +config PHY_ROCKCHIP_DP
> > +   tristate "Rockchip Display Port PHY Driver"
> > +   depends on ARCH_ROCKCHIP && OF
> > +   select GENERIC_PHY
> > +   help
> > + Enable this to support the Rockchip Display Port PHY.
> > +
> > 
> >  config PHY_ST_SPEAR1310_MIPHY
> >  
> > tristate "ST SPEAR1310-MIPHY driver"
> > select GENERIC_PHY
> > 
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index a5b18c1..e281f35 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+=
> > phy-s5pv210-usb2.o> 
> >  obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
> >  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
> >  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> > 
> > +obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
> > 
> >  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
> >  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
> >  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
> > 
> > diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> > new file mode 100644
> > index 000..3a2ac120
> > --- /dev/null
> > +++ b/drivers/phy/phy-rockchip-dp.c
> > @@ -0,0 +1,151 @@
> > +/*
> > + * Rockchip DP PHY driver
> > + *
> > + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> > + * Author: Yakir Yang 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define GRF_SOC_CON12   0x0274
> > +#define GRF_EDP_REF_CLK_SEL_INTER  BIT(4)
> > +#define GRF_EDP_PHY_SIDDQ_WRITE_EN  BIT(21)
> > +#define GRF_EDP_PHY_SIDDQ_ON0
> > +#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
> > +
> > +struct rockchip_dp_phy {
> > +   struct device  *dev;
> > +   struct regmap  *grf;
> > +   struct clk *phy_24m;
> > +};
> > +
> > +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> > +{
> > +   struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
> > +   int ret;
> > +
> > +   if (enable) {
> > +   ret = clk_prepare_enable(dp->phy_24m);
> > +   if (ret < 0) {
> > +   dev_err(dp->dev, "Can't enable clock 24m %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   ret = regmap_write(dp->grf, GRF_SOC_CON12,
> > +  GRF_EDP_PHY_SIDDQ_WRITE_EN |
> > +  GRF_EDP_PHY_SIDDQ_ON);
> > +   } else {
> > +   clk_disable_unprepare(dp->phy_24m);
> 
> should clk_disable come after regmap_write? It'll be symmetric to enable?
> 
> > +   ret = regmap_write(dp->grf, GRF_SOC_CON12,
> > + 

Re: [PATCH v4 5/8] clk: rockchip: Allow the RK3288 SPDIF clocks to change their parent

[Heiko Stübner]

Hi Sjoerd,

Am Freitag, 9. Oktober 2015, 13:35:55 schrieb Sjoerd Simons:
> On Thu, 2015-10-08 at 17:10 +0200, Heiko Stuebner wrote:
> > Am Donnerstag, 8. Oktober 2015, 15:31:16 schrieb Sjoerd Simons:
> > > The clock branches leading to sclk_spdif and sclk_spdif_8ch on
> > > RK3288
> > > SoCs only feed those clocks, allow those clocks to change their
> > > parents
> > > all the way up the hierarchy.
> > > 
> > > Signed-off-by: Sjoerd Simons 
> > 
> > Just as comment, if I'm seeing that right, this patch needs "clk:
> > rockchip:
> > handle mux dependency of fractional dividers" and friends [0] to
> > apply and
> > also actually handle the fractional dividers correctly.
> > 
> > For the clock change itself:
> > Reviewed-by: Heiko Stuebner 
> 
> Oh sorry yes, i completely forgot to at that as note on this patch
> (series). These are on top of your series as those are required to make
> things actually work as expected.
> 
> Which reminds me, i was wondering how to best move that forward. Could
> you pick this one up to include it in the next round of your series?
> (Otherwise i'm happy to rebase it once you do a v2)

I guess that will depend on how the core series gets handled. Aka if there 
needs to be a v2 (depending on the clock maintainers) I can pick that up as 
part of it. Otherwise we'll just need to ping the clock-maintainers separately 
on this patch if necessary.


Heiko

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] clocksource: rockchip: Make the driver more compatible

[Heiko Stübner]

Hi Daniel,

Am Dienstag, 29. September 2015, 06:18:03 schrieb Daniel Lezcano:
> On 09/25/2015 04:14 AM, Caesar Wang wrote:
> > Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
> > There are some failure with build up on timer driver for rockchip.
> > 
> > Says:
> > /tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand 1 --
> > `dsb`
> > ...
> > 
> > The problem was different semantics of dsb on btw arm32 and arm64,
> > Here we can convert the dsb with insteading of dsb(sy).The "sy" param
> > is the default which you are allow to omit, so on arm32 dsb()and dsb(sy)
> > are the same.
> > 
> > Signed-off-by: Caesar Wang 
> 
> Acked-by: Daniel Lezcano 

as you have "just" Acked these patches, I guess you are expecting them to go 
through the same tree as the devicetree changes, right?

Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/3] clocksource: rockchip: Make the driver more readability and compatible

[Heiko Stübner]

Hi Caesar,

Am Freitag, 18. September 2015, 16:51:09 schrieb Caesar Wang:
> Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
> There are some failure with build up on timer driver for rockchip.
> 
> logs:
> ...
> drivers/clocksource/rockchip_timer.c:156:13: error: 'NO_IRQ' undeclared
> /tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand 1 --
> `dsb`
> ...
> 
> The problem was different semantics of dsb on btw arm32 and arm64,
> Here we can convert the dsb with insteading of dsb(sy).
> 
> NO_IRQ definition is missing for ARM64, since NO_IRQ being -1 is a
> legacy thing for ARM - all ARM drivers are supposed to be converted to
> use <= 0 or == 0 to detect invalid IRQs, and _eventually_ once all users
> are gone, NO_IRQ deleted. Modern drivers should _all_ be using !irq to
> detect invalid IRQs, and not using NO_IRQ.
> 
> Meanwhile, I change a bit to make the code more readability for driver
> when I check the code style.
> 
> Signed-off-by: Caesar Wang 
> ---
> 
> Changes in v1:
> - As Russell, Thomas, Daniel comments, let's replace NO_IRQ by '!irq'.
> 
>  drivers/clocksource/rockchip_timer.c | 29 +++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/clocksource/rockchip_timer.c
> b/drivers/clocksource/rockchip_timer.c index bb2c2b0..e1af449 100644
> --- a/drivers/clocksource/rockchip_timer.c
> +++ b/drivers/clocksource/rockchip_timer.c
> @@ -17,16 +17,16 @@
> 
>  #define TIMER_NAME "rk_timer"
> 
> -#define TIMER_LOAD_COUNT0 0x00
> -#define TIMER_LOAD_COUNT1 0x04
> -#define TIMER_CONTROL_REG 0x10
> -#define TIMER_INT_STATUS 0x18
> +#define TIMER_LOAD_COUNT00x00
> +#define TIMER_LOAD_COUNT10x04
> +#define TIMER_CONTROL_REG0x10
> +#define TIMER_INT_STATUS 0x18
> 
> -#define TIMER_DISABLE 0x0
> -#define TIMER_ENABLE 0x1
> -#define TIMER_MODE_FREE_RUNNING (0 << 1)
> -#define TIMER_MODE_USER_DEFINED_COUNT (1 << 1)
> -#define TIMER_INT_UNMASK (1 << 2)
> +#define TIMER_DISABLE(0 << 0)
> +#define TIMER_ENABLE (1 << 0)
> +#define TIMER_MODE_FREE_RUNNING  (0 << 1)
> +#define TIMER_MODE_USER_DEFINED_COUNT(1 << 1)
> +#define TIMER_INT_UNMASK (1 << 2)

not sure how Daniel sees this, but those could count as "unrelated change", as 
they have nothing to do with the arm64 build-fixes.


> 
>  struct bc_timer {
>   struct clock_event_device ce;
> @@ -49,14 +49,14 @@ static inline void __iomem *rk_base(struct
> clock_event_device *ce) static inline void rk_timer_disable(struct
> clock_event_device *ce) {
>   writel_relaxed(TIMER_DISABLE, rk_base(ce) + TIMER_CONTROL_REG);
> - dsb();
> + dsb(sy);
>  }
> 
>  static inline void rk_timer_enable(struct clock_event_device *ce, u32
> flags) {
>   writel_relaxed(TIMER_ENABLE | TIMER_INT_UNMASK | flags,
>  rk_base(ce) + TIMER_CONTROL_REG);
> - dsb();
> + dsb(sy);
>  }
> 
>  static void rk_timer_update_counter(unsigned long cycles,
> @@ -64,13 +64,13 @@ static void rk_timer_update_counter(unsigned long
> cycles, {
>   writel_relaxed(cycles, rk_base(ce) + TIMER_LOAD_COUNT0);
>   writel_relaxed(0, rk_base(ce) + TIMER_LOAD_COUNT1);
> - dsb();
> + dsb(sy);
>  }
> 
>  static void rk_timer_interrupt_clear(struct clock_event_device *ce)
>  {
>   writel_relaxed(1, rk_base(ce) + TIMER_INT_STATUS);
> - dsb();
> + dsb(sy);
>  }
> 
>  static inline int rk_timer_set_next_event(unsigned long cycles,
> @@ -148,7 +148,7 @@ static void __init rk_timer_init(struct device_node *np)
> bc_timer.freq = clk_get_rate(timer_clk);
> 
>   irq = irq_of_parse_and_map(np, 0);
> - if (irq == NO_IRQ) {
> + if (!irq) {
>   pr_err("Failed to map interrupts for '%s'\n", TIMER_NAME);
>   return;
>   }
> @@ -173,4 +173,5 @@ static void __init rk_timer_init(struct device_node *np)
> 
>   clockevents_config_and_register(ce, bc_timer.freq, 1, UINT_MAX);
>  }
> +

unnecessary addition of a blank line (same reasons as above)
>  CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer", rk_timer_init);


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: dts: rockchip: Add dtb for the Radxa Rock 2 Square board

[Heiko Stübner]

Hi Sjoerd,

Am Dienstag, 15. September 2015, 08:57:21 schrieb Sjoerd Simons:
> The Radxa Rock 2 Square board is a combination of the Radxa Rock 2 SoM
> with the Square baseboard. Add a dtsi for the SoM which can be included
> into the dts for the various baseboards (e.g. full and square) and a dts
> for the square board.
> 
> Currently supported are serial console, wired networking, hdmi output,
> eMMC and SD storage and USB.
> 
> Signed-off-by: Sjoerd Simons 

applied to my dts32 branch for 4.4 with the following small changes:

- &vop{b/l}(_mmu) nodes only in the som.dtsi
  -> removed duplicates
- moved &tsadc and &wdt to alphabetical order


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] arm64: dts: rockchip: Add the needed timer for rk3368 SoC

[Heiko Stübner]

Am Donnerstag, 17. September 2015, 15:51:12 schrieb Caesar Wang:
> There is a need of a broadcast timer in this case to ensure proper
> wakeup when the cpus are in sleep mode and a timer expires.
> 
> Signed-off-by: Caesar Wang 
> ---
> 
>  arch/arm64/boot/dts/rockchip/rk3368.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3368.dtsi index a712bea..99edbaa 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> @@ -214,6 +214,12 @@
>   (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
>   };
> 
> + timer@ff81 {
> + compatible = "rockchip,rk3288-timer";

you probably want a
compatible = "rockchip,rk3368-timer", "rockchip,rk3288-timer";

> + reg = <0x0 0xff81 0x0 0x20>;
> + interrupts = ;
> + };
> +
>   xin24m: oscillator {
>   compatible = "fixed-clock";
>   clock-frequency = <2400>;

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/9] dt-bindings: add documentation of rk3036 clock controller

[Heiko Stübner]

Am Donnerstag, 17. September 2015, 18:32:49 schrieb Xing Zheng:
> Add the devicetree binding for the cru on the rk3036 which quite similar
> structured as previous clock controllers.
> 
> Signed-off-by: Xing Zheng 
> ---
> 
> Changes in v2: None
> 
>  .../bindings/clock/rockchip,rk3036-cru.txt |   60
>  1 file changed, 60 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
> b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt new file
> mode 100644
> index 000..ac3037a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
> @@ -0,0 +1,60 @@
> +* Rockchip RK3036 Clock and Reset Unit
> +
> +The RK3036 clock controller generates and supplies clock to various
> +controllers within the SoC and also implements a reset controller for SoC
> +peripherals.
> +
> +Required Properties:
> +
> +- compatible: should be "rockchip,rk3036-cru"
> +- reg: physical base address of the controller and length of memory mapped
> +  region.
> +- #clock-cells: should be 1.
> +- #reset-cells: should be 1.
> +
> +Optional Properties:
> +
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +  If missing pll rates are not changable, due to the missing pll lock
> status. +
> +Each clock is assigned an identifier and client nodes can use this
> identifier +to specify the clock which they consume. All available clocks
> are defined as +preprocessor macros in the dt-bindings/clock/rk3036-cru.h
> headers and can be +used in device tree sources. Similar macros exist for
> the reset sources in +these files.
> +
> +External clocks:
> +
> +There are several clocks that are generated outside the SoC. It is expected
> +that they are defined using standard clock bindings with following
> +clock-output-names:
> + - "xin24m" - crystal input - required,
> + - "xin32k" - rtc clock - optional,

The rk3036 does not seem to use a rtc clock, so this should probably go away

> + - "ext_i2s" - external I2S clock - optional,

> + - "ext_hsadc" - external HSADC clock - optional,
> + - "ext_vip" - external VIP clock - optional,
> + - "ext_isp" - external ISP clock - optional,
> + - "ext_jtag" - external JTAG clock - optional
There do not seem to exist external clock sources for hsadc, vip, isp and jtag 
in your clock tree?

missing here:
- ext_gmac

> +
> +Example: Clock controller node:
> +
> + cru: cru@2000 {
> + compatible = "rockchip,rk3036-cru";
> + reg = <0x2000 0x1000>;
> + rockchip,grf = <&grf>;
> +
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> +Example: UART controller node that consumes the clock generated by the
> clock +  controller:
> +
> + uart0: serial@2006 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x2006 0x100>;
> + interrupts = ;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&cru SCLK_UART0>;
> + };

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/9] pinctrl: rockchip: add support for the rk3036

[Heiko Stübner]

Am Donnerstag, 17. September 2015, 18:34:20 schrieb Xing Zheng:
> Add new type for rk3036 and many parts of pinctrl rk3036 are similar
> with rk2928's.
> 
> Signed-off-by: Xing Zheng 

very nice that the rk3036 pin-controller works with already established 
infrastructure :-)

Reviewed-by: Heiko Stuebner 

> ---
> 
> Changes in v2: None
> 
>  .../bindings/pinctrl/rockchip,pinctrl.txt  |1 +
>  drivers/pinctrl/pinctrl-rockchip.c |   17 +
> 2 files changed, 18 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
> 391ef4b..c73f2bb 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> @@ -22,6 +22,7 @@ Required properties for iomux controller:
>- compatible: one of "rockchip,rk2928-pinctrl",
> "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl",
> "rockchip,rk3188-pinctrl"
>  "rockchip,rk3288-pinctrl", "rockchip,rk3368-pinctrl"
> +"rockchip,rk3036-pinctrl"
>- rockchip,grf: phandle referencing a syscon providing the
>"general register files"
> 
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> b/drivers/pinctrl/pinctrl-rockchip.c index c5246c0..9c49510 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -2089,6 +2089,21 @@ static struct rockchip_pin_ctrl rk2928_pin_ctrl = {
>   .pull_calc_reg  = rk2928_calc_pull_reg_and_bit,
>  };
> 
> +static struct rockchip_pin_bank rk3036_pin_banks[] = {
> + PIN_BANK(0, 32, "gpio0"),
> + PIN_BANK(1, 32, "gpio1"),
> + PIN_BANK(2, 32, "gpio2"),
> +};
> +
> +static struct rockchip_pin_ctrl rk3036_pin_ctrl = {
> + .pin_banks  = rk3036_pin_banks,
> + .nr_banks   = ARRAY_SIZE(rk3036_pin_banks),
> + .label  = "RK3036-GPIO",
> + .type   = RK2928,
> + .grf_mux_offset = 0xa8,
> + .pull_calc_reg  = rk2928_calc_pull_reg_and_bit,
> +};
> +
>  static struct rockchip_pin_bank rk3066a_pin_banks[] = {
>   PIN_BANK(0, 32, "gpio0"),
>   PIN_BANK(1, 32, "gpio1"),
> @@ -2207,6 +,8 @@ static struct rockchip_pin_ctrl rk3368_pin_ctrl = {
>  static const struct of_device_id rockchip_pinctrl_dt_match[] = {
>   { .compatible = "rockchip,rk2928-pinctrl",
>   .data = (void *)&rk2928_pin_ctrl },
> + { .compatible = "rockchip,rk3036-pinctrl",
> + .data = (void *)&rk3036_pin_ctrl },
>   { .compatible = "rockchip,rk3066a-pinctrl",
>   .data = (void *)&rk3066a_pin_ctrl },
>   { .compatible = "rockchip,rk3066b-pinctrl",

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/9] Build and support rk3036 SoC platform

[Heiko Stübner]

Hi,

Am Donnerstag, 17. September 2015, 16:28:51 schrieb Xing Zheng:
> we need to support rk3036 soc platform via upstream, there are
> 3 primary parts for the initial release of minimum system: dts,
> pinctrl, and clock tree for rk3036, and additional, add a rtc
> hym8563 patch to fix initial invaild, we can use these startup
> and run to init processs.
> 
> Thanks.
> 
> changed in v2:
> - based on v1, add clock controller documentation
> - enable timer5 startup
> - add smp for cpu1
> - initial set time for rtc-hym8563
> 
> changes since v1:
> - add dts, pinctrl and clock tree for rk3036 soc platform
> 
> The patchset (9):
> 9) rtc: hym8563: make sure hym8563 can be normal work
> 8) ARM: rockchip: add support smp for rk3036
> 7) rockchip: make sure timer5 is enabled on rk3036 platforms
> 6) pinctrl: rockchip: add support for the rk3036
> 5) dt-bindings: add documentation of rk3036 clock controller
> 4) clk: rockchip: add new clock type and controller for rk3036
> 3) clk: rockchip: add clock controller for rk3036
> 2) clk: rockchip: add dt-binding header for rk3036
> 1) ARM: dts: rockchip: add core rk3036 dts
> 
> 
> Changes in v2:
> Signed-off-by: Xing Zheng 
> 
> Xing Zheng (9):
>   ARM: dts: rockchip: add core rk3036 dts
>   clk: rockchip: add dt-binding header for rk3036
>   clk: rockchip: add clock controller for rk3036
>   clk: rockchip: add new clock type and controller for rk3036
>   dt-bindings: add documentation of rk3036 clock controller
>   pinctrl: rockchip: add support for the rk3036
>   rockchip: make sure timer5 is enabled on rk3036 platforms
>   ARM: rockchip: add support smp for rk3036
>   rtc: hym8563: make sure hym8563 can be normal work

am I missing some patches? I only got patches 1-4.

Anyway, you should reorder a bit

- whatever other patches are necessary before
- dt-bindings: add documentation of rk3036 clock controller
- clk: rockchip: add dt-binding header for rk3036
- clk: rockchip: add new pll type for rk3036
-  clk: rockchip: add clock controller for rk3036
- ARM: dts: rockchip: add core rk3036 dts

The dts patch for example depends on the clock-header, so it really should 
come after its addition.


Heiko

> 
>  .../bindings/clock/rockchip,rk3036-cru.txt |   60 +++
>  .../bindings/pinctrl/rockchip,pinctrl.txt  |1 +
>  arch/arm/boot/dts/Makefile |1 +
>  arch/arm/boot/dts/rk3036-sdk.dts   |   62 +++
>  arch/arm/boot/dts/rk3036.dtsi  |  381 +++
>  arch/arm/mach-rockchip/platsmp.c   |  121 +
>  arch/arm/mach-rockchip/rockchip.c  |   22 +
>  drivers/clk/rockchip/Makefile  |1 +
>  drivers/clk/rockchip/clk-pll.c |  262 +-
>  drivers/clk/rockchip/clk-rk3036.c  |  504
>  drivers/clk/rockchip/clk.h |  
> 30 ++
>  drivers/pinctrl/pinctrl-rockchip.c |   17 +
>  drivers/rtc/rtc-hym8563.c  |   93 
>  include/dt-bindings/clock/rk3036-cru.h |  198 
>  14 files changed, 1752 insertions(+), 1 deletion(-)
>  create mode 100644
> Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt create mode
> 100644 arch/arm/boot/dts/rk3036-sdk.dts
>  create mode 100644 arch/arm/boot/dts/rk3036.dtsi
>  create mode 100644 drivers/clk/rockchip/clk-rk3036.c
>  create mode 100644 include/dt-bindings/clock/rk3036-cru.h

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/9] clk: rockchip: add dt-binding header for rk3036

[Heiko Stübner]

Am Donnerstag, 17. September 2015, 16:28:53 schrieb Xing Zheng:
> Add the dt-bindings header for the rk3036, that gets shared between
> the clock controller and the clock references in the dts.
> 
> Signed-off-by: Xing Zheng 
> ---
> 
> Changes in v2: None
> 
>  include/dt-bindings/clock/rk3036-cru.h |  198
>  1 file changed, 198 insertions(+)
>  create mode 100644 include/dt-bindings/clock/rk3036-cru.h
> 
> diff --git a/include/dt-bindings/clock/rk3036-cru.h
> b/include/dt-bindings/clock/rk3036-cru.h new file mode 100644
> index 000..b0033ef
> --- /dev/null
> +++ b/include/dt-bindings/clock/rk3036-cru.h
> @@ -0,0 +1,198 @@
> +/*
> + * Copyright (c) 2014 MundoReader S.L.
> + * Author: Heiko Stuebner 

you can probably drop that copyright line ... I didn't do anything here ;-)

> + *
> + * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
> + * Author: Xing Zheng 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
> +#define _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H
> +
> +/* core clocks */
> +#define PLL_APLL 1
> +#define PLL_DPLL 2
> +#define PLL_GPLL 3
> +#define ARMCLK   4
> +
> +/* sclk gates (special clocks) */

you have a lot of gaps in the numbering ... intentional?


otherwise
Reviewed-by: Heiko Stuebner 

> +#define SCLK_GPU 64
> +#define SCLK_SPI 65
> +#define SCLK_SDMMC   68
> +#define SCLK_SDIO69
> +#define SCLK_EMMC71
> +#define SCLK_NANDC   76
> +#define SCLK_UART0   77
> +#define SCLK_UART1   78
> +#define SCLK_UART2   79
> +#define SCLK_I2S 82
> +#define SCLK_SPDIF   83
> +#define SCLK_TIMER0  85
> +#define SCLK_TIMER1  86
> +#define SCLK_TIMER2  87
> +#define SCLK_TIMER3  88
> +#define SCLK_OTGPHY0 93
> +#define SCLK_OTGPHY1 94
> +#define SCLK_LCDC100
> +#define SCLK_HDMI109
> +#define SCLK_HEVC111
> +#define SCLK_I2S_OUT 113
> +#define SCLK_SDMMC_DRV   114
> +#define SCLK_SDIO_DRV115
> +#define SCLK_EMMC_DRV117
> +#define SCLK_SDMMC_SAMPLE118
> +#define SCLK_SDIO_SAMPLE 119
> +#define SCLK_EMMC_SAMPLE 121
> +#define SCLK_PVTM_CORE  123
> +#define SCLK_PVTM_GPU   124
> +#define SCLK_PVTM_VIDEO 125
> +#define SCLK_MAC 151
> +#define SCLK_MACREF  152
> +#define SCLK_SFC 160
> +
> +#define DCLK_LCDC190
> +
> +/* aclk gates */
> +#define ACLK_DMAC2   194
> +#define ACLK_LCDC197
> +#define ACLK_VIO 203
> +#define ACLK_VCODEC  208
> +#define ACLK_CPU 209
> +#define ACLK_PERI210
> +
> +/* pclk gates */
> +#define PCLK_GPIO0   320
> +#define PCLK_GPIO1   321
> +#define PCLK_GPIO2   322
> +#define PCLK_GRF 329
> +#define PCLK_I2C0332
> +#define PCLK_I2C1333
> +#define PCLK_I2C2334
> +#define PCLK_SPI 338
> +#define PCLK_UART0   341
> +#define PCLK_UART1   342
> +#define PCLK_UART2   343
> +#define PCLK_PWM 350
> +#define PCLK_TIMER   353
> +#define PCLK_HDMI360
> +#define PCLK_CPU 362
> +#define PCLK_PERI363
> +#define PCLK_DDRUPCTL364
> +#define PCLK_WDT 368
> +
> +/* hclk gates */
> +#define HCLK_OTG0449
> +#define HCLK_OTG1450
> +#define HCLK_NANDC   453
> +#define HCLK_SDMMC   456
> +#define HCLK_SDIO457
> +#define HCLK_EMMC459
> +#define HCLK_I2S 462
> +#define HCLK_LCDC465
> +#define HCLK_ROM 467
> +#define HCLK_VIO_BUS 472
> +#define HCLK_VCODEC  476
> +#define HCLK_CPU 477
> +#define HCLK_PERI478
> +
> +#define CLK_NR_CLKS  (HCLK_PERI + 1)
> +
> +/* soft-reset indices */
> +#define SRST_CORE0   0
> +#define SRST_CORE1   1
> +#define SRST_CORE0_DBG   4
> +#define SRST_CORE1_DBG   5
> +#define SRST_CORE0_POR   8
> +#define SRST_CORE1_POR   9
> +#define SRST_L2C 12
> +#define SRST_TOPDBG  13
> +#define SRST_STRC_SYS_A  14
> +#define SRST_PD_CORE_NIU 15
> +
> +#define SR

Re: [PATCH v2 1/9] ARM: dts: rockchip: add core rk3036 dts

[Heiko Stübner]

Am Donnerstag, 17. September 2015, 16:28:52 schrieb Xing Zheng:
> Initial release for rk3036, node definitions rk3036 sdk board.
> 
> Signed-off-by: Xing Zheng 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/boot/dts/Makefile   |1 +
>  arch/arm/boot/dts/rk3036-sdk.dts |   62 +++
>  arch/arm/boot/dts/rk3036.dtsi|  381
> ++ 3 files changed, 444 insertions(+)
>  create mode 100644 arch/arm/boot/dts/rk3036-sdk.dts
>  create mode 100644 arch/arm/boot/dts/rk3036.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d39ce4b..48260c4 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -502,6 +502,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3066a-bqcurie2.dtb \
>   rk3066a-marsboard.dtb \
>   rk3066a-rayeager.dtb \
> + rk3036-sdk.dtb \

ordering ... please put the rk3036 above rk3066 boards


>   rk3188-radxarock.dtb \
>   rk3288-evb-act8846.dtb \
>   rk3288-evb-rk808.dtb \
> diff --git a/arch/arm/boot/dts/rk3036-sdk.dts
> b/arch/arm/boot/dts/rk3036-sdk.dts new file mode 100644
> index 000..9187f93
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3036-sdk.dts

or "rk3036-evb.dts"? What is the actual board named?

> @@ -0,0 +1,62 @@
> +/*
> + * Copyright (c)  2015 Xing Zheng 

this probably wants a Rockchip copyright notice?


> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + *  Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "rk3036.dtsi"
> +
> +/ {
> + model = "SDK-RK3036";
> + compatible = "sdk,sdk-rk3036", "rockchip,rk3036";

model = "Rockchip RK3036-SDK";
compatible = "rockchip,rk3036-sdk", "rockchip,rk3036";

or

model = "Rockchip RK3036 Evaluation board";
compatible = "rockchip,rk3036-evb", "rockchip,rk3036";

depending on what the real board is labeled


> +};
> +
> +&i2c1 {
> + status = "okay";
> +
> +hym8563: hym8563@51 {
> + compatible = "haoyu,hym8563";
> + reg = <0x51>;
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + clock-output-names = "xin32k";
> + };
> +};
> \ No newline at end of file

missing newline as stated above


> diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
> new file mode 100644
> index 000..b7459c0
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3036.dtsi
> @@ -0,0 +1,381 @@
> +/*
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be use

Re: [PATCH v18 1/4] dt-bindings: add document of Rockchip power domains

[Heiko Stübner]

Hi Caesar, Jinkun,

Am Dienstag, 8. September 2015, 14:18:20 schrieb Caesar Wang:
> This add the necessary binding documentation for the power domains
> found on Rockchip SoCs.
> 
> Signed-off-by: jinkun.hong 
> Signed-off-by: Caesar Wang 

What is Jinkun Hong's relationship to the patches?

The issue behind this is, that Caesar is the sender of the patches and how 
they stand right now would also be the author, but Jinkun was the first to 
sign them off, which is normally the line of the author.

Please decide who gets to be author of patches 1,3 and 4. If it's Caesar, 
we'll drop the Signed-off-by or if it's Jinkun we'll change the author.

There is no big need to resend the patches, I can adapt authorship if 
necessary.


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: dts: rockchip: Add dtb for the Radxa Rock 2 Square board

[Heiko Stübner]

Am Montag, 14. September 2015, 10:05:58 schrieb Sjoerd Simons:
> Hey Javier,
> 
> On Mon, 2015-09-14 at 09:50 +0200, Javier Martinez Canillas wrote:
> > Hello Sjoerd,
> > 
> > On Mon, Sep 14, 2015 at 9:30 AM, Sjoerd Simons
> > 
> >  wrote:
> > > For the first patch i do prefer to keep them on so we can have get
> > > some
> > > more testing  with this board before fine-tuning those things
> > > (fwiw,
> > 
> > Ok.
> > 
> > > the rockchip evb board and others with essentially the same pmic
> > > setup
> > > all also have them always-on)
> > 
> > Yes but I believe that's because it was easier and there are
> > regulators on these boards that don't need to be always-on as well.
> 
> Yes what i was trying to say is that it's not an uncommon to keep these
> on for convenience while fine-tuning the device-tree setups ;)

Also, a lot of drivers do not yet do proper regulator handling (our drm/kms 
driver as a prime example), so the number of regulators able to being actually 
turned off is quite slim.

So I guess I'm ok, with handling these once driver components can actually do 
something with their supplies :-) .


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: dts: rockchip: Add dtb for the Radxa Rock 2 Square board

[Heiko Stübner]

Hi Sjoerd,

Am Samstag, 12. September 2015, 00:36:45 schrieb Sjoerd Simons:

one thing I forgot:

> +&emmc {
> + broken-cd;
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + disable-wp;
> + non-removable;
> + num-slots = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;
> + vmmc-supply = <&vcc_io>;
> + status = "okay";
> +};

this could probably use a mmc powersequence to handle the emmc-reset pin?


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: dts: rockchip: Add dtb for the Radxa Rock 2 Square board

[Heiko Stübner]

Hi Sjoerd,

Am Samstag, 12. September 2015, 00:36:45 schrieb Sjoerd Simons:
> The Radxa Rock 2 Square board is a combination of the Radxa Rock 2 SoM
> with the Square baseboard. Add a dtsi for the SoM which can be included
> into the dts for the various baseboards (e.g. full and square) and a dts
> for the square board.
> 
> Currently supported are serial console, wired networking, hdmi output
> and USB.
> 
> Signed-off-by: Sjoerd Simons 
> 
> ---
> 
>  arch/arm/boot/dts/Makefile|   1 +
>  arch/arm/boot/dts/rk3288-rock2-som.dtsi   | 267
> ++ arch/arm/boot/dts/rk3288-rock2-square.dts |
> 164 ++ 3 files changed, 432 insertions(+)

please add an entry to Documentation/devicetree/arm/rockchip.txt for the new 
board too.

Some more nitpicks below:


>  create mode 100644 arch/arm/boot/dts/rk3288-rock2-som.dtsi
>  create mode 100644 arch/arm/boot/dts/rk3288-rock2-square.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 233159d..1ed8ec1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -507,6 +507,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3288-firefly-beta.dtb \
>   rk3288-firefly.dtb \
>   rk3288-r89.dtb \
> + rk3288-rock2-square.dtb \
>   rk3288-veyron-jerry.dtb \
>   rk3288-veyron-minnie.dtb \
>   rk3288-veyron-pinky.dtb \
> diff --git a/arch/arm/boot/dts/rk3288-rock2-som.dtsi
> b/arch/arm/boot/dts/rk3288-rock2-som.dtsi new file mode 100644
> index 000..01e69e8
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
> @@ -0,0 +1,267 @@
> +/*
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include 
> +#include "rk3288.dtsi"
> +
> +/ {
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x8000>;

please swap those if possible. I try to keep the ordering like
- compatible
- reg
[alphabetic sorted]
- status

for ease of reading.


> + };
> +
> + ext_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <12500>;
> + clock-output-names = "ext_gmac";
> + };
> +
> + vcc_sys: vsys-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_sys";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +};
> +
> +&cpu0 {
> + cpu0-supply = <&vdd_cpu>;
> +};
> +
> +

double empty line


> +&emmc {
> + broken-cd;
[...]
> + non-removable;

Documentation/devicetree/bindings/mmc/mmc.txt:
"Only one of the properties in this section should be supplied"

so I guess non-removable would be the most suitable


> + num-slots = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;
> + vmmc-supply = <&vcc_io>;
> 

Re: [PATCH] ARM: dts: Add ddc i2c reference to veyron

[Heiko Stübner]

Am Mittwoch, 2. September 2015, 14:25:48 schrieb Douglas Anderson:
> The ddc-i2c-bus property was missing from the veyron dtsi file since
> downstream the ddc-i2c-bus was still being specified in rk3288.dtsi and
> nobody noticed when the veyron dtsi was sent upstream.  Add it.
> 
> Signed-off-by: Douglas Anderson 

I've applied that to a dts-fixes branch for 4.3 with Brian's Tested-by tag.

As discussed this is temporary-only anyway till the internal i2c stuff of the 
dw_hdmi works.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Add the hdmi-ddc pinctrl settings for rk3288

[Heiko Stübner]

Am Mittwoch, 2. September 2015, 14:54:22 schrieb Douglas Anderson:
> The pins for i2c5 can either be configured as "I2C5" which means that
> they're controlled by the normal RK3288 I2C controller or as "EDP / HDMI
> I2C".  It's unclear why EDP is referenced here since apparently setting
> the mux to this position enables I2C communication using the dw_hdmi
> block with a patch like .
> 
> There appear to be some reasons why using the builtin I2C controller in
> dw_hdmi is better than using the normal RK3288 I2C controller, so boards
> based on rk3288 might eventually want to use this pinmux if it's known
> to work.
> 
> Once driver support in dw_hdmi lands, boards would use this by selecting
> this pinctrl for the HDMI block and then _not_ specifying a ddc-i2c-bus
> and _not_ setting the status to "okay" for i2c5 (which uses the same
> pins).
> 
> Signed-off-by: Douglas Anderson 

applied to my dts branch for 4.4


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] pinctrl: rockchip: Define GPIO banks 7 and 8

[Heiko Stübner]

Hi Sjoerd,

Am Samstag, 12. September 2015, 00:36:44 schrieb Sjoerd Simons:
> Rockchip RK3288 has 9 GPIO banks (0 to 8) add definitions for the last
> two.
> 
> Signed-off-by: Sjoerd Simons 
> ---
> 
>  include/dt-bindings/pinctrl/rockchip.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/dt-bindings/pinctrl/rockchip.h
> b/include/dt-bindings/pinctrl/rockchip.h index 743e66a..efc57cf 100644
> --- a/include/dt-bindings/pinctrl/rockchip.h
> +++ b/include/dt-bindings/pinctrl/rockchip.h
> @@ -24,6 +24,8 @@
>  #define RK_GPIO3 3
>  #define RK_GPIO4 4
>  #define RK_GPIO6 6
> +#define RK_GPIO7 7
> +#define RK_GPIO8 8
> 
>  #define RK_FUNC_GPIO 0
>  #define RK_FUNC_11

I'm actually not sure about these. In retrospect the RK_GPIOx -> x defines do 
not provide any additional value compared to just having the actual value in 
the pinctrl-nodes, so we phased them out largely for the rk3288 boards.

While looking through some boards, I saw that some slipped in for stuff that 
gets copy'n'paste treatment most of the time, but generally we're only using 
the real numbers on boards - and I'd like to keep it that way and phase out 
the RK_GPIOx constants in new boards.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v18 0/4] ARM: rk3288: Add PM Domain support

[Heiko Stübner]

Am Freitag, 11. September 2015, 13:40:35 schrieb Kevin Hilman:
> Caesar Wang  writes:
> > Thank you all for providing inputs and comments on previous versions of
> > this patchset.
> > Especially thanks to the (Kevin, Heiko, Dmitry, Doug, ULF, Michael).
> > 
> > Add power domain drivers based on generic power domain for
> > Rockchip platform, and support RK3288 SoCs.
> 
> No further issues from me.
> 
> Reviewed-by: Kevin Hilman 
> 
> Thanks for your persistence in getting this upstream!

nice ... thanks Caesar and Kevin for wiggling through this.

I'll probably pick this up once 4.3-rc1 is released.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v5 1/9] mmc: dw_mmc: Add external dma interface support

[Heiko Stübner]

Hi Shawn,

Am Freitag, 14. August 2015, 16:34:35 schrieb Shawn Lin:
> DesignWare MMC Controller can supports two types of DMA
> mode: external dma and internal dma. We get a RK312x platform
> integrated dw_mmc and ARM pl330 dma controller. This patch add
> edmac ops to support these platforms. I've tested it on RK312x
> platform with edmac mode and RK3288 platform with idmac mode.
> 
> Signed-off-by: Shawn Lin 

judging by your "from", I guess you're running this on some older Rockchip soc 
without the idma? Because I tried testing this on a Radxa Rock, but only got 
failures, from the start (failed to read card status register). In PIO mode 
everything works again.


I guess I overlooked just some tiny detail, but to me the dma channel ids seem 
correct after all. Maybe you have any hints what I'm doing wrong?

diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 4497d28..92d7156 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -217,6 +217,8 @@
interrupts = ;
clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>;
clock-names = "biu", "ciu";
+ dmas = <&dmac2 1>;
+ dma-names = "rx-tx";
fifo-depth = <256>;
status = "disabled";
};
@@ -227,6 +229,8 @@
interrupts = ;
clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>;
clock-names = "biu", "ciu";
+ dmas = <&dmac2 3>;
+ dma-names = "rx-tx";
fifo-depth = <256>;
status = "disabled";
};
@@ -237,6 +241,8 @@
interrupts = ;
clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>;
clock-names = "biu", "ciu";
+ dmas = <&dmac2 4>;
+ dma-names = "rx-tx";
fifo-depth = <256>;
status = "disabled";
};


[...]

> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index fcbf552..e01ead3 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2517,8 +2642,23 @@ static void dw_mci_cleanup_slot(struct dw_mci_slot
> *slot, unsigned int id) static void dw_mci_init_dma(struct dw_mci *host)
>  {
>   int addr_config;
> + int trans_mode;
> + struct device *dev = host->dev;
> + struct device_node *np = dev->of_node;
> +
> + /* Check tansfer mode */
> + trans_mode = SDMMC_GET_TRANS_MODE(mci_readl(host, HCON));
> + if (trans_mode == 0) {
> + trans_mode = TRANS_MODE_IDMAC;
> + } else if (trans_mode == 1 || trans_mode == 2) {
> + trans_mode = TRANS_MODE_EDMAC;
> + } else {
> + trans_mode = TRANS_MODE_PIO;
> + goto no_dma;
> + }
> +
>   /* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
> - addr_config = (mci_readl(host, HCON) >> 27) & 0x01;
> + addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));
> 
>   if (addr_config == 1) {
>   /* host supports IDMAC in 64-bit address mode */

I guess the idmac address size checking block

/* Check ADDR_CONFIG bit in HCON to find IDMAC address bus width */
addr_config = SDMMC_GET_ADDR_CONFIG(mci_readl(host, HCON));

if (addr_config == 1) {
/* host supports IDMAC in 64-bit address mode */
host->dma_64bit_address = 1;
dev_info(host->dev, "IDMAC supports 64-bit address mode.\n");
if (!dma_set_mask(host->dev, DMA_BIT_MASK(64)))
dma_set_coherent_mask(host->dev, DMA_BIT_MASK(64));
} else {
/* host supports IDMAC in 32-bit address mode */
host->dma_64bit_address = 0;
dev_info(host->dev, "IDMAC supports 32-bit address mode.\n");
}

could either live inside the trans_mode == 0 conditional above or get its own
if (trans_mode == 0) conditional. Either way I guess it should not talk about 
idmac when either pio or extdmac are used.


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 01/10] clk: mediatek: Removed unused dpi_ck clock from MT8173

[Heiko Stübner]

Am Donnerstag, 30. Juli 2015, 12:42:44 schrieb Stephen Boyd:
> On 07/30/2015 11:04 AM, Heiko Stübner wrote:
> > Am Donnerstag, 30. Juli 2015, 10:36:43 schrieb Stephen Boyd:
> >> Is it being used in DT right now and causing regressions on
> >> v4.2-rcX? Sorry, I'm trying to understand why this patch matters
> >> for the 4.2 release.
> > 
> > it's not been used in an actual devicetree file, but as far as I
> > understand it, the dt-binding headers themself are also part of the ABI.
> > 
> > And it is new in 4.2, so has not been part of an official release yet.
> > 
> > The reason for the removal from what I understand is that the removed
> > clock is not documented at all (it's source, what it does), which got it
> > the "clk_null" parent in the first place.
> 
> Right, so my understanding of the DT ABI thing is that newer kernels
> should keep working with older DTs. If there isn't any DT using the
> binding, then we don't have a problem because the only thing that could
> happen would be a newer DT working with an older kernel, which doesn't
> make any sense from a backwards incompatible standpoint.
> 
> If you feel strongly that some sort of DT ABI rule would be broken and
> you want to make sure that doesn't happen I guess we can queue this up
> to be sent off to Linus, but if you aren't worried (and I'm obviously
> not worried) then I'd prefer we just queue it up for 4.3.

I don't feel strongly, it was only based on what I remember about all the dt-
ABI talk :-) . Aka if you're ok with it simply going into 4.3 that should be 
ok too from my pov.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 01/10] clk: mediatek: Removed unused dpi_ck clock from MT8173

[Heiko Stübner]

Am Donnerstag, 30. Juli 2015, 10:36:43 schrieb Stephen Boyd:
> On 07/29, James Liao wrote:
> > Hi Stephen,
> > 
> > Could you help to apply this patch into 4.2?
> > 
> > 
> > Best regards,
> > 
> > James
> > 
> > On Wed, 2015-07-29 at 09:05 +0200, Heiko Stübner wrote:
> > > Am Mittwoch, 29. Juli 2015, 14:52:25 schrieb James Liao:
> > > > The dpi_ck clock can be removed because it not actually used
> > > > in topckgen and subsystems.
> > > > 
> > > > Signed-off-by: James Liao 
> > > 
> > > From our past discussions this change looks about right, and should
> > > still
> > > become _part of 4.2_, to not have the CLK_TOP_DPI become part of the
> > > devicetree CLK_TOP_DPI.
> 
> Did you mean ABI?

yep, sorry

> 
> > > Reviewed-by: Heiko Stuebner 
> 
> Is it being used in DT right now and causing regressions on
> v4.2-rcX? Sorry, I'm trying to understand why this patch matters
> for the 4.2 release.

it's not been used in an actual devicetree file, but as far as I understand it, 
the dt-binding headers themself are also part of the ABI.

And it is new in 4.2, so has not been part of an official release yet.

The reason for the removal from what I understand is that the removed clock is 
not documented at all (it's source, what it does), which got it the "clk_null" 
parent in the first place.


Heiko

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 01/10] clk: mediatek: Removed unused dpi_ck clock from MT8173

[Heiko Stübner]

Am Mittwoch, 29. Juli 2015, 14:52:25 schrieb James Liao:
> The dpi_ck clock can be removed because it not actually used
> in topckgen and subsystems.
> 
> Signed-off-by: James Liao 

>From our past discussions this change looks about right, and should still 
become _part of 4.2_, to not have the CLK_TOP_DPI become part of the 
devicetree CLK_TOP_DPI.

Reviewed-by: Heiko Stuebner 

> ---
>  drivers/clk/mediatek/clk-mt8173.c  | 1 -
>  include/dt-bindings/clock/mt8173-clk.h | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c index 4b9e04c..4486f8f 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -26,7 +26,6 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
> 
>  static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
>   FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> - FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
>   FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
>   FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
>  };
> diff --git a/include/dt-bindings/clock/mt8173-clk.h
> b/include/dt-bindings/clock/mt8173-clk.h index 4ad76ed..7230c38 100644
> --- a/include/dt-bindings/clock/mt8173-clk.h
> +++ b/include/dt-bindings/clock/mt8173-clk.h
> @@ -18,7 +18,6 @@
>  /* TOPCKGEN */
> 
>  #define CLK_TOP_CLKPH_MCK_O  1
> -#define CLK_TOP_DPI  2
>  #define CLK_TOP_USB_SYSPLL_125M  3
>  #define CLK_TOP_HDMITX_DIG_CTS   4
>  #define CLK_TOP_ARMCA7PLL_754M   5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/7] clk: mediatek: Fix rate and dependency of MT8173 clocks

[Heiko Stübner]

Am Montag, 27. Juli 2015, 14:19:41 schrieb Daniel Kurtz:
> On Jul 27, 2015 12:52, "Sascha Hauer"  wrote:
> > On Fri, Jul 24, 2015 at 07:10:14PM +0800, Daniel Kurtz wrote:
> > > On Fri, Jul 24, 2015 at 11:02 AM, James Liao 
> 
> wrote:
> > > > Remove the dependency from clk_null, and give all root clocks a
> > > > typical rate, include clkph_mck_o, usb_syspll_125m and hdmitx_dig_cts.
> > > > 
> > > > dpi_ck was removed due to no clock reference to it.
> > > > 
> > > > Replace parent clock of infra_cpum with cpum_ck, which is an external
> > > > clock and can be defined in the deivce tree.
> > > > 
> > > > Signed-off-by: James Liao 
> > > > ---
> > > > 
> > > >  drivers/clk/mediatek/clk-mt8173.c  | 13 ++---
> > > >  include/dt-bindings/clock/mt8173-clk.h |  1 -
> > > >  2 files changed, 6 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/drivers/clk/mediatek/clk-mt8173.c
> 
> b/drivers/clk/mediatek/clk-mt8173.c
> 
> > > > index 4b9e04c..50b3266 100644
> > > > --- a/drivers/clk/mediatek/clk-mt8173.c
> > > > +++ b/drivers/clk/mediatek/clk-mt8173.c
> > > > @@ -24,11 +24,9 @@
> > > > 
> > > >  static DEFINE_SPINLOCK(mt8173_clk_lock);
> > > > 
> > > > -static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
> > > > -   FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> > > > -   FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
> > > > -   FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m",
> 
> "clk_null", 1, 1),
> 
> > > > -   FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null",
> 
> 1, 1),
> 
> > > > +static const struct mtk_fixed_clk fixed_clks[] __initconst = {
> > > > +   FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 *
> 
> MHZ),
> 
> > > > +   FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m",
> 
> "clk26m", 125 * MHZ),
> 
> > > >  };
> > > >  
> > > >  static const struct mtk_fixed_factor top_divs[] __initconst = {
> > > > 
> > > > @@ -53,6 +51,7 @@ static const struct mtk_fixed_factor top_divs[]
> 
> __initconst = {
> 
> > > > FACTOR(CLK_TOP_CLKRTC_INT, "clkrtc_int", "clk26m", 1, 793),
> > > > FACTOR(CLK_TOP_FPC, "fpc_ck", "clk26m", 1, 1),
> > > > 
> > > > +   FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts",
> 
> "tvdpll_445p5m", 1, 3),
> 
> > > > FACTOR(CLK_TOP_HDMITXPLL_D2, "hdmitxpll_d2",
> 
> "hdmitx_dig_cts", 1, 2),
> 
> > > > FACTOR(CLK_TOP_HDMITXPLL_D3, "hdmitxpll_d3",
> 
> "hdmitx_dig_cts", 1, 3),
> 
> > > > @@ -611,7 +610,7 @@ static const struct mtk_gate infra_clks[]
> 
> __initconst = {
> 
> > > > GATE_ICG(CLK_INFRA_GCE, "infra_gce", "axi_sel", 6),
> > > > GATE_ICG(CLK_INFRA_L2C_SRAM, "infra_l2c_sram", "axi_sel", 7),
> > > > GATE_ICG(CLK_INFRA_M4U, "infra_m4u", "mem_sel", 8),
> > > > 
> > > > -   GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
> > > > +   GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "cpum_ck", 15),
> > > > 
> > > > GATE_ICG(CLK_INFRA_KP, "infra_kp", "axi_sel", 16),
> > > > GATE_ICG(CLK_INFRA_CEC, "infra_cec", "clk26m", 18),
> > > > GATE_ICG(CLK_INFRA_PMICSPI, "infra_pmicspi", "pmicspi_sel",
> 
> 22),
> 
> > > > @@ -714,7 +713,7 @@ static void __init mtk_topckgen_init(struct
> 
> device_node *node)
> 
> > > > clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
> > > > 
> > > > -   mtk_clk_register_factors(root_clk_alias,
> 
> ARRAY_SIZE(root_clk_alias), clk_data);
> 
> > > > +   mtk_clk_register_fixed_clks(fixed_clks,
> 
> ARRAY_SIZE(fixed_clks), clk_data);
> 
> > > > mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs),
> 
> clk_data);
> 
> > > > mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes),
> 
> base,
> 
> > > > &mt8173_clk_lock, clk_data);
> > > > 
> > > > diff --git a/include/dt-bindings/clock/mt8173-clk.h
> 
> b/include/dt-bindings/clock/mt8173-clk.h
> 
> > > > index 4ad76ed..7230c38 100644
> > > > --- a/include/dt-bindings/clock/mt8173-clk.h
> > > > +++ b/include/dt-bindings/clock/mt8173-clk.h
> > > > @@ -18,7 +18,6 @@
> > > > 
> > > >  /* TOPCKGEN */
> > > >  
> > > >  #define CLK_TOP_CLKPH_MCK_O1
> > > > 
> > > > -#define CLK_TOP_DPI2
> > > > 
> > > >  #define CLK_TOP_USB_SYSPLL_125M3
> > > 
> > > I think we should renumber the rest of the CLK_TOP_*
> > 
> > They shouldn't be renumbered at all as this makes all binary device
> > trees out there useless. That may not be a big issue with the MT8173
> > at the moment as there are hardly any binary device trees with the
> > mainline device trees shipped, but still we should get used to not
> > break existing device trees without need.
> 
> As you mention, there are no devices shipped with mainline binary device
> trees.  So, let's just correct the numbering now while we still can do it
> painlessly.  It seems a bit unnecessary to preserve backwards compatibility
> when we are still landing basic device support, like the c

Re: [PATCH v2] ARM: dts: rockchip: Add veyron-speedy board

[Heiko Stübner]

Hi Romain,

I've applied the patch to my dts branch for 4.3 after fixing some smallish 
issues:


Am Donnerstag, 23. Juli 2015, 18:50:49 schrieb Romain Perier:
> Which is formally known as The Asus C201 chromebook

^ typo the with small "t"

> 
> Signed-off-by: Romain Perier 
> Reviewed-by: Doug Anderson 
> ---
> 
> Changes in v2:
>  - Remove dvs-gpio (not used in mainline yet)
>  - Remove edp subnode in pinctrl (not used in mainline yet)
>  - Reordering disable-wp correctly
> 
>  Documentation/devicetree/bindings/arm/rockchip.txt |  10 +-
>  arch/arm/boot/dts/Makefile |   3 +-
>  arch/arm/boot/dts/rk3288-veyron-speedy.dts | 155
> + 3 files changed, 166 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/rk3288-veyron-speedy.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> b/Documentation/devicetree/bindings/arm/rockchip.txt index
> 6de18bd2..da02022 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -37,4 +37,12 @@ Rockchip platforms device tree bindings
>  - Google Pinky (dev-board):
>  Required root node properties:
>- compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
> -  "google,veyron", "rockchip,rk3288";
> \ No newline at end of file
> +  "google,veyron", "rockchip,rk3288";
> +
> +- Google Speedy (Asus C201 Chromebook):
> +Required root node properties:
> +  - compatible = "google,veyron-speedy-rev9",
> "google,veyron-speedy-rev8", + 
> "google,veyron-speedy-rev7",
> "google,veyron-speedy-rev6",
> +  "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
> +  "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> +  "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 4993b3b..bf5225a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -490,7 +490,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3288-firefly-beta.dtb \
>   rk3288-firefly.dtb \
>   rk3288-veyron-jerry.dtb \
> - rk3288-veyron-pinky.dtb
> + rk3288-veyron-pinky.dtb \
> + rk3288-veyron-speedy.dtb
>  dtb-$(CONFIG_ARCH_S3C24XX) += \
>   s3c2416-smdk2416.dtb
>  dtb-$(CONFIG_ARCH_S3C64XX) += \

both the board description as well as the Makefile did not apply cleanly, as 
you seem to have based it on some unknown branch.
Please try to base patches on either linux-next or my version specific topic 
branch - v4.3-armsoc/dts in this case.


> diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> b/arch/arm/boot/dts/rk3288-veyron-speedy.dts new file mode 100644
> index 000..fdb2a73
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> @@ -0,0 +1,155 @@
> +/*
> + * Google Veyron Speedy Rev 1+ board device tree source
> + *
> + * Copyright 2015 Google, Inc
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + *  Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR O

Re: [PATCH 2/2] ARM: dts: rockchip: Add veyron-speedy board

[Heiko Stübner]

Hi Romain,

could you include Doug (diand...@chromium.org) and Alex (ams...@chromium.org) 
when touching Chromebook related stuff please?

Especially the new dts probably needs an Ack from Doug, as this is the 
chromeos one with changed license header.

And two nits below:


Am Mittwoch, 22. Juli 2015, 07:44:05 schrieb Romain Perier:
> Which is formally known as The Asus C201 chromebook
> 
> Signed-off-by: Romain Perier 
> ---
>  Documentation/devicetree/bindings/arm/rockchip.txt |  10 +-
>  arch/arm/boot/dts/Makefile |   3 +-
>  arch/arm/boot/dts/rk3288-veyron-speedy.dts | 163
> + 3 files changed, 174 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/rk3288-veyron-speedy.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> b/Documentation/devicetree/bindings/arm/rockchip.txt index
> 6de18bd2..da02022 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -37,4 +37,12 @@ Rockchip platforms device tree bindings
>  - Google Pinky (dev-board):
>  Required root node properties:
>- compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
> -  "google,veyron", "rockchip,rk3288";
> \ No newline at end of file

I think I caught that missing newline when applying my board patch :-)


> +  "google,veyron", "rockchip,rk3288";
> +
> +- Google Speedy (Asus C201 Chromebook):
> +Required root node properties:
> +  - compatible = "google,veyron-speedy-rev9",
> "google,veyron-speedy-rev8", + 
> "google,veyron-speedy-rev7",
> "google,veyron-speedy-rev6",
> +  "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
> +  "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> +  "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 653ede7..bfa7c86 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -498,7 +498,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>   rk3288-firefly-beta.dtb \
>   rk3288-firefly.dtb \
>   rk3288-veyron-jerry.dtb \
> - rk3288-veyron-pinky.dtb
> + rk3288-veyron-pinky.dtb \
> + rk3288-veyron-speedy.dtb
>  dtb-$(CONFIG_ARCH_S3C24XX) += \
>   s3c2416-smdk2416.dtb
>  dtb-$(CONFIG_ARCH_S3C64XX) += \
> diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> b/arch/arm/boot/dts/rk3288-veyron-speedy.dts new file mode 100644
> index 000..6578e2a
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> @@ -0,0 +1,163 @@
> +/*
> + * Google Veyron Speedy Rev 1+ board device tree source
> + *
> + * Copyright 2015 Google, Inc
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + *  Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "rk3288-veyron-chromebook.dtsi"
> +#include "cros-ec-sbs.dtsi"
> +
> +/ {
> + model = "Google Speedy";

Re: [PATCH 1/2] ARM: dts: rockchip: Use correct dts properties for tsadc node

[Heiko Stübner]

Am Mittwoch, 22. Juli 2015, 07:44:06 schrieb Romain Perier:
> tsadc-tshut-mode and tsadc-tshut-polarity properties don't exist. The
> rockchip thermal driver looks for rockchip,hw-tshut-mode and
> rockchip,hw-tshut-polarity instead, otherwise it might freeze or hang the
> device according to the default mode or polarity used.
> 
> Signed-off-by: Romain Perier 
> ---
>  arch/arm/boot/dts/rk3288-veyron.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
> b/arch/arm/boot/dts/rk3288-veyron.dtsi index 627d113..cc76cf7 100644
> --- a/arch/arm/boot/dts/rk3288-veyron.dtsi
> +++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
> @@ -367,8 +367,8 @@
>  &tsadc {
>   status = "okay";
> 
> - tsadc-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
> - tsadc-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> + rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
> + rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
>  };
> 
>  &uart0 {

applied this one to my dts branch for 4.3 (after adding a veyron to the 
subject).


Thanks for the catch
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dt-bindings: add vendor prefix for Netxeon Technology

[Heiko Stübner]

Am Dienstag, 26. Mai 2015, 21:49:05 schrieb Heiko Stuebner:
> Signed-off-by: Heiko Stuebner 

applied both patches to my dts branch for 4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] clk: mediatek: Fix PLL registers setting flow

[Heiko Stübner]

Am Mittwoch, 8. Juli 2015, 16:37:45 schrieb James Liao:
> Write postdiv and pcw settings at the same time for PLLs if postdiv
> and pcw settings are on the same register.
> 
> This is need by PLLs such as MT8173 MMPLL and ARM*PLL.
> 
> Signed-off-by: James Liao 

Reviewed-by: Heiko Stuebner 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clk: mediatek: Add MT8173 MMPLL change rate support

[Heiko Stübner]

Am Dienstag, 7. Juli 2015, 17:48:45 schrieb James Liao:
> Hi Heiko,
> 
> On Tue, 2015-07-07 at 11:34 +0200, Heiko Stübner wrote:
> > > > > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct
> > > > > mtk_clk_pll
> > > > > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > > > > 
> > > > >  {
> > > > >  
> > > > >   unsigned long fmin = 1000 * MHZ;
> > > > > 
> > > > > + const unsigned long *div_rate = pll->data->div_rate;
> > > > > 
> > > > >   u64 _pcw;
> > > > >   u32 val;
> > > > >   
> > > > >   if (freq > pll->data->fmax)
> > > > >   
> > > > >   freq = pll->data->fmax;
> > > > > 
> > > > > - for (val = 0; val < 4; val++) {
> > > > > + if (div_rate) {
> > > > > + for (val = 1; div_rate[val] != 0; val++) {
> > > > > + if (freq > div_rate[val])
> > > > > + break;
> > > > > + }
> > > > > + val--;
> > > > 
> > > > if you're changing the table struct, this of course also would need to
> > > > be
> > > > adapted.
> > > > 
> > > > 
> > > > Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the
> > > > table,
> > > > if
> > > > you ignore it here all the time?
> > > > 
> > > > So the table should probably look more like [when using the concept
> > > > from
> > > > above]
> > > > 
> > > > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> > > > 
> > > > { .freq = 10, .div = 0 },
> > > > { .freq = 70200, .div = 1 },
> > > > { .freq = 25350, .div = 2 },
> > > > { .freq = 12675, .div = 3 },
> > > > { /* sentinel */ },
> > > > 
> > > > };
> > > 
> > > The freq-div table describes the maximum frequency of each divider
> > > setting. Although the first element doesn't used in current
> > > implementation, I think it's better to keep freq-div table's
> > > completeness.
> > 
> > the issue I see is, that its value is currently 0 and the code substracts
> > 1. So if anything would (accidentially) select MT8173_PLL_FMAX, the u32
> > val would wrap around, as you're subtracting 1 from 0 .
> 
> Subtracting 1 from val is safe now because it starts from 1:
> 
>   for (val = 1; div_rate[val] != 0; val++) {
> ...
>   }
>   val--;
> 
> I can change this implementation to a more readable one such as:
> 
>   for (val = 0; div_rate[val + 1] != 0; val++) {
> if (freq <= div_rate[val] && freq > div_rate[val + 1]) {
>   ...
> 
> Do you think it is OK?

My issue is, that you have the MT8173_PLL_FMAX entry in the table, which is 
effectively unused, as it is ignored by the for loop. They why have it all, if 
nothing cares about it.

So if in the future somebody notices, "oh this is ignoring the first entry" 
without look further what the code does, this explodes ;-)


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clk: mediatek: Add MT8173 MMPLL change rate support

[Heiko Stübner]

Hi James,

Am Dienstag, 7. Juli 2015, 17:28:38 schrieb James Liao:
> On Tue, 2015-07-07 at 10:58 +0200, Heiko Stübner wrote:
> > > +#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits,  
> > > \
> > > + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg,   \
> > > + _pcw_shift) \
> > > + PLL_B(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, \
> > > + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, _pcw_shift, \
> > > + NULL)
> > > +
> > > +const unsigned long mmpll_div_rate[] = {
> > 
> > static?
> 
> OK. I'll add it.
> 
> > > + MT8173_PLL_FMAX,
> > > + 10,
> > > + 70200,
> > > + 25350,
> > > + 12675,
> > > + 0,
> > 
> > it's more common to label sentinel entries (the 0 marking the end) with
> > 
> > /* sentinel */
> > 
> > instead of value 0.
> 
> OK. I'll add it.
> 
> > If I'm reading the code correctly, this is a mapping divider -> frequency,
> > right? So it may be nice to make this a bit more explicit, like:
> > 
> > struct mtk_pll_div_table {
> > 
> > unsigned intfreq;
> > unsigned intdiv;
> > 
> > };
> > 
> > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> > 
> > { .freq = MT8173_PLL_FMAX, .div = 0 },
> > { .freq = 10, .div = 1 },
> > { .freq = 70200, .div = 2 },
> > { .freq = 25350, .div = 3 },
> > { .freq = 12675, .div = 4 },
> > { /* sentinel */ },
> > 
> > };
> 
> Hmm.. OK. I'll try to use a more readable way to implement it.
> 
> > -
> > 
> > > - u32 con1, pd, val;
> > > + u32 con1, val;
> > > 
> > >   int pll_en;
> > > 
> > > - /* set postdiv */
> > > - pd = readl(pll->pd_addr);
> > > - pd &= ~(POSTDIV_MASK << pll->data->pd_shift);
> > > - pd |= (ffs(postdiv) - 1) << pll->data->pd_shift;
> > > - writel(pd, pll->pd_addr);
> > > -
> > > 
> > >   pll_en = readl(pll->base_addr + REG_CON0) & CON0_BASE_EN;
> > > 
> > > - /* set pcw */
> > > - val = readl(pll->pcw_addr);
> > > + /* set postdiv */
> > > + val = readl(pll->pd_addr);
> > > + val &= ~(POSTDIV_MASK << pll->data->pd_shift);
> > > + val |= (ffs(postdiv) - 1) << pll->data->pd_shift;
> > > +
> > > + /* postdiv and pcw need to set at the same time if on same register 
*/
> > > + if (pll->pd_addr != pll->pcw_addr) {
> > > + writel(val, pll->pd_addr);
> > > + val = readl(pll->pcw_addr);
> > > + }
> > > 
> > > + /* set pcw */
> > > 
> > >   val &= ~GENMASK(pll->data->pcw_shift + pll->data->pcwbits - 1,
> > >   
> > >   pll->data->pcw_shift);
> > >   
> > >   val |= pcw << pll->data->pcw_shift;
> > 
> > This whole block probably wants to be a separate patch ;-) .
> > 
> > While it may not affect previous pll implementations, it changes how
> > register accesses are handled and should not hide in another patch.
> 
> OK, I'll separate it.
> 
> > > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct mtk_clk_pll
> > > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > > 
> > >  {
> > >  
> > >   unsigned long fmin = 1000 * MHZ;
> > > 
> > > + const unsigned long *div_rate = pll->data->div_rate;
> > > 
> > >   u64 _pcw;
> > >   u32 val;
> > >   
> > >   if (freq > pll->data->fmax)
> > >   
> > >   freq = pll->data->fmax;
> > > 
> > > - for (val = 0; val < 4; val++) {
> > > + if (div_rate) {
> > > + for (val = 1; div_rate[val] != 0; val++) {
> > > + if (freq > div_rate[val])
> > > + break;
> > > + }
> > > + val--;
> > 
> > if you're changing the table struct, this of course also would need to be
> > adapted.
> > 
> > 
> > Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the table,
> > if
> > you ignore it here all the time?
> > 
> > So the table should probably look more like [when using the concept from
> > above]
> > 
> > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> > 
> > { .freq = 10, .div = 0 },
> > { .freq = 70200, .div = 1 },
> > { .freq = 25350, .div = 2 },
> > { .freq = 12675, .div = 3 },
> > { /* sentinel */ },
> > 
> > };
> 
> The freq-div table describes the maximum frequency of each divider
> setting. Although the first element doesn't used in current
> implementation, I think it's better to keep freq-div table's
> completeness.

the issue I see is, that its value is currently 0 and the code substracts 1. 
So if anything would (accidentially) select MT8173_PLL_FMAX, the u32 val would 
wrap around, as you're subtracting 1 from 0 .


Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] clk: mediatek: Add MT8173 MMPLL change rate support

[Heiko Stübner]

Hi James,

Am Dienstag, 2. Juni 2015, 13:26:00 schrieb James Liao:
> MT8173 MMPLL frequency settings are different from common PLLs.
> It needs different post divider settings for some ranges of frequency.
> This patch add support for MT8173 MMPLL frequency setting, includes:
> 
> 1. Add div-rate table for PLLs.
> 2. Increase the max ost divider setting from 3 (/8) to 4 (/16).
> 3. Write postdiv and pcw settings at the same time.
> 
> Signed-off-by: James Liao 
> ---
>  drivers/clk/mediatek/clk-mt8173.c | 24 +---
>  drivers/clk/mediatek/clk-mtk.h|  1 +
>  drivers/clk/mediatek/clk-pll.c| 37
> + 3 files changed, 47 insertions(+), 15
> deletions(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c index 357b080..821de7d 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -779,8 +779,9 @@ CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg",
> mtk_pericfg_init);
> 
>  #define CON0_MT8173_RST_BAR  BIT(24)
> 
> -#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits,
> _pd_reg, _pd_shift, \ -   _tuner_reg, _pcw_reg, 
> _pcw_shift) { \
> +#define PLL_B(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits,
> \
> + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg,   \
> + _pcw_shift, _div_rate) {\
>   .id = _id,  \
>   .name = _name,  \
>   .reg = _reg,\
> @@ -795,14 +796,31 @@ CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg",
> mtk_pericfg_init); .tuner_reg = _tuner_reg,   \
>   .pcw_reg = _pcw_reg,\
>   .pcw_shift = _pcw_shift,\
> + .div_rate = _div_rate,  \
>   }
> 
> +#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits,  \
> + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg,   \
> + _pcw_shift) \
> + PLL_B(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, \
> + _pd_reg, _pd_shift, _tuner_reg, _pcw_reg, _pcw_shift, \
> + NULL)
> +
> +const unsigned long mmpll_div_rate[] = {

static?

> + MT8173_PLL_FMAX,
> + 10,
> + 70200,
> + 25350,
> + 12675,
> + 0,

it's more common to label sentinel entries (the 0 marking the end) with
/* sentinel */
instead of value 0.


If I'm reading the code correctly, this is a mapping divider -> frequency, 
right? So it may be nice to make this a bit more explicit, like:

struct mtk_pll_div_table {
unsigned intfreq;
unsigned intdiv;
};

static const struct mtk_pll_div_table mmpll_div_rate[] = {
{ .freq = MT8173_PLL_FMAX, .div = 0 },
{ .freq = 10, .div = 1 },
{ .freq = 70200, .div = 2 },
{ .freq = 25350, .div = 3 },
{ .freq = 12675, .div = 4 },
{ /* sentinel */ },
};


> +};
> +
>  static const struct mtk_pll_data plls[] = {
>   PLL(CLK_APMIXED_ARMCA15PLL, "armca15pll", 0x200, 0x20c, 0x0001, 0, 
21,
> 0x204, 24, 0x0, 0x204, 0), PLL(CLK_APMIXED_ARMCA7PLL, "armca7pll", 0x210,
> 0x21c, 0x0001, 0, 21, 0x214, 24, 0x0, 0x214, 0),
> PLL(CLK_APMIXED_MAINPLL, "mainpll", 0x220, 0x22c, 0xf101, HAVE_RST_BAR,
> 21, 0x220, 4, 0x0, 0x224, 0), PLL(CLK_APMIXED_UNIVPLL, "univpll", 0x230,
> 0x23c, 0xfe01, HAVE_RST_BAR, 7, 0x230, 4, 0x0, 0x234, 14),
> - PLL(CLK_APMIXED_MMPLL, "mmpll", 0x240, 0x24c, 0x0001, 0, 21, 0x244,
> 24, 0x0, 0x244, 0), + PLL_B(CLK_APMIXED_MMPLL, "mmpll", 0x240, 0x24c,
> 0x0001, 0, 21, 0x244, 24, 0x0, 0x244, 0, mmpll_div_rate),
> PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x250, 0x25c, 0x0001, 0, 21, 0x250,
> 4, 0x0, 0x254, 0), PLL(CLK_APMIXED_VENCPLL, "vencpll", 0x260, 0x26c,
> 0x0001, 0, 21, 0x260, 4, 0x0, 0x264, 0), PLL(CLK_APMIXED_TVDPLL,
> "tvdpll", 0x270, 0x27c, 0x0001, 0, 21, 0x270, 4, 0x0, 0x274, 0), diff
> --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index 61035b9..645af7c 100644
> --- a/drivers/clk/mediatek/clk-mtk.h
> +++ b/drivers/clk/mediatek/clk-mtk.h
> @@ -150,6 +150,7 @@ struct mtk_pll_data {
>   int pcwbits;
>   uint32_t pcw_reg;
>   int pcw_shift;
> + const unsigned long *div_rate;
>  };
> 
>  void __init mtk_clk_register_plls(struct device_node *node,
> diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
> index 44409e9..4680a09 100644
> --- a/drivers/clk/mediatek/clk-pll.c
> +++ b/drivers/clk/mediatek/clk-pll.c
> @@ -90,20 +90,23 @@ static unsigned long __mtk_pll_recalc_rate(struct
> mtk_clk_pll *pll, u

Re: [PATCH] arm64: dts: mt8173: add clock_null

[Heiko Stübner]

Am Freitag, 3. Juli 2015, 15:45:12 schrieb James Liao:
> On Thu, 2015-07-02 at 12:23 +0800, Daniel Kurtz wrote:
> > On Thu, Jul 2, 2015 at 11:06 AM, James Liao  
wrote:
> > > These clocks such as clkph_mck_o are configured by other modules before
> > > kernel init, and their rates may different among platforms.
> > 
> > What other modules?
> > Do you mean the rates are configured by firmware?
> > How are the rates set?
> > Are there registers that configure its rate?
> > If so, why can't the kernel read these registers and compute the current
> > rate?
> CLKPH_MCK_O for example, it's a DRAM related clock, and initialized in
> preloader (before kernel init). It's setting may be different because
> using different DRAM module. And the setting may be changed dynamically
> in runtime.

If it's set in the preloader (and maybe changed at runtime) this means, its 
setting can also be read back to determine its current clock rate, so this is 
a non-argument here ;-)


> We don't care CLKPH_MCK_O's rate in CCF because we don't need to change
> mem_sel's setting in kernel, and there is not driver need to know
> mem_sel's rate.

As Daniel said, some of these clocks may be parents of other clocks, and not 
knowing their rate might hurt in the future - especially when it's easy after 
all to get its actual value like in your CLKPH_MCK_O example above.


Heiko


> > For mt8173, we are essentially discussing the following clocks (whose
> > sole parent is clk_null):
> > 
> > FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> > FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
> > FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
> > FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
> > GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
> > GATE_MM1(CLK_MM_DSI0_DIGITAL, "mm_dsi0_digital", "clk_null", 5),
> > GATE_MM1(CLK_MM_DSI1_DIGITAL, "mm_dsi1_digital", "clk_null", 7),
> > GATE_MM1(CLK_MM_DPI1_PIXEL, "mm_dpi1_pixel", "clk_null", 10),
> > GATE_MM1(CLK_MM_LVDS_PIXEL, "mm_lvds_pixel", "clk_null", 16),
> > GATE_MM1(CLK_MM_LVDS_CTS, "mm_lvds_cts", "clk_null", 17),
> > 
> > clkph_mck_o - This is the parent for dmpll_*, which are themselves
> > (potential) parent clocks for nearly every subsystem.
> > In fact, as shown above, the dmpll_* is the selected parent for
> > several other clocks, which all end up with an unknown rate.
> > So, I think it is worth investigating a little more how to properly
> > read or otherwise specify the rate for clkph_mck_o.
> 
> Please see above.
> 
> > dpi_ck, infra_cpum, mm_dsi0_digital, mm_dsi1_digital, mm_lvds_cts -
> > These are a dead-end (internal?) clock.
> > It is probably fine if their rates are unknown (0 Hz).
> > 
> > usb_syspll_125m - This sounds like a fixed 125 MHz clock.  It is also
> > a possible parent usb30 clock, so its value will propagate.
> > 
> > hdmitx_dig_cts - This is the root clock for the tree leading to
> > mm_hdmi_pllck, which includes hdmitxpll_d* and hdmi_sel.
> > However, I don't know how "mm_hdmi_pllck" is used.
> > 
> > mm_dpi1_pixel, mm_lvds_pixel - These two look very suspicious.  The
> > similar "mm_dpi0_pixel" and "mm_hdmi_pixel" have parent dpi0_sel.
> > It looks like maybe they should have "dpi1_sel" or "dpilvds_sel" as
> > parents, but the _sel are not hooked up.
> 
> Subsystem clocks with parent clk_null may have different reasons. I'll
> get back to you later.
> 
> 
> Best regards,
> 
> James

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/4] dt-bindings: document rk3368 R88 board from Rockchip

[Heiko Stübner]

The initial board containing the rk3368 ARM64 soc.

Signed-off-by: Heiko Stuebner 
---
This should probably be simply in one branch with the Netxeon board
seen in the diff above, to prevent unncessary merge conflicts?

 Documentation/devicetree/bindings/arm/rockchip.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index b30bed1..c4119e0 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -30,3 +30,7 @@ Rockchip platforms device tree bindings
 - Netxeon R89 board:
 Required root node properties:
   - compatible = "netxeon,r89", "rockchip,rk3288";
+
+- Rockchip R88 board:
+Required root node properties:
+  - compatible = "rockchip,r88", "rockchip,rk3368";
-- 
2.1.4


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/4] arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88 board

[Heiko Stübner]

In terms of peripherals the rk3368 is quite similar to the rk3288, which
makes it possible to have a lot basic components working in the first go.
More to follow once I tracked down all the tiny differences that still
exist in some parts.

With these dts files, the R88 board is able to boot from an attached
usb device and most likely from its emmc too, if the emmc uses a standard
partition table instead of Rockchip's own one - the emmc itself is
detected correctly.

Signed-off-by: Heiko Stuebner 
---
This of course needs the dt-binding header from clock series, so
a shared branch will be needed.

 arch/arm64/boot/dts/Makefile|   1 +
 arch/arm64/boot/dts/rockchip/Makefile   |   5 +
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 353 +++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi| 900 
 4 files changed, 1259 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/Makefile
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-r88.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index ad26a75..6916eec 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -6,6 +6,7 @@ dts-dirs += exynos
 dts-dirs += freescale
 dts-dirs += mediatek
 dts-dirs += qcom
+dts-dirs += rockchip
 dts-dirs += sprd
 dts-dirs += xilinx
 
diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
new file mode 100644
index 000..601e6a2
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts 
b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
new file mode 100644
index 000..d0c519b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
@@ -0,0 +1,354 @@
+/*
+ * Copyright (c) 2015 Heiko Stuebner 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3368.dtsi"
+
+/ {
+   model = "Rockchip R88";
+   compatible = "rockchip,r88", "rockchip,rk3368";
+
+   chosen {
+   stdout-path = "serial2:115200n8";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   pinctrl-0 = <&emmc_reset>;
+   pinctrl-names = "default";
+   reset-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+   };
+
+   keys: gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pwr_key>;
+
+   button@0 {
+   gpio-key,wakeup = <1>;
+   gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+   label = "GPIO Power";
+   l

[PATCH v2 1/4] arm64: add Rockchip architecture entry

[Heiko Stübner]

The rk3368 is Rockchip's first ARM64 soc, build around 8 Cortex-A53 cores.

Signed-off-by: Heiko Stuebner 
---
 arch/arm64/Kconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 290ed64..9af528a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -197,6 +197,16 @@ config ARCH_QCOM
help
  This enables support for the ARMv8 based Qualcomm chipsets.
 
+config ARCH_ROCKCHIP
+   bool "Rockchip Platforms"
+   select ARCH_HAS_RESET_CONTROLLER
+   select ARCH_REQUIRE_GPIOLIB
+   select PINCTRL
+   select PINCTRL_ROCKCHIP
+   help
+ This enables support for the ARMv8 based Rockchip chipsets,
+ like the RK3368.
+
 config ARCH_SEATTLE
bool "AMD Seattle SoC Family"
help
-- 
2.1.4


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/4] arm64: defconfig: enable ARCH_ROCKCHIP

[Heiko Stübner]

Enable building Rockchip support in the defconfig.

Signed-off-by: Heiko Stuebner 
---
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index daefbf0..77bc5bc 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -34,6 +34,7 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_ARCH_EXYNOS7=y
 CONFIG_ARCH_FSL_LS2085A=y
 CONFIG_ARCH_MEDIATEK=y
+CONFIG_ARCH_ROCKCHIP=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_TEGRA=y
 CONFIG_ARCH_TEGRA_132_SOC=y
@@ -99,6 +100,7 @@ CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_DW=y
 CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
-- 
2.1.4


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/4] arm64: add initial support for the Rockchip rk3368

[Heiko Stübner]

This adds initial support for the new rk3368 ARM64 soc from Rockchip.

Overall it looks like someone dropped some A53 cores into a rk3288, so
it shares a lot of peripherals that only differ in details. Therefore
stuff like the mmc, usb, spi, i2c controllers work out of the box.
The support for the gmac already made it into the merge window as well
as the pinctrl support.

Interestingly, in its core the rk3368 seems trying to be a model student
with psci for smp and using scpi for ddr frequency scaling, although I
currently do not understand how the mailbox works yet. The display
controllers also are only minimally different so I'm hopefully to have
working graphics in the near-ish future :-)


As mentioned in the dts patch, this series depends on the dt-binding
header for the clock ids, so will need a shared branch once this is ready.

changes since v1:
- add missing device_type = "memeory", as found by Mark Rutland
- fix patch subject for patch4 (the board is called R88),
  found by Naoki Fukaumi

Heiko Stuebner (4):
  arm64: add Rockchip architecture entry
  arm64: defconfig: enable ARCH_ROCKCHIP
  arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88
board
  dt-bindings: document rk3368 R89 board from Rockchip

 Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
 arch/arm64/Kconfig |  10 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/Makefile  |   5 +
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts| 353 
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   | 900 +
 arch/arm64/configs/defconfig   |   2 +
 7 files changed, 1275 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/Makefile
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-r88.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368.dtsi

-- 
2.1.4


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] arm64: add initial support for the Rockchip rk3368

[Heiko Stübner]

Hi Bamvor,

Am Freitag, 26. Juni 2015, 12:35:58 schrieb Bamvor Jian Zhang:
> Could I test the code on rk3368 STB such as EKB368, CSA90?
> Is there some documents about it?

General information on flashing generic Rockchip devices can be found on [0]. 
That didn't change for the rk3368 it seems - although a device _might_ be 
locked down to prevent reflashing it seems.

You will of course also need a serial console on the device for the time 
being, so finding the test-points and soldering is probably required.


Heiko


[0] http://linux-rockchip.info


> On 06/26/2015 02:12 AM, Heiko Stübner wrote:
> > This adds initial support for the new rk3368 ARM64 soc from Rockchip.
> > 
> > Overall it looks like someone dropped some A53 cores into a rk3288, so
> > it shares a lot of peripherals that only differ in details. Therefore
> > stuff like the mmc, usb, spi, i2c controllers work out of the box.
> > The support for the gmac already made it into the merge window as well
> > as the pinctrl support.
> > 
> > Interestingly, in its core the rk3368 seems trying to be a model student
> > with psci for smp and using scpi for ddr frequency scaling, although I
> > currently do not understand how the mailbox works yet. The display
> > controllers also are only minimally different so I'm hopefully to have
> > working graphics in the near-ish future :-)
> > 
> > 
> > As mentioned in the dts patch, this series depends on the dt-binding
> > header for the clock ids, so will need a shared branch once this is ready.
> > 
> > Heiko Stuebner (4):
> >arm64: add Rockchip architecture entry
> >arm64: defconfig: enable ARCH_ROCKCHIP
> >arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88
> >
> >  board
> >
> >dt-bindings: document rk3368 R89 board from Rockchip
> >   
> >   Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
> >   arch/arm64/Kconfig |  10 +
> >   arch/arm64/boot/dts/Makefile   |   1 +
> >   arch/arm64/boot/dts/rockchip/Makefile  |   5 +
> >   arch/arm64/boot/dts/rockchip/rk3368-r88.dts| 353 
> >   arch/arm64/boot/dts/rockchip/rk3368.dtsi   | 900
> >   + arch/arm64/configs/defconfig 
> >|   2 +
> >   7 files changed, 1275 insertions(+)
> >   create mode 100644 arch/arm64/boot/dts/rockchip/Makefile
> >   create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-r88.dts
> >   create mode 100644 arch/arm64/boot/dts/rockchip/rk3368.dtsi

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] dt-bindings: document rk3368 R89 board from Rockchip

[Heiko Stübner]

The initial board containing the rk3368 ARM64 soc.

Signed-off-by: Heiko Stuebner 
---
This should probably be simply in one branch with the Netxeon board
seen in the diff above, to prevent unncessary merge conflicts?

 Documentation/devicetree/bindings/arm/rockchip.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index b30bed1..c4119e0 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -30,3 +30,7 @@ Rockchip platforms device tree bindings
 - Netxeon R89 board:
 Required root node properties:
   - compatible = "netxeon,r89", "rockchip,rk3288";
+
+- Rockchip R88 board:
+Required root node properties:
+  - compatible = "rockchip,r88", "rockchip,rk3368";
-- 
2.1.4


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88 board

[Heiko Stübner]

In terms of peripherals the rk3368 is quite similar to the rk3288, which
makes it possible to have a lot basic components working in the first go.
More to follow once I tracked down all the tiny differences that still
exist in some parts.

With these dts files, the R88 board is able to boot from an attached
usb device and most likely from its emmc too, if the emmc uses a standard
partition table instead of Rockchip's own one - the emmc itself is
detected correctly.

Signed-off-by: Heiko Stuebner 
---
This of course needs the dt-binding header from clock series, so
a shared branch will be needed.

 arch/arm64/boot/dts/Makefile|   1 +
 arch/arm64/boot/dts/rockchip/Makefile   |   5 +
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 353 +++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi| 900 
 4 files changed, 1259 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/Makefile
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-r88.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index ad26a75..6916eec 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -6,6 +6,7 @@ dts-dirs += exynos
 dts-dirs += freescale
 dts-dirs += mediatek
 dts-dirs += qcom
+dts-dirs += rockchip
 dts-dirs += sprd
 dts-dirs += xilinx
 
diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
new file mode 100644
index 000..601e6a2
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts 
b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
new file mode 100644
index 000..d0c519b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
@@ -0,0 +1,353 @@
+/*
+ * Copyright (c) 2015 Heiko Stuebner 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3368.dtsi"
+
+/ {
+   model = "Rockchip R88";
+   compatible = "rockchip,r88", "rockchip,rk3368";
+
+   chosen {
+   stdout-path = "serial2:115200n8";
+   };
+
+   memory {
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+
+   emmc_pwrseq: emmc-pwrseq {
+   compatible = "mmc-pwrseq-emmc";
+   pinctrl-0 = <&emmc_reset>;
+   pinctrl-names = "default";
+   reset-gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+   };
+
+   keys: gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pwr_key>;
+
+   button@0 {
+   gpio-key,wakeup = <1>;
+   gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+   label = "GPIO Power";
+   linux,code = <116>;
+   };
+ 

[PATCH 2/4] arm64: defconfig: enable ARCH_ROCKCHIP

[Heiko Stübner]

Enable building Rockchip support in the defconfig.

Signed-off-by: Heiko Stuebner 
---
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index daefbf0..77bc5bc 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -34,6 +34,7 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_ARCH_EXYNOS7=y
 CONFIG_ARCH_FSL_LS2085A=y
 CONFIG_ARCH_MEDIATEK=y
+CONFIG_ARCH_ROCKCHIP=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_TEGRA=y
 CONFIG_ARCH_TEGRA_132_SOC=y
@@ -99,6 +100,7 @@ CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_DW=y
 CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
-- 
2.1.4


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] arm64: add Rockchip architecture entry

[Heiko Stübner]

The rk3368 is Rockchip's first ARM64 soc, build around 8 Cortex-A53 cores.

Signed-off-by: Heiko Stuebner 
---
 arch/arm64/Kconfig | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 290ed64..9af528a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -197,6 +197,16 @@ config ARCH_QCOM
help
  This enables support for the ARMv8 based Qualcomm chipsets.
 
+config ARCH_ROCKCHIP
+   bool "Rockchip Platforms"
+   select ARCH_HAS_RESET_CONTROLLER
+   select ARCH_REQUIRE_GPIOLIB
+   select PINCTRL
+   select PINCTRL_ROCKCHIP
+   help
+ This enables support for the ARMv8 based Rockchip chipsets,
+ like the RK3368.
+
 config ARCH_SEATTLE
bool "AMD Seattle SoC Family"
help
-- 
2.1.4


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] arm64: add initial support for the Rockchip rk3368

[Heiko Stübner]

This adds initial support for the new rk3368 ARM64 soc from Rockchip.

Overall it looks like someone dropped some A53 cores into a rk3288, so
it shares a lot of peripherals that only differ in details. Therefore
stuff like the mmc, usb, spi, i2c controllers work out of the box.
The support for the gmac already made it into the merge window as well
as the pinctrl support.

Interestingly, in its core the rk3368 seems trying to be a model student
with psci for smp and using scpi for ddr frequency scaling, although I
currently do not understand how the mailbox works yet. The display
controllers also are only minimally different so I'm hopefully to have
working graphics in the near-ish future :-)


As mentioned in the dts patch, this series depends on the dt-binding
header for the clock ids, so will need a shared branch once this is ready.


Heiko Stuebner (4):
  arm64: add Rockchip architecture entry
  arm64: defconfig: enable ARCH_ROCKCHIP
  arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88
board
  dt-bindings: document rk3368 R89 board from Rockchip

 Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
 arch/arm64/Kconfig |  10 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/Makefile  |   5 +
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts| 353 
 arch/arm64/boot/dts/rockchip/rk3368.dtsi   | 900 +
 arch/arm64/configs/defconfig   |   2 +
 7 files changed, 1275 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/Makefile
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-r88.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368.dtsi

-- 
2.1.4


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html