* Re: [PATCH 2/4] Documetation: samsung-phy: add the exynos-pcie-phy binding
From: Rob Herring @ 2017-01-03 18:05 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
mark.rutland, kgene, krzk, kishon, jingoohan1, vivek.gautam,
pankaj.dubey, alim.akhtar, cpgs
In-Reply-To: <20161228103454.26467-3-jh80.chung@samsung.com>
On Wed, Dec 28, 2016 at 07:34:52PM +0900, Jaehoon Chung wrote:
> Adds the exynos-pcie-phy binding for Exynos PCIe PHY.
> This is for using generic PHY framework.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> .../devicetree/bindings/phy/samsung-phy.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 9872ba8..1cbc15f 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -191,3 +191,26 @@ Example:
> usbdrdphy0 = &usb3_phy0;
> usbdrdphy1 = &usb3_phy1;
> };
> +
> +Samsung Exynos SoC series PCIe PHY controller
> +--------------------------------------------------
> +Required properties:
> +- compatible : Should be set to "samsung,exynos5440-pcie-phy"
> +- #phy-cells : Must be zero
> +- reg : a register used by phy driver.
> +
> +Required properies for child node:
> +- reg : a block register used by phy driver.
There's no need for this. Either just make the length 0x1040 or add a
2nd address to the parent reg prop.
> +
> +Example:
> + pcie_phy0: pcie-phy@270000 {
> + #phy-cells = <0>;
> + compatible = "samsung,exynos5440-pcie-phy";
> + reg = <0x270000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + block@271000 {
> + reg = <0x271000 0x40>;
> + };
> + };
> --
> 2.10.2
>
^ permalink raw reply
* Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Geoff Lansberry @ 2017-01-03 18:35 UTC (permalink / raw)
To: Mark Greer
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, robh+dt, mark.rutland, netdev, devicetree,
linux-kernel, Justin Bronder, Jaret Cantu
In-Reply-To: <20170103163324.GA3184@animalcreek.com>
On Tue, Jan 3, 2017 at 11:33 AM, Mark Greer <mgreer@animalcreek.com> wrote:
> [Please stop top-posting. Bottom-post only to these lists.]
Sorry; gmail keeps baiting me to do it...
>
> Hi Geoff & happy new year.
>
> On Tue, Dec 27, 2016 at 09:18:32AM -0500, Geoff Lansberry wrote:
>> Mark - I will split this off soon.
>
> OK
Thanks for the reminder!
>
>> In the meantime - here is some more info about how we use it.
>>
>> We do use NFC structures. I did find an interesting clue in that
>> there are certain bottles that cause neard to segfault, I'm not sure
>> what is different about them. We write a string, like
>> "coppola_chardonnay_2015" to the bottles.
>
> Off the top of my head, it could be the length of the text.
> It would be useful to compare the data that works to the data
> that doesn't work. Can you install NXP's 'TagInfo' app on a
> smartphone and scan tags with working & non-working data?
> You can email the data from the app to yourself, edit out
> the cruft, and share here.
The data is always the same - and the tags are all the same. Only
difference is that the tag is physically different, and perhaps
orientation; distance from antenna to tag is fixed. I can't even
write the tags at all, so reading them will show blank. Also a minor
but significant detail, is that the tags are embedded in such a way
that the phone cannot get close enough to them to connect.
>
>> Come to think of it, I
>> haven't done anything special to make that an ndef record, just
>> assumed that it would happen by default, I'll look into this further.
>
> If you wrote the data using neard, it will be NDEF formatted.
> Since it is working this well, it is virtually guaranteed that
> the data is NDEF formatted.
OK, good.
>
>> Also, I've been running neard with --plugin nfctype2. Just in case
>> the problem was happening due to cycling through other tag types. It
>> didn't seem to make any difference, but I have not gone back to
>> default.
>
> Good to know, thanks.
>
> Mark
> --
^ permalink raw reply
* Re: [PATCH v3 1/3] power: reset: add linkstation-reset driver
From: Florian Fainelli @ 2017-01-03 18:39 UTC (permalink / raw)
To: Roger Shimizu, Andrew Lunn, Sebastian Reichel
Cc: Martin Michlmayr, Sylver Bruneau, Herbert Valerio Riedel,
Ryan Tandy, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAEQ9gE=MoQcr3eX0DAxZtvx0FW9pzgkUGjdxKHcsKwH7_+UsUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/03/2017 06:08 AM, Roger Shimizu wrote:
> Dear Florian, Andrew,
>
> Thanks for your email!
>
> On Tue, Jan 3, 2017 at 2:19 PM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> Interestingly, I submitted a patch doing nearly the same thing recently
>> after hacking on a Buffalo Terastation Pro II two days after yours
>> without seeing yours:
>>
>> https://lkml.org/lkml/2016/12/28/273
>
> Glad to know there's other developer working on linkstation/kurobox platform!
>
>> Some comments below.
>>
>>> +
>>> +static void __iomem *base;
>>> +static unsigned long tclk;
>>> +static const struct reset_cfg *cfg;
>>
>> How about avoiding the singletons here and pass this down from the
>> platform driver's private data after we (see below) also make use of a
>> reboot notifier?
>
> I see your patches. Indeed, it's a good idea to avoid the singletons
> and use private data instead.
>
>>> +static int linkstation_reset_probe(struct platform_device *pdev)
>>> +{
>>> + struct device_node *np = pdev->dev.of_node;
>>> + struct resource *res;
>>> + struct clk *clk;
>>> + char symname[KSYM_NAME_LEN];
>>> +
>>> + const struct of_device_id *match =
>>> + of_match_node(linkstation_reset_of_match_table, np);
>>> + cfg = match->data;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + if (!res) {
>>> + dev_err(&pdev->dev, "Missing resource");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
>>> + if (!base) {
>>> + dev_err(&pdev->dev, "Unable to map resource");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + /* We need to know tclk in order to calculate the UART divisor */
>>> + clk = devm_clk_get(&pdev->dev, NULL);
>>> + if (IS_ERR(clk)) {
>>> + dev_err(&pdev->dev, "Clk missing");
>>> + return PTR_ERR(clk);
>>> + }
>>> +
>>> + tclk = clk_get_rate(clk);
>>
>> Does this work with the Terastation II which has not been converted to
>> DT yet? Is tclk available through the CLK API there?
>
> I have no idea whether device-based legacy code and make use of power
> reset driver.
> Maybe Sebastian Reichel can offer a comment?
>
> However, I think Terastation II should convert to DT first.
> If you're willing to test, I can help to provide a dts/dtb.
> (If you use Debian, I can even provide DEB of kernel image and
> flash-kernel patch, which is easy for you to test)
>
> On Tue, Jan 3, 2017 at 10:09 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
>>>> +
>>>> + /* Check that nothing else has already setup a handler */
>>>> + if (pm_power_off) {
>>>> + lookup_symbol_name((ulong)pm_power_off, symname);
>>>> + dev_err(&pdev->dev,
>>>> + "pm_power_off already claimed %p %s",
>>>> + pm_power_off, symname);
>>>> + return -EBUSY;
>>>> + }
>>>> + pm_power_off = linkstation_reset;
>>>
>>> That seems a bit complicated, why not just assume that there will be
>>> either this driver used, or not at all?
>>
>> That is probably my fault. This is a copy from code i wrote many years
>> ago for the QNAP. I guess at the time i was battling with two
>> different pm_power_off handlers, so put in this code.
>>
>>> Also, you are supposed to register a reboot notifier to which you can
>>> pass private context:
>>
>> At the time i wrote the QNAP code, this did not exist. So maybe my
>> code is no longer a good example to copy.
>
> Really appreciated, Andrew!
> I'll modify this part in next series.
>
> BTW. the private data passing to reboot notifier can be shared to
> power-off function as well?
> Do you have example?
>
>> https://lkml.org/lkml/2016/12/28/275
>>
>> As indicated in my patch series, the UART1-attached micro controller
>> does a lot more things that just providing reboot, which is why I chose
>> to move this code to a MFD driver, as the starting point before adding
>> support for LEDs, FAN, PWM, beeper which would be other types of devices.
>>
>> Is adding support for other peripherals on your TODO as well?
>
> Except reset feature (power-off and reboot), other feature, such as
> LEDs / FAN speed / buttons, is managed by user-land program micro-evtd
> [0][1].
> Since the upstream [1] is not active anymore, Ryan Tandy (in CC) and I
> are maintaining it in Debian [0].
>
> [0] https://tracker.debian.org/pkg/micro-evtd
> [1] https://sourceforge.net/projects/ppc-evtd
>
> micro-evtd worked well for device-based legacy code, but after DT
> conversion, Ryan found the device cannot shutdown properly (reboot is
> OK).
> That why I created this patch series.
> I think for such old hardware and mature user-land program, it doesn't
> deserve the effort to implement those again in kernel side.
> What do you think?
An argument could be made that these are hardware peripherals, and so
the kernel is the best place to abstract support for that, and present
you with the standard device drive model for such kind of peripherals.
We don't have to do everything at the same time, so first things first,
get the reboot working, have me convert the Terastation over to Device
Tree and then we can decide what to do with these additional peripherals.
Thanks!
--
Florian
--
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/4] input: tm2-touchkey: Add touchkey driver support for TM2
From: Dmitry Torokhov @ 2017-01-03 18:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Jaechul Lee, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski, Andi Shyti,
Chanwoo Choi, beomho.seo, galaxyra, linux-arm-kernel, linux-input,
devicetree, linux-kernel, linux-samsung-soc
In-Reply-To: <7794c9b2-48e6-1451-9a3e-fe24410a145d@osg.samsung.com>
On Tue, Jan 03, 2017 at 10:11:39AM -0300, Javier Martinez Canillas wrote:
> Hello Jaechul,
>
> On 01/03/2017 04:57 AM, Jaechul Lee wrote:
> > This patch adds support for the TM2 touch key and led
> > functionlity.
> >
>
> s/functionlity/functionality
>
> > The driver interfaces with userspace through an input device and
> > reports KEY_PHONE and KEY_BACK event types. LED brightness can be
> > controlled by "/sys/class/leds/tm2-touchkey/brightness".
> >
> > Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> > Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> > ---
> > drivers/input/keyboard/Kconfig | 11 ++
> > drivers/input/keyboard/Makefile | 1 +
> > drivers/input/keyboard/tm2-touchkey.c | 326 ++++++++++++++++++++++++++++++++++
> > 3 files changed, 338 insertions(+)
> > create mode 100644 drivers/input/keyboard/tm2-touchkey.c
> >
> > diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> > index cbd75cf..72c0ba1 100644
> > --- a/drivers/input/keyboard/Kconfig
> > +++ b/drivers/input/keyboard/Kconfig
> > @@ -666,6 +666,17 @@ config KEYBOARD_TC3589X
> > To compile this driver as a module, choose M here: the
> > module will be called tc3589x-keypad.
> >
> > +config KEYBOARD_TM2_TOUCHKEY
> > + tristate "tm2-touchkey support"
> > + depends on I2C
There should be LED dependency as well.
> > + help
> > + Say Y here to enable the tm2-touchkey.
> > + touchkey driver for tm2. This driver can enable
> > + the interrupt and make input events and control led brightness.
> > +
> > + To compile this driver as a module, choose M here.
> > + module will be called tm2-touchkey
> > +
> > config KEYBOARD_TWL4030
> > tristate "TI TWL4030/TWL5030/TPS659x0 keypad support"
> > depends on TWL4030_CORE
> > diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> > index d9f4cfc..7d9acff 100644
> > --- a/drivers/input/keyboard/Makefile
> > +++ b/drivers/input/keyboard/Makefile
> > @@ -61,6 +61,7 @@ obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
> > obj-$(CONFIG_KEYBOARD_SUNKBD) += sunkbd.o
> > obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
> > obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
> > +obj-$(CONFIG_KEYBOARD_TM2_TOUCHKEY) += tm2-touchkey.o
> > obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
> > obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
> > obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
> > diff --git a/drivers/input/keyboard/tm2-touchkey.c b/drivers/input/keyboard/tm2-touchkey.c
> > new file mode 100644
> > index 0000000..d9575d8
> > --- /dev/null
> > +++ b/drivers/input/keyboard/tm2-touchkey.c
> > @@ -0,0 +1,326 @@
> > +/*
> > + * Driver for keys on GPIO lines capable of generating interrupts.
This does not match what the driver does.
> > + *
> > + * Copyright 2005 Phil Blundell
> > + * Copyright 2016 Samsung Electronics Co., Ltd.
> > + *
> > + * Author: Beomho Seo <beomho.seo@samsung.com>
> > + * Author: Jaechul Lee <jcsing.lee@samsung.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/bitops.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/i2c.h>
> > +#include <linux/input.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irq.h>
> > +#include <linux/leds.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/pm.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/workqueue.h>
> > +
> > +#define TM2_TOUCHKEY_DEV_NAME "tm2-touchkey"
> > +#define TM2_TOUCHKEY_KEYCODE_REG 0x03
> > +#define TM2_TOUCHKEY_BASE_REG 0x00
> > +#define TM2_TOUCHKEY_CMD_LED_ON 0x10
> > +#define TM2_TOUCHKEY_CMD_LED_OFF 0x20
> > +#define TM2_TOUCHKEY_BIT_PRESS_EV BIT(3)
> > +#define TM2_TOUCHKEY_BIT_KEYCODE GENMASK(2, 0)
> > +#define TM2_TOUCHKEY_LED_VOLTAGE_MIN 2500000
> > +#define TM2_TOUCHKEY_LED_VOLTAGE_MAX 3300000
> > +
> > +enum {
> > + TM2_TOUCHKEY_KEY_MENU = 0x1,
> > + TM2_TOUCHKEY_KEY_BACK,
> > +};
> > +
> > +#define tm2_touchkey_power_enable(x) __tm2_touchkey_power_onoff(x, 1)
> > +#define tm2_touchkey_power_disable(x) __tm2_touchkey_power_onoff(x, 0)
> > +
> > +struct tm2_touchkey_data {
> > + struct i2c_client *client;
> > + struct input_dev *input_dev;
> > + struct led_classdev led_dev;
> > +
> > + u8 keycode_type;
> > + u8 pressed;
> > + struct work_struct irq_work;
> > +
> > + bool power_onoff;
> > + struct regulator *regulator_vcc; /* 1.8V */
> > + struct regulator *regulator_vdd; /* 3.3V */
> > +};
> > +
> > +static void tm2_touchkey_led_brightness_set(struct led_classdev *led_dev,
> > + enum led_brightness brightness)
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey =
Just call it "touchkey", "samsung_touchkey" is too long for a local
variable.
> > + container_of(led_dev, struct tm2_touchkey_data, led_dev);
> > + u32 volt;
> > + u8 data;
> > +
> > + if (brightness == LED_OFF) {
> > + volt = TM2_TOUCHKEY_LED_VOLTAGE_MIN;
> > + data = TM2_TOUCHKEY_CMD_LED_OFF;
> > + } else {
> > + volt = TM2_TOUCHKEY_LED_VOLTAGE_MAX;
> > + data = TM2_TOUCHKEY_CMD_LED_ON;
> > + }
> > +
> > + regulator_set_voltage(samsung_touchkey->regulator_vdd, volt, volt);
> > + i2c_smbus_write_byte_data(samsung_touchkey->client,
> > + TM2_TOUCHKEY_BASE_REG, data);
> > +}
> > +
> > +static int __tm2_touchkey_power_onoff(struct tm2_touchkey_data
> > + *samsung_touchkey, bool onoff)
> > +{
> > + int ret = 0;
> > +
> > + if (samsung_touchkey->power_onoff == onoff)
> > + return ret;
> > +
> > + if (onoff) {
> > + ret = regulator_enable(samsung_touchkey->regulator_vcc);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regulator_enable(samsung_touchkey->regulator_vdd);
> > + if (ret) {
> > + regulator_disable(samsung_touchkey->regulator_vcc);
> > + return ret;
> > + }
>
> I would add a comment about the sleep here.
Also "bulk" regulator API can be useful here.
>
> > + msleep(150);
> > + } else {
> > + int err;
> > +
> > + err = regulator_disable(samsung_touchkey->regulator_vcc);
> > + if (err)
> > + ret = err;
> > +
> > + err = regulator_disable(samsung_touchkey->regulator_vdd);
> > + if (err && !ret)
> > + ret = err;
> > + }
> > + samsung_touchkey->power_onoff = onoff;
> > +
> > + return ret;
> > +}
> > +
> > +static void tm2_touchkey_irq_work(struct work_struct *irq_work)
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey =
> > + container_of(irq_work, struct tm2_touchkey_data, irq_work);
> > +
> > + if (!samsung_touchkey->pressed) {
> > + input_report_key(samsung_touchkey->input_dev, KEY_PHONE, 0);
> > + input_report_key(samsung_touchkey->input_dev, KEY_BACK, 0);
> > + } else {
> > + if (samsung_touchkey->keycode_type == TM2_TOUCHKEY_KEY_MENU)
> > + input_report_key(samsung_touchkey->input_dev,
> > + KEY_PHONE, 1);
> > + else
> > + input_report_key(samsung_touchkey->input_dev,
> > + KEY_BACK, 1);
> > + }
> > + input_sync(samsung_touchkey->input_dev);
> > +}
There is absolutely no reason for doing this in a work. Just call
input_report_key/input_sync from your threaded IRQ routine.
> > +
> > +static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid)
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey = devid;
> > + u32 data;
> > +
> > + data = i2c_smbus_read_byte_data(samsung_touchkey->client,
> > + TM2_TOUCHKEY_KEYCODE_REG);
> > +
> > + if (data < 0) {
> > + dev_err(&samsung_touchkey->client->dev, "Failed to read i2c data\n");
> > + return IRQ_HANDLED;
> > + }
> > +
> > + samsung_touchkey->keycode_type = data & TM2_TOUCHKEY_BIT_KEYCODE;
> > + samsung_touchkey->pressed = !(data & TM2_TOUCHKEY_BIT_PRESS_EV);
> > +
> > + if (samsung_touchkey->keycode_type != TM2_TOUCHKEY_KEY_MENU &&
> > + samsung_touchkey->keycode_type != TM2_TOUCHKEY_KEY_BACK)
>
> Shouldn't at least a debug message be printed here so the user can
> know that an error occurred and a correct keycode was not received?
>
> > + return IRQ_HANDLED;
> > +
> > + schedule_work(&samsung_touchkey->irq_work);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int tm2_touchkey_probe(struct i2c_client *client,
> > + const struct i2c_device_id *id)
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey;
> > + int ret;
> > +
> > + ret = i2c_check_functionality(client->adapter,
> > + I2C_FUNC_SMBUS_BYTE |
> > + I2C_FUNC_SMBUS_BYTE_DATA);
> > + if (!ret) {
> > + dev_err(&client->dev, "No I2C functionality found\n");
> > + return -ENODEV;
> > + }
> > +
> > + samsung_touchkey = devm_kzalloc(&client->dev,
> > + sizeof(struct tm2_touchkey_data), GFP_KERNEL);
sizeof(*touchkey)
> > +
> > + if (!samsung_touchkey) {
> > + dev_err(&client->dev, "Failed to allocate memory.\n");
> > + return -ENOMEM;
> > + }
> > +
> > + samsung_touchkey->client = client;
> > + i2c_set_clientdata(client, samsung_touchkey);
> > + INIT_WORK(&samsung_touchkey->irq_work, tm2_touchkey_irq_work);
Work is not needed.
> > +
> > + /* regulator */
> > + samsung_touchkey->regulator_vcc =
> > + devm_regulator_get(&client->dev, "vcc");
> > + if (IS_ERR(samsung_touchkey->regulator_vcc)) {
> > + dev_err(&client->dev, "Failed to get vcc regulator\n");
> > + return PTR_ERR(samsung_touchkey->regulator_vcc);
> > + }
> > +
> > + samsung_touchkey->regulator_vdd =
> > + devm_regulator_get(&client->dev, "vdd");
> > + if (IS_ERR(samsung_touchkey->regulator_vdd)) {
> > + dev_err(&client->dev, "Failed to get vdd regulator\n");
> > + return PTR_ERR(samsung_touchkey->regulator_vcc);
> > + }
devm_regulator_bulk_get
> > +
> > + /* power */
> > + ret = tm2_touchkey_power_enable(samsung_touchkey);
> > + if (ret) {
> > + dev_err(&client->dev, "Failed to enable power\n");
> > + return ret;
> > + }
You need to install devm action (devm_add_action_or_reset) to disable
power when unloading driver (or if initialization fails).
> > +
> > + /* irq */
> > + ret = devm_request_threaded_irq(&client->dev,
> > + client->irq, NULL,
> > + tm2_touchkey_irq_handler,
> > + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
I'd rather we rely on IRQ trigger from DT, so just use IRQF_PNESHOT
here.
I'd rather you allocated input device before requesting IRQ. The
registering input device is fine to do after getting IRQ.
> > + TM2_TOUCHKEY_DEV_NAME,
> > + samsung_touchkey);
> > + if (ret) {
> > + dev_err(&client->dev, "Failed to request threaded irq\n");
> > + return ret;
> > + }
> > +
> > + /* input device */
> > + samsung_touchkey->input_dev = devm_input_allocate_device(&client->dev);
> > + if (!samsung_touchkey->input_dev) {
> > + dev_err(&client->dev, "Failed to alloc input device.\n");
> > + return -ENOMEM;
> > + }
> > + samsung_touchkey->input_dev->name = TM2_TOUCHKEY_DEV_NAME;
> > + samsung_touchkey->input_dev->id.bustype = BUS_I2C;
> > + samsung_touchkey->input_dev->dev.parent = &client->dev;
No need to set parent when using devm_input_allocate_device(), it is
done automatically.
> > +
> > + set_bit(EV_KEY, samsung_touchkey->input_dev->evbit);
> > + set_bit(KEY_PHONE, samsung_touchkey->input_dev->keybit);
> > + set_bit(KEY_BACK, samsung_touchkey->input_dev->keybit);
Just do
input_set_capability(touchkey->input_dev, EV_KEY, KEY_PHONE);
input_set_capability(touchkey->input_dev, EV_KEY, KEY_BACK);
> > + input_set_drvdata(samsung_touchkey->input_dev, samsung_touchkey);
> > +
> > + ret = input_register_device(samsung_touchkey->input_dev);
> > + if (ret) {
> > + dev_err(&client->dev, "Failed to register input device.\n");
> > + return ret;
> > + }
> > +
> > + /* led device */
> > + samsung_touchkey->led_dev.name = TM2_TOUCHKEY_DEV_NAME;
> > + samsung_touchkey->led_dev.brightness = LED_FULL;
> > + samsung_touchkey->led_dev.max_brightness = LED_FULL;
> > + samsung_touchkey->led_dev.brightness_set =
> > + tm2_touchkey_led_brightness_set;
> > +
> > + ret = devm_led_classdev_register(&client->dev,
> > + &samsung_touchkey->led_dev);
> > + if (ret < 0) {
> > + dev_err(&client->dev, "Failed to register touchkey led\n");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void tm2_touchkey_shutdown(struct i2c_client *client)
> > +{
This is something not normally done. Does your platform really keep
rails on when AP is off?
> > + struct tm2_touchkey_data *samsung_touchkey =
> > + i2c_get_clientdata(client);
> > + int ret;
> > +
> > + disable_irq(client->irq);
> > + ret = tm2_touchkey_power_disable(samsung_touchkey);
> > + if (ret)
> > + dev_err(&client->dev, "Failed to disable power\n");
> > +}
> > +
> > +static int tm2_touchkey_suspend(struct device *dev)
__maybe_unused
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + disable_irq(samsung_touchkey->client->irq);
> > + ret = tm2_touchkey_power_disable(samsung_touchkey);
> > + if (ret)
> > + dev_err(dev, "Failed to disable power\n");
> > +
> > + return ret;
> > +}
>
> These two functions are basically the same, can you factor it out?
>
> > +
> > +static int tm2_touchkey_resume(struct device *dev)
__maybe_unused
> > +{
> > + struct tm2_touchkey_data *samsung_touchkey = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + enable_irq(samsung_touchkey->client->irq);
> > + ret = tm2_touchkey_power_enable(samsung_touchkey);
> > + if (ret)
> > + dev_err(dev, "Failed to enable power\n");
> > +
> > + return ret;
> > +}
> > +
> > +static SIMPLE_DEV_PM_OPS(tm2_touchkey_pm_ops, tm2_touchkey_suspend,
> > + tm2_touchkey_resume);
> > +
> > +static const struct i2c_device_id tm2_touchkey_id_table[] = {
> > + {TM2_TOUCHKEY_DEV_NAME, 0},
> > + {},
> > +};
> > +
>
> You need a MODULE_DEVICE_TABLE(i2c, tm2_touchkey_id_table) here so the
> module can be autoloaded when the device is registered.
>
> > +static const struct of_device_id tm2_touchkey_of_match[] = {
> > + {.compatible = "samsung,tm2-touchkey",},
> > + {},
> > +};
> > +
>
> Here a MODULE_DEVICE_TABLE(of, tm2_touchkey_of_match) is not strictly
> needed since the I2C core always reports MODALIAS of the form i2c:<dev>
> but still is good to have so the I2C core can be fixed at some point.
Yes, please add MODULE_DEVICE_TABLE(of, ...).
>
> > +static struct i2c_driver tm2_touchkey_driver = {
> > + .driver = {
> > + .name = TM2_TOUCHKEY_DEV_NAME,
> > + .pm = &tm2_touchkey_pm_ops,
> > + .of_match_table = of_match_ptr(tm2_touchkey_of_match),
> > + },
> > + .probe = tm2_touchkey_probe,
> > + .shutdown = tm2_touchkey_shutdown,
> > + .id_table = tm2_touchkey_id_table,
> > +};
> > +
> > +module_i2c_driver(tm2_touchkey_driver);
> > +
> > +MODULE_AUTHOR("Beomho Seo <beomho.seo@samsung.com>");
> > +MODULE_AUTHOR("Jaechul Lee <jcsing.lee@samsung.com>");
> > +MODULE_DESCRIPTION("Samsung touchkey driver");
> > +MODULE_LICENSE("GPL v2");
> >
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
From: Bjorn Andersson @ 2017-01-03 19:24 UTC (permalink / raw)
To: Vivek Gautam
Cc: Stephen Boyd, robh+dt, kishon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland,
Srinivas Kandagatla, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAFp+6iF0FQjt3bt1d_HjYmpMb8cTkg+BudoNR7yzThd+EgZfQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed 28 Dec 23:39 PST 2016, Vivek Gautam wrote:
> >> + *
> >> + */
> >> +static int phy_pipe_clk_register(struct qcom_qmp_phy *qphy, int id)
> >> +{
> >> + char clk_name[MAX_PROP_NAME];
> >
> > I'm not sure MAX_PROP_NAME is the same as some max clk name but
> > ok. We should be able to calculate that the maximum is length of
> > usb3_phy_pipe_clk_src for now though?
>
> Yea, i thought of using the same macro, considering that it provides
> 32 characters :-)
> Will rather use the length of usb3_phy_pipe_clk_src for now. May be
> #define MAX_CLK_NAME 24
>
Using a macro indicates that the size have some global meaning, but as
far as I can see it doesn't. Just write 24 and you will have enough
space for 100k pcie pipe clocks. And then use sizeof(clk_name) below.
> >
> >> + struct clk *clk;
> >> +
> >> + memset(&clk_name, 0, sizeof(clk_name));
There's no point in clearing clk_name, as it will be overwritten
and nul-terminated below.
> >> + switch (qphy->cfg->type) {
> >> + case PHY_TYPE_USB3:
> >> + snprintf(clk_name, MAX_PROP_NAME, "usb3_phy_pipe_clk_src");
> >> + break;
> >> + case PHY_TYPE_PCIE:
> >> + snprintf(clk_name, MAX_PROP_NAME, "pcie_%d_pipe_clk_src", id);
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >> +
> >> + /* controllers using QMP phys use 125MHz pipe clock interface */
> >> + clk = clk_register_fixed_rate(qphy->dev, clk_name, NULL, 0, 125000000);
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] Documetation: binding: modify the exynos5440 pcie binding
From: Rob Herring @ 2017-01-03 19:51 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, mark.rutland-5wv7dgnIgG8,
kgene-DgEjT+Ai2ygdnm+yROfE0A, krzk-DgEjT+Ai2ygdnm+yROfE0A,
kishon-l0cyMroinI0, jingoohan1-Re5JQEeQqe8AvxtiuMwx3w,
vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ,
pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ,
alim.akhtar-Sze3O3UU22JBDgjK7y7TUQ, cpgs-Sze3O3UU22JBDgjK7y7TUQ
In-Reply-To: <20161228103454.26467-4-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, Dec 28, 2016 at 07:34:53PM +0900, Jaehoon Chung wrote:
> According to using PHY framework, modified the exynos5440-pcie binding.
> And use "config" property to follow the designware-pcie binding.
You are breaking compatibility here. Please state that and why it is
okay to do so.
>
> Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> .../bindings/pci/samsung,exynos5440-pcie.txt | 29 +++++++++++++---------
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> index 4f9d23d..51f6214 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
> @@ -5,10 +5,15 @@ and thus inherits all the common properties defined in designware-pcie.txt.
>
> Required properties:
> - compatible: "samsung,exynos5440-pcie"
> -- reg: base addresses and lengths of the pcie controller,
> - the phy controller, additional register for the phy controller.
> +- reg: base addresses and lengths of the pcie controller
> - interrupts: A list of interrupt outputs for level interrupt,
> pulse interrupt, special interrupt.
> +- phys: From PHY binding. Phandle for the Generic PHY.
> + Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt
> +- phy-names: Must be "pcie-phy".
-names is pointless for a single element.
> +
> +Other common properties refer to
> + Documentation/devicetree/binding/pci/designware-pcie.txt
>
> Example:
>
> @@ -16,18 +21,18 @@ SoC specific DT Entry:
>
> pcie@290000 {
> compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x290000 0x1000
> - 0x270000 0x1000
> - 0x271000 0x40>;
> + reg = <0x290000 0x1000>, <0x40000000 0x100>;
256 bytes of config space?
> + reg-names = "elbi", "config";
> interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> clocks = <&clock 28>, <&clock 27>;
> clock-names = "pcie", "pcie_bus";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> - ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */
> - 0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
> + ranges = <0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
> 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
> + phys = <&pcie_phy0>;
> + phy-names = "pcie-phy";
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 0>;
> interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> @@ -36,17 +41,17 @@ SoC specific DT Entry:
>
> pcie@2a0000 {
> compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a0000 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> + reg = <0x2a0000 0x1000>, <0x60000000 0x1000>;
> + reg-names = "elbi", "config";
> interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> clocks = <&clock 29>, <&clock 27>;
> clock-names = "pcie", "pcie_bus";
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> - ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */
> - 0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
> + phys = <&pcie_phy1>;
> + phy-names = "pcie-phy";
> + ranges = <0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
> 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 0>;
> --
> 2.10.2
>
--
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] dt-bindings: document common IEEE 802.11 frequency properties
From: Rob Herring @ 2017-01-03 19:55 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
Martin Blumenstingl, Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161228155955.25518-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Dec 28, 2016 at 04:59:54PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> This new file should be used for properties handled at higher level and
> so usable with all drivers.
Why is this needed? Where would this data normally come from?
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> .../devicetree/bindings/net/wireless/ieee80211.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> new file mode 100644
> index 0000000..c762769
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> @@ -0,0 +1,16 @@
> +Common IEEE 802.11 properties
> +
> +This provides documentation of common properties that are handled by a proper
> +net layer and don't require extra driver code.
Not relavent to a binding. Bindings describe h/w.
> +
> +Optional properties:
> + - ieee80211-min-center-freq : minimal supported frequency in KHz
> + - ieee80211-max-center-freq : maximal supported frequency in KHz
> +
> +Example:
> +
> +pcie@0,0 {
> + reg = <0x0000 0 0 0 0>;
> + ieee80211-min-center-freq = <2437000>;
> + ieee80211-max-center-freq = <2457000>;
> +};
> --
> 2.10.1
>
> --
> 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
--
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/4] ARM: dts: Add am335x-boneblack-wireless
From: Tony Lindgren @ 2017-01-03 20:11 UTC (permalink / raw)
To: Jason Kridner
Cc: Robert Nelson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Kridner
In-Reply-To: <CB5C8999-6CAE-41F6-85A6-D2A856BD8011-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Jason Kridner <jkridner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [161228 13:27]:
>
>
> > On Dec 27, 2016, at 11:58 AM, Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
> > replaced by a TI wl1835 wireless module.
> >
> > This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
> > BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
>
> I believe the correct statement is BWxx, but BWBx reserves the option to be software incompatible in some way. My preference is to have it boot anyway, but I believe that is only dependent in the bootloader.
So does this patch need updating for that?
Regards,
Tony
--
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: [PATCHv2 net-next 01/16] dt-bindings: net: update Marvell PPv2 binding for PPv2.2 support
From: Rob Herring @ 2017-01-03 20:18 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Campbell, Pawel Moll,
Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Nadav Haklai, Hanna Hawa,
Yehuda Yitschak,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Stefan Chulski,
Marcin Wojtas
In-Reply-To: <1482943592-12556-2-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, Dec 28, 2016 at 05:46:17PM +0100, Thomas Petazzoni wrote:
> The Marvell PPv2 Device Tree binding was so far only used to describe
> the PPv2.1 network controller, used in the Marvell Armada 375.
>
> A new version of this IP block, PPv2.2 is used in the Marvell Armada
> 7K/8K processor. This commit extends the existing binding so that it can
> also be used to describe PPv2.2 hardware.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/net/marvell-pp2.txt | 66 ++++++++++++++++++----
> 1 file changed, 55 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt b/Documentation/devicetree/bindings/net/marvell-pp2.txt
> index aa4f423..76071f3 100644
> --- a/Documentation/devicetree/bindings/net/marvell-pp2.txt
> +++ b/Documentation/devicetree/bindings/net/marvell-pp2.txt
> @@ -1,17 +1,28 @@
> -* Marvell Armada 375 Ethernet Controller (PPv2)
> +* Marvell Armada 375 Ethernet Controller (PPv2.1)
> + Marvell Armada 7K/8K Ethernet Controller (PPv2.2)
>
> Required properties:
>
> -- compatible: should be "marvell,armada-375-pp2"
> +- compatible: should be one of:
> + "marvell,armada-375-pp2"
> + "marvell,armada-7k-pp2"
> - reg: addresses and length of the register sets for the device.
> - Must contain the following register sets:
> + For "marvell,armada-375-pp2", must contain the following register
> + sets:
> - common controller registers
> - LMS registers
> - In addition, at least one port register set is required.
> -- clocks: a pointer to the reference clocks for this device, consequently:
> - - main controller clock
> - - GOP clock
> -- clock-names: names of used clocks, must be "pp_clk" and "gop_clk".
> + - one register area per Ethernet port
> + For "marvell,armda-7k-pp2", must contain the following register
> + sets:
> + - common controller registers
> + - per-port registers
> +
> +- clocks: pointers to the reference clocks for this device, consequently:
> + - main controller clock (for both armada-375-pp2 and armada-7k-pp2)
> + - GOP clock (for both armada-375-pp2 and armada-7k-pp2)
> + - MG clock (only for armada-7k-pp2)
> +- clock-names: names of used clocks, must be "pp_clk", "gop_clk" and
> + "mg_clk" (the latter only for armada-7k-pp2).
>
> The ethernet ports are represented by subnodes. At least one port is
> required.
> @@ -19,8 +30,9 @@ required.
> Required properties (port):
>
> - interrupts: interrupt for the port
> -- port-id: should be '0' or '1' for ethernet ports, and '2' for the
> - loopback port
> +- port-id: ID of the port from the MAC point of view
> +- gop-port-id: only for marvell,armada-7k-pp2, ID of the port from the
> + GOP (Group Of Ports) point of view
What GOP is needs a better explanation. Why doesn't 375 need this?
> - phy-mode: See ethernet.txt file in the same directory
>
> Optional properties (port):
> @@ -31,7 +43,7 @@ Optional properties (port):
> then fixed link is assumed, and the 'fixed-link' property is
> mandatory.
>
> -Example:
> +Example for marvell,armada-375-pp2:
>
> ethernet@f0000 {
> compatible = "marvell,armada-375-pp2";
> @@ -59,3 +71,35 @@ ethernet@f0000 {
> phy-mode = "gmii";
> };
> };
> +
> +Example for marvell,armada-7k-pp2:
> +
> +cpm_ethernet: ethernet@0 {
> + compatible = "marvell,armada-7k-pp22";
> + reg = <0x0 0x100000>,
> + <0x100000 0x80000>;
> + clocks = <&cpm_syscon0 1 3>, <&cpm_syscon0 1 9>, <&cpm_syscon0 1 5>;
> + clock-names = "pp_clk", "gop_clk", "gp_clk";
> + status = "disabled";
Drop status from examples.
> +
> + eth0: eth@0 {
unit address requires a reg property. Or this can be 'eth0' instead.
> + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
> + port-id = <0>;
> + gop-port-id = <0>;
> + status = "disabled";
> + };
> +
> + eth1: eth@1 {
> + interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
> + port-id = <1>;
> + gop-port-id = <2>;
> + status = "disabled";
> + };
> +
> + eth2: eth@2 {
> + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> + port-id = <2>;
> + gop-port-id = <3>;
> + status = "disabled";
> + };
> +};
> --
> 2.7.4
>
> --
> 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
--
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] dt-bindings: document common IEEE 802.11 frequency properties
From: Rafał Miłecki @ 2017-01-03 20:20 UTC (permalink / raw)
To: Rob Herring
Cc: Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <20170103195514.vf4psb6qw2bd2lcw@rob-hp-laptop>
On 3 January 2017 at 20:55, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Dec 28, 2016 at 04:59:54PM +0100, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>
>> This new file should be used for properties handled at higher level and
>> so usable with all drivers.
>
> Why is this needed? Where would this data normally come from?
Vendors limit choice of channels at their web user interface level. I
want to do better and report proper channels directly at kernel level
instead of masking them in every possible configuration tool.
>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>> ---
>> .../devicetree/bindings/net/wireless/ieee80211.txt | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> new file mode 100644
>> index 0000000..c762769
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>> @@ -0,0 +1,16 @@
>> +Common IEEE 802.11 properties
>> +
>> +This provides documentation of common properties that are handled by a proper
>> +net layer and don't require extra driver code.
>
> Not relavent to a binding. Bindings describe h/w.
Yes, Arend pointed it to me and I improved this Documentation file in
further versions. Could you review V4, please?
https://patchwork.kernel.org/patch/9494713/
--
Rafał
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: Christopher Spinrath @ 2017-01-03 20:23 UTC (permalink / raw)
To: Shawn Guo, p.zabel
Cc: mark.rutland, devicetree, christopher.spinrath, linux, robh+dt,
grinberg, kernel, fabio.estevam, linux-arm-kernel
In-Reply-To: <27256207f2d84b1ca4b7dfc41a413fcc@rwthex-s2-a.rwth-ad.de>
Hi Shawn,
thanks for the review!
On 12/30/2016 03:27 PM, Shawn Guo wrote:
> On Fri, Dec 02, 2016 at 03:37:22PM +0100, christopher.spinrath@rwth-aachen.de wrote:
>> From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>>
>> Apart from the already enabled Designware HDMI port, the Utilite Pro
>> has a second display pipeline which has the following shape:
>>
>> IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
>> --> HDMI connector.
>> Enable support for it.
>>
>> In addition, since this pipeline is hardwired to IPU1, sever the link
>> between IPU1 and the SoC-internal Designware HDMI encoder forcing the
>> latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
>> possible to drive both displays at high resolution due to the bandwidth
>> limitations of a single IPU.
>>
>> Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
>
> @Philipp, can you help review the changes?
>
>> ---
>>
>> Hi all,
>>
>> the removal of the link between IPU1 and the Designware HDMI encoder is the
>> result of a discussion I had with Philipp Zabel:
>>
>> https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
>>
>> Altough it is not possible to connect anything else to IPU1 on the Utilite, this
>> approach has at least one disadvantage: if the resolution is low enough such
>> that a single IPU can handle both displays then muxing both displays to IPU1
>> would reduce the power consumption.
>>
>> However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
>> solution since I'm not aware of any OS/driver that is capable of switching IPUs
>> or can handle the bandwidth limitation in a sane way. In particular, Linux is
>> unusable when both displays are supposed to be driven at high resolution and
>> both muxing options for the DW HDMI are available (this is not a userspace
>> issue; the system becomes almost unresponsive as soon as the kernel sets the
>> initial resolution).
>>
>> Cheers,
>> Christopher
>>
>> P.S.: this patch depends on the tfp410 bridge driver which has recently been
>> merged into drm-next.
>
> v4.10-rc1 has the driver, so the dependency is gone now, I guess.
That's correct.
>>
>> arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
>> 1 file changed, 115 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> index 2200994..69bdd82 100644
>> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
>> @@ -59,6 +59,33 @@
>> rtc1 = &snvs_rtc;
>> };
>>
>> + encoder {
>> + compatible = "ti,tfp410";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + tfp410_in: endpoint {
>> + remote-endpoint = <¶llel_display_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + tfp410_out: endpoint {
>> + remote-endpoint = <&hdmi_connector_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> gpio-keys {
>> compatible = "gpio-keys";
>> pinctrl-names = "default";
>> @@ -72,6 +99,19 @@
>> };
>> };
>>
>> + hdmi-connector {
>> + compatible = "hdmi-connector";
>> +
>
> The newline is unnecessary.
>
>> + type = "a";
>> + ddc-i2c-bus = <&i2c_dvi_ddc>;
>> +
>> + port {
>> + hdmi_connector_in: endpoint {
>> + remote-endpoint = <&tfp410_out>;
>> + };
>> + };
>> + };
>> +
>> i2cmux {
>> compatible = "i2c-mux-gpio";
>> pinctrl-names = "default";
>> @@ -105,8 +145,46 @@
>> #size-cells = <0>;
>> };
>> };
>> +
>> + parallel-display {
>> + compatible = "fsl,imx-parallel-display";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ipu1>;
>> +
>
> Ditto
>
> I can fix them up if I get a Reviewed-by tag from Philipp on this
> version.
Thanks. I'll bear that in mind for future patches (and, of course, I
will fix them up myself if I have to send a v2).
Cheers,
Christopher
> Shawn
>
>> + interface-pix-fmt = "rgb24";
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + parallel_display_in: endpoint {
>> + remote-endpoint = <&ipu1_di0_disp0>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + parallel_display_out: endpoint {
>> + remote-endpoint = <&tfp410_in>;
>> + };
>> + };
>> + };
>> };
>>
>> +/*
>> + * A single IPU is not able to drive both display interfaces available on the
>> + * Utilite Pro at high resolution due to its bandwidth limitation. Since the
>> + * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
>> + * SoC-internal Designware HDMI encoder forcing the latter to be connected to
>> + * IPU2 instead of IPU1.
>> + */
>> +/delete-node/&ipu1_di0_hdmi;
>> +/delete-node/&hdmi_mux_0;
>> +/delete-node/&ipu1_di1_hdmi;
>> +/delete-node/&hdmi_mux_1;
>> +
>> &hdmi {
>> ddc-i2c-bus = <&i2c2>;
>> status = "okay";
>> @@ -151,6 +229,39 @@
>> >;
>> };
>>
>> + pinctrl_ipu1: ipu1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
>> + MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x38
>> + MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x38
>> + MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x38
>> + MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0x38
>> + MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x38
>> + MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x38
>> + MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x38
>> + MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x38
>> + MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x38
>> + MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x38
>> + MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x38
>> + MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x38
>> + MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x38
>> + MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x38
>> + MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x38
>> + MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x38
>> + MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x38
>> + MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x38
>> + MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x38
>> + MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x38
>> + MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x38
>> + MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x38
>> + MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x38
>> + MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x38
>> + MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x38
>> + MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x38
>> + MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x38
>> + >;
>> + };
>> +
>> pinctrl_uart2: uart2grp {
>> fsl,pins = <
>> MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
>> @@ -194,6 +305,10 @@
>> };
>> };
>>
>> +&ipu1_di0_disp0 {
>> + remote-endpoint = <¶llel_display_in>;
>> +};
>> +
>> &pcie {
>> pcie@0,0 {
>> reg = <0x000000 0 0 0 0>;
>> --
>> 2.10.2
>>
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: Add am335x-boneblack-wireless
From: Jason Kridner @ 2017-01-03 20:29 UTC (permalink / raw)
To: Tony Lindgren
Cc: Robert Nelson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Kridner
In-Reply-To: <20170103201103.GB25222-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> On Jan 3, 2017, at 3:11 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
>
> * Jason Kridner <jkridner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [161228 13:27]:
>>
>>
>>> On Dec 27, 2016, at 11:58 AM, Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>> BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
>>> replaced by a TI wl1835 wireless module.
>>>
>>> This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
>>> BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
>>
>> I believe the correct statement is BWxx, but BWBx reserves the option to be software incompatible in some way. My preference is to have it boot anyway, but I believe that is only dependent in the bootloader.
>
> So does this patch need updating for that?
No, it is bootloader controlled.
>
> Regards,
>
> Tony
--
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] dt: bindings: Add support for CSI1 bus
From: Rob Herring @ 2017-01-03 20:38 UTC (permalink / raw)
To: Pavel Machek
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
sakari.ailus-X3B1VOXEql0, sre-DgEjT+Ai2ygdnm+yROfE0A,
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161228183036.GA13139@amd>
On Wed, Dec 28, 2016 at 07:30:36PM +0100, Pavel Machek wrote:
> From: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
>
> In the vast majority of cases the bus type is known to the driver(s)
> since a receiver or transmitter can only support a single one. There
> are cases however where different options are possible.
What cases specifically?
> Document the CSI1/CCP2 properties strobe_clk_inv and strobe_clock
> properties. The former tells whether the strobe/clock signal is
> inverted, while the latter signifies the clock or strobe mode.
>
> Signed-off-by: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
>
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index 9cd2a36..f0523f7 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -76,6 +76,10 @@ Optional endpoint properties
> mode horizontal and vertical synchronization signals are provided to the
> slave device (data source) by the master device (data sink). In the master
> mode the data source device is also the source of the synchronization signals.
> +- bus-type: data bus type. Possible values are:
> + 0 - CSI2
As in MIPI CSI2?
> + 1 - parallel / Bt656
> + 2 - CCP2
> - bus-width: number of data lines actively used, valid for the parallel busses.
> - data-shift: on the parallel data busses, if bus-width is used to specify the
> number of data lines, data-shift can be used to specify which data lines are
> @@ -110,9 +114,10 @@ Optional endpoint properties
> lane and followed by the data lanes in the same order as in data-lanes.
> Valid values are 0 (normal) and 1 (inverted). The length of the array
> should be the combined length of data-lanes and clock-lanes properties.
> - If the lane-polarities property is omitted, the value must be interpreted
> - as 0 (normal). This property is valid for serial busses only.
Why is this removed?
> -
> +- clock-inv: Clock or strobe signal inversion.
> + Possible values: 0 -- not inverted; 1 -- inverted
"invert" assumes I know what is normal and I do not. Define what is
"normal" and name the property the opposite of that. If normal is data
shifted on clock rising edge, then call the the property
"clock-shift-falling-edge" for example..
> +- strobe: Whether the clock signal is used as clock or strobe. Used
> + with CCP2, for instance.
>
> Example
> -------
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 1/2] dt-bindings: Document the hi3660 clock bindings
From: Rob Herring @ 2017-01-03 20:40 UTC (permalink / raw)
To: Zhangfei Gao
Cc: Stephen Boyd, Arnd Bergmann,
haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A, guodong Xu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1482978805-6981-2-git-send-email-zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Dec 29, 2016 at 10:33:24AM +0800, Zhangfei Gao wrote:
> Add DT bindings documentation for hi3660 SoC clock.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/clock/hi3660-clock.txt | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/hi3660-clock.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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 v5 2/4] dt-bindings: add bindings for rk3328 clock controller
From: Rob Herring @ 2017-01-03 20:41 UTC (permalink / raw)
To: Elaine Zhang
Cc: heiko-4mtYJXux2i+zQB+pC5nmwQ, mturquette-rdvid1DuHRBWk0Htik3J/w,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, xf-TNX95d0MmH7DzftRWevZcw,
mark.rutland-5wv7dgnIgG8, linux-clk-u79uwXL29TY76Z2rM5mHXA,
huangtao-TNX95d0MmH7DzftRWevZcw, xxx-TNX95d0MmH7DzftRWevZcw,
cl-TNX95d0MmH7DzftRWevZcw,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1482979511-6847-3-git-send-email-zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Thu, Dec 29, 2016 at 10:45:09AM +0800, Elaine Zhang wrote:
> Add devicetree bindings for Rockchip cru which found on
> Rockchip SoCs.
>
> Changes in v4:
> dropping the "rockchip,cru" and "syscon" properties for bindings of rk3328
>
> Signed-off-by: Elaine Zhang <zhangqing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> .../bindings/clock/rockchip,rk3328-cru.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3328-cru.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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/4] ARM: dts: Add am335x-boneblack-wireless
From: Tony Lindgren @ 2017-01-03 20:43 UTC (permalink / raw)
To: Jason Kridner
Cc: devicetree, linux-omap, Robert Nelson, linux-arm-kernel,
Jason Kridner
In-Reply-To: <2D5ABB5A-E332-4D77-89EA-9DBF9A2FECFB@gmail.com>
* Jason Kridner <jkridner@gmail.com> [170103 12:30]:
>
>
> > On Jan 3, 2017, at 3:11 PM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > * Jason Kridner <jkridner@gmail.com> [161228 13:27]:
> >>
> >>
> >>> On Dec 27, 2016, at 11:58 AM, Robert Nelson <robertcnelson@gmail.com> wrote:
> >>>
> >>> BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
> >>> replaced by a TI wl1835 wireless module.
> >>>
> >>> This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
> >>> BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
> >>
> >> I believe the correct statement is BWxx, but BWBx reserves the option to be software incompatible in some way. My preference is to have it boot anyway, but I believe that is only dependent in the bootloader.
> >
> > So does this patch need updating for that?
>
> No, it is bootloader controlled.
What about the patch description? Does it need updating or is that
an Acked-by?
Tony
^ permalink raw reply
* Re: [PATCH 00/20] i.MX Media Driver
From: Steve Longerbeam @ 2017-01-03 20:50 UTC (permalink / raw)
To: Fabio Estevam, Steve Longerbeam, Hans Verkuil
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
Russell King - ARM Linux, Linus Walleij, Alexandre Courbot,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, Greg Kroah-Hartman, Philipp Zabel,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-media
In-Reply-To: <CAOMZO5DM4aRwzCWkRoZLmbCxn155YL+CUR_gJyDh+FjzSKD3PQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Fabio,
On 01/02/2017 01:09 PM, Fabio Estevam wrote:
> Hi Steve,
>
> On Thu, Dec 29, 2016 at 8:27 PM, Steve Longerbeam <slongerbeam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> This is a media driver for video capture on i.MX.
>>
>> Refer to Documentation/media/v4l-drivers/imx.rst for example capture
>> pipelines on SabreSD, SabreAuto, and SabreLite reference platforms.
>>
>> This patchset includes the OF graph layout as proposed by Philipp Zabel,
>> with only minor changes which are enumerated in the patch header.
> Patches 13, 14 and 19 miss your Signed-off-by tag.
thanks for catching. I've added them to version 2.
Steve
>
> Tested the whole series on a mx6qsabresd:
>
> Tested-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
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] dt-bindings: leds: document new usb-ports property
From: Rob Herring @ 2017-01-03 20:52 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Greg Kroah-Hartman, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Richard Purdie,
Jacek Anaszewski, Pavel Machek, devicetree-u79uwXL29TY76Z2rM5mHXA,
Mark Rutland, Rafał Miłecki
In-Reply-To: <20161229130306.30400-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Dec 29, 2016 at 02:03:04PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Some LEDs can be related to particular USB ports (common case for home
> routers). This property allows describing such a relation.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> This patch is based on top of commit 52e847dc431 ("DT: leds: Improve examples
> by adding some context") sitting in the linux-leds.git (for-4.11).
> ---
> Documentation/devicetree/bindings/leds/common.txt | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index 24b6560..fcfe661 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -49,6 +49,14 @@ Optional properties for child nodes:
> - panic-indicator : This property specifies that the LED should be used,
> if at all possible, as a panic indicator.
>
> +- usb-ports : List of USB ports related to this LED. Some devices have LEDs that
> + should be used to indicate USB device activity. This can be
> + described with this property.
> + There can be more than one LED like this, e.g. some vendors use
> + one controller per USB version. It's then common to use different
> + color LEDs depending on device USB standard (like USB 2.0 vs.
> + USB 3.0).
I don't like this being USB specific. Either we should have a generic
way to link triggers to other DT nodes or the existing trigger property
should be used (and be capable of listing more than 1 port). I'd prefer
the latter as I don't think we need another way to specify triggers.
> +
> Required properties for flash LED child nodes:
> - flash-max-microamp : Maximum flash LED supply current in microamperes.
> - flash-max-timeout-us : Maximum timeout in microseconds after which the flash
> @@ -69,6 +77,11 @@ gpio-leds {
> linux,default-trigger = "heartbeat";
> gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> };
> +
> + usb {
> + gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> + usb-ports = <&ohci_port1>, <&ehci_port1>;
> + };
> };
>
> max77693-led {
> --
> 2.10.1
>
--
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 v2 00/19] i.MX Media Driver
From: Steve Longerbeam @ 2017-01-03 20:57 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam, robh+dt, mark.rutland, linux,
mchehab, gregkh, p.zabel
Cc: linux-arm-kernel, devicetree, linux-kernel, linux-media, devel,
Steve Longerbeam
In version 2 (no functional changes):
- removed patch "gpio: pca953x: Add optional reset gpio control", it
has been submitted separately.
- fixed some whitespace errors.
- added a few missing Signed-off-by's.
Philipp Zabel (2):
ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their
connections
media: imx: Add video switch subdev driver
Steve Longerbeam (17):
ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
ARM: dts: imx6qdl: add media device
ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabreauto: create i2cmux for i2c3
ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
media: Add i.MX media core driver
media: imx: Add CSI subdev driver
media: imx: Add SMFC subdev driver
media: imx: Add IC subdev drivers
media: imx: Add Camera Interface subdev driver
media: imx: Add MIPI CSI-2 Receiver subdev driver
media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver
media: imx: Add Parallel OV5642 sensor subdev driver
ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers
Documentation/devicetree/bindings/media/imx.txt | 205 +
Documentation/media/v4l-drivers/imx.rst | 430 ++
arch/arm/boot/dts/imx6dl-sabrelite.dts | 5 +
arch/arm/boot/dts/imx6dl-sabresd.dts | 5 +
arch/arm/boot/dts/imx6dl.dtsi | 183 +
arch/arm/boot/dts/imx6q-sabrelite.dts | 6 +
arch/arm/boot/dts/imx6q-sabresd.dts | 5 +
arch/arm/boot/dts/imx6q.dtsi | 123 +
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 142 +-
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 122 +-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 +-
arch/arm/boot/dts/imx6qdl.dtsi | 25 +-
arch/arm/configs/imx_v6_v7_defconfig | 10 +-
drivers/staging/media/Kconfig | 2 +
drivers/staging/media/Makefile | 1 +
drivers/staging/media/imx/Kconfig | 36 +
drivers/staging/media/imx/Makefile | 16 +
drivers/staging/media/imx/TODO | 18 +
drivers/staging/media/imx/imx-camif.c | 1010 +++++
drivers/staging/media/imx/imx-csi.c | 638 +++
drivers/staging/media/imx/imx-ic-common.c | 113 +
drivers/staging/media/imx/imx-ic-pp.c | 636 +++
drivers/staging/media/imx/imx-ic-prpenc.c | 1037 +++++
drivers/staging/media/imx/imx-ic-prpvf.c | 1180 ++++++
drivers/staging/media/imx/imx-ic.h | 36 +
drivers/staging/media/imx/imx-media-common.c | 985 +++++
drivers/staging/media/imx/imx-media-dev.c | 479 +++
drivers/staging/media/imx/imx-media-fim.c | 509 +++
drivers/staging/media/imx/imx-media-internal-sd.c | 457 +++
drivers/staging/media/imx/imx-media-of.c | 291 ++
drivers/staging/media/imx/imx-media-of.h | 25 +
drivers/staging/media/imx/imx-media.h | 299 ++
drivers/staging/media/imx/imx-mipi-csi2.c | 509 +++
drivers/staging/media/imx/imx-smfc.c | 739 ++++
drivers/staging/media/imx/imx-video-switch.c | 351 ++
drivers/staging/media/imx/ov5640-mipi.c | 2349 +++++++++++
drivers/staging/media/imx/ov5642.c | 4364 +++++++++++++++++++++
include/media/imx.h | 15 +
include/uapi/Kbuild | 1 +
include/uapi/linux/v4l2-controls.h | 4 +
include/uapi/media/Kbuild | 2 +
include/uapi/media/imx.h | 30 +
42 files changed, 17479 insertions(+), 28 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/imx.txt
create mode 100644 Documentation/media/v4l-drivers/imx.rst
create mode 100644 drivers/staging/media/imx/Kconfig
create mode 100644 drivers/staging/media/imx/Makefile
create mode 100644 drivers/staging/media/imx/TODO
create mode 100644 drivers/staging/media/imx/imx-camif.c
create mode 100644 drivers/staging/media/imx/imx-csi.c
create mode 100644 drivers/staging/media/imx/imx-ic-common.c
create mode 100644 drivers/staging/media/imx/imx-ic-pp.c
create mode 100644 drivers/staging/media/imx/imx-ic-prpenc.c
create mode 100644 drivers/staging/media/imx/imx-ic-prpvf.c
create mode 100644 drivers/staging/media/imx/imx-ic.h
create mode 100644 drivers/staging/media/imx/imx-media-common.c
create mode 100644 drivers/staging/media/imx/imx-media-dev.c
create mode 100644 drivers/staging/media/imx/imx-media-fim.c
create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
create mode 100644 drivers/staging/media/imx/imx-media-of.c
create mode 100644 drivers/staging/media/imx/imx-media-of.h
create mode 100644 drivers/staging/media/imx/imx-media.h
create mode 100644 drivers/staging/media/imx/imx-mipi-csi2.c
create mode 100644 drivers/staging/media/imx/imx-smfc.c
create mode 100644 drivers/staging/media/imx/imx-video-switch.c
create mode 100644 drivers/staging/media/imx/ov5640-mipi.c
create mode 100644 drivers/staging/media/imx/ov5642.c
create mode 100644 include/media/imx.h
create mode 100644 include/uapi/media/Kbuild
create mode 100644 include/uapi/media/imx.h
--
2.7.4
^ permalink raw reply
* [PATCH v2 01/19] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
From: Steve Longerbeam @ 2017-01-03 20:57 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam, robh+dt, mark.rutland, linux,
mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <1483477049-19056-1-git-send-email-steve_longerbeam@mentor.com>
Add to the MIPI CSI2 receiver node: compatible string, interrupt sources,
clocks.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63..7b546e3 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1125,7 +1125,14 @@
};
mipi_csi: mipi@021dc000 {
+ compatible = "fsl,imx-mipi-csi2";
reg = <0x021dc000 0x4000>;
+ interrupts = <0 100 0x04>, <0 101 0x04>;
+ clocks = <&clks IMX6QDL_CLK_HSI_TX>,
+ <&clks IMX6QDL_CLK_VIDEO_27M>,
+ <&clks IMX6QDL_CLK_EIM_SEL>;
+ clock-names = "dphy_clk", "cfg_clk", "pix_clk";
+ status = "disabled";
};
mipi_dsi: mipi@021e0000 {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 02/19] ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their connections
From: Steve Longerbeam @ 2017-01-03 20:57 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mchehab-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Steve Longerbeam
In-Reply-To: <1483477049-19056-1-git-send-email-steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
This patch adds the device tree graph connecting the input multiplexers
to the IPU CSIs and the MIPI-CSI2 gasket on i.MX6. The MIPI_IPU
multiplexers are added as children of the iomuxc-gpr syscon device node.
On i.MX6Q/D two two-input multiplexers in front of IPU1 CSI0 and IPU2
CSI1 allow to select between CSI0/1 parallel input pads and the MIPI
CSI-2 virtual channels 0/3.
On i.MX6DL/S two five-input multiplexers in front of IPU1 CSI0 and IPU1
CSI1 allow to select between CSI0/1 parallel input pads and any of the
four MIPI CSI-2 virtual channels.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
- Removed some dangling/unused endpoints (ipu2_csi0_from_csi2ipu)
- Renamed the mipi virtual channel endpoint labels, from "mipi_csiX_..."
to "mipi_vcX...".
- Added input endpoints to the video muxes for the connections from parallel
sensors.
- Added input endpoints to the mipi_csi for the connections from mipi csi-2
sensors.
- The video multiplexer node has compatible string "imx-video-mux" instead
of "video-multiplexer".
- The video multiplexer node indicates GPR register via reg propert only,
(register offset and bitmask), instead of specifying with "bit-mask" and
"bit-shift" properties.
Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
---
arch/arm/boot/dts/imx6dl.dtsi | 183 +++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6q.dtsi | 119 +++++++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl.dtsi | 10 ++-
3 files changed, 311 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 1ade195..0a1718c 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -181,6 +181,189 @@
"di0", "di1";
};
+&gpr {
+ ipu1_csi0_mux: ipu1_csi0_mux@34 {
+ compatible = "imx-video-mux";
+ reg = <0x34 0x07>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port@0 {
+ reg = <0>;
+
+ ipu1_csi0_mux_from_mipi_vc0: endpoint {
+ remote-endpoint = <&mipi_vc0_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ipu1_csi0_mux_from_mipi_vc1: endpoint {
+ remote-endpoint = <&mipi_vc1_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ ipu1_csi0_mux_from_mipi_vc2: endpoint {
+ remote-endpoint = <&mipi_vc2_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ ipu1_csi0_mux_from_mipi_vc3: endpoint {
+ remote-endpoint = <&mipi_vc3_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ ipu1_csi0_mux_from_parallel_sensor: endpoint {
+ };
+ };
+
+ port@5 {
+ reg = <5>;
+
+ ipu1_csi0_mux_to_ipu1_csi0: endpoint {
+ remote-endpoint = <&ipu1_csi0_from_ipu1_csi0_mux>;
+ };
+ };
+ };
+
+ ipu1_csi1_mux: ipu1_csi1_mux@34 {
+ compatible = "imx-video-mux";
+ reg = <0x34 0x38>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port@0 {
+ reg = <0>;
+
+ ipu1_csi1_mux_from_mipi_vc0: endpoint {
+ remote-endpoint = <&mipi_vc0_to_ipu1_csi1_mux>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ipu1_csi1_mux_from_mipi_vc1: endpoint {
+ remote-endpoint = <&mipi_vc1_to_ipu1_csi1_mux>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ ipu1_csi1_mux_from_mipi_vc2: endpoint {
+ remote-endpoint = <&mipi_vc2_to_ipu1_csi1_mux>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ ipu1_csi1_mux_from_mipi_vc3: endpoint {
+ remote-endpoint = <&mipi_vc3_to_ipu1_csi1_mux>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ ipu1_csi1_mux_from_parallel_sensor: endpoint {
+ };
+ };
+
+ port@5 {
+ reg = <5>;
+
+ ipu1_csi1_mux_to_ipu1_csi1: endpoint {
+ remote-endpoint = <&ipu1_csi1_from_ipu1_csi1_mux>;
+ };
+ };
+ };
+};
+
+&ipu1_csi1 {
+ ipu1_csi1_from_ipu1_csi1_mux: endpoint {
+ remote-endpoint = <&ipu1_csi1_mux_to_ipu1_csi1>;
+ };
+};
+
+&mipi_csi {
+ port@0 {
+ reg = <0>;
+
+ mipi_csi_from_mipi_sensor: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_vc0_to_ipu1_csi0_mux: endpoint@0 {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc0>;
+ };
+
+ mipi_vc0_to_ipu1_csi1_mux: endpoint@1 {
+ remote-endpoint = <&ipu1_csi1_mux_from_mipi_vc0>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_vc1_to_ipu1_csi0_mux: endpoint@0 {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc1>;
+ };
+
+ mipi_vc1_to_ipu1_csi1_mux: endpoint@1 {
+ remote-endpoint = <&ipu1_csi1_mux_from_mipi_vc1>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_vc2_to_ipu1_csi0_mux: endpoint@0 {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc2>;
+ };
+
+ mipi_vc2_to_ipu1_csi1_mux: endpoint@1 {
+ remote-endpoint = <&ipu1_csi1_mux_from_mipi_vc2>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_vc3_to_ipu1_csi0_mux: endpoint@0 {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc3>;
+ };
+
+ mipi_vc3_to_ipu1_csi1_mux: endpoint@1 {
+ remote-endpoint = <&ipu1_csi1_mux_from_mipi_vc3>;
+ };
+ };
+};
+
&vpu {
compatible = "fsl,imx6dl-vpu", "cnm,coda960";
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e9a5d0b..56a314f 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -143,10 +143,18 @@
ipu2_csi0: port@0 {
reg = <0>;
+
+ ipu2_csi0_from_mipi_vc2: endpoint {
+ remote-endpoint = <&mipi_vc2_to_ipu2_csi0>;
+ };
};
ipu2_csi1: port@1 {
reg = <1>;
+
+ ipu2_csi1_from_ipu2_csi1_mux: endpoint {
+ remote-endpoint = <&ipu2_csi1_mux_to_ipu2_csi1>;
+ };
};
ipu2_di0: port@2 {
@@ -266,6 +274,76 @@
};
};
+&gpr {
+ ipu1_csi0_mux: ipu1_csi0_mux@4 {
+ compatible = "imx-video-mux";
+ reg = <0x04 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port@0 {
+ reg = <0>;
+
+ ipu1_csi0_mux_from_mipi_vc0: endpoint {
+ remote-endpoint = <&mipi_vc0_to_ipu1_csi0_mux>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ipu1_csi0_mux_from_parallel_sensor: endpoint {
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ ipu1_csi0_mux_to_ipu1_csi0: endpoint {
+ remote-endpoint = <&ipu1_csi0_from_ipu1_csi0_mux>;
+ };
+ };
+ };
+
+ ipu2_csi1_mux: ipu2_csi1_mux@4 {
+ compatible = "imx-video-mux";
+ reg = <0x04 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ port@0 {
+ reg = <0>;
+
+ ipu2_csi1_mux_from_mipi_vc3: endpoint {
+ remote-endpoint = <&mipi_vc3_to_ipu2_csi1_mux>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ipu2_csi1_mux_from_parallel_sensor: endpoint {
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ ipu2_csi1_mux_to_ipu2_csi1: endpoint {
+ remote-endpoint = <&ipu2_csi1_from_ipu2_csi1_mux>;
+ };
+ };
+ };
+};
+
+&ipu1_csi1 {
+ ipu1_csi1_from_mipi_vc1: endpoint {
+ remote-endpoint = <&mipi_vc1_to_ipu1_csi1>;
+ };
+};
+
&ldb {
clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>, <&clks IMX6QDL_CLK_LDB_DI1_SEL>,
<&clks IMX6QDL_CLK_IPU1_DI0_SEL>, <&clks IMX6QDL_CLK_IPU1_DI1_SEL>,
@@ -312,6 +390,47 @@
};
};
+&mipi_csi {
+ port@0 {
+ reg = <0>;
+
+ mipi_csi_from_mipi_sensor: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_vc0_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_from_mipi_vc0>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ mipi_vc1_to_ipu1_csi1: endpoint {
+ remote-endpoint = <&ipu1_csi1_from_mipi_vc1>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+
+ mipi_vc2_to_ipu2_csi0: endpoint {
+ remote-endpoint = <&ipu2_csi0_from_mipi_vc2>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ mipi_vc3_to_ipu2_csi1_mux: endpoint {
+ remote-endpoint = <&ipu2_csi1_mux_from_mipi_vc3>;
+ };
+ };
+};
+
&mipi_dsi {
ports {
port@2 {
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 7b546e3..89218a4 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -799,8 +799,10 @@
};
gpr: iomuxc-gpr@020e0000 {
- compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
+ compatible = "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd";
reg = <0x020e0000 0x38>;
+ #address-cells = <1>;
+ #size-cells = <0>;
};
iomuxc: iomuxc@020e0000 {
@@ -1127,6 +1129,8 @@
mipi_csi: mipi@021dc000 {
compatible = "fsl,imx-mipi-csi2";
reg = <0x021dc000 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
interrupts = <0 100 0x04>, <0 101 0x04>;
clocks = <&clks IMX6QDL_CLK_HSI_TX>,
<&clks IMX6QDL_CLK_VIDEO_27M>,
@@ -1232,6 +1236,10 @@
ipu1_csi0: port@0 {
reg = <0>;
+
+ ipu1_csi0_from_ipu1_csi0_mux: endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_to_ipu1_csi0>;
+ };
};
ipu1_csi1: port@1 {
--
2.7.4
--
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 v2 03/19] ARM: dts: imx6qdl: add media device
From: Steve Longerbeam @ 2017-01-03 20:57 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam, robh+dt, mark.rutland, linux,
mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <1483477049-19056-1-git-send-email-steve_longerbeam@mentor.com>
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6q.dtsi | 4 ++++
arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 56a314f..2fbe0b3 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -454,3 +454,7 @@
&vpu {
compatible = "fsl,imx6q-vpu", "cnm,coda960";
};
+
+&media0 {
+ ports = <&ipu1_csi0>, <&ipu1_csi1>, <&ipu2_csi0>, <&ipu2_csi1>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 89218a4..12ae045 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1296,5 +1296,13 @@
};
};
};
+
+ media0: media@0 {
+ compatible = "fsl,imx-media";
+ ports = <&ipu1_csi0>, <&ipu1_csi1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 04/19] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
From: Steve Longerbeam @ 2017-01-03 20:57 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam, robh+dt, mark.rutland, linux,
mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <1483477049-19056-1-git-send-email-steve_longerbeam@mentor.com>
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
Both hang off the same i2c2 bus, so they require different (and non-
default) i2c slave addresses.
The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi. It is set to transmit over MIPI virtual channel 1.
Note there is a pin conflict with GPIO6. This pin functions as a power
input pin to the OV5642, but ENET uses it as the h/w workaround for
erratum ERR006687, to wake-up the ARM cores on normal RX and TX packet
done events (see 6261c4c8). So workaround 6261c4c8 is reverted here to
support the OV5642, and the "fsl,err006687-workaround-present" boolean
also must be removed. The result is that the CPUidle driver will no longer
allow entering the deep idle states on the sabrelite.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6dl-sabrelite.dts | 5 ++
arch/arm/boot/dts/imx6q-sabrelite.dts | 6 ++
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 122 ++++++++++++++++++++++++++++++-
3 files changed, 129 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts b/arch/arm/boot/dts/imx6dl-sabrelite.dts
index 0f06ca5..fec2524 100644
--- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
@@ -48,3 +48,8 @@
model = "Freescale i.MX6 DualLite SABRE Lite Board";
compatible = "fsl,imx6dl-sabrelite", "fsl,imx6dl";
};
+
+&ipu1_csi1_from_ipu1_csi1_mux {
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts b/arch/arm/boot/dts/imx6q-sabrelite.dts
index 66d10d8..9e2d26d 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -52,3 +52,9 @@
&sata {
status = "okay";
};
+
+&ipu1_csi1_from_mipi_vc1 {
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
+
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 1f9076e..4a50bb1 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -39,6 +39,8 @@
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
+
+#include <dt-bindings/clock/imx6qdl-clock.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
@@ -96,6 +98,15 @@
};
};
+ mipi_xclk: mipi_xclk {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <22000000>;
+ clock-output-names = "mipi_pwm3";
+ pwms = <&pwm3 0 45>; /* 1 / 45 ns = 22 MHz */
+ status = "okay";
+ };
+
gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
@@ -220,6 +231,22 @@
};
};
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <8>;
+ data-shift = <12>; /* Lines 19:12 used */
+ hsync-active = <1>;
+ vync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&ov5642_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
+};
+
&audmux {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
@@ -271,9 +298,6 @@
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
- interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
- <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
- fsl,err006687-workaround-present;
status = "okay";
};
@@ -302,6 +326,52 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2>;
status = "okay";
+
+ camera: ov5642@42 {
+ compatible = "ovti,ov5642";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5642>;
+ clocks = <&clks IMX6QDL_CLK_CKO2>;
+ clock-names = "xclk";
+ reg = <0x42>;
+ xclk = <24000000>;
+ reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ pwdn-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ gp-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5642_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <8>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+
+ mipi_camera: ov5640@40 {
+ compatible = "ovti,ov5640_mipi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5640>;
+ clocks = <&mipi_xclk>;
+ clock-names = "xclk";
+ reg = <0x40>;
+ xclk = <22000000>;
+ reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
+ pwdn-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5640_to_mipi_csi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&mipi_csi_from_mipi_sensor>;
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+ };
+ };
+ };
};
&i2c3 {
@@ -374,7 +444,6 @@
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
/* Phy reset */
MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x000b0
- MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
>;
};
@@ -449,6 +518,39 @@
>;
};
+ pinctrl_ov5642: ov5642grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT0__GPIO1_IO16 0x80000000
+ MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x80000000
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x80000000
+ MX6QDL_PAD_GPIO_3__CCM_CLKO2 0x80000000
+ >;
+ };
+
+ pinctrl_ipu1_csi0: ipu1grp-csi0 {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x80000000
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x80000000
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x80000000
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x80000000
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x80000000
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x80000000
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x80000000
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x80000000
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
+ MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x80000000
+ MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x80000000
+ MX6QDL_PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN 0x80000000
+ >;
+ };
+
+ pinctrl_ov5640: ov5640grp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x000b0
+ MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x0b0b0
+ >;
+ };
+
pinctrl_pwm1: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD1_DAT3__PWM1_OUT 0x1b0b1
@@ -605,3 +707,15 @@
vmmc-supply = <®_3p3v>;
status = "okay";
};
+
+&mipi_csi {
+ status = "okay";
+};
+
+/* Incoming port from sensor */
+&mipi_csi_from_mipi_sensor {
+ remote-endpoint = <&ov5640_to_mipi_csi>;
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
+
--
2.7.4
^ permalink raw reply related
* [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
From: Steve Longerbeam @ 2017-01-03 20:57 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam, robh+dt, mark.rutland, linux,
mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <1483477049-19056-1-git-send-email-steve_longerbeam@mentor.com>
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi. It is set to transmit over MIPI virtual channel 1.
Until the OV5652 sensor module compatible with the SabreSD becomes
available for testing, the ov5642 node is currently disabled.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6dl-sabresd.dts | 5 ++
arch/arm/boot/dts/imx6q-sabresd.dts | 5 ++
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 ++++++++++++++++++++++++++++++++-
3 files changed, 123 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl-sabresd.dts b/arch/arm/boot/dts/imx6dl-sabresd.dts
index 1e45f2f..6cf7a50 100644
--- a/arch/arm/boot/dts/imx6dl-sabresd.dts
+++ b/arch/arm/boot/dts/imx6dl-sabresd.dts
@@ -15,3 +15,8 @@
model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
};
+
+&ipu1_csi1_from_ipu1_csi1_mux {
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts b/arch/arm/boot/dts/imx6q-sabresd.dts
index 9cbdfe7..8c1d7ad 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -23,3 +23,8 @@
&sata {
status = "okay";
};
+
+&ipu1_csi1_from_mipi_vc1 {
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 55ef535..39b4228 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -10,6 +10,7 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include <dt-bindings/clock/imx6qdl-clock.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
@@ -146,6 +147,33 @@
};
};
+&ipu1_csi0_from_ipu1_csi0_mux {
+ bus-width = <8>;
+ data-shift = <12>; /* Lines 19:12 used */
+ hsync-active = <1>;
+ vsync-active = <1>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+ remote-endpoint = <&ov5642_to_ipu1_csi0_mux>;
+};
+
+&ipu1_csi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
+};
+
+&mipi_csi {
+ status = "okay";
+};
+
+/* Incoming port from sensor */
+&mipi_csi_from_mipi_sensor {
+ remote-endpoint = <&ov5640_to_mipi_csi>;
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+};
+
&audmux {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
@@ -214,7 +242,33 @@
0x8014 /* 4:FN_DMICCDAT */
0x0000 /* 5:Default */
>;
- };
+ };
+
+ camera: ov5642@3c {
+ compatible = "ovti,ov5642";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5642>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ clock-names = "xclk";
+ reg = <0x3c>;
+ xclk = <24000000>;
+ DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+ AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
+ rev B board is VGEN5 */
+ DVDD-supply = <&vgen2_reg>; /* 1.5v*/
+ pwdn-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; /* SD1_DAT0 */
+ reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>; /* SD1_DAT1 */
+ status = "disabled";
+
+ port {
+ ov5642_to_ipu1_csi0_mux: endpoint {
+ remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+ bus-width = <8>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
};
&i2c2 {
@@ -322,6 +376,34 @@
};
};
};
+
+ mipi_camera: ov5640@3c {
+ compatible = "ovti,ov5640_mipi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5640>;
+ reg = <0x3c>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ clock-names = "xclk";
+ xclk = <24000000>;
+ DOVDD-supply = <&vgen4_reg>; /* 1.8v */
+ AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
+ rev B board is VGEN5 */
+ DVDD-supply = <&vgen2_reg>; /* 1.5v*/
+ pwdn-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; /* SD1_DAT2 */
+ reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; /* SD1_CLK */
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ov5640_to_mipi_csi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&mipi_csi_from_mipi_sensor>;
+ data-lanes = <0 1>;
+ clock-lanes = <2>;
+ };
+ };
+ };
};
&i2c3 {
@@ -426,6 +508,36 @@
>;
};
+ pinctrl_ov5640: ov5640grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x80000000
+ MX6QDL_PAD_SD1_CLK__GPIO1_IO20 0x80000000
+ >;
+ };
+
+ pinctrl_ov5642: ov5642grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT0__GPIO1_IO16 0x80000000
+ MX6QDL_PAD_SD1_DAT1__GPIO1_IO17 0x80000000
+ >;
+ };
+
+ pinctrl_ipu1_csi0: ipu1grp-csi0 {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x80000000
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x80000000
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x80000000
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x80000000
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x80000000
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x80000000
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x80000000
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x80000000
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x80000000
+ MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x80000000
+ MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x80000000
+ >;
+ };
+
pinctrl_pcie: pciegrp {
fsl,pins = <
MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
--
2.7.4
^ permalink raw reply related
* [PATCH v2 06/19] ARM: dts: imx6-sabreauto: create i2cmux for i2c3
From: Steve Longerbeam @ 2017-01-03 20:57 UTC (permalink / raw)
To: shawnguo, kernel, fabio.estevam, robh+dt, mark.rutland, linux,
mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <1483477049-19056-1-git-send-email-steve_longerbeam@mentor.com>
The sabreauto uses a steering pin to select between the SDA signal on
i2c3 bus, and a data-in pin for an SPI NOR chip. Use i2cmux to control
this steering pin. Idle state of the i2cmux selects SPI NOR. This is not
a classic way to use i2cmux, since one side of the mux selects something
other than an i2c bus, but it works and is probably the cleanest
solution. Note that if one thread is attempting to access SPI NOR while
another thread is accessing i2c3, the SPI NOR access will fail since the
i2cmux has selected the SDA pin rather than SPI NOR data-in. This couldn't
be avoided in any case, the board is not designed to allow concurrent
i2c3 and SPI NOR functions (and the default device-tree does not enable
SPI NOR anyway).
Devices hanging off i2c3 should now be defined under i2cmux, so
that the steering pin can be properly controlled to access those
devices. The port expanders (MAX7310) are thus moved into i2cmux.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 65 +++++++++++++++++++++-----------
1 file changed, 44 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 52390ba..4a6d038 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -108,6 +108,44 @@
default-brightness-level = <7>;
status = "okay";
};
+
+ i2cmux {
+ compatible = "i2c-mux-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3mux>;
+ mux-gpios = <&gpio5 4 0>;
+ i2c-parent = <&i2c3>;
+ idle-state = <0>;
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ max7310_a: gpio@30 {
+ compatible = "maxim,max7310";
+ reg = <0x30>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ max7310_b: gpio@32 {
+ compatible = "maxim,max7310";
+ reg = <0x32>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ max7310_c: gpio@34 {
+ compatible = "maxim,max7310";
+ reg = <0x34>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
};
&clks {
@@ -291,27 +329,6 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
-
- max7310_a: gpio@30 {
- compatible = "maxim,max7310";
- reg = <0x30>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- max7310_b: gpio@32 {
- compatible = "maxim,max7310";
- reg = <0x32>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- max7310_c: gpio@34 {
- compatible = "maxim,max7310";
- reg = <0x34>;
- gpio-controller;
- #gpio-cells = <2>;
- };
};
&iomuxc {
@@ -419,6 +436,12 @@
>;
};
+ pinctrl_i2c3mux: i2c3muxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_A24__GPIO5_IO04 0x80000000
+ >;
+ };
+
pinctrl_pwm3: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox