* [PATCH v5 06/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-7-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Introduce its_pmsi_init_one() to refactor the code to isolate
> ACPI&DT common code to prepare for ACPI later.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 45 ++++++++++++++++-----------
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index 16587a9..ff72704 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -84,34 +84,43 @@ static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
> {},
> };
>
> -static int __init its_pmsi_init(void)
> +static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
> + const char *name)
> {
> - struct device_node *np;
> struct irq_domain *parent;
>
> + parent = irq_find_matching_fwnode(fwnode, DOMAIN_BUS_NEXUS);
> + if (!parent || !msi_get_domain_info(parent)) {
> + pr_err("%s: unable to locate ITS domain\n", name);
> + return -ENXIO;
> + }
> +
> + if (!platform_msi_create_irq_domain(fwnode, &its_pmsi_domain_info,
> + parent)) {
> + pr_err("%s: unable to create platform domain\n", name);
> + return -ENXIO;
> + }
> +
> + pr_info("Platform MSI: %s domain created\n", name);
> + return 0;
> +}
> +
> +static void __init its_pmsi_of_init(void)
> +{
> + struct device_node *np;
> +
> for (np = of_find_matching_node(NULL, its_device_id); np;
> np = of_find_matching_node(np, its_device_id)) {
> if (!of_property_read_bool(np, "msi-controller"))
> continue;
>
> - parent = irq_find_matching_host(np, DOMAIN_BUS_NEXUS);
> - if (!parent || !msi_get_domain_info(parent)) {
> - pr_err("%s: unable to locate ITS domain\n",
> - np->full_name);
> - continue;
> - }
> -
> - if (!platform_msi_create_irq_domain(of_node_to_fwnode(np),
> - &its_pmsi_domain_info,
> - parent)) {
> - pr_err("%s: unable to create platform domain\n",
> - np->full_name);
> - continue;
> - }
> -
> - pr_info("Platform MSI: %s domain created\n", np->full_name);
> + its_pmsi_init_one(of_node_to_fwnode(np), np->full_name);
> }
> +}
>
> +static int __init its_pmsi_init(void)
> +{
> + its_pmsi_of_init();
> return 0;
> }
> early_initcall(its_pmsi_init);
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 07/14] irqchip: gicv3-its: platform-msi: scan MADT to create platform msi domain
From: Xinwei Kong @ 2016-12-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-8-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the introduction of its_pmsi_init_one(), we can add some code
> on top for ACPI support of platform MSI.
>
> We are scanning the MADT table to get the ITS entry(ies), then use
> the information to create the platform msi domain for devices connect
> to it, just like the PCI MSI for ITS did.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Tested-by: Sinan Kaya <okaya@codeaurora.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 36 +++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its-platform-msi.c b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> index ff72704..0be0437 100644
> --- a/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-platform-msi.c
> @@ -105,6 +105,41 @@ static int __init its_pmsi_init_one(struct fwnode_handle *fwnode,
> return 0;
> }
>
> +#ifdef CONFIG_ACPI
> +static int __init
> +its_pmsi_parse_madt(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> + struct acpi_madt_generic_translator *its_entry;
> + struct fwnode_handle *domain_handle;
> + const char *node_name;
> + int err = -ENXIO;
> +
> + its_entry = (struct acpi_madt_generic_translator *)header;
> + node_name = kasprintf(GFP_KERNEL, "ITS at 0x%lx",
> + (long)its_entry->base_address);
> + domain_handle = iort_find_domain_token(its_entry->translation_id);
> + if (!domain_handle) {
> + pr_err("%s: Unable to locate ITS domain handle\n", node_name);
> + goto out;
> + }
> +
> + err = its_pmsi_init_one(domain_handle, node_name);
> +
> +out:
> + kfree(node_name);
> + return err;
> +}
> +
> +static void __init its_acpi_pmsi_init(void)
> +{
> + acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> + its_pmsi_parse_madt, 0);
> +}
> +#else
> +static inline void its_acpi_pmsi_init(void) { }
> +#endif
> +
> static void __init its_pmsi_of_init(void)
> {
> struct device_node *np;
> @@ -121,6 +156,7 @@ static void __init its_pmsi_of_init(void)
> static int __init its_pmsi_init(void)
> {
> its_pmsi_of_init();
> + its_acpi_pmsi_init();
> return 0;
> }
> early_initcall(its_pmsi_init);
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH 4/6] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222172501.16121-5-gregory.clement@free-electrons.com>
On Thu, Dec 22, 2016 at 6:24 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoCs can handle interrupt through GPIO. However it can
> only manage the edge ones.
>
> The way the interrupt are managed are classical so we can use the generic
> interrupt chip model.
>
> The only unusual "feature" is that many interrupts are connected to the
> parent interrupt controller. But we do not take advantage of this and use
> the chained irq with all of them.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
So this is very simple and should use GPIOLIB_IRQCHIP.
Begin with select GPIOLIB_IRQCHIP in your Kconfig and then look
at conversions such as commit 85ae9e512f437cd09bf61564bdba29ab88bab3e3
("pinctrl: bcm2835: switch to GPIOLIB_IRQCHIP")
for inspiration.
> @@ -64,6 +71,8 @@ struct armada_37xx_pinctrl {
> struct armada_37xx_pin_data *data;
> struct device *dev;
> struct gpio_chip gpio_chip;
> + struct irq_chip irq_chip;
> + struct irq_domain *domain;
You don't need a domain when using GPIOLIB_IRQCHIP
> +static int armada_37xx_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(chip);
> +
> + return irq_create_mapping(info->domain, offset);
> +}
Nor this.
The irqchip code should be pretty much the same but you need to
dereference gpio_chip from chip data and pick the irqchip from
there.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-10-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the platform msi domain created, we can set up the msi domain
> for a platform device when it's probed.
>
> In order to do that, we need to get the domain that the platform
> device connecting to, so the iort_get_platform_device_domain() is
> introduced to retrieve the domain from iort.
>
> After the domain is retrieved, we need a proper way to set the
> domain to paltform device, as some platform devices such as an
> irqchip needs the msi irqdomain to be the interrupt parent domain,
> we need to get irqdomain before platform device is probed but after
> the platform device is allocated, so introduce a callback (pre_add_cb)
> in pdevinfo to prepare firmware related information which is needed
> for device probe, then set the msi domain in that callback.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> ---
> drivers/acpi/acpi_platform.c | 11 +++++++++++
> drivers/acpi/arm64/iort.c | 43 +++++++++++++++++++++++++++++++++++++++++
> drivers/base/platform.c | 3 +++
> include/linux/acpi_iort.h | 3 +++
> include/linux/platform_device.h | 3 +++
> 5 files changed, 63 insertions(+)
>
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index b4c1a6a..5d8d61b4 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -12,6 +12,7 @@
> */
>
> #include <linux/acpi.h>
> +#include <linux/acpi_iort.h>
> #include <linux/device.h>
> #include <linux/err.h>
> #include <linux/kernel.h>
> @@ -48,6 +49,15 @@ static void acpi_platform_fill_resource(struct acpi_device *adev,
> }
>
> /**
> + * acpi_platform_pre_add_cb - callback before platform device is added, to
> + * prepare firmware related information which is needed for device probe
> + */
> +static void acpi_platform_pre_add_cb(struct device *dev)
> +{
> + acpi_configure_pmsi_domain(dev);
> +}
> +
> +/**
> * acpi_create_platform_device - Create platform device for ACPI device node
> * @adev: ACPI device node to create a platform device for.
> * @properties: Optional collection of build-in properties.
> @@ -109,6 +119,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
> pdevinfo.num_res = count;
> pdevinfo.fwnode = acpi_fwnode_handle(adev);
> pdevinfo.properties = properties;
> + pdevinfo.pre_add_cb = acpi_platform_pre_add_cb;
>
> if (acpi_dma_supported(adev))
> pdevinfo.dma_mask = DMA_BIT_MASK(32);
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index bc68d93..6b72fcb 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -527,6 +527,49 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
> return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
> }
>
> +/**
> + * iort_get_platform_device_domain() - Find MSI domain related to a
> + * platform device
> + * @dev: the dev pointer associated with the platform device
> + *
> + * Returns: the MSI domain for this device, NULL otherwise
> + */
> +static struct irq_domain *iort_get_platform_device_domain(struct device *dev)
> +{
> + struct acpi_iort_node *node, *msi_parent;
> + struct fwnode_handle *iort_fwnode;
> + struct acpi_iort_its_group *its;
> +
> + /* find its associated iort node */
> + node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> + iort_match_node_callback, dev);
> + if (!node)
> + return NULL;
> +
> + /* then find its msi parent node */
> + msi_parent = iort_node_get_id(node, NULL, IORT_MSI_TYPE, 0);
> + if (!msi_parent)
> + return NULL;
> +
> + /* Move to ITS specific data */
> + its = (struct acpi_iort_its_group *)msi_parent->node_data;
> +
> + iort_fwnode = iort_find_domain_token(its->identifiers[0]);
> + if (!iort_fwnode)
> + return NULL;
> +
> + return irq_find_matching_fwnode(iort_fwnode, DOMAIN_BUS_PLATFORM_MSI);
> +}
> +
> +void acpi_configure_pmsi_domain(struct device *dev)
> +{
> + struct irq_domain *msi_domain;
> +
> + msi_domain = iort_get_platform_device_domain(dev);
> + if (msi_domain)
> + dev_set_msi_domain(dev, msi_domain);
> +}
> +
> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
> {
> u32 *rid = data;
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index c4af003..3e68f31 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -537,6 +537,9 @@ struct platform_device *platform_device_register_full(
> goto err;
> }
>
> + if (pdevinfo->pre_add_cb)
> + pdevinfo->pre_add_cb(&pdev->dev);
> +
> ret = platform_device_add(pdev);
> if (ret) {
> err:
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index ef99fd52..33f5ac3 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -38,6 +38,7 @@
> /* IOMMU interface */
> void iort_set_dma_mask(struct device *dev);
> const struct iommu_ops *iort_iommu_configure(struct device *dev);
> +void acpi_configure_pmsi_domain(struct device *dev);
> #else
> static inline void acpi_iort_init(void) { }
> static inline bool iort_node_match(u8 type) { return false; }
> @@ -58,6 +59,8 @@ static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
> const struct iommu_ops *iort_iommu_configure(struct device *dev)
> { return NULL; }
> +
> +static inline void acpi_configure_pmsi_domain(struct device *dev) { }
> #endif
>
> #define IORT_ACPI_DECLARE(name, table_id, fn) \
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 98c2a7c..280d366fb 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -74,6 +74,9 @@ struct platform_device_info {
> u64 dma_mask;
>
> struct property_entry *properties;
> +
> + /* preparation callback before the platform device is added */
> + void (*pre_add_cb)(struct device *);
> };
> extern struct platform_device *platform_device_register_full(
> const struct platform_device_info *pdevinfo);
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 10/14] ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-11-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> iort_node_get_id() for now only support NC(named componant)->SMMU
> or NC->ITS cases, we also have other device topology such NC->
> SMMU->ITS, so rework iort_node_get_id() for those cases.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
> drivers/acpi/arm64/iort.c | 59 ++++++++++++++++++++++++++---------------------
> 1 file changed, 33 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 6b72fcb..9b3f268 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -292,22 +292,28 @@ static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
> return status;
> }
>
> -static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> - u32 *rid_out)
> +static int iort_id_single_map(struct acpi_iort_id_mapping *map, u8 type,
> + u32 *rid_out)
> {
> /* Single mapping does not care for input id */
> if (map->flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> if (type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - *rid_out = map->output_base;
> + if (rid_out)
> + *rid_out = map->output_base;
> return 0;
> }
>
> pr_warn(FW_BUG "[map %p] SINGLE MAPPING flag not allowed for node type %d, skipping ID map\n",
> map, type);
> - return -ENXIO;
> }
>
> + return -ENXIO;
> +}
> +
> +static int iort_id_map(struct acpi_iort_id_mapping *map, u8 type, u32 rid_in,
> + u32 *rid_out)
> +{
> if (rid_in < map->input_base ||
> (rid_in >= map->input_base + map->id_count))
> return -ENXIO;
> @@ -324,33 +330,34 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
> struct acpi_iort_node *parent;
> struct acpi_iort_id_mapping *map;
>
> - if (!node->mapping_offset || !node->mapping_count ||
> - index >= node->mapping_count)
> - return NULL;
> -
> - map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> - node->mapping_offset);
> + while (node) {
> + if (!node->mapping_offset || !node->mapping_count ||
> + index >= node->mapping_count)
> + return NULL;
>
> - /* Firmware bug! */
> - if (!map->output_reference) {
> - pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
> - node, node->type);
> - return NULL;
> - }
> + map = ACPI_ADD_PTR(struct acpi_iort_id_mapping, node,
> + node->mapping_offset);
>
> - parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> - map->output_reference);
> + /* Firmware bug! */
> + if (!map->output_reference) {
> + pr_err(FW_BUG "[node %p type %d] ID map has NULL parent reference\n",
> + node, node->type);
> + return NULL;
> + }
>
> - if (!(IORT_TYPE_MASK(parent->type) & type_mask))
> - return NULL;
> + parent = ACPI_ADD_PTR(struct acpi_iort_node, iort_table,
> + map->output_reference);
>
> - if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> - if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> - node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - if (id_out)
> - *id_out = map[index].output_base;
> - return parent;
> + /* go upstream to find its parent */
> + if (!(IORT_TYPE_MASK(parent->type) & type_mask)) {
> + node = parent;
> + continue;
> }
> +
> + if (iort_id_single_map(&map[index], node->type, id_out))
> + break;
> +
> + return parent;
> }
>
> return NULL;
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 11/14] msi: platform: make platform_msi_create_device_domain() ACPI aware
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-12-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the platform msi domain created for ITS, irqchip such as
> mbi-gen connecting ITS, which needs ctreate its own irqdomain.
>
> Fortunately with the platform msi support upstreamed by Marc,
> we just need to add minor code to make it run properly.
>
> platform_msi_create_device_domain() is almost ready for ACPI use
> except of_node_to_fwnode() is for dt only, make it ACPI aware then
> things will work in both DTS and ACPI.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> ---
> drivers/base/platform-msi.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
> index be6a599..035ca3b 100644
> --- a/drivers/base/platform-msi.c
> +++ b/drivers/base/platform-msi.c
> @@ -345,8 +345,7 @@ struct irq_domain *
>
> data->host_data = host_data;
> domain = irq_domain_create_hierarchy(dev->msi_domain, 0, nvec,
> - of_node_to_fwnode(dev->of_node),
> - ops, data);
> + dev->fwnode, ops, data);
> if (!domain)
> goto free_priv;
>
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 12/14] irqchip: mbigen: drop module owner
From: Xinwei Kong @ 2016-12-30 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-13-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Kefeng Wang <wangkefeng.wang@huawei.com>
>
> Module owner will be set by driver core, so drop it.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ma Jun <majun258@huawei.com>
> ---
> drivers/irqchip/irq-mbigen.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 03b79b0..c01ab41 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -293,7 +293,6 @@ static int mbigen_device_probe(struct platform_device *pdev)
> static struct platform_driver mbigen_platform_driver = {
> .driver = {
> .name = "Hisilicon MBIGEN-V2",
> - .owner = THIS_MODULE,
> .of_match_table = mbigen_of_match,
> },
> .probe = mbigen_device_probe,
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 13/14] irqchip: mbigen: introduce mbigen_of_create_domain()
From: Xinwei Kong @ 2016-12-30 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-14-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Kefeng Wang <wangkefeng.wang@huawei.com>
>
> Introduce mbigen_of_create_domain() to consolidate OF related
> code and prepare for ACPI later, no funtional change.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ma Jun <majun258@huawei.com>
> ---
> drivers/irqchip/irq-mbigen.c | 42 +++++++++++++++++++++++++++---------------
> 1 file changed, 27 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index c01ab41..4e11da5 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -236,27 +236,15 @@ static int mbigen_irq_domain_alloc(struct irq_domain *domain,
> .free = irq_domain_free_irqs_common,
> };
>
> -static int mbigen_device_probe(struct platform_device *pdev)
> +static int mbigen_of_create_domain(struct platform_device *pdev,
> + struct mbigen_device *mgn_chip)
> {
> - struct mbigen_device *mgn_chip;
> + struct device *parent;
> struct platform_device *child;
> struct irq_domain *domain;
> struct device_node *np;
> - struct device *parent;
> - struct resource *res;
> u32 num_pins;
>
> - mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
> - if (!mgn_chip)
> - return -ENOMEM;
> -
> - mgn_chip->pdev = pdev;
> -
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(mgn_chip->base))
> - return PTR_ERR(mgn_chip->base);
> -
> for_each_child_of_node(pdev->dev.of_node, np) {
> if (!of_property_read_bool(np, "interrupt-controller"))
> continue;
> @@ -280,6 +268,30 @@ static int mbigen_device_probe(struct platform_device *pdev)
> return -ENOMEM;
> }
>
> + return 0;
> +}
> +
> +static int mbigen_device_probe(struct platform_device *pdev)
> +{
> + struct mbigen_device *mgn_chip;
> + struct resource *res;
> + int err;
> +
> + mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
> + if (!mgn_chip)
> + return -ENOMEM;
> +
> + mgn_chip->pdev = pdev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + if (IS_ERR(mgn_chip->base))
> + return PTR_ERR(mgn_chip->base);
> +
> + err = mbigen_of_create_domain(pdev, mgn_chip);
> + if (err)
> + return err;
> +
> platform_set_drvdata(pdev, mgn_chip);
> return 0;
> }
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH v5 14/14] irqchip: mbigen: Add ACPI support
From: Xinwei Kong @ 2016-12-30 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-15-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> With the preparation of platform msi support and interrupt producer
> in DSDT, we can add mbigen ACPI support now.
>
> We are using _PRS methd to indicate number of irq pins instead
> of num_pins in DT to avoid _DSD usage in this case.
>
> For mbi-gen,
> Device(MBI0) {
> Name(_HID, "HISI0152")
> Name(_UID, Zero)
> Name(_CRS, ResourceTemplate() {
> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
> })
>
> Name (_PRS, ResourceTemplate() {
> Interrupt(ResourceProducer,...) {12,14,....}
> })
> }
>
> For devices,
>
> Device(COM0) {
> Name(_HID, "ACPIIDxx")
> Name(_UID, Zero)
> Name(_CRS, ResourceTemplate() {
> Memory32Fixed(ReadWrite, 0xb0030000, 0x10000)
> Interrupt(ResourceConsumer,..., "\_SB.MBI0") {12}
> })
> }
>
> With the helpe of platform msi and interrupt producer, then devices
> will get the virq from mbi-gen's irqdomain.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ma Jun <majun258@huawei.com>
> ---
> drivers/irqchip/irq-mbigen.c | 70 ++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 67 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 4e11da5..17d35fa 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -16,6 +16,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/acpi.h>
> #include <linux/interrupt.h>
> #include <linux/irqchip.h>
> #include <linux/module.h>
> @@ -180,7 +181,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
> unsigned long *hwirq,
> unsigned int *type)
> {
> - if (is_of_node(fwspec->fwnode)) {
> + if (is_of_node(fwspec->fwnode) || is_acpi_device_node(fwspec->fwnode)) {
> if (fwspec->param_count != 2)
> return -EINVAL;
>
> @@ -271,6 +272,54 @@ static int mbigen_of_create_domain(struct platform_device *pdev,
> return 0;
> }
>
> +#ifdef CONFIG_ACPI
> +static acpi_status mbigen_acpi_process_resource(struct acpi_resource *ares,
> + void *context)
> +{
> + struct acpi_resource_extended_irq *ext_irq;
> + u32 *num_irqs = context;
> +
> + switch (ares->type) {
> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + ext_irq = &ares->data.extended_irq;
> + *num_irqs += ext_irq->interrupt_count;
> + break;
> + default:
> + break;
> + }
> +
> + return AE_OK;
> +}
> +
> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
> + struct mbigen_device *mgn_chip)
> +{
> + struct irq_domain *domain;
> + u32 num_msis = 0;
> + acpi_status status;
> +
> + status = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), METHOD_NAME__PRS,
> + mbigen_acpi_process_resource, &num_msis);
> + if (ACPI_FAILURE(status) || num_msis == 0)
> + return -EINVAL;
> +
> + domain = platform_msi_create_device_domain(&pdev->dev, num_msis,
> + mbigen_write_msg,
> + &mbigen_domain_ops,
> + mgn_chip);
> + if (!domain)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +#else
> +static int mbigen_acpi_create_domain(struct platform_device *pdev,
> + struct mbigen_device *mgn_chip)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> static int mbigen_device_probe(struct platform_device *pdev)
> {
> struct mbigen_device *mgn_chip;
> @@ -288,9 +337,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
> if (IS_ERR(mgn_chip->base))
> return PTR_ERR(mgn_chip->base);
>
> - err = mbigen_of_create_domain(pdev, mgn_chip);
> - if (err)
> + if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node)
> + err = mbigen_of_create_domain(pdev, mgn_chip);
> + else if (ACPI_COMPANION(&pdev->dev))
> + err = mbigen_acpi_create_domain(pdev, mgn_chip);
> + else
> + err = -EINVAL;
> +
> + if (err) {
> + dev_err(&pdev->dev, "Failed to create mbi-gen@%p irqdomain", mgn_chip->base);
> return err;
> + }
>
> platform_set_drvdata(pdev, mgn_chip);
> return 0;
> @@ -302,10 +359,17 @@ static int mbigen_device_probe(struct platform_device *pdev)
> };
> MODULE_DEVICE_TABLE(of, mbigen_of_match);
>
> +static const struct acpi_device_id mbigen_acpi_match[] = {
> + { "HISI0152", 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(acpi, mbigen_acpi_match);
> +
> static struct platform_driver mbigen_platform_driver = {
> .driver = {
> .name = "Hisilicon MBIGEN-V2",
> .of_match_table = mbigen_of_match,
> + .acpi_match_table = ACPI_PTR(mbigen_acpi_match),
> },
> .probe = mbigen_device_probe,
> };
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH 6/6] ARM64: dts: marvell: armada37xx: add pinctrl definition
From: Linus Walleij @ 2016-12-30 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222172501.16121-7-gregory.clement@free-electrons.com>
On Thu, Dec 22, 2016 at 6:25 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Start to populate the device tree of the Armada 37xx with the pincontrol
> configuration used on the board providing a dts.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +++++++
Maybe you want to take this opportunity to add gpio-line-names = ...;
to the armada 3720 pinctrl/gpiochip nodes?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 08/14] ACPI: ARM64: IORT: rework iort_node_get_id()
From: Xinwei Kong @ 2016-12-30 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482384922-21507-9-git-send-email-guohanjun@huawei.com>
On 2016/12/22 13:35, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> iort_node_get_id() has two output, one is the mapped ids,
> the other is the referenced parent node which is returned
> from the function.
>
> For now we need a API just return its parent node for
> single mapping, so just update this function slightly then
> reuse it later.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> drivers/acpi/arm64/iort.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ab7bae7..bc68d93 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -347,7 +347,8 @@ struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
> if (map[index].flags & ACPI_IORT_ID_SINGLE_MAPPING) {
> if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT ||
> node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
> - *id_out = map[index].output_base;
> + if (id_out)
> + *id_out = map[index].output_base;
> return parent;
> }
> }
Tested-by: Xinwei Kong <kong.kongxinwei@hisilicon.com>
^ permalink raw reply
* [PATCH 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Linus Walleij @ 2016-12-30 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222041328.3303-4-chris.packham@alliedtelesis.co.nz>
On Thu, Dec 22, 2016 at 5:13 AM, Chris Packham
<chris.packham@alliedtelesis.co.nz> wrote:
> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>
> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
> from Marvell.
>
> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Looks good to me, Sebastian and/or Thomas P can you ACK this patch?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: Linus Walleij @ 2016-12-30 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOAejn1zHMFNiGc-wVbbkC1-JFzG3sjnnUJogtCp9EeAkWsV5A@mail.gmail.com>
On Fri, Dec 23, 2016 at 2:09 PM, M'boumba Cedric Madianga
<cedric.madianga@gmail.com> wrote:
> 2016-12-22 20:11 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
>>> @@ -337,6 +350,16 @@
>>> slew-rate = <2>;
>>> };
>>> };
>>> +
>>> + i2c1_pins_b: i2c1 at 0 {
>>> + pins1 {
>>> + pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
>>> + drive-open-drain;
>>> + };
>>> + pins2 {
>>> + pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
>>> + };
>>
>> the second doesn't need the open-drain property? Why?
>
> I thought that open-drain was only needed for SDA line.
> But after double-checking I2C specification, it seems that SDA and SCL
> lines need open-drain or open-collector to perform the wired-AND
> function.
I think I2C SDA/SCL must be open drain by definition.
It also requires pull-up resistors, I guess you have these mounted on the board
so you do not need pull-up from the pin controller?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 5/9] pinctrl: samsung: Move retention control from mach-exynos to the pinctrl driver
From: Linus Walleij @ 2016-12-30 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482495889-6201-6-git-send-email-m.szyprowski@samsung.com>
On Fri, Dec 23, 2016 at 1:24 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Pad retention control after suspend/resume cycle should be done from pin
> controller driver instead of PMU (power management unit) driver to avoid
> possible ordering and logical dependencies. Till now it worked fine only
> because PMU driver registered its sys_ops after pin controller.
>
> This patch moves pad retention control from PMU driver to Exynos pin
> controller driver. This is a preparation for adding new features to Exynos
> pin controller driver, like runtime power management and suspending
> individual pin controllers, which might be a part of some power domain.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Clear and elegant.
I will need an ACK from some ARM SoC person on this so they are
aware that we rip code out of mach-* to pinctrl.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 7/9] pinctrl: samsung: Add property to mark pad state as suitable for power down
From: Linus Walleij @ 2016-12-30 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227153331.jbh7ei6oh3obmnri@kozik-lap>
On Tue, Dec 27, 2016 at 4:33 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Dec 27, 2016 at 11:30:57AM +0100, Marek Szyprowski wrote:
>> Separate sleep state is needed because of the pin control bindings and
>> design.
>>
>> A separate sleep state is required to let pin control client driver (in this
>> case
>> Exynos I2S driver) let to choose when it is okay to switch pads into sleep
>> state and I see no other way to achieve this.
>
> Maybe the pinctrl API should be extended for this? Doing this in DTS
> just for purpose of passing information between drivers (consumer and
> provider) looks odd.
I don't understand what is going on but you are all smart people so I
guess you're right :)
Tell me if I can help clarifying something...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/4] video: ARM CLCD: add support of an optional GPIO to enable panel
From: Vladimir Zapolskiy @ 2016-12-30 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb5Ojs+meXZKwJP3oDcYAnnrXgqBaXmCcgmgxJM=GkBGA@mail.gmail.com>
On 12/30/2016 10:20 AM, Linus Walleij wrote:
> On Wed, Dec 21, 2016 at 4:27 AM, Vladimir Zapolskiy <vz@mleia.com> wrote:
>
>> The change adds handling of "enable-gpios" property of panel-dpi device
>> node used with an ARM CLCD controller, note that the property already has
>> a description in display/panel/panel-dpi.txt documentation and it founds
>> practical usage while describing some panel devices connected to other
>> types of display controllers.
>>
>> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
>
> So as you may have seen I already handle a RESET GPIO in the
> Nomadik TPG110 panel subddriver in
> drivers/video/fbdev/amba-clcd-nomadik.c
>
> So is this all your panel needs?
I need "enable-gpios" property to define a GPIO, which literally enables
(powers up) a panel as a separate attached PCB.
To some extend "enable-gpios" property can be replaced by "power" property
with a phandle to a GPIO voltage regulator.
You may look at drivers/gpu/drm/panel/panel-simple.c, both "enable-gpios"
and "power" properties are defined for simple panels.
>
> I guess it is OK for simple panels.
>
--
With best wishes,
Vladimir
^ permalink raw reply
* [BUG] ARM64: amlogic: gxbb: unhandled level 2 translation fault (11)
From: Neil Armstrong @ 2016-12-30 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c9e66a1f-a53f-9993-dd15-5e566c5f46f0@baylibre.com>
On 12/30/2016 09:51 AM, Neil Armstrong wrote:
> On 12/29/2016 10:18 PM, Heinrich Schuchardt wrote:
>> On 12/29/2016 10:07 AM, Neil Armstrong wrote:
>>> On 12/24/2016 03:00 PM, Heinrich Schuchardt wrote:
>>>> When trying to run sddm on an Hardkernel Odroid C2 I invariably run into the
>>>> translation fault below.
>>>>
>>>> The following mail thread relates this kind of problem to TLB (translation
>>>> lookaside buffer) broadcasting.
>>>>
>>>> https://lkml.org/lkml/2014/4/15/207
>>>>
>>>> [ 3163.014263] sddm[1851]: unhandled level 2 translation fault (11) at 0x00000160, esr 0x82000006
>>>> [ 3163.017287] pgd = ffff80007bf86000
>>>> [ 3163.020589] [00000160] *pgd=000000007a8a3003
>>>> [ 3163.024733] , *pud=000000007be9c003
>>>> [ 3163.028095] , *pmd=0000000000000000
>>>>
>>>>
>>>> [ 3163.033026] CPU: 1 PID: 1851 Comm: sddm Not tainted 4.9.0-next-20161212-r022-arm64 #1
>>>> [ 3163.040831] Hardware name: Hardkernel ODROID-C2 (DT)
>>>> [ 3163.045698] task: ffff80007bc6d780 task.stack: ffff80007c524000
>>>> [ 3163.051563] PC is at 0x160
>>>> [ 3163.054231] LR is at 0xffff9a9fbc98
>>>> [ 3163.057686] pc : [<0000000000000160>] lr : [<0000ffff9a9fbc98>] pstate: 40000000
>>>> [ 3163.065022] sp : 0000ffffd7180130
>>>> [ 3163.068281] x29: 0000ffffd7180130 x28: 0000ffffd7180288
>>>> [ 3163.073538] x27: 0000ffff9aa94000 x26: 0000000000000001
>>>> [ 3163.078798] x25: 0000000000000000 x24: 0000ffffd7180410
>>>> [ 3163.084060] x23: 000000000e0c2190 x22: 000000000e0ca5c0
>>>> [ 3163.089322] x21: 0000ffff9ac35000 x20: 0000000000454fa9
>>>> [ 3163.094583] x19: 0000000000454fa8 x18: 000000000e0b5938
>>>> [ 3163.099843] x17: 0000ffff9a3f2988 x16: 0000ffff9ac36aa0
>>>> [ 3163.105105] x15: 0000000000000000 x14: 0000000000000000
>>>> [ 3163.110367] x13: 6d00640064007300 x12: 0800000005000000
>>>> [ 3163.115627] x11: 0000040000000000 x10: 0000a00000000000
>>>> [ 3163.120889] x9 : 00003fffffffffff x8 : 0000000000000000
>>>> [ 3163.126150] x7 : 000000000e0cb520 x6 : 0000000000454fc0
>>>> [ 3163.131412] x5 : 0000ffffd717ffd8 x4 : 000000000e0cb510
>>>> [ 3163.136680] x3 : 0000000000000004 x2 : f2f9022b551b3900
>>>> [ 3163.141935] x1 : 0000000000000160 x0 : 000000000e0ca5c0
>>>>
>>>> Best regards
>>>>
>>>> Heinrich Schuchardt
>>>
>>> Hi Heinrich,
>>>
>>> I personally never had this issue even while loading huge applications loke LibreOffice and Gnome environment.
>>>
>>> I will have a look and try to reproduce this issue, can you provide us your configuration and user-space complete use case ?
>>>
>>> Neil
>>>
>>
>> Hello Neil,
>>
>> the kernel is build with
>> https://github.com/xypron/kernel-odroid-c2/tree/f8d565ff755e92fd585f5ae10123ce20abe03968
>>
>> Especially look at the patch directory and config/config-next-20161212.
>>
>> The userland is Debian Stretch with this package:
>> https://packages.debian.org/stretch/sddm
>>
>> The link
>> https://www.spinics.net/lists/arm-kernel/msg550204.html
>> that you mention in a separate mail just links to this very thread due
>> to linux-arm-kernel at lists.infradead.org being in copy.
>>
>> Best regards
>>
>> Heinrich Schuchardt
>>
>
> Hi,
>
> Thanks for the details, but why do you use the next-20161212 tag ? does it work with 4.10-rc1 or previous next tags ?
>
> Neil
>
Hi Heinrich,
I'm able to reproduce the bug using SDMM from Ubuntu running a 4.10-rc1 patched with memory zones :
[ 17.988446] sddm-greeter[2366]: unhandled level 2 translation fault (11) at 0x00000000, esr 0x92000006
[ 17.988451] pgd = ffff80003c3ee000
[ 17.988472] [00000000] *pgd=00000000398bd003
[ 17.988474] , *pud=00000000398bf003
[ 17.990477] , *pmd=0000000000000000
[ 17.990485] CPU: 3 PID: 2366 Comm: sddm-greeter Not tainted 4.10.0-rc1-00004-gd3f812382-dirty #488
[ 17.990487] Hardware name: Amlogic Meson GXBB P200 Development Board (DT)
[ 17.990489] task: ffff80003c160000 task.stack: ffff80003c314000
[ 17.990493] PC is at 0xffffb2999994
[ 17.990495] LR is at 0xffffb299f774
[ 17.990497] pc : [<0000ffffb2999994>] lr : [<0000ffffb299f774>] pstate: 20000000
[ 17.990503] sp : 0000ffffd2d1d5b0
[ 17.990504] x29: 0000ffffd2d1d5b0 x28: 0000ffffad10e010
[ 17.990508] x27: 0000000009c376d0 x26: 0000000000000001
[ 17.990511] x25: 0000ffffb2b67000 x24: 0000ffffad10e010
[ 17.990514] x23: 0000000000000000 x22: 0000000000000000
[ 17.990517] x21: 0000000009c376d0 x20: 0000ffffb2fcdcb8
[ 17.990520] x19: 0000ffffb2b2b000 x18: 0000000009c78450
[ 17.990523] x17: 0000ffffb2b68068 x16: 0000ffffb2022158
[ 17.990526] x15: 0000ffffb2fcd000 x14: 0000000000000000
[ 17.990529] x13: aaaaaaaaaaaaaaab x12: 0000000000010000
[ 17.990532] x11: 0000000000000008 x10: 0000000009c3b980
[ 17.990535] x9 : 0000000009c38c40 x8 : 0000ffffd2d1d4e0
[ 17.990538] x7 : 0000000000000000 x6 : 0000000009c3b998
[ 17.990541] x5 : 0000000009c3b980 x4 : 0000800000000000
[ 17.990544] x3 : 00000000fffffff0 x2 : 0000ffffad10e010
[ 17.990547] x1 : 0000000009c379d8 x0 : 0000000000000000
Looking about other occurrence of such error, it seems it may be a issue from sdmm instead.
I'll continue searching,
Neil
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Sergei Shtylyov @ 2016-12-30 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com>
Hello!
On 12/29/2016 11:45 PM, Nikita Yushchenko wrote:
> It is possible that PCI device supports 64-bit DMA addressing, and thus
> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
Its.
> bridge has limitations on inbound transactions addressing. Example of
> such setup is NVME
Isn't it called NVMe?
> SSD device connected to RCAR PCIe controller.
R=Car.
> Previously there was attempt to handle this via bus notifier: after
> driver is attached to PCI device, bridge driver gets notifier callback,
> and resets dma_mask from there. However, this is racy: PCI device driver
> could already allocate buffers and/or start i/o in probe routine.
> In NVME case, i/o is started in workqueue context, and this race gives
> "sometimes works, sometimes not" effect.
>
> Proper solution should make driver's dma_set_mask() call to fail if host
> bridge can't support mask being set.
>
> This patch makes __swiotlb_dma_supported() to check mask being set for
"To" not needed here.
> PCI device against dma_mask of struct device corresponding to PCI host
> bridge (one with name "pciXXXX:YY"), if that dma_mask is set.
>
> This is the least destructive approach: currently dma_mask of that device
> object is not used anyhow, thus all existing setups will work as before,
> and modification is required only in actually affected components -
> driver of particular PCI host bridge, and dma_map_ops of particular
> platform.
>
> Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> ---
> arch/arm64/mm/dma-mapping.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 290a84f..49645277 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
[...]
> @@ -347,6 +348,16 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
>
> static int __swiotlb_dma_supported(struct device *hwdev, u64 mask)
> {
> +#ifdef CONFIG_PCI
> + if (dev_is_pci(hwdev)) {
> + struct pci_dev *pdev = to_pci_dev(hwdev);
> + struct pci_host_bridge *br = pci_find_host_bridge(pdev->bus);
> +
> + if (br->dev.dma_mask && (*br->dev.dma_mask) &&
> + (mask & (*br->dev.dma_mask)) != mask)
Hum, inner parens not necessary?
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Sergei Shtylyov @ 2016-12-30 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b83c353c-c054-4378-9308-e625c460bdd9@cogentembedded.com>
On 12/30/2016 12:46 PM, Sergei Shtylyov wrote:
>> It is possible that PCI device supports 64-bit DMA addressing, and thus
>> it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host
>
> Its.
>
>> bridge has limitations on inbound transactions addressing. Example of
>> such setup is NVME
>
> Isn't it called NVMe?
>
>> SSD device connected to RCAR PCIe controller.
>
> R=Car.
Sorry, R-Car. :-)
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH v3] ARM: dts: imx6: Disable "weim" node in the dtsi files
From: Fabio Estevam @ 2016-12-30 10:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Commit 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to
dtsi's") causes the following probe error when the weim node is not
present on the board dts (such as imx6q-sabresd):
imx-weim 21b8000.weim: Invalid 'ranges' configuration
imx-weim: probe of 21b8000.weim failed with error -22
There is no need to always enable the "weim" node on mx6. Do the same
as in the other i.MX dtsi files where "weim" is disabled and only gets
enabled on a per dts basis.
All the imx6 weim dts users explicitily provide 'status = "okay"', so
this change has no impact on current imx6 weim users.
If a board does not use the weim driver it will not describe its 'ranges'
property, so simply disable the 'weim' node in the imx6 dtsi files to
avoid such probe error message.
Fixes: 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to dtsi's")
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v2:
- Fix the error message by disabling weim at dtsi level.
arch/arm/boot/dts/imx6qdl.dtsi | 1 +
arch/arm/boot/dts/imx6sl.dtsi | 1 +
arch/arm/boot/dts/imx6sx.dtsi | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63..89b834f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1100,6 +1100,7 @@
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_EIM_SLOW>;
fsl,weim-cs-gpr = <&gpr>;
+ status = "disabled";
};
ocotp: ocotp at 021bc000 {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 4fd6de2..19cbd87 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -900,6 +900,7 @@
reg = <0x021b8000 0x4000>;
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
fsl,weim-cs-gpr = <&gpr>;
+ status = "disabled";
};
ocotp: ocotp at 021bc000 {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 076a30f..10f3330 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -977,6 +977,7 @@
interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_EIM_SLOW>;
fsl,weim-cs-gpr = <&gpr>;
+ status = "disabled";
};
ocotp: ocotp at 021bc000 {
--
2.7.4
^ permalink raw reply related
* [PATCH v2] bus: imx-weim: Fix the "fsl, weim-cs-gpr" lookup method
From: Fabio Estevam @ 2016-12-30 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230064650.GN6177@dragon>
On Fri, Dec 30, 2016 at 4:46 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> "fsl,weim-cs-gpr" is *not* a compatible string, while
> what syscon_regmap_lookup_by_compatible() does is to find a syscon node
> by its compatible string.
Ops, sorry about that. I sent a v3, which hopefully looks better.
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Hanjun Guo @ 2016-12-30 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9aa650ad-a32d-e942-1c6b-b069c8a2b87a@codeaurora.org>
On 2016/12/29 22:44, Sinan Kaya wrote:
> On 12/25/2016 8:31 PM, Hanjun Guo wrote:
>>> A type->setup() would be somewhat cleaner I think, but then it's more
>>> code. Whichever works better I guess. :-)
>> Agree, I will demo the type->setup() way and send out the patch for review,
>> also I find one minor issue for the IORT code, will update that also for next
>> version.
> Can you provide details on what the minor issue is with the IORT code?
It's about the mapping of NC (named component) -> SMMU -> ITS, we can
describe it as two ID mappings:
- NC->SMMU
- NC->ITS
And the code for now can work perfect for such id mappings, but if we
want to support chained mapping NC -> SMMU -> ITS, we need to add
extra code which in my [PATCH v5 10/14] ACPI: ARM64: IORT: rework
iort_node_get_id() for NC->SMMU->ITS case, but I just scanned the first
id mapping for now, I think I need to scan all the id mappings (but seems
single id mappings don't need to do that, I will investigate it more).
Thanks
Hanjun
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Hanjun Guo @ 2016-12-30 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <586072E9.3060609@huawei.com>
Hi Rafael,
On 2016/12/26 9:31, Hanjun Guo wrote:
[cut]
>
> + if (pdevinfo->pre_add_cb)
> + pdevinfo->pre_add_cb(&pdev->dev);
> +
>>>> -> because it looks like this might be done in acpi_platform_notify()
>>>> for platform devices.
>>> It works and I just simply add the code below:
>>>
>>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
>>> index f8d6564..e0cd649 100644
>>> --- a/drivers/acpi/glue.c
>>> +++ b/drivers/acpi/glue.c
>>> @@ -13,6 +13,7 @@
>>> #include <linux/slab.h>
>>> #include <linux/rwsem.h>
>>> #include <linux/acpi.h>
>>> +#include <linux/acpi_iort.h>
>>> #include <linux/dma-mapping.h>
>>>
>>> #include "internal.h"
>>> @@ -315,6 +316,8 @@ static int acpi_platform_notify(struct device *dev)
>>> if (!adev)
>>> goto out;
>>>
>>> + acpi_configure_pmsi_domain(dev);
>>> +
>> But that should apply to platform devices only I suppose?
> Yes, it's only for the platform device.
>
>>> if (type && type->setup)
>>> type->setup(dev);
>>> else if (adev->handler && adev->handler->bind)
>>>
>>> Do you suggesting to configure the msi domain in this way?
>>> or add the function in the type->setup() callback (which needs
>>> to introduce a new acpi bus type)?
>> A type->setup() would be somewhat cleaner I think, but then it's more
>> code. Whichever works better I guess. :-)
> Agree, I will demo the type->setup() way and send out the patch for review,
> also I find one minor issue for the IORT code, will update that also for next
> version.
Just demo the code and find out it's seems to cut the feet to the type->setup() code,
because we need a match function (it's ok) and a find_companion() (we don't need that
and make the code worse because we will call the find_companion callback which it not needed
for platform devices:
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 96983c9..654021d9b 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -138,3 +138,31 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
return pdev;
}
EXPORT_SYMBOL_GPL(acpi_create_platform_device);
+
+static bool platform_acpi_bus_match(struct device *dev)
+{
+ return dev->bus == &platform_bus_type;
+}
+
+static struct acpi_device *platform_acpi_bus_find_companion(struct device *dev)
+{
+ /* demo code, do nothing here */
+ return NULL;
+}
+
+static void platform_acpi_setup(struct device *dev)
+{
+ acpi_configure_pmsi_domain(dev);
+}
+
+static struct acpi_bus_type acpi_platform_bus = {
+ .name = "Platform",
+ .match = platform_acpi_bus_match,
+ .find_companion = platform_acpi_bus_find_companion,
+ .setup = platform_acpi_setup,
+};
+
+int acpi_platform_bus_register(void)
+{
+ return register_acpi_bus_type(&acpi_platform_bus);
+}
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 95855cb..0a0a639 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1199,6 +1199,7 @@ static int __init acpi_init(void)
}
pci_mmcfg_late_init();
+ acpi_platform_bus_register();
acpi_iort_init();
acpi_scan_init();
acpi_ec_init();
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 809b536..1d05f92 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -597,6 +597,8 @@ extern bool acpi_driver_match_device(struct device *dev,
struct platform_device *acpi_create_platform_device(struct acpi_device *,
struct property_entry *);
+int acpi_platform_bus_register(void);
+
#define ACPI_PTR(_ptr) (_ptr)
static inline void acpi_device_set_enumerated(struct acpi_device *adev)
So how about just add the code as below?
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 11e63dd..37a8dfe 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -316,7 +316,8 @@ static int acpi_platform_notify(struct device *dev)
if (!adev)
goto out;
+ if (dev->bus == &platform_bus_type)
+ acpi_configure_pmsi_domain(dev);
if (type && type->setup)
type->setup(dev);
Thanks
Hanjun
^ permalink raw reply related
* [PATCH 2/3][v2] arm64: freescale: ls2080a: Split devicetree for code resuability
From: Shawn Guo @ 2016-12-30 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480325824-14649-3-git-send-email-abhimanyu.saini@nxp.com>
On Mon, Nov 28, 2016 at 03:07:03PM +0530, Abhimanyu Saini wrote:
> LS2088A and LS2080A are similar SoCs with a few differences like
> ARM cores etc.
>
> Reorganize the LS2080A device tree to move the common nodes to:
> - fsl-ls2080a-ls2088a.dtsi
> - fsl-ls2080a-ls2088a-rdb.dts
> - fsl-ls2080a-ls2088a-qds.dts
I do not quite like the naming of these files. Will the following one
be better?
- fsl-ls208xa.dtsi
- fsl-ls208xa-rdb.dtsi
- fsl-ls208xa-qds.dtsi
Also if a DTS file is only to be included by another one, not to
generate a DTB, we name it .dtsi rather than .dts.
Shawn
>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> ---
> .../boot/dts/freescale/fsl-ls2080a-ls2088a-qds.dts | 196 ++++++
> .../boot/dts/freescale/fsl-ls2080a-ls2088a-rdb.dts | 152 +++++
> .../boot/dts/freescale/fsl-ls2080a-ls2088a.dtsi | 727 +++++++++++++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 154 +----
> arch/arm64/boot/dts/freescale/fsl-ls2080a-rdb.dts | 110 +---
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 706 +-------------------
> 6 files changed, 1100 insertions(+), 945 deletions(-)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-ls2088a.dtsi
^ permalink raw reply
* [PATCH v2 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
mx3 driver") the mx3 camera driver has been removed, so remove the camera
support from the board file as well.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes since v1:
- Also remove CSI pins from IOMUX definition
arch/arm/mach-imx/mach-mx31_3ds.c | 160 --------------------------------------
1 file changed, 160 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
index 12b8a52..558e5f8 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -26,16 +26,12 @@
#include <linux/regulator/machine.h>
#include <linux/usb/otg.h>
#include <linux/usb/ulpi.h>
-#include <linux/memblock.h>
-
-#include <media/soc_camera.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
#include <asm/memory.h>
#include <asm/mach/map.h>
-#include <asm/memblock.h>
#include "3ds_debugboard.h"
#include "common.h"
@@ -137,23 +133,6 @@ static int mx31_3ds_pins[] = {
MX31_PIN_HSYNC__HSYNC,
MX31_PIN_FPSHIFT__FPSHIFT,
MX31_PIN_CONTRAST__CONTRAST,
- /* CSI */
- MX31_PIN_CSI_D6__CSI_D6,
- MX31_PIN_CSI_D7__CSI_D7,
- MX31_PIN_CSI_D8__CSI_D8,
- MX31_PIN_CSI_D9__CSI_D9,
- MX31_PIN_CSI_D10__CSI_D10,
- MX31_PIN_CSI_D11__CSI_D11,
- MX31_PIN_CSI_D12__CSI_D12,
- MX31_PIN_CSI_D13__CSI_D13,
- MX31_PIN_CSI_D14__CSI_D14,
- MX31_PIN_CSI_D15__CSI_D15,
- MX31_PIN_CSI_HSYNC__CSI_HSYNC,
- MX31_PIN_CSI_MCLK__CSI_MCLK,
- MX31_PIN_CSI_PIXCLK__CSI_PIXCLK,
- MX31_PIN_CSI_VSYNC__CSI_VSYNC,
- MX31_PIN_CSI_D5__GPIO3_5, /* CMOS PWDN */
- IOMUX_MODE(MX31_PIN_RI_DTE1, IOMUX_CONFIG_GPIO), /* CMOS reset */
/* SSI */
MX31_PIN_STXD4__STXD4,
MX31_PIN_SRXD4__SRXD4,
@@ -162,98 +141,6 @@ static int mx31_3ds_pins[] = {
};
/*
- * Camera support
- */
-static phys_addr_t mx3_camera_base __initdata;
-#define MX31_3DS_CAMERA_BUF_SIZE SZ_8M
-
-#define MX31_3DS_GPIO_CAMERA_PW IOMUX_TO_GPIO(MX31_PIN_CSI_D5)
-#define MX31_3DS_GPIO_CAMERA_RST IOMUX_TO_GPIO(MX31_PIN_RI_DTE1)
-
-static struct gpio mx31_3ds_camera_gpios[] = {
- { MX31_3DS_GPIO_CAMERA_PW, GPIOF_OUT_INIT_HIGH, "camera-power" },
- { MX31_3DS_GPIO_CAMERA_RST, GPIOF_OUT_INIT_HIGH, "camera-reset" },
-};
-
-static const struct mx3_camera_pdata mx31_3ds_camera_pdata __initconst = {
- .flags = MX3_CAMERA_DATAWIDTH_10,
- .mclk_10khz = 2600,
-};
-
-static int __init mx31_3ds_init_camera(void)
-{
- int dma, ret = -ENOMEM;
- struct platform_device *pdev =
- imx31_alloc_mx3_camera(&mx31_3ds_camera_pdata);
-
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
-
- if (!mx3_camera_base)
- goto err;
-
- dma = dma_declare_coherent_memory(&pdev->dev,
- mx3_camera_base, mx3_camera_base,
- MX31_3DS_CAMERA_BUF_SIZE,
- DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
-
- if (!(dma & DMA_MEMORY_MAP))
- goto err;
-
- ret = platform_device_add(pdev);
- if (ret)
-err:
- platform_device_put(pdev);
-
- return ret;
-}
-
-static int mx31_3ds_camera_power(struct device *dev, int on)
-{
- /* enable or disable the camera */
- pr_debug("%s: %s the camera\n", __func__, on ? "ENABLE" : "DISABLE");
- gpio_set_value(MX31_3DS_GPIO_CAMERA_PW, on ? 0 : 1);
-
- if (!on)
- goto out;
-
- /* If enabled, give a reset impulse */
- gpio_set_value(MX31_3DS_GPIO_CAMERA_RST, 0);
- msleep(20);
- gpio_set_value(MX31_3DS_GPIO_CAMERA_RST, 1);
- msleep(100);
-
-out:
- return 0;
-}
-
-static struct i2c_board_info mx31_3ds_i2c_camera = {
- I2C_BOARD_INFO("ov2640", 0x30),
-};
-
-static struct regulator_bulk_data mx31_3ds_camera_regs[] = {
- { .supply = "cmos_vcore" },
- { .supply = "cmos_2v8" },
-};
-
-static struct soc_camera_link iclink_ov2640 = {
- .bus_id = 0,
- .board_info = &mx31_3ds_i2c_camera,
- .i2c_adapter_id = 0,
- .power = mx31_3ds_camera_power,
- .regulators = mx31_3ds_camera_regs,
- .num_regulators = ARRAY_SIZE(mx31_3ds_camera_regs),
-};
-
-static struct platform_device mx31_3ds_ov2640 = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &iclink_ov2640,
- },
-};
-
-/*
* FB support
*/
static const struct fb_videomode fb_modedb[] = {
@@ -410,7 +297,6 @@ static struct regulator_init_data vmmc2_init = {
static struct regulator_consumer_supply vmmc1_consumers[] = {
REGULATOR_SUPPLY("vcore", "spi0.0"),
- REGULATOR_SUPPLY("cmos_2v8", "soc-camera-pdrv.0"),
};
static struct regulator_init_data vmmc1_init = {
@@ -441,22 +327,6 @@ static struct regulator_init_data vgen_init = {
.consumer_supplies = vgen_consumers,
};
-static struct regulator_consumer_supply vvib_consumers[] = {
- REGULATOR_SUPPLY("cmos_vcore", "soc-camera-pdrv.0"),
-};
-
-static struct regulator_init_data vvib_init = {
- .constraints = {
- .min_uV = 1300000,
- .max_uV = 1300000,
- .apply_uV = 1,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE |
- REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = ARRAY_SIZE(vvib_consumers),
- .consumer_supplies = vvib_consumers,
-};
-
static struct mc13xxx_regulator_init_data mx31_3ds_regulators[] = {
{
.id = MC13783_REG_PWGT1SPI, /* Power Gate for ARM core. */
@@ -480,9 +350,6 @@ static struct mc13xxx_regulator_init_data mx31_3ds_regulators[] = {
}, {
.id = MC13783_REG_VGEN, /* Power LCD */
.init_data = &vgen_init,
- }, {
- .id = MC13783_REG_VVIB, /* Power CMOS */
- .init_data = &vvib_init,
},
};
@@ -688,10 +555,6 @@ static const struct imxi2c_platform_data mx31_3ds_i2c0_data __initconst = {
.bitrate = 100000,
};
-static struct platform_device *devices[] __initdata = {
- &mx31_3ds_ov2640,
-};
-
static void __init mx31_3ds_init(void)
{
imx31_soc_init();
@@ -723,14 +586,10 @@ static void __init mx31_3ds_init(void)
static void __init mx31_3ds_late(void)
{
- int ret;
-
mx31_3ds_spi_devs[0].irq = gpio_to_irq(IOMUX_TO_GPIO(MX31_PIN_GPIO1_3));
spi_register_board_info(mx31_3ds_spi_devs,
ARRAY_SIZE(mx31_3ds_spi_devs));
- platform_add_devices(devices, ARRAY_SIZE(devices));
-
mx31_3ds_usbotg_init();
if (otg_mode_host) {
otg_pdata.otg = imx_otg_ulpi_create(ULPI_OTG_DRVVBUS |
@@ -751,17 +610,6 @@ static void __init mx31_3ds_late(void)
"devices on the debug board are unusable.\n");
imx31_add_mxc_mmc(0, &sdhc1_pdata);
-
- /* CSI */
- /* Camera power: default - off */
- ret = gpio_request_array(mx31_3ds_camera_gpios,
- ARRAY_SIZE(mx31_3ds_camera_gpios));
- if (ret) {
- pr_err("Failed to request camera gpios");
- iclink_ov2640.power = NULL;
- }
-
- mx31_3ds_init_camera();
}
static void __init mx31_3ds_timer_init(void)
@@ -769,13 +617,6 @@ static void __init mx31_3ds_timer_init(void)
mx31_clocks_init(26000000);
}
-static void __init mx31_3ds_reserve(void)
-{
- /* reserve MX31_3DS_CAMERA_BUF_SIZE bytes for mx3-camera */
- mx3_camera_base = arm_memblock_steal(MX31_3DS_CAMERA_BUF_SIZE,
- MX31_3DS_CAMERA_BUF_SIZE);
-}
-
MACHINE_START(MX31_3DS, "Freescale MX31PDK (3DS)")
/* Maintainer: Freescale Semiconductor, Inc. */
.atag_offset = 0x100,
@@ -785,6 +626,5 @@ MACHINE_START(MX31_3DS, "Freescale MX31PDK (3DS)")
.init_time = mx31_3ds_timer_init,
.init_machine = mx31_3ds_init,
.init_late = mx31_3ds_late,
- .reserve = mx31_3ds_reserve,
.restart = mxc_restart,
MACHINE_END
--
2.7.4
^ permalink raw reply related
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