* Re: [PATCH 1/2] ARM: dts: Add the support for display5 equipped with Mitsubishi (800x480) display
From: Lucas Stach @ 2017-11-17 15:07 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Shawn Guo, Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Sascha Hauer,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171117160347.5c78be6e@jawa>
Am Freitag, den 17.11.2017, 16:03 +0100 schrieb Lukasz Majewski:
> Hi Lucas,
>
> > Am Freitag, den 17.11.2017, 15:13 +0100 schrieb Lukasz Majewski:
> > > Hi Shawn,
> > >
> > > > On Fri, Nov 17, 2017 at 11:24:03AM +0100, Lukasz Majewski wrote:
> > > > > This is the support for aa070mc01-ca1 Mitsubishi display.
> > > > >
> > > > > > > > > > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > > > > ---
> > > > > arch/arm/boot/dts/Makefile | 1 +
> > > > > .../imx6q-display5-mitsubishi-aa070-800x480.dts | 51
> > > > > ++++++++++++++++++++++ 2 files changed, 52 insertions(+)
> > > > > create mode 100644
> > > > > arch/arm/boot/dts/imx6q-display5-mitsubishi-aa070-800x480.dts
> > > > >
> > > > > diff --git a/arch/arm/boot/dts/Makefile
> > > > > b/arch/arm/boot/dts/Makefile
> > > > > index d9d0c82e7d20..10b3ad078dea 100644
> > > > > --- a/arch/arm/boot/dts/Makefile
> > > > > +++ b/arch/arm/boot/dts/Makefile
> > > > > @@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > > > > > > > > > imx6q-cm-fx6.dtb \
> > > > > > > > > > imx6q-cubox-i.dtb \
> > > > > > > > > > imx6q-dfi-fs700-m60.dtb \
> > > > > > > > > > + imx6q-display5-mitsubishi-aa070-800x480.dtb \
> > > > > > > > > > imx6q-display5-tianma-tm070-1280x768.dtb \
> > > > > > > > > > imx6q-dmo-edmqmx6.dtb \
> > > > > imx6q-evi.dtb \
> > > >
> > > > <snip>
> > > >
> > > > > +#include "imx6q-display5.dtsi"
> > > > > +
> > > > > +&panel {
> > > > > > > > > > + compatible = "mitsubishi,aa070mc01-ca1";
> > > > > +};
> > > >
> > > > How many DTB files do you want to add for this display5 board?
> > >
> > > This is a single board, which can support panels which I've posted.
> > >
> > > Those dtbs I do pack to u-boot' FIT image and don't need to worry
> > > that
> > > some display is not working (after setting bootloader env variable).
> > >
> > > > It's
> > > > obvious no fun to maintain a bunch of DTB files for all the panels
> > > > this board can support.
> > >
> > > Please note that those files excessively use #include directive, and
> > > there is not so much code added (the longest part is license and
> > > comments).
> > >
> > > > Let's stop right here.
> > >
> > > If I may ask - how shall I proceed? What would be your suggestion to
> > > move on (dtb overlays) ?
> >
> > The solution we use for the ZII RDU1 and RDU2 boards is to have the
> > bootloader patch in the correct panel compatible strings.
>
> Do you mean adjusting the DTB accordingly in u-boot for each display -
> change panel/compatible to new display name ?
Exactly. Simply let the bootloader insert the correct panel compatible
string into the DTB.
Regards,
Lucas
--
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 1/2] ARM: dts: Add the support for display5 equipped with Mitsubishi (800x480) display
From: Lukasz Majewski @ 2017-11-17 15:03 UTC (permalink / raw)
To: Lucas Stach
Cc: Shawn Guo, Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Sascha Hauer,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1510929383.8104.3.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3268 bytes --]
Hi Lucas,
> Am Freitag, den 17.11.2017, 15:13 +0100 schrieb Lukasz Majewski:
> > Hi Shawn,
> >
> > > On Fri, Nov 17, 2017 at 11:24:03AM +0100, Lukasz Majewski wrote:
> > > > This is the support for aa070mc01-ca1 Mitsubishi display.
> > > >
> > > > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > > > ---
> > > > arch/arm/boot/dts/Makefile | 1 +
> > > > .../imx6q-display5-mitsubishi-aa070-800x480.dts | 51
> > > > ++++++++++++++++++++++ 2 files changed, 52 insertions(+)
> > > > create mode 100644
> > > > arch/arm/boot/dts/imx6q-display5-mitsubishi-aa070-800x480.dts
> > > >
> > > > diff --git a/arch/arm/boot/dts/Makefile
> > > > b/arch/arm/boot/dts/Makefile
> > > > index d9d0c82e7d20..10b3ad078dea 100644
> > > > --- a/arch/arm/boot/dts/Makefile
> > > > +++ b/arch/arm/boot/dts/Makefile
> > > > @@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > > > imx6q-cm-fx6.dtb \
> > > > imx6q-cubox-i.dtb \
> > > > imx6q-dfi-fs700-m60.dtb \
> > > > + imx6q-display5-mitsubishi-aa070-800x480.dtb \
> > > > imx6q-display5-tianma-tm070-1280x768.dtb \
> > > > imx6q-dmo-edmqmx6.dtb \
> > > > imx6q-evi.dtb \
> > >
> > > <snip>
> > >
> > > > +#include "imx6q-display5.dtsi"
> > > > +
> > > > +&panel {
> > > > + compatible = "mitsubishi,aa070mc01-ca1";
> > > > +};
> > >
> > > How many DTB files do you want to add for this display5 board?
> >
> > This is a single board, which can support panels which I've posted.
> >
> > Those dtbs I do pack to u-boot' FIT image and don't need to worry
> > that
> > some display is not working (after setting bootloader env variable).
> >
> > > It's
> > > obvious no fun to maintain a bunch of DTB files for all the panels
> > > this board can support.
> >
> > Please note that those files excessively use #include directive, and
> > there is not so much code added (the longest part is license and
> > comments).
> >
> > > Let's stop right here.
> >
> > If I may ask - how shall I proceed? What would be your suggestion to
> > move on (dtb overlays) ?
>
> The solution we use for the ZII RDU1 and RDU2 boards is to have the
> bootloader patch in the correct panel compatible strings.
Do you mean adjusting the DTB accordingly in u-boot for each display -
change panel/compatible to new display name ?
> This is
> quite a bit simpler than using overlays and if you already have a
> environment variable for this it should be easy to do.
>
> > >
> > > Shawn
> > >
> > > > +
> > > > +&ldb {
> > > > + lvds0: lvds-channel@0 {
> > > > + fsl,data-mapping = "spwg";
> > > > + fsl,data-width = <24>;
> > > > + };
> > > > +};
>
> This isn't needed. The panel compatible implies the data mapping and
> bus width (at least if you properly filled in this information in the
> panel driver).
>
> Regards,
> Lucas
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 5/5] checks: add aliases node checks
From: Rob Herring @ 2017-11-17 14:45 UTC (permalink / raw)
To: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117144515.10870-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add checks for aliases node that properties are a valid path and that the
alias property names are a known, standard name.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
checks.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/checks.c b/checks.c
index a785b81bea07..2c5b6c2eacb3 100644
--- a/checks.c
+++ b/checks.c
@@ -637,6 +637,48 @@ static void check_names_is_string_list(struct check *c, struct dt_info *dti,
}
WARNING(names_is_string_list, check_names_is_string_list, NULL);
+static void check_alias_paths(struct check *c, struct dt_info *dti,
+ struct node *node)
+{
+ struct property *prop;
+
+ if (!streq(node->name, "aliases"))
+ return;
+
+ for_each_property(node, prop) {
+ if (!prop->val.val || !get_node_by_path(dti->dt, prop->val.val))
+ FAIL(c, dti, "aliases property '%s' is not a valid node (%s)",
+ prop->name, prop->val.val);
+ }
+}
+WARNING(alias_paths, check_alias_paths, NULL);
+
+static void check_known_aliases(struct check *c, struct dt_info *dti,
+ struct node *node)
+{
+ int i;
+ struct property *prop;
+ static char *aliases_strings[] = {
+ "ethernet", "gpio", "i2c", "rtc", "serial", "spi"
+ };
+
+ if (!streq(node->name, "aliases"))
+ return;
+
+ for_each_property(node, prop) {
+ for (i = 0; i < ARRAY_SIZE(aliases_strings); i++) {
+ if (strstarts(prop->name, aliases_strings[i]))
+ break;
+ }
+
+ if (i == ARRAY_SIZE(aliases_strings)) {
+ FAIL(c, dti, "unknown alias name %s", prop->name);
+ continue;
+ }
+ }
+}
+WARNING(known_aliases, check_known_aliases, NULL);
+
static void fixup_addr_size_cells(struct check *c, struct dt_info *dti,
struct node *node)
{
@@ -1355,6 +1397,8 @@ static struct check *check_table[] = {
&gpios_property,
&interrupts_property,
+ &known_aliases, &alias_paths,
+
&always_fail,
};
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 4/5] checks: check for #{size,address}-cells without child nodes
From: Rob Herring @ 2017-11-17 14:45 UTC (permalink / raw)
To: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117144515.10870-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
nodes with a 'reg' property nor a ranges property.
An exception may be an overlay that adds nodes, but this case would need
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
checks.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/checks.c b/checks.c
index 346b0256f9cb..a785b81bea07 100644
--- a/checks.c
+++ b/checks.c
@@ -982,6 +982,31 @@ static void check_avoid_default_addr_size(struct check *c, struct dt_info *dti,
WARNING(avoid_default_addr_size, check_avoid_default_addr_size, NULL,
&addr_size_cells);
+static void check_avoid_unecessary_addr_size(struct check *c, struct dt_info *dti,
+ struct node *node)
+{
+ struct property *prop;
+ struct node *child;
+ bool has_reg = false;
+
+ if (!node->parent || node->addr_cells < 0 || node->size_cells < 0)
+ return;
+
+ if (get_property(node, "ranges") || !node->children)
+ return;
+
+ for_each_child(node, child) {
+ prop = get_property(child, "reg");
+ if (prop)
+ has_reg = true;
+ }
+
+ if (!has_reg)
+ FAIL(c, dti, "unnecessary #address-cells/#size-cells without \"ranges\" or child \"reg\" property in %s",
+ node->fullpath);
+}
+WARNING(avoid_unecessary_addr_size, check_avoid_unecessary_addr_size, NULL, &avoid_default_addr_size);
+
static void check_obsolete_chosen_interrupt_controller(struct check *c,
struct dt_info *dti,
struct node *node)
@@ -1306,6 +1331,7 @@ static struct check *check_table[] = {
&simple_bus_reg,
&avoid_default_addr_size,
+ &avoid_unecessary_addr_size,
&obsolete_chosen_interrupt_controller,
&clocks_property,
--
2.14.1
^ permalink raw reply related
* [PATCH 3/5] checks: add string list check for *-names properties
From: Rob Herring @ 2017-11-17 14:45 UTC (permalink / raw)
To: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117144515.10870-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add a string list check for common properties ending in "-names" such as
reg-names or interrupt-names.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
checks.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/checks.c b/checks.c
index 4e23f29486bb..346b0256f9cb 100644
--- a/checks.c
+++ b/checks.c
@@ -622,6 +622,21 @@ WARNING_IF_NOT_STRING(stdout_path_is_string, "stdout-path");
WARNING_IF_NOT_STRING_LIST(compatible_is_string_list, "compatible");
+static void check_names_is_string_list(struct check *c, struct dt_info *dti,
+ struct node *node)
+{
+ struct property *prop;
+
+ for_each_property(node, prop) {
+ if (!strstr(prop->name, "-names"))
+ continue;
+
+ c->data = prop->name;
+ check_is_string_list(c, dti, node);
+ }
+}
+WARNING(names_is_string_list, check_names_is_string_list, NULL);
+
static void fixup_addr_size_cells(struct check *c, struct dt_info *dti,
struct node *node)
{
@@ -1273,7 +1288,7 @@ static struct check *check_table[] = {
&device_type_is_string, &model_is_string, &status_is_string,
&label_is_string, &bootargs_is_string, &stdout_path_is_string,
- &compatible_is_string_list,
+ &compatible_is_string_list, &names_is_string_list,
&property_name_chars_strict,
&node_name_chars_strict,
--
2.14.1
^ permalink raw reply related
* [PATCH 2/5] checks: add string list check
From: Rob Herring @ 2017-11-17 14:45 UTC (permalink / raw)
To: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117144515.10870-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add a check for string list properties with compatible being the first
check.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
checks.c | 34 ++++++++++++++++++++++++++++++++++
tests/bad-string-props.dts | 8 ++++++++
tests/run_tests.sh | 2 +-
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/checks.c b/checks.c
index a4a9d37ca19b..4e23f29486bb 100644
--- a/checks.c
+++ b/checks.c
@@ -179,6 +179,36 @@ static void check_is_string(struct check *c, struct dt_info *dti,
#define ERROR_IF_NOT_STRING(nm, propname) \
ERROR(nm, check_is_string, (propname))
+static void check_is_string_list(struct check *c, struct dt_info *dti,
+ struct node *node)
+{
+ int rem, l;
+ struct property *prop;
+ char *propname = c->data;
+ char *str;
+
+ prop = get_property(node, propname);
+ if (!prop)
+ return; /* Not present, assumed ok */
+
+ str = prop->val.val;
+ rem = prop->val.len;
+ while (rem > 0) {
+ l = strnlen(str, rem);
+ if (l == rem) {
+ FAIL(c, dti, "\"%s\" property in %s is not a string list",
+ propname, node->fullpath);
+ break;
+ }
+ rem -= l + 1;
+ str += l + 1;
+ }
+}
+#define WARNING_IF_NOT_STRING_LIST(nm, propname) \
+ WARNING(nm, check_is_string_list, (propname))
+#define ERROR_IF_NOT_STRING_LIST(nm, propname) \
+ ERROR(nm, check_is_string_list, (propname))
+
static void check_is_cell(struct check *c, struct dt_info *dti,
struct node *node)
{
@@ -590,6 +620,8 @@ WARNING_IF_NOT_STRING(label_is_string, "label");
WARNING_IF_NOT_STRING(bootargs_is_string, "bootargs");
WARNING_IF_NOT_STRING(stdout_path_is_string, "stdout-path");
+WARNING_IF_NOT_STRING_LIST(compatible_is_string_list, "compatible");
+
static void fixup_addr_size_cells(struct check *c, struct dt_info *dti,
struct node *node)
{
@@ -1241,6 +1273,8 @@ static struct check *check_table[] = {
&device_type_is_string, &model_is_string, &status_is_string,
&label_is_string, &bootargs_is_string, &stdout_path_is_string,
+ &compatible_is_string_list,
+
&property_name_chars_strict,
&node_name_chars_strict,
diff --git a/tests/bad-string-props.dts b/tests/bad-string-props.dts
index 9b5a7a1736ee..5e226ce0c736 100644
--- a/tests/bad-string-props.dts
+++ b/tests/bad-string-props.dts
@@ -7,4 +7,12 @@
bootargs = <0xdeadbeef>;
stdout-path = <0xdeadbeef>;
label = <0xdeadbeef>;
+
+ node1 {
+ compatible = <0xdeadbeef>;
+ };
+
+ node2 {
+ compatible = "good", <0xdeadbeef>;
+ };
};
diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index c610aaeb053e..f492cf78ae84 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -546,7 +546,7 @@ dtc_tests () {
check_tests bad-name-property.dts name_properties
check_tests bad-ncells.dts address_cells_is_cell size_cells_is_cell interrupt_cells_is_cell
- check_tests bad-string-props.dts device_type_is_string model_is_string status_is_string bootargs_is_string stdout_path_is_string label_is_string
+ check_tests bad-string-props.dts device_type_is_string model_is_string status_is_string bootargs_is_string stdout_path_is_string label_is_string compatible_is_string_list
check_tests bad-reg-ranges.dts reg_format ranges_format
check_tests bad-empty-ranges.dts ranges_format
check_tests reg-ranges-root.dts reg_format ranges_format
--
2.14.1
^ permalink raw reply related
* [PATCH 1/5] checks: add a string checks for label, bootargs and stdout-path
From: Rob Herring @ 2017-11-17 14:45 UTC (permalink / raw)
To: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171117144515.10870-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add more string property checks for label, bootargs, and stdout-path.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
checks.c | 4 ++++
tests/bad-string-props.dts | 3 +++
tests/run_tests.sh | 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/checks.c b/checks.c
index f5bf5f97a3ad..a4a9d37ca19b 100644
--- a/checks.c
+++ b/checks.c
@@ -586,6 +586,9 @@ WARNING_IF_NOT_CELL(interrupt_cells_is_cell, "#interrupt-cells");
WARNING_IF_NOT_STRING(device_type_is_string, "device_type");
WARNING_IF_NOT_STRING(model_is_string, "model");
WARNING_IF_NOT_STRING(status_is_string, "status");
+WARNING_IF_NOT_STRING(label_is_string, "label");
+WARNING_IF_NOT_STRING(bootargs_is_string, "bootargs");
+WARNING_IF_NOT_STRING(stdout_path_is_string, "stdout-path");
static void fixup_addr_size_cells(struct check *c, struct dt_info *dti,
struct node *node)
@@ -1236,6 +1239,7 @@ static struct check *check_table[] = {
&address_cells_is_cell, &size_cells_is_cell, &interrupt_cells_is_cell,
&device_type_is_string, &model_is_string, &status_is_string,
+ &label_is_string, &bootargs_is_string, &stdout_path_is_string,
&property_name_chars_strict,
&node_name_chars_strict,
diff --git a/tests/bad-string-props.dts b/tests/bad-string-props.dts
index 396f82069cf7..9b5a7a1736ee 100644
--- a/tests/bad-string-props.dts
+++ b/tests/bad-string-props.dts
@@ -4,4 +4,7 @@
device_type = <0xdeadbeef>;
model = <0xdeadbeef>;
status = <0xdeadbeef>;
+ bootargs = <0xdeadbeef>;
+ stdout-path = <0xdeadbeef>;
+ label = <0xdeadbeef>;
};
diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index 850bc165e757..c610aaeb053e 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -546,7 +546,7 @@ dtc_tests () {
check_tests bad-name-property.dts name_properties
check_tests bad-ncells.dts address_cells_is_cell size_cells_is_cell interrupt_cells_is_cell
- check_tests bad-string-props.dts device_type_is_string model_is_string status_is_string
+ check_tests bad-string-props.dts device_type_is_string model_is_string status_is_string bootargs_is_string stdout_path_is_string label_is_string
check_tests bad-reg-ranges.dts reg_format ranges_format
check_tests bad-empty-ranges.dts ranges_format
check_tests reg-ranges-root.dts reg_format ranges_format
--
2.14.1
^ permalink raw reply related
* [PATCH 0/5] Another batch of dtc checks
From: Rob Herring @ 2017-11-17 14:45 UTC (permalink / raw)
To: devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
Here's another batch of dtc checks. The first 3 patches are pretty
straightforward. The last 2 patches are a bit more subjective.
For aliases, I would like to see them restricted to a documented list of
names. There are some platforms I've seen that seem to just define
aliases for many devices and most are not needed. The main use of
aliases in the Linux kernel is to provide fixed device numbers to
userspace, but this is an anti-goal of in the kernel.
Rob
Rob Herring (5):
checks: add a string checks for label, bootargs and stdout-path
checks: add string list check
checks: add string list check for *-names properties
checks: check for #{size,address}-cells without child nodes
checks: add aliases node checks
checks.c | 123 +++++++++++++++++++++++++++++++++++++++++++++
tests/bad-string-props.dts | 11 ++++
tests/run_tests.sh | 2 +-
3 files changed, 135 insertions(+), 1 deletion(-)
--
2.14.1
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: Add the support for display5 equipped with Mitsubishi (800x480) display
From: Lucas Stach @ 2017-11-17 14:36 UTC (permalink / raw)
To: Lukasz Majewski, Shawn Guo
Cc: Mark Rutland, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
Russell King, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Sascha Hauer, Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171117151334.041c4684@jawa>
Am Freitag, den 17.11.2017, 15:13 +0100 schrieb Lukasz Majewski:
> Hi Shawn,
>
> > On Fri, Nov 17, 2017 at 11:24:03AM +0100, Lukasz Majewski wrote:
> > > This is the support for aa070mc01-ca1 Mitsubishi display.
> > >
> > > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > > ---
> > > arch/arm/boot/dts/Makefile | 1 +
> > > .../imx6q-display5-mitsubishi-aa070-800x480.dts | 51
> > > ++++++++++++++++++++++ 2 files changed, 52 insertions(+)
> > > create mode 100644
> > > arch/arm/boot/dts/imx6q-display5-mitsubishi-aa070-800x480.dts
> > >
> > > diff --git a/arch/arm/boot/dts/Makefile
> > > b/arch/arm/boot/dts/Makefile
> > > index d9d0c82e7d20..10b3ad078dea 100644
> > > --- a/arch/arm/boot/dts/Makefile
> > > +++ b/arch/arm/boot/dts/Makefile
> > > @@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > > imx6q-cm-fx6.dtb \
> > > imx6q-cubox-i.dtb \
> > > imx6q-dfi-fs700-m60.dtb \
> > > + imx6q-display5-mitsubishi-aa070-800x480.dtb \
> > > imx6q-display5-tianma-tm070-1280x768.dtb \
> > > imx6q-dmo-edmqmx6.dtb \
> > > imx6q-evi.dtb \
> >
> > <snip>
> >
> > > +#include "imx6q-display5.dtsi"
> > > +
> > > +&panel {
> > > + compatible = "mitsubishi,aa070mc01-ca1";
> > > +};
> >
> > How many DTB files do you want to add for this display5 board?
>
> This is a single board, which can support panels which I've posted.
>
> Those dtbs I do pack to u-boot' FIT image and don't need to worry
> that
> some display is not working (after setting bootloader env variable).
>
> > It's
> > obvious no fun to maintain a bunch of DTB files for all the panels
> > this board can support.
>
> Please note that those files excessively use #include directive, and
> there is not so much code added (the longest part is license and
> comments).
>
> > Let's stop right here.
>
> If I may ask - how shall I proceed? What would be your suggestion to
> move on (dtb overlays) ?
The solution we use for the ZII RDU1 and RDU2 boards is to have the
bootloader patch in the correct panel compatible strings. This is quite
a bit simpler than using overlays and if you already have a environment
variable for this it should be easy to do.
> >
> > Shawn
> >
> > > +
> > > +&ldb {
> > > + lvds0: lvds-channel@0 {
> > > + fsl,data-mapping = "spwg";
> > > + fsl,data-width = <24>;
> > > + };
> > > +};
This isn't needed. The panel compatible implies the data mapping and
bus width (at least if you properly filled in this information in the
panel driver).
Regards,
Lucas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: renesas: eagle: specify EtherAVB PHY IRQ
From: Simon Horman @ 2017-11-17 14:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sergei Shtylyov, Rob Herring, Catalin Marinas, Will Deacon,
Linux-Renesas, devicetree@vger.kernel.org, Magnus Damm,
Mark Rutland, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdUqX6OhsKBET5RkL0zcZO-aiTT4wHHuwuRTeVHAYkSnZg@mail.gmail.com>
On Wed, Nov 15, 2017 at 05:15:58PM +0100, Geert Uytterhoeven wrote:
> On Mon, Nov 13, 2017 at 10:23 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > Specify EtherAVB PHY IRQ in the Eagle board's device tree, now that we
> > have the GPIO support (previously phylib had to resort to polling).
> >
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: renesas: r8a77970: add GPIO support
From: Simon Horman @ 2017-11-17 14:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sergei Shtylyov, Rob Herring, Catalin Marinas, Will Deacon,
Linux-Renesas, devicetree@vger.kernel.org, Magnus Damm,
Mark Rutland, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdX9n6U8vP0NWRW0hFZqLQbMKvcf4U1HZkP4nJdaS4-qNg@mail.gmail.com>
On Wed, Nov 15, 2017 at 05:12:30PM +0100, Geert Uytterhoeven wrote:
> On Mon, Nov 13, 2017 at 10:23 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > Describe all 6 GPIO controllers in the R8A77970 device tree.
> >
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] arm64: dts: ulcb-kf: add dr_mode property for USB2.0 channel 0
From: Simon Horman @ 2017-11-17 14:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vladimir Barinov, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, devicetree@vger.kernel.org,
Linux-Renesas
In-Reply-To: <CAMuHMdWLXyj=WaeacPpOohP0Th2Puwszri4t4YjNgceTuBcU5Q@mail.gmail.com>
On Wed, Nov 15, 2017 at 05:52:29PM +0100, Geert Uytterhoeven wrote:
> On Wed, Nov 8, 2017 at 2:09 PM, Vladimir Barinov
> <vladimir.barinov@cogentembedded.com> wrote:
> > ULCB-KF has a USB2.0 dual-role channel (CN13).
> > This adds dr_mode property for USB2.0 channel 0 (EHCI/OHCI and HS-USB)
> > as "otg".
> >
> > Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ulcb-kf: enable USB2 PHY of channel 0
From: Simon Horman @ 2017-11-17 14:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vladimir Barinov, Magnus Damm, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <CAMuHMdWuHV38=XupXxH1TXFONpsjmY=3zN7iaKDT54xBd_DSGw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Nov 15, 2017 at 05:36:21PM +0100, Geert Uytterhoeven wrote:
> Hi Vladimir,
>
> On Wed, Nov 8, 2017 at 1:21 PM, Vladimir Barinov
> <vladimir.barinov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> wrote:
> > This supports USB2 PHY channel #0 on ULCB Kingfisher board
> >
> > The dedicated USB0_PWEN pin is used to control CN13 VBUS source from U43
> > power supply.
> > MAX3355 can also provide VBUS, hence it should be disabled via OTG_OFFVBUSn
> > node coming from gpio expander TCA9539.
> > Set MAX3355 enabled using OTG_EXTLPn node to be able to read OTG ID of CN13.
I took the liberty of line-wrapping the line above to keep it from going
over 75 characters wide to keep checkpatch happy.
> >
> > Signed-off-by: Vladimir Barinov <vladimir.barinov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
> > ---
> > Changes in version 2:
> > - added gpio hogs for MAX3355 VBUS and SHDN
>
> Thanks for the update!
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Thanks, applied.
--
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 1/2] ARM: dts: Add the support for display5 equipped with Mitsubishi (800x480) display
From: Lukasz Majewski @ 2017-11-17 14:13 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Rob Herring, Mark Rutland, Russell King,
Sascha Hauer, Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171117131047.GE25390@dragon>
[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]
Hi Shawn,
> On Fri, Nov 17, 2017 at 11:24:03AM +0100, Lukasz Majewski wrote:
> > This is the support for aa070mc01-ca1 Mitsubishi display.
> >
> > Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> > ---
> > arch/arm/boot/dts/Makefile | 1 +
> > .../imx6q-display5-mitsubishi-aa070-800x480.dts | 51
> > ++++++++++++++++++++++ 2 files changed, 52 insertions(+)
> > create mode 100644
> > arch/arm/boot/dts/imx6q-display5-mitsubishi-aa070-800x480.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index d9d0c82e7d20..10b3ad078dea 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > imx6q-cm-fx6.dtb \
> > imx6q-cubox-i.dtb \
> > imx6q-dfi-fs700-m60.dtb \
> > + imx6q-display5-mitsubishi-aa070-800x480.dtb \
> > imx6q-display5-tianma-tm070-1280x768.dtb \
> > imx6q-dmo-edmqmx6.dtb \
> > imx6q-evi.dtb \
>
> <snip>
>
> > +#include "imx6q-display5.dtsi"
> > +
> > +&panel {
> > + compatible = "mitsubishi,aa070mc01-ca1";
> > +};
>
> How many DTB files do you want to add for this display5 board?
This is a single board, which can support panels which I've posted.
Those dtbs I do pack to u-boot' FIT image and don't need to worry that
some display is not working (after setting bootloader env variable).
> It's
> obvious no fun to maintain a bunch of DTB files for all the panels
> this board can support.
Please note that those files excessively use #include directive, and
there is not so much code added (the longest part is license and
comments).
> Let's stop right here.
If I may ask - how shall I proceed? What would be your suggestion to
move on (dtb overlays) ?
>
> Shawn
>
> > +
> > +&ldb {
> > + lvds0: lvds-channel@0 {
> > + fsl,data-mapping = "spwg";
> > + fsl,data-width = <24>;
> > + };
> > +};
> > --
> > 2.11.0
> >
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] of: Document exactly what of_find_node_by_name() puts
From: Rob Herring @ 2017-11-17 14:08 UTC (permalink / raw)
To: Stephen Boyd
Cc: Randy Dunlap, Frank Rowand,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171117024404.GV11955-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Thu, Nov 16, 2017 at 8:44 PM, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> On 11/10, Randy Dunlap wrote:
>> On 11/10/2017 05:45 PM, Stephen Boyd wrote:
>> > It isn't clear if this function of_node_put()s the 'from'
>> > argument, or the node it finds in the search. Clearly indicate
>> > which variable is touched.
>> >
>> > Signed-off-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> > ---
>> > drivers/of/base.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/of/base.c b/drivers/of/base.c
>> > index 63897531cd75..602c5d65734a 100644
>> > --- a/drivers/of/base.c
>> > +++ b/drivers/of/base.c
>> > @@ -866,7 +866,7 @@ EXPORT_SYMBOL(of_find_node_opts_by_path);> * @from: The node to start searching from or NULL, the node
>>
>> * @from: The node to start searching from or %NULL; the node
>>
>> > * you pass will not be searched, only the next one
>> > * will; typically, you pass what the previous call
>>
>> * will. Typically, you pass what the previous call
>>
>
> Rob, do you want me to fold this in?
Yes, please.
Rob
--
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 v2] arm64: dts: ls1088a: add fsl-mc hardware resource manager node
From: Ioana Ciornei @ 2017-11-17 14:05 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ioana Ciornei
Add the fsl-mc node in the LS1088A device tree.
Signed-off-by: Ioana Ciornei <ioana.ciornei-3arQi8VN3Tc@public.gmane.org>
---
Changes in v2:
- add a newline in between nodes
- use hexadecimal unit-addresses
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 71 ++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index bd80e9a..e1a96b2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -166,6 +166,77 @@
<1 10 IRQ_TYPE_LEVEL_LOW>;/* Hypervisor PPI */
};
+ fsl_mc: fsl-mc@80c000000 {
+ compatible = "fsl,qoriq-mc";
+ reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
+ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
+ msi-parent = <&its>;
+ #address-cells = <3>;
+ #size-cells = <1>;
+
+ /*
+ * Region type 0x0 - MC portals
+ * Region type 0x1 - QBMAN portals
+ */
+ ranges = <0x0 0x0 0x0 0x8 0x0c000000 0x4000000
+ 0x1 0x0 0x0 0x8 0x18000000 0x8000000>;
+
+ dpmacs {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dpmac1: dpmac@1 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <1>;
+ };
+
+ dpmac2: dpmac@2 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <2>;
+ };
+
+ dpmac3: dpmac@3 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <3>;
+ };
+
+ dpmac4: dpmac@4 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <4>;
+ };
+
+ dpmac5: dpmac@5 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <5>;
+ };
+
+ dpmac6: dpmac@6 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <6>;
+ };
+
+ dpmac7: dpmac@7 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <7>;
+ };
+
+ dpmac8: dpmac@8 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <8>;
+ };
+
+ dpmac9: dpmac@9 {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <9>;
+ };
+
+ dpmac10: dpmac@a {
+ compatible = "fsl,qoriq-mc-dpmac";
+ reg = <0xa>;
+ };
+ };
+ };
+
psci {
compatible = "arm,psci-0.2";
method = "smc";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 3/5] ARM64: dts: meson-axg: add I2C DT info for Meson-AXG SoC
From: Yixun Lan @ 2017-11-17 14:02 UTC (permalink / raw)
To: Neil Armstrong, Wolfram Sang, Rob Herring, Mark Rutland,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Kevin Hilman
Cc: yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ, Jerome Brunet, Carlo Caione,
Jian Hu, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <96dc68e3-c394-70c4-eabe-f59d4c36150e-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Neil
see my comments in line
On 11/17/17 21:05, Neil Armstrong wrote:
> Hi Yixun, Jian,
>
> On 17/11/2017 09:02, Yixun Lan wrote:
>> From: Jian Hu <jian.hu-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>>
>> There are four I2C masters in EE domain, and one I2C Master in
>> AO domain, the DT info here should describe them all.
>>
>> Signed-off-by: Jian Hu <jian.hu-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 59 ++++++++++++++++++++++++++++++
>> 1 file changed, 59 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index 57faaa9d8013..99e967aff439 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -129,6 +129,54 @@
>> #reset-cells = <1>;
>> };
>>
>> + i2c_m0: i2c@1f000 {
>
> Can you use a more simple "i2c0" phandle naming instead ? or get back to the "i2c_A/B/C/D" naming like in meson_gx to keep consistency ?
>
Ok, I would prefer to use 'i2c0' then
we had a internal discussion about the inconsistent naming of the I2C
controller, and reach a consensus to name them as:
the EE domain: ee_i2c_m0, ee_i2c_m1 ..
the AO domain: ao_i2c_m0, ao_i2c_s0
in the future datasheet.
note: 'ee' means the EE domain, m0 mean the master 0, s0 mean the I2C
slave 0
> [...]
>
>> + };
>> +
>> + i2c_m1: i2c@1e000 {
>
> [...]
>
>> + };
>> +
>> + i2c_m2: i2c@1d000 {
>
> [...]
>
>> + };
>> +
>> + i2c_m3: i2c@1c000 {
>
> [...]
>
>> + };
>> +
>> uart_A: serial@24000 {
>> compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
>> reg = <0x0 0x24000 0x0 0x14>;
>> @@ -312,6 +360,17 @@
>> };
>> };
>>
>> + i2c_ao: i2c@5000 {
>
> Can you keep the same "i2c_AO" as in meson-gx ?
>
>
sure, can do
> [...]
>
>> + };
>> +
>> uart_AO: serial@3000 {
>> compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
>> reg = <0x0 0x3000 0x0 0x18>;
>>
>
> Neil
>
> .
>
--
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] arm64: dts: ls1088a: add fsl-mc hardware resource manager node
From: Ioana Ciornei @ 2017-11-17 13:59 UTC (permalink / raw)
To: Shawn Guo
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20171117123530.GA25390@dragon>
> On Thu, Nov 16, 2017 at 02:24:49PM +0000, Ioana Ciornei wrote:
> ...
> > > > + fsl_mc: fsl-mc@80c000000 {
> > >
> > > The unit-address of the node should be somehow related to 'reg'
> > > property. Can you please help me understand how they are related?
> >
> > The unit-address of the fsl-mc node is the base address of the MC portal
> described in the first region of the 'reg' property and formed using the 2
> address cells.
> > Hope this helps.
>
> Ah, sorry, I forgot that the address-cells is 2.
>
> >
> > >
> > > > + compatible = "fsl,qoriq-mc";
> > > > + reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal
> base */
> > > > + <0x00000000 0x08340000 0 0x40000>; /* MC control
> reg */
> > > > + msi-parent = <&its>;
> > > > + #address-cells = <3>;
> > > > + #size-cells = <1>;
> > > > +
> > > > + /*
> > > > + * Region type 0x0 - MC portals
> > > > + * Region type 0x1 - QBMAN portals
> > > > + */
> > > > + ranges = <0x0 0x0 0x0 0x8 0x0c000000 0x4000000
> > > > + 0x1 0x0 0x0 0x8 0x18000000 0x8000000>;
> > > > +
> > > > + dpmacs {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + dpmac1: dpmac@1 {
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <1>;
> > > > + };
> > >
> > > Please have a newline in between nodes.
> >
> > Will do.
> >
> > Should I send a rework of this patch right away or better to wait for the
> merge window to close?
>
> Either way is fine, as I will rebase my branch to v4.15-rc1 after merge window
> closes.
>
> > > > + dpmac2: dpmac@2 {
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <2>;
> > > > + };
> > > > + dpmac3: dpmac@3 {
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <3>;
> > > > + };
> > > > + dpmac4: dpmac@4 {
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <4>;
> > > > + };
> > > > + dpmac5: dpmac@5 {
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <5>;
> > > > + };
> > > > + dpmac6: dpmac@6 {
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <6>;
> > > > + };
> > > > + dpmac7: dpmac@7 {
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <7>;
> > > > + };
> > > > + dpmac8: dpmac@8 {
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <8>;
> > > > + };
> > > > + dpmac9: dpmac@9 {
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <9>;
> > > > + };
> > > > + dpmac10: dpmac@10 {
>
> Just noticed this - the unit-address should be hex number, so it should be
> dpmac@a rather than dpmac@10, I think.
>
Yes, that is right, it should be dpmac@a. Will change it.
Ioana
> Shawn
>
> > > > + compatible = "fsl,qoriq-mc-dpmac";
> > > > + reg = <0xa>;
> > > > + };
> > > > + };
> > > > + };
> > > > +
> > > > psci {
> > > > compatible = "arm,psci-0.2";
> > > > method = "smc";
> > > > --
> > > > 1.9.1
> > > >
> > > >
> >
--
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 1/5] dt-bindings: i2c: update documentation for the Meson-AXG
From: Yixun Lan @ 2017-11-17 13:47 UTC (permalink / raw)
To: Neil Armstrong, Wolfram Sang, Rob Herring, Mark Rutland,
linux-i2c, devicetree, Kevin Hilman
Cc: yixun.lan, Jerome Brunet, Carlo Caione, Jian Hu, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <03c9ea24-5f8d-f5dd-6e96-f53f56db530c@baylibre.com>
Hi Neil
On 11/17/17 21:02, Neil Armstrong wrote:
> On 17/11/2017 09:02, Yixun Lan wrote:
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> Update the doc to explicitly add Meson-AXG to support list
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>> ---
>> Documentation/devicetree/bindings/i2c/i2c-meson.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-meson.txt b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
>> index 611b934c7e10..3097d2b44dad 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-meson.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
>> @@ -2,6 +2,7 @@ Amlogic Meson I2C controller
>>
>> Required properties:
>> - compatible: must be "amlogic,meson6-i2c" or "amlogic,meson-gxbb-i2c"
>> + "amlogic,meson-axg-i2c"
>
> Hi Yixun, Jian,
>
> Maybe you should reformat by using :
> - compatible: must be :
> "amlogic,meson6-i2c" for Meson8 and compatible SoCs
> "amlogic,meson-gxbb-i2c" for GXBB and compatible SoCs
> "amlogic,meson-axg-i2c"for AXG and compatible SoCs
>
> Neil
>
sure, we can do this.
thanks for the review
>> - reg: physical address and length of the device registers
>> - interrupts: a single interrupt specifier
>> - clocks: clock for the device
>>
>
> .
>
^ permalink raw reply
* Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation
From: Rob Herring @ 2017-11-17 13:41 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Laurent Pinchart, Hans Verkuil,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:MEDIA DRIVERS FOR RENESAS - FCP,
tomoharu.fukawa.eb-zM6kxYcvzFBBDgjK7y7TUQ, Kieran Bingham,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171115225814.GJ12677-ofJ5d6taAgIKcZgyrm77+z0dHWC0CY5B@public.gmane.org>
On Wed, Nov 15, 2017 at 4:58 PM, Niklas Söderlund
<niklas.soderlund-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org> wrote:
> Hi Rob,
>
> Thanks for your feedback, much appreciated!
>
> On 2017-11-15 14:02:26 -0600, Rob Herring wrote:
>> On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote:
>> > Document the devicetree bindings for the CSI-2 inputs available on Gen3.
>> >
>> > There is a need to add a custom property 'renesas,id' and to define
>> > which CSI-2 input is described in which endpoint under the port@1 node.
>> > This information is needed since there are a set of predefined routes
>> > between each VIN and CSI-2 block. This routing table will be kept
>> > inside the driver but in order for it to act on it it must know which
>> > VIN and CSI-2 is which.
>> >
>> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>
>> > ---
>> > .../devicetree/bindings/media/rcar_vin.txt | 116 ++++++++++++++++++---
>> > 1 file changed, 104 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > index 6e4ef8caf759e5d3..df1abd0fb20386f8 100644
>> > --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
>> > @@ -2,8 +2,12 @@ Renesas R-Car Video Input driver (rcar_vin)
>> > -------------------------------------------
>> >
>> > The rcar_vin device provides video input capabilities for the Renesas R-Car
>> > -family of devices. The current blocks are always slaves and suppot one input
>> > -channel which can be either RGB, YUYV or BT656.
>> > +family of devices.
>> > +
>> > +Each VIN instance has a single parallel input that supports RGB and YUV video,
>> > +with both external synchronization and BT.656 synchronization for the latter.
>> > +Depending on the instance the VIN input is connected to external SoC pins, or
>> > +on Gen3 to a CSI-2 receiver.
>> >
>> > - compatible: Must be one or more of the following
>> > - "renesas,vin-r8a7795" for the R8A7795 device
>> > @@ -28,21 +32,38 @@ channel which can be either RGB, YUYV or BT656.
>> > Additionally, an alias named vinX will need to be created to specify
>> > which video input device this is.
>> >
>> > -The per-board settings:
>> > +The per-board settings Gen2:
>> > - port sub-node describing a single endpoint connected to the vin
>> > as described in video-interfaces.txt[1]. Only the first one will
>> > be considered as each vin interface has one input port.
>> >
>> > - These settings are used to work out video input format and widths
>> > - into the system.
>> > +The per-board settings Gen3:
>> > +
>> > +Gen3 can support both a single connected parallel input source from
>> > +external SoC pins (port0) and/or multiple parallel input sources from
>> > +local SoC CSI-2 receivers (port1) depending on SoC.
>> >
>> > +- renesas,id - ID number of the VIN, VINx in the documentation.
>>
>> Why is this needed? We try to avoid indexes unless that's the only way a
>> device is addressed (and then we use reg).
>
> This is unfortunately needed (or something similar) as there is a
> register in one VIN instance which controls the routing of the incoming
> CSI-2 video streams, not only to itself, but also to other VIN instances
> inside the same SoC.
>
> To be more specific I will try to clarify this using the R-Car H3 as an
> example. On the H3 there are 8 instances of the capture hardware (VIN0 -
> VIN7) and 3 instances off CSI-2 receivers (CSI20, CSI40 and CSI41) which
> receives CSI-2 streams, split the possible multiple virtual channels
> (VC) encoded in CSI-2 streams and forwards it to the VIN's.
>
> The problem is that VIN0 and VIN4 are different from the other VIN's,
> they have one register (CHSEL) which controls the limited number of
> possible routes of video streams between a CSI-2 + VC to a specific VIN.
> The CHSEL register in VIN0 controls the routing for VIN0-3 and the one
> in VIN4 controls VIN4-7 (the two subgroups are similar so lets only
> consider VIN0-3).
>
> There are only a handful of routes possible and the kicker is that
> changing the CHSEL value in VIN0, directly reflects all routes for
> VIN0-VIN3 per this table:
>
> CHSEL reg in VIN0: 0 1 2 3 4
> Video sent to VIN0: CSI40/VC0 CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI20/VC0
> Video sent to VIN1: CSI20/VC0 CSI40/VC1 CSI40/VC0 CSI40/VC1 CSI20/VC1
> Video sent to VIN2: CSI20/VC1 CSI40/VC0 CSI20/VC0 CSI40/VC2 CSI20/VC2
> Video sent to VIN3: CSI40/VC1 CSI20/VC1 CSI20/VC1 CSI40/VC3 CSI20/VC3
>
> So if CHSEL in VIN0 is set to 2 the following routes are active: VIN0:
> CSI40/VC1, VIN1: CSI40/VC0, VIN2: CSI20/VC0, CSI20/VC1. These routing
> tables are different for most SoCs in the R-Car Gen3 family, and are
> kept inside the driver code.
>
> So the renesas,id properly is used so that the rcar-vin driver knows
> which of the driver instances corresponds to a specific VINx number from
> the documentation so that using the media device API the correct links
> can be added and that the routing table is enforced so a user can't try
> to activate a CSI-2 + VC to a VIN link which is not possible due to
> other routes already being active.
>
> I agree that if possible I would like to not have the need for this
> property, but I can't think of another way on how to give this knowledge
> to the driver in a better way. I'm happy to try out other ideas :-)
>
> Dose this explanation make sens to you?
Yes. Thank you. It would be could to summarize this in the binding and
perhaps capture all of this information in the driver if you haven't
already.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/7] pinctrl: sh-pfc: r8a77995: Add CAN FD support
From: Geert Uytterhoeven @ 2017-11-17 13:31 UTC (permalink / raw)
To: Ulrich Hecht
Cc: Linux-Renesas, linux-can, devicetree@vger.kernel.org,
Wolfram Sang, Simon Horman, Magnus Damm, Chris Paterson,
Ramesh Shanmugasundaram
In-Reply-To: <1510915289-15059-3-git-send-email-ulrich.hecht+renesas@gmail.com>
On Fri, Nov 17, 2017 at 11:41 AM, Ulrich Hecht
<ulrich.hecht+renesas@gmail.com> wrote:
> This patch adds CAN FD[0-1] pinmux support to the r8a77995 SoC.
>
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in sh-pfc-for-v4.16.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/7] pinctrl: sh-pfc: r8a77995: Add CAN support
From: Geert Uytterhoeven @ 2017-11-17 13:30 UTC (permalink / raw)
To: Ulrich Hecht
Cc: Linux-Renesas, linux-can, devicetree@vger.kernel.org,
Wolfram Sang, Simon Horman, Magnus Damm, Chris Paterson,
Ramesh Shanmugasundaram
In-Reply-To: <1510915289-15059-2-git-send-email-ulrich.hecht+renesas@gmail.com>
On Fri, Nov 17, 2017 at 11:41 AM, Ulrich Hecht
<ulrich.hecht+renesas@gmail.com> wrote:
> This patch adds CAN[0-1] pinmux support to the r8a77995 SoC.
>
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in sh-pfc-for-v4.16.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] omapdrm: hdmi4: Correct the SoC revision matching
From: Peter Ujfalusi @ 2017-11-17 13:23 UTC (permalink / raw)
To: Tomi Valkeinen, laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
jsarha-l0cyMroinI0
Cc: airlied-cv59FeDIM0c, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk,
stable-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <6b859419-62fa-a7ff-d3da-0a7dd03ddc11-l0cyMroinI0@public.gmane.org>
On 2017-11-17 14:55, Tomi Valkeinen wrote:
> On 17/11/17 10:00, Peter Ujfalusi wrote:
>> I believe the intention of the commit 2c9fc9bf45f8
>> ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
>> was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions,
>> like omap4460.
>>
>> By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a
>> same way as it would treat omap4430 ES1.x
>>
>> This breaks HDMI audio on OMAP4460 devices (PandaES for example).
>>
>> Correct the match rule so we are not going to get false positive match.
>>
>> Fixes: 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
>>
>> CC: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 4.14
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
>> ---
>> drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 17 ++++++++++++++---
>> 1 file changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
>> index 62e451162d96..07945a40c33a 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
>> @@ -902,9 +902,20 @@ static const struct hdmi4_features hdmi4_es3_features = {
>> };
>>
>> static const struct soc_device_attribute hdmi4_soc_devices[] = {
>> - { .family = "OMAP4", .revision = "ES1.?", .data = &hdmi4_es1_features },
>> - { .family = "OMAP4", .revision = "ES2.?", .data = &hdmi4_es2_features },
>> - { .family = "OMAP4", .data = &hdmi4_es3_features },
>> + {
>> + .machine = "OMAP4430",
>> + .revision = "ES1.?",
>> + .data = &hdmi4_es1_features,
>> + },
>> + {
>> + .machine = "OMAP4430",
>> + .revision = "ES2.?",
>> + .data = &hdmi4_es2_features,
>> + },
>> + {
>> + .family = "OMAP4",
>> + .data = &hdmi4_es3_features,
>> + },
>> { /* sentinel */ }
>> };
>>
>>
>
> Looks good to me.
>
> Was there are reason to change the format from single-line to multi-line?
in one line it would beyond 80 and just breaking the .data to new line
looked ugly.
> While at it, I think it would make sense to rename hdmi4_es3_features
> to... hdmi4_features? It's not "ES3" in any way.
Yes, that would make sense, but then the hdmi4_es1/2 is not really
correct either as it should be omap4430_es1/2 ...
I'll resend it on Monday with this change.
>
> Tomi
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
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] ARM64: dts: meson-axg: add ethernet mac controller
From: Neil Armstrong @ 2017-11-17 13:12 UTC (permalink / raw)
To: Yixun Lan, devicetree, Kevin Hilman
Cc: Jerome Brunet, Giuseppe Cavallaro, Alexandre Torgue, Carlo Caione,
linux-amlogic, linux-arm-kernel, linux-kernel, netdev
In-Reply-To: <20171113080155.2463-1-yixun.lan@amlogic.com>
On 13/11/2017 09:01, Yixun Lan wrote:
> Add DT info for the stmmac ethernet MAC which found in
> the Amlogic's Meson-AXG SoC, also describe the ethernet
> pinctrl & clock information here.
>
> This is tested in the S400 dev board which use a RTL8211F PHY,
> and the pins connect to the 'eth_rgmii_y_pins' group.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 ++++
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 53 ++++++++++++++++++++++++++
> 2 files changed, 60 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 9eb6aaee155d..7b39a9fe2b0f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -21,3 +21,10 @@
> status = "okay";
> };
>
> +ðmac {
> + status = "okay";
> + phy-mode = "rgmii";
> +
> + pinctrl-0 = <ð_rgmii_y_pins>;
> + pinctrl-names = "default";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index 65945c6c8b65..57faaa9d8013 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -157,6 +157,19 @@
> #address-cells = <0>;
> };
>
> + ethmac: ethernet@ff3f0000 {
> + compatible = "amlogic,meson-axg-dwmac", "amlogic,meson-gxbb-dwmac", "snps,dwmac";
> + reg = <0x0 0xff3f0000 0x0 0x10000
> + 0x0 0xff634540 0x0 0x8>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "macirq";
> + status = "disabled";
> + clocks = <&clkc CLKID_ETH>,
> + <&clkc CLKID_FCLK_DIV2>,
> + <&clkc CLKID_MPLL2>;
> + clock-names = "stmmaceth", "clkin0", "clkin1";
> + };
> +
> hiubus: hiubus@ff63c000 {
> compatible = "simple-bus";
> reg = <0x0 0xff63c000 0x0 0x1c00>;
> @@ -203,6 +216,46 @@
> #gpio-cells = <2>;
> gpio-ranges = <&pinctrl_periphs 0 0 86>;
> };
> +
> + eth_rgmii_x_pins: eth-x-rgmii {
> + mux {
> + groups = "eth_mdio_x",
> + "eth_mdc_x",
> + "eth_rgmii_rx_clk_x",
> + "eth_rx_dv_x",
> + "eth_rxd0_x",
> + "eth_rxd1_x",
> + "eth_rxd2_rgmii",
> + "eth_rxd3_rgmii",
> + "eth_rgmii_tx_clk",
> + "eth_txen_x",
> + "eth_txd0_x",
> + "eth_txd1_x",
> + "eth_txd2_rgmii",
> + "eth_txd3_rgmii";
> + function = "eth";
> + };
> + };
> +
> + eth_rgmii_y_pins: eth-y-rgmii {
> + mux {
> + groups = "eth_mdio_y",
> + "eth_mdc_y",
> + "eth_rgmii_rx_clk_y",
> + "eth_rx_dv_y",
> + "eth_rxd0_y",
> + "eth_rxd1_y",
> + "eth_rxd2_rgmii",
> + "eth_rxd3_rgmii",
> + "eth_rgmii_tx_clk",
> + "eth_txen_y",
> + "eth_txd0_y",
> + "eth_txd1_y",
> + "eth_txd2_rgmii",
> + "eth_txd3_rgmii";
> + function = "eth";
> + };
> + };
> };
> };
>
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: Add the support for display5 equipped with Mitsubishi (800x480) display
From: Shawn Guo @ 2017-11-17 13:10 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Rob Herring, Rob Herring, Mark Rutland, Russell King,
Sascha Hauer, Fabio Estevam, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171117102404.6678-1-lukma-ynQEQJNshbs@public.gmane.org>
On Fri, Nov 17, 2017 at 11:24:03AM +0100, Lukasz Majewski wrote:
> This is the support for aa070mc01-ca1 Mitsubishi display.
>
> Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> .../imx6q-display5-mitsubishi-aa070-800x480.dts | 51 ++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6q-display5-mitsubishi-aa070-800x480.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d9d0c82e7d20..10b3ad078dea 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6q-cm-fx6.dtb \
> imx6q-cubox-i.dtb \
> imx6q-dfi-fs700-m60.dtb \
> + imx6q-display5-mitsubishi-aa070-800x480.dtb \
> imx6q-display5-tianma-tm070-1280x768.dtb \
> imx6q-dmo-edmqmx6.dtb \
> imx6q-evi.dtb \
<snip>
> +#include "imx6q-display5.dtsi"
> +
> +&panel {
> + compatible = "mitsubishi,aa070mc01-ca1";
> +};
How many DTB files do you want to add for this display5 board? It's
obvious no fun to maintain a bunch of DTB files for all the panels this
board can support. Let's stop right here.
Shawn
> +
> +&ldb {
> + lvds0: lvds-channel@0 {
> + fsl,data-mapping = "spwg";
> + fsl,data-width = <24>;
> + };
> +};
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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