* Re: [PATCH v4 6/6] clk: qcom: ipq4019: Add the cpu clock frequency change notifier
From: Stephen Boyd @ 2016-12-21 23:56 UTC (permalink / raw)
To: Abhishek Sahu
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
mturquette-rdvid1DuHRBWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, varada-sgV2jX0FEOL9JmXXK+q4OQ,
pradeepb-sgV2jX0FEOL9JmXXK+q4OQ, snlakshm-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480088493-4590-7-git-send-email-absahu-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 11/25, Abhishek Sahu wrote:
> @@ -1736,13 +1737,55 @@ static int clk_cpu_div_set_rate(struct clk_hw *hw, unsigned long rate,
> };
> MODULE_DEVICE_TABLE(of, gcc_ipq4019_match_table);
>
> +/* Contains index for safe clock during APSS freq change */
> +static int gcc_ipq4019_cpu_safe_parent;
> +static int
> +gcc_ipq4019_cpu_clk_notifier_fn(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + int err = 0;
> +
> + if (action == PRE_RATE_CHANGE)
> + err = clk_rcg2_ops.set_parent(&apps_clk_src.clkr.hw,
> + gcc_ipq4019_cpu_safe_parent);
Why can't we hardcode this? It's not like this safe parent is
going to change across boards.
> +
> + return notifier_from_errno(err);
> +}
> +
> +static struct notifier_block gcc_ipq4019_cpu_clk_notifier = {
> + .notifier_call = gcc_ipq4019_cpu_clk_notifier_fn,
> +};
> +
> static int gcc_ipq4019_probe(struct platform_device *pdev)
> {
> - return qcom_cc_probe(pdev, &gcc_ipq4019_desc);
> + int err;
> +
> + err = qcom_cc_probe(pdev, &gcc_ipq4019_desc);
> + if (err)
> + return err;
> +
> + gcc_ipq4019_cpu_safe_parent = qcom_find_src_index(&apps_clk_src.clkr.hw,
> + apps_clk_src.parent_map,
> + P_FEPLL500);
> + if (gcc_ipq4019_cpu_safe_parent < 0)
> + err = gcc_ipq4019_cpu_safe_parent;
Then we don't need to do this.
> +
> + if (!err)
> + err = clk_notifier_register(apps_clk_src.clkr.hw.clk,
> + &gcc_ipq4019_cpu_clk_notifier);
> +
> + return err;
> +}
> +
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 00/10] netcp: enhancements and minor fixes
From: Murali Karicheri @ 2016-12-21 23:50 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-omap, grygorii.strashko, mugunthanvnm, linux-kernel,
arnd, devicetree, mark.rutland, robh+dt
In-Reply-To: <20161220.190315.439054497576758011.davem@davemloft.net>
David,
On 12/20/2016 07:03 PM, David Miller wrote:
>
> The net-next tree is not open, do not resubmit this series until it
> is open again.
>
> Thanks.
>
Ok. Thanks
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
From: Stephen Boyd @ 2016-12-21 23:47 UTC (permalink / raw)
To: Markus Mayer
Cc: Michael Turquette, Rob Herring, Mark Rutland, Viresh Kumar,
Rafael J . Wysocki, Arnd Bergmann, Markus Mayer,
Broadcom Kernel List, Linux Clock List, Power Management List,
Device Tree List, ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <20161220225530.96699-2-code@mmayer.net>
On 12/20, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
>
> Add binding document for brcm,brcmstb-cpu-clk-div.
>
> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
> ---
> .../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 83 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 84 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> new file mode 100644
> index 0000000..3bc99c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> @@ -0,0 +1,83 @@
> +The CPU divider node serves as the sole clock for the CPU complex. It supports
> +power-of-2 clock division, with a divider of "1" as the default highest-speed
> +setting.
> +
> +Required properties:
> +- compatible: shall be "brcm,brcmstb-cpu-clk-div"
> +- reg: address and width of the divider configuration register
> +- #clock-cells: shall be set to 0
> +- clocks: phandle of clock provider which provides the source clock
> + (this would typically be a "fixed-clock" type PLL)
> +- div-table: list of (raw_value,divider) ordered pairs that correspond to the
> + allowed clock divider settings
> +- div-shift-width: least-significant bit position and width of divider value
> +
> +Optional properties:
> +- clocks: additional clocks can be specified if needed
> +- clock-names: clocks can be named, so they can be looked up
> +
> +Example:
> + sw_scb: sw_scb {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <432000000>;
> + };
> +
Is this a PLL?
> + fixed0: fixed0 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <54000000>;
> + };
And perhaps some sort of oscillator?
> +
> + cpu_pdiv: cpu_pdiv@f04e0008 {
> + compatible = "divider-clock";
> + #clock-cells = <0>;
> + reg = <0xf04e0008 0x4>;
> + bit-shift = <10>;
> + bit-mask = <0xf>;
> + index-starts-at-one;
> + clocks = <&fixed0>;
> + clock-names = "fixed0";
> + };
> +
> + cpu_ndiv_int: cpu_ndiv_int {
> + compatible = "fixed-factor-clock";
Ok..
> + #clock-cells = <0>;
> + clock-div = <1>;
> + clock-mult = <167>;
> + clocks = <&cpu_pdiv>;
> + clock-names = "cpu_pdiv";
> + };
> +
> + cpu_mdiv_ch0: cpu_mdiv_ch0@f04e0000 {
> + compatible = "divider-clock";
Is there a binding for this?
> + #clock-cells = <0>;
> + reg = <0xf04e0000 0x4>;
> + bit-shift = <1>;
> + bit-mask = <0xff>;
> + index-starts-at-one;
> + clocks = <&cpu_ndiv_int>;
> + clock-names = "cpu_ndiv_int";
> + };
> +
> + cpupll: cpupll@0 {
> + #clock-cells = <0>;
> + clock-frequency = <1503000000>;
> + compatible = "fixed-clock";
> + };
> +
> + cpuclkdiv: cpu-clk-div@0 {
Wrong unit address. Should be f03e257c?
> + #clock-cells = <0>;
> + clock-names = "cpupll",
> + "cpu_mdiv_ch0",
> + "cpu_ndiv_int",
> + "sw_scb";
> + clocks = <&cpupll,
> + &cpu_mdiv_ch0,
> + &cpu_ndiv_int,
> + &sw_scb>;
> + compatible = "brcm,brcmstb-cpu-clk-div";
> + reg = <0xf03e257c 0x4>;
> + div-table = <0x00 1>;
> + div-shift-width = <0 5>;
This entire DT design seems wrong. We don't put these sorts of
register level details into DT. There should be a driver that
knows the type of device that is present and how to drive that
hardware.
>From what I can tell there's something like a mux controller at
0xf04e0000 and then there's some sort of divider controller at
0xf03e0000. Perhaps those are two different devices that need
independent drivers? My wild guess is the PLL control is in those
register regions too, but we're not exposing control of them.
That's ok, but don't put the PLL into the DT as a fixed clock.
Just register it from the driver.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] clk: stm32f4: Use CLK_OF_DECLARE_DRIVER initialization method
From: Stephen Boyd @ 2016-12-21 23:34 UTC (permalink / raw)
To: gabriel.fernandez
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Nicolas Pitre, Arnd Bergmann,
daniel.thompson, andrea.merello, radoslaw.pietrzyk, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, kernel, ludovic.barre,
olivier.bideau, amelie.delaunay
In-Reply-To: <1481725348-860-1-git-send-email-gabriel.fernandez@st.com>
On 12/14, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Clock and reset controller use same compatible strings (same IP).
>
> Since commit 989eafd0b609 ("clk: core: Avoid double initialization of
> clocks") the OF core flags clock controllers registered with the
> CLK_OF_DECLARE() macro as OF_POPULATED, so platform devices with the same
> compatible string will not be registered.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
Applied to clk-fixes
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 2/2] clk: hi3660: Clock driver support for Hisilicon hi3660 SoC
From: Stephen Boyd @ 2016-12-21 23:25 UTC (permalink / raw)
To: Zhangfei Gao
Cc: Rob Herring, Arnd Bergmann, guodong Xu, devicetree,
haojian.zhuang, linux-arm-kernel
In-Reply-To: <1481781493-6188-3-git-send-email-zhangfei.gao@linaro.org>
On 12/15, Zhangfei Gao wrote:
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Add some commit text here?
> diff --git a/drivers/clk/hisilicon/clk-hi3660.c b/drivers/clk/hisilicon/clk-hi3660.c
> new file mode 100644
> index 0000000..42ca47d
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3660.c
> @@ -0,0 +1,601 @@
> +/*
> + * Copyright (c) 2016-2017 Linaro Ltd.
> + * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
> + *
> + * 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 <dt-bindings/clock/hi3660-clock.h>
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
This isn't needed.
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include "clk.h"
> +
[...]
> +
> +static int hi3660_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = pdev->dev.of_node;
> + const struct of_device_id *of_id;
> + enum hi3660_clk_type type;
> +
> + of_id = of_match_device(hi3660_clk_match_table, dev);
> + if (!of_id)
> + return -EINVAL;
> +
> + type = (enum hi3660_clk_type)of_id->data;
Use of_device_get_match_data() instead please.
> +
> + switch (type) {
> + case HI3660_CRGCTRL:
> + hi3660_clk_crgctrl_init(np);
> + break;
> + case HI3660_PCTRL:
> + hi3660_clk_pctrl_init(np);
> + break;
> + case HI3660_PMUCTRL:
> + hi3660_clk_pmuctrl_init(np);
> + break;
> + case HI3660_SCTRL:
> + hi3660_clk_sctrl_init(np);
> + break;
> + case HI3660_IOMCU:
> + hi3660_clk_iomcu_init(np);
> + break;
This "multi-device" driver design is sort of odd. Why not have
different files and struct drivers for the different devices in
the system that are clock controllers? I don't really understand
why we're controlling the devices with one struct driver
instance. Is something shared between the devices?
> + default:
> + break;
> + }
> + return 0;
> +}
[...]
> +
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hi3660-clk");
> +MODULE_DESCRIPTION("HiSilicon Hi3660 Clock Driver");
You can drop these MODULE_* things as they're not going to be
used in builtin only code.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board
From: Maxime Ripard @ 2016-12-21 22:41 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, Zepan, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20161221200235.11617-3-icenowy@aosc.xyz>
[-- Attachment #1.1: Type: text/plain, Size: 632 bytes --]
On Thu, Dec 22, 2016 at 04:02:35AM +0800, Icenowy Zheng wrote:
> Lichee Pi One is a low-cost Allwinner A13-based development board, with
> an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard
> RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO
> headers and two MicroSD card slots (connected to mmc0 and mmc2, both
> bootable).
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: add vendor prefix for Lichee Pi
From: Maxime Ripard @ 2016-12-21 22:40 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, Zepan, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20161221200235.11617-1-icenowy@aosc.xyz>
[-- Attachment #1.1: Type: text/plain, Size: 460 bytes --]
On Thu, Dec 22, 2016 at 04:02:33AM +0800, Icenowy Zheng wrote:
> Lichee Pi is a new "Pi"-named development board series.
>
> Currently available device, Lichee Pi One, is by only one person as
> night job, so the device series name is chosen to be the vendor prefix.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: sun5i: add a pinctrl node for 4bit mmc2
From: Maxime Ripard @ 2016-12-21 22:40 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, Zepan, linux-kernel, Chen-Yu Tsai, Rob Herring,
linux-arm-kernel
In-Reply-To: <20161221200235.11617-2-icenowy@aosc.xyz>
[-- Attachment #1.1: Type: text/plain, Size: 327 bytes --]
On Thu, Dec 22, 2016 at 04:02:34AM +0800, Icenowy Zheng wrote:
> Some board only use 4bit mode of mmc2.
>
> Add a pinctrl node for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] power: supply: bq24735: bring down the noise level
From: Peter Rosin @ 2016-12-21 21:29 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Sebastian Reichel, Rob Herring, Mark Rutland,
linux-pm, devicetree
In-Reply-To: <1482355793-16190-1-git-send-email-peda@axentia.se>
If there is no ti,ac-detect-gpios configured, it is normal to
have failed reads of the options register. So, hold back on the
log spamming.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/power/supply/bq24735-charger.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
index d8be81203837..eb0145380def 100644
--- a/drivers/power/supply/bq24735-charger.c
+++ b/drivers/power/supply/bq24735-charger.c
@@ -192,7 +192,7 @@ static bool bq24735_charger_is_present(struct bq24735 *charger)
ac = bq24735_read_word(charger->client, BQ24735_CHG_OPT);
if (ac < 0) {
- dev_err(&charger->client->dev,
+ dev_dbg(&charger->client->dev,
"Failed to read charger options : %d\n",
ac);
return false;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] power: supply: bq24735: allow polling even if there is no ac-detect gpio
From: Peter Rosin @ 2016-12-21 21:29 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Sebastian Reichel, Rob Herring, Mark Rutland,
linux-pm, devicetree
In-Reply-To: <1482355793-16190-1-git-send-email-peda@axentia.se>
It is possible to verify AC adapter presence via a register read, without
any physical connection to the ACOK pin on the charger. Allow this.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
Documentation/devicetree/bindings/power/supply/ti,bq24735.txt | 4 ++--
drivers/power/supply/bq24735-charger.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
index efc2c6a78661..de45e1a2a4d9 100644
--- a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
+++ b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
@@ -27,8 +27,8 @@ Optional properties :
- ti,external-control : Indicates that the charger is configured externally
and that the host should not attempt to enable/disable charging or set the
charge voltage/current.
- - poll-interval : In case 'interrupts' is not specified, poll AC presence
- on the ti,ac-detect-gpios GPIO with this interval (milliseconds).
+ - poll-interval : In case 'interrupts' is not specified, poll AC adapter
+ presence with this interval (milliseconds).
Example:
diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
index 4f6275e5cf1c..d8be81203837 100644
--- a/drivers/power/supply/bq24735-charger.c
+++ b/drivers/power/supply/bq24735-charger.c
@@ -468,7 +468,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
client->irq, ret);
return ret;
}
- } else if (charger->status_gpio) {
+ } else {
ret = device_property_read_u32(&client->dev, "poll-interval",
&charger->poll_interval);
if (ret)
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] power: supply: bq24735: poll register if no ac-detect gpio
From: Peter Rosin @ 2016-12-21 21:29 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Sebastian Reichel, Rob Herring, Mark Rutland,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi!
My patch [1] "power: supply: bq24735-charger: allow chargers to share the
ac-detect gpio" is perhaps a bit hard to digest. And while I still think
some way of sharing the ac-detect gpio is worthwhile, I thought of another
way to solve the problem at hand. Instead of polling a shared gpio, it's
as simple as polling the chip for what it is outputting on the ACOK pin.
And the code is already there! It just needs a tweak to allow this mode of
operation.
This appears to work just fine for me, and the difference is in the noise
since my shared gpio pin happens to be on an expander on the i2c bus, so
I end up with i2c traffic for each poll either way.
Cheers,
peda
[1] https://lkml.org/lkml/2016/12/13/786
Peter Rosin (2):
power: supply: bq24735: allow polling even if there is no ac-detect
gpio
power: supply: bq24735: bring down the noise level
Documentation/devicetree/bindings/power/supply/ti,bq24735.txt | 4 ++--
drivers/power/supply/bq24735-charger.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup
From: Rajat Jain @ 2016-12-21 20:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev, devicetree, linux-bluetooth, Brian Norris, linux-kernel
Cc: Rajat Jain, rajatxjain
In-Reply-To: <1482352432-38302-1-git-send-email-rajatja@google.com>
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
---
v4: same as v3
v3: * remove the Marvell specific id table and check
* Add reference to marvell-bt-8xxx.txt in btusb.txt
* Add "Reviewed-by" and "Acked-by"
v2: Fix the binding document to specify to use "wakeup" interrupt-name
Documentation/devicetree/bindings/net/btusb.txt | 3 ++
.../{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} | 46 +++++++++++++++----
drivers/bluetooth/btusb.c | 51 ++++++++++++++++++++++
3 files changed, 92 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/net/{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} (50%)
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
index 2c0355c..01fa2d4 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -10,6 +10,9 @@ Required properties:
"usb1286,204e" (Marvell 8997)
+Also, vendors that use btusb may have device additional properties, e.g:
+Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
+
Optional properties:
- interrupt-parent: phandle of the parent interrupt controller
diff --git a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
similarity index 50%
rename from Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
index 6a9a63c..9be1059 100644
--- a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
@@ -1,16 +1,21 @@
-Marvell 8897/8997 (sd8897/sd8997) bluetooth SDIO devices
+Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO or USB based)
------
+The 8997 devices supports multiple interfaces. When used on SDIO interfaces,
+the btmrvl driver is used and when used on USB interface, the btusb driver is
+used.
Required properties:
- compatible : should be one of the following:
- * "marvell,sd8897-bt"
- * "marvell,sd8997-bt"
+ * "marvell,sd8897-bt" (for SDIO)
+ * "marvell,sd8997-bt" (for SDIO)
+ * "usb1286,204e" (for USB)
Optional properties:
- marvell,cal-data: Calibration data downloaded to the device during
initialization. This is an array of 28 values(u8).
+ This is only applicable to SDIO devices.
- marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
firmware will use the pin to wakeup host system (u16).
@@ -18,10 +23,15 @@ Optional properties:
platform. The value will be configured to firmware. This
is needed to work chip's sleep feature as expected (u16).
- interrupt-parent: phandle of the parent interrupt controller
- - interrupts : interrupt pin number to the cpu. Driver will request an irq based
- on this interrupt number. During system suspend, the irq will be
- enabled so that the bluetooth chip can wakeup host platform under
- certain condition. During system resume, the irq will be disabled
+ - interrupt-names: Used only for USB based devices (See below)
+ - interrupts : specifies the interrupt pin number to the cpu. For SDIO, the
+ driver will use the first interrupt specified in the interrupt
+ array. For USB based devices, the driver will use the interrupt
+ named "wakeup" from the interrupt-names and interrupt arrays.
+ The driver will request an irq based on this interrupt number.
+ During system suspend, the irq will be enabled so that the
+ bluetooth chip can wakeup host platform under certain
+ conditions. During system resume, the irq will be disabled
to make sure unnecessary interrupt is not received.
Example:
@@ -29,7 +39,9 @@ Example:
IRQ pin 119 is used as system wakeup source interrupt.
wakeup pin 13 and gap 100ms are configured so that firmware can wakeup host
using this device side pin and wakeup latency.
-calibration data is also available in below example.
+
+Example for SDIO device follows (calibration data is also available in
+below example).
&mmc3 {
status = "okay";
@@ -54,3 +66,21 @@ calibration data is also available in below example.
marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
};
};
+
+Example for USB device:
+
+&usb_host1_ohci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupt-names = "wakeup";
+ interrupts = <119 IRQ_TYPE_LEVEL_LOW>;
+ marvell,wakeup-pin = /bits/ 16 <0x0d>;
+ marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2b45f1c..91dcd8a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2343,6 +2343,50 @@ static int btusb_shutdown_intel(struct hci_dev *hdev)
return 0;
}
+#ifdef CONFIG_PM
+/* Configure an out-of-band gpio as wake-up pin, if specified in device tree */
+static int marvell_config_oob_wake(struct hci_dev *hdev)
+{
+ struct sk_buff *skb;
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ u16 pin, gap, opcode;
+ int ret;
+ u8 cmd[5];
+
+ /* Move on if no wakeup pin specified */
+ if (of_property_read_u16(dev->of_node, "marvell,wakeup-pin", &pin) ||
+ of_property_read_u16(dev->of_node, "marvell,wakeup-gap-ms", &gap))
+ return 0;
+
+ /* Vendor specific command to configure a GPIO as wake-up pin */
+ opcode = hci_opcode_pack(0x3F, 0x59);
+ cmd[0] = opcode & 0xFF;
+ cmd[1] = opcode >> 8;
+ cmd[2] = 2; /* length of parameters that follow */
+ cmd[3] = pin;
+ cmd[4] = gap; /* time in ms, for which wakeup pin should be asserted */
+
+ skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
+ if (!skb) {
+ bt_dev_err(hdev, "%s: No memory\n", __func__);
+ return -ENOMEM;
+ }
+
+ memcpy(skb_put(skb, sizeof(cmd)), cmd, sizeof(cmd));
+ hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
+
+ ret = btusb_send_frame(hdev, skb);
+ if (ret) {
+ bt_dev_err(hdev, "%s: configuration failed\n", __func__);
+ kfree_skb(skb);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
static int btusb_set_bdaddr_marvell(struct hci_dev *hdev,
const bdaddr_t *bdaddr)
{
@@ -2917,6 +2961,13 @@ static int btusb_probe(struct usb_interface *intf,
err = btusb_config_oob_wake(hdev);
if (err)
goto out_free_dev;
+
+ /* Marvell devices may need a specific chip configuration */
+ if (id->driver_info & BTUSB_MARVELL && data->oob_wake_irq) {
+ err = marvell_config_oob_wake(hdev);
+ if (err)
+ goto out_free_dev;
+ }
#endif
if (id->driver_info & BTUSB_CW6622)
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v4 2/3] Bluetooth: btusb: Add out-of-band wakeup support
From: Rajat Jain @ 2016-12-21 20:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rajat Jain, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1482352432-38302-1-git-send-email-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that
can be connected to a gpio on the CPU side, and can be used to wakeup
the host out-of-band. This can be useful in situations where the
in-band wakeup is not possible or not preferable (e.g. the in-band
wakeup may require the USB host controller to remain active, and
hence consuming more system power during system sleep).
The oob gpio interrupt to be used for wakeup on the CPU side, is
read from the device tree node, (using standard interrupt descriptors).
A devcie tree binding document is also added for the driver. The
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
v4: Move the set_bit(BTUSB_OOB_WAKE_DISABLED,..) call to the beginning of
btusb_config_oob_wake() - caught by Brian.
v3: Add Brian's "Reviewed-by"
v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
* Leave it on device tree to specify IRQ flags (level /edge triggered)
* Mark the device as non wakeable on exit.
Documentation/devicetree/bindings/net/btusb.txt | 40 ++++++++++++
drivers/bluetooth/btusb.c | 84 +++++++++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/btusb.txt
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
new file mode 100644
index 0000000..2c0355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -0,0 +1,40 @@
+Generic Bluetooth controller over USB (btusb driver)
+---------------------------------------------------
+
+Required properties:
+
+ - compatible : should comply with the format "usbVID,PID" specified in
+ Documentation/devicetree/bindings/usb/usb-device.txt
+ At the time of writing, the only OF supported devices
+ (more may be added later) are:
+
+ "usb1286,204e" (Marvell 8997)
+
+Optional properties:
+
+ - interrupt-parent: phandle of the parent interrupt controller
+ - interrupt-names: (see below)
+ - interrupts : The interrupt specified by the name "wakeup" is the interrupt
+ that shall be used for out-of-band wake-on-bt. Driver will
+ request this interrupt for wakeup. During system suspend, the
+ irq will be enabled so that the bluetooth chip can wakeup host
+ platform out of band. During system resume, the irq will be
+ disabled to make sure unnecessary interrupt is not received.
+
+Example:
+
+Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
+
+&usb_host1_ehci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupt-name = "wakeup";
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ce22cef..2b45f1c 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -24,6 +24,8 @@
#include <linux/module.h>
#include <linux/usb.h>
#include <linux/firmware.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <asm/unaligned.h>
#include <net/bluetooth/bluetooth.h>
@@ -369,6 +371,7 @@ static const struct usb_device_id blacklist_table[] = {
#define BTUSB_BOOTING 9
#define BTUSB_RESET_RESUME 10
#define BTUSB_DIAG_RUNNING 11
+#define BTUSB_OOB_WAKE_DISABLED 12
struct btusb_data {
struct hci_dev *hdev;
@@ -416,6 +419,8 @@ struct btusb_data {
int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
int (*setup_on_usb)(struct hci_dev *hdev);
+
+ int oob_wake_irq; /* irq for out-of-band wake-on-bt */
};
static inline void btusb_free_frags(struct btusb_data *data)
@@ -2728,6 +2733,65 @@ static int btusb_bcm_set_diag(struct hci_dev *hdev, bool enable)
}
#endif
+#ifdef CONFIG_PM
+static irqreturn_t btusb_oob_wake_handler(int irq, void *priv)
+{
+ struct btusb_data *data = priv;
+
+ /* Disable only if not already disabled (keep it balanced) */
+ if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
+ disable_irq_nosync(irq);
+ disable_irq_wake(irq);
+ }
+ pm_wakeup_event(&data->udev->dev, 0);
+ return IRQ_HANDLED;
+}
+
+static const struct of_device_id btusb_match_table[] = {
+ { .compatible = "usb1286,204e" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, btusb_match_table);
+
+/* Use an oob wakeup pin? */
+static int btusb_config_oob_wake(struct hci_dev *hdev)
+{
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ int irq, ret;
+
+ set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
+
+ if (!of_match_device(btusb_match_table, dev))
+ return 0;
+
+ /* Move on if no IRQ specified */
+ irq = of_irq_get_byname(dev->of_node, "wakeup");
+ if (irq <= 0) {
+ bt_dev_dbg(hdev, "%s: no OOB Wakeup IRQ in DT", __func__);
+ return 0;
+ }
+
+ ret = devm_request_irq(&hdev->dev, irq, btusb_oob_wake_handler,
+ 0, "OOB Wake-on-BT", data);
+ if (ret) {
+ bt_dev_err(hdev, "%s: IRQ request failed", __func__);
+ return ret;
+ }
+
+ ret = device_init_wakeup(dev, true);
+ if (ret) {
+ bt_dev_err(hdev, "%s: failed to init_wakeup\n", __func__);
+ return ret;
+ }
+
+ data->oob_wake_irq = irq;
+ disable_irq(irq);
+ bt_dev_info(hdev, "OOB Wake-on-BT configured at IRQ %u\n", irq);
+ return 0;
+}
+#endif
+
static int btusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -2849,6 +2913,11 @@ static int btusb_probe(struct usb_interface *intf,
hdev->send = btusb_send_frame;
hdev->notify = btusb_notify;
+#ifdef CONFIG_PM
+ err = btusb_config_oob_wake(hdev);
+ if (err)
+ goto out_free_dev;
+#endif
if (id->driver_info & BTUSB_CW6622)
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
@@ -3061,6 +3130,9 @@ static void btusb_disconnect(struct usb_interface *intf)
usb_driver_release_interface(&btusb_driver, data->isoc);
}
+ if (data->oob_wake_irq)
+ device_init_wakeup(&data->udev->dev, false);
+
hci_free_dev(hdev);
}
@@ -3089,6 +3161,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
btusb_stop_traffic(data);
usb_kill_anchored_urbs(&data->tx_anchor);
+ if (data->oob_wake_irq && device_may_wakeup(&data->udev->dev)) {
+ clear_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
+ enable_irq_wake(data->oob_wake_irq);
+ enable_irq(data->oob_wake_irq);
+ }
+
/* Optionally request a device reset on resume, but only when
* wakeups are disabled. If wakeups are enabled we assume the
* device will stay powered up throughout suspend.
@@ -3126,6 +3204,12 @@ static int btusb_resume(struct usb_interface *intf)
if (--data->suspend_count)
return 0;
+ /* Disable only if not already disabled (keep it balanced) */
+ if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
+ disable_irq(data->oob_wake_irq);
+ disable_irq_wake(data->oob_wake_irq);
+ }
+
if (!test_bit(HCI_RUNNING, &hdev->flags))
goto done;
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/3] Bluetooth: btusb: Use an error label for error paths
From: Rajat Jain @ 2016-12-21 20:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rajat Jain, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
v4: same as v3
v3: Added Brian's "Reviewed-by"
v2: same as v1
drivers/bluetooth/btusb.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2f633df..ce22cef 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2991,18 +2991,15 @@ static int btusb_probe(struct usb_interface *intf,
err = usb_set_interface(data->udev, 0, 0);
if (err < 0) {
BT_ERR("failed to set interface 0, alt 0 %d", err);
- hci_free_dev(hdev);
- return err;
+ goto out_free_dev;
}
}
if (data->isoc) {
err = usb_driver_claim_interface(&btusb_driver,
data->isoc, data);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
}
#ifdef CONFIG_BT_HCIBTUSB_BCM
@@ -3016,14 +3013,16 @@ static int btusb_probe(struct usb_interface *intf,
#endif
err = hci_register_dev(hdev);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
usb_set_intfdata(intf, data);
return 0;
+
+out_free_dev:
+ hci_free_dev(hdev);
+ return err;
}
static void btusb_disconnect(struct usb_interface *intf)
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: sun5i: add support for Lichee Pi One board
From: Icenowy Zheng @ 2016-12-21 20:02 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Zepan
Cc: devicetree, linux-kernel, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20161221200235.11617-1-icenowy@aosc.xyz>
Lichee Pi One is a low-cost Allwinner A13-based development board, with
an AXP209 PMU, a USB2.0 OTG port, a USB2.0 host port (or an onboard
RTL8723BU Wi-Fi card), optional headers for LCD and CSI, two GPIO
headers and two MicroSD card slots (connected to mmc0 and mmc2, both
bootable).
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun5i-a13-licheepi-one.dts | 224 +++++++++++++++++++++++++++
2 files changed, 225 insertions(+)
create mode 100644 arch/arm/boot/dts/sun5i-a13-licheepi-one.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb557b6..5902d4ca7138 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -781,6 +781,7 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a13-empire-electronix-m712.dtb \
sun5i-a13-hsg-h702.dtb \
sun5i-a13-inet-98v-rev2.dtb \
+ sun5i-a13-licheepi-one.dtb \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
sun5i-a13-q8-tablet.dtb \
diff --git a/arch/arm/boot/dts/sun5i-a13-licheepi-one.dts b/arch/arm/boot/dts/sun5i-a13-licheepi-one.dts
new file mode 100644
index 000000000000..566cda91a66b
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-a13-licheepi-one.dts
@@ -0,0 +1,224 @@
+/*
+ * Copyright 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on sun5i-a13-olinuxino.dts, which is
+ * Copyright 2012 Maxime Ripard <maxime.ripard@free-electrons.com>
+ * Copyright 2013 Hans de Goede <hdegoede@redhat.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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 file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Lichee Pi One";
+ compatible = "licheepi,licheepi-one", "allwinner,sun5i-a13";
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ red {
+ label ="licheepi:red:usr";
+ gpios = <&pio 2 5 GPIO_ACTIVE_LOW>;
+ };
+
+ green {
+ label ="licheepi:green:usr";
+ gpios = <&pio 2 19 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
+ blue {
+ label ="licheepi:blue:usr";
+ gpios = <&pio 2 4 GPIO_ACTIVE_LOW>;
+ };
+
+ };
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupts = <0>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "disabled";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "disabled";
+};
+
+&lradc {
+ vref-supply = <®_ldo2>;
+ status = "okay";
+
+ button@984 {
+ label = "Home";
+ linux,code = <KEY_HOMEPAGE>;
+ channel = <0>;
+ voltage = <984126>;
+ };
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ broken-cd;
+ status = "okay";
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_4bit_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ broken-cd;
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+#include "axp209.dtsi"
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+®_ldo3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "csi-1.8v";
+};
+
+®_ldo4 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "csi-2.8v";
+};
+
+®_usb0_vbus {
+ gpio = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins_b>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ usb0_id_det-gpio = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
+ usb0_vbus_det-gpio = <&pio 6 1 GPIO_ACTIVE_HIGH>; /* PG1 */
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_vcc5v0>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: sun5i: add a pinctrl node for 4bit mmc2
From: Icenowy Zheng @ 2016-12-21 20:02 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Zepan
Cc: devicetree, linux-kernel, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20161221200235.11617-1-icenowy@aosc.xyz>
Some board only use 4bit mode of mmc2.
Add a pinctrl node for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun5i.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 54170147040f..c058d37d5433 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -594,6 +594,14 @@
bias-pull-up;
};
+ mmc2_4bit_pins_a: mmc2-4bit@0 {
+ pins = "PC6", "PC7", "PC8", "PC9",
+ "PC10", "PC11";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
spi2_pins_a: spi2@0 {
pins = "PE1", "PE2", "PE3";
function = "spi2";
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: add vendor prefix for Lichee Pi
From: Icenowy Zheng @ 2016-12-21 20:02 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Zepan
Cc: devicetree, linux-kernel, linux-arm-kernel, Icenowy Zheng
Lichee Pi is a new "Pi"-named development board series.
Currently available device, Lichee Pi One, is by only one person as
night job, so the device series name is chosen to be the vendor prefix.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e7f5d1..4ec84b7a3c56 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -161,6 +161,7 @@ lacie LaCie
lantiq Lantiq Semiconductor
lenovo Lenovo Group Ltd.
lg LG Corporation
+licheepi Lichee Pi
linux Linux-specific binding
lltc Linear Technology Corporation
lsi LSI Corp. (LSI Logic)
--
2.11.0
^ permalink raw reply related
* [PATCH v5 3/3] mtd: spi-nor: bindings for the Aspeed memory controllers
From: Cédric Le Goater @ 2016-12-21 16:57 UTC (permalink / raw)
To: linux-mtd
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Marek Vasut, Rob Herring, Joel Stanley, Cyrille Pitchen,
Brian Norris, David Woodhouse, Cédric Le Goater
In-Reply-To: <1482339439-26402-1-git-send-email-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/mtd/aspeed-smc.txt | 51 ++++++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/aspeed-smc.txt
diff --git a/Documentation/devicetree/bindings/mtd/aspeed-smc.txt b/Documentation/devicetree/bindings/mtd/aspeed-smc.txt
new file mode 100644
index 000000000000..49f6528ef547
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/aspeed-smc.txt
@@ -0,0 +1,51 @@
+* Aspeed Firmware Memory controller
+* Aspeed SPI Flash Memory Controller
+
+The Firmware Memory Controller in the Aspeed AST2500 SoC supports
+three chip selects, two of which are always of SPI type and the third
+can be SPI or NOR type flash. These bindings only describe SPI.
+
+The two SPI flash memory controllers in the AST2500 each support two
+chip selects.
+
+Required properties:
+ - compatible : Should be one of
+ "aspeed,ast2400-fmc" for the AST2400 Firmware Memory Controller
+ "aspeed,ast2400-spi" for the AST2400 SPI Flash memory Controller
+ "aspeed,ast2500-fmc" for the AST2500 Firmware Memory Controller
+ "aspeed,ast2500-spi" for the AST2500 SPI flash memory controllers
+
+ - reg : the first contains the control register location and length,
+ the second contains the memory window mapping address and length
+ - #address-cells : must be 1 corresponding to chip select child binding
+ - #size-cells : must be 0 corresponding to chip select child binding
+
+Optional properties:
+ - interrupts : Should contain the interrupt for the dma device if an
+ FMC
+
+The child nodes are the SPI flash modules which must have a compatible
+property as specified in bindings/mtd/jedec,spi-nor.txt
+
+Optionally, the child node can contain properties for SPI mode (may be
+ignored):
+ - spi-max-frequency - max frequency of spi bus
+
+
+Example:
+fmc: fmc@1e620000 {
+ compatible = "aspeed,ast2500-fmc";
+ reg = < 0x1e620000 0x94
+ 0x20000000 0x02000000 >;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <19>;
+ flash@0 {
+ reg = < 0 >;
+ compatible = "jedec,spi-nor";
+ /* spi-max-frequency = <>; */
+ /* m25p,fast-read; */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
--
2.7.4
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* [PATCH v5 2/3] mtd: aspeed: add memory controllers for the Aspeed AST2400 SoC
From: Cédric Le Goater @ 2016-12-21 16:57 UTC (permalink / raw)
To: linux-mtd
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Marek Vasut, Rob Herring, Joel Stanley, Cyrille Pitchen,
Brian Norris, David Woodhouse, Cédric Le Goater
In-Reply-To: <1482339439-26402-1-git-send-email-clg@kaod.org>
This driver adds mtd support for the Aspeed AST2400 SoC static memory
controllers:
* New Static Memory Controller (referred as FMC)
. BMC firmware
. AST2500 compatible register set
. 5 chip select pins (CE0 ∼ CE4)
. supports NOR flash, NAND flash and SPI flash memory.
* SPI Flash Controller (SPI)
. host Firmware
. slightly different register set, between AST2500 and the legacy
controller
. supports SPI flash memory
. 1 chip select pin (CE0)
The legacy static memory controller (referred as SMC) is not
supported, as well as types other than SPI.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
---
drivers/mtd/spi-nor/Kconfig | 2 +-
drivers/mtd/spi-nor/aspeed-smc.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 42168e9d6097..7b00a0cb9ed8 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -35,7 +35,7 @@ config SPI_ASPEED_SMC
depends on HAS_IOMEM && OF
help
This enables support for the Firmware Memory controller (FMC)
- in the Aspeed AST2500 SoC when attached to SPI NOR chips,
+ in the Aspeed AST2500/AST2400 SoCs when attached to SPI NOR chips,
and support for the SPI flash memory controller (SPI) for
the host firmware. The implementation only supports SPI NOR.
diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
index f1e18bea9888..6bb4c7d1788c 100644
--- a/drivers/mtd/spi-nor/aspeed-smc.c
+++ b/drivers/mtd/spi-nor/aspeed-smc.c
@@ -44,8 +44,27 @@ struct aspeed_smc_info {
void (*set_4b)(struct aspeed_smc_chip *chip);
};
+static void aspeed_smc_chip_set_4b_spi_2400(struct aspeed_smc_chip *chip);
static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip);
+static const struct aspeed_smc_info fmc_2400_info = {
+ .maxsize = 64 * 1024 * 1024,
+ .nce = 5,
+ .hastype = true,
+ .we0 = 16,
+ .ctl0 = 0x10,
+ .set_4b = aspeed_smc_chip_set_4b,
+};
+
+static const struct aspeed_smc_info spi_2400_info = {
+ .maxsize = 64 * 1024 * 1024,
+ .nce = 1,
+ .hastype = false,
+ .we0 = 0,
+ .ctl0 = 0x04,
+ .set_4b = aspeed_smc_chip_set_4b_spi_2400,
+};
+
static const struct aspeed_smc_info fmc_2500_info = {
.maxsize = 256 * 1024 * 1024,
.nce = 3,
@@ -135,6 +154,7 @@ struct aspeed_smc_controller {
#define CONTROL_IO_DUMMY_HI BIT(14)
#define CONTROL_IO_DUMMY_HI_SHIFT 14
#define CONTROL_CLK_DIV4 BIT(13) /* others */
+#define CONTROL_IO_ADDRESS_4B BIT(13) /* AST2400 SPI */
#define CONTROL_RW_MERGE BIT(12)
#define CONTROL_IO_DUMMY_LO_SHIFT 6
#define CONTROL_IO_DUMMY_LO GENMASK(7, \
@@ -397,6 +417,8 @@ static int aspeed_smc_remove(struct platform_device *dev)
}
static const struct of_device_id aspeed_smc_matches[] = {
+ { .compatible = "aspeed,ast2400-fmc", .data = &fmc_2400_info },
+ { .compatible = "aspeed,ast2400-spi", .data = &spi_2400_info },
{ .compatible = "aspeed,ast2500-fmc", .data = &fmc_2500_info },
{ .compatible = "aspeed,ast2500-spi", .data = &spi_2500_info },
{ }
@@ -470,6 +492,17 @@ static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip)
}
}
+/*
+ * The AST2400 SPI flash controller does not have a CE Control
+ * register. It uses the CE0 control register to set 4Byte mode at the
+ * controller level.
+ */
+static void aspeed_smc_chip_set_4b_spi_2400(struct aspeed_smc_chip *chip)
+{
+ chip->ctl_val[smc_base] |= CONTROL_IO_ADDRESS_4B;
+ chip->ctl_val[smc_read] |= CONTROL_IO_ADDRESS_4B;
+}
+
static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
struct resource *res)
{
--
2.7.4
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* [PATCH v5 1/3] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Cédric Le Goater @ 2016-12-21 16:57 UTC (permalink / raw)
To: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Joel Stanley, Cédric Le Goater
In-Reply-To: <1482339439-26402-1-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
This driver adds mtd support for the Aspeed AST2500 SoC static memory
controllers :
* Firmware SPI Memory Controller (FMC)
. BMC firmware
. 3 chip select pins (CE0 ~ CE2)
. supports SPI type flash memory (CE0-CE1)
. CE2 can be of NOR type flash but this is not supported by the
driver
* SPI Flash Controller (SPI1 and SPI2)
. host firmware
. 2 chip select pins (CE0 ~ CE1)
. supports SPI type flash memory
Each controller has a memory range on which it maps its flash module
slaves. Each slave is assigned a memory window for its mapping that
can be changed at bootime with the Segment Address Register.
Each SPI flash slave can then be accessed in two modes: Command and
User. When in User mode, accesses to the memory segment of the slaves
are translated in SPI transfers. When in Command mode, the HW
generates the SPI commands automatically and the memory segment is
accessed as if doing a MMIO.
Currently, only the User mode is supported. Command mode needs a
little more work to check that the memory window on the AHB bus fits
the module size.
Based on previous work from Milton D. Miller II <miltonm-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
Reviewed-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
Reviewed-by: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changes since v4:
- improved IO routines with Cyrille's suggestions
- added dummy bytes hanling for fast read commands
- removed the 'label' property from jedec,spi-nor. Needs more
discussion.
Changes since v3:
- reworked IO routines to use io{read,write}32_rep
- changed config option to SPI_ASPEED_SMC
- fixed aspeed_smc_chip_setup_init() returned value
- merged the use of the "label" property"
drivers/mtd/spi-nor/Kconfig | 10 +
drivers/mtd/spi-nor/Makefile | 1 +
drivers/mtd/spi-nor/aspeed-smc.c | 726 +++++++++++++++++++++++++++++++++++++++
3 files changed, 737 insertions(+)
create mode 100644 drivers/mtd/spi-nor/aspeed-smc.c
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 4a682ee0f632..42168e9d6097 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -29,6 +29,16 @@ config MTD_SPI_NOR_USE_4K_SECTORS
Please note that some tools/drivers/filesystems may not work with
4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
+config SPI_ASPEED_SMC
+ tristate "Aspeed flash controllers in SPI mode"
+ depends on ARCH_ASPEED || COMPILE_TEST
+ depends on HAS_IOMEM && OF
+ help
+ This enables support for the Firmware Memory controller (FMC)
+ in the Aspeed AST2500 SoC when attached to SPI NOR chips,
+ and support for the SPI flash memory controller (SPI) for
+ the host firmware. The implementation only supports SPI NOR.
+
config SPI_ATMEL_QUADSPI
tristate "Atmel Quad SPI Controller"
depends on ARCH_AT91 || (ARM && COMPILE_TEST)
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 121695e83542..6ff64bc7fa0e 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_MTD_SPI_NOR) += spi-nor.o
+obj-$(CONFIG_SPI_ASPEED_SMC) += aspeed-smc.o
obj-$(CONFIG_SPI_ATMEL_QUADSPI) += atmel-quadspi.o
obj-$(CONFIG_SPI_CADENCE_QUADSPI) += cadence-quadspi.o
obj-$(CONFIG_SPI_FSL_QUADSPI) += fsl-quadspi.o
diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
new file mode 100644
index 000000000000..f1e18bea9888
--- /dev/null
+++ b/drivers/mtd/spi-nor/aspeed-smc.c
@@ -0,0 +1,726 @@
+/*
+ * ASPEED Static Memory Controller driver
+ *
+ * Copyright (c) 2015-2016, IBM 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.
+ */
+
+#include <linux/bug.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/spi-nor.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/sysfs.h>
+
+#define DEVICE_NAME "aspeed-smc"
+
+/*
+ * The driver only support SPI flash
+ */
+enum aspeed_smc_flash_type {
+ smc_type_nor = 0,
+ smc_type_nand = 1,
+ smc_type_spi = 2,
+};
+
+struct aspeed_smc_chip;
+
+struct aspeed_smc_info {
+ u32 maxsize; /* maximum size of chip window */
+ u8 nce; /* number of chip enables */
+ bool hastype; /* flash type field exists in config reg */
+ u8 we0; /* shift for write enable bit for CE0 */
+ u8 ctl0; /* offset in regs of ctl for CE0 */
+
+ void (*set_4b)(struct aspeed_smc_chip *chip);
+};
+
+static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip);
+
+static const struct aspeed_smc_info fmc_2500_info = {
+ .maxsize = 256 * 1024 * 1024,
+ .nce = 3,
+ .hastype = true,
+ .we0 = 16,
+ .ctl0 = 0x10,
+ .set_4b = aspeed_smc_chip_set_4b,
+};
+
+static const struct aspeed_smc_info spi_2500_info = {
+ .maxsize = 128 * 1024 * 1024,
+ .nce = 2,
+ .hastype = false,
+ .we0 = 16,
+ .ctl0 = 0x10,
+ .set_4b = aspeed_smc_chip_set_4b,
+};
+
+enum aspeed_smc_ctl_reg_value {
+ smc_base, /* base value without mode for other commands */
+ smc_read, /* command reg for (maybe fast) reads */
+ smc_write, /* command reg for writes */
+ smc_max,
+};
+
+struct aspeed_smc_controller;
+
+struct aspeed_smc_chip {
+ int cs;
+ struct aspeed_smc_controller *controller;
+ void __iomem *ctl; /* control register */
+ void __iomem *ahb_base; /* base of chip window */
+ u32 ctl_val[smc_max]; /* control settings */
+ enum aspeed_smc_flash_type type; /* what type of flash */
+ struct spi_nor nor;
+};
+
+struct aspeed_smc_controller {
+ struct device *dev;
+
+ struct mutex mutex; /* controller access mutex */
+ const struct aspeed_smc_info *info; /* type info of controller */
+ void __iomem *regs; /* controller registers */
+ void __iomem *ahb_base; /* per-chip windows resource */
+
+ struct aspeed_smc_chip *chips[0]; /* pointers to attached chips */
+};
+
+/*
+ * SPI Flash Configuration Register (AST2500 SPI)
+ * or
+ * Type setting Register (AST2500 FMC).
+ * CE0 and CE1 can only be of type SPI. CE2 can be of type NOR but the
+ * driver does not support it.
+ */
+#define CONFIG_REG 0x0
+#define CONFIG_DISABLE_LEGACY BIT(31) /* 1 */
+
+#define CONFIG_CE2_WRITE BIT(18)
+#define CONFIG_CE1_WRITE BIT(17)
+#define CONFIG_CE0_WRITE BIT(16)
+
+#define CONFIG_CE2_TYPE BIT(4) /* AST2500 FMC only */
+#define CONFIG_CE1_TYPE BIT(2) /* AST2500 FMC only */
+#define CONFIG_CE0_TYPE BIT(0) /* AST2500 FMC only */
+
+/*
+ * CE Control Register
+ */
+#define CE_CONTROL_REG 0x4
+
+/*
+ * CEx Control Register
+ */
+#define CONTROL_AAF_MODE BIT(31)
+#define CONTROL_IO_MODE_MASK GENMASK(30, 28)
+#define CONTROL_IO_DUAL_DATA BIT(29)
+#define CONTROL_IO_DUAL_ADDR_DATA (BIT(29) | BIT(28))
+#define CONTROL_IO_QUAD_DATA BIT(30)
+#define CONTROL_IO_QUAD_ADDR_DATA (BIT(30) | BIT(28))
+#define CONTROL_CE_INACTIVE_SHIFT 24
+#define CONTROL_CE_INACTIVE_MASK GENMASK(27, \
+ CONTROL_CE_INACTIVE_SHIFT)
+/* 0 = 16T ... 15 = 1T T=HCLK */
+#define CONTROL_COMMAND_SHIFT 16
+#define CONTROL_DUMMY_COMMAND_OUT BIT(15)
+#define CONTROL_IO_DUMMY_HI BIT(14)
+#define CONTROL_IO_DUMMY_HI_SHIFT 14
+#define CONTROL_CLK_DIV4 BIT(13) /* others */
+#define CONTROL_RW_MERGE BIT(12)
+#define CONTROL_IO_DUMMY_LO_SHIFT 6
+#define CONTROL_IO_DUMMY_LO GENMASK(7, \
+ CONTROL_IO_DUMMY_LO_SHIFT)
+#define CONTROL_IO_DUMMY_MASK (CONTROL_IO_DUMMY_HI | \
+ CONTROL_IO_DUMMY_LO)
+#define CONTROL_IO_DUMMY_SET(dummy) \
+ (((((dummy) >> 2) & 0x1) << CONTROL_IO_DUMMY_HI_SHIFT) | \
+ (((dummy) & 0x3) << CONTROL_IO_DUMMY_LO_SHIFT))
+
+#define CONTROL_CLOCK_FREQ_SEL_SHIFT 8
+#define CONTROL_CLOCK_FREQ_SEL_MASK GENMASK(11, \
+ CONTROL_CLOCK_FREQ_SEL_SHIFT)
+#define CONTROL_LSB_FIRST BIT(5)
+#define CONTROL_CLOCK_MODE_3 BIT(4)
+#define CONTROL_IN_DUAL_DATA BIT(3)
+#define CONTROL_CE_STOP_ACTIVE_CONTROL BIT(2)
+#define CONTROL_COMMAND_MODE_MASK GENMASK(1, 0)
+#define CONTROL_COMMAND_MODE_NORMAL 0
+#define CONTROL_COMMAND_MODE_FREAD 1
+#define CONTROL_COMMAND_MODE_WRITE 2
+#define CONTROL_COMMAND_MODE_USER 3
+
+#define CONTROL_KEEP_MASK \
+ (CONTROL_AAF_MODE | CONTROL_CE_INACTIVE_MASK | CONTROL_CLK_DIV4 | \
+ CONTROL_IO_DUMMY_MASK | CONTROL_CLOCK_FREQ_SEL_MASK | \
+ CONTROL_LSB_FIRST | CONTROL_CLOCK_MODE_3)
+
+/*
+ * The Segment Register uses a 8MB unit to encode the start address
+ * and the end address of the mapping window of a flash SPI slave :
+ *
+ * | byte 1 | byte 2 | byte 3 | byte 4 |
+ * +--------+--------+--------+--------+
+ * | end | start | 0 | 0 |
+ */
+#define SEGMENT_ADDR_REG0 0x30
+#define SEGMENT_ADDR_START(_r) ((((_r) >> 16) & 0xFF) << 23)
+#define SEGMENT_ADDR_END(_r) ((((_r) >> 24) & 0xFF) << 23)
+
+/*
+ * In user mode all data bytes read or written to the chip decode address
+ * range are transferred to or from the SPI bus. The range is treated as a
+ * fifo of arbitratry 1, 2, or 4 byte width but each write has to be aligned
+ * to its size. The address within the multiple 8kB range is ignored when
+ * sending bytes to the SPI bus.
+ *
+ * On the arm architecture, as of Linux version 4.3, memcpy_fromio and
+ * memcpy_toio on little endian targets use the optimized memcpy routines
+ * that were designed for well behavied memory storage. These routines
+ * have a stutter if the source and destination are not both word aligned,
+ * once with a duplicate access to the source after aligning to the
+ * destination to a word boundary, and again with a duplicate access to
+ * the source when the final byte count is not word aligned.
+ *
+ * When writing or reading the fifo this stutter discards data or sends
+ * too much data to the fifo and can not be used by this driver.
+ *
+ * While the low level io string routines that implement the insl family do
+ * the desired accesses and memory increments, the cross architecture io
+ * macros make them essentially impossible to use on a memory mapped address
+ * instead of a a token from the call to iomap of an io port.
+ *
+ * These fifo routines use readl and friends to a constant io port and update
+ * the memory buffer pointer and count via explicit code. The final updates
+ * to len are optimistically suppressed.
+ */
+static int aspeed_smc_read_from_ahb(void *buf, const void __iomem *src,
+ size_t len)
+{
+ size_t offset = 0;
+
+ if (IS_ALIGNED((uintptr_t)src, sizeof(uintptr_t)) &&
+ IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t))) {
+ ioread32_rep(src, buf, len >> 2);
+ offset = len & ~0x3;
+ len -= offset;
+ }
+ ioread8_rep(src, (u8 *)buf + offset, len);
+ return 0;
+}
+
+static int aspeed_smc_write_to_ahb(void __iomem *dst, const void *buf,
+ size_t len)
+{
+ size_t offset = 0;
+
+ if (IS_ALIGNED((uintptr_t)dst, sizeof(uintptr_t)) &&
+ IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t))) {
+ iowrite32_rep(dst, buf, len >> 2);
+ offset = len & ~0x3;
+ len -= offset;
+ }
+ iowrite8_rep(dst, (const u8 *)buf + offset, len);
+ return 0;
+}
+
+static inline u32 aspeed_smc_chip_write_bit(struct aspeed_smc_chip *chip)
+{
+ return BIT(chip->controller->info->we0 + chip->cs);
+}
+
+static void aspeed_smc_chip_check_config(struct aspeed_smc_chip *chip)
+{
+ struct aspeed_smc_controller *controller = chip->controller;
+ u32 reg;
+
+ reg = readl(controller->regs + CONFIG_REG);
+
+ if (reg & aspeed_smc_chip_write_bit(chip))
+ return;
+
+ dev_dbg(controller->dev, "config write is not set ! @%p: 0x%08x\n",
+ controller->regs + CONFIG_REG, reg);
+ reg |= aspeed_smc_chip_write_bit(chip);
+ writel(reg, controller->regs + CONFIG_REG);
+}
+
+static void aspeed_smc_start_user(struct spi_nor *nor)
+{
+ struct aspeed_smc_chip *chip = nor->priv;
+ u32 ctl = chip->ctl_val[smc_base];
+
+ /*
+ * When the chip is controlled in user mode, we need write
+ * access to send the opcodes to it. So check the config.
+ */
+ aspeed_smc_chip_check_config(chip);
+
+ ctl |= CONTROL_COMMAND_MODE_USER |
+ CONTROL_CE_STOP_ACTIVE_CONTROL;
+ writel(ctl, chip->ctl);
+
+ ctl &= ~CONTROL_CE_STOP_ACTIVE_CONTROL;
+ writel(ctl, chip->ctl);
+}
+
+static void aspeed_smc_stop_user(struct spi_nor *nor)
+{
+ struct aspeed_smc_chip *chip = nor->priv;
+
+ u32 ctl = chip->ctl_val[smc_read];
+ u32 ctl2 = ctl | CONTROL_COMMAND_MODE_USER |
+ CONTROL_CE_STOP_ACTIVE_CONTROL;
+
+ writel(ctl2, chip->ctl); /* stop user CE control */
+ writel(ctl, chip->ctl); /* default to fread or read mode */
+}
+
+static int aspeed_smc_prep(struct spi_nor *nor, enum spi_nor_ops ops)
+{
+ struct aspeed_smc_chip *chip = nor->priv;
+
+ mutex_lock(&chip->controller->mutex);
+ return 0;
+}
+
+static void aspeed_smc_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
+{
+ struct aspeed_smc_chip *chip = nor->priv;
+
+ mutex_unlock(&chip->controller->mutex);
+}
+
+static int aspeed_smc_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
+{
+ struct aspeed_smc_chip *chip = nor->priv;
+
+ aspeed_smc_start_user(nor);
+ aspeed_smc_write_to_ahb(chip->ahb_base, &opcode, 1);
+ aspeed_smc_read_from_ahb(buf, chip->ahb_base, len);
+ aspeed_smc_stop_user(nor);
+ return 0;
+}
+
+static int aspeed_smc_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
+ int len)
+{
+ struct aspeed_smc_chip *chip = nor->priv;
+
+ aspeed_smc_start_user(nor);
+ aspeed_smc_write_to_ahb(chip->ahb_base, &opcode, 1);
+ aspeed_smc_write_to_ahb(chip->ahb_base, buf, len);
+ aspeed_smc_stop_user(nor);
+ return 0;
+}
+
+static void aspeed_smc_send_cmd_addr(struct spi_nor *nor, u8 cmd, u32 addr)
+{
+ struct aspeed_smc_chip *chip = nor->priv;
+ __be32 temp;
+ u32 cmdaddr;
+
+ switch (nor->addr_width) {
+ default:
+ WARN_ONCE(1, "Unexpected address width %u, defaulting to 3\n",
+ nor->addr_width);
+ /* FALLTHROUGH */
+ case 3:
+ cmdaddr = addr & 0xFFFFFF;
+ cmdaddr |= cmd << 24;
+
+ temp = cpu_to_be32(cmdaddr);
+ aspeed_smc_write_to_ahb(chip->ahb_base, &temp, 4);
+ break;
+ case 4:
+ temp = cpu_to_be32(addr);
+ aspeed_smc_write_to_ahb(chip->ahb_base, &cmd, 1);
+ aspeed_smc_write_to_ahb(chip->ahb_base, &temp, 4);
+ break;
+ }
+}
+
+static ssize_t aspeed_smc_read_user(struct spi_nor *nor, loff_t from,
+ size_t len, u_char *read_buf)
+{
+ struct aspeed_smc_chip *chip = nor->priv;
+ int i;
+ u8 dummy = 0xFF;
+
+ aspeed_smc_start_user(nor);
+ aspeed_smc_send_cmd_addr(nor, nor->read_opcode, from);
+ for (i = 0; i < chip->nor.read_dummy / 8; i++)
+ aspeed_smc_write_to_ahb(chip->ahb_base, &dummy, sizeof(dummy));
+
+ aspeed_smc_read_from_ahb(read_buf, chip->ahb_base, len);
+ aspeed_smc_stop_user(nor);
+ return len;
+}
+
+static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to,
+ size_t len, const u_char *write_buf)
+{
+ struct aspeed_smc_chip *chip = nor->priv;
+
+ aspeed_smc_start_user(nor);
+ aspeed_smc_send_cmd_addr(nor, nor->program_opcode, to);
+ aspeed_smc_write_to_ahb(chip->ahb_base, write_buf, len);
+ aspeed_smc_stop_user(nor);
+ return len;
+}
+
+static int aspeed_smc_unregister(struct aspeed_smc_controller *controller)
+{
+ struct aspeed_smc_chip *chip;
+ int n;
+
+ for (n = 0; n < controller->info->nce; n++) {
+ chip = controller->chips[n];
+ if (chip)
+ mtd_device_unregister(&chip->nor.mtd);
+ }
+
+ return 0;
+}
+
+static int aspeed_smc_remove(struct platform_device *dev)
+{
+ return aspeed_smc_unregister(platform_get_drvdata(dev));
+}
+
+static const struct of_device_id aspeed_smc_matches[] = {
+ { .compatible = "aspeed,ast2500-fmc", .data = &fmc_2500_info },
+ { .compatible = "aspeed,ast2500-spi", .data = &spi_2500_info },
+ { }
+};
+MODULE_DEVICE_TABLE(of, aspeed_smc_matches);
+
+/*
+ * Each chip has a mapping window defined by a segment address
+ * register defining a start and an end address on the AHB bus. These
+ * addresses can be configured to fit the chip size and offer a
+ * contiguous memory region across chips. For the moment, we only
+ * check that each chip segment is valid.
+ */
+static void __iomem *aspeed_smc_chip_base(struct aspeed_smc_chip *chip,
+ struct resource *res)
+{
+ struct aspeed_smc_controller *controller = chip->controller;
+ u32 offset = 0;
+ u32 reg;
+
+ if (controller->info->nce > 1) {
+ reg = readl(controller->regs + SEGMENT_ADDR_REG0 +
+ chip->cs * 4);
+
+ if (SEGMENT_ADDR_START(reg) >= SEGMENT_ADDR_END(reg))
+ return NULL;
+
+ offset = SEGMENT_ADDR_START(reg) - res->start;
+ }
+
+ return controller->ahb_base + offset;
+}
+
+static void aspeed_smc_chip_enable_write(struct aspeed_smc_chip *chip)
+{
+ struct aspeed_smc_controller *controller = chip->controller;
+ u32 reg;
+
+ reg = readl(controller->regs + CONFIG_REG);
+
+ reg |= aspeed_smc_chip_write_bit(chip);
+ writel(reg, controller->regs + CONFIG_REG);
+}
+
+static void aspeed_smc_chip_set_type(struct aspeed_smc_chip *chip, int type)
+{
+ struct aspeed_smc_controller *controller = chip->controller;
+ u32 reg;
+
+ chip->type = type;
+
+ reg = readl(controller->regs + CONFIG_REG);
+ reg &= ~(3 << (chip->cs * 2));
+ reg |= chip->type << (chip->cs * 2);
+ writel(reg, controller->regs + CONFIG_REG);
+}
+
+/*
+ * The AST2500 FMC flash controller should be strapped by hardware, or
+ * autodetected, but the AST2500 SPI flash needs to be set.
+ */
+static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip)
+{
+ struct aspeed_smc_controller *controller = chip->controller;
+ u32 reg;
+
+ if (chip->controller->info == &spi_2500_info) {
+ reg = readl(controller->regs + CE_CONTROL_REG);
+ reg |= 1 << chip->cs;
+ writel(reg, controller->regs + CE_CONTROL_REG);
+ }
+}
+
+static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
+ struct resource *res)
+{
+ struct aspeed_smc_controller *controller = chip->controller;
+ const struct aspeed_smc_info *info = controller->info;
+ u32 reg, base_reg;
+
+ /*
+ * Always turn on the write enable bit to allow opcodes to be
+ * sent in user mode.
+ */
+ aspeed_smc_chip_enable_write(chip);
+
+ /* The driver only supports SPI type flash */
+ if (info->hastype)
+ aspeed_smc_chip_set_type(chip, smc_type_spi);
+
+ /*
+ * Configure chip base address in memory
+ */
+ chip->ahb_base = aspeed_smc_chip_base(chip, res);
+ if (!chip->ahb_base) {
+ dev_warn(chip->nor.dev, "CE segment window closed.\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Get value of the inherited control register. U-Boot usually
+ * does some timing calibration on the FMC chip, so it's good
+ * to keep them. In the future, we should handle calibration
+ * from Linux.
+ */
+ reg = readl(chip->ctl);
+ dev_dbg(controller->dev, "control register: %08x\n", reg);
+
+ base_reg = reg & CONTROL_KEEP_MASK;
+ if (base_reg != reg) {
+ dev_dbg(controller->dev,
+ "control register changed to: %08x\n",
+ base_reg);
+ }
+ chip->ctl_val[smc_base] = base_reg;
+
+ /*
+ * Retain the prior value of the control register as the
+ * default if it was normal access mode. Otherwise start with
+ * the sanitized base value set to read mode.
+ */
+ if ((reg & CONTROL_COMMAND_MODE_MASK) ==
+ CONTROL_COMMAND_MODE_NORMAL)
+ chip->ctl_val[smc_read] = reg;
+ else
+ chip->ctl_val[smc_read] = chip->ctl_val[smc_base] |
+ CONTROL_COMMAND_MODE_NORMAL;
+
+ dev_dbg(controller->dev, "default control register: %08x\n",
+ chip->ctl_val[smc_read]);
+ return 0;
+}
+
+static int aspeed_smc_chip_setup_finish(struct aspeed_smc_chip *chip)
+{
+ struct aspeed_smc_controller *controller = chip->controller;
+ const struct aspeed_smc_info *info = controller->info;
+ u32 cmd;
+
+ if (chip->nor.addr_width == 4 && info->set_4b)
+ info->set_4b(chip);
+
+ /*
+ * base mode has not been optimized yet. use it for writes.
+ */
+ chip->ctl_val[smc_write] = chip->ctl_val[smc_base] |
+ chip->nor.program_opcode << CONTROL_COMMAND_SHIFT |
+ CONTROL_COMMAND_MODE_WRITE;
+
+ dev_dbg(controller->dev, "write control register: %08x\n",
+ chip->ctl_val[smc_write]);
+
+ /*
+ * TODO: Adjust clocks if fast read is supported and interpret
+ * SPI-NOR flags to adjust controller settings.
+ */
+ switch (chip->nor.flash_read) {
+ case SPI_NOR_NORMAL:
+ cmd = CONTROL_COMMAND_MODE_NORMAL;
+ break;
+ case SPI_NOR_FAST:
+ cmd = CONTROL_COMMAND_MODE_FREAD;
+ break;
+ default:
+ dev_err(chip->nor.dev, "unsupported SPI read mode\n");
+ return -EINVAL;
+ }
+
+ chip->ctl_val[smc_read] |= cmd |
+ CONTROL_IO_DUMMY_SET(chip->nor.read_dummy / 8);
+
+ dev_dbg(controller->dev, "base control register: %08x\n",
+ chip->ctl_val[smc_read]);
+ return 0;
+}
+
+static int aspeed_smc_setup_flash(struct aspeed_smc_controller *controller,
+ struct device_node *np, struct resource *r)
+{
+ const struct aspeed_smc_info *info = controller->info;
+ struct device *dev = controller->dev;
+ struct device_node *child;
+ unsigned int cs;
+ int ret = -ENODEV;
+
+ for_each_available_child_of_node(np, child) {
+ struct aspeed_smc_chip *chip;
+ struct spi_nor *nor;
+ struct mtd_info *mtd;
+
+ /* This driver does not support NAND or NOR flash devices. */
+ if (!of_device_is_compatible(child, "jedec,spi-nor"))
+ continue;
+
+ ret = of_property_read_u32(child, "reg", &cs);
+ if (ret) {
+ dev_err(dev, "Couldn't not read chip select.\n");
+ break;
+ }
+
+ if (cs >= info->nce) {
+ dev_err(dev, "Chip select %d out of range.\n",
+ cs);
+ ret = -ERANGE;
+ break;
+ }
+
+ if (controller->chips[cs]) {
+ dev_err(dev, "Chip select %d already in use by %s\n",
+ cs, dev_name(controller->chips[cs]->nor.dev));
+ ret = -EBUSY;
+ break;
+ }
+
+ chip = devm_kzalloc(controller->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip) {
+ ret = -ENOMEM;
+ break;
+ }
+
+ chip->controller = controller;
+ chip->ctl = controller->regs + info->ctl0 + cs * 4;
+ chip->cs = cs;
+
+ nor = &chip->nor;
+ mtd = &nor->mtd;
+
+ nor->dev = dev;
+ nor->priv = chip;
+ spi_nor_set_flash_node(nor, child);
+ nor->read = aspeed_smc_read_user;
+ nor->write = aspeed_smc_write_user;
+ nor->read_reg = aspeed_smc_read_reg;
+ nor->write_reg = aspeed_smc_write_reg;
+ nor->prepare = aspeed_smc_prep;
+ nor->unprepare = aspeed_smc_unprep;
+
+ ret = aspeed_smc_chip_setup_init(chip, r);
+ if (ret)
+ break;
+
+ /*
+ * TODO: Add support for SPI_NOR_QUAD and SPI_NOR_DUAL
+ * attach when board support is present as determined
+ * by of property.
+ */
+ ret = spi_nor_scan(nor, NULL, SPI_NOR_NORMAL);
+ if (ret)
+ break;
+
+ ret = aspeed_smc_chip_setup_finish(chip);
+ if (ret)
+ break;
+
+ ret = mtd_device_register(mtd, NULL, 0);
+ if (ret)
+ break;
+
+ controller->chips[cs] = chip;
+ }
+
+ if (ret)
+ aspeed_smc_unregister(controller);
+
+ return ret;
+}
+
+static int aspeed_smc_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct aspeed_smc_controller *controller;
+ const struct of_device_id *match;
+ const struct aspeed_smc_info *info;
+ struct resource *res;
+ int ret;
+
+ match = of_match_device(aspeed_smc_matches, &pdev->dev);
+ if (!match || !match->data)
+ return -ENODEV;
+ info = match->data;
+
+ controller = devm_kzalloc(&pdev->dev, sizeof(*controller) +
+ info->nce * sizeof(controller->chips[0]), GFP_KERNEL);
+ if (!controller)
+ return -ENOMEM;
+ controller->info = info;
+ controller->dev = dev;
+
+ mutex_init(&controller->mutex);
+ platform_set_drvdata(pdev, controller);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ controller->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(controller->regs)) {
+ dev_err(dev, "Cannot remap controller address.\n");
+ return PTR_ERR(controller->regs);
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ controller->ahb_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(controller->ahb_base)) {
+ dev_err(dev, "Cannot remap controller address.\n");
+ return PTR_ERR(controller->ahb_base);
+ }
+
+ ret = aspeed_smc_setup_flash(controller, np, res);
+ if (ret)
+ dev_err(dev, "Aspeed SMC probe failed %d\n", ret);
+
+ return ret;
+}
+
+static struct platform_driver aspeed_smc_driver = {
+ .probe = aspeed_smc_probe,
+ .remove = aspeed_smc_remove,
+ .driver = {
+ .name = DEVICE_NAME,
+ .of_match_table = aspeed_smc_matches,
+ }
+};
+
+module_platform_driver(aspeed_smc_driver);
+
+MODULE_DESCRIPTION("ASPEED Static Memory Controller Driver");
+MODULE_AUTHOR("Cedric Le Goater <clg-Bxea+6Xhats@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v5 0/3] Static memory controllers for the Aspeed SoC
From: Cédric Le Goater @ 2016-12-21 16:57 UTC (permalink / raw)
To: linux-mtd
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Marek Vasut, Rob Herring, Joel Stanley, Cyrille Pitchen,
Brian Norris, David Woodhouse, Cédric Le Goater
Hello,
Here is a series introducing a new driver for the different memory
controllers of the Aspeed AST2500 and AST2400 SoCs. Each SoC has at
least a memory controller for the BMC firmware and another one for the
host firmware. The register set are mostly compatible but there are
some slight differences on the AST2400.
The driver only supports SPI type flash.
Tested on:
* OpenPOWER Palmetto (AST2400) with
FMC controller : n25q256a
SPI controller : mx25l25635e and n25q512ax3
* Evaluation board (AST2500) with
FMC controller : w25q256
SPI controller : w25q256
* OpenPOWER Witherspoon (AST2500) with
FMC controller : mx25l25635e * 2
SPI controller : mx66l1g45g
Changes since v4:
- improved IO routines with Cyrille's suggestions
- added dummy bytes hanling for fast read commands
- removed the 'label' property from jedec,spi-nor. Needs more
discussion.
Changes since v3:
- reworked IO routines to use io{read,write}32_rep
- changed config option to SPI_ASPEED_SMC
- fixed aspeed_smc_chip_setup_init() returned value
Changes since v2:
- splitted patch to distinguish AST2400 and AST2500 controllers
- fixed controller names
- introduced prepare/unprepare ops
- introduced a aspeed_smc_setup_flash() routine
- various cleanups
Changes since v1:
- added a set4b ops to handle difference in the controllers
- simplified the IO routines
- prepared for fast read using dummy cycles
Work in progress:
- read optimization using higher SPI clock frequencies
- command mode to direct reads from AHB
- DMA support
Thanks,
C.
Cédric Le Goater (3):
mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
mtd: aspeed: add memory controllers for the Aspeed AST2400 SoC
mtd: spi-nor: bindings for the Aspeed memory controllers
.../devicetree/bindings/mtd/aspeed-smc.txt | 51 ++
drivers/mtd/spi-nor/Kconfig | 10 +
drivers/mtd/spi-nor/Makefile | 1 +
drivers/mtd/spi-nor/aspeed-smc.c | 759 +++++++++++++++++++++
4 files changed, 821 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/aspeed-smc.txt
create mode 100644 drivers/mtd/spi-nor/aspeed-smc.c
--
2.7.4
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Cédric Le Goater @ 2016-12-21 16:47 UTC (permalink / raw)
To: Cyrille Pitchen, Cyrille Pitchen, linux-mtd
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Marek Vasut, Rob Herring, Joel Stanley, Brian Norris,
David Woodhouse
In-Reply-To: <2bec1e91-a196-b894-fb66-590b8f4f35c3@atmel.com>
Hello Cyrille,
>>> all aspeed_smc_[read|write]_[reg|user]() functions call
>>> aspeed_smc_[start|stop]_user(), so this driver always selects the "USER"
>>> mode and configures the control register based on chip->ctrl_val[smc_base].
>>
>> yes.
>>
>> Maybe you think it is too early to prepare ground for the other
>> mode ? Is that really confusing in the code ? Do you think I should
>> remove it for the initial support in the driver and stick to 'User'
>> mode.
>>
>
> I think it is not a big deal, at least technically. This is more a
> psychological aspect of the review: the bigger patches, the more scarier.
> I mean it requires more time and courage to dig into the source code hence
> to understand what the driver actually does.
> Sometime, it's better to split a big patch into many incremental and
> smaller patches so it's more easy for reviewers to understand each part as
> an independent feature. It also reveals the driver evolution during the
> development process hence it helps to understand where it goes and what are
> the next improvements to come.
I fully agree. It is just that we have been sitting on the code for more
than a year, using it in production and we should send to mainline
much sooner. that was a mistake of us ...
> Anyway, since the review is done now, on my side I won't ask you to remove
> or split the support of the 'Command' mode in a separated patch.
> I let you do as you want, if it help you to introduce some part of the
> support of this 'Command' mode now even if not completed yet, no problem on
> my side :)
>
> I was just giving you some pieces of advice for the next time if you want
> to speed up the review of another patch introducing new features.
>
> However, I will just ask you one more version handling the dummy cycles
> properly as it would help us for the global maintenance of the spi-nor
> subsystem. This is the only mandatory modification I ask you, after that I
> think it would be ok for me and since Marek has already reviewed your
> driver, it would be ready to be merged into the spi-nor tree.
Sending a v5 which should address your comments.
I have removed the label property and will start a new thread in the
topic. Any hints on which binding we could add this label prop ?
> Anyway, thanks for taking time to explain us how your driver work :)
Thanks for the review !
C.
> Best regards,
>
> Cyrille
>
>
>
>>>> +static int aspeed_smc_setup_flash(struct aspeed_smc_controller *controller,
>>>> + struct device_node *np, struct resource *r)
>>>> +{
>>>> + const struct aspeed_smc_info *info = controller->info;
>>>> + struct device *dev = controller->dev;
>>>> + struct device_node *child;
>>>> + unsigned int cs;
>>>> + int ret = -ENODEV;
>>>> +
>>>> + for_each_available_child_of_node(np, child) {
>>>> + struct aspeed_smc_chip *chip;
>>>> + struct spi_nor *nor;
>>>> + struct mtd_info *mtd;
>>>> +
>>>> + /* This driver does not support NAND or NOR flash devices. */
>>>> + if (!of_device_is_compatible(child, "jedec,spi-nor"))
>>>> + continue;
>>>> +
>>>> + ret = of_property_read_u32(child, "reg", &cs);
>>>> + if (ret) {
>>>> + dev_err(dev, "Couldn't not read chip select.\n");
>>>> + break;
>>>> + }
>>>> +
>>>> + if (cs >= info->nce) {
>>>> + dev_err(dev, "Chip select %d out of range.\n",
>>>> + cs);
>>>> + ret = -ERANGE;
>>>> + break;
>>>> + }
>>>> +
>>>> + if (controller->chips[cs]) {
>>>> + dev_err(dev, "Chip select %d already in use by %s\n",
>>>> + cs, dev_name(controller->chips[cs]->nor.dev));
>>>> + ret = -EBUSY;
>>>> + break;
>>>> + }
>>>> +
>>>> + chip = devm_kzalloc(controller->dev, sizeof(*chip), GFP_KERNEL);
>>>> + if (!chip) {
>>>> + ret = -ENOMEM;
>>>> + break;
>>>> + }
>>>> +
>>>> + chip->controller = controller;
>>>> + chip->ctl = controller->regs + info->ctl0 + cs * 4;
>>>> + chip->cs = cs;
>>>> +
>>>> + nor = &chip->nor;
>>>> + mtd = &nor->mtd;
>>>> +
>>>> + nor->dev = dev;
>>>> + nor->priv = chip;
>>>> + spi_nor_set_flash_node(nor, child);
>>>> + nor->read = aspeed_smc_read_user;
>>>> + nor->write = aspeed_smc_write_user;
>>>> + nor->read_reg = aspeed_smc_read_reg;
>>>> + nor->write_reg = aspeed_smc_write_reg;
>>>> + nor->prepare = aspeed_smc_prep;
>>>> + nor->unprepare = aspeed_smc_unprep;
>>>> +
>>>> + mtd->name = of_get_property(child, "label", NULL);
>>>
>>> This new "label" DT property should be removed from this patch and send
>>> in a dedicated patch to be discussed separately. However I agree with
>>> Marek: it looks generic so maybe it could be managed directly from
>>> mtd_device_register() since setting such as name could also be done when
>>> using a NAND flash. Anyway, I don't see the link between this name and
>>> spi-nor. Hence I don't think the DT property should be documented in
>>> jedec,spi-nor.txt.
>>
>> OK. I will remove it in the next version.
>>
>>> Be patient because I expect such a topic to be discussed quite a long
>>> time before we all agree, even if this is "just" a new DT property ;)
>>
>> yeah. I expected that also :) But it is quite pratical to give user
>> space a hint on the flash nature. Systems can have up to 4 different
>> ones. So there is need for it IMO.
>>
>> How should I proceed then ? Shall I start a discussion with a single
>> patch changing mtd_device_register() ? but I need to know which binding
>> would be the more consensual for such a prop.
>>
>> Thanks,
>>
>> C.
>>
>>>
>>> Best regards,
>>>
>>> Cyrille
>>>
>>>
>>>> +
>>>> + ret = aspeed_smc_chip_setup_init(chip, r);
>>>> + if (ret)
>>>> + break;
>>>> +
>>>> + /*
>>>> + * TODO: Add support for SPI_NOR_QUAD and SPI_NOR_DUAL
>>>> + * attach when board support is present as determined
>>>> + * by of property.
>>>> + */
>>>> + ret = spi_nor_scan(nor, NULL, SPI_NOR_NORMAL);
>>>> + if (ret)
>>>> + break;
>>>> +
>>>> + ret = aspeed_smc_chip_setup_finish(chip);
>>>> + if (ret)
>>>> + break;
>>>> +
>>>> + ret = mtd_device_register(mtd, NULL, 0);
>>>> + if (ret)
>>>> + break;
>>>> +
>>>> + controller->chips[cs] = chip;
>>>> + }
>>>> +
>>>> + if (ret)
>>>> + aspeed_smc_unregister(controller);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int aspeed_smc_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct device_node *np = pdev->dev.of_node;
>>>> + struct device *dev = &pdev->dev;
>>>> + struct aspeed_smc_controller *controller;
>>>> + const struct of_device_id *match;
>>>> + const struct aspeed_smc_info *info;
>>>> + struct resource *res;
>>>> + int ret;
>>>> +
>>>> + match = of_match_device(aspeed_smc_matches, &pdev->dev);
>>>> + if (!match || !match->data)
>>>> + return -ENODEV;
>>>> + info = match->data;
>>>> +
>>>> + controller = devm_kzalloc(&pdev->dev, sizeof(*controller) +
>>>> + info->nce * sizeof(controller->chips[0]), GFP_KERNEL);
>>>> + if (!controller)
>>>> + return -ENOMEM;
>>>> + controller->info = info;
>>>> + controller->dev = dev;
>>>> +
>>>> + mutex_init(&controller->mutex);
>>>> + platform_set_drvdata(pdev, controller);
>>>> +
>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> + controller->regs = devm_ioremap_resource(dev, res);
>>>> + if (IS_ERR(controller->regs)) {
>>>> + dev_err(dev, "Cannot remap controller address.\n");
>>>> + return PTR_ERR(controller->regs);
>>>> + }
>>>> +
>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>>> + controller->ahb_base = devm_ioremap_resource(dev, res);
>>>> + if (IS_ERR(controller->ahb_base)) {
>>>> + dev_err(dev, "Cannot remap controller address.\n");
>>>> + return PTR_ERR(controller->ahb_base);
>>>> + }
>>>> +
>>>> + ret = aspeed_smc_setup_flash(controller, np, res);
>>>> + if (ret)
>>>> + dev_err(dev, "Aspeed SMC probe failed %d\n", ret);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static struct platform_driver aspeed_smc_driver = {
>>>> + .probe = aspeed_smc_probe,
>>>> + .remove = aspeed_smc_remove,
>>>> + .driver = {
>>>> + .name = DEVICE_NAME,
>>>> + .of_match_table = aspeed_smc_matches,
>>>> + }
>>>> +};
>>>> +
>>>> +module_platform_driver(aspeed_smc_driver);
>>>> +
>>>> +MODULE_DESCRIPTION("ASPEED Static Memory Controller Driver");
>>>> +MODULE_AUTHOR("Cedric Le Goater <clg@kaod.org>");
>>>> +MODULE_LICENSE("GPL v2");
>>>>
>>>
>>
>>
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v2] power: reset: add linkstation-reset driver
From: Andrew Lunn @ 2016-12-21 16:41 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Roger Shimizu, Rob Herring, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Ryan Tandy, Martin Michlmayr, Sylver Bruneau,
Herbert Valerio Riedel, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161221155929.o4ihvqezbuqx2stl@earth>
> These models can just be added to qnap-poweroff, which handles
> exactly this special case as far as I can see.
Nope, qnap is much, much simpler. The configuration of the serial port
is simpler, and it only needs to send a single byte. Here we have all
sorts of checksums to calculate, stuff coming back from the
microcontroller, etc. The complexity is much higher.
V1 of this patchset did extend the qnap driver. But in fact, very
little of the original code was left afterwards, and lots of new code
was added. So i requested a new driver be written, rather than extend
my qnap driver.
I would not like to see the nice and simple qnap driver get all this
code added to it, making it much harder to maintain, for very little
gain.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Mark Greer @ 2016-12-21 16:13 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin
In-Reply-To: <32FAB08E-BE8E-4127-80A6-013300B43BD0@kuvee.com>
On Wed, Dec 21, 2016 at 06:47:36AM -0500, Geoff Lansberry wrote:
> Thanks Mark. Should I resubmit patches with the requested edits today, or wait a bit for more comments? What is the desired etiquette?
Its up to you. I don't think there are any hard & fast rules on this.
If it were me, I would likely spin a new version today because there are
several responses already and it lets people review them at their leisure
over the holidays.
Just a thought - you may want to consider separating the third patch from
the other two. The problems the first two solve are well understood and
have reasonable solutions (I believe). The third one - for me, at least -
tries to fix a problem that is not well understood yet.
Mark
--
^ permalink raw reply
* Re: [PATCH v3 net-next 0/3] Add support for the ethernet switch on the ESPRESSObin
From: David Miller @ 2016-12-21 16:10 UTC (permalink / raw)
To: romain.perier
Cc: andrew, vivien.didelot, f.fainelli, jason, sebastian.hesselbarth,
gregory.clement, netdev, devicetree, robh+dt, ijc+devicetree,
pawel.moll, mark.rutland, galak, linux-arm-kernel,
thomas.petazzoni, nadavh
In-Reply-To: <20161221090045.474-1-romain.perier@free-electrons.com>
net-next is not open, please do not submit net-next changes during this
time.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox