* [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
* [PATCH v2 2/6] ARM: mx31moboard-marxbot: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
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/mx31moboard-marxbot.c | 92 ---------------------------------
1 file changed, 92 deletions(-)
diff --git a/arch/arm/mach-imx/mx31moboard-marxbot.c b/arch/arm/mach-imx/mx31moboard-marxbot.c
index 2e895a8..922d491 100644
--- a/arch/arm/mach-imx/mx31moboard-marxbot.c
+++ b/arch/arm/mach-imx/mx31moboard-marxbot.c
@@ -24,8 +24,6 @@
#include <linux/usb/otg.h>
-#include <media/soc_camera.h>
-
#include "common.h"
#include "devices-imx31.h"
#include "ehci.h"
@@ -39,17 +37,6 @@ static unsigned int marxbot_pins[] = {
MX31_PIN_PC_READY__SD2_DATA1, MX31_PIN_PC_WAIT_B__SD2_DATA0,
MX31_PIN_PC_CD2_B__SD2_CLK, MX31_PIN_PC_CD1_B__SD2_CMD,
MX31_PIN_ATA_DIOR__GPIO3_28, MX31_PIN_ATA_DIOW__GPIO3_29,
- /* 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_D4__GPIO3_4, MX31_PIN_CSI_D5__GPIO3_5,
- MX31_PIN_GPIO3_0__GPIO3_0, MX31_PIN_GPIO3_1__GPIO3_1,
- MX31_PIN_TXD2__GPIO1_28,
/* dsPIC resets */
MX31_PIN_STXD5__GPIO1_21, MX31_PIN_SRXD5__GPIO1_22,
/*battery detection */
@@ -143,82 +130,6 @@ static struct spi_board_info marxbot_spi_board_info[] __initdata = {
},
};
-#define TURRETCAM_POWER IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)
-#define BASECAM_POWER IOMUX_TO_GPIO(MX31_PIN_CSI_D5)
-#define TURRETCAM_RST_B IOMUX_TO_GPIO(MX31_PIN_GPIO3_0)
-#define BASECAM_RST_B IOMUX_TO_GPIO(MX31_PIN_CSI_D4)
-#define CAM_CHOICE IOMUX_TO_GPIO(MX31_PIN_TXD2)
-
-static int marxbot_basecam_power(struct device *dev, int on)
-{
- gpio_set_value(BASECAM_POWER, !on);
- return 0;
-}
-
-static int marxbot_basecam_reset(struct device *dev)
-{
- gpio_set_value(BASECAM_RST_B, 0);
- udelay(100);
- gpio_set_value(BASECAM_RST_B, 1);
- return 0;
-}
-
-static struct i2c_board_info marxbot_i2c_devices[] = {
- {
- I2C_BOARD_INFO("mt9t031", 0x5d),
- },
-};
-
-static struct soc_camera_link base_iclink = {
- .bus_id = 0, /* Must match with the camera ID */
- .power = marxbot_basecam_power,
- .reset = marxbot_basecam_reset,
- .board_info = &marxbot_i2c_devices[0],
- .i2c_adapter_id = 0,
-};
-
-static struct platform_device marxbot_camera[] = {
- {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &base_iclink,
- },
- },
-};
-
-static struct platform_device *marxbot_cameras[] __initdata = {
- &marxbot_camera[0],
-};
-
-static int __init marxbot_cam_init(void)
-{
- int ret = gpio_request(CAM_CHOICE, "cam-choice");
- if (ret)
- return ret;
- gpio_direction_output(CAM_CHOICE, 0);
-
- ret = gpio_request(BASECAM_RST_B, "basecam-reset");
- if (ret)
- return ret;
- gpio_direction_output(BASECAM_RST_B, 1);
- ret = gpio_request(BASECAM_POWER, "basecam-standby");
- if (ret)
- return ret;
- gpio_direction_output(BASECAM_POWER, 0);
-
- ret = gpio_request(TURRETCAM_RST_B, "turretcam-reset");
- if (ret)
- return ret;
- gpio_direction_output(TURRETCAM_RST_B, 1);
- ret = gpio_request(TURRETCAM_POWER, "turretcam-standby");
- if (ret)
- return ret;
- gpio_direction_output(TURRETCAM_POWER, 0);
-
- return 0;
-}
-
#define SEL0 IOMUX_TO_GPIO(MX31_PIN_DTR_DCE1)
#define SEL1 IOMUX_TO_GPIO(MX31_PIN_DSR_DCE1)
#define SEL2 IOMUX_TO_GPIO(MX31_PIN_RI_DCE1)
@@ -356,9 +267,6 @@ void __init mx31moboard_marxbot_init(void)
spi_register_board_info(marxbot_spi_board_info,
ARRAY_SIZE(marxbot_spi_board_info));
- marxbot_cam_init();
- platform_add_devices(marxbot_cameras, ARRAY_SIZE(marxbot_cameras));
-
/* battery present pin */
gpio_request(IOMUX_TO_GPIO(MX31_PIN_LCS0), "bat-present");
gpio_direction_input(IOMUX_TO_GPIO(MX31_PIN_LCS0));
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/6] ARM: mx31moboard-smartbot: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
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/mx31moboard-smartbot.c | 74 --------------------------------
1 file changed, 74 deletions(-)
diff --git a/arch/arm/mach-imx/mx31moboard-smartbot.c b/arch/arm/mach-imx/mx31moboard-smartbot.c
index 89fc35a..5cdd7ab 100644
--- a/arch/arm/mach-imx/mx31moboard-smartbot.c
+++ b/arch/arm/mach-imx/mx31moboard-smartbot.c
@@ -23,8 +23,6 @@
#include <linux/usb/otg.h>
#include <linux/usb/ulpi.h>
-#include <media/soc_camera.h>
-
#include "board-mx31moboard.h"
#include "common.h"
#include "devices-imx31.h"
@@ -37,16 +35,6 @@ static unsigned int smartbot_pins[] = {
/* UART1 */
MX31_PIN_CTS2__CTS2, MX31_PIN_RTS2__RTS2,
MX31_PIN_TXD2__TXD2, MX31_PIN_RXD2__RXD2,
- /* CSI */
- MX31_PIN_CSI_D4__CSI_D4, MX31_PIN_CSI_D5__CSI_D5,
- 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_GPIO3_0__GPIO3_0, MX31_PIN_GPIO3_1__GPIO3_1,
/* ENABLES */
MX31_PIN_DTR_DCE1__GPIO2_8, MX31_PIN_DSR_DCE1__GPIO2_9,
MX31_PIN_RI_DCE1__GPIO2_10, MX31_PIN_DCD_DCE1__GPIO2_11,
@@ -56,65 +44,6 @@ static const struct imxuart_platform_data uart_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
-#define CAM_POWER IOMUX_TO_GPIO(MX31_PIN_GPIO3_1)
-#define CAM_RST_B IOMUX_TO_GPIO(MX31_PIN_GPIO3_0)
-
-static int smartbot_cam_power(struct device *dev, int on)
-{
- gpio_set_value(CAM_POWER, !on);
- return 0;
-}
-
-static int smartbot_cam_reset(struct device *dev)
-{
- gpio_set_value(CAM_RST_B, 0);
- udelay(100);
- gpio_set_value(CAM_RST_B, 1);
- return 0;
-}
-
-static struct i2c_board_info smartbot_i2c_devices[] = {
- {
- I2C_BOARD_INFO("mt9t031", 0x5d),
- },
-};
-
-static struct soc_camera_link base_iclink = {
- .bus_id = 0, /* Must match with the camera ID */
- .power = smartbot_cam_power,
- .reset = smartbot_cam_reset,
- .board_info = &smartbot_i2c_devices[0],
- .i2c_adapter_id = 0,
-};
-
-static struct platform_device smartbot_camera[] = {
- {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &base_iclink,
- },
- },
-};
-
-static struct platform_device *smartbot_cameras[] __initdata = {
- &smartbot_camera[0],
-};
-
-static int __init smartbot_cam_init(void)
-{
- int ret = gpio_request(CAM_RST_B, "cam-reset");
- if (ret)
- return ret;
- gpio_direction_output(CAM_RST_B, 1);
- ret = gpio_request(CAM_POWER, "cam-standby");
- if (ret)
- return ret;
- gpio_direction_output(CAM_POWER, 0);
-
- return 0;
-}
-
static const struct fsl_usb2_platform_data usb_pdata __initconst = {
.operating_mode = FSL_USB2_DR_DEVICE,
.phy_mode = FSL_USB2_PHY_ULPI,
@@ -201,7 +130,4 @@ void __init mx31moboard_smartbot_init(int board)
}
smartbot_resets_init();
-
- smartbot_cam_init();
- platform_add_devices(smartbot_cameras, ARRAY_SIZE(smartbot_cameras));
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/6] ARM: mach-mx35_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
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-mx35_3ds.c | 103 --------------------------------------
1 file changed, 103 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c b/arch/arm/mach-imx/mach-mx35_3ds.c
index c8c2e09..1c33a6c 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -41,12 +41,9 @@
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
#include <asm/mach/map.h>
-#include <asm/memblock.h>
#include <video/platform_lcd.h>
-#include <media/soc_camera.h>
-
#include "3ds_debugboard.h"
#include "common.h"
#include "devices-imx35.h"
@@ -233,83 +230,10 @@ static const iomux_v3_cfg_t mx35pdk_pads[] __initconst = {
MX35_PAD_D3_VSYNC__IPU_DISPB_D3_VSYNC,
MX35_PAD_D3_REV__IPU_DISPB_D3_REV,
MX35_PAD_D3_CLS__IPU_DISPB_D3_CLS,
- /* CSI */
- MX35_PAD_TX1__IPU_CSI_D_6,
- MX35_PAD_TX0__IPU_CSI_D_7,
- MX35_PAD_CSI_D8__IPU_CSI_D_8,
- MX35_PAD_CSI_D9__IPU_CSI_D_9,
- MX35_PAD_CSI_D10__IPU_CSI_D_10,
- MX35_PAD_CSI_D11__IPU_CSI_D_11,
- MX35_PAD_CSI_D12__IPU_CSI_D_12,
- MX35_PAD_CSI_D13__IPU_CSI_D_13,
- MX35_PAD_CSI_D14__IPU_CSI_D_14,
- MX35_PAD_CSI_D15__IPU_CSI_D_15,
- MX35_PAD_CSI_HSYNC__IPU_CSI_HSYNC,
- MX35_PAD_CSI_MCLK__IPU_CSI_MCLK,
- MX35_PAD_CSI_PIXCLK__IPU_CSI_PIXCLK,
- MX35_PAD_CSI_VSYNC__IPU_CSI_VSYNC,
/*PMIC IRQ*/
MX35_PAD_GPIO2_0__GPIO2_0,
};
-/*
- * Camera support
-*/
-static phys_addr_t mx3_camera_base __initdata;
-#define MX35_3DS_CAMERA_BUF_SIZE SZ_8M
-
-static const struct mx3_camera_pdata mx35_3ds_camera_pdata __initconst = {
- .flags = MX3_CAMERA_DATAWIDTH_8,
- .mclk_10khz = 2000,
-};
-
-static int __init imx35_3ds_init_camera(void)
-{
- int dma, ret = -ENOMEM;
- struct platform_device *pdev =
- imx35_alloc_mx3_camera(&mx35_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,
- MX35_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 struct i2c_board_info mx35_3ds_i2c_camera = {
- I2C_BOARD_INFO("ov2640", 0x30),
-};
-
-static struct soc_camera_link iclink_ov2640 = {
- .bus_id = 0,
- .board_info = &mx35_3ds_i2c_camera,
- .i2c_adapter_id = 0,
- .power = NULL,
-};
-
-static struct platform_device mx35_3ds_ov2640 = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &iclink_ov2640,
- },
-};
-
static struct regulator_consumer_supply sw1_consumers[] = {
{
.supply = "cpu_vcc",
@@ -321,10 +245,6 @@ static struct regulator_consumer_supply vcam_consumers[] = {
REGULATOR_SUPPLY("VDDA", "0-000a"),
};
-static struct regulator_consumer_supply vaudio_consumers[] = {
- REGULATOR_SUPPLY("cmos_vio", "soc-camera-pdrv.0"),
-};
-
static struct regulator_init_data sw1_init = {
.constraints = {
.name = "SW1",
@@ -405,18 +325,6 @@ static struct regulator_init_data vvideo_init = {
}
};
-static struct regulator_init_data vaudio_init = {
- .constraints = {
- .name = "VAUDIO",
- .min_uV = 2300000,
- .max_uV = 3000000,
- .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
- .boot_on = 1
- },
- .num_consumer_supplies = ARRAY_SIZE(vaudio_consumers),
- .consumer_supplies = vaudio_consumers,
-};
-
static struct regulator_init_data vcam_init = {
.constraints = {
.name = "VCAM",
@@ -460,7 +368,6 @@ static struct mc13xxx_regulator_init_data mx35_3ds_regulators[] = {
{ .id = MC13892_VDIG, .init_data = &vdig_init },
{ .id = MC13892_VUSB2, .init_data = &vusb2_init },
{ .id = MC13892_VVIDEO, .init_data = &vvideo_init },
- { .id = MC13892_VAUDIO, .init_data = &vaudio_init },
{ .id = MC13892_VCAM, .init_data = &vcam_init },
{ .id = MC13892_VGEN1, .init_data = &vgen1_init },
{ .id = MC13892_VGEN2, .init_data = &vgen2_init },
@@ -583,8 +490,6 @@ static void __init mx35_3ds_init(void)
0, i2c_devices_3ds, ARRAY_SIZE(i2c_devices_3ds));
imx35_add_ipu_core();
- platform_device_register(&mx35_3ds_ov2640);
- imx35_3ds_init_camera();
}
static void __init mx35_3ds_late_init(void)
@@ -607,13 +512,6 @@ static void __init mx35pdk_timer_init(void)
mx35_clocks_init();
}
-static void __init mx35_3ds_reserve(void)
-{
- /* reserve MX35_3DS_CAMERA_BUF_SIZE bytes for mx3-camera */
- mx3_camera_base = arm_memblock_steal(MX35_3DS_CAMERA_BUF_SIZE,
- MX35_3DS_CAMERA_BUF_SIZE);
-}
-
MACHINE_START(MX35_3DS, "Freescale MX35PDK")
/* Maintainer: Freescale Semiconductor, Inc */
.atag_offset = 0x100,
@@ -623,6 +521,5 @@ MACHINE_START(MX35_3DS, "Freescale MX35PDK")
.init_time = mx35pdk_timer_init,
.init_machine = mx35_3ds_init,
.init_late = mx35_3ds_late_init,
- .reserve = mx35_3ds_reserve,
.restart = mxc_restart,
MACHINE_END
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/6] ARM: mach-pcm037: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
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-pcm037.c | 115 ----------------------------------------
1 file changed, 115 deletions(-)
diff --git a/arch/arm/mach-imx/mach-pcm037.c b/arch/arm/mach-imx/mach-pcm037.c
index 9f0f55b..b787ba6 100644
--- a/arch/arm/mach-imx/mach-pcm037.c
+++ b/arch/arm/mach-imx/mach-pcm037.c
@@ -31,17 +31,13 @@
#include <linux/usb/otg.h>
#include <linux/usb/ulpi.h>
#include <linux/gfp.h>
-#include <linux/memblock.h>
#include <linux/regulator/machine.h>
#include <linux/regulator/fixed.h>
-#include <media/soc_camera.h>
-
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
#include <asm/mach/time.h>
#include <asm/mach/map.h>
-#include <asm/memblock.h>
#include "common.h"
#include "devices-imx31.h"
@@ -150,22 +146,6 @@ static unsigned int pcm037_pins[] = {
MX31_PIN_D3_SPL__D3_SPL,
MX31_PIN_D3_CLS__D3_CLS,
MX31_PIN_LCS0__GPIO3_23,
- /* CSI */
- IOMUX_MODE(MX31_PIN_CSI_D5, IOMUX_CONFIG_GPIO),
- 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,
/* GPIO */
IOMUX_MODE(MX31_PIN_ATA_DMACK, IOMUX_CONFIG_GPIO),
/* OTG */
@@ -289,34 +269,6 @@ static struct at24_platform_data board_eeprom = {
.flags = AT24_FLAG_ADDR16,
};
-static int pcm037_camera_power(struct device *dev, int on)
-{
- /* disable or enable the camera in X7 or X8 PCM970 connector */
- gpio_set_value(IOMUX_TO_GPIO(MX31_PIN_CSI_D5), !on);
- return 0;
-}
-
-static struct i2c_board_info pcm037_i2c_camera[] = {
- {
- I2C_BOARD_INFO("mt9t031", 0x5d),
- }, {
- I2C_BOARD_INFO("mt9v022", 0x48),
- },
-};
-
-static struct soc_camera_link iclink_mt9v022 = {
- .bus_id = 0, /* Must match with the camera ID */
- .board_info = &pcm037_i2c_camera[1],
- .i2c_adapter_id = 2,
-};
-
-static struct soc_camera_link iclink_mt9t031 = {
- .bus_id = 0, /* Must match with the camera ID */
- .power = pcm037_camera_power,
- .board_info = &pcm037_i2c_camera[0],
- .i2c_adapter_id = 2,
-};
-
static struct i2c_board_info pcm037_i2c_devices[] = {
{
I2C_BOARD_INFO("at24", 0x52), /* E0=0, E1=1, E2=0 */
@@ -326,22 +278,6 @@ static struct i2c_board_info pcm037_i2c_devices[] = {
}
};
-static struct platform_device pcm037_mt9t031 = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &iclink_mt9t031,
- },
-};
-
-static struct platform_device pcm037_mt9v022 = {
- .name = "soc-camera-pdrv",
- .id = 1,
- .dev = {
- .platform_data = &iclink_mt9v022,
- },
-};
-
/* Not connected by default */
#ifdef PCM970_SDHC_RW_SWITCH
static int pcm970_sdhc1_get_ro(struct device *dev)
@@ -403,42 +339,9 @@ static const struct imxmmc_platform_data sdhc_pdata __initconst = {
.exit = pcm970_sdhc1_exit,
};
-struct mx3_camera_pdata camera_pdata __initdata = {
- .flags = MX3_CAMERA_DATAWIDTH_8 | MX3_CAMERA_DATAWIDTH_10,
- .mclk_10khz = 2000,
-};
-
-static phys_addr_t mx3_camera_base __initdata;
-#define MX3_CAMERA_BUF_SIZE SZ_4M
-
-static int __init pcm037_init_camera(void)
-{
- int dma, ret = -ENOMEM;
- struct platform_device *pdev = imx31_alloc_mx3_camera(&camera_pdata);
-
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
-
- dma = dma_declare_coherent_memory(&pdev->dev,
- mx3_camera_base, mx3_camera_base,
- MX3_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 struct platform_device *devices[] __initdata = {
&pcm037_flash,
&pcm037_sram_device,
- &pcm037_mt9t031,
- &pcm037_mt9v022,
};
static const struct fb_videomode fb_modedb[] = {
@@ -651,13 +554,6 @@ static void __init pcm037_timer_init(void)
mx31_clocks_init(26000000);
}
-static void __init pcm037_reserve(void)
-{
- /* reserve 4 MiB for mx3-camera */
- mx3_camera_base = arm_memblock_steal(MX3_CAMERA_BUF_SIZE,
- MX3_CAMERA_BUF_SIZE);
-}
-
static void __init pcm037_init_late(void)
{
int ret;
@@ -677,16 +573,6 @@ static void __init pcm037_init_late(void)
imx31_add_mxc_mmc(0, &sdhc_pdata);
- /* CSI */
- /* Camera power: default - off */
- ret = gpio_request(IOMUX_TO_GPIO(MX31_PIN_CSI_D5), "mt9t031-power");
- if (!ret)
- gpio_direction_output(IOMUX_TO_GPIO(MX31_PIN_CSI_D5), 1);
- else
- iclink_mt9t031.power = NULL;
-
- pcm037_init_camera();
-
pcm970_sja1000_resources[1].start =
gpio_to_irq(IOMUX_TO_GPIO(IOMUX_PIN(48, 105)));
pcm970_sja1000_resources[1].end =
@@ -699,7 +585,6 @@ static void __init pcm037_init_late(void)
MACHINE_START(PCM037, "Phytec Phycore pcm037")
/* Maintainer: Pengutronix */
.atag_offset = 0x100,
- .reserve = pcm037_reserve,
.map_io = mx31_map_io,
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
--
2.7.4
^ permalink raw reply related
* [PATCH v2 6/6] ARM: mach-mx27_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-30 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit 6b879edf75b316 ("[media] staging/media: remove deprecated
mx2 driver") the mx2 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-mx27_3ds.c | 107 --------------------------------------
1 file changed, 107 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
index 7ba651a..45e16bd 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -31,7 +31,6 @@
#include <linux/regulator/machine.h>
#include <linux/spi/l4f00242t03.h>
-#include <media/soc_camera.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -53,8 +52,6 @@
#define SD1_CD IMX_GPIO_NR(2, 26)
#define LCD_RESET IMX_GPIO_NR(1, 3)
#define LCD_ENABLE IMX_GPIO_NR(1, 31)
-#define CSI_PWRDWN IMX_GPIO_NR(4, 19)
-#define CSI_RESET IMX_GPIO_NR(3, 6)
static const int mx27pdk_pins[] __initconst = {
/* UART1 */
@@ -144,21 +141,6 @@ static const int mx27pdk_pins[] __initconst = {
PA30_PF_CONTRAST,
LCD_ENABLE | GPIO_GPIO | GPIO_OUT,
LCD_RESET | GPIO_GPIO | GPIO_OUT,
- /* CSI */
- PB10_PF_CSI_D0,
- PB11_PF_CSI_D1,
- PB12_PF_CSI_D2,
- PB13_PF_CSI_D3,
- PB14_PF_CSI_D4,
- PB15_PF_CSI_MCLK,
- PB16_PF_CSI_PIXCLK,
- PB17_PF_CSI_D5,
- PB18_PF_CSI_D6,
- PB19_PF_CSI_D7,
- PB20_PF_CSI_VSYNC,
- PB21_PF_CSI_HSYNC,
- CSI_PWRDWN | GPIO_GPIO | GPIO_OUT,
- CSI_RESET | GPIO_GPIO | GPIO_OUT,
/* SSI4 */
PC16_PF_SSI4_FS,
PC17_PF_SSI4_RXD,
@@ -166,11 +148,6 @@ static const int mx27pdk_pins[] __initconst = {
PC19_PF_SSI4_CLK,
};
-static struct gpio mx27_3ds_camera_gpios[] = {
- { CSI_PWRDWN, GPIOF_OUT_INIT_HIGH, "camera-power" },
- { CSI_RESET, GPIOF_OUT_INIT_HIGH, "camera-reset" },
-};
-
static const struct imxuart_platform_data uart_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
@@ -270,7 +247,6 @@ static struct regulator_init_data gpo_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 = {
@@ -299,22 +275,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 mx27_3ds_regulators[] = {
{
.id = MC13783_REG_VMMC1,
@@ -328,9 +288,6 @@ static struct mc13xxx_regulator_init_data mx27_3ds_regulators[] = {
}, {
.id = MC13783_REG_GPO3, /* Turn on 3.3V */
.init_data = &gpo_init,
- }, {
- .id = MC13783_REG_VVIB, /* Power OV2640 */
- .init_data = &vvib_init,
},
};
@@ -370,51 +327,6 @@ static const struct spi_imx_master spi2_pdata __initconst = {
.num_chipselect = ARRAY_SIZE(spi2_chipselect),
};
-static int mx27_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(CSI_PWRDWN, on ? 0 : 1);
-
- if (!on)
- goto out;
-
- /* If enabled, give a reset impulse */
- gpio_set_value(CSI_RESET, 0);
- msleep(20);
- gpio_set_value(CSI_RESET, 1);
- msleep(100);
-
-out:
- return 0;
-}
-
-static struct i2c_board_info mx27_3ds_i2c_camera = {
- I2C_BOARD_INFO("ov2640", 0x30),
-};
-
-static struct regulator_bulk_data mx27_3ds_camera_regs[] = {
- { .supply = "cmos_vcore" },
- { .supply = "cmos_2v8" },
-};
-
-static struct soc_camera_link iclink_ov2640 = {
- .bus_id = 0,
- .board_info = &mx27_3ds_i2c_camera,
- .i2c_adapter_id = 0,
- .power = mx27_3ds_camera_power,
- .regulators = mx27_3ds_camera_regs,
- .num_regulators = ARRAY_SIZE(mx27_3ds_camera_regs),
-};
-
-static struct platform_device mx27_3ds_ov2640 = {
- .name = "soc-camera-pdrv",
- .id = 0,
- .dev = {
- .platform_data = &iclink_ov2640,
- },
-};
-
static struct imx_fb_videomode mx27_3ds_modes[] = {
{ /* 480x640 @ 60 Hz */
.mode = {
@@ -471,14 +383,6 @@ static struct spi_board_info mx27_3ds_spi_devs[] __initdata = {
},
};
-static struct platform_device *devices[] __initdata = {
- &mx27_3ds_ov2640,
-};
-
-static const struct mx2_camera_platform_data mx27_3ds_cam_pdata __initconst = {
- .clk = 26000000,
-};
-
static const struct imxi2c_platform_data mx27_3ds_i2c0_data __initconst = {
.bitrate = 100000,
};
@@ -498,7 +402,6 @@ static void __init mx27pdk_init(void)
imx27_add_spi_imx0(&spi1_pdata);
imx27_add_imx_i2c(0, &mx27_3ds_i2c0_data);
- platform_add_devices(devices, ARRAY_SIZE(devices));
imx27_add_imx_fb(&mx27_3ds_fb_data);
imx27_add_imx_ssi(0, &mx27_3ds_ssi_pdata);
@@ -506,8 +409,6 @@ static void __init mx27pdk_init(void)
static void __init mx27pdk_late_init(void)
{
- int ret;
-
mx27_3ds_sdhc1_enable_level_translator();
imx27_add_mxc_mmc(0, &sdhc1_pdata);
@@ -531,14 +432,6 @@ static void __init mx27pdk_late_init(void)
if (mxc_expio_init(MX27_CS5_BASE_ADDR, IMX_GPIO_NR(3, 28)))
pr_warn("Init of the debugboard failed, all devices on the debugboard are unusable.\n");
- ret = gpio_request_array(mx27_3ds_camera_gpios,
- ARRAY_SIZE(mx27_3ds_camera_gpios));
- if (ret) {
- pr_err("Failed to request camera gpios");
- iclink_ov2640.power = NULL;
- }
-
- imx27_add_mx2_camera(&mx27_3ds_cam_pdata);
imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
}
--
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