* Re: [PATCH 2/6] dt-bindings: clk: max8997: Add DT binding documentation
From: Rob Herring @ 2016-11-14 16:15 UTC (permalink / raw)
To: Pankaj Dubey
Cc: linux-samsung-soc, linux-arm-kernel, krzk, javier, kgene,
thomas.ab, myungjoo.ham, Michael Turquette, devicetree, linux-clk
In-Reply-To: <1478513376-14307-3-git-send-email-pankaj.dubey@samsung.com>
On Mon, Nov 07, 2016 at 03:39:32PM +0530, Pankaj Dubey wrote:
> Add Device Tree binding documentation for the clocks
> outputs in the Maxim-8997 Power Management IC.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree@vger.kernel.org
> CC: linux-clk@vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> .../devicetree/bindings/clock/maxim,max8997.txt | 44 ++++++++++++++++++++++
> .../bindings/regulator/max8997-regulator.txt | 3 ++
> 2 files changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/maxim,max8997.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/maxim,max8997.txt b/Documentation/devicetree/bindings/clock/maxim,max8997.txt
> new file mode 100644
> index 0000000..d2e2a74
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/maxim,max8997.txt
> @@ -0,0 +1,44 @@
> +Binding for Maxim MAX8997 32k clock generator block
> +
> +This is a part of device tree bindings of MAX8997 multi-function device.
> +More information can be found in bindings/regulator/max8997-regulator.txt file.
> +
> +The MAX8997 contains two 32.768khz clock outputs that can be controlled
> +(gated/ungated) over I2C.
> +
> +Following properties should be presend in main device node of the MFD chip.
> +
> +Required properties:
> +
> +- #clock-cells: from common clock binding; shall be set to 1.
> +
> +Optional properties:
> +- clock-output-names: From common clock binding.
> +
> +Each clock is assigned an identifier and client nodes can use this identifier
> +to specify the clock which they consume. Following indices are allowed:
> + - 0: 32khz_ap clock,
> + - 1: 32khz_cp clock,
> +
> +Clocks are defined as preprocessor macros in dt-bindings/clock/maxim,max8997.h
> +header and can be used in device tree sources.
> +
> +Example: Node of the MFD chip
> +
> + max8997: max8997_pmic@66 {
pmic@66 {
With that:
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 3/3] clk: qcom: Add A53 clock driver
From: Georgi Djakov @ 2016-11-14 16:15 UTC (permalink / raw)
To: Rob Herring
Cc: sboyd, mturquette, linux-clk, devicetree, mark.rutland,
linux-kernel, linux-arm-msm
In-Reply-To: <20161109182440.hjiv725vpsh5dctd@rob-hp-laptop>
On 11/09/2016 08:24 PM, Rob Herring wrote:
> On Mon, Oct 31, 2016 at 04:55:26PM +0200, Georgi Djakov wrote:
>> Add a driver for the A53 Clock Controller. It is a hardware block that
>> implements a combined mux and half integer divider functionality. It can
>> choose between a fixed-rate clock or the dedicated A53 PLL. The source
>> and the divider can be set both at the same time.
>>
>> This is required for enabling CPU frequency scaling on platforms like
>> MSM8916.
>>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> ---
>> .../devicetree/bindings/clock/qcom,a53cc.txt | 23 ++++
>> drivers/clk/qcom/Kconfig | 8 ++
>> drivers/clk/qcom/Makefile | 1 +
>> drivers/clk/qcom/a53cc.c | 152 +++++++++++++++++++++
>> 4 files changed, 184 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/qcom,a53cc.txt
>> create mode 100644 drivers/clk/qcom/a53cc.c
>>
>> diff --git a/Documentation/devicetree/bindings/clock/qcom,a53cc.txt b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
>> new file mode 100644
>> index 000000000000..82d1634a2713
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/qcom,a53cc.txt
>> @@ -0,0 +1,23 @@
>> +Qualcomm A53 CPU Clock Controller Binding
>> +------------------------------------------------
>> +The A53 CPU Clock Controller is hardware, which provides a combined
>> +mux and divider functionality for the CPU clocks. It can choose between
>> +a fixed rate clock and the dedicated A53 PLL. This hardware block is used
>> +on platforms such as msm8916.
>> +
>> +Required properties :
>> +- compatible : shall contain:
>> +
>> + "qcom,a53cc-msm8916"
>
> Same comment on the ordering. With that, for the binding:
>
> Acked-by: Rob Herring <robh@kernel.org>
>
Thanks for reviewing, Rob. I am also going to make this a child node
as discussed here [1]. Please let me know if you have any comments.
[1]. https://lkml.org/lkml/2016/11/11/387
Thanks,
Georgi
^ permalink raw reply
* Re: [PATCH 2/3] devicetree: bindings: nvmem: Add compatible string for imx6ul
From: Rob Herring @ 2016-11-14 16:14 UTC (permalink / raw)
To: Bai Ping
Cc: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478497281-5477-2-git-send-email-ping.bai-3arQi8VN3Tc@public.gmane.org>
On Mon, Nov 07, 2016 at 01:41:20PM +0800, Bai Ping wrote:
> Add new compatible string for i.MX6UL SOC.
>
> Signed-off-by: Bai Ping <ping.bai-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> index 383d588..a7ff65d 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> @@ -1,13 +1,14 @@
> Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings
>
> This binding represents the on-chip eFuse OTP controller found on
> -i.MX6Q/D, i.MX6DL/S, i.MX6SL, and i.MX6SX SoCs.
> +i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX and i.MX6UL SoCs.
>
> Required properties:
> - compatible: should be one of
> "fsl,imx6q-ocotp" (i.MX6Q/D/DL/S),
> - "fsl,imx6sl-ocotp" (i.MX6SL), or
> - "fsl,imx6sx-ocotp" (i.MX6SX), followed by "syscon".
> + "fsl,imx6sl-ocotp" (i.MX6SL),
> + "fsl,imx6sx-ocotp" (i.MX6SX), or
> + "fsl,imx6ul-ocotp" (i.MX6UL), followed by "syscon".
This should be reformatted such that it's not a 5 line change to add a
compatible. "one of" defines this is an OR relationship, so drop that.
Move 'followed by "syscon"' to below the list of compatibles.
> - reg: Should contain the register base and length.
> - clocks: Should contain a phandle pointing to the gated peripheral clock.
>
> --
> 2.8.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 5/5] media: platform: rcar_drif: Add DRIF support
From: Ramesh Shanmugasundaram @ 2016-11-14 16:11 UTC (permalink / raw)
To: Hans Verkuil, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
crope-X3B1VOXEql0@public.gmane.org
Cc: Chris Paterson,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9b772894-f6ef-d5ad-4601-735f2321ce0c-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Hi Hans,
Thanks for the review comments.
> Subject: Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
>
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3
> SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and
> > the tuner device, which is registered as a sub-device, determines the
> > receive sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF
> > acts as a slave device and the tuner device acts as a master
> > transmitting the samples. The driver allows asynchronous binding of a
> > tuner device that is registered as a v4l2 sub-device. The driver can
> > learn about the tuner it is interfaced with based on port endpoint
> > properties of the device in device tree. The V4L2 SDR device inherits
> > the controls exposed by the tuner device.
> >
> > The device can also be configured to use either one or both of the
> > data pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> > ---
> > .../devicetree/bindings/media/renesas,drif.txt | 136 ++
> > drivers/media/platform/Kconfig | 25 +
> > drivers/media/platform/Makefile | 1 +
> > drivers/media/platform/rcar_drif.c | 1574
> ++++++++++++++++++++
> > 4 files changed, 1736 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/renesas,drif.txt
> > create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > new file mode 100644
> > index 0000000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +------------------------------------------------------------
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++---------------------+ +---------------------+
> > +| |-----SCK------->|CLK |
> > +| Master |-----SS-------->|SYNC DRIFn (slave) |
> > +| |-----SD0------->|D0 |
> > +| |-----SD1------->|D1 |
> > ++---------------------+ +---------------------+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 &
> drifn1).
> > +The sub-channels are like two individual channels in itself that
> > +share the common CLK & SYNC. Each sub-channel has it's own dedicated
> > +resources like irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's
> > +sub-channel as a separate node. The parent channel ties the
> > +sub-channels together with their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-------------------------------------
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-------------------------------------
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +---------------------------------
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +---------------------------------
> > +- port: child port node of a channel that defines the local and remote
> > + endpoints. The remote endpoint is assumed to be a tuner
> subdevice
> > + endpoint.
> > +- renesas,syncmd : sync mode
> > + 0 (Frame start sync pulse mode. 1-bit width pulse
> > + indicates start of a frame)
> > + 1 (L/R sync or I2S mode) (default)
> > +- renesas,lsb-first : empty property indicates lsb bit is received
> first.
> > + When not defined msb bit is received first (default)
> > +- renesas,syncac-pol-high : empty property indicates sync signal
> polarity.
> > + When defined, active high or high->low sync signal.
> > + When not defined, active low or low->high sync signal
> > + (default)
> > +- renesas,dtdl : delay between sync signal and start of
> reception.
> > + Must contain one of the following values:
> > + 0 (no bit delay)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay) (default)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > +- renesas,syncdl : delay between end of reception and sync signal
> edge.
> > + Must contain one of the following values:
> > + 0 (no bit delay) (default)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > + 300 (3-clock-cycle delay)
> > +
> > +Example
> > +--------
> > +
> > +SoC common dtsi file
> > +
> > + drif00: rif@e6f40000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f40000 0 0x64>;
> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 515>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif01: rif@e6f50000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f50000 0 0x64>;
> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 514>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif0: rif@0 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + sub-channels = <&drif00>, <&drif01>;
> > + status = "disabled";
> > + };
> > +
> > +Board specific dts file
> > +
> > +&drif00 {
> > + status = "okay";
> > +};
> > +
> > +&drif01 {
> > + status = "okay";
> > +};
> > +
> > +&drif0 {
> > + pinctrl-0 = <&drif0_pins>;
> > + pinctrl-names = "default";
> > + renesas,syncac-pol-high;
> > + status = "okay";
> > + port {
> > + drif0_ep: endpoint {
> > + remote-endpoint = <&tuner_subdev_ep>;
> > + };
> > + };
> > +};
> > diff --git a/drivers/media/platform/Kconfig
> > b/drivers/media/platform/Kconfig index 754edbf1..0ae83a8 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -393,3 +393,28 @@ menuconfig DVB_PLATFORM_DRIVERS if
> > DVB_PLATFORM_DRIVERS source
> > "drivers/media/platform/sti/c8sectpfe/Kconfig"
> > endif #DVB_PLATFORM_DRIVERS
> > +
> > +menuconfig SDR_PLATFORM_DRIVERS
> > + bool "SDR platform devices"
> > + depends on MEDIA_SDR_SUPPORT
> > + default n
> > + ---help---
> > + Say Y here to enable support for platform-specific SDR Drivers.
> > +
> > +if SDR_PLATFORM_DRIVERS
> > +
> > +config VIDEO_RCAR_DRIF
> > + tristate "Renesas Digitial Radio Interface (DRIF)"
> > + depends on VIDEO_V4L2 && HAS_DMA
> > + depends on ARCH_RENESAS
> > + select VIDEOBUF2_VMALLOC
> > + ---help---
> > + Say Y if you want to enable R-Car Gen3 DRIF support. DRIF is
> Digital
> > + Radio Interface that interfaces with an RF front end chip. It is a
> > + receiver of digital data which uses DMA to transfer received data
> to
> > + a configured location for an application to use.
> > +
> > + To compile this driver as a module, choose M here; the module
> > + will be called rcar_drif.
> > +
> > +endif # SDR_PLATFORM_DRIVERS
> > diff --git a/drivers/media/platform/Makefile
> > b/drivers/media/platform/Makefile index f842933..49ce238 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -49,6 +49,7 @@ obj-$(CONFIG_SOC_CAMERA) += soc_camera/
> >
> > obj-$(CONFIG_VIDEO_RENESAS_FCP) += rcar-fcp.o
> > obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o
> > +obj-$(CONFIG_VIDEO_RCAR_DRIF) += rcar_drif.o
> > obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
> >
> > obj-y += omap/
> > diff --git a/drivers/media/platform/rcar_drif.c
> > b/drivers/media/platform/rcar_drif.c
> > new file mode 100644
> > index 0000000..34dc282
> > --- /dev/null
> > +++ b/drivers/media/platform/rcar_drif.c
> > @@ -0,0 +1,1574 @@
>
> <snip>
>
> +#define for_each_rcar_drif_subdev(sd, tmp, ch) \
> + list_for_each_entry_safe(sd, tmp, &ch->v4l2_dev.subdevs, list)
> +
>
> Please don't use this. media/v4l2-device.h has a bunch of similar
> functions for this. Use those instead.
Thanks. Agreed.
>
> <snip>
>
> > +static int rcar_drif_querycap(struct file *file, void *fh,
> > + struct v4l2_capability *cap) {
> > + struct rcar_drif_chan *ch = video_drvdata(file);
> > +
> > + strlcpy(cap->driver, KBUILD_MODNAME, sizeof(cap->driver));
> > + strlcpy(cap->card, ch->vdev.name, sizeof(cap->card));
> > + cap->device_caps = V4L2_CAP_SDR_CAPTURE | V4L2_CAP_TUNER |
> > + V4L2_CAP_STREAMING | V4L2_CAP_READWRITE;
> > + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
>
> Set device_caps in struct video_device and drop it here.
>
> The core will fill in cap->device_caps and cap->capabilities for you.
Agreed.
>
> > + snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
> > + ch->vdev.name);
> > + return 0;
> > +}
> > +
> > +static int rcar_drif_set_default_format(struct rcar_drif_chan *ch) {
> > + unsigned int i;
> > +
> > + for (i = 0; i < NUM_FORMATS; i++) {
> > + /* Find any matching fmt and set it as default */
> > + if (ch->num_hw_schans == formats[i].num_schans) {
> > + ch->fmt_idx = i;
> > + ch->cur_schans_mask = ch->hw_schans_mask;
> > + ch->num_cur_schans = ch->num_hw_schans;
> > + dev_dbg(ch->dev, "default fmt[%u]: mask %lu num %u\n",
> > + i, ch->cur_schans_mask, ch->num_cur_schans);
> > + return 0;
> > + }
> > + }
> > + dev_err(ch->dev, "no matching sdr fmt found\n");
> > + return -EINVAL;
> > +}
> > +
> > +static int rcar_drif_enum_fmt_sdr_cap(struct file *file, void *priv,
> > + struct v4l2_fmtdesc *f)
> > +{
> > + if (f->index >= NUM_FORMATS)
> > + return -EINVAL;
> > +
> > + strlcpy(f->description, formats[f->index].name,
> > +sizeof(f->description));
>
> Drop this. The core fills that in for you.
>
Agreed.
> > + f->pixelformat = formats[f->index].pixelformat;
> > + return 0;
> > +}
> > +
> > +static int rcar_drif_g_fmt_sdr_cap(struct file *file, void *priv,
> > + struct v4l2_format *f)
> > +{
> > + struct rcar_drif_chan *ch = video_drvdata(file);
> > +
> > + f->fmt.sdr.pixelformat = formats[ch->fmt_idx].pixelformat;
> > + f->fmt.sdr.buffersize = formats[ch->fmt_idx].buffersize;
> > + memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
> > + return 0;
> > +}
> > +
[snip]
> > +/* Parse sub-devs (tuner) to find a matching device */ static int
> > +rcar_drif_parse_subdevs(struct device *dev,
> > + struct v4l2_async_notifier *notifier) {
> > + struct device_node *node = NULL;
> > +
> > + notifier->subdevs = devm_kzalloc(dev, sizeof(*notifier->subdevs),
> > + GFP_KERNEL);
> > + if (!notifier->subdevs)
> > + return -ENOMEM;
> > +
> > + node = of_graph_get_next_endpoint(dev->of_node, node);
>
> Do:
>
> if (!node)
> return 0;
>
> And the remainder can be shifted one tab to the left.
Agreed.
>
> > + if (node) {
> > + struct rcar_drif_async_subdev *rsd;
> > +
> > + rsd = devm_kzalloc(dev, sizeof(*rsd), GFP_KERNEL);
> > + if (!rsd) {
> > + of_node_put(node);
> > + return -ENOMEM;
> > + }
> > +
> > + notifier->subdevs[notifier->num_subdevs] = &rsd->asd;
> > + rsd->asd.match.of.node =
> of_graph_get_remote_port_parent(node);
> > + of_node_put(node);
> > + if (!rsd->asd.match.of.node) {
> > + dev_warn(dev, "bad remote port parent\n");
> > + return -EINVAL;
> > + }
> > +
> > + rsd->asd.match_type = V4L2_ASYNC_MATCH_OF;
> > + notifier->num_subdevs++;
> > + }
> > + return 0;
> > +}
> > +
> > +/* SIRMDR1 configuration */
> > +static int rcar_drif_validate_syncmd(struct rcar_drif_chan *ch, u32
> > +val) {
> > + if (val > 1) {
> > + dev_err(ch->dev, "invalid syncmd %u using L/R mode\n", val);
> > + return -EINVAL;
> > + }
> > +
> > + ch->mdr1 &= ~(3 << 28); /* Clear current settings */
> > + if (val == 0)
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCMD_FRAME;
> > + else
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCMD_LR;
> > + return 0;
> > +}
> > +
> > +/* Get the dtdl or syncdl bits as in MSIOF */ static u32
> > +rcar_drif_get_dtdl_or_syncdl_bits(u32 dtdl_or_syncdl) {
> > + /*
> > + * DTDL/SYNCDL bit : dtdl/syncdl
> > + * b'000 : 0
> > + * b'001 : 100
> > + * b'010 : 200
> > + * b'011 (SYNCDL only) : 300
> > + * b'101 : 50
> > + * b'110 : 150
> > + */
> > + if (dtdl_or_syncdl % 100)
> > + return dtdl_or_syncdl / 100 + 5;
> > + else
>
> Line can be dropped.
Agreed.
>
> > + return dtdl_or_syncdl / 100;
> > +}
> > +
> > +static int rcar_drif_validate_dtdl_syncdl(struct rcar_drif_chan *ch)
> > +{
> > + struct device_node *np = ch->dev->of_node;
> > + u32 dtdl = 100, syncdl = 0;
> > +
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_DTDL_1 | RCAR_DRIF_SIRMDR1_SYNCDL_0;
> > + of_property_read_u32(np, "renesas,dtdl", &dtdl);
> > + of_property_read_u32(np, "renesas,syncdl", &syncdl);
> > +
> > + /* Sanity checks */
> > + if (dtdl > 200 || syncdl > 300) {
> > + dev_err(ch->dev, "invalid dtdl %u/syncdl %u\n", dtdl, syncdl);
> > + return -EINVAL;
> > + }
> > + if ((dtdl + syncdl) % 100) {
> > + dev_err(ch->dev, "sum of dtdl %u & syncdl %u not OK\n",
> > + dtdl, syncdl);
> > + return -EINVAL;
> > + }
> > + ch->mdr1 &= ~(7 << 20) & ~(7 << 16); /* Clear current settings
> */
> > + ch->mdr1 |= rcar_drif_get_dtdl_or_syncdl_bits(dtdl) << 20;
> > + ch->mdr1 |= rcar_drif_get_dtdl_or_syncdl_bits(syncdl) << 16;
> > + return 0;
> > +}
> > +
> > +static int rcar_drif_parse_properties(struct rcar_drif_chan *ch) {
> > + struct device_node *np = ch->dev->of_node;
> > + u32 syncmd;
> > + int ret;
> > +
> > + /* Set the defaults and check for overrides */
> > + ch->mdr1 = RCAR_DRIF_SIRMDR1_SYNCMD_LR;
> > + if (!of_property_read_u32(np, "renesas,syncmd", &syncmd)) {
> > + ret = rcar_drif_validate_syncmd(ch, syncmd);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (of_find_property(np, "renesas,lsb-first", NULL))
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_LSB_FIRST;
> > + else
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_MSB_FIRST;
> > +
> > + if (of_find_property(np, "renesas,syncac-pol-high", NULL))
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCAC_POL_HIGH;
> > + else
> > + ch->mdr1 |= RCAR_DRIF_SIRMDR1_SYNCAC_POL_LOW;
> > +
> > + return rcar_drif_validate_dtdl_syncdl(ch);
> > +}
> > +
> > +static u32 rcar_drif_enum_sub_channels(struct platform_device *pdev,
> > + struct platform_device *s_pdev[]) {
> > + struct device_node *s_np;
> > + u32 hw_schans_mask = 0;
> > + unsigned int i;
> > +
> > + for (i = 0; i < RCAR_DRIF_MAX_SUBCHANS; i++) {
> > + s_np = of_parse_phandle(pdev->dev.of_node, "sub-channels", i);
> > + if (s_np && of_device_is_available(s_np)) {
> > + s_pdev[i] = of_find_device_by_node(s_np);
> > + if (s_pdev[i]) {
> > + hw_schans_mask |= BIT(i);
> > + dev_dbg(&s_pdev[i]->dev, "schan%u ok\n", i);
> > + }
> > + }
> > + }
> > + return hw_schans_mask;
> > +}
> > +
> > +static int rcar_drif_probe(struct platform_device *pdev) {
> > + struct platform_device *s_pdev[RCAR_DRIF_MAX_SUBCHANS];
> > + unsigned long hw_schans_mask;
> > + struct rcar_drif_chan *ch;
> > + unsigned int i;
> > + int ret;
> > +
> > + /*
> > + * Sub-channel resources are managed by the parent channel instance.
> > + * The sub-channel instance helps only in registering with power
> domain
> > + * to aid in run-time pm support
> > + */
> > + if (!of_find_property(pdev->dev.of_node, "sub-channels", NULL))
> > + return 0;
> > +
> > + /* Parent channel instance */
> > + hw_schans_mask = rcar_drif_enum_sub_channels(pdev, s_pdev);
> > + if (!hw_schans_mask) {
> > + dev_err(&pdev->dev, "no sub-channels enabled\n");
> > + return -ENODEV;
> > + }
> > +
> > +
> > + /* Reserve memory for driver structure */
> > + ch = devm_kzalloc(&pdev->dev, sizeof(*ch), GFP_KERNEL);
> > + if (!ch) {
> > + ret = PTR_ERR(ch);
> > + dev_err(&pdev->dev, "failed alloc drif context\n");
> > + return ret;
> > + }
> > + ch->dev = &pdev->dev;
> > +
> > + /* Parse device tree optional properties */
> > + ret = rcar_drif_parse_properties(ch);
> > + if (ret)
> > + return ret;
> > +
> > + dev_dbg(ch->dev, "parsed mdr1 0x%08x\n", ch->mdr1);
> > +
> > + /* Setup enabled sub-channels */
> > + for_each_rcar_drif_subchannel(i, &hw_schans_mask) {
> > + struct clk *clkp;
> > + struct resource *res;
> > + void __iomem *base;
> > +
> > + /* Peripheral clock */
> > + clkp = devm_clk_get(&s_pdev[i]->dev, "fck");
> > + if (IS_ERR(clkp)) {
> > + ret = PTR_ERR(clkp);
> > + dev_err(&s_pdev[i]->dev, "clk get failed (%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + /* Register map */
> > + res = platform_get_resource(s_pdev[i], IORESOURCE_MEM, 0);
> > + base = devm_ioremap_resource(&s_pdev[i]->dev, res);
> > + if (IS_ERR(base)) {
> > + ret = PTR_ERR(base);
> > + dev_err(&s_pdev[i]->dev, "ioremap failed (%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + /* Reserve memory for enabled sub-channel */
> > + ch->sch[i] = devm_kzalloc(&pdev->dev, sizeof(*ch->sch[i]),
> > + GFP_KERNEL);
> > + if (!ch->sch[i]) {
> > + ret = PTR_ERR(ch);
> > + dev_err(&s_pdev[i]->dev, "failed alloc sub-channel\n");
> > + return ret;
> > + }
> > + ch->sch[i]->pdev = s_pdev[i];
> > + ch->sch[i]->clkp = clkp;
> > + ch->sch[i]->base = base;
> > + ch->sch[i]->num = i;
> > + ch->sch[i]->start = res->start;
> > + ch->sch[i]->parent = ch;
> > + ch->num_hw_schans++;
> > + }
> > + ch->hw_schans_mask = hw_schans_mask;
> > +
> > + /* Validate any supported format for enabled sub-channels */
> > + ret = rcar_drif_set_default_format(ch);
> > + if (ret)
> > + return ret;
> > +
> > + /* Set defaults */
> > + ch->num_hwbufs = RCAR_DRIF_DEFAULT_NUM_HWBUFS;
> > + ch->hwbuf_size = RCAR_DRIF_DEFAULT_HWBUF_SIZE;
> > +
> > + mutex_init(&ch->v4l2_mutex);
> > + mutex_init(&ch->vb_queue_mutex);
> > + spin_lock_init(&ch->queued_bufs_lock);
> > + INIT_LIST_HEAD(&ch->queued_bufs);
> > +
> > + /* Init videobuf2 queue structure */
> > + ch->vb_queue.type = V4L2_BUF_TYPE_SDR_CAPTURE;
> > + ch->vb_queue.io_modes = VB2_READ | VB2_MMAP | VB2_DMABUF;
> > + ch->vb_queue.drv_priv = ch;
> > + ch->vb_queue.buf_struct_size = sizeof(struct rcar_drif_frame_buf);
> > + ch->vb_queue.ops = &rcar_drif_vb2_ops;
> > + ch->vb_queue.mem_ops = &vb2_vmalloc_memops;
> > + ch->vb_queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > +
> > + /* Init videobuf2 queue */
> > + ret = vb2_queue_init(&ch->vb_queue);
> > + if (ret) {
> > + dev_err(ch->dev, "could not initialize vb2 queue\n");
> > + return ret;
> > + }
> > +
> > + /* Init video_device structure */
> > + ch->vdev = rcar_drif_vdev;
>
> Don't embed video_device, use video_device_alloc instead. A lot of drivers
> embed this, but it turns out not to be a good idea. So new drivers should
> use video_device_alloc.
Agreed.
Thanks,
Ramesh
--
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 v8 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Rob Herring @ 2016-11-14 16:11 UTC (permalink / raw)
To: Joel Holdsworth
Cc: atull, moritz.fischer, geert, devicetree, linux-kernel, linux-spi,
marex, clifford
In-Reply-To: <1478486962-26794-2-git-send-email-joel@airwebreathe.org.uk>
On Sun, Nov 06, 2016 at 07:49:21PM -0700, Joel Holdsworth wrote:
> This adds documentation of the device tree bindings of the Lattice iCE40
> FPGA driver for the FPGA manager framework.
>
> Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
> ---
> .../bindings/fpga/lattice-ice40-fpga-mgr.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver
From: Rob Herring @ 2016-11-14 16:10 UTC (permalink / raw)
To: Andi Shyti
Cc: Jacek Anaszewski, Mauro Carvalho Chehab, Sean Young, Mark Rutland,
Richard Purdie,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux LED Subsystem,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161110100203.2qv6j6acywpjerfi-8vUhnHFVuGn35fTxX1Dczw@public.gmane.org>
On Thu, Nov 10, 2016 at 4:02 AM, Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi Jacek,
>
>> > > > > Only DT bindings of LED class drivers should be placed in
>> > > > > Documentation/devicetree/bindings/leds. Please move it to the
>> > > > > media bindings.
>> > > >
>> > > > that's where I placed it first, but Rob asked me to put it in the
>> > > > LED directory and Cc the LED mailining list.
>> > > >
>> > > > That's the discussion of the version 2:
>> > > >
>> > > > https://lkml.org/lkml/2016/9/12/380
>> > > >
>> > > > Rob, Jacek, could you please agree where I can put the binding?
>> > >
>> > > I'm not sure if this is a good approach. I've noticed also that
>> > > backlight bindings have been moved to leds, whereas they don't look
>> > > similarly.
>> > >
>> > > We have common.txt LED bindings, that all LED class drivers' bindings
>> > > have to follow. Neither backlight bindings nor these ones do that,
>> > > which introduces some mess.
>> >
>> > And there are probably LED bindings that don't follow common.txt either.
>> >
>> > > Eventually adding a sub-directory, e.g. remote_control could make it
>> > > somehow logically justified, but still - shouldn't bindings be
>> > > placed in the documentation directory related to the subsystem of the
>> > > driver they are predestined to?
>> >
>> > No. While binding directories often mirror the driver directories, they
>> > are not the same. Bindings are grouped by types of h/w and IR LEDs are a
>> > type of LED.
>> >
>> > If you prefer a sub-dir, that is fine with me.
>>
>> Fine. So how about sub-dir "ir" ?
>
> would we put here all the remote control bindings that currently
> are under media?
No. Only if they are just an LED that happens to be IR.
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: [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Scott Wood @ 2016-11-14 16:07 UTC (permalink / raw)
To: Sriram Dash, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, felipe.balbi@linux.intel.com,
mathias.nyman@intel.com, catalin.marinas@arm.com,
will.deacon@arm.com, kishon@ti.com, robh+dt@kernel.org,
stern@rowland.harvard.edu, Suresh Gupta,
gregkh@linuxfoundation.org, pku.leo@gmail.com
In-Reply-To: <1479101215-26954-2-git-send-email-sriram.dash@nxp.com>
On 11/13/2016 11:27 PM, Sriram Dash wrote:
> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> new file mode 100644
> index 0000000..d934c80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> @@ -0,0 +1,36 @@
> +Driver for Freescale USB 3.0 PHY
> +
> +Required properties:
> +
> +- compatible : fsl,qoriq-usb3-phy
This is a very vague compatible. Are there versioning registers within
this register block?
> +/* Parameter control */
> +#define USB3PRM1CR 0x000
> +#define USB3PRM1CR_VAL 0x27672b2a
> +
> +/*
> + * struct qoriq_usb3_phy - driver data for USB 3.0 PHY
> + * @dev: pointer to device instance of this platform device
> + * @param_ctrl: usb3 phy parameter control register base
> + * @phy_base: usb3 phy register memory base
> + * @has_erratum_flag: keeps track of erratum applicable on device
> + */
> +struct qoriq_usb3_phy {
> + struct device *dev;
> + void __iomem *param_ctrl;
> + void __iomem *phy_base;
> + u32 has_erratum_flag;
> +};
> +
> +static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32 offset)
> +{
> + return __raw_readl(addr + offset);
> +}
> +
> +static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
> + u32 data)
> +{
> + __raw_writel(data, addr + offset);
> +}
Why raw? Besides missing barriers, this will cause the accesses to be
native-endian which is not correct.
> +/*
> + * Erratum A008751
> + * SCFG USB3PRM1CR has incorrect default value
> + * SCFG USB3PRM1CR reset value should be 32'h27672B2A instead of 32'h25E72B2A.
When documenting C code, can you stick with C-style numeric constants?
For that matter, just put the constant in the code instead of hiding it
in an overly-generically-named USB3PRM1CR_VAL and then you won't need to
redundantly state the value in a comment. Normally putting magic
numbers in symbolic constants is a good thing, but in this case it's not
actually describing anything and the number is of no meaning outside of
this one erratum workaround (it might even be a different value if
another chip has a similar erratum).
> + */
> +static void erratum_a008751(struct qoriq_usb3_phy *phy)
> +{
> + qoriq_usb3_phy_writel(phy->param_ctrl, USB3PRM1CR,
> + USB3PRM1CR_VAL);
> +}
> +
> +/*
> + * qoriq_usb3_phy_erratum - List of phy erratum
> + * @qoriq_phy_erratum - erratum application
> + * @compat - comapt string for erratum
> + */
> +
> +struct qoriq_usb3_phy_erratum {
> + void (*qoriq_phy_erratum)(struct qoriq_usb3_phy *phy);
> + char *compat;
> +};
> +
> +/* Erratum list */
> +struct qoriq_usb3_phy_erratum phy_erratum_tbl[] = {
> + {&erratum_a008751, "fsl,usb-erratum-a008751"},
> + /* Add init time erratum here */
> +};
This needs to be static.
Unnecessary & on the function pointer.
> +static int qoriq_usb3_phy_init(struct phy *x)
> +{
> + struct qoriq_usb3_phy *phy = phy_get_drvdata(x);
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(phy_erratum_tbl); i++)
> + if (phy->has_erratum_flag & 1 << i)
> + phy_erratum_tbl[i].qoriq_phy_erratum(phy);
> + return 0;
> +}
> +
> +static const struct phy_ops ops = {
> + .init = qoriq_usb3_phy_init,
> + .owner = THIS_MODULE,
> +};
> +
> +static int qoriq_usb3_phy_probe(struct platform_device *pdev)
> +{
> + struct qoriq_usb3_phy *phy;
> + struct phy *generic_phy;
> + struct phy_provider *phy_provider;
> + const struct of_device_id *of_id;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + int i, ret;
> +
> + phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
> + if (!phy)
> + return -ENOMEM;
> + phy->dev = dev;
> +
> + of_id = of_match_device(dev->driver->of_match_table, dev);
> + if (!of_id) {
> + dev_err(dev, "failed to get device match\n");
> + ret = -EINVAL;
> + goto err_out;
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "param_ctrl");
> + if (!res) {
> + dev_err(dev, "failed to get param_ctrl memory\n");
> + ret = -ENOENT;
> + goto err_out;
> + }
> +
> + phy->param_ctrl = devm_ioremap_resource(dev, res);
> + if (!phy->param_ctrl) {
> + dev_err(dev, "failed to remap param_ctrl memory\n");
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy_base");
> + if (!res) {
> + dev_err(dev, "failed to get phy_base memory\n");
> + ret = -ENOENT;
> + goto err_out;
> + }
> +
> + phy->phy_base = devm_ioremap_resource(dev, res);
> + if (!phy->phy_base) {
> + dev_err(dev, "failed to remap phy_base memory\n");
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + phy->has_erratum_flag = 0;
> + for (i = 0; i < ARRAY_SIZE(phy_erratum_tbl); i++)
> + phy->has_erratum_flag |= device_property_read_bool(dev,
> + phy_erratum_tbl[i].compat) << i;
I don't see the erratum property in either the binding or the device
tree. Also, a property name is not a "compat".
Is there a reason why this flag and array mechanism is needed, rather
than just checking the erratum properties from the init function -- or,
if you have a good reason to not want to do device tree accesses from
init, just using a bool per erratum? How many errata are you expecting?
-Scott
^ permalink raw reply
* Re: [PATCH v2 3/9] arm64: dts: rockchip: add VOP and VOP iommu node for rk3399
From: Heiko Stuebner @ 2016-11-14 16:05 UTC (permalink / raw)
To: Caesar Wang
Cc: eddie.cai-TNX95d0MmH7DzftRWevZcw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
Mark Yao, Yakir Yang, Douglas Anderson, David Wu, Jianqun Xu,
devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, zhangqing,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Will Deacon, Ziyuan Xu, Mark Rutland, Catalin Marinas,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478697721-2323-4-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Mittwoch, 9. November 2016, 21:21:55 CET schrieb Caesar Wang:
> From: Mark Yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Add the core display-subsystem node and the two display controllers
> available on the rk3399.
>
> Signed-off-by: Mark Yao <mark.yao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Yakir Yang <ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Changes in v2: None
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 58
> ++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index e5b5b3d..f1d289a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1290,6 +1290,64 @@
> status = "disabled";
> };
>
> + vopl: vop@ff8f0000 {
> + compatible = "rockchip,rk3399-vop-lit";
> + reg = <0x0 0xff8f0000 0x0 0x3efc>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
we're usig 4 irq elements nowadays to accomodate the pmus for separate
clusters, see
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=210bbd38bb88989ce19208f98e530ff0468f38bd
Same for the edp node.
Also, sadly the rockchip drm seems to need some tweaks still, as I wasn't
able to get any display output yet.
To make the vop at least compile I needed to forward-port
https://github.com/mmind/linux-rockchip/commit/05ad856e54fc1aa1939ad1057897036cedc7fb0b
https://github.com/mmind/linux-rockchip/commit/0edb1f7e1ac77437a17d7966121ee6e10ab5db67
[full branch is https://github.com/mmind/linux-rockchip/commits/tmp/testing_20161109 ]
but I'm not sure if I did that correctly yet and am also still seeing
nothing on the display and get iommu errors when starting X11
Heiko
> + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_A_VOP1>, <&cru SRST_H_VOP1>, <&cru SRST_D_VOP1>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&vopl_mmu>;
> + status = "disabled";
> +
> + vopl_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + vopl_mmu: iommu@ff8f3f00 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xff8f3f00 0x0 0x100>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "vopl_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + vopb: vop@ff900000 {
> + compatible = "rockchip,rk3399-vop-big";
> + reg = <0x0 0xff900000 0x0 0x3efc>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_A_VOP0>, <&cru SRST_H_VOP0>, <&cru SRST_D_VOP0>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&vopb_mmu>;
> + status = "disabled";
> +
> + vopb_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + vopb_mmu: iommu@ff903f00 {
> + compatible = "rockchip,iommu";
> + reg = <0x0 0xff903f00 0x0 0x100>;
> + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "vopb_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + display_subsystem: display-subsystem {
> + compatible = "rockchip,display-subsystem";
> + ports = <&vopl_out>, <&vopb_out>;
> + status = "disabled";
> + };
> +
> pinctrl: pinctrl {
> compatible = "rockchip,rk3399-pinctrl";
> rockchip,grf = <&grf>;
--
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] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Alexandre Belloni @ 2016-11-14 16:04 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nicolas Ferre,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1479138250-17780-2-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On 14/11/2016 at 15:44:08 +0000, Sudeep Holla wrote :
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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] usb: dwc2: add amcc,dwc-otg device tree definition
From: Rob Herring @ 2016-11-14 16:04 UTC (permalink / raw)
To: Christian Lamparter
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, John Youn, Mark Rutland,
Greg Kroah-Hartman
In-Reply-To: <20161106005608.26386-1-chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sun, Nov 06, 2016 at 01:56:08AM +0100, Christian Lamparter wrote:
> This patch adds support for the "amcc,usb-otg" device
> which is found in the PowerPC Canyonlands' dts.
>
> The device definition was added by:
> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board")'.
> AMCC produced a standalone driver that was sent to the
> linuxppc-dev at the time. However, it was never integrated.
>
> Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> For anyone interested: the driver was sent to the ML multiple times back
> in 2012 [0], [1].
>
> [0] <https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-May/097847.html>
> [1] <https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-May/097938.html>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
I would say this needs to be more specific, but given it has been there
for 6 years:
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/usb/dwc2/platform.c | 33 ++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] mfd: rn5t618: Add Ricoh RC5T619 PMIC support
From: Rob Herring @ 2016-11-14 16:02 UTC (permalink / raw)
To: Pierre-Hugues Husson
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161105161925.14910-2-phh-8tEavu1zA38@public.gmane.org>
On Sat, Nov 05, 2016 at 05:19:24PM +0100, Pierre-Hugues Husson wrote:
> The Ricoh RN5T567 is from the same family as the Ricoh RN5T618 is,
> the differences are:
>
> + DCDC4/DCDC5
> + LDO7-10
> + Slightly different output voltage/currents
> + 32kHz Output
> + RTC
> + USB Charger detection
>
> Signed-off-by: Pierre-Hugues Husson <phh-8tEavu1zA38@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mfd/rn5t618.txt | 16 ++++++++++------
> drivers/mfd/Kconfig | 3 ++-
> drivers/mfd/rn5t618.c | 1 +
> include/linux/mfd/rn5t618.h | 9 +++++++++
> 4 files changed, 22 insertions(+), 7 deletions(-)
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 v4 2/2] i2c: aspeed: added documentation for Aspeed I2C driver
From: Rob Herring @ 2016-11-14 15:57 UTC (permalink / raw)
To: Brendan Higgins; +Cc: wsa, mark.rutland, linux-i2c, devicetree, joel, openbmc
In-Reply-To: <1478311099-6771-3-git-send-email-brendanhiggins@google.com>
On Fri, Nov 04, 2016 at 06:58:19PM -0700, Brendan Higgins wrote:
> Added device tree binding documentation for Aspeed I2C controller and
> busses.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> ---
> Changes for v2:
> - None
> Changes for v3:
> - Removed reference to "bus" device tree param
> Changes for v4:
> - None
> ---
> .../devicetree/bindings/i2c/i2c-aspeed.txt | 61 ++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 09/11] ARM: shmobile: document SK-RZG1E board
From: Rob Herring @ 2016-11-14 15:56 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: horms, linux-renesas-soc, mark.rutland, devicetree
In-Reply-To: <4775558.KSi1d1GNCP@wasted.cogentembedded.com>
On Sat, Nov 05, 2016 at 01:02:25AM +0300, Sergei Shtylyov wrote:
> Document the SK-RZG1E device tree bindings, listing it as a supported board.
>
> This allows to use checkpatch.pl to validate .dts files referring to the
> SK-RZG1E board.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> ---
> Changes in version 2:
> - fixed the subject;
> - added Geert's tag.
>
> Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 03/11] ARM: shmobile: r8a7745: basic SoC support
From: Rob Herring @ 2016-11-14 15:55 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: horms-/R6kz+dDXgpPR4JQBCEnsQ,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1611958.qRQu5pdJd3-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
On Sat, Nov 05, 2016 at 12:49:55AM +0300, Sergei Shtylyov wrote:
> Add minimal support for the RZ/G1E (R8A7745) SoC.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>
> ---
> Changes in version 2:
> - added Geert's tag;
> - refreshed the patch.
>
> Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
> arch/arm/mach-shmobile/Kconfig | 4 ++++
> arch/arm/mach-shmobile/setup-rcar-gen2.c | 1 +
> 3 files changed, 7 insertions(+)
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 02/11] soc: renesas: rcar-sysc: add R8A7745 support
From: Rob Herring @ 2016-11-14 15:54 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: horms, linux-renesas-soc, mark.rutland, devicetree
In-Reply-To: <1834171.PEVAvqbuLx@wasted.cogentembedded.com>
On Sat, Nov 05, 2016 at 12:46:13AM +0300, Sergei Shtylyov wrote:
> Add support for RZ/G1E (R8A7745) SoC power areas to the R-Car SYSC driver.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> ---
> Changes in version 2:
> - added Geert's tag.
>
> Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt | 1
Acked-by: Rob Herring <robh@kernel.org>
> drivers/soc/renesas/Makefile | 1
> drivers/soc/renesas/r8a7745-sysc.c | 32 ++++++++++
> drivers/soc/renesas/rcar-sysc.c | 3
> drivers/soc/renesas/rcar-sysc.h | 1
> 5 files changed, 38 insertions(+)
^ permalink raw reply
* RE: [PATCH 2/5] media: i2c: max2175: Add MAX2175 support
From: Ramesh Shanmugasundaram @ 2016-11-14 15:54 UTC (permalink / raw)
To: Hans Verkuil, robh+dt@kernel.org, mark.rutland@arm.com,
mchehab@kernel.org, sakari.ailus@linux.intel.com, crope@iki.fi
Cc: Chris Paterson, laurent.pinchart@ideasonboard.com,
geert+renesas@glider.be, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <46394837-c3f0-8487-750b-95dae7bcf859@xs4all.nl>
Hi Hans,
Thank you for the review comments.
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds driver support for MAX2175 chip. This is Maxim
> > Integrated's RF to Bits tuner front end chip designed for
> > software-defined radio solutions. This driver exposes the tuner as a
> > sub-device instance with standard and custom controls to configure the
> device.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram@bp.renesas.com>
> > ---
> > .../devicetree/bindings/media/i2c/max2175.txt | 61 +
> > drivers/media/i2c/Kconfig | 4 +
> > drivers/media/i2c/Makefile | 2 +
> > drivers/media/i2c/max2175/Kconfig | 8 +
> > drivers/media/i2c/max2175/Makefile | 4 +
> > drivers/media/i2c/max2175/max2175.c | 1558
> ++++++++++++++++++++
> > drivers/media/i2c/max2175/max2175.h | 108 ++
> > 7 files changed, 1745 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/i2c/max2175.txt
> > create mode 100644 drivers/media/i2c/max2175/Kconfig create mode
> > 100644 drivers/media/i2c/max2175/Makefile
> > create mode 100644 drivers/media/i2c/max2175/max2175.c
> > create mode 100644 drivers/media/i2c/max2175/max2175.h
> >
>
> <snip>
>
> > diff --git a/drivers/media/i2c/max2175/max2175.c
> > b/drivers/media/i2c/max2175/max2175.c
> > new file mode 100644
> > index 0000000..ec45b52
> > --- /dev/null
> > +++ b/drivers/media/i2c/max2175/max2175.c
> > @@ -0,0 +1,1558 @@
>
> <snip>
>
> > +/* Read/Write bit(s) on top of regmap */ static int
> > +max2175_read(struct max2175 *ctx, u8 idx, u8 *val) {
> > + u32 regval;
> > + int ret = regmap_read(ctx->regmap, idx, ®val);
> > +
> > + if (ret)
> > + v4l2_err(ctx->client, "read ret(%d): idx 0x%02x\n", ret, idx);
> > +
> > + *val = regval;
>
> Does regmap_read initialize regval even if it returns an error? If not,
> then I would initialize regval to 0 to prevent *val being uninitialized.
Agreed.
>
> > + return ret;
> > +}
> > +
> > +static int max2175_write(struct max2175 *ctx, u8 idx, u8 val) {
> > + int ret = regmap_write(ctx->regmap, idx, val);
> > +
> > + if (ret)
> > + v4l2_err(ctx->client, "write ret(%d): idx 0x%02x val
> 0x%02x\n",
> > + ret, idx, val);
> > + return ret;
> > +}
> > +
> > +static u8 max2175_read_bits(struct max2175 *ctx, u8 idx, u8 msb, u8
> > +lsb) {
> > + u8 val;
> > +
> > + if (max2175_read(ctx, idx, &val))
> > + return 0;
> > +
> > + return max2175_get_bitval(val, msb, lsb); }
> > +
> > +static bool max2175_read_bit(struct max2175 *ctx, u8 idx, u8 bit) {
> > + return !!max2175_read_bits(ctx, idx, bit, bit); }
> > +
> > +static int max2175_write_bits(struct max2175 *ctx, u8 idx,
> > + u8 msb, u8 lsb, u8 newval)
> > +{
> > + int ret = regmap_update_bits(ctx->regmap, idx, GENMASK(msb, lsb),
> > + newval << lsb);
> > +
> > + if (ret)
> > + v4l2_err(ctx->client, "wbits ret(%d): idx 0x%02x\n", ret,
> idx);
> > +
> > + return ret;
> > +}
> > +
> > +static int max2175_write_bit(struct max2175 *ctx, u8 idx, u8 bit, u8
> > +newval) {
> > + return max2175_write_bits(ctx, idx, bit, bit, newval); }
> > +
> > +/* Checks expected pattern every msec until timeout */ static int
> > +max2175_poll_timeout(struct max2175 *ctx, u8 idx, u8 msb, u8 lsb,
> > + u8 exp_bitval, u32 timeout_ms)
> > +{
> > + unsigned int val;
> > +
> > + return regmap_read_poll_timeout(ctx->regmap, idx, val,
> > + (max2175_get_bitval(val, msb, lsb) == exp_bitval),
> > + 1000, timeout_ms * 1000);
> > +}
> > +
> > +static int max2175_poll_csm_ready(struct max2175 *ctx) {
> > + int ret;
> > +
> > + ret = max2175_poll_timeout(ctx, 69, 1, 1, 0, 50);
> > + if (ret)
> > + v4l2_err(ctx->client, "csm not ready\n");
> > +
> > + return ret;
> > +}
> > +
> > +#define MAX2175_IS_BAND_AM(ctx) \
> > + (max2175_read_bits(ctx, 5, 1, 0) == MAX2175_BAND_AM)
> > +
> > +#define MAX2175_IS_BAND_VHF(ctx) \
> > + (max2175_read_bits(ctx, 5, 1, 0) == MAX2175_BAND_VHF)
> > +
> > +#define MAX2175_IS_FM_MODE(ctx) \
> > + (max2175_read_bits(ctx, 12, 5, 4) == 0)
> > +
> > +#define MAX2175_IS_FMHD_MODE(ctx) \
> > + (max2175_read_bits(ctx, 12, 5, 4) == 1)
> > +
> > +#define MAX2175_IS_DAB_MODE(ctx) \
> > + (max2175_read_bits(ctx, 12, 5, 4) == 2)
> > +
> > +static int max2175_band_from_freq(u32 freq) {
> > + if (freq >= 144000 && freq <= 26100000)
> > + return MAX2175_BAND_AM;
> > + else if (freq >= 65000000 && freq <= 108000000)
> > + return MAX2175_BAND_FM;
> > + else
>
> No need for these 'else' keywords.
Agreed.
>
> > + return MAX2175_BAND_VHF;
> > +}
> > +
> > +static int max2175_update_i2s_mode(struct max2175 *ctx, u32 rx_mode,
> > + u32 i2s_mode)
> > +{
> > + max2175_write_bits(ctx, 29, 2, 0, i2s_mode);
> > +
> > + /* Based on I2S mode value I2S_WORD_CNT values change */
> > + switch (i2s_mode) {
> > + case MAX2175_I2S_MODE3:
> > + max2175_write_bits(ctx, 30, 6, 0, 1);
> > + break;
> > + case MAX2175_I2S_MODE2:
> > + case MAX2175_I2S_MODE4:
> > + max2175_write_bits(ctx, 30, 6, 0, 0);
> > + break;
> > + case MAX2175_I2S_MODE0:
> > + max2175_write_bits(ctx, 30, 6, 0,
> > + ctx->rx_modes[rx_mode].i2s_word_size);
> > + break;
> > + }
> > + mxm_dbg(ctx, "update_i2s_mode %u, rx_mode %u\n", i2s_mode, rx_mode);
> > + return 0;
> > +}
[snip]
> > +
> > +static int max2175_enum_freq_bands(struct v4l2_subdev *sd,
> > + struct v4l2_frequency_band *band) {
> > + struct max2175 *ctx = max2175_from_sd(sd);
> > +
> > + if (band->tuner == 0 && band->index == 0)
> > + *band = *ctx->bands_rf;
> > + else
> > + return -EINVAL;
>
> This is a bit ugly. I would invert the condition and return -EINVAL.
> Then assign *band and return 0.
Agreed.
>
> > +
> > + return 0;
> > +}
> > +
> > +static int max2175_g_tuner(struct v4l2_subdev *sd, struct v4l2_tuner
> > +*vt) {
> > + struct max2175 *ctx = max2175_from_sd(sd);
> > +
> > + if (vt->index > 0)
> > + return -EINVAL;
> > +
> > + strlcpy(vt->name, "RF", sizeof(vt->name));
> > + vt->type = V4L2_TUNER_RF;
> > + vt->capability = V4L2_TUNER_CAP_1HZ | V4L2_TUNER_CAP_FREQ_BANDS;
> > + vt->rangelow = ctx->bands_rf->rangelow;
> > + vt->rangehigh = ctx->bands_rf->rangehigh;
> > + return 0;
> > +}
> > +
> > +static int max2175_s_tuner(struct v4l2_subdev *sd, const struct
> > +v4l2_tuner *vt) {
> > + /* Check tuner index is valid */
> > + if (vt->index > 0)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +static const struct v4l2_subdev_tuner_ops max2175_tuner_ops = {
> > + .s_frequency = max2175_s_frequency,
> > + .g_frequency = max2175_g_frequency,
> > + .enum_freq_bands = max2175_enum_freq_bands,
> > + .g_tuner = max2175_g_tuner,
> > + .s_tuner = max2175_s_tuner,
> > +};
> > +
> > +static const struct v4l2_subdev_ops max2175_ops = {
> > + .tuner = &max2175_tuner_ops,
> > +};
> > +
> > +static const struct v4l2_ctrl_ops max2175_ctrl_ops = {
> > + .s_ctrl = max2175_s_ctrl,
> > + .g_volatile_ctrl = max2175_g_volatile_ctrl, };
> > +
> > +static const struct v4l2_ctrl_config max2175_i2s_en = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_I2S_ENABLE,
> > + .name = "I2S Enable",
> > + .type = V4L2_CTRL_TYPE_BOOLEAN,
> > + .min = 0,
> > + .max = 1,
> > + .step = 1,
> > + .def = 1,
> > +};
> > +
> > +static const char * const max2175_ctrl_i2s_modes[] = {
> > + [MAX2175_I2S_MODE0] = "i2s mode 0",
> > + [MAX2175_I2S_MODE1] = "i2s mode 1 (skipped)",
> > + [MAX2175_I2S_MODE2] = "i2s mode 2",
> > + [MAX2175_I2S_MODE3] = "i2s mode 3",
> > + [MAX2175_I2S_MODE4] = "i2s mode 4",
> > +};
> > +
> > +static const struct v4l2_ctrl_config max2175_i2s_mode = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_I2S_MODE,
> > + .name = "I2S MODE value",
> > + .type = V4L2_CTRL_TYPE_MENU,
> > + .max = ARRAY_SIZE(max2175_ctrl_i2s_modes) - 1,
> > + .def = 0,
> > + .menu_skip_mask = 0x02,
> > + .qmenu = max2175_ctrl_i2s_modes,
> > +};
>
> Is this something that is changed dynamically? It looks more like a device
> tree thing (it's not clear what it does, so obviously I can't be sure).
Yes. It can be changed dynamically.
>
> > +
> > +static const struct v4l2_ctrl_config max2175_hsls = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_HSLS,
> > + .name = "HSLS above/below desired",
> > + .type = V4L2_CTRL_TYPE_INTEGER,
> > + .min = 0,
> > + .max = 1,
> > + .step = 1,
> > + .def = 1,
> > +};
> > +
> > +static const char * const max2175_ctrl_eu_rx_modes[] = {
> > + [MAX2175_EU_FM_1_2] = "EU FM 1.2",
> > + [MAX2175_DAB_1_2] = "DAB 1.2",
> > +};
> > +
> > +static const char * const max2175_ctrl_na_rx_modes[] = {
> > + [MAX2175_NA_FM_1_0] = "NA FM 1.0",
> > + [MAX2175_NA_FM_2_0] = "NA FM 2.0",
> > +};
> > +
> > +static const struct v4l2_ctrl_config max2175_eu_rx_mode = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_RX_MODE,
> > + .name = "RX MODE",
> > + .type = V4L2_CTRL_TYPE_MENU,
> > + .max = ARRAY_SIZE(max2175_ctrl_eu_rx_modes) - 1,
> > + .def = 0,
> > + .qmenu = max2175_ctrl_eu_rx_modes,
> > +};
> > +
> > +static const struct v4l2_ctrl_config max2175_na_rx_mode = {
> > + .ops = &max2175_ctrl_ops,
> > + .id = V4L2_CID_MAX2175_RX_MODE,
> > + .name = "RX MODE",
> > + .type = V4L2_CTRL_TYPE_MENU,
> > + .max = ARRAY_SIZE(max2175_ctrl_na_rx_modes) - 1,
> > + .def = 0,
> > + .qmenu = max2175_ctrl_na_rx_modes,
> > +};
>
> Please document all these controls better. This is part of the public API,
> so you need to give more information what this means exactly.
Thanks. Now, I have added a one-liner and a bit descriptive explanation at Documentation/media/v4l-drivers dir as you & Laurent concluded.
Thanks,
Ramesh
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: fixed: dt: Allow an optional over current pin
From: Rob Herring @ 2016-11-14 15:54 UTC (permalink / raw)
To: Axel Haslam
Cc: broonie, girdwood, khilman, nsekhar, david, linux-kernel,
devicetree
In-Reply-To: <20161104213536.28496-2-ahaslam@baylibre.com>
On Fri, Nov 04, 2016 at 10:35:35PM +0100, Axel Haslam wrote:
> Add support for an optional over current input pin which
> can be used to send an over current event to the regulator
> consumer.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
> Documentation/devicetree/bindings/regulator/fixed-regulator.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* RE: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
From: Ramesh Shanmugasundaram @ 2016-11-14 15:53 UTC (permalink / raw)
To: Hans Verkuil, Laurent Pinchart
Cc: Antti Palosaari, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Chris Paterson, geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <fb15b6f3-6c5c-0922-8655-aabd4799d158-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Hello Laurent, Antti, Hans,
> Subject: Re: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
>
> On 11/11/2016 02:57 PM, Laurent Pinchart wrote:
> > Hi Hans,
> >
> > On Friday 11 Nov 2016 14:53:58 Hans Verkuil wrote:
> >> On 11/10/2016 09:08 AM, Laurent Pinchart wrote:
> >>> Antti, Hans, ping ? Please see below.
> >>>
> >>> On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
> >>>>> On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
> >>>>>> On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
> >>>>>>>>> On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
> >>>>>>>>>> This patch adds documentation for the three new SDR formats
> >>>>>>>>>>
> >>>>>>>>>> V4L2_SDR_FMT_SCU16BE
> >>>>>>>>>> V4L2_SDR_FMT_SCU18BE
> >>>>>>>>>> V4L2_SDR_FMT_SCU20BE
> >>>>>>>
> >>>>>>> [snip]
> >>>>>>>
> >>>>>>>>>> +
> >>>>>>>>>> + - start + 0:
> >>>>>>>>>> +
> >>>>>>>>>> + - I'\ :sub:`0[D13:D6]`
> >>>>>>>>>> +
> >>>>>>>>>> + - I'\ :sub:`0[D5:D0]`
> >>>>>>>>>> +
> >>>>>>>>>> + - .. row 2
> >>>>>>>>>> +
> >>>>>>>>>> + - start + buffer_size/2:
> >>>>>>>>>> +
> >>>>>>>>>> + - Q'\ :sub:`0[D13:D6]`
> >>>>>>>>>> +
> >>>>>>>>>> + - Q'\ :sub:`0[D5:D0]`
> >>>>>>>>>
> >>>>>>>>> The format looks planar, does it use one V4L2 plane (as does
> >>>>>>>>> NV12) or two V4L2 planes (as does NV12M) ? Same question for
> >>>>>>>>> the other formats.
> >>>>>>>>
> >>>>>>>> Thank you for bringing up this topic. This is one of the key
> >>>>>>>> design dilemma.
> >>>>>>>>
> >>>>>>>> The I & Q data for these three SDR formats comes from two
> >>>>>>>> different DMA channels and hence two separate pointers -> we
> >>>>>>>> could say it is
> >>>>>>>> v4l2 multi- planar. Right now, I am making it look like a
> >>>>>>>> single plane by presenting the data in one single buffer ptr.
> >>>>>>>>
> >>>>>>>> For e.g. multi-planar SC16 format would look something like
> >>>>>>>> this
> >>>>>>>>
> >>>>>>>> <------------------------32bits---------------------->
> >>>>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0
> >>>>>>>> + 0
> >>>>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0
> >>>>>>>> + 4 ...
> >>>>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1
> >>>>>>>> + 0
> >>>>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1
> >>>>>>>> + 4
> >>>>>>>>
> >>>>>>>> My concerns are
> >>>>>>>>
> >>>>>>>> 1) These formats are not a standard as the video "Image Formats".
> >>>>>>>> These formats are possible when we use DRIF + MAX2175
> combination.
> >>>>>>>> If we interface with a different tuner vendor, the above
> >>>>>>>> format(s) MAY/MAY NOT be re-usable. We do not know at this
> >>>>>>>> point. This is the main open item for discussion in the cover
> letter.
> >>>>>>
> >>>>>> If the formats are really device-specific then they should be
> >>>>>> documented accordingly and not made generic.
> >>>>>>
> >>>>>>>> 2) MPLANE support within V4L2 seems specific to video. Please
> >>>>>>>> correct me if this is wrong interpretation.
> >>>>>>>>
> >>>>>>>> - struct v4l2_format contains v4l2_sdr_format and
> >>>>>>>> v4l2_pix_format_mplane as members of union. Should I create a
> >>>>>>>> new v4l2_sdr_format_mplane? If I have to use
> >>>>>>>> v4l2_pix_format_mplane most of the video specific members would
> >>>>>>>> be unused (it would be similar to using v4l2_pix_format itself
> instead of v4l2_sdr_format)?
> >>>>>>
> >>>>>> I have no answer to that question as I'm not familiar with SDR.
> >>>>>> Antti, you've added v4l2_sdr_format to the API, what's your
> >>>>>> opinion ? Hans, as you've acked the patch, your input would be
> appreciated as well.
> >>>>>
> >>>>> If I understood correctly this hardware provides I and Q samples
> >>>>> via different channels and driver now combines those channels as a
> >>>>> sequential IQ sample pairs.
> >>>>
> >>>> The driver combines the two buffer ptrs and present as one single
> buffer.
> >>>> For a buffer of size 200
> >>>>
> >>>> ptr + 0 : I I I I ... I
> >>>> ptr + 100 : Q Q Q Q ... Q
> >>>>
> >>>>> I have never seen any other than hw which provides IQ IQ IQ IQ ...
> IQ.
> >>>>
> >>>> There are some modes where this h/w combo can also do IQ IQ IQ
> pattern.
> >>>> Those modes are not added in the RFC patchset.
> >>>>
> >>>>> This is
> >>>>> I I I I ... I
> >>>>> Q Q Q Q ... Q
> >>>>> I am not very familiar with planars, but it sounds like it is
> >>>>> correct approach. So I think should be added rather than emulate
> >>>>> packet sequential format.
> >>>>
> >>>> My understanding of V4L2 MPLANE constructs is limited to a quick
> >>>> code read only. At this point MPLANE support seems specific to
> >>>> video. SDR is defined as separate format like v4l2_pix_format.
> >>>> Questions would be - should we define new SDR_MPLANE? or merge SDR
> >>>> format with pix format & reuse existing MPLANE with some SDR
> >>>> extensions (if possible)? These seem big design decisions. Any
> >>>> suggestions please?
> >>>>
> >>>> For my use case, MPLANE support does not seem to add significant
> >>>> benefit except it may be syntactically correct. I am doing cyclic
> >>>> DMA with a small set of h/w buffers and copying each stage to one
> >>>> mmapped vmalloc vb2_buffer at two offsets. If we add MPLANE
> >>>> support, it can be two non-contiguous buffer pointers.
> >>>>
> >>>>>>>> - The above decision (accomodate SDR & MPLANE) needs to be
> >>>>>>>> propagated across the framework. Is this the preferred approach?
> >>>>>>>>
> >>>>>>>> It goes back to point (1). As of today, the change set for this
> >>>>>>>> combo (DRIF+MAX2175) introduces new SDR formats only. Should it
> >>>>>>>> add further SDR+MPLANE support to the framework as well?
> >>>>>>>>
> >>>>>>>> I would appreciate your suggestions on this regard.
> >>
> >> Some terminology first:
> >>
> >> Planar formats separate the data into different memory areas: in this
> >> case one part is all I and one part is all Q. This as opposed to
> >> interleaved formats (IQIQIQIQ....).
> >>
> >> As long as both planes fit in the same buffer all is fine. Since that
> >> is the case here there is no need to introduce a new MPLANE API.
> >>
> >> The MPLANE API was added for video to handle cases where the two
> >> planes had to be in two different non-contiguous buffers.
> >
> > Not only that, it can also be used for cases where storing the two
> > planes in separate buffers can be beneficial, even if a single
> > contiguous buffer could work.
> >
> >> So instead of passing one buffer pointer, you need to pass two or
> >> more buffer pointers.
> >>
> >> In hindsight we should have called it the MBUFFER API.
> >
> > The name was badly chosen, yes.
> >
> >> Oh well...
> >>
> >> Anyway, since there is no problem here apparently to keep both planes
> >> in one buffer there is also no need to introduce a SDR_MPLANE.
> >
> > The question here is whether there could be a benefit in separating I
> > and Q data in two buffers compared to storing them in the same buffer.
> >
>
> The MPLANE API is very messy and introducing something like SDR_MPLANE is
> not something I would promote. If we want that, then we should first make
> a new v4l2_buffer struct that simplifies MPLANE handling (we discussed
> that before).
Thank you for the comments and closure on this topic.
Thanks,
Ramesh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/2] Documentation: dt: reset: Add TI SCI reset binding
From: Rob Herring @ 2016-11-14 15:52 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Philipp Zabel,
Mark Rutland, Suman Anna,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161104174240.9688-2-afd-l0cyMroinI0@public.gmane.org>
On Fri, Nov 04, 2016 at 12:42:39PM -0500, Andrew F. Davis wrote:
> Add TI SCI reset controller binding. This describes the DT binding
> details for a reset controller node providing reset management services
> to hardware blocks (reset consumers) using the Texas Instrument's System
> Control Interface (TI SCI) protocol to communicate to a system controller
> block present on the SoC.
>
> Signed-off-by: Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org>
> [s-anna-l0cyMroinI0@public.gmane.org: revise the binding format]
> Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> ---
> .../devicetree/bindings/reset/ti,sci-reset.txt | 65 ++++++++++++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/reset/k2g.h | 22 ++++++++
> 3 files changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 include/dt-bindings/reset/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> new file mode 100644
> index 0000000..cb00679
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> @@ -0,0 +1,65 @@
> +Texas Instruments System Control Interface (TI-SCI) Reset Controller
> +=====================================================================
> +
> +Some TI SoCs contain a system controller (like the Power Management Micro
> +Controller (PMMC) on Keystone K2G SoC) that are responsible for controlling
> +the state of the various hardware modules present on the SoC. Communication
> +between the host processor running an OS and the system controller happens
> +through a protocol called TI System Control Interface (TI-SCI protocol).
> +For TI SCI details, please refer to the document,
> +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +TI-SCI Reset Controller Node
> +============================
> +This reset controller node uses the TI SCI protocol to perform the reset
> +management of various hardware modules present on the SoC.
Needs to say must be a child of the SCI node somewhere in here.
> +
> +Required properties:
> +--------------------
> + - compatible : Should be "ti,sci-reset"
> + - #reset-cells : Should be 2. Please see the reset consumer node below for
> + usage details.
> +
> +TI-SCI Reset Consumer Nodes
> +===========================
> +Each of the reset consumer nodes should have the following properties,
> +in addition to their own properties.
> +
> +Required properties:
> +--------------------
> + - resets : A phandle and reset specifier pair, one pair for each reset
> + signal that affects the device, or that the device manages.
> + The phandle should point to the TI-SCI reset controller node,
> + and the reset specifier should have 2 cell-values. The first
> + cell should contain the device ID, the values of which are
> + specified in the <dt-bindings/genpd/<soc>.h> include file.
> + The second cell should contain the reset mask value used by
> + system controller, the values of which are specified in the
> + include file <dt-bindings/reset/<soc>.h>, where <soc> is the
> + name of the SoC involved, for example 'k2g'.
> +
> +Please also refer to Documentation/devicetree/bindings/reset/reset.txt for
> +common reset controller usage by consumers.
> +
> +Example:
> +--------
> +The following example demonstrates both a TI-SCI reset controller node and a
> +consumer (a DSP device) on the K2G SoC.
> +
> +#include <dt-bindings/genpd/k2g.h>
> +#include <dt-bindings/reset/k2g.h>
> +
> +pmmc: pmmc {
> + compatible = "ti,k2g-sci";
> +
> + k2g_reset: k2g_reset {
...: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> +};
> +
> +dsp0: dsp0 {
> + ...
> + resets = <&k2g_reset K2G_DEV_CGEM0 K2G_DEV_CGEM0_DSP0_RESET>;
> + ...
> +};
--
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] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Sudeep Holla @ 2016-11-14 15:51 UTC (permalink / raw)
To: Nicolas Ferre
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Belloni,
Jean-Christophe Plagniol-Villard
In-Reply-To: <55e95acc-d30f-432e-90d6-f96bad69ac3d-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
On 14/11/16 15:45, Nicolas Ferre wrote:
> Le 14/11/2016 à 16:44, Sudeep Holla a écrit :
>> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
>> check for/support the legacy "gpio-key,wakeup" boolean property to
>> enable gpio buttons as wakeup source, "wakeup-source" is the new
>> standard binding.
>>
>> This patch replaces the legacy "gpio-key,wakeup" with the unified
>> "wakeup-source" property in order to avoid any further copy-paste
>> duplication.
>>
>> Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>
> Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>
>> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>> ---
>> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Hi,
>>
>> Inspite of getting rid of most of the legacy property almost a year ago,
>> addition of new platforms have brought this back and over time it's
>> now found again in few places. Just get rid of them *again*
>>
>> Regards,
>> Sudeep
>
> Sorry for this Sudeep and thanks for the patch.
>
No problem, in fact you reminded me to post them :)
--
Regards,
Sudeep
--
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] regulator: pwm: DT: Add ramp delay for exponential voltage transition
From: Rob Herring @ 2016-11-14 15:48 UTC (permalink / raw)
To: Laxman Dewangan
Cc: broonie, mark.rutland, linux-kernel, devicetree, Douglas Anderson,
Aleksandr Frid
In-Reply-To: <1478281075-3498-1-git-send-email-ldewangan@nvidia.com>
On Fri, Nov 04, 2016 at 11:07:54PM +0530, Laxman Dewangan wrote:
> Some PWM regulator has the exponential transition in voltage change as
> opposite to fixed slew-rate linear transition on other regulators.
> For such PWM regulators, add the property for providing the delay
> from DT node.
>
> Add DT binding details of the new property
> "pwm-regulator-voltage-ramp-time-us" added for providing voltage
> transition delay.
>
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
> CC: Douglas Anderson <dianders@chromium.org>
> CC: Aleksandr Frid <afrid@nvidia.com>
>
> ---
> This patch is continuation of discussion on patch
> regulator: pwm: Fix regulator ramp delay for continuous mode
> https://patchwork.kernel.org/patch/9216857/
> where is it discussed to have separate property for PWM which has
> exponential voltage transition.
> ---
> Documentation/devicetree/bindings/regulator/pwm-regulator.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> index 3aeba9f..a163f42 100644
> --- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
> @@ -54,6 +54,16 @@ Optional properties:
> --------------------
> - enable-gpios: GPIO to use to enable/disable the regulator
>
> +- pwm-regulator-voltage-ramp-time-us: Integer, voltage ramp time in
This is a really long name. Drop the 'pwm-regulator-' part as it is
redundant. The fact that it is PWM reg specific is captured as it is
documented that way.
Rob
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6q: replace gpio-key,wakeup with wakeup-source for Utilite Pro
From: Fabio Estevam @ 2016-11-14 15:47 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shawn Guo,
Sascha Hauer, Fabio Estevam
In-Reply-To: <1479138250-17780-3-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On Mon, Nov 14, 2016 at 1:44 PM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
From: Nicolas Ferre @ 2016-11-14 15:45 UTC (permalink / raw)
To: Sudeep Holla, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Belloni,
Jean-Christophe Plagniol-Villard
In-Reply-To: <1479138250-17780-2-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Le 14/11/2016 à 16:44, Sudeep Holla a écrit :
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> Cc: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm/boot/dts/at91sam9260ek.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Hi,
>
> Inspite of getting rid of most of the legacy property almost a year ago,
> addition of new platforms have brought this back and over time it's
> now found again in few places. Just get rid of them *again*
>
> Regards,
> Sudeep
Sorry for this Sudeep and thanks for the patch.
Best regards,
> diff --git a/arch/arm/boot/dts/at91sam9260ek.dts b/arch/arm/boot/dts/at91sam9260ek.dts
> index 2c87f58448e7..b2578feceb08 100644
> --- a/arch/arm/boot/dts/at91sam9260ek.dts
> +++ b/arch/arm/boot/dts/at91sam9260ek.dts
> @@ -174,14 +174,14 @@
> label = "Button 3";
> gpios = <&pioA 30 GPIO_ACTIVE_LOW>;
> linux,code = <0x103>;
> - gpio-key,wakeup;
> + wakeup-source;
> };
>
> btn4 {
> label = "Button 4";
> gpios = <&pioA 31 GPIO_ACTIVE_LOW>;
> linux,code = <0x104>;
> - gpio-key,wakeup;
> + wakeup-source;
> };
> };
>
> --
> 2.7.4
>
>
--
Nicolas Ferre
--
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 v7 11/14] mmc: sdhci-msm: Add HS400 platform support
From: Ulf Hansson @ 2016-11-14 15:44 UTC (permalink / raw)
To: kbuild test robot
Cc: Ritesh Harjani, kbuild-all@01.org, linux-mmc, Adrian Hunter,
Shawn Lin, Stephen Boyd, Andy Gross, devicetree@vger.kernel.org,
linux-clk, david.brown, linux-arm-msm@vger.kernel.org,
Georgi Djakov, Alex Lemberg, Mateusz Nowak, Yuliy Izrailov,
Asutosh Das, kdorfman@codeaurora.org, David Griego
In-Reply-To: <201611142112.EdLY7cAN%fengguang.wu@intel.com>
Hi,
On 14 November 2016 at 14:53, kbuild test robot <lkp@intel.com> wrote:
> Hi Venkat,
>
> [auto build test ERROR on ulf.hansson-mmc/next]
> [also build test ERROR on v4.9-rc5]
> [cannot apply to next-20161114]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
Here we go...
>
> url: https://github.com/0day-ci/linux/commits/Ritesh-Harjani/mmc-sdhci-msm-Add-clk-rates-DDR-HS400-support/20161114-142815
> base: https://git.linaro.org/people/ulf.hansson/mmc next
This above is the old tree, here's the new:
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git
Could you please update the path in the build system?
[...]
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Sudeep Holla @ 2016-11-14 15:44 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sudeep Holla, devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai,
Maxime Ripard
Though the mmc core driver will continue to support the legacy
"enable-sdio-wakeup" property to enable SDIO as the wakeup source,
"wakeup-source" is the new standard binding.
This patch replaces the legacy "enable-sdio-wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
Inspite of getting rid of most of the legacy property almost a year ago,
addition of new platforms have brought this back and over time it's
now found again in few places. Just get rid of them *again*
Regards,
Sudeep
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index ba5bca0fe997..1df47aa0a07b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -167,7 +167,7 @@
mmc-pwrseq = <&mmc3_pwrseq>;
bus-width = <4>;
non-removable;
- enable-sdio-wakeup;
+ wakeup-source;
status = "okay";
brcmf: bcrmf@1 {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
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