* Re: [PATCH 2/2] clk: hisilicon: add CRG driver for Hi3516CV300 SoC
From: Stephen Boyd @ 2016-11-14 20:03 UTC (permalink / raw)
To: Jiancheng Xue
Cc: mturquette, robh+dt, mark.rutland, linux-kernel, linux-clk,
devicetree, bin.chen, elder, hermit.wangheming, yanhaifeng,
wenpan, howell.yang
In-Reply-To: <0c3b49a4-f58c-253a-fd87-ab52b0b26010@hisilicon.com>
On 11/14, Jiancheng Xue wrote:
> Hi Stephen,
>
> On 2016/11/12 8:04, Stephen Boyd wrote:
> > On 10/29, Jiancheng Xue wrote:
> >
> > Should be a From: Pan Wen here?
> >
> >> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
> >> Generator) module generates clock and reset signals used
> >> by other module blocks on SoC.
> >>
> >> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
> >
> > And you should have signed it off? Care to resend or state that
> > this is incorrectly attributed to you instead of Pan Wen?
> >
>
> Pan Wen is the main author of this patch. I just made some small modification
> with agreement from him. Do I need to resend this patch if it's better to add my
> signed-off?
>
Sure I'll apply the resent one. But you should also make sure to
retain Pan Wen's authorship. I'll go do that when applying it.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 04/14] ARM: dts: Add xo_clock to sdhc nodes on qcom platforms
From: Stephen Boyd @ 2016-11-14 20:01 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-5-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> Add xo_clock to sdhc clock node on all qcom platforms.
>
> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
> ---
> arch/arm/boot/dts/qcom-apq8084.dtsi | 14 ++++++++------
> arch/arm/boot/dts/qcom-msm8974.dtsi | 14 ++++++++------
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 10 ++++++----
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 +++++----
> 4 files changed, 27 insertions(+), 20 deletions(-)
>
Is there an update to
Documentation/devicetree/bindings/mmc/sdhci-msm.txt as well?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 13/14] mmc: sdhci-msm: Add calibration tuning for CDCLP533 circuit
From: Stephen Boyd @ 2016-11-14 19:59 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-14-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -575,6 +729,15 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host *host,
> dev_dbg(mmc_dev(mmc), "%s: clock=%u uhs=%u ctrl_2=0x%x\n",
> mmc_hostname(host->mmc), host->clock, uhs, ctrl_2);
> sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
> +
> + spin_unlock_irq(&host->lock);
> + /* CDCLP533 HW calibration is only required for HS400 mode*/
> + if (host->clock > CORE_FREQ_100MHZ &&
> + msm_host->tuning_done && !msm_host->calibration_done &&
> + (mmc->ios.timing == MMC_TIMING_MMC_HS400))
Drop useless parenthesis.
> + if (!sdhci_msm_cdclp533_calibration(host))
> + msm_host->calibration_done = true;
> + spin_lock_irq(&host->lock);
> }
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 14/14] sdhci: sdhci-msm: update dll configuration
From: Stephen Boyd @ 2016-11-14 19:57 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav,
Krishna Konda
In-Reply-To: <1479103248-9491-15-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -903,7 +998,33 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> config |= CORE_HC_SELECT_IN_EN;
> writel_relaxed(config, host->ioaddr + CORE_VENDOR_SPEC);
> }
> + if (!msm_host->clk_rate && !msm_host->use_cdclp533) {
> + /*
> + * Poll on DLL_LOCK or DDR_DLL_LOCK bits in
> + * CORE_DLL_STATUS to be set. This should get set
> + * within 15 us at 200 MHz.
> + */
> + rc = readl_relaxed_poll_timeout(host->ioaddr +
> + CORE_DLL_STATUS,
> + dll_lock,
> + (dll_lock &
> + (CORE_DLL_LOCK |
> + CORE_DDR_DLL_LOCK)), 10,
> + 1000);
> + if (rc == -ETIMEDOUT)
> + pr_err("%s: Unable to get DLL_LOCK/DDR_DLL_LOCK, dll_status: 0x%08x\n",
> + mmc_hostname(host->mmc), dll_lock);
> + }
> } else {
> + if (!msm_host->use_cdclp533) {
> + /* set CORE_PWRSAVE_DLL bit in CORE_VENDOR_SPEC3 */
These types of comments are totally useless. The code says
exactly what is being done, and the comment is actually wrong in
this case. Please remove all these "set/clear bit X in register
Y" comments.
> + config = readl_relaxed(host->ioaddr +
> + CORE_VENDOR_SPEC3);
> + config &= ~CORE_PWRSAVE_DLL;
> + writel_relaxed(config, host->ioaddr +
> + CORE_VENDOR_SPEC3);
> + }
> +
> /* Select the default clock (free running MCLK) */
> config = readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC);
> config &= ~CORE_HC_MCLK_SEL_MASK;
> @@ -1100,6 +1221,13 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> msm_host->use_14lpp_dll_reset = true;
>
> /*
> + * SDCC 5 controller with major version 1, minor version 0x34 and later
> + * with HS 400 mode support will use CM DLL instead of CDC LP 533 DLL.
> + */
> + if ((core_major == 1) && (core_minor < 0x34))
Drop useless parenthesis please.
> + msm_host->use_cdclp533 = true;
> +
> + /*
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Maxime Ripard @ 2016-11-14 19:53 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1479138250-17780-4-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
On Mon, Nov 14, 2016 at 03:44:10PM +0000, Sudeep Holla wrote:
> 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>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Rob Herring @ 2016-11-14 19:52 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ramesh Shanmugasundaram, mark.rutland-5wv7dgnIgG8,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA, crope-X3B1VOXEql0,
chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2857106.83gIJRJqtY@avalon>
On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
> Hi Ramesh,
>
> Thank you for the patch.
>
> On Wednesday 09 Nov 2016 15:44:44 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)
>
> Shouldn't those two properties be instead queried from the tuner at runtime
> through the V4L2 subdev API ?
>
> > +- 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)
>
> This could be queried too, except that an inverter could be present on the
> board, so it has to be specified in DT. I would however try to standardize it
> the same way that hsync-active and vsync-active are standardized in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> > +- renesas,dtdl : delay between sync signal and start of reception.
>
> Are this and the next property meant to account for PCB traces delays ?
>
> > + 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)
>
> How about specifying the property in half clock cycle units, from 0 to 4 ?
>
> > +- 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";
rx, rx? That doesn't make sense. While we don't explicitly disallow
this, I'm thinking we should. I wonder if there's any case this is
valid. If not, then a dtc check for this could be added.
> > + 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";
> > + };
>
> I'm afraid this really hurts my eyes, especially using the same compatible
> string for both the channel and sub-channel nodes.
>
> We need to decide how to model the hardware in DT. Given that the two channels
> are mostly independent having separate DT nodes makes sense to me. However, as
> they share the clock and sync signals, somehow grouping them makes sense. I
> see three ways to do so, and there might be more.
>
> 1. Adding an extra DT node for the channels group, with phandles to the two
> channels. This is what you're proposing here.
>
> 2. Adding an extra DT node for the channels group, as a parent of the two
> channels.
>
> 3. Adding phandles to the channels, pointing to each other, or possibly a
> phandle from channel 0 pointing to channel 1.
>
> Neither of these options seem perfect to me. I don't like option 1 as the
> group DT node really doesn't describe a hardware block. If we want to use a DT
> node to convey group information, option 2 seems better to me. However, it
> somehow abuses the DT parent-child model that is supposed to describe
> relationships from a control bus point of view. Option 3 has the drawback of
> not scaling properly, at least with phandles in both channels pointing to the
> other one.
>
> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
> solve all those problems :-)
What's the purpose/need for grouping them?
I'm fine with Option 2, though I want to make sure it is really needed.
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 2/5] media: i2c: max2175: Add MAX2175 support
From: Rob Herring @ 2016-11-14 19:41 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: mark.rutland-5wv7dgnIgG8, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA, crope-X3B1VOXEql0,
chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478706284-59134-3-git-send-email-ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
On Wed, Nov 09, 2016 at 03:44:41PM +0000, 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-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> ---
> .../devicetree/bindings/media/i2c/max2175.txt | 61 +
It's preferred that bindings are a separate patch.
> 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
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/max2175.txt b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> new file mode 100644
> index 0000000..69f0dad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> @@ -0,0 +1,61 @@
> +Maxim Integrated MAX2175 RF to Bits tuner
> +-----------------------------------------
> +
> +The MAX2175 IC is an advanced analog/digital hybrid-radio receiver with
> +RF to Bits® front-end designed for software-defined radio solutions.
> +
> +Required properties:
> +--------------------
> +- compatible: "maxim,max2175" for MAX2175 RF-to-bits tuner.
> +- clocks: phandle to the fixed xtal clock.
> +- clock-names: name of the fixed xtal clock.
> +- port: child port node of a tuner that defines the local and remote
> + endpoints. The remote endpoint is assumed to be an SDR device
> + that is capable of receiving the digital samples from the tuner.
> +
> +Optional properties:
> +--------------------
> +- maxim,slave : empty property indicates this is a slave of
> + another master tuner. This is used to define two
> + tuners in diversity mode (1 master, 1 slave). By
> + default each tuner is an individual master.
> +- maxim,refout-load-pF: load capacitance value (in pF) on reference
Please add 'pF' to property-units.txt.
> + output drive level. The possible load values are
> + 0pF (default - refout disabled)
> + 10pF
> + 20pF
> + 30pF
> + 40pF
> + 60pF
> + 70pF
> +- maxim,am-hiz : empty property indicates AM Hi-Z filter path is
> + selected for AM antenna input. By default this
> + filter path is not used.
> +
> +Example:
> +--------
> +
> +Board specific DTS file
> +
> +/* Fixed XTAL clock node */
> +maxim_xtal: maximextal {
clock {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <36864000>;
> +};
> +
> +/* A tuner device instance under i2c bus */
> +max2175_0: tuner@60 {
> + compatible = "maxim,max2175";
> + reg = <0x60>;
> + clocks = <&maxim_xtal>;
> + clock-names = "xtal";
> + maxim,refout-load-pF = <10>;
> +
> + port {
> + max2175_0_ep: endpoint {
> + remote-endpoint = <&slave_rx_v4l2_sdr_device>;
'v4l2' is not something that should appear in a DT.
> + };
> + };
> +
> +};
--
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 08/14] mmc: sdhci-msm: Implement set_clock callback for sdhci-msm
From: Stephen Boyd @ 2016-11-14 19:37 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-9-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -577,6 +578,90 @@ static unsigned int sdhci_msm_get_min_clock(struct sdhci_host *host)
> return SDHCI_MSM_MIN_CLOCK;
> }
>
> +/**
> + * __sdhci_msm_set_clock - sdhci_msm clock control.
> + *
> + * Description:
> + * Implement MSM version of sdhci_set_clock.
> + * This is required since MSM controller does not
> + * use internal divider and instead directly control
> + * the GCC clock as per HW recommendation.
> + **/
> +void __sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + u16 clk;
> + unsigned long timeout;
> +
> + /*
> + * Keep actual_clock as zero -
> + * - since there is no divider used so no need of having actual_clock.
> + * - MSM controller uses SDCLK for data timeout calculation. If
> + * actual_clock is zero, host->clock is taken for calculation.
> + */
> + host->mmc->actual_clock = 0;
> +
> + sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> +
> + if (clock == 0)
> + return;
> +
> + /*
> + * MSM controller do not use clock divider.
> + * Thus read SDHCI_CLOCK_CONTROL and only enable
> + * clock with no divider value programmed.
> + */
> + clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> +
> + clk |= SDHCI_CLOCK_INT_EN;
> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> +
> + /* Wait max 20 ms */
> + timeout = 20;
> + while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
> + & SDHCI_CLOCK_INT_STABLE)) {
> + if (timeout == 0) {
> + pr_err("%s: Internal clock never stabilised\n",
> + mmc_hostname(host->mmc));
> + return;
> + }
> + timeout--;
> + mdelay(1);
> + }
> +
> + clk |= SDHCI_CLOCK_CARD_EN;
> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
This is almost a copy/paste of sdhci_set_clock(). Can we make
sdhci_set_clock() call a __sdhci_set_clock() function that takes
unsigned int clock, and also a flag indicating if we want to set
the internal clock divider or not? Then we can call
__sdhci_set_clock() from sdhci_set_clock() with (clock, true) as
arguments and (clock, false).
> +}
> +
> +/* sdhci_msm_set_clock - Called with (host->lock) spinlock held. */
> +static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + int rc;
> +
> + if (!clock) {
> + msm_host->clk_rate = clock;
> + goto out;
> + }
> +
> + spin_unlock_irq(&host->lock);
> + if (clock != msm_host->clk_rate) {
Why do we need to check here? Can't we call clk_set_rate()
Unconditionally?
> + rc = clk_set_rate(msm_host->clk, clock);
> + if (rc) {
> + pr_err("%s: Failed to set clock at rate %u\n",
> + mmc_hostname(host->mmc), clock);
> + spin_lock_irq(&host->lock);
> + goto out;
Or replace the above two lines with goto err;
> + }
> + msm_host->clk_rate = clock;
> + pr_debug("%s: Setting clock at rate %lu\n",
> + mmc_hostname(host->mmc), clk_get_rate(msm_host->clk));
> + }
And put an err label here.
> + spin_lock_irq(&host->lock);
> +out:
> + __sdhci_msm_set_clock(host, clock);
> +}
> +
> static const struct of_device_id sdhci_msm_dt_match[] = {
> { .compatible = "qcom,sdhci-msm-v4" },
> {},
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:36 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Lee Jones, Rob Herring, Andy Gross, devicetree, linux-kernel,
linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <20161114185621.GC27931@tuxbot>
On 14/11/16 18:56, Bjorn Andersson wrote:
> On Mon 14 Nov 09:52 PST 2016, Srinivas Kandagatla wrote:
>
>> This patch adds support to PM8821 PMIC and interrupt support.
>> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> Changes from v1:
>> - Removed unnessary locking spotted by Bjorn
>> - updated register naming to reflect PM8821
>> - lot of cleanups suggested by Bjorn
>> - rebased on top of Linus Walleij's pm8xxx namespace
>> cleanup patch.
>
> Looks good, just some minor style nits below.
Thanks, I will address all the comments in next version.
>
>>
>> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
>> drivers/mfd/qcom-pm8xxx.c | 247 ++++++++++++++++++++-
>> 2 files changed, 238 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> index 37a088f..8f1b4ec 100644
>> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
>> Definition: must be one of:
>> "qcom,pm8058"
>> "qcom,pm8921"
>> + "qcom,pm8821"
>
> 8 < 9, so move it one step up please.
sure.. makes sense.
>
>>
>> - #address-cells:
>> Usage: required
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> [..]
>> +#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
>> +#define PM8821_SSBI_REG(m, b, offset) \
>> + ((m == 0) ? \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
>> +#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
>> +#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
>> +#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
>> +#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
>
> I like how this cleaned up the rest of the implementation.
>
> [..]
>
>> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
>> + int master, int block)
>> +{
>> + int pmirq, irq, i, ret;
>> + unsigned int bits;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
>> + if (ret) {
>> + pr_err("Failed reading %d block ret=%d", block, ret);
>
> "Reading block %d failed ret=%d"
yep.
>
>> + return;
>> + }
>> + if (!bits) {
>> + pr_err("block bit set in master but no irqs: %d", block);
>
> This seems more like a debug thing, either showing missbehaving hardware
> or something odd in the driver. I think you should drop the print or
> make it pr_debug().
okay.
>
>> + return;
>> + }
>
> I would prefer that you just drop the entire if statement, it's just an
> corner case optimization with a info print.
>
i will have a closer look at this part once again.
>> +
>> + /* Convert block offset to global block number */
>> + block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
>> +
>> + /* Check IRQ bits */
>> + for (i = 0; i < 8; i++) {
>> + if (bits & BIT(i)) {
>> + pmirq = block * 8 + i;
>> + irq = irq_find_mapping(chip->irqdomain, pmirq);
>> + generic_handle_irq(irq);
>> + }
>> + }
>> +
>
> Empty line
will fix all the empty lines in next version.
>
>> +}
>> +
>> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
>> + int master, u8 master_val)
>> +{
>> + int block;
>> +
>> + for (block = 1; block < 8; block++)
>> + if (master_val & BIT(block))
>> + pm8821_irq_block_handler(chip, master, block);
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
> ^
> |
> I see you're using vim :)
>
>> + return;
>> + }
>> +
>> + /* bits 1 through 7 marks the first 7 blocks in master 0*/
>
> Indentation
>
>> + if (master & GENMASK(7, 1))
>> + pm8821_irq_master_handler(chip, 0, master);
>> +
>> + /* bit 0 marks if master 1 contains any bits */
>
> Dito
yep.
>
>> + if (!(master & BIT(0)))
>> + goto done;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
>> + if (ret) {
>> + pr_err("Failed to read master 1 ret=%d\n", ret);
>> + return;
>
> "goto done;" so that we pass chained_irq_exit()
yes,
>
>> + }
>> +
>> + pm8821_irq_master_handler(chip, 1, master);
>> +
>> +done:
>> + chained_irq_exit(irq_chip, desc);
>> +}
>> +
>
> [..]
>
>> +static void pm8821_irq_mask_ack(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + u8 block, master;
>> + int irq_bit, rc;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to mask IRQ %d rc=%d\n"
>
>> + return;
>> + }
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
>> + pmirq, rc);
>
> "Failed to clear IRQ %d rc=%d\n"
>
>> + }
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_unmask(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + int irq_bit, rc;
>> + u8 block, master;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), ~BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc)
>> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to unmask IRQ %d rc=%d\n"
will update it in next version.
>
>> +
>
> Empty line
>
>> +}
>> +
>> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
>> + enum irqchip_irq_state which,
>> + bool *state)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + int rc, pmirq = irqd_to_hwirq(d);
>> + u8 block, irq_bit, master;
>> + unsigned int bits;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
>> + if (rc) {
>> + pr_err("Failed Reading Status rc=%d\n", rc);
>
> Odd capitalization, I suggest that you match it to the other functions
> by:
>
> "Reading status of IRQ %d failed rc=%d\n"
>
Okay
>> + return rc;
>> + }
>> +
>> + *state = !!(bits & BIT(irq_bit));
>> +
>> + return rc;
>> +}
>> +
>
> [..]
>
>>
>> static int pm8xxx_probe(struct platform_device *pdev)
>> {
>> + const struct of_device_id *match;
>> + const struct pm_irq_data *data;
>> struct regmap *regmap;
>> int irq, rc;
>> unsigned int val;
>> u32 rev;
>> struct pm_irq_chip *chip;
>> - unsigned int nirqs = PM8XXX_NR_IRQS;
>> +
>> + match = of_match_node(pm8xxx_id_table, pdev->dev.of_node);
>> + if (!match) {
>> + dev_err(&pdev->dev, "No matching driver data found\n");
>> + return -EINVAL;
>> + }
>> +
>> + data = match->data;
>
> data = of_device_get_match_data(&pdev->dev); (from of_device.h)
This is good one.. I will use it in next version.
> Regards,
> Bjorn
>
^ permalink raw reply
* Re: [PATCH v5 00/23] Support qcom's HSIC USB and rewrite USB2 HS support
From: Stephen Boyd @ 2016-11-14 19:35 UTC (permalink / raw)
To: Peter Chen
Cc: Felipe Balbi, Heikki Krogerus, Arnd Bergmann, Neil Armstrong,
linux-arm-msm, linux-usb, linux-kernel, Bjorn Andersson,
devicetree, Rob Herring, Peter Chen, Greg Kroah-Hartman,
Andy Gross, Ivan T. Ivanov, Kishon Vijay Abraham I,
linux-arm-kernel
In-Reply-To: <20161111074017.GA21045@b29397-desktop>
Quoting Peter Chen (2016-11-10 23:40:17)
> On Tue, Oct 18, 2016 at 01:51:39PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-10-18 02:31:40)
> > > On Mon, Oct 17, 2016 at 06:56:13PM -0700, Stephen Boyd wrote:
> > > > I've also sent separate patches for other minor pieces to make this
> > > > all work. The full tree can be found here[2], hacks and all to get
> > > > things working. I've tested this on the db410c, apq8074 dragonboard,
> > > > and ifc6410 with configfs gadgets and otg cables.
> > > >
> > > > Patches based on v4.8-rc1
> >
> > Oops should be v4.9-rc1 here.
> >
> > > >
> > > > Changes from v4:
> > > > * Picked up Acks from Rob
> > > > * Updated HS phy init sequence DT property to restrict it to offsets
> > >
> > > I remembered that you got all my acks for chipidea patches, right? I did
> > > not check for this series.
> >
> > Sorry I've added in one more patch
> >
> > usb: chipidea: Emulate OTGSC interrupt enable path
> >
> > to fix extcon interrupt emulation even further.
> >
> > >
> > > Besides, the patch "gpu: Remove depends on RESET_CONTROLLER when not a
> > > provider" [1] still not be accepted, I need this patch to be merged
> > > first, then apply your chipidea part, otherwise, there is a building
> > > warning.
> > >
> > > [1] https://patchwork.kernel.org/patch/9322583/
> >
> > Yes, I'm going to resend that patch now. I hope that David will apply it
> > for -rc2.
>
> Stephen, just a mind. I have rebased Greg's usb-next tree (v4.9-rc3 on
> it), your GPU fix is still not there.
>
It looks like the patch is in drm-misc. I think they're going to hold
off on merging it until the next merge window though. fb80016af071 is
the commit in drm-misc tree and in linux-next. I'm not sure anything can
be done here besides a cross tree merge or ignore the warning?
^ permalink raw reply
* Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory
From: Reza Arbab @ 2016-11-14 19:34 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Paul Mackerras, Andrew Morton,
Rob Herring, Frank Rowand, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
Aneesh Kumar K.V, linux-kernel
In-Reply-To: <87bmxii85s.fsf@concordia.ellerman.id.au>
On Mon, Nov 14, 2016 at 10:59:43PM +1100, Michael Ellerman wrote:
>So I'm not opposed to this, but it is a little vague.
>
>What does the "hotpluggable" property really mean?
>
>Is it just a hint to the operating system? (which may or may not be
>Linux).
>
>Or is it a direction, "this memory must be able to be hotunplugged"?
>
>I think you're intending the former, ie. a hint, which is probably OK.
>But it needs to be documented clearly.
Yes, you've got it right. It's just a hint, not a mandate.
I'm about to send v7 which adds a description of "hotpluggable" in the
documentation. Hopefully I've explained it well enough there.
--
Reza Arbab
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH V2 1/2] pinctrl: tegra: Add DT binding for io pads control
From: Rob Herring @ 2016-11-14 19:34 UTC (permalink / raw)
To: Laxman Dewangan
Cc: linus.walleij, mark.rutland, swarren, thierry.reding, gnurou,
yamada.masahiro, jonathanh, linux-gpio, devicetree, linux-tegra,
linux-kernel
In-Reply-To: <1478696782-11657-2-git-send-email-ldewangan@nvidia.com>
On Wed, Nov 09, 2016 at 06:36:21PM +0530, Laxman Dewangan wrote:
> NVIDIA Tegra124 and later SoCs support the multi-voltage level and
> low power state of some of its IO pads. The IO pads can work in
> the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
> sources. When IO interfaces are not used then IO pads can be
> configure in low power state to reduce the power consumption from
> that IO pads.
>
> On Tegra124, the voltage level of IO power rail source is auto
> detected by hardware(SoC) and hence it is only require to configure
> in low power mode if IO pads are not used.
>
> On T210 onwards, the auto-detection of voltage level from IO power
> rail is removed from SoC and hence SW need to configure the PMC
> register explicitly to set proper voltage in IO pads based on
> IO rail power source voltage.
>
> Add DT binding document for detailing the DT properties for
> configuring IO pads voltage levels and its power state.
>
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
>
> ---
> Changes from V1:
> The DT binding document is modified to explain the regulator handle
> for different IOs and how can it be passed from the DT.
> ---
> .../bindings/pinctrl/nvidia,tegra-io-pad.txt | 126 +++++++++++++++++++++
> 1 file changed, 126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
> new file mode 100644
> index 0000000..6ca961f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
> @@ -0,0 +1,126 @@
> +NVIDIA Tegra PMC IO pad controller
> +
> +NVIDIA Tegra124 and later SoCs support the multi-voltage level and
> +low power state of some of its IO pads. When IO interface are not
> +used then IO pads can be configure in low power state to reduce
> +the power from that IO pads. The IO pads can work in the voltage
> +of the 1.8V and 3.3V of IO voltage from power rail sources.
> +
> +On Tegra124, the voltage of IO power rail source is auto detected by
> +SoC and hence it is only require to configure in low power mode if
> +IO pads are not used.
> +
> +On T210 onwards, the HW based auto-detection for IO voltage is removed
> +and hence SW need to configure the PMC register explicitly, to set proper
> +voltage in IO pads, based on IO rail power source voltage.
> +
> +The voltage configurations and low power state of IO pads should be done
> +in boot if it is not going to change other wise dynamically based on IO
> +rail voltage on that IO pads and usage of IO pads
s/other wise/otherwise/
The end of the sentence is not clear and missing a period.
> +
> +The DT property of the io pads must be under the node of pmc i.e.
> +pmc@7000e400 for Tegra124 onwards.
s/io/IO/
> +
> +Please refer to <pinctrl-bindings.txt> in this directory for details of the
> +common pinctrl bindings used by client devices, including the meaning of the
> +phrase "pin configuration node".
> +
> +Tegra's pin configuration nodes act as a container for an arbitrary number of
> +subnodes. Each of these subnodes represents some desired configuration for an
> +IO pads, or a list of IO pads. This configuration can include the voltage and
> +power enable/disable control
> +
> +The name of each subnode is not important; all subnodes should be enumerated
> +and processed purely based on their content. Each subnode only affects those
> +parameters that are explicitly listed. Unspecified is represented as an absent
> +property,
> +
> +See the TRM to determine which properties and values apply to each IO pads.
> +
> +Required subnode-properties:
> +==========================
> +- pins : An array of strings. Each string contains the name of an IO pads. Valid
> + values for these names are listed below.
> +
> +Optional subnode-properties:
> +==========================
> +Following properties are supported from generic pin configuration explained
> +in <dt-bindings/pinctrl/pinctrl-binding.txt>.
> +low-power-enable: enable low power mode.
> +low-power-disable: disable low power mode.
> +
> +Valid values for pin for T124 are:
> + audio, bb, cam, comp, csia, csib, csie, dsi, dsib, dsic, dsid, hdmi,
> + hsic, hv, lvds, mipi-bias, nand, pex-bias, pex-clk1, pex-clk2,
> + pex-ctrl, sdmmc1, sdmmc3, sdmmc4, sys-ddc, uart, usb0, usb1, usb2,
> + usb-bias
> +
> +Valid values for pin for T210 are:
> + audio, audio-hv, cam, csia, csib, csic, csid, csie, csif,
> + dbg, debug-nonao, dmic, dp, dsi, dsib, dsic, dsid, emmc, emmc2,
> + gpio, hdmi, hsic, lvds, mipi-bias, pex-bias, pex-clk1, pex-clk2,
> + pex-ctrl, sdmmc1, sdmmc3, spi, spi-hv, uart, usb-bias, usb0,
> + usb1, usb2, usb3.
> +
> +To find out the IO rail voltage for setting the voltage of IO pad by SW,
> +the regulator supply handle must provided from the DT and it is explained
> +in the regulator DT binding document
> + <devicetree/bindings/regulator/regulator.txt>.
> +For example, for GPIO rail the supply name is vddio-gpio and regulator
> +handle is supplied from DT as
> + vddio-gpio-supply = <®ulator_xyz>;
> +
> +For T210, following IO pads support the 1.8V/3.3V and the corresponding
> +io voltage pin names are as follows:
> + audio -> vddio-audio
> + audio-hv -> vddio-audio-hv
> + cam ->vddio-cam
> + dbg -> vddio-dbg
> + dmic -> vddio-dmic
> + gpio -> vddio-gpio
> + pex-ctrl -> vddio-pex-ctrl
> + sdmmc1 -> vddio-sdmmc1
> + sdmmc3 -> vddio-sdmmc3
> + spi -> vddio-spi
> + spi-hv -> vddio-spi-hv
> + uart -> vddio-uart
> +
> +Example:
> + i2c@7000d000 {
> + pmic@3c {
> + regulators {
> + vddio_sdmmc1: ldo2 {
> + /* Regulator entries for LDO2 */
> + };
> +
> + vdd_cam: ldo3 {
> + /* Regulator entries for LDO3 */
> + };
> + };
> + };
> + };
> +
> + pmc@7000e400 {
> + vddio-cam = <&vdd_cam>;
Missing -supply.
> + vddio-sdmmc1-supply = <&vddio_sdmmc1>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&tegra_io_pad_volt_default>;
> + tegra_io_pad_volt_default: common {
> + audio-hv {
> + pins = "audio-hv";
> + low-power-disable;
> + };
> +
> + gpio {
> + pins = "gpio";
> + low-power-disable;
> + };
> +
> + audio {
> + pins = "audio", "dmic", "sdmmc3";
What's the purpose of grouping these?
> + low-power-enable;
> + };
> + };
> +
> + };
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:33 UTC (permalink / raw)
To: Stephen Boyd, Lee Jones
Cc: bjorn.andersson, Rob Herring, Andy Gross, devicetree,
linux-kernel, linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <a1116e3f-32d2-aa2d-9404-1d8147bd8500@codeaurora.org>
On 14/11/16 18:40, Stephen Boyd wrote:
> On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
>> index 7f9620e..dc347d3 100644
>> --- a/drivers/mfd/qcom-pm8xxx.c
>> +++ b/drivers/mfd/qcom-pm8xxx.c
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
>
> Hm? vi?
yes.. That was good catch!! will fix it in next version...
>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2016-11-14 19:20 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Nishanth Menon, devicetree@vger.kernel.org, Santosh Shilimkar,
linux-pm@vger.kernel.org, Kevin Hilman, Sudeep Holla,
Rafael J . Wysocki, linux-kernel@vger.kernel.org, Jon Hunter,
Tero Kristo, Russell King, Keerthy,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAPDyKFofZdFfGA8gbS9FJxAX5Ub-s8yZWDcNVOgwiEBpho4oyw@mail.gmail.com>
Hi,
On 11/11/2016 06:34 AM, Ulf Hansson wrote:
> On 10 November 2016 at 20:56, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Rob, Ulf, Jon,
>>
>> On 10/27/2016 08:15 AM, Dave Gerlach wrote:
>>>
>>> +Jon
>>> On 10/26/2016 04:59 PM, Rob Herring wrote:
>>>>
>>>> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com>
>>>> wrote:
>>>>>
>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>
>>>>>> Hi,
>>>>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>>>>>>
>>>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>>>
>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>>>> control device power states.
>>>>>>>>
>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>
>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>> ---
>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54
>>>>>>>> +++++++++++++
>>>>>>>> MAINTAINERS | 2 +
>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>> ++++++++++++++++++++++
>>>>>>>> 3 files changed, 146 insertions(+)
>>>>>>>> create mode 100644
>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..32f38a349656
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> @@ -0,0 +1,54 @@
>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>> +---------------------------------------------
>>>>>>>> +
>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>> that is
>>>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>> system
>>>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>>>>> domain
>>>>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>>>>> use of
>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>> +
>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>> +
>>>>>>>> +PM Domain Node
>>>>>>>> +==============
>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>> PMMC,
>>>>>>>> +which in this case is the single implementation as documented by the
>>>>>>>> generic
>>>>>>>> +PM domain bindings in
>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the
>>>>>>>> devices.
>>>>>>>>
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +k2g_pds: k2g_pds {
>>>>>>>
>>>>>>>
>>>>>>> should use generic name like "power-contoller", e.g. k2g_pds:
>>>>>>> power-controller
>>>>>>
>>>>>>
>>>>>> Ok, that makes more sense.
>>>>>>
>>>>>>>
>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>> + ti,sci = <&pmmc>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +PM Domain Consumers
>>>>>>>> +===================
>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>> provide
>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>> device
>>>>>>>> +specific ID that identifies the device.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>> node.
>>>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI
>>>>>>>> to
>>>>>>>> + be used for device control.
>>>>>>>
>>>>>>>
>>>>>>> This ID doesn't look right.
>>>>>>>
>>>>>>> Why not use #power-domain-cells = <1> and pass the index in the DT?
>>>>>>> ...
>>>>
>>>>
>>>> Exactly. ti,sci-id is a NAK for me.
>>>
>>>
>>> I was told not to use the onecell during v1 discussion. I agree this would
>>> be
>>> ideal but I cannot due to what the bindings represent, the phandle
>>> parameter is
>>> an index into a list of genpds, whereas we need an actual ID number we can
>>> use
>>> and I do not have the ability to get that from the phandle.
>>>
>>> @Ulf/Jon, is there any hope of bringing back custom xlate functions for
>>> genpd
>>> providers? I don't have a good background on why it was even removed. I
>>> can
>>> maintain a single genpd for all devices but I need a way to parse this ID,
>>> whether it's from a separate property or a phandle. It is locked now to
>>> indexing
>>> into a list of genpds but I need additional per device information for
>>> devices
>>> bound to a genpd and I need either a custom parameter or the ability to
>>> parse
>>> the phandle myself.
>>>
>>
>> Any comments here? The meaning of the phandle onecell is fixed in the genpd
>> framework so I'm not sure how we want to move forward with this, I need to
>> pass a power domain ID to the genpd driver, and if this shouldn't be a new
>> property I'm not sure what direction we should take.
>>
>> Regards,
>> Dave
>>
>>
>>>>
>>>>>>>
>>>>>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for
>>>>>>>> k2g.
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +uart0: serial@02530c00 {
>>>>>>>> + compatible = "ns16550a";
>>>>>>>> + ...
>>>>>>>> + power-domains = <&k2g_pds>;
>>>>>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>>>>>
>>>>>>>
>>>>>>> ... like this:
>>>>>>>
>>>>>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>>>>>
>>>>>>
>>>>>> That's how I did it in version one actually. I was able to define my
>>>>>> own xlate function to parse the phandle and get that index, but Ulf
>>>>>> pointed me to this series by Jon Hunter [1] that simplified genpd
>>>>>> providers and dropped the concept of adding your own xlate. This locks
>>>>>> the onecell approach to using a fixed static array of genpds that get
>>>>>> indexed into (without passing the index to the provider, just the
>>>>>> genpd that's looked up), which doesn't fit our usecase, as we don't
>>>>>> want a 1 to 1 genpd to device mapping based on the comments provided
>>>>>> in v1. Now we just use the genpd device attach/detach hooks to parse
>>>>>> the sci-id and then use it in the genpd device start/stop hooks.
>>>>
>>>>
>>>> I have no idea what any of this means. All sounds like driver
>>>> architecture, not anything to do with bindings.
>>>
>>>
>>> This was a response to Kevin, not part of binding description.
>>>
>>>>
>>>>>
>>>>> Ah, right. I remember now. This approach allows you to use a single
>>>>> genpd as discussed earlier.
>>>>>
>>>>> Makes sense now, suggestion retracted.
>>>>
>>>>
>>>> IIRC, the bindings in Jon's case had a node for each domain and didn't
>>>> need any additional property.
>>>
>>>
>>> Yes but we only have one domain and index into it, not into a list of
>>> domains,
>
> Exactly. And this my main point as well. We are not talking about a
> domain property but a device property.
>
>>> so the additional property is solving a different problem.
>
> Yes.
>
> Perhaps you could try to elaborate about what the TI SCI ID really
> represents for the device, as to help Rob understand the bigger
> picture?
>
> To me, the TI SCI ID, is similar to a "conid" for any another "device
> resource" (like clock, pinctrl, regulator etc) which we can describe
> in DT and assign to a device node. The only difference here, is that
> we don't have common API to fetch the resource (like clk_get(),
> regulator_get()), but instead we fetches the device's resource from
> SoC specific code, via genpd's device ->attach() callback.
Thanks for the response. Yes, you've pretty much hit it on the head. It
is not an index into a list of genpds but rather identifies the device
*within* a single genpd. It is a property specific to each device that
resides in a ti-sci-genpd, not a mapping describing which genpd the
device belongs to. The generic power domain binding is concerned with
mapping the device to a specific genpd, which is does fine for us, but
we have a sub mapping for devices that exist inside a genpd which, we
must describe as well, hence the ti,sci-id.
Regards,
Dave
>
> Hope that helps.
>
> Kind regards
> Uffe
>
^ permalink raw reply
* Re: [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-14 19:17 UTC (permalink / raw)
To: Neil Armstrong, Martin Blumenstingl
Cc: carlo, linux-amlogic, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
Since the P23x and Q20x boards are identical, should we just come up
with a singel dtsi for them all? e.g move the -p23x.dtsi to -pq2xx.dtsi
or something?
I don't think it's a big deal, but it does seem like we should avoid the
copy/paste wherever possible.
Kevin
^ permalink raw reply
* Re: [PATCH v2 3/3] remoteproc: qcom: add Venus video core firmware loader driver
From: Stephen Boyd @ 2016-11-14 19:16 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Ohad Ben-Cohen, Bjorn Andersson, Andy Gross, Rob Herring,
Mark Rutland, Srinivas Kandagatla,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478539853-23218-4-git-send-email-stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 11/07, Stanimir Varbanov wrote:
> +#include <linux/module.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/qcom_scm.h>
> +#include <linux/remoteproc.h>
> +
> +#include "qcom_mdt_loader.h"
> +#include "remoteproc_internal.h"
> +
> +#define VENUS_CRASH_REASON_SMEM 425
This is unused. Is there going to be some common smem API to get
the crash reason?
> +
> +static const struct of_device_id venus_of_match[] = {
> + { .compatible = "qcom,venus-pil" },
> + { },
> +};
Add a MODULE_DEVICE_TABLE?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] Add basic support for DW CSI-2 Host IPK
From: kbuild test robot @ 2016-11-14 19:12 UTC (permalink / raw)
Cc: kbuild-all, robh+dt, mark.rutland, mchehab, devicetree,
linux-kernel, linux-media, davem, gregkh, geert+renesas, akpm,
linux, hverkuil, laurent.pinchart+renesas, arnd, sudipm.mukherjee,
tiffany.lin, minghsiu.tsai, jean-christophe.trotin,
andrew-ct.chen, simon.horman, songjun.wu, bparrot,
CARLOS.PALMINHA, Ramiro.Oliveira
In-Reply-To: <c1699c43562aaae69ab851ff3955086131119c51.1479132355.git.roliveir@synopsys.com>
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
Hi Ramiro,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.9-rc5 next-20161114]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ramiro-Oliveira/Add-support-for-the-DW-IP-Prototyping-Kits-for-MIPI-CSI-2-Host/20161115-014759
base: git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/media/platform/dwc/dw_mipi_csi.c: In function 'mipi_csi_probe':
>> drivers/media/platform/dwc/dw_mipi_csi.c:597:8: error: implicit declaration of function 'devm_request_irq' [-Werror=implicit-function-declaration]
ret = devm_request_irq(dev, mipi_csi->ctrl_irq_number,
^~~~~~~~~~~~~~~~
>> drivers/media/platform/dwc/dw_mipi_csi.c:598:29: error: 'IRQF_SHARED' undeclared (first use in this function)
dw_mipi_csi_irq1, IRQF_SHARED,
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:598:29: note: each undeclared identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +/devm_request_irq +597 drivers/media/platform/dwc/dw_mipi_csi.c
591 mipi_csi->ctrl_irq_number = platform_get_irq(pdev, 0);
592 if (mipi_csi->ctrl_irq_number <= 0) {
593 dev_err(dev, "IRQ number not set.\n");
594 return mipi_csi->ctrl_irq_number;
595 }
596
> 597 ret = devm_request_irq(dev, mipi_csi->ctrl_irq_number,
> 598 dw_mipi_csi_irq1, IRQF_SHARED,
599 dev_name(dev), mipi_csi);
600 if (ret) {
601 dev_err(dev, "IRQ failed\n");
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56871 bytes --]
^ permalink raw reply
* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-14 19:08 UTC (permalink / raw)
To: Tim Harvey, Ulf Hansson
Cc: Mark Rutland, Javier Martinez Canillas, Fabio Estevam,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAJ+vNU26tx-1bLKNpzYJ0UCeFJ-SczZOca1dYdt5mCGDxAuKTQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
So, someone merged a patch which makes mmcblk devices follow the
host controller numbering.
Now my cubox-i fails to boot correctly because the SD card in the
_only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
USDHC1 is wired to the on-microsom WiFi, and never has anything
remotely near a SD card or eMMC present. So, this change is
confusing on these platforms.
Moreover, this is _going_ to break SolidRun distros if people upgrade
their kernels.
It may be appropriate for eMMC, but it's not appropriate everywhere.
This is a user visible _regression_ in 4.9-rc. Whoever did this,
please revert whatever change caused this, and next time limit it
to only eMMC.
Thanks.
On Fri, Oct 28, 2016 at 09:45:00AM -0700, Tim Harvey wrote:
> On Fri, Oct 28, 2016 at 8:37 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
> >> Greetings,
> >>
> >> I have an IMX6 board that has the following:
> >> sdhc1: mmc0: sdio radio
> >> sdhc2: mmc1: /dev/mmcblk1: microSD connector
> >> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
> >>
> >> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
> >> registered as /dev/mmcblk1 so that permanent storage is the first
> >> mmcblk device as I think this is more intuitive however currently
> >> these get instanced in the order they appear in the imx6qdl.dtsi
> >> device-tree configuration and are not able to be mapped the way I want
> >> them in my dts file.
> >>
> >> Is there a way, or if not is there a desire for a way, to specify the
> >> order of /dev/mmcblk devices via device-tree?
> >
> > As with many other devices, there is no standard way of controlling the
> > Linux enumeration (and given the ID space is shared with other dynamic
> > devices it's not something that could generally work).
> >
> > These should be refererd to by UUID if possible.
> >
> > If not, we could cosider adding a by-dt-path or something like that.
> >
> > Thanks,
> > Mark.
>
> Mark / Javier/ Fabio,
>
> Thanks - this is very useful.
>
> Yes, I agree that using UUID's is the way to go and now I see how that
> can be easily accessed via uboot 'part' command.
>
> Regards,
>
> Tim
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Bjorn Andersson @ 2016-11-14 18:56 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Lee Jones, Rob Herring, Andy Gross, devicetree, linux-kernel,
linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla@linaro.org>
On Mon 14 Nov 09:52 PST 2016, Srinivas Kandagatla wrote:
> This patch adds support to PM8821 PMIC and interrupt support.
> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes from v1:
> - Removed unnessary locking spotted by Bjorn
> - updated register naming to reflect PM8821
> - lot of cleanups suggested by Bjorn
> - rebased on top of Linus Walleij's pm8xxx namespace
> cleanup patch.
Looks good, just some minor style nits below.
>
> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
> drivers/mfd/qcom-pm8xxx.c | 247 ++++++++++++++++++++-
> 2 files changed, 238 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> index 37a088f..8f1b4ec 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
> Definition: must be one of:
> "qcom,pm8058"
> "qcom,pm8921"
> + "qcom,pm8821"
8 < 9, so move it one step up please.
>
> - #address-cells:
> Usage: required
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
[..]
> +#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
> +#define PM8821_SSBI_REG(m, b, offset) \
> + ((m == 0) ? \
> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
> +#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
> +#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
> +#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
> +#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
I like how this cleaned up the rest of the implementation.
[..]
> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
> + int master, int block)
> +{
> + int pmirq, irq, i, ret;
> + unsigned int bits;
> +
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
> + if (ret) {
> + pr_err("Failed reading %d block ret=%d", block, ret);
"Reading block %d failed ret=%d"
> + return;
> + }
> + if (!bits) {
> + pr_err("block bit set in master but no irqs: %d", block);
This seems more like a debug thing, either showing missbehaving hardware
or something odd in the driver. I think you should drop the print or
make it pr_debug().
> + return;
> + }
I would prefer that you just drop the entire if statement, it's just an
corner case optimization with a info print.
> +
> + /* Convert block offset to global block number */
> + block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
> +
> + /* Check IRQ bits */
> + for (i = 0; i < 8; i++) {
> + if (bits & BIT(i)) {
> + pmirq = block * 8 + i;
> + irq = irq_find_mapping(chip->irqdomain, pmirq);
> + generic_handle_irq(irq);
> + }
> + }
> +
Empty line
> +}
> +
> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
> + int master, u8 master_val)
> +{
> + int block;
> +
> + for (block = 1; block < 8; block++)
> + if (master_val & BIT(block))
> + pm8821_irq_block_handler(chip, master, block);
> +
Empty line
> +}
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
^
|
I see you're using vim :)
> + return;
> + }
> +
> + /* bits 1 through 7 marks the first 7 blocks in master 0*/
Indentation
> + if (master & GENMASK(7, 1))
> + pm8821_irq_master_handler(chip, 0, master);
> +
> + /* bit 0 marks if master 1 contains any bits */
Dito
> + if (!(master & BIT(0)))
> + goto done;
> +
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
> + if (ret) {
> + pr_err("Failed to read master 1 ret=%d\n", ret);
> + return;
"goto done;" so that we pass chained_irq_exit()
> + }
> +
> + pm8821_irq_master_handler(chip, 1, master);
> +
> +done:
> + chained_irq_exit(irq_chip, desc);
> +}
> +
[..]
> +static void pm8821_irq_mask_ack(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int pmirq = irqd_to_hwirq(d);
> + u8 block, master;
> + int irq_bit, rc;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> + BIT(irq_bit), BIT(irq_bit));
> +
Empty line
> + if (rc) {
> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
"Failed to mask IRQ %d rc=%d\n"
> + return;
> + }
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
> + BIT(irq_bit), BIT(irq_bit));
> +
Empty line
> + if (rc) {
> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
> + pmirq, rc);
"Failed to clear IRQ %d rc=%d\n"
> + }
> +
Empty line
> +}
> +
> +static void pm8821_irq_unmask(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int pmirq = irqd_to_hwirq(d);
> + int irq_bit, rc;
> + u8 block, master;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> + BIT(irq_bit), ~BIT(irq_bit));
> +
Empty line
> + if (rc)
> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
"Failed to unmask IRQ %d rc=%d\n"
> +
Empty line
> +}
> +
> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
> + enum irqchip_irq_state which,
> + bool *state)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + int rc, pmirq = irqd_to_hwirq(d);
> + u8 block, irq_bit, master;
> + unsigned int bits;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_read(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
> + if (rc) {
> + pr_err("Failed Reading Status rc=%d\n", rc);
Odd capitalization, I suggest that you match it to the other functions
by:
"Reading status of IRQ %d failed rc=%d\n"
> + return rc;
> + }
> +
> + *state = !!(bits & BIT(irq_bit));
> +
> + return rc;
> +}
> +
[..]
>
> static int pm8xxx_probe(struct platform_device *pdev)
> {
> + const struct of_device_id *match;
> + const struct pm_irq_data *data;
> struct regmap *regmap;
> int irq, rc;
> unsigned int val;
> u32 rev;
> struct pm_irq_chip *chip;
> - unsigned int nirqs = PM8XXX_NR_IRQS;
> +
> + match = of_match_node(pm8xxx_id_table, pdev->dev.of_node);
> + if (!match) {
> + dev_err(&pdev->dev, "No matching driver data found\n");
> + return -EINVAL;
> + }
> +
> + data = match->data;
data = of_device_get_match_data(&pdev->dev); (from of_device.h)
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH resend] input: touchscreen: silead: Add regulator support
From: Dmitry Torokhov @ 2016-11-14 18:50 UTC (permalink / raw)
To: Hans de Goede
Cc: Rob Herring, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
In-Reply-To: <20161114144502.10595-2-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi Hans,
On Mon, Nov 14, 2016 at 03:45:02PM +0100, Hans de Goede wrote:
> On some tablets the touchscreen controller is powered by seperate
> regulators, add support for this.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> .../bindings/input/touchscreen/silead_gsl1680.txt | 2 +
> drivers/input/touchscreen/silead.c | 51 ++++++++++++++++++++--
> 2 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> index e844c3f..b726823 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> @@ -22,6 +22,8 @@ Optional properties:
> - touchscreen-inverted-y : See touchscreen.txt
> - touchscreen-swapped-x-y : See touchscreen.txt
> - silead,max-fingers : maximum number of fingers the touchscreen can detect
> +- vddio-supply : regulator phandle for controller VDDIO
> +- avdd-supply : regulator phandle for controller AVDD
>
> Example:
>
> diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
> index f502c84..c6a1ae9 100644
> --- a/drivers/input/touchscreen/silead.c
> +++ b/drivers/input/touchscreen/silead.c
> @@ -29,6 +29,7 @@
> #include <linux/input/touchscreen.h>
> #include <linux/pm.h>
> #include <linux/irq.h>
> +#include <linux/regulator/consumer.h>
>
> #include <asm/unaligned.h>
>
> @@ -72,6 +73,8 @@ enum silead_ts_power {
> struct silead_ts_data {
> struct i2c_client *client;
> struct gpio_desc *gpio_power;
> + struct regulator *vddio;
> + struct regulator *avdd;
> struct input_dev *input;
> char fw_name[64];
> struct touchscreen_properties prop;
> @@ -465,21 +468,52 @@ static int silead_ts_probe(struct i2c_client *client,
> if (client->irq <= 0)
> return -ENODEV;
>
> + data->vddio = devm_regulator_get_optional(dev, "vddio");
> + if (IS_ERR(data->vddio)) {
> + if (PTR_ERR(data->vddio) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + data->vddio = NULL;
Why do we ignore other errors? If there is an issue reported by
regulator framework we should net be ignoring it.
Unless regulator is truly optional (i.e. chip can work with some
functionality powered off) and not simply hidden (firmware takes care of
powering up system), we should not be using regulator_get_optional():
if regulator is absent from ACPI/DT/etc, regulator framework will supply
dummy regulator that you can enable/disable and not bothering checking
whether it is NULL or not.
Also, please consider using devm_regulator_bulk_get().
> + }
> +
> + data->avdd = devm_regulator_get_optional(dev, "avdd");
> + if (IS_ERR(data->avdd)) {
> + if (PTR_ERR(data->avdd) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + data->avdd = NULL;
> + }
> +
> + /*
> + * Enable regulators at probe and disable them at remove, we need
> + * to keep the chip powered otherwise it forgets its firmware.
> + */
> + if (data->vddio) {
> + error = regulator_enable(data->vddio);
> + if (error)
> + return error;
> + }
> +
> + if (data->avdd) {
> + error = regulator_enable(data->avdd);
> + if (error)
> + goto disable_vddio;
> + }
Use devm_add_action_or_reset() to work regulator_bulk_disable call into
devm stream. As it is you are leaving regulators on on unbind/remove.
> +
> /* Power GPIO pin */
> data->gpio_power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
> if (IS_ERR(data->gpio_power)) {
> if (PTR_ERR(data->gpio_power) != -EPROBE_DEFER)
> dev_err(dev, "Shutdown GPIO request failed\n");
> - return PTR_ERR(data->gpio_power);
> + error = PTR_ERR(data->gpio_power);
> + goto disable_avdd;
> }
>
> error = silead_ts_setup(client);
> if (error)
> - return error;
> + goto disable_avdd;
>
> error = silead_ts_request_input_dev(data);
> if (error)
> - return error;
> + goto disable_avdd;
>
> error = devm_request_threaded_irq(dev, client->irq,
> NULL, silead_ts_threaded_irq_handler,
> @@ -487,10 +521,19 @@ static int silead_ts_probe(struct i2c_client *client,
> if (error) {
> if (error != -EPROBE_DEFER)
> dev_err(dev, "IRQ request failed %d\n", error);
> - return error;
> + goto disable_avdd;
> }
>
> return 0;
> +
> +disable_avdd:
> + if (data->avdd)
> + regulator_disable(data->avdd);
> +disable_vddio:
> + if (data->vddio)
> + regulator_disable(data->vddio);
> +
> + return error;
> }
>
> static int __maybe_unused silead_ts_suspend(struct device *dev)
> --
> 2.9.3
>
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] Add basic support for DW CSI-2 Host IPK
From: kbuild test robot @ 2016-11-14 18:44 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw, arnd-r2nGTMty4D4,
sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
simon.horman-wFxRvT7yatFl57MIdRCFDg,
songjun.wu-UWL1GkI3JZL3oGB3hsPCZA, bparrot-l0cyMroinI0,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w,
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <c1699c43562aaae69ab851ff3955086131119c51.1479132355.git.roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5550 bytes --]
Hi Ramiro,
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.9-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ramiro-Oliveira/Add-support-for-the-DW-IP-Prototyping-Kits-for-MIPI-CSI-2-Host/20161115-014759
base: git://linuxtv.org/media_tree.git master
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/media/platform/dwc/dw_mipi_csi.h:12,
from drivers/media/platform/dwc/dw_mipi_csi.c:14:
drivers/media/platform/dwc/dw_mipi_csi.c: In function 'dw_mipi_csi_irq1':
>> drivers/media/platform/dwc/dw_mipi_csi.c:437:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
>> drivers/media/platform/dwc/dw_mipi_csi.c:436:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT PHY FATAL: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:443:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:442:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT PKT FATAL: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:449:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:448:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT FRAME FATAL: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:455:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:454:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT PHY: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:461:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:460:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT PKT: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:467:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:466:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT LINE: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:473:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:472:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT IPI: %08X\n",
^~~~~~~~~~~~~~~~~~~
vim +437 drivers/media/platform/dwc/dw_mipi_csi.c
430
431 int_status = dw_mipi_csi_read(dev, R_CSI2_INTERRUPT);
432 spin_lock_irqsave(&dev->slock, flags);
433
434 if (int_status & CSI2_INT_PHY_FATAL) {
435 ind_status = dw_mipi_csi_read(dev, R_CSI2_INT_PHY_FATAL);
> 436 pr_info_ratelimited("%08X CSI INT PHY FATAL: %08X\n",
> 437 (uint32_t) dev->base_address, ind_status);
438 }
439
440 if (int_status & CSI2_INT_PKT_FATAL) {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 45123 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods
From: Frank Rowand @ 2016-11-14 18:44 UTC (permalink / raw)
To: Hans de Goede, Rob Herring, Pantelis Antoniou
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b2cef3fb-cbb4-f34b-cb9a-84578bb67751-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 11/14/16 03:04, Hans de Goede wrote:
> Hi,
>
> On 14-11-16 08:34, Frank Rowand wrote:
>> Hi Hans, Pantelis,
>>
>> On 11/12/16 18:15, Frank Rowand wrote:
>>> On 11/04/16 07:42, Hans de Goede wrote:
>>>> From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>>
>>>> Changesets are very powerful, but the lack of a helper API
>>>> makes using them cumbersome. Introduce a simple copy based
>>>> API that makes things considerably easier.
>>>>
>>>> To wit, adding a property using the raw API.
>>>>
>>>> struct property *prop;
>>>> prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
>>>> prop->name = kstrdup("compatible");
>>>> prop->value = kstrdup("foo,bar");
>>>> prop->length = strlen(prop->value) + 1;
>>>> of_changeset_add_property(ocs, np, prop);
>>>>
>>>> while using the helper API
>>>>
>>>> of_changeset_add_property_string(ocs, np, "compatible",
>>>> "foo,bar");
>>>>
>>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>> Changes in v2 (hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>>>> -Address review comments from:
>>>> https://www.spinics.net/lists/kernel/msg2252845.html
>>>
>>> That points to the May 9 version 1 patches from Pantelis (as expected),
>>> but containing 4, not 2, patches. Patch 1/4 was applied. Patch 4/4
>>> seems to have disappeared?
>>>
>>> Pantelis then sent a version 2 set of the patches on May 16.
>>>
>>> Your version is a modification of the May 9 patches (as would be expected
>>> of a version 2). It is confusing to have two different version 2 patch
>>> sets. I don't have any brilliant ideas on how this patch set could have
>>> been named differently to avoid that confusion.
>>>
>>> The point of this little side-track is simply to note the existence of two
>>> different version 2 series so I won't be confused when I revisit this
>>> thread in the future.
>>>
>>>> -Simplify (and fix) __of_changeset_add_update_property_copy OOM handling
>>>> -Remove (by manual inlining) these 2 static helpers:
>>>> __of_changeset_add_update_property_u32
>>>> __of_changeset_add_update_property_bool
>>>> -Remove the following exported helper method:
>>>> of_changeset_node_move_to
>>>
>>> Not all comments were addressed.
>>>
>>> There are some other changes made that are not noted in the changelog.
>>>
>>> I am still reading through the patches. I will reply again either with
>>> a reviewed-by or specific comments when I finish.
>>
>> Replying here for the entire patchset (there was no patch 0 to reply to).
>>
>> After reading through the patches, my reply is meta instead of specific
>> comments about the code.
>>
>> There are very few users of change sets in tree. I do not see the need to
>> add these helpers until such users are likely to appear.
>>
>> I would expect change sets to be _mostly_ used internally by the device tree
>> overlay framework, not directly by drivers. If change sets are an attractive
>> technology for drivers, I want to approach that usage very carefully to avoid
>> inappropriate use, which could be very difficult to reign in after the fact.
>>
>> Even if helpers should be added, this seems to be an overly complex approach.
>> If the need for these helpers becomes apparent I can provide review comments
>> with the specifics about how it appears to be overly complex.
>>
>> Can you please provide some more insights into the needs driving the desire
>> to have change set helpers and the expected use cases of them? Please put
>> your architect's hat on when replying to this question.
>
> My use case for this is discussed in this thread:
> https://www.spinics.net/lists/arm-kernel/msg536111.html
>
> With the dt-bindings for the hardware-manager I want to add here:
> https://www.spinics.net/lists/arm-kernel/msg536109.html
>
> Note that there is a lot of discussion in this thread whether or
> not this belongs in the kernel. I strongly believe though that
> some functionality like this will be needed in the kernel for
> ARM+dt devices going forward, just like there is plenty of x86
> code which adjusts itself to specific hardware, because whether
> we like it or not hardware (revisions) will always have quirks.
Thanks! That context should have been provided with the patches.
The use case discussion is important and I am paying a lot of
attention to that discussion and many other discussions about
dynamic device trees. I don't think it makes sense to apply the
change set helper patches yet, given the unsettled state of the
various dynamic device tree discussions.
-Frank
--
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] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Marek Vasut @ 2016-11-14 18:42 UTC (permalink / raw)
To: Joel Stanley, Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <CACPK8Xc=AcA=d+O++W07ki+KkCxA86EnXj7dqTRobTpb9WQbUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/11/2016 05:42 AM, Joel Stanley wrote:
> On Wed, Nov 9, 2016 at 9:12 PM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
>> This driver adds mtd support for spi-nor attached to either or both of
>> the Firmware Memory Controller or the SPI Flash Controller (AST2400
>> only).
>>
>> The SMC controllers on the Aspeed AST2500 SoC are very similar to the
>> ones found on the AST2400. The differences are on the number of
>> supported flash modules and their default mappings in the SoC address
>> space.
>>
>> The Aspeed AST2500 has one SPI controller for the BMC firmware and two
>> for the host firmware. All controllers have now the same set of
>> registers compatible with the AST2400 FMC controller and the legacy
>> 'SMC' controller is fully gone.
>>
>> Each controller has a memory range on which it maps its flash module
>> slaves. Each slave is assigned a memory window for its mapping that
>> can be changed at bootime with the Segment Address Register.
>>
>> Each SPI flash slave can then be accessed in two modes: Command and
>> User. When in User mode, accesses to the memory segment of the slaves
>> are translated in SPI transfers. When in Command mode, the HW
>> generates the SPI commands automatically and the memory segment is
>> accessed as if doing a MMIO.
>>
>> Currently, only the User mode is supported. Command mode needs a
>> little more work to check that the memory window on the AHB bus fits
>> the module size.
>>
>> Based on previous work from Milton D. Miller II <miltonm-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>>
>> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
>> ---
>> Tested on:
>>
>> * OpenPOWER Palmetto (AST2400) with
>> FMC controller : n25q256a
>> SPI controller : mx25l25635e and n25q512ax3
>>
>> * Evaluation board (AST2500) with
>> FMC controller : w25q256
>> SPI controller : w25q256
>>
>> * OpenPOWER Witherspoon (AST2500) with
>> FMC controller : mx25l25635e * 2
>> SPI controller : mx66l1g45g
>
> It's also in use on the Zaius and Barreleye OpenBMC systems.
>
> In that respect, I would like to see this merged once it's deemed
> ready by the mtd maintainers. We can follow up with the extra features
> in future patches.
>
> I've reviewed and tested this as Cedric and Milton have developed it,
> so please add:
>
> Reviewed-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
>
Thanks! I'll review the patch ASAP (this week).
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Stephen Boyd @ 2016-11-14 18:40 UTC (permalink / raw)
To: Srinivas Kandagatla, Lee Jones
Cc: bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, Rob Herring, Andy Gross,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 7f9620e..dc347d3 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
Hm? vi?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v6] media: et8ek8: add device tree binding documentation
From: Rob Herring @ 2016-11-14 18:39 UTC (permalink / raw)
To: Pavel Machek
Cc: Ivaylo Dimitrov, Sakari Ailus, Sebastian Reichel, Pali Rohár,
linux-media@vger.kernel.org, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Mauro Carvalho Chehab,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161114183040.GB28778@amd>
On Mon, Nov 14, 2016 at 12:30 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Add device tree binding documentation for toshiba et8ek8 sensor.
>
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox