* [PATCH/RESEND V4 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-01 13:28 UTC (permalink / raw)
To: catalin.marinas, will.deacon, robh+dt, bhelgaas, mark.rutland,
arnd, linux-arm-kernel
Cc: lorenzo.pieralisi, linux-kernel, linuxarm, devicetree, linux-pci,
linux-serial, minyard, benh, liviu.dudau, zourongrong, john.garry,
gabriele.paoloni, zhichang.yuan02, kantyzc, xuwei5, zhichang.yuan
In-Reply-To: <1478006926-240933-1-git-send-email-yuanzhichang@hisilicon.com>
On Hip06, the accesses to LPC peripherals work in an indirect way. A
corresponding LPC driver configure some registers in LPC master at first, then
the real accesses on LPC slave devices are finished by the LPC master, which
is transparent to LPC driver.
This patch implement the relevant driver for Hip06 LPC. Cooperating with
indirect-IO, ipmi messages is in service without any changes on ipmi driver.
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
---
.../arm/hisilicon/hisilicon-low-pin-count.txt | 31 ++
MAINTAINERS | 8 +
drivers/bus/Kconfig | 8 +
drivers/bus/Makefile | 1 +
drivers/bus/hisi_lpc.c | 501 +++++++++++++++++++++
5 files changed, 549 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
create mode 100644 drivers/bus/hisi_lpc.c
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
new file mode 100644
index 0000000..e681419
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
@@ -0,0 +1,31 @@
+Hisilicon Hip06 low-pin-count device
+ Usually LPC controller is part of PCI host bridge, so the legacy ISA ports
+ locate on LPC bus can be accessed direclty. But some SoCs have independent
+ LPC controller, and access the legacy ports by triggering LPC I/O cycles.
+ Hisilicon Hip06 implements this LPC device.
+
+Required properties:
+- compatible: should be "hisilicon,low-pin-count"
+- #address-cells: must be 2 which stick to the ISA/EISA binding doc.
+- #size-cells: must be 1 which stick to the ISA/EISA binding doc.
+- reg: base memory range where the register set for this device is mapped.
+
+Note:
+ The node name before '@' must be "isa" to represent the binding stick to the
+ ISA/EISA binding specification.
+
+Example:
+
+isa@a01b0000 {
+ compatible = "hisilicom,low-pin-count";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x0 0xa01b0000 0x0 0x1000>;
+
+ ipmi0: bt@e4 {
+ compatible = "ipmi-bt";
+ device_type = "ipmi";
+ reg = <0x01 0xe4 0x04>;
+ status = "disabled";
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..7c69410 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5716,6 +5716,14 @@ F: include/uapi/linux/if_hippi.h
F: net/802/hippi.c
F: drivers/net/hippi/
+HISILICON LPC BUS DRIVER
+M: Zhichang Yuan <yuanzhichang@hisilicon.com>
+L: linux-arm-kernel@lists.infradead.org
+W: http://www.hisilicon.com
+S: Maintained
+F: drivers/bus/hisi_lpc.c
+F: Documentation/devicetree/bindings/arm/hisilicon/hisilicon-low-pin-count.txt
+
HISILICON NETWORK SUBSYSTEM DRIVER
M: Yisen Zhuang <yisen.zhuang@huawei.com>
M: Salil Mehta <salil.mehta@huawei.com>
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 7010dca..a108abc 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -64,6 +64,14 @@ config BRCMSTB_GISB_ARB
arbiter. This driver provides timeout and target abort error handling
and internal bus master decoding.
+config HISILICON_LPC
+ bool "Workaround for nonstandard ISA I/O space on Hisilicon Hip0X"
+ depends on (ARCH_HISI || COMPILE_TEST) && ARM64
+ select ARM64_INDIRECT_PIO
+ help
+ Driver needed for some legacy ISA devices attached to Low-Pin-Count
+ on Hisilicon Hip0X SoC.
+
config IMX_WEIM
bool "Freescale EIM DRIVER"
depends on ARCH_MXC
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index c6cfa6b..10b4983 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
obj-$(CONFIG_ARM_CCN) += arm-ccn.o
obj-$(CONFIG_BRCMSTB_GISB_ARB) += brcmstb_gisb.o
+obj-$(CONFIG_HISILICON_LPC) += hisi_lpc.o
obj-$(CONFIG_IMX_WEIM) += imx-weim.o
obj-$(CONFIG_MIPS_CDMM) += mips_cdmm.o
obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
new file mode 100644
index 0000000..9f48a1a
--- /dev/null
+++ b/drivers/bus/hisi_lpc.c
@@ -0,0 +1,501 @@
+/*
+ * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
+ * Author: Zhichang Yuan <yuanzhichang@hisilicon.com>
+ * Author: Zou Rongrong <zourongrong@huawei.com>
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/acpi.h>
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/serial_8250.h>
+#include <linux/slab.h>
+
+/*
+ * this bit set means each IO operation will target to different port address;
+ * 0 means repeatly IO operations will be sticked on the same port, such as BT;
+ */
+#define FG_INCRADDR_LPC 0x02
+
+struct lpc_cycle_para {
+ unsigned int opflags;
+ unsigned int csize;/* the data length of each operation */
+};
+
+struct hisilpc_dev {
+ spinlock_t cycle_lock;
+ void __iomem *membase;
+ struct extio_ops io_ops;
+};
+
+
+/* The maximum continous operations*/
+#define LPC_MAX_OPCNT 16
+/* only support IO data unit length is four at maximum */
+#define LPC_MAX_DULEN 4
+#if LPC_MAX_DULEN > LPC_MAX_OPCNT
+#error "LPC.. MAX_DULEN must be not bigger than MAX_OPCNT!"
+#endif
+
+#define LPC_REG_START 0x00/* start a new LPC cycle */
+#define LPC_REG_OP_STATUS 0x04/* the current LPC status */
+#define LPC_REG_IRQ_ST 0x08/* interrupt enable&status */
+#define LPC_REG_OP_LEN 0x10/* how many LPC cycles each start */
+#define LPC_REG_CMD 0x14/* command for the required LPC cycle */
+#define LPC_REG_ADDR 0x20/* LPC target address */
+#define LPC_REG_WDATA 0x24/* data to be written */
+#define LPC_REG_RDATA 0x28/* data coming from peer */
+
+
+/* The command register fields*/
+#define LPC_CMD_SAMEADDR 0x08
+#define LPC_CMD_TYPE_IO 0x00
+#define LPC_CMD_WRITE 0x01
+#define LPC_CMD_READ 0x00
+/* the bit attribute is W1C. 1 represents OK. */
+#define LPC_STAT_BYIRQ 0x02
+
+#define LPC_STATUS_IDLE 0x01
+#define LPC_OP_FINISHED 0x02
+
+#define START_WORK 0x01
+
+/*
+ * The minimal waiting interval... Suggest it is not less than 10.
+ * Bigger value probably will lower the performance.
+ */
+#define LPC_NSEC_PERWAIT 100
+/*
+ * The maximum waiting time is about 128us.
+ * The fastest IO cycle time is about 390ns, but the worst case will wait
+ * for extra 256 lpc clocks, so (256 + 13) * 30ns = 8 us. The maximum
+ * burst cycles is 16. So, the maximum waiting time is about 128us under
+ * worst case.
+ * choose 1300 as the maximum.
+ */
+#define LPC_MAX_WAITCNT 1300
+/* About 10us. This is specfic for single IO operation, such as inb. */
+#define LPC_PEROP_WAITCNT 100
+
+
+static inline int wait_lpc_idle(unsigned char *mbase,
+ unsigned int waitcnt) {
+ u32 opstatus;
+
+ while (waitcnt--) {
+ ndelay(LPC_NSEC_PERWAIT);
+ opstatus = readl(mbase + LPC_REG_OP_STATUS);
+ if (opstatus & LPC_STATUS_IDLE)
+ return (opstatus & LPC_OP_FINISHED) ? 0 : (-EIO);
+ }
+ return -ETIME;
+}
+
+
+/**
+ * hisilpc_target_in - trigger a series of lpc cycles to read required data
+ * from target periperal.
+ * @pdev: pointer to hisi lpc device
+ * @para: some paramerters used to control the lpc I/O operations
+ * @ptaddr: the lpc I/O target port address
+ * @buf: where the read back data is stored
+ * @opcnt: how many I/O operations required in this calling
+ *
+ * only one byte data is read each I/O operation.
+ *
+ * Returns 0 on success, non-zero on fail.
+ *
+ */
+static int hisilpc_target_in(struct hisilpc_dev *pdev,
+ struct lpc_cycle_para *para,
+ unsigned long ptaddr, unsigned char *buf,
+ unsigned long opcnt)
+{
+ unsigned int cmd_word;
+ unsigned int waitcnt;
+ int retval;
+ unsigned long flags;
+ unsigned long cnt_per_trans;
+
+ if (!buf || !opcnt || !para || !para->csize || !pdev)
+ return -EINVAL;
+
+ if (opcnt > LPC_MAX_OPCNT)
+ return -EINVAL;
+
+ cmd_word = LPC_CMD_TYPE_IO | LPC_CMD_READ;
+ waitcnt = (LPC_PEROP_WAITCNT);
+ if (!(para->opflags & FG_INCRADDR_LPC)) {
+ cmd_word |= LPC_CMD_SAMEADDR;
+ waitcnt = LPC_MAX_WAITCNT;
+ }
+
+ retval = 0;
+ cnt_per_trans = (para->csize == 1) ? opcnt : para->csize;
+ for (; opcnt && !retval; cnt_per_trans = para->csize) {
+ /* whole operation must be atomic */
+ spin_lock_irqsave(&pdev->cycle_lock, flags);
+
+ writel(cnt_per_trans, pdev->membase + LPC_REG_OP_LEN);
+
+ writel(cmd_word, pdev->membase + LPC_REG_CMD);
+
+ writel(ptaddr, pdev->membase + LPC_REG_ADDR);
+
+ writel(START_WORK, pdev->membase + LPC_REG_START);
+
+ /* whether the operation is finished */
+ retval = wait_lpc_idle(pdev->membase, waitcnt);
+ if (!retval) {
+ opcnt -= cnt_per_trans;
+ for (; cnt_per_trans--; buf++)
+ *buf = readl(pdev->membase + LPC_REG_RDATA);
+ }
+
+ spin_unlock_irqrestore(&pdev->cycle_lock, flags);
+ }
+
+ return retval;
+}
+
+/**
+ * hisilpc_target_out - trigger a series of lpc cycles to write required data
+ * to target periperal.
+ * @pdev: pointer to hisi lpc device
+ * @para: some paramerters used to control the lpc I/O operations
+ * @ptaddr: the lpc I/O target port address
+ * @buf: where the data to be written is stored
+ * @opcnt: how many I/O operations required
+ *
+ * only one byte data is read each I/O operation.
+ *
+ * Returns 0 on success, non-zero on fail.
+ *
+ */
+static int hisilpc_target_out(struct hisilpc_dev *pdev,
+ struct lpc_cycle_para *para,
+ unsigned long ptaddr,
+ const unsigned char *buf,
+ unsigned long opcnt)
+{
+ unsigned int cmd_word;
+ unsigned int waitcnt;
+ int retval;
+ unsigned long flags;
+ unsigned long cnt_per_trans;
+
+ if (!buf || !opcnt || !para || !pdev)
+ return -EINVAL;
+
+ if (opcnt > LPC_MAX_OPCNT)
+ return -EINVAL;
+ /* default is increasing address */
+ cmd_word = LPC_CMD_TYPE_IO | LPC_CMD_WRITE;
+ waitcnt = (LPC_PEROP_WAITCNT);
+ if (!(para->opflags & FG_INCRADDR_LPC)) {
+ cmd_word |= LPC_CMD_SAMEADDR;
+ waitcnt = LPC_MAX_WAITCNT;
+ }
+
+ retval = 0;
+ cnt_per_trans = (para->csize == 1) ? opcnt : para->csize;
+ for (; opcnt && !retval; cnt_per_trans = para->csize) {
+ spin_lock_irqsave(&pdev->cycle_lock, flags);
+
+ writel(cnt_per_trans, pdev->membase + LPC_REG_OP_LEN);
+ opcnt -= cnt_per_trans;
+ for (; cnt_per_trans--; buf++)
+ writel(*buf, pdev->membase + LPC_REG_WDATA);
+
+ writel(cmd_word, pdev->membase + LPC_REG_CMD);
+
+ writel(ptaddr, pdev->membase + LPC_REG_ADDR);
+
+ writel(START_WORK, pdev->membase + LPC_REG_START);
+
+ /* whether the operation is finished */
+ retval = wait_lpc_idle(pdev->membase, waitcnt);
+
+ spin_unlock_irqrestore(&pdev->cycle_lock, flags);
+ }
+
+ return retval;
+}
+
+
+/**
+ * hisilpc_comm_in - read/input the data from the I/O peripheral through LPC.
+ * @devobj: pointer to the device information relevant to LPC controller.
+ * @ptaddr: the target I/O port address.
+ * @dlen: the data length required to read from the target I/O port.
+ *
+ * when succeed, the data read back is stored in buffer pointed by inbuf.
+ * For inb, return the data read from I/O or -1 when error occur.
+ */
+static u64 hisilpc_comm_in(void *devobj, unsigned long ptaddr, size_t dlen)
+{
+ struct hisilpc_dev *lpcdev;
+ struct lpc_cycle_para iopara;
+ u32 rd_data;
+ unsigned char *newbuf;
+ int ret = 0;
+
+ if (!devobj || !dlen || dlen > LPC_MAX_DULEN || (dlen & (dlen - 1)))
+ return -1;
+
+ /* the local buffer must be enough for one data unit */
+ if (sizeof(rd_data) < dlen)
+ return -1;
+
+ newbuf = (unsigned char *)&rd_data;
+
+ lpcdev = (struct hisilpc_dev *)devobj;
+
+ iopara.opflags = FG_INCRADDR_LPC;
+ iopara.csize = dlen;
+
+ ret = hisilpc_target_in(lpcdev, &iopara, ptaddr, newbuf, dlen);
+ if (ret)
+ return -1;
+
+ return le32_to_cpu(rd_data);
+}
+
+/**
+ * hisilpc_comm_out - write/output the data whose maximal length is four bytes to
+ * the I/O peripheral through LPC.
+ * @devobj: pointer to the device information relevant to LPC controller.
+ * @outval: a value to be outputed from caller, maximum is four bytes.
+ * @ptaddr: the target I/O port address.
+ * @dlen: the data length required writing to the target I/O port .
+ *
+ * This function is corresponding to out(b,w,l) only
+ *
+ */
+static void hisilpc_comm_out(void *devobj, unsigned long ptaddr,
+ u32 outval, size_t dlen)
+{
+ struct hisilpc_dev *lpcdev;
+ struct lpc_cycle_para iopara;
+ const unsigned char *newbuf;
+
+ if (!devobj || !dlen || dlen > LPC_MAX_DULEN)
+ return;
+
+ if (sizeof(outval) < dlen)
+ return;
+
+ outval = cpu_to_le32(outval);
+
+ newbuf = (const unsigned char *)&outval;
+ lpcdev = (struct hisilpc_dev *)devobj;
+
+ iopara.opflags = FG_INCRADDR_LPC;
+ iopara.csize = dlen;
+
+ hisilpc_target_out(lpcdev, &iopara, ptaddr, newbuf, dlen);
+}
+
+
+/**
+ * hisilpc_comm_ins - read/input the data in buffer to the I/O peripheral
+ * through LPC, it corresponds to ins(b,w,l)
+ * @devobj: pointer to the device information relevant to LPC controller.
+ * @ptaddr: the target I/O port address.
+ * @inbuf: a buffer where read/input data bytes are stored.
+ * @dlen: the data length required writing to the target I/O port .
+ * @count: how many data units whose length is dlen will be read.
+ *
+ */
+static u64 hisilpc_comm_ins(void *devobj, unsigned long ptaddr,
+ void *inbuf, size_t dlen, unsigned int count)
+{
+ struct hisilpc_dev *lpcdev;
+ struct lpc_cycle_para iopara;
+ unsigned char *newbuf;
+ unsigned int loopcnt, cntleft;
+ unsigned int max_perburst;
+ int ret = 0;
+
+ if (!devobj || !inbuf || !count || !dlen ||
+ dlen > LPC_MAX_DULEN || (dlen & (dlen - 1)))
+ return -1;
+
+ iopara.opflags = 0;
+ if (dlen > 1)
+ iopara.opflags |= FG_INCRADDR_LPC;
+ iopara.csize = dlen;
+
+ lpcdev = (struct hisilpc_dev *)devobj;
+ newbuf = (unsigned char *)inbuf;
+ /*
+ * ensure data stream whose lenght is multiple of dlen to be processed
+ * each IO input
+ */
+ max_perburst = LPC_MAX_OPCNT & (~(dlen - 1));
+ cntleft = count * dlen;
+ do {
+ loopcnt = (cntleft >= max_perburst) ? max_perburst : cntleft;
+ ret = hisilpc_target_in(lpcdev, &iopara, ptaddr, newbuf,
+ loopcnt);
+ if (ret)
+ break;
+ newbuf += loopcnt;
+ cntleft -= loopcnt;
+ } while (cntleft);
+
+ return ret;
+}
+
+/**
+ * hisilpc_comm_outs - write/output the data in buffer to the I/O peripheral
+ * through LPC, it corresponds to outs(b,w,l)
+ * @devobj: pointer to the device information relevant to LPC controller.
+ * @ptaddr: the target I/O port address.
+ * @outbuf: a buffer where write/output data bytes are stored.
+ * @dlen: the data length required writing to the target I/O port .
+ * @count: how many data units whose length is dlen will be written.
+ *
+ */
+static void hisilpc_comm_outs(void *devobj, unsigned long ptaddr,
+ const void *outbuf, size_t dlen, unsigned int count)
+{
+ struct hisilpc_dev *lpcdev;
+ struct lpc_cycle_para iopara;
+ const unsigned char *newbuf;
+ unsigned int loopcnt, cntleft;
+ unsigned int max_perburst;
+ int ret = 0;
+
+ if (!devobj || !outbuf || !count || !dlen ||
+ dlen > LPC_MAX_DULEN || (dlen & (dlen - 1)))
+ return;
+
+ iopara.opflags = 0;
+ if (dlen > 1)
+ iopara.opflags |= FG_INCRADDR_LPC;
+ iopara.csize = dlen;
+
+ lpcdev = (struct hisilpc_dev *)devobj;
+ newbuf = (unsigned char *)outbuf;
+ /*
+ * ensure data stream whose lenght is multiple of dlen to be processed
+ * each IO input
+ */
+ max_perburst = LPC_MAX_OPCNT & (~(dlen - 1));
+ cntleft = count * dlen;
+ do {
+ loopcnt = (cntleft >= max_perburst) ? max_perburst : cntleft;
+ ret = hisilpc_target_out(lpcdev, &iopara, ptaddr, newbuf,
+ loopcnt);
+ if (ret)
+ break;
+ newbuf += loopcnt;
+ cntleft -= loopcnt;
+ } while (cntleft);
+}
+
+
+/**
+ * hisilpc_probe - the probe callback function for hisi lpc device,
+ * will finish all the intialization.
+ * @pdev: the platform device corresponding to hisi lpc
+ *
+ * Returns 0 on success, non-zero on fail.
+ *
+ */
+static int hisilpc_probe(struct platform_device *pdev)
+{
+ struct resource *iores;
+ struct hisilpc_dev *lpcdev;
+ int ret;
+
+ dev_info(&pdev->dev, "hslpc start probing...\n");
+
+ lpcdev = devm_kzalloc(&pdev->dev,
+ sizeof(struct hisilpc_dev), GFP_KERNEL);
+ if (!lpcdev)
+ return -ENOMEM;
+
+ spin_lock_init(&lpcdev->cycle_lock);
+ iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ lpcdev->membase = devm_ioremap_resource(&pdev->dev, iores);
+ if (IS_ERR(lpcdev->membase)) {
+ dev_err(&pdev->dev, "No mem resource for memory mapping!\n");
+ return PTR_ERR(lpcdev->membase);
+ }
+ /*
+ * The first PCIBIOS_MIN_IO is reserved specific for indirectIO.
+ * It will separate indirectIO range from pci host bridge to
+ * avoid the possible PIO conflict.
+ * Set the indirectIO range directly here.
+ */
+ lpcdev->io_ops.start = 0;
+ lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
+ lpcdev->io_ops.devpara = lpcdev;
+ lpcdev->io_ops.pfin = hisilpc_comm_in;
+ lpcdev->io_ops.pfout = hisilpc_comm_out;
+ lpcdev->io_ops.pfins = hisilpc_comm_ins;
+ lpcdev->io_ops.pfouts = hisilpc_comm_outs;
+
+ platform_set_drvdata(pdev, lpcdev);
+
+ arm64_set_extops(&lpcdev->io_ops);
+
+ /*
+ * The children scanning is only for dts mode. For ACPI children,
+ * the corresponding devices had be created during acpi scanning.
+ */
+ ret = 0;
+ if (!has_acpi_companion(&pdev->dev))
+ ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
+
+ if (!ret)
+ dev_info(&pdev->dev, "hslpc end probing. range[0x%lx - %lx]\n",
+ arm64_extio_ops->start, arm64_extio_ops->end);
+ else
+ dev_info(&pdev->dev, "hslpc probing is fail(%d)\n", ret);
+
+ return ret;
+}
+
+static const struct of_device_id hisilpc_of_match[] = {
+ {
+ .compatible = "hisilicon,low-pin-count",
+ },
+ {},
+};
+
+static const struct acpi_device_id hisilpc_acpi_match[] = {
+ {"HISI0191", },
+ {},
+};
+
+static struct platform_driver hisilpc_driver = {
+ .driver = {
+ .name = "hisi_lpc",
+ .of_match_table = hisilpc_of_match,
+ .acpi_match_table = hisilpc_acpi_match,
+ },
+ .probe = hisilpc_probe,
+};
+
+
+builtin_platform_driver(hisilpc_driver);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 20/23] ARM: shmobile: rcar-gen2: Stop passing mode pins state to clock driver
From: Sergei Shtylyov @ 2016-11-01 13:35 UTC (permalink / raw)
To: Geert Uytterhoeven, Philipp Zabel, Michael Turquette,
Stephen Boyd, Simon Horman, Magnus Damm
Cc: devicetree, linux-renesas-soc, linux-arm-kernel, linux-kernel
In-Reply-To: <1477055857-17936-21-git-send-email-geert+renesas@glider.be>
On 10/21/2016 04:17 PM, Geert Uytterhoeven wrote:
> Now the R-Car Gen2 CPG clock driver obtains the state of the mode pins
> from the R-Car RST driver, there's no longer a need to pass this state
> explicitly. Hence we can just call of_clk_init() instead.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
> ---
> v4:
> - Add Acked-by,
> - Rebase on top of "ARM: shmobile: rcar-gen2: Obtain extal frequency
> from DT",
> - Remove the call to rcar_gen2_read_mode_pins(),
>
> v3:
> - Drop "select MFD_SYSCON", as the clock driver no longer uses syscon,
>
> v2:
> - Kill compiler warning if CONFIG_ARM_ARCH_TIMER is not enabled.
> ---
> arch/arm/mach-shmobile/setup-rcar-gen2.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> index afb9fdcd3d9084e2..b527258e0a62e806 100644
> --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
[...]
> @@ -130,7 +129,7 @@ void __init rcar_gen2_timer_init(void)
> iounmap(base);
> #endif /* CONFIG_ARM_ARCH_TIMER */
>
> - rcar_gen2_clocks_init(mode);
> + of_clk_init(NULL);
> clocksource_probe();
> }
>
This hunk no longer applies to devel.
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/1] ARM: dts: imx6ul-14x14-evk: add USB dual-role support
From: Shawn Guo @ 2016-11-01 13:35 UTC (permalink / raw)
To: Peter Chen
Cc: Peter Chen, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAL411-p_T9DP61kVJ8yTf3v5tduAgTgPaKa1dBCPDo+RhP7igw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Oct 28, 2016 at 05:17:24PM +0800, Peter Chen wrote:
> On Tue, Aug 2, 2016 at 5:08 PM, Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org> wrote:
> > With commit 851ce932242d ("usb: chipidea: otg: don't wait vbus
> > drops below BSV when starts host"), the driver can support
> > enabling vbus output without software control, so this board
> > (control vbus output through ID pin) can support dual-role now.
> >
> > Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
> > ---
> > arch/arm/boot/dts/imx6ul-14x14-evk.dts | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dts b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> > index e281d50..c5cf942 100644
> > --- a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> > +++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
> > @@ -225,7 +225,7 @@
> > };
> >
> > &usbotg1 {
> > - dr_mode = "peripheral";
> > + dr_mode = "otg";
> > status = "okay";
> > };
> >
>
> Ping....
Applied, thanks. Sorry for missing the patch in the first place.
Shawn
--
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 01/14] dma: sun6i-dma: Add burst case of 4
From: Koul, Vinod @ 2016-11-01 13:46 UTC (permalink / raw)
To: wens-jdAy2FN1RRM@public.gmane.org,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org,
moinejf-GANU6spQydw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tiwai-IBi9RG/b67k@public.gmane.org,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
"mylene.josserand-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org" <mylene.josserand>
In-Reply-To: <CAGb2v67SSZF6XL-HXv83nuwTKpJc53h8gsrb2r2V98LNZBzqEA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, 2016-10-30 at 10:06 +0800, Chen-Yu Tsai wrote:
> Looking at the dmaengine API, I believe we got it wrong.
>
> max_burst in dma_slave_config denotes the largest amount of data
> a single transfer should be, as described in dmaengine.h:
Not a single transfer but smallest transaction within a transfer of a
block. So dmaengines transfer data in bursts from source to destination,
this parameter decides the size of that bursts
>
> * @src_maxburst: the maximum number of words (note: words, as in
> * units of the src_addr_width member, not bytes) that can be sent
> * in one burst to the device. Typically something like half the
> * FIFO depth on I/O peripherals so you don't overflow it. This
> * may or may not be applicable on memory sources.
> * @dst_maxburst: same as src_maxburst but for destination target
> * mutatis mutandis.
>
> The DMA engine driver should be free to select whatever burst size
> that doesn't exceed this. So for max_burst = 4, the driver can select
> burst = 4 for controllers that do support it, or burst = 1 for those
> that don't, and do more bursts.
Nope, the client configures these parameters and dmaengine driver
validates and programs
>
> This also means we can increase max_burst for the audio codec, as
> the FIFO is 64 samples deep for stereo, or 128 samples for mono.
Beware that higher bursts means chance of underrun of FIFO. This value
is selected with consideration of power and performance required. Lazy
allocation would be half of FIFO size..
--
~Vinod
--
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
* Re: [PATCH v8 0/3] ARM: dts: imx6q: Add Engicam i.CoreM6 dts
From: Shawn Guo @ 2016-11-01 13:48 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-arm-kernel, devicetree, linux-kernel, Matteo Lisi,
Michael Trimarchi, Jagan Teki
In-Reply-To: <1477037153-20484-1-git-send-email-jteki@openedev.com>
On Fri, Oct 21, 2016 at 01:35:50PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> This is series add dts support for Engicam I.Core M6 qdl modules. just
> rebased on top of linux-next.
>
> Jagan Teki (3):
> ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
> ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
> ARM: dts: imx6qdl-icore: Add FEC support
Applied all, thanks.
^ permalink raw reply
* Re: [PATCH] clk: cdce925: add support for CDCE913, CDCE937, and CDCE949
From: Akinobu Mita @ 2016-11-01 13:52 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-clk, open list:OPEN FIRMWARE AND..., Mike Looijmans,
Michael Turquette
In-Reply-To: <20161031181509.GS16026@codeaurora.org>
2016-11-01 3:15 GMT+09:00 Stephen Boyd <sboyd@codeaurora.org>:
> On 10/31, Akinobu Mita wrote:
>> @@ -582,13 +615,19 @@ static int cdce925_probe(struct i2c_client *client,
>> struct clk_cdce925_chip *data;
>> struct device_node *node = client->dev.of_node;
>> const char *parent_name;
>> - const char *pll_clk_name[NUMBER_OF_PLLS] = {NULL,};
>> + const char *pll_clk_name[MAX_NUMBER_OF_PLLS] = {NULL,};
>> struct clk_init_data init;
>> u32 value;
>> int i;
>> int err;
>> struct device_node *np_output;
>> char child_name[6];
>> + struct regmap_config cdce925_regmap_config = {
>
> Maybe just call this config because it's a local variable now.
Sounds good.
>> + .name = "configuration0",
>> + .reg_bits = 8,
>> + .val_bits = 8,
>> + .cache_type = REGCACHE_RBTREE,
>> + };
>>
>> dev_dbg(&client->dev, "%s\n", __func__);
>> data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
>> @@ -596,6 +635,9 @@ static int cdce925_probe(struct i2c_client *client,
>> return -ENOMEM;
>>
>> data->i2c_client = client;
>> + data->chip_info = &clk_cdce925_chip_info_tbl[id->driver_data];
>> + cdce925_regmap_config.max_register = CDCE925_OFFSET_PLL +
>> + data->chip_info->num_plls * 0x10 - 1;
>> data->regmap = devm_regmap_init(&client->dev, ®map_cdce925_bus,
>> &client->dev, &cdce925_regmap_config);
>> if (IS_ERR(data->regmap)) {
>> @@ -728,13 +780,19 @@ static int cdce925_probe(struct i2c_client *client,
>> }
>>
>> static const struct i2c_device_id cdce925_id[] = {
>> - { "cdce925", 0 },
>> + { "cdce913", CDCE913 },
>> + { "cdce925", CDCE925 },
>> + { "cdce937", CDCE937 },
>> + { "cdce949", CDCE949 },
>> { }
>> };
>> MODULE_DEVICE_TABLE(i2c, cdce925_id);
>>
>> static const struct of_device_id clk_cdce925_of_match[] = {
>> + { .compatible = "ti,cdce913" },
>> { .compatible = "ti,cdce925" },
>> + { .compatible = "ti,cdce937" },
>> + { .compatible = "ti,cdce949" },
>
> Doesn't this need to be updated to point to the correct enum
> values?
I think it isn't needed. Because the data field in struct of_device_id
for this driver is not used even if the device is registered from
device tree. But the driver_data in i2c_device_id is used instead.
^ permalink raw reply
* Re: [PATCH 1/5] ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support
From: Shawn Guo @ 2016-11-01 14:13 UTC (permalink / raw)
To: Gary Bisson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
fabio.estevam-KZfg59tc24xl57MIdRCFDg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-lFZ/pmaqli7XmaaqVzeoHQ
In-Reply-To: <20161025211955.5345-2-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
On Tue, Oct 25, 2016 at 11:19:51PM +0200, Gary Bisson wrote:
> SoM based on i.MX6 Quad with 1GB of DDR3.
>
> https://boundarydevices.com/product/nit6x-som-v2/
>
> Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6q-nitrogen6_som2.dts | 53 ++
> arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 770 ++++++++++++++++++++++++++
> 3 files changed, 824 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6_som2.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
<snip>
> +/ {
> + chosen {
> + stdout-path = &uart2;
> + };
> +
> + memory {
> + reg = <0x10000000 0x40000000>;
> + };
> +
> + backlight_lcd: backlight_lcd {
Please use hyphen instead of underscore in node name. Please check
through the patch series.
Shawn
> + compatible = "pwm-backlight";
> + pwms = <&pwm1 0 5000000>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <7>;
> + power-supply = <®_3p3v>;
> + status = "okay";
> + };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/5] ARM: dts: imx6qdl-sabrelite: add missing USB PHY reset control
From: Shawn Guo @ 2016-11-01 14:17 UTC (permalink / raw)
To: Gary Bisson
Cc: Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Fabio Estevam, Russell King,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Sascha Hauer,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Peter Chen
In-Reply-To: <CAAMH-yu1oC8qaAtVwSxJxKxSmXMzMJkUeu4cUu3OB2yhDV8GBg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Oct 25, 2016 at 11:53:40PM +0200, Gary Bisson wrote:
> Hi Fabio,
>
> On Tue, Oct 25, 2016 at 11:28 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Hi Gary,
> >
> > On Tue, Oct 25, 2016 at 7:19 PM, Gary Bisson
> > <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org> wrote:
> >> Declared as a regulator since the driver doesn't have a reset-gpios
> >> property for this.
> >
> > Peter Chen is working on adding USB reset-gpio property this. Please
> > check his series:
> > https://www.spinics.net/lists/arm-kernel/msg536105.html
>
> Thanks, I wasn't aware of this series. Indeed if this power sequence
> code gets upstream soon I guess we can drop both patches about the USB
> PHY reset.
Let's wait then instead of adding something that will be removed later.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support
From: Gary Bisson @ 2016-11-01 14:54 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Russell King
In-Reply-To: <20161101141338.GC9807@dragon>
Hi Shawn,
On Tue, Nov 1, 2016 at 3:13 PM, Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Oct 25, 2016 at 11:19:51PM +0200, Gary Bisson wrote:
>> SoM based on i.MX6 Quad with 1GB of DDR3.
>>
>> https://boundarydevices.com/product/nit6x-som-v2/
>>
>> Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/imx6q-nitrogen6_som2.dts | 53 ++
>> arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 770 ++++++++++++++++++++++++++
>> 3 files changed, 824 insertions(+)
>> create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6_som2.dts
>> create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
>
> <snip>
>
>> +/ {
>> + chosen {
>> + stdout-path = &uart2;
>> + };
>> +
>> + memory {
>> + reg = <0x10000000 0x40000000>;
>> + };
>> +
>> + backlight_lcd: backlight_lcd {
>
> Please use hyphen instead of underscore in node name. Please check
> through the patch series.
Sorry about that, forgot (again). Just to make sure, the label can
have underscore but not the name right? Or is it better to have hypens
everywhere?
So I guess I need to make a pass on current boards as well. Some
patches in my series rename the panel to panel_lvdsX to match the
current Nitrogen6_MAX naming[1] but this would need to be changed to
panel-lvdsX as well.
Regards,
Gary
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi#n296
--
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 01/14] dma: sun6i-dma: Add burst case of 4
From: Chen-Yu Tsai @ 2016-11-01 14:55 UTC (permalink / raw)
To: Koul, Vinod
Cc: wens-jdAy2FN1RRM@public.gmane.org,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org,
moinejf-GANU6spQydw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tiwai-IBi9RG/b67k@public.gmane.org,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-arm-kernel
In-Reply-To: <1477922460.2837.5.camel-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Tue, Nov 1, 2016 at 9:46 PM, Koul, Vinod <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> On Sun, 2016-10-30 at 10:06 +0800, Chen-Yu Tsai wrote:
>> Looking at the dmaengine API, I believe we got it wrong.
>>
>> max_burst in dma_slave_config denotes the largest amount of data
>> a single transfer should be, as described in dmaengine.h:
>
> Not a single transfer but smallest transaction within a transfer of a
> block. So dmaengines transfer data in bursts from source to destination,
> this parameter decides the size of that bursts
Right.
>
>>
>> * @src_maxburst: the maximum number of words (note: words, as in
>> * units of the src_addr_width member, not bytes) that can be sent
>> * in one burst to the device. Typically something like half the
>> * FIFO depth on I/O peripherals so you don't overflow it. This
>> * may or may not be applicable on memory sources.
>> * @dst_maxburst: same as src_maxburst but for destination target
>> * mutatis mutandis.
>>
>> The DMA engine driver should be free to select whatever burst size
>> that doesn't exceed this. So for max_burst = 4, the driver can select
>> burst = 4 for controllers that do support it, or burst = 1 for those
>> that don't, and do more bursts.
>
> Nope, the client configures these parameters and dmaengine driver
> validates and programs
Shouldn't we just name it "burst_size" then if it's meant to be what
the client specifically asks for?
My understanding is that the client configures its own parameters,
such as the trigger level for the DRQ, like raise DRQ when level < 1/4
FIFO depth, request maxburst = 1/4 or 1/2 FIFO depth, so as not to
overrun the FIFO. When the DRQ is raised, the DMA engine will do a
burst, and after the burst the DRQ would be low again, so the DMA
engine will wait. So the DMA engine driver should be free to
program the actual burst size to something less than maxburst, shouldn't
it?
>>
>> This also means we can increase max_burst for the audio codec, as
>> the FIFO is 64 samples deep for stereo, or 128 samples for mono.
>
> Beware that higher bursts means chance of underrun of FIFO. This value
> is selected with consideration of power and performance required. Lazy
> allocation would be half of FIFO size..
You mean underrun if its the source right? So the client setting maxburst
should take the DRQ trigger level into account for this.
Regards
ChenYu
^ permalink raw reply
* Re: [PATCH/RESEND V4 2/3] ARM64 LPC: Add missing range exception for special ISA
From: kbuild test robot @ 2016-11-01 15:04 UTC (permalink / raw)
Cc: kbuild-all, catalin.marinas, will.deacon, robh+dt, bhelgaas,
mark.rutland, arnd, linux-arm-kernel, lorenzo.pieralisi,
linux-kernel, linuxarm, devicetree, linux-pci, linux-serial,
minyard, benh, liviu.dudau, zourongrong, john.garry,
gabriele.paoloni, zhichang.yuan02, kantyzc, xuwei5, zhichang.yuan
In-Reply-To: <1478006926-240933-3-git-send-email-yuanzhichang@hisilicon.com>
[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]
Hi zhichang.yuan,
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/zhichang-yuan/ARM64-LPC-legacy-ISA-I-O-support/20161101-211425
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: openrisc-or1ksim_defconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All errors (new ones prefixed by >>):
drivers/of/address.c: In function '__of_address_to_resource':
>> drivers/of/address.c:733:40: error: 'PCIBIOS_MIN_IO' undeclared (first use in this function)
drivers/of/address.c:733:40: note: each undeclared identifier is reported only once for each function it appears in
vim +/PCIBIOS_MIN_IO +733 drivers/of/address.c
727 if ((flags & (IORESOURCE_IO | IORESOURCE_MEM)) == 0)
728 return -EINVAL;
729 taddr = of_translate_address(dev, addrp);
730 if (taddr == OF_BAD_ADDR)
731 return -EINVAL;
732 memset(r, 0, sizeof(struct resource));
> 733 if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
734 unsigned long port;
735
736 port = pci_address_to_pio(taddr);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 7206 bytes --]
^ permalink raw reply
* Re: [RFC 1/2] mmc: sdhci: dt: Add device tree properties sdhci-caps and sdhci-caps-mask
From: Zach Brown @ 2016-11-01 15:08 UTC (permalink / raw)
To: Jaehoon Chung
Cc: Adrian Hunter, Ulf Hansson, Rob Herring, Mark Rutland, linux-mmc,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <c254c113-8f21-ca71-da5b-02fb95fed412@samsung.com>
On Tue, Nov 01, 2016 at 07:13:29AM +0900, Jaehoon Chung wrote:
> On 10/31/2016 09:34 PM, Adrian Hunter wrote:
> > On 31/10/16 13:59, Jaehoon Chung wrote:
> >> On 10/28/2016 05:12 PM, Ulf Hansson wrote:
> >>> On 25 October 2016 at 21:58, Zach Brown <zach.brown@ni.com> wrote:
> >>>> On some systems the sdhci capabilty registers are incorrect for one
> >>>> reason or another.
> >>>>
> >>>> The sdhci-caps-mask property specifies which bits in the registers
> >>>> are incorrect and should be turned off before using sdhci-caps to turn
> >>>> on bits.
> >>>>
> >>>> The sdhci-caps property specifies which bits should be turned on.
> >>>>
> >>>> Signed-off-by: Zach Brown <zach.brown@ni.com>
> >>>> ---
> >>>> Documentation/devicetree/bindings/mmc/mmc.txt | 7 +++++++
> >>>> 1 file changed, 7 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
> >>>> index 8a37782..1415aa0 100644
> >>>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> >>>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> >>>
> >>> The bindings in this document are common mmc DT bindings, not bindings
> >>> specific to a mmc controller.
> >>>
> >>> So unless these bindings are applicable for another controller than
> >>> sdhci, I suggest we create a new file to document these.
> >>> How about Documentation/devicetree/bindings/mmc/sdhci.txt?
> >>>
> >>>> @@ -52,6 +52,13 @@ Optional properties:
> >>>> - no-sdio: controller is limited to send sdio cmd during initialization
> >>>> - no-sd: controller is limited to send sd cmd during initialization
> >>>> - no-mmc: controller is limited to send mmc cmd during initialization
> >>>> +- sdhci-caps-mask: The sdhci capabilities registers are incorrect. This 64bit
> >>>
> >>> /s/registers/register
> >>>
> >>> This applies to some more places below as well.
> >>>
> >>>> + property corresponds to the bits in the sdhci capabilty registers. If the bit
> >>>> + is on in the mask then the bit is incorrect in the registers and should be
> >>>> + turned off.
> >>>> +- sdhci-caps: The sdhci capabilities registers are incorrect. This 64bit
> >>>> + property corresponds to the bits in the sdhci capability registers. If the
> >>>> + bit is on in the property then the bit should be on in the reigsters.
> >>>
> >>> /s/reigsters/register
> >>>
> >>>>
> >>>> *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
> >>>> polarity properties, we have to fix the meaning of the "normal" and "inverted"
> >>>> --
> >>>> 2.7.4
> >>>>
> >>>
> >>> Overall, I like this idea as it gives us good flexibility. Thus it
> >>> should avoid us to having to add any further new similar "sdhci broken
> >>> cap" DT binding. We could also decide to start deprecate some of the
> >>> existing sdhci bindings, if we think that makes sense.
> >>>
> >>> The downside is that we get a "magic" hex value in the dts. Although,
> >>> people could address this issue by providing some comments about what
> >>> the bits it means in the dts files themselves.
> >>
> >> I think it's not good about getting "magic" hex value.
> >> In my experience, it's too difficult what bits means and calculate..
> >> Because some people who i know had already used like this.(locally..)
> >>
> >> It needs to consider this...otherwise..it should become really complex magic code.
> >
> > The bits we use are listed in sdhci.h and how we use them can be determined
> > from the sdhci source code. Also, from the hardware perspective, there is
> > the SDHCI specification. So what the bits mean is readily available.
> >
> > With regard to calculating the values, won't it be obvious from testing if
> > they are wrong?
>
> You're right. But I didn't see the real use case for this properties.
> If it needs to add these properties, why didn't add codes relevant to these in device-tree?
> Otherwise, this code should be dead code.
>
The issue here is the sdhci has a register that is supposed report the
capabilities of the device, but it can be wrong. It might turn on a mode or
behavior that should not be on.
For example, in our use case the sdhci itself is capable of highspeed so it
naturally has the highspeed capable bit set in it's capabilities register.
However due to board setup, the entire system is not actually capable of
highspeed. So we need a way to say the sdhci capabilities register's highspeed
bit is incorrect.
A simple "no-sdhci-highspeed" device tree property might suffice, but there are
roughly ~64 sdhci capabilities represented in the capabilities register.
Instead of creating ~64 device-tree properties to handle each individually this
patch set creates just two that handle them all. In a way that is flexible
enough to correct all ~64 or just 1 or any subset depending on the use case.
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add Macnica Americas vendor prefix
From: Dinh Nguyen @ 2016-11-01 15:36 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dinh Nguyen
Add a vendor prefix for the Macnica company.
http://http://www.macnica.com
Signed-off-by: Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea..81674f2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -158,6 +158,7 @@ lg LG Corporation
linux Linux-specific binding
lltc Linear Technology Corporation
lsi LSI Corp. (LSI Logic)
+macnica Macnica Americas
marvell Marvell Technology Group Ltd.
maxim Maxim Integrated Products
meas Measurement Specialties
--
2.8.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: Add vendor prefix for Terasic Inc.
From: Dinh Nguyen @ 2016-11-01 15:36 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dinh Nguyen
In-Reply-To: <20161101153632.6844-1-dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add a vendor prefix for Terasic.
http://www.terasic.com
Signed-off-by: Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 81674f2..948d3ac 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -276,6 +276,7 @@ tcg Trusted Computing Group
tcl Toby Churchill Ltd.
technexion TechNexion
technologic Technologic Systems
+terasic Terasic Inc.
thine THine Electronics, Inc.
ti Texas Instruments
tlm Trusted Logic Mobility
--
2.8.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: Add vendor prefix for Samtec
From: Dinh Nguyen @ 2016-11-01 15:36 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dinh Nguyen
In-Reply-To: <20161101153632.6844-1-dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add a vendor prefix for Samtec, a Softing company.
http://www.samtec.de
http://www.samtec.org
Signed-off-by: Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 948d3ac..bff8f53 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -232,6 +232,7 @@ richtek Richtek Technology Corporation
ricoh Ricoh Co. Ltd.
rockchip Fuzhou Rockchip Electronics Co., Ltd
samsung Samsung Semiconductor
+samtec Samtec/Softing company
sandisk Sandisk Corporation
sbs Smart Battery System
schindler Schindler
--
2.8.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ARM: dts: socfpga: add specific compatible strings for boards
From: Dinh Nguyen @ 2016-11-01 15:38 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
olof-nZhT3qVonbNeoWH0uzbU5w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dinh Nguyen
Add a more specific board compatible entry for all of the SOCFPGA
Cyclone 5 based boards.
Signed-off-by: Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
index afea364..5ecd2ef 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
@@ -18,7 +18,7 @@
/ {
model = "Terasic DE-0(Atlas)";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "terasic,de0-atlas", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
index 424523b..668d77c 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_mcvevk.dts
@@ -19,7 +19,7 @@
/ {
model = "Aries/DENX MCV EVK";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "denx, mcvevk", "altr,socfpga-cyclone5", "altr,socfpga";
aliases {
ethernet0 = &gmac0;
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
index 15e43f4..b0577c1 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
@@ -19,7 +19,7 @@
/ {
model = "Altera SOCFPGA Cyclone V SoC Development Kit";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "altr,socdk", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 02e22f5..c5623a7 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -19,7 +19,7 @@
/ {
model = "Terasic SoCkit";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "terasic,sockit", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
index 9aaf413..992ae49 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
@@ -21,7 +21,7 @@
/ {
model = "Altera SOCFPGA Cyclone V SoC Macnica Sodia board";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "macnica, sodia", "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "earlyprintk";
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
index b844473..78b187e 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
@@ -51,7 +51,7 @@
/ {
model = "samtec VIN|ING FPGA";
- compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+ compatible = "samtec,vining". "altr,socfpga-cyclone5", "altr,socfpga";
chosen {
bootargs = "console=ttyS0,115200";
--
2.8.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH/RESEND V4 2/3] ARM64 LPC: Add missing range exception for special ISA
From: kbuild test robot @ 2016-11-01 15:40 UTC (permalink / raw)
Cc: kbuild-all, catalin.marinas, will.deacon, robh+dt, bhelgaas,
mark.rutland, arnd, linux-arm-kernel, lorenzo.pieralisi,
linux-kernel, linuxarm, devicetree, linux-pci, linux-serial,
minyard, benh, liviu.dudau, zourongrong, john.garry,
gabriele.paoloni, zhichang.yuan02, kantyzc, xuwei5, zhichang.yuan
In-Reply-To: <1478006926-240933-3-git-send-email-yuanzhichang@hisilicon.com>
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
Hi zhichang.yuan,
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/zhichang-yuan/ARM64-LPC-legacy-ISA-I-O-support/20161101-211425
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: arm-efm32_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `__of_address_to_resource':
>> drivers/of/address.c:748: undefined reference to `pcibios_min_io'
vim +748 drivers/of/address.c
1f5bef30 Grant Likely 2010-06-08 742 r->start = taddr;
1f5bef30 Grant Likely 2010-06-08 743 r->end = taddr + size - 1;
1f5bef30 Grant Likely 2010-06-08 744 }
1f5bef30 Grant Likely 2010-06-08 745 r->flags = flags;
35f3da32 Benoit Cousson 2011-12-05 746 r->name = name ? name : dev->full_name;
35f3da32 Benoit Cousson 2011-12-05 747
1f5bef30 Grant Likely 2010-06-08 @748 return 0;
1f5bef30 Grant Likely 2010-06-08 749 }
1f5bef30 Grant Likely 2010-06-08 750
1f5bef30 Grant Likely 2010-06-08 751 /**
:::::: The code at line 748 was first introduced by commit
:::::: 1f5bef30cf6c66f097ea5dfc580a41924df888d1 of/address: merge of_address_to_resource()
:::::: TO: Grant Likely <grant.likely@secretlab.ca>
:::::: CC: Grant Likely <grant.likely@secretlab.ca>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 10888 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Jon Mason @ 2016-11-01 15:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland, devicetree, Florian Fainelli, netdev, linux-kernel,
Rob Herring, bcm-kernel-feedback-list, rafal, David Miller,
linux-arm-kernel
In-Reply-To: <20161029081839.GA32579@lunn.ch>
On Sat, Oct 29, 2016 at 10:18:39AM +0200, Andrew Lunn wrote:
> On Fri, Oct 28, 2016 at 04:56:55PM -0400, Jon Mason wrote:
> > The BCM54810 PHY requires some semi-unique configuration, which results
> > in some additional configuration in addition to the standard config.
> > Also, some users of the BCM54810 require the PHY lanes to be swapped.
> > Since there is no way to detect this, add a device tree query to see if
> > it is applicable.
> >
> > Inspired-by: Vikas Soni <vsoni@broadcom.com>
> > Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> > ---
> > drivers/net/phy/Kconfig | 2 +-
> > drivers/net/phy/broadcom.c | 58 +++++++++++++++++++++++++++++++++++++++++++++-
> > include/linux/brcmphy.h | 10 ++++++++
>
> Hi Jon
>
> The binding documentation is missing.
>
> > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> > + /* Lane Swap - Undocumented register...magic! */
> > + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> > + 0x11B);
> > + if (ret < 0)
> > + return ret;
> > + }
> > +
>
> I wounder if this property could be made generic? What exactly are you
> swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
Are you envisioning adding a DT check (similar to the
of_property_read_bool above, only with a more generic string) in
phy_device_create(), which will then set a PHY device flag? This flag
would then be checked for in the PHY driver and the appropriate action
taken (in this case the bcm_phy_write_exp above).
If so, I cam completely fine doing this. I think the only caveat
would be that this would be creating a generic interface for only 1
user. If you envision this being used by others, then disregard my
concern.
Thanks,
Jon
>
> Andrew
^ permalink raw reply
* Re: [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-11-01 16:26 UTC (permalink / raw)
To: Jon Mason
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree, netdev, linux-kernel, bcm-kernel-feedback-list, rafal,
linux-arm-kernel
In-Reply-To: <20161101155950.GA19378@broadcom.com>
> > > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> > > + /* Lane Swap - Undocumented register...magic! */
> > > + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> > > + 0x11B);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > > +
> >
> > I wounder if this property could be made generic? What exactly are you
> > swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
>
> Are you envisioning adding a DT check (similar to the
> of_property_read_bool above, only with a more generic string) in
> phy_device_create(), which will then set a PHY device flag? This flag
> would then be checked for in the PHY driver and the appropriate action
> taken (in this case the bcm_phy_write_exp above).
I would keep the parsing of the property in the driver. But if we
think other PHYs could also support this feature, it would be good to
avoid having "brcm,enet-phy-lane-swap", "marvell,enet-phy-lane-swap",
"davicom,enet-phy-lane-swap", etc. It would be better to have one well
defined property documented in phy.txt which any PHY is free to
implement.
Andrew
^ permalink raw reply
* [PATCH v2 0/2] mmc: sdhci-iproc: Add byte register access support
From: Scott Branden @ 2016-11-01 16:37 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Mark Rutland, Ray Jui, Scott Branden,
Adrian Hunter
Cc: BCM Kernel Feedback, linux-mmc, devicetree, linux-arm-kernel,
linux-kernel, Scott Branden
Add brcm,sdhci-iproc compat string and code for support of newer versions of
sdhci-iproc controller that allow byte-wise register accesses.
Changes from v1:
- added details to bindings documentation to clarify usage of brcm,sdhci-iproc
compatibility string
Scott Branden (2):
mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings
document
mmc: sdhci-iproc: support standard byte register accesses
.../devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 ++++++
drivers/mmc/host/sdhci-iproc.c | 35 ++++++++++++++++++++--
2 files changed, 42 insertions(+), 2 deletions(-)
--
2.5.0
^ permalink raw reply
* [PATCH v2 1/2] mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings document
From: Scott Branden @ 2016-11-01 16:37 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Mark Rutland, Ray Jui, Scott Branden,
Adrian Hunter
Cc: BCM Kernel Feedback, linux-mmc, devicetree, linux-arm-kernel,
linux-kernel, Scott Branden, Anup Patel
In-Reply-To: <1478018277-10097-1-git-send-email-scott.branden@broadcom.com>
Adds brcm,sdhci-iproc compat string to DT bindings document for
the iProc SDHCI driver.
Signed-off-by: Anup Patel <anup.patel@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
index be56d2b..954561d 100644
--- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
+++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
@@ -7,6 +7,15 @@ Required properties:
- compatible : Should be one of the following
"brcm,bcm2835-sdhci"
"brcm,sdhci-iproc-cygnus"
+ "brcm,sdhci-iproc"
+
+Use brcm2835-sdhci for Rasperry PI.
+
+Use sdhci-iproc-cygnus for Broadcom SDHCI Controllers
+restricted to 32bit host accesses to SDHCI registers.
+
+Use sdhci-iproc for Broadcom SDHCI Controllers that allow standard
+8, 16, 32-bit host access to SDHCI register.
- clocks : The clock feeding the SDHCI controller.
--
2.5.0
^ permalink raw reply related
* [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Scott Branden @ 2016-11-01 16:37 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Mark Rutland, Ray Jui, Scott Branden,
Adrian Hunter
Cc: devicetree, Scott Branden, linux-mmc, linux-kernel,
BCM Kernel Feedback, Srinath Mannam, linux-arm-kernel
In-Reply-To: <1478018277-10097-1-git-send-email-scott.branden@broadcom.com>
Add bytewise register accesses support for newer versions of IPROC
SDHCI controllers.
Previous sdhci-iproc versions of SDIO controllers
(such as Raspberry Pi and Cygnus) only allowed for 32-bit register
accesses.
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
drivers/mmc/host/sdhci-iproc.c | 35 +++++++++++++++++++++++++++++++++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index 7262466..d7046d6 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -143,6 +143,14 @@ static void sdhci_iproc_writeb(struct sdhci_host *host, u8 val, int reg)
}
static const struct sdhci_ops sdhci_iproc_ops = {
+ .set_clock = sdhci_set_clock,
+ .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+ .set_bus_width = sdhci_set_bus_width,
+ .reset = sdhci_reset,
+ .set_uhs_signaling = sdhci_set_uhs_signaling,
+};
+
+static const struct sdhci_ops sdhci_iproc_32only_ops = {
.read_l = sdhci_iproc_readl,
.read_w = sdhci_iproc_readw,
.read_b = sdhci_iproc_readb,
@@ -156,6 +164,28 @@ static const struct sdhci_ops sdhci_iproc_ops = {
.set_uhs_signaling = sdhci_set_uhs_signaling,
};
+static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
+ .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
+ .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
+ .ops = &sdhci_iproc_32only_ops,
+};
+
+static const struct sdhci_iproc_data iproc_cygnus_data = {
+ .pdata = &sdhci_iproc_cygnus_pltfm_data,
+ .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
+ & SDHCI_MAX_BLOCK_MASK) |
+ SDHCI_CAN_VDD_330 |
+ SDHCI_CAN_VDD_180 |
+ SDHCI_CAN_DO_SUSPEND |
+ SDHCI_CAN_DO_HISPD |
+ SDHCI_CAN_DO_ADMA2 |
+ SDHCI_CAN_DO_SDMA,
+ .caps1 = SDHCI_DRIVER_TYPE_C |
+ SDHCI_DRIVER_TYPE_D |
+ SDHCI_SUPPORT_DDR50,
+ .mmc_caps = MMC_CAP_1_8V_DDR,
+};
+
static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
.quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
.quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
@@ -182,7 +212,7 @@ static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
.quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
SDHCI_QUIRK_MISSING_CAPS,
- .ops = &sdhci_iproc_ops,
+ .ops = &sdhci_iproc_32only_ops,
};
static const struct sdhci_iproc_data bcm2835_data = {
@@ -194,7 +224,8 @@ static const struct sdhci_iproc_data bcm2835_data = {
static const struct of_device_id sdhci_iproc_of_match[] = {
{ .compatible = "brcm,bcm2835-sdhci", .data = &bcm2835_data },
- { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_data },
+ { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_cygnus_data},
+ { .compatible = "brcm,sdhci-iproc", .data = &iproc_data },
{ }
};
MODULE_DEVICE_TABLE(of, sdhci_iproc_of_match);
--
2.5.0
^ permalink raw reply related
* Re: [PATCH 1/2] mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings document
From: Scott Branden @ 2016-11-01 16:40 UTC (permalink / raw)
To: Rob Herring
Cc: Ulf Hansson, Mark Rutland, Ray Jui, Scott Branden, Adrian Hunter,
BCM Kernel Feedback, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Anup Patel
In-Reply-To: <93502f42-ae86-742f-a8b1-3645005fa98e-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Hi Rob,
On 16-10-18 01:08 PM, Scott Branden wrote:
> Hi Rob,
>
> On 16-10-18 06:16 AM, Rob Herring wrote:
>> On Wed, Oct 12, 2016 at 11:35:51AM -0700, Scott Branden wrote:
>>> Adds brcm,sdhci-iproc compat string to DT bindings document for
>>> the iProc SDHCI driver.
>>>
>>> Signed-off-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>> Signed-off-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>>> ---
>>> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
>>> b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
>>> index be56d2b..aa58b94 100644
>>> --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
>>> @@ -7,6 +7,7 @@ Required properties:
>>> - compatible : Should be one of the following
>>> "brcm,bcm2835-sdhci"
>>> "brcm,sdhci-iproc-cygnus"
>>> + "brcm,sdhci-iproc"
>>
>> Seems kind of generic. SoC specific compatible strings please.
>>
> The compatibility string is generic on purpose as it is not intended to
> be SoC specific but work on all new iproc SoCs that have the proper
> fixes in place for this block (unlike bcm2835 and cygnus class devices
> which can only do 32-bit accesses). I could call it brcm,sdhci-iproc-v2
> if that is better or leave it as is. Please let me know your preferences.
>
I just sent out v2 of the patch with additional details in the device
tree bindings document. Please let me know if this covers your
concerns. The SDHCI controller binding is not SoC specific and is used
in multiple SoCs going forward with the same binding.
> Regards,
> Scott
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Jon Mason @ 2016-11-01 16:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree, netdev, linux-kernel, bcm-kernel-feedback-list, rafal,
linux-arm-kernel
In-Reply-To: <20161101162648.GG10785@lunn.ch>
On Tue, Nov 01, 2016 at 05:26:48PM +0100, Andrew Lunn wrote:
> > > > + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap")) {
> > > > + /* Lane Swap - Undocumented register...magic! */
> > > > + ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
> > > > + 0x11B);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > + }
> > > > +
> > >
> > > I wounder if this property could be made generic? What exactly are you
> > > swapping? Rx and Tx lanes? Maybe we should add it to phy.txt?
> >
> > Are you envisioning adding a DT check (similar to the
> > of_property_read_bool above, only with a more generic string) in
> > phy_device_create(), which will then set a PHY device flag? This flag
> > would then be checked for in the PHY driver and the appropriate action
> > taken (in this case the bcm_phy_write_exp above).
>
> I would keep the parsing of the property in the driver. But if we
> think other PHYs could also support this feature, it would be good to
> avoid having "brcm,enet-phy-lane-swap", "marvell,enet-phy-lane-swap",
> "davicom,enet-phy-lane-swap", etc. It would be better to have one well
> defined property documented in phy.txt which any PHY is free to
> implement.
Okay, I understand what you are saying now. I will assume that if
nothing exists today aside from this Broadcom errata, something in the
future will happen. So, I agree that making it generic is a good idea.
I'll make the generic string be "enet-phy-lane-swap" (without the
previous "brcm"), and add the flag to phy.txt to document it.
Thanks,
Jon
>
> Andrew
^ permalink raw reply
* Re: [PATCH v2 2/6] net: phy: broadcom: Add BCM54810 PHY entry
From: Andrew Lunn @ 2016-11-01 16:48 UTC (permalink / raw)
To: Jon Mason
Cc: David Miller, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
rafal-g1n6cQUeyibVItvQsEIGlw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161101164337.GA19654-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> I'll make the generic string be "enet-phy-lane-swap" (without the
> previous "brcm"), and add the flag to phy.txt to document it.
Great.
Please be quite verbose as to what it means.
Thanks
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox