* [PATCH v2 16/18] drivers/fsi: Document FSI master sysfs files in ABI
From: christopher.lee.bostic @ 2017-01-12 22:36 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Chris Bostic <cbostic@us.ibm.com>
Add info for sysfs scan file in Documentaiton ABI/testing
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-fsi | 6 ++++++
1 file changed, 6 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-fsi
diff --git a/Documentation/ABI/testing/sysfs-bus-fsi b/Documentation/ABI/testing/sysfs-bus-fsi
new file mode 100644
index 0000000..dfcbc1b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-fsi
@@ -0,0 +1,6 @@
+What: /sys/bus/platform/devices/fsi-master/scan
+KernelVersion: 4.9
+Contact: cbostic@us.ibm.com
+Description:
+ Initiates a FSI master scan for all connected
+ slave devices on its links.
--
1.8.2.2
^ permalink raw reply related
* Re: [PATCH] ARM: dts: OMAP5 / DRA7: indicate that SATA port 0 is available.
From: Tony Lindgren @ 2017-01-12 22:36 UTC (permalink / raw)
To: Jean-Jacques Hiblot
Cc: bcousson-rdvid1DuHRBWk0Htik3J/w,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, rogerq-l0cyMroinI0,
stable-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170112223007.GP2630-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170112 14:31]:
> * Jean-Jacques Hiblot <jjhiblot-l0cyMroinI0@public.gmane.org> [170109 04:23]:
> > AHCI provides the register PORTS_IMPL to let the software know which port
> > is supported. The register must be initialized by the bootloader. However
> > in some cases u-boot doesn't properly initialize this value (if it is not
> > compiled with SATA support for example or if the SATA initialization fails).
> > The DTS entry "ports-implemented" can be used to override the value in
> > PORTS_IMPL.
> > Adding this entry in the dts allows us no to worry about what is done by
> > the bootloader.
>
> Adding into omap-for-v4.11/dt thanks.
Actually not applying just yet as I just noticed you tagged this for stable.
Care to describe what breaks and on which devices without this patch?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 17/18] drivers/fsi: Add GPIO based FSI master
From: christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w @ 2017-01-12 22:37 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
joel-U3u1mxZcP9KHXe+LvDLADg, jk-mnsaURCQ41sdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-zrmu5oMJ5Fs,
alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
Cc: Chris Bostic
From: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Implement a FSI master using GPIO. Will generate FSI protocol for
read and write commands to particular addresses. Sends master command
and waits for and decodes a slave response.
Includes Jeremy Kerr's original GPIO master base commit.
Signed-off-by: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Signed-off-by: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
---
V2 - Merge fsi_master_gpio_init() into probe.
- Remove scan sysfs file creation since its now created in the
core.
- Set pin initial output values at time of requesting the pins
from the gpio driver.
- Assign value to master->master.dev at probe time.
- Use the get_optional gpio driver interface for all optional
pins.
---
drivers/fsi/Kconfig | 11 +
drivers/fsi/Makefile | 1 +
drivers/fsi/fsi-master-gpio.c | 530 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 542 insertions(+)
create mode 100644 drivers/fsi/fsi-master-gpio.c
diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index 04c1a0e..9cf8345 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -9,4 +9,15 @@ config FSI
---help---
FSI - the FRU Support Interface - is a simple bus for low-level
access to POWER-based hardware.
+
+if FSI
+
+config FSI_MASTER_GPIO
+ tristate "GPIO-based FSI master"
+ depends on FSI && GPIOLIB
+ ---help---
+ This option enables a FSI master driver using GPIO lines.
+
+endif
+
endmenu
diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile
index db0e5e7..ed28ac0 100644
--- a/drivers/fsi/Makefile
+++ b/drivers/fsi/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_FSI) += fsi-core.o
+obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o
diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c
new file mode 100644
index 0000000..b549d0b
--- /dev/null
+++ b/drivers/fsi/fsi-master-gpio.c
@@ -0,0 +1,530 @@
+/*
+ * FSI GPIO based master driver
+ *
+ * Copyright (C) IBM Corporation 2016
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ * A FSI master controller, using a simple GPIO bit-banging interface
+ */
+
+#include <linux/platform_device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/fsi.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/spinlock.h>
+#include <linux/crc-fsi.h>
+
+#include "fsi-master.h"
+
+#define FSI_GPIO_STD_DLY 1 /* Standard pin delay in nS */
+#define FSI_ECHO_DELAY_CLOCKS 16 /* Number clocks for echo delay */
+#define FSI_PRE_BREAK_CLOCKS 50 /* Number clocks to prep for break */
+#define FSI_BREAK_CLOCKS 256 /* Number of clocks to issue break */
+#define FSI_POST_BREAK_CLOCKS 16000 /* Number clocks to set up cfam */
+#define FSI_INIT_CLOCKS 5000 /* Clock out any old data */
+#define FSI_GPIO_STD_DELAY 10 /* Standard GPIO delay in nS */
+ /* todo: adjust down as low as */
+ /* possible or eliminate */
+#define FSI_GPIO_CMD_DPOLL 0x000000000000002AULL
+#define FSI_GPIO_CMD_DPOLL_SIZE 9
+#define FSI_GPIO_DPOLL_CLOCKS 100 /* < 21 will cause slave to hang */
+#define FSI_GPIO_CMD_DEFAULT 0x2000000000000000ULL
+#define FSI_GPIO_CMD_WRITE 0
+#define FSI_GPIO_CMD_READ 0x0400000000000000ULL
+#define FSI_GPIO_CMD_SLAVE_MASK 0xC000000000000000ULL
+#define FSI_GPIO_CMD_ADDR_SHIFT 37
+#define FSI_GPIO_CMD_ADDR_MASK 0x001FFFFF
+#define FSI_GPIO_CMD_SLV_SHIFT 62
+#define FSI_GPIO_CMD_SIZE_16 0x0000001000000000ULL
+#define FSI_GPIO_CMD_SIZE_32 0x0000003000000000ULL
+#define FSI_GPIO_CMD_DT32_SHIFT 4
+#define FSI_GPIO_CMD_DT16_SHIFT 20
+#define FSI_GPIO_CMD_DT8_SHIFT 28
+#define FSI_GPIO_CMD_DFLT_LEN 28
+#define FSI_GPIO_CMD_CRC_SHIFT 60
+
+/* Bus errors */
+#define FSI_GPIO_ERR_BUSY 1 /* Slave stuck in busy state */
+#define FSI_GPIO_RESP_ERRA 2 /* Any (misc) Error */
+#define FSI_GPIO_RESP_ERRC 3 /* Slave reports master CRC error */
+#define FSI_GPIO_MTOE 4 /* Master time out error */
+#define FSI_GPIO_CRC_INVAL 5 /* Master reports slave CRC error */
+
+/* Normal slave responses */
+#define FSI_GPIO_RESP_BUSY 1
+#define FSI_GPIO_RESP_ACK 0
+#define FSI_GPIO_RESP_ACKD 4
+
+#define FSI_GPIO_MAX_BUSY 100
+#define FSI_GPIO_MTOE_COUNT 1000
+#define FSI_GPIO_DRAIN_BITS 20
+#define FSI_GPIO_CRC_SIZE 4
+#define FSI_GPIO_MSG_ID_SIZE 2
+#define FSI_GPIO_MSG_RESPID_SIZE 2
+#define FSI_GPIO_PRIME_SLAVE_CLOCKS 100
+
+static DEFINE_SPINLOCK(fsi_gpio_cmd_lock); /* lock around fsi commands */
+
+struct fsi_master_gpio {
+ struct fsi_master master;
+ struct gpio_desc *gpio_clk;
+ struct gpio_desc *gpio_data;
+ struct gpio_desc *gpio_trans; /* Voltage translator */
+ struct gpio_desc *gpio_enable; /* FSI enable */
+ struct gpio_desc *gpio_mux; /* Mux control */
+};
+
+#define to_fsi_master_gpio(m) container_of(m, struct fsi_master_gpio, master)
+
+struct fsi_gpio_msg {
+ uint64_t msg;
+ uint8_t bits;
+};
+
+static void clock_toggle(struct fsi_master_gpio *master, int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++) {
+ ndelay(FSI_GPIO_STD_DLY);
+ gpiod_set_value(master->gpio_clk, 0);
+ ndelay(FSI_GPIO_STD_DLY);
+ gpiod_set_value(master->gpio_clk, 1);
+ }
+}
+
+static int sda_in(struct fsi_master_gpio *master)
+{
+ int in;
+
+ ndelay(FSI_GPIO_STD_DLY);
+ in = gpiod_get_value(master->gpio_data);
+ return in ? 1 : 0;
+}
+
+static void sda_out(struct fsi_master_gpio *master, int value)
+{
+ gpiod_set_value(master->gpio_data, value);
+}
+
+static void set_sda_input(struct fsi_master_gpio *master)
+{
+ gpiod_direction_input(master->gpio_data);
+ if (master->gpio_trans)
+ gpiod_set_value(master->gpio_trans, 0);
+}
+
+static void set_sda_output(struct fsi_master_gpio *master, int value)
+{
+ if (master->gpio_trans)
+ gpiod_set_value(master->gpio_trans, 1);
+ gpiod_direction_output(master->gpio_data, value);
+}
+
+static void serial_in(struct fsi_master_gpio *master, struct fsi_gpio_msg *cmd,
+ uint8_t num_bits)
+{
+ uint8_t bit;
+ uint64_t msg = 0;
+ uint8_t in_bit = 0;
+
+ set_sda_input(master);
+
+ for (bit = 0; bit < num_bits; bit++) {
+ clock_toggle(master, 1);
+ in_bit = sda_in(master);
+ msg <<= 1;
+ msg |= ~in_bit & 0x1; /* Data is negative active */
+ }
+ cmd->bits = num_bits;
+ cmd->msg = msg;
+}
+
+static void serial_out(struct fsi_master_gpio *master,
+ const struct fsi_gpio_msg *cmd)
+{
+ uint8_t bit;
+ uint64_t msg = ~cmd->msg; /* Data is negative active */
+ uint64_t sda_mask = 0x1ULL << (cmd->bits - 1);
+ uint64_t last_bit = ~0;
+ int next_bit;
+
+ if (!cmd->bits) {
+ dev_warn(master->master.dev, "trying to output 0 bits\n");
+ return;
+ }
+ set_sda_output(master, 0);
+
+ /* Send the start bit */
+ sda_out(master, 0);
+ clock_toggle(master, 1);
+
+ /* Send the message */
+ for (bit = 0; bit < cmd->bits; bit++) {
+ next_bit = (msg & sda_mask) >> (cmd->bits - 1);
+ if (last_bit ^ next_bit) {
+ sda_out(master, next_bit);
+ last_bit = next_bit;
+ }
+ clock_toggle(master, 1);
+ msg <<= 1;
+ }
+}
+
+/*
+ * Clock out some 0's after every message to ride out line reflections
+ */
+static void echo_delay(struct fsi_master_gpio *master)
+{
+ set_sda_output(master, 1);
+ clock_toggle(master, FSI_ECHO_DELAY_CLOCKS);
+}
+
+/*
+ * Used in bus error cases only. Clears out any remaining data the slave
+ * is attempting to send
+ */
+static void drain_response(struct fsi_master_gpio *master)
+{
+ struct fsi_gpio_msg msg;
+
+ serial_in(master, &msg, FSI_GPIO_DRAIN_BITS);
+}
+
+/*
+ * Store information on master errors so handler can detect and clean
+ * up the bus
+ */
+static void fsi_master_gpio_error(struct fsi_master_gpio *master, int error)
+{
+
+}
+
+static int poll_for_response(struct fsi_master_gpio *master, uint8_t expected,
+ uint8_t size, void *data)
+{
+ int busy_count = 0, i;
+ struct fsi_gpio_msg response, cmd;
+ int bits_remaining = 0, bit_count, response_id, id;
+ uint64_t resp = 0;
+ uint8_t bits_received = FSI_GPIO_MSG_ID_SIZE +
+ FSI_GPIO_MSG_RESPID_SIZE;
+ uint8_t crc_in;
+
+ do {
+ for (i = 0; i < FSI_GPIO_MTOE_COUNT; i++) {
+ serial_in(master, &response, 1);
+ if (response.msg)
+ break;
+ }
+ if (i >= FSI_GPIO_MTOE_COUNT) {
+ dev_dbg(master->master.dev,
+ "Master time out waiting for response\n");
+ drain_response(master);
+ fsi_master_gpio_error(master, FSI_GPIO_MTOE);
+ return -EIO;
+ }
+
+ /* Response received */
+ bit_count = FSI_GPIO_MSG_ID_SIZE + FSI_GPIO_MSG_RESPID_SIZE;
+ serial_in(master, &response, bit_count);
+
+ response_id = response.msg & 0x3;
+ id = (response.msg >> FSI_GPIO_MSG_RESPID_SIZE) & 0x3;
+ dev_dbg(master->master.dev, "id:%d resp:%d\n", id, response_id);
+
+ resp = response.msg;
+
+ switch (response_id) {
+ case FSI_GPIO_RESP_ACK:
+ if (expected == FSI_GPIO_RESP_ACKD)
+ bits_remaining = 8 * size;
+ break;
+
+ case FSI_GPIO_RESP_BUSY:
+ /*
+ * Its necessary to clock slave before issuing
+ * d-poll, not indicated in the hardware protocol
+ * spec. < 20 clocks causes slave to hang, 21 ok.
+ */
+ set_sda_output(master, 1);
+ clock_toggle(master, FSI_GPIO_DPOLL_CLOCKS);
+ cmd.msg = FSI_GPIO_CMD_DPOLL;
+ cmd.bits = FSI_GPIO_CMD_DPOLL_SIZE;
+ serial_out(master, &cmd);
+ echo_delay(master);
+ continue;
+
+ case FSI_GPIO_RESP_ERRA:
+ case FSI_GPIO_RESP_ERRC:
+ dev_dbg(master->master.dev, "ERR received: %d\n",
+ (int)response.msg);
+ /*
+ * todo: Verify crc from slave and in general
+ * only act on any response if crc is correct
+ */
+ clock_toggle(master, FSI_GPIO_CRC_SIZE);
+ fsi_master_gpio_error(master, response.msg);
+ return -EIO;
+ }
+
+ /* Read in the data field if applicable */
+ if (bits_remaining) {
+ serial_in(master, &response, bits_remaining);
+ resp <<= bits_remaining;
+ resp |= response.msg;
+ bits_received += bits_remaining;
+ *((uint32_t *)data) = response.msg;
+ }
+
+ crc_in = crc_fsi(0, resp | (0x1ULL << bits_received),
+ bits_received + 1);
+
+ /* Read in the crc and check it */
+ serial_in(master, &response, FSI_GPIO_CRC_SIZE);
+ if (crc_in != response.msg) {
+ dev_dbg(master->master.dev, "ERR response CRC\n");
+ fsi_master_gpio_error(master, FSI_GPIO_CRC_INVAL);
+ return -EIO;
+ }
+ /* Clock the slave enough to be ready for next operation */
+ clock_toggle(master, FSI_GPIO_PRIME_SLAVE_CLOCKS);
+ return 0;
+
+ } while (busy_count++ < FSI_GPIO_MAX_BUSY);
+
+ dev_dbg(master->master.dev, "ERR slave is stuck in busy state\n");
+ fsi_master_gpio_error(master, FSI_GPIO_ERR_BUSY);
+
+ return -EIO;
+}
+
+static void build_abs_ar_command(struct fsi_gpio_msg *cmd, uint64_t mode,
+ uint8_t slave, uint32_t addr, size_t size,
+ const void *data)
+{
+ uint8_t crc;
+
+ cmd->bits = FSI_GPIO_CMD_DFLT_LEN;
+ cmd->msg = FSI_GPIO_CMD_DEFAULT;
+ cmd->msg |= mode;
+ cmd->msg &= ~FSI_GPIO_CMD_SLAVE_MASK;
+ cmd->msg |= (((uint64_t)slave) << FSI_GPIO_CMD_SLV_SHIFT);
+ addr &= FSI_GPIO_CMD_ADDR_MASK;
+ cmd->msg |= (((uint64_t)addr) << FSI_GPIO_CMD_ADDR_SHIFT);
+ if (size == sizeof(uint8_t)) {
+ if (data) {
+ uint8_t cmd_data = *((uint8_t *)data);
+
+ cmd->msg |=
+ ((uint64_t)cmd_data) << FSI_GPIO_CMD_DT8_SHIFT;
+ }
+ } else if (size == sizeof(uint16_t)) {
+ cmd->msg |= FSI_GPIO_CMD_SIZE_16;
+ if (data) {
+ uint16_t cmd_data;
+
+ memcpy(&cmd_data, data, size);
+ cmd->msg |=
+ ((uint64_t)cmd_data) << FSI_GPIO_CMD_DT16_SHIFT;
+ }
+ } else {
+ cmd->msg |= FSI_GPIO_CMD_SIZE_32;
+ if (data) {
+ uint32_t cmd_data;
+
+ memcpy(&cmd_data, data, size);
+ cmd->msg |=
+ ((uint64_t)cmd_data) << FSI_GPIO_CMD_DT32_SHIFT;
+ }
+ }
+
+ if (mode == FSI_GPIO_CMD_WRITE)
+ cmd->bits += (8 * size);
+
+ /* Include start bit */
+ crc = crc_fsi(0,
+ (cmd->msg >> (64 - cmd->bits)) | (0x1ULL << cmd->bits),
+ cmd->bits + 1);
+ cmd->msg |= ((uint64_t)crc) << (FSI_GPIO_CMD_CRC_SHIFT - cmd->bits);
+ cmd->bits += FSI_GPIO_CRC_SIZE;
+
+ /* Right align message */
+ cmd->msg >>= (64 - cmd->bits);
+}
+
+static int fsi_master_gpio_read(struct fsi_master *_master, int link,
+ uint8_t slave, uint32_t addr, void *val, size_t size)
+{
+ struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
+ struct fsi_gpio_msg cmd;
+ int rc;
+ unsigned long flags;
+
+ if (link != 0)
+ return -ENODEV;
+
+ build_abs_ar_command(&cmd, FSI_GPIO_CMD_READ, slave, addr, size, NULL);
+
+ spin_lock_irqsave(&fsi_gpio_cmd_lock, flags);
+ serial_out(master, &cmd);
+ echo_delay(master);
+ rc = poll_for_response(master, FSI_GPIO_RESP_ACKD, size, val);
+ spin_unlock_irqrestore(&fsi_gpio_cmd_lock, flags);
+
+ return rc;
+}
+
+static int fsi_master_gpio_write(struct fsi_master *_master, int link,
+ uint8_t slave, uint32_t addr, const void *val, size_t size)
+{
+ struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
+ struct fsi_gpio_msg cmd;
+ int rc;
+ unsigned long flags;
+
+ if (link != 0)
+ return -ENODEV;
+
+ build_abs_ar_command(&cmd, FSI_GPIO_CMD_WRITE, slave, addr, size, val);
+
+ spin_lock_irqsave(&fsi_gpio_cmd_lock, flags);
+ serial_out(master, &cmd);
+ echo_delay(master);
+ rc = poll_for_response(master, FSI_GPIO_RESP_ACK, size, NULL);
+ spin_unlock_irqrestore(&fsi_gpio_cmd_lock, flags);
+
+ return rc;
+}
+
+/*
+ * Issue a break command on link
+ */
+static int fsi_master_gpio_break(struct fsi_master *_master, int link)
+{
+ struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
+
+ if (link != 0)
+ return -ENODEV;
+
+ set_sda_output(master, 1);
+ clock_toggle(master, FSI_PRE_BREAK_CLOCKS);
+ sda_out(master, 0);
+ clock_toggle(master, FSI_BREAK_CLOCKS);
+ echo_delay(master);
+ sda_out(master, 1);
+ clock_toggle(master, FSI_POST_BREAK_CLOCKS);
+
+ /* Wait for logic reset to take effect */
+ udelay(200);
+
+ return 0;
+}
+
+static int fsi_master_gpio_link_enable(struct fsi_master *_master, int link)
+{
+ struct fsi_master_gpio *master = to_fsi_master_gpio(_master);
+
+ if (link != 0)
+ return -ENODEV;
+ if (master->gpio_enable)
+ gpiod_set_value(master->gpio_enable, 1);
+
+ return 0;
+}
+
+static int fsi_master_gpio_probe(struct platform_device *pdev)
+{
+ struct fsi_master_gpio *master;
+
+ master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
+ if (!master)
+ return -ENOMEM;
+
+ master->master.dev = &pdev->dev;
+
+ master->gpio_clk = devm_gpiod_get(&pdev->dev, "clock", GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_clk)) {
+ dev_dbg(&pdev->dev, "probe: failed to get clock pin\n");
+ return PTR_ERR(master->gpio_clk);
+ }
+
+ master->gpio_data = devm_gpiod_get(&pdev->dev, "data", GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_data)) {
+ dev_dbg(&pdev->dev, "probe: failed to get data pin\n");
+ return PTR_ERR(master->gpio_data);
+ }
+
+ /* Optional pins */
+
+ master->gpio_trans = devm_gpiod_get_optional(&pdev->dev, "trans",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_trans))
+ dev_dbg(&pdev->dev, "probe: failed to get trans pin\n");
+
+ master->gpio_enable = devm_gpiod_get_optional(&pdev->dev, "enable",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_enable))
+ dev_dbg(&pdev->dev, "probe: failed to get enable pin\n");
+
+ master->gpio_mux = devm_gpiod_get_optional(&pdev->dev, "mux",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(master->gpio_mux))
+ dev_dbg(&pdev->dev, "probe: failed to get mux pin\n");
+
+ /* todo: evaluate if clocks can be reduced */
+ clock_toggle(master, FSI_INIT_CLOCKS);
+
+ master->master.n_links = 1;
+ master->master.read = fsi_master_gpio_read;
+ master->master.write = fsi_master_gpio_write;
+ master->master.send_break = fsi_master_gpio_break;
+ master->master.link_enable = fsi_master_gpio_link_enable;
+ return fsi_master_register(&master->master);
+}
+
+static int fsi_master_gpio_remove(struct platform_device *pdev)
+{
+ struct fsi_master_gpio *master = platform_get_drvdata(pdev);
+
+ devm_gpiod_put(&pdev->dev, master->gpio_clk);
+ devm_gpiod_put(&pdev->dev, master->gpio_data);
+ if (master->gpio_trans)
+ devm_gpiod_put(&pdev->dev, master->gpio_trans);
+ if (master->gpio_enable)
+ devm_gpiod_put(&pdev->dev, master->gpio_enable);
+ if (master->gpio_mux)
+ devm_gpiod_put(&pdev->dev, master->gpio_mux);
+ fsi_master_unregister(&master->master);
+
+ return 0;
+}
+
+static const struct of_device_id fsi_master_gpio_match[] = {
+ { .compatible = "ibm,fsi-master-gpio" },
+ { },
+};
+
+static struct platform_driver fsi_master_gpio_driver = {
+ .driver = {
+ .name = "fsi-master-gpio",
+ .of_match_table = fsi_master_gpio_match,
+ },
+ .probe = fsi_master_gpio_probe,
+ .remove = fsi_master_gpio_remove,
+};
+
+module_platform_driver(fsi_master_gpio_driver);
+MODULE_LICENSE("GPL");
--
1.8.2.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 18/18] insert build break
From: christopher.lee.bostic @ 2017-01-12 22:37 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, jk, linux-kernel, andrew,
alistair, benh
Cc: Chris Bostic
From: Chris Bostic <cbostic@us.ibm.com>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
drivers/fsi/fsi-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 28b82d1..db09836 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -42,6 +42,7 @@
static DEFINE_IDA(master_ida);
+
struct fsi_slave {
struct device dev;
struct fsi_master *master;
--
1.8.2.2
^ permalink raw reply related
* Re: [PATCH v4 1/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
From: Serge Semin @ 2017-01-12 22:54 UTC (permalink / raw)
To: Greg KH
Cc: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A, andrew-g2DYL2Zd6BY,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170111082119.GA26387-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Wed, Jan 11, 2017 at 09:21:19AM +0100, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Tue, Dec 13, 2016 at 05:22:50PM +0300, Serge Semin wrote:
> > +struct idt_89hpesx_dev {
> > + u32 eesize;
> > + bool eero;
> > + u8 eeaddr;
> > +
> > + u8 inieecmd;
> > + u8 inicsrcmd;
> > + u8 iniccode;
> > +
> > + atomic_t csr;
>
> Why is this an atomic_t and not just a "normal" u32 or u64? I don't see
> the need for an atomic variable at all here, do you?
>
Of course, I did. Since it was shared resource before it was necessary to have
it atomically accessed. But since we moved "csr" sysfs node to DebugFS, it might not
be necessary of atomic_t type.
Ok, I'll make it unsigned int.
>
> > +
> > + int (*smb_write)(struct idt_89hpesx_dev *, const struct idt_smb_seq *);
> > + int (*smb_read)(struct idt_89hpesx_dev *, struct idt_smb_seq *);
> > + struct mutex smb_mtx;
> > +
> > + struct i2c_client *client;
> > +
> > + struct bin_attribute *ee_file;
> > + struct dentry *csr_dir;
> > + struct dentry *csr_file;
> > +};
>
> <snip>
>
> > +
> > +static int idt_create_dbgfs_files(struct idt_89hpesx_dev *pdev)
> > +{
> > + struct device *dev = &pdev->client->dev;
> > + struct i2c_client *cli = pdev->client;
> > + char fname[CSRNAME_LEN];
> > +
> > + /* Initialize basic value of CSR debugfs dentries */
> > + pdev->csr_dir = NULL;
> > + pdev->csr_file = NULL;
> > +
> > + /* Return failure if root directory doesn't exist */
> > + if (!csr_dbgdir) {
> > + dev_dbg(dev, "No Debugfs root directory");
> > + return -EINVAL;
> > + }
>
> If debugfs is not enabled, don't error out, just keep going, it should
> never stop kernel code from running properly.
>
> Also, this test isn't really doing what you think it is doing...
>
I see, it must be replaced with IS_ERR_OR_NULL() test. But I don't think,
it would be good to get rid of dev_dbg() completely here. In case if
debugging is enabled, user would understand why csr-node isn't created within
DebugFS directory. I don't see the reasoning why one shouldn't know a source
of possible problems.
(See the next comment as continue of the discussion)
> > + /* Create Debugfs directory for CSR file */
> > + snprintf(fname, CSRNAME_LEN, "%d-%04hx", cli->adapter->nr, cli->addr);
> > + pdev->csr_dir = debugfs_create_dir(fname, csr_dbgdir);
> > + if (IS_ERR_OR_NULL(pdev->csr_dir)) {
> > + dev_err(dev, "Failed to create CSR node directory");
> > + return -EINVAL;
>
> Again, don't do this, you really don't care if debugfs worked or not.
>
Actually the driver doesn't stop the kernel code from running, if it finds out
any problem with DebugFS CSR-node creation. The function just logs the error
and return error status. Take a look the place the method is called:
1489 /* Create debugfs files */
1490 (void)idt_create_dbgfs_files(pdev);
The initialization code doesn't check the return value at all, so the driver
will proceed with further code.
Why did I make the function with return value? Because it's a good style to
always return a status of function code execution if it may fail, but only
caller will decide whether to check the return value or not.
Regarding the error printing. In case if the code gets to this check, one can
be sure the DebugFS works properly, so in case if the driver failed to create
the corresponding sub-directory or node, it is really error to have any failure
at this point, and a user should be notified. But still the driver won't stop
functioning, since the caller doesn't check the return value.
Hopefully you'll understand my point.
> > + }
> > +
> > + /* Create Debugfs file for CSR read/write operations */
> > + pdev->csr_file = debugfs_create_file(cli->name, 0600,
> > + pdev->csr_dir, pdev, &csr_dbgfs_ops);
> > + if (IS_ERR_OR_NULL(pdev->csr_file)) {
> > + dev_err(dev, "Failed to create CSR dbgfs-node");
> > + debugfs_remove_recursive(pdev->csr_dir);
> > + return -EINVAL;
>
> Same here, just create the file and move on.
>
> > + }
> > +
> > + dev_dbg(dev, "Debugfs-files created");
>
> You do know about ftrace, right? Please remove all of these
> "trace-like" debugging lines, they aren't needed for anyone.
>
Ok, I'll remove all these prints, even though I do find these prints being
handy to have initialization process printed on debugging stage.
> thanks,
>
> greg k-h
thanks,
Sergey
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: vf610-zii-dev: add EEPROM entry to Rev C
From: Vivien Didelot @ 2017-01-12 23:06 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, kernel, Andrey Smirnov, Shawn Guo, Rob Herring,
Mark Rutland, Russell King, Sascha Hauer, Stefan Agner,
devicetree, andrew, Vivien Didelot, Nikita Yushchenko, cphealy
The ZII Dev Rev C board has EEPROMs hanging the 88E6390 Ethernet switch
chips. Add an "eeprom-length" property to allow access from ethtool.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
---
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
index fbedb7bb3628..6a45bd24ffe6 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -71,6 +71,7 @@
#size-cells = <0>;
reg = <0>;
dsa,member = <0 0>;
+ eeprom-length = <512>;
ports {
#address-cells = <1>;
@@ -128,6 +129,7 @@
#size-cells = <0>;
reg = <0>;
dsa,member = <0 1>;
+ eeprom-length = <512>;
ports {
#address-cells = <1>;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 10/24] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
From: Steve Longerbeam @ 2017-01-12 23:40 UTC (permalink / raw)
To: Tim Harvey, Steve Longerbeam
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
Russell King - ARM Linux, mchehab, Hans Verkuil, Nick Dyer,
markus.heiser, Philipp Zabel, laurent.pinchart+renesas, bparrot,
geert, Arnd Bergmann, Sudip Mukherjee, minghsiu.tsai, Tiffany Lin,
Jean-Christophe TROTIN, Simon Horman
In-Reply-To: <CAJ+vNU1ci=fbeemJcBGCAk40PETdcov7Fm112F5FePL9SR4cFQ@mail.gmail.com>
On 01/12/2017 11:37 AM, Tim Harvey wrote:
> On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
>> Add pinctrl groups for both GPT input capture channels.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> index 967c3b8..495709f 100644
>> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
>> @@ -457,6 +457,18 @@
>> >;
>> };
>>
>> + pinctrl_gpt_input_capture0: gptinputcapture0grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_gpt_input_capture1: gptinputcapture1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2 0x1b0b0
>> + >;
>> + };
>> +
>> pinctrl_spdif: spdifgrp {
>> fsl,pins = <
>> MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
>> --
> Steve,
>
> These are not used anywhere.
Yes, maybe I should just remove this patch for now. I'm only keeping it
because eventually it will be needed to support i.MX6 input capture.
Steve
^ permalink raw reply
* Re: [PATCH] ARM: dts: NSP: Fix DT ranges error
From: Florian Fainelli @ 2017-01-13 0:07 UTC (permalink / raw)
To: Jon Mason, Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484236210-16067-1-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 01/12/2017 07:50 AM, Jon Mason wrote:
> The range size for axi is 0x2 bytes too small, as the QSPI needs
> 0x11c408 + 0x004 (which is 0x0011c40c, not 0x0011c40a). No errors have
> been observed with this shortcoming, but fixing it for correctness.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Applied to devicetree/fixes thanks Jon.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/5] i2c: mux: pca954x: Add interrupt controller support
From: Phil Reid @ 2017-01-13 0:17 UTC (permalink / raw)
To: Wolfram Sang; +Cc: peda, robh+dt, mark.rutland, linux-i2c, devicetree
In-Reply-To: <20170112191514.dpusqnbqahayx6j3@ninjato>
On 13/01/2017 03:15, Wolfram Sang wrote:
> On Mon, Jan 09, 2017 at 05:02:54PM +0800, Phil Reid wrote:
>> Various muxes can aggregate multiple interrupts from each i2c bus.
>> All of the muxes with interrupt support combine the active low irq lines
>> using an internal 'and' function and generate a combined active low
>> output. The muxes do provide the ability to read a control register to
>> determine which irq is active. By making the mux an irq controller isr
>> latency can potentially be reduced by reading the status register and
>> then only calling the registered isr on that bus segment.
>>
>> As there is no irq masking on the mux irq are disabled until irq_unmask is
>> called at least once.
>>
>> Signed-off-by: Phil Reid <preid@electromag.com.au>
>
> Is the ack from Peda here forgotten or still missing?
>
> @peda: Once you are happy, do you want to take these patches via your
> shiny new mux-tree or do you prefer if I pick them?
>
G'day Wolfram,
I think he was hoping someone else would have a look at it based on this
feedback.
On 2017-01-04 15:13, Peter Rosin wrote:
> Irqs are not my strong point, I would prefer if someone else also had
> a look. And there are some comments below...
--
Regards
Phil Reid
^ permalink raw reply
* Re: [PATCHv5 3/8] rtc: add STM32 RTC driver
From: Alexandre Belloni @ 2017-01-13 0:38 UTC (permalink / raw)
To: Amelie Delaunay
Cc: Alessandro Zummo, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Russell King, rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Gabriel Fernandez
In-Reply-To: <1484142403-11556-1-git-send-email-amelie.delaunay-qxv4g6HH51o@public.gmane.org>
On 11/01/2017 at 14:46:43 +0100, Amelie Delaunay wrote :
> This patch adds support for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/rtc/Kconfig | 11 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-stm32.c | 727 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 739 insertions(+)
> create mode 100644 drivers/rtc/rtc-stm32.c
>
This didn't apply cleanly, please check rtc-next. I don't think I made
any mistake as the issue was only in Kconfig. You probably based your
patches on 4.9 instead of 4.10-rc1.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCHv3 2/8] dt-bindings: document the STM32 RTC bindings
From: Alexandre Belloni @ 2017-01-13 0:39 UTC (permalink / raw)
To: Amelie Delaunay
Cc: Alessandro Zummo, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Russell King, rtc-linux, devicetree,
linux-arm-kernel, linux-kernel, Gabriel Fernandez
In-Reply-To: <1483623809-29937-3-git-send-email-amelie.delaunay@st.com>
On 05/01/2017 at 14:43:23 +0100, Amelie Delaunay wrote :
> This patch adds documentation of device tree bindings for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/rtc/st,stm32-rtc.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage
From: Kevin Hilman @ 2017-01-13 0:52 UTC (permalink / raw)
To: Jerome Brunet
Cc: Carlo Caione, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1482319894-656-1-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
> OdroidC2 GbE link breaks under heavy tx transfer. This happens even if the
> MAC does not enable Energy Efficient Ethernet (No Low Power state Idle on
> the Tx path). The problem seems to come from the phy Rx path, entering the
> LPI state.
>
> Disabling EEE advertisement on the phy prevent this feature to be
> negociated with the link partner and solve the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
>
> This patch is based on Linus recent master branch [0]
> This patch depends on the series [1] which has been merged in this branch.
>
> 0: ba6d973f78eb ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> 1: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
> Fix integration of eee-broken-modes
>
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbeacd330..d8933e9e9a5a 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -147,6 +147,18 @@
> status = "okay";
> pinctrl-0 = <ð_rgmii_pins>;
> pinctrl-names = "default";
> + phy-handle = <ð_phy0>;
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy@0 {
> + reg = <0>;
> + eee-broken-1000t;
> + };
> + };
There's already an MDIO node in the meson-gx.dtsi (using the same
compatible), shouldn't you just override that and add the new
properties?
What would make things easier is if the names were like Martin used in
his reset patch, so that when I merge them together it's not a major
conflict.
Thanks,
Kevin
[1] https://patchwork.kernel.org/patch/9459409/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v20 0/4] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2017-01-13 1:27 UTC (permalink / raw)
To: Rob Herring, Jassi Brar, Matthias Brugger
Cc: Daniel Kurtz, Sascha Hauer, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, srv_heupstream, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, CK HU, cawa cheng, Bibby Hsieh,
YT Shen, Daoyuan Huang, Damon Chu, Josh-YC Liu, Glory Hung,
Jiaguang Zhang, Dennis-YC Hsieh
In-Reply-To: <1483499169-16329-1-git-send-email-hs.liao@mediatek.com>
On Wed, 2017-01-04 at 11:06 +0800, HS Liao wrote:
> Hi,
>
> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> to help write registers with critical time limitation, such as
> updating display configuration during the vblank. It controls Global
> Command Engine (GCE) hardware to achieve this requirement.
>
> These patches have a build dependency on top of v4.10-rc2.
>
> Changes since v19:
> - rebase to v4.10-rc2
>
> Best regards,
> HS Liao
>
> HS Liao (4):
> dt-bindings: soc: Add documentation for the MediaTek GCE unit
> mailbox: mediatek: Add Mediatek CMDQ driver
> arm64: dts: mt8173: Add GCE node
> soc: mediatek: Add Mediatek CMDQ helper
>
> .../devicetree/bindings/mailbox/mtk-gce.txt | 43 ++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> drivers/mailbox/Kconfig | 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mtk-cmdq-mailbox.c | 596 +++++++++++++++++++++
> drivers/soc/mediatek/Kconfig | 12 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-cmdq-helper.c | 310 +++++++++++
> include/linux/mailbox/mtk-cmdq-mailbox.h | 75 +++
> include/linux/soc/mediatek/mtk-cmdq.h | 174 ++++++
> 10 files changed, 1233 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
> create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
>
Hi Jassi, Matthias,
Sorry to disturb you.
Do you have any further comments on CMDQ v20?
Thanks.
HS
^ permalink raw reply
* [PATCH] arm64: dts: mt8173: Fix cpu_thermal cooling-maps contributions
From: Daniel Kurtz @ 2017-01-13 2:30 UTC (permalink / raw)
Cc: Dawei Chien, Javi Merino, Daniel Kurtz, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Matthias Brugger, Hans Verkuil,
Mauro Carvalho Chehab, Tiffany Lin, CK Hu, Andrew-CT Chen,
Sascha Hauer, Minghsiu Tsai, Yong Wu, Chunfeng Yun,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
According to [0], the contribution field for each cooling-device express
their relative power efficiency. Higher weights express higher power
efficiency. Weighting is relative such that if each cooling device has a
weight of 1 they are considered equal. This is particularly useful in
heterogeneous systems where two cooling devices may perform the same kind
of compute, but with different efficiency.
[0] Documentation/thermal/power_allocator.txt
According to Mediatek IC designer, the power efficiency ratio between the
LITTLE core cluster (cooling-device cpu0) and big core cluster
(cooling-device cpu1) is around 3:1 (3072:1024).
Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e702771f5c..9a3b0d20f7a8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -182,12 +182,12 @@
map@0 {
trip = <&target>;
cooling-device = <&cpu0 0 0>;
- contribution = <1024>;
+ contribution = <3072>;
};
map@1 {
trip = <&target>;
cooling-device = <&cpu2 0 0>;
- contribution = <2048>;
+ contribution = <1024>;
};
};
};
--
2.11.0.390.gc69c2f50cf-goog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
From: Jacky Bai @ 2017-01-13 3:04 UTC (permalink / raw)
To: Stephen Boyd
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
p.zabel@pengutronix.de, mturquette@baylibre.com,
daniel.lezcano@linaro.org, linux-clk@vger.kernel.org,
linux-gpio@vger.kernel.org, robh+dt@kernel.org,
kernel@pengutronix.de, jacky.baip@gmail.com, Fabio Estevam,
tglx@linutronix.de, shawnguo@kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170112220536.GP17126@codeaurora.org>
> Subject: Re: [PATCH v2 04/12] driver: clk: imx: Add clock driver for imx6sll
>
> > > > +
> > > > +static const char *pll_bypass_src_sels[] = { "osc", "dummy", };
> > >
> > > All these should be const char * const unless something is wrong.
> >
> > If changed to 'const char * const', it vill has argument type mismatch
> > error, as imx_clk_* wrapper function has argument type 'const char *'.
>
> Hmm that's unfortunate.
>
> >
> > >
> > > > +
> > > > + for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> > > > + clk_prepare_enable(clks[clks_init_on[i]]);
> > >
> > > Critical clocks?
> >
> > Yes, these clocks must be always on.
> >
> > >
> > > > +
> > > > + if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
> > > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY1_GATE]);
> > > > + clk_prepare_enable(clks[IMX6SLL_CLK_USBPHY2_GATE]);
> > >
> > > The phy driver can't enable these?
> >
> > The reason why we enable these two clks here is in below commit commit
> > a5120e89e7e187a91852896f586876c7a2030804
> > Author: Peter Chen <peter.chen@freescale.com>
> > Date: Fri Jan 18 10:38:05 2013 +0800
> > ARM i.MX6: change mxs usbphy clock usage
> >
>
> So can we mark these clks with CLK_IS_CRITICAL flag then instead?
> Or are they disabled out of the bootloader?
>
Sure, using 'CLK_IS_CRITICAL' should be ok for clks_init_on clocks. But for USBPHY*_GATE, it is
only enabled when CONIG_USB_MXC_PHY is true. And another concern is if we need to add CLK_IS_CRITICAL
flag to clks_init_on clocks, we may need to add new wrapper function to register these critical clock. It is not very good.
> >
> > > > + }
> > > > +
> > > > + /* Lower the AHB clock rate before changing the clock source. */
> > > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 99000000);
> > > > +
> > > > + /* Change periph_pre clock to pll2_bus to adjust AXI rate to 264MHz */
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_CLK2_SEL],
> > > clks[IMX6SLL_CLK_PLL3_USB_OTG]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > > clks[IMX6SLL_CLK_PERIPH_CLK2]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH_PRE],
> > > clks[IMX6SLL_CLK_PLL2_BUS]);
> > > > + clk_set_parent(clks[IMX6SLL_CLK_PERIPH],
> > > > +clks[IMX6SLL_CLK_PERIPH_PRE]);
> > > > +
> > > > + clk_set_rate(clks[IMX6SLL_CLK_AHB], 132000000);
> > >
> > > assigned-clocks for rates now? Or perhaps we shouldn't be exposing
> > > these as clks if they have some sort of complicated rate sequence
> > > switch that we can't guarantee with the clk_ops we have today.
> >
> > These clks will be used by some peripherals, so we need to expose these
> clocks.
> > And the above parent and rate swith sequence is not very easy to be
> > handled in assigned-clocks, So we leave it in this place.
> >
>
> How do we guarantee that the rate switch doesn't happen later on, requiring
> this coordinated sequence of clk operations?
>
This clock sequence is used for increasing the AXI and AHB bus clock rate. In normal
use, it is very rarely that we need to change them again. If we really need to change
AXI and AHB bus clock later, a similar sequence must be used to do this.
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 4/4] mmc: pwrseq-simple: add disable-post-power-on option
From: Matt Ranostay @ 2017-01-13 3:12 UTC (permalink / raw)
To: Ulf Hansson
Cc: Linus Walleij, Rob Herring, devicetree@vger.kernel.org,
linux-mmc@vger.kernel.org, Tony Lindgren, Liam Breck
In-Reply-To: <CAPDyKFpm_B0aSQ2sY6yz9eYGzp1sokLVt0uk5K-9UkU=gYOOEw@mail.gmail.com>
On Thu, Jan 12, 2017 at 7:57 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 12 January 2017 at 05:43, Matt Ranostay <matt@ranostay.consulting> wrote:
>> On Wed, Jan 11, 2017 at 2:55 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>> On 9 January 2017 at 05:53, Matt Ranostay <matt@ranostay.consulting> wrote:
>>>> On Fri, Dec 30, 2016 at 12:05 AM, Linus Walleij
>>>> <linus.walleij@linaro.org> wrote:
>>>>> On Mon, Dec 19, 2016 at 1:01 AM, Matt Ranostay <matt@ranostay.consulting> wrote:
>>>>>
>>>>>> * SD8787 has a "powerdown" line, and CW1200 has a "powerup" line.. I
>>>>>> know this is a simple logic inversion.
>>>>>
>>>>> If this is a GPIO line, the GPIO subsystem can flag a line for
>>>>> inverted logic. GPIO_ACTIVE_LOW from device tree for example.
>>>>
>>>> Slight ping on Ulf on this thread :).
>>>
>>> Thanks, sorry for the delay!
>>>
>>>>
>>>> I do understand the inverted logic flag but that doesn't help if there
>>>> are different logic states between various chipsets.
>>>
>>> For cw1200 (I looked at code from an old ST-Ericsson vendor tree), the
>>> sequence is as follows:
>>>
>>> 1) Enable clock/power to the card/chip.
>>> 2) Assert GPIO pin. I assume this also can be done before the
>>> clock/power is enabled.
>>> 3) Wait some time (~50ms).
>>> 4) De-assert GPIO pin.
>>> 5) Wait some time (~20ms)
>>> 6) Assert GPIO pin.
>>> 7) Wait some time (~32ms).
>>>
>>> At power off, the GPIO pin is de-asserted and of course also the
>>> clock/power is disabled. Just to make sure we have all the relevant
>>> logic.
>>>
>>> Looking at mmc pwrseq simple, perhaps we can extend this to deal with
>>> GPIOs that needs to be *toggled*, as this is not just reset GPIOs.
>>> Then we also need to deal with the delays in-between the toggling.
>>
>> Wouldn't we need to have a per chip function for each device
>> supported? As well document gpios? I suspect we'd need an array of
>
> I was hoping to avoid this, but the more I look at it, it seems inevitable.
>
>> gpios defined in device tree since different devices will likely have
>> various numbers of pins to toggle
>
> Maybe we can think of a clever way to combine cw1200 with your case?
> Perhaps a "mmc pwrseq toggle". :-) If not, please go ahead an repost a
> device specific mmc pwrseq for your case.
I think the best solution for now. We can merge the two solutions
latter down the road.
Thanks,
Matt
>
> I realize this would be a good opportunity for me to work on enabling
> support for cw1200 on ux500, but as the implementation of the
> clock/power control also needs to be up-streamed, I am quite far from
> being done.
>
> Kind regards
> Uffe
^ permalink raw reply
* Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300
From: Gautham R Shenoy @ 2017-01-13 3:44 UTC (permalink / raw)
To: Balbir Singh
Cc: Gautham R. Shenoy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rafael J. Wysocki, Daniel Lezcano,
Michael Neuling, Vaidyanathan Srinivasan, Shreyas B. Prabhu,
Shilpasri G Bhat, Stewart Smith, Oliver O'Halloran,
linuxppc-dev, linux-kernel, linux-pm, devicetree, Rob Herring,
mark.rutland
In-Reply-To: <20170112094733.GC3006@localhost.localdomain>
On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote:
> On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote:
> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> >
> > Balbir pointed out that in idle_book3s.S and powernv/idle.c some
> > functions and variables had power9 in their names while some others
> > had arch300.
> >
>
> I would prefer power9 to arch300
>
I don't have a strong preference for arch300 vs power9, will change it
to power9 if that looks better.
--
Thanks and Regards
gautham.
^ permalink raw reply
* Re: [PATCH v5 2/5] powernv:stop: Uniformly rename power9 to arch300
From: Oliver O'Halloran @ 2017-01-13 3:46 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Balbir Singh, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rafael J. Wysocki, Daniel Lezcano,
Michael Neuling, Vaidyanathan Srinivasan, Shreyas B. Prabhu,
Shilpasri G Bhat, Stewart Smith, linuxppc-dev, linux-kernel,
linux-pm, devicetree, Rob Herring, mark.rutland
In-Reply-To: <20170113034418.GA10844@in.ibm.com>
On Fri, Jan 13, 2017 at 2:44 PM, Gautham R Shenoy
<ego@linux.vnet.ibm.com> wrote:
> On Thu, Jan 12, 2017 at 03:17:33PM +0530, Balbir Singh wrote:
>> On Tue, Jan 10, 2017 at 02:37:01PM +0530, Gautham R. Shenoy wrote:
>> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>> >
>> > Balbir pointed out that in idle_book3s.S and powernv/idle.c some
>> > functions and variables had power9 in their names while some others
>> > had arch300.
>> >
>>
>> I would prefer power9 to arch300
>>
>
>
> I don't have a strong preference for arch300 vs power9, will change it
> to power9 if that looks better.
Personally I think we should be as descriptive as possible and use
power_9_arch_300_the_bikeshed_is_red_dammit.
Oliver
^ permalink raw reply
* RE: [PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2017-01-13 4:28 UTC (permalink / raw)
To: Vinod Koul
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
dan.j.williams@intel.com, michal.simek@xilinx.com,
Soren Brinkmann, moritz.fischer@ettus.com,
laurent.pinchart@ideasonboard.com, luis@debethencourt.com,
Jose.Abreu@synopsys.com, dmaengine@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20170110062349.GY3573@localhost>
Hi Vinod,
Thanks for the review...
>
> On Sat, Jan 07, 2017 at 12:15:28PM +0530, Kedareswara rao Appana wrote:
> > Add channel idle state to ensure that dma descriptor is not
> > submitted when VDMA engine is in progress.
>
> any reason why you want to make your own varible and not use the HW to
> query
> as done earlier. It is not clear to me why that is removed from description
We need to poll for a bit in the status register to know the dma state.
We are currently doing that in the driver hot path
To avoid this using own variables.
Regards,
Kedar.
^ permalink raw reply
* Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-13 4:36 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-kernel, linux-sunxi,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Stephen Boyd, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linus Walleij, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chen-Yu Tsai
In-Reply-To: <20170112174122.iqzrcyytfefqspwq@lukather>
13.01.2017, 01:41, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> On Fri, Jan 13, 2017 at 01:31:41AM +0800, Icenowy Zheng wrote:
>> 2017年1月13日 01:19于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
>> >
>> > On Thu, Jan 12, 2017 at 03:44:53AM +0800, Icenowy Zheng wrote:
>> > >
>> > >
>> > > 12.01.2017, 03:40, "Icenowy Zheng" <icenowy-ymACFijhrKM@public.gmane.org>:
>> > > > 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> > > >> On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
>> > > >>> V3s has a similar but cut-down CCU to H3.
>> > > >>>
>> > > >>> Add support for it.
>> > > >>>
>> > > >>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> > > >>
>> > > >> It looks like there's nothing different but the clocks that you
>> > > >> register with the H3, please just use the H3 driver.
>> > > >
>> > > > Nope.
>> > > >
>> > > > It has a different PLL (PLL_ISP) at different address, and some
>> > > > different muxes.
>> > >
>> > > Forgot to mention the missing of PLL_DE and related misses.
>> >
>> > Those are not conflicting, it's just a slightly different set of
>> > clocks.
>>
>> If saying so, we can have only one ccu driver, and make every ccu
>> register different set ;-)
>>
>> V3s itself is a totally different SoC with H3.
>>
>> The relationship of V3s and H3 can be farther than the relationship
>> of A33 and H3😃
>
> A33 and H3 are an entirely different story. The H3 and A33 have
> conflicting clocks (ie same clocks with different parameters). This is
> not your case.
I think V3s and H3 has also conflicting clocks, e.g. CLK_DE.
The mux of CLK_DE in V3s is PLL_PERIPHx2 and PLL_VIDEO, but on H3
it's PLL_PERIPHx2 and PLL_DE (V3s lacks PLL_DE).
(What I say that there's a PLL missing means that there will also be mux
changes... I think you can understand this... sorry.)
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v2 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:22 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset
Matt Ranostay (2):
devicetree: document vmmc-supply and mmc-pwrseq options
mmc: pwrseq: add support for Marvell SD8787 chip
.../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++++++-
drivers/mmc/core/Kconfig | 10 ++++++++++
drivers/mmc/core/Makefile | 1 +
3 files changed, 17 insertions(+), 1 deletion(-)
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/2] devicetree: document vmmc-supply and mmc-pwrseq options
From: Matt Ranostay @ 2017-01-13 5:22 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, Matt Ranostay
In-Reply-To: <20170113052218.10534-1-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
---
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
This node provides properties for controlling the Marvell SDIO/PCIE wireless device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+ for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:22 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree
Cc: tony, Matt Ranostay, Ulf Hansson
In-Reply-To: <20170113052218.10534-1-matt@ranostay.consulting>
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
drivers/mmc/core/Kconfig | 10 ++++++++++
drivers/mmc/core/Makefile | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:24 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Linux Kernel,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Tony Lindgren, Matt Ranostay, Ulf Hansson
In-Reply-To: <20170113052218.10534-3-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
On Thu, Jan 12, 2017 at 9:22 PM, Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
Er crap seems how the main patch file got dropped out. Resubmitting in
a minute... sorry!
>
> Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> ---
> drivers/mmc/core/Kconfig | 10 ++++++++++
> drivers/mmc/core/Makefile | 1 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index cdfa8520a4b1..fc1ecdaaa9ca 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
> This driver can also be built as a module. If so, the module
> will be called pwrseq_emmc.
>
> +config PWRSEQ_SD8787
> + tristate "HW reset support for SD8787 BT + Wifi module"
> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
> + help
> + This selects hardware reset support for the SD8787 BT + Wifi
> + module. By default this option is set to n.
> +
> + This driver can also be built as a module. If so, the module
> + will be called pwrseq_sd8787.
> +
> config PWRSEQ_SIMPLE
> tristate "Simple HW reset support for MMC"
> default y
> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
> index b2a257dc644f..0f81464fa824 100644
> --- a/drivers/mmc/core/Makefile
> +++ b/drivers/mmc/core/Makefile
> @@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
> quirks.o slot-gpio.o
> mmc_core-$(CONFIG_OF) += pwrseq.o
> obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
> +obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset
Changes from v2:
* fix rookie mistake missing the main source file and docs
Matt Ranostay (2):
devicetree: document new marvell-8xxx and pwrseq-sd8787 options
mmc: pwrseq: add support for Marvell SD8787 chip
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
.../bindings/net/wireless/marvell-8xxx.txt | 7 +-
drivers/mmc/core/Kconfig | 10 ++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
5 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
--
2.10.2
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox