* [PATCH v4 3/3] ARM: dts: vf610-zii-dev-rev-b: Remove 'fixed-link' from DSA ports
From: Andrey Smirnov @ 2016-12-19 7:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Andrey Smirnov, Shawn Guo, Rob Herring, Mark Rutland,
Russell King, Sascha Hauer, Stefan Agner, devicetree,
linux-kernel, andrew, Vivien Didelot, cphealy
In-Reply-To: <1482131877-6097-1-git-send-email-andrew.smirnov@gmail.com>
Remove 'fixed-link' nodes from DSA ports since they are not needed (they
are not limiting link's speed and the ports will be configured to their
maximux speed as a default)
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
Changes since v3:
- None
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index c0fc3f2..646c90c 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -97,10 +97,6 @@
phy-mode = "rgmii-txid";
link = <&switch1port6
&switch2port9>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
};
port@6 {
@@ -165,10 +161,6 @@
label = "dsa";
phy-mode = "rgmii-txid";
link = <&switch0port5>;
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
};
};
mdio {
--
2.5.5
^ permalink raw reply related
* Re: [PATCH v6 4/5] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Uwe Kleine-König @ 2016-12-19 7:23 UTC (permalink / raw)
To: Joshua Clayton
Cc: Alan Tull, Moritz Fischer, Russell King, Catalin Marinas,
Will Deacon, Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland,
devicetree, linux-fpga, linux-kernel, Rob Herring,
Anatolij Gustschin, linux-arm-kernel
In-Reply-To: <abaad69b5dd15c086826cc9b6e2d52aefb04f9ef.1481918884.git.stillcompiling@gmail.com>
On Fri, Dec 16, 2016 at 03:17:53PM -0800, Joshua Clayton wrote:
> cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial"
> interface on Altera Cyclone FPGAS.
>
> This is one of the simpler ways to set up an FPGA at runtime.
> The signal interface is close to unidirectional spi with lsb first.
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
> ---
> drivers/fpga/Kconfig | 7 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/cyclone-ps-spi.c | 186 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 194 insertions(+)
> create mode 100644 drivers/fpga/cyclone-ps-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index ce861a2..e6c032d 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -20,6 +20,13 @@ config FPGA_REGION
> FPGA Regions allow loading FPGA images under control of
> the Device Tree.
>
> +config FPGA_MGR_CYCLONE_PS_SPI
> + tristate "Altera Cyclone FPGA Passive Serial over SPI"
> + depends on SPI
> + help
> + FPGA manager driver support for Altera Cyclone using the
> + passive serial interface over SPI
> +
> config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8df07bc..a112bef 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -6,6 +6,7 @@
> obj-$(CONFIG_FPGA) += fpga-mgr.o
>
> # FPGA Manager Drivers
> +obj-$(CONFIG_FPGA_MGR_CYCLONE_PS_SPI) += cyclone-ps-spi.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
> new file mode 100644
> index 0000000..f9126f9
> --- /dev/null
> +++ b/drivers/fpga/cyclone-ps-spi.c
> @@ -0,0 +1,186 @@
> +/**
> + * Altera Cyclone Passive Serial SPI Driver
> + *
> + * Copyright (c) 2017 United Western Technologies, Corporation
In which timezone it's already 2017? s/ / /
> + *
> + * Joshua Clayton <stillcompiling@gmail.com>
> + *
> + * Manage Altera FPGA firmware that is loaded over spi using the passive
> + * serial configuration method.
> + * Firmware must be in binary "rbf" format.
> + * Works on Cyclone V. Should work on cyclone series.
> + * May work on other Altera FPGAs.
I can test this later on an Arria 10. I'm not sure what the connection
between "Cyclone" and "Arria" is, but the protocol looks similar.
> + *
> + */
> +
> +#include <linux/bitrev.h>
> +#include <linux/delay.h>
> +#include <linux/fpga/fpga-mgr.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of_gpio.h>
> +#include <linux/spi/spi.h>
> +#include <linux/sizes.h>
> +
> +#define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
> +#define FPGA_MIN_DELAY 50 /* min usecs to wait for config status */
> +#define FPGA_MAX_DELAY 1000 /* max usecs to wait for config status */
> +
> +struct cyclonespi_conf {
> + struct gpio_desc *config;
> + struct gpio_desc *status;
> + struct spi_device *spi;
> +};
> +
> +static const struct of_device_id of_ef_match[] = {
> + { .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, of_ef_match);
barebox already has such a driver, the binding is available at
https://git.pengutronix.de/cgit/barebox/tree/Documentation/devicetree/bindings/firmware/altr,passive-serial.txt
(This isn't completely accurate because nstat is optional in the driver.)
> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> +
> + if (gpiod_get_value(conf->status))
> + return FPGA_MGR_STATE_RESET;
> +
> + return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int cyclonespi_write_init(struct fpga_manager *mgr,
> + struct fpga_image_info *info,
> + const char *buf, size_t count)
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + int i;
> +
> + if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
> + return -EINVAL;
> + }
> +
> + gpiod_set_value(conf->config, 1);
> + usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
> + if (!gpiod_get_value(conf->status)) {
> + dev_err(&mgr->dev, "Status pin should be low.\n");
You write this when get_value returns 0. There is something fishy.
> + return -EIO;
> + }
> +
> + gpiod_set_value(conf->config, 0);
> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
> + if (!gpiod_get_value(conf->status))
> + return 0;
> + }
> +
> + dev_err(&mgr->dev, "Status pin not ready.\n");
> + return -EIO;
For Arria 10 the documentation has:
To ensure a successful configuration, send the entire
configuration data to the device. CONF_DONE is released high
when the device receives all the configuration data
successfully. After CONF_DONE goes high, send two additional
falling edges on DCLK to begin initialization and enter user
mode.
ISTR this is necessary for Arria V, too.
> +}
> +
> +static void rev_buf(void *buf, size_t len)
> +{
> + u32 *fw32 = (u32 *)buf;
> + const u32 *fw_end = (u32 *)(buf + len);
> +
> + /* set buffer to lsb first */
> + while (fw32 < fw_end) {
> + *fw32 = bitrev8x4(*fw32);
> + fw32++;
> + }
Is the size of the firmware always a multiple of 32 bit? If len isn't a
multiple of 4 you access data after the end of buf.
> +}
> +
> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + const char *fw_data = buf;
> + const char *fw_data_end = fw_data + count;
> +
> + while (fw_data < fw_data_end) {
> + int ret;
> + size_t stride = min(fw_data_end - fw_data, SZ_4K);
> +
> + rev_buf((void *)fw_data, stride);
This isn't necessary if the spi controller supports SPI_LSB_FIRST. At
least the mvebu spi core can do this for you. (The driver doesn't
support it yet, though.)
> + ret = spi_write(conf->spi, fw_data, stride);
> + if (ret) {
> + dev_err(&mgr->dev, "spi error in firmware write: %d\n",
> + ret);
> + return ret;
> + }
> + fw_data += stride;
> + }
> +
> + return 0;
> +}
> [...]
> +static int cyclonespi_probe(struct spi_device *spi)
> +{
> + struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
> + GFP_KERNEL);
please indent to the opening (.
> +
> + if (!conf)
> + return -ENOMEM;
> +
> + conf->spi = spi;
> + conf->config = devm_gpiod_get(&spi->dev, "config", GPIOD_OUT_HIGH);
> + if (IS_ERR(conf->config)) {
> + dev_err(&spi->dev, "Failed to get config gpio: %ld\n",
> + PTR_ERR(conf->config));
> + return PTR_ERR(conf->config);
> + }
> +
> + conf->status = devm_gpiod_get(&spi->dev, "status", GPIOD_IN);
> + if (IS_ERR(conf->status)) {
> + dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
> + PTR_ERR(conf->status));
> + return PTR_ERR(conf->status);
> + }
> +
> + return fpga_mgr_register(&spi->dev,
> + "Altera Cyclone PS SPI FPGA Manager",
> + &cyclonespi_ops, conf);
> +}
> +
> +static int cyclonespi_remove(struct spi_device *spi)
> +{
> + fpga_mgr_unregister(&spi->dev);
> +
> + return 0;
> +}
> +
> +static struct spi_driver cyclonespi_driver = {
> + .driver = {
> + .name = "cyclone-ps-spi",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(of_ef_match),
> + },
> + .probe = cyclonespi_probe,
> + .remove = cyclonespi_remove,
> +};
I'm not a big fan of aligning the assignment operators. This tends to
get out of sync or results in bigger than necessary changes in follow up
patches. Note that it's out of sync already now, so I suggest to use a
single space before =.
> +
> +module_spi_driver(cyclonespi_driver)
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Joshua Clayton <stillcompiling@gmail.com>");
> +MODULE_DESCRIPTION("Module to load Altera FPGA firmware over spi");
> --
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 2/3] of/overlay: sysfs based ABI for dt overlays
From: Heinrich Schuchardt @ 2016-12-19 8:03 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Rob Herring, Mark Rutland, Frank Rowand, devicetree,
linux-kernel
In-Reply-To: <201612191008.JibpO0Px%fengguang.wu@intel.com>
On 12/19/2016 03:34 AM, kbuild test robot wrote:
> Hi Heinrich,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on next-20161216]
> [cannot apply to glikely/devicetree/next robh/for-next v4.9]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Heinrich-Schuchardt/of-overlay-sysfs-based-ABI-for-dt-overlays/20161219-093606
> config: i386-randconfig-r0-12190124 (attached as .config)
> compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
> drivers/of/ov_sysfs.c: In function 'of_create_overlay_from_file':
> drivers/of/ov_sysfs.c:69:12: error: implicit declaration of function 'of_fdt_unflatten_tree' [-Werror=implicit-function-declaration]
select OF_EARLY_FLATTREE
is missing in Kconfig. It is automatically selected on ARM64 but not on
other architectures.
> overlay = of_fdt_unflatten_tree((unsigned long *) buffer, NULL, NULL);
> ^
>>> drivers/of/ov_sysfs.c:69:10: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
> overlay = of_fdt_unflatten_tree((unsigned long *) buffer, NULL, NULL);
> ^
> cc1: some warnings being treated as errors
>
> vim +/of_fdt_unflatten_tree +69 drivers/of/ov_sysfs.c
>
> 63 offset < fdt_totalsize(buffer)) {
> 64 pr_err("OF: Size of %s does not match header information\n",
> 65 path);
> 66 ret = -EINVAL;
> 67 goto err_file_read;
> 68 }
> > 69 overlay = of_fdt_unflatten_tree((unsigned long *) buffer, NULL, NULL);
> 70 if (overlay == NULL) {
> 71 pr_err("OF: Cannot unflatten %s\n", path);
> 72 ret = -EINVAL;
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
^ permalink raw reply
* Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
From: Dongpo Li @ 2016-12-19 8:14 UTC (permalink / raw)
To: Rob Herring, David Miller
Cc: Mark Rutland, Michael Turquette, Stephen Boyd, Russell King,
Zhangfei Gao, Yisen Zhuang, salil.mehta, Arnd Bergmann,
Andrew Lunn, Jiancheng Xue, benjamin.chenhao, caizhiyong, netdev,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAL_Jsq+d5xHsxMKxbWSYy3cDXnC+HQj3=wun1zxf5PZ_BYrD-Q@mail.gmail.com>
Hi Rob and David,
On 2016/12/12 22:21, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
>> Hi Rob,
>>
>> On 2016/12/10 6:35, Rob Herring wrote:
>>> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:
>>>> The "hix5hd2" is SoC name, add the generic ethernet driver name.
>>>> The "hisi-gemac-v1" is the basic version and "hisi-gemac-v2" adds
>>>> the SG/TXCSUM/TSO/UFO features.
>>>>
>>>> Signed-off-by: Dongpo Li <lidongpo@hisilicon.com>
>>>> ---
>>>> .../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt | 9 +++++++--
>>>> drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 15 +++++++++++----
>>>> 2 files changed, 18 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>>>> index 75d398b..75920f0 100644
>>>> --- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>>>> +++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>>>> @@ -1,7 +1,12 @@
>>>> Hisilicon hix5hd2 gmac controller
>>>>
>>>> Required properties:
>>>> -- compatible: should be "hisilicon,hix5hd2-gmac".
>>>> +- compatible: should contain one of the following SoC strings:
>>>> + * "hisilicon,hix5hd2-gemac"
>>>> + * "hisilicon,hi3798cv200-gemac"
>>>> + and one of the following version string:
>>>> + * "hisilicon,hisi-gemac-v1"
>>>> + * "hisilicon,hisi-gemac-v2"
>>>
>>> What combinations are valid? I assume both chips don't have both v1 and
>>> v2. 2 SoCs and 2 versions so far, I don't think there is much point to
>>> have the v1 and v2 compatible strings.
>>>
>> The v1 and v2 are generic MAC compatible strings, many HiSilicon SoCs may
>> use the same MAC version. For example,
>> hix5hd2, hi3716cv200 SoCs use the v1 MAC version,
>> hi3798cv200, hi3516a SoCs use the v2 MAC version,
>> and there may be more SoCs added in future.
>> So I think the generic compatible strings are okay here.
>> Should I add the hi3716cv200, hi3516a SoCs compatible here?
>
> Yes.
>
>> Do you have any good advice?
>>
>>>> - reg: specifies base physical address(s) and size of the device registers.
>>>> The first region is the MAC register base and size.
>>>> The second region is external interface control register.
>>>> @@ -20,7 +25,7 @@ Required properties:
>>>>
>>>> Example:
>>>> gmac0: ethernet@f9840000 {
>>>> - compatible = "hisilicon,hix5hd2-gmac";
>>>> + compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
>>>
>>> You can't just change compatible strings.
>>>
>> Okay, maybe I should name all the compatible string with the suffix "-gmac" instead of
>> "-gemac". This can keep the compatible strings with the same suffix. Is this okay?
>> Can I just add the generic compatible string without changing the SoCs compatible string?
>> Like following:
>> gmac0: ethernet@f9840000 {
>> - compatible = "hisilicon,hix5hd2-gmac";
>> + compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";
>
> Yes, this is fine.
As the patch series have been applied to net-next branch,
in which way should I commit this compatible fix?
Should I send a new patch fixing this compatible string error with "Fixes: xxx"?
Looking forward to your reply!
Regards,
Dongpo
.
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Maxime Ripard @ 2016-12-19 8:46 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Hans de Goede, Quentin Schulz,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161215182754.33921-1-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2537 bytes --]
On Fri, Dec 16, 2016 at 02:27:54AM +0800, Icenowy Zheng wrote:
> An operating point table is needed for the cpu frequency adjusting to
> work.
>
> The operating point table is converted from the common value in
> extracted script.fex from many A33 board/tablets.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> Changes since v1:
> - Fix format problem (blank lines).
> - Removed the 1.344GHz operating point, as it's overvoltage and overclocked.
>
> This patch depends on the following patchset:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473962.html
>
> It's the v2 of the [PATCH 4/6] in this patchset.
>
> I think this operating point table may also apply to A23, as there's no
> difference except the points over 1.2GHz between A23 and A33's stock dvfs table.
>
> But as A23 CCU may not have the necessary fixes, I won't add the table to A23
> now.
>
> Chen-Yu, could you test the CCU fixes I described in the patchset above on A23,
> then test this operating points table?
>
> If it's necessary, you can send out the CCU fixes and add one more patch that
> moves this opp-v2 table to sun8i-a23-a33.dtsi .
>
> arch/arm/boot/dts/sun8i-a33.dtsi | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 504996cbee29..0f5b2af72981 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -46,7 +46,42 @@
> #include <dt-bindings/dma/sun4i-a10.h>
>
> / {
> + cpu0_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp@648000000 {
> + opp-hz = /bits/ 64 <648000000>;
> + opp-microvolt = <1040000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + };
> +
> + opp@816000000 {
> + opp-hz = /bits/ 64 <816000000>;
> + opp-microvolt = <1100000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + };
> +
> + opp@1008000000 {
> + opp-hz = /bits/ 64 <1008000000>;
> + opp-microvolt = <1200000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + };
> +
> + opp@1200000000 {
> + opp-hz = /bits/ 64 <1200000000>;
> + opp-microvolt = <1320000>;
> + clock-latency-ns = <244144>; /* 8 32k periods */
> + };
> + };
> +
> cpus {
> + cpu0: cpu@0 {
There's no need to duplicate the label here. I removed it and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Chen-Yu Tsai @ 2016-12-19 8:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Icenowy Zheng, Chen-Yu Tsai, Hans de Goede, Quentin Schulz,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
In-Reply-To: <20161219084652.kiqdkiewu5tujlyd@lukather>
On Mon, Dec 19, 2016 at 4:46 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Fri, Dec 16, 2016 at 02:27:54AM +0800, Icenowy Zheng wrote:
>> An operating point table is needed for the cpu frequency adjusting to
>> work.
>>
>> The operating point table is converted from the common value in
>> extracted script.fex from many A33 board/tablets.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> ---
>> Changes since v1:
>> - Fix format problem (blank lines).
>> - Removed the 1.344GHz operating point, as it's overvoltage and overclocked.
>>
>> This patch depends on the following patchset:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473962.html
>>
>> It's the v2 of the [PATCH 4/6] in this patchset.
>>
>> I think this operating point table may also apply to A23, as there's no
>> difference except the points over 1.2GHz between A23 and A33's stock dvfs table.
>>
>> But as A23 CCU may not have the necessary fixes, I won't add the table to A23
>> now.
>>
>> Chen-Yu, could you test the CCU fixes I described in the patchset above on A23,
>> then test this operating points table?
>>
>> If it's necessary, you can send out the CCU fixes and add one more patch that
>> moves this opp-v2 table to sun8i-a23-a33.dtsi .
>>
>> arch/arm/boot/dts/sun8i-a33.dtsi | 35 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
>> index 504996cbee29..0f5b2af72981 100644
>> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
>> @@ -46,7 +46,42 @@
>> #include <dt-bindings/dma/sun4i-a10.h>
>>
>> / {
>> + cpu0_opp_table: opp_table0 {
>> + compatible = "operating-points-v2";
>> + opp-shared;
>> +
>> + opp@648000000 {
>> + opp-hz = /bits/ 64 <648000000>;
>> + opp-microvolt = <1040000>;
>> + clock-latency-ns = <244144>; /* 8 32k periods */
>> + };
>> +
>> + opp@816000000 {
>> + opp-hz = /bits/ 64 <816000000>;
>> + opp-microvolt = <1100000>;
>> + clock-latency-ns = <244144>; /* 8 32k periods */
>> + };
>> +
>> + opp@1008000000 {
>> + opp-hz = /bits/ 64 <1008000000>;
>> + opp-microvolt = <1200000>;
>> + clock-latency-ns = <244144>; /* 8 32k periods */
>> + };
>> +
>> + opp@1200000000 {
>> + opp-hz = /bits/ 64 <1200000000>;
>> + opp-microvolt = <1320000>;
>> + clock-latency-ns = <244144>; /* 8 32k periods */
>> + };
>> + };
>> +
>> cpus {
>> + cpu0: cpu@0 {
>
> There's no need to duplicate the label here. I removed it and applied.
I think using the label to directly reference cpu0 would be better,
instead of duplicating the cpu@0 block.
ChenYu
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Markus Reichl @ 2016-12-19 9:14 UTC (permalink / raw)
To: Javier Martinez Canillas, Krzysztof Kozlowski, Doug Anderson
Cc: Mark Rutland, devicetree@vger.kernel.org, linux-samsung-soc,
Bartlomiej Zolnierkiewicz, Ben Gamari, linux-pm@vger.kernel.org,
Russell King, Rob Herring, linux-kernel@vger.kernel.org,
Kukjin Kim, Thomas Abraham, Alim, Arjun K V, Andreas Faerber,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <f4f0dd96-abf1-d1ba-86a6-99f216b5175b@osg.samsung.com>
Hi Javier,
Am 16.12.2016 um 17:22 schrieb Javier Martinez Canillas:
> Hello Markus,
>
> On 12/16/2016 06:08 AM, Markus Reichl wrote:
>> Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
>>> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>>
>>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>>> IOW if the problem exists it is already present in the mainline
>>>>> kernel.
>>>>
>>>> Interesting. In the ChromeOS tree I see significantly higher voltages
>>>> needed... Note that one might naively look at
>>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>>>
>>>> 1362500, /* L0 2100 */
>>>> 1312500, /* L1 2000 */
>>>>
>>>> ..but, amazingly enough those voltages aren't used at all. Surprise!
>>>>
>>>> I believe that the above numbers are actually not used and the ASV
>>>> numbers are used instead. See
>>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>>>
>>>> { 2100000,
>>>> 1350000, 1350000, 1350000, 1350000, 1350000,
>>>> 1337500, 1325000, 1312500, 1300000, 1287500,
>>>> 1275000, 1262500, 1250000, 1237500 },
>>>>
>>>> I believe that interpretation there is: some bins of the CPU can run
>>>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>>>
>>> That is definitely the case. One could just look at vendors ASV table
>>> (for 1.9 GHz):
>>> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
>>> 1200000, 1187500, 1175000, 1162500, 1150000,
>>> 1137500, 1125000, 1112500, 1112500},
>>>
>>> The theoretical difference is up to 1.875V! From my experiments I saw
>>> BIN1 chips which should be the same... but some working on 1.2V, some on
>>> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
>>> does not mean that there aren't such...
>>>
>>>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>>>> running on a CPU from a nice bin?
>>
>> I've been running the proposed frequency/voltage combinations without any
>> stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
>> nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
>> The chips are poorly cooled, especially the XU4 and quickly step down.
>>
>>>
>>> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
>>> along with name of tested board. Because the "Tested on XU3" is not
>>> sufficient.
>>
>> If you point me to how to read these values out, I will publish them.
>>
>
> You can use the exynos-chipid driver posted by Pankaj. Apply patches 1 and
> 2 from this series (http://www.spinics.net/lists/arm-kernel/msg548384.html)
> and then this diff to get the values of the registers that Krzysztof asked:
>
Thanks for the code.
XU4: [ 0.080039] Exynos: CPU[EXYNOS5800] CPU_REV[0x1] PKG_ID[0x1c04832a] AUX_INFO[0x43]
XU3: [ 0.080034] Exynos: CPU[EXYNOS5800] CPU_REV[0x1] PKG_ID[0x1604832a] AUX_INFO[0x43]
XU3-lite:[ 0.080033] Exynos: CPU[EXYNOS5800] CPU_REV[0x1] PKG_ID[0x5a12832a] AUX_INFO[0x13000054]
Servus,
--
Markus Reichl
> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> index cf0128b18ee2..49fa76ec6d49 100644
> --- a/drivers/soc/samsung/exynos-chipid.c
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -22,6 +22,9 @@
> #define EXYNOS_MAINREV_MASK (0xF << 0)
> #define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
>
> +#define EXYNOS_PKG_ID 0x04
> +#define EXYNOS_AUX_INFO 0x1C
> +
> static const struct exynos_soc_id {
> const char *name;
> unsigned int id;
> @@ -71,6 +74,8 @@ int __init exynos_chipid_early_init(void)
> const struct of_device_id *match;
> u32 product_id;
> u32 revision;
> + u32 pkg_id;
> + u32 aux_info;
>
> np = of_find_matching_node_and_match(NULL,
> of_exynos_chipid_ids, &match);
> @@ -84,6 +89,8 @@ int __init exynos_chipid_early_init(void)
>
> product_id = readl_relaxed(exynos_chipid_base);
> revision = product_id & EXYNOS_REV_MASK;
> + pkg_id = readl_relaxed(exynos_chipid_base + EXYNOS_PKG_ID);
> + aux_info = readl_relaxed(exynos_chipid_base + EXYNOS_AUX_INFO);
> iounmap(exynos_chipid_base);
>
> soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> @@ -100,8 +107,8 @@ int __init exynos_chipid_early_init(void)
> soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
>
>
> - pr_info("Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
> - product_id_to_soc_id(product_id), revision);
> + pr_info("Exynos: CPU[%s] CPU_REV[0x%x] PKG_ID[0x%x] AUX_INFO[0x%x] \n",
> + product_id_to_soc_id(product_id), revision, pkg_id, aux_info);
>
> soc_dev = soc_device_register(soc_dev_attr);
> if (IS_ERR(soc_dev)) {
>
> Best regards,
>
^ permalink raw reply
* [PATCH v3 1/3] USB3/DWC3: Add definition for global soc bus configuration register
From: Changming Huang @ 2016-12-19 9:25 UTC (permalink / raw)
To: balbi, mark.rutland, catalin.marinas, will.deacon, robh+dt, linux
Cc: devicetree, linux-usb, linux-kernel, linux-arm-kernel,
Changming Huang
Add the macro definition for global soc bus configuration register 0/1
Signed-off-by: Changming Huang <jerry.huang@nxp.com>
---
Changes in v3:
- no change
Changes in v2:
- split the patch
- add more macro definition for soc bus configuration register
drivers/usb/dwc3/core.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index de5a857..065aa6f 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -161,6 +161,32 @@
/* Bit fields */
+/* Global SoC Bus Configuration Register 0 */
+#define AXI3_CACHE_TYPE_AW 0x8 /* write allocate */
+#define AXI3_CACHE_TYPE_AR 0x4 /* read allocate */
+#define AXI3_CACHE_TYPE_SNP 0x2 /* cacheable */
+#define AXI3_CACHE_TYPE_BUF 0x1 /* bufferable */
+#define DWC3_GSBUSCFG0_DATARD_SHIFT 28
+#define DWC3_GSBUSCFG0_DESCRD_SHIFT 24
+#define DWC3_GSBUSCFG0_DATAWR_SHIFT 20
+#define DWC3_GSBUSCFG0_DESCWR_SHIFT 16
+#define DWC3_GSBUSCFG0_SNP_MASK 0xffff0000
+#define DWC3_GSBUSCFG0_DATABIGEND (1 << 11)
+#define DWC3_GSBUSCFG0_DESCBIGEND (1 << 10)
+#define DWC3_GSBUSCFG0_INCR256BRSTENA (1 << 7) /* INCR256 burst */
+#define DWC3_GSBUSCFG0_INCR128BRSTENA (1 << 6) /* INCR128 burst */
+#define DWC3_GSBUSCFG0_INCR64BRSTENA (1 << 5) /* INCR64 burst */
+#define DWC3_GSBUSCFG0_INCR32BRSTENA (1 << 4) /* INCR32 burst */
+#define DWC3_GSBUSCFG0_INCR16BRSTENA (1 << 3) /* INCR16 burst */
+#define DWC3_GSBUSCFG0_INCR8BRSTENA (1 << 2) /* INCR8 burst */
+#define DWC3_GSBUSCFG0_INCR4BRSTENA (1 << 1) /* INCR4 burst */
+#define DWC3_GSBUSCFG0_INCRBRSTENA (1 << 0) /* undefined length enable */
+#define DWC3_GSBUSCFG0_INCRBRST_MASK 0xff
+
+/* Global SoC Bus Configuration Register 1 */
+#define DWC3_GSBUSCFG1_1KPAGEENA (1 << 12) /* 1K page boundary enable */
+#define DWC3_GSBUSCFG1_PTRANSLIMIT_MASK 0xf00
+
/* Global Debug Queue/FIFO Space Available Register */
#define DWC3_GDBGFIFOSPACE_NUM(n) ((n) & 0x1f)
#define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Changming Huang @ 2016-12-19 9:25 UTC (permalink / raw)
To: balbi, mark.rutland, catalin.marinas, will.deacon, robh+dt, linux
Cc: devicetree, linux-usb, linux-kernel, linux-arm-kernel,
Changming Huang
In-Reply-To: <1482139554-13618-1-git-send-email-jerry.huang@nxp.com>
New property "snps,incr-burst-type-adjustment = <x>, <y>" for USB3.0 DWC3.
Field "x": 1/0 - undefined length INCR burst type enable or not;
Field "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type.
While enabling undefined length INCR burst type and INCR16 burst type,
get better write performance on NXP Layerscape platform:
around 3% improvement (from 364MB/s to 375MB/s).
Signed-off-by: Changming Huang <jerry.huang@nxp.com>
---
Changes in v3:
- add new property for INCR burst in usb node.
Documentation/devicetree/bindings/usb/dwc3.txt | 5 +++++
arch/arm/boot/dts/ls1021a.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 ++
4 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index e3e6983..8c405a3 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -55,6 +55,10 @@ Optional properties:
fladj_30mhz_sdbnd signal is invalid or incorrect.
- <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
+ register, undefined length INCR burst type enable and INCRx type.
+ First field is for undefined length INCR burst type enable or not.
+ Second field is for largest INCRx type enabled.
This is usually a subnode to DWC3 glue to which it is connected.
@@ -63,4 +67,5 @@ dwc3@4a030000 {
reg = <0x4a030000 0xcfff>;
interrupts = <0 92 4>
usb-phy = <&usb2_phy>, <&usb3,phy>;
+ snps,incr-burst-type-adjustment = <0x1>, <16>;
};
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..2999edb 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -627,6 +627,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <0x1>, <16>;
};
pcie@3400000 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 97d331e..64828ce 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -482,6 +482,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <0x1>, <16>;
};
usb1: usb3@3000000 {
@@ -491,6 +492,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <0x1>, <16>;
};
usb2: usb3@3100000 {
@@ -500,6 +502,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <0x1>, <16>;
};
sata: sata@3200000 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index d058e56..414af27 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -710,6 +710,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <0x1>, <16>;
};
usb1: usb3@3110000 {
@@ -720,6 +721,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <0x1>, <16>;
};
ccn@4000000 {
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 3/3] USB3/DWC3: Enable undefined length INCR burst type
From: Changming Huang @ 2016-12-19 9:25 UTC (permalink / raw)
To: balbi, mark.rutland, catalin.marinas, will.deacon, robh+dt, linux
Cc: linux-usb, linux-kernel, devicetree, linux-arm-kernel,
Changming Huang, Rajesh Bhagat
In-Reply-To: <1482139554-13618-1-git-send-email-jerry.huang@nxp.com>
Enable the undefined length INCR burst type and set INCRx.
Different platform may has the different burst size type.
In order to get best performance, we need to tune the burst size to
one special value, instead of the default value.
Signed-off-by: Changming Huang <jerry.huang@nxp.com>
Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com>
---
Changes in v3:
- add new property for INCR burst in usb node to reset GSBUSCFG0.
Changes in v2:
- split patch
- create one new function to handle soc bus configuration register.
drivers/usb/dwc3/core.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/usb/dwc3/core.h | 7 +++++++
2 files changed, 58 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 369bab1..404d7e9 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -650,6 +650,55 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
}
+/* set global soc bus configuration registers */
+static void dwc3_set_soc_bus_cfg(struct dwc3 *dwc)
+{
+ struct device *dev = dwc->dev;
+ u32 cfg;
+ int ret;
+
+ cfg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
+
+ /* Get INCR burst type, if return !NULL, not to change this type */
+ ret = device_property_read_u32_array(dev,
+ "snps,incr-burst-type-adjustment",
+ dwc->incr_burst_type, 2);
+ if (!ret) {
+ /* Enable Undefined Length INCR Burst and Enable INCRx Burst */
+ cfg &= ~DWC3_GSBUSCFG0_INCRBRST_MASK;
+ if (*dwc->incr_burst_type)
+ cfg |= DWC3_GSBUSCFG0_INCRBRSTENA;
+ switch (*(dwc->incr_burst_type + 1)) {
+ case 256:
+ cfg |= DWC3_GSBUSCFG0_INCR256BRSTENA;
+ break;
+ case 128:
+ cfg |= DWC3_GSBUSCFG0_INCR128BRSTENA;
+ break;
+ case 64:
+ cfg |= DWC3_GSBUSCFG0_INCR64BRSTENA;
+ break;
+ case 32:
+ cfg |= DWC3_GSBUSCFG0_INCR32BRSTENA;
+ break;
+ case 16:
+ cfg |= DWC3_GSBUSCFG0_INCR16BRSTENA;
+ break;
+ case 8:
+ cfg |= DWC3_GSBUSCFG0_INCR8BRSTENA;
+ break;
+ case 4:
+ cfg |= DWC3_GSBUSCFG0_INCR4BRSTENA;
+ break;
+ default:
+ dev_err(dev, "Invalid property\n");
+ break;
+ }
+ }
+
+ dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, cfg);
+}
+
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -698,6 +747,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
/* Adjust Frame Length */
dwc3_frame_length_adjustment(dwc);
+ dwc3_set_soc_bus_cfg(dwc);
+
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
ret = phy_power_on(dwc->usb2_generic_phy);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 065aa6f..cfe389b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -805,6 +805,7 @@ struct dwc3_scratchpad_array {
* @regs: base address for our registers
* @regs_size: address space size
* @fladj: frame length adjustment
+ * @incr_burst_type: INCR burst type adjustment
* @irq_gadget: peripheral controller's IRQ number
* @nr_scratch: number of scratch buffers
* @u1u2: only used on revisions <1.83a for workaround
@@ -928,6 +929,12 @@ struct dwc3 {
enum usb_phy_interface hsphy_mode;
u32 fladj;
+ /*
+ * For INCR burst type.
+ * First field: for undefined length INCR burst type enable.
+ * Second field: for INCRx burst type enable
+ */
+ u32 incr_burst_type[2];
u32 irq_gadget;
u32 nr_scratch;
u32 u1u2;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Andreas Klinger @ 2016-12-19 9:26 UTC (permalink / raw)
To: Matt Ranostay
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg
In-Reply-To: <CAJCx=g=--vuGHRi1HUjJgzV_Hwj0-6bO+oakCNN_LZQVbwn5_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Matt,
thank you for your suggestions. See below.
Matt Ranostay <matt.ranostay-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> schrieb am Sat, 17. Dec 00:53:
> On Tue, Dec 13, 2016 at 10:02 AM, Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org> wrote:
> > This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> > cells.
>
> First off cool that this is finally getting a driver... I'll have to
> get the SparkFun breakout and really cheap scale to test :).
>
> >
> > The protocol is quite simple and using GPIO's:
> > One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
> >
> > Signed-off-by: Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
> > ---
> > drivers/iio/adc/Kconfig | 13 +++
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/hx711.c | 269 +++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 283 insertions(+)
> > create mode 100644 drivers/iio/adc/hx711.c
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 932de1f9d1e7..7902b50fcf32 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -205,6 +205,19 @@ config HI8435
> > This driver can also be built as a module. If so, the module will be
> > called hi8435.
> >
> > +config HX711
> > + tristate "AVIA HX711 ADC for weight cells"
> > + depends on GPIOLIB
> > + help
> > + If you say yes here you get support for AVIA HX711 ADC which is used
> > + for weight cells
> > +
> > + This driver uses two GPIO's, one for setting the clock and the other
> > + one for getting the data
> > +
> > + This driver can also be built as a module. If so, the module will be
> > + called hx711.
> > +
> > config INA2XX_ADC
> > tristate "Texas Instruments INA2xx Power Monitors IIO driver"
> > depends on I2C && !SENSORS_INA2XX
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index b1aa456e6af3..d46e289900ef 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> > obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> > obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> > obj-$(CONFIG_HI8435) += hi8435.o
> > +obj-$(CONFIG_HX711) += hx711.o
> > obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
> > obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
> > obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> > diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> > new file mode 100644
> > index 000000000000..cbc89e467985
> > --- /dev/null
> > +++ b/drivers/iio/adc/hx711.c
> > @@ -0,0 +1,269 @@
> > +/*
> > + * HX711: analog to digital converter for weight sensor module
> > + *
> > + * Copyright (c) Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License 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/err.h>
> > +#include <linux/gpio.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/property.h>
> > +#include <linux/slab.h>
> > +#include <linux/sched.h>
> > +#include <linux/delay.h>
> > +#include <linux/iio/iio.h>
> > +
> > +#define HX711_GAIN_32 2 /* gain = 32 for channel B */
> > +#define HX711_GAIN_64 3 /* gain = 64 for channel A */
> > +#define HX711_GAIN_128 1 /* gain = 128 for channel A */
> > +
> > +
> > +struct hx711_data {
> > + struct device *dev;
> > + dev_t devt;
> > + struct gpio_desc *gpiod_sck;
> > + struct gpio_desc *gpiod_dout;
> > + int gain_pulse;
> > + struct mutex lock;
> > +};
> > +
> > +static void hx711_reset(struct hx711_data *hx711_data)
> > +{
> > + int val;
> > + int i;
> > +
> > + val = gpiod_get_value(hx711_data->gpiod_dout);
>
> could move the val assignment here to the initialization don't think
> it will hit 80 chars
>
I'll change this.
> > + if (val) {
>
> move "int i" here to avoid compiler initialization warnings
>
> > + dev_warn(hx711_data->dev, "RESET-HX711\n");
> > +
> > + gpiod_set_value(hx711_data->gpiod_sck, 1);
> > + udelay(80);
>
> IIRC this chip has quite a bit of latency thresholds, can't use
> usleep_range? Single core embedded systems could have an issue with
> continuous polling.
>
That's a good suggestion. We don't need udelay so i'll change to usleep_range
for the next version
> > + gpiod_set_value(hx711_data->gpiod_sck, 0);
> > +
> > + for (i = 0; i < 1000; i++) {
> > + val = gpiod_get_value(hx711_data->gpiod_dout);
> > + if (!val)
> > + break;
> > + /* sleep at least 1 ms*/
> > + msleep(1);
> > + }
> > + }
> > +}
> > +
> > +static int hx711_cycle(struct hx711_data *hx711_data)
> > +{
> > + int val;
> > +
> > + /* if preempted for more then 60us while SCK is high:
> > + * hx711 is going in reset
> > + * ==> measuring is false
> > + */
> > + preempt_disable();
> > + gpiod_set_value(hx711_data->gpiod_sck, 1);
> > + val = gpiod_get_value(hx711_data->gpiod_dout);
> > + gpiod_set_value(hx711_data->gpiod_sck, 0);
> > + preempt_enable();
> > +
> > + return val;
> > +}
> > +
> > +static unsigned int hx711_read(struct hx711_data *hx711_data)
> > +{
> > + int i;
> > + int ret;
> > + int wert = 0;
> > +
> > + hx711_reset(hx711_data);
> > +
> > + for (i = 0; i < 24; i++) {
> > + wert <<= 1;
> > + ret = hx711_cycle(hx711_data);
> > + if (ret)
> > + wert++;
> > + }
> > +
> > + wert ^= 0x800000;
> > +
> > + for (i = 0; i < hx711_data->gain_pulse; i++)
> > + ret = hx711_cycle(hx711_data);
>
> What is ret used for here?
> > +
> > + return wert;
> > +}
> > +
> > +
> > +static int hx711_read_raw(struct iio_dev *iio_dev,
> > + const struct iio_chan_spec *chan,
> > + int *val, int *val2, long mask)
> > +{
> > + struct hx711_data *hx711_data = iio_priv(iio_dev);
> > + int ret;
> > +
> > + switch (mask) {
> > + case IIO_CHAN_INFO_RAW:
> > + switch (chan->type) {
> > + case IIO_VOLTAGE:
> > + mutex_lock(&hx711_data->lock);
> > + *val = (int)hx711_read(hx711_data);
> > + mutex_unlock(&hx711_data->lock);
> > + ret = IIO_VAL_INT;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > + return ret;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static const struct iio_info hx711_iio_info = {
> > + .driver_module = THIS_MODULE,
> > + .read_raw = hx711_read_raw,
> > +};
> > +
> > +static const struct iio_chan_spec hx711_chan_spec[] = {
> > + { .type = IIO_VOLTAGE,
> > + .channel = 0,
> > + .info_mask_separate =
> > + BIT(IIO_CHAN_INFO_RAW),
> > + .scan_type = {
> > + .sign = 'u',
> > + .realbits = 24,
> > + .storagebits = 32,
> > + .shift = 0,
> > + }
> > + },
> > +};
> > +
> > +static int hx711_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *node = dev->of_node;
> > + struct hx711_data *hx711_data = NULL;
> > + struct iio_dev *iio;
> > + int ret = 0, ival;
> > +
> > + iio = devm_iio_device_alloc(dev, sizeof(struct hx711_data));
> > + if (!iio) {
> > + dev_err(dev, "failed to allocate IIO device\n");
> > + return -ENOMEM;
> > + }
> > +
> > + hx711_data = iio_priv(iio);
> > + hx711_data->dev = dev;
> > +
> > + mutex_init(&hx711_data->lock);
> > +
> > + hx711_data->gpiod_sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_HIGH);
> > + if (IS_ERR(hx711_data->gpiod_sck)) {
> > + ret = PTR_ERR(hx711_data->gpiod_sck);
> > + goto err;
> > + }
> > +
> > + hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
> > + if (IS_ERR(hx711_data->gpiod_dout)) {
> > + ret = PTR_ERR(hx711_data->gpiod_dout);
> > + goto err;
> > + }
> > +
> > + ret = of_property_read_u32 (node, "gain", &ival);
> > + if (!ret) {
> > + switch (ival) {
> > + case 32:
> > + hx711_data->gain_pulse = HX711_GAIN_32;
> > + break;
> > + case 64:
> > + hx711_data->gain_pulse = HX711_GAIN_64;
> > + break;
> > + case 128:
> > + hx711_data->gain_pulse = HX711_GAIN_128;
> > + break;
> > + default:
> > + hx711_data->gain_pulse = HX711_GAIN_128;
> > + }
> > + } else
> > + hx711_data->gain_pulse = HX711_GAIN_128;
> > + dev_dbg(hx711_data->dev, "gain: %d\n", hx711_data->gain_pulse);
> > +
> > + ret = gpiod_direction_input(hx711_data->gpiod_dout);
> > + if (ret < 0) {
> > + dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
> > + goto err;
> > + }
> > +
> > + ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);
> > + if (ret < 0) {
> > + dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
> > + goto err;
> > + }
> > +
> > + platform_set_drvdata(pdev, iio);
> > +
> > + iio->name = pdev->name;
> > + iio->dev.parent = &pdev->dev;
> > + iio->info = &hx711_iio_info;
> > + iio->modes = INDIO_DIRECT_MODE;
> > + iio->channels = hx711_chan_spec;
> > + iio->num_channels = ARRAY_SIZE(hx711_chan_spec);
> > +
> > + dev_err(hx711_data->dev, "initialized\n");
> > +
> > + return devm_iio_device_register(dev, iio);
> > +
> > +err:
> > + return ret;
> > +}
> > +
> > +
> > +static int hx711_suspend(struct device *dev)
> > +{
> > + return 0;
> > +}
> > +
> > +static int hx711_resume(struct device *dev)
> > +{
> > + return 0;
> > +}
> > +
> > +static SIMPLE_DEV_PM_OPS(hx711_pm_ops, hx711_suspend, hx711_resume);
> > +
> > +
> > +static const struct of_device_id of_hx711_match[] = {
> > + { .compatible = "avia,hx711", },
> > + {},
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, of_hx711_match);
> > +
> > +static struct platform_driver hx711_driver = {
> > + .probe = hx711_probe,
> > + .driver = {
> > + .name = "hx711-gpio",
> > + .pm = &hx711_pm_ops,
> > + .of_match_table = of_hx711_match,
> > + },
> > +};
> > +
> > +module_platform_driver(hx711_driver);
> > +
> > +MODULE_AUTHOR("Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>");
> > +MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
> > +MODULE_LICENSE("GPL");
> > +MODULE_ALIAS("platform:hx711-gpio");
> > +
> > --
> > 2.1.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" 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 pci/next] PCI: rcar: Add compatible string for r8a7796
From: Geert Uytterhoeven @ 2016-12-19 9:49 UTC (permalink / raw)
To: Yoshihiro Kaneko
Cc: linux-pci, Bjorn Helgaas, Simon Horman, Magnus Damm,
Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <1482064022-8998-1-git-send-email-ykaneko0929@gmail.com>
Hi Kaneko-san,
On Sun, Dec 18, 2016 at 1:27 PM, Yoshihiro Kaneko <ykaneko0929@gmail.com> wrote:
> From: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
>
> This patch adds support for r8a7796.
>
> Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> ---
>
> This patch is based on the next branch of the pci tree.
>
> Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
> drivers/pci/host/pcie-rcar.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index eee518d..34712d6 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -6,6 +6,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
> "renesas,pcie-r8a7791" for the R8A7791 SoC;
> "renesas,pcie-r8a7793" for the R8A7793 SoC;
> "renesas,pcie-r8a7795" for the R8A7795 SoC;
> + "renesas,pcie-r8a7796" for the R8A7796 SoC;
> "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
> "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
>
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index aca85be..02e5777 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1078,6 +1078,7 @@ static int rcar_pcie_parse_map_dma_ranges(struct rcar_pcie *pcie,
> { .compatible = "renesas,pcie-rcar-gen2",
> .data = rcar_pcie_hw_init_gen2 },
> { .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
> + { .compatible = "renesas,pcie-r8a7796", .data = rcar_pcie_hw_init },
> { .compatible = "renesas,pcie-rcar-gen3", .data = rcar_pcie_hw_init },
> {},
Given the driver already matches against "renesas,pcie-rcar-gen3",
and mainline arch/arm64/boot/dts/renesas/r8a7796.dtsi doesn't have pcie
nodes yet, I think there's no need to update the driver, only the bindings.
Hence if you drop the last chunk, you can add my
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ARM: dts: da850-lcdk: add gpio-keys
From: Bartosz Golaszewski @ 2016-12-19 9:53 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Russell King
Cc: arm-soc, linux-devicetree, LKML, Bartosz Golaszewski
Add a gpio-keys node for two user buttons present on the board.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 397c77a..628f4de 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -6,6 +6,7 @@
/dts-v1/;
#include "da850.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
/ {
model = "DA850/AM1808/OMAP-L138 LCDK";
@@ -90,6 +91,23 @@
};
};
};
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ user1 {
+ label = "GPIO Key USER1";
+ linux,code = <BTN_0>;
+ gpios = <&gpio 36 GPIO_ACTIVE_LOW>;
+ };
+
+ user2 {
+ label = "GPIO Key USER2";
+ linux,code = <BTN_1>;
+ gpios = <&gpio 37 GPIO_ACTIVE_LOW>;
+ };
+ };
};
&pmx_core {
--
2.9.3
^ permalink raw reply related
* Re: [PATCH/RFC v2 3/7] spi: core: Add support for registering SPI slave controllers
From: Geert Uytterhoeven @ 2016-12-19 10:02 UTC (permalink / raw)
To: Mark Brown
Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland, Magnus Damm,
Wolfram Sang, Hisashi Nakamura, Hiromitsu Yamasaki, linux-spi,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161215175326.tbblqe7kto2qgxwz-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Hi Mark,
On Thu, Dec 15, 2016 at 6:53 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Mon, Sep 12, 2016 at 10:50:42PM +0200, Geert Uytterhoeven wrote:
>> TBD:
>> - s/spi_master/spi_controller/ where appropriate,
>> - Provide wrappers (e.g. "#define spi_master spi_controller" until all
>> SPI drivers have been converted),
>> - Do we want a separate spi_register_slave() instead?
>
> This basically looks fine to me - there's these TBDs so I might be
> missing things and we probably need some GPIO chip select handling but
Given the hard real-time requirements of SPI slave, supporting GPIO chip
select may not be feasible.
> that's a separate thing. Sorry it took me so long to review this.
Thanks for the review!
As I managed to fix the issue with spi_slave_abort() on MSIOF, I think
the remaining
obstacle is the DT binding. Do you have any feedback or other
suggestions in that area?
IMHO having the ability to bind to an SPI slave handler either from DT or
by using the sysfs virtual file is useful to have.
Thanks again!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 v6 2/5] lib: implement __arch_bitrev8x4()
From: Will Deacon @ 2016-12-19 10:06 UTC (permalink / raw)
To: Joshua Clayton
Cc: Alan Tull, Moritz Fischer, Russell King, Catalin Marinas,
Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland, Rob Herring,
Anatolij Gustschin, devicetree, linux-kernel, linux-arm-kernel,
linux-fpga
In-Reply-To: <6c1c052d3c1d0c02a791aaaf8e114360ab1cb4e7.1481918884.git.stillcompiling@gmail.com>
On Fri, Dec 16, 2016 at 03:17:51PM -0800, Joshua Clayton wrote:
> Implement faster bitrev8x4() for arm, arm64 and mips, all the platforms
> with CONFIG_HAVE_ARCH_BITREVERSE.
> ARM platforms just need a byteswap added to the existing __arch_bitrev32()
> Amusingly, the mips implementation is exactly the opposite, requiring
> removal of the byteswap from its __arch_bitrev32()
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
> ---
> arch/arm/include/asm/bitrev.h | 6 ++++++
> arch/arm64/include/asm/bitrev.h | 6 ++++++
> arch/mips/include/asm/bitrev.h | 6 ++++++
> include/linux/bitrev.h | 1 +
> 4 files changed, 19 insertions(+)
>
> diff --git a/arch/arm/include/asm/bitrev.h b/arch/arm/include/asm/bitrev.h
> index ec291c3..9482f78 100644
> --- a/arch/arm/include/asm/bitrev.h
> +++ b/arch/arm/include/asm/bitrev.h
> @@ -17,4 +17,10 @@ static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
> return __arch_bitrev32((u32)x) >> 24;
> }
>
> +static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
> +{
> + __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
> + return x;
> +}
> +
> #endif
> diff --git a/arch/arm64/include/asm/bitrev.h b/arch/arm64/include/asm/bitrev.h
> index a5a0c36..1801078 100644
> --- a/arch/arm64/include/asm/bitrev.h
> +++ b/arch/arm64/include/asm/bitrev.h
> @@ -16,4 +16,10 @@ static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
> return __arch_bitrev32((u32)x) >> 24;
> }
>
> +static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
> +{
> + __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
This is broken -- you're operating on 64-bit registers. I only noticed
because if you write:
swab32(bitrev32(x))
then GCC generates:
rbit w0, w0
rev w0, w0
so perhaps we should just implement the asm-generic version like that
and not bother with the arch-specific stuff?
Will
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Maxime Ripard @ 2016-12-19 10:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Hans de Goede, Chen-Yu Tsai, linux-kernel,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <4720181481899200@web7g.yandex.ru>
[-- Attachment #1.1: Type: text/plain, Size: 2300 bytes --]
On Fri, Dec 16, 2016 at 10:40:00PM +0800, Icenowy Zheng wrote:
> >> > > &r_pio {
> >> > > wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
> >> > > - pins = "PL6", "PL7", "PL11";
> >> > > + pins = "PL6", "PL7", "PL8", "PL11";
> >> > > function = "gpio_in";
> >> > > bias-pull-up;
> >> > > };
> >> >
> >> > There's several things wrong here. The first one is that you rely
> >> > solely on the pinctrl state to maintain a reset line. This is very
> >> > fragile (especially since the GPIO pinctrl state are likely to go away
> >> > at some point), but it also means that if your driver wants to recover
> >> > from that situation at some point, it won't work.
> >> >
> >> > The other one is that the bluetooth and wifi chips are two devices in
> >> > linux, and you assign that pin to the wrong device (wifi).
> >> >
> >> > rfkill-gpio is made just for that, so please use it.
> >>
> >> The GPIO is not for the radio, but for the full Bluetooth part.
> >
> > I know.
> >
> >> If it's set to 0, then the bluetooth part will reset, and the
> >> hciattach will fail.
> >
> > Both rfkill-gpio and rfkill-regulator will shutdown when called
> > (either by poking the reset pin or shutting down the regulator), so
> > that definitely seems like an expected behavior to put the device in
> > reset.
> >
> >> The BSP uses this as a rfkill, and the result is that the bluetooth
> >> on/off switch do not work properly.
> >
> > Then rfkill needs fixing, but working around it by hoping that the
> > core will probe an entirely different device, and enforcing a default
> > that the rest of the kernel might or might not change is both fragile
> > and wrong.
>
> I think a rfkill-gpio here works just like the BSP rfkill...
>
> The real problem is that the Realtek UART bluetooth driver is a userspace
> program (a modified hciattach), which is not capable of the GPIO reset...
Can't you run rfkill before attaching? What is the problem exactly?
It's not in reset for long enough?
This seems more and more like an issue in the BT stack you're
using. We might consider workarounds in the kernel, but they have to
be correct.
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 v10 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Geert Uytterhoeven @ 2016-12-19 11:16 UTC (permalink / raw)
To: Joel Holdsworth
Cc: atull, Moritz Fischer, Rob Herring, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-spi, Marek Vasut, linux-fpga
In-Reply-To: <1482039234-21335-2-git-send-email-joel@airwebreathe.org.uk>
Hi Joel,
On Sun, Dec 18, 2016 at 6:33 AM, Joel Holdsworth
<joel@airwebreathe.org.uk> wrote:
> This adds documentation of the device tree bindings of the Lattice iCE40
> FPGA driver for the FPGA manager framework.
>
> Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Alan Tull <atull@opensource.altera.com>
> Acked-by: Moritz Fischer <moritz.fischer@ettus.com>
> Acked-by: Marek Vasut <marex@denx.de>
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> @@ -0,0 +1,21 @@
> +Lattice iCE40 FPGA Manager
> +
> +Required properties:
> +- compatible: Should contain "lattice,ice40-fpga-mgr"
> +- reg: SPI chip select
> +- spi-max-frequency: Maximum SPI frequency (>=1000000, <=25000000)
> +- cdone-gpios: GPIO input connected to CDONE pin
> +- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
> + that unless the GPIO is held low during startup, the
> + FPGA will enter Master SPI mode and drive SCK with a
> + clock signal potentially jamming other devices on the
> + bus until the firmware is loaded.
> +
> +Example:
> + ice40: ice40@0 {
As per ePAPR, node names should be generic names, e.g. "fpga@0".
Sorry for not noticing before.
> + compatible = "lattice,ice40-fpga-mgr";
> + reg = <0>;
> + spi-max-frequency = <1000000>;
> + cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
> + };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Matt Redfearn @ 2016-12-19 12:04 UTC (permalink / raw)
To: Serge Semin, ralf, paul.burton, rabinv, james.hogan,
alexander.sverdlin, robh+dt, frowand.list
Cc: Sergey.Semin, linux-mips, devicetree, linux-kernel
In-Reply-To: <1482113266-13207-20-git-send-email-fancer.lancer@gmail.com>
Hi Serge,
On 19/12/16 02:07, Serge Semin wrote:
> It's useful to have some printed map of the kernel virtual memory,
> at least for debugging purpose.
>
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> ---
> arch/mips/mm/init.c | 47 +++++++++++++++++++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
> index 13a032f..35e7ba8 100644
> --- a/arch/mips/mm/init.c
> +++ b/arch/mips/mm/init.c
> @@ -32,6 +32,7 @@
> #include <linux/hardirq.h>
> #include <linux/gfp.h>
> #include <linux/kcore.h>
> +#include <linux/sizes.h>
>
> #include <asm/asm-offsets.h>
> #include <asm/bootinfo.h>
> @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> }
>
> /*
> + * Print out kernel memory layout
> + */
> +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> +static void __init mem_print_kmap_info(void)
> +{
> + pr_notice("Virtual kernel memory layout:\n"
> + " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n"
> + " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n"
> +#ifdef CONFIG_HIGHMEM
> + " pkmap : 0x%08lx - 0x%08lx (%4ld MB)\n"
> +#endif
> + " fixmap : 0x%08lx - 0x%08lx (%4ld kB)\n"
> + " .text : 0x%p" " - 0x%p" " (%4td kB)\n"
> + " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
> + " .init : 0x%p" " - 0x%p" " (%4td kB)\n",
> + MLM(PAGE_OFFSET, (unsigned long)high_memory),
> + MLM(VMALLOC_START, VMALLOC_END),
> +#ifdef CONFIG_HIGHMEM
> + MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> +#endif
> + MLK(FIXADDR_START, FIXADDR_TOP),
> + MLK_ROUNDUP(_text, _etext),
> + MLK_ROUNDUP(_sdata, _edata),
> + MLK_ROUNDUP(__init_begin, __init_end));
Please drop printing the kernel addresses, or at least only do it if
KASLR is not turned on, otherwise you're removing the advantage of
KASLR, that critical kernel addresses cannot be determined easily from
userspace.
It may be better to merge the functionality of show_kernel_relocation
http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
into this function, but only print it under the same conditions as
currently, i.e.
#if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
Thanks,
Matt
> +
> + /* Check some fundamental inconsistencies. May add something else? */
> +#ifdef CONFIG_HIGHMEM
> + BUILD_BUG_ON(VMALLOC_END < PAGE_OFFSET);
> + BUG_ON(VMALLOC_END < (unsigned long)high_memory);
> +#endif
> + BUILD_BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) < PAGE_OFFSET);
> + BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) <
> + (unsigned long)high_memory);
> + BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
> + BUG_ON(FIXADDR_TOP < (unsigned long)high_memory);
> +}
> +#undef MLK
> +#undef MLM
> +#undef MLK_ROUNDUP
> +
> +/*
> * Not static inline because used by IP27 special magic initialization code
> */
> void setup_zero_pages(void)
> @@ -492,6 +536,9 @@ void __init mem_init(void)
> /* Free highmemory registered in memblocks */
> mem_init_free_highmem();
>
> + /* Print out kernel memory layout */
> + mem_print_kmap_info();
> +
> /* Print out memory areas statistics */
> mem_init_print_info(NULL);
>
^ permalink raw reply
* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Serge Semin @ 2016-12-19 12:09 UTC (permalink / raw)
To: Matt Redfearn
Cc: ralf, paul.burton, rabinv, james.hogan, alexander.sverdlin,
robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
linux-kernel
In-Reply-To: <db27f41e-4121-bb83-6533-6727c26b9c5b@imgtec.com>
On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn <matt.redfearn@imgtec.com> wrote:
Hello Matt.
> Hi Serge,
>
>
> On 19/12/16 02:07, Serge Semin wrote:
> >It's useful to have some printed map of the kernel virtual memory,
> >at least for debugging purpose.
> >
> >Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> >---
> > arch/mips/mm/init.c | 47 +++++++++++++++++++++++++++++++++++
> > 1 file changed, 47 insertions(+)
> >
> >diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
> >index 13a032f..35e7ba8 100644
> >--- a/arch/mips/mm/init.c
> >+++ b/arch/mips/mm/init.c
> >@@ -32,6 +32,7 @@
> > #include <linux/hardirq.h>
> > #include <linux/gfp.h>
> > #include <linux/kcore.h>
> >+#include <linux/sizes.h>
> > #include <asm/asm-offsets.h>
> > #include <asm/bootinfo.h>
> >@@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> > }
> > /*
> >+ * Print out kernel memory layout
> >+ */
> >+#define MLK(b, t) b, t, ((t) - (b)) >> 10
> >+#define MLM(b, t) b, t, ((t) - (b)) >> 20
> >+#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> >+static void __init mem_print_kmap_info(void)
> >+{
> >+ pr_notice("Virtual kernel memory layout:\n"
> >+ " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n"
> >+ " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n"
> >+#ifdef CONFIG_HIGHMEM
> >+ " pkmap : 0x%08lx - 0x%08lx (%4ld MB)\n"
> >+#endif
> >+ " fixmap : 0x%08lx - 0x%08lx (%4ld kB)\n"
> >+ " .text : 0x%p" " - 0x%p" " (%4td kB)\n"
> >+ " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
> >+ " .init : 0x%p" " - 0x%p" " (%4td kB)\n",
> >+ MLM(PAGE_OFFSET, (unsigned long)high_memory),
> >+ MLM(VMALLOC_START, VMALLOC_END),
> >+#ifdef CONFIG_HIGHMEM
> >+ MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> >+#endif
> >+ MLK(FIXADDR_START, FIXADDR_TOP),
> >+ MLK_ROUNDUP(_text, _etext),
> >+ MLK_ROUNDUP(_sdata, _edata),
> >+ MLK_ROUNDUP(__init_begin, __init_end));
>
> Please drop printing the kernel addresses, or at least only do it if KASLR
> is not turned on, otherwise you're removing the advantage of KASLR, that
> critical kernel addresses cannot be determined easily from userspace.
>
> It may be better to merge the functionality of show_kernel_relocation
> http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> into this function, but only print it under the same conditions as
> currently, i.e.
> #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
>
> Thanks,
> Matt
>
Understood. Will be fixed within the next patchset.
> >+
> >+ /* Check some fundamental inconsistencies. May add something else? */
> >+#ifdef CONFIG_HIGHMEM
> >+ BUILD_BUG_ON(VMALLOC_END < PAGE_OFFSET);
> >+ BUG_ON(VMALLOC_END < (unsigned long)high_memory);
> >+#endif
> >+ BUILD_BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) < PAGE_OFFSET);
> >+ BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) <
> >+ (unsigned long)high_memory);
> >+ BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
> >+ BUG_ON(FIXADDR_TOP < (unsigned long)high_memory);
> >+}
> >+#undef MLK
> >+#undef MLM
> >+#undef MLK_ROUNDUP
> >+
> >+/*
> > * Not static inline because used by IP27 special magic initialization code
> > */
> > void setup_zero_pages(void)
> >@@ -492,6 +536,9 @@ void __init mem_init(void)
> > /* Free highmemory registered in memblocks */
> > mem_init_free_highmem();
> >+ /* Print out kernel memory layout */
> >+ mem_print_kmap_info();
> >+
> > /* Print out memory areas statistics */
> > mem_init_print_info(NULL);
>
^ permalink raw reply
* [PATCH v10 8/8] dt-bindings: mmc: Add Cavium SOCs MMC bindings
From: Jan Glauber @ 2016-12-19 12:15 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, linux-kernel, David Daney, Steven J . Hill,
Jan Glauber, Rob Herring, Mark Rutland, devicetree
In-Reply-To: <20161219121552.18316-1-jglauber@cavium.com>
Add description of Cavium Octeon and ThunderX SOC device tree bindings.
CC: Ulf Hansson <ulf.hansson@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Mark Rutland <mark.rutland@arm.com>
CC: devicetree@vger.kernel.org
Signed-off-by: Jan Glauber <jglauber@cavium.com>
---
.../devicetree/bindings/mmc/octeon-mmc.txt | 59 ++++++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/octeon-mmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/octeon-mmc.txt b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
new file mode 100644
index 0000000..aad02eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
@@ -0,0 +1,59 @@
+* Cavium Octeon & ThunderX MMC controller
+
+The highspeed MMC host controller on Caviums SoCs provides an interface
+for MMC and SD types of memory cards.
+
+Supported maximum speeds are the ones of the eMMC standard 4.41 as well
+as the speed of SD standard 4.0. Only 3.3 Volt is supported.
+
+Required properties:
+ - compatible : should be one of:
+ * "cavium,octeon-6130-mmc"
+ * "cavium,octeon-6130-mmc-slot"
+ * "cavium,octeon-7890-mmc"
+ * "cavium,octeon-7890-mmc-slot"
+ * "cavium,thunder-8190-mmc"
+ * "cavium,thunder-8190-mmc-slot"
+ * "cavium,thunder-8390-mmc"
+ * "cavium,thunder-8390-mmc-slot"
+ - reg : mmc controller base registers
+ - clocks : phandle
+
+Optional properties:
+ - for cd, bus-width and additional generic mmc parameters
+ please refer to mmc.txt within this directory
+ - "cavium,cmd-clk-skew" : number of coprocessor clocks before sampling command
+ - "cavium,dat-clk-skew" : number of coprocessor clocks before sampling data
+
+Deprecated properties:
+- spi-max-frequency : use max-frequency instead
+- "cavium,bus-max-width" : use bus-width instead
+
+Examples:
+ - Within .dtsi:
+ mmc_1_4: mmc@1,4 {
+ compatible = "cavium,thunder-8390-mmc";
+ reg = <0x0c00 0 0 0 0>; /* DEVFN = 0x0c (1:4) */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&sclk>;
+ };
+
+ - Within dts:
+ mmc-slot@0 {
+ compatible = "cavium,thunder-8390-mmc-slot";
+ reg = <0>;
+ voltage-ranges = <3300 3300>;
+ max-frequency = <42000000>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ };
+ mmc-slot@1 {
+ compatible = "cavium,thunder-8390-mmc-slot";
+ reg = <1>;
+ voltage-ranges = <3300 3300>;
+ max-frequency = <42000000>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ non-removable;
+ };
--
2.9.0.rc0.21.g7777322
^ permalink raw reply related
* Re: [PATCH v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Quentin Schulz @ 2016-12-19 12:28 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Russell King,
Maxime Ripard, Lee Jones, open list:THERMAL, devicetree,
linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <CAGb2v66jDsU2rt4d-0ydWR926y-hHTfOBJQmyYVdKd7rcm1WWQ@mail.gmail.com>
Hi Chen-Yu,
On 14/12/2016 16:43, Chen-Yu Tsai wrote:
> On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
>> The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
>> and minimum current delivered by the VBUS power supply.
>>
>> This adds the register used by the VBUS power supply driver to the range
>> of volatile and writeable regs ranges.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>> ---
>>
>> added in v2
>>
>> drivers/mfd/axp20x.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> index ba130be..6ee2cc6 100644
>> --- a/drivers/mfd/axp20x.c
>> +++ b/drivers/mfd/axp20x.c
>> @@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
>>
>> static const struct regmap_range axp20x_writeable_ranges[] = {
>> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
>> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
>
> This is already covered by the previous entry.
>
>> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
>> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
>> };
>>
>> static const struct regmap_range axp20x_volatile_ranges[] = {
>> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
>> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
>
> And I'm not sure why you specify it as volatile? The PMIC doesn't change any
> of the bits in this register on its own.
>
I got things mixed up between the work on the battery driver I'll soon
send (which actually needs updated reg ranges) and this VBUS driver.
Sorry for that.
> Same for the AXP22x bits. So basically I think you don't need this patch.
>
Indeed. Should I send a v3 to remove this patch or is it fine for you to
ignore this one?
Thanks!
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Lee Jones @ 2016-12-19 12:55 UTC (permalink / raw)
To: Rob Herring
Cc: Benjamin Gaignard, Mark Rutland, Alexandre Torgue,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Thierry Reding, Linux PWM List, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Fabrice Gasnier, Gerald Baeza, Arnaud POULIQUEN
In-Reply-To: <CAL_JsqL8pJSFb8LbABAYJOQ0URaMpyupbFryk_mS2ToN1kStdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 13 Dec 2016, Rob Herring wrote:
> On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, 12 Dec 2016, Rob Herring wrote:
> >
> >> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
> >> > Define bindings for pwm-stm32
> >> >
> >> > version 6:
> >> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
> >> >
> >> > version 2:
> >> > - use parameters instead of compatible of handle the hardware configuration
> >> >
> >> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> >> > ---
> >> > .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
> >> > 1 file changed, 33 insertions(+)
> >> > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> > new file mode 100644
> >> > index 0000000..866f222
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> > @@ -0,0 +1,33 @@
> >> > +STMicroelectronics STM32 Timers PWM bindings
> >> > +
> >> > +Must be a sub-node of an STM32 Timers device tree node.
> >> > +See ../mfd/stm32-timers.txt for details about the parent node.
> >> > +
> >> > +Required parameters:
> >> > +- compatible: Must be "st,stm32-pwm".
> >> > +- pinctrl-names: Set to "default".
> >> > +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
> >> > + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
> >> > +
> >> > +Optional parameters:
> >> > +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
> >> > + "index" indicates on which break input the configuration should be applied.
> >> > + "level" gives the active level (0=low or 1=high) for this configuration.
> >> > + "filter" gives the filtering value to be applied.
> >> > +
> >> > +Example:
> >> > + timers@40010000 {
> >>
> >> timer@...
> >
> > No, it should be timers.
>
> Read the spec. "timer" is a generic node name. "timers" is not. How
> many is not relevant.
It's not the amount of timers that there are, it's the different types
of timers which this one IP contains.
In MFD we usually list the part number or IP name, however in this
case its difficult because the same IP doesn't have a specific name
listed, and provides; advanced, general purpose and basic timers, as
well as PWM functionality.
This IP is not a timer (although one of its children is one). It's
the parent device of many different types of timer.
timer {
timer {
};
pwm {
};
};
... looks weird.
"timer" is not right for the parent IP. Happy for you to provide an
alternative to "timers" though?
> > The 's' is intentional, since this parent (MFD) device houses 3
> > different types of timers. The "timer" node is a child of this one.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v7 1/2] mtd: nand: add tango NFC dt bindings doc
From: Boris Brezillon @ 2016-12-19 12:59 UTC (permalink / raw)
To: Marc Gonzalez
Cc: Arnd Bergmann, linux-mtd, Richard Weinberger, DT, Rob Herring,
Mark Rutland, Mason, Sebastian Frias
In-Reply-To: <d3cbfda6-23bf-4ad1-b1ce-c179b765272f-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
On Fri, 16 Dec 2016 11:56:38 +0100
Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org> wrote:
> On 07/11/2016 10:18, Arnd Bergmann wrote:
> > On Tuesday, October 25, 2016 3:15:50 PM CET Marc Gonzalez wrote:
> >> Add the tango NAND Flash Controller dt bindings documentation.
> >>
> >> Signed-off-by: Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/mtd/tango-nand.txt | 38 ++++++++++++++++++++++++++++++
> >> 1 file changed, 38 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> >> new file mode 100644
> >> index 000000000000..3cbf95d6595a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> >> @@ -0,0 +1,38 @@
> >> +Sigma Designs Tango4 NAND Flash Controller (NFC)
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: "sigma,smp8758-nand"
> >> +- reg: address/size of nfc_reg, nfc_mem, and pbus_reg
> >> +- dmas: reference to the DMA channel used by the controller
> >> +- dma-names: "nfc_sbox"
> >
> > Drop the "nfc_" prefix here, it seems redundant.
>
> I took a closer look at Documentation/devicetree/bindings and
> arch/arm/boot/dts and it seems the overwhelming nomenclature
> is "rx", "tx" (with variants around these two).
>
> Should I just use "rxtx" for my driver?
>
> >> +- clocks: reference to the system clock
> >> +- #address-cells: <1>
> >> +- #size-cells: <0>
> >> +
> >> +Children nodes represent the available NAND chips.
> >> +See Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
> >> +
> >> +Example:
> >> +
> >> + nand: nand@2c000 {
> >> + compatible = "sigma,smp8758-nand";
> >> + reg = <0x2c000 0x30 0x2d000 0x800 0x20000 0x1000>;
> >
> > It would be nicer to write this as
> >
> > reg = <0x2c000 0x30>, <0x2d000 0x800>, <0x20000 0x1000>;
> >
> > which is identical in binary format.
>
> This is indeed a marked improvement. Boris, if I fix these two nits,
> can I submit a single patch, or do you want them split?
Sure, just describe the different binding changes in your commit
message.
--
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 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: James Hogan @ 2016-12-19 13:02 UTC (permalink / raw)
To: Matt Redfearn
Cc: Serge Semin, ralf, paul.burton, rabinv, alexander.sverdlin,
robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
linux-kernel
In-Reply-To: <db27f41e-4121-bb83-6533-6727c26b9c5b@imgtec.com>
[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
Hi Matt,
On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn wrote:
> On 19/12/16 02:07, Serge Semin wrote:
> > It's useful to have some printed map of the kernel virtual memory,
> > at least for debugging purpose.
> >
> > Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> > ---
> > @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> > }
> >
> > /*
> > + * Print out kernel memory layout
> > + */
> > +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> > +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> > +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> > +static void __init mem_print_kmap_info(void)
> > +{
> > + pr_notice("Virtual kernel memory layout:\n"
> > + " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > + " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > +#ifdef CONFIG_HIGHMEM
> > + " pkmap : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > +#endif
> > + " fixmap : 0x%08lx - 0x%08lx (%4ld kB)\n"
> > + " .text : 0x%p" " - 0x%p" " (%4td kB)\n"
> > + " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
> > + " .init : 0x%p" " - 0x%p" " (%4td kB)\n",
> > + MLM(PAGE_OFFSET, (unsigned long)high_memory),
> > + MLM(VMALLOC_START, VMALLOC_END),
> > +#ifdef CONFIG_HIGHMEM
> > + MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> > +#endif
> > + MLK(FIXADDR_START, FIXADDR_TOP),
> > + MLK_ROUNDUP(_text, _etext),
> > + MLK_ROUNDUP(_sdata, _edata),
> > + MLK_ROUNDUP(__init_begin, __init_end));
>
> Please drop printing the kernel addresses, or at least only do it if
> KASLR is not turned on, otherwise you're removing the advantage of
> KASLR, that critical kernel addresses cannot be determined easily from
> userspace.
According to Documentation/printk-formats.txt, this is what %pK is for.
Better to use that instead?
Cheers
James
>
> It may be better to merge the functionality of show_kernel_relocation
> http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> into this function, but only print it under the same conditions as
> currently, i.e.
> #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
>
> Thanks,
> Matt
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Serge Semin @ 2016-12-19 13:15 UTC (permalink / raw)
To: James Hogan
Cc: Matt Redfearn, ralf, paul.burton, rabinv, alexander.sverdlin,
robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
linux-kernel
In-Reply-To: <20161219130236.GJ27950@jhogan-linux.le.imgtec.org>
On Mon, Dec 19, 2016 at 01:02:37PM +0000, James Hogan <james.hogan@imgtec.com> wrote:
> Hi Matt,
>
> On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn wrote:
> > On 19/12/16 02:07, Serge Semin wrote:
> > > It's useful to have some printed map of the kernel virtual memory,
> > > at least for debugging purpose.
> > >
> > > Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> > > ---
>
> > > @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> > > }
> > >
> > > /*
> > > + * Print out kernel memory layout
> > > + */
> > > +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> > > +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> > > +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> > > +static void __init mem_print_kmap_info(void)
> > > +{
> > > + pr_notice("Virtual kernel memory layout:\n"
> > > + " lowmem : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > > + " vmalloc : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > > +#ifdef CONFIG_HIGHMEM
> > > + " pkmap : 0x%08lx - 0x%08lx (%4ld MB)\n"
> > > +#endif
> > > + " fixmap : 0x%08lx - 0x%08lx (%4ld kB)\n"
> > > + " .text : 0x%p" " - 0x%p" " (%4td kB)\n"
> > > + " .data : 0x%p" " - 0x%p" " (%4td kB)\n"
> > > + " .init : 0x%p" " - 0x%p" " (%4td kB)\n",
> > > + MLM(PAGE_OFFSET, (unsigned long)high_memory),
> > > + MLM(VMALLOC_START, VMALLOC_END),
> > > +#ifdef CONFIG_HIGHMEM
> > > + MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> > > +#endif
> > > + MLK(FIXADDR_START, FIXADDR_TOP),
> > > + MLK_ROUNDUP(_text, _etext),
> > > + MLK_ROUNDUP(_sdata, _edata),
> > > + MLK_ROUNDUP(__init_begin, __init_end));
> >
> > Please drop printing the kernel addresses, or at least only do it if
> > KASLR is not turned on, otherwise you're removing the advantage of
> > KASLR, that critical kernel addresses cannot be determined easily from
> > userspace.
>
> According to Documentation/printk-formats.txt, this is what %pK is for.
> Better to use that instead?
>
> Cheers
> James
>
The function is called from the kernel directly, which is privileged
enough to do the printing. So I suppose Matt is right, to hide this
prints out unless debug is enabled.
Thanks,
-Sergey
> >
> > It may be better to merge the functionality of show_kernel_relocation
> > http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> > into this function, but only print it under the same conditions as
> > currently, i.e.
> > #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> > http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
> >
> > Thanks,
> > Matt
^ 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