* Re: [PATCH 2/4] arm: dts: sun8i: a83t: Add registers needed for MCPM
From: Maxime Ripard @ 2017-12-13 10:50 UTC (permalink / raw)
To: Mylène Josserand
Cc: wens, linux, robh+dt, mark.rutland, linux-arm-kernel,
linux-kernel, devicetree, thomas.petazzoni
In-Reply-To: <20171211075001.6100-3-mylene.josserand@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]
Hi,
On Mon, Dec 11, 2017 at 08:49:59AM +0100, Mylène Josserand wrote:
> Add 3 registers needed for MCPM (ie SMP): prcm, cpucfg and r_cpucfg.
> prcm and cpucfg are identical with sun9i-a80. The only difference
> is the r_cpucfg that does not exist on sun9i.
>
> Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index a384b766f3dc..eeb2e7d0d6dc 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -323,6 +323,16 @@
> #reset-cells = <1>;
> };
> + cpucfg@01700000 {
Please drop the leading zero here, it generates a warning in dtc.
> + compatible = "allwinner,sun9i-a80-cpucfg";
There's some significant differences between the A83t and the A80 IPs,
you should use a different compatible.
> + reg = <0x01700000 0x100>;
the size is 1k (0x400)
> + };
> +
> + r_cpucfg@1f01c00 {
> + compatible = "allwinner,sun8i-a83t-r-cpucfg";
> + reg = <0x1f01c00 0x100>;
You should order the nodes by physical address
> + };
> +
> pio: pinctrl@1c20800 {
> compatible = "allwinner,sun8i-a83t-pinctrl";
> interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
> @@ -493,6 +503,11 @@
> interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> + prcm@1f01400 {
> + compatible = "allwinner,sun9i-a80-prcm";
That block is significantly different on the A83t. Please use a
different compatible.
> + reg = <0x1f01400 0x200>;
> + };
> +
The size is 1k, again.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: allwinner: a64: a64-olinuxino: add usb otg
From: Maxime Ripard @ 2017-12-13 10:42 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Icenowy Zheng, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi
In-Reply-To: <CAMty3ZDEhXjHTE4WsJK8=yAayuR=qvJQaZEjGq=LDS6Y4V7RFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
On Tue, Dec 12, 2017 at 02:57:01PM +0530, Jagan Teki wrote:
> On Tue, Dec 12, 2017 at 1:43 PM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > Hi,
> >
> > On Tue, Dec 12, 2017 at 11:26:09AM +0530, Jagan Teki wrote:
> >> Add usb otg support for a64-olinuxino board,
> >> - USB0-ID connected with PH9
> >> - USB0-VBUSDET connected with PH6
> >> - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC
> >>
> >> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> >
> > How was this tested? Did you test the OTG part, or only the peripheral
> > part?
>
> Yes peripheral.
Please test the switching between host and peripheral then, and the
same comment applies to your bananapi-m64.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2] eeprom: at25: Add DT support for EEPROMs with odd address bits
From: Ivo Sieben @ 2017-12-13 10:37 UTC (permalink / raw)
To: Rob Herring
Cc: Geert Uytterhoeven, Mark Rutland, Arnd Bergmann,
Greg Kroah-Hartman, Wolfram Sang, devicetree, LKML
In-Reply-To: <20171212205439.ijhvzmsumiu3l5pp@rob-hp-laptop>
2017-12-12 21:54 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Fri, Dec 08, 2017 at 02:46:41PM +0100, Geert Uytterhoeven wrote:
>> Certain EEPROMS have a size that is larger than the number of address
>> bytes would allow, and store the MSB of the address in bit 3 of the
>> instruction byte.
>>
>> This can be described in platform data using EE_INSTR_BIT3_IS_ADDR, or
>> in DT using the obsolete legacy "at25,addr-mode" property.
>> But currently there exists no non-deprecated way to describe this in DT.
>>
>> Hence extend the existing "address-width" DT property to allow
>> specifying 9 address bits, and enable support for that in the driver.
>>
>> This has been tested with a Microchip 25LC040A.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> v2:
>> - Do not consider odd address widths of 17 or 25 bits,
>> - Move handling inside the switch() statement.
>> ---
>> Documentation/devicetree/bindings/eeprom/at25.txt | 4 +++-
>> drivers/misc/eeprom/at25.c | 3 +++
>> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Ivo Sieben <meltedpianoman@gmail.com>
^ permalink raw reply
* [PATCH v2 5/5] arm64: dts: rockchip: add pd_usb3 power-domain node for rk3399
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: MyungJoo Ham, Chanwoo Choi, Lee Jones, Rob Herring,
Heiko Stuebner
Cc: dianders-hpIqsD4AKlfQT0dZR+AlfA, groeck-F7+t8E8rja9g9hUCZPvPmw,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171213103219.1464-1-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Add the usb3 power-domain, its qos area and assign it to the usb device
node.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
---
Changes since v1:
- Split the original patch in different commits
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index ea91f25..c18ff88 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -417,6 +417,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,dis-tx-ipgap-linecheck-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -447,6 +448,7 @@
snps,dis_u2_susphy_quirk;
snps,dis-del-phy-power-chg-quirk;
snps,dis-tx-ipgap-linecheck-quirk;
+ power-domains = <&power RK3399_PD_USB3>;
status = "disabled";
};
};
@@ -995,6 +997,12 @@
clocks = <&cru HCLK_SDIO>;
pm_qos = <&qos_sdioaudio>;
};
+ pd_usb3@RK3399_PD_USB3 {
+ reg = <RK3399_PD_USB3>;
+ clocks = <&cru ACLK_USB3>;
+ pm_qos = <&qos_usb_otg0>,
+ <&qos_usb_otg1>;
+ };
pd_vio@RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.9.3
--
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
* [PATCH v2 4/5] arm64: dts: rockchip: add usb3-phy otg-port support for rk3399.
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: MyungJoo Ham, Chanwoo Choi, Lee Jones, Rob Herring,
Heiko Stuebner
Cc: dianders, groeck, briannorris, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20171213103219.1464-1-enric.balletbo@collabora.com>
Add the usb3 phyter for the USB3.0 OTG controller.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
Changes since v1:
- Split the original patch in different commits
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index f32e9c4..ea91f25 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -409,8 +409,8 @@
reg = <0x0 0xfe800000 0x0 0x100000>;
interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
dr_mode = "otg";
- phys = <&u2phy0_otg>;
- phy-names = "usb2-phy";
+ phys = <&u2phy0_otg>, <&tcphy0_usb3>;
+ phy-names = "usb2-phy", "usb3-phy";
phy_type = "utmi_wide";
snps,dis_enblslpm_quirk;
snps,dis-u2-freeclk-exists-quirk;
@@ -439,8 +439,8 @@
reg = <0x0 0xfe900000 0x0 0x100000>;
interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
dr_mode = "otg";
- phys = <&u2phy1_otg>;
- phy-names = "usb2-phy";
+ phys = <&u2phy1_otg>, <&tcphy1_usb3>;
+ phy-names = "usb2-phy", "usb3-phy";
phy_type = "utmi_wide";
snps,dis_enblslpm_quirk;
snps,dis-u2-freeclk-exists-quirk;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: rockchip: add the aclk_usb3 clocks for USB3.
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: MyungJoo Ham, Chanwoo Choi, Lee Jones, Rob Herring,
Heiko Stuebner
Cc: devicetree, linux-kernel, dianders, linux-rockchip, groeck,
briannorris, linux-arm-kernel
In-Reply-To: <20171213103219.1464-1-enric.balletbo@collabora.com>
The aclk_usb3 must be enabled to support USB3 for rk3399.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
Changes since v1:
- Split the original patch in different commits
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 17e5e1a..f32e9c4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -397,9 +397,11 @@
#size-cells = <2>;
ranges;
clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
- <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+ <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
clock-names = "ref_clk", "suspend_clk",
- "bus_clk", "grf_clk";
+ "bus_clk", "aclk_usb3_rksoc_axi_perf",
+ "aclk_usb3", "grf_clk";
status = "disabled";
usbdrd_dwc3_0: dwc3 {
@@ -425,9 +427,11 @@
#size-cells = <2>;
ranges;
clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
- <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
+ <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+ <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
clock-names = "ref_clk", "suspend_clk",
- "bus_clk", "grf_clk";
+ "bus_clk", "aclk_usb3_rksoc_axi_perf",
+ "aclk_usb3", "grf_clk";
status = "disabled";
usbdrd_dwc3_1: dwc3 {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: rockchip: add extcon nodes and enable tcphy.
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: MyungJoo Ham, Chanwoo Choi, Lee Jones, Rob Herring,
Heiko Stuebner
Cc: dianders-hpIqsD4AKlfQT0dZR+AlfA, groeck-F7+t8E8rja9g9hUCZPvPmw,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171213103219.1464-1-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes since v1:
- Add the Reviewed-by: Brian Norris
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 470105d..03f1950 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -855,6 +855,20 @@ ap_i2c_audio: &i2c8 {
compatible = "google,cros-ec-pwm";
#pwm-cells = <1>;
};
+
+ usbc_extcon0: extcon@0 {
+ compatible = "google,extcon-usbc-cros-ec";
+ google,usb-port-id = <0>;
+
+ #extcon-cells = <0>;
+ };
+
+ usbc_extcon1: extcon@1 {
+ compatible = "google,extcon-usbc-cros-ec";
+ google,usb-port-id = <1>;
+
+ #extcon-cells = <0>;
+ };
};
};
@@ -865,6 +879,16 @@ ap_i2c_audio: &i2c8 {
rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
};
+&tcphy0 {
+ status = "okay";
+ extcon = <&usbc_extcon0>;
+};
+
+&tcphy1 {
+ status = "okay";
+ extcon = <&usbc_extcon1>;
+};
+
&u2phy0 {
status = "okay";
};
@@ -911,6 +935,7 @@ ap_i2c_audio: &i2c8 {
&usbdrd3_0 {
status = "okay";
+ extcon = <&usbc_extcon0>;
};
&usbdrd_dwc3_0 {
@@ -920,6 +945,7 @@ ap_i2c_audio: &i2c8 {
&usbdrd3_1 {
status = "okay";
+ extcon = <&usbc_extcon1>;
};
&usbdrd_dwc3_1 {
--
2.9.3
--
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
* [PATCH v2 1/5] extcon: usbc-cros-ec: add support to notify USB type cables.
From: Enric Balletbo i Serra @ 2017-12-13 10:32 UTC (permalink / raw)
To: MyungJoo Ham, Chanwoo Choi, Lee Jones, Rob Herring,
Heiko Stuebner
Cc: dianders-hpIqsD4AKlfQT0dZR+AlfA, groeck-F7+t8E8rja9g9hUCZPvPmw,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Benson Leung
From: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Extend the driver to notify host and device type cables and the presence
of power.
Signed-off-by: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Reviewed-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
Changes since v1:
- Use the BIT macro. Requested by Lee Jones.
- Add the Reviewed-by: Chanwoo Choi.
drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
include/linux/mfd/cros_ec_commands.h | 17 +++++
2 files changed, 155 insertions(+), 4 deletions(-)
diff --git a/drivers/extcon/extcon-usbc-cros-ec.c b/drivers/extcon/extcon-usbc-cros-ec.c
index 6187f73..6721ab0 100644
--- a/drivers/extcon/extcon-usbc-cros-ec.c
+++ b/drivers/extcon/extcon-usbc-cros-ec.c
@@ -34,16 +34,26 @@ struct cros_ec_extcon_info {
struct notifier_block notifier;
+ unsigned int dr; /* data role */
+ bool pr; /* power role (true if VBUS enabled) */
bool dp; /* DisplayPort enabled */
bool mux; /* SuperSpeed (usb3) enabled */
unsigned int power_type;
};
static const unsigned int usb_type_c_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
EXTCON_DISP_DP,
EXTCON_NONE,
};
+enum usb_data_roles {
+ DR_NONE,
+ DR_HOST,
+ DR_DEVICE,
+};
+
/**
* cros_ec_pd_command() - Send a command to the EC.
* @info: pointer to struct cros_ec_extcon_info
@@ -150,6 +160,7 @@ static int cros_ec_usb_get_role(struct cros_ec_extcon_info *info,
pd_control.port = info->port_id;
pd_control.role = USB_PD_CTRL_ROLE_NO_CHANGE;
pd_control.mux = USB_PD_CTRL_MUX_NO_CHANGE;
+ pd_control.swap = USB_PD_CTRL_SWAP_NONE;
ret = cros_ec_pd_command(info, EC_CMD_USB_PD_CONTROL, 1,
&pd_control, sizeof(pd_control),
&resp, sizeof(resp));
@@ -183,11 +194,72 @@ static int cros_ec_pd_get_num_ports(struct cros_ec_extcon_info *info)
return resp.num_ports;
}
+static const char *cros_ec_usb_role_string(unsigned int role)
+{
+ return role == DR_NONE ? "DISCONNECTED" :
+ (role == DR_HOST ? "DFP" : "UFP");
+}
+
+static const char *cros_ec_usb_power_type_string(unsigned int type)
+{
+ switch (type) {
+ case USB_CHG_TYPE_NONE:
+ return "USB_CHG_TYPE_NONE";
+ case USB_CHG_TYPE_PD:
+ return "USB_CHG_TYPE_PD";
+ case USB_CHG_TYPE_PROPRIETARY:
+ return "USB_CHG_TYPE_PROPRIETARY";
+ case USB_CHG_TYPE_C:
+ return "USB_CHG_TYPE_C";
+ case USB_CHG_TYPE_BC12_DCP:
+ return "USB_CHG_TYPE_BC12_DCP";
+ case USB_CHG_TYPE_BC12_CDP:
+ return "USB_CHG_TYPE_BC12_CDP";
+ case USB_CHG_TYPE_BC12_SDP:
+ return "USB_CHG_TYPE_BC12_SDP";
+ case USB_CHG_TYPE_OTHER:
+ return "USB_CHG_TYPE_OTHER";
+ case USB_CHG_TYPE_VBUS:
+ return "USB_CHG_TYPE_VBUS";
+ case USB_CHG_TYPE_UNKNOWN:
+ return "USB_CHG_TYPE_UNKNOWN";
+ default:
+ return "USB_CHG_TYPE_UNKNOWN";
+ }
+}
+
+static bool cros_ec_usb_power_type_is_wall_wart(unsigned int type,
+ unsigned int role)
+{
+ switch (type) {
+ /* FIXME : Guppy, Donnettes, and other chargers will be miscategorized
+ * because they identify with USB_CHG_TYPE_C, but we can't return true
+ * here from that code because that breaks Suzy-Q and other kinds of
+ * USB Type-C cables and peripherals.
+ */
+ case USB_CHG_TYPE_PROPRIETARY:
+ case USB_CHG_TYPE_BC12_DCP:
+ return true;
+ case USB_CHG_TYPE_PD:
+ case USB_CHG_TYPE_C:
+ case USB_CHG_TYPE_BC12_CDP:
+ case USB_CHG_TYPE_BC12_SDP:
+ case USB_CHG_TYPE_OTHER:
+ case USB_CHG_TYPE_VBUS:
+ case USB_CHG_TYPE_UNKNOWN:
+ case USB_CHG_TYPE_NONE:
+ default:
+ return false;
+ }
+}
+
static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
bool force)
{
struct device *dev = info->dev;
int role, power_type;
+ unsigned int dr = DR_NONE;
+ bool pr = false;
bool polarity = false;
bool dp = false;
bool mux = false;
@@ -206,9 +278,12 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
dev_err(dev, "failed getting role err = %d\n", role);
return role;
}
+ dev_dbg(dev, "disconnected\n");
} else {
int pd_mux_state;
+ dr = (role & PD_CTRL_RESP_ROLE_DATA) ? DR_HOST : DR_DEVICE;
+ pr = (role & PD_CTRL_RESP_ROLE_POWER);
pd_mux_state = cros_ec_usb_get_pd_mux_state(info);
if (pd_mux_state < 0)
pd_mux_state = USB_PD_MUX_USB_ENABLED;
@@ -216,20 +291,62 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
dp = pd_mux_state & USB_PD_MUX_DP_ENABLED;
mux = pd_mux_state & USB_PD_MUX_USB_ENABLED;
hpd = pd_mux_state & USB_PD_MUX_HPD_IRQ;
- }
- if (force || info->dp != dp || info->mux != mux ||
- info->power_type != power_type) {
+ dev_dbg(dev,
+ "connected role 0x%x pwr type %d dr %d pr %d pol %d mux %d dp %d hpd %d\n",
+ role, power_type, dr, pr, polarity, mux, dp, hpd);
+ }
+ /*
+ * When there is no USB host (e.g. USB PD charger),
+ * we are not really a UFP for the AP.
+ */
+ if (dr == DR_DEVICE &&
+ cros_ec_usb_power_type_is_wall_wart(power_type, role))
+ dr = DR_NONE;
+
+ if (force || info->dr != dr || info->pr != pr || info->dp != dp ||
+ info->mux != mux || info->power_type != power_type) {
+ bool host_connected = false, device_connected = false;
+
+ dev_dbg(dev, "Type/Role switch! type = %s role = %s\n",
+ cros_ec_usb_power_type_string(power_type),
+ cros_ec_usb_role_string(dr));
+ info->dr = dr;
+ info->pr = pr;
info->dp = dp;
info->mux = mux;
info->power_type = power_type;
- extcon_set_state(info->edev, EXTCON_DISP_DP, dp);
+ if (dr == DR_DEVICE)
+ device_connected = true;
+ else if (dr == DR_HOST)
+ host_connected = true;
+ extcon_set_state(info->edev, EXTCON_USB, device_connected);
+ extcon_set_state(info->edev, EXTCON_USB_HOST, host_connected);
+ extcon_set_state(info->edev, EXTCON_DISP_DP, dp);
+ extcon_set_property(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_VBUS,
+ (union extcon_property_value)(int)pr);
+ extcon_set_property(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_VBUS,
+ (union extcon_property_value)(int)pr);
+ extcon_set_property(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_TYPEC_POLARITY,
+ (union extcon_property_value)(int)polarity);
+ extcon_set_property(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY,
+ (union extcon_property_value)(int)polarity);
extcon_set_property(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_USB_TYPEC_POLARITY,
(union extcon_property_value)(int)polarity);
+ extcon_set_property(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_SS,
+ (union extcon_property_value)(int)mux);
+ extcon_set_property(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_SS,
+ (union extcon_property_value)(int)mux);
extcon_set_property(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_USB_SS,
(union extcon_property_value)(int)mux);
@@ -237,6 +354,8 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
EXTCON_PROP_DISP_HPD,
(union extcon_property_value)(int)hpd);
+ extcon_sync(info->edev, EXTCON_USB);
+ extcon_sync(info->edev, EXTCON_USB_HOST);
extcon_sync(info->edev, EXTCON_DISP_DP);
} else if (hpd) {
@@ -322,13 +441,28 @@ static int extcon_cros_ec_probe(struct platform_device *pdev)
return ret;
}
+ extcon_set_property_capability(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_VBUS);
+ extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_VBUS);
+ extcon_set_property_capability(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_TYPEC_POLARITY);
+ extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY);
extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_USB_TYPEC_POLARITY);
+ extcon_set_property_capability(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_SS);
+ extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_SS);
extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_USB_SS);
extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
EXTCON_PROP_DISP_HPD);
+ info->dr = DR_NONE;
+ info->pr = false;
+
platform_set_drvdata(pdev, info);
/* Get PD events from the EC */
diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
index 2b16e95..a83f649 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -2904,16 +2904,33 @@ enum usb_pd_control_mux {
USB_PD_CTRL_MUX_AUTO = 5,
};
+enum usb_pd_control_swap {
+ USB_PD_CTRL_SWAP_NONE = 0,
+ USB_PD_CTRL_SWAP_DATA = 1,
+ USB_PD_CTRL_SWAP_POWER = 2,
+ USB_PD_CTRL_SWAP_VCONN = 3,
+ USB_PD_CTRL_SWAP_COUNT
+};
+
struct ec_params_usb_pd_control {
uint8_t port;
uint8_t role;
uint8_t mux;
+ uint8_t swap;
} __packed;
#define PD_CTRL_RESP_ENABLED_COMMS (1 << 0) /* Communication enabled */
#define PD_CTRL_RESP_ENABLED_CONNECTED (1 << 1) /* Device connected */
#define PD_CTRL_RESP_ENABLED_PD_CAPABLE (1 << 2) /* Partner is PD capable */
+#define PD_CTRL_RESP_ROLE_POWER BIT(0) /* 0=SNK/1=SRC */
+#define PD_CTRL_RESP_ROLE_DATA BIT(1) /* 0=UFP/1=DFP */
+#define PD_CTRL_RESP_ROLE_VCONN BIT(2) /* Vconn status */
+#define PD_CTRL_RESP_ROLE_DR_POWER BIT(3) /* Partner is dualrole power */
+#define PD_CTRL_RESP_ROLE_DR_DATA BIT(4) /* Partner is dualrole data */
+#define PD_CTRL_RESP_ROLE_USB_COMM BIT(5) /* Partner USB comm capable */
+#define PD_CTRL_RESP_ROLE_EXT_POWERED BIT(6) /* Partner externally powerd */
+
struct ec_response_usb_pd_control_v1 {
uint8_t enabled;
uint8_t role;
--
2.9.3
--
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 3/3] arm64: dts: rockchip: add extcon nodes and enable tcphy.
From: Enric Balletbo Serra @ 2017-12-13 10:28 UTC (permalink / raw)
To: Brian Norris
Cc: Enric Balletbo i Serra, MyungJoo Ham, Chanwoo Choi, Lee Jones,
Rob Herring, Heiko Stuebner, Doug Anderson, Guenter Roeck,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
open list:ARM/Rockchip SoC..., linux-kernel, Alexandru Stan,
Jeffy Chen, Frank Wang
In-Reply-To: <20171206172919.GA87458-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Hi Brian,
2017-12-06 18:29 GMT+01:00 Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>:
> + Alex, Jeffy, Frank Wang
>
> Hi,
>
> On Wed, Dec 06, 2017 at 12:10:08PM +0100, Enric Balletbo i Serra wrote:
>> Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
>>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
>> index 470105d..03f1950 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
>> @@ -855,6 +855,20 @@ ap_i2c_audio: &i2c8 {
>> compatible = "google,cros-ec-pwm";
>> #pwm-cells = <1>;
>> };
>> +
>> + usbc_extcon0: extcon@0 {
>> + compatible = "google,extcon-usbc-cros-ec";
>> + google,usb-port-id = <0>;
>> +
>> + #extcon-cells = <0>;
>> + };
>> +
>> + usbc_extcon1: extcon@1 {
>> + compatible = "google,extcon-usbc-cros-ec";
>> + google,usb-port-id = <1>;
>> +
>> + #extcon-cells = <0>;
>> + };
>> };
>> };
>>
>> @@ -865,6 +879,16 @@ ap_i2c_audio: &i2c8 {
>> rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
>> };
>>
>> +&tcphy0 {
>> + status = "okay";
>> + extcon = <&usbc_extcon0>;
>> +};
>> +
>> +&tcphy1 {
>> + status = "okay";
>> + extcon = <&usbc_extcon1>;
>> +};
>> +
>> &u2phy0 {
>> status = "okay";
>> };
>> @@ -911,6 +935,7 @@ ap_i2c_audio: &i2c8 {
>>
>> &usbdrd3_0 {
>> status = "okay";
>> + extcon = <&usbc_extcon0>;
>> };
>>
>> &usbdrd_dwc3_0 {
>> @@ -920,6 +945,7 @@ ap_i2c_audio: &i2c8 {
>>
>> &usbdrd3_1 {
>> status = "okay";
>> + extcon = <&usbc_extcon1>;
>> };
>>
>> &usbdrd_dwc3_1 {
>
> Seems OK.
>
> Also, IIUC, I think if we ever want to support dual-role/OTG, we need an
> extcon reference in the USB2/OTG PHY that serves these ports too. i.e.,
> u2phy0 and u2phy1? Notably, the PHY driver supports the extcon
> properties, but it's not documented in
> Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt yet (we
> should probably get that fixed).
>
I'll take a look at this and send a separate patchset. Thanks.
Enric
> So, anyway, maybe the above isn't a blocker for this patch. Just noticed
> it while reading. Assuming the driver stuff falls into place:
>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@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 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
From: Alexandre TORGUE @ 2017-12-13 10:28 UTC (permalink / raw)
To: Vladimir Murzin, Maxime Coquelin,
arnd-r2nGTMty4D4@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org, Patrice CHOTARD,
lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <ab9a2ef4-4944-c935-af6e-12503b477879-5wv7dgnIgG8@public.gmane.org>
-----Original Message-----
From: Vladimir Murzin [mailto:vladimir.murzin@arm.com]
Sent: mercredi 13 décembre 2017 11:07
To: Alexandre TORGUE <alexandre.torgue@st.com>; Maxime Coquelin <mcoquelin.stm32@gmail.com>; arnd@arndb.de; robh+dt@kernel.org; mark.rutland@arm.com; linux@armlinux.org.uk; Patrice CHOTARD <patrice.chotard@st.com>; lee.jones@linaro.org
Cc: devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
On 12/12/17 18:02, Alexandre Torgue wrote:
> On cortex-M7 MCU, DMA have to use a non cache-able memory area. For
> this reason a dedicated memory pool is created for DMA.
> This patch creates a DMA memory pool of 1MB of each STM32 MCU which
> embeds a cortex-M7 expect stm32f746-disco. Indeed, as stm32f746-disco
> has
^^^^^^
except?
Sorry, Is there a typo issue (or just wording issue) ?
> only a 8MB SDRAM and it's tricky to reduce memory used by Kernel.
I guess that 1MB is a kind of "should be enough" estimate, probably something along with [1] would give you exact numbers...
Exactly, 1MB is a kind "should be enough" and code is here to show that we need a dedicated memory area for DMA. But this value has
to be adapt regarding to use case needed by users. Thanks for the lkml link. It will help users to adapt DMA area and thanks for reviewing.
Regards
Alex
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
>
> diff --git a/arch/arm/boot/dts/stm32746g-eval.dts
> b/arch/arm/boot/dts/stm32746g-eval.dts
> index 2d4e717..3f52a7b 100644
> --- a/arch/arm/boot/dts/stm32746g-eval.dts
> +++ b/arch/arm/boot/dts/stm32746g-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xc0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32f769-disco.dts
> b/arch/arm/boot/dts/stm32f769-disco.dts
> index 4463ca1..08699a2 100644
> --- a/arch/arm/boot/dts/stm32f769-disco.dts
> +++ b/arch/arm/boot/dts/stm32f769-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xC0000000 0x1000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc0f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-disco.dts
> b/arch/arm/boot/dts/stm32h743i-disco.dts
> index 79e841d..104545a 100644
> --- a/arch/arm/boot/dts/stm32h743i-disco.dts
> +++ b/arch/arm/boot/dts/stm32h743i-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart2;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts
> b/arch/arm/boot/dts/stm32h743i-eval.dts
> index 9f0e72c..5bd4b16 100644
> --- a/arch/arm/boot/dts/stm32h743i-eval.dts
> +++ b/arch/arm/boot/dts/stm32h743i-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
>
Usage of dma-default looks correct to me, so FWIW
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
[1] https://lkml.org/lkml/2017/7/7/296
Vladimir
^ permalink raw reply
* Re: [PATCH V4 00/12] drivers: Boot Constraints core
From: Viresh Kumar @ 2017-12-13 10:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Vincent Guittot, Stephen Boyd, Rajendra Nayak,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robdclark-Re5JQEeQqe8AvxtiuMwx3w, s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
l.stach-bIcnvbaLZ9MEGnE8C9+IrQ, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
fabio.estevam-3arQi8VN3Tc, nm-l0cyMroinI0,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, Frank Rowand
In-Reply-To: <20171213095529.GK13194-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On 13-12-17, 10:55, Greg Kroah-Hartman wrote:
> On Tue, Nov 28, 2017 at 09:48:18AM +0530, Viresh Kumar wrote:
> > On 29-10-17, 19:18, Viresh Kumar wrote:
> > > Here is V4 of the boot constraints core based on your feedback from V3.
> > > We now have support for three platforms (as you suggested) included in
> > > this series: Hisilicon, IMX and Qualcomm.
> >
> > Hi Greg,
> >
> > I was waiting for rc1 to come out before sending a reminder for this
> > series and so here is one :)
>
> I've reviewed it enough for now, needs a tiny bit of work, but looking
> much better, nice job!
Thanks a lot for finding time to get this reviewed. Really appreciate that.
--
viresh
--
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 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-13 10:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Rob Herring, Mark Rutland, Russell King,
Magnus Damm, Chris Paterson, Biju Das,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdWEFttz_Shve+D1Ku2NoUYX-AomzXY9JFGRjzzM=hOc_A@mail.gmail.com>
Hello Geert,
thank you for your feedback.
> Hi Fabrizio,
>
> On Wed, Dec 13, 2017 at 10:42 AM, Fabrizio Castro
> <fabrizio.castro@bp.renesas.com> wrote:
> >> On Tue, Dec 12, 2017 at 06:49:38PM +0000, Fabrizio Castro wrote:
> >> > Add CMT[01] support to SoC DT.
> >> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> >> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> >> > ---
> >> > arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
> >> > 1 file changed, 30 insertions(+)
> >>
> >> I was expecting the cmt nodes to be "disabled" in the SoC file
> >> and then enabled selectively in board files. Am I missing something?
> >
> > Since this component is just a compare and match timer, I thought there was no harm in enabling it by default in the SoC specific DT.
> > The system will park it and leave its clock disabled until actually needed for something.
> > The user can still disable it in the board specific DT if he/she doesn't mean to even have the option to use it. Do you prefer I left it
> disabled by default?
>
> It's debatable (thus up to Simon the maintainer ;-).
> For I/O devices, we disable them in the SoC .dtsi file.
> For core infrastructure like interrupt, DMA, and GPIO controllers, we keep
> them enabled.
>
> Timers are core functionality, but who's actually using these timers?
I don't have a use case in mind unfortunately, but it's still core functionality and pretty harmless as far as I can tell. Let's see what Simon thinks about this.
Thanks,
Fab
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH 2/3] ARM: configs: stm32: Enable ARM_MPU
From: Vladimir Murzin @ 2017-12-13 10:11 UTC (permalink / raw)
To: Alexandre Torgue, Maxime Coquelin, arnd-r2nGTMty4D4,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, patrice.chotard-qxv4g6HH51o,
lee.jones-QSEj5FYQhm4dnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513101746-18030-3-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On 12/12/17 18:02, Alexandre Torgue wrote:
> STM32 MCUs embed a Memory Protection Unit. Enabling this setting will
> allow the Kernel to configure the MPU according to devicetree.
Would it be better to "select ARM_MPU" for machines with Cortex-M7?
Vladimir
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>
> diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
> index bb358ff..e642bdf9 100644
> --- a/arch/arm/configs/stm32_defconfig
> +++ b/arch/arm/configs/stm32_defconfig
> @@ -24,6 +24,7 @@ CONFIG_SET_MEM_PARAM=y
> CONFIG_DRAM_BASE=0x90000000
> CONFIG_FLASH_MEM_BASE=0x08000000
> CONFIG_FLASH_SIZE=0x00200000
> +CONFIG_ARM_MPU=y
> CONFIG_PREEMPT=y
> # CONFIG_ATAGS is not set
> CONFIG_ZBOOT_ROM_TEXT=0x0
>
--
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 1/3] ARM: dts: stm32: add DMA memory pool on MCU which embed a cortex-M7
From: Vladimir Murzin @ 2017-12-13 10:06 UTC (permalink / raw)
To: Alexandre Torgue, Maxime Coquelin, arnd-r2nGTMty4D4,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, patrice.chotard-qxv4g6HH51o,
lee.jones-QSEj5FYQhm4dnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513101746-18030-2-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On 12/12/17 18:02, Alexandre Torgue wrote:
> On cortex-M7 MCU, DMA have to use a non cache-able memory area. For this
> reason a dedicated memory pool is created for DMA.
> This patch creates a DMA memory pool of 1MB of each STM32 MCU which
> embeds a cortex-M7 expect stm32f746-disco. Indeed, as stm32f746-disco has
^^^^^^
except?
> only a 8MB SDRAM and it's tricky to reduce memory used by Kernel.
I guess that 1MB is a kind of "should be enough" estimate, probably something
along with [1] would give you exact numbers...
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>
> diff --git a/arch/arm/boot/dts/stm32746g-eval.dts b/arch/arm/boot/dts/stm32746g-eval.dts
> index 2d4e717..3f52a7b 100644
> --- a/arch/arm/boot/dts/stm32746g-eval.dts
> +++ b/arch/arm/boot/dts/stm32746g-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xc0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
> index 4463ca1..08699a2 100644
> --- a/arch/arm/boot/dts/stm32f769-disco.dts
> +++ b/arch/arm/boot/dts/stm32f769-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xC0000000 0x1000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc0f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-disco.dts b/arch/arm/boot/dts/stm32h743i-disco.dts
> index 79e841d..104545a 100644
> --- a/arch/arm/boot/dts/stm32h743i-disco.dts
> +++ b/arch/arm/boot/dts/stm32h743i-disco.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart2;
> };
> diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts b/arch/arm/boot/dts/stm32h743i-eval.dts
> index 9f0e72c..5bd4b16 100644
> --- a/arch/arm/boot/dts/stm32h743i-eval.dts
> +++ b/arch/arm/boot/dts/stm32h743i-eval.dts
> @@ -57,6 +57,19 @@
> reg = <0xd0000000 0x2000000>;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + linux,dma {
> + compatible = "shared-dma-pool";
> + linux,dma-default;
> + no-map;
> + reg = <0xc1f00000 0x100000>;
> + };
> + };
> +
> aliases {
> serial0 = &usart1;
> };
>
Usage of dma-default looks correct to me, so FWIW
Reviewed-by: Vladimir Murzin <vladimir.murzin-5wv7dgnIgG8@public.gmane.org>
[1] https://lkml.org/lkml/2017/7/7/296
Vladimir
--
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 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Geert Uytterhoeven @ 2017-12-13 10:05 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Simon Horman, Rob Herring, Mark Rutland, Russell King,
Magnus Damm, Chris Paterson, Biju Das,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <TY1PR06MB0895B34EFC2A48F49AFF0694C0350-/PRLmSCtZ16EeHdvShrxA20DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Fabrizio,
On Wed, Dec 13, 2017 at 10:42 AM, Fabrizio Castro
<fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> wrote:
>> On Tue, Dec 12, 2017 at 06:49:38PM +0000, Fabrizio Castro wrote:
>> > Add CMT[01] support to SoC DT.
>> > Signed-off-by: Fabrizio Castro <fabrizio.castro-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
>> > Reviewed-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
>> > ---
>> > arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
>> > 1 file changed, 30 insertions(+)
>>
>> I was expecting the cmt nodes to be "disabled" in the SoC file
>> and then enabled selectively in board files. Am I missing something?
>
> Since this component is just a compare and match timer, I thought there was no harm in enabling it by default in the SoC specific DT. The system will park it and leave its clock disabled until actually needed for something.
> The user can still disable it in the board specific DT if he/she doesn't mean to even have the option to use it. Do you prefer I left it disabled by default?
It's debatable (thus up to Simon the maintainer ;-).
For I/O devices, we disable them in the SoC .dtsi file.
For core infrastructure like interrupt, DMA, and GPIO controllers, we keep
them enabled.
Timers are core functionality, but who's actually using these timers?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v3 09/33] nds32: Cache and TLB routines
From: Greentime Hu @ 2017-12-13 10:04 UTC (permalink / raw)
To: Guo Ren
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial-u79uwXL29TY76Z2rM5mHXA,
Geert Uytterhoeven, Linus Walleij, Mark Rutland, Greg KH
In-Reply-To: <20171213094548.GA23563@gary-OptiPlex-3050>
2017-12-13 17:45 GMT+08:00 Guo Ren <ren_guo-Y+KPrCd2zL4AvxtiuMwx3w@public.gmane.org>:
> Hello,
>
> CPU team could improve the tlbop_*. Eg: Design a hardware
> internal flag bit for SR_TLB_VPN, tlbop_* will invalid it and mtsr
> SR_TLB_VPN will valid it.
>
> So:
> On Wed, Dec 13, 2017 at 05:03:33PM +0800, Greentime Hu wrote:
>> mtsr addr1 NDS32_SR_TLB_VPN
>> interrupt coming
>> mtsr addr2 NDS32_SR_TLB_VPN <- TLB_VPN has been set to addr2
> mtsr SR_TLB_VPN will valid the flag bit
>> tlbop_rwr(*pte);
> tlbop_rwr will invalid SR_TLB_VPN flag bit
>> interrupt finish
>> tlbop_rwr(*pte); <- it will use the wrong TLB_VPN
> Because SR_TLB_VPN is in a invalid state, no operation happen on
> tlbop_rwr.
>
> Then they are atomic safe ,no spin_lock_irq need.
> :)
>
Oh, I see. I may propose this idea to our ARCH colleagues for the next
version design.
Many thanks.
--
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 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
From: Geert Uytterhoeven @ 2017-12-13 9:59 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Rob Herring, Mark Rutland, Linux-Renesas, Daniel Lezcano,
Thomas Gleixner, Simon Horman, Chris Paterson, Biju Das,
devicetree
In-Reply-To: <1513104579-6333-2-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
On Tue, Dec 12, 2017 at 7:49 PM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Document SoC specific compatible strings for r8a7743 and r8a7745.
> No driver change is needed as the fallback strings will activate
> the right code.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
With the issues pointed out by Simon fixed:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V4 00/12] drivers: Boot Constraints core
From: Greg Kroah-Hartman @ 2017-12-13 9:55 UTC (permalink / raw)
To: Viresh Kumar
Cc: Vincent Guittot, Stephen Boyd, Rajendra Nayak, linux-kernel,
linux-arm-kernel, robdclark, s.hauer, l.stach, shawnguo,
fabio.estevam, nm, xuwei5, robh+dt, devicetree, Frank Rowand
In-Reply-To: <20171128041818.GE11413@vireshk-i7>
On Tue, Nov 28, 2017 at 09:48:18AM +0530, Viresh Kumar wrote:
> On 29-10-17, 19:18, Viresh Kumar wrote:
> > Here is V4 of the boot constraints core based on your feedback from V3.
> > We now have support for three platforms (as you suggested) included in
> > this series: Hisilicon, IMX and Qualcomm.
>
> Hi Greg,
>
> I was waiting for rc1 to come out before sending a reminder for this
> series and so here is one :)
I've reviewed it enough for now, needs a tiny bit of work, but looking
much better, nice job!
gre gk-h
^ permalink raw reply
* RE: [PATCH 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
From: Fabrizio Castro @ 2017-12-13 9:50 UTC (permalink / raw)
To: Simon Horman
Cc: Rob Herring, Mark Rutland, linux-renesas-soc@vger.kernel.org,
Daniel Lezcano, Thomas Gleixner, Geert Uytterhoeven,
Chris Paterson, Biju Das, devicetree@vger.kernel.org
In-Reply-To: <20171213084048.jxofa3hinb6gm2ax@verge.net.au>
Hello Simon,
thank you for the feedback.
I'll apply your comments to V2, but I'll wait for your reply on the CMT "enable by default" issue.
Thanks,
Fab
> Subject: Re: [PATCH 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
>
> On Tue, Dec 12, 2017 at 06:49:37PM +0000, Fabrizio Castro wrote:
> > Document SoC specific compatible strings for r8a7743 and r8a7745.
> > No driver change is needed as the fallback strings will activate
> > the right code.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > ---
> > Documentation/devicetree/bindings/timer/renesas,cmt.txt | 12 +++++++++---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > index d740989..1e4fe98 100644
> > --- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> > @@ -22,6 +22,10 @@ Required Properties:
> >
> > - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4.
> > - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4.
> > + - "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743.
> > + - "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743.
> > + - "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in r8a7745.
> > + - "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in r8a7745.
> > - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790.
> > - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790.
> > - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791.
> > @@ -31,9 +35,11 @@ Required Properties:
> > - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794.
> > - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794.
> >
> > - - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2.
> > - - "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2.
> > -These are fallbacks for r8a73a4 and all the R-Car Gen2
> > + - "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2 or
>
> nit: or -> and ?
>
> > +RZ/G1.
> > + - "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2 or
> > +RZ/G1.
> > +These are fallbacks for r8a73a4, all the R-Car Gen2 and RZ/G1
> > entrieslisted above.
>
> nit: all the R-Car -> R-Car
>
> > - reg: base address and length of the registers block for the timer module.
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH v3 09/33] nds32: Cache and TLB routines
From: Guo Ren @ 2017-12-13 9:45 UTC (permalink / raw)
To: Greentime Hu
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial-u79uwXL29TY76Z2rM5mHXA,
Geert Uytterhoeven, Linus Walleij, Mark Rutland, Greg KH
In-Reply-To: <CAEbi=3fvdWMExreVsSu3TJqXUr5Zpt4k_q=cXXB3miJCvY-+1g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello,
CPU team could improve the tlbop_*. Eg: Design a hardware
internal flag bit for SR_TLB_VPN, tlbop_* will invalid it and mtsr
SR_TLB_VPN will valid it.
So:
On Wed, Dec 13, 2017 at 05:03:33PM +0800, Greentime Hu wrote:
> mtsr addr1 NDS32_SR_TLB_VPN
> interrupt coming
> mtsr addr2 NDS32_SR_TLB_VPN <- TLB_VPN has been set to addr2
mtsr SR_TLB_VPN will valid the flag bit
> tlbop_rwr(*pte);
tlbop_rwr will invalid SR_TLB_VPN flag bit
> interrupt finish
> tlbop_rwr(*pte); <- it will use the wrong TLB_VPN
Because SR_TLB_VPN is in a invalid state, no operation happen on
tlbop_rwr.
Then they are atomic safe ,no spin_lock_irq need.
:)
Guo Ren
--
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 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-13 9:42 UTC (permalink / raw)
To: Simon Horman
Cc: Rob Herring, Mark Rutland, Russell King, Magnus Damm,
Geert Uytterhoeven, Chris Paterson, Biju Das,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20171213083829.ptdeggbon3szmko4@verge.net.au>
Hello Simon,
thank you for your feedback.
> On Tue, Dec 12, 2017 at 06:49:38PM +0000, Fabrizio Castro wrote:
> > Add CMT[01] support to SoC DT.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > ---
> > arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
> > 1 file changed, 30 insertions(+)
>
> I was expecting the cmt nodes to be "disabled" in the SoC file
> and then enabled selectively in board files. Am I missing something?
Since this component is just a compare and match timer, I thought there was no harm in enabling it by default in the SoC specific DT. The system will park it and leave its clock disabled until actually needed for something.
The user can still disable it in the board specific DT if he/she doesn't mean to even have the option to use it. Do you prefer I left it disabled by default?
Thanks,
Fab
>
> Otherwise this patch looks good to me.
>
> > diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
> > index 59860c8..0e2834a 100644
> > --- a/arch/arm/boot/dts/r8a7743.dtsi
> > +++ b/arch/arm/boot/dts/r8a7743.dtsi
> > @@ -262,6 +262,36 @@
> > IRQ_TYPE_LEVEL_LOW)>;
> > };
> >
> > +cmt0: timer@ffca0000 {
> > +compatible = "renesas,r8a7743-cmt0",
> > + "renesas,rcar-gen2-cmt0";
> > +reg = <0 0xffca0000 0 0x1004>;
> > +interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> > +clocks = <&cpg CPG_MOD 124>;
> > +clock-names = "fck";
> > +power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> > +resets = <&cpg 124>;
> > +};
> > +
> > +cmt1: timer@e6130000 {
> > +compatible = "renesas,r8a7743-cmt1",
> > + "renesas,rcar-gen2-cmt1";
> > +reg = <0 0xe6130000 0 0x1004>;
> > +interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
> > +clocks = <&cpg CPG_MOD 329>;
> > +clock-names = "fck";
> > +power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> > +resets = <&cpg 329>;
> > +};
> > +
> > cpg: clock-controller@e6150000 {
> > compatible = "renesas,r8a7743-cpg-mssr";
> > reg = <0 0xe6150000 0 0x1000>;
> > --
> > 2.7.4
> >
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* Re: [PATCH v2 3/4] thermal: armada: add support for CP110
From: Baruch Siach @ 2017-12-13 9:42 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Ezequiel Garcia, Miquel RAYNAL, Zhang Rui, Eduardo Valentin,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Russell King,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <874lovq9cx.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Gregory,
On Wed, Dec 13, 2017 at 10:13:02AM +0100, Gregory CLEMENT wrote:
> On mer., déc. 13 2017, Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
[...]
> > There are two separate issues here:
> >
> > 1. DT binding
> >
> > 2. init_sensor callback implementation
> >
> > We both agree on #1. The A38x and CP110 need separate compatible strings. In
> > case we want to access the LSB control register on Armada 38x, we will need
> > yet another compatible string (marvell,armada380-v2-thermal maybe?).
>
> Actually, if it is _compatible_ then we will use the same compatible, ie
> "marvell,armadacp110-thermal"
Reusing the same compatible string for the same hardware peripheral in
different SoCs is not a good idea. You often find out later that they are not
actually the same.
But this point is moot. The A38x and CP110 thermal sensors are not the same.
The overheat interrupt registers are in different offsets.
> > As for #2, I'm all for sharing as much code as possible. I find the vendor
> > kernel approach of duplicating the init routines[1] unhelpful as it violates
> > the DRY principle. The differences between armada380_init_sensor() and
> > cp110_init_sensor() are minor. In my opinion, these differences should be
> > expressed explicitly in the armada_thermal_data, in a similar way to my
> > suggested control_msb_offset field. The vendor code hides these differences in
> > slight variations of duplicated code.
> >
> > What is the advantage of a separate init routine?
>
> The main advantage is to be able keep the armada380_init_sensor as the
> legacy init, and then being able to use the new armadacp110_init_sensor
> for the new binding.
I disagree, sorry. I don't think I can make my point any more clear than I
did.
I am fine with you or Miquel making the code changes that you think are
necessary. I'll comment on the code when I see it.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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 0/5] Add Sound support for iWave RZ/G1M board
From: Biju Das @ 2017-12-13 9:27 UTC (permalink / raw)
To: Simon Horman
Cc: Rob Herring, Mark Rutland, Russell King, Magnus Damm,
Chris Paterson,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20171213090240.xqgihh4bqsfzeaip-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hi Simon,
Thanks.
There is a typo in the documentation dependency link.
The correct one is https://patchwork.kernel.org/patch/10108015/
Regards,
Biju
> -----Original Message-----
> From: Simon Horman [mailto:horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org]
> Sent: 13 December 2017 09:03
> To: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>; Mark Rutland
> <mark.rutland-5wv7dgnIgG8@public.gmane.org>; Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>; Magnus
> Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; Chris Paterson
> <Chris.Paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-renesas-
> soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH 0/5] Add Sound support for iWave RZ/G1M board
>
> On Tue, Dec 12, 2017 at 06:25:06PM +0000, Biju Das wrote:
> > This series aims to add sound support for iWave RZ/G1M board.
> >
> > This patch series has documentation dependency on
> > https://patchwork.kernel.org/patch/10108014/
> >
> > Biju Das (5):
> > ARM: shmobile: defconfig: Enable SGTL5000 audio codec
> > ARM: dts: r8a7743: Add audio clocks
> > ARM: dts: r8a7743: Add audio DMAC support
> > ARM: dts: r8a7743: Add sound support
> > ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec
> >
> > arch/arm/boot/dts/iwg20d-q7-common.dtsi | 24 +++
> > arch/arm/boot/dts/r8a7743.dtsi | 270
> ++++++++++++++++++++++++++++++++
> > arch/arm/configs/shmobile_defconfig | 1 +
> > 3 files changed, 295 insertions(+)
>
> These patches seem clean to me although I do not have sufficient
> documentation to properly review the last patch.
>
> I will leave these sit for a few days to allow others to review them.
[https://www2.renesas.eu/media/email/unicef_2017.jpg]
This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
--
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 v10 08/13] regmap: add SLIMbus support
From: Greg Kroah-Hartman @ 2017-12-13 9:25 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: Mark Brown, alsa-devel, sdharia, Rob Herring, Mark Rutland,
Jonathan Corbet, pombredanne, j.neuschaefer, linux-arm-msm,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20171211234307.14465-9-srinivas.kandagatla@linaro.org>
On Mon, Dec 11, 2017 at 11:43:02PM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> This patch adds support to read/write SLIMbus value elements.
> Currently it only supports byte read/write. Adding this support in
> regmap would give codec drivers more flexibility when there are more
> than 2 control interfaces like SLIMbus, i2c.
>
> Without this patch each codec driver has to directly call SLIMbus value
> element apis, and this could would get messy once we want to add i2c
> interface to it.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> drivers/base/regmap/Kconfig | 4 ++
> drivers/base/regmap/Makefile | 1 +
> drivers/base/regmap/regmap-slimbus.c | 80 ++++++++++++++++++++++++++++++++++++
> include/linux/regmap.h | 18 ++++++++
> 4 files changed, 103 insertions(+)
> create mode 100644 drivers/base/regmap/regmap-slimbus.c
Mark, can I get an Ack for this patch so I can take it through my tree
with the other patches in this series?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v10 00/13] Introduce framework for SLIMbus device driver
From: Greg Kroah-Hartman @ 2017-12-13 9:25 UTC (permalink / raw)
To: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A
Cc: Mark Brown, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
sdharia-sgV2jX0FEOL9JmXXK+q4OQ, Rob Herring, Mark Rutland,
Jonathan Corbet, pombredanne-od1rfyK75/E,
j.neuschaefer-hi6Y0CQ0nG0, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171211234307.14465-1-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Dec 11, 2017 at 11:42:54PM +0000, srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> SLIMbus (Serial Low Power Interchip Media Bus) is a specification
> developed by MIPI (Mobile Industry Processor Interface) alliance.
> SLIMbus is a 2-wire implementation, which is used to communicate with
> peripheral components like audio-codec.
> SLIMbus uses Time-Division-Multiplexing to accommodate multiple data
> channels, and control channel. Control channel has messages to do
> device-enumeration, messages to send/receive control-data to/from
> SLIMbus devices, messages for port/channel management, and messages to
> do bandwidth allocation.
> Framework is introduced to support multiple instances of the bus
> (1 controller per bus), and multiple slave devices per controller.
> SPI and I2C frameworks, and comments from last time when I submitted
> the patches were referred-to while working on this framework.
>
> These patchsets introduce device-management, OF helpers, and messaging
> APIs, controller driver for Qualcomm's SLIMbus controller, and
> clock-pause feature for entering/exiting low-power mode for SLIMbus.
> Framework patches to do channel, port and bandwidth
> management are work-in-progress and will be sent out once these
> initial patches are accepted.
>
> These patchsets were tested on IFC6410 board with Qualcomm APQ8064
> processor using the controller driver, and a WCD9310 codec.
>
> v9: https://lkml.org/lkml/2017/12/7/289
>
> Changes from v9 to v10:
> * Added kernel-doc reference into slimbus driver api doc suggested by
> Jonathan Corbet
These all look good to me. I can take this through my tree if I get the
ack from Mark for the regmap changes.
thanks,
greg k-h
--
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