date:20170821

Re: [PATCH 04/18] rpmsg: glink: Move the common glink protocol implementation to glink_native.c

2017-08-21 Thread Arun Kumar Neelakantam




On 8/16/2017 10:48 PM, Sricharan R wrote:

+
+struct glink_msg {
+   __le16 cmd;
+   __le16 param1;
+   __le32 param2;
+   u8 data[];
+} __packed;


why we are using extra u8 data[] member here ?


+
+/**
+ * struct glink_defer_cmd - deferred incoming control message
+ * @node:  list node
+ * @msg:   message header
+ * data:   payload of the message
+ *
+ * Copy of a received control message, to be added to @rx_queue and processed
+ * by @rx_work of @glink_rpm.
+ */
+struct glink_defer_cmd {
+   struct list_head node;
+
+   struct glink_msg msg;
+   u8 data[];
+};
+
+/**
+ * struct glink_rpm - driver context, relates to one remote subsystem


glink_rpm to qcom_glink


+static int qcom_glink_tx(struct qcom_glink *glink,
+const void *hdr, size_t hlen,
+const void *data, size_t dlen, bool wait)
+{
+   unsigned int tlen = hlen + dlen;
+   int ret;
+
+   /* Reject packets that are too big */
+   if (tlen >= glink->tx_pipe->length)
+   return -EINVAL;


we need to add support for split packets, in some cases packets may be 
greater than 16K.

+
+   if (WARN(tlen % 8, "Unaligned TX request"))
+   return -EINVAL;
+
+   ret = mutex_lock_interruptible(>tx_lock);
+   if (ret)
+   return ret;
+
+   while (qcom_glink_tx_avail(glink) < tlen) {
+   if (!wait) {
+   ret = -ENOMEM;


This condition is either reader is slow or not reading data, should we 
return -EAGAIN here instead of -ENOMEM?

+   goto out;
+   }
+
+   msleep(10);
+   }
+
+   qcom_glink_tx_write(glink, hdr, hlen, data, dlen);
+
+   mbox_send_message(glink->mbox_chan, NULL);
+   mbox_client_txdone(glink->mbox_chan, 0);
+
+out:
+   mutex_unlock(>tx_lock);
+
+   return ret;
+}
+




+/**
+ * qcom_glink_send_open_req() - send a RPM_CMD_OPEN request to the remote
+ * @glink:
+ * @channel:


Missed information for @ glink and @channel

+ *
+ * Allocates a local channel id and sends a RPM_CMD_OPEN message to the remote.
+ * Will return with refcount held, regardless of outcome.
+ *
+ * Returns 0 on success, negative errno otherwise.
+ */
+static int qcom_glink_send_open_req(struct qcom_glink *glink,
+   struct glink_channel *channel)




+static irqreturn_t qcom_glink_native_intr(int irq, void *data)
+{
+   struct qcom_glink *glink = data;
+   struct glink_msg msg;
+   unsigned int param1;
+   unsigned int param2;
+   unsigned int avail;
+   unsigned int cmd;
+   int ret;
+
+   for (;;) {
+   avail = qcom_glink_rx_avail(glink);
+   if (avail < sizeof(msg))
+   break;
+
+   qcom_glink_rx_peak(glink, , sizeof(msg));
+
+   cmd = le16_to_cpu(msg.cmd);
+   param1 = le16_to_cpu(msg.param1);
+   param2 = le32_to_cpu(msg.param2);
+
+   switch (cmd) {
+   case RPM_CMD_VERSION:
+   case RPM_CMD_VERSION_ACK:
+   case RPM_CMD_CLOSE:
+   case RPM_CMD_CLOSE_ACK:
+   ret = qcom_glink_rx_defer(glink, 0);
+   break;
+   case RPM_CMD_OPEN_ACK:
+   ret = qcom_glink_rx_open_ack(glink, param1);
+   qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
+   break;
+   case RPM_CMD_OPEN:
+   ret = qcom_glink_rx_defer(glink, param2);
+   break;
+   case RPM_CMD_TX_DATA:
+   case RPM_CMD_TX_DATA_CONT:
+   ret = qcom_glink_rx_data(glink, avail);
+   break;
+   case RPM_CMD_READ_NOTIF:
+   qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
+
+   mbox_send_message(glink->mbox_chan, NULL);
+   mbox_client_txdone(glink->mbox_chan, 0);
+
+   ret = 0;
+   break;
+   default:
+   dev_err(glink->dev, "unhandled rx cmd: %d\n", cmd);


please add more information in error log to find the remote peripheral 
also other wise after adding SMEM transport it will be difficult to find 
for which peripheral the error came.

+   ret = -EINVAL;
+   break;
+   }
+
+   if (ret)
+   break;
+   }
+
+   return IRQ_HANDLED;
+}
+



+struct qcom_glink *qcom_glink_native_probe(struct device *dev,
+  struct qcom_glink_pipe *rx,
+  struct qcom_glink_pipe *tx)
+{
+   int irq;
+   int ret;
+   struct qcom_glink *glink;
+
+   glink = devm_kzalloc(dev, sizeof(*glink), GFP_KERNEL);
+   if (!glink)
+

Re: [PATCH 04/18] rpmsg: glink: Move the common glink protocol implementation to glink_native.c

2017-08-21 Thread Arun Kumar Neelakantam




On 8/16/2017 10:48 PM, Sricharan R wrote:

+
+struct glink_msg {
+   __le16 cmd;
+   __le16 param1;
+   __le32 param2;
+   u8 data[];
+} __packed;


why we are using extra u8 data[] member here ?


+
+/**
+ * struct glink_defer_cmd - deferred incoming control message
+ * @node:  list node
+ * @msg:   message header
+ * data:   payload of the message
+ *
+ * Copy of a received control message, to be added to @rx_queue and processed
+ * by @rx_work of @glink_rpm.
+ */
+struct glink_defer_cmd {
+   struct list_head node;
+
+   struct glink_msg msg;
+   u8 data[];
+};
+
+/**
+ * struct glink_rpm - driver context, relates to one remote subsystem


glink_rpm to qcom_glink


+static int qcom_glink_tx(struct qcom_glink *glink,
+const void *hdr, size_t hlen,
+const void *data, size_t dlen, bool wait)
+{
+   unsigned int tlen = hlen + dlen;
+   int ret;
+
+   /* Reject packets that are too big */
+   if (tlen >= glink->tx_pipe->length)
+   return -EINVAL;


we need to add support for split packets, in some cases packets may be 
greater than 16K.

+
+   if (WARN(tlen % 8, "Unaligned TX request"))
+   return -EINVAL;
+
+   ret = mutex_lock_interruptible(>tx_lock);
+   if (ret)
+   return ret;
+
+   while (qcom_glink_tx_avail(glink) < tlen) {
+   if (!wait) {
+   ret = -ENOMEM;


This condition is either reader is slow or not reading data, should we 
return -EAGAIN here instead of -ENOMEM?

+   goto out;
+   }
+
+   msleep(10);
+   }
+
+   qcom_glink_tx_write(glink, hdr, hlen, data, dlen);
+
+   mbox_send_message(glink->mbox_chan, NULL);
+   mbox_client_txdone(glink->mbox_chan, 0);
+
+out:
+   mutex_unlock(>tx_lock);
+
+   return ret;
+}
+




+/**
+ * qcom_glink_send_open_req() - send a RPM_CMD_OPEN request to the remote
+ * @glink:
+ * @channel:


Missed information for @ glink and @channel

+ *
+ * Allocates a local channel id and sends a RPM_CMD_OPEN message to the remote.
+ * Will return with refcount held, regardless of outcome.
+ *
+ * Returns 0 on success, negative errno otherwise.
+ */
+static int qcom_glink_send_open_req(struct qcom_glink *glink,
+   struct glink_channel *channel)




+static irqreturn_t qcom_glink_native_intr(int irq, void *data)
+{
+   struct qcom_glink *glink = data;
+   struct glink_msg msg;
+   unsigned int param1;
+   unsigned int param2;
+   unsigned int avail;
+   unsigned int cmd;
+   int ret;
+
+   for (;;) {
+   avail = qcom_glink_rx_avail(glink);
+   if (avail < sizeof(msg))
+   break;
+
+   qcom_glink_rx_peak(glink, , sizeof(msg));
+
+   cmd = le16_to_cpu(msg.cmd);
+   param1 = le16_to_cpu(msg.param1);
+   param2 = le32_to_cpu(msg.param2);
+
+   switch (cmd) {
+   case RPM_CMD_VERSION:
+   case RPM_CMD_VERSION_ACK:
+   case RPM_CMD_CLOSE:
+   case RPM_CMD_CLOSE_ACK:
+   ret = qcom_glink_rx_defer(glink, 0);
+   break;
+   case RPM_CMD_OPEN_ACK:
+   ret = qcom_glink_rx_open_ack(glink, param1);
+   qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
+   break;
+   case RPM_CMD_OPEN:
+   ret = qcom_glink_rx_defer(glink, param2);
+   break;
+   case RPM_CMD_TX_DATA:
+   case RPM_CMD_TX_DATA_CONT:
+   ret = qcom_glink_rx_data(glink, avail);
+   break;
+   case RPM_CMD_READ_NOTIF:
+   qcom_glink_rx_advance(glink, ALIGN(sizeof(msg), 8));
+
+   mbox_send_message(glink->mbox_chan, NULL);
+   mbox_client_txdone(glink->mbox_chan, 0);
+
+   ret = 0;
+   break;
+   default:
+   dev_err(glink->dev, "unhandled rx cmd: %d\n", cmd);


please add more information in error log to find the remote peripheral 
also other wise after adding SMEM transport it will be difficult to find 
for which peripheral the error came.

+   ret = -EINVAL;
+   break;
+   }
+
+   if (ret)
+   break;
+   }
+
+   return IRQ_HANDLED;
+}
+



+struct qcom_glink *qcom_glink_native_probe(struct device *dev,
+  struct qcom_glink_pipe *rx,
+  struct qcom_glink_pipe *tx)
+{
+   int irq;
+   int ret;
+   struct qcom_glink *glink;
+
+   glink = devm_kzalloc(dev, sizeof(*glink), GFP_KERNEL);
+   if (!glink)
+

[PATCH 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

2017-08-21 Thread Takashi Iwai

This patch adds the MFD driver for Dollar Cove TI PMIC (ACPI INT33F5)
that is found on some Intel Cherry Trail devices.
The driver is based on the original work by Intel, found at:
  https://github.com/01org/ProductionKernelQuilts

This is a minimal version for adding the basic resources.  Currently,
only ACPI PMIC opregion and the external power-button are used.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Signed-off-by: Takashi Iwai 
---
 drivers/mfd/Kconfig|  13 +++
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/intel_soc_pmic_dc_ti.c | 189 +
 3 files changed, 203 insertions(+)
 create mode 100644 drivers/mfd/intel_soc_pmic_dc_ti.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 94ad2c1c3d90..28c12bb50c9f 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -496,6 +496,19 @@ config INTEL_SOC_PMIC_CHTWC
  available before any devices using it are probed. This option also
  causes the designware-i2c driver to be builtin for the same reason.
 
+config INTEL_SOC_PMIC_DC_TI
+   tristate "Support for Dollar Cove TI PMIC"
+   depends on GPIOLIB
+   depends on I2C
+   depends on ACPI
+   depends on X86
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ Select this option for supporting Dollar Cove TI PMIC device that is
+ found on some Intel Cherry Trail systems.
+
 config MFD_INTEL_LPSS
tristate
select COMMON_CLK
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 080793b3fd0e..16c4fe519d30 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -216,6 +216,7 @@ intel-soc-pmic-objs := intel_soc_pmic_core.o 
intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
 obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
+obj-$(CONFIG_INTEL_SOC_PMIC_DC_TI) += intel_soc_pmic_dc_ti.o
 obj-$(CONFIG_MFD_MT6397)   += mt6397-core.o
 
 obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
diff --git a/drivers/mfd/intel_soc_pmic_dc_ti.c 
b/drivers/mfd/intel_soc_pmic_dc_ti.c
new file mode 100644
index ..f1c2ac310bf0
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_dc_ti.c
@@ -0,0 +1,189 @@
+/*
+ * Device access for Dollar Cove TI PMIC
+ * Copyright (c) 2014, Intel Corporation.
+ *   Author: Ramakrishna Pallala 
+ *
+ * Cleanup and forward-ported
+ *   Copyright (c) 2017 Takashi Iwai 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DC_TI_IRQLVL1  0x01
+#define DC_TI_MASK_IRQLVL1 0x02
+
+/* Level 1 IRQs */
+enum {
+   DC_TI_PWRBTN = 0,   /* power button */
+   DC_TI_DIETMPWARN,   /* thermal */
+   DC_TI_ADCCMPL,  /* ADC */
+   /* no irq 3 */
+   DC_TI_VBATLOW = 4,  /* battery */
+   DC_TI_VBUSDET,  /* power source */
+   /* no irq 6 */
+   DC_TI_CCEOCAL = 7,  /* battery */
+};
+
+static struct resource power_button_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_PWRBTN),
+};
+
+static struct resource thermal_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_DIETMPWARN),
+};
+
+static struct resource adc_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_ADCCMPL),
+};
+
+static struct resource pwrsrc_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_VBUSDET),
+};
+
+static struct resource battery_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_VBATLOW),
+   DEFINE_RES_IRQ(DC_TI_CCEOCAL),
+};
+
+static struct mfd_cell dc_ti_dev[] = {
+   {
+   .name = "dc_ti_pwrbtn",
+   .num_resources = ARRAY_SIZE(power_button_resources),
+   .resources = power_button_resources,
+   },
+   {
+   .name = "dc_ti_adc",
+   .num_resources = ARRAY_SIZE(adc_resources),
+   .resources = adc_resources,
+   },
+   {
+   .name = "dc_ti_thermal",
+   .num_resources = ARRAY_SIZE(thermal_resources),
+   .resources = thermal_resources,
+   },
+   {
+   .name = "dc_ti_pwrsrc",
+   .num_resources = ARRAY_SIZE(pwrsrc_resources),
+   .resources = pwrsrc_resources,
+   },
+   {
+   .name = "dc_ti_battery",
+   .num_resources = ARRAY_SIZE(battery_resources),
+   .resources = battery_resources,
+   },
+   {
+   .name = "dc_ti_region",
+   },
+};
+
+static const struct regmap_config dc_ti_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = 128,
+   .cache_type = REGCACHE_NONE,
+};
+
+static const struct regmap_irq dc_ti_irqs[] = {
+   REGMAP_IRQ_REG(DC_TI_PWRBTN, 0, BIT(DC_TI_PWRBTN)),
+   REGMAP_IRQ_REG(DC_TI_DIETMPWARN, 0, BIT(DC_TI_DIETMPWARN)),
+

[PATCH 2/3] input/keyboard: Add support for Dollar Cove TI power button

2017-08-21 Thread Takashi Iwai

This provides a new input driver for supporting the power button on
Dollar Cove TI PMIC, found on Cherrytrail-based devices.
The patch is based on the original work by Intel, found at:
  https://github.com/01org/ProductionKernelQuilts

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Signed-off-by: Takashi Iwai 
---
 drivers/input/keyboard/Kconfig|  7 +++
 drivers/input/keyboard/Makefile   |  1 +
 drivers/input/keyboard/dc_ti_pwrbtn.c | 85 +++
 3 files changed, 93 insertions(+)
 create mode 100644 drivers/input/keyboard/dc_ti_pwrbtn.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 4c4ab1ced235..673748b3cc34 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -756,4 +756,11 @@ config KEYBOARD_BCM
  To compile this driver as a module, choose M here: the
  module will be called bcm-keypad.
 
+config KEYBOARD_DC_TI_PWRBTN
+   tristate "Dollar Cove TI power button driver"
+   depends on INTEL_SOC_PMIC_DC_TI
+   help
+ Say Y here fi you want to have a power button driver for
+ Dollar Cove TI PMIC.
+
 endif
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index d2338bacdad1..fa473d241e5c 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -66,3 +66,4 @@ obj-$(CONFIG_KEYBOARD_TM2_TOUCHKEY)   += tm2-touchkey.o
 obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
 obj-$(CONFIG_KEYBOARD_XTKBD)   += xtkbd.o
 obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
+obj-$(CONFIG_KEYBOARD_DC_TI_PWRBTN)+= dc_ti_pwrbtn.o
diff --git a/drivers/input/keyboard/dc_ti_pwrbtn.c 
b/drivers/input/keyboard/dc_ti_pwrbtn.c
new file mode 100644
index ..a0900a440c92
--- /dev/null
+++ b/drivers/input/keyboard/dc_ti_pwrbtn.c
@@ -0,0 +1,85 @@
+/*
+ * Power button driver for Dollar Cove TI PMIC
+ * Copyright (C) 2014 Intel Corp
+ * Copyright (c) 2017 Takashi Iwai 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DC_TI_SIRQ_REG 0x3
+#define SIRQ_PWRBTN_REL(1 << 0)
+
+#define DRIVER_NAME "dc_ti_pwrbtn"
+
+static irqreturn_t dc_ti_pwrbtn_interrupt(int irq, void *dev_id)
+{
+   struct input_dev *pwrbtn_input = dev_id;
+   struct device *dev = pwrbtn_input->dev.parent;
+   struct regmap *regmap = dev_get_drvdata(dev);
+   int state;
+
+   if (!regmap_read(regmap, DC_TI_SIRQ_REG, )) {
+   dev_dbg(dev, "SIRQ_REG=0x%x\n", state);
+   state &= SIRQ_PWRBTN_REL;
+   input_event(pwrbtn_input, EV_KEY, KEY_POWER, !state);
+   input_sync(pwrbtn_input);
+   }
+
+   return IRQ_HANDLED;
+}
+
+static int dc_ti_pwrbtn_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct intel_soc_pmic *pmic = dev_get_drvdata(dev->parent);
+   struct input_dev *pwrbtn_input;
+   int irq;
+   int ret;
+
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0)
+   return -EINVAL;
+   pwrbtn_input = devm_input_allocate_device(dev);
+   if (!pwrbtn_input)
+   return -ENOMEM;
+   pwrbtn_input->name = pdev->name;
+   pwrbtn_input->phys = "dc-ti-power/input0";
+   pwrbtn_input->id.bustype = BUS_HOST;
+   pwrbtn_input->dev.parent = dev;
+   input_set_capability(pwrbtn_input, EV_KEY, KEY_POWER);
+   ret = input_register_device(pwrbtn_input);
+   if (ret)
+   return ret;
+
+   dev_set_drvdata(dev, pmic->regmap);
+
+   ret = devm_request_threaded_irq(dev, irq, NULL, dc_ti_pwrbtn_interrupt,
+   0, KBUILD_MODNAME, pwrbtn_input);
+   if (ret)
+   return ret;
+
+   ret = enable_irq_wake(irq);
+   if (ret)
+   dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);
+
+   return 0;
+}
+
+static struct platform_driver dc_ti_pwrbtn_driver = {
+   .driver = {
+   .name = DRIVER_NAME,
+   },
+   .probe  = dc_ti_pwrbtn_probe,
+};
+
+module_platform_driver(dc_ti_pwrbtn_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRIVER_NAME);
-- 
2.14.0

[PATCH 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

2017-08-21 Thread Takashi Iwai

This patch adds the MFD driver for Dollar Cove TI PMIC (ACPI INT33F5)
that is found on some Intel Cherry Trail devices.
The driver is based on the original work by Intel, found at:
  https://github.com/01org/ProductionKernelQuilts

This is a minimal version for adding the basic resources.  Currently,
only ACPI PMIC opregion and the external power-button are used.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Signed-off-by: Takashi Iwai 
---
 drivers/mfd/Kconfig|  13 +++
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/intel_soc_pmic_dc_ti.c | 189 +
 3 files changed, 203 insertions(+)
 create mode 100644 drivers/mfd/intel_soc_pmic_dc_ti.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 94ad2c1c3d90..28c12bb50c9f 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -496,6 +496,19 @@ config INTEL_SOC_PMIC_CHTWC
  available before any devices using it are probed. This option also
  causes the designware-i2c driver to be builtin for the same reason.
 
+config INTEL_SOC_PMIC_DC_TI
+   tristate "Support for Dollar Cove TI PMIC"
+   depends on GPIOLIB
+   depends on I2C
+   depends on ACPI
+   depends on X86
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ Select this option for supporting Dollar Cove TI PMIC device that is
+ found on some Intel Cherry Trail systems.
+
 config MFD_INTEL_LPSS
tristate
select COMMON_CLK
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 080793b3fd0e..16c4fe519d30 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -216,6 +216,7 @@ intel-soc-pmic-objs := intel_soc_pmic_core.o 
intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
 obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
+obj-$(CONFIG_INTEL_SOC_PMIC_DC_TI) += intel_soc_pmic_dc_ti.o
 obj-$(CONFIG_MFD_MT6397)   += mt6397-core.o
 
 obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
diff --git a/drivers/mfd/intel_soc_pmic_dc_ti.c 
b/drivers/mfd/intel_soc_pmic_dc_ti.c
new file mode 100644
index ..f1c2ac310bf0
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_dc_ti.c
@@ -0,0 +1,189 @@
+/*
+ * Device access for Dollar Cove TI PMIC
+ * Copyright (c) 2014, Intel Corporation.
+ *   Author: Ramakrishna Pallala 
+ *
+ * Cleanup and forward-ported
+ *   Copyright (c) 2017 Takashi Iwai 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DC_TI_IRQLVL1  0x01
+#define DC_TI_MASK_IRQLVL1 0x02
+
+/* Level 1 IRQs */
+enum {
+   DC_TI_PWRBTN = 0,   /* power button */
+   DC_TI_DIETMPWARN,   /* thermal */
+   DC_TI_ADCCMPL,  /* ADC */
+   /* no irq 3 */
+   DC_TI_VBATLOW = 4,  /* battery */
+   DC_TI_VBUSDET,  /* power source */
+   /* no irq 6 */
+   DC_TI_CCEOCAL = 7,  /* battery */
+};
+
+static struct resource power_button_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_PWRBTN),
+};
+
+static struct resource thermal_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_DIETMPWARN),
+};
+
+static struct resource adc_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_ADCCMPL),
+};
+
+static struct resource pwrsrc_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_VBUSDET),
+};
+
+static struct resource battery_resources[] = {
+   DEFINE_RES_IRQ(DC_TI_VBATLOW),
+   DEFINE_RES_IRQ(DC_TI_CCEOCAL),
+};
+
+static struct mfd_cell dc_ti_dev[] = {
+   {
+   .name = "dc_ti_pwrbtn",
+   .num_resources = ARRAY_SIZE(power_button_resources),
+   .resources = power_button_resources,
+   },
+   {
+   .name = "dc_ti_adc",
+   .num_resources = ARRAY_SIZE(adc_resources),
+   .resources = adc_resources,
+   },
+   {
+   .name = "dc_ti_thermal",
+   .num_resources = ARRAY_SIZE(thermal_resources),
+   .resources = thermal_resources,
+   },
+   {
+   .name = "dc_ti_pwrsrc",
+   .num_resources = ARRAY_SIZE(pwrsrc_resources),
+   .resources = pwrsrc_resources,
+   },
+   {
+   .name = "dc_ti_battery",
+   .num_resources = ARRAY_SIZE(battery_resources),
+   .resources = battery_resources,
+   },
+   {
+   .name = "dc_ti_region",
+   },
+};
+
+static const struct regmap_config dc_ti_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = 128,
+   .cache_type = REGCACHE_NONE,
+};
+
+static const struct regmap_irq dc_ti_irqs[] = {
+   REGMAP_IRQ_REG(DC_TI_PWRBTN, 0, BIT(DC_TI_PWRBTN)),
+   REGMAP_IRQ_REG(DC_TI_DIETMPWARN, 0, BIT(DC_TI_DIETMPWARN)),
+   REGMAP_IRQ_REG(DC_TI_ADCCMPL, 0, BIT(DC_TI_ADCCMPL)),
+

[PATCH 2/3] input/keyboard: Add support for Dollar Cove TI power button

2017-08-21 Thread Takashi Iwai

This provides a new input driver for supporting the power button on
Dollar Cove TI PMIC, found on Cherrytrail-based devices.
The patch is based on the original work by Intel, found at:
  https://github.com/01org/ProductionKernelQuilts

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Signed-off-by: Takashi Iwai 
---
 drivers/input/keyboard/Kconfig|  7 +++
 drivers/input/keyboard/Makefile   |  1 +
 drivers/input/keyboard/dc_ti_pwrbtn.c | 85 +++
 3 files changed, 93 insertions(+)
 create mode 100644 drivers/input/keyboard/dc_ti_pwrbtn.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 4c4ab1ced235..673748b3cc34 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -756,4 +756,11 @@ config KEYBOARD_BCM
  To compile this driver as a module, choose M here: the
  module will be called bcm-keypad.
 
+config KEYBOARD_DC_TI_PWRBTN
+   tristate "Dollar Cove TI power button driver"
+   depends on INTEL_SOC_PMIC_DC_TI
+   help
+ Say Y here fi you want to have a power button driver for
+ Dollar Cove TI PMIC.
+
 endif
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index d2338bacdad1..fa473d241e5c 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -66,3 +66,4 @@ obj-$(CONFIG_KEYBOARD_TM2_TOUCHKEY)   += tm2-touchkey.o
 obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
 obj-$(CONFIG_KEYBOARD_XTKBD)   += xtkbd.o
 obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
+obj-$(CONFIG_KEYBOARD_DC_TI_PWRBTN)+= dc_ti_pwrbtn.o
diff --git a/drivers/input/keyboard/dc_ti_pwrbtn.c 
b/drivers/input/keyboard/dc_ti_pwrbtn.c
new file mode 100644
index ..a0900a440c92
--- /dev/null
+++ b/drivers/input/keyboard/dc_ti_pwrbtn.c
@@ -0,0 +1,85 @@
+/*
+ * Power button driver for Dollar Cove TI PMIC
+ * Copyright (C) 2014 Intel Corp
+ * Copyright (c) 2017 Takashi Iwai 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DC_TI_SIRQ_REG 0x3
+#define SIRQ_PWRBTN_REL(1 << 0)
+
+#define DRIVER_NAME "dc_ti_pwrbtn"
+
+static irqreturn_t dc_ti_pwrbtn_interrupt(int irq, void *dev_id)
+{
+   struct input_dev *pwrbtn_input = dev_id;
+   struct device *dev = pwrbtn_input->dev.parent;
+   struct regmap *regmap = dev_get_drvdata(dev);
+   int state;
+
+   if (!regmap_read(regmap, DC_TI_SIRQ_REG, )) {
+   dev_dbg(dev, "SIRQ_REG=0x%x\n", state);
+   state &= SIRQ_PWRBTN_REL;
+   input_event(pwrbtn_input, EV_KEY, KEY_POWER, !state);
+   input_sync(pwrbtn_input);
+   }
+
+   return IRQ_HANDLED;
+}
+
+static int dc_ti_pwrbtn_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct intel_soc_pmic *pmic = dev_get_drvdata(dev->parent);
+   struct input_dev *pwrbtn_input;
+   int irq;
+   int ret;
+
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0)
+   return -EINVAL;
+   pwrbtn_input = devm_input_allocate_device(dev);
+   if (!pwrbtn_input)
+   return -ENOMEM;
+   pwrbtn_input->name = pdev->name;
+   pwrbtn_input->phys = "dc-ti-power/input0";
+   pwrbtn_input->id.bustype = BUS_HOST;
+   pwrbtn_input->dev.parent = dev;
+   input_set_capability(pwrbtn_input, EV_KEY, KEY_POWER);
+   ret = input_register_device(pwrbtn_input);
+   if (ret)
+   return ret;
+
+   dev_set_drvdata(dev, pmic->regmap);
+
+   ret = devm_request_threaded_irq(dev, irq, NULL, dc_ti_pwrbtn_interrupt,
+   0, KBUILD_MODNAME, pwrbtn_input);
+   if (ret)
+   return ret;
+
+   ret = enable_irq_wake(irq);
+   if (ret)
+   dev_warn(dev, "Can't enable IRQ as wake source: %d\n", ret);
+
+   return 0;
+}
+
+static struct platform_driver dc_ti_pwrbtn_driver = {
+   .driver = {
+   .name = DRIVER_NAME,
+   },
+   .probe  = dc_ti_pwrbtn_probe,
+};
+
+module_platform_driver(dc_ti_pwrbtn_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRIVER_NAME);
-- 
2.14.0

[PATCH 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

2017-08-21 Thread Takashi Iwai

Hi,

this is a patch set to add the support for Dollar Cove TI PMIC found
on some Intel Cherry Trail laptops / tablets.  All drivers are based
on the original code from Intel downstream patches, with lots of
rewrites and cleanups.  MFD driver is implemented as a stand-alone
like a few other variants, and the input driver got a diet in a
minimalistic form.

The patch set has been tested on ASUS E100H and E200H, as well as on
HP x210.


thanks,

Takashi

===

Takashi Iwai (3):
  mfd: Add support for Cherry Trail Dollar Cove TI PMIC
  input/keyboard: Add support for Dollar Cove TI power button
  ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

 drivers/acpi/Kconfig  |   6 ++
 drivers/acpi/Makefile |   1 +
 drivers/acpi/pmic/intel_pmic_dc_ti.c  | 135 
 drivers/input/keyboard/Kconfig|   7 ++
 drivers/input/keyboard/Makefile   |   1 +
 drivers/input/keyboard/dc_ti_pwrbtn.c |  85 +++
 drivers/mfd/Kconfig   |  13 +++
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/intel_soc_pmic_dc_ti.c| 189 ++
 9 files changed, 438 insertions(+)
 create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c
 create mode 100644 drivers/input/keyboard/dc_ti_pwrbtn.c
 create mode 100644 drivers/mfd/intel_soc_pmic_dc_ti.c

-- 
2.14.0

Re: linux-next: manual merge of the tip tree with the iommu tree

2017-08-21 Thread Baoquan He

Hi Stephen,

On 08/22/17 at 01:50pm, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got conflicts in:
> 
>   drivers/iommu/amd_iommu.c
>   drivers/iommu/amd_iommu_init.c
>   drivers/iommu/amd_iommu_proto.h
>   drivers/iommu/amd_iommu_types.h
> 
> between commits:
> 
>   4c232a708be1 ("iommu/amd: Detect pre enabled translation")
>   9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
>   07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
>   daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")
> 
> from the iommu tree and commit:
> 
>   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory 
> encryption")

Could you tell where the above commit is put? I can have a look.

Thanks
Baoquan

> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/iommu/amd_iommu.c
> index 31bce367866c,4ad7e5e31943..
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@@ -1476,10 -1538,10 +1478,10 @@@ static int iommu_map_page(struct protec
>   return -EBUSY;
>   
>   if (count > 1) {
> - __pte = PAGE_SIZE_PTE(phys_addr, page_size);
> + __pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
>  -__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
>  +__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   } else
> - __pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
>  -__pte = __sme_set(phys_addr) | IOMMU_PTE_P | IOMMU_PTE_FC;
> ++__pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   
>   if (prot & IOMMU_PROT_IR)
>   __pte |= IOMMU_PTE_IR;
> diff --cc drivers/iommu/amd_iommu_init.c
> index ff8887ac,2292a6cece76..
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@@ -29,6 -29,8 +29,7 @@@
>   #include 
>   #include 
>   #include 
>  -#include 
> + #include 
>   #include 
>   #include 
>   #include 
> diff --cc drivers/iommu/amd_iommu_proto.h
> index 90e62e9b01c5,3f12fb2338ea..
> --- a/drivers/iommu/amd_iommu_proto.h
> +++ b/drivers/iommu/amd_iommu_proto.h
> @@@ -87,6 -87,14 +87,16 @@@ static inline bool iommu_feature(struc
>   return !!(iommu->features & f);
>   }
>   
> + static inline u64 iommu_virt_to_phys(void *vaddr)
> + {
> + return (u64)__sme_set(virt_to_phys(vaddr));
> + }
> + 
> + static inline void *iommu_phys_to_virt(unsigned long paddr)
> + {
> + return phys_to_virt(__sme_clr(paddr));
> + }
> + 
>  +extern bool translation_pre_enabled(struct amd_iommu *iommu);
>  +extern struct iommu_dev_data *get_dev_data(struct device *dev);
>   #endif /* _ASM_X86_AMD_IOMMU_PROTO_H  */
> diff --cc drivers/iommu/amd_iommu_types.h
> index 5f775fef341c,8591f43c467c..
> --- a/drivers/iommu/amd_iommu_types.h
> +++ b/drivers/iommu/amd_iommu_types.h
> @@@ -361,8 -343,8 +361,8 @@@
>   #define GCR3_VALID  0x01ULL
>   
>   #define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
>  -#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
>  +#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
> - #define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
> + #define IOMMU_PTE_PAGE(pte) (iommu_phys_to_virt((pte) & IOMMU_PAGE_MASK))
>   #define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
>   
>   #define IOMMU_PROT_MASK 0x03

[PATCH 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

2017-08-21 Thread Takashi Iwai

Hi,

this is a patch set to add the support for Dollar Cove TI PMIC found
on some Intel Cherry Trail laptops / tablets.  All drivers are based
on the original code from Intel downstream patches, with lots of
rewrites and cleanups.  MFD driver is implemented as a stand-alone
like a few other variants, and the input driver got a diet in a
minimalistic form.

The patch set has been tested on ASUS E100H and E200H, as well as on
HP x210.


thanks,

Takashi

===

Takashi Iwai (3):
  mfd: Add support for Cherry Trail Dollar Cove TI PMIC
  input/keyboard: Add support for Dollar Cove TI power button
  ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

 drivers/acpi/Kconfig  |   6 ++
 drivers/acpi/Makefile |   1 +
 drivers/acpi/pmic/intel_pmic_dc_ti.c  | 135 
 drivers/input/keyboard/Kconfig|   7 ++
 drivers/input/keyboard/Makefile   |   1 +
 drivers/input/keyboard/dc_ti_pwrbtn.c |  85 +++
 drivers/mfd/Kconfig   |  13 +++
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/intel_soc_pmic_dc_ti.c| 189 ++
 9 files changed, 438 insertions(+)
 create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c
 create mode 100644 drivers/input/keyboard/dc_ti_pwrbtn.c
 create mode 100644 drivers/mfd/intel_soc_pmic_dc_ti.c

-- 
2.14.0

Re: linux-next: manual merge of the tip tree with the iommu tree

2017-08-21 Thread Baoquan He

Hi Stephen,

On 08/22/17 at 01:50pm, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got conflicts in:
> 
>   drivers/iommu/amd_iommu.c
>   drivers/iommu/amd_iommu_init.c
>   drivers/iommu/amd_iommu_proto.h
>   drivers/iommu/amd_iommu_types.h
> 
> between commits:
> 
>   4c232a708be1 ("iommu/amd: Detect pre enabled translation")
>   9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
>   07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
>   daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")
> 
> from the iommu tree and commit:
> 
>   2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory 
> encryption")

Could you tell where the above commit is put? I can have a look.

Thanks
Baoquan

> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/iommu/amd_iommu.c
> index 31bce367866c,4ad7e5e31943..
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@@ -1476,10 -1538,10 +1478,10 @@@ static int iommu_map_page(struct protec
>   return -EBUSY;
>   
>   if (count > 1) {
> - __pte = PAGE_SIZE_PTE(phys_addr, page_size);
> + __pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
>  -__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
>  +__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   } else
> - __pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
>  -__pte = __sme_set(phys_addr) | IOMMU_PTE_P | IOMMU_PTE_FC;
> ++__pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
>   
>   if (prot & IOMMU_PROT_IR)
>   __pte |= IOMMU_PTE_IR;
> diff --cc drivers/iommu/amd_iommu_init.c
> index ff8887ac,2292a6cece76..
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@@ -29,6 -29,8 +29,7 @@@
>   #include 
>   #include 
>   #include 
>  -#include 
> + #include 
>   #include 
>   #include 
>   #include 
> diff --cc drivers/iommu/amd_iommu_proto.h
> index 90e62e9b01c5,3f12fb2338ea..
> --- a/drivers/iommu/amd_iommu_proto.h
> +++ b/drivers/iommu/amd_iommu_proto.h
> @@@ -87,6 -87,14 +87,16 @@@ static inline bool iommu_feature(struc
>   return !!(iommu->features & f);
>   }
>   
> + static inline u64 iommu_virt_to_phys(void *vaddr)
> + {
> + return (u64)__sme_set(virt_to_phys(vaddr));
> + }
> + 
> + static inline void *iommu_phys_to_virt(unsigned long paddr)
> + {
> + return phys_to_virt(__sme_clr(paddr));
> + }
> + 
>  +extern bool translation_pre_enabled(struct amd_iommu *iommu);
>  +extern struct iommu_dev_data *get_dev_data(struct device *dev);
>   #endif /* _ASM_X86_AMD_IOMMU_PROTO_H  */
> diff --cc drivers/iommu/amd_iommu_types.h
> index 5f775fef341c,8591f43c467c..
> --- a/drivers/iommu/amd_iommu_types.h
> +++ b/drivers/iommu/amd_iommu_types.h
> @@@ -361,8 -343,8 +361,8 @@@
>   #define GCR3_VALID  0x01ULL
>   
>   #define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
>  -#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
>  +#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
> - #define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
> + #define IOMMU_PTE_PAGE(pte) (iommu_phys_to_virt((pte) & IOMMU_PAGE_MASK))
>   #define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
>   
>   #define IOMMU_PROT_MASK 0x03

[PATCH 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

2017-08-21 Thread Takashi Iwai

This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
Cherry Trail devices.  The patch is based on the original work by
Intel, found at:
  https://github.com/01org/ProductionKernelQuilts
with many cleanups and rewrites.

The driver is currently provided only as built-in to follow other
PMIC opregion drivers convention.

The re-enumeration of devices at probe is required for fixing the
issues on HP x2 210 G2.  See bug#195689.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689
Signed-off-by: Takashi Iwai 
---
 drivers/acpi/Kconfig |   6 ++
 drivers/acpi/Makefile|   1 +
 drivers/acpi/pmic/intel_pmic_dc_ti.c | 135 +++
 3 files changed, 142 insertions(+)
 create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f84dc23..9da8dcefde7b 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -521,6 +521,12 @@ config CHT_WC_PMIC_OPREGION
help
  This config adds ACPI operation region support for CHT Whiskey Cove 
PMIC.
 
+config DC_TI_PMIC_OPREGION
+   bool "ACPI operation region support for Dollar Cove TI PMIC"
+   depends on INTEL_SOC_PMIC_DC_TI
+   help
+ This config adds ACPI operation region support for Dollar Cove TI 
PMIC.
+
 endif
 
 config ACPI_CONFIGFS
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b1aacfc62b1f..0a9008b971af 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
 obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
 obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += pmic/intel_pmic_chtwc.o
+obj-$(CONFIG_DC_TI_PMIC_OPREGION) += pmic/intel_pmic_dc_ti.o
 
 obj-$(CONFIG_ACPI_CONFIGFS)+= acpi_configfs.o
 
diff --git a/drivers/acpi/pmic/intel_pmic_dc_ti.c 
b/drivers/acpi/pmic/intel_pmic_dc_ti.c
new file mode 100644
index ..236ff31c5a79
--- /dev/null
+++ b/drivers/acpi/pmic/intel_pmic_dc_ti.c
@@ -0,0 +1,135 @@
+/*
+ * intel_pmic_dc_ti.c - TI Dollar Cove PMIC operation region driver
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ * Rewritten and cleaned up
+ * Copyright (C) 2017 Takashi Iwai 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "intel_pmic.h"
+
+#define TI_DC_PMICTEMP_LOW 0x57
+#define TI_DC_BATTEMP_LOW  0x59
+#define TI_DC_GPADC_LOW0x5b
+
+static struct pmic_table dc_ti_power_table[] = {
+   { .address = 0x00, .reg = 0x41 },
+   { .address = 0x04, .reg = 0x42 },
+   { .address = 0x08, .reg = 0x43 },
+   { .address = 0x0c, .reg = 0x45 },
+   { .address = 0x10, .reg = 0x46 },
+   { .address = 0x14, .reg = 0x47 },
+   { .address = 0x18, .reg = 0x48 },
+   { .address = 0x1c, .reg = 0x49 },
+   { .address = 0x20, .reg = 0x4a },
+   { .address = 0x24, .reg = 0x4b },
+   { .address = 0x28, .reg = 0x4c },
+   { .address = 0x2c, .reg = 0x4d },
+   { .address = 0x30, .reg = 0x4e },
+};
+
+static struct pmic_table dc_ti_thermal_table[] = {
+   {
+   .address = 0x00,
+   .reg = TI_DC_GPADC_LOW
+   },
+   {
+   .address = 0x0c,
+   .reg = TI_DC_GPADC_LOW
+   },
+   /* TMP2 -> SYSTEMP */
+   {
+   .address = 0x18,
+   .reg = TI_DC_GPADC_LOW
+   },
+   /* TMP3 -> BATTEMP */
+   {
+   .address = 0x24,
+   .reg = TI_DC_BATTEMP_LOW
+   },
+   {
+   .address = 0x30,
+   .reg = TI_DC_GPADC_LOW
+   },
+   /* TMP5 -> PMICTEMP */
+   {
+   .address = 0x3c,
+   .reg = TI_DC_PMICTEMP_LOW
+   },
+};
+
+static int dc_ti_pmic_get_power(struct regmap *regmap, int reg, int bit,
+   u64 *value)
+{
+   int data;
+
+   if (regmap_read(regmap, reg, ))
+   return -EIO;
+
+   *value = data & 1;
+   return 0;
+}
+
+static int dc_ti_pmic_update_power(struct regmap *regmap, int reg, int bit,
+  bool on)
+{
+   return regmap_update_bits(regmap, reg, 1, on);
+}
+
+static int dc_ti_pmic_get_raw_temp(struct regmap *regmap, int reg)
+{
+   int temp_l, temp_h;
+
+   if (regmap_read(regmap, reg, _l) ||
+   regmap_read(regmap, reg - 1, _h))
+   return -EIO;
+
+   return temp_l | (temp_h & 0x3) << 8;
+}
+
+static struct intel_pmic_opregion_data dc_ti_pmic_opregion_data = {
+   .get_power = dc_ti_pmic_get_power,
+   .update_power = dc_ti_pmic_update_power,
+   .get_raw_temp = dc_ti_pmic_get_raw_temp,
+   .power_table = dc_ti_power_table,
+   .power_table_count = ARRAY_SIZE(dc_ti_power_table),
+   .thermal_table =

[PATCH 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

2017-08-21 Thread Takashi Iwai

This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
Cherry Trail devices.  The patch is based on the original work by
Intel, found at:
  https://github.com/01org/ProductionKernelQuilts
with many cleanups and rewrites.

The driver is currently provided only as built-in to follow other
PMIC opregion drivers convention.

The re-enumeration of devices at probe is required for fixing the
issues on HP x2 210 G2.  See bug#195689.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689
Signed-off-by: Takashi Iwai 
---
 drivers/acpi/Kconfig |   6 ++
 drivers/acpi/Makefile|   1 +
 drivers/acpi/pmic/intel_pmic_dc_ti.c | 135 +++
 3 files changed, 142 insertions(+)
 create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f84dc23..9da8dcefde7b 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -521,6 +521,12 @@ config CHT_WC_PMIC_OPREGION
help
  This config adds ACPI operation region support for CHT Whiskey Cove 
PMIC.
 
+config DC_TI_PMIC_OPREGION
+   bool "ACPI operation region support for Dollar Cove TI PMIC"
+   depends on INTEL_SOC_PMIC_DC_TI
+   help
+ This config adds ACPI operation region support for Dollar Cove TI 
PMIC.
+
 endif
 
 config ACPI_CONFIGFS
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b1aacfc62b1f..0a9008b971af 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
 obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
 obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += pmic/intel_pmic_chtwc.o
+obj-$(CONFIG_DC_TI_PMIC_OPREGION) += pmic/intel_pmic_dc_ti.o
 
 obj-$(CONFIG_ACPI_CONFIGFS)+= acpi_configfs.o
 
diff --git a/drivers/acpi/pmic/intel_pmic_dc_ti.c 
b/drivers/acpi/pmic/intel_pmic_dc_ti.c
new file mode 100644
index ..236ff31c5a79
--- /dev/null
+++ b/drivers/acpi/pmic/intel_pmic_dc_ti.c
@@ -0,0 +1,135 @@
+/*
+ * intel_pmic_dc_ti.c - TI Dollar Cove PMIC operation region driver
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ * Rewritten and cleaned up
+ * Copyright (C) 2017 Takashi Iwai 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "intel_pmic.h"
+
+#define TI_DC_PMICTEMP_LOW 0x57
+#define TI_DC_BATTEMP_LOW  0x59
+#define TI_DC_GPADC_LOW0x5b
+
+static struct pmic_table dc_ti_power_table[] = {
+   { .address = 0x00, .reg = 0x41 },
+   { .address = 0x04, .reg = 0x42 },
+   { .address = 0x08, .reg = 0x43 },
+   { .address = 0x0c, .reg = 0x45 },
+   { .address = 0x10, .reg = 0x46 },
+   { .address = 0x14, .reg = 0x47 },
+   { .address = 0x18, .reg = 0x48 },
+   { .address = 0x1c, .reg = 0x49 },
+   { .address = 0x20, .reg = 0x4a },
+   { .address = 0x24, .reg = 0x4b },
+   { .address = 0x28, .reg = 0x4c },
+   { .address = 0x2c, .reg = 0x4d },
+   { .address = 0x30, .reg = 0x4e },
+};
+
+static struct pmic_table dc_ti_thermal_table[] = {
+   {
+   .address = 0x00,
+   .reg = TI_DC_GPADC_LOW
+   },
+   {
+   .address = 0x0c,
+   .reg = TI_DC_GPADC_LOW
+   },
+   /* TMP2 -> SYSTEMP */
+   {
+   .address = 0x18,
+   .reg = TI_DC_GPADC_LOW
+   },
+   /* TMP3 -> BATTEMP */
+   {
+   .address = 0x24,
+   .reg = TI_DC_BATTEMP_LOW
+   },
+   {
+   .address = 0x30,
+   .reg = TI_DC_GPADC_LOW
+   },
+   /* TMP5 -> PMICTEMP */
+   {
+   .address = 0x3c,
+   .reg = TI_DC_PMICTEMP_LOW
+   },
+};
+
+static int dc_ti_pmic_get_power(struct regmap *regmap, int reg, int bit,
+   u64 *value)
+{
+   int data;
+
+   if (regmap_read(regmap, reg, ))
+   return -EIO;
+
+   *value = data & 1;
+   return 0;
+}
+
+static int dc_ti_pmic_update_power(struct regmap *regmap, int reg, int bit,
+  bool on)
+{
+   return regmap_update_bits(regmap, reg, 1, on);
+}
+
+static int dc_ti_pmic_get_raw_temp(struct regmap *regmap, int reg)
+{
+   int temp_l, temp_h;
+
+   if (regmap_read(regmap, reg, _l) ||
+   regmap_read(regmap, reg - 1, _h))
+   return -EIO;
+
+   return temp_l | (temp_h & 0x3) << 8;
+}
+
+static struct intel_pmic_opregion_data dc_ti_pmic_opregion_data = {
+   .get_power = dc_ti_pmic_get_power,
+   .update_power = dc_ti_pmic_update_power,
+   .get_raw_temp = dc_ti_pmic_get_raw_temp,
+   .power_table = dc_ti_power_table,
+   .power_table_count = ARRAY_SIZE(dc_ti_power_table),
+   .thermal_table = dc_ti_thermal_table,
+

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

2017-08-21 Thread Byungchul Park

On Mon, Aug 21, 2017 at 03:07:57PM +0100, Juri Lelli wrote:
> > Consider a 4 core, SMT2 system:
> > 
> > LLC [0 - 7]
> > 
> > SMT [0,1] [2,3] [4,5] [6,7]
> > 
> > If we do a wake-up on CPU0, we'll find CPU1, mark that as fallback,
> > continue up the domain tree, exclude 0,1 from 0-7 and find CPU2.
> > 
> > A next wakeup on CPU0 does the same and will find CPU3, fully loading
> > that core, instead of considering CPU4 first.
> > 
> 
> Ah, right, I see. Thanks for explaining.
> 
> Byungchul, maybe you could add this explanation as a comment?

Yes. Good idea. I will add it.

Thank you,
Byungchul

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

2017-08-21 Thread Byungchul Park

On Mon, Aug 21, 2017 at 03:07:57PM +0100, Juri Lelli wrote:
> > Consider a 4 core, SMT2 system:
> > 
> > LLC [0 - 7]
> > 
> > SMT [0,1] [2,3] [4,5] [6,7]
> > 
> > If we do a wake-up on CPU0, we'll find CPU1, mark that as fallback,
> > continue up the domain tree, exclude 0,1 from 0-7 and find CPU2.
> > 
> > A next wakeup on CPU0 does the same and will find CPU3, fully loading
> > that core, instead of considering CPU4 first.
> > 
> 
> Ah, right, I see. Thanks for explaining.
> 
> Byungchul, maybe you could add this explanation as a comment?

Yes. Good idea. I will add it.

Thank you,
Byungchul

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

2017-08-21 Thread Byungchul Park

On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote:
> Hi,
> On 18/08/17 17:21, Byungchul Park wrote:
> > It would be better to try to check other siblings first if
> > SD_PREFER_SIBLING is flaged when pushing tasks - migration.
> > 
> > Signed-off-by: Byungchul Park 
> 
> Mmm, this looks like Peter's proposed patch, maybe add (at least) a
> Suggested-by: him ?

Hi Juri,

Why not. I will add it from the next spin.

BTW, is it enough? I don't know the way I should do, whenever I got
thankful suggestions. I really want to add them as a separate patch
which can be stacked on my patches _if possible_. But in case that
it's better to merge them into one like this, I don't know how.

I mean I will add 'Suggested-by' from now on - I learned what I should
do (at least) in this case thanks to Juri, but I'm still not sure if
it's enough.

Speaking of which, I have something to ask Peterz and Ingo for. I really
want to interact with maintainers actively e.g. asking ways they prefer.
But it takes too much long to get responses from them e.g. at most 2
monthes in case rushing them. I should have decided and done what the
best I think is, than asking.

It would be very appriciated if you pay more attention.

> > @@ -1376,8 +1399,7 @@ static int find_later_rq(struct task_struct *task)
> > return this_cpu;
> > }
> >  
> > -   best_cpu = cpumask_first_and(later_mask,
> > -   sched_domain_span(sd));
> > +   best_cpu = find_cpu(later_mask, sd, prefer);
> > /*
> >  * Last chance: if a cpu being in both later_mask
> >  * and current sd span is valid, that becomes our
> > @@ -1385,6 +1407,26 @@ static int find_later_rq(struct task_struct *task)
> >  * already under consideration through later_mask.
> >  */
> 
> It seems that the comment above should be updated as well.

How? Could you explain it more?

Thanks,
Byungchul

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

2017-08-21 Thread Byungchul Park

On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote:
> Hi,
> On 18/08/17 17:21, Byungchul Park wrote:
> > It would be better to try to check other siblings first if
> > SD_PREFER_SIBLING is flaged when pushing tasks - migration.
> > 
> > Signed-off-by: Byungchul Park 
> 
> Mmm, this looks like Peter's proposed patch, maybe add (at least) a
> Suggested-by: him ?

Hi Juri,

Why not. I will add it from the next spin.

BTW, is it enough? I don't know the way I should do, whenever I got
thankful suggestions. I really want to add them as a separate patch
which can be stacked on my patches _if possible_. But in case that
it's better to merge them into one like this, I don't know how.

I mean I will add 'Suggested-by' from now on - I learned what I should
do (at least) in this case thanks to Juri, but I'm still not sure if
it's enough.

Speaking of which, I have something to ask Peterz and Ingo for. I really
want to interact with maintainers actively e.g. asking ways they prefer.
But it takes too much long to get responses from them e.g. at most 2
monthes in case rushing them. I should have decided and done what the
best I think is, than asking.

It would be very appriciated if you pay more attention.

> > @@ -1376,8 +1399,7 @@ static int find_later_rq(struct task_struct *task)
> > return this_cpu;
> > }
> >  
> > -   best_cpu = cpumask_first_and(later_mask,
> > -   sched_domain_span(sd));
> > +   best_cpu = find_cpu(later_mask, sd, prefer);
> > /*
> >  * Last chance: if a cpu being in both later_mask
> >  * and current sd span is valid, that becomes our
> > @@ -1385,6 +1407,26 @@ static int find_later_rq(struct task_struct *task)
> >  * already under consideration through later_mask.
> >  */
> 
> It seems that the comment above should be updated as well.

How? Could you explain it more?

Thanks,
Byungchul

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

2017-08-21 Thread Dave Chinner

On Mon, Aug 21, 2017 at 05:46:00PM +0200, Peter Zijlstra wrote:
> 
> 
> Booting the very latest -tip on my test machine gets me the below splat.
> 
> Dave, TJ, FYI, lockdep grew annotations for completions; it remembers
> which locks were taken before we complete() and checks none of those are
> held while we wait_for_completion().
> 
> That is, something like:
> 
>   mutex_lock();
>   mutex_unlock();
>   complete();
> 
>   mutex_lock();
>   wait_for_completion();

Ok, that seems reasonable...

> Is now considered a problem. Note that in order for C to link to A it
> needs to have observed the complete() thread acquiring it after a
> wait_for_completion(), something like:
> 
>   wait_for_completion()
>   mutex_lock();
>   mutex_unlock();
>   complete();

Sure.

> 
> That is, only locks observed taken between C's wait_for_completion() and
> it's complete() are considered.
> 
> Now given the above observance rule and the fact that the below report
> is from the complete, the thing that happened appears to be:
> 
> 
>   lockdep_map_acquire(>lockdep_map)
>   down_write()
> 
>   down_write()
>   wait_for_completion()
> 
>   lockdep_map_acquire(_lockdep_map);
>   complete()
> 
> Which lockdep then puked over because both sides saw the same work
> class.

Let me get this straight, first. If we:

1. take a lock in a work queue context; and
2. in a separate context, hold that lock while we wait for a
completion; and
3. Run the completion from the original workqueue where we
/once/ held that lock

lockdep will barf?

IIUC, that's a problem because XFS does this all over the place.
Let me pull the trace apart in reverse order to explain why XFS is
going to throw endless false positives on this:

> [   39.159708] -> #0 ((>io_work)){+.+.}:
> [   39.166126]process_one_work+0x244/0x6b0
> [   39.171184]worker_thread+0x48/0x3f0
> [   39.175845]kthread+0x147/0x180
> [   39.180020]ret_from_fork+0x2a/0x40
> [   39.184593]0x

That's a data IO completion, which will take an inode lock if we
have to run a transaction to update inode size or convert an
unwritten extent.

> [   39.100611] -> #1 (_nondir_ilock_class){}:
> [   39.107612]__lock_acquire+0x10a1/0x1100
> [   39.112660]lock_acquire+0xea/0x1f0
> [   39.117224]down_write_nested+0x26/0x60
> [   39.122184]xfs_ilock+0x166/0x220
> [   39.126563]__xfs_setfilesize+0x30/0x200
> [   39.131612]xfs_setfilesize_ioend+0x7f/0xb0
> [   39.136958]xfs_end_io+0x49/0xf0
> [   39.141240]process_one_work+0x273/0x6b0
> [   39.146288]worker_thread+0x48/0x3f0
> [   39.150960]kthread+0x147/0x180
> [   39.155146]ret_from_fork+0x2a/0x40

That's the data IO completion locking the inode inside a transaction
to update the inode size inside a workqueue.


> [   38.962397] -> #2 ((complete)>b_iowait){+.+.}:
> [   38.969401]__lock_acquire+0x10a1/0x1100
> [   38.974460]lock_acquire+0xea/0x1f0
> [   38.979036]wait_for_completion+0x3b/0x130
> [   38.984285]xfs_buf_submit_wait+0xb2/0x590
> [   38.989535]_xfs_buf_read+0x23/0x30
> [   38.994108]xfs_buf_read_map+0x14f/0x320
> [   38.999169]xfs_trans_read_buf_map+0x170/0x5d0
> [   39.004812]xfs_read_agf+0x97/0x1d0
> [   39.009386]xfs_alloc_read_agf+0x60/0x240
> [   39.014541]xfs_alloc_fix_freelist+0x32a/0x3d0
> [   39.020180]xfs_free_extent_fix_freelist+0x6b/0xa0
> [   39.026206]xfs_free_extent+0x48/0x120
> [   39.031068]xfs_trans_free_extent+0x57/0x200
> [   39.036512]xfs_extent_free_finish_item+0x26/0x40
> [   39.042442]xfs_defer_finish+0x174/0x770
> [   39.047494]xfs_itruncate_extents+0x126/0x470
> [   39.053035]xfs_setattr_size+0x2a1/0x310
> [   39.058093]xfs_vn_setattr_size+0x57/0x160
> [   39.063342]xfs_vn_setattr+0x50/0x70
> [   39.068015]notify_change+0x2ee/0x420
> [   39.072785]do_truncate+0x5d/0x90
> [   39.077165]path_openat+0xab2/0xc00
> [   39.081737]do_filp_open+0x8a/0xf0
> [   39.086213]do_sys_open+0x123/0x200
> [   39.090787]SyS_open+0x1e/0x20
> [   39.094876]entry_SYSCALL_64_fastpath+0x23/0xc2

And that's waiting for a metadata read IO to complete during a
truncate transaction. This has no direct connection to the inode at
all - it's a allocation group header that we have to lock to do
block allocation. The completion it is waiting on doesn't even run
through the same workqueue as the ioends - ioends go through

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

2017-08-21 Thread Dave Chinner

On Mon, Aug 21, 2017 at 05:46:00PM +0200, Peter Zijlstra wrote:
> 
> 
> Booting the very latest -tip on my test machine gets me the below splat.
> 
> Dave, TJ, FYI, lockdep grew annotations for completions; it remembers
> which locks were taken before we complete() and checks none of those are
> held while we wait_for_completion().
> 
> That is, something like:
> 
>   mutex_lock();
>   mutex_unlock();
>   complete();
> 
>   mutex_lock();
>   wait_for_completion();

Ok, that seems reasonable...

> Is now considered a problem. Note that in order for C to link to A it
> needs to have observed the complete() thread acquiring it after a
> wait_for_completion(), something like:
> 
>   wait_for_completion()
>   mutex_lock();
>   mutex_unlock();
>   complete();

Sure.

> 
> That is, only locks observed taken between C's wait_for_completion() and
> it's complete() are considered.
> 
> Now given the above observance rule and the fact that the below report
> is from the complete, the thing that happened appears to be:
> 
> 
>   lockdep_map_acquire(>lockdep_map)
>   down_write()
> 
>   down_write()
>   wait_for_completion()
> 
>   lockdep_map_acquire(_lockdep_map);
>   complete()
> 
> Which lockdep then puked over because both sides saw the same work
> class.

Let me get this straight, first. If we:

1. take a lock in a work queue context; and
2. in a separate context, hold that lock while we wait for a
completion; and
3. Run the completion from the original workqueue where we
/once/ held that lock

lockdep will barf?

IIUC, that's a problem because XFS does this all over the place.
Let me pull the trace apart in reverse order to explain why XFS is
going to throw endless false positives on this:

> [   39.159708] -> #0 ((>io_work)){+.+.}:
> [   39.166126]process_one_work+0x244/0x6b0
> [   39.171184]worker_thread+0x48/0x3f0
> [   39.175845]kthread+0x147/0x180
> [   39.180020]ret_from_fork+0x2a/0x40
> [   39.184593]0x

That's a data IO completion, which will take an inode lock if we
have to run a transaction to update inode size or convert an
unwritten extent.

> [   39.100611] -> #1 (_nondir_ilock_class){}:
> [   39.107612]__lock_acquire+0x10a1/0x1100
> [   39.112660]lock_acquire+0xea/0x1f0
> [   39.117224]down_write_nested+0x26/0x60
> [   39.122184]xfs_ilock+0x166/0x220
> [   39.126563]__xfs_setfilesize+0x30/0x200
> [   39.131612]xfs_setfilesize_ioend+0x7f/0xb0
> [   39.136958]xfs_end_io+0x49/0xf0
> [   39.141240]process_one_work+0x273/0x6b0
> [   39.146288]worker_thread+0x48/0x3f0
> [   39.150960]kthread+0x147/0x180
> [   39.155146]ret_from_fork+0x2a/0x40

That's the data IO completion locking the inode inside a transaction
to update the inode size inside a workqueue.


> [   38.962397] -> #2 ((complete)>b_iowait){+.+.}:
> [   38.969401]__lock_acquire+0x10a1/0x1100
> [   38.974460]lock_acquire+0xea/0x1f0
> [   38.979036]wait_for_completion+0x3b/0x130
> [   38.984285]xfs_buf_submit_wait+0xb2/0x590
> [   38.989535]_xfs_buf_read+0x23/0x30
> [   38.994108]xfs_buf_read_map+0x14f/0x320
> [   38.999169]xfs_trans_read_buf_map+0x170/0x5d0
> [   39.004812]xfs_read_agf+0x97/0x1d0
> [   39.009386]xfs_alloc_read_agf+0x60/0x240
> [   39.014541]xfs_alloc_fix_freelist+0x32a/0x3d0
> [   39.020180]xfs_free_extent_fix_freelist+0x6b/0xa0
> [   39.026206]xfs_free_extent+0x48/0x120
> [   39.031068]xfs_trans_free_extent+0x57/0x200
> [   39.036512]xfs_extent_free_finish_item+0x26/0x40
> [   39.042442]xfs_defer_finish+0x174/0x770
> [   39.047494]xfs_itruncate_extents+0x126/0x470
> [   39.053035]xfs_setattr_size+0x2a1/0x310
> [   39.058093]xfs_vn_setattr_size+0x57/0x160
> [   39.063342]xfs_vn_setattr+0x50/0x70
> [   39.068015]notify_change+0x2ee/0x420
> [   39.072785]do_truncate+0x5d/0x90
> [   39.077165]path_openat+0xab2/0xc00
> [   39.081737]do_filp_open+0x8a/0xf0
> [   39.086213]do_sys_open+0x123/0x200
> [   39.090787]SyS_open+0x1e/0x20
> [   39.094876]entry_SYSCALL_64_fastpath+0x23/0xc2

And that's waiting for a metadata read IO to complete during a
truncate transaction. This has no direct connection to the inode at
all - it's a allocation group header that we have to lock to do
block allocation. The completion it is waiting on doesn't even run
through the same workqueue as the ioends - ioends go through

Re: linux-next: manual merge of the l2-mtd tree with the kbuild-current tree

2017-08-21 Thread Masahiro Yamada

Hi Boris,


2017-08-22 14:37 GMT+09:00 Boris Brezillon :
> Le Tue, 22 Aug 2017 11:56:14 +1000,
> Stephen Rothwell  a écrit :
>
>> Hi Brian,
>>
>> Today's linux-next merge of the l2-mtd tree got a conflict in:
>>
>>   include/asm-generic/vmlinux.lds.h
>>
>> between commit:
>>
>>   cb87481ee89d ("kbuild: linker script do not match C names unless 
>> LD_DEAD_CODE_DATA_ELIMINATION is configured")
>
> Masahiro, according to this message [1], you queued the above patch to
> your fixes branch. Do you plan to send a fixes PR to Linus before
> -rc7?


Yes.  I am planning to do so.




> If that's the case I'll merge -rc7 in l2-mtd/master, otherwise
> I'll need an immutable branch.
>

-- 
Best Regards
Masahiro Yamada

Re: linux-next: manual merge of the l2-mtd tree with the kbuild-current tree

2017-08-21 Thread Masahiro Yamada

Hi Boris,


2017-08-22 14:37 GMT+09:00 Boris Brezillon :
> Le Tue, 22 Aug 2017 11:56:14 +1000,
> Stephen Rothwell  a écrit :
>
>> Hi Brian,
>>
>> Today's linux-next merge of the l2-mtd tree got a conflict in:
>>
>>   include/asm-generic/vmlinux.lds.h
>>
>> between commit:
>>
>>   cb87481ee89d ("kbuild: linker script do not match C names unless 
>> LD_DEAD_CODE_DATA_ELIMINATION is configured")
>
> Masahiro, according to this message [1], you queued the above patch to
> your fixes branch. Do you plan to send a fixes PR to Linus before
> -rc7?


Yes.  I am planning to do so.




> If that's the case I'll merge -rc7 in l2-mtd/master, otherwise
> I'll need an immutable branch.
>

-- 
Best Regards
Masahiro Yamada

Re: qustion about eeh_add_virt_device

2017-08-21 Thread Russell Currey

On Sun, 2017-08-13 at 16:54 +0200, Julia Lawall wrote:
> Hello,

Hello, sorry for the delayed response.

> 
> At the suggestion of Christoph Hellwig, I am working on inlining the
> functions stored in the err_handler field of a pci_driver structure into
> the pci_driver structure itself.  A number of functions in the file
> arch/powerpc/kernel/eeh_driver.c have code like:
> 
> if (!driver->err_handler ||
> !driver->err_handler->error_detected) {
> eeh_pcid_put(dev);
> return NULL;
> }
> 
> This I would just convert to:
> 
> if (!driver->error_detected) {
> eeh_pcid_put(dev);
> return NULL;
> }
> 
> But I am not sure what is best to do about eeh_add_virt_device, which
> contains:
> 
> if (driver->err_handler)
>   return NULL;
> 
> Should I try to find a subfield of the err_handler that is guaranteed to
> be there if anything is there?  Or could the test just be dropped, leaving
> a direct return NULL?

I believe the test can be dropped.

- Russell

> 
> thanks,
> julia

Re: qustion about eeh_add_virt_device

2017-08-21 Thread Russell Currey

On Sun, 2017-08-13 at 16:54 +0200, Julia Lawall wrote:
> Hello,

Hello, sorry for the delayed response.

> 
> At the suggestion of Christoph Hellwig, I am working on inlining the
> functions stored in the err_handler field of a pci_driver structure into
> the pci_driver structure itself.  A number of functions in the file
> arch/powerpc/kernel/eeh_driver.c have code like:
> 
> if (!driver->err_handler ||
> !driver->err_handler->error_detected) {
> eeh_pcid_put(dev);
> return NULL;
> }
> 
> This I would just convert to:
> 
> if (!driver->error_detected) {
> eeh_pcid_put(dev);
> return NULL;
> }
> 
> But I am not sure what is best to do about eeh_add_virt_device, which
> contains:
> 
> if (driver->err_handler)
>   return NULL;
> 
> Should I try to find a subfield of the err_handler that is guaranteed to
> be there if anything is there?  Or could the test just be dropped, leaving
> a direct return NULL?

I believe the test can be dropped.

- Russell

> 
> thanks,
> julia

Re: linux-next: manual merge of the l2-mtd tree with the kbuild-current tree

2017-08-21 Thread Boris Brezillon

Le Tue, 22 Aug 2017 11:56:14 +1000,
Stephen Rothwell  a écrit :

> Hi Brian,
> 
> Today's linux-next merge of the l2-mtd tree got a conflict in:
> 
>   include/asm-generic/vmlinux.lds.h
> 
> between commit:
> 
>   cb87481ee89d ("kbuild: linker script do not match C names unless 
> LD_DEAD_CODE_DATA_ELIMINATION is configured")

Masahiro, according to this message [1], you queued the above patch to
your fixes branch. Do you plan to send a fixes PR to Linus before
-rc7? If that's the case I'll merge -rc7 in l2-mtd/master, otherwise
I'll need an immutable branch.

Thanks,

Boris

[1]https://www.spinics.net/lists/arm-kernel/msg599088.html

> 
> from the kbuild-current tree and commit:
> 
>   129f6c4820dd ("mtd: only use __xipram annotation when XIP_KERNEL is set")
> 
> from the l2-mtd tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>

Re: linux-next: manual merge of the l2-mtd tree with the kbuild-current tree

2017-08-21 Thread Boris Brezillon

Le Tue, 22 Aug 2017 11:56:14 +1000,
Stephen Rothwell  a écrit :

> Hi Brian,
> 
> Today's linux-next merge of the l2-mtd tree got a conflict in:
> 
>   include/asm-generic/vmlinux.lds.h
> 
> between commit:
> 
>   cb87481ee89d ("kbuild: linker script do not match C names unless 
> LD_DEAD_CODE_DATA_ELIMINATION is configured")

Masahiro, according to this message [1], you queued the above patch to
your fixes branch. Do you plan to send a fixes PR to Linus before
-rc7? If that's the case I'll merge -rc7 in l2-mtd/master, otherwise
I'll need an immutable branch.

Thanks,

Boris

[1]https://www.spinics.net/lists/arm-kernel/msg599088.html

> 
> from the kbuild-current tree and commit:
> 
>   129f6c4820dd ("mtd: only use __xipram annotation when XIP_KERNEL is set")
> 
> from the l2-mtd tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>

linux-next: build failure after merge of the slave-dma tree

2017-08-21 Thread Stephen Rothwell

Hi Vinod,

After merging the slave-dma tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from drivers/dma/dmaengine.h:9:0,
 from drivers/dma/altera-msgdma.c:27:
drivers/dma/altera-msgdma.c: In function 'msgdma_probe':
drivers/dma/altera-msgdma.c:946:14: error: 'DMA_SG' undeclared (first use in 
this function)
  dma_cap_set(DMA_SG, dma_dev->cap_mask);
  ^
include/linux/dmaengine.h:1197:46: note: in definition of macro 'dma_cap_set'
 #define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask))
  ^
drivers/dma/altera-msgdma.c:946:14: note: each undeclared identifier is 
reported only once for each function it appears in
  dma_cap_set(DMA_SG, dma_dev->cap_mask);
  ^
include/linux/dmaengine.h:1197:46: note: in definition of macro 'dma_cap_set'
 #define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask))
  ^
drivers/dma/altera-msgdma.c:965:9: error: 'struct dma_device' has no member 
named 'device_prep_dma_sg'
  dma_dev->device_prep_dma_sg = msgdma_prep_sg;
 ^

Caused by commit

  a85c6f1b2921 ("dmaengine: Add driver for Altera / Intel mSGDMA IP core")

interacting with commit

  c678fa66341c ("dmaengine: remove DMA_SG as it is dead code in kernel")

This should have been fixed up in the merge commit

  0a0ab6497093 ("Merge branch 'topic/dmatest' into next")

I have used the slave-dma tree from next-20170817 for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the slave-dma tree

2017-08-21 Thread Stephen Rothwell

Hi Vinod,

After merging the slave-dma tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from drivers/dma/dmaengine.h:9:0,
 from drivers/dma/altera-msgdma.c:27:
drivers/dma/altera-msgdma.c: In function 'msgdma_probe':
drivers/dma/altera-msgdma.c:946:14: error: 'DMA_SG' undeclared (first use in 
this function)
  dma_cap_set(DMA_SG, dma_dev->cap_mask);
  ^
include/linux/dmaengine.h:1197:46: note: in definition of macro 'dma_cap_set'
 #define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask))
  ^
drivers/dma/altera-msgdma.c:946:14: note: each undeclared identifier is 
reported only once for each function it appears in
  dma_cap_set(DMA_SG, dma_dev->cap_mask);
  ^
include/linux/dmaengine.h:1197:46: note: in definition of macro 'dma_cap_set'
 #define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask))
  ^
drivers/dma/altera-msgdma.c:965:9: error: 'struct dma_device' has no member 
named 'device_prep_dma_sg'
  dma_dev->device_prep_dma_sg = msgdma_prep_sg;
 ^

Caused by commit

  a85c6f1b2921 ("dmaengine: Add driver for Altera / Intel mSGDMA IP core")

interacting with commit

  c678fa66341c ("dmaengine: remove DMA_SG as it is dead code in kernel")

This should have been fixed up in the merge commit

  0a0ab6497093 ("Merge branch 'topic/dmatest' into next")

I have used the slave-dma tree from next-20170817 for today.

-- 
Cheers,
Stephen Rothwell

[PATCH] storvsc: do not assume SG list is continuous when doing bounce buffers (for 4.1 stable only)

2017-08-21 Thread Long Li

From: Long Li 

This patch is for linux-stable 4.1 branch only.

storvsc checks the SG list for gaps before passing them to Hyper-v device.
If there are gaps, data is copied to a bounce buffer and a continuous data
buffer is passed to Hyper-V.

The check on gaps assumes SG list is continuous, and not chained. This is
 not always true. Failing the check may result in incorrect I/O data
passed to the Hyper-v device.

This code path is not used post Linux 4.1.

Signed-off-by: Long Li 
---
 drivers/scsi/storvsc_drv.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 6c52d14..14dc5c6 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -584,17 +584,18 @@ static int do_bounce_buffer(struct scatterlist *sgl, 
unsigned int sg_count)
for (i = 0; i < sg_count; i++) {
if (i == 0) {
/* make sure 1st one does not have hole */
-   if (sgl[i].offset + sgl[i].length != PAGE_SIZE)
+   if (sgl->offset + sgl->length != PAGE_SIZE)
return i;
} else if (i == sg_count - 1) {
/* make sure last one does not have hole */
-   if (sgl[i].offset != 0)
+   if (sgl->offset != 0)
return i;
} else {
/* make sure no hole in the middle */
-   if (sgl[i].length != PAGE_SIZE || sgl[i].offset != 0)
+   if (sgl->length != PAGE_SIZE || sgl->offset != 0)
return i;
}
+   sgl = sg_next(sgl);
}
return -1;
 }
-- 
2.7.4

[PATCH] storvsc: do not assume SG list is continuous when doing bounce buffers (for 4.1 stable only)

2017-08-21 Thread Long Li

From: Long Li 

This patch is for linux-stable 4.1 branch only.

storvsc checks the SG list for gaps before passing them to Hyper-v device.
If there are gaps, data is copied to a bounce buffer and a continuous data
buffer is passed to Hyper-V.

The check on gaps assumes SG list is continuous, and not chained. This is
 not always true. Failing the check may result in incorrect I/O data
passed to the Hyper-v device.

This code path is not used post Linux 4.1.

Signed-off-by: Long Li 
---
 drivers/scsi/storvsc_drv.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 6c52d14..14dc5c6 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -584,17 +584,18 @@ static int do_bounce_buffer(struct scatterlist *sgl, 
unsigned int sg_count)
for (i = 0; i < sg_count; i++) {
if (i == 0) {
/* make sure 1st one does not have hole */
-   if (sgl[i].offset + sgl[i].length != PAGE_SIZE)
+   if (sgl->offset + sgl->length != PAGE_SIZE)
return i;
} else if (i == sg_count - 1) {
/* make sure last one does not have hole */
-   if (sgl[i].offset != 0)
+   if (sgl->offset != 0)
return i;
} else {
/* make sure no hole in the middle */
-   if (sgl[i].length != PAGE_SIZE || sgl[i].offset != 0)
+   if (sgl->length != PAGE_SIZE || sgl->offset != 0)
return i;
}
+   sgl = sg_next(sgl);
}
return -1;
 }
-- 
2.7.4

[PATCH v2 3/3] ARM: sunxi: add support for R40 SoC

2017-08-21 Thread Icenowy Zheng

Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
like A20.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Fix alphabetical orders.

 Documentation/arm/sunxi/README  | 6 ++
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 arch/arm/mach-sunxi/sunxi.c | 1 +
 3 files changed, 8 insertions(+)

diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index de791e18ccef..f8efc21998bf 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -76,6 +76,12 @@ SunXi family
 + Datasheet
   http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
 
+  - Allwinner R40 (sun8i)
++ Datasheet
+  https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf
++ User Manual
+  
https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf
+
 * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
   - Allwinner A80
 + Datasheet
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index f35c6ada5a65..e4beec3d9ad3 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h2-plus
   allwinner,sun8i-h3
+  allwinner-sun8i-r40
   allwinner,sun8i-v3s
   allwinner,sun9i-a80
   allwinner,sun50i-a64
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 7ab353fb25f2..5e9602ce1573 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -65,6 +65,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a83t",
"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
+   "allwinner,sun8i-r40",
"allwinner,sun8i-v3s",
NULL,
 };
-- 
2.13.5

[PATCH v2 3/3] ARM: sunxi: add support for R40 SoC

2017-08-21 Thread Icenowy Zheng

Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
like A20.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Fix alphabetical orders.

 Documentation/arm/sunxi/README  | 6 ++
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 arch/arm/mach-sunxi/sunxi.c | 1 +
 3 files changed, 8 insertions(+)

diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index de791e18ccef..f8efc21998bf 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -76,6 +76,12 @@ SunXi family
 + Datasheet
   http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
 
+  - Allwinner R40 (sun8i)
++ Datasheet
+  https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf
++ User Manual
+  
https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf
+
 * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
   - Allwinner A80
 + Datasheet
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index f35c6ada5a65..e4beec3d9ad3 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h2-plus
   allwinner,sun8i-h3
+  allwinner-sun8i-r40
   allwinner,sun8i-v3s
   allwinner,sun9i-a80
   allwinner,sun50i-a64
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 7ab353fb25f2..5e9602ce1573 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -65,6 +65,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a83t",
"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
+   "allwinner,sun8i-r40",
"allwinner,sun8i-v3s",
NULL,
 };
-- 
2.13.5

[PATCH v2 2/3] ARM: sunxi: fix the core number of V3s in sunxi README

2017-08-21 Thread Icenowy Zheng

The Allwinner V3s SoC is not quad-core, but single-core.

Fix this in the README file.

Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng 
---
 Documentation/arm/sunxi/README | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index d7b1f016bd62..de791e18ccef 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -33,6 +33,11 @@ SunXi family
 
   - Next Thing Co GR8 (sun5i)
 
+* Single ARM Cortex-A7 based SoCs
+  - Allwinner V3s (sun8i)
++ Datasheet
+  http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
+
 * Dual ARM Cortex-A7 based SoCs
   - Allwinner A20 (sun7i)
 + User Manual
@@ -71,10 +76,6 @@ SunXi family
 + Datasheet
   http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
 
-  - Allwinner V3s (sun8i)
-+ Datasheet
-  http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
-
 * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
   - Allwinner A80
 + Datasheet
-- 
2.13.5

[PATCH v2 2/3] ARM: sunxi: fix the core number of V3s in sunxi README

2017-08-21 Thread Icenowy Zheng

The Allwinner V3s SoC is not quad-core, but single-core.

Fix this in the README file.

Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng 
---
 Documentation/arm/sunxi/README | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index d7b1f016bd62..de791e18ccef 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -33,6 +33,11 @@ SunXi family
 
   - Next Thing Co GR8 (sun5i)
 
+* Single ARM Cortex-A7 based SoCs
+  - Allwinner V3s (sun8i)
++ Datasheet
+  http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
+
 * Dual ARM Cortex-A7 based SoCs
   - Allwinner A20 (sun7i)
 + User Manual
@@ -71,10 +76,6 @@ SunXi family
 + Datasheet
   http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
 
-  - Allwinner V3s (sun8i)
-+ Datasheet
-  http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf
-
 * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
   - Allwinner A80
 + Datasheet
-- 
2.13.5

Re: [PATCH v2 2/3] i2c: davinci: Add PM Runtime Support

2017-08-21 Thread Sekhar Nori

On Tuesday 22 August 2017 06:47 AM, Franklin S Cooper Jr wrote:
> 
> 
> On 08/21/2017 04:05 AM, Sekhar Nori wrote:
>> On Thursday 17 August 2017 03:47 AM, Franklin S Cooper Jr wrote:
>>
>>> @@ -802,7 +821,6 @@ static int davinci_i2c_probe(struct platform_device 
>>> *pdev)
>>> dev->clk = devm_clk_get(>dev, NULL);
>>> if (IS_ERR(dev->clk))
>>> return PTR_ERR(dev->clk);
>>> -   clk_prepare_enable(dev->clk);
>>>  
>>> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> dev->base = devm_ioremap_resource(>dev, mem);
>>> @@ -811,6 +829,18 @@ static int davinci_i2c_probe(struct platform_device 
>>> *pdev)
>>> goto err_unuse_clocks;
>>
>> This goto is wrong now. There is no need to unwind the pm_runtime setup
>> on a devm_ioremap_resource() failure. You can just return error here.
> 
> Ok
>>
>>> }
>>>  
>>> +   pm_runtime_set_autosuspend_delay(dev->dev,
>>> +DAVINCI_I2C_PM_TIMEOUT);
>>> +   pm_runtime_use_autosuspend(dev->dev);
>>> +
>>> +   pm_runtime_enable(dev->dev);
>>> +
>>> +   r = pm_runtime_get_sync(dev->dev);
>>> +   if (r < 0) {
>>> +   dev_err(dev->dev, "failed to runtime_get device: %d\n", r);
>>> +   goto err_unuse_clocks;
>>> +   }
>>> +
>>> i2c_davinci_init(dev);
>>>  
>>> r = devm_request_irq(>dev, dev->irq, i2c_davinci_isr, 0,
>>> @@ -849,10 +879,16 @@ static int davinci_i2c_probe(struct platform_device 
>>> *pdev)
>>> if (r)
>>> goto err_unuse_clocks;
>>>  
>>> +   pm_runtime_mark_last_busy(dev->dev);
>>> +   pm_runtime_put_autosuspend(dev->dev);
>>> +
>>> return 0;
>>>  
>>>  err_unuse_clocks:
>>> -   clk_disable_unprepare(dev->clk);
>>> +   pm_runtime_dont_use_autosuspend(dev->dev);
>>> +   pm_runtime_put_sync(dev->dev);
>>> +   pm_runtime_disable(dev->dev);
>>> +
>>> dev->clk = NULL;
>>
>> This null setting of clk seems quite bogus and can be cleaned-up.
> 
> Do you mean that I should just remove this line?

Yes, and I noticed a similar line in at least one more place that can be
removed as well.

Thanks,
Sekhar

Re: [PATCH v2 2/3] i2c: davinci: Add PM Runtime Support

2017-08-21 Thread Sekhar Nori

On Tuesday 22 August 2017 06:47 AM, Franklin S Cooper Jr wrote:
> 
> 
> On 08/21/2017 04:05 AM, Sekhar Nori wrote:
>> On Thursday 17 August 2017 03:47 AM, Franklin S Cooper Jr wrote:
>>
>>> @@ -802,7 +821,6 @@ static int davinci_i2c_probe(struct platform_device 
>>> *pdev)
>>> dev->clk = devm_clk_get(>dev, NULL);
>>> if (IS_ERR(dev->clk))
>>> return PTR_ERR(dev->clk);
>>> -   clk_prepare_enable(dev->clk);
>>>  
>>> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> dev->base = devm_ioremap_resource(>dev, mem);
>>> @@ -811,6 +829,18 @@ static int davinci_i2c_probe(struct platform_device 
>>> *pdev)
>>> goto err_unuse_clocks;
>>
>> This goto is wrong now. There is no need to unwind the pm_runtime setup
>> on a devm_ioremap_resource() failure. You can just return error here.
> 
> Ok
>>
>>> }
>>>  
>>> +   pm_runtime_set_autosuspend_delay(dev->dev,
>>> +DAVINCI_I2C_PM_TIMEOUT);
>>> +   pm_runtime_use_autosuspend(dev->dev);
>>> +
>>> +   pm_runtime_enable(dev->dev);
>>> +
>>> +   r = pm_runtime_get_sync(dev->dev);
>>> +   if (r < 0) {
>>> +   dev_err(dev->dev, "failed to runtime_get device: %d\n", r);
>>> +   goto err_unuse_clocks;
>>> +   }
>>> +
>>> i2c_davinci_init(dev);
>>>  
>>> r = devm_request_irq(>dev, dev->irq, i2c_davinci_isr, 0,
>>> @@ -849,10 +879,16 @@ static int davinci_i2c_probe(struct platform_device 
>>> *pdev)
>>> if (r)
>>> goto err_unuse_clocks;
>>>  
>>> +   pm_runtime_mark_last_busy(dev->dev);
>>> +   pm_runtime_put_autosuspend(dev->dev);
>>> +
>>> return 0;
>>>  
>>>  err_unuse_clocks:
>>> -   clk_disable_unprepare(dev->clk);
>>> +   pm_runtime_dont_use_autosuspend(dev->dev);
>>> +   pm_runtime_put_sync(dev->dev);
>>> +   pm_runtime_disable(dev->dev);
>>> +
>>> dev->clk = NULL;
>>
>> This null setting of clk seems quite bogus and can be cleaned-up.
> 
> Do you mean that I should just remove this line?

Yes, and I noticed a similar line in at least one more place that can be
removed as well.

Thanks,
Sekhar

[PATCH v2 1/3] dt-bindings: add compatible string for Allwinner V3s SoC

2017-08-21 Thread Icenowy Zheng

The compatible string for Allwinner V3s SoC used to be missing.

Add it to the binding document.

Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng 
---
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index d2c46449b4eb..f35c6ada5a65 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h2-plus
   allwinner,sun8i-h3
+  allwinner,sun8i-v3s
   allwinner,sun9i-a80
   allwinner,sun50i-a64
   nextthing,gr8
-- 
2.13.5

[PATCH v2 1/3] dt-bindings: add compatible string for Allwinner V3s SoC

2017-08-21 Thread Icenowy Zheng

The compatible string for Allwinner V3s SoC used to be missing.

Add it to the binding document.

Fixes: b074fede01c0 ("arm: sunxi: add support for V3s SoC")
Signed-off-by: Icenowy Zheng 
---
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt
index d2c46449b4eb..f35c6ada5a65 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h2-plus
   allwinner,sun8i-h3
+  allwinner,sun8i-v3s
   allwinner,sun9i-a80
   allwinner,sun50i-a64
   nextthing,gr8
-- 
2.13.5

Re: [PATCH 4/4] staging: iio: tsl2x7x: constify i2c_device_id

2017-08-21 Thread Arvind Yadav


Hi


On Tuesday 22 August 2017 01:50 AM, Dan Carpenter wrote:

Don't say "[PATCH 4/4]".  It's not a patchset or a part of an email
thread.

Yes, It's part of these patchset.
  [PATCH 1/4] misc: apds9802als: constify i2c_device_id
  [PATCH 2/4] misc: hmc6352: constify i2c_device_id
  [PATCH 3/4] misc: isl29020: constify i2c_device_id
  [PATCH 4/4] staging: iio: tsl2x7x: constify i2c_device_id



regards,
dan carpenter


~arvind

Re: [PATCH 4/4] staging: iio: tsl2x7x: constify i2c_device_id

2017-08-21 Thread Arvind Yadav


Hi


On Tuesday 22 August 2017 01:50 AM, Dan Carpenter wrote:

Don't say "[PATCH 4/4]".  It's not a patchset or a part of an email
thread.

Yes, It's part of these patchset.
  [PATCH 1/4] misc: apds9802als: constify i2c_device_id
  [PATCH 2/4] misc: hmc6352: constify i2c_device_id
  [PATCH 3/4] misc: isl29020: constify i2c_device_id
  [PATCH 4/4] staging: iio: tsl2x7x: constify i2c_device_id



regards,
dan carpenter


~arvind

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

2017-08-21 Thread Byungchul Park

On Mon, Aug 21, 2017 at 05:46:00PM +0200, Peter Zijlstra wrote:
> Now given the above observance rule and the fact that the below report
> is from the complete, the thing that happened appears to be:
> 
> 
>   lockdep_map_acquire(>lockdep_map)
>   down_write()
> 
>   down_write()
>   wait_for_completion()
> 
>   lockdep_map_acquire(_lockdep_map);
>   complete()
> 
> Which lockdep then puked over because both sides saw the same work
> class.
> 
> Byungchul; should we not exclude the work class itself, it appears to me
> the workqueue code is explicitly parallel, or am I confused again?

Do you mean the lockdep_map_acquire(>lockdep_map) used manuallly?

That was introduced by Johannes:

commit 4e6045f134784f4b158b3c0f7a282b04bd816887
"workqueue: debug flushing deadlocks with lockdep"

I am not sure but, for that purpose, IMHO, we can use a
lockdep_map_acquire_read() instead, in process_one_work(), can't we?

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

2017-08-21 Thread Byungchul Park

On Mon, Aug 21, 2017 at 05:46:00PM +0200, Peter Zijlstra wrote:
> Now given the above observance rule and the fact that the below report
> is from the complete, the thing that happened appears to be:
> 
> 
>   lockdep_map_acquire(>lockdep_map)
>   down_write()
> 
>   down_write()
>   wait_for_completion()
> 
>   lockdep_map_acquire(_lockdep_map);
>   complete()
> 
> Which lockdep then puked over because both sides saw the same work
> class.
> 
> Byungchul; should we not exclude the work class itself, it appears to me
> the workqueue code is explicitly parallel, or am I confused again?

Do you mean the lockdep_map_acquire(>lockdep_map) used manuallly?

That was introduced by Johannes:

commit 4e6045f134784f4b158b3c0f7a282b04bd816887
"workqueue: debug flushing deadlocks with lockdep"

I am not sure but, for that purpose, IMHO, we can use a
lockdep_map_acquire_read() instead, in process_one_work(), can't we?

Re: [PATCH 2/2] ARM: sunxi: add support for R40 SoC

2017-08-21 Thread icenowy


在 2017-08-21 17:34，Maxime Ripard 写道：

Hi,

On Sun, Aug 20, 2017 at 01:29:57PM +0800, Icenowy Zheng wrote:

Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
like A20.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
 Documentation/arm/sunxi/README  | 6 ++
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 arch/arm/mach-sunxi/sunxi.c | 1 +
 3 files changed, 8 insertions(+)

diff --git a/Documentation/arm/sunxi/README 
b/Documentation/arm/sunxi/README

index d7b1f016bd62..4fa836782e46 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -75,6 +75,12 @@ SunXi family
 + Datasheet
   
http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf


+  - Allwinner R40 (sun8i)
++ Datasheet
+  
https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf

++ User Manual
+  
https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf

+


Please sort it by alphabetical order.


I prefer to sort it by the wafer ID (the number after w in the official 
ID).


The current document can be explained to follow the alphabetical order
or the wafer ID.

P.S. there's some error in the V3s datasheet position, and if it's fixed
we can still continue to make the two kinds of order both meaningful ;-)




 * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
   - Allwinner A80
 + Datasheet
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt

index f35c6ada5a65..e4beec3d9ad3 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h2-plus
   allwinner,sun8i-h3
+  allwinner-sun8i-r40
   allwinner,sun8i-v3s
   allwinner,sun9i-a80
   allwinner,sun50i-a64
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 7ab353fb25f2..311e6c4fc4f4 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = 
{

"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
"allwinner,sun8i-v3s",
+   "allwinner,sun8i-r40",


And same thing here.

Thanks!
Maxime

Re: [PATCH 2/2] ARM: sunxi: add support for R40 SoC

2017-08-21 Thread icenowy


在 2017-08-21 17:34，Maxime Ripard 写道：

Hi,

On Sun, Aug 20, 2017 at 01:29:57PM +0800, Icenowy Zheng wrote:

Allwinner R40 is a new SoC, with Quad Core Cortex-A7 and peripherals
like A20.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
 Documentation/arm/sunxi/README  | 6 ++
 Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
 arch/arm/mach-sunxi/sunxi.c | 1 +
 3 files changed, 8 insertions(+)

diff --git a/Documentation/arm/sunxi/README 
b/Documentation/arm/sunxi/README

index d7b1f016bd62..4fa836782e46 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -75,6 +75,12 @@ SunXi family
 + Datasheet
   
http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf


+  - Allwinner R40 (sun8i)
++ Datasheet
+  
https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf

++ User Manual
+  
https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf

+


Please sort it by alphabetical order.


I prefer to sort it by the wafer ID (the number after w in the official 
ID).


The current document can be explained to follow the alphabetical order
or the wafer ID.

P.S. there's some error in the V3s datasheet position, and if it's fixed
we can still continue to make the two kinds of order both meaningful ;-)




 * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
   - Allwinner A80
 + Datasheet
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt 
b/Documentation/devicetree/bindings/arm/sunxi.txt

index f35c6ada5a65..e4beec3d9ad3 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h2-plus
   allwinner,sun8i-h3
+  allwinner-sun8i-r40
   allwinner,sun8i-v3s
   allwinner,sun9i-a80
   allwinner,sun50i-a64
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 7ab353fb25f2..311e6c4fc4f4 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -66,6 +66,7 @@ static const char * const sun8i_board_dt_compat[] = 
{

"allwinner,sun8i-h2-plus",
"allwinner,sun8i-h3",
"allwinner,sun8i-v3s",
+   "allwinner,sun8i-r40",


And same thing here.

Thanks!
Maxime

Re: [PATCH v2 2/5] powerpc: pseries: vio: match parent nodes with of_find_node_by_path

2017-08-21 Thread Michael Ellerman

Rob Herring  writes:

> In preparation to remove the full path from device_node.full_name, use
> of_find_node_by_path instead of open coding with strcmp.
>
> Signed-off-by: Rob Herring 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-...@lists.ozlabs.org
> ---
> v2:
> - rebased to linux-next and removed spurious change fro patch 1.
>
>  arch/powerpc/platforms/pseries/vio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/vio.c 
> b/arch/powerpc/platforms/pseries/vio.c
> index aa5ca74316fa..5754572deb23 100644
> --- a/arch/powerpc/platforms/pseries/vio.c
> +++ b/arch/powerpc/platforms/pseries/vio.c
> @@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct 
> device_node *of_node)
>*/
>   parent_node = of_get_parent(of_node);
>   if (parent_node) {
> - if (!strcmp(parent_node->full_name, "/ibm,platform-facilities"))
> + if (parent_node == 
> of_find_node_by_path("/ibm,platform-facilities"))
>   family = PFO;
> - else if (!strcmp(parent_node->full_name, "/vdevice"))
> + else if (parent_node == of_find_node_by_path("/vdevice"))
>   family = VDEVICE;

This leaks references to the looked up nodes.

Both these nodes are defined in PAPR (our hypervisor spec), and both of
them must have a device_type, either "ibm,platform-facilities" or
"vdevice".

Looking at the commit that added the code I don't see any particular
reason it used the comparison against full_name, rather than using the
device_type.

So I'm inclined to do this instead:

diff --git a/arch/powerpc/platforms/pseries/vio.c 
b/arch/powerpc/platforms/pseries/vio.c
index 8a47f168476b..f26f906e6021 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct 
device_node *of_node)
 */
parent_node = of_get_parent(of_node);
if (parent_node) {
-   if (!strcmp(parent_node->full_name, "/ibm,platform-facilities"))
+   if (!strcmp(parent_node->type, "ibm,platform-facilities"))
family = PFO;
-   else if (!strcmp(parent_node->full_name, "/vdevice"))
+   else if (!strcmp(parent_node->type, "vdevice"))
family = VDEVICE;
else {
pr_warn("%s: parent(%s) of %s not recognized.\n",


I've checked both Qemu and kvmtool add the device_type, and I'm fairly
confident that PowerVM does too. Anyway I'll test it on all the machines
I can find.

cheers

Re: [PATCH v2 2/5] powerpc: pseries: vio: match parent nodes with of_find_node_by_path

2017-08-21 Thread Michael Ellerman

Rob Herring  writes:

> In preparation to remove the full path from device_node.full_name, use
> of_find_node_by_path instead of open coding with strcmp.
>
> Signed-off-by: Rob Herring 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-...@lists.ozlabs.org
> ---
> v2:
> - rebased to linux-next and removed spurious change fro patch 1.
>
>  arch/powerpc/platforms/pseries/vio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/vio.c 
> b/arch/powerpc/platforms/pseries/vio.c
> index aa5ca74316fa..5754572deb23 100644
> --- a/arch/powerpc/platforms/pseries/vio.c
> +++ b/arch/powerpc/platforms/pseries/vio.c
> @@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct 
> device_node *of_node)
>*/
>   parent_node = of_get_parent(of_node);
>   if (parent_node) {
> - if (!strcmp(parent_node->full_name, "/ibm,platform-facilities"))
> + if (parent_node == 
> of_find_node_by_path("/ibm,platform-facilities"))
>   family = PFO;
> - else if (!strcmp(parent_node->full_name, "/vdevice"))
> + else if (parent_node == of_find_node_by_path("/vdevice"))
>   family = VDEVICE;

This leaks references to the looked up nodes.

Both these nodes are defined in PAPR (our hypervisor spec), and both of
them must have a device_type, either "ibm,platform-facilities" or
"vdevice".

Looking at the commit that added the code I don't see any particular
reason it used the comparison against full_name, rather than using the
device_type.

So I'm inclined to do this instead:

diff --git a/arch/powerpc/platforms/pseries/vio.c 
b/arch/powerpc/platforms/pseries/vio.c
index 8a47f168476b..f26f906e6021 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -1357,9 +1357,9 @@ struct vio_dev *vio_register_device_node(struct 
device_node *of_node)
 */
parent_node = of_get_parent(of_node);
if (parent_node) {
-   if (!strcmp(parent_node->full_name, "/ibm,platform-facilities"))
+   if (!strcmp(parent_node->type, "ibm,platform-facilities"))
family = PFO;
-   else if (!strcmp(parent_node->full_name, "/vdevice"))
+   else if (!strcmp(parent_node->type, "vdevice"))
family = VDEVICE;
else {
pr_warn("%s: parent(%s) of %s not recognized.\n",


I've checked both Qemu and kvmtool add the device_type, and I'm fairly
confident that PowerVM does too. Anyway I'll test it on all the machines
I can find.

cheers

Re: [RFC v1 4/6] platform: x86: Add generic Intel IPC driver

2017-08-21 Thread sathya


Hi Andy,


On 08/18/2017 05:38 AM, Andy Shevchenko wrote:

On Tue, Aug 1, 2017 at 9:13 PM,
 wrote:

From: Kuppuswamy Sathyanarayanan 

Currently intel_scu_ipc.c, intel_pmc_ipc.c and intel_punit_ipc.c
redundantly implements the same IPC features and has lot of code
duplication between them. This driver addresses this issue by grouping
the common IPC functionalities under the same driver.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
  arch/x86/include/asm/intel_ipc_dev.h | 148 

No, it should go under include/linux/platform_data/x86/


+/*
+ * intel_ipc_dev.h: IPC class device header file

No file names in the top of files.


+ *
+ * (C) Copyright 2017 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ *
+ */
+struct intel_ipc_dev_cfg {
+   void __iomem *base;
+   void __iomem *wrbuf_reg;
+   void __iomem *rbuf_reg;
+   void __iomem *sptr_reg;
+   void __iomem *dptr_reg;
+   void __iomem *status_reg;
+   void __iomem *cmd_reg;

No, you have to switch to regmap instead.
Do you want me to register regmap in intel_pmc_ipc.c and pass this 
regmap pointer to devm_intel_ipc_dev_create()
instead of regular mem address ? Please correct me if my understanding 
is incorrect.


But I don't understand how this change will improve the design.



+   int mode;
+   int irq;
+   int irqflags;
+   int chan_type;
+   bool use_msi;
+};



-
Sathya

Re: [RFC v1 4/6] platform: x86: Add generic Intel IPC driver

2017-08-21 Thread sathya


Hi Andy,


On 08/18/2017 05:38 AM, Andy Shevchenko wrote:

On Tue, Aug 1, 2017 at 9:13 PM,
 wrote:

From: Kuppuswamy Sathyanarayanan 

Currently intel_scu_ipc.c, intel_pmc_ipc.c and intel_punit_ipc.c
redundantly implements the same IPC features and has lot of code
duplication between them. This driver addresses this issue by grouping
the common IPC functionalities under the same driver.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
  arch/x86/include/asm/intel_ipc_dev.h | 148 

No, it should go under include/linux/platform_data/x86/


+/*
+ * intel_ipc_dev.h: IPC class device header file

No file names in the top of files.


+ *
+ * (C) Copyright 2017 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ *
+ */
+struct intel_ipc_dev_cfg {
+   void __iomem *base;
+   void __iomem *wrbuf_reg;
+   void __iomem *rbuf_reg;
+   void __iomem *sptr_reg;
+   void __iomem *dptr_reg;
+   void __iomem *status_reg;
+   void __iomem *cmd_reg;

No, you have to switch to regmap instead.
Do you want me to register regmap in intel_pmc_ipc.c and pass this 
regmap pointer to devm_intel_ipc_dev_create()
instead of regular mem address ? Please correct me if my understanding 
is incorrect.


But I don't understand how this change will improve the design.



+   int mode;
+   int irq;
+   int irqflags;
+   int chan_type;
+   bool use_msi;
+};



-
Sathya

linux-next: build warning after merge of the phy-next tree

2017-08-21 Thread Stephen Rothwell

Hi Kishon,

After merging the phy-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/phy/ralink/phy-ralink-usb.c: In function 'ralink_usb_phy_probe':
drivers/phy/ralink/phy-ralink-usb.c:195:13: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
  phy->clk = (u32) match->data;
 ^

Introduced by commit

  2411a736ff09 ("phy: ralink-usb: add driver for Mediatek/Ralink")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the phy-next tree

2017-08-21 Thread Stephen Rothwell

Hi Kishon,

After merging the phy-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/phy/ralink/phy-ralink-usb.c: In function 'ralink_usb_phy_probe':
drivers/phy/ralink/phy-ralink-usb.c:195:13: warning: cast from pointer to 
integer of different size [-Wpointer-to-int-cast]
  phy->clk = (u32) match->data;
 ^

Introduced by commit

  2411a736ff09 ("phy: ralink-usb: add driver for Mediatek/Ralink")

-- 
Cheers,
Stephen Rothwell

Re: [RFC v1 2/6] platform/x86: intel_pmc_ipc: Use devm_* calls in driver probe

2017-08-21 Thread sathya


Hi,


On 08/18/2017 05:24 AM, Andy Shevchenko wrote:

On Tue, Aug 1, 2017 at 9:13 PM,
 wrote:

From: Kuppuswamy Sathyanarayanan 

This patch cleans up unnecessary free/alloc calls in this driver
by using devm_* calls.
  static int ipc_plat_remove(struct platform_device *pdev)
  {
-   struct resource *res;
-
 sysfs_remove_group(>dev.kobj, _ipc_group);
-   free_irq(ipcdev.irq, );

Can we get an IRQ at any time here?
Yes, if the ipc_plat_probe() is successful then ipcdev.irq will have 
valid IRQ in all cases.



 platform_device_unregister(ipcdev.tco_dev);
 platform_device_unregister(ipcdev.punit_dev);
 platform_device_unregister(ipcdev.telemetry_dev);
 ipcdev.dev = NULL;
 return 0;
  }



-
Sathya

Re: [RFC v1 2/6] platform/x86: intel_pmc_ipc: Use devm_* calls in driver probe

2017-08-21 Thread sathya


Hi,


On 08/18/2017 05:24 AM, Andy Shevchenko wrote:

On Tue, Aug 1, 2017 at 9:13 PM,
 wrote:

From: Kuppuswamy Sathyanarayanan 

This patch cleans up unnecessary free/alloc calls in this driver
by using devm_* calls.
  static int ipc_plat_remove(struct platform_device *pdev)
  {
-   struct resource *res;
-
 sysfs_remove_group(>dev.kobj, _ipc_group);
-   free_irq(ipcdev.irq, );

Can we get an IRQ at any time here?
Yes, if the ipc_plat_probe() is successful then ipcdev.irq will have 
valid IRQ in all cases.



 platform_device_unregister(ipcdev.tco_dev);
 platform_device_unregister(ipcdev.punit_dev);
 platform_device_unregister(ipcdev.telemetry_dev);
 ipcdev.dev = NULL;
 return 0;
  }



-
Sathya

Re: [GIT PULL] phy: for 4.14

2017-08-21 Thread Kishon Vijay Abraham I

Hi Greg,

On Monday 21 August 2017 06:15 PM, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Please find the phy pull request for 4.14 merge window below.
> 
> It adds a new USB phy driver for Ralink SoC, add support for PCIe and
> SATA PHY in phy-mt65xx-usb3 driver, add support for allwinner A83T
> USB PHY and Qualcomm IPQ8074 in sun4i-usb-phy driver and
> qcom-qmp-phy driver respectively.
> 
> Please let me know if I have to make any changes.
> 
> Thanks
> Kishon
> 
> The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:
> 
>   Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
> tags/phy-for-4.14

Please ignore this pull request. There is an issue w.r.t missing Signed-off-by
the committer in a couple of patches reported by Stephen. I've sent a fresh
pull request after fixing those.

Thanks
Kishon

> 
> for you to fetch changes up to b35193655dd60003d8f4e43cba3a5f982e82551e:
> 
>   phy: brcm-sata: fix a timeout test in init (2017-08-20 15:59:48 +0530)
> 
> 
> phy: for 4.14
> 
>  *) Add USB PHY driver for Ralink SoC
>  *) Make phy-mt65xx-usb3 driver support PCIe and SATA phy
>  *) Add mediatek directory and rename phy-mt65xx-usb3 to phy-mtk-tphy.c
> since it now supports USB3.0, PCIe and SATA PHYs
>  *) Make sun4i-usb-phy driver support USB PHYs for A83T SoC
>  *) Make phy-qcom-qmp driver support USB PHYs for IPQ8074 SoC
>  *) Make rockchip-inno-usb2 driver support usb2-phy for rv1108 SoC
>  *) Minor fixes in phy drivers
> 
> Signed-off-by: Kishon Vijay Abraham I 
> 
> 
> Chen-Yu Tsai (4):
>   dt-bindings: phy: sun4i-usb-phy: Add property descriptions for H3
>   dt-bindings: phy: sun4i-usb-phy: Add compatible string for A83T
>   phy: sun4i-usb: Support secondary clock for HSIC PHY
>   phy: sun4i-usb: Support A83T USB PHYs
> 
> Chunfeng Yun (3):
>   dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file
>   phy: phy-mt65xx-usb3: add mediatek directory and rename file
>   phy: samsung: use of_device_get_match_data()
> 
> Dan Carpenter (3):
>   phy: phy-twl4030-usb: silence an uninitialized variable warning
>   phy: cpcap-usb: remove a stray tab
>   phy: brcm-sata: fix a timeout test in init
> 
> Frank Wang (5):
>   phy: rockchip-inno-usb2: add support for rockchip,usbgrf property
>   dt-bindings: phy-rockchip-inno-usb2: add rockchip,usbgrf property
>   phy: rockchip-inno-usb2: add support for otg-mux interrupt
>   dt-bindings: phy-rockchip-inno-usb2: add otg-mux interrupt
>   phy: rockchip-inno-usb2: add support of usb2-phy for rv1108 SoCs
> 
> John Crispin (2):
>   dt-bindings: phy: Add bindings for ralink-usb PHY
>   phy: ralink-usb: add driver for Mediatek/Ralink
> 
> Quentin Schulz (1):
>   phy: allwinner: phy-sun4i-usb: Add log when probing
> 
> Roger Quadros (1):
>   phy: ti-pipe3: Use TRM recommended settings for SATA DPLL
> 
> Ryder Lee (2):
>   phy: phy-mt65xx-usb3: add PCIe PHY support
>   phy: phy-mt65xx-usb3: add SATA PHY support
> 
> Shawn Lin (1):
>   phy: rockchip-typec: remove unused dfp variable
> 
> Varadarajan Narayanan (4):
>   dt-bindings: phy: qmp: Add output-clock-names
>   dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074
>   phy: qcom-qmp: Fix phy pipe clock name
>   phy: qcom-qmp: Add support for IPQ8074
> 
> Vivek Gautam (1):
>   phy: qcom-qmp: Fix failure path in phy_init functions
> 
>  Documentation/devicetree/bindings/phy/{phy-mt65xx-usb.txt => 
> phy-mtk-tphy.txt} |  17 ++--
>  Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt 
>   |  11 ++-
>  Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt   
>   |  11 +++
>  Documentation/devicetree/bindings/phy/ralink-usb-phy.txt 
>   |  23 +
>  Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt  
>   |  10 ++-
>  MAINTAINERS  
>   |   2 +-
>  drivers/phy/Kconfig  
>   |  10 +--
>  drivers/phy/Makefile 
>   |   3 +-
>  drivers/phy/allwinner/phy-sun4i-usb.c
>   | 112 
>  drivers/phy/broadcom/phy-brcm-sata.c 
>   |   2 +-
>  drivers/phy/mediatek/Kconfig 
>   |  14 +++
>  drivers/phy/mediatek/Makefile
>   |   5 ++
>  drivers/phy/{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c}   
>   | 557 
>

Re: [GIT PULL] phy: for 4.14

2017-08-21 Thread Kishon Vijay Abraham I

Hi Greg,

On Monday 21 August 2017 06:15 PM, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Please find the phy pull request for 4.14 merge window below.
> 
> It adds a new USB phy driver for Ralink SoC, add support for PCIe and
> SATA PHY in phy-mt65xx-usb3 driver, add support for allwinner A83T
> USB PHY and Qualcomm IPQ8074 in sun4i-usb-phy driver and
> qcom-qmp-phy driver respectively.
> 
> Please let me know if I have to make any changes.
> 
> Thanks
> Kishon
> 
> The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:
> 
>   Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
> tags/phy-for-4.14

Please ignore this pull request. There is an issue w.r.t missing Signed-off-by
the committer in a couple of patches reported by Stephen. I've sent a fresh
pull request after fixing those.

Thanks
Kishon

> 
> for you to fetch changes up to b35193655dd60003d8f4e43cba3a5f982e82551e:
> 
>   phy: brcm-sata: fix a timeout test in init (2017-08-20 15:59:48 +0530)
> 
> 
> phy: for 4.14
> 
>  *) Add USB PHY driver for Ralink SoC
>  *) Make phy-mt65xx-usb3 driver support PCIe and SATA phy
>  *) Add mediatek directory and rename phy-mt65xx-usb3 to phy-mtk-tphy.c
> since it now supports USB3.0, PCIe and SATA PHYs
>  *) Make sun4i-usb-phy driver support USB PHYs for A83T SoC
>  *) Make phy-qcom-qmp driver support USB PHYs for IPQ8074 SoC
>  *) Make rockchip-inno-usb2 driver support usb2-phy for rv1108 SoC
>  *) Minor fixes in phy drivers
> 
> Signed-off-by: Kishon Vijay Abraham I 
> 
> 
> Chen-Yu Tsai (4):
>   dt-bindings: phy: sun4i-usb-phy: Add property descriptions for H3
>   dt-bindings: phy: sun4i-usb-phy: Add compatible string for A83T
>   phy: sun4i-usb: Support secondary clock for HSIC PHY
>   phy: sun4i-usb: Support A83T USB PHYs
> 
> Chunfeng Yun (3):
>   dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file
>   phy: phy-mt65xx-usb3: add mediatek directory and rename file
>   phy: samsung: use of_device_get_match_data()
> 
> Dan Carpenter (3):
>   phy: phy-twl4030-usb: silence an uninitialized variable warning
>   phy: cpcap-usb: remove a stray tab
>   phy: brcm-sata: fix a timeout test in init
> 
> Frank Wang (5):
>   phy: rockchip-inno-usb2: add support for rockchip,usbgrf property
>   dt-bindings: phy-rockchip-inno-usb2: add rockchip,usbgrf property
>   phy: rockchip-inno-usb2: add support for otg-mux interrupt
>   dt-bindings: phy-rockchip-inno-usb2: add otg-mux interrupt
>   phy: rockchip-inno-usb2: add support of usb2-phy for rv1108 SoCs
> 
> John Crispin (2):
>   dt-bindings: phy: Add bindings for ralink-usb PHY
>   phy: ralink-usb: add driver for Mediatek/Ralink
> 
> Quentin Schulz (1):
>   phy: allwinner: phy-sun4i-usb: Add log when probing
> 
> Roger Quadros (1):
>   phy: ti-pipe3: Use TRM recommended settings for SATA DPLL
> 
> Ryder Lee (2):
>   phy: phy-mt65xx-usb3: add PCIe PHY support
>   phy: phy-mt65xx-usb3: add SATA PHY support
> 
> Shawn Lin (1):
>   phy: rockchip-typec: remove unused dfp variable
> 
> Varadarajan Narayanan (4):
>   dt-bindings: phy: qmp: Add output-clock-names
>   dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074
>   phy: qcom-qmp: Fix phy pipe clock name
>   phy: qcom-qmp: Add support for IPQ8074
> 
> Vivek Gautam (1):
>   phy: qcom-qmp: Fix failure path in phy_init functions
> 
>  Documentation/devicetree/bindings/phy/{phy-mt65xx-usb.txt => 
> phy-mtk-tphy.txt} |  17 ++--
>  Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt 
>   |  11 ++-
>  Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt   
>   |  11 +++
>  Documentation/devicetree/bindings/phy/ralink-usb-phy.txt 
>   |  23 +
>  Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt  
>   |  10 ++-
>  MAINTAINERS  
>   |   2 +-
>  drivers/phy/Kconfig  
>   |  10 +--
>  drivers/phy/Makefile 
>   |   3 +-
>  drivers/phy/allwinner/phy-sun4i-usb.c
>   | 112 
>  drivers/phy/broadcom/phy-brcm-sata.c 
>   |   2 +-
>  drivers/phy/mediatek/Kconfig 
>   |  14 +++
>  drivers/phy/mediatek/Makefile
>   |   5 ++
>  drivers/phy/{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c}   
>   | 557 
>

Re: [RFC v1 3/6] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

2017-08-21 Thread sathya


Hi Andy,


On 08/18/2017 05:29 AM, Andy Shevchenko wrote:

On Tue, Aug 1, 2017 at 9:13 PM,
 wrote:


Currently, we have lot of repetitive code in dependent device resource
allocation and device creation handling code. This logic can be improved if
we use MFD framework for dependent device creation. This patch adds this
support.
+static int ipc_create_pmc_devices(struct platform_device *pdev)
  {
-   int ret;
-
-   /* If we have ACPI based watchdog use that instead */
+   u8 n = 0;
+   struct mfd_cell *pmc_mfd_cells;
+
+   pmc_mfd_cells = devm_kzalloc(>dev,
+   (sizeof(*pmc_mfd_cells) * PMC_IPC_MAX_MFD_BLOCK),
+   GFP_KERNEL);
+   if (!pmc_mfd_cells)
+   return -ENOMEM;
+
+   /* Create PUNIT IPC MFD cell */
+   pmc_mfd_cells[n].name = PUNIT_DEVICE_NAME;
+   pmc_mfd_cells[n].id = -1;
+   pmc_mfd_cells[n].num_resources = ARRAY_SIZE(punit_ipc_resources);
+   pmc_mfd_cells[n].resources = punit_ipc_resources;
+   pmc_mfd_cells[n].ignore_resource_conflicts = 1;

Please, use static variables instead of allocated on a heap.

I will follow the model used in lpc_ich.c. Will fix it in next version.



+   n++;
+
+   /* If we have ACPI based watchdog use that instead, othewise create
+* a MFD cell for iTCO watchdog*/
 if (!acpi_has_watchdog()) {
+   pmc_mfd_cells[n].name = TCO_DEVICE_NAME;
+   pmc_mfd_cells[n].id = -1;
+   pmc_mfd_cells[n].platform_data = _info;
+   pmc_mfd_cells[n].pdata_size = sizeof(tco_info);
+   pmc_mfd_cells[n].num_resources =
+   ARRAY_SIZE(watchdog_ipc_resources);
+   pmc_mfd_cells[n].resources = watchdog_ipc_resources;
+   pmc_mfd_cells[n].ignore_resource_conflicts = 1;
+   n++;
 }

...and here you do mfd_add_devices() instead of this stuff.

Check how lpc_ich.c designed.

Will fix it in next version.




-
Sathya

Re: [RFC v1 3/6] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

2017-08-21 Thread sathya


Hi Andy,


On 08/18/2017 05:29 AM, Andy Shevchenko wrote:

On Tue, Aug 1, 2017 at 9:13 PM,
 wrote:


Currently, we have lot of repetitive code in dependent device resource
allocation and device creation handling code. This logic can be improved if
we use MFD framework for dependent device creation. This patch adds this
support.
+static int ipc_create_pmc_devices(struct platform_device *pdev)
  {
-   int ret;
-
-   /* If we have ACPI based watchdog use that instead */
+   u8 n = 0;
+   struct mfd_cell *pmc_mfd_cells;
+
+   pmc_mfd_cells = devm_kzalloc(>dev,
+   (sizeof(*pmc_mfd_cells) * PMC_IPC_MAX_MFD_BLOCK),
+   GFP_KERNEL);
+   if (!pmc_mfd_cells)
+   return -ENOMEM;
+
+   /* Create PUNIT IPC MFD cell */
+   pmc_mfd_cells[n].name = PUNIT_DEVICE_NAME;
+   pmc_mfd_cells[n].id = -1;
+   pmc_mfd_cells[n].num_resources = ARRAY_SIZE(punit_ipc_resources);
+   pmc_mfd_cells[n].resources = punit_ipc_resources;
+   pmc_mfd_cells[n].ignore_resource_conflicts = 1;

Please, use static variables instead of allocated on a heap.

I will follow the model used in lpc_ich.c. Will fix it in next version.



+   n++;
+
+   /* If we have ACPI based watchdog use that instead, othewise create
+* a MFD cell for iTCO watchdog*/
 if (!acpi_has_watchdog()) {
+   pmc_mfd_cells[n].name = TCO_DEVICE_NAME;
+   pmc_mfd_cells[n].id = -1;
+   pmc_mfd_cells[n].platform_data = _info;
+   pmc_mfd_cells[n].pdata_size = sizeof(tco_info);
+   pmc_mfd_cells[n].num_resources =
+   ARRAY_SIZE(watchdog_ipc_resources);
+   pmc_mfd_cells[n].resources = watchdog_ipc_resources;
+   pmc_mfd_cells[n].ignore_resource_conflicts = 1;
+   n++;
 }

...and here you do mfd_add_devices() instead of this stuff.

Check how lpc_ich.c designed.

Will fix it in next version.




-
Sathya

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

2017-08-21 Thread Meelis Roos

> 
> >> I think with this patch from -rc6 the symptoms should be cured:
> >> 
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c005390374957baacbc38eef96ea360559510aa7
> >> 
> >> if that theory is right.
> > 
> > The result with 4.13-rc6 is positive but mixed: the message about MSI-X 
> > affinty maks are still there but the rest of the detection works and the 
> > driver is loaded successfully:
> 
> Is this an SMP system?

Yes, T5120.

-- 
Meelis Roos (mr...@linux.ee)

Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors

2017-08-21 Thread Meelis Roos

> 
> >> I think with this patch from -rc6 the symptoms should be cured:
> >> 
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c005390374957baacbc38eef96ea360559510aa7
> >> 
> >> if that theory is right.
> > 
> > The result with 4.13-rc6 is positive but mixed: the message about MSI-X 
> > affinty maks are still there but the rest of the detection works and the 
> > driver is loaded successfully:
> 
> Is this an SMP system?

Yes, T5120.

-- 
Meelis Roos (mr...@linux.ee)

Re: [RFC v1 1/6] platform/x86: intel_pmc_ipc: Fix error handling in ipc_pci_probe()

2017-08-21 Thread sathya


Hi Andy,


On 08/18/2017 05:22 AM, Andy Shevchenko wrote:

On Tue, Aug 1, 2017 at 9:13 PM,
 wrote:

From: Kuppuswamy Sathyanarayanan 

This patch adds proper error handling for failure cases in
ipc_pci_probe() function.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
  drivers/platform/x86/intel_pmc_ipc.c | 23 ++-
  1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_ipc.c 
b/drivers/platform/x86/intel_pmc_ipc.c
index bb792a5..7b65237 100644
--- a/drivers/platform/x86/intel_pmc_ipc.c
+++ b/drivers/platform/x86/intel_pmc_ipc.c
@@ -489,33 +489,46 @@ static int ipc_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)

 ret = pci_enable_device(pdev);
 if (ret)
-   return ret;
+   goto release_device;

Instead of doing this way and ping-ponging code in the same series,
better to switch to managed PCI functions in the first place.
ok. I will merge this patch and "Use devm_* calls in driver probe" patch 
into a single patch.






-
Sathya

Re: [RFC v1 1/6] platform/x86: intel_pmc_ipc: Fix error handling in ipc_pci_probe()

2017-08-21 Thread sathya


Hi Andy,


On 08/18/2017 05:22 AM, Andy Shevchenko wrote:

On Tue, Aug 1, 2017 at 9:13 PM,
 wrote:

From: Kuppuswamy Sathyanarayanan 

This patch adds proper error handling for failure cases in
ipc_pci_probe() function.

Signed-off-by: Kuppuswamy Sathyanarayanan 

---
  drivers/platform/x86/intel_pmc_ipc.c | 23 ++-
  1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_ipc.c 
b/drivers/platform/x86/intel_pmc_ipc.c
index bb792a5..7b65237 100644
--- a/drivers/platform/x86/intel_pmc_ipc.c
+++ b/drivers/platform/x86/intel_pmc_ipc.c
@@ -489,33 +489,46 @@ static int ipc_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)

 ret = pci_enable_device(pdev);
 if (ret)
-   return ret;
+   goto release_device;

Instead of doing this way and ping-ponging code in the same series,
better to switch to managed PCI functions in the first place.
ok. I will merge this patch and "Use devm_* calls in driver probe" patch 
into a single patch.






-
Sathya

[GIT PULL v2] phy: for 4.14

2017-08-21 Thread Kishon Vijay Abraham I

Hi Greg,

Stephen Rothwell reported a issue with my previous pull request
w.r.t missing Signed-off-by committer. I've fixed that in this pull
request.

It adds a new USB phy driver for Ralink SoC, add support for PCIe and
SATA PHY in phy-mt65xx-usb3 driver, add support for allwinner A83T
USB PHY and Qualcomm IPQ8074 in sun4i-usb-phy driver and
qcom-qmp-phy driver respectively.

Please let me know if I have to make any changes.

Thanks
Kishon

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:

  Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
tags/phy-for-4.14_v2

for you to fetch changes up to d9c51f4c53ae2af03aa8bd001d46f21b0adcdab8:

  phy: brcm-sata: fix a timeout test in init (2017-08-22 10:11:27 +0530)


phy: for 4.14

 *) Add USB PHY driver for Ralink SoC
 *) Make phy-mt65xx-usb3 driver support PCIe and SATA phy
 *) Add mediatek directory and rename phy-mt65xx-usb3 to phy-mtk-tphy.c
since it now supports USB3.0, PCIe and SATA PHYs
 *) Make sun4i-usb-phy driver support USB PHYs for A83T SoC
 *) Make phy-qcom-qmp driver support USB PHYs for IPQ8074 SoC
 *) Make rockchip-inno-usb2 driver support usb2-phy for rv1108 SoC
 *) Minor fixes in phy drivers

Signed-off-by: Kishon Vijay Abraham I 


Chen-Yu Tsai (4):
  dt-bindings: phy: sun4i-usb-phy: Add property descriptions for H3
  dt-bindings: phy: sun4i-usb-phy: Add compatible string for A83T
  phy: sun4i-usb: Support secondary clock for HSIC PHY
  phy: sun4i-usb: Support A83T USB PHYs

Chunfeng Yun (3):
  dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file
  phy: phy-mt65xx-usb3: add mediatek directory and rename file
  phy: samsung: use of_device_get_match_data()

Dan Carpenter (3):
  phy: phy-twl4030-usb: silence an uninitialized variable warning
  phy: cpcap-usb: remove a stray tab
  phy: brcm-sata: fix a timeout test in init

Frank Wang (5):
  phy: rockchip-inno-usb2: add support for rockchip,usbgrf property
  dt-bindings: phy-rockchip-inno-usb2: add rockchip,usbgrf property
  phy: rockchip-inno-usb2: add support for otg-mux interrupt
  dt-bindings: phy-rockchip-inno-usb2: add otg-mux interrupt
  phy: rockchip-inno-usb2: add support of usb2-phy for rv1108 SoCs

John Crispin (2):
  dt-bindings: phy: Add bindings for ralink-usb PHY
  phy: ralink-usb: add driver for Mediatek/Ralink

Quentin Schulz (1):
  phy: allwinner: phy-sun4i-usb: Add log when probing

Roger Quadros (1):
  phy: ti-pipe3: Use TRM recommended settings for SATA DPLL

Ryder Lee (2):
  phy: phy-mt65xx-usb3: add PCIe PHY support
  phy: phy-mt65xx-usb3: add SATA PHY support

Shawn Lin (1):
  phy: rockchip-typec: remove unused dfp variable

Varadarajan Narayanan (4):
  dt-bindings: phy: qmp: Add output-clock-names
  dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074
  phy: qcom-qmp: Fix phy pipe clock name
  phy: qcom-qmp: Add support for IPQ8074

Vivek Gautam (1):
  phy: qcom-qmp: Fix failure path in phy_init functions

 Documentation/devicetree/bindings/phy/{phy-mt65xx-usb.txt => phy-mtk-tphy.txt} 
|  17 ++--
 Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt   
|  11 ++-
 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
|  11 +++
 Documentation/devicetree/bindings/phy/ralink-usb-phy.txt   
|  23 +
 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
|  10 ++-
 MAINTAINERS
|   2 +-
 drivers/phy/Kconfig
|  10 +--
 drivers/phy/Makefile   
|   3 +-
 drivers/phy/allwinner/phy-sun4i-usb.c  
| 112 
 drivers/phy/broadcom/phy-brcm-sata.c   
|   2 +-
 drivers/phy/mediatek/Kconfig   
|  14 +++
 drivers/phy/mediatek/Makefile  
|   5 ++
 drivers/phy/{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c} 
| 557 
+++---
 drivers/phy/motorola/phy-cpcap-usb.c   
|   2 +-
 drivers/phy/qualcomm/phy-qcom-qmp.c
| 162 ++-
 drivers/phy/ralink/Kconfig 
|  11 +++
 drivers/phy/ralink/Makefile

[GIT PULL v2] phy: for 4.14

2017-08-21 Thread Kishon Vijay Abraham I

Hi Greg,

Stephen Rothwell reported a issue with my previous pull request
w.r.t missing Signed-off-by committer. I've fixed that in this pull
request.

It adds a new USB phy driver for Ralink SoC, add support for PCIe and
SATA PHY in phy-mt65xx-usb3 driver, add support for allwinner A83T
USB PHY and Qualcomm IPQ8074 in sun4i-usb-phy driver and
qcom-qmp-phy driver respectively.

Please let me know if I have to make any changes.

Thanks
Kishon

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:

  Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
tags/phy-for-4.14_v2

for you to fetch changes up to d9c51f4c53ae2af03aa8bd001d46f21b0adcdab8:

  phy: brcm-sata: fix a timeout test in init (2017-08-22 10:11:27 +0530)


phy: for 4.14

 *) Add USB PHY driver for Ralink SoC
 *) Make phy-mt65xx-usb3 driver support PCIe and SATA phy
 *) Add mediatek directory and rename phy-mt65xx-usb3 to phy-mtk-tphy.c
since it now supports USB3.0, PCIe and SATA PHYs
 *) Make sun4i-usb-phy driver support USB PHYs for A83T SoC
 *) Make phy-qcom-qmp driver support USB PHYs for IPQ8074 SoC
 *) Make rockchip-inno-usb2 driver support usb2-phy for rv1108 SoC
 *) Minor fixes in phy drivers

Signed-off-by: Kishon Vijay Abraham I 


Chen-Yu Tsai (4):
  dt-bindings: phy: sun4i-usb-phy: Add property descriptions for H3
  dt-bindings: phy: sun4i-usb-phy: Add compatible string for A83T
  phy: sun4i-usb: Support secondary clock for HSIC PHY
  phy: sun4i-usb: Support A83T USB PHYs

Chunfeng Yun (3):
  dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file
  phy: phy-mt65xx-usb3: add mediatek directory and rename file
  phy: samsung: use of_device_get_match_data()

Dan Carpenter (3):
  phy: phy-twl4030-usb: silence an uninitialized variable warning
  phy: cpcap-usb: remove a stray tab
  phy: brcm-sata: fix a timeout test in init

Frank Wang (5):
  phy: rockchip-inno-usb2: add support for rockchip,usbgrf property
  dt-bindings: phy-rockchip-inno-usb2: add rockchip,usbgrf property
  phy: rockchip-inno-usb2: add support for otg-mux interrupt
  dt-bindings: phy-rockchip-inno-usb2: add otg-mux interrupt
  phy: rockchip-inno-usb2: add support of usb2-phy for rv1108 SoCs

John Crispin (2):
  dt-bindings: phy: Add bindings for ralink-usb PHY
  phy: ralink-usb: add driver for Mediatek/Ralink

Quentin Schulz (1):
  phy: allwinner: phy-sun4i-usb: Add log when probing

Roger Quadros (1):
  phy: ti-pipe3: Use TRM recommended settings for SATA DPLL

Ryder Lee (2):
  phy: phy-mt65xx-usb3: add PCIe PHY support
  phy: phy-mt65xx-usb3: add SATA PHY support

Shawn Lin (1):
  phy: rockchip-typec: remove unused dfp variable

Varadarajan Narayanan (4):
  dt-bindings: phy: qmp: Add output-clock-names
  dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074
  phy: qcom-qmp: Fix phy pipe clock name
  phy: qcom-qmp: Add support for IPQ8074

Vivek Gautam (1):
  phy: qcom-qmp: Fix failure path in phy_init functions

 Documentation/devicetree/bindings/phy/{phy-mt65xx-usb.txt => phy-mtk-tphy.txt} 
|  17 ++--
 Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt   
|  11 ++-
 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
|  11 +++
 Documentation/devicetree/bindings/phy/ralink-usb-phy.txt   
|  23 +
 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
|  10 ++-
 MAINTAINERS
|   2 +-
 drivers/phy/Kconfig
|  10 +--
 drivers/phy/Makefile   
|   3 +-
 drivers/phy/allwinner/phy-sun4i-usb.c  
| 112 
 drivers/phy/broadcom/phy-brcm-sata.c   
|   2 +-
 drivers/phy/mediatek/Kconfig   
|  14 +++
 drivers/phy/mediatek/Makefile  
|   5 ++
 drivers/phy/{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c} 
| 557 
+++---
 drivers/phy/motorola/phy-cpcap-usb.c   
|   2 +-
 drivers/phy/qualcomm/phy-qcom-qmp.c
| 162 ++-
 drivers/phy/ralink/Kconfig 
|  11 +++
 drivers/phy/ralink/Makefile
|   1 +

Re: [PATCH 2/2] sched/fair: Fix use of NULL with find_idlest_group

2017-08-21 Thread Joel Fernandes

Hi Peter,

On Mon, Aug 21, 2017 at 2:14 PM, Peter Zijlstra  wrote:
> On Mon, Aug 21, 2017 at 04:21:28PM +0100, Brendan Jackman wrote:
>> The current use of returning NULL from find_idlest_group is broken in
>> two cases:
>>
>> a1) The local group is not allowed.
>>
>>In this case, we currently do not change this_runnable_load or
>>this_avg_load from its initial value of 0, which means we return
>>NULL regardless of the load of the other, allowed groups. This
>>results in pointlessly continuing the find_idlest_group search
>>within the local group and then returning prev_cpu from
>>select_task_rq_fair.
>
>> b) smp_processor_id() is the "idlest" and != prev_cpu.
>>
>>find_idlest_group also returns NULL when the local group is
>>allowed and is the idlest. The caller then continues the
>>find_idlest_group search at a lower level of the current CPU's
>>sched_domain hierarchy. However new_cpu is not updated. This means
>>the search is pointless and we return prev_cpu from
>>select_task_rq_fair.
>>
>
> I think its much simpler than that.. but its late, so who knows ;-)
>
> Both cases seem predicated on the assumption that we'll return @cpu when
> we don't find any idler CPU. Consider, if the local group is the idlest,
> we should stick with @cpu and simply proceed with the child domain.
>
> The confusion, and the bugs, seem to have snuck in when we started
> considering @prev_cpu, whenever that was. The below is mostly code
> movement to put that whole while(sd) loop into its own function.
>
> The effective change is setting @new_cpu = @cpu when we start that loop:
>

> ---
>  kernel/sched/fair.c | 83 
> +++--
>  1 file changed, 48 insertions(+), 35 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c77e4b1d51c0..3e77265c480a 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5588,10 +5588,10 @@ static unsigned long capacity_spare_wake(int cpu, 
> struct task_struct *p)
>  }
>
>  /*
> - * find_idlest_cpu - find the idlest cpu among the cpus in group.
> + * find_idlest_group_cpu - find the idlest cpu among the cpus in group.
>   */
>  static int
> -find_idlest_cpu(struct sched_group *group, struct task_struct *p, int 
> this_cpu)
> +find_idlest_group_cpu(struct sched_group *group, struct task_struct *p, int 
> this_cpu)
>  {
> unsigned long load, min_load = ULONG_MAX;
> unsigned int min_exit_latency = UINT_MAX;
> @@ -5640,6 +5640,50 @@ static unsigned long capacity_spare_wake(int cpu, 
> struct task_struct *p)
> return shallowest_idle_cpu != -1 ? shallowest_idle_cpu : 
> least_loaded_cpu;
>  }
>
> +static int
> +find_idlest_cpu(struct sched_domain *sd, struct task_struct *p, int cpu, int 
> sd_flag)
> +{
> +   struct sched_domain *tmp;
> +   int new_cpu = cpu;
> +
> +   while (sd) {
> +   struct sched_group *group;
> +   int weight;
> +
> +   if (!(sd->flags & sd_flag)) {
> +   sd = sd->child;
> +   continue;
> +   }
> +
> +   group = find_idlest_group(sd, p, cpu, sd_flag);
> +   if (!group) {
> +   sd = sd->child;
> +   continue;

But this will still have the issue of pointlessly searching in the
local_group when the idlest CPU is in the non-local group? Stemming
from the fact that find_idlest_group is broken if the local group is
not allowed.

I believe this is fixed by Brendan's patch? :

"Initializing this_runnable_load and this_avg_load to ULONG_MAX
   instead of 0. This means in case a1) we now return the idlest
   non-local group."


Hopefully I didn't missing something. Sorry if I did, thanks,

-Joel

Re: [PATCH 2/2] sched/fair: Fix use of NULL with find_idlest_group

2017-08-21 Thread Joel Fernandes

Hi Peter,

On Mon, Aug 21, 2017 at 2:14 PM, Peter Zijlstra  wrote:
> On Mon, Aug 21, 2017 at 04:21:28PM +0100, Brendan Jackman wrote:
>> The current use of returning NULL from find_idlest_group is broken in
>> two cases:
>>
>> a1) The local group is not allowed.
>>
>>In this case, we currently do not change this_runnable_load or
>>this_avg_load from its initial value of 0, which means we return
>>NULL regardless of the load of the other, allowed groups. This
>>results in pointlessly continuing the find_idlest_group search
>>within the local group and then returning prev_cpu from
>>select_task_rq_fair.
>
>> b) smp_processor_id() is the "idlest" and != prev_cpu.
>>
>>find_idlest_group also returns NULL when the local group is
>>allowed and is the idlest. The caller then continues the
>>find_idlest_group search at a lower level of the current CPU's
>>sched_domain hierarchy. However new_cpu is not updated. This means
>>the search is pointless and we return prev_cpu from
>>select_task_rq_fair.
>>
>
> I think its much simpler than that.. but its late, so who knows ;-)
>
> Both cases seem predicated on the assumption that we'll return @cpu when
> we don't find any idler CPU. Consider, if the local group is the idlest,
> we should stick with @cpu and simply proceed with the child domain.
>
> The confusion, and the bugs, seem to have snuck in when we started
> considering @prev_cpu, whenever that was. The below is mostly code
> movement to put that whole while(sd) loop into its own function.
>
> The effective change is setting @new_cpu = @cpu when we start that loop:
>

> ---
>  kernel/sched/fair.c | 83 
> +++--
>  1 file changed, 48 insertions(+), 35 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c77e4b1d51c0..3e77265c480a 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5588,10 +5588,10 @@ static unsigned long capacity_spare_wake(int cpu, 
> struct task_struct *p)
>  }
>
>  /*
> - * find_idlest_cpu - find the idlest cpu among the cpus in group.
> + * find_idlest_group_cpu - find the idlest cpu among the cpus in group.
>   */
>  static int
> -find_idlest_cpu(struct sched_group *group, struct task_struct *p, int 
> this_cpu)
> +find_idlest_group_cpu(struct sched_group *group, struct task_struct *p, int 
> this_cpu)
>  {
> unsigned long load, min_load = ULONG_MAX;
> unsigned int min_exit_latency = UINT_MAX;
> @@ -5640,6 +5640,50 @@ static unsigned long capacity_spare_wake(int cpu, 
> struct task_struct *p)
> return shallowest_idle_cpu != -1 ? shallowest_idle_cpu : 
> least_loaded_cpu;
>  }
>
> +static int
> +find_idlest_cpu(struct sched_domain *sd, struct task_struct *p, int cpu, int 
> sd_flag)
> +{
> +   struct sched_domain *tmp;
> +   int new_cpu = cpu;
> +
> +   while (sd) {
> +   struct sched_group *group;
> +   int weight;
> +
> +   if (!(sd->flags & sd_flag)) {
> +   sd = sd->child;
> +   continue;
> +   }
> +
> +   group = find_idlest_group(sd, p, cpu, sd_flag);
> +   if (!group) {
> +   sd = sd->child;
> +   continue;

But this will still have the issue of pointlessly searching in the
local_group when the idlest CPU is in the non-local group? Stemming
from the fact that find_idlest_group is broken if the local group is
not allowed.

I believe this is fixed by Brendan's patch? :

"Initializing this_runnable_load and this_avg_load to ULONG_MAX
   instead of 0. This means in case a1) we now return the idlest
   non-local group."


Hopefully I didn't missing something. Sorry if I did, thanks,

-Joel

Re: [PATCH v4 1/9] ASoC: rt5514: Avoid legacy dai naming

2017-08-21 Thread jeffy


Hi Mark,

thanks for your reply.

On 08/22/2017 01:31 AM, Mark Brown wrote:

On Fri, Aug 18, 2017 at 11:03:46PM +0800, jeffy wrote:


when using legacy dai naming, the dai->name for rt5514-spi would be the dev
name, which is spi2.0 with my local 4.4 kernel, and would be spi32765.0 with
upstream kernel.


It would be better to fix the code to not need a name if the device by
itself is unambiguous.



right...

i'm not familiar with the soc core codes, would these make sense?

1/ consider match when the of nodes are the same:

@@ -978,9 +978,10 @@ struct snd_soc_dai *snd_soc_find_dai(
if (dlc->name && strcmp(component->name, dlc->name))
continue;
list_for_each_entry(dai, >dai_list, list) {
+   if (dlc->of_node && dai->dev->of_node == 
dlc->of_node)

+   return dai;

or
2/ return the first dai when there's only one:

@@ -977,10 +977,11 @@ struct snd_soc_dai *snd_soc_find_dai(
continue;
if (dlc->name && strcmp(component->name, dlc->name))
continue;
+   if (component->num_dai == 1)
+   return >dai_list[0];
list_for_each_entry(dai, >dai_list, list) {

or
3/ also check for dai driver name:

@@ -978,9 +978,10 @@ struct snd_soc_dai *snd_soc_find_dai(
if (dlc->name && strcmp(component->name, dlc->name))
continue;
list_for_each_entry(dai, >dai_list, list) {
-   if (dlc->dai_name && strcmp(dai->name, 
dlc->dai_name))
+   if (dlc->dai_name && strcmp(dai->name, 
dlc->dai_name)

+   && strcmp(dai->driver->name, dlc->dai_name))
continue;

Re: [PATCH v4 1/9] ASoC: rt5514: Avoid legacy dai naming

2017-08-21 Thread jeffy


Hi Mark,

thanks for your reply.

On 08/22/2017 01:31 AM, Mark Brown wrote:

On Fri, Aug 18, 2017 at 11:03:46PM +0800, jeffy wrote:


when using legacy dai naming, the dai->name for rt5514-spi would be the dev
name, which is spi2.0 with my local 4.4 kernel, and would be spi32765.0 with
upstream kernel.


It would be better to fix the code to not need a name if the device by
itself is unambiguous.



right...

i'm not familiar with the soc core codes, would these make sense?

1/ consider match when the of nodes are the same:

@@ -978,9 +978,10 @@ struct snd_soc_dai *snd_soc_find_dai(
if (dlc->name && strcmp(component->name, dlc->name))
continue;
list_for_each_entry(dai, >dai_list, list) {
+   if (dlc->of_node && dai->dev->of_node == 
dlc->of_node)

+   return dai;

or
2/ return the first dai when there's only one:

@@ -977,10 +977,11 @@ struct snd_soc_dai *snd_soc_find_dai(
continue;
if (dlc->name && strcmp(component->name, dlc->name))
continue;
+   if (component->num_dai == 1)
+   return >dai_list[0];
list_for_each_entry(dai, >dai_list, list) {

or
3/ also check for dai driver name:

@@ -978,9 +978,10 @@ struct snd_soc_dai *snd_soc_find_dai(
if (dlc->name && strcmp(component->name, dlc->name))
continue;
list_for_each_entry(dai, >dai_list, list) {
-   if (dlc->dai_name && strcmp(dai->name, 
dlc->dai_name))
+   if (dlc->dai_name && strcmp(dai->name, 
dlc->dai_name)

+   && strcmp(dai->driver->name, dlc->dai_name))
continue;

Re: [PATCH v5 0/4] Add support for ThunderX2 pmu events using json files

2017-08-21 Thread Ganapatrao Kulkarni

Hi Arnaldo, Will,

are there any comments on this series?


On Wed, Aug 16, 2017 at 12:40 PM, Ganapatrao Kulkarni
 wrote:
> Extending json/jevent framework for parsing arm64 event files.
> Adding jevents for ThunderX2 implementation defined PMU events.
>
> v5:
>- Addressed comments from Arnaldo.
>- Rebased to 4.13-rc5
>
> v4:
>- Rebased to 4.13-rc1
>
> v3:
>- Addressed comments from Will Deacon and Jayachandran C.
>- Rebased to 4.12-rc1
>
> v2:
>- Updated as per Mark Rutland's suggestions.
>- Added provision for get_cpuid_str to get cpu id string
>  from associated cpus of pmu core device.
>
> v1: Initial patchset.
>
> Ganapatrao Kulkarni (4):
>   perf utils: passing pmu as a parameter to function get_cpuid_str
>   perf tools arm64: Add support for get_cpuid_str function.
>   perf utils: Add helper function is_pmu_core to detect PMU CORE devices
>   perf vendor events arm64: Add ThunderX2 implementation defined pmu
> core events
>
>  tools/perf/arch/arm64/util/Build   |  1 +
>  tools/perf/arch/arm64/util/header.c| 61 +
>  tools/perf/arch/powerpc/util/header.c  |  2 +-
>  tools/perf/arch/x86/util/header.c  |  2 +-
>  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>  .../arm64/thunderx2/implementation-defined.json| 62 
> ++
>  tools/perf/util/header.h   |  3 +-
>  tools/perf/util/pmu.c  | 53 +++---
>  8 files changed, 188 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/header.c
>  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>  create mode 100644 
> tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
>
> --
> 2.9.4
>

thanks
Ganapat

Re: [PATCH v5 0/4] Add support for ThunderX2 pmu events using json files

2017-08-21 Thread Ganapatrao Kulkarni

Hi Arnaldo, Will,

are there any comments on this series?


On Wed, Aug 16, 2017 at 12:40 PM, Ganapatrao Kulkarni
 wrote:
> Extending json/jevent framework for parsing arm64 event files.
> Adding jevents for ThunderX2 implementation defined PMU events.
>
> v5:
>- Addressed comments from Arnaldo.
>- Rebased to 4.13-rc5
>
> v4:
>- Rebased to 4.13-rc1
>
> v3:
>- Addressed comments from Will Deacon and Jayachandran C.
>- Rebased to 4.12-rc1
>
> v2:
>- Updated as per Mark Rutland's suggestions.
>- Added provision for get_cpuid_str to get cpu id string
>  from associated cpus of pmu core device.
>
> v1: Initial patchset.
>
> Ganapatrao Kulkarni (4):
>   perf utils: passing pmu as a parameter to function get_cpuid_str
>   perf tools arm64: Add support for get_cpuid_str function.
>   perf utils: Add helper function is_pmu_core to detect PMU CORE devices
>   perf vendor events arm64: Add ThunderX2 implementation defined pmu
> core events
>
>  tools/perf/arch/arm64/util/Build   |  1 +
>  tools/perf/arch/arm64/util/header.c| 61 +
>  tools/perf/arch/powerpc/util/header.c  |  2 +-
>  tools/perf/arch/x86/util/header.c  |  2 +-
>  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>  .../arm64/thunderx2/implementation-defined.json| 62 
> ++
>  tools/perf/util/header.h   |  3 +-
>  tools/perf/util/pmu.c  | 53 +++---
>  8 files changed, 188 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/header.c
>  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>  create mode 100644 
> tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
>
> --
> 2.9.4
>

thanks
Ganapat

linux-next: manual merge of the rcu tree with the tip tree

2017-08-21 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the rcu tree got a conflict in:

  arch/x86/mm/tlb.c

between commit:

  94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")

from the tip tree and commit:

  3ed668659e95 ("membarrier: Document scheduler barrier requirements")

from the rcu tree.

I am pretty sure I have reported this before ... but the latter commit
has been rebased.

I fixed it up (I again just dropped the additional commit in
switch_mm_irqs_off()) and can carry the fix as necessary. This is now
fixed as far as linux-next is concerned, but any non trivial conflicts
should be mentioned to your upstream maintainer when your tree is
submitted for merging.  You may also want to consider cooperating with
the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the rcu tree with the tip tree

2017-08-21 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the rcu tree got a conflict in:

  arch/x86/mm/tlb.c

between commit:

  94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")

from the tip tree and commit:

  3ed668659e95 ("membarrier: Document scheduler barrier requirements")

from the rcu tree.

I am pretty sure I have reported this before ... but the latter commit
has been rebased.

I fixed it up (I again just dropped the additional commit in
switch_mm_irqs_off()) and can carry the fix as necessary. This is now
fixed as far as linux-next is concerned, but any non trivial conflicts
should be mentioned to your upstream maintainer when your tree is
submitted for merging.  You may also want to consider cooperating with
the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

[PATCH v2 3/4] net: phy: realtek: add disable RX internal delay mode

2017-08-21 Thread Icenowy Zheng

From: Icenowy Zheng 

Some RTL8211E chips have broken GbE function, which needs a hack to
fix. It's said that this fix will affect the performance on not-buggy
PHYs, so it should only be enabled on boards with the broken PHY.
Currently only some Pine64+ boards are known to have this issue.

This hack is said to disable RX relay for RTL8211E according to Realtek.
So implement it as RGMII-TXID mode.

As this hack is not documented on the datasheet at all, it contains
magic numbers, and could not be revealed. These magic numbers are
received from Realtek via Pine64.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Used RGMII_TXID phy mode.

 drivers/net/phy/realtek.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index d820d00addf6..8306b6abaaa8 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -13,6 +13,7 @@
  * option) any later version.
  *
  */
+#include 
 #include 
 #include 
 
@@ -26,6 +27,8 @@
 #define RTL8211_PAGE_SELECT0x1f
 
 #define RTL8211E_INER_LINK_STATUS 0x400
+#define RTL8211E_EXT_PAGE_SELECT 0x1e
+#define RTL8211E_EXT_PAGE  0x7
 
 #define RTL8211F_INER_LINK_STATUS 0x0010
 #define RTL8211F_INSR  0x1d
@@ -121,6 +124,33 @@ static int rtl8211f_config_init(struct phy_device *phydev)
return 0;
 }
 
+static int rtl8211e_config_init(struct phy_device *phydev)
+{
+   struct device *dev = >mdio.dev;
+   struct device_node *of_node = dev->of_node;
+   int ret;
+
+   ret = genphy_config_init(phydev);
+   if (ret < 0)
+   return ret;
+
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+   /* Disable the RX internal delay here.
+*
+* All the magic numbers are not documented on RTL8211E
+* datasheet. They're said to be from Realtek by Pine64.
+*/
+   phy_write(phydev, RTL8211_PAGE_SELECT, RTL8211E_EXT_PAGE);
+   phy_write(phydev, RTL8211E_EXT_PAGE_SELECT, 0xa4);
+   phy_write(phydev, 0x1c, 0xb591);
+
+   /* Restore to default page 0 */
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0);
+   }
+
+   return 0;
+}
+
 static struct phy_driver realtek_drvs[] = {
{
.phy_id = 0x8201,
@@ -159,6 +189,7 @@ static struct phy_driver realtek_drvs[] = {
.features   = PHY_GBIT_FEATURES,
.flags  = PHY_HAS_INTERRUPT,
.config_aneg= _config_aneg,
+   .config_init= rtl8211e_config_init,
.read_status= _read_status,
.ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
-- 
2.13.5

[PATCH v2 3/4] net: phy: realtek: add disable RX internal delay mode

2017-08-21 Thread Icenowy Zheng

From: Icenowy Zheng 

Some RTL8211E chips have broken GbE function, which needs a hack to
fix. It's said that this fix will affect the performance on not-buggy
PHYs, so it should only be enabled on boards with the broken PHY.
Currently only some Pine64+ boards are known to have this issue.

This hack is said to disable RX relay for RTL8211E according to Realtek.
So implement it as RGMII-TXID mode.

As this hack is not documented on the datasheet at all, it contains
magic numbers, and could not be revealed. These magic numbers are
received from Realtek via Pine64.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- Used RGMII_TXID phy mode.

 drivers/net/phy/realtek.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index d820d00addf6..8306b6abaaa8 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -13,6 +13,7 @@
  * option) any later version.
  *
  */
+#include 
 #include 
 #include 
 
@@ -26,6 +27,8 @@
 #define RTL8211_PAGE_SELECT0x1f
 
 #define RTL8211E_INER_LINK_STATUS 0x400
+#define RTL8211E_EXT_PAGE_SELECT 0x1e
+#define RTL8211E_EXT_PAGE  0x7
 
 #define RTL8211F_INER_LINK_STATUS 0x0010
 #define RTL8211F_INSR  0x1d
@@ -121,6 +124,33 @@ static int rtl8211f_config_init(struct phy_device *phydev)
return 0;
 }
 
+static int rtl8211e_config_init(struct phy_device *phydev)
+{
+   struct device *dev = >mdio.dev;
+   struct device_node *of_node = dev->of_node;
+   int ret;
+
+   ret = genphy_config_init(phydev);
+   if (ret < 0)
+   return ret;
+
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
+   /* Disable the RX internal delay here.
+*
+* All the magic numbers are not documented on RTL8211E
+* datasheet. They're said to be from Realtek by Pine64.
+*/
+   phy_write(phydev, RTL8211_PAGE_SELECT, RTL8211E_EXT_PAGE);
+   phy_write(phydev, RTL8211E_EXT_PAGE_SELECT, 0xa4);
+   phy_write(phydev, 0x1c, 0xb591);
+
+   /* Restore to default page 0 */
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0);
+   }
+
+   return 0;
+}
+
 static struct phy_driver realtek_drvs[] = {
{
.phy_id = 0x8201,
@@ -159,6 +189,7 @@ static struct phy_driver realtek_drvs[] = {
.features   = PHY_GBIT_FEATURES,
.flags  = PHY_HAS_INTERRUPT,
.config_aneg= _config_aneg,
+   .config_init= rtl8211e_config_init,
.read_status= _read_status,
.ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
-- 
2.13.5

[PATCH v2 2/4] net: phy: realtek: change macro name for page select register

2017-08-21 Thread Icenowy Zheng

From: Icenowy Zheng 

The page select register also exists on RTL8211E PHY (although it
behaves slightly differently).

Change the register macro name to remove the F.

Signed-off-by: Icenowy Zheng 
---
 drivers/net/phy/realtek.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 9cbe645e3d89..d820d00addf6 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -22,11 +22,13 @@
 #define RTL821x_INER   0x12
 #define RTL821x_INER_INIT  0x6400
 #define RTL821x_INSR   0x13
+
+#define RTL8211_PAGE_SELECT0x1f
+
 #define RTL8211E_INER_LINK_STATUS 0x400
 
 #define RTL8211F_INER_LINK_STATUS 0x0010
 #define RTL8211F_INSR  0x1d
-#define RTL8211F_PAGE_SELECT   0x1f
 #define RTL8211F_TX_DELAY  0x100
 
 MODULE_DESCRIPTION("Realtek PHY driver");
@@ -46,10 +48,10 @@ static int rtl8211f_ack_interrupt(struct phy_device *phydev)
 {
int err;
 
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0xa43);
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0xa43);
err = phy_read(phydev, RTL8211F_INSR);
/* restore to default page 0 */
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0x0);
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0x0);
 
return (err < 0) ? err : 0;
 }
@@ -102,7 +104,7 @@ static int rtl8211f_config_init(struct phy_device *phydev)
if (ret < 0)
return ret;
 
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0xd08);
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0xd08);
reg = phy_read(phydev, 0x11);
 
/* enable TX-delay for rgmii-id and rgmii-txid, otherwise disable it */
@@ -114,7 +116,7 @@ static int rtl8211f_config_init(struct phy_device *phydev)
 
phy_write(phydev, 0x11, reg);
/* restore to default page 0 */
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0x0);
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0x0);
 
return 0;
 }
-- 
2.13.5

[PATCH v2 2/4] net: phy: realtek: change macro name for page select register

2017-08-21 Thread Icenowy Zheng

From: Icenowy Zheng 

The page select register also exists on RTL8211E PHY (although it
behaves slightly differently).

Change the register macro name to remove the F.

Signed-off-by: Icenowy Zheng 
---
 drivers/net/phy/realtek.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 9cbe645e3d89..d820d00addf6 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -22,11 +22,13 @@
 #define RTL821x_INER   0x12
 #define RTL821x_INER_INIT  0x6400
 #define RTL821x_INSR   0x13
+
+#define RTL8211_PAGE_SELECT0x1f
+
 #define RTL8211E_INER_LINK_STATUS 0x400
 
 #define RTL8211F_INER_LINK_STATUS 0x0010
 #define RTL8211F_INSR  0x1d
-#define RTL8211F_PAGE_SELECT   0x1f
 #define RTL8211F_TX_DELAY  0x100
 
 MODULE_DESCRIPTION("Realtek PHY driver");
@@ -46,10 +48,10 @@ static int rtl8211f_ack_interrupt(struct phy_device *phydev)
 {
int err;
 
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0xa43);
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0xa43);
err = phy_read(phydev, RTL8211F_INSR);
/* restore to default page 0 */
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0x0);
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0x0);
 
return (err < 0) ? err : 0;
 }
@@ -102,7 +104,7 @@ static int rtl8211f_config_init(struct phy_device *phydev)
if (ret < 0)
return ret;
 
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0xd08);
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0xd08);
reg = phy_read(phydev, 0x11);
 
/* enable TX-delay for rgmii-id and rgmii-txid, otherwise disable it */
@@ -114,7 +116,7 @@ static int rtl8211f_config_init(struct phy_device *phydev)
 
phy_write(phydev, 0x11, reg);
/* restore to default page 0 */
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0x0);
+   phy_write(phydev, RTL8211_PAGE_SELECT, 0x0);
 
return 0;
 }
-- 
2.13.5

[PATCH v2 4/4] arm64: allwinner: a64: disable the RTL8211E internal RX delay on Pine64+

2017-08-21 Thread Icenowy Zheng

Some Pine64+ boards have a broken RTL8211E PHY, which cannot work
reliably in 1000Base-T mode with default configuration.

A solution is passed to Pine64, which is said to be disabling the
internal RX delay of the PHY.

Enable the hack by set the PHY mode to RGMII-TXID.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- It can be merged now as dwmac-sun8i entered mainline.
- Use phy-mode rgmii-txid instead of custom property.

 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 24f1aac366d6..ed715426fffc 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -52,7 +52,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-txid";
phy-handle = <_rgmii_phy>;
status = "okay";
 };
-- 
2.13.5

[PATCH v2 4/4] arm64: allwinner: a64: disable the RTL8211E internal RX delay on Pine64+

2017-08-21 Thread Icenowy Zheng

Some Pine64+ boards have a broken RTL8211E PHY, which cannot work
reliably in 1000Base-T mode with default configuration.

A solution is passed to Pine64, which is said to be disabling the
internal RX delay of the PHY.

Enable the hack by set the PHY mode to RGMII-TXID.

Signed-off-by: Icenowy Zheng 
---
Changes in v2:
- It can be merged now as dwmac-sun8i entered mainline.
- Use phy-mode rgmii-txid instead of custom property.

 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 24f1aac366d6..ed715426fffc 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -52,7 +52,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-   phy-mode = "rgmii";
+   phy-mode = "rgmii-txid";
phy-handle = <_rgmii_phy>;
status = "okay";
 };
-- 
2.13.5

[PATCH v2 1/4] net: stmmac: dwmac-sun8i: support RGMII modes with PHY internal delay

2017-08-21 Thread Icenowy Zheng

Some boards uses a PHY with internal delay with an Allwinner SoC.

Support these PHY modes in the driver.

As the driver has no configuration registers for these modes, just treat
them as ordinary RGMII.

Signed-off-by: Icenowy Zheng 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index fffd6d5fc907..2af680cac497 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -723,6 +723,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
/* default */
break;
case PHY_INTERFACE_MODE_RGMII:
+   case PHY_INTERFACE_MODE_RGMII_ID:
+   case PHY_INTERFACE_MODE_RGMII_RXID:
+   case PHY_INTERFACE_MODE_RGMII_TXID:
reg |= SYSCON_EPIT | SYSCON_ETCS_INT_GMII;
break;
case PHY_INTERFACE_MODE_RMII:
-- 
2.13.5

[PATCH v2 1/4] net: stmmac: dwmac-sun8i: support RGMII modes with PHY internal delay

2017-08-21 Thread Icenowy Zheng

Some boards uses a PHY with internal delay with an Allwinner SoC.

Support these PHY modes in the driver.

As the driver has no configuration registers for these modes, just treat
them as ordinary RGMII.

Signed-off-by: Icenowy Zheng 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index fffd6d5fc907..2af680cac497 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -723,6 +723,9 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv *priv)
/* default */
break;
case PHY_INTERFACE_MODE_RGMII:
+   case PHY_INTERFACE_MODE_RGMII_ID:
+   case PHY_INTERFACE_MODE_RGMII_RXID:
+   case PHY_INTERFACE_MODE_RGMII_TXID:
reg |= SYSCON_EPIT | SYSCON_ETCS_INT_GMII;
break;
case PHY_INTERFACE_MODE_RMII:
-- 
2.13.5

[PATCH v2 0/4] Workaround broken RTL8211E on some Pine64+ boards

2017-08-21 Thread Icenowy Zheng

Some Pine64+ boards come with bad RTL8211E PHYs, which cannot work reliably
unless do some hack. According to Pine64 people, Realtek describes the hack
as totally disabling RX delay, and it's not documented at all.

This patchset introduces the workaround on Pine64+.

The first patch adds RGMII variants' support to the dwmac-sun8i driver.

The second patch renames some macros in RTL PHY driver, and the third
patch introduces the hack as the "RGMII-TXID" mode of the PHY.

The fourth patch enables the hack in the device tree.

Icenowy Zheng (4):
  net: stmmac: dwmac-sun8i: support RGMII modes with PHY internal delay
  net: phy: realtek: change macro name for page select register
  net: phy: realtek: add disable RX internal delay mode
  arm64: allwinner: a64: disable the RTL8211E internal RX delay on
Pine64+

 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c  |  3 ++
 drivers/net/phy/realtek.c  | 43 +++---
 3 files changed, 42 insertions(+), 6 deletions(-)

-- 
2.13.5

[PATCH v2 0/4] Workaround broken RTL8211E on some Pine64+ boards

2017-08-21 Thread Icenowy Zheng

Some Pine64+ boards come with bad RTL8211E PHYs, which cannot work reliably
unless do some hack. According to Pine64 people, Realtek describes the hack
as totally disabling RX delay, and it's not documented at all.

This patchset introduces the workaround on Pine64+.

The first patch adds RGMII variants' support to the dwmac-sun8i driver.

The second patch renames some macros in RTL PHY driver, and the third
patch introduces the hack as the "RGMII-TXID" mode of the PHY.

The fourth patch enables the hack in the device tree.

Icenowy Zheng (4):
  net: stmmac: dwmac-sun8i: support RGMII modes with PHY internal delay
  net: phy: realtek: change macro name for page select register
  net: phy: realtek: add disable RX internal delay mode
  arm64: allwinner: a64: disable the RTL8211E internal RX delay on
Pine64+

 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c  |  3 ++
 drivers/net/phy/realtek.c  | 43 +++---
 3 files changed, 42 insertions(+), 6 deletions(-)

-- 
2.13.5

linux-next: manual merge of the tip tree with the iommu tree

2017-08-21 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  drivers/iommu/amd_iommu.c
  drivers/iommu/amd_iommu_init.c
  drivers/iommu/amd_iommu_proto.h
  drivers/iommu/amd_iommu_types.h

between commits:

  4c232a708be1 ("iommu/amd: Detect pre enabled translation")
  9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
  07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
  daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")

from the iommu tree and commit:

  2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/iommu/amd_iommu.c
index 31bce367866c,4ad7e5e31943..
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@@ -1476,10 -1538,10 +1478,10 @@@ static int iommu_map_page(struct protec
return -EBUSY;
  
if (count > 1) {
-   __pte = PAGE_SIZE_PTE(phys_addr, page_size);
+   __pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
 -  __pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
 +  __pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
} else
-   __pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
 -  __pte = __sme_set(phys_addr) | IOMMU_PTE_P | IOMMU_PTE_FC;
++  __pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
  
if (prot & IOMMU_PROT_IR)
__pte |= IOMMU_PTE_IR;
diff --cc drivers/iommu/amd_iommu_init.c
index ff8887ac,2292a6cece76..
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@@ -29,6 -29,8 +29,7 @@@
  #include 
  #include 
  #include 
 -#include 
+ #include 
  #include 
  #include 
  #include 
diff --cc drivers/iommu/amd_iommu_proto.h
index 90e62e9b01c5,3f12fb2338ea..
--- a/drivers/iommu/amd_iommu_proto.h
+++ b/drivers/iommu/amd_iommu_proto.h
@@@ -87,6 -87,14 +87,16 @@@ static inline bool iommu_feature(struc
return !!(iommu->features & f);
  }
  
+ static inline u64 iommu_virt_to_phys(void *vaddr)
+ {
+   return (u64)__sme_set(virt_to_phys(vaddr));
+ }
+ 
+ static inline void *iommu_phys_to_virt(unsigned long paddr)
+ {
+   return phys_to_virt(__sme_clr(paddr));
+ }
+ 
 +extern bool translation_pre_enabled(struct amd_iommu *iommu);
 +extern struct iommu_dev_data *get_dev_data(struct device *dev);
  #endif /* _ASM_X86_AMD_IOMMU_PROTO_H  */
diff --cc drivers/iommu/amd_iommu_types.h
index 5f775fef341c,8591f43c467c..
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@@ -361,8 -343,8 +361,8 @@@
  #define GCR3_VALID0x01ULL
  
  #define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
 -#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
 +#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
- #define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
+ #define IOMMU_PTE_PAGE(pte) (iommu_phys_to_virt((pte) & IOMMU_PAGE_MASK))
  #define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
  
  #define IOMMU_PROT_MASK 0x03

linux-next: manual merge of the tip tree with the iommu tree

2017-08-21 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  drivers/iommu/amd_iommu.c
  drivers/iommu/amd_iommu_init.c
  drivers/iommu/amd_iommu_proto.h
  drivers/iommu/amd_iommu_types.h

between commits:

  4c232a708be1 ("iommu/amd: Detect pre enabled translation")
  9494ea90a56d ("Revert "iommu/amd: Suppress IO_PAGE_FAULTs in kdump kernel"")
  07a80a6b5920 ("iommu/amd: Define bit fields for DTE particularly")
  daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")

from the iommu tree and commit:

  2543a786aa25 ("iommu/amd: Allow the AMD IOMMU to work with memory encryption")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/iommu/amd_iommu.c
index 31bce367866c,4ad7e5e31943..
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@@ -1476,10 -1538,10 +1478,10 @@@ static int iommu_map_page(struct protec
return -EBUSY;
  
if (count > 1) {
-   __pte = PAGE_SIZE_PTE(phys_addr, page_size);
+   __pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
 -  __pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_P | IOMMU_PTE_FC;
 +  __pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
} else
-   __pte = phys_addr | IOMMU_PTE_PR | IOMMU_PTE_FC;
 -  __pte = __sme_set(phys_addr) | IOMMU_PTE_P | IOMMU_PTE_FC;
++  __pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
  
if (prot & IOMMU_PROT_IR)
__pte |= IOMMU_PTE_IR;
diff --cc drivers/iommu/amd_iommu_init.c
index ff8887ac,2292a6cece76..
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@@ -29,6 -29,8 +29,7 @@@
  #include 
  #include 
  #include 
 -#include 
+ #include 
  #include 
  #include 
  #include 
diff --cc drivers/iommu/amd_iommu_proto.h
index 90e62e9b01c5,3f12fb2338ea..
--- a/drivers/iommu/amd_iommu_proto.h
+++ b/drivers/iommu/amd_iommu_proto.h
@@@ -87,6 -87,14 +87,16 @@@ static inline bool iommu_feature(struc
return !!(iommu->features & f);
  }
  
+ static inline u64 iommu_virt_to_phys(void *vaddr)
+ {
+   return (u64)__sme_set(virt_to_phys(vaddr));
+ }
+ 
+ static inline void *iommu_phys_to_virt(unsigned long paddr)
+ {
+   return phys_to_virt(__sme_clr(paddr));
+ }
+ 
 +extern bool translation_pre_enabled(struct amd_iommu *iommu);
 +extern struct iommu_dev_data *get_dev_data(struct device *dev);
  #endif /* _ASM_X86_AMD_IOMMU_PROTO_H  */
diff --cc drivers/iommu/amd_iommu_types.h
index 5f775fef341c,8591f43c467c..
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@@ -361,8 -343,8 +361,8 @@@
  #define GCR3_VALID0x01ULL
  
  #define IOMMU_PAGE_MASK (((1ULL << 52) - 1) & ~0xfffULL)
 -#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_P)
 +#define IOMMU_PTE_PRESENT(pte) ((pte) & IOMMU_PTE_PR)
- #define IOMMU_PTE_PAGE(pte) (phys_to_virt((pte) & IOMMU_PAGE_MASK))
+ #define IOMMU_PTE_PAGE(pte) (iommu_phys_to_virt((pte) & IOMMU_PAGE_MASK))
  #define IOMMU_PTE_MODE(pte) (((pte) >> 9) & 0x07)
  
  #define IOMMU_PROT_MASK 0x03

Re: L0AN

2017-08-21 Thread softlink Int'L

Do you need a personal/business L0AN, if yes contact Softlink Int'L for more 
info

Re: L0AN

2017-08-21 Thread softlink Int'L

Do you need a personal/business L0AN, if yes contact Softlink Int'L for more 
info

[PATCH v1 2/3] arm: dts: add Nuvoton NPCM750 device tree

2017-08-21 Thread Brendan Higgins

Add a common device tree for all Nuvoton NPCM750 BMCs and a board
specific device tree for the NPCM750 (Poleg) evaluation board.

Signed-off-by: Brendan Higgins 
---
 .../devicetree/bindings/arm/npcm/npcm.txt  |   6 +
 arch/arm/boot/dts/nuvoton-npcm750-evb.dts  |  63 ++
 arch/arm/boot/dts/nuvoton-npcm750.dtsi | 222 +
 include/dt-bindings/clock/nuvoton,npcm7xx-clks.h   |  39 
 4 files changed, 330 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt
 create mode 100644 arch/arm/boot/dts/nuvoton-npcm750-evb.dts
 create mode 100644 arch/arm/boot/dts/nuvoton-npcm750.dtsi
 create mode 100644 include/dt-bindings/clock/nuvoton,npcm7xx-clks.h

diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.txt 
b/Documentation/devicetree/bindings/arm/npcm/npcm.txt
new file mode 100644
index ..19aabe9a7414
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/npcm/npcm.txt
@@ -0,0 +1,6 @@
+NPCM Platforms Device Tree Bindings
+---
+NPCM750 SoC
+Required root node properties:
+   - compatible = "nuvoton,npcm750";
+   - enable-method = "nuvoton,npcm7xx-smp"; required for dual core variant.
diff --git a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts 
b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
new file mode 100644
index ..10f523388dc1
--- /dev/null
+++ b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
@@ -0,0 +1,63 @@
+/*
+ * DTS file for all NPCM750 SoCs
+ *
+ * Copyright 2012 Tomer Maimon 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "nuvoton-npcm750.dtsi"
+
+/ {
+   model = "Nuvoton npcm750 Development Board (Device Tree)";
+   compatible = "nuvoton,npcm750";
+   enable-method = "nuvoton,npcm7xx-smp";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   memory {
+   reg = <0 0x4000>;
+   };
+
+   clocks {
+   clk: clock-controller@f0801000 {
+   status = "okay";
+   };
+   };
+
+   ahb {
+   };
+
+   apb {
+   watchdog1: watchdog@f0009000 {
+   status = "okay";
+   };
+
+   uart0: uart0@f0001000 {
+   status = "okay";
+   };
+
+   uart1: uart1@f0002000 {
+   status = "okay";
+   };
+
+   uart2: uart2@f0003000 {
+   status = "okay";
+   };
+
+   uart3: uart3@f0004000 {
+   status = "okay";
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/nuvoton-npcm750.dtsi 
b/arch/arm/boot/dts/nuvoton-npcm750.dtsi
new file mode 100644
index ..fc64550c49a6
--- /dev/null
+++ b/arch/arm/boot/dts/nuvoton-npcm750.dtsi
@@ -0,0 +1,222 @@
+/*
+ * DTSi file for the NPCM750 SoC
+ *
+ * Copyright 2012 Tomer Maimon 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "skeleton.dtsi"
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   clocks = < NPCM7XX_CLK_CPU>;
+   clock-names = "clk_cpu";
+   reg = <0>;
+   next-level-cache = <>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   clocks = < NPCM7XX_CLK_CPU>;
+   clock-names = "clk_cpu";
+   reg = <1>;
+   next-level-cache = <>;
+   };
+
+   };
+
+   L2: l2-cache {
+   compatible = "arm,pl310-cache";
+   reg = <0xf03fc000 0x8>;
+   interrupts = <0 21 4>;
+   cache-unified;
+   cache-level = <2>;
+   clocks = < NPCM7XX_CLK_AXI>;
+   clock-names = "clk_axi";
+   };
+
+   clocks {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+

[PATCH v1 2/3] arm: dts: add Nuvoton NPCM750 device tree

2017-08-21 Thread Brendan Higgins

Add a common device tree for all Nuvoton NPCM750 BMCs and a board
specific device tree for the NPCM750 (Poleg) evaluation board.

Signed-off-by: Brendan Higgins 
---
 .../devicetree/bindings/arm/npcm/npcm.txt  |   6 +
 arch/arm/boot/dts/nuvoton-npcm750-evb.dts  |  63 ++
 arch/arm/boot/dts/nuvoton-npcm750.dtsi | 222 +
 include/dt-bindings/clock/nuvoton,npcm7xx-clks.h   |  39 
 4 files changed, 330 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt
 create mode 100644 arch/arm/boot/dts/nuvoton-npcm750-evb.dts
 create mode 100644 arch/arm/boot/dts/nuvoton-npcm750.dtsi
 create mode 100644 include/dt-bindings/clock/nuvoton,npcm7xx-clks.h

diff --git a/Documentation/devicetree/bindings/arm/npcm/npcm.txt 
b/Documentation/devicetree/bindings/arm/npcm/npcm.txt
new file mode 100644
index ..19aabe9a7414
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/npcm/npcm.txt
@@ -0,0 +1,6 @@
+NPCM Platforms Device Tree Bindings
+---
+NPCM750 SoC
+Required root node properties:
+   - compatible = "nuvoton,npcm750";
+   - enable-method = "nuvoton,npcm7xx-smp"; required for dual core variant.
diff --git a/arch/arm/boot/dts/nuvoton-npcm750-evb.dts 
b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
new file mode 100644
index ..10f523388dc1
--- /dev/null
+++ b/arch/arm/boot/dts/nuvoton-npcm750-evb.dts
@@ -0,0 +1,63 @@
+/*
+ * DTS file for all NPCM750 SoCs
+ *
+ * Copyright 2012 Tomer Maimon 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "nuvoton-npcm750.dtsi"
+
+/ {
+   model = "Nuvoton npcm750 Development Board (Device Tree)";
+   compatible = "nuvoton,npcm750";
+   enable-method = "nuvoton,npcm7xx-smp";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   memory {
+   reg = <0 0x4000>;
+   };
+
+   clocks {
+   clk: clock-controller@f0801000 {
+   status = "okay";
+   };
+   };
+
+   ahb {
+   };
+
+   apb {
+   watchdog1: watchdog@f0009000 {
+   status = "okay";
+   };
+
+   uart0: uart0@f0001000 {
+   status = "okay";
+   };
+
+   uart1: uart1@f0002000 {
+   status = "okay";
+   };
+
+   uart2: uart2@f0003000 {
+   status = "okay";
+   };
+
+   uart3: uart3@f0004000 {
+   status = "okay";
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/nuvoton-npcm750.dtsi 
b/arch/arm/boot/dts/nuvoton-npcm750.dtsi
new file mode 100644
index ..fc64550c49a6
--- /dev/null
+++ b/arch/arm/boot/dts/nuvoton-npcm750.dtsi
@@ -0,0 +1,222 @@
+/*
+ * DTSi file for the NPCM750 SoC
+ *
+ * Copyright 2012 Tomer Maimon 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "skeleton.dtsi"
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   clocks = < NPCM7XX_CLK_CPU>;
+   clock-names = "clk_cpu";
+   reg = <0>;
+   next-level-cache = <>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   clocks = < NPCM7XX_CLK_CPU>;
+   clock-names = "clk_cpu";
+   reg = <1>;
+   next-level-cache = <>;
+   };
+
+   };
+
+   L2: l2-cache {
+   compatible = "arm,pl310-cache";
+   reg = <0xf03fc000 0x8>;
+   interrupts = <0 21 4>;
+   cache-unified;
+   cache-level = <2>;
+   clocks = < NPCM7XX_CLK_AXI>;
+   clock-names = "clk_axi";
+   };
+
+   clocks {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   clk: clock-controller@f0801000 {
+   compatible =

Re: [PATCH] mfd: intel-lpss: Put I2C and SPI controllers into reset state on suspend

2017-08-21 Thread Furquan Shaikh

Hello Lee,

Gentle ping. Do you see any issues with the following change?

Thanks,
Furquan

On Sun, Jul 23, 2017 at 11:02 PM, Furquan Shaikh  wrote:
>
> Commit 274e43edcda6f ("mfd: intel-lpss: Do not put device in reset
> state on suspend") changed the behavior on suspend by not putting LPSS
> controllers into reset. This was done because S3/S0ix fail if UART
> device is put into reset and no_console_suspend flag is enabled.
>
> Because of the above change, I2C controller gets into a bad state if
> it observes that the I2C lines are pulled low when power to I2C device
> is cut off during suspend (generally, I2C lines are pulled to power
> rail of the I2C device in order to ensure that there is no leakage
> because of the pulls when device is turned off). This results in the
> controller timing out for all future I2C operations after resume. It
> is primarily because of the following sequence of operations:
>
> During suspend:
> 1. I2C controller is disabled, but it is not put into reset.
> 2. Power to I2C device is cut off.
> 3. #2 results in the I2C lines being pulled low.
>
> ==> At this point the I2C controller gets into a bad state
>
> On resume:
> 1. Power to I2C device is enabled.
> 2. #2 results in the I2C lines being pulled high.
> 3. I2C controller is enabled.
>
> However, even after enabling the I2C controller, all future I2C xfers
> fail since the controller is in a bad state and does not attempt to
> make any transactions and hence times out.
>
> In order to ensure that the controller does not get into a bad state,
> this change puts it into reset if the controller type is not
> UART. With this change, the order of operations is:
>
> During suspend:
> 1. I2C controller is disabled and put into reset.
> 2. Power to I2C device is cut off.
> 3. #2 results in the I2C lines being pulled low.
>
> On resume:
> 1. Power to I2C device is enabled.
> 2. #2 results in the I2C lines being pulled high.
> 3. I2C controller is enabled and taken out of reset.
>
> Signed-off-by: Furquan Shaikh 
> ---
>  drivers/mfd/intel-lpss.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
> index 70c646b0097d..0e0ab9bb1530 100644
> --- a/drivers/mfd/intel-lpss.c
> +++ b/drivers/mfd/intel-lpss.c
> @@ -502,6 +502,14 @@ int intel_lpss_suspend(struct device *dev)
> for (i = 0; i < LPSS_PRIV_REG_COUNT; i++)
> lpss->priv_ctx[i] = readl(lpss->priv + i * 4);
>
> +   /*
> +* If the device type is not UART, then put the controller into
> +* reset. UART cannot be put into reset since S3/S0ix fail when
> +* no_console_suspend flag is enabled.
> +*/
> +   if (lpss->type != LPSS_DEV_UART)
> +   writel(0, lpss->priv + LPSS_PRIV_RESETS);
> +
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(intel_lpss_suspend);
> --
> 2.14.0.rc0.284.gd933b75aa4-goog
>

Re: [PATCH] mfd: intel-lpss: Put I2C and SPI controllers into reset state on suspend

2017-08-21 Thread Furquan Shaikh

Hello Lee,

Gentle ping. Do you see any issues with the following change?

Thanks,
Furquan

On Sun, Jul 23, 2017 at 11:02 PM, Furquan Shaikh  wrote:
>
> Commit 274e43edcda6f ("mfd: intel-lpss: Do not put device in reset
> state on suspend") changed the behavior on suspend by not putting LPSS
> controllers into reset. This was done because S3/S0ix fail if UART
> device is put into reset and no_console_suspend flag is enabled.
>
> Because of the above change, I2C controller gets into a bad state if
> it observes that the I2C lines are pulled low when power to I2C device
> is cut off during suspend (generally, I2C lines are pulled to power
> rail of the I2C device in order to ensure that there is no leakage
> because of the pulls when device is turned off). This results in the
> controller timing out for all future I2C operations after resume. It
> is primarily because of the following sequence of operations:
>
> During suspend:
> 1. I2C controller is disabled, but it is not put into reset.
> 2. Power to I2C device is cut off.
> 3. #2 results in the I2C lines being pulled low.
>
> ==> At this point the I2C controller gets into a bad state
>
> On resume:
> 1. Power to I2C device is enabled.
> 2. #2 results in the I2C lines being pulled high.
> 3. I2C controller is enabled.
>
> However, even after enabling the I2C controller, all future I2C xfers
> fail since the controller is in a bad state and does not attempt to
> make any transactions and hence times out.
>
> In order to ensure that the controller does not get into a bad state,
> this change puts it into reset if the controller type is not
> UART. With this change, the order of operations is:
>
> During suspend:
> 1. I2C controller is disabled and put into reset.
> 2. Power to I2C device is cut off.
> 3. #2 results in the I2C lines being pulled low.
>
> On resume:
> 1. Power to I2C device is enabled.
> 2. #2 results in the I2C lines being pulled high.
> 3. I2C controller is enabled and taken out of reset.
>
> Signed-off-by: Furquan Shaikh 
> ---
>  drivers/mfd/intel-lpss.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
> index 70c646b0097d..0e0ab9bb1530 100644
> --- a/drivers/mfd/intel-lpss.c
> +++ b/drivers/mfd/intel-lpss.c
> @@ -502,6 +502,14 @@ int intel_lpss_suspend(struct device *dev)
> for (i = 0; i < LPSS_PRIV_REG_COUNT; i++)
> lpss->priv_ctx[i] = readl(lpss->priv + i * 4);
>
> +   /*
> +* If the device type is not UART, then put the controller into
> +* reset. UART cannot be put into reset since S3/S0ix fail when
> +* no_console_suspend flag is enabled.
> +*/
> +   if (lpss->type != LPSS_DEV_UART)
> +   writel(0, lpss->priv + LPSS_PRIV_RESETS);
> +
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(intel_lpss_suspend);
> --
> 2.14.0.rc0.284.gd933b75aa4-goog
>

[PATCH v1 3/3] MAINTAINERS: Add entry for the Nuvoton NPCM architecture

2017-08-21 Thread Brendan Higgins

Add maintainers and reviewers for the Nuvoton NPCM architecture.

Signed-off-by: Brendan Higgins 
---
 MAINTAINERS | 13 +
 1 file changed, 13 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 44cb004c765d..67064bf11904 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1598,6 +1598,19 @@ F:   drivers/pinctrl/nomadik/
 F: drivers/i2c/busses/i2c-nomadik.c
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
 
+ARM/NUVOTON NPCM ARCHITECTURE
+M: Avi Fishman 
+M: Tomer Maimon 
+R: Brendan Higgins 
+R: Rick Altherr 
+L: open...@lists.ozlabs.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/mach-npcm/
+F: arch/arm/boot/dts/nuvoton-npcm*
+F: include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
+F: drivers/*/*npcm*
+F: Documentation/*/*npcm*
+
 ARM/NUVOTON W90X900 ARM ARCHITECTURE
 M: Wan ZongShun 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-- 
2.14.1.480.gb18f417b89-goog

[PATCH v1 3/3] MAINTAINERS: Add entry for the Nuvoton NPCM architecture

2017-08-21 Thread Brendan Higgins

Add maintainers and reviewers for the Nuvoton NPCM architecture.

Signed-off-by: Brendan Higgins 
---
 MAINTAINERS | 13 +
 1 file changed, 13 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 44cb004c765d..67064bf11904 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1598,6 +1598,19 @@ F:   drivers/pinctrl/nomadik/
 F: drivers/i2c/busses/i2c-nomadik.c
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
 
+ARM/NUVOTON NPCM ARCHITECTURE
+M: Avi Fishman 
+M: Tomer Maimon 
+R: Brendan Higgins 
+R: Rick Altherr 
+L: open...@lists.ozlabs.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/mach-npcm/
+F: arch/arm/boot/dts/nuvoton-npcm*
+F: include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
+F: drivers/*/*npcm*
+F: Documentation/*/*npcm*
+
 ARM/NUVOTON W90X900 ARM ARCHITECTURE
 M: Wan ZongShun 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-- 
2.14.1.480.gb18f417b89-goog

linux-next: manual merge of the tip tree with the arm64 tree

2017-08-21 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/firmware/efi/libstub/arm64-stub.c

between commit:

  170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN")

from the arm64 tree and commit:

  0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section 
markers")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/firmware/efi/libstub/arm64-stub.c
index af6ae95a5e34,f7a6970e9abc..
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@@ -9,10 -9,17 +9,18 @@@
   * published by the Free Software Foundation.
   *
   */
+ 
+ /*
+  * To prevent the compiler from emitting GOT-indirected (and thus absolute)
+  * references to the section markers, override their visibility as 'hidden'
+  */
+ #pragma GCC visibility push(hidden)
+ #include 
+ #pragma GCC visibility pop
+ 
  #include 
  #include 
 +#include 
- #include 
  #include 
  
  #include "efistub.h"

linux-next: manual merge of the tip tree with the arm64 tree

2017-08-21 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  drivers/firmware/efi/libstub/arm64-stub.c

between commit:

  170976bcab07 ("efi/arm64: add EFI_KIMG_ALIGN")

from the arm64 tree and commit:

  0426a4e68f18 ("efi/libstub/arm64: Force 'hidden' visibility for section 
markers")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/firmware/efi/libstub/arm64-stub.c
index af6ae95a5e34,f7a6970e9abc..
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@@ -9,10 -9,17 +9,18 @@@
   * published by the Free Software Foundation.
   *
   */
+ 
+ /*
+  * To prevent the compiler from emitting GOT-indirected (and thus absolute)
+  * references to the section markers, override their visibility as 'hidden'
+  */
+ #pragma GCC visibility push(hidden)
+ #include 
+ #pragma GCC visibility pop
+ 
  #include 
  #include 
 +#include 
- #include 
  #include 
  
  #include "efistub.h"

[PATCH v1 1/3] arm: npcm: add basic support for Nuvoton BMCs

2017-08-21 Thread Brendan Higgins

Adds basic support for the Nuvoton NPCM750 BMC.

Signed-off-by: Brendan Higgins 
---
 arch/arm/Kconfig |   2 +
 arch/arm/Makefile|   1 +
 arch/arm/mach-npcm/Kconfig   |  60 +++
 arch/arm/mach-npcm/Makefile  |   3 +
 arch/arm/mach-npcm/headsmp.S | 120 ++
 arch/arm/mach-npcm/npcm7xx.c |  34 +
 arch/arm/mach-npcm/platsmp.c | 170 +++
 7 files changed, 390 insertions(+)
 create mode 100644 arch/arm/mach-npcm/Kconfig
 create mode 100644 arch/arm/mach-npcm/Makefile
 create mode 100644 arch/arm/mach-npcm/headsmp.S
 create mode 100644 arch/arm/mach-npcm/npcm7xx.c
 create mode 100644 arch/arm/mach-npcm/platsmp.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 61a0cb15067e..05543f1cfbde 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -782,6 +782,8 @@ source "arch/arm/mach-netx/Kconfig"
 
 source "arch/arm/mach-nomadik/Kconfig"
 
+source "arch/arm/mach-npcm/Kconfig"
+
 source "arch/arm/mach-nspire/Kconfig"
 
 source "arch/arm/plat-omap/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..60ca50c7d762 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -191,6 +191,7 @@ machine-$(CONFIG_ARCH_MEDIATEK) += mediatek
 machine-$(CONFIG_ARCH_MXS) += mxs
 machine-$(CONFIG_ARCH_NETX)+= netx
 machine-$(CONFIG_ARCH_NOMADIK) += nomadik
+machine-$(CONFIG_ARCH_NPCM)+= npcm
 machine-$(CONFIG_ARCH_NSPIRE)  += nspire
 machine-$(CONFIG_ARCH_OXNAS)   += oxnas
 machine-$(CONFIG_ARCH_OMAP1)   += omap1
diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig
new file mode 100644
index ..82714b8a890f
--- /dev/null
+++ b/arch/arm/mach-npcm/Kconfig
@@ -0,0 +1,60 @@
+menuconfig ARCH_NPCM
+   bool "Nuvoton NPCM Architecture"
+   select ARCH_REQUIRE_GPIOLIB
+   select USE_OF
+   select PINCTRL
+   select PINCTRL_NPCM7XX
+
+if ARCH_NPCM
+
+comment "NPCMX50 CPU type"
+
+config CPU_NPCM750
+   depends on ARCH_NPCM
+   bool "Support for NPCM750 BMC CPU (Poleg)"
+   select CACHE_L2X0
+   select CPU_V7
+   select ARM_GIC
+   select ARM_ERRATA_754322
+   select ARM_ERRATA_764369
+   select USB_EHCI_ROOT_HUB_TT
+   select USB_ARCH_HAS_HCD
+   select USB_ARCH_HAS_EHCI
+   select USB_EHCI_HCD
+   select USB_ARCH_HAS_OHCI
+   select USB_OHCI_HCD
+   select USB
+   select FIQ
+   select CPU_USE_DOMAINS
+   select COMMON_CLK if OF
+   select NPCM750_TIMER
+   select MFD_SYSCON
+   help
+ Support for single core NPCM750 BMC CPU (Poleg).
+
+ Single core variant of the Nuvoton NPCM750 BMC based on the Cortex A9.
+
+config CPU_NPCM750_SMP
+   depends on ARCH_NPCM
+   bool "Support for NPCM750 BMC CPU SMP (Poleg)"
+   select HAVE_SMP
+   select HAVE_ARM_SCU
+   select ARM_ERRATA_458693
+   select ARM_ERRATA_742231
+   select ARM_ERRATA_794072
+   select PL310_ERRATA_588369
+   select PL310_ERRATA_727915
+   select ARM_ERRATA_720789
+   select DEBUG_SPINLOCK
+   select GENERIC_CLOCKEVENTS
+   select SMP
+   select HAVE_ARM_TWD if SMP
+   select HAVE_ARM_SCU if SMP
+   select CLKDEV_LOOKUP
+   select COMMON_CLK if OF
+   help
+ Support for dual core NPCM750 BMC CPU (Poleg).
+
+ Dual core variant of the Nuvoton NPCM750 BMC based on the Cortex A9.
+
+endif
diff --git a/arch/arm/mach-npcm/Makefile b/arch/arm/mach-npcm/Makefile
new file mode 100644
index ..e7d27340f968
--- /dev/null
+++ b/arch/arm/mach-npcm/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_SMP)  += platsmp.o headsmp.o
+
+obj-$(CONFIG_ARCH_NPCM)+= npcm7xx.o
diff --git a/arch/arm/mach-npcm/headsmp.S b/arch/arm/mach-npcm/headsmp.S
new file mode 100644
index ..d22d2fc1a35c
--- /dev/null
+++ b/arch/arm/mach-npcm/headsmp.S
@@ -0,0 +1,120 @@
+/*
+ * linux/arch/arm/mach-realview/headsmp.S
+ *
+ * Copyright (c) 2003 ARM Limited
+ * Copyright 2017 Google, Inc.
+ *  All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+.equ SVC_MODE, 0x13
+.equ I_BIT, 0x80
+.equ F_BIT, 0x40
+
+ENTRY(npcm7xx_wakeup_z1)
+   stmfd   sp!, {r0-r12, lr}
+   ldr r0, =0x01
+   ldr r1, =0x01
+   ldr r2, =0x01
+
+   and r3, r0, #0x0F /* Mask off unused bits of ID, and move to r3 */
+   and r1, r1, #0x0F /* Mask off unused bits of target_filter */
+   and r2, r2, #0x0F /* Mask off unused bits of filter_list */
+
+   orr r3, r3, r1, LSL #16 /* Combine ID and target_filter */
+   orr r3, r3, r2, LSL #24 /* and now the filter list */
+
+   /* Get the address

[PATCH v1 1/3] arm: npcm: add basic support for Nuvoton BMCs

2017-08-21 Thread Brendan Higgins

Adds basic support for the Nuvoton NPCM750 BMC.

Signed-off-by: Brendan Higgins 
---
 arch/arm/Kconfig |   2 +
 arch/arm/Makefile|   1 +
 arch/arm/mach-npcm/Kconfig   |  60 +++
 arch/arm/mach-npcm/Makefile  |   3 +
 arch/arm/mach-npcm/headsmp.S | 120 ++
 arch/arm/mach-npcm/npcm7xx.c |  34 +
 arch/arm/mach-npcm/platsmp.c | 170 +++
 7 files changed, 390 insertions(+)
 create mode 100644 arch/arm/mach-npcm/Kconfig
 create mode 100644 arch/arm/mach-npcm/Makefile
 create mode 100644 arch/arm/mach-npcm/headsmp.S
 create mode 100644 arch/arm/mach-npcm/npcm7xx.c
 create mode 100644 arch/arm/mach-npcm/platsmp.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 61a0cb15067e..05543f1cfbde 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -782,6 +782,8 @@ source "arch/arm/mach-netx/Kconfig"
 
 source "arch/arm/mach-nomadik/Kconfig"
 
+source "arch/arm/mach-npcm/Kconfig"
+
 source "arch/arm/mach-nspire/Kconfig"
 
 source "arch/arm/plat-omap/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 47d3a1ab08d2..60ca50c7d762 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -191,6 +191,7 @@ machine-$(CONFIG_ARCH_MEDIATEK) += mediatek
 machine-$(CONFIG_ARCH_MXS) += mxs
 machine-$(CONFIG_ARCH_NETX)+= netx
 machine-$(CONFIG_ARCH_NOMADIK) += nomadik
+machine-$(CONFIG_ARCH_NPCM)+= npcm
 machine-$(CONFIG_ARCH_NSPIRE)  += nspire
 machine-$(CONFIG_ARCH_OXNAS)   += oxnas
 machine-$(CONFIG_ARCH_OMAP1)   += omap1
diff --git a/arch/arm/mach-npcm/Kconfig b/arch/arm/mach-npcm/Kconfig
new file mode 100644
index ..82714b8a890f
--- /dev/null
+++ b/arch/arm/mach-npcm/Kconfig
@@ -0,0 +1,60 @@
+menuconfig ARCH_NPCM
+   bool "Nuvoton NPCM Architecture"
+   select ARCH_REQUIRE_GPIOLIB
+   select USE_OF
+   select PINCTRL
+   select PINCTRL_NPCM7XX
+
+if ARCH_NPCM
+
+comment "NPCMX50 CPU type"
+
+config CPU_NPCM750
+   depends on ARCH_NPCM
+   bool "Support for NPCM750 BMC CPU (Poleg)"
+   select CACHE_L2X0
+   select CPU_V7
+   select ARM_GIC
+   select ARM_ERRATA_754322
+   select ARM_ERRATA_764369
+   select USB_EHCI_ROOT_HUB_TT
+   select USB_ARCH_HAS_HCD
+   select USB_ARCH_HAS_EHCI
+   select USB_EHCI_HCD
+   select USB_ARCH_HAS_OHCI
+   select USB_OHCI_HCD
+   select USB
+   select FIQ
+   select CPU_USE_DOMAINS
+   select COMMON_CLK if OF
+   select NPCM750_TIMER
+   select MFD_SYSCON
+   help
+ Support for single core NPCM750 BMC CPU (Poleg).
+
+ Single core variant of the Nuvoton NPCM750 BMC based on the Cortex A9.
+
+config CPU_NPCM750_SMP
+   depends on ARCH_NPCM
+   bool "Support for NPCM750 BMC CPU SMP (Poleg)"
+   select HAVE_SMP
+   select HAVE_ARM_SCU
+   select ARM_ERRATA_458693
+   select ARM_ERRATA_742231
+   select ARM_ERRATA_794072
+   select PL310_ERRATA_588369
+   select PL310_ERRATA_727915
+   select ARM_ERRATA_720789
+   select DEBUG_SPINLOCK
+   select GENERIC_CLOCKEVENTS
+   select SMP
+   select HAVE_ARM_TWD if SMP
+   select HAVE_ARM_SCU if SMP
+   select CLKDEV_LOOKUP
+   select COMMON_CLK if OF
+   help
+ Support for dual core NPCM750 BMC CPU (Poleg).
+
+ Dual core variant of the Nuvoton NPCM750 BMC based on the Cortex A9.
+
+endif
diff --git a/arch/arm/mach-npcm/Makefile b/arch/arm/mach-npcm/Makefile
new file mode 100644
index ..e7d27340f968
--- /dev/null
+++ b/arch/arm/mach-npcm/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_SMP)  += platsmp.o headsmp.o
+
+obj-$(CONFIG_ARCH_NPCM)+= npcm7xx.o
diff --git a/arch/arm/mach-npcm/headsmp.S b/arch/arm/mach-npcm/headsmp.S
new file mode 100644
index ..d22d2fc1a35c
--- /dev/null
+++ b/arch/arm/mach-npcm/headsmp.S
@@ -0,0 +1,120 @@
+/*
+ * linux/arch/arm/mach-realview/headsmp.S
+ *
+ * Copyright (c) 2003 ARM Limited
+ * Copyright 2017 Google, Inc.
+ *  All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+
+.equ SVC_MODE, 0x13
+.equ I_BIT, 0x80
+.equ F_BIT, 0x40
+
+ENTRY(npcm7xx_wakeup_z1)
+   stmfd   sp!, {r0-r12, lr}
+   ldr r0, =0x01
+   ldr r1, =0x01
+   ldr r2, =0x01
+
+   and r3, r0, #0x0F /* Mask off unused bits of ID, and move to r3 */
+   and r1, r1, #0x0F /* Mask off unused bits of target_filter */
+   and r2, r2, #0x0F /* Mask off unused bits of filter_list */
+
+   orr r3, r3, r1, LSL #16 /* Combine ID and target_filter */
+   orr r3, r3, r2, LSL #24 /* and now the filter list */
+
+   /* Get the address of the GIC */
+   mrc

[PATCH v1 0/3] arm: npcm: add basic support for Nuvoton BMCs

2017-08-21 Thread Brendan Higgins

This patch set adds support for the Nuvoton NPCM Baseboard Management Controller
(BMC) SoC architecture as well as the NPCM750 variant. NPCM is an ARM based SoC
with external DDR RAM and supports a large set of peripherals.

The NPCM750 is based on Cortex A9 and comes in single core and dual core
flavors.

The device tree added in this patchset has a number of bindings for which the
corresponding drivers will be sent out later and thus do not yet have binding
documentation. Apologies in advance if you would like the bindings to be added
along with the corresponding drivers.

Thanks!

[PATCH v1 0/3] arm: npcm: add basic support for Nuvoton BMCs

2017-08-21 Thread Brendan Higgins

This patch set adds support for the Nuvoton NPCM Baseboard Management Controller
(BMC) SoC architecture as well as the NPCM750 variant. NPCM is an ARM based SoC
with external DDR RAM and supports a large set of peripherals.

The NPCM750 is based on Cortex A9 and comes in single core and dual core
flavors.

The device tree added in this patchset has a number of bindings for which the
corresponding drivers will be sent out later and thus do not yet have binding
documentation. Apologies in advance if you would like the bindings to be added
along with the corresponding drivers.

Thanks!

Re: [PATCH 2/2] mm: Update NUMA counter threshold size

2017-08-21 Thread kemi



On 2017年08月15日 17:58, Mel Gorman wrote:
> On Tue, Aug 15, 2017 at 04:45:36PM +0800, Kemi Wang wrote:
>>  Threshold   CPU cyclesThroughput(88 threads)
>>  32  799 241760478
>>  64  640 301628829
>>  125 537 358906028 <==> system by default (base)
>>  256 468 412397590
>>  512 428 450550704
>>  4096399 482520943
>>  2   394 489009617
>>  3   395 488017817
>>  32765   394(-26.6%) 488932078(+36.2%) <==> with this patchset
>>  N/A 342(-36.3%) 562900157(+56.8%) <==> disable zone_statistics
>>
>> Signed-off-by: Kemi Wang 
>> Suggested-by: Dave Hansen 
>> Suggested-by: Ying Huang 
>> ---
>>  include/linux/mmzone.h |  4 ++--
>>  include/linux/vmstat.h |  6 +-
>>  mm/vmstat.c| 23 ++-
>>  3 files changed, 17 insertions(+), 16 deletions(-)
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index 0b11ba7..7eaf0e8 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -282,8 +282,8 @@ struct per_cpu_pageset {
>>  struct per_cpu_pages pcp;
>>  #ifdef CONFIG_NUMA
>>  s8 expire;
>> -s8 numa_stat_threshold;
>> -s8 vm_numa_stat_diff[NR_VM_ZONE_NUMA_STAT_ITEMS];
>> +s16 numa_stat_threshold;
>> +s16 vm_numa_stat_diff[NR_VM_ZONE_NUMA_STAT_ITEMS];
> 
> I'm fairly sure this pushes the size of that structure into the next
> cache line which is not welcome.
> 
Hi Mel
  I am refreshing this patch. Would you pls be more explicit of what "that
structure" indicates. 
  If you mean "struct per_cpu_pageset", for 64 bits machine, this structure
still occupies two caches line after extending s8 to s16/u16, that should
not be a problem. For 32 bits machine, we probably does not need to extend
the size of vm_numa_stat_diff[] since 32 bits OS nearly not be used in large
numa system, and s8/u8 is large enough for it, in this case, we can keep the 
same size of "struct per_cpu_pageset".

 If you mean "s16 vm_numa_stat_diff[]", and want to keep it in a single cache
line, we probably can add some padding after "s8 expire" to achieve it.

Again, thanks for your comments to make this patch more graceful.
> vm_numa_stat_diff is an always incrementing field. How much do you gain
> if this becomes a u8 code and remove any code that deals with negative
> values? That would double the threshold without consuming another cache line.
> 
> Furthermore, the stats in question are only ever incremented by one.
> That means that any calcluation related to overlap can be removed and
> special cased that it'll never overlap by more than 1. That potentially
> removes code that is required for other stats but not locality stats.
> This may give enough savings to avoid moving to s16.
> 
> Very broadly speaking, I like what you're doing but I would like to see
> more work on reducing any unnecessary code in that path (such as dealing
> with overlaps for single increments) and treat incrasing the cache footprint
> only as a very last resort.
> 
>>

Re: [PATCH 2/2] mm: Update NUMA counter threshold size

2017-08-21 Thread kemi



On 2017年08月15日 17:58, Mel Gorman wrote:
> On Tue, Aug 15, 2017 at 04:45:36PM +0800, Kemi Wang wrote:
>>  Threshold   CPU cyclesThroughput(88 threads)
>>  32  799 241760478
>>  64  640 301628829
>>  125 537 358906028 <==> system by default (base)
>>  256 468 412397590
>>  512 428 450550704
>>  4096399 482520943
>>  2   394 489009617
>>  3   395 488017817
>>  32765   394(-26.6%) 488932078(+36.2%) <==> with this patchset
>>  N/A 342(-36.3%) 562900157(+56.8%) <==> disable zone_statistics
>>
>> Signed-off-by: Kemi Wang 
>> Suggested-by: Dave Hansen 
>> Suggested-by: Ying Huang 
>> ---
>>  include/linux/mmzone.h |  4 ++--
>>  include/linux/vmstat.h |  6 +-
>>  mm/vmstat.c| 23 ++-
>>  3 files changed, 17 insertions(+), 16 deletions(-)
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index 0b11ba7..7eaf0e8 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -282,8 +282,8 @@ struct per_cpu_pageset {
>>  struct per_cpu_pages pcp;
>>  #ifdef CONFIG_NUMA
>>  s8 expire;
>> -s8 numa_stat_threshold;
>> -s8 vm_numa_stat_diff[NR_VM_ZONE_NUMA_STAT_ITEMS];
>> +s16 numa_stat_threshold;
>> +s16 vm_numa_stat_diff[NR_VM_ZONE_NUMA_STAT_ITEMS];
> 
> I'm fairly sure this pushes the size of that structure into the next
> cache line which is not welcome.
> 
Hi Mel
  I am refreshing this patch. Would you pls be more explicit of what "that
structure" indicates. 
  If you mean "struct per_cpu_pageset", for 64 bits machine, this structure
still occupies two caches line after extending s8 to s16/u16, that should
not be a problem. For 32 bits machine, we probably does not need to extend
the size of vm_numa_stat_diff[] since 32 bits OS nearly not be used in large
numa system, and s8/u8 is large enough for it, in this case, we can keep the 
same size of "struct per_cpu_pageset".

 If you mean "s16 vm_numa_stat_diff[]", and want to keep it in a single cache
line, we probably can add some padding after "s8 expire" to achieve it.

Again, thanks for your comments to make this patch more graceful.
> vm_numa_stat_diff is an always incrementing field. How much do you gain
> if this becomes a u8 code and remove any code that deals with negative
> values? That would double the threshold without consuming another cache line.
> 
> Furthermore, the stats in question are only ever incremented by one.
> That means that any calcluation related to overlap can be removed and
> special cased that it'll never overlap by more than 1. That potentially
> removes code that is required for other stats but not locality stats.
> This may give enough savings to avoid moving to s16.
> 
> Very broadly speaking, I like what you're doing but I would like to see
> more work on reducing any unnecessary code in that path (such as dealing
> with overlaps for single increments) and treat incrasing the cache footprint
> only as a very last resort.
> 
>>

[PATCH v4 4/4] arm64: dts: rockchip: Handle pcie wake in pcie driver for Gru

2017-08-21 Thread Jeffy Chen

Currently we are handling pcie wake irq in mrvl wifi driver.
Move it to rockchip pcie driver for Gru boards.

Signed-off-by: Jeffy Chen 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index d48e98b62d09..42158512e979 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -712,7 +712,15 @@ ap_i2c_audio:  {
 
ep-gpios = < 27 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
-   pinctrl-0 = <_clkreqn_cpm>, <_perst_l>;
+   pinctrl-0 = <_clkreqn_cpm>, <_host_wake_l>, <_perst_l>;
+
+   interrupts-extended = < GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
+ < 8 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-names = "sys", "legacy", "client", "wake";
+   /delete-property/ interrupts;
+
vpcie3v3-supply = <_wifi_bt>;
vpcie1v8-supply = <_pd_n>; /* HACK: see _pd_n */
vpcie0v9-supply = <_pcie>;
@@ -727,11 +735,6 @@ ap_i2c_audio:  {
compatible = "pci1b4b,2b42";
reg = <0x8301 0x0 0x 0x0 0x0010
   0x8301 0x0 0x0010 0x0 0x0010>;
-   interrupt-parent = <>;
-   interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_host_wake_l>;
-   wakeup-source;
};
};
 };
-- 
2.11.0

[PATCH v4 4/4] arm64: dts: rockchip: Handle pcie wake in pcie driver for Gru

2017-08-21 Thread Jeffy Chen

Currently we are handling pcie wake irq in mrvl wifi driver.
Move it to rockchip pcie driver for Gru boards.

Signed-off-by: Jeffy Chen 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index d48e98b62d09..42158512e979 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -712,7 +712,15 @@ ap_i2c_audio:  {
 
ep-gpios = < 27 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
-   pinctrl-0 = <_clkreqn_cpm>, <_perst_l>;
+   pinctrl-0 = <_clkreqn_cpm>, <_host_wake_l>, <_perst_l>;
+
+   interrupts-extended = < GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
+ < 8 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-names = "sys", "legacy", "client", "wake";
+   /delete-property/ interrupts;
+
vpcie3v3-supply = <_wifi_bt>;
vpcie1v8-supply = <_pd_n>; /* HACK: see _pd_n */
vpcie0v9-supply = <_pcie>;
@@ -727,11 +735,6 @@ ap_i2c_audio:  {
compatible = "pci1b4b,2b42";
reg = <0x8301 0x0 0x 0x0 0x0010
   0x8301 0x0 0x0010 0x0 0x0010>;
-   interrupt-parent = <>;
-   interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_host_wake_l>;
-   wakeup-source;
};
};
 };
-- 
2.11.0

[PATCH v4 3/4] dt-bindings: PCI: rockchip: Add support for pcie wake irq

2017-08-21 Thread Jeffy Chen

Add an optional interrupt for PCIE_WAKE pin.

Signed-off-by: Jeffy Chen 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/pci/rockchip-pcie.txt| 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
index 5678be82530d..9f6504129e80 100644
--- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
@@ -20,10 +20,13 @@ Required properties:
 - msi-map: Maps a Requester ID to an MSI controller and associated
msi-specifier data. See ./pci-msi.txt
 - interrupts: Three interrupt entries must be specified.
-- interrupt-names: Must include the following names
-   - "sys"
-   - "legacy"
-   - "client"
+- interrupt-names: Include the following names
+   Required:
+   - "sys"
+   - "legacy"
+   - "client"
+   Optional:
+   - "wake"
 - resets: Must contain seven entries for each entry in reset-names.
   See ../reset/reset.txt for details.
 - reset-names: Must include the following names
@@ -87,10 +90,11 @@ pcie0: pcie@f800 {
clock-names = "aclk", "aclk-perf",
  "hclk", "pm";
bus-range = <0x0 0x1>;
-   interrupts = ,
-,
-;
-   interrupt-names = "sys", "legacy", "client";
+   interrupts-extended = < GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+ < GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>,
+ < 8 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-names = "sys", "legacy", "client", "wake";
assigned-clocks = < SCLK_PCIEPHY_REF>;
assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
assigned-clock-rates = <1>;
-- 
2.11.0

[PATCH v4 1/4] PCI: rockchip: Fix error handlings

2017-08-21 Thread Jeffy Chen

Fix error handlings in probe & resume.

Signed-off-by: Jeffy Chen 
---

Changes in v4:
Rebase on newest for-next branch, also fix error handling by:
1e7f570a1b86 PCI: rockchip: Idle inactive PHY(s)

Changes in v3: None
Changes in v2: None

 drivers/pci/host/pcie-rockchip.c | 160 +--
 1 file changed, 87 insertions(+), 73 deletions(-)

diff --git a/drivers/pci/host/pcie-rockchip.c b/drivers/pci/host/pcie-rockchip.c
index 2eccd532c256..5d85ec2e2fb0 100644
--- a/drivers/pci/host/pcie-rockchip.c
+++ b/drivers/pci/host/pcie-rockchip.c
@@ -561,32 +561,32 @@ static int rockchip_pcie_init_port(struct rockchip_pcie 
*rockchip)
err = phy_init(rockchip->phys[i]);
if (err) {
dev_err(dev, "init phy%d err %d\n", i, err);
-   return err;
+   goto err_exit_phy;
}
}
 
err = reset_control_assert(rockchip->core_rst);
if (err) {
dev_err(dev, "assert core_rst err %d\n", err);
-   return err;
+   goto err_exit_phy;
}
 
err = reset_control_assert(rockchip->mgmt_rst);
if (err) {
dev_err(dev, "assert mgmt_rst err %d\n", err);
-   return err;
+   goto err_exit_phy;
}
 
err = reset_control_assert(rockchip->mgmt_sticky_rst);
if (err) {
dev_err(dev, "assert mgmt_sticky_rst err %d\n", err);
-   return err;
+   goto err_exit_phy;
}
 
err = reset_control_assert(rockchip->pipe_rst);
if (err) {
dev_err(dev, "assert pipe_rst err %d\n", err);
-   return err;
+   goto err_exit_phy;
}
 
udelay(10);
@@ -594,19 +594,19 @@ static int rockchip_pcie_init_port(struct rockchip_pcie 
*rockchip)
err = reset_control_deassert(rockchip->pm_rst);
if (err) {
dev_err(dev, "deassert pm_rst err %d\n", err);
-   return err;
+   goto err_exit_phy;
}
 
err = reset_control_deassert(rockchip->aclk_rst);
if (err) {
dev_err(dev, "deassert aclk_rst err %d\n", err);
-   return err;
+   goto err_exit_phy;
}
 
err = reset_control_deassert(rockchip->pclk_rst);
if (err) {
dev_err(dev, "deassert pclk_rst err %d\n", err);
-   return err;
+   goto err_exit_phy;
}
 
if (rockchip->link_gen == 2)
@@ -628,7 +628,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie 
*rockchip)
err = phy_power_on(rockchip->phys[i]);
if (err) {
dev_err(dev, "power on phy%d err %d\n", i, err);
-   return err;
+   goto err_power_off_phy;
}
}
 
@@ -639,25 +639,25 @@ static int rockchip_pcie_init_port(struct rockchip_pcie 
*rockchip)
err = reset_control_deassert(rockchip->mgmt_sticky_rst);
if (err) {
dev_err(dev, "deassert mgmt_sticky_rst err %d\n", err);
-   return err;
+   goto err_power_off_phy;
}
 
err = reset_control_deassert(rockchip->core_rst);
if (err) {
dev_err(dev, "deassert core_rst err %d\n", err);
-   return err;
+   goto err_power_off_phy;
}
 
err = reset_control_deassert(rockchip->mgmt_rst);
if (err) {
dev_err(dev, "deassert mgmt_rst err %d\n", err);
-   return err;
+   goto err_power_off_phy;
}
 
err = reset_control_deassert(rockchip->pipe_rst);
if (err) {
dev_err(dev, "deassert pipe_rst err %d\n", err);
-   return err;
+   goto err_power_off_phy;
}
 
/* Fix the transmitted FTS count desired to exit from L0s. */
@@ -690,7 +690,7 @@ static int rockchip_pcie_init_port(struct rockchip_pcie 
*rockchip)
 500 * USEC_PER_MSEC);
if (err) {
dev_err(dev, "PCIe link training gen1 timeout!\n");
-   return -ETIMEDOUT;
+   goto err_power_off_phy;
}
 
if (rockchip->link_gen == 2) {
@@ -751,6 +751,26 @@ static int rockchip_pcie_init_port(struct rockchip_pcie 
*rockchip)
rockchip_pcie_write(rockchip, status, PCIE_RC_CONFIG_DCSR);
 
return 0;
+err_power_off_phy:
+   while (i--)
+   phy_power_off(rockchip->phys[i]);
+   i = MAX_LANE_NUM;
+err_exit_phy:
+   while (i--)
+   phy_exit(rockchip->phys[i]);
+   return err;
+}
+
+static void rockchip_pcie_deinit_phys(struct rockchip_pcie *rockchip)
+{
+   int i;
+
+   for (i = 0; i < MAX_LANE_NUM; i++) {
+   /* inactive lane is already powered off */
+   if

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1934 matches

Mail list logo