* [PATCH v5 1/1] eeprom: at24: convert magic numbers to structs.
From: Sven Van Asbroeck @ 2017-12-20 16:48 UTC (permalink / raw)
To: svendev, wsa, brgl, nsekhar, sakari.ailus, javier,
divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c
In-Reply-To: <1513788536-7672-1-git-send-email-svendev@arcx.com>
Fundamental properties such as capacity and page size differ
among at24-type chips. But these chips do not have an id register,
so this can't be discovered at runtime.
Traditionally, at24-type eeprom properties were determined in two ways:
- by passing a 'struct at24_platform_data' via platform_data, or
- by naming the chip type in the devicetree, which passes a
'magic number' to probe(), which is then converted to
a 'struct at24_platform_data'.
Recently a bug was discovered because the magic number rounds down
all chip sizes to the lowest power of two. This was addressed by
a work-around, with the wish that magic numbers should over time
be converted to structs.
commit 5478e478eee3 ("eeprom: at24: correctly set the size for at24mac402")
This patch replaces the magic numbers with 'struct at24_chip_data'.
Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
---
drivers/misc/eeprom/at24.c | 221 ++++++++++++++++++++-------------------------
1 file changed, 100 insertions(+), 121 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index b44a3d2b..b1f78b9 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -105,16 +105,6 @@ struct at24_data {
module_param_named(write_timeout, at24_write_timeout, uint, 0);
MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 25)");
-#define AT24_SIZE_BYTELEN 5
-#define AT24_SIZE_FLAGS 8
-
-#define AT24_BITMASK(x) (BIT(x) - 1)
-
-/* create non-zero magic value for given eeprom parameters */
-#define AT24_DEVICE_MAGIC(_len, _flags) \
- ((1 << AT24_SIZE_FLAGS | (_flags)) \
- << AT24_SIZE_BYTELEN | ilog2(_len))
-
/*
* Both reads and writes fail if the previous write didn't complete yet. This
* macro loops a few times waiting at least long enough for one entire page
@@ -132,113 +122,108 @@ struct at24_data {
op_time ? time_before(op_time, tout) : true; \
usleep_range(1000, 1500), op_time = jiffies)
+struct at24_chip_data {
+ /*
+ * these fields mirror their equivalents in
+ * struct at24_platform_data
+ */
+ u32 byte_len;
+ u8 flags;
+};
+
+#define AT24_CHIP_DATA(_name, _len, _flags) \
+ static const struct at24_chip_data _name = { \
+ .byte_len = _len, .flags = _flags, \
+ }
+
+/* needs 8 addresses as A0-A2 are ignored */
+AT24_CHIP_DATA(at24_data_24c00, 128 / 8, AT24_FLAG_TAKE8ADDR);
+/* old variants can't be handled with this generic entry! */
+AT24_CHIP_DATA(at24_data_24c01, 1024 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs01, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c02, 2048 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs02, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24mac402, 48 / 8,
+ AT24_FLAG_MAC | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24mac602, 64 / 8,
+ AT24_FLAG_MAC | AT24_FLAG_READONLY);
+/* spd is a 24c02 in memory DIMMs */
+AT24_CHIP_DATA(at24_data_spd, 2048 / 8,
+ AT24_FLAG_READONLY | AT24_FLAG_IRUGO);
+AT24_CHIP_DATA(at24_data_24c04, 4096 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs04, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+/* 24rf08 quirk is handled at i2c-core */
+AT24_CHIP_DATA(at24_data_24c08, 8192 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs08, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c16, 16384 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs16, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c32, 32768 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24cs32, 16,
+ AT24_FLAG_ADDR16 | AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c64, 65536 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24cs64, 16,
+ AT24_FLAG_ADDR16 | AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c128, 131072 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24c256, 262144 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24c512, 524288 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24c1024, 1048576 / 8, AT24_FLAG_ADDR16);
+/* identical to 24c08 ? */
+AT24_CHIP_DATA(at24_data_INT3499, 8192 / 8, 0);
+
static const struct i2c_device_id at24_ids[] = {
- /* needs 8 addresses as A0-A2 are ignored */
- { "24c00", AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR) },
- /* old variants can't be handled with this generic entry! */
- { "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
- { "24cs01", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) },
- { "24cs02", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24mac402", AT24_DEVICE_MAGIC(48 / 8,
- AT24_FLAG_MAC | AT24_FLAG_READONLY) },
- { "24mac602", AT24_DEVICE_MAGIC(64 / 8,
- AT24_FLAG_MAC | AT24_FLAG_READONLY) },
- /* spd is a 24c02 in memory DIMMs */
- { "spd", AT24_DEVICE_MAGIC(2048 / 8,
- AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
- { "24c04", AT24_DEVICE_MAGIC(4096 / 8, 0) },
- { "24cs04", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- /* 24rf08 quirk is handled at i2c-core */
- { "24c08", AT24_DEVICE_MAGIC(8192 / 8, 0) },
- { "24cs08", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24c16", AT24_DEVICE_MAGIC(16384 / 8, 0) },
- { "24cs16", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24c32", AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16) },
- { "24cs32", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_ADDR16 |
- AT24_FLAG_SERIAL |
- AT24_FLAG_READONLY) },
- { "24c64", AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16) },
- { "24cs64", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_ADDR16 |
- AT24_FLAG_SERIAL |
- AT24_FLAG_READONLY) },
- { "24c128", AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16) },
- { "24c256", AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16) },
- { "24c512", AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16) },
- { "24c1024", AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16) },
- { "at24", 0 },
+ { "24c00", (kernel_ulong_t)&at24_data_24c00 },
+ { "24c01", (kernel_ulong_t)&at24_data_24c01 },
+ { "24cs01", (kernel_ulong_t)&at24_data_24cs01 },
+ { "24c02", (kernel_ulong_t)&at24_data_24c02 },
+ { "24cs02", (kernel_ulong_t)&at24_data_24cs02 },
+ { "24mac402", (kernel_ulong_t)&at24_data_24mac402 },
+ { "24mac602", (kernel_ulong_t)&at24_data_24mac602 },
+ { "spd", (kernel_ulong_t)&at24_data_spd },
+ { "24c04", (kernel_ulong_t)&at24_data_24c04 },
+ { "24cs04", (kernel_ulong_t)&at24_data_24cs04 },
+ { "24c08", (kernel_ulong_t)&at24_data_24c08 },
+ { "24cs08", (kernel_ulong_t)&at24_data_24cs08 },
+ { "24c16", (kernel_ulong_t)&at24_data_24c16 },
+ { "24cs16", (kernel_ulong_t)&at24_data_24cs16 },
+ { "24c32", (kernel_ulong_t)&at24_data_24c32 },
+ { "24cs32", (kernel_ulong_t)&at24_data_24cs32 },
+ { "24c64", (kernel_ulong_t)&at24_data_24c64 },
+ { "24cs64", (kernel_ulong_t)&at24_data_24cs64 },
+ { "24c128", (kernel_ulong_t)&at24_data_24c128 },
+ { "24c256", (kernel_ulong_t)&at24_data_24c256 },
+ { "24c512", (kernel_ulong_t)&at24_data_24c512 },
+ { "24c1024", (kernel_ulong_t)&at24_data_24c1024 },
+ { "at24", 0 },
{ /* END OF LIST */ }
};
MODULE_DEVICE_TABLE(i2c, at24_ids);
static const struct of_device_id at24_of_match[] = {
- {
- .compatible = "atmel,24c00",
- .data = (void *)AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR)
- },
- {
- .compatible = "atmel,24c01",
- .data = (void *)AT24_DEVICE_MAGIC(1024 / 8, 0)
- },
- {
- .compatible = "atmel,24c02",
- .data = (void *)AT24_DEVICE_MAGIC(2048 / 8, 0)
- },
- {
- .compatible = "atmel,spd",
- .data = (void *)AT24_DEVICE_MAGIC(2048 / 8,
- AT24_FLAG_READONLY | AT24_FLAG_IRUGO)
- },
- {
- .compatible = "atmel,24c04",
- .data = (void *)AT24_DEVICE_MAGIC(4096 / 8, 0)
- },
- {
- .compatible = "atmel,24c08",
- .data = (void *)AT24_DEVICE_MAGIC(8192 / 8, 0)
- },
- {
- .compatible = "atmel,24c16",
- .data = (void *)AT24_DEVICE_MAGIC(16384 / 8, 0)
- },
- {
- .compatible = "atmel,24c32",
- .data = (void *)AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c64",
- .data = (void *)AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c128",
- .data = (void *)AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c256",
- .data = (void *)AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c512",
- .data = (void *)AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16)
- },
- {
- .compatible = "atmel,24c1024",
- .data = (void *)AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16)
- },
- { },
+ { .compatible = "atmel,24c00", .data = &at24_data_24c00 },
+ { .compatible = "atmel,24c01", .data = &at24_data_24c01 },
+ { .compatible = "atmel,24c02", .data = &at24_data_24c02 },
+ { .compatible = "atmel,spd", .data = &at24_data_spd },
+ { .compatible = "atmel,24c04", .data = &at24_data_24c04 },
+ { .compatible = "atmel,24c08", .data = &at24_data_24c08 },
+ { .compatible = "atmel,24c16", .data = &at24_data_24c16 },
+ { .compatible = "atmel,24c32", .data = &at24_data_24c32 },
+ { .compatible = "atmel,24c64", .data = &at24_data_24c64 },
+ { .compatible = "atmel,24c128", .data = &at24_data_24c128 },
+ { .compatible = "atmel,24c256", .data = &at24_data_24c256 },
+ { .compatible = "atmel,24c512", .data = &at24_data_24c512 },
+ { .compatible = "atmel,24c1024", .data = &at24_data_24c1024 },
+ { /* END OF LIST */ },
};
MODULE_DEVICE_TABLE(of, at24_of_match);
static const struct acpi_device_id at24_acpi_ids[] = {
- { "INT3499", AT24_DEVICE_MAGIC(8192 / 8, 0) },
- { }
+ { "INT3499", (kernel_ulong_t)&at24_data_INT3499 },
+ { /* END OF LIST */ }
};
MODULE_DEVICE_TABLE(acpi, at24_acpi_ids);
@@ -516,8 +501,8 @@ static unsigned int at24_get_offset_adj(u8 flags, unsigned int byte_len)
static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
- struct at24_platform_data chip;
- kernel_ulong_t magic = 0;
+ struct at24_platform_data chip = { 0 };
+ const struct at24_chip_data *cd = NULL;
bool writable;
struct at24_data *at24;
int err;
@@ -535,28 +520,22 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
*/
if (client->dev.of_node &&
of_match_device(at24_of_match, &client->dev)) {
- magic = (kernel_ulong_t)
- of_device_get_match_data(&client->dev);
+ cd = of_device_get_match_data(&client->dev);
} else if (id) {
- magic = id->driver_data;
+ cd = (void *)id->driver_data;
} else {
const struct acpi_device_id *aid;
aid = acpi_match_device(at24_acpi_ids, &client->dev);
if (aid)
- magic = aid->driver_data;
+ cd = (void *)aid->driver_data;
}
- if (!magic)
+ if (!cd)
return -ENODEV;
- chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
- magic >>= AT24_SIZE_BYTELEN;
- chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
-
+ chip.byte_len = cd->byte_len;
+ chip.flags = cd->flags;
at24_get_pdata(&client->dev, &chip);
-
- chip.setup = NULL;
- chip.context = NULL;
}
if (!is_power_of_2(chip.byte_len))
--
1.9.1
^ permalink raw reply related
* [PATCH v5 0/1] eeprom: at24: convert magic numbers to structs.
From: Sven Van Asbroeck @ 2017-12-20 16:48 UTC (permalink / raw)
To: svendev, wsa, brgl, nsekhar, sakari.ailus, javier,
divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c
v5:
applied formatting suggestions
v4:
applied formatting suggestions
v3:
rebase against maintainer's latest devel branch
removed macros from struct {i2c,of,acpi}_device_id for easy grepping
applied newline, formatting, tab suggestions
v2:
use struct at24_chip_data instead of struct at24_platform_data
(which decreases code size)
explicitly write out of compatible nodes, e.g. "atmel,24c04"
(which allows grepping for of compatible nodes)
v1:
first shot
Sven Van Asbroeck (1):
eeprom: at24: convert magic numbers to structs.
drivers/misc/eeprom/at24.c | 221 ++++++++++++++++++++-------------------------
1 file changed, 100 insertions(+), 121 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v3 1/1] eeprom: at24: convert magic numbers to structs.
From: Sven Van Asbroeck @ 2017-12-20 16:42 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sven Van Asbroeck, Sven Van Asbroeck, Wolfram Sang, nsekhar,
Sakari Ailus, Javier Martinez Canillas, Divagar Mohandass,
devicetree, Linux Kernel Mailing List, linux-i2c
In-Reply-To: <CAMRc=McQThGRYqmbue8jw_uKQPicitQn6rNxZxo9+HYQ3UaYDw@mail.gmail.com>
> I'm at 77 columns if I add a single tab after '.compatible = "atmel,24c1024"'.
You're right, I had to knock some sense into my editor first :)
>
> It looks nice like this, so I prefer to keep it.
Ok I'll post a v5.
^ permalink raw reply
* Re: [PATCH v3 1/1] eeprom: at24: convert magic numbers to structs.
From: Bartosz Golaszewski @ 2017-12-20 16:37 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: Sven Van Asbroeck, Sven Van Asbroeck, Wolfram Sang,
nsekhar-l0cyMroinI0, Sakari Ailus, Javier Martinez Canillas,
Divagar Mohandass, devicetree, Linux Kernel Mailing List,
linux-i2c
In-Reply-To: <CAGngYiVJRVuMtLThnvsXbXMuL-_4ZN=2RkuCkRBzq3cf+W4sPg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-20 17:32 GMT+01:00 Sven Van Asbroeck <thesven73-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>> + { .compatible = "atmel,24c00", .data = &at24_data_24c00 },
>>
>> Add tabs here as well, seems like there's enough space in the line.
>
> There's not enough space in the line to line up the 24c1024 entry with
> the others. I'll revert to the formatting style that was there before.
I'm at 77 columns if I add a single tab after '.compatible = "atmel,24c1024"'.
It looks nice like this, so I prefer to keep it.
Thanks,
Bartosz Golaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 1/1] eeprom: at24: convert magic numbers to structs.
From: Sven Van Asbroeck @ 2017-12-20 16:36 UTC (permalink / raw)
To: svendev, wsa, brgl, nsekhar, sakari.ailus, javier,
divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c
In-Reply-To: <1513787814-6245-1-git-send-email-svendev@arcx.com>
Fundamental properties such as capacity and page size differ
among at24-type chips. But these chips do not have an id register,
so this can't be discovered at runtime.
Traditionally, at24-type eeprom properties were determined in two ways:
- by passing a 'struct at24_platform_data' via platform_data, or
- by naming the chip type in the devicetree, which passes a
'magic number' to probe(), which is then converted to
a 'struct at24_platform_data'.
Recently a bug was discovered because the magic number rounds down
all chip sizes to the lowest power of two. This was addressed by
a work-around, with the wish that magic numbers should over time
be converted to structs.
commit 5478e478eee3 ("eeprom: at24: correctly set the size for at24mac402")
This patch replaces the magic numbers with 'struct at24_chip_data'.
Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
---
drivers/misc/eeprom/at24.c | 182 +++++++++++++++++++++++++--------------------
1 file changed, 100 insertions(+), 82 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index b44a3d2b..5cbb92c 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -105,16 +105,6 @@ struct at24_data {
module_param_named(write_timeout, at24_write_timeout, uint, 0);
MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 25)");
-#define AT24_SIZE_BYTELEN 5
-#define AT24_SIZE_FLAGS 8
-
-#define AT24_BITMASK(x) (BIT(x) - 1)
-
-/* create non-zero magic value for given eeprom parameters */
-#define AT24_DEVICE_MAGIC(_len, _flags) \
- ((1 << AT24_SIZE_FLAGS | (_flags)) \
- << AT24_SIZE_BYTELEN | ilog2(_len))
-
/*
* Both reads and writes fail if the previous write didn't complete yet. This
* macro loops a few times waiting at least long enough for one entire page
@@ -132,48 +122,83 @@ struct at24_data {
op_time ? time_before(op_time, tout) : true; \
usleep_range(1000, 1500), op_time = jiffies)
+struct at24_chip_data {
+ /*
+ * these fields mirror their equivalents in
+ * struct at24_platform_data
+ */
+ u32 byte_len;
+ u8 flags;
+};
+
+#define AT24_CHIP_DATA(_name, _len, _flags) \
+ static const struct at24_chip_data _name = { \
+ .byte_len = _len, .flags = _flags, \
+ }
+
+/* needs 8 addresses as A0-A2 are ignored */
+AT24_CHIP_DATA(at24_data_24c00, 128 / 8, AT24_FLAG_TAKE8ADDR);
+/* old variants can't be handled with this generic entry! */
+AT24_CHIP_DATA(at24_data_24c01, 1024 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs01, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c02, 2048 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs02, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24mac402, 48 / 8,
+ AT24_FLAG_MAC | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24mac602, 64 / 8,
+ AT24_FLAG_MAC | AT24_FLAG_READONLY);
+/* spd is a 24c02 in memory DIMMs */
+AT24_CHIP_DATA(at24_data_spd, 2048 / 8,
+ AT24_FLAG_READONLY | AT24_FLAG_IRUGO);
+AT24_CHIP_DATA(at24_data_24c04, 4096 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs04, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+/* 24rf08 quirk is handled at i2c-core */
+AT24_CHIP_DATA(at24_data_24c08, 8192 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs08, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c16, 16384 / 8, 0);
+AT24_CHIP_DATA(at24_data_24cs16, 16,
+ AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c32, 32768 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24cs32, 16,
+ AT24_FLAG_ADDR16 | AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c64, 65536 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24cs64, 16,
+ AT24_FLAG_ADDR16 | AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
+AT24_CHIP_DATA(at24_data_24c128, 131072 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24c256, 262144 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24c512, 524288 / 8, AT24_FLAG_ADDR16);
+AT24_CHIP_DATA(at24_data_24c1024, 1048576 / 8, AT24_FLAG_ADDR16);
+/* identical to 24c08 ? */
+AT24_CHIP_DATA(at24_data_INT3499, 8192 / 8, 0);
+
static const struct i2c_device_id at24_ids[] = {
- /* needs 8 addresses as A0-A2 are ignored */
- { "24c00", AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR) },
- /* old variants can't be handled with this generic entry! */
- { "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
- { "24cs01", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) },
- { "24cs02", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24mac402", AT24_DEVICE_MAGIC(48 / 8,
- AT24_FLAG_MAC | AT24_FLAG_READONLY) },
- { "24mac602", AT24_DEVICE_MAGIC(64 / 8,
- AT24_FLAG_MAC | AT24_FLAG_READONLY) },
- /* spd is a 24c02 in memory DIMMs */
- { "spd", AT24_DEVICE_MAGIC(2048 / 8,
- AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
- { "24c04", AT24_DEVICE_MAGIC(4096 / 8, 0) },
- { "24cs04", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- /* 24rf08 quirk is handled at i2c-core */
- { "24c08", AT24_DEVICE_MAGIC(8192 / 8, 0) },
- { "24cs08", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24c16", AT24_DEVICE_MAGIC(16384 / 8, 0) },
- { "24cs16", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
- { "24c32", AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16) },
- { "24cs32", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_ADDR16 |
- AT24_FLAG_SERIAL |
- AT24_FLAG_READONLY) },
- { "24c64", AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16) },
- { "24cs64", AT24_DEVICE_MAGIC(16,
- AT24_FLAG_ADDR16 |
- AT24_FLAG_SERIAL |
- AT24_FLAG_READONLY) },
- { "24c128", AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16) },
- { "24c256", AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16) },
- { "24c512", AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16) },
- { "24c1024", AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16) },
- { "at24", 0 },
+ { "24c00", (kernel_ulong_t)&at24_data_24c00 },
+ { "24c01", (kernel_ulong_t)&at24_data_24c01 },
+ { "24cs01", (kernel_ulong_t)&at24_data_24cs01 },
+ { "24c02", (kernel_ulong_t)&at24_data_24c02 },
+ { "24cs02", (kernel_ulong_t)&at24_data_24cs02 },
+ { "24mac402", (kernel_ulong_t)&at24_data_24mac402 },
+ { "24mac602", (kernel_ulong_t)&at24_data_24mac602 },
+ { "spd", (kernel_ulong_t)&at24_data_spd },
+ { "24c04", (kernel_ulong_t)&at24_data_24c04 },
+ { "24cs04", (kernel_ulong_t)&at24_data_24cs04 },
+ { "24c08", (kernel_ulong_t)&at24_data_24c08 },
+ { "24cs08", (kernel_ulong_t)&at24_data_24cs08 },
+ { "24c16", (kernel_ulong_t)&at24_data_24c16 },
+ { "24cs16", (kernel_ulong_t)&at24_data_24cs16 },
+ { "24c32", (kernel_ulong_t)&at24_data_24c32 },
+ { "24cs32", (kernel_ulong_t)&at24_data_24cs32 },
+ { "24c64", (kernel_ulong_t)&at24_data_24c64 },
+ { "24cs64", (kernel_ulong_t)&at24_data_24cs64 },
+ { "24c128", (kernel_ulong_t)&at24_data_24c128 },
+ { "24c256", (kernel_ulong_t)&at24_data_24c256 },
+ { "24c512", (kernel_ulong_t)&at24_data_24c512 },
+ { "24c1024", (kernel_ulong_t)&at24_data_24c1024 },
+ { "at24", 0 },
{ /* END OF LIST */ }
};
MODULE_DEVICE_TABLE(i2c, at24_ids);
@@ -181,64 +206,63 @@ struct at24_data {
static const struct of_device_id at24_of_match[] = {
{
.compatible = "atmel,24c00",
- .data = (void *)AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR)
+ .data = &at24_data_24c00
},
{
.compatible = "atmel,24c01",
- .data = (void *)AT24_DEVICE_MAGIC(1024 / 8, 0)
+ .data = &at24_data_24c01
},
{
.compatible = "atmel,24c02",
- .data = (void *)AT24_DEVICE_MAGIC(2048 / 8, 0)
+ .data = &at24_data_24c02
},
{
.compatible = "atmel,spd",
- .data = (void *)AT24_DEVICE_MAGIC(2048 / 8,
- AT24_FLAG_READONLY | AT24_FLAG_IRUGO)
+ .data = &at24_data_spd
},
{
.compatible = "atmel,24c04",
- .data = (void *)AT24_DEVICE_MAGIC(4096 / 8, 0)
+ .data = &at24_data_24c04
},
{
.compatible = "atmel,24c08",
- .data = (void *)AT24_DEVICE_MAGIC(8192 / 8, 0)
+ .data = &at24_data_24c08
},
{
.compatible = "atmel,24c16",
- .data = (void *)AT24_DEVICE_MAGIC(16384 / 8, 0)
+ .data = &at24_data_24c16
},
{
.compatible = "atmel,24c32",
- .data = (void *)AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16)
+ .data = &at24_data_24c32
},
{
.compatible = "atmel,24c64",
- .data = (void *)AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16)
+ .data = &at24_data_24c64
},
{
.compatible = "atmel,24c128",
- .data = (void *)AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16)
+ .data = &at24_data_24c128
},
{
.compatible = "atmel,24c256",
- .data = (void *)AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16)
+ .data = &at24_data_24c256
},
{
.compatible = "atmel,24c512",
- .data = (void *)AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16)
+ .data = &at24_data_24c512
},
{
.compatible = "atmel,24c1024",
- .data = (void *)AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16)
+ .data = &at24_data_24c1024
},
- { },
+ { /* END OF LIST */ },
};
MODULE_DEVICE_TABLE(of, at24_of_match);
static const struct acpi_device_id at24_acpi_ids[] = {
- { "INT3499", AT24_DEVICE_MAGIC(8192 / 8, 0) },
- { }
+ { "INT3499", (kernel_ulong_t)&at24_data_INT3499 },
+ { /* END OF LIST */ }
};
MODULE_DEVICE_TABLE(acpi, at24_acpi_ids);
@@ -516,8 +540,8 @@ static unsigned int at24_get_offset_adj(u8 flags, unsigned int byte_len)
static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
- struct at24_platform_data chip;
- kernel_ulong_t magic = 0;
+ struct at24_platform_data chip = { 0 };
+ const struct at24_chip_data *cd = NULL;
bool writable;
struct at24_data *at24;
int err;
@@ -535,28 +559,22 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
*/
if (client->dev.of_node &&
of_match_device(at24_of_match, &client->dev)) {
- magic = (kernel_ulong_t)
- of_device_get_match_data(&client->dev);
+ cd = of_device_get_match_data(&client->dev);
} else if (id) {
- magic = id->driver_data;
+ cd = (void *)id->driver_data;
} else {
const struct acpi_device_id *aid;
aid = acpi_match_device(at24_acpi_ids, &client->dev);
if (aid)
- magic = aid->driver_data;
+ cd = (void *)aid->driver_data;
}
- if (!magic)
+ if (!cd)
return -ENODEV;
- chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
- magic >>= AT24_SIZE_BYTELEN;
- chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
-
+ chip.byte_len = cd->byte_len;
+ chip.flags = cd->flags;
at24_get_pdata(&client->dev, &chip);
-
- chip.setup = NULL;
- chip.context = NULL;
}
if (!is_power_of_2(chip.byte_len))
--
1.9.1
^ permalink raw reply related
* [PATCH v4 0/1] eeprom: at24: convert magic numbers to structs.
From: Sven Van Asbroeck @ 2017-12-20 16:36 UTC (permalink / raw)
To: svendev, wsa, brgl, nsekhar, sakari.ailus, javier,
divagar.mohandass
Cc: devicetree, linux-kernel, linux-i2c
v4:
applied formatting suggestions
v3:
rebase against maintainer's latest devel branch
removed macros from struct {i2c,of,acpi}_device_id for easy grepping
applied newline, formatting, tab suggestions
v2:
use struct at24_chip_data instead of struct at24_platform_data
(which decreases code size)
explicitly write out of compatible nodes, e.g. "atmel,24c04"
(which allows grepping for of compatible nodes)
v1:
first shot
Sven Van Asbroeck (1):
eeprom: at24: convert magic numbers to structs.
drivers/misc/eeprom/at24.c | 182 +++++++++++++++++++++++++--------------------
1 file changed, 100 insertions(+), 82 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v3 1/1] eeprom: at24: convert magic numbers to structs.
From: Sven Van Asbroeck @ 2017-12-20 16:32 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sven Van Asbroeck, Sven Van Asbroeck, Wolfram Sang,
nsekhar-l0cyMroinI0, Sakari Ailus, Javier Martinez Canillas,
Divagar Mohandass, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, linux-i2c
In-Reply-To: <CAMRc=Md0VwJ=OeE_-2uWi2sr4gJ8v9CnmexYgdDGR0pbyXYo_g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> + { .compatible = "atmel,24c00", .data = &at24_data_24c00 },
>
> Add tabs here as well, seems like there's enough space in the line.
There's not enough space in the line to line up the 24c1024 entry with
the others. I'll revert to the formatting style that was there before.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: Add an enable method to RISC-V
From: Rob Herring @ 2017-12-20 16:13 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
patches-q3qR2WxjNRFS9aJRtSZj7A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171207230523.29798-1-palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
On Thu, Dec 07, 2017 at 03:05:23PM -0800, Palmer Dabbelt wrote:
> RISC-V doesn't currently specify a mechanism for enabling or disabling
> CPUs. Instead, we assume that all CPUs are enabled on boot, and if
> someone wants to save power we instead put a CPU to sleep via a WFI
> loop. Future systems may have an explicit mechanism for putting a CPU
> to sleep, so we're standardizing the device tree entry for when that
> happens.
>
> We're not defining a spin-table based interface to the firmware, as the
> plan is to handle this entirely within the kernel instead.
>
> CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Palmer Dabbelt <palmer-SpMDHPYPyPbQT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/riscv/cpus.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.txt b/Documentation/devicetree/bindings/riscv/cpus.txt
> index adf7b7af5dc3..68f88eacc594 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.txt
> +++ b/Documentation/devicetree/bindings/riscv/cpus.txt
> @@ -82,6 +82,15 @@ described below.
> Value type: <string>
> Definition: Contains the RISC-V ISA string of this hart. These
> ISA strings are defined by the RISC-V ISA manual.
> + - cpu-enable-method:
> + Usage: optional
> + Value type: <stringlist>
> + Definition: When absent, default is either "always-disabled"
> + "always-enabled", depending on the current state
> + of the CPU.
How does one determine the state of other cpus?
> + Must be one of:
> + * "always-disabled": This CPU cannot be enabled.
status = "disabled" already serves this purpose.
> + * "always-enabled": This CPU cannot be disabled.
I don't see how this can work unless the kernel is loaded prior to
bringing all cpus out of reset. You have to halt cpus in some way until
the kernel is loaded.
>
> Example: SiFive Freedom U540G Development Kit
> ---------------------------------------------
> --
> 2.13.6
>
--
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
* Devicetree Specification 0.2
From: Grant Likely @ 2017-12-20 16:05 UTC (permalink / raw)
To: devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi all,
I've just released v0.2 of the devicetree specification. You can find
the prebuilt PDF on the release page here:
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2
The document text is also published on readthedocs (unofficially; the
pdf is considered authoritative):
http://devicetree-specification.readthedocs.io/en/latest/
Please go take a look. Comments can be made here, or posted as issues
on the GitHub page. Or better yet, submit patches!
https://github.com/devicetree-org/devicetree-specification/issues
Cheers,
g.
---
Mostly editorial changes from v0.1. Primary purpose for this release is to work
through the mechanics of cutting a release. Right now it is more labour
intensive than I would like for two reasons:
- The GitHub OAuth key must be manually changed to the person cutting the
release. I would like it to be automatically selected based on who signed
the release tag
- The pre-release flag needs to be manually changed between -pre/-rc and full
releases. This also should be automatically determined based on tag pattern
matching
Content changes include:
* Added more recommended generic node names
* Added interrupts-extended
* Additional phy times
* Filled out detail in source language chapter
* Editorial changes
* Added changebar version to release documents
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v11 2/3] dt-bindings: iio: temperature: add MLX90632 device bindings
From: Crt Mori @ 2017-12-20 15:48 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Crt Mori
Add device tree bindings for MLX90632 IR temperature sensor.
Signed-off-by: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../bindings/iio/temperature/mlx90632.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
new file mode 100644
index 000000000000..0b05812001f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
@@ -0,0 +1,28 @@
+* Melexis MLX90632 contactless Infra Red temperature sensor
+
+Link to datasheet: https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90632
+
+There are various applications for the Infra Red contactless temperature sensor
+and MLX90632 is most suitable for consumer applications where measured object
+temperature is in range between -20 to 200 degrees Celsius with relative error
+of measurement below 1 degree Celsius in object temperature range for
+industrial applications. Since it can operate and measure ambient temperature
+in range of -20 to 85 degrees Celsius it is suitable also for outdoor use.
+
+Be aware that electronics surrounding the sensor can increase ambient
+temperature. MLX90632 can be calibrated to reduce the housing effect via
+already existing EEPROM parameters.
+
+Since measured object emissivity effects Infra Red energy emitted, emissivity
+should be set before requesting the object temperature.
+
+Required properties:
+ - compatible: should be "melexis,mlx90632"
+ - reg: the I2C address of the sensor (default 0x3a)
+
+Example:
+
+mlx90632@3a {
+ compatible = "melexis,mlx90632";
+ reg = <0x3a>;
+};
--
2.15.0
^ permalink raw reply related
* Re: [PATCH v3 3/4] ARM: dts: add Samsung's exynos4412-based midas boards
From: Krzysztof Kozlowski @ 2017-12-20 15:39 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Kukjin Kim,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marek Szyprowski,
Bartłomiej Żołnierkiewicz
In-Reply-To: <20171220153315.GB23127-WP75azK+jQYgsBAKwltoeQ@public.gmane.org>
On Wed, Dec 20, 2017 at 4:33 PM, Simon Shields <simon-WP75azK+jQYgsBAKwltoeQ@public.gmane.org> wrote:
> Hi Krzysztof,
>
> On Wed, Dec 20, 2017 at 03:08:27PM +0100, Krzysztof Kozlowski wrote:
>> On Mon, Dec 18, 2017 at 1:38 PM, Simon Shields <simon-WP75azK+jQYgsBAKwltoeQ@public.gmane.org> wrote:
>> > "midas" is the codename for a family of smartphones released by Samsung
>> > Mobile. It includes the Galaxy S3 (GT-I9300/I9305) and the Galaxy
>> > Note 2 (GT-N7100/N7105). The boards largely have the same peripherals:
>> > the main differences are touchscreen, display panel and cellular modem.
>> >
>> > Signed-off-by: Simon Shields <simon-WP75azK+jQYgsBAKwltoeQ@public.gmane.org>
>> > ---
>> > arch/arm/boot/dts/Makefile | 3 +++
>> > arch/arm/boot/dts/exynos4412-m0.dts | 27 +++++++++++++++++++++++++
>> > arch/arm/boot/dts/exynos4412-m3.dts | 14 +++++++++++++
>> > arch/arm/boot/dts/exynos4412-t0.dts | 40 +++++++++++++++++++++++++++++++++++++
>> > 4 files changed, 84 insertions(+)
>> > create mode 100644 arch/arm/boot/dts/exynos4412-m0.dts
>> > create mode 100644 arch/arm/boot/dts/exynos4412-m3.dts
>> > create mode 100644 arch/arm/boot/dts/exynos4412-t0.dts
>> >
>> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> > index 66e28af289da..035abd66b472 100644
>> > --- a/arch/arm/boot/dts/Makefile
>> > +++ b/arch/arm/boot/dts/Makefile
>> > @@ -164,11 +164,14 @@ dtb-$(CONFIG_ARCH_EXYNOS4) += \
>> > exynos4210-trats.dtb \
>> > exynos4210-universal_c210.dtb \
>> > exynos4412-itop-elite.dtb \
>> > + exynos4412-m0.dtb \
>> > + exynos4412-m3.dtb \
>> > exynos4412-odroidu3.dtb \
>> > exynos4412-odroidx.dtb \
>> > exynos4412-odroidx2.dtb \
>> > exynos4412-origen.dtb \
>> > exynos4412-smdk4412.dtb \
>> > + exynos4412-t0.dtb \
>> > exynos4412-tiny4412.dtb \
>> > exynos4412-trats2.dtb
>> > dtb-$(CONFIG_ARCH_EXYNOS5) += \
>> > diff --git a/arch/arm/boot/dts/exynos4412-m0.dts b/arch/arm/boot/dts/exynos4412-m0.dts
>> > new file mode 100644
>> > index 000000000000..56c1ea6b5695
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/exynos4412-m0.dts
>> > @@ -0,0 +1,27 @@
>> > +/*
>> > + * Samsung's Exynos4412 based M0 (GT-I9300) board device tree source
>> > + *
>> > + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> > + * http://www.samsung.com
>> > + *
>> > + * Device tree source file for Samsung's M0 board which is based on
>> > + * Samsung's Exynos4412 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 "exynos4412-galaxy-s3.dtsi"
>> > +
>> > +/ {
>> > + model = "Samsung M0 (GT-I9300) based on Exynos4412";
>> > + compatible = "samsung,m0", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
>> > +
>> > + memory@40000000 {
>> > + device_type = "memory";
>> > + reg = <0x40000000 0x40000000>;
>>
>> I think each board has the same memory so maybe this can be made part
>> of midas.dtsi?
>
> T0 and M3 have 2GB of RAM, trats2/M0 have 1GB.
Ah, ok.
>
>>
>> > + };
>>
>> What about bootargs?
>
> Handled by the bootloader - to work around the proprietary bootloader not
> supporting device tree and requiring hacks to successfully boot a
> mainline kernel, i'm using kexec from a suitably patched kernel to load
> and boot the "real" kernel. (This also means one image can be used
> across all boards).
Could you document it in DTS why bootargs are missing?
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/4] ARM: dts: split trats2 DTS in preparation for midas boards
From: Krzysztof Kozlowski @ 2017-12-20 15:38 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Kukjin Kim, devicetree, Marek Szyprowski,
Bartłomiej Żołnierkiewicz
In-Reply-To: <20171220152713.GA23127@lineageos.org>
On Wed, Dec 20, 2017 at 4:27 PM, Simon Shields <simon@lineageos.org> wrote:
(...)
>> > @@ -68,17 +60,8 @@
>> > regulator-name = "CAM_SENSOR_A";
>> > regulator-min-microvolt = <2800000>;
>> > regulator-max-microvolt = <2800000>;
>> > - gpio = <&gpm0 2 GPIO_ACTIVE_HIGH>;
>> > - enable-active-high;
>> > - };
>> > -
>> > - lcd_vdd3_reg: voltage-regulator-2 {
>> > - compatible = "regulator-fixed";
>> > - regulator-name = "LCD_VDD_2.2V";
>> > - regulator-min-microvolt = <2200000>;
>> > - regulator-max-microvolt = <2200000>;
>> > - gpio = <&gpc0 1 GPIO_ACTIVE_HIGH>;
>> > enable-active-high;
>> > + status = "disabled";
>>
>> Why disabled?
>
> The GPIO which controls CAM_SENSOR_A differs between boards (gpm0-2 on
> s3, gpm0-7 on t0).
Hmm, okay, makes sense then.
>
>>
>> > };
>> >
>> > cam_af_reg: voltage-regulator-3 {
>> > @@ -86,17 +69,8 @@
>> > regulator-name = "CAM_AF";
>> > regulator-min-microvolt = <2800000>;
>> > regulator-max-microvolt = <2800000>;
>> > - gpio = <&gpm0 4 GPIO_ACTIVE_HIGH>;
>> > - enable-active-high;
>> > - };
>> > -
>> > - ps_als_reg: voltage-regulator-5 {
>> > - compatible = "regulator-fixed";
>> > - regulator-name = "LED_A_3.0V";
>> > - regulator-min-microvolt = <3000000>;
>> > - regulator-max-microvolt = <3000000>;
>> > - gpio = <&gpj0 5 GPIO_ACTIVE_HIGH>;
>> > enable-active-high;
>> > + status = "disabled";
>>
>> Why disabled?
>
> Same as above. gpm0-4 on s3, gpm1-1 on t0.
>>
>> > };
>> >
>> > vsil12: voltage-regulator-6 {
>> > @@ -227,37 +201,6 @@
>> > };
>> > };
>> >
>> > - i2c_ak8975: i2c-gpio-0 {
>> > - compatible = "i2c-gpio";
>> > - gpios = <&gpy2 4 GPIO_ACTIVE_HIGH>, <&gpy2 5 GPIO_ACTIVE_HIGH>;
>> > - i2c-gpio,delay-us = <2>;
>> > - #address-cells = <1>;
>> > - #size-cells = <0>;
>> > - status = "okay";
>> > -
>> > - ak8975@c {
>> > - compatible = "asahi-kasei,ak8975";
>> > - reg = <0x0c>;
>> > - gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
>> > - };
>> > - };
>> > -
>> > - i2c_cm36651: i2c-gpio-2 {
>> > - compatible = "i2c-gpio";
>> > - gpios = <&gpf0 0 GPIO_ACTIVE_LOW>, <&gpf0 1 GPIO_ACTIVE_LOW>;
>> > - i2c-gpio,delay-us = <2>;
>> > - #address-cells = <1>;
>> > - #size-cells = <0>;
>> > -
>> > - cm36651@18 {
>> > - compatible = "capella,cm36651";
>> > - reg = <0x18>;
>> > - interrupt-parent = <&gpx0>;
>> > - interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
>> > - vled-supply = <&ps_als_reg>;
>> > - };
>> > - };
>> > -
>> > i2c-mhl {
>> > compatible = "i2c-gpio";
>> > gpios = <&gpf0 4 GPIO_ACTIVE_HIGH>, <&gpf0 6 GPIO_ACTIVE_HIGH>;
>> > @@ -296,8 +239,6 @@
>> > <&clock CLK_MOUT_CAM1>;
>> > assigned-clock-parents = <&clock CLK_XUSBXTI>,
>> > <&clock CLK_XUSBXTI>;
>> > -
>> > -
>> > };
>> >
>> > wlan_pwrseq: sdhci3-pwrseq {
>> > @@ -454,36 +395,7 @@
>> > samsung,burst-clock-frequency = <500000000>;
>> > samsung,esc-clock-frequency = <20000000>;
>> > samsung,pll-clock-frequency = <24000000>;
>> > - status = "okay";
>> > -
>> > - panel@0 {
>> > - compatible = "samsung,s6e8aa0";
>> > - reg = <0>;
>> > - vdd3-supply = <&lcd_vdd3_reg>;
>> > - vci-supply = <&ldo25_reg>;
>> > - reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>;
>> > - power-on-delay= <50>;
>> > - reset-delay = <100>;
>> > - init-delay = <100>;
>> > - flip-horizontal;
>> > - flip-vertical;
>> > - panel-width-mm = <58>;
>> > - panel-height-mm = <103>;
>> > -
>> > - display-timings {
>> > - timing-0 {
>> > - clock-frequency = <57153600>;
>> > - hactive = <720>;
>> > - vactive = <1280>;
>> > - hfront-porch = <5>;
>> > - hback-porch = <5>;
>> > - hsync-len = <5>;
>> > - vfront-porch = <13>;
>> > - vback-porch = <1>;
>> > - vsync-len = <2>;
>> > - };
>> > - };
>> > - };
>> > + status = "disabled";
>>
>> It is already disabled by exynos4.dtsi, no need to duplicate properties.
>>
>> > };
>> >
>> > &exynos_usbphy {
>> > @@ -603,7 +515,7 @@
>> > samsung,i2c-max-bus-freq = <400000>;
>> > pinctrl-0 = <&i2c0_bus>;
>> > pinctrl-names = "default";
>> > - status = "okay";
>> > + status = "disabled";
>>
>> I do not get this node. It sits in midas.dtsi and s3.dtsi just enables
>> it. Why not enabling it here?
> Initially, I thought that T0 had some extra regulator that needed to be enabled,
> but in reality it's just a different vdda supply - so vdda should be
> moved down to galaxy-s3
Yes, please and then only for s5c73m3@3c. The i2c node should stay
enabled, I think.
>
>>
>> > s5c73m3@3c {
>> > compatible = "samsung,s5c73m3";
>> > @@ -635,18 +547,7 @@
>> > samsung,i2c-max-bus-freq = <400000>;
>> > pinctrl-0 = <&i2c3_bus>;
>> > pinctrl-names = "default";
>> > - status = "okay";
>> > -
>> > - mms114-touchscreen@48 {
>> > - compatible = "melfas,mms114";
>> > - reg = <0x48>;
>> > - interrupt-parent = <&gpm2>;
>> > - interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
>> > - x-size = <720>;
>> > - y-size = <1280>;
>> > - avdd-supply = <&ldo23_reg>;
>> > - vdd-supply = <&ldo24_reg>;
>> > - };
>> > + status = "disabled";
>> > };
>> >
>> > &i2c_4 {
>> > @@ -827,6 +728,7 @@
>> > regulator-name = "CAM_SENSOR_CORE_1.2V";
>> > regulator-min-microvolt = <1200000>;
>> > regulator-max-microvolt = <1200000>;
>> > + status = "okay";
>>
>> Regulator should not be disabled or enabled. It is not a device. I do
>> not get the logic behind...
>>
>> The ''status = disabled" usually is added in DTSI files to nodes which
>> are not fully configured at this point, e.g. they require external
>> resources (clocks, regulators). These external resources will be
>> provided when extending in DTS (or further DTSI) while enabling it.
>> However regulator has always all necessary resources.
>>
>
> Ack. This one shouldn't be here.
>
>> > };
>> >
>> > ldo18_reg: LDO18 {
>> > @@ -874,9 +776,7 @@
>> > };
>> >
>> > ldo25_reg: LDO25 {
>> > - regulator-name = "LCD_VCC_3.3V";
>> > - regulator-min-microvolt = <2800000>;
>> > - regulator-max-microvolt = <2800000>;
>> > + status = "disabled";
>>
>> Ditto.
>
> In this case, s3 and t0 have different regulator voltages/names
> (3.0V vs 2.8V), but it doesn't really seem to make sense to me
> to leave ldo25 out of the common dts altogether, since it's there on all
> boards. If you would prefer, I can remove ldo25 and leave it completely
> in the t0/s3 config files
So leave empty ldo25, like:
ldo25_reg: LDO25 {
regulator-name = "LDO25";
};
Something like buck8_reg in
arch/arm/boot/dts/exynos4412-odroid-common.dtsi. The point is to
provide entire description of max77686 regulators in basic DTSI. The
driver anyway knows the constraints (min/max voltages) so in case of
missing entries in DTS, default will be applied. Then in child-DTS you
can customize the voltage and/or name to necessary value.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] Input: mms114 - add support for mms152
From: Simon Shields @ 2017-12-20 15:38 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, devicetree, Andi Shyti, Simon Shields
In-Reply-To: <20171218124933.1803-1-simon@lineageos.org>
MMS152 has no configuration registers, but the packet format used in
interrupts is identical to mms114.
Signed-off-by: Simon Shields <simon@lineageos.org>
---
.../bindings/input/touchscreen/mms114.txt | 8 ++--
drivers/input/touchscreen/mms114.c | 53 +++++++++++++++++++---
include/linux/platform_data/mms114.h | 6 +++
3 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
index 89d4c56c5671..733411020ced 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
@@ -1,15 +1,15 @@
-* MELFAS MMS114 touchscreen controller
+* MELFAS MMS114/MMS152 touchscreen controller
Required properties:
-- compatible: must be "melfas,mms114"
+- compatible: "melfas,mms114" for MMS114, or "melfas,mms152" for MMS152
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
- x-size: horizontal resolution of touchscreen
- y-size: vertical resolution of touchscreen
Optional properties:
-- contact-threshold:
-- moving-threshold:
+- contact-threshold: only with "melfas,mms114"
+- moving-threshold: only with "melfas,mms114"
- x-invert: invert X axis
- y-invert: invert Y axis
diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c
index e5eeb6311f7d..9ecda193802b 100644
--- a/drivers/input/touchscreen/mms114.c
+++ b/drivers/input/touchscreen/mms114.c
@@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/i2c.h>
#include <linux/input/mt.h>
#include <linux/interrupt.h>
@@ -33,6 +34,9 @@
#define MMS114_INFOMATION 0x10
#define MMS114_TSP_REV 0xF0
+#define MMS152_FW_REV 0xE1
+#define MMS152_COMPAT_GROUP 0xF2
+
/* Minimum delay time is 50us between stop and start signal of i2c */
#define MMS114_I2C_DELAY 50
@@ -251,12 +255,27 @@ static int mms114_get_version(struct mms114_data *data)
u8 buf[6];
int error;
- error = __mms114_read_reg(data, MMS114_TSP_REV, 6, buf);
- if (error < 0)
- return error;
+ switch (data->pdata->type) {
+ case TYPE_MMS152:
+ error = __mms114_read_reg(data, MMS152_FW_REV, 3, buf);
+ if (error < 0)
+ return error;
+ buf[3] = i2c_smbus_read_byte_data(data->client,
+ MMS152_COMPAT_GROUP);
+ if (buf[3] < 0)
+ return buf[3];
+ dev_info(dev, "TSP FW Rev: bootloader 0x%x / core 0x%x / config 0x%x, Compat group: %c\n",
+ buf[0], buf[1], buf[2], buf[3]);
+ break;
+ case TYPE_MMS114:
+ error = __mms114_read_reg(data, MMS114_TSP_REV, 6, buf);
+ if (error < 0)
+ return error;
- dev_info(dev, "TSP Rev: 0x%x, HW Rev: 0x%x, Firmware Ver: 0x%x\n",
- buf[0], buf[1], buf[3]);
+ dev_info(dev, "TSP Rev: 0x%x, HW Rev: 0x%x, Firmware Ver: 0x%x\n",
+ buf[0], buf[1], buf[3]);
+ break;
+ }
return 0;
}
@@ -271,6 +290,10 @@ static int mms114_setup_regs(struct mms114_data *data)
if (error < 0)
return error;
+ /* MMS152 has no configuration or power on registers */
+ if (data->pdata->type == TYPE_MMS152)
+ return 0;
+
error = mms114_set_active(data, true);
if (error < 0)
return error;
@@ -391,6 +414,8 @@ static struct mms114_platform_data *mms114_parse_dt(struct device *dev)
return NULL;
}
+ pdata->type = (enum mms_type)of_device_get_match_data(dev);
+
if (of_property_read_u32(np, "x-size", &pdata->x_size)) {
dev_err(dev, "failed to get x-size property\n");
return NULL;
@@ -456,7 +481,15 @@ static int mms114_probe(struct i2c_client *client,
data->input_dev = input_dev;
data->pdata = pdata;
- input_dev->name = "MELFAS MMS114 Touchscreen";
+ switch (pdata->type) {
+ case TYPE_MMS114:
+ input_dev->name = "MELFAS MMS114 Touchscreen";
+ break;
+ case TYPE_MMS152:
+ input_dev->name = "MELFAS MMS152 Touchscreen";
+ break;
+ }
+
input_dev->id.bustype = BUS_I2C;
input_dev->dev.parent = &client->dev;
input_dev->open = mms114_input_open;
@@ -569,7 +602,13 @@ MODULE_DEVICE_TABLE(i2c, mms114_id);
#ifdef CONFIG_OF
static const struct of_device_id mms114_dt_match[] = {
- { .compatible = "melfas,mms114" },
+ {
+ .compatible = "melfas,mms114",
+ .data = (void *)TYPE_MMS114,
+ }, {
+ .compatible = "melfas,mms152",
+ .data = (void *)TYPE_MMS152,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, mms114_dt_match);
diff --git a/include/linux/platform_data/mms114.h b/include/linux/platform_data/mms114.h
index 5722ebfb2738..58e4c463bf0c 100644
--- a/include/linux/platform_data/mms114.h
+++ b/include/linux/platform_data/mms114.h
@@ -10,6 +10,11 @@
#ifndef __LINUX_MMS114_H
#define __LINUX_MMS114_H
+enum mms_type {
+ TYPE_MMS114,
+ TYPE_MMS152,
+};
+
struct mms114_platform_data {
unsigned int x_size;
unsigned int y_size;
@@ -17,6 +22,7 @@ struct mms114_platform_data {
unsigned int moving_threshold;
bool x_invert;
bool y_invert;
+ enum mms_type type;
void (*cfg_pin)(bool);
};
--
2.15.1
^ permalink raw reply related
* Re: [PATCH v3 3/4] ARM: dts: add Samsung's exynos4412-based midas boards
From: Simon Shields @ 2017-12-20 15:33 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc, Kukjin Kim, devicetree, Marek Szyprowski,
Bartłomiej Żołnierkiewicz
In-Reply-To: <CAJKOXPf4H6kSXJCSaVBPr9G1yNw9FjCUT+fox2V++Nyrco5bQA@mail.gmail.com>
Hi Krzysztof,
On Wed, Dec 20, 2017 at 03:08:27PM +0100, Krzysztof Kozlowski wrote:
> On Mon, Dec 18, 2017 at 1:38 PM, Simon Shields <simon@lineageos.org> wrote:
> > "midas" is the codename for a family of smartphones released by Samsung
> > Mobile. It includes the Galaxy S3 (GT-I9300/I9305) and the Galaxy
> > Note 2 (GT-N7100/N7105). The boards largely have the same peripherals:
> > the main differences are touchscreen, display panel and cellular modem.
> >
> > Signed-off-by: Simon Shields <simon@lineageos.org>
> > ---
> > arch/arm/boot/dts/Makefile | 3 +++
> > arch/arm/boot/dts/exynos4412-m0.dts | 27 +++++++++++++++++++++++++
> > arch/arm/boot/dts/exynos4412-m3.dts | 14 +++++++++++++
> > arch/arm/boot/dts/exynos4412-t0.dts | 40 +++++++++++++++++++++++++++++++++++++
> > 4 files changed, 84 insertions(+)
> > create mode 100644 arch/arm/boot/dts/exynos4412-m0.dts
> > create mode 100644 arch/arm/boot/dts/exynos4412-m3.dts
> > create mode 100644 arch/arm/boot/dts/exynos4412-t0.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 66e28af289da..035abd66b472 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -164,11 +164,14 @@ dtb-$(CONFIG_ARCH_EXYNOS4) += \
> > exynos4210-trats.dtb \
> > exynos4210-universal_c210.dtb \
> > exynos4412-itop-elite.dtb \
> > + exynos4412-m0.dtb \
> > + exynos4412-m3.dtb \
> > exynos4412-odroidu3.dtb \
> > exynos4412-odroidx.dtb \
> > exynos4412-odroidx2.dtb \
> > exynos4412-origen.dtb \
> > exynos4412-smdk4412.dtb \
> > + exynos4412-t0.dtb \
> > exynos4412-tiny4412.dtb \
> > exynos4412-trats2.dtb
> > dtb-$(CONFIG_ARCH_EXYNOS5) += \
> > diff --git a/arch/arm/boot/dts/exynos4412-m0.dts b/arch/arm/boot/dts/exynos4412-m0.dts
> > new file mode 100644
> > index 000000000000..56c1ea6b5695
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/exynos4412-m0.dts
> > @@ -0,0 +1,27 @@
> > +/*
> > + * Samsung's Exynos4412 based M0 (GT-I9300) board device tree source
> > + *
> > + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> > + * http://www.samsung.com
> > + *
> > + * Device tree source file for Samsung's M0 board which is based on
> > + * Samsung's Exynos4412 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 "exynos4412-galaxy-s3.dtsi"
> > +
> > +/ {
> > + model = "Samsung M0 (GT-I9300) based on Exynos4412";
> > + compatible = "samsung,m0", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
> > +
> > + memory@40000000 {
> > + device_type = "memory";
> > + reg = <0x40000000 0x40000000>;
>
> I think each board has the same memory so maybe this can be made part
> of midas.dtsi?
T0 and M3 have 2GB of RAM, trats2/M0 have 1GB.
>
> > + };
>
> What about bootargs?
Handled by the bootloader - to work around the proprietary bootloader not
supporting device tree and requiring hacks to successfully boot a
mainline kernel, i'm using kexec from a suitably patched kernel to load
and boot the "real" kernel. (This also means one image can be used
across all boards).
>
> > +
>
> Unneeded new line.
>
> > +};
> > diff --git a/arch/arm/boot/dts/exynos4412-m3.dts b/arch/arm/boot/dts/exynos4412-m3.dts
> > new file mode 100644
> > index 000000000000..80431044f07a
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/exynos4412-m3.dts
> > @@ -0,0 +1,14 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/dts-v1/;
> > +#include "exynos4412-galaxy-s3.dtsi"
> > +
> > +/ {
> > + model = "Samsung M3 (GT-I9305) based on Exynos4412";
> > + compatible = "samsung,m3", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
> > +
> > + memory@40000000 {
> > + device_type = "memory";
> > + reg = <0x40000000 0x80000000>;
> > + };
> > +
>
> Ditto
>
> > +};
> > diff --git a/arch/arm/boot/dts/exynos4412-t0.dts b/arch/arm/boot/dts/exynos4412-t0.dts
> > new file mode 100644
> > index 000000000000..1444e893fb0e
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/exynos4412-t0.dts
> > @@ -0,0 +1,40 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/dts-v1/;
> > +#include "exynos4412-midas.dtsi"
> > +
> > +/ {
> > + compatible = "samsung,t0", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
> > + model = "Samsung T0 (GT-N7100, GT-N7105) based on Exynos4412";
> > +
> > + memory@40000000 {
> > + device_type = "memory";
> > + reg = <0x40000000 0x80000000>;
> > + };
> > +};
> > +
> > +&buck9_reg {
> > + maxim,ena-gpios = <&gpm1 0 GPIO_ACTIVE_HIGH>;
> > + status = "okay";
> > +};
> > +
> > +&cam_io_reg {
> > + gpio = <&gpm0 7 GPIO_ACTIVE_HIGH>;
> > + status = "okay";
> > +};
> > +
> > +&cam_af_reg {
> > + gpio = <&gpm1 1 GPIO_ACTIVE_HIGH>;
> > + status = "okay";
> > +};
>
> Please but the cam nodes in alphabetical order.
>
> > +
> > +&ldo13_reg {
> > + regulator-name = "VCC_1.8V_LCD";
> > + regulator-always-on;
> > +};
> > +
> > +&ldo25_reg {
> > + regulator-name = "VCI_3.0V_LCD";
> > + regulator-min-microvolt = <3000000>;
> > + regulator-max-microvolt = <3000000>;
> > + status = "okay";
> > +};
> > --
> > 2.15.1
> >
Cheers,
Simon
^ permalink raw reply
* Re: [PATCH v3 2/4] ARM: dts: split trats2 DTS in preparation for midas boards
From: Simon Shields @ 2017-12-20 15:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc, Kukjin Kim, devicetree, Marek Szyprowski,
Bartłomiej Żołnierkiewicz
In-Reply-To: <CAJKOXPdzAvsaAOo6P+UA8VWYd7YjmtSqtkyKtNaz7jNdUXUH4A@mail.gmail.com>
Hi Krzysztof,
Thanks for the review.
On Wed, Dec 20, 2017 at 03:05:18PM +0100, Krzysztof Kozlowski wrote:
> On Mon, Dec 18, 2017 at 1:38 PM, Simon Shields <simon@lineageos.org> wrote:
> > The midas boards share a lot with trats2. Split the common parts
> > out of trats2 into a common midas dtsi and a common "galaxy s3" dts.
> >
> > Signed-off-by: Simon Shields <simon@lineageos.org>
> > ---
> > arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi | 145 ++
> > ...exynos4412-trats2.dts => exynos4412-midas.dtsi} | 117 +-
> > arch/arm/boot/dts/exynos4412-trats2.dts | 1446 +-------------------
> > 3 files changed, 184 insertions(+), 1524 deletions(-)
> > create mode 100644 arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> > copy arch/arm/boot/dts/{exynos4412-trats2.dts => exynos4412-midas.dtsi} (92%)
> > rewrite arch/arm/boot/dts/exynos4412-trats2.dts (97%)
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> > new file mode 100644
> > index 000000000000..2806236484a6
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> > @@ -0,0 +1,145 @@
> > +/*
> > + * Samsung's Exynos4412 based Galaxy S3 board device tree source
> > + *
> > + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> > + * http://www.samsung.com
> > + *
> > + * Device tree source file for Samsung's Galaxy S3 boards which are based on
> > + * Samsung's Exynos4412 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.
> > + */
>
> One new line to make it consistent with others.
>
> > +/dts-v1/;
> > +#include "exynos4412-midas.dtsi"
> > +
> > +/ {
> > + aliases {
> > + i2c9 = &i2c_ak8975;
> > + i2c10 = &i2c_cm36651;
> > + };
> > +
> > + regulators {
> > + lcd_vdd3_reg: voltage-regulator-2 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "LCD_VDD_2.2V";
> > + regulator-min-microvolt = <2200000>;
> > + regulator-max-microvolt = <2200000>;
> > + gpio = <&gpc0 1 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > + ps_als_reg: voltage-regulator-5 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "LED_A_3.0V";
> > + regulator-min-microvolt = <3000000>;
> > + regulator-max-microvolt = <3000000>;
> > + gpio = <&gpj0 5 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > + };
> > +
> > + i2c_ak8975: i2c-gpio-0 {
> > + compatible = "i2c-gpio";
> > + gpios = <&gpy2 4 GPIO_ACTIVE_HIGH>, <&gpy2 5 GPIO_ACTIVE_HIGH>;
> > + i2c-gpio,delay-us = <2>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "okay";
> > +
> > + ak8975@c {
> > + compatible = "asahi-kasei,ak8975";
> > + reg = <0x0c>;
> > + gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
> > + };
> > + };
> > +
> > + i2c_cm36651: i2c-gpio-2 {
> > + compatible = "i2c-gpio";
> > + gpios = <&gpf0 0 GPIO_ACTIVE_LOW>, <&gpf0 1 GPIO_ACTIVE_LOW>;
> > + i2c-gpio,delay-us = <2>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cm36651@18 {
> > + compatible = "capella,cm36651";
> > + reg = <0x18>;
> > + interrupt-parent = <&gpx0>;
> > + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> > + vled-supply = <&ps_als_reg>;
> > + };
> > + };
> > +};
> > +
> > +&buck9_reg {
> > + maxim,ena-gpios = <&gpm0 3 GPIO_ACTIVE_HIGH>;
> > +};
> > +
> > +&cam_af_reg {
> > + gpio = <&gpm0 4 GPIO_ACTIVE_HIGH>;
> > + status = "okay";
> > +};
> > +
> > +&cam_io_reg {
> > + gpio = <&gpm0 2 GPIO_ACTIVE_HIGH>;
> > + status = "okay";
> > +};
> > +
> > +&dsi_0 {
> > + status = "okay";
>
> One new line.
>
> > + panel@0 {
> > + compatible = "samsung,s6e8aa0";
> > + reg = <0>;
> > + vdd3-supply = <&lcd_vdd3_reg>;
> > + vci-supply = <&ldo25_reg>;
> > + reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>;
> > + power-on-delay= <50>;
> > + reset-delay = <100>;
> > + init-delay = <100>;
> > + flip-horizontal;
> > + flip-vertical;
> > + panel-width-mm = <58>;
> > + panel-height-mm = <103>;
> > +
> > + display-timings {
> > + timing-0 {
> > + clock-frequency = <57153600>;
> > + hactive = <720>;
> > + vactive = <1280>;
> > + hfront-porch = <5>;
> > + hback-porch = <5>;
> > + hsync-len = <5>;
> > + vfront-porch = <13>;
> > + vback-porch = <1>;
> > + vsync-len = <2>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&i2c_0 {
> > + status = "okay";
> > +};
> > +
> > +&i2c_3 {
> > + status = "okay";
> > +
> > + mms114-touchscreen@48 {
> > + compatible = "melfas,mms114";
> > + reg = <0x48>;
> > + interrupt-parent = <&gpm2>;
> > + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> > + x-size = <720>;
> > + y-size = <1280>;
> > + avdd-supply = <&ldo23_reg>;
> > + vdd-supply = <&ldo24_reg>;
> > + };
> > +};
> > +
> > +&ldo25_reg {
> > + regulator-name = "LCD_VCC_3.3V";
> > + regulator-min-microvolt = <2800000>;
> > + regulator-max-microvolt = <2800000>;
> > + status = "okay";
> > +};
> > diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-midas.dtsi
> > similarity index 92%
> > copy from arch/arm/boot/dts/exynos4412-trats2.dts
> > copy to arch/arm/boot/dts/exynos4412-midas.dtsi
> > index f285790e8e04..384767a34fa7 100644
> > --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> > +++ b/arch/arm/boot/dts/exynos4412-midas.dtsi
> > @@ -10,7 +10,7 @@
> > * 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 "exynos4412.dtsi"
> > @@ -25,19 +25,11 @@
> > compatible = "samsung,trats2", "samsung,exynos4412", "samsung,exynos4";
>
> This looks incorrect. Not every midas board is trats2... Unless that
> was left here for compatibility purpose but then it would be good to
> see explanation.
>
Yes, this was my mistake. Will fix in v3.
> >
> > aliases {
> > - i2c9 = &i2c_ak8975;
> > - i2c10 = &i2c_cm36651;
> > i2c11 = &i2c_max77693;
> > i2c12 = &i2c_max77693_fuel;
> > };
> >
> > - memory@40000000 {
> > - device_type = "memory";
> > - reg = <0x40000000 0x40000000>;
> > - };
> > -
> > chosen {
> > - bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rootwait earlyprintk panic=5";
> > stdout-path = &serial_2;
> > };
> >
> > @@ -68,17 +60,8 @@
> > regulator-name = "CAM_SENSOR_A";
> > regulator-min-microvolt = <2800000>;
> > regulator-max-microvolt = <2800000>;
> > - gpio = <&gpm0 2 GPIO_ACTIVE_HIGH>;
> > - enable-active-high;
> > - };
> > -
> > - lcd_vdd3_reg: voltage-regulator-2 {
> > - compatible = "regulator-fixed";
> > - regulator-name = "LCD_VDD_2.2V";
> > - regulator-min-microvolt = <2200000>;
> > - regulator-max-microvolt = <2200000>;
> > - gpio = <&gpc0 1 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > + status = "disabled";
>
> Why disabled?
The GPIO which controls CAM_SENSOR_A differs between boards (gpm0-2 on
s3, gpm0-7 on t0).
>
> > };
> >
> > cam_af_reg: voltage-regulator-3 {
> > @@ -86,17 +69,8 @@
> > regulator-name = "CAM_AF";
> > regulator-min-microvolt = <2800000>;
> > regulator-max-microvolt = <2800000>;
> > - gpio = <&gpm0 4 GPIO_ACTIVE_HIGH>;
> > - enable-active-high;
> > - };
> > -
> > - ps_als_reg: voltage-regulator-5 {
> > - compatible = "regulator-fixed";
> > - regulator-name = "LED_A_3.0V";
> > - regulator-min-microvolt = <3000000>;
> > - regulator-max-microvolt = <3000000>;
> > - gpio = <&gpj0 5 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > + status = "disabled";
>
> Why disabled?
Same as above. gpm0-4 on s3, gpm1-1 on t0.
>
> > };
> >
> > vsil12: voltage-regulator-6 {
> > @@ -227,37 +201,6 @@
> > };
> > };
> >
> > - i2c_ak8975: i2c-gpio-0 {
> > - compatible = "i2c-gpio";
> > - gpios = <&gpy2 4 GPIO_ACTIVE_HIGH>, <&gpy2 5 GPIO_ACTIVE_HIGH>;
> > - i2c-gpio,delay-us = <2>;
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > - status = "okay";
> > -
> > - ak8975@c {
> > - compatible = "asahi-kasei,ak8975";
> > - reg = <0x0c>;
> > - gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
> > - };
> > - };
> > -
> > - i2c_cm36651: i2c-gpio-2 {
> > - compatible = "i2c-gpio";
> > - gpios = <&gpf0 0 GPIO_ACTIVE_LOW>, <&gpf0 1 GPIO_ACTIVE_LOW>;
> > - i2c-gpio,delay-us = <2>;
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > -
> > - cm36651@18 {
> > - compatible = "capella,cm36651";
> > - reg = <0x18>;
> > - interrupt-parent = <&gpx0>;
> > - interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> > - vled-supply = <&ps_als_reg>;
> > - };
> > - };
> > -
> > i2c-mhl {
> > compatible = "i2c-gpio";
> > gpios = <&gpf0 4 GPIO_ACTIVE_HIGH>, <&gpf0 6 GPIO_ACTIVE_HIGH>;
> > @@ -296,8 +239,6 @@
> > <&clock CLK_MOUT_CAM1>;
> > assigned-clock-parents = <&clock CLK_XUSBXTI>,
> > <&clock CLK_XUSBXTI>;
> > -
> > -
> > };
> >
> > wlan_pwrseq: sdhci3-pwrseq {
> > @@ -454,36 +395,7 @@
> > samsung,burst-clock-frequency = <500000000>;
> > samsung,esc-clock-frequency = <20000000>;
> > samsung,pll-clock-frequency = <24000000>;
> > - status = "okay";
> > -
> > - panel@0 {
> > - compatible = "samsung,s6e8aa0";
> > - reg = <0>;
> > - vdd3-supply = <&lcd_vdd3_reg>;
> > - vci-supply = <&ldo25_reg>;
> > - reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>;
> > - power-on-delay= <50>;
> > - reset-delay = <100>;
> > - init-delay = <100>;
> > - flip-horizontal;
> > - flip-vertical;
> > - panel-width-mm = <58>;
> > - panel-height-mm = <103>;
> > -
> > - display-timings {
> > - timing-0 {
> > - clock-frequency = <57153600>;
> > - hactive = <720>;
> > - vactive = <1280>;
> > - hfront-porch = <5>;
> > - hback-porch = <5>;
> > - hsync-len = <5>;
> > - vfront-porch = <13>;
> > - vback-porch = <1>;
> > - vsync-len = <2>;
> > - };
> > - };
> > - };
> > + status = "disabled";
>
> It is already disabled by exynos4.dtsi, no need to duplicate properties.
>
> > };
> >
> > &exynos_usbphy {
> > @@ -603,7 +515,7 @@
> > samsung,i2c-max-bus-freq = <400000>;
> > pinctrl-0 = <&i2c0_bus>;
> > pinctrl-names = "default";
> > - status = "okay";
> > + status = "disabled";
>
> I do not get this node. It sits in midas.dtsi and s3.dtsi just enables
> it. Why not enabling it here?
Initially, I thought that T0 had some extra regulator that needed to be enabled,
but in reality it's just a different vdda supply - so vdda should be
moved down to galaxy-s3
>
> > s5c73m3@3c {
> > compatible = "samsung,s5c73m3";
> > @@ -635,18 +547,7 @@
> > samsung,i2c-max-bus-freq = <400000>;
> > pinctrl-0 = <&i2c3_bus>;
> > pinctrl-names = "default";
> > - status = "okay";
> > -
> > - mms114-touchscreen@48 {
> > - compatible = "melfas,mms114";
> > - reg = <0x48>;
> > - interrupt-parent = <&gpm2>;
> > - interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> > - x-size = <720>;
> > - y-size = <1280>;
> > - avdd-supply = <&ldo23_reg>;
> > - vdd-supply = <&ldo24_reg>;
> > - };
> > + status = "disabled";
> > };
> >
> > &i2c_4 {
> > @@ -827,6 +728,7 @@
> > regulator-name = "CAM_SENSOR_CORE_1.2V";
> > regulator-min-microvolt = <1200000>;
> > regulator-max-microvolt = <1200000>;
> > + status = "okay";
>
> Regulator should not be disabled or enabled. It is not a device. I do
> not get the logic behind...
>
> The ''status = disabled" usually is added in DTSI files to nodes which
> are not fully configured at this point, e.g. they require external
> resources (clocks, regulators). These external resources will be
> provided when extending in DTS (or further DTSI) while enabling it.
> However regulator has always all necessary resources.
>
Ack. This one shouldn't be here.
> > };
> >
> > ldo18_reg: LDO18 {
> > @@ -874,9 +776,7 @@
> > };
> >
> > ldo25_reg: LDO25 {
> > - regulator-name = "LCD_VCC_3.3V";
> > - regulator-min-microvolt = <2800000>;
> > - regulator-max-microvolt = <2800000>;
> > + status = "disabled";
>
> Ditto.
In this case, s3 and t0 have different regulator voltages/names
(3.0V vs 2.8V), but it doesn't really seem to make sense to me
to leave ldo25 out of the common dts altogether, since it's there on all
boards. If you would prefer, I can remove ldo25 and leave it completely
in the t0/s3 config files
>
> Best regards,
> Krzysztof
Cheers,
Simon
^ permalink raw reply
* Re: [PATCH v2 01/11] ARM: dts: imx53: Move nodes which have no reg property out of bus
From: Shawn Guo @ 2017-12-20 15:13 UTC (permalink / raw)
To: Fabio Estevam
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Fabio Estevam
In-Reply-To: <1511981684-13433-1-git-send-email-festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Nov 29, 2017 at 04:54:34PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>
> Move pmu, usbphy0 and usbphy1 nodes from soc node to root node.
>
> The nodes that have been moved do not have any register properties and thus
> shouldn't be placed on the bus.
>
> This fixes the following build warnings with W=1:
>
> arch/arm/boot/dts/imx53-ard.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
> arch/arm/boot/dts/imx53-ard.dtb: Warning (simple_bus_reg): Node /soc/aips@50000000/usbphy-0 missing or empty reg/ranges property
> arch/arm/boot/dts/imx53-ard.dtb: Warning (simple_bus_reg): Node /soc/aips@50000000/usbphy-1 missing or empty reg/ranges property
> arch/arm/boot/dts/imx53-ard.dtb: Warning (simple_bus_reg): Node /soc/pmu missing or empty reg/ranges property
>
> Based on a patch from Simon Horman for r8a7795.dtsi.
>
> Signed-off-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Applied all, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/2] eeprom: at24: write-protect pin support
From: Bartosz Golaszewski @ 2017-12-20 15:05 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rob Herring, Mark Rutland, Linus Walleij, Peter Rosin, linux-i2c,
devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <CAHp75VfjP64o8iqMRn-XOththnL=Wm+jMF++q+ic0zpR3T0EKw@mail.gmail.com>
2017-12-20 16:00 GMT+01:00 Andy Shevchenko <andy.shevchenko@gmail.com>:
> On Wed, Dec 20, 2017 at 2:41 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>> 2017-12-20 11:21 GMT+01:00 Andy Shevchenko <andy.shevchenko@gmail.com>:
>>> On Wed, Dec 20, 2017 at 10:26 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>> AT24 EEPROMs have a write-protect pin, which - when pulled high -
>>>> inhibits writes to the upper quadrant of memory (although it has been
>>>> observed that on some chips it disables writing to the entire memory
>>>> range).
>>>>
>>>> On some boards, this pin is connected to a GPIO and pulled high by
>>>> default, which forces the user to manually change its state before
>>>> writing. On linux this means that we either need to hog the line all
>>>> the time, or set the GPIO value before writing from outside of the
>>>> at24 driver.
>>>>
>>>> This series adds support for the write-protect pin split into two
>>>> parts. The first patch extends the relevant binding document, while
>>>> the second modifies the at24 code to pull the write-protect GPIO
>>>> low (if present) during write operations.
>>>>
>>>
>>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>>>
>>> A one totally minor nit: if it possible now to have one line where
>>> devm_gpiod_get_optional() is called?
>>> You may ignore this nit anyway.
>>>
>>
>> Hi Andy,
>>
>> I'm afraid I don't understand what you mean here. I do use
>> devm_gpiod_get_optional() in patch 2/2.
>
> I meant to do something like
> ...->wp_gpio = devm_gpiod_get_optional(...);
> if (IS_ERR(...))
> return ...;
>
> So, note that the first is occupied only one line.
>
> --
> With Best Regards,
> Andy Shevchenko
Oh, now I get it.
It doesn't fit into 80 characters if we use &client->dev as the first
argument, but I see that client->dev is used extensively in probe() so
we could probably use a separate struct device *dev helper variable
for that. I'll note it for future refactoring that will happen soon. I
prefer that this patch stays as it is though.
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v2 0/2] eeprom: at24: write-protect pin support
From: Andy Shevchenko @ 2017-12-20 15:00 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Rob Herring, Mark Rutland, Linus Walleij, Peter Rosin, linux-i2c,
devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <CAMRc=Mej4SVZwSNqObgMfzgnc9mOFHi5GLTVKGW4Lp3n_Q-bvA@mail.gmail.com>
On Wed, Dec 20, 2017 at 2:41 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> 2017-12-20 11:21 GMT+01:00 Andy Shevchenko <andy.shevchenko@gmail.com>:
>> On Wed, Dec 20, 2017 at 10:26 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>> AT24 EEPROMs have a write-protect pin, which - when pulled high -
>>> inhibits writes to the upper quadrant of memory (although it has been
>>> observed that on some chips it disables writing to the entire memory
>>> range).
>>>
>>> On some boards, this pin is connected to a GPIO and pulled high by
>>> default, which forces the user to manually change its state before
>>> writing. On linux this means that we either need to hog the line all
>>> the time, or set the GPIO value before writing from outside of the
>>> at24 driver.
>>>
>>> This series adds support for the write-protect pin split into two
>>> parts. The first patch extends the relevant binding document, while
>>> the second modifies the at24 code to pull the write-protect GPIO
>>> low (if present) during write operations.
>>>
>>
>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>>
>> A one totally minor nit: if it possible now to have one line where
>> devm_gpiod_get_optional() is called?
>> You may ignore this nit anyway.
>>
>
> Hi Andy,
>
> I'm afraid I don't understand what you mean here. I do use
> devm_gpiod_get_optional() in patch 2/2.
I meant to do something like
...->wp_gpio = devm_gpiod_get_optional(...);
if (IS_ERR(...))
return ...;
So, note that the first is occupied only one line.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 4/4] arm64: dts: mediatek: add mt2712 cpufreq related device nodes
From: Matthias Brugger @ 2017-12-20 14:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, Andrew-sh Cheng, mark.rutland-5wv7dgnIgG8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <7730089.t6jDuHQEn5-yvgW3jdyMHm1GS7QM15AGw@public.gmane.org>
On 12/17/2017 07:05 PM, Rafael J. Wysocki wrote:
> On Tuesday, December 12, 2017 10:34:42 AM CET Matthias Brugger wrote:
>> Hi,
>>
>> On 12/12/2017 08:26 AM, Viresh Kumar wrote:
>>> On 12-12-17, 02:17, Rafael J. Wysocki wrote:
>>>> On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
>>>>> On 08-12-17, 14:07, Andrew-sh Cheng wrote:
>>>>>> Add opp v2 information,
>>>>>> and also add clocks, regulators and opp information into cpu nodes
>>>>>>
>>>>>> Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>> ---
>>>>>> arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++++++++++++++
>>>>>> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 57 +++++++++++++++++++++++++++++
>>>>>> 2 files changed, 84 insertions(+)
>>>>>
>>>>> Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>
>>>> Of course, DT bindings require ACKs from DT maintainers to be applied.
>>>
>>> I didn't knew that we need Acks from DT maintainers for dts files as well? Yeah,
>>> its very much required while defining new bindings for sure.
>>>
>>
>> I will take the dts parts through the Mediatek SoC tree, so you don't have to
>> worry about them.
>>
>> Please let me know when you take patch 1 and 2.
>
> Applied now, thanks!
>
> Do you need the branch containing them to be exposed?
>
No, that's not necessary.
I pushed the two patches to v4.15-next/dts64 now.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v10 2/3] dt-bindings: iio: temperature: add MLX90632 device bindings
From: Crt Mori @ 2017-12-20 14:20 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Crt Mori
Add device tree bindings for MLX90632 IR temperature sensor.
Signed-off-by: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../bindings/iio/temperature/mlx90632.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
new file mode 100644
index 000000000000..0b05812001f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
@@ -0,0 +1,28 @@
+* Melexis MLX90632 contactless Infra Red temperature sensor
+
+Link to datasheet: https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90632
+
+There are various applications for the Infra Red contactless temperature sensor
+and MLX90632 is most suitable for consumer applications where measured object
+temperature is in range between -20 to 200 degrees Celsius with relative error
+of measurement below 1 degree Celsius in object temperature range for
+industrial applications. Since it can operate and measure ambient temperature
+in range of -20 to 85 degrees Celsius it is suitable also for outdoor use.
+
+Be aware that electronics surrounding the sensor can increase ambient
+temperature. MLX90632 can be calibrated to reduce the housing effect via
+already existing EEPROM parameters.
+
+Since measured object emissivity effects Infra Red energy emitted, emissivity
+should be set before requesting the object temperature.
+
+Required properties:
+ - compatible: should be "melexis,mlx90632"
+ - reg: the I2C address of the sensor (default 0x3a)
+
+Example:
+
+mlx90632@3a {
+ compatible = "melexis,mlx90632";
+ reg = <0x3a>;
+};
--
2.15.0
^ permalink raw reply related
* Re: [RFC PATCH 09/12] mmc: sdhci: Use software timer when timeout greater than hardware capablility
From: Adrian Hunter @ 2017-12-20 14:11 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Ulf Hansson, Rob Herring, Tony Lindgren
Cc: Mark Rutland, Russell King, linux-mmc, devicetree, linux-kernel,
linux-omap, linux-arm-kernel, nsekhar
In-Reply-To: <20171214130941.26666-10-kishon@ti.com>
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> Errata i834 in AM572x Sitara Processors Silicon Revision 2.0, 1.1
> (SPRZ429K July 2014–Revised March 2017 [1]) mentions
> Under high speed HS200 and SDR104 modes, the functional clock for MMC
> modules will reach up to 192 MHz. At this frequency, the maximum obtainable
> timeout (DTO = 0xE) through MMC host controller is (1/192MHz)*2^27 = 700ms.
> Commands taking longer than 700ms may be affected by this small window
> frame. Workaround for this errata is use a software timer instead of
> hardware timer to provide the delay requested by the upper layer.
>
> While this errata is specific to AM572x, it is applicable to all sdhci
> based controllers when a particular request require timeout greater
> than hardware capability.
It doesn't work for our controllers. Even if the data timeout interrupt is
disabled, it seems like the timeout still "happens" in some fashion - after
which the host controller starts misbehaving.
So you will need to add a quirk.
>
> Re-use the software timer already implemented in sdhci to program the
> correct timeout value and also disable the hardware timeout when
> the required timeout is greater than hardware capabiltiy in order to
> avoid spurious timeout interrupts.
>
> This patch is based on the earlier patch implemented for omap_hsmmc [2]
>
> [1] -> http://www.ti.com/lit/er/sprz429k/sprz429k.pdf
> [2] -> https://patchwork.kernel.org/patch/9791449/
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/mmc/host/sdhci.c | 41 +++++++++++++++++++++++++++++++++++++++--
> drivers/mmc/host/sdhci.h | 11 +++++++++++
> 2 files changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index e9290a3439d5..d0655e1d2cc7 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -673,6 +673,27 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
> }
> }
>
> +static void sdhci_calc_sw_timeout(struct sdhci_host *host,
> + struct mmc_command *cmd,
> + unsigned int target_timeout)
> +{
> + struct mmc_host *mmc = host->mmc;
> + struct mmc_ios *ios = &mmc->ios;
> + struct mmc_data *data = cmd->data;
> + unsigned long long transfer_time;
> +
> + if (data) {
> + transfer_time = MMC_BLOCK_TRANSFER_TIME_MS(data->blksz,
> + ios->bus_width,
> + ios->clock);
If it has a value, actual_clock is better than ios->clock.
> + /* calculate timeout for the entire data */
> + host->data_timeout = (data->blocks * (target_timeout +
> + transfer_time));
> + } else if (cmd->flags & MMC_RSP_BUSY) {
> + host->data_timeout = cmd->busy_timeout * MSEC_PER_SEC;
Doesn't need MSEC_PER_SEC multiplier.
> + }
> +}
> +
> static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
> {
> u8 count;
> @@ -732,8 +753,12 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
> }
>
> if (count >= 0xF) {
> - DBG("Too large timeout 0x%x requested for CMD%d!\n",
> - count, cmd->opcode);
> + DBG("Too large timeout.. using SW timeout for CMD%d!\n",
> + cmd->opcode);
> + sdhci_calc_sw_timeout(host, cmd, target_timeout);
> + host->ier &= ~SDHCI_INT_DATA_TIMEOUT;
> + sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
> count = 0xE;
> }
>
> @@ -1198,6 +1223,14 @@ static void sdhci_finish_command(struct sdhci_host *host)
> {
> struct mmc_command *cmd = host->cmd;
>
> + if (host->data_timeout) {
> + unsigned long timeout;
> +
> + timeout = jiffies +
> + msecs_to_jiffies(host->data_timeout);
> + sdhci_mod_timer(host, host->cmd->mrq, timeout);
cmd could be the sbc or a stop cmd or a command during transfer, so this
needs more logic.
> + }
> +
> host->cmd = NULL;
>
> if (cmd->flags & MMC_RSP_PRESENT) {
> @@ -2341,6 +2374,10 @@ static bool sdhci_request_done(struct sdhci_host *host)
> return true;
> }
>
> + host->data_timeout = 0;
> + host->ier |= SDHCI_INT_DATA_TIMEOUT;
> + sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
> + sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
sdhci can have 2 requests in progress to allow for commands to be sent while
a data transfer is in progress, so this is not necessarily the data transfer
request that is done. Also we want to avoid unnecessary register writes.
> sdhci_del_timer(host, mrq);
>
> /*
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 54bc444c317f..e6e0278bea1a 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -332,6 +332,15 @@ struct sdhci_adma2_64_desc {
> /* Allow for a a command request and a data request at the same time */
> #define SDHCI_MAX_MRQS 2
>
> +/*
> + * Time taken for transferring one block. It is multiplied by a constant
> + * factor '2' to account for any errors
> + */
> +#define MMC_BLOCK_TRANSFER_TIME_MS(blksz, bus_width, freq) \
> + ((unsigned long long) \
> + (2 * (((blksz) * MSEC_PER_SEC * \
> + (8 / (bus_width))) / (freq))))
I don't think the macro helps make the code more readable. Might just as
well write a nice function to calculate the entire data request timeout.
> +
> enum sdhci_cookie {
> COOKIE_UNMAPPED,
> COOKIE_PRE_MAPPED, /* mapped by sdhci_pre_req() */
> @@ -546,6 +555,8 @@ struct sdhci_host {
> /* Host SDMA buffer boundary. */
> u32 sdma_boundary;
>
> + unsigned long long data_timeout;
msecs_to_jiffies() will truncate to 'unsigned int' anyway, so this might as
well be 'unsigned int'.
> +
> unsigned long private[0] ____cacheline_aligned;
> };
>
>
^ permalink raw reply
* Re: [PATCH v2 4/6] ARM: dts: imx6: Add support for phxBOARD-Mira i.MX 6 DualLight/Solo RDK
From: Lothar Waßmann @ 2017-12-20 14:10 UTC (permalink / raw)
To: Stefan Riedmueller
Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Christian Hemp, Stefan Christ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513776567-30182-5-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
Hi,
On Wed, 20 Dec 2017 14:29:25 +0100 Stefan Riedmueller wrote:
> From: Christian Hemp <c.hemp-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
>
> Add support for the PHYTEC phyBOARD-Mira Low-Cost Rapid Development Kit
> with i.MX 6DualLight/Solo with NAND.
>
s/phxBOARD/phyBOARD/ in the subject line.
Lothar Waßmann
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/4] ARM: dts: add Samsung's exynos4412-based midas boards
From: Krzysztof Kozlowski @ 2017-12-20 14:08 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Kukjin Kim, devicetree, Marek Szyprowski,
Bartłomiej Żołnierkiewicz
In-Reply-To: <20171218123805.26345-4-simon@lineageos.org>
On Mon, Dec 18, 2017 at 1:38 PM, Simon Shields <simon@lineageos.org> wrote:
> "midas" is the codename for a family of smartphones released by Samsung
> Mobile. It includes the Galaxy S3 (GT-I9300/I9305) and the Galaxy
> Note 2 (GT-N7100/N7105). The boards largely have the same peripherals:
> the main differences are touchscreen, display panel and cellular modem.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/Makefile | 3 +++
> arch/arm/boot/dts/exynos4412-m0.dts | 27 +++++++++++++++++++++++++
> arch/arm/boot/dts/exynos4412-m3.dts | 14 +++++++++++++
> arch/arm/boot/dts/exynos4412-t0.dts | 40 +++++++++++++++++++++++++++++++++++++
> 4 files changed, 84 insertions(+)
> create mode 100644 arch/arm/boot/dts/exynos4412-m0.dts
> create mode 100644 arch/arm/boot/dts/exynos4412-m3.dts
> create mode 100644 arch/arm/boot/dts/exynos4412-t0.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 66e28af289da..035abd66b472 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -164,11 +164,14 @@ dtb-$(CONFIG_ARCH_EXYNOS4) += \
> exynos4210-trats.dtb \
> exynos4210-universal_c210.dtb \
> exynos4412-itop-elite.dtb \
> + exynos4412-m0.dtb \
> + exynos4412-m3.dtb \
> exynos4412-odroidu3.dtb \
> exynos4412-odroidx.dtb \
> exynos4412-odroidx2.dtb \
> exynos4412-origen.dtb \
> exynos4412-smdk4412.dtb \
> + exynos4412-t0.dtb \
> exynos4412-tiny4412.dtb \
> exynos4412-trats2.dtb
> dtb-$(CONFIG_ARCH_EXYNOS5) += \
> diff --git a/arch/arm/boot/dts/exynos4412-m0.dts b/arch/arm/boot/dts/exynos4412-m0.dts
> new file mode 100644
> index 000000000000..56c1ea6b5695
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4412-m0.dts
> @@ -0,0 +1,27 @@
> +/*
> + * Samsung's Exynos4412 based M0 (GT-I9300) board device tree source
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Device tree source file for Samsung's M0 board which is based on
> + * Samsung's Exynos4412 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 "exynos4412-galaxy-s3.dtsi"
> +
> +/ {
> + model = "Samsung M0 (GT-I9300) based on Exynos4412";
> + compatible = "samsung,m0", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
> +
> + memory@40000000 {
> + device_type = "memory";
> + reg = <0x40000000 0x40000000>;
I think each board has the same memory so maybe this can be made part
of midas.dtsi?
> + };
What about bootargs?
> +
Unneeded new line.
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-m3.dts b/arch/arm/boot/dts/exynos4412-m3.dts
> new file mode 100644
> index 000000000000..80431044f07a
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4412-m3.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +#include "exynos4412-galaxy-s3.dtsi"
> +
> +/ {
> + model = "Samsung M3 (GT-I9305) based on Exynos4412";
> + compatible = "samsung,m3", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
> +
> + memory@40000000 {
> + device_type = "memory";
> + reg = <0x40000000 0x80000000>;
> + };
> +
Ditto
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-t0.dts b/arch/arm/boot/dts/exynos4412-t0.dts
> new file mode 100644
> index 000000000000..1444e893fb0e
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4412-t0.dts
> @@ -0,0 +1,40 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/dts-v1/;
> +#include "exynos4412-midas.dtsi"
> +
> +/ {
> + compatible = "samsung,t0", "samsung,midas", "samsung,exynos4412", "samsung,exynos4";
> + model = "Samsung T0 (GT-N7100, GT-N7105) based on Exynos4412";
> +
> + memory@40000000 {
> + device_type = "memory";
> + reg = <0x40000000 0x80000000>;
> + };
> +};
> +
> +&buck9_reg {
> + maxim,ena-gpios = <&gpm1 0 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> +
> +&cam_io_reg {
> + gpio = <&gpm0 7 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> +
> +&cam_af_reg {
> + gpio = <&gpm1 1 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
Please but the cam nodes in alphabetical order.
> +
> +&ldo13_reg {
> + regulator-name = "VCC_1.8V_LCD";
> + regulator-always-on;
> +};
> +
> +&ldo25_reg {
> + regulator-name = "VCI_3.0V_LCD";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + status = "okay";
> +};
> --
> 2.15.1
>
^ permalink raw reply
* Re: [PATCH v3 2/4] ARM: dts: split trats2 DTS in preparation for midas boards
From: Krzysztof Kozlowski @ 2017-12-20 14:05 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Kukjin Kim, devicetree, Marek Szyprowski,
Bartłomiej Żołnierkiewicz
In-Reply-To: <20171218123805.26345-3-simon@lineageos.org>
On Mon, Dec 18, 2017 at 1:38 PM, Simon Shields <simon@lineageos.org> wrote:
> The midas boards share a lot with trats2. Split the common parts
> out of trats2 into a common midas dtsi and a common "galaxy s3" dts.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi | 145 ++
> ...exynos4412-trats2.dts => exynos4412-midas.dtsi} | 117 +-
> arch/arm/boot/dts/exynos4412-trats2.dts | 1446 +-------------------
> 3 files changed, 184 insertions(+), 1524 deletions(-)
> create mode 100644 arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> copy arch/arm/boot/dts/{exynos4412-trats2.dts => exynos4412-midas.dtsi} (92%)
> rewrite arch/arm/boot/dts/exynos4412-trats2.dts (97%)
>
> diff --git a/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> new file mode 100644
> index 000000000000..2806236484a6
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
> @@ -0,0 +1,145 @@
> +/*
> + * Samsung's Exynos4412 based Galaxy S3 board device tree source
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Device tree source file for Samsung's Galaxy S3 boards which are based on
> + * Samsung's Exynos4412 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.
> + */
One new line to make it consistent with others.
> +/dts-v1/;
> +#include "exynos4412-midas.dtsi"
> +
> +/ {
> + aliases {
> + i2c9 = &i2c_ak8975;
> + i2c10 = &i2c_cm36651;
> + };
> +
> + regulators {
> + lcd_vdd3_reg: voltage-regulator-2 {
> + compatible = "regulator-fixed";
> + regulator-name = "LCD_VDD_2.2V";
> + regulator-min-microvolt = <2200000>;
> + regulator-max-microvolt = <2200000>;
> + gpio = <&gpc0 1 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + ps_als_reg: voltage-regulator-5 {
> + compatible = "regulator-fixed";
> + regulator-name = "LED_A_3.0V";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + gpio = <&gpj0 5 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> + };
> +
> + i2c_ak8975: i2c-gpio-0 {
> + compatible = "i2c-gpio";
> + gpios = <&gpy2 4 GPIO_ACTIVE_HIGH>, <&gpy2 5 GPIO_ACTIVE_HIGH>;
> + i2c-gpio,delay-us = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + ak8975@c {
> + compatible = "asahi-kasei,ak8975";
> + reg = <0x0c>;
> + gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + i2c_cm36651: i2c-gpio-2 {
> + compatible = "i2c-gpio";
> + gpios = <&gpf0 0 GPIO_ACTIVE_LOW>, <&gpf0 1 GPIO_ACTIVE_LOW>;
> + i2c-gpio,delay-us = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cm36651@18 {
> + compatible = "capella,cm36651";
> + reg = <0x18>;
> + interrupt-parent = <&gpx0>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + vled-supply = <&ps_als_reg>;
> + };
> + };
> +};
> +
> +&buck9_reg {
> + maxim,ena-gpios = <&gpm0 3 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&cam_af_reg {
> + gpio = <&gpm0 4 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> +
> +&cam_io_reg {
> + gpio = <&gpm0 2 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> +
> +&dsi_0 {
> + status = "okay";
One new line.
> + panel@0 {
> + compatible = "samsung,s6e8aa0";
> + reg = <0>;
> + vdd3-supply = <&lcd_vdd3_reg>;
> + vci-supply = <&ldo25_reg>;
> + reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>;
> + power-on-delay= <50>;
> + reset-delay = <100>;
> + init-delay = <100>;
> + flip-horizontal;
> + flip-vertical;
> + panel-width-mm = <58>;
> + panel-height-mm = <103>;
> +
> + display-timings {
> + timing-0 {
> + clock-frequency = <57153600>;
> + hactive = <720>;
> + vactive = <1280>;
> + hfront-porch = <5>;
> + hback-porch = <5>;
> + hsync-len = <5>;
> + vfront-porch = <13>;
> + vback-porch = <1>;
> + vsync-len = <2>;
> + };
> + };
> + };
> +};
> +
> +&i2c_0 {
> + status = "okay";
> +};
> +
> +&i2c_3 {
> + status = "okay";
> +
> + mms114-touchscreen@48 {
> + compatible = "melfas,mms114";
> + reg = <0x48>;
> + interrupt-parent = <&gpm2>;
> + interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> + x-size = <720>;
> + y-size = <1280>;
> + avdd-supply = <&ldo23_reg>;
> + vdd-supply = <&ldo24_reg>;
> + };
> +};
> +
> +&ldo25_reg {
> + regulator-name = "LCD_VCC_3.3V";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-midas.dtsi
> similarity index 92%
> copy from arch/arm/boot/dts/exynos4412-trats2.dts
> copy to arch/arm/boot/dts/exynos4412-midas.dtsi
> index f285790e8e04..384767a34fa7 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-midas.dtsi
> @@ -10,7 +10,7 @@
> * 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 "exynos4412.dtsi"
> @@ -25,19 +25,11 @@
> compatible = "samsung,trats2", "samsung,exynos4412", "samsung,exynos4";
This looks incorrect. Not every midas board is trats2... Unless that
was left here for compatibility purpose but then it would be good to
see explanation.
>
> aliases {
> - i2c9 = &i2c_ak8975;
> - i2c10 = &i2c_cm36651;
> i2c11 = &i2c_max77693;
> i2c12 = &i2c_max77693_fuel;
> };
>
> - memory@40000000 {
> - device_type = "memory";
> - reg = <0x40000000 0x40000000>;
> - };
> -
> chosen {
> - bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rootwait earlyprintk panic=5";
> stdout-path = &serial_2;
> };
>
> @@ -68,17 +60,8 @@
> regulator-name = "CAM_SENSOR_A";
> regulator-min-microvolt = <2800000>;
> regulator-max-microvolt = <2800000>;
> - gpio = <&gpm0 2 GPIO_ACTIVE_HIGH>;
> - enable-active-high;
> - };
> -
> - lcd_vdd3_reg: voltage-regulator-2 {
> - compatible = "regulator-fixed";
> - regulator-name = "LCD_VDD_2.2V";
> - regulator-min-microvolt = <2200000>;
> - regulator-max-microvolt = <2200000>;
> - gpio = <&gpc0 1 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> + status = "disabled";
Why disabled?
> };
>
> cam_af_reg: voltage-regulator-3 {
> @@ -86,17 +69,8 @@
> regulator-name = "CAM_AF";
> regulator-min-microvolt = <2800000>;
> regulator-max-microvolt = <2800000>;
> - gpio = <&gpm0 4 GPIO_ACTIVE_HIGH>;
> - enable-active-high;
> - };
> -
> - ps_als_reg: voltage-regulator-5 {
> - compatible = "regulator-fixed";
> - regulator-name = "LED_A_3.0V";
> - regulator-min-microvolt = <3000000>;
> - regulator-max-microvolt = <3000000>;
> - gpio = <&gpj0 5 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> + status = "disabled";
Why disabled?
> };
>
> vsil12: voltage-regulator-6 {
> @@ -227,37 +201,6 @@
> };
> };
>
> - i2c_ak8975: i2c-gpio-0 {
> - compatible = "i2c-gpio";
> - gpios = <&gpy2 4 GPIO_ACTIVE_HIGH>, <&gpy2 5 GPIO_ACTIVE_HIGH>;
> - i2c-gpio,delay-us = <2>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - status = "okay";
> -
> - ak8975@c {
> - compatible = "asahi-kasei,ak8975";
> - reg = <0x0c>;
> - gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
> - };
> - };
> -
> - i2c_cm36651: i2c-gpio-2 {
> - compatible = "i2c-gpio";
> - gpios = <&gpf0 0 GPIO_ACTIVE_LOW>, <&gpf0 1 GPIO_ACTIVE_LOW>;
> - i2c-gpio,delay-us = <2>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - cm36651@18 {
> - compatible = "capella,cm36651";
> - reg = <0x18>;
> - interrupt-parent = <&gpx0>;
> - interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> - vled-supply = <&ps_als_reg>;
> - };
> - };
> -
> i2c-mhl {
> compatible = "i2c-gpio";
> gpios = <&gpf0 4 GPIO_ACTIVE_HIGH>, <&gpf0 6 GPIO_ACTIVE_HIGH>;
> @@ -296,8 +239,6 @@
> <&clock CLK_MOUT_CAM1>;
> assigned-clock-parents = <&clock CLK_XUSBXTI>,
> <&clock CLK_XUSBXTI>;
> -
> -
> };
>
> wlan_pwrseq: sdhci3-pwrseq {
> @@ -454,36 +395,7 @@
> samsung,burst-clock-frequency = <500000000>;
> samsung,esc-clock-frequency = <20000000>;
> samsung,pll-clock-frequency = <24000000>;
> - status = "okay";
> -
> - panel@0 {
> - compatible = "samsung,s6e8aa0";
> - reg = <0>;
> - vdd3-supply = <&lcd_vdd3_reg>;
> - vci-supply = <&ldo25_reg>;
> - reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>;
> - power-on-delay= <50>;
> - reset-delay = <100>;
> - init-delay = <100>;
> - flip-horizontal;
> - flip-vertical;
> - panel-width-mm = <58>;
> - panel-height-mm = <103>;
> -
> - display-timings {
> - timing-0 {
> - clock-frequency = <57153600>;
> - hactive = <720>;
> - vactive = <1280>;
> - hfront-porch = <5>;
> - hback-porch = <5>;
> - hsync-len = <5>;
> - vfront-porch = <13>;
> - vback-porch = <1>;
> - vsync-len = <2>;
> - };
> - };
> - };
> + status = "disabled";
It is already disabled by exynos4.dtsi, no need to duplicate properties.
> };
>
> &exynos_usbphy {
> @@ -603,7 +515,7 @@
> samsung,i2c-max-bus-freq = <400000>;
> pinctrl-0 = <&i2c0_bus>;
> pinctrl-names = "default";
> - status = "okay";
> + status = "disabled";
I do not get this node. It sits in midas.dtsi and s3.dtsi just enables
it. Why not enabling it here?
> s5c73m3@3c {
> compatible = "samsung,s5c73m3";
> @@ -635,18 +547,7 @@
> samsung,i2c-max-bus-freq = <400000>;
> pinctrl-0 = <&i2c3_bus>;
> pinctrl-names = "default";
> - status = "okay";
> -
> - mms114-touchscreen@48 {
> - compatible = "melfas,mms114";
> - reg = <0x48>;
> - interrupt-parent = <&gpm2>;
> - interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
> - x-size = <720>;
> - y-size = <1280>;
> - avdd-supply = <&ldo23_reg>;
> - vdd-supply = <&ldo24_reg>;
> - };
> + status = "disabled";
> };
>
> &i2c_4 {
> @@ -827,6 +728,7 @@
> regulator-name = "CAM_SENSOR_CORE_1.2V";
> regulator-min-microvolt = <1200000>;
> regulator-max-microvolt = <1200000>;
> + status = "okay";
Regulator should not be disabled or enabled. It is not a device. I do
not get the logic behind...
The ''status = disabled" usually is added in DTSI files to nodes which
are not fully configured at this point, e.g. they require external
resources (clocks, regulators). These external resources will be
provided when extending in DTS (or further DTSI) while enabling it.
However regulator has always all necessary resources.
> };
>
> ldo18_reg: LDO18 {
> @@ -874,9 +776,7 @@
> };
>
> ldo25_reg: LDO25 {
> - regulator-name = "LCD_VCC_3.3V";
> - regulator-min-microvolt = <2800000>;
> - regulator-max-microvolt = <2800000>;
> + status = "disabled";
Ditto.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 5/5] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.
From: jan.tuerk @ 2017-12-20 13:47 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Russell King, Shawn Guo, Sascha Hauer, Fabio Estevam,
Andreas Färber, Kevin Hilman, Maxime Ripard,
Alexandre Belloni, SZ Lin, Greg Kroah-Hartman, devicetree,
linux-kernel, dri-devel, linux-arm-kernel
In-Reply-To: <20171220134710.64479-1-jan.tuerk@emtrion.com>
From: Jan Tuerk <jan.tuerk@emtrion.com>
All recent emtrion modules based on i.mx6 make use of the DA0963.
Therefore enable it with the following defaults:
- CONFIG_MFD_DA9063=y
- CONFIG_REGULATOR_DA9063=y
- CONFIG_DA9063_WATCHDOG=m
- CONFIG_RTC_DRV_DA9063=m
MFD and REGULATOR are built-in to have it at Kernel boot-time.
The WATCHDOG and RTC are optional and could be loaded from userspace.
Signed-off-by: Jan Tuerk <jan.tuerk@emtrion.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 0d4494922561..09cd8048b0c1 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -215,8 +215,10 @@ CONFIG_THERMAL_WRITABLE_TRIPS=y
CONFIG_CPU_THERMAL=y
CONFIG_IMX_THERMAL=y
CONFIG_WATCHDOG=y
+CONFIG_DA9063_WATCHDOG=m
CONFIG_IMX2_WDT=y
CONFIG_MFD_DA9052_I2C=y
+CONFIG_MFD_DA9063=y
CONFIG_MFD_MC13XXX_SPI=y
CONFIG_MFD_MC13XXX_I2C=y
CONFIG_MFD_STMPE=y
@@ -224,6 +226,7 @@ CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_ANATOP=y
CONFIG_REGULATOR_DA9052=y
+CONFIG_REGULATOR_DA9063=y
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_MC13783=y
CONFIG_REGULATOR_MC13892=y
@@ -349,6 +352,7 @@ CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_M41T80=y
CONFIG_RTC_DRV_MC13XXX=y
CONFIG_RTC_DRV_MXC=y
+CONFIG_RTC_DRV_DA9063=m
CONFIG_RTC_DRV_SNVS=y
CONFIG_DMADEVICES=y
CONFIG_FSL_EDMA=y
--
emtrion GmbH
Alter Schlachthof 45
76131 Karlsruhe
GERMANY
https://www.emtrion.de
Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
^ permalink raw reply related
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