* Re: [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files
From: Joao Pinto @ 2017-01-13 16:49 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Bjorn Helgaas, Jingoo Han, Joao Pinto,
Arnd Bergmann
Cc: devicetree, linux-samsung-soc, linux-doc, linux-pci, nsekhar,
linux-kernel, linux-arm-kernel, linux-arm-msm, linux-omap,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1484216786-17292-12-git-send-email-kishon@ti.com>
Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Split pcie-designware.c into pcie-designware-host.c that contains
> the host specific parts of the driver and pcie-designware.c that
> contains the parts used by both host driver and endpoint driver.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/Makefile | 2 +-
> drivers/pci/dwc/pcie-designware-host.c | 619 ++++++++++++++++++++++++++++++++
> drivers/pci/dwc/pcie-designware.c | 613 +------------------------------
> drivers/pci/dwc/pcie-designware.h | 8 +
> 4 files changed, 634 insertions(+), 608 deletions(-)
> create mode 100644 drivers/pci/dwc/pcie-designware-host.c
>
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 7d27c14..3b57e55 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,4 @@
(snip...)
> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> - int type, u64 cpu_addr, u64 pci_addr,
> - u32 size)
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> + u64 cpu_addr, u64 pci_addr, u32 size)
> {
> u32 retries, val;
>
> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> dev_err(pci->dev, "iATU is not being enabled\n");
> }
Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host.
>
> -static struct irq_chip dw_msi_irq_chip = {
> - .name = "PCI-MSI",
> - .irq_enable = pci_msi_unmask_irq,
> - .irq_disable = pci_msi_mask_irq,
> - .irq_mask = pci_msi_mask_irq,
> - .irq_unmask = pci_msi_unmask_irq,
> -};
> -
(snip...)
> -
> -static const struct irq_domain_ops msi_domain_ops = {
> - .map = dw_pcie_msi_map,
> -};
> -
> static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
> {
> u32 val;
> @@ -454,303 +192,11 @@ static u8 dw_pcie_iatu_unroll_enabled(struct dw_pcie *pci)
> return 0;
> }
Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host.
(snip...)
> diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-designware.h
> index 491fbe3..808d17b 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -14,6 +14,10 @@
> #ifndef _PCIE_DESIGNWARE_H
> #define _PCIE_DESIGNWARE_H
>
> +#include <linux/irq.h>
> +#include <linux/msi.h>
> +#include <linux/pci.h>
> +
> /* Parameters for the waiting for link up routine */
> #define LINK_WAIT_MAX_RETRIES 10
> #define LINK_WAIT_USLEEP_MIN 90000
> @@ -167,4 +171,8 @@ struct dw_pcie {
> void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val);
> int dw_pcie_link_up(struct dw_pcie *pci);
> int dw_pcie_wait_for_link(struct dw_pcie *pci);
> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> + int type, u64 cpu_addr, u64 pci_addr,
> + u32 size);
> +void dw_pcie_setup(struct dw_pcie *pci);
Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
the pcie-designware-host as static.
> #endif /* _PCIE_DESIGNWARE_H */
>
Thanks,
Joao
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-13 16:56 UTC (permalink / raw)
To: Marek Vasut
Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <86c997be-f500-eaa1-3ba5-d21cff6223b7-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 13 Jan 2017 17:44:12 +0100
Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 17:13:55 +0100
> > Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
> >>>
> >>>
> >>> On 13/01/17 15:17, Boris Brezillon wrote:
> >>>> On Fri, 13 Jan 2017 15:13:29 +0800
> >>>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> >>>>
> >>>>> Add Mediatek nor flash node.
> >>>>>
> >>>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >>>>> ---
> >>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
> >>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
> >>>>> 2 files changed, 37 insertions(+)
> >>>>>
> >>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> index 082ca88..85e5ae8 100644
> >>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> >>>>> @@ -24,6 +24,31 @@
> >>>>> };
> >>>>> };
> >>>>>
> >>>>> +&nor_flash {
> >>>>> + pinctrl-names = "default";
> >>>>> + pinctrl-0 = <&nor_pins_default>;
> >>>>> + status = "okay";
> >>>>> + flash@0 {
> >>>>> + compatible = "jedec,spi-nor";
> >>>>> + reg = <0>;
> >>>>> + };
> >>>>> +};
> >>>>> +
> >>>>> +&pio {
> >>>>> + nor_pins_default: nor {
> >>>>> + pins1 {
> >>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> >>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> >>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> >>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> >>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> >>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> >>>>> + drive-strength = <MTK_DRIVE_4mA>;
> >>>>> + bias-pull-up;
> >>>>> + };
> >>>>> + };
> >>>>> +};
> >>>>> +
> >>>>> &uart0 {
> >>>>> status = "okay";
> >>>>> };
> >>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
> >>>>> b/arch/arm/boot/dts/mt2701.dtsi
> >>>>> index bdf8954..1eefce4 100644
> >>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
> >>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
> >>>>> @@ -227,6 +227,18 @@
> >>>>> status = "disabled";
> >>>>> };
> >>>>>
> >>>>> + nor_flash: spi@11014000 {
> >>>>> + compatible = "mediatek,mt2701-nor",
> >>>>> + "mediatek,mt8173-nor";
> >>>>
> >>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
> >>>> subset of the features supported by "mediatek,mt2701-nor"?
> >>>>
> >>>
> >>> I think even if the ip block is the same, we should provide both
> >>> bindings, just in case in the future we find out that mt2701 has some
> >>> hidden bug, feature or bug-feature. This way even if we update the
> >>> driver, we stay compatible with older device tree blobs in the wild.
> >>>
> >>> We can drop the mt2701-nor in the bindings definition if you want.
> >
> > Oh, sorry, I misunderstood. What I meant is that if you want to
> > list/support all possible compatibles, maybe you should just put one
> > compatible in your DT and patch your driver (+ binding doc) to define
> > all of them.
>
> Uh, what ? I lost you here :-)
>
> >> This exactly. We should have a DT compat in the form:
> >> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
> >> Then if we find a problem in the future, we can match on the
> >> "vendor,<soc>-block" and still support the old DTs.
> >
> > Not sure it's only in term of whose IP appeared first. My understanding
> > is that it's a way to provide inheritance. For example:
> >
> > "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
> >
> > or
> >
> > "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
> >
> > BTW, which one is the oldest between mt8173 and mt2701? :-)
>
> And that's another thing and I agree with you, but I don't think that's
> what we're discussing in this thread. But (!), OT, I think we should
> codify the rules in Documentation/ . This discussion came up multiple
> times recently.
>
> And my question still stands, what do we put into the DT here, IMO
> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
I'd say
compatible = "mediatek,mt8173-nor";
because both compatible are referring to very specific IP version. It's
not the same as
compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";
where you clearly have a generic compatible which is overloaded by a
specific one.
But anyway, I'm not the one taking the decision here, let's wait for DT
maintainers reviews.
> and what goes into the binding document ? I guess both too ?
If both exist, they should be both documented.
--
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 v5 5/5] Documentation:powerpc: Add device-tree bindings for power-mgt
From: Rob Herring @ 2017-01-13 16:57 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Stewart Smith, devicetree, Michael Neuling, linux-pm,
Shreyas B. Prabhu, Daniel Lezcano, Rafael J. Wysocki,
linux-kernel, Paul Mackerras, Shilpasri G Bhat,
Oliver O'Halloran, mark.rutland, linuxppc-dev
In-Reply-To: <1484039224-5630-6-git-send-email-ego@linux.vnet.ibm.com>
On Tue, Jan 10, 2017 at 02:37:04PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> Document the device-tree bindings defining the the properties under
> the @power-mgt node in the device tree that describe the idle states
> for Linux running on baremetal POWER servers.
>
We have "common" idle state bindings. Perhaps some explanation why those
can't be used.
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
> [v4]-> [v5]: Fixed a couple of typos.
>
> .../devicetree/bindings/powerpc/opal/power-mgt.txt | 125 +++++++++++++++++++++
> 1 file changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
> new file mode 100644
> index 0000000..4967831
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
> @@ -0,0 +1,125 @@
> +IBM Power-Management Bindings
> +=============================
> +
> +Linux running on baremetal POWER machines has access to the processor
> +idle states. The description of these idle states is exposed via the
> +node @power-mgt in the device-tree by the firmware.
> +
> +Definitions:
> +----------------
> +Typically each idle state has the following associated properties:
> +
> +- name: The name of the idle state as defined by the firmware.
> +
> +- flags: indicating some aspects of this idle states such as the
> + extent of state-loss, whether timebase is stopped on this
> + idle states and so on. The flag bits are as follows:
> +
> +- exit-latency: The latency involved in transitioning the state of the
> + CPU from idle to running.
> +
> +- target-residency: The minimum time that the CPU needs to reside in
> + this idle state in order to accrue power-savings
> + benefit.
> +
> +Properties
> +----------------
> +The following properties provide details about the idle states. These
> +properties are optional unless mentioned otherwise below.
-names is optional but everything else seems to require it. It is not
clear what the binding looks like if -names is not present.
> +
> +- ibm,cpu-idle-state-names:
> + Array of strings containing the names of the idle states.
> +
> +- ibm,cpu-idle-state-flags:
> + Array of unsigned 32-bit values containing the values of the
> + flags associated with the the aforementioned idle-states. This
> + property is required on POWER9 whenever
> + ibm,cpu-idle-state-names is defined and the length of this
> + property array should be the same as
> + ibm,-cpu-idle-state-names.The flag bits are as follows:
s/ibm,-cpu/ibm,cpu/
Needs a space after the period.
> + 0x00000001 /* Decrementer would stop */
> + 0x00000002 /* Needs timebase restore */
> + 0x00001000 /* Restore GPRs like nap */
> + 0x00002000 /* Restore hypervisor resource from PACA pointer */
> + 0x00004000 /* Program PORE to restore PACA pointer */
> + 0x00010000 /* This is a nap state */
> + 0x00020000 /* This is a fast-sleep state */
> + 0x00040000 /* This is a winkle state */
> + 0x00080000 /* This is a fast-sleep state which requires a */
> + /* software workaround for restoring the timebase*/
> + 0x00800000 /* This state uses SPR PMICR instruction */
> + 0x00100000 /* This is a fast stop state */
> + 0x00200000 /* This is a deep-stop state */
> +
> +- ibm,cpu-idle-state-latencies-ns:
> + Array of unsigned 32-bit values containing the values of the
> + exit-latencies (in ns) for the idle states in
> + ibm,cpu-idle-state-names. This property is required whenever
> + ibm,cpu-idle-state-names is defined and the length of this
> + property array should be the same as
> + ibm,-cpu-idle-state-names.
Same typo.
> +
> +- ibm,cpu-idle-state-residency-ns:
> + Array of unsigned 32-bit values containing the values of the
> + target-residency (in ns) for the idle states in
> + ibm,cpu-idle-state-names. On POWER8 this is an optional
> + property. If the property is absent, the target residency for
> + the "Nap", "FastSleep" are defined to 10000 and 300000000
> + respectively. On POWER9 this property must be defined if
> + ibm,cpu-idle-state-names is defined and the length should be
> + same as that of ibm,cpu-idle-state-names.
> +
> +- ibm,cpu-idle-state-psscr:
> + Array of unsigned 64-bit values containing the values for the
> + PSSCR for each of the idle states in ibm,cpu-idle-state-names.
> + This property is required on POWER9 whenever
> + ibm,cpu-idle-state-names is defined and the length of this
> + property array should be the same as
> + ibm,cpu-idle-state-names.
> +
> +- ibm,cpu-idle-state-psscr-mask:
> + Array of unsigned 64-bit values containing the masks
> + indicating which psscr fields are set in the corresponding
> + entries of ibm,cpu-idle-state-psscr. This property is
> + required on POWER9 whenever ibm,cpu-idle-state-names is
> + defined and the length of this property array should be the
> + same as ibm,cpu-idle-state-names.
> +
> + Whenever the firmware sets an entry in
> + ibm,cpu-idle-state-psscr-mask value to 0xf, it implies that
> + only the Requested Level (RL) field of the corresponding entry
> + in ibm,cpu-idle-state-psscr should be considered by the
> + kernel. For such idle states, the kernel would set the
> + remaining fields of the psscr to the following sane-default
> + values.
> +
> + - ESL and EC bits are to 1. So wakeup from any stop
> + state will be at vector 0x100.
> +
> + - MTL and PSLL are set to the maximum allowed value as
> + per the ISA, i.e. 15.
> +
> + - The Transition Rate, TR is set to the Maximum value
> + 3.
> +
> + For all the other values of the entry in
> + ibm,cpu-idle-state-psscr-mask, the Kernel expects all the
> + psscr fields of the corresponding entry in
> + ibm,cpu-idle-state-psscr to be correctly set by the firmware.
> +
> +- ibm,cpu-idle-state-pmicr:
> + Array of unsigned 64-bit values containing the pmicr values
> + for the idle states in ibm,cpu-idle-state-names. This 64-bit
> + register value is to be set in pmicr for the corresponding
> + state if the flag indicates that pmicr SPR should be set. This
> + is an optional property on POWER8 and is absent on
> + POWER9. When present on POWER8, the length of this property
> + array should be the same as ibm,cpu-idle-state-names.
> +
> +- ibm,cpu-idle-state-pmicr:-mask
> + Array of unsigned 64-bit values containing the mask indicating
> + which of the fields of the PMICR are set in the corresponding
> + entries in ibm,cpu-idle-state-pmicr. This is an optional
> + property on POWER8 and is absent on POWER9. When present on
> + POWER8, the length of this property array should be the same
> + as ibm,cpu-idle-state-names.
> --
> 1.9.4
>
^ permalink raw reply
* Re: [PATCH] regulator: anatop: Add support for "anatop-enable-bit"
From: Rob Herring @ 2017-01-13 17:07 UTC (permalink / raw)
To: Andrey Smirnov
Cc: linux-kernel, yurovsky, Liam Girdwood, Mark Brown, Mark Rutland,
Shawn Guo, devicetree
In-Reply-To: <20170110163015.22444-2-andrew.smirnov@gmail.com>
On Tue, Jan 10, 2017 at 08:30:14AM -0800, Andrey Smirnov wrote:
> Add code to support support for "anatop-enable-bit" device-tree
> property. This property translates to LINREG_ENABLE bit in real hardware
> and is present on 1p1, 2p5 and 3p0 regulators on i.MX6 and 1p0d regulator
> on i.MX7.
>
> Cc: yurovsky@gmail.com
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
>
> Note: "anatop-enable-bit" has already found its way into upstream tree
> before this patch (probably not on purpose). See imx6ul.dtsi and
> imx7s.dtsi for concrete examples
But since the kernel is not using it, it doesn't really mean we have to
keep it. Yes, other OSs could be, but that's unlikely.
> .../devicetree/bindings/regulator/anatop-regulator.txt | 1 +
> drivers/regulator/anatop-regulator.c | 12 ++++++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> index 37c4ea0..1d58c8c 100644
> --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> @@ -14,6 +14,7 @@ Optional properties:
> - anatop-delay-bit-shift: Bit shift for the step time register
> - anatop-delay-bit-width: Number of bits used in the step time register
> - vin-supply: The supply for this regulator
> +- anatop-enable-bit: Regulator enable bit offset
Looks like we have several properties describing the register layout.
IMO, we should drop all of them and use the compatible strings to
determine those instead.
Rob
^ permalink raw reply
* Re: [PATCH 09/37] PCI: dwc: designware: Parse *num-lanes* property in dw_pcie_setup_rc
From: Joao Pinto @ 2017-01-13 17:13 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Bjorn Helgaas, Jingoo Han, Joao Pinto,
Arnd Bergmann
Cc: devicetree, linux-samsung-soc, linux-doc, linux-pci, nsekhar,
linux-kernel, linux-arm-kernel, linux-arm-msm, linux-omap,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1484216786-17292-10-git-send-email-kishon@ti.com>
Hi,
Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> *num-lanes* dt property is parsed in dw_pcie_host_init. However
> *num-lanes* property is applicable to both root complex mode and
> endpoint mode. As a first step, move the parsing of this property
> outside dw_pcie_host_init. This is in preparation for splitting
> pcie-designware.c to pcie-designware.c and pcie-designware-host.c
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/pcie-designware.c | 18 +++++++++++-------
> drivers/pci/dwc/pcie-designware.h | 1 -
> 2 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware.c b/drivers/pci/dwc/pcie-designware.c
> index 00a0fdc..89cdb6b 100644
> --- a/drivers/pci/dwc/pcie-designware.c
> +++ b/drivers/pci/dwc/pcie-designware.c
> @@ -551,10 +551,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
> }
> }
>
> - ret = of_property_read_u32(np, "num-lanes", &pci->lanes);
> - if (ret)
> - pci->lanes = 0;
> -
> ret = of_property_read_u32(np, "num-viewport", &pci->num_viewport);
> if (ret)
> pci->num_viewport = 2;
> @@ -751,18 +747,26 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
>
> void dw_pcie_setup_rc(struct pcie_port *pp)
> {
> + int ret;
> + u32 lanes;
> u32 val;
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct device *dev = pci->dev;
> + struct device_node *np = dev->of_node;
>
> /* get iATU unroll support */
> pci->iatu_unroll_enabled = dw_pcie_iatu_unroll_enabled(pci);
> dev_dbg(pci->dev, "iATU unroll: %s\n",
> pci->iatu_unroll_enabled ? "enabled" : "disabled");
>
> + ret = of_property_read_u32(np, "num-lanes", &lanes);
> + if (ret)
> + lanes = 0;
You moved from host_init to root complex setup function, which in my opinion did
not improve (in this scope).
I suggest that instead of making so much intermediary patches, which is nice to
understand your development sequence, but hard to review. Wouldn't be better to
condense some of the patches? We would have a cloear vision of the final product :)
Joao
> +
> /* set the number of lanes */
> val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
> val &= ~PORT_LINK_MODE_MASK;
> - switch (pci->lanes) {
> + switch (lanes) {
> case 1:
> val |= PORT_LINK_MODE_1_LANES;
> break;
> @@ -776,7 +780,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
> val |= PORT_LINK_MODE_8_LANES;
> break;
> default:
> - dev_err(pci->dev, "num-lanes %u: invalid value\n", pci->lanes);
> + dev_err(pci->dev, "num-lanes %u: invalid value\n", lanes);
> return;
> }
> dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, val);
> @@ -784,7 +788,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
> /* set link width speed control register */
> val = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL);
> val &= ~PORT_LOGIC_LINK_WIDTH_MASK;
> - switch (pci->lanes) {
> + switch (lanes) {
> case 1:
> val |= PORT_LOGIC_LINK_WIDTH_1_LANES;
> break;
> diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-designware.h
> index d4b3d43..491fbe3 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -148,7 +148,6 @@ struct dw_pcie_ops {
> struct dw_pcie {
> struct device *dev;
> void __iomem *dbi_base;
> - u32 lanes;
> u32 num_viewport;
> u8 iatu_unroll_enabled;
> struct pcie_port pp;
>
^ permalink raw reply
* Re: [PATCH] Documentation: dt-bindings: Add binding documentation for TI clkctrl clocks
From: Tony Lindgren @ 2017-01-13 17:13 UTC (permalink / raw)
To: Rob Herring
Cc: Michael Turquette, Stephen Boyd, Tero Kristo,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Paul Walmsley
In-Reply-To: <20170113163647.6xbhoafb5xddtvnz@rob-hp-laptop>
* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170113 08:37]:
> On Tue, Jan 10, 2017 at 07:44:01AM -0800, Tony Lindgren wrote:
> > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170109 15:43]:
> > > Texas Instruments omap variant SoCs starting with omap4 have a clkctrl
> > > clock controller instance for each interconnect target module. The clkctrl
> > > controls functional and interface clocks for the module.
> > >
> > > The clkctrl clocks are currently handled by arch/arm/mach-omap2 hwmod code.
> > > With this binding and a related clock device driver we can start moving the
> > > clkctrl clock handling to live in drivers/clk/ti.
> > >
> > > For hardware reference, see omap4430 TRM "Table 3-1312. L4PER_CM2 Registers
> > > Mapping Summary" for example. It show one instance of a clkctrl clock
> > > controller with multiple clkctrl registers.
> > >
> > > Note that this binding allows keeping the clockdomain related parts out of
> > > drivers/clock. The CLKCTCTRL and DYNAMICDEP registers can be handled by
> > > using a separate driver in drivers/soc/ti and genpd. If the clockdomain
> > > driver needs to know it's clocks, we can just set the the clkctrl device
> > > instances to be children of the related clockdomain device.
> > >
> > > On omap4 CM_L3INIT_USB_HOST_HS_CLKCTRL on omap5 has eight OPTFCLKEN bits.
> > > So we need to shift the clock index to avoid index conflict for the clock
> > > consumer binding with the next clkctrl offset on omap4.
> > >
> > > Cc: Paul Walmsley <paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org>
> > > Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > > ---
> > >
> > > So here's what I was able to come up for the clkctr binding based on
> > > all we've discussed so far. Can you guys please take a look and see
> > > if it looks OK to you before we do the device driver?
> > >
> > > Also, does anybody have better suggestions for addressing the optional
> > > clocks in each clkctrl register?
> >
> > The other option that might be worth considering is to make use of the
> > #clock-cells property. Then the index of any optional clock could be passed
> > in the second cell.
> >
> > The third cell could be used to set the modulemode for the clock (software
> > controlled or hardware controlled) instead of using a custom property
> > at the clock controllel level.
>
> I guess I prefer this way. Or you could do a mixture of both proposals
> with 2 cells. The first being the clock id and the 2nd flags.
OK. I don't think we can do it with two cells with using real hardware
offsets for the clocks though. So in that case I'd prefer the three
cell binding as below.
> What's the max optional clocks in theory? B picked from the current
> worst case seems a bit worrying. Why not 16? Upper half is offset, lower
> half is index.
It seems the max is "stuff it into whatever bits are available" in the
register :) And I just noticed omap5 CM_L3INIT_USB_HOST_HS_CLKCTRL has 10
optional clocks, not 8. So yeah let's assume it could be even more.
> > In that case clock consume usage would look like the following using
> > #clock-cells = <3>:
> >
> > #define OMAP4_CLKCTRL_OFFSET 0x20
> > #define MODULEMODE_HWCTRL 1
> > #define MODULEMODE_SWCTRL 2
>
> Can you make one of these 0 instead or is both being set valid?
For MODULEMODE clock 0 means disabed. HWCTRL and SWCTRL are flags for
enabled mode.
So clock index 0 would be the MODULEMODE clock, index 1 first optional clock
and so on. The index could be also be the offset in the actual register
if you prefer that.
> > #define OMAP_CLKCTRL_INDEX(offset) ((offset) - OMAP4_CLKCTRL_OFFSET)
> >
> > #define OMAP4_GPTIMER10_CLKTRL OMAP_CLKCTRL_INDEX(0x28)
> > #define OMAP4_GPTIMER11_CLKTRL OMAP_CLKCTRL_INDEX(0x30)
> > #define OMAP4_GPTIMER2_CLKTRL OMAP_CLKCTRL_INDEX(0x38)
> > ...
> > #define OMAP4_GPIO2_CLKCTRL OMAP_CLKCTRL_INDEX(0x60)
> > ...
> >
> > &gpio2 {
> > clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
> > &cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL_DBCLK 1 0>;
>
> Drop the _DBCLK here, right?
Ah sorry yeah this should be:
&gpio2 {
clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 1 0>;
};
or if using actual bit offsets within the register instead of optional
clock instance count:
&gpio2 {
clocks = <&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 0 MODULEMODE_HWCTRL
&cm_l4per_clkctrl OMAP4_GPIO2_CLKCTRL 8 0>;
};
Regards,
Tony
--
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 36/37] ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
From: Tony Lindgren @ 2017-01-13 17:15 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Jingoo Han, Joao Pinto, Arnd Bergmann, linux-pci,
linux-doc, linux-kernel, devicetree, linux-omap, linux-arm-kernel,
linux-samsung-soc, linuxppc-dev, linux-arm-kernel, linux-arm-msm,
nsekhar
In-Reply-To: <1484216786-17292-37-git-send-email-kishon@ti.com>
* Kishon Vijay Abraham I <kishon@ti.com> [170112 02:35]:
> The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should
> be set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO
> in RC mode. However in EP mode, the host system is not able to access the
> MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.
I guess ideally in the long run we would set this dynamically based on
the selected mode, right?
Regards,
Tony
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c b/arch/arm/mach-omap2/clockdomains7xx_data.c
> index 6c67965..67ebff8 100644
> --- a/arch/arm/mach-omap2/clockdomains7xx_data.c
> +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
> @@ -524,7 +524,7 @@
> .dep_bit = DRA7XX_PCIE_STATDEP_SHIFT,
> .wkdep_srcs = pcie_wkup_sleep_deps,
> .sleepdep_srcs = pcie_wkup_sleep_deps,
> - .flags = CLKDM_CAN_HWSUP_SWSUP,
> + .flags = CLKDM_CAN_SWSUP,
> };
>
> static struct clockdomain atl_7xx_clkdm = {
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 05/37] PCI: dwc: Add platform_set_drvdata
From: Joao Pinto @ 2017-01-13 17:16 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Bjorn Helgaas, Jingoo Han, Joao Pinto,
Arnd Bergmann
Cc: linux-pci, linux-doc, linux-kernel, devicetree, linux-omap,
linux-arm-kernel, linux-samsung-soc, linuxppc-dev,
linux-arm-kernel, linux-arm-msm, nsekhar, Richard Zhu,
Lucas Stach, Murali Karicheri, Minghuan Lian, Mingkai Hu,
Roy Zang, Thomas Petazzoni, Niklas Cassel, Jesper Nilsson,
Zhou Wang, Gabrie
In-Reply-To: <1484216786-17292-6-git-send-email-kishon@ti.com>
Hi,
Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Add platform_set_drvdata in all designware based drivers to store the
> private data structure of the driver so that dev_set_drvdata can be
> used to get back private data pointer in add_pcie_port/host_init.
> This is in preparation for splitting struct pcie_port into core and
> host only structures. After the split pcie_port will not be part of
> the driver's private data structure and *container_of* used now
> to get the private data pointer cannot be used.
>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Richard Zhu <hongxing.zhu@nxp.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: Murali Karicheri <m-karicheri2@ti.com>
> Cc: Minghuan Lian <minghuan.Lian@freescale.com>
> Cc: Mingkai Hu <mingkai.hu@freescale.com>
> Cc: Roy Zang <tie-fei.zang@freescale.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Niklas Cassel <niklas.cassel@axis.com>
> Cc: Jesper Nilsson <jesper.nilsson@axis.com>
> Cc: Joao Pinto <Joao.Pinto@synopsys.com>
> Cc: Zhou Wang <wangzhou1@hisilicon.com>
> Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
> Cc: Pratyush Anand <pratyush.anand@gmail.com>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/pci-dra7xx.c | 3 ++-
> drivers/pci/dwc/pci-exynos.c | 3 ++-
> drivers/pci/dwc/pci-imx6.c | 3 ++-
> drivers/pci/dwc/pci-keystone.c | 2 ++
> drivers/pci/dwc/pci-layerscape.c | 2 ++
> drivers/pci/dwc/pcie-armada8k.c | 2 ++
> drivers/pci/dwc/pcie-artpec6.c | 2 ++
> drivers/pci/dwc/pcie-designware-plat.c | 2 ++
> drivers/pci/dwc/pcie-hisi.c | 2 ++
> drivers/pci/dwc/pcie-qcom.c | 2 ++
> drivers/pci/dwc/pcie-spear13xx.c | 3 ++-
> 11 files changed, 22 insertions(+), 4 deletions(-)
>
This is an example of a change that could be merged with another patch that
gives it more meaning, like I wrote in the review of patch 9/37.
Thanks,
Joao
^ permalink raw reply
* RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
From: Chris Brandt @ 2017-01-13 17:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAMuHMdVkTS21UnZA9OyEZ=mR5+GtAEbiLwpe=uKB_O6deXBPyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
> > But...that would make me think on boot it would be set to '01' (setting prohibited).
>
> Yeah, running with enabled SDHI core and disabled card detect sounds silly.
I just did some testing and with only 1 clock enabled ('01'), the core works but
card detect doesn't work. If you boot with the card in, you can read it fine, but
if you pull it...no removal is detected.
As soon as I turn the other clock on ('00'), card detect magically starts working.
So from my experiments:
00: SD Host Interface 1 Module runs.
>> everything works
01: Setting prohibited.
>> core runs, but no card detect
10: Only card detect block in SD Host Interface 1 Module runs.
>> SDHI address space all 00s (core not running)
11: Clock supply to SD Host Interface 1 Module is halted
>> nothing works (of course)
> So typically you want to use 10 when idle, and 00 when active.
I wonder if that would mean the system would get a CD interrupt. Of course
if no ISR registered (SDHI not enabled), the kernel would throw it away.
> No there isn't. That's another reason why a full-fledged clock driver with
> tables in C is a better idea than trying to describe all clocks in DT.
> The new CPG/MSSR based driver (renesas-cpg-mssr.c) supports "critical
> module clocks" through CLK_ENABLE_HAND_OFF. Unfortunately that flag hasn't
> made it upstream, so I really should convert the driver to use the new
> CLK_IS_CRITICAL instead...
So basically at the moment you're tell me it's going to stay broke (unless it's
enabled in u-boot).
In sh_mobile_sdhi.c, can we change sh_mobile_sdhi_probe() so that if there
are 2 clocks specified (in DT or platform data), it automatically enables
the 2nd clock (forever) and just uses the 1st clock as the on/off clock?
Chris
^ permalink raw reply
* Re: [PATCH] regulator: anatop: Add support for "anatop-enable-bit"
From: Rob Herring @ 2017-01-13 17:17 UTC (permalink / raw)
To: Andrey Smirnov
Cc: linux-kernel, yurovsky, Liam Girdwood, Mark Brown, Mark Rutland,
Shawn Guo, devicetree
In-Reply-To: <20170113170742.n4vacn373rmh6qqs@rob-hp-laptop>
On Fri, Jan 13, 2017 at 11:07:42AM -0600, Rob Herring wrote:
> On Tue, Jan 10, 2017 at 08:30:14AM -0800, Andrey Smirnov wrote:
> > Add code to support support for "anatop-enable-bit" device-tree
> > property. This property translates to LINREG_ENABLE bit in real hardware
> > and is present on 1p1, 2p5 and 3p0 regulators on i.MX6 and 1p0d regulator
> > on i.MX7.
> >
> > Cc: yurovsky@gmail.com
> > Cc: Liam Girdwood <lgirdwood@gmail.com>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> > ---
> >
> > Note: "anatop-enable-bit" has already found its way into upstream tree
> > before this patch (probably not on purpose). See imx6ul.dtsi and
> > imx7s.dtsi for concrete examples
>
> But since the kernel is not using it, it doesn't really mean we have to
> keep it. Yes, other OSs could be, but that's unlikely.
>
> > .../devicetree/bindings/regulator/anatop-regulator.txt | 1 +
> > drivers/regulator/anatop-regulator.c | 12 ++++++++++++
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> > index 37c4ea0..1d58c8c 100644
> > --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> > +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
> > @@ -14,6 +14,7 @@ Optional properties:
> > - anatop-delay-bit-shift: Bit shift for the step time register
> > - anatop-delay-bit-width: Number of bits used in the step time register
> > - vin-supply: The supply for this regulator
> > +- anatop-enable-bit: Regulator enable bit offset
>
> Looks like we have several properties describing the register layout.
> IMO, we should drop all of them and use the compatible strings to
> determine those instead.
NM, I see this on each regulator...
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] iio: distance: srf08: add trivial DT binding
From: Rob Herring @ 2017-01-13 17:18 UTC (permalink / raw)
To: Andreas Klinger
Cc: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel, ktsai,
wsa, pawel.moll, mark.rutland, ijc+devicetree, galak, trivial,
mranostay, linux-i2c, devicetree
In-Reply-To: <20170110184744.GA15520@andreas>
On Tue, Jan 10, 2017 at 07:47:44PM +0100, Andreas Klinger wrote:
> Add DT binding for devantech,srf08
> Add vendor devantech to vendor list
>
> Signed-off-by: Andreas Klinger <ak@it-klinger.de>
> ---
> Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 2 files changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] ARM: dts: OMAP5 / DRA7: indicate that SATA port 0 is available.
From: Tony Lindgren @ 2017-01-13 17:19 UTC (permalink / raw)
To: Jean-Jacques Hiblot; +Cc: bcousson, linux-omap, devicetree, rogerq, stable
In-Reply-To: <423304d1-ffe3-ce7e-74d9-9707c391d501@ti.com>
* Jean-Jacques Hiblot <jjhiblot@ti.com> [170113 00:00]:
>
>
> On 12/01/2017 23:36, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [170112 14:31]:
> > > * Jean-Jacques Hiblot <jjhiblot@ti.com> [170109 04:23]:
> > > > AHCI provides the register PORTS_IMPL to let the software know which port
> > > > is supported. The register must be initialized by the bootloader. However
> > > > in some cases u-boot doesn't properly initialize this value (if it is not
> > > > compiled with SATA support for example or if the SATA initialization fails).
> > > > The DTS entry "ports-implemented" can be used to override the value in
> > > > PORTS_IMPL.
> > > > Adding this entry in the dts allows us no to worry about what is done by
> > > > the bootloader.
> > > Adding into omap-for-v4.11/dt thanks.
> > Actually not applying just yet as I just noticed you tagged this for stable.
> >
> > Care to describe what breaks and on which devices without this patch?
> Hi tony,
>
> Without this patch the SATA will not work in the following two cases:
> * if there has been a failure to initialize SATA in u-boot.
> * if ahci_platform module has been removed and re-inserted. The reason is
> that the content of PORTS_IMPL is lost after the module is removed. I
> suspect that it's because the controller is reset by the hwmod.
OK I'll add that to the comments and apply into omap-for-v4.10/fixes.
Thanks,
Tony
^ permalink raw reply
* Re: [PATCH 07/37] PCI: dwc: designware: Get device pointer at the start of dw_pcie_host_init
From: Joao Pinto @ 2017-01-13 17:22 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Bjorn Helgaas, Jingoo Han, Joao Pinto,
Arnd Bergmann
Cc: devicetree, linux-samsung-soc, linux-doc, linux-pci, nsekhar,
linux-kernel, linux-arm-kernel, linux-arm-msm, linux-omap,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1484216786-17292-8-git-send-email-kishon@ti.com>
Hi!
Às 10:25 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> No functional change. Get device pointer at the beginning of
> dw_pcie_host_init instead of getting it all over dw_pcie_host_init.
> This is in preparation for splitting struct pcie_port into host and
> core structures (Once split pcie_port will not have device pointer).
>
I think change should be condense with another patch to reduce the patch-set
number and to give it real meaning. I understand why you are breaking so much
the patch, it is has a lot of changes, but in my opinion is too much fragmented.
Thanks
Joao
^ permalink raw reply
* Re: [PATCH v3 1/7] devicetree: power: add battery state machine documentation
From: Rob Herring @ 2017-01-13 17:23 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, sre-DgEjT+Ai2ygdnm+yROfE0A,
tony-4v6yS6AI5VpBDgjK7y7TUQ
In-Reply-To: <20170111062003.10110-2-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
On Tue, Jan 10, 2017 at 10:19:57PM -0800, Matt Ranostay wrote:
> Documentation on battery properties that can be defined for
> fine tuning fuel gauge state machines.
>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> ---
> .../devicetree/bindings/power/supply/battery.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/battery.txt
>
> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
> new file mode 100644
> index 000000000000..a6ca761e0a29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
> @@ -0,0 +1,20 @@
> +Battery State Machine Support
> +
> +Optional Properties
> + - nominal-microvolt: dead battery voltage in microvolts
> + - design-microwatt-hours: battery design mWh in microwatts
mWh in microwatts?
mWh would be milliwatt-hours.
> + - design-microamp-hours: battery design mAh in microamps
ditto
> +
> +Example:
> +
> + bat: battery@0 {
No reg prop, so no unit-address.
> + nominal-microvolt = <3700000>;
> + design-microwatt-hours = <5290000>;
> + design-microamp-hours = <1430000>;
> + };
> +
> + charger: charger@0 {
> + ....
> + monitored-battery = <&bat>;
> + ...
> + };
> --
> 2.10.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 6/7] devicetree: power: bq27xxx: add monitored battery documentation
From: Rob Herring @ 2017-01-13 17:28 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, sre-DgEjT+Ai2ygdnm+yROfE0A,
tony-4v6yS6AI5VpBDgjK7y7TUQ
In-Reply-To: <20170111062003.10110-7-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
On Tue, Jan 10, 2017 at 10:20:02PM -0800, Matt Ranostay wrote:
> Depends-On: http://marc.info/?l=linux-pm&m=148392292830015&w=2
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/power/supply/bq27xxx.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.txt b/Documentation/devicetree/bindings/power/supply/bq27xxx.txt
> index b0c95ef63e68..0472a2db0f13 100644
> --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.txt
> +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.txt
> @@ -28,9 +28,17 @@ Required properties:
> * "ti,bq27621" - BQ27621
> - reg: integer, i2c address of the device.
>
> +Optional properties:
> +- monitored-battery: phandle of battery information devicetree node
We need a common way to describe charger/monitor to battery connections,
not yet another way. The battery and power supply related bindings are a
bit of a mess from what I've looked at.
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 v8 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding
From: Rob Herring @ 2017-01-13 17:29 UTC (permalink / raw)
To: Hoegeun Kwon
Cc: krzk, thierry.reding, airlied, kgene, dri-devel, linux-kernel,
devicetree, linux-samsung-soc, inki.dae, a.hajda, cw00.choi,
jh80.chung, andi.shyti, Donghwa Lee, Hyungwon Hwang
In-Reply-To: <1484116439-7275-2-git-send-email-hoegeun.kwon@samsung.com>
On Wed, Jan 11, 2017 at 03:33:57PM +0900, Hoegeun Kwon wrote:
> The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
> .../bindings/display/panel/samsung,s6e3ha2.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
From: Geert Uytterhoeven @ 2017-01-13 17:31 UTC (permalink / raw)
To: Chris Brandt
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <SG2PR06MB1165D0D67AD68A12030C961D8A780@SG2PR06MB1165.apcprd06.prod.outlook.com>
Hi Chris,
On Fri, Jan 13, 2017 at 6:16 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
>> > But...that would make me think on boot it would be set to '01' (setting prohibited).
>>
>> Yeah, running with enabled SDHI core and disabled card detect sounds silly.
>
> I just did some testing and with only 1 clock enabled ('01'), the core works but
> card detect doesn't work. If you boot with the card in, you can read it fine, but
> if you pull it...no removal is detected.
> As soon as I turn the other clock on ('00'), card detect magically starts working.
>
> So from my experiments:
>
> 00: SD Host Interface 1 Module runs.
> >> everything works
>
> 01: Setting prohibited.
> >> core runs, but no card detect
>
> 10: Only card detect block in SD Host Interface 1 Module runs.
> >> SDHI address space all 00s (core not running)
>
> 11: Clock supply to SD Host Interface 1 Module is halted
> >> nothing works (of course)
>
>
>> So typically you want to use 10 when idle, and 00 when active.
>
> I wonder if that would mean the system would get a CD interrupt. Of course
> if no ISR registered (SDHI not enabled), the kernel would throw it away.
>
>
>> No there isn't. That's another reason why a full-fledged clock driver with
>> tables in C is a better idea than trying to describe all clocks in DT.
>> The new CPG/MSSR based driver (renesas-cpg-mssr.c) supports "critical
>> module clocks" through CLK_ENABLE_HAND_OFF. Unfortunately that flag hasn't
>> made it upstream, so I really should convert the driver to use the new
>> CLK_IS_CRITICAL instead...
>
> So basically at the moment you're tell me it's going to stay broke (unless it's
> enabled in u-boot).
>
> In sh_mobile_sdhi.c, can we change sh_mobile_sdhi_probe() so that if there
> are 2 clocks specified (in DT or platform data), it automatically enables
> the 2nd clock (forever) and just uses the 1st clock as the on/off clock?
Of course the driver can handle the second interrupt, if you update the
binding, and add support code for that...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Marek Vasut @ 2017-01-13 17:33 UTC (permalink / raw)
To: Boris Brezillon
Cc: Matthias Brugger, Guochun Mao, David Woodhouse, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Russell King, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170113175628.1793f433@bbrezillon>
On 01/13/2017 05:56 PM, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 17:44:12 +0100
> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
>>> On Fri, 13 Jan 2017 17:13:55 +0100
>>> Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>>> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
>>>>>
>>>>>
>>>>> On 13/01/17 15:17, Boris Brezillon wrote:
>>>>>> On Fri, 13 Jan 2017 15:13:29 +0800
>>>>>> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>>>>>>
>>>>>>> Add Mediatek nor flash node.
>>>>>>>
>>>>>>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/mt2701-evb.dts | 25 +++++++++++++++++++++++++
>>>>>>> arch/arm/boot/dts/mt2701.dtsi | 12 ++++++++++++
>>>>>>> 2 files changed, 37 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> index 082ca88..85e5ae8 100644
>>>>>>> --- a/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> +++ b/arch/arm/boot/dts/mt2701-evb.dts
>>>>>>> @@ -24,6 +24,31 @@
>>>>>>> };
>>>>>>> };
>>>>>>>
>>>>>>> +&nor_flash {
>>>>>>> + pinctrl-names = "default";
>>>>>>> + pinctrl-0 = <&nor_pins_default>;
>>>>>>> + status = "okay";
>>>>>>> + flash@0 {
>>>>>>> + compatible = "jedec,spi-nor";
>>>>>>> + reg = <0>;
>>>>>>> + };
>>>>>>> +};
>>>>>>> +
>>>>>>> +&pio {
>>>>>>> + nor_pins_default: nor {
>>>>>>> + pins1 {
>>>>>>> + pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
>>>>>>> + <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
>>>>>>> + <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
>>>>>>> + <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
>>>>>>> + <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
>>>>>>> + <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
>>>>>>> + drive-strength = <MTK_DRIVE_4mA>;
>>>>>>> + bias-pull-up;
>>>>>>> + };
>>>>>>> + };
>>>>>>> +};
>>>>>>> +
>>>>>>> &uart0 {
>>>>>>> status = "okay";
>>>>>>> };
>>>>>>> diff --git a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> index bdf8954..1eefce4 100644
>>>>>>> --- a/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/mt2701.dtsi
>>>>>>> @@ -227,6 +227,18 @@
>>>>>>> status = "disabled";
>>>>>>> };
>>>>>>>
>>>>>>> + nor_flash: spi@11014000 {
>>>>>>> + compatible = "mediatek,mt2701-nor",
>>>>>>> + "mediatek,mt8173-nor";
>>>>>>
>>>>>> Why define both here? Is "mediatek,mt8173-nor" really providing a
>>>>>> subset of the features supported by "mediatek,mt2701-nor"?
>>>>>>
>>>>>
>>>>> I think even if the ip block is the same, we should provide both
>>>>> bindings, just in case in the future we find out that mt2701 has some
>>>>> hidden bug, feature or bug-feature. This way even if we update the
>>>>> driver, we stay compatible with older device tree blobs in the wild.
>>>>>
>>>>> We can drop the mt2701-nor in the bindings definition if you want.
>>>
>>> Oh, sorry, I misunderstood. What I meant is that if you want to
>>> list/support all possible compatibles, maybe you should just put one
>>> compatible in your DT and patch your driver (+ binding doc) to define
>>> all of them.
>>
>> Uh, what ? I lost you here :-)
>>
>>>> This exactly. We should have a DT compat in the form:
>>>> compatible = "vendor,<soc>-block", "vendor,<oldest-compat-soc>-block";
>>>> Then if we find a problem in the future, we can match on the
>>>> "vendor,<soc>-block" and still support the old DTs.
>>>
>>> Not sure it's only in term of whose IP appeared first. My understanding
>>> is that it's a way to provide inheritance. For example:
>>>
>>> "<soc-vendor>,<ip-version>", "<ip-vendor>,<ip-version>";
>>>
>>> or
>>>
>>> "<soc-vendor>,<full-featured-ip-version>","<soc-vendor>,<basic-feature-ip-version>";
>>>
>>> BTW, which one is the oldest between mt8173 and mt2701? :-)
>>
>> And that's another thing and I agree with you, but I don't think that's
>> what we're discussing in this thread. But (!), OT, I think we should
>> codify the rules in Documentation/ . This discussion came up multiple
>> times recently.
>>
>> And my question still stands, what do we put into the DT here, IMO
>> compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
>
> I'd say
>
> compatible = "mediatek,mt8173-nor";
>
> because both compatible are referring to very specific IP version. It's
> not the same as
But then you don't have the ability to handle a block in this particular
SoC in case there's a bug found in it in the future,
so IMO it should be:
compatible = "mediatek,mt2701-nor", "mediatek,mt8173-nor";
> compatible = "mediatek,mt8173-nor", "mediatek,mt81xx-nor";
This doesn't look right, since here we add two new compatibles ...
> where you clearly have a generic compatible which is overloaded by a
> specific one.
>
> But anyway, I'm not the one taking the decision here, let's wait for DT
> maintainers reviews.
>
>> and what goes into the binding document ? I guess both too ?
>
> If both exist, they should be both documented.
>
--
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 v11 01/12] dt-bindings: display: mediatek: update supported chips
From: Rob Herring @ 2017-01-13 17:37 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Matthias Brugger, linux-mediatek,
yingjoe.chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-2-git-send-email-yt.shen@mediatek.com>
On Wed, Jan 11, 2017 at 02:51:02PM +0800, YT Shen wrote:
> Add decriptions about supported chips, including MT2701 & MT8173
>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 ++
> Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt | 2 ++
> 2 files changed, 4 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v1 1/1] iio: adc: tlc4541: add support for TI tlc4541 adc
From: Rob Herring @ 2017-01-13 17:39 UTC (permalink / raw)
To: Phil Reid
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
mark.rutland-5wv7dgnIgG8, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484117471-67082-1-git-send-email-preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
On Wed, Jan 11, 2017 at 02:51:11PM +0800, Phil Reid wrote:
> This adds TI's tlc4541 16-bit ADC driver. Which is a single channel
> ADC. Supports raw and trigger buffer access.
> Also supports the tlc3541 14-bit device, which has not been tested.
> Implementation of the tlc3541 is fairly straight forward thou.
>
> Signed-off-by: Phil Reid <preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
> ---
>
> Notes:
> Changes from v1:
> - Add tlc3541 support and chan spec.
> - remove fields that where already 0 from TLC4541_V_CHAN macro
> - Increase rx_buf size in tlc4541_state to avoid copy in tlc4541_trigger_handle
> - Remove erroneous be16_to_cpu in tlc4541_trigger_handle
> - Docs/binding: spi -> SPI & add ti,tlc3541
>
> I haven't add Rob's Ack due to adding a new compatible string.
>
> I tried to ".index = 1" from the spec as suggested by Peter, but that didn't
> seem to work. Perhaps remove of .channel was the intended target.
>
> Example output from iio_readdev
>
> with ".index = 1"
> root@cyclone5:~# mkdir /sys/kernel/config/iio/triggers/hrtimer/hr1
> root@cyclone5:~# iio_readdev -t hr1 -b 32 -s 10 tlc4541 | hexdump
> WARNING: High-speed mode not enabled
> 0000000 af00 0000 0000 0000 b922 ca99 93da 1492
> 0000010 a800 00ff 0000 0000 b246 cb30 93da 1492
> 0000020 a900 0000 0000 0000 4f9c cbc9 93da 1492
> 0000030 aa00 00ff 0000 0000 bd2c cc61 93da 1492
> 0000040 aa00 00ff 0000 0000 544c ccfa 93da 1492
> 0000050 ab00 00ff 0000 0000 e806 cd92 93da 1492
> 0000060 a900 00ff 0000 0000 846c ce2b 93da 1492
> 0000070 ab00 0000 0000 0000 2efc cec8 93da 1492
> 0000080 a800 00ff 0000 0000 b090 cf5c 93da 1492
> 0000090 a900 00ff 0000 0000 476a cff5 93da 1492
>
> without .index
> root@cyclone5:~# mkdir /sys/kernel/config/iio/triggers/hrtimer/hr1
> root@cyclone5:~# iio_readdev -t hr1 -b 32 -s 10 tlc4541 | hexdump
> WARNING: High-speed mode not enabled
> 0000000 6db0 eeb6 93e3 1492 35e0 ef4f 93e3 1492
> 0000010 4b34 efe5 93e3 1492 e9f2 f07d 93e3 1492
> 0000020 6182 f116 93e3 1492 090a f1af 93e3 1492
> 0000030 409c f249 93e3 1492 6c1a f2e0 93e3 1492
> 0000040 cd02 f378 93e3 1492 9582 f411 93e3 1492
>
> .../devicetree/bindings/iio/adc/ti-tlc4541.txt | 17 ++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/iio/adc/Kconfig | 11 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ti-tlc4541.c | 276 +++++++++++++++++++++
> 4 files changed, 305 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-tlc4541.txt
> create mode 100644 drivers/iio/adc/ti-tlc4541.c
^ permalink raw reply
* Re: [PATCH 12/37] PCI: dwc: Create a new config symbol to enable pci dwc host
From: Joao Pinto @ 2017-01-13 17:50 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Bjorn Helgaas, Jingoo Han, Joao Pinto,
Arnd Bergmann
Cc: linux-pci, linux-doc, linux-kernel, devicetree, linux-omap,
linux-arm-kernel, linux-samsung-soc, linuxppc-dev,
linux-arm-kernel, linux-arm-msm, nsekhar
In-Reply-To: <1484216786-17292-13-git-send-email-kishon@ti.com>
Hi Kishon,
Às 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
> Now that pci designware host has a separate file, create a new
> config symbol to select the host only driver. This is in preparation
> to enable endpoint support to designware driver.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/dwc/Kconfig | 26 +++++++++++++++-----------
> drivers/pci/dwc/Makefile | 3 ++-
> drivers/pci/dwc/pcie-designware.h | 29 +++++++++++++++++++++++++----
> 3 files changed, 42 insertions(+), 16 deletions(-)
>
You are already working in a base where dwc/ already exists. I know you made a
rename / re-structure patch for pci, but I think it was not yet accepted, right?
I don't see it in any of Bjorn' dev branches.
Thanks.
> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index 8b08519..d0bdfb5 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -3,13 +3,17 @@ menu "DesignWare PCI Core Support"
>
> config PCIE_DW
> bool
> +
> +config PCIE_DW_HOST
> + bool
> depends on PCI_MSI_IRQ_DOMAIN
> + select PCIE_DW
>
> config PCI_DRA7XX
> bool "TI DRA7xx PCIe controller"
> depends on OF && HAS_IOMEM && TI_PIPE3
> depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Enables support for the PCIe controller in the DRA7xx SoC. There
> are two instances of PCIe controller in DRA7xx. This controller can
> @@ -18,7 +22,7 @@ config PCI_DRA7XX
> config PCIE_DW_PLAT
> bool "Platform bus based DesignWare PCIe Controller"
> depends on PCI_MSI_IRQ_DOMAIN
> - select PCIE_DW
> + select PCIE_DW_HOST
> ---help---
> This selects the DesignWare PCIe controller support. Select this if
> you have a PCIe controller on Platform bus.
> @@ -32,21 +36,21 @@ config PCI_EXYNOS
> depends on SOC_EXYNOS5440 || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>
> config PCI_IMX6
> bool "Freescale i.MX6 PCIe controller"
> depends on SOC_IMX6Q || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
>
> config PCIE_SPEAR13XX
> bool "STMicroelectronics SPEAr PCIe controller"
> depends on ARCH_SPEAR13XX || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want PCIe support on SPEAr13XX SoCs.
>
> @@ -55,7 +59,7 @@ config PCI_KEYSTONE
> depends on ARCH_KEYSTONE || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want to enable PCI controller support on Keystone
> SoCs. The PCI controller on Keystone is based on Designware hardware
> @@ -67,7 +71,7 @@ config PCI_LAYERSCAPE
> depends on OF && (ARM || ARCH_LAYERSCAPE || COMPILE_TEST)
> depends on PCI_MSI_IRQ_DOMAIN
> select MFD_SYSCON
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want PCIe controller support on Layerscape SoCs.
>
> @@ -76,7 +80,7 @@ config PCI_HISI
> bool "HiSilicon Hip05 and Hip06 SoCs PCIe controllers"
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want PCIe controller support on HiSilicon
> Hip05 and Hip06 SoCs
> @@ -86,7 +90,7 @@ config PCIE_QCOM
> depends on (ARCH_QCOM || COMPILE_TEST) && OF
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here to enable PCIe controller support on Qualcomm SoCs. The
> PCIe controller uses the Designware core plus Qualcomm-specific
> @@ -97,7 +101,7 @@ config PCIE_ARMADA_8K
> depends on ARCH_MVEBU || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here if you want to enable PCIe controller support on
> Armada-8K SoCs. The PCIe controller on Armada-8K is based on
> @@ -109,7 +113,7 @@ config PCIE_ARTPEC6
> depends on MACH_ARTPEC6 || COMPILE_TEST
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> - select PCIE_DW
> + select PCIE_DW_HOST
> help
> Say Y here to enable PCIe controller support on Axis ARTPEC-6
> SoCs. This PCIe controller uses the DesignWare core.
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index 3b57e55..a2df13c 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -1,4 +1,5 @@
> -obj-$(CONFIG_PCIE_DW) += pcie-designware.o pcie-designware-host.o
> +obj-$(CONFIG_PCIE_DW) += pcie-designware.o
> +obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
> obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
> obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
> obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
> diff --git a/drivers/pci/dwc/pcie-designware.h b/drivers/pci/dwc/pcie-designware.h
> index 808d17b..8f3dcb2 100644
> --- a/drivers/pci/dwc/pcie-designware.h
> +++ b/drivers/pci/dwc/pcie-designware.h
> @@ -162,10 +162,6 @@ struct dw_pcie {
>
> int dw_pcie_read(void __iomem *addr, int size, u32 *val);
> int dw_pcie_write(void __iomem *addr, int size, u32 val);
> -irqreturn_t dw_handle_msi_irq(struct pcie_port *pp);
> -void dw_pcie_msi_init(struct pcie_port *pp);
> -void dw_pcie_setup_rc(struct pcie_port *pp);
> -int dw_pcie_host_init(struct pcie_port *pp);
>
> u32 dw_pcie_readl_dbi(struct dw_pcie *pci, u32 reg);
> void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val);
> @@ -175,4 +171,29 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
> int type, u64 cpu_addr, u64 pci_addr,
> u32 size);
> void dw_pcie_setup(struct dw_pcie *pci);
> +
> +#ifdef CONFIG_PCIE_DW_HOST
> +irqreturn_t dw_handle_msi_irq(struct pcie_port *pp);
> +void dw_pcie_msi_init(struct pcie_port *pp);
> +void dw_pcie_setup_rc(struct pcie_port *pp);
> +int dw_pcie_host_init(struct pcie_port *pp);
> +#else
> +static inline irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> +{
> + return IRQ_NONE;
> +}
> +
> +static inline void dw_pcie_msi_init(struct pcie_port *pp)
> +{
> +}
> +
> +static inline void dw_pcie_setup_rc(struct pcie_port *pp)
> +{
> +}
> +
> +static inline int dw_pcie_host_init(struct pcie_port *pp)
> +{
> + return 0;
> +}
> +#endif
> #endif /* _PCIE_DESIGNWARE_H */
>
^ permalink raw reply
* RE: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
From: Chris Brandt @ 2017-01-13 17:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAMuHMdUVnUS-iOM8cbXNP7jMLNFb5+hgnMp3edkCzpbEpAePzw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
On Friday, January 13, 2017, Geert Uytterhoeven wrote:
> > In sh_mobile_sdhi.c, can we change sh_mobile_sdhi_probe() so that if
> > there are 2 clocks specified (in DT or platform data), it
> > automatically enables the 2nd clock (forever) and just uses the 1st
> clock as the on/off clock?
>
> Of course the driver can handle the second interrupt, if you update the
> binding, and add support code for that...
Of course my idea is that I would only have to update the bindings for
RZ/A1...not any other device.
My only question is, today sh_mobile_sdhi.c uses this:
priv->clk = devm_clk_get(&pdev->dev, NULL);
to get the clock. But if there is a 2nd clock...how do I know the
string id name to look to replace NULL with??
Or...for the RZ/A1 dtsi, should I just give the 2 clocks names:
clocks = <&mstp12_clks R7S72100_CLK_SDHI00,
&mstp12_clks R7S72100_CLK_SDHI01>;
clock-names = "core", "cd";
and then in the code do:
struct *cd_clk;
cd_clk = devm_clk_get(&pdev->dev, "cd");
if (cd_clk) {
clk_prepare_enable(cd_clk);
}
(this simple 1-line fix patch is getting a lot more complicated)
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH 16/37] PCI: endpoint: Introduce configfs entry for configuring EP functions
From: Christoph Hellwig @ 2017-01-13 18:06 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: devicetree, Joao Pinto, Arnd Bergmann, linux-doc, Jingoo Han,
linux-arm-msm, nsekhar, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-pci, Bjorn Helgaas, linux-omap,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1484216786-17292-17-git-send-email-kishon@ti.com>
Hi Kishon,
a couple comments on the configfs layout based on my experiments with
your previous drop to implement a NVMe device using it.
I don't think most of these configfs files should be present here, as
they are properties of the implemented PCIe devices. E.g. for my
NVMe device they will be sort of hardcoded most of the time, as they
would be for other devices that would always have a fixed vendor/device/
class ID, cacheline size, etc.
In the end what we'll to be able to do here is to be able to create
a directory for each function driver, which then can create it's own
attributes inside it.
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: dra7-evm: increase QSPI SPL partition size
From: Tony Lindgren @ 2017-01-13 18:12 UTC (permalink / raw)
To: Ravi Babu
Cc: devicetree, nsekhar, Sekhar Nori, bcousson, linux-omap,
linux-arm-kernel
In-Reply-To: <1484311234-21978-2-git-send-email-ravibabu@ti.com>
* Ravi Babu <ravibabu@ti.com> [170113 04:41]:
> The SPL size for DRA74x platform has increased and
> is now more than 64KB. Increase QSPI SPL partition
> size to 256KB for DRA74x EVM.
>
> QSPI partition numbering changes because of this.
And this will break the existing partitions potentially..
See what was discussed on the list few days ago in thread
"[PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND
partition table".
It's best to have these left empty or as they originally
were and let u-boot configure the partitions.
Regards,
Tony
> Signed-off-by: Ravi Babu <ravibabu@ti.com>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> ---
> arch/arm/boot/dts/dra7-evm.dts | 24 ++++++------------------
> 1 file changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index 132f2be..2784241 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -681,41 +681,29 @@
> */
> partition@0 {
> label = "QSPI.SPL";
> - reg = <0x00000000 0x000010000>;
> + reg = <0x00000000 0x000040000>;
> };
> partition@1 {
> - label = "QSPI.SPL.backup1";
> - reg = <0x00010000 0x00010000>;
> - };
> - partition@2 {
> - label = "QSPI.SPL.backup2";
> - reg = <0x00020000 0x00010000>;
> - };
> - partition@3 {
> - label = "QSPI.SPL.backup3";
> - reg = <0x00030000 0x00010000>;
> - };
> - partition@4 {
> label = "QSPI.u-boot";
> reg = <0x00040000 0x00100000>;
> };
> - partition@5 {
> + partition@2 {
> label = "QSPI.u-boot-spl-os";
> reg = <0x00140000 0x00080000>;
> };
> - partition@6 {
> + partition@3 {
> label = "QSPI.u-boot-env";
> reg = <0x001c0000 0x00010000>;
> };
> - partition@7 {
> + partition@4 {
> label = "QSPI.u-boot-env.backup1";
> reg = <0x001d0000 0x0010000>;
> };
> - partition@8 {
> + partition@5 {
> label = "QSPI.kernel";
> reg = <0x001e0000 0x0800000>;
> };
> - partition@9 {
> + partition@6 {
> label = "QSPI.file-system";
> reg = <0x009e0000 0x01620000>;
> };
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v3] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: David Lechner @ 2017-01-13 18:16 UTC (permalink / raw)
To: Sekhar Nori, devicetree, linux-arm-kernel
Cc: Kevin Hilman, Rob Herring, Mark Rutland, linux-kernel
In-Reply-To: <3066d614-0676-319a-6149-6d723e1cf35f@ti.com>
On 01/13/2017 06:04 AM, Sekhar Nori wrote:
> On Friday 13 January 2017 02:02 AM, David Lechner wrote:
>> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>>
...
>
> There are couple of checkpatch errors that show up. The compatible
> "lego,ev3" needs to be documented in
> Documentation/devicetree/bindings/arm/davinci.txt
>
> "at24,24c128" is undocumented. Is that an atmel chip on the EV3? If the
> manufacturer name is not clear,
> Documentation/devicetree/bindings/eeprom/eeprom.txt advises using just
> "24c128"
The mfg is microchip, so I guess I will just go with "24c128"
>
> Finally, lego needs to be added to
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
> Can you please submit the documentation portions as separate patches in
> a series along with this patch.
Yes.
>
> Thanks,
> Sekhar
>
^ 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