RE: [PATCH v4 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
> -Original Message-
> From: Anup Patel [mailto:anup.pa...@broadcom.com]
> Sent: 30 October 2015 11:49
> To: David Woodhouse; Brian Norris; Linux MTD
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Catalin Marinas; Will Deacon;
> Sudeep Holla; Ian Campbell; Kumar Gala; Ray Jui; Scott Branden; Florian
> Fainelli;
> Pramod Kumar; Vikram Prakash; Sandeep Tripathy; Linux ARM Kernel; Device
> Tree; Linux Kernel; bcm-kernel-feedback-list; Anup Patel
> Subject: [PATCH v4 2/3] mtd: brcmnand: Force 8bit mode before doing
> nand_scan_ident()
>
> Just like other NAND controllers, the NAND READID command only works in 8bit
> mode for all versions of BRCMNAND controller.
>
> This patch forces 8bit mode for each NAND CS in brcmnand_init_cs() before
> doing nand_scan_ident() to ensure that BRCMNAND controller is in 8bit mode
> when NAND READID command is issued.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Ray Jui
> Reviewed-by: Scott Branden
> ---
> drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index dda96fa..641591d 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1912,6 +1912,7 @@ static int brcmnand_init_cs(struct brcmnand_host
> *host)
> struct mtd_info *mtd;
> struct nand_chip *chip;
> int ret;
> + u16 cfg_offs;
> struct mtd_part_parser_data ppdata = { .of_node = dn };
>
> ret = of_property_read_u32(dn, "reg", &host->cs); @@ -1954,6
> +1955,15 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
>
> chip->controller = &ctrl->controller;
>
> + /*
> + * The bootloader might have configured 16bit mode but
> + * NAND READID command only works in 8bit mode. We force
> + * 8bit mode here to ensure that NAND READID commands works.
> + */
> + cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
> + nand_writereg(ctrl, cfg_offs,
> + nand_readreg(ctrl, cfg_offs) & CFG_BUS_WIDTH);
This should have been "nand_readreg(ctrl, cfg_offs) & ~CFG_BUS_WIDTH".
My bad ...
--
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
[PATCH v5 0/3] NAND support for Broadcom NS2 SoC
We enable NAND support for Broadcom NS2 SoC by reusing existing BRCMNAND driver. This patchset applies on-top of "arm64: Simple additions to NS2 DT" v1 patchset and is available in ns2_nand_v5 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Changes since v4: - Fix accidental typo in patch2 regarding use of CFG_BUS_WIDTH Changes since v3: - Include Brian's patch for magic number cleanup related to CFG and CFG_EXT registers - Base patch1 of v3 patchset upon Brian's cleanup patch Changes since v2: - Dropped patch1 and patch2 because these are already merged by MTD maintainer. - Avoid using absolute node paths in ns2-svk.dts. Changes since v1: - Dropped patch3 and patch4 because we don't need to reset BRCMNAND controller for NS2. - Added patch to force 8bit mode before doing nand_scan_ident() in brcmnand_init_cs(). Anup Patel (2): mtd: brcmnand: Force 8bit mode before doing nand_scan_ident() arm64: dts: Add BRCM IPROC NAND DT node for NS2 Brian Norris (1): mtd: brcmnand: factor out CFG and CFG_EXT bitfields arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 +--- arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++ drivers/mtd/nand/brcmnand/brcmnand.c | 48 +++- 3 files changed, 75 insertions(+), 17 deletions(-) -- 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 v4 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> > Add documentation for new subnode properties, allowing bank configuration.
> > Based on u-boot implementation, but heavily reworked.
>
> Please, carefully look at:
> Documentation/devicetree/bindings/net/gpmc-eth.txt
> Documentation/devicetree/bindings/bus/ti-gpmc.txt
Thank you very much. Indeed, this looks very similar. By the way, should i
document smsc over sromc in the same manner, writing
devicetree/bindings/net/sromc-eth.txt?
This is a short reply for now, i'll make longer one (or just a new version)
after studying these existing bindings and trying to
apply them.
Pankaj:
> > +&sromc {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
> > +
> > + ethernet@0700 {
> > + compatible = "smsc,lan9115";
> > + reg = <0x0700 0x1>;
> > + phy-mode = "mii";
> > + interrupt-parent = <&gpx0>;
> > + interrupts = <5 8>;
> > + reg-io-width = <2>;
> > + smsc,irq-push-pull;
> > + smsc,force-internal-phy;
> > +
> > + samsung,srom-bank = <3>;
> > + samsung,srom-data-width = <2>;
> > + samsung,srom-timing = <1 9 12 1 9 1 1>;
>
> I think this is not correct. We can't change binding of "smsc,lan9115"
> which is already documented here [1]. These samsung specific srom
> properties should be in srom node or its subnode, but not in this way.
So, if you look at gpmc-eth.txt, you'll see that this approach is perfectly
valid (this is a reply to another msg, just don't want
to post one more single-line reply).
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 0/3] NAND support for Broadcom NS2 SoC
Hi All, Please disregard this patchset. There is an accidental typo in patch2. We should use ~CFG_BUS_WIDTH instead of CFG_BUS_WIDTH in patch2. I will quickly send v5 patchset to fix this. Sorry, for the noise. 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 v4 0/4] [PATCH v4 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
Hello! > > .../bindings/arm/samsung/exynos-srom.txt | 50 ++- > > arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++ > > arch/arm/boot/dts/exynos5410.dtsi | 15 ++ > > arch/arm/mach-exynos/Kconfig | 2 +- > > drivers/soc/samsung/Kconfig| 2 +- > > drivers/soc/samsung/exynos-srom.c | 58 > > +- > > 6 files changed, 162 insertions(+), 6 deletions(-) > > > > Something wrong here, I am not able to find V4 1/4 and 3/4 in this mailing > list. Which mailing list is "this"? I've just rechecked, i've got my messages back on both (linux-samsung-soc and linux-arm-kernel). Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 2/4] ARM: dts: Add SROMc to Exynos 5410
Hello!
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org
> [mailto:linux-samsung-soc-ow...@vger.kernel.org]
> On Behalf Of Pankaj Dubey
> Sent: Thursday, October 29, 2015 8:28 PM
> To: Pavel Fedin
> Cc: devicetree@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-samsung-soc;
> linux-ker...@vger.kernel.org; Rob Herring; Pawel Moll; Mark Rutland; Ian
> Campbell; Kumar Gala;
> Kukjin Kim; Krzysztof Kozlowski
> Subject: Re: [PATCH v4 2/4] ARM: dts: Add SROMc to Exynos 5410
>
> Hi Pavel,
>
> On 29 October 2015 at 18:12, Pavel Fedin wrote:
> > This machine uses own SoC device tree file, add missing part.
> >
> > Signed-off-by: Pavel Fedin
> > ---
> > arch/arm/boot/dts/exynos5410.dtsi | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos5410.dtsi
> > b/arch/arm/boot/dts/exynos5410.dtsi
> > index 4603356..da6a8fa0e 100644
> > --- a/arch/arm/boot/dts/exynos5410.dtsi
> > +++ b/arch/arm/boot/dts/exynos5410.dtsi
> > @@ -101,6 +101,15 @@
> > reg = <0x1000 0x100>;
> > };
> >
> > + sromc: sromc@1225 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
>
> We do not need to specify these three properties as they are already
> present in parent node "soc".
We do, otherwise dtc complains about defaults of #address-cells = 2 and
#size-cells=1, and without empty "ranges" subnode's resources are not correctly
translated.
>
> > + compatible = "samsung,exynos-srom";
> > + reg = <0x1225 0x14>;
> > + };
> > +
> > pmu_system_controller: system-controller@1004 {
> > compatible = "samsung,exynos5410-pmu", "syscon";
> > reg = <0x1004 0x5000>;
> > @@ -133,6 +142,12 @@
> > <10 &gic 0 130 0>,
> > <11 &gic 0 131 0>;
> > };
> > +
> > + arch_timer {
> > + compatible = "arm,armv7-timer";
> > + clock-frequency = <2400>;
> > + };
> > +
>
> This change should not be part of this patch.
Ooops, thank you very much, this should not have been here at all. This is a
leftover from my experiments, i was tracing DT parsing code and added it just
for test, to see why timer gets probed as a subnode.
Just forgot to remove it afterwards and it slipped into the patch.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 1/4] Documentation: dt-bindings: Describe SROMc configuration
On 29.10.2015 21:42, Pavel Fedin wrote:
> Add documentation for new subnode properties, allowing bank configuration.
> Based on u-boot implementation, but heavily reworked.
Please, carefully look at:
Documentation/devicetree/bindings/net/gpmc-eth.txt
Documentation/devicetree/bindings/bus/ti-gpmc.txt
1. Try to re-use existing bindings. Although I see existing bank-width
and gpmc,device-width but yours samsung,srom-data-width seems better.
Maybe there are other to re-use?
2. The array of "PMC, Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs" is poorly
extendable and not very descriptive/readable. You mapped directly device
register which is the easier way for the driver but that is not the
purpose of binding.
3. Please provide ranges for valid values and units.
4. PMC is not a timing.
I doubt that TI GPMC could be used in Exynos SROM but please look at it
and get useful stuff from it.
Best regards,
Krzysztof
>
> Signed-off-by: Pavel Fedin
> ---
> .../bindings/arm/samsung/exynos-srom.txt | 50
> +-
> 1 file changed, 48 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..02ecc7f 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> @@ -5,8 +5,54 @@ Required properties:
>
> - reg: offset and length of the register set
>
> -Example:
> +- #address-cells, #size-cells : should be '1' if the device has sub-nodes
> + with 'reg' property.
> +- ranges: allows valid 1:1 translation between child's address space and
> + parent's address space
> +
> +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:
> +- samsung,srom-bank : bank number (0 - 3)
> +
> +- samsung,srom-timing : array of 7 integers: PMC, Tacp, Tcah, Tcoh, Tacc,
> Tcos,
> + Tacs
> +
> +Optional properties:
> +- samsung,srom-data-width : data width in bytes (1 or 2). If omitted, default
> + of 1 is used.
> +
> +Example: basic definition, no banks are configured
> sromc@1257 {
> compatible = "samsung,exynos-srom";
> - reg = <0x1257 0x10>;
> + reg = <0x1257 0x14>;
> + };
> +
> +Example: SROMc with smsc 911x ethernet chip on bank 3
> + sromc@1257 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + compatible = "samsung,exynos-srom";
> + reg = <0x1257 0x14>;
> +
> + ethernet@0700 {
> + compatible = "smsc,lan9115";
> + reg = <0x0700 0x1>;
> + phy-mode = "mii";
> + interrupt-parent = <&gpx0>;
> + interrupts = <5 8>;
> + reg-io-width = <2>;
> + smsc,irq-push-pull;
> + smsc,force-internal-phy;
> +
> + samsung,srom-bank = <3>;
> + samsung,srom-data-width = <2>;
> + samsung,srom-timing = <1 9 12 1 9 1 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 v5 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
From: Thomas Abraham Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators. This also supports RTC and three 32.768KHz clock outputs. Cc: devicetree@vger.kernel.org Signed-off-by: Thomas Abraham Signed-off-by: Alim Akhtar --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 890f0b0e1643..4c0543ceec25 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic" - or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic". +- compatible: Should be one of the following + - "samsung,s2mps11-pmic" + - "samsung,s2mps13-pmic" + - "samsung,s2mps14-pmic" + - "samsung,s2mps15-pmic" + - "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -24,7 +28,7 @@ Optional properties: unwanted buck warm reset (setting buck voltages to default values). Optional nodes: -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768 +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz outputs, so to register these as clocks with common clock framework instantiate a sub-node named "clocks". It uses the common clock binding documented in : @@ -37,12 +41,13 @@ Optional nodes: the clock which they consume. Clock ID Devices -- -32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767 -32KhzCP1S2MPS11, S2MPS13, S5M8767 -32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767 +32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 +32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767 +32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", "samsung,s2mps14-clk", "samsung,s5m8767-clk" +The s2msp15 uses the same compatible as s2mps13, as both provides similar clocks. - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -90,6 +95,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 38 - S2MPS13: 1 to 40 - S2MPS14: 1 to 25 + - S2MPS15: 1 to 27 - S2MPU02: 1 to 28 - Example: LDO1, LDO2, LDO28 - BUCKn @@ -97,6 +103,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 10 - S2MPS13: 1 to 10 - S2MPS14: 1 to 5 + - S2MPS15: 1 to 10 - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 -- 1.7.10.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 v4 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.
This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index dda96fa..641591d 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1912,6 +1912,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+ u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
ret = of_property_read_u32(dn, "reg", &host->cs);
@@ -1954,6 +1955,15 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
chip->controller = &ctrl->controller;
+ /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+ cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+ nand_writereg(ctrl, cfg_offs,
+ nand_readreg(ctrl, cfg_offs) & CFG_BUS_WIDTH);
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
--
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 v4 0/3] NAND support for Broadcom NS2 SoC
We enable NAND support for Broadcom NS2 SoC by reusing existing BRCMNAND driver. This patchset applies on-top of "arm64: Simple additions to NS2 DT" v1 patchset and is available in ns2_nand_v4 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Changes since v3: - Include Brian's patch for magic number cleanup related to CFG and CFG_EXT registers - Base patch1 of v3 patchset upon Brian's cleanup patch Changes since v2: - Dropped patch1 and patch2 because these are already merged by MTD maintainer. - Avoid using absolute node paths in ns2-svk.dts. Changes since v1: - Dropped patch3 and patch4 because we don't need to reset BRCMNAND controller for NS2. - Added patch to force 8bit mode before doing nand_scan_ident() in brcmnand_init_cs(). Anup Patel (2): mtd: brcmnand: Force 8bit mode before doing nand_scan_ident() arm64: dts: Add BRCM IPROC NAND DT node for NS2 Brian Norris (1): mtd: brcmnand: factor out CFG and CFG_EXT bitfields arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 +--- arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++ drivers/mtd/nand/brcmnand/brcmnand.c | 48 +++- 3 files changed, 75 insertions(+), 17 deletions(-) -- 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 v4 3/3] arm64: dts: Add BRCM IPROC NAND DT node for NS2
The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.
This patch also fixes use of node labels in ns2-svk.dts.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Brian Norris
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..6bb3d4d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -50,18 +50,28 @@
device_type = "memory";
reg = <0x0 0x8000 0x 0x4000>;
};
+};
- soc: soc {
- i2c0: i2c@6608 {
- status = "ok";
- };
+&i2c0 {
+ status = "ok";
+};
- i2c1: i2c@660b {
- status = "ok";
- };
+&i2c1 {
+ status = "ok";
+};
+
+&uart3 {
+ status = "ok";
+};
- uart3: serial@6613 {
- status = "ok";
- };
+&nand {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ #address-cells = <1>;
+ #size-cells = <1>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+ nand: nand@6646 {
+ compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+ reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+ reg-names = "nand", "iproc-idm", "iproc-ext";
+ interrupts = ;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcm,nand-has-wp;
+ };
};
};
--
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 v4 1/3] mtd: brcmnand: factor out CFG and CFG_EXT bitfields
From: Brian Norris
Use enum instead of magic numbers for CFG and CFG_EXT bitfields.
Signed-off-by: Brian Norris
Tested-by: Anup Patel
---
drivers/mtd/nand/brcmnand/brcmnand.c | 38 +---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..dda96fa 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -344,6 +344,28 @@ static const u8 brcmnand_cs_offsets_cs0[] = {
[BRCMNAND_CS_TIMING2] = 0x14,
};
+/*
+ * Bitfields for the CFG and CFG_EXT registers. Pre-v7.1 controllers only had
+ * one config register, but once the bitfields overflowed, newer controllers
+ * (v7.1 and newer) added a CFG_EXT register and shuffled a few fields around.
+ */
+enum {
+ CFG_BLK_ADR_BYTES_SHIFT = 8,
+ CFG_COL_ADR_BYTES_SHIFT = 12,
+ CFG_FUL_ADR_BYTES_SHIFT = 16,
+ CFG_BUS_WIDTH_SHIFT = 23,
+ CFG_BUS_WIDTH = BIT(CFG_BUS_WIDTH_SHIFT),
+ CFG_DEVICE_SIZE_SHIFT = 24,
+
+ /* Only for pre-v7.1 (with no CFG_EXT register) */
+ CFG_PAGE_SIZE_SHIFT = 20,
+ CFG_BLK_SIZE_SHIFT = 28,
+
+ /* Only for v7.1+ (with CFG_EXT register) */
+ CFG_EXT_PAGE_SIZE_SHIFT = 0,
+ CFG_EXT_BLK_SIZE_SHIFT = 4,
+};
+
/* BRCMNAND_INTFC_STATUS */
enum {
INTFC_FLASH_STATUS = GENMASK(7, 0),
@@ -1720,17 +1742,19 @@ static int brcmnand_set_cfg(struct brcmnand_host *host,
}
device_size = fls64(cfg->device_size) - fls64(BRCMNAND_MIN_DEVSIZE);
- tmp = (cfg->blk_adr_bytes << 8) |
- (cfg->col_adr_bytes << 12) |
- (cfg->ful_adr_bytes << 16) |
- (!!(cfg->device_width == 16) << 23) |
- (device_size << 24);
+ tmp = (cfg->blk_adr_bytes << CFG_BLK_ADR_BYTES_SHIFT) |
+ (cfg->col_adr_bytes << CFG_COL_ADR_BYTES_SHIFT) |
+ (cfg->ful_adr_bytes << CFG_FUL_ADR_BYTES_SHIFT) |
+ (!!(cfg->device_width == 16) << CFG_BUS_WIDTH_SHIFT) |
+ (device_size << CFG_DEVICE_SIZE_SHIFT);
if (cfg_offs == cfg_ext_offs) {
- tmp |= (page_size << 20) | (block_size << 28);
+ tmp |= (page_size << CFG_PAGE_SIZE_SHIFT) |
+ (block_size << CFG_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_offs, tmp);
} else {
nand_writereg(ctrl, cfg_offs, tmp);
- tmp = page_size | (block_size << 4);
+ tmp = (page_size << CFG_EXT_PAGE_SIZE_SHIFT) |
+ (block_size << CFG_EXT_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_ext_offs, tmp);
}
--
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 v3 1/4] Documentation: dt-bindings: Describe SROMc configuration
On 29.10.2015 20:43, Pavel Fedin wrote: > Hello! > Any vendor prefix here? How generic is this? >>> >>> I just don't know... Does *everything* really need a vendor prefix? How >>> readable would that >> be? "compatible" property already says >>> that it's samsung-exynos-specific. And IMHO it's quite obvious that >>> properties of vendor- >> specific device are automatically >>> vendor-specific. >>> Ok, i am currently fixing up the rest and will post v4 soon, and will Cc: >>> it to devicetree >> ML. >> >> Which my reply you are referring to? You stripped part of some >> sentence and put it without *any context*. Just random sentence. >> I asked for vendor prefix in few places... srom-timing? width? And I >> do not remember where I used exactly these words. > > Ok, sorry, i promise to improve. :) > Anyway, i have figured out how to add sub-devices, and heavily modified the > whole thing. And indeed, vendor prefix is now very useful, so i added it to > all three properties. Making v4... Actually now I found: Documentation/devicetree/bindings/net/gpmc-eth.txt Aren't you duplicating this work? This looks very, very similar. 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 v12 0/6] Altera PCIe host controller driver with MSI support
On Fri, Oct 30, 2015 at 7:22 AM, Bjorn Helgaas wrote: >> >>> >> >>> I applied these to pci/host-altera for v4.4, thanks! >> >>> >> >>> I squashed these into three patches: >> >>> >> >>> - add msi.h to Kbuild >> >>> - add Altera host driver (including DT binding and MAINTAINERS update) >> >>> - add Altera MSI driver (including DT binding and MAINTAINERS update) >> >>> >> >>> Since the convention is to add PCI ID #defines only when they are used in >> >>> multiple places, I replaced PCI_VENDOR_ID_ALTERA with 0x1172 in the >> >>> single >> >>> place it is used. >> >> Hi Bjorn >> >> >> >> Thanks for applied these. >> >> >> >> By the way, I can't see pci/host-altera branch in your pci.git tree >> >> yet. It takes some time to appear there? >> > >> > Sorry, I forgot to push it. It should be there now! >> > >> Yes, saw it now. It will merge to 'next' branch eventually? > > Yep, I just merged it to 'next' and pushed it. Saw it. Thanks! Regards Ley Foon -- 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] gpio: xgene: add support to configure GPIO line as input, output or external IRQ pin
Forgive me for not turn on plain text mode my last email.
Hi Linus,
My name is Quan Nguyen, I'm working with Y Vo on this patch.
Allow me to explain as below:
In current implementation, gic irq resources were used in both sbgpio
and gpios-key nodes, and this causes confusion.
To avoid this, we introduce sbgpio driver as interrupt controller, it
now provides 6 external irq pins mapped from gpio line 8-13. The
gpio-keys node now uses sbgpio irq resources instead.
-- Quan
On Thu, Oct 29, 2015 at 8:28 PM, Linus Walleij wrote:
> On Mon, Oct 26, 2015 at 7:49 AM, Y Vo wrote:
>
>> Add support to configure GPIO line as input, output or external IRQ pin.
>>
>> Signed-off-by: Y Vo
>
> As I will say again, this description is too terse, add lots of information
> on how IRQs work on this controller please. I get confused.
How about:
+
Enable X-Gene standby GPIO driver as interrupt controller, it provides
6 external irq pins via gpio line 8-13.
+
>
> (...)
>
>> +#define XGENE_GPIO8_HWIRQ 0x48
>> +#define XGENE_GPIO8_IDX8
> (...)
>> +#define XGENE_HWIRQ_TO_GPIO(hwirq) ((hwirq) + XGENE_GPIO8_IDX)
>> +#define XGENE_GPIO_TO_HWIRQ(gpio) ((gpio) - XGENE_GPIO8_IDX)
>> +#define GIC_IRQ_TO_GPIO_IRQ(hwirq) ((hwirq) - XGENE_GPIO8_HWIRQ)
>> +#define GPIO_IRQ_TO_GIC_IRQ(hwirq) ((hwirq) + XGENE_GPIO8_HWIRQ)
>
> I'm a bit uneasy about this, maybe I just don't get it.
>
> What is this indexing into "GIC IRQ" that is starting to happen
> here?
>
> The GIC (if that is drivers/irqchip/irq-gic.c) has a totally dynamic IRQ
> translation and the Linux IRQs it is using may change. I am worried
> that there is some reliance here on Linux IRQ having certain numbers
> because there is certainly no ABI like that.
>
> Is this 0x48 really an index into the *hardware* offset in the GIC?
>
> And if it is: why are we not getting this hardware information from the
> device tree like all other interrupt numbers and offsets?
>
> I'm worried about this.
The SPI40(0x48) through SPI45(0x4D) from GIC are mapped as external
IRQ0 - IRQ5 in this GPIO block, so it is hardware offset not mapped
irq number.
Below is detail:
+ GIC: SPI40 (hwirq=0x48) <=> SB-GPIO: (hwirq=0) (gpio line 8)
+ GIC: SPI41 (hwirq=0x49) <=> SB-GPIO: (hwirq=1) (gpio line 9)
...
+ GIC: SPI45 (hwirq=0x4D) <=> SB-GPIO: (hwirq=5) (gpio line 13)
These defines are to help translating between Gic hardware irq and
SBGPIO hardware irq number.
>
>> - u32 *irq;
>> + void __iomem *regs;
>> + struct irq_domain *gic_domain;
>> + struct irq_domain *irq_domain;
>
> And there is some secondary gic_domain here, which is confusing
> since the GIC does have an IRQ domain too.
>
> I think I want a clear explanation to how this GPIO controller interacts
> with the GIC, and I want it to be part of the patch, as comments in the
> code and in the commit message (which is way too small for a complex
> patch like this).
>
> Otherwise I have no chance to understand what is really going on here.
SBGPIO currently is not capable to mask/unmask/... irqs, so these will
rely on the parent (GIC) instead. To do so, we need keep a parent
domain reference here "struct irq_domain *gic_domain" so we can find
correspond parent irq in runtime.
>
>> +static int xgene_gpio_sb_irq_set_type(struct irq_data *d, unsigned int type)
>> +{
>> + int hwirq = d->hwirq;
>> + int gpio = XGENE_HWIRQ_TO_GPIO(hwirq);
>> + struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
>> + int lvl_type;
>> + int ret;
>> +
>> + switch (type & IRQ_TYPE_SENSE_MASK) {
>> + case IRQ_TYPE_EDGE_RISING:
>> + case IRQ_TYPE_LEVEL_HIGH:
>> + lvl_type = GPIO_INT_LVL_LEVEL_HIGH;
>> + break;
>> + case IRQ_TYPE_EDGE_FALLING:
>> + case IRQ_TYPE_LEVEL_LOW:
>> + lvl_type = GPIO_INT_LVL_LEVEL_LOW;
>> + break;
>> + default:
>> + return -EINVAL;
>> + }
>> +
>> + ret = gpiochip_lock_as_irq(&priv->bgc.gc, gpio);
>> + if (ret) {
>> + dev_err(priv->bgc.gc.dev,
>> + "Unable to configure XGene GPIO standby pin %d as IRQ\n",
>> + gpio);
>> + return ret;
>> + }
>> +
>> + if ((gpio >= XGENE_GPIO8_IDX) &&
>> + (hwirq < XGENE_MAX_GPIO_DS_IRQ)) {
>> + xgene_gpio_set_bit(&priv->bgc, priv->regs + MPA_GPIO_SEL_LO,
>> + gpio * 2, 1);
>> + xgene_gpio_set_bit(&priv->bgc, priv->regs + MPA_GPIO_INT_LVL,
>> + hwirq, lvl_type);
>> + }
>> + if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
>> + irq_set_handler_locked(d, handle_edge_irq);
>> + else
>> + irq_set_handler_locked(d, handle_level_irq);
>> +
>> +
Re: [PATCH v4 2/3] mtd: mtk-nor: mtk serial flash controller driver
Hi Bayi, On Fri, Oct 30, 2015 at 10:12:39AM +0800, bayi.cheng wrote: > Hi Brian, The current station is as follows. > > 1: put 0x9F to MTK_NOR_PRGDATA5_REG, and five 0x0 to > MTK_NOR_PRGDATA4_REG ~ MTK_NOR_PRGDATA0_REG, then set (1 + 5) * 8 > to MTK_NOR_CNT_REG, for this way, we can read five IDs. > > 2: put 0x9F to MTK_NOR_PRGDATA5_REG, and five 0x0 to > MTK_NOR_PRGDATA4_REG ~ MTK_NOR_PRGDATA0_REG, then set (1 + 5 + 1) * 8 > to MTK_NOR_CNT_REG, for this way, we can read six IDs. > In this case, nor flash IDs can be read from MTK_NOR_SHREG5_REG to > MTK_NOR_SHREG0_REG . Thanks! Thanks for the update. Glad to hear you can read more bytes there; the extra number of Shift Registers *looked* to me like you should be able to read even more than 5... So in my other email, I showed you how I generalized the TX/RX function, so it can handle most of both the write_reg() and read_reg() functions. I'm not 100% sure now that it has all of the RX path correct; it worked for the cases I could test, but it's confusing when reading the manual to figure out which SHREG register I should start from. But anyway, I think it should only take some small adjustments to my patch to make it handle things properly. I'd really appreciate it if you could incorporate my feedback and review/improve the ..._do_tx_rx() function I wrote, to make sure it handles reading any arbitrary number of bytes (at least up to 6). So, you might, for example, run some tests where you have spi-nor.c call nor->read_reg(nor, SPINOR_OP_RDID, id, idlen) with varying values for 'idlen', and make sure they all work properly. Let me know if you have any questions about comments either here, or on v5. 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 v5 2/3] mtd: mtk-nor: mtk serial flash controller driver
Hi Bayi, (I drafted most of this before you clarified on how to read out 6 bytes of ID. So a bit of this is slightly out-of-date. Still, I think most of the comments and much of the appended patch should be useful to you.) On Mon, Oct 26, 2015 at 09:40:38PM +0800, Bayi Cheng wrote: > add spi nor flash driver for mediatek controller > > Signed-off-by: Bayi Cheng > --- > drivers/mtd/spi-nor/Kconfig | 7 + > drivers/mtd/spi-nor/Makefile | 1 + > drivers/mtd/spi-nor/mtk-quadspi.c | 491 > ++ > 3 files changed, 499 insertions(+) > create mode 100644 drivers/mtd/spi-nor/mtk-quadspi.c > > diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig > index 89bf4c1..387396d 100644 > --- a/drivers/mtd/spi-nor/Kconfig > +++ b/drivers/mtd/spi-nor/Kconfig > @@ -7,6 +7,13 @@ menuconfig MTD_SPI_NOR > > if MTD_SPI_NOR > > +config MTD_MT81xx_NOR > + tristate "Mediatek MT81xx SPI NOR flash controller" > + help > + This enables access to SPI NOR flash, using MT81xx SPI NOR flash > + controller. This controller does not support generic SPI BUS, It only Nit: s/It/it/ > + supports SPI NOR Flash. > + > config MTD_SPI_NOR_USE_4K_SECTORS > bool "Use small 4096 B erase sectors" > default y > diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile > index e5e..0bf3a7f8 100644 > --- a/drivers/mtd/spi-nor/Makefile > +++ b/drivers/mtd/spi-nor/Makefile > @@ -1,3 +1,4 @@ > obj-$(CONFIG_MTD_SPI_NOR)+= spi-nor.o > obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o > +obj-$(CONFIG_MTD_MT81xx_NOR)+= mtk-quadspi.o > obj-$(CONFIG_SPI_NXP_SPIFI) += nxp-spifi.o > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c > b/drivers/mtd/spi-nor/mtk-quadspi.c > new file mode 100644 > index 000..33a8dc5 > --- /dev/null > +++ b/drivers/mtd/spi-nor/mtk-quadspi.c > @@ -0,0 +1,491 @@ > +/* > + * Copyright (c) 2015 MediaTek Inc. > + * Author: Bayi Cheng > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include You're not using GPIOs. You don't need this header. > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define MTK_NOR_CMD_REG 0x00 > +#define MTK_NOR_CNT_REG 0x04 > +#define MTK_NOR_RDSR_REG 0x08 > +#define MTK_NOR_RDATA_REG0x0c > +#define MTK_NOR_RADR0_REG0x10 > +#define MTK_NOR_RADR1_REG0x14 > +#define MTK_NOR_RADR2_REG0x18 > +#define MTK_NOR_WDATA_REG0x1c > +#define MTK_NOR_PRGDATA0_REG 0x20 > +#define MTK_NOR_PRGDATA1_REG 0x24 > +#define MTK_NOR_PRGDATA2_REG 0x28 > +#define MTK_NOR_PRGDATA3_REG 0x2c > +#define MTK_NOR_PRGDATA4_REG 0x30 > +#define MTK_NOR_PRGDATA5_REG 0x34 > +#define MTK_NOR_SHREG0_REG 0x38 > +#define MTK_NOR_SHREG1_REG 0x3c > +#define MTK_NOR_SHREG2_REG 0x40 > +#define MTK_NOR_SHREG3_REG 0x44 > +#define MTK_NOR_SHREG4_REG 0x48 > +#define MTK_NOR_SHREG5_REG 0x4c > +#define MTK_NOR_SHREG6_REG 0x50 > +#define MTK_NOR_SHREG7_REG 0x54 > +#define MTK_NOR_SHREG8_REG 0x58 > +#define MTK_NOR_SHREG9_REG 0x5c > +#define MTK_NOR_CFG1_REG 0x60 > +#define MTK_NOR_CFG2_REG 0x64 > +#define MTK_NOR_CFG3_REG 0x68 > +#define MTK_NOR_STATUS0_REG 0x70 > +#define MTK_NOR_STATUS1_REG 0x74 > +#define MTK_NOR_STATUS2_REG 0x78 > +#define MTK_NOR_STATUS3_REG 0x7c > +#define MTK_NOR_FLHCFG_REG 0x84 > +#define MTK_NOR_TIME_REG 0x94 > +#define MTK_NOR_PP_DATA_REG 0x98 > +#define MTK_NOR_PREBUF_STUS_REG 0x9c > +#define MTK_NOR_DELSEL0_REG 0xa0 > +#define MTK_NOR_DELSEL1_REG 0xa4 > +#define MTK_NOR_INTRSTUS_REG 0xa8 > +#define MTK_NOR_INTREN_REG 0xac > +#define MTK_NOR_CHKSUM_CTL_REG 0xb8 > +#define MTK_NOR_CHKSUM_REG 0xbc > +#define MTK_NOR_CMD2_REG 0xc0 > +#define MTK_NOR_WRPROT_REG 0xc4 > +#define MTK_NOR_RADR3_REG0xc8 > +#define MTK_NOR_DUAL_REG 0xcc > +#define MTK_NOR_DELSEL2_REG 0xd0 > +#define MTK_NOR_DELSEL3_REG 0xd4 > +#define MTK_NOR_DELSEL4_REG 0xd8 > + > +/* commands for mtk
[PATCH] dma: fix platform_no_drv_owner.cocci warnings
drivers/dma/qcom_hidma_mgmt.c:852:3-8: No need to set .owner here. The core
will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: Sinan Kaya
Signed-off-by: Fengguang Wu
---
qcom_hidma_mgmt.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/dma/qcom_hidma_mgmt.c
+++ b/drivers/dma/qcom_hidma_mgmt.c
@@ -849,7 +849,6 @@ static struct platform_driver qcom_hidma
.remove = qcom_hidma_mgmt_remove,
.driver = {
.name = MODULE_NAME,
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(qcom_hidma_mgmt_match),
.acpi_match_table = ACPI_PTR(qcom_hidma_mgmt_acpi_ids),
},
--
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
Hi Sinan, [auto build test WARNING on lwn/docs-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Sinan-Kaya/dma-add-Qualcomm-Technologies-HIDMA-management-driver/20151030-111408 coccinelle warnings: (new ones prefixed by >>) >> drivers/dma/qcom_hidma_mgmt.c:852:3-8: No need to set .owner here. The core >> will do it. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- 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
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.:- Thanks Heiko ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip -- 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
Re: [PATCH net-next v2 0/2] drivers: xgene: Add support RGMII TX/RX delay configuration
From: Iyappan Subramanian
Date: Mon, 26 Oct 2015 15:25:14 -0700
> X-Gene RGMII ethernet controller has a RGMII bridge that performs the
> task of converting the RGMII signal {RX_CLK,RX_CTL, RX_DATA[3:0]} from
> PHY to GMII signal {RX_DV,RX_ER,RX_DATA[7:0]} and vice versa. This
> RGMII bridge has a provision to internally delay the input RX_CLK and
> the output TX_CLK using configuration registers. This will help in
> maintain the CLK-CTL delay relationship in various operating
> conditions.
>
> This patch adds support RGMII TX/RX delay configuration.
>
> Signed-off-by: Iyappan Subramanian
Series applied, thanks.
--
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] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver
consists of two logical blocks. The DMA engine interface
and the low-level interface. This version of the driver
does not support virtualization on this release and only
memcpy interface support is included.
Signed-off-by: Sinan Kaya
---
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
drivers/dma/Kconfig| 11 +
drivers/dma/Makefile |4 +
drivers/dma/qcom_hidma.c | 1717
drivers/dma/qcom_hidma.h | 44 +
drivers/dma/qcom_hidma_ll.c| 1132 +
6 files changed, 2926 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 drivers/dma/qcom_hidma.c
create mode 100644 drivers/dma/qcom_hidma.h
create mode 100644 drivers/dma/qcom_hidma_ll.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..9a01635
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+ hidma_24: hidma@0x5c05 {
+ compatible = "qcom,hidma";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ event-channel = /bits/ 8 <4>;
+ };
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 76a5a5e..2645185 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -512,6 +512,17 @@ config QCOM_HIDMA_MGMT
OS would run QCOM_HIDMA driver and the hypervisor would run
the QCOM_HIDMA_MGMT driver.
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA support"
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy/memset interfaces. The core is not intended for general
+ purpose slave DMA.
+
config XILINX_VDMA
tristate "Xilinx AXI VDMA Engine"
depends on (ARCH_ZYNQ || MICROBLAZE)
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 3d25ffd..5665df2 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -53,6 +53,10 @@ obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
+obj-$(CONFIG_QCOM_HIDMA) += qcom_hdma.o
+qcom_hdma-objs:= qcom_hidma_ll.o qcom_hidma.o
+
+
obj-$(CONFIG_QCOM_HIDMA_MGMT) += qcom_hidma_mgmt.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
diff --git a/drivers/dma/qcom_hidma.c b/drivers/dma/qcom_hidma.c
new file mode 100644
index 000..2a92305
--- /dev/null
+++ b/drivers/dma/qcom_hidma.c
@@ -0,0 +1,1717 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik . Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen .
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * 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, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR P
[PATCH 1/2] dma: add Qualcomm Technologies HIDMA management driver
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
managment for all channels provided by the device. The
channel driver is exected in the guest OS context.
Signed-off-by: Sinan Kaya
---
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 42 +
drivers/dma/Kconfig| 11 +
drivers/dma/Makefile | 1 +
drivers/dma/qcom_hidma_mgmt.c | 868 +
4 files changed, 922 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom_hidma_mgmt.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..81674ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,42 @@
+Qualcomm Technologies HIDMA Management interface
+
+Required properties:
+- compatible: must contain "qcom,hidma_mgmt"
+- reg: Address range for DMA device
+- interrupts: Should contain the one interrupt shared by all channels
+- nr-channels: Number of channels supported by this DMA controller.
+- max-write: Maximum write burst in bytes. A memcpy requested is
+ fragmented to multiples of this amount.
+- max-read: Maximum read burst in bytes. A memcpy request is
+ fragmented to multiples of this amount.
+- max-wxactions: Maximum write transactions to perform in a burst
+- max-rdactions: Maximum read transactions to perform in a burst
+- max-memset-limit: Maximum memset limit
+- ch-priority-#n: Priority of the channel
+- ch-weight-#n: Round robin weight of the channel
+Example:
+
+ hidma-mgmt@f9984000 = {
+ compatible = "qcom,hidma_mgmt";
+ reg = <0xf9984000 0x15000>;
+ interrupts = <0 94 0>;
+ nr-channels = 6;
+ max-write = 1024;
+ max-read = 1024;
+ max-wxactions = 31;
+ max-rdactions = 31;
+ max-memset-limit = 8;
+ ch-priority-0 = 0;
+ ch-priority-1 = 1;
+ ch-priority-2 = 1;
+ ch-priority-3 = 0;
+ ch-priority-4 = 0;
+ ch-priority-5 = 0;
+ ch-weight-0 = 1;
+ ch-weight-1 = 13;
+ ch-weight-2 = 10;
+ ch-weight-3 = 3;
+ ch-weight-4 = 4;
+ ch-weight-5 = 5;
+ };
+
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..76a5a5e 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -501,6 +501,17 @@ config XGENE_DMA
help
Enable support for the APM X-Gene SoC DMA engine.
+config QCOM_HIDMA_MGMT
+ bool "Qualcomm Technologies HIDMA Managment support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA Management.
+ Each DMA device requires one management interface driver
+ for basic initialization before QCOM_HIDMA driver can start
+ managing the channels. In a virtualized environment, the guest
+ OS would run QCOM_HIDMA driver and the hypervisor would run
+ the QCOM_HIDMA_MGMT driver.
+
config XILINX_VDMA
tristate "Xilinx AXI VDMA Engine"
depends on (ARCH_ZYNQ || MICROBLAZE)
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..3d25ffd 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
+obj-$(CONFIG_QCOM_HIDMA_MGMT) += qcom_hidma_mgmt.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
diff --git a/drivers/dma/qcom_hidma_mgmt.c b/drivers/dma/qcom_hidma_mgmt.c
new file mode 100644
index 000..8fcad4d
--- /dev/null
+++ b/drivers/dma/qcom_hidma_mgmt.c
@@ -0,0 +1,868 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine Management interface
+ *
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "qcom_hidma.h"
+
+#define MHICFG_OFFSET
Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004
On Thu, Oct 29, 2015 at 09:08:45PM -0500, Michael Welling wrote:
> Dmitry,
>
> On Thu, Oct 29, 2015 at 06:45:22PM -0700, Dmitry Torokhov wrote:
> > Hi Michael,
> >
> > On Wed, Oct 28, 2015 at 07:12:34PM -0500, Michael Welling wrote:
> > > Adds support for the i2c based tsc2004.
> > >
> > > Due to the overlapping functionality of the tsc2004 and tsc2005
> > > the common code was moved to a core driver (tsc200x-core).
> > >
> > > Signed-off-by: Michael Welling
> >
> > In addition to what has been discussed in the other email:
> >
> > > ---
> > > v3: Splits the tsc2004 and tsc2005 into separate drivers with
> > > with common routines in tsc200x-core.
> > > v2: Fixes Kconfig based on report for 0-day build bot.
> > > .../bindings/input/touchscreen/tsc2004.txt | 38 +
> >
> > Can we please combine tsc2004.txt and tsc2005.txt?
>
> Sure.
>
> >
> > >
> > > +config TOUCHSCREEN_TSC200X
> > > + tristate
> >
> > Let's call it TOUCHSCREEN_TSC200X_CORE.
>
> Okay.
>
> >
> > > --- /dev/null
> > > +++ b/drivers/input/touchscreen/tsc2004.c
> > > @@ -0,0 +1,73 @@
> > > +/*
> > > + * TSC2004 touchscreen driver
> > > + *
> > > + * Copyright (C) 2015 EMAC Inc.
> > > + * Copyright (C) 2015 QWERTY Embedded Design
> > > + *
> > > + * 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, or
> > > + * (at your option) any later version.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + *
> >
> > Please drop this empty line in the comment.
> >
>
> No problem.
>
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include "tsc200x-core.h"
> > > +
> > > +static int tsc2004_probe(struct i2c_client *i2c,
> > > + const struct i2c_device_id *id)
> > > +
> > > +{
> > > + return tsc200x_probe(&i2c->dev, i2c->irq, BUS_I2C,
> > > + devm_regmap_init_i2c(i2c,
> > > + &tsc2005_regmap_config));
> > > +}
> > > +
> > > +static int tsc2004_remove(struct i2c_client *i2c)
> > > +{
> > > + return tsc200x_remove(&i2c->dev);
> > > +}
> > > +
> > > +static const struct i2c_device_id tsc2004_idtable[] = {
> > > + { "tsc2004", 0 },
> > > + { }
> > > +};
> > > +
> > > +MODULE_DEVICE_TABLE(i2c, tsc2004_idtable);
> > > +
> > > +#ifdef CONFIG_OF
> > > +static const struct of_device_id tsc2004_of_match[] = {
> > > + { .compatible = "ti,tsc2004" },
> > > + { /* sentinel */ }
> > > +};
> > > +MODULE_DEVICE_TABLE(of, tsc2004_of_match);
> > > +#endif
> > > +
> > > +static SIMPLE_DEV_PM_OPS(tsc2004_pm_ops, tsc200x_suspend,
> > > tsc200x_resume);
> >
> > Hmm, maybe you should export tsc200x_pm_ops instead of individual
> > functions.
> >
> > > +
> > > +int __maybe_unused tsc200x_suspend(struct device *dev)
> > > +{
> > > + struct tsc2005 *ts = dev_get_drvdata(dev);
> > > +
> > > + mutex_lock(&ts->mutex);
> > > +
> > > + if (!ts->suspended && ts->opened)
> > > + __tsc2005_disable(ts);
> > > +
> > > + ts->suspended = true;
> > > +
> > > + mutex_unlock(&ts->mutex);
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(tsc200x_suspend);
> >
> > __maybe_unused does not make sense here - the symbol is exported and
> > therefore is always used. If you export the pm_ops stucture then you can
> > keep functions as __maybe_unused.
> >
> > BTW, can you generate the patch with -M to let git do the rename
> > detection - it will be easier to see what changed in the core.
>
> Okay.
>
> Here is somthing that I just saw. The tsc2005_cmd function uses a pointer to
> struct tsc2005 as a paramter. So the struct needs to moved into the
> tsc200x-core.h. Should all of the defines be moved there too?
You do not actually need tsc2005 structure in the command function, you
only need the command itself and the generic device structure and then you can
get back to either i2c_client or spi device from it.
>
> Also the old platform data is in a SPI specific include directory.
> Do we want to move this?
If you do not mind whipping up an additional patch - sure.
>
> Also should I change all of the names of the core functions, variables,
> structs,
> and defines to tsc200x for consistency including the driver
> struct/defines/etc?
That would be nice, but I'd like it split into different patches if
possible:
1. Split off spi/tsc2005 from the core.
2. Rename core functions to tsc200x.
3. Add tsc2004/i2c module.
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:/
Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004
Dmitry,
On Thu, Oct 29, 2015 at 06:45:22PM -0700, Dmitry Torokhov wrote:
> Hi Michael,
>
> On Wed, Oct 28, 2015 at 07:12:34PM -0500, Michael Welling wrote:
> > Adds support for the i2c based tsc2004.
> >
> > Due to the overlapping functionality of the tsc2004 and tsc2005
> > the common code was moved to a core driver (tsc200x-core).
> >
> > Signed-off-by: Michael Welling
>
> In addition to what has been discussed in the other email:
>
> > ---
> > v3: Splits the tsc2004 and tsc2005 into separate drivers with
> > with common routines in tsc200x-core.
> > v2: Fixes Kconfig based on report for 0-day build bot.
> > .../bindings/input/touchscreen/tsc2004.txt | 38 +
>
> Can we please combine tsc2004.txt and tsc2005.txt?
Sure.
>
> >
> > +config TOUCHSCREEN_TSC200X
> > + tristate
>
> Let's call it TOUCHSCREEN_TSC200X_CORE.
Okay.
>
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/tsc2004.c
> > @@ -0,0 +1,73 @@
> > +/*
> > + * TSC2004 touchscreen driver
> > + *
> > + * Copyright (C) 2015 EMAC Inc.
> > + * Copyright (C) 2015 QWERTY Embedded Design
> > + *
> > + * 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, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
>
> Please drop this empty line in the comment.
>
No problem.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "tsc200x-core.h"
> > +
> > +static int tsc2004_probe(struct i2c_client *i2c,
> > +const struct i2c_device_id *id)
> > +
> > +{
> > + return tsc200x_probe(&i2c->dev, i2c->irq, BUS_I2C,
> > +devm_regmap_init_i2c(i2c,
> > + &tsc2005_regmap_config));
> > +}
> > +
> > +static int tsc2004_remove(struct i2c_client *i2c)
> > +{
> > + return tsc200x_remove(&i2c->dev);
> > +}
> > +
> > +static const struct i2c_device_id tsc2004_idtable[] = {
> > + { "tsc2004", 0 },
> > + { }
> > +};
> > +
> > +MODULE_DEVICE_TABLE(i2c, tsc2004_idtable);
> > +
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id tsc2004_of_match[] = {
> > + { .compatible = "ti,tsc2004" },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, tsc2004_of_match);
> > +#endif
> > +
> > +static SIMPLE_DEV_PM_OPS(tsc2004_pm_ops, tsc200x_suspend, tsc200x_resume);
>
> Hmm, maybe you should export tsc200x_pm_ops instead of individual
> functions.
>
> > +
> > +int __maybe_unused tsc200x_suspend(struct device *dev)
> > +{
> > + struct tsc2005 *ts = dev_get_drvdata(dev);
> > +
> > + mutex_lock(&ts->mutex);
> > +
> > + if (!ts->suspended && ts->opened)
> > + __tsc2005_disable(ts);
> > +
> > + ts->suspended = true;
> > +
> > + mutex_unlock(&ts->mutex);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(tsc200x_suspend);
>
> __maybe_unused does not make sense here - the symbol is exported and
> therefore is always used. If you export the pm_ops stucture then you can
> keep functions as __maybe_unused.
>
> BTW, can you generate the patch with -M to let git do the rename
> detection - it will be easier to see what changed in the core.
Okay.
Here is somthing that I just saw. The tsc2005_cmd function uses a pointer to
struct tsc2005 as a paramter. So the struct needs to moved into the
tsc200x-core.h. Should all of the defines be moved there too?
Also the old platform data is in a SPI specific include directory.
Do we want to move this?
Also should I change all of the names of the core functions, variables, structs,
and defines to tsc200x for consistency including the driver struct/defines/etc?
Regards,
Michael
>
> 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 0/2] power: Add support for TI BQ24261 charger
2015-10-30 1:37 GMT+09:00 Ramakrishna Pallala : > This patch series adds the support for TI BQ24261 charger driver. > > TI BQ24261 charger driver relies on extcon notifications to get the > charger cable type and based on that it will set the charging parameters. > > Ramakrishna Pallala (2): > dt: power: Add support for BQ24261 charger > power: Add support for TI BQ24261 charger I think I saw these patches before. Like one or two months ago. Now you sent these two times. There is no changelog, no versioning. This is confusing. What the background? History? 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 1/2] dt: power: Add support for TI BQ24261 charger
2015-10-30 1:37 GMT+09:00 Ramakrishna Pallala : > This patch adds the device tree documentation for TI BQ24261 charger. > > Signed-off-by: Ramakrishna Pallala > Signed-off-by: Jenny TC > --- > .../devicetree/bindings/power/bq24261.txt | 34 > > 1 file changed, 34 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power/bq24261.txt > > diff --git a/Documentation/devicetree/bindings/power/bq24261.txt > b/Documentation/devicetree/bindings/power/bq24261.txt > new file mode 100644 > index 000..e18f6dc > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/bq24261.txt > @@ -0,0 +1,34 @@ > +Binding for TI bq24261 Li-Ion Charger > + > +Required properties: > +- compatible: Should contain one of the following: > +* "ti,bq24261" Just: 'should be "ti,bq24261"'. > +- reg: integer, i2c address of the device. > +- ti,battery-regulation-voltage: integer, maximum charging voltage in uV. > +- ti,charge-current: integer, maximum charging current in uA. > +- ti,termination-current: integer, charge will be terminated when current in > +constant-voltage phase drops below this value (in uA). Same as proposed extension of bq24257.txt. I like it. > + > +Optional properties: > +- ti,max-charge-current: integer, maximum charging current (in uA); I did not look at the code yet but description of property is exactly the same as "ti,charge-current"... Two different properties with same description? > +- ti,max-charge-voltage: integer, maximum charging voltage (in uV); Ditto. > +- ti,min-charge-temperature: integer, minimum charging temperature (in DegC); > +- ti,max-charge-temperature: integer, maximum charging temperature (in DegC). > +- ti,thermal-sensing: integer, enable(1) or disable(0) JEITA thermal control. You made it integer instead of boolean, so just to be sure - you expect the possibility of overriding this property or extending it in further devices? 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 v3] Input: tsc2005 - Add support for tsc2004
Hi Michael,
On Wed, Oct 28, 2015 at 07:12:34PM -0500, Michael Welling wrote:
> Adds support for the i2c based tsc2004.
>
> Due to the overlapping functionality of the tsc2004 and tsc2005
> the common code was moved to a core driver (tsc200x-core).
>
> Signed-off-by: Michael Welling
In addition to what has been discussed in the other email:
> ---
> v3: Splits the tsc2004 and tsc2005 into separate drivers with
> with common routines in tsc200x-core.
> v2: Fixes Kconfig based on report for 0-day build bot.
> .../bindings/input/touchscreen/tsc2004.txt | 38 +
Can we please combine tsc2004.txt and tsc2005.txt?
>
> +config TOUCHSCREEN_TSC200X
> + tristate
Let's call it TOUCHSCREEN_TSC200X_CORE.
> --- /dev/null
> +++ b/drivers/input/touchscreen/tsc2004.c
> @@ -0,0 +1,73 @@
> +/*
> + * TSC2004 touchscreen driver
> + *
> + * Copyright (C) 2015 EMAC Inc.
> + * Copyright (C) 2015 QWERTY Embedded Design
> + *
> + * 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, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
Please drop this empty line in the comment.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "tsc200x-core.h"
> +
> +static int tsc2004_probe(struct i2c_client *i2c,
> + const struct i2c_device_id *id)
> +
> +{
> + return tsc200x_probe(&i2c->dev, i2c->irq, BUS_I2C,
> + devm_regmap_init_i2c(i2c,
> + &tsc2005_regmap_config));
> +}
> +
> +static int tsc2004_remove(struct i2c_client *i2c)
> +{
> + return tsc200x_remove(&i2c->dev);
> +}
> +
> +static const struct i2c_device_id tsc2004_idtable[] = {
> + { "tsc2004", 0 },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(i2c, tsc2004_idtable);
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id tsc2004_of_match[] = {
> + { .compatible = "ti,tsc2004" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, tsc2004_of_match);
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(tsc2004_pm_ops, tsc200x_suspend, tsc200x_resume);
Hmm, maybe you should export tsc200x_pm_ops instead of individual
functions.
> +
> +int __maybe_unused tsc200x_suspend(struct device *dev)
> +{
> + struct tsc2005 *ts = dev_get_drvdata(dev);
> +
> + mutex_lock(&ts->mutex);
> +
> + if (!ts->suspended && ts->opened)
> + __tsc2005_disable(ts);
> +
> + ts->suspended = true;
> +
> + mutex_unlock(&ts->mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(tsc200x_suspend);
__maybe_unused does not make sense here - the symbol is exported and
therefore is always used. If you export the pm_ops stucture then you can
keep functions as __maybe_unused.
BTW, can you generate the patch with -M to let git do the rename
detection - it will be easier to see what changed in the core.
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
[PATCH 2/3] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
Depending on the version of hardware or its properties, which are only
known at runtime, various properties of the OPP can change. For example,
an OPP with frequency 1.2 GHz, may have different voltage/current
requirements based on the version of the hardware it is running on.
Similarly, it may or may not be a turbo or suspend OPP on those
circumstances.
In order to not replicate the same OPP tables for varying values of all
such fields, this commit introduces the concept of opp-property-.
The can be chosen by the platform at runtime, and OPPs will be
initialized depending on that name string. Currently support is extended
for the following properties:
- opp-microvolt-
- opp-microamp-
- turbo-mode-
- opp-suspend-
If the name string isn't provided by the platform, or if it is provided
but doesn't match the properties present in the OPP node, we will fall
back to the original properties without the - string, if they are
available.
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 58 +++
1 file changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index 96892057586a..6e0dd8db3b86 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -100,6 +100,14 @@ properties.
Entries for multiple regulators must be present in the same order as
regulators are specified in device's DT node.
+- opp-microvolt-: Named opp-microvolt property. This is exactly similar
to
+ the above opp-microvolt property, but allows multiple voltage ranges to be
+ provided for the same OPP. At runtime, the platform can pick a and
+ matching opp-microvolt- property will be enabled for all OPPs. If the
+ platform doesn't pick a specific or the doesn't match with any
+ opp-microvolt- properties, then opp-microvolt property shall be used,
if
+ present.
+
- opp-microamp: The maximum current drawn by the device in microamperes
considering system specific parameters (such as transients, process, aging,
maximum operating temperature range etc.) as necessary. This may be used to
@@ -112,6 +120,9 @@ properties.
for few regulators, then this should be marked as zero for them. If it isn't
required for any regulator, then this property need not be present.
+- opp-microamp-: Named opp-microamp property. Similar to
+ opp-microvolt- property, but for microamp instead.
+
- clock-latency-ns: Specifies the maximum possible transition latency (in
nanoseconds) for switching to this OPP from any other OPP.
@@ -120,9 +131,15 @@ properties.
frequency for a short duration of time limited by the device's power, current
and thermal limits.
+- turbo-mode-: Named turbo-mode property. Similar to opp-microvolt-
+ property, but for turbo mode instead.
+
- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
the table should have this.
+- opp-suspend-: Named opp-suspend property. Similar to
+ opp-microvolt- property, but for suspend opp instead.
+
- opp-supported-hw: User defined array containing a hierarchy of hardware
version numbers, supported by the OPP. For example: a platform with hierarchy
of three levels of versions (A, B and C), this field should be like ,
@@ -520,3 +537,44 @@ Example 6: opp-supported-hw
};
};
};
+
+Example 7: opp-microvolt-, opp-microamp-, turbo-mode-,
+opp-suspend-:
+(example: device with two possible microvolt ranges: slow and fast)
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ ...
+
+ operating-points-v2 = <&cpu0_opp_table>;
+ };
+ };
+
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt-slow = <90 915000 925000>;
+ opp-microvolt-fast = <97 975000 985000>;
+ opp-microamp-slow = <7>;
+ opp-microamp-fast = <71000>;
+ turbo-mode-slow; /* Will be used as turbo only if
'slow' is chosen */
+ opp-suspend-slow; /* Will be used as suspend-opp only
if 'slow' is chosen */
+ };
+
+ opp01 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt-slow = <90 915000 925000>, /* Supply
vcc0 */
+ <91 925000 935000>; /* Supply
vcc1 */
+ opp-microvolt-fast = <97 975000 985000>, /* Supply
vcc0 */
+<96 965000 975000>; /* Supply
vcc1 */
+ opp-microamp = <7>; /* Will be used for both
slow/fast */
+
[PATCH 3/3] PM / OPP: Remove 'operating-points-names' binding
These aren't used until now by any DT files and wouldn't be used now as
we have a better scheme in place now, i.e. opp-property-
properties.
Remove the (useless) binding without breaking ABI.
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 62 +--
1 file changed, 2 insertions(+), 60 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index 6e0dd8db3b86..9d2e08f488b5 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -45,21 +45,10 @@ Devices supporting OPPs must set their
"operating-points-v2" property with
phandle to a OPP table in their DT node. The OPP core will use this phandle to
find the operating points for the device.
-Devices may want to choose OPP tables at runtime and so can provide a list of
-phandles here. But only *one* of them should be chosen at runtime. This must be
-accompanied by a corresponding "operating-points-names" property, to uniquely
-identify the OPP tables.
-
If required, this can be extended for SoC vendor specfic bindings. Such
bindings
should be documented as
Documentation/devicetree/bindings/power/-opp.txt
and should have a compatible description like: "operating-points-v2-".
-Optional properties:
-- operating-points-names: Names of OPP tables (required if multiple OPP
- tables are present), to uniquely identify them. The same list must be present
- for all the CPUs which are sharing clock/voltage rails and hence the OPP
- tables.
-
* OPP Table Node
This describes the OPPs belonging to a device. This node can have following
@@ -446,54 +435,7 @@ Example 4: Handling multiple regulators
};
};
-Example 5: Multiple OPP tables
-
-/ {
- cpus {
- cpu@0 {
- compatible = "arm,cortex-a7";
- ...
-
- cpu-supply = <&cpu_supply>
- operating-points-v2 = <&cpu0_opp_table_slow>,
<&cpu0_opp_table_fast>;
- operating-points-names = "slow", "fast";
- };
- };
-
- cpu0_opp_table_slow: opp_table_slow {
- compatible = "operating-points-v2";
- status = "okay";
- opp-shared;
-
- opp00 {
- opp-hz = /bits/ 64 <6>;
- ...
- };
-
- opp01 {
- opp-hz = /bits/ 64 <8>;
- ...
- };
- };
-
- cpu0_opp_table_fast: opp_table_fast {
- compatible = "operating-points-v2";
- status = "okay";
- opp-shared;
-
- opp10 {
- opp-hz = /bits/ 64 <10>;
- ...
- };
-
- opp11 {
- opp-hz = /bits/ 64 <11>;
- ...
- };
- };
-};
-
-Example 6: opp-supported-hw
+Example 5: opp-supported-hw
(example: three level hierarchy of versions: cuts, substrate and process)
/ {
@@ -538,7 +480,7 @@ Example 6: opp-supported-hw
};
};
-Example 7: opp-microvolt-, opp-microamp-, turbo-mode-,
+Example 6: opp-microvolt-, opp-microamp-, turbo-mode-,
opp-suspend-:
(example: device with two possible microvolt ranges: slow and fast)
--
2.6.2.198.g614a2ac
--
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 1/3] PM / OPP: Add "opp-supported-hw" binding
We may want to enable only a subset of OPPs, from the bigger list of
OPPs, based on what version of the hardware we are running on. This
would enable us to not duplicate OPP tables for every version of the
hardware we support.
To enable that, this patch defines a new property 'opp-supported-hw'. It
can support any number of hierarchy levels of the versions the hardware
follows. And based on the selected hardware versions, we can pick only
the relevant OPPs at runtime.
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 57 +++
1 file changed, 57 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index 0cb44dc21f97..96892057586a 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -123,6 +123,18 @@ properties.
- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
the table should have this.
+- opp-supported-hw: User defined array containing a hierarchy of hardware
+ version numbers, supported by the OPP. For example: a platform with hierarchy
+ of three levels of versions (A, B and C), this field should be like ,
+ where X corresponds to Version hierarchy A, Y corresponds to version
hierarchy
+ B and Z corresponds to version hierarchy C.
+
+ Each level of hierarchy is represented by a 32 bit value, and so there can be
+ only 32 different supported version per hierarchy. i.e. 1 bit per version. A
+ value of 0x will enable the OPP for all versions for that hierarchy
+ level. And a value of 0x will disable the OPP completely, and so we
+ never want that to happen.
+
- status: Marks the node enabled/disabled.
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
@@ -463,3 +475,48 @@ Example 5: Multiple OPP tables
};
};
};
+
+Example 6: opp-supported-hw
+(example: three level hierarchy of versions: cuts, substrate and process)
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ ...
+
+ cpu-supply = <&cpu_supply>
+ operating-points-v2 = <&cpu0_opp_table_slow>;
+ };
+ };
+
+ opp_table {
+ compatible = "operating-points-v2";
+ status = "okay";
+ opp-shared;
+
+ opp00 {
+ /*
+* Supports all substrate and process versions for 0xF
+* cuts, i.e. only first four cuts.
+*/
+ opp-supported-hw = <0xF 0x 0x>
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <90 915000 925000>;
+ ...
+ };
+
+ opp01 {
+ /*
+* Supports:
+* - cuts: only one, 6th cut (represented by 6th bit).
+* - substrate: supports 16 different substrate versions
+* - process: supports 9 different process versions
+*/
+ opp-supported-hw = <0x20 0xffff 0xf4f0>
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = <90 915000 925000>;
+ ...
+ };
+ };
+};
--
2.6.2.198.g614a2ac
--
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/3] PM / OPP: opp-supported-hw and -name bindings
Hi Rob/Stephen/Rafael,
These bindings are discussed in detail earlier:
http://marc.info/?l=linux-kernel&m=144237804923159&w=2
and I was waiting for the multi-regulator series to get applied first,
to post these patches.
But that series is not moving at fast pace and probably its time to get
other things going at least.
These are already kind of approved by Rob and Stephen (these are the
bindings we came up with for solving the issues reported by Lee Jones),
but a formal Ack is still required to get them merged.
The first patch enables us to select only a subset of OPPs from the
bigger table, based on what version of the hardware we are running on.
The second one enables us to select slightly different values for
multiple properties, based on what kind of hardware they are running on.
And the last one removes an (unused) binding, which is replaced by the
second patch with a better solution.
@Stephen/Rob: I already have working code for these bindings, which I
shared with Lee earlier. Just that I need to rebase that without the
multi-regulator series, will do that in coming days. But please see if
we can get these Acked/merged before that :)
Viresh Kumar (3):
PM / OPP: Add "opp-supported-hw" binding
PM / OPP: Add
{opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
PM / OPP: Remove 'operating-points-names' binding
Documentation/devicetree/bindings/opp/opp.txt | 101 --
1 file changed, 79 insertions(+), 22 deletions(-)
--
2.6.2.198.g614a2ac
--
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 v4 2/3] clk: bcm: Add BCM63138 clock support
BCM63138 has a simple clocking domain which is primarily the ARMPLL
clocking complex, from which the ARM (CPU), APB and AXI clocks would be
derived from.
Since the ARMPLL controller is entirely compatible with the iProc ARM
PLL, we just initialize it without additional parameters.
Signed-off-by: Florian Fainelli
---
No changes in v4
Changes in v3:
- made default depend on ARCH_BCM_63XX per Stephen Boyd's comment
Changes in v2:
- added COMPILE_TEST per Scott Branden's comment
drivers/clk/bcm/Kconfig | 10 ++
drivers/clk/bcm/Makefile | 1 +
drivers/clk/bcm/clk-bcm63xx.c | 22 ++
3 files changed, 33 insertions(+)
create mode 100644 drivers/clk/bcm/clk-bcm63xx.c
diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index 85260fb96b36..f2878459199a 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -1,3 +1,13 @@
+config CLK_BCM_63XX
+ bool "Broadcom BCM63xx clock support"
+ depends on ARCH_BCM_63XX || COMPILE_TEST
+ depends on COMMON_CLK
+ select COMMON_CLK_IPROC
+ default ARCH_BCM_63XX
+ help
+ Enable common clock framework support for Broadcom BCM63xx DSL SoCs
+ based on the ARM architecture
+
config CLK_BCM_KONA
bool "Broadcom Kona CCU clock support"
depends on ARCH_BCM_MOBILE || COMPILE_TEST
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 3fc95060d875..247c26750d8b 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_CLK_BCM_63XX) += clk-bcm63xx.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-kona.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
diff --git a/drivers/clk/bcm/clk-bcm63xx.c b/drivers/clk/bcm/clk-bcm63xx.c
new file mode 100644
index ..fbc17ae5ff2b
--- /dev/null
+++ b/drivers/clk/bcm/clk-bcm63xx.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include "clk-iproc.h"
+
+static void __init bcm63138_armpll_init(struct device_node *node)
+{
+ iproc_armpll_setup(node);
+}
+CLK_OF_DECLARE(bcm63138_armpll, "brcm,bcm63138-armpll", bcm63138_armpll_init);
--
2.1.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
[PATCH v4 0/3] clk: Broadcom BCM63138 support
This patch series adds support for the Broadcom BCM63138 DSL SoCs clocking framework. Since the HW is identical to the one found in Broadcom iProc SoCs, but the integration is different (obviously), there is still a new compatible string introduced just in case we happen to find issues in the future. Stephen, could you stage the two patches in a clk-bcm63xx branch that I could later utilize while doing the arm-soc DT pull request? Thank you! Florian Fainelli (3): clk: iproc: Extend binding to cover BCM63138 clk: bcm: Add BCM63138 clock support ARM: dts: BCM63xx: Add ARMPLL device tree nodes .../bindings/clock/brcm,iproc-clocks.txt | 5 +++ arch/arm/boot/dts/bcm63138.dtsi| 36 +- drivers/clk/bcm/Kconfig| 10 ++ drivers/clk/bcm/Makefile | 1 + drivers/clk/bcm/clk-bcm63xx.c | 22 + 5 files changed, 66 insertions(+), 8 deletions(-) create mode 100644 drivers/clk/bcm/clk-bcm63xx.c -- 2.1.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
[PATCH v4 3/3] ARM: dts: BCM63xx: Add ARMPLL device tree nodes
Add the ARM PLL controller which comes standard with the Cortex-A9 found
on the BCM63138 SoCs. This is the same controller as the one found in
the Broadcom iProc architecture, however, we have a separate compatible
string to indicate the integration difference, since the hardware is
different.
Signed-off-by: Florian Fainelli
---
Changes in v4:
- properly reflect the HW clocking and make it clear that periph_clk
is feeding into the ARM PLL clock domain
No changes in v2 or v3
arch/arm/boot/dts/bcm63138.dtsi | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/bcm63138.dtsi b/arch/arm/boot/dts/bcm63138.dtsi
index 34cd64051250..d0560e8cd6de 100644
--- a/arch/arm/boot/dts/bcm63138.dtsi
+++ b/arch/arm/boot/dts/bcm63138.dtsi
@@ -43,18 +43,31 @@
#address-cells = <1>;
#size-cells = <0>;
- arm_timer_clk: arm_timer_clk {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <5>;
- };
-
+ /* UBUS peripheral clock */
periph_clk: periph_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <5000>;
clock-output-names = "periph";
};
+
+ /* peripheral clock for system timer */
+ axi_clk: axi_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <&armpll>;
+ clock-div = <2>;
+ clock-mult = <1>;
+ };
+
+ /* APB bus clock */
+ apb_clk: apb_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-factor-clock";
+ clocks = <&armpll>;
+ clock-div = <4>;
+ clock-mult = <1>;
+ };
};
/* ARM bus */
@@ -93,14 +106,14 @@
compatible = "arm,cortex-a9-global-timer";
reg = <0x1e200 0x20>;
interrupts = ;
- clocks = <&arm_timer_clk>;
+ clocks = <&axi_clk>;
};
local_timer: local-timer@1e600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x1e600 0x20>;
interrupts = ;
- clocks = <&arm_timer_clk>;
+ clocks = <&axi_clk>;
};
twd_watchdog: watchdog@1e620 {
@@ -109,6 +122,13 @@
interrupts = ;
};
+ armpll: armpll {
+ #clock-cells = <0>;
+ compatible = "brcm,bcm63138-armpll";
+ clocks = <&periph_clk>;
+ reg = <0x2 0xf00>;
+ };
+
pmb0: reset-controller@4800c0 {
compatible = "brcm,bcm63138-pmb";
reg = <0x4800c0 0x10>;
--
2.1.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
[PATCH v4 1/3] clk: iproc: Extend binding to cover BCM63138
Broadcom BCM63138 DSL SoCs have the same ARMPLL clocking infrastructure as the Cygnus and iProc chips, add a dedicated compatible string and document that the ARMPLL node is a valid node for this chip. Acked-by: Rob Herring Signed-off-by: Florian Fainelli --- No changes in v4 Changes in v3: - added Rob's Acked-by tag No changes in v2 Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt index ede65a55e21b..0b35e71b39e8 100644 --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt @@ -208,3 +208,8 @@ These clock IDs are defined in: ch3_unused lcpll_ports 4 BCM_NS2_LCPLL_PORTS_CH3_UNUSED ch4_unused lcpll_ports 5 BCM_NS2_LCPLL_PORTS_CH4_UNUSED ch5_unused lcpll_ports 6 BCM_NS2_LCPLL_PORTS_CH5_UNUSED + +BCM63138 + +PLL and leaf clock compatible strings for BCM63138 are: +"brcm,bcm63138-armpll" -- 2.1.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: [alsa-devel] [PATCH V2 02/10] ASoC: img: Add driver for I2S input controller
On Thu, Oct 29, 2015 at 03:42:59PM +, Damien Horsley wrote: > For the I2S In, there is another issue with flushing on stream close. If > the stream is stopped, then reconfigured to use a larger number of > channels (without the stream being closed), then the per-channel fifos > will become inconsistent with each other. The new channels will have no > samples in their FIFOs, while the others may contain samples from the > previous stream. > Would hw_params be the correct place to flush instead? Yes, you could flush there (or in both places for that matter). signature.asc Description: PGP signature
[PATCH v9 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Tested-by: Heiko Stuebner
Tested-by: Javier Martinez Canillas
Signed-off-by: Yakir Yang
---
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 +++---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..74f0e80 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -analogix,need-force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9905081..8800164 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+ -analogix,need-force-hpd (optional)
-video interfaces (optional)
Deprecated properties for DisplayPort:
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index ec93917..be18388 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -31,6 +31,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- analogix,need-force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 563ffb1d..3842dbd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->need_force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+ dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+ analogix_dp_force_hpd(dp);
+
+ if (analogix_dp_get_plug_in_status(dp) != 0) {
+ dev
Re: [PATCH v8 0/17] Add Analogix Core Display Port Driver
Hi Heiko, On 10/30/2015 01:49 AM, Heiko Stuebner wrote: Am Mittwoch, 28. Oktober 2015, 16:15:43 schrieb Yakir Yang: Hi all, The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller share the same IP, so a lot of parts can be re-used. I split the common code into bridge directory, then rk3288 and exynos only need to keep some platform code. Cause I can't find the exact IP name of exynos dp controller, so I decide to name dp core driver with "analogix" which I find in rk3288 eDP TRM But there are still three light registers setting differents bewteen exynos and rk3288. 1. RK3288 have five special pll resigters which not indicata in exynos dp controller. 2. The address of DP_PHY_PD(dp phy power manager register) are different between rk3288 and exynos. 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug register). This series have been well tested on Rockchip platform with eDP panel on Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have tested on Samsung Snow and Peach Pit Chromebooks, and thanks to Javier@Samsung help to retest the whole series on Samsung Exynos5800 Peach Pi Chromebook, glad to say that things works rightlly. Patch 15/17 looks like it didn't make it? I haven't found it in neither my inbox nor in the linux-rockchip list archive? So I've used the v7 version for my tests. Oops, thanks for your reminding, I would send it now. This series on a rk3288-veyron-pinky and rk3288-veyron-jerry Tested-by: Heiko Stuebner Thanks, - Yakir -- 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 v3] Input: tsc2005 - Add support for tsc2004
On Fri, Oct 30, 2015 at 09:39:05AM +0900, Mark Brown wrote: > On Thu, Oct 29, 2015 at 03:23:31PM -0700, Dmitry Torokhov wrote: > > > However, you have regmap in the driver core already. Mark, is it > > possible to have regmap API also allow doing raw underlying protocol > > transfer so that consumers could issue command requests without needing > > to know if they need to do it over i2c or spi or whatever. Or we need a > > notion of command registers in regmap... > > I don't think it's a good idea to break the encapsulation of the regmap > and export the raw I/O functionality directly, there seem to be more bad > ways of using that than good. The driver must at some point know what > bus it is dealing with and be able to manage this itself. > > I don't know what "command registers" are. With this device, if the MSB of the first byte of the transaction is 1 then a convertor command is encoded in that byte instead of a register address. So here is my plan: - Add a function pointer for tsc2005_cmd in the struct tsc2005 - Put the spi and i2c tsc2005_cmd versions in their respective drivers - Pass the cmd functions to the core via tsc200x_probe Any objections? Other review suggestions before I code the revision? Am I doing too much with a single patch? -- 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 v3] Input: tsc2005 - Add support for tsc2004
On Thu, Oct 29, 2015 at 03:23:31PM -0700, Dmitry Torokhov wrote: > However, you have regmap in the driver core already. Mark, is it > possible to have regmap API also allow doing raw underlying protocol > transfer so that consumers could issue command requests without needing > to know if they need to do it over i2c or spi or whatever. Or we need a > notion of command registers in regmap... I don't think it's a good idea to break the encapsulation of the regmap and export the raw I/O functionality directly, there seem to be more bad ways of using that than good. The driver must at some point know what bus it is dealing with and be able to manage this itself. I don't know what "command registers" are. signature.asc Description: PGP signature
[PATCH v5 0/5] mfd: tps65912: Driver rewrite with DT support
In an effort to cleanup this driver and add Device Tree support the driver has been rewritten based on new driver styles and modern kernel driver helpers. This has nearly halved the lines of code while keeping all previous functionality. Platform file based initialization has been dropped as there is no examples of this use in the kernel. v1 can be found here: [1] v2: [2] v3: [3] v4: [4] Changes from v4: - Use mfd core to add sub-devices Changes from v3: - Reorganized regulator driver and related DT node - Other small fixes as discussed in v3 thread Changes from v2: - Split the series further into subsystems Changes from v1: - Split the rewrite into delete/create patches - Several small fixes as discussed in v1 thread [1] http://www.spinics.net/lists/devicetree/msg93863.html [2] http://www.spinics.net/lists/devicetree/msg95003.html [3] http://www.spinics.net/lists/devicetree/msg95133.html [4] http://www.spinics.net/lists/devicetree/msg96109.html Andrew F. Davis (5): Documentation: tps65912: Add DT bindings for the TPS65912 PMIC mfd: tps65912: Remove old driver in preparation for new driver mfd: tps65912: Add driver for the TPS65912 PMIC regulator: tps65912: Add regulator driver for the TPS65912 PMIC gpio: tps65912: Add GPIO driver for the TPS65912 PMIC .../devicetree/bindings/gpio/gpio-tps65912.txt | 16 + Documentation/devicetree/bindings/mfd/tps65912.txt | 51 ++ .../bindings/regulator/tps65912-regulator.txt | 28 + drivers/gpio/Kconfig | 2 +- drivers/gpio/gpio-tps65912.c | 289 - drivers/mfd/Kconfig| 22 +- drivers/mfd/Makefile | 3 +- drivers/mfd/tps65912-core.c| 297 - drivers/mfd/tps65912-i2c.c | 220 +++ drivers/mfd/tps65912-irq.c | 217 --- drivers/mfd/tps65912-spi.c | 221 +++ drivers/regulator/Kconfig | 2 +- drivers/regulator/tps65912-regulator.c | 711 + include/linux/mfd/tps65912.h | 211 +++--- 14 files changed, 812 insertions(+), 1478 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt create mode 100644 Documentation/devicetree/bindings/regulator/tps65912-regulator.txt rewrite drivers/gpio/gpio-tps65912.c (69%) rewrite drivers/mfd/tps65912-core.c (95%) rewrite drivers/mfd/tps65912-i2c.c (93%) delete mode 100644 drivers/mfd/tps65912-irq.c rewrite drivers/mfd/tps65912-spi.c (92%) rewrite drivers/regulator/tps65912-regulator.c (94%) -- 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 v5 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
This patch adds support for TPS65912 PMIC regulators.
The regulators set consists of 4 DCDCs and 10 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: Andrew F. Davis
---
drivers/regulator/Kconfig | 6 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/tps65912-regulator.c | 170 +
3 files changed, 177 insertions(+)
create mode 100644 drivers/regulator/tps65912-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 3cb2de9..1dec96a 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -727,6 +727,12 @@ config REGULATOR_TPS65910
help
This driver supports TPS65910/TPS65911 voltage regulator chips.
+config REGULATOR_TPS65912
+ tristate "TI TPS65912 Power regulator"
+ depends on MFD_TPS65912
+ help
+ This driver supports TPS65912 voltage regulator chip.
+
config REGULATOR_TPS80031
tristate "TI TPS80031/TPS80032 power regualtor driver"
depends on MFD_TPS80031
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 222ff5f..0f81749 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_REGULATOR_TPS65218) += tps65218-regulator.o
obj-$(CONFIG_REGULATOR_TPS6524X) += tps6524x-regulator.o
obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o
obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress.o
diff --git a/drivers/regulator/tps65912-regulator.c
b/drivers/regulator/tps65912-regulator.c
new file mode 100644
index 000..1c9e474
--- /dev/null
+++ b/drivers/regulator/tps65912-regulator.c
@@ -0,0 +1,170 @@
+/*
+ * Regulator driver for TPS65912x PMIC
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65218 driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+enum tps65912_regulators { DCDC1, DCDC2, DCDC3, DCDC4, LDO1, LDO2, LDO3,
+ LDO4, LDO5, LDO6, LDO7, LDO8, LDO9, LDO10 };
+
+#define TPS65912_REGULATOR(_name, _id, _of_match, _ops, _vr, _er, _lr) \
+ [_id] = { \
+ .name = _name,\
+ .of_match = of_match_ptr(_of_match), \
+ .id = _id, \
+ .ops= &_ops,\
+ .n_voltages = 64, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .vsel_reg = _vr, \
+ .vsel_mask = 0x3f, \
+ .enable_reg = _er, \
+ .enable_mask= BIT(7), \
+ .volt_table = NULL, \
+ .linear_ranges = _lr, \
+ .n_linear_ranges= ARRAY_SIZE(_lr), \
+ }
+
+static const struct regulator_linear_range tps65912_dcdc_ranges[] = {
+ REGULATOR_LINEAR_RANGE(50, 0x0, 0x3f, 5),
+};
+
+static const struct regulator_linear_range tps65912_ldo_ranges[] = {
+ REGULATOR_LINEAR_RANGE(80, 0x0, 0x20, 25000),
+ REGULATOR_LINEAR_RANGE(165, 0x21, 0x3c, 5),
+ REGULATOR_LINEAR_RANGE(310, 0x3d, 0x3f, 10),
+};
+
+/* Operations permitted on DCDCx */
+static struct regulator_ops tps65912_ops_dcdc = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+};
+
+/* Operations perm
[PATCH v5 1/5] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC
The TPS65912 PMIC contains several regulators and a GPIO controller.
Add bindings for the TPS65912 PMIC.
Signed-off-by: Andrew F. Davis
---
.../devicetree/bindings/gpio/gpio-tps65912.txt | 16 +++
Documentation/devicetree/bindings/mfd/tps65912.txt | 51 ++
.../bindings/regulator/tps65912-regulator.txt | 28
3 files changed, 95 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
create mode 100644
Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
new file mode 100644
index 000..0c5c05c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
@@ -0,0 +1,16 @@
+* TPS65912 GPIO Controller bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65912-gpio".
+ - gpio-controller : Marks the device node as a GPIO Controller.
+ - #gpio-cells : Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See include/dt-bindings/gpio/gpio.h for possible values.
+
+Example:
+
+ gpio4: tps65912_gpio {
+ compatible = "ti,tps65912-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/tps65912.txt
b/Documentation/devicetree/bindings/mfd/tps65912.txt
new file mode 100644
index 000..da5804a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65912.txt
@@ -0,0 +1,51 @@
+* TPS65912 Power Management Integrated Circuit bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65912".
+ - reg : Slave address or chip select number (I2C / SPI).
+ - interrupt-parent : The parent interrupt controller.
+ - interrupts : The interrupt line the device is connected to.
+ - interrupt-controller : Marks the device node as an interrupt controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, this should be 2.
+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger masks from
+ ../interrupt-controller/interrupts.txt
+
+Additional nodes defined in:
+ - Regulators: ../regulator/tps65912-regulator.txt
+ - GPIO: ../gpio/gpio-tps65912.txt.
+
+Example:
+
+ pmic: tps65912@2d {
+ compatible = "ti,tps65912";
+ reg = <0x2d>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ regulators {
+ compatible = "ti,tps65912-regulator";
+
+ dcdc1 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <190>;
+ regulator-max-microvolt = <190>;
+ };
+ };
+
+ gpio4: tps65912_gpio {
+ compatible = "ti,tps65912-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
new file mode 100644
index 000..4cd05fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
@@ -0,0 +1,28 @@
+* TPS65912 regulator bindings
+
+Required properties:
+ - compatible: "ti,tps65912-regulator"
+ - list of regulators provided by this controller, must be named
+ after their hardware counterparts: dcdc[1-4] and ldo[1-10]
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ tps65912_regulator {
+ compatible = "ti,tps65912-regulator";
+
+ dcdc1 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <190>;
+ regulator-max-microvolt = <190>;
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger
[PATCH v5 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC
This patch adds support for TPS65912 PMIC MFD core. It provides
communication through the I2C and SPI interfaces. It contains
the following components:
- Regulators
- GPIO controller
Signed-off-by: Andrew F. Davis
---
drivers/mfd/Kconfig | 26
drivers/mfd/Makefile | 3 +
drivers/mfd/tps65912-core.c | 122 +++
drivers/mfd/tps65912-i2c.c | 81 ++
drivers/mfd/tps65912-spi.c | 80 ++
include/linux/mfd/tps65912.h | 345 +++
6 files changed, 657 insertions(+)
create mode 100644 drivers/mfd/tps65912-core.c
create mode 100644 drivers/mfd/tps65912-i2c.c
create mode 100644 drivers/mfd/tps65912-spi.c
create mode 100644 include/linux/mfd/tps65912.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9a8df8e..1398340 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1167,6 +1167,32 @@ config MFD_TPS65910
if you say yes here you get support for the TPS65910 series of
Power Management chips.
+config MFD_TPS65912
+ tristate
+ select MFD_CORE
+ select REGMAP
+ select REGMAP_IRQ
+
+config MFD_TPS65912_I2C
+ tristate "TI TPS65912 Power Management chip with I2C"
+ select MFD_TPS65912
+ select REGMAP_I2C
+ depends on I2C
+ depends on OF || COMPILE_TEST
+ help
+ If you say yes here you get support for the TPS65912 series of
+ PM chips with I2C interface.
+
+config MFD_TPS65912_SPI
+ tristate "TI TPS65912 Power Management chip with SPI"
+ select MFD_TPS65912
+ select REGMAP_SPI
+ depends on SPI_MASTER
+ depends on OF || COMPILE_TEST
+ help
+ If you say yes here you get support for the TPS65912 series of
+ PM chips with SPI interface.
+
config MFD_TPS80031
bool "TI TPS80031/TPS80032 Power Management chips"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 004aa76..49c3530 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -69,6 +69,9 @@ obj-$(CONFIG_TPS6507X)+= tps6507x.o
obj-$(CONFIG_MFD_TPS65217) += tps65217.o
obj-$(CONFIG_MFD_TPS65218) += tps65218.o
obj-$(CONFIG_MFD_TPS65910) += tps65910.o
+obj-$(CONFIG_MFD_TPS65912) += tps65912-core.o
+obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o
+obj-$(CONFIG_MFD_TPS65912_SPI) += tps65912-spi.o
obj-$(CONFIG_MFD_TPS80031) += tps80031.o
obj-$(CONFIG_MENELAUS) += menelaus.o
diff --git a/drivers/mfd/tps65912-core.c b/drivers/mfd/tps65912-core.c
new file mode 100644
index 000..93a382e
--- /dev/null
+++ b/drivers/mfd/tps65912-core.c
@@ -0,0 +1,122 @@
+/*
+ * Core functions for TI TPS65912x PMIC
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65218 driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+static const struct mfd_cell tps65912_cells[] = {
+ {
+ .name = "tps65912-regulator",
+ .of_compatible = "ti,tps65912-regulator",
+ },
+ {
+ .name = "tps65912-gpio",
+ .of_compatible = "ti,tps65912-gpio",
+ },
+};
+
+static const struct regmap_irq tps65912_irqs[] = {
+ /* INT_STS IRQs */
+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_F, 0, TPS65912_INT_STS_PWRHOLD_F),
+ REGMAP_IRQ_REG(TPS65912_IRQ_VMON, 0, TPS65912_INT_STS_VMON),
+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRON, 0, TPS65912_INT_STS_PWRON),
+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRON_LP, 0, TPS65912_INT_STS_PWRON_LP),
+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_R, 0, TPS65912_INT_STS_PWRHOLD_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_HOTDIE, 0, TPS65912_INT_STS_HOTDIE),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_R, 0, TPS65912_INT_STS_GPIO1_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_F, 0, TPS65912_INT_STS_GPIO1_F),
+ /* INT_STS2 IRQs */
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_R, 1, TPS65912_INT_STS2_GPIO2_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_F, 1, TPS65912_INT_STS2_GPIO2_F),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_R, 1, TPS65912_INT_STS2_GPIO3_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_F, 1, TPS65912_INT_STS2_GPIO3_F),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_R, 1, TPS65912_INT_STS2_GPIO4_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_F, 1, TPS65912_INT_STS2_GPIO4_F),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO5_R,
[PATCH v5 2/5] mfd: tps65912: Remove old driver in preparation for new driver
The old tps65912 driver is being replaced, delete old driver.
Signed-off-by: Andrew F. Davis
Acked-by: Lee Jones
---
drivers/gpio/Kconfig | 6 -
drivers/gpio/Makefile | 1 -
drivers/gpio/gpio-tps65912.c | 153 --
drivers/mfd/Kconfig| 26 --
drivers/mfd/Makefile | 4 -
drivers/mfd/tps65912-core.c| 175 ---
drivers/mfd/tps65912-i2c.c | 139 -
drivers/mfd/tps65912-irq.c | 217 -
drivers/mfd/tps65912-spi.c | 141 -
drivers/regulator/Kconfig | 6 -
drivers/regulator/Makefile | 1 -
drivers/regulator/tps65912-regulator.c | 541 -
include/linux/mfd/tps65912.h | 328
13 files changed, 1738 deletions(-)
delete mode 100644 drivers/gpio/gpio-tps65912.c
delete mode 100644 drivers/mfd/tps65912-core.c
delete mode 100644 drivers/mfd/tps65912-i2c.c
delete mode 100644 drivers/mfd/tps65912-irq.c
delete mode 100644 drivers/mfd/tps65912-spi.c
delete mode 100644 drivers/regulator/tps65912-regulator.c
delete mode 100644 include/linux/mfd/tps65912.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4..fb28483 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -838,12 +838,6 @@ config GPIO_TPS65910
Select this option to enable GPIO driver for the TPS65910
chip family.
-config GPIO_TPS65912
- tristate "TI TPS65912 GPIO"
- depends on (MFD_TPS65912_I2C || MFD_TPS65912_SPI)
- help
- This driver supports TPS65912 gpio chip
-
config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f79a7c4..605bf89 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -96,7 +96,6 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
obj-$(CONFIG_GPIO_PALMAS) += gpio-palmas.o
obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
-obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
obj-$(CONFIG_GPIO_TS5500) += gpio-ts5500.o
obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
deleted file mode 100644
index 9cdbc0c..000
--- a/drivers/gpio/gpio-tps65912.c
+++ /dev/null
@@ -1,153 +0,0 @@
-/*
- * Copyright 2011 Texas Instruments Inc.
- *
- * Author: Margarita Olaya
- *
- * 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, or (at your
- * option) any later version.
- *
- * This driver is based on wm8350 implementation.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-struct tps65912_gpio_data {
- struct tps65912 *tps65912;
- struct gpio_chip gpio_chip;
-};
-
-#define to_tgd(gc) container_of(gc, struct tps65912_gpio_data, gpio_chip)
-
-static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
-{
- struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
- struct tps65912 *tps65912 = tps65912_gpio->tps65912;
- int val;
-
- val = tps65912_reg_read(tps65912, TPS65912_GPIO1 + offset);
-
- if (val & GPIO_STS_MASK)
- return 1;
-
- return 0;
-}
-
-static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
- int value)
-{
- struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
- struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
- if (value)
- tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
- GPIO_SET_MASK);
- else
- tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
- GPIO_SET_MASK);
-}
-
-static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
- int value)
-{
- struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
- struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
- /* Set the initial value */
- tps65912_gpio_set(gc, offset, value);
-
- return tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
- GPIO_CFG_MASK);
-}
-
-static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
-{
- struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
- struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
- return tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
- GPIO_CFG
[PATCH v5 5/5] gpio: tps65912: Add GPIO driver for the TPS65912 PMIC
This patch adds support for the TPS65912 PMIC GPIOs.
TPS65912 has five configurable GPIOs that can be used for several
purposes.
Signed-off-by: Andrew F. Davis
---
drivers/gpio/Kconfig | 6 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-tps65912.c | 136 +++
3 files changed, 143 insertions(+)
create mode 100644 drivers/gpio/gpio-tps65912.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index fb28483..82218fa 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -838,6 +838,12 @@ config GPIO_TPS65910
Select this option to enable GPIO driver for the TPS65910
chip family.
+config GPIO_TPS65912
+ tristate "TI TPS65912 GPIO"
+ depends on MFD_TPS65912
+ help
+ This driver supports TPS65912 gpio chip
+
config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 605bf89..f79a7c4 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -96,6 +96,7 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
obj-$(CONFIG_GPIO_PALMAS) += gpio-palmas.o
obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
+obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
obj-$(CONFIG_GPIO_TS5500) += gpio-ts5500.o
obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
new file mode 100644
index 000..db99a11
--- /dev/null
+++ b/drivers/gpio/gpio-tps65912.c
@@ -0,0 +1,136 @@
+/*
+ * TI TPS65912x GPIO Driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the Arizona GPIO driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera
+ */
+
+#include
+#include
+#include
+
+#include
+
+struct tps65912_gpio {
+ struct gpio_chip gpio_chip;
+ struct tps65912 *tps;
+};
+
+#define to_tps65912_gpio(gc) container_of(gc, struct tps65912_gpio, gpio_chip)
+
+static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
+{
+ struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+ int ret, val;
+
+ ret = regmap_read(gpio->tps->regmap, TPS65912_GPIO1 + offset, &val);
+ if (ret < 0)
+ return ret;
+
+ return val & GPIO_STS_MASK;
+}
+
+static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
+ int value)
+{
+ struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+ regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_SET_MASK, value ? GPIO_SET_MASK : 0);
+}
+
+static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
+ int value)
+{
+ struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+ /* Set the initial value */
+ tps65912_gpio_set(gc, offset, value);
+
+ return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, GPIO_CFG_MASK);
+}
+
+static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
+{
+ struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+ return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, 0);
+}
+
+static struct gpio_chip template_chip = {
+ .label = "tps65912-gpio",
+ .owner = THIS_MODULE,
+ .direction_input= tps65912_gpio_input,
+ .direction_output = tps65912_gpio_output,
+ .get= tps65912_gpio_get,
+ .set= tps65912_gpio_set,
+ .can_sleep = true,
+ .ngpio = 5,
+ .base = -1,
+};
+
+static int tps65912_gpio_probe(struct platform_device *pdev)
+{
+ struct tps65912_gpio *gpio;
+ int ret;
+
+ gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL);
+ if (!gpio)
+ return -ENOMEM;
+
+ gpio->tps = dev_get_drvdata(pdev->dev.parent);
+ gpio->gpio_chip = template_chip;
+ ret = gpiochip_add(&gpio->gpio_chip);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
+ return ret;
+ }
+
+ platform_
Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
On 10/28, Mark Brown wrote: > On Tue, Oct 27, 2015 at 01:49:17PM +0530, Viresh Kumar wrote: > > On 23-10-15, 01:39, Mark Brown wrote: > > > > I'm not sure that's > > > a place we want to end up just yet, I think it's safer to just have a > > > little bit of code in the kernel that glues things together in the cases > > > where this is needed. > > > So you are effectively saying that we shouldn't go ahead with multi > > regulator support in OPP library, right? > > Well, I think things like libraries for getting the data tables out of > DT are fine but I'm not convinced that trying to avoid having any device > specific code at all is sufficiently clear yet - as far as I know we're > mostly looking at a fairly small subset of devices still and with things > like sequencing in the mix it's a bit worrying to me to be putting it > all into an ABI intended to be used with no knowledge of the platform. Agreed. Looking at the current oppv2 binding I'm confused how it even works. It shows cpu-supply = <&phandle1>, <&phandle2>, etc. which doesn't work with the regulator bindings design. It seems that Viresh figured that out when implementing support for multiple regulators, so the binding was changed to put names in the opp tables and then use that to get regulators in the opp core. Urgh. I think I understand the goal here though. The goal is to move all the clk_get()/regulator_get() and clock and regulator API interactions into the OPP framework so that we can say "go to OPP at index 4" from the cpufreq core and the OPP framework takes care of actually doing the transition. Given that doing such a transition could be very machine specific, we probably ought to make the OPP framework flexible enough to let us decide how to do that. Perhaps we need to expand on the compatible string in the opp node to have compatible = "vendor,cool-transition", "operating-points-v2"? Then we can plug in vendor specific drivers that handle the frequency/voltage transition and they'll know that the fourth column in the voltage entry corresponds to this particular device's foo-supply and in what order to change voltages. A generic driver could exist for the simple case of one regulator and one clock that matches on "operating-points-v2". Or we can avoid doing any clk_get()/regulator_get() stuff inside the OPP framework, and let OPP consumers tell the OPP framework about each clock and regulator it wants the framework to manage on the consumer's behalf. It could even tell the framework which regulator corresponds to which voltage column and in what order to change the voltages so that the OPP framework doesn't need to know these device specific details. Then the consumer can still say go to OPP level 4 and that all works without introducing some new DT ABI. -- 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 0/6] Altera PCIe host controller driver with MSI support
On Wed, Oct 28, 2015 at 02:25:11PM +0800, Ley Foon Tan wrote: > On Wed, Oct 28, 2015 at 9:02 AM, Bjorn Helgaas wrote: > > On Tue, Oct 27, 2015 at 7:56 PM, Ley Foon Tan wrote: > >> On Tue, Oct 27, 2015 at 10:26 PM, Bjorn Helgaas wrote: > >>> Hi Ley, > >>> > >>> On Fri, Oct 23, 2015 at 06:27:09PM +0800, Ley Foon Tan wrote: > This is the 12th version of patch set to add support for Altera PCIe host > controller with MSI feature on Altera FPGA device families. This patchset > mainly resovle the comments from Bjorn. > > > This patchset is based on v4.3-rc6. > > v11->v12 changes: > - pcie-altera: use DECLARE_PCI_FIXUP_EARLY for pcie retrain fixup > - pcie-altera: move pcie_bus_configure_settings before > pci_bus_add_devices > - pcie-altera: add %d for irq bit in dev_err() > - pcie-altera: prevent enumeration of root complex resources in config > accessors > - Documentation: add Acked-by from Rob Herring > > History: > --- > [v1]: https://lkml.org/lkml/2015/7/28/395 > [v2]: https://lkml.org/lkml/2015/7/31/267 > [v3]: http://www.kernelhub.org/?msg=811940&p=2 > [v4]: https://lkml.org/lkml/2015/8/17/141 > [v5]: https://lkml.org/lkml/2015/8/25/238 > [v6]: https://lkml.org/lkml/2015/9/1/177 > [v7]: https://lkml.org/lkml/2015/9/20/193 > [v8]: http://www.kernelhub.org/?msg=853553&p=2 > [v9]: https://lkml.org/lkml/2015/10/13/998 > [v10]: https://lkml.org/lkml/2015/10/19/139 > [v11]: https://lkml.org/lkml/2015/10/22/206 > > > Ley Foon Tan (6): > arm: add msi.h to Kbuild > pci: add Altera PCI vendor ID > pci:host: Add Altera PCIe host controller driver > pci: altera: Add Altera PCIe MSI driver > Documentation: dt-bindings: pci: altera pcie device tree binding > MAINTAINERS: Add Altera PCIe and MSI drivers maintainer > > .../devicetree/bindings/pci/altera-pcie-msi.txt| 28 + > .../devicetree/bindings/pci/altera-pcie.txt| 49 ++ > MAINTAINERS| 16 + > arch/arm/include/asm/Kbuild| 1 + > drivers/pci/host/Kconfig | 16 + > drivers/pci/host/Makefile | 2 + > drivers/pci/host/pcie-altera-msi.c | 314 +++ > drivers/pci/host/pcie-altera.c | 580 > + > include/linux/pci_ids.h| 2 + > 9 files changed, 1008 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/pci/altera-pcie-msi.txt > create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt > create mode 100644 drivers/pci/host/pcie-altera-msi.c > create mode 100644 drivers/pci/host/pcie-altera.c > >>> > >>> I applied these to pci/host-altera for v4.4, thanks! > >>> > >>> I squashed these into three patches: > >>> > >>> - add msi.h to Kbuild > >>> - add Altera host driver (including DT binding and MAINTAINERS update) > >>> - add Altera MSI driver (including DT binding and MAINTAINERS update) > >>> > >>> Since the convention is to add PCI ID #defines only when they are used in > >>> multiple places, I replaced PCI_VENDOR_ID_ALTERA with 0x1172 in the single > >>> place it is used. > >> Hi Bjorn > >> > >> Thanks for applied these. > >> > >> By the way, I can't see pci/host-altera branch in your pci.git tree > >> yet. It takes some time to appear there? > > > > Sorry, I forgot to push it. It should be there now! > > > Yes, saw it now. It will merge to 'next' branch eventually? Yep, I just merged it to 'next' and pushed it. Bjorn -- 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 1/6] of: Add vendor prefix for Advantech Corporation
This patch adds vendor prefix for Advantech Corporation. Website: http://www.advantech.com/ Signed-off-by: Akshay Bhat --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 8fb0590..816383b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -10,6 +10,7 @@ adAvionic Design GmbH adapteva Adapteva, Inc. adhAD Holdings Plc. adiAnalog Devices, Inc. +advAdvantech Corporation aeroflexgaislerAeroflex Gaisler AB al Annapurna Labs allwinner Allwinner Technology Co., Ltd. -- 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 3/6] ARM: dts: imx: Add support for Advantech/GE Bx50v3
From: Justin Waters
Advantech has 3 carrier boards (B450v3, B650v3, B850v3) which use
the Advantech BA-16 module (based on iMX6D). This file has the
devicetree entries that are common to all 3 boards.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 206
1 file changed, 206 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
new file mode 100644
index 000..e9d97ee
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -0,0 +1,206 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx6q-ba16.dtsi"
+
+/ {
+ regulators {
+ /* regulator for wl18xx on sdhc4 */
+ wl18xx_vmmc: regulator@6 {
+ compatible = "regulator-fixed";
+ regulator-name = "vwl1807";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&pca9539 3 GPIO_ACTIVE_HIGH>;
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
+ reg_wlan: regulator@7 {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V_wlan";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = <&gpio6 14 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx6q-ba16-sgtl5000",
+"fsl,imx-audio-sgtl5000";
+ model = "imx6q-ba16-sgtl5000";
+ ssi-controller = <&ssi1>;
+ audio-codec = <&codec>;
+ audio-routing =
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT";
+ mux-int-port = <1>;
+ mux-ext-port = <4>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mclk: clock@0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <2200>;
+ };
+ };
+};
+
+&i2c1 {
+ pca9547: mux@70 {
+ compatible = "nxp,pca9547";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mux_i2c3: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0>;
+
+ ads7830: ads7830@48 {
+ compatible = "ti,ads7830";
+ reg = <0x48>;
+ };
+ };
+
+ mux_i2c4: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1>;
+
+ eeprom: eeprom@50 {
+ compatible = "atmel,24c08";
+ reg = <0x50>;
+ };
+
+ mpl3115: mpl3115@60 {
+ compatible = "fsl,mpl3115";
+ reg = <0x60>;
+ };
+ };
+
+ mux_i2c5: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+ };
+
+ mux_i2c6: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ codec: sgtl5000@0a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ clocks = <&mclk>;
+ VDDA-supply = <®_1p8v>;
+ VDDIO-supply = <®_3p3v>;
+ };
+ };
+
+ mux_i2c7: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4>;
+
+ pca9539: pca9539@74 {
+ compatible = "nxp,pca9539";
+
[PATCH 4/6] ARM: dts: imx: Add support for Advantech/GE B450v3
Add support for Advantech/GE B450v3 board.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-b450v3.dts | 75 ++
2 files changed, 76 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7d3e495..267b2be 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -308,6 +308,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-wandboard-revb1.dtb \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
+ imx6q-b450v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts
b/arch/arm/boot/dts/imx6q-b450v3.dts
new file mode 100644
index 000..d63d9e1
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -0,0 +1,75 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+ model = "Advantech MX6Q B450V3 QSeven Board";
+ compatible = "adv,imx6q-b450v3", "adv,imx6q-ba16", "fsl,imx6q";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+};
+
+&ldb {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+
+ lvds1: lvds-channel@1 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing1>;
+ timing1: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+
+};
--
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 5/6] ARM: dts: imx: Add support for Advantech/GE B650v3
Add support for Advantech/GE B650v3 board.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-b650v3.dts | 74 ++
2 files changed, 75 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 267b2be..3588160 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -309,6 +309,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
imx6q-b450v3.dtb \
+ imx6q-b650v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts
b/arch/arm/boot/dts/imx6q-b650v3.dts
new file mode 100644
index 000..29cbdb0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -0,0 +1,74 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+ model = "Advantech MX6Q B650V3 QSeven Board";
+ compatible = "adv,imx6q-b650v3", "adv,imx6q-ba16", "fsl,imx6q";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+};
+
+&ldb {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+
+ lvds1: lvds-channel@1 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing1>;
+ timing1: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+};
--
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 2/6] ARM: dts: imx: Add Advantech BA-16 Qseven module
From: Justin Waters
Add support for Advantech BA-16 module based on iMX6D processor
http://www2.advantech.com/products/medical_computing_system/dms-ba16/mod_64aa1566-169c-483d-97c8-c2c22c163fc3.aspx
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/imx6q-ba16.dtsi | 559 ++
1 file changed, 559 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi
diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi
b/arch/arm/boot/dts/imx6q-ba16.dtsi
new file mode 100644
index 000..3d47039
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
@@ -0,0 +1,559 @@
+/*
+ * Support for imx6 based Advantech DMS-BA16 Qseven module
+ *
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx6q.dtsi"
+#include
+
+/ {
+ memory {
+ reg = <0x1000 0x4000>;
+ };
+
+ clocks {
+ clk24m: clk24m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+
+ reg_usb_otg_vbus: regulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_usb_h1_vbus: regulator@2 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_1p8v: regulator@3 {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator@4 {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ lvds_ppen: regulator@5 {
+ compatible = "regulator-fixed";
+ regulator-name = "lvds_ppen";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+ };
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 500>;
+ brightness-levels = < 0 1 2 3 4 5 6 7 8 9
+ 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29
+ 30 31 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47 48 49
+ 50 51 52 53 54 55 56 57 58 59
+ 60 61 62 63 64 65 66 67 68 69
+ 70 71 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87 88 89
+ 90 91 92 93 94 95 96 97 98 99
+100 101 102 103 104 105 106 107 108 109
+110 111 112 113 114 115 116 117 118 119
+120 121 122 123 124 125 126 127 128 129
+130 131 132 133 134 135 136 137 138 139
+140 141 142 143 144 145 146 147 148 149
+150 151 152 153 154 155 156 157 158 159
+160 161 162 163 164 165 166 167 168 169
+170 171 172 173 174 175 176 177 178 179
+180 181 182 183 184 185 186 187 188 189
+190 191 192 193 194 195 196 197 198 199
+200 201 202 203 204 205 206 207 208 209
+210 211 212 213 214 215 216 217 218 219
+
[PATCH 6/6] ARM: dts: imx: Add support for Advantech/GE B850v3
Add support for Advantech/GE B850v3 board.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-b850v3.dts | 122 +
2 files changed, 123 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3588160..becb377 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -310,6 +310,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-arm2.dtb \
imx6q-b450v3.dtb \
imx6q-b650v3.dtb \
+ imx6q-b850v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts
b/arch/arm/boot/dts/imx6q-b850v3.dts
new file mode 100644
index 000..be6c0da
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+ model = "Advantech MX6Q B850V3 QSeven Board";
+ compatible = "adv,imx6q-b850v3", "adv,imx6q-ba16", "fsl,imx6q";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+};
+
+&ldb {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+ fsl,dual-channel;
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: stdp4028 {
+ clock-frequency = <137143857>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hback-porch = <100>;
+ hfront-porch = <40>;
+ vback-porch = <30>;
+ vfront-porch = <3>;
+ hsync-len = <10>;
+ vsync-len = <2>;
+ };
+ };
+ };
+};
+
+&i2c2 {
+ pca9547_ddc: mux@70 {
+ compatible = "nxp,pca9547";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mux_i2c11: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0>;
+ };
+
+ mux_i2c12: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1>;
+ };
+
+ mux_i2c13: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+ };
+
+ mux_i2c14: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+ };
+
+ mux_i2c15: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4>;
+ };
+
+ mux_i2c16: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x5>;
+ };
+
+ mux_i2c17: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x6>;
+ };
+
+ mux_i2c18: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x7>;
+ };
+ };
+};
+
+&hdmi {
+ ddc-i2c-bus = <&mux_i2c11>;
+};
+
+&mux_i2c3 {
+ ads7830_2: ads7830@4a {
+ compatible = "ti,ads7830";
+ reg = <0x4a>;
+ };
+};
--
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 0/6] ARM: dts: Add Advantech board support
This series aims to add Advantech BA-16 module (iMX6 based) and board support. Module details: http://www2.advantech.com/products/computer-on-module/rom-7420/mod_a091469f-b4b1-4929-be51-a9237d5ba40a.aspx This series has been tested against linux-next tag next-20151022. Akshay Bhat (4): of: Add vendor prefix for Advantech Corporation ARM: dts: imx: Add support for Advantech/GE B450v3 ARM: dts: imx: Add support for Advantech/GE B650v3 ARM: dts: imx: Add support for Advantech/GE B850v3 Justin Waters (2): ARM: dts: imx: Add Advantech BA-16 Qseven module ARM: dts: imx: Add support for Advantech/GE Bx50v3 .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/Makefile | 3 + arch/arm/boot/dts/imx6q-b450v3.dts | 75 +++ arch/arm/boot/dts/imx6q-b650v3.dts | 74 +++ arch/arm/boot/dts/imx6q-b850v3.dts | 122 + arch/arm/boot/dts/imx6q-ba16.dtsi | 559 + arch/arm/boot/dts/imx6q-bx50v3.dtsi| 206 7 files changed, 1040 insertions(+) create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi -- 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] ARM: dts: rockchip: Setup ethernet0 alias for u-boot
Am Donnerstag, 29. Oktober 2015, 22:39:24 schrieb Sjoerd Simons:
> On Thu, 2015-10-29 at 21:52 +0100, Heiko Stuebner wrote:
> > Hi Sjoerd,
> >
> > Am Donnerstag, 29. Oktober 2015, 21:44:57 schrieb Sjoerd Simons:
> > > Add an ethernet0 alias for the wired network card and an all 0
> > > default
> > > mac address so that u-boot can find the device-node and fill in the
> > > mac address.
> > >
> > > Signed-off-by: Sjoerd Simons
> > > ---
> > >
> > > arch/arm/boot/dts/rk3288-rock2-square.dts | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/rk3288-rock2-square.dts
> > > b/arch/arm/boot/dts/rk3288-rock2-square.dts
> > > index 0ef065d..a029ebf 100644
> > > --- a/arch/arm/boot/dts/rk3288-rock2-square.dts
> > > +++ b/arch/arm/boot/dts/rk3288-rock2-square.dts
> > > @@ -45,6 +45,10 @@
> > > model = "Radxa Rock 2 Square";
> > > compatible = "radxa,rock2-square", "rockchip,rk3288";
> > >
> > > + aliases {
> > > + ethernet0 = &gmac;
> > > + };
> > > +
> >
> > wouldn't it make more sense to have this in the rk3288.dtsi, so to
> > keep
> > every board from having to add this alias?
>
> Hmm, that would work. Thought it would add an alias point to a disabled
> node for boards that don't have a wired interface. If that isn't an
> issue it can indeed be moved there.
we also have aliases for all i2c, mmc, spi, uart etc nodes ... some of
which may stay disabled. But i2c5 stays i2c5 everywhere
and similarly the internal ethernet will stay ethernet0 everywhere too.
And for the "fluffy" good feeling, a lot of other socs also seem to keep their
ethernet0 aliases in the central dtsi (allwinner, freescale, socfpga),
so it's not obviously wrong :-) .
Heiko
--
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 v3] Input: tsc2005 - Add support for tsc2004
On Thu, Oct 29, 2015 at 04:53:53PM -0500, Michael Welling wrote: > On Thu, Oct 29, 2015 at 10:46:20PM +0100, Arnd Bergmann wrote: > > On Thursday 29 October 2015 09:22:37 Michael Welling wrote: > > > > > > > > All errors (new ones prefixed by >>): > > > > > > > >drivers/built-in.o: In function `tsc2005_cmd': > > > > >> tsc200x-core.c:(.text+0x2ae07f): undefined reference to > > > > >> `i2c_smbus_write_byte' > > > > > > Argh! > > > > > > How do I fix this one? > > > > > > > Move all the I2C specific code into the tsc2004.c file and remove the > > #ifdef. The problem is that tsc200x-core.c is used as built-in when > > TOUCHSCREEN_TSC2005=y and I2C=m, so it can't call functions that are > > defined in i2c-core.c. > > How would I call the function from the core then? You can pass a cmd function from the transport module into core module and store and use it. However, you have regmap in the driver core already. Mark, is it possible to have regmap API also allow doing raw underlying protocol transfer so that consumers could issue command requests without needing to know if they need to do it over i2c or spi or whatever. Or we need a notion of command registers in regmap... 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 v2 0/8] arm: dts: lpc32xx: updates to LPC32xx SoC and boards
Hi Arnd, On 21.10.2015 17:45, Arnd Bergmann wrote: > On Sunday 18 October 2015 00:35:49 Vladimir Zapolskiy wrote: >> The change improves description of NXP LPC32xx hardware, among >> important changes it adds standard timers and external memory >> controller nodes, splits PWM device node into two, >> >> Changes from v1 to v2: >> - removed v1 2/5 "arm: dts: lpc32xx: fix improper usage of ranges property" >> - v1 4/5 "arm: dts: lpc32xx: remove unneeded cell settings from cpus" >> is replaced by v2 3/8 "arm: dts: lpc32xx: add reg property to cpu device >> node" >> - new change, sets physical memory offset for EA3250 and PHY3250 v5/8 >> - new change, added EMC device node v2 6/8 >> - new change, added standard timer nodes v2 7/8 >> - new change, grouped USB subdevices together v2 8/8 > > Looks ok to me. Who should pick them up? I haven't seen pull requests from > Roland in a while. If he's still interested in the port, I think it would be > best if he could create a branch here. I still don't see a reply from Roland, if possible please apply the patches to arm-soc this time. > If not, we can pick them up directly this time into arm-soc, but then we > should find a new maintainer. > I have some interest in LPC32xx SoC, I know the SoC very well (authored LPC32xx support in U-boot) and there are more patches in my queue, if there is no objection from anyone, I would be happy to become a maintainer of the platform. -- With best wishes, Vladimir -- 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] clk: add clock support for NXP LPC32xx
Add support for all configurable clocks found on NXP LPC32xx SoC.
The list contains several heterogenous groups of clocks:
* system clocks including multiple dividers and muxes,
* x397 PLL, HCLK PLL and USB PLL,
* peripheral clocks inherited from rtc, hclk and pclk,
* USB controller clocks: AHB slave, I2C, OTG, OHCI and device.
Signed-off-by: Vladimir Zapolskiy
---
checkpatch.pl generates a number of COMPLEX_MACRO false positives, to fix
it I've sent a patch to Joe: https://lkml.org/lkml/2015/10/29/505
drivers/clk/nxp/Makefile |1 +
drivers/clk/nxp/clk-lpc32xx.c | 1411 +
include/dt-bindings/clock/lpc32xx-clock.h | 55 ++
3 files changed, 1467 insertions(+)
create mode 100644 drivers/clk/nxp/clk-lpc32xx.c
create mode 100644 include/dt-bindings/clock/lpc32xx-clock.h
diff --git a/drivers/clk/nxp/Makefile b/drivers/clk/nxp/Makefile
index 7f608b0..607bd48 100644
--- a/drivers/clk/nxp/Makefile
+++ b/drivers/clk/nxp/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_ARCH_LPC18XX) += clk-lpc18xx-cgu.o
obj-$(CONFIG_ARCH_LPC18XX) += clk-lpc18xx-ccu.o
+obj-$(CONFIG_ARCH_LPC32XX) += clk-lpc32xx.o
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
new file mode 100644
index 000..8a4aa7f
--- /dev/null
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -0,0 +1,1411 @@
+/*
+ * Copyright 2015 Vladimir Zapolskiy
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#undef pr_fmt
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+/* Common bitfield definitions for x397 PLL (lock), USB PLL and HCLK PLL */
+#define PLL_CTRL_ENABLEBIT(16)
+#define PLL_CTRL_BYPASSBIT(15)
+#define PLL_CTRL_DIRECTBIT(14)
+#define PLL_CTRL_FEEDBACK BIT(13)
+#define PLL_CTRL_POSTDIV (BIT(12)|BIT(11))
+#define PLL_CTRL_PREDIV(BIT(10)|BIT(9))
+#define PLL_CTRL_FEEDDIV (0xFF << 1)
+#define PLL_CTRL_LOCK BIT(0)
+
+/* Clock registers on System Control Block */
+#define LPC32XX_CLKPWR_DEBUG_CTRL 0x00
+#define LPC32XX_CLKPWR_USB_DIV 0x1C
+#define LPC32XX_CLKPWR_HCLKDIV_CTRL0x40
+#define LPC32XX_CLKPWR_PWR_CTRL0x44
+#define LPC32XX_CLKPWR_PLL397_CTRL 0x48
+#define LPC32XX_CLKPWR_OSC_CTRL0x4C
+#define LPC32XX_CLKPWR_SYSCLK_CTRL 0x50
+#define LPC32XX_CLKPWR_LCDCLK_CTRL 0x54
+#define LPC32XX_CLKPWR_HCLKPLL_CTRL0x58
+#define LPC32XX_CLKPWR_ADCCLK_CTRL10x60
+#define LPC32XX_CLKPWR_USB_CTRL0x64
+#define LPC32XX_CLKPWR_SSP_CTRL0x78
+#define LPC32XX_CLKPWR_I2S_CTRL0x7C
+#define LPC32XX_CLKPWR_MS_CTRL 0x80
+#define LPC32XX_CLKPWR_MACCLK_CTRL 0x90
+#define LPC32XX_CLKPWR_TEST_CLK_CTRL 0xA4
+#define LPC32XX_CLKPWR_I2CCLK_CTRL 0xAC
+#define LPC32XX_CLKPWR_KEYCLK_CTRL 0xB0
+#define LPC32XX_CLKPWR_ADCCLK_CTRL 0xB4
+#define LPC32XX_CLKPWR_PWMCLK_CTRL 0xB8
+#define LPC32XX_CLKPWR_TIMCLK_CTRL 0xBC
+#define LPC32XX_CLKPWR_TIMCLK_CTRL10xC0
+#define LPC32XX_CLKPWR_SPI_CTRL0xC4
+#define LPC32XX_CLKPWR_FLASHCLK_CTRL 0xC8
+#define LPC32XX_CLKPWR_UART3_CLK_CTRL 0xD0
+#define LPC32XX_CLKPWR_UART4_CLK_CTRL 0xD4
+#define LPC32XX_CLKPWR_UART5_CLK_CTRL 0xD8
+#define LPC32XX_CLKPWR_UART6_CLK_CTRL 0xDC
+#define LPC32XX_CLKPWR_UART_CLK_CTRL 0xE4
+#define LPC32XX_CLKPWR_DMA_CLK_CTRL0xE8
+
+/* Clock registers on USB controller */
+#define LPC32XX_USB_CLK_CTRL 0xF4
+#define LPC32XX_USB_CLK_STS0xF8
+
+static void __iomem *clk_vbase;
+static void __iomem *usb_clk_vbase;
+
+enum {
+ LPC32XX_USB_CLK_OTG = LPC32XX_USB_CLK_HOST + 1,
+ LPC32XX_USB_CLK_AHB,
+
+ LPC32XX_USB_CLK_MAX = LPC32XX_USB_CLK_AHB + 1,
+};
+
+enum {
+ /* Start from the last defined clock in dt bindings */
+ LPC32XX_CLK_ADC_DIV = LPC32XX_CLK_ADC + 1,
+ LPC32XX_CLK_ADC_RTC,
+ LPC32XX_CLK_TEST1,
+ LPC32XX_CLK_TEST2,
+
+ /* System clocks, PLL 397x and HCLK PLL clocks */
+ LPC32XX_CLK_OSC,
+ LPC32XX_CLK_SYS,
+ LPC32XX_CLK_PLL397X,
+ LPC32XX_CLK_HCLK_PLL,
+ LPC32XX_CLK_HCLK_DIV_PERIPH,
+ LPC32XX_CLK_HCLK_DIV,
+ LPC32XX_CLK_HCLK,
+ LPC32XX_CLK_PERIPH,
+ LPC32XX_CLK_ARM,
+ LPC32XX_CLK_ARM_VFP,
+
+ /* USB clocks */
+ LPC32XX_CLK_USB_PLL,
+ LPC32XX_CLK_USB_DIV,
+ LPC32XX_CLK_USB,
+
+ /* Only one control PWR_CTRL[10] for both muxes */
+ LPC32XX_CLK_PERIPH_HCLK_MUX,
+ LPC32XX_CLK_PERIPH_ARM_MUX,
+
+ /* Only one control PWR_CTRL[2] f
Re: [PATCH v3] Input: tsc2005 - Add support for tsc2004
On Thu, Oct 29, 2015 at 10:46:20PM +0100, Arnd Bergmann wrote: > On Thursday 29 October 2015 09:22:37 Michael Welling wrote: > > > > > > All errors (new ones prefixed by >>): > > > > > >drivers/built-in.o: In function `tsc2005_cmd': > > > >> tsc200x-core.c:(.text+0x2ae07f): undefined reference to > > > >> `i2c_smbus_write_byte' > > > > Argh! > > > > How do I fix this one? > > > > Move all the I2C specific code into the tsc2004.c file and remove the > #ifdef. The problem is that tsc200x-core.c is used as built-in when > TOUCHSCREEN_TSC2005=y and I2C=m, so it can't call functions that are > defined in i2c-core.c. How would I call the function from the core then? -Michael > > 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] arm64: dts: Added syscon-reboot node for FSL's LS2085A SoC
On Wednesday 28 October 2015 16:09:44 J. German Rivera wrote:
> + rst_ccsr: rstccsr@1E6 {
> + compatible = "syscon";
> + reg = <0x0 0x1E6 0x0 0x1>;
> + };
> +
>
What does 'rstccsr' stand for? Is this by chance a reset controller?
If so, we probably want a real driver for it rather than just a
syscon.
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 v3] Input: tsc2005 - Add support for tsc2004
On Thursday 29 October 2015 09:22:37 Michael Welling wrote: > > > > All errors (new ones prefixed by >>): > > > >drivers/built-in.o: In function `tsc2005_cmd': > > >> tsc200x-core.c:(.text+0x2ae07f): undefined reference to > > >> `i2c_smbus_write_byte' > > Argh! > > How do I fix this one? > Move all the I2C specific code into the tsc2004.c file and remove the #ifdef. The problem is that tsc200x-core.c is used as built-in when TOUCHSCREEN_TSC2005=y and I2C=m, so it can't call functions that are defined in i2c-core.c. 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 v7 0/3] Add Freescale LS1043a device tree
Hi ARM SoC maintainers, After several rounds of review I think the patch series is generally in good shape. Can someone from the ARM maintainers group help to pick these patches up? Some small updates to v7: - Re-grouped the series to only include device tree related patches for arm-soc subsystem. - Rebased the patches on latest LS2080 patches from Bhupesh to apply cleanly. Regards, Leo -- 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] ARM: dts: rockchip: Setup ethernet0 alias for u-boot
On Thu, 2015-10-29 at 21:52 +0100, Heiko Stuebner wrote:
> Hi Sjoerd,
>
> Am Donnerstag, 29. Oktober 2015, 21:44:57 schrieb Sjoerd Simons:
> > Add an ethernet0 alias for the wired network card and an all 0
> > default
> > mac address so that u-boot can find the device-node and fill in the
> > mac address.
> >
> > Signed-off-by: Sjoerd Simons
> > ---
> >
> > arch/arm/boot/dts/rk3288-rock2-square.dts | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/rk3288-rock2-square.dts
> > b/arch/arm/boot/dts/rk3288-rock2-square.dts
> > index 0ef065d..a029ebf 100644
> > --- a/arch/arm/boot/dts/rk3288-rock2-square.dts
> > +++ b/arch/arm/boot/dts/rk3288-rock2-square.dts
> > @@ -45,6 +45,10 @@
> > model = "Radxa Rock 2 Square";
> > compatible = "radxa,rock2-square", "rockchip,rk3288";
> >
> > + aliases {
> > + ethernet0 = &gmac;
> > + };
> > +
>
> wouldn't it make more sense to have this in the rk3288.dtsi, so to
> keep
> every board from having to add this alias?
Hmm, that would work. Thought it would add an alias point to a disabled
node for boards that don't have a wired interface. If that isn't an
issue it can indeed be moved there.
>
> > chosen {
> > stdout-path = "serial2:115200n8";
> > };
> > @@ -130,6 +134,8 @@
> > };
> >
> > &gmac {
> > + /* To be filled in by U-Boot */
> > + mac-address = [00 00 00 00 00 00];
> > status = "ok";
> > };
>
> I guess the same applies for the mac placeholder.
In any case they should be in the same dts{i}.
--
Sjoerd Simons
Collabora Ltd.
--
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 3/3] ARM64: dts: add LS1043a-RDB board support
From: Shaohui Xie
Signed-off-by: Shaohui Xie
Signed-off-by: Mingkai Hu
Signed-off-by: Wenbin Song
Signed-off-by: Hou Zhiqiang
Signed-off-by: Li Yang
---
V7:
- Rebased on latest LS2080 patches.
V6:
- No change.
V5:
- Move gic, timer and pmu nodes out of SoC node.
V4:
- Add soc node with simple-bus compatible.
- Add property interrupt-affinity for armv8 pmuv3 node.
V3:
- Add device tree node for SATA.
- Remove properity enable-method for all cpu node.
Remove reserved memory region for spin-table.
V2:
- Add secondary core boot method.
- Move out the sysclk node from the clockgen node.
- Correct the reg size of GICC.
arch/arm64/boot/dts/freescale/Makefile| 1 +
arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 116 ++
2 files changed, 117 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile
b/arch/arm64/boot/dts/freescale/Makefile
index c4957a4..f3c2516 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -1,6 +1,7 @@
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-rdb.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
new file mode 100644
index 000..7a351e2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts
@@ -0,0 +1,116 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ *
+ * Copyright 2014-2015, Freescale Semiconductor
+ *
+ * Mingkai Hu
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library 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, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "fsl-ls1043a.dtsi"
+
+/ {
+ model = "LS1043A RDB Board";
+};
+
+&i2c0 {
+ status = "okay";
+ ina220@40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <1000>;
+ };
+ adt7461a@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ eeprom@56 {
+ compatible = "at24,24c512";
+ reg = <0x52>;
+ };
+ eeprom@57 {
+ compatible = "at24,24c512";
+ reg = <0x53>;
+ };
+ rtc@68 {
+ compatible = "pericom,pt7c4338";
+ reg = <0x68>;
+ };
+};
+
+&ifc {
+ status = "okay";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ /* NOR, NAND Flashes and FPGA on board */
+ ranges = <0x0 0x0 0x0 0x6000 0x0800
+ 0x1 0x0 0x0 0x7e80 0x0001
+ 0x2 0x0 0x0 0x7fb0 0x0100>;
+
+ nor@0,0 {
+ compatible = "cfi-flash";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x0 0x0 0x800>;
+
[PATCH V7 2/3] ARM64: dts: add Freescale LS1043a SoC support
From: Mingkai Hu
LS1043a is an SoC with 4 ARMv8 A53 cores and most other IP blocks
are similar to LS1021a which also complies to Freescale Chassis 2.1 spec.
Created LS1043a SoC DTSI file to be included by board level DTS files.
Signed-off-by: Li Yang
Signed-off-by: Hou Zhiqiang
Signed-off-by: Mingkai Hu
Signed-off-by: Wenbin Song
---
V7:
- Some update to patch description.
V6:
- No change.
V5:
- Move gic, timer and pmu nodes out of SoC node.
V4:
- Add soc node with simple-bus compatible.
- Add property interrupt-affinity for armv8 pmuv3 node.
V3:
- Add device tree node for SATA.
- Remove properity enable-method for all cpu node.
Remove reserved memory region for spin-table.
V2:
- Add secondary core boot method.
- Move out the sysclk node from the clockgen node.
- Correct the reg size of GICC.
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 525 +
1 file changed, 525 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
new file mode 100644
index 000..bf5af82
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -0,0 +1,525 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1043A family SoC.
+ *
+ * Copyright 2014-2015, Freescale Semiconductor
+ *
+ * Mingkai Hu
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library 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, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+ compatible = "fsl,ls1043a";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ /*
+* We expect the enable-method for cpu's to be "psci", but this
+* is dependent on the SoC FW, which will fill this in.
+*
+* Currently supported enable-method is psci v0.2
+*/
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x0>;
+ clocks = <&clockgen 1 0>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x1>;
+ clocks = <&clockgen 1 0>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x2>;
+ clocks = <&clockgen 1 0>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x0 0x3>;
+ clocks = <&clockgen 1 0>;
+ };
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x0 0x8000 0 0x8000>;
+
[PATCH V7 1/3] Documentation: DT: Add entry for Freescale LS1043a-RDB board
From: Mingkai Hu Signed-off-by: Mingkai Hu Signed-off-by: Hou Zhiqiang --- v2-v7: no change Documentation/devicetree/bindings/arm/fsl.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index 34c88b0..752a685 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -131,6 +131,10 @@ Example: Freescale ARMv8 based Layerscape SoC family Device Tree Bindings +LS1043A ARMv8 based RDB Board +Required root node properties: +- compatible = "fsl,ls1043a-rdb", "fsl,ls1043a"; + LS2080A ARMv8 based Simulator model Required root node properties: - compatible = "fsl,ls2080a-simu", "fsl,ls2080a"; -- 2.3.3 -- 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] ARM: dts: rockchip: Setup ethernet0 alias for u-boot
Hi Sjoerd,
Am Donnerstag, 29. Oktober 2015, 21:44:57 schrieb Sjoerd Simons:
> Add an ethernet0 alias for the wired network card and an all 0 default
> mac address so that u-boot can find the device-node and fill in the
> mac address.
>
> Signed-off-by: Sjoerd Simons
> ---
>
> arch/arm/boot/dts/rk3288-rock2-square.dts | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-rock2-square.dts
> b/arch/arm/boot/dts/rk3288-rock2-square.dts
> index 0ef065d..a029ebf 100644
> --- a/arch/arm/boot/dts/rk3288-rock2-square.dts
> +++ b/arch/arm/boot/dts/rk3288-rock2-square.dts
> @@ -45,6 +45,10 @@
> model = "Radxa Rock 2 Square";
> compatible = "radxa,rock2-square", "rockchip,rk3288";
>
> + aliases {
> + ethernet0 = &gmac;
> + };
> +
wouldn't it make more sense to have this in the rk3288.dtsi, so to keep
every board from having to add this alias?
> chosen {
> stdout-path = "serial2:115200n8";
> };
> @@ -130,6 +134,8 @@
> };
>
> &gmac {
> + /* To be filled in by U-Boot */
> + mac-address = [00 00 00 00 00 00];
> status = "ok";
> };
I guess the same applies for the mac placeholder.
Heiko
--
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: arm: Fixed typo in socfpga fpga mgr example
On Thu, Oct 29, 2015 at 1:47 PM, Moritz Fischer
wrote:
> Addresses should not be prefixed contain '0x' in nodes.
>
> Signed-off-by: Moritz Fischer
> ---
> Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
> b/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
> index 9b027a6..823f3d6 100644
> --- a/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
> +++ b/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
> @@ -9,7 +9,7 @@ Required properties:
>
> Example:
>
> - hps_0_fpgamgr: fpgamgr@0xff706000 {
> + hps_0_fpgamgr: fpgamgr@0ff706000 {
*grrr* ... should've been fpgamgr@ff706000 obviously ...
> compatible = "altr,socfpga-fpga-mgr";
> reg = <0xFF706000 0x1000
>0xFFB9 0x1000>;
> --
> 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] Documentation: arm: Fixed typo in socfpga fpga mgr example
Addresses should not be prefixed contain '0x' in nodes.
Signed-off-by: Moritz Fischer
---
Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
b/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
index 9b027a6..823f3d6 100644
--- a/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
+++ b/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt
@@ -9,7 +9,7 @@ Required properties:
Example:
- hps_0_fpgamgr: fpgamgr@0xff706000 {
+ hps_0_fpgamgr: fpgamgr@0ff706000 {
compatible = "altr,socfpga-fpga-mgr";
reg = <0xFF706000 0x1000
0xFFB9 0x1000>;
--
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] ARM: dts: rockchip: Setup ethernet0 alias for u-boot
Add an ethernet0 alias for the wired network card and an all 0 default
mac address so that u-boot can find the device-node and fill in the
mac address.
Signed-off-by: Sjoerd Simons
---
arch/arm/boot/dts/rk3288-rock2-square.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-rock2-square.dts
b/arch/arm/boot/dts/rk3288-rock2-square.dts
index 0ef065d..a029ebf 100644
--- a/arch/arm/boot/dts/rk3288-rock2-square.dts
+++ b/arch/arm/boot/dts/rk3288-rock2-square.dts
@@ -45,6 +45,10 @@
model = "Radxa Rock 2 Square";
compatible = "radxa,rock2-square", "rockchip,rk3288";
+ aliases {
+ ethernet0 = &gmac;
+ };
+
chosen {
stdout-path = "serial2:115200n8";
};
@@ -130,6 +134,8 @@
};
&gmac {
+ /* To be filled in by U-Boot */
+ mac-address = [00 00 00 00 00 00];
status = "ok";
};
--
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: [RFC] rpi: add support to enable usb power domain
Alexander Aring writes:
> 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
> Cc: Andy Whitcroft
> Cc: Joe Perches
> Signed-off-by: Alexander Aring
> ---
> First:
> I cc'ed Andy Whitcroft and Joe Perches here, because this patch will
> generate a false positive for checkpatch and checkpatch told me to
> cc checkpatch maintainers if this occurs:
>
> ERROR: Macros with complex values should be enclosed in parentheses
> #191: FILE: drivers/firmware/raspberrypi.c:26:
> +#define RPI_POWER_DOMAIN(_domain, _name) \
> + [_domain] = \
> + { \
> ...
>
> Second:
> This patch based on linus/master and requires the rpi-firmware patch.
>
> Third:
> The barebox regulator doesn't support right now to enable/disable
> regulators at runtime but I want to bring this mainline in the next
> days. So you can't check yourself if the above scripts working right
> now. I describe it here to show you what exactly I tested.
>
> changes since Eric Anholts "power domain" patch:
> - add for me all known power domains of the RPi, it contains the domains
>0 - 9.
Note: None of the power domain enums other than the ones I'd had in my
patch are actually connected to anything in the firmware. I don't think
we should be adding them, given that.
signature.asc
Description: PGP signature
Re: [PATCH v8 0/17] Add Analogix Core Display Port Driver
Am Mittwoch, 28. Oktober 2015, 16:15:43 schrieb Yakir Yang: > Hi all, > >The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller > share the same IP, so a lot of parts can be re-used. I split the common > code into bridge directory, then rk3288 and exynos only need to keep > some platform code. Cause I can't find the exact IP name of exynos dp > controller, so I decide to name dp core driver with "analogix" which I > find in rk3288 eDP TRM > > But there are still three light registers setting differents bewteen > exynos and rk3288. > 1. RK3288 have five special pll resigters which not indicata in exynos >dp controller. > 2. The address of DP_PHY_PD(dp phy power manager register) are different >between rk3288 and exynos. > 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug >register). > > This series have been well tested on Rockchip platform with eDP panel on > Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have > tested on Samsung Snow and Peach Pit Chromebooks, and thanks to Javier@Samsung > help to retest the whole series on Samsung Exynos5800 Peach Pi Chromebook, > glad to say that things works rightlly. Patch 15/17 looks like it didn't make it? I haven't found it in neither my inbox nor in the linux-rockchip list archive? So I've used the v7 version for my tests. This series on a rk3288-veyron-pinky and rk3288-veyron-jerry Tested-by: Heiko Stuebner -- 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 0/4] [PATCH v4 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
On 29 October 2015 at 18:12, 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 > > Pinctrl support is necessary in order to correctly configure > multifunctional pins of the Exynos chip. > > 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 | 50 ++- > arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++ > arch/arm/boot/dts/exynos5410.dtsi | 15 ++ > arch/arm/mach-exynos/Kconfig | 2 +- > drivers/soc/samsung/Kconfig| 2 +- > drivers/soc/samsung/exynos-srom.c | 58 > +- > 6 files changed, 162 insertions(+), 6 deletions(-) > Something wrong here, I am not able to find V4 1/4 and 3/4 in this mailing list. Thanks, Pankaj Dubey > -- > 2.4.4 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] ARM: dts: Add Ethernet chip to SMDK5410
Hi Pavel,
On 29 October 2015 at 18:12, Pavel Fedin wrote:
> 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 | 41
> +++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
> b/arch/arm/boot/dts/exynos5410-smdk5410.dts
> index cebeaab..311e7be 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,23 @@
> &uart2 {
> status = "okay";
> };
> +
> +&sromc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
> +
> + ethernet@0700 {
> + compatible = "smsc,lan9115";
> + reg = <0x0700 0x1>;
> + phy-mode = "mii";
> + interrupt-parent = <&gpx0>;
> + interrupts = <5 8>;
> + reg-io-width = <2>;
> + smsc,irq-push-pull;
> + smsc,force-internal-phy;
> +
> + samsung,srom-bank = <3>;
> + samsung,srom-data-width = <2>;
> + samsung,srom-timing = <1 9 12 1 9 1 1>;
I think this is not correct. We can't change binding of "smsc,lan9115"
which is already documented here [1]. These samsung specific srom
properties should be in srom node or its subnode, but not in this way.
[1]: Documentation/devicetree/bindings/net/smsc911x.txt
Thanks,
Pankaj Dubey
> + };
> +};
> --
> 2.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 2/4] ARM: dts: Add SROMc to Exynos 5410
Hi Pavel,
On 29 October 2015 at 18:12, Pavel Fedin wrote:
> This machine uses own SoC device tree file, add missing part.
>
> Signed-off-by: Pavel Fedin
> ---
> arch/arm/boot/dts/exynos5410.dtsi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5410.dtsi
> b/arch/arm/boot/dts/exynos5410.dtsi
> index 4603356..da6a8fa0e 100644
> --- a/arch/arm/boot/dts/exynos5410.dtsi
> +++ b/arch/arm/boot/dts/exynos5410.dtsi
> @@ -101,6 +101,15 @@
> reg = <0x1000 0x100>;
> };
>
> + sromc: sromc@1225 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
We do not need to specify these three properties as they are already
present in parent node "soc".
> + compatible = "samsung,exynos-srom";
> + reg = <0x1225 0x14>;
> + };
> +
> pmu_system_controller: system-controller@1004 {
> compatible = "samsung,exynos5410-pmu", "syscon";
> reg = <0x1004 0x5000>;
> @@ -133,6 +142,12 @@
> <10 &gic 0 130 0>,
> <11 &gic 0 131 0>;
> };
> +
> + arch_timer {
> + compatible = "arm,armv7-timer";
> + clock-frequency = <2400>;
> + };
> +
This change should not be part of this patch.
Thanks,
Pankaj Dubey
> };
>
> sysram@0202 {
> --
> 2.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 3/3] ARM64: zynqmp: DT: Add interrupt-controller property to GPIO
On 10/23/2015 06:25 PM, Soren Brinkmann wrote: > GPIO can be used as interrupt-controller. Add the missing properties to > the GPIO node. > > Signed-off-by: Soren Brinkmann > --- > arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi > b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi > index 857eda5c7217..200fb588d0f5 100644 > --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi > +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi > @@ -133,6 +133,8 @@ > clocks = <&misc_clk>; > interrupt-parent = <&gic>; > interrupts = <0 16 4>; > + interrupt-controller; > + #interrupt-cells = <2>; > reg = <0x0 0xff0a 0x1000>; > }; > > Applied. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/3] mtd: create a partition type device tree binding
+ devicetree-spec and others, since other non-driver-specific MTD
partitioning stuff has gotten directed there [1], and this binding
should probably get promoted in short order to the core mtdpart.c
partitioning
On Thu, Oct 29, 2015 at 01:52:30PM +0100, Linus Walleij wrote:
> The Linux code in drivers/mtd/maps/physmap_of.c will optionally
> look for the linux,part-probe binding for hints on a partition type to
> look for in the MTD. It was added in commit 9d5da3a9b849
> "mtd: extend physmap_of to let the device tree specify the parition probe"
>
> This solution is too Linux-specific and depend on some
> Linux kernel-internal naming conventions. We need a proper
> way of describing partition types that follow the pattern set by
> other device tree bindings.
>
> Create a "partition-type" binding for this, and add "my" bindings
> for "arm,arm-flash-structure" as a starter for others to follow.
> A follow-on patch adds support to the Linux kernel to handle this
> binding, with some infrastructure for others to use it too.
Overall, I like this. And thanks for expanding the explanation of DT
partitions vs. parsers. It'd be good if we make parsers like this easier
to integrate, so we see less hard-coded partitions in device tree.
> Cc: devicetree@vger.kernel.org
> Cc: Jason Gunthorpe
> Cc: Liviu Dudau
> Reported-by: Liviu Dudau
> Signed-off-by: Linus Walleij
> ---
> .../devicetree/bindings/mtd/mtd-physmap.txt| 2 ++
> .../devicetree/bindings/mtd/partition.txt | 35
> +++---
> 2 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> index 4a0a48bf4ecb..863560bdbb19 100644
> --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> @@ -23,6 +23,8 @@ file systems on embedded devices.
> unaligned accesses as implemented in the JFFS2 code via memcpy().
> By defining "no-unaligned-direct-access", the flash will not be
> exposed directly to the MTD users (e.g. JFFS2) any more.
> + - partition-type : a flash partition type to expect and probe for
> + on this device. See "partition.txt" for available partition types.
> - linux,mtd-name: allow to specify the mtd name for retro capability with
> physmap-flash drivers as boot loader pass the mtd partition via the old
> device name physmap-flash.
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt
> b/Documentation/devicetree/bindings/mtd/partition.txt
> index 8e5557da1955..85d45764a4b3 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -1,9 +1,36 @@
> Representing flash partitions in devicetree
>
> -Partitions can be represented by sub-nodes of an mtd device. This can be used
> -on platforms which have strong conventions about which portions of a flash
> are
> -used for what purposes, but which don't use an on-flash partition table such
> -as RedBoot.
> +On-device partition types:
> +
> +It is possible for some drivers to indicate an on-device partition type, i.e.
> +partition tables, footers or other binary pattern in the flash used to
> +define how the flash is partitioned. This can be done in the device tree node
> +of an MTD device by specifying partition-type = "foo"; This tells the
> operating
> +system to look for the partition type indicated.
> +
> +Required properties:
> +- partition-type : the type of partition. Only one type can be specified.
You're supporting this as a list property (for future expansion,
presumably), so I can only assume the "only one type" is referring to
the number of different parsers available currently, not the behavior of
the property itself? This should probably be worded differently if
that's the intention. Like, "a list of partition types ... ordered by
priority We currently support the following: (list only the AFS
type)" (fill in the blanks how you'd like).
Also, this patch will conflict with [1]. I'll probably take [1] soon, so
one of us will have to rebase this.
Brian
[1] http://thread.gmane.org/gmane.comp.devicetree.spec/191
> + Valid types are:
> + "arm,arm-flash-structure" (also called AFS)
> +
> +Example:
> +
> +flash0@4000 {
> + /* 2 * 32MiB NOR Flash memory */
> + compatible = "arm,vexpress-flash", "cfi-flash";
> + partition-type = "arm,arm-flash-structure";
> + reg = <0x4000 0x0400>;
> + bank-width = <4>;
> +};
> +
> +
> +Device Tree specified partitions:
> +
> +If there is no specified on-device binary format, partitions can be
> +represented by sub-nodes of an mtd device. This can be used on platforms
> which
> +have strong conventions about which portions of a flash are used for what
> +purposes.
> +
> NOTE: if the sub-node has a compatible string, then it is not a partition.
>
> #address-cells & #size-cells must both
Re: [PATCH v12 2/6] fpga: add bindings document for simple fpga bus
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.
>
> > +- 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";
> > + reg = <0xc000 0x2000>,
> > + <0xff20 0x0020>;
>
> You have registers for the bus, so therefore it is not simple. I think
> the bus or bridge needs a specific compatible
>
The reg here is cruft from device tree generation. I don't use it and will
clean it out. After I've done that, does that become simple again?
What I need in a bus is:
- Handles 'ranges'
- Controls enabling/disabling bridges and programs the FPGA
- Populates the child devices (and there will probably be many)
This raises another issue: each area of the FPGA is likely to have multiple
bridges. That's why I had a list of phandles to bridges rather than
different bus for each type of bridge. Is that acceptible-ish?
> Rob
>
> [1] http://www.spinics.net/lists/devicetree/msg92462.html
>
--
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 22/22] of/platform: Defer probes of registered devices
On Wed, 2015-10-28 at 15:40 +0100, Tomeu Vizoso wrote: > On 22 October 2015 at 23:27, Scott Wood wrote: > > On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote: > > > On 22 October 2015 at 00:51, Scott Wood wrote: > > > > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote: > > > > > On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood < > > > > > scottw...@freescale.com> > > > > > wrote: > > > > > > On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote: > > > > > > > Instead of trying to match and probe platform and AMBA devices > > > > > > > right > > > > > > > after each is registered, delay their probes until > > > > > > > device_initcall_sync. > > > > > > > > > > > > > > This means that devices will start probing once all built-in > > > > > > > drivers > > > > > > > have registered, and after all platform and AMBA devices from > > > > > > > the DT > > > > > > > have been registered already. > > > > > > > > > > > > > > This allows us to prevent deferred probes by probing > > > > > > > dependencies on > > > > > > > demand. > > > > > > > > > > > > > > Signed-off-by: Tomeu Vizoso > > > > > > > --- > > > > > > > > > > > > > > Changes in v4: > > > > > > > - Also defer probes of AMBA devices registered from the DT as > > > > > > > they > > > > > > > can > > > > > > > also request resources. > > > > > > > > > > > > > > drivers/of/platform.c | 11 --- > > > > > > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > > > > > > > > > This breaks arch/powerpc/sysdev/fsl_pci.c. The PCI bus is an OF > > > > > > platform > > > > > > device, and it must be probed before pcibios_init() which is a > > > > > > subsys_initcall(), or else the PCI bus never gets scanned. > > > > > > > > > > Thanks for the report. This is probably getting dropped, but it > > > > > could > > > > > be disabled for PPC. > > > > > > > > I don't think that adding another arbitrary arch difference would be > > > > the > > > > right solution. > > > > > > I think Rob meant temporarily disable it while things get fixed. At > > > least, > > > > So, what is the permanent fix for the swiotlb issue (or more generally, > > the > > inability to have a late_initcall that runs after non-module, non-hotplug > > platform devices have been probed)? > > If the code in pcibios_init() depends on the PCI bus device having > probed, then I would recommend making that dependency explicit by > calling of_device_probe() on the OF node of the PCI controller when > looking it up. "when looking it up"? pcibios_init() doesn't do anything with the OF node or know any details about the particular PCI bus host implementation. > > > I don't see any reason why PPC wouldn't benefit from this > > > series. > > > > It's not clear to me what the benefit of this is at all, much less for > > PPC. > > What is the fundamental problem with deferred probes? In the cover letter > > you say this change saves 2.3 seconds, but where is that time being > > consumed? > > Are the drivers taking too long in their probe function trying to > > initialize > > and then deferring, rather than checking for dependencies up front? Or > > are > > there really so many devices and such a pessimal ordering that most of the > > time is spent iterating through and reordering the list, with each defer > > happening quickly? > > The problem is that a device that defers its probe is currently sent > to the back of the queue, and that's undesired in some use cases in > which there's a device that should be up as soon as possible during > boot (and boot takes a long time). So the goal is to change the order > in which devices with dependencies end up probing. That doesn't answer my question about where the time is being spent. Did you profile? -Scott -- 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 2/3] mtd: mtk-nor: mtk serial flash controller driver
On Thu, Oct 29, 2015 at 09:56:31PM +0800, bayi.cheng wrote:
> On Thu, 2015-10-29 at 11:28 +0800, bayi.cheng wrote:
> > On Wed, 2015-10-28 at 18:52 -0700, Brian Norris wrote:
> > > On Sun, Oct 18, 2015 at 10:20:35PM +0800, bayi.cheng wrote:
> > > > On Fri, 2015-10-16 at 00:39 -0700, Brian Norris wrote:
> > > > > On Tue, Oct 13, 2015 at 05:39:19PM +0800, Bayi Cheng wrote:
> > > > > > + /* mtk nor controller doesn't supoort SPINOR_OP_RDCR */
> > > > > > + switch (opcode) {
> > > > > > + case SPINOR_OP_RDID:
> > > > > > + /* read JEDEC ID need 4 bytes commands */
> > > > > > + ret = mt8173_nor_set_cmd(mt8173_nor, 0, 32,
> > > > > > SPINOR_OP_RDID);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + /* mtk nor flash controller only support 3 bytes IDs */
> > > > >
> > > > > Are you absolutely sure of this? That would be highly unfortunate, but
> > > > > I also don't believe it's true.
> > > > >
> > > > Yes, for this issue I have asked our designer of nor flash controller,
> > > > unfortunately, it is true, and I have tried to read more IDs, but our
> > > > controller just accept 3 IDs from nor flash, and our next generation IC
> > > > may solve this problem.
> > >
> > > How exactly did you try? Did you do what I suggested above? Are the
> > > "shift registers" not all actually functional?
> > >
> > Hi Brian, For this problem, I have asked our nor controller designer to
> > double confirm again, and he promise to do some simulation testes, On
> > the other hand, I have got some Spansion nor flash which has 5 IDs, and
> > after our designer make sure our controller can support 5 or 6 IDs, then
> > I will rework a special platform with S25FL256SA. If we have any
> > progress, I will inform you immediately! Thanks!!
> >
> Hi Brian, Thanks very much for your perseverance!!
> Actually, You idea is correct, and our designer has completed some
> simulation test on spansion nor flash witch has more than 3 IDs, and the
> results has prove that we can support to read 5 IDs. I also double
Awesome!
> confirmed with spansion nor flash. The only pity is that our nor
> controller can't support 6 IDs, we just support 5 IDs.
That's not quite as awesome. But that's still much more workable than
only 3 bytes. Perhaps we'll want a way to communicate that to the
spi-nor layer, so it doesn't think it can match a full 6 bytes?
> I will submit my changes to V6 version. Thanks again!!
OK, but let me take another look at v5 and send you comments on that one
first.
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: [alsa-devel] [PATCH V2 02/10] ASoC: img: Add driver for I2S input controller
On 28/10/15 23:43, Mark Brown wrote: > On Wed, Oct 28, 2015 at 09:18:20PM +, Damien Horsley wrote: >> On 28/10/15 01:04, Mark Brown wrote: > I think it also makes sense to keep the blocks consistent with each other. The spdif (out and in), and parallel out, all flush automatically when stopped, and the fifo for the i2s out block is cleared when the reset is asserted. > >>> This seems like an issue that got missed in the other drivers then. I'd >>> expect the trigger operation to be a minimal operation which starts and >>> stops the data transfer, not doing anything else. > >> The spdif out, spdif in, and parallel out blocks auto-flush whenever >> they are stopped. It is not possible for software to prevent this behavior. > > Oh, so this isn't the drivers doing this? In that case it's fine for > them to do that, if it's what the hardware does it's what the hardware > does. It sounded like you were saying that there was similar code in > the other drivers. > For the I2S In, there is another issue with flushing on stream close. If the stream is stopped, then reconfigured to use a larger number of channels (without the stream being closed), then the per-channel fifos will become inconsistent with each other. The new channels will have no samples in their FIFOs, while the others may contain samples from the previous stream. Would hw_params be the correct place to flush instead? -- 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 5/6] ARM: socfpga: add bindings document for fpga bridge drivers
On Wed, 28 Oct 2015, Rob Herring wrote:
> On Tue, Oct 27, 2015 at 5:09 PM, wrote:
> > From: Alan Tull
> >
> > Add bindings documentation for Altera SOCFPGA bridges:
> > * fpga2sdram
> > * fpga2hps
> > * hps2fpga
> > * lwhps2fpga
> >
> > Signed-off-by: Alan Tull
>
> Oops...
Wow. Ugh.
>
> > Signed-off-by: Dinh Nguyen
> > Signed-off-by: Matthew Gerlach
>
> These should be roughly in order of who did modifications. I'd expect
> you to be last.
I wrote the driver, Matthew, Dinh, and I all made mods.
>
> > ---
> > 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
> > ---
> > .../bindings/fpga/altera-fpga2sdram-bridge.txt | 18 ++
> > .../bindings/fpga/altera-hps2fpga-bridge.txt | 36
> >
> > 2 files changed, 54 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..11eb5b7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> > @@ -0,0 +1,18 @@
> > +Altera FPGA To SDRAM Bridge Driver
> > +
> > +Required properties:
> > +- compatible : Should contain "altr,socfpga-fpga2sdram-bridge"
> > +
> > +Optional properties:
> > +- label: User-readable name for this bridge.
> > + Default is br
>
> Why does the user need label? We generally use label to match physical
> labels like "Rear USB port" or "disk LED" or something.
>
I'll remove it.
> > +- init-val : 0 if driver should disable bridge at startup
> > + 1 if driver should enable bridge at startup
>
> Perhaps "bridge-enable" would be a more descriptive name.
>
I could change it to bridge-enable. Alternatively I could have two
booleans that are bridge-enable and bridge-disable as:
bridge-enable : boolean property should be defined if driver should
enable bridge at startup
bridge-disable : boolean property should be defined if driver should
disable bridge at startup
Default if neither bridge-enable or bridge-disable are specified is
driver will leave bridge in its current state.
> And to comment on other replies, I have no problem with this type of
> property in the DT. But yes, configuration type properties will get
> more scrutiny.
>
> > + Default is to leave bridge in current state.
> > +
> > +Example:
> > + fpga2sdram_br: fpgabridge@3 {
> > + compatible = "altr,socfpga-fpga2sdram-bridge";
> > + label = "fpga2sdram";
> > + init-val = <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..eb52f3b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> > @@ -0,0 +1,36 @@
> > +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:
> > +- label: User-readable name for this bridge.
> > + Default is br
> > +- init-val : 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";
> > + label = "hps2fpga";
> > + clocks = <&l4_main_clk>;
> > + init-val = <1>;
> > + };
> > +
> > + hps_fpgabridge1: fpgabridge@1 {
> > + compatible = "altr,socfpga-lwhps2fpga-bridge";
> > + label = "lwhps2fpga";
> > + clocks = <&l4_main_clk>;
> > + init-val = <0>;
> > + };
> > +
> > + hps_fpgabridge2: fpgabridge@2 {
> > + compatible = "altr,socfpga-fpga2hps-bridge";
> > + label = "fpga2hps";
> > + clocks = <&l4_main_clk>;
> > + };
> > --
> > 1.7.9.5
> >
>
--
To unsubscribe from this lis
Re: [PATCH 07/11] pinctrl: use ngpios propety from DT
On 29.10.2015 15:36, Linus Walleij wrote: > On Wed, Oct 28, 2015 at 12:52 PM, Pramod Kumar wrote: > >> I discussed with ASIC team regarding this iProc GPIO block. They use a >> library to create the GPIOs block where "total number of GPIO pins( let say >> N) in GPIO block" is used as an parameter. >> Library uses a construct for *a* GPIO pin. This gets instantiated N times to >> create a complete GPIO block with N pins. >> >> All iProc based SoCs uses this library. So I'm not sure whether attaching >> "total number of GPIOs pins" to compatible-string make sense in this case. >> I personally feel that passing this number from the DT makes more sense >> here. Any iProc based future as well as current SoCs would be able to use >> this driver without any change. >> >> Please advise us in this case. > > Hm! You make a good case. > > But this contradicts the traditional use of ngpios. > > But on the other hand: > git grep ngpio Documentation/devicetree/bindings/gpio/ > > Gives at hand that the use of ngpio[s] is a complete mess. > > :( > > I will think about patching the standard bindings to fix this mess > and include your case. Give me some time. Using ngpios to restrict the amount of actually available GPIOs from the possible amount of GPIOs seems a rather limited use, as rerouted gpios are seldom at the end of the GPIO space. So maybe it makes more sense to use ngpio as the number of possible gpios and then have an additional "reserved-gpios" bitmask / list of unavailable gpios? Ideally those would be just consumed by a pinctrl instance, but I guess that these are sometimes controlled through pinstrapping, so there might be no driver to attach to them. Regards Jonas -- 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 07/11] pinctrl: use ngpios propety from DT
On Wed, Oct 28, 2015 at 12:52 PM, Pramod Kumar wrote: > I discussed with ASIC team regarding this iProc GPIO block. They use a > library to create the GPIOs block where "total number of GPIO pins( let say > N) in GPIO block" is used as an parameter. > Library uses a construct for *a* GPIO pin. This gets instantiated N times to > create a complete GPIO block with N pins. > > All iProc based SoCs uses this library. So I'm not sure whether attaching > "total number of GPIOs pins" to compatible-string make sense in this case. > I personally feel that passing this number from the DT makes more sense here. > Any iProc based future as well as current SoCs would be able to use this > driver without any change. > > Please advise us in this case. Hm! You make a good case. But this contradicts the traditional use of ngpios. But on the other hand: git grep ngpio Documentation/devicetree/bindings/gpio/ Gives at hand that the use of ngpio[s] is a complete mess. :( I will think about patching the standard bindings to fix this mess and include your case. Give me some time. Yours, Linus Walleij -- 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/3] gpio: arizona: Support Cirrus Logic CS47L24 and WM1831
On Wed, Oct 28, 2015 at 12:42 PM, Lee Jones wrote: > On Tue, 27 Oct 2015, Linus Walleij wrote: > >> On Mon, Oct 19, 2015 at 4:13 PM, Richard Fitzgerald >> wrote: >> >> > 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 >> >> Lee can merge this into the MFD tree with patch 1/3 if he likes, >> I guess that's simplest. > > I can do. Do you require a pull-request? Nah. I usually optimistically assume that these (small) things will not clash. Yours, Linus Walleij -- 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 v3] Input: tsc2005 - Add support for tsc2004
On Thu, Oct 29, 2015 at 03:25:34PM +0800, kbuild test robot wrote: > Hi Michael, > > [auto build test ERROR on input/next -- if it's inappropriate base, please > suggest rules for selecting the more suitable base] > > url: > https://github.com/0day-ci/linux/commits/Michael-Welling/Input-tsc2005-Add-support-for-tsc2004/20151029-081504 > config: x86_64-randconfig-s1-10291412 (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers/built-in.o: In function `tsc2005_cmd': > >> tsc200x-core.c:(.text+0x2ae07f): undefined reference to > >> `i2c_smbus_write_byte' Argh! How do I fix this one? > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation -- 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] Documentation: dt: Add bindings for Secure-only devices
The existing device tree bindings assume that we are only trying to describe a single address space with a device tree (for ARM, either the Normal or the Secure world). Some uses for device tree need to describe both Normal and Secure worlds in a single device tree. Add documentation of how to do this, by adding extra properties which describe when a device appears differently in the two worlds or when it only appears in one of them. The binding describes the general principles for adding new properties describing the secure world, but for now we only need a single new property, "secure-status", which can be used to annotate devices to indicate that they are only visible in one of the two worlds. The primary expected use of this binding is for a virtual machine like QEMU to describe the VM layout to a TrustZone aware firmware (which would then use the secure-only devices itself, and pass the DT on to a kernel running in the non-secure world, which ignores the secure-only devices and uses the rest). Signed-off-by: Peter Maydell --- This binding doesn't affect the kernel itself, but the kernel Documentation/ tree is the de-facto current place where all DT bindings are documented, so Grant suggested this was the right place to send a doc patch. Documentation/devicetree/bindings/arm/secure.txt | 41 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/secure.txt diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt new file mode 100644 index 000..4129fba --- /dev/null +++ b/Documentation/devicetree/bindings/arm/secure.txt @@ -0,0 +1,41 @@ +* ARM Secure world bindings + +ARM CPUs with TrustZone support have two distinct address spaces, +"Normal" and "Secure". Most devicetree consumers (including the Linux +kernel) are not TrustZone aware and run entirely in either the Normal +world or the Secure world. However some devicetree consumers are +TrustZone aware and need to be able to determine whether devices are +visible only in the Secure address space, only in the Normal address +space, or visible in both. (One example of that situation would be a +virtual machine which boots Secure firmware and wants to tell the +firmware about the layout of the machine via devicetree.) + +The general principle of the naming scheme for Secure world bindings +is that any property that needs a different value in the Secure world +can be supported by prefixing the property name with "secure-". So for +instance "secure-reg" would override "reg". If there is no "secure-" +property then the Secure world value is the same as specified for the +Normal world by the non-prefixed property. However, only the +properties listed below may validly have "secure-" versions; this list +will be enlarged on a case-by-case basis. + +Defining the bindings in this way means that a device tree which has +been annotated to indicate the presence of Secure-only devices can +still be processed unmodified by existing Non-secure software (and in +particular by the kernel). + +Note that it is still valid for bindings intended for purely Secure +world consumers (like kernels that run entirely in Secure) to simply +describe the view of Secure world using the standard bindings. These +secure- bindings only need to be used where both the Secure and Normal +world views need to be described in a single device tree. + +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 + status = "disabled"; secure-status = "okay"; // S-only + status = "okay"; secure-status = "disabled"; // NS-only -- 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 v4 5/5] [RFC] clk: shmobile: r8a7795: Add new CPG/MSSR driver
On Thu, Oct 22, 2015 at 2:58 PM, Geert Uytterhoeven
wrote:
> - Calling platform_driver_probe() from arch_initcall() is too late, as the
> IRQC is initialized first (it's located before the CPG in .dtsi).
> Hence the IRQC can't find it's Clock Domain, and its probe is deferred.
> IRQC will be reprobed later, but in the mean time the Ethernet PHY can't
> find its IRQ, as the of_mdio code uses irq_of_parse_and_map(), which
> plainly ignores EPROBE_DEFER :-(
> Nevertheless, Ethernet works...
To correct myself: renesas-irqc is initialized first because it uses
postcore_initcall().
The of_mdio issue on R-Car Gen2 boards can be worked around by changing that
to device_initcall(). That would cause a few more probe deferrals on R-Mobile
APE6 (r8a73a4), where IRQC is not only the external interrupt controller,
but also the parent interrupt controller of the PFC/GPIO combo.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] gpio: xgene: add support to configure GPIO line as input, output or external IRQ pin
On Mon, Oct 26, 2015 at 7:49 AM, Y Vo wrote:
> Add support to configure GPIO line as input, output or external IRQ pin.
>
> Signed-off-by: Y Vo
As I will say again, this description is too terse, add lots of information
on how IRQs work on this controller please. I get confused.
(...)
> +#define XGENE_GPIO8_HWIRQ 0x48
> +#define XGENE_GPIO8_IDX8
(...)
> +#define XGENE_HWIRQ_TO_GPIO(hwirq) ((hwirq) + XGENE_GPIO8_IDX)
> +#define XGENE_GPIO_TO_HWIRQ(gpio) ((gpio) - XGENE_GPIO8_IDX)
> +#define GIC_IRQ_TO_GPIO_IRQ(hwirq) ((hwirq) - XGENE_GPIO8_HWIRQ)
> +#define GPIO_IRQ_TO_GIC_IRQ(hwirq) ((hwirq) + XGENE_GPIO8_HWIRQ)
I'm a bit uneasy about this, maybe I just don't get it.
What is this indexing into "GIC IRQ" that is starting to happen
here?
The GIC (if that is drivers/irqchip/irq-gic.c) has a totally dynamic IRQ
translation and the Linux IRQs it is using may change. I am worried
that there is some reliance here on Linux IRQ having certain numbers
because there is certainly no ABI like that.
Is this 0x48 really an index into the *hardware* offset in the GIC?
And if it is: why are we not getting this hardware information from the
device tree like all other interrupt numbers and offsets?
I'm worried about this.
> - u32 *irq;
> + void __iomem *regs;
> + struct irq_domain *gic_domain;
> + struct irq_domain *irq_domain;
And there is some secondary gic_domain here, which is confusing
since the GIC does have an IRQ domain too.
I think I want a clear explanation to how this GPIO controller interacts
with the GIC, and I want it to be part of the patch, as comments in the
code and in the commit message (which is way too small for a complex
patch like this).
Otherwise I have no chance to understand what is really going on here.
> +static int xgene_gpio_sb_irq_set_type(struct irq_data *d, unsigned int type)
> +{
> + int hwirq = d->hwirq;
> + int gpio = XGENE_HWIRQ_TO_GPIO(hwirq);
> + struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
> + int lvl_type;
> + int ret;
> +
> + switch (type & IRQ_TYPE_SENSE_MASK) {
> + case IRQ_TYPE_EDGE_RISING:
> + case IRQ_TYPE_LEVEL_HIGH:
> + lvl_type = GPIO_INT_LVL_LEVEL_HIGH;
> + break;
> + case IRQ_TYPE_EDGE_FALLING:
> + case IRQ_TYPE_LEVEL_LOW:
> + lvl_type = GPIO_INT_LVL_LEVEL_LOW;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = gpiochip_lock_as_irq(&priv->bgc.gc, gpio);
> + if (ret) {
> + dev_err(priv->bgc.gc.dev,
> + "Unable to configure XGene GPIO standby pin %d as IRQ\n",
> + gpio);
> + return ret;
> + }
> +
> + if ((gpio >= XGENE_GPIO8_IDX) &&
> + (hwirq < XGENE_MAX_GPIO_DS_IRQ)) {
> + xgene_gpio_set_bit(&priv->bgc, priv->regs + MPA_GPIO_SEL_LO,
> + gpio * 2, 1);
> + xgene_gpio_set_bit(&priv->bgc, priv->regs + MPA_GPIO_INT_LVL,
> + hwirq, lvl_type);
> + }
> + if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
> + irq_set_handler_locked(d, handle_edge_irq);
> + else
> + irq_set_handler_locked(d, handle_level_irq);
> +
> + return 0;
> +}
If you are assigning hadle_edge_irq() your irqchip *must* have an
.irq_ack() callback that acknowledges the IRQs as they come in.
This makes me suspect that you haven't really tested edge
interrupts, because if you did, the kernel would crash as it
is unconditionally calling the .irq_ack() from handle_level_irq().
Yours,
Linus Walleij
--
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 1/3] mtd: create a partition type device tree binding
The Linux code in drivers/mtd/maps/physmap_of.c will optionally
look for the linux,part-probe binding for hints on a partition type to
look for in the MTD. It was added in commit 9d5da3a9b849
"mtd: extend physmap_of to let the device tree specify the parition probe"
This solution is too Linux-specific and depend on some
Linux kernel-internal naming conventions. We need a proper
way of describing partition types that follow the pattern set by
other device tree bindings.
Create a "partition-type" binding for this, and add "my" bindings
for "arm,arm-flash-structure" as a starter for others to follow.
A follow-on patch adds support to the Linux kernel to handle this
binding, with some infrastructure for others to use it too.
Cc: devicetree@vger.kernel.org
Cc: Jason Gunthorpe
Cc: Liviu Dudau
Reported-by: Liviu Dudau
Signed-off-by: Linus Walleij
---
.../devicetree/bindings/mtd/mtd-physmap.txt| 2 ++
.../devicetree/bindings/mtd/partition.txt | 35 +++---
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
index 4a0a48bf4ecb..863560bdbb19 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
@@ -23,6 +23,8 @@ file systems on embedded devices.
unaligned accesses as implemented in the JFFS2 code via memcpy().
By defining "no-unaligned-direct-access", the flash will not be
exposed directly to the MTD users (e.g. JFFS2) any more.
+ - partition-type : a flash partition type to expect and probe for
+ on this device. See "partition.txt" for available partition types.
- linux,mtd-name: allow to specify the mtd name for retro capability with
physmap-flash drivers as boot loader pass the mtd partition via the old
device name physmap-flash.
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt
b/Documentation/devicetree/bindings/mtd/partition.txt
index 8e5557da1955..85d45764a4b3 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -1,9 +1,36 @@
Representing flash partitions in devicetree
-Partitions can be represented by sub-nodes of an mtd device. This can be used
-on platforms which have strong conventions about which portions of a flash are
-used for what purposes, but which don't use an on-flash partition table such
-as RedBoot.
+On-device partition types:
+
+It is possible for some drivers to indicate an on-device partition type, i.e.
+partition tables, footers or other binary pattern in the flash used to
+define how the flash is partitioned. This can be done in the device tree node
+of an MTD device by specifying partition-type = "foo"; This tells the operating
+system to look for the partition type indicated.
+
+Required properties:
+- partition-type : the type of partition. Only one type can be specified.
+ Valid types are:
+ "arm,arm-flash-structure" (also called AFS)
+
+Example:
+
+flash0@4000 {
+ /* 2 * 32MiB NOR Flash memory */
+ compatible = "arm,vexpress-flash", "cfi-flash";
+ partition-type = "arm,arm-flash-structure";
+ reg = <0x4000 0x0400>;
+ bank-width = <4>;
+};
+
+
+Device Tree specified partitions:
+
+If there is no specified on-device binary format, partitions can be
+represented by sub-nodes of an mtd device. This can be used on platforms which
+have strong conventions about which portions of a flash are used for what
+purposes.
+
NOTE: if the sub-node has a compatible string, then it is not a partition.
#address-cells & #size-cells must both be present in the mtd device. There are
--
2.4.3
--
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 v4 1/4] Documentation: dt-bindings: Describe SROMc configuration
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 | 50 +-
1 file changed, 48 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..02ecc7f 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,54 @@ Required properties:
- reg: offset and length of the register set
-Example:
+- #address-cells, #size-cells : should be '1' if the device has sub-nodes
+ with 'reg' property.
+- ranges: allows valid 1:1 translation between child's address space and
+ parent's address space
+
+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:
+- samsung,srom-bank : bank number (0 - 3)
+
+- samsung,srom-timing : array of 7 integers: PMC, Tacp, Tcah, Tcoh, Tacc, Tcos,
+ Tacs
+
+Optional properties:
+- samsung,srom-data-width : data width in bytes (1 or 2). If omitted, default
+ of 1 is used.
+
+Example: basic definition, no banks are configured
sromc@1257 {
compatible = "samsung,exynos-srom";
- reg = <0x1257 0x10>;
+ reg = <0x1257 0x14>;
+ };
+
+Example: SROMc with smsc 911x ethernet chip on bank 3
+ sromc@1257 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ compatible = "samsung,exynos-srom";
+ reg = <0x1257 0x14>;
+
+ ethernet@0700 {
+ compatible = "smsc,lan9115";
+ reg = <0x0700 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-bank = <3>;
+ samsung,srom-data-width = <2>;
+ samsung,srom-timing = <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
[PATCH v4 4/4] ARM: dts: Add Ethernet chip to SMDK5410
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 | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..311e7be 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,23 @@
&uart2 {
status = "okay";
};
+
+&sromc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+ ethernet@0700 {
+ compatible = "smsc,lan9115";
+ reg = <0x0700 0x1>;
+ phy-mode = "mii";
+ interrupt-parent = <&gpx0>;
+ interrupts = <5 8>;
+ reg-io-width = <2>;
+ smsc,irq-push-pull;
+ smsc,force-internal-phy;
+
+ samsung,srom-bank = <3>;
+ samsung,srom-data-width = <2>;
+ samsung,srom-timing = <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
[PATCH v4 2/4] ARM: dts: Add SROMc to Exynos 5410
This machine uses own SoC device tree file, add missing part.
Signed-off-by: Pavel Fedin
---
arch/arm/boot/dts/exynos5410.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..da6a8fa0e 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,15 @@
reg = <0x1000 0x100>;
};
+ sromc: sromc@1225 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ compatible = "samsung,exynos-srom";
+ reg = <0x1225 0x14>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
@@ -133,6 +142,12 @@
<10 &gic 0 130 0>,
<11 &gic 0 131 0>;
};
+
+ arch_timer {
+ compatible = "arm,armv7-timer";
+ clock-frequency = <2400>;
+ };
+
};
sysram@0202 {
--
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 v4 3/4] drivers: exynos-srom: Add support for bank configuration
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 | 58 +--
3 files changed, 58 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..68e894f 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,48 @@ 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;
+ u32 timing[7];
+ u32 cs, bw;
+
+ if (of_property_read_u32(np, "samsung,srom-bank", &bank))
+ return -EINVAL;
+ if (of_property_read_u32(np, "samsung,srom-data-width", &width))
+ width = 1;
+ 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((timing[0] << EXYNOS_SROM_BCX__PMC__SHIFT) |
+ (timing[1] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+ (timing[2] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+ (timing[3] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+ (timing[4] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+ (timing[5] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+ (timing[6] << 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 +138,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 v4 0/4] [PATCH v4 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
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. 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 | 50 ++- arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 +++ arch/arm/boot/dts/exynos5410.dtsi | 15 ++ arch/arm/mach-exynos/Kconfig | 2 +- drivers/soc/samsung/Kconfig| 2 +- drivers/soc/samsung/exynos-srom.c | 58 +- 6 files changed, 162 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 v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135
On Thu, 2015-10-29 at 02:12 -0700, Kevin Hilman wrote: > Eddie Huang writes: > > > Hi Kevin, > > > > On Mon, 2015-10-26 at 17:06 +0900, Kevin Hilman wrote: > >> On Mon, Oct 26, 2015 at 4:15 PM, Yingjoe Chen > >> wrote: > >> > On Mon, 2015-10-26 at 09:56 +0900, Kevin Hilman wrote: > >> >> Hello, > >> >> > >> >> On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen > >> >> wrote: > >> >> > Add arch timer node to enable arch-timer support. MT8135 firmware > >> >> > doesn't correctly setup arch-timer frequency and CNTVOFF, add > >> >> > properties to workaround this. > >> >> > > >> >> > This also set cpu enable-method to enable SMP. > >> >> > > >> >> > Signed-off-by: Yingjoe Chen > >> >> > >> >> kernelci.org started detecting new boot failures for the mt8135-evb in > >> >> the arm-soc tree[1], and the boot failures were bisected down to this > >> >> patch, which landed upstream in the form of commit d186a394bb98 (ARM: > >> >> dts: mt8135: enable basic SMP bringup for mt8135) > >> >> > >> >> Maybe this new SMP support requires updating the firmware on the board > >> >> as well? If so, the changelog should've been a bit more explicit > >> >> about firmware dependencies. > >> > > >> > Kevin, > >> > > >> > Thanks for testing. > >> > > >> > No, it doesn't need new firmware. Will test to see what's going wrong. > >> > >> Thanks for following up. I'll be glad to test any patches if you have > >> anything you'd like me to test. > > > > You need "clockevents/drivers/mtk: Fix spurious interrupt leading to > > crash" (https://lkml.org/lkml/2015/8/24/803) > > > > Daniel Lezcano already applied this patch in his tree for 4.4. > > (https://git.linaro.org/people/daniel.lezcano/linux.git) > > > > Thanks for letting us know. > > In the future, these kinds of cross-tree dependencies are important to > mention in the cover letter of the pull request so we can setup > dependency branches and keep arm-soc/for-next building and booting. > sorry, we will be more careful in the future Eddie Thanks -- 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 v3 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello! > >> Any vendor prefix here? How generic is this? > > > > I just don't know... Does *everything* really need a vendor prefix? How > > readable would that > be? "compatible" property already says > > that it's samsung-exynos-specific. And IMHO it's quite obvious that > > properties of vendor- > specific device are automatically > > vendor-specific. > > Ok, i am currently fixing up the rest and will post v4 soon, and will Cc: > > it to devicetree > ML. > > Which my reply you are referring to? You stripped part of some > sentence and put it without *any context*. Just random sentence. > I asked for vendor prefix in few places... srom-timing? width? And I > do not remember where I used exactly these words. Ok, sorry, i promise to improve. :) Anyway, i have figured out how to add sub-devices, and heavily modified the whole thing. And indeed, vendor prefix is now very useful, so i added it to all three properties. Making v4... Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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 v3 1/4] Documentation: dt-bindings: Describe SROMc configuration
2015-10-29 16:45 GMT+09:00 Pavel Fedin : > Hello! > >> You missed here a lot of potential Cc. Please use get_maintainer.pl >> script. It *must* be sent to devicetree list. >> >> Please send it also to DeviceTree maintainers because you are adding >> quite generic names for bindings so they may have interesting thoughts >> on this. >> >> LKML list is also missing. > > Ok. Next version will go there too. > >> Any vendor prefix here? How generic is this? > > I just don't know... Does *everything* really need a vendor prefix? How > readable would that be? "compatible" property already says > that it's samsung-exynos-specific. And IMHO it's quite obvious that > properties of vendor-specific device are automatically > vendor-specific. > Ok, i am currently fixing up the rest and will post v4 soon, and will Cc: it > to devicetree ML. Which my reply you are referring to? You stripped part of some sentence and put it without *any context*. Just random sentence. I asked for vendor prefix in few places... srom-timing? width? And I do not remember where I used exactly these words. This is why *context* is needed. > > P.S. I intentionally omit the rest of the text in order to avoid > overquoting, since we are already focused on some specific things. > If someone wants to get the whole picture, he/she could just browse back to > the start of the thread. Or is it considered wrong > approach in this particular ML? Yep, selecting some sentences and replying only to them, leaving the context away, is highly confusing. I reply in different places, sometimes asking for similar things. Removing context messes this up. In the same time all of my other questions are being removed without any acknowledgment so I do not know if they were ignored or just silently acked. I show you example: > I just don't know... I don't know neither. > If someone wants to get the whole picture, he/she could just browse back to > the start of the thread. Yes, I would just scroll up and see the context. No, wait. There is no context. I have to find mine original email and compare which part was ignored, which was applied and which quoted sentence you are referring to. 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
