* RE: [PATCH] Documentation: binding: Update endianness usage
From: Prabhakar Kushwaha @ 2017-12-05 9:45 UTC (permalink / raw)
To: Scott Wood,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <1512441957.10062.6.camel-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2924 bytes --]
> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Tuesday, December 05, 2017 8:16 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> mtd@lists.infradead.org; devicetree@vger.kernel.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: Re: [PATCH] Documentation: binding: Update endianness usage
>
> On Mon, 2017-12-04 at 04:33 +0000, Prabhakar Kushwaha wrote:
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Saturday, December 02, 2017 3:25 AM
> > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > >
> > > On Fri, 2017-12-01 at 08:42 +0000, Prabhakar Kushwaha wrote:
> > > > > -----Original Message-----
> > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > Sent: Friday, December 01, 2017 10:43 AM
> > > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > > > mtd@lists.infradead.org; devicetree-discuss@lists.ozlabs.org
> > > > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > > > >
> > > > > If big endian is the default, is this change really
> > > > > necessary?  Particularly
> > > > > since the big endian chips are older and thus have existing device
> > > > > trees.
> > > > >
> > > >
> > > > Earlier endianness information was only used for "how to"Â Â access IFC-
> > > > NAND
> > > > register access.
> > > > Now this info  will also be used for defining swap requirement of NOR
> > > > flash.
> > >
> > > Is this a difference between LS1021A and PPC-based chips?
> > >
> >
> > Yes.
> > CONFIG_MTD_CFI_BE_BYTE_SWAP needs to be defined For LS1021A, LS1043A,
> > LS1046A
>
> Only because you're running a little-endian kernel on those chips. I still
> don't see why the absence of a little-endian property isn't sufficient to
> communicate that the hardware is big-endian given that that's the established
> default.
>
> I now see your patch to of_flash_probe... where is the non-IFC-specific
> binding that says the *parent* of a CFI node should be looked at for this?
> Where in general are endian properties kept in the parent of the node with
> "reg"? The right answer is to add endianness to mtd-physmap.txt.
>
Flashes are always littler endian.
It is because of IFC controller behavior, endianness is required.
So as per my understanding, this info should go in IFC binding.
Please help me if I am not able to understand your view.
--prabhakar
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* Re: [PATCH v4 09/10] ARM: dtsi: axp81x: add GPIO DT node
From: Maxime Ripard @ 2017-12-05 9:39 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Quentin Schulz, Linus Walleij, Rob Herring, Mark Rutland,
Russell King, Lee Jones,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
linux-kernel, linux-arm-kernel, Thomas Petazzoni, linux-sunxi
In-Reply-To: <CAGb2v65mOwNBdit=gKOq0=iv94FNuH__4yvCw4v0NHYiCKccBw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]
Hi,
On Tue, Dec 05, 2017 at 05:24:47PM +0800, Chen-Yu Tsai wrote:
> On Fri, Dec 1, 2017 at 9:44 PM, Quentin Schulz
> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > This adds DT node for the GPIO/pinctrl part present in AXP813/AXP818.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > arch/arm/boot/dts/axp81x.dtsi | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
> > index 73b761f..0ef959d 100644
> > --- a/arch/arm/boot/dts/axp81x.dtsi
> > +++ b/arch/arm/boot/dts/axp81x.dtsi
> > @@ -48,6 +48,12 @@
> > interrupt-controller;
> > #interrupt-cells = <1>;
> >
> > + axp_gpio: axp-gpio {
> > + compatible = "x-powers,axp813-gpio";
> > + gpio-controller;
> > + #gpio-cells = <2>;
>
> What about interrupt-controller for directly referenced interrupts from
> the GPIO pins?
There's a bit more to it to enable interrupts. You would probably need
to set up a chained interrupt controller in the GPIO driver, and in
the DTS with a interrupt-parent and interrupts properties pointing to
the AXP device itself.
> Otherwise,
>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Applied 9 and 10, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: hwrng: Add Samsung Exynos 5250+ True RNG bindings
From: Łukasz Stelmach @ 2017-12-05 9:30 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring
Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Matt Mackall,
Herbert Xu, Kukjin Kim, devicetree, linux-crypto,
linux-samsung-soc, linux-kernel, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <CAJKOXPej1G6npvNSr9TP8DmWubtZpn6ONeNMN4Ax_RaafMiT7g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]
It was <2017-12-04 pon 14:13>, when Krzysztof Kozlowski wrote:
> On Mon, Dec 4, 2017 at 1:53 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
>> Add binding documentation for the True Random Number Generator
>> found on Samsung Exynos 5250+ SoCs.
>>
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> ---
>> .../devicetree/bindings/rng/samsung,exynos5250-trng.txt | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
>> b/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
>> new file mode 100644
>> index 000000000000..5a613a4ec780
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
>> @@ -0,0 +1,17 @@
>> +Exynos True Random Number Generator
>> +
>> +Required properties:
>> +
>> +- compatible : Should be "samsung,exynos5250-trng".
>> +- reg : Specifies base physical address and size of the registers map.
>> +- clocks : Phandle to clock-controller plus clock-specifier pair.
>> +- clock-names : "secss" as a clock name.
>> +
>> +Example:
>> +
>> + rng@10830600 {
>> + compatible = "samsung,exynos5250-trng";
>> + reg = <0x10830600 0x100>;
>> + clocks = <&clock CLK_SSS>;
>> + clock-names = "secss";
>> + };
>> --
>> 2.11.0
>
> Mine and Rob's tags disappeared and I think you did not introduce any
> major changes here, right?
A very experienced kernel developer adviced me to remove them.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply
* Re: [PATCH v4 10/10] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs
From: Chen-Yu Tsai @ 2017-12-05 9:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Quentin Schulz, Linus Walleij, Rob Herring, Mark Rutland,
Chen-Yu Tsai, Russell King, Lee Jones,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
linux-kernel, linux-arm-kernel, Thomas Petazzoni, linux-sunxi
In-Reply-To: <20171201155808.rxgp7pz7nmr6tab7-ZC1Zs529Oq4@public.gmane.org>
On Fri, Dec 1, 2017 at 11:58 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Fri, Dec 01, 2017 at 02:44:51PM +0100, Quentin Schulz wrote:
>> On AXP813/818, GPIO0 and GPIO1 can be used as LDO as (respectively)
>> ldo_io0 and ldo_io1.
>>
>> Let's add the pinctrl properties to the said regulators.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v4 09/10] ARM: dtsi: axp81x: add GPIO DT node
From: Chen-Yu Tsai @ 2017-12-05 9:24 UTC (permalink / raw)
To: Quentin Schulz
Cc: Linus Walleij, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, Lee Jones,
linux-gpio@vger.kernel.org, devicetree, linux-kernel,
linux-arm-kernel, Thomas Petazzoni, linux-sunxi
In-Reply-To: <af90c57ebf97c8f5504a4b5b1dad3638bedadfef.1512135804.git-series.quentin.schulz@free-electrons.com>
On Fri, Dec 1, 2017 at 9:44 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This adds DT node for the GPIO/pinctrl part present in AXP813/AXP818.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> arch/arm/boot/dts/axp81x.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
> index 73b761f..0ef959d 100644
> --- a/arch/arm/boot/dts/axp81x.dtsi
> +++ b/arch/arm/boot/dts/axp81x.dtsi
> @@ -48,6 +48,12 @@
> interrupt-controller;
> #interrupt-cells = <1>;
>
> + axp_gpio: axp-gpio {
> + compatible = "x-powers,axp813-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
What about interrupt-controller for directly referenced interrupts from
the GPIO pins?
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> + };
> +
> regulators {
> /* Default work frequency for buck regulators */
> x-powers,dcdc-freq = <3000>;
> --
> git-series 0.9.1
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 5/5] PCI: cadence: add EndPoint Controller driver for Cadence PCIe controller
From: Kishon Vijay Abraham I @ 2017-12-05 9:19 UTC (permalink / raw)
To: Lorenzo Pieralisi, Cyrille Pitchen
Cc: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
adouglas-vna1KIf7WgpBDgjK7y7TUQ, stelford-vna1KIf7WgpBDgjK7y7TUQ,
dgary-vna1KIf7WgpBDgjK7y7TUQ, kgopi-vna1KIf7WgpBDgjK7y7TUQ,
eandrews-vna1KIf7WgpBDgjK7y7TUQ,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
sureshp-vna1KIf7WgpBDgjK7y7TUQ, nsekhar-l0cyMroinI0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171201122048.GB25010@red-moon>
Hi,
On Friday 01 December 2017 05:50 PM, Lorenzo Pieralisi wrote:
> On Thu, Nov 23, 2017 at 04:01:50PM +0100, Cyrille Pitchen wrote:
>> This patch adds support to the Cadence PCIe controller in endpoint mode.
>
> Please add a brief description to the log to describe the most salient
> features.
>
>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> ---
>> drivers/pci/cadence/Kconfig | 9 +
>> drivers/pci/cadence/Makefile | 1 +
>> drivers/pci/cadence/pcie-cadence-ep.c | 553 ++++++++++++++++++++++++++++++++++
>> 3 files changed, 563 insertions(+)
>> create mode 100644 drivers/pci/cadence/pcie-cadence-ep.c
>>
>> diff --git a/drivers/pci/cadence/Kconfig b/drivers/pci/cadence/Kconfig
>> index 120306cae2aa..b2e6af71f39e 100644
>> --- a/drivers/pci/cadence/Kconfig
>> +++ b/drivers/pci/cadence/Kconfig
>> @@ -21,4 +21,13 @@ config PCIE_CADENCE_HOST
>> mode. This PCIe controller may be embedded into many different vendors
>> SoCs.
>>
>> +config PCIE_CADENCE_EP
>> + bool "Cadence PCIe endpoint controller"
>> + depends on PCI_ENDPOINT
>> + select PCIE_CADENCE
>> + help
>> + Say Y here if you want to support the Cadence PCIe controller in
>> + endpoint mode. This PCIe controller may be embedded into many
>> + different vendors SoCs.
>> +
>> endif # PCI_CADENCE
>> diff --git a/drivers/pci/cadence/Makefile b/drivers/pci/cadence/Makefile
>> index d57d192d2595..61e9c8d6839d 100644
>> --- a/drivers/pci/cadence/Makefile
>> +++ b/drivers/pci/cadence/Makefile
>> @@ -1,2 +1,3 @@
>> obj-$(CONFIG_PCIE_CADENCE) += pcie-cadence.o
>> obj-$(CONFIG_PCIE_CADENCE_HOST) += pcie-cadence-host.o
>> +obj-$(CONFIG_PCIE_CADENCE_EP) += pcie-cadence-ep.o
>> diff --git a/drivers/pci/cadence/pcie-cadence-ep.c b/drivers/pci/cadence/pcie-cadence-ep.c
>> new file mode 100644
>> index 000000000000..a1d761101a9c
>> --- /dev/null
>> +++ b/drivers/pci/cadence/pcie-cadence-ep.c
>> @@ -0,0 +1,553 @@
>> +/*
>> + * Cadence PCIe host controller driver.
>
> You should update this comment.
>
>> + *
>> + * Copyright (c) 2017 Cadence
>> + *
>> + * Author: Cyrille Pitchen <cyrille.pitchen-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +#include <linux/kernel.h>
>> +#include <linux/of.h>
>> +#include <linux/pci-epc.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>> +#include <linux/sizes.h>
>> +#include <linux/delay.h>
>
> Nit: alphabetical order.
>
>> +#include "pcie-cadence.h"
>> +
>> +#define CDNS_PCIE_EP_MIN_APERTURE 128 /* 128 bytes */
>> +#define CDNS_PCIE_EP_IRQ_PCI_ADDR_NONE 0x1
>> +#define CDNS_PCIE_EP_IRQ_PCI_ADDR_LEGACY 0x3
>> +
>> +/**
>> + * struct cdns_pcie_ep_data - hardware specific data
>> + * @max_regions: maximum nmuber of regions supported by hardware
>
> s/nmuber/number
>
>> + */
>> +struct cdns_pcie_ep_data {
>> + size_t max_regions;
>> +};
>> +
>> +/**
>> + * struct cdns_pcie_ep - private data for this PCIe endpoint controller driver
>> + * @pcie: Cadence PCIe controller
>> + * @data: pointer to a 'struct cdns_pcie_data'
>> + */
>> +struct cdns_pcie_ep {
>> + struct cdns_pcie pcie;
>> + const struct cdns_pcie_ep_data *data;
>> + struct pci_epc *epc;
>> + unsigned long ob_region_map;
>> + phys_addr_t *ob_addr;
>> + phys_addr_t irq_phys_addr;
>> + void __iomem *irq_cpu_addr;
>> + u64 irq_pci_addr;
>> + u8 irq_pending;
>> +};
>> +
>> +static int cdns_pcie_ep_write_header(struct pci_epc *epc,
>> + struct pci_epf_header *hdr)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u8 fn = 0;
>> +
>> + if (fn == 0) {
>
> I think there is some code to retrieve fn missing here.
hmm.. the endpoint core has to send the function number which right now it's
not doing though it has the function number info in pci_epf.
>
>> + u32 id = CDNS_PCIE_LM_ID_VENDOR(hdr->vendorid) |
>> + CDNS_PCIE_LM_ID_SUBSYS(hdr->subsys_vendor_id);
>> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_ID, id);
>> + }
>> + cdns_pcie_ep_fn_writew(pcie, fn, PCI_DEVICE_ID, hdr->deviceid);
>> + cdns_pcie_ep_fn_writeb(pcie, fn, PCI_REVISION_ID, hdr->revid);
>> + cdns_pcie_ep_fn_writeb(pcie, fn, PCI_CLASS_PROG, hdr->progif_code);
>> + cdns_pcie_ep_fn_writew(pcie, fn, PCI_CLASS_DEVICE,
>> + hdr->subclass_code | hdr->baseclass_code << 8);
>> + cdns_pcie_ep_fn_writeb(pcie, fn, PCI_CACHE_LINE_SIZE,
>> + hdr->cache_line_size);
>> + cdns_pcie_ep_fn_writew(pcie, fn, PCI_SUBSYSTEM_ID, hdr->subsys_id);
>> + cdns_pcie_ep_fn_writeb(pcie, fn, PCI_INTERRUPT_PIN, hdr->interrupt_pin);
>> +
>> + return 0;
>> +}
>> +
>> +static int cdns_pcie_ep_set_bar(struct pci_epc *epc, enum pci_barno bar,
>> + dma_addr_t bar_phys, size_t size, int flags)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u32 addr0, addr1, reg, cfg, b, aperture, ctrl;
>> + u8 fn = 0;
Here too endpoint core should send the function number..
>> + u64 sz;
>> +
>> + /* BAR size is 2^(aperture + 7) */
>> + sz = max_t(size_t, size, CDNS_PCIE_EP_MIN_APERTURE);
>> + sz = 1ULL << fls64(sz - 1);
>> + aperture = ilog2(sz) - 7; /* 128B -> 0, 256B -> 1, 512B -> 2, ... */
>> +
>> + if ((flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
>> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_IO_32BITS;
>> + } else {
>> + bool is_prefetch = !!(flags & PCI_BASE_ADDRESS_MEM_PREFETCH);
>> + bool is_64bits = sz > SZ_2G;
>> +
>> + if (is_64bits && (bar & 1))
>> + return -EINVAL;
>> +
>> + switch (is_64bits << 1 | is_prefetch) {
>
> I would not mind implementing this as a nested if-else, I am not a big
> fan of using bool this way.
>
>> + case 0:
>> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_32BITS;
>> + break;
>> +
>> + case 1:
>> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_32BITS;
>> + break;
>> +
>> + case 2:
>> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_MEM_64BITS;
>> + break;
>> +
>> + case 3:
>> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_PREFETCH_MEM_64BITS;
>> + break;
>> + }
>> + }
>> +
>> + addr0 = lower_32_bits(bar_phys);
>> + addr1 = upper_32_bits(bar_phys);
>> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR0(fn, bar),
>> + addr0);
It would be nice if you can have defines for CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR0
included in this patch rather than "PCI: cadence: Add host driver for Cadence
PCIe controller". All EP specific functions in header file should be included here.
>> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR1(fn, bar),
>> + addr1);
>
> Is fn always 0 ?
>
>> + if (bar < BAR_4) {
>> + reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG0(fn);
>> + b = bar;
>> + } else {
>> + reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG1(fn);
>> + b = bar - BAR_4;
>> + }
>> +
>> + cfg = cdns_pcie_readl(pcie, reg);
>> + cfg &= ~(CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE_MASK(b) |
>> + CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(b));
>> + cfg |= (CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE(b, aperture) |
>> + CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL(b, ctrl));
>> + cdns_pcie_writel(pcie, reg, cfg);
>> +
>> + return 0;
>> +}
>> +
>> +static void cdns_pcie_ep_clear_bar(struct pci_epc *epc, enum pci_barno bar)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u32 reg, cfg, b, ctrl;
>> + u8 fn = 0;
Here too endpoint core should send the function number..
>> +
>> + if (bar < BAR_4) {
>> + reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG0(fn);
>> + b = bar;
>> + } else {
>> + reg = CDNS_PCIE_LM_EP_FUNC_BAR_CFG1(fn);
>> + b = bar - BAR_4;
>> + }
>> +
>> + ctrl = CDNS_PCIE_LM_BAR_CFG_CTRL_DISABLED;
>> + cfg = cdns_pcie_readl(pcie, reg);
>> + cfg &= ~(CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_APERTURE_MASK(b) |
>> + CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(b));
>> + cfg |= CDNS_PCIE_LM_EP_FUNC_BAR_CFG_BAR_CTRL_MASK(ctrl);
>> + cdns_pcie_writel(pcie, reg, cfg);
>> +
>> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR0(fn, bar), 0);
>> + cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_EP_FUNC_BAR_ADDR1(fn, bar), 0);
>> +}
>> +
>> +static int cdns_pcie_ep_map_addr(struct pci_epc *epc, phys_addr_t addr,
>> + u64 pci_addr, size_t size)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u32 r;
>> +
>> + r = find_first_zero_bit(&ep->ob_region_map, sizeof(ep->ob_region_map));
>
> Second argument must be in bits not bytes.
>
> https://marc.info/?l=linux-pci&m=151179781225513&w=2
>
>> + if (r >= ep->data->max_regions - 1) {
>> + dev_err(&epc->dev, "no free outbound region\n");
>> + return -EINVAL;
>> + }
>> +
>> + cdns_pcie_set_outbound_region(pcie, r, false, addr, pci_addr, size);
>> +
>> + set_bit(r, &ep->ob_region_map);
>> + ep->ob_addr[r] = addr;
>> +
>> + return 0;
>> +}
>> +
>> +static void cdns_pcie_ep_unmap_addr(struct pci_epc *epc, phys_addr_t addr)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u32 r;
>> +
>> + for (r = 0; r < ep->data->max_regions - 1; r++)
>> + if (ep->ob_addr[r] == addr)
>> + break;
>> +
>> + if (r >= ep->data->max_regions - 1)
>
> == ?
>
>> + return;
>> +
>> + cdns_pcie_reset_outbound_region(pcie, r);
>> +
>> + ep->ob_addr[r] = 0;
>> + clear_bit(r, &ep->ob_region_map);
>> +}
>> +
>> +static int cdns_pcie_ep_set_msi(struct pci_epc *epc, u8 mmc)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
>> + u16 flags;
>> + u8 fn = 0;
>> +
>> + /* Validate the ID of the MSI Capability structure. */
>> + if (cdns_pcie_ep_fn_readb(pcie, fn, cap) != PCI_CAP_ID_MSI)
>> + return -EINVAL;
>> +
>> + /*
>> + * Set the Multiple Message Capable bitfield into the Message Control
>> + * register.
>> + */
>> + flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
>> + flags = (flags & ~PCI_MSI_FLAGS_QMASK) | (mmc << 1);
>> + flags |= PCI_MSI_FLAGS_64BIT;
>> + flags &= ~PCI_MSI_FLAGS_MASKBIT;
Any reason why "Per-vector masking capable" is reset?
>> + cdns_pcie_ep_fn_writew(pcie, fn, cap + PCI_MSI_FLAGS, flags);
>> +
>> + return 0;
>> +}
>> +
>> +static int cdns_pcie_ep_get_msi(struct pci_epc *epc)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
>> + u16 flags, mmc, mme;
>> + u8 fn = 0;
>> +
>> + /* Validate the ID of the MSI Capability structure. */
>> + if (cdns_pcie_ep_fn_readb(pcie, fn, cap) != PCI_CAP_ID_MSI)
>> + return -EINVAL;
>> +
>> + /* Validate that the MSI feature is actually enabled. */
>> + flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
>> + if (!(flags & PCI_MSI_FLAGS_ENABLE))
>> + return -EINVAL;
>> +
>> + /*
>> + * Get the Multiple Message Enable bitfield from the Message Control
>> + * register.
>> + */
>> + mmc = (flags & PCI_MSI_FLAGS_QMASK) >> 1;
>> + mme = (flags & PCI_MSI_FLAGS_QSIZE) >> 4;
>> + if (mme > mmc)
>> + mme = mmc;
>> + if (mme > 5)
>> + mme = 5;
I'm not sure if both these above checks are required..
>
> You should comment on what this 5 means and why it is fine to cap mme.
>
>> +
>> + return mme;
>> +}
>> +
>> +static void cdns_pcie_ep_assert_intx(struct cdns_pcie_ep *ep, u8 fn,
>> + u8 intx, bool is_asserted)
>> +{
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u32 r = ep->data->max_regions - 1;
>> + u32 offset;
>> + u16 status;
>> + u8 msg_code;
>> +
>> + intx &= 3;
>> +
>> + /* Set the outbound region if needed. */
>> + if (unlikely(ep->irq_pci_addr != CDNS_PCIE_EP_IRQ_PCI_ADDR_LEGACY)) {
>> + /* Last region was reserved for IRQ writes. */
>> + cdns_pcie_set_outbound_region_for_normal_msg(pcie, r,
>> + ep->irq_phys_addr);
>> + ep->irq_pci_addr = CDNS_PCIE_EP_IRQ_PCI_ADDR_LEGACY;
>> + }
>> +
>> + if (is_asserted) {
>> + ep->irq_pending |= BIT(intx);
>> + msg_code = MSG_CODE_ASSERT_INTA + intx;
>> + } else {
>> + ep->irq_pending &= ~BIT(intx);
>> + msg_code = MSG_CODE_DEASSERT_INTA + intx;
>> + }
>> +
>> + status = cdns_pcie_ep_fn_readw(pcie, fn, PCI_STATUS);
>> + if (((status & PCI_STATUS_INTERRUPT) != 0) ^ (ep->irq_pending != 0)) {
>> + status ^= PCI_STATUS_INTERRUPT;
>> + cdns_pcie_ep_fn_writew(pcie, fn, PCI_STATUS, status);
>> + }
here you are setting the PCI_STATUS_INTERRUPT even before sending the ASSERT
message.
>> +
>> + offset = CDNS_PCIE_NORMAL_MSG_ROUTING(MSG_ROUTING_LOCAL) |
>> + CDNS_PCIE_NORMAL_MSG_CODE(msg_code) |
>> + CDNS_PCIE_MSG_NO_DATA;
>> + writel(0, ep->irq_cpu_addr + offset);
>> +}
>> +
>> +static int cdns_pcie_ep_send_legacy_irq(struct cdns_pcie_ep *ep, u8 fn, u8 intx)
>> +{
>> + u16 cmd;
>> +
>> + cmd = cdns_pcie_ep_fn_readw(&ep->pcie, fn, PCI_COMMAND);
>> + if (cmd & PCI_COMMAND_INTX_DISABLE)
>> + return -EINVAL;
>> +
>> + cdns_pcie_ep_assert_intx(ep, fn, intx, true);
>> + mdelay(1);
>
> Add a comment please to explain the mdelay value.
>
>> + cdns_pcie_ep_assert_intx(ep, fn, intx, false);
>> + return 0;
>> +}
>> +
>> +static int cdns_pcie_ep_raise_irq(struct pci_epc *epc,
>> + enum pci_epc_irq_type type, u8 interrupt_num)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
>> + u16 flags, mmc, mme, data, data_mask;
>> + u8 msi_count;
>> + u64 pci_addr, pci_addr_mask = 0xff;
>> + u8 fn = 0;
>> +
>> + /* Handle legacy IRQ. */
>> + if (type == PCI_EPC_IRQ_LEGACY)
>> + return cdns_pcie_ep_send_legacy_irq(ep, fn, 0);
>> +
>> + /* Otherwise MSI. */
>> + if (type != PCI_EPC_IRQ_MSI)
>> + return -EINVAL;
MSI-X?
>> +
>> + /* Check whether the MSI feature has been enabled by the PCI host. */
>> + flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
>> + if (!(flags & PCI_MSI_FLAGS_ENABLE))
>> + return -EINVAL;
>> +
>> + /* Get the number of enabled MSIs */
>> + mmc = (flags & PCI_MSI_FLAGS_QMASK) >> 1;
>> + mme = (flags & PCI_MSI_FLAGS_QSIZE) >> 4;
>> + if (mme > mmc)
>> + mme = mmc;
>> + if (mme > 5)
>> + mme = 5;
>
> Same comment as above.
>
>> + msi_count = 1 << mme;
>> + if (!interrupt_num || interrupt_num > msi_count)
>> + return -EINVAL;
>> +
>> + /* Compute the data value to be written. */
>> + data_mask = msi_count - 1;
>> + data = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_DATA_64);
>> + data = (data & ~data_mask) | ((interrupt_num - 1) & data_mask);
>> +
>> + /* Get the PCI address where to write the data into. */
>> + pci_addr = cdns_pcie_ep_fn_readl(pcie, fn, cap + PCI_MSI_ADDRESS_HI);
>> + pci_addr <<= 32;
>> + pci_addr |= cdns_pcie_ep_fn_readl(pcie, fn, cap + PCI_MSI_ADDRESS_LO);
>> + pci_addr &= GENMASK_ULL(63, 2);
>> +
>> + /* Set the outbound region if needed. */
>> + if (unlikely(ep->irq_pci_addr != pci_addr)) {
>> + /* Last region was reserved for IRQ writes. */
>> + cdns_pcie_set_outbound_region(pcie, ep->data->max_regions - 1,
>> + false,
>> + ep->irq_phys_addr,
>> + pci_addr & ~pci_addr_mask,
>> + pci_addr_mask + 1);
>> + ep->irq_pci_addr = pci_addr;
>> + }
>> + writew(data, ep->irq_cpu_addr + (pci_addr & pci_addr_mask));
>> +
>> + return 0;
>> +}
>> +
>> +static int cdns_pcie_ep_start(struct pci_epc *epc)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + struct pci_epf *epf;
>> + u32 cfg;
>> + u8 fn = 0;
>> +
>> + /* Enable this endpoint function. */
>> + cfg = cdns_pcie_readl(pcie, CDNS_PCIE_LM_EP_FUNC_CFG);
>> + cfg |= BIT(fn);
>> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, cfg);
>> +
>> + /*
>> + * Already linked-up: don't call directly pci_epc_linkup() because we've
>> + * already locked the epc->lock.
>> + */
Not sure what you mean by linked-up here?
>> + list_for_each_entry(epf, &epc->pci_epf, list)
>> + pci_epf_linkup(epf);
>> +
>> + return 0;
>> +}
>> +
>> +static void cdns_pcie_ep_stop(struct pci_epc *epc)
>> +{
>> + struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> + struct cdns_pcie *pcie = &ep->pcie;
>> + u32 cfg;
>> + u8 fn = 0;
>> +
>> + /* Disable this endpoint function (function 0 can't be disabled). */
>
> I do not understand this comment and how it applies to the code,
> in other words fn is always 0 here (so it can't be disabled)
> I do not understand what this code is there for.
>
>> + cfg = cdns_pcie_readl(pcie, CDNS_PCIE_LM_EP_FUNC_CFG);
>> + cfg &= ~BIT(fn);
>> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, cfg);
>> +}
>> +
>> +static const struct pci_epc_ops cdns_pcie_epc_ops = {
>> + .write_header = cdns_pcie_ep_write_header,
>> + .set_bar = cdns_pcie_ep_set_bar,
>> + .clear_bar = cdns_pcie_ep_clear_bar,
>> + .map_addr = cdns_pcie_ep_map_addr,
>> + .unmap_addr = cdns_pcie_ep_unmap_addr,
>> + .set_msi = cdns_pcie_ep_set_msi,
>> + .get_msi = cdns_pcie_ep_get_msi,
>> + .raise_irq = cdns_pcie_ep_raise_irq,
>> + .start = cdns_pcie_ep_start,
>> + .stop = cdns_pcie_ep_stop,
>> +};
>> +
>> +static const struct cdns_pcie_ep_data cdns_pcie_ep_data = {
>> + .max_regions = 16,
>> +};
>
> As I mentioned in patch 3, should this be set-up with DT ?
>
> Thanks,
> Lorenzo
>
>> +
>> +static const struct of_device_id cdns_pcie_ep_of_match[] = {
>> + { .compatible = "cdns,cdns-pcie-ep",
>> + .data = &cdns_pcie_ep_data },
>> +
>> + { },
>> +};
>> +
>> +static int cdns_pcie_ep_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *np = dev->of_node;
>> + const struct of_device_id *of_id;
>> + struct cdns_pcie_ep *ep;
>> + struct cdns_pcie *pcie;
>> + struct pci_epc *epc;
>> + struct resource *res;
>> + size_t max_regions;
>> + int ret;
>> +
>> + ep = devm_kzalloc(dev, sizeof(*ep), GFP_KERNEL);
>> + if (!ep)
>> + return -ENOMEM;
>> +
>> + platform_set_drvdata(pdev, ep);
>> +
>> + pcie = &ep->pcie;
>> + pcie->is_rc = false;
>> +
>> + of_id = of_match_node(cdns_pcie_ep_of_match, np);
>> + ep->data = (const struct cdns_pcie_ep_data *)of_id->data;
>> +
>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg");
>> + pcie->reg_base = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(pcie->reg_base)) {
>> + dev_err(dev, "missing \"reg\"\n");
>> + return PTR_ERR(pcie->reg_base);
>> + }
>> +
>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mem");
>> + if (!res) {
>> + dev_err(dev, "missing \"mem\"\n");
>> + return -EINVAL;
>> + }
>> + pcie->mem_res = res;
>> +
>> + max_regions = ep->data->max_regions;
>> + ep->ob_addr = devm_kzalloc(dev, max_regions * sizeof(*ep->ob_addr),
>> + GFP_KERNEL);
>> + if (!ep->ob_addr)
>> + return -ENOMEM;
>> +
>> + pm_runtime_enable(dev);
>> + ret = pm_runtime_get_sync(dev);
>> + if (ret < 0) {
>> + dev_err(dev, "pm_runtime_get_sync() failed\n");
>> + goto err_get_sync;
>> + }
>> +
>> + /* Disable all but function 0 (anyway BIT(0) is hardwired to 1). */
>> + cdns_pcie_writel(pcie, CDNS_PCIE_LM_EP_FUNC_CFG, BIT(0));
why disable all functions?
>> +
>> + epc = devm_pci_epc_create(dev, &cdns_pcie_epc_ops);
>> + if (IS_ERR(epc)) {
>> + dev_err(dev, "failed to create epc device\n");
>> + ret = PTR_ERR(epc);
>> + goto err_init;
>> + }
>> +
>> + ep->epc = epc;
>> + epc_set_drvdata(epc, ep);
>> +
>> + ret = of_property_read_u8(np, "max-functions", &epc->max_functions);
>> + if (ret < 0)
>> + epc->max_functions = 1;
>> +
>> + ret = pci_epc_mem_init(epc, pcie->mem_res->start,
>> + resource_size(pcie->mem_res));
>> + if (ret < 0) {
>> + dev_err(dev, "failed to initialize the memory space\n");
>> + goto err_init;
>> + }
>> +
>> + ep->irq_cpu_addr = pci_epc_mem_alloc_addr(epc, &ep->irq_phys_addr,
>> + SZ_128K);
Any reason why you chose SZ_128K?
Thanks
Kishon
--
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] dt-bindings: ifc: Update endianness usage
From: Prabhakar Kushwaha @ 2017-12-05 9:15 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20171204204727.fnt4vsw2lg2q2w5x@rob-hp-laptop>
> -----Original Message-----
> From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Tuesday, December 05, 2017 2:17 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH][v3] dt-bindings: ifc: Update endianness usage
>
> On Thu, Nov 30, 2017 at 01:36:36PM +0530, Prabhakar Kushwaha wrote:
> > IFC controller version < 2.0 support IFC register access as
> > big endian. These controller version also require IFC NOR signals to
> > be connected in reverse order with NOR flash.
> >
> > IFC >= 2.0 is other way around.
> >
> > So updating IFC binding to take care of both using endianness field.
> >
> > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> > ---
> > Changes for v2: updated subject
> > Changes for v3: fixed typo for "big-endian"
> >
> > Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > index 89427b0..824a2ca 100644
> > --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > @@ -18,8 +18,10 @@ Properties:
> > interrupt (NAND_EVTER_STAT). If there is only one,
> > that interrupt reports both types of event.
> >
> > -- little-endian : If this property is absent, the big-endian mode will
> > - be in use as default for registers.
> > +- little-endian or big-endian : It represents how IFC registers to be accessed.
> > + It also represents connection between controller and
> > + NOR flash. If this property is absent, the big-endian
> > + mode will be in use as default.
>
> My question on the prior version remains. I think if you need to handle
> more than just register endianness, that should be done with the
> compatible string.
>
I may not able to use compatible string as this information will also be used it drivers/mtd/maps/physmap_of_core.c other than drivers/memory/fsl_ifc.c.
I am trying to avoid controller specific details in generic file.
This is the reason endianness property is being used.
--prabhakar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: orange-pi-zero-plus2: fix sdcard detect
From: Maxime Ripard @ 2017-12-05 9:15 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jagan Teki
In-Reply-To: <20171103195855.15283-2-geomatsi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Fri, Nov 03, 2017 at 10:58:54PM +0300, Sergey Matyukevich wrote:
> The sdcard detect pin on orange-pi-zero-plus2 is pulled up.
> Fix cd-gpio description to enable sdcard detect.
>
> Signed-off-by: Sergey Matyukevich <geomatsi-Re5JQEeQqe8AvxtiuMwx3w@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: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits
From: Geert Uytterhoeven @ 2017-12-05 9:09 UTC (permalink / raw)
To: Rob Herring
Cc: Ivo Sieben, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Chris Wright, Wolfram Sang,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdUDPFhSwkHg2wm7yCNAfdUP8wAR9OXxbcu6SDhtZqe2+A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
On Tue, Dec 5, 2017 at 9:57 AM, Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> On Mon, Dec 4, 2017 at 10:17 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Mon, Dec 04, 2017 at 10:17:47AM +0100, Geert Uytterhoeven wrote:
>>> On Thu, Nov 30, 2017 at 2:29 PM, Geert Uytterhoeven
>>> <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
>>> > Certain EEPROMS have a size that is larger than the number of address
>>> > bytes would allow, and store the MSB of the address in bit 3 of the
>>> > instruction byte.
>>> >
>>> > This can be described in platform data using EE_INSTR_BIT3_IS_ADDR, or
>>> > in DT using the obsolete legacy "at25,addr-mode" property.
>>> > But currently there exists no non-deprecated way to describe this in DT.
>>> >
>>> > Hence extend the existing "address-width" DT property to allow
>>> > specifying 9, 17, or 25 address bits, and enable support for that in the
>>> > driver.
>>> >
>>> > Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>>> > ---
>>> > EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040).
>>> > Do EEPROMs using 17 or 25 address bits, as mentioned in
>>> > include/linux/spi/eeprom.h, really exist?
>>> > Or should we just limit it to a single odd value (9 bits)?
>>>
>>> At least for the real Atmel parts, only the AT25040 part uses odd (8 +
>>> 1 bit) addressing.
>>
>> Seems like we should have a specific compatible for it.
>
> Possibly. But currently all configuration is done through DT properties, not
> through matching on compatible values.
Adding compatible values for all known/used parts could quickly become a
large table.
E.g. Atmel/Microchip has 3 variants of 512-byte EEPROMs: AT25040B,
25LC040A, and 25AA040A. The former uses an 8-byte pagesize, while the
latter parts use 16-byte pagesizes.
Not to mention "compatible" parts from other manufacturers, and all other
supported size.
Currently all of this is configured through the "pagesize", "size", and
"address-width" DT properties, with matching on generic "atmel,at25".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i: h3: enable USB OTG for NanoPi Neo board
From: Maxime Ripard @ 2017-12-05 9:07 UTC (permalink / raw)
To: Krzysztof Adamski
Cc: Rob Herring, Mark Rutland, Russell King, Chen-Yu Tsai,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171201224942.GA12473-JrLRIG1mnG582hYKe6nXyg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
Hi,
On Fri, Dec 01, 2017 at 11:49:42PM +0100, Krzysztof Adamski wrote:
> Similarly to Orange Pi Zero, NanoPi Neo board has an USB OTG port with
> an ID pin but with unpowered VBUS. This patch enables this port in
> forced peripheral mode.
>
> Signed-off-by: Krzysztof Adamski <k@japko.eu>
> ---
> arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
> index 78f6c24952dd..14c3f137dbd3 100644
> --- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
> @@ -53,3 +53,20 @@
> allwinner,leds-active-low;
> status = "okay";
> };
> +
> +&usb_otg {
> + status = "okay";
> + dr_mode = "peripheral";
> +};
> +
> +&usbphy {
> + usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
Please sort the nodes in alphabetical order.
Also, does it make sense to add the OHCI and EHCI controller for a
peripheral-only device?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] eeprom: at25: Add DT support for 25lc040
From: Geert Uytterhoeven @ 2017-12-05 9:04 UTC (permalink / raw)
To: Rob Herring
Cc: Geert Uytterhoeven, Arnd Bergmann, Greg Kroah-Hartman,
Mark Rutland, Ivo Sieben, Chris Wright, Wolfram Sang,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171204212215.f5dqiei6eqk6d7de@rob-hp-laptop>
Hi Rob,
On Mon, Dec 4, 2017 at 10:22 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Nov 30, 2017 at 02:29:43PM +0100, Geert Uytterhoeven wrote:
>> Some "atmel,at25" compatible SPI EEPROMs (e.g. Microchip 25lc040) use an
>> odd number of address bits. This patch series adds support for
>> instantiating such devices from DT.
>>
>> Do EEPROMs using 17 or 25 address bits, as mentioned in
>> include/linux/spi/eeprom.h, really exist?
>> Or should we just limit it to a single odd value (9 bits)?
>>
>> This has been tested with a bunch of 25lc040 EEPROMs.
>>
>> Thanks!
>>
>> Geert Uytterhoeven (3):
>> eeprom: at25: Add DT support for EEPROMs with odd address bits
>> dt-bindings: eeprom: at25: Grammar s/are can/can/
>> dt-bindings: eeprom: at25: Document device-specific compatible values
>
> 2 and 3 are fixes and I'll apply for 4.15 if you don't mind.
Thanks, I don't mind.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits
From: Geert Uytterhoeven @ 2017-12-05 8:59 UTC (permalink / raw)
To: Ivo Sieben
Cc: Arnd Bergmann, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
Chris Wright, Wolfram Sang, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAMSQXEFsooRytoJaZXwEvQnJQtFVMUtgaN2t2=Y1Jir=WNee1g@mail.gmail.com>
Hi Ivo,
On Mon, Dec 4, 2017 at 11:00 PM, Ivo Sieben <meltedpianoman@gmail.com> wrote:
> 2017-12-04 10:17 GMT+01:00 Geert Uytterhoeven <geert@linux-m68k.org>:
>>> EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040).
>>> Do EEPROMs using 17 or 25 address bits, as mentioned in
>>> include/linux/spi/eeprom.h, really exist?
>>> Or should we just limit it to a single odd value (9 bits)?
>>
>> At least for the real Atmel parts, only the AT25040 part uses odd (8 +
>> 1 bit) addressing.
>> AT25M01 uses 3-byte addressing (it needs 17 bits).
>>
>> So I tend to believe EEPROMs using 16 + 1 or 24 + 1 address bits (with the
>> extra bit in the instruction byte) do not exist?
>>
>
> I think you are right. Most likely this extra address bit option is
> only used for 9 bit addressable chips.
> I'm not an expert, but I know only the M95040 chip for which I
> originally wrote the patch.
> By then I decided to make it a bit broader (so also to be used as
> address 17 & 25 bit addressing) but that might
> not make any sense indeed.
>
>>> @@ -6,7 +6,9 @@ Required properties:
>>> - spi-max-frequency : max spi frequency to use
>>> - pagesize : size of the eeprom page
>>> - size : total eeprom size in bytes
>>> -- address-width : number of address bits (one of 8, 16, or 24)
>>> +- address-width : number of address bits (one of 8, 9, 16, 17, 24, or 25).
>>> + For odd values, the MSB of the address is sent as bit 3 of the instruction
>>> + byte, before the address byte(s).
>>
>> Alternatively, we can drop the binding change, i.e. keep on using
>> address-width = <8> for 512-byte '040...
>>
>
> As you also stated before: maybe it is more clear to leave only the
> "9" value option documented
> here, that looks to me the only valid use case for it.
OK.
>
>>> + if (val & 1) {
>>> + chip->flags |= EE_INSTR_BIT3_IS_ADDR;
>>> + val -= 1;
>>> + }
>>
>> ... and handle it here like:
>>
>> if (chip->byte_len == 2U << val)
>> chip->flags |= EE_INSTR_BIT3_IS_ADDR;
>>
>> However, that would IMHO be a bit confusing, as the "address-width"
>> property is no longer the real address width, but indicates how many bits
>> are specified in address bytes sent after the read/write command.
>> So "address-bytes" = 1, 2, or 3 would be more correct ;-)
>>
>> Or deprecate this whole "specify parameters using DT properties" business,
>> and derive them from the compatible value. But that would mean adding a
>> large and ever growing table to an old driver...
>>
>> Thoughts?
>
> I'm not a DT expert but to me your first proposal makes the most sense
> to me and feels the most intuitive:
> I would go for the address-with value 9 option here.
OK.
> Since we only expect value 9 to be a valid option, maybe you could
> rewrite it a bit to explicitly check for value 9:
>
> if (val == 9) {
> chip->flags |= EE_INSTR_BIT3_IS_ADDR;
> val -= 1;
> }
>
> I think this is slightly more readable.
Sure.
> Hope this helps,
Thanks!
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 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits
From: Geert Uytterhoeven @ 2017-12-05 8:57 UTC (permalink / raw)
To: Rob Herring
Cc: Ivo Sieben, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Chris Wright, Wolfram Sang, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20171204211705.543xjzvttbrt65pm@rob-hp-laptop>
Hi Rob,
On Mon, Dec 4, 2017 at 10:17 PM, Rob Herring <robh@kernel.org> wrote:
> On Mon, Dec 04, 2017 at 10:17:47AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Nov 30, 2017 at 2:29 PM, Geert Uytterhoeven
>> <geert+renesas@glider.be> wrote:
>> > Certain EEPROMS have a size that is larger than the number of address
>> > bytes would allow, and store the MSB of the address in bit 3 of the
>> > instruction byte.
>> >
>> > This can be described in platform data using EE_INSTR_BIT3_IS_ADDR, or
>> > in DT using the obsolete legacy "at25,addr-mode" property.
>> > But currently there exists no non-deprecated way to describe this in DT.
>> >
>> > Hence extend the existing "address-width" DT property to allow
>> > specifying 9, 17, or 25 address bits, and enable support for that in the
>> > driver.
>> >
>> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> > ---
>> > EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040).
>> > Do EEPROMs using 17 or 25 address bits, as mentioned in
>> > include/linux/spi/eeprom.h, really exist?
>> > Or should we just limit it to a single odd value (9 bits)?
>>
>> At least for the real Atmel parts, only the AT25040 part uses odd (8 +
>> 1 bit) addressing.
>
> Seems like we should have a specific compatible for it.
Possibly. But currently all configuration is done through DT properties, not
through matching on compatible values.
>> AT25M01 uses 3-byte addressing (it needs 17 bits).
>
> Do you need to know it is 17-bit vs. 24-bits? I'm guessing not as the
> unused bits are probably don't care.
The 17 bits can be derived from the EEPROM size in bytes (1 Mb = 128 KiB).
What is important to know is how to pass addresses to the device:
1. 3 address bytes, OR
2. 2 address bytes, and the odd MSB bit in the command byte.
But apparently the second scheme is not used for 17-bit addressing.
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 v4 00/10] add pinmuxing support for pins in AXP209 and AXP813 PMICs
From: Maxime Ripard @ 2017-12-05 8:55 UTC (permalink / raw)
To: Linus Walleij
Cc: Quentin Schulz, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Lee Jones, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux ARM,
Thomas Petazzoni, linux-sunxi
In-Reply-To: <CACRpkdaMxaLjsDETm6_56tyGDu6=W0L4SQCAA2mmSR4mkR-jAA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Sat, Dec 02, 2017 at 05:00:03PM +0100, Linus Walleij wrote:
> On Fri, Dec 1, 2017 at 2:44 PM, Quentin Schulz
> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > The AXP209 and AXP813 PMICs have several pins (respectively 3 and 2) that can
> > be used either as GPIOs or for other purposes (ADC or LDO here).
> >
> > We already have a GPIO driver for the GPIO use of those pins on the AXP209.
> > Let's "upgrade" this driver to support all the functions these pins can have.
> >
> > Then we add support to this driver for the AXP813 which is slighlty different
> > (basically a different offset in two registers and one less pin).
> >
> > I suggest patches 1 to 8 go through Linus's tree and 9 and 10 via Maxime or
> > Chen-Yu's tree.
> >
> > v4:
>
> Looks overall good. As soon as Maxime is happy with everything I will
> happily apply 1-8 to the pinctrl tree and then pull it to GPIO as well to
> avoid clashes.
>
> I think there were some minor comments but it seems almost finished.
You can apply everything with my
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The only comment left is the checkpatch warning, but there's multiple
occurences of that issue in the driver, so it can definitely be done
in a separate patch.
(But please do it Quentin ;))
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 02/10] pinctrl: axp209: add pinctrl features
From: Maxime Ripard @ 2017-12-05 8:53 UTC (permalink / raw)
To: Quentin Schulz
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <2207ddcb-21fc-e3e1-1a1c-11e11690a02e-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]
Hi,
On Mon, Dec 04, 2017 at 09:07:52AM +0100, Quentin Schulz wrote:
> >> +static int axp20x_pmx_set_mux(struct pinctrl_dev *pctldev,
> >> + unsigned int function, unsigned int group)
> >> +{
> >> + struct axp20x_gpio *gpio = pinctrl_dev_get_drvdata(pctldev);
> >> + unsigned int mask;
> >> +
> >> + /* Every pin supports GPIO_OUT and GPIO_IN functions */
> >> + if (function <= AXP20X_FUNC_GPIO_IN)
> >> + return axp20x_pmx_set(pctldev, group,
> >> + gpio->funcs[function].muxval);
> >> +
> >> + if (function == AXP20X_FUNC_LDO)
> >> + mask = gpio->desc->ldo_mask;
> >> + else
> >> + mask = gpio->desc->adc_mask;
> >
> > What is the point of this test...
> >
> >> + if (!(BIT(group) & mask))
> >> + return -EINVAL;
> >> +
> >> + /*
> >> + * We let the regulator framework handle the LDO muxing as muxing bits
> >> + * are basically also regulators on/off bits. It's better not to enforce
> >> + * any state of the regulator when selecting LDO mux so that we don't
> >> + * interfere with the regulator driver.
> >> + */
> >> + if (function == AXP20X_FUNC_LDO)
> >> + return 0;
> >
> > ... if you know that you're not going to do anything with one of the
> > outcomes. It would be better to just move that part above, instead of
> > doing the same test twice.
> >
>
> Return value is different. In one case, it is an error to request "ldo"
> for a pin that does not support it. In the other case, the ldo request
> is valid but nothing's done on driver side.
>
> Both cases are handled differently by the core:
> http://elixir.free-electrons.com/linux/latest/source/drivers/pinctrl/pinmux.c#L439
>
> I think that's the behavior we're expecting from this driver.
Ah, right.
> Or maybe you're asking to do:
>
> + if (function == AXP20X_FUNC_LDO) {
> + if (!(BIT(group) & gpio->desc->ldo_mask))
> + return -EINVAL;
> + return 0;
> + } else if (!(BIT(group) & gpio->desc->adc_mask)) {
> + return -EINVAL;
> + }
>
> ?
No, it's definitely better the way you did it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 0/3] pwm: meson-axg: add pwm controller driver
From: Thierry Reding @ 2017-12-05 8:52 UTC (permalink / raw)
To: Yixun Lan
Cc: Kevin Hilman, linux-pwm, linux-amlogic, Rob Herring, devicetree,
Neil Armstrong, Jerome Brunet, Mark Rutland, Carlo Caione,
Jian Hu, linux-arm-kernel, linux-kernel
In-Reply-To: <20171204060018.8856-1-yixun.lan@amlogic.com>
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
On Mon, Dec 04, 2017 at 02:00:15PM +0800, Yixun Lan wrote:
> This patch series try to add PWM controller driver for the
> Amlogic's Meson-AXG SoC. Update the Clock sources, pin DT.
>
> Jian Hu (3):
> dt-bindings: pwm: update bindings for the Meson-AXG
> pwm: meson: add clock source configuratin for Meson-AXG
Applied both of these, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Mathias Nyman @ 2017-12-05 8:48 UTC (permalink / raw)
To: Adam Wallis, Chunfeng Yun
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Matthias Brugger,
Mathias Nyman, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
timur-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <99ea0ee4-1fff-73df-d9b5-0f756dfc5635-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 05.12.2017 04:54, Adam Wallis wrote:
> On 12/4/2017 9:15 PM, Chunfeng Yun wrote:
>> On Mon, 2017-12-04 at 09:27 -0500, Adam Wallis wrote:
>>> The xHCI driver currently has the IMOD set to 160, which
>>> translates to an IMOD interval of 40,000ns (160 * 250)ns
>>>
>>> Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
>>> introduced a QUIRK for the MTK platform to adjust this interval to 20,
>>> which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
>>> due to the fact that the MTK controller IMOD interval is 8 times
>>> as much as defined in xHCI spec.
>>>
>>> Instead of adding more quirk bits for additional platforms, this patch
>>> introduces the ability for vendors to set the IMOD_INTERVAL as is
>>> optimal for their platform. By using device_property_read_u32() on
>>> "imod-interval-ns", the IMOD INTERVAL can be specified in nano seconds.
>>> If no interval is specified, the default of 40,000ns (IMOD=160) will be
>>> used.
>>>
>>> No bounds checking has been implemented due to the fact that a vendor
>>> may have violated the spec and would need to specify a value outside of
>>> the max 8,000 IRQs/second limit specified in the xHCI spec.
>>>
>>> Tested-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>> Signed-off-by: Adam Wallis <awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>> ---
>>> changes from v3:
>>> * Changed imod-interval to imod-interval-ns [Rob Herring/Chunfeng]
>>> * Changed "modulation" to "moderation" throughout patch [Mathias]
>>> changes from v2:
>>> * Added PCI default value [Mathias]
>>> * Removed xhci-mtk.h from xhci-plat.c [Chunfeng Yun]
>>> * Removed MTK quirk from xhci-plat and moved logic to xhci-mtk [Chunfeng]
>>> * Updated bindings Documentation to use proper units [Rob Herring]
>>> * Added imod-interval description and example to MTK binding documentation
>>> changes from v1:
>>> * Removed device_property_read_u32() per suggestion from greg k-h
>>> * Used ER_IRQ_INTERVAL_MASK in place of (u16) cast
>>>
>>> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 2 ++
>>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>>> drivers/usb/host/xhci-mtk.c | 9 +++++++++
>>> drivers/usb/host/xhci-pci.c | 3 +++
>>> drivers/usb/host/xhci-plat.c | 5 +++++
>>> drivers/usb/host/xhci.c | 7 ++-----
>>> drivers/usb/host/xhci.h | 2 ++
>>> 7 files changed, 24 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> index 3059596..9ff5602 100644
>>> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
>>> @@ -46,6 +46,7 @@ Optional properties:
>>> - pinctrl-names : a pinctrl state named "default" must be defined
>>> - pinctrl-0 : pin control group
>>> See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>>> + - imod-interval-ns: default interrupt moderation interval is 5000ns
>>>
>>> Example:
>>> usb30: usb@11270000 {
>>> @@ -66,6 +67,7 @@ usb30: usb@11270000 {
>>> usb3-lpm-capable;
>>> mediatek,syscon-wakeup = <&pericfg>;
>>> mediatek,wakeup-src = <1>;
>>> + imod-interval-ns = <10000>;
>>> };
>>>
>>> 2nd: dual-role mode with xHCI driver
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> index ae6e484..969908d 100644
>>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> @@ -29,6 +29,7 @@ Optional properties:
>>> - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
>>> - usb3-lpm-capable: determines if platform is USB3 LPM capable
>>> - quirk-broken-port-ped: set if the controller has broken port disable mechanism
>>> + - imod-interval-ns: default interrupt moderation interval is 5000ns
>>>
>>> Example:
>>> usb@f0931000 {
>>> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
>>> index b62a1d2..1cb2a8b 100644
>>> --- a/drivers/usb/host/xhci-mtk.c
>>> +++ b/drivers/usb/host/xhci-mtk.c
>>> @@ -674,6 +674,15 @@ static int xhci_mtk_probe(struct platform_device *pdev)
>>>
>>> xhci = hcd_to_xhci(hcd);
>>> xhci->main_hcd = hcd;
>>> +
>>> + /*
>>> + * imod_interval is the interrupt moderation value in nanoseconds.
>>> + * The increment interval is 8 times as much as that defined in
>>> + * the xHCI spec on MTK's controller.
>>> + */
>>> + xhci->imod_interval = 5000;
>>> + device_property_read_u32(dev, "imod-interval-ns", &xhci->imod_interval);
>>> +
>>> xhci->shared_hcd = usb_create_shared_hcd(driver, dev,
>>> dev_name(dev), hcd);
>>> if (!xhci->shared_hcd) {
>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>> index 7ef1274..4bcddd4 100644
>>> --- a/drivers/usb/host/xhci-pci.c
>>> +++ b/drivers/usb/host/xhci-pci.c
>>> @@ -234,6 +234,9 @@ static int xhci_pci_setup(struct usb_hcd *hcd)
>>> if (!xhci->sbrn)
>>> pci_read_config_byte(pdev, XHCI_SBRN_OFFSET, &xhci->sbrn);
>>>
>>> + /* imod_interval is the interrupt moderation value in nanoseconds. */
>>> + xhci->imod_interval = 40000;
>>> +
>>> retval = xhci_gen_setup(hcd, xhci_pci_quirks);
>>> if (retval)
>>> return retval;
>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>> index 09f164f..6f03830 100644
>>> --- a/drivers/usb/host/xhci-plat.c
>>> +++ b/drivers/usb/host/xhci-plat.c
>>> @@ -269,6 +269,11 @@ static int xhci_plat_probe(struct platform_device *pdev)
>>> if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
>>> xhci->quirks |= XHCI_BROKEN_PORT_PED;
>>>
>>> + /* imod_interval is the interrupt moderation value in nanoseconds. */
>>> + xhci->imod_interval = 40000;
>>> + device_property_read_u32(sysdev, "imod-interval-ns",
>>> + &xhci->imod_interval);
>>> +
>>> hcd->usb_phy = devm_usb_get_phy_by_phandle(sysdev, "usb-phy", 0);
>>> if (IS_ERR(hcd->usb_phy)) {
>>> ret = PTR_ERR(hcd->usb_phy);
>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>>> index 2424d30..0b7755b 100644
>>> --- a/drivers/usb/host/xhci.c
>>> +++ b/drivers/usb/host/xhci.c
>>> @@ -586,11 +586,8 @@ int xhci_run(struct usb_hcd *hcd)
>>> "// Set the interrupt modulation register");
>> s/modulation/moderation
>
> Mathias said there was no need to change the existing modulation strings - only
> the ones that I had added.
Baolu is working on a cleanup patch that removes debug messages that became
useless with debugfs and proper tracing support, including this line.
Less conflicts to resolve for me if we don't change this.
>
>>
>>> temp = readl(&xhci->ir_set->irq_control);
>>> temp &= ~ER_IRQ_INTERVAL_MASK;
>>> - /*
>>> - * the increment interval is 8 times as much as that defined
>>> - * in xHCI spec on MTK's controller
>>> - */
>>> - temp |= (u32) ((xhci->quirks & XHCI_MTK_HOST) ? 20 : 160);
>>> + temp |= (xhci->imod_interval / 250) & ER_IRQ_INTERVAL_MASK;
>>> +
>> No need a blank line
>
> If this patch goes through another version, I will remove this line
If Rob Acks this version I'll apply it and remove that blank line.
-Mathias
--
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] arm64: dts: a64-olinuxino: Enable RTL8723BS WiFi
From: Maxime Ripard @ 2017-12-05 8:34 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Icenowy Zheng, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki
In-Reply-To: <1512363187-8353-1-git-send-email-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
On Mon, Dec 04, 2017 at 10:23:06AM +0530, Jagan Teki wrote:
> Enable RTL8723BS WiFi chip on a64-olinuxino board:
> - WiFi SDIO interface is connected to MMC1
> - WiFi REG_ON pin connected to gpio PL2: attach to mmc-pwrseq
> - WiFi HOST_WAKE pin connected to gpio PL3
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3
From: Maxime Ripard @ 2017-12-05 8:33 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Icenowy Zheng, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki
In-Reply-To: <1512363187-8353-2-git-send-email-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
On Mon, Dec 04, 2017 at 10:23:07AM +0530, Jagan Teki wrote:
> Since current tree support AXP803 regulators,
> replace fixed regulator vcc3v3 with AXP803 dcdc1 regulator where ever
> it need to replace.
>
> Tested mmc0 on sopine baseboard.
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Queued as a fix, thanks
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: sunxi: Convert to CCU index macros for HDMI controller
From: Maxime Ripard @ 2017-12-05 8:27 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171204084401.2646-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
Hi,
On Mon, Dec 04, 2017 at 04:44:01PM +0800, Chen-Yu Tsai wrote:
> When the HDMI controller device node was added, the needed PLL clock
> macros were not exported. A separate patch addresses that, but it is
> merged through a different tree.
>
> Now that both patches are in mainline proper, we can convert the raw
> numbers to proper macros.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@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: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 6/8] mfd: axp20x: add battery power supply cell for AXP813
From: Lee Jones @ 2017-12-05 8:24 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA, icenowy-h8G6r0blFSE,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <9b5e9ed623165d0586f086343a7c67bc5c18bbb5.1512396054.git-series.quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, 04 Dec 2017, Quentin Schulz wrote:
> As axp20x-battery-power-supply now supports AXP813, add a cell for it.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> drivers/mfd/axp20x.c | 3 +++
> 1 file changed, 3 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH resend] arm: dts: ls1021a: Specify interrupt-affinity for pmu node
From: Rasmus Villemoes @ 2017-12-05 8:22 UTC (permalink / raw)
To: Shawn Guo, Rob Herring, Mark Rutland, Russell King
Cc: Esben Haabendal, Rasmus Villemoes,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1510672189-13306-1-git-send-email-rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
From: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
From: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
This avoids the warning
hw perfevents: no interrupt-affinity property for /pmu, guessing.
Signed-off-by: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
[RV: adapt commit log to the warning emitted in current mainline]
Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
---
arch/arm/boot/dts/ls1021a.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 02a266faec9b..96dc1a29fc64 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -106,6 +106,7 @@
compatible = "arm,cortex-a7-pmu";
interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
};
reboot {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH resend] arm: dts: ls1021a: Add label to USB controllers
From: Rasmus Villemoes @ 2017-12-05 8:16 UTC (permalink / raw)
To: Shawn Guo, Rob Herring, Mark Rutland, Russell King
Cc: Rasmus Villemoes, Esben Haabendal,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1510663184-19537-1-git-send-email-rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
From: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
Add usb2 and usb3 labels to USB2 and USB3 controller device tree nodes,
for easier modification in board dts files.
Signed-off-by: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
---
arch/arm/boot/dts/ls1021a.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 3ff2b8a9f01a..02a266faec9b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -675,7 +675,7 @@
};
};
- usb@8600000 {
+ usb2: usb@8600000 {
compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
reg = <0x0 0x8600000 0x0 0x1000>;
interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
@@ -683,7 +683,7 @@
phy_type = "ulpi";
};
- usb3@3100000 {
+ usb3: usb3@3100000 {
compatible = "snps,dwc3";
reg = <0x0 0x3100000 0x0 0x10000>;
interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 1/1] at24: support eeproms that do not auto-rollover reads.
From: Bartosz Golaszewski @ 2017-12-05 8:14 UTC (permalink / raw)
To: Sakari Ailus
Cc: Sven Van Asbroeck, Sven Van Asbroeck, Rob Herring, Mark Rutland,
Wolfram Sang, nsekhar, David Lechner, javier, divagar.mohandass,
devicetree, linux-kernel, linux-i2c, Sven Van Asbroeck
In-Reply-To: <20171205074451.gpsidrxlwyfo2fu7@paasikivi.fi.intel.com>
2017-12-05 8:44 GMT+01:00 Sakari Ailus <sakari.ailus@linux.intel.com>:
> On Mon, Dec 04, 2017 at 05:24:33PM -0500, Sven Van Asbroeck wrote:
>> > If this is truly specific to at24, then vendor prefix would be appropriate,
>> > plus it'd go to an at24 specific binding file. However if it isn't I'd just
>> > remove the above sentence. I guess the latter?
>>
>> Yes, no-read-rollover is truly specific to at24.c, because it applies only
>> to i2c multi-address chips. The at25 is spi based so cannot have multiple
>> addresses.
>>
>> So yes, "at24,no-read-rollover" would perhaps be a better name.
>>
>> Regarding an at24 specific binding file. You're saying I should create
>> Documentation/devicetree/bindings/eeprom/at24.txt ? Should I indicate
>> that at24.txt "inherits from" eeprom.txt? Note that at25.txt does not
>> currently do this.
>
> Hmm. I actually missed we didn't have one to begin with. at25.txt exists
> and it documents a number of properties specific to at25, so if at24 will
> have an at24-specific property, then I think it should go to a separate
> file.
The eeprom.txt file in the bindings directory actually describes the
bindings for at24. There's a patch[1] from Wolfram waiting for Rob's
ack that renames it to at24.txt. I hope that clears any confusion.
@Sven: please split the patch into two: one for bindings and one for code.
As for the name: I would change it to at24,no-read-rollover and remove
the fragment saying it's only supported in at24 - as I said: this file
only concerns at24 and will be renamed.
>
> Aren't there really other chips which need this? It'd be (a little bit)
> easier to just remove the sentence. :-)
>
> --
> Regards,
>
> Sakari Ailus
> sakari.ailus@linux.intel.com
Thanks,
Bartosz
[1] http://patchwork.ozlabs.org/patch/842500/
^ permalink raw reply
* [PATCH resend] arm: dts: ls1021a: add reboot node to .dtsi
From: Rasmus Villemoes @ 2017-12-05 8:12 UTC (permalink / raw)
To: Shawn Guo, Rob Herring, Mark Rutland, Russell King
Cc: Rasmus Villemoes, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1510566980-26602-1-git-send-email-rasmus.villemoes@prevas.dk>
The LS1021A can be reset via the dcfg regmap in the same way as the
arm64 layerscape SoCs, so add the corresponding DT node.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
arch/arm/boot/dts/ls1021a.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 9319e1f0f1d8..3ff2b8a9f01a 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -108,6 +108,13 @@
<GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
};
+ reboot {
+ compatible = "syscon-reboot";
+ regmap = <&dcfg>;
+ offset = <0xb0>;
+ mask = <0x02>;
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox