Re: [PATCH v7,1/3] dt-bindings: binding for jz4780-{nand,bch}

[Boris Brezillon]

Hi Harvey,

On Tue, 6 Oct 2015 17:27:15 +0100
Harvey Hunt  wrote:

> From: Alex Smith 
> 
> Add DT bindings for NAND devices connected to the NEMC on JZ4780 SoCs,
> as well as the hardware BCH controller, used by the jz4780_{nand,bch}
> drivers.

Patch 3 does not seem to follow this binding: it still uses the
ingenic,ecc-xxx properties and defines NAND timings.

Also, as answered to patch 3, I think it would be clearer to separate
the nand controller and nand chip representation.

Best Regards,

Boris

> 
> Signed-off-by: Alex Smith 
> Cc: Zubair Lutfullah Kakakhel 
> Cc: David Woodhouse 
> Cc: Brian Norris 
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: Alex Smith 
> Signed-off-by: Harvey Hunt 
> ---
> v6 -> v7:
>  - Add nand-ecc-mode to DT bindings.
>  - Add nand-on-flash-bbt to DT bindings.
> 
> v5 -> v6:
>  - No change.
> 
> v4 -> v5:
>  - Rename ingenic,bch-device to ingenic,bch-controller to fit with
>existing convention.
> 
> v3 -> v4:
>  - No change
> 
> v2 -> v3:
>  - Rebase to 4.0-rc6
>  - Changed ingenic,ecc-size to common nand-ecc-step-size
>  - Changed ingenic,ecc-strength to common nand-ecc-strength
>  - Changed ingenic,busy-gpio to common rb-gpios
>  - Changed ingenic,wp-gpio to common wp-gpios
> 
> v1 -> v2:
>  - Rebase to 4.0-rc3
> 
>  .../bindings/mtd/ingenic,jz4780-nand.txt   | 61 
> ++
>  1 file changed, 61 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> 
> diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt 
> b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> new file mode 100644
> index 000..44a0468
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> @@ -0,0 +1,61 @@
> +* Ingenic JZ4780 NAND/BCH
> +
> +This file documents the device tree bindings for NAND flash devices on the
> +JZ4780. NAND devices are connected to the NEMC controller (described in
> +memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND device nodes must
> +be children of the NEMC node.
> +
> +Required NAND device properties:
> +- compatible: Should be set to "ingenic,jz4780-nand".
> +- reg: For each bank with a NAND chip attached, should specify a bank number,
> +  an offset of 0 and a size of 0x100 (i.e. the whole NEMC bank).
> +
> +Optional NAND device properties:
> +- ingenic,bch-controller: To make use of the hardware BCH controller, this
> +  property must contain a phandle for the BCH controller node. The required
> +  properties for this node are described below. If this is not specified,
> +  software BCH will be used instead.
> +- nand-ecc-step-size: ECC block size in bytes.
> +- nand-ecc-strength: ECC strength (max number of correctable bits).
> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. "hw" by default
> +- nand-on-flash-bbt: boolean to enable on flash bbt option if not present 
> false
> +- rb-gpios: GPIO specifier for the busy pin.
> +- wp-gpios: GPIO specifier for the write protect pin.
> +
> +Example:
> +
> +nemc: nemc@1341 {
> + ...
> +
> + nand: nand@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>;  /* Bank 1 */
> +
> + ingenic,bch-controller = <&bch>;
> + nand-ecc-step-size = <1024>;
> + nand-ecc-strength = <24>;
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + rb-gpios = <&gpa 20 GPIO_ACTIVE_LOW>;
> + wp-gpios = <&gpf 22 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +The BCH controller is a separate SoC component used for error correction on
> +NAND devices. The following is a description of the device properties for a
> +BCH controller.
> +
> +Required BCH properties:
> +- compatible: Should be set to "ingenic,jz4780-bch".
> +- reg: Should specify the BCH controller registers location and length.
> +- clocks: Clock for the BCH controller.
> +
> +Example:
> +
> +bch: bch@134d {
> + compatible = "ingenic,jz4780-bch";
> + reg = <0x134d 0x1>;
> +
> + clocks = <&cgu JZ4780_CLK_BCH>;
> +};



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

> > Without #ifdefs if we compile driver for legacy, MSI structures will not be
> available and we get compile time error.
> 
> Sorry for nitpicking but at least can we use elegant version of #ifdefs .i.e. 
> #if
> IS_ENABLED() here ?
> 
Since IS_ENABLED() is checked at runtime, compile time error would come for 
legacy.

Thanks
Bharat

Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

[Boris Brezillon]

Paul, Harvey,

On Fri, 16 Oct 2015 11:48:48 +0100
Paul Burton  wrote:

> On Fri, Oct 16, 2015 at 11:31:12AM +0100, James Hogan wrote:
> > > >> +
> > > >> +&nemc {
> > > >> + status = "okay";
> > > >> +
> > > >> + nand: nand@1 {
> > > >> + compatible = "ingenic,jz4780-nand";
> > > >
> > > > Isn't the NAND a micron part? This doesn't seem right. Is the device
> > > > driver and binding already accepted upstream with that compatible
> > > > string?
> > > 
> > > This is the compatible string for the JZ4780 NAND driver, this patch
> > > is part of the series adding that. Detection of the NAND part is
> > > handled by the MTD subsystem.
> > 
> > Right (didn't spot that it was part of a series).
> > 
> > The node appears to describe the NAND interface itself, i.e. a part of
> > the SoC, so should be in the SoC dtsi file, with overrides in the board
> > file if necessary for it to work with a particular NAND part
> > (potentially utilising status="disabled"). Would you agree?
> 
> Hi James,
> 
> The "nemc" node there is for the Nand & External Memory Controller which
> is a hardware block inside the SoC. It has 6 banks (ie. 6 chip select
> pins, each associated with a different address range, that connect to
> different devices). NAND flash is one such possible device, but a board
> could connect it to any of the 6 chip selects, or banks. To represent
> that in the SoC dtsi you'd want to have 6 NAND nodes, each disabled by
> default, which doesn't make a whole lot of sense to me. Other, non-NAND
> devices can connect to the NEMC too - for example the ethernet
> controller on the CI20 is connected to one bank.
> 
> The NAND device nodes are sort of a mix of describing the NAND flash
> (ie. Micron part as you point out) and its connections & properties, the
> way the NEMC should be used to interact with it alongside the BCH block,
> and the configuration for the NEMC such as timing parameters.
> 
> I imagine the most semantically correct means of describing it would
> probably be for the compatible string to reflect the Micron NAND part,
> and the NEMC driver to pick up on the relevant properties of its child
> nodes for configuring timings, whether the device is NAND etc. However
> the handling of registering NAND devices with MTD would probably then
> have to be part of the NEMC driver, which feels a bit off too.

Another solution would be to describe both the NAND controller and the
NAND chip in the DT (with the NAND chip being a chip of the NAND
controller).
Actually this is already what other binding are doing [1][2]. I know
those bindings are representing NAND controllers which can interface
with more than one NAND chip, but I think that even in the 1:1 case it
would make it clearer to represent both the NAND chip and the NAND
controller.

In your case this would give the following representation

+&nemc {
+   status = "okay";
+
+   nandc: nand-controller@1 {
+   compatible = "ingenic,jz4780-nand";
+   reg = <1 0 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ingenic,bch-controller = <&bch>;
+
+   nand@0 {
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   nand-ecc-size = <1024>;
+   nand-ecc-strength = <24>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   partition@0 {
+   label = "u-boot-spl";
+   reg = <0x0 0x0 0x0 0x80>;
+   };
+   /* ... */
+
+   };
+   };
+};

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt#L119
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt#L28

> 
> Thanks,
> Paul
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Amit Tomer]

> Without #ifdefs if we compile driver for legacy, MSI structures will not be 
> available and we get compile time error.

Sorry for nitpicking but at least can we use elegant version of
#ifdefs .i.e. #if IS_ENABLED() here ?

Thanks,
Amit.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

[Krzysztof Kozlowski]

On 03.11.2015 18:16, Pavel Fedin wrote:
> This patch extends Exynos SROM controller driver with ability to configure
> controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
> which is connected via SROMc bank #3.
> 
> With this patchset, support for the whole existing SMDK range can be added.
> Actually, only bank number is different.
> 
> This patchset also depends on Exynos 5410 pinctrl support, introduced by
> patches 0003 and 0004 from this set:
> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html

Only the first patch made up to kernel. The rest (2-5) received feedback
and I am waiting for fixing it. Andreas apparently loose the interest...

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation: dt: Add bindings for Secure-only devices

[Frank Rowand]

On 10/30/2015 1:07 PM, Peter Maydell wrote:
> On 30 October 2015 at 18:28, Rob Herring  wrote:
>> On Thu, Oct 29, 2015 at 9:01 AM, Peter Maydell  
>> wrote:
>>> +Valid Secure world properties:
>>> +
>>> +- secure-status : specifies whether the device is present and usable
>>> +  in the secure world. The combination of this with "status" allows
>>> +  the various possible combinations of device visibility to be
>>> +  specified:
>>> +   status = "okay"; // visible in S and NS
>>
>> I assume neither property present or both okay also mean the same.
>>
>> status = "okay"; secure-status = "okay";
>>
>> We should be explicit.
> 
> Yes; status defaults to "okay" (presumably this is listed in
> the overal DT binding spec somewhere), 

Valid values for the "status" property do not seem to be well documented
for Linux.

The code, __of_device_is_available(), implements:

  value of "okay"  returns true
  value of "ok"returns true
  status property does not exist returns true (thus defaults to true)

  anything else returns false.

Eight individual bindings define the status property (I'll put them
on my todo list to remove since they should be inherited).  The status
property should be in a top level binding, which should be created as
part of the bindings documentation cleanup.  I'll watch for it to get
created or do it myself.

(Lots of bindings show examples of using the status property in their
examples -- that is fine.)

ePAPR v1.1, section "2.3.4 status" does not list "ok", but does list:
  "okay"
  "disabled"
  "fail"
  "fail-sss"


< snip >

-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] drivers/gpio: Port gpio driver to layerscape platform

[Liu Gang]

Layerscape has the same ip block/controller as
GPIO on powerpc platform(MPC8XXX).

So use portable i/o accessors, as in_be32/out_be32
accessors are Power architecture specific whereas
ioread32/iowrite32 and ioread32be/iowrite32be are
available in other architectures.

Layerscape GPIO controller's registers may be big
or little endian, so the code needs to get the
endian property from DTB, then make additional
functions to fit right register read/write
operations.

Currently the code can support ls2080a GPIO with
little endian registers. And it can also work well
on other layerscape platform with big endian GPIO
registers.

Signed-off-by: Liu Gang 
Signed-off-by: Shaveta Leekha 

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8949b3f..c3ca283 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -290,12 +290,12 @@ config GPIO_MPC5200
depends on PPC_MPC52xx
 
 config GPIO_MPC8XXX
-   bool "MPC512x/MPC8xxx GPIO support"
+   bool "MPC512x/MPC8xxx/QorIQ GPIO support"
depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || \
-  FSL_SOC_BOOKE || PPC_86xx
+  FSL_SOC_BOOKE || PPC_86xx || ARCH_LAYERSCAPE
help
  Say Y here if you're going to use hardware that connects to the
- MPC512x/831x/834x/837x/8572/8610 GPIOs.
+ MPC512x/831x/834x/837x/8572/8610/QorIQ GPIOs.
 
 config GPIO_MSM_V2
tristate "Qualcomm MSM GPIO v2"
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 48ef368..eb7a1ca 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -1,5 +1,5 @@
 /*
- * GPIOs on MPC512x/8349/8572/8610 and compatible
+ * GPIOs on MPC512x/8349/8572/8610/QorIQ and compatible
  *
  * Copyright (C) 2008 Peter Korsgaard 
  *
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MPC8XXX_GPIO_PINS  32
 
@@ -44,6 +45,27 @@ struct mpc8xxx_gpio_chip {
const void *of_dev_id_data;
 };
 
+static bool gpio_little_endian;
+static inline u32 gpio_in32(void __iomem *addr)
+{
+   u32 val;
+
+   if (gpio_little_endian)
+   val = ioread32(addr);
+   else
+   val = ioread32be(addr);
+
+   return val;
+}
+
+static inline void gpio_out32(u32 val, void __iomem *addr)
+{
+   if (gpio_little_endian)
+   iowrite32(val, addr);
+   else
+   iowrite32be(val, addr);
+}
+
 static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
 {
return 1u << (MPC8XXX_GPIO_PINS - 1 - gpio);
@@ -59,9 +81,17 @@ static void mpc8xxx_gpio_save_regs(struct of_mm_gpio_chip 
*mm)
 {
struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
 
-   mpc8xxx_gc->data = in_be32(mm->regs + GPIO_DAT);
+   mpc8xxx_gc->data = gpio_in32(mm->regs + GPIO_DAT);
 }
 
+/* Generic set and clear bits accessor ports */
+#define bgpio_setbits32(_addr, _v) \
+   gpio_out32(gpio_in32(_addr) |  (_v), (_addr))
+#define bgpio_clrbits32(_addr, _v) \
+   gpio_out32(gpio_in32(_addr) & ~(_v), (_addr))
+#define bgpio_clrsetbits32(addr, clear, set) \
+   gpio_out32((gpio_in32(addr) & ~(clear)) | (set), (addr))
+
 /* Workaround GPIO 1 errata on MPC8572/MPC8536. The status of GPIOs
  * defined as output cannot be determined by reading GPDAT register,
  * so we use shadow data register instead. The status of input pins
@@ -74,9 +104,9 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned 
int gpio)
struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
u32 out_mask, out_shadow;
 
-   out_mask = in_be32(mm->regs + GPIO_DIR);
+   out_mask = gpio_in32(mm->regs + GPIO_DIR);
 
-   val = in_be32(mm->regs + GPIO_DAT) & ~out_mask;
+   val = gpio_in32(mm->regs + GPIO_DAT) & ~out_mask;
out_shadow = mpc8xxx_gc->data & out_mask;
 
return (val | out_shadow) & mpc8xxx_gpio2mask(gpio);
@@ -86,7 +116,7 @@ static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned 
int gpio)
 {
struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
 
-   return in_be32(mm->regs + GPIO_DAT) & mpc8xxx_gpio2mask(gpio);
+   return gpio_in32(mm->regs + GPIO_DAT) & mpc8xxx_gpio2mask(gpio);
 }
 
 static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
@@ -102,7 +132,7 @@ static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned 
int gpio, int val)
else
mpc8xxx_gc->data &= ~mpc8xxx_gpio2mask(gpio);
 
-   out_be32(mm->regs + GPIO_DAT, mpc8xxx_gc->data);
+   gpio_out32(mpc8xxx_gc->data, mm->regs + GPIO_DAT);
 
raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
 }
@@ -128,7 +158,7 @@ static void mpc8xxx_gpio_set_multiple(struct gpio_chip *gc,
}
}
 
-   out_be32(mm->regs + GPIO_DAT, mpc8xxx_gc->data);
+   gpio_out32(mpc8xxx_gc->data, mm->regs + GPIO_DAT);
 
raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
 }
@@ -141,7 +171,7 @

[PATCH 1/2] ls2080a/dts: Add little endian property for GPIO IP block

[Liu Gang]

The GPIO block for ls2080a platform has little endian registers,
the GPIO driver needs this property to read/write registers by
right interface.

Signed-off-by: Liu Gang 

diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt 
b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
index f2455c5..c836dab 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
@@ -10,6 +10,9 @@ Required properties:
   the second cell is used to specify the gpio polarity:
   0 = active high
   1 = active low
+- little-endian : Should be set if the GPIO has little endian
+ registers. No the property means the GPIO
+ registers are big endian mode.
 
 Example:
 
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index f3c59f9..41bb8c1 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -277,6 +277,7 @@
reg = <0x0 0x230 0x0 0x1>;
interrupts = <0 36 0x4>; /* Level high type */
gpio-controller;
+   little-endian;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
@@ -287,6 +288,7 @@
reg = <0x0 0x231 0x0 0x1>;
interrupts = <0 36 0x4>; /* Level high type */
gpio-controller;
+   little-endian;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
@@ -297,6 +299,7 @@
reg = <0x0 0x232 0x0 0x1>;
interrupts = <0 37 0x4>; /* Level high type */
gpio-controller;
+   little-endian;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
@@ -307,6 +310,7 @@
reg = <0x0 0x233 0x0 0x1>;
interrupts = <0 37 0x4>; /* Level high type */
gpio-controller;
+   little-endian;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

> > +static struct msi_domain_info nwl_msi_domain_info = {
> > +   .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> MSI_FLAG_USE_DEF_CHIP_OPS |
> > + MSI_FLAG_MULTI_PCI_MSI),
> 
> If you're supporting multi-MSI, how do you ensure that all hwirqs are
> contiguous as required by the spec? Clearly, your allocator doesn't provide
> this guarantee.
> 
Oh ok, then how can we know if one EP is requesting for multiple irq's, because 
in pci_enable_msi_range,
 it does do while loop according to msi_capability_init return value 
which in turn requests for multiple irq's. Is there any way to find out when 
single EP requesting for multiple MSI?

> Also, you still lack support for MSI-X (which would come for free...).

We don't support MSI-X in root port mode.
> 
> > +   .chip = &nwl_msi_irq_chip,
> > +};
> > +#endif
> > +
> > +   irq_domain_remove(pcie->legacy_irq_domain);
> > +
> > +#ifdef CONFIG_PCI_MSI
> > +   irq_set_chained_handler_and_data(msi->irq_msi0, NULL, NULL);
> > +   irq_set_chained_handler_and_data(msi->irq_msi1, NULL, NULL);
> > +
> > +   irq_domain_remove(msi->msi_domain);
> > +   irq_domain_remove(msi->dev_domain);
> > +#endif
> > +
> > +}
> 
> Remove these #ifdefs. You can test the validity of these fields before calling
> the various functions. You can also move this to a separate function.

Without #ifdefs if we compile driver for legacy, MSI structures will not be 
available and we get compile time error.
> 
> > +
> > +   /* setup AFI/FPCI range */
> > +   msi->pages = __get_free_pages(GFP_KERNEL, 0);
> > +   base = virt_to_phys((void *)msi->pages);
> > +   nwl_bridge_writel(pcie, lower_32_bits(base), I_MSII_BASE_LO);
> > +   nwl_bridge_writel(pcie, upper_32_bits(base), I_MSII_BASE_HI);
> 
> I just read this, and I'm puzzled. Actually, puzzled is an understatement. Why
> on Earth do you need to give RAM to your MSI HW?
> This should be a device, not RAM. By the look of it, this could be absolutely
> anything. Are you sure you have to supply RAM here?
> 
This is required in our hardware, so that bridge identifies incoming MWr as MSI.
> > +
> > +   /* Disable high range msi interrupts */
> > +   nwl_bridge_writel(pcie, (u32)~MSGF_MSI_SR_HI_MASK,
> > +MSGF_MSI_MASK_HI);
> > +
> > +

Bharat
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[Zain]

Hi LABBE,

On 2015年11月03日 16:59, LABBE Corentin wrote:
> On Tue, Nov 03, 2015 at 01:52:05PM +0800, Zain Wang wrote:
>> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher
>> mode.
>> The names registered are:
>> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
>> You can alloc tags above in your case.
>>
>> And other algorithms and platforms will be added later on.
>>
>> Signed-off-by: Zain Wang 
>> ---
>>  drivers/crypto/Kconfig |  11 +
>>  drivers/crypto/Makefile|   1 +
>>  drivers/crypto/rockchip/Makefile   |   3 +
>>  drivers/crypto/rockchip/rk3288_crypto.c| 383 
>>  drivers/crypto/rockchip/rk3288_crypto.h| 290 
>>  drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 501 
>> +
>>  6 files changed, 1189 insertions(+)
>>  create mode 100644 drivers/crypto/rockchip/Makefile
>>  create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
>>  create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
>>  create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
>>
>> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
>> index 2569e04..d1e42cf 100644
>> --- a/drivers/crypto/Kconfig
>> +++ b/drivers/crypto/Kconfig
>> @@ -498,4 +498,15 @@ config CRYPTO_DEV_SUN4I_SS
>>To compile this driver as a module, choose M here: the module
>>will be called sun4i-ss.
>>  
>> +config CRYPTO_DEV_ROCKCHIP
>> +tristate "Rockchip's Cryptographic Engine driver"
>> +
>> +select CRYPTO_AES
>> +select CRYPTO_DES
>> +select CRYPTO_BLKCIPHER
>> +
>> +help
>> +  This driver interfaces with the hardware crypto accelerator.
>> +  Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
>> +
>>  endif # CRYPTO_HW
>> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
>> index c3ced6f..713de9d 100644
>> --- a/drivers/crypto/Makefile
>> +++ b/drivers/crypto/Makefile
>> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>>  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>>  obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>>  obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
>> +obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
>> diff --git a/drivers/crypto/rockchip/Makefile 
>> b/drivers/crypto/rockchip/Makefile
>> new file mode 100644
>> index 000..7051c6c
>> --- /dev/null
>> +++ b/drivers/crypto/rockchip/Makefile
>> @@ -0,0 +1,3 @@
>> +obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o
>> +rk_crypto-objs := rk3288_crypto.o \
>> +  rk3288_crypto_ablkcipher.o \
>> diff --git a/drivers/crypto/rockchip/rk3288_crypto.c 
>> b/drivers/crypto/rockchip/rk3288_crypto.c
>> new file mode 100644
>> index 000..02830f2
>> --- /dev/null
>> +++ b/drivers/crypto/rockchip/rk3288_crypto.c
>> @@ -0,0 +1,383 @@
>> +/*
>> + *Crypto acceleration support for Rockchip RK3288
>> + *
>> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
>> + *
>> + * Author: Zain Wang 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * Some ideas are from marvell-cesa.c and s5p-sss.c driver.
>> + */
>> +
>> +#include "rk3288_crypto.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct crypto_info_t *crypto_p;
>> +
>> +static int rk_crypto_enable_clk(struct crypto_info_t *dev)
>> +{
>> +int err;
>> +
>> +err = clk_prepare_enable(dev->sclk);
>> +if (err) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'sclk'\n",
>> +__func__, __LINE__);
>> +goto err_return;
>> +}
>> +err = clk_prepare_enable(dev->aclk);
>> +if (err) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
>> +__func__, __LINE__);
>> +goto err_aclk;
>> +}
>> +err = clk_prepare_enable(dev->hclk);
>> +if (err) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
>> +__func__, __LINE__);
>> +goto err_hclk;
>> +}
>> +
>> +err = clk_prepare_enable(dev->dmaclk);
>> +if (err) {
>> +dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'dmaclk'\n",
>> +__func__, __LINE__);
>> +goto err_dmaclk;
>> +}
>> +return err;
>> +err_dmaclk:
>> +clk_disable_unprepare(dev->hclk);
>> +err_hclk:
>> +clk_disable_unprepare(dev->aclk);
>> +err_aclk:
>> +clk_disable_unprepare(dev->sclk);
>> +err_return:
>> +return err;
>> +}
>> +
>> +static void rk_crypto_disable_clk(struct crypto_info_t *dev)
>> +{
>> +clk_disable_unprepare(dev->dmaclk);
>> +clk_disable_unprepare(dev->hclk);
>> +

Re: [PATCH v2 1/5] spi: introduce mmap read support for spi flash devices

[Vignesh R]

Hi,

On 11/03/2015 04:49 PM, Michal Suchanek wrote:
> On 3 November 2015 at 11:06, Vignesh R  wrote:
>> In addition to providing direct access to SPI bus, some spi controller
>> hardwares (like ti-qspi) provide special memory mapped port
>> to accesses SPI flash devices in order to increase read performance.
>> This means the controller can automatically send the SPI signals
>> required to read data from the SPI flash device.
>> For this, spi controller needs to know flash specific information like
>> read command to use, dummy bytes and address width. Once these settings
>> are populated in hardware registers, any read accesses to flash's memory
>> map region(SoC specific) through memcpy (or mem-to mem DMA copy) will be
>> handled by controller hardware. The hardware will automatically generate
>> SPI signals required to read data from flash and present it to CPU/DMA.
>>
>> Introduce spi_mtd_mmap_read() interface to support memory mapped read
>> over SPI flash devices. SPI master drivers can implement this callback to
>> support memory mapped read interfaces. m25p80 flash driver and other
>> flash drivers can call this to request memory mapped read. The interface
>> should only be used MTD flashes and cannot be used with other SPI devices.
>>
>> Signed-off-by: Vignesh R 
>> ---
>>  drivers/spi/spi.c   | 35 +++
>>  include/linux/spi/spi.h | 23 +++
>>  2 files changed, 58 insertions(+)
>>
>> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
>> index a5f53de813d3..5a5c7a7d47f2 100644
>> --- a/drivers/spi/spi.c
>> +++ b/drivers/spi/spi.c
>> @@ -1059,6 +1059,7 @@ static void __spi_pump_messages(struct spi_master 
>> *master, bool in_kthread)
>> }
>> }
>>
>> +   mutex_lock(&master->mmap_lock_mutex);
>> trace_spi_message_start(master->cur_msg);
>>
>> if (master->prepare_message) {
>> @@ -1068,6 +1069,7 @@ static void __spi_pump_messages(struct spi_master 
>> *master, bool in_kthread)
>> "failed to prepare message: %d\n", ret);
>> master->cur_msg->status = ret;
>> spi_finalize_current_message(master);
>> +   mutex_unlock(&master->mmap_lock_mutex);
>> return;
>> }
>> master->cur_msg_prepared = true;
>> @@ -1077,6 +1079,7 @@ static void __spi_pump_messages(struct spi_master 
>> *master, bool in_kthread)
>> if (ret) {
>> master->cur_msg->status = ret;
>> spi_finalize_current_message(master);
>> +   mutex_unlock(&master->mmap_lock_mutex);
>> return;
>> }
>>
>> @@ -1084,8 +1087,10 @@ static void __spi_pump_messages(struct spi_master 
>> *master, bool in_kthread)
>> if (ret) {
>> dev_err(&master->dev,
>> "failed to transfer one message from queue\n");
>> +   mutex_unlock(&master->mmap_lock_mutex);
>> return;
>> }
>> +   mutex_unlock(&master->mmap_lock_mutex);
>>  }
>>
>>  /**
>> @@ -1732,6 +1737,7 @@ int spi_register_master(struct spi_master *master)
>> spin_lock_init(&master->queue_lock);
>> spin_lock_init(&master->bus_lock_spinlock);
>> mutex_init(&master->bus_lock_mutex);
>> +   mutex_init(&master->mmap_lock_mutex);
>> master->bus_lock_flag = 0;
>> init_completion(&master->xfer_completion);
>> if (!master->max_dma_len)
>> @@ -2237,6 +2243,35 @@ int spi_async_locked(struct spi_device *spi, struct 
>> spi_message *message)
>>  EXPORT_SYMBOL_GPL(spi_async_locked);
>>
>>
>> +int spi_mtd_mmap_read(struct spi_device *spi, loff_t from, size_t len,
>> + size_t *retlen, u_char *buf, u8 read_opcode,
>> + u8 addr_width, u8 dummy_bytes)
>> +
>> +{
>> +   struct spi_master *master = spi->master;
>> +   int ret;
>> +
>> +   if (master->auto_runtime_pm) {
>> +   ret = pm_runtime_get_sync(master->dev.parent);
>> +   if (ret < 0) {
>> +   dev_err(&master->dev, "Failed to power device: %d\n",
>> +   ret);
>> +   goto err;
>> +   }
>> +   }
>> +   mutex_lock(&master->mmap_lock_mutex);
>> +   ret = master->spi_mtd_mmap_read(spi, from, len, retlen, buf,
>> +   read_opcode, addr_width,
>> +   dummy_bytes);
>> +   mutex_unlock(&master->mmap_lock_mutex);
>> +   if (master->auto_runtime_pm)
>> +   pm_runtime_put(master->dev.parent);
>> +
>> +err:
>> +   return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(spi_mtd_mmap_read);
>> +
>>  
>> /*-*/
>>
>>  /* Utility methods for SPI master protocol drivers, layered on
>> diff --git a/include/linux/spi/spi.h b/includ

Re: [PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY

[Brian Norris]

Hi Yakir,

On Wed, Nov 04, 2015 at 08:48:38AM +0800, Yakir Yang wrote:
> On 11/03/2015 12:38 PM, Brian Norris wrote:
> >On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> >(FYI, I came across this by inspection when comparing Heiko's
> >'somewhat-stable' branch [1] with this series. The former brings up eDP
> >fine on veyron-jaq, whereas this one doesn't yet, even with the above
> >change. Still debugging the issue.)
> 
> Hmm... I'm not sure whether your eDP screen have the hotplug signal, so I

I believe hotplug is hooked up but...

> think you can try to add "analogix,force-hpd" flag into
> rk3288-veyron-jaq.dts
> 
> &edp {
> analogix,need-force-hpd;
> }

...already tried, just in case. No luck.

> If that changes couldn't fix the problem, guess you may need max the panel
> power up delay time which pointed by Heiko. Like:
> 
> Thanks,
> - Yakir
> 
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 4fa5f69..546a506 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -82,6 +82,13 @@ static int analogix_dp_detect_hpd(struct
> analogix_dp_device *dp)
>  */
> dev_dbg(dp->dev, "failed to get hpd plug status, try to
> force hpd\n");
> 
> +   /*
> +* Hotplug signal would indicate the right time to operate
> +* panel after poweron, but if the hotplug is missing, then
> +* panel would need wait hundreds of milliseconds at here.
> +*/
> +   mdelay(100);
> +
> analogix_dp_force_hpd(dp);
> 
> if (analogix_dp_get_plug_in_status(dp) != 0) {

I'll give that a try. Per Heiko's suggestion, I've already hacked around
with adding delays in the regulator node, but this could give slightly
different behavior. I doubt it'll help, but I'll let you know if it
does.

Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

On 11/3/2015 7:42 AM, Arnd Bergmann wrote:

You have a distinct "compatible" string for qemu, right? It sounds like
this is not the same device if the dependencies are different, and
you could just have two ways to probe the same device.

No, it is the same dma channel object that gets probed by the same name 
like the hypervisor. The channel object gets unbound from the 
hypervisor, it then gets bound to VFIO. Then, eventually QEMU takes 
over. The channel driver does not know under which OS it is running and 
it works in both environments as it is without any code changes at this 
moment.



The split between the two drivers still feels a little awkward overall,
it might be good to give it some more thought.


I see. I'd like to keep the management driver as independent as possible 
from the channel driver for security and functionality reasons. I need 
to keep the management addresses and functionality in the hypervisor only.



> Would it work to describe the combination of the channel and management
registers as a single device with a single driver, but the management
parts being optional? That way, the management registers could be
intergrated better into the dmaengine framework, to provide a consistent
API to user space.


I can compile both management driver and channel driver into the same 
module if it sounds better. I can probe one with channel and another 
with the management name. I just need to be careful about not sharing 
any kind of data structure between them otherwise virtualization will break.


I consider the management driver a client of the DMA engine API at this 
moment.


--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

Hi Brain,

On 11/03/2015 12:38 PM, Brian Norris wrote:

Hi Yakir,

On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:

Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.

Reviewed-by: Heiko Stuebner
Signed-off-by: Yakir Yang
---

...

diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..f3e0058
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(4)
+#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)

Why are the above two macros the same? Judging by the RK3288 manual and
other downstream drivers, it seems like you want the _MASK one to be
shifted left by 16 (i.e., BIT(20)).


Oops, yes, you're right, it should be BIT(20), thanks for the catch.


+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
+

...


+   ret = regmap_write(dp->grf, GRF_SOC_CON12, GRF_EDP_REF_CLK_SEL_INTER |
+  GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK);

IOW, the above is writing:

BIT(4) | BIT(4)

whereas I think you want:

BIT(4) | BIT(20)


+   if (ret != 0) {
+   dev_err(dp->dev, "Could not config GRF edp ref clk: %d\n", ret);
+   return ret;
+   }
+

...

(FYI, I came across this by inspection when comparing Heiko's
'somewhat-stable' branch [1] with this series. The former brings up eDP
fine on veyron-jaq, whereas this one doesn't yet, even with the above
change. Still debugging the issue.)


Hmm... I'm not sure whether your eDP screen have the hotplug signal, so I
think you can try to add "analogix,force-hpd" flag into 
rk3288-veyron-jaq.dts


&edp {
analogix,need-force-hpd;
}


If that changes couldn't fix the problem, guess you may need max the panel
power up delay time which pointed by Heiko. Like:

Thanks,
- Yakir


diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c

index 4fa5f69..546a506 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -82,6 +82,13 @@ static int analogix_dp_detect_hpd(struct 
analogix_dp_device *dp)

 */
dev_dbg(dp->dev, "failed to get hpd plug status, try to force 
hpd\n");


+   /*
+* Hotplug signal would indicate the right time to operate
+* panel after poweron, but if the hotplug is missing, then
+* panel would need wait hundreds of milliseconds at here.
+*/
+   mdelay(100);
+
analogix_dp_force_hpd(dp);

if (analogix_dp_get_plug_in_status(dp) != 0) {



Brian

[1]https://github.com/mmind/linux-rockchip/tree/devel/somewhat-stable






--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

On 11/3/2015 5:22 AM, Andy Shevchenko wrote:

On Mon, Nov 2, 2015 at 8:07 AM, Sinan Kaya  wrote:

The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design. The management
driver is executed in hypervisor context and is the main
management entity for all channels provided by the device.
The channel driver is executed in the hypervisor/guest OS
context.

All channel devices get probed in the hypervisor
context during power up. They show up as DMA engine
channels. Then, before starting the virtualization; each
channel device is unbound from the hypervisor by VFIO
and assigned to the guest machine for control.

This management driver will be used by the system
admin to monitor/reset the execution state of the DMA
channels. This will be the management interface.




+static ssize_t qcom_hidma_mgmt_evtena(struct file *file,
+   const char __user *user_buf, size_t count, loff_t *ppos)
+{
+   char temp_buf[16+1];


16 is a magic number. Make it defined constant.



removed it


+   struct qcom_hidma_mgmt_dev *mgmtdev = file->f_inode->i_private;
+   u32 event;
+   ssize_t ret;
+   unsigned long val;
+
+   temp_buf[16] = '\0';
+   if (copy_from_user(temp_buf, user_buf, min_t(int, count, 16)))
+   goto out;
+
+   ret = kstrtoul(temp_buf, 16, &val);


kstrtoul_from_user?


nice, simpler.




+   if (ret) {
+   dev_warn(&mgmtdev->pdev->dev, "unknown event\n");
+   goto out;
+   }
+
+   event = (u32)val & HW_EVENTS_CFG_MASK;
+
+   pm_runtime_get_sync(&mgmtdev->pdev->dev);
+   writel(event, mgmtdev->dev_virtaddr + HW_EVENTS_CFG_OFFSET);
+   pm_runtime_mark_last_busy(&mgmtdev->pdev->dev);
+   pm_runtime_put_autosuspend(&mgmtdev->pdev->dev);
+out:
+   return count;
+}
+
+static const struct file_operations qcom_hidma_mgmt_evtena_fops = {
+   .write = qcom_hidma_mgmt_evtena,
+};
+
+struct fileinfo {
+   char *name;
+   int mode;
+   const struct file_operations *ops;
+};
+
+static struct fileinfo files[] = {
+   {"info", S_IRUGO, &qcom_hidma_mgmt_fops},
+   {"err", S_IRUGO,  &qcom_hidma_mgmt_err_fops},
+   {"mhiderrclr", S_IWUSR, &qcom_hidma_mgmt_mhiderr_clrfops},
+   {"evterrclr", S_IWUSR, &qcom_hidma_mgmt_evterr_clrfops},
+   {"ideerrclr", S_IWUSR, &qcom_hidma_mgmt_ideerr_clrfops},
+   {"odeerrclr", S_IWUSR, &qcom_hidma_mgmt_odeerr_clrfops},
+   {"msierrclr", S_IWUSR, &qcom_hidma_mgmt_msierr_clrfops},
+   {"treerrclr", S_IWUSR, &qcom_hidma_mgmt_treerr_clrfops},
+   {"evtena", S_IWUSR, &qcom_hidma_mgmt_evtena_fops},
+};
+
+static void qcom_hidma_mgmt_debug_uninit(struct qcom_hidma_mgmt_dev *mgmtdev)
+{
+   debugfs_remove_recursive(mgmtdev->debugfs);
+}
+
+static int qcom_hidma_mgmt_debug_init(struct qcom_hidma_mgmt_dev *mgmtdev)
+{
+   int rc = 0;
+   u32 i;
+   struct dentry   *fs_entry;
+
+   mgmtdev->debugfs = debugfs_create_dir(dev_name(&mgmtdev->pdev->dev),
+   NULL);
+   if (!mgmtdev->debugfs) {
+   rc = -ENODEV;
+   return rc;
+   }
+
+   for (i = 0; i < ARRAY_SIZE(files); i++) {
+   fs_entry = debugfs_create_file(files[i].name,
+   files[i].mode, mgmtdev->debugfs,
+   mgmtdev, files[i].ops);
+   if (!fs_entry) {
+   rc = -ENOMEM;
+   goto cleanup;
+   }
+   }
+
+   return 0;
+cleanup:
+   qcom_hidma_mgmt_debug_uninit(mgmtdev);
+   return rc;
+}
+#else
+static void qcom_hidma_mgmt_debug_uninit(struct qcom_hidma_mgmt_dev *mgmtdev)
+{
+}
+static int qcom_hidma_mgmt_debug_init(struct qcom_hidma_mgmt_dev *mgmtdev)
+{
+   return 0;
+}
+#endif
+
+static int qcom_hidma_mgmt_setup(struct qcom_hidma_mgmt_dev *mgmtdev)
+{
+   u32 val;
+   u32 i;
+
+   val = readl(mgmtdev->dev_virtaddr + MAX_BUS_REQ_LEN_OFFSET);
+   val = val &
+   ~(MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS);
+   val = val |
+   (mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS);
+   val = val & ~(MAX_BUS_REQ_LEN_MASK);
+   val = val | (mgmtdev->max_read_request);
+   writel(val, mgmtdev->dev_virtaddr + MAX_BUS_REQ_LEN_OFFSET);
+
+   val = readl(mgmtdev->dev_virtaddr + MAX_XACTIONS_OFFSET);
+   val = val &
+   ~(MAX_WR_XACTIONS_MASK << MAX_WR_XACTIONS_BIT_POS);
+   val = val |
+   (mgmtdev->max_wr_xactions << MAX_WR_XACTIONS_BIT_POS);
+   val = val & ~(MAX_RD_XACTIONS_MASK);
+   val = val | (mgmtdev->max_rd_xactions);
+   writel(val, mgmtdev->dev_virtaddr + MAX_XACTIONS_OFFSET);
+
+   mgmtdev->sw_version = readl(mgmtdev->dev_virtaddr + SW_VERSION_OFFSET);
+
+   for (i = 0; i < mgmtdev->dma_channels; i++) {
+   

Re: [PATCH V2 3/3] dma: add Qualcomm Technologies HIDMA channel driver

[Sinan Kaya]

On 11/3/2015 5:10 AM, Andy Shevchenko wrote:

On Mon, Nov 2, 2015 at 8:07 AM, Sinan Kaya  wrote:

This patch adds support for hidma engine. The driver
consists of two logical blocks. The DMA engine interface
and the low-level interface. The hardware only supports
memcpy/memset and this driver only support memcpy
interface. HW and driver doesn't support slave interface.



+/* Linux Foundation elects GPLv2 license only.
+ */


One line?

ok




+#include 
+#include 
+#include 


Do you need this one explicitly?


got rid of it




+#include 
+#include 


+ empty line?

ok



+#include 


+ empty line?

ok



+#include "dmaengine.h"
+#include "qcom_hidma.h"
+
+/* Default idle time is 2 seconds. This parameter can
+ * be overridden by changing the following
+ * /sys/bus/platform/devices/QCOM8061:/power/autosuspend_delay_ms
+ * during kernel boot.
+ */



ok


Block comments usually like
/*
  * text
  */




+struct hidma_chan {
+   boolpaused;
+   boolallocated;
+   charname[16];


So, do you need specific name? There is already one in struct dma_chan.

OK, removed.


+/* process completed descriptors */
+static void hidma_process_completed(struct hidma_dev *mdma)
+{
+   dma_cookie_t last_cookie = 0;
+   struct hidma_chan *mchan;
+   struct hidma_desc *mdesc;
+   struct dma_async_tx_descriptor *desc;
+   unsigned long irqflags;
+   LIST_HEAD(list);
+   struct dma_chan *dmach = NULL;
+
+   list_for_each_entry(dmach, &mdma->ddev.channels,
+   device_node) {
+   mchan = to_hidma_chan(dmach);
+
Found a bug here now. I should have initialized the list on each 
iteration of the loop.



+   /* Get all completed descriptors */
+   spin_lock_irqsave(&mchan->lock, irqflags);
+   if (!list_empty(&mchan->completed))


Removed this one.


+   list_splice_tail_init(&mchan->completed, &list);
+   spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+   if (list_empty(&list))
+   continue;





Redundant check. It's done in both list_for_each_entry() and
list_splice_tail_init().


ok



+
+   /* Execute callbacks and run dependencies */
+   list_for_each_entry(mdesc, &list, node) {
+   desc = &mdesc->desc;
+
+   spin_lock_irqsave(&mchan->lock, irqflags);
+   dma_cookie_complete(desc);
+   spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+   if (desc->callback &&
+   (hidma_ll_status(mdma->lldev, mdesc->tre_ch)
+   == DMA_COMPLETE))
+   desc->callback(desc->callback_param);
+
+   last_cookie = desc->cookie;
+   dma_run_dependencies(desc);
+   }
+
+   /* Free descriptors */
+   spin_lock_irqsave(&mchan->lock, irqflags);
+   list_splice_tail_init(&list, &mchan->free);
+   spin_unlock_irqrestore(&mchan->lock, irqflags);
+   }
+}
+
+/*
+ * Execute all queued DMA descriptors.
+ * This function is called either on the first transfer attempt in tx_submit
+ * or from the callback routine when one transfer is finished. It can only be
+ * called from a single location since both of places check active list to be
+ * empty and will immediately fill the active list while lock is held.
+ *
+ * Following requirements must be met while calling hidma_execute():
+ * a) mchan->lock is locked,
+ * b) mchan->active list contains multiple entries.
+ * c) pm protected
+ */
+static int hidma_execute(struct hidma_chan *mchan)
+{
+   struct hidma_dev *mdma = mchan->dmadev;
+   int rc;
+
+   if (!hidma_ll_isenabled(mdma->lldev))
+   return -ENODEV;
+
+   /* Start the transfer */
+   if (!list_empty(&mchan->active))
+   rc = hidma_ll_start(mdma->lldev);
+
+   return 0;
+}
+
+/*
+ * Called once for each submitted descriptor.
+ * PM is locked once for each descriptor that is currently
+ * in execution.
+ */
+static void hidma_callback(void *data)
+{
+   struct hidma_desc *mdesc = data;
+   struct hidma_chan *mchan = to_hidma_chan(mdesc->desc.chan);
+   unsigned long irqflags;
+   struct dma_device *ddev = mchan->chan.device;
+   struct hidma_dev *dmadev = to_hidma_dev(ddev);
+   bool queued = false;
+
+   dev_dbg(dmadev->ddev.dev, "callback: data:0x%p\n", data);
+
+   spin_lock_irqsave(&mchan->lock, irqflags);
+
+   if (mdesc->node.next) {
+   /* Delete from the active list, add to completed list */
+   list_move_tail(&mdesc->node, &mchan->completed);
+   queued = true;
+   }
+   spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+   hidma_process_com

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Dmitry Torokhov]

On Tue, Nov 03, 2015 at 05:11:56PM -0600, Michael Welling wrote:
> On Tue, Nov 03, 2015 at 02:59:13PM -0800, Dmitry Torokhov wrote:
> > On Tue, Nov 03, 2015 at 09:41:17AM -0600, Michael Welling wrote:
> > > On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> > > > On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
> > > >  wrote:
> > > > > On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> > > > >> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > > > >> > > +Required properties:
> > > > >> > > + - compatible: "ti,tsc2004"
> > > > >> > > + - interrupts: IRQ specifier
> > > > >> > > + - vio-supply : Regulator specifier
> > > > >> >
> > > > >> > reg property?
> > > > >>
> > > > >> Rob,
> > > > >>
> > > > >> It appears that I missed this in the description.
> > > > >>
> > > > >> Probably because I was following the lead of the ts2005 description.
> > > > >>
> > > > >> How does this look:
> > > > >> - reg : I2C address. 0x48 - 0x4b based on the 
> > > > >> voltage applied to
> > > > >> the AD1 and AD0 inputs on the IC.
> > > > >>
> > > > >
> > > > > How about the version below?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > --
> > > > > Dmitry
> > > > >
> > > > >
> > > > > Input: tsc2004 - document ts2004 dt bindings
> > > 
> > > Just noticed that it says ts2004 instead of tsc2004 in the subject.
> > > Otherwise, I am fine with it.
> > > 
> > > Thanks for the assistance.
> > > 
> > > Still no acks or reviews for the other patches in the series.
> > > I would like for someone to test the tsc2005 support to see if it still 
> > > works.
> > > 
> > > The tsc2004 works very well on the target that I have here.
> > 
> > I folded this patch into the patch #3 and applied everything.
> >
> 
> Great.
> 
> Will this patch series conflict with the patch series to take out the 
> .owner=THIS_MODULE
> from spi_drivers?
> 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1004626.html

If he tries to get them in one pass - probably, but the conflicts should
be trivial and should be easily resolved by SPI maintainer and/or Linus.

Or he could split the patch per-subsystem.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 38/42] drivers/of: Unflatten subordinate nodes after specified level

[Gavin Shan]

On Thu, Aug 06, 2015 at 02:11:43PM +1000, Gavin Shan wrote:
>unflatten_dt_node() is called recursively to unflatten FDT nodes
>with the assumption that FDT blob has only one root node, which
>isn't true when the FDT blob represents device sub-tree. This
>improves the function to supporting device sub-tree that have
>multiple nodes in the first level:
>
>   * Rename original unflatten_dt_node() to __unflatten_dt_node().
>   * Wrapper unflatten_dt_node() calls __unflatten_dt_node() with
> adjusted current node depth to 1 to avoid underflow.
>
>Signed-off-by: Gavin Shan 
>---
> drivers/of/fdt.c | 53 -
> 1 file changed, 40 insertions(+), 13 deletions(-)
>
>diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>index 0749656..a18a2ce 100644
>--- a/drivers/of/fdt.c
>+++ b/drivers/of/fdt.c
>@@ -161,7 +161,7 @@ static void *unflatten_dt_alloc(void **mem, unsigned long 
>size,
> }
>
> /**
>- * unflatten_dt_node - Alloc and populate a device_node from the flat tree
>+ * __unflatten_dt_node - Alloc and populate a device_node from the flat tree
>  * @blob: The parent device tree blob
>  * @mem: Memory chunk to use for allocating device nodes and properties
>  * @poffset: pointer to node in flat tree
>@@ -171,20 +171,20 @@ static void *unflatten_dt_alloc(void **mem, unsigned 
>long size,
>  * @dryrun: If true, do not allocate device nodes but still calculate needed
>  * memory size
>  */
>-static void * unflatten_dt_node(const void *blob,
>+static void *__unflatten_dt_node(const void *blob,
>   void *mem,
>   int *poffset,
>   struct device_node *dad,
>   struct device_node **nodepp,
>   unsigned long fpsize,
>-  bool dryrun)
>+  bool dryrun,
>+  int *depth)
> {
>   const __be32 *p;
>   struct device_node *np;
>   struct property *pp, **prev_pp = NULL;
>   const char *pathp;
>   unsigned int l, allocl;
>-  static int depth = 0;
>   int old_depth;
>   int offset;
>   int has_name = 0;
>@@ -337,13 +337,25 @@ static void * unflatten_dt_node(const void *blob,
>   np->type = "";
>   }
>
>-  old_depth = depth;
>-  *poffset = fdt_next_node(blob, *poffset, &depth);
>-  if (depth < 0)
>-  depth = 0;
>-  while (*poffset > 0 && depth > old_depth)
>-  mem = unflatten_dt_node(blob, mem, poffset, np, NULL,
>-  fpsize, dryrun);
>+  /* Multiple nodes might be in the first depth level if
>+   * the device tree is sub-tree. All nodes in current
>+   * or deeper depth are unflattened after it returns.
>+   */
>+  old_depth = *depth;
>+  *poffset = fdt_next_node(blob, *poffset, depth);
>+  while (*poffset > 0) {
>+  if (*depth < old_depth)
>+  break;
>+
>+  if (*depth == old_depth)
>+  mem = __unflatten_dt_node(blob, mem, poffset,
>+dad, NULL, fpsize,
>+dryrun, depth);
>+  else if (*depth > old_depth)
>+  mem = __unflatten_dt_node(blob, mem, poffset,
>+np, NULL, fpsize,
>+dryrun, depth);
>+  }
>

Sorry for the delay. I'm afraid this one has to be reworked. With current
code and changes, the nodes in the FDT blob are scanned in recursive fasion.
That would cause exhausted stack when this function is called at early stage
of system boot to unflatten the device tree that have too much levels and nodes.
In next revision, I'll rework it to avoid recursive calls on this function.

So there're more time needed to post next revision. This issue was observed in
recent testing with 4.3.rc6 and the patchset. On P7 box, the bad stack is 
reported
directly. On P8 box, the /bin/init in the initram image can't be started 
properly.
I run "git bisect" and this patch is located in both case.

>   if (*poffset < 0 && *poffset != -FDT_ERR_NOTFOUND)
>   pr_err("unflatten: error %d processing FDT\n", *poffset);
>@@ -369,6 +381,20 @@ static void * unflatten_dt_node(const void *blob,
>   return mem;
> }
>
>+static void *unflatten_dt_node(const void *blob,
>+ void *mem,
>+ int *poffset,
>+ struct device_node *dad,
>+ struct device_node **nodepp,
>+ bool dryrun)
>+{
>+  int depth = 1;
>+
>+  return __unflatten_dt_node(blob, mem, poffset,
>+ dad, nodepp, 0,
>+ dryrun, &depth);
>+}
>+
> /**
>  * __unflatten_device_tree -

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

On Tue, Nov 03, 2015 at 02:59:13PM -0800, Dmitry Torokhov wrote:
> On Tue, Nov 03, 2015 at 09:41:17AM -0600, Michael Welling wrote:
> > On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> > > On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
> > >  wrote:
> > > > On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> > > >> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > > >> > > +Required properties:
> > > >> > > + - compatible: "ti,tsc2004"
> > > >> > > + - interrupts: IRQ specifier
> > > >> > > + - vio-supply : Regulator specifier
> > > >> >
> > > >> > reg property?
> > > >>
> > > >> Rob,
> > > >>
> > > >> It appears that I missed this in the description.
> > > >>
> > > >> Probably because I was following the lead of the ts2005 description.
> > > >>
> > > >> How does this look:
> > > >> - reg : I2C address. 0x48 - 0x4b based on the voltage 
> > > >> applied to
> > > >> the AD1 and AD0 inputs on the IC.
> > > >>
> > > >
> > > > How about the version below?
> > > >
> > > > Thanks.
> > > >
> > > > --
> > > > Dmitry
> > > >
> > > >
> > > > Input: tsc2004 - document ts2004 dt bindings
> > 
> > Just noticed that it says ts2004 instead of tsc2004 in the subject.
> > Otherwise, I am fine with it.
> > 
> > Thanks for the assistance.
> > 
> > Still no acks or reviews for the other patches in the series.
> > I would like for someone to test the tsc2005 support to see if it still 
> > works.
> > 
> > The tsc2004 works very well on the target that I have here.
> 
> I folded this patch into the patch #3 and applied everything.
>

Great.

Will this patch series conflict with the patch series to take out the 
.owner=THIS_MODULE
from spi_drivers?

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1004626.html
 
> Thanks!
> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4] arm64: dts: Added syscon-reboot node for FSL's LS2085A SoC

[Stuart Yoder]

> -Original Message-
> From: J. German Rivera [mailto:german.riv...@freescale.com]
> Sent: Friday, October 30, 2015 3:05 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; devicetree@vger.kernel.org; 
> linux-arm-
> ker...@lists.infradead.org; linux-ker...@vger.kernel.org
> Cc: Sharma Bhupesh-B45370; Yoder Stuart-B08248; Li Yang-Leo-R58472; Rivera 
> Jose-B46482
> Subject: [PATCH v4] arm64: dts: Added syscon-reboot node for FSL's LS2085A SoC
> 
> Added sys-reboot node to the FSL's LS2085A SoC DT to leverage
> the ARM-generic reboot mechanism for this SoC. This mechanism
> is enabled through CONFIG_POWER_RESET_SYSCON.

German, one thing I noticed with this patch-- with the name change to
ls2080a, we should update the patch subject and commit message
to reflect that.

Thanks,
Stuart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Dmitry Torokhov]

On Tue, Nov 03, 2015 at 09:41:17AM -0600, Michael Welling wrote:
> On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> > On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
> >  wrote:
> > > On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> > >> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > >> > > +Required properties:
> > >> > > + - compatible: "ti,tsc2004"
> > >> > > + - interrupts: IRQ specifier
> > >> > > + - vio-supply : Regulator specifier
> > >> >
> > >> > reg property?
> > >>
> > >> Rob,
> > >>
> > >> It appears that I missed this in the description.
> > >>
> > >> Probably because I was following the lead of the ts2005 description.
> > >>
> > >> How does this look:
> > >> - reg : I2C address. 0x48 - 0x4b based on the voltage 
> > >> applied to
> > >> the AD1 and AD0 inputs on the IC.
> > >>
> > >
> > > How about the version below?
> > >
> > > Thanks.
> > >
> > > --
> > > Dmitry
> > >
> > >
> > > Input: tsc2004 - document ts2004 dt bindings
> 
> Just noticed that it says ts2004 instead of tsc2004 in the subject.
> Otherwise, I am fine with it.
> 
> Thanks for the assistance.
> 
> Still no acks or reviews for the other patches in the series.
> I would like for someone to test the tsc2005 support to see if it still works.
> 
> The tsc2004 works very well on the target that I have here.

I folded this patch into the patch #3 and applied everything.

Thanks!

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv2 0/2] rpi: add support for rpi power domain driver

[Alexander Aring]

Hi,

this patch series contains at first a patch for the power domain subsystem
which offers to uninit generic power domains when init was called before.

The RPi Power-Domains need to be enabled/disabled by interacting with the
RPi firmware which can fail. To cleanup the probing we need to undo the
power domains again which was registered before.

- Alex

Alexander Aring (2):
  power: domain: add pm_genpd_uninit
  rpi: add support to enable usb power domain

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  25 +++
 arch/arm/boot/dts/bcm2835-rpi.dtsi |  11 ++
 arch/arm/boot/dts/bcm2835.dtsi |   2 +-
 arch/arm/mach-bcm/Kconfig  |  10 ++
 arch/arm/mach-bcm/Makefile |   1 +
 arch/arm/mach-bcm/raspberrypi-power.c  | 180 +
 drivers/base/power/domain.c|  15 ++
 include/dt-bindings/arm/raspberrypi-power.h|  14 ++
 include/linux/pm_domain.h  |   4 +
 9 files changed, 261 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv2 1/2] power: domain: add pm_genpd_uninit

[Alexander Aring]

This patch adds function pm_genpd_uninit for undo a pm_genpd_init. This
is useful for multiple power domains while probing. If the probing fails
after one pm_genpd_init was called we need to undo all previous
registrations of generic pm domains inside the gpd_list list.

There is a check on IS_ERR_OR_NULL(genpd) which is useful to check again
registered power domains and not registered domains, the driver can use
this mechanism to have an array with registered and non-registered power
domains, where non-registered power domains are NULL.

Cc: Rafael J. Wysocki 
Cc: Kevin Hilman 
Cc: Ulf Hansson 
Cc: Pavel Machek 
Cc: Len Brown 
Cc: Greg Kroah-Hartman 
Signed-off-by: Alexander Aring 
---
 drivers/base/power/domain.c | 15 +++
 include/linux/pm_domain.h   |  4 
 2 files changed, 19 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 16550c6..65b9d1a 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1730,6 +1730,21 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
 }
 EXPORT_SYMBOL_GPL(pm_genpd_init);
 
+/**
+ * pm_genpd_uninit - Uninitialize a generic I/O PM domain object.
+ * @genpd: PM domain object to initialize.
+ */
+void pm_genpd_uninit(struct generic_pm_domain *genpd)
+{
+   if (IS_ERR_OR_NULL(genpd))
+   return;
+
+   mutex_lock(&gpd_list_lock);
+   list_del(&genpd->gpd_list_node);
+   mutex_unlock(&gpd_list_lock);
+}
+EXPORT_SYMBOL_GPL(pm_genpd_uninit);
+
 #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
 /*
  * Device Tree based PM domain providers.
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index b1cf7e7..45d4f7a 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -143,6 +143,7 @@ extern int pm_genpd_detach_cpuidle(struct generic_pm_domain 
*genpd);
 extern int pm_genpd_name_detach_cpuidle(const char *name);
 extern void pm_genpd_init(struct generic_pm_domain *genpd,
  struct dev_power_governor *gov, bool is_off);
+extern void pm_genpd_uninit(struct generic_pm_domain *genpd);
 
 extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
 extern int pm_genpd_name_poweron(const char *domain_name);
@@ -212,6 +213,9 @@ static inline void pm_genpd_init(struct generic_pm_domain 
*genpd,
 struct dev_power_governor *gov, bool is_off)
 {
 }
+static inline void pm_genpd_uninit(struct generic_pm_domain *genpd)
+{
+}
 static inline int pm_genpd_poweron(struct generic_pm_domain *genpd)
 {
return -ENOSYS;
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFCv2 2/2] rpi: add support to enable usb power domain

[Alexander Aring]

This patch adds support for RPi several Power Domains and enable support
to enable the USB Power Domain when it's not enabled before.

This patch based on Eric Anholt's patch to support Power Domains. He had
an issue about -EPROBE_DEFER inside the power domain subsystem, this
issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
if we fail to init or turn-on domain").

It was tested with barebox and the following scripts before booting
linux:

/env/a_off:

 # cat /env/a_off
 #turn off which are enabled by default
 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable

/env/a_on:

 # cat /env/a_on
 #turn off which are enabled by default
 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable

 regulator -n bcm2835_mci0 -s enable
 regulator -n uart0-pl0110 -s enable
 regulator -n uart0-pl0111 -s enable
 regulator -n bcm2835_usb -s enable
 regulator -n bcm2835_i2c0 -s enable
 regulator -n bcm2835_i2c1 -s enable
 regulator -n bcm2835_i2c2 -s enable
 regulator -n bcm2835_spi -s enable
 regulator -n bcm2835_ccp2tx -s enable
 regulator -n bcm2835_dsi -s enable

/env/b:

 # cat /env/b
 sh /env/a_on

 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable
 regulator -n uart0-pl0111 -s disable
 regulator -n bcm2835_usb -s disable
 regulator -n bcm2835_i2c0 -s disable
 regulator -n bcm2835_i2c1 -s disable
 regulator -n bcm2835_i2c2 -s disable
 regulator -n bcm2835_spi -s disable
 regulator -n bcm2835_ccp2tx -s disable
 regulator -n bcm2835_dsi -s disable

/env/c:

 # cat /env/c
 sh ./env/b

 regulator -n bcm2835_mci0 -s enable
 regulator -n uart0-pl0110 -s enable
 regulator -n uart0-pl0111 -s enable
 regulator -n bcm2835_usb -s enable
 regulator -n bcm2835_i2c0 -s enable
 regulator -n bcm2835_i2c1 -s enable
 regulator -n bcm2835_i2c2 -s enable
 regulator -n bcm2835_spi -s enable
 regulator -n bcm2835_ccp2tx -s enable
 regulator -n bcm2835_dsi -s enable

These scripts enables/disable all regulators inside the bootloader. It
was running with a "hard" and "soft" reset without any issues. These
testcases should fit to Stephen Warren suggestions:

"(a) before having explicitly turned the power domain on or off at all (b)
after having turned it on (c) after having turned it off, and for all
power domains."

Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Eric Anholt 
Signed-off-by: Alexander Aring 
---
changes since v2:
 - add pm_genpd_uninit to handle probing failure.
 - move power domain drive to his own driver in arch/arm/mach-bcm/
   Also add own devicetree node for this driver, "raspberrypi,bcm2835-power".
 - Removing all power domains which might exists for the firmware API but
   we currently have no use-case for it. I tried to keep the same domain
   numbering in generic power domains subsystem like they are offered from
   the firmware API. This works, all power_domains which are NULL inside
   the array of genpd_onecell_data.domains[#] will be ignored.
 - Adding Eric Anholt and me to the authors.
 - Creating devicetree documentation for the power domain driver.
 - fix error handling in raspberrypi_firmware_set_power.
 - Remove comment about mapping between power domains array, this is not
   necessary anymore. I add a "enabled" attribute to raspberrypi_power_domain
   which indicates if a domain should be registered or not (zeroed values
   does not indicate such handling, but enabled is false then).
 - remove "goto mbox" not necessary anymore because an own driver
   implementation.
 - Update devicetrees for changes in v2.

 .../bindings/arm/bcm/raspberrypi,bcm2835-power.txt |  25 +++
 arch/arm/boot/dts/bcm2835-rpi.dtsi |  11 ++
 arch/arm/boot/dts/bcm2835.dtsi |   2 +-
 arch/arm/mach-bcm/Kconfig  |  10 ++
 arch/arm/mach-bcm/Makefile |   1 +
 arch/arm/mach-bcm/raspberrypi-power.c  | 180 +
 include/dt-bindings/arm/raspberrypi-power.h|  14 ++
 7 files changed, 242 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
 create mode 100644 arch/arm/mach-bcm/raspberrypi-power.c
 create mode 100644 include/dt-bindings/arm/raspberrypi-power.h

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
new file mode 100644
index 000..c3abc24
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
@@ -0,0 +1,25 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible:  Should be "raspberrypi,bcm2835-power".
+- firmware:Reference to the RPi firmware device node.
+- #power-domain-cells: Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_USB
+
+Example:
+
+power: power {
+   compatible = "raspberrypi,bcm2835-power";
+   

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Arnd Bergmann]

On Tuesday 03 November 2015 16:07:34 Sinan Kaya wrote:
> On 11/3/2015 5:43 AM, Arnd Bergmann wrote:
> > Ok, got it.
> >
> > Best add an explanation like the above in the interrupt handler,
> > to prevent this from accidentally getting 'cleaned up' to use
> > readl(), or copied into a driver that uses PCI ordering rules
> > where it is actually wrong.
> >
> 
> I'm adding this disclaimer into the ISR routine.
> 
> /*
>  * Fine tuned for this HW...
>  *
>  * This ISR has been designed for this particular hardware. Relaxed 
> read
>  * and write accessors are used for performance reasons due to 
> interrupt
>  * delivery guarantees. Do not copy this code blindly and expect
>  * that to work.
>  */
> 
> 

Sounds good.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Sinan Kaya]

On 11/3/2015 5:43 AM, Arnd Bergmann wrote:

Ok, got it.

Best add an explanation like the above in the interrupt handler,
to prevent this from accidentally getting 'cleaned up' to use
readl(), or copied into a driver that uses PCI ordering rules
where it is actually wrong.



I'm adding this disclaimer into the ISR routine.

/*
 * Fine tuned for this HW...
 *
 * This ISR has been designed for this particular hardware. Relaxed read
 * and write accessors are used for performance reasons due to interrupt
 * delivery guarantees. Do not copy this code blindly and expect
 * that to work.
 */



I think it should be done like this:

- anything that is not performance critical, use normal readl/writel
- in the fast path, add a comment to each readl_relaxed()/writel_relaxed()
   that is safe in this driver but that would not be safe in a PCI
   device
- For the ones that would be safe on PCI as weel, use
   readl_relaxed()/writel_relaxed() without a comment on each one,
   but clarify somewhere that these are all intentional.


Makes sense.

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 2/6] fpga: add bindings document for simple fpga bus

[Rob Herring]

On Tue, Nov 3, 2015 at 10:28 AM, atull  wrote:
> On Fri, 30 Oct 2015, Rob Herring wrote:
>
>> On Thu, Oct 29, 2015 at 11:02 AM, atull  wrote:
>> > On Wed, 28 Oct 2015, Rob Herring wrote:
>> >
>> >> On Tue, Oct 27, 2015 at 5:09 PM,   wrote:
>> >> > From: Alan Tull 
>> >> >
>> >> > New bindings document for simple fpga bus.
>> >> >
>> >> > Signed-off-by: Alan Tull 
>> >> > ---
>> >> > v9:  initial version added to this patchset
>> >> > v10: s/fpga/FPGA/g
>> >> >  replace DT overlay example with slightly more complicated example
>> >> >  move to staging/simple-fpga-bus
>> >> > v11: No change in this patch for v11 of the patch set
>> >> > v12: Moved out of staging.
>> >> >  Changed to use FPGA bridges framework instead of resets
>> >> >  for bridges.
>> >> > ---
>> >> >  .../devicetree/bindings/fpga/simple-fpga-bus.txt   |   81 
>> >> > 
>> >> >  1 file changed, 81 insertions(+)
>> >> >  create mode 100644 
>> >> > Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
>> >> >
>> >> > diff --git a/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt 
>> >> > b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
>> >> > new file mode 100644
>> >> > index 000..2e742f7
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
>> >> > @@ -0,0 +1,81 @@
>> >> > +Simple FPGA Bus
>> >> > +===
>> >> > +
>> >> > +A Simple FPGA Bus is a bus that handles configuring an FPGA and its 
>> >> > bridges
>> >> > +before populating the devices below its node.  All this happens when a 
>> >> > device
>> >> > +tree overlay is added to the live tree.  This document describes that 
>> >> > device
>> >> > +tree overlay.
>> >> > +
>> >> > +Required properties:
>> >> > +- compatible : should contain "simple-fpga-bus"
>> >> > +- #address-cells, #size-cells, ranges: must be present to handle 
>> >> > address space
>> >> > +  mapping for children.
>> >> > +
>> >> > +Optional properties:
>> >> > +- fpga-mgr : should contain a phandle to a FPGA manager.
>> >> > +- fpga-firmware : should contain the name of a FPGA image file located 
>> >> > on the
>> >> > +  firmware search path.
>> >>
>> >> Putting firmware filename in DT has come up in other cases recently[1]
>> >> and we concluded it should not be in the DT. Maybe the conclusion
>> >> would be different here, and if so we should have a common property
>> >> here.
>> >
>> > Interesting discussion.
>> >
>> > One FPGA image will almost always have multiple hardware devices in it.
>> > The device blocks will be reused in various combinations in different
>> > FPGA images.  So hardwiring the image name in some specific driver won't
>> > be possible.  Also many of the devices that could appear on a FPGA also
>> > could appear in normal hardware.  Same driver for both cases, just
>> > different address.
>> >
>> > I won't have control of the name of the firmware file.  It will be 
>> > something
>> > that makes sense to a FPGA hardware guy so translating the node name to an
>> > image name would be brittle.
>> >
>> > Renaming this as a generic property "firmware-name" or "firmware" would be
>> > an improvement on what I proposed.
>> >
>> > If it is acceptible to have this in the DT, it means FPGA hardware 
>> > development
>> > workflow does not require a kernel rebuild.  The DT can collect together 
>> > the
>> > image name, the bridges to the FPGA (or to that area of the FPGA), and a 
>> > list
>> > of the devices/drivers in that image.
>>
>> You can deal with this purely in userspace.
>
> We have.  It's ugly.  That means we have to also deal with bridges from
> userspace since they have to be disable during FPGA programming.  And the
> drivers have to be modules that we modprobe after FPGA programming.

I didn't mean everything. From the FPGA mgr perspective, it just calls
request_firmware. From there, whether the kernel does it or a
userspace script does it should be transparent to the rest of the
flow. I fully agree the flow should be controlled from within the
kernel.

>> The firmware userspace
>> helper can load any file you like. If the name is frequently changing,
>> then I agree it should not be in the kernel. But neither should it be
>> in the base DT. However, this would be in the overlay DT? In that use,
>> I think having the firmware name in DT is fine. The other option is
>> just put the firmware itself into the DT overlay (u-boot FIT images
>> are actually DTs with binary blobs). Either way please just create and
>> use a generic binding here.
>
> Planning to use overlays.  I'll use "firmware-name."

Okay, but in v13 you didn't...

>
>>
>> >> > +- partial-reconfig : boolean property should be defined if partial
>> >> > +  reconfiguration of the FPGA is to be done, otherwise full 
>> >> > reconfiguration
>> >> > +  is done.
>> >> > +- fpga-bridges : should contain a list of bridges that the bus will 
>> >> > disable
>> >> > +  before   programming the FPGA and then enable afte

Re: [PATCH v2 5/6] regulator: tps65086: Add regulator driver for the TPS65086 PMIC

[Andrew F. Davis]

On 11/03/2015 10:31 AM, Mark Brown wrote:

On Tue, Nov 03, 2015 at 09:57:46AM -0600, Andrew F. Davis wrote:

On 10/31/2015 09:37 PM, Mark Brown wrote:

On Fri, Oct 30, 2015 at 05:41:43PM -0500, Andrew F. Davis wrote:



+   struct regulator_desc desc;
+   unsigned int decay_reg;
+   unsigned int decay_mask;



The decay_reg and decay_mask fields appear to be entirely write only,
why are they present?



Not sure what you mean, they are written to differently for each regulator,
and read when setting the decay mode in _probe.


Ugh, that's a bit hidden (mostly due to not using the callback).


+   ret = of_regulator_match(&pdev->dev, pdev->dev.of_node,
+tps65086_matches,
+ARRAY_SIZE(tps65086_matches));
+   if (ret < 0) {
+   dev_err(tps->dev, "Error parsing regulator init data\n");
+   return ret;
+   }



Please match regulators using the fields in the regulator_desc rather
than open coding.



I need to match to get the driver specific information for each regulator,
if I let regulator_register do it I never get a chance to process the match,
unless there is a callback or something I'm missing.


There's a callback you are missing, of_parse_cb().



Ah, that will make things easier, I'll re-spin with the callback.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v13 3/6] fpga: add simple-fpga-bus

[atull]

From: Alan Tull 

The Simple FPGA bus uses the FPGA Manager Framework and the
FPGA Bridge Framework to provide a manufactorer-agnostic
interface for reprogramming FPGAs that is Device Tree
Overlays-based.

When a Device Tree Overlay containing a Simple FPGA Bus is
applied, the Simple FPGA Bus will be probed and will:
 * Disable the FPGA bridges specified in the overlay
 * Reprogram a specified FPGA with a specified image file
 * Enable the specified FPGA bridges
 * Populate the child devices

Removing the Device Tree Overlay is also supported.

This supports fpga use where hardware blocks on a fpga will
need drivers.

Signed-off-by: Alan Tull 
---
v9:  initial version (this patch added during rest of patchset's v9)
v10: request deferral if fpga mgr or bridges not available yet
 cleanup as fpga manager core goes into the real kernel
 Don't assume bridges are disabled before programming FPGA
 Don't hang onto reference for fpga manager
 Move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Use fpga bridges framework.
v13: If no bridges are specified, assume we don't need any.
 Clean up debug messages
 Some dev_info -> dev_dbg
 Remove unneeded #include
 Fix size of array of pointers
 Don't need to specify .owner
 Use common binding: firmware-name
---
 drivers/fpga/Kconfig   |   7 +
 drivers/fpga/Makefile  |   3 +
 drivers/fpga/simple-fpga-bus.c | 323 +
 3 files changed, 333 insertions(+)
 create mode 100644 drivers/fpga/simple-fpga-bus.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index c9b9fdf..5fcf60a 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -13,6 +13,13 @@ config FPGA
 
 if FPGA
 
+config SIMPLE_FPGA_BUS
+   bool "Simple FPGA Bus"
+   depends on OF
+   help
+ Simple FPGA Bus allows loading FPGA images under control of
+Device Tree.
+
 config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6..9b55ae0 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 # FPGA Manager Drivers
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
+
+# High Level Interfaces
+obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
diff --git a/drivers/fpga/simple-fpga-bus.c b/drivers/fpga/simple-fpga-bus.c
new file mode 100644
index 000..abe95a0
--- /dev/null
+++ b/drivers/fpga/simple-fpga-bus.c
@@ -0,0 +1,323 @@
+/*
+ * Simple FPGA Bus
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct simple_fpga_bus - simple fpga bus private data
+ * @dev:   device from pdev
+ * @bridges:   FPGA bridges associated with this bus
+ * @num_bridges: size of the bridges array
+ */
+struct simple_fpga_bus {
+   struct device *dev;
+   struct fpga_bridge **bridges;
+   int num_bridges;
+};
+
+/**
+ * simple_fpga_bus_get_mgr - get associated fpga manager
+ * @priv: simple fpga bus private data
+ * pointer to fpga manager in priv->mgr on success
+ *
+ * Given a simple fpga bus, get a reference to its the fpga manager specified
+ * by its "fpga-mgr" device tree property.
+ *
+ * Return: 0 if the fpga manager is not specified.
+ * pointer to struct fpga_manager if successful.
+ * Negative error code otherwise.
+ */
+static struct fpga_manager *simple_fpga_bus_get_mgr(
+   struct simple_fpga_bus *priv)
+{
+   struct device *dev = priv->dev;
+   struct device_node *np = dev->of_node;
+   struct device_node *mgr_node;
+
+   /*
+* Return 0 (not an error) if fpga manager is not specified.
+* This supports the case where fpga was already configured.
+*/
+   mgr_node = of_parse_phandle(np, "fpga-mgr", 0);
+   if (!mgr_node) {
+   dev_dbg(dev, "could not find fpga-mgr DT property\n");
+   return 0;
+   }
+
+   return of_fpga_mgr_get(mgr_node);
+}
+
+/**
+ * simple_fpga_bus_load_image - load an fpga image under device tree control
+ * @priv: simple fpga

[PATCH v13 5/6] ARM: socfpga: add bindings document for fpga bridge drivers

[atull]

From: Alan Tull 

Add bindings documentation for Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Dinh Nguyen 
---
v2:  separate into 2 documents for the 2 drivers
v12: bump version to line up with simple-fpga-bus version
 remove Linux specific notes such as references to sysfs
 move non-DT specific documentation elsewhere
 remove bindings that would have been used to pass configuration
 clean up formatting
v13: Remove 'label' property
 Change property from init-val to bridge-enable
 Fix email address
---
 .../bindings/fpga/altera-fpga2sdram-bridge.txt | 15 +++
 .../bindings/fpga/altera-hps2fpga-bridge.txt   | 31 ++
 2 files changed, 46 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

diff --git 
a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
new file mode 100644
index 000..81e2f06
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
@@ -0,0 +1,15 @@
+Altera FPGA To SDRAM Bridge Driver
+
+Required properties:
+- compatible   : Should contain "altr,socfpga-fpga2sdram-bridge"
+
+Optional properties:
+- bridge-enable: 0 if driver should disable bridge at startup
+ 1 if driver should enable bridge at startup
+ Default is to leave bridge in current state.
+
+Example:
+   fpga2sdram_br: fpgabridge@3 {
+   compatible = "altr,socfpga-fpga2sdram-bridge";
+   bridge-enable = <0>;
+   };
diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt 
b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
new file mode 100644
index 000..67c28b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
@@ -0,0 +1,31 @@
+Altera FPGA/HPS Bridge Driver
+
+Required properties:
+- compatible   : Should contain one of:
+ "altr,socfpga-hps2fpga-bridge",
+ "altr,socfpga-lwhps2fpga-bridge", or
+ "altr,socfpga-fpga2hps-bridge"
+- clocks   : Clocks used by this module.
+
+Optional properties:
+- bridge-enable: 0 if driver should disable bridge at startup.
+ 1 if driver should enable bridge at startup.
+ Default is to leave bridge in its current state.
+
+Example:
+   hps_fpgabridge0: fpgabridge@0 {
+   compatible = "altr,socfpga-hps2fpga-bridge";
+   clocks = <&l4_main_clk>;
+   bridge-enable = <1>;
+   };
+
+   hps_fpgabridge1: fpgabridge@1 {
+   compatible = "altr,socfpga-lwhps2fpga-bridge";
+   clocks = <&l4_main_clk>;
+   bridge-enable = <0>;
+   };
+
+   hps_fpgabridge2: fpgabridge@2 {
+   compatible = "altr,socfpga-fpga2hps-bridge";
+   clocks = <&l4_main_clk>;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v13 0/6] simple fpga bus and fpga bridge framework

[atull]

From: Alan Tull 

These patches are too late for this merge window; I'm submitting
them for those who are reviewing, especially the bindings.

Changes since v12:
 Change DT property from "init-val" to "bridge-enable"
 Use proposed DT common property "firmware-name" instead of "fpga-firmware"
 Clean up cruft from simple-fpga-bus DT bindings example
 Support Simple FPGA Bus when FPGA Bridges are compiled out.
 Cleanup and nits

The Simple FPGA Bus provides a manufacturer-agnostic interface for
reprogramming FPGAs using Device Tree Overlays.  It uses the FPGA Bridge
Framework and the upstreamed FPGA Manager Framework.  In the case where
FPGA Bridges are not needed, they don't need to be specified in the DT
and can compiled out, if desired.

Alan Tull (6):
  fpga: add usage documentation for simple fpga bus
  fpga: add bindings document for simple fpga bus
  fpga: add simple-fpga-bus
  fpga: add fpga bridge framework
  ARM: socfpga: add bindings document for fpga bridge drivers
  ARM: socfpga: fpga bridge driver support

 .../bindings/fpga/altera-fpga2sdram-bridge.txt |  15 +
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |  31 ++
 .../devicetree/bindings/fpga/simple-fpga-bus.txt   |  74 +
 Documentation/fpga/simple-fpga-bus.txt |  58 
 drivers/fpga/Kconfig   |  21 ++
 drivers/fpga/Makefile  |   7 +
 drivers/fpga/altera-fpga2sdram.c   | 185 
 drivers/fpga/altera-hps2fpga.c | 233 +++
 drivers/fpga/fpga-bridge.c | 229 +++
 drivers/fpga/simple-fpga-bus.c | 323 +
 include/linux/fpga/fpga-bridge.h   |  74 +
 11 files changed, 1250 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
 create mode 100644 Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
 create mode 100644 Documentation/fpga/simple-fpga-bus.txt
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 drivers/fpga/simple-fpga-bus.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v13 4/6] fpga: add fpga bridge framework

[atull]

From: Alan Tull 

This framework adds API functions for enabling/
disabling FPGA bridges under kernel control.

This allows the Linux kernel to disable FPGA bridges
during FPGA reprogramming and to enable FPGA bridges
when FPGA reprogramming is done.  This framework is
be manufacturer-agnostic, allowing it to be used in
interfaces that use the FPGA Manager Framework to
reprogram FPGAs.

The functions are:
* of_fpga_bridge_get
* fpga_bridge_put
   Get/put a reference to a FPGA bridge.

* fpga_bridge_enable
* fpga_bridge_disable
   Enable/Disable traffic through a bridge.

* fpga_bridge_register
* fpga_bridge_unregister
   Register/unregister a device-specific low level FPGA
   Bridge driver.

Signed-off-by: Alan Tull 
---
v2:  Minor cleanup
v12: Bump version to line up with simple fpga bus
 Remove sysfs
 Improve get/put functions, get the low level driver too.
 Clean up class implementation
 Add kernel doc documentation
 Rename (un)register_fpga_bridge -> fpga_bridge_(un)register
v13: Add inlined empty functions for if not CONFIG_FPGA_BRIDGE
 Clean up debugging
 Remove unneeded #include in .h
 Remove unnecessary prints
 Remove 'label' DT binding.
 Document the mutex
---
 drivers/fpga/Kconfig |   7 ++
 drivers/fpga/Makefile|   3 +
 drivers/fpga/fpga-bridge.c   | 229 +++
 include/linux/fpga/fpga-bridge.h |  74 +
 4 files changed, 313 insertions(+)
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 5fcf60a..6383b47 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -31,6 +31,13 @@ config FPGA_MGR_ZYNQ_FPGA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
+config FPGA_BRIDGE
+   bool "FPGA Bridge Drivers"
+   depends on OF
+   help
+ Say Y here if you want to support bridges connected between host
+processors and FPGAs or between FPGAs.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 9b55ae0..5e9e0e1 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -9,5 +9,8 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
 
+# FPGA Bridge Drivers
+obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+
 # High Level Interfaces
 obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
new file mode 100644
index 000..14cdb7f
--- /dev/null
+++ b/drivers/fpga/fpga-bridge.c
@@ -0,0 +1,229 @@
+/*
+ * fpga bridge driver
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_IDA(fpga_bridge_ida);
+static struct class *fpga_bridge_class;
+
+/**
+ * fpga_bridge_enable
+ * @bridge: fpga bridge
+ *
+ * Enable transactions on the bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_enable(struct fpga_bridge *bridge)
+{
+   return bridge->br_ops->enable_set(bridge, 1);
+}
+EXPORT_SYMBOL_GPL(fpga_bridge_enable);
+
+/**
+ * fpga_bridge_disable
+ * @bridge: fpga bridge
+ *
+ * Disable transactions on the bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_disable(struct fpga_bridge *bridge)
+{
+   return bridge->br_ops->enable_set(bridge, 0);
+}
+EXPORT_SYMBOL_GPL(fpga_bridge_disable);
+
+static int fpga_bridge_of_node_match(struct device *dev, const void *data)
+{
+   return dev->of_node == data;
+}
+
+/**
+ * of_fpga_bridge_get - get an exclusive reference to a fpga bridge
+ * @node: device node
+ *
+ * Given a device node, get an exclusive reference to a fpga bridge.
+ *
+ * Returns a fpga manager struct or IS_ERR() condition containing errno.
+ */
+struct fpga_bridge *of_fpga_bridge_get(struct device_node *node)
+{
+   struct device *dev;
+   struct fpga_bridge *bridge;
+   int ret = -ENODEV;
+
+   dev = class_find_device(fpga_bridge_class, NULL, node,
+   fpga_bridge_of_node_match);
+   if (!dev)
+   return ERR_PTR(-ENODEV);
+
+   bridge = to_fpga_bridge(dev);
+  

[PATCH v13 2/6] fpga: add bindings document for simple fpga bus

[atull]

From: Alan Tull 

New bindings document for simple fpga bus.

Signed-off-by: Alan Tull 
---
v9:  initial version added to this patchset
v10: s/fpga/FPGA/g
 replace DT overlay example with slightly more complicated example
 move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Changed to use FPGA bridges framework instead of resets
 for bridges.
v13: bridge@0xff2 -> bridge@ff20, etc
 Leave out directly talking about overlays
 Remove regs and clocks directly under simple-fpga-bus in example
 Use common "firmware-name" binding instead of "fpga-firmware"
---
 .../devicetree/bindings/fpga/simple-fpga-bus.txt   | 74 ++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt

diff --git a/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt 
b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
new file mode 100644
index 000..9646c09
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
@@ -0,0 +1,74 @@
+Simple FPGA Bus
+===
+
+A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
+before populating the devices below its node.
+
+Required properties:
+- compatible : should contain "simple-fpga-bus"
+- #address-cells, #size-cells, ranges: must be present to handle address space
+  mapping for children.
+
+Optional properties:
+- fpga-mgr : should contain a phandle to a FPGA manager.
+- fpga-firmware : should contain the name of a FPGA image file located on the
+  firmware search path.
+- partial-reconfig : boolean property should be defined if partial
+  reconfiguration of the FPGA is to be done, otherwise full reconfiguration
+  is done.
+- fpga-bridges : should contain a list of bridges that the bus will disable
+  before programming the FPGA and then enable after the FPGA has been
+  programmed.
+
+Example:
+
+/dts-v1/;
+/plugin/;
+/ {
+   fragment@0 {
+   target-path="/soc";
+   __overlay__ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   bridge@ff20 {
+   compatible = "simple-fpga-bus";
+
+   #address-cells = <0x2>;
+   #size-cells = <0x1>;
+
+   ranges = <0x 0x 0xc000 
0x0001>,
+<0x0001 0x0002 0xff22 
0x0008>,
+<0x0001 0x00010040 0xff210040 
0x0020>;
+
+   fpga-mgr = <&hps_0_fpgamgr>;
+   firmware-name = "soc_system.rbf";
+
+   fpga-bridges = <&hps_fpgabridge0>, 
<&hps_fpgabridge1>, <&hps_fpgabridge2>;
+
+   onchip_memory2_0: memory@0 {
+   device_type = "memory";
+   compatible = "ALTR,onchipmem-15.1";
+   reg = <0x 0x 
0x0001>;
+   };
+
+   jtag_uart: serial@10002 {
+   compatible = "altr,juart-15.1", 
"altr,juart-1.0";
+   reg = <0x0001 0x0002 
0x0008>;
+   interrupt-parent = <&intc>;
+   interrupts = <0 42 4>;
+   };
+
+   led_pio: gpio@100010040 {
+   compatible = "altr,pio-15.1", 
"altr,pio-1.0";
+   reg = <0x0001 0x00010040 
0x0020>;
+   altr,gpio-bank-width = <4>;
+   resetvalue = <0>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   };
+   };
+   };
+   };
+};
+
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v13 6/6] ARM: socfpga: fpga bridge driver support

[atull]

From: Alan Tull 

Supports Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Allows enabling/disabling the bridges through the FPGA
Bridge Framework API functions.

The fpga2sdram driver only supports enabling and disabling
of the ports that been configured early on.  This is due to
a hardware limitation where the read, write, and command
ports on the fpga2sdram bridge can only be reconfigured
while there are no transactions to the sdram, i.e. when
running out of OCRAM before the kernel boots.

Device tree property 'init-val' configures the driver to
enable or disable the bridge during probe.  If the property
does not exist, the driver will leave the bridge in its
current state.

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Dinh Nguyen 
---
v2:  Use resets instead of directly writing reset registers
v12: Bump version to align with simple-fpga-bus version
 Get rid of the sysfs interface
 fpga2sdram: get configuration stored in handoff register
v13: Remove unneeded WARN_ON
 Change property from init-val to bridge-enable
 Checkpatch cleanup
 Fix email address
---
 drivers/fpga/Kconfig |   7 ++
 drivers/fpga/Makefile|   1 +
 drivers/fpga/altera-fpga2sdram.c | 185 +++
 drivers/fpga/altera-hps2fpga.c   | 233 +++
 4 files changed, 426 insertions(+)
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 6383b47..ccbacd0 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -38,6 +38,13 @@ config FPGA_BRIDGE
  Say Y here if you want to support bridges connected between host
 processors and FPGAs or between FPGAs.
 
+config SOCFPGA_FPGA_BRIDGE
+   bool "Altera SoCFPGA FPGA Bridges"
+   depends on ARCH_SOCFPGA && FPGA_BRIDGE
+   help
+ Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
+ devices.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 5e9e0e1..93c7aff 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
 
 # High Level Interfaces
 obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
diff --git a/drivers/fpga/altera-fpga2sdram.c b/drivers/fpga/altera-fpga2sdram.c
new file mode 100644
index 000..acd52f1
--- /dev/null
+++ b/drivers/fpga/altera-fpga2sdram.c
@@ -0,0 +1,185 @@
+/*
+ * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+
+/*
+ * This driver manages a bridge between an FPGA and the SDRAM used by the ARM
+ * host processor system (HPS).
+ *
+ * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
+ * Reconfiguring these ports requires that no SDRAM transactions occur during
+ * reconfiguration.  The code reconfiguring the ports cannot run out of SDRAM
+ * nor can the FPGA access the SDRAM during reconfiguration.  This driver does
+ * not support reconfiguring the ports.  The ports are configured by code
+ * running out of on chip ram before Linux is started and the configuration
+ * is passed in a handoff register in the system manager.
+ *
+ * This driver supports enabling and disabling of the configured ports, which
+ * allows for safe reprogramming of the FPGA, assuming that the new FPGA image
+ * uses the same port configuration.  Bridges must be disabled before
+ * reprogramming the FPGA and re-enabled after the FPGA has been programmed.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ALT_SDR_CTL_FPGAPORTRST_OFST   0x80
+#define ALT_SDR_CTL_FPGAPORTRST_PORTRSTN_MSK   0x3fff
+#define ALT_SDR_CTL_FPGAPORTRST_RD_SHIFT   0
+#define ALT_SDR_CTL_FPGAPORTRST_WR_SHIFT   4
+#define ALT_SDR_CTL_FPGAPORTRST_CTRL_SHIFT 8
+
+#define SYSMGR_ISWGRP_HANDOFF3  (0x8C)
+#define ISWGRP_HANDOFF_FPGA2SDR SYSMGR_ISWGRP_HANDOFF3
+
+#define F2S_BRIDGE_NAME "fpga2sdram"
+
+struct alt_fpga2sdram_data {
+   struct device *de

[PATCH v13 1/6] fpga: add usage documentation for simple fpga bus

[atull]

From: Alan Tull 

Add a document spelling out usage of the simple fpga bus.

Signed-off-by: Alan Tull 
Reviewed-by: Moritz Fischer 
---
v9:  Initial version of this patch in patchset
v10: s/fpga/FPGA/g
 improve formatting
 some rewriting
 move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging
 Small changes due to using FPGA bridge framework and not
 representing the bridges as resets.
v13: Fix some nits
---
 Documentation/fpga/simple-fpga-bus.txt | 58 ++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/fpga/simple-fpga-bus.txt

diff --git a/Documentation/fpga/simple-fpga-bus.txt 
b/Documentation/fpga/simple-fpga-bus.txt
new file mode 100644
index 000..9b04826
--- /dev/null
+++ b/Documentation/fpga/simple-fpga-bus.txt
@@ -0,0 +1,58 @@
+Simple FPGA Bus
+
+Alan Tull 2015
+
+Overview
+
+
+The simple FPGA bus adds device tree overlay support for FPGAs.  Loading a DT
+overlay will result in the FPGA getting programmed with an image, its bridges
+will be released, and the DT populated for nodes below the simple-fpga-bus.
+This results in drivers getting probed for the hardware that just got added.
+This is intended to support the FPGA usage where the FPGA has hardware that
+requires drivers.  Removing the overlay will result in the drivers getting
+removed and the bridges being disabled.
+
+The simple FPGA bus will need to disable and enable bridges that will only
+affect the child devices that are below the bus.  If partial reconfiguration
+is to be done, then bridges will need to be added within the FPGA design to
+protect the rest of the bus when one part of the FPGA design is being
+reconfigured.
+
+
+Sequence
+
+
+Load the DT overlay.  One way to do that from user space is to use Pantelis'
+DT-Overlay configfs interface.
+
+This causes the simple FPGA bus to be probed and will do the following:
+ 1. Disable the FPGA bridges.
+ 2. Call the FPGA manager core to program the FPGA.
+ 3. Release the FPGA bridges.
+ 4. Call of_platform_populate resulting in device drivers getting probed.
+
+
+Requirements
+
+
+ 1. An FPGA image that has a hardware block or blocks that use drivers that are
+supported in the kernel.
+ 2. A device tree overlay (example is in the simple-fpga-bus bindings 
document).
+ 3. A FPGA manager driver supporting writing the FPGA.
+ 4. FPGA bridge drivers.
+
+The DT overlay includes bindings (documented in bindings/simple-fpga-bus.txt)
+that specify:
+ * Which FPGA manager to use.
+ * Which image file to load.
+ * Flags indicating whether this this image is for full reconfiguration or
+   partial.
+ * A list of FPGA bridges.
+ * Child nodes specifying the devices that will be added with appropriate
+   compatible strings, etc.
+
+Since this code uses the firmware interface to get the image and DT overlay,
+they currently have to be files on the file system.  It doesn't have to be that
+way forever as DT bindings could be added to point to other sources for the
+image.
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] mfd: arizona: Add DT binding for irq-gpios property

[Charles Keepax]

On Tue, Nov 03, 2015 at 03:04:50PM +, Mark Brown wrote:
> On Tue, Nov 03, 2015 at 03:10:06PM +0100, Sebastien Jan wrote:
> 
> > +  - irq-gpios : GPIO specifier for the GPIO connected to /IRQ
> 
> The platform data this is providing is essentially a workaround for the
> lack of an irq_to_gpio() function and the use of it is a workaround for
> the lack of level triggered IRQ emulation in genirq...  do we really
> want this in the ABI (especially as a generic thing)?

Personally I would rather not add this to the DT unless we really
had to.

Also are you sure this is necessary on your system? Specifically
you only need this entry if the CODEC is connected to an IRQ line
that only supports edge triggered IRQs.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 2/6] fpga: add bindings document for simple fpga bus

[atull]

On Fri, 30 Oct 2015, Rob Herring wrote:

> On Thu, Oct 29, 2015 at 11:02 AM, atull  wrote:
> > On Wed, 28 Oct 2015, Rob Herring wrote:
> >
> >> On Tue, Oct 27, 2015 at 5:09 PM,   wrote:
> >> > From: Alan Tull 
> >> >
> >> > New bindings document for simple fpga bus.
> >> >
> >> > Signed-off-by: Alan Tull 
> >> > ---
> >> > v9:  initial version added to this patchset
> >> > v10: s/fpga/FPGA/g
> >> >  replace DT overlay example with slightly more complicated example
> >> >  move to staging/simple-fpga-bus
> >> > v11: No change in this patch for v11 of the patch set
> >> > v12: Moved out of staging.
> >> >  Changed to use FPGA bridges framework instead of resets
> >> >  for bridges.
> >> > ---
> >> >  .../devicetree/bindings/fpga/simple-fpga-bus.txt   |   81 
> >> > 
> >> >  1 file changed, 81 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt 
> >> > b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> >> > new file mode 100644
> >> > index 000..2e742f7
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> >> > @@ -0,0 +1,81 @@
> >> > +Simple FPGA Bus
> >> > +===
> >> > +
> >> > +A Simple FPGA Bus is a bus that handles configuring an FPGA and its 
> >> > bridges
> >> > +before populating the devices below its node.  All this happens when a 
> >> > device
> >> > +tree overlay is added to the live tree.  This document describes that 
> >> > device
> >> > +tree overlay.
> >> > +
> >> > +Required properties:
> >> > +- compatible : should contain "simple-fpga-bus"
> >> > +- #address-cells, #size-cells, ranges: must be present to handle 
> >> > address space
> >> > +  mapping for children.
> >> > +
> >> > +Optional properties:
> >> > +- fpga-mgr : should contain a phandle to a FPGA manager.
> >> > +- fpga-firmware : should contain the name of a FPGA image file located 
> >> > on the
> >> > +  firmware search path.
> >>
> >> Putting firmware filename in DT has come up in other cases recently[1]
> >> and we concluded it should not be in the DT. Maybe the conclusion
> >> would be different here, and if so we should have a common property
> >> here.
> >
> > Interesting discussion.
> >
> > One FPGA image will almost always have multiple hardware devices in it.
> > The device blocks will be reused in various combinations in different
> > FPGA images.  So hardwiring the image name in some specific driver won't
> > be possible.  Also many of the devices that could appear on a FPGA also
> > could appear in normal hardware.  Same driver for both cases, just
> > different address.
> >
> > I won't have control of the name of the firmware file.  It will be something
> > that makes sense to a FPGA hardware guy so translating the node name to an
> > image name would be brittle.
> >
> > Renaming this as a generic property "firmware-name" or "firmware" would be
> > an improvement on what I proposed.
> >
> > If it is acceptible to have this in the DT, it means FPGA hardware 
> > development
> > workflow does not require a kernel rebuild.  The DT can collect together the
> > image name, the bridges to the FPGA (or to that area of the FPGA), and a 
> > list
> > of the devices/drivers in that image.
> 
> You can deal with this purely in userspace.

We have.  It's ugly.  That means we have to also deal with bridges from
userspace since they have to be disable during FPGA programming.  And the
drivers have to be modules that we modprobe after FPGA programming.

> The firmware userspace
> helper can load any file you like. If the name is frequently changing,
> then I agree it should not be in the kernel. But neither should it be
> in the base DT. However, this would be in the overlay DT? In that use,
> I think having the firmware name in DT is fine. The other option is
> just put the firmware itself into the DT overlay (u-boot FIT images
> are actually DTs with binary blobs). Either way please just create and
> use a generic binding here.

Planning to use overlays.  I'll use "firmware-name."

> 
> >> > +- partial-reconfig : boolean property should be defined if partial
> >> > +  reconfiguration of the FPGA is to be done, otherwise full 
> >> > reconfiguration
> >> > +  is done.
> >> > +- fpga-bridges : should contain a list of bridges that the bus will 
> >> > disable
> >> > +  before   programming the FPGA and then enable after the FPGA has been
> >> > +
> >> > +Example:
> >> > +
> >> > +/dts-v1/;
> >> > +/plugin/;
> >> > +/ {
> >> > +   fragment@0 {
> >> > +   target-path="/soc";
> >> > +   __overlay__ {
> >> > +   #address-cells = <1>;
> >> > +   #size-cells = <1>;
> >> > +
> >> > +   bridge@0xff20 {
> >> > +   compatible = "simple-fpga-bus";
> >> > + 

Re: [PATCH v2 5/6] regulator: tps65086: Add regulator driver for the TPS65086 PMIC

[Mark Brown]

On Tue, Nov 03, 2015 at 09:57:46AM -0600, Andrew F. Davis wrote:
> On 10/31/2015 09:37 PM, Mark Brown wrote:
> >On Fri, Oct 30, 2015 at 05:41:43PM -0500, Andrew F. Davis wrote:

> >>+   struct regulator_desc desc;
> >>+   unsigned int decay_reg;
> >>+   unsigned int decay_mask;

> >The decay_reg and decay_mask fields appear to be entirely write only,
> >why are they present?

> Not sure what you mean, they are written to differently for each regulator,
> and read when setting the decay mode in _probe.

Ugh, that's a bit hidden (mostly due to not using the callback).

> >>+   ret = of_regulator_match(&pdev->dev, pdev->dev.of_node,
> >>+tps65086_matches,
> >>+ARRAY_SIZE(tps65086_matches));
> >>+   if (ret < 0) {
> >>+   dev_err(tps->dev, "Error parsing regulator init data\n");
> >>+   return ret;
> >>+   }

> >Please match regulators using the fields in the regulator_desc rather
> >than open coding.

> I need to match to get the driver specific information for each regulator,
> if I let regulator_register do it I never get a chance to process the match,
> unless there is a callback or something I'm missing.

There's a callback you are missing, of_parse_cb().


signature.asc
Description: PGP signature

[PATCH] PCI: rcar (usb): DT can override default window settings

[Phil Edworthy]

If the dtb specifies dma-ranges, we use those values. Otherwise, we
default to the values that were previously hardcoded into the driver.

Signed-off-by: Phil Edworthy 
---
 .../devicetree/bindings/pci/pci-rcar-gen2.txt  |  6 ++
 drivers/pci/host/pci-rcar-gen2.c   | 76 +-
 2 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt 
b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
index 7fab84b..891463c 100644
--- a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -24,6 +24,11 @@ Required properties:
 - interrupt-map-mask: standard property that helps to define the interrupt
   mapping.
 
+Optional properties:
+- dma-ranges: a single range for the inbound memory region. If not supplied,
+  defaults to 1GiB at 0x4000. Note there are hardware restrictions on the
+  allowed combinations of address and size.
+
 Example SoC configuration:
 
pci0: pci@ee09  {
@@ -38,6 +43,7 @@ Example SoC configuration:
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
+   dma-ranges = <0x4200 0 0x4000 0 0x4000 0 
0x4000>;
interrupt-map-mask = <0xff00 0 0 0x7>;
interrupt-map = <0x 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
index c4f64bf..6295116 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -102,6 +103,8 @@ struct rcar_pci_priv {
unsigned busnr;
int irq;
unsigned long window_size;
+   unsigned long window_addr;
+   unsigned long window_pci;
 };
 
 /* PCI configuration space operations */
@@ -239,8 +242,8 @@ static int rcar_pci_setup(int nr, struct pci_sys_data *sys)
   RCAR_PCI_ARBITER_PCIBP_MODE;
iowrite32(val, reg + RCAR_PCI_ARBITER_CTR_REG);
 
-   /* PCI-AHB mapping: 0x4000 base */
-   iowrite32(0x4000 | RCAR_PCIAHB_PREFETCH16,
+   /* PCI-AHB mapping */
+   iowrite32(priv->window_addr | RCAR_PCIAHB_PREFETCH16,
  reg + RCAR_PCIAHB_WIN1_CTR_REG);
 
/* AHB-PCI mapping: OHCI/EHCI registers */
@@ -251,7 +254,7 @@ static int rcar_pci_setup(int nr, struct pci_sys_data *sys)
iowrite32(RCAR_AHBPCI_WIN1_HOST | RCAR_AHBPCI_WIN_CTR_CFG,
  reg + RCAR_AHBPCI_WIN1_CTR_REG);
/* Set PCI-AHB Window1 address */
-   iowrite32(0x4000 | PCI_BASE_ADDRESS_MEM_PREFETCH,
+   iowrite32(priv->window_pci | PCI_BASE_ADDRESS_MEM_PREFETCH,
  reg + PCI_BASE_ADDRESS_1);
/* Set AHB-PCI bridge PCI communication area address */
val = priv->cfg_res->start + RCAR_AHBPCI_PCICOM_OFFSET;
@@ -284,6 +287,64 @@ static struct pci_ops rcar_pci_ops = {
.write  = pci_generic_config_write,
 };
 
+static int pci_dma_range_parser_init(struct of_pci_range_parser *parser,
+struct device_node *node)
+{
+   const int na = 3, ns = 2;
+   int rlen;
+
+   parser->node = node;
+   parser->pna = of_n_addr_cells(node);
+   parser->np = parser->pna + na + ns;
+
+   parser->range = of_get_property(node, "dma-ranges", &rlen);
+   if (!parser->range)
+   return -ENOENT;
+
+   parser->end = parser->range + rlen / sizeof(__be32);
+   return 0;
+}
+
+static int rcar_pci_parse_map_dma_ranges(struct rcar_pci_priv *pci,
+struct device_node *np)
+{
+   struct of_pci_range range;
+   struct of_pci_range_parser parser;
+   int index = 0;
+
+   /* Failure to parse is ok as we fall back to defaults */
+   if (pci_dma_range_parser_init(&parser, np))
+   return 0;
+
+   /* Get the dma-ranges from DT */
+   for_each_of_pci_range(&parser, &range) {
+   /* Hardware only allows one inbound 32-bit range */
+   if (index)
+   return -EINVAL;
+
+   pci->window_addr = (unsigned long)range.cpu_addr;
+   pci->window_pci = (unsigned long)range.pci_addr;
+   pci->window_size = (unsigned long)range.size;
+
+   /* Catch HW limitations */
+   if (!(range.flags & IORESOURCE_PREFETCH)) {
+   dev_err(pci->dev, "window must be prefetchable\n");
+   return -EINVAL;
+   }
+   if (pci->window_addr) {
+   u32 lowaddr = 1 << (ffs(pci->window_addr) - 1);
+
+   if (lowaddr < pci->window_size) {
+   dev_err(pci->dev, "invalid window size/addr\n");
+   

Re: [PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 03/11/15 15:23, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
> Removed msi_controller and added irq_domian for MSI domain hierarchy.
> Modified code for filling MSI address in struct msg.
> Added check for hwirq before passing it to irq_domain_set_info.
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
>  drivers/pci/host/Kconfig   |   10 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1053 
> 
>  4 files changed, 1132 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c

[...]

> +#ifdef CONFIG_PCI_MSI
> +static struct irq_chip nwl_msi_irq_chip = {
> + .name = "nwl_pcie:msi",
> + .irq_enable = unmask_msi_irq,
> + .irq_disable = mask_msi_irq,
> + .irq_mask = mask_msi_irq,
> + .irq_unmask = unmask_msi_irq,
> +
> +};
> +
> +static struct msi_domain_info nwl_msi_domain_info = {
> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> +   MSI_FLAG_MULTI_PCI_MSI),

If you're supporting multi-MSI, how do you ensure that all hwirqs are
contiguous as required by the spec? Clearly, your allocator doesn't
provide this guarantee.

Also, you still lack support for MSI-X (which would come for free...).

> + .chip = &nwl_msi_irq_chip,
> +};
> +#endif
> +
> +static void nwl_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + struct nwl_pcie *pcie = irq_data_get_irq_chip_data(data);
> + struct nwl_msi *msi = &pcie->msi;
> + phys_addr_t msi_addr = virt_to_phys((void *)msi->pages);
> +
> + msg->address_lo = lower_32_bits(msi_addr);
> + msg->address_hi = upper_32_bits(msi_addr);
> + msg->data = data->hwirq;
> +}
> +
> +static int nwl_msi_set_affinity(struct irq_data *irq_data,
> + const struct cpumask *mask, bool force)
> +{
> + return -EINVAL;
> +}
> +
> +static struct irq_chip nwl_irq_chip = {
> + .name = "Xilinx MSI",
> + .irq_compose_msi_msg = nwl_compose_msi_msg,
> + .irq_set_affinity = nwl_msi_set_affinity,
> +};
> +
> +static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs, void *args)
> +{
> + struct nwl_pcie *pcie = domain->host_data;
> + struct nwl_msi *msi = &pcie->msi;
> + unsigned long bit;
> +
> + mutex_lock(&msi->lock);
> + bit = find_first_zero_bit(msi->used, INT_PCI_MSI_NR);
> + if (bit < INT_PCI_MSI_NR)
> + set_bit(bit, msi->used);
> + else
> + bit = -ENOSPC;
> +
> + mutex_unlock(&msi->lock);
> +
> + if (bit < 0)
> + return bit;
> +
> + irq_domain_set_info(domain, virq, bit, &nwl_irq_chip,
> + domain->host_data, handle_simple_irq,
> + NULL, NULL);
> + return 0;
> +}
> +
> +static void nwl_irq_domain_free(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs)
> +{
> + struct irq_data *data = irq_domain_get_irq_data(domain, virq);
> + struct nwl_pcie *pcie = irq_data_get_irq_chip_data(data);
> + struct nwl_msi *msi = &pcie->msi;
> +
> + mutex_lock(&msi->lock);
> + if (!test_bit(data->hwirq, msi->used))
> + dev_err(pcie->dev, "freeing unused MSI %lu\n", data->hwirq);
> + else
> + clear_bit(data->hwirq, msi->used);
> +
> + mutex_unlock(&msi->lock);
> +}
> +
> +static const struct irq_domain_ops dev_msi_domain_ops = {
> + .alloc  = nwl_irq_domain_alloc,
> + .free   = nwl_irq_domain_free,
> +};
> +
> +static void nwl_pcie_free_irq_domain(struct nwl_pcie *pcie)
> +{
> + int i;
> + u32 irq;
> +
> +#ifdef CONFIG_PCI_MSI
> + struct nwl_msi *msi = &pcie->msi;
> +#endif
> +
> + for (i = 0; i < 4; i++) {
> + irq = irq_find_mapping(pcie->legacy_irq_domain, i + 1);
> + if (irq > 0)
> + irq_dispose_mapping(irq);
> + }
> +
> + irq_domain_remove(pcie->legacy_irq_domain);
> +
> +#ifdef CONFIG_PCI_MSI
> + irq_set_chained_handler_and_data(msi->irq_msi0, NULL, NULL);
> + irq_set_chained_handler_and_data(msi->irq_msi1, NULL, NULL);
> +
> + irq_domain_remove(msi->msi_domain);
> + irq_domain_remove(msi->dev_domain);
> +#endif
> +
> +}

Remove these #ifdefs. You can test the validity of these fields before
calling the various functions. You can also move this to a separate
function.

> +
> +static int nwl_pcie_init_irq_domain(struct nwl_pcie *pcie)
> +{
> + struct device_node *node = pcie->dev->of_node;
> + struct device_node *legacy_intc_node;
> +
> +#ifdef CONFIG_PCI_MSI
> + struct nwl_msi *msi = &pcie->msi;
> +#endif
> +
> + legacy

Re: [PATCH RESEND 15/16] leds: add LM3633 driver

[Jacek Anaszewski]

Hi Milo,

Thanks for the patch. Please find my comments in the code.

On 11/02/2015 06:24 AM, Milo Kim wrote:

LM3633 LED driver supports generic LED functions and pattern generation.
Pattern is generated through the sysfs. ABI documentation is also added.

Device creation from device tree

   LED channel name, LED string usage and max current settings are
   configured inside the DT.

LED dimming pattern generation
--
   LM3633 supports programmable dimming pattern generator.
   To enable it, three attributes are used.
   'pattern_times', 'pattern_levels' and 'run_pattern'.
   Sysfs ABI describes it.

LMU HWMON event handling

   As soon as LMU HWMON operation is done, LMU HWMON driver sends the event,
   'LMU_EVENT_HWMON_DONE'. Then, LM3633 device should be reinitialized
   because the device was reset by LMU HWMON driver.
   lm3633_led_hwmon_notifier() handles this event.

Data structure
--
   ti_lmu_led_chip: LED device data.
   ti_lmu_led:  LED output channel data.
One LED device can have multiple LED channels.

Cc: Jacek Anaszewski 
Cc: linux-l...@vger.kernel.org
Cc: Lee Jones 
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Milo Kim 
---
  Documentation/ABI/testing/sysfs-class-led-lm3633 |  60 ++
  drivers/leds/Kconfig |  10 +
  drivers/leds/Makefile|   1 +
  drivers/leds/leds-lm3633.c   | 749 +++
  4 files changed, 820 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-class-led-lm3633
  create mode 100644 drivers/leds/leds-lm3633.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-lm3633 
b/Documentation/ABI/testing/sysfs-class-led-lm3633
new file mode 100644
index 000..c1d8759
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-lm3633
@@ -0,0 +1,60 @@
+LM3633 LED driver generates programmable pattern via the sysfs.
+
+LED Pattern Generator Structure
+
+(3)
+  (a) --->  ___
+   /   \
+  (2) / \ (4)
+  (b) > _/   \_  ...
+   (1)   (5)
+
+ |<-   period   -> |
+
+What:  /sys/class/leds//pattern_times


"time" noun is uncountable.


+Date:  Oct 2015
+KernelVersion: 4.3


These properties certainly will not appear in 4.3.


+Contact:   Milo Kim 
+Description:   read/write
+Set pattern time dimension. There are five arguments.
+  (1) startup delay
+  (2) rising dimming time
+  (3) how much time stays at high level
+  (4) falling dimming time
+  (5) how much time stays at low level
+Ranges are
+  (1), (3), (5): 0 ~ 1. Unit is millisecond.
+  (2), (4): 0 ~ 16000. Unit is millisecond.
+
+Example:
+No delay, rising 200ms, high 300ms, falling 100ms, low 400ms.
+echo "0 200 300 100 400" > /sys/class/leds//pattern_times
+
+cat /sys/class/leds//pattern_times
+delay: 0, rise: 200, high: 300, fall: 100, low: 400


Generally a sysfs attribute should represent a single value.
There are cases where the attribute comprises a list of space separated
values, but certainly colons and commas adds to much noise, and are
cumbersome to parse. I'd opt for creating a separate sysfs attribute
for each of the above 5 properties.


+What:  /sys/class/leds//pattern_levels
+Date:  Oct 2015
+KernelVersion: 4.3
+Contact:   Milo Kim 
+Description:   read/write
+Set pattern level(brightness). There are two arguments.
+  (a) Low brightness level
+  (b) High brightness level
+Ranges are from 0 to 255.
+
+Example:
+Low level is 0, high level is 255.
+echo "0 255" > /sys/class/leds//pattern_levels


I'd go also for two separate attributes. E.g. pattern_brightness_lo and
pattern_brightness_hi, or maybe you'll have better idea.


+cat /sys/class/leds//pattern_levels
+low brightness: 0, high brightness: 255
+
+What:  /sys/class/leds//run_pattern
+Date:  Oct 2015
+KernelVersion: 4.3
+Contact:   Milo Kim 
+Description:   write only
+After 'pattern_times' and 'pattern_levels' are updated,
+run the pattern by writing 1 to 'run_pattern'.
+To stop running pattern, writes 0 to 'run_pattern'.


I wonder how registering an in-driver trigger would work. It would
allow for hiding above pattern attributes when the trigger is inactive,
and thus making the sysfs interface more transparent. You could av

Re: [PATCH RESEND 04/16] Documentation: dt-bindings: leds: add LM3633 LED binding information

[Jacek Anaszewski]

Hi Milo,

Thanks for the patch. Apart from the issues
pointed out by Rob, I have one more suggestion below.

On 11/02/2015 06:24 AM, Milo Kim wrote:

LM3633 LED device is one of TI LMU device list.

Cc: devicetree@vger.kernel.org
Cc: Jacek Anaszewski 
Cc: Lee Jones 
Cc: linux-ker...@vger.kernel.org
Cc: linux-l...@vger.kernel.org
Signed-off-by: Milo Kim 
---
  .../devicetree/bindings/leds/leds-lm3633.txt   | 28 ++
  1 file changed, 28 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-lm3633.txt 
b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
new file mode 100644
index 000..bb7f213
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
@@ -0,0 +1,28 @@
+TI LMU LM3633 LED device tree bindings
+
+Required properties:
+  - compatible: "ti,lm3633-leds"
+
+Child nodes:
+  Each node matches with LED control bank.
+  Please refer to the datasheet [1].
+
+  Required properties of a child node:
+  - lvled1-used, lvled2-used, lvled3-used,
+lvled4-used, lvled5-used, lvled6-used:
+Low voltage LED string configuration. Type is .
+Please describe which output LED string is used.
+
+  Optional properties of a child node:
+  - channel-name: Name string for LED channel identification
+  It is used for creating LED sysfs,
+  /sys/class/leds//.
+  If this property is empty, then default name is set to
+  "indicator:" by the driver.
+  - led-max-microamp: Max current setting. Type is .
+  Unit is microampere. Range is from 5000 to 3.


Could you specify also a step?


+Examples: Please refer to ti-lmu dt-bindings [2].
+
+[1] http://www.ti.com/product/LM3633/datasheet
+[2] Documentation/devicetree/bindings/mfd/ti-lmu.txt




--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] ARM: dts: sun4i: inet9f-rev03: Add support for game buttons /

[Hans de Goede]

Hi Maxime,

Note this patch depends on #include 
changes from input.git/next commit 4f38b9f2f4a56164cad7a42e92f945c3515c5a2e.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/6] regulator: tps65086: Add regulator driver for the TPS65086 PMIC

[Andrew F. Davis]

On 10/31/2015 09:37 PM, Mark Brown wrote:

On Fri, Oct 30, 2015 at 05:41:43PM -0500, Andrew F. Davis wrote:


+struct tps65086_regulator {
+   struct regulator_desc desc;
+   unsigned int decay_reg;
+   unsigned int decay_mask;


The decay_reg and decay_mask fields appear to be entirely write only,
why are they present?



Not sure what you mean, they are written to differently for each regulator,
and read when setting the decay mode in _probe.


+   ret = of_regulator_match(&pdev->dev, pdev->dev.of_node,
+tps65086_matches,
+ARRAY_SIZE(tps65086_matches));
+   if (ret < 0) {
+   dev_err(tps->dev, "Error parsing regulator init data\n");
+   return ret;
+   }


Please match regulators using the fields in the regulator_desc rather
than open coding.



I need to match to get the driver specific information for each regulator,
if I let regulator_register do it I never get a chance to process the match,
unless there is a callback or something I'm missing.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: sun4i: inet9f-rev03: Add support for game buttons / joysticks

[Hans de Goede]

The inet9f-rev03 tablet has multiple fire-buttons / direction controls,
add support for these using the same axis mapping as ps2 compatible game
controllers with the same stick / button layout use.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Do not include dt-bindings/input/evdev.h, as the necessary evdev codes
 have been added to dt-bindings/input/input.h instead
---
 arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts | 164 +++
 1 file changed, 164 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts 
b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
index 2fffc04..ca49b0d 100644
--- a/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
+++ b/arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts
@@ -59,6 +59,159 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+   gpio_keys {
+   compatible = "gpio-keys-polled";
+   pinctrl-names = "default";
+   pinctrl-0 = <&key_pins_inet9f>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+
+   button@0 {
+   label = "Left Joystick Left";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <0x>; /* -1 */
+   gpios = <&pio 0 6 GPIO_ACTIVE_LOW>; /* PA6 */
+   };
+
+   button@1 {
+   label = "Left Joystick Right";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <1>;
+   gpios = <&pio 0 5 GPIO_ACTIVE_LOW>; /* PA5 */
+   };
+
+   button@2 {
+   label = "Left Joystick Up";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <0x>; /* -1 */
+   gpios = <&pio 0 8 GPIO_ACTIVE_LOW>; /* PA8 */
+   };
+
+   button@3 {
+   label = "Left Joystick Down";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <1>;
+   gpios = <&pio 0 9 GPIO_ACTIVE_LOW>; /* PA9 */
+   };
+
+   button@4 {
+   label = "Right Joystick Left";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <0x>; /* -1 */
+   gpios = <&pio 0 1 GPIO_ACTIVE_LOW>; /* PA1 */
+   };
+
+   button@5 {
+   label = "Right Joystick Right";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <1>;
+   gpios = <&pio 0 0 GPIO_ACTIVE_LOW>; /* PA0 */
+   };
+
+   button@6 {
+   label = "Right Joystick Up";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <0x>; /* -1 */
+   gpios = <&pio 0 3 GPIO_ACTIVE_LOW>; /* PA3 */
+   };
+
+   button@7 {
+   label = "Right Joystick Down";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <1>;
+   gpios = <&pio 0 4 GPIO_ACTIVE_LOW>; /* PA4 */
+   };
+
+   button@8 {
+   label = "DPad Left";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <0x>; /* -1 */
+   gpios = <&pio 7 23 GPIO_ACTIVE_LOW>; /* PH23 */
+   };
+
+   button@9 {
+   label = "DPad Right";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <1>;
+   gpios = <&pio 7 24 GPIO_ACTIVE_LOW>; /* PH24 */
+   };
+
+   button@10 {
+   label = "DPad Up";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <0x>; /* -1 */
+   gpios = <&pio 7 25 GPIO_ACTIVE_LOW>; /* PH25 */
+   };
+
+   button@11 {
+   label = "DPad Down";
+   linux,code = ;
+   linux,input-type = ;
+   linux,input-value = <1>;
+   gpios = <&pio 7 26 GPIO_ACTIVE_LOW>; /* PH26 */
+   };
+
+   button@12 {
+   label = "Button X";
+   linux,code = ;
+   gpios = <&pio 0 

Re: [PATCH 1/4] Input: tsc2005 - Separate SPI and core functions

[Michael Welling]

On Mon, Nov 02, 2015 at 05:49:46PM -0800, Dmitry Torokhov wrote:
> On Fri, Oct 30, 2015 at 07:41:23PM -0500, Michael Welling wrote:
> > This patch separates the SPI functionality from core functionality
> > that overlaps with the tsc2004.
> > 
> > Prepares kernel for new tsc2004 driver without much redundant code.
> > 
> > Signed-off-by: Michael Welling 
> > ---
> >  drivers/input/touchscreen/Kconfig  |   4 +
> >  drivers/input/touchscreen/Makefile |   1 +
> >  drivers/input/touchscreen/tsc2005.c| 709 
> > +
> >  .../touchscreen/{tsc2005.c => tsc200x-core.c}  | 226 ++-
> >  drivers/input/touchscreen/tsc200x-core.h   |  78 +++
> >  5 files changed, 162 insertions(+), 856 deletions(-)
> >  copy drivers/input/touchscreen/{tsc2005.c => tsc200x-core.c} (72%)
> >  create mode 100644 drivers/input/touchscreen/tsc200x-core.h
> 
> This was giving me:
> 
> Kernel: arch/x86/boot/bzImage is ready  (#1451)
>   MODPOST 1447 modules
> ERROR: "tsc200x_regmap_config" [drivers/input/touchscreen/tsc2005.ko] 
> undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> 
> I'll fix it up locally by exporting the symbol.
> 
> Thanks.

Ooops. I guess that I need to check more thoroughly the different configs.

Thanks for your help.

> 
> -- 
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: sun7i: Enable audio codec on pcDuino

[Hans de Goede]

From: Jelle van der Waa 

Enable the on-chip audio codec

Signed-off-by: Jelle van der Waa 
Signed-off-by: Hans de Goede 
---
 arch/arm/boot/dts/sun7i-a20-pcduino3.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts 
b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
index 861a4a6..067f365 100644
--- a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
+++ b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
@@ -111,6 +111,11 @@
allwinner,pins = "PH2";
 };
 
+
+&codec {
+   status = "okay";
+};
+
 &cpu0 {
cpu-supply = <®_dcdc2>;
 };
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Michael Welling]

On Tue, Nov 03, 2015 at 09:31:10AM -0600, Rob Herring wrote:
> On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
>  wrote:
> > On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> >> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> >> > > +Required properties:
> >> > > + - compatible: "ti,tsc2004"
> >> > > + - interrupts: IRQ specifier
> >> > > + - vio-supply : Regulator specifier
> >> >
> >> > reg property?
> >>
> >> Rob,
> >>
> >> It appears that I missed this in the description.
> >>
> >> Probably because I was following the lead of the ts2005 description.
> >>
> >> How does this look:
> >> - reg : I2C address. 0x48 - 0x4b based on the voltage 
> >> applied to
> >> the AD1 and AD0 inputs on the IC.
> >>
> >
> > How about the version below?
> >
> > Thanks.
> >
> > --
> > Dmitry
> >
> >
> > Input: tsc2004 - document ts2004 dt bindings

Just noticed that it says ts2004 instead of tsc2004 in the subject.
Otherwise, I am fine with it.

Thanks for the assistance.

Still no acks or reviews for the other patches in the series.
I would like for someone to test the tsc2005 support to see if it still works.

The tsc2004 works very well on the target that I have here.

> >
> > From: Michael Welling 
> >
> > Adds documentation for the devicetree bindings of the new tsc2004 driver.
> >
> > Signed-off-by: Michael Welling 
> > Signed-off-by: Dmitry Torokhov 
> 
> Acked-by: Rob Herring 
> 
> > ---
> >  .../bindings/input/touchscreen/tsc2005.txt |   34 
> > 
> >  1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
> > b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > index 09089a6..b80c04b 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > @@ -1,14 +1,15 @@
> > -* Texas Instruments tsc2005 touchscreen controller
> > +* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
> >
> >  Required properties:
> > - - compatible: "ti,tsc2005"
> > - - reg   : SPI device address
> > - - spi-max-frequency : Maximal SPI speed
> > + - compatible: "ti,tsc2004" or "ti,tsc2005"
> > + - reg   : Device address
> >   - interrupts: IRQ specifier
> > - - reset-gpios   : GPIO specifier
> > - - vio-supply : Regulator specifier
> > + - spi-max-frequency : Maximum SPI clocking speed of the device
> > +   (for tsc2005)
> >
> >  Optional properties:
> > + - vio-supply: Regulator specifier
> > + - reset-gpios   : GPIO specifier for the controller reset line
> >   - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
> > plates
> > in ohm (defaults to 280)
> >   - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not 
> > respond after
> > @@ -18,6 +19,27 @@ Optional properties:
> >
> >  Example:
> >
> > +&i2c3 {
> > +   tsc2004@48 {
> > +   compatible = "ti,tsc2004";
> > +   reg = <0x48>;
> > +   vio-supply = <&vio>;
> > +
> > +   reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
> > +   interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
> > +
> > +   touchscreen-fuzz-x = <4>;
> > +   touchscreen-fuzz-y = <7>;
> > +   touchscreen-fuzz-pressure = <2>;
> > +   touchscreen-size-x = <4096>;
> > +   touchscreen-size-y = <4096>;
> > +   touchscreen-max-pressure = <2048>;
> > +
> > +   ti,x-plate-ohms = <280>;
> > +   ti,esd-recovery-timeout-ms = <8000>;
> > +   };
> > +}
> > +
> >  &mcspi1 {
> > tsc2005@0 {
> > compatible = "ti,tsc2005";
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 02/16] Documentation: dt-bindings: backlight: add TI LMU backlight binding information

[Rob Herring]

On Tue, Nov 3, 2015 at 1:13 AM, Kim, Milo  wrote:
>
> On 11/3/2015 12:02 AM, Rob Herring wrote:
>>
>> On Sun, Nov 1, 2015 at 11:24 PM, Milo Kim  wrote:
>>>
>>> LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697 use common dt-bindings
>>> for describing device.
>>>
>>> Cc: devicetree@vger.kernel.org
>>> Cc: Jingoo Han 
>>> Cc: Lee Jones 
>>> Cc: linux-ker...@vger.kernel.org
>>> Signed-off-by: Milo Kim 
>>> ---
>>>   .../bindings/video/backlight/ti-lmu-backlight.txt  | 67
>>> ++
>>
>>
>> Please move to bindings/leds/backlight/
>
>
> There are backlight bindings under video/backlight. I'd like to know why

Not if you look in linux-next.

> this 'led' location is preferred. My guess is most of properties are from
> common LED properties. Any other reasons?

Yes, that is the main reason.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings

[Rob Herring]

On Tue, Nov 3, 2015 at 1:21 AM, Dmitry Torokhov
 wrote:
> On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
>> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
>> > > +Required properties:
>> > > + - compatible: "ti,tsc2004"
>> > > + - interrupts: IRQ specifier
>> > > + - vio-supply : Regulator specifier
>> >
>> > reg property?
>>
>> Rob,
>>
>> It appears that I missed this in the description.
>>
>> Probably because I was following the lead of the ts2005 description.
>>
>> How does this look:
>> - reg : I2C address. 0x48 - 0x4b based on the voltage 
>> applied to
>> the AD1 and AD0 inputs on the IC.
>>
>
> How about the version below?
>
> Thanks.
>
> --
> Dmitry
>
>
> Input: tsc2004 - document ts2004 dt bindings
>
> From: Michael Welling 
>
> Adds documentation for the devicetree bindings of the new tsc2004 driver.
>
> Signed-off-by: Michael Welling 
> Signed-off-by: Dmitry Torokhov 

Acked-by: Rob Herring 

> ---
>  .../bindings/input/touchscreen/tsc2005.txt |   34 
> 
>  1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> index 09089a6..b80c04b 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> @@ -1,14 +1,15 @@
> -* Texas Instruments tsc2005 touchscreen controller
> +* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
>
>  Required properties:
> - - compatible: "ti,tsc2005"
> - - reg   : SPI device address
> - - spi-max-frequency : Maximal SPI speed
> + - compatible: "ti,tsc2004" or "ti,tsc2005"
> + - reg   : Device address
>   - interrupts: IRQ specifier
> - - reset-gpios   : GPIO specifier
> - - vio-supply : Regulator specifier
> + - spi-max-frequency : Maximum SPI clocking speed of the device
> +   (for tsc2005)
>
>  Optional properties:
> + - vio-supply: Regulator specifier
> + - reset-gpios   : GPIO specifier for the controller reset line
>   - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
> plates
> in ohm (defaults to 280)
>   - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond 
> after
> @@ -18,6 +19,27 @@ Optional properties:
>
>  Example:
>
> +&i2c3 {
> +   tsc2004@48 {
> +   compatible = "ti,tsc2004";
> +   reg = <0x48>;
> +   vio-supply = <&vio>;
> +
> +   reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
> +   interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
> +
> +   touchscreen-fuzz-x = <4>;
> +   touchscreen-fuzz-y = <7>;
> +   touchscreen-fuzz-pressure = <2>;
> +   touchscreen-size-x = <4096>;
> +   touchscreen-size-y = <4096>;
> +   touchscreen-max-pressure = <2048>;
> +
> +   ti,x-plate-ohms = <280>;
> +   ti,esd-recovery-timeout-ms = <8000>;
> +   };
> +}
> +
>  &mcspi1 {
> tsc2005@0 {
> compatible = "ti,tsc2005";
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.

Signed-off-by: Bharat Kumar Gogada 
Signed-off-by: Ravi Kiran Gummaluri 
---
Removed msi_controller and added irq_domian for MSI domain hierarchy.
Modified code for filling MSI address in struct msg.
Added check for hwirq before passing it to irq_domain_set_info.
---
 .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
 drivers/pci/host/Kconfig   |   10 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pcie-xilinx-nwl.c | 1053 
 4 files changed, 1132 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
 create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c

diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..3b2a9ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,68 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location,
+   configuration sapce, and length
+- reg-names: Must include the following entries:
+   "breg": bridge registers
+   "pcireg": PCIe controller registers
+   "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+   "msi1, msi0": interrupt asserted when msi is received
+   "intx": interrupt that is asserted when an legacy interrupt is received
+   "misc": interrupt asserted when miscellaneous is received
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+   mapping of the PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+   supported by hardware)
+   Please refer to the standard PCI bus binding document for a more
+   detailed explanation
+- msi-controller: indicates that this is MSI controller node
+- msi-parent:  MSI parent of the root complex itself
+- legacy-interrupt-controller: Interrupt controller device node for Legacy 
interrupts
+   - interrupt-controller: identifies the node as an interrupt controller
+   - #interrupt-cells: should be set to 1
+   - #address-cells: specifies the number of cells needed to encode an
+   address. The value must be 0.
+
+
+Example:
+
+
+nwl_pcie: pcie@fd0e {
+   #address-cells = <3>;
+   #size-cells = <2>;
+   compatible = "xlnx,nwl-pcie-2.11";
+   #interrupt-cells = <1>;
+   msi-controller;
+   device_type = "pci";
+   interrupt-parent = <&gic>;
+   interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
+   interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
+   interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+   interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
+   <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
+   <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
+   <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
+
+   msi-parent = <&nwl_pcie>;
+   reg = <0x0 0xfd0e 0x1000>,
+ <0x0 0xfd48 0x1000>,
+ <0x0 0xe000 0x100>;
+   reg-names = "breg", "pcireg", "cfg";
+   ranges = <0x0200 0x 0xe100 0x 0xe100 0 
0x0f00>;
+
+   pcie_intc: legacy-interrupt-controller {
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..24cbcba 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,16 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF
 
+config PCIE_XILINX_NWL
+   bool "NWL PCIe Core"
+   depends on ARCH_ZYNQMP
+   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+   help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller. The controller can act as Root Port
+or End Point. The current option selection will only
+support root port enabling.
+
 config PCIE_DW
bool
 
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6a56df7 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone

[PATCH v3 5/5] MAINTAINERS: Update Wolfson Micro section to include CS47L24 source

[Richard Fitzgerald]

The CS47L24 source is part of the ex-Wolfson "Arizona" group of
drivers. Not all cs47lxx devices are part of the Arizona driver
group so the cs47l24 is explicitly listed by its full part number.

Signed-off-by: Richard Fitzgerald 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ee10b57..bd181c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11444,6 +11444,7 @@ F:  drivers/input/touchscreen/wm831x-ts.c
 F: drivers/input/touchscreen/wm97*.c
 F: drivers/mfd/arizona*
 F: drivers/mfd/wm*.c
+F: drivers/mfd/cs47l24*
 F: drivers/power/wm83*.c
 F: drivers/rtc/rtc-wm83*.c
 F: drivers/regulator/wm8*.c
@@ -11457,6 +11458,7 @@ F:  include/linux/wm97xx.h
 F: include/sound/wm.h
 F: sound/soc/codecs/arizona.?
 F: sound/soc/codecs/wm*
+F: sound/soc/codecs/cs47l24*
 
 WORKQUEUE
 M: Tejun Heo 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/5] ASoC: cs47l24: Add driver for Cirrus Logic CS47L24 and WM1831 codecs

[Richard Fitzgerald]

This patch adds support for the Cirrus Logic CS47L24 and WM1831 codecs.

Signed-off-by: Richard Fitzgerald 
---
 sound/soc/codecs/Kconfig   |8 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/cs47l24.c | 1148 
 sound/soc/codecs/cs47l24.h |   23 +
 4 files changed, 1181 insertions(+)
 create mode 100644 sound/soc/codecs/cs47l24.c
 create mode 100644 sound/soc/codecs/cs47l24.h

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index cfdafc4..55e14a3 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -55,6 +55,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_CS4271_SPI if SPI_MASTER
select SND_SOC_CS42XX8_I2C if I2C
select SND_SOC_CS4349 if I2C
+   select SND_SOC_CS47L24 if MFD_CS47L24
select SND_SOC_CX20442 if TTY
select SND_SOC_DA7210 if SND_SOC_I2C_AND_SPI
select SND_SOC_DA7213 if I2C
@@ -195,10 +196,12 @@ config SND_SOC_88PM860X
 
 config SND_SOC_ARIZONA
tristate
+   default y if SND_SOC_CS47L24=y
default y if SND_SOC_WM5102=y
default y if SND_SOC_WM5110=y
default y if SND_SOC_WM8997=y
default y if SND_SOC_WM8998=y
+   default m if SND_SOC_CS47L24=m
default m if SND_SOC_WM5102=m
default m if SND_SOC_WM5110=m
default m if SND_SOC_WM8997=m
@@ -211,9 +214,11 @@ config SND_SOC_WM_HUBS
 
 config SND_SOC_WM_ADSP
tristate
+   default y if SND_SOC_CS47L24=y
default y if SND_SOC_WM5102=y
default y if SND_SOC_WM5110=y
default y if SND_SOC_WM2200=y
+   default m if SND_SOC_CS47L24=m
default m if SND_SOC_WM5102=m
default m if SND_SOC_WM5110=m
default m if SND_SOC_WM2200=m
@@ -422,6 +427,9 @@ config SND_SOC_CS4349
tristate "Cirrus Logic CS4349 CODEC"
depends on I2C
 
+config SND_SOC_CS47L24
+   tristate
+
 config SND_SOC_CX20442
tristate
depends on TTY
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index f632fc4..c1d73fe 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -47,6 +47,7 @@ snd-soc-cs4271-spi-objs := cs4271-spi.o
 snd-soc-cs42xx8-objs := cs42xx8.o
 snd-soc-cs42xx8-i2c-objs := cs42xx8-i2c.o
 snd-soc-cs4349-objs := cs4349.o
+snd-soc-cs47l24-objs := cs47l24.o
 snd-soc-cx20442-objs := cx20442.o
 snd-soc-da7210-objs := da7210.o
 snd-soc-da7213-objs := da7213.o
@@ -242,6 +243,7 @@ obj-$(CONFIG_SND_SOC_CS4271_SPI)+= snd-soc-cs4271-spi.o
 obj-$(CONFIG_SND_SOC_CS42XX8)  += snd-soc-cs42xx8.o
 obj-$(CONFIG_SND_SOC_CS42XX8_I2C) += snd-soc-cs42xx8-i2c.o
 obj-$(CONFIG_SND_SOC_CS4349)   += snd-soc-cs4349.o
+obj-$(CONFIG_SND_SOC_CS47L24)  += snd-soc-cs47l24.o
 obj-$(CONFIG_SND_SOC_CX20442)  += snd-soc-cx20442.o
 obj-$(CONFIG_SND_SOC_DA7210)   += snd-soc-da7210.o
 obj-$(CONFIG_SND_SOC_DA7213)   += snd-soc-da7213.o
diff --git a/sound/soc/codecs/cs47l24.c b/sound/soc/codecs/cs47l24.c
new file mode 100644
index 000..dc5ae7f
--- /dev/null
+++ b/sound/soc/codecs/cs47l24.c
@@ -0,0 +1,1148 @@
+/*
+ * cs47l24.h  --  ALSA SoC Audio driver for Cirrus Logic CS47L24
+ *
+ * Copyright 2015 Cirrus Logic Inc.
+ *
+ * Author: Richard Fitzgerald 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "arizona.h"
+#include "wm_adsp.h"
+#include "cs47l24.h"
+
+struct cs47l24_priv {
+   struct arizona_priv core;
+   struct arizona_fll fll[2];
+};
+
+static const struct wm_adsp_region cs47l24_dsp2_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x20 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x28 },
+   { .type = WMFW_ADSP2_XM, .base = 0x29 },
+   { .type = WMFW_ADSP2_YM, .base = 0x2a8000 },
+};
+
+static const struct wm_adsp_region cs47l24_dsp3_regions[] = {
+   { .type = WMFW_ADSP2_PM, .base = 0x30 },
+   { .type = WMFW_ADSP2_ZM, .base = 0x38 },
+   { .type = WMFW_ADSP2_XM, .base = 0x39 },
+   { .type = WMFW_ADSP2_YM, .base = 0x3a8000 },
+};
+
+static const struct wm_adsp_region *cs47l24_dsp_regions[] = {
+   cs47l24_dsp2_regions,
+   cs47l24_dsp3_regions,
+};
+
+static DECLARE_TLV_DB_SCALE(eq_tlv, -1200, 100, 0);
+static DECLARE_TLV_DB_SCALE(digital_tlv, -6400, 50, 0);
+static DECLARE_TLV_DB_SCALE(noise_tlv, -13200, 600, 0);
+static DECLARE_TLV_DB_SCALE(ng_tlv, -10200, 600, 0);
+
+#define CS47L24_NG_SRC(name, base) \
+   SOC_SINGLE(name " NG HPOUT1L Switch",  base,  0, 1, 0), \
+   SOC_SINGLE(name " NG HPOUT1R Switch",  base,  1, 1, 0), \
+   SOC_SINGLE(name " NG SPKOUT Switch",  base,  6, 1, 0)
+
+static const struct snd_kcontrol_new cs47l24_snd_controls[] = {

[PATCH v3 2/5] mfd: arizona: Update DT bindings to add CS47L24 and WM1831

[Richard Fitzgerald]

This updates the Arizona MFD device tree bindings to add the
Cirrus Logic CS47L24 and WM1831 codecs. Note that unlike all the
other codecs the DCVDD-supply and MICVDD-supply are mandatory.

Signed-off-by: Richard Fitzgerald 
---
 Documentation/devicetree/bindings/mfd/arizona.txt | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 18be0cb..84e1af5 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -1,4 +1,4 @@
-Wolfson Arizona class audio SoCs
+Cirrus Logic/Wolfson Microelectronics Arizona class audio SoCs
 
 These devices are audio SoCs with extensive digital capabilites and a range
 of analogue I/O.
@@ -6,12 +6,14 @@ of analogue I/O.
 Required properties:
 
   - compatible : One of the following chip-specific strings:
+"cirrus,cs47l24"
 "wlf,wm5102"
 "wlf,wm5110"
 "wlf,wm8280"
 "wlf,wm8997"
 "wlf,wm8998"
 "wlf,wm1814"
+"wlf,wm1831"
 
   - reg : I2C slave address when connected using I2C, chip select number when
 using SPI.
@@ -41,6 +43,10 @@ Required properties:
 
   - SPKVDD-supply : Speaker driver power supply (wm8997)
 
+  - DCVDD-supply : Main power supply (cs47l24, wm1831)
+
+  - MICVDD-supply : Microphone power supply (cs47l24, wm1831)
+
 Optional properties:
 
   - wlf,reset : GPIO specifier for the GPIO controlling /RESET
@@ -69,6 +75,7 @@ Optional properties:
   - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
 they are being externally supplied. As covered in
 Documentation/devicetree/bindings/regulator/regulator.txt
+(wm5102, wm5110, wm8280, wm8997, wm8998, wm1814)
 
 Also see child specific device properties:
   Regulator - ../regulator/arizona-regulator.txt
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/5] gpio: arizona: Support Cirrus Logic CS47L24 and WM1831

[Richard Fitzgerald]

The CS47L24 and WM1831 codecs only have two GPIO lines, but are
otherwise similar to the WM8280.

Signed-off-by: Richard Fitzgerald 
Acked-by: Linus Walleij 
---
 drivers/gpio/gpio-arizona.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index ca00273..624ea54 100644
--- a/drivers/gpio/gpio-arizona.c
+++ b/drivers/gpio/gpio-arizona.c
@@ -122,6 +122,10 @@ static int arizona_gpio_probe(struct platform_device *pdev)
case WM1814:
arizona_gpio->gpio_chip.ngpio = 5;
break;
+   case WM1831:
+   case CS47L24:
+   arizona_gpio->gpio_chip.ngpio = 2;
+   break;
default:
dev_err(&pdev->dev, "Unknown chip variant %d\n",
arizona->type);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/5] mfd: arizona: Support Cirrus Logic CS47L24 and WM1831

[Richard Fitzgerald]

This patch adds the regmap configuration tables and
core MFD handling for the CS47L24 and WM1831 codecs.

Note that compared to the other Arizona codecs, these devices
do not have an LDO1 or micsupp regulators, extcon driver, or
the DCVDD isolation control.

Signed-off-by: Richard Fitzgerald 
---
 drivers/mfd/Kconfig  |   18 +-
 drivers/mfd/Makefile |3 +
 drivers/mfd/arizona-core.c   |   74 +-
 drivers/mfd/arizona-irq.c|   40 +-
 drivers/mfd/arizona-spi.c|7 +
 drivers/mfd/arizona.h|4 +
 drivers/mfd/cs47l24-tables.c | 1629 ++
 include/linux/mfd/arizona/core.h |3 +
 8 files changed, 1753 insertions(+), 25 deletions(-)
 create mode 100644 drivers/mfd/cs47l24-tables.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4d92df6..9581ebb 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1370,24 +1370,30 @@ config MFD_ARIZONA
bool
 
 config MFD_ARIZONA_I2C
-   tristate "Wolfson Microelectronics Arizona platform with I2C"
+   tristate "Cirrus Logic/Wolfson Microelectronics Arizona platform with 
I2C"
select MFD_ARIZONA
select MFD_CORE
select REGMAP_I2C
depends on I2C
help
- Support for the Wolfson Microelectronics Arizona platform audio SoC
- core functionality controlled via I2C.
+ Support for the Cirrus Logic/Wolfson Microelectronics Arizona platform
+ audio SoC core functionality controlled via I2C.
 
 config MFD_ARIZONA_SPI
-   tristate "Wolfson Microelectronics Arizona platform with SPI"
+   tristate "Cirrus Logic/Wolfson Microelectronics Arizona platform with 
SPI"
select MFD_ARIZONA
select MFD_CORE
select REGMAP_SPI
depends on SPI_MASTER
help
- Support for the Wolfson Microelectronics Arizona platform audio SoC
- core functionality controlled via I2C.
+ Support for the Cirrus Logic/Wolfson Microelectronics Arizona platform
+ audio SoC core functionality controlled via I2C.
+
+config MFD_CS47L24
+   bool "Cirrus Logic CS47L24 and WM1831"
+   depends on MFD_ARIZONA
+   help
+ Support for Cirrus Logic CS47L24 and WM1831 low power audio SoC
 
 config MFD_WM5102
bool "Wolfson Microelectronics WM5102"
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a8b76b8..3fa1df4 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -51,6 +51,9 @@ endif
 ifeq ($(CONFIG_MFD_WM8998),y)
 obj-$(CONFIG_MFD_ARIZONA)  += wm8998-tables.o
 endif
+ifeq ($(CONFIG_MFD_CS47L24),y)
+obj-$(CONFIG_MFD_ARIZONA)  += cs47l24-tables.o
+endif
 obj-$(CONFIG_MFD_WM8400)   += wm8400-core.o
 wm831x-objs:= wm831x-core.o wm831x-irq.o wm831x-otp.o
 wm831x-objs+= wm831x-auxadc.o
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index d474732..b9489a0 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -598,6 +598,12 @@ static int arizona_runtime_resume(struct device *dev)
goto err;
}
break;
+   case WM1831:
+   case CS47L24:
+   ret = arizona_wait_for_boot(arizona);
+   if (ret != 0)
+   goto err;
+   break;
default:
ret = arizona_wait_for_boot(arizona);
if (ret != 0)
@@ -682,6 +688,9 @@ static int arizona_runtime_suspend(struct device *dev)
}
}
break;
+   case WM1831:
+   case CS47L24:
+   break;
default:
jd_active = arizona_is_jack_det_active(arizona);
if (jd_active < 0)
@@ -862,6 +871,8 @@ const struct of_device_id arizona_of_match[] = {
{ .compatible = "wlf,wm8997", .data = (void *)WM8997 },
{ .compatible = "wlf,wm8998", .data = (void *)WM8998 },
{ .compatible = "wlf,wm1814", .data = (void *)WM1814 },
+   { .compatible = "wlf,wm1831", .data = (void *)WM1831 },
+   { .compatible = "cirrus,cs47l24", .data = (void *)CS47L24 },
{},
 };
 EXPORT_SYMBOL_GPL(arizona_of_match);
@@ -919,6 +930,23 @@ static const struct mfd_cell wm5110_devs[] = {
},
 };
 
+static const char * const cs47l24_supplies[] = {
+   "MICVDD",
+   "CPVDD",
+   "SPKVDD",
+};
+
+static const struct mfd_cell cs47l24_devs[] = {
+   { .name = "arizona-gpio" },
+   { .name = "arizona-haptics" },
+   { .name = "arizona-pwm" },
+   {
+   .name = "cs47l24-codec",
+   .parent_supplies = cs47l24_supplies,
+   .num_parent_supplies = ARRAY_SIZE(cs47l24_supplies),
+   },
+};
+
 static const char * const wm8997_supplies[] = {
"MICVDD",
"DBVDD2",
@@ -963,7 +991,7 @@ static const struct mfd_cell wm8998_devs[] = {
 int arizona_dev_init(struct arizona *arizona)
 {

[PATCH v3 0/5] Add support for Cirrus Logic CS47L24 and WM1831 codecs

[Richard Fitzgerald]

Changes since v2
MFD:
  - Make binding doc a separate patch, add updates to supply bindings
  - Fix review comments

ASoC::
  - Fix sort order in KConfig and Makefile

MAINTAINERS:
  - Add patch to update MAINTAINERS


mfd patch based on Lee Jones's for-next
gpio patch based on Linus Walleij's for-next
ASoC patch based on Mark Brown's for-next

Lee/Mark - can one of you take all three patches (with maintainer acks) so
that the patch set is kept together?

Richard Fitzgerald (5):
  mfd: arizona: Support Cirrus Logic CS47L24 and WM1831
  mfd: arizona: Update DT bindings to add CS47L24 and WM1831
  gpio: arizona: Support Cirrus Logic CS47L24 and WM1831
  ASoC: cs47l24: Add driver for Cirrus Logic CS47L24 and WM1831 codecs
  MAINTAINERS: Update Wolfson Micro section to include CS47L24 source

 Documentation/devicetree/bindings/mfd/arizona.txt |9 +-
 MAINTAINERS   |2 +
 drivers/gpio/gpio-arizona.c   |4 +
 drivers/mfd/Kconfig   |   18 +-
 drivers/mfd/Makefile  |3 +
 drivers/mfd/arizona-core.c|   74 +-
 drivers/mfd/arizona-irq.c |   40 +-
 drivers/mfd/arizona-spi.c |7 +
 drivers/mfd/arizona.h |4 +
 drivers/mfd/cs47l24-tables.c  | 1629 +
 include/linux/mfd/arizona/core.h  |3 +
 sound/soc/codecs/Kconfig  |8 +
 sound/soc/codecs/Makefile |2 +
 sound/soc/codecs/cs47l24.c| 1148 +++
 sound/soc/codecs/cs47l24.h|   23 +
 15 files changed, 2948 insertions(+), 26 deletions(-)
 create mode 100644 drivers/mfd/cs47l24-tables.c
 create mode 100644 sound/soc/codecs/cs47l24.c
 create mode 100644 sound/soc/codecs/cs47l24.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] mfd: arizona: Add DT binding for irq-gpios property

[Mark Brown]

On Tue, Nov 03, 2015 at 03:10:06PM +0100, Sebastien Jan wrote:

> +  - irq-gpios : GPIO specifier for the GPIO connected to /IRQ

The platform data this is providing is essentially a workaround for the
lack of an irq_to_gpio() function and the use of it is a workaround for
the lack of level triggered IRQ emulation in genirq...  do we really
want this in the ABI (especially as a generic thing)?


signature.asc
Description: PGP signature

Re: [PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver

[Timur Tabi]

Arnd Bergmann wrote:

If you change the order in the Makefile, the management driver should
always get probed first if both are built-in. When the driver is a
loadable module, the ordering should work because of the way that the
modules are loaded.


This sounds like something that should be commented in the Makefile. 
Even if you use -EPROBE_DEFER and you re-order the Makefile only so that 
it's less likely to be a problem, that's still worthy of a comment.


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] mfd: arizona: Add DT binding for irq-gpios property

[Sebastien Jan]

Signed-off-by: Sebastien Jan 
---
 Documentation/devicetree/bindings/mfd/arizona.txt | 2 ++
 drivers/mfd/arizona-core.c| 5 +
 2 files changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
b/Documentation/devicetree/bindings/mfd/arizona.txt
index a8fee60..f9405ad 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -46,6 +46,8 @@ Optional properties:
   - wlf,reset : GPIO specifier for the GPIO controlling /RESET
   - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
 
+  - irq-gpios : GPIO specifier for the GPIO connected to /IRQ
+
   - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
 for the appropriate values can found in . If
 absent, no configuration of these registers is performed. If any entry has
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 44cfdbb..2046617 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -814,6 +814,11 @@ static int arizona_of_get_core_pdata(struct arizona 
*arizona)
count++;
}
 
+   arizona->pdata.irq_gpio = of_get_named_gpio(arizona->dev->of_node,
+   "irq-gpios", 0);
+   if (arizona->pdata.irq_gpio < 0)
+   arizona->pdata.irq_gpio = 0;
+
return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver

[Arnd Bergmann]

On Monday 02 November 2015 23:45:17 Sinan Kaya wrote:
> On 11/2/2015 4:30 PM, Arnd Bergmann wrote:
> > On Saturday 31 October 2015 02:51:46 Sinan Kaya wrote:
> >> On 10/30/2015 5:34 AM, Arnd Bergmann wrote:
> >>> On Thursday 29 October 2015 23:08:12 Sinan Kaya wrote:
> >> This will be used by the system admin to monitor/reset the execution
> >> state of the DMA channels. This will be the management interface.
> >> Debugfs is probably not the right choice. I originally had sysfs but
> >> than had some doubts. I'm open to suggestions.
> >
> > User interface design is unfortunately always hard, and I don't have
> > an obvious answer for you.
> >
> > Using debugfs by definition means that you don't expect users to
> > rely on ABI stability, so they should not write any automated scripts
> > against the contents of the files.
> >
> > With sysfs, the opposite is true: you need to maintain compatibility
> > for as long as anyone might rely on the current interface, and it
> > needs to be reviewed properly and documented in Documentation/ABI/.
> >
> > Other options are to use ioctl(), netlink or your own virtual file
> > system, but each of them has the same ABI requirements as sysfs.
> >
> > Regardless of what you pick, you also need to consider how other drivers
> > would use the same interface: If someone else has hardware that does
> > the same thing, we want to be able to use the same tools to access
> > it, so you should avoid having any hardware specific data in it and
> > keep it as generic and extensible as possible. In this particular
> > case, that probably means you should implement the user interfaces in
> > the dmaengine core driver, and let the specific DMA driver provide
> > callback function pointers along with the normal ones to fill that
> > data.
> >
> Thanks, I'll think about this. I'm inclined towards sysfs.

Ok. Documentation/sysfs-rules.txt has a good introduction of how this is done.

> >>> The rest of the probe function does not register any user interface aside 
> >>> from
> >>> the debugging stuff. Can you explain in the changelog how you expect the
> >>> driver to be used in a real system? Is there another driver coming?
> >>
> >> I expect this driver to grow in functionality over time. Right now, it
> >> does the global init for the DMA. After that all channels execute on
> >> their own without depending on each other. Global init has to be done
> >> first before attempting to do any channel initialization.
> >>
> >> There is also implied startup ordering requirements. I was doing this by
> >> using channel driver with the late binding to guarantee that.
> >>
> >> As soon as I use module_platform_driver, the ordering gets reversed for
> >> some reason.
> >
> > For the ordering requirements, it's probably best to export a symbol
> > with the entry point and let the normal driver call into that. Using
> > separate initcall levels is not something you should do in a normal
> > device driver like this.
> >
> I figured this out. If the channel driver starts before the management 
> driver; then channel reset fails. I'm handling this in the channel 
> driver and am returning -EPROBE_DEFER. After that, management driver 
> gets its chance to work. Then, the channel driver again. This change is 
> in the v2 series.

If you change the order in the Makefile, the management driver should
always get probed first if both are built-in. When the driver is a
loadable module, the ordering should work because of the way that the
modules are loaded. Using the deferred probing makes sense here,
so that would just be an optimization to avoid it normally. Things
can still get shuffled around e.g. if the management device is
deferred itself and we end up probing the channel driver first.

> > What is the relation between the device nodes for the two kinds of
> > devices? Does it make sense to model the other one as a child device
> > of this one? That way you would trivially do the ordering by not marking
> > this one as 'compatible="simple-bus"' and triggering the registration
> > of the child from the parent probe function.
> >
> 
> The required order is management driver first, channel drivers next. If 
> the order is reversed, channel init fails. I handle this with deferred 
> probing.
> 
> I tried to keep loose binding between the management driver due to QEMU.
> 
> QEMU auto-generates the devicetree entries. The guest machine just sees 
> one devicetree object for the DMA channel but guest machine device-tree 
> kernel does not have any management driver entity.
> 
> This requires DMA channel driver to work independently in the guest 
> machine without dependencies.

You have a distinct "compatible" string for qemu, right? It sounds like
this is not the same device if the dependencies are different, and
you could just have two ways to probe the same device.

The split between the two drivers still feels a little awkward overall,
it might be good to give it some more thought.

Would it work to describe

Re: [PATCH v2 27/32] scsi: hisi_sas: add smp protocol support

[Arnd Bergmann]

On Tuesday 03 November 2015 11:42:30 John Garry wrote:
> >
> There seems to be some misunderstanding. Are you suggesting I change 
> sas_smp_task?
> ./include/scsi/libsas.h
> struct sas_smp_task {
> struct scatterlist smp_req;
> struct scatterlist smp_resp;
> };
> 

Ah, no. I had not realized this comes from another file.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 27/32] scsi: hisi_sas: add smp protocol support

[John Garry]

On 02/11/2015 20:29, Arnd Bergmann wrote:

On Monday 02 November 2015 17:03:58 John Garry wrote:


Can do. Actually sg_req seems only ever has one element:
expander.c, smp_execute_task()
sg_init_one(&task->smp_task.smp_req, req, req_size);



I tried replacing with dma_map_single, but I feel the code is not as
clean as I need to manually set sg_dma_len() and sg_dma_address():
  req_len = sg_dma_len(sg_req) = sg_req->length;
  sg_dma_address(sg_req) = dma_map_single(dev, sg_virt(sg_req),
  req_len, DMA_TO_DEVICE);
  if (dma_mapping_error(dev, sg_dma_address(sg_req)))
   return -ENOMEM;
sg_dma_address(sg_req) is used in another function for unmap.

opinion?



What I meant was not using a struct scatterlist at all:
replace the 'sg_req' variable with a normal pointer, and then
do

hdr->cmd_table_addr = cpu_to_le64(dma_map_single(dev, req, len, 
DMA_TO_DEVICE));

Any reason this won't work?

Arnd

.

There seems to be some misunderstanding. Are you suggesting I change 
sas_smp_task?

./include/scsi/libsas.h
struct sas_smp_task {
struct scatterlist smp_req;
struct scatterlist smp_resp;
};

thanks,
John

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 11/11] scsi: ufs-exynos: add UFS host support for Exynos SoCs

[Alim Akhtar]

Hi Kishon,
Thanks for your time.

On 10/28/2015 06:23 PM, Kishon Vijay Abraham I wrote:

Hi,

On Sunday 25 October 2015 05:34 PM, Alim Akhtar wrote:

Hi Kishon
Thanks again for you review.

On Fri, Oct 23, 2015 at 8:48 PM, Kishon Vijay Abraham I  wrote:

Hi,

On Thursday 15 October 2015 08:38 AM, Alim Akhtar wrote:

+CCing kishon Vijay,

On 10/14/2015 06:25 PM, Alim Akhtar wrote:

From: Seungwon Jeon 

This patch introduces Exynos UFS host controller driver,
which mainly handles vendor-specific operations including
link startup, power mode change and hibernation/unhibernation.

Signed-off-by: Seungwon Jeon 
Signed-off-by: Alim Akhtar 
---
   drivers/scsi/ufs/Kconfig |   12 +
   drivers/scsi/ufs/Makefile|1 +
   drivers/scsi/ufs/ufs-exynos-hw.c |  131 
   drivers/scsi/ufs/ufs-exynos-hw.h |   43 ++
   drivers/scsi/ufs/ufs-exynos.c| 1317
++
   drivers/scsi/ufs/ufs-exynos.h|  247 +++
   drivers/scsi/ufs/ufshci.h|   26 +-
   drivers/scsi/ufs/unipro.h|   47 ++
   8 files changed, 1823 insertions(+), 1 deletion(-)
   create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
   create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
   create mode 100644 drivers/scsi/ufs/ufs-exynos.c
   create mode 100644 drivers/scsi/ufs/ufs-exynos.h


.
.

.
.

diff --git a/drivers/scsi/ufs/ufs-exynos-hw.c
b/drivers/scsi/ufs/ufs-exynos-hw.c
new file mode 100644
index ..be6c61541a8f
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-exynos-hw.c
@@ -0,0 +1,131 @@

.
.

.
.

+
+#define PWR_MODE_STR_LEN64
+static int exynos_ufs_post_pwr_mode(struct ufs_hba *hba,
+struct ufs_pa_layer_attr *pwr_max,
+struct ufs_pa_layer_attr *pwr_req)
+{
+struct exynos_ufs *ufs = to_exynos_ufs(hba);
+struct exynos_ufs_phy_info *phy_info = phy_get_drvdata(ufs->phy);


This is abusing the interface. phy_get_drvdata is meant to be used only
by the PHY driver.

+struct exynos_ufs_phy_specific_ops *phy_ops =
+phy_info->phy_specific_ops;


I'm really not happy about having platform specific ops for PHY. We have
to see if existing PHY ops can be used for this or in worst case add new
PHY ops.

Well you said you like the controller driver to use only PHY ops[1], I
am sorry If I misunderstood that point, can you please help me to
understand that?


I meant PHY generic ops and not PHY ops.

Ok, got it, will use only generic phy here in controller driver.
- Will remove the platform specific PHY ops from phy driver introduce in 
this series (patch 02/11)

[1]-> https://lkml.org/lkml/2015/9/18/29


+struct uic_pwr_mode *pwr = &ufs->pwr_act;
+char pwr_str[PWR_MODE_STR_LEN] = "";
+int ret = 0;
+
+if (ufs->drv_data->post_pwr_change)
+ufs->drv_data->post_pwr_change(ufs, pwr);
+
+if (IS_UFS_PWR_MODE_HS(pwr->mode)) {
+switch (pwr->hs_series) {
+case PA_HS_MODE_A:
+case PA_HS_MODE_B:
+phy_ops->calibrate_phy(ufs->phy, CFG_POST_PWR_HS,
+PWR_MODE_HS(pwr->gear, pwr->hs_series));
+break;
+}
+
+ret = phy_ops->wait_for_lock_acq(ufs->phy);
+snprintf(pwr_str, sizeof(pwr_str), "Fast%s series_%s G_%d L_%d",
+pwr->mode == FASTAUTO_MODE ? "_Auto" : "",
+pwr->hs_series == PA_HS_MODE_A ? "A" : "B",
+pwr->gear, pwr->lane);
+} else if (IS_UFS_PWR_MODE_PWM(pwr->mode)) {
+snprintf(pwr_str, sizeof(pwr_str), "Slow%s G_%d L_%d",
+pwr->mode == SLOWAUTO_MODE ? "_Auto" : "",
+pwr->gear, pwr->lane);
+}
+
+dev_info(hba->dev, "Power mode change %d : %s\n", ret, pwr_str);
+return ret;
+}
+
+static void exynos_ufs_specify_nexus_t_xfer_req(struct ufs_hba *hba,
+int tag, struct scsi_cmnd *cmd)
+{
+struct exynos_ufs *ufs = to_exynos_ufs(hba);
+u32 type;
+
+type =  hci_readl(ufs, HCI_UTRL_NEXUS_TYPE);
+
+if (cmd)
+hci_writel(ufs, type | (1 << tag), HCI_UTRL_NEXUS_TYPE);
+else
+hci_writel(ufs, type & ~(1 << tag), HCI_UTRL_NEXUS_TYPE);
+}
+
+static void exynos_ufs_specify_nexus_t_tm_req(struct ufs_hba *hba,
+int tag, u8 func)
+{
+struct exynos_ufs *ufs = to_exynos_ufs(hba);
+u32 type;
+
+type =  hci_readl(ufs, HCI_UTMRL_NEXUS_TYPE);
+
+switch (func) {
+case UFS_ABORT_TASK:
+case UFS_QUERY_TASK:
+hci_writel(ufs, type | (1 << tag), HCI_UTMRL_NEXUS_TYPE);
+break;
+case UFS_ABORT_TASK_SET:
+case UFS_CLEAR_TASK_SET:
+case UFS_LOGICAL_RESET:
+case UFS_QUERY_TASK_SET:
+hci_writel(ufs, type & ~(1 << tag), HCI_UTMRL_NEXUS_TYPE);
+break;
+}
+}
+
+static void exynos_ufs_phy_init(struct exynos_ufs *ufs)
+{
+struct ufs_hba *hba = ufs->hba;
+struct exynos_ufs_phy_info *phy_info = phy_get_drvdata(ufs->phy);
+struct exynos_ufs_phy_specific_ops *phy_ops =
+phy_info->phy_specific_ops;
+
+if

Re: [PATCH v2 1/5] spi: introduce mmap read support for spi flash devices

[Michal Suchanek]

On 3 November 2015 at 11:06, Vignesh R  wrote:
> In addition to providing direct access to SPI bus, some spi controller
> hardwares (like ti-qspi) provide special memory mapped port
> to accesses SPI flash devices in order to increase read performance.
> This means the controller can automatically send the SPI signals
> required to read data from the SPI flash device.
> For this, spi controller needs to know flash specific information like
> read command to use, dummy bytes and address width. Once these settings
> are populated in hardware registers, any read accesses to flash's memory
> map region(SoC specific) through memcpy (or mem-to mem DMA copy) will be
> handled by controller hardware. The hardware will automatically generate
> SPI signals required to read data from flash and present it to CPU/DMA.
>
> Introduce spi_mtd_mmap_read() interface to support memory mapped read
> over SPI flash devices. SPI master drivers can implement this callback to
> support memory mapped read interfaces. m25p80 flash driver and other
> flash drivers can call this to request memory mapped read. The interface
> should only be used MTD flashes and cannot be used with other SPI devices.
>
> Signed-off-by: Vignesh R 
> ---
>  drivers/spi/spi.c   | 35 +++
>  include/linux/spi/spi.h | 23 +++
>  2 files changed, 58 insertions(+)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index a5f53de813d3..5a5c7a7d47f2 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1059,6 +1059,7 @@ static void __spi_pump_messages(struct spi_master 
> *master, bool in_kthread)
> }
> }
>
> +   mutex_lock(&master->mmap_lock_mutex);
> trace_spi_message_start(master->cur_msg);
>
> if (master->prepare_message) {
> @@ -1068,6 +1069,7 @@ static void __spi_pump_messages(struct spi_master 
> *master, bool in_kthread)
> "failed to prepare message: %d\n", ret);
> master->cur_msg->status = ret;
> spi_finalize_current_message(master);
> +   mutex_unlock(&master->mmap_lock_mutex);
> return;
> }
> master->cur_msg_prepared = true;
> @@ -1077,6 +1079,7 @@ static void __spi_pump_messages(struct spi_master 
> *master, bool in_kthread)
> if (ret) {
> master->cur_msg->status = ret;
> spi_finalize_current_message(master);
> +   mutex_unlock(&master->mmap_lock_mutex);
> return;
> }
>
> @@ -1084,8 +1087,10 @@ static void __spi_pump_messages(struct spi_master 
> *master, bool in_kthread)
> if (ret) {
> dev_err(&master->dev,
> "failed to transfer one message from queue\n");
> +   mutex_unlock(&master->mmap_lock_mutex);
> return;
> }
> +   mutex_unlock(&master->mmap_lock_mutex);
>  }
>
>  /**
> @@ -1732,6 +1737,7 @@ int spi_register_master(struct spi_master *master)
> spin_lock_init(&master->queue_lock);
> spin_lock_init(&master->bus_lock_spinlock);
> mutex_init(&master->bus_lock_mutex);
> +   mutex_init(&master->mmap_lock_mutex);
> master->bus_lock_flag = 0;
> init_completion(&master->xfer_completion);
> if (!master->max_dma_len)
> @@ -2237,6 +2243,35 @@ int spi_async_locked(struct spi_device *spi, struct 
> spi_message *message)
>  EXPORT_SYMBOL_GPL(spi_async_locked);
>
>
> +int spi_mtd_mmap_read(struct spi_device *spi, loff_t from, size_t len,
> + size_t *retlen, u_char *buf, u8 read_opcode,
> + u8 addr_width, u8 dummy_bytes)
> +
> +{
> +   struct spi_master *master = spi->master;
> +   int ret;
> +
> +   if (master->auto_runtime_pm) {
> +   ret = pm_runtime_get_sync(master->dev.parent);
> +   if (ret < 0) {
> +   dev_err(&master->dev, "Failed to power device: %d\n",
> +   ret);
> +   goto err;
> +   }
> +   }
> +   mutex_lock(&master->mmap_lock_mutex);
> +   ret = master->spi_mtd_mmap_read(spi, from, len, retlen, buf,
> +   read_opcode, addr_width,
> +   dummy_bytes);
> +   mutex_unlock(&master->mmap_lock_mutex);
> +   if (master->auto_runtime_pm)
> +   pm_runtime_put(master->dev.parent);
> +
> +err:
> +   return ret;
> +}
> +EXPORT_SYMBOL_GPL(spi_mtd_mmap_read);
> +
>  /*-*/
>
>  /* Utility methods for SPI master protocol drivers, layered on
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index 6b00f18f5e6b..0a6d8ad57357 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -297,6 +297,7 @@ static inline void spi_un

Re: [PATCH] dmaengine: of_dma: Correct return code for of_dma_request_slave_channel in case !CONFIG_OF

[Arnd Bergmann]

On Tuesday 03 November 2015 12:28:10 Peter Ujfalusi wrote:
> of_dma_request_slave_channel should return either pointer for valid
> dma_chan or ERR_PTR() error code, NULL is not expected to be returned.
> 
> Signed-off-by: Peter Ujfalusi 
> 

Acked-by: Arnd Bergmann 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver

[Arnd Bergmann]

On Tuesday 03 November 2015 00:29:07 Sinan Kaya wrote:
> On 11/2/2015 3:55 PM, Arnd Bergmann wrote:
> > Are you using message signaled interrupts then?
> > Typically MSI guarantees
> > ordering against DMA, but level or edge triggered interrupts by definition
> > cannot (at least on PCI, but most other buses are the same way), because
> > the DMA master has no insight into when a DMA is actually complete.
> >
> > If you use MSI, please add a comment to the readl_relaxed() that it
> > is safe because of that, otherwise the next person who tries to debug
> > a problem with your driver has to look into this.
> 
> No, using regular GIC SPI interrupts at this moment. I know that HW 
> doesn't use any of the typical AHB/AXI ARM buses.
> 
> I'm familiar with how PCI endpoints works. While the first read in a 
> typical PCI endpoint ISR flushes all outstanding requests traditionally 
> to the destination, this concept does not apply here for this HW.
> 

Ok, got it.

Best add an explanation like the above in the interrupt handler,
to prevent this from accidentally getting 'cleaned up' to use
readl(), or copied into a driver that uses PCI ordering rules
where it is actually wrong.

I think it should be done like this:

- anything that is not performance critical, use normal readl/writel
- in the fast path, add a comment to each readl_relaxed()/writel_relaxed()
  that is safe in this driver but that would not be safe in a PCI
  device
- For the ones that would be safe on PCI as weel, use
  readl_relaxed()/writel_relaxed() without a comment on each one,
  but clarify somewhere that these are all intentional.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] dmaengine: of_dma: Correct return code for of_dma_request_slave_channel in case !CONFIG_OF

[Peter Ujfalusi]

of_dma_request_slave_channel should return either pointer for valid
dma_chan or ERR_PTR() error code, NULL is not expected to be returned.

Signed-off-by: Peter Ujfalusi 
---
 include/linux/of_dma.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index 36112cdd665a..b90d8ec57c1f 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -80,7 +80,7 @@ static inline int of_dma_router_register(struct device_node 
*np,
 static inline struct dma_chan *of_dma_request_slave_channel(struct device_node 
*np,
 const char *name)
 {
-   return NULL;
+   return ERR_PTR(-ENODEV);
 }
 
 static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args 
*dma_spec,
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver

[Andy Shevchenko]

On Mon, Nov 2, 2015 at 8:07 AM, Sinan Kaya  wrote:
> The Qualcomm Technologies HIDMA device has been designed
> to support virtualization technology. The driver has been
> divided into two to follow the hardware design. The management
> driver is executed in hypervisor context and is the main
> management entity for all channels provided by the device.
> The channel driver is executed in the hypervisor/guest OS
> context.
>
> All channel devices get probed in the hypervisor
> context during power up. They show up as DMA engine
> channels. Then, before starting the virtualization; each
> channel device is unbound from the hypervisor by VFIO
> and assigned to the guest machine for control.
>
> This management driver will be used by the system
> admin to monitor/reset the execution state of the DMA
> channels. This will be the management interface.


> +static ssize_t qcom_hidma_mgmt_evtena(struct file *file,
> +   const char __user *user_buf, size_t count, loff_t *ppos)
> +{
> +   char temp_buf[16+1];

16 is a magic number. Make it defined constant.

> +   struct qcom_hidma_mgmt_dev *mgmtdev = file->f_inode->i_private;
> +   u32 event;
> +   ssize_t ret;
> +   unsigned long val;
> +
> +   temp_buf[16] = '\0';
> +   if (copy_from_user(temp_buf, user_buf, min_t(int, count, 16)))
> +   goto out;
> +
> +   ret = kstrtoul(temp_buf, 16, &val);

kstrtoul_from_user?

> +   if (ret) {
> +   dev_warn(&mgmtdev->pdev->dev, "unknown event\n");
> +   goto out;
> +   }
> +
> +   event = (u32)val & HW_EVENTS_CFG_MASK;
> +
> +   pm_runtime_get_sync(&mgmtdev->pdev->dev);
> +   writel(event, mgmtdev->dev_virtaddr + HW_EVENTS_CFG_OFFSET);
> +   pm_runtime_mark_last_busy(&mgmtdev->pdev->dev);
> +   pm_runtime_put_autosuspend(&mgmtdev->pdev->dev);
> +out:
> +   return count;
> +}
> +
> +static const struct file_operations qcom_hidma_mgmt_evtena_fops = {
> +   .write = qcom_hidma_mgmt_evtena,
> +};
> +
> +struct fileinfo {
> +   char *name;
> +   int mode;
> +   const struct file_operations *ops;
> +};
> +
> +static struct fileinfo files[] = {
> +   {"info", S_IRUGO, &qcom_hidma_mgmt_fops},
> +   {"err", S_IRUGO,  &qcom_hidma_mgmt_err_fops},
> +   {"mhiderrclr", S_IWUSR, &qcom_hidma_mgmt_mhiderr_clrfops},
> +   {"evterrclr", S_IWUSR, &qcom_hidma_mgmt_evterr_clrfops},
> +   {"ideerrclr", S_IWUSR, &qcom_hidma_mgmt_ideerr_clrfops},
> +   {"odeerrclr", S_IWUSR, &qcom_hidma_mgmt_odeerr_clrfops},
> +   {"msierrclr", S_IWUSR, &qcom_hidma_mgmt_msierr_clrfops},
> +   {"treerrclr", S_IWUSR, &qcom_hidma_mgmt_treerr_clrfops},
> +   {"evtena", S_IWUSR, &qcom_hidma_mgmt_evtena_fops},
> +};
> +
> +static void qcom_hidma_mgmt_debug_uninit(struct qcom_hidma_mgmt_dev *mgmtdev)
> +{
> +   debugfs_remove_recursive(mgmtdev->debugfs);
> +}
> +
> +static int qcom_hidma_mgmt_debug_init(struct qcom_hidma_mgmt_dev *mgmtdev)
> +{
> +   int rc = 0;
> +   u32 i;
> +   struct dentry   *fs_entry;
> +
> +   mgmtdev->debugfs = debugfs_create_dir(dev_name(&mgmtdev->pdev->dev),
> +   NULL);
> +   if (!mgmtdev->debugfs) {
> +   rc = -ENODEV;
> +   return rc;
> +   }
> +
> +   for (i = 0; i < ARRAY_SIZE(files); i++) {
> +   fs_entry = debugfs_create_file(files[i].name,
> +   files[i].mode, mgmtdev->debugfs,
> +   mgmtdev, files[i].ops);
> +   if (!fs_entry) {
> +   rc = -ENOMEM;
> +   goto cleanup;
> +   }
> +   }
> +
> +   return 0;
> +cleanup:
> +   qcom_hidma_mgmt_debug_uninit(mgmtdev);
> +   return rc;
> +}
> +#else
> +static void qcom_hidma_mgmt_debug_uninit(struct qcom_hidma_mgmt_dev *mgmtdev)
> +{
> +}
> +static int qcom_hidma_mgmt_debug_init(struct qcom_hidma_mgmt_dev *mgmtdev)
> +{
> +   return 0;
> +}
> +#endif
> +
> +static int qcom_hidma_mgmt_setup(struct qcom_hidma_mgmt_dev *mgmtdev)
> +{
> +   u32 val;
> +   u32 i;
> +
> +   val = readl(mgmtdev->dev_virtaddr + MAX_BUS_REQ_LEN_OFFSET);
> +   val = val &
> +   ~(MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS);
> +   val = val |
> +   (mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS);
> +   val = val & ~(MAX_BUS_REQ_LEN_MASK);
> +   val = val | (mgmtdev->max_read_request);
> +   writel(val, mgmtdev->dev_virtaddr + MAX_BUS_REQ_LEN_OFFSET);
> +
> +   val = readl(mgmtdev->dev_virtaddr + MAX_XACTIONS_OFFSET);
> +   val = val &
> +   ~(MAX_WR_XACTIONS_MASK << MAX_WR_XACTIONS_BIT_POS);
> +   val = val |
> +   (mgmtdev->max_wr_xactions << MAX_WR_XACTIONS_BIT_POS);
> +   val = val & ~(MAX_RD_XACTIONS_MASK);
> +   val = val | (mgmtdev->max_rd_xactions);
> +   writel(val, mgmtdev->dev_virtaddr

Re: [PATCH V2 3/3] dma: add Qualcomm Technologies HIDMA channel driver

[Andy Shevchenko]

On Mon, Nov 2, 2015 at 8:07 AM, Sinan Kaya  wrote:
> This patch adds support for hidma engine. The driver
> consists of two logical blocks. The DMA engine interface
> and the low-level interface. The hardware only supports
> memcpy/memset and this driver only support memcpy
> interface. HW and driver doesn't support slave interface.

> +/* Linux Foundation elects GPLv2 license only.
> + */

One line?

> +#include 
> +#include 
> +#include 

Do you need this one explicitly?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

+ empty line?

> +#include 

+ empty line?

> +#include "dmaengine.h"
> +#include "qcom_hidma.h"
> +
> +/* Default idle time is 2 seconds. This parameter can
> + * be overridden by changing the following
> + * /sys/bus/platform/devices/QCOM8061:/power/autosuspend_delay_ms
> + * during kernel boot.
> + */

Block comments usually like
/*
 * text
 */

> +#define AUTOSUSPEND_TIMEOUT2000
> +
> +struct hidma_lldev;
> +
> +struct hidma_dev {
> +   int evridx;
> +   u32 nr_descriptors;
> +
> +   struct hidma_lldev  *lldev;
> +   void__iomem *dev_trca;
> +   void__iomem *dev_evca;
> +
> +   /* used to protect the pending channel list*/
> +   spinlock_t  lock;
> +   struct dma_device   ddev;
> +};
> +
> +struct hidma_chan {
> +   boolpaused;
> +   boolallocated;
> +   charname[16];

So, do you need specific name? There is already one in struct dma_chan.

> +   u32 dma_sig;
> +
> +   /*
> +* active descriptor on this channel
> +* It is used by the DMA complete notification to
> +* locate the descriptor that initiated the transfer.
> +*/
> +   struct hidma_dev*dmadev;
> +
> +   struct dma_chan chan;
> +   struct list_headfree;
> +   struct list_headprepared;
> +   struct list_headactive;
> +   struct list_headcompleted;
> +
> +   /* Lock for this structure */
> +   spinlock_t  lock;
> +};
> +
> +struct hidma_desc {
> +   struct dma_async_tx_descriptor  desc;
> +   /* link list node for this channel*/
> +   struct list_headnode;
> +   u32 tre_ch;
> +};
> +
> +static inline
> +struct hidma_dev *to_hidma_dev(struct dma_device *dmadev)
> +{
> +   return container_of(dmadev, struct hidma_dev, ddev);
> +}
> +
> +static inline
> +struct hidma_dev *to_hidma_dev_from_lldev(struct hidma_lldev **_lldevp)
> +{
> +   return container_of(_lldevp, struct hidma_dev, lldev);
> +}
> +
> +static inline
> +struct hidma_chan *to_hidma_chan(struct dma_chan *dmach)
> +{
> +   return container_of(dmach, struct hidma_chan, chan);
> +}
> +
> +static inline struct hidma_desc *
> +to_hidma_desc(struct dma_async_tx_descriptor *t)
> +{
> +   return container_of(t, struct hidma_desc, desc);
> +}
> +
> +static void hidma_free(struct hidma_dev *dmadev)
> +{
> +   dev_dbg(dmadev->ddev.dev, "free dmadev\n");
> +   INIT_LIST_HEAD(&dmadev->ddev.channels);
> +}
> +
> +static unsigned int nr_desc_prm;
> +module_param(nr_desc_prm, uint, 0644);
> +MODULE_PARM_DESC(nr_desc_prm,
> +"number of descriptors (default: 0)");
> +
> +#define MAX_HIDMA_CHANNELS 64
> +static int event_channel_idx[MAX_HIDMA_CHANNELS] = {
> +   [0 ... (MAX_HIDMA_CHANNELS - 1)] = -1};
> +static unsigned int num_event_channel_idx;
> +module_param_array_named(event_channel_idx, event_channel_idx, int,
> +   &num_event_channel_idx, 0644);
> +MODULE_PARM_DESC(event_channel_idx,
> +   "event channel index array for the notifications");
> +static atomic_t channel_ref_count;
> +
> +/* process completed descriptors */
> +static void hidma_process_completed(struct hidma_dev *mdma)
> +{
> +   dma_cookie_t last_cookie = 0;
> +   struct hidma_chan *mchan;
> +   struct hidma_desc *mdesc;
> +   struct dma_async_tx_descriptor *desc;
> +   unsigned long irqflags;
> +   LIST_HEAD(list);
> +   struct dma_chan *dmach = NULL;
> +
> +   list_for_each_entry(dmach, &mdma->ddev.channels,
> +   device_node) {
> +   mchan = to_hidma_chan(dmach);
> +
> +   /* Get all completed descriptors */
> +   spin_lock_irqsave(&mchan->lock, irqflags);
> +   if (!list_empty(&mchan->completed))
> +   list_splice_tail_init(&mchan->completed, &list);
> +   

[PATCH v2 1/5] spi: introduce mmap read support for spi flash devices

[Vignesh R]

In addition to providing direct access to SPI bus, some spi controller
hardwares (like ti-qspi) provide special memory mapped port
to accesses SPI flash devices in order to increase read performance.
This means the controller can automatically send the SPI signals
required to read data from the SPI flash device.
For this, spi controller needs to know flash specific information like
read command to use, dummy bytes and address width. Once these settings
are populated in hardware registers, any read accesses to flash's memory
map region(SoC specific) through memcpy (or mem-to mem DMA copy) will be
handled by controller hardware. The hardware will automatically generate
SPI signals required to read data from flash and present it to CPU/DMA.

Introduce spi_mtd_mmap_read() interface to support memory mapped read
over SPI flash devices. SPI master drivers can implement this callback to
support memory mapped read interfaces. m25p80 flash driver and other
flash drivers can call this to request memory mapped read. The interface
should only be used MTD flashes and cannot be used with other SPI devices.

Signed-off-by: Vignesh R 
---
 drivers/spi/spi.c   | 35 +++
 include/linux/spi/spi.h | 23 +++
 2 files changed, 58 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index a5f53de813d3..5a5c7a7d47f2 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1059,6 +1059,7 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
}
}
 
+   mutex_lock(&master->mmap_lock_mutex);
trace_spi_message_start(master->cur_msg);
 
if (master->prepare_message) {
@@ -1068,6 +1069,7 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
"failed to prepare message: %d\n", ret);
master->cur_msg->status = ret;
spi_finalize_current_message(master);
+   mutex_unlock(&master->mmap_lock_mutex);
return;
}
master->cur_msg_prepared = true;
@@ -1077,6 +1079,7 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
if (ret) {
master->cur_msg->status = ret;
spi_finalize_current_message(master);
+   mutex_unlock(&master->mmap_lock_mutex);
return;
}
 
@@ -1084,8 +1087,10 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
if (ret) {
dev_err(&master->dev,
"failed to transfer one message from queue\n");
+   mutex_unlock(&master->mmap_lock_mutex);
return;
}
+   mutex_unlock(&master->mmap_lock_mutex);
 }
 
 /**
@@ -1732,6 +1737,7 @@ int spi_register_master(struct spi_master *master)
spin_lock_init(&master->queue_lock);
spin_lock_init(&master->bus_lock_spinlock);
mutex_init(&master->bus_lock_mutex);
+   mutex_init(&master->mmap_lock_mutex);
master->bus_lock_flag = 0;
init_completion(&master->xfer_completion);
if (!master->max_dma_len)
@@ -2237,6 +2243,35 @@ int spi_async_locked(struct spi_device *spi, struct 
spi_message *message)
 EXPORT_SYMBOL_GPL(spi_async_locked);
 
 
+int spi_mtd_mmap_read(struct spi_device *spi, loff_t from, size_t len,
+ size_t *retlen, u_char *buf, u8 read_opcode,
+ u8 addr_width, u8 dummy_bytes)
+
+{
+   struct spi_master *master = spi->master;
+   int ret;
+
+   if (master->auto_runtime_pm) {
+   ret = pm_runtime_get_sync(master->dev.parent);
+   if (ret < 0) {
+   dev_err(&master->dev, "Failed to power device: %d\n",
+   ret);
+   goto err;
+   }
+   }
+   mutex_lock(&master->mmap_lock_mutex);
+   ret = master->spi_mtd_mmap_read(spi, from, len, retlen, buf,
+   read_opcode, addr_width,
+   dummy_bytes);
+   mutex_unlock(&master->mmap_lock_mutex);
+   if (master->auto_runtime_pm)
+   pm_runtime_put(master->dev.parent);
+
+err:
+   return ret;
+}
+EXPORT_SYMBOL_GPL(spi_mtd_mmap_read);
+
 /*-*/
 
 /* Utility methods for SPI master protocol drivers, layered on
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 6b00f18f5e6b..0a6d8ad57357 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -297,6 +297,7 @@ static inline void spi_unregister_driver(struct spi_driver 
*sdrv)
  * @flags: other constraints relevant to this driver
  * @bus_lock_spinlock: spinlock for SPI bus locking
  * @bus_lock_mutex: mutex for SPI bus locking
+ * @mmap_lock_mutex: mutex for locking SPI bus when mmap transfer i

[PATCH v2 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Vignesh R]

Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
update the binding documents for the controller to document this change.

Signed-off-by: Vignesh R 
---
 Documentation/devicetree/bindings/spi/ti_qspi.txt | 13 +
 arch/arm/boot/dts/dra7.dtsi   |  6 --
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 601a360531a5..f05dd631bef1 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -26,3 +26,16 @@ qspi: qspi@4b30 {
spi-max-frequency = <2500>;
ti,hwmods = "qspi";
 };
+
+For dra7xx:
+qspi: qspi@4b30 {
+   compatible = "ti,dra7xxx-qspi";
+   reg = <0x4b30 0x100>, <0x4a002558 0x4>,
+ <0x5c00 0x400>;
+   reg-names = "qspi_base", "qspi_ctrlmod",
+   "qspi_mmap";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   spi-max-frequency = <4800>;
+   ti,hwmods = "qspi";
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e289c706d27d..13c2f10ec217 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1108,8 +1108,10 @@
 
qspi: qspi@4b30 {
compatible = "ti,dra7xxx-qspi";
-   reg = <0x4b30 0x100>;
-   reg-names = "qspi_base";
+   reg = <0x4b30 0x100>, <0x4a002558 0x4>,
+ <0x5c00 0x400>;
+   reg-names = "qspi_base", "qspi_ctrlmod",
+   "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/5] spi: spi-ti-qspi: add mmap mode read support

[Vignesh R]

ti-qspi controller provides mmap port to read data from SPI flashes.
mmap port is enabled in QSPI_SPI_SWITCH_REG. ctrl module register may
also need to be accessed for some SoCs. The QSPI_SPI_SETUP_REGx needs to
be populated with flash specific information like read opcode, read
mode(quad, dual, normal), address width and dummy bytes. Once,
controller is in mmap mode, the whole flash memory is available as a
memory region at SoC specific address. This region can be accessed using
normal memcpy() (or mem-to-mem dma copy). The ti-qspi controller hardware
will internally communicate with SPI flash over SPI bus and get the
requested data.

Implement spi_mtd_mmap_read() callback to support mmap read over SPI
flash devices. With this, the read throughput increases from ~100kB/s to
~2.5 MB/s.

Signed-off-by: Vignesh R 
---
 drivers/spi/spi-ti-qspi.c | 92 ---
 1 file changed, 88 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 69c1a95b0615..2f58fb7eb410 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -65,11 +65,8 @@ struct ti_qspi {
 #define QSPI_SPI_CMD_REG   (0x48)
 #define QSPI_SPI_STATUS_REG(0x4c)
 #define QSPI_SPI_DATA_REG  (0x50)
-#define QSPI_SPI_SETUP0_REG(0x54)
+#define QSPI_SPI_SETUP_REG(n)  ((0x54 + 4 * n))
 #define QSPI_SPI_SWITCH_REG(0x64)
-#define QSPI_SPI_SETUP1_REG(0x58)
-#define QSPI_SPI_SETUP2_REG(0x5c)
-#define QSPI_SPI_SETUP3_REG(0x60)
 #define QSPI_SPI_DATA_REG_1(0x68)
 #define QSPI_SPI_DATA_REG_2(0x6c)
 #define QSPI_SPI_DATA_REG_3(0x70)
@@ -109,6 +106,16 @@ struct ti_qspi {
 
 #define QSPI_AUTOSUSPEND_TIMEOUT 2000
 
+#define MEM_CS_EN(n)   ((n + 1) << 8)
+
+#define MM_SWITCH  0x1
+
+#define QSPI_SETUP_RD_NORMAL   (0x0 << 12)
+#define QSPI_SETUP_RD_DUAL (0x1 << 12)
+#define QSPI_SETUP_RD_QUAD (0x3 << 12)
+#define QSPI_SETUP_ADDR_SHIFT  8
+#define QSPI_SETUP_DUMMY_SHIFT 10
+
 static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
unsigned long reg)
 {
@@ -366,6 +373,82 @@ static int qspi_transfer_msg(struct ti_qspi *qspi, struct 
spi_transfer *t)
return 0;
 }
 
+static void ti_qspi_enable_memory_map(struct spi_device *spi)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 val;
+
+   ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
+   if (qspi->ctrl_mod) {
+   val = readl(qspi->ctrl_base);
+   val |= MEM_CS_EN(spi->chip_select);
+   writel(val, qspi->ctrl_base);
+   /* dummy readl to ensure bus sync */
+   readl(qspi->ctrl_base);
+   }
+}
+
+static void ti_qspi_disable_memory_map(struct spi_device *spi)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 val;
+
+   ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
+   if (qspi->ctrl_mod) {
+   val = readl(qspi->ctrl_base);
+   val &= ~MEM_CS_EN(spi->chip_select);
+   writel(val, qspi->ctrl_base);
+   }
+}
+
+static void ti_qspi_setup_mmap_read(struct spi_device *spi,
+   u8 read_opcode, u8 addr_width,
+   u8 dummy_bytes)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 mode = spi->mode & (SPI_RX_DUAL | SPI_RX_QUAD);
+   u32 memval = read_opcode;
+
+   switch (mode) {
+   case SPI_RX_QUAD:
+   memval |= QSPI_SETUP_RD_QUAD;
+   break;
+   case SPI_RX_DUAL:
+   memval |= QSPI_SETUP_RD_DUAL;
+   break;
+   default:
+   memval |= QSPI_SETUP_RD_NORMAL;
+   break;
+   }
+   memval |= ((addr_width - 1) << QSPI_SETUP_ADDR_SHIFT |
+  dummy_bytes << QSPI_SETUP_DUMMY_SHIFT);
+   ti_qspi_write(qspi, memval,
+ QSPI_SPI_SETUP_REG(spi->chip_select));
+}
+
+static int ti_qspi_spi_mtd_mmap_read(struct  spi_device *spi,
+loff_t from, size_t len,
+size_t *retlen, u_char *buf,
+u8 read_opcode, u8 addr_width,
+u8 dummy_bytes)
+{
+   struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
+   int ret = 0;
+
+   mutex_lock(&qspi->list_lock);
+
+   ti_qspi_enable_memory_map(spi);
+   ti_qspi_setup_mmap_read(spi, read_opcode, addr_width,
+   dummy_bytes);
+   memcpy_fromio(buf, qspi->mmap_base + from, len);
+   *retlen = len;
+   ti_qspi_disable_memory_map(spi);
+
+   mutex_unlock(&qspi->list_lock);
+
+   return ret;
+}
+
 static int ti_qspi_start_transfer_one(

[PATCH v2 5/5] ARM: dts: AM4372: add entry for qspi mmap region

[Vignesh R]

Add qspi memory mapped region entries for AM43xx based SoCs. Also,
update the binding documents for the controller to document this change.

Signed-off-by: Vignesh R 
---
 Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
 arch/arm/boot/dts/am4372.dtsi | 4 +++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index f05dd631bef1..05488970060b 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -17,9 +17,10 @@ Recommended properties:
 
 Example:
 
+For am4372:
 qspi: qspi@4b30 {
-   compatible = "ti,dra7xxx-qspi";
-   reg = <0x4790 0x100>, <0x3000 0x3ff>;
+   compatible = "ti,am4372-qspi";
+   reg = <0x4790 0x100>, <0x3000 0x400>;
reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 0447c04a40cc..1b2c545f3f2c 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -962,7 +962,9 @@
 
qspi: qspi@4790 {
compatible = "ti,am4372-qspi";
-   reg = <0x4790 0x100>;
+   reg = <0x4790 0x100>,
+ <0x3000 0x400>;
+   reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/5] mtd: devices: m25p80: add support for mmap read request

[Vignesh R]

Certain spi controllers may support memory mapped interface to read from
m25p80 type flash devices. This interface provides better read
performance than regular SPI interface.
Call spi_mtd_mmap_read() interface, if supported, to make use of
memory-mapped interface.

Signed-off-by: Vignesh R 
---
 drivers/mtd/devices/m25p80.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 9cd3631170ef..3978bcb513b9 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -133,6 +133,11 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, 
size_t len,
/* convert the dummy cycles to the number of bytes */
dummy /= 8;
 
+   if (spi_mmap_read_supported(spi))
+   return spi_mtd_mmap_read(spi, from, len, retlen, buf,
+nor->read_opcode,
+nor->addr_width, dummy);
+
spi_message_init(&m);
memset(t, 0, (sizeof t));
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] clocksource: rockchip: Make the driver more compatible

[Caesar Wang]

在 2015年11月03日 16:32, Daniel Lezcano 写道:

On 11/03/2015 03:00 AM, Caesar Wang wrote:

Daniel,

在 2015年11月03日 01:28, Daniel Lezcano 写道:

On 10/31/2015 12:47 AM, Heiko Stuebner wrote:

Hi Daniel,

Am Freitag, 30. Oktober 2015, 11:42:29 schrieb Daniel Lezcano:

On 10/30/2015 04:43 AM, Caesar Wang wrote:

Hi Daniel,

在 2015年10月01日 03:14, Heiko Stübner 写道:

Hi Daniel,

Am Dienstag, 29. September 2015, 06:18:03 schrieb Daniel Lezcano:

On 09/25/2015 04:14 AM, Caesar Wang wrote:

Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for 
rockchip.


Says:
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at  
operand

1 --
`dsb`
...

The problem was different semantics of dsb on btw arm32 and 
arm64,

Here we can convert the dsb with insteading of dsb(sy).The "sy"
param
is the default which you are allow to omit, so on arm32 dsb()and
dsb(sy)
are the same.

Signed-off-by: Caesar Wang 

Acked-by: Daniel Lezcano 

as you have "just" Acked these patches, I guess you are expecting
them
to go
through the same tree as the devicetree changes, right?


I'm wonder if someone will apply this series patchs but the wait.:-)
In fact, I'm no sure that the Acked is really meaning.:-


Yes, by acking the patch I say I am ok with it and I agree it can go
through another tree.


although I guess the two clocksource changes could very well just go
through your tree. dsb() -> dsb(sy) is supposed to be equal and the
second
one is just cosmetics.  The Kconfig and dts changes need to wait in
any case
for 4.5 ... but I guess that may be true for the clocksource changes
as well?


Heiko, Caesar,

I am wondering if the dsb() is really necessary. Is it possible you
test the timer by removing this instruction ? Otherwise I will have to
setup my board again and it will take awhile.



As the @Arnd suggestion,

That's seem ok for me.
Although the writel_relaxed() and writel() a bit different  with DSB()
and L2's sync.

Do I need send the patch v3?  I will test that on my board.

I'm no sure that why the clocksource driver didn't use the
writel_relaxed() to work.
Okay, I think we should according to the suggestion or required.


I think the patch is trivial enough I can do the change myself if you 
test the change on your side. But it would be a good practice to send 
the patch you have tested. Up to you ;)




Yup, that's also happy work.

Feel free add my test tag if you remove the dsb().
Tested-by: Caesar Wang 

Thanks your send!


Thanks !

  -- Daniel





--
Thanks,
Caesar

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/5] Add memory mapped read support for ti-qspi

[Vignesh R]

Changes since v1:
Introduce API in SPI core that MTD flash driver can call for mmap read
instead of directly calling spi-master driver callback. This API makes
sure that SPI core msg queue is locked during mmap transfers.
v1: https://lkml.org/lkml/2015/9/4/103


Cover letter:

This patch series adds support for memory mapped read port of ti-qspi.
ti-qspi has a special memory mapped port through which SPI flash
memories can be accessed directly via SoC specific memory region.

First patch adds a method to pass flash specific information like read
opcode, dummy bytes etc and to request mmap read. Second patch
implements mmap read method in ti-qspi driver. Patch 3 adapts m25p80 to
use mmap read method before trying normal SPI transfer. Patch 4 and 5
add memory map region DT entries for DRA7xx and AM43xx SoCs.

This patch series is based on the discussions here:
http://www.spinics.net/lists/linux-spi/msg04796.html

Tested on DRA74 EVM and AM437x-SK.
Read performance increases from ~100kB/s to ~2.5MB/s.


Vignesh R (5):
  spi: introduce mmap read support for spi flash devices
  spi: spi-ti-qspi: add mmap mode read support
  mtd: devices: m25p80: add support for mmap read request
  ARM: dts: DRA7: add entry for qspi mmap region
  ARM: dts: AM4372: add entry for qspi mmap region

 Documentation/devicetree/bindings/spi/ti_qspi.txt | 18 -
 arch/arm/boot/dts/am4372.dtsi |  4 +-
 arch/arm/boot/dts/dra7.dtsi   |  6 +-
 drivers/mtd/devices/m25p80.c  |  5 ++
 drivers/spi/spi-ti-qspi.c | 92 ++-
 drivers/spi/spi.c | 35 +
 include/linux/spi/spi.h   | 23 ++
 7 files changed, 174 insertions(+), 9 deletions(-)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

[Pavel Fedin]

This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.

With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.

This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html

Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.

v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
  "reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation

v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
  to cleary specify dependency. If configuration fails, error will be reported
  and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.

v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now

v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation

Pavel Fedin (4):
  Documentation: dt-bindings: Describe SROMc configuration
  ARM: dts: Add SROMc to Exynos 5410
  drivers: exynos-srom: Add support for bank configuration
  ARM: dts: Add Ethernet chip to SMDK5410

 .../bindings/arm/samsung/exynos-srom.txt   | 68 +-
 arch/arm/boot/dts/exynos5410-smdk5410.dts  | 40 +
 arch/arm/boot/dts/exynos5410.dtsi  | 11 
 arch/arm/mach-exynos/Kconfig   |  2 +-
 drivers/soc/samsung/Kconfig|  2 +-
 drivers/soc/samsung/exynos-srom.c  | 60 ++-
 6 files changed, 177 insertions(+), 6 deletions(-)

-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Kim, Milo]

On 11/3/2015 5:33 PM, Lee Jones wrote:

On Tue, 03 Nov 2015, Kim, Milo wrote:


Hi Lee,

On 11/2/2015 5:59 PM, Lee Jones wrote:

  drivers/video/backlight/Kconfig|  62 ++

  drivers/video/backlight/Makefile   |   7 +
  drivers/video/backlight/lm3532_bl.c| 183 +
  drivers/video/backlight/lm3631_bl.c| 129 
  drivers/video/backlight/lm3632_bl.c| 125 
  drivers/video/backlight/lm3633_bl.c| 210 ++
  drivers/video/backlight/lm3695_bl.c|  91 +++
  drivers/video/backlight/lm3697_bl.c| 187 +
  drivers/video/backlight/ti-lmu-backlight.c | 429 
  drivers/video/backlight/ti-lmu-backlight.h | 152 +

How different are all of these drivers?

Can you create one driver that supports them all instead?



Thanks for your suggestion.

'ti-lmu-backlight' is the common part of lm_bl drivers. And each
lmxxx_bl has its own operation functions by using ti_lmu_bl_ops.
I've tried to make consolidated driver but it contained too much
device specific code in one file. So I prefer simple drivers
structure - 'common part' and 'device specific operations'.
It would be appreciated if you could introduce better idea.


I wish to avoid having to apply the patches to conduct my own analysis
of the files, as I am severely restricted on time.  Can you tell me how
much duplicated code there is between the files?  How many lines would
be saved by supporting all of the lm* drivers in a single file?



Understood. Let me try it again. I'll get back to you soon.
Thanks for your help.

Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/4] drivers: exynos-srom: Add support for bank configuration

[Pavel Fedin]

Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.

Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.

Signed-off-by: Pavel Fedin 
---
 arch/arm/mach-exynos/Kconfig  |  2 +-
 drivers/soc/samsung/Kconfig   |  2 +-
 drivers/soc/samsung/exynos-srom.c | 60 +--
 3 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
-   select EXYNOS_SROM if PM
+   select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
 
 config EXYNOS_SROM
bool
-   depends on ARM && ARCH_EXYNOS && PM
+   depends on ARM && ARCH_EXYNOS
 
 endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c 
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..49b5c9e 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -67,11 +68,50 @@ static struct exynos_srom_reg_dump 
*exynos_srom_alloc_reg_dump(
return rd;
 }
 
+static int decode_sromc(struct exynos_srom *srom, struct device_node *np)
+{
+   u32 bank, width, pmc;
+   u32 timing[6];
+   u32 cs, bw;
+
+   if (of_property_read_u32(np, "reg", &bank))
+   return -EINVAL;
+   if (of_property_read_u32(np, "reg-io-width", &width))
+   width = 1;
+   if (of_property_read_u32(np, "samsung,srom-page-mode", &pmc))
+   pmc = 0;
+   if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+  ARRAY_SIZE(timing)))
+   return -EINVAL;
+
+   bank *= 4; /* Convert bank into shift/offset */
+
+   cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+   if (width == 2)
+   cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+   bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+   bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+   __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+   __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+   (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+   (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+   (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+   (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+   (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+   (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+   srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+   return 0;
+}
+
 static int exynos_srom_probe(struct platform_device *pdev)
 {
-   struct device_node *np;
+   struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = &pdev->dev;
+   bool error = false;
 
np = dev->of_node;
if (!np) {
@@ -100,7 +140,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
-   return 0;
+   for_each_child_of_node(np, child) {
+   if (decode_sromc(srom, child)) {
+   dev_err(dev,
+   "Could not decode bank configuration for %s\n",
+   child->name);
+   error = true;
+   }
+   }
+
+   /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+   if (error)
+   return 0;
+
+   return of_platform_populate(np, NULL, NULL, dev);
 }
 
 static int exynos_srom_remove(struct platform_device *pdev)
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/4] ARM: dts: Add Ethernet chip to SMDK5410

[Pavel Fedin]

The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.

Signed-off-by: Pavel Fedin 
---
 arch/arm/boot/dts/exynos5410-smdk5410.dts | 40 +++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts 
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..f41952f 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -61,6 +61,27 @@
disable-wp;
 };
 
+&pinctrl_0 {
+   srom_ctl: srom-ctl {
+   samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+  "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+   samsung,pin-function = <2>;
+   samsung,pin-drv = <0>;
+   };
+
+   srom_ebi: srom-ebi {
+   samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+  "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+  "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+  "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+  "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+  "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
+};
+
 &uart0 {
status = "okay";
 };
@@ -72,3 +93,22 @@
 &uart2 {
status = "okay";
 };
+
+&sromc {
+   pinctrl-names = "default";
+   pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+   ethernet@3 {
+   compatible = "smsc,lan9115";
+   reg = <3 0 0x1>;
+   phy-mode = "mii";
+   interrupt-parent = <&gpx0>;
+   interrupts = <5 8>;
+   reg-io-width = <2>;
+   smsc,irq-push-pull;
+   smsc,force-internal-phy;
+
+   samsung,srom-page-mode = <1>;
+   samsung,srom-timing = <9 12 1 9 1 1>;
+   };
+};
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/4] ARM: dts: Add SROMc to Exynos 5410

[Pavel Fedin]

This machine uses own SoC device tree file, add missing part.
We insert the complete description, with ranges, because we are going to
connect devices to it. Values in ranges are SoC-specific, so they go here
in order not to duplicate them for every machine.

Signed-off-by: Pavel Fedin 
---
 arch/arm/boot/dts/exynos5410.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,17 @@
reg = <0x1000 0x100>;
};
 
+   sromc: sromc@1225 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1225 0x14>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
+   };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Pavel Fedin]

Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.

Signed-off-by: Pavel Fedin 
---
 .../bindings/arm/samsung/exynos-srom.txt   | 68 +-
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..ee378ca 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,72 @@ Required properties:
 
 - reg: offset and length of the register set
 
-Example:
+- #address-cells: Must be set to 2 to allow memory address translation
+
+- #size-cells: Must be set to 1 to allow CS address passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0  
+
+Sub-nodes:
+The SROM controller can be used to attach external peripherials. In this case
+device nodes should be added as subnodes to the SROMc node. These subnodes,
+except regular device specification, should contain the following properties,
+describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+   the memory mapped for the device. Note that base address will be
+   typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles (0 - 15) and has the
+following meaning:
+Tacp : Page mode access cycle at Page mode
+Tcah : Address holding time after CSn
+Tcoh : Chip selection hold on OEn
+Tacc : Access cycle
+Tcos : Chip selection set-up before OEn
+Tacs : Address set-up before CSn
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is 
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+  0 - normal (one data)
+  1 - four data
+  If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+   sromc@1257 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1257 0x14>;
+   };
+
+Example: SROMc with smsc 911x ethernet chip on bank 3
sromc@1257 {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0 0 0x0400 0x2   // Bank0
+ 1 0 0x0500 0x2   // Bank1
+ 2 0 0x0600 0x2   // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
-   reg = <0x1257 0x10>;
+   reg = <0x1257 0x14>;
+
+   ethernet@3 {
+   compatible = "smsc,lan9115";
+   reg = <3 0 0x1>;   // Bank 3, offset = 0
+   phy-mode = "mii";
+   interrupt-parent = <&gpx0>;
+   interrupts = <5 8>;
+   reg-io-width = <2>;
+   smsc,irq-push-pull;
+   smsc,force-internal-phy;
+
+   samsung,srom-config = <1 9 12 1 9 1 1>;
+   };
};
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[LABBE Corentin]

On Tue, Nov 03, 2015 at 01:52:05PM +0800, Zain Wang wrote:
> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher
> mode.
> The names registered are:
> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
> You can alloc tags above in your case.
> 
> And other algorithms and platforms will be added later on.
> 
> Signed-off-by: Zain Wang 
> ---
>  drivers/crypto/Kconfig |  11 +
>  drivers/crypto/Makefile|   1 +
>  drivers/crypto/rockchip/Makefile   |   3 +
>  drivers/crypto/rockchip/rk3288_crypto.c| 383 
>  drivers/crypto/rockchip/rk3288_crypto.h| 290 
>  drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 501 
> +
>  6 files changed, 1189 insertions(+)
>  create mode 100644 drivers/crypto/rockchip/Makefile
>  create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
>  create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
>  create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
> 
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 2569e04..d1e42cf 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -498,4 +498,15 @@ config CRYPTO_DEV_SUN4I_SS
> To compile this driver as a module, choose M here: the module
> will be called sun4i-ss.
>  
> +config CRYPTO_DEV_ROCKCHIP
> + tristate "Rockchip's Cryptographic Engine driver"
> +
> + select CRYPTO_AES
> + select CRYPTO_DES
> + select CRYPTO_BLKCIPHER
> +
> + help
> +   This driver interfaces with the hardware crypto accelerator.
> +   Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
> +
>  endif # CRYPTO_HW
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index c3ced6f..713de9d 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>  obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>  obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
> +obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
> diff --git a/drivers/crypto/rockchip/Makefile 
> b/drivers/crypto/rockchip/Makefile
> new file mode 100644
> index 000..7051c6c
> --- /dev/null
> +++ b/drivers/crypto/rockchip/Makefile
> @@ -0,0 +1,3 @@
> +obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o
> +rk_crypto-objs := rk3288_crypto.o \
> +   rk3288_crypto_ablkcipher.o \
> diff --git a/drivers/crypto/rockchip/rk3288_crypto.c 
> b/drivers/crypto/rockchip/rk3288_crypto.c
> new file mode 100644
> index 000..02830f2
> --- /dev/null
> +++ b/drivers/crypto/rockchip/rk3288_crypto.c
> @@ -0,0 +1,383 @@
> +/*
> + *Crypto acceleration support for Rockchip RK3288
> + *
> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Author: Zain Wang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * Some ideas are from marvell-cesa.c and s5p-sss.c driver.
> + */
> +
> +#include "rk3288_crypto.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct crypto_info_t *crypto_p;
> +
> +static int rk_crypto_enable_clk(struct crypto_info_t *dev)
> +{
> + int err;
> +
> + err = clk_prepare_enable(dev->sclk);
> + if (err) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'sclk'\n",
> + __func__, __LINE__);
> + goto err_return;
> + }
> + err = clk_prepare_enable(dev->aclk);
> + if (err) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
> + __func__, __LINE__);
> + goto err_aclk;
> + }
> + err = clk_prepare_enable(dev->hclk);
> + if (err) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
> + __func__, __LINE__);
> + goto err_hclk;
> + }
> +
> + err = clk_prepare_enable(dev->dmaclk);
> + if (err) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'dmaclk'\n",
> + __func__, __LINE__);
> + goto err_dmaclk;
> + }
> + return err;
> +err_dmaclk:
> + clk_disable_unprepare(dev->hclk);
> +err_hclk:
> + clk_disable_unprepare(dev->aclk);
> +err_aclk:
> + clk_disable_unprepare(dev->sclk);
> +err_return:
> + return err;
> +}
> +
> +static void rk_crypto_disable_clk(struct crypto_info_t *dev)
> +{
> + clk_disable_unprepare(dev->dmaclk);
> + clk_disable_unprepare(dev->hclk);
> + clk_disable_unprepare(dev->aclk);
> + clk_disable_unprepare(dev->sclk);
> +}
> +
> +static int check_alignment(struct scatterlist *sg_src,
> +  

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Lee Jones]

On Tue, 03 Nov 2015, Kim, Milo wrote:

> Hi Lee,
> 
> On 11/2/2015 6:00 PM, Lee Jones wrote:
> >Is it just me, or have you missed lots of people off Cc?
> 
> Ah, that's what I was hesitating...
> What is the best way to submit MFD code patches? Cc for all people
> from get_maintainer.pl?

As this is a 0th patch of a set which touches many different
subsystems, I suggest that you should have Cc'ed all of the
Maintainers of the subsystems you changed.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Lee Jones]

On Tue, 03 Nov 2015, Kim, Milo wrote:

> Hi Lee,
> 
> On 11/2/2015 5:59 PM, Lee Jones wrote:
> >>  drivers/video/backlight/Kconfig|  62 ++
> >>>  drivers/video/backlight/Makefile   |   7 +
> >>>  drivers/video/backlight/lm3532_bl.c| 183 +
> >>>  drivers/video/backlight/lm3631_bl.c| 129 
> >>>  drivers/video/backlight/lm3632_bl.c| 125 
> >>>  drivers/video/backlight/lm3633_bl.c| 210 ++
> >>>  drivers/video/backlight/lm3695_bl.c|  91 +++
> >>>  drivers/video/backlight/lm3697_bl.c| 187 +
> >>>  drivers/video/backlight/ti-lmu-backlight.c | 429 
> >>>  drivers/video/backlight/ti-lmu-backlight.h | 152 +
> >How different are all of these drivers?
> >
> >Can you create one driver that supports them all instead?
> >
> 
> Thanks for your suggestion.
> 
> 'ti-lmu-backlight' is the common part of lm_bl drivers. And each
> lmxxx_bl has its own operation functions by using ti_lmu_bl_ops.
> I've tried to make consolidated driver but it contained too much
> device specific code in one file. So I prefer simple drivers
> structure - 'common part' and 'device specific operations'.
> It would be appreciated if you could introduce better idea.

I wish to avoid having to apply the patches to conduct my own analysis
of the files, as I am severely restricted on time.  Can you tell me how
much duplicated code there is between the files?  How many lines would
be saved by supporting all of the lm* drivers in a single file?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] clocksource: rockchip: Make the driver more compatible

[Daniel Lezcano]

On 11/03/2015 03:00 AM, Caesar Wang wrote:

Daniel,

在 2015年11月03日 01:28, Daniel Lezcano 写道:

On 10/31/2015 12:47 AM, Heiko Stuebner wrote:

Hi Daniel,

Am Freitag, 30. Oktober 2015, 11:42:29 schrieb Daniel Lezcano:

On 10/30/2015 04:43 AM, Caesar Wang wrote:

Hi Daniel,

在 2015年10月01日 03:14, Heiko Stübner 写道:

Hi Daniel,

Am Dienstag, 29. September 2015, 06:18:03 schrieb Daniel Lezcano:

On 09/25/2015 04:14 AM, Caesar Wang wrote:

Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.

Says:
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand
1 --
`dsb`
...

The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).The "sy"
param
is the default which you are allow to omit, so on arm32 dsb()and
dsb(sy)
are the same.

Signed-off-by: Caesar Wang 

Acked-by: Daniel Lezcano 

as you have "just" Acked these patches, I guess you are expecting
them
to go
through the same tree as the devicetree changes, right?


I'm wonder if someone will apply this series patchs but the wait.:-)
In fact, I'm no sure that the Acked is really meaning.:-


Yes, by acking the patch I say I am ok with it and I agree it can go
through another tree.


although I guess the two clocksource changes could very well just go
through your tree. dsb() -> dsb(sy) is supposed to be equal and the
second
one is just cosmetics.  The Kconfig and dts changes need to wait in
any case
for 4.5 ... but I guess that may be true for the clocksource changes
as well?


Heiko, Caesar,

I am wondering if the dsb() is really necessary. Is it possible you
test the timer by removing this instruction ? Otherwise I will have to
setup my board again and it will take awhile.



As the @Arnd suggestion,

That's seem ok for me.
Although the writel_relaxed() and writel() a bit different  with DSB()
and L2's sync.

Do I need send the patch v3?  I will test that on my board.

I'm no sure that why the clocksource driver didn't use the
writel_relaxed() to work.
Okay, I think we should according to the suggestion or required.


I think the patch is trivial enough I can do the change myself if you 
test the change on your side. But it would be a good practice to send 
the patch you have tested. Up to you ;)


Thanks !

  -- Daniel


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v5 0/3] NAND support for Broadcom NS2 SoC

[Anup Patel]

+Arnd, +Olof

Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] nvmem: NXP LPC18xx EEPROM memory NVMEM driver

[Stefan Wahren]

Hi Ariel,

Am 19.10.2015 um 19:32 schrieb Ariel D'Alessandro:
> This commit adds support for NXP LPC18xx EEPROM memory found in NXP
> LPC185x/3x and LPC435x/3x/2x/1x devices.
>
> EEPROM size is 16384 bytes and it can be entirely read and
> written/erased with 1 word (4 bytes) granularity. The last page
> (128 bytes) contains the EEPROM initialization data and is not writable.
>
> Erase/program time is less than 3ms. The EEPROM device requires a
> ~1500 kHz clock (min 800 kHz, max 1600 kHz) that is generated dividing
> the system bus clock by the division factor, contained in the divider
> register (minus 1 encoded).
>
> Signed-off-by: Ariel D'Alessandro 
> ---
>  drivers/nvmem/Kconfig  |   9 ++
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/lpc18xx_eeprom.c | 266 
> +
>  3 files changed, 277 insertions(+)
>  create mode 100644 drivers/nvmem/lpc18xx_eeprom.c
> [...]
> +
> +static int lpc18xx_eeprom_gather_write(void *context, const void *reg,
> +size_t reg_size, const void *val,
> +size_t val_size)
> +{
> + struct lpc18xx_eeprom_dev *eeprom = context;
> + unsigned int offset = *(u32 *)reg;
> +
> + /* 3 ms of erase/program time between each writing */
> + while (val_size) {
> + writel(*(u32 *)val, eeprom->mem_base + offset);
> + usleep_range(3000, 4000);

i think it would be good to verify that the EEPROM write operation has
really finished.

Best regards
Stefan

> + val_size -= eeprom->val_bytes;
> + val += eeprom->val_bytes;
> + offset += eeprom->val_bytes;
> + }
> +
> + return 0;
> +}



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 0/6] arm64: Simple additions to NS2 DT

[Anup Patel]

+Arnd, +Olof

Ping?

Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html