Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Rob Herring @ 2018-05-31 14:20 UTC (permalink / raw)
  To: Codrin Ciubotariu
  Cc: devicetree, Linux-ALSA, Alexandre Belloni, Nicolas Ferre,
	linux-kernel@vger.kernel.org, Boris Brezillon, Mark Brown,
	Cristian.Birsan, linux-clk,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <4f2e6e6a-df3a-b645-093c-b4467b3aa843@microchip.com>

On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
<codrin.ciubotariu@microchip.com> wrote:
> On 31.05.2018 03:58, Rob Herring wrote:
>>
>> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>>>
>>> The I2S mux clock can be used to select the I2S input clock. The
>>> available parents are the peripheral and the generated clocks.
>>>
>>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>>> ---
>>>   .../devicetree/bindings/clock/at91-clock.txt       | 34
>>> ++++++++++++++++++++++
>>>   1 file changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> index 51c259a..1c46b3c 100644
>>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
>>> @@ -90,6 +90,8 @@ Required properties:
>>>         "atmel,sama5d2-clk-audio-pll-pmc"
>>>                 at91 audio pll output on AUDIOPLLCLK that feeds the PMC
>>>                 and can be used by peripheral clock or generic clock
>>> +       "atmel,sama5d2-clk-i2s-mux":
>>> +               at91 I2S clock source selection
>>
>>
>> Is this boolean or takes some values. If latter, what are valid values?
>
>
> This is the compatible string of the clock driver.

Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
still a plan to fix this?

>>>     Required properties for SCKC node:
>>>   - reg : defines the IO memory reserved for the SCKC.
>>> @@ -507,3 +509,35 @@ For example:
>>>                         atmel,clk-output-range = <0 83000000>;
>>>                 };
>>>         };
>>> +
>>> +Required properties for I2S mux clocks:
>>> +- #size-cells : shall be 0 (reg is used to encode I2S bus id).
>>> +- #address-cells : shall be 1 (reg is used to encode I2S bus id).
>>> +- name: device tree node describing a specific mux clock.
>>> +       * #clock-cells : from common clock binding; shall be set to 0.
>>> +       * clocks : shall be the mux clock parent phandles; shall be 2
>>> phandles:
>>> +         peripheral and generated clock; the first phandle shall belong
>>> to the
>>> +         peripheral clock and the second one shall belong to the
>>> generated
>>> +         clock; "clock-indices" property can be user to specify
>>> +         the correct order.
>>> +       * reg: I2S bus id of the corresponding mux clock.
>>> +         e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
>>> +
>>> +For example:
>>> +       i2s_clkmux {
>>
>>
>> What is this a child of?
>
>
> It is a child of PMC node, since both parent clocks are generated by PMC.
>
>>
>>> +               compatible = "atmel,sama5d2-clk-i2s-mux";
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>
>>
>> How do you address this block? My guess is you don't because it is just
>> part of some other block and you are just creating this node to
>> instantiate a driver. Just make the node for the actual h/w block a
>> clock provider and define the clock ids (0 and 1).
>
>
> This block is not addressed, but its children are. The register we access in
> this driver is not part of other block. It's a SFR register, accessed
> through syscon and it has nothing to do with the I2S IP (see SAMA5D2 DS,
> page 1256, fig. 44-1: I2SC Block Diagram) that is the consumer of this
> clock. Adding a clock-id property in the I2S node would be just like v3 of
> this series, with the difference that we use clock-id instead of alias id to
> set the clock parent, which is not how you suggested back then.

I wasn't suggesting a clock-id property, but a clock specifier (i.e.
make #clock-cells 1).

But AT91 clocks are all a mess, so I don't know what to tell you.

Rob

^ permalink raw reply

* Re: [PATCH V2 13/15] arm: dts: r8a77xx: Add missing OPP properties for CPUs
From: Simon Horman @ 2018-05-31 14:24 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: arm, biju.das, Magnus Damm, Rob Herring, Mark Rutland,
	Vincent Guittot, ionela.voinescu, Daniel Lezcano, chris.redpath,
	linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <c6254ebb1f177468db6b8ac560ffb5a4a0b864f0.1527655562.git.viresh.kumar@linaro.org>

On Wed, May 30, 2018 at 10:16:58AM +0530, Viresh Kumar wrote:
> The OPP properties, like "operating-points", should either be present
> for all the CPUs of a cluster or none. If these are present only for a
> subset of CPUs of a cluster then things will start falling apart as soon
> as the CPUs are brought online in a different order. For example, this
> will happen because the operating system looks for such properties in
> the CPU node it is trying to bring up, so that it can create an OPP
> table.
> 
> Add such missing properties.
> 
> Fix other missing properties (like, clock latency, voltage tolerance,
> etc) as well to make it all work.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>

This looks fine but I will wait to see if there are other reviews before
applying.

Reviewed-by: Simon Horman <horms+renesas@verge.net.au>

^ permalink raw reply

* Re: [PATCH v2 4/8] dt-bindings: gnss: add u-blox binding
From: Johan Hovold @ 2018-05-31 14:34 UTC (permalink / raw)
  To: Rob Herring
  Cc: Johan Hovold, Greg Kroah-Hartman, Mark Rutland, Andreas Kemnade,
	Arnd Bergmann, H . Nikolaus Schaller, Pavel Machek,
	Marcel Holtmann, Sebastian Reichel, Tony Lindgren,
	linux-kernel@vger.kernel.org, devicetree
In-Reply-To: <CAL_Jsq+-NBqR8H49oB-XZtH8XSCn_BO92Zf17=KfEXfE5mvjAg@mail.gmail.com>

On Thu, May 31, 2018 at 08:55:10AM -0500, Rob Herring wrote:
> On Thu, May 31, 2018 at 3:22 AM, Johan Hovold <johan@kernel.org> wrote:
> > On Wed, May 30, 2018 at 10:58:05PM -0500, Rob Herring wrote:
> >> On Wed, May 30, 2018 at 12:32:38PM +0200, Johan Hovold wrote:
> >> > Add binding for u-blox GNSS receivers.
> >> >
> >> > Note that the u-blox product names encodes form factor (e.g. "neo"),
> >> > chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
> >> > chipset is used for the compatible strings (for now).
> >> >
> >> > Signed-off-by: Johan Hovold <johan@kernel.org>
> >> > ---
> >> >  .../devicetree/bindings/gnss/u-blox.txt       | 44 +++++++++++++++++++
> >> >  .../devicetree/bindings/vendor-prefixes.txt   |  1 +
> >> >  2 files changed, 45 insertions(+)
> >> >  create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/gnss/u-blox.txt b/Documentation/devicetree/bindings/gnss/u-blox.txt
> >> > new file mode 100644
> >> > index 000000000000..caef9ace0b0c
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/gnss/u-blox.txt
> >> > @@ -0,0 +1,44 @@
> >> > +u-blox GNSS Receiver DT binding
> >> > +
> >> > +The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
> >> > +
> >> > +Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
> >> > +properties.
> >> > +
> >> > +Required properties:
> >> > +
> >> > +- compatible       : Must be one of
> >>
> >> mixture of space and tab here.
> >
> > Oops. Same single space character before the tab here in all three
> > binding docs (and in the in-tree slave_devices.txt which I think I used
> > as a template).
> 
> Who wrote that crap? ;)

Heh.

> >
> >> > +
> >> > +                   "u-blox,neo-8"
> >> > +                   "u-blox,neo-m8"
> >> > +
> >> > +- vcc-supply       : Main voltage regulator
> >> > +
> >> > +Required properties (DDC):
> >> > +- reg              : DDC (I2C) slave address
> >> > +
> >> > +Required properties (SPI):
> >> > +- reg              : SPI chip select address
> >> > +
> >> > +Required properties (USB):
> >> > +- reg              : Number of the USB hub port or the USB host-controller port
> >> > +                  to which this device is attached
> >> > +
> >> > +Optional properties:
> >> > +
> >> > +- timepulse-gpios  : Time pulse GPIO
> >> > +- u-blox,extint-gpios      : External interrupt GPIO
> >>
> >> This should be interrupts property instead of a gpio.
> >
> > Contrary to what the name may suggest, this pin is actually an input
> > which can be used to control active power or to provide time or
> > frequency aiding data to the receiver (see section 1.13 in [1]).
> >
> > I only added it for completeness as the driver does not use it
> > currently. Remove, leave as is, or add "input" to the description as in:
> >
> >         - u-blox,extint-gpios   : External interrupt input GPIO
> 
> Yes. You should also define the active level.

The active level appears to be runtime configurable and dependent on the
selected function. For power control it can be used to control force-on
(active high), force-off (active low) or both; and for time aiding
sampling on falling or rising edge is also configurable. And who knows
what else this pin is used for next time they update the firmware. ;)

Shall I remove the property, or just add "input" as suggested above?

Thanks,
Johan

^ permalink raw reply

* Re: [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Rob Herring @ 2018-05-31 14:45 UTC (permalink / raw)
  To: Levin Du
  Cc: open list:ARM/Rockchip SoC..., Wayne Chou, Heiko Stuebner,
	devicetree, Linus Walleij, linux-kernel@vger.kernel.org,
	open list:GPIO SUBSYSTEM, Mark Rutland,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1527737273-8387-3-git-send-email-djw@t-chip.com.cn>

On Wed, May 30, 2018 at 10:27 PM,  <djw@t-chip.com.cn> wrote:
> From: Levin Du <djw@t-chip.com.cn>
>
> In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
> mute control, can also be used for general purpose. It is manipulated by
> the GRF_SOC_CON10 register.
>
> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>
> ---
>
> Changes in v3:
> - Change from general gpio-syscon to specific rk3328-gpio-mute
>
> Changes in v2:
> - Rename gpio_syscon10 to gpio_mute in doc
>
> Changes in v1:
> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> - Add doc rockchip,gpio-syscon.txt
>
>  .../bindings/gpio/rockchip,rk3328-gpio-mute.txt    | 28 +++++++++++++++++++
>  drivers/gpio/gpio-syscon.c                         | 31 ++++++++++++++++++++++
>  2 files changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> new file mode 100644
> index 0000000..10bc632
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
> @@ -0,0 +1,28 @@
> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE pin.
> +
> +In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute
> +control, can also be used for general purpose. It is manipulated by the
> +GRF_SOC_CON10 register.
> +
> +Required properties:
> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
> +- gpio-controller: Marks the device node as a gpio controller.
> +- #gpio-cells: Should be 2. The first cell is the pin number and
> +  the second cell is used to specify the gpio polarity:
> +    0 = Active high,
> +    1 = Active low.
> +
> +Example:
> +
> +       grf: syscon@ff100000 {
> +               compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> +
> +               gpio_mute: gpio-mute {

Node names should be generic:

gpio {

This also means you can't add another GPIO node in the future and
you'll have to live with "rockchip,rk3328-gpio-mute" covering more
than 1 GPIO if you do need to add more GPIOs.

> +                       compatible = "rockchip,rk3328-gpio-mute";
> +                       gpio-controller;
> +                       #gpio-cells = <2>;
> +               };
> +       };
> +
> +Note: The gpio_mute node should be declared as the child of the GRF (General
> +Register File) node. The GPIO_MUTE pin is referred to as <&gpio_mute 0>.

This is wrong because you should have 2 cells. The phandle doesn't
count as a cell.

Rob

^ permalink raw reply

* Re: [PATCH v4 2/6] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Stephen Boyd @ 2018-05-31 14:57 UTC (permalink / raw)
  To: Matti Vaittinen, Rob Herring
  Cc: Matti Vaittinen, Michael Turquette, Mark Rutland, Lee Jones,
	Liam Girdwood, Mark Brown, linux-clk, devicetree,
	linux-kernel@vger.kernel.org, mikko.mutanen, heikki.haikola
In-Reply-To: <CAL_Jsq+33G7zMEDOUXHQijxqqbvqykxZENLe1-52ECkXwo2o4g@mail.gmail.com>

Quoting Rob Herring (2018-05-31 07:07:24)
> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen
> <mazziesaccount@gmail.com> wrote:
> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
> >> Hello Rob,
> >>
> >> Thanks for the review!
> >>
> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote:
> >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD.
> >> > > + - interrupts            : The interrupt line the device is connected to.
> >> > > + - interrupt-controller  : Marks the device node as an interrupt controller.
> >> >
> >> > What sub blocks have interrupts?
> >>
> >> The PMIC can generate interrupts from events which cause it to reset.
> >> Eg, irq from watchdog line change, power button pushes, reset request
> >> via register interface etc. I don't know any generic handling for these
> >> interrupts. In "normal" use-case this PMIC is powering the processor
> >> where driver is running and I do not see reasonable handling because
> >> power-reset is going to follow the irq.
> >>
> >
> > Oh, but when reading this I understand that the interrupt-controller
> > property should at least be optional.
> 
> I don't think it should. The h/w either has an interrupt controller or
> it doesn't. My concern is you added it but nothing uses it which tells
> me your binding is incomplete. I'd rather see complete bindings even
> if you don't have drivers. For example, as-is, there's not really any
> need for the clocks child node. You can just make the parent a clock
> provider. But we need a complete picture of the h/w to make that
> determination.
> 

I don't see a reason to have the clk subnode either.

^ permalink raw reply

* Re: [PATCH v4 5/6] clk: bd71837: Add driver for BD71837 PMIC clock
From: Stephen Boyd @ 2018-05-31 15:10 UTC (permalink / raw)
  To: Matti Vaittinen, broonie, lee.jones, lgirdwood, mark.rutland,
	mazziesaccount, mturquette, robh+dt
  Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
	heikki.haikola
In-Reply-To: <3d9d7239331c30826a237ae55db28d918155d504.1527669443.git.matti.vaittinen@fi.rohmeurope.com>

Quoting Matti Vaittinen (2018-05-30 01:43:19)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 41492e980ef4..4b045699bb5e 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -279,6 +279,15 @@ config COMMON_CLK_STM32H7
>         ---help---
>           Support for stm32h7 SoC family clocks
>  
> +config COMMON_CLK_BD71837
> +       tristate "Clock driver for ROHM BD71837 PMIC MFD"
> +       depends on MFD_BD71837
> +       depends on I2C=y

Why depend on I2C=y?

> +       depends on OF

Why depend on OF?

> +       help
> +         This driver supports ROHM BD71837 PMIC clock.
> +
> +
>  source "drivers/clk/bcm/Kconfig"
>  source "drivers/clk/hisilicon/Kconfig"
>  source "drivers/clk/imgtec/Kconfig"
> diff --git a/drivers/clk/clk-bd71837.c b/drivers/clk/clk-bd71837.c
> new file mode 100644
> index 000000000000..91456d1077ac
> --- /dev/null
> +++ b/drivers/clk/clk-bd71837.c
> @@ -0,0 +1,151 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2018 ROHM Semiconductors
> +// bd71837.c  -- ROHM BD71837MWV clock driver
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/mfd/bd71837.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +
> +static int bd71837_clk_enable(struct clk_hw *hw);
> +static void bd71837_clk_disable(struct clk_hw *hw);
> +static int bd71837_clk_is_enabled(struct clk_hw *hw);
> +
> +struct bd71837_clk {
> +       struct clk_hw hw;
> +       uint8_t reg;
> +       uint8_t mask;
> +       unsigned long rate;
> +       struct platform_device *pdev;
> +       struct bd71837 *mfd;
> +};
> +
> +static unsigned long bd71837_clk_recalc_rate(struct clk_hw *hw,
> +                                            unsigned long parent_rate);
> +
> +static const struct clk_ops bd71837_clk_ops = {
> +       .recalc_rate = &bd71837_clk_recalc_rate,
> +       .prepare = &bd71837_clk_enable,
> +       .unprepare = &bd71837_clk_disable,
> +       .is_prepared = &bd71837_clk_is_enabled,
> +};

Move this structure after the function definitions. And drop the forward
declared functions.

> +
> +static int bd71837_clk_set(struct clk_hw *hw, int status)
> +{
> +       struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> +
> +       return bd71837_update_bits(c->mfd, c->reg, c->mask, status);
> +}
> +
> +static void bd71837_clk_disable(struct clk_hw *hw)
> +{
> +       int rv;
> +       struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> +
> +       rv = bd71837_clk_set(hw, 0);
> +       if (rv)
> +               dev_err(&c->pdev->dev, "Failed to disable 32K clk (%d)\n", rv);

Why is a disable error message more important than an enable error
message?  Please drop this message and rely on callers to indicate if
enabling their clk didn't work for some reason.

> +}
> +
> +static int bd71837_clk_enable(struct clk_hw *hw)
> +{
> +       return bd71837_clk_set(hw, 1);
> +}
> +
> +static int bd71837_clk_is_enabled(struct clk_hw *hw)
> +{
> +       struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> +
> +       return c->mask & bd71837_reg_read(c->mfd, c->reg);

Please put this on two or more lines so we know what the type of
bd71837_reg_read() returns:

	u32 reg = bd71837_reg_read(....)

	return c->mask & reg;


> +}
> +
> +static unsigned long bd71837_clk_recalc_rate(struct clk_hw *hw,
> +                                            unsigned long parent_rate)
> +{
> +       struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> +
> +       return c->rate;

Recalc rate should read the hardware instead of returning a cached rate
unless it can't actually read hardware.

> +}
> +
> +static int bd71837_clk_probe(struct platform_device *pdev)
> +{
> +       struct bd71837_clk *c;
> +       int rval = -ENOMEM;
> +       struct bd71837 *mfd = dev_get_drvdata(pdev->dev.parent);
> +       const char *errstr = "memory allocation for bd71837 data failed";

We don't need allocation error messages.

> +       struct clk_init_data init = {
> +               .name = "bd71837-32k-out",
> +               .ops = &bd71837_clk_ops,
> +       };
> +
> +       c = kzalloc(sizeof(struct bd71837_clk), GFP_KERNEL);

Use sizeof(*c) instead so we don't have to worry about type mismatches.

> +       if (!c)
> +               goto err_out;
> +
> +       c->reg = BD71837_REG_OUT32K;
> +       c->mask = BD71837_OUT32K_EN;
> +       c->rate = BD71837_CLK_RATE;

Is the plan to have more clks supported by this driver in the future?
Because right now it seems to make a structure up and then hardcode the
members for a single clk so I'm not sure why those registers aren't just
hardcoded in the clk_ops functions that use them.

> +       c->mfd = mfd;
> +       c->pdev = pdev;
> +
> +       if (pdev->dev.of_node)

If there isn't an of_node it would be NULL, and then calling the
function below would cause it to not update the init name? Seems like it
could be called unconditionally.

> +               of_property_read_string_index(pdev->dev.of_node,
> +                                             "clock-output-names", 0,
> +                                             &init.name);
> +
> +       c->hw.init = &init;
> +
> +       errstr = "failed to register 32K clk";

The 'errstr' thing is not standard. Please just call dev_err() directly
with the string you want to print. And consider not printing anything at
all.

> +       rval = clk_hw_register(&pdev->dev, &c->hw);
> +       if (rval)
> +               goto err_free;
> +
> +       errstr = "failed to register clkdev for bd71837";
> +       rval = clk_hw_register_clkdev(&c->hw, init.name, NULL);

Are you using the clkdev lookup? Or this is just added for backup
purposes? If this is a mostly DT driver then please drop this part of
the patch and rely on of_clk_hw_add_provider() to handle the lookup
instead.

> +       if (rval)
> +               goto err_unregister;
> +
> +       platform_set_drvdata(pdev, c);
> +       dev_dbg(&pdev->dev, "bd71837_clk successfully probed\n");

There's a pr_debug() in really_probe() for this.

> +
> +       return 0;
> +
> +err_unregister:
> +       clk_hw_unregister(&c->hw);
> +err_free:
> +       kfree(c);
> +err_out:
> +       dev_err(&pdev->dev, "%s\n", errstr);
> +       return rval;
> +}
> +
> +static int bd71837_clk_remove(struct platform_device *pdev)
> +{
> +       struct bd71837_clk *c = platform_get_drvdata(pdev);
> +
> +       if (c) {
> +               clk_hw_unregister(&c->hw);

Use devm to register clks.

> +               kfree(c);

and devm_kzalloc()

> +               platform_set_drvdata(pdev, NULL);

This doesn't need to be done. Drop it.

> +       }
> +       return 0;
> +}
> +

^ permalink raw reply

* Re: [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Tony Lindgren @ 2018-05-31 15:26 UTC (permalink / raw)
  To: Tero Kristo
  Cc: Faiz Abbas, linux-kernel, devicetree, linux-omap,
	linux-arm-kernel, linux-clk, robh+dt, bcousson, paul
In-Reply-To: <98c989ca-0694-5150-f74b-35f3e4bf20c0@ti.com>

* Tero Kristo <t-kristo@ti.com> [180531 06:18]:
> On 30/05/18 18:54, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [180530 15:44]:
> > > On 30/05/18 18:28, Tony Lindgren wrote:
> > > > * Tero Kristo <t-kristo@ti.com> [180530 15:18]:
> > > > > For the OCP if part, I think that is still needed until we switch over to
> > > > > full sysc driver. clkctrl_offs you probably also need because that is used
> > > > > for mapping the omap_hwmod against a specific clkctrl clock. Those can be
> > > > > only removed once we are done with hwmod (or figure out some other way to
> > > > > assign the clkctrl clock to a hwmod.)
> > > > 
> > > > Hmm might be worth testing. I thought your commit 70f05be32133
> > > > ("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
> > > > already parses the clkctrl from dts?
> > > 
> > > It maps the clkctrl clock to be used by hwmod, if those are available. We
> > > didn't add any specific clock entries to DT for mapping the actual clkctrl
> > > clock without the hwmod_data hints yet though, as that was deemed temporary
> > > solution only due to transition to interconnect driver. I.e., you would need
> > > something like this in DT for every device node:
> > > 
> > > &uart3 {
> > >    clocks = <l4per_clkctrl UART3_CLK 0>;
> > >    clock-names = "clkctrl";
> > > };
> > > 
> > > ... which is currently not present.
> > 
> > Hmm is that not the "fck" clkctrl clock we have already in
> > the dts files for the interconnect target modules?
> 
> Oh okay, yeah, we could parse that one, but currently it is not done, and is
> not present for everything either I believe.
> 
> > We can also use pdata callbacks to pass the clock node if
> > needed. But I guess I don't quite still understand what we
> > are missing :)
> 
> So, what is missing is the glue logic only from the hwmod codebase. Right
> now this is not supported but should be relatively trivial thing to add if
> we really want to do this.

OK let's think about this a bit for v4.19 then.

Regards,

Tony

^ permalink raw reply

* Re: [PATCH v4 2/7] clk: at91: add I2S clock mux driver
From: Stephen Boyd @ 2018-05-31 15:26 UTC (permalink / raw)
  To: Codrin Ciubotariu, alexandre.belloni, alsa-devel, boris.brezillon,
	broonie, devicetree, linux-arm-kernel, linux-clk, linux-kernel,
	nicolas.ferre, robh+dt
  Cc: Cristian.Birsan
In-Reply-To: <1527251668-31396-3-git-send-email-codrin.ciubotariu@microchip.com>

Quoting Codrin Ciubotariu (2018-05-25 05:34:23)
> This driver is a simple muxing driver that controls the
> I2S's clock input by using syscon/regmap to change the parrent.

s/parrent/parent/

> The available inputs can be Peripheral clock and Generated clock.

Why capitalize peripheral and generated?

> 
> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> ---
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 1254bf9..903f23c 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -27,6 +27,7 @@ config SOC_SAMA5D2
>         select HAVE_AT91_H32MX
>         select HAVE_AT91_GENERATED_CLK
>         select HAVE_AT91_AUDIO_PLL
> +       select HAVE_AT91_I2S_MUX_CLK
>         select PINCTRL_AT91PIO4
>         help
>           Select this if ou are using one of Microchip's SAMA5D2 family SoC.
> @@ -129,6 +130,9 @@ config HAVE_AT91_GENERATED_CLK
>  config HAVE_AT91_AUDIO_PLL
>         bool
>  
> +config HAVE_AT91_I2S_MUX_CLK
> +       bool
> +
>  config SOC_SAM_V4_V5
>         bool
>  

I guess this is OK.

> diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
> index 082596f..facc169 100644
> --- a/drivers/clk/at91/Makefile
> +++ b/drivers/clk/at91/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_HAVE_AT91_USB_CLK)               += clk-usb.o
>  obj-$(CONFIG_HAVE_AT91_SMD)            += clk-smd.o
>  obj-$(CONFIG_HAVE_AT91_H32MX)          += clk-h32mx.o
>  obj-$(CONFIG_HAVE_AT91_GENERATED_CLK)  += clk-generated.o
> +obj-$(CONFIG_HAVE_AT91_I2S_MUX_CLK)    += clk-i2s-mux.o
> diff --git a/drivers/clk/at91/clk-i2s-mux.c b/drivers/clk/at91/clk-i2s-mux.c
> new file mode 100644
> index 0000000..2d56ded
> --- /dev/null
> +++ b/drivers/clk/at91/clk-i2s-mux.c
> @@ -0,0 +1,117 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + *  Copyright (C) 2018 Microchip Technology Inc,
> + *                     Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> + *
> + *
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#include <soc/at91/atmel-sfr.h>
> +
> +#define        I2S_BUS_NR      2
> +
> +struct clk_i2s_mux {
> +       struct clk_hw hw;
> +       struct regmap *regmap;
> +       u32 bus_id;

Can be a u8?

> +};
> +
> +#define to_clk_i2s_mux(hw) container_of(hw, struct clk_i2s_mux, hw)
> +
> +static u8 clk_i2s_mux_get_parent(struct clk_hw *hw)
> +{
> +       struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
> +       u32 val;
> +
> +       regmap_read(mux->regmap, AT91_SFR_I2SCLKSEL, &val);
> +
> +       return (val & BIT(mux->bus_id)) >> mux->bus_id;
> +}
> +
> +static int clk_i2s_mux_set_parent(struct clk_hw *hw, u8 index)
> +{
> +       struct clk_i2s_mux *mux = to_clk_i2s_mux(hw);
> +
> +       return regmap_update_bits(mux->regmap, AT91_SFR_I2SCLKSEL,
> +                                 BIT(mux->bus_id), index << mux->bus_id);
> +}
> +
> +const struct clk_ops clk_i2s_mux_ops = {

static?

> +       .get_parent = clk_i2s_mux_get_parent,
> +       .set_parent = clk_i2s_mux_set_parent,
> +       .determine_rate = __clk_mux_determine_rate,
> +};
> +
> +static struct clk_hw * __init
> +at91_clk_i2s_mux_register(struct regmap *regmap, const char *name,
> +                         const char * const *parent_names,
> +                         unsigned int num_parents, u32 bus_id)
> +{
> +       struct clk_init_data init = {};
> +       struct clk_i2s_mux *i2s_ck;
> +       int ret;
> +
> +       i2s_ck = kzalloc(sizeof(*i2s_ck), GFP_KERNEL);
> +       if (!i2s_ck)
> +               return ERR_PTR(-ENOMEM);
> +
> +       init.name = name;
> +       init.ops = &clk_i2s_mux_ops;
> +       init.parent_names = parent_names;
> +       init.num_parents = num_parents;
> +       init.flags = CLK_IGNORE_UNUSED;

Really? Why?

> +
> +       i2s_ck->hw.init = &init;
> +       i2s_ck->bus_id = bus_id;
> +       i2s_ck->regmap = regmap;
> +
> +       ret = clk_hw_register(NULL, &i2s_ck->hw);
> +       if (ret) {
> +               kfree(i2s_ck);
> +               return ERR_PTR(ret);
> +       }
> +
> +       return &i2s_ck->hw;
> +}

^ permalink raw reply

* Re: [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Stephen Boyd @ 2018-05-31 15:31 UTC (permalink / raw)
  To: Codrin Ciubotariu, Rob Herring
  Cc: devicetree, Linux-ALSA, Alexandre Belloni,
	linux-kernel@vger.kernel.org, Boris Brezillon, Mark Brown,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	linux-clk, Cristian.Birsan
In-Reply-To: <CAL_JsqJ=T0p17hHg6=obtydt7T-yrAeOr7C2XAEnDFQ-c0b5XQ@mail.gmail.com>

Quoting Rob Herring (2018-05-31 07:20:57)
> On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
> <codrin.ciubotariu@microchip.com> wrote:
> > On 31.05.2018 03:58, Rob Herring wrote:
> >>
> >> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
> >>>
> >>> The I2S mux clock can be used to select the I2S input clock. The
> >>> available parents are the peripheral and the generated clocks.
> >>>
> >>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> >>> ---
> >>>   .../devicetree/bindings/clock/at91-clock.txt       | 34
> >>> ++++++++++++++++++++++
> >>>   1 file changed, 34 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> index 51c259a..1c46b3c 100644
> >>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> @@ -90,6 +90,8 @@ Required properties:
> >>>         "atmel,sama5d2-clk-audio-pll-pmc"
> >>>                 at91 audio pll output on AUDIOPLLCLK that feeds the PMC
> >>>                 and can be used by peripheral clock or generic clock
> >>> +       "atmel,sama5d2-clk-i2s-mux":
> >>> +               at91 I2S clock source selection
> >>
> >>
> >> Is this boolean or takes some values. If latter, what are valid values?
> >
> >
> > This is the compatible string of the clock driver.
> 
> Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
> still a plan to fix this?

I'm also interested in a plan.

> >>
> >>> +               compatible = "atmel,sama5d2-clk-i2s-mux";
> >>> +               #address-cells = <1>;
> >>> +               #size-cells = <0>;
> >>
> >>
> >> How do you address this block? My guess is you don't because it is just
> >> part of some other block and you are just creating this node to
> >> instantiate a driver. Just make the node for the actual h/w block a
> >> clock provider and define the clock ids (0 and 1).
> >
> >
> > This block is not addressed, but its children are. The register we access in
> > this driver is not part of other block. It's a SFR register, accessed
> > through syscon and it has nothing to do with the I2S IP (see SAMA5D2 DS,
> > page 1256, fig. 44-1: I2SC Block Diagram) that is the consumer of this
> > clock. Adding a clock-id property in the I2S node would be just like v3 of
> > this series, with the difference that we use clock-id instead of alias id to
> > set the clock parent, which is not how you suggested back then.
> 
> I wasn't suggesting a clock-id property, but a clock specifier (i.e.
> make #clock-cells 1).
> 
> But AT91 clocks are all a mess, so I don't know what to tell you.
> 

If #clock-cells of 1 works then we should go with that. It's still weird
that we need random nodes to add more clks, but I guess that's how it's
going to be for each at91 clk driver until it changes to be one big
provider node.

^ permalink raw reply

* Re: [PATCH v2 00/12] coresight: tmc-etr Transparent buffer management
From: Mathieu Poirier @ 2018-05-31 15:36 UTC (permalink / raw)
  To: Suzuki K Poulose
  Cc: linux-arm-kernel, Linux Kernel Mailing List, Mike Leach,
	Robert Walker, coresight, devicetree, Rob Herring, Frank Rowand
In-Reply-To: <1527599737-28408-1-git-send-email-suzuki.poulose@arm.com>

On 29 May 2018 at 07:15, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> This series is split of the Coresight ETR perf support patches posted
> here [0]. The CATU support and perf backend support will be posted as
> separate series for better management and review of the patches.
>
> This series adds the support for TMC ETR Scatter-Gather mode to allow
> using physical non-contiguous buffer for holding the trace data. It
> also adds a layer to handle the buffer management in a transparent
> manner, independent of the underlying mode used by the TMC ETR.
> The layer chooses the ETR mode based on different parameters (size,
> re-using a set of pages, presence of an SMMU etc.).
>
> Finally we add a sysfs parameter to tune the buffer size for ETR in
> sysfs-mode.
>
> During the testing, we found out that if the TMC ETR is not properly
> connected to the memory subsystem, the ETR could lock-up the system
> while waiting for the "read" transactions to complete in scatter-gather
> mode. So, we do not use the mode on a system unless it is safe to do
> so. This is specified by a DT property "arm,scatter-gather".
>
> Applies on coreisght-next tree from Mathieu
>
> Changes since previous version [1]:
>  - Rebased to Mathieu's coresight-next tree to resolve a conflict.
>  - Added tags for DT changes from Rob and Mathieu
>  - Split the SG mode backend support patch from the
>    ETR-BUF patch.
>  - Address other comments from Mathieu
>
> Changes since splitted series [0] :
>  - Split the series in [0]
>  - Address comments on v2
>  - Rename DT property "scatter-gather" to "arm,scatter-gather"
>  - Add ETM PID for Cortex-A35, use macros to make the listing easier
>
> [0] - http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/574875.html
> [1] - http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/579135.html
>
> Suzuki K Poulose (12):
>   coresight: ETM: Add support for Arm Cortex-A73 and Cortex-A35
>   coresight: tmc: Hide trace buffer handling for file read
>   coresight: tmc-etr: Do not clean trace buffer
>   coresight: tmc-etr: Disallow perf mode
>   coresight: Add helper for inserting synchronization packets
>   dts: bindings: Restrict coresight tmc-etr scatter-gather mode
>   dts: juno: Add scatter-gather support for all revisions
>   coresight: Add generic TMC sg table framework
>   coresight: Add support for TMC ETR SG unit
>   coresight: tmc-etr: Add transparent buffer management
>   coresight: tmc-etr buf: Add TMC scatter gather mode backend
>   coresight: tmc: Add configuration support for trace buffer size
>
>  .../ABI/testing/sysfs-bus-coresight-devices-tmc    |    8 +
>  .../devicetree/bindings/arm/coresight.txt          |    5 +-
>  arch/arm64/boot/dts/arm/juno-base.dtsi             |    1 +
>  drivers/hwtracing/coresight/coresight-etb10.c      |   12 +-
>  drivers/hwtracing/coresight/coresight-etm4x.c      |   31 +-
>  drivers/hwtracing/coresight/coresight-priv.h       |   10 +-
>  drivers/hwtracing/coresight/coresight-tmc-etf.c    |   45 +-
>  drivers/hwtracing/coresight/coresight-tmc-etr.c    | 1010 ++++++++++++++++++--
>  drivers/hwtracing/coresight/coresight-tmc.c        |   83 +-
>  drivers/hwtracing/coresight/coresight-tmc.h        |  110 ++-
>  drivers/hwtracing/coresight/coresight.c            |    3 +-
>  11 files changed, 1144 insertions(+), 174 deletions(-)

Applied after correcting indentation problems and rectifying the
kernel version and date in "sysfs-bus-coresight-devices-tmc".

Mathieu

>
> --
> 2.7.4
>

^ permalink raw reply

* Re: [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Rob Herring @ 2018-05-31 15:56 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: devicetree, Linux-ALSA, Alexandre Belloni,
	linux-kernel@vger.kernel.org, Boris Brezillon, Mark Brown,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	Codrin Ciubotariu, linux-clk, Cristian.Birsan
In-Reply-To: <152778070837.144038.4555982304713569160@swboyd.mtv.corp.google.com>

On Thu, May 31, 2018 at 10:31 AM, Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Rob Herring (2018-05-31 07:20:57)
>> On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
>> <codrin.ciubotariu@microchip.com> wrote:
>> > On 31.05.2018 03:58, Rob Herring wrote:
>> >>
>> >> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
>> >>>
>> >>> The I2S mux clock can be used to select the I2S input clock. The
>> >>> available parents are the peripheral and the generated clocks.
>> >>>
>> >>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
>> >>> ---
>> >>>   .../devicetree/bindings/clock/at91-clock.txt       | 34
>> >>> ++++++++++++++++++++++
>> >>>   1 file changed, 34 insertions(+)
>> >>>
>> >>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
>> >>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> >>> index 51c259a..1c46b3c 100644
>> >>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
>> >>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
>> >>> @@ -90,6 +90,8 @@ Required properties:
>> >>>         "atmel,sama5d2-clk-audio-pll-pmc"
>> >>>                 at91 audio pll output on AUDIOPLLCLK that feeds the PMC
>> >>>                 and can be used by peripheral clock or generic clock
>> >>> +       "atmel,sama5d2-clk-i2s-mux":
>> >>> +               at91 I2S clock source selection
>> >>
>> >>
>> >> Is this boolean or takes some values. If latter, what are valid values?
>> >
>> >
>> > This is the compatible string of the clock driver.
>>
>> Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
>> still a plan to fix this?
>
> I'm also interested in a plan.
>
>> >>
>> >>> +               compatible = "atmel,sama5d2-clk-i2s-mux";
>> >>> +               #address-cells = <1>;
>> >>> +               #size-cells = <0>;
>> >>
>> >>
>> >> How do you address this block? My guess is you don't because it is just
>> >> part of some other block and you are just creating this node to
>> >> instantiate a driver. Just make the node for the actual h/w block a
>> >> clock provider and define the clock ids (0 and 1).
>> >
>> >
>> > This block is not addressed, but its children are. The register we access in
>> > this driver is not part of other block. It's a SFR register, accessed
>> > through syscon and it has nothing to do with the I2S IP (see SAMA5D2 DS,
>> > page 1256, fig. 44-1: I2SC Block Diagram) that is the consumer of this
>> > clock. Adding a clock-id property in the I2S node would be just like v3 of
>> > this series, with the difference that we use clock-id instead of alias id to
>> > set the clock parent, which is not how you suggested back then.
>>
>> I wasn't suggesting a clock-id property, but a clock specifier (i.e.
>> make #clock-cells 1).
>>
>> But AT91 clocks are all a mess, so I don't know what to tell you.
>>
>
> If #clock-cells of 1 works then we should go with that. It's still weird
> that we need random nodes to add more clks, but I guess that's how it's
> going to be for each at91 clk driver until it changes to be one big
> provider node.

Seems to me that clock additions could use a new binding and we start
with a new driver that handles these few clocks initially. But I
haven't looked whether both can coexist.

Rob

^ permalink raw reply

* Re: [PATCH v2 4/8] dt-bindings: gnss: add u-blox binding
From: Rob Herring @ 2018-05-31 15:58 UTC (permalink / raw)
  To: Johan Hovold
  Cc: Greg Kroah-Hartman, Mark Rutland, Andreas Kemnade, Arnd Bergmann,
	H . Nikolaus Schaller, Pavel Machek, Marcel Holtmann,
	Sebastian Reichel, Tony Lindgren, linux-kernel@vger.kernel.org,
	devicetree
In-Reply-To: <20180531143428.GK3259@localhost>

On Thu, May 31, 2018 at 9:34 AM, Johan Hovold <johan@kernel.org> wrote:
> On Thu, May 31, 2018 at 08:55:10AM -0500, Rob Herring wrote:
>> On Thu, May 31, 2018 at 3:22 AM, Johan Hovold <johan@kernel.org> wrote:
>> > On Wed, May 30, 2018 at 10:58:05PM -0500, Rob Herring wrote:
>> >> On Wed, May 30, 2018 at 12:32:38PM +0200, Johan Hovold wrote:
>> >> > Add binding for u-blox GNSS receivers.
>> >> >
>> >> > Note that the u-blox product names encodes form factor (e.g. "neo"),
>> >> > chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
>> >> > chipset is used for the compatible strings (for now).
>> >> >
>> >> > Signed-off-by: Johan Hovold <johan@kernel.org>
>> >> > ---
>> >> >  .../devicetree/bindings/gnss/u-blox.txt       | 44 +++++++++++++++++++
>> >> >  .../devicetree/bindings/vendor-prefixes.txt   |  1 +
>> >> >  2 files changed, 45 insertions(+)
>> >> >  create mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
>> >> >
>> >> > diff --git a/Documentation/devicetree/bindings/gnss/u-blox.txt b/Documentation/devicetree/bindings/gnss/u-blox.txt
>> >> > new file mode 100644
>> >> > index 000000000000..caef9ace0b0c
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/gnss/u-blox.txt
>> >> > @@ -0,0 +1,44 @@
>> >> > +u-blox GNSS Receiver DT binding
>> >> > +
>> >> > +The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.
>> >> > +
>> >> > +Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic
>> >> > +properties.
>> >> > +
>> >> > +Required properties:
>> >> > +
>> >> > +- compatible       : Must be one of
>> >>
>> >> mixture of space and tab here.
>> >
>> > Oops. Same single space character before the tab here in all three
>> > binding docs (and in the in-tree slave_devices.txt which I think I used
>> > as a template).
>>
>> Who wrote that crap? ;)
>
> Heh.
>
>> >
>> >> > +
>> >> > +                   "u-blox,neo-8"
>> >> > +                   "u-blox,neo-m8"
>> >> > +
>> >> > +- vcc-supply       : Main voltage regulator
>> >> > +
>> >> > +Required properties (DDC):
>> >> > +- reg              : DDC (I2C) slave address
>> >> > +
>> >> > +Required properties (SPI):
>> >> > +- reg              : SPI chip select address
>> >> > +
>> >> > +Required properties (USB):
>> >> > +- reg              : Number of the USB hub port or the USB host-controller port
>> >> > +                  to which this device is attached
>> >> > +
>> >> > +Optional properties:
>> >> > +
>> >> > +- timepulse-gpios  : Time pulse GPIO
>> >> > +- u-blox,extint-gpios      : External interrupt GPIO
>> >>
>> >> This should be interrupts property instead of a gpio.
>> >
>> > Contrary to what the name may suggest, this pin is actually an input
>> > which can be used to control active power or to provide time or
>> > frequency aiding data to the receiver (see section 1.13 in [1]).
>> >
>> > I only added it for completeness as the driver does not use it
>> > currently. Remove, leave as is, or add "input" to the description as in:
>> >
>> >         - u-blox,extint-gpios   : External interrupt input GPIO
>>
>> Yes. You should also define the active level.
>
> The active level appears to be runtime configurable and dependent on the
> selected function. For power control it can be used to control force-on
> (active high), force-off (active low) or both; and for time aiding
> sampling on falling or rising edge is also configurable. And who knows
> what else this pin is used for next time they update the firmware. ;)

Okay.

> Shall I remove the property, or just add "input" as suggested above?

Just add "input".

Rob

^ permalink raw reply

* Re: [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Alexandre Belloni @ 2018-05-31 16:01 UTC (permalink / raw)
  To: Rob Herring
  Cc: devicetree, Linux-ALSA, linux-kernel@vger.kernel.org,
	Nicolas Ferre, Boris Brezillon, Mark Brown, Cristian.Birsan,
	Codrin Ciubotariu, linux-clk,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJ=T0p17hHg6=obtydt7T-yrAeOr7C2XAEnDFQ-c0b5XQ@mail.gmail.com>

On 31/05/2018 09:20:57-0500, Rob Herring wrote:
> On Thu, May 31, 2018 at 5:25 AM, Codrin Ciubotariu
> <codrin.ciubotariu@microchip.com> wrote:
> > On 31.05.2018 03:58, Rob Herring wrote:
> >>
> >> On Fri, May 25, 2018 at 03:34:22PM +0300, Codrin Ciubotariu wrote:
> >>>
> >>> The I2S mux clock can be used to select the I2S input clock. The
> >>> available parents are the peripheral and the generated clocks.
> >>>
> >>> Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> >>> ---
> >>>   .../devicetree/bindings/clock/at91-clock.txt       | 34
> >>> ++++++++++++++++++++++
> >>>   1 file changed, 34 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> b/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> index 51c259a..1c46b3c 100644
> >>> --- a/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
> >>> @@ -90,6 +90,8 @@ Required properties:
> >>>         "atmel,sama5d2-clk-audio-pll-pmc"
> >>>                 at91 audio pll output on AUDIOPLLCLK that feeds the PMC
> >>>                 and can be used by peripheral clock or generic clock
> >>> +       "atmel,sama5d2-clk-i2s-mux":
> >>> +               at91 I2S clock source selection
> >>
> >>
> >> Is this boolean or takes some values. If latter, what are valid values?
> >
> >
> > This is the compatible string of the clock driver.
> 
> Ah, now I remember. AT91 uses fine grained clock nodes in DT. Is there
> still a plan to fix this?
> 

There is still a plan to do that, hopefully soon (I'd like to aim for
the next release or the one after).

I think this one should go in as-is so it can be fixed with all the
other one at once.

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply

* Re: [PATCH v2 00/12] coresight: tmc-etr Transparent buffer management
From: Suzuki K Poulose @ 2018-05-31 16:17 UTC (permalink / raw)
  To: Mathieu Poirier
  Cc: linux-arm-kernel, Linux Kernel Mailing List, Mike Leach,
	Robert Walker, coresight, devicetree, Rob Herring, Frank Rowand
In-Reply-To: <CANLsYkxStH5R0_8WFF1oe=PCCFr4Ko+0J+Xhn-wzopFFDgrRCw@mail.gmail.com>

On 31/05/18 16:36, Mathieu Poirier wrote:
> On 29 May 2018 at 07:15, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:

>> Suzuki K Poulose (12):
>>    coresight: ETM: Add support for Arm Cortex-A73 and Cortex-A35
>>    coresight: tmc: Hide trace buffer handling for file read
>>    coresight: tmc-etr: Do not clean trace buffer
>>    coresight: tmc-etr: Disallow perf mode
>>    coresight: Add helper for inserting synchronization packets
>>    dts: bindings: Restrict coresight tmc-etr scatter-gather mode
>>    dts: juno: Add scatter-gather support for all revisions
>>    coresight: Add generic TMC sg table framework
>>    coresight: Add support for TMC ETR SG unit
>>    coresight: tmc-etr: Add transparent buffer management
>>    coresight: tmc-etr buf: Add TMC scatter gather mode backend
>>    coresight: tmc: Add configuration support for trace buffer size
>>
>>   .../ABI/testing/sysfs-bus-coresight-devices-tmc    |    8 +
>>   .../devicetree/bindings/arm/coresight.txt          |    5 +-
>>   arch/arm64/boot/dts/arm/juno-base.dtsi             |    1 +
>>   drivers/hwtracing/coresight/coresight-etb10.c      |   12 +-
>>   drivers/hwtracing/coresight/coresight-etm4x.c      |   31 +-
>>   drivers/hwtracing/coresight/coresight-priv.h       |   10 +-
>>   drivers/hwtracing/coresight/coresight-tmc-etf.c    |   45 +-
>>   drivers/hwtracing/coresight/coresight-tmc-etr.c    | 1010 ++++++++++++++++++--
>>   drivers/hwtracing/coresight/coresight-tmc.c        |   83 +-
>>   drivers/hwtracing/coresight/coresight-tmc.h        |  110 ++-
>>   drivers/hwtracing/coresight/coresight.c            |    3 +-
>>   11 files changed, 1144 insertions(+), 174 deletions(-)
> 
> Applied after correcting indentation problems and rectifying the
> kernel version and date in "sysfs-bus-coresight-devices-tmc".

Mathieu,

Thanks for the fixups.

Suzuki

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: mtd: explicitly describe nesting partitions
From: Rob Herring @ 2018-05-31 16:20 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
	Marek Vasut, linux-mtd, Jonas Gorski, Rafał Miłecki,
	Brian Norris, David Woodhouse
In-Reply-To: <20180523171448.26234-1-zajec5@gmail.com>

On Wed, May 23, 2018 at 07:14:47PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> Documentation was already saying that fixed and dynamic partitioning can
> be mixed but was missing a clear description and examples. This commit
> adds a proper description of how partitions can be nested and how layout
> descriptions can be mixed.
> 
> This addition is important for partitions that contain subpartitions.
> It's useful to have parent partition registered (e.g. for overwriting
> purposes) as well as children ones (for accessing data). It's also
> required when a single partition uses different partitioning method
> (e.g. vendor custom "firmware" partition with kernel + rootfs).
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> Another example (I couldn't put in Documentation yet) could be:
> 
> flash@0 {
> 	partitions {
> 		compatible = "fixed-partitions";
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 
> 		partition@0 {
> 			label = "bootloader";
> 			reg = <0x0000000 0x0100000>;
> 			read-only;
> 		};
> 
> 		firmware@100000 {
> 			label = "firmware";
> 			reg = <0x0100000 0x0800000>;
> 			compatible = "brcm,trx";
> 		};
> 	};
> };
> 
> It's probably even more realistic one, but we don't describe "brcm,trx"
> binding yet.

This one makes more sense to me than the one you've added because if you 
only have fixed partitions, it seems like most times you could just 
flatten them to 1 level. I suppose having some levels could make doing 
updates easier.

> The purpose of above description would be to:
> 1) Specify fixed partitions (they never change)
> 2) Tell operating system that "firmware" partition uses Broadcom's TRX
>    format which is a container for 2 or 3 subpartitions (usually: kernel
>    and rootfs).
> ---
>  .../devicetree/bindings/mtd/partition.txt          | 25 ++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
> index a8f382642ba9..2214167ce88a 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -14,6 +14,13 @@ method is used for a given flash device. To describe the method there should be
>  a subnode of the flash device that is named 'partitions'. It must have a
>  'compatible' property, which is used to identify the method to use.
>  
> +When a single partition is represented with a DT node (it depends on a used
> +format) it may also be described using above rules ('compatible' and optionally
> +some extra properties / subnodes). It allows describing more complex,
> +hierarchical (multi-level) layouts and should be used if there is some
> +significant relation between partitions or some partition internally uses
> +another partitioning method.
> +
>  Available bindings are listed in the "partitions" subdirectory.
>  
>  
> @@ -73,6 +80,24 @@ flash@0 {
>  		uimage@100000 {
>  			reg = <0x0100000 0x200000>;
>  		};
> +
> +		calibration@200000 {
> +			label = "calibration";
> +			reg = <0x0200000 0x100000>;
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;

You are missing 'ranges' here.

> +
> +			partition@0 {
> +				label = "wifi0";
> +				reg = <0x000000 0x080000>;
> +			};
> +
> +			partition@80000 {
> +				label = "wifi1";
> +				reg = <0x080000 0x080000>;
> +			};
> +		};
>  	};
>  };
>  
> -- 
> 2.13.6
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [PATCH 2/3] clk: bcm: Update and add tingray clock entries
From: Rob Herring @ 2018-05-31 16:25 UTC (permalink / raw)
  To: Ray Jui
  Cc: Michael Turquette, Stephen Boyd, Mark Rutland, linux-clk,
	linux-kernel, bcm-kernel-feedback-list, devicetree,
	linux-arm-kernel, Pramod Kumar
In-Reply-To: <1527266717-8406-3-git-send-email-ray.jui@broadcom.com>

On Fri, May 25, 2018 at 09:45:16AM -0700, Ray Jui wrote:
> Update and add Stingray clock definitions and tables so they match the
> binding document and the latest ASIC datasheet
> 
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
>  drivers/clk/bcm/clk-sr.c           | 135 ++++++++++++++++++++++++++++++++-----
>  include/dt-bindings/clock/bcm-sr.h |  24 +++++--

This goes in the 1st patch.

>  2 files changed, 137 insertions(+), 22 deletions(-)

^ permalink raw reply

* Re: [PATCH 10/11] dt-bindings: misc: add bindings for throttler
From: Rob Herring @ 2018-05-31 16:31 UTC (permalink / raw)
  To: Matthias Kaehlcke
  Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Arnd Bergmann,
	Greg Kroah-Hartman, Mark Rutland, linux-pm, devicetree,
	linux-kernel, Brian Norris, Douglas Anderson
In-Reply-To: <20180525203043.249193-11-mka@chromium.org>

On Fri, May 25, 2018 at 01:30:42PM -0700, Matthias Kaehlcke wrote:

Commit msg?

> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
>  .../devicetree/bindings/misc/throttler.txt    | 41 +++++++++++++++++++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/throttler.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/throttler.txt b/Documentation/devicetree/bindings/misc/throttler.txt
> new file mode 100644
> index 000000000000..92f13e94451a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/throttler.txt
> @@ -0,0 +1,41 @@
> +Throttler driver
> +
> +The Throttler is used for non-thermal throttling of system components like
> +CPUs or devfreq devices.

This all looks very Linux specific and not a h/w device. Perhaps you can 
add hint properties to OPP tables as to what entries can be used for 
throttling, but otherwise this doesn't belong in DT.

^ permalink raw reply

* Re: [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Faiz Abbas @ 2018-05-31 16:35 UTC (permalink / raw)
  To: Tony Lindgren, Tero Kristo
  Cc: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk,
	robh+dt, bcousson, paul
In-Reply-To: <20180531152623.GN5705@atomide.com>

Hi,

On Thursday 31 May 2018 08:56 PM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [180531 06:18]:
>> On 30/05/18 18:54, Tony Lindgren wrote:
>>> * Tero Kristo <t-kristo@ti.com> [180530 15:44]:
>>>> On 30/05/18 18:28, Tony Lindgren wrote:
>>>>> * Tero Kristo <t-kristo@ti.com> [180530 15:18]:
>>>>>> For the OCP if part, I think that is still needed until we switch over to
>>>>>> full sysc driver. clkctrl_offs you probably also need because that is used
>>>>>> for mapping the omap_hwmod against a specific clkctrl clock. Those can be
>>>>>> only removed once we are done with hwmod (or figure out some other way to
>>>>>> assign the clkctrl clock to a hwmod.)
>>>>>
>>>>> Hmm might be worth testing. I thought your commit 70f05be32133
>>>>> ("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
>>>>> already parses the clkctrl from dts?
>>>>
>>>> It maps the clkctrl clock to be used by hwmod, if those are available. We
>>>> didn't add any specific clock entries to DT for mapping the actual clkctrl
>>>> clock without the hwmod_data hints yet though, as that was deemed temporary
>>>> solution only due to transition to interconnect driver. I.e., you would need
>>>> something like this in DT for every device node:
>>>>
>>>> &uart3 {
>>>>    clocks = <l4per_clkctrl UART3_CLK 0>;
>>>>    clock-names = "clkctrl";
>>>> };
>>>>
>>>> ... which is currently not present.
>>>
>>> Hmm is that not the "fck" clkctrl clock we have already in
>>> the dts files for the interconnect target modules?
>>
>> Oh okay, yeah, we could parse that one, but currently it is not done, and is
>> not present for everything either I believe.
>>
>>> We can also use pdata callbacks to pass the clock node if
>>> needed. But I guess I don't quite still understand what we
>>> are missing :)
>>
>> So, what is missing is the glue logic only from the hwmod codebase. Right
>> now this is not supported but should be relatively trivial thing to add if
>> we really want to do this.
> 
> OK let's think about this a bit for v4.19 then.
> 

I am not sure what the conclusion is. Should I try removing the
clkctrl_offsets, clkdm_name, and main_clk?

Thanks,
Faiz

^ permalink raw reply

* Re: [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
From: Faiz Abbas @ 2018-05-31 16:38 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: linux-kernel, devicetree, linux-omap, linux-arm-kernel, linux-clk,
	robh+dt, bcousson, paul, t-kristo
In-Reply-To: <20180531134507.GK5705@atomide.com>

Hi,

On Thursday 31 May 2018 07:15 PM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180531 10:22]:
>> On Wednesday 30 May 2018 08:34 PM, Tony Lindgren wrote:
>>> Looks good to me except I think the reset won't do anything currently
>>> with ti-sysc.c unless you specfify also "ti,hwmods" for the module?
>>>
>>> Can you please check? It might be worth adding the reset function to
>>> ti-sysc.c for non "ti,hwmods" case and that just might remove the
>>> need for any hwmod code for this module.
>>>
>>
>> If I understand correctly, this involves adding a (*reset_module) in
>> ti_sysc_platform_data and defining a ti_sysc_reset_module() in ti-sysc.c
>> similar to ti_sysc_idle_module(). Right?
> 
> Well try moving "ti,hwmods" to the module level first. Then reset will
> happen with enable.

Ok. Let me try that.

Thanks,
Faiz

^ permalink raw reply

* Re: [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Tony Lindgren @ 2018-05-31 16:39 UTC (permalink / raw)
  To: Faiz Abbas
  Cc: Tero Kristo, linux-kernel, devicetree, linux-omap,
	linux-arm-kernel, linux-clk, robh+dt, bcousson, paul
In-Reply-To: <f74763ed-7e27-146b-6856-6be1b2ba630d@ti.com>

* Faiz Abbas <faiz_abbas@ti.com> [180531 16:36]:
> Hi,
> 
> On Thursday 31 May 2018 08:56 PM, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [180531 06:18]:
> >> On 30/05/18 18:54, Tony Lindgren wrote:
> >>> * Tero Kristo <t-kristo@ti.com> [180530 15:44]:
> >>>> On 30/05/18 18:28, Tony Lindgren wrote:
> >>>>> * Tero Kristo <t-kristo@ti.com> [180530 15:18]:
> >>>>>> For the OCP if part, I think that is still needed until we switch over to
> >>>>>> full sysc driver. clkctrl_offs you probably also need because that is used
> >>>>>> for mapping the omap_hwmod against a specific clkctrl clock. Those can be
> >>>>>> only removed once we are done with hwmod (or figure out some other way to
> >>>>>> assign the clkctrl clock to a hwmod.)
> >>>>>
> >>>>> Hmm might be worth testing. I thought your commit 70f05be32133
> >>>>> ("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
> >>>>> already parses the clkctrl from dts?
> >>>>
> >>>> It maps the clkctrl clock to be used by hwmod, if those are available. We
> >>>> didn't add any specific clock entries to DT for mapping the actual clkctrl
> >>>> clock without the hwmod_data hints yet though, as that was deemed temporary
> >>>> solution only due to transition to interconnect driver. I.e., you would need
> >>>> something like this in DT for every device node:
> >>>>
> >>>> &uart3 {
> >>>>    clocks = <l4per_clkctrl UART3_CLK 0>;
> >>>>    clock-names = "clkctrl";
> >>>> };
> >>>>
> >>>> ... which is currently not present.
> >>>
> >>> Hmm is that not the "fck" clkctrl clock we have already in
> >>> the dts files for the interconnect target modules?
> >>
> >> Oh okay, yeah, we could parse that one, but currently it is not done, and is
> >> not present for everything either I believe.
> >>
> >>> We can also use pdata callbacks to pass the clock node if
> >>> needed. But I guess I don't quite still understand what we
> >>> are missing :)
> >>
> >> So, what is missing is the glue logic only from the hwmod codebase. Right
> >> now this is not supported but should be relatively trivial thing to add if
> >> we really want to do this.
> > 
> > OK let's think about this a bit for v4.19 then.
> > 
> 
> I am not sure what the conclusion is. Should I try removing the
> clkctrl_offsets, clkdm_name, and main_clk?

No need to, it's not going to work currently without them.

Regards,

Tony

^ permalink raw reply

* Re: [PATCH 01/13] dt-bindings: net: bluetooth: add support for Realtek Bluetooth chips
From: Rob Herring @ 2018-05-31 16:42 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Marcel Holtmann, Johan Hedberg, Martin Blumenstingl, Jeremy Cline,
	linux-bluetooth, linux-serial, linux-acpi, devicetree
In-Reply-To: <16b7e10b-6816-f441-00e5-9e86d1df33a7@redhat.com>

On Wed, May 30, 2018 at 10:04:37AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 30-05-18 08:42, Marcel Holtmann wrote:
> > Hi Hans,
> > 
> > > This adds the documentation for Bluetooth functionality of the Realtek
> > > RTL8723BS and RTL8723DS.
> > > Both are SDIO wifi chips with an additional Bluetooth module which is
> > > connected via UART to the host.
> > > 
> > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > > Signed-off-by: Jeremy Cline <jeremy@jcline.org>
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > > ---
> > > .../bindings/net/realtek-bluetooth.txt        | 41 +++++++++++++++++++
> > > 1 file changed, 41 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/net/realtek-bluetooth.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.txt b/Documentation/devicetree/bindings/net/realtek-bluetooth.txt
> > > new file mode 100644
> > > index 000000000000..1491329c4cd1
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.txt
> > > @@ -0,0 +1,41 @@
> > > +Realtek Bluetooth Chips
> > > +-----------------------
> > > +
> > > +This documents the binding structure and common properties for serial
> > > +attached Realtek devices.
> > > +
> > > +Serial attached Realtek devices shall be a child node of the host UART
> > > +device the slave device is attached to. See ../serial/slave-device.txt
> > > +for more information
> > > +
> > > +Required properties:
> > > +- compatible: should contain one of the following:
> > > +    * "realtek,rtl8723bs-bluetooth"
> > > +    * "realtek,rtl8723ds-bluetooth"
> > > +
> > > +Optional properties:
> > > +- realtek,config-data: Bluetooth chipset configuration data which is
> > > +			needed for communication (it typically contains
> > > +			board specific settings like the baudrate and
> > > +			whether flow-control is used).
> > > +			This is an array of u8 values.
> > > +- enable-gpios: GPIO specifier, used to enable/disable the BT module
> > > +- reset-gpios: GPIO specifier, used to reset the BT module
> > > +
> > > +
> > > +Example:
> > > +
> > > +&uart {
> > > +	...
> > > +
> > > +	bluetooth {
> > > +		compatible = "realtek,rtl8723bs-bluetooth";
> > > +		enable-gpios = <&gpio 20 GPIO_ACTIVE_HIGH>;
> > > +		reset-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
> > > +		realtek,config-data = /bits/ 8 <
> > > +			0x55 0xab 0x23 0x87 0x29 0x00 0xf4 0x00 0x01 0x01 0xf6 0x00
> > > +			0x02 0x81 0x00 0xfa 0x00 0x02 0x12 0x80 0x0c 0x00 0x10 0x02
> > > +			0x80 0x92 0x04 0x50 0xc5 0xea 0x19 0xe1 0x1b 0xfd 0xaf 0x5f
> > > +			0x01 0xa4 0x0b 0xd9 0x00 0x01 0x0f 0xe4 0x00 0x01 0x08>;
> > > +	};
> > > +};
> > 
> > we actually need to agree on this config-data. As I wrote in an earlier email some time ago, the actual config-data files are just memory portions that will overload the default config area. I wrote tools/rtlfw.c to parse these.
> > 
> > So now I wonder if we can just read the current configuration and run with that when no extra blob is provided. That way it would always work and we might just give the config-data filename here. Mostly this is the for PCM and UART settings anyway.
> 
> I've been thinking about this too and 2 different solutions come to mind.
> 
> Note this is all x86 specific, I think it best to solve this for x86 first
> and then we can apply the lessons learned there to ARM/devicetree when
> someone comes along who wants to hook-up things on ARM.
> 
> My first idea was to stick with a config blob using the firmware_load
> mechanism, but to add a postfix to the filename based on the ACPI
> HID (hardware-id) of the serdev device, so in practice this means
> we would try to load:
> 
> /lib/firmware/rtl_bt/rtl8723bs_config-OBDA8723.bin
> 
> On most x86 devices, so far all my testing on a bunch of different
> devices has shown that the same config works for all x86 devices
> (I took the config from a Chuwi Vi8 tablet which uses 3000000bps
> + hardware flowcontrol).
> 
> This way we can put the config in linux-firmware, without it
> getting loaded on ARM boards where it might very well be wrong.
> 
> 
> My second idea is to include a default config inside the driver,
> which can be optionally overridden by a file in
> /lib/firmware/rtl_bt and/or dt. Combined with module-options to
> override the baudrate and flowcontrol setting (and patch the
> builtin config accordingly).
> 
> 
> Your idea to read back the config from the device is also
> interesting, but I don't think that will gain us anything because
> AFAIK the whole purpose of the board specific config file
> bits is that the chip lack eeprom space to store this info,
> so we will just always get some generic defaults.
> 
> 
> I've run your rtlfw tool on a bunch of different config files and
> there are a lot of unknown fields, and even of the known fields
> I don't think we understand all the bits. So all in all the
> config file is a bit of a black box and as such I believe it
> would be best to just treat it as such and I personally
> prefer my first idea, which is to add a postfix to the
> firmware filename request, so on x86 load:
> 
> /lib/firmware/rtl_bt/rtl8723bs_config-OBDA8723.bin
> 
> And on devicetree we could postfix things with the machine
> model string (as returned by  of_flat_dt_get_machine_name())

If the firmware file is going to depend on the DT, then you might as 
well just put the data into the DT.

There's a similar issue on QCom Dragonboards. The WiFi (and BT?) 
firmware files are supposedly board specific, so folks don't want to put 
them into linux-firmware. But it also seems to be unknown as to which 
parts are board specific are not.

Rob

^ permalink raw reply

* Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for SR thermal
From: Rob Herring @ 2018-05-31 16:48 UTC (permalink / raw)
  To: Srinath Mannam
  Cc: Zhang Rui, Eduardo Valentin, Mark Rutland, devicetree,
	linux-kernel, bcm-kernel-feedback-list, Pramod Kumar
In-Reply-To: <1527486084-4636-2-git-send-email-srinath.mannam@broadcom.com>

On Mon, May 28, 2018 at 11:11:22AM +0530, Srinath Mannam wrote:
> From: Pramod Kumar <pramod.kumar@broadcom.com>
> 
> Add binding document for supported thermal implementation
> in Stingray.
> 
> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Reviewed-by: Srinath Mannam <srinath.mannam@broadcom.com>
> ---
>  .../bindings/thermal/brcm,sr-thermal.txt           | 45 ++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
> 
> diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
> new file mode 100644
> index 0000000..33f9e11
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
> @@ -0,0 +1,45 @@
> +* Broadcom Stingray Thermal
> +
> +This binding describes thermal sensors that is part of Stingray SoCs.
> +
> +Required properties:
> +- compatible : Must be "brcm,sr-thermal"
> +- reg : memory where tmon data will be available.

What type of memory is this?

> +
> +Example:
> +	tmons {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		tmon_ihost0: thermal@8f100000 {
> +			compatible = "brcm,sr-thermal";
> +			reg = <0x8f100000 0x4>;
> +		};

Convince me that you need a node per register. This can all be 
accomplished with a single node and either a single reg entry or a 
series of reg entries.

> +
> +		tmon_ihost1: thermal@8f100004 {
> +			compatible = "brcm,sr-thermal";
> +			reg = <0x8f100004 0x4>;
> +		};
> +
> +		tmon_ihost2: thermal@8f100008 {
> +			compatible = "brcm,sr-thermal";
> +			reg = <0x8f100008 0x4>;
> +		};
> +
> +		tmon_ihost3: thermal@8f10000c {
> +			compatible = "brcm,sr-thermal";
> +			reg = <0x8f10000c 0x4>;
> +		};
> +
> +		tmon_crmu: thermal@8f100010 {
> +			compatible = "brcm,sr-thermal";
> +			reg = <0x8f100010 0x4>;
> +		};
> +
> +		tmon_nitro: thermal@8f100014 {
> +			compatible = "brcm,sr-thermal";
> +			reg = <0x8f100014 0x4>;
> +		};
> +	};
> -- 
> 2.7.4
> 

^ permalink raw reply

* Re: [PATCH v2 2/3] USB: DT probing support to ehci-npcm7xx
From: Sergei Shtylyov @ 2018-05-31 16:49 UTC (permalink / raw)
  To: avifishman70, gregkh, stern
  Cc: tmaimon77, venture, yuenn, brendanhiggins, mathias.nyman,
	bjorn.andersson, jhogan, albeu, chunfeng.yun, tony, baolu.lu,
	elder, digetx, kstewart, hdegoede, linux-kernel, linux-usb,
	openbmc, robh+dt, mark.rutland, devicetree
In-Reply-To: <1527774046-7952-3-git-send-email-avifishman70@gmail.com>

Hello!

On 05/31/2018 04:40 PM, avifishman70@gmail.com wrote:

> From: Avi Fishman <AviFishman70@gmail.com>
> 
> Device Tree documentation for Nuvoton npcm7xx EHCI.
> 
> Signed-off-by: Avi Fishman <AviFishman70@gmail.com>
> ---
>  Documentation/devicetree/bindings/usb/npcm7xx-usb.txt | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt b/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
> new file mode 100644
> index 000000000000..dec67d4d4c30
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/npcm7xx-usb.txt
> @@ -0,0 +1,17 @@
> +Nuvoton NPCM7XX SoC USB controllers:
> +-----------------------------
> +
> +EHCI:
> +-----
> +
> +Required properties:
> +- compatible: "nuvoton,npcm750-ehci"
> +- interrupts: Should contain the EHCI interrupt
> +
> +Example:
> +
> +	ehci@e1800000 {

  The node should be named "usb@e1800000" as the DT spec. requires the generic
node names.

[...]

MBR, Sergei

^ permalink raw reply

* Re: [PATCH] dt-bindings: arm: Remove obsolete insignal-boards.txt
From: Rob Herring @ 2018-05-31 16:50 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Kukjin Kim, Mark Rutland, linux-arm-kernel, linux-samsung-soc,
	devicetree, linux-kernel
In-Reply-To: <20180528185310.21971-1-krzk@kernel.org>

On Mon, May 28, 2018 at 08:53:10PM +0200, Krzysztof Kozlowski wrote:
> The compatibles mentioned in insignal-boards.txt are already documented
> under devicetree/bindings/arm/samsung/samsung-boards.txt.  Also the
> contents of insignal-boards.txt is not accurate, e.g. does not mention
> Arndale boards.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
>  Documentation/devicetree/bindings/arm/insignal-boards.txt | 8 --------
>  1 file changed, 8 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/arm/insignal-boards.txt

Reviewd-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* [PATCH v2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Jagan Teki @ 2018-05-31 16:51 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Michael Trimarchi, Icenowy Zheng
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki

Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
- WiFi SDIO interface is connected to MMC1
- WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
- WiFi WL-WAKE-AP pin connected to gpio PL3
- 32kHz external oscillator gate clock from RTC

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
Changes for v2:
- Move external rtc clock nodes into main rtc node definition
  of sun50i-a64.dtsi

 .../dts/allwinner/sun50i-a64-amarula-relic.dts     | 31 ++++++++++++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      |  3 +++
 2 files changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index ce4a256ff086..eac4793c8502 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -21,12 +21,43 @@
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
+
+	wifi_pwrseq: wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rtc 1>;
+		clock-names = "ext_clock";
+		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
+	};
 };
 
 &ehci0 {
 	status = "okay";
 };
 
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+	vmmc-supply = <&reg_dcdc1>;
+	/*
+	 * Schematic shows both dldo4 and eldo1 connected for vcc-io-wifi, but
+	 * dldo4 connection shows DNP(Do Not Populate) and eldo1 connected with
+	 * 0Ohm register to vcc-io-wifi so eldo1 is used.
+	 */
+	vqmmc-supply = <&reg_eldo1>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+
+	brcmf: wifi@1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+		interrupt-parent = <&r_pio>;
+		interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>;	/* WL-WAKE-AP: PL3 */
+		interrupt-names = "host-wake";
+	};
+};
+
 &mmc2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc2_pins>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..82516aec4153 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -634,6 +634,9 @@
 			reg = <0x01f00000 0x54>;
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+			clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
+			clocks = <&osc32k>;
+			#clock-cells = <1>;
 		};
 
 		r_intc: interrupt-controller@1f00c00 {
-- 
2.14.3

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox