* [PATCH 0/3] Add clock and power domain DT nodes for Mediatek MT2701
From: James Liao @ 2016-12-28 5:46 UTC (permalink / raw)
To: Rob Herring, Russell King, Matthias Brugger
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
This patch series base on v4.10-rc1, include MT2701 power domain and clock
DT nodes.
An early patch [1] which was not applied in v4.10-rc1 also included in this
patch series.
[1] https://patchwork.kernel.org/patch/9457625/
James Liao (3):
arm: dts: mt2701: Sort DT nodes by register address
arm: dts: mt2701: Add subsystem clock controller device nodes
arm: dts: mt2701: Add power domain controller device node
arch/arm/boot/dts/mt2701.dtsi | 84 +++++++++++++++++++++++++++++++++----------
1 file changed, 66 insertions(+), 18 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy
From: Vivek Gautam @ 2016-12-28 5:40 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, kishon, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, Mark Rutland, Srinivas Kandagatla,
linux-arm-msm
In-Reply-To: <a4fc38f0-425d-5d4f-7fe9-8245b5b9c3af@codeaurora.org>
On Wed, Dec 28, 2016 at 6:43 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 12/22/2016 08:52 PM, Vivek Gautam wrote:
>>
>>>> +
>>>> +Optional properties:
>>>> + - nvmem-cells: a list of phandles to nvmem cells that contain fused
>>>> + tuning parameters for qusb2 phy, one for each entry
>>>> + in nvmem-cell-names.
>>>> + - nvmem-cell-names: must be "tune2_hstx_trim" for cell containing
>>>> + HS Tx trim value.
>>> ditto.
>> nvmem doesn't allow, at this point, to get the cells by index.
>> Its APIs take 'const char' cell id and get the cell.
>>
>> We should add this support to get the cell by index.
>> Will create a patch for that, and drop the '-names' property from bindings.
>>
>
> If we introduce a cells based API just for this case of one phandle it
> may make sense to allow the cell id to be NULL and default to whatever
> cell is there without a names property. We do something similar with
> clks where a NULL connection id defaults to the first phandle in the
> list. Then we can avoid having a new set of DT specific APIs here. Of
> course, documentation should be updated to indicate that a NULL cell_id
> means use index 0 with DT.
Right. This makes sense. I didn't notice that we do something
similar in clocks.
I will post a new change for this (which should be pretty small
in comparison to earlier patchset that introduced new dt based APIs).
>
> --
> 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 linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: AKASHI Takahiro @ 2016-12-28 4:37 UTC (permalink / raw)
To: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: james.morse-5wv7dgnIgG8, geoff-wEGCiKHe2LqWVfeAwA7xHQ,
bauerman-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
dyoung-H+wXaHxf7aLQT0dZR+AlfA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, AKASHI Takahiro
In-Reply-To: <20161228043347.27358-1-takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
From: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
Add documentation for
linux,crashkernel-base and crashkernel-size,
linux,usable-memory-range
linux,elfcorehdr
used by arm64 kdump to decribe the kdump reserved area, and
the elfcorehdr's location within it.
Signed-off-by: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
[takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org: added "linux,crashkernel-base" and "-size" ]
Signed-off-by: AKASHI Takahiro <takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
---
Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 6ae9d82d4c37..7b115165e9ec 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -52,3 +52,53 @@ This property is set (currently only on PowerPC, and only needed on
book3e) by some versions of kexec-tools to tell the new kernel that it
is being booted by kexec, as the booting environment may differ (e.g.
a different secondary CPU release mechanism)
+
+linux,crashkernel-base
+linux,crashkernel-size
+----------------------
+
+These properties (currently used on PowerPC and arm64) indicates
+the base address and the size, respectively, of the reserved memory
+range for crash dump kernel.
+e.g.
+
+/ {
+ chosen {
+ linux,crashkernel-base = <0x9 0xf0000000>;
+ linux,crashkernel-size = <0x0 0x10000000>;
+ };
+};
+
+linux,usable-memory-range
+-------------------------
+
+This property (currently used only on arm64) holds the memory range,
+the base address and the size, which can be used as system ram on
+the *current* kernel. Note that, if this property is present, any memory
+regions under "memory" nodes in DT blob or ones marked as "conventional
+memory" in EFI memory map should be ignored.
+e.g.
+
+/ {
+ chosen {
+ linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
+ };
+};
+
+The main usage is for crash dump kernel to identify its own usable
+memory and exclude, at its boot time, any other memory areas that are
+part of the panicked kernel's memory.
+
+linux,elfcorehdr
+----------------
+
+This property (currently used only on arm64) holds the memory range,
+the address and the size, of the elf core header which mainly describes
+the panicked kernel's memory layout as PT_LOAD segments of elf format.
+e.g.
+
+/ {
+ chosen {
+ linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>;
+ };
+};
--
2.11.0
--
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
* Re: [RFC PATCH 1/6] phy: exynos-pcie: Add support for Exynos PCIe phy
From: Jaehoon Chung @ 2016-12-28 2:49 UTC (permalink / raw)
To: Vivek Gautam
Cc: linux-pci, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
Bjorn Helgaas, robh+dt, Mark Rutland, Kukjin Kim, krzk, javier,
kishon, Will Deacon, catalin.marinas, CPGS
In-Reply-To: <CAFp+6iH0q9TNvPgv3_Nexm-vE6TBB_eQHXCwniO-Yn=fq+WWMg@mail.gmail.com>
Hi Vivek,
On 12/27/2016 02:53 PM, Vivek Gautam wrote:
> Hi Jaehoon,
>
>
> On Mon, Dec 26, 2016 at 10:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>> This patch supports to use Generic Phy framework for Exynos PCIe phy.
>> When Exynos that supported the pcie want to use the PCIe,
>> it needs to control the phy resgister.
>> But it should be more complex to control in their own PCIe device drivers.
>>
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> ---
>> drivers/phy/Kconfig | 9 ++
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-exynos-pcie.c | 227 ++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 237 insertions(+)
>> create mode 100644 drivers/phy/phy-exynos-pcie.c
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index fe00f91..94b0433 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -341,6 +341,15 @@ config PHY_EXYNOS5_USBDRD
>> This driver provides PHY interface for USB 3.0 DRD controller
>> present on Exynos5 SoC series.
>>
>> +config PHY_EXYNOS_PCIE
>> + bool "Exynos PCIe PHY driver"
>
> Is there a reason for this not being 'tristate' ?
Will change.
>
>> + depends on ARCH_EXYNOS && OF
>> + depends on PCI_EXYNOS5433
>> + select GENERIC_PHY
>> + help
>> + Enable PCIe PHY support for Exynos SoC series.
>
> If this driver is for Exynos5433, then same should come in this help
> text as well.
will support the other exynos series.
I'm working on refactoring exynos5440 with PHY generic Framework.
Then this drive is not for only Exnyos5433. how about?
>
>> + This driver provides PHY interface for Exynos PCIe controller.
>> +
>> config PHY_PISTACHIO_USB
>> tristate "IMG Pistachio USB2.0 PHY driver"
>> depends on MACH_PISTACHIO
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index a534cf5..586344d 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
>> phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
>> phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
>> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>> +obj-$(CONFIG_PHY_EXYNOS_PCIE) += phy-exynos-pcie.o
>> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
>> obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>> obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o
>> diff --git a/drivers/phy/phy-exynos-pcie.c b/drivers/phy/phy-exynos-pcie.c
>> new file mode 100644
>> index 0000000..0f5eefd
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos-pcie.c
>> @@ -0,0 +1,227 @@
>> +/*
>> + * Samsung EXYNOS SoC series PCIe PHY driver
>> + *
>> + * Phy provider for PCIe controller on Exynos SoC series
>> + *
>> + * Copyright (C) 2016 Samsung Electronics Co., Ltd.
>> + * Jaehoon Chung <jh80.chung@samsung.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/mfd/syscon.h>
>
> nit: It's good to have these includes in alphabetical order.
Will fix.
>
>> +
>> +#define PCIE_EXYNOS5433_PMU_PHY_OFFSET 0x730
>> +#define PCIE_PHY_OFFSET(x) ((x) * 0x4)
>> +
>> +/* Sysreg Fsys register offset and bit for Exynos5433 */
>> +#define PCIE_PHY_MAC_RESET 0x208
>> +#define PCIE_MAC_RESET_MASK 0xFF
>> +#define PCIE_MAC_RESET BIT(4)
>> +#define PCIE_L1SUB_CM_CON 0x1010
>> +#define PCIE_REFCLK_GATING_EN BIT(0)
>> +#define PCIE_PHY_COMMON_RESET 0x1020
>> +#define PCIE_PHY_RESET BIT(0)
>> +#define PCIE_PHY_GLOBAL_RESET 0x1040
>> +#define PCIE_GLOBAL_RESET BIT(0)
>> +#define PCIE_REFCLK BIT(1)
>> +#define PCIE_REFCLK_MASK 0x16
>> +#define PCIE_APP_REQ_EXIT_L1_MODE BIT(5)
>> +
>> +enum exynos_pcie_phy_data_type {
>> + PCIE_PHY_TYPE_EXYNOS5433,
>> +};
>> +
>> +struct exynos_pcie_phy_data {
>> + enum exynos_pcie_phy_data_type ctrl_type;
>
> Why do we need this controller type ?
> If there are changes in the IP between different version,
> then you can as well use different compatibles.
Do you mean is the using "of_device_is_compatible()"?
>
>> + u32 pmureg_offset; /* PMU_REG offset */
>
> Please use top comments.
>
>> + struct phy_ops *ops;
>> +};
>> +
>> +/* for Exynos pcie phy */
>> +struct exynos_pcie_phy {
>> + const struct exynos_pcie_phy_data *drv_data;
>> + struct regmap *pmureg;
>> + struct regmap *fsysreg;
>> + void __iomem *phy_base;
>
> just 'base' ?
Will change
>
>> +};
>> +
>> +static void exynos_pcie_phy_writel(void __iomem *base, u32 val, u32 offset)
>> +{
>> + writel(val, base + offset);
>> +}
>> +
>> +static int exynos_pcie_phy_init(struct phy *phy)
>> +{
>> + struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
>> +
>> + if (ep->fsysreg) {
>> + regmap_update_bits(ep->fsysreg, PCIE_PHY_COMMON_RESET,
>> + PCIE_PHY_RESET, 1);
>> + regmap_update_bits(ep->fsysreg, PCIE_PHY_MAC_RESET,
>> + PCIE_MAC_RESET, 0);
>> + /* PHY refclk 24MHz */
>> + regmap_update_bits(ep->fsysreg, PCIE_PHY_GLOBAL_RESET,
>> + PCIE_REFCLK_MASK, PCIE_REFCLK);
>> + regmap_update_bits(ep->fsysreg, PCIE_PHY_GLOBAL_RESET,
>> + PCIE_GLOBAL_RESET, 0);
>> + }
>> +
>> + exynos_pcie_phy_writel(ep->phy_base, 0x11, PCIE_PHY_OFFSET(0x3));
>> +
>> + /* band gap reference on */
>> + exynos_pcie_phy_writel(ep->phy_base, 0, PCIE_PHY_OFFSET(0x20));
>> + exynos_pcie_phy_writel(ep->phy_base, 0, PCIE_PHY_OFFSET(0x4b));
>> +
>> + /* jitter tunning */
>> + exynos_pcie_phy_writel(ep->phy_base, 0x34, PCIE_PHY_OFFSET(0x4));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x02, PCIE_PHY_OFFSET(0x7));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x41, PCIE_PHY_OFFSET(0x21));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x7F, PCIE_PHY_OFFSET(0x14));
>> + exynos_pcie_phy_writel(ep->phy_base, 0xC0, PCIE_PHY_OFFSET(0x15));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x61, PCIE_PHY_OFFSET(0x36));
>> +
>> + /* D0 uninit.. */
>> + exynos_pcie_phy_writel(ep->phy_base, 0x44, PCIE_PHY_OFFSET(0x3D));
>> +
>> + /* 24MHz */
>> + exynos_pcie_phy_writel(ep->phy_base, 0x94, PCIE_PHY_OFFSET(0x8));
>> + exynos_pcie_phy_writel(ep->phy_base, 0xA7, PCIE_PHY_OFFSET(0x9));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x93, PCIE_PHY_OFFSET(0xA));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x6B, PCIE_PHY_OFFSET(0xC));
>> + exynos_pcie_phy_writel(ep->phy_base, 0xA5, PCIE_PHY_OFFSET(0xF));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x34, PCIE_PHY_OFFSET(0x16));
>> + exynos_pcie_phy_writel(ep->phy_base, 0xA3, PCIE_PHY_OFFSET(0x17));
>> + exynos_pcie_phy_writel(ep->phy_base, 0xA7, PCIE_PHY_OFFSET(0x1A));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x71, PCIE_PHY_OFFSET(0x23));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x4C, PCIE_PHY_OFFSET(0x24));
>> +
>> + exynos_pcie_phy_writel(ep->phy_base, 0x0E, PCIE_PHY_OFFSET(0x26));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x14, PCIE_PHY_OFFSET(0x7));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x48, PCIE_PHY_OFFSET(0x43));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x44, PCIE_PHY_OFFSET(0x44));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x03, PCIE_PHY_OFFSET(0x45));
>> + exynos_pcie_phy_writel(ep->phy_base, 0xA7, PCIE_PHY_OFFSET(0x48));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x13, PCIE_PHY_OFFSET(0x54));
>> + exynos_pcie_phy_writel(ep->phy_base, 0x04, PCIE_PHY_OFFSET(0x31));
>> + exynos_pcie_phy_writel(ep->phy_base, 0, PCIE_PHY_OFFSET(0x32));
>> +
>> + if (ep->fsysreg) {
>> + regmap_update_bits(ep->fsysreg, PCIE_PHY_COMMON_RESET,
>> + PCIE_PHY_RESET, 0);
>> + regmap_update_bits(ep->fsysreg, PCIE_PHY_MAC_RESET,
>> + PCIE_MAC_RESET_MASK, PCIE_MAC_RESET);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int exynos_pcie_phy_power_on(struct phy *phy)
>> +{
>> + struct exynos_pcie_phy *ep = phy_get_drvdata(phy);
>> +
>> + if (ep->pmureg) {
>> + if (regmap_update_bits(ep->pmureg, ep->drv_data->pmureg_offset,
>> + BIT(0), 1))
>> + dev_warn(&phy->dev, "Failed to update regmap bit.\n");
>> + }
>> +
>> + if (ep->fsysreg) {
>> + regmap_update_bits(ep->fsysreg, PCIE_PHY_GLOBAL_RESET,
>> + PCIE_APP_REQ_EXIT_L1_MODE, 0);
>> + regmap_update_bits(ep->fsysreg, PCIE_L1SUB_CM_CON,
>> + PCIE_REFCLK_GATING_EN, 0);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static struct phy_ops exynos_phy_ops = {
>
> const ?
Yep.
>
>> + .init = exynos_pcie_phy_init,
>> + .power_on = exynos_pcie_phy_power_on,
>> +};
>> +
>> +static const struct exynos_pcie_phy_data exynos5433_pcie_phy_data = {
>> + .ctrl_type = PCIE_PHY_TYPE_EXYNOS5433,
>> + .pmureg_offset = PCIE_EXYNOS5433_PMU_PHY_OFFSET,
>> + .ops = &exynos_phy_ops,
>> +};
>> +
>> +static const struct of_device_id exynos_pcie_phy_match[] = {
>> + {
>> + .compatible = "samsung,exynos5433-pcie-phy",
>> + .data = &exynos5433_pcie_phy_data,
>> + },
>> + {}
>
> missing comma after braces.
Will fix.
>
>> +};
>> +MODULE_DEVICE_TABLE(of, exynos_pcie_phy_match);
>> +
>> +static int exynos_pcie_phy_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *np = dev->of_node;
>> + struct exynos_pcie_phy *exynos_phy;
>> + struct phy *generic_phy;
>> + struct phy_provider *phy_provider;
>> + struct resource *res;
>> + const struct exynos_pcie_phy_data *drv_data;
>> + const struct of_device_id *match;
>> +
>> + exynos_phy = devm_kzalloc(dev, sizeof(*exynos_phy), GFP_KERNEL);
>> + if (!exynos_phy)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + exynos_phy->phy_base = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(exynos_phy->phy_base))
>> + return PTR_ERR(exynos_phy->phy_base);
>> +
>> + exynos_phy->pmureg = syscon_regmap_lookup_by_phandle(np,
>> + "samsung,pmureg-phandle");
>> + if (IS_ERR(exynos_phy->pmureg)) {
>> + dev_warn(&pdev->dev, "pmureg syscon regmap lookup failed.\n");
>> + exynos_phy->pmureg = NULL;
>> + }
>
> Is this really optional ? There should be a failure path for IP versions that
> require this compulsorily.
Agreed. Will fix.
>
>> +
>> + match = of_match_node(exynos_pcie_phy_match, pdev->dev.of_node);
>> + drv_data = match->data;
>
> Please use of_device_get_match_data().
Ok.
>
>> + exynos_phy->drv_data = drv_data;
>> +
>> + exynos_phy->fsysreg = syscon_regmap_lookup_by_phandle(np,
>> + "samsung,fsys-sysreg");
>> + if (IS_ERR(exynos_phy->fsysreg)) {
>> + dev_warn(&pdev->dev, "Fsysreg syscon regmap lookup failed.\n");
>> + exynos_phy->fsysreg = NULL;
>> + }
>
> Same here, is this optional ?
Will fix.
Thanks for reviewing.
Best Regards,
Jaehoon Chung
>
>> +
>> + generic_phy = devm_phy_create(dev, dev->of_node, drv_data->ops);
>> + if (IS_ERR(generic_phy)) {
>> + dev_err(dev, "failed to create PHY\n");
>> + return PTR_ERR(generic_phy);
>> + }
>> +
>> + phy_set_drvdata(generic_phy, exynos_phy);
>> + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
>> +
>> + return PTR_ERR_OR_ZERO(phy_provider);
>> +}
>> +
>> +static struct platform_driver exynos_pcie_phy_driver = {
>> + .probe = exynos_pcie_phy_probe,
>> + .driver = {
>> + .of_match_table = exynos_pcie_phy_match,
>> + .name = "exynos_pcie_phy",
>> + }
>> +};
>> +module_platform_driver(exynos_pcie_phy_driver);
>> --
>> 2.10.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Thanks
> Vivek
>
^ permalink raw reply
* Re: [PATCH 1/2] spi: bcm-qspi: Enable the driver on BMIPS_GENERIC
From: Florian Fainelli @ 2016-12-28 1:15 UTC (permalink / raw)
To: Jaedon Shin, Ralf Baechle
Cc: Kevin Cernekee, Rob Herring, linux-mips, devicetree
In-Reply-To: <20161227015923.882-2-jaedon.shin@gmail.com>
On 12/26/2016 05:59 PM, Jaedon Shin wrote:
> The Broadcom BCM7XXX ARM and MIPS based SoCs share a similar hardware
> block for SPI.
>
> Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy
From: Stephen Boyd @ 2016-12-28 1:13 UTC (permalink / raw)
To: Vivek Gautam, Rob Herring
Cc: kishon, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Mark Rutland, Srinivas Kandagatla, linux-arm-msm
In-Reply-To: <CAFp+6iESYfFrLpidhAXrPm7LQtYa6dV1xOL=AjdMfLXgL8Fv8g@mail.gmail.com>
On 12/22/2016 08:52 PM, Vivek Gautam wrote:
>
>>> +
>>> +Optional properties:
>>> + - nvmem-cells: a list of phandles to nvmem cells that contain fused
>>> + tuning parameters for qusb2 phy, one for each entry
>>> + in nvmem-cell-names.
>>> + - nvmem-cell-names: must be "tune2_hstx_trim" for cell containing
>>> + HS Tx trim value.
>> ditto.
> nvmem doesn't allow, at this point, to get the cells by index.
> Its APIs take 'const char' cell id and get the cell.
>
> We should add this support to get the cell by index.
> Will create a patch for that, and drop the '-names' property from bindings.
>
If we introduce a cells based API just for this case of one phandle it
may make sense to allow the cell id to be NULL and default to whatever
cell is there without a names property. We do something similar with
clks where a NULL connection id defaults to the first phandle in the
list. Then we can avoid having a new set of DT specific APIs here. Of
course, documentation should be updated to indicate that a NULL cell_id
means use index 0 with DT.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [RESEND PATCH V3 4/4] gpio: pv88080: Add GPIO function support
From: Linus Walleij @ 2016-12-28 0:28 UTC (permalink / raw)
To: Eric Jeong
Cc: Alexandre Courbot, LINUX-GPIO, LINUX-KERNEL, DEVICETREE,
Lee Jones, Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource
In-Reply-To: <3e5d9f938494bf7420577ca2f55fd243705d9415.1481002393.git.eric.jeong@diasemi.com>
On Tue, Dec 6, 2016 at 6:33 AM, Eric Jeong
<eric.jeong.opensource@diasemi.com> wrote:
> From: Eric Jeong <eric.jeong.opensource@diasemi.com>
>
> This patch adds support for PV88080 PMIC GPIOs.
> PV88080 has two configurable GPIOs.
>
> Kconfig and Makefile are updated to reflect support
> for PV88080 PMIC GPIO.
>
> Signed-off-by: Eric Jeong <eric.jeong.opensource@diasemi.com>
> +#include <linux/gpio.h>
Use
#include <linux/gpio/driver.h>
only.
> +#include <linux/mfd/pv88080.h>
I see this header is not yet upstream so I can't merge
this driver (else I would just correct the above and merge it).
With the oneliner change:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
I guess Lee needs to merge this with the MFD bits.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 5/5] pinctrl: aspeed: Fix kerneldoc return descriptions
From: Linus Walleij @ 2016-12-28 0:23 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Lee Jones, Joel Stanley,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20161220073551.28522-6-andrew@aj.id.au>
On Tue, Dec 20, 2016 at 8:35 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Acked-by: Joel Stanley <joel@jms.id.au>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 4/5] pinctrl: aspeed-g5: Add mux configuration for all pins
From: Linus Walleij @ 2016-12-28 0:22 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Lee Jones, Joel Stanley,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161220073551.28522-5-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Tue, Dec 20, 2016 at 8:35 AM, Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org> wrote:
> The patch introducing the g5 pinctrl driver implemented a smattering of
> pins to flesh out the implementation of the core and provide bare-bones
> support for some OpenPOWER platforms and the AST2500 evaluation board.
> Now, update the bindings document to reflect the complete functionality
> and implement the necessary pin configuration tables in the driver.
>
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
> Acked-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Patch applied.
Yours,
Linus Walleij
--
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: [RFC PATCH 6/6] ARM64: exynos: add the pcie node for TM2
From: Jaehoon Chung @ 2016-12-27 23:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, javier, kishon, will.deacon,
catalin.marinas, cpgs
In-Reply-To: <20161227163200.6noed454fmtgozrv@kozik-lap>
On 12/28/2016 01:32 AM, Krzysztof Kozlowski wrote:
> On Mon, Dec 26, 2016 at 02:20:29PM +0900, Jaehoon Chung wrote:
>> Add the Exxynos5433 pcie node for TM2.
>> This pcie device is used for supporting WiFi.
>>
>> And some gpios are already requested from pinctrl. so it doesn't need to
>> initialize.
>> GPJ2-0 is used for supplying to WiFi PCIe chip.
>>
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 7 +++++++
>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 11 +++++++++--
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 23 ++++++++++++++++++++++
>> 3 files changed, 39 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
>> index ad71247..3e8b728 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
>> @@ -183,6 +183,13 @@
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> };
>> +
>> + pcie_wlanen: pcie-wlanen {
>> + samsung,pins = "gpj2-0";
>> + samsung,pin-function = <0>;
>> + samsung,pin-pud = <3>;
>> + samsung,pin-drv = <3>;
>> + };
>> };
>>
>> &pinctrl_finger {
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index f21bdc2..c84a2ad 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -737,6 +737,15 @@
>> bus-width = <4>;
>> };
>>
>> +&pcie {
>> + assigned-clocks = <&cmu_fsys CLK_MOUT_SCLK_PCIE_100_USER>,
>> + <&cmu_top CLK_MOUT_SCLK_PCIE_100>;
>> + assigned-clock-parents = <&cmu_top CLK_SCLK_PCIE_100_FSYS>,
>> + <&cmu_top CLK_MOUT_BUS_PLL_USER>;
>> + assigned-clock-rates = <0>, <100000000>;
>> + status = "okay";
>> +};
>> +
>> &pinctrl_alive {
>> pinctrl-names = "default";
>> pinctrl-0 = <&initial_alive>;
>> @@ -836,7 +845,6 @@
>> pinctrl-0 = <&initial_ese>;
>>
>> initial_ese: initial-state {
>> - PIN(IN, gpj2-0, DOWN, LV1);
>> PIN(IN, gpj2-1, DOWN, LV1);
>> PIN(IN, gpj2-2, DOWN, LV1);
>> };
>> @@ -851,7 +859,6 @@
>> PIN(IN, gpr3-1, DOWN, LV1);
>> PIN(IN, gpr3-2, DOWN, LV1);
>> PIN(IN, gpr3-3, DOWN, LV1);
>> - PIN(IN, gpr3-7, NONE, LV1);
>> };
>> };
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index 2a15f18..da287f4 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -1457,6 +1457,29 @@
>> samsung,fsys-sysreg = <&syscon_fsys>;
>> status = "okay";
>> };
>> +
>> + pcie: pcie@15700000 {
>> + compatible = "samsung,exynos5433-pcie", "snps,dw-pcie";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + device_type = "pci";
>> + interrupts = <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "intr";
>> + clocks = <&cmu_fsys CLK_PCIE>,
>> + <&cmu_fsys CLK_PCLK_PCIE_PHY>;
>
> Here and in the 'reg' property - indentation looks weird. Tabs+spaces
> but not aligned. Either you use spaces to align... or just don't care
> and use tabs. I prefer consistency and below the 'ranges' property is
> aligned.
Will fix.
>
>> + clock-names = "pcie", "pcie_bus";
>> + num-lanes = <1>;
>> + pinctrl-names = "default";
>> + phys = <&pcie_phy>;
>> + phy-names = "pcie-phy";
>> + pinctrl-0 = <&pcie_bus &pcie_wlanen>;
>> + reg = <0x156b0000 0x1000>, <0x15700000 0x1000>,
>> + <0x0c000000 0x1000>;
>> + reg-names = "elbi", "dbi", "config";
>
> This does not match the bindings documentation.
This is right. Bindings documentation is wrong. :)
And I will put the prefix as "dts" on subject, according to your other comment.
Best Regards,
Jaehoon Chung
>
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* Re: [RFC PATCH 5/6] Documentation: pci: add the exynos5433-pcie binding
From: Jaehoon Chung @ 2016-12-27 23:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, javier, kishon, will.deacon,
catalin.marinas, cpgs
In-Reply-To: <20161227161916.nb6yf3n2kmkzkeg2@kozik-lap>
On 12/28/2016 01:19 AM, Krzysztof Kozlowski wrote:
> On Mon, Dec 26, 2016 at 02:20:28PM +0900, Jaehoon Chung wrote:
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> ---
>> .../devicetree/bindings/pci/exynos5433-pcie.txt | 36 ++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/exynos5433-pcie.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pci/exynos5433-pcie.txt b/Documentation/devicetree/bindings/pci/exynos5433-pcie.txt
>> new file mode 100644
>> index 0000000..932a847
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/exynos5433-pcie.txt
>> @@ -0,0 +1,36 @@
>> +* Samsung Exynos5433 PCIe interface
>> +
>> +This PCIe host controller is based on the Synopsis Designware PCIe IP
>
> Synopsys.
Will fix.
>
>> +and thus inherits all the common properties defined in designware-pcie.txt.
>> +
>> +Required properties:
>> +- compatible: "samsung,exynos5433-pcie"
>> +- reg: base addresses and lengths of the pcie controller,
>> + the phy controller, additional register for the phy controller.
>
> You mentioned three regs but the example contains four of them. Is the
> config comming from snps,dw-pcie?
Oops..It's my mistake. Just needs to put three reg.
Elbi : External local Bus interface register.
Dbi : Data bus interface register.(Control register.)
Config : for configuration space.
"config" can be removed. Because it's not Exynos specific, synopsys's Required property.
>
>> +- reg-names: Must be "elbi", "phy" and "dbi" for each regs
>
> Again, three here, four in example.
Will fix.
>
>> +- interrupt-names: Must be "intr" for legacy interrupt pin.
>> +
>> +Other common properites refer to
>> + Documentation/devicetree/binding/pci/designware-pcie.txt
>> +
>> +Example:
>> +
>> + pcie: pcie@15700000 {
>> + compatible ="samsung,exynos5433-pcie", "snps,dw-pcie";
> ^
> space needed
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + device_type = "pci";
>> + interrupts = <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "intr";
>> + clocks = <&cmu_fsys CLK_PCIE>, <&cmu_fsys CLK_PCLK_PCIE_PHY>;
>> + clock-names = "pcie", "pcie_bus";
>> + num-lanes = <1>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pcie_bus>;
>> + reg = <0x156b0000 0x1000>, <0x15680000 0x1000>,
>> + <0x15700000 0x1000>, <0x0c000000 0x1000>;
>
> Indentation here looks wrong. You indented it with spaces after tabs...
> but not to align with line before.
Will fix.
Best Regards,
Jaehoon Chung
>
> Beside that, fine with me:
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> Best regards,
> Krzysztof
>
>
>> + reg-names = "elbi", "phy", "dbi", "config";
>> + ranges = <0x81000000 0 0 0x0c001000 0 0x00010000
>> + 0x82000000 0 0x0c011000 0x0c011000 0 0x3feefff>;
>> + status = "disabled";
>> + };
>> --
>> 2.10.2
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* Re: [RFC PATCH 3/6] ARM64: dts: exynos5433: add the pcie_phy node for PCIe
From: Jaehoon Chung @ 2016-12-27 22:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, javier, kishon, will.deacon,
catalin.marinas, cpgs
In-Reply-To: <20161227161134.ds67t5byucphwkjg@kozik-lap>
On 12/28/2016 01:11 AM, Krzysztof Kozlowski wrote:
> On Mon, Dec 26, 2016 at 02:20:26PM +0900, Jaehoon Chung wrote:
>> To use the generic PHY framework, adds the pcie_phy node.
>>
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index 64226d5..2a15f18 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -805,6 +805,11 @@
>> reg = <0x145f0000 0x1038>;
>> };
>>
>> + syscon_fsys: syscon@156f0000 {
>> + compatible = "syscon";
>> + reg = <0x156f0000 0x1044>;
>> + };
>> +
>> gsc_0: video-scaler@13C00000 {
>> compatible = "samsung,exynos5433-gsc";
>> reg = <0x13c00000 0x1000>;
>> @@ -1443,6 +1448,15 @@
>> status = "disabled";
>> };
>> };
>> +
>> + pcie_phy: pcie-phy@15680000 {
>> + #phy-cells = <0>;
>> + compatible = "samsung,exynos5433-pcie-phy";
>
> Mostly we use the convention of compatible being first property.
>
>> + reg = <0x15680000 0x1000>;
>> + samsung,pmureg-phandle = <&pmu_system_controller>;
>> + samsung,fsys-sysreg = <&syscon_fsys>;
>> + status = "okay";
>
> Why do you need to put status=okay here?
Not need. Will remove.
Best Regards,
Jaehoon Chung
>
> Best regards,
> Krzysztof
>
>> + };
>> };
>>
>> timer: timer {
>> --
>> 2.10.2
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* Re: [PATCH v4 3/5] pinctrl: aspeed-g4: Add mux configuration for all pins
From: Linus Walleij @ 2016-12-27 22:18 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Lee Jones, Joel Stanley,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Timothy Pearson
In-Reply-To: <20161220073551.28522-4-andrew@aj.id.au>
On Tue, Dec 20, 2016 at 8:35 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> The patch introducing the g4 pinctrl driver implemented a smattering of
> pins to flesh out the implementation of the core and provide bare-bones
> support for some OpenPOWER platforms. Now, update the bindings document
> to reflect the complete functionality and implement the necessary pin
> configuration tables in the driver.
>
> Cc: Timothy Pearson <tpearson@raptorengineering.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Acked-by: Joel Stanley <joel@jms.id.au>
> Acked-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 2/5] pinctrl: aspeed: Read and write bits in LPC and GFX controllers
From: Linus Walleij @ 2016-12-27 22:16 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Lee Jones, Joel Stanley,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20161220073551.28522-3-andrew@aj.id.au>
On Tue, Dec 20, 2016 at 8:35 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> The System Control Unit IP block in the Aspeed SoCs is typically where
> the pinmux configuration is found, but not always. A number of pins
> depend on state in one of LPC Host Control (LHC) or SoC Display
> Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> means to adjust these as necessary.
>
> We use syscon to cast a regmap over the GFX and LPC blocks, which is
> used as an arbitration layer between the relevant driver and the pinctrl
> subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> drivers by phandles in the devicetree, and are selected during a mux
> request by querying a new 'ip' member in struct aspeed_sig_desc.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
Patch applied, adding Rob's ack in the process.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 1/5] pinctrl: aspeed: dt: Fix compatibles for the System Control Unit
From: Linus Walleij @ 2016-12-27 22:14 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Mark Rutland, Lee Jones, Joel Stanley,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161220073551.28522-2-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Tue, Dec 20, 2016 at 8:35 AM, Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org> wrote:
> Reference the SoC-specific compatible string in the examples as
> required.
>
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
Patch applied with the ACKs.
Yours,
Linus Walleij
--
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/2] MIPS: BMIPS: Add support SPI device nodes
From: Florian Fainelli @ 2016-12-27 22:12 UTC (permalink / raw)
To: Jaedon Shin, Ralf Baechle
Cc: Kevin Cernekee, Rob Herring, linux-mips, devicetree
In-Reply-To: <20161227015923.882-3-jaedon.shin@gmail.com>
On 12/26/2016 05:59 PM, Jaedon Shin wrote:
> Adds SPI device nodes to BCM7xxx MIPS based SoCs.
>
> Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
> ---
> arch/mips/boot/dts/brcm/bcm7125.dtsi | 55 +++++++++++++++++++++++++++++--
> arch/mips/boot/dts/brcm/bcm7346.dtsi | 49 +++++++++++++++++++++++++++
> arch/mips/boot/dts/brcm/bcm7358.dtsi | 49 +++++++++++++++++++++++++++
> arch/mips/boot/dts/brcm/bcm7360.dtsi | 49 +++++++++++++++++++++++++++
> arch/mips/boot/dts/brcm/bcm7362.dtsi | 49 +++++++++++++++++++++++++++
> arch/mips/boot/dts/brcm/bcm7420.dtsi | 55 +++++++++++++++++++++++++++++--
> arch/mips/boot/dts/brcm/bcm7425.dtsi | 49 +++++++++++++++++++++++++++
> arch/mips/boot/dts/brcm/bcm7435.dtsi | 49 +++++++++++++++++++++++++++
> arch/mips/boot/dts/brcm/bcm97125cbmb.dts | 4 +++
> arch/mips/boot/dts/brcm/bcm97346dbsmb.dts | 4 +++
> arch/mips/boot/dts/brcm/bcm97358svmb.dts | 36 ++++++++++++++++++++
> arch/mips/boot/dts/brcm/bcm97360svmb.dts | 36 ++++++++++++++++++++
> arch/mips/boot/dts/brcm/bcm97362svmb.dts | 4 +++
> arch/mips/boot/dts/brcm/bcm97420c.dts | 4 +++
> arch/mips/boot/dts/brcm/bcm97425svmb.dts | 36 ++++++++++++++++++++
> arch/mips/boot/dts/brcm/bcm97435svmb.dts | 4 +++
> 16 files changed, 526 insertions(+), 6 deletions(-)
>
> diff --git a/arch/mips/boot/dts/brcm/bcm7125.dtsi b/arch/mips/boot/dts/brcm/bcm7125.dtsi
> index bbd00f65ce39..c1e19e57f64a 100644
> --- a/arch/mips/boot/dts/brcm/bcm7125.dtsi
> +++ b/arch/mips/boot/dts/brcm/bcm7125.dtsi
> @@ -46,6 +46,12 @@
> #clock-cells = <0>;
> clock-frequency = <27000000>;
> };
> +
> + spi_clk: spi_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <27000000>;
> + };
Nit, this should actually be upg_clk, since this is the clock that the
SPI controller uses, and it is a fixed-clock with a 27Mhz frequency.
Other than that, the rest looks good to me, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH v8 3/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature
From: Dmitry Torokhov @ 2016-12-27 21:54 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Jonathan Cameron, Jonathan Cameron, Sebastian Reichel,
Mark Rutland, Benoît Cousson, Tony Lindgren, Russell King,
Arnd Bergmann, Michael Welling, Mika Penttilä,
Javier Martinez Canillas, Igor Grinberg, Andrew F. Davis,
Mark Brown, Rob Herring, Alexander Stein, Eric Engestrom,
Hans de Goede
In-Reply-To: <E4E31180-A686-4631-9713-519987C55F06-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
On Mon, Dec 12, 2016 at 10:21:25PM +0100, H. Nikolaus Schaller wrote:
> Hi,
>
>
> > Am 27.11.2016 um 16:47 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
> >
> > Hi Jonathan,
> >
> >> Am 27.11.2016 um 12:02 schrieb Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
> >>
> >> On 24/11/16 18:05, H. Nikolaus Schaller wrote:
> >>>
> >>>> Am 24.11.2016 um 18:38 schrieb Jonathan Cameron <jic23-tko9wxEg+fIOOJlXag/Snyp2UmYkHbXO@public.gmane.org>:
> >>>>
> >>>>
> >>>>
> >>>> On 22 November 2016 14:02:30 GMT+00:00, "H. Nikolaus Schaller" <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:
>
> >
> >> - hence cc'd Yann and the Kbuild list
> >> to see if they can offer some advices.
>
> no response / advice so far.
Since you are saying that IIO stuff is optional, add it to Kconfig
explicitly:
config "TOUCHSCREEN_TSC2007_IIO"
bool "IIO interface for external ADC input and temperature"
depends on TOUCHSCREEN_TSC2007
depends on IIO=y || IIO=TOUCHSCREEN_TSC2007
help
...
and use this symbols in makefile:
and in Makefile:
obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o
tsc2007-y := tsc2007-core.o ...
tsc2007-$(CONFIG_TOUCHSCREEN_TSC2007_IIO) += tsc2007_iio.o
Thanks.
--
Dmitry
--
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/4] ARM: dts: Add am335x-boneblack-wireless
From: Robert Nelson @ 2016-12-27 19:21 UTC (permalink / raw)
To: Tony Lindgren
Cc: devicetree, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jason Kridner
In-Reply-To: <20161227185645.GZ4920@atomide.com>
On Tue, Dec 27, 2016 at 12:56 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Tony Lindgren <tony@atomide.com> [161227 10:15]:
>> * Robert Nelson <robertcnelson@gmail.com> [161227 10:02]:
>> > On Tue, Dec 27, 2016 at 11:58 AM, Robert Nelson <robertcnelson@gmail.com> wrote:
>> > > BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
>> > > replaced by a TI wl1835 wireless module.
>> > >
>> > > This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
>> > > BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
>> > >
>> > > http://beagleboard.org/black-wireless
>> > > https://github.com/beagleboard/beaglebone-black-wireless
>> > >
>> > > firmware: https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
>> >
>> > Tony, this firmware should be there shortly, i have a pull request
>> > setup for Jason:
>> >
>> > https://github.com/beagleboard/beaglebone-black-wireless/pull/5
>>
>> OK great, good to have these working out of the box with mainline
>> kernel :)
>
> Hmm so is this firmware file also something that should really be generated
> separately for each board? Or can the same one be used for all BBB black
> wireless and green boards?
>
> See the LKML thread "[PATCH 0/6] wl1251: Fix MAC address for Nokia N900",
> at least with wl1251 the calibration has been done for each n900 device
> during production.
>From what i can tell from TI, it should be good for all wl1835 modules
that use two wifi antenna's.
(that's the magic in: WL1835MOD_INI_C2PC.ini)
We are using the same wl18xx-conf.bin firmware for:
Original CircuitCo (now out of production) wl1835mod cape for BeagleBone Black
updated GateWay Cape from embest (this was meant to replace the wl1835mod cape)
SeeedStudio BeagleBone Green Wireless
BeagleBone Black Wireless
and the upcoming: (jason just sent me the next alpha, so i'll have a
patch after i verify all changes..)
BeagleBone Blue
For FCC testing, this was the same firmware (wl18xx-conf.bin) that
SeeedStudio used when they did the official FCC testing on the Green
Wireless. I believe GHI Electronics did the same with the BeagleBone
Black Wireless, but i wasn't CC'ed in that email conversation, so i
can't say with 100% certainty..
Regards,
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply
* Re: [PATCH v8 3/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature
From: H. Nikolaus Schaller @ 2016-12-27 19:08 UTC (permalink / raw)
To: Jonathan Cameron, Dmitry Torokhov
Cc: Jonathan Cameron, Mark Rutland, Benoît Cousson,
Tony Lindgren, Russell King, Arnd Bergmann, Michael Welling,
Mika Penttilä, Javier Martinez Canillas, Igor Grinberg,
Andrew F. Davis, Mark Brown, Rob Herring, Alexander Stein,
Eric Engestrom, Hans de Goede, Benjamin Tissoires, Denis Carikli
In-Reply-To: <E4E31180-A686-4631-9713-519987C55F06-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
ping.
> Am 12.12.2016 um 22:21 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
>
> Hi,
>
>
>> Am 27.11.2016 um 16:47 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
>>
>> Hi Jonathan,
>>
>>> Am 27.11.2016 um 12:02 schrieb Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>>>
>>> On 24/11/16 18:05, H. Nikolaus Schaller wrote:
>>>>
>>>>> Am 24.11.2016 um 18:38 schrieb Jonathan Cameron <jic23-tko9wxEg+fIOOJlXag/Snyp2UmYkHbXO@public.gmane.org>:
>>>>>
>>>>>
>>>>>
>>>>> On 22 November 2016 14:02:30 GMT+00:00, "H. Nikolaus Schaller" <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:
>
>>
>>> - hence cc'd Yann and the Kbuild list
>>> to see if they can offer some advices.
>
> no response / advice so far.
>
>>
>> Thanks!
>>
>> BTW, the other tsc2007 and ads7846 patches could already be merged (if there
>> are no more changes needed) since this one only depends on the result of applying
>> all others before.
>
> I wonder if input maintainers can already merge the other patches of this patch series?
series: https://lkml.org/lkml/2016/11/22/309
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: Add am335x-boneblack-wireless
From: Tony Lindgren @ 2016-12-27 18:56 UTC (permalink / raw)
To: Robert Nelson
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jason Kridner
In-Reply-To: <20161227181429.GY4920-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161227 10:15]:
> * Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [161227 10:02]:
> > On Tue, Dec 27, 2016 at 11:58 AM, Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
> > > replaced by a TI wl1835 wireless module.
> > >
> > > This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
> > > BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
> > >
> > > http://beagleboard.org/black-wireless
> > > https://github.com/beagleboard/beaglebone-black-wireless
> > >
> > > firmware: https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
> >
> > Tony, this firmware should be there shortly, i have a pull request
> > setup for Jason:
> >
> > https://github.com/beagleboard/beaglebone-black-wireless/pull/5
>
> OK great, good to have these working out of the box with mainline
> kernel :)
Hmm so is this firmware file also something that should really be generated
separately for each board? Or can the same one be used for all BBB black
wireless and green boards?
See the LKML thread "[PATCH 0/6] wl1251: Fix MAC address for Nokia N900",
at least with wl1251 the calibration has been done for each n900 device
during production.
Regards,
Tony
--
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 V2 2/2] backlight arcxcnn devicetree bindings for ArcticSand
From: Jingoo Han @ 2016-12-27 18:39 UTC (permalink / raw)
To: 'Olimpiu Dejeu', robh
Cc: lee.jones, linux-kernel, linux-fbdev, devicetree, bdodge
In-Reply-To: <1481298573-15463-1-git-send-email-olimpiu@arcticsand.com>
On Friday, December 9, 2016 10:50 AM, Olimpiu Dejeu wrote:
>
Please add the commit message here.
Best regards,
Jingoo Han
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Olimpiu Dejeu <olimpiu@arcticsand.com>
> ---
>
> v1 => v2:
> - Version updated to match other patch in set. No other changes.
>
> .../bindings/leds/backlight/arcxcnn_bl.txt | 31
> ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
>
> diff --git
> a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> new file mode 100644
> index 0000000..a7b6ff2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> @@ -0,0 +1,33 @@
> +Binding for ArcticSand arc2c0608 LED driver
> +
> +Required properties:
> +- compatible: should be "arc,arc2c0608"
> +- reg: slave address
> +
> +Optional properties:
> +- default-brightness: brightness value on boot, value from: 0-4095
> +- label: The name of the backlight device
> + See
Documentation/devicetree/bindings/leds/common.txt
> +- led-sources: List of enabled channels from 0 to 5.
> + See
Documentation/devicetree/bindings/leds/common.txt
> +
> +- arc,led-config-0: setting for register ILED_CONFIG_0
> +- arc,led-config-1: setting for register ILED_CONFIG_1
> +- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
> +- arc,comp-config: setting for register CONFIG_COMP
> +- arc,filter-config: setting for register FILTER_CONFIG
> +- arc,trim-config: setting for register IMAXTUNE
> +
> +Note: Optional properties not specified will default to values in IC
> EPROM
> +
> +Example:
> +
> +arc2c0608@30 {
> + compatible = "arc,arc2c0608";
> + reg = <0x30>;
> + default-brightness = <500>;
> + label = "lcd-backlight";
> + linux,default-trigger = "backlight";
> + led-sources = <0 1 2 5>;
> +};
> +
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v2 1/2] backlight arcxcnn add support for ArcticSand devices
From: Jingoo Han @ 2016-12-27 18:37 UTC (permalink / raw)
To: 'Olimpiu Dejeu', robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, bdodge-eV7fy4qpoLhpLGFMi4vTTA
In-Reply-To: <1481298549-15400-1-git-send-email-olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
On Friday, December 9, 2016 10:49 AM, Olimpiu Dejeu wrote:
>
Please add the commit message here.
Refer to commit logs of other backlight drivers.
> Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> ---
>
> v1 => v2:
> - Removed "magic numbers" to initialize registers
> - Cleaned up device tree bindings
> - Fixed code style to address comments and pass "checkpatch"
> - Removed unneeded debug and testing code
>
> drivers/video/backlight/Kconfig | 7 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/arcxcnn_bl.c | 458
> +++++++++++++++++++++++++++++++++++
> include/linux/i2c/arcxcnn.h | 51 ++++
> 4 files changed, 517 insertions(+)
> create mode 100644 drivers/video/backlight/arcxcnn_bl.c
> create mode 100644 include/linux/i2c/arcxcnn.h
>
> diff --git a/drivers/video/backlight/Kconfig
> b/drivers/video/backlight/Kconfig
> index 5ffa4b4..4e1d2ad 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -460,6 +460,13 @@ config BACKLIGHT_BD6107
> help
> If you have a Rohm BD6107 say Y to enable the backlight driver.
>
> +config BACKLIGHT_ARCXCNN
> + tristate "Backlight driver for the Arctic Sands ARCxCnnnn family"
> + depends on I2C
> + help
> + If you have an ARCxCnnnn family backlight say Y to enable
> + the backlight driver.
> +
> endif # BACKLIGHT_CLASS_DEVICE
>
> endif # BACKLIGHT_LCD_SUPPORT
> diff --git a/drivers/video/backlight/Makefile
> b/drivers/video/backlight/Makefile
> index 16ec534..8905129 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -55,3 +55,4 @@ obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-
> backlight.o
> obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
> obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
> obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
> +obj-$(CONFIG_BACKLIGHT_ARCXCNN) += arcxcnn_bl.o
> diff --git a/drivers/video/backlight/arcxcnn_bl.c
> b/drivers/video/backlight/arcxcnn_bl.c
> new file mode 100644
> index 0000000..fcebbd6
> --- /dev/null
> +++ b/drivers/video/backlight/arcxcnn_bl.c
> @@ -0,0 +1,458 @@
> +/*
> + * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
> + *
> + * Copyright 2016 ArcticSand, Inc.
> + * Author : Brian Dodge <bdodge-eV7fy4qpoLhpLGFMi4vTTA@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 version 2
> + * as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> along
> + * with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +
> +#include "linux/i2c/arcxcnn.h"
> +
> +#define ARCXCNN_CMD 0x00 /* Command Register */
> +#define ARCXCNN_CMD_STDBY 0x80 /* I2C Standby */
> +#define ARCXCNN_CMD_RESET 0x40 /* Reset */
> +#define ARCXCNN_CMD_BOOST 0x10 /* Boost */
> +#define ARCXCNN_CMD_OVP_MASK 0x0C /* --- Over Voltage Threshold */
> +#define ARCXCNN_CMD_OVP_XXV 0x0C /* <rsvrd> Over Voltage
> Threshold */
> +#define ARCXCNN_CMD_OVP_20V 0x08 /* 20v Over Voltage Threshold */
> +#define ARCXCNN_CMD_OVP_24V 0x04 /* 24v Over Voltage Threshold */
> +#define ARCXCNN_CMD_OVP_31V 0x00 /* 31.4v Over Voltage Threshold
> */
> +#define ARCXCNN_CMD_EXT_COMP 0x01 /* part (0) or full (1) ext.
> comp */
> +
> +#define ARCXCNN_CONFIG 0x01 /* Configuration */
> +#define ARCXCNN_STATUS1 0x02 /* Status 1 */
> +#define ARCXCNN_STATUS2 0x03 /* Status 2 */
> +#define ARCXCNN_FADECTRL 0x04 /* Fading Control */
> +#define ARCXCNN_ILED_CONFIG 0x05 /* ILED Configuration */
> +#define ARCXCNN_ILED_DIM_PWM 0x00 /* config dim mode pwm */
> +#define ARCXCNN_ILED_DIM_INT 0x04 /* config dim mode internal */
> +#define ARCXCNN_LEDEN 0x06 /* LED Enable Register */
> +#define ARCXCNN_LEDEN_ISETEXT 0x80 /* Full-scale current set
extern
> */
> +#define ARCXCNN_LEDEN_MASK 0x3F /* LED string enables mask */
> +#define ARCXCNN_LEDEN_BITS 0x06 /* Bits of LED string enables */
> +#define ARCXCNN_LEDEN_LED1 0x01
> +#define ARCXCNN_LEDEN_LED2 0x02
> +#define ARCXCNN_LEDEN_LED3 0x04
> +#define ARCXCNN_LEDEN_LED4 0x08
> +#define ARCXCNN_LEDEN_LED5 0x10
> +#define ARCXCNN_LEDEN_LED6 0x20
> +
> +#define ARCXCNN_WLED_ISET_LSB 0x07 /* LED ISET LSB (in upper
nibble)
> */
> +#define ARCXCNN_WLED_ISET_LSB_SHIFT 0x04 /* ISET LSB Left Shift */
> +#define ARCXCNN_WLED_ISET_MSB 0x08 /* LED ISET MSB (8 bits) */
> +
> +#define ARCXCNN_DIMFREQ 0x09
> +#define ARCXCNN_COMP_CONFIG 0x0A
> +#define ARCXCNN_FILT_CONFIG 0x0B
> +#define ARCXCNN_IMAXTUNE 0x0C
> +#define ARCXCNN_ID_MSB 0x1E
> +#define ARCXCNN_ID_LSB 0x1F
> +
> +#define MAX_BRIGHTNESS 4095
> +
> +static int s_no_reset_on_remove;
Please just use 'no_reset_on_remove' without prefix 's_'.
> +module_param_named(noreset, s_no_reset_on_remove, int, 0644);
> +MODULE_PARM_DESC(noreset, "No reset on module removal");
> +
> +static int s_ibright = 60;
Same above.
> +module_param_named(ibright, s_ibright, int, 0644);
> +MODULE_PARM_DESC(ibright, "Initial brightness (when no plat data)");
> +
> +static int s_ileden = ARCXCNN_LEDEN_MASK;
Same above.
> +module_param_named(ileden, s_ileden, int, 0644);
> +MODULE_PARM_DESC(ileden, "Initial LED String Enables (when no plat
> data)");
> +
> +struct arcxcnn {
> + char chipname[64];
> + struct i2c_client *client;
> + struct backlight_device *bl;
> + struct device *dev;
> + struct arcxcnn_platform_data *pdata;
> +};
> +
> +static int arcxcnn_update_bit(struct arcxcnn *lp, u8 reg, u8 mask, u8
> data)
> +{
> + int ret;
> + u8 tmp;
> +
> + ret = i2c_smbus_read_byte_data(lp->client, reg);
> + if (ret < 0) {
> + dev_err(lp->dev, "failed to read 0x%.2x\n", reg);
> + return ret;
> + }
> +
> + tmp = (u8)ret;
> + tmp &= ~mask;
> + tmp |= data & mask;
> +
> + return i2c_smbus_write_byte_data(lp->client, reg, tmp);
> +}
> +
> +static int arcxcnn_set_brightness(struct arcxcnn *lp, u32 brightness)
> +{
> + int ret;
> + u8 val;
> +
> + /* lower nibble of brightness goes in upper nibble of LSB register
> */
> + val = (brightness & 0xF) << ARCXCNN_WLED_ISET_LSB_SHIFT;
> + ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_WLED_ISET_LSB,
> val);
> + if (ret < 0)
> + return ret;
> +
> + /* remaining 8 bits of brightness go in MSB register */
> + val = (brightness >> 4);
> + ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_WLED_ISET_MSB,
> val);
> +
> + return ret;
> +}
> +
> +static int arcxcnn_bl_update_status(struct backlight_device *bl)
> +{
> + struct arcxcnn *lp = bl_get_data(bl);
> + u32 brightness = bl->props.brightness;
> +
> + if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> + brightness = 0;
> +
> + arcxcnn_set_brightness(lp, brightness);
> +
> + /* set power-on/off/save modes */
> + if (bl->props.power == 0)
> + /* take out of standby */
> + arcxcnn_update_bit(lp, ARCXCNN_CMD, ARCXCNN_CMD_STDBY, 0);
> + else
> + /* place in low-power standby mode */
> + arcxcnn_update_bit(lp, ARCXCNN_CMD,
> + ARCXCNN_CMD_STDBY, ARCXCNN_CMD_STDBY);
> + return 0;
> +}
> +
> +static const struct backlight_ops arcxcnn_bl_ops = {
> + .options = BL_CORE_SUSPENDRESUME,
> + .update_status = arcxcnn_bl_update_status,
> +};
> +
> +static int arcxcnn_backlight_register(struct arcxcnn *lp)
> +{
> + struct backlight_properties *props;
> + const char *name = lp->pdata->name ? : "arctic_bl";
> +
> + props = devm_kzalloc(lp->dev, sizeof(*props), GFP_KERNEL);
> + if (!props)
> + return -ENOMEM;
> +
> + memset(props, 0, sizeof(props));
> + props->type = BACKLIGHT_PLATFORM;
> + props->max_brightness = MAX_BRIGHTNESS;
> +
> + if (lp->pdata->initial_brightness > props->max_brightness)
> + lp->pdata->initial_brightness = props->max_brightness;
> +
> + props->brightness = lp->pdata->initial_brightness;
> +
> + lp->bl = devm_backlight_device_register(lp->dev, name, lp->dev, lp,
> + &arcxcnn_bl_ops, props);
> +
> + if (IS_ERR(lp->bl))
> + return PTR_ERR(lp->bl);
> +
> + return 0;
> +}
> +
> +static ssize_t arcxcnn_chip_id_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct arcxcnn *lp = dev_get_drvdata(dev);
> +
> + return scnprintf(buf, PAGE_SIZE, "%s\n", lp->chipname);
> +}
> +
> +static ssize_t arcxcnn_leden_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct arcxcnn *lp = dev_get_drvdata(dev);
> +
> + return scnprintf(buf, PAGE_SIZE, "%02X\n", lp->pdata->leden);
> +}
> +
> +static ssize_t arcxcnn_leden_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t len)
> +{
> + struct arcxcnn *lp = dev_get_drvdata(dev);
> + unsigned long leden;
> +
> + if (kstrtoul(buf, 0, &leden))
> + return 0;
> +
> + if (leden != lp->pdata->leden) {
> + /* don't allow 0 for leden, use power to turn all off */
> + if (leden == 0)
> + return -EINVAL;
> + lp->pdata->leden = leden & ARCXCNN_LEDEN_MASK;
> + arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
> + ARCXCNN_LEDEN_MASK, lp->pdata->leden);
> + }
> +
> + return len;
> +}
> +
> +static DEVICE_ATTR(chip_id, 0444, arcxcnn_chip_id_show, NULL);
> +static DEVICE_ATTR(leden, 0664, arcxcnn_leden_show, arcxcnn_leden_store);
> +
> +static struct attribute *arcxcnn_attributes[] = {
> + &dev_attr_chip_id.attr,
> + &dev_attr_leden.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group arcxcnn_attr_group = {
> + .attrs = arcxcnn_attributes,
> +};
> +
> +static void arcxcnn_parse_dt(struct arcxcnn *lp)
> +{
> + struct device *dev = lp->dev;
> + struct device_node *node = dev->of_node;
> + u32 prog_val, num_entry, entry, sources[ARCXCNN_LEDEN_BITS];
> + int ret;
> +
> + /* device tree entry isn't required, defaults are OK */
> + if (!node)
> + return;
> +
> + ret = of_property_read_string(node, "label", &lp->pdata->name);
> + if (ret < 0)
> + lp->pdata->name = NULL;
> +
> + ret = of_property_read_u32(node, "default-brightness", &prog_val);
> + if (ret == 0)
> + lp->pdata->initial_brightness = prog_val;
> +
> + ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
> + if (ret == 0)
> + lp->pdata->led_config_0 = (u8)prog_val;
> +
> + ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
> + if (ret == 0)
> + lp->pdata->led_config_1 = (u8)prog_val;
> +
> + ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
> + if (ret == 0)
> + lp->pdata->dim_freq = (u8)prog_val;
> +
> + ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
> + if (ret == 0)
> + lp->pdata->comp_config = (u8)prog_val;
> +
> + ret = of_property_read_u32(node, "arc,filter-config", &prog_val);
> + if (ret == 0)
> + lp->pdata->filter_config = (u8)prog_val;
> +
> + ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
> + if (ret == 0)
> + lp->pdata->trim_config = (u8)prog_val;
> +
> + ret = of_property_count_u32_elems(node, "led-sources");
> + if (ret < 0) {
> + lp->pdata->leden = ARCXCNN_LEDEN_MASK; /* all on is default
> */
> + } else {
> + num_entry = ret;
> + if (num_entry > ARCXCNN_LEDEN_BITS)
> + num_entry = ARCXCNN_LEDEN_BITS;
> +
> + ret = of_property_read_u32_array(node, "led-sources",
> sources,
> + num_entry);
> + if (ret < 0) {
> + dev_err(dev, "led-sources node is invalid.\n");
> + } else {
> + u8 onbit;
> +
> + lp->pdata->leden = 0;
> +
> + /* for each enable in source, set bit in led enable
> */
> + for (entry = 0; entry < num_entry; entry++) {
> + onbit = 1 << sources[entry];
> + lp->pdata->leden |= onbit;
> + }
> + }
> + }
> +}
> +
> +static int arcxcnn_probe(struct i2c_client *cl, const struct
> i2c_device_id *id)
> +{
> + struct arcxcnn *lp;
> + int ret;
> + u8 regval;
> + u16 chipid;
> +
> + if (!i2c_check_functionality(cl->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
> + return -EIO;
> +
> + lp = devm_kzalloc(&cl->dev, sizeof(*lp), GFP_KERNEL);
> + if (!lp)
> + return -ENOMEM;
> +
> + lp->client = cl;
> + lp->dev = &cl->dev;
> + lp->pdata = dev_get_platdata(&cl->dev);
> +
> + /* reset the device */
> + i2c_smbus_write_byte_data(lp->client,
> + ARCXCNN_CMD, ARCXCNN_CMD_RESET);
> +
> + /* read device ID */
> + regval = i2c_smbus_read_byte_data(lp->client, ARCXCNN_ID_MSB);
> + chipid = regval;
> + chipid <<= 8;
> +
> + regval = i2c_smbus_read_byte_data(lp->client, ARCXCNN_ID_LSB);
> + chipid |= regval;
> +
> + snprintf(lp->chipname, sizeof(lp->chipname),
> + "%s-%04X", id->name, chipid);
> +
> + if (!lp->pdata) {
> + lp->pdata = devm_kzalloc(lp->dev,
> + sizeof(*lp->pdata), GFP_KERNEL);
> + if (!lp->pdata)
> + return -ENOMEM;
> +
> + /* Setup defaults based on power-on defaults */
> + lp->pdata->name = NULL;
> + lp->pdata->initial_brightness = s_ibright;
> + lp->pdata->leden = s_ileden;
> +
> + lp->pdata->led_config_0 = i2c_smbus_read_byte_data(
> + lp->client, ARCXCNN_FADECTRL);
> +
> + lp->pdata->led_config_1 = i2c_smbus_read_byte_data(
> + lp->client, ARCXCNN_ILED_CONFIG);
> + /* insure dim mode is not default pwm */
> + lp->pdata->led_config_1 |= ARCXCNN_ILED_DIM_INT;
> +
> + lp->pdata->dim_freq = i2c_smbus_read_byte_data(
> + lp->client, ARCXCNN_DIMFREQ);
> +
> + lp->pdata->comp_config = i2c_smbus_read_byte_data(
> + lp->client, ARCXCNN_COMP_CONFIG);
> +
> + lp->pdata->filter_config = i2c_smbus_read_byte_data(
> + lp->client, ARCXCNN_FILT_CONFIG);
> +
> + lp->pdata->trim_config = i2c_smbus_read_byte_data(
> + lp->client, ARCXCNN_IMAXTUNE);
> +
> + if (IS_ENABLED(CONFIG_OF))
> + arcxcnn_parse_dt(lp);
> + }
> +
> + i2c_set_clientdata(cl, lp);
> +
> + /* constrain settings to what is possible */
> + if (lp->pdata->initial_brightness > MAX_BRIGHTNESS)
> + lp->pdata->initial_brightness = MAX_BRIGHTNESS;
> +
> + /* set initial brightness */
> + arcxcnn_set_brightness(lp, lp->pdata->initial_brightness);
> +
> + /* set other register values directly */
> + i2c_smbus_write_byte_data(lp->client, ARCXCNN_FADECTRL,
> + lp->pdata->led_config_0);
> + i2c_smbus_write_byte_data(lp->client, ARCXCNN_ILED_CONFIG,
> + lp->pdata->led_config_1);
> + i2c_smbus_write_byte_data(lp->client, ARCXCNN_DIMFREQ,
> + lp->pdata->dim_freq);
> + i2c_smbus_write_byte_data(lp->client, ARCXCNN_COMP_CONFIG,
> + lp->pdata->comp_config);
> + i2c_smbus_write_byte_data(lp->client, ARCXCNN_FILT_CONFIG,
> + lp->pdata->filter_config);
> + i2c_smbus_write_byte_data(lp->client, ARCXCNN_IMAXTUNE,
> + lp->pdata->trim_config);
> +
> + /* set initial LED Enables */
> + arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
> + ARCXCNN_LEDEN_MASK, lp->pdata->leden);
> +
> + ret = arcxcnn_backlight_register(lp);
> + if (ret) {
> + dev_err(lp->dev,
> + "failed to register backlight. err: %d\n", ret);
> + return ret;
> + }
> +
> + ret = sysfs_create_group(&lp->dev->kobj, &arcxcnn_attr_group);
> + if (ret) {
> + dev_err(lp->dev, "failed to register sysfs. err: %d\n",
ret);
> + return ret;
> + }
> +
> + backlight_update_status(lp->bl);
> +
> + return 0;
> +}
> +
> +static int arcxcnn_remove(struct i2c_client *cl)
> +{
> + struct arcxcnn *lp = i2c_get_clientdata(cl);
> +
> + if (!s_no_reset_on_remove) {
> + /* disable all strings */
> + i2c_smbus_write_byte_data(lp->client,
> + ARCXCNN_LEDEN, 0x00);
> + /* reset the device */
> + i2c_smbus_write_byte_data(lp->client,
> + ARCXCNN_CMD, ARCXCNN_CMD_RESET);
> + }
> + lp->bl->props.brightness = 0;
> +
> + backlight_update_status(lp->bl);
> +
> + sysfs_remove_group(&lp->dev->kobj, &arcxcnn_attr_group);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id arcxcnn_dt_ids[] = {
> + { .compatible = "arc,arc2c0608" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, arcxcnn_dt_ids);
> +
> +static const struct i2c_device_id arcxcnn_ids[] = {
> + {"arc2c0608", ARC2C0608},
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, arcxcnn_ids);
> +
> +static struct i2c_driver arcxcnn_driver = {
> + .driver = {
> + .name = "arcxcnn_bl",
> + .of_match_table = of_match_ptr(arcxcnn_dt_ids),
> + },
> + .probe = arcxcnn_probe,
> + .remove = arcxcnn_remove,
> + .id_table = arcxcnn_ids,
> +};
> +module_i2c_driver(arcxcnn_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Brian Dodge <bdodge-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>");
> +MODULE_DESCRIPTION("ARCXCNN Backlight driver");
> diff --git a/include/linux/i2c/arcxcnn.h b/include/linux/i2c/arcxcnn.h
> new file mode 100644
> index 0000000..e378d63
> --- /dev/null
> +++ b/include/linux/i2c/arcxcnn.h
> @@ -0,0 +1,51 @@
> +/*
> + * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
What is 'ARC_X_C_0N_0N'?
Please use more general naming.
Maybe, you can find that name from specification document of that devices.
Best regards,
Jingoo Han
> + *
> + * Copyright 2016 ArcticSand, Inc.
> + * Author : Brian Dodge <bdodge-eV7fy4qpoLhpLGFMi4vTTA@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 version 2
> + * as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> along
> + * with this program; if not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef _ARCXCNN_H
> +#define _ARCXCNN_H
> +
> +enum arcxcnn_chip_id {
> + ARC2C0608
> +};
> +
> +/**
> + * struct arcxcnn_platform_data
> + * @name : Backlight driver name (NULL will use default)
> + * @initial_brightness : initial value of backlight brightness
> + * @leden : initial LED string enables, upper bit is global
> on/off
> + * @led_config_0 : fading speed (period between intensity steps)
> + * @led_config_1 : misc settings, see datasheet
> + * @dim_freq : pwm dimming frequency if in pwm mode
> + * @comp_config : misc config, see datasheet
> + * @filter_config : RC/PWM filter config, see datasheet
> + * @trim_config : full scale current trim, see datasheet
> + */
> +struct arcxcnn_platform_data {
> + const char *name;
> + u16 initial_brightness;
> + u8 leden;
> + u8 led_config_0;
> + u8 led_config_1;
> + u8 dim_freq;
> + u8 comp_config;
> + u8 filter_config;
> + u8 trim_config;
> +};
> +
> +#endif
> --
> 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
* Re: [PATCH v4 3/5] backlight: lm3533: Support initialization from Device Tree
From: Jingoo Han @ 2016-12-27 18:23 UTC (permalink / raw)
To: 'Pavel Machek', 'Bjorn Andersson'
Cc: 'Lee Jones', 'Rob Herring',
'Mark Rutland', 'Jonathan Cameron',
'Hartmut Knaack', 'Lars-Peter Clausen',
'Peter Meerwald-Stadler', 'Richard Purdie',
'Jacek Anaszewski', devicetree, linux-kernel, linux-iio,
linux-leds, 'Bjorn Andersson'
In-Reply-To: <20161227104630.GA15452@amd>
On Tuesday, December 27, 2016 5:47 AM, Pavel Machek wrote:
>
> On Mon 2016-12-26 10:11:51, Bjorn Andersson wrote:
> > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> >
> > Implement support for initialization of the lm3533 backlight from Device
> > Tree.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: Add am335x-boneblack-wireless
From: Tony Lindgren @ 2016-12-27 18:14 UTC (permalink / raw)
To: Robert Nelson
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jason Kridner
In-Reply-To: <CAOCHtYjx+KD3iy1cssjCLN0xjXBGJFZ_e1Qw2zRGbV4=X0+bHg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [161227 10:02]:
> On Tue, Dec 27, 2016 at 11:58 AM, Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
> > replaced by a TI wl1835 wireless module.
> >
> > This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
> > BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
> >
> > http://beagleboard.org/black-wireless
> > https://github.com/beagleboard/beaglebone-black-wireless
> >
> > firmware: https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
>
> Tony, this firmware should be there shortly, i have a pull request
> setup for Jason:
>
> https://github.com/beagleboard/beaglebone-black-wireless/pull/5
OK great, good to have these working out of the box with mainline
kernel :)
Tony
--
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/4] ARM: dts: Add am335x-boneblack-wireless
From: Robert Nelson @ 2016-12-27 18:01 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Robert Nelson, Jason Kridner
In-Reply-To: <20161227175837.28970-2-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Dec 27, 2016 at 11:58 AM, Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> BeagleBone Black Wireless is clone of the BeagleBone Black (BBB) with the Ethernet
> replaced by a TI wl1835 wireless module.
>
> This board can be indentified by the BWAx value after A335BNLT (BBB) in the at24 eeprom:
> BWAx [aa 55 33 ee 41 33 33 35 42 4e 4c 54 42 57 41 35 |.U3.A335BNLTBWA5|]
>
> http://beagleboard.org/black-wireless
> https://github.com/beagleboard/beaglebone-black-wireless
>
> firmware: https://github.com/beagleboard/beaglebone-black-wireless/tree/master/firmware
Tony, this firmware should be there shortly, i have a pull request
setup for Jason:
https://github.com/beagleboard/beaglebone-black-wireless/pull/5
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
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
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