* Re: [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
From: Javier Martinez Canillas @ 2017-01-10 19:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Catalin Marinas, Will Deacon, linux-kernel, Andi Shyti,
Chanwoo Choi, Kukjin Kim, linux-arm-kernel
In-Reply-To: <20170110185109.n3x25yxbaarzikcd@kozik-lap>
Hello Krzysztof,
On 01/10/2017 03:51 PM, Krzysztof Kozlowski wrote:
[snip]
>>
>> - usbdrd30: usb@15400000 {
>> + usbdrd30: usb-0 {
>
> How about "usbdrd" instead of "usb-0"? It would be still quite a generic
> description of a class.
>
>> compatible = "samsung,exynos5250-dwusb3";
>> clocks = <&cmu_fsys CLK_ACLK_USBDRD30>,
>> <&cmu_fsys CLK_SCLK_USBDRD30>;
>> @@ -1332,7 +1332,7 @@
>> status = "disabled";
>> };
>>
>> - usbhost30: usb@15a00000 {
>> + usbhost30: usb-1 {
>
> usbhost?
>
Indeed, these sounds better so I'll change for them.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v3 1/3] arm64: dts: exynos5433: add DECON_TV node
From: Krzysztof Kozlowski @ 2017-01-10 19:09 UTC (permalink / raw)
To: Andrzej Hajda
Cc: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andi Shyti, Chanwoo Choi
In-Reply-To: <1484036664-15951-1-git-send-email-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Tue, Jan 10, 2017 at 09:24:22AM +0100, Andrzej Hajda wrote:
> DECON_TV is 2nd display controller on Exynos5433, used in HDMI path
> or 2nd DSI path.
>
> Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> Reviewed-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Tested-by: Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
>
> Hi Krzysztof,
>
> These patches are based on latest patches separating tm2 and tm2e and
> touchscreen patches. I hope this is good base.
> Thanks all for quick response/review.
>
> Regards
> Andrzej
>
> v2:
> - replaced magic numbers with macros,
> - removed power domains,
> - removed 0x prefixes from node names
>
> v3:
> - order nodes by address
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 43 ++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
First, I applied your fix for unit addresses. Then I wanted to apply
these... no, it does not apply.
Okay, so maybe unit address confuses git-am (it is not that smart as
cherry-pick etc) - let's try the other way. I applied these three
patches, fixed that damned subject in each commit and I wanted to apply
the fix for unit address. Nope. It won't apply.
I do not know how you rebased your work.
As of now, the fix is applied. Please fix the subject and rebase.
Best regards,
Krzysztof
--
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: Re: [PATCH 3/6] clk: sunxi-ng: Add H5 clocks
From: Maxime Ripard @ 2017-01-10 19:10 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Andre Przywara, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170109161500.Ep9GCmIb-8ttnI0T0xQU0PDqKvflMoHmW9unr2Ajn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]
On Mon, Jan 09, 2017 at 09:13:12PM +0800, Icenowy Zheng wrote:
>
> 2017年1月9日 下午7:01于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Fri, Jan 06, 2017 at 06:48:31AM +0800, Icenowy Zheng wrote:
> > >
> > > 2017年1月6日 06:04于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> > > >
> > > > On Tue, Dec 27, 2016 at 12:25:15AM +0800, Icenowy Zheng wrote:
> > > > > Add the H5 CCU clocks set based on the H3 one.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> > > >
> > > > Is there any difference with H3's?
> > >
> > > One more Transport Stream controller, so one more bus gate and bus
> > > reset for it.
> >
> > There's no need to duplicate more than 1000 lines of code just for
> > that then. Just add a new compatible and reuse the clocks already
> > defined.
>
> How can I do this? Add them in ccu-sun8i-h3.c ?
Yes, you can have a look at how I did it for sun5i for example if you
want.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:10 UTC (permalink / raw)
To: Andy Shevchenko, Vladimir Zapolskiy
Cc: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio@vger.kernel.org, devicetree,
linux-kernel@vger.kernel.org, Steve Longerbeam
In-Reply-To: <CAHp75Vey4R8o+7h3DuBJ9FiciGSHfvRWjs_0d3ZWeTm+cB4WrA@mail.gmail.com>
On 01/04/2017 02:31 AM, Andy Shevchenko wrote:
>
>>>> + reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
>>>> + GPIOD_OUT_LOW);
>>> Shouldn't be _optional_exclusive?
>>> See this recent discussion https://patchwork.ozlabs.org/patch/706002/
>> There is no devm_gpiod_get_optional_exclusive(), probably you confuse
>> the function with devm_reset_control_get_optional_exclusive().
> Perhaps it's time to add
> drivers/reset/reset-gpio.c ?
Yeah, looks like a GPIO based reset controller driver would need to be
implemented in order to go this route. The max7310 nodes in
imx6qdl-sabreauto.dtsi could then refer to that reset controller by the
'resets' phandle.
There are many many devices that would benefit from a GPIO reset
controller, I count 143 nodes under arch/arm/boot/dts that specify a
'reset-gpios' property.
But I don't have the time to write such a driver. So I would propose just
keeping the devm_gpiod_get_optional() call here. When such a gpio reset
controller is written, the work can begin to convert all the gpio reset
users
to make use of it.
Steve
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:13 UTC (permalink / raw)
To: Vladimir Zapolskiy, linus.walleij, gnurou, robh+dt, mark.rutland
Cc: linux-gpio, devicetree, linux-kernel, Steve Longerbeam
In-Reply-To: <e043cb00-9b8e-edec-0949-b23fbed6e2c5@mentor.com>
On 01/04/2017 02:25 AM, Vladimir Zapolskiy wrote:
> Hi Steve,
>
> On 01/02/2017 11:07 PM, Steve Longerbeam wrote:
>> Add optional reset-gpios pin control. If present, de-assert the
>> specified reset gpio pin to bring the chip out of reset.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Alexandre Courbot <gnurou@gmail.com>
>> Cc: linux-gpio@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
>> drivers/gpio/gpio-pca953x.c | 11 +++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> index 08dd15f..da54f4c 100644
>> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> @@ -29,6 +29,10 @@ Required properties:
>> onsemi,pca9654
>> exar,xra1202
>>
>> +Optional properties:
>> + - reset-gpios: GPIO specification for the RESET input
>> +
>> +
> Drop the surplus empty line above.
done.
>
>> Example:
>>
>>
>> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
>> index d5d72d8..ca2ddea 100644
>> --- a/drivers/gpio/gpio-pca953x.c
>> +++ b/drivers/gpio/gpio-pca953x.c
>> @@ -22,6 +22,7 @@
>> #include <linux/of_platform.h>
>> #include <linux/acpi.h>
>> #include <linux/regulator/consumer.h>
>> +#include <linux/gpio/consumer.h>
>>
>> #define PCA953X_INPUT 0
>> #define PCA953X_OUTPUT 1
>> @@ -754,8 +755,18 @@ static int pca953x_probe(struct i2c_client *client,
>> invert = pdata->invert;
>> chip->names = pdata->names;
>> } else {
>> + struct gpio_desc *reset_gpio;
>> +
>> chip->gpio_start = -1;
>> irq_base = 0;
>> +
>> + /* see if we need to de-assert a reset pin */
>> + reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
>> + GPIOD_OUT_LOW);
>> + if (IS_ERR(reset_gpio)) {
>> + dev_err(&client->dev, "request for reset pin failed\n");
> I'm not confident that the error message is wanted here, you may consider either
> to remove it or at least print it out if (PTR_ERR(reset_gpio) != -EPROBE_DEFER).
no problem, I just removed it.
Steve
^ permalink raw reply
* Re: [PATCH v2 6/6] arm64: allwinner: a64: Increase the MMC max frequency
From: Maxime Ripard @ 2017-01-10 19:15 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree, Ulf Hansson, Andre Przywara,
linux-mmc@vger.kernel.org, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <CAGb2v67JoOAtHjMJboNUdCDX=+=Hf+zOWr234rT7GEiUmPb=nQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1707 bytes --]
Hi,
On Tue, Jan 10, 2017 at 01:01:20AM +0800, Chen-Yu Tsai wrote:
> On Tue, Jan 10, 2017 at 12:46 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > All the controllers can have a maximum frequency of 200MHz.
> >
> > Since older SoCs cannot go that high, we cannot change the default maximum
> > frequency, but fortunately for us we have a property for that in the DT.
> >
> > This also has the side effect of allowing to use the MMC HS200 mode for the
> > boards that support it (with either 1.2v or 1.8v IOs).
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++
> > 1 file changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 8e149498e096..f46ae965cf5b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -332,6 +332,7 @@
> > resets = <&ccu RST_BUS_MMC0>;
> > reset-names = "ahb";
> > interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> > + max-frequency = <200000000>;
>
> You also have to set one of MMC_CAP2_HS200* in the driver,
> or mmc-hs200-1_8v or mmc-hs200-1_2v in the device tree to
> actually use HS200, right?
Yes, but that requires a board with 1.8V IOs to work properly, which
not all board use, so it's probably best to enable it in the board
DTS.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Tony Lindgren @ 2017-01-10 19:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170110153045.GS2630@atomide.com>
* Tony Lindgren <tony@atomide.com> [170110 07:32]:
> * Geert Uytterhoeven <geert@linux-m68k.org> [170110 06:09]:
> > Hi Tony,
> >
> > On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > Having the pin control framework call pin controller functions
> > > before it's probe has finished is not nice as the pin controller
> > > device driver does not yet have struct pinctrl_dev handle.
> > >
> > > Let's fix this issue by adding deferred work for late init. This is
> > > needed to be able to add pinctrl generic helper functions that expect
> > > to know struct pinctrl_dev handle. Note that we now need to call
> > > create_pinctrl() directly as we don't want to add the pin controller
> > > to the list of controllers until the hogs are claimed. We also need
> > > to pass the pinctrl_dev to the device tree parser functions as they
> > > otherwise won't find the right controller at this point.
> > >
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > I believe this patch causes a regression on r8a7740/armadillo, where the
> > pin controller is also a GPIO controller, and lcd0 needs a hog
> > (cfr. arch/arm/boot/dts/r8a7740-armadillo800eva.dts):
> >
> > -GPIO line 176 (lcd0) hogged as output/high
> > -sh-pfc e6050000.pfc: r8a7740_pfc handling gpio 0 -> 211
> > +gpiochip_add_data: GPIOs 0..211 (r8a7740_pfc) failed to register
> > +sh-pfc e6050000.pfc: failed to init GPIO chip, ignoring...
> > sh-pfc e6050000.pfc: r8a7740_pfc support registered
> >
> > Hence all drivers using GPIOs fail to initialize because their GPIOs never
> > become available.
> >
> > Adding debug prints to the failure paths shows that the call to
> > of_pinctrl_get() in of_gpiochip_add_pin_range() fails with -EPROBE_DEFER.
> > Adding a debug print to the top of gpiochip_add_data() makes the problem go
> > away, presumably because it introduces a delay that allows the delayed work
> > to kick in...
>
> OK. What if we added also an optional pinctrl function that the pin
> controller driver could call to initialize hogs? Then the pin controller
> driver could call it during or after probe as needed. That is after
> there's a valid struct pinctrl_dev handle.
...
> We could also pass some flag if should always call pinctrl_late_init()
> directly. But that does not remove the problem of struct pinctrl_dev handle
> being uninitialized when the pin controller driver functionas are called.
Looks like we need both a flag and a way for the pin controller driver
to start things.
Below is an experimental fix to intorduce pinctrl_start() that I've
tested with pinctrl-single. Then we should probably make all pin controller
drivers call pinctrl_start() to properly fix the issue of struct pinctrl_dev
handle not being initialized before driver functions are called.
Or do you guys have any better ideas?
Regards,
Tony
8< --------------------------------
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1962,6 +1962,17 @@ static void pinctrl_late_init(struct work_struct *work)
pinctrl_init_device_debugfs(pctldev);
}
+int pinctrl_start(struct pinctrl_dev *pctldev)
+{
+ if (!IS_ERR(pctldev->p))
+ return -EEXIST;
+
+ pinctrl_late_init(&pctldev->late_init.work);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pinctrl_start);
+
/**
* pinctrl_register() - register a pin controller device
* @pctldesc: descriptor for this pin controller
@@ -2035,9 +2046,14 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
/*
* If the device has hogs we want the probe() function of the driver
* to complete before we go in and hog them and add the pin controller
- * to the list of controllers. If it has no hogs, we can just complete
- * the registration immediately.
+ * to the list of controllers. If the pin controller driver initializes
+ * hogs, or the pin controller instance has no hogs, we can just
+ * complete the registration immediately.
*/
+
+ if (pctldesc->flags & PINCTRL_DRIVER_START)
+ return pctldev;
+
if (pinctrl_dt_has_hogs(pctldev))
schedule_delayed_work(&pctldev->late_init, 0);
else
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1741,6 +1741,7 @@ static int pcs_probe(struct platform_device *pdev)
pcs->desc.pmxops = &pcs_pinmux_ops;
if (PCS_HAS_PINCONF)
pcs->desc.confops = &pcs_pinconf_ops;
+ pcs->desc.flags = PINCTRL_DRIVER_START;
pcs->desc.owner = THIS_MODULE;
ret = pcs_allocate_pin_table(pcs);
@@ -1754,6 +1755,10 @@ static int pcs_probe(struct platform_device *pdev)
goto free;
}
+ ret = pinctrl_start(pcs->pctl);
+ if (ret)
+ goto free;
+
ret = pcs_add_gpio_func(np, pcs);
if (ret < 0)
goto free;
diff --git a/drivers/pinctrl/sh-pfc/pinctrl.c b/drivers/pinctrl/sh-pfc/pinctrl.c
--- a/drivers/pinctrl/sh-pfc/pinctrl.c
+++ b/drivers/pinctrl/sh-pfc/pinctrl.c
@@ -815,7 +815,15 @@ int sh_pfc_register_pinctrl(struct sh_pfc *pfc)
pmx->pctl_desc.confops = &sh_pfc_pinconf_ops;
pmx->pctl_desc.pins = pmx->pins;
pmx->pctl_desc.npins = pfc->info->nr_pins;
+ pmx->pctl_desc.flags = PINCTRL_DRIVER_START;
pmx->pctl = devm_pinctrl_register(pfc->dev, &pmx->pctl_desc, pmx);
- return PTR_ERR_OR_ZERO(pmx->pctl);
+ if (IS_ERR(pmx->pctl))
+ return PTR_ERR(pmx->pctl);
+
+ ret = pinctrl_start(pmx->pctl);
+ if (ret)
+ return ret;
+
+ return 0;
}
diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h
--- a/include/linux/pinctrl/pinctrl.h
+++ b/include/linux/pinctrl/pinctrl.h
@@ -104,6 +104,8 @@ struct pinctrl_ops {
struct pinctrl_map *map, unsigned num_maps);
};
+#define PINCTRL_DRIVER_START BIT(0)
+
/**
* struct pinctrl_desc - pin controller descriptor, register this to pin
* control subsystem
@@ -112,6 +114,8 @@ struct pinctrl_ops {
* this pin controller
* @npins: number of descriptors in the array, usually just ARRAY_SIZE()
* of the pins field above
+ * @flags: Optional pin controller feature flags
+ * handling is needed in the pin controller driver.
* @pctlops: pin control operation vtable, to support global concepts like
* grouping of pins, this is optional.
* @pmxops: pinmux operations vtable, if you support pinmuxing in your driver
@@ -129,6 +133,7 @@ struct pinctrl_desc {
const char *name;
const struct pinctrl_pin_desc *pins;
unsigned int npins;
+ unsigned int flags;
const struct pinctrl_ops *pctlops;
const struct pinmux_ops *pmxops;
const struct pinconf_ops *confops;
@@ -149,6 +154,7 @@ extern struct pinctrl_dev *devm_pinctrl_register(struct device *dev,
void *driver_data);
extern void devm_pinctrl_unregister(struct device *dev,
struct pinctrl_dev *pctldev);
+extern int pinctrl_start(struct pinctrl_dev *pctldev);
extern bool pin_is_valid(struct pinctrl_dev *pctldev, int pin);
extern void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
--
2.11.0
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Rob Clark @ 2017-01-10 19:20 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm,
Jordan Crouse,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
In-Reply-To: <20170110175219.GK527-5wv7dgnIgG8@public.gmane.org>
On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi Rob,
>
> On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote:
>> On Thu, Jan 5, 2017 at 10:49 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
>> > On Thu, Jan 05, 2017 at 10:27:27AM -0500, Rob Clark wrote:
>> >> I'm not sure if the better solution then would be to have two fault
>> >> callbacks, one immediately from the IRQ and a later one from wq. Or
>> >> let the driver handle the wq business and give it a way to tell the
>> >> IOMMU when to resume.
>> >>
>> >> I kinda think we should punt on the worker thread for now until we are
>> >> ready to resume faulting transactions, because I guess a strong chance
>> >> that whatever way we do it now will be wrong ;-)
>> >
>> > I guess what I'm after is for you to change the interrupt handlers to be
>> > threaded, like they are for SMMUv3. I *think* you can do that with a NULL
>> > thread_fn for now, and just call report_iommu_fault from the handler.
>> > The return value of that could, in theory, be used to queued the paging
>> > request and wake the paging thread in future.
>>
>> If we only pass in the non-threaded irq fxn, I'm not really sure how
>> that changes anything.. or maybe I'm not understanding what you mean.
>>
>> But yeah, I guess we could use request_threaded_irq() to get both IRQ
>> context notification and a later thread context notification rather
>> than doing the wq thing. Either way the iommu API has to change
>> slightly.
>>
>> >> > I wonder if this should also be predicated on the compatible string, so
>> >> > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
>> >> > the compatible string isn't specific enough to identify an implementation
>> >> > with the required SS behaviour? On the other hand, it feels pretty
>> >> > redundant and a single "stalling works" property is all we need.
>> >>
>> >> We could also drop the property and key the behavior on specific
>> >> compat strings I guess. Having both seems a bit odd. Anyways, I'll
>> >> defer to DT folks about what the cleaner approach is.
>> >
>> > As Robin pointed out, we do need to be able to distinguish the integration
>> > of the device from the device itself. For example, MMU-9000 might be capable
>> > of stalling, but if it's bolted to a PCI RC, it's not safe to do so.
>>
>> Hmm, well we install the fault handler on the iommu_domain.. perhaps
>> maybe a combo of dts property (or deciding based on more specific
>> compat string), plus extra param passed in to
>> iommu_set_fault_hander(). The dts property or compat string to
>> indicate whether the iommu (and how it is wired up) can handle stalls,
>> and enable_stall param when fault handler is registered to indicate
>> whether the device itself can cope.. if either can't do stalling, then
>> don't set CFCFG.
>
> I thought about this some more, and I think you're right. Having
> iommu_set_fault_handler take a flags parameter indicating that, for example,
> the fault handler can deal with paging, is all we need to implement the
> per-master opt-in functionality for stalling faults. There's no real
> requirement to standardise a generic firmware property for that (but
> we still need *something* that says stalling is usable on the SMMU --
> perhaps just the compatible string is ok).
btw, it occurred to me that maybe it should be flags param to
iommu_attach_device() (just in case fault handler not installed?)
otoh stalling without a fault handler is silly, but I guess we need it
to infer whether stalling can be supported by other devices on same
iommu.. tbh I'm on a bit shaky ground when it comes to multiple
devices per iommu since the SoC's I'm familiar with do it the other
way around. But I guess you have thought more about the multi-device
case, so figured I should suggest it..
> Taking this further, there's then no need for the threaded IRQ function
> in the SMMUv2 driver after all. Instead, we pass a continuation function
> pointer and opaque token from the SMMU driver to the fault handler in
> IRQ context (this will be in thread context for SMMUv3, but that should
> be fine). The fault handler can then stash these someplace, and signal
> a wakeup for its own threaded handler, which ultimately calls the SMMU
> continuation function with the opaque token as a parameter when it's done
> with the fault. I think that's enough to get things rolling without adding
> lots of infrastructure to the SMMU driver initially. If a pattern emerges
> amongst users of the interface, then we could consolidate some of the work
> handling back into IOMMU core.
>
> What do you think? It should all be pretty straightforward for what you
> want to do.
yeah, that makes sense to me.. I can give it a try.
BR,
-R
> Will
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:21 UTC (permalink / raw)
To: Rob Herring
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Steve Longerbeam
In-Reply-To: <20170104132231.jlhqwngaeza7duoo@rob-hp-laptop>
On 01/04/2017 05:22 AM, Rob Herring wrote:
> On Mon, Jan 02, 2017 at 01:07:51PM -0800, Steve Longerbeam wrote:
>> Add optional reset-gpios pin control. If present, de-assert the
>> specified reset gpio pin to bring the chip out of reset.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
>> drivers/gpio/gpio-pca953x.c | 11 +++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> index 08dd15f..da54f4c 100644
>> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> @@ -29,6 +29,10 @@ Required properties:
>> onsemi,pca9654
>> exar,xra1202
>>
>> +Optional properties:
>> + - reset-gpios: GPIO specification for the RESET input
> Need to specify active high or low.
done (it's an active low signal).
Steve
--
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] pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:29 UTC (permalink / raw)
To: linus.walleij, gnurou, robh+dt, mark.rutland
Cc: linux-gpio, devicetree, linux-kernel, Steve Longerbeam
In version 2:
- Specify that reset signal to PCA953x chip is active low, in
binding doc.
- reorder includes in gpio-pca953x.c.
- remove dev_err() on devm_gpiod_get_optional() error return.
Steve Longerbeam (1):
gpio: pca953x: Add optional reset gpio control
Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
drivers/gpio/gpio-pca953x.c | 9 +++++++++
2 files changed, 13 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v2] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:29 UTC (permalink / raw)
To: linus.walleij, gnurou, robh+dt, mark.rutland
Cc: linux-gpio, devicetree, linux-kernel, Steve Longerbeam
In-Reply-To: <1484076591-20834-1-git-send-email-steve_longerbeam@mentor.com>
Add optional reset-gpios pin control. If present, de-assert the
specified reset gpio pin to bring the chip out of reset.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
--
v2:
- Specify that reset signal to PCA953x chip is active low, in
binding doc.
- reorder includes in gpio-pca953x.c.
- remove dev_err() on devm_gpiod_get_optional() error return.
---
Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
drivers/gpio/gpio-pca953x.c | 9 +++++++++
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
index 08dd15f..e639357 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
@@ -29,6 +29,10 @@ Required properties:
onsemi,pca9654
exar,xra1202
+Optional properties:
+ - reset-gpios: GPIO specification for the RESET input. This is an
+ active low signal to the PCA953x.
+
Example:
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index d5d72d8..d44232a 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -14,6 +14,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/interrupt.h>
#include <linux/i2c.h>
#include <linux/platform_data/pca953x.h>
@@ -754,8 +755,16 @@ static int pca953x_probe(struct i2c_client *client,
invert = pdata->invert;
chip->names = pdata->names;
} else {
+ struct gpio_desc *reset_gpio;
+
chip->gpio_start = -1;
irq_base = 0;
+
+ /* See if we need to de-assert a reset pin */
+ reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(reset_gpio))
+ return PTR_ERR(reset_gpio);
}
chip->client = client;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Heiko Stübner @ 2017-01-10 19:46 UTC (permalink / raw)
To: Doug Anderson
Cc: Mark Rutland, devicetree@vger.kernel.org, Elaine Zhang,
Xing Zheng, Catalin Marinas, Shawn Lin, Brian Norris, Will Deacon,
linux-kernel@vger.kernel.org, open list:ARM/Rockchip SoC...,
Rob Herring, David Wu, Jianqun Xu,
linux-arm-kernel@lists.infradead.org, Caesar Wang
In-Reply-To: <CAD=FV=Wwu3q_LqwYUWcJQRvp5neVOS9szgsYFONWTRJ0X8hRTA@mail.gmail.com>
Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> Hi,
>
> On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com>
wrote:
> > The structure rockchip_clk_provider needs to refer the GRF regmap
> > in somewhere, if the CRU node has not "rockchip,grf" property,
> > calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> > regmap, and the MUXGRF type clock will be not supported.
> >
> > Therefore, we need to add them.
> >
> > Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> > ---
> >
> > Changes in v4:
> > - separte the binding patch
> >
> > Changes in v3:
> > - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
> >
> > Changes in v2:
> > - referring pmugrf for PMUGRU
> > - fix the typo "invaild" in COMMIT message
> >
> > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> > 1 file changed, 2 insertions(+)
>
> This seems fine to me, so:
>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
>
> ...but I will say that before you actually add any real "MUXGRF"
> clocks on rk3399 you _might_ need to rework the code to make things
> truly "optional". If it turns out that any existing clocks that
> already exist today already go through one of these muxes in the GRF
> and we've always been assuming one setting of the mux, we'll need to
> make sure we keep assuming that setting of the mux even if the "grf"
> isn't specified.
I guess I see that a bit more relaxed :-) .
I.e. the GRF being optional is a remnant of syscons not being available when
the clocks get set up- so were coming in later or not at all. For the rk3288 I
converted, there we never really had the case of the GRF missing.
And the GRF mux for the vcodec now present is not being used by anything yet
(neither driver nor binding), so no old devicetree can break.
> As I understand it, your motivation for this patch is to eventually be
> able to model the EDP reference clock which can either be xin24 or
> "edp osc". Presumably the eDP "reference clock" isn't related to any
> of the pre-existing eDP clocks so that one should be safe.
Same here, so far we don't even have edp or even any other graphical output on
the rk3399, so again there is no old devicetree that could break when the grf
is not specified.
So, for me that looks good.
Heiko
^ permalink raw reply
* Re: [PATCH] of: alloc anywhere from memblock if range not specified
From: Laura Abbott @ 2017-01-10 19:49 UTC (permalink / raw)
To: Leonard Crestez, Vinayak Menon
Cc: devicetree, linux-kernel, robh+dt, vinayakm.list,
Octavian Purdila, frowand.list, linux-arm-kernel, m.szyprowski
In-Reply-To: <717b117d-9b8b-d4e9-6135-3c52afd635c8@gmail.com>
On 01/10/2017 08:16 AM, Leonard Crestez wrote:
> Hello,
>
> I have some trouble with this patch.
>
> It seems the intention is to allow CMA to be placed in highmem. If the CMA area is
> larger than highmem and no alloc-ranges is specified (just a size) it is possible
> to end up allocating a area that spans from multiple zones. This later breaks
> checks in cma_activate_area and makes most dma allocations fail.
>
> Am I missing something or this a bug?
>
This has been discussed in previous threads
https://marc.info/?l=linux-kernel&m=147990760506179&w=2
https://marc.info/?l=linux-kernel&m=147928325113103&w=2
I haven't seen any follow up since then though.
> On Mon, Feb 22, 2016 at 3:45 PM, Vinayak Menon <vinmenon@codeaurora.org> wrote:
>>
>> early_init_dt_alloc_reserved_memory_arch passes end as 0 to
>> __memblock_alloc_base, when limits are not specified. But
>> __memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE
>> and limits the end to memblock.current_limit. This results in regions
>> never being placed in HIGHMEM area, for e.g. CMA.
>> Let __memblock_alloc_base allocate from anywhere in memory if limits are
>> not specified.
>>
>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
>> ---
>> drivers/of/of_reserved_mem.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>> index 1a3556a..ed01c01 100644
>> --- a/drivers/of/of_reserved_mem.c
>> +++ b/drivers/of/of_reserved_mem.c
>> @@ -32,11 +32,13 @@ int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
>> phys_addr_t align, phys_addr_t start, phys_addr_t end, bool nomap,
>> phys_addr_t *res_base)
>> {
>> + phys_addr_t base;
>> /*
>> * We use __memblock_alloc_base() because memblock_alloc_base()
>> * panic()s on allocation failure.
>> */
>> - phys_addr_t base = __memblock_alloc_base(size, align, end);
>> + end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
>> + base = __memblock_alloc_base(size, align, end);
>> if (!base)
>> return -ENOMEM;
>>
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>> member of the Code Aurora Forum, hosted by The Linux Foundation
>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/9] dt/bindings: Add a serial/UART attached device binding
From: One Thousand Gnomes @ 2017-01-10 19:50 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Marcel Holtmann, Jiri Slaby,
Sebastian Reichel, Arnd Bergmann, Dr . H . Nikolaus Schaller,
Peter Hurley, Andy Shevchenko, Loic Poulain, Pavel Machek,
NeilBrown, Linus Walleij, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170106162635.19677-7-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Fri, 6 Jan 2017 10:26:32 -0600
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Add a common binding for describing serial/UART attached devices. Common
> examples are Bluetooth, WiFi, NFC and GPS devices.
>
> Serial attached devices are represented as child nodes of a UART node.
> This may need to be extended for more complex devices with multiple
> interfaces, but for the simple cases a child node is sufficient.
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/serial/slave-device.txt | 34 ++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/slave-device.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/slave-device.txt b/Documentation/devicetree/bindings/serial/slave-device.txt
> new file mode 100644
> index 000000000000..9b7c2d651345
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/slave-device.txt
> @@ -0,0 +1,34 @@
> +Serial Slave Device DT binding
> +
> +This documents the binding structure and common properties for serial
> +attached devices. Common examples include Bluetooth, WiFi, NFC and GPS
> +devices.
> +
> +qSerial
Stray 'q' ??
^ permalink raw reply
* Re: [PATCH] iio: accel: st_accel: handle deprecated bindings
From: Jonathan Cameron @ 2017-01-10 19:55 UTC (permalink / raw)
To: Rob Herring, Linus Walleij
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170109181645.lntlvawt26vsp4l2@rob-hp-laptop>
On 09/01/17 18:16, Rob Herring wrote:
> On Thu, Jan 05, 2017 at 02:32:33PM +0100, Linus Walleij wrote:
>> The earlier deployed LIS3LV02DL driver had already defined a few
>> DT bindings that need to be supported by the new more generic
>> driver and listed as compatible but deprecated bindings in the
>> documentation.
>>
>> After this we can start to activate the new driver with the old
>> systems where applicable.
>>
>> As part of this enablement: make us depend on the old drivers
>> not being in use so we don't get a kernel with two competing
>> drivers.
>>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/iio/accel/lis302.txt | 2 +-
>> Documentation/devicetree/bindings/iio/st-sensors.txt | 2 ++
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Added as I haven't pushed this out as a non rebasing branch yet.
Thanks,
Jonathan
>
>> drivers/iio/accel/Kconfig | 2 ++
>> drivers/iio/accel/st_accel_i2c.c | 5 +++++
>> drivers/iio/accel/st_accel_spi.c | 9 +++++++++
>> 5 files changed, 19 insertions(+), 1 deletion(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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/3] arm64: dts: exynos: Add missing unit name to Exynos7 SoC node
From: Javier Martinez Canillas @ 2017-01-10 19:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Catalin Marinas, Will Deacon, linux-kernel, Andi Shyti,
Chanwoo Choi, Kukjin Kim, linux-arm-kernel
In-Reply-To: <20170110184728.2nff4r634ics4wb3@kozik-lap>
Hello Krzysztof,
On 01/10/2017 03:47 PM, Krzysztof Kozlowski wrote:
> On Tue, Jan 10, 2017 at 02:38:30PM -0300, Javier Martinez Canillas wrote:
>> This patch fixes the following DTC warning about a mismatch
>> between a device node reg property and its unit name:
>>
>> Node /soc has a reg or ranges property, but no unit name
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
>>
>> arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> index 80aa60e38237..0d2fedc6ac2f 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> @@ -69,7 +69,7 @@
>> method = "smc";
>> };
>>
>> - soc: soc {
>> + soc: soc@0 {
>
> This looks unnatural, like a fix just to silence the DTC. Mostly de do
> not enumerate soc node, although there are few exceptions.
>
Yes, but OTOH arm32 Exynos SoCs just have an empty "ranges" property in their
soc device node (parent and child address space is the same, no translation)
so DTC doesn't complain about the unit address in those.
But others SoCs DTSI with a non-empty ranges property have an unit name in
their soc nodes, i.e for arm64 and arm32:
arch/arm64/boot/dts/marvell/berlin4ct.dtsi
arch/arm/boot/dts/da850.dtsi
> I would prefer ignore the warning... however I am happy to hear other opinions.
>
If is wrong/unnatural to have addresses for soc nodes then I think DTC should
be patched to ignore these (like it will be the case for the OPP nodes AFAIU).
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Heiko Stübner @ 2017-01-10 19:58 UTC (permalink / raw)
To: Doug Anderson
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Elaine Zhang, Xing Zheng, Catalin Marinas, Shawn Lin,
Brian Norris, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Rob Herring, David Wu, Jianqun Xu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Caesar Wang
In-Reply-To: <8683375.pL9J7LxuT0@diego>
Hi Doug,
Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko Stübner:
> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> > Hi,
> >
> > On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> wrote:
> > > The structure rockchip_clk_provider needs to refer the GRF regmap
> > > in somewhere, if the CRU node has not "rockchip,grf" property,
> > > calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> > > regmap, and the MUXGRF type clock will be not supported.
> > >
> > > Therefore, we need to add them.
> > >
> > > Signed-off-by: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > > ---
> > >
> > > Changes in v4:
> > > - separte the binding patch
> > >
> > > Changes in v3:
> > > - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
> > >
> > > Changes in v2:
> > > - referring pmugrf for PMUGRU
> > > - fix the typo "invaild" in COMMIT message
> > >
> > > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > This seems fine to me, so:
> >
> > Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >
> > ...but I will say that before you actually add any real "MUXGRF"
> > clocks on rk3399 you _might_ need to rework the code to make things
> > truly "optional". If it turns out that any existing clocks that
> > already exist today already go through one of these muxes in the GRF
> > and we've always been assuming one setting of the mux, we'll need to
> > make sure we keep assuming that setting of the mux even if the "grf"
> > isn't specified.
>
> I guess I see that a bit more relaxed :-) .
>
> I.e. the GRF being optional is a remnant of syscons not being available when
> the clocks get set up- so were coming in later or not at all. For the
> rk3288 I converted, there we never really had the case of the GRF missing.
>
> And the GRF mux for the vcodec now present is not being used by anything yet
> (neither driver nor binding), so no old devicetree can break.
>
> > As I understand it, your motivation for this patch is to eventually be
> > able to model the EDP reference clock which can either be xin24 or
> > "edp osc". Presumably the eDP "reference clock" isn't related to any
> > of the pre-existing eDP clocks so that one should be safe.
>
> Same here, so far we don't even have edp or even any other graphical output
> on the rk3399, so again there is no old devicetree that could break when
> the grf is not specified.
reading all of the above again, it feels like you essentially also said
similar things already in your original reply and I misread some of it.
But again, I don't see the need for any more code right now, as hopefully the
simple stuff we currently only support does not have any grf-based muxes in
it. Xing + Rockchip people, please correct me if I'm wrong here :-)
Heiko
^ permalink raw reply
* Re: [PATCH v2] gpio: pca953x: Add optional reset gpio control
From: Andy Shevchenko @ 2017-01-10 20:01 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio@vger.kernel.org, devicetree,
linux-kernel@vger.kernel.org, Steve Longerbeam
In-Reply-To: <1484076591-20834-2-git-send-email-steve_longerbeam@mentor.com>
On Tue, Jan 10, 2017 at 9:29 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> --
>
> v2:
> - Specify that reset signal to PCA953x chip is active low, in
> binding doc.
> - reorder includes in gpio-pca953x.c.
> - remove dev_err() on devm_gpiod_get_optional() error return.
This should go after delimiter.
FWIW:
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> ---
> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
> drivers/gpio/gpio-pca953x.c | 9 +++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> index 08dd15f..e639357 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> @@ -29,6 +29,10 @@ Required properties:
> onsemi,pca9654
> exar,xra1202
>
> +Optional properties:
> + - reset-gpios: GPIO specification for the RESET input. This is an
> + active low signal to the PCA953x.
> +
> Example:
>
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index d5d72d8..d44232a 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -14,6 +14,7 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/interrupt.h>
> #include <linux/i2c.h>
> #include <linux/platform_data/pca953x.h>
> @@ -754,8 +755,16 @@ static int pca953x_probe(struct i2c_client *client,
> invert = pdata->invert;
> chip->names = pdata->names;
> } else {
> + struct gpio_desc *reset_gpio;
> +
> chip->gpio_start = -1;
> irq_base = 0;
> +
> + /* See if we need to de-assert a reset pin */
> + reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(reset_gpio))
> + return PTR_ERR(reset_gpio);
> }
>
> chip->client = client;
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Bin Liu @ 2017-01-10 20:24 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, linux-usb, linux-kernel, Kishon Vijay Abraham I,
Chen-Yu Tsai, Maxime Ripard, linux-arm-kernel
In-Reply-To: <20170103152534.20118-5-icenowy@aosc.xyz>
On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> Lichee Pi Zero features a USB OTG port.
>
> Add support for it.
>
> Note: in order to use the Host mode, the board must be powered via the
> +5V and GND pins.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> index 0099affc6ce3..3d9168cbaeca 100644
> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> @@ -71,3 +71,13 @@
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +&usb_otg {
> + dr_mode = "otg";
Why not set this default mode in dtsi instead?
Regards,
-Bin.
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Laurent Pinchart @ 2017-01-10 21:04 UTC (permalink / raw)
To: dri-devel
Cc: Peter Senna Tschudin, Rob Herring, Mark Rutland, Daniel Vetter,
Peter Senna Tschudin, Takashi Iwai, Yakir Yang, Jiri Slaby,
Martyn Welch, Ian Campbell, Russell King, Peter Senna Tschudin,
Javier Martinez Canillas, Thierry Reding, Guenter Roeck,
martin.donnelly, devicetree@vger.kernel.org, Pawel Moll,
Mauro Carvalho Chehab
In-Reply-To: <74f0-58704480-5-27259840@173563636>
Hi Peter,
On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> > On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> >> On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
> >>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> >>>> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> >>>> display bridge.
> >>>>
> >>>> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> >>>> Cc: Martin Donnelly <martin.donnelly@ge.com>
> >>>> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> >>>> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> >>>> Cc: Rob Herring <robh@kernel.org>
> >>>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> >>>> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> >>>> ---
> >>>> There was an Acked-by from Rob Herring <robh@kernel.org> for V6, but
> >>>> I changed the bindings to use i2c_new_secondary_device() so I
> >>>> removed it from the commit message.
> >>>>
> >>>> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++++++++++++++
> >>> Generally, bindings are not organized by vendor. Put in
> >>> bindings/display/bridge/... instead.
> >>
> >> Will change that.
> >>
> >>>> 1 file changed, 39 insertions(+)
> >>>> create mode 100644
> >>>> Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >>>> b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt new file
> >>>> mode 100644
> >>>> index 0000000..1bc6ebf
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >>>> @@ -0,0 +1,39 @@
> >>>> +Driver for GE B850v3 LVDS/DP++ display bridge
> >>>> +
> >>>> +Required properties:
> >>>> + - compatible : should be "ge,b850v3-lvds-dp".
> >>>
> >>> Isn't '-lvds-dp' redundant? The part# should be enough.
> >>
> >> b850v3 is the name of the product, this is why the proposed name. What
> >> about, b850v3-dp2 dp2 indicating the second DP output?
> >
> > Humm, b850v3 is the board name? This node should be the name of the bridge
> > chip.
>
> From the cover letter:
>
> -- // --
> There are two physical bridges on the video signal pipeline: a STDP4028(LVDS
> to DP) and a STDP2690(DP to DP++). The hardware and firmware made it
> complicated for this binding to comprise two device tree nodes, as the
> design goal is to configure both bridges based on the LVDS signal, which
> leave the driver powerless to control the video processing pipeline. The
> two bridges behaves as a single bridge, and the driver is only needed for
> telling the host about EDID / HPD, and for giving the host powers to ack
> interrupts. The video signal pipeline is as follows:
>
> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
> -- // --
You forgot to prefix your patch series with [HACK] ;-)
How about fixing the issues that make the two DT nodes solution difficult ?
What are they ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Laurent Pinchart @ 2017-01-10 21:06 UTC (permalink / raw)
To: dri-devel
Cc: Peter Senna Tschudin, airlied, architt, akpm, daniel.vetter,
davem, devicetree, enric.balletbo, eballetbo, galak, gregkh,
heiko, ijc+devicetree, javier, jslaby, kernel, linux-arm-kernel,
linux, linux-kernel, linux, mark.rutland, martin.donnelly,
martyn.welch, mchehab, pawel.moll, peter.senna, p.zabel,
thierry.reding, rmk+kernel, robh+dt, shawnguo, tiwai
In-Reply-To: <21ea1b0795bdaa30ca475d6ce675b620b2b644ed.1483301745.git.peter.senna@collabora.com>
Hi Peter,
Thank you for the patch.
On Sunday 01 Jan 2017 21:24:29 Peter Senna Tschudin wrote:
> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> display bridge.
>
> Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> Cc: Martin Donnelly <martin.donnelly@ge.com>
> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> ---
> There was an Acked-by from Rob Herring <robh@kernel.org> for V6, but I
> changed the bindings to use i2c_new_secondary_device() so I removed it from
> the commit message.
>
> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 +++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>
> diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt new file mode
> 100644
> index 0000000..1bc6ebf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> @@ -0,0 +1,39 @@
> +Driver for GE B850v3 LVDS/DP++ display bridge
> +
> +Required properties:
> + - compatible : should be "ge,b850v3-lvds-dp".
> + - reg : should contain the main address which is used to ack the
> + interrupts and address for edid.
> + - reg-names : comma separeted list of register names. Valid values
> + are "main", and "edid".
> + - interrupt-parent : phandle of the interrupt controller that services
> + interrupts to the device
> + - interrupts : one interrupt should be described here, as in
> + <0 IRQ_TYPE_LEVEL_HIGH>.
> + - port : should describe the video signal connection between the host
> + and the bridge.
A bridge has, by definition, (at least) one input and (at least) one output.
You should thus have (at least) two ports.
> +Example:
> +
> +&mux2_i2c2 {
> + status = "okay";
> + clock-frequency = <100000>;
> +
> + b850v3-lvds-dp-bridge@73 {
> + compatible = "ge,b850v3-lvds-dp";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0x73 0x72>;
> + reg-names = "main", "edid";
> +
> + interrupt-parent = <&gpio2>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + port {
> + b850v3_dp_bridge_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/1] iio: adc: tlc4541: add support for TI tlc4541 adc
From: Jonathan Cameron @ 2017-01-10 21:17 UTC (permalink / raw)
To: Phil Reid, Peter Meerwald-Stadler
Cc: lars-Qo5EllUWu/uELgA04lAiVw, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d2b5f8fe-f9ce-bf9b-b5d8-facc10936290-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
On 10/01/17 06:26, Phil Reid wrote:
> G'day Peter,
>
> Thanks for the review.
>
> On 5/01/2017 17:21, Peter Meerwald-Stadler wrote:
> <snip>
>>> +
>>> +#define TLC4541_V_CHAN(index, bits) { \
>>> + .type = IIO_VOLTAGE, \
>>> + .indexed = 1, \
>>
>> no need if there is just one channel
>>
>>> + .channel = index, \
>>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>>> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
>>> + .address = index, \
>>
>> .address not needed
>>
>>> + .scan_index = index, \
>>> + .scan_type = { \
>>> + .sign = 'u', \
>>> + .realbits = (bits), \
>>> + .storagebits = 16, \
>>> + .endianness = IIO_BE, \
>>> + }, \
>>> + }
>>> +
>>> +#define DECLARE_TLC4541_CHANNELS(name, bits) \
>>
>> this flexibility is only needed when further chips are added; maybe start
>> simple and only implement what is needed at first
> I'll add the spec for to the TLC3541 which is a 14-bit version of this chip.
> I don't have one to test, but it looks pretty straight forward.
>
>>
>>> +const struct iio_chan_spec name ## _channels[] = { \
>>> + TLC4541_V_CHAN(0, bits), \
>>> + IIO_CHAN_SOFT_TIMESTAMP(1), \
>>> +}
>>> +
>>> +static DECLARE_TLC4541_CHANNELS(tlc4541, 16);
>>> +
>>> +static const struct tlc4541_chip_info tlc4541_chip_info[] = {
>>> + [TLC4541] = {
>>> + .channels = tlc4541_channels,
>>> + .num_channels = ARRAY_SIZE(tlc4541_channels),
>>> + },
>>> +};
>>> +
>>> +static irqreturn_t tlc4541_trigger_handler(int irq, void *p)
>>> +{
>>> + struct iio_poll_func *pf = p;
>>> + struct iio_dev *indio_dev = pf->indio_dev;
>>> + struct tlc4541_state *st = iio_priv(indio_dev);
>>> + u16 buf[8]; /* 2 bytes data + 6 bytes padding + 8 bytes timestamp */
>>> + int ret;
>>> +
>>> + ret = spi_sync(st->spi, &st->scan_single_msg);
>>> + if (ret < 0)
>>> + goto done;
>>> +
>>> + buf[0] = be16_to_cpu(st->rx_buf[0]);
>>
>> endianness is set to IIO_BE in scan_type, so this conversion is not needed
>> and maybe also buf and the copy can be avoided if rx_buf is large enough
>
> I was doing the conversion in IIO_CHAN_INFO_RAW as well.
> Is it required there? I'm guessing yes.
Yes. That path is outputting a human readable string so needs to be the write
way around.
>
>>
>>> + iio_push_to_buffers_with_timestamp(indio_dev, buf,
>>> + iio_get_time_ns(indio_dev));
>>> +
>>> +done:
>>> + iio_trigger_notify_done(indio_dev->trig);
>>> + return IRQ_HANDLED;
>>> +}
>>> +
>>> +static int tlc4541_get_range(struct tlc4541_state *st)
>>> +{
>>> + int vref;
>>> +
>>> + vref = regulator_get_voltage(st->reg);
>>> + if (vref < 0)
>>> + return vref;
>>> +
>>> + vref /= 1000;
>>> +
>>> + return vref;
>>> +}
>>> +
>>> +static int tlc4541_read_raw(struct iio_dev *indio_dev,
>>> + struct iio_chan_spec const *chan,
>>> + int *val,
>>> + int *val2,
>>> + long m)
>>> +{
>>> + int ret = 0;
>>> + struct tlc4541_state *st = iio_priv(indio_dev);
>>> +
>>> + switch (m) {
>>> + case IIO_CHAN_INFO_RAW:
>>> + ret = iio_device_claim_direct_mode(indio_dev);
>>> + if (ret)
>>> + return ret;
>>> + ret = spi_sync(st->spi, &st->scan_single_msg);
>>> + iio_device_release_direct_mode(indio_dev);
>>> + if (ret < 0)
>>> + return ret;
>>> + *val = be16_to_cpu(st->rx_buf[0]);
>>
>> on page 12 of the datasheet, the conversion results is in two registers?
>> and rx_buf has two elements?
>>
>> haven't investigated in detail -- maybe a comment would be good to detail
>> operation?
> I set that to 4 bytes because I also use that for the dummy 24 clock cycles
> at the beginning as well. I think that documentation is a bit misleading.
> Possible due to the tlc3451 datasheet being very similar. Those two registers
> are 14 bits and 2 bits wide respectively. The SPI cycle time shows data is
> available in the first 16 bits.
>
>
>>
>>> + return IIO_VAL_INT;
>>> + case IIO_CHAN_INFO_SCALE:
>>> + ret = tlc4541_get_range(st);
>>> + if (ret < 0)
>>> + return ret;
>>> + *val = ret;
>>> + *val2 = chan->scan_type.realbits;
>>> + return IIO_VAL_FRACTIONAL_LOG2;
>>> + }
>>> + return -EINVAL;
>>> +}
> <snip>
>
>
^ permalink raw reply
* Re: [PATCH v7 05/12] mux: support simplified bindings for single-user gpio mux
From: Jonathan Cameron @ 2017-01-10 21:22 UTC (permalink / raw)
To: Peter Rosin, linux-kernel
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
Arnd Bergmann, Greg Kroah-Hartman, linux-i2c, devicetree,
linux-iio, linux-doc
In-Reply-To: <60cd24a4-dd13-c5e8-c06d-bbd12a8e7e21@axentia.se>
On 08/01/17 21:56, Peter Rosin wrote:
> On 2017-01-08 11:28, Jonathan Cameron wrote:
>> On 05/01/17 16:21, Peter Rosin wrote:
>>> On 2017-01-04 13:16, Peter Rosin wrote:
>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>> ---
>>>> drivers/mux/mux-core.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++--
>>>> drivers/mux/mux-gpio.c | 56 ++--------------------------------
>>>> include/linux/mux.h | 7 +++++
>>>> 3 files changed, 89 insertions(+), 55 deletions(-)
>>>>
>>>> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
>>>> index 21da15a264ad..d887ae1c0e55 100644
>>>> --- a/drivers/mux/mux-core.c
>>>> +++ b/drivers/mux/mux-core.c
>>>> @@ -15,6 +15,7 @@
>>>> #include <linux/device.h>
>>>> #include <linux/err.h>
>>>> #include <linux/idr.h>
>>>> +#include <linux/gpio/consumer.h>
>>>> #include <linux/module.h>
>>>> #include <linux/mux.h>
>>>> #include <linux/of.h>
>>>> @@ -288,6 +289,63 @@ static struct mux_chip *of_find_mux_chip_by_node(struct device_node *np)
>>>> return dev ? to_mux_chip(dev) : NULL;
>>>> }
>>>>
>>>> +#ifdef CONFIG_MUX_GPIO
>>>> +
>>>> +static int mux_gpio_set(struct mux_control *mux, int state)
>>>> +{
>>>> + struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < mux_gpio->gpios->ndescs; i++)
>>>> + mux_gpio->val[i] = (state >> i) & 1;
>>>> +
>>>> + gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
>>>> + mux_gpio->gpios->desc,
>>>> + mux_gpio->val);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static const struct mux_control_ops mux_gpio_ops = {
>>>> + .set = mux_gpio_set,
>>>> +};
>>>> +
>>>> +struct mux_chip *mux_gpio_alloc(struct device *dev)
>>>> +{
>>>> + struct mux_chip *mux_chip;
>>>> + struct mux_gpio *mux_gpio;
>>>> + int pins;
>>>> + int ret;
>>>> +
>>>> + pins = gpiod_count(dev, "mux");
>>>> + if (pins < 0)
>>>> + return ERR_PTR(pins);
>>>> +
>>>> + mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
>>>> + pins * sizeof(*mux_gpio->val));
>>>> + if (!mux_chip)
>>>> + return ERR_PTR(-ENOMEM);
>>>> +
>>>> + mux_gpio = mux_chip_priv(mux_chip);
>>>> + mux_gpio->val = (int *)(mux_gpio + 1);
>>>> + mux_chip->ops = &mux_gpio_ops;
>>>> +
>>>> + mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
>>>> + if (IS_ERR(mux_gpio->gpios)) {
>>>> + ret = PTR_ERR(mux_gpio->gpios);
>>>> + if (ret != -EPROBE_DEFER)
>>>> + dev_err(dev, "failed to get gpios\n");
>>>> + return ERR_PTR(ret);
>>>> + }
>>>> + WARN_ON(pins != mux_gpio->gpios->ndescs);
>>>> + mux_chip->mux->states = 1 << pins;
>>>> +
>>>> + return mux_chip;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(mux_gpio_alloc);
>>>> +
>>>> +#endif /* CONFIG_MUX_GPIO */
>>>> +
>>>> struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
>>>> {
>>>> struct device_node *np = dev->of_node;
>>>> @@ -307,9 +365,28 @@ struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
>>>> ret = of_parse_phandle_with_args(np,
>>>> "mux-controls", "#mux-control-cells",
>>>> index, &args);
>>>> +
>>>> +#ifdef CONFIG_MUX_GPIO
>>>> + if (ret == -ENOENT && !mux_name && gpiod_count(dev, "mux") > 0) {
>>>> + mux_chip = mux_gpio_alloc(dev);
>>>> + if (!IS_ERR(mux_chip)) {
>>>> + ret = devm_mux_chip_register(dev, mux_chip);
>>>> + if (ret < 0) {
>>>> + dev_err(dev, "failed to register mux-chip\n");
>>>> + return ERR_PTR(ret);
>>>> + }
>>>> + get_device(&mux_chip->dev);
>>>> + return mux_chip->mux;
>>>> + }
>>>> +
>>>> + ret = PTR_ERR(mux_chip);
>>>> + }
>>>> +#endif
>>>> +
>>>> if (ret) {
>>>> - dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
>>>> - np->full_name, mux_name ?: "", index);
>>>> + if (ret != -EPROBE_DEFER)
>>>> + dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
>>>> + np->full_name, mux_name ?: "", index);
>>>> return ERR_PTR(ret);
>>>> }
>>>>
>>>> diff --git a/drivers/mux/mux-gpio.c b/drivers/mux/mux-gpio.c
>>>> index 76b52bc63470..8a7bfbc0c4bb 100644
>>>> --- a/drivers/mux/mux-gpio.c
>>>> +++ b/drivers/mux/mux-gpio.c
>>>> @@ -11,37 +11,12 @@
>>>> */
>>>>
>>>> #include <linux/err.h>
>>>> -#include <linux/gpio/consumer.h>
>>>> #include <linux/module.h>
>>>> #include <linux/mux.h>
>>>> #include <linux/of_platform.h>
>>>> #include <linux/platform_device.h>
>>>> #include <linux/property.h>
>>>
>>> Instead of moving the mux-gpio guts from mux-gpio.c to mux-core.c, I
>>> will instead make CONFIG_MUX_GPIO a bool option (no module possible)
>>> and call it from the mux-core. That will be cleaner and less of a
>>> break of abstractions in my opinion.
>> Hmm. I wonder if the balance is right here or whether we should just not have the
>> simplified binding at all as it breaks the assumption that all muxes are of the
>> same level...
>>
>> I like the binding, but it is causing significant complexity in here.
>
> Yes, in this patch it looks pretty bad. But with the suggested
> changes it at least looks fine (apart from the remaining ifdef
> in mux_control_get). But then there's of course the conceptual
> badness of the core depending on a specific driver that you
> mention...
>
> But. I expect that gpio based muxes will be in vast majority, and
> giving them some extra freedoms is probably not wrong considering
> the upside of the simpler binding.
>
Difficult balance. As you are going to be the poor soul who has
to maintain this I'm not that bothered either way ;)
Probably worth gathering a few more opinions on this though if
they are forthcoming.
Jonathan
>>>
>>> Cheers,
>>> Peter
>>>
>>>> -struct mux_gpio {
>>>> - struct gpio_descs *gpios;
>>>> - int *val;
>>>> -};
>>>> -
>>>> -static int mux_gpio_set(struct mux_control *mux, int state)
>>>> -{
>>>> - struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
>>>> - int i;
>>>> -
>>>> - for (i = 0; i < mux_gpio->gpios->ndescs; i++)
>>>> - mux_gpio->val[i] = (state >> i) & 1;
>>>> -
>>>> - gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
>>>> - mux_gpio->gpios->desc,
>>>> - mux_gpio->val);
>>>> -
>>>> - return 0;
>>>> -}
>>>> -
>>>> -static const struct mux_control_ops mux_gpio_ops = {
>>>> - .set = mux_gpio_set,
>>>> -};
>>>> -
>>>> static const struct of_device_id mux_gpio_dt_ids[] = {
>>>> { .compatible = "mux-gpio", },
>>>> { /* sentinel */ }
>>>> @@ -51,38 +26,13 @@ MODULE_DEVICE_TABLE(of, mux_gpio_dt_ids);
>>>> static int mux_gpio_probe(struct platform_device *pdev)
>>>> {
>>>> struct device *dev = &pdev->dev;
>>>> - struct device_node *np = dev->of_node;
>>>> struct mux_chip *mux_chip;
>>>> - struct mux_gpio *mux_gpio;
>>>> - int pins;
>>>> u32 idle_state;
>>>> int ret;
>>>>
>>>> - if (!np)
>>>> - return -ENODEV;
>>>> -
>>>> - pins = gpiod_count(dev, "mux");
>>>> - if (pins < 0)
>>>> - return pins;
>>>> -
>>>> - mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
>>>> - pins * sizeof(*mux_gpio->val));
>>>> - if (!mux_chip)
>>>> - return -ENOMEM;
>>>> -
>>>> - mux_gpio = mux_chip_priv(mux_chip);
>>>> - mux_gpio->val = (int *)(mux_gpio + 1);
>>>> - mux_chip->ops = &mux_gpio_ops;
>>>> -
>>>> - mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
>>>> - if (IS_ERR(mux_gpio->gpios)) {
>>>> - ret = PTR_ERR(mux_gpio->gpios);
>>>> - if (ret != -EPROBE_DEFER)
>>>> - dev_err(dev, "failed to get gpios\n");
>>>> - return ret;
>>>> - }
>>>> - WARN_ON(pins != mux_gpio->gpios->ndescs);
>>>> - mux_chip->mux->states = 1 << pins;
>>>> + mux_chip = mux_gpio_alloc(dev);
>>>> + if (IS_ERR(mux_chip))
>>>> + return PTR_ERR(mux_chip);
>>>>
>>>> ret = device_property_read_u32(dev, "idle-state", &idle_state);
>>>> if (ret >= 0) {
>>>> diff --git a/include/linux/mux.h b/include/linux/mux.h
>>>> index 3b9439927f11..3bfee23cfb8c 100644
>>>> --- a/include/linux/mux.h
>>>> +++ b/include/linux/mux.h
>>>> @@ -241,4 +241,11 @@ struct mux_control *devm_mux_control_get(struct device *dev,
>>>> */
>>>> void devm_mux_control_put(struct device *dev, struct mux_control *mux);
>>>>
>>>> +struct mux_gpio {
>>>> + struct gpio_descs *gpios;
>>>> + int *val;
>>>> +};
>>>> +
>>>> +struct mux_chip *mux_gpio_alloc(struct device *dev);
>>>> +
>>>> #endif /* _LINUX_MUX_H */
>>>>
>>>
>>
>
^ permalink raw reply
* [PATCH] devicetree: Add Fujitsu Ltd. vendor prefix
From: Marek Vasut @ 2017-01-10 21:32 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA; +Cc: Marek Vasut, Rob Herring
The vendor prefix for Fujitsu is used in the tree, but it's
still missing from the documentation, so add it. Fujitsu Ltd.
is a japanese ICT company, http://www.fujitsu.com
Signed-off-by: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d9c51d7f4aac..b04ef615c124 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -103,6 +103,7 @@ firefly Firefly
focaltech FocalTech Systems Co.,Ltd
friendlyarm Guangzhou FriendlyARM Computer Tech Co., Ltd
fsl Freescale Semiconductor
+fujitsu Fujitsu Ltd.
ge General Electric Company
geekbuying GeekBuying
gef GE Fanuc Intelligent Platforms Embedded Systems, Inc.
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 6/9] dt/bindings: Add a serial/UART attached device binding
From: Pavel Machek @ 2017-01-10 21:41 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Marcel Holtmann, Jiri Slaby,
Sebastian Reichel, Arnd Bergmann, Dr . H . Nikolaus Schaller,
Peter Hurley, Andy Shevchenko, Alan Cox, Loic Poulain, NeilBrown,
Linus Walleij, linux-bluetooth, linux-serial, linux-kernel,
Mark Rutland, devicetree
In-Reply-To: <20170106162635.19677-7-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
On Fri 2017-01-06 10:26:32, Rob Herring wrote:
> Add a common binding for describing serial/UART attached devices. Common
> examples are Bluetooth, WiFi, NFC and GPS devices.
>
> Serial attached devices are represented as child nodes of a UART node.
> This may need to be extended for more complex devices with multiple
> interfaces, but for the simple cases a child node is sufficient.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Looks ok to me.
Acked-by: Pavel Machek <pavel@ucw.cz>
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox