* Re: [PATCH v5 1/8] dt-bindings: fsi: Add SBEFIFO documentation
From: Rob Herring @ 2017-11-20 21:35 UTC (permalink / raw)
To: Eddie James
Cc: linux-kernel, gregkh, devicetree, mark.rutland, bradleyb, cbostic,
joel, Edward A. James
In-Reply-To: <1511207217-14075-2-git-send-email-eajames@linux.vnet.ibm.com>
On Mon, Nov 20, 2017 at 01:46:50PM -0600, Eddie James wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
>
> Document the bindings for the SBE CFAM device. SBE devices are
> located on a CFAM off an FSI bus.
>
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> ---
> .../devicetree/bindings/fsi/ibm,p9-sbefifo.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-sbefifo.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: net: add mt76 wireless device binding
From: Rob Herring @ 2017-11-20 21:34 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
kvalo-sgV2jX0FEOL9JmXXK+q4OQ, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171120193549.80831-2-nbd-Vt+b4OUoWG0@public.gmane.org>
On Mon, Nov 20, 2017 at 08:35:47PM +0100, Felix Fietkau wrote:
> Add documentation describing how device tree can be used to configure
> wireless chips supported by the mt76 driver.
>
> Signed-off-by: Felix Fietkau <nbd-Vt+b4OUoWG0@public.gmane.org>
> ---
> .../bindings/net/wireless/mediatek,mt76.txt | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: i2c: update documentation for the Meson-AXG
From: Rob Herring @ 2017-11-20 21:33 UTC (permalink / raw)
To: Yixun Lan
Cc: Wolfram Sang, Mark Rutland, linux-i2c, devicetree, Kevin Hilman,
Neil Armstrong, Jerome Brunet, Carlo Caione, Jian Hu,
linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20171120145415.6581-2-yixun.lan@amlogic.com>
On Mon, Nov 20, 2017 at 10:54:11PM +0800, Yixun Lan wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Update the doc to explicitly add Meson-AXG to support list
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> Documentation/devicetree/bindings/i2c/i2c-meson.txt | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [RESEND PATCH v3 1/2] documentation: Add compatibles for Amlogic Meson AXG pin controllers
From: Rob Herring @ 2017-11-20 21:32 UTC (permalink / raw)
To: Yixun Lan
Cc: Kevin Hilman, Mark Rutland, Linus Walleij, Neil Armstrong,
Jerome Brunet, Carlo Caione, Xingyu Chen, devicetree, linux-gpio,
linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <20171120102354.5354-2-yixun.lan@amlogic.com>
On Mon, Nov 20, 2017 at 06:23:53PM +0800, Yixun Lan wrote:
> From: Xingyu Chen <xingyu.chen@amlogic.com>
>
> Add compatibles for Amlogic Meson AXG pin controllers
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] DT: i2c: W83773G is a trivial device
From: Rob Herring @ 2017-11-20 21:31 UTC (permalink / raw)
To: Lei YU; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1511157223-7162-1-git-send-email-mine260309-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Nov 20, 2017 at 01:53:43PM +0800, Lei YU wrote:
> Signed-off-by: Lei YU <mine260309-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/trivial-devices.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: Add binding for Ilitek ILI9225 display panels
From: Rob Herring @ 2017-11-20 21:30 UTC (permalink / raw)
To: David Lechner; +Cc: Mark Rutland, devicetree, linux-kernel, dri-devel
In-Reply-To: <1511122328-31133-3-git-send-email-david@lechnology.com>
On Sun, Nov 19, 2017 at 02:12:06PM -0600, David Lechner wrote:
> This adds a new binding for display panels that use an Ilitek ILI9225
> controller.
>
> The "ilitek,ili9225-2.2in-176x220" device listed has no identification
> markings whatsoever and an hour of googling turned up nothing, hence the use
> of the size and resolution in the name instead of a model name.
>
> An example of this nameless device can be found at:
> https://github.com/Nkawu/TFT_22_ILI9225
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> v2 changes:
> * renamed compatible string based on feedback
>
> .../devicetree/bindings/display/ilitek,ili9225.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: Add vendor prefix for ilitek
From: Rob Herring @ 2017-11-20 21:29 UTC (permalink / raw)
To: David Lechner; +Cc: Mark Rutland, devicetree, linux-kernel, dri-devel
In-Reply-To: <1511122328-31133-2-git-send-email-david@lechnology.com>
On Sun, Nov 19, 2017 at 02:12:05PM -0600, David Lechner wrote:
> This adds the vendor prefix ilitek for ILI Technology Corporation (ILITEK).
>
> This prefix is already used several places and I will be adding more.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> v2 changes:
> * New patch in v2
>
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: iio: add Intersil isl76683 light sensor bindings
From: Rob Herring @ 2017-11-20 21:29 UTC (permalink / raw)
To: Christoph Fritz
Cc: Jonathan Cameron, Peter Meerwald-Stadler,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1511047230-7021-3-git-send-email-chf.fritz-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Sun, Nov 19, 2017 at 12:20:29AM +0100, Christoph Fritz wrote:
> This patch adds documentation of device tree bindings for Intersil
> isl76683 light sensor.
>
> Signed-off-by: Christoph Fritz <chf.fritz-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> .../devicetree/bindings/iio/light/isl76683.txt | 26 ++++++++++++++++++++++
> .../devicetree/bindings/property-units.txt | 1 +
> 2 files changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/light/isl76683.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/light/isl76683.txt b/Documentation/devicetree/bindings/iio/light/isl76683.txt
> new file mode 100644
> index 0000000..b1a8a67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/isl76683.txt
> @@ -0,0 +1,26 @@
> +* ISL76683 ambient light sensor
> +
> +http://www.intersil.com/content/dam/Intersil/documents/isl7/isl76683.pdf
> +
> +Required properties:
> +
> + - compatible: must be "isil,isl76683"
> + - reg: the I2C address of the sensor
> + - interrupt-parent: should be the phandle for the interrupt controller
> + - interrupts: interrupt mapping for GPIO IRQ
> +
> +Optional properties:
> +
> + - isil,external-resistor-kilo-ohms: integer in kilo Ohms of external resistor
> + R_ext. Valid values are from 1 to 1000. If not supplied, 100 kilo Ohms
> + will be assumed.
> +
> +Example:
> +
> +isl76683@44 {
> + compatible = "isil,isl76683";
> + reg = <0x44>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
> + isil,external-resistor-kilo-ohms = <50>;
> +};
> diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt
> index 45ce054..5f9c71a 100644
> --- a/Documentation/devicetree/bindings/property-units.txt
> +++ b/Documentation/devicetree/bindings/property-units.txt
> @@ -28,6 +28,7 @@ Electricity
> -microamp-hours : micro amp-hours
> -ohms : Ohms
> -micro-ohms : micro Ohms
> +-kilo-ohms : kilo Ohms
Ohms would be enough range for you. I'd prefer not to add additional
units just because. Then we'll have folks just pick whatever they
prefer.
The cases we already have are either because they existed prior to
writing this doc or we needed the range/resolution.
> -microwatt-hours: micro Watt-hours
> -microvolt : micro volts
> -picofarads : picofarads
> --
> 2.1.4
>
^ permalink raw reply
* Re: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node
From: Palmer Dabbelt @ 2017-11-20 21:28 UTC (permalink / raw)
Cc: mark.rutland, robh+dt, devicetree, patches, linux-kernel,
j.neuschaefer
In-Reply-To: <20171120202856.nptoirhm5luiamt7@latitude>
On Mon, 20 Nov 2017 12:28:56 PST (-0800), j.neuschaefer@gmx.net wrote:
> On Mon, Nov 20, 2017 at 11:50:00AM -0800, Palmer Dabbelt wrote:
>> The RISC-V privileged ISA mandates the presence of an SBI, but there's
>> no reason not to put it in the device tree. This would allow us to
>> possibly remove the SBI later.
>
> Thanks!
>
>>
>> CC: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
>> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
>> ---
>> .../devicetree/bindings/firmware/riscv.sbi.txt | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/firmware/riscv.sbi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/riscv.sbi.txt b/Documentation/devicetree/bindings/firmware/riscv.sbi.txt
>> new file mode 100644
>> index 000000000000..42384d5d52cf
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/firmware/riscv.sbi.txt
>
> Nit: Other bindings use either a comma (as in the compatible string,
> "riscv,sbi.txt") or a dash (vendor-product.txt, "riscv-sbi.txt") in the
> file name.
That was just a typo, I'll fix it.
>> @@ -0,0 +1,20 @@
>> +RISC-V Supervisor Binary Interface (SBI)
>> +
>> +The RISC-V privileged ISA specification mandates the presence of a supervisor
>> +binary interface that performs some operations which might otherwise require
>> +particularly complicated instructions. This interface includes
>> +inter-processor interrupts, TLB flushes, i-cache and TLB shootdowns, a
>> +console, and power management.
>> +
>> +Required properties:
>> +- compatible: must contain one of the following
>> + * "riscv,sbi" for the SBI defined by the privileged specification of the
>> + system.
>
> "of the system" seems to imply that different RISC-V systems (different
> RISC-V implementations) can have different privileged specifications.
Actually, that was intentional -- I wrote it this way because different RISC-V
systems do have different privileged specifications. The RISC-V specifications
aren't frozen in time, they're just guaranteed to be compatible in the future.
For example, the user ISA document has been updated multiple times (the C spec,
eliminating some unspecified behavior) and will continue to be updated (V and
other extensions, the memory model). The privileged spec will be updated in a
compatible way just like the user spec will be -- I know there's at least
hypervisor support in the works, and I saw some things to remove undefined
behavior go past as well.
In a similar fashion, the ABI and SBI will continue to evolve. For example,
we'll probably add new system calls to extend the user ABI and new hyper calls
to extend the SBI.
> I think it's better to refer to concrete documents, that don't depend on
> the rest of the system, instead. Either:
>
> * "riscv,sbi" for the SBI defined by the RISC-V Privileged ISA Specification.
>
> Or something like:
>
> * "sifive,sbi" for the SBI defined by SiFive document XYZ.
>
>
> [ I know that there currently is no SBI spec, because the chapter has
> been removed from the Priv Spec, but this can be fixed later, once
> the final name of the document describing the SBI is clear. ]
Ya, well, that's just a bug :). There'll eventually be a spec, but I don't
think it changes the wording here.
>
>> +
>> +Example:
>> +
>> +firmware {
>> + sbi {
>> + compatible = "riscv,sbi";
>> + };
>> +};
>> --
>
>
> Thanks,
> Jonathan Neuschäfer
>
> --
> You received this message because you are subscribed to the Google Groups "RISC-V Patches" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to patches+unsubscribe@groups.riscv.org.
> To post to this group, send email to patches@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/patches/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/patches/20171120202856.nptoirhm5luiamt7%40latitude.
> For more options, visit https://groups.google.com/a/groups.riscv.org/d/optout.
^ permalink raw reply
* Re: [PATCH v2] pwm: imx: Allow keeping the PWM active during suspend
From: Rob Herring @ 2017-11-20 21:19 UTC (permalink / raw)
To: Fabio Estevam
Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
linux-lFZ/pmaqli7XmaaqVzeoHQ, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1511015768-14140-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, Nov 18, 2017 at 12:36:08PM -0200, Fabio Estevam wrote:
> In some systems it is desirable to keep the PWM active during system
> suspend.
>
> One use case is the imx6q-cubox-i board, which has an LED driven by PWM.
> When the system goes into suspend the PWM block is disabled by default,
> the PWM pin goes to zero and turn on the LED during suspend, which is
> not really the behaviour we want to see.
Seems to me the default behavior should be LEDs are off in suspend and
you'd add a property to enable them if desired.
You problem to me sounds like something that should be fixed in the pwm
and/or pwm-led drivers.
>
> By keeping the PWM enabled during suspend the pwm-leds driver sets
> the brightness to zero in suspend and then the LED is turned off as
> expected.
>
> Introduce the 'fsl,active-in-suspend' property to indicate that the
> PWM will stay active during suspend.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] dt-bindings: trivial-devices: Remove fsl,mc13892
From: Rob Herring @ 2017-11-20 21:10 UTC (permalink / raw)
To: Jonathan Neuschäfer; +Cc: devicetree, linux-kernel, Mark Rutland
In-Reply-To: <20171118022232.16835-1-j.neuschaefer@gmx.net>
On Sat, Nov 18, 2017 at 03:22:32AM +0100, Jonathan Neuschäfer wrote:
> This device's bindings are not trivial: Additional properties are
> documented in in Documentation/devicetree/bindings/mfd/mc13xxx.txt.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> ---
> Documentation/devicetree/bindings/trivial-devices.txt | 1 -
> 1 file changed, 1 deletion(-)
Applied.
Rob
^ permalink raw reply
* Re: [PATCH v3 2/3] leds: Add driver for Qualcomm LPG
From: Bjorn Andersson @ 2017-11-20 21:10 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Richard Purdie, Pavel Machek, linux-kernel, linux-leds,
linux-arm-msm, Rob Herring, Mark Rutland, devicetree, Fenglin Wu
In-Reply-To: <19018aa2-c460-1d5e-8dd2-1cfa557be2f2@gmail.com>
On Sun 19 Nov 13:36 PST 2017, Jacek Anaszewski wrote:
> Hi Bjorn,
>
> Thanks for the patch. Please refer to my comments in the code.
>
> On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
[..]
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index 52ea34e337cd..ccc3aa4b2474 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -651,6 +651,13 @@ config LEDS_POWERNV
> > To compile this driver as a module, choose 'm' here: the module
> > will be called leds-powernv.
> >
> > +config LEDS_QCOM_LPG
> > + tristate "LED support for Qualcomm LPG"
> > + depends on LEDS_CLASS
>
> You were mentioning that this driver is for a MFD child block,
> so we should probably depend on the parent MFD driver?
>
There's no build time dependency between the two, so it's not strictly
necessary.
Adding a dependency on MFD_SPMI_PMIC would indirectly add a dependency
on ARCH_QCOM, which limit build testing and stop some static code
checkers to check the driver.
So, unless you strongly object I would prefer not to mention the MFD.
> > + help
> > + This option enables support for the Light Pulse Generator found in a
> > + wide variety of Qualcomm PMICs.
> > +
[..]
> > diff --git a/drivers/leds/leds-qcom-lpg.c b/drivers/leds/leds-qcom-lpg.c
[..]
> > +#define LPG_PATTERN_CONFIG_REG 0x40
> > +#define LPG_SIZE_CLK_REG 0x41
> > +#define LPG_PREDIV_CLK_REG 0x42
> > +#define PWM_TYPE_CONFIG_REG 0x43
> > +#define PWM_VALUE_REG 0x44
> > +#define PWM_ENABLE_CONTROL_REG 0x46
> > +#define PWM_SYNC_REG 0x47
> > +#define LPG_RAMP_DURATION_REG 0x50
> > +#define LPG_HI_PAUSE_REG 0x52
> > +#define LPG_LO_PAUSE_REG 0x54
> > +#define LPG_HI_IDX_REG 0x56
> > +#define LPG_LO_IDX_REG 0x57
> > +#define PWM_SEC_ACCESS_REG 0xd0
> > +#define PWM_DTEST_REG(x) (0xe2 + (x) - 1)
> > +
> > +#define TRI_LED_SRC_SEL 0x45
> > +#define TRI_LED_EN_CTL 0x46
> > +#define TRI_LED_ATC_CTL 0x47
> > +
> > +#define LPG_LUT_REG(x) (0x40 + (x) * 2)
> > +#define RAMP_CONTROL_REG 0xc8
>
> Please add QCOM_ namespacing prefix to the macros.
> At least PWM prefix is reserved for pwm subsystem.
>
Will fix.
[..]
> > +static void lpg_calc_freq(struct lpg_channel *chan, unsigned int period_us)
> > +{
> > + int n, m, clk, div;
> > + int best_m, best_div, best_clk;
> > + unsigned int last_err, cur_err, min_err;
> > + unsigned int tmp_p, period_n;
> > +
> > + if (period_us == chan->period_us)
> > + return;
> > +
> > + /* PWM Period / N */
> > + if (period_us < ((unsigned int)(-1) / NSEC_PER_USEC)) {
> > + period_n = (period_us * NSEC_PER_USEC) >> 6;
> > + n = 6;
> > + } else {
> > + period_n = (period_us >> 9) * NSEC_PER_USEC;
> > + n = 9;
> > + }
>
> Please provide macros for 6 and 9 magic numbers.
>
They really aren't magic numbers, they represent the number of bits of
resolution, referred to as "size" in the rest of the driver.
I'll replace "n" with "pwm_size" to clarify this. Ok?
[..]
> > +static void lpg_apply_freq(struct lpg_channel *chan)
> > +{
> > + unsigned long val;
> > + struct lpg *lpg = chan->lpg;
> > +
> > + if (!chan->enabled)
> > + return;
> > +
> > + /* Clock register values are off-by-one from lpg_clk_table */
> > + val = chan->clk + 1;
> > +
> > + if (chan->pwm_size == 9)
> > + val |= lpg->data->pwm_9bit_mask;
> > +
> > + regmap_write(lpg->map, chan->base + LPG_SIZE_CLK_REG, val);
> > +
> > + val = chan->pre_div << 5 | chan->pre_div_exp;
> > + regmap_write(lpg->map, chan->base + LPG_PREDIV_CLK_REG, val);
>
> Please provide macros for 5 and 9.
>
5 definitely deserves a macro.
9 is, as above, the number of bits of resolution (or "size of the pwm").
Is there a name different than "pwm_size" that would make this more
obvious?
[..]
> > +static void lpg_brightness_set(struct led_classdev *cdev,
> > + enum led_brightness value)
> > +{
[..]
> > + /* Trigger start of ramp generator(s) */
> > + if (lut_mask)
> > + lpg_lut_sync(lpg, lut_mask);
>
> We need some synchronization while changing device state in
> few steps, to prevent troubles when we are preempted by other
> process in the middle. spin_lock() in this case since it seems
> that we are not going to sleep while accessing device registers.
>
You're right, we need to protect the TRILED during the read-modify-write
of the enable bits and we also need a lock around the allocation of bits
in the LUT block. Will fix this.
As far as I can see the framework is expected to protect me from
concurrent accesses on the same LED though.
[..]
> > +static int lpg_add_led(struct lpg *lpg, struct device_node *np)
> > +{
> > + struct lpg_led *led;
> > + const char *state;
> > + int sources;
> > + int size;
> > + u32 chan;
> > + int ret;
> > + int i;
> > +
> > + sources = of_property_count_u32_elems(np, "led-sources");
> > + if (sources <= 0) {
> > + dev_err(lpg->dev, "invalid led-sources of %s\n",
> > + np->name);
> > + return -EINVAL;
> > + }
> > +
> > + size = sizeof(*led) + sources * sizeof(struct lpg_channel*);
>
> To fix checkpatch.pl complaint:
>
> s/lpg_channel*/lpg_channel */
>
Sorry, will fix.
> > + led = devm_kzalloc(lpg->dev, size, GFP_KERNEL);
> > + if (!led)
> > + return -ENOMEM;
> > +
> > + led->lpg = lpg;
> > + led->num_channels = sources;
> > +
> > + for (i = 0; i < sources; i++) {
> > + ret = of_property_read_u32_index(np, "led-sources",
> > + i, &chan);
> > + if (ret || !chan || chan > lpg->num_channels) {
> > + dev_err(lpg->dev,
> > + "invalid led-sources of %s\n",
> > + np->name);
> > + return -EINVAL;
> > + }
> > +
> > + led->channels[i] = &lpg->channels[chan - 1];
> > +
> > + led->channels[i]->in_use = true;
> > + }
> > +
> > + /* Use label else node name */
> > + led->cdev.name = of_get_property(np, "label", NULL) ? : np->name;
>
> Documentation/leds/leds-class.txt states that LED class device name
> pattern is devicename:colour:function.
>
> This is not explicitly stated in the common LED DT bindings, but label
> should be prepended with devicename by the driver.
I was under the impression that "devicename" referred to the board name,
but I presume then that this refer to the name of the "LED hardware"?
> Not all LED class drivers adhere to this rule and we have some mess in
> this area currently, but we will fix it soon I hope.
>
I presume the default name should be built on the form of
dev_name(dev)::of_node->name then?
Unfortunately I can't find a single driver that does this, so please
let me know the format you would like and I'll update the driver with
this.
> > + led->cdev.default_trigger = of_get_property(np, "linux,default-trigger", NULL);
> > + led->cdev.brightness_set = lpg_brightness_set;
> > + led->cdev.brightness_get = lpg_brightness_get;
> > + led->cdev.blink_set = lpg_blink_set;
> > + led->cdev.max_brightness = 255;
>
> You can skip this line, since it will be set to LED_FULL
> in case passed 0 to led_classdev_init().
>
Convenient.
Thank you for the review!
Regards,
Bjorn
^ permalink raw reply
* Re: [RFC v1 8/8] dt-bindings: net: bluetooth: add support for Realtek Bluetooth chips
From: Rob Herring @ 2017-11-20 21:09 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
marcel-kz+m5ild9QBg9hUCZPvPmw, gustavo-THi1TnShQwVAfugRpC6u6w,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jslaby-IBi9RG/b67k,
johan-DgEjT+Ai2ygdnm+yROfE0A, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ
In-Reply-To: <20171117223543.32429-9-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Fri, Nov 17, 2017 at 11:35:43PM +0100, Martin Blumenstingl wrote:
> 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-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> .../devicetree/bindings/net/realtek-bluetooth.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 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..c919e06469f8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.txt
> @@ -0,0 +1,31 @@
> +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:
> +- disable-gpios: GPIO specifier, used to enable/disable the BT module
We generally use 'enable-gpios' or 'powerdown-gpios' even if the h/w
name is somewhat different.
> +- reset-gpios: GPIO specifier, used to reset the BT module
> +
> +
> +Example:
> +
> +&uart {
> + ...
> +
> + bluetooth {
> + compatible = "realtek,rtl8723bs-bluetooth";
> + disable-gpios = <&gpio 20 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
> + };
> +};
> --
> 2.15.0
>
^ permalink raw reply
* Re: [PATCH v8 2/3] arm: dts: add Nuvoton NPCM750 device tree
From: Rob Herring @ 2017-11-20 21:07 UTC (permalink / raw)
To: Brendan Higgins
Cc: linux, mark.rutland, tmaimon77, avifishman70, raltherr,
f.fainelli, julien.thierry, devicetree, linux-kernel,
linux-arm-kernel, openbmc
In-Reply-To: <20171117190747.21642-3-brendanhiggins@google.com>
On Fri, Nov 17, 2017 at 11:07:46AM -0800, Brendan Higgins wrote:
> Add a common device tree for all Nuvoton NPCM750 BMCs and a board
> specific device tree for the NPCM750 (Poleg) evaluation board.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> Reviewed-by: Tomer Maimon <tmaimon77@gmail.com>
> Reviewed-by: Avi Fishman <avifishman70@gmail.com>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
> Tested-by: Tomer Maimon <tmaimon77@gmail.com>
> Tested-by: Avi Fishman <avifishman70@gmail.com>
> ---
> Changes since v7:
> - Added arm,shared-override to l2 cache
> - Cleaned up node names
> - Cleaned up ranges properties
> - Fixed address for nuvoton,npcm750-timer
> - Dropped watchdog nodes for now since the properties in them are wrong
> ---
> .../arm/cpu-enable-method/nuvoton,npcm7xx-smp | 42 +++++
> .../devicetree/bindings/arm/npcm/npcm.txt | 6 +
> arch/arm/boot/dts/nuvoton-npcm750-evb.dts | 44 ++++++
> arch/arm/boot/dts/nuvoton-npcm750.dtsi | 171 +++++++++++++++++++++
> include/dt-bindings/clock/nuvoton,npcm7xx-clks.h | 39 +++++
> 5 files changed, 302 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/nuvoton,npcm7xx-smp
> create mode 100644 Documentation/devicetree/bindings/arm/npcm/npcm.txt
> create mode 100644 arch/arm/boot/dts/nuvoton-npcm750-evb.dts
> create mode 100644 arch/arm/boot/dts/nuvoton-npcm750.dtsi
> create mode 100644 include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCHv2] of: Document exactly what of_find_node_by_name() puts
From: Rob Herring @ 2017-11-20 20:44 UTC (permalink / raw)
To: Stephen Boyd
Cc: Frank Rowand, linux-kernel, linux-doc, devicetree, Randy Dunlap
In-Reply-To: <20171117165321.18591-1-sboyd@codeaurora.org>
On Fri, Nov 17, 2017 at 08:53:21AM -0800, Stephen Boyd wrote:
> It isn't clear if this function of_node_put()s the 'from'
> argument, or the node it searches. Clearly indicate which
> variable is touched. Fold in some more fixes from Randy too
> because we're in the area.
>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> Changes from v1:
> * Fold in Randy's fixes
>
> drivers/of/base.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: da7218: Correct IRQ level in DT binding example
From: Rob Herring @ 2017-11-20 20:44 UTC (permalink / raw)
To: Adam Thomson
Cc: Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Mark Rutland, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Support Opensource
In-Reply-To: <c57eabe7cd6bb5a5466c774725c5150cc33d1ab5.1510930791.git.Adam.Thomson.Opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
On Fri, Nov 17, 2017 at 03:09:28PM +0000, Adam Thomson wrote:
> Current DT binding documentation shows an example where the IRQ
> for the device is chosen to be ACTIVE_HIGH. This is incorrect as
> the device only supports ACTIVE_LOW, so this commit fixes that
> discrepancy.
>
> Signed-off-by: Adam Thomson <Adam.Thomson.Opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/sound/da7218.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: da7219: Correct IRQ level in DT binding example
From: Rob Herring @ 2017-11-20 20:44 UTC (permalink / raw)
To: Adam Thomson
Cc: Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Mark Rutland, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Support Opensource
In-Reply-To: <e21b3fdd673d9baf8b4872d251df57b32b6149f6.1510930791.git.Adam.Thomson.Opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
On Fri, Nov 17, 2017 at 03:09:27PM +0000, Adam Thomson wrote:
> Current DT binding documentation shows an example where the IRQ
> for the device is chosen to be ACTIVE_HIGH. This is incorrect as
> the device only supports ACTIVE_LOW, so this commit fixes that
> discrepancy.
>
> Signed-off-by: Adam Thomson <Adam.Thomson.Opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/sound/da7219.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 7/7] can: rcar_canfd: document r8a77995 (R-Car D3) compatibility strings
From: Rob Herring @ 2017-11-20 20:43 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc, linux-can, devicetree, wsa, horms, geert,
magnus.damm, chris.paterson2, ramesh.shanmugasundaram
In-Reply-To: <1510915289-15059-8-git-send-email-ulrich.hecht+renesas@gmail.com>
On Fri, Nov 17, 2017 at 11:41:29AM +0100, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
> ---
> Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 6/7] can: rcar_can: document r8a77995 (R-Car D3) compatibility strings
From: Rob Herring @ 2017-11-20 20:42 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc, linux-can, devicetree, wsa, horms, geert,
magnus.damm, chris.paterson2, ramesh.shanmugasundaram
In-Reply-To: <1510915289-15059-7-git-send-email-ulrich.hecht+renesas@gmail.com>
On Fri, Nov 17, 2017 at 11:41:28AM +0100, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
> ---
> Documentation/devicetree/bindings/net/can/rcar_can.txt | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/3] DT: leds: Add Qualcomm Light Pulse Generator binding
From: Jacek Anaszewski @ 2017-11-20 20:35 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Richard Purdie, Pavel Machek, Rob Herring, Mark Rutland,
linux-kernel, linux-leds, linux-arm-msm, devicetree, Fenglin Wu
In-Reply-To: <20171120195812.GY28761@minitux>
On 11/20/2017 08:58 PM, Bjorn Andersson wrote:
> On Sun 19 Nov 13:35 PST 2017, Jacek Anaszewski wrote:
>
>> Hi Bjorn,
>>
>> Thanks for the update.
>>
>> On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
>>> This adds the binding document describing the three hardware blocks
>>> related to the Light Pulse Generator found in a wide range of Qualcomm
>>> PMICs.
>>>
>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>> ---
>>>
>>> Changes since v2:
>>> - Squashed all things into one node
>>> - Removed quirks from the binding, compatible implies number of channels, their
>>> configuration etc.
>>> - Binding describes LEDs connected as child nodes
>>> - Support describing multi-channel LEDs
>>> - Change style of the binding document, to match other LED bindings
>>>
>>> Changes since v1:
>>> - Dropped custom pattern properties
>>> - Renamed cell-index to qcom,lpg-channel to clarify its purpose
>>>
>>> .../devicetree/bindings/leds/leds-qcom-lpg.txt | 66 ++++++++++++++++++++++
>>> 1 file changed, 66 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
>>> new file mode 100644
>>> index 000000000000..9cee6f9f543c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
>>> @@ -0,0 +1,66 @@
>>> +Binding for Qualcomm Light Pulse Generator
>>> +
>>> +The Qualcomm Light Pulse Generator consists of three different hardware blocks;
>>> +a ramp generator with lookup table, the light pulse generator and a three
>>> +channel current sink. These blocks are found in a wide range of Qualcomm PMICs.
>>> +
>>> +Required properties:
>>> +- compatible: one of:
>>> + "qcom,pm8916-pwm",
>>> + "qcom,pm8941-lpg",
>>> + "qcom,pm8994-lpg",
>>> + "qcom,pmi8994-lpg",
>>> + "qcom,pmi8998-lpg",
>>> +
>>> +Optional properties:
>>> +- qcom,power-source: power-source used to drive the output, as defined in the
>>> + datasheet. Should be specified if the TRILED block is
>>> + present
>>
>> Range of possible values is missing here.
>>
>
> There seems to be a 4-way mux in all variants, but the wiring is
> different in the different products. E.g. in pm8941 1 represents VPH_PWR
> while in pmi8994 this is pulled from a dedicated pin named VIN_RGB.
>
> Would you like me to list the 4 options for each compatible?
Could you please explain why user would prefer one power source
over the other? Is it that they have different max current limit?
>>> +- qcom,dtest: configures the output into an internal test line of the
>>> + pmic. Specified by a list of u32 pairs, one pair per channel,
>>> + where each pair denotes the test line to drive and the second
>>> + configures how the value should be outputed, as defined in the
>>> + datasheet
>>> +- #pwm-cells: should be 2, see ../pwm/pwm.txt
>>> +
>>> +LED subnodes:
>>> +A set of subnodes can be used to specify LEDs connected to the LPG. Channels
>>> +not associated with a LED are available as pwm channels, see ../pwm/pwm.txt.
>>> +
>>> +Required properties:
>>> +- led-sources: list of channels associated with this LED, starting at 1 for the
>>> + first LPG channel
>>> +
>>> +Optional properties:
>>> +- label: see Documentation/devicetree/bindings/leds/common.txt
>>> +- default-state: see Documentation/devicetree/bindings/leds/common.txt
>>> +- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
>>> +
>>> +Example:
>>> +The following example defines a RGB LED attached to the PM8941.
>>> +
>>> +&spmi_bus {
>>> + pm8941@1 {
>>> + lpg {
>>> + compatible = "qcom,pm8941-lpg";
>>> + qcom,power-source = <1>;
>>> +
>>> + rgb {
>>> + led-sources = <7 6 5>;
>>> + };
>>> + };
>>> + };
>>> +};
>>> +
>>> +The following example defines the single PWM channel of the PM8916, which can
>>> +be muxed by the MPP4 as a current sink.
>>> +
>>> +&spmi_bus {
>>> + pm8916@1 {
>>> + pm8916_pwm: pwm {
>>> + compatible = "qcom,pm8916-pwm";
>>> +
>>> + #pwm-cells = <2>;
>>
>> LED has to be represented as a child node -
>> see Documentation/devicetree/bindings/leds/common.txt
>>
>
> Some use cases for this hardware block is to use it as a "traditional"
> PWM source, so any channels not allocated to a LED are available as pwm
> channels.
>
> So this is from the Dragonboard410c, where the example application is to
> wire this pwm signal as control signal to a backlight controller; i.e.
> using pwm-backlight associated with the display panel.
Ack.
>
> For testing purposes I did route the signal to another gpio with a LED
> on the board, added a LED node here and saw that I can control that as
> well.
>
> I did include this example here, even though there's no LED, just to
> show how this could be done.
>
>>> + };
>>> + };
>>> +};
>>>
>>
>> Could you please also provide an example of the arrangement on the
>> board DragonBoard820c, you were describing in the discussions under
>> the previous version of the patch set. i.e. three green LEDs connected
>> to TRILED and one to the GPIO sink?
>>
>
> Of course.
One more question regarding TRILED - in your design it will be
exposed as a single LED class device with one brightness file,
right? Does it mean that all three LEDs will be applied the
same brightness after writing it to the sysfs file?
>> Also any other non-trivial board configurations supported by the
>> driver would allow to increase our comprehensions of the device
>> capabilities.
>>
>
> There is a few other hardware components that can be fed the output of
> the LPG as control signal, but I think the GPIO sink case above does
> showcase the power.
>
> Regards,
> Bjorn
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node
From: Jonathan Neuschäfer @ 2017-11-20 20:28 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jonathan=20Neusch=C3=A4fer?=
In-Reply-To: <20171120195000.2070-1-palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]
On Mon, Nov 20, 2017 at 11:50:00AM -0800, Palmer Dabbelt wrote:
> The RISC-V privileged ISA mandates the presence of an SBI, but there's
> no reason not to put it in the device tree. This would allow us to
> possibly remove the SBI later.
Thanks!
>
> CC: Jonathan Neuschäfer <j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org>
> Signed-off-by: Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/firmware/riscv.sbi.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/firmware/riscv.sbi.txt
>
> diff --git a/Documentation/devicetree/bindings/firmware/riscv.sbi.txt b/Documentation/devicetree/bindings/firmware/riscv.sbi.txt
> new file mode 100644
> index 000000000000..42384d5d52cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/riscv.sbi.txt
Nit: Other bindings use either a comma (as in the compatible string,
"riscv,sbi.txt") or a dash (vendor-product.txt, "riscv-sbi.txt") in the
file name.
> @@ -0,0 +1,20 @@
> +RISC-V Supervisor Binary Interface (SBI)
> +
> +The RISC-V privileged ISA specification mandates the presence of a supervisor
> +binary interface that performs some operations which might otherwise require
> +particularly complicated instructions. This interface includes
> +inter-processor interrupts, TLB flushes, i-cache and TLB shootdowns, a
> +console, and power management.
> +
> +Required properties:
> +- compatible: must contain one of the following
> + * "riscv,sbi" for the SBI defined by the privileged specification of the
> + system.
"of the system" seems to imply that different RISC-V systems (different
RISC-V implementations) can have different privileged specifications.
I think it's better to refer to concrete documents, that don't depend on
the rest of the system, instead. Either:
* "riscv,sbi" for the SBI defined by the RISC-V Privileged ISA Specification.
Or something like:
* "sifive,sbi" for the SBI defined by SiFive document XYZ.
[ I know that there currently is no SBI spec, because the chapter has
been removed from the Priv Spec, but this can be fixed later, once
the final name of the document describing the SBI is clear. ]
> +
> +Example:
> +
> +firmware {
> + sbi {
> + compatible = "riscv,sbi";
> + };
> +};
> --
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: RFC: Copying Device Tree File into reserved area of VMLINUX before deployment
From: Ulf Samuelsson @ 2017-11-20 20:19 UTC (permalink / raw)
To: Frank Rowand, LKML, devicetree@vger.kernel.org, Rob Herring
In-Reply-To: <fe7925f3-30d4-ec03-a6c5-61a8644dcdfe@gmail.com>
On 2017-11-20 05:32, Frank Rowand wrote:
> Hi Ulf,
>
>
> On 11/19/17 23:23, Frank Rowand wrote:
>> adding devicetree list, devicetree maintainers
>>
>> On 11/18/17 12:59, Ulf Samuelsson wrote:
>>> I noticed when checking out the OpenWRT support for the board that they have a method to avoid having to pass the device tree address to the kernel, and can thus boot device tree based kernels with U-boots that
>>> does not support device trees.
>>>
>>> Is this something that would be considered useful for including in mainstream:
>>>
>>> BACKGROUND:
>>> Trying to load a yocto kernel into a MIPS target (MT7620A based),
>>> and the U-Boot is more than stupid.
>>> Does not support the "run" command as an example.
>>> They modified the U-Boot MAGIC Word to complicate things.
>>> The U-Boot is not configured to use device tree files.
>>> The board runs a 2.6 kernel right now.
>>>
>>> Several attempts by me a and others to rebuild U-Boot according to
>>> the H/W vendors source code and build instructions results in a
>>> bricked unit. Bricked units cannot be recovered.
>
> Hopefully you have brought this to the attention of the vendor. U-Boot
> is GPL v2 (or in some ways possibly GPL v2 or later), so if you can not
> build U-Boot that is equivalent to the binary U-Boot they shipped, the
> vendor may want to ensure that they are shipping the proper source and
> build instructions.
>
I am not the one in contact with the H/W vendor.
The U-boot is pretty old, and from comments from those
in contact with them, the U-Boot knowledge at the H/W vendor
is minimal at best.
It might even be that they program an U-boot where the upgrade of the
U-boot is broken...
>
>>> Not my choice of H/W, so I cannot change it.
>>>
>>>
>>> ===================================================================
>>> OPENWRT:
>>> I noticed when checking out the OpenWRT support for the board that
>>> they have a method to avoid having to pass the device tree address
>>> to the kernel, and can thus boot device tree based kernels with
>>> U-boots that does not support device trees.
>>>
>>> What they do is to reserve 16 kB of kernel space, and tag it with
>>> an ASCII string "OWRTDTB:". After the kernel and dtb is built, a
>>> utility "patch-dtb" will update the vmlinux binary, copying in the
>>> device tree file.
>>>
>>> ===================================================================
>>> It would be useful to me, and I could of course patch the
>>> mainstream kernel, but first I would like to check if this is of
>>> interest for mainstream.
>
> Not in this form. Hard coding a fixed size area in the boot image
> to contain the FDT (aka DTB) is a non-starter.
OK, Is it the fixed size, which is a problem?
Is generally combining an image with a DTB into a single file also a
non-starter?
>
> And again, I would first approach the H/W vendor before trying to
> come up with a work around like this.
>
>
>>> I envisage the support would look something like:
>>>
>>> ============
>>> Kconfig.
>>> config MIPS
>>> select HAVE_IMAGE_DTB
>>>
>>> config HAVE_IMAGE_DTB
>>> bool
>>>
>>> if HAVE_IMAGE_DTB
>>> config IMAGE_DTB
>>> bool "Allocated space for DTB within image
>>>
>>> config DTB_SIZE
>>> int "DTB space (kB)
>>>
>>> config DTB_TAG
>>> string "DTB space tag"
>>> default "OWRTDTB:"
>>> endif
>>>
>>> ============
>>> Some Makefile
>>> obj-$(CONFIG_INCLUDE_DTB) += image_dtb.o
>>>
>>> ============
>>> image_dtb.S:
>>> .text
>>> .align 5
>>> .ascii CONFIG_DTB_TAG
>>> EXPORT(__image_dtb)
>>> .fill DTB_SIZE * 1024
>>>
>>> ===================
>>> arch/mips/xxx/of.c:
>>>
>>> #if defined(CONFIG_IMAGE_DTB)
>>> if (<conditions to boot from dtb_space>)
>>> __dt_setup_arch(__dtb_start);
>>> else
>>> __dt_setup_arch(&__image_dtb);
>>> #else
>>> __dt_setup_arch(__dtb_start);
>>> #endif
>>>
>>> I imagine that if the support is enabled for a target, it should
>>> be possible to override it with a CMDLINE argument
>>>
>>>
>>> They do something similar for the CMDLINE; copying it into the vmlinux, to allow a smaller boot
--
Best Regards
Ulf Samuelsson
^ permalink raw reply
* Re: [PATCH v3 3/3] DT: leds: Add Qualcomm Light Pulse Generator binding
From: Bjorn Andersson @ 2017-11-20 19:58 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Richard Purdie, Pavel Machek, Rob Herring, Mark Rutland,
linux-kernel, linux-leds, linux-arm-msm, devicetree, Fenglin Wu
In-Reply-To: <a97a6cd3-b624-5127-003d-7ffd7d9d67e9@gmail.com>
On Sun 19 Nov 13:35 PST 2017, Jacek Anaszewski wrote:
> Hi Bjorn,
>
> Thanks for the update.
>
> On 11/15/2017 08:13 AM, Bjorn Andersson wrote:
> > This adds the binding document describing the three hardware blocks
> > related to the Light Pulse Generator found in a wide range of Qualcomm
> > PMICs.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Changes since v2:
> > - Squashed all things into one node
> > - Removed quirks from the binding, compatible implies number of channels, their
> > configuration etc.
> > - Binding describes LEDs connected as child nodes
> > - Support describing multi-channel LEDs
> > - Change style of the binding document, to match other LED bindings
> >
> > Changes since v1:
> > - Dropped custom pattern properties
> > - Renamed cell-index to qcom,lpg-channel to clarify its purpose
> >
> > .../devicetree/bindings/leds/leds-qcom-lpg.txt | 66 ++++++++++++++++++++++
> > 1 file changed, 66 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
> >
> > diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
> > new file mode 100644
> > index 000000000000..9cee6f9f543c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
> > @@ -0,0 +1,66 @@
> > +Binding for Qualcomm Light Pulse Generator
> > +
> > +The Qualcomm Light Pulse Generator consists of three different hardware blocks;
> > +a ramp generator with lookup table, the light pulse generator and a three
> > +channel current sink. These blocks are found in a wide range of Qualcomm PMICs.
> > +
> > +Required properties:
> > +- compatible: one of:
> > + "qcom,pm8916-pwm",
> > + "qcom,pm8941-lpg",
> > + "qcom,pm8994-lpg",
> > + "qcom,pmi8994-lpg",
> > + "qcom,pmi8998-lpg",
> > +
> > +Optional properties:
> > +- qcom,power-source: power-source used to drive the output, as defined in the
> > + datasheet. Should be specified if the TRILED block is
> > + present
>
> Range of possible values is missing here.
>
There seems to be a 4-way mux in all variants, but the wiring is
different in the different products. E.g. in pm8941 1 represents VPH_PWR
while in pmi8994 this is pulled from a dedicated pin named VIN_RGB.
Would you like me to list the 4 options for each compatible?
> > +- qcom,dtest: configures the output into an internal test line of the
> > + pmic. Specified by a list of u32 pairs, one pair per channel,
> > + where each pair denotes the test line to drive and the second
> > + configures how the value should be outputed, as defined in the
> > + datasheet
> > +- #pwm-cells: should be 2, see ../pwm/pwm.txt
> > +
> > +LED subnodes:
> > +A set of subnodes can be used to specify LEDs connected to the LPG. Channels
> > +not associated with a LED are available as pwm channels, see ../pwm/pwm.txt.
> > +
> > +Required properties:
> > +- led-sources: list of channels associated with this LED, starting at 1 for the
> > + first LPG channel
> > +
> > +Optional properties:
> > +- label: see Documentation/devicetree/bindings/leds/common.txt
> > +- default-state: see Documentation/devicetree/bindings/leds/common.txt
> > +- linux,default-trigger: see Documentation/devicetree/bindings/leds/common.txt
> > +
> > +Example:
> > +The following example defines a RGB LED attached to the PM8941.
> > +
> > +&spmi_bus {
> > + pm8941@1 {
> > + lpg {
> > + compatible = "qcom,pm8941-lpg";
> > + qcom,power-source = <1>;
> > +
> > + rgb {
> > + led-sources = <7 6 5>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +The following example defines the single PWM channel of the PM8916, which can
> > +be muxed by the MPP4 as a current sink.
> > +
> > +&spmi_bus {
> > + pm8916@1 {
> > + pm8916_pwm: pwm {
> > + compatible = "qcom,pm8916-pwm";
> > +
> > + #pwm-cells = <2>;
>
> LED has to be represented as a child node -
> see Documentation/devicetree/bindings/leds/common.txt
>
Some use cases for this hardware block is to use it as a "traditional"
PWM source, so any channels not allocated to a LED are available as pwm
channels.
So this is from the Dragonboard410c, where the example application is to
wire this pwm signal as control signal to a backlight controller; i.e.
using pwm-backlight associated with the display panel.
For testing purposes I did route the signal to another gpio with a LED
on the board, added a LED node here and saw that I can control that as
well.
I did include this example here, even though there's no LED, just to
show how this could be done.
> > + };
> > + };
> > +};
> >
>
> Could you please also provide an example of the arrangement on the
> board DragonBoard820c, you were describing in the discussions under
> the previous version of the patch set. i.e. three green LEDs connected
> to TRILED and one to the GPIO sink?
>
Of course.
> Also any other non-trivial board configurations supported by the
> driver would allow to increase our comprehensions of the device
> capabilities.
>
There is a few other hardware components that can be fed the output of
the LPG as control signal, but I think the GPIO sink case above does
showcase the power.
Regards,
Bjorn
^ permalink raw reply
* [PATCH] dt-bindings: Add an enable method to RISC-V
From: Palmer Dabbelt @ 2017-11-20 19:50 UTC (permalink / raw)
To: mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Palmer Dabbelt
RISC-V doesn't currently specify a mechanism for enabling or disabling
CPUs. Instead, we assume that all CPUs are enabled on boot, and if
someone wants to save power we instead put a CPU to sleep via a WFI
loop.
This patch adds "enable-method" to the RISC-V CPU binding, which
currently only has the value "none". This allows us to change the
enable method in the future.
CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Signed-off-by: Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/riscv/cpus.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/cpus.txt b/Documentation/devicetree/bindings/riscv/cpus.txt
index adf7b7af5dc3..dd9e1ae197e2 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.txt
+++ b/Documentation/devicetree/bindings/riscv/cpus.txt
@@ -82,6 +82,11 @@ described below.
Value type: <string>
Definition: Contains the RISC-V ISA string of this hart. These
ISA strings are defined by the RISC-V ISA manual.
+ - cpu-enable-method:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Must be one of
+ "none": This CPU's state cannot be changed.
Example: SiFive Freedom U540G Development Kit
---------------------------------------------
@@ -105,6 +110,7 @@ Linux is allowed to run on.
reg = <0>;
riscv,isa = "rv64imac";
status = "disabled";
+ enable-method = "none";
L10: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
@@ -130,6 +136,7 @@ Linux is allowed to run on.
reg = <1>;
riscv,isa = "rv64imafdc";
status = "okay";
+ enable-method = "none";
tlb-split;
L13: interrupt-controller {
#interrupt-cells = <1>;
--
2.13.6
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] dt-bindings: Add a RISC-V SBI firmware node
From: Palmer Dabbelt @ 2017-11-20 19:50 UTC (permalink / raw)
To: mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Palmer Dabbelt,
nathan=20Neusch=C3=A4fer?=
The RISC-V privileged ISA mandates the presence of an SBI, but there's
no reason not to put it in the device tree. This would allow us to
possibly remove the SBI later.
CC: Jonathan Neuschäfer <j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org>
Signed-off-by: Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
---
.../devicetree/bindings/firmware/riscv.sbi.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/riscv.sbi.txt
diff --git a/Documentation/devicetree/bindings/firmware/riscv.sbi.txt b/Documentation/devicetree/bindings/firmware/riscv.sbi.txt
new file mode 100644
index 000000000000..42384d5d52cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/riscv.sbi.txt
@@ -0,0 +1,20 @@
+RISC-V Supervisor Binary Interface (SBI)
+
+The RISC-V privileged ISA specification mandates the presence of a supervisor
+binary interface that performs some operations which might otherwise require
+particularly complicated instructions. This interface includes
+inter-processor interrupts, TLB flushes, i-cache and TLB shootdowns, a
+console, and power management.
+
+Required properties:
+- compatible: must contain one of the following
+ * "riscv,sbi" for the SBI defined by the privileged specification of the
+ system.
+
+Example:
+
+firmware {
+ sbi {
+ compatible = "riscv,sbi";
+ };
+};
--
2.13.6
--
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
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