* Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Jon Mason @ 2017-04-25 15:15 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Eric Anholt, Florian Fainelli, Vivien Didelot, Andrew Lunn,
Network Development, Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-kernel, open list, BCM Kernel Feedback, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <f870339f-2fa1-411d-5ce8-adbe8802d8a8-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On Tue, Apr 25, 2017 at 5:40 AM, Sergei Shtylyov
<sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> Hello.
>
> On 4/25/2017 12:50 AM, Eric Anholt wrote:
>
>> Cygnus has a single amac controller connected to the B53 switch with 2
>> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
>> the external ethernet jacks.
>
>
> My spell checker trips on "amac" and "ethernet" -- perhaps they need
> capitalization?
>
>> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
>> ---
>> arch/arm/boot/dts/bcm-cygnus.dtsi | 60
>> ++++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
>> 2 files changed, 68 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 009f1346b817..318899df9972 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -142,6 +142,56 @@
>> interrupts = <0>;
>> };
>>
>> + mdio: mdio@18002000 {
>> + compatible = "brcm,iproc-mdio";
>> + reg = <0x18002000 0x8>;
>> + #size-cells = <1>;
>> + #address-cells = <0>;
>> +
>> + gphy0: eth-gphy@0 {
>
>
> The node anmes must be generic, the DT spec has standardized
> "ethernet-phy" name for this case.
>
>> + reg = <0>;
>> + max-speed = <1000>;
>> + };
>> +
>> + gphy1: eth-gphy@1 {
>> + reg = <1>;
>> + max-speed = <1000>;
>> + };
>> + };
>
> [...]
>>
>> @@ -295,6 +345,16 @@
>> status = "disabled";
>> };
>>
>> + eth0: enet@18042000 {
>> + compatible = "brcm,amac";
>> + reg = <0x18042000 0x1000>,
>> + <0x18110000 0x1000>;
>> + reg-names = "amac_base", "idm_base";
>
>
> I don't think "_base" suffixes are necessary here.
100% necessary, per the driver. See
drivers/net/ethernet/broadcom/bgmac-platform.c
>
> [...]
>
> MBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2017-04-25 14:55 UTC (permalink / raw)
To: Philipp Zabel
Cc: Jonathan Cameron, linux-kernel, Greg Kroah-Hartman, Wolfram Sang,
Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jonathan Corbet, linux-i2c, devicetree,
linux-iio, linux-doc, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel
In-Reply-To: <f74d5619-8614-d003-3c70-710aee0b550b@axentia.se>
On 2017-04-25 16:16, Peter Rosin wrote:
> On 2017-04-24 16:59, Philipp Zabel wrote:
>> On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote:
>> [...]
>>>> How about an atomic use_count on the mux_control, a bool shared that is
>>>> only set by the first consumer, and controls whether selecting locks?
>>>
>>> That has the drawback that it is hard to restore the mux-control in a safe
>>> way so that exclusive consumers are allowed after the last shared consumer
>>> puts the mux away.
>>
>> True.
>>
>>> Agreed, it's a corner case, but I had this very similar
>>> patch going through the compiler when I got this mail. Does it work as well
>>> as what you suggested?
>>
>> Yes, this patch works just as well.
>
> Right, as expected :-) However, I don't like it much. It divides the mux
> consumers into two camps in a way that makes it difficult to select which
> camp a consumer should be in.
>
> E.g. consider the iio-mux. The current implementation only supports quick
> accesses that fit the mux_control_get_shared case. But if that mux in the
> future needs to grow continuous buffered accesses, I think there will be
> pressure to switch it over to the exclusive mode. Because that is a lot
> closer to what you are doing with the video-mux. And then what? It will be
> impossible to predict if the end user is going to use buffered accesses or
> not...
>
> So, I think the best approach is to skip the distinction between shared
> and exclusive consumers and instead implement the locking with an ordinary
> semaphore (instead of the old rwsem or the current mutex). Semaphores don't
> have the property that the same task should down/up them (mutexes require
> that for lock/unlock, and is also the reason for the lockdep complaint) and
> thus fits better for long-time use such as yours or the above iio-mux with
> buffered accesses. It should also hopefully be cheaper that an rwsem, and
> not have any downgrade_write calls thus possibly keeping Greg sufficiently
> happy...
>
> Sure, consumers can still dig themselves into a hole by not calling deselect
> as they should, but at least I think it can be made to work w/o dividing the
> consumers...
Like this (only compile-tested). Philipp, it should work the same as with
the rwsem in v13 and earlier. At least for your case...
Cheers,
peda
diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
index c02fa4dd2d09..f99b70d4e319 100644
--- a/drivers/mux/mux-core.c
+++ b/drivers/mux/mux-core.c
@@ -116,7 +116,7 @@ struct mux_chip *mux_chip_alloc(struct device *dev,
struct mux_control *mux = &mux_chip->mux[i];
mux->chip = mux_chip;
- mutex_init(&mux->lock);
+ sema_init(&mux->lock, 1);
mux->cached_state = MUX_CACHE_UNKNOWN;
mux->idle_state = MUX_IDLE_AS_IS;
}
@@ -372,12 +372,14 @@ int mux_control_select(struct mux_control *mux, unsigned int state)
{
int ret;
- mutex_lock(&mux->lock);
+ ret = down_killable(&mux->lock);
+ if (ret < 0)
+ return ret;
ret = __mux_control_select(mux, state);
if (ret < 0)
- mutex_unlock(&mux->lock);
+ up(&mux->lock);
return ret;
}
@@ -399,13 +401,13 @@ int mux_control_try_select(struct mux_control *mux, unsigned int state)
{
int ret;
- if (!mutex_trylock(&mux->lock))
+ if (down_trylock(&mux->lock))
return -EBUSY;
ret = __mux_control_select(mux, state);
if (ret < 0)
- mutex_unlock(&mux->lock);
+ up(&mux->lock);
return ret;
}
@@ -427,7 +429,7 @@ int mux_control_deselect(struct mux_control *mux)
mux->idle_state != mux->cached_state)
ret = mux_control_set(mux, mux->idle_state);
- mutex_unlock(&mux->lock);
+ up(&mux->lock);
return ret;
}
diff --git a/include/linux/mux/driver.h b/include/linux/mux/driver.h
index 95269f40670a..43f65f80c275 100644
--- a/include/linux/mux/driver.h
+++ b/include/linux/mux/driver.h
@@ -15,7 +15,6 @@
#include <dt-bindings/mux/mux.h>
#include <linux/device.h>
-#include <linux/mutex.h>
#include <linux/semaphore.h>
struct mux_chip;
@@ -44,7 +43,7 @@ struct mux_control_ops {
* mux drivers.
*/
struct mux_control {
- struct mutex lock; /* protects the state of the mux */
+ struct semaphore lock; /* protects the state of the mux */
struct mux_chip *chip;
int cached_state;
^ permalink raw reply related
* Re: [PATCH v2 12/18] gpio: madera: Support Cirrus Logic Madera class codecs
From: Richard Fitzgerald @ 2017-04-25 14:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, alsa-devel@alsa-project.org, Jason Cooper,
devicetree@vger.kernel.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, Mark Brown, Thomas Gleixner,
Lee Jones
In-Reply-To: <CACRpkdbhgkwtPygfRL6JXc7syi4MqSUXx2jrVzp7q9FPOWX6OQ@mail.gmail.com>
On Tue, 2017-04-25 at 16:13 +0200, Linus Walleij wrote:
> On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
> <rf@opensource.wolfsonmicro.com> wrote:
>
> > This adds support for the GPIOs on Cirrus Logic Madera class codecs.
> > Any pins not used for special functions (see the pinctrl driver) can be
> > used as general single-bit input or output lines. The number of available
> > GPIOs varies between codecs.
> >
> > Signed-off-by: Nariman Poushin <nariman@opensource.wolfsonmicro.com>
> > Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> > Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
> > ---
> > Changes from V1:
> > - dt bindings moved to a separate patch
> > - dependent on pinctrl driver instead of parent MFD
> > - added get_direction function
> > - added .request / .free / .set_config to work with pinctrl driver
> > - register range with pinctrl driver
>
> Nice, but...
>
> > + ret = gpiochip_add_pin_range(&madera_gpio->gpio_chip, "madera-pinctrl",
> > + 0, 0, madera_gpio->gpio_chip.ngpio);
> > + if (ret) {
> > + dev_warn(&pdev->dev, "Failed to add pin range (%d)\n", ret);
> > + return ret;
> > + }
>
> This is all fine, but we have generic code for adding ranges from
> the device tree, see
> Documentation/devicetree/bindings/gpio/gpio.txt
>
The range of gpio pins is a fixed property of the chip, and so is the
combination of gpio+pinctrl drivers.
I think the general principle of the DT maintainers is that DT should be
used for things that the drivers don't already know and can't figure
out.
> With that this range should not even be needed.
> Apart from that it looks pretty solid.
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2017-04-25 14:16 UTC (permalink / raw)
To: Philipp Zabel
Cc: Jonathan Cameron, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Wolfram Sang, Rob Herring, Mark Rutland,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1493045969.2446.47.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-24 16:59, Philipp Zabel wrote:
> On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote:
> [...]
>>> How about an atomic use_count on the mux_control, a bool shared that is
>>> only set by the first consumer, and controls whether selecting locks?
>>
>> That has the drawback that it is hard to restore the mux-control in a safe
>> way so that exclusive consumers are allowed after the last shared consumer
>> puts the mux away.
>
> True.
>
>> Agreed, it's a corner case, but I had this very similar
>> patch going through the compiler when I got this mail. Does it work as well
>> as what you suggested?
>
> Yes, this patch works just as well.
Right, as expected :-) However, I don't like it much. It divides the mux
consumers into two camps in a way that makes it difficult to select which
camp a consumer should be in.
E.g. consider the iio-mux. The current implementation only supports quick
accesses that fit the mux_control_get_shared case. But if that mux in the
future needs to grow continuous buffered accesses, I think there will be
pressure to switch it over to the exclusive mode. Because that is a lot
closer to what you are doing with the video-mux. And then what? It will be
impossible to predict if the end user is going to use buffered accesses or
not...
So, I think the best approach is to skip the distinction between shared
and exclusive consumers and instead implement the locking with an ordinary
semaphore (instead of the old rwsem or the current mutex). Semaphores don't
have the property that the same task should down/up them (mutexes require
that for lock/unlock, and is also the reason for the lockdep complaint) and
thus fits better for long-time use such as yours or the above iio-mux with
buffered accesses. It should also hopefully be cheaper that an rwsem, and
not have any downgrade_write calls thus possibly keeping Greg sufficiently
happy...
Sure, consumers can still dig themselves into a hole by not calling deselect
as they should, but at least I think it can be made to work w/o dividing the
consumers...
Cheers,
peda
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 12/18] gpio: madera: Support Cirrus Logic Madera class codecs
From: Linus Walleij @ 2017-04-25 14:13 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Lee Jones, Mark Brown, Alexandre Courbot, Rob Herring,
Thomas Gleixner, Jason Cooper,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1493050124-5970-13-git-send-email-rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
<rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote:
> This adds support for the GPIOs on Cirrus Logic Madera class codecs.
> Any pins not used for special functions (see the pinctrl driver) can be
> used as general single-bit input or output lines. The number of available
> GPIOs varies between codecs.
>
> Signed-off-by: Nariman Poushin <nariman-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> Signed-off-by: Richard Fitzgerald <rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
> Changes from V1:
> - dt bindings moved to a separate patch
> - dependent on pinctrl driver instead of parent MFD
> - added get_direction function
> - added .request / .free / .set_config to work with pinctrl driver
> - register range with pinctrl driver
Nice, but...
> + ret = gpiochip_add_pin_range(&madera_gpio->gpio_chip, "madera-pinctrl",
> + 0, 0, madera_gpio->gpio_chip.ngpio);
> + if (ret) {
> + dev_warn(&pdev->dev, "Failed to add pin range (%d)\n", ret);
> + return ret;
> + }
This is all fine, but we have generic code for adding ranges from
the device tree, see
Documentation/devicetree/bindings/gpio/gpio.txt
With that this range should not even be needed.
Apart from that it looks pretty solid.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 3/3] soc: qcom: rfsa driver
From: Sricharan R @ 2017-04-25 13:21 UTC (permalink / raw)
To: Bjorn Andersson, Andy Gross, David Brown, Frank Rowand,
Rob Herring, Mark Rutland
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170422173519.5782-3-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Bjorn,
On 4/22/2017 11:05 PM, Bjorn Andersson wrote:
> The rfsa driver is used for allocating and exposing regions of shared
> memory with remote processors for the purpose of exchanging sector-data
> between the remote filesystem service and its clients.
>
> It provides accessors for the properties needed by the user space remote
> filesystem implementation through sysfs and a character device that can be used
> to read and write the requested chunks of data.
>
couple of minor nits.
> Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/soc/qcom/Kconfig | 8 ++
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/rfsa.c | 261 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 270 insertions(+)
> create mode 100644 drivers/soc/qcom/rfsa.c
>
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 9fca977ef18d..788a63cd430e 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -24,6 +24,14 @@ config QCOM_PM
> modes. It interface with various system drivers to put the cores in
> low power modes.
>
> +config QCOM_RFSA
> + tristate "Qualcomm Remote Filesystem Access driver"
depends on ARCH_QCOM ?
> + help
> + The Qualcomm remote filesystem access driver is used for allocating
> + and exposing regions of shared memory with remote processors for the
> + purpose of exchanging sector-data between the remote filesystem
> + service and its clients.
> +
> config QCOM_SMEM
> tristate "Qualcomm Shared Memory Manager (SMEM)"
> depends on ARCH_QCOM
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index 414f0de274fa..d1bbc791ddc0 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -1,6 +1,7 @@
> obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
> obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
> obj-$(CONFIG_QCOM_PM) += spm.o
> +obj-$(CONFIG_QCOM_RFSA) += rfsa.o
> obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
> obj-$(CONFIG_QCOM_SMEM) += smem.o
> obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
> diff --git a/drivers/soc/qcom/rfsa.c b/drivers/soc/qcom/rfsa.c
> new file mode 100644
> index 000000000000..1b79976dad9d
> --- /dev/null
> +++ b/drivers/soc/qcom/rfsa.c
> @@ -0,0 +1,261 @@
> +/*
> + * Copyright (c) 2017 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/cdev.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/of_fdt.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +#include <linux/io.h>
> +
> +#define QCOM_RFSA_DEV_MAX (MINORMASK + 1)
> +
> +static dev_t qcom_rfsa_major;
> +
> +struct qcom_rfsa {
> + struct device dev;
> + struct cdev cdev;
> +
> + void *base;
> + phys_addr_t addr;
> + phys_addr_t size;
> +
> + unsigned int client_id;
> +};
> +
> +static ssize_t qcom_rfsa_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf);
> +
> +static DEVICE_ATTR(phys_addr, 0400, qcom_rfsa_show, NULL);
> +static DEVICE_ATTR(size, 0400, qcom_rfsa_show, NULL);
> +static DEVICE_ATTR(client_id, 0400, qcom_rfsa_show, NULL);
> +
> +static ssize_t qcom_rfsa_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct qcom_rfsa *rfsa = container_of(dev, struct qcom_rfsa, dev);
> +
> + if (attr == &dev_attr_phys_addr)
> + return sprintf(buf, "%pa\n", &rfsa->addr);
> + if (attr == &dev_attr_size)
> + return sprintf(buf, "%pa\n", &rfsa->size);
> + if (attr == &dev_attr_client_id)
> + return sprintf(buf, "%d\n", rfsa->client_id);
> +
> + return -EINVAL;
> +}
> +
> +static struct attribute *qcom_rfsa_attrs[] = {
> + &dev_attr_phys_addr.attr,
> + &dev_attr_size.attr,
> + &dev_attr_client_id.attr,
> + NULL
> +};
> +ATTRIBUTE_GROUPS(qcom_rfsa);
> +
> +static int qcom_rfsa_open(struct inode *inode, struct file *filp)
> +{
> + struct qcom_rfsa *rfsa = container_of(inode->i_cdev, struct qcom_rfsa, cdev);
> +
> + get_device(&rfsa->dev);
> + filp->private_data = rfsa;
> +
> + return 0;
> +}
> +static ssize_t qcom_rfsa_read(struct file *filp,
> + char __user *buf, size_t count, loff_t *f_pos)
> +{
> + struct qcom_rfsa *rfsa = filp->private_data;
> +
> + if (*f_pos >= rfsa->size)
> + return 0;
> +
> + if (*f_pos + count >= rfsa->size)
> + count = rfsa->size - *f_pos;
> +
> + if (copy_to_user(buf, rfsa->base + *f_pos, count))
> + return -EFAULT;
> +
> + *f_pos += count;
> + return count;
> +}
> +
> +static ssize_t qcom_rfsa_write(struct file *filp,
> + const char __user *buf, size_t count,
> + loff_t *f_pos)
> +{
> + struct qcom_rfsa *rfsa = filp->private_data;
> +
> + if (*f_pos >= rfsa->size)
> + return 0;
> +
> + if (*f_pos + count >= rfsa->size)
> + count = rfsa->size - *f_pos;
> +
> + if (copy_from_user(rfsa->base + *f_pos, buf, count))
> + return -EFAULT;
> +
> + *f_pos += count;
> + return count;
> +}
> +
> +static int qcom_rfsa_release(struct inode *inode, struct file *filp)
> +{
> + struct qcom_rfsa *rfsa = filp->private_data;
> +
> + put_device(&rfsa->dev);
> +
> + return 0;
> +}
> +
> +static const struct file_operations qcom_rfsa_fops = {
> + .owner = THIS_MODULE,
> + .open = qcom_rfsa_open,
> + .read = qcom_rfsa_read,
> + .write = qcom_rfsa_write,
> + .release = qcom_rfsa_release,
> + .llseek = default_llseek,
> +};
> +
> +static void qcom_rfsa_release_device(struct device *dev)
> +{
> + struct qcom_rfsa *rfsa = container_of(dev, struct qcom_rfsa, dev);
> +
> + kfree(rfsa);
> +}
> +
> +static int qcom_rfsa_probe(struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + struct reserved_mem *rmem;
> + struct qcom_rfsa *rfsa;
> + u32 client_id;
> + int ret;
> +
> + rmem = of_get_reserved_mem_by_idx(node, 0);
> + if (!rmem) {
> + dev_err(&pdev->dev, "failed to acquire memory region\n");
> + return -EINVAL;
> + }
> +
> + ret = of_property_read_u32(node, "qcom,client-id", &client_id);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to parse \"qcom,client-id\"\n");
> + return ret;
> +
> + }
> +
> + rfsa = kzalloc(sizeof(*rfsa), GFP_KERNEL);
> + if (!rfsa)
> + return -ENOMEM;
> +
> + rfsa->addr = rmem->base;
> + rfsa->client_id = client_id;
> + rfsa->size = rmem->size;
> +
> + device_initialize(&rfsa->dev);
> + rfsa->dev.parent = &pdev->dev;
> + rfsa->dev.groups = qcom_rfsa_groups;
> +
> + cdev_init(&rfsa->cdev, &qcom_rfsa_fops);
> + rfsa->cdev.owner = THIS_MODULE;
> +
> + dev_set_name(&rfsa->dev, "qcom_rfsa%d", client_id);
> + rfsa->dev.id = client_id;
> + rfsa->dev.devt = MKDEV(MAJOR(qcom_rfsa_major), client_id);
> +
> + ret = cdev_device_add(&rfsa->cdev, &rfsa->dev);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to add cdev: %d\n", ret);
> + put_device(&rfsa->dev);
> + return ret;
> + }
> +
> + rfsa->dev.release = qcom_rfsa_release_device;
> +
> + rfsa->base = devm_memremap(&rfsa->dev, rfsa->addr, rfsa->size, MEMREMAP_WC);
> + if (IS_ERR(rfsa->base)) {
> + dev_err(&pdev->dev, "failed to remap rfsa region\n");
> +
> + device_del(&rfsa->dev);
> + put_device(&rfsa->dev);
> +
> + return PTR_ERR(rfsa->base);
> + }
> +
> + dev_set_drvdata(&pdev->dev, rfsa);
> +
> + return 0;
> +}
> +
> +static int qcom_rfsa_remove(struct platform_device *pdev)
> +{
> + struct qcom_rfsa *rfsa = dev_get_drvdata(&pdev->dev);
> +
> + cdev_del(&rfsa->cdev);
> + device_del(&rfsa->dev);
cdev_device_del instead of the above two ?
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 5/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Heiko Stübner, Neil Armstrong
Cc: Sjoerd Simons, Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Guillaume Tucker
In-Reply-To: <cover.1493125299.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
From: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Add reference to the Mali GPU device tree node on rk3288-veyron.
Tested on Minnie and Jerry boards.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 5d1eb0a25827..9847d5c6db3b 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -447,6 +447,11 @@
status = "okay";
};
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
&wdt {
status = "okay";
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 4/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Heiko Stübner, Neil Armstrong
Cc: Sjoerd Simons, Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Guillaume Tucker
In-Reply-To: <cover.1493125299.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Add reference to the Mali GPU device tree node on rk3288-firefly.
Tested on Firefly board.
Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
---
arch/arm/boot/dts/rk3288-firefly.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 10793ac18599..f520589493b4 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -594,3 +594,8 @@
&wdt {
status = "okay";
};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 3/5] ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Heiko Stübner, Neil Armstrong
Cc: Sjoerd Simons, Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Guillaume Tucker
In-Reply-To: <cover.1493125299.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Add reference to the Mali GPU device tree node on the
rk3288-rock2-som platform. Tested on a Radxa Rock2 Square board.
Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
---
arch/arm/boot/dts/rk3288-rock2-som.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-rock2-som.dtsi b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
index 1c0bbc9b928b..f694867fa46a 100644
--- a/arch/arm/boot/dts/rk3288-rock2-som.dtsi
+++ b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
@@ -301,3 +301,8 @@
&wdt {
status = "okay";
};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 2/5] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Heiko Stübner, Neil Armstrong
Cc: Sjoerd Simons, Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Guillaume Tucker
In-Reply-To: <cover.1493125299.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Add Mali GPU device tree node for the rk3288 SoC, with devfreq
opp table.
Tested-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
---
arch/arm/boot/dts/rk3288.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index df8a0dbe9d91..35969041eae2 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -43,6 +43,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/clock/rk3288-cru.h>
+#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/thermal/thermal.h>
#include <dt-bindings/power/rk3288-power.h>
#include <dt-bindings/soc/rockchip,boot-mode.h>
@@ -1117,6 +1118,48 @@
};
};
+ gpu: mali@ffa30000 {
+ compatible = "rockchip,rk3288-mali", "arm,mali-t760", "arm,mali-midgard";
+ reg = <0xffa30000 0x10000>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&cru ACLK_GPU>;
+ operating-points-v2 = <&gpu_opp_table>;
+ power-domains = <&power RK3288_PD_GPU>;
+ status = "disabled";
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp@100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <950000>;
+ };
+ opp@200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <950000>;
+ };
+ opp@300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <1000000>;
+ };
+ opp@400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1100000>;
+ };
+ opp@500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <1200000>;
+ };
+ opp@600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1250000>;
+ };
+ };
+
qos_gpu_r: qos@ffaa0000 {
compatible = "syscon";
reg = <0xffaa0000 0x20>;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Heiko Stübner, Neil Armstrong
Cc: Sjoerd Simons, Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Guillaume Tucker
In-Reply-To: <cover.1493125299.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
The ARM Mali Midgard GPU family is present in a number of SoCs
from many different vendors such as Samsung Exynos and Rockchip.
Import the device tree bindings documentation from the r16p0
release of the Mali Midgard GPU kernel driver:
https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
Remove the copyright and GPL licence header as deemed not necessary.
Redesign the "compatible" property strings to list all the Mali
Midgard GPU types and include optional vendor ones.
Drop the "clock-names" property as only one clock is used by the Mali
Midgard driver (which now needs to call clk_get with NULL).
Convert the "interrupt-names" property values to lower-case: "job",
"mmu" and "gpu".
Replace the deprecated "operating-points" optional property with
"operating-points-v2".
Omit the following optional properties in this initial version as they
are only used in very specific cases:
* snoop_enable_smc
* snoop_disable_smc
* jm_config
* power_model
* system-coherency
* ipa-model
Update the example accordingly to reflect all these changes.
CC: John Reitan <john.reitan-5wv7dgnIgG8@public.gmane.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
---
.../devicetree/bindings/gpu/arm,mali-midgard.txt | 82 ++++++++++++++++++++++
1 file changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
new file mode 100644
index 000000000000..547ddeceb498
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
@@ -0,0 +1,82 @@
+ARM Mali Midgard GPU
+====================
+
+Required properties:
+
+- compatible :
+ * Must be one of the following:
+ + "arm,mali-t60x"
+ + "arm,mali-t62x"
+ + "arm,mali-t720"
+ + "arm,mali-t760"
+ + "arm,mali-t820"
+ + "arm,mali-t830"
+ + "arm,mali-t860"
+ + "arm,mali-t880"
+ * And, optionally, one of the vendor specific compatible:
+ + "amlogic,meson-gxm-mali"
+ + "rockchip,rk3288-mali"
+
+- reg : Physical base address of the device and length of the register area.
+
+- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
+
+- interrupt-names : Contains the names of IRQ resources in the order they were
+ provided in the interrupts property. Must contain: "job", "mmu", "gpu".
+
+
+Optional properties:
+
+- clocks : Phandle to clock for the Mali Midgard device.
+
+- mali-supply : Phandle to regulator for the Mali device. Refer to
+ Documentation/devicetree/bindings/regulator/regulator.txt for details.
+
+- operating-points-v2 : Refer to Documentation/devicetree/bindings/power/opp.txt
+ for details.
+
+
+Example for a Mali-T602:
+
+gpu@fc010000 {
+ compatible = "arm,mali-t60x", "arm,mali-midgard";
+ reg = <0xfc010000 0x4000>;
+ interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&pclk_mali>;
+ mali-supply = <&vdd_mali>;
+ operating-points-v2 = <&gpu_opp_table>;
+};
+
+gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp@533000000 {
+ opp-hz = /bits/ 64 <533000000>;
+ opp-microvolt = <1250000>;
+ };
+ opp@450000000 {
+ opp-hz = /bits/ 64 <450000000>;
+ opp-microvolt = <1150000>;
+ };
+ opp@400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1125000>;
+ };
+ opp@350000000 {
+ opp-hz = /bits/ 64 <350000000>;
+ opp-microvolt = <1075000>;
+ };
+ opp@266000000 {
+ opp-hz = /bits/ 64 <266000000>;
+ opp-microvolt = <1025000>;
+ };
+ opp@160000000 {
+ opp-hz = /bits/ 64 <160000000>;
+ opp-microvolt = <925000>;
+ };
+ opp@100000000 {
+ opp-hz = /bits/ 64 <100000000>;
+ opp-microvolt = <912500>;
+ };
+};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
From: Guillaume Tucker @ 2017-04-25 13:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Heiko Stübner, Neil Armstrong
Cc: Sjoerd Simons, Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Guillaume Tucker
The ARM Mali Midgard GPU kernel driver is only available
out-of-tree and is not going to be merged in its current form.
However, it would be useful to have its device tree bindings
merged. In particular, this would enable distributions to create
working driver packages (dkms...) without having to patch the
kernel.
The bindings for the earlier Mali Utgard GPU family have already
been merged, so this is essentially the same scenario but for
newer GPUs (Mali-T604 ~ Mali-T880).
This series of patches first imports the bindings from the latest
driver release with some clean-up then adds a gpu node for the
rk3288 SoC. This was successfully tested on Radxa Rock2 Square,
Firefly, Veyron Minnie and Jerry boards using Mali kernel driver
r16p0 and r12p0 user-space binary.
Changes since v1:
- enabled gpu on rk3288-veyron boards
Changes since v2:
- removed "clk-names" property and "clk_mali" name
- converted values of "interrupt-names" property to
lower-case: "job", "mmu" and "gpu"
- replaced dt compatible strings with list of all Midgard GPU variants and
optional vendors
- cleaned up gpu node example
Changes since v3:
- add "rockchip,rk3288-mali" vendor compatible string
- move gpu node at the right location in rk3288.dtsi
- use operating-points-v2 in documentation and rk3288.dtsi
Enric Balletbo i Serra (1):
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron
Guillaume Tucker (4):
dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
ARM: dts: rockchip: add ARM Mali GPU node for rk3288
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly
.../devicetree/bindings/gpu/arm,mali-midgard.txt | 82 ++++++++++++++++++++++
arch/arm/boot/dts/rk3288-firefly.dtsi | 5 ++
arch/arm/boot/dts/rk3288-rock2-som.dtsi | 5 ++
arch/arm/boot/dts/rk3288-veyron.dtsi | 5 ++
arch/arm/boot/dts/rk3288.dtsi | 43 ++++++++++++
5 files changed, 140 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support
From: Arnd Bergmann @ 2017-04-25 12:38 UTC (permalink / raw)
To: Ryder Lee
Cc: Bjorn Helgaas, Rob Herring, linux-pci,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
Linux ARM, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1492935543-18190-2-git-send-email-ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> +static inline bool mtk_pcie_link_is_up(struct mtk_pcie_port *port)
> +{
> + return !!(readl_relaxed(port->base + PCIE_LINK_STATUS) &
> + PCIE_PORT_LINKUP);
> +}
If this is not performance critical, please use the regular readl() instead
of readl_relaxed().
> +static bool mtk_pcie_valid_device(struct mtk_pcie *pcie,
> + struct pci_bus *bus, int devfn)
> +{
> + struct mtk_pcie_port *port;
> + struct pci_dev *dev;
> + struct pci_bus *pbus;
> +
> + /* if there is no link, then there is no device */
> + list_for_each_entry(port, &pcie->ports, list) {
> + if (bus->number == 0 && port->index == PCI_SLOT(devfn) &&
> + mtk_pcie_link_is_up(port)) {
> + return true;
> + } else if (bus->number != 0) {
> + pbus = bus;
> + do {
> + dev = pbus->self;
> + if (port->index == PCI_SLOT(dev->devfn) &&
> + mtk_pcie_link_is_up(port)) {
> + return true;
> + }
> + pbus = dev->bus;
> + } while (dev->bus->number != 0);
> + }
> + }
> +
> + return false;
> +}
> +static int mtk_pcie_hw_rd_cfg(struct mtk_pcie *pcie, u32 bus, u32 devfn,
> + int where, int size, u32 *val)
> +{
> + writel(PCIE_CONF_ADDR(where, PCI_FUNC(devfn), PCI_SLOT(devfn), bus),
> + pcie->base + PCIE_CFG_ADDR);
> +
> + *val = 0;
> +
> + switch (size) {
> + case 1:
> + *val = readb(pcie->base + PCIE_CFG_DATA + (where & 3));
> + break;
> + case 2:
> + *val = readw(pcie->base + PCIE_CFG_DATA + (where & 2));
> + break;
> + case 4:
> + *val = readl(pcie->base + PCIE_CFG_DATA);
> + break;
> + }
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
This is a fairly standard set of read/write operations. Can you change
the pci_ops
to use pci_generic_config_read/pci_generic_config_write and an appropriate
map function instead?
> +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)
> +{
> + struct device *dev = pcie->dev;
> + struct mtk_pcie_port *port, *tmp;
> + int err, linkup = 0;
> +
> + list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
> + err = clk_prepare_enable(port->sys_ck);
> + if (err) {
> + dev_err(dev, "failed to enable port%d clock\n",
> + port->index);
> + continue;
> + }
> +
> + /* assert RC */
> + reset_control_assert(port->reset);
> + /* de-assert RC */
> + reset_control_deassert(port->reset);
> +
> + /* power on PHY */
> + err = phy_power_on(port->phy);
> + if (err) {
> + dev_err(dev, "failed to power on port%d phy\n",
> + port->index);
> + goto err_phy_on;
> + }
> +
> + mtk_pcie_assert_ports(port);
> +
Similar to the comment I had for the binding, I wonder if it would be
better to keep all the information about the ports in one place and
then just deal with it at the root level.
Alternatively, we could decide to standardize on the properties
you have added to the pcie port node, but then I would handle
them in the pcieport driver rather than in the host bridge driver.
> +/*
> + * This IP lacks interrupt status register to check or map INTx from
> + * different devices at the same time.
> + */
> +static int __init mtk_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> +{
> + struct mtk_pcie *pcie = dev->bus->sysdata;
> + struct mtk_pcie_port *port;
> +
> + list_for_each_entry(port, &pcie->ports, list)
> + if (port->index == slot)
> + return port->irq;
> +
> + return -1;
> +}
This looks odd, what is it needed for specifically? It looks like
it's broken for devices behind bridges, and the interrupt mapping
should normally come from the interrupt-map property, without
the need for a driver specific map_irq override.
> +static int mtk_pcie_register_ports(struct mtk_pcie *pcie)
> +{
> + struct pci_bus *bus, *child;
> +
> + bus = pci_scan_root_bus(pcie->dev, 0, &mtk_pcie_ops, pcie,
> + &pcie->resources);
Can you use the new pci_register_host_bridge() method instead of
pci_scan_root_bus() here?
ARnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe
From: Arnd Bergmann @ 2017-04-25 12:18 UTC (permalink / raw)
To: Ryder Lee
Cc: Bjorn Helgaas, Rob Herring, linux-pci,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
Linux ARM, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1492935543-18190-3-git-send-email-ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> Add documentation for PCIe host driver available in MT7623
> series SoCs.
>
> Signed-off-by: Ryder Lee <ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../bindings/pci/mediatek,mt7623-pcie.txt | 153 +++++++++++++++++++++
> 1 file changed, 153 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> new file mode 100644
> index 0000000..ee93ba2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7623-pcie.txt
> @@ -0,0 +1,153 @@
> +Mediatek MT7623 PCIe controller
> +
> +Required properties:
> +- compatible: Should contain "mediatek,mt7623-pcie".
Did mediatek license the IP block from someone else or was it
developed in-house? Is there a name and/or version identifier
for the block itself other than identifying it as the one in mt7623?
> +- device_type: Must be "pci"
> +- reg: Base addresses and lengths of the pcie controller.
> +- interrupts: A list of interrupt outputs of the controller.
Please be more specific about what each interrupt is for, and how
many there are.
> +Required properties:
> +- device_type: Must be "pci"
> +- assigned-addresses: Address and size of the port configuration registers
> +- reg: Only the first four bytes are used to refer to the correct bus number
> + and device number.
> +- #address-cells: Must be 3
> +- #size-cells: Must be 2
> +- ranges: Sub-ranges distributed from the PCIe controller node. An empty
> + property is sufficient.
> +- clocks: Must contain an entry for each entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> +- clock-names: Must include the following entries:
> + - sys_ck
> +- resets: Must contain an entry for each entry in reset-names.
> + See ../reset/reset.txt for details.
This seems odd: you have a device that is simply identified as "pci"
without any more specific ID, but you require additional properties
(clocks, reset, ...) that are not part of the standard PCI binding.
Can you clarify how the port devices related to the root device in
this hardware design?
Have you considered moving the nonstandard properties into the host
bridge node and having that device deal with setting up the links
to the other drivers? That way we could use the regular pcie
port driver for the children.
> +- reset-names: Must include the following entries:
> + - pcie-reset
> +- num-lanes: Number of lanes to use for this port.
> +- phys: Must contain an entry for each entry in phy-names.
> +- phy-names: Must include an entry for each sub node. Entries are of the form
> + "pcie-phyN": where N ranges from 0 to the value specified for port number.
> + See ../phy/phy-mt7623-pcie.txt for details.
I think the name should not include the number of the port but rather
be always the same here.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/7] v4l: Switch from V4L2 OF not V4L2 fwnode API
From: Sakari Ailus @ 2017-04-25 11:58 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-media, linux-acpi, devicetree, laurent.pinchart, hverkuil
In-Reply-To: <1493121374-13298-1-git-send-email-sakari.ailus@linux.intel.com>
Changes since v3:
- Convert recently merged ov5645 and ov5647 to V4L2 fwnode
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
^ permalink raw reply
* [PATCH v3.1 4/7] v4l: Switch from V4L2 OF not V4L2 fwnode API
From: Sakari Ailus @ 2017-04-25 11:56 UTC (permalink / raw)
To: linux-media; +Cc: linux-acpi, devicetree, laurent.pinchart, hverkuil
In-Reply-To: <1491829376-14791-5-git-send-email-sakari.ailus@linux.intel.com>
Switch users of the v4l2_of_ APIs to the more generic v4l2_fwnode_ APIs.
Async OF matching is replaced by fwnode matching and OF matching support
is removed.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Benoit Parrot <bparrot@ti.com> # i2c/ov2569.c, am437x/am437x-vpfe.c and ti-vpe/cal.c
Tested-by: Hans Verkuil <hans.verkuil@cisco.com> # Atmel sama5d3 board + ov2640 sensor
---
drivers/media/i2c/Kconfig | 11 +++++
drivers/media/i2c/adv7604.c | 7 +--
drivers/media/i2c/mt9v032.c | 7 +--
drivers/media/i2c/ov2659.c | 8 ++--
drivers/media/i2c/ov5645.c | 7 +--
drivers/media/i2c/ov5647.c | 7 +--
drivers/media/i2c/s5c73m3/s5c73m3-core.c | 7 +--
drivers/media/i2c/s5k5baf.c | 6 +--
drivers/media/i2c/smiapp/Kconfig | 1 +
drivers/media/i2c/smiapp/smiapp-core.c | 29 ++++++------
drivers/media/i2c/tc358743.c | 11 +++--
drivers/media/i2c/tvp514x.c | 6 +--
drivers/media/i2c/tvp5150.c | 7 +--
drivers/media/i2c/tvp7002.c | 6 +--
drivers/media/platform/Kconfig | 3 ++
drivers/media/platform/am437x/Kconfig | 1 +
drivers/media/platform/am437x/am437x-vpfe.c | 15 +++---
drivers/media/platform/atmel/Kconfig | 2 +
drivers/media/platform/atmel/atmel-isc.c | 13 ++++--
drivers/media/platform/atmel/atmel-isi.c | 11 +++--
drivers/media/platform/exynos4-is/Kconfig | 2 +
drivers/media/platform/exynos4-is/media-dev.c | 13 +++---
drivers/media/platform/exynos4-is/mipi-csis.c | 6 +--
drivers/media/platform/omap3isp/isp.c | 49 ++++++++++----------
drivers/media/platform/pxa_camera.c | 11 +++--
drivers/media/platform/rcar-vin/Kconfig | 1 +
drivers/media/platform/rcar-vin/rcar-core.c | 19 ++++----
drivers/media/platform/soc_camera/soc_camera.c | 7 +--
drivers/media/platform/ti-vpe/cal.c | 15 +++---
drivers/media/platform/xilinx/Kconfig | 1 +
drivers/media/platform/xilinx/xilinx-vipp.c | 63 ++++++++++++++------------
drivers/media/v4l2-core/v4l2-async.c | 14 +-----
include/media/v4l2-async.h | 5 --
33 files changed, 204 insertions(+), 167 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index b358d1a..aeb7485 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -210,6 +210,7 @@ config VIDEO_ADV7604
depends on GPIOLIB || COMPILE_TEST
select HDMI
select MEDIA_CEC_EDID
+ select V4L2_FWNODE
---help---
Support for the Analog Devices ADV7604 video decoder.
@@ -324,6 +325,7 @@ config VIDEO_TC358743
tristate "Toshiba TC358743 decoder"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
select HDMI
+ select V4L2_FWNODE
---help---
Support for the Toshiba TC358743 HDMI to MIPI CSI-2 bridge.
@@ -333,6 +335,7 @@ config VIDEO_TC358743
config VIDEO_TVP514X
tristate "Texas Instruments TVP514x video decoder"
depends on VIDEO_V4L2 && I2C
+ select V4L2_FWNODE
---help---
This is a Video4Linux2 sensor-level driver for the TI TVP5146/47
decoder. It is currently working with the TI OMAP3 camera
@@ -344,6 +347,7 @@ config VIDEO_TVP514X
config VIDEO_TVP5150
tristate "Texas Instruments TVP5150 video decoder"
depends on VIDEO_V4L2 && I2C
+ select V4L2_FWNODE
---help---
Support for the Texas Instruments TVP5150 video decoder.
@@ -353,6 +357,7 @@ config VIDEO_TVP5150
config VIDEO_TVP7002
tristate "Texas Instruments TVP7002 video decoder"
depends on VIDEO_V4L2 && I2C
+ select V4L2_FWNODE
---help---
Support for the Texas Instruments TVP7002 video decoder.
@@ -535,6 +540,7 @@ config VIDEO_OV2659
tristate "OmniVision OV2659 sensor support"
depends on VIDEO_V4L2 && I2C
depends on MEDIA_CAMERA_SUPPORT
+ select V4L2_FWNODE
---help---
This is a Video4Linux2 sensor-level driver for the OmniVision
OV2659 camera.
@@ -547,6 +553,7 @@ config VIDEO_OV5645
depends on OF
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
+ select V4L2_FWNODE
---help---
This is a Video4Linux2 sensor-level driver for the OmniVision
OV5645 camera.
@@ -558,6 +565,7 @@ config VIDEO_OV5647
tristate "OmniVision OV5647 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
+ select V4L2_FWNODE
---help---
This is a Video4Linux2 sensor-level driver for the OmniVision
OV5647 camera.
@@ -650,6 +658,7 @@ config VIDEO_MT9V032
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
select REGMAP_I2C
+ select V4L2_FWNODE
---help---
This is a Video4Linux2 sensor-level driver for the Micron
MT9V032 752x480 CMOS sensor.
@@ -697,6 +706,7 @@ config VIDEO_S5K4ECGX
config VIDEO_S5K5BAF
tristate "Samsung S5K5BAF sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ select V4L2_FWNODE
---help---
This is a V4L2 sensor-level driver for Samsung S5K5BAF 2M
camera sensor with an embedded SoC image signal processor.
@@ -707,6 +717,7 @@ source "drivers/media/i2c/et8ek8/Kconfig"
config VIDEO_S5C73M3
tristate "Samsung S5C73M3 sensor support"
depends on I2C && SPI && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+ select V4L2_FWNODE
---help---
This is a V4L2 sensor-level driver for Samsung S5C73M3
8 Mpixel camera.
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index f1fa9ce..660bacb 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -33,6 +33,7 @@
#include <linux/i2c.h>
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/of_graph.h>
#include <linux/slab.h>
#include <linux/v4l2-dv-timings.h>
#include <linux/videodev2.h>
@@ -45,7 +46,7 @@
#include <media/v4l2-device.h>
#include <media/v4l2-event.h>
#include <media/v4l2-dv-timings.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
static int debug;
module_param(debug, int, 0644);
@@ -3069,7 +3070,7 @@ MODULE_DEVICE_TABLE(of, adv76xx_of_id);
static int adv76xx_parse_dt(struct adv76xx_state *state)
{
- struct v4l2_of_endpoint bus_cfg;
+ struct v4l2_fwnode_endpoint bus_cfg;
struct device_node *endpoint;
struct device_node *np;
unsigned int flags;
@@ -3083,7 +3084,7 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
if (!endpoint)
return -EINVAL;
- ret = v4l2_of_parse_endpoint(endpoint, &bus_cfg);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg);
if (ret) {
of_node_put(endpoint);
return ret;
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 2e7a6e6..8a43064 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -19,6 +19,7 @@
#include <linux/log2.h>
#include <linux/mutex.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/videodev2.h>
@@ -28,7 +29,7 @@
#include <media/i2c/mt9v032.h>
#include <media/v4l2-ctrls.h>
#include <media/v4l2-device.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-subdev.h>
/* The first four rows are black rows. The active area spans 753x481 pixels. */
@@ -979,7 +980,7 @@ static struct mt9v032_platform_data *
mt9v032_get_pdata(struct i2c_client *client)
{
struct mt9v032_platform_data *pdata = NULL;
- struct v4l2_of_endpoint endpoint;
+ struct v4l2_fwnode_endpoint endpoint;
struct device_node *np;
struct property *prop;
@@ -990,7 +991,7 @@ mt9v032_get_pdata(struct i2c_client *client)
if (!np)
return NULL;
- if (v4l2_of_parse_endpoint(np, &endpoint) < 0)
+ if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(np), &endpoint) < 0)
goto done;
pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
index 6e63672..545ca3f 100644
--- a/drivers/media/i2c/ov2659.c
+++ b/drivers/media/i2c/ov2659.c
@@ -42,9 +42,9 @@
#include <media/v4l2-ctrls.h>
#include <media/v4l2-device.h>
#include <media/v4l2-event.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-image-sizes.h>
#include <media/v4l2-mediabus.h>
-#include <media/v4l2-of.h>
#include <media/v4l2-subdev.h>
#define DRIVER_NAME "ov2659"
@@ -1346,7 +1346,7 @@ static struct ov2659_platform_data *
ov2659_get_pdata(struct i2c_client *client)
{
struct ov2659_platform_data *pdata;
- struct v4l2_of_endpoint *bus_cfg;
+ struct v4l2_fwnode_endpoint *bus_cfg;
struct device_node *endpoint;
if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
@@ -1356,7 +1356,7 @@ ov2659_get_pdata(struct i2c_client *client)
if (!endpoint)
return NULL;
- bus_cfg = v4l2_of_alloc_parse_endpoint(endpoint);
+ bus_cfg = v4l2_fwnode_endpoint_alloc_parse(of_fwnode_handle(endpoint));
if (IS_ERR(bus_cfg)) {
pdata = NULL;
goto done;
@@ -1376,7 +1376,7 @@ ov2659_get_pdata(struct i2c_client *client)
pdata->link_frequency = bus_cfg->link_frequencies[0];
done:
- v4l2_of_free_endpoint(bus_cfg);
+ v4l2_fwnode_endpoint_free(bus_cfg);
of_node_put(endpoint);
return pdata;
}
diff --git a/drivers/media/i2c/ov5645.c b/drivers/media/i2c/ov5645.c
index 57bd591..d1e844f 100644
--- a/drivers/media/i2c/ov5645.c
+++ b/drivers/media/i2c/ov5645.c
@@ -39,7 +39,7 @@
#include <linux/slab.h>
#include <linux/types.h>
#include <media/v4l2-ctrls.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-subdev.h>
#define OV5645_VOLTAGE_ANALOG 2800000
@@ -87,7 +87,7 @@ struct ov5645 {
struct device *dev;
struct v4l2_subdev sd;
struct media_pad pad;
- struct v4l2_of_endpoint ep;
+ struct v4l2_fwnode_endpoint ep;
struct v4l2_mbus_framefmt fmt;
struct v4l2_rect crop;
struct clk *xclk;
@@ -1102,7 +1102,8 @@ static int ov5645_probe(struct i2c_client *client,
return -EINVAL;
}
- ret = v4l2_of_parse_endpoint(endpoint, &ov5645->ep);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint),
+ &ov5645->ep);
if (ret < 0) {
dev_err(dev, "parsing endpoint node failed\n");
return ret;
diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
index f57a0b3..95ce90f 100644
--- a/drivers/media/i2c/ov5647.c
+++ b/drivers/media/i2c/ov5647.c
@@ -25,12 +25,13 @@
#include <linux/init.h>
#include <linux/io.h>
#include <linux/module.h>
+#include <linux/of_graph.h>
#include <linux/slab.h>
#include <linux/videodev2.h>
#include <media/v4l2-device.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-image-sizes.h>
#include <media/v4l2-mediabus.h>
-#include <media/v4l2-of.h>
#define SENSOR_NAME "ov5647"
@@ -510,7 +511,7 @@ static const struct v4l2_subdev_internal_ops ov5647_subdev_internal_ops = {
static int ov5647_parse_dt(struct device_node *np)
{
- struct v4l2_of_endpoint bus_cfg;
+ struct v4l2_fwnode_endpoint bus_cfg;
struct device_node *ep;
int ret;
@@ -519,7 +520,7 @@ static int ov5647_parse_dt(struct device_node *np)
if (!ep)
return -EINVAL;
- ret = v4l2_of_parse_endpoint(ep, &bus_cfg);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &bus_cfg);
of_node_put(ep);
return ret;
diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index 3844853..f434fb2 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -24,6 +24,7 @@
#include <linux/media.h>
#include <linux/module.h>
#include <linux/of_gpio.h>
+#include <linux/of_graph.h>
#include <linux/regulator/consumer.h>
#include <linux/sizes.h>
#include <linux/slab.h>
@@ -35,7 +36,7 @@
#include <media/v4l2-subdev.h>
#include <media/v4l2-mediabus.h>
#include <media/i2c/s5c73m3.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include "s5c73m3.h"
@@ -1602,7 +1603,7 @@ static int s5c73m3_get_platform_data(struct s5c73m3 *state)
const struct s5c73m3_platform_data *pdata = dev->platform_data;
struct device_node *node = dev->of_node;
struct device_node *node_ep;
- struct v4l2_of_endpoint ep;
+ struct v4l2_fwnode_endpoint ep;
int ret;
if (!node) {
@@ -1639,7 +1640,7 @@ static int s5c73m3_get_platform_data(struct s5c73m3 *state)
return 0;
}
- ret = v4l2_of_parse_endpoint(node_ep, &ep);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(node_ep), &ep);
of_node_put(node_ep);
if (ret)
return ret;
diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
index db82ed0..962051b 100644
--- a/drivers/media/i2c/s5k5baf.c
+++ b/drivers/media/i2c/s5k5baf.c
@@ -30,7 +30,7 @@
#include <media/v4l2-device.h>
#include <media/v4l2-subdev.h>
#include <media/v4l2-mediabus.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
static int debug;
module_param(debug, int, 0644);
@@ -1841,7 +1841,7 @@ static int s5k5baf_parse_device_node(struct s5k5baf *state, struct device *dev)
{
struct device_node *node = dev->of_node;
struct device_node *node_ep;
- struct v4l2_of_endpoint ep;
+ struct v4l2_fwnode_endpoint ep;
int ret;
if (!node) {
@@ -1868,7 +1868,7 @@ static int s5k5baf_parse_device_node(struct s5k5baf *state, struct device *dev)
return -EINVAL;
}
- ret = v4l2_of_parse_endpoint(node_ep, &ep);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(node_ep), &ep);
of_node_put(node_ep);
if (ret)
return ret;
diff --git a/drivers/media/i2c/smiapp/Kconfig b/drivers/media/i2c/smiapp/Kconfig
index 3149cda..f59718d 100644
--- a/drivers/media/i2c/smiapp/Kconfig
+++ b/drivers/media/i2c/smiapp/Kconfig
@@ -3,5 +3,6 @@ config VIDEO_SMIAPP
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAVE_CLK
depends on MEDIA_CAMERA_SUPPORT
select VIDEO_SMIAPP_PLL
+ select V4L2_FWNODE
---help---
This is a generic driver for SMIA++/SMIA camera modules.
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c
index f4e92bd..e0b0c03 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -27,12 +27,13 @@
#include <linux/gpio/consumer.h>
#include <linux/module.h>
#include <linux/pm_runtime.h>
+#include <linux/property.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/smiapp.h>
#include <linux/v4l2-mediabus.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-device.h>
-#include <media/v4l2-of.h>
#include "smiapp.h"
@@ -2784,19 +2785,20 @@ static int __maybe_unused smiapp_resume(struct device *dev)
static struct smiapp_hwconfig *smiapp_get_hwconfig(struct device *dev)
{
struct smiapp_hwconfig *hwcfg;
- struct v4l2_of_endpoint *bus_cfg;
- struct device_node *ep;
+ struct v4l2_fwnode_endpoint *bus_cfg;
+ struct fwnode_handle *ep;
+ struct fwnode_handle *fwnode = dev_fwnode(dev);
int i;
int rval;
- if (!dev->of_node)
+ if (!fwnode)
return dev->platform_data;
- ep = of_graph_get_next_endpoint(dev->of_node, NULL);
+ ep = fwnode_graph_get_next_endpoint(fwnode, NULL);
if (!ep)
return NULL;
- bus_cfg = v4l2_of_alloc_parse_endpoint(ep);
+ bus_cfg = v4l2_fwnode_endpoint_alloc_parse(ep);
if (IS_ERR(bus_cfg))
goto out_err;
@@ -2817,11 +2819,10 @@ static struct smiapp_hwconfig *smiapp_get_hwconfig(struct device *dev)
dev_dbg(dev, "lanes %u\n", hwcfg->lanes);
/* NVM size is not mandatory */
- of_property_read_u32(dev->of_node, "nokia,nvm-size",
- &hwcfg->nvm_size);
+ fwnode_property_read_u32(fwnode, "nokia,nvm-size", &hwcfg->nvm_size);
- rval = of_property_read_u32(dev->of_node, "clock-frequency",
- &hwcfg->ext_clk);
+ rval = fwnode_property_read_u32(fwnode, "clock-frequency",
+ &hwcfg->ext_clk);
if (rval) {
dev_warn(dev, "can't get clock-frequency\n");
goto out_err;
@@ -2846,13 +2847,13 @@ static struct smiapp_hwconfig *smiapp_get_hwconfig(struct device *dev)
dev_dbg(dev, "freq %d: %lld\n", i, hwcfg->op_sys_clock[i]);
}
- v4l2_of_free_endpoint(bus_cfg);
- of_node_put(ep);
+ v4l2_fwnode_endpoint_free(bus_cfg);
+ fwnode_handle_put(ep);
return hwcfg;
out_err:
- v4l2_of_free_endpoint(bus_cfg);
- of_node_put(ep);
+ v4l2_fwnode_endpoint_free(bus_cfg);
+ fwnode_handle_put(ep);
return NULL;
}
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index acef4ec..052d164 100644
--- a/drivers/media/i2c/tc358743.c
+++ b/drivers/media/i2c/tc358743.c
@@ -33,6 +33,7 @@
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
#include <linux/interrupt.h>
+#include <linux/of_graph.h>
#include <linux/videodev2.h>
#include <linux/workqueue.h>
#include <linux/v4l2-dv-timings.h>
@@ -41,7 +42,7 @@
#include <media/v4l2-device.h>
#include <media/v4l2-ctrls.h>
#include <media/v4l2-event.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/i2c/tc358743.h>
#include "tc358743_regs.h"
@@ -76,7 +77,7 @@ static const struct v4l2_dv_timings_cap tc358743_timings_cap = {
struct tc358743_state {
struct tc358743_platform_data pdata;
- struct v4l2_of_bus_mipi_csi2 bus;
+ struct v4l2_fwnode_bus_mipi_csi2 bus;
struct v4l2_subdev sd;
struct media_pad pad;
struct v4l2_ctrl_handler hdl;
@@ -1695,7 +1696,7 @@ static void tc358743_gpio_reset(struct tc358743_state *state)
static int tc358743_probe_of(struct tc358743_state *state)
{
struct device *dev = &state->i2c_client->dev;
- struct v4l2_of_endpoint *endpoint;
+ struct v4l2_fwnode_endpoint *endpoint;
struct device_node *ep;
struct clk *refclk;
u32 bps_pr_lane;
@@ -1715,7 +1716,7 @@ static int tc358743_probe_of(struct tc358743_state *state)
return -EINVAL;
}
- endpoint = v4l2_of_alloc_parse_endpoint(ep);
+ endpoint = v4l2_fwnode_endpoint_alloc_parse(of_fwnode_handle(ep));
if (IS_ERR(endpoint)) {
dev_err(dev, "failed to parse endpoint\n");
return PTR_ERR(endpoint);
@@ -1803,7 +1804,7 @@ static int tc358743_probe_of(struct tc358743_state *state)
disable_clk:
clk_disable_unprepare(refclk);
free_endpoint:
- v4l2_of_free_endpoint(endpoint);
+ v4l2_fwnode_endpoint_free(endpoint);
return ret;
}
#else
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 07853d2..ad2df99 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -38,7 +38,7 @@
#include <media/v4l2-device.h>
#include <media/v4l2-common.h>
#include <media/v4l2-mediabus.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-ctrls.h>
#include <media/i2c/tvp514x.h>
#include <media/media-entity.h>
@@ -998,7 +998,7 @@ static struct tvp514x_platform_data *
tvp514x_get_pdata(struct i2c_client *client)
{
struct tvp514x_platform_data *pdata = NULL;
- struct v4l2_of_endpoint bus_cfg;
+ struct v4l2_fwnode_endpoint bus_cfg;
struct device_node *endpoint;
unsigned int flags;
@@ -1009,7 +1009,7 @@ tvp514x_get_pdata(struct i2c_client *client)
if (!endpoint)
return NULL;
- if (v4l2_of_parse_endpoint(endpoint, &bus_cfg))
+ if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
goto done;
pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 04e96b3..9da4bf4 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -12,10 +12,11 @@
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
#include <linux/module.h>
+#include <linux/of_graph.h>
#include <media/v4l2-async.h>
#include <media/v4l2-device.h>
#include <media/v4l2-ctrls.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-mc.h>
#include "tvp5150_reg.h"
@@ -1358,7 +1359,7 @@ static int tvp5150_init(struct i2c_client *c)
static int tvp5150_parse_dt(struct tvp5150 *decoder, struct device_node *np)
{
- struct v4l2_of_endpoint bus_cfg;
+ struct v4l2_fwnode_endpoint bus_cfg;
struct device_node *ep;
#ifdef CONFIG_MEDIA_CONTROLLER
struct device_node *connectors, *child;
@@ -1373,7 +1374,7 @@ static int tvp5150_parse_dt(struct tvp5150 *decoder, struct device_node *np)
if (!ep)
return -EINVAL;
- ret = v4l2_of_parse_endpoint(ep, &bus_cfg);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &bus_cfg);
if (ret)
goto err;
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index 4c11901..a26c1a3 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -33,7 +33,7 @@
#include <media/v4l2-device.h>
#include <media/v4l2-common.h>
#include <media/v4l2-ctrls.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include "tvp7002_reg.h"
@@ -889,7 +889,7 @@ static const struct v4l2_subdev_ops tvp7002_ops = {
static struct tvp7002_config *
tvp7002_get_pdata(struct i2c_client *client)
{
- struct v4l2_of_endpoint bus_cfg;
+ struct v4l2_fwnode_endpoint bus_cfg;
struct tvp7002_config *pdata = NULL;
struct device_node *endpoint;
unsigned int flags;
@@ -901,7 +901,7 @@ tvp7002_get_pdata(struct i2c_client *client)
if (!endpoint)
return NULL;
- if (v4l2_of_parse_endpoint(endpoint, &bus_cfg))
+ if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
goto done;
pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 73c3bc5..4150b2c 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -82,6 +82,7 @@ config VIDEO_OMAP3
select ARM_DMA_USE_IOMMU
select VIDEOBUF2_DMA_CONTIG
select MFD_SYSCON
+ select V4L2_FWNODE
---help---
Driver for an OMAP 3 camera controller.
@@ -97,6 +98,7 @@ config VIDEO_PXA27x
depends on PXA27x || COMPILE_TEST
select VIDEOBUF2_DMA_SG
select SG_SPLIT
+ select V4L2_FWNODE
---help---
This is a v4l2 driver for the PXA27x Quick Capture Interface
@@ -127,6 +129,7 @@ config VIDEO_TI_CAL
depends on SOC_DRA7XX || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
+ select V4L2_FWNODE
default n
---help---
Support for the TI CAL (Camera Adaptation Layer) block
diff --git a/drivers/media/platform/am437x/Kconfig b/drivers/media/platform/am437x/Kconfig
index 42d9c18..160e77e 100644
--- a/drivers/media/platform/am437x/Kconfig
+++ b/drivers/media/platform/am437x/Kconfig
@@ -3,6 +3,7 @@ config VIDEO_AM437X_VPFE
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
depends on SOC_AM43XX || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
+ select V4L2_FWNODE
help
Support for AM437x Video Processing Front End based Video
Capture Driver.
diff --git a/drivers/media/platform/am437x/am437x-vpfe.c b/drivers/media/platform/am437x/am437x-vpfe.c
index 05489a4..466aba8 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -26,6 +26,7 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/module.h>
+#include <linux/of_graph.h>
#include <linux/pinctrl/consumer.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
@@ -36,7 +37,7 @@
#include <media/v4l2-common.h>
#include <media/v4l2-ctrls.h>
#include <media/v4l2-event.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include "am437x-vpfe.h"
@@ -2303,7 +2304,8 @@ vpfe_async_bound(struct v4l2_async_notifier *notifier,
vpfe_dbg(1, vpfe, "vpfe_async_bound\n");
for (i = 0; i < ARRAY_SIZE(vpfe->cfg->asd); i++) {
- if (vpfe->cfg->asd[i]->match.of.node == asd[i].match.of.node) {
+ if (vpfe->cfg->asd[i]->match.fwnode.fwnode ==
+ asd[i].match.fwnode.fwnode) {
sdinfo = &vpfe->cfg->sub_devs[i];
vpfe->sd[i] = subdev;
vpfe->sd[i]->grp_id = sdinfo->grp_id;
@@ -2419,7 +2421,7 @@ static struct vpfe_config *
vpfe_get_pdata(struct platform_device *pdev)
{
struct device_node *endpoint = NULL;
- struct v4l2_of_endpoint bus_cfg;
+ struct v4l2_fwnode_endpoint bus_cfg;
struct vpfe_subdev_info *sdinfo;
struct vpfe_config *pdata;
unsigned int flags;
@@ -2463,7 +2465,8 @@ vpfe_get_pdata(struct platform_device *pdev)
sdinfo->vpfe_param.if_type = VPFE_RAW_BAYER;
}
- err = v4l2_of_parse_endpoint(endpoint, &bus_cfg);
+ err = v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint),
+ &bus_cfg);
if (err) {
dev_err(&pdev->dev, "Could not parse the endpoint\n");
goto done;
@@ -2501,8 +2504,8 @@ vpfe_get_pdata(struct platform_device *pdev)
goto done;
}
- pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_OF;
- pdata->asd[i]->match.of.node = rem;
+ pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
+ pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
of_node_put(rem);
}
diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig
index 9bd0f19..55de751 100644
--- a/drivers/media/platform/atmel/Kconfig
+++ b/drivers/media/platform/atmel/Kconfig
@@ -4,6 +4,7 @@ config VIDEO_ATMEL_ISC
depends on ARCH_AT91 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select REGMAP_MMIO
+ select V4L2_FWNODE
help
This module makes the ATMEL Image Sensor Controller available
as a v4l2 device.
@@ -13,6 +14,7 @@ config VIDEO_ATMEL_ISI
depends on VIDEO_V4L2 && OF && HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
+ select V4L2_FWNODE
---help---
This module makes the ATMEL Image Sensor Interface available
as a v4l2 device.
diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
index 7dacf8c..380a95e 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -32,6 +32,7 @@
#include <linux/math64.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regmap.h>
@@ -42,7 +43,7 @@
#include <media/v4l2-event.h>
#include <media/v4l2-image-sizes.h>
#include <media/v4l2-ioctl.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-subdev.h>
#include <media/videobuf2-dma-contig.h>
@@ -1683,7 +1684,7 @@ static int isc_parse_dt(struct device *dev, struct isc_device *isc)
{
struct device_node *np = dev->of_node;
struct device_node *epn = NULL, *rem;
- struct v4l2_of_endpoint v4l2_epn;
+ struct v4l2_fwnode_endpoint v4l2_epn;
struct isc_subdev_entity *subdev_entity;
unsigned int flags;
int ret;
@@ -1702,7 +1703,8 @@ static int isc_parse_dt(struct device *dev, struct isc_device *isc)
continue;
}
- ret = v4l2_of_parse_endpoint(epn, &v4l2_epn);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(epn),
+ &v4l2_epn);
if (ret) {
of_node_put(rem);
ret = -EINVAL;
@@ -1737,8 +1739,9 @@ static int isc_parse_dt(struct device *dev, struct isc_device *isc)
if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
- subdev_entity->asd->match_type = V4L2_ASYNC_MATCH_OF;
- subdev_entity->asd->match.of.node = rem;
+ subdev_entity->asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
+ subdev_entity->asd->match.fwnode.fwnode =
+ of_fwnode_handle(rem);
list_add_tail(&subdev_entity->list, &isc->subdev_entities);
}
diff --git a/drivers/media/platform/atmel/atmel-isi.c b/drivers/media/platform/atmel/atmel-isi.c
index e4867f8..ef482cc 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -19,6 +19,7 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/of_graph.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/slab.h>
@@ -30,7 +31,7 @@
#include <media/v4l2-dev.h>
#include <media/v4l2-ioctl.h>
#include <media/v4l2-event.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/videobuf2-dma-contig.h>
#include <media/v4l2-image-sizes.h>
@@ -801,7 +802,7 @@ static int atmel_isi_parse_dt(struct atmel_isi *isi,
struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct v4l2_of_endpoint ep;
+ struct v4l2_fwnode_endpoint ep;
int err;
/* Default settings for ISI */
@@ -814,7 +815,7 @@ static int atmel_isi_parse_dt(struct atmel_isi *isi,
return -EINVAL;
}
- err = v4l2_of_parse_endpoint(np, &ep);
+ err = v4l2_fwnode_endpoint_parse(of_fwnode_handle(np), &ep);
of_node_put(np);
if (err) {
dev_err(&pdev->dev, "Could not parse the endpoint\n");
@@ -1126,8 +1127,8 @@ static int isi_graph_parse(struct atmel_isi *isi, struct device_node *node)
/* Remote node to connect */
isi->entity.node = remote;
- isi->entity.asd.match_type = V4L2_ASYNC_MATCH_OF;
- isi->entity.asd.match.of.node = remote;
+ isi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
+ isi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
return 0;
}
}
diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig
index 57d42c6..c480efb 100644
--- a/drivers/media/platform/exynos4-is/Kconfig
+++ b/drivers/media/platform/exynos4-is/Kconfig
@@ -4,6 +4,7 @@ config VIDEO_SAMSUNG_EXYNOS4_IS
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
depends on OF && COMMON_CLK
+ select V4L2_FWNODE
help
Say Y here to enable camera host interface devices for
Samsung S5P and EXYNOS SoC series.
@@ -32,6 +33,7 @@ config VIDEO_S5P_MIPI_CSIS
tristate "S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver"
depends on REGULATOR
select GENERIC_PHY
+ select V4L2_FWNODE
help
This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2
receiver (MIPI-CSIS) devices.
diff --git a/drivers/media/platform/exynos4-is/media-dev.c b/drivers/media/platform/exynos4-is/media-dev.c
index e82450e9..7d1cf78 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -29,7 +29,7 @@
#include <linux/slab.h>
#include <media/v4l2-async.h>
#include <media/v4l2-ctrls.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/media-device.h>
#include <media/drv-intf/exynos-fimc.h>
@@ -388,7 +388,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
{
struct fimc_source_info *pd = &fmd->sensor[index].pdata;
struct device_node *rem, *ep, *np;
- struct v4l2_of_endpoint endpoint;
+ struct v4l2_fwnode_endpoint endpoint;
int ret;
/* Assume here a port node can have only one endpoint node. */
@@ -396,7 +396,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
if (!ep)
return 0;
- ret = v4l2_of_parse_endpoint(ep, &endpoint);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &endpoint);
if (ret) {
of_node_put(ep);
return ret;
@@ -453,8 +453,8 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
return -EINVAL;
}
- fmd->sensor[index].asd.match_type = V4L2_ASYNC_MATCH_OF;
- fmd->sensor[index].asd.match.of.node = rem;
+ fmd->sensor[index].asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
+ fmd->sensor[index].asd.match.fwnode.fwnode = of_fwnode_handle(rem);
fmd->async_subdevs[index] = &fmd->sensor[index].asd;
fmd->num_sensors++;
@@ -1361,7 +1361,8 @@ static int subdev_notifier_bound(struct v4l2_async_notifier *notifier,
/* Find platform data for this sensor subdev */
for (i = 0; i < ARRAY_SIZE(fmd->sensor); i++)
- if (fmd->sensor[i].asd.match.of.node == subdev->dev->of_node)
+ if (fmd->sensor[i].asd.match.fwnode.fwnode ==
+ of_fwnode_handle(subdev->dev->of_node))
si = &fmd->sensor[i];
if (si == NULL)
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index f819b29..98c8987 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -30,7 +30,7 @@
#include <linux/spinlock.h>
#include <linux/videodev2.h>
#include <media/drv-intf/exynos-fimc.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-subdev.h>
#include "mipi-csis.h"
@@ -718,7 +718,7 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
struct csis_state *state)
{
struct device_node *node = pdev->dev.of_node;
- struct v4l2_of_endpoint endpoint;
+ struct v4l2_fwnode_endpoint endpoint;
int ret;
if (of_property_read_u32(node, "clock-frequency",
@@ -735,7 +735,7 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
return -EINVAL;
}
/* Get port node and validate MIPI-CSI channel id. */
- ret = v4l2_of_parse_endpoint(node, &endpoint);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(node), &endpoint);
if (ret)
goto err;
diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c
index 084ecf4a..d8fba9c 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -55,6 +55,7 @@
#include <linux/module.h>
#include <linux/omap-iommu.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/sched.h>
@@ -63,9 +64,9 @@
#include <asm/dma-iommu.h>
#include <media/v4l2-common.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-device.h>
#include <media/v4l2-mc.h>
-#include <media/v4l2-of.h>
#include "isp.h"
#include "ispreg.h"
@@ -2024,20 +2025,20 @@ enum isp_of_phy {
ISP_OF_PHY_CSIPHY2,
};
-static int isp_of_parse_node(struct device *dev, struct device_node *node,
- struct isp_async_subdev *isd)
+static int isp_fwnode_parse(struct device *dev, struct fwnode_handle *fwnode,
+ struct isp_async_subdev *isd)
{
struct isp_bus_cfg *buscfg = &isd->bus;
- struct v4l2_of_endpoint vep;
+ struct v4l2_fwnode_endpoint vep;
unsigned int i;
int ret;
- ret = v4l2_of_parse_endpoint(node, &vep);
+ ret = v4l2_fwnode_endpoint_parse(fwnode, &vep);
if (ret)
return ret;
- dev_dbg(dev, "parsing endpoint %s, interface %u\n", node->full_name,
- vep.base.port);
+ dev_dbg(dev, "parsing endpoint %s, interface %u\n",
+ to_of_node(fwnode)->full_name, vep.base.port);
switch (vep.base.port) {
case ISP_OF_PHY_PARALLEL:
@@ -2094,18 +2095,18 @@ static int isp_of_parse_node(struct device *dev, struct device_node *node,
break;
default:
- dev_warn(dev, "%s: invalid interface %u\n", node->full_name,
- vep.base.port);
+ dev_warn(dev, "%s: invalid interface %u\n",
+ to_of_node(fwnode)->full_name, vep.base.port);
break;
}
return 0;
}
-static int isp_of_parse_nodes(struct device *dev,
- struct v4l2_async_notifier *notifier)
+static int isp_fwnodes_parse(struct device *dev,
+ struct v4l2_async_notifier *notifier)
{
- struct device_node *node = NULL;
+ struct fwnode_handle *fwnode = NULL;
notifier->subdevs = devm_kcalloc(
dev, ISP_MAX_SUBDEVS, sizeof(*notifier->subdevs), GFP_KERNEL);
@@ -2113,7 +2114,8 @@ static int isp_of_parse_nodes(struct device *dev,
return -ENOMEM;
while (notifier->num_subdevs < ISP_MAX_SUBDEVS &&
- (node = of_graph_get_next_endpoint(dev->of_node, node))) {
+ (fwnode = fwnode_graph_get_next_endpoint(
+ of_fwnode_handle(dev->of_node), fwnode))) {
struct isp_async_subdev *isd;
isd = devm_kzalloc(dev, sizeof(*isd), GFP_KERNEL);
@@ -2122,23 +2124,24 @@ static int isp_of_parse_nodes(struct device *dev,
notifier->subdevs[notifier->num_subdevs] = &isd->asd;
- if (isp_of_parse_node(dev, node, isd))
+ if (isp_fwnode_parse(dev, fwnode, isd))
goto error;
- isd->asd.match.of.node = of_graph_get_remote_port_parent(node);
- if (!isd->asd.match.of.node) {
+ isd->asd.match.fwnode.fwnode =
+ fwnode_graph_get_remote_port_parent(fwnode);
+ if (!isd->asd.match.fwnode.fwnode) {
dev_warn(dev, "bad remote port parent\n");
goto error;
}
- isd->asd.match_type = V4L2_ASYNC_MATCH_OF;
+ isd->asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
notifier->num_subdevs++;
}
return notifier->num_subdevs;
error:
- of_node_put(node);
+ fwnode_handle_put(fwnode);
return -EINVAL;
}
@@ -2209,8 +2212,8 @@ static int isp_probe(struct platform_device *pdev)
return -ENOMEM;
}
- ret = of_property_read_u32(pdev->dev.of_node, "ti,phy-type",
- &isp->phy_type);
+ ret = fwnode_property_read_u32(of_fwnode_handle(pdev->dev.of_node),
+ "ti,phy-type", &isp->phy_type);
if (ret)
return ret;
@@ -2219,12 +2222,12 @@ static int isp_probe(struct platform_device *pdev)
if (IS_ERR(isp->syscon))
return PTR_ERR(isp->syscon);
- ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1,
- &isp->syscon_offset);
+ ret = of_property_read_u32_index(pdev->dev.of_node,
+ "syscon", 1, &isp->syscon_offset);
if (ret)
return ret;
- ret = isp_of_parse_nodes(&pdev->dev, &isp->notifier);
+ ret = isp_fwnodes_parse(&pdev->dev, &isp->notifier);
if (ret < 0)
return ret;
diff --git a/drivers/media/platform/pxa_camera.c b/drivers/media/platform/pxa_camera.c
index 929006f..ebf9ea9 100644
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -25,6 +25,7 @@
#include <linux/mm.h>
#include <linux/moduleparam.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
#include <linux/time.h>
#include <linux/platform_device.h>
#include <linux/clk.h>
@@ -39,7 +40,7 @@
#include <media/v4l2-common.h>
#include <media/v4l2-device.h>
#include <media/v4l2-ioctl.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/videobuf2-dma-sg.h>
@@ -2236,7 +2237,7 @@ static int pxa_camera_pdata_from_dt(struct device *dev,
{
u32 mclk_rate;
struct device_node *remote, *np = dev->of_node;
- struct v4l2_of_endpoint ep;
+ struct v4l2_fwnode_endpoint ep;
int err = of_property_read_u32(np, "clock-frequency",
&mclk_rate);
if (!err) {
@@ -2250,7 +2251,7 @@ static int pxa_camera_pdata_from_dt(struct device *dev,
return -EINVAL;
}
- err = v4l2_of_parse_endpoint(np, &ep);
+ err = v4l2_fwnode_endpoint_parse(of_fwnode_handle(np), &ep);
if (err) {
dev_err(dev, "could not parse endpoint\n");
goto out;
@@ -2287,10 +2288,10 @@ static int pxa_camera_pdata_from_dt(struct device *dev,
if (ep.bus.parallel.flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
pcdev->platform_flags |= PXA_CAMERA_PCLK_EN;
- asd->match_type = V4L2_ASYNC_MATCH_OF;
+ asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
remote = of_graph_get_remote_port(np);
if (remote) {
- asd->match.of.node = remote;
+ asd->match.fwnode.fwnode = of_fwnode_handle(remote);
of_node_put(remote);
} else {
dev_notice(dev, "no remote for %s\n", of_node_full_name(np));
diff --git a/drivers/media/platform/rcar-vin/Kconfig b/drivers/media/platform/rcar-vin/Kconfig
index 111d2a1..af4c98b 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -3,6 +3,7 @@ config VIDEO_RCAR_VIN
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && MEDIA_CONTROLLER
depends on ARCH_RENESAS || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
+ select V4L2_FWNODE
---help---
Support for Renesas R-Car Video Input (VIN) driver.
Supports R-Car Gen2 SoCs.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
index 098a0b1..264604a 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -21,7 +21,7 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include "rcar-vin.h"
@@ -104,7 +104,8 @@ static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
v4l2_set_subdev_hostdata(subdev, vin);
- if (vin->digital.asd.match.of.node == subdev->dev->of_node) {
+ if (vin->digital.asd.match.fwnode.fwnode ==
+ of_fwnode_handle(subdev->dev->of_node)) {
vin_dbg(vin, "bound digital subdev %s\n", subdev->name);
vin->digital.subdev = subdev;
return 0;
@@ -118,10 +119,10 @@ static int rvin_digitial_parse_v4l2(struct rvin_dev *vin,
struct device_node *ep,
struct v4l2_mbus_config *mbus_cfg)
{
- struct v4l2_of_endpoint v4l2_ep;
+ struct v4l2_fwnode_endpoint v4l2_ep;
int ret;
- ret = v4l2_of_parse_endpoint(ep, &v4l2_ep);
+ ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &v4l2_ep);
if (ret) {
vin_err(vin, "Could not parse v4l2 endpoint\n");
return -EINVAL;
@@ -151,7 +152,7 @@ static int rvin_digital_graph_parse(struct rvin_dev *vin)
struct device_node *ep, *np;
int ret;
- vin->digital.asd.match.of.node = NULL;
+ vin->digital.asd.match.fwnode.fwnode = NULL;
vin->digital.subdev = NULL;
/*
@@ -175,8 +176,8 @@ static int rvin_digital_graph_parse(struct rvin_dev *vin)
if (ret)
return ret;
- vin->digital.asd.match.of.node = np;
- vin->digital.asd.match_type = V4L2_ASYNC_MATCH_OF;
+ vin->digital.asd.match.fwnode.fwnode = of_fwnode_handle(np);
+ vin->digital.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
return 0;
}
@@ -190,7 +191,7 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
if (ret)
return ret;
- if (!vin->digital.asd.match.of.node) {
+ if (!vin->digital.asd.match.fwnode.fwnode) {
vin_dbg(vin, "No digital subdevice found\n");
return -ENODEV;
}
@@ -203,7 +204,7 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
subdevs[0] = &vin->digital.asd;
vin_dbg(vin, "Found digital subdevice %s\n",
- of_node_full_name(subdevs[0]->match.of.node));
+ of_node_full_name(to_of_node(subdevs[0]->match.fwnode.fwnode)));
vin->notifier.num_subdevs = 1;
vin->notifier.subdevs = subdevs;
diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c
index 3c9421f..45a0429 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -23,6 +23,7 @@
#include <linux/list.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/of_graph.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/regulator/consumer.h>
@@ -36,7 +37,7 @@
#include <media/v4l2-common.h>
#include <media/v4l2-ioctl.h>
#include <media/v4l2-dev.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/videobuf2-v4l2.h>
/* Default to VGA resolution */
@@ -1512,8 +1513,8 @@ static int soc_of_bind(struct soc_camera_host *ici,
if (!info)
return -ENOMEM;
- info->sasd.asd.match.of.node = remote;
- info->sasd.asd.match_type = V4L2_ASYNC_MATCH_OF;
+ info->sasd.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
+ info->sasd.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
info->subdev = &info->sasd.asd;
/* Or shall this be managed by the soc-camera device? */
diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c
index 7a058b6..177faa3 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -21,7 +21,7 @@
#include <linux/of_device.h>
#include <linux/of_graph.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include <media/v4l2-async.h>
#include <media/v4l2-common.h>
#include <media/v4l2-ctrls.h>
@@ -270,7 +270,7 @@ struct cal_ctx {
struct video_device vdev;
struct v4l2_async_notifier notifier;
struct v4l2_subdev *sensor;
- struct v4l2_of_endpoint endpoint;
+ struct v4l2_fwnode_endpoint endpoint;
struct v4l2_async_subdev asd;
struct v4l2_async_subdev *asd_list[1];
@@ -608,7 +608,8 @@ static void csi2_lane_config(struct cal_ctx *ctx)
u32 val = reg_read(ctx->dev, CAL_CSI2_COMPLEXIO_CFG(ctx->csi2_port));
u32 lane_mask = CAL_CSI2_COMPLEXIO_CFG_CLOCK_POSITION_MASK;
u32 polarity_mask = CAL_CSI2_COMPLEXIO_CFG_CLOCK_POL_MASK;
- struct v4l2_of_bus_mipi_csi2 *mipi_csi2 = &ctx->endpoint.bus.mipi_csi2;
+ struct v4l2_fwnode_bus_mipi_csi2 *mipi_csi2 =
+ &ctx->endpoint.bus.mipi_csi2;
int lane;
set_field(&val, mipi_csi2->clock_lane + 1, lane_mask);
@@ -1643,7 +1644,7 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst)
struct platform_device *pdev = ctx->dev->pdev;
struct device_node *ep_node, *port, *remote_ep,
*sensor_node, *parent;
- struct v4l2_of_endpoint *endpoint;
+ struct v4l2_fwnode_endpoint *endpoint;
struct v4l2_async_subdev *asd;
u32 regval = 0;
int ret, index, found_port = 0, lane;
@@ -1698,15 +1699,15 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst)
ctx_dbg(3, ctx, "can't get remote parent\n");
goto cleanup_exit;
}
- asd->match_type = V4L2_ASYNC_MATCH_OF;
- asd->match.of.node = sensor_node;
+ asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
+ asd->match.fwnode.fwnode = of_fwnode_handle(sensor_node);
remote_ep = of_parse_phandle(ep_node, "remote-endpoint", 0);
if (!remote_ep) {
ctx_dbg(3, ctx, "can't get remote-endpoint\n");
goto cleanup_exit;
}
- v4l2_of_parse_endpoint(remote_ep, endpoint);
+ v4l2_fwnode_endpoint_parse(of_fwnode_handle(remote_ep), endpoint);
if (endpoint->bus_type != V4L2_MBUS_CSI2) {
ctx_err(ctx, "Port:%d sub-device %s is not a CSI2 device\n",
diff --git a/drivers/media/platform/xilinx/Kconfig b/drivers/media/platform/xilinx/Kconfig
index 84bae79..a5d21b7 100644
--- a/drivers/media/platform/xilinx/Kconfig
+++ b/drivers/media/platform/xilinx/Kconfig
@@ -2,6 +2,7 @@ config VIDEO_XILINX
tristate "Xilinx Video IP (EXPERIMENTAL)"
depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA
select VIDEOBUF2_DMA_CONTIG
+ select V4L2_FWNODE
---help---
Driver for Xilinx Video IP Pipelines
diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c b/drivers/media/platform/xilinx/xilinx-vipp.c
index feb3b2f..ac47043 100644
--- a/drivers/media/platform/xilinx/xilinx-vipp.c
+++ b/drivers/media/platform/xilinx/xilinx-vipp.c
@@ -22,7 +22,7 @@
#include <media/v4l2-async.h>
#include <media/v4l2-common.h>
#include <media/v4l2-device.h>
-#include <media/v4l2-of.h>
+#include <media/v4l2-fwnode.h>
#include "xilinx-dma.h"
#include "xilinx-vipp.h"
@@ -74,7 +74,7 @@ static int xvip_graph_build_one(struct xvip_composite_device *xdev,
struct media_pad *local_pad;
struct media_pad *remote_pad;
struct xvip_graph_entity *ent;
- struct v4l2_of_link link;
+ struct v4l2_fwnode_link link;
struct device_node *ep = NULL;
struct device_node *next;
int ret = 0;
@@ -92,7 +92,7 @@ static int xvip_graph_build_one(struct xvip_composite_device *xdev,
dev_dbg(xdev->dev, "processing endpoint %s\n", ep->full_name);
- ret = v4l2_of_parse_link(ep, &link);
+ ret = v4l2_fwnode_parse_link(of_fwnode_handle(ep), &link);
if (ret < 0) {
dev_err(xdev->dev, "failed to parse link for %s\n",
ep->full_name);
@@ -103,9 +103,10 @@ static int xvip_graph_build_one(struct xvip_composite_device *xdev,
* the link.
*/
if (link.local_port >= local->num_pads) {
- dev_err(xdev->dev, "invalid port number %u on %s\n",
- link.local_port, link.local_node->full_name);
- v4l2_of_put_link(&link);
+ dev_err(xdev->dev, "invalid port number %u for %s\n",
+ link.local_port,
+ to_of_node(link.local_node)->full_name);
+ v4l2_fwnode_put_link(&link);
ret = -EINVAL;
break;
}
@@ -114,25 +115,28 @@ static int xvip_graph_build_one(struct xvip_composite_device *xdev,
if (local_pad->flags & MEDIA_PAD_FL_SINK) {
dev_dbg(xdev->dev, "skipping sink port %s:%u\n",
- link.local_node->full_name, link.local_port);
- v4l2_of_put_link(&link);
+ to_of_node(link.local_node)->full_name,
+ link.local_port);
+ v4l2_fwnode_put_link(&link);
continue;
}
/* Skip DMA engines, they will be processed separately. */
- if (link.remote_node == xdev->dev->of_node) {
+ if (link.remote_node == of_fwnode_handle(xdev->dev->of_node)) {
dev_dbg(xdev->dev, "skipping DMA port %s:%u\n",
- link.local_node->full_name, link.local_port);
- v4l2_of_put_link(&link);
+ to_of_node(link.local_node)->full_name,
+ link.local_port);
+ v4l2_fwnode_put_link(&link);
continue;
}
/* Find the remote entity. */
- ent = xvip_graph_find_entity(xdev, link.remote_node);
+ ent = xvip_graph_find_entity(xdev,
+ to_of_node(link.remote_node));
if (ent == NULL) {
dev_err(xdev->dev, "no entity found for %s\n",
- link.remote_node->full_name);
- v4l2_of_put_link(&link);
+ to_of_node(link.remote_node)->full_name);
+ v4l2_fwnode_put_link(&link);
ret = -ENODEV;
break;
}
@@ -141,15 +145,16 @@ static int xvip_graph_build_one(struct xvip_composite_device *xdev,
if (link.remote_port >= remote->num_pads) {
dev_err(xdev->dev, "invalid port number %u on %s\n",
- link.remote_port, link.remote_node->full_name);
- v4l2_of_put_link(&link);
+ link.remote_port,
+ to_of_node(link.remote_node)->full_name);
+ v4l2_fwnode_put_link(&link);
ret = -EINVAL;
break;
}
remote_pad = &remote->pads[link.remote_port];
- v4l2_of_put_link(&link);
+ v4l2_fwnode_put_link(&link);
/* Create the media link. */
dev_dbg(xdev->dev, "creating %s:%u -> %s:%u link\n",
@@ -194,7 +199,7 @@ static int xvip_graph_build_dma(struct xvip_composite_device *xdev)
struct media_pad *source_pad;
struct media_pad *sink_pad;
struct xvip_graph_entity *ent;
- struct v4l2_of_link link;
+ struct v4l2_fwnode_link link;
struct device_node *ep = NULL;
struct device_node *next;
struct xvip_dma *dma;
@@ -213,7 +218,7 @@ static int xvip_graph_build_dma(struct xvip_composite_device *xdev)
dev_dbg(xdev->dev, "processing endpoint %s\n", ep->full_name);
- ret = v4l2_of_parse_link(ep, &link);
+ ret = v4l2_fwnode_parse_link(of_fwnode_handle(ep), &link);
if (ret < 0) {
dev_err(xdev->dev, "failed to parse link for %s\n",
ep->full_name);
@@ -225,7 +230,7 @@ static int xvip_graph_build_dma(struct xvip_composite_device *xdev)
if (dma == NULL) {
dev_err(xdev->dev, "no DMA engine found for port %u\n",
link.local_port);
- v4l2_of_put_link(&link);
+ v4l2_fwnode_put_link(&link);
ret = -EINVAL;
break;
}
@@ -234,19 +239,21 @@ static int xvip_graph_build_dma(struct xvip_composite_device *xdev)
dma->video.name);
/* Find the remote entity. */
- ent = xvip_graph_find_entity(xdev, link.remote_node);
+ ent = xvip_graph_find_entity(xdev,
+ to_of_node(link.remote_node));
if (ent == NULL) {
dev_err(xdev->dev, "no entity found for %s\n",
- link.remote_node->full_name);
- v4l2_of_put_link(&link);
+ to_of_node(link.remote_node)->full_name);
+ v4l2_fwnode_put_link(&link);
ret = -ENODEV;
break;
}
if (link.remote_port >= ent->entity->num_pads) {
dev_err(xdev->dev, "invalid port number %u on %s\n",
- link.remote_port, link.remote_node->full_name);
- v4l2_of_put_link(&link);
+ link.remote_port,
+ to_of_node(link.remote_node)->full_name);
+ v4l2_fwnode_put_link(&link);
ret = -EINVAL;
break;
}
@@ -263,7 +270,7 @@ static int xvip_graph_build_dma(struct xvip_composite_device *xdev)
sink_pad = &dma->pad;
}
- v4l2_of_put_link(&link);
+ v4l2_fwnode_put_link(&link);
/* Create the media link. */
dev_dbg(xdev->dev, "creating %s:%u -> %s:%u link\n",
@@ -383,8 +390,8 @@ static int xvip_graph_parse_one(struct xvip_composite_device *xdev,
}
entity->node = remote;
- entity->asd.match_type = V4L2_ASYNC_MATCH_OF;
- entity->asd.match.of.node = remote;
+ entity->asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
+ entity->asd.match.fwnode.fwnode = of_fwnode_handle(remote);
list_add_tail(&entity->list, &xdev->entities);
xdev->num_subdevs++;
}
diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
index ff32f95..cbd919d 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -41,12 +41,6 @@ static bool match_devname(struct v4l2_subdev *sd,
return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
}
-static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
-{
- return !of_node_cmp(of_node_full_name(sd->of_node),
- of_node_full_name(asd->match.of.node));
-}
-
static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
@@ -88,9 +82,6 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct v4l2_async_notifier *
case V4L2_ASYNC_MATCH_I2C:
match = match_i2c;
break;
- case V4L2_ASYNC_MATCH_OF:
- match = match_of;
- break;
case V4L2_ASYNC_MATCH_FWNODE:
match = match_fwnode;
break;
@@ -171,7 +162,6 @@ int v4l2_async_notifier_register(struct v4l2_device *v4l2_dev,
case V4L2_ASYNC_MATCH_CUSTOM:
case V4L2_ASYNC_MATCH_DEVNAME:
case V4L2_ASYNC_MATCH_I2C:
- case V4L2_ASYNC_MATCH_OF:
case V4L2_ASYNC_MATCH_FWNODE:
break;
default:
@@ -295,8 +285,8 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
* (struct v4l2_subdev.dev), and async sub-device does not
* exist independently of the device at any point of time.
*/
- if (!sd->of_node && sd->dev)
- sd->of_node = sd->dev->of_node;
+ if (!sd->fwnode && sd->dev)
+ sd->fwnode = dev_fwnode(sd->dev);
mutex_lock(&list_lock);
diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index c3695fa..c69d8c8 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -31,7 +31,6 @@ struct v4l2_async_notifier;
* v4l2_async_subdev.match ops
* @V4L2_ASYNC_MATCH_DEVNAME: Match will use the device name
* @V4L2_ASYNC_MATCH_I2C: Match will check for I2C adapter ID and address
- * @V4L2_ASYNC_MATCH_OF: Match will use OF node
* @V4L2_ASYNC_MATCH_FWNODE: Match will use firmware node
*
* This enum is used by the asyncrhronous sub-device logic to define the
@@ -41,7 +40,6 @@ enum v4l2_async_match_type {
V4L2_ASYNC_MATCH_CUSTOM,
V4L2_ASYNC_MATCH_DEVNAME,
V4L2_ASYNC_MATCH_I2C,
- V4L2_ASYNC_MATCH_OF,
V4L2_ASYNC_MATCH_FWNODE,
};
@@ -57,9 +55,6 @@ struct v4l2_async_subdev {
enum v4l2_async_match_type match_type;
union {
struct {
- const struct device_node *node;
- } of;
- struct {
struct fwnode_handle *fwnode;
} fwnode;
struct {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Mark Brown @ 2017-04-25 10:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jiada Wang, Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer,
Fabio Estevam, linux-spi,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAMuHMdXa_O6RsqUciiNWQ0Zp6dniS47AUmPN9UWAWitP0csx=Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]
On Mon, Apr 24, 2017 at 12:55:21PM +0200, Geert Uytterhoeven wrote:
> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang <jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
> > Our use case is to use spidev as an interface to communicate with external
> > SPI master devices.
> > meanwhile the SPI bus controller can also act as master device to send data
> > to other
> > SPI slave devices on the board.
> That sounds a bit hackish to me. SPI was never meant to be a multi-master bus.
> While it can be done, you will need external synchronization (signals) to
> avoid conflicts between the SPI masters.
> > I found in your implementation, SPI bus controller is limited to either work
> > in master mode or
> > slave mode, is there any reasoning to not configure SPI mode based on SPI
> > devices use case?
> If you really need both master and slave support, you can use 2 subnodes
> in DT, the first representing the master, the second the slave.
> Mark, what's your opinion about this?
That sounds like a mess... we *could* put the slave flag on the device
rather than the controller I guess but there's also going to need to be
something representing whatever avoids collisions on the bus somewhere.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 10/18] pinctrl: madera: Add driver for Cirrus Logic Madera codecs
From: Richard Fitzgerald @ 2017-04-25 10:26 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, alsa-devel@alsa-project.org, Jason Cooper,
devicetree@vger.kernel.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, Mark Brown, Thomas Gleixner,
Lee Jones
In-Reply-To: <CACRpkdYtuu4mFf9bjz-z_kNhbgmuw7TQdQqBc66iWfFP5wp_fw@mail.gmail.com>
On Tue, 2017-04-25 at 11:41 +0200, Linus Walleij wrote:
> On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
> <rf@opensource.wolfsonmicro.com> wrote:
>
> > These codecs have a variable number of I/O lines each of which
> > is individually selectable to a wide range of possible functions.
> >
> > The functionality is slightly different from the traditional muxed
> > GPIO since most of the functions can be mapped to any pin (and even
> > the same function to multiple pins). Most pins have a dedicated
> > "alternate" function that is only available on that pin. The
> > alternate functions are usually a group of signals, though it is
> > not always necessary to enable the full group, depending on the
> > alternate function and how it is to be used. The mapping between
> > alternate functions and GPIO pins varies between codecs depending
> > on the number of alternate functions and available pins.
> >
> > Note on the Kconfig options:
> > The formula "default y if..." is used for PINCTRL_MADERA so that its
> > select options will be processed, allowing us to group selects for
> > pinctrl into the pinctrl Kconfig where they logically belong instead
> > of accumulating under the parent MFD Kconfig.
> >
> > Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> (...)
>
> > Changes since V1:
>
> This is starting to look good!
>
> In fact, kind of finished. Except:
>
> > + if (pdata) {
> > + ret = pinctrl_register_mappings(pdata->gpio_configs,
> > + pdata->n_gpio_configs);
> > + if (ret) {
> > + dev_err(priv->dev,
> > + "Failed to register pdata mappings (%d)\n",
> > + ret);
> > + return ret;
> > + }
> > + }
>
> What is this? It looks like boardfile support which we do not like to
> encourage. Why are the mappings not exclusively set up from
> device tree or similar?
>
We want to work on systems that don't use DT for configuration, so we
offer pdata as a fallback across all the drivers. In that case the
configuration is defined as part of the parent pdata struct and this
applies it.
> Yours,
> Linus Walleij
^ permalink raw reply
* RE: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C
From: Ryan Chen @ 2017-04-25 9:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Brendan Higgins
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Joel Stanley, Vladimir Zapolskiy,
Kachalov Anton, Cédric Le Goater,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, OpenBMC Maillist
In-Reply-To: <1493112875.25766.268.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 18710 bytes --]
Thanks Ryan. Can you shed some light on the meaning of the high-speed bit as well please ?
About ASPEED_I2CD_M_HIGH_SPEED_EN, it is support for I2C specification "High speed transfer". And also device need support it.
If you just speed up the I2C bus clock, you don’t have to enable ASPEED_I2CD_M_HIGH_SPEED_EN, just change the clock is ok.
-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
Sent: Tuesday, April 25, 2017 5:35 PM
To: Ryan Chen <ryan_chen@aspeedtech.com>; Brendan Higgins <brendanhiggins@google.com>
Cc: Wolfram Sang <wsa@the-dreams.de>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Thomas Gleixner <tglx@linutronix.de>; Jason Cooper <jason@lakedaemon.net>; Marc Zyngier <marc.zyngier@arm.com>; Joel Stanley <joel@jms.id.au>; Vladimir Zapolskiy <vz@mleia.com>; Kachalov Anton <mouse@mayc.ru>; Cédric Le Goater <clg@kaod.org>; linux-i2c@vger.kernel.org; devicetree@vger.kernel.org; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C
On Tue, 2017-04-25 at 08:50 +0000, Ryan Chen wrote:
> Hello All,
> ASPEED_I2CD_M_SDA_DRIVE_1T_EN,
> ASPEED_I2CD_SDA_DRIVE_1T_EN is specific for some case usage.Â
> For example, if i2c bus is use on "high speed" and "single slave and
> master" and i2c bus is too long. It need drive SDA or SCL less lunacy.
> It would enable it.
> Otherwise, don’t enable it. especially in multi-master.
> It can’t be enable.
That smells like a specific enough use case that we should probably cover with a device-tree property, something like an empty "sda-extra-drive" property (empty properties are typically used for booleans, their presence means "true").
Thanks Ryan. Can you shed some light on the meaning of the high-speed bit as well please ? Does it force to a specific speed (ignoring the
divisor) or we can still play with the clock high/low counts ?
Cheers,
Ben.
> Â Â
>
>
> Best Regards,
> Ryan
>
> 信驊科技股份有é™å…¬å¸
> ASPEED Technology Inc.
> 2F,No.15,Industry East Road 4.,Hsinchu Science Park, Hsinchu City
> 30077, Taiwan
> Tel: 886-3-578-9568Â #857
> Fax: 886-3-578-9586
> ************* Email Confidentiality Notice ********************
> DISCLAIMER:
> This message (and any attachments) may contain legally privileged
> and/or other confidential information. If you have received it in
> error, please notify the sender by reply e-mail and immediately delete
> the e-mail and any attachments without copying or disclosing the
> contents. Thank you.
>
>
> -----Original Message-----
> From: Brendan Higgins [mailto:brendanhiggins@google.com]
> Sent: Tuesday, April 25, 2017 4:32 PM
> To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Wolfram Sang <wsa@the-dreams.de>; Rob Herring <robh+dt@kernel.org
> >; Mark Rutland <mark.rutland@arm.com>; Thomas Gleixner <tglx@linutro
> nix.de>; Jason Cooper <jason@lakedaemon.net>; Marc Zyngier <marc.zyng
> ier@arm.com>; Joel Stanley <joel@jms.id.au>; Vladimir Zapolskiy <vz@m
> leia.com>; Kachalov Anton <mouse@mayc.ru>; Cédric Le Goater <clg@kaod
> .org>; linux-i2c@vger.kernel.org; devicetree@vger.kernel.org; Linux
> Kernel Mailing List <linux-kernel@vger.kernel.org>; OpenBMC Maillist
> <openbmc@lists.ozlabs.org>; Ryan Chen <ryan_chen@aspeedtech.com>
> Subject: Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C
>
> Adding Ryan.
>
> On Mon, Apr 24, 2017 at 7:19 PM, Benjamin Herrenschmidt <benh@kernel.
> crashing.org> wrote:
> > On Mon, 2017-04-24 at 11:56 -0700, Brendan Higgins wrote:
> > > > > +struct aspeed_i2c_bus {
> > > > > +     struct i2c_adapter              adap;
> > > > > +     struct device                   *dev;
> > > > > +     void __iomem                    *base;
> > > > > +Â Â Â Â Â /* Synchronizes I/O mem access to base. */
> > > > > +     spinlock_t                      lock;
> > > >
> > > > I am not entirely convinced we need that lock. The i2c core will
> > > > take a mutex protecting all operations on the bus. So we only
> > > > need to synchronize between our "xfer" code and our interrupt
> > > > handler.
> > >
> > > You are right if both having slave and master active at the same
> > > time was not possible; however, it is.
> >
> > Right, I somewhat forgot about the slave case.
> >
> > Â ...
> >
> > > > Some of those error states probably also warrant a reset of the
> > > > controller, I think aspeed does that in the SDK.
> > >
> > > For timeout and cmd_err, I do not see any argument against it; it
> > > sounds like we are in a very messed up, very unknown state, so
> > > full reset is probably the best last resort.
> >
> > Yup.
> >
> > > For SDA staying pulled down, I
> > > think we can say with reasonable confidence that some device on
> > > our bus is behaving very badly and I am not convinced that
> > > resetting the controller is likely to do anything to help;
> >
> > Right. Hammering with STOPs and pray ...
>
> I think sending recovery mode sends stops as a part of the recovery
> algorithm it executes.
>
> >
> > > Â that being said, I really
> > > do not have any good ideas to address that. So maybe praying and
> > > resetting the controller is *the most reasonable thing to do.* I
> > > would like to know what you think we should do in that case.
> >
> > Well, there's a (small ?) chance that it's a controller bug
> > asserting the line so ... but there's little we can do if not.
>
> True.
>
> >
> > > While I was thinking about this I also realized that the SDA line
> > > check after recovery happens in the else branch, but SCL line
> > > check does not happen after we attempt to STOP if SCL is hung. If
> > > we decide to make special note SDA being hung by a device that
> > > won't let go, we might want to make a special note that SCL is
> > > hung by a device that won't let go. Just a thought.
> >
> > Maybe. Or just "unrecoverable error"... hopefully these don't happen
> > too often ... We had cases of a TPM misbehaving like that.
>
> Yeah, definitely should print something out.
>
> >
> > > > > +out:
> > >
> > > ...
> > > > What about I2C_M_NOSTART ?
> > > >
> > > > Not that I've ever seen it used... ;-)
> > >
> > > Right now I am not doing any of the protocol mangling options, but
> > > I can add them in if you think it is important for initial
> > > support.
> >
> > No, not important, we can add that later if it ever becomes useful.
> >
> > Â ...
> >
> > > > In general, you always ACK all interrupts first. Then you handle
> > > > the bits you have harvested.
> > > >
> > >
> > > The documentation says to ACK the interrupt after handling in the
> > > RX
> > > case:
> > >
> > > <<<
> > > S/W needs to clear this status bit to allow next data receiving.
> > > > > >
> > >
> > > I will double check with Ryan to make sure TX works the same way.
> > >
> > > > > +Â Â Â Â Â if (irq_status & ASPEED_I2CD_INTR_ERROR ||
> > > > > +Â Â Â Â Â Â Â Â Â (!bus->msgs && bus->master_state !=
> > > > > ASPEED_I2C_MASTER_STOP)) {
> > >
> > > ...
> > > >
> > > > I would set master_state to "RECOVERY" (new state ?) and ensure
> > > > those things are caught if they happen outside of a recovery.
> >
> > I replied privately ... as long as we ack before we start a new
> > command we should be ok but we shouldn't ack after.
> >
> > Your latest patch still does that. It will do things like start a
> > STOP command *then* ack the status bits. I'm pretty sure that's
> > bogus.
> >
> > That way it's a lot simpler to simply move the
> >
> > Â Â Â Â Â Â Â Â writel(irq_status, bus->base + ASPEED_I2C_INTR_STS_REG);
> >
> > To either right after the readl of the status reg at the beginning
> > of aspeed_i2c_master_irq().
> >
> > I would be very surprised if that didn't work properly and wasn't
> > much safer than what you are currently doing.
>
> I think I tried your way and it worked. In anycase, Ryan will be able
> to clarify for us.
>
> >
> > > Let me know if you still think we need a "RECOVERY" state.
> >
> > The way you just switch to stop state and store the error for later
> > should work I think.
> >
> > > >
> > > > > +Â Â Â Â Â if (bus->master_state == ASPEED_I2C_MASTER_START) {
> > >
> > > ...
> > > >
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â dev_dbg(bus->dev,
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "no slave present at %02x",
> > > > > msg-
> > > > > > addr);
> > > > >
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â status_ack |= ASPEED_I2CD_INTR_TX_NAK;
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â bus->cmd_err = -EIO;
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â do_stop(bus);
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â goto out_no_complete;
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â } else {
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â status_ack |= ASPEED_I2CD_INTR_TX_ACK;
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (msg->flags & I2C_M_RD)
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â bus->master_state =
> > > > > ASPEED_I2C_MASTER_RX;
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â else
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â bus->master_state =
> > > > > ASPEED_I2C_MASTER_TX_FIRST;
> > > >
> > > > What about the SMBUS_QUICK case ? (0-len transfer). Do we need
> > > > to handle this here ? A quick look at the TX_FIRST case makes me
> > > > think we are ok there but I'm not sure about the RX case.
> > >
> > > I did not think that there is an SMBUS_QUICK RX. Could you point
> > > me to an example?
> >
> > Not so much an RX, it's more like you are sending a 1-bit data in
> > the place of the Rd/Wr bit. So you have a read with a lenght of 0, I
> > don't think in that case you should set ASPEED_I2CD_M_RX_CMD in
> > __aspeed_i2c_do_start
>
> Forget what I said, I was just not thinking about the fact that SMBus
> emulation causes the data bit to be encoded as the R/W flag. I see
> what you are saying; you are correct.
>
> >
> > > > I'm not sure the RX case is tight also. What completion does the
> > > > HW give you for the address cycle ? Won't you get that before it
> > > > has received the first character ? IE. You fall through to the
> > > > read case of the state machine with the read potentially not
> > > > complete yet no ?
> > >
> > > ...
> > > > > +Â Â Â Â Â case ASPEED_I2C_MASTER_RX:
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â if (!(irq_status & ASPEED_I2CD_INTR_RX_DONE)) {
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â dev_err(bus->dev, "master failed to
> > > > > RX");
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â goto out_complete;
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â }
> > > >
> > > > See my comment above for a bog standard i2c_read. Aren't you
> > > > getting the completion for the address before the read is even
> > > > started ?
> > >
> > > In practice no, but it is probably best to be safe :-)
> >
> > Yup :)
> > > >
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â status_ack |= ASPEED_I2CD_INTR_RX_DONE;
> > > > > +
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â recv_byte = aspeed_i2c_read(bus,
> > > > > ASPEED_I2C_BYTE_BUF_REG) >> 8;
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â msg->buf[bus->buf_index++] = recv_byte;
> > > > > +
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â if (msg->flags & I2C_M_RECV_LEN &&
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â recv_byte <= I2C_SMBUS_BLOCK_MAX) {
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â msg->len = recv_byte +
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ((msg->flags &
> > > > > I2C_CLIENT_PEC) ? 2 : 1);
> > >
> > > ...
> > > > > +Â Â Â Â Â return ((clk_high << ASPEED_I2CD_TIME_SCL_HIGH_SHIFT)
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â & ASPEED_I2CD_TIME_SCL_HIGH_MASK)
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | ((clk_low <<
> > > > > ASPEED_I2CD_TIME_SCL_LOW_SHIFT)
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â & ASPEED_I2CD_TIME_SCL_LOW_MASK)
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â | (base_clk &
> > > > > ASPEED_I2CD_TIME_BASE_DIVISOR_MASK);
> > > > > +}
> > > >
> > > > As I think I mentioned earlier, the AST2500 has a slightly
> > > > different register layout which support larger values for high
> > > > and low, thus allowing a finer granularity.
> > >
> > > I am developing against the 2500.
> >
> > Yes but we'd like the driver to work with both :-)
>
> Right, I thought you were making an assertion about the 2500, if you
> are making an assertion about the 2400, I do not know and do not have
> one handy.
>
> >
> > > > BTW. In case you haven't, I would suggest you copy/paste the
> > > > above in a userspace app and run it for all frequency divisors
> > > > and see if your results match the aspeed table :)
> > >
> > > Good call.
> >
> > If you end up doing that, can you shoot it my way ? I can take care
> > of making sure it's all good for the 2400.
>
> Will do.
>
> >
> > > > > +static int aspeed_i2c_init_clk(struct aspeed_i2c_bus *bus,
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â struct platform_device *pdev) {
> > > > > +Â Â Â Â Â u32 clk_freq, divisor;
> > > > > +Â Â Â Â Â struct clk *pclk;
> > > > > +Â Â Â Â Â int ret;
> > > > > +
> > > > > +Â Â Â Â Â pclk = devm_clk_get(&pdev->dev, NULL);
> > > > > +Â Â Â Â Â if (IS_ERR(pclk)) {
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â dev_err(&pdev->dev, "clk_get failed\n");
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â return PTR_ERR(pclk);
> > > > > +Â Â Â Â Â }
> > > > > +Â Â Â Â Â ret = of_property_read_u32(pdev->dev.of_node,
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "clock-frequency",
> > > > > &clk_freq);
> > > >
> > > > See my previous comment about calling that 'bus-frequency'
> > > > rather
> > > > than 'clock-frequency'.
> > > >
> > > > > +Â Â Â Â Â if (ret < 0) {
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â dev_err(&pdev->dev,
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â "Could not read clock-frequency
> > > > > property\n");
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â clk_freq = 100000;
> > > > > +Â Â Â Â Â }
> > > > > +Â Â Â Â Â divisor = clk_get_rate(pclk) / clk_freq;
> > > > > +Â Â Â Â Â /* We just need the clock rate, we don't actually use
> > > > > the
> > > > > clk object. */
> > > > > +Â Â Â Â Â devm_clk_put(&pdev->dev, pclk);
> > > > > +
> > > > > +Â Â Â Â Â /* Set AC Timing */
> > > > > +Â Â Â Â Â if (clk_freq / 1000 > 1000) {
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â aspeed_i2c_write(bus, aspeed_i2c_read(bus,
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ASPEED_I2
> > > > > C_FU
> > > > > N_CTRL_REG) |
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ASPEED_I2CD_M_HIGH_SPEED_EN |
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ASPEED_I2CD_M_SDA_DRIVE_1T_EN |
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ASPEED_I2CD_SDA_DRIVE_1T_EN,
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ASPEED_I2C_FUN_CTRL_REG);
> > > > > +
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â aspeed_i2c_write(bus, 0x3,
> > > > > ASPEED_I2C_AC_TIMING_REG2);
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â aspeed_i2c_write(bus,
> > > > > aspeed_i2c_get_clk_reg_val(divisor),
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ASPEED_I2C_AC_TIMING_REG1);
> > > >
> > > > I already discussed by doubts about the above. I can try to
> > > > scope it with the EVB if you don't get to it. For now I'd rather
> > > > take the code out.
> > > >
> > > > We should ask aspeed from what frequency the "1T" stuff is
> > > > useful.
> > >
> > > Will do, I will try to rope Ryan in on the next review; it will be
> > > good for him to get used to working with upstream anyway.
> >
> > Yup. However, for the sake of getting something upstream (and in
> > OpenBMC 4.10 kernel) asap, I would suggest just dropping support for
> > those fast speeds for now, we can add them back later.
>
> Alright, that's fine. Still, Ryan, could you provide some context on
> this?
>
> >
> > > >
> > > > > +Â Â Â Â Â } else {
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â aspeed_i2c_write(bus,
> > > > > aspeed_i2c_get_clk_reg_val(divisor),
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ASPEED_I2C_AC_TIMING_REG1);
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â aspeed_i2c_write(bus, ASPEED_NO_TIMEOUT_CTRL,
> > > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ASPEED_I2C_AC_TIMING_REG2);
> > > > > +Â Â Â Â Â }
> > >
> > > ...
> > > > > +Â Â Â Â Â spin_lock_init(&bus->lock);
> > > > > +Â Â Â Â Â init_completion(&bus->cmd_complete);
> > > > > +Â Â Â Â Â bus->adap.owner = THIS_MODULE;
> > > > > +Â Â Â Â Â bus->adap.retries = 0;
> > > > > +Â Â Â Â Â bus->adap.timeout = 5 * HZ;
> > > > > +Â Â Â Â Â bus->adap.algo = &aspeed_i2c_algo;
> > > > > +Â Â Â Â Â bus->adap.algo_data = bus;
> > > > > +Â Â Â Â Â bus->adap.dev.parent = &pdev->dev;
> > > > > +Â Â Â Â Â bus->adap.dev.of_node = pdev->dev.of_node;
> > > > > +Â Â Â Â Â snprintf(bus->adap.name, sizeof(bus->adap.name),
> > > > > "Aspeed
> > > > > i2c");
> > > >
> > > > Another trivial one, should we put some kind of bus number in
> > > > that string ?
> > >
> > > Whoops, looks like I missed this one; I will get to it in the next
> > > revision.
> >
> > Ok. I noticed you missed that in v7, so I assume you mean v8 :-)
>
> Yep, I will get it in v8.
>
> >
> > > >
> > > > > +Â Â Â Â Â bus->dev = &pdev->dev;
> > > > > +
> > > > > +Â Â Â Â Â /* reset device: disable master & slave functions */
> > > > > +Â Â Â Â Â aspeed_i2c_write(bus, 0, ASPEED_I2C_FUN_CTRL_REG);
> > >
> > > ...
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe
> > > devicetree"
> > > in
> > > the body of a message to majordomo@vger.kernel.org More majordomo
> > > info at  http://vger.kernel.org/majordomo-info.html
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* Re: [PATCH v2 13/18] dt-bindings: gpio: Add bindings for GPIO on Cirrus Logic Madera codecs
From: Linus Walleij @ 2017-04-25 9:42 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Alexandre Courbot, alsa-devel@alsa-project.org, Jason Cooper,
devicetree@vger.kernel.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, Mark Brown, Thomas Gleixner,
Lee Jones
In-Reply-To: <1493050124-5970-14-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
<rf@opensource.wolfsonmicro.com> wrote:
> The Cirrus Logic Madera codecs have a range of GPIO pins that can be
> used as single-bit logic input or output. These are presented as a
> standard GPIO binding.
>
> The second cell in a GPIO binding is currently reserved for future use
> as chip-specific flags.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> Changes from V1:
> - moved out of main gpio patch into a separate patch
> - added gpio-line-names as an optional property
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 10/18] pinctrl: madera: Add driver for Cirrus Logic Madera codecs
From: Linus Walleij @ 2017-04-25 9:41 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Lee Jones, Mark Brown, Alexandre Courbot, Rob Herring,
Thomas Gleixner, Jason Cooper, alsa-devel@alsa-project.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1493050124-5970-11-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
<rf@opensource.wolfsonmicro.com> wrote:
> These codecs have a variable number of I/O lines each of which
> is individually selectable to a wide range of possible functions.
>
> The functionality is slightly different from the traditional muxed
> GPIO since most of the functions can be mapped to any pin (and even
> the same function to multiple pins). Most pins have a dedicated
> "alternate" function that is only available on that pin. The
> alternate functions are usually a group of signals, though it is
> not always necessary to enable the full group, depending on the
> alternate function and how it is to be used. The mapping between
> alternate functions and GPIO pins varies between codecs depending
> on the number of alternate functions and available pins.
>
> Note on the Kconfig options:
> The formula "default y if..." is used for PINCTRL_MADERA so that its
> select options will be processed, allowing us to group selects for
> pinctrl into the pinctrl Kconfig where they logically belong instead
> of accumulating under the parent MFD Kconfig.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
(...)
> Changes since V1:
This is starting to look good!
In fact, kind of finished. Except:
> + if (pdata) {
> + ret = pinctrl_register_mappings(pdata->gpio_configs,
> + pdata->n_gpio_configs);
> + if (ret) {
> + dev_err(priv->dev,
> + "Failed to register pdata mappings (%d)\n",
> + ret);
> + return ret;
> + }
> + }
What is this? It looks like boardfile support which we do not like to
encourage. Why are the mappings not exclusively set up from
device tree or similar?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Sergei Shtylyov @ 2017-04-25 9:41 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev, Rob Herring, Mark Rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <20170424215022.30382-3-eric@anholt.net>
On 4/25/2017 12:50 AM, Eric Anholt wrote:
> Cygnus has a single amac controller connected to the B53 switch with 2
> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
> the external ethernet jacks.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
> 2 files changed, 68 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 009f1346b817..318899df9972 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
[...]
> @@ -295,6 +345,16 @@
> status = "disabled";
> };
>
> + eth0: enet@18042000 {
Oh, and this one should be named "ethernet", according to the DT spec.
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
> + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1000>;
> + status = "disabled";
> + };
> +
> nand: nand@18046000 {
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
> reg = <0x18046000 0x600>, <0xf8105408 0x600>,
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.
From: Sergei Shtylyov @ 2017-04-25 9:40 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev, Rob Herring, Mark Rutland, devicetree
Cc: linux-arm-kernel, linux-kernel, bcm-kernel-feedback-list, Ray Jui,
Scott Branden, Jon Mason
In-Reply-To: <20170424215022.30382-3-eric@anholt.net>
Hello.
On 4/25/2017 12:50 AM, Eric Anholt wrote:
> Cygnus has a single amac controller connected to the B53 switch with 2
> PHYs. On the BCM911360_EP platform, those two PHYs are connected to
> the external ethernet jacks.
My spell checker trips on "amac" and "ethernet" -- perhaps they need
capitalization?
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 60 ++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm911360_entphn.dts | 8 +++++
> 2 files changed, 68 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 009f1346b817..318899df9972 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -142,6 +142,56 @@
> interrupts = <0>;
> };
>
> + mdio: mdio@18002000 {
> + compatible = "brcm,iproc-mdio";
> + reg = <0x18002000 0x8>;
> + #size-cells = <1>;
> + #address-cells = <0>;
> +
> + gphy0: eth-gphy@0 {
The node anmes must be generic, the DT spec has standardized
"ethernet-phy" name for this case.
> + reg = <0>;
> + max-speed = <1000>;
> + };
> +
> + gphy1: eth-gphy@1 {
> + reg = <1>;
> + max-speed = <1000>;
> + };
> + };
[...]
> @@ -295,6 +345,16 @@
> status = "disabled";
> };
>
> + eth0: enet@18042000 {
> + compatible = "brcm,amac";
> + reg = <0x18042000 0x1000>,
> + <0x18110000 0x1000>;
> + reg-names = "amac_base", "idm_base";
I don't think "_base" suffixes are necessary here.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Sergei Shtylyov @ 2017-04-25 9:35 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Vivien Didelot, Andrew Lunn,
netdev, Rob Herring, Mark Rutland, devicetree
Cc: Scott Branden, Jon Mason, Ray Jui, linux-kernel,
bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <20170424215022.30382-2-eric@anholt.net>
Hello!
On 4/25/2017 12:50 AM, Eric Anholt wrote:
> Cygnus is a small family of SoCs, of which we currently have
> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
> same as 58xx, just requiring a tiny bit of setup that was previously
> missing.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
> Documentation/devicetree/bindings/net/dsa/b53.txt | 3 +++
> drivers/net/dsa/b53/b53_srab.c | 2 ++
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/b53.txt b/Documentation/devicetree/bindings/net/dsa/b53.txt
> index d6c6e41648d4..49c93d3c0839 100644
> --- a/Documentation/devicetree/bindings/net/dsa/b53.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/b53.txt
> @@ -29,6 +29,9 @@ Required properties:
> "brcm,bcm58625-srab"
> "brcm,bcm88312-srab" and the mandatory "brcm,nsp-srab string
>
> + For the BCM11360 SoC, must be:
> + "brcm,bcm11360-srab" and the mandatory "brcm,cygnus-srab string
Missing closing quote here and above?
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 11/18] dt-bindings: pinctrl: Add bindings for Cirrus Logic Madera codecs
From: Linus Walleij @ 2017-04-25 9:35 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Alexandre Courbot, alsa-devel@alsa-project.org, Jason Cooper,
devicetree@vger.kernel.org,
open list:WOLFSON MICROELECTRONICS DRIVERS,
linux-kernel@vger.kernel.org, Rob Herring,
linux-gpio@vger.kernel.org, Mark Brown, Thomas Gleixner,
Lee Jones
In-Reply-To: <1493050124-5970-12-git-send-email-rf@opensource.wolfsonmicro.com>
On Mon, Apr 24, 2017 at 6:08 PM, Richard Fitzgerald
<rf@opensource.wolfsonmicro.com> wrote:
> This is the binding description of the pinctrl driver for Cirru Logic
> Madera codecs. The binding uses the generic pinctrl binding so the main
> purpose here is to describe the device-specific names for groups and
> functions.
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> Changes since V1:
> - split out from main pinctrl patch into a separate patch
> - fixed typo in pinctrl-names property description
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox