* Re: [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
From: Sudeep Holla @ 2017-01-06 11:54 UTC (permalink / raw)
To: Michał Zegan, Neil Armstrong, khilman, carlo
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Sudeep Holla
In-Reply-To: <9f508097-f605-ebd8-20af-c3e798c6fdcc@poczta.onet.pl>
Hi Michał,
On 05/01/17 19:04, Michał Zegan wrote:
> Hello.
>
> The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
> it actually works, but...
> Loading the module causes few errors because of not found frequencies or
> something, then it is all okay. However after loading scpi-cpufreq you
> cannot actually power the cpu off and on. You will power it off
> successfully, but when trying to power it on, the cpufreq driver will
> error out,
Yes I had noticed this in past, this needs to be fixed. I had a patch
and seems like it slipped through the cracks. I will fins and post it.
> and then after it happens, the cpu that was trying to go
> online will be offline again, and that is a little... unfortunate. The
IIUC, you mean the cpufreq drive spits error on every hotplug event ?
If so yes, otherwise I think I didn't understand you concern above.
> question is, and I cannot really test that: will the module actually
> autoload after this change?
>
It should work, I had tested this in past.
--
Regards,
Sudeep
_______________________________________________
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 V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Arnd Bergmann @ 2017-01-06 11:43 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Benjamin Herrenschmidt, gabriele.paoloni,
Catalin Marinas, Will Deacon, linuxarm, Lorenzo Pieralisi,
Ming Lei, xuwei5, linux-serial, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, minyard, Liviu Dudau, john.garry,
Olof Johansson, Rob Herring, Bjorn Helgaas, kantyzc,
zhichang.yuan02, Linux Kernel Mailing List, zhichang.yuan,
zourongrong
In-Reply-To: <CACVXFVNS9n9_ty8y3CyqfRaLitqDKdk1mMOrQHM-enOgJtUBeQ@mail.gmail.com>
On Thursday, December 22, 2016 4:15:57 PM CET Ming Lei wrote:
> ERROR: "inb" [drivers/watchdog/wdt_pci.ko] undefined!
> ERROR: "outb" [drivers/watchdog/wdt_pci.ko] undefined!
> ERROR: "outb" [drivers/watchdog/pcwd_pci.ko] undefined!
> ERROR: "inb" [drivers/watchdog/pcwd_pci.ko] undefined!
> ERROR: "outw" [drivers/video/vgastate.ko] undefined!
> ERROR: "outb" [drivers/video/vgastate.ko] undefined!
> ERROR: "inb" [drivers/video/vgastate.ko] undefined!
> ERROR: "outw" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: "inb" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: "outb" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: "outw" [drivers/video/fbdev/tridentfb.ko] undefined!
> ERROR: "inb" [drivers/video/fbdev/tridentfb.ko] undefined!
> ERROR: "outb" [drivers/video/fbdev/tridentfb.ko] undefined!
> ERROR: "inb" [drivers/video/fbdev/tdfxfb.ko] undefined!
>
In case you haven't figured it out by now, the new code is simply
missing a few "EXPORT_SYMBOL" lines.
Arnd
^ permalink raw reply
* Re: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Russell King - ARM Linux @ 2017-01-06 11:42 UTC (permalink / raw)
To: Jerome Brunet
Cc: Florian Fainelli, netdev, devicetree, Andrew Lunn,
Alexandre TORGUE, Neil Armstrong, Martin Blumenstingl,
Kevin Hilman, linux-kernel, Yegor Yefremov, Julia Lawall,
Andre Roth, linux-amlogic, Carlo Caione, Giuseppe Cavallaro,
Andreas Färber, linux-arm-kernel
In-Reply-To: <1483697496.28003.40.camel@baylibre.com>
On Fri, Jan 06, 2017 at 11:11:36AM +0100, Jerome Brunet wrote:
> The purpose of this patch is to provide a way to mark as broken a
> particular eee mode. At first, it had nothing to do with "set_eee" but,
> as Florian rightly pointed out, users shouldn't be able to re-enable a
> broken mode.
I think something else has been missed - I don't see much point to
telling userspace that (eg) 1000baseT EEE is supported and then
ignore attempts to advertise it.
If it's broken, then arguably the hardware doesn't support the mode,
so we should really be masking those bits from the EEE supported mask
as well.
> I wonder if we should return an error though. With the current
> implementation, user space application could simply ask to activate
> everything, excepting the kernel to sort it out and return an error
> only if something horribly wrong happened. If we start returning an
> error for unsupported modes, we could break things. I guess we should
> just silently filter the requested modes.
The ethtool behaviour for advertisments is that errors are not returned
unless the attempted advert is really wrong.
So, for example, when setting an advertisment for link modes, we accept
the user's supplied mask, and bitwise AND it with the supported mask,
so unsupported link modes are cleared. Only if the result is an empty
mask do we then return an error to userspace.
It's similar for forcing the link parameters - phylib attempts to find
the best phy setting mode which fuzzily matches the users request, but
doesn't error out if we can't do exactly what the user requested.
In the EEE case, an empty mask is acceptable (it means "EEE is supported
in no link modes") so it isn't appropriate to return errors there.
> > - maybe the problem here is that the PCS doesn't support support
> > EEE in 1000baseT mode?
>
>
> It does, and that's kind of the problem. EEE in ON for 100Tx and 1000T
> by default with this PHY. I have several platform with the same MAC-PHY
> combination. Only the OdroidC2 shows this particular issue with 1000T-
> EEE
>
> As explained in other mails in this thread. The problem does not come
> from the MAC entering LPI. It actually comes from the link partner
> entering LPI on the Rx path under significant Tx transfer. For some
> reason, this completely mess up our PHY.
For a 1000baseT link to enter low power, both ends have to enter LPI
(see 802.3 78.1.3.3.1) - the Tx and Rx paths can't independently enter
LPI.
So, if you have a busy Tx link, the link itself can't be entering LPI.
Your link partner may be sending a request to enter LPI due to its own
Tx path being idle, which should then be forwarded to your MAC.
It's pretty hard to see what could be messed up with that - I'd have
expected the problems to occur when both ends were idle and the link
had entered low power mode.
> > On the SolidRun boards, they're using AR8035, and have suffered this
> > occasional link drop problem. What has been found is that it seems
> > to
> > be to do with the timing parameters, and it seemed to only be 1000bT
> > that was affected. I don't remember off hand exactly which or what
> > the change was they made to stabilise it though, but I can probabily
> > find out tomorrow.
> >
>
> Since the same combination of MAC-PHY works well on other designs, it
> is also my feeling that is has something to do with some timing
> parameter, maybe related to this particular PCB.
Maybe a different PHY interface? Meson seems to use RGMII, maybe
others use SGMII - but then I'd expect 100base-Tx to also be broken.
So not really sure.
I was talking to Florian about that last night, because the mis-named
phy_init_eee() tests for various phy interface modes before proceeding,
which seems to be fairly rubbish as the list of interface modes is
gradually increasing since it was introduced (and I need to add SGMII
to it.) The conclusion I've come to there is that the test should
never have been part of phylib, because if there are restrictions on
which phy interface modes are allowable for EEE, they're likely to be
either PHY or MAC specific.
The other problem that having the test there causes is that if the
existing users can't handle EEE over SGMII, then when I add SGMII to
support my hardware, they end up breaking - far from desirable.
There's no information on why the test is there, or even which PHYs
or MACs it's applicable to, which makes this unnecessarily more
difficult to now resolve.
My feeling is that the integration of EEE into phylib is fairly poor
at the moment, and we need to be a lot smarter about it.
BTW, one of the problems (not caused by your patch) is that changing
the EEE advertisment does not (on all PHY drivers) cause the link to
be renegotiated - there's no call to phy_start_aneg() when the advert
changes, and even if there was, there's no guarantee that
phy_start_aneg() will even set the AN restart bit in the control
register.
However, given that you're hooking into the set_eee function, I'm not
sure why you placed your EEE advertisment thing into config_aneg() -
isn't it more an initialisation thing (so should be in config_init()?)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v4 5/5] arm64: dts: exynos: Add tm2 touchkey node
From: Andi Shyti @ 2017-01-06 11:41 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Chanwoo Choi, Beomho Seo
Cc: devicetree, linux-samsung-soc, Jaechul Lee, linux-kernel,
Andi Shyti, Andi Shyti, linux-input, Jaechul Lee,
linux-arm-kernel
In-Reply-To: <20170106114114.19321-1-andi.shyti@samsung.com>
From: Jaechul Lee <jcsing.lee@samsung.com>
Add DT node support for TM2 touchkey device.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index d30b45a9c0d4..15bdc2e9f2a3 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -18,6 +18,19 @@
compatible = "samsung,tm2e", "samsung,exynos5433";
};
+&hsi2c_9 {
+ status = "okay";
+
+ touchkey@20 {
+ compatible = "samsung,tm2-touchkey";
+ reg = <0x20>;
+ interrupt-parent = <&gpa3>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ vcc-supply = <&ldo32_reg>;
+ vdd-supply = <&ldo33_reg>;
+ };
+};
+
®ulators {
ldo31_reg: LDO31 {
regulator-name = "TSP_VDD_1.85V_AP";
--
2.11.0
^ permalink raw reply related
* [PATCH v4 4/5] input: tm2-touchkey: Add touchkey driver support for TM2
From: Andi Shyti @ 2017-01-06 11:41 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Chanwoo Choi, Beomho Seo
Cc: devicetree, linux-samsung-soc, Jaechul Lee, linux-kernel,
Andi Shyti, Andi Shyti, linux-input, Jaechul Lee,
linux-arm-kernel
In-Reply-To: <20170106114114.19321-1-andi.shyti@samsung.com>
From: Jaechul Lee <jcsing.lee@samsung.com>
This patch adds support for the TM2 touch key and led
functionality.
The driver interfaces with userspace through an input device and
reports KEY_PHONE and KEY_BACK event types. LED brightness can be
controlled by "/sys/class/leds/tm2-touchkey/brightness".
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
---
drivers/input/keyboard/Kconfig | 11 ++
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/tm2-touchkey.c | 280 ++++++++++++++++++++++++++++++++++
3 files changed, 292 insertions(+)
create mode 100644 drivers/input/keyboard/tm2-touchkey.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index cbd75cf44739..e6e98585b4b0 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -666,6 +666,17 @@ config KEYBOARD_TC3589X
To compile this driver as a module, choose M here: the
module will be called tc3589x-keypad.
+config KEYBOARD_TM2_TOUCHKEY
+ tristate "tm2-touchkey support"
+ depends on I2C
+ depends on LEDS_CLASS
+ help
+ Say Y here to enable device driver for tm2-touchkey with
+ LED control for the Exynos5433 TM2 board.
+
+ To compile this driver as a module, choose M here.
+ module will be called tm2-touchkey.
+
config KEYBOARD_TWL4030
tristate "TI TWL4030/TWL5030/TPS659x0 keypad support"
depends on TWL4030_CORE
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index d9f4cfcf3410..7d9acff819a7 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
obj-$(CONFIG_KEYBOARD_SUNKBD) += sunkbd.o
obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
+obj-$(CONFIG_KEYBOARD_TM2_TOUCHKEY) += tm2-touchkey.o
obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/tm2-touchkey.c b/drivers/input/keyboard/tm2-touchkey.c
new file mode 100644
index 000000000000..92eacb62f8e7
--- /dev/null
+++ b/drivers/input/keyboard/tm2-touchkey.c
@@ -0,0 +1,280 @@
+/*
+ * TM2 touchkey device driver
+ *
+ * Copyright 2005 Phil Blundell
+ * Copyright 2016 Samsung Electronics Co., Ltd.
+ *
+ * Author: Beomho Seo <beomho.seo@samsung.com>
+ * Author: Jaechul Lee <jcsing.lee@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/bitops.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pm.h>
+#include <linux/regulator/consumer.h>
+
+#define TM2_TOUCHKEY_DEV_NAME "tm2-touchkey"
+#define TM2_TOUCHKEY_KEYCODE_REG 0x03
+#define TM2_TOUCHKEY_BASE_REG 0x00
+#define TM2_TOUCHKEY_CMD_LED_ON 0x10
+#define TM2_TOUCHKEY_CMD_LED_OFF 0x20
+#define TM2_TOUCHKEY_BIT_PRESS_EV BIT(3)
+#define TM2_TOUCHKEY_BIT_KEYCODE GENMASK(2, 0)
+#define TM2_TOUCHKEY_LED_VOLTAGE_MIN 2500000
+#define TM2_TOUCHKEY_LED_VOLTAGE_MAX 3300000
+
+enum {
+ TM2_TOUCHKEY_KEY_MENU = 0x1,
+ TM2_TOUCHKEY_KEY_BACK,
+};
+
+struct tm2_touchkey_data {
+ struct i2c_client *client;
+ struct input_dev *input_dev;
+ struct led_classdev led_dev;
+ struct regulator_bulk_data regulators[2];
+
+ u8 keycode_type;
+ u8 pressed;
+};
+
+static void tm2_touchkey_led_brightness_set(struct led_classdev *led_dev,
+ enum led_brightness brightness)
+{
+ struct tm2_touchkey_data *touchkey =
+ container_of(led_dev, struct tm2_touchkey_data, led_dev);
+ u32 volt;
+ u8 data;
+
+ if (brightness == LED_OFF) {
+ volt = TM2_TOUCHKEY_LED_VOLTAGE_MIN;
+ data = TM2_TOUCHKEY_CMD_LED_OFF;
+ } else {
+ volt = TM2_TOUCHKEY_LED_VOLTAGE_MAX;
+ data = TM2_TOUCHKEY_CMD_LED_ON;
+ }
+
+ regulator_set_voltage(touchkey->regulators[1].consumer, volt, volt);
+ i2c_smbus_write_byte_data(touchkey->client,
+ TM2_TOUCHKEY_BASE_REG, data);
+}
+
+static int tm2_touchkey_power_enable(struct tm2_touchkey_data *touchkey)
+{
+ int ret = 0;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(touchkey->regulators),
+ touchkey->regulators);
+ if (ret)
+ return ret;
+
+ /* waiting for device initialization, at least 150ms */
+ msleep(150);
+
+ return 0;
+}
+
+static void tm2_touchkey_power_disable(void *data)
+{
+ struct tm2_touchkey_data *touchkey = data;
+
+ regulator_bulk_disable(ARRAY_SIZE(touchkey->regulators),
+ touchkey->regulators);
+}
+
+static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid)
+{
+ struct tm2_touchkey_data *touchkey = devid;
+ u32 data;
+
+ data = i2c_smbus_read_byte_data(touchkey->client,
+ TM2_TOUCHKEY_KEYCODE_REG);
+
+ if (data < 0) {
+ dev_err(&touchkey->client->dev, "Failed to read i2c data\n");
+ return IRQ_HANDLED;
+ }
+
+ touchkey->keycode_type = data & TM2_TOUCHKEY_BIT_KEYCODE;
+ touchkey->pressed = !(data & TM2_TOUCHKEY_BIT_PRESS_EV);
+
+ if (touchkey->keycode_type != TM2_TOUCHKEY_KEY_MENU &&
+ touchkey->keycode_type != TM2_TOUCHKEY_KEY_BACK) {
+ dev_warn(&touchkey->client->dev, "Skip unhandled keycode(%d)\n",
+ touchkey->keycode_type);
+ return IRQ_HANDLED;
+ }
+
+ if (!touchkey->pressed) {
+ input_report_key(touchkey->input_dev, KEY_PHONE, 0);
+ input_report_key(touchkey->input_dev, KEY_BACK, 0);
+ } else {
+ if (touchkey->keycode_type == TM2_TOUCHKEY_KEY_MENU)
+ input_report_key(touchkey->input_dev,
+ KEY_PHONE, 1);
+ else
+ input_report_key(touchkey->input_dev,
+ KEY_BACK, 1);
+ }
+ input_sync(touchkey->input_dev);
+
+ return IRQ_HANDLED;
+}
+
+static int tm2_touchkey_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct tm2_touchkey_data *touchkey;
+ int ret;
+
+ ret = i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BYTE |
+ I2C_FUNC_SMBUS_BYTE_DATA);
+ if (!ret) {
+ dev_err(&client->dev, "No I2C functionality found\n");
+ return -ENODEV;
+ }
+
+ touchkey = devm_kzalloc(&client->dev, sizeof(*touchkey), GFP_KERNEL);
+ if (!touchkey)
+ return -ENOMEM;
+
+ touchkey->client = client;
+ i2c_set_clientdata(client, touchkey);
+
+ /* regulators */
+ touchkey->regulators[0].supply = "vcc";
+ touchkey->regulators[1].supply = "vdd";
+ ret = devm_regulator_bulk_get(&client->dev,
+ ARRAY_SIZE(touchkey->regulators),
+ touchkey->regulators);
+ if (ret) {
+ dev_err(&client->dev, "Failed to get regulators\n");
+ return ret;
+ }
+
+ /* power */
+ ret = tm2_touchkey_power_enable(touchkey);
+ if (ret) {
+ dev_err(&client->dev, "Failed to enable power\n");
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(&client->dev,
+ tm2_touchkey_power_disable, touchkey);
+ if (ret)
+ return ret;
+
+ /* input device */
+ touchkey->input_dev = devm_input_allocate_device(&client->dev);
+ if (!touchkey->input_dev) {
+ dev_err(&client->dev, "Failed to alloc input device\n");
+ return -ENOMEM;
+ }
+ touchkey->input_dev->name = TM2_TOUCHKEY_DEV_NAME;
+ touchkey->input_dev->id.bustype = BUS_I2C;
+
+ set_bit(EV_KEY, touchkey->input_dev->evbit);
+ input_set_capability(touchkey->input_dev, EV_KEY, KEY_PHONE);
+ input_set_capability(touchkey->input_dev, EV_KEY, KEY_BACK);
+
+ input_set_drvdata(touchkey->input_dev, touchkey);
+
+ ret = input_register_device(touchkey->input_dev);
+ if (ret) {
+ dev_err(&client->dev, "Failed to register input device\n");
+ return ret;
+ }
+
+ /* irq */
+ ret = devm_request_threaded_irq(&client->dev,
+ client->irq, NULL,
+ tm2_touchkey_irq_handler,
+ IRQF_ONESHOT, TM2_TOUCHKEY_DEV_NAME,
+ touchkey);
+ if (ret) {
+ dev_err(&client->dev, "Failed to request threaded irq\n");
+ return ret;
+ }
+
+ /* led device */
+ touchkey->led_dev.name = TM2_TOUCHKEY_DEV_NAME;
+ touchkey->led_dev.brightness = LED_FULL;
+ touchkey->led_dev.max_brightness = LED_FULL;
+ touchkey->led_dev.brightness_set = tm2_touchkey_led_brightness_set;
+
+ ret = devm_led_classdev_register(&client->dev, &touchkey->led_dev);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to register touchkey led\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __maybe_unused tm2_touchkey_suspend(struct device *dev)
+{
+ struct tm2_touchkey_data *touchkey = dev_get_drvdata(dev);
+
+ disable_irq(touchkey->client->irq);
+ tm2_touchkey_power_disable(touchkey);
+
+ return 0;
+}
+
+static int __maybe_unused tm2_touchkey_resume(struct device *dev)
+{
+ struct tm2_touchkey_data *touchkey = dev_get_drvdata(dev);
+ int ret;
+
+ enable_irq(touchkey->client->irq);
+ ret = tm2_touchkey_power_enable(touchkey);
+ if (ret)
+ dev_err(dev, "Failed to enable power\n");
+
+ return ret;
+}
+
+static SIMPLE_DEV_PM_OPS(tm2_touchkey_pm_ops, tm2_touchkey_suspend,
+ tm2_touchkey_resume);
+
+static const struct i2c_device_id tm2_touchkey_id_table[] = {
+ {TM2_TOUCHKEY_DEV_NAME, 0},
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, tm2_touchkey_id_table);
+
+static const struct of_device_id tm2_touchkey_of_match[] = {
+ {.compatible = "samsung,tm2-touchkey",},
+ {},
+};
+MODULE_DEVICE_TABLE(of, tm2_touchkey_of_match);
+
+static struct i2c_driver tm2_touchkey_driver = {
+ .driver = {
+ .name = TM2_TOUCHKEY_DEV_NAME,
+ .pm = &tm2_touchkey_pm_ops,
+ .of_match_table = of_match_ptr(tm2_touchkey_of_match),
+ },
+ .probe = tm2_touchkey_probe,
+ .id_table = tm2_touchkey_id_table,
+};
+
+module_i2c_driver(tm2_touchkey_driver);
+
+MODULE_AUTHOR("Beomho Seo <beomho.seo@samsung.com>");
+MODULE_AUTHOR("Jaechul Lee <jcsing.lee@samsung.com>");
+MODULE_DESCRIPTION("Samsung touchkey driver");
+MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* [PATCH v4 3/5] input: Add support for the tm2 touchkey device driver
From: Andi Shyti @ 2017-01-06 11:41 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Chanwoo Choi, Beomho Seo
Cc: devicetree, linux-samsung-soc, Jaechul Lee, linux-kernel,
Andi Shyti, Andi Shyti, linux-input, Jaechul Lee,
linux-arm-kernel
In-Reply-To: <20170106114114.19321-1-andi.shyti@samsung.com>
From: Jaechul Lee <jcsing.lee@samsung.com>
This patch adds the binding description of the tm2 touchkey
device driver.
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
---
.../bindings/input/samsung,tm2-touchkey.txt | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
diff --git a/Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt b/Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
new file mode 100644
index 000000000000..4de1af0f0a37
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
@@ -0,0 +1,27 @@
+Samsung tm2-touchkey
+
+Required properties:
+- compatible: must be "samsung,tm2-touchkey"
+- reg: I2C address of the chip.
+- interrupt-parent: a phandle for the interrupt controller (see interrupt
+ binding[0]).
+- interrupts: interrupt to which the chip is connected (see interrupt
+ binding[0]).
+- vcc-supply : internal regulator output. 1.8V
+- vdd-supply : power supply for IC 3.3V
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+Example:
+ &i2c0 {
+ /* ... */
+
+ touchkey@20 {
+ compatible = "samsung,tm2-touchkey";
+ reg = <0x20>;
+ interrupt-parent = <&gpa3>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ vcc-supply=<&ldo32_reg>;
+ vdd-supply=<&ldo33_reg>;
+ };
+ };
--
2.11.0
^ permalink raw reply related
* [PATCH v4 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Andi Shyti @ 2017-01-06 11:41 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Chanwoo Choi, Beomho Seo
Cc: devicetree, linux-samsung-soc, Jaechul Lee, linux-kernel,
Andi Shyti, Andi Shyti, linux-input, Jaechul Lee,
linux-arm-kernel
In-Reply-To: <20170106114114.19321-1-andi.shyti@samsung.com>
Currently tm2e dts includes tm2 but there are some differences
between the two boards and tm2 has some properties that tm2e
doesn't have.
That's why it's important to keep the two dts files independent
and put all the commonalities in a tm2-common.dtsi file.
At the current status the only two differences between the two
dts files (besides the board name) are ldo31 and ldo38.
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
---
...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 24 +-
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1153 +-------------------
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 22 +-
3 files changed, 56 insertions(+), 1143 deletions(-)
copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (98%)
rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
similarity index 98%
copy from arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
copy to arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index e8971f4a5977..c43f9a38adf6 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -3,8 +3,8 @@
*
* Copyright (c) 2016 Samsung Electronics Co., Ltd.
*
- * Device tree source file for Samsung's TM2 board which is based on
- * Samsung Exynos5433 SoC.
+ * Common device tree source file for Samsung's TM2 and TM2E boards
+ * which are based on Samsung Exynos5433 SoC.
*
* 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
@@ -322,7 +322,7 @@
"s2mps13_bt";
};
- regulators {
+ regulators: regulators {
ldo1_reg: LDO1 {
regulator-name = "VDD_ALIVE_0.9V_AP";
regulator-min-microvolt = <900000>;
@@ -552,11 +552,10 @@
regulator-max-microvolt = <3300000>;
};
- ldo31_reg: LDO31 {
- regulator-name = "TSP_VDD_1.85V_AP";
- regulator-min-microvolt = <1850000>;
- regulator-max-microvolt = <1850000>;
- };
+ /*
+ * LDO31 differs from target to target,
+ * its definition is in the .dts
+ */
ldo32_reg: LDO32 {
regulator-name = "VTOUCH_1.8V_AP";
@@ -595,11 +594,10 @@
regulator-max-microvolt = <1800000>;
};
- ldo38_reg: LDO38 {
- regulator-name = "VCC_3.0V_MOTOR_AP";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
+ /*
+ * LDO38 differs from target to target,
+ * its definition is in the .dts
+ */
ldo39_reg: LDO39 {
regulator-name = "V_HRM_1.8V";
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
dissimilarity index 98%
index e8971f4a5977..d30b45a9c0d4 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -1,1120 +1,33 @@
-/*
- * SAMSUNG Exynos5433 TM2 board device tree source
- *
- * Copyright (c) 2016 Samsung Electronics Co., Ltd.
- *
- * Device tree source file for Samsung's TM2 board which is based on
- * Samsung Exynos5433 SoC.
- *
- * 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.
- */
-
-/dts-v1/;
-#include "exynos5433.dtsi"
-#include <dt-bindings/clock/samsung,s2mps11.h>
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "Samsung TM2 board";
- compatible = "samsung,tm2", "samsung,exynos5433";
-
- aliases {
- gsc0 = &gsc_0;
- gsc1 = &gsc_1;
- gsc2 = &gsc_2;
- pinctrl0 = &pinctrl_alive;
- pinctrl1 = &pinctrl_aud;
- pinctrl2 = &pinctrl_cpif;
- pinctrl3 = &pinctrl_ese;
- pinctrl4 = &pinctrl_finger;
- pinctrl5 = &pinctrl_fsys;
- pinctrl6 = &pinctrl_imem;
- pinctrl7 = &pinctrl_nfc;
- pinctrl8 = &pinctrl_peric;
- pinctrl9 = &pinctrl_touch;
- serial0 = &serial_0;
- serial1 = &serial_1;
- serial2 = &serial_2;
- serial3 = &serial_3;
- spi0 = &spi_0;
- spi1 = &spi_1;
- spi2 = &spi_2;
- spi3 = &spi_3;
- spi4 = &spi_4;
- mshc0 = &mshc_0;
- mshc2 = &mshc_2;
- };
-
- chosen {
- stdout-path = &serial_1;
- };
-
- memory@20000000 {
- device_type = "memory";
- reg = <0x0 0x20000000 0x0 0xc0000000>;
- };
-
- gpio-keys {
- compatible = "gpio-keys";
-
- power-key {
- gpios = <&gpa2 7 GPIO_ACTIVE_LOW>;
- linux,code = <KEY_POWER>;
- label = "power key";
- debounce-interval = <10>;
- };
-
- volume-up-key {
- gpios = <&gpa2 0 GPIO_ACTIVE_LOW>;
- linux,code = <KEY_VOLUMEUP>;
- label = "volume-up key";
- debounce-interval = <10>;
- };
-
- volume-down-key {
- gpios = <&gpa2 1 GPIO_ACTIVE_LOW>;
- linux,code = <KEY_VOLUMEDOWN>;
- label = "volume-down key";
- debounce-interval = <10>;
- };
-
- homepage-key {
- gpios = <&gpa0 3 GPIO_ACTIVE_LOW>;
- linux,code = <KEY_MENU>;
- label = "homepage key";
- debounce-interval = <10>;
- };
- };
-
- i2c_max98504: i2c-gpio-0 {
- compatible = "i2c-gpio";
- gpios = <&gpd0 1 GPIO_ACTIVE_HIGH /* SPK_AMP_SDA */
- &gpd0 0 GPIO_ACTIVE_HIGH /* SPK_AMP_SCL */ >;
- i2c-gpio,delay-us = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
- status = "okay";
-
- max98504: max98504@31 {
- compatible = "maxim,max98504";
- reg = <0x31>;
- maxim,rx-path = <1>;
- maxim,tx-path = <1>;
- maxim,tx-channel-mask = <3>;
- maxim,tx-channel-source = <2>;
- };
- };
-
- sound {
- compatible = "samsung,tm2-audio";
- audio-codec = <&wm5110>;
- i2s-controller = <&i2s0>;
- audio-amplifier = <&max98504>;
- mic-bias-gpios = <&gpr3 2 GPIO_ACTIVE_HIGH>;
- model = "wm5110";
- samsung,audio-routing =
- /* Headphone */
- "HP", "HPOUT1L",
- "HP", "HPOUT1R",
-
- /* Speaker */
- "SPK", "SPKOUT",
- "SPKOUT", "HPOUT2L",
- "SPKOUT", "HPOUT2R",
-
- /* Receiver */
- "RCV", "HPOUT3L",
- "RCV", "HPOUT3R";
- status = "okay";
- };
-};
-
-&adc {
- vdd-supply = <&ldo3_reg>;
- status = "okay";
-
- thermistor-ap {
- compatible = "murata,ncp03wf104";
- pullup-uv = <1800000>;
- pullup-ohm = <100000>;
- pulldown-ohm = <0>;
- io-channels = <&adc 0>;
- };
-
- thermistor-battery {
- compatible = "murata,ncp03wf104";
- pullup-uv = <1800000>;
- pullup-ohm = <100000>;
- pulldown-ohm = <0>;
- io-channels = <&adc 1>;
- #thermal-sensor-cells = <0>;
- };
-
- thermistor-charger {
- compatible = "murata,ncp03wf104";
- pullup-uv = <1800000>;
- pullup-ohm = <100000>;
- pulldown-ohm = <0>;
- io-channels = <&adc 2>;
- };
-};
-
-&bus_g2d_400 {
- devfreq-events = <&ppmu_event0_d0_general>, <&ppmu_event0_d1_general>;
- vdd-supply = <&buck4_reg>;
- exynos,saturation-ratio = <10>;
- status = "okay";
-};
-
-&bus_g2d_266 {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_gscl {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_hevc {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_jpeg {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_mfc {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_mscl {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_noc0 {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_noc1 {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_noc2 {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&cmu_aud {
- assigned-clocks = <&cmu_aud CLK_MOUT_AUD_PLL_USER>;
- assigned-clock-parents = <&cmu_top CLK_FOUT_AUD_PLL>;
-};
-
-&cmu_fsys {
- assigned-clocks = <&cmu_top CLK_MOUT_SCLK_USBDRD30>,
- <&cmu_top CLK_MOUT_SCLK_USBHOST30>,
- <&cmu_fsys CLK_MOUT_SCLK_USBDRD30_USER>,
- <&cmu_fsys CLK_MOUT_SCLK_USBHOST30_USER>,
- <&cmu_fsys CLK_MOUT_PHYCLK_USBDRD30_UDRD30_PIPE_PCLK_USER>,
- <&cmu_fsys CLK_MOUT_PHYCLK_USBHOST30_UHOST30_PIPE_PCLK_USER>,
- <&cmu_fsys CLK_MOUT_PHYCLK_USBDRD30_UDRD30_PHYCLOCK_USER>,
- <&cmu_fsys CLK_MOUT_PHYCLK_USBHOST30_UHOST30_PHYCLOCK_USER>,
- <&cmu_top CLK_DIV_SCLK_USBDRD30>,
- <&cmu_top CLK_DIV_SCLK_USBHOST30>;
- assigned-clock-parents = <&cmu_top CLK_MOUT_BUS_PLL_USER>,
- <&cmu_top CLK_MOUT_BUS_PLL_USER>,
- <&cmu_top CLK_SCLK_USBDRD30_FSYS>,
- <&cmu_top CLK_SCLK_USBHOST30_FSYS>,
- <&cmu_fsys CLK_PHYCLK_USBDRD30_UDRD30_PIPE_PCLK_PHY>,
- <&cmu_fsys CLK_PHYCLK_USBHOST30_UHOST30_PIPE_PCLK_PHY>,
- <&cmu_fsys CLK_PHYCLK_USBDRD30_UDRD30_PHYCLOCK_PHY>,
- <&cmu_fsys CLK_PHYCLK_USBHOST30_UHOST30_PHYCLOCK_PHY>;
- assigned-clock-rates = <0>, <0>, <0>, <0>, <0>, <0>, <0>, <0>,
- <66700000>, <66700000>;
-};
-
-&cmu_gscl {
- assigned-clocks = <&cmu_gscl CLK_MOUT_ACLK_GSCL_111_USER>,
- <&cmu_gscl CLK_MOUT_ACLK_GSCL_333_USER>;
- assigned-clock-parents = <&cmu_top CLK_ACLK_GSCL_111>,
- <&cmu_top CLK_ACLK_GSCL_333>;
-};
-
-&cmu_mfc {
- assigned-clocks = <&cmu_mfc CLK_MOUT_ACLK_MFC_400_USER>;
- assigned-clock-parents = <&cmu_top CLK_ACLK_MFC_400>;
-};
-
-&cmu_mscl {
- assigned-clocks = <&cmu_mscl CLK_MOUT_ACLK_MSCL_400_USER>,
- <&cmu_mscl CLK_MOUT_SCLK_JPEG_USER>,
- <&cmu_mscl CLK_MOUT_SCLK_JPEG>,
- <&cmu_top CLK_MOUT_SCLK_JPEG_A>;
- assigned-clock-parents = <&cmu_top CLK_ACLK_MSCL_400>,
- <&cmu_top CLK_SCLK_JPEG_MSCL>,
- <&cmu_mscl CLK_MOUT_SCLK_JPEG_USER>,
- <&cmu_top CLK_MOUT_BUS_PLL_USER>;
-};
-
-&cpu0 {
- cpu-supply = <&buck3_reg>;
-};
-
-&cpu4 {
- cpu-supply = <&buck2_reg>;
-};
-
-&decon {
- status = "okay";
-
- i80-if-timings {
- };
-};
-
-&dsi {
- status = "okay";
- vddcore-supply = <&ldo6_reg>;
- vddio-supply = <&ldo7_reg>;
- samsung,pll-clock-frequency = <24000000>;
- pinctrl-names = "default";
- pinctrl-0 = <&te_irq>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
-
- dsi_out: endpoint {
- samsung,burst-clock-frequency = <512000000>;
- samsung,esc-clock-frequency = <16000000>;
- };
- };
- };
-};
-
-&hsi2c_0 {
- status = "okay";
- clock-frequency = <2500000>;
-
- s2mps13-pmic@66 {
- compatible = "samsung,s2mps13-pmic";
- interrupt-parent = <&gpa0>;
- interrupts = <7 IRQ_TYPE_NONE>;
- reg = <0x66>;
- samsung,s2mps11-wrstbi-ground;
-
- s2mps13_osc: clocks {
- compatible = "samsung,s2mps13-clk";
- #clock-cells = <1>;
- clock-output-names = "s2mps13_ap", "s2mps13_cp",
- "s2mps13_bt";
- };
-
- regulators {
- ldo1_reg: LDO1 {
- regulator-name = "VDD_ALIVE_0.9V_AP";
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <900000>;
- regulator-always-on;
- };
-
- ldo2_reg: LDO2 {
- regulator-name = "VDDQ_MMC2_2.8V_AP";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo3_reg: LDO3 {
- regulator-name = "VDD1_E_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
-
- ldo4_reg: LDO4 {
- regulator-name = "VDD10_MIF_PLL_1.0V_AP";
- regulator-min-microvolt = <1300000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo5_reg: LDO5 {
- regulator-name = "VDD10_DPLL_1.0V_AP";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo6_reg: LDO6 {
- regulator-name = "VDD10_MIPI2L_1.0V_AP";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo7_reg: LDO7 {
- regulator-name = "VDD18_MIPI2L_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo8_reg: LDO8 {
- regulator-name = "VDD18_LLI_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo9_reg: LDO9 {
- regulator-name = "VDD18_ABB_ETC_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo10_reg: LDO10 {
- regulator-name = "VDD33_USB30_3.0V_AP";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo11_reg: LDO11 {
- regulator-name = "VDD_INT_M_1.0V_AP";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo12_reg: LDO12 {
- regulator-name = "VDD_KFC_M_1.1V_AP";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1350000>;
- regulator-always-on;
- };
-
- ldo13_reg: LDO13 {
- regulator-name = "VDD_G3D_M_0.95V_AP";
- regulator-min-microvolt = <950000>;
- regulator-max-microvolt = <950000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo14_reg: LDO14 {
- regulator-name = "VDDQ_M1_LDO_1.2V_AP";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo15_reg: LDO15 {
- regulator-name = "VDDQ_M2_LDO_1.2V_AP";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo16_reg: LDO16 {
- regulator-name = "VDDQ_EFUSE";
- regulator-min-microvolt = <1400000>;
- regulator-max-microvolt = <3400000>;
- regulator-always-on;
- };
-
- ldo17_reg: LDO17 {
- regulator-name = "V_TFLASH_2.8V_AP";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo18_reg: LDO18 {
- regulator-name = "V_CODEC_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo19_reg: LDO19 {
- regulator-name = "VDDA_1.8V_COMP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
-
- ldo20_reg: LDO20 {
- regulator-name = "VCC_2.8V_AP";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-always-on;
- };
-
- ldo21_reg: LDO21 {
- regulator-name = "VT_CAM_1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo22_reg: LDO22 {
- regulator-name = "CAM_IO_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo23_reg: LDO23 {
- regulator-name = "CAM_SEN_CORE_1.05V_AP";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- };
-
- ldo24_reg: LDO24 {
- regulator-name = "VT_CAM_1.2V";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- };
-
- ldo25_reg: LDO25 {
- regulator-name = "UNUSED_LDO25";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-always-off;
- };
-
- ldo26_reg: LDO26 {
- regulator-name = "CAM_AF_2.8V_AP";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo27_reg: LDO27 {
- regulator-name = "VCC_3.0V_LCD_AP";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
-
- ldo28_reg: LDO28 {
- regulator-name = "VCC_1.8V_LCD_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo29_reg: LDO29 {
- regulator-name = "VT_CAM_2.8V";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
-
- ldo30_reg: LDO30 {
- regulator-name = "TSP_AVDD_3.3V_AP";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo31_reg: LDO31 {
- regulator-name = "TSP_VDD_1.85V_AP";
- regulator-min-microvolt = <1850000>;
- regulator-max-microvolt = <1850000>;
- };
-
- ldo32_reg: LDO32 {
- regulator-name = "VTOUCH_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo33_reg: LDO33 {
- regulator-name = "VTOUCH_LED_3.3V";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <3300000>;
- regulator-ramp-delay = <12500>;
- };
-
- ldo34_reg: LDO34 {
- regulator-name = "VCC_1.8V_MHL_AP";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <2100000>;
- };
-
- ldo35_reg: LDO35 {
- regulator-name = "OIS_VM_2.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo36_reg: LDO36 {
- regulator-name = "VSIL_1.0V";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- };
-
- ldo37_reg: LDO37 {
- regulator-name = "VF_1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo38_reg: LDO38 {
- regulator-name = "VCC_3.0V_MOTOR_AP";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
-
- ldo39_reg: LDO39 {
- regulator-name = "V_HRM_1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo40_reg: LDO40 {
- regulator-name = "V_HRM_3.3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- buck1_reg: BUCK1 {
- regulator-name = "VDD_MIF_0.9V_AP";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck2_reg: BUCK2 {
- regulator-name = "VDD_EGL_1.0V_AP";
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck3_reg: BUCK3 {
- regulator-name = "VDD_KFC_1.0V_AP";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck4_reg: BUCK4 {
- regulator-name = "VDD_INT_0.95V_AP";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck5_reg: BUCK5 {
- regulator-name = "VDD_DISP_CAM0_0.9V_AP";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck6_reg: BUCK6 {
- regulator-name = "VDD_G3D_0.9V_AP";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck7_reg: BUCK7 {
- regulator-name = "VDD_MEM1_1.2V_AP";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- };
-
- buck8_reg: BUCK8 {
- regulator-name = "VDD_LLDO_1.35V_AP";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- buck9_reg: BUCK9 {
- regulator-name = "VDD_MLDO_2.0V_AP";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- buck10_reg: BUCK10 {
- regulator-name = "vdd_mem2";
- regulator-min-microvolt = <550000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- };
- };
- };
-};
-
-&hsi2c_8 {
- status = "okay";
-
- max77843@66 {
- compatible = "maxim,max77843";
- interrupt-parent = <&gpa1>;
- interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
- reg = <0x66>;
-
- muic: max77843-muic {
- compatible = "maxim,max77843-muic";
- };
-
- regulators {
- compatible = "maxim,max77843-regulator";
- safeout1_reg: SAFEOUT1 {
- regulator-name = "SAFEOUT1";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <4950000>;
- };
-
- safeout2_reg: SAFEOUT2 {
- regulator-name = "SAFEOUT2";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <4950000>;
- };
-
- charger_reg: CHARGER {
- regulator-name = "CHARGER";
- regulator-min-microamp = <100000>;
- regulator-max-microamp = <3150000>;
- };
- };
-
- haptic: max77843-haptic {
- compatible = "maxim,max77843-haptic";
- haptic-supply = <&ldo38_reg>;
- pwms = <&pwm 0 33670 0>;
- pwm-names = "haptic";
- };
- };
-};
-
-&i2s0 {
- status = "okay";
-};
-
-&mshc_0 {
- status = "okay";
- num-slots = <1>;
- mmc-hs200-1_8v;
- mmc-hs400-1_8v;
- cap-mmc-highspeed;
- non-removable;
- card-detect-delay = <200>;
- samsung,dw-mshc-ciu-div = <3>;
- samsung,dw-mshc-sdr-timing = <0 4>;
- samsung,dw-mshc-ddr-timing = <0 2>;
- samsung,dw-mshc-hs400-timing = <0 3>;
- samsung,read-strobe-delay = <90>;
- fifo-depth = <0x80>;
- pinctrl-names = "default";
- pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_qrdy &sd0_bus1 &sd0_bus4
- &sd0_bus8 &sd0_rdqs>;
- bus-width = <8>;
- assigned-clocks = <&cmu_top CLK_SCLK_MMC0_FSYS>;
- assigned-clock-rates = <800000000>;
-};
-
-&mshc_2 {
- status = "okay";
- num-slots = <1>;
- cap-sd-highspeed;
- disable-wp;
- cd-gpios = <&gpa2 4 GPIO_ACTIVE_HIGH>;
- cd-inverted;
- card-detect-delay = <200>;
- samsung,dw-mshc-ciu-div = <3>;
- samsung,dw-mshc-sdr-timing = <0 4>;
- samsung,dw-mshc-ddr-timing = <0 2>;
- fifo-depth = <0x80>;
- pinctrl-names = "default";
- pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus1 &sd2_bus4>;
- bus-width = <4>;
-};
-
-&ppmu_d0_general {
- status = "okay";
- events {
- ppmu_event0_d0_general: ppmu-event0-d0-general {
- event-name = "ppmu-event0-d0-general";
- };
- };
-};
-
-&ppmu_d1_general {
- status = "okay";
- events {
- ppmu_event0_d1_general: ppmu-event0-d1-general {
- event-name = "ppmu-event0-d1-general";
- };
- };
-};
-
-&pinctrl_alive {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_alive>;
-
- initial_alive: initial-state {
- PIN(INPUT, gpa0-0, DOWN, FAST_SR1);
- PIN(INPUT, gpa0-1, NONE, FAST_SR1);
- PIN(INPUT, gpa0-2, DOWN, FAST_SR1);
- PIN(INPUT, gpa0-3, NONE, FAST_SR1);
- PIN(INPUT, gpa0-4, NONE, FAST_SR1);
- PIN(INPUT, gpa0-5, DOWN, FAST_SR1);
- PIN(INPUT, gpa0-6, NONE, FAST_SR1);
- PIN(INPUT, gpa0-7, NONE, FAST_SR1);
-
- PIN(INPUT, gpa1-0, UP, FAST_SR1);
- PIN(INPUT, gpa1-1, NONE, FAST_SR1);
- PIN(INPUT, gpa1-2, NONE, FAST_SR1);
- PIN(INPUT, gpa1-3, DOWN, FAST_SR1);
- PIN(INPUT, gpa1-4, DOWN, FAST_SR1);
- PIN(INPUT, gpa1-5, NONE, FAST_SR1);
- PIN(INPUT, gpa1-6, NONE, FAST_SR1);
- PIN(INPUT, gpa1-7, NONE, FAST_SR1);
-
- PIN(INPUT, gpa2-0, NONE, FAST_SR1);
- PIN(INPUT, gpa2-1, NONE, FAST_SR1);
- PIN(INPUT, gpa2-2, NONE, FAST_SR1);
- PIN(INPUT, gpa2-3, DOWN, FAST_SR1);
- PIN(INPUT, gpa2-4, NONE, FAST_SR1);
- PIN(INPUT, gpa2-5, DOWN, FAST_SR1);
- PIN(INPUT, gpa2-6, DOWN, FAST_SR1);
- PIN(INPUT, gpa2-7, NONE, FAST_SR1);
-
- PIN(INPUT, gpa3-0, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-1, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-2, NONE, FAST_SR1);
- PIN(INPUT, gpa3-3, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-4, NONE, FAST_SR1);
- PIN(INPUT, gpa3-5, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-6, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-7, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf1-0, NONE, FAST_SR1);
- PIN(INPUT, gpf1-1, NONE, FAST_SR1);
- PIN(INPUT, gpf1-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf1-4, UP, FAST_SR1);
- PIN(OUTPUT, gpf1-5, NONE, FAST_SR1);
- PIN(INPUT, gpf1-6, DOWN, FAST_SR1);
- PIN(INPUT, gpf1-7, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf2-0, DOWN, FAST_SR1);
- PIN(INPUT, gpf2-1, DOWN, FAST_SR1);
- PIN(INPUT, gpf2-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf2-3, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf3-0, DOWN, FAST_SR1);
- PIN(INPUT, gpf3-1, DOWN, FAST_SR1);
- PIN(INPUT, gpf3-2, NONE, FAST_SR1);
- PIN(INPUT, gpf3-3, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf4-0, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-1, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-3, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-4, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-5, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-6, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-7, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf5-0, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-1, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-3, DOWN, FAST_SR1);
- PIN(OUTPUT, gpf5-4, NONE, FAST_SR1);
- PIN(INPUT, gpf5-5, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-6, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-7, DOWN, FAST_SR1);
- };
-
- te_irq: te_irq {
- samsung,pins = "gpf1-3";
- samsung,pin-function = <0xf>;
- };
-};
-
-&pinctrl_cpif {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_cpif>;
-
- initial_cpif: initial-state {
- PIN(INPUT, gpv6-0, DOWN, FAST_SR1);
- PIN(INPUT, gpv6-1, DOWN, FAST_SR1);
- };
-};
-
-&pinctrl_ese {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_ese>;
-
- initial_ese: initial-state {
- PIN(INPUT, gpj2-0, DOWN, FAST_SR1);
- PIN(INPUT, gpj2-1, DOWN, FAST_SR1);
- PIN(INPUT, gpj2-2, DOWN, FAST_SR1);
- };
-};
-
-&pinctrl_fsys {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_fsys>;
-
- initial_fsys: initial-state {
- PIN(INPUT, gpr3-0, NONE, FAST_SR1);
- PIN(INPUT, gpr3-1, DOWN, FAST_SR1);
- PIN(INPUT, gpr3-2, DOWN, FAST_SR1);
- PIN(INPUT, gpr3-3, DOWN, FAST_SR1);
- PIN(INPUT, gpr3-7, NONE, FAST_SR1);
- };
-};
-
-&pinctrl_imem {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_imem>;
-
- initial_imem: initial-state {
- PIN(INPUT, gpf0-0, UP, FAST_SR1);
- PIN(INPUT, gpf0-1, UP, FAST_SR1);
- PIN(INPUT, gpf0-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf0-3, UP, FAST_SR1);
- PIN(INPUT, gpf0-4, DOWN, FAST_SR1);
- PIN(INPUT, gpf0-5, NONE, FAST_SR1);
- PIN(INPUT, gpf0-6, DOWN, FAST_SR1);
- PIN(INPUT, gpf0-7, UP, FAST_SR1);
- };
-};
-
-&pinctrl_nfc {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_nfc>;
-
- initial_nfc: initial-state {
- PIN(INPUT, gpj0-2, DOWN, FAST_SR1);
- };
-};
-
-&pinctrl_peric {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_peric>;
-
- initial_peric: initial-state {
- PIN(INPUT, gpv7-0, DOWN, FAST_SR1);
- PIN(INPUT, gpv7-1, DOWN, FAST_SR1);
- PIN(INPUT, gpv7-2, NONE, FAST_SR1);
- PIN(INPUT, gpv7-3, DOWN, FAST_SR1);
- PIN(INPUT, gpv7-4, DOWN, FAST_SR1);
- PIN(INPUT, gpv7-5, DOWN, FAST_SR1);
-
- PIN(INPUT, gpb0-4, DOWN, FAST_SR1);
-
- PIN(INPUT, gpc0-2, DOWN, FAST_SR1);
- PIN(INPUT, gpc0-5, DOWN, FAST_SR1);
- PIN(INPUT, gpc0-7, DOWN, FAST_SR1);
-
- PIN(INPUT, gpc1-1, DOWN, FAST_SR1);
-
- PIN(INPUT, gpc3-4, NONE, FAST_SR1);
- PIN(INPUT, gpc3-5, NONE, FAST_SR1);
- PIN(INPUT, gpc3-6, NONE, FAST_SR1);
- PIN(INPUT, gpc3-7, NONE, FAST_SR1);
-
- PIN(OUTPUT, gpg0-0, NONE, FAST_SR1);
- PIN(2, gpg0-1, DOWN, FAST_SR1);
-
- PIN(INPUT, gpd2-5, DOWN, FAST_SR1);
-
- PIN(INPUT, gpd4-0, NONE, FAST_SR1);
- PIN(INPUT, gpd4-1, DOWN, FAST_SR1);
- PIN(INPUT, gpd4-2, DOWN, FAST_SR1);
- PIN(INPUT, gpd4-3, DOWN, FAST_SR1);
- PIN(INPUT, gpd4-4, DOWN, FAST_SR1);
-
- PIN(INPUT, gpd6-3, DOWN, FAST_SR1);
-
- PIN(INPUT, gpd8-1, UP, FAST_SR1);
-
- PIN(INPUT, gpg1-0, DOWN, FAST_SR1);
- PIN(INPUT, gpg1-1, DOWN, FAST_SR1);
- PIN(INPUT, gpg1-2, DOWN, FAST_SR1);
- PIN(INPUT, gpg1-3, DOWN, FAST_SR1);
- PIN(INPUT, gpg1-4, DOWN, FAST_SR1);
-
- PIN(INPUT, gpg2-0, DOWN, FAST_SR1);
- PIN(INPUT, gpg2-1, DOWN, FAST_SR1);
-
- PIN(INPUT, gpg3-0, DOWN, FAST_SR1);
- PIN(INPUT, gpg3-1, DOWN, FAST_SR1);
- PIN(INPUT, gpg3-5, DOWN, FAST_SR1);
- PIN(INPUT, gpg3-7, DOWN, FAST_SR1);
- };
-};
-
-&pinctrl_touch {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_touch>;
-
- initial_touch: initial-state {
- PIN(INPUT, gpj1-2, DOWN, FAST_SR1);
- };
-};
-
-&pwm {
- pinctrl-0 = <&pwm0_out>;
- pinctrl-names = "default";
- status = "okay";
-};
-
-&mic {
- status = "okay";
-
- i80-if-timings {
- };
-};
-
-&pmu_system_controller {
- assigned-clocks = <&pmu_system_controller 0>;
- assigned-clock-parents = <&xxti>;
-};
-
-&serial_1 {
- status = "okay";
-};
-
-&spi_1 {
- cs-gpios = <&gpd6 3 GPIO_ACTIVE_HIGH>;
- status = "okay";
-
- wm5110: wm5110-codec@0 {
- compatible = "wlf,wm5110";
- reg = <0x0>;
- spi-max-frequency = <20000000>;
- interrupt-parent = <&gpa0>;
- interrupts = <4 IRQ_TYPE_NONE>;
- clocks = <&pmu_system_controller 0>,
- <&s2mps13_osc S2MPS11_CLK_BT>;
- clock-names = "mclk1", "mclk2";
-
- gpio-controller;
- #gpio-cells = <2>;
-
- wlf,micd-detect-debounce = <300>;
- wlf,micd-bias-start-time = <0x1>;
- wlf,micd-rate = <0x7>;
- wlf,micd-dbtime = <0x1>;
- wlf,micd-force-micbias;
- wlf,micd-configs = <0x0 1 0>;
- wlf,hpdet-channel = <1>;
- wlf,gpsw = <0x1>;
- wlf,inmode = <2 0 2 0>;
-
- wlf,reset = <&gpc0 7 GPIO_ACTIVE_HIGH>;
- wlf,ldoena = <&gpf0 0 GPIO_ACTIVE_HIGH>;
-
- /* core supplies */
- AVDD-supply = <&ldo18_reg>;
- DBVDD1-supply = <&ldo18_reg>;
- CPVDD-supply = <&ldo18_reg>;
- DBVDD2-supply = <&ldo18_reg>;
- DBVDD3-supply = <&ldo18_reg>;
-
- controller-data {
- samsung,spi-feedback-delay = <0>;
- };
- };
-};
-
-&timer {
- clock-frequency = <24000000>;
-};
-
-&tmu_atlas0 {
- vtmu-supply = <&ldo3_reg>;
- status = "okay";
-};
-
-&tmu_apollo {
- vtmu-supply = <&ldo3_reg>;
- status = "okay";
-};
-
-&tmu_g3d {
- vtmu-supply = <&ldo3_reg>;
- status = "okay";
-};
-
-&usbdrd30 {
- vdd33-supply = <&ldo10_reg>;
- vdd10-supply = <&ldo6_reg>;
- status = "okay";
-};
-
-&usbdrd_dwc3_0 {
- dr_mode = "otg";
-};
-
-&usbdrd30_phy {
- vbus-supply = <&safeout1_reg>;
- status = "okay";
-};
-
-&xxti {
- clock-frequency = <24000000>;
-};
+/*
+ * SAMSUNG Exynos5433 TM2 board device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * Device tree source file for Samsung's TM2 board which is based on
+ * Samsung Exynos5433 SoC.
+ *
+ * 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 "exynos5433-tm2-common.dtsi"
+
+/ {
+ model = "Samsung TM2E board";
+ compatible = "samsung,tm2e", "samsung,exynos5433";
+};
+
+®ulators {
+ ldo31_reg: LDO31 {
+ regulator-name = "TSP_VDD_1.85V_AP";
+ regulator-min-microvolt = <1850000>;
+ regulator-max-microvolt = <1850000>;
+ };
+
+ ldo38_reg: LDO38 {
+ regulator-name = "VCC_3.0V_MOTOR_AP";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ };
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 854c583092d5..53e361f61ad5 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -11,21 +11,23 @@
* published by the Free Software Foundation.
*/
-#include "exynos5433-tm2.dts"
+#include "exynos5433-tm2-common.dtsi"
/ {
model = "Samsung TM2E board";
compatible = "samsung,tm2e", "samsung,exynos5433";
};
-&ldo31_reg {
- regulator-name = "TSP_VDD_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-};
+®ulators {
+ ldo31_reg: LDO31 {
+ regulator-name = "TSP_VDD_1.8V_AP";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
-&ldo38_reg {
- regulator-name = "VCC_3.3V_MOTOR_AP";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
+ ldo38_reg: LDO38 {
+ regulator-name = "VCC_3.3V_MOTOR_AP";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
};
--
2.11.0
^ permalink raw reply related
* [PATCH v4 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong values foe ldo23 and ldo25
From: Andi Shyti @ 2017-01-06 11:41 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Chanwoo Choi, Beomho Seo
Cc: devicetree, linux-samsung-soc, Jaechul Lee, linux-kernel,
Andi Shyti, Andi Shyti, linux-input, Jaechul Lee,
linux-arm-kernel
In-Reply-To: <20170106114114.19321-1-andi.shyti@samsung.com>
From: Chanwoo Choi <cw00.choi@samsung.com>
This patch fixes wrong values assigned to ldo23 and ldo25 on both TM2 and TM2E.
Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 7 ++++---
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 9 ---------
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 3b5215c40fcd..e8971f4a5977 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -504,9 +504,9 @@
};
ldo23_reg: LDO23 {
- regulator-name = "CAM_SEN_CORE_1.2V_AP";
+ regulator-name = "CAM_SEN_CORE_1.05V_AP";
regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1200000>;
+ regulator-max-microvolt = <1050000>;
};
ldo24_reg: LDO24 {
@@ -516,9 +516,10 @@
};
ldo25_reg: LDO25 {
- regulator-name = "CAM_SEN_A2.8V_AP";
+ regulator-name = "UNUSED_LDO25";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
+ regulator-always-off;
};
ldo26_reg: LDO26 {
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 398f5e092b02..854c583092d5 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -18,15 +18,6 @@
compatible = "samsung,tm2e", "samsung,exynos5433";
};
-&ldo23_reg {
- regulator-name = "CAM_SEN_CORE_1.025V_AP";
- regulator-max-microvolt = <1050000>;
-};
-
-&ldo25_reg {
- regulator-name = "UNUSED_LDO25";
-};
-
&ldo31_reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <1800000>;
--
2.11.0
^ permalink raw reply related
* [PATCH v4 0/5]
From: Andi Shyti @ 2017-01-06 11:41 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Chanwoo Choi, Beomho Seo
Cc: linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc, Jaechul Lee, Andi Shyti, Andi Shyti,
Jaechul Lee
In-Reply-To: <CGME20170106114119epcas5p2c29ea8c8118db4a1fb600970ea0dafd4@epcas5p2.samsung.com>
Hi,
I'll send this patch on behalf of Jaechul Lee
<jcsing.lee@samsung.com> becasue it's I don't want to block
anyone who wants to make changes to the exynos5433-tm2*dts*
files.
This patches are based on Krzysztof's branch for-next [1]
"This patchset adds support for the tm2 touchkey device.
The driver has been ported from Tizen Kernel,
originally written
by Beomho. I ported it to the latest mainline Kernel."
Thanks,
Andi
[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-next
Changes in v4:
- patch 1 has been rebased on top of 7c294e002641 (arm64: dts:
exynos: Remove unsupported regulator-always-off property from
TM2E)
- patch 2 has been generated with -B50% diff option using git
2.11
Changes in v3:
- Changed the commit ordering, the tm2-touchkey related patches
are the last 3.
- Added Chanwoo's patch which fixes the wrong voltage of ldo23
and ldo25.
- Andi (patch 3) moves the ldo31 and ldo38 in the tm2 and tm2e
files as they have different values.
Changes in v2:
- fixed reviews from Javier, Dmitry
- refactored power enable/disable functions.
- reordered signed-offs in patch 2, while patch 4 is left as it
was as Andi copy pasted the node to the new tm2.dts file
- added Jarvier's (patch 1,2,4) and Krzysztof's (patch 4)
reviews
and Rob's Ack
- patch 3 diff has been generated with -B50%
Andi Shyti (1):
arm64: dts: exynos: make tm2 and tm2e independent from each other
Chanwoo Choi (1):
arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and
ldo25
Jaechul Lee (3):
input: Add support for the tm2 touchkey device driver
input: tm2-touchkey: Add touchkey driver support for TM2
arm64: dts: exynos: Add tm2 touchkey node
.../bindings/input/samsung,tm2-touchkey.txt | 27 +
...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 31 +-
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1165 +-------------------
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 31 +-
drivers/input/keyboard/Kconfig | 11 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/tm2-touchkey.c | 280 +++++
7 files changed, 392 insertions(+), 1154 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (97%)
rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
create mode 100644 drivers/input/keyboard/tm2-touchkey.c
--
2.11.0
^ permalink raw reply
* Re: [RFC 0/1] Platform driver support for 'amd5536udc' driver
From: Arnd Bergmann @ 2017-01-06 11:20 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, BCM Kernel Feedback,
linux-usb-u79uwXL29TY76Z2rM5mHXA, John Youn
In-Reply-To: <CAEHZuqNK07Xku9SmFhV0DJ4apV0m8yWznuFDwjr33CDP_OcXew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Friday, January 6, 2017 12:29:12 PM CET Raviteja Garimella wrote:
> Hi Arnd,
>
> On Fri, Jan 6, 2017 at 3:33 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > On Thursday, January 5, 2017 1:53:16 PM CET Raviteja Garimella wrote:
> >> The UDC is based on Synopsys Designware core USB (2.0) Device controller
> >> IP.
> > ...
> >> This is a request for comments from maintainers/others regarding approach
> >> on whether to have 2 different drivers (one each for AMD and Broadcom)
> >> with a common library (3 files in total), or have a single driver like
> >> it's done in this patch and have the driver filename changed to some
> >> common name based on ther underlying IP, like snps_udc.c.
> >
> > I have not looked at the code at all, so sorry for my ignorance, but
> > isn't the IP block you describe the one that drivers/usb/dwc2/ is for?
> > Could you add support for the Broadcom hardware there instead?
>
> The current driver I submitted is for a different Synopsys IP (USB
> Device Controller IP,
> not the HS OTG). It's confirmed by John Youn (from Synopsys) earlier.
>
Ok, sounds fine the. I'd suggest taking the current driver than and
splitting out the pci_driver front-end into a separate module that
calls exported symbols of the main driver, with the new platform
driver in a third file that also calls the same exported symbols.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 1/2] PM / Domains: Introduce domain-performance-states binding
From: Viresh Kumar @ 2017-01-06 11:09 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Rafael Wysocki, linaro-kernel, linux-pm, linux-kernel,
Stephen Boyd, Nishanth Menon, Vincent Guittot, Rob Herring,
Mark Rutland, Kevin Hilman, Ulf Hansson, Lina Iyer, devicetree
In-Reply-To: <586F732A.8090401@codeaurora.org>
On 06-01-17, 16:06, Rajendra Nayak wrote:
> No, I am thoroughly confused :)
> I was struggling with 2 powerdomains and now there are way too many of them :P
For the record, we had some offline chat and his case is pretty much
taken care of by the proposed bindings. Though he will look in more
details and post further queries later. :)
--
viresh
^ permalink raw reply
* [PATCH v3 4/4] hwmon: adc128d818: Preserve operation mode
From: Alexander Koch @ 2017-01-06 10:38 UTC (permalink / raw)
To: linux-kernel, linux-hwmon
Cc: Rob Herring, Mark Rutland, Jean Delvare, Guenter Roeck,
Michael Hornung, devicetree, Alexander Koch
In-Reply-To: <20170106103817.11588-1-mail@alexanderkoch.net>
Preserve chip operation mode if no mode is specified via devicetree. This
enables operation when chip configuration is done by BIOS/ROMMON.
Signed-off-by: Alexander Koch <mail@alexanderkoch.net>
Acked-by: Michael Hornung <mhornung.linux@gmail.com>
---
drivers/hwmon/adc128d818.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/adc128d818.c b/drivers/hwmon/adc128d818.c
index 0502af963f73..bbe3a5c5b3f5 100644
--- a/drivers/hwmon/adc128d818.c
+++ b/drivers/hwmon/adc128d818.c
@@ -491,7 +491,7 @@ static int adc128_probe(struct i2c_client *client,
data->vref = 2560; /* 2.56V, in mV */
}
- /* Operation mode is optional and defaults to mode 0 */
+ /* Operation mode is optional. If unspecified, keep current mode */
if (of_property_read_u8(dev->of_node, "ti,mode", &data->mode) == 0) {
if (data->mode > 3) {
dev_err(dev, "invalid operation mode %d\n",
@@ -500,7 +500,10 @@ static int adc128_probe(struct i2c_client *client,
goto error;
}
} else {
- data->mode = 0;
+ err = i2c_smbus_read_byte_data(client, ADC128_REG_CONFIG_ADV);
+ if (err < 0)
+ goto error;
+ data->mode = (err >> 1) & ADC128_REG_MASK;
}
data->client = client;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/4] hwmon: adc128d818: Support operation modes 1-3
From: Alexander Koch @ 2017-01-06 10:38 UTC (permalink / raw)
To: linux-kernel, linux-hwmon
Cc: Rob Herring, Mark Rutland, Jean Delvare, Guenter Roeck,
Michael Hornung, devicetree, Alexander Koch
In-Reply-To: <20170106103817.11588-1-mail@alexanderkoch.net>
Add support for operation modes 1-3 of the ADC128D818 (see datasheet sec.
8.4.1). These differ in the number and type of the available input signals,
requiring the driver to selectively hide sysfs nodes according to the
operation mode configured via devicetree.
Signed-off-by: Alexander Koch <mail@alexanderkoch.net>
Acked-by: Michael Hornung <mhornung.linux@gmail.com>
---
drivers/hwmon/adc128d818.c | 126 +++++++++++++++++++++++++++++++--------------
1 file changed, 86 insertions(+), 40 deletions(-)
diff --git a/drivers/hwmon/adc128d818.c b/drivers/hwmon/adc128d818.c
index 2b61936c32ff..0502af963f73 100644
--- a/drivers/hwmon/adc128d818.c
+++ b/drivers/hwmon/adc128d818.c
@@ -59,6 +59,12 @@ static const unsigned short normal_i2c[] = {
#define ADC128_REG_MAN_ID 0x3e
#define ADC128_REG_DEV_ID 0x3f
+/* No. of voltage entries in adc128_attrs */
+#define ADC128_ATTR_NUM_VOLT (8 * 4)
+
+/* Voltage inputs visible per operation mode */
+static const u8 num_inputs[] = { 7, 8, 4, 6 };
+
struct adc128_data {
struct i2c_client *client;
struct regulator *regulator;
@@ -68,7 +74,7 @@ struct adc128_data {
bool valid; /* true if following fields are valid */
unsigned long last_updated; /* In jiffies */
- u16 in[3][7]; /* Register value, normalized to 12 bit
+ u16 in[3][8]; /* Register value, normalized to 12 bit
* 0: input voltage
* 1: min limit
* 2: max limit
@@ -89,7 +95,7 @@ static struct adc128_data *adc128_update_device(struct device *dev)
mutex_lock(&data->update_lock);
if (time_after(jiffies, data->last_updated + HZ) || !data->valid) {
- for (i = 0; i < 7; i++) {
+ for (i = 0; i < num_inputs[data->mode]; i++) {
rv = i2c_smbus_read_word_swapped(client,
ADC128_REG_IN(i));
if (rv < 0)
@@ -109,20 +115,25 @@ static struct adc128_data *adc128_update_device(struct device *dev)
data->in[2][i] = rv << 4;
}
- rv = i2c_smbus_read_word_swapped(client, ADC128_REG_TEMP);
- if (rv < 0)
- goto abort;
- data->temp[0] = rv >> 7;
+ if (data->mode != 1) {
+ rv = i2c_smbus_read_word_swapped(client,
+ ADC128_REG_TEMP);
+ if (rv < 0)
+ goto abort;
+ data->temp[0] = rv >> 7;
- rv = i2c_smbus_read_byte_data(client, ADC128_REG_TEMP_MAX);
- if (rv < 0)
- goto abort;
- data->temp[1] = rv << 1;
+ rv = i2c_smbus_read_byte_data(client,
+ ADC128_REG_TEMP_MAX);
+ if (rv < 0)
+ goto abort;
+ data->temp[1] = rv << 1;
- rv = i2c_smbus_read_byte_data(client, ADC128_REG_TEMP_HYST);
- if (rv < 0)
- goto abort;
- data->temp[2] = rv << 1;
+ rv = i2c_smbus_read_byte_data(client,
+ ADC128_REG_TEMP_HYST);
+ if (rv < 0)
+ goto abort;
+ data->temp[2] = rv << 1;
+ }
rv = i2c_smbus_read_byte_data(client, ADC128_REG_ALARM);
if (rv < 0)
@@ -242,6 +253,25 @@ static ssize_t adc128_show_alarm(struct device *dev,
return sprintf(buf, "%u\n", !!(alarms & mask));
}
+static umode_t adc128_is_visible(struct kobject *kobj,
+ struct attribute *attr, int index)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct adc128_data *data = dev_get_drvdata(dev);
+
+ if (index < ADC128_ATTR_NUM_VOLT) {
+ /* Voltage, visible according to num_inputs[] */
+ if (index >= num_inputs[data->mode] * 4)
+ return 0;
+ } else {
+ /* Temperature, visible if not in mode 1 */
+ if (data->mode == 1)
+ return 0;
+ }
+
+ return attr->mode;
+}
+
static SENSOR_DEVICE_ATTR_2(in0_input, S_IRUGO,
adc128_show_in, NULL, 0, 0);
static SENSOR_DEVICE_ATTR_2(in0_min, S_IWUSR | S_IRUGO,
@@ -291,6 +321,13 @@ static SENSOR_DEVICE_ATTR_2(in6_min, S_IWUSR | S_IRUGO,
static SENSOR_DEVICE_ATTR_2(in6_max, S_IWUSR | S_IRUGO,
adc128_show_in, adc128_set_in, 6, 2);
+static SENSOR_DEVICE_ATTR_2(in7_input, S_IRUGO,
+ adc128_show_in, NULL, 7, 0);
+static SENSOR_DEVICE_ATTR_2(in7_min, S_IWUSR | S_IRUGO,
+ adc128_show_in, adc128_set_in, 7, 1);
+static SENSOR_DEVICE_ATTR_2(in7_max, S_IWUSR | S_IRUGO,
+ adc128_show_in, adc128_set_in, 7, 2);
+
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, adc128_show_temp, NULL, 0);
static SENSOR_DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO,
adc128_show_temp, adc128_set_temp, 1);
@@ -304,44 +341,54 @@ static SENSOR_DEVICE_ATTR(in3_alarm, S_IRUGO, adc128_show_alarm, NULL, 3);
static SENSOR_DEVICE_ATTR(in4_alarm, S_IRUGO, adc128_show_alarm, NULL, 4);
static SENSOR_DEVICE_ATTR(in5_alarm, S_IRUGO, adc128_show_alarm, NULL, 5);
static SENSOR_DEVICE_ATTR(in6_alarm, S_IRUGO, adc128_show_alarm, NULL, 6);
+static SENSOR_DEVICE_ATTR(in7_alarm, S_IRUGO, adc128_show_alarm, NULL, 7);
static SENSOR_DEVICE_ATTR(temp1_max_alarm, S_IRUGO, adc128_show_alarm, NULL, 7);
static struct attribute *adc128_attrs[] = {
- &sensor_dev_attr_in0_min.dev_attr.attr,
- &sensor_dev_attr_in1_min.dev_attr.attr,
- &sensor_dev_attr_in2_min.dev_attr.attr,
- &sensor_dev_attr_in3_min.dev_attr.attr,
- &sensor_dev_attr_in4_min.dev_attr.attr,
- &sensor_dev_attr_in5_min.dev_attr.attr,
- &sensor_dev_attr_in6_min.dev_attr.attr,
- &sensor_dev_attr_in0_max.dev_attr.attr,
- &sensor_dev_attr_in1_max.dev_attr.attr,
- &sensor_dev_attr_in2_max.dev_attr.attr,
- &sensor_dev_attr_in3_max.dev_attr.attr,
- &sensor_dev_attr_in4_max.dev_attr.attr,
- &sensor_dev_attr_in5_max.dev_attr.attr,
- &sensor_dev_attr_in6_max.dev_attr.attr,
+ &sensor_dev_attr_in0_alarm.dev_attr.attr,
&sensor_dev_attr_in0_input.dev_attr.attr,
+ &sensor_dev_attr_in0_max.dev_attr.attr,
+ &sensor_dev_attr_in0_min.dev_attr.attr,
+ &sensor_dev_attr_in1_alarm.dev_attr.attr,
&sensor_dev_attr_in1_input.dev_attr.attr,
+ &sensor_dev_attr_in1_max.dev_attr.attr,
+ &sensor_dev_attr_in1_min.dev_attr.attr,
+ &sensor_dev_attr_in2_alarm.dev_attr.attr,
&sensor_dev_attr_in2_input.dev_attr.attr,
+ &sensor_dev_attr_in2_max.dev_attr.attr,
+ &sensor_dev_attr_in2_min.dev_attr.attr,
+ &sensor_dev_attr_in3_alarm.dev_attr.attr,
&sensor_dev_attr_in3_input.dev_attr.attr,
+ &sensor_dev_attr_in3_max.dev_attr.attr,
+ &sensor_dev_attr_in3_min.dev_attr.attr,
+ &sensor_dev_attr_in4_alarm.dev_attr.attr,
&sensor_dev_attr_in4_input.dev_attr.attr,
+ &sensor_dev_attr_in4_max.dev_attr.attr,
+ &sensor_dev_attr_in4_min.dev_attr.attr,
+ &sensor_dev_attr_in5_alarm.dev_attr.attr,
&sensor_dev_attr_in5_input.dev_attr.attr,
+ &sensor_dev_attr_in5_max.dev_attr.attr,
+ &sensor_dev_attr_in5_min.dev_attr.attr,
+ &sensor_dev_attr_in6_alarm.dev_attr.attr,
&sensor_dev_attr_in6_input.dev_attr.attr,
+ &sensor_dev_attr_in6_max.dev_attr.attr,
+ &sensor_dev_attr_in6_min.dev_attr.attr,
+ &sensor_dev_attr_in7_alarm.dev_attr.attr,
+ &sensor_dev_attr_in7_input.dev_attr.attr,
+ &sensor_dev_attr_in7_max.dev_attr.attr,
+ &sensor_dev_attr_in7_min.dev_attr.attr,
&sensor_dev_attr_temp1_input.dev_attr.attr,
&sensor_dev_attr_temp1_max.dev_attr.attr,
- &sensor_dev_attr_temp1_max_hyst.dev_attr.attr,
- &sensor_dev_attr_in0_alarm.dev_attr.attr,
- &sensor_dev_attr_in1_alarm.dev_attr.attr,
- &sensor_dev_attr_in2_alarm.dev_attr.attr,
- &sensor_dev_attr_in3_alarm.dev_attr.attr,
- &sensor_dev_attr_in4_alarm.dev_attr.attr,
- &sensor_dev_attr_in5_alarm.dev_attr.attr,
- &sensor_dev_attr_in6_alarm.dev_attr.attr,
&sensor_dev_attr_temp1_max_alarm.dev_attr.attr,
+ &sensor_dev_attr_temp1_max_hyst.dev_attr.attr,
NULL
};
-ATTRIBUTE_GROUPS(adc128);
+
+static struct attribute_group adc128_group = {
+ .attrs = adc128_attrs,
+ .is_visible = adc128_is_visible,
+};
+__ATTRIBUTE_GROUPS(adc128);
static int adc128_detect(struct i2c_client *client, struct i2c_board_info *info)
{
@@ -446,9 +493,8 @@ static int adc128_probe(struct i2c_client *client,
/* Operation mode is optional and defaults to mode 0 */
if (of_property_read_u8(dev->of_node, "ti,mode", &data->mode) == 0) {
- /* Currently only mode 0 supported */
- if (data->mode != 0) {
- dev_err(dev, "unsupported operation mode %d\n",
+ if (data->mode > 3) {
+ dev_err(dev, "invalid operation mode %d\n",
data->mode);
err = -EINVAL;
goto error;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 2/4] hwmon: adc128d818: Implement mode selection via dt
From: Alexander Koch @ 2017-01-06 10:38 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Mark Rutland, Jean Delvare, Guenter Roeck,
Michael Hornung, devicetree-u79uwXL29TY76Z2rM5mHXA,
Alexander Koch
In-Reply-To: <20170106103817.11588-1-mail-y2PnNNZjvYd4VEKF+Mn3m16hYfS7NtTn@public.gmane.org>
Implement operation mode selection using the optional 'ti,mode' devicetree
property (see [1]). The ADC128D818 supports four operation modes differing
in the number and type of input readings (see datasheet, sec. 8.4.1), of
which mode 0 is the default.
We only add handling of the 'ti,mode' property here, the driver still
supports nothing else than the default mode 0.
[1] Documentation/devicetree/bindings/hwmon/adc128d818.txt
Signed-off-by: Alexander Koch <mail-y2PnNNZjvYd4VEKF+Mn3m16hYfS7NtTn@public.gmane.org>
Acked-by: Michael Hornung <mhornung.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/hwmon/adc128d818.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/hwmon/adc128d818.c b/drivers/hwmon/adc128d818.c
index ad2b47e40345..2b61936c32ff 100644
--- a/drivers/hwmon/adc128d818.c
+++ b/drivers/hwmon/adc128d818.c
@@ -28,6 +28,7 @@
#include <linux/regulator/consumer.h>
#include <linux/mutex.h>
#include <linux/bitops.h>
+#include <linux/of.h>
/* Addresses to scan
* The chip also supports addresses 0x35..0x37. Don't scan those addresses
@@ -63,6 +64,7 @@ struct adc128_data {
struct regulator *regulator;
int vref; /* Reference voltage in mV */
struct mutex update_lock;
+ u8 mode; /* Operation mode */
bool valid; /* true if following fields are valid */
unsigned long last_updated; /* In jiffies */
@@ -387,6 +389,15 @@ static int adc128_init_client(struct adc128_data *data)
if (err)
return err;
+ /* Set operation mode, if non-default */
+ if (data->mode != 0) {
+ err = i2c_smbus_write_byte_data(client,
+ ADC128_REG_CONFIG_ADV,
+ data->mode << 1);
+ if (err)
+ return err;
+ }
+
/* Start monitoring */
err = i2c_smbus_write_byte_data(client, ADC128_REG_CONFIG, 0x01);
if (err)
@@ -433,6 +444,19 @@ static int adc128_probe(struct i2c_client *client,
data->vref = 2560; /* 2.56V, in mV */
}
+ /* Operation mode is optional and defaults to mode 0 */
+ if (of_property_read_u8(dev->of_node, "ti,mode", &data->mode) == 0) {
+ /* Currently only mode 0 supported */
+ if (data->mode != 0) {
+ dev_err(dev, "unsupported operation mode %d\n",
+ data->mode);
+ err = -EINVAL;
+ goto error;
+ }
+ } else {
+ data->mode = 0;
+ }
+
data->client = client;
i2c_set_clientdata(client, data);
mutex_init(&data->update_lock);
--
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
* [PATCH v3 1/4] devicetree: hwmon: Add bindings for ADC128D818
From: Alexander Koch @ 2017-01-06 10:38 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Mark Rutland, Jean Delvare, Guenter Roeck,
Michael Hornung, devicetree-u79uwXL29TY76Z2rM5mHXA,
Alexander Koch
In-Reply-To: <20170106103817.11588-1-mail-y2PnNNZjvYd4VEKF+Mn3m16hYfS7NtTn@public.gmane.org>
Add bindings documentation for the ADC128D818 driver, featuring default I2C
properties along with the optional 'mode' property for chip operation mode
selection (see datasheet, sec. 8.4.1).
Signed-off-by: Alexander Koch <mail-y2PnNNZjvYd4VEKF+Mn3m16hYfS7NtTn@public.gmane.org>
Acked-by: Michael Hornung <mhornung.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
.../devicetree/bindings/hwmon/adc128d818.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/adc128d818.txt
diff --git a/Documentation/devicetree/bindings/hwmon/adc128d818.txt b/Documentation/devicetree/bindings/hwmon/adc128d818.txt
new file mode 100644
index 000000000000..db213dcc1391
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/adc128d818.txt
@@ -0,0 +1,39 @@
+TI ADC128D818 ADC System Monitor With Temperature Sensor
+--------------------------------------------------------
+
+Operation modes:
+
+ - Mode 0: 7 single-ended voltage readings (IN0-IN6),
+ 1 temperature reading (internal)
+ - Mode 1: 8 single-ended voltage readings (IN0-IN7),
+ no temperature
+ - Mode 2: 4 pseudo-differential voltage readings
+ (IN0-IN1, IN3-IN2, IN4-IN5, IN7-IN6),
+ 1 temperature reading (internal)
+ - Mode 3: 4 single-ended voltage readings (IN0-IN3),
+ 2 pseudo-differential voltage readings
+ (IN4-IN5, IN7-IN6),
+ 1 temperature reading (internal)
+
+If no operation mode is configured via device tree, the driver keeps the
+currently active chip operation mode (default is mode 0).
+
+
+Required node properties:
+
+ - compatible: must be set to "ti,adc128d818"
+ - reg: I2C address of the device
+
+Optional node properties:
+
+ - ti,mode: Operation mode (see above).
+
+
+Example (operation mode 2):
+
+ adc128d818@1d {
+ compatible = "ti,adc128d818";
+ reg = <0x1d>;
+ ti,mode = <2>;
+ };
+
--
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
* [PATCH v3 0/4] hwmon: adc128d818: Support missing operation modes
From: Alexander Koch @ 2017-01-06 10:38 UTC (permalink / raw)
To: linux-kernel, linux-hwmon
Cc: Rob Herring, Mark Rutland, Jean Delvare, Guenter Roeck,
Michael Hornung, devicetree, Alexander Koch
The ADC128D818 offers four different chip operation modes which vary in the
number and measurement types of the available input signals (see datasheet
sec. 8.4.1).
The current version of the driver only supports the default chip operation
mode (mode 0), providing seven analog values and a temperature reading.
This patch series adds support for operation modes 1-3, selectable through
the device tree attribute 'ti,mode':
adc1: adc128d818@1d {
compatible = "ti,adc128d818";
reg = <0x1d>;
mode = <1>;
};
The changes are transparent as the driver defaults to keeping the currently
active operation mode if no mode is specified via device tree (which is
mode 0 on chip initialization).
Changes from v2:
- Omit device attribute refactoring (for checkpatch.pl), as requested by
maintainer
- Add vendor prefix 'ti,' for mode property in device tree
- Drop size indication for mode property in device tree
- Preserve chip operation mode if none specified in devicetree
- Fix missing '\n' in dev_err() calls
Changes from v1:
- Add bindings document as first patch
- Preserve logical atomicity of code changes
- Improve sysfs device node handling (use is_visible() instead of
duplicate attribute list)
- Add trivial code refactoring stage for checkpatch.pl to succeed
Alexander Koch (4):
devicetree: hwmon: Add bindings for ADC128D818
hwmon: adc128d818: Implement mode selection via dt
hwmon: adc128d818: Support operation modes 1-3
hwmon: adc128d818: Preserve operation mode
.../devicetree/bindings/hwmon/adc128d818.txt | 39 ++++++
drivers/hwmon/adc128d818.c | 147 +++++++++++++++------
2 files changed, 149 insertions(+), 37 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwmon/adc128d818.txt
--
2.11.0
^ permalink raw reply
* Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding
From: Rajendra Nayak @ 2017-01-06 10:36 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, linaro-kernel, linux-pm, linux-kernel,
Stephen Boyd, Nishanth Menon, Vincent Guittot, Rob Herring,
Mark Rutland, Kevin Hilman, Ulf Hansson, Lina Iyer, devicetree
In-Reply-To: <20170106102308.GI21926@vireshk-i7>
On 01/06/2017 03:53 PM, Viresh Kumar wrote:
> On 06-01-17, 15:42, Rajendra Nayak wrote:
>> I read through that discussion, and I thought that was to do we
>> handling multiple powerdomains with performance states
>> (or in other words multiple voltage rails controlled by the M3)
>
> I thought about it as multiple power domains available for a device,
> and the device will be in a single domain out of those at a time. So
> perhaps it is about the problem you mentioned.
>
>> What I was pointing to, was that devices quite often (again on qcom
>> platforms) have a power-switch (gdscs as we call it) which are modeled
>> as powerdomains (which have nothing to do with taking to the M3 core),
>> and with the proposed bindings one or more voltage rails controlled by the M3
>> also as powerdomains associated with a device and the bindings have just one
>> power-domains property in the device node, which runtime PM would use
>> to power_on/off the device and OPP core would use to set the performance
>> state?
>>
>> + leaky-device@12350000 {
>> + compatible = "foo,i-leak-current";
>> + reg = <0x12350000 0x1000>;
>> + power-domains = <&power 0>;
>> + domain-performance-state = <&domain_perf_state2>;
>> + };
>>
>> Lets say leaky-device needs to switch on/off a gdsc and also send a
>> value to M3 to set a minimum performance state (so M3 configures the
>> voltage rails accordingly) how would it work?
>
> So the way I proposed this earlier is that every device will have a
> single power domain for it. In your case that power domain will
> represent gdscs. Idle state and performance state request will go to
> that level and then its up to the gdscs domain specific code to choose
> the right domain and its performance state. The parent domain shall
> then pass on the performance state to the next level power domain
> controlled by the M3 core.
>
> For example a device can have I power domain for idle state management
> and A power domain for active state management. The device will also
> have a M power domain which represents the gdscs. M can choose I or A
> as its parent. The power domain A (and similar power domains for all
> other devices) will have a parent power domain P. Now P is controlled
> or configured via the M3. Will that make sense ?
No, I am thoroughly confused :)
I was struggling with 2 powerdomains and now there are way too many of them :P
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Boris Brezillon @ 2017-01-06 10:23 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Mark Rutland, devicetree, Richard Weinberger, Marek Vasut,
Rob Herring, linux-mtd, Joel Stanley, Cyrille Pitchen,
Cyrille Pitchen, Brian Norris, David Woodhouse
In-Reply-To: <5017c983-e619-b3db-404c-8eab45bdd1f8@kaod.org>
On Fri, 6 Jan 2017 11:04:12 +0100
Cédric Le Goater <clg@kaod.org> wrote:
> Hello Boris,
>
> On 01/06/2017 09:49 AM, Boris Brezillon wrote:
> > Hi Cédric,
> >
> > On Thu, 5 Jan 2017 14:39:14 +0100
> > Cédric Le Goater <clg@kaod.org> wrote:
> >
> >> Hello Cyrille, Boris
> >>
> >> On 01/04/2017 06:50 PM, Boris Brezillon wrote:
> >>> Cyrille, Cédric,
> >>>
> >>> On Wed, 4 Jan 2017 15:52:07 +0100
> >>> Cyrille Pitchen <cyrille.pitchen@atmel.com> wrote:
> >>>
> >>>>>
> >>>>>> Anyway, since the review is done now, on my side I won't ask you to remove
> >>>>>> or split the support of the 'Command' mode in a separated patch.
> >>>>>> I let you do as you want, if it help you to introduce some part of the
> >>>>>> support of this 'Command' mode now even if not completed yet, no problem on
> >>>>>> my side :)
> >>>>>>
> >>>>>> I was just giving you some pieces of advice for the next time if you want
> >>>>>> to speed up the review of another patch introducing new features.
> >>>>>>
> >>>>>> However, I will just ask you one more version handling the dummy cycles
> >>>>>> properly as it would help us for the global maintenance of the spi-nor
> >>>>>> subsystem. This is the only mandatory modification I ask you, after that I
> >>>>>> think it would be ok for me and since Marek has already reviewed your
> >>>>>> driver, it would be ready to be merged into the spi-nor tree.
> >>>>>
> >>>>> Sending a v5 which should address your comments.
> >>>>>
> >>>>> I have removed the label property and will start a new thread in the
> >>>>> topic. Any hints on which binding we could add this label prop ?
> >>>>>
> >>>>
> >>>> Here I will provide just few thoughts about this new DT property. I don't
> >>>> pretend this is what should be done. I still think other mtd maintainers
> >>>> should be involved to discuss this topic.
> >>>>
> >>>> First the DT property name "label" sounds good to me: it is consistent with
> >>>> "label" DT property used to name mtd partitions. However, I don't think it
> >>>> should be documented in jedec,spi-nor.txt but *maybe* in partition.txt as
> >>>> the purpose of this new DT property seems very close to the "label"
> >>>> property of partition nodes: let's think about some hard-disk device
> >>>> (/dev/sda) and its partition devices (/dev/sdaX).
> >>
> >> yes this is very similar. I first looked at introducing a name to
> >> an overall containing partition but the partition binding is not
> >> designed for that. There are constraints on the start address and
> >> the size which does not fit the purpose.
> >>
> >>> Hm, partition.txt may not be appropriate here. We're not documenting
> >>> the MTD partition binding, but the MTD device one. Maybe we should
> >>> create mtd.txt and put all generic MTD dev properties here.
> >>>>
> >>>> Besides, the concept of this memory label is not limited to SPI NOR but
> >>>> could also apply to NAND memories or any other MTD handled memories.
> >>>
> >>> Definitely. Actually I think I'll need that for the Atmel NAND
> >>> controller driver rework I'm currently working on, to keep mtdparts
> >>> parser happy even after changing the NAND device naming scheme.
> >>>
> >>>> Hence the DT property might be handled by drivers/mtd/ofpart.c instead of
> >>>> being handled by spi-nor.c or by each SPI NOR memory controller driver.
> >>>
> >>> Actually, that could be done at the mtdcore level in
> >>> mtd_set_dev_defaults() [1].
> >>
> >> that would be perfect.
> >>
> >>>> Finally, I guess we should take time to discuss and all agree what should
> >>>> be done precisely before introducing a new DT property because one general
> >>>> rule with DTB files is that users should be able to update their kernel
> >>>> image (zImage, uImage, ...) without changing their DTB: device trees should
> >>>> be backward compatible. Hence if we make a wrong choice today, we are
> >>>> likely to have to live with it and keep supporting that bad choice.
> >>>
> >>> Rob already acked the patch, so, if all MTD maintainers agree that this
> >>> new property is acceptable, we should be fine ;-).
> >>
> >> yes but we would need to move the binding property to another file.
> >> What I sent applied to "jedec,spi-nor" and we want to generalize the
> >> property to other devices.
> >
> > We could create an new file under
> > Documentation/devicetree/bindings/mtd/, or we could rename
> > partition.txt into something else (generic.txt or common.txt) and
> > document more than the partition binding.
>
> OK.
>
> I guess that creating a new file for a single property is a little
> overkill or do we expect more common properties at the device level ?
Not that I can think of, but we never know.
> In that case, may be we could keep the partition.txt file and add
> a common.txt file. If not, common.txt seems to be a good name.
> Waiting a little for others to chime in.
>
>
> > Can you take care of that (in a separate patch series of course)?
>
> sure, and will you send :
>
> http://code.bulix.org/p019ah-107877
>
> in a separate patch ?
No, you should make it part of your series ;-).
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding
From: Viresh Kumar @ 2017-01-06 10:23 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Rafael Wysocki, linaro-kernel, linux-pm, linux-kernel,
Stephen Boyd, Nishanth Menon, Vincent Guittot, Rob Herring,
Mark Rutland, Kevin Hilman, Ulf Hansson, Lina Iyer, devicetree
In-Reply-To: <586F6DA5.30203@codeaurora.org>
On 06-01-17, 15:42, Rajendra Nayak wrote:
> I read through that discussion, and I thought that was to do we
> handling multiple powerdomains with performance states
> (or in other words multiple voltage rails controlled by the M3)
I thought about it as multiple power domains available for a device,
and the device will be in a single domain out of those at a time. So
perhaps it is about the problem you mentioned.
> What I was pointing to, was that devices quite often (again on qcom
> platforms) have a power-switch (gdscs as we call it) which are modeled
> as powerdomains (which have nothing to do with taking to the M3 core),
> and with the proposed bindings one or more voltage rails controlled by the M3
> also as powerdomains associated with a device and the bindings have just one
> power-domains property in the device node, which runtime PM would use
> to power_on/off the device and OPP core would use to set the performance
> state?
>
> + leaky-device@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&power 0>;
> + domain-performance-state = <&domain_perf_state2>;
> + };
>
> Lets say leaky-device needs to switch on/off a gdsc and also send a
> value to M3 to set a minimum performance state (so M3 configures the
> voltage rails accordingly) how would it work?
So the way I proposed this earlier is that every device will have a
single power domain for it. In your case that power domain will
represent gdscs. Idle state and performance state request will go to
that level and then its up to the gdscs domain specific code to choose
the right domain and its performance state. The parent domain shall
then pass on the performance state to the next level power domain
controlled by the M3 core.
For example a device can have I power domain for idle state management
and A power domain for active state management. The device will also
have a M power domain which represents the gdscs. M can choose I or A
as its parent. The power domain A (and similar power domains for all
other devices) will have a parent power domain P. Now P is controlled
or configured via the M3. Will that make sense ?
--
viresh
^ permalink raw reply
* Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding
From: Rajendra Nayak @ 2017-01-06 10:12 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, linaro-kernel, linux-pm, linux-kernel,
Stephen Boyd, Nishanth Menon, Vincent Guittot, Rob Herring,
Mark Rutland, Kevin Hilman, Ulf Hansson, Lina Iyer, devicetree
In-Reply-To: <20170106092702.GH21926@vireshk-i7>
On 01/06/2017 02:57 PM, Viresh Kumar wrote:
> On 06-01-17, 14:16, Rajendra Nayak wrote:
>>
>> On 12/12/2016 04:26 PM, Viresh Kumar wrote:
>>> Some platforms have the capability to configure the performance state of
>>> their Power Domains. The performance levels are represented by positive
>>> integer values, a lower value represents lower performance state.
>>>
>>> The power-domains until now were only concentrating on the idle state
>>> management of the device and this needs to change in order to reuse the
>>> infrastructure of power domains for active state management.
>>>
>>> This patch adds binding to describe the performance states of a power
>>> domain.
>>
>> The bindings would also need to take into account the fact that a device
>> could (and is quite often the case with qcom platforms) have 2 separate
>> powerdomains, one for idle state management and another to manage active
>> states. I guess the below bindings assume that there's just one.
>
> I have answered a similar question here..
>
> https://marc.info/?l=linux-kernel&m=148067565219477&w=2
I read through that discussion, and I thought that was to do we
handling multiple powerdomains with performance states
(or in other words multiple voltage rails controlled by the M3)
What I was pointing to, was that devices quite often (again on qcom
platforms) have a power-switch (gdscs as we call it) which are modeled
as powerdomains (which have nothing to do with taking to the M3 core),
and with the proposed bindings one or more voltage rails controlled by the M3
also as powerdomains associated with a device and the bindings have just one
power-domains property in the device node, which runtime PM would use
to power_on/off the device and OPP core would use to set the performance
state?
+ leaky-device@12350000 {
+ compatible = "foo,i-leak-current";
+ reg = <0x12350000 0x1000>;
+ power-domains = <&power 0>;
+ domain-performance-state = <&domain_perf_state2>;
+ };
Lets say leaky-device needs to switch on/off a gdsc and also send a
value to M3 to set a minimum performance state (so M3 configures the
voltage rails accordingly) how would it work?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Jerome Brunet @ 2017-01-06 10:11 UTC (permalink / raw)
To: Russell King - ARM Linux, Florian Fainelli
Cc: Andrew Lunn, Alexandre TORGUE, Neil Armstrong,
Martin Blumenstingl, netdev, Giuseppe Cavallaro, linux-kernel,
Yegor Yefremov, Julia Lawall, devicetree, Andre Roth,
Kevin Hilman, Carlo Caione, linux-amlogic, Andreas Färber,
linux-arm-kernel
In-Reply-To: <20170105232508.GU14217@n2100.armlinux.org.uk>
On Thu, 2017-01-05 at 23:25 +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 28, 2016 at 09:54:28AM -0800, Florian Fainelli wrote:
> >
> > If we start supporting generic "enable", "disable" type of
> > properties
> > with values that map directly to register definitions of the HW, we
> > leave too much room for these properties to be utilized to
> > implement a
> > specific policy, and this is not acceptable.
>
> Another concern with this patch is that the existing phylib "set_eee"
> code is horribly buggy - it just translates the modes from userspace
> into the register value and writes them directly to the register with
> no validation. So it's possible to set modes in the register that
> the
> hardware doesn't support, and have them advertised to the link
> partner.
Hi Russell,
The purpose of this patch is to provide a way to mark as broken a
particular eee mode. At first, it had nothing to do with "set_eee" but,
as Florian rightly pointed out, users shouldn't be able to re-enable a
broken mode.
At first, I was thinking about returning -ENOSUP if a broken mode was
requested. Then I noticed the behavior you just described: A user can
request anything of "set_eee", he won't necessarily get what he asked
but won't get an error either.
To avoid mixing different topic in a single patch, I kept the same
behavior, not returning an error, just silently discarding broken modes
I agree with you, we should probably validate a bit more what we asked
of the hardware in set_eee.
I wonder if we should return an error though. With the current
implementation, user space application could simply ask to activate
everything, excepting the kernel to sort it out and return an error
only if something horribly wrong happened. If we start returning an
error for unsupported modes, we could break things. I guess we should
just silently filter the requested modes.
>
> I have a patch which fixes that, restricting (as we do elsewhere) the
> advert according to the EEE supported capabilities retrieved from the
> PCS
Could be interesting :)
> - maybe the problem here is that the PCS doesn't support support
> EEE in 1000baseT mode?
It does, and that's kind of the problem. EEE in ON for 100Tx and 1000T
by default with this PHY. I have several platform with the same MAC-PHY
combination. Only the OdroidC2 shows this particular issue with 1000T-
EEE
As explained in other mails in this thread. The problem does not come
from the MAC entering LPI. It actually comes from the link partner
entering LPI on the Rx path under significant Tx transfer. For some
reason, this completely mess up our PHY.
>
> Out of interest, which PHY is used on this platform?
The PHY is the Realtek RTL8211F
>
> On the SolidRun boards, they're using AR8035, and have suffered this
> occasional link drop problem. What has been found is that it seems
> to
> be to do with the timing parameters, and it seemed to only be 1000bT
> that was affected. I don't remember off hand exactly which or what
> the change was they made to stabilise it though, but I can probabily
> find out tomorrow.
>
Since the same combination of MAC-PHY works well on other designs, it
is also my feeling that is has something to do with some timing
parameter, maybe related to this particular PCB.
While debugging this issue, we tried to play with all the parameters we
could think of but never found anything worth mentioning.
If you have any ideas, I'd be happy to try.
Jerome
_______________________________________________
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 v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Cédric Le Goater @ 2017-01-06 10:04 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Richard Weinberger, Marek Vasut,
Rob Herring, linux-mtd, Joel Stanley, Cyrille Pitchen,
Cyrille Pitchen, Brian Norris, David Woodhouse
In-Reply-To: <20170106094930.0f579dca@bbrezillon>
Hello Boris,
On 01/06/2017 09:49 AM, Boris Brezillon wrote:
> Hi Cédric,
>
> On Thu, 5 Jan 2017 14:39:14 +0100
> Cédric Le Goater <clg@kaod.org> wrote:
>
>> Hello Cyrille, Boris
>>
>> On 01/04/2017 06:50 PM, Boris Brezillon wrote:
>>> Cyrille, Cédric,
>>>
>>> On Wed, 4 Jan 2017 15:52:07 +0100
>>> Cyrille Pitchen <cyrille.pitchen@atmel.com> wrote:
>>>
>>>>>
>>>>>> Anyway, since the review is done now, on my side I won't ask you to remove
>>>>>> or split the support of the 'Command' mode in a separated patch.
>>>>>> I let you do as you want, if it help you to introduce some part of the
>>>>>> support of this 'Command' mode now even if not completed yet, no problem on
>>>>>> my side :)
>>>>>>
>>>>>> I was just giving you some pieces of advice for the next time if you want
>>>>>> to speed up the review of another patch introducing new features.
>>>>>>
>>>>>> However, I will just ask you one more version handling the dummy cycles
>>>>>> properly as it would help us for the global maintenance of the spi-nor
>>>>>> subsystem. This is the only mandatory modification I ask you, after that I
>>>>>> think it would be ok for me and since Marek has already reviewed your
>>>>>> driver, it would be ready to be merged into the spi-nor tree.
>>>>>
>>>>> Sending a v5 which should address your comments.
>>>>>
>>>>> I have removed the label property and will start a new thread in the
>>>>> topic. Any hints on which binding we could add this label prop ?
>>>>>
>>>>
>>>> Here I will provide just few thoughts about this new DT property. I don't
>>>> pretend this is what should be done. I still think other mtd maintainers
>>>> should be involved to discuss this topic.
>>>>
>>>> First the DT property name "label" sounds good to me: it is consistent with
>>>> "label" DT property used to name mtd partitions. However, I don't think it
>>>> should be documented in jedec,spi-nor.txt but *maybe* in partition.txt as
>>>> the purpose of this new DT property seems very close to the "label"
>>>> property of partition nodes: let's think about some hard-disk device
>>>> (/dev/sda) and its partition devices (/dev/sdaX).
>>
>> yes this is very similar. I first looked at introducing a name to
>> an overall containing partition but the partition binding is not
>> designed for that. There are constraints on the start address and
>> the size which does not fit the purpose.
>>
>>> Hm, partition.txt may not be appropriate here. We're not documenting
>>> the MTD partition binding, but the MTD device one. Maybe we should
>>> create mtd.txt and put all generic MTD dev properties here.
>>>>
>>>> Besides, the concept of this memory label is not limited to SPI NOR but
>>>> could also apply to NAND memories or any other MTD handled memories.
>>>
>>> Definitely. Actually I think I'll need that for the Atmel NAND
>>> controller driver rework I'm currently working on, to keep mtdparts
>>> parser happy even after changing the NAND device naming scheme.
>>>
>>>> Hence the DT property might be handled by drivers/mtd/ofpart.c instead of
>>>> being handled by spi-nor.c or by each SPI NOR memory controller driver.
>>>
>>> Actually, that could be done at the mtdcore level in
>>> mtd_set_dev_defaults() [1].
>>
>> that would be perfect.
>>
>>>> Finally, I guess we should take time to discuss and all agree what should
>>>> be done precisely before introducing a new DT property because one general
>>>> rule with DTB files is that users should be able to update their kernel
>>>> image (zImage, uImage, ...) without changing their DTB: device trees should
>>>> be backward compatible. Hence if we make a wrong choice today, we are
>>>> likely to have to live with it and keep supporting that bad choice.
>>>
>>> Rob already acked the patch, so, if all MTD maintainers agree that this
>>> new property is acceptable, we should be fine ;-).
>>
>> yes but we would need to move the binding property to another file.
>> What I sent applied to "jedec,spi-nor" and we want to generalize the
>> property to other devices.
>
> We could create an new file under
> Documentation/devicetree/bindings/mtd/, or we could rename
> partition.txt into something else (generic.txt or common.txt) and
> document more than the partition binding.
OK.
I guess that creating a new file for a single property is a little
overkill or do we expect more common properties at the device level ?
In that case, may be we could keep the partition.txt file and add
a common.txt file. If not, common.txt seems to be a good name.
Waiting a little for others to chime in.
> Can you take care of that (in a separate patch series of course)?
sure, and will you send :
http://code.bulix.org/p019ah-107877
in a separate patch ?
Thanks,
C.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
From: Lee Jones @ 2017-01-06 9:53 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Jingoo Han, devicetree,
linux-kernel, linux-iio, linux-leds, Bjorn Andersson
In-Reply-To: <20170105163054.GO10531@minitux>
On Thu, 05 Jan 2017, Bjorn Andersson wrote:
> On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
>
> > On Wed, 04 Jan 2017, Bjorn Andersson wrote:
> >
> > > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> > >
> > > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > > >
> > > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > > >
> > > > > Implement support for initialization of the lm3533 driver core and
> > > > > probing child devices from Device Tree.
> > > > >
> > >
> > > [..]
> > >
> > > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > > > lm3533_device_bl_init(lm3533);
> > > > > lm3533_device_led_init(lm3533);
> > > > >
> > > > > + if (lm3533->dev->of_node) {
> > > > > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > > + lm3533->dev);
> > > > > + }
> > > >
> > > > I think it's save to call of_platform_populate(), even if !of_node.
> > > > It will just fail and return an error code, which you are ignoring
> > > > anyway.
> > > >
> > >
> > > I thought so too, but that's apparently how you trigger probing children
> > > of the root node. So we're stuck with a conditional.
> >
> > Ah, so this is to protect against the case where DT is present, but a
> > node for this device is not (or is disabled), so is left unprobed.
> > Then the bind is initiated via I2C? Or something else?
> >
>
> In the event that a new lm3533 is spawned from sysfs we would not have
> platform_data when entering lm3533_device_init() and just bail early.
>
> Therefor, this issue would be limited to the odd case of lm3533 being
> initiated from code (e.g. a board file) on a DT enabled system. In which
> case it will create and probe new devices from the root of the DT.
Eewww, do we really want to support that?
--
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 v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
From: Vivek Gautam @ 2017-01-06 9:47 UTC (permalink / raw)
To: Bjorn Andersson
Cc: robh+dt, kishon, sboyd, linux-kernel, devicetree, mark.rutland,
srinivas.kandagatla, linux-arm-msm
In-Reply-To: <20170106071834.GP10531@minitux>
Hi,
On 01/06/2017 12:48 PM, Bjorn Andersson wrote:
> On Tue 20 Dec 09:03 PST 2016, Vivek Gautam wrote:
>
>> diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
> [..]
>> +static int qcom_qmp_phy_poweron(struct phy *phy)
> [..]
>> +
>> +err3:
> Rather than naming your labels errX, it's idiomatic to give them
> descriptive names, e.g. "disable_ref_clk" here.
Sure will change these labels and any such occurrence further in the code.
>
>> + clk_disable_unprepare(qphy->ref_clk);
>> +err2:
>> + regulator_disable(qphy->vddp_ref_clk);
>> +err1:
>> + regulator_disable(qphy->vdda_pll);
>> +err:
>> + regulator_disable(qphy->vdda_phy);
>> + return ret;
>> +}
> [..]
>> +static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
>> +{
>> + const struct qmp_phy_cfg *cfg = qphy->cfg;
>> + void __iomem *serdes = qphy->serdes;
>> + int ret;
>> +
>> + mutex_lock(&qphy->phy_mutex);
>> + if (qphy->init_count++) {
>> + mutex_unlock(&qphy->phy_mutex);
>> + return 0;
>> + }
> As far as I can see phy_init() and phy_exit() already keep reference
> count on the initialization and you only call this function from
> phy_ops->init, so you should be able to drop this.
This is an intermediary function that does the common block initialization.
PHYs like PCIe have a separate common block (apart from SerDes)
for all phy channels. We shouldn't program this common block
multiple times for each channel. That's why this init_count.
>
> [..]
>> +
>> +/* PHY Initialization */
>> +static int qcom_qmp_phy_init(struct phy *phy)
>> +{
> [..]
>> + /* phy power down delay; given in PCIE phy programming guide only */
>> + if (qphy->cfg->type == PHY_TYPE_PCIE)
> Rather than basing this off "is this pcie" it's preferred if you have a
> bool power_down_delay; (or optionally carrying the timeout value) to
> control this.
Sure, will modify this.
>
>> + usleep_range(POWER_DOWN_DELAY_US_MIN, POWER_DOWN_DELAY_US_MAX);
>> +
>> + /* start SerDes and Phy-Coding-Sublayer */
>> + qphy_setbits(pcs + QPHY_START_CTRL, cfg->start_ctrl);
>> +
>> + /* Pull PHY out of reset state */
>> + qphy_clrbits(pcs + QPHY_SW_RESET, SW_RESET);
>> +
>> + status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
>> + mask = cfg->mask_pcs_ready;
>> +
>> + ret = !mask ? 0 : readl_poll_timeout(status, val, !(val & mask), 1,
>> + PHY_INIT_COMPLETE_TIMEOUT);
> I presume it's not okay to read the status register even once for pcie?
> If it is you can skip the conditional as !(val & 0) will break the poll
> after the first read.
Yea, it is okay to read the status register for pcie.
Will leave just readl_poll_timeout() that exits on !(val & mask).
We anyways don't set mask_pcs_ready for pcie.
> [..]
>> +static int qcom_qmp_phy_exit(struct phy *phy)
>> +{
> [..]
>> +}
>> +
>> +
> Extra blank line
Will remove it.
>
>> +static int qcom_qmp_phy_regulator_init(struct device *dev)
> [..]
>> +static
>> +struct qmp_phy_desc *qcom_qmp_phy_create(struct platform_device *pdev, int id)
>> +{
> [..]
>> + phy_desc->pipe_clk = devm_clk_get(dev, prop_name);
>> + if (IS_ERR(phy_desc->pipe_clk)) {
>> + if (qphy->cfg->type == PHY_TYPE_PCIE ||
>> + qphy->cfg->type == PHY_TYPE_USB3) {
> Is this check adding any value?
The USB3 and PCIe phys are PIPE based phys, and hence the pipe
clock is mandatory for them. Other phys don't care about pipe clock.
>
>> + ret = PTR_ERR(phy_desc->pipe_clk);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev,
>> + "failed to get lane%d pipe_clk, %d\n",
>> + id, ret);
>> + return ERR_PTR(ret);
>> + }
>> + phy_desc->pipe_clk = NULL;
> Regards,
> Bjorn
> --
> 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
Regards
Vivek
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Teresa Remmet @ 2017-01-06 9:27 UTC (permalink / raw)
To: Brian Norris, Tony Lindgren
Cc: Mark Rutland, devicetree, linux-omap, Rob Herring, linux-mtd,
Benoît Cousson, Brian Norris, Adam Ford, linux-arm-kernel
In-Reply-To: <20170105175619.GA56877@google.com>
Hello Brian,
Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> >
> > * Tony Lindgren <tony@atomide.com> [170105 07:37]:
> > >
> > > * Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
> > > >
> > > > To improve NAND safety we updated the partition layout.
> > > > Added barebox backup partition and removed kernel and oftree
> > > > partition. They are kept in ubi now.
> > > What about the users with earlier partition tables?
> > >
> > > Please read about "flag day" changes, typically they are not
> > > acceptable.
> > Adding Brian and Adam to Cc. Can you guys come up with some
> > solution on this?
> I don't have much context for this thread, and no I don't plan to
> solve
> your problems for you. But I can provide tips!
>
> >
> > I'm suggesting we leave the kernel nodes empty and let u-boot
> > populate them, so maybe you guys can discuss this on the related
> > lists.
> That's an option. I've worked with platforms that did something like
> this, and that's really one of the only ways you can handle putting
> partition information in the device tree. You're really hamstringing
> yourself when you put all the partition information in the device
> tree.
> And it's just dumb once that gets codified in the kernel source tree.
>
In our case the bootloader does pass the partition table to the kernel.
So it gets overwritten anyway. This was just more for backup,
if someone uses a different bootloader. But I'm fine with removing the
nand partition table completely from the kernel device tree.
Same with the SPI nor partition table.
I will send patches for this.
Regards,
Teresa
> The best solution would be to try to migrate away from static device
> tree representations of partition info entirely. UBI volumes are best
> where possible. If not, then some other kind of on-flash data
> structures
> (along the lines of a GPT) with a corresponding MTD partition parser
> is
> an OK alternative. Unfortunately, there isn't any good standard
> format
> for this on MTD, so it's typically all custom -- and so people use
> the
> easiest approach: device tree. And it's even more difficult with
> NAND,
> which has reliability problems, especially with static data (e.g.,
> read
> disturb).
>
> Anyway, the parser solution is helpful only if one can properly fix
> the
> "flag day" first. And it requires a little bit more work to be
> generally
> useful; I posted some work for this over a year ago, but bikeshedding
> brought it down.
>
> >
> > The rest of the series looks fine to me so applying it into
> > omap-for-v4.11/dt.
> Brian
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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