* Re: [PATCH V4 3/6] dt/bindings: Add bindings for Tegra GMI controller
From: Thierry Reding @ 2016-11-07 11:35 UTC (permalink / raw)
To: Mirza Krak
Cc: swarren-3lzwWm7+Weoh9ZMKESR00Q, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA,
pgaikwad-DDmLM1+adcrQT0dZR+AlfA,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478507405-13204-4-git-send-email-mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
On Mon, Nov 07, 2016 at 09:30:02AM +0100, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Document the devicetree bindings for the Generic Memory Interface (GMI)
> bus driver found on Tegra SOCs.
>
> Signed-off-by: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Marcel Ziswiler <marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>
> Changes in v2:
> - Updated examples and some information based on comments from Jon Hunter.
>
> Changes in v3:
> - Updates ranges description based on comments from Rob Herring
>
> Changes in v4:
> - renamed snor-*-inv to snor-*-active-high
>
> .../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 +++++++++++++++++++++
> 1 file changed, 132 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/8] iio:core: add a callback to allow drivers to provide _available attributes
From: Daniel Baluta @ 2016-11-07 11:37 UTC (permalink / raw)
To: Peter Rosin
Cc: Linux Kernel Mailing List, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring,
Mark Rutland, linux-iio@vger.kernel.org, Devicetree List
In-Reply-To: <1477262381-7800-2-git-send-email-peda@axentia.se>
On Mon, Oct 24, 2016 at 1:39 AM, Peter Rosin <peda@axentia.se> wrote:
> From: Jonathan Cameron <jic23@kernel.org>
>
> A large number of attributes can only take a limited range of values.
> Currently in IIO this is handled by directly registering additional
> *_available attributes thus providing this information to userspace.
>
> It is desirable to provide this information via the core for much the same
> reason this was done for the actual channel information attributes in the
> first place. If it isn't there, then it can only really be accessed from
> userspace. Other in kernel IIO consumers have no access to what valid
> parameters are.
>
> Two forms are currently supported:
> * list of values in one particular IIO_VAL_* format.
> e.g. 1.300000 1.500000 1.730000
> * range specification with a step size:
> e.g. [1.000000 0.500000 2.500000]
> equivalent to 1.000000 1.5000000 2.000000 2.500000
Is there any driver using this format? :)
>
> An addition set of masks are used to allow different sharing rules for the
> *_available attributes generated.
>
> This allows for example:
>
> in_accel_x_offset
> in_accel_y_offset
> in_accel_offset_available.
>
> We could have gone with having a specification for each and every
> info_mask element but that would have meant changing the existing userspace
> ABI. This approach does not.
>
> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
> [forward ported, added some docs and fixed buffer overflows /peda]
> Signed-off-by: Peter Rosin <peda@axentia.se>
The patch looks good to me at a first glance.
^ permalink raw reply
* Re: [PATCH V4 6/6] bus: Add support for Tegra Generic Memory Interface
From: Thierry Reding @ 2016-11-07 11:49 UTC (permalink / raw)
To: Mirza Krak
Cc: swarren-3lzwWm7+Weoh9ZMKESR00Q, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA,
pgaikwad-DDmLM1+adcrQT0dZR+AlfA,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478507405-13204-7-git-send-email-mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]
On Mon, Nov 07, 2016 at 09:30:05AM +0100, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> The Generic Memory Interface bus can be used to connect high-speed
> devices such as NOR flash, FPGAs, DSPs...
>
> Signed-off-by: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Marcel Ziswiler <marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
> ---
>
> Changes in v2:
> - Fixed some checkpatch errors
> - Re-ordered probe to get rid of local variables
> - Moved of_platform_default_populate call to the end of probe
> - Use the timing and configuration properties from the child device
> - Added warning if more then 1 child device exist
>
> Changes in v3:
> - added helper function to disable the controller which is used in remove and
> on error.
> - Added logic to parse CS# from "ranges" property with fallback to "reg"
> property
>
> Changes in v4:
> - added sanity check of chip-select property (fail if invalid)
> - adjusted for device tree binding property name changes
> - fail probe if there are no child nodes
> - removed superfluous error message
> - removed superfluous newline in Kconfig
>
> drivers/bus/Kconfig | 7 ++
> drivers/bus/Makefile | 1 +
> drivers/bus/tegra-gmi.c | 275 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 283 insertions(+)
> create mode 100644 drivers/bus/tegra-gmi.c
Applied with a bit of code reshuffling to make things more symmetric as
well as a couple of pedantic cleanups because I couldn't resist.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/8] iio:core: add a callback to allow drivers to provide _available attributes
From: Peter Rosin @ 2016-11-07 11:57 UTC (permalink / raw)
To: Daniel Baluta
Cc: Linux Kernel Mailing List, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Devicetree List
In-Reply-To: <CAEnQRZDgF-x6rNiS1Uv9Evdt1sVfUu9pMF98Z4=r-vKP52C1kA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2016-11-07 12:37, Daniel Baluta wrote:
> On Mon, Oct 24, 2016 at 1:39 AM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>> From: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> A large number of attributes can only take a limited range of values.
>> Currently in IIO this is handled by directly registering additional
>> *_available attributes thus providing this information to userspace.
>>
>> It is desirable to provide this information via the core for much the same
>> reason this was done for the actual channel information attributes in the
>> first place. If it isn't there, then it can only really be accessed from
>> userspace. Other in kernel IIO consumers have no access to what valid
>> parameters are.
>>
>> Two forms are currently supported:
>> * list of values in one particular IIO_VAL_* format.
>> e.g. 1.300000 1.500000 1.730000
>> * range specification with a step size:
>> e.g. [1.000000 0.500000 2.500000]
>> equivalent to 1.000000 1.5000000 2.000000 2.500000
>
> Is there any driver using this format? :)
Yes, soon. Hopefully. See patch 3/8
iio: mcp4531: provide range of available raw values
https://patchwork.kernel.org/patch/9391283/
>>
>> An addition set of masks are used to allow different sharing rules for the
>> *_available attributes generated.
>>
>> This allows for example:
>>
>> in_accel_x_offset
>> in_accel_y_offset
>> in_accel_offset_available.
>>
>> We could have gone with having a specification for each and every
>> info_mask element but that would have meant changing the existing userspace
>> ABI. This approach does not.
>>
>> Signed-off-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> [forward ported, added some docs and fixed buffer overflows /peda]
>> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>
> The patch looks good to me at a first glance.
Thanks, may I add your acked-by if/when I respin?
Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/6] Documentation: devicetree: dwc3: Add interrupt moderation
From: Mark Rutland @ 2016-11-07 12:00 UTC (permalink / raw)
To: Felipe Balbi
Cc: John Youn, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In-Reply-To: <87lgx3phxi.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Tue, Nov 01, 2016 at 01:18:17PM +0200, Felipe Balbi wrote:
>
> Hi,
>
> John Youn <John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
> >>>> John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
> >>>>> Add interrupt moderation interval binding for dwc3.
> >>>>>
> >>>>> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> >>>>> ---
> >>>>> Documentation/devicetree/bindings/usb/dwc3.txt | 1 +
> >>>>> 1 file changed, 1 insertion(+)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> >>>>> index e3e6983..17de9fc 100644
> >>>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> >>>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> >>>>> @@ -53,6 +53,7 @@ Optional properties:
> >>>>> - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ
> >>>>> register for post-silicon frame length adjustment when the
> >>>>> fladj_30mhz_sdbnd signal is invalid or incorrect.
> >>>>> + - snps,imod_interval: the interrupt moderation interval.
> >>>>
> >>>> on top of all other comments, what's the unit here? nanoseconds? clock cycles?
> >>>>
> >>>
> >>> Number of 250 ns intervals. I'll update the description to clarify.
> >>
> >> it's probably better to add it in nanoseconds itself, then let driver
> >> compute register value with DIV_ROUND_UP()
> >>
> >
> > I'm fine with it either way, but I think "increments of 250 ns" is
> > slightly cleaner in that it reflects the exact settings that are
> > possible and documented, and also fits neatly into a u16.
>
> I don't know, I'll leave this to Mark and the other devicetree folks,
> but I remember there was a preference of not passing register values via
> devicetree. What if a following HW revision decides to change 250ns
> increments to 125ns increments?
>
> Mark?
Generally, directly human-readable units are preferable, with some
validation/reporting left to the driver for cases the HW cannot support.
In this case, some *-interval-ns property would be better.
That said, it sounds like we're all agreed that we don't need this
property for now. :)
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 0/2] support USB2 PHY OTG port for rk3399
From: William Wu @ 2016-11-07 12:08 UTC (permalink / raw)
To: kishon-l0cyMroinI0, heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frank.wang-TNX95d0MmH7DzftRWevZcw,
huangtao-TNX95d0MmH7DzftRWevZcw, dianders-hpIqsD4AKlfQT0dZR+AlfA,
briannorris-hpIqsD4AKlfQT0dZR+AlfA, groeck-hpIqsD4AKlfQT0dZR+AlfA,
wulf-TNX95d0MmH7DzftRWevZcw
This series add support for rk3399 USB2 PHY0 and PHY1 OTG port.
rk3399 has two USB2 PHYs, and each USB2 PHY is comprised of one
Host port and one OTG port. We have supported Host port before,
and try to support OTG port now.
Test on rk3399-evb board.
William Wu (2):
phy: rockchip-inno-usb2: support otg-port for rk3399
arm64: dts: rockchip: add usb2-phy otg-port support for rk3399
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 21 ++
drivers/phy/phy-rockchip-inno-usb2.c | 591 +++++++++++++++++++++++++++++--
2 files changed, 582 insertions(+), 30 deletions(-)
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/2] phy: rockchip-inno-usb2: support otg-port for rk3399
From: William Wu @ 2016-11-07 12:08 UTC (permalink / raw)
To: kishon, heiko
Cc: linux-kernel, linux-arm-kernel, linux-rockchip, devicetree,
robh+dt, frank.wang, huangtao, dianders, briannorris, groeck,
wulf
In-Reply-To: <1478520529-8869-1-git-send-email-wulf@rock-chips.com>
The rk3399 SoC USB2 PHY is comprised of one Host port and
one OTG port. And OTG port is for USB2.0 part of USB3.0 OTG
controller, as a part to construct a fully feature Type-C
subsystem.
With this patch, we can support OTG port with the following
functions:
- Support BC1.2 charger detect, and use extcon notifier to
send USB charger types to power driver.
- Support PHY suspend for power management.
- Support OTG Host only mode.
Signed-off-by: William Wu <wulf@rock-chips.com>
---
Changes in v3:
- split the clock fix into a separate patch
Changes in v2:
- remove wakelock
drivers/phy/phy-rockchip-inno-usb2.c | 591 +++++++++++++++++++++++++++++++++--
1 file changed, 561 insertions(+), 30 deletions(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
index ac20310..ecfd7d1 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -17,6 +17,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/delay.h>
+#include <linux/extcon.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/gpio/consumer.h>
@@ -30,11 +31,15 @@
#include <linux/of_platform.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/power_supply.h>
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
+#include <linux/usb/of.h>
+#include <linux/usb/otg.h>
#define BIT_WRITEABLE_SHIFT 16
-#define SCHEDULE_DELAY (60 * HZ)
+#define SCHEDULE_DELAY (60 * HZ)
+#define OTG_SCHEDULE_DELAY (2 * HZ)
enum rockchip_usb2phy_port_id {
USB2PHY_PORT_OTG,
@@ -49,6 +54,37 @@ enum rockchip_usb2phy_host_state {
PHY_STATE_FS_LS_ONLINE = 4,
};
+/**
+ * Different states involved in USB charger detection.
+ * USB_CHG_STATE_UNDEFINED USB charger is not connected or detection
+ * process is not yet started.
+ * USB_CHG_STATE_WAIT_FOR_DCD Waiting for Data pins contact.
+ * USB_CHG_STATE_DCD_DONE Data pin contact is detected.
+ * USB_CHG_STATE_PRIMARY_DONE Primary detection is completed (Detects
+ * between SDP and DCP/CDP).
+ * USB_CHG_STATE_SECONDARY_DONE Secondary detection is completed (Detects
+ * between DCP and CDP).
+ * USB_CHG_STATE_DETECTED USB charger type is determined.
+ */
+enum usb_chg_state {
+ USB_CHG_STATE_UNDEFINED = 0,
+ USB_CHG_STATE_WAIT_FOR_DCD,
+ USB_CHG_STATE_DCD_DONE,
+ USB_CHG_STATE_PRIMARY_DONE,
+ USB_CHG_STATE_SECONDARY_DONE,
+ USB_CHG_STATE_DETECTED,
+};
+
+static const unsigned int rockchip_usb2phy_extcon_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
+ EXTCON_CHG_USB_SDP,
+ EXTCON_CHG_USB_CDP,
+ EXTCON_CHG_USB_DCP,
+ EXTCON_CHG_USB_SLOW,
+ EXTCON_NONE,
+};
+
struct usb2phy_reg {
unsigned int offset;
unsigned int bitend;
@@ -58,19 +94,55 @@ struct usb2phy_reg {
};
/**
+ * struct rockchip_chg_det_reg: usb charger detect registers
+ * @cp_det: charging port detected successfully.
+ * @dcp_det: dedicated charging port detected successfully.
+ * @dp_det: assert data pin connect successfully.
+ * @idm_sink_en: open dm sink curren.
+ * @idp_sink_en: open dp sink current.
+ * @idp_src_en: open dm source current.
+ * @rdm_pdwn_en: open dm pull down resistor.
+ * @vdm_src_en: open dm voltage source.
+ * @vdp_src_en: open dp voltage source.
+ * @opmode: utmi operational mode.
+ */
+struct rockchip_chg_det_reg {
+ struct usb2phy_reg cp_det;
+ struct usb2phy_reg dcp_det;
+ struct usb2phy_reg dp_det;
+ struct usb2phy_reg idm_sink_en;
+ struct usb2phy_reg idp_sink_en;
+ struct usb2phy_reg idp_src_en;
+ struct usb2phy_reg rdm_pdwn_en;
+ struct usb2phy_reg vdm_src_en;
+ struct usb2phy_reg vdp_src_en;
+ struct usb2phy_reg opmode;
+};
+
+/**
* struct rockchip_usb2phy_port_cfg: usb-phy port configuration.
* @phy_sus: phy suspend register.
+ * @bvalid_det_en: vbus valid rise detection enable register.
+ * @bvalid_det_st: vbus valid rise detection status register.
+ * @bvalid_det_clr: vbus valid rise detection clear register.
* @ls_det_en: linestate detection enable register.
* @ls_det_st: linestate detection state register.
* @ls_det_clr: linestate detection clear register.
+ * @utmi_avalid: utmi vbus avalid status register.
+ * @utmi_bvalid: utmi vbus bvalid status register.
* @utmi_ls: utmi linestate state register.
* @utmi_hstdet: utmi host disconnect register.
*/
struct rockchip_usb2phy_port_cfg {
struct usb2phy_reg phy_sus;
+ struct usb2phy_reg bvalid_det_en;
+ struct usb2phy_reg bvalid_det_st;
+ struct usb2phy_reg bvalid_det_clr;
struct usb2phy_reg ls_det_en;
struct usb2phy_reg ls_det_st;
struct usb2phy_reg ls_det_clr;
+ struct usb2phy_reg utmi_avalid;
+ struct usb2phy_reg utmi_bvalid;
struct usb2phy_reg utmi_ls;
struct usb2phy_reg utmi_hstdet;
};
@@ -80,31 +152,51 @@ struct rockchip_usb2phy_port_cfg {
* @reg: the address offset of grf for usb-phy config.
* @num_ports: specify how many ports that the phy has.
* @clkout_ctl: keep on/turn off output clk of phy.
+ * @chg_det: charger detection registers.
*/
struct rockchip_usb2phy_cfg {
unsigned int reg;
unsigned int num_ports;
struct usb2phy_reg clkout_ctl;
const struct rockchip_usb2phy_port_cfg port_cfgs[USB2PHY_NUM_PORTS];
+ const struct rockchip_chg_det_reg chg_det;
};
/**
* struct rockchip_usb2phy_port: usb-phy port data.
* @port_id: flag for otg port or host port.
* @suspended: phy suspended flag.
+ * @utmi_avalid: utmi avalid status usage flag.
+ * true - use avalid to get vbus status
+ * flase - use bvalid to get vbus status
+ * @vbus_attached: otg device vbus status.
+ * @bvalid_irq: IRQ number assigned for vbus valid rise detection.
* @ls_irq: IRQ number assigned for linestate detection.
* @mutex: for register updating in sm_work.
- * @sm_work: OTG state machine work.
+ * @chg_work: charge detect work.
+ * @otg_sm_work: OTG state machine work.
+ * @sm_work: HOST state machine work.
* @phy_cfg: port register configuration, assigned by driver data.
+ * @event_nb: hold event notification callback.
+ * @state: define OTG enumeration states before device reset.
+ * @mode: the dr_mode of the controller.
*/
struct rockchip_usb2phy_port {
struct phy *phy;
unsigned int port_id;
bool suspended;
+ bool utmi_avalid;
+ bool vbus_attached;
+ int bvalid_irq;
int ls_irq;
struct mutex mutex;
+ struct delayed_work chg_work;
+ struct delayed_work otg_sm_work;
struct delayed_work sm_work;
const struct rockchip_usb2phy_port_cfg *port_cfg;
+ struct notifier_block event_nb;
+ enum usb_otg_state state;
+ enum usb_dr_mode mode;
};
/**
@@ -113,6 +205,11 @@ struct rockchip_usb2phy_port {
* @clk: clock struct of phy input clk.
* @clk480m: clock struct of phy output clk.
* @clk_hw: clock struct of phy output clk management.
+ * @chg_state: states involved in USB charger detection.
+ * @chg_type: USB charger types.
+ * @dcd_retries: The retry count used to track Data contact
+ * detection process.
+ * @edev: extcon device for notification registration
* @phy_cfg: phy register configuration, assigned by driver data.
* @ports: phy port instance.
*/
@@ -122,6 +219,10 @@ struct rockchip_usb2phy {
struct clk *clk;
struct clk *clk480m;
struct clk_hw clk480m_hw;
+ enum usb_chg_state chg_state;
+ enum power_supply_type chg_type;
+ u8 dcd_retries;
+ struct extcon_dev *edev;
const struct rockchip_usb2phy_cfg *phy_cfg;
struct rockchip_usb2phy_port ports[USB2PHY_NUM_PORTS];
};
@@ -263,33 +364,84 @@ rockchip_usb2phy_clk480m_register(struct rockchip_usb2phy *rphy)
return ret;
}
-static int rockchip_usb2phy_init(struct phy *phy)
+static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
{
- struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
- struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent);
int ret;
+ struct device_node *node = rphy->dev->of_node;
+ struct extcon_dev *edev;
+
+ if (of_property_read_bool(node, "extcon")) {
+ edev = extcon_get_edev_by_phandle(rphy->dev, 0);
+ if (IS_ERR(edev)) {
+ if (PTR_ERR(edev) != -EPROBE_DEFER)
+ dev_err(rphy->dev, "Invalid or missing extcon\n");
+ return PTR_ERR(edev);
+ }
+ } else {
+ /* Initialize extcon device */
+ edev = devm_extcon_dev_allocate(rphy->dev,
+ rockchip_usb2phy_extcon_cable);
- if (rport->port_id == USB2PHY_PORT_HOST) {
- /* clear linestate and enable linestate detect irq */
- mutex_lock(&rport->mutex);
+ if (IS_ERR(edev))
+ return -ENOMEM;
- ret = property_enable(rphy, &rport->port_cfg->ls_det_clr, true);
+ ret = devm_extcon_dev_register(rphy->dev, edev);
if (ret) {
- mutex_unlock(&rport->mutex);
+ dev_err(rphy->dev, "failed to register extcon device\n");
return ret;
}
+ }
- ret = property_enable(rphy, &rport->port_cfg->ls_det_en, true);
- if (ret) {
- mutex_unlock(&rport->mutex);
- return ret;
+ rphy->edev = edev;
+
+ return 0;
+}
+
+static int rockchip_usb2phy_init(struct phy *phy)
+{
+ struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
+ struct rockchip_usb2phy *rphy = dev_get_drvdata(phy->dev.parent);
+ int ret = 0;
+
+ mutex_lock(&rport->mutex);
+
+ if (rport->port_id == USB2PHY_PORT_OTG) {
+ if (rport->mode != USB_DR_MODE_HOST) {
+ /* clear bvalid status and enable bvalid detect irq */
+ ret = property_enable(rphy,
+ &rport->port_cfg->bvalid_det_clr,
+ true);
+ if (ret)
+ goto out;
+
+ ret = property_enable(rphy,
+ &rport->port_cfg->bvalid_det_en,
+ true);
+ if (ret)
+ goto out;
+
+ schedule_delayed_work(&rport->otg_sm_work,
+ OTG_SCHEDULE_DELAY);
+ } else {
+ /* If OTG works in host only mode, do nothing. */
+ dev_dbg(&rport->phy->dev, "mode %d\n", rport->mode);
}
+ } else if (rport->port_id == USB2PHY_PORT_HOST) {
+ /* clear linestate and enable linestate detect irq */
+ ret = property_enable(rphy, &rport->port_cfg->ls_det_clr, true);
+ if (ret)
+ goto out;
+
+ ret = property_enable(rphy, &rport->port_cfg->ls_det_en, true);
+ if (ret)
+ goto out;
- mutex_unlock(&rport->mutex);
schedule_delayed_work(&rport->sm_work, SCHEDULE_DELAY);
}
- return 0;
+out:
+ mutex_unlock(&rport->mutex);
+ return ret;
}
static int rockchip_usb2phy_power_on(struct phy *phy)
@@ -340,7 +492,11 @@ static int rockchip_usb2phy_exit(struct phy *phy)
{
struct rockchip_usb2phy_port *rport = phy_get_drvdata(phy);
- if (rport->port_id == USB2PHY_PORT_HOST)
+ if (rport->port_id == USB2PHY_PORT_OTG &&
+ rport->mode != USB_DR_MODE_HOST) {
+ cancel_delayed_work_sync(&rport->otg_sm_work);
+ cancel_delayed_work_sync(&rport->chg_work);
+ } else if (rport->port_id == USB2PHY_PORT_HOST)
cancel_delayed_work_sync(&rport->sm_work);
return 0;
@@ -354,6 +510,249 @@ static const struct phy_ops rockchip_usb2phy_ops = {
.owner = THIS_MODULE,
};
+static void rockchip_usb2phy_otg_sm_work(struct work_struct *work)
+{
+ struct rockchip_usb2phy_port *rport =
+ container_of(work, struct rockchip_usb2phy_port,
+ otg_sm_work.work);
+ struct rockchip_usb2phy *rphy = dev_get_drvdata(rport->phy->dev.parent);
+ static unsigned int cable;
+ unsigned long delay;
+ bool vbus_attach, sch_work, notify_charger;
+
+ if (rport->utmi_avalid)
+ vbus_attach =
+ property_enabled(rphy, &rport->port_cfg->utmi_avalid);
+ else
+ vbus_attach =
+ property_enabled(rphy, &rport->port_cfg->utmi_bvalid);
+
+ sch_work = false;
+ notify_charger = false;
+ delay = OTG_SCHEDULE_DELAY;
+ dev_dbg(&rport->phy->dev, "%s otg sm work\n",
+ usb_otg_state_string(rport->state));
+
+ switch (rport->state) {
+ case OTG_STATE_UNDEFINED:
+ rport->state = OTG_STATE_B_IDLE;
+ if (!vbus_attach)
+ rockchip_usb2phy_power_off(rport->phy);
+ /* fall through */
+ case OTG_STATE_B_IDLE:
+ if (extcon_get_cable_state_(rphy->edev, EXTCON_USB_HOST) > 0) {
+ dev_dbg(&rport->phy->dev, "usb otg host connect\n");
+ rport->state = OTG_STATE_A_HOST;
+ rockchip_usb2phy_power_on(rport->phy);
+ return;
+ } else if (vbus_attach) {
+ dev_dbg(&rport->phy->dev, "vbus_attach\n");
+ switch (rphy->chg_state) {
+ case USB_CHG_STATE_UNDEFINED:
+ schedule_delayed_work(&rport->chg_work, 0);
+ return;
+ case USB_CHG_STATE_DETECTED:
+ switch (rphy->chg_type) {
+ case POWER_SUPPLY_TYPE_USB:
+ dev_dbg(&rport->phy->dev,
+ "sdp cable is connecetd\n");
+ rockchip_usb2phy_power_on(rport->phy);
+ rport->state = OTG_STATE_B_PERIPHERAL;
+ notify_charger = true;
+ sch_work = true;
+ cable = EXTCON_CHG_USB_SDP;
+ break;
+ case POWER_SUPPLY_TYPE_USB_DCP:
+ dev_dbg(&rport->phy->dev,
+ "dcp cable is connecetd\n");
+ rockchip_usb2phy_power_off(rport->phy);
+ notify_charger = true;
+ sch_work = true;
+ cable = EXTCON_CHG_USB_DCP;
+ break;
+ case POWER_SUPPLY_TYPE_USB_CDP:
+ dev_dbg(&rport->phy->dev,
+ "cdp cable is connecetd\n");
+ rockchip_usb2phy_power_on(rport->phy);
+ rport->state = OTG_STATE_B_PERIPHERAL;
+ notify_charger = true;
+ sch_work = true;
+ cable = EXTCON_CHG_USB_CDP;
+ break;
+ default:
+ break;
+ }
+ break;
+ default:
+ break;
+ }
+ } else {
+ notify_charger = true;
+ rphy->chg_state = USB_CHG_STATE_UNDEFINED;
+ rphy->chg_type = POWER_SUPPLY_TYPE_UNKNOWN;
+ }
+
+ if (rport->vbus_attached != vbus_attach) {
+ rport->vbus_attached = vbus_attach;
+
+ if (notify_charger && rphy->edev)
+ extcon_set_cable_state_(rphy->edev,
+ cable, vbus_attach);
+ }
+ break;
+ case OTG_STATE_B_PERIPHERAL:
+ if (!vbus_attach) {
+ dev_dbg(&rport->phy->dev, "usb disconnect\n");
+ rphy->chg_state = USB_CHG_STATE_UNDEFINED;
+ rphy->chg_type = POWER_SUPPLY_TYPE_UNKNOWN;
+ rport->state = OTG_STATE_B_IDLE;
+ delay = 0;
+ rockchip_usb2phy_power_off(rport->phy);
+ }
+ sch_work = true;
+ break;
+ case OTG_STATE_A_HOST:
+ if (extcon_get_cable_state_(rphy->edev, EXTCON_USB_HOST) == 0) {
+ dev_dbg(&rport->phy->dev, "usb otg host disconnect\n");
+ rport->state = OTG_STATE_B_IDLE;
+ rockchip_usb2phy_power_off(rport->phy);
+ }
+ break;
+ default:
+ break;
+ }
+
+ if (sch_work)
+ schedule_delayed_work(&rport->otg_sm_work, delay);
+}
+
+static const char *chg_to_string(enum power_supply_type chg_type)
+{
+ switch (chg_type) {
+ case POWER_SUPPLY_TYPE_USB:
+ return "USB_SDP_CHARGER";
+ case POWER_SUPPLY_TYPE_USB_DCP:
+ return "USB_DCP_CHARGER";
+ case POWER_SUPPLY_TYPE_USB_CDP:
+ return "USB_CDP_CHARGER";
+ default:
+ return "INVALID_CHARGER";
+ }
+}
+
+static void rockchip_chg_enable_dcd(struct rockchip_usb2phy *rphy,
+ bool en)
+{
+ property_enable(rphy, &rphy->phy_cfg->chg_det.rdm_pdwn_en, en);
+ property_enable(rphy, &rphy->phy_cfg->chg_det.idp_src_en, en);
+}
+
+static void rockchip_chg_enable_primary_det(struct rockchip_usb2phy *rphy,
+ bool en)
+{
+ property_enable(rphy, &rphy->phy_cfg->chg_det.vdp_src_en, en);
+ property_enable(rphy, &rphy->phy_cfg->chg_det.idm_sink_en, en);
+}
+
+static void rockchip_chg_enable_secondary_det(struct rockchip_usb2phy *rphy,
+ bool en)
+{
+ property_enable(rphy, &rphy->phy_cfg->chg_det.vdm_src_en, en);
+ property_enable(rphy, &rphy->phy_cfg->chg_det.idp_sink_en, en);
+}
+
+#define CHG_DCD_POLL_TIME (100 * HZ / 1000)
+#define CHG_DCD_MAX_RETRIES 6
+#define CHG_PRIMARY_DET_TIME (40 * HZ / 1000)
+#define CHG_SECONDARY_DET_TIME (40 * HZ / 1000)
+static void rockchip_chg_detect_work(struct work_struct *work)
+{
+ struct rockchip_usb2phy_port *rport =
+ container_of(work, struct rockchip_usb2phy_port, chg_work.work);
+ struct rockchip_usb2phy *rphy = dev_get_drvdata(rport->phy->dev.parent);
+ bool is_dcd, tmout, vout;
+ unsigned long delay;
+
+ dev_dbg(&rport->phy->dev, "chg detection work state = %d\n",
+ rphy->chg_state);
+ switch (rphy->chg_state) {
+ case USB_CHG_STATE_UNDEFINED:
+ if (!rport->suspended)
+ rockchip_usb2phy_power_off(rport->phy);
+ /* put the controller in non-driving mode */
+ property_enable(rphy, &rphy->phy_cfg->chg_det.opmode, false);
+ /* Start DCD processing stage 1 */
+ rockchip_chg_enable_dcd(rphy, true);
+ rphy->chg_state = USB_CHG_STATE_WAIT_FOR_DCD;
+ rphy->dcd_retries = 0;
+ delay = CHG_DCD_POLL_TIME;
+ break;
+ case USB_CHG_STATE_WAIT_FOR_DCD:
+ /* get data contact detection status */
+ is_dcd = property_enabled(rphy, &rphy->phy_cfg->chg_det.dp_det);
+ tmout = ++rphy->dcd_retries == CHG_DCD_MAX_RETRIES;
+ /* stage 2 */
+ if (is_dcd || tmout) {
+ /* stage 4 */
+ /* Turn off DCD circuitry */
+ rockchip_chg_enable_dcd(rphy, false);
+ /* Voltage Source on DP, Probe on DM */
+ rockchip_chg_enable_primary_det(rphy, true);
+ delay = CHG_PRIMARY_DET_TIME;
+ rphy->chg_state = USB_CHG_STATE_DCD_DONE;
+ } else {
+ /* stage 3 */
+ delay = CHG_DCD_POLL_TIME;
+ }
+ break;
+ case USB_CHG_STATE_DCD_DONE:
+ vout = property_enabled(rphy, &rphy->phy_cfg->chg_det.cp_det);
+ rockchip_chg_enable_primary_det(rphy, false);
+ if (vout) {
+ /* Voltage Source on DM, Probe on DP */
+ rockchip_chg_enable_secondary_det(rphy, true);
+ delay = CHG_SECONDARY_DET_TIME;
+ rphy->chg_state = USB_CHG_STATE_PRIMARY_DONE;
+ } else {
+ if (tmout) {
+ /* floating charger found */
+ rphy->chg_type = POWER_SUPPLY_TYPE_USB_DCP;
+ rphy->chg_state = USB_CHG_STATE_DETECTED;
+ delay = 0;
+ } else {
+ rphy->chg_type = POWER_SUPPLY_TYPE_USB;
+ rphy->chg_state = USB_CHG_STATE_DETECTED;
+ delay = 0;
+ }
+ }
+ break;
+ case USB_CHG_STATE_PRIMARY_DONE:
+ vout = property_enabled(rphy, &rphy->phy_cfg->chg_det.dcp_det);
+ /* Turn off voltage source */
+ rockchip_chg_enable_secondary_det(rphy, false);
+ if (vout)
+ rphy->chg_type = POWER_SUPPLY_TYPE_USB_DCP;
+ else
+ rphy->chg_type = POWER_SUPPLY_TYPE_USB_CDP;
+ /* fall through */
+ case USB_CHG_STATE_SECONDARY_DONE:
+ rphy->chg_state = USB_CHG_STATE_DETECTED;
+ delay = 0;
+ /* fall through */
+ case USB_CHG_STATE_DETECTED:
+ /* put the controller in normal mode */
+ property_enable(rphy, &rphy->phy_cfg->chg_det.opmode, true);
+ rockchip_usb2phy_otg_sm_work(&rport->otg_sm_work.work);
+ dev_info(&rport->phy->dev, "charger = %s\n",
+ chg_to_string(rphy->chg_type));
+ return;
+ default:
+ return;
+ }
+
+ schedule_delayed_work(&rport->chg_work, delay);
+}
+
/*
* The function manage host-phy port state and suspend/resume phy port
* to save power.
@@ -485,6 +884,26 @@ static irqreturn_t rockchip_usb2phy_linestate_irq(int irq, void *data)
return IRQ_HANDLED;
}
+static irqreturn_t rockchip_usb2phy_bvalid_irq(int irq, void *data)
+{
+ struct rockchip_usb2phy_port *rport = data;
+ struct rockchip_usb2phy *rphy = dev_get_drvdata(rport->phy->dev.parent);
+
+ if (!property_enabled(rphy, &rport->port_cfg->bvalid_det_st))
+ return IRQ_NONE;
+
+ mutex_lock(&rport->mutex);
+
+ /* clear bvalid detect irq pending status */
+ property_enable(rphy, &rport->port_cfg->bvalid_det_clr, true);
+
+ mutex_unlock(&rport->mutex);
+
+ rockchip_usb2phy_otg_sm_work(&rport->otg_sm_work.work);
+
+ return IRQ_HANDLED;
+}
+
static int rockchip_usb2phy_host_port_init(struct rockchip_usb2phy *rphy,
struct rockchip_usb2phy_port *rport,
struct device_node *child_np)
@@ -509,13 +928,86 @@ static int rockchip_usb2phy_host_port_init(struct rockchip_usb2phy *rphy,
IRQF_ONESHOT,
"rockchip_usb2phy", rport);
if (ret) {
- dev_err(rphy->dev, "failed to request irq handle\n");
+ dev_err(rphy->dev, "failed to request linestate irq handle\n");
return ret;
}
return 0;
}
+static int rockchip_otg_event(struct notifier_block *nb,
+ unsigned long event, void *ptr)
+{
+ struct rockchip_usb2phy_port *rport =
+ container_of(nb, struct rockchip_usb2phy_port, event_nb);
+
+ schedule_delayed_work(&rport->otg_sm_work, OTG_SCHEDULE_DELAY);
+
+ return NOTIFY_DONE;
+}
+
+static int rockchip_usb2phy_otg_port_init(struct rockchip_usb2phy *rphy,
+ struct rockchip_usb2phy_port *rport,
+ struct device_node *child_np)
+{
+ int ret;
+
+ rport->port_id = USB2PHY_PORT_OTG;
+ rport->port_cfg = &rphy->phy_cfg->port_cfgs[USB2PHY_PORT_OTG];
+ rport->state = OTG_STATE_UNDEFINED;
+
+ /*
+ * set suspended flag to true, but actually don't
+ * put phy in suspend mode, it aims to enable usb
+ * phy and clock in power_on() called by usb controller
+ * driver during probe.
+ */
+ rport->suspended = true;
+ rport->vbus_attached = false;
+
+ mutex_init(&rport->mutex);
+
+ rport->mode = of_usb_get_dr_mode_by_phy(child_np, -1);
+ if (rport->mode == USB_DR_MODE_HOST) {
+ ret = 0;
+ goto out;
+ }
+
+ INIT_DELAYED_WORK(&rport->chg_work, rockchip_chg_detect_work);
+ INIT_DELAYED_WORK(&rport->otg_sm_work, rockchip_usb2phy_otg_sm_work);
+
+ rport->utmi_avalid =
+ of_property_read_bool(child_np, "rockchip,utmi-avalid");
+
+ rport->bvalid_irq = of_irq_get_byname(child_np, "otg-bvalid");
+ if (rport->bvalid_irq < 0) {
+ dev_err(rphy->dev, "no vbus valid irq provided\n");
+ ret = rport->bvalid_irq;
+ goto out;
+ }
+
+ ret = devm_request_threaded_irq(rphy->dev, rport->bvalid_irq, NULL,
+ rockchip_usb2phy_bvalid_irq,
+ IRQF_ONESHOT,
+ "rockchip_usb2phy_bvalid", rport);
+ if (ret) {
+ dev_err(rphy->dev, "failed to request otg-bvalid irq handle\n");
+ goto out;
+ }
+
+ if (!IS_ERR(rphy->edev)) {
+ rport->event_nb.notifier_call = rockchip_otg_event;
+
+ ret = extcon_register_notifier(rphy->edev, EXTCON_USB_HOST,
+ &rport->event_nb);
+ if (ret)
+ dev_err(rphy->dev, "register USB HOST notifier failed\n");
+ }
+
+out:
+ return ret;
+}
+
static int rockchip_usb2phy_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -553,8 +1045,14 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
rphy->dev = dev;
phy_cfgs = match->data;
+ rphy->chg_state = USB_CHG_STATE_UNDEFINED;
+ rphy->chg_type = POWER_SUPPLY_TYPE_UNKNOWN;
platform_set_drvdata(pdev, rphy);
+ ret = rockchip_usb2phy_extcon_register(rphy);
+ if (ret)
+ return ret;
+
/* find out a proper config which can be matched with dt. */
index = 0;
while (phy_cfgs[index].reg) {
@@ -591,13 +1089,9 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
struct rockchip_usb2phy_port *rport = &rphy->ports[index];
struct phy *phy;
- /*
- * This driver aim to support both otg-port and host-port,
- * but unfortunately, the otg part is not ready in current,
- * so this comments and below codes are interim, which should
- * be changed after otg-port is supplied soon.
- */
- if (of_node_cmp(child_np->name, "host-port"))
+ /* This driver aims to support both otg-port and host-port */
+ if (of_node_cmp(child_np->name, "host-port") &&
+ of_node_cmp(child_np->name, "otg-port"))
goto next_child;
phy = devm_phy_create(dev, child_np, &rockchip_usb2phy_ops);
@@ -610,9 +1104,18 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
rport->phy = phy;
phy_set_drvdata(rport->phy, rport);
- ret = rockchip_usb2phy_host_port_init(rphy, rport, child_np);
- if (ret)
- goto put_child;
+ /* initialize otg/host port separately */
+ if (!of_node_cmp(child_np->name, "host-port")) {
+ ret = rockchip_usb2phy_host_port_init(rphy, rport,
+ child_np);
+ if (ret)
+ goto put_child;
+ } else {
+ ret = rockchip_usb2phy_otg_port_init(rphy, rport,
+ child_np);
+ if (ret)
+ goto put_child;
+ }
next_child:
/* to prevent out of boundary */
@@ -654,10 +1157,18 @@ static const struct rockchip_usb2phy_cfg rk3366_phy_cfgs[] = {
static const struct rockchip_usb2phy_cfg rk3399_phy_cfgs[] = {
{
- .reg = 0xe450,
+ .reg = 0xe450,
.num_ports = 2,
.clkout_ctl = { 0xe450, 4, 4, 1, 0 },
.port_cfgs = {
+ [USB2PHY_PORT_OTG] = {
+ .phy_sus = { 0xe454, 1, 0, 2, 1 },
+ .bvalid_det_en = { 0xe3c0, 3, 3, 0, 1 },
+ .bvalid_det_st = { 0xe3e0, 3, 3, 0, 1 },
+ .bvalid_det_clr = { 0xe3d0, 3, 3, 0, 1 },
+ .utmi_avalid = { 0xe2ac, 7, 7, 0, 1 },
+ .utmi_bvalid = { 0xe2ac, 12, 12, 0, 1 },
+ },
[USB2PHY_PORT_HOST] = {
.phy_sus = { 0xe458, 1, 0, 0x2, 0x1 },
.ls_det_en = { 0xe3c0, 6, 6, 0, 1 },
@@ -667,12 +1178,32 @@ static const struct rockchip_usb2phy_cfg rk3399_phy_cfgs[] = {
.utmi_hstdet = { 0xe2ac, 23, 23, 0, 1 }
}
},
+ .chg_det = {
+ .opmode = { 0xe454, 3, 0, 5, 1 },
+ .cp_det = { 0xe2ac, 2, 2, 0, 1 },
+ .dcp_det = { 0xe2ac, 1, 1, 0, 1 },
+ .dp_det = { 0xe2ac, 0, 0, 0, 1 },
+ .idm_sink_en = { 0xe450, 8, 8, 0, 1 },
+ .idp_sink_en = { 0xe450, 7, 7, 0, 1 },
+ .idp_src_en = { 0xe450, 9, 9, 0, 1 },
+ .rdm_pdwn_en = { 0xe450, 10, 10, 0, 1 },
+ .vdm_src_en = { 0xe450, 12, 12, 0, 1 },
+ .vdp_src_en = { 0xe450, 11, 11, 0, 1 },
+ },
},
{
- .reg = 0xe460,
+ .reg = 0xe460,
.num_ports = 2,
.clkout_ctl = { 0xe460, 4, 4, 1, 0 },
.port_cfgs = {
+ [USB2PHY_PORT_OTG] = {
+ .phy_sus = { 0xe464, 1, 0, 2, 1 },
+ .bvalid_det_en = { 0xe3c0, 8, 8, 0, 1 },
+ .bvalid_det_st = { 0xe3e0, 8, 8, 0, 1 },
+ .bvalid_det_clr = { 0xe3d0, 8, 8, 0, 1 },
+ .utmi_avalid = { 0xe2ac, 10, 10, 0, 1 },
+ .utmi_bvalid = { 0xe2ac, 16, 16, 0, 1 },
+ },
[USB2PHY_PORT_HOST] = {
.phy_sus = { 0xe468, 1, 0, 0x2, 0x1 },
.ls_det_en = { 0xe3c0, 11, 11, 0, 1 },
--
2.0.0
^ permalink raw reply related
* [PATCH v3 2/2] arm64: dts: rockchip: add usb2-phy otg-port support for rk3399
From: William Wu @ 2016-11-07 12:08 UTC (permalink / raw)
To: kishon-l0cyMroinI0, heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frank.wang-TNX95d0MmH7DzftRWevZcw,
huangtao-TNX95d0MmH7DzftRWevZcw, dianders-hpIqsD4AKlfQT0dZR+AlfA,
briannorris-hpIqsD4AKlfQT0dZR+AlfA, groeck-hpIqsD4AKlfQT0dZR+AlfA,
wulf-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <1478520529-8869-1-git-send-email-wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Add otg-port nodes for both u2phy0 and u2phy1. The otg-port can
be used for USB2.0 part of USB3.0 OTG controller.
Signed-off-by: William Wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Changes in v3:
- None
Changes in v2:
- None
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index b65c193..ea2df51 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1095,6 +1095,17 @@
clock-output-names = "clk_usbphy0_480m";
status = "disabled";
+ u2phy0_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "otg-bvalid", "otg-id",
+ "linestate";
+ status = "disabled";
+ };
+
+
u2phy0_host: host-port {
#phy-cells = <0>;
interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
@@ -1112,6 +1123,16 @@
clock-output-names = "clk_usbphy1_480m";
status = "disabled";
+ u2phy1_otg: otg-port {
+ #phy-cells = <0>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "otg-bvalid", "otg-id",
+ "linestate";
+ status = "disabled";
+ };
+
u2phy1_host: host-port {
#phy-cells = <0>;
interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH 0>;
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 0/2] mmc: sdhci-iproc: Add byte register access support
From: Ulf Hansson @ 2016-11-07 12:14 UTC (permalink / raw)
To: Scott Branden
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Adrian Hunter,
BCM Kernel Feedback, linux-mmc, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1478018277-10097-1-git-send-email-scott.branden@broadcom.com>
On 1 November 2016 at 17:37, Scott Branden <scott.branden@broadcom.com> wrote:
> Add brcm,sdhci-iproc compat string and code for support of newer versions of
> sdhci-iproc controller that allow byte-wise register accesses.
>
> Changes from v1:
> - added details to bindings documentation to clarify usage of brcm,sdhci-iproc
> compatibility string
>
> Scott Branden (2):
> mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings
> document
> mmc: sdhci-iproc: support standard byte register accesses
>
> .../devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 ++++++
> drivers/mmc/host/sdhci-iproc.c | 35 ++++++++++++++++++++--
> 2 files changed, 42 insertions(+), 2 deletions(-)
>
> --
> 2.5.0
>
It seems I had already applied v1 of this series. I have dropped those
now, waiting to receive an ack from Rob first.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v3 1/8] iio:core: add a callback to allow drivers to provide _available attributes
From: Daniel Baluta @ 2016-11-07 12:18 UTC (permalink / raw)
To: Peter Rosin
Cc: Linux Kernel Mailing List, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Rob Herring,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Devicetree List
In-Reply-To: <62f150ba-abc0-8e45-1355-8a61354ee3e1-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On Mon, Nov 7, 2016 at 1:57 PM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
> On 2016-11-07 12:37, Daniel Baluta wrote:
>> On Mon, Oct 24, 2016 at 1:39 AM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>>> From: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>
>>> A large number of attributes can only take a limited range of values.
>>> Currently in IIO this is handled by directly registering additional
>>> *_available attributes thus providing this information to userspace.
>>>
>>> It is desirable to provide this information via the core for much the same
>>> reason this was done for the actual channel information attributes in the
>>> first place. If it isn't there, then it can only really be accessed from
>>> userspace. Other in kernel IIO consumers have no access to what valid
>>> parameters are.
>>>
>>> Two forms are currently supported:
>>> * list of values in one particular IIO_VAL_* format.
>>> e.g. 1.300000 1.500000 1.730000
>>> * range specification with a step size:
>>> e.g. [1.000000 0.500000 2.500000]
>>> equivalent to 1.000000 1.5000000 2.000000 2.500000
>>
>> Is there any driver using this format? :)
>
> Yes, soon. Hopefully. See patch 3/8
> iio: mcp4531: provide range of available raw values
> https://patchwork.kernel.org/patch/9391283/
>
>>>
>>> An addition set of masks are used to allow different sharing rules for the
>>> *_available attributes generated.
>>>
>>> This allows for example:
>>>
>>> in_accel_x_offset
>>> in_accel_y_offset
>>> in_accel_offset_available.
>>>
>>> We could have gone with having a specification for each and every
>>> info_mask element but that would have meant changing the existing userspace
>>> ABI. This approach does not.
>>>
>>> Signed-off-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> [forward ported, added some docs and fixed buffer overflows /peda]
>>> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>>
>> The patch looks good to me at a first glance.
>
> Thanks, may I add your acked-by if/when I respin?
Yes. You can have it from here:
Acked-by: Daniel Baluta <daniel.baluta-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: DTS: r8a7794: alt: Fix PFC names for DU
From: Simon Horman @ 2016-11-07 12:40 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Jacopo Mondi, magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <c0a3c44b-545c-7af3-feed-857cb20ef698-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On Fri, Nov 04, 2016 at 02:43:18PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 11/3/2016 10:34 PM, Jacopo Mondi wrote:
>
> >Update the PFC pin groups and function names of DU interface for
> >r8a7794 ALT board.
> >
> >The currently specified pin groups and function names prevented PFC and
> >DU interfaces from being correctly configured:
> >
> >sh-pfc e6060000.pin-controller: function 'du' not supported
> >sh-pfc e6060000.pin-controller: invalid function du in map table
> >sh-pfc e6060000.pin-controller: function 'du' not supported
> >sh-pfc e6060000.pin-controller: invalid function du in map table
> >sh-pfc e6060000.pin-controller: function 'du' not supported
> >sh-pfc e6060000.pin-controller: invalid function du in map table
> >sh-pfc e6060000.pin-controller: function 'du' not supported
> >sh-pfc e6060000.pin-controller: invalid function du in map table
> >rcar-du: probe of feb00000.display failed with error -22
> >
> >Signed-off-by: Jacopo Mondi <jacopo-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
>
> Acked-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Thanks, I have queued this up.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] media: mtk-mdp: allocate video_device dynamically
From: Minghsiu Tsai @ 2016-11-07 12:42 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak
Cc: srv_heupstream, Eddie Huang, Yingjoe Chen, devicetree,
linux-kernel, linux-arm-kernel, linux-media, linux-mediatek
v4l2-compliance test output:
v4l2-compliance SHA : abc1453dfe89f244dccd3460d8e1a2e3091cbadb
Driver Info:
Driver name : mtk-mdp
Card type : soc:mdp
Bus info : platform:mt8173
Driver version: 4.9.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Compliance test for device /dev/image-proc0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK
test Scaling: OK
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
Test input 0:
Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
Minghsiu Tsai (1):
[media] mtk-mdp: allocate video_device dynamically
drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 2 +-
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 33 ++++++++++++++++-----------
2 files changed, 21 insertions(+), 14 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH] [media] mtk-mdp: allocate video_device dynamically
From: Minghsiu Tsai @ 2016-11-07 12:42 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson-QSEj5FYQhm4dnm+yROfE0A, Rob Herring,
Mauro Carvalho Chehab, Matthias Brugger, Daniel Kurtz,
Pawel Osciak
Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Eddie Huang, Yingjoe Chen,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Minghsiu Tsai
In-Reply-To: <1478522529-57129-1-git-send-email-minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
It can fix known problems with embedded video_device structs.
Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 2 +-
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 33 ++++++++++++++++-----------
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
index 848569d..ad1cff3 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
@@ -167,7 +167,7 @@ struct mtk_mdp_dev {
struct mtk_mdp_comp *comp[MTK_MDP_COMP_ID_MAX];
struct v4l2_m2m_dev *m2m_dev;
struct list_head ctx_list;
- struct video_device vdev;
+ struct video_device *vdev;
struct v4l2_device v4l2_dev;
struct workqueue_struct *job_wq;
struct platform_device *vpu_dev;
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index 9a747e7..b8dee1c 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -1236,16 +1236,22 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
int ret;
mdp->variant = &mtk_mdp_default_variant;
- mdp->vdev.device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
- mdp->vdev.fops = &mtk_mdp_m2m_fops;
- mdp->vdev.ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
- mdp->vdev.release = video_device_release_empty;
- mdp->vdev.lock = &mdp->lock;
- mdp->vdev.vfl_dir = VFL_DIR_M2M;
- mdp->vdev.v4l2_dev = &mdp->v4l2_dev;
- snprintf(mdp->vdev.name, sizeof(mdp->vdev.name), "%s:m2m",
+ mdp->vdev = video_device_alloc();
+ if (!mdp->vdev) {
+ dev_err(dev, "failed to allocate video device\n");
+ ret = -ENOMEM;
+ goto err_video_alloc;
+ }
+ mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
+ mdp->vdev->fops = &mtk_mdp_m2m_fops;
+ mdp->vdev->ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
+ mdp->vdev->release = video_device_release;
+ mdp->vdev->lock = &mdp->lock;
+ mdp->vdev->vfl_dir = VFL_DIR_M2M;
+ mdp->vdev->v4l2_dev = &mdp->v4l2_dev;
+ snprintf(mdp->vdev->name, sizeof(mdp->vdev->name), "%s:m2m",
MTK_MDP_MODULE_NAME);
- video_set_drvdata(&mdp->vdev, mdp);
+ video_set_drvdata(mdp->vdev, mdp);
mdp->m2m_dev = v4l2_m2m_init(&mtk_mdp_m2m_ops);
if (IS_ERR(mdp->m2m_dev)) {
@@ -1254,26 +1260,27 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
goto err_m2m_init;
}
- ret = video_register_device(&mdp->vdev, VFL_TYPE_GRABBER, 2);
+ ret = video_register_device(mdp->vdev, VFL_TYPE_GRABBER, 2);
if (ret) {
dev_err(dev, "failed to register video device\n");
goto err_vdev_register;
}
v4l2_info(&mdp->v4l2_dev, "driver registered as /dev/video%d",
- mdp->vdev.num);
+ mdp->vdev->num);
return 0;
err_vdev_register:
v4l2_m2m_release(mdp->m2m_dev);
err_m2m_init:
- video_device_release(&mdp->vdev);
+ video_unregister_device(mdp->vdev);
+err_video_alloc:
return ret;
}
void mtk_mdp_unregister_m2m_device(struct mtk_mdp_dev *mdp)
{
- video_device_release(&mdp->vdev);
+ video_unregister_device(mdp->vdev);
v4l2_m2m_release(mdp->m2m_dev);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 0/2] mmc: sdhci: Fix sdhci caps register bits with corrections provided by dt
From: Ulf Hansson @ 2016-11-07 12:42 UTC (permalink / raw)
To: Zach Brown
Cc: Adrian Hunter, Rob Herring, Mark Rutland, linux-mmc,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1478100376-602-1-git-send-email-zach.brown@ni.com>
On 2 November 2016 at 16:26, Zach Brown <zach.brown@ni.com> wrote:
> For various reasons the sdhci caps register can be incorrect. This patch set
> introduces a general way to correct the bits when they are read to accurately
> reflect the capabilties of the controller/board combo.
>
> The first patch creates sdhci-caps and sdhci-caps-mask dt properties that
> combined represent the correction to the sdhci caps register.
>
> The second patch uses the new dt properties to correct the caps from the
> register as they read during __sdhci_read_caps.
>
> Changes from RFC:
> * /s/registers/register
> * Moved sdhci dt properties into new documentation file sdhci.txt
> v2:
> * Fixed style issue, all branches of 'if' should have {}
>
>
> Zach Brown (2):
> mmc: sdhci: dt: Add device tree properties sdhci-caps and
> sdhci-caps-mask
> mmc: sdhci: Use sdhci-caps-mask and sdhci-caps to change the caps read
> during __sdhci_read_caps
>
> Documentation/devicetree/bindings/mmc/sdhci.txt | 14 ++++++++++++++
> drivers/mmc/host/sdhci.c | 24 ++++++++++++++++++++++--
> 2 files changed, 36 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci.txt
>
> --
> 2.7.4
>
Thanks, applied for next!
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] ARM: tegra: nyan: Enable GPU node and related supply
From: Alexandre Courbot @ 2016-11-07 12:51 UTC (permalink / raw)
To: Jon Hunter
Cc: Paul Kocialkowski, Linux Kernel Mailing List, Thierry Reding,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Warren
In-Reply-To: <e95335ae-ad19-b8cd-634b-63c6a0b88e01-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Wed, Sep 21, 2016 at 4:57 PM, Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>
> On 20/09/16 19:17, Paul Kocialkowski wrote:
>> * PGP Signed by an unknown key
>>
>> Le mardi 20 septembre 2016 à 13:24 +0100, Jon Hunter a écrit :
>>> On 18/09/16 15:13, Paul Kocialkowski wrote:
>>>>
>>>> This enables the GPU node for tegra124 nyan boards, which is required to
>>>> get graphics acceleration with nouveau on these devices.
>>>>
>>>> Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
>>>> ---
>>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 8 +++++++-
>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi
>>>> b/arch/arm/boot/dts/tegra124-nyan.dtsi
>>>> index dab9509..225ca77 100644
>>>> --- a/arch/arm/boot/dts/tegra124-nyan.dtsi
>>>> +++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
>>>> @@ -42,6 +42,12 @@
>>>> };
>>>> };
>>>>
>>>> + gpu@0,57000000 {
>>>> + status = "okay";
>>>> +
>>>> + vdd-supply = <&vdd_gpu>;
>>>> + };
>>>> +
>>>> serial@70006000 {
>>>> /* Debug connector on the bottom of the board near SD card.
>>>> */
>>>> status = "okay";
>>>> @@ -214,7 +220,7 @@
>>>> regulator-always-on;
>>>> };
>>>>
>>>> - sd6 {
>>>> + vdd_gpu: sd6 {
>>>> regulator-name = "+VDD_GPU_AP";
>>>> regulator-min-microvolt = <650000>;
>>>> regulator-max-microvolt =
>>>> <1200000>;
>>>>
>>>
>>> Looks good to me. I see the following error when booting but looking at the
>>> code appears to be benign. Thierry, Alex, is this normal/okay?
>>
>> I have the same messages and asked Alexandre about them the other day. He told
>> me that it looks normal.
>
> Ok great. Hopefully, Alex can ACK then.
Apologies for the (very) delayed reply.
Yes, the messages you are seeing are part of the normal probe sequence
on Tegra. So this looks good to me.
Acked-by: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4 4/6] ARM: tegra: Add Tegra30 GMI support
From: Thierry Reding @ 2016-11-07 12:56 UTC (permalink / raw)
To: Mirza Krak
Cc: swarren-3lzwWm7+Weoh9ZMKESR00Q, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA,
pgaikwad-DDmLM1+adcrQT0dZR+AlfA,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478507405-13204-5-git-send-email-mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
On Mon, Nov 07, 2016 at 09:30:03AM +0100, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Add a device node for the GMI controller found on Tegra30.
>
> Signed-off-by: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Marcel Ziswiler <marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
> Acked-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>
> Changes in v2:
> - added address-cells, size-cells and ranges properties
>
> Changes in v3:
> - no changes
>
> Changes in v4:
> - no changes
>
> arch/arm/boot/dts/tegra30.dtsi | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH V4 5/6] ARM: tegra: Add Tegra20 GMI support
From: Thierry Reding @ 2016-11-07 12:56 UTC (permalink / raw)
To: Mirza Krak
Cc: swarren-3lzwWm7+Weoh9ZMKESR00Q, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA,
pgaikwad-DDmLM1+adcrQT0dZR+AlfA,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478507405-13204-6-git-send-email-mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
On Mon, Nov 07, 2016 at 09:30:04AM +0100, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Add a device node for the GMI controller found on Tegra20.
>
> Signed-off-by: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Marcel Ziswiler <marcel.ziswiler-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
> Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
> Acked-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>
> Changes in v2:
> - added address-cells, size-cells and ranges properties
>
> Changes in v3:
> - fixed range address which is not the same as Tegra30.
>
> Changes in v4:
> - removed extra newline and a initial space in resets property.
>
> arch/arm/boot/dts/tegra20.dtsi | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 4/9] arm64: dts: m3ulcb: enable GPIO leds
From: Simon Horman @ 2016-11-07 12:57 UTC (permalink / raw)
To: Vladimir Barinov
Cc: Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478196451-1298-1-git-send-email-vladimir.barinov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On Thu, Nov 03, 2016 at 09:07:31PM +0300, Vladimir Barinov wrote:
> This supports GPIO leds on M3ULCB board
Are GPIO leds and keys also present on the H3ULCB.
If so could you consider sending patches to enable them?
> Signed-off-by: Vladimir Barinov <vladimir.barinov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
> ---
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> index fb694b8..3329f78 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> @@ -31,6 +31,17 @@
> /* first 128MB is reserved for secure area. */
> reg = <0x0 0x48000000 0x0 0x38000000>;
> };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led5 {
> + gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
> + };
> + led6 {
> + gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
> + };
> + };
> };
>
> &extal_clk {
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: tegra: nyan: Enable GPU node and related supply
From: Jon Hunter @ 2016-11-07 13:00 UTC (permalink / raw)
To: Alexandre Courbot, Thierry Reding
Cc: Paul Kocialkowski, Linux Kernel Mailing List,
linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Stephen Warren
In-Reply-To: <CAAVeFuLb5gU70B0jP0YNPB58NcuR_D0e--6zn3dG7VOmZafLRA@mail.gmail.com>
Thierry,
On 07/11/16 12:51, Alexandre Courbot wrote:
> On Wed, Sep 21, 2016 at 4:57 PM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>> On 20/09/16 19:17, Paul Kocialkowski wrote:
>>> * PGP Signed by an unknown key
>>>
>>> Le mardi 20 septembre 2016 à 13:24 +0100, Jon Hunter a écrit :
>>>> On 18/09/16 15:13, Paul Kocialkowski wrote:
>>>>>
>>>>> This enables the GPU node for tegra124 nyan boards, which is required to
>>>>> get graphics acceleration with nouveau on these devices.
>>>>>
>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>>>> ---
>>>>> arch/arm/boot/dts/tegra124-nyan.dtsi | 8 +++++++-
>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi
>>>>> b/arch/arm/boot/dts/tegra124-nyan.dtsi
>>>>> index dab9509..225ca77 100644
>>>>> --- a/arch/arm/boot/dts/tegra124-nyan.dtsi
>>>>> +++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
>>>>> @@ -42,6 +42,12 @@
>>>>> };
>>>>> };
>>>>>
>>>>> + gpu@0,57000000 {
>>>>> + status = "okay";
>>>>> +
>>>>> + vdd-supply = <&vdd_gpu>;
>>>>> + };
>>>>> +
>>>>> serial@70006000 {
>>>>> /* Debug connector on the bottom of the board near SD card.
>>>>> */
>>>>> status = "okay";
>>>>> @@ -214,7 +220,7 @@
>>>>> regulator-always-on;
>>>>> };
>>>>>
>>>>> - sd6 {
>>>>> + vdd_gpu: sd6 {
>>>>> regulator-name = "+VDD_GPU_AP";
>>>>> regulator-min-microvolt = <650000>;
>>>>> regulator-max-microvolt =
>>>>> <1200000>;
>>>>>
>>>>
>>>> Looks good to me. I see the following error when booting but looking at the
>>>> code appears to be benign. Thierry, Alex, is this normal/okay?
>>>
>>> I have the same messages and asked Alexandre about them the other day. He told
>>> me that it looks normal.
>>
>> Ok great. Hopefully, Alex can ACK then.
>
> Apologies for the (very) delayed reply.
>
> Yes, the messages you are seeing are part of the normal probe sequence
> on Tegra. So this looks good to me.
>
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Can you pick this one up for v4.10 as well?
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 6/9] arm64: dts: m3ulcb: enable SDHI0
From: Simon Horman @ 2016-11-07 13:00 UTC (permalink / raw)
To: Vladimir Barinov
Cc: Magnus Damm, Rob Herring, Mark Rutland, devicetree,
linux-renesas-soc
In-Reply-To: <1478196471-1381-1-git-send-email-vladimir.barinov@cogentembedded.com>
On Thu, Nov 03, 2016 at 09:07:51PM +0300, Vladimir Barinov wrote:
> This supports SDHI0 on M3ULCB board SD card slot
Is SDHI3 also exposed on the M3ULCB?
If so could you consider sending patches to enable it?
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> ---
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 48 ++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> index 3329f78..5be0cf6 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
> @@ -44,6 +44,30 @@
> gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
> };
> };
> +
> + vcc_sdhi0: regulator-vcc-sdhi0 {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "SDHI0 Vcc";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vccq_sdhi0: regulator-vccq-sdhi0 {
> + compatible = "regulator-gpio";
> +
> + regulator-name = "SDHI0 VccQ";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
> + gpios-states = <1>;
> + states = <3300000 1
> + 1800000 0>;
> + };
> };
>
> &extal_clk {
> @@ -68,8 +92,33 @@
> groups = "scif_clk_a";
> function = "scif_clk";
> };
> +
> + sdhi0_pins_3v3: sd0_3v3 {
> + groups = "sdhi0_data4", "sdhi0_ctrl";
> + function = "sdhi0";
> + power-source = <3300>;
> + };
> +
> + sdhi0_pins_1v8: sd0_1v8 {
> + groups = "sdhi0_data4", "sdhi0_ctrl";
> + function = "sdhi0";
> + power-source = <1800>;
> + };
I would prefer the pin nodes to be named as follows:
sdhi0_pins_3v3 -> sdhi0_pins_3v3
sdhi0_pins_1v8 -> sdhi0_pins_uhs
Likewise for SDHI2.
> };
>
> +&sdhi0 {
> + pinctrl-0 = <&sdhi0_pins_3v3>;
> + pinctrl-1 = <&sdhi0_pins_1v8>;
> + pinctrl-names = "default", "state_uhs";
> +
> + vmmc-supply = <&vcc_sdhi0>;
> + vqmmc-supply = <&vccq_sdhi0>;
> + cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
> + bus-width = <4>;
> + sd-uhs-sdr50;
> + status = "okay";
> +};
> +
> &scif2 {
> pinctrl-0 = <&scif2_pins>;
> pinctrl-names = "default";
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: William Wu @ 2016-11-07 13:00 UTC (permalink / raw)
To: kishon-l0cyMroinI0, heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: huangtao-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA, groeck-hpIqsD4AKlfQT0dZR+AlfA,
frank.wang-TNX95d0MmH7DzftRWevZcw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dianders-hpIqsD4AKlfQT0dZR+AlfA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, wulf-TNX95d0MmH7DzftRWevZcw,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
We found that the system crashed due to 480MHz output clock of
USB2 PHY was unstable after clock had been enabled by gpu module.
Theoretically, 1 millisecond is a critical value for 480MHz
output clock stable time, so we try to change the delay time
to 1.2 millisecond to avoid this issue.
Signed-off-by: William Wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
index ecfd7d1..8f2d2b6 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -267,7 +267,7 @@ static int rockchip_usb2phy_clk480m_enable(struct clk_hw *hw)
return ret;
/* waitting for the clk become stable */
- mdelay(1);
+ udelay(1200);
}
return 0;
--
2.0.0
^ permalink raw reply related
* Re: [PATCH] serial: tegra20-hsuart: fix typo in dmas DT binding description
From: Thierry Reding @ 2016-11-07 13:01 UTC (permalink / raw)
To: Mirza Krak
Cc: swarren-3lzwWm7+Weoh9ZMKESR00Q, gnurou-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1468787481-27753-1-git-send-email-mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
On Sun, Jul 17, 2016 at 10:31:21PM +0200, Mirza Krak wrote:
> From: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> The description for dmas references a second property, which should be
> "dma-names" instead of "clock-names".
>
> Signed-off-by: Mirza Krak <mirza.krak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed, ast2400-ibt-bmc'
From: Arnd Bergmann @ 2016-11-07 13:02 UTC (permalink / raw)
To: Cédric Le Goater
Cc: devicetree, Corey Minyard, Benjamin Herrenschmidt, Rob Herring,
Joel Stanley, openipmi-developer, linux-arm-kernel
In-Reply-To: <ebeba60f-429f-fb84-b9da-c27d11d23094@kaod.org>
On Wednesday, November 2, 2016 3:28:01 PM CET Cédric Le Goater wrote:
> On 11/02/2016 02:56 PM, Joel Stanley wrote:
> > On Wed, Nov 2, 2016 at 11:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Wednesday 02 November 2016, Cédric Le Goater wrote:
> >>> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
> >>> other is H8S/2168 compliant.
> >>>
> >>> The current ipmi/bt-bmc driver implements the IPMI version and we
> >>> should reflect its nature in the compatible node name using
> >>> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
> >>> latter should be used for a H8S interface driver if it is implemented
> >>> one day.
> >>>
> >>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> >>
> >> We generally try to avoid changing the compatible strings after the
> >> fact, but it's probably ok in this case.
>
> As the device tree changes are not merged yet, we thought we had some
> more time to fine tune the naming.
Ok, I see. No problem then.
> >> I don't understand who decides which of the two interfaces is used:
> >> is it the same register set that can be driven by either one or the
> >> other driver, or do you expect to have two drivers that can both
> >> be active in the same system and talk to different hardware once
> >> you get there?
> >
> > It's the second case. The H8S BT has a different register layout so it
> > would require a different driver.
>
> yes.
>
> > We don't yet have a driver for the other BT device, but there was
> > recent talk of using it as an alternate (non-ipmi channel) between the
> > BMC and the host. Before that discussion I wasn't aware that the H8S
> > BT existed. I suggested we fix this up before it hits a final release.
> >
> > Cédric, do you think ast2400-ibt-bmc or ast2400-ipmi-bt-bmc does a
> > better job of describing the hardware here?
>
> The specs refer to the two interfaces as BT (non IPMI) and iBT (IPMI).
> I think we can keep the same naming.
Ok
> > While we're modifying the binding, should we add a compat string for
> > the ast2500?
>
> Well, if the change in this patch is fine for all, may be we can add
> the ast2500 compat string in a followup patch ?
Sounds good to me.
Arnd
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
^ permalink raw reply
* Re: [PATCH 4/9] arm64: dts: m3ulcb: enable GPIO leds
From: Vladimir Barinov @ 2016-11-07 13:02 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, Rob Herring, Mark Rutland, devicetree,
linux-renesas-soc
In-Reply-To: <20161107125737.GF12319@verge.net.au>
Hi Simon,
On 07.11.2016 15:57, Simon Horman wrote:
> On Thu, Nov 03, 2016 at 09:07:31PM +0300, Vladimir Barinov wrote:
>> This supports GPIO leds on M3ULCB board
> Are GPIO leds and keys also present on the H3ULCB.
Yes.
> If so could you consider sending patches to enable them?
H3ULCB already includes GPIO leds and keys support in upstream kernel.
Regards,
Vladimir
>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> ---
>> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
>> index fb694b8..3329f78 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
>> @@ -31,6 +31,17 @@
>> /* first 128MB is reserved for secure area. */
>> reg = <0x0 0x48000000 0x0 0x38000000>;
>> };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + led5 {
>> + gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
>> + };
>> + led6 {
>> + gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> };
>>
>> &extal_clk {
>> --
>> 1.9.1
>>
^ permalink raw reply
* Re: [PATCH 6/9] arm64: dts: m3ulcb: enable SDHI0
From: Vladimir Barinov @ 2016-11-07 13:05 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161107130054.GG12319-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hi Simon,
On 07.11.2016 16:00, Simon Horman wrote:
> On Thu, Nov 03, 2016 at 09:07:51PM +0300, Vladimir Barinov wrote:
>> This supports SDHI0 on M3ULCB board SD card slot
> Is SDHI3 also exposed on the M3ULCB?
No, SDHI3 is not exposed on M3ULCB.
Only SDHI0 exposed to SD slot and SDHI2 as eMMC.
> If so could you consider sending patches to enable it?
>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 48 ++++++++++++++++++++++++++
>> 1 file changed, 48 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
>> index 3329f78..5be0cf6 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
>> +++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
>> @@ -44,6 +44,30 @@
>> gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
>> };
>> };
>> +
>> + vcc_sdhi0: regulator-vcc-sdhi0 {
>> + compatible = "regulator-fixed";
>> +
>> + regulator-name = "SDHI0 Vcc";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> +
>> + gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
>> + enable-active-high;
>> + };
>> +
>> + vccq_sdhi0: regulator-vccq-sdhi0 {
>> + compatible = "regulator-gpio";
>> +
>> + regulator-name = "SDHI0 VccQ";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <3300000>;
>> +
>> + gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
>> + gpios-states = <1>;
>> + states = <3300000 1
>> + 1800000 0>;
>> + };
>> };
>>
>> &extal_clk {
>> @@ -68,8 +92,33 @@
>> groups = "scif_clk_a";
>> function = "scif_clk";
>> };
>> +
>> + sdhi0_pins_3v3: sd0_3v3 {
>> + groups = "sdhi0_data4", "sdhi0_ctrl";
>> + function = "sdhi0";
>> + power-source = <3300>;
>> + };
>> +
>> + sdhi0_pins_1v8: sd0_1v8 {
>> + groups = "sdhi0_data4", "sdhi0_ctrl";
>> + function = "sdhi0";
>> + power-source = <1800>;
>> + };
> I would prefer the pin nodes to be named as follows:
>
> sdhi0_pins_3v3 -> sdhi0_pins_3v3
> sdhi0_pins_1v8 -> sdhi0_pins_uhs
>
> Likewise for SDHI2.
Okay, I will resend these changes in the next try.
Regards,
Vladimir
>
>> };
>>
>> +&sdhi0 {
>> + pinctrl-0 = <&sdhi0_pins_3v3>;
>> + pinctrl-1 = <&sdhi0_pins_1v8>;
>> + pinctrl-names = "default", "state_uhs";
>> +
>> + vmmc-supply = <&vcc_sdhi0>;
>> + vqmmc-supply = <&vccq_sdhi0>;
>> + cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
>> + bus-width = <4>;
>> + sd-uhs-sdr50;
>> + status = "okay";
>> +};
>> +
>> &scif2 {
>> pinctrl-0 = <&scif2_pins>;
>> pinctrl-names = "default";
>> --
>> 1.9.1
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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