* Re: [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Sergei Shtylyov @ 2018-05-14 9:42 UTC (permalink / raw)
To: Marco Felsch, robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, Markus Niebel
In-Reply-To: <20180514082218.29158-1-m.felsch@pengutronix.de>
On 5/14/2018 11:22 AM, Marco Felsch wrote:
> 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
Not "micrel,force-master"?
> + workaround at least for KSZ9031 errata #2.
> +
> Examples:
>
> mdio {
[...]
MBR, Sergei
^ permalink raw reply
* Re: Allwinner A64: Issue on external rtc clock to wifi chip
From: Jagan Teki @ 2018-05-14 9:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Michael Trimarchi, linux-sunxi, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <20180514090618.r5xc3elzpvfp47f4@flea>
On Mon, May 14, 2018 at 2:36 PM, Maxime Ripard
<maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> On Mon, May 14, 2018 at 02:34:22PM +0530, Jagan Teki wrote:
>> On Mon, May 14, 2018 at 1:57 PM, Maxime Ripard
>> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>> > 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.
>>
>> This is 4.17-rc4 do you want to try it on 4.16 ?
>
> No, this is next-20180503. Please try with 4.17-rc4
Couldn't find any different in behaviour [2]
[2] https://paste.ubuntu.com/p/m3PGBwrv6W/
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Sergei Shtylyov @ 2018-05-14 9:41 UTC (permalink / raw)
To: Marco Felsch, robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, Markus Niebel
In-Reply-To: <20180514082218.29158-1-m.felsch@pengutronix.de>
Hello!
On 5/14/2018 11:22 AM, Marco Felsch wrote:
> 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>
[...]
> @@ -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);
Parens not needed.
> + phy_write(phydev, MII_CTRL1000, val);
> + }
> + }
> }
>
> return ksz9031_center_flp_timing(phydev);
>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 2/2] drm/bridge: sii902x: add optional power supplies
From: Philippe CORNU @ 2018-05-14 9:38 UTC (permalink / raw)
To: Archit Taneja, Andrzej Hajda, Laurent Pinchart, David Airlie,
Rob Herring, Mark Rutland, dri-devel@lists.freedesktop.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Yannick FERTRE, Alexandre TORGUE
In-Reply-To: <20180425075314.19137-3-philippe.cornu@st.com>
Hi Laurent, Archit, Andrzej & Yannick,
Do you have any comments on this v2 driver part?
(more details regarding v1/v2 differences in the cover letter
https://www.spinics.net/lists/dri-devel/msg174137.html)
Thank you,
Philippe :-)
On 04/25/2018 09:53 AM, Philippe Cornu wrote:
> Add the optional power supplies using the description found in
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>
> The sii902x input IOs are not "io safe" so it is important to
> enable/disable voltage regulators during probe/remove phases to
> avoid damages.
>
> Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
> ---
> drivers/gpu/drm/bridge/sii902x.c | 38 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
> index 60373d7eb220..c367d7b91ade 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -24,6 +24,7 @@
> #include <linux/i2c.h>
> #include <linux/module.h>
> #include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
>
> #include <drm/drmP.h>
> #include <drm/drm_atomic_helper.h>
> @@ -86,6 +87,7 @@ struct sii902x {
> struct drm_bridge bridge;
> struct drm_connector connector;
> struct gpio_desc *reset_gpio;
> + struct regulator_bulk_data supplies[2];
> };
>
> static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
> @@ -392,23 +394,42 @@ static int sii902x_probe(struct i2c_client *client,
> return PTR_ERR(sii902x->reset_gpio);
> }
>
> + sii902x->supplies[0].supply = "iovcc";
> + sii902x->supplies[1].supply = "vcc12";
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
> + sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "Failed to get power supplies: %d\n", ret);
> + return ret;
> + }
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
> + sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "Failed to enable power supplies: %d\n", ret);
> + return ret;
> + }
> +
> + usleep_range(10000, 20000);
> +
> sii902x_reset(sii902x);
>
> ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
> if (ret)
> - return ret;
> + goto err_disable_regulator;
>
> ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
> &chipid, 4);
> if (ret) {
> dev_err(dev, "regmap_read failed %d\n", ret);
> - return ret;
> + goto err_disable_regulator;
> }
>
> if (chipid[0] != 0xb0) {
> dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
> chipid[0]);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto err_disable_regulator;
> }
>
> /* Clear all pending interrupts */
> @@ -424,7 +445,7 @@ static int sii902x_probe(struct i2c_client *client,
> IRQF_ONESHOT, dev_name(dev),
> sii902x);
> if (ret)
> - return ret;
> + goto err_disable_regulator;
> }
>
> sii902x->bridge.funcs = &sii902x_bridge_funcs;
> @@ -434,6 +455,12 @@ static int sii902x_probe(struct i2c_client *client,
> i2c_set_clientdata(client, sii902x);
>
> return 0;
> +
> +err_disable_regulator:
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> + sii902x->supplies);
> +
> + return ret;
> }
>
> static int sii902x_remove(struct i2c_client *client)
> @@ -443,6 +470,9 @@ static int sii902x_remove(struct i2c_client *client)
>
> drm_bridge_remove(&sii902x->bridge);
>
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> + sii902x->supplies);
> +
> return 0;
> }
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* RE: [PATCH v5 14/14] staging: typec: tcpci: move tcpci driver out of staging
From: Jun Li @ 2018-05-14 9:38 UTC (permalink / raw)
To: Mats Karrman, robh+dt@kernel.org, gregkh@linuxfoundation.org,
heikki.krogerus@linux.intel.com, linux@roeck-us.net
Cc: a.hajda@samsung.com, cw00.choi@samsung.com,
shufan_lee@richtek.com, Peter Chen, gsomlo@gmail.com,
devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
dl-linux-imx
In-Reply-To: <d29927f6-0481-8fee-fdc8-0eef81a56f9c@gmail.com>
Hi
> -----Original Message-----
> From: Mats Karrman [mailto:mats.dev.list@gmail.com]
> Sent: 2018年5月12日 5:37
> To: Jun Li <jun.li@nxp.com>; robh+dt@kernel.org; gregkh@linuxfoundation.org;
> heikki.krogerus@linux.intel.com; linux@roeck-us.net
> Cc: a.hajda@samsung.com; cw00.choi@samsung.com;
> shufan_lee@richtek.com; Peter Chen <peter.chen@nxp.com>;
> gsomlo@gmail.com; devicetree@vger.kernel.org; linux-usb@vger.kernel.org;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v5 14/14] staging: typec: tcpci: move tcpci driver out of
> staging
>
> Hi Li Jun,
>
> This patch takes away building the entire staging/typec tree but this is still not
> empty after your patch, another driver "tcpci_rt1711h" is there.
> Better just remove tcpci from staging/typec/{Kconfig,Makefile}
Oh, yes, I should also move out tcpci_rt1711h driver, will update in next version.
Thanks
Li Jun
>
> // Mats
>
> On 2018-05-03 02:24, Li Jun wrote:
>
> > Move TCPCI(Typec port controller interface) driver out of staging.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > drivers/staging/Kconfig | 2 --
> > drivers/staging/Makefile | 1 -
> > drivers/staging/typec/TODO | 5 -----
> > drivers/usb/typec/Kconfig | 7 +++++++
> > drivers/usb/typec/Makefile | 1 +
> > drivers/{staging => usb}/typec/tcpci.c | 0
> > drivers/{staging => usb}/typec/tcpci.h | 0
> > 7 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig index
> > d5926f0..d83ff66 100644
> > --- a/drivers/staging/Kconfig
> > +++ b/drivers/staging/Kconfig
> > @@ -112,8 +112,6 @@ source "drivers/staging/greybus/Kconfig"
> >
> > source "drivers/staging/vc04_services/Kconfig"
> >
> > -source "drivers/staging/typec/Kconfig"
> > -
> > source "drivers/staging/vboxvideo/Kconfig"
> >
> > source "drivers/staging/pi433/Kconfig"
> > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index
> > 919753c..a71ec1f 100644
> > --- a/drivers/staging/Makefile
> > +++ b/drivers/staging/Makefile
> > @@ -2,7 +2,6 @@
> > # Makefile for staging directory
> >
> > obj-y += media/
> > -obj-y += typec/
> > obj-$(CONFIG_IPX) += ipx/
> > obj-$(CONFIG_NCP_FS) += ncpfs/
> > obj-$(CONFIG_PRISM2_USB) += wlan-ng/
> > diff --git a/drivers/staging/typec/TODO b/drivers/staging/typec/TODO
> > deleted file mode 100644 index 53fe2f7..0000000
> > --- a/drivers/staging/typec/TODO
> > +++ /dev/null
> > @@ -1,5 +0,0 @@
> > -tcpci:
> > -- Test with real hardware
> > -
> > -Please send patches to Guenter Roeck <linux@roeck-us.net> and copy
> > -Heikki Krogerus <heikki.krogerus@linux.intel.com>.
> > diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> > index 2c8eab1..0a862fc 100644
> > --- a/drivers/usb/typec/Kconfig
> > +++ b/drivers/usb/typec/Kconfig
> > @@ -56,6 +56,13 @@ config TYPEC_TCPM
> >
> > if TYPEC_TCPM
> >
> > +config TYPEC_TCPCI
> > + tristate "Type-C Port Controller Interface driver"
> > + depends on I2C
> > + select REGMAP_I2C
> > + help
> > + Type-C Port Controller driver for TCPCI-compliant controller.
> > +
> > source "drivers/usb/typec/fusb302/Kconfig"
> >
> > config TYPEC_WCOVE
> > diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> > index 1f599a6..02758a1 100644
> > --- a/drivers/usb/typec/Makefile
> > +++ b/drivers/usb/typec/Makefile
> > @@ -7,3 +7,4 @@ obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
> > obj-$(CONFIG_TYPEC_UCSI) += ucsi/
> > obj-$(CONFIG_TYPEC_TPS6598X) += tps6598x.o
> > obj-$(CONFIG_TYPEC) += mux/
> > +obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
> > diff --git a/drivers/staging/typec/tcpci.c b/drivers/usb/typec/tcpci.c
> > similarity index 100% rename from drivers/staging/typec/tcpci.c rename
> > to drivers/usb/typec/tcpci.c diff --git
> > a/drivers/staging/typec/tcpci.h b/drivers/usb/typec/tcpci.h similarity
> > index 100% rename from drivers/staging/typec/tcpci.h rename to
> > drivers/usb/typec/tcpci.h
^ permalink raw reply
* RE: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config
From: Jun Li @ 2018-05-14 9:36 UTC (permalink / raw)
To: Mats Karrman, robh+dt@kernel.org, gregkh@linuxfoundation.org,
heikki.krogerus@linux.intel.com, linux@roeck-us.net
Cc: a.hajda@samsung.com, cw00.choi@samsung.com,
shufan_lee@richtek.com, Peter Chen, gsomlo@gmail.com,
devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
dl-linux-imx
In-Reply-To: <c28a8352-e960-449b-e7c1-7965d340536e@gmail.com>
Hi
> -----Original Message-----
> From: Mats Karrman [mailto:mats.dev.list@gmail.com]
> Sent: 2018年5月12日 3:56
> To: Jun Li <jun.li@nxp.com>; robh+dt@kernel.org; gregkh@linuxfoundation.org;
> heikki.krogerus@linux.intel.com; linux@roeck-us.net
> Cc: a.hajda@samsung.com; cw00.choi@samsung.com;
> shufan_lee@richtek.com; Peter Chen <peter.chen@nxp.com>;
> gsomlo@gmail.com; devicetree@vger.kernel.org; linux-usb@vger.kernel.org;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port power
> and data config
>
> Hi Li Jun,
>
> On 2018-05-03 02:24, Li Jun wrote:
>
> > This patch adds 3 APIs to get the typec port power and data type, and
> > preferred power role by its name string.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > drivers/usb/typec/class.c | 52
> +++++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/usb/typec.h | 3 +++
> > 2 files changed, 55 insertions(+)
> >
> > diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> > index 53df10d..5981e18 100644
> > --- a/drivers/usb/typec/class.c
> > +++ b/drivers/usb/typec/class.c
> > @@ -9,6 +9,7 @@
> > #include <linux/device.h>
> > #include <linux/module.h>
> > #include <linux/mutex.h>
> > +#include <linux/property.h>
> > #include <linux/slab.h>
> > #include <linux/usb/typec.h>
> > #include <linux/usb/typec_mux.h>
> > @@ -802,6 +803,12 @@ static const char * const typec_port_types[] = {
> > [TYPEC_PORT_DRP] = "dual",
> > };
> >
> > +static const char * const typec_data_types[] = {
> > + [TYPEC_PORT_DFP] = "host",
> > + [TYPEC_PORT_UFP] = "device",
> > + [TYPEC_PORT_DRD] = "dual",
> > +};
> > +
> > static const char * const typec_port_types_drp[] = {
> > [TYPEC_PORT_SRC] = "dual [source] sink",
> > [TYPEC_PORT_SNK] = "dual source [sink]", @@ -1252,6 +1259,51
> @@
> > void typec_set_pwr_opmode(struct typec_port *port,
> > }
> > EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
> >
> > +/**
> > + * typec_find_power_type - Get the typec port power type
>
> Why is this function called typec_find_power_type() and not
> typec_find_port_type()?
> It's called port_type in sysfs, having different names just adds confusion.
> (Otherwise I agree power_type is a better name but...)
We have "port type" before the power and data role separation,
this API name's intention is to reflect the power cap, anyway I
leave this to be decided by Heikki then.
>
> > + * @name: port type string
> > + *
> > + * This routine is used to find the typec_port_type by its string name.
> > + *
> > + * Returns typec_port_type if success, otherwise negative error code.
> > + */
> > +int typec_find_power_type(const char *name) {
> > + return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
> > + name);
> > +}
> > +EXPORT_SYMBOL_GPL(typec_find_power_type);
> > +
> > +/**
> > + * typec_find_preferred_role - Find the typec drp port preferred
> > +power role
>
> Why typec_find_preferred_role()? Could be used for any power_role so why not
> typec_find_power_role()?
I am not sure if I catch your point of this comment.
For preferred role(if support try.sink or try.src) the only allowed power roles are
"sink"
"source"
But for power role, the allowed type are
"sink"
"source"
"dual"
Thanks
Li Jun
>
> BR // Mats
>
> > + * @name: power role string
> > + *
> > + * This routine is used to find the typec_role by its string name of
> > + * preferred power role(Try.SRC or Try.SNK).
> > + *
> > + * Returns typec_role if success, otherwise negative error code.
> > + */
> > +int typec_find_preferred_role(const char *name) {
> > + return match_string(typec_roles, ARRAY_SIZE(typec_roles), name); }
> > +EXPORT_SYMBOL_GPL(typec_find_preferred_role);
> > +
> > +/**
> > + * typec_find_data_type - Get the typec port data capability
> > + * @name: data type string
> > + *
> > + * This routine is used to find the typec_port_data by its string name.
> > + *
> > + * Returns typec_port_data if success, otherwise negative error code.
> > + */
> > +int typec_find_data_type(const char *name) {
> > + return match_string(typec_data_types, ARRAY_SIZE(typec_data_types),
> > + name);
> > +}
> > +EXPORT_SYMBOL_GPL(typec_find_data_type);
> > +
> > /* ------------------------------------------ */
> > /* API for Multiplexer/DeMultiplexer Switches */
> >
> > diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
> > index 672b39b..00c93e7 100644
> > --- a/include/linux/usb/typec.h
> > +++ b/include/linux/usb/typec.h
> > @@ -267,4 +267,7 @@ int typec_set_orientation(struct typec_port *port,
> > enum typec_orientation orientation);
> > int typec_set_mode(struct typec_port *port, int mode);
> >
> > +int typec_find_power_type(const char *name); int
> > +typec_find_preferred_role(const char *name); int
> > +typec_find_data_type(const char *name);
> > #endif /* __LINUX_USB_TYPEC_H */
> >
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies
From: Philippe CORNU @ 2018-05-14 9:22 UTC (permalink / raw)
To: Laurent Pinchart, Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, Alexandre TORGUE,
David Airlie, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, Yannick FERTRE
In-Reply-To: <3518575.OAoTTXDygq@avalon>
Hi Rob & Laurent :)
On 04/26/2018 12:05 AM, Laurent Pinchart wrote:
> Hi Rob,
>
> On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote:
>> On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote:
>>> On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote:
>>>> On 04/25/2018 11:01 AM, Laurent Pinchart wrote:
>>>>> On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote:
>>>>>> Add optional power supplies using the description found in
>>>>>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>>>>>
>>>>>> There is a single 1v2 supply voltage named vcc12 from which cvcc12
>>>>>> (digital core) and avcc12 (TMDS analog) are derived because according
>>>>>> to this data sheet:
>>>>>> "cvcc12 and avcc12 can be derived from the same power source"
>>>>>
>>>>> Shouldn't the power supplies be mandatory, as explained by Mark in
>>>>> https://lists.freedesktop.org/archives/dri-devel/2018-April/172400.html
>>>>> ?
>>>>
>>>> Laurent,
>>>> Many thanks Laurent for your comment, I understood the merge of the two
>>>> 1v2 power supplies but missed the "mandatory" part... maybe because this
>>>> patch (with optional power supplies) already got the reviewed-by from
>>>> Rob, I thought the discussion thread you pointed out was applicable
>>>> "only" to totally new driver documentation.
>>>>
>>>> So, on my side, as a "new user" of sii902x IC, no problem to put these
>>>> power supplies as mandatory instead of optional properties but I would
>>>> like to be sure this is applicable to both old and new bindings doc : )
>>>
>>> We obviously need to retain backward compatibility, so on the driver side
>>> you need to treat those power supplies as optional. From a DT bindings
>>> point of view, however, I think they should be mandatory for new DT.
>>
>> We don't really have a way to describe these 3 conditions (required for
>> all, optional for all, and required for new). So generally we make
>> additions optional. The exception sometimes is if we update all the dts
>> files.
>
> Can't we just make it mandatory in the bindings, as long as we treat it as
> optional in drivers ?
>
How to progress on this patch? Do you have any suggestions?
Many thanks for your help,
Philippe :-)
>>>> Rob,
>>>> could you please confirm these power supply properties should be
>>>> "mandatory"? if yes, should we then modify other optional properties like
>>>> the reset-gpios too in the future?
>>>
>>> The GPIOs properties are different in my opinion, as there's no
>>> requirement to connect for instance the reset pin to a GPIO controllable
>>> by the SoC. The pin could be hardwired to VCC, or connected to a system
>>> reset that is automatically managed without SoC intervention. The power
>>> supplies, however, are mandatory, in the sense that the chip will not work
>>> if you leave the power supplies unconnected.
>>
>> DT only needs to describe what matters to s/w. If a regulator is
>> fixed and you don't need to know its voltage (or other read-only
>> parameters), then there's not much point in putting it in DT.
>>
>> I'd probably base this more at a platform level and you either use
>> regulator binding or you don't. It's perfectly valid that you want to do
>> things like regulator setup, pin ctrl and muxing setup, etc. all in
>> firmware and the OS doesn't touch any of that.
>>
>> That's all a big can of worms which we shouldn't solve on this 2 line
>> change. I think this change is fine as-is, so:
>>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/3] thermal: imx: remove cpufreq cooling registration
From: Bastian Stender @ 2018-05-14 9:18 UTC (permalink / raw)
To: Anson Huang, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, Fabio Estevam, robh+dt@kernel.org,
mark.rutland@arm.com, rjw@rjwysocki.net, viresh.kumar@linaro.org,
rui.zhang@intel.com, edubezval@gmail.com
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
dl-linux-imx, linux-arm-kernel@lists.infradead.org,
linux-pm@vger.kernel.org
In-Reply-To: <AM3PR04MB1315B6320421800346313075F59C0@AM3PR04MB1315.eurprd04.prod.outlook.com>
On 05/14/2018 11:10 AM, Anson Huang wrote:
>> -----Original Message-----
>> From: Bastian Stender [mailto:bst@pengutronix.de]
>> Sent: Monday, May 14, 2018 4:37 PM
>> To: Anson Huang <anson.huang@nxp.com>; shawnguo@kernel.org;
>> s.hauer@pengutronix.de; kernel@pengutronix.de; Fabio Estevam
>> <fabio.estevam@nxp.com>; robh+dt@kernel.org; mark.rutland@arm.com;
>> rjw@rjwysocki.net; viresh.kumar@linaro.org; rui.zhang@intel.com;
>> edubezval@gmail.com
>> Cc: devicetree@vger.kernel.org; linux-pm@vger.kernel.org; dl-linux-imx
>> <linux-imx@nxp.com>; linux-arm-kernel@lists.infradead.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH 1/3] thermal: imx: remove cpufreq cooling registration
>>
>> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
>> work.kernel.org%2Fpatch%2F10059085%2F&data=02%7C01%7Canson.huang
>> %40nxp.com%7C179da3635cab4a14deef08d5b975ecb6%7C686ea1d3bc2b4c6f
>> a92cd99c5c301635%7C0%7C0%7C636618838508978629&sdata=BcQ9tc%2BE
>> CZ%2Fk4AsZFxshgmvSsPg7eRN0ASzP8LO8yBI%3D&reserved=0
>>
>> Some of the comments might apply here too.
>
> Ah, I did NOT notice this thread, so how to proceed, will you
> continue to finish your patch? If yes, then you can just ignore/skip
> my patch, thanks.
Yes, I will revisit the patch in a couple of weeks. It would be nice to
get your feedback then.
Regards,
Bastian
--
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 v5 08/14] media: ov772x: support device tree probing
From: jacopo mondi @ 2018-05-14 9:16 UTC (permalink / raw)
To: Sakari Ailus
Cc: Akinobu Mita, linux-media, devicetree, Jacopo Mondi,
Laurent Pinchart, Hans Verkuil, Mauro Carvalho Chehab
In-Reply-To: <20180507092641.bgsko6f34npn3mc7@paasikivi.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 6808 bytes --]
Hi Sakari,
On Mon, May 07, 2018 at 12:26:41PM +0300, Sakari Ailus wrote:
> Dear Mita-san,
>
> On Sun, May 06, 2018 at 11:19:23PM +0900, Akinobu Mita wrote:
> > The ov772x driver currently only supports legacy platform data probe.
> > This change enables device tree probing.
> >
> > Note that the platform data probe can select auto or manual edge control
> > mode, but the device tree probling can only select auto edge control mode
> > for now.
> >
> > Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Cc: Hans Verkuil <hans.verkuil@cisco.com>
> > Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> > Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
> > Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> > ---
> > * v5
> > - Remove unnecessary space
> >
> > drivers/media/i2c/ov772x.c | 64 ++++++++++++++++++++++++++++++++--------------
> > 1 file changed, 45 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> > index f939e28..2b02411 100644
> > --- a/drivers/media/i2c/ov772x.c
> > +++ b/drivers/media/i2c/ov772x.c
> > @@ -749,13 +749,13 @@ static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
> > case V4L2_CID_VFLIP:
> > val = ctrl->val ? VFLIP_IMG : 0x00;
> > priv->flag_vflip = ctrl->val;
> > - if (priv->info->flags & OV772X_FLAG_VFLIP)
> > + if (priv->info && (priv->info->flags & OV772X_FLAG_VFLIP))
> > val ^= VFLIP_IMG;
> > return ov772x_mask_set(client, COM3, VFLIP_IMG, val);
> > case V4L2_CID_HFLIP:
> > val = ctrl->val ? HFLIP_IMG : 0x00;
> > priv->flag_hflip = ctrl->val;
> > - if (priv->info->flags & OV772X_FLAG_HFLIP)
> > + if (priv->info && (priv->info->flags & OV772X_FLAG_HFLIP))
> > val ^= HFLIP_IMG;
> > return ov772x_mask_set(client, COM3, HFLIP_IMG, val);
> > case V4L2_CID_BAND_STOP_FILTER:
> > @@ -914,19 +914,14 @@ static void ov772x_select_params(const struct v4l2_mbus_framefmt *mf,
> > *win = ov772x_select_win(mf->width, mf->height);
> > }
> >
> > -static int ov772x_set_params(struct ov772x_priv *priv,
> > - const struct ov772x_color_format *cfmt,
> > - const struct ov772x_win_size *win)
> > +static int ov772x_edgectrl(struct ov772x_priv *priv)
> > {
> > struct i2c_client *client = v4l2_get_subdevdata(&priv->subdev);
> > - struct v4l2_fract tpf;
> > int ret;
> > - u8 val;
> >
> > - /* Reset hardware. */
> > - ov772x_reset(client);
> > + if (!priv->info)
> > + return 0;
> >
> > - /* Edge Ctrl. */
> > if (priv->info->edgectrl.strength & OV772X_MANUAL_EDGE_CTRL) {
> > /*
> > * Manual Edge Control Mode.
> > @@ -937,19 +932,19 @@ static int ov772x_set_params(struct ov772x_priv *priv,
> >
> > ret = ov772x_mask_set(client, DSPAUTO, EDGE_ACTRL, 0x00);
> > if (ret < 0)
> > - goto ov772x_set_fmt_error;
> > + return ret;
> >
> > ret = ov772x_mask_set(client,
> > EDGE_TRSHLD, OV772X_EDGE_THRESHOLD_MASK,
> > priv->info->edgectrl.threshold);
> > if (ret < 0)
> > - goto ov772x_set_fmt_error;
> > + return ret;
> >
> > ret = ov772x_mask_set(client,
> > EDGE_STRNGT, OV772X_EDGE_STRENGTH_MASK,
> > priv->info->edgectrl.strength);
> > if (ret < 0)
> > - goto ov772x_set_fmt_error;
> > + return ret;
> >
> > } else if (priv->info->edgectrl.upper > priv->info->edgectrl.lower) {
> > /*
> > @@ -961,15 +956,35 @@ static int ov772x_set_params(struct ov772x_priv *priv,
> > EDGE_UPPER, OV772X_EDGE_UPPER_MASK,
> > priv->info->edgectrl.upper);
> > if (ret < 0)
> > - goto ov772x_set_fmt_error;
> > + return ret;
> >
> > ret = ov772x_mask_set(client,
> > EDGE_LOWER, OV772X_EDGE_LOWER_MASK,
> > priv->info->edgectrl.lower);
> > if (ret < 0)
> > - goto ov772x_set_fmt_error;
> > + return ret;
> > }
> >
> > + return 0;
> > +}
> > +
> > +static int ov772x_set_params(struct ov772x_priv *priv,
> > + const struct ov772x_color_format *cfmt,
> > + const struct ov772x_win_size *win)
> > +{
> > + struct i2c_client *client = v4l2_get_subdevdata(&priv->subdev);
> > + struct v4l2_fract tpf;
> > + int ret;
> > + u8 val;
> > +
> > + /* Reset hardware. */
> > + ov772x_reset(client);
> > +
> > + /* Edge Ctrl. */
> > + ret = ov772x_edgectrl(priv);
> > + if (ret < 0)
> > + return ret;
> > +
> > /* Format and window size. */
> > ret = ov772x_write(client, HSTART, win->rect.left >> 2);
> > if (ret < 0)
> > @@ -1020,9 +1035,9 @@ static int ov772x_set_params(struct ov772x_priv *priv,
> >
> > /* Set COM3. */
> > val = cfmt->com3;
> > - if (priv->info->flags & OV772X_FLAG_VFLIP)
> > + if (priv->info && (priv->info->flags & OV772X_FLAG_VFLIP))
> > val |= VFLIP_IMG;
> > - if (priv->info->flags & OV772X_FLAG_HFLIP)
> > + if (priv->info && (priv->info->flags & OV772X_FLAG_HFLIP))
> > val |= HFLIP_IMG;
> > if (priv->flag_vflip)
> > val ^= VFLIP_IMG;
> > @@ -1271,8 +1286,9 @@ static int ov772x_probe(struct i2c_client *client,
> > struct i2c_adapter *adapter = client->adapter;
> > int ret;
> >
> > - if (!client->dev.platform_data) {
> > - dev_err(&client->dev, "Missing ov772x platform data\n");
> > + if (!client->dev.of_node && !client->dev.platform_data) {
> > + dev_err(&client->dev,
> > + "Missing ov772x platform data for non-DT device\n");
> > return -EINVAL;
> > }
> >
> > @@ -1370,9 +1386,19 @@ static const struct i2c_device_id ov772x_id[] = {
> > };
> > MODULE_DEVICE_TABLE(i2c, ov772x_id);
> >
> > +#if IS_ENABLED(CONFIG_OF)
> > +static const struct of_device_id ov772x_of_match[] = {
> > + { .compatible = "ovti,ov7725", },
> > + { .compatible = "ovti,ov7720", },
> > + { /* sentinel */ },
> > +};
> > +MODULE_DEVICE_TABLE(of, ov772x_of_match);
> > +#endif
>
> No need for #ifdef's nor of_match_ptr below.
>
> If no other changes would be needed for the set (pending Jacopo's review),
> I can also drop these bits if you're ok for that.
I've now reviewed all the patches in the series, 11/14 apart where I
would apreciate if you could have a look at (nothing complex, just me
not knowing enough of controls to feel confident enough to give my ack
there).
From my side then, the series is now fine. Thank Mita-san for your
work.
>
> > +
> > static struct i2c_driver ov772x_i2c_driver = {
> > .driver = {
> > .name = "ov772x",
> > + .of_match_table = of_match_ptr(ov772x_of_match),
> > },
> > .probe = ov772x_probe,
> > .remove = ov772x_remove,
>
> --
> Kind regards,
>
> Sakari Ailus
> sakari.ailus@linux.intel.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH/RFC v3 4/4] arm64: dts: renesas: r8a7795: add OF graph for usb role switch
From: Yoshihiro Shimoda @ 2018-05-14 9:16 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland
Cc: heikki.krogerus, hdegoede, andy.shevchenko, linux-usb,
linux-renesas-soc, devicetree, Yoshihiro Shimoda
In-Reply-To: <1526289360-3997-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
This patch adds OF graph properties for usb role switch in r8a7795
into USB3.0 host/peripheral nodes.
TODO:
- need patches for other SoCs.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1d5e3ac..50d3312 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1746,6 +1746,12 @@
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 328>;
status = "disabled";
+
+ port {
+ usb3_host0_ep: endpoint {
+ remote-endpoint = <&usb3_peri0_ep>;
+ };
+ };
};
usb3_peri0: usb@ee020000 {
@@ -1757,6 +1763,12 @@
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 328>;
status = "disabled";
+
+ port {
+ usb3_peri0_ep: endpoint {
+ remote-endpoint = <&usb3_host0_ep>;
+ };
+ };
};
usb_dmac0: dma-controller@e65a0000 {
--
1.9.1
^ permalink raw reply related
* [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API
From: Yoshihiro Shimoda @ 2018-05-14 9:15 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland
Cc: heikki.krogerus, hdegoede, andy.shevchenko, linux-usb,
linux-renesas-soc, devicetree, Yoshihiro Shimoda
In-Reply-To: <1526289360-3997-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
This patch uses usb role switch API if the register suceeeded.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/usb/gadget/udc/renesas_usb3.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c
index c878449..bfb5803 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -657,7 +657,11 @@ static void _usb3_set_mode(struct renesas_usb3 *usb3, bool host)
static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
{
- _usb3_set_mode(usb3, host);
+ if (usb3->role_sw)
+ usb_role_switch_set_role(usb3->role_sw, host ?
+ USB_ROLE_HOST : USB_ROLE_DEVICE);
+ else
+ _usb3_set_mode(usb3, host);
}
static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
@@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, bool host, bool a_dev)
{
unsigned long flags;
- spin_lock_irqsave(&usb3->lock, flags);
usb3_set_mode(usb3, host);
+ spin_lock_irqsave(&usb3->lock, flags);
usb3_vbus_out(usb3, a_dev);
/* for A-Peripheral or forced B-device mode */
if ((!host && a_dev) ||
--
1.9.1
^ permalink raw reply related
* [PATCH/RFC v3 2/4] usb: gadget: udc: renesas_usb3: Add register of usb role switch
From: Yoshihiro Shimoda @ 2018-05-14 9:15 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland
Cc: heikki.krogerus, hdegoede, andy.shevchenko, linux-usb,
linux-renesas-soc, devicetree, Yoshihiro Shimoda
In-Reply-To: <1526289360-3997-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
This patch adds role switch support for R-Car SoCs into the USB
3.0 peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB
3.0 dual-role device controller which has the USB 3.0 xHCI host
and Renesas USB 3.0 peripheral.
Unfortunately, the mode change register contains the USB 3.0 peripheral
controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
manages this register now. However, in peripheral mode, the host
should stop. Also the host hardware needs to reinitialize its own
registers when the mode changes from peripheral to host mode.
Otherwise, the host cannot work correctly (e.g. detect a device as
high-speed).
To achieve this by a driver, this role switch driver manages
the mode change register and attach/release the xhci-plat driver.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
.../devicetree/bindings/usb/renesas_usb3.txt | 15 +++++
drivers/usb/gadget/udc/Kconfig | 1 +
drivers/usb/gadget/udc/renesas_usb3.c | 68 +++++++++++++++++++++-
3 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
index 2c071bb5..f6105aa 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
@@ -19,6 +19,9 @@ Required properties:
Optional properties:
- phys: phandle + phy specifier pair
- phy-names: must be "usb"
+ - The connection to a usb3.0 host node needs by using OF graph bindings for
+ usb role switch.
+ - port@0 = USB3.0 host port.
Example of R-Car H3 ES1.x:
usb3_peri0: usb@ee020000 {
@@ -27,6 +30,12 @@ Example of R-Car H3 ES1.x:
reg = <0 0xee020000 0 0x400>;
interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 328>;
+
+ port {
+ usb3_peri0_ep: endpoint {
+ remote-endpoint = <&usb3_host0_ep>;
+ };
+ };
};
usb3_peri1: usb@ee060000 {
@@ -35,4 +44,10 @@ Example of R-Car H3 ES1.x:
reg = <0 0xee060000 0 0x400>;
interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 327>;
+
+ port {
+ usb3_peri1_ep: endpoint {
+ remote-endpoint = <&usb3_host1_ep>;
+ };
+ };
};
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38..7e4a5dd 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -193,6 +193,7 @@ config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
depends on EXTCON && HAS_DMA
+ select USB_ROLE_SWITCH
help
Renesas USB3.0 Peripheral controller is a USB peripheral controller
that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c
index 409cde4..c878449 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -23,6 +23,7 @@
#include <linux/uaccess.h>
#include <linux/usb/ch9.h>
#include <linux/usb/gadget.h>
+#include <linux/usb/role.h>
/* register definitions */
#define USB3_AXI_INT_STA 0x008
@@ -334,6 +335,9 @@ struct renesas_usb3 {
struct work_struct extcon_work;
struct phy *phy;
+ struct usb_role_switch *role_sw;
+ struct device *host_dev;
+
struct renesas_usb3_ep *usb3_ep;
int num_usb3_eps;
@@ -643,7 +647,7 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
}
}
-static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
+static void _usb3_set_mode(struct renesas_usb3 *usb3, bool host)
{
if (host)
usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
@@ -651,6 +655,11 @@ static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
usb3_set_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
}
+static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
+{
+ _usb3_set_mode(usb3, host);
+}
+
static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
{
if (enable)
@@ -2294,6 +2303,41 @@ static int renesas_usb3_set_selfpowered(struct usb_gadget *gadget, int is_self)
.set_selfpowered = renesas_usb3_set_selfpowered,
};
+static enum usb_role renesas_usb3_role_switch_get(struct device *dev)
+{
+ struct renesas_usb3 *usb3 = dev_get_drvdata(dev);
+ enum usb_role cur_role;
+
+ pm_runtime_get_sync(dev);
+ cur_role = usb3_is_host(usb3) ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+ pm_runtime_put(dev);
+
+ return cur_role;
+}
+
+static int renesas_usb3_role_switch_set(struct device *dev,
+ enum usb_role role)
+{
+ struct renesas_usb3 *usb3 = dev_get_drvdata(dev);
+ struct device *host = usb3->host_dev;
+ enum usb_role cur_role = renesas_usb3_role_switch_get(dev);
+
+ pm_runtime_get_sync(dev);
+
+ if (cur_role == USB_ROLE_HOST && role == USB_ROLE_DEVICE) {
+ device_release_driver(host);
+ _usb3_set_mode(usb3, false);
+ } else if (cur_role == USB_ROLE_DEVICE && role == USB_ROLE_HOST) {
+ /* Must set the mode before device_attach of the host */
+ _usb3_set_mode(usb3, true);
+ if (device_attach(host) < 0)
+ dev_err(dev, "device_attach(usb3_port) failed\n");
+ }
+ pm_runtime_put(dev);
+
+ return 0;
+}
+
static ssize_t role_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -2404,6 +2448,8 @@ static int renesas_usb3_remove(struct platform_device *pdev)
device_remove_file(&pdev->dev, &dev_attr_role);
+ usb_role_switch_unregister(usb3->role_sw);
+
usb_del_gadget_udc(&usb3->gadget);
renesas_usb3_dma_free_prd(usb3, &pdev->dev);
@@ -2562,6 +2608,12 @@ static void renesas_usb3_init_ram(struct renesas_usb3 *usb3, struct device *dev,
EXTCON_NONE,
};
+static struct usb_role_switch_desc renesas_usb3_role_switch_desc = {
+ .set = renesas_usb3_role_switch_set,
+ .get = renesas_usb3_role_switch_get,
+ .allow_userspace_control = true,
+};
+
static int renesas_usb3_probe(struct platform_device *pdev)
{
struct renesas_usb3 *usb3;
@@ -2644,6 +2696,20 @@ static int renesas_usb3_probe(struct platform_device *pdev)
if (IS_ERR(usb3->phy))
usb3->phy = NULL;
+ usb3->role_sw = usb_role_switch_register(&pdev->dev,
+ &renesas_usb3_role_switch_desc);
+ if (!IS_ERR(usb3->role_sw)) {
+ usb3->host_dev = device_connection_find_by_graph(&pdev->dev,
+ 0, 0);
+ if (IS_ERR_OR_NULL(usb3->host_dev)) {
+ /* If not found, this driver will not use a role sw */
+ usb_role_switch_unregister(usb3->role_sw);
+ usb3->role_sw = NULL;
+ }
+ } else {
+ usb3->role_sw = NULL;
+ }
+
usb3->workaround_for_vbus = priv->workaround_for_vbus;
renesas_usb3_debugfs_init(usb3, &pdev->dev);
--
1.9.1
^ permalink raw reply related
* [PATCH/RFC v3 1/4] base: devcon: add a new API to find the graph
From: Yoshihiro Shimoda @ 2018-05-14 9:15 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland
Cc: heikki.krogerus, hdegoede, andy.shevchenko, linux-usb,
linux-renesas-soc, devicetree, Yoshihiro Shimoda
In-Reply-To: <1526289360-3997-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
This patch adds a new API "device_connection_find_by_graph()" to
find device connection by using graph.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
Documentation/driver-api/device_connection.rst | 4 +--
drivers/base/devcon.c | 43 ++++++++++++++++++++++++++
include/linux/device.h | 2 ++
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/Documentation/driver-api/device_connection.rst b/Documentation/driver-api/device_connection.rst
index affbc556..2e2d26f 100644
--- a/Documentation/driver-api/device_connection.rst
+++ b/Documentation/driver-api/device_connection.rst
@@ -19,7 +19,7 @@ Device connections alone do not create a dependency between the two devices.
They are only descriptions which are not tied to either of the devices directly.
A dependency between the two devices exists only if one of the two endpoint
devices requests a reference to the other. The descriptions themselves can be
-defined in firmware (not yet supported) or they can be built-in.
+defined in firmware or they can be built-in.
Usage
-----
@@ -40,4 +40,4 @@ API
---
.. kernel-doc:: drivers/base/devcon.c
- : functions: device_connection_find_match device_connection_find device_connection_add device_connection_remove
+ : functions: device_connection_find_match device_connection_find device_connection_add device_connection_remove device_connection_find_by_graph
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
index d427e80..5a0da33 100644
--- a/drivers/base/devcon.c
+++ b/drivers/base/devcon.c
@@ -7,6 +7,7 @@
*/
#include <linux/device.h>
+#include <linux/property.h>
static DEFINE_MUTEX(devcon_lock);
static LIST_HEAD(devcon_list);
@@ -134,3 +135,45 @@ void device_connection_remove(struct device_connection *con)
mutex_unlock(&devcon_lock);
}
EXPORT_SYMBOL_GPL(device_connection_remove);
+
+static int generic_graph_match(struct device *dev, void *fwnode)
+{
+ return dev->fwnode == fwnode;
+}
+
+/**
+ * device_connection_find_by_graph - Find two devices connected together
+ * @dev: Device to find connected device
+ * @port: identifier of the @dev port node
+ * @endpoint: identifier of the @dev endpoint node
+ *
+ * Find a connection with @port and @endpoint by using graph between @dev and
+ * another device. On success returns handle to the device that is connected
+ * to @dev, with the reference count for the found device incremented. Returns
+ * NULL if no matching connection was found, or ERR_PTR(-EPROBE_DEFER) when
+ * a connection was found but the other device has not been enumerated yet.
+ */
+struct device *device_connection_find_by_graph(struct device *dev, u32 port,
+ u32 endpoint)
+{
+ struct bus_type *bus;
+ struct fwnode_handle *remote;
+ struct device *conn;
+
+ remote = fwnode_graph_get_remote_node(dev_fwnode(dev), port, endpoint);
+ if (!remote)
+ return NULL;
+
+ for (bus = generic_match_buses[0]; bus; bus++) {
+ conn = bus_find_device(bus, NULL, remote, generic_graph_match);
+ if (conn)
+ return conn;
+ }
+
+ /*
+ * We only get called if a connection was found, tell the caller to
+ * wait for the other device to show up.
+ */
+ return ERR_PTR(-EPROBE_DEFER);
+}
+EXPORT_SYMBOL_GPL(device_connection_find_by_graph);
diff --git a/include/linux/device.h b/include/linux/device.h
index 0059b99..58f8544 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -751,6 +751,8 @@ void *device_connection_find_match(struct device *dev, const char *con_id,
void device_connection_add(struct device_connection *con);
void device_connection_remove(struct device_connection *con);
+struct device *device_connection_find_by_graph(struct device *dev, u32 port,
+ u32 endpoint);
/**
* enum device_link_state - Device link states.
--
1.9.1
^ permalink raw reply related
* [PATCH/RFC v3 0/4] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs
From: Yoshihiro Shimoda @ 2018-05-14 9:15 UTC (permalink / raw)
To: gregkh, robh+dt, mark.rutland
Cc: heikki.krogerus, hdegoede, andy.shevchenko, linux-usb,
linux-renesas-soc, devicetree, Yoshihiro Shimoda
This patch set is based on Felipe's usb.git / testing/next branch
(commit id = 5d1332a8eabd8bd5b8c322d45542968ee6f113be).
I still marked this patch set as "RFC". I would like to know whether
this way is good or not.
Changes from RFC v2:
- Add registering usb role switch into drivers/usb/gadget/udc/renesas_usb3
because hardware resource (a register) is shared and remove individual
usb role switch driver/dt-bindings for R-Car.
- Remove "usb_role_switch_get_by_graph" API because the renesas_usb3 driver
doesn't need such API now.
Changes from RFC:
- Remove "device-connection-id" and "usb role switch driver" dt-bingings.
- Remove drivers/of code.
- Add a new API for find the connection by using graph on devcon.c and roles.c.
- Use each new API on the rcar usb role switch and renesas_usb3 drivers.
- Update the dtsi file for r8a7795.
Yoshihiro Shimoda (4):
base: devcon: add a new API to find the graph
usb: gadget: udc: renesas_usb3: Add register of usb role switch
usb: gadget: udc: renesas_usb3: use usb role switch API
arm64: dts: renesas: r8a7795: add OF graph for usb role switch
.../devicetree/bindings/usb/renesas_usb3.txt | 15 +++++
Documentation/driver-api/device_connection.rst | 4 +-
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 12 ++++
drivers/base/devcon.c | 43 +++++++++++++
drivers/usb/gadget/udc/Kconfig | 1 +
drivers/usb/gadget/udc/renesas_usb3.c | 74 +++++++++++++++++++++-
include/linux/device.h | 2 +
7 files changed, 147 insertions(+), 4 deletions(-)
--
1.9.1
^ permalink raw reply
* RE: [PATCH v5 03/14] staging: typec: tcpci: add compatible string for nxp ptn5110
From: Jun Li @ 2018-05-14 9:15 UTC (permalink / raw)
To: Mats Karrman, robh+dt@kernel.org, gregkh@linuxfoundation.org,
heikki.krogerus@linux.intel.com, linux@roeck-us.net
Cc: a.hajda@samsung.com, cw00.choi@samsung.com,
shufan_lee@richtek.com, Peter Chen, gsomlo@gmail.com,
devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
dl-linux-imx
In-Reply-To: <b5a8eb68-c4dc-ee6e-5e3c-f2a49577e4c0@gmail.com>
Hi
> -----Original Message-----
> From: Mats Karrman [mailto:mats.dev.list@gmail.com]
> Sent: 2018年5月12日 3:52
> To: Jun Li <jun.li@nxp.com>; robh+dt@kernel.org; gregkh@linuxfoundation.org;
> heikki.krogerus@linux.intel.com; linux@roeck-us.net
> Cc: a.hajda@samsung.com; cw00.choi@samsung.com;
> shufan_lee@richtek.com; Peter Chen <peter.chen@nxp.com>;
> gsomlo@gmail.com; devicetree@vger.kernel.org; linux-usb@vger.kernel.org;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v5 03/14] staging: typec: tcpci: add compatible string for
> nxp ptn5110
>
> Hi Li Jun,
>
> On 2018-05-03 02:24, Li Jun wrote:
>
> > Add nxp ptn5110 typec controller compatible string: usb-tcpci,ptn5110,
> > which is a standard tcpci chip with power delivery support.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > drivers/staging/typec/tcpci.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/staging/typec/tcpci.c
> > b/drivers/staging/typec/tcpci.c index 076d97e..741a80a 100644
> > --- a/drivers/staging/typec/tcpci.c
> > +++ b/drivers/staging/typec/tcpci.c
> > @@ -576,6 +576,7 @@ MODULE_DEVICE_TABLE(i2c, tcpci_id);
> > #ifdef CONFIG_OF
> > static const struct of_device_id tcpci_of_match[] = {
> > { .compatible = "usb,tcpci", },
>
> Either this line should go away, or a "generic TCPCI controller" line should be
> added to the DT documentation.
This binding name didn't follow the rule "<vender prefix>, <chip specific>",
AFAIK there is no user on upstream kernel, if no objection, I can remove it.
Li Jun
>
> BR // Mats
>
> > + { .compatible = "nxp,ptn5110", },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, tcpci_of_match);
> >
^ permalink raw reply
* Re: [PATCH v5 14/14] media: ov772x: create subdevice device node
From: jacopo mondi @ 2018-05-14 9:11 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-media, devicetree, Jacopo Mondi, Laurent Pinchart,
Hans Verkuil, Sakari Ailus, Mauro Carvalho Chehab
In-Reply-To: <1525616369-8843-15-git-send-email-akinobu.mita@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]
Hi Akinobu,
thanks for the patch.
On Sun, May 06, 2018 at 11:19:29PM +0900, Akinobu Mita wrote:
> Set the V4L2_SUBDEV_FL_HAS_DEVNODE flag for the subdevice so that the
> subdevice device node is created.
>
> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Thanks
j
> ---
> * v5
> - No changes
>
> drivers/media/i2c/ov772x.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 4b479f9..f7f4fe6 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
> @@ -1409,6 +1409,7 @@ static int ov772x_probe(struct i2c_client *client,
> mutex_init(&priv->lock);
>
> v4l2_i2c_subdev_init(&priv->subdev, client, &ov772x_subdev_ops);
> + priv->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> v4l2_ctrl_handler_init(&priv->hdl, 3);
> /* Use our mutex for the controls */
> priv->hdl.lock = &priv->lock;
> --
> 2.7.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCH 1/3] thermal: imx: remove cpufreq cooling registration
From: Anson Huang @ 2018-05-14 9:10 UTC (permalink / raw)
To: Bastian Stender, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, Fabio Estevam, robh+dt@kernel.org,
mark.rutland@arm.com, rjw@rjwysocki.net, viresh.kumar@linaro.org,
rui.zhang@intel.com, edubezval@gmail.com
Cc: devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
dl-linux-imx, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5a449fc0-4d3e-c7c7-0e9a-43efb4b909cf@pengutronix.de>
Anson Huang
Best Regards!
> -----Original Message-----
> From: Bastian Stender [mailto:bst@pengutronix.de]
> Sent: Monday, May 14, 2018 4:37 PM
> To: Anson Huang <anson.huang@nxp.com>; shawnguo@kernel.org;
> s.hauer@pengutronix.de; kernel@pengutronix.de; Fabio Estevam
> <fabio.estevam@nxp.com>; robh+dt@kernel.org; mark.rutland@arm.com;
> rjw@rjwysocki.net; viresh.kumar@linaro.org; rui.zhang@intel.com;
> edubezval@gmail.com
> Cc: devicetree@vger.kernel.org; linux-pm@vger.kernel.org; dl-linux-imx
> <linux-imx@nxp.com>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3] thermal: imx: remove cpufreq cooling registration
>
> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fpatch%2F10059085%2F&data=02%7C01%7Canson.huang
> %40nxp.com%7C179da3635cab4a14deef08d5b975ecb6%7C686ea1d3bc2b4c6f
> a92cd99c5c301635%7C0%7C0%7C636618838508978629&sdata=BcQ9tc%2BE
> CZ%2Fk4AsZFxshgmvSsPg7eRN0ASzP8LO8yBI%3D&reserved=0
>
> Some of the comments might apply here too.
Ah, I did NOT notice this thread, so how to proceed, will you continue to finish your patch?
If yes, then you can just ignore/skip my patch, thanks.
Anson.
>
> 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
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&data=02%7C01%7Canson.huang%40nxp.com%7C179da36
> 35cab4a14deef08d5b975ecb6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
> %7C0%7C636618838508978629&sdata=kHHjnbmj2kV0aPlAvULXUh%2Fm%2Fp
> gbu21luMQ6jfIUgLo%3D&reserved=0
> Peiner Str. 6-8, 31137 Hildesheim, Germany Amtsgericht Hildesheim, HRA 2686
^ permalink raw reply
* Re: [PATCH v5 13/14] media: ov772x: make set_fmt() and s_frame_interval() return -EBUSY while streaming
From: jacopo mondi @ 2018-05-14 9:10 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-media, devicetree, Jacopo Mondi, Laurent Pinchart,
Hans Verkuil, Sakari Ailus, Mauro Carvalho Chehab
In-Reply-To: <1525616369-8843-14-git-send-email-akinobu.mita@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]
Hi Akinobu,
thanks for the patch
On Sun, May 06, 2018 at 11:19:28PM +0900, Akinobu Mita wrote:
> The ov772x driver is going to offer a V4L2 sub-device interface, so
> changing the output data format and the frame interval on this sub-device
> can be made anytime. However, these requests are preferred to fail while
> the video stream on the device is active.
>
> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Thanks
j
> ---
> * v5:
> - Make s_frame_interval() return -EBUSY while streaming
>
> drivers/media/i2c/ov772x.c | 43 +++++++++++++++++++++++++++++++++----------
> 1 file changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 262a7e5..4b479f9 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
> @@ -424,9 +424,10 @@ struct ov772x_priv {
> /* band_filter = COM8[5] ? 256 - BDBASE : 0 */
> struct v4l2_ctrl *band_filter_ctrl;
> unsigned int fps;
> - /* lock to protect power_count */
> + /* lock to protect power_count and streaming */
> struct mutex lock;
> int power_count;
> + int streaming;
> #ifdef CONFIG_MEDIA_CONTROLLER
> struct media_pad pad;
> #endif
> @@ -603,18 +604,28 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int enable)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> struct ov772x_priv *priv = to_ov772x(sd);
> + int ret = 0;
>
> - if (!enable) {
> - ov772x_mask_set(client, COM2, SOFT_SLEEP_MODE, SOFT_SLEEP_MODE);
> - return 0;
> - }
> + mutex_lock(&priv->lock);
>
> - ov772x_mask_set(client, COM2, SOFT_SLEEP_MODE, 0);
> + if (priv->streaming == enable)
> + goto done;
>
> - dev_dbg(&client->dev, "format %d, win %s\n",
> - priv->cfmt->code, priv->win->name);
> + ret = ov772x_mask_set(client, COM2, SOFT_SLEEP_MODE,
> + enable ? 0 : SOFT_SLEEP_MODE);
> + if (ret)
> + goto done;
>
> - return 0;
> + if (enable) {
> + dev_dbg(&client->dev, "format %d, win %s\n",
> + priv->cfmt->code, priv->win->name);
> + }
> + priv->streaming = enable;
> +
> +done:
> + mutex_unlock(&priv->lock);
> +
> + return ret;
> }
>
> static unsigned int ov772x_select_fps(struct ov772x_priv *priv,
> @@ -743,9 +754,15 @@ static int ov772x_s_frame_interval(struct v4l2_subdev *sd,
> unsigned int fps;
> int ret = 0;
>
> + mutex_lock(&priv->lock);
> +
> + if (priv->streaming) {
> + ret = -EBUSY;
> + goto error;
> + }
> +
> fps = ov772x_select_fps(priv, tpf);
>
> - mutex_lock(&priv->lock);
> /*
> * If the device is not powered up by the host driver do
> * not apply any changes to H/W at this time. Instead
> @@ -1222,6 +1239,12 @@ static int ov772x_set_fmt(struct v4l2_subdev *sd,
> }
>
> mutex_lock(&priv->lock);
> +
> + if (priv->streaming) {
> + ret = -EBUSY;
> + goto error;
> + }
> +
> /*
> * If the device is not powered up by the host driver do
> * not apply any changes to H/W at this time. Instead
> --
> 2.7.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 12/14] media: ov772x: avoid accessing registers under power saving mode
From: jacopo mondi @ 2018-05-14 9:06 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-media, devicetree, Jacopo Mondi, Laurent Pinchart,
Hans Verkuil, Sakari Ailus, Mauro Carvalho Chehab
In-Reply-To: <1525616369-8843-13-git-send-email-akinobu.mita@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5700 bytes --]
Hi Akinobu,
a small nit below
On Sun, May 06, 2018 at 11:19:27PM +0900, Akinobu Mita wrote:
> The set_fmt() in subdev pad ops, the s_ctrl() for subdev control handler,
> and the s_frame_interval() in subdev video ops could be called when the
> device is under power saving mode. These callbacks for ov772x driver
> cause updating H/W registers that will fail under power saving mode.
>
> This avoids it by not apply any changes to H/W if the device is not powered
> up. Instead the changes will be restored right after power-up.
>
> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> ---
> * v5
> - No changes
>
> drivers/media/i2c/ov772x.c | 79 +++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 64 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 9292a18..262a7e5 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
> @@ -741,19 +741,30 @@ static int ov772x_s_frame_interval(struct v4l2_subdev *sd,
> struct ov772x_priv *priv = to_ov772x(sd);
> struct v4l2_fract *tpf = &ival->interval;
> unsigned int fps;
> - int ret;
> + int ret = 0;
>
> fps = ov772x_select_fps(priv, tpf);
>
> - ret = ov772x_set_frame_rate(priv, fps, priv->cfmt, priv->win);
> - if (ret)
> - return ret;
> + mutex_lock(&priv->lock);
> + /*
> + * If the device is not powered up by the host driver do
> + * not apply any changes to H/W at this time. Instead
> + * the frame rate will be restored right after power-up.
> + */
> + if (priv->power_count > 0) {
> + ret = ov772x_set_frame_rate(priv, fps, priv->cfmt, priv->win);
> + if (ret)
> + goto error;
> + }
>
> tpf->numerator = 1;
> tpf->denominator = fps;
> priv->fps = fps;
>
> - return 0;
> +error:
> + mutex_unlock(&priv->lock);
> +
> + return ret;
> }
>
> static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
> @@ -765,6 +776,16 @@ static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
> int ret = 0;
> u8 val;
>
> + /* v4l2_ctrl_lock() locks our own mutex */
> +
> + /*
> + * If the device is not powered up by the host driver do
> + * not apply any controls to H/W at this time. Instead
> + * the controls will be restored right after power-up.
> + */
> + if (priv->power_count == 0)
> + return 0;
> +
> switch (ctrl->id) {
> case V4L2_CID_VFLIP:
> val = ctrl->val ? VFLIP_IMG : 0x00;
> @@ -885,6 +906,10 @@ static int ov772x_power_off(struct ov772x_priv *priv)
> return 0;
> }
>
> +static int ov772x_set_params(struct ov772x_priv *priv,
> + const struct ov772x_color_format *cfmt,
> + const struct ov772x_win_size *win);
> +
> static int ov772x_s_power(struct v4l2_subdev *sd, int on)
> {
> struct ov772x_priv *priv = to_ov772x(sd);
> @@ -895,8 +920,20 @@ static int ov772x_s_power(struct v4l2_subdev *sd, int on)
> /* If the power count is modified from 0 to != 0 or from != 0 to 0,
> * update the power state.
> */
> - if (priv->power_count == !on)
> - ret = on ? ov772x_power_on(priv) : ov772x_power_off(priv);
> + if (priv->power_count == !on) {
> + if (on) {
> + ret = ov772x_power_on(priv);
> + /*
> + * Restore the format, the frame rate, and
> + * the controls
> + */
> + if (!ret)
> + ret = ov772x_set_params(priv, priv->cfmt,
> + priv->win);
> + } else {
> + ret = ov772x_power_off(priv);
> + }
> + }
>
> if (!ret) {
> /* Update the power count. */
> @@ -1163,7 +1200,7 @@ static int ov772x_set_fmt(struct v4l2_subdev *sd,
> struct v4l2_mbus_framefmt *mf = &format->format;
> const struct ov772x_color_format *cfmt;
> const struct ov772x_win_size *win;
> - int ret;
> + int ret = 0;
>
> if (format->pad)
> return -EINVAL;
> @@ -1184,14 +1221,24 @@ static int ov772x_set_fmt(struct v4l2_subdev *sd,
> return 0;
> }
>
> - ret = ov772x_set_params(priv, cfmt, win);
> - if (ret < 0)
> - return ret;
> -
> + mutex_lock(&priv->lock);
> + /*
> + * If the device is not powered up by the host driver do
> + * not apply any changes to H/W at this time. Instead
> + * the format will be restored right after power-up.
> + */
> + if (priv->power_count > 0) {
> + ret = ov772x_set_params(priv, cfmt, win);
> + if (ret < 0)
> + goto error;
> + }
> priv->win = win;
> priv->cfmt = cfmt;
>
> - return 0;
> +error:
> + mutex_unlock(&priv->lock);
> +
> + return ret;
> }
>
> static int ov772x_video_probe(struct ov772x_priv *priv)
> @@ -1201,7 +1248,7 @@ static int ov772x_video_probe(struct ov772x_priv *priv)
> const char *devname;
> int ret;
>
> - ret = ov772x_s_power(&priv->subdev, 1);
> + ret = ov772x_power_on(priv);
> if (ret < 0)
> return ret;
>
> @@ -1241,7 +1288,7 @@ static int ov772x_video_probe(struct ov772x_priv *priv)
> ret = v4l2_ctrl_handler_setup(&priv->hdl);
>
> done:
> - ov772x_s_power(&priv->subdev, 0);
> + ov772x_power_off(priv);
>
> return ret;
> }
> @@ -1340,6 +1387,8 @@ static int ov772x_probe(struct i2c_client *client,
>
> v4l2_i2c_subdev_init(&priv->subdev, client, &ov772x_subdev_ops);
> v4l2_ctrl_handler_init(&priv->hdl, 3);
> + /* Use our mutex for the controls */
> + priv->hdl.lock = &priv->lock;
Isn't this unrelated?
Apart from that,
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Thanks
j
> priv->vflip_ctrl = v4l2_ctrl_new_std(&priv->hdl, &ov772x_ctrl_ops,
> V4L2_CID_VFLIP, 0, 1, 1, 0);
> priv->hflip_ctrl = v4l2_ctrl_new_std(&priv->hdl, &ov772x_ctrl_ops,
> --
> 2.7.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCH v5 01/14] dt-bindings: connector: add properties for typec
From: Jun Li @ 2018-05-14 9:06 UTC (permalink / raw)
To: Mats Karrman, robh+dt@kernel.org, gregkh@linuxfoundation.org,
heikki.krogerus@linux.intel.com, linux@roeck-us.net
Cc: a.hajda@samsung.com, cw00.choi@samsung.com,
shufan_lee@richtek.com, Peter Chen, gsomlo@gmail.com,
devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
dl-linux-imx
In-Reply-To: <deb2502c-4ffc-c7ef-ec6f-4fb5b7685bf6@gmail.com>
Hi
> -----Original Message-----
> From: Mats Karrman [mailto:mats.dev.list@gmail.com]
> Sent: 2018年5月12日 3:49
> To: Jun Li <jun.li@nxp.com>; robh+dt@kernel.org; gregkh@linuxfoundation.org;
> heikki.krogerus@linux.intel.com; linux@roeck-us.net
> Cc: a.hajda@samsung.com; cw00.choi@samsung.com;
> shufan_lee@richtek.com; Peter Chen <peter.chen@nxp.com>;
> gsomlo@gmail.com; devicetree@vger.kernel.org; linux-usb@vger.kernel.org;
> dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v5 01/14] dt-bindings: connector: add properties for typec
>
> Hi Li Jun,
>
> On 2018-05-03 02:24, Li Jun wrote:
>
> > Add bingdings supported by current typec driver, so user can pass all
> > those properties via dt.
> >
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > ---
> > .../bindings/connector/usb-connector.txt | 44
> +++++++++++++++
> > include/dt-bindings/usb/pd.h | 62
> ++++++++++++++++++++++
> > 2 files changed, 106 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > index e1463f1..4b19de6d0 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -15,6 +15,33 @@ Optional properties:
> > - type: size of the connector, should be specified in case of USB-A, USB-B
> > non-fullsize connectors: "mini", "micro".
> >
> > +Optional properties for usb-c-connector:
> > +- power-role: should be one of "source", "sink" or "dual"(DRP) if
> > +typec
> > + connector has power support.
> > +- try-power-role: preferred power role if "dual"(DRP) can support
> > +Try.SNK
> > + or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC.
> > +- data-role: should be one of "host", "device", "dual"(DRD) if typec
> > + connector supports USB data.
> > +
> > +Required properties for usb-c-connector with power delivery support:
> > +- source-pdos: An array of u32 with each entry providing supported
> > +power
> > + source data object(PDO), the detailed bit definitions of PDO can be
> > +found
> > + in "Universal Serial Bus Power Delivery Specification" chapter
> > +6.4.1.2
> > + Source_Capabilities Message, the order of each entry(PDO) should
> > +follow
> > + the PD spec chapter 6.4.1. Required for power source and power dual
> role.
> > + User can specify the source PDO array via PDO_FIXED/BATT/VAR()
> > +defined in
> > + dt-bindings/usb/pd.h.
> > +- sink-pdos: An array of u32 with each entry providing supported
> > +power
> > + sink data object(PDO), the detailed bit definitions of PDO can be
> > +found
> > + in "Universal Serial Bus Power Delivery Specification" chapter
> > +6.4.1.3
> > + Sink Capabilities Message, the order of each entry(PDO) should
> > +follow
> > + the PD spec chapter 6.4.1. Required for power sink and power dual role.
> > + User can specify the sink PDO array via PDO_FIXED/BATT/VAR()
> > +defined in
> > + dt-bindings/usb/pd.h.
> > +- op-sink-microwatt: Sink required operating power in microwatt, if
> > +source
> > + can't offer the power, Capability Mismatch is set, required for
> > +power
>
> ...set. Required...
> (new sentence, otherwise it's unclear what is required; op-sink-microwatt or
> Capability Mismatch set)
OK, will update as you suggested.
Thanks
Li Jun
^ permalink raw reply
* Re: Allwinner A64: Issue on external rtc clock to wifi chip
From: Maxime Ripard @ 2018-05-14 9:06 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Michael Trimarchi, linux-sunxi, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <CAMty3ZC3ggxkZwirpQ-aRP8Udg=aYypBArb0KcR0_Z0AG8wATA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]
On Mon, May 14, 2018 at 02:34:22PM +0530, Jagan Teki wrote:
> On Mon, May 14, 2018 at 1:57 PM, Maxime Ripard
> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > 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.
>
> This is 4.17-rc4 do you want to try it on 4.16 ?
No, this is next-20180503. Please try with 4.17-rc4
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Uwe Kleine-König @ 2018-05-14 9:05 UTC (permalink / raw)
To: Marco Felsch
Cc: robh+dt, mark.rutland, andrew, f.fainelli, netdev, Markus Niebel,
kernel, devicetree
In-Reply-To: <20180514082218.29158-1-m.felsch@pengutronix.de>
Hello,
> 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;
These could be declared in more local scope.
> 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);
There is no need for two variables, just use a single int variable that
on all Linux archs can hold the whole domain of u16 should be fine.
> + }
> + }
Maybe issue a warning if reading MII_CTRL1000 failed?
> }
>
> return ksz9031_center_flp_timing(phydev);
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Allwinner A64: Issue on external rtc clock to wifi chip
From: Jagan Teki @ 2018-05-14 9:04 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Michael Trimarchi, linux-sunxi, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <20180514082744.ydmfg5mzsbol5onu@flea>
On Mon, May 14, 2018 at 1:57 PM, Maxime Ripard
<maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> 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.
This is 4.17-rc4 do you want to try it on 4.16 ?
^ permalink raw reply
* Re: [PATCH v5 10/14] media: ov772x: reconstruct s_frame_interval()
From: jacopo mondi @ 2018-05-14 9:02 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-media, devicetree, Jacopo Mondi, Laurent Pinchart,
Hans Verkuil, Sakari Ailus, Mauro Carvalho Chehab
In-Reply-To: <1525616369-8843-11-git-send-email-akinobu.mita@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4252 bytes --]
Hi Akinobu,
thanks for resending
On Sun, May 06, 2018 at 11:19:25PM +0900, Akinobu Mita wrote:
> This splits the s_frame_interval() in subdev video ops into selecting the
> frame interval and setting up the registers.
>
> This is a preparatory change to avoid accessing registers under power
> saving mode.
>
> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Thanks
j
> ---
> * v5
> - Align arguments to open parenthesis
> - Sort variable declarations
>
> drivers/media/i2c/ov772x.c | 56 +++++++++++++++++++++++++++++-----------------
> 1 file changed, 35 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> index 6c0c792..92ad13f 100644
> --- a/drivers/media/i2c/ov772x.c
> +++ b/drivers/media/i2c/ov772x.c
> @@ -617,25 +617,16 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int enable)
> return 0;
> }
>
> -static int ov772x_set_frame_rate(struct ov772x_priv *priv,
> - struct v4l2_fract *tpf,
> - const struct ov772x_color_format *cfmt,
> - const struct ov772x_win_size *win)
> +static unsigned int ov772x_select_fps(struct ov772x_priv *priv,
> + struct v4l2_fract *tpf)
> {
> - struct i2c_client *client = v4l2_get_subdevdata(&priv->subdev);
> - unsigned long fin = clk_get_rate(priv->clk);
> unsigned int fps = tpf->numerator ?
> tpf->denominator / tpf->numerator :
> tpf->denominator;
> unsigned int best_diff;
> - unsigned int fsize;
> - unsigned int pclk;
> unsigned int diff;
> unsigned int idx;
> unsigned int i;
> - u8 clkrc = 0;
> - u8 com4 = 0;
> - int ret;
>
> /* Approximate to the closest supported frame interval. */
> best_diff = ~0L;
> @@ -646,7 +637,25 @@ static int ov772x_set_frame_rate(struct ov772x_priv *priv,
> best_diff = diff;
> }
> }
> - fps = ov772x_frame_intervals[idx];
> +
> + return ov772x_frame_intervals[idx];
> +}
> +
> +static int ov772x_set_frame_rate(struct ov772x_priv *priv,
> + unsigned int fps,
> + const struct ov772x_color_format *cfmt,
> + const struct ov772x_win_size *win)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&priv->subdev);
> + unsigned long fin = clk_get_rate(priv->clk);
> + unsigned int best_diff;
> + unsigned int fsize;
> + unsigned int pclk;
> + unsigned int diff;
> + unsigned int i;
> + u8 clkrc = 0;
> + u8 com4 = 0;
> + int ret;
>
> /* Use image size (with blankings) to calculate desired pixel clock. */
> switch (cfmt->com7 & OFMT_MASK) {
> @@ -711,10 +720,6 @@ static int ov772x_set_frame_rate(struct ov772x_priv *priv,
> if (ret < 0)
> return ret;
>
> - tpf->numerator = 1;
> - tpf->denominator = fps;
> - priv->fps = tpf->denominator;
> -
> return 0;
> }
>
> @@ -735,8 +740,20 @@ static int ov772x_s_frame_interval(struct v4l2_subdev *sd,
> {
> struct ov772x_priv *priv = to_ov772x(sd);
> struct v4l2_fract *tpf = &ival->interval;
> + unsigned int fps;
> + int ret;
> +
> + fps = ov772x_select_fps(priv, tpf);
> +
> + ret = ov772x_set_frame_rate(priv, fps, priv->cfmt, priv->win);
> + if (ret)
> + return ret;
>
> - return ov772x_set_frame_rate(priv, tpf, priv->cfmt, priv->win);
> + tpf->numerator = 1;
> + tpf->denominator = fps;
> + priv->fps = fps;
> +
> + return 0;
> }
>
> static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
> @@ -993,7 +1010,6 @@ static int ov772x_set_params(struct ov772x_priv *priv,
> const struct ov772x_win_size *win)
> {
> struct i2c_client *client = v4l2_get_subdevdata(&priv->subdev);
> - struct v4l2_fract tpf;
> int ret;
> u8 val;
>
> @@ -1075,9 +1091,7 @@ static int ov772x_set_params(struct ov772x_priv *priv,
> goto ov772x_set_fmt_error;
>
> /* COM4, CLKRC: Set pixel clock and framerate. */
> - tpf.numerator = 1;
> - tpf.denominator = priv->fps;
> - ret = ov772x_set_frame_rate(priv, &tpf, cfmt, win);
> + ret = ov772x_set_frame_rate(priv, priv->fps, cfmt, win);
> if (ret < 0)
> goto ov772x_set_fmt_error;
>
> --
> 2.7.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* 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
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