* Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support
From: Maxime Ripard @ 2018-05-14 8:40 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Icenowy Zheng, Jernej Skrabec, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel, Michael Turquette, Stephen Boyd, linux-clk,
Michael Trimarchi, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CAMty3ZBheurXewQ8R53G_0gNLgv1jQkZbjAbaN30JQ6_ZVn7Eg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
On Mon, May 14, 2018 at 02:03:36PM +0530, Jagan Teki wrote:
> On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > Hi,
> >
> > On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
> >> + hdmi_phy: hdmi-phy@1ef0000 {
> >> + compatible = "allwinner,sun50i-a64-hdmi-phy",
> >> + "allwinner,sun8i-h3-hdmi-phy";
> >> + reg = <0x01ef0000 0x10000>;
> >> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
> >> + <&ccu CLK_PLL_VIDEO1>;
> >
> > You were discussing that the PLL0 could also be used to clock the PHY,
> > has that been figured out?
>
> This is what I understand from Fig: 3-3. Module Clock Diagram, both
> tcon0 and tcon1 are using HDMI. I'm thinking based on the tcon
> configuration we need use proper PLL or some logic to get common PLL
> don't know yet. Since this series adding tcon1 I've attached PLL1.
You're not describing the TCON node here though, but the HDMI one, and
the HDMI block is listed in both the PLL video 0 and 1.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings
From: Andrzej Hajda @ 2018-05-14 8:38 UTC (permalink / raw)
To: open list:DESIGNWARE USB3 DRD IP DRIVER
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Felipe Balbi, Greg Kroah-Hartman, Inki Dae, Rob Herring,
Mark Rutland, Krzysztof Kozlowski, Chanwoo Choi, Laurent Pinchart,
linux-kernel, linux-samsung-soc
In-Reply-To: <20180131155718.5237-2-a.hajda@samsung.com>
On 31.01.2018 16:57, Andrzej Hajda wrote:
> extcon device is used to detect host/device connection. Since extcon
> OF property is deprecated, alternative method should be added.
> This method uses OF graph bindings to locate extcon.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Ping, 3.5 months passed.
Regards
Andrzej
> ---
> Hi all,
>
> This patch implements alternative method to get extcon from DWC3.
> The code works but is hacky, as DWC3 must traverse different DT nodes
> to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
> platforms can have different paths.
> I would be glad if it can be merged as is for now, but additional work
> must be done to make it generic.
> I guess on DT binding side it is OK. So the problem should be addressed
> in the code.
> My rough idea is to implement kind of extcon aliases/forwarder mechanism,
> ie. USB-PHY will expect on its output remote port extcon, and it should register
> extcon-forwarder pointing to this extcon. This way DWC3 can look for the extcon
> on its PHY phandle, and it will receive via forwarding mechanism extcon
> exposed by MUIC.
> As I said this is rough idea for discussion, other propositions are welcome.
>
> Regards
> Andrzej
> ---
> drivers/usb/dwc3/drd.c | 41 ++++++++++++++++++++++++++++-------------
> 1 file changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index cc8ab9a8e9d2..eee2eca3d513 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -8,6 +8,7 @@
> */
>
> #include <linux/extcon.h>
> +#include <linux/of_graph.h>
>
> #include "debug.h"
> #include "core.h"
> @@ -38,24 +39,38 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
> return NOTIFY_DONE;
> }
>
> +struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
> +{
> + struct device *dev = dwc->dev;
> + struct device_node *np_phy, *np_conn;
> + struct extcon_dev *edev;
> +
> + if (of_property_read_bool(dev->of_node, "extcon"))
> + return extcon_get_edev_by_phandle(dwc->dev, 0);
> +
> + np_phy = of_parse_phandle(dev->of_node, "phys", 0);
> + np_conn = of_graph_get_remote_node(np_phy, -1, -1);
> + edev = extcon_get_edev_by_of_node(np_conn);
> + of_node_put(np_conn);
> + of_node_put(np_phy);
> +
> + return edev;
> +}
> +
> int dwc3_drd_init(struct dwc3 *dwc)
> {
> int ret;
>
> - if (dwc->dev->of_node) {
> - if (of_property_read_bool(dwc->dev->of_node, "extcon"))
> - dwc->edev = extcon_get_edev_by_phandle(dwc->dev, 0);
> -
> - if (IS_ERR(dwc->edev))
> - return PTR_ERR(dwc->edev);
> + dwc->edev = dwc3_get_extcon(dwc);
> + if (IS_ERR(dwc->edev))
> + return PTR_ERR(dwc->edev);
>
> - dwc->edev_nb.notifier_call = dwc3_drd_notifier;
> - ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
> - &dwc->edev_nb);
> - if (ret < 0) {
> - dev_err(dwc->dev, "couldn't register cable notifier\n");
> - return ret;
> - }
> + dwc->edev_nb.notifier_call = dwc3_drd_notifier;
> + ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
> + &dwc->edev_nb);
> + if (ret < 0) {
> + dev_err(dwc->dev, "couldn't register cable notifier\n");
> + return ret;
> }
>
> dwc3_drd_update(dwc);
^ permalink raw reply
* Re: [PATCH 1/3] thermal: imx: remove cpufreq cooling registration
From: Bastian Stender @ 2018-05-14 8:37 UTC (permalink / raw)
To: Anson Huang, shawnguo, s.hauer, kernel, fabio.estevam, robh+dt,
mark.rutland, rjw, viresh.kumar, rui.zhang, edubezval
Cc: devicetree, linux-pm, Linux-imx, linux-arm-kernel, linux-kernel
In-Reply-To: <1526285359-17978-1-git-send-email-Anson.Huang@nxp.com>
Hi,
On 05/14/2018 10:09 AM, Anson Huang wrote:
> This patch removes cpufreq cooling registration in
> thermal .probe function, cpufreq cooling should be
> done in cpufreq driver when it is ready.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
It seems you are trying to achieve something similar to a patch I sent a
couple of month ago. Unfortunately I did not have the time to rework it yet:
https://patchwork.kernel.org/patch/10059085/
Some of the comments might apply here too.
Regards,
Bastian
> ---
> drivers/thermal/imx_thermal.c | 16 ----------------
> 1 file changed, 16 deletions(-)
>
> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> index c30dc21..8eedb97 100644
> --- a/drivers/thermal/imx_thermal.c
> +++ b/drivers/thermal/imx_thermal.c
> @@ -9,7 +9,6 @@
>
> #include <linux/clk.h>
> #include <linux/cpufreq.h>
> -#include <linux/cpu_cooling.h>
> #include <linux/delay.h>
> #include <linux/device.h>
> #include <linux/init.h>
> @@ -207,7 +206,6 @@ static struct thermal_soc_data thermal_imx7d_data = {
> struct imx_thermal_data {
> struct cpufreq_policy *policy;
> struct thermal_zone_device *tz;
> - struct thermal_cooling_device *cdev;
> enum thermal_device_mode mode;
> struct regmap *tempmon;
> u32 c1, c2; /* See formula in imx_init_calib() */
> @@ -729,22 +727,12 @@ static int imx_thermal_probe(struct platform_device *pdev)
> return -EPROBE_DEFER;
> }
>
> - data->cdev = cpufreq_cooling_register(data->policy);
> - if (IS_ERR(data->cdev)) {
> - ret = PTR_ERR(data->cdev);
> - dev_err(&pdev->dev,
> - "failed to register cpufreq cooling device: %d\n", ret);
> - cpufreq_cpu_put(data->policy);
> - return ret;
> - }
> -
> data->thermal_clk = devm_clk_get(&pdev->dev, NULL);
> if (IS_ERR(data->thermal_clk)) {
> ret = PTR_ERR(data->thermal_clk);
> if (ret != -EPROBE_DEFER)
> dev_err(&pdev->dev,
> "failed to get thermal clk: %d\n", ret);
> - cpufreq_cooling_unregister(data->cdev);
> cpufreq_cpu_put(data->policy);
> return ret;
> }
> @@ -759,7 +747,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
> ret = clk_prepare_enable(data->thermal_clk);
> if (ret) {
> dev_err(&pdev->dev, "failed to enable thermal clk: %d\n", ret);
> - cpufreq_cooling_unregister(data->cdev);
> cpufreq_cpu_put(data->policy);
> return ret;
> }
> @@ -775,7 +762,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
> dev_err(&pdev->dev,
> "failed to register thermal zone device %d\n", ret);
> clk_disable_unprepare(data->thermal_clk);
> - cpufreq_cooling_unregister(data->cdev);
> cpufreq_cpu_put(data->policy);
> return ret;
> }
> @@ -811,7 +797,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
> dev_err(&pdev->dev, "failed to request alarm irq: %d\n", ret);
> clk_disable_unprepare(data->thermal_clk);
> thermal_zone_device_unregister(data->tz);
> - cpufreq_cooling_unregister(data->cdev);
> cpufreq_cpu_put(data->policy);
> return ret;
> }
> @@ -831,7 +816,6 @@ static int imx_thermal_remove(struct platform_device *pdev)
> clk_disable_unprepare(data->thermal_clk);
>
> thermal_zone_device_unregister(data->tz);
> - cpufreq_cooling_unregister(data->cdev);
> cpufreq_cpu_put(data->policy);
>
> return 0;
>
--
Pengutronix e.K.
Industrial Linux Solutions
http://www.pengutronix.de/
Peiner Str. 6-8, 31137 Hildesheim, Germany
Amtsgericht Hildesheim, HRA 2686
^ permalink raw reply
* Re: [PATCH 1/3] thermal: imx: remove cpufreq cooling registration
From: Daniel Lezcano @ 2018-05-14 8:34 UTC (permalink / raw)
To: Anson Huang
Cc: shawnguo, s.hauer, kernel, fabio.estevam, robh+dt, mark.rutland,
rjw, viresh.kumar, rui.zhang, edubezval, Linux-imx,
linux-arm-kernel, devicetree, linux-kernel, linux-pm
In-Reply-To: <1526285359-17978-1-git-send-email-Anson.Huang@nxp.com>
On Mon, May 14, 2018 at 04:09:17PM +0800, Anson Huang wrote:
> This patch removes cpufreq cooling registration in
> thermal .probe function, cpufreq cooling should be
> done in cpufreq driver when it is ready.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support
From: Jagan Teki @ 2018-05-14 8:33 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Icenowy Zheng, Jernej Skrabec, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel, Michael Turquette, Stephen Boyd, linux-clk,
Michael Trimarchi, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <20180502113413.vv2r3ubfoh7gm3ms@flea>
On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi,
>
> On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
>> + hdmi_phy: hdmi-phy@1ef0000 {
>> + compatible = "allwinner,sun50i-a64-hdmi-phy",
>> + "allwinner,sun8i-h3-hdmi-phy";
>> + reg = <0x01ef0000 0x10000>;
>> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_DDC>,
>> + <&ccu CLK_PLL_VIDEO1>;
>
> You were discussing that the PLL0 could also be used to clock the PHY,
> has that been figured out?
This is what I understand from Fig: 3-3. Module Clock Diagram, both
tcon0 and tcon1 are using HDMI. I'm thinking based on the tcon
configuration we need use proper PLL or some logic to get common PLL
don't know yet. Since this series adding tcon1 I've attached PLL1.
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* Re: Allwinner A64: Issue on external rtc clock to wifi chip
From: Maxime Ripard @ 2018-05-14 8:27 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Michael Trimarchi, linux-sunxi, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <CAMty3ZDew=+zytKUx5+nX27CjCe0UfJpyYOy2s07NoJvbe57mQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]
On Mon, May 14, 2018 at 01:34:56PM +0530, Jagan Teki wrote:
> On Mon, May 14, 2018 at 1:27 PM, Maxime Ripard
> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > Hi,
> >
> > On Mon, May 14, 2018 at 12:37:49PM +0530, Jagan Teki wrote:
> >> Hi Maxime and All,
> >>
> >> We are trying to bring-up AP6330 Wifi chip for A64 board. We noticed
> >> to have an external rtc clock has driven from wifi chip.
> >>
> >> So the devicetree is configured according to this as below.
> >>
> >> / {
> >> wifi_pwrseq: wifi-pwrseq {
> >> compatible = "mmc-pwrseq-simple";
> >> clocks = <&rtc 1>;
> >> clock-names = "ext_clock";
> >> reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> >> post-power-on-delay-ms = <400>;
> >> };
> >> };
> >>
> >> &rtc {
> >> clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
> >> clocks = <&osc32k>;
> >> #clock-cells = <1>;
> >> };
> >>
> >> &mmc1 {
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&mmc1_pins>;
> >> vmmc-supply = <®_dcdc1>;
> >> vqmmc-supply = <®_eldo1>;
> >> mmc-pwrseq = <&wifi_pwrseq>;
> >> bus-width = <4>;
> >> non-removable;
> >> status = "okay";
> >>
> >> brcmf: wifi@1 {
> >> reg = <1>;
> >> compatible = "brcm,bcm4329-fmac";
> >> interrupt-parent = <&r_pio>;
> >> interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
> >> interrupt-names = "host-wake";
> >> };
> >> };
> >>
> >> And observed rtc-osc32k-out clock is never enabled[1] and the value of
> >> LOSC_OUT_GATING is 0x0 which eventually not enabling
> >> LOSC_OUT_GATING_EN
> >>
> >> Pls. let us know if we miss anything here?
> >>
> >> [1] https://paste.ubuntu.com/p/X2By4q8kD2/
> >
> > Could you paste your config and the logs from a boot to?
>
> .config
> https://paste.ubuntu.com/p/w9w2KB7RFc/
>
> dmesg
> https://paste.ubuntu.com/p/mrZGk5bWRR/
This is kind of weird. Have you tested with a 4.17 kernel? We have
runtime_pm changes lined up in next, so that might be a regression
there, even though we tested it with Quentin at some point.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Marco Felsch @ 2018-05-14 8:22 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, Markus Niebel
From: Markus Niebel <Markus.Niebel@tqs.de>
handle errata #2 for KSZ9031: force 1000Base-T master
Attention: enabling the workaround will cause no link to
other GIGE master.
Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
[m.felsch@pengutronix.de: move dt binding to the KSZ9031 entry]
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
.../devicetree/bindings/net/micrel-ksz90x1.txt | 3 +++
drivers/net/phy/micrel.c | 18 ++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index 42a248301615..e2465fbbbcef 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -57,6 +57,9 @@ KSZ9031:
- txd2-skew-ps : Skew control of TX data 2 pad
- txd3-skew-ps : Skew control of TX data 3 pad
+ - force-master: Boolean, force phy to master mode. This is a
+ workaround at least for KSZ9031 errata #2.
+
Examples:
mdio {
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f41b224a9cdb..3e4243e4f7a7 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -528,6 +528,8 @@ static int ksz9031_enable_edpd(struct phy_device *phydev)
static int ksz9031_config_init(struct phy_device *phydev)
{
+ int rc;
+ u16 val;
const struct device *dev = &phydev->mdio.dev;
const struct device_node *of_node = dev->of_node;
static const char *clk_skews[2] = {"rxc-skew-ps", "txc-skew-ps"};
@@ -573,6 +575,22 @@ static int ksz9031_config_init(struct phy_device *phydev)
ksz9031_of_load_skew_values(phydev, of_node,
MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
tx_data_skews, 4);
+
+ /* force master mode -> errata #2
+ * attention: Master <-> Master will not work
+ */
+ if (of_property_read_bool(of_node, "force-master")) {
+ rc = phy_read(phydev, MII_CTRL1000);
+ if (rc >= 0) {
+ val = (u16)rc;
+ /* enable master mode, config &
+ * prefer master
+ */
+ val |= (CTL1000_ENABLE_MASTER |
+ CTL1000_AS_MASTER);
+ phy_write(phydev, MII_CTRL1000, val);
+ }
+ }
}
return ksz9031_center_flp_timing(phydev);
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 03/21] clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs
From: Jagan Teki @ 2018-05-14 8:20 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Icenowy Zheng, Jernej Skrabec, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, David Airlie,
dri-devel, Michael Turquette, Stephen Boyd, linux-clk,
Michael Trimarchi, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <CAGb2v66MKooAAroCzYdsXZDY0Oh66Dydpy59xj80QfiY+5mz_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, May 1, 2018 at 9:53 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>> Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable them
>> as default.
>>
>> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
>> ---
>> drivers/clk/sunxi-ng/Kconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
>> index 79dfd296c3d1..1fffd3bf6ff3 100644
>> --- a/drivers/clk/sunxi-ng/Kconfig
>> +++ b/drivers/clk/sunxi-ng/Kconfig
>> @@ -58,6 +58,8 @@ config SUN8I_V3S_CCU
>>
>> config SUN8I_DE2_CCU
>> bool "Support for the Allwinner SoCs DE2 CCU"
>> + default ARM64 && ARCH_SUNXI
>> + depends on (DRM_SUN4I && (ARM64 && ARCH_SUNXI)) || COMPILE_TEST
>
> There is no reason to depend on DRM_SUN4I. There is no compile dependency.
Since this CCU is for DE2 I've make DRM_SUN4I for that matter, any problem?
>
> Also, this is needed on SUN8I as well, pretty much anything with DE 2.0.
> So you shouldn't limit it to ARM64. That pretty much breaks things for
> people with A83T's or H3's. In fact you should enable it by default for
> these as well.
True, I've skipped SUN8I since this series for A64.
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* Re: [PATCH v2 0/9] Input: support for latest Lenovo thinkpads (series 80)
From: Benjamin Tissoires @ 2018-05-14 8:19 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: 廖崇榮, Oliver Haessler, Benjamin Berg,
Rob Herring, devicetree, open list:HID CORE LAYER, lkml, Aaron Ma
In-Reply-To: <ca40347e-44cd-aa93-75ba-1bf0a63705be@canonical.com>
Hi Dmitry,
This is your monthly reminder of the Lenov 80 pending series :)
Could you consider taking this series and Aaron's patch?
Cheers,
Benjamin
On Tue, Apr 17, 2018 at 1:42 PM, Aaron Ma <aaron.ma@canonical.com> wrote:
> Hi Dmitry and Benjamin:
>
> Could you apply my patch too?
>
> It add LEN0096 that Benjamin's patch doesn't include.
>
> + "LEN0096", /* X280 */
>
> Regards,
> Aaron
^ permalink raw reply
* [PATCH 3/3] ARM: dts: imx: add cooling-cells for cpufreq cooling device
From: Anson Huang @ 2018-05-14 8:09 UTC (permalink / raw)
To: shawnguo, s.hauer, kernel, fabio.estevam, robh+dt, mark.rutland,
rjw, viresh.kumar, rui.zhang, edubezval
Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel, linux-pm
In-Reply-To: <1526285359-17978-1-git-send-email-Anson.Huang@nxp.com>
Add #cooling-cells for i.MX6/7 SoCs for cpufreq
cooling device usage.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx6dl.dtsi | 1 +
arch/arm/boot/dts/imx6q.dtsi | 1 +
arch/arm/boot/dts/imx6sl.dtsi | 1 +
arch/arm/boot/dts/imx6sx.dtsi | 1 +
arch/arm/boot/dts/imx6ul.dtsi | 1 +
arch/arm/boot/dts/imx7d.dtsi | 1 +
6 files changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 558bce8..b830dfd 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -39,6 +39,7 @@
396000 1175000
>;
clock-latency = <61036>; /* two CLK32 periods */
+ #cooling-cells = <2>;
clocks = <&clks IMX6QDL_CLK_ARM>,
<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
<&clks IMX6QDL_CLK_STEP>,
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index ae7b3f1..ac9f5cb 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -44,6 +44,7 @@
396000 1175000
>;
clock-latency = <61036>; /* two CLK32 periods */
+ #cooling-cells = <2>;
clocks = <&clks IMX6QDL_CLK_ARM>,
<&clks IMX6QDL_CLK_PLL2_PFD2_396M>,
<&clks IMX6QDL_CLK_STEP>,
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index ab6a7e2..d35d4e9 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -65,6 +65,7 @@
396000 1175000
>;
clock-latency = <61036>; /* two CLK32 periods */
+ #cooling-cells = <2>;
clocks = <&clks IMX6SL_CLK_ARM>, <&clks IMX6SL_CLK_PLL2_PFD2>,
<&clks IMX6SL_CLK_STEP>, <&clks IMX6SL_CLK_PLL1_SW>,
<&clks IMX6SL_CLK_PLL1_SYS>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 49c7205..966e39a 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -83,6 +83,7 @@
198000 1175000
>;
clock-latency = <61036>; /* two CLK32 periods */
+ #cooling-cells = <2>;
clocks = <&clks IMX6SX_CLK_ARM>,
<&clks IMX6SX_CLK_PLL2_PFD2>,
<&clks IMX6SX_CLK_STEP>,
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 1241972..14b6ac7 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -66,6 +66,7 @@
device_type = "cpu";
reg = <0>;
clock-latency = <61036>; /* two CLK32 periods */
+ #cooling-cells = <2>;
operating-points = <
/* kHz uV */
696000 1275000
diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 200714e..49913717 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -53,6 +53,7 @@
792000 975000
>;
clock-frequency = <996000000>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] cpufreq: imx6q: add cpufreq cooling device based on device tree
From: Anson Huang @ 2018-05-14 8:09 UTC (permalink / raw)
To: shawnguo, s.hauer, kernel, fabio.estevam, robh+dt, mark.rutland,
rjw, viresh.kumar, rui.zhang, edubezval
Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel, linux-pm
In-Reply-To: <1526285359-17978-1-git-send-email-Anson.Huang@nxp.com>
Register the imx6q cpufreq driver as a cooling device
based on the thermal device tree framework.
When temperature exceeds the passive trip point, cpufreq
driver will be used to throttle CPUs.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/cpufreq/imx6q-cpufreq.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 83cf631..27ce84d 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -9,6 +9,7 @@
#include <linux/clk.h>
#include <linux/cpu.h>
#include <linux/cpufreq.h>
+#include <linux/cpu_cooling.h>
#include <linux/err.h>
#include <linux/module.h>
#include <linux/of.h>
@@ -50,6 +51,7 @@ static struct clk_bulk_data clks[] = {
};
static struct device *cpu_dev;
+struct thermal_cooling_device *cdev;
static bool free_opp;
static struct cpufreq_frequency_table *freq_table;
static unsigned int max_freq;
@@ -202,6 +204,11 @@ static int imx6q_cpufreq_init(struct cpufreq_policy *policy)
return ret;
}
+static void imx6q_cpufreq_ready(struct cpufreq_policy *policy)
+{
+ cdev = of_cpufreq_cooling_register(policy);
+}
+
static struct cpufreq_driver imx6q_cpufreq_driver = {
.flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK,
.verify = cpufreq_generic_frequency_table_verify,
@@ -210,6 +217,7 @@ static struct cpufreq_driver imx6q_cpufreq_driver = {
.init = imx6q_cpufreq_init,
.name = "imx6q-cpufreq",
.attr = cpufreq_generic_attr,
+ .ready = imx6q_cpufreq_ready,
.suspend = cpufreq_generic_suspend,
};
@@ -482,6 +490,7 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
static int imx6q_cpufreq_remove(struct platform_device *pdev)
{
+ cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(&imx6q_cpufreq_driver);
dev_pm_opp_free_cpufreq_table(cpu_dev, &freq_table);
if (free_opp)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] thermal: imx: remove cpufreq cooling registration
From: Anson Huang @ 2018-05-14 8:09 UTC (permalink / raw)
To: shawnguo, s.hauer, kernel, fabio.estevam, robh+dt, mark.rutland,
rjw, viresh.kumar, rui.zhang, edubezval
Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel, linux-pm
This patch removes cpufreq cooling registration in
thermal .probe function, cpufreq cooling should be
done in cpufreq driver when it is ready.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
drivers/thermal/imx_thermal.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index c30dc21..8eedb97 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -9,7 +9,6 @@
#include <linux/clk.h>
#include <linux/cpufreq.h>
-#include <linux/cpu_cooling.h>
#include <linux/delay.h>
#include <linux/device.h>
#include <linux/init.h>
@@ -207,7 +206,6 @@ static struct thermal_soc_data thermal_imx7d_data = {
struct imx_thermal_data {
struct cpufreq_policy *policy;
struct thermal_zone_device *tz;
- struct thermal_cooling_device *cdev;
enum thermal_device_mode mode;
struct regmap *tempmon;
u32 c1, c2; /* See formula in imx_init_calib() */
@@ -729,22 +727,12 @@ static int imx_thermal_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
- data->cdev = cpufreq_cooling_register(data->policy);
- if (IS_ERR(data->cdev)) {
- ret = PTR_ERR(data->cdev);
- dev_err(&pdev->dev,
- "failed to register cpufreq cooling device: %d\n", ret);
- cpufreq_cpu_put(data->policy);
- return ret;
- }
-
data->thermal_clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(data->thermal_clk)) {
ret = PTR_ERR(data->thermal_clk);
if (ret != -EPROBE_DEFER)
dev_err(&pdev->dev,
"failed to get thermal clk: %d\n", ret);
- cpufreq_cooling_unregister(data->cdev);
cpufreq_cpu_put(data->policy);
return ret;
}
@@ -759,7 +747,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
ret = clk_prepare_enable(data->thermal_clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable thermal clk: %d\n", ret);
- cpufreq_cooling_unregister(data->cdev);
cpufreq_cpu_put(data->policy);
return ret;
}
@@ -775,7 +762,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
dev_err(&pdev->dev,
"failed to register thermal zone device %d\n", ret);
clk_disable_unprepare(data->thermal_clk);
- cpufreq_cooling_unregister(data->cdev);
cpufreq_cpu_put(data->policy);
return ret;
}
@@ -811,7 +797,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failed to request alarm irq: %d\n", ret);
clk_disable_unprepare(data->thermal_clk);
thermal_zone_device_unregister(data->tz);
- cpufreq_cooling_unregister(data->cdev);
cpufreq_cpu_put(data->policy);
return ret;
}
@@ -831,7 +816,6 @@ static int imx_thermal_remove(struct platform_device *pdev)
clk_disable_unprepare(data->thermal_clk);
thermal_zone_device_unregister(data->tz);
- cpufreq_cooling_unregister(data->cdev);
cpufreq_cpu_put(data->policy);
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 16/19 v3] regulator: fixed/gpio: Update device tree bindings
From: Linus Walleij @ 2018-05-14 8:06 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: linux-kernel, Linus Walleij, devicetree
In-Reply-To: <20180514080640.12515-1-linus.walleij@linaro.org>
Deprecate the open drain binding for fixed regulator and indicate
that we prefer this to be passed in the GPIO phandle flags.
Clarify that the line inversion semantics for fixed and GPIO
regulators completely overrides the active low flags in the
phandle flags.
Unfortunately this can not be changed to prefer that we pass
the flags in the phandle: the bindings have been specified and
deployed such that the presence/absence of this flag and only
that controls the line inversion semantics. The crucial semantic
is that the absence of the flag means the core will assume
the line is active low, which in GPIO terms is an exception,
as GPIO lines are normally assumed to be active high.
This special device tree semantic cannot be changed without
introducing a whole new compatible string for the fixed and
GPIO regulators, so we just contain the situation.
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Collect Rob's ACK.
---
.../bindings/regulator/fixed-regulator.txt | 13 +++++++++++--
.../bindings/regulator/gpio-regulator.txt | 4 ++++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
index 0c2a6c8a1536..a7a1cd0dfa6e 100644
--- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -8,10 +8,19 @@ Optional properties:
- gpio: gpio to use for enable control
- startup-delay-us: startup time in microseconds
- enable-active-high: Polarity of GPIO is Active high
-If this property is missing, the default assumed is Active low.
+ If this property is missing, the default assumed is Active low.
+ If the phandle flags to the GPIO handle also flag the line as active
+ low or high, that will be ignored for fixed regulators and the
+ presence or absence of this flag solely controls the inversion
+ semantics.
+-vin-supply: Input supply name.
+
+Deprecated properties:
- gpio-open-drain: GPIO is open drain type.
If this property is missing then default assumption is false.
--vin-supply: Input supply name.
+ Do not use this property in new device trees: instead use the
+ phandle flag to indicate to the GPIO provider that the line
+ should be handled as open drain.
Any property defined as part of the core regulator
binding, defined in regulator.txt, can also be used.
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
index 1f496159e2bb..8fef3e5358a2 100644
--- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -14,6 +14,10 @@ Optional properties:
defualt is LOW if nothing is specified.
- startup-delay-us : Startup time in microseconds.
- enable-active-high : Polarity of GPIO is active high (default is low).
+ If the phandle flags to the GPIO handle also flag the line as
+ active low or high, that will be ignored for fixed regulators
+ and the presence or absence of this flag solely controls the
+ inversion semantics.
- regulator-type : Specifies what is being regulated, must be either
"voltage" or "current", defaults to voltage.
--
2.17.0
^ permalink raw reply related
* Re: Allwinner A64: Issue on external rtc clock to wifi chip
From: Jagan Teki @ 2018-05-14 8:04 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Michael Trimarchi, linux-sunxi, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <20180514075727.uxggyhmbahvhestx@flea>
On Mon, May 14, 2018 at 1:27 PM, Maxime Ripard
<maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi,
>
> On Mon, May 14, 2018 at 12:37:49PM +0530, Jagan Teki wrote:
>> Hi Maxime and All,
>>
>> We are trying to bring-up AP6330 Wifi chip for A64 board. We noticed
>> to have an external rtc clock has driven from wifi chip.
>>
>> So the devicetree is configured according to this as below.
>>
>> / {
>> wifi_pwrseq: wifi-pwrseq {
>> compatible = "mmc-pwrseq-simple";
>> clocks = <&rtc 1>;
>> clock-names = "ext_clock";
>> reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>> post-power-on-delay-ms = <400>;
>> };
>> };
>>
>> &rtc {
>> clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
>> clocks = <&osc32k>;
>> #clock-cells = <1>;
>> };
>>
>> &mmc1 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&mmc1_pins>;
>> vmmc-supply = <®_dcdc1>;
>> vqmmc-supply = <®_eldo1>;
>> mmc-pwrseq = <&wifi_pwrseq>;
>> bus-width = <4>;
>> non-removable;
>> status = "okay";
>>
>> brcmf: wifi@1 {
>> reg = <1>;
>> compatible = "brcm,bcm4329-fmac";
>> interrupt-parent = <&r_pio>;
>> interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
>> interrupt-names = "host-wake";
>> };
>> };
>>
>> And observed rtc-osc32k-out clock is never enabled[1] and the value of
>> LOSC_OUT_GATING is 0x0 which eventually not enabling
>> LOSC_OUT_GATING_EN
>>
>> Pls. let us know if we miss anything here?
>>
>> [1] https://paste.ubuntu.com/p/X2By4q8kD2/
>
> Could you paste your config and the logs from a boot to?
.config
https://paste.ubuntu.com/p/w9w2KB7RFc/
dmesg
https://paste.ubuntu.com/p/mrZGk5bWRR/
^ permalink raw reply
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
From: Maxime Ripard @ 2018-05-14 8:03 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
Stephen Boyd, netdev, Michael Turquette, Rob Herring,
Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk
In-Reply-To: <CAGb2v64xTNqQQSppw2NZoLn+ViQNQLytn1EukLqw+HJzf1=5ig@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3965 bytes --]
1;5201;0c
On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
> >> ><maxime.ripard@bootlin.com> wrote:
> >> >> Hi,
> >> >>
> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
> >> >>>
> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
> >> >currently
> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
> >> >>> register. As SRAM controller driver can now export regmap for this
> >> >>> register, replace the syscon node to the SRAM controller device
> >> >node,
> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
> >> >>>
> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> >>> ---
> >> >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
> >> >+++++++++++++++----
> >> >>> 1 file changed, 19 insertions(+), 4 deletions(-)
> >> >>>
> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> @@ -168,10 +168,25 @@
> >> >>> #size-cells = <1>;
> >> >>> ranges;
> >> >>>
> >> >>> - syscon: syscon@1c00000 {
> >> >>> - compatible =
> >> >"allwinner,sun50i-a64-system-controller",
> >> >>> - "syscon";
> >> >>> + sram_controller: sram-controller@1c00000 {
> >> >>> + compatible =
> >> >"allwinner,sun50i-a64-sram-controller";
> >> >>
> >> >> I don't think there's anything preventing us from keeping the
> >> >> -system-controller compatible. It's what was in the DT before, and
> >> >> it's how it's called in the datasheet.
> >> >
> >> >I actually meant to ask you about this. The -system-controller
> >> >compatible matches the datasheet better. Maybe we should just
> >> >switch to that one?
> >>
> >> No, if we do the switch the system-controller compatible,
> >> the device will be probed on the same memory region with
> >> a syscon on old DTs.
> >
> > The device hasn't magically changed either. Maybe we just need to add
> > a check to make sure we don't have the syscon compatible in the SRAM
> > driver probe so that the double driver issue doesn't happen?
>
> The syscon interface (which is not even a full blown device driver)
> only looks at the "syscon" compatible. Either way we're removing that
> part from the device tree so things should be ok for new device trees.
> As Maxime mentioned we can do a check for the syscon compatible and
> either give a warning to the user asking them to update their device
> tree, or not register our custom regmap, or not probe the SRAM driver.
> Personally I prefer the first option. The system controller block is
> probed before any syscon users, so we should be fine, given the dwmac
> driver goes the custom regmap path first.
>
> BTW, I still might end up changing the compatible. The manual uses
> "system control", not "system controller", which I think makes sense,
> since it is just a bunch of register files, kind of like the GRF
> (General Register Files) block found in Rockchip SoCs [1], and not an
> actual "controller".
I'm not really fond of that, but we should at least make it consistent
on the other patches Paul sent then.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: exynos: Use dedicated DT bindings for Odroid X/X2, U3
From: Sylwester Nawrocki @ 2018-05-14 8:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh+dt, devicetree, linux-samsung-soc, linux-arm-kernel,
linux-kernel, b.zolnierkie, m.szyprowski
In-Reply-To: <20180513122412.shxdxtxt2phb46l5@kozik-lap>
On 05/13/2018 02:24 PM, Krzysztof Kozlowski wrote:
> On Fri, May 11, 2018 at 10:09:47AM +0200, Sylwester Nawrocki wrote:
>> Use dedicated Odroid audio subsystem DT bindings instead of the simple-card.
>> This adds support for audio on the HDMI interface.
> How about changing the subject to "Add suppor for audio over HDMI for
> Odroid X/X2/U3"?
Sure, I don't mind.
>> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> index bdcd4523cc1c..7a94a423097d 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> @@ -113,11 +113,12 @@
>> };
>>
>> &sound {
>> - simple-audio-card,name = "Odroid-U3";
>> - simple-audio-card,widgets =
>> + compatible = "hardkernel,odroid-xu4-audio";
> The compatible is the same for all users using DTSI so it could be moved
> to the exynos4412-odroid-common.dtsi itself.
Corrected.
--
Regards,
Sylwester
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Add support for audio over HDMI for Odroid X/X2/U3
From: Sylwester Nawrocki @ 2018-05-14 8:01 UTC (permalink / raw)
To: krzk
Cc: robh+dt, devicetree, linux-samsung-soc, linux-arm-kernel,
linux-kernel, b.zolnierkie, m.szyprowski, Sylwester Nawrocki
In-Reply-To: <CGME20180514080220epcas2p110497f1deca1e9c10db9b9edb890d76b@epcas2p1.samsung.com>
This patch switches Odroid X/X2/U3 to use dedicated Odroid audio subsystem
DT bindings instead of the simple-card in order to add support for audio
over HDMI.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 33 +++++++++++++++----------
arch/arm/boot/dts/exynos4412-odroidu3.dts | 6 ++---
arch/arm/boot/dts/exynos4412-odroidx.dts | 6 ++---
3 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index d7ad07fd48f9..a09e46c9dbc0 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -37,20 +37,14 @@
};
sound: sound {
- compatible = "simple-audio-card";
+ compatible = "hardkernel,odroid-xu4-audio";
- simple-audio-card,format = "i2s";
- simple-audio-card,bitclock-master = <&link0_codec>;
- simple-audio-card,frame-master = <&link0_codec>;
-
- simple-audio-card,cpu {
+ cpu {
sound-dai = <&i2s0 0>;
- system-clock-frequency = <19200000>;
};
- link0_codec: simple-audio-card,codec {
- sound-dai = <&max98090>;
- clocks = <&i2s0 CLK_I2S_CDCLK>;
+ codec {
+ sound-dai = <&hdmi>, <&max98090>;
};
};
@@ -142,14 +136,25 @@
pinctrl-0 = <>;
};
+&clock {
+ assigned-clocks = <&clock CLK_FOUT_EPLL>;
+ assigned-clock-rates = <45158401>;
+};
+
&clock_audss {
assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
<&clock_audss EXYNOS_MOUT_I2S>,
<&clock_audss EXYNOS_DOUT_SRP>,
- <&clock_audss EXYNOS_DOUT_AUD_BUS>;
+ <&clock_audss EXYNOS_DOUT_AUD_BUS>,
+ <&clock_audss EXYNOS_DOUT_I2S>;
+
assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
- <&clock_audss EXYNOS_MOUT_AUDSS>;
- assigned-clock-rates = <0>, <0>, <192000000>, <19200000>;
+ <&clock_audss EXYNOS_MOUT_AUDSS>;
+
+ assigned-clock-rates = <0>, <0>,
+ <196608001>,
+ <(196608001 / 2)>,
+ <(196608001 / 8)>;
};
&cpu0 {
@@ -498,6 +503,8 @@
pinctrl-0 = <&i2s0_bus>;
pinctrl-names = "default";
status = "okay";
+ assigned-clocks = <&i2s0 CLK_I2S_RCLK_SRC>;
+ assigned-clock-parents = <&clock_audss EXYNOS_SCLK_I2S>;
};
&mixer {
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index bdcd4523cc1c..459919b65df8 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -113,11 +113,11 @@
};
&sound {
- simple-audio-card,name = "Odroid-U3";
- simple-audio-card,widgets =
+ model = "Odroid-U3";
+ samsung,audio-widgets =
"Headphone", "Headphone Jack",
"Speakers", "Speakers";
- simple-audio-card,routing =
+ samsung,audio-routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
"Headphone Jack", "MICBIAS",
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 2dff129bc2ad..348556fcdd9d 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -97,12 +97,12 @@
};
&sound {
- simple-audio-card,name = "Odroid-X";
- simple-audio-card,widgets =
+ model = "Odroid-X";
+ samsung,audio-widgets =
"Headphone", "Headphone Jack",
"Microphone", "Mic Jack",
"Microphone", "DMIC";
- simple-audio-card,routing =
+ samsung,audio-routing =
"Headphone Jack", "HPL",
"Headphone Jack", "HPR",
"IN1", "Mic Jack",
--
2.14.2
^ permalink raw reply related
* Re: Allwinner A64: Issue on external rtc clock to wifi chip
From: Maxime Ripard @ 2018-05-14 7:57 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Michael Trimarchi, linux-sunxi, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <CAMty3ZCNyuEwmLGdDZLM_9qKJ2NsT33rodug7ZpKAE-OHymVEg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
Hi,
On Mon, May 14, 2018 at 12:37:49PM +0530, Jagan Teki wrote:
> Hi Maxime and All,
>
> We are trying to bring-up AP6330 Wifi chip for A64 board. We noticed
> to have an external rtc clock has driven from wifi chip.
>
> So the devicetree is configured according to this as below.
>
> / {
> wifi_pwrseq: wifi-pwrseq {
> compatible = "mmc-pwrseq-simple";
> clocks = <&rtc 1>;
> clock-names = "ext_clock";
> reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> post-power-on-delay-ms = <400>;
> };
> };
>
> &rtc {
> clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
> clocks = <&osc32k>;
> #clock-cells = <1>;
> };
>
> &mmc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc1_pins>;
> vmmc-supply = <®_dcdc1>;
> vqmmc-supply = <®_eldo1>;
> mmc-pwrseq = <&wifi_pwrseq>;
> bus-width = <4>;
> non-removable;
> status = "okay";
>
> brcmf: wifi@1 {
> reg = <1>;
> compatible = "brcm,bcm4329-fmac";
> interrupt-parent = <&r_pio>;
> interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
> interrupt-names = "host-wake";
> };
> };
>
> And observed rtc-osc32k-out clock is never enabled[1] and the value of
> LOSC_OUT_GATING is 0x0 which eventually not enabling
> LOSC_OUT_GATING_EN
>
> Pls. let us know if we miss anything here?
>
> [1] https://paste.ubuntu.com/p/X2By4q8kD2/
Could you paste your config and the logs from a boot to?
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* RE: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
From: Yinbo Zhu @ 2018-05-14 7:47 UTC (permalink / raw)
To: Leo Li, Rob Herring, Mark Rutland, Catalin Marinas ),
Will Deacon ), Lorenzo Pieralisi )
Cc: Xiaobo Xie, Ran Wang, Daniel Lezcano, Thomas Gleixner, Shawn Guo,
Madalin-cristian Bucur, Z.q. Hou, Jerry Huang, M.h. Lian,
Qiang Zhao, Fabio Estevam, Jiaheng Fan, Po Liu, Nipun Gupta,
Horia Geantă, Priyanka Jain, Sumit Garg, costi,
Bogdan Purcareata
In-Reply-To: <AM4PR0401MB16995DFED0376ACE0DD5E7A78F9F0@AM4PR0401MB1699.eurprd04.prod.outlook.com>
-----Original Message-----
From: Leo Li
Sent: 2018年5月12日 1:00
To: Yinbo Zhu <yinbo.zhu@nxp.com>; Yinbo Zhu <yinbo.zhu@nxp.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Catalin Marinas ) <catalin.marinas@arm.com>; Will Deacon ) <will.deacon@arm.com>; Lorenzo Pieralisi ) <lorenzo.pieralisi@arm.com>
Cc: Xiaobo Xie <xiaobo.xie@nxp.com>; Ran Wang <ran.wang_1@nxp.com>; Daniel Lezcano <daniel.lezcano@linaro.org>; Thomas Gleixner <tglx@linutronix.de>; Shawn Guo <shawnguo@kernel.org>; Madalin-cristian Bucur <madalin.bucur@nxp.com>; Z.q. Hou <zhiqiang.hou@nxp.com>; Jerry Huang <jerry.huang@nxp.com>; M.h. Lian <minghuan.lian@nxp.com>; Qiang Zhao <qiang.zhao@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>; Jiaheng Fan <jiaheng.fan@nxp.com>; Po Liu <po.liu@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Horia Geantă <horia.geanta@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>; Sumit Garg <sumit.garg@nxp.com>; costi <constantin.tudor@freescale.com>; Bogdan Purcareata <bogdan.purcareata@nxp.com>; open list:CLOCKSOURCE, CLOCKEVENT DRIVERS <linux-kernel@vger.kernel.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-arm-kernel@lists.infradead.org; open list:FREESCALE SOC DRIVERS <linuxppc-dev@lists.ozlabs.org>; Andy Tang <andy.tang@nxp.com>; Ying Zhang <ying.zhang22455@nxp.com>
Subject: RE: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
> -----Original Message-----
> From: Yinbo Zhu [mailto:yinbo.zhu@nxp.com]
> Sent: Thursday, May 10, 2018 10:35 PM
> To: Yinbo Zhu <yinbo.zhu@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Catalin Marinas )
> <catalin.marinas@arm.com>; Will Deacon ) <will.deacon@arm.com>;
> Lorenzo Pieralisi ) <lorenzo.pieralisi@arm.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: Xiaobo Xie <xiaobo.xie@nxp.com>; Ran Wang <ran.wang_1@nxp.com>;
> Daniel Lezcano <daniel.lezcano@linaro.org>; Thomas Gleixner
> <tglx@linutronix.de>; Shawn Guo <shawnguo@kernel.org>;
> Madalin-cristian Bucur <madalin.bucur@nxp.com>; Z.q. Hou
> <zhiqiang.hou@nxp.com>; Jerry Huang <jerry.huang@nxp.com>; M.h. Lian
> <minghuan.lian@nxp.com>; Qiang Zhao <qiang.zhao@nxp.com>; Fabio
> Estevam <fabio.estevam@nxp.com>; Jiaheng Fan <jiaheng.fan@nxp.com>; Po
> Liu <po.liu@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Horia Geantă
> <horia.geanta@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>; Sumit
> Garg <sumit.garg@nxp.com>; costi <constantin.tudor@freescale.com>;
> Bogdan Purcareata <bogdan.purcareata@nxp.com>; Meng Yi
> <meng.yi@nxp.com>; Wang Dongsheng <dongsheng.wang@nxp.com>; open
> list:CLOCKSOURCE, CLOCKEVENT DRIVERS <linux-kernel@vger.kernel.org>;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicetree@vger.kernel.org>; linux-arm-kernel@lists.infradead.org;
> open list:FREESCALE SOC DRIVERS <linuxppc-dev@lists.ozlabs.org>; Andy
> Tang <andy.tang@nxp.com>; Ying Zhang <ying.zhang22455@nxp.com>
> Subject: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
>
> From: Zhang Ying-22455 <ying.zhang22455@nxp.com>
>
> Set RCPM for FTM when using FTM as wakeup source. Because the RCPM
> module of each platform has different big-end and little-end mode,
> there need to set RCPM depending on the platform.
>
> Signed-off-by: Zhang Ying-22455 <ying.zhang22455@nxp.com>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
> ---
> .../devicetree/bindings/timer/fsl,ftm-timer.txt | 7 ++
> drivers/soc/fsl/layerscape/ftm_alarm.c | 92 ++++++++++++++++++-
> 2 files changed, 94 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> index aa8c402..15ead58 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> @@ -3,6 +3,13 @@ Freescale FlexTimer Module (FTM) Timer Required
> properties:
>
> - compatible : should be "fsl,ftm-timer"
>Hi Yingbo,
>This is a change that breaks backward compatibility and not acceptable.
Hi leo,
This patch if I keep the change as inner patch and push it to dash-linnux but I will not push it to upstream, It's okay?
As far as I know, there was a other patch and file for replace the file and that the patch is already on the upstream
https://patchwork.kernel.org/patch/9391293/
> + Possible compatibles for ARM:
> + "fsl,ls1012a-ftm"
> + "fsl,ls1021a-ftm"
> + "fsl,ls1043a-ftm"
> + "fsl,ls1046a-ftm"
> + "fsl,ls1088a-ftm"
> + "fsl,ls208xa-ftm"
> - reg : Specifies base physical address and size of the register sets for the
> clock event device and clock source device.
> - interrupts : Should be the clock event device interrupt.
> diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c
> b/drivers/soc/fsl/layerscape/ftm_alarm.c
> index 6f9882f..811dcfa 100644
> --- a/drivers/soc/fsl/layerscape/ftm_alarm.c
> +++ b/drivers/soc/fsl/layerscape/ftm_alarm.c
>There is no such file in the mainline kernel. So it looks like the patch set is
> based on some internal git repo instead of the upstream Linux kernel. This kind of patches
> shouldn't be sent to the upstream mailing list for review.
>Regards,
>Leo
This patch will not to upstream.
Regards,
Yinbo.
^ permalink raw reply
* 答复: reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
From: songxiaowei @ 2018-05-14 7:40 UTC (permalink / raw)
To: Andy Shevchenko
Cc: chenyao (F), Wangbinghui, Lorenzo Pieralisi, Bjorn Helgaas,
xuwei (O), Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, linux-pci@vger.kernel.org, Linux Kernel Mailing List,
linux-arm Mailing List, devicetree, dimitrysh@google.com,
guodong.xu@linaro.org, Suzhuangluan, Kongfei
In-Reply-To: <CAHp75VfHfUCNKNun4-bb2BhwV6D9jg2+hzVjrDER+af0SrzqjA@mail.gmail.com>
Hi Andy Shevchenko
> -----邮件原件-----
> 发件人: Andy Shevchenko [mailto:andy.shevchenko@gmail.com]
> 发送时间: 2018年5月14日 15:17
> 收件人: songxiaowei <songxiaowei@hisilicon.com>
> 抄送: chenyao (F) <chenyao11@huawei.com>; Wangbinghui
> <wangbinghui@hisilicon.com>; Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>;
> Bjorn Helgaas <bhelgaas@google.com>; xuwei (O) <xuwei5@huawei.com>;
> Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> Catalin Marinas <catalin.marinas@arm.com>; Will Deacon
> <will.deacon@arm.com>; linux-pci@vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; linux-arm Mailing List
> <linux-arm-kernel@lists.infradead.org>; devicetree
> <devicetree@vger.kernel.org>; dimitrysh@google.com;
> guodong.xu@linaro.org; Suzhuangluan <suzhuangluan@hisilicon.com>; Kongfei
> <kongfei@hisilicon.com>
> 主题: Re: reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
>
> On Mon, May 14, 2018 at 4:11 AM, songxiaowei <songxiaowei@hisilicon.com>
> wrote:
>
> >> > + int ret;
> >> > +
> >> > + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> >>
> >> > + pci->pp.msi_irq = platform_get_irq(pdev, 0);
> >> > + if (pci->pp.msi_irq < 0) {
> >> > + dev_err(&pdev->dev, "failed to get MSI IRQ
> >> (%d)\n",
> >> > + pci->pp.msi_irq);
> >>
> >> > + return -ENODEV;
> >>
> >> Why shadowing actual error code?
> > [songxiaowei] Sorry, I can't get your point about this, would you explain it
> for me.
>
> platform_get_irq() returns either correct IRQ number or negative error code.
> In the code above you shadow the actual error (as returned by that
> call) by -ENODEV. Any reason why?
>
[songxiaowei] I guess the reason is that she wanted to keep the same with other hosts,
So, you'd like to use "return pci->pp.msi_irq " instead of " return -ENODEV ".
> --
> With Best Regards,
> Andy Shevchenko
Thanks a lot,
Xiaowei.
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: jacopo mondi @ 2018-05-14 7:39 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Jacopo Mondi, laurent.pinchart, horms, geert, magnus.damm,
robh+dt, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20180513125755.GQ18974@bigcity.dyn.berto.se>
[-- Attachment #1: Type: text/plain, Size: 5074 bytes --]
Hi Niklas,
On Sun, May 13, 2018 at 02:57:55PM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> On 2018-05-11 12:00:02 +0200, Jacopo Mondi wrote:
> > Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> > development board.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 ++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > index d03f194..e0ce462 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > @@ -59,6 +59,17 @@
> > };
> > };
> >
> > + hdmi-in {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <&adv7612_in>;
> > + };
> > + };
> > + };
> > +
> > memory@48000000 {
> > device_type = "memory";
> > /* first 128MB is reserved for secure area. */
> > @@ -142,6 +153,11 @@
> > groups = "usb0";
> > function = "usb0";
> > };
> > +
> > + vin4_pins: vin4 {
> > + groups = "vin4_data24", "vin4_sync", "vin4_clk", "vin4_clkenb";
> > + function = "vin4";
> > + };
> > };
> >
> > &i2c0 {
> > @@ -154,6 +170,35 @@
> > reg = <0x50>;
> > pagesize = <8>;
> > };
> > +
> > + hdmi-decoder@4c {
> > + compatible = "adi,adv7612";
> > + reg = <0x4c>;
> > + default-input = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + adv7612_in: endpoint {
> > + remote-endpoint = <&hdmi_con_in>;
> > + };
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > + adv7612_out: endpoint {
> > + pclk-sample = <0>;
> > + hsync-active = <0>;
> > + vsync-active = <0>;
>
> This differs from the Gen2 DT bindings which is a very similar hardware
> setup using the same components. Defining these properties will make the
> bus marked as V4L2_MBUS_PARALLEL instead of V4L2_MBUS_BT656.
And that's what we want....
>
> This will change how the hardware is configured for capture if the media
> bus is in a UYVY format, see VNMC_INF register in rvin_setup(). Maybe
> this it not an issue here but still I'm curious to why this differ
> between Gen2 and Gen3 :-)
Actually this won't impact the VIN configuration as this is the
'remote endpoint' from VIN perspective and the properties used to
configure the interface are the ones in the 'local endpoint'.
>
> > +
> > + remote-endpoint = <&vin4_in>;
> > + };
> > + };
> > + };
> > + };
> > };
> >
> > &i2c1 {
> > @@ -246,3 +291,26 @@
> > timeout-sec = <60>;
> > status = "okay";
> > };
> > +
> > +&vin4 {
> > + pinctrl-0 = <&vin4_pins>;
> > + pinctrl-names = "default";
> > +
> > + status = "okay";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > +
> > + vin4_in: endpoint {
> > + hsync-active = <0>;
> > + vsync-active = <0>;
>
> Comparing this to the Gen2 bindings some properties are missing,
>
> bus-width = <24>;
> pclk-sample = <1>;
> data-active = <1>;
The VIN driver does not parse them, so there is no value in having
them there, if not confusing people as it happened to me reading the
Gen2 DT.
>
> This is not a big deal as the VIN driver don't use these properties so
> no functional change should come of this but still a difference.
Exactly.
On a side note. I have not seen a way to configure the pixel clock
sampling level in the interface datasheet. The register used to
configure synchronism signals polarities is VnDMR2, and there I read
we can configure HSYNC/VSYNC and CLOCKENB (which is data enable, not
pixel clock) polarities. Is it configured through some other
register?
>
> Over all I'm happy with this change but before I add my tag I would like
> to understand why it differs from the Gen2 configuration for the adv7612
> properties.
>
> Also on a side not it is possible with hardware switches on the board
> switch the VIN4 source to a completely different pipeline CVBS connector
> -> adv7180 -> VIN4. But I think it's best we keep the HDMI as default as
> this seems to be how the boards are shipped. But maybe mentioning this
> in the commit message would not hurt if you end-up resending the patch.
Oh I see. SW-49 to SW-52 enables the HDMI input, SW53-SW54 CVBS one.
And actually, reading the 'initial setting of slide switches' in the
Draak board manual, it turns out that the board default configuration
is with CVBS input selected... What should we do here? reflect
defaults in the DT, or prioritize HDMI?
Thanks
j
>
> > +
> > + remote-endpoint = <&adv7612_out>;
> > + };
> > + };
> > + };
> > +};
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas Söderlund
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] driver core: make deferring probe forever optional
From: Alexander Graf @ 2018-05-14 7:37 UTC (permalink / raw)
To: Linus Walleij, Sören Brinkmann
Cc: Bjorn Andersson, Rob Herring, linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Grant Likely, Mark Brown, Stephen Boyd,
boot-architecture, Linux ARM, Michal Simek, Jan Kiszka
In-Reply-To: <CACRpkdaYN-wKErERP_65T2NH6L-+8O_ugSgg7pXfkaLkn1A2KQ@mail.gmail.com>
On 05/14/2018 12:01 AM, Linus Walleij wrote:
> On Wed, May 9, 2018 at 11:44 AM, Alexander Graf <agraf@suse.de> wrote:
>> On 05/07/2018 08:31 PM, Bjorn Andersson wrote:
>>> Can you please name platform that has enough support for Alexander to
>>> care about backwards and forwards compatibility but lacks a pinctrl
>>> driver.
>> ZynqMP is one example that immediately comes to my mind. I'm sure there are
>> others too.
> Why isn't that using drivers/pinctrl/pinctrl-zynq.c?
>
> How is it so very different from (old) Zynq as it is already using
> the same GPIO driver?
That one is very simple: ZynqMP is usually an AMP system where Linux
doesn't have full knowledge of the overall system. IIUC they have a tiny
microblaze (PMU) that does the actual full system configuration for
peripherals that may interfere with each other. This architecture also
allows for safety critical code to run alongside a (less safe) Linux system.
I think we'll see architectures like this pop up more over time. TI
Sitara has similar issues. I know that Jailhouse ran into exactly that
problem before. I also know that during Linaro Connect Budapest even the
OP-TEE people realized the current model is bad, because Linux may
control pins/clocks/etc of devices that the secure world wants to use.
So I actually believe we will see more SoCs in the future that may even
start with Linux controllable pinctrl or no pinctrl driver but then will
move to firmware controlled drivers once it starts being necessary.
Alex
^ permalink raw reply
* Re: [PATCH 6/8] serial: Add Tegra Combined UART driver
From: Mikko Perttunen @ 2018-05-14 7:36 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mikko Perttunen, Rob Herring, Mark Rutland, Jassi Brar,
Greg Kroah-Hartman, Thierry Reding, Jon Hunter, araza, devicetree,
open list:SERIAL DRIVERS, linux-tegra, linux-arm Mailing List,
Linux Kernel Mailing List
In-Reply-To: <CAHp75VeJcqaiWUVr=oXEH5YurY3yCDdE1eeoWumo6jCa_4PWEQ@mail.gmail.com>
On 14.05.2018 01:20, Andy Shevchenko wrote:
> On Sun, May 13, 2018 at 9:04 PM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
>> On 05/13/2018 05:16 PM, Andy Shevchenko wrote:
>>>
>>> On Tue, May 8, 2018 at 2:44 PM, Mikko Perttunen <mperttunen@nvidia.com>
>>> wrote:
>>>>
>>>> The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
>>>> multiplexing multiple "virtual UARTs" into a single hardware serial
>>>> port. The TCU is the primary serial port on Tegra194 devices.
>>>>
>>>> Add a TCU driver utilizing the mailbox framework, as the used mailboxes
>>>> are part of Tegra HSP blocks that are already controlled by the Tegra
>>>> HSP mailbox driver.
>
>>>> +static void tegra_tcu_uart_set_mctrl(struct uart_port *port, unsigned
>>>> int mctrl)
>>>> +{
>>>
>>>
>>>> + (void)port;
>>>> + (void)mctrl;
>>>
>>>
>>> Huh?
>>
>>
>> The serial core calls these callbacks without checking if they are set. They
>> don't make sense for this driver so they are stubbed out.
>
> My question why do you need these ugly lines? I'm pretty sure no other
> driver with stubs using such style.
It's my personal style, being explicit about unused variables in this
way - I don't consider them ugly. But I can certainly remove them for
the next version.
>
>>>> +}
>
>>>> + if (written == 3) {
>>>> + value |= 3 << 24;
>>>> + value |= BIT(26);
>>>> + mbox_send_message(tcu->tx, &value);
>>>
>>>
>>>> + }
>>>
>>>
>>> (1)
>>>
>>>> + }
>>>> +
>>>> + if (written) {
>>>> + value |= written << 24;
>>>> + value |= BIT(26);
>>>> + mbox_send_message(tcu->tx, &value);
>>>> + }
>>>
>>>
>>> (2)
>>>
>>> These are code duplications.
>>
>>
>> Indeed - the length of the duplicated code is so short, and the instances
>> are so close to each other, that I don't find it necessary (or clearer) to
>> have an extra function.
>
> It makes sense. Consider to refactor other way w/o duplication then.
I'll see if I can refactor it out.
>
>>>> +static void tegra_tcu_uart_set_termios(struct uart_port *port,
>>>> + struct ktermios *new,
>>>> + struct ktermios *old)
>>>> +{
>>>> + (void)port;
>>>> + (void)new;
>>>> + (void)old;
>>>> +}
>>>
>>>
>>> Remove those unused stub contents.
>>
>>
>> Sure. I had these here so that we don't get unused parameter warnings, but I
>> can just as well remove the parameter names.
>
> What warnings? How did you get them? We have them disabled as far as I
> know even with W=1.
May be - it's just a habit, maybe from other projects where the warning
is enabled.
>
>>
>>>
>>>> + return uart_set_options(&tegra_tcu_uart_port, cons,
>>>> + 115200, 'n', 8, 'n');
>>>
>>>
>>> Can't it be one line?
>>
>>
>> It would be a total of 81 characters in length on one line, so no.
>
> So, yes. 1 character doesn't prevent us make the readability better.
> Please, put to one line.
>
Ok, I'll change this.
Thanks,
Mikko
^ permalink raw reply
* Re: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch
From: Peter Rosin @ 2018-05-14 7:21 UTC (permalink / raw)
To: yossim
Cc: Peter Chen, Greg Kroah-Hartman,
open list:CHIPIDEA USB HIGH SPEED DUAL ROLE CONTROLLER, open list,
robh, swboyd, devicetree, Stephen Boyd
In-Reply-To: <e75dff8424debcabd79f36faf3b23aaf@codeaurora.org>
On 2018-04-18 07:48, yossim@codeaurora.org wrote:
> On 2018-04-17 17:11, Peter Rosin wrote:
>> On 2018-04-17 15:52, Yossi Mansharoff wrote:
>>> On the db410c 96boards platform we have a TC7USB40MU on the board
>>> to mux the D+/D- lines coming from the controller between a micro
>>> usb "device" port and a USB hub for "host" roles[1]. During a
>>> role switch, we need to toggle this mux to forward the D+/D-
>>> lines to either the port or the hub. Add the necessary code to do
>>> the role switch in chipidea core via the generic mux framework.
>>> Board configurations like on db410c are expected to change roles
>>> via the sysfs API described in
>>> Documentation/ABI/testing/sysfs-platform-chipidea-usb2.
>>
>> Ok, so this is v2. Please describe what is different from v1.
>> I have told you before that this information helps.
>>
>>> [1]
>>> https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf
>>
>> This link returns 404 for me.
>>
>> Cheers,
>> Peter
>
>
> Hi,
> This patch was split apart from the original patch into two patches
> one for chipidea and the other for bindings.
> this patch has no other changes two the code.
>
> I will update the link.
Just a note: I will not feed the mux_control_get_optional patch upstream
until I feel confident that this patch is going also heading upstream.
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Maxime Ripard @ 2018-05-14 7:21 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Andrew Lunn, Giuseppe Cavallaro, linux-arm-kernel, devicetree,
netdev, Corentin Labbe, Icenowy Zheng, Rob Herring
In-Reply-To: <CAGb2v66F_Ho2OZdrF3p6xe9mQ=zJZ_KjE9MnW1VmWs9jw65eEg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]
On Sun, May 13, 2018 at 09:59:22PM -0700, Chen-Yu Tsai wrote:
> On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
> >> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> >> > Hi Chen-Yu
> >> >> >
> >> >> > Are these delays the MAC applies? Not the PHY. It would be good to
> >> >> > make it clear here these are MAC imposed delays.
> >> >>
> >> >> Yes these are applied on the MAC side. Being described in the device
> >> >> tree bindings for the MAC, I thought this was implied to be the case?
> >> >> Are there known exceptions?
> >> >
> >> > There is frequent confusion with this. Most of the time, the PHY does
> >> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> >> > an exception in itself.
> >> >
> >> > Do you actually need these delays for the board you adding support
> >> > for? Does the PHY not support adding the needed delays? If you don't
> >> > need the delays, i would not even implement them.
> >>
> >> Yes this is already used on the Bananapi M3. This patch merely reformats
> >> the description and adds a note saying this only applies to RGMII mode.
> >
> > Yes, the current code is needed for the Bananapi M3. But you have
> > another patch which extends the code to support a smaller range. Do
> > you have a board which actually needs this? If not, i would not add
> > that new code.
>
> IIRC the delay on the PHY side is either 2ns or none. The delay on the
> MAC side here is an order smaller, likely fine tuning to cope with board
> design deficiencies.
>
> Currently no other board requires this, but this is already part of the
> binding. The new stuff limits the range for a specific SoC, simply because
> that is the range supported by the control register. Not implementing, i.e.
> supporting the whole range from the property, which might get truncated,
> doesn't make much sense to me.
With that driver we don't, but the previous design had the same
feature and it was used on more boards. It was simply initialized
statically in U-Boot, and not in Linux through the DT like it is done
here.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox