* [PATCH V4 08/12] boot_constraint: Manage deferrable constraints
From: Russell King - ARM Linux @ 2017-12-13 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213102707.GD3322@vireshk-i7>
On Wed, Dec 13, 2017 at 03:57:07PM +0530, Viresh Kumar wrote:
> On 13-12-17, 10:53, Greg Kroah-Hartman wrote:
> > On Sun, Oct 29, 2017 at 07:18:56PM +0530, Viresh Kumar wrote:
> > > +static void add_deferrable_of_single(struct device_node *np,
> > > + struct dev_boot_constraint *constraints,
> > > + int count)
> > > +{
> > > + struct device *dev;
> > > + int ret;
> > > +
> > > + if (!of_device_is_available(np))
> > > + return;
> > > +
> > > + ret = of_platform_bus_create(np, NULL, NULL, NULL, false);
> > > + if (ret)
> > > + return;
> > > +
> > > + if (of_device_is_compatible(np, "arm,primecell")) {
> >
> > Why is "arm,primecell" in the core code here?
>
> All we need here is a struct device pointer to add constraints. But how we get
> the device node depends on what bus type the device corresponds to. Currently
> this only support amba and platform devices, but we may need to get spi, i2c,
> etc later on.
>
> How do you suggest to keep this stuff out of core here ? Are you asking me to
> add a generic API in the OF core to find the struct device pointer using a node
> pointer ?
Why do we need this? Why can't we lookup the "struct device" by DT
node, and then look at the device's bus type and decide what to do
from that?
Wouldn't a better solution be to use fwnode stuff for this, and
make the bus-type handling a property of the bus type itself,
pushing the bus specific code into the bus layer?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
From: gengdongjiu @ 2017-12-13 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <73019dea-3e2c-8d03-fe1a-6c54527fa401@arm.com>
On 2017/12/13 18:09, Suzuki K Poulose wrote:
>> Reviewed-by: Dave Martin <Dave.Martin@arm.com>
>
> Looks good to me.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Thanks a lot to Suzuki's review.
^ 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: linux-arm-kernel
In-Reply-To: <20171213103219.1464-1-enric.balletbo@collabora.com>
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@collabora.com>
---
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 at RK3399_PD_USB3 {
+ reg = <RK3399_PD_USB3>;
+ clocks = <&cru ACLK_USB3>;
+ pm_qos = <&qos_usb_otg0>,
+ <&qos_usb_otg1>;
+ };
pd_vio at RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
#address-cells = <1>;
--
2.9.3
^ 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: linux-arm-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: 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: linux-arm-kernel
In-Reply-To: <20171213103219.1464-1-enric.balletbo@collabora.com>
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@collabora.com>
Reviewed-by: Brian Norris <briannorris@chromium.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 at 0 {
+ compatible = "google,extcon-usbc-cros-ec";
+ google,usb-port-id = <0>;
+
+ #extcon-cells = <0>;
+ };
+
+ usbc_extcon1: extcon at 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
^ 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: linux-arm-kernel
From: Benson Leung <bleung@chromium.org>
Extend the driver to notify host and device type cables and the presence
of power.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
---
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
^ permalink raw reply related
* [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: linux-arm-kernel
In-Reply-To: <20171206172919.GA87458@google.com>
Hi Brian,
2017-12-06 18:29 GMT+01:00 Brian Norris <briannorris@chromium.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@collabora.com>
>> ---
>> 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 at 0 {
>> + compatible = "google,extcon-usbc-cros-ec";
>> + google,usb-port-id = <0>;
>> +
>> + #extcon-cells = <0>;
>> + };
>> +
>> + usbc_extcon1: extcon at 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@chromium.org>
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <ab9a2ef4-4944-c935-af6e-12503b477879@arm.com>
-----Original Message-----
From: Vladimir Murzin [mailto:vladimir.murzin at arm.com]
Sent: mercredi 13 d?cembre 2017 11:07
To: Alexandre TORGUE <alexandre.torgue@st.com>; Maxime Coquelin <mcoquelin.stm32@gmail.com>; arnd at arndb.de; robh+dt at kernel.org; mark.rutland at arm.com; linux at armlinux.org.uk; Patrice CHOTARD <patrice.chotard@st.com>; lee.jones at linaro.org
Cc: devicetree at vger.kernel.org; linux-arm-kernel at 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
* [PATCH V4 00/12] drivers: Boot Constraints core
From: Viresh Kumar @ 2017-12-13 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213095529.GK13194@kroah.com>
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
^ permalink raw reply
* [PATCH V4 08/12] boot_constraint: Manage deferrable constraints
From: Viresh Kumar @ 2017-12-13 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213095345.GJ13194@kroah.com>
On 13-12-17, 10:53, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 07:18:56PM +0530, Viresh Kumar wrote:
> > +static void add_deferrable_of_single(struct device_node *np,
> > + struct dev_boot_constraint *constraints,
> > + int count)
> > +{
> > + struct device *dev;
> > + int ret;
> > +
> > + if (!of_device_is_available(np))
> > + return;
> > +
> > + ret = of_platform_bus_create(np, NULL, NULL, NULL, false);
> > + if (ret)
> > + return;
> > +
> > + if (of_device_is_compatible(np, "arm,primecell")) {
>
> Why is "arm,primecell" in the core code here?
All we need here is a struct device pointer to add constraints. But how we get
the device node depends on what bus type the device corresponds to. Currently
this only support amba and platform devices, but we may need to get spi, i2c,
etc later on.
How do you suggest to keep this stuff out of core here ? Are you asking me to
add a generic API in the OF core to find the struct device pointer using a node
pointer ?
> > + struct amba_device *adev = of_find_amba_device_by_node(np);
> > +
> > + if (!adev) {
> > + pr_err("Failed to find amba dev: %s\n", np->full_name);
>
> Never use pr_* when you have a valid struct device to use.
Sure. I agree.
> Don't you
> have one from the struct device_node * passed in here?
The struct device_node doesn't contain a struct device * unfortunately. Will it
be acceptable to add one ? That will solve some controversial part of this
function for sure :)
--
viresh
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-13 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpOZ=WOx14gTwH5jfLozepT2Jw8JSY5x+bfEZ_YaiQvFpw@mail.gmail.com>
Bhupesh, Ard,
On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> Hi Ard, Akashi
>
(snip)
> Looking deeper into the issue, since the arm64 kexec-tools uses the
> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> identify its own usable memory and exclude, at its boot time, any
> other memory areas that are part of the panicked kernel's memory.
> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> , for details)
Right.
> 1). Now when 'kexec -p' is executed, this node is patched up only
> with the crashkernel memory range:
>
> /* add linux,usable-memory-range */
> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> result = fdt_setprop_range(new_buf, nodeoffset,
> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> address_cells, size_cells);
>
> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> , for details)
>
> 2). This excludes the ACPI reclaim regions irrespective of whether
> they are marked as System RAM or as RESERVED. As,
> 'linux,usable-memory-range' dt node is patched up only with
> 'crash_reserved_mem' and not 'system_memory_ranges'
>
> 3). As a result when the crashkernel boots up it doesn't find this
> ACPI memory and crashes while trying to access the same:
>
> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> -r`.img --reuse-cmdline -d
>
> [snip..]
>
> Reserved memory range
> 000000000e800000-000000002e7fffff (0)
>
> Coredump memory ranges
> 0000000000000000-000000000e7fffff (0)
> 000000002e800000-000000003961ffff (0)
> 0000000039d40000-000000003ed2ffff (0)
> 000000003ed60000-000000003fbfffff (0)
> 0000001040000000-0000001ffbffffff (0)
> 0000002000000000-0000002ffbffffff (0)
> 0000009000000000-0000009ffbffffff (0)
> 000000a000000000-000000affbffffff (0)
>
> 4). So if we revert Ard's patch or just comment the fixing up of the
> memory cap'ing passed to the crash kernel inside
> 'arch/arm64/mm/init.c' (see below):
>
> static void __init fdt_enforce_memory_region(void)
> {
> struct memblock_region reg = {
> .size = 0,
> };
>
> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>
> if (reg.size)
> //memblock_cap_memory_range(reg.base, reg.size); /*
> comment this out */
> }
Please just don't do that. It can cause a fatal damage on
memory contents of the *crashed* kernel.
> 5). Both the above temporary solutions fix the problem.
>
> 6). However exposing all System RAM regions to the crashkernel is not
> advisable and may cause the crashkernel or some crashkernel drivers to
> fail.
>
> 6a). I am trying an approach now, where the ACPI reclaim regions are
> added to '/proc/iomem' separately as ACPI reclaim regions by the
> kernel code and on the other hand the user-space 'kexec-tools' will
> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> dt node 'linux,usable-memory-range'
I still don't understand why we need to carry over the information
about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
such regions are free to be reused by the kernel after some point of
initialization. Why does crash dump kernel need to know about them?
(In other words, can or should we skip some part of ACPI-related init code
on crash dump kernel?)
Thanks,
-Takahiro AKASHI
> 6b). The kernel code currently looks like the following:
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 30ad2f085d1f..867bdec7c692 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -206,6 +206,7 @@ static void __init request_standard_resources(void)
> {
> struct memblock_region *region;
> struct resource *res;
> + phys_addr_t addr_start, addr_end;
>
> kernel_code.start = __pa_symbol(_text);
> kernel_code.end = __pa_symbol(__init_begin - 1);
> @@ -218,9 +219,17 @@ static void __init request_standard_resources(void)
> res->name = "reserved";
> res->flags = IORESOURCE_MEM;
> } else {
> - res->name = "System RAM";
> - res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> + addr_start =
> __pfn_to_phys(memblock_region_reserved_base_pfn(region));
> + addr_end =
> __pfn_to_phys(memblock_region_reserved_end_pfn(region)) - 1;
> + if ((efi_mem_type(addr_start) == EFI_ACPI_RECLAIM_MEMORY)
> || (efi_mem_type(addr_end) == EFI_ACPI_RECLAIM_MEMORY)) {
> + res->name = "ACPI reclaim region";
> + res->flags = IORESOURCE_MEM;
> + } else {
> + res->name = "System RAM";
> + res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> + }
> }
> +
> res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
> res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
>
> @@ -292,6 +301,7 @@ void __init setup_arch(char **cmdline_p)
>
> request_standard_resources();
>
> + efi_memmap_unmap();
> early_ioremap_reset();
>
> if (acpi_disabled)
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 80d1a885def5..a7c522eac640 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -259,7 +259,6 @@ void __init efi_init(void)
>
> reserve_regions();
> efi_esrt_init();
> - efi_memmap_unmap();
>
> memblock_reserve(params.mmap & PAGE_MASK,
> PAGE_ALIGN(params.mmap_size +
>
>
> After this change the ACPI reclaim regions are properly recognized in
> '/proc/iomem':
>
> # cat /proc/iomem | grep -i ACPI
> 396c0000-3975ffff : ACPI reclaim region
> 39770000-397affff : ACPI reclaim region
> 398a0000-398bffff : ACPI reclaim region
>
> 6c). I am currently changing the 'kexec-tools' and will finish the
> testing over the next few days.
>
> I just wanted to know your opinion on this issue, so that I will be
> able to propose a fix on the above lines.
>
> Also Cc'ing kexec mailing list for more inputs on changes proposed to
> kexec-tools.
>
> Thanks,
> Bhupesh
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Will Deacon @ 2017-12-13 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdX1emac77CnKRbL_xEq4CFm6YyeNMHimFDUhEsDoeWBOw@mail.gmail.com>
Hi Geert,
Thanks for trying to bisect this.
On Tue, Dec 12, 2017 at 09:54:05PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 5:57 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Do you reckon you can bisect between -rc1 and -rc2? We've been unable to
> > reproduce this on any of our systems, unfortunately.
>
> I've tried, but ended up on an unrelated XFS merge commit. Probably I
> marked a few commits good due to not seeing this heisenbug.
>
> For reference, here's the bisect log.
>
> Bad commits showed one or both of "unhandled level 0 translation fault" and
> "invalid pointer". Good commits didn't show any during 6 tries.
>
> git bisect start
> # bad: [ae64f9bd1d3621b5e60d7363bc20afb46aede215] Linux 4.15-rc2
> git bisect bad ae64f9bd1d3621b5e60d7363bc20afb46aede215
> # good: [4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323] Linux 4.15-rc1
> git bisect good 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323
> # good: [9e0600f5cf6cecfcab5046d1453a9538c054d8a7] Merge tag
> 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
> git bisect good 9e0600f5cf6cecfcab5046d1453a9538c054d8a7
> # good: [503505bfea19b7d69e2572297e6defa0f9c2404e] Merge branch
> 'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux into
> drm-fixes
> git bisect good 503505bfea19b7d69e2572297e6defa0f9c2404e
> # good: [ae753ee2771a1bacade56411bb98037b2545c929] Merge tag
> 'afs-fixes-20171201' of
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
> git bisect good ae753ee2771a1bacade56411bb98037b2545c929
> # good: [e1ba1c99dad92c5917b22b1047cf36e4426b124a] Merge tag
> 'riscv-for-linus-4.15-rc2_cleanups' of
> git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux
> git bisect good e1ba1c99dad92c5917b22b1047cf36e4426b124a
^^ This one is the first "good" commit containing the arm64-fixes pull.
Maybe try stressing it a bit more and see if it also fails?
That said, I'm still suspicious that nobody else is seeing this -- I also
checked the various build/boot farms and everything looks ok.
Will
^ permalink raw reply
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-13 10:15 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
* [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
From: Dongjiu Geng @ 2017-12-13 10:13 UTC (permalink / raw)
To: linux-arm-kernel
ARM v8.4 extensions add new neon instructions for performing a
multiplication of each FP16 element of one vector with the corresponding
FP16 element of a second vector, and to add or subtract this without an
intermediate rounding to the corresponding FP32 element in a third vector.
This patch detects this feature and let the userspace know about it via a
HWCAP bit and MRS emulation.
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
---
Change since v2:
1. Change the HWCAP_FHM to HWCAP_ASIMDFHM
Change since v1:
1. Address Dave and Suzuki's comments to update the commit message.
2. Address Dave's comments to update Documentation/arm64/elf_hwcaps.txt.
---
Documentation/arm64/cpu-feature-registers.txt | 4 +++-
Documentation/arm64/elf_hwcaps.txt | 4 ++++
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/include/uapi/asm/hwcap.h | 1 +
arch/arm64/kernel/cpufeature.c | 2 ++
arch/arm64/kernel/cpuinfo.c | 1 +
6 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt
index bd9b3fa..a70090b 100644
--- a/Documentation/arm64/cpu-feature-registers.txt
+++ b/Documentation/arm64/cpu-feature-registers.txt
@@ -110,7 +110,9 @@ infrastructure:
x--------------------------------------------------x
| Name | bits | visible |
|--------------------------------------------------|
- | RES0 | [63-48] | n |
+ | RES0 | [63-52] | n |
+ |--------------------------------------------------|
+ | FHM | [51-48] | y |
|--------------------------------------------------|
| DP | [47-44] | y |
|--------------------------------------------------|
diff --git a/Documentation/arm64/elf_hwcaps.txt b/Documentation/arm64/elf_hwcaps.txt
index 89edba1..57324ee 100644
--- a/Documentation/arm64/elf_hwcaps.txt
+++ b/Documentation/arm64/elf_hwcaps.txt
@@ -158,3 +158,7 @@ HWCAP_SHA512
HWCAP_SVE
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
+
+HWCAP_ASIMDFHM
+
+ Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 08cc885..1818077 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -419,6 +419,7 @@
#define SCTLR_EL1_CP15BEN (1 << 5)
/* id_aa64isar0 */
+#define ID_AA64ISAR0_FHM_SHIFT 48
#define ID_AA64ISAR0_DP_SHIFT 44
#define ID_AA64ISAR0_SM4_SHIFT 40
#define ID_AA64ISAR0_SM3_SHIFT 36
diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
index cda76fa..f018c3d 100644
--- a/arch/arm64/include/uapi/asm/hwcap.h
+++ b/arch/arm64/include/uapi/asm/hwcap.h
@@ -43,5 +43,6 @@
#define HWCAP_ASIMDDP (1 << 20)
#define HWCAP_SHA512 (1 << 21)
#define HWCAP_SVE (1 << 22)
+#define HWCAP_ASIMDFHM (1 << 23)
#endif /* _UAPI__ASM_HWCAP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c5ba009..bc7e707 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -123,6 +123,7 @@ static int __init register_cpu_hwcaps_dumper(void)
* sync with the documentation of the CPU feature register ABI.
*/
static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
+ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_FHM_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_DP_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM4_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM3_SHIFT, 4, 0),
@@ -991,6 +992,7 @@ static bool has_no_fpsimd(const struct arm64_cpu_capabilities *entry, int __unus
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM3),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM4),
HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDDP),
+ HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDFHM),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_FP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_FPHP),
HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 1e25545..7f94623 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -76,6 +76,7 @@
"asimddp",
"sha512",
"sve",
+ "asimdfhm",
NULL
};
--
1.9.1
^ permalink raw reply related
* [PATCH V4 10/12] boot_constraint: Add support for Hisilicon platforms
From: Viresh Kumar @ 2017-12-13 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213094718.GE13194@kroah.com>
On 13-12-17, 10:47, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 07:18:58PM +0530, Viresh Kumar wrote:
> > +static const struct of_device_id machines[] __initconst = {
> > + { .compatible = "hisilicon,hi3660", .data = &hikey3660_constraints },
> > + { .compatible = "hisilicon,hi3798cv200", .data = &hikey3798cv200_constraints },
> > + { .compatible = "hisilicon,hi6220", .data = &hikey6220_constraints },
> > + { }
> > +};
> > +
> > +static int __init hikey_constraints_init(void)
> > +{
> > + const struct hikey_machine_constraints *constraints;
> > + const struct of_device_id *match;
> > + struct device_node *np;
> > +
> > + if (!boot_constraint_earlycon_enabled())
> > + return 0;
> > +
> > + np = of_find_node_by_path("/");
>
> What is this for?
We need to match the above list of "machines" with the root node and "np" here
points to the root node.. and ...
> > + if (!np)
> > + return -ENODEV;
> > +
> > + match = of_match_node(machines, np);
Its used here.
> > + of_node_put(np);
> > +/*
> > + * The amba-pl011 driver registers itself from arch_initcall level. Setup the
> > + * serial boot constraints before that in order not to miss any boot messages.
> > + */
> > +postcore_initcall_sync(hikey_constraints_init);
>
> Now you have to worry about the bootconstraints earlycon being called
> before/after your code.
For boot-constraints to work for any device, it is extremely important to add
the constraint before the device is probed by its driver, otherwise the driver
would end up re-configuring the resources. There is no other way then having
this order dependency here.
> That's another linking order dependancy you
> just created. It feels more complex for something so "simple" as
> looking for the earlycon flag...
--
viresh
^ permalink raw reply
* [PATCH 2/3] ARM: configs: stm32: Enable ARM_MPU
From: Vladimir Murzin @ 2017-12-13 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513101746-18030-3-git-send-email-alexandre.torgue@st.com>
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@st.com>
>
> 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
>
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Arnd Bergmann @ 2017-12-13 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513153607.2439.2.camel@Nokia-N900>
On Wed, Dec 13, 2017 at 9:26 AM, Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> On Wed Dec 13 08:34:22 2017 Linus Walleij <linus.walleij@linaro.org> wrote:
>> Arnd has been nudging me to do DT conversion for EP93xx
>> so if there are many active industrial users of these
>> I should prioritize it, because these things have 20+ years
>> support cycles.
>
> I'm not sure how important or necessary at all is to change anything in these legacy platforms.
I suspect that at several points in the next 5 to 10 years, we will remove
additional platforms or CPU types, as we tend to do when a platform
becomes a maintenance burden and is clearly not used by anyone.
It's hard to predict in advance what triggers the removal, but as the
number of platforms that are not using DT or ARCH_MULTIPLATFORM
goes down to a small number, there will be increased interested in either
removing or converting the remaining ones. This is not an immediate
danger at the moment, since we still have 14 platforms that are not
using ARCH_MULTIPLATFORM, and 23 that have remaining
board files, but you don't want to be the last user of the last platform
after the other ones are done ;-)
>> We also need to think about upholding support in GCC for
>> ARMv4(t) for the foreseeable future if there is a big web of
>> random deeply embedded systems out there that will need
>> updates.
>
> But we should definitely preserve at least what we have.
Plain ARMv4 (and earlier) support in gcc is already marked 'deprecated'
and will likely be gone in gcc-8 (it's still there as of last week). ARMv4T
is going to be around for a while, and you can even keep building for
ARMv4 using "-march=armv4t -marm" when linking with 'ld --fix-v4bx'.
Debian recently did a survey to find out whether there were still users
on ARMv4 or ARMv4T, and the result was that probably everyone is
on ARMv5E or ARMv6 for the ARM port (which is separate from the
ARMHF port that is ARMv7+). See also
https://lists.debian.org/debian-user/2017/11/msg00379.html
and let them know quickly if you use Debian stable releases and
plan to update to Debian 10 (Buster) in the future.
Arnd
^ permalink raw reply
* [PATCH v3] arm64: v8.4: Support for new floating point multiplication instructions
From: Suzuki K Poulose @ 2017-12-13 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513160036-41377-1-git-send-email-gengdongjiu@huawei.com>
On 13/12/17 10:13, Dongjiu Geng wrote:
> ARM v8.4 extensions add new neon instructions for performing a
> multiplication of each FP16 element of one vector with the corresponding
> FP16 element of a second vector, and to add or subtract this without an
> intermediate rounding to the corresponding FP32 element in a third vector.
>
> This patch detects this feature and let the userspace know about it via a
> HWCAP bit and MRS emulation.
>
> Cc: Dave Martin <Dave.Martin@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Looks good to me.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
From: Will Deacon @ 2017-12-13 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7352752.eljzo8O4u9@aspire.rjw.lan>
[adding Lorenzo, Sudeep and Hanjun -- see Rafael's comment below]
On Wed, Dec 13, 2017 at 01:22:59AM +0100, Rafael J. Wysocki wrote:
> On Monday, December 11, 2017 4:50:58 PM CET Prarit Bhargava wrote:
> > Other architectures can use SPCR to setup an early console or console
> > but the current code is ARM64 specific.
> >
> > Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
> > function acpi_arch_setup_console() that can be used for arch-specific
> > setup. Move flags into ACPI code. Update the Documention on the use of
> > the SPCR.
> >
> > [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
> > Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
> > mmio value. Move baud rate check earlier.
> >
> > Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>
> This mostly affects ARM64, so ACKs from that side are requisite for it.
>
> > Cc: linux-doc at vger.kernel.org
> > Cc: linux-kernel at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: linux-pm at vger.kernel.org
> > Cc: linux-acpi at vger.kernel.org
> > Cc: linux-serial at vger.kernel.org
> > Cc: Bhupesh Sharma <bhsharma@redhat.com>
> > Cc: Lv Zheng <lv.zheng@intel.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: x86 at kernel.org
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Timur Tabi <timur@codeaurora.org>
> > ---
> > Documentation/admin-guide/kernel-parameters.txt | 6 +-
> > arch/arm64/kernel/acpi.c | 128 ++++++++++++++++-
> > drivers/acpi/Kconfig | 7 +-
> > drivers/acpi/spcr.c | 175 ++++++------------------
> > drivers/tty/serial/earlycon.c | 15 +-
> > include/linux/acpi.h | 11 +-
> > include/linux/serial_core.h | 2 -
> > 7 files changed, 184 insertions(+), 160 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 6571fbfdb2a1..0d173289c67e 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -914,9 +914,9 @@
> >
> > earlycon= [KNL] Output early console device and options.
> >
> > - When used with no options, the early console is
> > - determined by the stdout-path property in device
> > - tree's chosen node.
> > + [ARM64] The early console is determined by the
> > + stdout-path property in device tree's chosen node,
> > + or determined by the ACPI SPCR table.
> >
> > cdns,<addr>[,options]
> > Start an early, polled-mode console on a Cadence
> > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > index b3162715ed78..b3e33bbdf3b7 100644
> > --- a/arch/arm64/kernel/acpi.c
> > +++ b/arch/arm64/kernel/acpi.c
> > @@ -25,7 +25,6 @@
> > #include <linux/memblock.h>
> > #include <linux/of_fdt.h>
> > #include <linux/smp.h>
> > -#include <linux/serial_core.h>
> >
> > #include <asm/cputype.h>
> > #include <asm/cpu_ops.h>
> > @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
> > return ret;
> > }
> >
> > +/*
> > + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> > + * occasionally getting stuck as 1. To avoid the potential for a hang, check
> > + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> > + * implementations, so only do so if an affected platform is detected in
> > + * acpi_parse_spcr().
> > + */
> > +bool qdf2400_e44_present;
> > +EXPORT_SYMBOL(qdf2400_e44_present);
> > +
> > +/*
> > + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
> > + * Detect them by examining the OEM fields in the SPCR header, similar to PCI
> > + * quirk detection in pci_mcfg.c.
> > + */
> > +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> > +{
> > + if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
> > + return false;
> > +
> > + if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> > + return true;
> > +
> > + if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> > + h->oem_revision == 1)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > +/*
> > + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> > + * register aligned to 32-bit. In addition, the BIOS also encoded the
> > + * access width to be 8 bits. This function detects this errata condition.
> > + */
> > +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> > +{
> > + bool xgene_8250 = false;
> > +
> > + if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
> > + return false;
> > +
> > + if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
> > + memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
> > + return false;
> > +
> > + if (!memcmp(tb->header.oem_table_id, "XGENESPC",
> > + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
> > + xgene_8250 = true;
> > +
> > + if (!memcmp(tb->header.oem_table_id, "ProLiant",
> > + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
> > + xgene_8250 = true;
> > +
> > + return xgene_8250;
> > +}
> > +
> > +int acpi_arch_setup_console(struct acpi_table_spcr *table,
> > + char *opts, char *uart, char *iotype,
> > + int baud_rate, bool earlycon)
> > +{
> > + if (table->header.revision < 2) {
> > + pr_err("wrong table version\n");
> > + return -ENOENT;
> > + }
> > +
> > + switch (table->interface_type) {
> > + case ACPI_DBG2_ARM_SBSA_32BIT:
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
> > + /* fall through */
> > + case ACPI_DBG2_ARM_PL011:
> > + case ACPI_DBG2_ARM_SBSA_GENERIC:
> > + case ACPI_DBG2_BCM2835:
> > + snprintf(uart, ACPI_SPCR_BUF_SIZE, "pl011");
> > + break;
> > + default:
> > + if (strlen(uart) == 0)
> > + return -ENOENT;
> > + }
> > +
> > + /*
> > + * If the E44 erratum is required, then we need to tell the pl011
> > + * driver to implement the work-around.
> > + *
> > + * The global variable is used by the probe function when it
> > + * creates the UARTs, whether or not they're used as a console.
> > + *
> > + * If the user specifies "traditional" earlycon, the qdf2400_e44
> > + * console name matches the EARLYCON_DECLARE() statement, and
> > + * SPCR is not used. Parameter "earlycon" is false.
> > + *
> > + * If the user specifies "SPCR" earlycon, then we need to update
> > + * the console name so that it also says "qdf2400_e44". Parameter
> > + * "earlycon" is true.
> > + *
> > + * For consistency, if we change the console name, then we do it
> > + * for everyone, not just earlycon.
> > + */
> > + if (qdf2400_erratum_44_present(&table->header)) {
> > + qdf2400_e44_present = true;
> > + if (earlycon)
> > + snprintf(uart, ACPI_SPCR_BUF_SIZE, "qdf2400_e44");
> > + }
> > +
> > + if (xgene_8250_erratum_present(table)) {
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio32");
> > +
> > + /* for xgene v1 and v2 we don't know the clock rate of the
> > + * UART so don't attempt to change to the baud rate state
> > + * in the table because driver cannot calculate the dividers
> > + */
> > + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx", uart,
> > + iotype, table->serial_port.address);
> > + } else {
> > + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart,
> > + iotype, table->serial_port.address, baud_rate);
> > + }
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(acpi_arch_setup_console);
> > +
> > /*
> > * acpi_boot_table_init() called from setup_arch(), always.
> > * 1. find RSDP and get its address, and then find XSDT
> > @@ -230,10 +351,11 @@ void __init acpi_boot_table_init(void)
> >
> > done:
> > if (acpi_disabled) {
> > - if (earlycon_init_is_deferred)
> > + if (console_acpi_spcr_enable)
> > early_init_dt_scan_chosen_stdout();
> > } else {
> > - parse_spcr(earlycon_init_is_deferred);
> > + /* Always enable the ACPI SPCR console */
> > + acpi_parse_spcr(console_acpi_spcr_enable);
> > if (IS_ENABLED(CONFIG_ACPI_BGRT))
> > acpi_table_parse(ACPI_SIG_BGRT, acpi_parse_bgrt);
> > }
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index 46505396869e..9ae98eeada76 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -79,7 +79,12 @@ config ACPI_DEBUGGER_USER
> > endif
> >
> > config ACPI_SPCR_TABLE
> > - bool
> > + bool "ACPI Serial Port Console Redirection Support"
> > + default y if ARM64
> > + help
> > + Enable support for Serial Port Console Redirection (SPCR) Table.
> > + This table provides information about the configuration of the
> > + earlycon console.
> >
> > config ACPI_LPIT
> > bool
> > diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> > index 324b35bfe781..f4bb8110e404 100644
> > --- a/drivers/acpi/spcr.c
> > +++ b/drivers/acpi/spcr.c
> > @@ -16,65 +16,18 @@
> > #include <linux/kernel.h>
> > #include <linux/serial_core.h>
> >
> > -/*
> > - * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
> > - * occasionally getting stuck as 1. To avoid the potential for a hang, check
> > - * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
> > - * implementations, so only do so if an affected platform is detected in
> > - * parse_spcr().
> > - */
> > -bool qdf2400_e44_present;
> > -EXPORT_SYMBOL(qdf2400_e44_present);
> > -
> > -/*
> > - * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit.
> > - * Detect them by examining the OEM fields in the SPCR header, similiar to PCI
> > - * quirk detection in pci_mcfg.c.
> > - */
> > -static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
> > -{
> > - if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
> > - return false;
> > -
> > - if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
> > - return true;
> > -
> > - if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
> > - h->oem_revision == 1)
> > - return true;
> > -
> > - return false;
> > -}
> > -
> > -/*
> > - * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> > - * register aligned to 32-bit. In addition, the BIOS also encoded the
> > - * access width to be 8 bits. This function detects this errata condition.
> > - */
> > -static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> > +int __weak acpi_arch_setup_console(struct acpi_table_spcr *table,
> > + char *opts, char *uart, char *iotype,
> > + int baud_rate, bool earlycon)
> > {
> > - bool xgene_8250 = false;
> > -
> > - if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
> > - return false;
> > -
> > - if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
> > - memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
> > - return false;
> > -
> > - if (!memcmp(tb->header.oem_table_id, "XGENESPC",
> > - ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
> > - xgene_8250 = true;
> > -
> > - if (!memcmp(tb->header.oem_table_id, "ProLiant",
> > - ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
> > - xgene_8250 = true;
> > -
> > - return xgene_8250;
> > + snprintf(opts, ACPI_SPCR_OPTS_SIZE, "%s,%s,0x%llx,%d", uart, iotype,
> > + table->serial_port.address, baud_rate);
> > + return 0;
> > }
> >
> > +bool console_acpi_spcr_enable __initdata;
> > /**
> > - * parse_spcr() - parse ACPI SPCR table and add preferred console
> > + * acpi_parse_spcr() - parse ACPI SPCR table and add preferred console
> > *
> > * @earlycon: set up earlycon for the console specified by the table
> > *
> > @@ -86,13 +39,13 @@ static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> > * from arch initialization code as soon as the DT/ACPI decision is made.
> > *
> > */
> > -int __init parse_spcr(bool earlycon)
> > +int __init acpi_parse_spcr(bool earlycon)
> > {
> > - static char opts[64];
> > + static char opts[ACPI_SPCR_OPTS_SIZE];
> > + static char uart[ACPI_SPCR_BUF_SIZE];
> > + static char iotype[ACPI_SPCR_BUF_SIZE];
> > struct acpi_table_spcr *table;
> > acpi_status status;
> > - char *uart;
> > - char *iotype;
> > int baud_rate;
> > int err;
> >
> > @@ -105,48 +58,6 @@ int __init parse_spcr(bool earlycon)
> > if (ACPI_FAILURE(status))
> > return -ENOENT;
> >
> > - if (table->header.revision < 2) {
> > - err = -ENOENT;
> > - pr_err("wrong table version\n");
> > - goto done;
> > - }
> > -
> > - if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> > - switch (ACPI_ACCESS_BIT_WIDTH((
> > - table->serial_port.access_width))) {
> > - default:
> > - pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
> > - case 8:
> > - iotype = "mmio";
> > - break;
> > - case 16:
> > - iotype = "mmio16";
> > - break;
> > - case 32:
> > - iotype = "mmio32";
> > - break;
> > - }
> > - } else
> > - iotype = "io";
> > -
> > - switch (table->interface_type) {
> > - case ACPI_DBG2_ARM_SBSA_32BIT:
> > - iotype = "mmio32";
> > - /* fall through */
> > - case ACPI_DBG2_ARM_PL011:
> > - case ACPI_DBG2_ARM_SBSA_GENERIC:
> > - case ACPI_DBG2_BCM2835:
> > - uart = "pl011";
> > - break;
> > - case ACPI_DBG2_16550_COMPATIBLE:
> > - case ACPI_DBG2_16550_SUBSET:
> > - uart = "uart";
> > - break;
> > - default:
> > - err = -ENOENT;
> > - goto done;
> > - }
> > -
> > switch (table->baud_rate) {
> > case 3:
> > baud_rate = 9600;
> > @@ -165,43 +76,36 @@ int __init parse_spcr(bool earlycon)
> > goto done;
> > }
> >
> > - /*
> > - * If the E44 erratum is required, then we need to tell the pl011
> > - * driver to implement the work-around.
> > - *
> > - * The global variable is used by the probe function when it
> > - * creates the UARTs, whether or not they're used as a console.
> > - *
> > - * If the user specifies "traditional" earlycon, the qdf2400_e44
> > - * console name matches the EARLYCON_DECLARE() statement, and
> > - * SPCR is not used. Parameter "earlycon" is false.
> > - *
> > - * If the user specifies "SPCR" earlycon, then we need to update
> > - * the console name so that it also says "qdf2400_e44". Parameter
> > - * "earlycon" is true.
> > - *
> > - * For consistency, if we change the console name, then we do it
> > - * for everyone, not just earlycon.
> > - */
> > - if (qdf2400_erratum_44_present(&table->header)) {
> > - qdf2400_e44_present = true;
> > - if (earlycon)
> > - uart = "qdf2400_e44";
> > + switch (table->interface_type) {
> > + case ACPI_DBG2_16550_COMPATIBLE:
> > + case ACPI_DBG2_16550_SUBSET:
> > + snprintf(uart, ACPI_SPCR_BUF_SIZE, "uart");
> > + break;
> > + default:
> > + break;
> > }
> >
> > - if (xgene_8250_erratum_present(table)) {
> > - iotype = "mmio32";
> > + if (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> > + u8 width = ACPI_ACCESS_BIT_WIDTH((
> > + table->serial_port.access_width));
> > + switch (width) {
> > + default:
> > + pr_err("Unexpected SPCR Access Width. Defaulting to byte size\n");
> > + case 8:
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio");
> > + break;
> > + case 16:
> > + case 32:
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "mmio%d", width);
> > + break;
> > + }
> > + } else
> > + snprintf(iotype, ACPI_SPCR_BUF_SIZE, "io");
> >
> > - /* for xgene v1 and v2 we don't know the clock rate of the
> > - * UART so don't attempt to change to the baud rate state
> > - * in the table because driver cannot calculate the dividers
> > - */
> > - snprintf(opts, sizeof(opts), "%s,%s,0x%llx", uart, iotype,
> > - table->serial_port.address);
> > - } else {
> > - snprintf(opts, sizeof(opts), "%s,%s,0x%llx,%d", uart, iotype,
> > - table->serial_port.address, baud_rate);
> > - }
> > + err = acpi_arch_setup_console(table, opts, uart, iotype, baud_rate,
> > + earlycon);
> > + if (err)
> > + goto done;
> >
> > pr_info("console: %s\n", opts);
> >
> > @@ -209,7 +113,6 @@ int __init parse_spcr(bool earlycon)
> > setup_earlycon(opts);
> >
> > err = add_preferred_console(uart, 0, opts + strlen(uart) + 1);
> > -
> > done:
> > acpi_put_table((struct acpi_table_header *)table);
> > return err;
> > diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> > index 4c8b80f1c688..b22afb62c7a3 100644
> > --- a/drivers/tty/serial/earlycon.c
> > +++ b/drivers/tty/serial/earlycon.c
> > @@ -196,26 +196,15 @@ int __init setup_earlycon(char *buf)
> > return -ENOENT;
> > }
> >
> > -/*
> > - * When CONFIG_ACPI_SPCR_TABLE is defined, "earlycon" without parameters in
> > - * command line does not start DT earlycon immediately, instead it defers
> > - * starting it until DT/ACPI decision is made. At that time if ACPI is enabled
> > - * call parse_spcr(), else call early_init_dt_scan_chosen_stdout()
> > - */
> > -bool earlycon_init_is_deferred __initdata;
> > -
> > /* early_param wrapper for setup_earlycon() */
> > static int __init param_setup_earlycon(char *buf)
> > {
> > int err;
> >
> > - /*
> > - * Just 'earlycon' is a valid param for devicetree earlycons;
> > - * don't generate a warning from parse_early_params() in that case
> > - */
> > + /* Just 'earlycon' is a valid param for devicetree and ACPI SPCR. */
> > if (!buf || !buf[0]) {
> > if (IS_ENABLED(CONFIG_ACPI_SPCR_TABLE)) {
> > - earlycon_init_is_deferred = true;
> > + console_acpi_spcr_enable = true;
> > return 0;
> > } else if (!buf) {
> > return early_init_dt_scan_chosen_stdout();
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> > index dc1ebfeeb5ec..875d7327d91c 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -1241,10 +1241,17 @@ static inline bool acpi_has_watchdog(void) { return false; }
> > #endif
> >
> > #ifdef CONFIG_ACPI_SPCR_TABLE
> > +#define ACPI_SPCR_OPTS_SIZE 64
> > +#define ACPI_SPCR_BUF_SIZE 32
> > extern bool qdf2400_e44_present;
> > -int parse_spcr(bool earlycon);
> > +extern bool console_acpi_spcr_enable __initdata;
> > +extern int acpi_arch_setup_console(struct acpi_table_spcr *table,
> > + char *opts, char *uart, char *iotype,
> > + int baud_rate, bool earlycon);
> > +int acpi_parse_spcr(bool earlycon);
> > #else
> > -static inline int parse_spcr(bool earlycon) { return 0; }
> > +static const bool console_acpi_spcr_enable;
> > +static inline int acpi_parse_spcr(bool earlycon) { return 0; }
> > #endif
> >
> > #if IS_ENABLED(CONFIG_ACPI_GENERIC_GSI)
> > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> > index 37b044e78333..abfffb4b1c37 100644
> > --- a/include/linux/serial_core.h
> > +++ b/include/linux/serial_core.h
> > @@ -376,10 +376,8 @@ extern int of_setup_earlycon(const struct earlycon_id *match,
> > const char *options);
> >
> > #ifdef CONFIG_SERIAL_EARLYCON
> > -extern bool earlycon_init_is_deferred __initdata;
> > int setup_earlycon(char *buf);
> > #else
> > -static const bool earlycon_init_is_deferred;
> > static inline int setup_earlycon(char *buf) { return 0; }
> > #endif
> >
> >
>
>
^ permalink raw reply
* [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: linux-arm-kernel
In-Reply-To: <1513101746-18030-2-git-send-email-alexandre.torgue@st.com>
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@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
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Geert Uytterhoeven @ 2017-12-13 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <TY1PR06MB0895B34EFC2A48F49AFF0694C0350@TY1PR06MB0895.apcprd06.prod.outlook.com>
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?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH V4 03/12] drivers: Add boot constraints core
From: Viresh Kumar @ 2017-12-13 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213094227.GC13194@kroah.com>
On 13-12-17, 10:42, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 07:18:51PM +0530, Viresh Kumar wrote:
> > Some devices are powered ON by the bootloader before the bootloader
> > handovers control to Linux. It maybe important for those devices to keep
> > working until the time a Linux device driver probes the device and
> > reconfigure its resources.
> >
> > A typical example of that can be the LCD controller, which is used by
> > the bootloaders to show image(s) while the platform is booting into
> > Linux. The LCD controller can be using some resources, like clk,
> > regulators, PM domain, etc, that are shared between several devices.
> > These shared resources should be configured to satisfy need of all the
> > users. If another device's (X) driver gets probed before the LCD
> > controller driver in this case, then it may end up reconfiguring these
> > resources to ranges satisfying the current users (only device X) and
> > that can make the LCD screen unstable.
> >
> > This patch introduces the concept of boot-constraints, which will be set
> > by the bootloaders and the kernel will satisfy them until the time
> > driver for such a device is probed (successfully or unsuccessfully).
> >
> > The list of boot constraint types is empty for now, and will be
> > incrementally updated by later patches.
> >
> > Only two routines are exposed by the boot constraints core for now:
>
> I think we need some documentation somewhere on how to use this, right?
Will add that in next version.
--
viresh
^ permalink raw reply
* [PATCH V4 03/12] drivers: Add boot constraints core
From: Viresh Kumar @ 2017-12-13 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213094205.GB13194@kroah.com>
On 13-12-17, 10:42, Greg Kroah-Hartman wrote:
> On Sun, Oct 29, 2017 at 07:18:51PM +0530, Viresh Kumar wrote:
> > + /*
> > + * Remove boot constraints for both successful and unsuccessful probe(),
> > + * except for the case where EPROBE_DEFER is returned by probe().
> > + */
> > + if (ret != -EPROBE_DEFER)
> > + dev_boot_constraints_remove(dev);
>
> This feels odd, but ok, I trust you :)
I did this because it may not be right to keep the boot constraints up for a
device that failed to probe. For example, a LCD screen may continue wasting
power if its device failed to probe. At least I would like to see a real case
where we don't want to remove the constraints here on probe failure.
> > +/* Forward declarations of constraint specific callbacks */
> > +#endif /* _CORE_H */
>
> What is this comment at the end of the file for?
Perhaps this should be moved to a later patch.
Ack for every other comment you gave.
--
viresh
^ permalink raw reply
* [PATCH V4 00/12] drivers: Boot Constraints core
From: Greg Kroah-Hartman @ 2017-12-13 9:55 UTC (permalink / raw)
To: linux-arm-kernel
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
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