* [PATCH v6 01/23] PCI: endpoint: Add EP core layer to enable EP controller and EP functions
From: Kishon Vijay Abraham I @ 2017-04-05 8:52 UTC (permalink / raw)
To: Bjorn Helgaas, Joao Pinto, linux-pci, linux-doc, linux-kernel,
devicetree, linux-omap, linux-arm-kernel
Cc: hch, nsekhar, kishon
In-Reply-To: <20170405085243.18123-1-kishon@ti.com>
Introduce a new EP core layer in order to support endpoint functions in
linux kernel. This comprises the EPC library (Endpoint Controller Library)
and EPF library (Endpoint Function Library). EPC library implements
functions specific to an endpoint controller and EPF library implements
functions specific to an endpoint function.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-By: Joao Pinto <jpinto@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/Makefile | 2 +
drivers/pci/Kconfig | 1 +
drivers/pci/endpoint/Kconfig | 20 ++
drivers/pci/endpoint/Makefile | 6 +
drivers/pci/endpoint/pci-epc-core.c | 575 ++++++++++++++++++++++++++++++++++++
drivers/pci/endpoint/pci-epc-mem.c | 143 +++++++++
drivers/pci/endpoint/pci-epf-core.c | 347 ++++++++++++++++++++++
include/linux/mod_devicetable.h | 10 +
include/linux/pci-epc.h | 142 +++++++++
include/linux/pci-epf.h | 160 ++++++++++
10 files changed, 1406 insertions(+)
create mode 100644 drivers/pci/endpoint/Kconfig
create mode 100644 drivers/pci/endpoint/Makefile
create mode 100644 drivers/pci/endpoint/pci-epc-core.c
create mode 100644 drivers/pci/endpoint/pci-epc-mem.c
create mode 100644 drivers/pci/endpoint/pci-epf-core.c
create mode 100644 include/linux/pci-epc.h
create mode 100644 include/linux/pci-epf.h
diff --git a/drivers/Makefile b/drivers/Makefile
index 2eced9afba53..a5f8e43b2c4d 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -14,7 +14,9 @@ obj-$(CONFIG_GENERIC_PHY) += phy/
obj-$(CONFIG_PINCTRL) += pinctrl/
obj-$(CONFIG_GPIOLIB) += gpio/
obj-y += pwm/
+
obj-$(CONFIG_PCI) += pci/
+obj-$(CONFIG_PCI_ENDPOINT) += pci/endpoint/
# PCI dwc controller drivers
obj-y += pci/dwc/
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index df141420c902..9747c1ec8c74 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -134,3 +134,4 @@ config PCI_HYPERV
source "drivers/pci/hotplug/Kconfig"
source "drivers/pci/dwc/Kconfig"
source "drivers/pci/host/Kconfig"
+source "drivers/pci/endpoint/Kconfig"
diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
new file mode 100644
index 000000000000..a5442ace7077
--- /dev/null
+++ b/drivers/pci/endpoint/Kconfig
@@ -0,0 +1,20 @@
+#
+# PCI Endpoint Support
+#
+
+menu "PCI Endpoint"
+
+config PCI_ENDPOINT
+ bool "PCI Endpoint Support"
+ help
+ Enable this configuration option to support configurable PCI
+ endpoint. This should be enabled if the platform has a PCI
+ controller that can operate in endpoint mode.
+
+ Enabling this option will build the endpoint library, which
+ includes endpoint controller library and endpoint function
+ library.
+
+ If in doubt, say "N" to disable Endpoint support.
+
+endmenu
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
new file mode 100644
index 000000000000..dc1bc16491e6
--- /dev/null
+++ b/drivers/pci/endpoint/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for PCI Endpoint Support
+#
+
+obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
+ pci-epc-mem.o
diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
new file mode 100644
index 000000000000..54b366ece844
--- /dev/null
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -0,0 +1,575 @@
+/**
+ * PCI Endpoint *Controller* (EPC) library
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I <kishon@ti.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 of
+ * the License 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/device.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+
+#include <linux/pci-epc.h>
+#include <linux/pci-epf.h>
+
+static struct class *pci_epc_class;
+
+static void devm_pci_epc_release(struct device *dev, void *res)
+{
+ struct pci_epc *epc = *(struct pci_epc **)res;
+
+ pci_epc_destroy(epc);
+}
+
+static int devm_pci_epc_match(struct device *dev, void *res, void *match_data)
+{
+ struct pci_epc **epc = res;
+
+ return *epc == match_data;
+}
+
+/**
+ * pci_epc_put() - release the PCI endpoint controller
+ * @epc: epc returned by pci_epc_get()
+ *
+ * release the refcount the caller obtained by invoking pci_epc_get()
+ */
+void pci_epc_put(struct pci_epc *epc)
+{
+ if (!epc || IS_ERR(epc))
+ return;
+
+ module_put(epc->ops->owner);
+ put_device(&epc->dev);
+}
+EXPORT_SYMBOL_GPL(pci_epc_put);
+
+/**
+ * pci_epc_get() - get the PCI endpoint controller
+ * @epc_name: device name of the endpoint controller
+ *
+ * Invoke to get struct pci_epc * corresponding to the device name of the
+ * endpoint controller
+ */
+struct pci_epc *pci_epc_get(const char *epc_name)
+{
+ int ret = -EINVAL;
+ struct pci_epc *epc;
+ struct device *dev;
+ struct class_dev_iter iter;
+
+ class_dev_iter_init(&iter, pci_epc_class, NULL, NULL);
+ while ((dev = class_dev_iter_next(&iter))) {
+ if (strcmp(epc_name, dev_name(dev)))
+ continue;
+
+ epc = to_pci_epc(dev);
+ if (!try_module_get(epc->ops->owner)) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ get_device(&epc->dev);
+ return epc;
+ }
+
+err:
+ class_dev_iter_exit(&iter);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(pci_epc_get);
+
+/**
+ * pci_epc_stop() - stop the PCI link
+ * @epc: the link of the EPC device that has to be stopped
+ *
+ * Invoke to stop the PCI link
+ */
+void pci_epc_stop(struct pci_epc *epc)
+{
+ unsigned long flags;
+
+ if (IS_ERR(epc) || !epc->ops->stop)
+ return;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ epc->ops->stop(epc);
+ spin_unlock_irqrestore(&epc->lock, flags);
+}
+EXPORT_SYMBOL_GPL(pci_epc_stop);
+
+/**
+ * pci_epc_start() - start the PCI link
+ * @epc: the link of *this* EPC device has to be started
+ *
+ * Invoke to start the PCI link
+ */
+int pci_epc_start(struct pci_epc *epc)
+{
+ int ret;
+ unsigned long flags;
+
+ if (IS_ERR(epc))
+ return -EINVAL;
+
+ if (!epc->ops->start)
+ return 0;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ ret = epc->ops->start(epc);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_start);
+
+/**
+ * pci_epc_raise_irq() - interrupt the host system
+ * @epc: the EPC device which has to interrupt the host
+ * @type: specify the type of interrupt; legacy or MSI
+ * @interrupt_num: the MSI interrupt number
+ *
+ * Invoke to raise an MSI or legacy interrupt
+ */
+int pci_epc_raise_irq(struct pci_epc *epc, enum pci_epc_irq_type type,
+ u8 interrupt_num)
+{
+ int ret;
+ unsigned long flags;
+
+ if (IS_ERR(epc))
+ return -EINVAL;
+
+ if (!epc->ops->raise_irq)
+ return 0;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ ret = epc->ops->raise_irq(epc, type, interrupt_num);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_raise_irq);
+
+/**
+ * pci_epc_get_msi() - get the number of MSI interrupt numbers allocated
+ * @epc: the EPC device to which MSI interrupts was requested
+ *
+ * Invoke to get the number of MSI interrupts allocated by the RC
+ */
+int pci_epc_get_msi(struct pci_epc *epc)
+{
+ int interrupt;
+ unsigned long flags;
+
+ if (IS_ERR(epc))
+ return 0;
+
+ if (!epc->ops->get_msi)
+ return 0;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ interrupt = epc->ops->get_msi(epc);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ if (interrupt < 0)
+ return 0;
+
+ interrupt = 1 << interrupt;
+
+ return interrupt;
+}
+EXPORT_SYMBOL_GPL(pci_epc_get_msi);
+
+/**
+ * pci_epc_set_msi() - set the number of MSI interrupt numbers required
+ * @epc: the EPC device on which MSI has to be configured
+ * @interrupts: number of MSI interrupts required by the EPF
+ *
+ * Invoke to set the required number of MSI interrupts.
+ */
+int pci_epc_set_msi(struct pci_epc *epc, u8 interrupts)
+{
+ int ret;
+ u8 encode_int;
+ unsigned long flags;
+
+ if (IS_ERR(epc))
+ return -EINVAL;
+
+ if (!epc->ops->set_msi)
+ return 0;
+
+ encode_int = order_base_2(interrupts);
+
+ spin_lock_irqsave(&epc->lock, flags);
+ ret = epc->ops->set_msi(epc, encode_int);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_set_msi);
+
+/**
+ * pci_epc_unmap_addr() - unmap CPU address from PCI address
+ * @epc: the EPC device on which address is allocated
+ * @phys_addr: physical address of the local system
+ *
+ * Invoke to unmap the CPU address from PCI address.
+ */
+void pci_epc_unmap_addr(struct pci_epc *epc, phys_addr_t phys_addr)
+{
+ unsigned long flags;
+
+ if (IS_ERR(epc))
+ return;
+
+ if (!epc->ops->unmap_addr)
+ return;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ epc->ops->unmap_addr(epc, phys_addr);
+ spin_unlock_irqrestore(&epc->lock, flags);
+}
+EXPORT_SYMBOL_GPL(pci_epc_unmap_addr);
+
+/**
+ * pci_epc_map_addr() - map CPU address to PCI address
+ * @epc: the EPC device on which address is allocated
+ * @phys_addr: physical address of the local system
+ * @pci_addr: PCI address to which the physical address should be mapped
+ * @size: the size of the allocation
+ *
+ * Invoke to map CPU address with PCI address.
+ */
+int pci_epc_map_addr(struct pci_epc *epc, phys_addr_t phys_addr,
+ u64 pci_addr, size_t size)
+{
+ int ret;
+ unsigned long flags;
+
+ if (IS_ERR(epc))
+ return -EINVAL;
+
+ if (!epc->ops->map_addr)
+ return 0;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ ret = epc->ops->map_addr(epc, phys_addr, pci_addr, size);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_map_addr);
+
+/**
+ * pci_epc_clear_bar() - reset the BAR
+ * @epc: the EPC device for which the BAR has to be cleared
+ * @bar: the BAR number that has to be reset
+ *
+ * Invoke to reset the BAR of the endpoint device.
+ */
+void pci_epc_clear_bar(struct pci_epc *epc, int bar)
+{
+ unsigned long flags;
+
+ if (IS_ERR(epc))
+ return;
+
+ if (!epc->ops->clear_bar)
+ return;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ epc->ops->clear_bar(epc, bar);
+ spin_unlock_irqrestore(&epc->lock, flags);
+}
+EXPORT_SYMBOL_GPL(pci_epc_clear_bar);
+
+/**
+ * pci_epc_set_bar() - configure BAR in order for host to assign PCI addr space
+ * @epc: the EPC device on which BAR has to be configured
+ * @bar: the BAR number that has to be configured
+ * @size: the size of the addr space
+ * @flags: specify memory allocation/io allocation/32bit address/64 bit address
+ *
+ * Invoke to configure the BAR of the endpoint device.
+ */
+int pci_epc_set_bar(struct pci_epc *epc, enum pci_barno bar,
+ dma_addr_t bar_phys, size_t size, int flags)
+{
+ int ret;
+ unsigned long irq_flags;
+
+ if (IS_ERR(epc))
+ return -EINVAL;
+
+ if (!epc->ops->set_bar)
+ return 0;
+
+ spin_lock_irqsave(&epc->lock, irq_flags);
+ ret = epc->ops->set_bar(epc, bar, bar_phys, size, flags);
+ spin_unlock_irqrestore(&epc->lock, irq_flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_set_bar);
+
+/**
+ * pci_epc_write_header() - write standard configuration header
+ * @epc: the EPC device to which the configuration header should be written
+ * @header: standard configuration header fields
+ *
+ * Invoke to write the configuration header to the endpoint controller. Every
+ * endpoint controller will have a dedicated location to which the standard
+ * configuration header would be written. The callback function should write
+ * the header fields to this dedicated location.
+ */
+int pci_epc_write_header(struct pci_epc *epc, struct pci_epf_header *header)
+{
+ int ret;
+ unsigned long flags;
+
+ if (IS_ERR(epc))
+ return -EINVAL;
+
+ if (!epc->ops->write_header)
+ return 0;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ ret = epc->ops->write_header(epc, header);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_write_header);
+
+/**
+ * pci_epc_add_epf() - bind PCI endpoint function to an endpoint controller
+ * @epc: the EPC device to which the endpoint function should be added
+ * @epf: the endpoint function to be added
+ *
+ * A PCI endpoint device can have one or more functions. In the case of PCIe,
+ * the specification allows up to 8 PCIe endpoint functions. Invoke
+ * pci_epc_add_epf() to add a PCI endpoint function to an endpoint controller.
+ */
+int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf)
+{
+ unsigned long flags;
+
+ if (epf->epc)
+ return -EBUSY;
+
+ if (IS_ERR(epc))
+ return -EINVAL;
+
+ if (epf->func_no > epc->max_functions - 1)
+ return -EINVAL;
+
+ epf->epc = epc;
+ dma_set_coherent_mask(&epf->dev, epc->dev.coherent_dma_mask);
+ epf->dev.dma_mask = epc->dev.dma_mask;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ list_add_tail(&epf->list, &epc->pci_epf);
+ spin_unlock_irqrestore(&epc->lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pci_epc_add_epf);
+
+/**
+ * pci_epc_remove_epf() - remove PCI endpoint function from endpoint controller
+ * @epc: the EPC device from which the endpoint function should be removed
+ * @epf: the endpoint function to be removed
+ *
+ * Invoke to remove PCI endpoint function from the endpoint controller.
+ */
+void pci_epc_remove_epf(struct pci_epc *epc, struct pci_epf *epf)
+{
+ unsigned long flags;
+
+ if (!epc || IS_ERR(epc))
+ return;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ list_del(&epf->list);
+ spin_unlock_irqrestore(&epc->lock, flags);
+}
+EXPORT_SYMBOL_GPL(pci_epc_remove_epf);
+
+/**
+ * pci_epc_linkup() - Notify the EPF device that EPC device has established a
+ * connection with the Root Complex.
+ * @epc: the EPC device which has established link with the host
+ *
+ * Invoke to Notify the EPF device that the EPC device has established a
+ * connection with the Root Complex.
+ */
+void pci_epc_linkup(struct pci_epc *epc)
+{
+ unsigned long flags;
+ struct pci_epf *epf;
+
+ if (!epc || IS_ERR(epc))
+ return;
+
+ spin_lock_irqsave(&epc->lock, flags);
+ list_for_each_entry(epf, &epc->pci_epf, list)
+ pci_epf_linkup(epf);
+ spin_unlock_irqrestore(&epc->lock, flags);
+}
+EXPORT_SYMBOL_GPL(pci_epc_linkup);
+
+/**
+ * pci_epc_destroy() - destroy the EPC device
+ * @epc: the EPC device that has to be destroyed
+ *
+ * Invoke to destroy the PCI EPC device
+ */
+void pci_epc_destroy(struct pci_epc *epc)
+{
+ device_unregister(&epc->dev);
+ kfree(epc);
+}
+EXPORT_SYMBOL_GPL(pci_epc_destroy);
+
+/**
+ * devm_pci_epc_destroy() - destroy the EPC device
+ * @dev: device that wants to destroy the EPC
+ * @epc: the EPC device that has to be destroyed
+ *
+ * Invoke to destroy the devres associated with this
+ * pci_epc and destroy the EPC device.
+ */
+void devm_pci_epc_destroy(struct device *dev, struct pci_epc *epc)
+{
+ int r;
+
+ r = devres_destroy(dev, devm_pci_epc_release, devm_pci_epc_match,
+ epc);
+ dev_WARN_ONCE(dev, r, "couldn't find PCI EPC resource\n");
+}
+EXPORT_SYMBOL_GPL(devm_pci_epc_destroy);
+
+/**
+ * __pci_epc_create() - create a new endpoint controller (EPC) device
+ * @dev: device that is creating the new EPC
+ * @ops: function pointers for performing EPC operations
+ * @owner: the owner of the module that creates the EPC device
+ *
+ * Invoke to create a new EPC device and add it to pci_epc class.
+ */
+struct pci_epc *
+__pci_epc_create(struct device *dev, const struct pci_epc_ops *ops,
+ struct module *owner)
+{
+ int ret;
+ struct pci_epc *epc;
+
+ if (WARN_ON(!dev)) {
+ ret = -EINVAL;
+ goto err_ret;
+ }
+
+ epc = kzalloc(sizeof(*epc), GFP_KERNEL);
+ if (!epc) {
+ ret = -ENOMEM;
+ goto err_ret;
+ }
+
+ spin_lock_init(&epc->lock);
+ INIT_LIST_HEAD(&epc->pci_epf);
+
+ device_initialize(&epc->dev);
+ dma_set_coherent_mask(&epc->dev, dev->coherent_dma_mask);
+ epc->dev.class = pci_epc_class;
+ epc->dev.dma_mask = dev->dma_mask;
+ epc->ops = ops;
+
+ ret = dev_set_name(&epc->dev, "%s", dev_name(dev));
+ if (ret)
+ goto put_dev;
+
+ ret = device_add(&epc->dev);
+ if (ret)
+ goto put_dev;
+
+ return epc;
+
+put_dev:
+ put_device(&epc->dev);
+ kfree(epc);
+
+err_ret:
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(__pci_epc_create);
+
+/**
+ * __devm_pci_epc_create() - create a new endpoint controller (EPC) device
+ * @dev: device that is creating the new EPC
+ * @ops: function pointers for performing EPC operations
+ * @owner: the owner of the module that creates the EPC device
+ *
+ * Invoke to create a new EPC device and add it to pci_epc class.
+ * While at that, it also associates the device with the pci_epc using devres.
+ * On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ */
+struct pci_epc *
+__devm_pci_epc_create(struct device *dev, const struct pci_epc_ops *ops,
+ struct module *owner)
+{
+ struct pci_epc **ptr, *epc;
+
+ ptr = devres_alloc(devm_pci_epc_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ epc = __pci_epc_create(dev, ops, owner);
+ if (!IS_ERR(epc)) {
+ *ptr = epc;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return epc;
+}
+EXPORT_SYMBOL_GPL(__devm_pci_epc_create);
+
+static int __init pci_epc_init(void)
+{
+ pci_epc_class = class_create(THIS_MODULE, "pci_epc");
+ if (IS_ERR(pci_epc_class)) {
+ pr_err("failed to create pci epc class --> %ld\n",
+ PTR_ERR(pci_epc_class));
+ return PTR_ERR(pci_epc_class);
+ }
+
+ return 0;
+}
+module_init(pci_epc_init);
+
+static void __exit pci_epc_exit(void)
+{
+ class_destroy(pci_epc_class);
+}
+module_exit(pci_epc_exit);
+
+MODULE_DESCRIPTION("PCI EPC Library");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon@ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/pci/endpoint/pci-epc-mem.c b/drivers/pci/endpoint/pci-epc-mem.c
new file mode 100644
index 000000000000..3a94cc1caf22
--- /dev/null
+++ b/drivers/pci/endpoint/pci-epc-mem.c
@@ -0,0 +1,143 @@
+/**
+ * PCI Endpoint *Controller* Address Space Management
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I <kishon@ti.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 of
+ * the License 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/io.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+
+#include <linux/pci-epc.h>
+
+/**
+ * pci_epc_mem_init() - initialize the pci_epc_mem structure
+ * @epc: the EPC device that invoked pci_epc_mem_init
+ * @phys_base: the physical address of the base
+ * @size: the size of the address space
+ *
+ * Invoke to initialize the pci_epc_mem structure used by the
+ * endpoint functions to allocate mapped PCI address.
+ */
+int pci_epc_mem_init(struct pci_epc *epc, phys_addr_t phys_base, size_t size)
+{
+ int ret;
+ struct pci_epc_mem *mem;
+ unsigned long *bitmap;
+ int pages = size >> PAGE_SHIFT;
+ int bitmap_size = BITS_TO_LONGS(pages) * sizeof(long);
+
+ mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+ if (!mem) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+ if (!bitmap) {
+ ret = -ENOMEM;
+ goto err_mem;
+ }
+
+ mem->bitmap = bitmap;
+ mem->phys_base = phys_base;
+ mem->pages = pages;
+ mem->size = size;
+
+ epc->mem = mem;
+
+ return 0;
+
+err_mem:
+ kfree(mem);
+
+err:
+return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_mem_init);
+
+/**
+ * pci_epc_mem_exit() - cleanup the pci_epc_mem structure
+ * @epc: the EPC device that invoked pci_epc_mem_exit
+ *
+ * Invoke to cleanup the pci_epc_mem structure allocated in
+ * pci_epc_mem_init().
+ */
+void pci_epc_mem_exit(struct pci_epc *epc)
+{
+ struct pci_epc_mem *mem = epc->mem;
+
+ epc->mem = NULL;
+ kfree(mem->bitmap);
+ kfree(mem);
+}
+EXPORT_SYMBOL_GPL(pci_epc_mem_exit);
+
+/**
+ * pci_epc_mem_alloc_addr() - allocate memory address from EPC addr space
+ * @epc: the EPC device on which memory has to be allocated
+ * @phys_addr: populate the allocated physical address here
+ * @size: the size of the address space that has to be allocated
+ *
+ * Invoke to allocate memory address from the EPC address space. This
+ * is usually done to map the remote RC address into the local system.
+ */
+void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc,
+ phys_addr_t *phys_addr, size_t size)
+{
+ int pageno;
+ void __iomem *virt_addr;
+ struct pci_epc_mem *mem = epc->mem;
+ int order = get_order(size);
+
+ pageno = bitmap_find_free_region(mem->bitmap, mem->pages, order);
+ if (pageno < 0)
+ return NULL;
+
+ *phys_addr = mem->phys_base + (pageno << PAGE_SHIFT);
+ virt_addr = ioremap(*phys_addr, size);
+ if (!virt_addr)
+ bitmap_release_region(mem->bitmap, pageno, order);
+
+ return virt_addr;
+}
+EXPORT_SYMBOL_GPL(pci_epc_mem_alloc_addr);
+
+/**
+ * pci_epc_mem_free_addr() - free the allocated memory address
+ * @epc: the EPC device on which memory was allocated
+ * @phys_addr: the allocated physical address
+ * @virt_addr: virtual address of the allocated mem space
+ * @size: the size of the allocated address space
+ *
+ * Invoke to free the memory allocated using pci_epc_mem_alloc_addr.
+ */
+void pci_epc_mem_free_addr(struct pci_epc *epc, phys_addr_t phys_addr,
+ void __iomem *virt_addr, size_t size)
+{
+ int pageno;
+ int order = get_order(size);
+ struct pci_epc_mem *mem = epc->mem;
+
+ iounmap(virt_addr);
+ pageno = (phys_addr - mem->phys_base) >> PAGE_SHIFT;
+ bitmap_release_region(mem->bitmap, pageno, order);
+}
+EXPORT_SYMBOL_GPL(pci_epc_mem_free_addr);
+
+MODULE_DESCRIPTION("PCI EPC Address Space Management");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon@ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c
new file mode 100644
index 000000000000..7564a29f435c
--- /dev/null
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -0,0 +1,347 @@
+/**
+ * PCI Endpoint *Function* (EPF) library
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I <kishon@ti.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 of
+ * the License 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/device.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+
+#include <linux/pci-epc.h>
+#include <linux/pci-epf.h>
+
+static struct bus_type pci_epf_bus_type;
+static struct device_type pci_epf_type;
+
+/**
+ * pci_epf_linkup() - Notify the function driver that EPC device has
+ * established a connection with the Root Complex.
+ * @epf: the EPF device bound to the EPC device which has established
+ * the connection with the host
+ *
+ * Invoke to notify the function driver that EPC device has established
+ * a connection with the Root Complex.
+ */
+void pci_epf_linkup(struct pci_epf *epf)
+{
+ if (!epf->driver)
+ dev_WARN(&epf->dev, "epf device not bound to driver\n");
+
+ epf->driver->ops->linkup(epf);
+}
+EXPORT_SYMBOL_GPL(pci_epf_linkup);
+
+/**
+ * pci_epf_unbind() - Notify the function driver that the binding between the
+ * EPF device and EPC device has been lost
+ * @epf: the EPF device which has lost the binding with the EPC device
+ *
+ * Invoke to notify the function driver that the binding between the EPF device
+ * and EPC device has been lost.
+ */
+void pci_epf_unbind(struct pci_epf *epf)
+{
+ if (!epf->driver)
+ dev_WARN(&epf->dev, "epf device not bound to driver\n");
+
+ epf->driver->ops->unbind(epf);
+ module_put(epf->driver->owner);
+}
+EXPORT_SYMBOL_GPL(pci_epf_unbind);
+
+/**
+ * pci_epf_bind() - Notify the function driver that the EPF device has been
+ * bound to a EPC device
+ * @epf: the EPF device which has been bound to the EPC device
+ *
+ * Invoke to notify the function driver that it has been bound to a EPC device
+ */
+int pci_epf_bind(struct pci_epf *epf)
+{
+ if (!epf->driver)
+ dev_WARN(&epf->dev, "epf device not bound to driver\n");
+
+ if (!try_module_get(epf->driver->owner))
+ return -EAGAIN;
+
+ return epf->driver->ops->bind(epf);
+}
+EXPORT_SYMBOL_GPL(pci_epf_bind);
+
+/**
+ * pci_epf_free_space() - free the allocated PCI EPF register space
+ * @addr: the virtual address of the PCI EPF register space
+ * @bar: the BAR number corresponding to the register space
+ *
+ * Invoke to free the allocated PCI EPF register space.
+ */
+void pci_epf_free_space(struct pci_epf *epf, void *addr, enum pci_barno bar)
+{
+ struct device *dev = &epf->dev;
+
+ if (!addr)
+ return;
+
+ dma_free_coherent(dev, epf->bar[bar].size, addr,
+ epf->bar[bar].phys_addr);
+
+ epf->bar[bar].phys_addr = 0;
+ epf->bar[bar].size = 0;
+}
+EXPORT_SYMBOL_GPL(pci_epf_free_space);
+
+/**
+ * pci_epf_alloc_space() - allocate memory for the PCI EPF register space
+ * @size: the size of the memory that has to be allocated
+ * @bar: the BAR number corresponding to the allocated register space
+ *
+ * Invoke to allocate memory for the PCI EPF register space.
+ */
+void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar)
+{
+ void *space;
+ struct device *dev = &epf->dev;
+ dma_addr_t phys_addr;
+
+ if (size < 128)
+ size = 128;
+ size = roundup_pow_of_two(size);
+
+ space = dma_alloc_coherent(dev, size, &phys_addr, GFP_KERNEL);
+ if (!space) {
+ dev_err(dev, "failed to allocate mem space\n");
+ return NULL;
+ }
+
+ epf->bar[bar].phys_addr = phys_addr;
+ epf->bar[bar].size = size;
+
+ return space;
+}
+EXPORT_SYMBOL_GPL(pci_epf_alloc_space);
+
+/**
+ * pci_epf_unregister_driver() - unregister the PCI EPF driver
+ * @driver: the PCI EPF driver that has to be unregistered
+ *
+ * Invoke to unregister the PCI EPF driver.
+ */
+void pci_epf_unregister_driver(struct pci_epf_driver *driver)
+{
+ driver_unregister(&driver->driver);
+}
+EXPORT_SYMBOL_GPL(pci_epf_unregister_driver);
+
+/**
+ * __pci_epf_register_driver() - register a new PCI EPF driver
+ * @driver: structure representing PCI EPF driver
+ * @owner: the owner of the module that registers the PCI EPF driver
+ *
+ * Invoke to register a new PCI EPF driver.
+ */
+int __pci_epf_register_driver(struct pci_epf_driver *driver,
+ struct module *owner)
+{
+ int ret;
+
+ if (!driver->ops)
+ return -EINVAL;
+
+ if (!driver->ops->bind || !driver->ops->unbind || !driver->ops->linkup)
+ return -EINVAL;
+
+ driver->driver.bus = &pci_epf_bus_type;
+ driver->driver.owner = owner;
+
+ ret = driver_register(&driver->driver);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(__pci_epf_register_driver);
+
+/**
+ * pci_epf_destroy() - destroy the created PCI EPF device
+ * @epf: the PCI EPF device that has to be destroyed.
+ *
+ * Invoke to destroy the PCI EPF device created by invoking pci_epf_create().
+ */
+void pci_epf_destroy(struct pci_epf *epf)
+{
+ device_unregister(&epf->dev);
+}
+EXPORT_SYMBOL_GPL(pci_epf_destroy);
+
+/**
+ * pci_epf_create() - create a new PCI EPF device
+ * @name: the name of the PCI EPF device. This name will be used to bind the
+ * the EPF device to a EPF driver
+ *
+ * Invoke to create a new PCI EPF device by providing the name of the function
+ * device.
+ */
+struct pci_epf *pci_epf_create(const char *name)
+{
+ int ret;
+ struct pci_epf *epf;
+ struct device *dev;
+ char *func_name;
+ char *buf;
+
+ epf = kzalloc(sizeof(*epf), GFP_KERNEL);
+ if (!epf) {
+ ret = -ENOMEM;
+ goto err_ret;
+ }
+
+ buf = kstrdup(name, GFP_KERNEL);
+ if (!buf) {
+ ret = -ENOMEM;
+ goto free_epf;
+ }
+
+ func_name = buf;
+ buf = strchrnul(buf, '.');
+ *buf = '\0';
+
+ epf->name = kstrdup(func_name, GFP_KERNEL);
+ if (!epf->name) {
+ ret = -ENOMEM;
+ goto free_epf;
+ }
+
+ dev = &epf->dev;
+ device_initialize(dev);
+ dev->bus = &pci_epf_bus_type;
+ dev->type = &pci_epf_type;
+
+ ret = dev_set_name(dev, "%s", name);
+ if (ret)
+ goto put_dev;
+
+ ret = device_add(dev);
+ if (ret)
+ goto put_dev;
+
+ kfree(func_name);
+ return epf;
+
+put_dev:
+ put_device(dev);
+ kfree(epf->name);
+ kfree(func_name);
+
+free_epf:
+ kfree(epf);
+
+err_ret:
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(pci_epf_create);
+
+static void pci_epf_dev_release(struct device *dev)
+{
+ struct pci_epf *epf = to_pci_epf(dev);
+
+ kfree(epf->name);
+ kfree(epf);
+}
+
+static struct device_type pci_epf_type = {
+ .release = pci_epf_dev_release,
+};
+
+static int
+pci_epf_match_id(const struct pci_epf_device_id *id, const struct pci_epf *epf)
+{
+ while (id->name[0]) {
+ if (strcmp(epf->name, id->name) == 0)
+ return true;
+ id++;
+ }
+
+ return false;
+}
+
+static int pci_epf_device_match(struct device *dev, struct device_driver *drv)
+{
+ struct pci_epf *epf = to_pci_epf(dev);
+ struct pci_epf_driver *driver = to_pci_epf_driver(drv);
+
+ if (driver->id_table)
+ return pci_epf_match_id(driver->id_table, epf);
+
+ return !strcmp(epf->name, drv->name);
+}
+
+static int pci_epf_device_probe(struct device *dev)
+{
+ struct pci_epf *epf = to_pci_epf(dev);
+ struct pci_epf_driver *driver = to_pci_epf_driver(dev->driver);
+
+ if (!driver->probe)
+ return -ENODEV;
+
+ epf->driver = driver;
+
+ return driver->probe(epf);
+}
+
+static int pci_epf_device_remove(struct device *dev)
+{
+ int ret;
+ struct pci_epf *epf = to_pci_epf(dev);
+ struct pci_epf_driver *driver = to_pci_epf_driver(dev->driver);
+
+ ret = driver->remove(epf);
+ epf->driver = NULL;
+
+ return ret;
+}
+
+static struct bus_type pci_epf_bus_type = {
+ .name = "pci-epf",
+ .match = pci_epf_device_match,
+ .probe = pci_epf_device_probe,
+ .remove = pci_epf_device_remove,
+};
+
+static int __init pci_epf_init(void)
+{
+ int ret;
+
+ ret = bus_register(&pci_epf_bus_type);
+ if (ret) {
+ pr_err("failed to register pci epf bus --> %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+module_init(pci_epf_init);
+
+static void __exit pci_epf_exit(void)
+{
+ bus_unregister(&pci_epf_bus_type);
+}
+module_exit(pci_epf_exit);
+
+MODULE_DESCRIPTION("PCI EPF Library");
+MODULE_AUTHOR("Kishon Vijay Abraham I <kishon@ti.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 8850fcaf50db..566fda587fcf 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -428,6 +428,16 @@ struct i2c_device_id {
kernel_ulong_t driver_data; /* Data private to the driver */
};
+/* pci_epf */
+
+#define PCI_EPF_NAME_SIZE 20
+#define PCI_EPF_MODULE_PREFIX "pci_epf:"
+
+struct pci_epf_device_id {
+ char name[PCI_EPF_NAME_SIZE];
+ kernel_ulong_t driver_data;
+};
+
/* spi */
#define SPI_NAME_SIZE 32
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
new file mode 100644
index 000000000000..8c63d3c37f76
--- /dev/null
+++ b/include/linux/pci-epc.h
@@ -0,0 +1,142 @@
+/**
+ * PCI Endpoint *Controller* (EPC) header file
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I <kishon@ti.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 of
+ * the License as published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_PCI_EPC_H
+#define __LINUX_PCI_EPC_H
+
+#include <linux/pci-epf.h>
+
+struct pci_epc;
+
+enum pci_epc_irq_type {
+ PCI_EPC_IRQ_UNKNOWN,
+ PCI_EPC_IRQ_LEGACY,
+ PCI_EPC_IRQ_MSI,
+};
+
+/**
+ * struct pci_epc_ops - set of function pointers for performing EPC operations
+ * @write_header: ops to populate configuration space header
+ * @set_bar: ops to configure the BAR
+ * @clear_bar: ops to reset the BAR
+ * @map_addr: ops to map CPU address to PCI address
+ * @unmap_addr: ops to unmap CPU address and PCI address
+ * @set_msi: ops to set the requested number of MSI interrupts in the MSI
+ * capability register
+ * @get_msi: ops to get the number of MSI interrupts allocated by the RC from
+ * the MSI capability register
+ * @raise_irq: ops to raise a legacy or MSI interrupt
+ * @start: ops to start the PCI link
+ * @stop: ops to stop the PCI link
+ * @owner: the module owner containing the ops
+ */
+struct pci_epc_ops {
+ int (*write_header)(struct pci_epc *pci_epc,
+ struct pci_epf_header *hdr);
+ int (*set_bar)(struct pci_epc *epc, enum pci_barno bar,
+ dma_addr_t bar_phys, size_t size, int flags);
+ void (*clear_bar)(struct pci_epc *epc, enum pci_barno bar);
+ int (*map_addr)(struct pci_epc *epc, phys_addr_t addr,
+ u64 pci_addr, size_t size);
+ void (*unmap_addr)(struct pci_epc *epc, phys_addr_t addr);
+ int (*set_msi)(struct pci_epc *epc, u8 interrupts);
+ int (*get_msi)(struct pci_epc *epc);
+ int (*raise_irq)(struct pci_epc *pci_epc,
+ enum pci_epc_irq_type type, u8 interrupt_num);
+ int (*start)(struct pci_epc *epc);
+ void (*stop)(struct pci_epc *epc);
+ struct module *owner;
+};
+
+/**
+ * struct pci_epc_mem - address space of the endpoint controller
+ * @phys_base: physical base address of the PCI address space
+ * @size: the size of the PCI address space
+ * @bitmap: bitmap to manage the PCI address space
+ * @pages: number of bits representing the address region
+ */
+struct pci_epc_mem {
+ phys_addr_t phys_base;
+ size_t size;
+ unsigned long *bitmap;
+ int pages;
+};
+
+/**
+ * struct pci_epc - represents the PCI EPC device
+ * @dev: PCI EPC device
+ * @pci_epf: list of endpoint functions present in this EPC device
+ * @ops: function pointers for performing endpoint operations
+ * @mem: address space of the endpoint controller
+ * @max_functions: max number of functions that can be configured in this EPC
+ * @lock: spinlock to protect pci_epc ops
+ */
+struct pci_epc {
+ struct device dev;
+ struct list_head pci_epf;
+ const struct pci_epc_ops *ops;
+ struct pci_epc_mem *mem;
+ u8 max_functions;
+ /* spinlock to protect against concurrent access of EP controller */
+ spinlock_t lock;
+};
+
+#define to_pci_epc(device) container_of((device), struct pci_epc, dev)
+
+#define pci_epc_create(dev, ops) \
+ __pci_epc_create((dev), (ops), THIS_MODULE)
+#define devm_pci_epc_create(dev, ops) \
+ __devm_pci_epc_create((dev), (ops), THIS_MODULE)
+
+static inline void epc_set_drvdata(struct pci_epc *epc, void *data)
+{
+ dev_set_drvdata(&epc->dev, data);
+}
+
+static inline void *epc_get_drvdata(struct pci_epc *epc)
+{
+ return dev_get_drvdata(&epc->dev);
+}
+
+struct pci_epc *
+__devm_pci_epc_create(struct device *dev, const struct pci_epc_ops *ops,
+ struct module *owner);
+struct pci_epc *
+__pci_epc_create(struct device *dev, const struct pci_epc_ops *ops,
+ struct module *owner);
+void devm_pci_epc_destroy(struct device *dev, struct pci_epc *epc);
+void pci_epc_destroy(struct pci_epc *epc);
+int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf);
+void pci_epc_linkup(struct pci_epc *epc);
+void pci_epc_remove_epf(struct pci_epc *epc, struct pci_epf *epf);
+int pci_epc_write_header(struct pci_epc *epc, struct pci_epf_header *hdr);
+int pci_epc_set_bar(struct pci_epc *epc, enum pci_barno bar,
+ dma_addr_t bar_phys, size_t size, int flags);
+void pci_epc_clear_bar(struct pci_epc *epc, int bar);
+int pci_epc_map_addr(struct pci_epc *epc, phys_addr_t phys_addr,
+ u64 pci_addr, size_t size);
+void pci_epc_unmap_addr(struct pci_epc *epc, phys_addr_t phys_addr);
+int pci_epc_set_msi(struct pci_epc *epc, u8 interrupts);
+int pci_epc_get_msi(struct pci_epc *epc);
+int pci_epc_raise_irq(struct pci_epc *epc, enum pci_epc_irq_type type,
+ u8 interrupt_num);
+int pci_epc_start(struct pci_epc *epc);
+void pci_epc_stop(struct pci_epc *epc);
+struct pci_epc *pci_epc_get(const char *epc_name);
+void pci_epc_put(struct pci_epc *epc);
+
+int pci_epc_mem_init(struct pci_epc *epc, phys_addr_t phys_addr, size_t size);
+void pci_epc_mem_exit(struct pci_epc *epc);
+void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc,
+ phys_addr_t *phys_addr, size_t size);
+void pci_epc_mem_free_addr(struct pci_epc *epc, phys_addr_t phys_addr,
+ void __iomem *virt_addr, size_t size);
+#endif /* __LINUX_PCI_EPC_H */
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
new file mode 100644
index 000000000000..5628714f7bcf
--- /dev/null
+++ b/include/linux/pci-epf.h
@@ -0,0 +1,160 @@
+/**
+ * PCI Endpoint *Function* (EPF) header file
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I <kishon@ti.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 of
+ * the License as published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_PCI_EPF_H
+#define __LINUX_PCI_EPF_H
+
+#include <linux/device.h>
+#include <linux/mod_devicetable.h>
+
+struct pci_epf;
+
+enum pci_interrupt_pin {
+ PCI_INTERRUPT_UNKNOWN,
+ PCI_INTERRUPT_INTA,
+ PCI_INTERRUPT_INTB,
+ PCI_INTERRUPT_INTC,
+ PCI_INTERRUPT_INTD,
+};
+
+enum pci_barno {
+ BAR_0,
+ BAR_1,
+ BAR_2,
+ BAR_3,
+ BAR_4,
+ BAR_5,
+};
+
+/**
+ * struct pci_epf_header - represents standard configuration header
+ * @vendorid: identifies device manufacturer
+ * @deviceid: identifies a particular device
+ * @revid: specifies a device-specific revision identifier
+ * @progif_code: identifies a specific register-level programming interface
+ * @subclass_code: identifies more specifically the function of the device
+ * @baseclass_code: broadly classifies the type of function the device performs
+ * @cache_line_size: specifies the system cacheline size in units of DWORDs
+ * @subsys_vendor_id: vendor of the add-in card or subsystem
+ * @subsys_id: id specific to vendor
+ * @interrupt_pin: interrupt pin the device (or device function) uses
+ */
+struct pci_epf_header {
+ u16 vendorid;
+ u16 deviceid;
+ u8 revid;
+ u8 progif_code;
+ u8 subclass_code;
+ u8 baseclass_code;
+ u8 cache_line_size;
+ u16 subsys_vendor_id;
+ u16 subsys_id;
+ enum pci_interrupt_pin interrupt_pin;
+};
+
+/**
+ * struct pci_epf_ops - set of function pointers for performing EPF operations
+ * @bind: ops to perform when a EPC device has been bound to EPF device
+ * @unbind: ops to perform when a binding has been lost between a EPC device
+ * and EPF device
+ * @linkup: ops to perform when the EPC device has established a connection with
+ * a host system
+ */
+struct pci_epf_ops {
+ int (*bind)(struct pci_epf *epf);
+ void (*unbind)(struct pci_epf *epf);
+ void (*linkup)(struct pci_epf *epf);
+};
+
+/**
+ * struct pci_epf_driver - represents the PCI EPF driver
+ * @probe: ops to perform when a new EPF device has been bound to the EPF driver
+ * @remove: ops to perform when the binding between the EPF device and EPF
+ * driver is broken
+ * @driver: PCI EPF driver
+ * @ops: set of function pointers for performing EPF operations
+ * @owner: the owner of the module that registers the PCI EPF driver
+ * @id_table: identifies EPF devices for probing
+ */
+struct pci_epf_driver {
+ int (*probe)(struct pci_epf *epf);
+ int (*remove)(struct pci_epf *epf);
+
+ struct device_driver driver;
+ struct pci_epf_ops *ops;
+ struct module *owner;
+ const struct pci_epf_device_id *id_table;
+};
+
+#define to_pci_epf_driver(drv) (container_of((drv), struct pci_epf_driver, \
+ driver))
+
+/**
+ * struct pci_epf_bar - represents the BAR of EPF device
+ * @phys_addr: physical address that should be mapped to the BAR
+ * @size: the size of the address space present in BAR
+ */
+struct pci_epf_bar {
+ dma_addr_t phys_addr;
+ size_t size;
+};
+
+/**
+ * struct pci_epf - represents the PCI EPF device
+ * @dev: the PCI EPF device
+ * @name: the name of the PCI EPF device
+ * @header: represents standard configuration header
+ * @bar: represents the BAR of EPF device
+ * @msi_interrupts: number of MSI interrupts required by this function
+ * @func_no: unique function number within this endpoint device
+ * @epc: the EPC device to which this EPF device is bound
+ * @driver: the EPF driver to which this EPF device is bound
+ * @list: to add pci_epf as a list of PCI endpoint functions to pci_epc
+ */
+struct pci_epf {
+ struct device dev;
+ const char *name;
+ struct pci_epf_header *header;
+ struct pci_epf_bar bar[6];
+ u8 msi_interrupts;
+ u8 func_no;
+
+ struct pci_epc *epc;
+ struct pci_epf_driver *driver;
+ struct list_head list;
+};
+
+#define to_pci_epf(epf_dev) container_of((epf_dev), struct pci_epf, dev)
+
+#define pci_epf_register_driver(driver) \
+ __pci_epf_register_driver((driver), THIS_MODULE)
+
+static inline void epf_set_drvdata(struct pci_epf *epf, void *data)
+{
+ dev_set_drvdata(&epf->dev, data);
+}
+
+static inline void *epf_get_drvdata(struct pci_epf *epf)
+{
+ return dev_get_drvdata(&epf->dev);
+}
+
+struct pci_epf *pci_epf_create(const char *name);
+void pci_epf_destroy(struct pci_epf *epf);
+int __pci_epf_register_driver(struct pci_epf_driver *driver,
+ struct module *owner);
+void pci_epf_unregister_driver(struct pci_epf_driver *driver);
+void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar);
+void pci_epf_free_space(struct pci_epf *epf, void *addr, enum pci_barno bar);
+int pci_epf_bind(struct pci_epf *epf);
+void pci_epf_unbind(struct pci_epf *epf);
+void pci_epf_linkup(struct pci_epf *epf);
+#endif /* __LINUX_PCI_EPF_H */
--
2.11.0
^ permalink raw reply related
* [GIT PULL] PCI: Support for configurable PCI endpoint
From: Kishon Vijay Abraham I @ 2017-04-05 8:52 UTC (permalink / raw)
To: Bjorn Helgaas, Joao Pinto, linux-pci, linux-doc, linux-kernel,
devicetree, linux-omap, linux-arm-kernel
Cc: hch, nsekhar, kishon
Hi Bjorn,
Please find the pull request for PCI endpoint support below. I've
also included all the history here.
Changes from v5:
*) remove #syscon-cells property added in v5 and used
of_parse_phandle_with_fixed_args
*) fix compilation error in make.cross ARCH=blackfin that was because
pci_endpoint_test.c driver depends on COMPILE_TEST.
Changes from v4:
*) add #syscon-cells property and used of_parse_phandle_with_args
to perform a configuration in syscon module (as suggested by
Rob Herring)
*) Remove unnecessary white space.
Changes from v3:
*) fixed a typo and adapted to https://lkml.org/lkml/2017/3/13/562.
Changes from v2:
*) changed the configfs structure as suggested by Christoph Hellwig. With
this change the framework creates configfs entry for EP function driver
and EP controller. Previously these entries have to be created by the
the user. (Haven't changed the epc core or epf core except for invoking
configfs APIs to create entries for EP function driver and EP controller.
That's mostly because the EP function device can still be created by
directly invoking the epf core API without using configfs).
*) Now the user has to use configfs entry 'start' to start the link.
This was previously done by the function driver. However in the case of
multi function EP, the function driver shouldn't start the link.
Changes from v1:
*) The preparation patches for adding EP support is removed and is sent
separately
*) Added device ID for DRA74x/DRA72x and used it instead of
using "PCI_ANY_ID"
*) Added userguide for PCI endpoint test function
Major Improvements from RFC:
*) support multi-function devices (hw supported not virtual)
*) Access host side buffers
*) Raise MSI interrupts
*) Add user space program to use the host side PCI driver
*) Adapt all other users of designware to use the new design (only
compile tested. Since I have only dra7xx boards, the new design
has only been tested in dra7xx. I'd require the help of others
to test the platforms they have access to).
This is based on
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
pci/host-designware
Thanks
Kishon
The following changes since commit 7ea64dcf602c21b3e5062ca90111ca4459fab403:
__end__ (2017-04-04 15:29:37 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/pci-endpoint.git tags/pci-endpoint-for-4.12
for you to fetch changes up to a5c85ba45c9682456077d7277196e91f8ea5fd5c:
ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP (2017-04-05 14:05:28 +0530)
----------------------------------------------------------------
pci: endpoint: for 4.12
*) Add PCI endpoint core layer
*) Modify designware and dra7xx driver to be configured in EP mode
*) Add a PCI endpoint *test* function driver and corresponding host
driver
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
----------------------------------------------------------------
Kishon Vijay Abraham I (23):
PCI: endpoint: Add EP core layer to enable EP controller and EP functions
Documentation: PCI: Guide to use PCI Endpoint Core Layer
PCI: endpoint: Introduce configfs entry for configuring EP functions
Documentation: PCI: Guide to use PCI endpoint configfs
PCI: endpoint: Create configfs entry for EPC device and EPF driver
Documentation: PCI: Add specification for the *PCI test* function device
PCI: endpoint: functions: Add an EP function to test PCI
Documentation: PCI: Add binding documentation for pci-test endpoint function
PCI: dwc: designware: Add EP mode support
dt-bindings: PCI: Add DT bindings for PCI designware EP mode
PCI: dwc: dra7xx: Facilitate wrapper and MSI interrupts to be enabled independently
PCI: dwc: dra7xx: Add EP mode support
dt-bindings: PCI: dra7xx: Add DT bindings for PCI dra7xx EP mode
PCI: dwc: dra7xx: Workaround for errata id i870
dt-bindings: PCI: dra7xx: Add DT bindings to enable unaligned access
PCI: Add device IDs for DRA74x and DRA72x
misc: Add host side PCI driver for PCI test function device
Documentation: misc-devices: Add Documentation for pci-endpoint-test driver
tools: PCI: Add a userspace tool to test PCI endpoint
tools: PCI: Add sample test script to invoke pcitest
Documentation: PCI: Add userguide for PCI endpoint test function
MAINTAINERS: Add PCI Endpoint maintainer
ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
Documentation/PCI/00-INDEX | 10 +++
Documentation/PCI/endpoint/function/binding/pci-test.txt | 17 +++++
Documentation/PCI/endpoint/pci-endpoint-cfs.txt | 105 ++++++++++++++++++++++++++
Documentation/PCI/endpoint/pci-endpoint.txt | 215 ++++++++++++++++++++++++++++++++++++++++++++++++++++
Documentation/PCI/endpoint/pci-test-function.txt | 66 ++++++++++++++++
Documentation/PCI/endpoint/pci-test-howto.txt | 179 +++++++++++++++++++++++++++++++++++++++++++
Documentation/devicetree/bindings/pci/designware-pcie.txt | 26 +++++--
Documentation/devicetree/bindings/pci/ti-pci.txt | 42 +++++++++--
Documentation/misc-devices/pci-endpoint-test.txt | 35 +++++++++
MAINTAINERS | 9 +++
arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
drivers/Makefile | 2 +
drivers/misc/Kconfig | 7 ++
drivers/misc/Makefile | 1 +
drivers/misc/pci_endpoint_test.c | 534 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/pci/Kconfig | 1 +
drivers/pci/dwc/Kconfig | 36 ++++++++-
drivers/pci/dwc/Makefile | 5 +-
drivers/pci/dwc/pci-dra7xx.c | 270 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
drivers/pci/dwc/pcie-designware-ep.c | 342 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/pci/dwc/pcie-designware.c | 125 ++++++++++++++++++++++++++++++
drivers/pci/dwc/pcie-designware.h | 112 +++++++++++++++++++++++++++
drivers/pci/endpoint/Kconfig | 31 ++++++++
drivers/pci/endpoint/Makefile | 7 ++
drivers/pci/endpoint/functions/Kconfig | 12 +++
drivers/pci/endpoint/functions/Makefile | 5 ++
drivers/pci/endpoint/functions/pci-epf-test.c | 510 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/pci/endpoint/pci-ep-cfs.c | 509 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/pci/endpoint/pci-epc-core.c | 579 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/pci/endpoint/pci-epc-mem.c | 143 +++++++++++++++++++++++++++++++++++
drivers/pci/endpoint/pci-epf-core.c | 351 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/mod_devicetable.h | 10 +++
include/linux/pci-ep-cfs.h | 41 ++++++++++
include/linux/pci-epc.h | 144 +++++++++++++++++++++++++++++++++++
include/linux/pci-epf.h | 162 +++++++++++++++++++++++++++++++++++++++
include/linux/pci_ids.h | 2 +
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/pcitest.h | 19 +++++
tools/pci/pcitest.c | 186 +++++++++++++++++++++++++++++++++++++++++++++
tools/pci/pcitest.sh | 56 ++++++++++++++
40 files changed, 4869 insertions(+), 40 deletions(-)
create mode 100644 Documentation/PCI/endpoint/function/binding/pci-test.txt
create mode 100644 Documentation/PCI/endpoint/pci-endpoint-cfs.txt
create mode 100644 Documentation/PCI/endpoint/pci-endpoint.txt
create mode 100644 Documentation/PCI/endpoint/pci-test-function.txt
create mode 100644 Documentation/PCI/endpoint/pci-test-howto.txt
create mode 100644 Documentation/misc-devices/pci-endpoint-test.txt
create mode 100644 drivers/misc/pci_endpoint_test.c
create mode 100644 drivers/pci/dwc/pcie-designware-ep.c
create mode 100644 drivers/pci/endpoint/Kconfig
create mode 100644 drivers/pci/endpoint/Makefile
create mode 100644 drivers/pci/endpoint/functions/Kconfig
create mode 100644 drivers/pci/endpoint/functions/Makefile
create mode 100644 drivers/pci/endpoint/functions/pci-epf-test.c
create mode 100644 drivers/pci/endpoint/pci-ep-cfs.c
create mode 100644 drivers/pci/endpoint/pci-epc-core.c
create mode 100644 drivers/pci/endpoint/pci-epc-mem.c
create mode 100644 drivers/pci/endpoint/pci-epf-core.c
create mode 100644 include/linux/pci-ep-cfs.h
create mode 100644 include/linux/pci-epc.h
create mode 100644 include/linux/pci-epf.h
create mode 100644 include/uapi/linux/pcitest.h
create mode 100644 tools/pci/pcitest.c
create mode 100644 tools/pci/pcitest.sh
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
From: Quentin Schulz @ 2017-04-05 8:48 UTC (permalink / raw)
To: Liam Breck
Cc: Sebastian Reichel, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAKvHMgRD8N4zuW1E4NO8Dzux6V8cHTwiYL+cvoEuz49am2duKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Liam,
On 05/04/2017 10:38, Liam Breck wrote:
> [reduced CC list]
>
> Hi Quentin,
>
> On Wed, Apr 5, 2017 at 1:10 AM, Quentin Schulz
> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>>
>> This patch adds the DT binding documentation for the battery power
>> supply which gets various data from the PMIC, such as the battery status
>> (charging, discharging, full, dead), current max limit, current current,
>> battery capacity (in percentage), voltage max and min limits, current
>> voltage and battery capacity (in Ah).
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> ---
>>
>> v5:
>> - removed DT property example from monitored-battery,
>>
>> v4:
>> - added monitored-battery optional property,
>> - added example with battery,
>>
>> v3:
>> - removed constant charge current property, now should use the WIP
>> battery framework,
>>
>> v2:
>> - changed DT node name from ac_power_supply to ac-power-supply,
>> - removed io-channels and io-channel-names from DT (the IIO mapping is
>> done in the IIO ADC driver now),
>> - added x-powers,constant-charge-current property to set the maximal
>> default constant current charge of the battery,
>>
>> .../bindings/power/supply/axp20x_battery.txt | 28 ++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>> new file mode 100644
>> index 0000000..63826fd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>> @@ -0,0 +1,28 @@
>> +AXP20x and AXP22x battery power supply
>> +
>> +Required Properties:
>> + - compatible, one of:
>> + "x-powers,axp209-battery-power-supply"
>> + "x-powers,axp221-battery-power-supply"
>> +
>> +Optional properties:
>> + - monitored-battery, phandle to a fixed battery
>
> Say here what properties of the battery your driver considers, e.g.
> https://patchwork.kernel.org/patch/9660987/
>
Sorry but I'm completely lost in your patch series, this isn't your
patch series for the battery framework. How do I know from which I
should take the name of the DT property then?
>> +
>> +This node is a subnode of the axp20x/axp22x PMIC.
>> +
>> +The AXP20X and AXP22X can read the battery voltage, charge and discharge
>> +currents of the battery by reading ADC channels from the AXP20X/AXP22X
>> +ADC.
>> +
>> +Example:
>> +
>> +battery: battery {
>> + compatible = "fixed-battery";
>
> This is now "simple-battery". Also needs properties.
>
I've removed all the code in the driver to take care of the monitored
battery info until your framework is merged. Since there are still
discussion around the name to give to the different DT properties and
since it's not required in this driver, I'll add them later to the DT
binding.
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: [GIT PULL] PCI: Support for configurable PCI endpoint
From: Kishon Vijay Abraham I @ 2017-04-05 8:47 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Helgaas, Joao Pinto, linux-pci, linux-doc, linux-kernel,
devicetree, linux-omap, linux-arm-kernel, hch, nsekhar
In-Reply-To: <20170404203606.GE27692@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn,
On Wednesday 05 April 2017 02:06 AM, Bjorn Helgaas wrote:
> On Mon, Mar 27, 2017 at 03:14:56PM +0530, Kishon Vijay Abraham I wrote:
>> Hi Bjorn,
>>
>> Please find the pull request for PCI endpoint support below. I've
>> also included all the history here.
>
> I tentatively applied this to pci/host-designware with the mostly trival
> textual changes below. If you post the series again, please include them.
Sure, I've used pci/host-designware as the base for the next revision.
>
> I saw some acks to prior revisions, but few of them were included in this
> series. Can you collect them up? If there are no other substantial
> changes, I can insert them into my branch manually.
Yeah, looks like I've missed including Joao Pinto's Acked-by in some of the
patches. I'll include them in the next revision.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
From: Liam Breck @ 2017-04-05 8:38 UTC (permalink / raw)
To: Quentin Schulz; +Cc: Sebastian Reichel, robh+dt, linux-pm, devicetree
In-Reply-To: <20170405081059.1684-2-quentin.schulz@free-electrons.com>
[reduced CC list]
Hi Quentin,
On Wed, Apr 5, 2017 at 1:10 AM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the DT binding documentation for the battery power
> supply which gets various data from the PMIC, such as the battery status
> (charging, discharging, full, dead), current max limit, current current,
> battery capacity (in percentage), voltage max and min limits, current
> voltage and battery capacity (in Ah).
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>
> v5:
> - removed DT property example from monitored-battery,
>
> v4:
> - added monitored-battery optional property,
> - added example with battery,
>
> v3:
> - removed constant charge current property, now should use the WIP
> battery framework,
>
> v2:
> - changed DT node name from ac_power_supply to ac-power-supply,
> - removed io-channels and io-channel-names from DT (the IIO mapping is
> done in the IIO ADC driver now),
> - added x-powers,constant-charge-current property to set the maximal
> default constant current charge of the battery,
>
> .../bindings/power/supply/axp20x_battery.txt | 28 ++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>
> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> new file mode 100644
> index 0000000..63826fd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> @@ -0,0 +1,28 @@
> +AXP20x and AXP22x battery power supply
> +
> +Required Properties:
> + - compatible, one of:
> + "x-powers,axp209-battery-power-supply"
> + "x-powers,axp221-battery-power-supply"
> +
> +Optional properties:
> + - monitored-battery, phandle to a fixed battery
Say here what properties of the battery your driver considers, e.g.
https://patchwork.kernel.org/patch/9660987/
> +
> +This node is a subnode of the axp20x/axp22x PMIC.
> +
> +The AXP20X and AXP22X can read the battery voltage, charge and discharge
> +currents of the battery by reading ADC channels from the AXP20X/AXP22X
> +ADC.
> +
> +Example:
> +
> +battery: battery {
> + compatible = "fixed-battery";
This is now "simple-battery". Also needs properties.
> +};
> +
> +&axp209 {
> + battery_power_supply: battery-power-supply {
> + compatible = "x-powers,axp209-battery-power-supply";
> + monitored-battery = <&battery>;
> + }
> +};
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash
From: Guochun Mao @ 2017-04-05 8:37 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: David Woodhouse, Richard Weinberger, Rob Herring, Mark Rutland,
Matthias Brugger, Russell King,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Guochun Mao
In-Reply-To: <1491381462-21893-1-git-send-email-guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
When nor's size larger than 16MByte, nor's address width maybe
set to 3 or 4, and controller should change address width according
to nor's setting.
Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
index e661877..b637770 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -104,6 +104,8 @@
#define MTK_NOR_MAX_RX_TX_SHIFT 6
/* can shift up to 56 bits (7 bytes) transfer by MTK_NOR_PRG_CMD */
#define MTK_NOR_MAX_SHIFT 7
+/* nor controller 4-byte address mode enable bit */
+#define MTK_NOR_4B_ADDR_EN BIT(4)
/* Helpers for accessing the program data / shift data registers */
#define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
@@ -230,10 +232,35 @@ static int mt8173_nor_write_buffer_disable(struct mt8173_nor *mt8173_nor)
10000);
}
+static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
+{
+ u8 val;
+ struct spi_nor *nor = &mt8173_nor->nor;
+
+ val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG);
+
+ switch (nor->addr_width) {
+ case 3:
+ val &= ~MTK_NOR_4B_ADDR_EN;
+ break;
+ case 4:
+ val |= MTK_NOR_4B_ADDR_EN;
+ break;
+ default:
+ dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n",
+ nor->addr_width);
+ break;
+ }
+
+ writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG);
+}
+
static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
{
int i;
+ mt8173_nor_set_addr_width(mt8173_nor);
+
for (i = 0; i < 3; i++) {
writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i * 4);
addr >>= 8;
--
1.7.9.5
--
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 v1] mtd: mtk-nor: set controller's address width according to nor flas
From: Guochun Mao @ 2017-04-05 8:37 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: David Woodhouse, Richard Weinberger, Rob Herring, Mark Rutland,
Matthias Brugger, Russell King, linux-mtd, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel
Guochun Mao (1):
mtd: mtk-nor: set controller's address width according to nor flash
drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v5 14/24] dt-bindings: mfd: syscon: Add documentation for #syscon-cells property
From: Kishon Vijay Abraham I @ 2017-04-05 8:25 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Helgaas, Joao Pinto, linux-pci, linux-doc, linux-kernel,
devicetree, linux-omap, linux-arm-kernel, hch, nsekhar
In-Reply-To: <20170331190627.nucviejokdklgtk7@rob-hp-laptop>
Hi Rob,
On Saturday 01 April 2017 12:36 AM, Rob Herring wrote:
> On Fri, Mar 31, 2017 at 01:58:52PM -0500, Rob Herring wrote:
>> On Mon, Mar 27, 2017 at 03:15:10PM +0530, Kishon Vijay Abraham I wrote:
>>> Add documentation for the optional #syscon-cells property to determine
>>> the number of cells that should be given in the phandle while
>>> referencing the syscon-node.
>>>
>>> Suggested-by: Rob Herring <robh@kernel.org>
>>
>> I did? When?
>>
>> I'm not remembering why we need this. Generally, phandles to a syscon
>> are for a single defined purpose. When do we need a list of them?
>
> Ah, I remember now the context. I suggested using standard parsing
> function rather than open coding. I wasn't suggesting changing the
> binding. Instead of of_parse_phandle_with_args, can't
> of_parse_phandle_with_fixed_args work?
yes, it can be used. Will change it my next revision.
Thanks
Kishon
^ permalink raw reply
* Re: Re: [PATCH 10/11] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Icenowy Zheng @ 2017-04-05 8:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Rob Herring, linux-kernel, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lee Jones, Liam Girdwood,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Chen-Yu Tsai
In-Reply-To: <20170405080857.hetsjgatyh6hbsoh@lukather>
在 2017年04月05日 16:08, Maxime Ripard 写道:
> On Wed, Apr 05, 2017 at 02:15:43PM +0800, Icenowy Zheng wrote:
>>
>> 2017年4月5日 14:13于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
>>>
>>> On Wed, Apr 05, 2017 at 02:01:44AM +0800, Icenowy Zheng wrote:
>>>> Add support of AXP803 regulators in the Pine64 device tree, in order to
>>>> enable many future functionalities, e.g. Wi-Fi.
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>>> ---
>>>> .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
>>>> 1 file changed, 109 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> index 2132d8e6cb3d..7da074f95065 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>>>> @@ -106,6 +106,115 @@
>>>> };
>>>> };
>>>>
>>>> +#include "axp803.dtsi"
>>>> +
>>>> +®_aldo1 {
>>>> + regulator-min-microvolt = <2800000>;
>>>> + regulator-max-microvolt = <2800000>;
>>>> + regulator-name = "vcc-csi";
>>>> +};
>>>> +
>>>> +®_aldo2 {
>>>> + regulator-always-on;
>>>> + regulator-min-microvolt = <1800000>;
>>>> + regulator-max-microvolt = <3300000>;
>>>> + regulator-name = "vcc-pl";
>>>> +};
>>>> +
>>>> +®_aldo3 {
>>>> + regulator-always-on;
>>>> + regulator-min-microvolt = <2700000>;
>>>> + regulator-max-microvolt = <3300000>;
>>>> + regulator-name = "vcc-pll-avcc";
>>>> +};
>>>> +
>>>> +®_dc1sw {
>>>> + regulator-name = "vcc-phy";
>>>> +};
>>>> +
>>>> +®_dcdc1 {
>>>> + regulator-always-on;
>>>> + regulator-min-microvolt = <3300000>;
>>>> + regulator-max-microvolt = <3300000>;
>>>> + regulator-name = "vcc-3v3";
>>>> +};
>>>> +
>>>> +®_dcdc2 {
>>>> + regulator-always-on;
>>>> + regulator-min-microvolt = <1000000>;
>>>> + regulator-max-microvolt = <1300000>;
>>>> + regulator-name = "vdd-cpux";
>>>> +};
>>>> +
>>>> +/* DCDC3 is polyphased with DCDC2 */
>>>> +
>>>> +®_dcdc5 {
>>>> + regulator-always-on;
>>>> + regulator-min-microvolt = <1500000>;
>>>> + regulator-max-microvolt = <1500000>;
>>>> + regulator-name = "vcc-dram";
>>>> +};
>>>> +
>>>> +®_dcdc6 {
>>>> + regulator-always-on;
>>>> + regulator-min-microvolt = <1100000>;
>>>> + regulator-max-microvolt = <1100000>;
>>>> + regulator-name = "vdd-sys";
>>>> +};
>>>> +
>>>> +®_dldo1 {
>>>> + regulator-min-microvolt = <3300000>;
>>>> + regulator-max-microvolt = <3300000>;
>>>> + regulator-name = "vcc-hdmi";
>>>> +};
>>>> +
>>>> +®_dldo2 {
>>>> + regulator-min-microvolt = <3300000>;
>>>> + regulator-max-microvolt = <3300000>;
>>>> + regulator-name = "vcc-mipi";
>>>> +};
>>>> +
>>>> +®_dldo3 {
>>>> + regulator-min-microvolt = <3300000>;
>>>> + regulator-max-microvolt = <3300000>;
>>>> + regulator-name = "avdd-csi";
>>>> +};
>>>> +
>>>> +®_dldo4 {
>>>> + regulator-min-microvolt = <3300000>;
>>>> + regulator-max-microvolt = <3300000>;
>>>> + regulator-name = "vcc-wifi";
>>>> +};
>>>> +
>>>> +®_eldo1 {
>>>> + regulator-min-microvolt = <1800000>;
>>>> + regulator-max-microvolt = <1800000>;
>>>> + regulator-name = "cpvdd";
>>>> +};
>>>> +
>>>> +®_eldo3 {
>>>> + regulator-min-microvolt = <1800000>;
>>>> + regulator-max-microvolt = <1800000>;
>>>> + regulator-name = "vdd-1v8-csi";
>>>> +};
>>>> +
>>>> +®_fldo1 {
>>>> + regulator-min-microvolt = <1200000>;
>>>> + regulator-max-microvolt = <1200000>;
>>>> + regulator-name = "vcc-1v2-hsic";
>>>> +};
>>>> +
>>>> +®_fldo2 {
>>>> + regulator-always-on;
>>>> + regulator-min-microvolt = <1100000>;
>>>> + regulator-max-microvolt = <1100000>;
>>>> + regulator-name = "vdd-cpus";
>>>> +};
>>>
>>> Why do you need to always power the AR100 on?
>>
>> It's for CPUS power domain, not the AR100 processor.
>>
>> Kill it will lead to instantly system hang.
>
> What are you calling CPUS then?
I think it's the full zone after 0x01f00000 (all R_
peripherals)
In A23/A33 we also called this "vdd-cpus" and it should
be always-on.
>
> Maxime
>
--
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] drm: rcar-du: Document the vsps property in the DT bindings
From: Laurent Pinchart @ 2017-04-05 8:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas, devicetree@vger.kernel.org, Laurent Pinchart,
DRI Development, Sergei Shtylyov
In-Reply-To: <CAMuHMdWYq-w9T4chEh4Hg0+9_MCb+bivD3sgHeCoMPe61=czjg@mail.gmail.com>
Hi Geert,
On Wednesday 05 Apr 2017 09:54:38 Geert Uytterhoeven wrote:
> On Fri, Mar 31, 2017 at 11:21 AM, Geert Uytterhoeven wrote:
> > On Fri, Mar 31, 2017 at 11:19 AM, Laurent Pinchart wrote:
> >> On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
> >>> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
> >>>> The property is used by the driver but is missing from the DT
> >>>> bindings. Document it.
> >>>>
> >>>> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >>>> Signed-off-by: Laurent Pinchart
> >>>> <laurent.pinchart+renesas@ideasonboard.com>
> >>>> ---
> >>>>
> >>>> Documentation/devicetree/bindings/display/renesas,du.txt | 5 +++++
> >>>> 1 file changed, 5 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> >>>> b/Documentation/devicetree/bindings/display/renesas,du.txt index
> >>>> 1a02f099a0ff..cf34893a1b53 100644
> >>>> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> >>>> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> >>>>
> >>>> @@ -36,6 +36,11 @@ Required Properties:
> >>>> When supplied they must be named "dclkin.x" with "x" being the
> >>>> input clock numerical index.
> >>> >
> >>> > +Optional Properties:
> >>> > +
> >>> > + - vsps: A list of phandles to the VSP nodes that handle the memory
> >>> > + interfaces for the DU channels (Gen3 only).
> >>>
> >>> ", one per channel"?
> >>>
> >>> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
> >>
> >> How about making it mandatory on Gen2 as well ? The VSPs are there, even
> >> if the driver doesn't use them, it makes sense to describe the
> >> connection. Of
> >
> > Fine for me, as this is hardware description.
> >
> >> course the driver will treat the property as optional for backward
> >> compatibility.
> >
> > OK.
>
> Will you do this as an incremental update?
> I noticed the initial version is now in drm-next.
I've included it in the pull request by mistake and realized that too late,
sorry :-/ I will send an incremental update.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1
From: Russell King - ARM Linux @ 2017-04-05 8:21 UTC (permalink / raw)
To: Steve Longerbeam
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, sakari.ailus, nick,
songjun.wu, hverkuil, Steve Longerbeam, pavel, robert.jarzmik,
devel, markus.heiser, laurent.pinchart+renesas, shuah, geert,
linux-media, devicetree, kernel, arnd, mchehab, bparrot, robh+dt,
horms+renesas, tiffany.lin, linux-arm-kernel,
niklas.soderlund+renesas, gregkh, linux-kernel,
jean-christophe.trotin, Philipp Zabel, fabio.estevam, shawnguo,
sudipm.mukherjee
In-Reply-To: <7235285c-f39a-64bc-195a-11cfde9e67c5@gmail.com>
On Tue, Apr 04, 2017 at 05:44:05PM -0700, Steve Longerbeam wrote:
>
>
> On 04/04/2017 05:40 PM, Steve Longerbeam wrote:
> >
> >
> >On 04/04/2017 04:10 PM, Russell King - ARM Linux wrote:
> >>On Thu, Mar 30, 2017 at 07:25:49PM +0200, Philipp Zabel wrote:
> >>>The TVP5150 DT bindings specify a single output port (port 0) that
> >>>corresponds to the video output pad (pad 1, DEMOD_PAD_VID_OUT).
> >>>
> >>>Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> >>>---
> >>>I'm trying to get this to work with a TVP5150 analog TV decoder, and the
> >>>first problem is that this device doesn't have pad 0 as its single
> >>>output pad. Instead, as a MEDIA_ENT_F_ATV_DECODER entity, it has for
> >>>pads (input, video out, vbi out, audio out), and video out is pad 1,
> >>>whereas the device tree only defines a single port (0).
> >>
> >>Looking at the patch, it's highlighted another review point with
> >>Steve's driver.
> >>
> >>>diff --git a/drivers/staging/media/imx/imx-media-dev.c
> >>>b/drivers/staging/media/imx/imx-media-dev.c
> >>>index 17e2386a3ca3a..c52d6ca797965 100644
> >>>--- a/drivers/staging/media/imx/imx-media-dev.c
> >>>+++ b/drivers/staging/media/imx/imx-media-dev.c
> >>>@@ -267,6 +267,15 @@ static int imx_media_create_link(struct
> >>>imx_media_dev *imxmd,
> >>> source_pad = link->local_pad;
> >>> sink_pad = link->remote_pad;
> >>>
> >>>+ /*
> >>>+ * If the source subdev is an analog video decoder with a single
> >>>source
> >>>+ * port, assume that this port 0 corresponds to the
> >>>DEMOD_PAD_VID_OUT
> >>>+ * entity pad.
> >>>+ */
> >>>+ if (source->entity.function == MEDIA_ENT_F_ATV_DECODER &&
> >>>+ local_sd->num_sink_pads == 0 && local_sd->num_src_pads == 1)
> >>>+ source_pad = DEMOD_PAD_VID_OUT;
> >>>+
> >>> v4l2_info(&imxmd->v4l2_dev, "%s: %s:%d -> %s:%d\n", __func__,
> >>> source->name, source_pad, sink->name, sink_pad);
> >>
> >>What is "local" and what is "remote" here? It seems that, in the case of
> >>a link being created with the sensor(etc), it's all back to front.
> >>
> >>Eg, I see locally:
> >>
> >>imx-media: imx_media_create_link: imx219 0-0010:0 -> imx6-mipi-csi2:0
> >>
> >>So here, "source" is the imx219 (the sensor), and sink is
> >>"imx6-mipi-csi2"
> >>(part of the iMX6 capture.) However, this makes "local_sd" the subdev of
> >>the sensor, and "remote_sd" the subdev of the CSI2 interface - which is
> >>totally back to front - this code is part of the iMX6 capture system,
> >>so "local" implies that it should be part of that, and the "remote" thing
> >>would be the sensor.
> >>
> >>Hence, this seems completely confused. I'd suggest that:
> >>
> >>(a) the "pad->pad.flags & MEDIA_PAD_FL_SINK" test in
> >>imx_media_create_link()
> >> is moved into imx_media_create_links(), and placed here instead:
> >>
> >> for (j = 0; j < num_pads; j++) {
> >> pad = &local_sd->pad[j];
> >>
> >> if (pad->pad.flags & MEDIA_PAD_FL_SINK)
> >> continue;
> >>
> >> ...
> >> }
> >>
> >> as the pad isn't going to spontaneously change this flag while we
> >> consider each individual link.
> >
> >
> >Sure, I can do that. It would avoid iterating unnecessarily through the
> >pad's links if the pad is a sink.
> >
> >
> >> However, maybe the test should be:
> >>
> >> if (!(pad->pad.flags & MEDIA_PAD_FL_SOURCE))
> >>
> >> ?
> >>
> >
> >maybe that is more intuitive.
> >
> >
> >>(b) the terms "local" and "remote" in imx_media_create_link() are
> >> replaced with "source" and "sink" respectively, since this will
> >> now be called with a guaranteed source pad.
> >
> >Agreed. I'll change the arg and local var names.
> >
> >>
> >>As for Philipp's solution, I'm not sure what the correct solution for
> >>something like this is. It depends how you view "hardware interface"
> >>as defined by video-interfaces.txt, and whether the pads on the TVP5150
> >>represent the hardware interfaces. If we take the view that the pads
> >>do represent hardware interfaces, then using the reg= property on the
> >>port node will solve this problem.
> >
> >And the missing port nodes would have to actually be defined first.
> >According to Philipp they aren't, only a single output port 0.
> >
> >
> >>
> >>If not, it would mean that we would have to have the iMX capture code
> >>scan the pads on the source device, looking for outputs - but that
> >>runs into a problem - if the source device has multiple outputs, does
> >>the reg= property specify the output pad index or the pad number,
> >
> >And how do we even know the data direction of a DT port. Is it an input,
> >an output, bidirectional? The OF graph parsing in imx-media-of.c can't
> >determine a port's direction if it encounters a device it doesn't
> >recognize that has multiple ports. For now that is not really a problem
> >because upstream from the video mux and csi-2 receiver it's expected
> >there will only be original sources of video with only one source port.
> >But it can become a limitation later. For example a device that has
> >multiple output bus interfaces, which would require multiple output
> >ports.
> >
>
> Actually what was I thinking, the TVP5150 is already an example of
> such a device.
>
> All of this could be solved if there was some direction information
> in port nodes.
I disagree.
Philipp identified that the TVP5150 has four pads:
* Input pad
* Video output pad
* VBI output pad
* Audio output pad
So, it has one input and three outputs. How does marking the direction
in the port node (which would indicate that there was a data flow out of
TVP5150 into the iMX6 capture) help identify which of those pads should
be used?
It would eliminate the input pad, but you still have three output pads
to choose from.
So no, your idea can't work.
As I already stated, I believe that this case is already covered by
video-interfaces.txt:
If more than
one port is present in a device node or there is more than one endpoint at a
port, or port node needs to be associated with a selected hardware interface,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
used.
So, according to that, you do not need to have more than one port node
to use the reg property - it's _either_ more than one port _or_ to
select the hardware interface.
It all hinges on whether you consider the video output, VBI output or
audio output to be separate hardware interfaces that the singular
specified "port" node needs to select between.
There's another reason why the TVP5150 binding looks wrong and broken,
however. How does the audio output get routed to other parts of the
system if you're using the video output, and how is that relationship
defined? It's a v4l2 subdev pad, so it would need to be part of the
v4l2 subdev graph. It sounds to me like the binding was created with
a narrow focused "this is the board in front of me, it only has video
wired up, I'm not going to consider other use cases" blinkered view.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts
From: Maxime Ripard @ 2017-04-05 8:13 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Kishon Vijay Abraham I,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <a4ca2175-b4df-42e4-1f85-20d34430d4dc-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
On Wed, Apr 05, 2017 at 03:33:09PM +0800, Icenowy Zheng wrote:
> > > P.S. to be compatible with older DTs, I think I should adjust
> > > the phy driver, make it enable dual-route function only when
> > > pmu0 is present.
> >
> > That, or if we're quick enough, we can still add it to 4.11. There's a
> > bit of time left.
>
> Thus the device tree binding patch and the DT part of this patchset
> should be all pushed to 4.11 .
>
> The device tree binding patch is commit ee73fd7dfc86 ("dt: bindings:
> add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64").
It should have always been there. If there is a register for the PHY
somewhere, it must be in the DT node. Period. There's not relation to
whether the driver actually uses it or not.
Please send a patch to add that range for 4.11.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 7/7] ARM: sun5i: chip: enable battery power supply subnode
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The NextThing Co. CHIP has an AXP209 PMIC with battery connector.
This enables the battery power supply subnode.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts b/arch/arm/boot/dts/sun5i-r8-chip.dts
index d078560..879a4b0 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -132,6 +132,10 @@
status = "okay";
};
+&battery_power_supply {
+ status = "okay";
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins_a>;
--
2.9.3
^ permalink raw reply related
* [PATCH v5 6/7] ARM: dts: sun8i: sina33: enable battery power supply subnode
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Sinlinx SinA33 has an AXP223 PMIC and a battery connector, thus, we
enable the battery power supply subnode in its Device Tree.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index e34e092..7afe7fe 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -182,6 +182,10 @@
status = "okay";
};
+&battery_power_supply {
+ status = "okay";
+};
+
®_aldo1 {
regulator-always-on;
regulator-min-microvolt = <3000000>;
--
2.9.3
^ permalink raw reply related
* [PATCH v5 5/7] ARM: dtsi: axp22x: add battery power supply subnode
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP22X PMIC exposes battery supply various data such as
the battery status (charging, discharging, full, dead), current max
limit, current current, battery capacity (in percentage), voltage max
limit, current voltage, and battery capacity (in Ah).
This adds the battery power supply subnode for AXP22X PMIC.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
v2:
- changed DT node name from battery_power_supply to
battery-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
arch/arm/boot/dts/axp22x.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
index 67331c5..87fb08e 100644
--- a/arch/arm/boot/dts/axp22x.dtsi
+++ b/arch/arm/boot/dts/axp22x.dtsi
@@ -57,6 +57,11 @@
status = "disabled";
};
+ battery_power_supply: battery-power-supply {
+ compatible = "x-powers,axp221-battery-power-supply";
+ status = "disabled";
+ };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <3000>;
--
2.9.3
^ permalink raw reply related
* [PATCH v5 4/7] ARM: dtsi: axp209: add battery power supply subnode
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP209 PMIC exposes battery supply various data such as
the battery status (charging, discharging, full, dead), current max
limit, current current, battery capacity (in percentage), voltage max
and min limits, current voltage, and battery capacity (in Ah).
This adds the battery power supply subnode for AXP20X PMIC.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
v2:
- changed DT node name from battery_power_supply to
battery-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
arch/arm/boot/dts/axp209.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
index 9677dd5..3c8fa26 100644
--- a/arch/arm/boot/dts/axp209.dtsi
+++ b/arch/arm/boot/dts/axp209.dtsi
@@ -64,6 +64,11 @@
#gpio-cells = <2>;
};
+ battery_power_supply: battery-power-supply {
+ compatible = "x-powers,axp209-battery-power-supply";
+ status = "disabled";
+ };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <1500>;
--
2.9.3
^ permalink raw reply related
* [PATCH v5 3/7] mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
This patch adds the AXP20X/AXP22X battery driver to the MFD cells of the
AXP209, AXP221 and AXP223 MFD.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
v2:
- changed DT node name from battery_power_supply to
battery-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
drivers/mfd/axp20x.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 5ba3b04..e6f5507 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -594,6 +594,9 @@ static struct mfd_cell axp20x_cells[] = {
}, {
.name = "axp20x-adc",
}, {
+ .name = "axp20x-battery-power-supply",
+ .of_compatible = "x-powers,axp209-battery-power-supply",
+ }, {
.name = "axp20x-ac-power-supply",
.of_compatible = "x-powers,axp202-ac-power-supply",
.num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
@@ -621,6 +624,9 @@ static struct mfd_cell axp221_cells[] = {
.num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
.resources = axp20x_ac_power_supply_resources,
}, {
+ .name = "axp20x-battery-power-supply",
+ .of_compatible = "x-powers,axp221-battery-power-supply",
+ }, {
.name = "axp20x-usb-power-supply",
.of_compatible = "x-powers,axp221-usb-power-supply",
.num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
@@ -636,6 +642,9 @@ static struct mfd_cell axp223_cells[] = {
}, {
.name = "axp22x-adc",
}, {
+ .name = "axp20x-battery-power-supply",
+ .of_compatible = "x-powers,axp221-battery-power-supply",
+ }, {
.name = "axp20x-regulator",
}, {
.name = "axp20x-ac-power-supply",
--
2.9.3
^ permalink raw reply related
* [PATCH v5 2/7] power: supply: add battery driver for AXP20X and AXP22X PMICs
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
This patch adds the battery power supply driver to get various data from
the PMIC, such as the battery status (charging, discharging, full,
dead), current max limit, current current, battery capacity (in
percentage), voltage max and min limits, current voltage and battery
capacity (in Ah).
This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data
provider.
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Acked-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
v5:
- removed support for constant charge current setting from DT,
- added a function to compute the constant charge current depending on the
PMIC variant,
v4:
- removed useless axp20x_dev variable in struct axp20x_batt_ps,
- added struct device and maximum constant current charge variables in struct
axp20x_batt_ps,
- fixed wrong maximum constant current charge formula for AXP22X (forgot to add
a custom formula so it was calculated like the AXP209),
- when a battery node in DT does not have a valid constant current charge or
there is no battery, the maximum current constant current charge are set to the
lowest possible value,
- it is possible to set maximum constant current charge now but a warn message
is printed when trying to increase it to inform people it is risky,
- added a check to verify the constant current charge to be set is under the
maximum allowed,
- lower the current constant charge current if it is higher than the maximum
current value to be set,
v3:
- added axp20x_set_voltage_min_design function so it can be reused,
- used power_supply_get_battery_info for setting constant charge current
instead of x-powers,constant-charge-current introduced in v2,
- used power_supply_get_battery_info for setting voltage min design of
the battery,
v2:
- changed BIT(x) to 1 << x when describing bits purpose for which 2 <<
x or 3 << x exists, to be consistent,
- switched from POWER_SUPPLY_PROP_CURRENT_MAX to
POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
- added POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX to the list of
readable properties,
- replaced µ character by a common u for micro units to make checkpatch
happy,
- factorized code in axp20x_battery_set_max_voltage,
- added a axp20x_set_constant_charge_current function to be used when
setting the value from sysfs and from the DT,
- removed some dead code,
- added a DT property to set constant current charge of the battery
(x-powers,constant-charge-current),
- migrated to dev_get_regmap instead of manually looking for the regmap
in the drvdata of the parent,
- switched from int to uintptr_t cast to make sure the cast is always
for the same size type (make build on 64bits platforms happy mainly),
drivers/power/supply/Kconfig | 12 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/axp20x_battery.c | 502 ++++++++++++++++++++++++++++++++++
3 files changed, 515 insertions(+)
create mode 100644 drivers/power/supply/axp20x_battery.c
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index cc50e15..7f1ada8 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -232,6 +232,18 @@ config CHARGER_AXP20X
This driver can also be built as a module. If so, the module will be
called axp20x_ac_power.
+config BATTERY_AXP20X
+ tristate "X-Powers AXP20X battery driver"
+ depends on MFD_AXP20X
+ depends on AXP20X_ADC
+ depends on IIO
+ help
+ Say Y here to enable support for X-Powers AXP20X PMICs' battery power
+ supply.
+
+ This driver can also be built as a module. If so, the module will be
+ called axp20x_battery.
+
config AXP288_CHARGER
tristate "X-Powers AXP288 Charger"
depends on MFD_AXP20X && EXTCON_AXP288
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 3789a2c..52dd17d 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_TEST_POWER) += test_power.o
obj-$(CONFIG_BATTERY_88PM860X) += 88pm860x_battery.o
obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o
+obj-$(CONFIG_BATTERY_AXP20X) += axp20x_battery.o
obj-$(CONFIG_CHARGER_AXP20X) += axp20x_ac_power.o
obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o
diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
new file mode 100644
index 0000000..5d29b2e
--- /dev/null
+++ b/drivers/power/supply/axp20x_battery.c
@@ -0,0 +1,502 @@
+/*
+ * Battery power supply driver for X-Powers AXP20X and AXP22X PMICs
+ *
+ * Copyright 2016 Free Electrons NextThing Co.
+ * Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This driver is based on a previous upstreaming attempt by:
+ * Bruno Prémont <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ */
+
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/power_supply.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/time.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/consumer.h>
+#include <linux/mfd/axp20x.h>
+
+#define AXP20X_PWR_STATUS_BAT_CHARGING BIT(2)
+
+#define AXP20X_PWR_OP_BATT_PRESENT BIT(5)
+#define AXP20X_PWR_OP_BATT_ACTIVATED BIT(3)
+
+#define AXP209_FG_PERCENT GENMASK(6, 0)
+#define AXP22X_FG_VALID BIT(7)
+
+#define AXP20X_CHRG_CTRL1_TGT_VOLT GENMASK(6, 5)
+#define AXP20X_CHRG_CTRL1_TGT_4_1V (0 << 5)
+#define AXP20X_CHRG_CTRL1_TGT_4_15V (1 << 5)
+#define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5)
+#define AXP20X_CHRG_CTRL1_TGT_4_36V (3 << 5)
+
+#define AXP22X_CHRG_CTRL1_TGT_4_22V (1 << 5)
+#define AXP22X_CHRG_CTRL1_TGT_4_24V (3 << 5)
+
+#define AXP20X_CHRG_CTRL1_TGT_CURR GENMASK(3, 0)
+
+#define AXP20X_V_OFF_MASK GENMASK(2, 0)
+
+struct axp20x_batt_ps {
+ struct regmap *regmap;
+ struct power_supply *batt;
+ struct device *dev;
+ struct iio_channel *batt_chrg_i;
+ struct iio_channel *batt_dischrg_i;
+ struct iio_channel *batt_v;
+ u8 axp_id;
+};
+
+static int axp20x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
+ int *val)
+{
+ int ret, reg;
+
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
+ if (ret)
+ return ret;
+
+ switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
+ case AXP20X_CHRG_CTRL1_TGT_4_1V:
+ *val = 4100000;
+ break;
+ case AXP20X_CHRG_CTRL1_TGT_4_15V:
+ *val = 4150000;
+ break;
+ case AXP20X_CHRG_CTRL1_TGT_4_2V:
+ *val = 4200000;
+ break;
+ case AXP20X_CHRG_CTRL1_TGT_4_36V:
+ *val = 4360000;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int axp22x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
+ int *val)
+{
+ int ret, reg;
+
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
+ if (ret)
+ return ret;
+
+ switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
+ case AXP20X_CHRG_CTRL1_TGT_4_1V:
+ *val = 4100000;
+ break;
+ case AXP20X_CHRG_CTRL1_TGT_4_2V:
+ *val = 4200000;
+ break;
+ case AXP22X_CHRG_CTRL1_TGT_4_22V:
+ *val = 4220000;
+ break;
+ case AXP22X_CHRG_CTRL1_TGT_4_24V:
+ *val = 4240000;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val)
+{
+ if (axp->axp_id == AXP209_ID)
+ *val = *val * 100000 + 300000;
+ else
+ *val = *val * 150000 + 300000;
+}
+
+static int axp20x_get_constant_charge_current(struct axp20x_batt_ps *axp,
+ int *val)
+{
+ int ret;
+
+ ret = regmap_read(axp->regmap, AXP20X_CHRG_CTRL1, val);
+ if (ret)
+ return ret;
+
+ *val &= AXP20X_CHRG_CTRL1_TGT_CURR;
+
+ raw_to_constant_charge_current(axp, val);
+
+ return 0;
+}
+
+static int axp20x_battery_get_prop(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct axp20x_batt_ps *axp20x_batt = power_supply_get_drvdata(psy);
+ struct iio_channel *chan;
+ int ret = 0, reg, val1;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_PRESENT:
+ case POWER_SUPPLY_PROP_ONLINE:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_OP_MODE,
+ ®);
+ if (ret)
+ return ret;
+
+ val->intval = !!(reg & AXP20X_PWR_OP_BATT_PRESENT);
+ break;
+
+ case POWER_SUPPLY_PROP_STATUS:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_INPUT_STATUS,
+ ®);
+ if (ret)
+ return ret;
+
+ if (reg & AXP20X_PWR_STATUS_BAT_CHARGING) {
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ return 0;
+ }
+
+ ret = iio_read_channel_processed(axp20x_batt->batt_dischrg_i,
+ &val1);
+ if (ret)
+ return ret;
+
+ if (val1) {
+ val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+ return 0;
+ }
+
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_FG_RES, &val1);
+ if (ret)
+ return ret;
+
+ /*
+ * Fuel Gauge data takes 7 bits but the stored value seems to be
+ * directly the raw percentage without any scaling to 7 bits.
+ */
+ if ((val1 & AXP209_FG_PERCENT) == 100)
+ val->intval = POWER_SUPPLY_STATUS_FULL;
+ else
+ val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
+ break;
+
+ case POWER_SUPPLY_PROP_HEALTH:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_OP_MODE,
+ &val1);
+ if (ret)
+ return ret;
+
+ if (val1 & AXP20X_PWR_OP_BATT_ACTIVATED) {
+ val->intval = POWER_SUPPLY_HEALTH_DEAD;
+ return 0;
+ }
+
+ val->intval = POWER_SUPPLY_HEALTH_GOOD;
+ break;
+
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ ret = axp20x_get_constant_charge_current(axp20x_batt,
+ &val->intval);
+ if (ret)
+ return ret;
+ break;
+
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
+ val->intval = AXP20X_CHRG_CTRL1_TGT_CURR;
+ raw_to_constant_charge_current(axp20x_batt, &val->intval);
+
+ break;
+
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_INPUT_STATUS,
+ ®);
+ if (ret)
+ return ret;
+
+ if (reg & AXP20X_PWR_STATUS_BAT_CHARGING)
+ chan = axp20x_batt->batt_chrg_i;
+ else
+ chan = axp20x_batt->batt_dischrg_i;
+
+ ret = iio_read_channel_processed(chan, &val->intval);
+ if (ret)
+ return ret;
+
+ /* IIO framework gives mA but Power Supply framework gives uA */
+ val->intval *= 1000;
+ break;
+
+ case POWER_SUPPLY_PROP_CAPACITY:
+ /* When no battery is present, return capacity is 100% */
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_PWR_OP_MODE,
+ ®);
+ if (ret)
+ return ret;
+
+ if (!(reg & AXP20X_PWR_OP_BATT_PRESENT)) {
+ val->intval = 100;
+ return 0;
+ }
+
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_FG_RES, ®);
+ if (ret)
+ return ret;
+
+ if (axp20x_batt->axp_id == AXP221_ID &&
+ !(reg & AXP22X_FG_VALID))
+ return -EINVAL;
+
+ /*
+ * Fuel Gauge data takes 7 bits but the stored value seems to be
+ * directly the raw percentage without any scaling to 7 bits.
+ */
+ val->intval = reg & AXP209_FG_PERCENT;
+ break;
+
+ case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
+ if (axp20x_batt->axp_id == AXP209_ID)
+ return axp20x_battery_get_max_voltage(axp20x_batt,
+ &val->intval);
+ return axp22x_battery_get_max_voltage(axp20x_batt,
+ &val->intval);
+
+ case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
+ ret = regmap_read(axp20x_batt->regmap, AXP20X_V_OFF, ®);
+ if (ret)
+ return ret;
+
+ val->intval = 2600000 + 100000 * (reg & AXP20X_V_OFF_MASK);
+ break;
+
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ ret = iio_read_channel_processed(axp20x_batt->batt_v,
+ &val->intval);
+ if (ret)
+ return ret;
+
+ /* IIO framework gives mV but Power Supply framework gives uV */
+ val->intval *= 1000;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int axp20x_battery_set_max_voltage(struct axp20x_batt_ps *axp20x_batt,
+ int val)
+{
+ switch (val) {
+ case 4100000:
+ val = AXP20X_CHRG_CTRL1_TGT_4_1V;
+ break;
+
+ case 4150000:
+ if (axp20x_batt->axp_id == AXP221_ID)
+ return -EINVAL;
+
+ val = AXP20X_CHRG_CTRL1_TGT_4_15V;
+ break;
+
+ case 4200000:
+ val = AXP20X_CHRG_CTRL1_TGT_4_2V;
+ break;
+
+ default:
+ /*
+ * AXP20x max voltage can be set to 4.36V and AXP22X max voltage
+ * can be set to 4.22V and 4.24V, but these voltages are too
+ * high for Lithium based batteries (AXP PMICs are supposed to
+ * be used with these kinds of battery).
+ */
+ return -EINVAL;
+ }
+
+ return regmap_update_bits(axp20x_batt->regmap, AXP20X_CHRG_CTRL1,
+ AXP20X_CHRG_CTRL1_TGT_VOLT, val);
+}
+
+static int axp20x_set_constant_charge_current(struct axp20x_batt_ps *axp_batt,
+ int charge_current)
+{
+ if (axp_batt->axp_id == AXP209_ID)
+ charge_current = (charge_current - 300000) / 100000;
+ else
+ charge_current = (charge_current - 300000) / 150000;
+
+ if (charge_current > AXP20X_CHRG_CTRL1_TGT_CURR || charge_current < 0)
+ return -EINVAL;
+
+ return regmap_update_bits(axp_batt->regmap, AXP20X_CHRG_CTRL1,
+ AXP20X_CHRG_CTRL1_TGT_CURR, charge_current);
+}
+
+static int axp20x_set_voltage_min_design(struct axp20x_batt_ps *axp_batt,
+ int min_voltage)
+{
+ int val1 = (min_voltage - 2600000) / 100000;
+
+ if (val1 < 0 || val1 > AXP20X_V_OFF_MASK)
+ return -EINVAL;
+
+ return regmap_update_bits(axp_batt->regmap, AXP20X_V_OFF,
+ AXP20X_V_OFF_MASK, val1);
+}
+
+static int axp20x_battery_set_prop(struct power_supply *psy,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct axp20x_batt_ps *axp20x_batt = power_supply_get_drvdata(psy);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN:
+ return axp20x_set_voltage_min_design(axp20x_batt, val->intval);
+
+ case POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN:
+ return axp20x_battery_set_max_voltage(axp20x_batt, val->intval);
+
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+ return axp20x_set_constant_charge_current(axp20x_batt,
+ val->intval);
+
+ default:
+ return -EINVAL;
+ }
+}
+
+static enum power_supply_property axp20x_battery_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
+ POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
+ POWER_SUPPLY_PROP_CAPACITY,
+};
+
+static int axp20x_battery_prop_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
+{
+ return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN ||
+ psp == POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN ||
+ psp == POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT;
+}
+
+static const struct power_supply_desc axp20x_batt_ps_desc = {
+ .name = "axp20x-battery",
+ .type = POWER_SUPPLY_TYPE_BATTERY,
+ .properties = axp20x_battery_props,
+ .num_properties = ARRAY_SIZE(axp20x_battery_props),
+ .property_is_writeable = axp20x_battery_prop_writeable,
+ .get_property = axp20x_battery_get_prop,
+ .set_property = axp20x_battery_set_prop,
+};
+
+static const struct of_device_id axp20x_battery_ps_id[] = {
+ {
+ .compatible = "x-powers,axp209-battery-power-supply",
+ .data = (void *)AXP209_ID,
+ }, {
+ .compatible = "x-powers,axp221-battery-power-supply",
+ .data = (void *)AXP221_ID,
+ }, { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, axp20x_battery_ps_id);
+
+static int axp20x_power_probe(struct platform_device *pdev)
+{
+ struct axp20x_batt_ps *axp20x_batt;
+ struct power_supply_config psy_cfg = {};
+
+ if (!of_device_is_available(pdev->dev.of_node))
+ return -ENODEV;
+
+ axp20x_batt = devm_kzalloc(&pdev->dev, sizeof(*axp20x_batt),
+ GFP_KERNEL);
+ if (!axp20x_batt)
+ return -ENOMEM;
+
+ axp20x_batt->dev = &pdev->dev;
+
+ axp20x_batt->batt_v = devm_iio_channel_get(&pdev->dev, "batt_v");
+ if (IS_ERR(axp20x_batt->batt_v)) {
+ if (PTR_ERR(axp20x_batt->batt_v) == -ENODEV)
+ return -EPROBE_DEFER;
+ return PTR_ERR(axp20x_batt->batt_v);
+ }
+
+ axp20x_batt->batt_chrg_i = devm_iio_channel_get(&pdev->dev,
+ "batt_chrg_i");
+ if (IS_ERR(axp20x_batt->batt_chrg_i)) {
+ if (PTR_ERR(axp20x_batt->batt_chrg_i) == -ENODEV)
+ return -EPROBE_DEFER;
+ return PTR_ERR(axp20x_batt->batt_chrg_i);
+ }
+
+ axp20x_batt->batt_dischrg_i = devm_iio_channel_get(&pdev->dev,
+ "batt_dischrg_i");
+ if (IS_ERR(axp20x_batt->batt_dischrg_i)) {
+ if (PTR_ERR(axp20x_batt->batt_dischrg_i) == -ENODEV)
+ return -EPROBE_DEFER;
+ return PTR_ERR(axp20x_batt->batt_dischrg_i);
+ }
+
+ axp20x_batt->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ platform_set_drvdata(pdev, axp20x_batt);
+
+ psy_cfg.drv_data = axp20x_batt;
+ psy_cfg.of_node = pdev->dev.of_node;
+
+ axp20x_batt->axp_id = (uintptr_t)of_device_get_match_data(&pdev->dev);
+
+ axp20x_batt->batt = devm_power_supply_register(&pdev->dev,
+ &axp20x_batt_ps_desc,
+ &psy_cfg);
+ if (IS_ERR(axp20x_batt->batt)) {
+ dev_err(&pdev->dev, "failed to register power supply: %ld\n",
+ PTR_ERR(axp20x_batt->batt));
+ return PTR_ERR(axp20x_batt->batt);
+ }
+
+ return 0;
+}
+
+static struct platform_driver axp20x_batt_driver = {
+ .probe = axp20x_power_probe,
+ .driver = {
+ .name = "axp20x-battery-power-supply",
+ .of_match_table = axp20x_battery_ps_id,
+ },
+};
+
+module_platform_driver(axp20x_batt_driver);
+
+MODULE_DESCRIPTION("Battery power supply driver for AXP20X and AXP22X PMICs");
+MODULE_AUTHOR("Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>");
+MODULE_LICENSE("GPL");
--
2.9.3
--
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 related
* [PATCH v5 1/7] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405081059.1684-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
This patch adds the DT binding documentation for the battery power
supply which gets various data from the PMIC, such as the battery status
(charging, discharging, full, dead), current max limit, current current,
battery capacity (in percentage), voltage max and min limits, current
voltage and battery capacity (in Ah).
Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
v5:
- removed DT property example from monitored-battery,
v4:
- added monitored-battery optional property,
- added example with battery,
v3:
- removed constant charge current property, now should use the WIP
battery framework,
v2:
- changed DT node name from ac_power_supply to ac-power-supply,
- removed io-channels and io-channel-names from DT (the IIO mapping is
done in the IIO ADC driver now),
- added x-powers,constant-charge-current property to set the maximal
default constant current charge of the battery,
.../bindings/power/supply/axp20x_battery.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
new file mode 100644
index 0000000..63826fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
@@ -0,0 +1,28 @@
+AXP20x and AXP22x battery power supply
+
+Required Properties:
+ - compatible, one of:
+ "x-powers,axp209-battery-power-supply"
+ "x-powers,axp221-battery-power-supply"
+
+Optional properties:
+ - monitored-battery, phandle to a fixed battery
+
+This node is a subnode of the axp20x/axp22x PMIC.
+
+The AXP20X and AXP22X can read the battery voltage, charge and discharge
+currents of the battery by reading ADC channels from the AXP20X/AXP22X
+ADC.
+
+Example:
+
+battery: battery {
+ compatible = "fixed-battery";
+};
+
+&axp209 {
+ battery_power_supply: battery-power-supply {
+ compatible = "x-powers,axp209-battery-power-supply";
+ monitored-battery = <&battery>;
+ }
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v5 0/7] add support for AXP20X and AXP22X battery power supply driver
From: Quentin Schulz @ 2017-04-05 8:10 UTC (permalink / raw)
To: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, icenowy-ymACFijhrKM
Cc: Quentin Schulz, liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
This is a series for AXP20X and AXP22X battery power supply without the
support for changing constant charge current from the DT. The patches for
supporting the constant charge current from DT are ready and will be sent
once the battery framework required to make this work has been merged.
Quote from v4 cover letter:
The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose
information and data of the various power supplies they support such as
ACIN, battery and VBUS. For example, they expose the current battery
voltage, charge or discharge, as well as ACIN and VBUS current voltages
and currents, internal PMIC temperature and ADC on 2 different GPIOs
when in the right mode (for the AXP209 only).
The ACIN power supply driver is added by this patch. The AXP20X and
AXP22X can both read the status and the "usability" of the power supply
but only the AXP209 will be able to tell the current current and voltage
of the power supply by reading ADC channels. It is simply not supported
by the AXP22X PMICs.
The battery power supply driver is also added by this patch. The AXP20X
and AXP22X share most of their behaviour but have slight variations. The
allowed target voltages for battery charging are not the same, the
AXP22X PMIC are able to tell if the battery percentage computed by the
PMIC is trustworthy and they have different formulas for computing max
current for battery power supply. The driver is able to give the current
voltage and current of the battery (be it charging or discharging), the
maximal and minimal voltage and maximal current allowed for the battery,
whether the battery is present and usable and its capacity. It will get
the battery current current and voltage by reading the ADC channels. The
PMIC allows maximal voltages (4.36V for AXP20X and 4.22V and 4.24V for
AXP22X) that should not be used with Lithium-based batteries and since
this PMIC is supposed to be used with Lithium-based batteries, they have
been disabled. The values returned by the ADC driver are multipled by
1000 to scale from the mV returned by the ADC to the uV expected by the
power supply framework.
This series of patch adds DT bindings for ACIN power supply, ADC and
battery power supply drivers for AXP20X and AXP22X PMICs and their
documentation. It also enables the supported power supplies for the
Nextthing Co. CHIP and Sinlinx SinA33 boards.
The different drivers are also added to the MFD cells of the AXP20X and
AXP22X cells and the writeable and volatile regs updated to work with
the newly added drivers.
This series of patch is based on a previous upstreaming attempt done by
Bruno Prémont few months ago. It differs in three points: the ADC
driver does not tell the battery temperature (TS_IN) as I do not have a
board to test it with, it does not tell the instantaneous battery power
as it returns crazy values for me and finally no support for OCV curves
for the battery.
You can test these patches from this repo and branch:
https://github.com/QSchulz/linux/tree/axp2xx_adc_batt_ac_v4
v4:
- added the ability to set maximum constant charge current from sysfs,
- added a warning when setting a higher than current maximum constant charge
current,
- set default to minimum possible value for current and maximum constant charge
current when no battery DT is present or invalid battery DT,
- fixed a forgotten custom formula to compute maximum constant charge current
for AXP22X,
- automatically lower the current constant charge current when it is higher
than the maximum constant charge current about to be set,
v3:
- Removed DT property for constant charge current in favor of the WIP
battery framework as requested by Sebastian Reichel,
- Using a simple if condition instead of a switch in the ADC driver,
- Fixed error handling in ADC driver's probe,
- Fixed missing call to iio_map_array_unregister in the ADC driver's
remove,
- Removed ADC driver's DT node and documentation,
- Merged IIO channel mapping patches into the original ADC driver
patch,
- Removed `adding V-OFF to writeable reg' patch as it's already in
writeable reg range,
v2:
- Some registers' name have been changed to better reflect their
purpose,
- Make VBUS power supply driver use IIO channels when AXP ADC driver is
enabled, but fall back on previous behavior when disabled. This is made
to avoid the ADC driver overwritting registers for VBUS power supply
ADC when removed,
- Removed useless adding of data registers to volatile registers,
- Reordered IIO channels, now grouped by same part of the PMIC (e.g.
voltage and current of the battery have the same index in different
IIO types),
- Added structures for specific data instead of matching on IDs,
- Switched from DT IIO channels mapping to iio_map structures IIO
channels mapping,
Quentin
Quentin Schulz (7):
dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
power: supply: add battery driver for AXP20X and AXP22X PMICs
mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver
ARM: dtsi: axp209: add battery power supply subnode
ARM: dtsi: axp22x: add battery power supply subnode
ARM: dts: sun8i: sina33: enable battery power supply subnode
ARM: sun5i: chip: enable battery power supply subnode
.../bindings/power/supply/axp20x_battery.txt | 28 ++
arch/arm/boot/dts/axp209.dtsi | 5 +
arch/arm/boot/dts/axp22x.dtsi | 5 +
arch/arm/boot/dts/sun5i-r8-chip.dts | 4 +
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 +
drivers/mfd/axp20x.c | 9 +
drivers/power/supply/Kconfig | 12 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/axp20x_battery.c | 502 +++++++++++++++++++++
9 files changed, 570 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
create mode 100644 drivers/power/supply/axp20x_battery.c
--
2.9.3
--
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: Re: [PATCH v3 04/11] drm/sun4i: abstract the layer type
From: Maxime Ripard @ 2017-04-05 8:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, linux-arm-kernel, Sean Paul, linux-sunxi,
Rob Herring, linux-kernel, devicetree, Jernej Skrabec, linux-clk,
dri-devel
In-Reply-To: <20170405052325.98B958A2E94-Y9/x5g2N/Tt0ykcd9G8QkxTxI0vvWBSX@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 7199 bytes --]
On Wed, Apr 05, 2017 at 01:23:15PM +0800, Icenowy Zheng wrote:
>
> 2017年4月5日 10:27于 Chen-Yu Tsai <wens@csie.org>写道：
> >
> > On Wed, Apr 5, 2017 at 3:53 AM, Icenowy Zheng <icenowy@aosc.io> wrote:
> > >
> > >
> > > 在 2017年04月05日 03:28, Sean Paul 写道:
> > >>
> > >> On Thu, Mar 30, 2017 at 03:46:06AM +0800, Icenowy Zheng wrote:
> > >>>
> > >>> As we are going to add support for the Allwinner DE2 Mixer in sun4i-drm
> > >>> driver, we will finally have two types of layer.
> > >>>
> > >>> Abstract the layer type to void * and a ops struct, which contains the
> > >>> only function used by crtc -- get the drm_plane struct of the layer.
> > >>>
> > >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > >>> ---
> > >>> Refactored patch in v3.
> > >>>
> > >>> drivers/gpu/drm/sun4i/sun4i_crtc.c | 19 +++++++++++--------
> > >>> drivers/gpu/drm/sun4i/sun4i_crtc.h | 3 ++-
> > >>> drivers/gpu/drm/sun4i/sun4i_layer.c | 19 ++++++++++++++++++-
> > >>> drivers/gpu/drm/sun4i/sun4i_layer.h | 2 +-
> > >>> drivers/gpu/drm/sun4i/sunxi_layer.h | 17 +++++++++++++++++
> > >>> 5 files changed, 49 insertions(+), 11 deletions(-)
> > >>> create mode 100644 drivers/gpu/drm/sun4i/sunxi_layer.h
> > >>>
> > >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > >>> b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > >>> index 3c876c3a356a..33854ee7f636 100644
> > >>> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > >>> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > >>> @@ -29,6 +29,7 @@
> > >>> #include "sun4i_crtc.h"
> > >>> #include "sun4i_drv.h"
> > >>> #include "sun4i_layer.h"
> > >>> +#include "sunxi_layer.h"
> > >>> #include "sun4i_tcon.h"
> > >>>
> > >>> static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
> > >>> @@ -149,7 +150,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device
> > >>> *drm,
> > >>> scrtc->tcon = tcon;
> > >>>
> > >>> /* Create our layers */
> > >>> - scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
> > >>> + scrtc->layers = (void **)sun4i_layers_init(drm, scrtc);
> > >>> if (IS_ERR(scrtc->layers)) {
> > >>> dev_err(drm->dev, "Couldn't create the planes\n");
> > >>> return NULL;
> > >>> @@ -157,14 +158,15 @@ struct sun4i_crtc *sun4i_crtc_init(struct
> > >>> drm_device *drm,
> > >>>
> > >>> /* find primary and cursor planes for drm_crtc_init_with_planes
> > >>> */
> > >>> for (i = 0; scrtc->layers[i]; i++) {
> > >>> - struct sun4i_layer *layer = scrtc->layers[i];
> > >>> + void *layer = scrtc->layers[i];
> > >>> + struct drm_plane *plane =
> > >>> scrtc->layer_ops->get_plane(layer);
> > >>>
> > >>> - switch (layer->plane.type) {
> > >>> + switch (plane->type) {
> > >>> case DRM_PLANE_TYPE_PRIMARY:
> > >>> - primary = &layer->plane;
> > >>> + primary = plane;
> > >>> break;
> > >>> case DRM_PLANE_TYPE_CURSOR:
> > >>> - cursor = &layer->plane;
> > >>> + cursor = plane;
> > >>> break;
> > >>> default:
> > >>> break;
> > >>> @@ -190,10 +192,11 @@ struct sun4i_crtc *sun4i_crtc_init(struct
> > >>> drm_device *drm,
> > >>> /* Set possible_crtcs to this crtc for overlay planes */
> > >>> for (i = 0; scrtc->layers[i]; i++) {
> > >>> uint32_t possible_crtcs =
> > >>> BIT(drm_crtc_index(&scrtc->crtc));
> > >>> - struct sun4i_layer *layer = scrtc->layers[i];
> > >>> + void *layer = scrtc->layers[i];
> > >>> + struct drm_plane *plane =
> > >>> scrtc->layer_ops->get_plane(layer);
> > >>>
> > >>> - if (layer->plane.type == DRM_PLANE_TYPE_OVERLAY)
> > >>> - layer->plane.possible_crtcs = possible_crtcs;
> > >>> + if (plane->type == DRM_PLANE_TYPE_OVERLAY)
> > >>> + plane->possible_crtcs = possible_crtcs;
> > >>> }
> > >>>
> > >>> return scrtc;
> > >>> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h
> > >>> b/drivers/gpu/drm/sun4i/sun4i_crtc.h
> > >>> index 230cb8f0d601..a4036ee44cf8 100644
> > >>> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.h
> > >>> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h
> > >>> @@ -19,7 +19,8 @@ struct sun4i_crtc {
> > >>>
> > >>> struct sun4i_backend *backend;
> > >>> struct sun4i_tcon *tcon;
> > >>> - struct sun4i_layer **layers;
> > >>> + void **layers;
> > >>> + const struct sunxi_layer_ops *layer_ops;
> > >>
> > >>
> > >> I think you should probably take a different approach to abstract the
> > >> layer
> > >> type. How about creating
> > >>
> > >> struct sunxi_layer {
> > >> struct drm_plane plane;
> > >> }
> > >>
> > >> base and then subclassing that for sun4i and sun8i? By doing this you can
> > >> avoid
> > >> the nasty casting and you can also get rid of the get_plane() hook and
> > >> layer_ops.
> > >
> > >
> > > For the situation that using ** things are easily to get weird.
> >
> > That code could be reworked, by initializing the layers directly within
> > the crtc init code. If you look at rockchip's drm driver, you'll see
> > they do this. There is a good reason to do it this way, as you need
> > to first create the primary and cursor layers, pass them in when you
> > create the crtc, then initialize any additional layers with the
> > possible_crtcs bitmap.
>
> But furthurly maybe more layers will be created for DE2 mixer, and
> may even depends on mixer type (On A83T/H3/A64/H5 mixer1 has fewer
> channel than mixer0).
You'll always have one primary and one cursor plane, no matter how
much planes you support.
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@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Re: [PATCH 10/11] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Maxime Ripard @ 2017-04-05 8:08 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, linux-kernel, devicetree-u79uwXL29TY76Z2rM5mHXA,
Lee Jones, Liam Girdwood,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Chen-Yu Tsai
In-Reply-To: <20170405061552.C15201033DF-Y9/x5g2N/Tt0ykcd9G8QkxTxI0vvWBSX@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4689 bytes --]
On Wed, Apr 05, 2017 at 02:15:43PM +0800, Icenowy Zheng wrote:
>
> 2017年4月5日 14:13于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Wed, Apr 05, 2017 at 02:01:44AM +0800, Icenowy Zheng wrote:
> > > Add support of AXP803 regulators in the Pine64 device tree, in order to
> > > enable many future functionalities, e.g. Wi-Fi.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> > > ---
> > > .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
> > > 1 file changed, 109 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > > index 2132d8e6cb3d..7da074f95065 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> > > @@ -106,6 +106,115 @@
> > > };
> > > };
> > >
> > > +#include "axp803.dtsi"
> > > +
> > > +®_aldo1 {
> > > + regulator-min-microvolt = <2800000>;
> > > + regulator-max-microvolt = <2800000>;
> > > + regulator-name = "vcc-csi";
> > > +};
> > > +
> > > +®_aldo2 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-pl";
> > > +};
> > > +
> > > +®_aldo3 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <2700000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-pll-avcc";
> > > +};
> > > +
> > > +®_dc1sw {
> > > + regulator-name = "vcc-phy";
> > > +};
> > > +
> > > +®_dcdc1 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-3v3";
> > > +};
> > > +
> > > +®_dcdc2 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1000000>;
> > > + regulator-max-microvolt = <1300000>;
> > > + regulator-name = "vdd-cpux";
> > > +};
> > > +
> > > +/* DCDC3 is polyphased with DCDC2 */
> > > +
> > > +®_dcdc5 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1500000>;
> > > + regulator-max-microvolt = <1500000>;
> > > + regulator-name = "vcc-dram";
> > > +};
> > > +
> > > +®_dcdc6 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1100000>;
> > > + regulator-max-microvolt = <1100000>;
> > > + regulator-name = "vdd-sys";
> > > +};
> > > +
> > > +®_dldo1 {
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-hdmi";
> > > +};
> > > +
> > > +®_dldo2 {
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-mipi";
> > > +};
> > > +
> > > +®_dldo3 {
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "avdd-csi";
> > > +};
> > > +
> > > +®_dldo4 {
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-name = "vcc-wifi";
> > > +};
> > > +
> > > +®_eldo1 {
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-name = "cpvdd";
> > > +};
> > > +
> > > +®_eldo3 {
> > > + regulator-min-microvolt = <1800000>;
> > > + regulator-max-microvolt = <1800000>;
> > > + regulator-name = "vdd-1v8-csi";
> > > +};
> > > +
> > > +®_fldo1 {
> > > + regulator-min-microvolt = <1200000>;
> > > + regulator-max-microvolt = <1200000>;
> > > + regulator-name = "vcc-1v2-hsic";
> > > +};
> > > +
> > > +®_fldo2 {
> > > + regulator-always-on;
> > > + regulator-min-microvolt = <1100000>;
> > > + regulator-max-microvolt = <1100000>;
> > > + regulator-name = "vdd-cpus";
> > > +};
> >
> > Why do you need to always power the AR100 on?
>
> It's for CPUS power domain, not the AR100 processor.
>
> Kill it will lead to instantly system hang.
What are you calling CPUS then?
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: cpu of_node links broken
From: Benjamin Herrenschmidt @ 2017-04-05 7:58 UTC (permalink / raw)
To: Wesley Terpstra; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAMgXwThRqAO0vG0QVC7LYO2Srf9inh+osw7+u21abRVhH0LDSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2017-04-04 at 23:49 -0700, Wesley Terpstra wrote:
> On Tue, Apr 4, 2017 at 11:41 PM, Benjamin Herrenschmidt
> <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
> > > [ 0.010000] cpu cpu0: Error -2 creating of_node link
> >
> > Interesting. I've never seen that error, I wonder if that's because
> > we fail to link the CPU to an OF node to begin with on our
> > platforms.
>
> You can find quite a few dmesg traces on google that include the
> warning. It affects at least nios2, microblaze and riscv.
>
> It's because the 'sd' pointer in the of_node's kobject is null, which
> causes sysfs_do_create_link_sd to return -ENOENT. AFAICT, it's null
> because the device tree nodes have not yet been linked into sysfs;
> that is what of_core_init() does.
>
> > Devices might try to create symlinks to device-tree nodes,
> > thus all devices that have OF node linkages should be created
> > after of_core_init() has been called.
>
> Your proposed patch fixes the warning for me on riscv.
Thanks. I'll smoke-test it on powerpc tomorrow (and figure out why we
don't hit the warning) and submit it formally to Greg.
Remind me if I forget, I'm rather swamped these days :)
Cheers,
Ben.
--
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] drm: rcar-du: Document the vsps property in the DT bindings
From: Geert Uytterhoeven @ 2017-04-05 7:54 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Laurent Pinchart, Sergei Shtylyov, devicetree@vger.kernel.org,
DRI Development, Linux-Renesas
In-Reply-To: <CAMuHMdWSuz79mdHLuT4jDQsNvecFck21aBNLOrs5JHmMXnyTCQ@mail.gmail.com>
Hi Laurent,
On Fri, Mar 31, 2017 at 11:21 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Mar 31, 2017 at 11:19 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
>>> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
>>> > The property is used by the driver but is missing from the DT bindings.
>>> > Document it.
>>> >
>>> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>> > Signed-off-by: Laurent Pinchart
>>> > <laurent.pinchart+renesas@ideasonboard.com>
>>> > ---
>>> > Documentation/devicetree/bindings/display/renesas,du.txt | 5 +++++
>>> > 1 file changed, 5 insertions(+)
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>>> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
>>> > 1a02f099a0ff..cf34893a1b53 100644
>>> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>>> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>>> >
>>> > @@ -36,6 +36,11 @@ Required Properties:
>>> > When supplied they must be named "dclkin.x" with "x" being the
>>> > input
>>> > clock numerical index.
>>> >
>>> > +Optional Properties:
>>> > +
>>> > + - vsps: A list of phandles to the VSP nodes that handle the memory
>>> > + interfaces for the DU channels (Gen3 only).
>>>
>>> ", one per channel"?
>>>
>>> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
>>
>> How about making it mandatory on Gen2 as well ? The VSPs are there, even if
>> the driver doesn't use them, it makes sense to describe the connection. Of
>
> Fine for me, as this is hardware description.
>
>> course the driver will treat the property as optional for backward
>> compatibility.
>
> OK.
Will you do this as an incremental update?
I noticed the initial version is now in drm-next.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts
From: Icenowy Zheng @ 2017-04-05 7:33 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Kishon Vijay Abraham I, linux-arm-kernel,
devicetree, linux-kernel, linux-sunxi
In-Reply-To: <20170405072631.ou4e5gafvagwpykq@lukather>
在 2017年04月05日 15:26, Maxime Ripard 写道:
> On Wed, Apr 05, 2017 at 03:17:19PM +0800, Icenowy Zheng wrote:
>>
>>
>> 在 2017年04月05日 15:15, Maxime Ripard 写道:
>>> On Wed, Apr 05, 2017 at 02:45:17AM +0800, Icenowy Zheng wrote:
>>>> As we added USB0 route auto switching support for A64, add related
>>>> device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
>>>> pmu0 memory area for PHY).
>>>>
>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>> ---
>>>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 ++++++++++++++++++++++++
>>>> 1 file changed, 24 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> index 1c64ea2d23f9..a8916df99048 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> @@ -179,8 +179,10 @@
>>>> usbphy: phy@01c19400 {
>>>> compatible = "allwinner,sun50i-a64-usb-phy";
>>>> reg = <0x01c19400 0x14>,
>>>> + <0x01c1a800 0x4>,
>>>> <0x01c1b800 0x4>;
>>>> reg-names = "phy_ctrl",
>>>> + "pmu0",
>>>
>>> This breaks the older DTs, and that property isn't documented.
>>
>> It's already documented.
>>
>> In the H3 dual-route patchset I have already added this.
>>
>> (" * "pmu0" for H3, V3s and A64")
>
> This is not in linux-next then, sorry.
It's already in next-20160405.
>
>> P.S. to be compatible with older DTs, I think I should adjust
>> the phy driver, make it enable dual-route function only when
>> pmu0 is present.
>
> That, or if we're quick enough, we can still add it to 4.11. There's a
> bit of time left.
Thus the device tree binding patch and the DT part of this patchset
should be all pushed to 4.11 .
The device tree binding patch is commit ee73fd7dfc86 ("dt: bindings: add
pmu0 regs for USB PHYs on Allwinner H3/V3s/A64").
>
> Maxime
>
^ 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