Re: [PATCH v2 2/5] mtd: nand: add NVIDIA Tegra NAND Flash controller driver
Hi Stefan,
thanks for the review.
Am Freitag, den 10.04.2015, 10:46 +0200 schrieb Stefan Agner:
Hi Lucas,
Thanks for working on that. Some minor comments below...
On 2015-04-08 21:46, Lucas Stach wrote:
Add support for the NAND flash controller found on NVIDIA
Tegra 2/3 SoCs.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Signed-off-by: Lucas Stach d...@lynxeye.de
---
v2:
- remove Tegra 3 compatible
- remove useless part_probes
- don't store irq number
- use gpiod API instead of deprecated of_gpios
- don't store reset
- correct TIMING_TCS mask
- simplify irq handler
- correct timing calculations
- don't store buswidth
- drop compile test
- correct ECC handling
---
MAINTAINERS | 6 +
drivers/mtd/nand/Kconfig | 6 +
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/tegra_nand.c | 786
++
4 files changed, 799 insertions(+)
create mode 100644 drivers/mtd/nand/tegra_nand.c
[...]
+static struct nand_ecclayout tegra_nand_oob_16 = {
+ .eccbytes = 4,
+ .eccpos = { 3, 4, 5, 6 },
+ .oobfree = {
+ { .offset = 7, . length = 8 }
+ }
+};
+
+static struct nand_ecclayout tegra_nand_oob_64 = {
+ .eccbytes = 36,
+ .eccpos = {
+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
+ },
The amount of eccbytes vs. length of eccpos do not match...
+ .oobfree = {
+ { .offset = 40, .length = 24 }
+ }
+};
+
+static struct nand_ecclayout tegra_nand_oob_128 = {
+ .eccbytes = 72,
+ .eccpos = {
+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
+ },
Here...
+ .oobfree = {
+ { .offset = 76, .length = 52 }
+ }
+};
+
+static struct nand_ecclayout tegra_nand_oob_224 = {
+ .eccbytes = 144,
+ .eccpos = {
+ 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
+ },
... and here too.
Urgh, actually they are all wrong, as the ECC starts at byte 4, not
3. :/ Thanks for the hint.
[...]
+static int tegra_nand_probe(struct platform_device *pdev)
+{
+ struct reset_control *rst;
+ struct tegra_nand *nand;
+ struct nand_chip *chip;
+ struct mtd_info *mtd;
+ struct resource *res;
+ unsigned long value;
+ int irq, buswidth, err = 0;
+
+ nand = devm_kzalloc(pdev-dev, sizeof(*nand), GFP_KERNEL);
+ if (!nand)
+ return -ENOMEM;
+
+ nand-dev = pdev-dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ nand-regs = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(nand-regs))
+ return PTR_ERR(nand-regs);
+
+ irq = platform_get_irq(pdev, 0);
+ err = devm_request_irq(pdev-dev, irq, tegra_nand_irq, 0,
+ dev_name(pdev-dev), nand);
+ if (err)
+ return err;
+
+ rst = devm_reset_control_get(pdev-dev, nand);
+ if (IS_ERR(rst))
+ return PTR_ERR(rst);
+
+ nand-clk = devm_clk_get(pdev-dev, nand);
+ if (IS_ERR(nand-clk))
+ return PTR_ERR(nand-clk);
+
+ nand-wp_gpio = gpiod_get_optional(pdev-dev, nvidia,wp-gpios,
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(nand-wp_gpio))
+ return PTR_ERR(nand-wp_gpio);
+
+ buswidth = of_get_nand_bus_width(pdev-dev.of_node);
+ if (buswidth 0)
+ return buswidth;
+
+ err = clk_prepare_enable(nand-clk);
+ if (err)
+ return err;
+
+ reset_control_assert(rst);
+ udelay(2);
+ reset_control_deassert(rst);
+
+ value = HWSTATUS_RDSTATUS_MASK(1) | HWSTATUS_RDSTATUS_VALUE(0) |
+
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
Hey Arnaud, On Mon, Apr 13, 2015 at 06:06:49PM +0200, Arnaud Ebalard wrote: Jason Cooper ja...@lakedaemon.net writes: ... I really tried to adapt the existing driver to add the missing features (especially the support for TDMA), but all my attempts ended up introducing hackish code (not even talking about the performance penalty of this approach). Ok, fair enough. It would be helpful if this account of attempting to reconcile the old driver made it into the commit message. This puts us in perfect is the enemy of getting it done territory. I have another solution though: keep the existing driver for old marvell SoCs (orion, kirkwood and dove), and add a new one for modern SoCs (armada 370, XP, 375 and 38x), so that users of the mv_cesa driver won't have to audit the new code. A fair proposal, but I'll freely admit the number of people actually auditing their code paths is orders of magnitude smaller than the number of users of the driver. There's such a large population of compatible legacy SoCs in the wild, adding an artificial boundary doesn't make sense. Especially since we're talking about features everyone would want to use. Perhaps we should keep both around, and deprecate the legacy driver over 3 to 4 cycles? But I guess that some users will want to use the new driver on the old marvell SoCs (especially kirkwood and dove). Yes, despite my arguments, I'm one of those people. :-P If we go to this path, then the best solution would be to still update all the the dts, and modifying the old driver to be able to use the new binding: for my point of view the only adaptation should be related to the SRAM. It will be also needed to find a way to be able to load only one driver at a time: either the old or the new, but not both. The approach Boris proposed above seems to make everyone happy: 1) Keep the old driver for old marvells SoCs (kirkwood, dove and orion) 2) Introduce the new driver for those that are not supported by the old driver, i.e. armada (370, XP, 375, 38x) AFAICT, this can easily be done (based on compatible strings) and it will let everyone the time to audit the new driver. Current users will not be taken by surprise. At some point, when everyone is confident w/ the new driver, we can then switch to that one for all SoCs so that old platform get more performance. Additionnally, for those who want to get the feature of the new driver for their old SoC right now, we *could* add a simple kernel config option for the new driver to use it for the old SoC too (that one disabling the old one). I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. thx, Jason. -- 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: Re: [PATCH 1/2] pinctrl: bcm2835: add pinctrl pre-processor define
Hi Alexander, Alexander Stein alexander...@web.de hat am 13. April 2015 um 19:43 geschrieben: On Monday 13 April 2015, 18:31:17 wrote Stefan Wahren: Hi Alexander, Alexander Stein alexander...@web.de hat am 12. April 2015 um 14:33 geschrieben: This adds defines for the BCM2835 function selections. This is notably useful as the functions are not ordered. if you look at Lee's repository then you will see this is already implemented. Thanks for that information. But I've yet to find it, those 2 on https://git.kernel.org/cgit/ don't seem to contain that. Could you please give me an URL for that repository + branch? Thanks a lot. sorry for the confusion: https://git.kernel.org/cgit/linux/kernel/git/rpi/linux-rpi.git/log/?h=for-rpi-next Best regards, Alexander Stefan -- 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 2/2] memory: pl353: Add driver for arm pl353 static memory controller
On Mon, 2015-04-13 at 21:41 +0530, Punnaiah Choudary Kalluri wrote:
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
+config PL353_SMC
+ bool ARM PL353 Static Memory Controller (SMC) driver
+ depends on ARM
+ help
+ This driver is for the ARM PL353 Static Memory Controller (SMC)
+ module.
This adds a bool symbol.
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
+obj-$(CONFIG_PL353_SMC) += pl353-smc.o
Which means pl353-smc.o can never be part of a module, right?
(If that's not right you can stop reading here.)
--- /dev/null
+++ b/drivers/memory/pl353-smc.c
+ * 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.
This states the license is GPL v2 or later.
+#include linux/module.h
I wonder whether this include is needed, since this is built-in only
code.
+MODULE_DEVICE_TABLE(of, pl353_smc_of_match);
According to include/linux/module.h this will be preprocessed away for
built-in code.
+static struct platform_driver pl353_smc_driver = {
+ .probe = pl353_smc_probe,
+ .remove = pl353_smc_remove,
+ .driver = {
+ .name = pl353-smc,
+ .owner = THIS_MODULE,
THIS_MODULE will be equivalent to NULL for built-in code, according to
include/linux/export.h.
+ .pm = pl353_smc_dev_pm_ops,
+ .of_match_table = pl353_smc_of_match,
+ },
+};
+module_platform_driver(pl353_smc_driver);
Speaking from memory: for built-in only code this is equivalent to
having a wrapper that only does
register_platform_driver(pl353_smc_driver);
and mark that wrapper with device_initcall().
+MODULE_AUTHOR(Xilinx, Inc.);
+MODULE_DESCRIPTION(ARM PL353 SMC Driver);
+MODULE_LICENSE(GPL v2);
For built-in only code these macros will be effectively preprocessed
away.
(Would you make PL353_SMC a tristate symbol then you should note that
according to include/linux/module.h GPL is the license ident that
matches the license stated in the comment at the top of this file.)
Thanks,
Paul Bolle
--
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 1/6] clk: iproc: define Broadcom iProc clock binding
Hi Mike,
On 4/12/2015 11:02 PM, Michael Turquette wrote:
Quoting Ray Jui (2015-04-12 21:08:32)
On 4/10/2015 5:12 PM, Michael Turquette wrote:
Quoting Ray Jui (2015-03-17 22:45:17)
Document the device tree binding for Broadcom iProc architecture based
clock controller
Signed-off-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
.../bindings/clock/brcm,iproc-clocks.txt | 171
1 file changed, 171 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
new file mode 100644
index 000..bf2316b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
@@ -0,0 +1,171 @@
+Broadcom iProc Family Clocks
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The iProc clock controller manages clocks that are common to the iProc
family.
+An SoC from the iProc family may have several PPLs, e.g., ARMPLL, GENPLL,
+LCPLL0, MIPIPLL, and etc., all derived from an onboard crystal. Each PLL
+comprises of several leaf clocks
+
+Required properties for PLLs:
+- compatible:
+Should have a value of the form brcm,soc-pll. For example,
GENPLL on
+Cygnus has a compatible string of brcm,cygnus-genpll
+
+- #clock-cells:
+Must be 0
+
+- reg:
+Define the base and range of the I/O address space that contain the
iProc
+clock control registers required for the PLL
+
+- clocks:
+The input parent clock phandle for the PLL. For all iProc PLLs, this
is an
+onboard crystal with a fixed rate
+
+Example:
+
+ osc: oscillator {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2500;
+ };
+
+ genpll: genpll {
+ #clock-cells = 0;
+ compatible = brcm,cygnus-genpll;
+ reg = 0x0301d000 0x2c,
+ 0x0301c020 0x4;
+ clocks = osc;
+ };
+
+Required properties for leaf clocks of a PLL:
+
+- compatible:
+Should have a value of the form brcm,soc-pll-clk. For example,
leaf
+clocks derived from the GENPLL on Cygnus SoC have a compatible string of
+brcm,cygnus-genpll-clk
+
+- #clock-cells:
+Have a value of 1 since there are more than 1 leaf clock of a
+given PLL
+
+- reg:
+Define the base and range of the I/O address space that contain the
iProc
+clock control registers required for the PLL leaf clocks
+
+- clocks:
+The input parent PLL phandle for the leaf clock
+
+- clock-output-names:
+An ordered list of strings defining the names of the leaf clocks
+
+Example:
+
+ genpll: genpll {
+ #clock-cells = 0;
+ compatible = brcm,cygnus-genpll;
+ reg = 0x0301d000 0x2c,
+ 0x0301c020 0x4;
+ clocks = osc;
+ };
+
+ genpll_clks: genpll_clks {
+ #clock-cells = 1;
+ compatible = brcm,cygnus-genpll-clk;
+ reg = 0x0301d000 0x2c;
+ clocks = genpll;
+ clock-output-names = axi21, 250mhz, ihost_sys,
+ enet_sw, audio_125, can;
+ };
Hi Ray,
Thanks for submitting the patch. It was nice meeting you at ELC as well.
This binding doesn't conform to the norms for clock bindings. It looks
like for each type of controllable clock node (e.g. pll, leaf clock,
etc) you have a dts node. Looking at the above example it seems that
those two nodes (genpll and genpll_clks) share the same register.
/me checks patch #5
Yup, you re-use the same register address for the *pll and *pll_clks
nodes. I'm not a DT expert but I think this is considered Wrong.
More generally your clock dt binding should be modeling the hardware in
terms of IP blocks. If you have a clock generator IP block it may
control many clock bits and output many clock signals. E.g. for your
hardware (based only on the addresses in patch #5 and not having seen
any data manual) I will hazard a guess that the genpll, lcpll and asiu
clocks are all part of the same IP block.
Hi Mike,
In fact, lcpll, genpll, mipipll are similar but DIFFERENT IP blocks, and
asiu is completely different from any of them. All of these plls are
unique and have their own register banks, as you can see from the
bcm-cygnus-clock.dtsi file. Therefore, I think it's totally correct and
actually necessary to represent each of them with a separate device node.
OK, that makes sense to me, if those registers live in addresses ranges
which correspond to different IP blocks.
Regarding the relationship between a PLL clock and its leaf clocks:
Taking the genpll as an example, physically they are connected as:
Re: [PATCH] clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
On Mon, Apr 13, 2015 at 06:37:29PM +0100, Ola Jeppsson wrote:
Some Cortex A9 CPU:s (e.g. zynq) have the tick tied to the CPU
frequency. On those CPU:s we cannot use the global-timer as a reliable
clocksource with CPU frequency scaling enabled since this is not
currently taken into account by the driver.
The global timer is _always_ tied to the CPU frequency -- it's fed by
PERIPHCLK, which must have a period which is a multiple of CLK.
Add a tied-to-cpu-freq boolean to the global-timer dt node indicate
this condition.
Is this indicating the truism above, or that the kernel is performing
frequency scaling? The latter is an OS property rather than a HW
property, and thus doesn't belong in the DT.
The SMP TWD driver tries to account for frequency scaling. Assuming that
works, the same should be possible here. Otherwise, the global timer is
simply unusable with any frequency scaling.
In either case the property seems pointless; all you care about is
whether the platform actually performs CPU frequency scaling.
Mark.
When the global-timer register function sees this property return
immediately and don't register the clocksource.
Signed-off-by: Ola Jeppsson o...@adapteva.com
---
Documentation/devicetree/bindings/arm/global_timer.txt | 4
drivers/clocksource/arm_global_timer.c | 7 +++
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt
b/Documentation/devicetree/bindings/arm/global_timer.txt
index bdae3a818793..465e02c17b5b 100644
--- a/Documentation/devicetree/bindings/arm/global_timer.txt
+++ b/Documentation/devicetree/bindings/arm/global_timer.txt
@@ -17,6 +17,10 @@
- clocks : Should be phandle to a clock.
+** Timer node optional properties:
+
+- tied-to-cpu-freq : indicates that the timer scales with the CPU frequency.
+
Example:
timer@2c000600 {
diff --git a/drivers/clocksource/arm_global_timer.c
b/drivers/clocksource/arm_global_timer.c
index e6833771a716..8913ebda3f09 100644
--- a/drivers/clocksource/arm_global_timer.c
+++ b/drivers/clocksource/arm_global_timer.c
@@ -268,6 +268,13 @@ static void __init global_timer_of_register(struct
device_node *np)
return;
}
+#ifdef CONFIG_CPU_FREQ
+ if (of_property_read_bool(np, tied-to-cpu-freq)) {
+ pr_warn(global-timer: tied to cpu frequency, not supported
with scaling\n);
+ return;
+ }
+#endif
+
gt_clk = of_clk_get(np, 0);
if (!IS_ERR(gt_clk)) {
err = clk_prepare_enable(gt_clk);
--
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
--
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 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
On Mon, 2015-04-13 at 21:42 +0530, Punnaiah Choudary Kalluri wrote: --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile +obj-$(CONFIG_MTD_NAND_PL353) += pl353_nand.o (I think pl353_nand.o can be part of a module. If that's incorrect, you can stop reading here.) --- /dev/null +++ b/drivers/mtd/nand/pl353_nand.c + * 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; either version 2 of the License, or (at your + * option) any later version. This states the license of this driver is GPL v2 or later. +MODULE_LICENSE(GPL v2); And according to include/linux/module.h this states the license is GPL v2. So either the comment at the top of this file or the license ident used in the MODULE_LICENSE() macro needs to change. Thanks, Paul Bolle -- 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: sun7i: Add Goodix GT911 nodes for Wexler TAB7200
On Mon, 13 Apr 2015 18:09:51 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Sat, Apr 11, 2015 at 07:18:16PM +0300, Aleksei Mamlin wrote: On Thu, 2 Apr 2015 11:22:59 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Mar 31, 2015 at 10:14:20PM +0300, Aleksei Mamlin wrote: On Tue, 31 Mar 2015 07:43:38 -0700 Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Tue, Mar 31, 2015 at 11:18:17AM +0300, Aleksei Mamlin wrote: This patch adds nodes for the Goodix GT911 touchscreen controller found on the Wexler TAB7200 tablet. Controller uses one of following I2C addresses: 0x5d or 0x14, so just add two nodes. In which case are these different addresses encountered? Different revisions of the same board? According to the datasheet it is a feature of the controller. The address(0x5d or 0x14) can be configured using a reset sequence, which has not yet been implemented in the driver. Which address is set up by the bootloader then? I assume that bootloader(u-boot) didn't sets up any address, but touchscreen controller usually uses 0x5d. Sometimes, after hard reset, it uses 0x14. For this we need nodes on both adresses. I'm confused, who changes that address then? The controller itself? If I understood correctly, when device starts it sets reset pin (PB13) to high level and int pin(PH21) to low level. After this int pin sets up as external interrupt. This sequence triggers controller to use 0x5d address. After hard reset both pins may be hight level and it triggers controller to use 0x14 address. Please see datasheets at pages 8-10. https://drive.google.com/file/d/0BxCVOQS3ZymGdEE0cHI3bnp5WVE https://drive.google.com/file/d/0BxCVOQS3ZymGbDAzVnZwZ2lOZ1E Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- Thanks and regards, Aleksei Mamlin -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] Renesas Ethernet AVB driver
Ethernet AVB includes an Gigabit Ethernet controller (E-MAC) that is basically
compatible with SuperH Gigabit Ethernet E-MAC). Ethernet AVB has a dedicated
direct memory access controller (AVB-DMAC) that is a new design compared to the
SuperH E-DMAC. The AVB-DMAC is compliant with 3 standards formulated for IEEE
802.1BA: IEEE 802.1AS timing and synchronization protocol, IEEE 802.1Qav real-
time transfer, and the IEEE 802.1Qat stream reservation protocol.
Not only the Ethernet driver is enclosed, there is also the PTP driver in
the same file. These drivers only support device tree probing, so the binding
document is included in this patch.
Based on the original patches by Mitsuhiro Kimura (Ethernet driver) and Masaru
Nagai (PTP driver).
Signed-off-by: Mitsuhiro Kimura mitsuhiro.kimura...@renesas.com
Signed-off-by: Masaru Nagai masaru.nagai...@renesas.com
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against David Miller's 'net-next.git' repo.
Changes in version 3:
- fixed errors due to the PTP core having switched to using 'struct timespec64';
to get/set time, renaming ravb_ptp_{get|set}time();
- fixed type cast warning in ravb_set_buffer_align();
- removed memory allocation failure message from ravb_start_xmit();
- added 'irq' local variable in ravb_probe();
- rephrased error messages in ravb_config() and ravb_close();
- lowercased the first letter of the driver messages throughout;
- renamed the 'result' local variables to 'error' throughout.
Changes in version 2:
- fixed the bug where interrupts weren't re-enabled in ravb_set_ringparam();
- added netif_device_{detach|attach}() calls to ravb_set_ringparam(), fixing
TX watchdog being fired during ring resize;
- made ravb_ring_{init|free}(), ravb_free_dma_buffer(), and ravb_[ed]mac_init()
calls conditional fixing crash/memory leak when resizing rings of a closed
device;
- fixed the order of setting SKBTX_IN_PROGRESS and skb_tx_timestamp() calls;
- implemented ndo_set_rx_mode() method;
- implemented SIOCGHWTSTAMP ioctl(), turning *if* statement in ravb_do_ioctl()
into *switch*;
- merged ravb_wait_clear() and ravb_wait_setting() into ravb_wait(), switching
to 100 times more frequent polling and simplfying the code;
- replaced unbounded register polling loops with ravb_wait() calls;
- switched to using 'struct timespec64' instead of 'struct timespec' whenever
possible, adding code to read/write extra PTP registers;
- added dma_[rw]mb() barrier calls where needed (with comments);
- renamed ravb_reset() to ravb_config(), fixed the comment grammar there;
- renamed ravb_mac_init() to ravb_emac_init(), removing now unneeded parameter,
renamed local variable there, simplified the expression assigned to that
variable;
- removed now unneeded parameter from ravb_dmac_init() along with the code
disabling interrupts, moved netif_start_queue() from this function to its
callers;
- renamed ravb_hwtstamp_ioctl() to ravb_hwtstamp_set(), renaming the 2nd
parameter, removing unused 3rd parameter, and turning the initializer for
one of the local variables into assignment;
- removed unused parameter from ravb_rx();
- renamed variables in ravb_get_tx_tstamp() and ravb_close();
- changed the compatible property values;
- removed unneeded parens and netif_queue_stopped() call in ravb_poll(), fixed
the comment there;
- simplified ravb_ptp_is_config();
- realigned some lines/names/operators throughout;
- sorted the variable declarations by length descending thoughout;
- capitalize the first letter in the comments thoughout;
- added Masaru Nagai to MODULE_AUTHOR();
- mentioned the PTP driver in the changelog;
- added original authors' sign-offs.
Documentation/devicetree/bindings/net/renesas,ravb.txt | 48
drivers/net/ethernet/renesas/Kconfig | 14
drivers/net/ethernet/renesas/Makefile |1
drivers/net/ethernet/renesas/ravb.c| 3078 +
4 files changed, 3141 insertions(+)
Index: net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
===
--- /dev/null
+++ net-next/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -0,0 +1,48 @@
+* Renesas Electronics Ethernet AVB
+
+This file provides information on what the device node for the Ethernet AVB
+interface contains.
+
+Required properties:
+- compatible: renesas,etheravb-r8a7790 if the device is a part of R8A7790
SoC.
+ renesas,etheravb-r8a7794 if the device is a part of R8A7794 SoC.
+- reg: offset and length of (1) the register block and (2) the stream buffer.
+- interrupts: interrupt specifier for the sole interrupt.
+- phy-mode: see ethernet.txt file in the same directory.
+- phy-handle: see ethernet.txt file in the same directory.
+- #address-cells: number of address cells for the MDIO bus, must be equal to 1.
+- #size-cells: number of size cells on the MDIO bus, must be equal to 0.
+-
Re: [PATCH resend] Renesas Ethernet AVB driver
On Tue, 2015-04-14 at 00:13 +0200, Lino Sanfilippo wrote: Hi, On 13.04.2015 22:34, Sergei Shtylyov wrote: Hello. On 04/02/2015 04:56 PM, Ben Hutchings wrote: This driver looks somewhat similar to sh-eth, but lacks some of the recent bug fixes made to that. At least commit 283e38db65e7 (sh_eth: Fix serialisation of interrupt disable with interrupt NAPI handler) appears to be applicable, but there are probably others. I suspect this issue applies to many drivers... I couldn't reproduce the bug that patch was fixing, so left this fix out for the time being. Others cases were fixed (if applicable). Maybe its just harder to trigger but it indeed looks similar to what Ben has fixed for sh-eth. I wonder if that shutdown flag in the fix is really needed though. IMHO it should be save if we simply call napi_disable first, then disable irqs on hardware and finally synchronize_irq... In sh_eth: if we call napi_disable() first, EESR_RX_CHECK can still be set and nothing will clear it. If only one CPU is online this can hard hang the system. Please trust that I did consider and rule out the simpler approaches first. I don't have the full documentation for the EtherAVB block, so I don't know how its programming model differs from the other Ethernet DMA engines. It's possible that a simpler approach will work in ravb. Ben. -- 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] Renesas Ethernet AVB driver
Hello. On 04/13/2015 11:32 PM, David Miller wrote: Ethernet AVB includes an Gigabit Ethernet controller (E-MAC) that is basically compatible with SuperH Gigabit Ethernet E-MAC). Ethernet AVB has a dedicated direct memory access controller (AVB-DMAC) that is a new design compared to the SuperH E-DMAC. The AVB-DMAC is compliant with 3 standards formulated for IEEE 802.1BA: IEEE 802.1AS timing and synchronization protocol, IEEE 802.1Qav real- time transfer, and the IEEE 802.1Qat stream reservation protocol. Not only the Ethernet driver is enclosed, there is also the PTP driver in the same file. These drivers only support device tree probing, so the binding document is included in this patch. Based on the original patches by Mitsuhiro Kimura (Ethernet driver) and Masaru Nagai (PTP driver). Signed-off-by: Mitsuhiro Kimura mitsuhiro.kimura...@renesas.com Signed-off-by: Masaru Nagai masaru.nagai...@renesas.com Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Doesn't build properly on x86-64: CC [M] drivers/net/ethernet/renesas/ravb.o drivers/net/ethernet/renesas/ravb.c: In function ‘ravb_set_buffer_align’: drivers/net/ethernet/renesas/ravb.c:955:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] u32 reserve = (u32)skb-data (RAVB_ALIGN - 1); ^ drivers/net/ethernet/renesas/ravb.c: At top level: drivers/net/ethernet/renesas/ravb.c:2771:2: error: unknown field ‘gettime’ specified in initializer .gettime = ravb_ptp_gettime, ^ drivers/net/ethernet/renesas/ravb.c:2772:2: error: unknown field ‘settime’ specified in initializer .settime = ravb_ptp_settime, ^ So, timespec64 patches have been merged to net-next... In my haste I just forgot to compile-test the driver in net-next, sorry about that. :- It is not acceptable to fix this by removing COMPILE_TEST from the Kconfig dependencies or something like that. It's also impossible as the errors themselves don't depend on ARCH. :-) Thanks. WBR, Sergei -- 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: [v2] dt/bindings: qoriq-clock: Add binding for FMan clock mux
On Sun, 2015-04-12 at 10:54 -0500, Liberman Igal-B31950 wrote: Regards, Igal Liberman. -Original Message- From: Wood Scott-B07421 Sent: Thursday, April 09, 2015 8:03 PM To: Liberman Igal-B31950 Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org Subject: Re: [v2] dt/bindings: qoriq-clock: Add binding for FMan clock mux On Thu, 2015-04-09 at 02:18 -0500, Liberman Igal-B31950 wrote: Regards, Igal Liberman. -Original Message- From: Wood Scott-B07421 Sent: Thursday, April 09, 2015 12:12 AM To: Liberman Igal-B31950 Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org Subject: Re: [v2] dt/bindings: qoriq-clock: Add binding for FMan clock mux On Wed, 2015-04-08 at 10:43 +0300, Igal.Liberman wrote: @@ -76,6 +77,52 @@ Required properties: Recommended properties: - clocks: Should be the phandle of input parent clock + For fsl,fman-clk-mux clock there are several options for parent + clock (clock provider), the parent is determined according to the + Reset Configuration Word of the specific device: + * P2041, P3041: + * 0 - equal to platform PLL divided by 2 + * 1 - equal to PLL2 divided by 2 + * P4080 (Both FMans): + * 0 - equal to platform PLL divided by 2 + * 1 - equal to PLL3 divided by 2 ... Again, the clock specifier format is determined by the clock provider, not the clock consumer. Scott, The clocks property contains all possible clock providers, right? In the text above I'm trying to explain how the FMan clock provider is determined and what are the options for each SoC. Do you think that we shouldn't have this explanation? Can you please elaborate? I'm saying that the clock specifiers must be the same regardless of the node that is consuming the clock. You can't define certain values as only being for fsl,fman-clk-mux. Just to make things clear, In fm0clk/fm1clk node, clocks holds a list of clock specifiers. This list reflects all optional clock providers for a specific hardware, this list varies between different SoCs. All those possible providers described by other nodes, as clock providers. Please notice that this bindings describes the possible source clock for FMan mux, not the providers themselves. You mentioned the following: You can't define certain values as only being for fsl,fman-clk-mux. I'm defining those values in the clock provider nodes and using those values as clock providers for FMan mux, it can be used be other HW blocks too. My point is that the encoding of the clock specifier is not fman-specific and thus fman should not appear in the description. -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
[PATCH 0/3] Qualcomm 8974 RPM Regulator drivers
In 8974 Qualcomm replaced the previously used special purpose mmio communication with SMD; a packet based point-to-point communication interface used since the dawn of time for communicating with the modem - now used to communicate with everything. This series adds a smd client for the RPM as well as the regulator driver ontop of this RPM abstraction. It depends on the pending smd patches: https://patchwork.kernel.org/patch/6200611/ Bjorn Andersson (3): mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding mfd: qcom-smd-rpm: Driver for the Qualcomm RPM over SMD regulator: qcom: smd: Regulator driver for the Qualcomm RPM .../devicetree/bindings/mfd/qcom-rpm-smd.txt | 136 drivers/mfd/Kconfig| 14 + drivers/mfd/Makefile | 1 + drivers/mfd/qcom-smd-rpm.c | 234 ++ drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile | 1 + drivers/regulator/qcom_smd-regulator.c | 351 + include/linux/mfd/qcom-smd-rpm.h | 35 ++ 8 files changed, 784 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt create mode 100644 drivers/mfd/qcom-smd-rpm.c create mode 100644 drivers/regulator/qcom_smd-regulator.c create mode 100644 include/linux/mfd/qcom-smd-rpm.h -- 1.8.2.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 resend] Renesas Ethernet AVB driver
Hello.
On 03/31/2015 01:51 AM, Sergei Shtylyov wrote:
Ethernet AVB includes an Gigabit Ethernet controller (E-MAC) that is basically
compatible with SuperH Gigabit Ethernet E-MAC). Ethernet AVB has a dedicated
direct memory access controller (AVB-DMAC) that is a new design compared to
the
SuperH E-DMAC. The AVB-DMAC is compliant with 3 standards formulated for IEEE
802.1BA: IEEE 802.1AS timing and synchronization protocol, IEEE 802.1Qav real-
time transfer, and the IEEE 802.1Qat stream reservation protocol.
The driver only supports device tree probing, so the binding document is
included in this patch.
Based on the patches by Mitsuhiro Kimura mitsuhiro.kimura...@renesas.com and
Masaru Nagai masaru.nagai...@renesas.com.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
[...]
Index: net-next/drivers/net/ethernet/renesas/ravb.c
===
--- /dev/null
+++ net-next/drivers/net/ethernet/renesas/ravb.c
@@ -0,0 +1,3071 @@
[...]
+/* There is CPU dependent code */
+static int ravb_wait_clear(struct net_device *ndev, u16 reg, u32 bits)
+{
+int i;
+
+for (i = 0; i 100; i++) {
+if (!(ravb_read(ndev, reg) bits))
+break;
+mdelay(1);
+}
+if (i = 100)
+return -ETIMEDOUT;
+
+return 0;
+}
+
+static int ravb_wait_setting(struct net_device *ndev, u16 reg, u32 bits)
+{
This function is identical to the previous one.
It is not, the *break* condition is different. I'll look into merging them
though...
Done.
[...]
+/* Caller must hold the lock */
+static void ravb_ptp_update_compare(struct ravb_private *priv, u32 ns)
+{
+struct net_device *ndev = priv-ndev;
+/* When the comparison value (GPTC.PTCV) is in range of
+ * [x-1 to x+1] (x is the configured increment value in
+ * GTI.TIV), it may happen that a comparison match is
+ * not detected when the timer wraps around.
+ */
What does this funtion do, exactly?
Loads the new timer comparator value, apparenlty.
This looks very fishy to me.
Perhaps a workaround for an errata I don't know about.
Or perhaps it's to keep the comparison value between x and 2**32 - x
(where x is increment in ns) as required by the manual?
Nagai-san, could you maybe elaborate?
[...]
+static bool ravb_ptp_is_config(struct ravb_private *priv)
+{
This is a bit hacky. Can't your driver make sure that the HW is ready?
Will look into this. Perhaps it's a remainder from when the PTP driver was
separate...
No, we enter this mode upon closing the Ethernet device and when the ring
DMA sizes are changed. Seems unavoidable...
+if (ravb_read(priv-ndev, CSR) CSR_OPS_CONFIG)
+return true;
+else
+return false;
+}
+
[...]
WBR, Sergei
--
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] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding
Add binding documentation for the Qualcomm Resource Power Manager (RPM)
using shared memory (Qualcomm SMD) as transport mechanism. This is found
in 8974 and newer based devices.
The binding currently describes the rpm itself and the regulator
subnodes.
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
.../devicetree/bindings/mfd/qcom-rpm-smd.txt | 136 +
1 file changed, 136 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
new file mode 100644
index 000..65e5539
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
@@ -0,0 +1,136 @@
+Qualcomm Resource Power Manager (RPM) over SMD
+
+This driver is used to interface with the Resource Power Manager (RPM) found in
+various Qualcomm platforms. The RPM allows each component in the system to vote
+for state of the system resources, such as clocks, regulators and bus
+frequencies.
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,rpm-msm8974
+
+- qcom,smd-channels:
+ Usage: required
+ Value type: stringlist
+ Definition: Shared Memory channel used for communication with the RPM
+
+= SUBDEVICES
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
+
+== Regulators
+
+Regulator nodes are identified by their compatible:
+
+- compatible:
+ Usage: required
+ Value type: string
+ Definition: must be one of:
+ qcom,rpm-pm8841-regulators
+ qcom,rpm-pm8941-regulators
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_s4-supply:
+- vdd_s5-supply:
+- vdd_s6-supply:
+- vdd_s7-supply:
+- vdd_s8-supply:
+ Usage: optional (pm8841 only)
+ Value type: phandle
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_l1_l3-supply:
+- vdd_l2_lvs1_2_3-supply:
+- vdd_l1_l3-supply:
+- vdd_l4_l11-supply:
+- vdd_l5_l7-supply:
+- vdd_l6_l12_l14_l15-supply:
+- vdd_l5_l7-supply:
+- vdd_l8_l16_l18_l19-supply:
+- vdd_l9_l10_l17_l22-supply:
+- vdd_l9_l10_l17_l22-supply:
+- vdd_l4_l11-supply:
+- vdd_l6_l12_l14_l15-supply:
+- vdd_l13_l20_l23_l24-supply:
+- vdd_l6_l12_l14_l15-supply:
+- vdd_l6_l12_l14_l15-supply:
+- vdd_l8_l16_l18_l19-supply:
+- vdd_l9_l10_l17_l22-supply:
+- vdd_l8_l16_l18_l19-supply:
+- vdd_l8_l16_l18_l19-supply:
+- vdd_l13_l20_l23_l24-supply:
+- vdd_l21-supply:
+- vdd_l9_l10_l17_l22-supply:
+- vdd_l13_l20_l23_l24-supply:
+- vdd_l13_l20_l23_l24-supply:
+- vdd_l2_lvs1_2_3-supply:
+- vdd_l2_lvs1_2_3-supply:
+- vdd_l2_lvs1_2_3-supply:
+- vin_5vs-supply:
+- vin_5vs-supply:
+ Usage: optional (pm8941 only)
+ Value type: phandle
+ Definition: reference to regulator supplying the input pin, as
+ described in the data sheet
+
+The regulator node houses sub-nodes for each regulator within the device. Each
+sub-node is identified using the node's name, with valid values listed for each
+of the pmics below.
+
+pm8841:
+ s1, s2, s3, s4, s5, s6, s7, s8
+
+pm8941:
+ s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
+ l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
+ lvs3, 5vs1, 5vs2
+
+The content of each sub-node is defined by the standard binding for regulators
-
+see regulator.txt.
+
+= EXAMPLE
+
+ smd {
+ compatible = qcom,smd;
+
+ rpm {
+ interrupts = 0 168 1;
+ qcom,ipc = apcs 8 0;
+ qcom,smd-edge = 15;
+
+ rpm_requests {
+ compatible = qcom,rpm-msm8974;
+ qcom,smd-channels = rpm_requests;
+
+ pm8941-regulators {
+ compatible =
qcom,rpm-pm8941-regulators;
+ vdd_l13_l20_l23_l24-supply =
pm8941_boost;
+
+ pm8941_s3: s3 {
+ regulator-min-microvolt =
180;
+ regulator-max-microvolt =
180;
+ };
+
+ pm8941_boost: s4 {
+ regulator-min-microvolt =
500;
+ regulator-max-microvolt =
500;
+ };
+
+ pm8941_l20: l20 {
+ regulator-min-microvolt =
295;
+
Re: [PATCH v2] Renesas Ethernet AVB driver
From: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Date: Mon, 13 Apr 2015 01:36:56 +0300 Ethernet AVB includes an Gigabit Ethernet controller (E-MAC) that is basically compatible with SuperH Gigabit Ethernet E-MAC). Ethernet AVB has a dedicated direct memory access controller (AVB-DMAC) that is a new design compared to the SuperH E-DMAC. The AVB-DMAC is compliant with 3 standards formulated for IEEE 802.1BA: IEEE 802.1AS timing and synchronization protocol, IEEE 802.1Qav real- time transfer, and the IEEE 802.1Qat stream reservation protocol. Not only the Ethernet driver is enclosed, there is also the PTP driver in the same file. These drivers only support device tree probing, so the binding document is included in this patch. Based on the original patches by Mitsuhiro Kimura (Ethernet driver) and Masaru Nagai (PTP driver). Signed-off-by: Mitsuhiro Kimura mitsuhiro.kimura...@renesas.com Signed-off-by: Masaru Nagai masaru.nagai...@renesas.com Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Doesn't build properly on x86-64: CC [M] drivers/net/ethernet/renesas/ravb.o drivers/net/ethernet/renesas/ravb.c: In function ‘ravb_set_buffer_align’: drivers/net/ethernet/renesas/ravb.c:955:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] u32 reserve = (u32)skb-data (RAVB_ALIGN - 1); ^ drivers/net/ethernet/renesas/ravb.c: At top level: drivers/net/ethernet/renesas/ravb.c:2771:2: error: unknown field ‘gettime’ specified in initializer .gettime = ravb_ptp_gettime, ^ drivers/net/ethernet/renesas/ravb.c:2772:2: error: unknown field ‘settime’ specified in initializer .settime = ravb_ptp_settime, ^ It is not acceptable to fix this by removing COMPILE_TEST from the Kconfig dependencies or something like that. Thanks.
Re: [PATCH resend] Renesas Ethernet AVB driver
Hello.
On 04/02/2015 04:56 PM, Ben Hutchings wrote:
This driver looks somewhat similar to sh-eth, but lacks some of the
recent bug fixes made to that. At least commit 283e38db65e7 (sh_eth:
Fix serialisation of interrupt disable with interrupt NAPI handler)
appears to be applicable, but there are probably others.
I suspect this issue applies to many drivers...
I couldn't reproduce the bug that patch was fixing, so left this fix out
for the time being. Others cases were fixed (if applicable).
One feature request:
On Sat, 2015-03-28 at 02:13 +0300, Sergei Shtylyov wrote:
[...]
+/* ioctl to device function */
+static int ravb_do_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+ struct phy_device *phydev = priv-phydev;
+
+ if (!netif_running(ndev))
+ return -EINVAL;
+
+ if (!phydev)
+ return -ENODEV;
+
+ if (cmd == SIOCSHWTSTAMP)
+ return ravb_hwtstamp_ioctl(ndev, req, cmd);
[...]
The driver should also handle SIOCGHWTSTAMP.
Done.
Ben.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resend] Renesas Ethernet AVB driver
Hi, On 13.04.2015 22:34, Sergei Shtylyov wrote: Hello. On 04/02/2015 04:56 PM, Ben Hutchings wrote: This driver looks somewhat similar to sh-eth, but lacks some of the recent bug fixes made to that. At least commit 283e38db65e7 (sh_eth: Fix serialisation of interrupt disable with interrupt NAPI handler) appears to be applicable, but there are probably others. I suspect this issue applies to many drivers... I couldn't reproduce the bug that patch was fixing, so left this fix out for the time being. Others cases were fixed (if applicable). Maybe its just harder to trigger but it indeed looks similar to what Ben has fixed for sh-eth. I wonder if that shutdown flag in the fix is really needed though. IMHO it should be save if we simply call napi_disable first, then disable irqs on hardware and finally synchronize_irq... Lino -- 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] Renesas Ethernet AVB driver
On 13/04/15 15:07, Sergei Shtylyov wrote:
[snip]
+struct ravb_private {
+ struct net_device *ndev;
+ struct platform_device *pdev;
+ void __iomem *addr;
+ struct mdiobb_ctrl mdiobb;
+ u32 num_rx_ring[NUM_RX_QUEUE];
+ u32 num_tx_ring[NUM_TX_QUEUE];
+ u32 desc_bat_size;
+ dma_addr_t desc_bat_dma;
+ struct ravb_desc *desc_bat;
+ dma_addr_t rx_desc_dma[NUM_RX_QUEUE];
+ dma_addr_t tx_desc_dma[NUM_TX_QUEUE];
As a future optimization, you could try to group the variables by
direction: RX and TX such that you have better cache locality.
[snip]
+static void ravb_set_duplex(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+
+ if (priv-duplex) /* Full */
+ ravb_write(ndev, ravb_read(ndev, ECMR) | ECMR_DM, ECMR);
+ else/* Half */
+ ravb_write(ndev, ravb_read(ndev, ECMR) ~ECMR_DM, ECMR);
reg = ravb_read(ndev, ECMR);
if (priv-duplex)
reg |= ECMR_DM;
else
reg = ~ECMR_DM;
ravb_writel(ndev, reg, ECMR);
+}
+
+static void ravb_set_rate(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+
+ switch (priv-speed) {
+ case 100: /* 100BASE */
+ ravb_write(ndev, GECMR_SPEED_100, GECMR);
+ break;
+ case 1000: /* 1000BASE */
+ ravb_write(ndev, GECMR_SPEED_1000, GECMR);
+ break;
+ default:
+ break;
+ }
That still won't quite work with 10Mbits/sec will it? Or is this
controller 100/1000 only (which would be extremely surprising).
[snip]
+ if (desc_status (MSC_CRC | MSC_RFE | MSC_RTSF | MSC_RTLF |
+MSC_CEEF)) {
+ stats-rx_errors++;
+ if (desc_status MSC_CRC)
+ stats-rx_crc_errors++;
+ if (desc_status MSC_RFE)
+ stats-rx_frame_errors++;
+ if (desc_status (MSC_RTLF | MSC_RTSF))
+ stats-rx_length_errors++;
+ if (desc_status MSC_CEEF)
+ stats-rx_missed_errors++;
The flow after the else condition, while refiling might deserve some
explanation.
+ } else {
+ u32 get_ts = priv-tstamp_rx_ctrl RAVB_RXTSTAMP_TYPE;
+
+ skb = priv-rx_skb[q][entry];
Based on the refill logic below, it seems to me like you could leave
holes in your ring where rx_skb[q][entry] is NULL, should not that be
checked here?
+ priv-rx_skb[q][entry] = NULL;
+ dma_sync_single_for_cpu(ndev-dev, desc-dptr,
+ ALIGN(priv-rx_buffer_size, 16),
+ DMA_FROM_DEVICE);
+ get_ts = (q == RAVB_NC) ?
+ RAVB_RXTSTAMP_TYPE_V2_L2_EVENT :
+ ~RAVB_RXTSTAMP_TYPE_V2_L2_EVENT;
+ if (get_ts) {
+ struct skb_shared_hwtstamps *shhwtstamps;
+
+ shhwtstamps = skb_hwtstamps(skb);
+ memset(shhwtstamps, 0, sizeof(*shhwtstamps));
+ ts.tv_sec = ((u64)desc-ts_sh 32) |
+ desc-ts_sl;
+ ts.tv_nsec = (u64)desc-ts_n;
+ shhwtstamps-hwtstamp = timespec64_to_ktime(ts);
+ }
+ skb_put(skb, pkt_len);
+ skb-protocol = eth_type_trans(skb, ndev);
+ if (q == RAVB_NC)
+ netif_rx(skb);
+ else
+ netif_receive_skb(skb);
Can't you always invoke netif_receive_skb() here? Why is there a special
queue?
+ stats-rx_packets++;
+ stats-rx_bytes += pkt_len;
+ }
+
+ entry = (++priv-cur_rx[q]) % priv-num_rx_ring[q];
+ desc = priv-rx_ring[q][entry];
+ }
+
+ /* Refill the RX ring buffers. */
+ for (; priv-cur_rx[q] - priv-dirty_rx[q] 0; priv-dirty_rx[q]++) {
+ entry = priv-dirty_rx[q] % priv-num_rx_ring[q];
+ desc = priv-rx_ring[q][entry];
+ /* The size of the buffer should be on 16-byte boundary. */
+ desc-ds = ALIGN(priv-rx_buffer_size, 16);
+
+ if (!priv-rx_skb[q][entry]) {
+ skb = netdev_alloc_skb(ndev, skb_size);
+ if (!skb)
+ break; /* Better luck next round. */
Should this really be a break or a continue?
[snip]
+/* function for waiting dma process finished */
+static void
Re: [GIT PULL] simple-mfd cleanup
On Wednesday 08 April 2015, Linus Walleij wrote: On Wed, Mar 25, 2015 at 8:50 AM, Linus Walleij linus.wall...@linaro.org wrote: Cleanups from Antoine Tenart and Alexandre Belloni depend on this. Please pull this in. Ping on this. The OF patch is ACKed by Grant: http://marc.info/?l=devicetreeamp;m=142755431728537amp;w=2 Somehow we completely missed this one, sorry about that. I really wanted to have it merged, but it's too late now, especially as the patches were not in linux-next already. Please send again after rebasing on top of -rc1. 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] ARM: socfpga: dts: Add a ciu clock node for sdmmc
Hi,
On Fri, Apr 10, 2015 at 1:56 PM, dingu...@opensource.altera.com wrote:
From: Dinh Nguyen dingu...@opensource.altera.com
The CIU(Card Interface Unit) clock is used by the dw_mmc IP to clock an SD
card. The ciu_clk is the sdmmc_clk passed through a fixed divider of 4. This
patch
adds the ciu_clk node and makes the sdmmc_clk it's parent.
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
arch/arm/boot/dts/socfpga.dtsi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index d9176e6..25418ee 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -451,6 +451,14 @@
clk-phase = 0 135;
};
+ ciu_clk: ciu_clk {
Can't say I'm an expert on socfpga, but seems like this clock is only
for sdmmc, right? ...so its name ought to have sdmmc in its name?
-Doug
--
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 00/11] ARM: vf610m4: Add Vybrid Cortex-M4 support
On Thursday 09 April 2015, Stefan Agner wrote: In this fifth revision the patchset moves away from the idea including ARMv7-M platforms into ARCH_MULTIPLATFORM, but instead adds a new top-level config symbol ARM_SINGLE_ARMV7M Patch 7 adds this new config symbol while patch 8 alters the existing ARMv7-M platform ARCH_EFM32 to use ARM_SINGLE_ARMV7M. I chose to move the config symbol of the ARMv7-M specific architectures (ARCH_EFM32 at that point) below the multiarch includes. I think it is a good idea to keep them together, but I'm not sure if this is an appropriate place. The architecture which Vybrid is depending on, ARCH_MXC, is not also selectable when ARM_SINGLE_ARMV7M is selected. It's a shame we didn't manage to pull these in in time for 4.1, but while the patches look ok to me, they came a little late, and it's not clear to me how we should maintain that platform. You have lots of people on 'To:' for the emails, which is always confusing. My preferred way of merging these in 4.2 would be for you to send the patches to the imx maintainers so they can pick them up and send them to a...@kernel.org. 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 resend] Renesas Ethernet AVB driver
On Tue, 2015-04-14 at 00:53 +0200, Lino Sanfilippo wrote: On 14.04.2015 00:31, Ben Hutchings wrote: This driver looks somewhat similar to sh-eth, but lacks some of the recent bug fixes made to that. At least commit 283e38db65e7 (sh_eth: Fix serialisation of interrupt disable with interrupt NAPI handler) appears to be applicable, but there are probably others. I suspect this issue applies to many drivers... I couldn't reproduce the bug that patch was fixing, so left this fix out for the time being. Others cases were fixed (if applicable). Maybe its just harder to trigger but it indeed looks similar to what Ben has fixed for sh-eth. I wonder if that shutdown flag in the fix is really needed though. IMHO it should be save if we simply call napi_disable first, then disable irqs on hardware and finally synchronize_irq... In sh_eth: if we call napi_disable() first, EESR_RX_CHECK can still be set and nothing will clear it. If only one CPU is online this can hard hang the system. Please trust that I did consider and rule out the simpler approaches first. The idea was to check the return value from napi_schedule_prep() and in case it returns false use this as an indication for a shutdown. In case of sh_eth this would be sh_eth_write(ndev, 0, EESIPR) for example. Might work - but please give it a thorough test. Ben. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resend] Renesas Ethernet AVB driver
On 14.04.2015 00:31, Ben Hutchings wrote: This driver looks somewhat similar to sh-eth, but lacks some of the recent bug fixes made to that. At least commit 283e38db65e7 (sh_eth: Fix serialisation of interrupt disable with interrupt NAPI handler) appears to be applicable, but there are probably others. I suspect this issue applies to many drivers... I couldn't reproduce the bug that patch was fixing, so left this fix out for the time being. Others cases were fixed (if applicable). Maybe its just harder to trigger but it indeed looks similar to what Ben has fixed for sh-eth. I wonder if that shutdown flag in the fix is really needed though. IMHO it should be save if we simply call napi_disable first, then disable irqs on hardware and finally synchronize_irq... In sh_eth: if we call napi_disable() first, EESR_RX_CHECK can still be set and nothing will clear it. If only one CPU is online this can hard hang the system. Please trust that I did consider and rule out the simpler approaches first. The idea was to check the return value from napi_schedule_prep() and in case it returns false use this as an indication for a shutdown. In case of sh_eth this would be sh_eth_write(ndev, 0, EESIPR) for example. Lino -- 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] Renesas Ethernet AVB driver
Hi,
On 14.04.2015 00:07, Sergei Shtylyov wrote:
+struct ravb_desc {
+#ifdef __LITTLE_ENDIAN
+ u32 ds: 12; /* Descriptor size */
+ u32 cc: 12; /* Content control */
+ u32 die: 4; /* Descriptor interrupt enable */
+ /* 0: disable, other: enable */
+ u32 dt: 4; /* Descriptor type */
+#else
+ u32 dt: 4; /* Descriptor type */
+ u32 die: 4; /* Descriptor interrupt enable */
+ /* 0: disable, other: enable */
+ u32 cc: 12; /* Content control */
+ u32 ds: 12; /* Descriptor size */
+#endif
+ u32 dptr; /* Descriptor pointer */
+};
+
+struct ravb_rx_desc {
+#ifdef __LITTLE_ENDIAN
+ u32 ds: 12; /* Descriptor size */
+ u32 ei: 1; /* Error indication */
+ u32 ps: 2; /* Padding selection */
+ u32 tr: 1; /* Truncation indication */
+ u32 msc: 8; /* MAC status code */
+ u32 die: 4; /* Descriptor interrupt enable */
+ /* 0: disable, other: enable */
+ u32 dt: 4; /* Descriptor type */
+#else
+ u32 dt: 4; /* Descriptor type */
+ u32 die: 4; /* Descriptor interrupt enable */
+ /* 0: disable, other: enable */
+ u32 msc: 8; /* MAC status code */
+ u32 ps: 2; /* Padding selection */
+ u32 ei: 1; /* Error indication */
+ u32 tr: 1; /* Truncation indication */
+ u32 ds: 12; /* Descriptor size */
+#endif
+ u32 dptr; /* Descpriptor pointer */
+};
+
+struct ravb_ex_rx_desc {
+#ifdef __LITTLE_ENDIAN
+ u32 ds: 12; /* Descriptor size */
+ u32 ei: 1; /* Error indication */
+ u32 ps: 2; /* Padding selection */
+ u32 tr: 1; /* Truncation indication */
+ u32 msc: 8; /* MAC status code */
+ u32 die: 4; /* Descriptor interrupt enable */
+ /* 0: disable, other: enable */
+ u32 dt: 4; /* Descriptor type */
+#else
+ u32 dt: 4; /* Descriptor type */
+ u32 die: 4; /* Descriptor interrupt enable */
+ /* 0: disable, other: enable */
+ u32 msc: 8; /* MAC status code */
+ u32 ps: 2; /* Padding selection */
+ u32 ei: 1; /* Error indication */
+ u32 tr: 1; /* Truncation indication */
+ u32 ds: 12; /* Descriptor size */
+#endif
+ u32 dptr; /* Descpriptor pointer */
+ u32 ts_n; /* Timestampe nsec */
+ u32 ts_sl; /* Timestamp low */
+#ifdef __LITTLE_ENDIAN
+ u32 res: 16;/* Reserved bits */
+ u32 ts_sh: 16; /* Timestamp high */
+#else
+ u32 ts_sh: 16; /* Timestamp high */
+ u32 res: 16;/* Reserved bits */
+#endif
+};
I recall a thread in which the use of bitfields for structs that are
shared with the hardware was considered a bad idea (because the compiler
is free to reorder the fields). Shift operations are probably a better
choice here.
+
+struct ravb_tx_desc {
+#ifdef __LITTLE_ENDIAN
+ u32 ds: 12; /* Descriptor size */
+ u32 tag: 10;/* Frame tag */
+ u32 tsr: 1; /* Timestamp storage request */
+ u32 msc: 1; /* MAC status storage request */
+ u32 die: 4; /* Descriptor interrupt enable */
+ /* 0: disable, other: enable */
+ u32 dt: 4; /* Descriptor type */
+#else
+ u32 dt: 4; /* Descriptor type */
+ u32 die: 4; /* Descriptor interrupt enable */
+ /* 0: disable, other: enable */
+ u32 msc: 1; /* MAC status storage request */
+ u32 tsr: 1; /* Timestamp storage request */
+ u32 tag: 10;/* Frame tag */
+ u32 ds: 12; /* Descriptor size */
+#endif
+ u32 dptr; /* Descpriptor pointer */
+};
+
Same as above.
+
+/* Network device open function for Ethernet AVB */
+static int ravb_open(struct net_device *ndev)
+{
+ struct ravb_private *priv = netdev_priv(ndev);
+ int error;
+
+ napi_enable(priv-napi);
+
+ error = request_irq(ndev-irq, ravb_interrupt, IRQF_SHARED, ndev-name,
+ ndev);
+ if (error) {
+ netdev_err(ndev, cannot request IRQ\n);
+ goto out_napi_off;
+ }
+
+ /* Descriptor set */
+ /* +26 gets the maximum ethernet encapsulation, +7 ~7 because the
+ * card needs room to do 8 byte alignment, +2 so we can reserve
+ * the first 2 bytes, and +16 gets room for the status word from the
+ * card.
+ */
+ priv-rx_buffer_size = (ndev-mtu = 1492 ? PKT_BUF_SZ :
+ (((ndev-mtu + 26 + 7) ~7) + 2 + 16));
+
+ error = ravb_ring_init(ndev, RAVB_BE);
+ if (error)
+ goto out_free_irq;
+ error = ravb_ring_init(ndev, RAVB_NC);
+ if (error)
+ goto out_free_irq;
+
+ /* Device init */
+ error = ravb_dmac_init(ndev);
+ if (error)
+
[PATCH] of/fdt: fix allocation size for device node path
The allocation size of device node path is off by one which drops the '\0' terminator. Signed-off-by: Ricky Liang jcli...@chromium.org --- drivers/of/fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 3a896c9..98a9e6e 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -172,7 +172,7 @@ static void * unflatten_dt_node(void *blob, if (!pathp) return mem; - allocl = l++; + allocl = ++l; /* version 0x10 has a more compact unit name here instead of the full * path. we accumulate the full path size using fpsize, we'll rebuild -- 2.1.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 resend] Renesas Ethernet AVB driver
On Mon, Apr 13, 2015 at 11:23:26PM +0300, Sergei Shtylyov wrote: This is a bit hacky. Can't your driver make sure that the HW is ready? Will look into this. Perhaps it's a remainder from when the PTP driver was separate... No, we enter this mode upon closing the Ethernet device and when the ring DMA sizes are changed. Seems unavoidable... +if (ravb_read(priv-ndev, CSR) CSR_OPS_CONFIG) +return true; +else +return false; It is surely avoidable. The driver knows (or should know) whether or not the hardware has been configured or not. Thanks, Richard -- 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 3/6] clk: hi6220: Document devicetree bindings for hi6220 clock
Hello Arnd,
On 2015/4/13 23:32, Arnd Bergmann wrote:
On Monday 13 April 2015 17:17:37 Bintian Wang wrote:
+- compatible: the compatible should be one of the following strings to
+ indicate the clock controller functionality.
+
+ - hisilicon,aoctrl
+ - hisilicon,sysctrl
+ - hisilicon,mediactrl
+ - hisilicon,pmctrl
+
These ones already have bindings, you can't reuse the strings.
Please work with someone in hisilicon to set up a registry of
device names so you can avoid conflicts in the future.
All the clock registers are under above four system controllers,
discussed with Mark and Haojian two months ago, I think using above
same four binding strings is enough for clk module.
On second thoughts, there really some problems for future hisilicon
code upstream, how about change back to the first version of this
patch set, just like following:
+ sys_ctrl: sys_ctrl {
+ compatible = hisilicon,sysctrl, syscon;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x0 0xf703 0x0 0x2000;
+ ranges = 0 0x0 0xf703 0x2000;
+
+ clock_sys: clock1@0 {
+ compatible = hisilicon,hi6220-clock-sys;
+ reg = 0 0x1000;
+ #clock-cells = 1;
+ };
+ };
Thanks,
Bintian
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: Re: [PATCH 1/2] pinctrl: bcm2835: add pinctrl pre-processor define
On Monday 13 April 2015, 18:31:17 wrote Stefan Wahren: Hi Alexander, Alexander Stein alexander...@web.de hat am 12. April 2015 um 14:33 geschrieben: This adds defines for the BCM2835 function selections. This is notably useful as the functions are not ordered. if you look at Lee's repository then you will see this is already implemented. Thanks for that information. But I've yet to find it, those 2 on https://git.kernel.org/cgit/ don't seem to contain that. Could you please give me an URL for that repository + branch? Thanks a lot. Best regards, Alexander -- 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: sun7i: Add Goodix GT911 nodes for Wexler TAB7200
On Sat, Apr 11, 2015 at 07:36:14PM +0300, Aleksei Mamlin wrote: On Thu, 2 Apr 2015 20:50:08 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Mar 31, 2015 at 10:31:20PM +0300, Aleksei Mamlin wrote: + compatible = goodix,gt911; + reg = 0x5d; + interrupt-parent = pio; + interrupts = 21 IRQ_TYPE_NONE; /* EINT21 (PH21) */ Unfortunately, IRQ_TYPE_NONE is not a valid value for the GIC bindings. Hmm. Which value I must use in this case? IRQ type is set by the touchscreen controller driver, so I think that value must be 0. Whatever the hardware is using. Presumably the same value than the driver sets. You're also not adding a pinctrl group for that pin? No, because it works fine with this DT nodes. It seems that I should first configure pin to work in interrupt mode. Correct? You don't have to, since the pio driver will already take care of muxing it to the right function, but that will prevent any driver to call pinctrl_request on the same pin. It is still necessary? I see that you have accepted Hans de Goede's patches: http://www.spinics.net/lists/arm-kernel/msg411142.html No, it's fine. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: sun7i: Add Goodix GT911 nodes for Wexler TAB7200
On Sat, Apr 11, 2015 at 07:18:16PM +0300, Aleksei Mamlin wrote: On Thu, 2 Apr 2015 11:22:59 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Mar 31, 2015 at 10:14:20PM +0300, Aleksei Mamlin wrote: On Tue, 31 Mar 2015 07:43:38 -0700 Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Tue, Mar 31, 2015 at 11:18:17AM +0300, Aleksei Mamlin wrote: This patch adds nodes for the Goodix GT911 touchscreen controller found on the Wexler TAB7200 tablet. Controller uses one of following I2C addresses: 0x5d or 0x14, so just add two nodes. In which case are these different addresses encountered? Different revisions of the same board? According to the datasheet it is a feature of the controller. The address(0x5d or 0x14) can be configured using a reset sequence, which has not yet been implemented in the driver. Which address is set up by the bootloader then? I assume that bootloader(u-boot) didn't sets up any address, but touchscreen controller usually uses 0x5d. Sometimes, after hard reset, it uses 0x14. For this we need nodes on both adresses. I'm confused, who changes that address then? The controller itself? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH V4 0/5] Add big-endian MMIO support to serial8250
On Fri, Apr 10, 2015 at 10:28:55AM -0400, Peter Hurley wrote: On 04/10/2015 09:52 AM, Rob Herring wrote: On Thu, Apr 9, 2015 at 3:05 PM, Kevin Cernekee cerne...@gmail.com wrote: V3-V4: Rebase on Linus' head of tree Tweak documentation per Grant's request Drop the of_earlycon patches in favor of Peter's series Are there conflicts with Peter's stuff? No. It adds the required pieces so that a trivial patch on top of both series will enable mmio32be for earlycon. The series looks good to me. Same. Reviewed-by: Peter Hurley pe...@hurleysoftware.com Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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] clocksource: arm_global_timer: Detect if gt is usable with CPU_FREQ
Some Cortex A9 CPU:s (e.g. zynq) have the tick tied to the CPU
frequency. On those CPU:s we cannot use the global-timer as a reliable
clocksource with CPU frequency scaling enabled since this is not
currently taken into account by the driver.
Add a tied-to-cpu-freq boolean to the global-timer dt node indicate
this condition.
When the global-timer register function sees this property return
immediately and don't register the clocksource.
Signed-off-by: Ola Jeppsson o...@adapteva.com
---
Documentation/devicetree/bindings/arm/global_timer.txt | 4
drivers/clocksource/arm_global_timer.c | 7 +++
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt
b/Documentation/devicetree/bindings/arm/global_timer.txt
index bdae3a818793..465e02c17b5b 100644
--- a/Documentation/devicetree/bindings/arm/global_timer.txt
+++ b/Documentation/devicetree/bindings/arm/global_timer.txt
@@ -17,6 +17,10 @@
- clocks : Should be phandle to a clock.
+** Timer node optional properties:
+
+- tied-to-cpu-freq : indicates that the timer scales with the CPU frequency.
+
Example:
timer@2c000600 {
diff --git a/drivers/clocksource/arm_global_timer.c
b/drivers/clocksource/arm_global_timer.c
index e6833771a716..8913ebda3f09 100644
--- a/drivers/clocksource/arm_global_timer.c
+++ b/drivers/clocksource/arm_global_timer.c
@@ -268,6 +268,13 @@ static void __init global_timer_of_register(struct
device_node *np)
return;
}
+#ifdef CONFIG_CPU_FREQ
+ if (of_property_read_bool(np, tied-to-cpu-freq)) {
+ pr_warn(global-timer: tied to cpu frequency, not supported
with scaling\n);
+ return;
+ }
+#endif
+
gt_clk = of_clk_get(np, 0);
if (!IS_ERR(gt_clk)) {
err = clk_prepare_enable(gt_clk);
--
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: socfpga: dts: Add a ciu clock node for sdmmc
Hi!
dingu...@opensource.altera.com writes:
From: Dinh Nguyen dingu...@opensource.altera.com
The CIU(Card Interface Unit) clock is used by the dw_mmc IP to clock an SD
card. The ciu_clk is the sdmmc_clk passed through a fixed divider of 4. This
patch
adds the ciu_clk node and makes the sdmmc_clk it's parent.
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
arch/arm/boot/dts/socfpga.dtsi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index d9176e6..25418ee 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -451,6 +451,14 @@
clk-phase = 0 135;
};
+ ciu_clk: ciu_clk {
+ #clock-cells = 0;
+ compatible =
altr,socfpga-gate-clk;
+ clocks = sdmmc_clk;
+ clk-gate = 0xa0 8;
+ fixed-divider = 4;
+ };
+
Hm, is this correct? The clk-gate at 0xa0 is for the SDMMC_CLK, no?
Also, maybe the clock should be named sdmmc_clk_divided like in the
datasheet, so it is easier to find.
nand_x_clk: nand_x_clk {
#clock-cells = 0;
compatible =
altr,socfpga-gate-clk;
@@ -635,7 +643,7 @@
fifo-depth = 0x400;
#address-cells = 1;
#size-cells = 0;
- clocks = l4_mp_clk, sdmmc_clk;
+ clocks = l4_mp_clk, ciu_clk;
clock-names = biu, ciu;
};
Regards,
Steffen
--
Pengutronix e.K. | Steffen Trumtrar|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 1/6] clk: iproc: define Broadcom iProc clock binding
Quoting Ray Jui (2015-04-12 21:08:32)
On 4/10/2015 5:12 PM, Michael Turquette wrote:
Quoting Ray Jui (2015-03-17 22:45:17)
Document the device tree binding for Broadcom iProc architecture based
clock controller
Signed-off-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
.../bindings/clock/brcm,iproc-clocks.txt | 171
1 file changed, 171 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
new file mode 100644
index 000..bf2316b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
@@ -0,0 +1,171 @@
+Broadcom iProc Family Clocks
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The iProc clock controller manages clocks that are common to the iProc
family.
+An SoC from the iProc family may have several PPLs, e.g., ARMPLL, GENPLL,
+LCPLL0, MIPIPLL, and etc., all derived from an onboard crystal. Each PLL
+comprises of several leaf clocks
+
+Required properties for PLLs:
+- compatible:
+Should have a value of the form brcm,soc-pll. For example,
GENPLL on
+Cygnus has a compatible string of brcm,cygnus-genpll
+
+- #clock-cells:
+Must be 0
+
+- reg:
+Define the base and range of the I/O address space that contain the
iProc
+clock control registers required for the PLL
+
+- clocks:
+The input parent clock phandle for the PLL. For all iProc PLLs, this
is an
+onboard crystal with a fixed rate
+
+Example:
+
+ osc: oscillator {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2500;
+ };
+
+ genpll: genpll {
+ #clock-cells = 0;
+ compatible = brcm,cygnus-genpll;
+ reg = 0x0301d000 0x2c,
+ 0x0301c020 0x4;
+ clocks = osc;
+ };
+
+Required properties for leaf clocks of a PLL:
+
+- compatible:
+Should have a value of the form brcm,soc-pll-clk. For example,
leaf
+clocks derived from the GENPLL on Cygnus SoC have a compatible string of
+brcm,cygnus-genpll-clk
+
+- #clock-cells:
+Have a value of 1 since there are more than 1 leaf clock of a
+given PLL
+
+- reg:
+Define the base and range of the I/O address space that contain the
iProc
+clock control registers required for the PLL leaf clocks
+
+- clocks:
+The input parent PLL phandle for the leaf clock
+
+- clock-output-names:
+An ordered list of strings defining the names of the leaf clocks
+
+Example:
+
+ genpll: genpll {
+ #clock-cells = 0;
+ compatible = brcm,cygnus-genpll;
+ reg = 0x0301d000 0x2c,
+ 0x0301c020 0x4;
+ clocks = osc;
+ };
+
+ genpll_clks: genpll_clks {
+ #clock-cells = 1;
+ compatible = brcm,cygnus-genpll-clk;
+ reg = 0x0301d000 0x2c;
+ clocks = genpll;
+ clock-output-names = axi21, 250mhz, ihost_sys,
+ enet_sw, audio_125, can;
+ };
Hi Ray,
Thanks for submitting the patch. It was nice meeting you at ELC as well.
This binding doesn't conform to the norms for clock bindings. It looks
like for each type of controllable clock node (e.g. pll, leaf clock,
etc) you have a dts node. Looking at the above example it seems that
those two nodes (genpll and genpll_clks) share the same register.
/me checks patch #5
Yup, you re-use the same register address for the *pll and *pll_clks
nodes. I'm not a DT expert but I think this is considered Wrong.
More generally your clock dt binding should be modeling the hardware in
terms of IP blocks. If you have a clock generator IP block it may
control many clock bits and output many clock signals. E.g. for your
hardware (based only on the addresses in patch #5 and not having seen
any data manual) I will hazard a guess that the genpll, lcpll and asiu
clocks are all part of the same IP block.
Hi Mike,
In fact, lcpll, genpll, mipipll are similar but DIFFERENT IP blocks, and
asiu is completely different from any of them. All of these plls are
unique and have their own register banks, as you can see from the
bcm-cygnus-clock.dtsi file. Therefore, I think it's totally correct and
actually necessary to represent each of them with a separate device node.
OK, that makes sense to me, if those registers live in addresses ranges
which correspond to different IP blocks.
Regarding the relationship between a PLL clock and its leaf
Re: [PATCH v3 3/5] PCI: st: Provide support for the sti PCIe controller
Hi
Thanks for reviewing.
On 11 April 2015 at 16:55, Arnd Bergmann a...@arndb.de wrote:
On Saturday 11 April 2015 12:17:57 Paul Bolle wrote:
Something I didn't spot in my first look at this patch.
On Fri, 2015-04-10 at 11:12 +0200, Gabriel FERNANDEZ wrote:
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
+config PCI_ST
+ bool ST PCIe controller
+ depends on ARCH_STI || (ARM COMPILE_TEST)
+ select PCIE_DW
+ help
+ Enable PCIe controller support on ST Socs. This controller is based
+ on Designware hardware and therefore the driver re-uses the
+ Designware core functions to implement the driver.
You can't have ARCH_STI without ARM, so ARM will always be set if this
driver is enabled. Correct?
Right, though the ARM dependency could soon be dropped, once the PCIE_DW
driver can use generic infrastructure in the few places it relies on
ARM specific code today.
--- /dev/null
+++ b/drivers/pci/host/pci-st.c
+ if (IS_ENABLED(CONFIG_ARM)) {
+ /*
+ * We have to hook the abort handler so that we can intercept
+ * bus errors when doing config read/write that return UR,
+ * which is flagged up as a bus error
+ */
+ hook_fault_code(16+6, st_pcie_abort_handler, SIGBUS, 0,
+ imprecise external abort);
+ }
So, unless I'm missing something obvious here, IS_ENABLED(CONFIG_ARM)
will always evaluate to 1. Can't that test be dropped?
I would leave it in, as it's quite likely to get reused with ARM64 at some
point in the future (no, I don't know anything about ST's product plans,
but everybody seems to be doing this).
Arnd
Yes i agree with that.
Gabriel
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/6] arm64: dts: Add dts files for Hisilicon Hi6220 SoC
Add initial dtsi file to support Hisilicon Hi6220 SoC with
support of Octal core CPUs in two clusters and each cluster
has quard Cortex-A53.
Also add dts file to support HiKey development board which
based on Hi6220 SoC.
Signed-off-by: Bintian Wang bintian.w...@huawei.com
Reviewed-by: Haojian Zhuang haojian.zhu...@linaro.org
Reviewed-by: Yiping Xu xuyip...@hisilicon.com
---
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/hisilicon/Makefile | 5 +
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 28
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 171 +
4 files changed, 205 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/Makefile
create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220.dtsi
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index e0350ca..3c1c4cf 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -5,5 +5,6 @@ dts-dirs += cavium
dts-dirs += exynos
dts-dirs += freescale
dts-dirs += mediatek
+dts-dirs += hisilicon
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/hisilicon/Makefile
b/arch/arm64/boot/dts/hisilicon/Makefile
new file mode 100644
index 000..fa81a6e
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
+
+always := $(dtb-y)
+subdir-y := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
new file mode 100644
index 000..c4b3ed8
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -0,0 +1,28 @@
+/*
+ * dts file for Hisilicon HiKey Development Board
+ *
+ * Copyright (C) 2015, Hisilicon Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include hi6220.dtsi
+
+/ {
+ model = HiKey Development Board;
+ compatible = hisilicon,hi6220-hikey;
+
+ aliases {
+ serial0 = uart0;
+ };
+
+ chosen {
+ linux,stdout-path = uart0;
+ };
+
+ memory@0 {
+ device_type = memory;
+ reg = 0x0 0x0 0x0 0x4000;
+ };
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
new file mode 100644
index 000..ca0f64c
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -0,0 +1,171 @@
+/*
+ * dts file for Hisilicon Hi6220 SoC
+ *
+ * Copyright (C) 2015, Hisilicon Ltd.
+ */
+
+#include dt-bindings/clock/hi6220-clock.h
+#include dt-bindings/interrupt-controller/arm-gic.h
+
+/ {
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ psci {
+ compatible = arm,psci-0.2;
+ method = smc;
+ };
+
+ cpus {
+ #address-cells = 2;
+ #size-cells = 0;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = cpu0;
+ };
+ core1 {
+ cpu = cpu1;
+ };
+ core2 {
+ cpu = cpu2;
+ };
+ core3 {
+ cpu = cpu3;
+ };
+ };
+ cluster1 {
+ core0 {
+ cpu = cpu4;
+ };
+ core1 {
+ cpu = cpu5;
+ };
+ core2 {
+ cpu = cpu6;
+ };
+ core3 {
+ cpu = cpu7;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ compatible = arm,cortex-a53, arm,armv8;
+ device_type = cpu;
+ reg = 0x0 0x0;
+ enable-method = psci;
+ };
+
+ cpu1: cpu@1 {
+ compatible = arm,cortex-a53, arm,armv8;
+ device_type = cpu;
+ reg = 0x0 0x1;
+ enable-method = psci;
+ };
+
+ cpu2: cpu@2 {
+ compatible = arm,cortex-a53, arm,armv8;
+ device_type = cpu;
+ reg = 0x0 0x2;
+ enable-method = psci;
+ };
+
+ cpu3: cpu@3 {
+ compatible = arm,cortex-a53, arm,armv8;
+ device_type
[PATCH v2 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
Add clock drivers for hi6220 SoC, this driver controls the SoC
registers to supply different clocks to different IPs in the SoC.
We add one divider clock for hi6220 because the divider in hi6220
also has a mask bit but it doesnot obey the rule defined by flag
CLK_DIVIDER_HIWORD_MASK, we can not get index of the mask bit by
left shift fixed bits (e.g. 16 bits), so we add this divider clock
to handle it.
Signed-off-by: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org
Signed-off-by: Bintian Wang bintian.w...@huawei.com
Reviewed-by: Haojian Zhuang haojian.zhu...@linaro.org
Reviewed-by: Zhangfei Gao zhangfei@linaro.org
---
drivers/clk/Kconfig | 2 +
drivers/clk/Makefile | 4 +-
drivers/clk/hisilicon/Kconfig | 5 +
drivers/clk/hisilicon/Makefile| 3 +-
drivers/clk/hisilicon/clk-hi6220.c| 292 ++
drivers/clk/hisilicon/clk.c | 29 +++
drivers/clk/hisilicon/clk.h | 17 ++
drivers/clk/hisilicon/clkdivider-hi6220.c | 273
include/dt-bindings/clock/hi6220-clock.h | 173 ++
9 files changed, 794 insertions(+), 4 deletions(-)
create mode 100644 drivers/clk/hisilicon/Kconfig
create mode 100644 drivers/clk/hisilicon/clk-hi6220.c
create mode 100644 drivers/clk/hisilicon/clkdivider-hi6220.c
create mode 100644 include/dt-bindings/clock/hi6220-clock.h
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 0b474a0..415fc31 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -145,6 +145,8 @@ config COMMON_CLK_CDCE706
source drivers/clk/qcom/Kconfig
+source drivers/clk/hisilicon/Kconfig
+
endmenu
source drivers/clk/bcm/Kconfig
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d478ceb..45fa028 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -45,9 +45,7 @@ obj-$(CONFIG_COMMON_CLK_XGENE)+= clk-xgene.o
obj-$(CONFIG_COMMON_CLK_AT91) += at91/
obj-$(CONFIG_ARCH_BCM_MOBILE) += bcm/
obj-$(CONFIG_ARCH_BERLIN) += berlin/
-obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
-obj-$(CONFIG_ARCH_HIP04) += hisilicon/
-obj-$(CONFIG_ARCH_HIX5HD2) += hisilicon/
+obj-$(CONFIG_ARCH_HISI)+= hisilicon/
obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
ifeq ($(CONFIG_COMMON_CLK), y)
obj-$(CONFIG_ARCH_MMP) += mmp/
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
new file mode 100644
index 000..e3ead46
--- /dev/null
+++ b/drivers/clk/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+config COMMON_CLK_HI6220
+ tristate Hi6220 Clock Driver
+ depends on OF ARCH_HISI
+ help
+ Build the Hisilicon Hi6220 clock driver based on the common clock
framework.
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 038c02f..48f0116 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -2,8 +2,9 @@
# Hisilicon Clock specific Makefile
#
-obj-y += clk.o clkgate-separated.o
+obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o
obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o
obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
+obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o
diff --git a/drivers/clk/hisilicon/clk-hi6220.c
b/drivers/clk/hisilicon/clk-hi6220.c
new file mode 100644
index 000..ee85a3a
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi6220.c
@@ -0,0 +1,292 @@
+/*
+ * Hisilicon Hi6220 clock driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Bintian Wang bintian.w...@huawei.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/slab.h
+#include linux/clk.h
+
+#include dt-bindings/clock/hi6220-clock.h
+
+#include clk.h
+
+
+/* clocks in AO (always on) controller */
+static struct hisi_fixed_rate_clock hi6220_fixed_rate_clks[] __initdata = {
+ { HI6220_REF32K,ref32k, NULL, CLK_IS_ROOT, 32764, },
+ { HI6220_CLK_TCXO, clk_tcxo, NULL, CLK_IS_ROOT, 1920, },
+ { HI6220_MMC1_PAD, mmc1_pad, NULL, CLK_IS_ROOT, 1, },
+ { HI6220_MMC2_PAD, mmc2_pad, NULL, CLK_IS_ROOT, 1, },
+ { HI6220_MMC0_PAD, mmc0_pad, NULL, CLK_IS_ROOT, 2, },
+ { HI6220_PLL_BBP, bbppll0, NULL, CLK_IS_ROOT, 24576, },
+ { HI6220_PLL_GPU, gpupll, NULL, CLK_IS_ROOT, 10,},
+ { HI6220_PLL1_DDR, ddrpll1, NULL, CLK_IS_ROOT, 106600,},
+ {
[PATCH v2 1/1] ata: ahci_xgene: Add AHCI Support for second generation of APM X-Gene SoC
This patch enables full AHCI feature support for APM X-Gene SoC SATA host host
controller. The following errata's are removed:
1. 2a0bdff6b95 (ahci-xgene: fix the dma state machine lockup for the
IDENTIFY DEVICE PIO mode command)
2. 09c32aaa368 (ahci_xgene: Fix the dma state machine lockup for the
ATA_CMD_SMART PIO mode command)
3. 1540035da71 (ahci_xgene: Implement the xgene_ahci_poll_reg_val to
support PMP)
4. a3a84bc7c88 (ahci_xgene: Implement the workaround to support PMP
enumeration and discovery)
5. 1102407bb71 (ahci_xgene: Fix the DMA state machine lockup for the
ATA_CMD_PACKET PIO mode command)
6. 72f79f9e35b (ahci_xgene: Removing NCQ support from the APM X-Gene SoC
AHCI SATA Host Controller driver)
In addition, enable PMP support for APM X-Gene SoC and enable FBS support
for second generation APM X-Gene SoC.
---
drivers/ata/ahci_xgene.c | 96 +++-
1 file changed, 78 insertions(+), 18 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 2b78510..7320da3 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -27,6 +27,7 @@
#include linux/platform_device.h
#include linux/ahci_platform.h
#include linux/of_address.h
+#include linux/of_device.h
#include linux/of_irq.h
#include linux/phy/phy.h
#include ahci.h
@@ -84,6 +85,11 @@
/* Max retry for link down */
#define MAX_LINK_DOWN_RETRY 3
+enum xgene_ahci_version {
+ XGENE_AHCI_V1 = 1,
+ XGENE_AHCI_V2,
+};
+
struct xgene_ahci_context {
struct ahci_host_priv *hpriv;
struct device *dev;
@@ -547,9 +553,6 @@ static struct ata_port_operations xgene_ahci_ops = {
.host_stop = xgene_ahci_host_stop,
.hardreset = xgene_ahci_hardreset,
.read_id = xgene_ahci_read_id,
- .qc_issue = xgene_ahci_qc_issue,
- .softreset = xgene_ahci_softreset,
- .pmp_softreset = xgene_ahci_pmp_softreset
};
static const struct ata_port_info xgene_ahci_port_info = {
@@ -629,12 +632,30 @@ static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT(DRV_NAME),
};
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_ahci_acpi_match[] = {
+ { APMC0D0D, XGENE_AHCI_V1},
+ { APMC0D32, XGENE_AHCI_V2},
+ {},
+};
+MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
+#endif
+
+static const struct of_device_id xgene_ahci_of_match[] = {
+ {.compatible = apm,xgene-ahci, .data = (void *) XGENE_AHCI_V1},
+ {.compatible = apm,xgene-ahci-v2, .data = (void *) XGENE_AHCI_V2},
+ {},
+};
+MODULE_DEVICE_TABLE(of, xgene_ahci_of_match);
+
static int xgene_ahci_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
struct ahci_host_priv *hpriv;
struct xgene_ahci_context *ctx;
struct resource *res;
+ const struct of_device_id *of_devid;
+ enum xgene_ahci_version version;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -677,6 +698,49 @@ static int xgene_ahci_probe(struct platform_device *pdev)
ctx-csr_mux = csr;
}
+ of_devid = of_match_device(xgene_ahci_of_match, dev);
+ if (of_devid) {
+ if (of_devid-data) {
+ version = (enum xgene_ahci_version) of_devid-data;
+ } else {
+ dev_warn(pdev-dev, No device data found. Assume
version1\n);
+ version = XGENE_AHCI_V1;
+ }
+ }
+#ifdef CONFIG_ACPI
+ else if (!of_devid) {
+ const struct acpi_device_id *acpi_id;
+ struct acpi_device_info *info;
+ acpi_status status;
+
+ acpi_id = acpi_match_device(xgene_ahci_acpi_match, pdev-dev);
+ if (!acpi_id) {
+ dev_warn(pdev-dev, No node entry in ACPI table.
Assume version1\n);
+ version = XGENE_AHCI_V1;
+ }
+
+ if (acpi_id-driver_data) {
+ version = (enum xgene_ahci_version)
acpi_id-driver_data;
+ status = acpi_get_object_info(ACPI_HANDLE(pdev-dev),
info);
+ if (ACPI_FAILURE(status)) {
+ dev_err(pdev-dev, %s: Error reading device
info\n,
+ __func__);
+ return -EINVAL;
+ }
+ if (info-valid ACPI_VALID_CID)
+ version = XGENE_AHCI_V2;
+
+ } else {
+ dev_warn(pdev-dev, No device data found. Assume
version1\n);
+ version = XGENE_AHCI_V1;
+ }
+ }
+#endif
+ else {
+ dev_err(pdev-dev, No node entry in DTS\n);
+ return -ENODEV;
+ }
+
dev_dbg(dev, VAddr 0x%p Mmio VAddr 0x%p\n,
Re: [PATCHv7] media: i2c/adp1653: fix includes
Hello Pali, On Thu, Apr 9, 2015 at 2:59 PM, Pali Rohár pali.ro...@gmail.com wrote: On Thursday 09 April 2015 14:43:59 Javier Martinez Canillas wrote: Please re-spin your previous patch and submit it properly. Best regards, Javier Hi all! What about stopping this meaningless discussion about resending full patch series when everybody know how to fix is quickly in editor (e.g with sed under 5s) and not wasting another 10 minutes to generate new unified diff sent via SMTP protocol? No, there is a reason why we have written rules on how patches should be submitted. Everyone in the kernel community is expected to optimize their workflow according to these rules to make life easier for people reviewing and merging the patches. As you said now someone has to fix this using an editor and that is an error prone process. Besides, why it would take 10 minutes to generate a proper patch-set? git is very good on this regard (i.e: git commit ---fixup git rebase -i git format-patch git send-email). I won't argue anymore but I find very sad that people who have been in the kernel community for years don't follow the basic rules we have documented it. So I wonder why we have the documentation in the first place and how can we expect newcomers to follow if even experienced kernel hackers don't. -- Pali Rohár pali.ro...@gmail.com Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/6] clk: hi6220: Document devicetree bindings for hi6220 clock
Document DT files bindings for Hisilicon hi6220 clock.
Signed-off-by: Bintian Wang bintian.w...@huawei.com
Reviewed-by: Haojian Zhuang haojian.zhu...@linaro.org
---
.../devicetree/bindings/clock/hi6220-clock.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/hi6220-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/hi6220-clock.txt
b/Documentation/devicetree/bindings/clock/hi6220-clock.txt
new file mode 100644
index 000..83cc7c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi6220-clock.txt
@@ -0,0 +1,34 @@
+* Hisilicon Hi6220 Clock Controller
+
+Clock control registers reside in different Hi6220 system controllers,
+please refer the following document to know more about the binding rules
+for these system controllers:
+
+Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+
+Required Properties:
+
+- compatible: the compatible should be one of the following strings to
+ indicate the clock controller functionality.
+
+ - hisilicon,aoctrl
+ - hisilicon,sysctrl
+ - hisilicon,mediactrl
+ - hisilicon,pmctrl
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+For example:
+ sys_ctrl: sys_ctrl {
+ compatible = hisilicon,sysctrl, syscon;
+ reg = 0x0 0xf703 0x0 0x2000;
+ #clock-cells = 1;
+ };
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in dt-bindings/clock/hi6220-clock.h.
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/1] ata: ahci_xgene: Enable native NCQ and FBS for second generation of X-Gene SoC.
V2 change: * Drop the MIDR based implementation as it is wrong. Signed-off-by: Suman Tripathi stripa...@apm.com --- Suman Tripathi (1): ata: ahci_xgene: Add AHCI Support for second generation of APM X-Gene SoC drivers/ata/ahci_xgene.c | 96 +++- 1 file changed, 78 insertions(+), 18 deletions(-) -- 1.8.2.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
[RESEND] [PATCH 1/1] ARM: dts: Add LEDs on odroid XU3 board
This patch adds the RGB-LED on XU3 as 3 gpio-leds.
It is derived from hardkernel's 3.10 tree.
Tested-by: Anand Moon linux.am...@gmail.com
Signed-off-by: Markus Reichl m.rei...@fivetechno.de
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index a519c86..0a32302 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -278,6 +278,30 @@
rtc@101E {
status = okay;
};
+
+ leds {
+ compatible = gpio-leds;
+ heartbeat {
+ label = blue:heartbeart;
+ gpios = gpb2 2 0;
+ default-state = off;
+ linux,default-trigger = heartbeat;
+ };
+
+ eMMC {
+ label = green:eMMC;
+ gpios = gpb2 1 0;
+ default-state = off;
+ linux,default-trigger = mmc0;
+ };
+
+ microSD {
+ label = red:microSD;
+ gpios = gpx2 3 0;
+ default-state = off;
+ linux,default-trigger = mmc1;
+ };
+ };
};
hdmi {
--
1.9.1
--
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
[PATCH v2 5/6] arm64: Kconfig: Add clock support to ARCH_HISI
Select hi6220 clock driver for ARCH_HISI. Signed-off-by: Bintian Wang bintian.w...@huawei.com --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 64d4d6d..75c55fe 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -230,6 +230,7 @@ config ARCH_XGENE config ARCH_HISI bool Hisilicon SoC Family + select COMMON_CLK_HI6220 help This enables support for Hisilicon ARMv8 SoC family -- 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 v2 2/6] arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC
This patch adds documentation for the devicetree bindings used by the
DT files of Hisilicon hi6220 SoC mobile platform.
Signed-off-by: Bintian Wang bintian.w...@huawei.com
---
.../bindings/arm/hisilicon/hisilicon.txt | 73 ++
1 file changed, 73 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 35b1bd4..66ad65d 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -13,6 +13,9 @@ HiP01 ca9x2 Board
Required root node properties:
- compatible = hisilicon,hip01-ca9x2;
+HiKey Board
+Required root node properties:
+ - compatible = hisilicon,hi6220-hikey;
Hisilicon system controller
@@ -29,6 +32,10 @@ Optional properties:
- resume-offset : offset in sysctrl for notifying cpu0 when resume
- reboot-offset : offset in sysctrl for system reboot
+For some SoCs(e.g. Hi6220), many clock registers are defined under this
+controller, so #clock-cells is a required property for these SoCs and
+it should be set to 1.
+
Example:
/* for Hi3620 */
@@ -40,6 +47,72 @@ Example:
reboot-offset = 0x4;
};
+
+Hisilicon Power Always ON domain controller
+
+Hisilicon designs this system controller to control the power always
+on domain for mobile platform.
+
+Required properties:
+- compatible : hisilicon,aoctrl
+- reg : Register address and size
+
+For some SoCs(e.g. Hi6220), many clock registers are defined under this
+controller, so #clock-cells is a required property for these SoCs and
+it should be set to 1.
+
+Example:
+ /*for Hi6220*/
+ ao_ctrl: ao_ctrl {
+ compatible = hisilicon,aoctrl, syscon;
+ reg = 0x0 0xf780 0x0 0x2000;
+ #clock-cells = 1;
+ };
+
+
+Hisilicon Media domain controller
+
+Hisilicon designs this system controller to control the multimedia
+domain(e.g. codec, G3D ...) for mobile platform.
+
+Required properties:
+- compatible : hisilicon,mediactrl
+- reg : Register address and size
+
+For some SoCs(e.g. Hi6220), many clock registers are defined under this
+controller, so #clock-cells is a required property for these SoCs and
+it should be set to 1.
+
+Example:
+ /*for Hi6220*/
+ media_ctrl: media_ctrl {
+ compatible = hisilicon,mediactrl, syscon;
+ reg = 0x0 0xf441 0x0 0x1000;
+ #clock-cells = 1;
+ };
+
+
+Hisilicon Power Management domain controller
+
+Hisilicon designs this system controller to control the power management
+domain for mobile platform.
+
+Required properties:
+- compatible : hisilicon,pmctrl
+- reg : Register address and size
+
+For some SoCs (e.g. Hi6220), many clock registers are defined under this
+controller, so #clock-cells is a required property for these SoCs and
+it should be set to 1.
+
+Example:
+ /*for Hi6220*/
+ pm_ctrl: pm_ctrl {
+ compatible = hisilicon,pmctrl, syscon;
+ reg = 0x0 0xf7032000 0x0 0x1000;
+ #clock-cells = 1;
+ };
+
---
Hisilicon HiP01 system controller
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: chipidea: Use extcon framework for VBUS and ID detection
On Apr 13, 2015, at 6:53 AM, Peter Chen peter.c...@freescale.com wrote:
On Thu, Apr 09, 2015 at 11:33:38AM +0300, Ivan T. Ivanov wrote:
On recent Qualcomm platforms VBUS and ID lines are not routed to
USB PHY LINK controller. Use extcon framework to receive connect
and disconnect ID and VBUS notification.
snip
+Optional properties:
+- extcon: phandles to external connector devices. First phandle
+should point to external connector, which provide USB
+cable events, the second should point to external connector
+device, which provide USB-HOST cable events. If one of
+the external connector devices is not required empty 0
+phandle should be specified.
You mean if id connector is not needed, we write dts like below:
extcon = usb_vbus, 0;
If it is, you may miss ',' between required and empty 0”.
Yes. Will fix it.
u32 hw_read_otgsc(struct ci_hdrc *ci, u32 mask)
{
-return hw_read(ci, OP_OTGSC, mask);
+u32 val = hw_read(ci, OP_OTGSC, mask);
+
+if ((mask OTGSC_BSV) ci-vbus.conn.edev) {
You may use || since you can't get vbus and id value from
cpu register (otgsc).
The idea is to not rely on the register content for these
bits if user have defined these DT bindings.
Will fix rest of the comments and resend.
Thank you,
Ivan--
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] DT: leds: Improve description of flash LEDs related properties
We're missing only a DT maintainer ack now. Could anyone take
a look at this, please?
On 04/10/2015 10:36 AM, Jacek Anaszewski wrote:
1. Since max-microamp property has had no users so far, then rename
it to more descriptive led-max-microamp.
2. Since flash-timeout-us property has had no users so far, then rename
it to more accurate flash-max-timeout-us.
3. Describe led-max-microamp property as mandatory for specific board
configurations.
4. Make flash-max-microamp and flash-max-timeout-us properties mandatory
for devices with configurable flash current and flash timeout settings
respectively.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Pavel Machek pa...@ucw.cz
Cc: Sakari Ailus sakari.ai...@linux.intel.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: devicetree@vger.kernel.org
---
Documentation/devicetree/bindings/leds/common.txt | 27 ++---
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index 747c538..6841984 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -29,14 +29,23 @@ Optional properties for child nodes:
ide-disk - LED indicates disk activity
timer - LED flashes at a fixed, configurable rate
-- max-microamp : maximum intensity in microamperes of the LED
-(torch LED for flash devices)
-- flash-max-microamp : maximum intensity in microamperes of the
- flash LED; it is mandatory if the LED should
- support the flash mode
-- flash-timeout-us : timeout in microseconds after which the flash
- LED is turned off
+- led-max-microamp : Maximum LED supply current in microamperes. This property
+ can be made mandatory for the board configurations
+ introducing a risk of hardware damage in case an excessive
+ current is set.
+ For flash LED controllers with configurable current this
+ property is mandatory for the LEDs in the non-flash modes
+ (e.g. torch or indicator).
+Required properties for flash LED child nodes:
+- flash-max-microamp : Maximum flash LED supply current in microamperes.
+- flash-max-timeout-us : Maximum timeout in microseconds after which the flash
+ LED is turned off.
+
+For controllers that have no configurable current the flash-max-microamp
+property can be omitted.
+For controllers that have no configurable timeout the flash-max-timeout-us
+property can be omitted.
Examples:
@@ -49,7 +58,7 @@ system-status {
camera-flash {
label = Flash;
led-sources = 0, 1;
- max-microamp = 5;
+ led-max-microamp = 5;
flash-max-microamp = 32;
- flash-timeout-us = 50;
+ flash-max-timeout-us = 50;
};
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/6] arm64,hi6220: Enable Hisilicon Hi6220 SoC
Hi6220 is one mobile solution of Hisilicon, this patchset contains initial support for Hi6220 SoC and HiKey development board, which supports octal ARM Cortex A53 cores. Initial support is minimal and includes just the arch configuration, clock driver, device tree configuration. PSCI is enabled in device tree and there is no problem to boot all the octal cores, but the CPU hotplug is still under development, you can download and compile the latest firmware based on the following link to run this patch set: https://github.com/96boards/documentation/wiki/UEFI Changes v2: * Split the DT bindings documents into earlier patches * Change SMP enable method from spin-table to PSCI in device tree * Remove clock-frequency from armv8-timer device node in device tree * Add more description about Hisilicon designed system controllers in DT bindings document * Enable high speed clock on UART1 mux * Other changes based on the discussion in the mailing list: https://lkml.org/lkml/2015/2/5/147 Bintian Wang (6): arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC clk: hi6220: Document devicetree bindings for hi6220 clock clk: hi6220: Clock driver support for Hisilicon hi6220 SoC arm64: Kconfig: Add clock support to ARCH_HISI arm64: dts: Add dts files for Hisilicon Hi6220 SoC .../bindings/arm/hisilicon/hisilicon.txt | 73 ++ .../devicetree/bindings/clock/hi6220-clock.txt | 34 +++ arch/arm64/Kconfig | 6 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/hisilicon/Makefile | 5 + arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 28 ++ arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 171 arch/arm64/configs/defconfig | 1 + drivers/clk/Kconfig| 2 + drivers/clk/Makefile | 4 +- drivers/clk/hisilicon/Kconfig | 5 + drivers/clk/hisilicon/Makefile | 3 +- drivers/clk/hisilicon/clk-hi6220.c | 292 + drivers/clk/hisilicon/clk.c| 29 ++ drivers/clk/hisilicon/clk.h| 17 ++ drivers/clk/hisilicon/clkdivider-hi6220.c | 273 +++ include/dt-bindings/clock/hi6220-clock.h | 173 17 files changed, 1113 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/hi6220-clock.txt create mode 100644 arch/arm64/boot/dts/hisilicon/Makefile create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220.dtsi create mode 100644 drivers/clk/hisilicon/Kconfig create mode 100644 drivers/clk/hisilicon/clk-hi6220.c create mode 100644 drivers/clk/hisilicon/clkdivider-hi6220.c create mode 100644 include/dt-bindings/clock/hi6220-clock.h -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/6] arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig
This patch introduces ARCH_HISI to enable Hisilicon SoC family in Kconfig and defconfig. Signed-off-by: Bintian Wang bintian.w...@huawei.com Reviewed-by: Haojian Zhuang haojian.zhu...@linaro.org Reviewed-by: Wei Xu xuw...@hisilicon.com --- arch/arm64/Kconfig | 5 + arch/arm64/configs/defconfig | 1 + 2 files changed, 6 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 1b8e973..64d4d6d 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -228,6 +228,11 @@ config ARCH_XGENE help This enables support for AppliedMicro X-Gene SOC Family +config ARCH_HISI + bool Hisilicon SoC Family + help + This enables support for Hisilicon ARMv8 SoC family + endmenu menu Bus support diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index be1f12a..36ebd9b 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -36,6 +36,7 @@ CONFIG_ARCH_MEDIATEK=y CONFIG_ARCH_THUNDER=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_XGENE=y +CONFIG_ARCH_HISI=y CONFIG_PCI=y CONFIG_PCI_MSI=y CONFIG_PCI_XGENE=y -- 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: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs
On Fri, Apr 10, 2015 at 02:06:33PM -0500, Kumar Gala wrote: On Apr 10, 2015, at 11:10 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, Apr 10, 2015 at 10:24:46AM -0500, Kumar Gala wrote: On Apr 10, 2015, at 5:05 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Thu, Apr 09, 2015 at 12:37:06PM -0500, Kumar Gala wrote: This patch set adds support for SMP boot on the MSM8x16 family of Qualcomm SoCs. To support SMP on the MSM8x16 SoCs we need to add ARMv8/64-bit SCM interfaces to setup the boot/release addresses for the secondary CPUs. In addition we need a uniquie set of cpu ops. I'm aware the desired methods for booting secondary CPUs is either via spintable or PSCI. However, these SoCs are shipping with a firmware that does not support those methods. And the reason is? Some guesses: a) QC doesn't think boot interface (and cpuidle) standardisation is worth the effort (to put it nicely) b) The hardware was available before we even mentioned PSCI c) PSCI is not suitable for the QC's SCM interface d) Any combination of the above I strongly suspect it's point (a). Should we expect future QC hardware to do the same? You could argue the reason was (b), though we've been discussing PSCI for at least two years and, according to QC press releases, MSM8916 started sampling in 2014. The only valid reason is (c) and if that's the case, I would expect a proposal for a new firmware interface protocol (it could be PSCI-based), well documented, that can be shared with others that may encounter the same shortcomings. Does it matter? I’ve always felt the kernel was a place of inclusion. Qualcomm choose for whatever reason to not use PSCI or spin table. You don’t like it, I might not like it, but it is what it is. Yes, it matters, but only if Qualcomm wants the SoC support in mainline. Just because Qualcomm Inc does not want to invest in implementing a standard firmware interface is not a good enough reason to merge the kernel code. The reason to merge the code upstream it expands functionality for a platform. This alone has never been a good enough reason. Code (both design and style) needs to pass the review. There is nothing that says when someone licenses an ARM core that they must also implement this standard. Just to be perfectly clear: this has nothing to do with ARM Ltd nor the ARM hardware licensing terms. ARM Ltd doesn't even require you to use Linux, that's your choice. But when you make an OS choice, you have to abide by its rules. Qualcomm choose for whatever reasons to not implement it. There are examples on other architectures supporting non-standard platforms all the time (x86 supported Voyager and SGI VIS for a long time). As far as I can tell you are just wanting uniformity to impose this rule. Don't confuse non-standard hardware (which has always been acceptable on ARM) with non-standard ways of entering the kernel from firmware, whether it's a primary or secondary CPU. Just look at how many smp_ops structures are defined on x86. What if Qualcomm decides that it doesn't like DT, nor ACPI but comes up with yet another way to describe hardware because that's what the firmware provides? Should the kernel community take it? You could argue that this is a significant change but it's about the principle. And each SoC with its own non-standard boot protocol for no good reason is significant. I wouldn’t argue that because we are talking about something that has an extremely small impact on the maintainability or changes to how the kernel actually functions. It's not about one particular case but about where to draw the line. Just multiply this change by the number of SoC variants and you'll no longer see this as extremely small impact. Why would we accept it for Qualcomm and reject it for others? It's either giving up trying to standardise this altogether or enforcing rules. Since you only care about Qualcomm hardware, you don't care about the overall picture. By your reasoning, Qualcomm may solely decide to change the booting for the primary CPU as well, ignore single Image requirements (well, why would Qualcomm care about other SoCs) and so on. The kernel community should just accept such changes without questioning because they expand platform functionality. I am not asking for *hardware* standardisation here, but common software interfaces. Also, if Qualcomm did come up with some other means to replace DT or ACPI and felt it was worth trying to get accepted upstream, I would hope the upstream would look at it before just saying it was not using some standard. We would still expect proper technical arguments. That's exactly what I'm asking here; is PSCI not suitable for Qualcomm? If not, can it be improved? If you have completely different needs, can you come up with a standard firmware interface, which may only be used by Qualcomm for the time
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
Hi Jason, Boris, On 11/04/2015 00:30, Jason Cooper wrote: Hey Boris, On Fri, Apr 10, 2015 at 05:11:48PM +0200, Boris Brezillon wrote: On Fri, 10 Apr 2015 13:50:56 + Jason Cooper ja...@lakedaemon.net wrote: On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote: I know we usually try to adapt existing drivers instead of replacing them by new ones, but after trying to refactor the mv_cesa driver I realized it would take longer than writing an new one from scratch. I'm sorry, but this makes me *very* uncomfortable. Any organization worth it's salt will do a very careful audit of code touching cryptographic material and sensitive (decrypted) data. From that point on, small audits of the changes to the code allow the organization to build a comfort level with kernel updates. iow, following the git history of the driver. By apply this series, we are basically forcing those organizations to either a) stop updating, or b) expend significant resources to do another full audit. In short, this series breaks the audit chain for the mv_cesa driver. Maybe I'm the only person with this level of paranoia. If so, I'm sure others will override me. From my POV, it looks like the *only* reason we've chosen this route is developer convenience. I don't think that's sufficient reason to break the change history of a driver handling sensitive data. Well, I understand you concern, but if you read carefully the old and new drivers, you'll notice that they are completely different (the only thing I kept are the macro definitions). Yes, that's the worrying part for me. ;-) I understand the logic behind your concern, but I wonder if it is really an issue. My knowledge ans my background around crypto is very limited, so I really would like the opinion of other people on the subject. I really tried to adapt the existing driver to add the missing features (especially the support for TDMA), but all my attempts ended up introducing hackish code (not even talking about the performance penalty of this approach). Ok, fair enough. It would be helpful if this account of attempting to reconcile the old driver made it into the commit message. This puts us in perfect is the enemy of getting it done territory. I have another solution though: keep the existing driver for old marvell SoCs (orion, kirkwood and dove), and add a new one for modern SoCs (armada 370, XP, 375 and 38x), so that users of the mv_cesa driver won't have to audit the new code. A fair proposal, but I'll freely admit the number of people actually auditing their code paths is orders of magnitude smaller than the number of users of the driver. There's such a large population of compatible legacy SoCs in the wild, adding an artificial boundary doesn't make sense. Especially since we're talking about features everyone would want to use. Perhaps we should keep both around, and deprecate the legacy driver over 3 to 4 cycles? But I guess that some users will want to use the new driver on the old marvell SoCs (especially kirkwood and dove). If we go to this path, then the best solution would be to still update all the the dts, and modifying the old driver to be able to use the new binding: for my point of view the only adaptation should be related to the SRAM. It will be also needed to find a way to be able to load only one driver at a time: either the old or the new, but not both. However I still wonder if it worth the effort. Thanks, Gregory thx, Jason. -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex
On Mon, Apr 6, 2015 at 10:04 PM, Ohad Ben-Cohen o...@wizery.com wrote: Mark, are you OK with the latest iteration from Suman? it would be nice to get your +1 just to make sure we don't merge stuff you're uncomfortable with. Quick update: As Tim pointed out, we can move forward with the driver binding patch according to the process described under II.2 of [1]. Both Bjorn and myself would still prefer to make sure Mark is satisfied with the response Bjorn sent to Mark's question, but we understand if Mark is swamped and we eventually would proceed according to the DT's submitting-patches guidance below. Tim, thanks for pointing that out as I wasn't aware of this. What we probably do need a DT ack on is the hwspinlock subsystem binding submitted by Suman, again according to the process described under II.2 of [1]: Subsystem bindings (anything affecting more than a single device): then getting a devicetree maintainer to review it is required. Mark and Rob: thanks so much for all your help so far as you have substantially helped shaping the hwspinlock binding. Please let us know if you are satisfied with Suman's latest iteration, still prefer to take another look at it, or are too swamped. If the latter, then maybe we can ask Kumar to take a look, as this seems to be blocking Qualcomm's upstream roadmap. Thanks, Ohad. [1] Documentation/devicetree/bindings/submitting-patches.txt -- 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] gpio: add driver to export DT configured GPIOs to userspace
Selected GPIOs (defined as child nodes in DT) may be exported as
symlinks to user space (using gpiod_export_link())
The advantages of this are:
* Userspace no longer needs to know the GPIO number (which may
vary with other hardware and with kernel version due to dynamic
allocation)
* Userspace can be prevented from changing the direction if that
does not make sense from a hardware perspective.
Signed-off-by: Martin Fuzzey mfuz...@parkeon.com
---
drivers/gpio/Kconfig |9 ++
drivers/gpio/Makefile|1
drivers/gpio/gpio-exporter.c | 171 ++
3 files changed, 181 insertions(+)
create mode 100644 drivers/gpio/gpio-exporter.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 633ec21..682fce2 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -110,6 +110,15 @@ config GPIO_DA9055
config GPIO_MAX730X
tristate
+config GPIO_EXPORTER
+ tristate Userspace exporter driver
+ depends on OF_GPIO GPIO_SYSFS
+ help
+ This enables a GPIO consumer which exports some GPIOs to userspace.
+ The GPIOs to be exported are defined in the device tree.
+ The exported GPIOs are represented as symbolic links in sysfs,
+ relieving usespace of the burden of knowing the GPIO number to export
+
comment Memory mapped GPIO drivers:
config GPIO_74XX_MMIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 81755f1..bb665c5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o
obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
# Device drivers. Generally keep list sorted alphabetically
+obj-$(CONFIG_GPIO_EXPORTER)+= gpio-exporter.o
obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o
obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
diff --git a/drivers/gpio/gpio-exporter.c b/drivers/gpio/gpio-exporter.c
new file mode 100644
index 000..72cdcf0
--- /dev/null
+++ b/drivers/gpio/gpio-exporter.c
@@ -0,0 +1,171 @@
+/*
+ * A driver that allows some gpios to be exported to userspace
+ * using friendly names.
+ *
+ * This allows the gpios to be exported to be configured in the device tree
+ * and frees userspace from having to know unstable gpio numbers.
+ *
+ * Copyright 2015 Parkeon
+ *
+ * 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.
+ *
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/gpio/consumer.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/platform_device.h
+
+
+struct gpio_exporter_gpio {
+ const char *name;
+ struct gpio_desc *desc;
+};
+
+struct gpio_exporter_data {
+ struct device *dev;
+ int num_gpios;
+ struct gpio_exporter_gpio *gpios;
+};
+
+static int gpio_exporter_do_one(struct gpio_exporter_data *data,
+ struct fwnode_handle *child)
+{
+ struct device_node *np = of_node(child);
+ const char *name = np-name;
+ const char *config;
+ struct gpio_desc *desc;
+ int ret;
+
+ desc = devm_get_gpiod_from_child(data-dev, child);
+ if (IS_ERR(desc)) {
+ ret = PTR_ERR(desc);
+ goto failed_get;
+ }
+
+ if (of_property_read_bool(np, output)) {
+ u32 state = 0;
+
+ of_property_read_u32(np, initial-state, state);
+ ret = gpiod_direction_output(desc, state);
+ } else {
+ ret = gpiod_direction_input(desc);
+ }
+ if (ret)
+ goto failed_setdir;
+
+ ret = gpiod_export(desc,
+ of_property_read_bool(np, allow-direction-change));
+ if (ret)
+ goto failed_export;
+
+ ret = gpiod_export_link(data-dev, name, desc);
+ if (ret)
+ goto failed_link;
+
+ data-gpios[data-num_gpios].name = name;
+ data-gpios[data-num_gpios].desc = desc;
+ data-num_gpios++;
+
+ dev_info(data-dev,
+ Exported gpio%d as '%s'\n, desc_to_gpio(desc), name);
+
+ return 0;
+
+failed_link:
+ gpiod_unexport(desc);
+
+failed_export:
+failed_setdir:
+failed_get:
+ dev_err(data-dev, Failed to export gpio '%s': %d\n, name, ret);
+
+ return ret;
+}
+
+static void gpio_exporter_cleanup(struct gpio_exporter_data *data)
+{
+ int i;
+
+ for (i = 0; i data-num_gpios; i++) {
+ sysfs_remove_link(data-dev-kobj, data-gpios[i].name);
+ gpiod_unexport(data-gpios[i].desc);
+ }
+}
+
+static int gpio_exporter_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct fwnode_handle *child;
+ int num_gpios;
+ int ret;
+ struct
Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver
On Tue, Mar 31, 2015 at 09:27:53AM -0700, Kevin Hilman wrote:
Hi Sascha,
Sascha Hauer s.ha...@pengutronix.de writes:
This adds a power domain driver for the Mediatek SCPSYS unit.
The System Control Processor System (SCPSYS) has several power
management related tasks in the system. The tasks include thermal
measurement, dynamic voltage frequency scaling (DVFS), interrupt
filter and lowlevel sleep control. The System Power Manager (SPM)
inside the SCPSYS is for the MTCMOS power domain control.
For now this driver only adds power domain support, the more
advanced features are not yet supported. The driver implements
the generic PM domain device tree bindings, the first user will
most likely be the Mediatek AFE audio driver.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Sorry for the lag, was travelling last week at ELC and not keeping up
with reviews.
This version looks pretty good to me, but had one minor
comment/question...
[...]
+#define NUM_DOMAINSARRAY_SIZE(scp_domain_data)
+
+struct scp;
+
+struct scp_domain {
+ struct generic_pm_domain pmd;
+ struct scp_domain_data *data;
+ struct scp *scp;
+};
+
+struct scp {
+ struct scp_domain domains[NUM_DOMAINS];
+ struct generic_pm_domain *pmd[NUM_DOMAINS];
Why is this genpd pointer needed? It's just a pointer to the
.domains.pmd[i] anyways, and IMO makes the code a bit hard to follow.
The driver itself does not need the genpd pointer, but
of_genpd_add_provider_onecell() expects an array of pointers to struct
generic_pm_domain.
I can allocate the array of pointers separately and remove the pmd field
from struct scp to make this a bit more clearer.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
On Mon, 2015-04-13 at 17:17 +0800, Bintian Wang wrote:
--- /dev/null
+++ b/drivers/clk/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+config COMMON_CLK_HI6220
+ tristate Hi6220 Clock Driver
+ depends on OF ARCH_HISI
+ help
+ Build the Hisilicon Hi6220 clock driver based on the common clock
framework.
In 5/6 you make arm64's ARCH_HISI (a bool) select COMMON_CLK_HI6220. So
for arm64 this driver will always be built-in.
For arm's ARCH_HISI it's possible to set COMMON_CLK_HI6220 to 'm'.
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -2,8 +2,9 @@
# Hisilicon Clock specific Makefile
#
-obj-y+= clk.o clkgate-separated.o
+obj-y+= clk.o clkgate-separated.o clkdivider-hi6220.o
These objects will always be built-in, right?
obj-$(CONFIG_ARCH_HI3xxx)+= clk-hi3620.o
obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o
obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
+obj-$(CONFIG_COMMON_CLK_HI6220) += clk-hi6220.o
If CONFIG_COMMON_CLK_HI6220 is 'm' this will build a module named
clk-hi6220.ko. If I try to do that I get:
$ make -C ../../.. ARCH=arm CROSS_COMPILE=arm-linux-gnu- M=$PWD
clk-hi6220.ko
make: Entering directory `[...]'
CC [M] [...]/drivers/clk/hisilicon/clk-hi6220.o
MODPOST 1 modules
WARNING: hisi_clk_register_gate
[[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined!
WARNING: hi6220_clk_register_divider
[[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined!
WARNING: hisi_clk_register_mux
[[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined!
WARNING: hisi_clk_register_gate_sep
[[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined!
WARNING: hisi_clk_register_fixed_factor
[[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined!
WARNING: hisi_clk_register_fixed_rate
[[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined!
WARNING: hisi_clk_init [[...]/drivers/clk/hisilicon/clk-hi6220.ko]
undefined!
CC [...]/drivers/clk/hisilicon/clk-hi6220.mod.o
LDFINAL [M] [...]/drivers/clk/hisilicon/clk-hi6220.ko
make: Leaving directory `[...]'
That is, I think, because nothing exports these symbols.
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi6220.c
@@ -0,0 +1,292 @@
+/*
+ * Hisilicon Hi6220 clock driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Bintian Wang bintian.w...@huawei.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/slab.h
+#include linux/clk.h
+
+#include dt-bindings/clock/hi6220-clock.h
+
+#include clk.h
+
+
+/* clocks in AO (always on) controller */
+static struct hisi_fixed_rate_clock hi6220_fixed_rate_clks[] __initdata = {
+ { HI6220_REF32K,ref32k, NULL, CLK_IS_ROOT, 32764, },
+ { HI6220_CLK_TCXO, clk_tcxo, NULL, CLK_IS_ROOT, 1920, },
+ { HI6220_MMC1_PAD, mmc1_pad, NULL, CLK_IS_ROOT, 1, },
+ { HI6220_MMC2_PAD, mmc2_pad, NULL, CLK_IS_ROOT, 1, },
+ { HI6220_MMC0_PAD, mmc0_pad, NULL, CLK_IS_ROOT, 2, },
+ { HI6220_PLL_BBP, bbppll0, NULL, CLK_IS_ROOT, 24576, },
+ { HI6220_PLL_GPU, gpupll, NULL, CLK_IS_ROOT, 10,},
+ { HI6220_PLL1_DDR, ddrpll1, NULL, CLK_IS_ROOT, 106600,},
+ { HI6220_PLL_SYS, syspll, NULL, CLK_IS_ROOT, 12,},
+ { HI6220_PLL_SYS_MEDIA, media_syspll, NULL, CLK_IS_ROOT, 12,},
+ { HI6220_DDR_SRC, ddr_sel_src, NULL, CLK_IS_ROOT, 12,},
+ { HI6220_PLL_MEDIA, media_pll,NULL, CLK_IS_ROOT, 144000,},
+ { HI6220_PLL_DDR, ddrpll0, NULL, CLK_IS_ROOT, 16,},
+};
+
+static struct hisi_fixed_factor_clock hi6220_fixed_factor_clks[] __initdata
= {
+ { HI6220_300M, clk_300m,syspll, 1, 4, 0, },
+ { HI6220_150M, clk_150m,clk_300m,1, 2, 0, },
+ { HI6220_PICOPHY_SRC, picophy_src, clk_150m,1, 4, 0, },
+ { HI6220_MMC0_SRC_SEL, mmc0srcsel, mmc0_sel,1, 8, 0, },
+ { HI6220_MMC1_SRC_SEL, mmc1srcsel, mmc1_sel,1, 8, 0, },
+ { HI6220_MMC2_SRC_SEL, mmc2srcsel, mmc2_sel,1, 8, 0, },
+ { HI6220_VPU_CODEC,vpucodec,codec_jpeg_aclk, 1, 2, 0, },
+ { HI6220_MMC0_SMP, mmc0_sample, mmc0_sel,1, 8, 0, },
+ { HI6220_MMC1_SMP, mmc1_sample, mmc1_sel,1, 8, 0, },
+ { HI6220_MMC2_SMP, mmc2_sample, mmc2_sel,1, 8, 0, },
+};
+
+static struct hisi_gate_clock hi6220_separated_gate_clks_ao[] __initdata = {
+ { HI6220_WDT0_PCLK, wdt0_pclk, clk_tcxo,
Re: [PATCH v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark,
On 04/13/2015 07:56 PM, Mark Rutland wrote:
Hi Chanwoo,
Could you please reply to the below?
Without an answer I'm going to have to ask for the patch to be unqueued
for the moment, and I'd prefer that we came to a solution instead.
I'm sorry about late reply.
Thanks,
Mark.
On Tue, Apr 07, 2015 at 11:25:27AM +0100, Mark Rutland wrote:
I'm very worried about adding a DT that's known broken, especially when
we have no idea as to if/when the FW will be fixed judging from prior
replies.
As I replied, I can not fix the FW because I don't have any code of FW.
Surely you are able to contact those who do?
I don't have any solution to fix it on Linux kernel level.
So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
I disagree. I do not want to add a DT that is known to be broken;
especially when we have no idea how to fix it. It creates long-term
maintenance pain for everyone, and marginal gain for few. A comment does
nothing to aid the end-user.
So NAK to the PSCI node and PSCI enable method in this dts until we
either have a working firmware, or a reasonable mechanism to handle the
deficiency.
There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.
I understand that, but the issue with CPU0 is still a blocker from my
PoV.
To fix this issue, we must need the help of firmware developer.
But, We never get the any help.
Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?
I didn't ask any help to firmware engineer because I didn't know who firmware
engineer
and also didn't access the source code. If I knew the engineer and can access
them,
I would have asked some help to them or inquired the reason about CPU0 not
hotplugged.
Also, as I mentioned on previous mail, all Exynos SoCs can not turn
off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.
While that may be the case, PSCI is a more generic standard, and it is
used on systems where CPU0 can be hot unplugged. So Exynos-specific
details cannot dictate how the kernel PSCI driver should behave.
Is there a particular reason that CPU0 cannot be hotplugged?
Unfortunately, I don't know correctly why Exynos SoC cannot hotplug the CPU0.
But, IMHO, SoC had to maintain at least online core for operation.
Just Exynos SoC has remained the CPU0 as at least online core.
In PSCI 0.2 and later it's possible to determine whether a trusted OS
prohibits a core from being hotplugged, but this mechanism doesn't exist
in earlier versions. I am not averse to adding a property to PSCI 0.1
to mark a CPU as not being hotpluggable if there is a fundamental reason
(i.e. not simply a bug) for this being the case.
Thanks,
Chanwoo Choi
--
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/7] ARM: dts: Refactor Exynos5 boards for phandle notation
2015-04-13 5:07 GMT+09:00 Arnd Bergmann a...@arndb.de:
On Sunday 12 April 2015 21:24:47 Krzysztof Kozlowski wrote:
The phandle notation reduces possible mistakes when overriding nodes
by child board files and reduces duplication of addresses.
The patchset refactors Exynos5 boards to use the phandle way.
Tested by comparison of decompiled DTB for each commit.
The patches look fine, but the description is wrong as you are not
using 'phandles' here, you are using 'labels'.
Heh, I suspected this but some docs I found referred to label { ...
} also as a phandle. Thanks for pointing this out. I'll respin.
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] [RFC] OF: probe order dependency aware of_platform_populate
Hi Rob,
On Wed, Apr 8, 2015 at 3:40 PM, Rob Herring robherri...@gmail.com wrote:
On Wed, Apr 8, 2015 at 3:42 AM, Geert Uytterhoeven ge...@linux-m68k.org
wrote:
On Thu, Apr 2, 2015 at 4:38 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Mon, 30 Mar 2015 15:27:27 +0200
, Geert Uytterhoeven ge...@linux-m68k.org
wrote:
On Tue, Mar 24, 2015 at 6:56 PM, Pantelis Antoniou
pantelis.anton...@konsulko.com wrote:
On Mar 24, 2015, at 07:50 , Geert Uytterhoeven ge...@linux-m68k.org
wrote:
IIUC, this would fix the issue I worked around in ARM: shmobile:
r8a73a4:
Move pfc node to work around probe ordering bug?
https://git.kernel.org/cgit/linux/kernel/git/horms/renesas.git/commit/?h=r8a73a4-ccf-and-multiplatform-for-v4.1id=e4ba0a9bddff3ba52cec100414d2f178440efc91
There are two ways to fix this so that .dtb order doesn't matter. The
dirty hack is to change the pfc driver to use subsys_initcall (level 4)
or later so that it happens after the devices are registered. The second
I've just tried that, and it doesn't work.
solution is to make the pfc drivers able to return -EPROBE_DEFER, but
that also requires fixing deferred probe to start retrying devices
before late_initcall time. Right now there is a holdoff flag that
All the pfc driver can detect is that some platform_device.resource[i] are
empty (resource_type zero). Returning -EPROBE_DEFER won't help,
as the resource won't change later.
The problem is not the initialization order of the device drivers, but the
creation order of the platform devices.
of_device_alloc() silently (except for the pr_debug() message) ignores
any failures to setup IRQ resources. Hence platform devices for interrupt
providers must be created before platform devices for interrupt consumers,
which is what the reordering in DT fixes.
This doesn't sound right. It ignores failures because platform_get_irq
will parse the interrupts when called rather than just using the
resource struct and will return EPROBE_DEFER if the irq resource is
not ready. We left the of_device_alloc code in to be safe, but we
should be able to remove it.
Thanks, using platform_get_irq() (and propagating EPROBE_DEFER) instead of
accessing the platform_device's resources directly indeed does work, but will
require some rework in the sh-pfc driver.
One more thing to consider for a porting your driver to DT tutorial ;-)
One side effect is that almost all drivers now end up being probe-deferred, as
the pinctrl configuration can't be done until the pfc driver is active.
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 v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Chanwoo,
Could you please reply to the below?
Without an answer I'm going to have to ask for the patch to be unqueued
for the moment, and I'd prefer that we came to a solution instead.
Thanks,
Mark.
On Tue, Apr 07, 2015 at 11:25:27AM +0100, Mark Rutland wrote:
I'm very worried about adding a DT that's known broken, especially when
we have no idea as to if/when the FW will be fixed judging from prior
replies.
As I replied, I can not fix the FW because I don't have any code of FW.
Surely you are able to contact those who do?
I don't have any solution to fix it on Linux kernel level.
So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
I disagree. I do not want to add a DT that is known to be broken;
especially when we have no idea how to fix it. It creates long-term
maintenance pain for everyone, and marginal gain for few. A comment does
nothing to aid the end-user.
So NAK to the PSCI node and PSCI enable method in this dts until we
either have a working firmware, or a reasonable mechanism to handle the
deficiency.
There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.
I understand that, but the issue with CPU0 is still a blocker from my
PoV.
To fix this issue, we must need the help of firmware developer.
But, We never get the any help.
Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?
Also, as I mentioned on previous mail, all Exynos SoCs can not turn
off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.
While that may be the case, PSCI is a more generic standard, and it is
used on systems where CPU0 can be hot unplugged. So Exynos-specific
details cannot dictate how the kernel PSCI driver should behave.
Is there a particular reason that CPU0 cannot be hotplugged?
In PSCI 0.2 and later it's possible to determine whether a trusted OS
prohibits a core from being hotplugged, but this mechanism doesn't exist
in earlier versions. I am not averse to adding a property to PSCI 0.1
to mark a CPU as not being hotpluggable if there is a fundamental reason
(i.e. not simply a bug) for this being the case.
Thanks,
Mark.
--
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
--
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/2] gpio: Allow userspace export from DT
Currently the gpio sysfs interface allows userspace to access simple hardware where no kernel driver exists or would be useful. However it requires userspace to know the gpio number that has been assigned by the kernel. That number, in the case of gpio drviers using dynamic allocation, is not fixed, and may change when: * The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17) * The kernel version changes and probe order changes for gpio chips. * The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used * The board is redesigned (eg switching an externally visible signal from a SoC provided GPIO to an I2C expander chip or vice versa). * Other GPIO chips are added to the system. The above means that, in order to export the GPIO to userspace via /sys/class/gpio/export the userspace code must know the exact hardware and kernel version information. Furthermore, in many cases, it makes no sense to allow userspace to change the signal direction; even if the GPIO itself allows it the circuitry connected to the pin often does not (eg a signal dedicated to an output function driving a transistor). This patch series solves both problems by performing the external signal = GPIO mapping in the device tree. -- 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/2] Doc: DT: Add binding document for GPIO exporter
Signed-off-by: Martin Fuzzey mfuz...@parkeon.com
---
.../devicetree/bindings/gpio/gpio-exporter.txt | 40
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-exporter.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-exporter.txt
b/Documentation/devicetree/bindings/gpio/gpio-exporter.txt
new file mode 100644
index 000..58fc2a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-exporter.txt
@@ -0,0 +1,40 @@
+Bindings to export some GPIOs to userspace.
+
+This is useful when some signals are made externally available by a piece
+of hardware (eg terminal blocks to connect sensors, actuators) but no
+special purpose kernel driver exists.
+
+Use of this binding allows userspace to have a stable name and input
+/ output mode across hardware and software versions.
+
+Required properties:
+- compatible: linux,gpio-exporter
+
+
+Each GPIO to be exported is represented as a child node with:
+
+Required child properties:
+- gpios : Reference to the GPIO to export (standard gpio binding)
+
+Optional child properties:
+- output : if present GPIO is output, otherwise input
+- initial-state : Initial state (0=low, 1=high) for output
+- allow-direction-change : Present if GPIO direction may be modified
+
+The name of the child node is that exposed to userspace.
+
+Example:
+ gpio_exporter:gpio-exporter {
+ compatible = linux,gpio-exporter;
+
+ terminalblock_1_out1 {
+ gpios = gpio2 12 0;
+ output;
+ initial-state = 0;
+ };
+
+ terminalblock_1_in1 {
+ gpios = gpio2 15 0;
+ };
+
+ };
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: mvebu: Add DLINK-DNS327L support
Hi Andrew, On 11/04/2015 23:28, Andrew Lunn wrote: When power button is pressed to turn the NAS off, weltrend signals the SoC by driving mpp63 line low. Apparently right now pinctrl assumes that this line can only work as 'gpo' that screws up gpio-buttons driver. Since without gpio-buttons, mpp63 works as input properly via sysfs interface, I've added a patch for pinctrl-armada-370.c that fixes the issue. Hi Andrew This is odd. I just checked the Marvell datasheets, and they list this pin a GPO. We probably want Thomas or Gregory to check this with Marvell. I have check on the datasheet I have (in case of it was different of the public one) and for all the variant of the Armada 370: 88F6710, 88F6707, and 88F6W11 the MPP63 is list as GPO. I will ask Marvell to see if it was a typo on their datasheet. Thanks, Gregory Andrew -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Re: [PATCH 2/2] ARM: mvebu: dts: Add dts file for DLink DNS-327L
Hi Andrew(s), On 12/04/2015 21:47, Andrew Lunn wrote: On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote: Andrew Lunn ?? 12.04.2015 17:58: Okay, got it. I'll file a bug about this issue to the the bugzilla. However something tells me it might not be cpuidle, but D-link. This one's sounds nasty and it has been around since 3.16.x. How could it go unnoticed? Unfortunately I have no other armada-370 hardware to test it. Hi Andrew A few of us here do have hardware to test with. Please give a detailed description of how you reproduce the issue, and your kernel configuration, if different from mvebu_v7_defconfig, or multi_v7_defconfig. Thanks Andrew arch/arm/configs/mvebu_v7_defconfig has CONFIG_ARM_MVEBU_V7_CPUIDLE=y, so it should be sufficient to reproduce the issue. I first encountered this issue using that very config and observed it on 2 DNS-327L boxes I own. All I have to do to trigger the bug - enable cpuidle driver and let the box sit for some 4-12 hours, till it hard-freezes. If wdt is enabled - wdt reboot will happen. That simple! Well i've got a 370RD which has been sat mostly idle for weeks, using the mvebu_v7_defconfig, with a few addition things turned on for testing the Ethernet switch on the board. I've not had that lockup. One thing you can try to narrow it down is the disable the second idle mode. Take a look at armada370_idle_driver. Keep the ARM_CPUIDLE_WFI_STATE but disable the Deep Idle state. Actually you don't have to modify the kernel you can setup the CPU idle level you want at runtime: echo 1 /sys/devices/system/cpu/cpu0/cpuidle/state1/disable will disable the state1. By doing this on Armada 370 then you will only use the WFI state. Do you still have this issue on v4.0-rc7? Thanks, Gregory Andrew -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Re: [PATCH 2/2] ARM: mvebu: dts: Add dts file for DLink DNS-327L
Gregory CLEMENT писал 13.04.2015 17:16: Hi Andrew(s), On 12/04/2015 21:47, Andrew Lunn wrote: On Sun, Apr 12, 2015 at 06:41:31PM +0300, Andrew wrote: Andrew Lunn ?? 12.04.2015 17:58: Okay, got it. I'll file a bug about this issue to the the bugzilla. However something tells me it might not be cpuidle, but D-link. This one's sounds nasty and it has been around since 3.16.x. How could it go unnoticed? Unfortunately I have no other armada-370 hardware to test it. Hi Andrew A few of us here do have hardware to test with. Please give a detailed description of how you reproduce the issue, and your kernel configuration, if different from mvebu_v7_defconfig, or multi_v7_defconfig. Thanks Andrew arch/arm/configs/mvebu_v7_defconfig has CONFIG_ARM_MVEBU_V7_CPUIDLE=y, so it should be sufficient to reproduce the issue. I first encountered this issue using that very config and observed it on 2 DNS-327L boxes I own. All I have to do to trigger the bug - enable cpuidle driver and let the box sit for some 4-12 hours, till it hard-freezes. If wdt is enabled - wdt reboot will happen. That simple! Well i've got a 370RD which has been sat mostly idle for weeks, using the mvebu_v7_defconfig, with a few addition things turned on for testing the Ethernet switch on the board. I've not had that lockup. One thing you can try to narrow it down is the disable the second idle mode. Take a look at armada370_idle_driver. Keep the ARM_CPUIDLE_WFI_STATE but disable the Deep Idle state. Actually you don't have to modify the kernel you can setup the CPU idle level you want at runtime: echo 1 /sys/devices/system/cpu/cpu0/cpuidle/state1/disable will disable the state1. By doing this on Armada 370 then you will only use the WFI state. Do you still have this issue on v4.0-rc7? Yep, I can confirm having this issue on 4.0-rc7. I will only be able to test if disabling state1 fixes it the next weekend. Thanks, Gregory Andrew -- Regards, Andrew -- 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 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
Hello Arnd, Thanks for your code review. On 2015/4/13 21:30, Arnd Bergmann wrote: On Monday 13 April 2015 17:17:38 Bintian Wang wrote: +#define HI6220_CFG_CSI2PHY 8 +#define HI6220_ISP_SCLK_GATE 9 +#define HI6220_ISP_SCLK_GATE1 10 +#define HI6220_ADE_CORE_GATE 11 +#define HI6220_CODEC_VPU_GATE 12 +#define HI6220_MED_SYSPLL 13 + +/* mux clocks */ +#define HI6220_1440_1200 20 +#define HI6220_1000_1200 21 +#define HI6220_1000_1440 22 + +/* divider clocks */ +#define HI6220_CODEC_JPEG 30 +#define HI6220_ISP_SCLK_SRC31 +#define HI6220_ISP_SCLK1 32 The numbers seem rather arbitrary, and you have both holes as well as duplicate numbers here. I would suggest you do one of two things instead: I just worry about some special clocks may be added later so keep some holes for them; The duplicate numbers means clocks belong to different system control domains. a) have a separate header file per clock driver and make all the numbers unique and consecutive within that header b) use the same numbers as the hardware registers so you can put the numbers directly into the dts and don't need a header to create an artificial ABI between the clock driver and the boot loader. This header file will be used by device tree (I like using the clock name instead magic number in dts :) ), so how about keep them in one header file and let dts just include one header file (not four files), but remove the holes? Thank you Arnd. BR, Bintian 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 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
On Mon, 2015-04-13 at 21:17 +0800, Bintian wrote: Thank you very much for code review and testing on arm! s/testing/crosscompiling for/ On 2015/4/13 19:56, Paul Bolle wrote: I wonder what checkpatch had to say about the length of the lines seen in this patch. Yes, I ran this script before sending out this patch set, it reports warnings about line over 80 characters , but I find it's easier to read than shrinking one line to several lines, so just keep it, do I need to fix it? I'll leave that to the maintainers of drivers/clk/. (I don't care deeply. So on second thought I should not have made that remark.) Thanks, Paul Bolle -- 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] power_supply: Add TI BQ24257 charger driver
W dniu 10.04.2015 o 22:18, Laurentiu Palcu pisze:
Based on the datasheet found here:
http://www.ti.com/lit/ds/symlink/bq24257.pdf
Signed-off-by: Laurentiu Palcu laurentiu.pa...@intel.com
(...)
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
new file mode 100644
index 000..58b9af1
--- /dev/null
+++ b/drivers/power/bq24257_charger.c
@@ -0,0 +1,868 @@
+/*
+ * TI BQ24257 charger driver
+ *
+ * Copyright (C) 2015 Intel 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; 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.
+ *
+ */
+
+#include linux/module.h
+#include linux/i2c.h
+#include linux/power_supply.h
+#include linux/regmap.h
+#include linux/types.h
+#include linux/gpio/consumer.h
+#include linux/interrupt.h
+#include linux/delay.h
+
+#include linux/acpi.h
+#include linux/of.h
+
+#define BQ24257_REG_1 0x00
+#define BQ24257_REG_2 0x01
+#define BQ24257_REG_3 0x02
+#define BQ24257_REG_4 0x03
+#define BQ24257_REG_5 0x04
+#define BQ24257_REG_6 0x05
+#define BQ24257_REG_7 0x06
+
+#define BQ24257_MANUFACTURER Texas Instruments
+#define BQ24257_STAT_IRQ stat
+#define BQ24257_PG_GPIOpg
+
+#define BQ24257_ILIM_SET_DELAY 1000/* msec */
+
+enum bq24257_fields {
+ F_WD_FAULT, F_WD_EN, F_STAT, F_FAULT, /* REG 1 */
+ F_RESET, F_IILIMIT, F_EN_STAT, F_EN_TERM, F_CE, F_HZ_MODE, /* REG 2 */
+ F_VBAT, F_USB_DET, /* REG 3 */
+ F_ICHG, F_ITERM,/* REG 4 */
+ F_LOOP_STATUS, F_LOW_CHG, F_DPDM_EN, F_CE_STATUS, F_VINDPM, /* REG 5 */
+ F_X2_TMR_EN, F_TMR, F_SYSOFF, F_TS_STAT,/* REG 6 */
+ F_VOVP, F_CLR_VDP, F_FORCE_BATDET, F_FORCE_PTM, /* REG 7 */
+
+ F_MAX_FIELDS
+};
+
+/* initial field values, converted from uV/uA */
+struct bq24257_init_data {
+ u8 ichg;/* charge current */
+ u8 vbat;/* regulation voltage */
+ u8 iterm; /* termination current */
+};
+
+struct bq24257_state {
+ u8 status;
+ u8 fault;
+ bool power_good;
+};
+
+struct bq24257_device {
+ struct i2c_client *client;
+ struct device *dev;
+ struct power_supply *charger;
+ struct power_supply_desc charger_desc;
+
+ struct regmap *rmap;
+ struct regmap_field *rmap_fields[F_MAX_FIELDS];
+
+ struct gpio_desc *pg;
+
+ struct delayed_work iilimit_setup_work;
+
+ struct bq24257_init_data init_data;
+ struct bq24257_state state;
+
+ struct mutex lock; /* protect state data */
+};
+
+static bool bq24257_is_writeable_reg(struct device *dev, unsigned int reg)
+{
+ return true;
What is the benefit of such function always returning true?
(...)
+
+static enum power_supply_property bq24257_power_supply_props[] = {
+ POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
+ POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
+};
+
+static char *bq24257_charger_supplied_to[] = {
+ main-battery,
+};
+
+static int bq24257_power_supply_init(struct bq24257_device *bq)
+{
+ struct power_supply_config psy_cfg = { .drv_data = bq, };
+ struct power_supply_desc *psy_desc = bq-charger_desc;
+
+ psy_desc-name = bq24257-charger;
+ psy_desc-type = POWER_SUPPLY_TYPE_USB;
+ psy_desc-properties = bq24257_power_supply_props;
+ psy_desc-num_properties = ARRAY_SIZE(bq24257_power_supply_props);
+ psy_desc-get_property = bq24257_power_supply_get_property;
You are not modifying the power_supply_desc so it can be made a static
const variable (file scope).
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 v2 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
Hello Paul, Thank you very much for code review and testing on arm! On 2015/4/13 19:56, Paul Bolle wrote: On Mon, 2015-04-13 at 17:17 +0800, Bintian Wang wrote: --- /dev/null +++ b/drivers/clk/hisilicon/Kconfig @@ -0,0 +1,5 @@ +config COMMON_CLK_HI6220 + tristate Hi6220 Clock Driver + depends on OF ARCH_HISI + help + Build the Hisilicon Hi6220 clock driver based on the common clock framework. In 5/6 you make arm64's ARCH_HISI (a bool) select COMMON_CLK_HI6220. So for arm64 this driver will always be built-in. For arm's ARCH_HISI it's possible to set COMMON_CLK_HI6220 to 'm'. Setting COMMON_CLK_HI6220 to a bool symbol is a good solution based on current code base, I will fix it in next version. --- a/drivers/clk/hisilicon/Makefile +++ b/drivers/clk/hisilicon/Makefile @@ -2,8 +2,9 @@ # Hisilicon Clock specific Makefile # -obj-y += clk.o clkgate-separated.o +obj-y += clk.o clkgate-separated.o clkdivider-hi6220.o These objects will always be built-in, right? obj-$(CONFIG_ARCH_HI3xxx) += clk-hi3620.o obj-$(CONFIG_ARCH_HIP04) += clk-hip04.o obj-$(CONFIG_ARCH_HIX5HD2)+= clk-hix5hd2.o +obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o If CONFIG_COMMON_CLK_HI6220 is 'm' this will build a module named clk-hi6220.ko. If I try to do that I get: $ make -C ../../.. ARCH=arm CROSS_COMPILE=arm-linux-gnu- M=$PWD clk-hi6220.ko make: Entering directory `[...]' CC [M] [...]/drivers/clk/hisilicon/clk-hi6220.o MODPOST 1 modules WARNING: hisi_clk_register_gate [[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined! WARNING: hi6220_clk_register_divider [[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined! WARNING: hisi_clk_register_mux [[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined! WARNING: hisi_clk_register_gate_sep [[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined! WARNING: hisi_clk_register_fixed_factor [[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined! WARNING: hisi_clk_register_fixed_rate [[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined! WARNING: hisi_clk_init [[...]/drivers/clk/hisilicon/clk-hi6220.ko] undefined! CC [...]/drivers/clk/hisilicon/clk-hi6220.mod.o LDFINAL [M] [...]/drivers/clk/hisilicon/clk-hi6220.ko make: Leaving directory `[...]' That is, I think, because nothing exports these symbols. [...] There's nothing module specific in this file. And the lack of a MODULE_LICENSE() macro is also telling. If this was built as a module loading that module - ignoring the undefined symbols - would taint the kernel. It seems to me that COMMON_CLK_HI6220 is meant to be a bool symbol. You are right. Paul Bolle I wonder what checkpatch had to say about the length of the lines seen in this patch. Yes, I ran this script before sending out this patch set, it reports warnings about line over 80 characters , but I find it's easier to read than shrinking one line to several lines, so just keep it, do I need to fix it? Thanks, Bintian . -- 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] of: return NUMA_NO_NODE from fallback of_node_to_nid()
On 13.04.2015 16:22, Rob Herring wrote:
On Wed, Apr 8, 2015 at 11:59 AM, Konstantin Khlebnikov
khlebni...@yandex-team.ru wrote:
Node 0 might be offline as well as any other numa node,
in this case kernel cannot handle memory allocation and crashes.
Signed-off-by: Konstantin Khlebnikov khlebni...@yandex-team.ru
Fixes: 0c3f061c195c (of: implement of_node_to_nid as a weak function)
---
drivers/of/base.c |2 +-
include/linux/of.h |5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8f165b112e03..51f4bd16e613 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -89,7 +89,7 @@ EXPORT_SYMBOL(of_n_size_cells);
#ifdef CONFIG_NUMA
int __weak of_node_to_nid(struct device_node *np)
{
- return numa_node_id();
+ return NUMA_NO_NODE;
This is going to break any NUMA machine that enables OF and expects
the weak function to work.
Why? NUMA_NO_NODE == -1 -- this's standard no-affinity signal.
As I see powerpc/sparc versions of of_node_to_nid returns -1 if they
cannot find out which node should be used.
Rob
}
#endif
diff --git a/include/linux/of.h b/include/linux/of.h
index dfde07e77a63..78a04ee85a9c 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -623,7 +623,10 @@ static inline const char *of_prop_next_string(struct
property *prop,
#if defined(CONFIG_OF) defined(CONFIG_NUMA)
extern int of_node_to_nid(struct device_node *np);
#else
-static inline int of_node_to_nid(struct device_node *device) { return 0; }
+static inline int of_node_to_nid(struct device_node *device)
+{
+ return NUMA_NO_NODE;
+}
#endif
static inline struct device_node *of_find_matching_node(
--
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
--
Konstantin
--
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] crypto: add new driver for Marvell CESA
Hey Gregory, On Mon, Apr 13, 2015 at 11:39:16AM +0200, Gregory CLEMENT wrote: Hi Jason, Boris, On 11/04/2015 00:30, Jason Cooper wrote: Hey Boris, On Fri, Apr 10, 2015 at 05:11:48PM +0200, Boris Brezillon wrote: On Fri, 10 Apr 2015 13:50:56 + Jason Cooper ja...@lakedaemon.net wrote: On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote: I know we usually try to adapt existing drivers instead of replacing them by new ones, but after trying to refactor the mv_cesa driver I realized it would take longer than writing an new one from scratch. I'm sorry, but this makes me *very* uncomfortable. Any organization worth it's salt will do a very careful audit of code touching cryptographic material and sensitive (decrypted) data. From that point on, small audits of the changes to the code allow the organization to build a comfort level with kernel updates. iow, following the git history of the driver. By apply this series, we are basically forcing those organizations to either a) stop updating, or b) expend significant resources to do another full audit. In short, this series breaks the audit chain for the mv_cesa driver. Maybe I'm the only person with this level of paranoia. If so, I'm sure others will override me. From my POV, it looks like the *only* reason we've chosen this route is developer convenience. I don't think that's sufficient reason to break the change history of a driver handling sensitive data. Well, I understand you concern, but if you read carefully the old and new drivers, you'll notice that they are completely different (the only thing I kept are the macro definitions). Yes, that's the worrying part for me. ;-) I understand the logic behind your concern, but I wonder if it is really an issue. My knowledge ans my background around crypto is very limited, so I really would like the opinion of other people on the subject. It's not about the crypto, it's about trust. imho, one of the most important security advances in the past 20 years is the default use of git (or other SCMs) by open source projects. Now, no one is forced to trust the authors and maintainers tarball dumps. Regular code audits and security updates are *much* more feasible because you can audit small changes. It can even be automated to a large extent. All this means the user has a choice: they can trust the authors and maintainers, or they can trust their own audits. Since updates are an essential part of a security posture, small commits facilitate maintaining the 'trust in audits'. It's not about Should you trust free-electrons? Or, Should you trust Jason / Herbert / Linus? It's about Should you have to trust any of them? I really tried to adapt the existing driver to add the missing features (especially the support for TDMA), but all my attempts ended up introducing hackish code (not even talking about the performance penalty of this approach). Ok, fair enough. It would be helpful if this account of attempting to reconcile the old driver made it into the commit message. This puts us in perfect is the enemy of getting it done territory. I have another solution though: keep the existing driver for old marvell SoCs (orion, kirkwood and dove), and add a new one for modern SoCs (armada 370, XP, 375 and 38x), so that users of the mv_cesa driver won't have to audit the new code. A fair proposal, but I'll freely admit the number of people actually auditing their code paths is orders of magnitude smaller than the number of users of the driver. There's such a large population of compatible legacy SoCs in the wild, adding an artificial boundary doesn't make sense. Especially since we're talking about features everyone would want to use. Perhaps we should keep both around, and deprecate the legacy driver over 3 to 4 cycles? But I guess that some users will want to use the new driver on the old marvell SoCs (especially kirkwood and dove). Yes, despite my arguments, I'm one of those people. :-P If we go to this path, then the best solution would be to still update all the the dts, and modifying the old driver to be able to use the new binding: for my point of view the only adaptation should be related to the SRAM. It will be also needed to find a way to be able to load only one driver at a time: either the old or the new, but not both. We can look at how the wireless drivers handle this. They often have to choose between multiple drivers (foss, proprietary, ndis-something, etc) for a given card. Not much different here. However I still wonder if it worth the effort. I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. thx,
Re: [PATCH] of: return NUMA_NO_NODE from fallback of_node_to_nid()
On Wed, Apr 8, 2015 at 11:59 AM, Konstantin Khlebnikov
khlebni...@yandex-team.ru wrote:
Node 0 might be offline as well as any other numa node,
in this case kernel cannot handle memory allocation and crashes.
Signed-off-by: Konstantin Khlebnikov khlebni...@yandex-team.ru
Fixes: 0c3f061c195c (of: implement of_node_to_nid as a weak function)
---
drivers/of/base.c |2 +-
include/linux/of.h |5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8f165b112e03..51f4bd16e613 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -89,7 +89,7 @@ EXPORT_SYMBOL(of_n_size_cells);
#ifdef CONFIG_NUMA
int __weak of_node_to_nid(struct device_node *np)
{
- return numa_node_id();
+ return NUMA_NO_NODE;
This is going to break any NUMA machine that enables OF and expects
the weak function to work.
Rob
}
#endif
diff --git a/include/linux/of.h b/include/linux/of.h
index dfde07e77a63..78a04ee85a9c 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -623,7 +623,10 @@ static inline const char *of_prop_next_string(struct
property *prop,
#if defined(CONFIG_OF) defined(CONFIG_NUMA)
extern int of_node_to_nid(struct device_node *np);
#else
-static inline int of_node_to_nid(struct device_node *device) { return 0; }
+static inline int of_node_to_nid(struct device_node *device)
+{
+ return NUMA_NO_NODE;
+}
#endif
static inline struct device_node *of_find_matching_node(
--
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
--
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: [PATCHv7] media: i2c/adp1653: Devicetree support for adp1653
Hi! #define to_adp1653_flash(sd) container_of(sd, struct adp1653_flash, subdev) Let me know if you're going to send v8 or if I can make the changes. I think we're pretty much done then. You are free to make the changes. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v2 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
On Monday 13 April 2015 17:17:38 Bintian Wang wrote: +#define HI6220_CFG_CSI2PHY 8 +#define HI6220_ISP_SCLK_GATE 9 +#define HI6220_ISP_SCLK_GATE1 10 +#define HI6220_ADE_CORE_GATE 11 +#define HI6220_CODEC_VPU_GATE 12 +#define HI6220_MED_SYSPLL 13 + +/* mux clocks */ +#define HI6220_1440_1200 20 +#define HI6220_1000_1200 21 +#define HI6220_1000_1440 22 + +/* divider clocks */ +#define HI6220_CODEC_JPEG 30 +#define HI6220_ISP_SCLK_SRC31 +#define HI6220_ISP_SCLK1 32 The numbers seem rather arbitrary, and you have both holes as well as duplicate numbers here. I would suggest you do one of two things instead: a) have a separate header file per clock driver and make all the numbers unique and consecutive within that header b) use the same numbers as the hardware registers so you can put the numbers directly into the dts and don't need a header to create an artificial ABI between the clock driver and the boot loader. 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] of: return NUMA_NO_NODE from fallback of_node_to_nid()
On Mon, Apr 13, 2015 at 8:38 AM, Konstantin Khlebnikov
khlebni...@yandex-team.ru wrote:
On 13.04.2015 16:22, Rob Herring wrote:
On Wed, Apr 8, 2015 at 11:59 AM, Konstantin Khlebnikov
khlebni...@yandex-team.ru wrote:
Node 0 might be offline as well as any other numa node,
in this case kernel cannot handle memory allocation and crashes.
Signed-off-by: Konstantin Khlebnikov khlebni...@yandex-team.ru
Fixes: 0c3f061c195c (of: implement of_node_to_nid as a weak function)
---
drivers/of/base.c |2 +-
include/linux/of.h |5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8f165b112e03..51f4bd16e613 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -89,7 +89,7 @@ EXPORT_SYMBOL(of_n_size_cells);
#ifdef CONFIG_NUMA
int __weak of_node_to_nid(struct device_node *np)
{
- return numa_node_id();
+ return NUMA_NO_NODE;
This is going to break any NUMA machine that enables OF and expects
the weak function to work.
Why? NUMA_NO_NODE == -1 -- this's standard no-affinity signal.
As I see powerpc/sparc versions of of_node_to_nid returns -1 if they
cannot find out which node should be used.
Ah, I was thinking those platforms were relying on the default
implementation. I guess any real NUMA support is going to need to
override this function. The arm64 patch series does that as well. We
need to be sure this change is correct for metag which appears to be
the only other OF enabled platform with NUMA support.
In that case, then there is little reason to keep the inline and we
can just always enable the weak function (with your change). It is
slightly less optimal, but the few callers hardly appear to be hot
paths.
Rob
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: socfpga: dts: Add a ciu clock node for sdmmc
Hi Steffen,
On 04/13/2015 03:10 AM, Steffen Trumtrar wrote:
Hi!
dingu...@opensource.altera.com writes:
From: Dinh Nguyen dingu...@opensource.altera.com
The CIU(Card Interface Unit) clock is used by the dw_mmc IP to clock an SD
card. The ciu_clk is the sdmmc_clk passed through a fixed divider of 4. This
patch
adds the ciu_clk node and makes the sdmmc_clk it's parent.
Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
arch/arm/boot/dts/socfpga.dtsi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index d9176e6..25418ee 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -451,6 +451,14 @@
clk-phase = 0 135;
};
+ciu_clk: ciu_clk {
+#clock-cells = 0;
+compatible =
altr,socfpga-gate-clk;
+clocks = sdmmc_clk;
+clk-gate = 0xa0 8;
+fixed-divider = 4;
+};
+
Hm, is this correct? The clk-gate at 0xa0 is for the SDMMC_CLK, no?
Also, maybe the clock should be named sdmmc_clk_divided like in the
datasheet, so it is easier to find.
Well, I didn't want to go down the path of defining a new clock that is
just a fork of the sdmmc_clk, so I just defined it as a gate-clock. I
think ultimately the gating of the sdmmc_clk is being done.
I can rename it to sdmmc_clk_divided.
Dinh
--
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 v6 0/3] Add arm pl353 smc nand driver for xilinx zynq soc
The following patches add arm pl353 static memory controller driver for xilinx zynq soc. The arm pl353 smc supports two interfaces i.e nand and nor/sram memory interfaces. The current implementation supports only a single SMC instance and nand specific configuration. xilinx zynq TRM link: http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf ARM pl353 smc TRM link: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/ DDI0380G_smc_pl350_series_r2p1_trm.pdf Punnaiah Choudary Kalluri (3): nand: pl353: Add basic driver for arm pl353 smc nand interface nand: pl353: Add software ecc support Documentation: nand: pl353: Add documentation for controller and driver Documentation/mtd/nand/pl353-nand.txt | 92 +++ drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/pl353_nand.c | 1068 + 4 files changed, 1168 insertions(+), 0 deletions(-) create mode 100644 Documentation/mtd/nand/pl353-nand.txt create mode 100644 drivers/mtd/nand/pl353_nand.c -- 1.7.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 v6 2/3] nand: pl353: Add software ecc support
Added software ecc support.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes in v6:
- None
Changes in v5:
- None
Changes in v4:
- Updated the driver to sync with pl353_smc driver APIs
---
drivers/mtd/nand/pl353_nand.c | 164 +
1 files changed, 164 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c
index 1fe048f..4f4bf93 100644
--- a/drivers/mtd/nand/pl353_nand.c
+++ b/drivers/mtd/nand/pl353_nand.c
@@ -331,6 +331,71 @@ static int pl353_nand_write_oob(struct mtd_info *mtd,
struct nand_chip *chip,
}
/**
+ * pl353_nand_read_page_raw - [Intern] read raw page data without ecc
+ * @mtd: Pointer to the mtd info structure
+ * @chip: Pointer to the NAND chip info structure
+ * @buf: Pointer to the data buffer
+ * @oob_required: Caller requires OOB data read to chip-oob_poi
+ * @page: Page number to read
+ *
+ * Return: Always return zero
+ */
+static int pl353_nand_read_page_raw(struct mtd_info *mtd,
+ struct nand_chip *chip,
+ uint8_t *buf, int oob_required, int page)
+{
+ unsigned long data_phase_addr;
+ uint8_t *p;
+
+ chip-read_buf(mtd, buf, mtd-writesize);
+
+ p = chip-oob_poi;
+ chip-read_buf(mtd, p,
+ (mtd-oobsize - PL353_NAND_LAST_TRANSFER_LENGTH));
+ p += (mtd-oobsize - PL353_NAND_LAST_TRANSFER_LENGTH);
+
+ data_phase_addr = (unsigned long __force)chip-IO_ADDR_R;
+ data_phase_addr |= PL353_NAND_CLEAR_CS;
+ chip-IO_ADDR_R = (void __iomem * __force)data_phase_addr;
+
+ chip-read_buf(mtd, p, PL353_NAND_LAST_TRANSFER_LENGTH);
+ return 0;
+}
+
+/**
+ * pl353_nand_write_page_raw - [Intern] raw page write function
+ * @mtd: Pointer to the mtd info structure
+ * @chip: Pointer to the NAND chip info structure
+ * @buf: Pointer to the data buffer
+ * @oob_required: Caller requires OOB data read to chip-oob_poi
+ *
+ * Return: Always return zero
+ */
+static int pl353_nand_write_page_raw(struct mtd_info *mtd,
+ struct nand_chip *chip,
+ const uint8_t *buf, int oob_required)
+{
+ unsigned long data_phase_addr;
+ uint8_t *p;
+
+ chip-write_buf(mtd, buf, mtd-writesize);
+
+ p = chip-oob_poi;
+ chip-write_buf(mtd, p,
+ (mtd-oobsize - PL353_NAND_LAST_TRANSFER_LENGTH));
+ p += (mtd-oobsize - PL353_NAND_LAST_TRANSFER_LENGTH);
+
+ data_phase_addr = (unsigned long __force)chip-IO_ADDR_W;
+ data_phase_addr |= PL353_NAND_CLEAR_CS;
+ data_phase_addr |= (1 END_CMD_VALID_SHIFT);
+ chip-IO_ADDR_W = (void __iomem * __force)data_phase_addr;
+
+ chip-write_buf(mtd, p, PL353_NAND_LAST_TRANSFER_LENGTH);
+
+ return 0;
+}
+
+/**
* nand_write_page_hwecc - Hardware ECC based page write function
* @mtd: Pointer to the mtd info structure
* @chip: Pointer to the NAND chip info structure
@@ -396,6 +461,39 @@ static int pl353_nand_write_page_hwecc(struct mtd_info
*mtd,
}
/**
+ * pl353_nand_write_page_swecc - [REPLACEABLE] software ecc based page write
+ * function
+ * @mtd: Pointer to the mtd info structure
+ * @chip: Pointer to the NAND chip info structure
+ * @buf: Pointer to the data buffer
+ * @oob_required: Caller requires OOB data read to chip-oob_poi
+ *
+ * Return: Always return zero
+ */
+static int pl353_nand_write_page_swecc(struct mtd_info *mtd,
+ struct nand_chip *chip, const uint8_t *buf,
+ int oob_required)
+{
+ int i, eccsize = chip-ecc.size;
+ int eccbytes = chip-ecc.bytes;
+ int eccsteps = chip-ecc.steps;
+ uint8_t *ecc_calc = chip-buffers-ecccalc;
+ const uint8_t *p = buf;
+ uint32_t *eccpos = chip-ecc.layout-eccpos;
+
+ /* Software ecc calculation */
+ for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize)
+ chip-ecc.calculate(mtd, p, ecc_calc[i]);
+
+ for (i = 0; i chip-ecc.total; i++)
+ chip-oob_poi[eccpos[i]] = ecc_calc[i];
+
+ chip-ecc.write_page_raw(mtd, chip, buf, 1);
+
+ return 0;
+}
+
+/**
* pl353_nand_read_page_hwecc - Hardware ECC based page read function
* @mtd: Pointer to the mtd info structure
* @chip: Pointer to the NAND chip info structure
@@ -477,6 +575,52 @@ static int pl353_nand_read_page_hwecc(struct mtd_info *mtd,
}
/**
+ * pl353_nand_read_page_swecc - [REPLACEABLE] software ecc based page read
+ * function
+ * @mtd: Pointer to the mtd info structure
+ * @chip: Pointer to the NAND chip info structure
+ * @buf: Pointer to the buffer to
[PATCH v6 1/2] Devicetree: Add pl353 smc controller devicetree binding information
Add pl353 static memory controller devicetree binding information.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes in v6:
- None
Changes in v5:
- Removed timing properties
Changes in v4:
- none
Changes in v3:
- none
Changes in v2:
- modified timing binding info as per onfi timing parameters
- add suffix nano second as timing unit
- modified the clock names as per the IP spec
---
.../bindings/memory-controllers/pl353-smc.txt | 37
1 files changed, 37 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
new file mode 100644
index 000..a868f94
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
@@ -0,0 +1,37 @@
+Device tree bindings for ARM PL353 static memory controller
+
+PL353 static memory controller supports two kinds of memory
+interfaces. i.e NAND and SRAM/NOR interfaces.
+The actual devices are instantiated from the child nodes of pl353 smc node.
+
+Required properties:
+- compatible : Should be arm,pl353-smc-r2p1
+- reg : Controller registers map and length.
+- clock-names : List of input clock names - memclk, aclk
+ (See clock bindings for details).
+- clocks : Clock phandles (see clock bindings for details).
+- address-cells: Address cells, must be 1.
+- size-cells : Size cells. Must be 1.
+
+Child nodes:
+ For NAND the arm,pl353-nand-r2p1 and for NOR the cfi-flash drivers are
+supported as child nodes.
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ pl353smcc_0: pl353smcc@e000e000 {
+ compatible = arm,pl353-smcc-r2p1
+ clock-names = memclk, aclk;
+ clocks = clkc 11, clkc 44;
+ reg = 0xe000e000 0x1000;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ nand_0: nand@e100 {
+ compatible = arm,pl353-nand-r2p1
+ reg = 0xe100 0x100;
+ (...)
+ };
+ };
--
1.7.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 v6 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
Add driver for arm pl353 static memory controller nand interface with HW ECC support. This controller is used in xilinx zynq soc for interfacing the nand flash memory. Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com --- Changes in v6: - Fixed the checkpatch.pl reported warnings - Using the address cycles information from the onfi param page earlier it is hardcoded to 5 in driver Changes in v5: - Configure the nand timing parameters as per the onfi spec Changes in v4: - Updated the driver to sync with pl353_smc driver APIs Changes in v3: - implemented the proper error codes - further breakdown this patch to multiple sets - added the controller and driver details to Documentation section - updated the licenece to GPLv2 - reorganized the pl353_nand_ecc_init function Changes in v2: - use depends on rather than select option in kconfig - remove unused variable parts - remove dummy helper and use writel_relaxed directly --- drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/pl353_nand.c | 904 + 3 files changed, 912 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/nand/pl353_nand.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 5897d8d..c14a955 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -497,6 +497,13 @@ config MTD_NAND_NUC900 This enables the driver for the NAND Flash on evaluation board based on w90p910 / NUC9xx. +config MTD_NAND_PL353 + tristate ARM Pl353 NAND flash driver + depends on MTD_NAND ARM + depends on PL353_SMC + help + This enables access to the NAND flash device on PL353 SMC controller. + config MTD_NAND_JZ4740 tristate Support for JZ4740 SoC NAND controller depends on MACH_JZ4740 diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 582bbd05..c68fd7c 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -52,5 +52,6 @@ obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o +obj-$(CONFIG_MTD_NAND_PL353) += pl353_nand.o nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/drivers/mtd/nand/pl353_nand.c b/drivers/mtd/nand/pl353_nand.c new file mode 100644 index 000..1fe048f --- /dev/null +++ b/drivers/mtd/nand/pl353_nand.c @@ -0,0 +1,904 @@ +/* + * ARM PL353 NAND Flash Controller Driver + * + * Copyright (C) 2009 - 2014 Xilinx, Inc. + * + * This driver is based on plat_nand.c and mxc_nand.c drivers + * + * 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; either version 2 of the License, or (at your + * option) any later version. + */ + +#include linux/err.h +#include linux/delay.h +#include linux/interrupt.h +#include linux/io.h +#include linux/ioport.h +#include linux/irq.h +#include linux/memory/pl353-smc.h +#include linux/module.h +#include linux/moduleparam.h +#include linux/mtd/mtd.h +#include linux/mtd/nand.h +#include linux/mtd/nand_ecc.h +#include linux/mtd/partitions.h +#include linux/of_address.h +#include linux/of_device.h +#include linux/of_mtd.h +#include linux/of_platform.h +#include linux/platform_device.h +#include linux/slab.h + +#define PL353_NAND_DRIVER_NAME pl353-nand + +/* NAND flash driver defines */ +#define PL353_NAND_CMD_PHASE 1 /* End command valid in command phase */ +#define PL353_NAND_DATA_PHASE 2 /* End command valid in data phase */ +#define PL353_NAND_ECC_SIZE512 /* Size of data for ECC operation */ + +/* Flash memory controller operating parameters */ + +#define PL353_NAND_ECC_CONFIG (BIT(4) | /* ECC read at end of page */ \ +(0 5)) /* No Jumping */ + +/* AXI Address definitions */ +#define START_CMD_SHIFT3 +#define END_CMD_SHIFT 11 +#define END_CMD_VALID_SHIFT20 +#define ADDR_CYCLES_SHIFT 21 +#define CLEAR_CS_SHIFT 21 +#define ECC_LAST_SHIFT 10 +#define COMMAND_PHASE (0 19) +#define DATA_PHASE BIT(19) + +#define PL353_NAND_ECC_LASTBIT(ECC_LAST_SHIFT) /* Set ECC_Last */ +#define PL353_NAND_CLEAR_CSBIT(CLEAR_CS_SHIFT) /* Clear chip select */ + +#define ONDIE_ECC_FEATURE_ADDR 0x90 +#define PL353_NAND_ECC_BUSY_TIMEOUT(1 * HZ) +#define PL353_NAND_DEV_BUSY_TIMEOUT(1 * HZ) +#define PL353_NAND_LAST_TRANSFER_LENGTH4 + +/** + * struct pl353_nand_command_format - Defines NAND flash command format + * @start_cmd: First cycle command (Start command) + * @end_cmd: Second cycle command (Last command) + * @addr_cycles: Number of address cycles required to send the address
[PATCH v6 0/2] Add arm pl353 smc driver for xilinx zynq soc
The following patches add arm pl353 static memory controller driver for xilinx zynq soc. The arm pl353 smc supports two interfaces i.e nand and nor/sram memory interfaces. The current implementation supports only a single SMC instance and nand specific configuration. xilinx zynq TRM link: http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf ARM pl353 smc TRM link: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/ DDI0380G_smc_pl350_series_r2p1_trm.pdf Punnaiah Choudary Kalluri (2): Devicetree: Add pl353 smc controller devicetree binding information memory: pl353: Add driver for arm pl353 static memory controller .../bindings/memory-controllers/pl353-smc.txt | 37 ++ drivers/memory/Kconfig |7 + drivers/memory/Makefile|2 +- drivers/memory/pl353-smc.c | 526 include/linux/memory/pl353-smc.h | 37 ++ 5 files changed, 608 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt create mode 100644 drivers/memory/pl353-smc.c create mode 100644 include/linux/memory/pl353-smc.h -- 1.7.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 v6 3/3] Documentation: nand: pl353: Add documentation for controller and driver
Added notes about the controller and driver Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com --- Changes in v6: - None Changes in v5: - Fixed the review comments Changes in v4: - None --- Documentation/mtd/nand/pl353-nand.txt | 92 + 1 files changed, 92 insertions(+), 0 deletions(-) create mode 100644 Documentation/mtd/nand/pl353-nand.txt diff --git a/Documentation/mtd/nand/pl353-nand.txt b/Documentation/mtd/nand/pl353-nand.txt new file mode 100644 index 000..d91ad62 --- /dev/null +++ b/Documentation/mtd/nand/pl353-nand.txt @@ -0,0 +1,92 @@ +This documents provides some notes about the ARM pl353 smc controller used in +Zynq SOC and confined to NAND specific details. + +Overview of the controller +== + The SMC (PL353) supports two memory interfaces: + Interface 0 type SRAM. + Interface 1 type NAND. + This configuration supports the following configurable options: + . 32-bit or 64-bit AXI data width + . 8-bit, 16-bit, or 32-bit memory data width for interface 0 + . 8-bit, or 16-bit memory data width for interface 1 + . 1-4 chip selects on each interface + . SLC ECC block for interface 1 + +For more information, refer the below link for TRM +http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/ +DDI0380G_smc_pl350_series_r2p1_trm.pdf + +NAND memory accesses + + . Two phase NAND accesses + . NAND command phase transfers + . NAND data phase transfers + +Two phase NAND accesses + The SMC defines two phases of commands when transferring data to or from +NAND flash. + +Command phase + Commands and optional address information are written to the NAND flash. +The command and address can be associated with either a data phase operation to +write to or read from the array, or a status/ID register transfer. + +Data phase + Data is either written to or read from the NAND flash. This data can be either +data transferred to or from the array, or status/ID register information. + +NAND AXI address setup + AXI address Command phase Data phase + [31:24] Chip address Chip address + [23]NoOfAddCycles_2Reserved + [22]NoOfAddCycles_1Reserved + [21]NoOfAddCycles_0ClearCS + [20]End command valid End command valid + [19]0 1 + [18:11] End commandEnd command + [10:3] Start command [10] ECC Last + [9:3] Reserved + [2:0] Reserved Reserved + +ECC +=== +It operates on a number of 512 byte blocks of NAND memory and can be +programmed to store the ECC codes after the data in memory. For writes, +the ECC is written to the spare area of the page. For reads, the result of +a block ECC check are made available to the device driver. + + +| n * 512 blocks | extra | ecc| | +| | block | codes | | + + +The ECC calculation uses a simple Hamming code, using 1-bit correction 2-bit +detection. It starts when a valid read or write command with a 512 byte aligned +address is detected on the memory interface. + +Driver details +== + The NAND driver has dependency with the pl353_smc memory controller +driver for intializing the nand timing parameters, bus width, ECC modes, +control and status information. + +Since the controller expects that the chipselect bit should be cleared for the +last data transfer i.e last 4 data bytes, the existing nandbase page +read/write routines for soft ecc and ecc none modes will not work. So, inorder +to make this driver work, it always updates the ecc mode as HW ECC and +implemented the page read/write functions for supporting the SW ECC. + +HW ECC mode: + Upto 2K page size is supported and beyond that it retuns +-ENOSUPPORT error. If the flsh has ONDIE ecc controller then the +priority has given to the ONDIE ecc controller. Also the current +implementation has support for upto 64 byte oob area + +SW ECC mode: + It supports all the pgae sizes. But since, zynq soc bootrom uses +HW ECC for the devices that have pgae size =2K so, to avoid any ecc related +issues during boot, prefer HW ECC over SW ECC. + +For devicetree binding information please refer the below dt binding file +Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt -- 1.7.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 v6 2/2] memory: pl353: Add driver for arm pl353 static memory controller
Add driver for arm pl353 static memory controller. This controller is used in xilinx zynq soc for interfacing the nand and nor/sram memory devices. Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com --- Changes in v6: - Fixed checkpatch.pl reported warnings - fixed missing space and dont enable this driver default Changes in v5: - Added pl353_smc_get_clkrate function, made pl353_smc_set_cycles as public API - Removed nand timing parameter initialization and moved it to nand driver Changes in v4: - Modified driver to support multiple instances - Used sleep instaed of busywait for delay Changes in v3: - None Changes in v2: - Since now the timing parameters are in nano seconds, added logic to convert them to the cycles --- drivers/memory/Kconfig |7 + drivers/memory/Makefile |2 +- drivers/memory/pl353-smc.c | 526 ++ include/linux/memory/pl353-smc.h | 37 +++ 4 files changed, 571 insertions(+), 1 deletions(-) create mode 100644 drivers/memory/pl353-smc.c create mode 100644 include/linux/memory/pl353-smc.h diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 191383d8..7db4f74 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -83,6 +83,13 @@ config FSL_IFC bool depends on FSL_SOC +config PL353_SMC + bool ARM PL353 Static Memory Controller (SMC) driver + depends on ARM + help + This driver is for the ARM PL353 Static Memory Controller (SMC) + module. + source drivers/memory/tegra/Kconfig endif diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile index 6b65481..8a112ac 100644 --- a/drivers/memory/Makefile +++ b/drivers/memory/Makefile @@ -13,5 +13,5 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o obj-$(CONFIG_FSL_IFC) += fsl_ifc.o obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o - +obj-$(CONFIG_PL353_SMC)+= pl353-smc.o obj-$(CONFIG_TEGRA_MC) += tegra/ diff --git a/drivers/memory/pl353-smc.c b/drivers/memory/pl353-smc.c new file mode 100644 index 000..b407b47 --- /dev/null +++ b/drivers/memory/pl353-smc.c @@ -0,0 +1,526 @@ +/* + * ARM PL353 SMC Driver + * + * Copyright (C) 2012 - 2014 Xilinx, Inc. + * + * 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. + * + * Currently only a single SMC instance is supported. + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/io.h +#include linux/kernel.h +#include linux/memory/pl353-smc.h +#include linux/module.h +#include linux/of_platform.h +#include linux/platform_device.h +#include linux/slab.h + +/* Register definitions */ +#define PL353_SMC_MEMC_STATUS_OFFS 0 /* Controller status reg, RO */ +#define PL353_SMC_CFG_CLR_OFFS 0xC /* Clear config reg, WO */ +#define PL353_SMC_DIRECT_CMD_OFFS 0x10/* Direct command reg, WO */ +#define PL353_SMC_SET_CYCLES_OFFS 0x14/* Set cycles register, WO */ +#define PL353_SMC_SET_OPMODE_OFFS 0x18/* Set opmode register, WO */ +#define PL353_SMC_ECC_STATUS_OFFS 0x400 /* ECC status register */ +#define PL353_SMC_ECC_MEMCFG_OFFS 0x404 /* ECC mem config reg */ +#define PL353_SMC_ECC_MEMCMD1_OFFS 0x408 /* ECC mem cmd1 reg */ +#define PL353_SMC_ECC_MEMCMD2_OFFS 0x40C /* ECC mem cmd2 reg */ +#define PL353_SMC_ECC_VALUE0_OFFS 0x418 /* ECC value 0 reg */ + +/* Controller status register specific constants */ +#define PL353_SMC_MEMC_STATUS_RAW_INT_1_SHIFT 6 + +/* Clear configuration register specific constants */ +#define PL353_SMC_CFG_CLR_INT_CLR_10x10 +#define PL353_SMC_CFG_CLR_ECC_INT_DIS_10x40 +#define PL353_SMC_CFG_CLR_INT_DIS_10x2 +#define PL353_SMC_CFG_CLR_DEFAULT_MASK (PL353_SMC_CFG_CLR_INT_CLR_1 | \ +PL353_SMC_CFG_CLR_ECC_INT_DIS_1 | \ +PL353_SMC_CFG_CLR_INT_DIS_1) + +/* Set cycles register specific constants */ +#define PL353_SMC_SET_CYCLES_T0_MASK 0xF +#define PL353_SMC_SET_CYCLES_T0_SHIFT 0 +#define PL353_SMC_SET_CYCLES_T1_MASK 0xF +#define PL353_SMC_SET_CYCLES_T1_SHIFT 4 +#define PL353_SMC_SET_CYCLES_T2_MASK 0x7 +#define PL353_SMC_SET_CYCLES_T2_SHIFT 8 +#define PL353_SMC_SET_CYCLES_T3_MASK 0x7 +#define PL353_SMC_SET_CYCLES_T3_SHIFT 11 +#define PL353_SMC_SET_CYCLES_T4_MASK 0x7 +#define PL353_SMC_SET_CYCLES_T4_SHIFT 14 +#define PL353_SMC_SET_CYCLES_T5_MASK 0x7 +#define PL353_SMC_SET_CYCLES_T5_SHIFT 17
Re: [PATCH 1/2] pinctrl: bcm2835: add pinctrl pre-processor define
Hi Alexander, Alexander Stein alexander...@web.de hat am 12. April 2015 um 14:33 geschrieben: This adds defines for the BCM2835 function selections. This is notably useful as the functions are not ordered. if you look at Lee's repository then you will see this is already implemented. Best regards Stefan -- 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/1] ata: ahci_xgene: Add AHCI Support for second generation of APM X-Gene SoC
On Monday 13 April 2015 15:02:40 Suman Tripathi wrote: This patch enables full AHCI feature support for APM X-Gene SoC SATA host host controller. The following errata's are removed: 1. 2a0bdff6b95 (ahci-xgene: fix the dma state machine lockup for the IDENTIFY DEVICE PIO mode command) 2. 09c32aaa368 (ahci_xgene: Fix the dma state machine lockup for the ATA_CMD_SMART PIO mode command) 3. 1540035da71 (ahci_xgene: Implement the xgene_ahci_poll_reg_val to support PMP) 4. a3a84bc7c88 (ahci_xgene: Implement the workaround to support PMP enumeration and discovery) 5. 1102407bb71 (ahci_xgene: Fix the DMA state machine lockup for the ATA_CMD_PACKET PIO mode command) 6. 72f79f9e35b (ahci_xgene: Removing NCQ support from the APM X-Gene SoC AHCI SATA Host Controller driver) In addition, enable PMP support for APM X-Gene SoC and enable FBS support for second generation APM X-Gene SoC. Is this now close enough to AHCI that you can just use the normal AHCI driver, or are there still too many remaining errata? 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 v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
So NAK to the PSCI node and PSCI enable method in this dts until we
either have a working firmware, or a reasonable mechanism to handle the
deficiency.
There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.
I understand that, but the issue with CPU0 is still a blocker from my
PoV.
To fix this issue, we must need the help of firmware developer.
But, We never get the any help.
Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?
I didn't ask any help to firmware engineer because I didn't know who firmware
engineer
and also didn't access the source code. If I knew the engineer and can access
them,
I would have asked some help to them or inquired the reason about CPU0 not
hotplugged.
You must have acquired the firmware (or board(s) with the firmware
preloaded) from somewhere. Surely you can work backwards from there to
file a bug report and/or inquire as to who you need to speak to...
Mark.
--
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] crypto: add new driver for Marvell CESA
Hi Jason, Jason Cooper ja...@lakedaemon.net writes: It's not about the crypto, it's about trust. imho, one of the most important security advances in the past 20 years is the default use of git (or other SCMs) by open source projects. Now, no one is forced to trust the authors and maintainers tarball dumps. Regular code audits and security updates are *much* more feasible because you can audit small changes. It can even be automated to a large extent. All this means the user has a choice: they can trust the authors and maintainers, or they can trust their own audits. Since updates are an essential part of a security posture, small commits facilitate maintaining the 'trust in audits'. It's not about Should you trust free-electrons? Or, Should you trust Jason / Herbert / Linus? It's about Should you have to trust any of them? It's ok, you can call our driver fat. It is ;-) More seriously, I tend to agree w/ what you write above. I really tried to adapt the existing driver to add the missing features (especially the support for TDMA), but all my attempts ended up introducing hackish code (not even talking about the performance penalty of this approach). Ok, fair enough. It would be helpful if this account of attempting to reconcile the old driver made it into the commit message. This puts us in perfect is the enemy of getting it done territory. I have another solution though: keep the existing driver for old marvell SoCs (orion, kirkwood and dove), and add a new one for modern SoCs (armada 370, XP, 375 and 38x), so that users of the mv_cesa driver won't have to audit the new code. A fair proposal, but I'll freely admit the number of people actually auditing their code paths is orders of magnitude smaller than the number of users of the driver. There's such a large population of compatible legacy SoCs in the wild, adding an artificial boundary doesn't make sense. Especially since we're talking about features everyone would want to use. Perhaps we should keep both around, and deprecate the legacy driver over 3 to 4 cycles? But I guess that some users will want to use the new driver on the old marvell SoCs (especially kirkwood and dove). Yes, despite my arguments, I'm one of those people. :-P If we go to this path, then the best solution would be to still update all the the dts, and modifying the old driver to be able to use the new binding: for my point of view the only adaptation should be related to the SRAM. It will be also needed to find a way to be able to load only one driver at a time: either the old or the new, but not both. The approach Boris proposed above seems to make everyone happy: 1) Keep the old driver for old marvells SoCs (kirkwood, dove and orion) 2) Introduce the new driver for those that are not supported by the old driver, i.e. armada (370, XP, 375, 38x) AFAICT, this can easily be done (based on compatible strings) and it will let everyone the time to audit the new driver. Current users will not be taken by surprise. At some point, when everyone is confident w/ the new driver, we can then switch to that one for all SoCs so that old platform get more performance. Additionnally, for those who want to get the feature of the new driver for their old SoC right now, we *could* add a simple kernel config option for the new driver to use it for the old SoC too (that one disabling the old one). I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? Cheers, a+ -- 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 3/6] clk: hi6220: Document devicetree bindings for hi6220 clock
On Monday 13 April 2015 17:17:37 Bintian Wang wrote: +- compatible: the compatible should be one of the following strings to + indicate the clock controller functionality. + + - hisilicon,aoctrl + - hisilicon,sysctrl + - hisilicon,mediactrl + - hisilicon,pmctrl + These ones already have bindings, you can't reuse the strings. Please work with someone in hisilicon to set up a registry of device names so you can avoid conflicts in the future. 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 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
On Monday 13 April 2015 21:57:46 Bintian wrote: Hello Arnd, Thanks for your code review. On 2015/4/13 21:30, Arnd Bergmann wrote: On Monday 13 April 2015 17:17:38 Bintian Wang wrote: +#define HI6220_CFG_CSI2PHY 8 +#define HI6220_ISP_SCLK_GATE 9 +#define HI6220_ISP_SCLK_GATE1 10 +#define HI6220_ADE_CORE_GATE 11 +#define HI6220_CODEC_VPU_GATE 12 +#define HI6220_MED_SYSPLL 13 + +/* mux clocks */ +#define HI6220_1440_1200 20 +#define HI6220_1000_1200 21 +#define HI6220_1000_1440 22 + +/* divider clocks */ +#define HI6220_CODEC_JPEG 30 +#define HI6220_ISP_SCLK_SRC31 +#define HI6220_ISP_SCLK1 32 The numbers seem rather arbitrary, and you have both holes as well as duplicate numbers here. I would suggest you do one of two things instead: I just worry about some special clocks may be added later so keep some holes for them; The duplicate numbers means clocks belong to different system control domains. I don't understand. How would there be additional clocks added later? Wouldn't that be a new chip? If you have separate system control domains, doesn't that mean that you also have separate DT bindings? a) have a separate header file per clock driver and make all the numbers unique and consecutive within that header b) use the same numbers as the hardware registers so you can put the numbers directly into the dts and don't need a header to create an artificial ABI between the clock driver and the boot loader. This header file will be used by device tree (I like using the clock name instead magic number in dts :) ) That's not how it works though: The dts file is the place to define the hardware numbers, we do that for all sorts of numbers: interrupts, gpios, register ranges etc are all defined in dts to avoid putting magic numbers in external header files. There are some cases where it gets too ugly for clock controllers that are highly irregular, but yours doesn't seem to be that kind. E.g. all the fixed rate clocks should just be separate device nodes, which lets you remove the binding for that node. so how about keep them in one header file and let dts just include one header file (not four files), but remove the holes? The header files constantly cause problems with merge dependencies, and we have some other companies that keep releasing new chips that each time require a new header file. If hisilicon plans to make more chips like this one, please consider coming up with more generic bindings to avoid this. 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
