Re: [PATCH 0/8] Add support for CL-SOM-iMX7 and SBC-iMX7

[Igor Grinberg]

On 12/21/15 08:41, Shawn Guo wrote:
> On Wed, Dec 16, 2015 at 04:09:02PM +0200, Igor Grinberg wrote:
>> Hi Shawn,
>>
>> On 12/14/15 04:47, Shawn Guo wrote:
>>> On Mon, Dec 07, 2015 at 09:14:31AM +0200, Ilya Ledvich wrote:
 Ilya Ledvich (8):
   ARM: dts: imx7d: cl-som-imx7: add basic module support
   ARM: dts: imx7d: cl-som-imx7: add usb otg support
   ARM: dts: imx7d: cl-som-imx7: add eMMC support
   ARM: dts: imx7d: cl-som-imx7: add fec1 support
   ARM: dts: imx7d: cl-som-imx7: add eeprom support
   ARM: dts: imx7d: cl-som-imx7: add gpio extender support
   ARM: dts: imx7d: cl-som-imx7: add fec2 support
>>>
>>> For the initial board support submission, it doesn't really need such
>>> splitting.  Please merge above patches into one.
>>
>> Yeah, I know there is no need for such splitting, yet I think
>> if the splitting is done right - it is much simpler to review,
> 
> Not really for a initial board support.
> 
>> it provides a better bisectability (in case it will be needed in
>> the future),
> 
> This is an initial board support submission and all the devices added
> there should be functional.  The bisectability shouldn't needed in this
> case.
> 
>> and also if for some reason one (or more) patches are
>> needing some time consuming rework, others (earlier ones in the series)
>> can be accepted meanwhile.
> 
> It's not really the case for this series.

I'm glad you think so :-)

> 
>>
>> So, I really like to keep it this way, unless you insist.
> 
> Please merge them.

Ok.


-- 
Regards,
Igor.
--
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: imx28: add alternate auart4 pinmux

[Shawn Guo]

On Fri, Dec 11, 2015 at 01:36:26PM +, Mans Rullgard wrote:
> Add auart4 2-pin configuration on auart0 rts/cts pads.
> 
> Signed-off-by: Mans Rullgard 

Applied, thanks.
--
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 v1 1/2] drm: rockchip/hdmi: add Innosilicon HDMI support

[Yakir Yang]

Hi Mark,

On 12/21/2015 03:31 PM, Mark yao wrote:

On 2015年11月11日 15:46, Yakir Yang wrote:

+hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
+
+drm_connector_helper_add(&hdmi->connector,
+ &inno_hdmi_connector_helper_funcs);
+drm_connector_init(drm, &hdmi->connector, 
&inno_hdmi_connector_funcs,

+   DRM_MODE_CONNECTOR_HDMIA);
+
+hdmi->connector.encoder = encoder;


Pls remove "hdmi->connector.encoder = encoder;"

It would cause a error dump on atomic drm runtime:

WARNING: CPU: 3 PID: 74 at drivers/gpu/drm/drm_atomic_helper.c:682 
drm_atomic_helper_update_legacy_modeset_state+0x6c/0x200()


This issue can be explained from following thread:
https://lkml.org/lkml/2015/11/16/498



Done, thanks

- Yakir


Thanks.




--
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 v1 0/2] Introduce Innosilicon HDMI driver on Rockchip platforms

[Yakir Yang]

Hi Mark

On 12/21/2015 03:25 PM, Mark yao wrote:

Hi Yakir
I want to convert drm/rockchip to support atomic api,
I'd like you can do some modify to adapt it.



Sure, would update as soon as possible.

Thanks,
- Yakir


- Mark

On 2015年11月11日 15:45, Yakir Yang wrote:

Hi guys:

Here are a brief introduction to Innosilicon HDMI IP:
  - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant 
transmitter

  - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
  - Digital video interface supports a pixel size of 24, 30, 36, 
48bits color

depth in RGB
  - S/PDIF output supports PCM, Dolby Digital, DTS digital audio 
transmission

(32-192kHz Fs) using IEC60958 and IEC 61937
  - The EDID and CEC function are also supported by Innosilicon HDMI 
Transmitter

Controlle

This IP have been integrated on some Rockchip CPUs (like 
RK3036/RK312x), due
to those CPUs haven't been landed on manline kernel, so I creat a 
branch to

verify this series [https://github.com/rockchip-linux/kernel].

- Yakir


Yakir Yang (2):
   drm: rockchip/hdmi: add Innosilicon HDMI support
   dt-bindings: add document for Innosilicon HDMI on Rockchip platform

  .../display/rockchip/inno_hdmi-rockchip.txt|   50 +
  drivers/gpu/drm/rockchip/Kconfig   |8 +
  drivers/gpu/drm/rockchip/Makefile  |1 +
  drivers/gpu/drm/rockchip/inno_hdmi.c   | 1008 


  drivers/gpu/drm/rockchip/inno_hdmi.h   |  364 +++
  5 files changed, 1431 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt

  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.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: [RFC PATCH v1 1/2] drm: rockchip/hdmi: add Innosilicon HDMI support

[Mark yao]

On 2015年11月11日 15:46, Yakir Yang wrote:

+   hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
+
+   drm_connector_helper_add(&hdmi->connector,
+&inno_hdmi_connector_helper_funcs);
+   drm_connector_init(drm, &hdmi->connector, &inno_hdmi_connector_funcs,
+  DRM_MODE_CONNECTOR_HDMIA);
+
+   hdmi->connector.encoder = encoder;


Pls remove "hdmi->connector.encoder = encoder;"

It would cause a error dump on atomic drm runtime:

WARNING: CPU: 3 PID: 74 at drivers/gpu/drm/drm_atomic_helper.c:682 
drm_atomic_helper_update_legacy_modeset_state+0x6c/0x200()


This issue can be explained from following thread:
https://lkml.org/lkml/2015/11/16/498

Thanks.

--
Ｍark Yao


--
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 v1 0/2] Introduce Innosilicon HDMI driver on Rockchip platforms

[Mark yao]

Hi Yakir
I want to convert drm/rockchip to support atomic api,
I'd like you can do some modify to adapt it.

- Mark

On 2015年11月11日 15:45, Yakir Yang wrote:

Hi guys:

Here are a brief introduction to Innosilicon HDMI IP:
  - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
  - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
  - Digital video interface supports a pixel size of 24, 30, 36, 48bits color
depth in RGB
  - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission
(32-192kHz Fs) using IEC60958 and IEC 61937
  - The EDID and CEC function are also supported by Innosilicon HDMI Transmitter
Controlle

This IP have been integrated on some Rockchip CPUs (like RK3036/RK312x), due
to those CPUs haven't been landed on manline kernel, so I creat a branch to
verify this series [https://github.com/rockchip-linux/kernel].

- Yakir


Yakir Yang (2):
   drm: rockchip/hdmi: add Innosilicon HDMI support
   dt-bindings: add document for Innosilicon HDMI on Rockchip platform

  .../display/rockchip/inno_hdmi-rockchip.txt|   50 +
  drivers/gpu/drm/rockchip/Kconfig   |8 +
  drivers/gpu/drm/rockchip/Makefile  |1 +
  drivers/gpu/drm/rockchip/inno_hdmi.c   | 1008 
  drivers/gpu/drm/rockchip/inno_hdmi.h   |  364 +++
  5 files changed, 1431 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
  create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h




--
Ｍark Yao


--
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/3] ARM: imx: select HAVE_ARM_ARCH_TIMER if selected i.MX7D

[Shawn Guo]

On Fri, Dec 11, 2015 at 07:12:11AM +0800, frank...@freescale.com wrote:
> From: Frank Li 
> 
> i.MX7D Supported ARCH Timer.
> 
> Signed-off-by: Frank Li 
> ---
>  arch/arm/mach-imx/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 0ac180f..061dea4 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -563,6 +563,7 @@ config SOC_IMX7D
>   select ARM_GIC
>   select HAVE_IMX_ANATOP
>   select HAVE_IMX_MMDC
> + select HAVE_ARM_ARCH_TIMER

Please sort these selections alphabetically.

Shawn

>   help
>   This enables support for Freescale i.MX7 Dual processor.
>  
> -- 
> 2.5.2
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
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: imx7d: add arch timer

[Shawn Guo]

On Thu, Dec 17, 2015 at 03:23:59PM -0600, Zhi Li wrote:
> On Thu, Dec 17, 2015 at 2:45 PM, Stefan Agner  wrote:
> > On 2015-12-10 15:12, frank...@freescale.com wrote:
> >> From: Frank Li 
> >>
> >> add cortex a7 arch timer.
> >> uboot v2016.01-rc2 supported psci basic support.
> >> smp can be supported by psci
> >
> > This sounds a bit overly simplified log message. I am not very into this
> > PSCI topic, is this a prerequisit for the ARM arch timers? Maybe you
> > could elaborate that a bit more.
> 
> No.
> But according to previous discussion. Shawn want us to use psci to enable
> second core.  We need enable arch timer if second core enabled.

I guess you can make the commit log a bit better by commenting
the relationship between the arch timer and secondary core.

Shawn
--
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/8] Add support for CL-SOM-iMX7 and SBC-iMX7

[Shawn Guo]

On Wed, Dec 16, 2015 at 04:09:02PM +0200, Igor Grinberg wrote:
> Hi Shawn,
> 
> On 12/14/15 04:47, Shawn Guo wrote:
> > On Mon, Dec 07, 2015 at 09:14:31AM +0200, Ilya Ledvich wrote:
> >> Ilya Ledvich (8):
> >>   ARM: dts: imx7d: cl-som-imx7: add basic module support
> >>   ARM: dts: imx7d: cl-som-imx7: add usb otg support
> >>   ARM: dts: imx7d: cl-som-imx7: add eMMC support
> >>   ARM: dts: imx7d: cl-som-imx7: add fec1 support
> >>   ARM: dts: imx7d: cl-som-imx7: add eeprom support
> >>   ARM: dts: imx7d: cl-som-imx7: add gpio extender support
> >>   ARM: dts: imx7d: cl-som-imx7: add fec2 support
> > 
> > For the initial board support submission, it doesn't really need such
> > splitting.  Please merge above patches into one.
> 
> Yeah, I know there is no need for such splitting, yet I think
> if the splitting is done right - it is much simpler to review,

Not really for a initial board support.

> it provides a better bisectability (in case it will be needed in
> the future),

This is an initial board support submission and all the devices added
there should be functional.  The bisectability shouldn't needed in this
case.

> and also if for some reason one (or more) patches are
> needing some time consuming rework, others (earlier ones in the series)
> can be accepted meanwhile.

It's not really the case for this series.

> 
> So, I really like to keep it this way, unless you insist.

Please merge them.

Shawn
--
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: imx7d: cl-som-imx7: add basic module support

[Shawn Guo]

On Wed, Dec 16, 2015 at 04:01:08PM +0200, Igor Grinberg wrote:
> Hi Shawn,
> 
> On 12/14/15 04:43, Shawn Guo wrote:
> > On Thu, Dec 10, 2015 at 04:01:37PM +0200, Igor Grinberg wrote:
> >> From: Ilya Ledvich 
> 
> [...]
> 
> >> diff --git a/Documentation/devicetree/bindings/arm/fsl.txt 
> >> b/Documentation/devicetree/bindings/arm/fsl.txt
> >> index 34c88b0..30b0ba1 100644
> >> --- a/Documentation/devicetree/bindings/arm/fsl.txt
> >> +++ b/Documentation/devicetree/bindings/arm/fsl.txt
> >> @@ -53,6 +53,10 @@ i.MX6 Quad SABRE Automotive Board
> >>  Required root node properties:
> >>  - compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
> >>  
> >> +i.MX7D CL-SOM-iMX7 Board
> >> +Required root node properties:
> >> +- compatible = "compulab,cl-som-imx7", "fsl,imx7d";
> >> +
> > 
> > This is not a board produced by FSL, so it should be documented in
> > fsl.txt.
> 
> You mean _should not_ be documented in fsl.txt, right?

Right.  Sorry.

> Ok, I have no problem with that, we've just used the same approach OMAP
> takes - all the OMAP based boards are documented in the same file:
> Documentation/devicetree/bindings/arm/omap/omap.txt

omap.txt is probably fine, as it's not ti.txt.

> 
> Do you think we should document it in:
> Documentation/devicetree/bindings/arm/compulab-boards.txt
> (this file should already exist in arm-soc/next/dt)?

Yeah, if the file already exist, it's the best option.  But, as it
doesn't exist on my tree, I can not apply this change.

> 
> > 
> >>  Generic i.MX boards
> >>  ---
> >>  
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index 30bbc37..83ed521 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -350,6 +350,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
> >>  dtb-$(CONFIG_SOC_IMX6UL) += \
> >>imx6ul-14x14-evk.dtb
> >>  dtb-$(CONFIG_SOC_IMX7D) += \
> >> +  imx7d-cl-som-imx7.dtb \
> >>imx7d-sdb.dtb
> >>  dtb-$(CONFIG_SOC_LS1021A) += \
> >>ls1021a-qds.dtb \
> >> diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts 
> >> b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> >> new file mode 100644
> >> index 000..ba05198
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> >> @@ -0,0 +1,150 @@
> >> +/*
> >> + * Support for CompuLab CL-SOM-iMX7 System-on-Module
> >> + *
> >> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> >> + * Author: Ilya Ledvich 
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms of the GNU General Public License version 2 as 
> >> published by
> >> + * the Free Software Foundation.
> >> + */
> > 
> > GPL/X11 dual licence is generally suggested for newly added dts files,
> > as it will let non-Linux OS use them.
> 
> I don't remember we've used this one before...
> Can you please point to an example?

The following command will give you a plenty of examples.

$ git grep X11 arch/arm/boot/dts

Shawn
--
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: [linux-sunxi][PATCH v2 2/5] ARM: dts: sun7i: Add Itead A20 Core support

[Chen-Yu Tsai]

On Sat, Dec 19, 2015 at 11:05 PM,   wrote:
> From: Marcus Cooper 
>
> The A20 Itead Core module comes with 4GB NAND and 1GB DDR RAM. All of the
> I/O interfaces are exposed via 4 groups of 2*30 1mm pitched female headers.
>
> Signed-off-by: Marcus Cooper 

Acked-by: Chen-Yu Tsai 
--
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: [linux-sunxi][PATCH v2 1/5] ARM: dts: sunxi: Add sunxi-itead-core-common.dtsi

[Chen-Yu Tsai]

Hi,

On Sat, Dec 19, 2015 at 11:05 PM,   wrote:
> From: Marcus Cooper 
>
> Itead have a core module board that can be populated with either
> an Allwinner A10 or A20 SoC. This patch creates a common dtsi
> which these boards can use.
>
> Signed-off-by: Marcus Cooper 
> ---
>  arch/arm/boot/dts/sunxi-itead-core-common.dtsi | 114 
> +
>  1 file changed, 114 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sunxi-itead-core-common.dtsi
>
> diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi 
> b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> new file mode 100644
> index 000..41449fa
> --- /dev/null
> +++ b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> @@ -0,0 +1,114 @@
> +/*
> + * Copyright 2015 - Marcus Cooper 
> + *
> + * 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 "sunxi-common-regulators.dtsi"
> +
> +#include 
> +#include 
> +#include 
> +
> +/ {
> +   aliases {
> +   serial0 = &uart0;
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };
> +};
> +
> +&ahci {
> +   target-supply = <®_ahci_5v>;
> +   status = "okay";
> +};
> +
> +&codec {
> +   status = "okay";
> +};
> +
> +&ehci0 {
> +   status = "okay";
> +};
> +
> +&ehci1 {
> +   status = "okay";
> +};
> +
> +&i2c1 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c1_pins_a>;
> +   status = "okay";
> +};
> +
> +&ohci0 {
> +   status = "okay";
> +};
> +
> +&ohci1 {
> +   status = "okay";
> +};
> +
> +®_ahci_5v {
> +   pinctrl-0 = <&ahci_pwr_pin_a>;
> +   gpio = <&pio 1 8 GPIO_ACTIVE_HIGH>;

These 2 lines are in sunxi-common-regulators.dtsi. No need to repeat them here.

Otherwise,

Acked-by: Chen-Yu Tsai 

> +   status = "okay";
> +};
> +
> +®_usb1_vbus {
> +   status = "okay";
> +};
> +
> +®_usb2_vbus {
> +   status = "okay";
> +};
> +
> +&uart0 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&uart0_pins_a>;
> +   status = "okay";
> +};
> +
> +&usbphy {
> +   usb1_vbus-supply = <®_usb1_vbus>;
> +   usb2_vbus-supply = <®_usb2_vbus>;
> +   status = "okay";
> +};
> --
> 1.9.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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] ARM: dts: imx6q-icore-rqs: Add Engicam IMX6 Q7 initial support

[Shawn Guo]

On Wed, Dec 16, 2015 at 07:12:05PM +0100, Michael Trimarchi wrote:
> Hi
> 
> I have address most of the changes but I have problem when I remove
> the group of pinctrl as you suggest
...
> > > > +&iomuxc {
> > > 
> > > Suggest move iomuxc node to the bottom to make the file a bit easier to
> > > read.
> > > 
> > 
> > Ok
> > 
> > 
> > > > +   imx6qdl-icore-rqs {
> > > > +
> > > 
> > > With commit 5fcdf6a7ed95 (pinctrl: imx: Allow parsing DT without function
> > > nodes) in place, we can now save this container.
> > > 
> 
> If I save this I can not register usb. Group is not found
> 
> [2.768476] imx6q-pinctrl 20e.iomuxc: unable to find group for node 
> usdhc1grp-1
> [2.768844] imx6q-pinctrl 20e.iomuxc: unable to find group for node 
> usdhc1grp-1
> [2.768932] sdhci-esdhc-imx: probe of 219.usdhc failed with error -22
> [2.768994] imx6q-pinctrl 20e.iomuxc: unable to find group for node 
> usdhc3grp-2
> [2.769240] imx6q-pinctrl 20e.iomuxc: unable to find group for node 
> usdhc3grp-2
> [2.769322] sdhci-esdhc-imx: probe of 2198000.usdhc failed with error -22
> [2.769381] imx6q-pinctrl 20e.iomuxc: unable to find group for node 
> usdhc4grp-1
> [2.769621] imx6q-pinctrl 20e.iomuxc: unable to find group for node 
> usdhc4grp-1
> [2.769701] sdhci-esdhc-imx: probe of 219c000.usdhc failed with error -22

I'm not sure if you got my comment correct, but what I meant is
something like below.

&iomuxc {
   pinctrl_audmux_4: audmux-4 {
   fsl,pins = <
   MX6QDL_PAD_DISP0_DAT20__AUD4_TXC  0x130b0
   MX6QDL_PAD_DISP0_DAT21__AUD4_TXD  0x110b0
   MX6QDL_PAD_DISP0_DAT22__AUD4_TXFS 0x130b0
   MX6QDL_PAD_DISP0_DAT23__AUD4_RXD  0x130b0
   >;
   };

   pinctrl_enet_3: enetgrp-3 {
   fsl,pins = <
   MX6QDL_PAD_ENET_MDIO__ENET_MDIO   0x1b0b0
   MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
   MX6QDL_PAD_RGMII_TXC__RGMII_TXC   0x1b0b0
   MX6QDL_PAD_RGMII_TD0__RGMII_TD0   0x1b0b0
   MX6QDL_PAD_RGMII_TD1__RGMII_TD1   0x1b0b0
   MX6QDL_PAD_RGMII_TD2__RGMII_TD2   0x1b0b0
   MX6QDL_PAD_RGMII_TD3__RGMII_TD3   0x1b0b0
   MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
   MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK  0x1b0b0
   MX6QDL_PAD_RGMII_RXC__RGMII_RXC   0x1b0b0
   MX6QDL_PAD_RGMII_RD0__RGMII_RD0   0x1b0b0
   MX6QDL_PAD_RGMII_RD1__RGMII_RD1   0x1b0b0
   MX6QDL_PAD_RGMII_RD2__RGMII_RD2   0x1b0b0
   MX6QDL_PAD_RGMII_RD3__RGMII_RD3   0x1b0b0
   MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
   MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
   >;
   };

   ..
};

Is this what you did?

Shawn
--
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: sun5i: Add dts file for the Empire Electronix D709 tablet

[Chen-Yu Tsai]

Hi,

On Sun, Dec 20, 2015 at 7:43 PM, Hans de Goede  wrote:
> The Empire Electronix D709 tablet is a fairly standard 7" A13 tablet,
> featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone jack.
>
> Empire Electronix is written on the back of the tablet, the D709 model
> info can be found in the about tablet menu in android.
>
> The PCB has no markings to speak of.
>
> This dts file does not add support for the ft5x touchscreen found at
> i2c bus 1, addr 0x38, irq PG11, because it does not work out of the box.
> It seems it has been flashed with the wrong firmware and needs to have
> alternative firmware uploaded at boot to make the touchscreen work
> properly, when hot-booting from android into an upstream kernel the
> touchscreen does work.
>
> The Memsic MXC622X accelerometer at i2c bus 1, addr 0x15 also is not
> enabled as there is no driver for it.
>
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/Makefile |   1 +
>  .../boot/dts/sun5i-a13-empire-electronix-d709.dts  | 241 
> +

The contents seem the same as sun5i-q8-common.dtsi and sun5i-a13-q8-tablet.dts.
Any chance you could use those instead?

On the side, any thoughts on how to handle the differences between various "Q8"
tablets, like different I2C-based sensors and WiFi chips?

I'm asking because with Maxime's couple-regulator we should be able to get the
RTL8723BS on the Q8 A23/33 v1.5 working.

Regards
ChenYu

>  2 files changed, 242 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.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 1/5] ARM: dts: sun4i: Add touchscreen node to inet9f-rev03 tablet dts file

[Chen-Yu Tsai]

On Sun, Dec 20, 2015 at 7:42 PM, Hans de Goede  wrote:
> Add a node describing the focaltech ft5406ee8 touchscreen found on
> inet-9f-rev03 / qware qw tb-g100 tablets.
>
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts 
> b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
> index ca49b0d..d39067e 100644
> --- a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
> @@ -253,6 +253,16 @@
> pinctrl-names = "default";
> pinctrl-0 = <&i2c2_pins_a>;
> status = "okay";
> +
> +   ft5406ee8: touchscreen@38 {
> +   compatible = "edt,edt-ft5406";
> +   reg = <0x38>;
> +   interrupt-parent = <&pio>;
> +   interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
> +   pinctrl-names = "default";

Name only and no references?

ChenYu

> +   touchscreen-size-x = <800>;
> +   touchscreen-size-y = <480>;
> +   };
>  };
>
>  &lradc {
> --
> 2.5.0
>
--
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] ARM: dts: sun4i: Add touchscreen node to inet97fv2 dts file

[Chen-Yu Tsai]

On Sun, Dec 20, 2015 at 7:43 PM, Hans de Goede  wrote:
> Add a node describing the focaltech ft5306de4 touchscreen found on
> inet97fv2 tablets.
>
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts 
> b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> index 77c31da..74dd458 100644
> --- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
> @@ -48,6 +48,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  / {
> model = "INet-97F Rev 02";
> @@ -93,6 +94,16 @@
> pinctrl-names = "default";
> pinctrl-0 = <&i2c2_pins_a>;
> status = "okay";
> +
> +   ft5406ee8: touchscreen@38 {
> +   compatible = "edt,edt-ft5406";
> +   reg = <0x38>;
> +   interrupt-parent = <&pio>;
> +   interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
> +   pinctrl-names = "default";

Name only and no references?

ChenYu

> +   touchscreen-size-x = <800>;
> +   touchscreen-size-y = <480>;
> +   };
>  };
>
>  &lradc {
> --
> 2.5.0
>
--
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] ARM: dts: sun4i: Add touchscreen node to chuwi-v7 dts file

[Chen-Yu Tsai]

On Sun, Dec 20, 2015 at 7:42 PM, Hans de Goede  wrote:
> Add a node describing the focaltech ft5306de4 touchscreen found on
> chuwi-v7-cw0825 tablets.
>
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts 
> b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> index 5366089..c71b654 100644
> --- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
> @@ -45,6 +45,7 @@
>  #include "sunxi-common-regulators.dtsi"
>  #include 
>  #include 
> +#include 
>
>  / {
> model = "Chuwi V7 CW0825";
> @@ -88,6 +89,16 @@
> pinctrl-names = "default";
> pinctrl-0 = <&i2c2_pins_a>;
> status = "okay";
> +
> +   ft5306de4: touchscreen@38 {
> +   compatible = "edt,edt-ft5406";
> +   reg = <0x38>;
> +   interrupt-parent = <&pio>;
> +   interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
> +   pinctrl-names = "default";

Only a name and no references?

ChenYu

> +   touchscreen-size-x = <1024>;
> +   touchscreen-size-y = <768>;
> +   };
>  };
>
>  &lradc {
> --
> 2.5.0
>
--
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: dts: sun7i: Enable gmac on Wits Pro A20 DKT

[Chen-Yu Tsai]

On Sun, Dec 20, 2015 at 7:43 PM, Hans de Goede  wrote:
> The Wits Pro A20 DKT has a gbit ethernet port, enable it.
>
> Signed-off-by: Hans de Goede 

Acked-by: Chen-Yu Tsai 
--
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] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

Hi Bjorn, can you comment on this. Marc has also replied for query on 
irq_dispose_mapping().

> Subject: RE: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL
> PCIe Host Controller
> 
> > Subject: Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for
> > Xilinx NWL PCIe Host Controller
> >
> > [+cc Marc for irq_dispose_mapping() question]
> >
> > On Thu, Dec 10, 2015 at 02:10:34PM +, Bharat Kumar Gogada wrote:
> > I'm trying to figure out what the difference is between these two
> > checks and why you have both of them:
> >
> > > + if (bus->number == pcie->root_busno && devfn > 0)
> > > + if (bus->primary == pcie->root_busno && devfn > 0)
> >
> > If I understand correctly, pcie->root_busno is the bus number of the
> > Root Port device (likely 00).  I think the "bus->number ==
> > pcie->root_busno && devfn > 0" check means that the Root Port, e.g.,
> > 00:00.0, is the only device allowed on bus 00.  Often a Root Complex
> > contains several Root Ports and other integrated devices that typically are
> on bus 00.
> > But in your case, I think you're saying there is only the single Root
> > Port and no other devices.
> >
> > I think that first check takes care of everything on bus 00, so I'm
> > trying to figure out what the second check is for.  Assume your Root
> > Port is device
> > 00:00.0 and it is a bridge to [bus 01-ff].  Then we have two pci_bus
> > structs with these values:
> >
> >   bus->number = 00
> >   bus->primary = 00
> >   bus->busn_res = [bus 00-ff]
> >
> >   bus->number = 01
> >   bus->primary = 00
> >   bus->busn_res = [bus 01-ff]
> >
> > Because of the first check, 00:00.0 is the only possible device on bus
> > 00, and because of the second check, 01:00.0 is the only possible device on
> bus 01.
> > Therefore, you don't support a multifunction device connected to the
> > Root Port.  Right?
> >
> We support multifunction devices also, so this check should not be there, will
> remove this check in next patch.
> 
> > > > > + return false;
> > > > > +
> > > > > + return true;
> > > > > +}
> > > > > + * nwl_setup_sspl - Set Slot Power limit
> > > > > + *
> > > > > + * @pcie: PCIe port information  */ static int
> > > > > +nwl_setup_sspl(struct nwl_pcie *pcie)
> > > >
> > > The Set_Slot_Power_Limit Message includes a one DW data payload. The
> > > data payload is copied from the Slot Capabilities register of the
> > > Downstream Port and is written into the Device Capabilities register
> > > of the Upstream Port on the other side of the Link. Bits 9:8 of the
> > > data payload map to the Slot Power Limit Scale field and bits 7:0
> > > map to the Slot Power Limit Value field. Bits 31:10 of the data
> > > payload must be set to all 0's by the Transmitter and ignored by the
> Receiver.
> >
> > > This Message is sent automatically by the Downstream Port (of a Root
> > > Complex or a Switch) when one of the following events occurs:
> > > -> On a Configuration Write to the Slot Capabilities register (see
> > > Section 7.8.9) when the Data Link Layer reports DL_Up status.
> >
> > I interpret this as meaning "the *hardware* automatically sends a
> > Set_Slot_Power_Limit Message."  There's no mention of software doing
> > anything other than the configuration write.
> >
> > If your hardware doesn't do that, I think it's a defect.  It's fine to
> > work around it, but we should have a comment to that effect so people
> > don't copy the code to new drivers that don't need it.
> 
> Our hardware is not capable of doing it, so we are doing it software. Yes I 
> will
> add some comments.
> 
> >
> > It's a little strange that 7.8.9 talks about writing to this register
> > when all of its fields are HwInit and supposedly read-only.  I had
> > assumed devices would use strapping or implementation-specific
> > registers to set the Slot Power values, but maybe some devices use direct
> writes to Slot Capabilities instead.
> >
> > BTW, I noticed a related lspci bug: it didn't decode the Capture Slot
> > Power Limit in Device Capabilities of Endpoints.  I posted a fix for that
> separately.
> >
> > The Slot Power Limit (in Slot Capabilities) indicates how much power
> > the slot can supply to a downstream device.  That's a function of the
> > platform design, so it seems like this is something you want to set
> > via DT or some other mechanism that knows about the platform.
> > Intercepting all config writes and updating it with whatever the
> > caller supplies doesn't sound wise.  The value might be coming from
> > setpci or some other source with no knowledge of the platform.
> 
> Agreed, but this is what can be done, it is difficult to determine who does
> what.
> >
> > > > > + status = nwl_bridge_readl(pcie,
> TX_PCIE_MSG)
> > > > > +   & MSG_DONE_BIT;
> > > > > + if (status) {
> > > > > + status = nwl_bridge_readl(pcie,
> > > > TX_PCIE_MSG)
> > > > > +  

Re: I2C eeprom compatibles? (was Re: [PATCH/RFC 03/19] ARM: shmobile: gose: add i2c2 bus to device tree)

[Simon Horman]

On Fri, Dec 18, 2015 at 11:32:15AM +0100, Wolfram Sang wrote:
> On Fri, Dec 18, 2015 at 10:06:48AM +0100, Arnd Bergmann wrote:
> > On Friday 18 December 2015 08:35:32 Wolfram Sang wrote:
> > > > 
> > > > It seems to me that we have some consensus around:
> > > > 
> > > >   compatible = "renesas,r1ex24002", "24c02";
> > > 
> > > Thinking again, "generic,24c02" or "generic-24c02" could also be an
> > > option.
> > > 
> > > > Should this be added to 
> > > > Documentation/devicetree/bindings/eeprom/eeprom.txt ?
> > > > Or documented elsewhere?
> > > 
> > > Probably we need a DT maintainers advice here? I don't mind vendor
> > > specific compatibles being documented, but I'm reluctant to add all
> > > these compatibles for the myriads of I2C eeproms to the at24 driver. 99%
> > > are covered by the generic case.
> > > 
> > > Adding DT to CC.
> > 
> > I'd rather use some vendor string in addition to 24c02. Isn't this 
> > originally
> > an Atmel part? In that case, using "atmel,24c02" as the most generic string
> > would be appropriate,
> 
> Yeah, the at24 driver is named after Atmel chips AFAIR. Having "atmel,*"
> as the generic fallback sounds like a good solution to me, too.
> 
> > and IIRC the i2c framework will just match that with
> > the "24c02" entry in the i2c_device_id list.
> 
> True, although this behaviour is often complained about. There have been
> attempts to make i2c/spi behave like the rest of the DT world and to
> deprecate the current way. It didn't happen because of lots gory details,
> however :/

My reading of the above is that we are currently leaning towards:

compatible = "renesas,r1ex24002", "atmel,24c02";

And we are unsure what to do about the documentation.
--
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] extcon: add Maxim MAX3355 driver

[Chanwoo Choi]

Hi,

On 2015년 12월 21일 02:15, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/20/2015 05:31 PM, Chanwoo Choi wrote:
> 
>> This patch depend on GPIOLIB configuration as following:
>> I modified it with following diff and applied it.
>>
>> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
>> index ba4db7d..3d89e60 100644
>> --- a/drivers/extcon/Kconfig
>> +++ b/drivers/extcon/Kconfig
>> @@ -54,6 +54,7 @@ config EXTCON_MAX14577
>>
>>   config EXTCON_MAX3355
>>  tristate "Maxim MAX3355 USB OTG EXTCON Support"
>> +   depends on GPIOLIB || COMPILE_TEST
> 
>If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST?
>And no, it shouldn't depend on gpiolib. It has empty stubs for the case of 
> CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers, I'll 
> look into it.

Yes. When GPIOLIB is disabled, the build issue don't happen.
because include/linux/gpio/consumer.h implement the dummy function
for all gpio functions if CONFIG_GPIOLIB is disabled.

For correct operation of max3355, you should add the dependency 
to the extcon-max3355.c driver. This driver use the GPIO library
certainly.

COMPILE_TEST is used for just build test. You can see the detailed data[1].
[1] https://lkml.org/lkml/2013/5/22/155

Thanks,
Chanwoo Choi
--
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/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for mt2701

[Daniel Kurtz]

Hi Biao and Joe,

On Fri, Dec 18, 2015 at 11:13 PM, Yingjoe Chen
 wrote:
> On Fri, 2015-12-11 at 17:07 +0800, Biao Huang wrote:
>> Add mt2701 support using mediatek common pinctrl driver.
>> MT2701 have some special pins need an extra setting register
>> than other ICs, so adding this support to common code.
>>
>> Signed-off-by: Biao Huang 
>> ---
>>  drivers/pinctrl/mediatek/Kconfig  |6 +
>>  drivers/pinctrl/mediatek/Makefile |1 +
>>  drivers/pinctrl/mediatek/pinctrl-mt2701.c |  590 +++
>>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |   14 +
>>  drivers/pinctrl/mediatek/pinctrl-mtk-common.h |   12 +-
>>  drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h | 2323 
>> +
>>  6 files changed, 2945 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2701.c
>>  create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h
>
> This patch looks good to me.
> Thanks
>
> Acked-by: Yingjoe Chen 

>
> Joe.C
>
>>
>> diff --git a/drivers/pinctrl/mediatek/Kconfig 
>> b/drivers/pinctrl/mediatek/Kconfig
>> index 02f6f92..13e9939 100644
>> --- a/drivers/pinctrl/mediatek/Kconfig
>> +++ b/drivers/pinctrl/mediatek/Kconfig
>> @@ -9,6 +9,12 @@ config PINCTRL_MTK_COMMON
>>   select OF_GPIO
>>
>>  # For ARMv7 SoCs
>> +config PINCTRL_MT2701
>> + bool "Mediatek MT2701 pin control" if COMPILE_TEST && !MACH_MT2701

This is 'bool', so can never be built as a module...

[snip...]

>> +module_init(mtk_pinctrl_init);

Yingjoe - you just ack'ed this change for the other MTK pinctrl.
So, let's apply it here too:

-module_init(mtk_pinctrl_init);
+arch_initcall(mtk_pinctrl_init);

>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("MediaTek MT2701 Pinctrl Driver");
>> +MODULE_AUTHOR("Biao Huang ");

And remove these lines since this isn't a module.

-Dan
--
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/8 v6] thermal: rcar: enable to use thermal-zone on DT

[Kuninori Morimoto]

Hi

> > +thermal: thermal@e61f {
> > +   compatible ="renesas,thermal-r8a7790",
> > +   "renesas,rcar-gen2-thermal",
> > +   "renesas,rcar-thermal";
> 
> Isn't having both mutually exclusive?

"rcar-thermal" is very basic version of "rcar-gen2",
and "rcar-gen2" is common/basic version of "thermal-r8xxx"
--
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 3/5] PCI: qcom: Add Qualcomm PCIe controller driver

[Bjorn Andersson]

On Fri, Dec 18, 2015 at 5:44 AM, kbuild test robot  wrote:
> Hi Stanimir,
>
> [auto build test WARNING on next-20151218]
> [also build test WARNING on v4.4-rc5]
> [cannot apply to pci/next robh/for-next v4.4-rc5 v4.4-rc4 v4.4-rc3]
>
> url:
> https://github.com/0day-ci/linux/commits/Stanimir-Varbanov/Qualcomm-PCIe-driver-and-designware-fixes/20151218-205427
>
>
> coccinelle warnings: (new ones prefixed by >>)
>
>>> drivers/pci/host/pcie-qcom.c:188:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>drivers/pci/host/pcie-qcom.c:220:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
> Please review and possibly fold the followup patch.
>

I disagree with this "recommendation" as it's only outcome will be asymmetry.

I think this script should be changed to only warn if there's a single
IS_ERR/PTR_ERR at the end of the function, not if there's a list of
them and this would replace the last one.

Regards,
Bjorn
--
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/8] Raspberry Pi 2 support.

[Alexander Aring]

On Fri, Dec 18, 2015 at 11:08:26AM +0100, Alexander Aring wrote:
...
> Uncompressing Linux... done, booting the kernel.
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.4.0-rc5+ (alex@omega) (gcc version 4.9.2 
> (OSELAS.Toolchain-2014.12.1) ) #989 Fri Dec 18 10:54:40 CET 2015
> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] Machine model: Raspberry Pi 2 Model B Rev 1.1
> [0.00] bootconsole [earlycon0] enabled
> [0.00] Truncating RAM at 0x-0x3e00 to -0x3000
> [0.00] Consider using a HIGHMEM enabled kernel.

I can remove this "note" when I enable CONFIG_HIGHMEM.

> [0.00] Memory policy: Data cache writeback
> [0.00] BUG: mapping for 0x3f201000 at 0xf0201000 out of vmalloc space
> [0.00] [ cut here ]
> [0.00] WARNING: CPU: 0 PID: 0 at arch/arm/kernel/devtree.c:149 
> arm_dt_init_cpu_maps+0x100/0x1a4()
> [0.00] DT /cpu 2 nodes greater than max cores 1, capping them
> [0.00] Modules linked in:
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc5+ #989
> [0.00] Hardware name: BCM2835
> [0.00] [] (unwind_backtrace) from [] 
> (show_stack+0x20/0x24)
> [0.00] [] (show_stack) from [] 
> (dump_stack+0x20/0x28)
> [0.00] [] (dump_stack) from [] 
> (warn_slowpath_common+0x9c/0xc4)
> [0.00] [] (warn_slowpath_common) from [] 
> (warn_slowpath_fmt+0x40/0x48)
> [0.00] [] (warn_slowpath_fmt) from [] 
> (arm_dt_init_cpu_maps+0x100/0x1a4)
> [0.00] [] (arm_dt_init_cpu_maps) from [] 
> (setup_arch+0x6f4/0x89c)
> [0.00] [] (setup_arch) from [] 
> (start_kernel+0x74/0x3a4)
> [0.00] [] (start_kernel) from [<8078>] (0x8078)
> [0.00] ---[ end trace cb88537fdc8fa200 ]---
> [0.00] DT missing boot CPU MPIDR[23:0], fall back to default 
> cpu_logical_map
> [0.00] CPU: All CPU(s) started in SVC mode.

I can remove this WARNING when I enable CONFIG_SMP.

> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 195072
> [0.00] Kernel command line: earlyprintk console=ttyAMA0 
> dma.dmachans=0x7f35 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=576 
> bcm2709.boardrev=0xa01041 bcm2709.serial=0x3449476 
> smsc95xx.macaddr=B8:27:EB:44:94:76 bcm2708_fb.fbswap=1 
> bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 
> sdhci-bcm2708.emmc_clock_freq=25000 vc_mem.mem_base=0x3ea0 
> vc_mem.mem_size=0x3f00  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 
> kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait 
> consoleblank=0 rw
> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> bytes)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Memory: 770408K/786432K available (5713K kernel code, 426K 
> rwdata, 1720K rodata, 420K init, 687K bss, 16024K reserved, 0K cma-reserved)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
> [0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
> [0.00] modules : 0xbf00 - 0xc000   (  16 MB)
> [0.00]   .text : 0xc0008000 - 0xc074a7cc   (7434 kB)
> [0.00]   .init : 0xc074b000 - 0xc07b4000   ( 420 kB)
> [0.00]   .data : 0xc07b4000 - 0xc081e910   ( 427 kB)
> [0.00].bss : 0xc081e910 - 0xc08ca80c   ( 688 kB)
> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [0.00] NR_IRQS:16 nr_irqs:16 16
> [0.00] Kernel panic - not syncing: /soc/local_intc: unable to map 
> local interrupt registers
> [0.00] 
> [0.00] CPU: 0 PID: 0 Comm: swapper Tainted: GW   
> 4.4.0-rc5+ #989
> [0.00] Hardware name: BCM2835
> [0.00] [] (unwind_backtrace) from [] 
> (show_stack+0x20/0x24)
> [0.00] [] (show_stack) from [] 
> (dump_stack+0x20/0x28)
> [0.00] [] (dump_stack) from [] (panic+0x84/0x210)
> [0.00] [] (panic) from [] 
> (bcm2836_arm_irqchip_l1_intc_of_init+0x94/0x110)
> [0.00] [] (bcm2836_arm_irqchip_l1_intc_of_init) from 
> [] (of_irq_init+0x1a0/0x2a8)
> [0.00] [] (of_irq_init) from [] 
> (irqchip_init+0x14/0x1c)
> [0.00] [] (irqchip_init) from [] 
> (init_IRQ+0x28/0x88)
> [0.00] [] (init_IRQ) from [] 
> (start_kernel+0x20c/0x3a4)
> [0.00] [] (start_kernel) from [<8078>] (

Re: [PATCH v5] extcon: add Maxim MAX3355 driver

[Sergei Shtylyov]

Hello.

On 12/20/2015 05:31 PM, Chanwoo Choi wrote:


This patch depend on GPIOLIB configuration as following:
I modified it with following diff and applied it.

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index ba4db7d..3d89e60 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -54,6 +54,7 @@ config EXTCON_MAX14577

  config EXTCON_MAX3355
 tristate "Maxim MAX3355 USB OTG EXTCON Support"
+   depends on GPIOLIB || COMPILE_TEST


   If it won't compile w/o gpiolib, what's the use of COMIPLE_TEST?
   And no, it shouldn't depend on gpiolib. It has empty stubs for the case of 
CONFIG_GPIOLIB=n. Obviously something is wrong with the GPIO headers, I'll 
look into it.


[...]


Thanks,
Chanwoo Choi


MBR, Sergei

--
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 v2] ARM: l2x0: make it possible to disable outer sync from DT

[Russell King - ARM Linux]

On Sat, Dec 19, 2015 at 09:39:24PM -0600, Rob Herring wrote:
> On Mon, Dec 14, 2015 at 09:53:05PM +0100, Linus Walleij wrote:
> > According to commit 2503a5ecd86c002506001eba432c524ea009fe7f
> > "ARM: 6201/1: RealView: Do not use outer_sync() on ARM11MPCore
> > boards with L220" Some PB11MPCore RealView core tiles have broken
> > outer_sync.
> > 
> > We got rid of the custom barriers from the machine by disabling
> > outer sync, but that was just for the boardfile case. We have
> > to be able to do the same in the device tree case.
> > 
> > Since __l2c_init() is cloning and copying the L2C vtable,
> > we pass an argument to this function to optionally numb
> > the outer sync operation if desired, before initializing
> > the cache.
> > 
> > After this we can set up the cache correctly on the RealView
> > PB11MPCore. This was tested on a PB11MPCore known to have the
> > issue. Before this, spurious crashes would occur if we try to
> > set up the cache properly, after this it boots rock solid.
> > 
> > Cc: Russell King 
> > Cc: Arnd Bergmann 
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Linus Walleij 
> > ---
> > ChangeLog v2->v3:
> > - Update description, reference Catalins initial commit in the
> >   commit blurb.
> > ---
> >  Documentation/devicetree/bindings/arm/l2cc.txt |  3 +++
> >  arch/arm/mm/cache-l2x0.c   | 13 ++---
> >  2 files changed, 13 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt 
> > b/Documentation/devicetree/bindings/arm/l2cc.txt
> > index d181b7c4c522..416864e9dc92 100644
> > --- a/Documentation/devicetree/bindings/arm/l2cc.txt
> > +++ b/Documentation/devicetree/bindings/arm/l2cc.txt
> > @@ -75,6 +75,9 @@ Optional properties:
> >specified to indicate that such transforms are precluded.
> >  - arm,parity-enable : enable parity checking on the L2 cache (L220 or 
> > PL310).
> >  - arm,parity-disable : disable parity checking on the L2 cache (L220 or 
> > PL310).
> > +- arm,outer-sync-disable : disable the outer sync operation on the L2 
> > cache.
> > +  Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
> > +  will randomly hang unless outer sync operations are disabled.
> 
> This is also useful on Highbank as a feature where all DMA goes thru the 
> ACP port and there should not be a need to flush the L2 write buffer. 
> But I already optimized the performance critical register accesses with 
> _relaxed variants, so it doesn't really matter. I don't think any other 
> platform cares, therefore:
> 
> Acked-by: Rob Herring 

Thanks.

It would be nice to have a faster response though, because Linus Walleij
put this in the patch system on the 15th December, and I could have
applied it without waiting for DT people to comment.  The good thing is
that I _have_ the patch system, which allows me to temporarily ignore
patches (provided I remember) while people chew the cud on stuff like
this.

However, I'd _much_ rather prefer the authors to hold back the patches
until they get "approved" *before* sending them there, so I don't have
to find and remember to track the status of each patch on the mailing
list.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 1/1] powerpc: legacy serial port use device tree cell-index property

[Segher Boessenkool]

On Wed, Nov 25, 2015 at 10:46:49AM -0800, Curt Brune wrote:
> + /* Check if the ports have an ordering, defined by 'cell-index' */
> + if (((indexp = (u32*)of_get_property(np, "cell-index", &len)) != NULL) 
> &&
> + (len == sizeof(u32)))
> + index = *indexp;
> +
>   /* Add port, irq will be dealt with later. We passed a translated
>* IO port value. It will be fixed up later along with the irq
>*/
>   if (tsi && !strcmp(tsi->type, "tsi-bridge"))
> - return add_legacy_port(np, -1, UPIO_TSI, addr, addr,
> + return add_legacy_port(np, index, UPIO_TSI, addr, addr,
>  NO_IRQ, legacy_port_flags, 0);
>   else
> - return add_legacy_port(np, -1, UPIO_MEM, addr, addr,
> + return add_legacy_port(np, index, UPIO_MEM, addr, addr,
>  NO_IRQ, legacy_port_flags, 0);

What does this do if the value in cell-index is a duplicate. or the port
with that number is already created some other way?  Are the numbers in
cell-index global anyway, or relative to some parent device (I couldn't
find the documentation for this).


Segher
--
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
> .
> 
> > 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 v5] extcon: add Maxim MAX3355 driver

[Chanwoo Choi]

Hi,

This patch depend on GPIOLIB configuration as following:
I modified it with following diff and applied it.

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index ba4db7d..3d89e60 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -54,6 +54,7 @@ config EXTCON_MAX14577

 config EXTCON_MAX3355
tristate "Maxim MAX3355 USB OTG EXTCON Support"
+   depends on GPIOLIB || COMPILE_TEST
help
  If you say yes here you get support for the USB OTG role detection by
  MAX3355. The MAX3355 chip integrates a charge pump and comparators to

Thanks,
Chanwoo Choi


On Sat, Dec 19, 2015 at 8:17 AM, Sergei Shtylyov
 wrote:
> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
> enable a system with an integrated USB OTG dual-role transceiver to
> function as an USB OTG dual-role device. In addition to sensing/controlling
> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
> pin -- there's no real OTG controller, only host and gadget USB controllers
> sharing the same USB bus; however, we'd like to allow host or gadget
> drivers to be loaded depending on the cable type, hence the need for the
> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
> (however, we aren't currently interested in them), the OFFVBUS# signal is
> controlled by the host controllers, there's also the SHDN# signal wired to
> a GPIO, it should be driven high for the normal operation.
>
> Signed-off-by: Sergei Shtylyov 
> Acked-by: Chanwoo Choi 
>
> ---
> Changes in version 5:
> - removed unused variable in the probe() method;
> - removed reference to the Koelsch board from the binding document;
> - added Chanwoo Choi's ACK.
>
> Changes in version 4:
> - stopped calling kstrdup() for the device name;
> - removed unneeded 'owner' field initializer;
> - moved devm_extcon_allocate() call further down in the probe() method;
> - extended the driver copyright;
> - indented the continuation lines in the binding document.
>
> Changes in version 3:
> - reformatted the change log.
>
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
>   entry, the driver heading comment, the module description, and the change 
> log;
> - fixed up and reformatted the change log.
>
>  Documentation/devicetree/bindings/extcon/extcon-max3355.txt |   21 +
>  drivers/extcon/Kconfig  |8
>  drivers/extcon/Makefile |1
>  drivers/extcon/extcon-max3355.c |  150 
> 
>  4 files changed, 180 insertions(+)
>
> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO 
> pin
> +   connected to the MAX3355's SHDN# pin;
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> +   connected to the MAX3355's ID_OUT pin.
> +
> +Example:
> +
> +   usb-otg {
> +   compatible = "maxim,max3355";
> +   maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
> +   id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
> +   };
> Index: extcon/drivers/extcon/Kconfig
> ===
> --- extcon.orig/drivers/extcon/Kconfig
> +++ extcon/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
>   Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port 
> accessory
>   detector and switch.
>
> +config EXTCON_MAX3355
> +   tristate "Maxim MAX3355 USB OTG EXTCON Support"
> +   help
> + If you say yes here you get support for the USB OTG role detection 
> by
> + MAX3355. The MAX3355 chip integrates a charge pump and comparators 
> t

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

[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 
.



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-next 
now.


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 v5 2/2] spi: sun4i: Add support for wait time between word transmissions

[Marcus Weseloh]

Hi,

2015-12-18 12:16 GMT+01:00 Maxime Ripard :

>>   sun4i_spi_write(sspi, SUN4I_CLK_CTL_REG, reg);
>>
>> + /*
>> +  * Setup wait time between words.
>> +  *
>> +  * Wait time is set in SPI_CLK cycles. The SPI hardware needs 3
>> +  * additional cycles to setup the wait counter, so the minimum delay
>> +  * time is 4 cycles.
>> +  */
>> + if (spi->word_wait_ns) {
>> + clk_ns = DIV_ROUND_UP(10, tfr->speed_hz);
>
> You should use the actual rate of the clock returned by clk_get_rate
> (or probably just use mclk_rate).
>
> The clock driver might round the frequency to something else than what
> was set in clk_set_rate, which would make your calculation here a bit
> off.

Yes, good point! And as the wait clock counter is based on the actual
SPI_CLK and not the mod clock, I need to calculate the exact clock
myself before handling the wait clock setting. Will amend the patch
and send a new version.

While looking into this, I also noticed a problem with a previous
patch of mine, which changed the spi-sun[46]i to use
transfer->speed_hz instead of the spi->max_speed_hz: I also changed
the mclk_rate calculation to be based on tfr->speed_hz, which should
have stayed with spi->max_speed_hz. In the current state, the clock
calculations only ever increase mclk_rate, wich leads to very
different clocks being set depending on which clock was used on the
previous transfer. Will send a fix for that as well in a separate
patch.

Cheers,

   Marcus
--
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] rtc: support DS1302 RTC on ICP DAS LP-8x4x

[Sergei Ianovich]

On Sat, 2015-12-19 at 21:38 -0600, Rob Herring wrote:
> On Tue, Dec 15, 2015 at 08:45:23PM +0300, Sergei Ianovich wrote:
> 
> Nothing in this is specific to ICP, so the subject should be updated.
> 
> > Signed-off-by: Sergei Ianovich 
> > CC: Alexandre Belloni 
> > ---
> >    v4..v5
> >    * drop THIS_MODULE from struct platform driver
> >    * use "dallas" for vendor name per vendor-prefixes.txt
> > 
> >    v3..v4
> >    * move DTS bindings to a different patch
> > 
> >    v2..v3
> >    * use usleep_range instead of custom nsleep
> >    * number change (07/16 -> 09/21)
> > 
> >    v0..v2
> >    * use device tree
> >    * use devm helpers where possible
> > 
> >  .../devicetree/bindings/rtc/rtc-ds1302.txt |  14 +++
> >  drivers/rtc/Kconfig|   2 +-
> >  drivers/rtc/rtc-ds1302.c   | 100
> > -
> >  3 files changed, 113 insertions(+), 3 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/rtc/rtc-
> > ds1302.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> > b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> > new file mode 100644
> > index 000..810613b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rtc/rtc-ds1302.txt
> > @@ -0,0 +1,14 @@
> > +* Dallas Semiconductor DS-1302 RTC
> > +
> > +Simple device which could be used to store date/time between
> > reboots.
> > +
> > +Required properties:
> > +- compatible : Should be "dallas,rtc-ds1302"
> > +- reg : Should be address and size of IO memory region
> 
> This device is a SPI (or SPI like?) interface. So you have some sort
> of 
> of FPGA logic in between the cpu and ds1302. The DT should have a node
> for the controller and then the ds1302 as a child of it. A full blown 
> SPI driver may be overkill here, but that's a separate discussion from
> the DT binding.

Below is the quote from the actual DT of LP-8x4x:
> fpga@5 {
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 5 0x300 0x1>;
> interrupt-parent = <&fpgairq>;
> 
> rtc@901c {
> compatible = "dallas,rtc-ds1302";
> reg = <0x901c 0x1>;
> status = "okay";
> };

You are right about the topology. ds1302 is a half-duplex SPI device.
Does this mean I should rewrite the driver to handle the chip as a slave
SPI device, and then provide a master SPI functionality at the FPGA?
--
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 9/9] phy: omap-usb2: use *syscon* framework API to power on/off the PHY

[Kishon Vijay Abraham I]

Hi Rob,

On Sunday 20 December 2015 09:09 AM, Rob Herring wrote:
> On Tue, Dec 15, 2015 at 02:46:08PM +0530, Kishon Vijay Abraham I wrote:
>> Deprecate using phy-omap-control driver to power on/off the PHY,
>> and use *syscon* framework to do the same. This handles
>> powering on/off the PHY for the USB2 PHYs used in various TI SoCs.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> ---
>>  Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
>>  drivers/phy/phy-omap-usb2.c  |   94 
>> ++
>>  include/linux/phy/omap_usb.h |   23 ++
>>  3 files changed, 107 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
>> b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> index 49e5b0c..a3b3945 100644
>> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> @@ -31,6 +31,8 @@ OMAP USB2 PHY
>>  
>>  Required properties:
>>   - compatible: Should be "ti,omap-usb2"
>> +   Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
>> +   in DRA7x
> 
> The 2nd instance is different somehow?

yeah, the bit fields are slightly different.

Thanks
Kishon
--
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 5/5] ARM: dts: sun7i: Enable gmac on Wits Pro A20 DKT

[Hans de Goede]

The Wits Pro A20 DKT has a gbit ethernet port, enable it.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts 
b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
index 85b500d..dc31d47 100644
--- a/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
+++ b/arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
@@ -80,6 +80,18 @@
status = "okay";
 };
 
+&gmac {
+   pinctrl-names = "default";
+   pinctrl-0 = <&gmac_pins_rgmii_a>;
+   phy = <&phy1>;
+   phy-mode = "rgmii";
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
 &i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins_a>;
-- 
2.5.0

--
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/5] ARM: dts: sun4i: Add touchscreen node to inet97fv2 dts file

[Hans de Goede]

Add a node describing the focaltech ft5306de4 touchscreen found on
inet97fv2 tablets.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts 
b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
index 77c31da..74dd458 100644
--- a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
+++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
@@ -48,6 +48,7 @@
 
 #include 
 #include 
+#include 
 
 / {
model = "INet-97F Rev 02";
@@ -93,6 +94,16 @@
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
+
+   ft5406ee8: touchscreen@38 {
+   compatible = "edt,edt-ft5406";
+   reg = <0x38>;
+   interrupt-parent = <&pio>;
+   interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
+   pinctrl-names = "default";
+   touchscreen-size-x = <800>;
+   touchscreen-size-y = <480>;
+   };
 };
 
 &lradc {
-- 
2.5.0

--
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/5] ARM: dts: sun4i: Add touchscreen node to inet9f-rev03 tablet dts file

[Hans de Goede]

Add a node describing the focaltech ft5406ee8 touchscreen found on
inet-9f-rev03 / qware qw tb-g100 tablets.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts 
b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
index ca49b0d..d39067e 100644
--- a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
+++ b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
@@ -253,6 +253,16 @@
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
+
+   ft5406ee8: touchscreen@38 {
+   compatible = "edt,edt-ft5406";
+   reg = <0x38>;
+   interrupt-parent = <&pio>;
+   interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
+   pinctrl-names = "default";
+   touchscreen-size-x = <800>;
+   touchscreen-size-y = <480>;
+   };
 };
 
 &lradc {
-- 
2.5.0

--
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 2/5] ARM: dts: sun4i: Add touchscreen node to chuwi-v7 dts file

[Hans de Goede]

Add a node describing the focaltech ft5306de4 touchscreen found on
chuwi-v7-cw0825 tablets.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts 
b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
index 5366089..c71b654 100644
--- a/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
+++ b/arch/arm/boot/dts/sun4i-a10-chuwi-v7-cw0825.dts
@@ -45,6 +45,7 @@
 #include "sunxi-common-regulators.dtsi"
 #include 
 #include 
+#include 
 
 / {
model = "Chuwi V7 CW0825";
@@ -88,6 +89,16 @@
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
+
+   ft5306de4: touchscreen@38 {
+   compatible = "edt,edt-ft5406";
+   reg = <0x38>;
+   interrupt-parent = <&pio>;
+   interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
+   pinctrl-names = "default";
+   touchscreen-size-x = <1024>;
+   touchscreen-size-y = <768>;
+   };
 };
 
 &lradc {
-- 
2.5.0

--
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/5] ARM: dts: sun5i: Add dts file for the Empire Electronix D709 tablet

[Hans de Goede]

The Empire Electronix D709 tablet is a fairly standard 7" A13 tablet,
featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone jack.

Empire Electronix is written on the back of the tablet, the D709 model
info can be found in the about tablet menu in android.

The PCB has no markings to speak of.

This dts file does not add support for the ft5x touchscreen found at
i2c bus 1, addr 0x38, irq PG11, because it does not work out of the box.
It seems it has been flashed with the wrong firmware and needs to have
alternative firmware uploaded at boot to make the touchscreen work
properly, when hot-booting from android into an upstream kernel the
touchscreen does work.

The Memsic MXC622X accelerometer at i2c bus 1, addr 0x15 also is not
enabled as there is no driver for it.

Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/Makefile |   1 +
 .../boot/dts/sun5i-a13-empire-electronix-d709.dts  | 241 +
 2 files changed, 242 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cdffcef..78882ae 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -612,6 +612,7 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-olinuxino-micro.dtb \
sun5i-a10s-r7-tv-dongle.dtb \
sun5i-a10s-wobo-i5.dtb \
+   sun5i-a13-empire-electronix-d709.dtb \
sun5i-a13-hsg-h702.dtb \
sun5i-a13-inet-98v-rev2.dtb \
sun5i-a13-olinuxino.dtb \
diff --git a/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts 
b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
new file mode 100644
index 000..7fbb0b0
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-a13-empire-electronix-d709.dts
@@ -0,0 +1,241 @@
+/*
+ * Copyright 2015 Hans de Goede 
+ *
+ * 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 "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   model = "Empire Electronix D709 tablet";
+   compatible = "empire-electronix,d709", "allwinner,sun5i-a13";
+
+   aliases {
+   serial0 = &uart1;
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+   default-brightness-level = <8>;
+   /* TODO: backlight uses axp gpio1 as enable pin */
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&cpu0 {
+   cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+   status = "okay";
+};
+
+&i2c0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c0_pins_a>;
+   status = "okay";
+
+   axp209: pmic@34 {
+   reg = <0x34>;
+   interrupts = <0>;
+   };
+};
+
+#include "axp209.dtsi"
+
+&i2c1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_pins_a>;
+   status 

[PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi

[Uwe Kleine-König]

Some displays have a reset input and/or need a regulator to function
properly. Allow to specify them for panel-dpi devices.

Signed-off-by: Uwe Kleine-König 
---
 Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt 
b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
index 216c894d4f99..b52ac52757df 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
@@ -7,6 +7,8 @@ Required properties:
 Optional properties:
 - label: a symbolic name for the panel
 - enable-gpios: panel enable gpio
+- reset-gpios: GPIO to control the RESET pin
+- vcc-supply: phandle of regulator that will be used to enable power to the 
display
 
 Required nodes:
 - "panel-timing" containing video timings
-- 
2.6.2

--
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] mtd: support BB SRAM on ICP DAS LP-8x4x

[Sergei Ianovich]

On Sat, 2015-12-19 at 21:38 -0600, Rob Herring wrote:
> On Tue, Dec 15, 2015 at 09:58:53PM +0300, Sergei Ianovich wrote:
> > This provides an MTD device driver for 512kB of battery backed up
> > SRAM
> > on ICPDAS LP-8X4X programmable automation controllers.
> > 
> > SRAM chip is connected via FPGA and is not accessible without a
> > driver,
> > unlike flash memory which is wired to CPU MMU.
> > 
> > This SRAM becomes an excellent persisent storage of volatile process
> > data like counter values and sensor statuses. Storing those data in
> > flash or mmc card is not a viable solution.
> > 
> > Signed-off-by: Sergei Ianovich 
> > Reviewed-by: Brian Norris 
> > ---
> >    v4..v5
> >    * remove .owner from struct platform_driver
> >    * constify struct of_device_id
> > for further Brian Norris comments:
> >    * drop unused property from doc file
> >    * move defconfig update to a different file
> >    * drop extra match w/ of_match_device()
> > 
> >    v3..v4 for Brian Norris 'Reviewed-by'
> >    * add doc file for DT binding
> >    * move DTS binding to a different patch (8/21)
> >    * drop unused include directive
> >    * drop safely unused callback
> >    * drop non-default partion probe types
> >    * drop duplicate error checks
> >    * drop duplicate error reporting
> >    * fixed error message on MTD registeration
> >    * fixed module removal routine
> > 
> >    v2..v3
> >    * no changes (except number 08/16 -> 10/21)
> > 
> >    v0..v2
> >    * use device tree
> >    * use devm helpers where possible
> > 
> >  .../devicetree/bindings/mtd/sram-lp8x4x.txt|  20 +++
> >  drivers/mtd/devices/Kconfig|  14 ++
> >  drivers/mtd/devices/Makefile   |   1 +
> >  drivers/mtd/devices/sram_lp8x4x.c  | 199
> > +
> >  4 files changed, 234 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mtd/sram-
> > lp8x4x.txt
> >  create mode 100644 drivers/mtd/devices/sram_lp8x4x.c
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> > b/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> > new file mode 100644
> > index 000..476934f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/sram-lp8x4x.txt
> > @@ -0,0 +1,20 @@
> > +512kB battery backed up SRAM on LP-8x4x industrial computers
> > +
> > +Required properties:
> > +- compatible : should be "icpdas,sram-lp8x4x"
> 
> No wildcards please. Otherwise looks fine.

There is a similar review comment from Arnd Bergmann in the discussion
of `[PATCH v5] serial: support for 16550A serial ports on LP-8x4x`.

I'll quote my latest clarification:
> ... This driver will support ports on LP-8081, 
> LP-8141, LP-8441, LP-8841. Last time I checked the vendor was announcing
> a series with 3 as the last digit. They use lp8x4x name, eg. in
> documentation like `LP-8x4x_ChangeLog.txt`. They ship their proprietary
> SDK in `lp8x4x_sdk_for_linux.tar`. All of this implies that it is a
> single board.

I think the solution should be the same for all LP-8x4x drivers (IRQ,
SRAM, SERIAL, IIO).
--
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] fbdev: omap2: panel-dpi: allow specification of a reset gpio

[Uwe Kleine-König]

[Cc += devicetree@vger.kernel.org]

Hello Tomi,

On Wed, Dec 16, 2015 at 07:35:30PM +0200, Tomi Valkeinen wrote:
> 
> On 10/12/15 15:11, Uwe Kleine-König wrote:
> > From: Uwe Kleine-König 
> > 
> > Some displays have a reset input. To assert that the display is
> > functional the reset gpio must be deasserted.
> > 
> > Teach the driver to get and drive such a gpio accordingly.
> > 
> > Signed-off-by: Uwe Kleine-König 
> > ---
> >  Documentation/devicetree/bindings/video/panel-dpi.txt | 1 +
> >  drivers/video/fbdev/omap2/displays-new/panel-dpi.c| 7 +++
> >  2 files changed, 8 insertions(+)
> 
> DT changes should be posted to devicetree@vger.kernel.org. And, I think,
> the binding document changes are usually as a separate patch.

Right for devicetree@vger.kernel.org, but separate patches for bindings
is news to me. Anyhow, I can split this off if you prefer.

> > diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt 
> > b/Documentation/devicetree/bindings/video/panel-dpi.txt
> > index a40180b05bab..1a1d8f6f884f 100644
> > --- a/Documentation/devicetree/bindings/video/panel-dpi.txt
> > +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
> > @@ -7,6 +7,7 @@ Required properties:
> >  Optional properties:
> >  - label: a symbolic name for the panel
> >  - enable-gpios: panel enable gpio
> > +- reset-gpios: GPIO to control the RESET pin
> >  
> >  Required nodes:
> >  - "panel-timing" containing video timings
> > diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c 
> > b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> > index 1216341a0d19..7e2f9e0813dc 100644
> > --- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> > +++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
> > @@ -32,6 +32,7 @@ struct panel_drv_data {
> > int backlight_gpio;
> >  
> > struct gpio_desc *enable_gpio;
> > +   struct gpio_desc *reset_gpio;
> >  };
> >  
> >  #define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
> > @@ -83,6 +84,7 @@ static int panel_dpi_enable(struct omap_dss_device 
> > *dssdev)
> > if (r)
> > return r;
> >  
> > +   gpiod_set_value_cansleep(ddata->reset_gpio, 0);
> > gpiod_set_value_cansleep(ddata->enable_gpio, 1);
> >  
> > if (gpio_is_valid(ddata->backlight_gpio))
> > @@ -211,6 +213,11 @@ static int panel_dpi_probe_of(struct platform_device 
> > *pdev)
> > if (IS_ERR(ddata->enable_gpio))
> > return PTR_ERR(ddata->enable_gpio);
> >  
> > +   ddata->reset_gpio = devm_gpiod_get_optional(&pdev->dev,
> > +   "reset", GPIOD_OUT_HIGH);
> > +   if (IS_ERR(ddata->reset_gpio))
> > +   return PTR_ERR(ddata->reset_gpio);
> > +
> > ddata->backlight_gpio = -ENOENT;
> >  
> > r = of_get_display_timing(node, "panel-timing", &timing);
> > 
> 
> This looks a bit odd to me. This only ever sets the reset gpio to 0, on
> panel enable. If we never toggle the reset, it could be set to 0 at
> probe time, right?
> 
> Reset is a bit tricky. I've seen panels where you have to have only a
> short reset pulse (reset high, wait a short time, reset low). If you
> leave the reset high, the panel draws extra power.
> 
> So I think the best we can do in a generic way is just to ensure the
> reset is not asserted.

Good idea, will implement this in v2.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] ARM: dts: veyron: enable the tsadc on pinky board

[Caesar Wang]

I think the tsadc is fakly hand on pinky board,
maybe that's fixed in newest kernel.
As the following patch is a example:
https://patchwork.kernel.org/patch/7472051/

I don't have meet this issue on pinky board.
Let me know if that's still hanging on pinky board.

Signed-off-by: Caesar Wang 
---

 arch/arm/boot/dts/rk3288-veyron-pinky.dts | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts 
b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
index 94b56e3..b587ebf 100644
--- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
@@ -121,8 +121,3 @@
 &sdmmc_wp_gpio &sdmmc_bus4>;
wp-gpios = <&gpio7 10 GPIO_ACTIVE_HIGH>;
 };
-
-&tsadc {
-   /* Some connection is flaky making the tsadc hang the system */
-   status = "disabled";
-};
-- 
1.9.1

--
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] Fix a trivial typo and support rk3228/rk3399 SoCs for thermal driver.

[Caesar Wang]

在 2015年12月18日 04:09, Eduardo Valentin 写道:

Hello,

On Thu, Dec 03, 2015 at 04:48:38PM +0800, Caesar Wang wrote:

This series pacthes to support the next soc for this thermal driver.
I don't add the dts thermal data since these SoCs have *_not_* land
in this mainline. I believe these SoCs dts will land in this mainline
lately,
then I will add the thermal data for Heiko.

This series patches can apply into Eduardo branch.
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git

Also, this series pacthes have built on github branch.
https://github.com/rockchip-linux/kernel/commits/develop4.4

PATCH[1/5]:
That's bit ugly typo, sorry for sending again :(.

PATCH[2/5]:
To fix a build warning came from Dan Carpenter report smatch check,
Thanks. :)

PATCH[3/5]:
Add the rk3228/rk3399 SoCs compatible for dt-bindings.

PATCH[4/5]:
Add the rk3228 SoCs for thermal driver.

PATCH[5/5]:
Add the rk3399 SoCs for thermal driver based on PATCH[4/5].

I applied all but 2/5.


Thanks Eduardo,

I send the new patch[2/5].
https://patchwork.kernel.org/patch/7891381/



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
caesar wang | software engineer | w...@rock-chip.com


--
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 v4 2/5] thermal: rockchip: fix a impossible condition caused by the warning

[Caesar Wang]

As the Dan report the smatch check the thermal driver warning:
drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt()
warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) =>
(s32min-s32max > s32max)'

Although The shut_temp read from DT is u32,the temperature is currently
represented as int not long in the thermal driver.
Let's change to make shut_temp instead of the thermal->tshut_temp for
the condition.

Fixes: commit 437df2172e8d
("thermal: rockchip: consistently use int for temperatures")

Reported-by: Dan Carpenter 
Signed-off-by: Caesar Wang 

---

Changes in v4:
- As the Dmitry and Brain comments, let's change to make.sh
  tshut_temp instead of thermal->tshut_temp.

Changes in v3:
- As Brian comments on https://patchwork.kernel.org/patch/7580661/,
  let's remove the impossible condition.

Changes in v2:
- None

Changes in v1:
- None

 drivers/thermal/rockchip_thermal.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c 
b/drivers/thermal/rockchip_thermal.c
index e845841..7106288 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -545,15 +545,14 @@ static int rockchip_configure_from_dt(struct device *dev,
 thermal->chip->tshut_temp);
thermal->tshut_temp = thermal->chip->tshut_temp;
} else {
+   if (shut_temp > INT_MAX) {
+   dev_err(dev, "Invalid tshut temperature specified: 
%d\n",
+   shut_temp);
+   return -ERANGE;
+   }
thermal->tshut_temp = shut_temp;
}
 
-   if (thermal->tshut_temp > INT_MAX) {
-   dev_err(dev, "Invalid tshut temperature specified: %d\n",
-   thermal->tshut_temp);
-   return -ERANGE;
-   }
-
if (of_property_read_u32(np, "rockchip,hw-tshut-mode", &tshut_mode)) {
dev_warn(dev,
 "Missing tshut mode property, using default (%s)\n",
-- 
1.9.1

--
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