* Re: [PATCH net-next v3 3/4] dt: bindings: add ethernet phy eee-broken-modes option documentation
From: Andreas Färber @ 2016-11-28 12:22 UTC (permalink / raw)
To: Jerome Brunet, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Florian Fainelli, Carlo Caione, Kevin Hilman, Giuseppe Cavallaro,
Alexandre TORGUE, Martin Blumenstingl, Andre Roth, Andrew Lunn,
Neil Armstrong, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480326409-25419-4-git-send-email-jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> Signed-off-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
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 net-next v3 2/4] dt-bindings: net: add EEE capability constants
From: Andreas Färber @ 2016-11-28 12:21 UTC (permalink / raw)
To: Jerome Brunet, netdev, devicetree
Cc: Florian Fainelli, Carlo Caione, Kevin Hilman, Giuseppe Cavallaro,
Alexandre TORGUE, Martin Blumenstingl, Andre Roth, Andrew Lunn,
Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <1480326409-25419-3-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/dt-bindings/net/mdio.h
Tested-by: Andreas Färber <afaerber@suse.de>
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH net-next v3 1/4] net: phy: add an option to disable EEE advertisement
From: Andreas Färber @ 2016-11-28 12:20 UTC (permalink / raw)
To: Jerome Brunet, netdev
Cc: devicetree, Florian Fainelli, Alexandre TORGUE, Andrew Lunn,
Martin Blumenstingl, Kevin Hilman, Neil Armstrong, linux-kernel,
Andre Roth, linux-amlogic, Carlo Caione, Giuseppe Cavallaro,
linux-arm-kernel
In-Reply-To: <1480326409-25419-2-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> This patch adds an option to disable EEE advertisement in the generic PHY
> by providing a mask of prohibited modes corresponding to the value found in
> the MDIO_AN_EEE_ADV register.
>
> On some platforms, PHY Low power idle seems to be causing issues, even
> breaking the link some cases. The patch provides a convenient way for these
> platforms to disable EEE advertisement and work around the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/net/phy/phy.c | 3 ++
> drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
> include/linux/phy.h | 3 ++
> 3 files changed, 77 insertions(+), 9 deletions(-)
Tested-by: Andreas Färber <afaerber@suse.de>
With this and the corresponding .dts change, Odroid-C2 survived a
317-package zypper update for me.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: da850-lcdk: specify the maximum pixel clock rate for tilcdc
From: Bartosz Golaszewski @ 2016-11-28 12:15 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: linux-devicetree, LKML, linux-drm, Bartosz Golaszewski,
Tomi Valkeinen, Jyri Sarha, arm-soc, Laurent Pinchart
In-Reply-To: <1480335328-4010-1-git-send-email-bgolaszewski@baylibre.com>
Due to memory throughput constraints any display mode for which the
pixel clock rate exceeds the recommended value of 37500 KHz must be
filtered out.
Specify the max-pixelclock property for the display node for
da850-lcdk.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index d864f11..1283263 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -285,6 +285,7 @@
&display {
status = "okay";
+ max-pixelclock = <37500>;
};
&display_out {
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v2 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Bartosz Golaszewski @ 2016-11-28 12:15 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: linux-devicetree, LKML, linux-drm, Bartosz Golaszewski,
Tomi Valkeinen, Jyri Sarha, arm-soc, Laurent Pinchart
In-Reply-To: <1480335328-4010-1-git-send-email-bgolaszewski@baylibre.com>
Add the dumb-vga-dac node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 58 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
2 files changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 711b9ad..d864f11 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -50,6 +50,53 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga_bridge {
+ compatible = "dumb-vga-dac";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&display_out_vga>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -235,3 +282,14 @@
&memctrl {
status = "okay";
};
+
+&display {
+ status = "okay";
+};
+
+&display_out {
+ display_out_vga: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4070619..5f4ba2e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -454,6 +454,23 @@
reg = <0x213000 0x1000>;
interrupts = <52>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ display_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
};
};
aemif: aemif@68000000 {
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v2 0/2] ARM: dts: da850: tilcdc related DT changes
From: Bartosz Golaszewski @ 2016-11-28 12:15 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: linux-devicetree, LKML, linux-drm, Bartosz Golaszewski,
Tomi Valkeinen, Jyri Sarha, arm-soc, Laurent Pinchart
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
Bartosz Golaszewski (2):
ARM: dts: da850-lcdk: add the dumb-vga-dac node
ARM: dts: da850-lcdk: specify the maximum pixel clock rate for tilcdc
arch/arm/boot/dts/da850-lcdk.dts | 59 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
2 files changed, 76 insertions(+)
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v10 3/4] dtc: Plugin and fixup support
From: Pantelis Antoniou @ 2016-11-28 12:10 UTC (permalink / raw)
To: David Gibson
Cc: Jon Loeliger, Grant Likely, Frank Rowand, Rob Herring, Jan Luebbe,
Sascha Hauer, Phil Elwell, Simon Glass, Maxime Ripard,
Thomas Petazzoni, Boris Brezillon, Antoine Tenart, Stephen Boyd,
Devicetree Compiler, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161128041228.GJ30927-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
> On Nov 28, 2016, at 06:12 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>
> On Fri, Nov 25, 2016 at 02:32:10PM +0200, Pantelis Antoniou wrote:
>> This patch enable the generation of symbols & local fixup information
>> for trees compiled with the -@ (--symbols) option.
>>
>> Using this patch labels in the tree and their users emit information
>> in __symbols__ and __local_fixups__ nodes.
>>
>> The __fixups__ node make possible the dynamic resolution of phandle
>> references which are present in the plugin tree but lie in the
>> tree that are applying the overlay against.
>>
>> While there is a new magic number for dynamic device tree/overlays blobs
>> it is by default enabled. Remember to use -M to generate compatible
>> blobs.
>>
>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> Signed-off-by: Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> ---
>> Documentation/manual.txt | 25 +++++-
>> checks.c | 8 +-
>> dtc-lexer.l | 5 ++
>> dtc-parser.y | 50 +++++++++--
>> dtc.c | 39 +++++++-
>> dtc.h | 20 ++++-
>> fdtdump.c | 2 +-
>> flattree.c | 17 ++--
>> fstree.c | 2 +-
>> libfdt/fdt.c | 2 +-
>> libfdt/fdt.h | 3 +-
>> livetree.c | 225 ++++++++++++++++++++++++++++++++++++++++++++++-
>> tests/mangle-layout.c | 7 +-
>> 13 files changed, 375 insertions(+), 30 deletions(-)
>>
>> diff --git a/Documentation/manual.txt b/Documentation/manual.txt
>> index 398de32..094893b 100644
>> --- a/Documentation/manual.txt
>> +++ b/Documentation/manual.txt
>> @@ -119,6 +119,24 @@ Options:
>> Make space for <number> reserve map entries
>> Relevant for dtb and asm output only.
>>
>> + -@
>> + Generates a __symbols__ node at the root node of the resulting blob
>> + for any node labels used, and for any local references using phandles
>> + it also generates a __local_fixups__ node that tracks them.
>> +
>> + When using the /plugin/ tag all unresolved label references to
>> + be tracked in the __fixups__ node, making dynamic resolution possible.
>> +
>> + -A
>> + Generate automatically aliases for all node labels. This is similar to
>> + the -@ option (the __symbols__ node contain identical information) but
>> + the semantics are slightly different since no phandles are automatically
>> + generated for labeled nodes.
>> +
>> + -M
>> + Generate blobs with the old FDT magic number for device tree objects.
>> + By default blobs use the DTBO FDT magic number instead.
>> +
>> -S <bytes>
>> Ensure the blob at least <bytes> long, adding additional
>> space if needed.
>> @@ -146,13 +164,18 @@ Additionally, dtc performs various sanity checks on the tree.
>> Here is a very rough overview of the layout of a DTS source file:
>>
>>
>> - sourcefile: list_of_memreserve devicetree
>> + sourcefile: versioninfo plugindecl list_of_memreserve devicetree
>>
>> memreserve: label 'memreserve' ADDR ADDR ';'
>> | label 'memreserve' ADDR '-' ADDR ';'
>>
>> devicetree: '/' nodedef
>>
>> + versioninfo: '/' 'dts-v1' '/' ';'
>> +
>> + plugindecl: '/' 'plugin' '/' ';'
>> + | /* empty */
>> +
>> nodedef: '{' list_of_property list_of_subnode '}' ';'
>>
>> property: label PROPNAME '=' propdata ';'
>> diff --git a/checks.c b/checks.c
>> index 2bd27a4..4292f4b 100644
>> --- a/checks.c
>> +++ b/checks.c
>> @@ -487,8 +487,12 @@ static void fixup_phandle_references(struct check *c, struct boot_info *bi,
>>
>> refnode = get_node_by_ref(dt, m->ref);
>> if (! refnode) {
>> - FAIL(c, "Reference to non-existent node or label \"%s\"\n",
>> - m->ref);
>> + if (!(bi->versionflags & VF_PLUGIN))
>> + FAIL(c, "Reference to non-existent node or "
>> + "label \"%s\"\n", m->ref);
>> + else /* mark the entry as unresolved */
>> + *((cell_t *)(prop->val.val + m->offset)) =
>> + cpu_to_fdt32(0xffffffff);
>> continue;
>> }
>>
>> diff --git a/dtc-lexer.l b/dtc-lexer.l
>> index 790fbf6..40bbc87 100644
>> --- a/dtc-lexer.l
>> +++ b/dtc-lexer.l
>> @@ -121,6 +121,11 @@ static void lexical_error(const char *fmt, ...);
>> return DT_V1;
>> }
>>
>> +<*>"/plugin/" {
>> + DPRINT("Keyword: /plugin/\n");
>> + return DT_PLUGIN;
>> + }
>> +
>> <*>"/memreserve/" {
>> DPRINT("Keyword: /memreserve/\n");
>> BEGIN_DEFAULT();
>> diff --git a/dtc-parser.y b/dtc-parser.y
>> index 14aaf2e..1a1f660 100644
>> --- a/dtc-parser.y
>> +++ b/dtc-parser.y
>> @@ -19,6 +19,7 @@
>> */
>> %{
>> #include <stdio.h>
>> +#include <inttypes.h>
>>
>> #include "dtc.h"
>> #include "srcpos.h"
>> @@ -33,6 +34,7 @@ extern void yyerror(char const *s);
>>
>> extern struct boot_info *the_boot_info;
>> extern bool treesource_error;
>> +
>
> Extraneous whitespace change here
>
OK.
>> %}
>>
>> %union {
>> @@ -52,9 +54,11 @@ extern bool treesource_error;
>> struct node *nodelist;
>> struct reserve_info *re;
>> uint64_t integer;
>> + unsigned int flags;
>> }
>>
>> %token DT_V1
>> +%token DT_PLUGIN
>> %token DT_MEMRESERVE
>> %token DT_LSHIFT DT_RSHIFT DT_LE DT_GE DT_EQ DT_NE DT_AND DT_OR
>> %token DT_BITS
>> @@ -71,6 +75,8 @@ extern bool treesource_error;
>>
>> %type <data> propdata
>> %type <data> propdataprefix
>> +%type <flags> versioninfo
>> +%type <flags> plugindecl
>> %type <re> memreserve
>> %type <re> memreserves
>> %type <array> arrayprefix
>> @@ -101,16 +107,34 @@ extern bool treesource_error;
>> %%
>>
>> sourcefile:
>> - v1tag memreserves devicetree
>> + versioninfo plugindecl memreserves devicetree
>> + {
>> + the_boot_info = build_boot_info($1 | $2, $3, $4,
>> + guess_boot_cpuid($4));
>> + }
>> + ;
>> +
>> +versioninfo:
>> + v1tag
>> {
>> - the_boot_info = build_boot_info($2, $3,
>> - guess_boot_cpuid($3));
>> + $$ = VF_DT_V1;
>> }
>> ;
>>
>> v1tag:
>> DT_V1 ';'
>> + | DT_V1
>> | DT_V1 ';' v1tag
>> +
>> +plugindecl:
>> + DT_PLUGIN ';'
>> + {
>> + $$ = VF_PLUGIN;
>> + }
>> + | /* empty */
>> + {
>> + $$ = 0;
>> + }
>> ;
>>
>> memreserves:
>> @@ -161,10 +185,19 @@ devicetree:
>> {
>> struct node *target = get_node_by_ref($1, $2);
>>
>> - if (target)
>> + if (target) {
>> merge_nodes(target, $3);
>> - else
>> - ERROR(&@2, "Label or path %s not found", $2);
>> + } else {
>> + /*
>> + * We rely on the rule being always:
>> + * versioninfo plugindecl memreserves devicetree
>> + * so $-1 is what we want (plugindecl)
>> + */
>> + if ($<flags>-1 & VF_PLUGIN)
>
> o_O... ok. I've never seen negative value references before. Can you
> provide a link to some documentation saying this is actually supported
> usage in bison? I wasn't able to find it when I looked.
>
There is a section about inherited attributes in the flex & bison book by O’Reily.
https://books.google.gr/books?id=3Sr1V5J9_qMC&lpg=PP1&dq=flex%20bison&hl=el&pg=PP1#v=onepage&q=flex%20bison&f=false
There’s a direct link to the 2nd Edition of lex & yacc:
https://books.google.gr/books?id=fMPxfWfe67EC&lpg=PA183&ots=RcRSji2NAT&dq=yacc%20inherited%20attributes&hl=el&pg=PA183#v=onepage&q=yacc%20inherited%20attributes&f=false
>> + add_orphan_node($1, $3, $2);
>> + else
>> + ERROR(&@2, "Label or path %s not found", $2);
>> + }
>> $$ = $1;
>> }
>> | devicetree DT_DEL_NODE DT_REF ';'
>> @@ -179,6 +212,11 @@ devicetree:
>>
>> $$ = $1;
>> }
>> + | /* empty */
>> + {
>> + /* build empty node */
>> + $$ = name_node(build_node(NULL, NULL), "");
>> + }
>> ;
>>
>> nodedef:
>> diff --git a/dtc.c b/dtc.c
>> index 9dcf640..06e91bc 100644
>> --- a/dtc.c
>> +++ b/dtc.c
>> @@ -32,6 +32,9 @@ int minsize; /* Minimum blob size */
>> int padsize; /* Additional padding to blob */
>> int alignsize; /* Additional padding to blob accroding to the alignsize */
>> int phandle_format = PHANDLE_BOTH; /* Use linux,phandle or phandle properties */
>> +int symbol_fixup_support; /* enable symbols & fixup support */
>> +int auto_label_aliases; /* auto generate labels -> aliases */
>> +int no_dtbo_magic; /* use old FDT magic values for objects */
>>
>> static int is_power_of_2(int x)
>> {
>> @@ -59,7 +62,7 @@ static void fill_fullpaths(struct node *tree, const char *prefix)
>> #define FDT_VERSION(version) _FDT_VERSION(version)
>> #define _FDT_VERSION(version) #version
>> static const char usage_synopsis[] = "dtc [options] <input file>";
>> -static const char usage_short_opts[] = "qI:O:o:V:d:R:S:p:a:fb:i:H:sW:E:hv";
>> +static const char usage_short_opts[] = "qI:O:o:V:d:R:S:p:a:fb:i:H:sW:E:@AMhv";
>> static struct option const usage_long_opts[] = {
>> {"quiet", no_argument, NULL, 'q'},
>> {"in-format", a_argument, NULL, 'I'},
>> @@ -78,6 +81,9 @@ static struct option const usage_long_opts[] = {
>> {"phandle", a_argument, NULL, 'H'},
>> {"warning", a_argument, NULL, 'W'},
>> {"error", a_argument, NULL, 'E'},
>> + {"symbols", no_argument, NULL, '@'},
>> + {"auto-alias", no_argument, NULL, 'A'},
>> + {"no-dtbo-magic", no_argument, NULL, 'M'},
>> {"help", no_argument, NULL, 'h'},
>> {"version", no_argument, NULL, 'v'},
>> {NULL, no_argument, NULL, 0x0},
>> @@ -109,6 +115,9 @@ static const char * const usage_opts_help[] = {
>> "\t\tboth - Both \"linux,phandle\" and \"phandle\" properties",
>> "\n\tEnable/disable warnings (prefix with \"no-\")",
>> "\n\tEnable/disable errors (prefix with \"no-\")",
>> + "\n\tEnable symbols/fixup support",
>> + "\n\tEnable auto-alias of labels",
>> + "\n\tDo not use DTBO magic value for plugin objects",
>> "\n\tPrint this help and exit",
>> "\n\tPrint version and exit",
>> NULL,
>> @@ -153,7 +162,7 @@ static const char *guess_input_format(const char *fname, const char *fallback)
>> fclose(f);
>>
>> magic = fdt32_to_cpu(magic);
>> - if (magic == FDT_MAGIC)
>> + if (magic == FDT_MAGIC || magic == FDT_MAGIC_DTBO)
>> return "dtb";
>>
>> return guess_type_by_name(fname, fallback);
>> @@ -172,6 +181,7 @@ int main(int argc, char *argv[])
>> FILE *outf = NULL;
>> int outversion = DEFAULT_FDT_VERSION;
>> long long cmdline_boot_cpuid = -1;
>> + fdt32_t out_magic = FDT_MAGIC;
>>
>> quiet = 0;
>> reservenum = 0;
>> @@ -249,6 +259,16 @@ int main(int argc, char *argv[])
>> parse_checks_option(false, true, optarg);
>> break;
>>
>> + case '@':
>> + symbol_fixup_support = 1;
>> + break;
>> + case 'A':
>> + auto_label_aliases = 1;
>> + break;
>> + case 'M':
>> + no_dtbo_magic = 1;
>> + break;
>> +
>> case 'h':
>> usage(NULL);
>> default:
>> @@ -306,6 +326,14 @@ int main(int argc, char *argv[])
>> fill_fullpaths(bi->dt, "");
>> process_checks(force, bi);
>>
>> + if (auto_label_aliases)
>> + generate_label_tree(bi->dt, "aliases", false);
>> +
>> + if (symbol_fixup_support) {
>> + generate_label_tree(bi->dt, "__symbols__", true);
>> + generate_fixups_tree(bi->dt);
>
> Hang on.. this doesn't seem right. I thought -@ controlled the
> __symbols__ side (i.e. the part upon which we overlay) rather than the
> fixups side (the part which overlays). A dtbo could certainly have
> both, of course, but for base trees, wouldn't you have symbols without
> fixups? And should it be illegal to try to build a /plugin/ without
> -@?
It does control both for now. For base trees having the fixup nodes
will allow us to do probe order dependency tracking in the future.
For plugins we need the __symbols__ node to support stacked overlays, i.e.
overlays referring label that were introduced by a previous overlay.
For plugins there is no requirement for now to actually contain references to
be resolved. It can easily be enforced though.
>
>> + }
>> +
>> if (sort)
>> sort_tree(bi);
>>
>> @@ -318,12 +346,15 @@ int main(int argc, char *argv[])
>> outname, strerror(errno));
>> }
>>
>> + if (!no_dtbo_magic && (bi->versionflags & VF_PLUGIN))
>> + out_magic = FDT_MAGIC_DTBO;
>> +
>> if (streq(outform, "dts")) {
>> dt_to_source(outf, bi);
>> } else if (streq(outform, "dtb")) {
>> - dt_to_blob(outf, bi, outversion);
>> + dt_to_blob(outf, bi, out_magic, outversion);
>> } else if (streq(outform, "asm")) {
>> - dt_to_asm(outf, bi, outversion);
>> + dt_to_asm(outf, bi, out_magic, outversion);
>> } else if (streq(outform, "null")) {
>> /* do nothing */
>> } else {
>> diff --git a/dtc.h b/dtc.h
>> index 32009bc..581b3bf 100644
>> --- a/dtc.h
>> +++ b/dtc.h
>> @@ -55,6 +55,9 @@ extern int minsize; /* Minimum blob size */
>> extern int padsize; /* Additional padding to blob */
>> extern int alignsize; /* Additional padding to blob accroding to the alignsize */
>> extern int phandle_format; /* Use linux,phandle or phandle properties */
>> +extern int symbol_fixup_support;/* enable symbols & fixup support */
>> +extern int auto_label_aliases; /* auto generate labels -> aliases */
>> +extern int no_dtbo_magic; /* use old FDT magic values for objects */
>>
>> #define PHANDLE_LEGACY 0x1
>> #define PHANDLE_EPAPR 0x2
>> @@ -195,6 +198,7 @@ struct node *build_node_delete(void);
>> struct node *name_node(struct node *node, char *name);
>> struct node *chain_node(struct node *first, struct node *list);
>> struct node *merge_nodes(struct node *old_node, struct node *new_node);
>> +void add_orphan_node(struct node *old_node, struct node *new_node, char *ref);
>>
>> void add_property(struct node *node, struct property *prop);
>> void delete_property_by_name(struct node *node, char *name);
>> @@ -202,6 +206,8 @@ void delete_property(struct property *prop);
>> void add_child(struct node *parent, struct node *child);
>> void delete_node_by_name(struct node *parent, char *name);
>> void delete_node(struct node *node);
>> +void append_to_property(struct node *node,
>> + char *name, const void *data, int len);
>>
>> const char *get_unitname(struct node *node);
>> struct property *get_property(struct node *node, const char *propname);
>> @@ -237,14 +243,22 @@ struct reserve_info *add_reserve_entry(struct reserve_info *list,
>>
>>
>> struct boot_info {
>> + unsigned int versionflags;
>> struct reserve_info *reservelist;
>> struct node *dt; /* the device tree */
>> uint32_t boot_cpuid_phys;
>> };
>>
>> -struct boot_info *build_boot_info(struct reserve_info *reservelist,
>> +/* version flags definitions */
>> +#define VF_DT_V1 0x0001 /* /dts-v1/ */
>> +#define VF_PLUGIN 0x0002 /* /plugin/ */
>> +
>> +struct boot_info *build_boot_info(unsigned int versionflags,
>> + struct reserve_info *reservelist,
>> struct node *tree, uint32_t boot_cpuid_phys);
>> void sort_tree(struct boot_info *bi);
>> +void generate_label_tree(struct node *dt, char *gen_node_name, bool allocph);
>> +void generate_fixups_tree(struct node *dt);
>>
>> /* Checks */
>>
>> @@ -253,8 +267,8 @@ void process_checks(bool force, struct boot_info *bi);
>>
>> /* Flattened trees */
>>
>> -void dt_to_blob(FILE *f, struct boot_info *bi, int version);
>> -void dt_to_asm(FILE *f, struct boot_info *bi, int version);
>> +void dt_to_blob(FILE *f, struct boot_info *bi, fdt32_t magic, int version);
>> +void dt_to_asm(FILE *f, struct boot_info *bi, fdt32_t magic, int version);
>>
>> struct boot_info *dt_from_blob(const char *fname);
>>
>> diff --git a/fdtdump.c b/fdtdump.c
>> index a9a2484..dd63ac2 100644
>> --- a/fdtdump.c
>> +++ b/fdtdump.c
>> @@ -201,7 +201,7 @@ int main(int argc, char *argv[])
>> p = memchr(p, smagic[0], endp - p - FDT_MAGIC_SIZE);
>> if (!p)
>> break;
>> - if (fdt_magic(p) == FDT_MAGIC) {
>> + if (fdt_magic(p) == FDT_MAGIC || fdt_magic(p) == FDT_MAGIC_DTBO) {
>> /* try and validate the main struct */
>> off_t this_len = endp - p;
>> fdt32_t max_version = 17;
>> diff --git a/flattree.c b/flattree.c
>> index a9d9520..57d76cf 100644
>> --- a/flattree.c
>> +++ b/flattree.c
>> @@ -335,6 +335,7 @@ static struct data flatten_reserve_list(struct reserve_info *reservelist,
>> }
>>
>> static void make_fdt_header(struct fdt_header *fdt,
>> + fdt32_t magic,
>> struct version_info *vi,
>> int reservesize, int dtsize, int strsize,
>> int boot_cpuid_phys)
>> @@ -345,7 +346,7 @@ static void make_fdt_header(struct fdt_header *fdt,
>>
>> memset(fdt, 0xff, sizeof(*fdt));
>>
>> - fdt->magic = cpu_to_fdt32(FDT_MAGIC);
>> + fdt->magic = cpu_to_fdt32(magic);
>> fdt->version = cpu_to_fdt32(vi->version);
>> fdt->last_comp_version = cpu_to_fdt32(vi->last_comp_version);
>>
>> @@ -366,7 +367,7 @@ static void make_fdt_header(struct fdt_header *fdt,
>> fdt->size_dt_struct = cpu_to_fdt32(dtsize);
>> }
>>
>> -void dt_to_blob(FILE *f, struct boot_info *bi, int version)
>> +void dt_to_blob(FILE *f, struct boot_info *bi, fdt32_t magic, int version)
>> {
>> struct version_info *vi = NULL;
>> int i;
>> @@ -390,7 +391,7 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version)
>> reservebuf = flatten_reserve_list(bi->reservelist, vi);
>>
>> /* Make header */
>> - make_fdt_header(&fdt, vi, reservebuf.len, dtbuf.len, strbuf.len,
>> + make_fdt_header(&fdt, magic, vi, reservebuf.len, dtbuf.len, strbuf.len,
>> bi->boot_cpuid_phys);
>>
>> /*
>> @@ -467,7 +468,7 @@ static void dump_stringtable_asm(FILE *f, struct data strbuf)
>> }
>> }
>>
>> -void dt_to_asm(FILE *f, struct boot_info *bi, int version)
>> +void dt_to_asm(FILE *f, struct boot_info *bi, fdt32_t magic, int version)
>> {
>> struct version_info *vi = NULL;
>> int i;
>> @@ -830,6 +831,7 @@ struct boot_info *dt_from_blob(const char *fname)
>> struct node *tree;
>> uint32_t val;
>> int flags = 0;
>> + unsigned int versionflags = VF_DT_V1;
>>
>> f = srcfile_relative_open(fname, NULL);
>>
>> @@ -845,9 +847,12 @@ struct boot_info *dt_from_blob(const char *fname)
>> }
>>
>> magic = fdt32_to_cpu(magic);
>> - if (magic != FDT_MAGIC)
>> + if (magic != FDT_MAGIC && magic != FDT_MAGIC_DTBO)
>> die("Blob has incorrect magic number\n");
>>
>> + if (magic == FDT_MAGIC_DTBO)
>> + versionflags |= VF_PLUGIN;
>
> Not particularly useful yet, but I wonder if we'll want some option to
> force treating dtb input as a plugin, for the case of old plugins
> which don't have the new magic number.
>
It can easily be added.
>> +
>> rc = fread(&totalsize, sizeof(totalsize), 1, f);
>> if (ferror(f))
>> die("Error reading DT blob size: %s\n", strerror(errno));
>> @@ -942,5 +947,5 @@ struct boot_info *dt_from_blob(const char *fname)
>>
>> fclose(f);
>>
>> - return build_boot_info(reservelist, tree, boot_cpuid_phys);
>> + return build_boot_info(versionflags, reservelist, tree, boot_cpuid_phys);
>> }
>> diff --git a/fstree.c b/fstree.c
>> index 6d1beec..54f520b 100644
>> --- a/fstree.c
>> +++ b/fstree.c
>> @@ -86,6 +86,6 @@ struct boot_info *dt_from_fs(const char *dirname)
>> tree = read_fstree(dirname);
>> tree = name_node(tree, "");
>>
>> - return build_boot_info(NULL, tree, guess_boot_cpuid(tree));
>> + return build_boot_info(VF_DT_V1, NULL, tree, guess_boot_cpuid(tree));
>> }
>>
>> diff --git a/libfdt/fdt.c b/libfdt/fdt.c
>> index 22286a1..28d422c 100644
>> --- a/libfdt/fdt.c
>> +++ b/libfdt/fdt.c
>> @@ -57,7 +57,7 @@
>>
>> int fdt_check_header(const void *fdt)
>> {
>> - if (fdt_magic(fdt) == FDT_MAGIC) {
>> + if (fdt_magic(fdt) == FDT_MAGIC || fdt_magic(fdt) == FDT_MAGIC_DTBO) {
>> /* Complete tree */
>> if (fdt_version(fdt) < FDT_FIRST_SUPPORTED_VERSION)
>> return -FDT_ERR_BADVERSION;
>> diff --git a/libfdt/fdt.h b/libfdt/fdt.h
>> index 526aedb..493cd55 100644
>> --- a/libfdt/fdt.h
>> +++ b/libfdt/fdt.h
>> @@ -55,7 +55,7 @@
>> #ifndef __ASSEMBLY__
>>
>> struct fdt_header {
>> - fdt32_t magic; /* magic word FDT_MAGIC */
>> + fdt32_t magic; /* magic word FDT_MAGIC[|_DTBO] */
>> fdt32_t totalsize; /* total size of DT block */
>> fdt32_t off_dt_struct; /* offset to structure */
>> fdt32_t off_dt_strings; /* offset to strings */
>> @@ -93,6 +93,7 @@ struct fdt_property {
>> #endif /* !__ASSEMBLY */
>>
>> #define FDT_MAGIC 0xd00dfeed /* 4: version, 4: total size */
>> +#define FDT_MAGIC_DTBO 0xd00dfdb0 /* DTBO magic */
>> #define FDT_TAGSIZE sizeof(fdt32_t)
>>
>> #define FDT_BEGIN_NODE 0x1 /* Start node: full name */
>> diff --git a/livetree.c b/livetree.c
>> index 3dc7559..f2c86bd 100644
>> --- a/livetree.c
>> +++ b/livetree.c
>> @@ -216,6 +216,31 @@ struct node *merge_nodes(struct node *old_node, struct node *new_node)
>> return old_node;
>> }
>>
>> +void add_orphan_node(struct node *dt, struct node *new_node, char *ref)
>> +{
>> + static unsigned int next_orphan_fragment = 0;
>> + struct node *node = build_node(NULL, NULL);
>> + struct property *p;
>> + struct data d = empty_data;
>> + char *name;
>> +
>> + memset(node, 0, sizeof(*node));
>
> You don't need the memset() now that you're using build_node() above.
>
OK
>> +
>> + d = data_add_marker(d, REF_PHANDLE, ref);
>> + d = data_append_integer(d, 0xffffffff, 32);
>> +
>> + p = build_property("target", d);
>> + add_property(node, p);
>> +
>> + xasprintf(&name, "fragment@%u",
>> + next_orphan_fragment++);
>> + name_node(node, name);
>> + name_node(new_node, "__overlay__");
>
> You can do this more naturally if you do the name_node() here, then
> you can just pass the __overlay__ node into build_node() for the
> fragment@ node instead of having to explicitly add_child.
>
Hmm, I’ll see if I can rework it like this.
>> +
>> + add_child(dt, node);
>> + add_child(node, new_node);
>> +}
>> +
>> struct node *chain_node(struct node *first, struct node *list)
>> {
>> assert(first->next_sibling == NULL);
>> @@ -296,6 +321,23 @@ void delete_node(struct node *node)
>> delete_labels(&node->labels);
>> }
>>
>> +void append_to_property(struct node *node,
>> + char *name, const void *data, int len)
>> +{
>> + struct data d;
>> + struct property *p;
>> +
>> + p = get_property(node, name);
>> + if (p) {
>> + d = data_append_data(p->val, data, len);
>> + p->val = d;
>> + } else {
>> + d = data_append_data(empty_data, data, len);
>> + p = build_property(name, d);
>> + add_property(node, p);
>> + }
>> +}
>> +
>> struct reserve_info *build_reserve_entry(uint64_t address, uint64_t size)
>> {
>> struct reserve_info *new = xmalloc(sizeof(*new));
>> @@ -335,12 +377,14 @@ struct reserve_info *add_reserve_entry(struct reserve_info *list,
>> return list;
>> }
>>
>> -struct boot_info *build_boot_info(struct reserve_info *reservelist,
>> +struct boot_info *build_boot_info(unsigned int versionflags,
>> + struct reserve_info *reservelist,
>> struct node *tree, uint32_t boot_cpuid_phys)
>> {
>> struct boot_info *bi;
>>
>> bi = xmalloc(sizeof(*bi));
>> + bi->versionflags = versionflags;
>> bi->reservelist = reservelist;
>> bi->dt = tree;
>> bi->boot_cpuid_phys = boot_cpuid_phys;
>> @@ -709,3 +753,182 @@ void sort_tree(struct boot_info *bi)
>> sort_reserve_entries(bi);
>> sort_node(bi->dt);
>> }
>> +
>> +/* utility helper to avoid code duplication */
>> +static struct node *build_and_name_child_node(struct node *parent, char *name)
>> +{
>> + struct node *node;
>> +
>> + node = build_node(NULL, NULL);
>> + name_node(node, xstrdup(name));
>> + add_child(parent, node);
>> +
>> + return node;
>> +}
>> +
>> +static void generate_label_tree_internal(struct node *dt, struct node *node,
>> + struct node *an, bool allocph)
>> +{
>> + struct node *c;
>> + struct property *p;
>> + struct label *l;
>> +
>> + /* if if there are labels */
>> + if (node->labels) {
>> + /* now add the label in the node */
>> + for_each_label(node->labels, l) {
>> + /* check whether the label already exists */
>> + p = get_property(an, l->label);
>> + if (p) {
>> + fprintf(stderr, "WARNING: label %s already"
>> + " exists in /%s", l->label,
>> + an->name);
>> + continue;
>> + }
>> +
>> + /* insert it */
>> + p = build_property(l->label,
>> + data_copy_mem(node->fullpath,
>> + strlen(node->fullpath) + 1));
>> + add_property(an, p);
>> + }
>> +
>> + /* force allocation of a phandle for this node */
>> + if (allocph)
>> + (void)get_node_phandle(dt, node);
>> + }
>> +
>> + for_each_child(node, c)
>> + generate_label_tree_internal(dt, c, an, allocph);
>> +}
>> +
>> +void generate_label_tree(struct node *dt, char *gen_node_name, bool allocph)
>> +{
>> + struct node *an;
>> +
>> + for_each_child(dt, an)
>> + if (streq(gen_node_name, an->name))
>> + break;
>> +
>> + if (!an)
>> + an = build_and_name_child_node(dt, gen_node_name);
>> + if (!an)
>> + die("Could not build label node /%s\n", gen_node_name);
>> +
>> + generate_label_tree_internal(dt, dt, an, allocph);
>> +}
>> +
>> +#define FIXUPS "__fixups__"
>> +#define LOCAL_FIXUPS "__local_fixups__"
>> +
>> +static void add_fixup_entry(struct node *dt, struct node *node,
>> + struct property *prop, struct marker *m)
>> +{
>> + struct node *fn; /* fixup node */
>> + char *entry;
>> +
>> + /* m->ref can only be a REF_PHANDLE, but check anyway */
>> + assert(m->type == REF_PHANDLE);
>> +
>> + /* fn is the node we're putting entries in */
>> + fn = get_subnode(dt, FIXUPS);
>> + assert(fn != NULL);
>> +
>> + /* there shouldn't be any ':' in the arguments */
>> + if (strchr(node->fullpath, ':') || strchr(prop->name, ':'))
>> + die("arguments should not contain ':'\n");
>> +
>> + xasprintf(&entry, "%s:%s:%u",
>> + node->fullpath, prop->name, m->offset);
>> + append_to_property(fn, m->ref, entry, strlen(entry) + 1);
>> +}
>> +
>> +static void add_local_fixup_entry(struct node *dt, struct node *node,
>> + struct property *prop, struct marker *m,
>> + struct node *refnode)
>> +{
>> + struct node *lfn, *wn, *nwn; /* local fixup node, walk node, new */
>> + uint32_t value_32;
>> + char *s, *e, *comp;
>> + int len;
>> +
>> + /* fn is the node we're putting entries in */
>> + lfn = get_subnode(dt, LOCAL_FIXUPS);
>> + assert(lfn != NULL);
>> +
>> + /* walk the path components creating nodes if they don't exist */
>> + comp = xmalloc(strlen(node->fullpath) + 1);
>> + /* start skipping the first / */
>> + s = node->fullpath + 1;
>> + wn = lfn;
>> + while (*s) {
>> + /* retrieve path component */
>> + e = strchr(s, '/');
>> + if (e == NULL)
>> + e = s + strlen(s);
>> + len = e - s;
>> + memcpy(comp, s, len);
>> + comp[len] = '\0';
>
> Parsing the fullpath into components seems an odd way of doing this.
> We have an actual handle on the node, and therefore all it's parents,
> which already have the individual path components split out.
>
Hmm, I’ll see if it can be done. I don’t remember what was the original
cause for using this form.
>> +
>> + /* if no node exists, create it */
>> + nwn = get_subnode(wn, comp);
>> + if (!nwn)
>> + nwn = build_and_name_child_node(wn, comp);
>> + wn = nwn;
>> +
>> + /* last path component */
>> + if (!*e)
>> + break;
>> +
>> + /* next path component */
>> + s = e + 1;
>> + }
>> + free(comp);
>> +
>> + value_32 = cpu_to_fdt32(m->offset);
>> + append_to_property(wn, prop->name, &value_32, sizeof(value_32));
>> +}
>> +
>> +static void generate_fixups_tree_internal(struct node *dt, struct node *node)
>> +{
>> + struct node *c;
>> + struct property *prop;
>> + struct marker *m;
>> + struct node *refnode;
>> +
>> + for_each_property(node, prop) {
>> + m = prop->val.markers;
>> + for_each_marker_of_type(m, REF_PHANDLE) {
>> + refnode = get_node_by_ref(dt, m->ref);
>> + if (!refnode)
>> + add_fixup_entry(dt, node, prop, m);
>> + else
>> + add_local_fixup_entry(dt, node, prop, m,
>> + refnode);
>> + }
>> + }
>> +
>> + for_each_child(node, c)
>> + generate_fixups_tree_internal(dt, c);
>> +}
>> +
>> +void generate_fixups_tree(struct node *dt)
>> +{
>> + struct node *an;
>> +
>> + for_each_child(dt, an)
>> + if (streq(FIXUPS, an->name))
>> + break;
>> +
>> + if (!an)
>> + build_and_name_child_node(dt, FIXUPS);
>> +
>> + for_each_child(dt, an)
>> + if (streq(LOCAL_FIXUPS, an->name))
>> + break;
>> +
>> + if (!an)
>> + build_and_name_child_node(dt, LOCAL_FIXUPS);
>> +
>> + generate_fixups_tree_internal(dt, dt);
>> +}
>> diff --git a/tests/mangle-layout.c b/tests/mangle-layout.c
>> index a76e51e..d29ebc6 100644
>> --- a/tests/mangle-layout.c
>> +++ b/tests/mangle-layout.c
>> @@ -42,7 +42,8 @@ static void expand_buf(struct bufstate *buf, int newsize)
>> buf->size = newsize;
>> }
>>
>> -static void new_header(struct bufstate *buf, int version, const void *fdt)
>> +static void new_header(struct bufstate *buf, fdt32_t magic, int version,
>> + const void *fdt)
>> {
>> int hdrsize;
>>
>> @@ -56,7 +57,7 @@ static void new_header(struct bufstate *buf, int version, const void *fdt)
>> expand_buf(buf, hdrsize);
>> memset(buf->buf, 0, hdrsize);
>>
>> - fdt_set_magic(buf->buf, FDT_MAGIC);
>> + fdt_set_magic(buf->buf, magic);
>> fdt_set_version(buf->buf, version);
>> fdt_set_last_comp_version(buf->buf, 16);
>> fdt_set_boot_cpuid_phys(buf->buf, fdt_boot_cpuid_phys(fdt));
>> @@ -145,7 +146,7 @@ int main(int argc, char *argv[])
>> if (fdt_version(fdt) < 17)
>> CONFIG("Input tree must be v17");
>>
>> - new_header(&buf, version, fdt);
>> + new_header(&buf, FDT_MAGIC, version, fdt);
>>
>> while (*blockorder) {
>> add_block(&buf, version, *blockorder, fdt);
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
Regards
— Pantelis
^ permalink raw reply
* Re: [PATCH v9 3/4] dtc: Plugin and fixup support
From: Pantelis Antoniou @ 2016-11-28 11:55 UTC (permalink / raw)
To: David Gibson
Cc: Jon Loeliger, Grant Likely, Frank Rowand, Rob Herring, Jan Luebbe,
Sascha Hauer, Phil Elwell, Simon Glass, Maxime Ripard,
Thomas Petazzoni, Boris Brezillon, Antoine Tenart, Stephen Boyd,
Devicetree Compiler, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161128023252.GH30927-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
Hi David,
> On Nov 28, 2016, at 04:32 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>
> On Fri, Nov 25, 2016 at 02:44:39PM +0200, Pantelis Antoniou wrote:
>> Hi David,
>>
>>> On Nov 25, 2016, at 13:26 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>>>
>>> On Fri, Nov 25, 2016 at 12:55:25PM +0200, Pantelis Antoniou wrote:
>>>> Hi David,
>>>>
>>>>> On Nov 25, 2016, at 06:11 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
>>>>>
>>>>> On Thu, Nov 24, 2016 at 02:31:32PM +0200, Pantelis Antoniou wrote:
>>>>>> This patch enable the generation of symbols & local fixup information
>>>>>> for trees compiled with the -@ (--symbols) option.
>>>>>>
>>>>>> Using this patch labels in the tree and their users emit information
>>>>>> in __symbols__ and __local_fixups__ nodes.
>>>>>>
>>>>>> The __fixups__ node make possible the dynamic resolution of phandle
>>>>>> references which are present in the plugin tree but lie in the
>>>>>> tree that are applying the overlay against.
>>>>>>
>>>>>> While there is a new magic number for dynamic device tree/overlays blobs
>>>>>> it is by default disabled. This is in order to give time for DT blob
>>>>>> methods to be updated.
>>>>>>
>>>>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>>>> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>>>>> Signed-off-by: Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>>>>> ---
>>>>>> Documentation/manual.txt | 25 +++++-
>>>>>> checks.c | 8 +-
>>>>>> dtc-lexer.l | 5 ++
>>>>>> dtc-parser.y | 49 +++++++++--
>>>>>> dtc.c | 39 +++++++-
>>>>>> dtc.h | 20 ++++-
>>>>>> fdtdump.c | 2 +-
>>>>>> flattree.c | 17 ++--
>>>>>> fstree.c | 2 +-
>>>>>> libfdt/fdt.c | 2 +-
>>>>>> libfdt/fdt.h | 3 +-
>>>>>> livetree.c | 225 ++++++++++++++++++++++++++++++++++++++++++++++-
>>>>>> tests/mangle-layout.c | 7 +-
>>>>>> treesource.c | 7 +-
>>>>>> 14 files changed, 380 insertions(+), 31 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/manual.txt b/Documentation/manual.txt
>>>>>> index 398de32..65fbf09 100644
>>>>>> --- a/Documentation/manual.txt
>>>>>> +++ b/Documentation/manual.txt
>>>>>> @@ -119,6 +119,24 @@ Options:
>>>>>> Make space for <number> reserve map entries
>>>>>> Relevant for dtb and asm output only.
>>>>>>
>>>>>> + -@
>>>>>> + Generates a __symbols__ node at the root node of the resulting blob
>>>>>> + for any node labels used, and for any local references using phandles
>>>>>> + it also generates a __local_fixups__ node that tracks them.
>>>>>> +
>>>>>> + When using the /plugin/ tag all unresolved label references to
>>>>>> + be tracked in the __fixups__ node, making dynamic resolution possible.
>>>>>> +
>>>>>> + -A
>>>>>> + Generate automatically aliases for all node labels. This is similar to
>>>>>> + the -@ option (the __symbols__ node contain identical information) but
>>>>>> + the semantics are slightly different since no phandles are automatically
>>>>>> + generated for labeled nodes.
>>>>>> +
>>>>>> + -M
>>>>>> + Generate blobs with the new FDT magic number. By default blobs with the
>>>>>> + standard FDT magic number are generated.
>>>>>
>>>>> First, this description is incomplete since -M *only* affects the
>>>>> magic number for /plugin/ input, not in other cases. Second, the
>>>>> default is the wrong way around. If we make old-style the default,
>>>>> then new-style will never be used, which defeats the purpose.
>>>>
>>>> Then we’ll break user-space that has this assumption (i.e. that the magic is the same).
>>>> I can certainly do it the other way around.
>>>
>>> Which userspace in particular?
>>>
>>
>> Kernel unflatteners in various OSes/bootloaders? All those would have to be updated since
>> they don’t grok the new magic number.
>
> Those will certainly need dtbs with the old magic number as input, but
> I don't see how that affects the dtc default. Using the option
> explicitly if you're targetting a bootloader that hasn't been updated
> seems reasonable.
>
OK.
>>>>>> +
>>>>>> -S <bytes>
>>>>>> Ensure the blob at least <bytes> long, adding additional
>>>>>> space if needed.
>>>>>> @@ -146,13 +164,18 @@ Additionally, dtc performs various sanity checks on the tree.
>>>>>> Here is a very rough overview of the layout of a DTS source file:
>>>>>>
>>>>>>
>>>>>> - sourcefile: list_of_memreserve devicetree
>>>>>> + sourcefile: versioninfo plugindecl list_of_memreserve devicetree
>>>>>>
>>>>>> memreserve: label 'memreserve' ADDR ADDR ';'
>>>>>> | label 'memreserve' ADDR '-' ADDR ';'
>>>>>>
>>>>>> devicetree: '/' nodedef
>>>>>>
>>>>>> + versioninfo: '/' 'dts-v1' '/' ';'
>>>>>> +
>>>>>> + plugindecl: '/' 'plugin' '/' ';'
>>>>>> + | /* empty */
>>>>>> +
>>>>>> nodedef: '{' list_of_property list_of_subnode '}' ';'
>>>>>>
>>>>>> property: label PROPNAME '=' propdata ';'
>>>>>> diff --git a/checks.c b/checks.c
>>>>>> index 609975a..bc03d42 100644
>>>>>> --- a/checks.c
>>>>>> +++ b/checks.c
>>>>>> @@ -486,8 +486,12 @@ static void fixup_phandle_references(struct check *c, struct boot_info *bi,
>>>>>>
>>>>>> refnode = get_node_by_ref(dt, m->ref);
>>>>>> if (! refnode) {
>>>>>> - FAIL(c, "Reference to non-existent node or label \"%s\"\n",
>>>>>> - m->ref);
>>>>>> + if (!(bi->versionflags & VF_PLUGIN))
>>>>>> + FAIL(c, "Reference to non-existent node or "
>>>>>> + "label \"%s\"\n", m->ref);
>>>>>> + else /* mark the entry as unresolved */
>>>>>> + *((cell_t *)(prop->val.val + m->offset)) =
>>>>>> + cpu_to_fdt32(0xffffffff);
>>>>>> continue;
>>>>>> }
>>>>>>
>>>>>> diff --git a/dtc-lexer.l b/dtc-lexer.l
>>>>>> index 790fbf6..40bbc87 100644
>>>>>> --- a/dtc-lexer.l
>>>>>> +++ b/dtc-lexer.l
>>>>>> @@ -121,6 +121,11 @@ static void lexical_error(const char *fmt, ...);
>>>>>> return DT_V1;
>>>>>> }
>>>>>>
>>>>>> +<*>"/plugin/" {
>>>>>> + DPRINT("Keyword: /plugin/\n");
>>>>>> + return DT_PLUGIN;
>>>>>> + }
>>>>>> +
>>>>>> <*>"/memreserve/" {
>>>>>> DPRINT("Keyword: /memreserve/\n");
>>>>>> BEGIN_DEFAULT();
>>>>>> diff --git a/dtc-parser.y b/dtc-parser.y
>>>>>> index 14aaf2e..4afc592 100644
>>>>>> --- a/dtc-parser.y
>>>>>> +++ b/dtc-parser.y
>>>>>> @@ -19,6 +19,7 @@
>>>>>> */
>>>>>> %{
>>>>>> #include <stdio.h>
>>>>>> +#include <inttypes.h>
>>>>>>
>>>>>> #include "dtc.h"
>>>>>> #include "srcpos.h"
>>>>>> @@ -33,6 +34,9 @@ extern void yyerror(char const *s);
>>>>>>
>>>>>> extern struct boot_info *the_boot_info;
>>>>>> extern bool treesource_error;
>>>>>> +
>>>>>> +/* temporary while the tree is not built */
>>>>>> +static unsigned int the_versionflags;
>>>>>
>>>>> Hrm. Using a global during parsing is pretty dangerous - it makes
>>>>> assumptions about the order in which bison will execute semantic
>>>>> actions that may not always be correct.
>>>>>
>>>>> It'll probably work in practice, so I *might* be convinced it's
>>>>> adequate for a first cut. I'm a bit reluctant though, since I suspect
>>>>> once merged it will become entrenched.
>>>>>
>>>>
>>>> We use bison, globals are the way of life. It’s not going to be used
>>>> anywhere else, it’s static in the parser file.
>>>
>>> Using globals to communicate the final result is inevitable (well, not
>>> without using the whole different re-entrant interface stuff). That
>>> just assumes that the start symbol's semantic action is executed
>>> before the parser competes, which is guaranteed.
>>>
>>> This is a different matter - using a global to communicate between
>>> different parts of the parser. More specifically different parts of
>>> the parser that are in different arms of the parse tree. That makes
>>> assumptions about the relative order of semantic actions which are
>>> *not* guaranteed. In theory the parser could generate the entire
>>> parse tree and semantic action dependency graph, then execute them in
>>> an arbitrary order (well, it would have to be a topologically sorted
>>> order, but that won't help).
>>>
>>
>> I’ve given it a little bit more thought and it’s easily fixed by using
>> inherited attributes which is safe to do and avoid the global all together.
>
> Hmm.. we'll see.
>
>>>> We could allocate the boot_info earlier (when the v1tag is detected) but
>>>> that would be quite a big change for something as trivial.
>>>
>>> That wouldn't help. You still wouldn't have a guarantee on the order
>>> between setting the version flags and using the version flags.
>>>
>>>>> The correct way to handle this, IMO, is not to ever attempt to apply
>>>>> overlays during the parse. Basically, we'd change the overall
>>>>> structure so that the output from the parser is not a single tree, but
>>>>> a list of overlays / fragments. Then, once the parse is complete, so
>>>>> versioninfo (which could now become a member of bootinfo) is well
>>>>> defined, we either apply the fragments in place (base tree) or encode
>>>>> them into the overlay structure (plugin mode).
>>>>>
>>>>> See https://github.com/dgibson/dtc/tree/overlay for some incomplete
>>>>> work I did in this direction.
>>>>>
>>>>
>>>> This tree is pretty stale; last commit was back in march.
>>>
>>> Yes, it was a while since I worked on it. It rebased clean, though.
>>>
>>>> I thing there’s a wrong assumption here. The purpose of this patch is not
>>>> to apply overlays during compile time, is to generate a blob that can be
>>>> applied at runtime by another piece of software.
>>>
>>> No, I realise what you're doing. But the input is in the form of a
>>> batch of overlays, regardless. You then have two modes of operation:
>>> for base trees you resolve those overlays during the compile, for
>>> plugins you assemble those overlays into a blob which can be applied
>>> later.
>>>
>>> Because it wasn't designed with runtime overlays in mind, the current
>>> code handles the resolution of those overlays during the parse. Your
>>> patch extends that by rather than resolving them, just putting them
>>> together with metadata into the dtbo.
>>>
>>> I'm saying that resolution or assembly should be moved out of the
>>> parser. Instead, the parser output would be an (ordered) list of
>>> overlay fragments. In the main program the two modes of operation
>>> become explicit: for base trees we resolve the overlays into a single
>>> tree, for plugins we collate the pieces into the dtbo format.
>>
>> The case for building an overlay is only for the syntactic sugar version.
>
> I don't understand what you're saying here.
>
>> This is not the common use case at all. I could easily remove it and then
>> there would be no overlays built at all in the parser.
>
> Remove what exactly? You mean the case with &ref { } when you're not
> building a dtbo? I'm not sure that is so uncommon - dts include files
> are basically useless without it.
>
Those cases are not meant to generate an overlay. We are not targeting
this right now.
>> In fact the extra fixup nodes are generated now after the parse stage,
>> after the check stage and before the sort stage.
>
> Yes.. I'm not talking about the fixup nodes, I'm talking about the
> assembly of the tree fragments.
>
>> Perhaps it should be separated out so that we don’t get sidetracked?
>
> What exactly should be separated out from what?
>
Well, a new patch is going to be shortly posted and will make this clearer.
>>>>> In addition to not making unsafe assumptions about parser operation, I
>>>>> think this will also allow for better error reporting. It also moves
>>>>> more code into plain-old-C instead of potentially hard to follow bison
>>>>> code fragments.
>>>>>
>>>>
>>>> We don’t try to apply overlays during parse, and especially in the parse code.
>>>
>>> The existing code does this, and you don't change it. Furthermore you
>>> absolutely do do the assembly of the fragments within the parser -
>>> that's exactly what add_orphan_node() called directly from semantic
>>> actions does. To verify this, all you need to do is look at the
>>> parser output: the boot_info structure has just a single tree, not a
>>> list of overlays.
>>>
>>
>> Only for the un-common case.
>>
>>>> The global is used only for the syntactic sugar method of turning a &ref { };
>>>> node into an overlay.
>>>
>>> I'm saying that treating that as mere syntactic sugar is a fundamental
>>> error in design. We could get away with it when the &ref {} stuff was
>>> always resolved immediately. Now that that resolution can be delayed
>>> until later, it gets worse. We should move that resolution outside of
>>> the parser.
>>>
>>
>> The &ref { } stuff is sidetracking us. This is not the core issue.
>
> You haven't convinced me of that.
>
>> In fact out in the community there are not a lot of cases where it
>> is used.
>
> I thought it was the standard way to construct a dtbo.
>
No, not by a long shot. All bb.org, rpi & chip overlays use the vanilla
method.
> But in any case, regardless of how common it is, it is currently
> introducing an order dependency between different parts of the parse
> tree that hasn't been adequately handled (in v9, I'll reasses when I
> review the v10 patches).
>
>>>>>> diff --git a/treesource.c b/treesource.c
>>>>>> index a55d1d1..75e920d 100644
>>>>>> --- a/treesource.c
>>>>>> +++ b/treesource.c
>>>>>> @@ -267,7 +267,12 @@ void dt_to_source(FILE *f, struct boot_info *bi)
>>>>>> {
>>>>>> struct reserve_info *re;
>>>>>>
>>>>>> - fprintf(f, "/dts-v1/;\n\n");
>>>>>> + fprintf(f, "/dts-v1/");
>>>>>> +
>>>>>> + if (bi->versionflags & VF_PLUGIN)
>>>>>> + fprintf(f, " /plugin/");
>>>>>> +
>>>>>> + fprintf(f, ";\n\n");
>>>>>
>>>>> I'm not sure this really makes sense. The /plugin/ tag triggers the
>>>>> fixup construction and encoding of overlay fragments. But in an
>>>>> incoming dtb, that processing has already been done once, doing it
>>>>> again would not make sense. So I think the output should not have the
>>>>> /plugin/ tag, even if the input did.
>>>>>
>>>>> Unless, of course, you parsed the input into an explicit list of
>>>>> overlays, then output it here again as a list of overlays, not the
>>>>> encoded fragments. i.e. if this was the original tree:
>>>>>
>>>>> /dts-v1/ /plugin/;
>>>>>
>>>>> &somwhere {
>>>>> name = "value";
>>>>> };
>>>>>
>>>>> then legitimately the output of -I dts -O dts could be either:
>>>>>
>>>>> /dts-v1/ /plugin/;
>>>>>
>>>>> &somwhere {
>>>>> name = "value";
>>>>> };
>>>>>
>>>>> OR
>>>>>
>>>>> /dts-v1/;
>>>>>
>>>>> / {
>>>>> fragment@0 {
>>>>> target = <0xffffffff>;
>>>>> __overlay__{
>>>>> name = "value";
>>>>> };
>>>>> };
>>>>> __fixups__ {
>>>>> somewhere = "/fragment@0:target:0";
>>>>> };
>>>>> };
>>>>>
>>>>> But it doesn't make sense to combine the two: the second structure
>>>>> with the "/plugin/" tag.
>>>>>
>>>>
>>>>> Another advantage of moving the overlay application out of the parser
>>>>> is you can sanely produce either output, both of which could be useful
>>>>> in the right circumstances. You can potentially even produce the
>>>>> first output (or something close) from dtb input, with correct parsing
>>>>> of the overlay structure on dtb input.
>>>>>
>>>>
>>>> Yes, this makes sense. For now I’ll remove the plugin tag, but if the blob
>>>> was compiled with -@ you could conceivably reverse back to a form that contains
>>>> labels and phandle references correctly.
>>>>
>>>> But this is quite complicated to undertake in this patch series.
>>>>
>>>> To re-iterate though there is no overlay application here :)
>>>
>>> Well, I think we've both been a bit sloppy with terminology - does
>>> "overlay" refer to a dtbo file, or to one of the &ref { ... }
>>> fragments in the source, or to both.
>>>
>>> But whatever the right term is for the &ref { .. } fragments in the
>>> source they absolutely *are* applied during compile for the base tree
>>> case. And while they're not resolved fully, they are encoded into
>>> part of a larger tree structure for the plugin case.
>>>
>>> The confusion will be reduced if we make these
>>> overlays/fragments/whatever first class objects in the "live tree"
>>> phase of the compile, and move the resolution and/or assembly of them
>>> a stage that's separate from the parse. In addition, it opens the way
>>> for decompiling a dtbo more naturally, though as you say that's a
>>> moderate amount of extra work.
>>
>> How about we get the non &ref { } case sorted out and we can talk about
>> the syntactic sugar version done?
>
> Uh.. sure. I'm not really clear on what you mean by that, but I guess
> I'll look and see.
>
>>
>> v10 has been sent out.
>>
>>
>> Regards
>>
>> — Pantelis
>>
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
Regards
— Pantelis
^ permalink raw reply
* Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ziji Hu @ 2016-11-28 11:38 UTC (permalink / raw)
To: Ulf Hansson
Cc: Gregory CLEMENT, Adrian Hunter, linux-mmc@vger.kernel.org,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree@vger.kernel.org, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Jimmy Xu, Jisheng Zhang,
Nadav Haklai, Ryan Gao, Doug Jones, Victor Gu, Wei(SOCP) Liu,
Wilson Ding
In-Reply-To: <CAPDyKFo3ezYOywtSZ8GGQ1XK9KPsxCgQNbaiz45EVgbgtnUxjg@mail.gmail.com>
Hi Ulf,
On 2016/11/28 19:13, Ulf Hansson wrote:
>>
>> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
>> send commands for testing current sampling point set in our host PHY.
>>
>> According to my test result, it shows that mmc_send_tuning() can only support
>> tuning command (CMD21/CMD19).
>> As a result, we cannot use mmc_send_tuning() when card is in the speed modes
>> which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
>> SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
>> speed modes.
>>
>> Could you please provide suggestions for the speed mode in which tuning is
>> not available?
>>
>
> Normally the mmc host driver shouldn't have to care about what the
> card supports, as that is the responsibility of the mmc core to
> manage.
>
> The host should only need to implement the ->execute_tuning() ops,
> which gets called when the card supports tuning (CMD19/21). Does it
> make sense?
>
I think it is irrelevant to tuning procedure.
Our host requires to adjust PHY setting after each time ios setting
(SDCLK/bus width/speed mode) is changed.
The simplified sequence is:
mmc change ios --> mmc_set_ios() --> ->set_ios() --> after sdhci_set_ios(),
adjust PHY setting.
During PHY setting adjustment, out host driver has to send commands to
test current sampling point. Tuning is another independent step.
Thus our host needs a valid command in PHY setting adjustment. Tuning command
can be borrowed to complete this task in SD SDR50. But for other speed mode,
we have to find out a valid command.
Any suggestion please?
Thank you.
Best regards,
Hu Ziji
> Kind regards
> Uffe
>
^ permalink raw reply
* [RESEND PATCH V4 4/8] mfd: da9061: MFD core support
From: Steve Twiss @ 2016-11-28 11:37 UTC (permalink / raw)
To: LINUX-KERNEL, Lee Jones
Cc: DEVICETREE, Dmitry Torokhov, Eduardo Valentin, Guenter Roeck,
LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG, Liam Girdwood, Mark Brown,
Mark Rutland, Rob Herring, Support Opensource, Wim Van Sebroeck,
Zhang Rui
In-Reply-To: <cover.1480333041.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
MFD support for DA9061 is provided as part of the DA9062 device driver.
The registers header file adds two new chip variant IDs defined in DA9061
and DA9062 hardware. The core header file adds new software enumerations
for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
for distinguishing between DA9061/62 devices in software.
The core source code adds a new .compatible of_device_id entry. This is
extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
.data entry now holds a reference to the enumerated device type.
A new regmap_irq_chip model is added for DA9061 and this supports the new
list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
new sub system components for DA9061. Support is added for a new DA9061
regmap_config which lists the correct readable, writable and volatile
ranges for this chip.
The probe function uses the device tree compatible string to switch on the
da9062_compatible_types and configure the correct mfd cells, irq chip and
regmap config.
Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
---
This patch applies against linux-next and v4.8
v3 -> v4
- Patch renamed from [PATCH V3 5/9] to [PATCH V4 4/8]
- Removed DEFINE_RES_NAMED() macros for DA9061 resources and replaced
them with DEFINE_RES_IRQ_NAMED().
- Removed whitespace
- Reverted change for badly defined mfd_cell da9062_devs of_compatible
string from "dlg,da9062-watchdog" back to "dlg,da9062-wdt"
v2 -> v3
- NO CODE CHANGE
- Patch renamed from [PATCH V2 05/10] to [PATCH V3 5/9]
v1 -> v2
- Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- Fixed typo in the commit message "readble" to "readable"
- Removed the explicit cross-check to decide if there is a conflict
between the device tree compatible string and the hardware definition.
This patch assumes the device tree is correctly written and therefore
removes the need for a hardware/DT sanity check.
- Removed extra semicolon in drivers/mfd/da9062-core.c:877
- Re-write compatible entries into numerical order
Lee,
Changes as described in the version history above.
As previously:
This patch adds support for the DA9061 PMIC. This is done as part of the
existing DA9062 device driver by extending the of_device_id match table.
This in turn allows new MFD cells, irq chip and regmap definitions to
support DA9061.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/mfd/Kconfig | 5 +-
drivers/mfd/da9062-core.c | 424 +++++++++++++++++++++++++++++++++--
include/linux/mfd/da9062/core.h | 27 ++-
include/linux/mfd/da9062/registers.h | 2 +
4 files changed, 439 insertions(+), 19 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2d1fb64..533798a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -236,13 +236,14 @@ config MFD_DA9055
called "da9055"
config MFD_DA9062
- tristate "Dialog Semiconductor DA9062 PMIC Support"
+ tristate "Dialog Semiconductor DA9062/61 PMIC Support"
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
depends on I2C
help
- Say yes here for support for the Dialog Semiconductor DA9062 PMIC.
+ Say yes here for support for the Dialog Semiconductor DA9061 and
+ DA9062 PMICs.
This includes the I2C driver and core APIs.
Additional drivers must be enabled in order to use the functionality
of the device.
diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
index 8f873866..4b5f70f 100644
--- a/drivers/mfd/da9062-core.c
+++ b/drivers/mfd/da9062-core.c
@@ -1,5 +1,5 @@
/*
- * Core, IRQ and I2C device driver for DA9062 PMIC
+ * Core, IRQ and I2C device driver for DA9061 and DA9062 PMICs
* Copyright (C) 2015 Dialog Semiconductor Ltd.
*
* This program is free software; you can redistribute it and/or
@@ -30,6 +30,70 @@
#define DA9062_REG_EVENT_B_OFFSET 1
#define DA9062_REG_EVENT_C_OFFSET 2
+static struct regmap_irq da9061_irqs[] = {
+ /* EVENT A */
+ [DA9061_IRQ_ONKEY] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_NONKEY_MASK,
+ },
+ [DA9061_IRQ_WDG_WARN] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_WDG_WARN_MASK,
+ },
+ [DA9061_IRQ_SEQ_RDY] = {
+ .reg_offset = DA9062_REG_EVENT_A_OFFSET,
+ .mask = DA9062AA_M_SEQ_RDY_MASK,
+ },
+ /* EVENT B */
+ [DA9061_IRQ_TEMP] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_TEMP_MASK,
+ },
+ [DA9061_IRQ_LDO_LIM] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_LDO_LIM_MASK,
+ },
+ [DA9061_IRQ_DVC_RDY] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_DVC_RDY_MASK,
+ },
+ [DA9061_IRQ_VDD_WARN] = {
+ .reg_offset = DA9062_REG_EVENT_B_OFFSET,
+ .mask = DA9062AA_M_VDD_WARN_MASK,
+ },
+ /* EVENT C */
+ [DA9061_IRQ_GPI0] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI0_MASK,
+ },
+ [DA9061_IRQ_GPI1] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI1_MASK,
+ },
+ [DA9061_IRQ_GPI2] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI2_MASK,
+ },
+ [DA9061_IRQ_GPI3] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI3_MASK,
+ },
+ [DA9061_IRQ_GPI4] = {
+ .reg_offset = DA9062_REG_EVENT_C_OFFSET,
+ .mask = DA9062AA_M_GPI4_MASK,
+ },
+};
+
+static struct regmap_irq_chip da9061_irq_chip = {
+ .name = "da9061-irq",
+ .irqs = da9061_irqs,
+ .num_irqs = DA9061_NUM_IRQ,
+ .num_regs = 3,
+ .status_base = DA9062AA_EVENT_A,
+ .mask_base = DA9062AA_IRQ_MASK_A,
+ .ack_base = DA9062AA_EVENT_A,
+};
+
static struct regmap_irq da9062_irqs[] = {
/* EVENT A */
[DA9062_IRQ_ONKEY] = {
@@ -102,6 +166,57 @@ static struct regmap_irq_chip da9062_irq_chip = {
.ack_base = DA9062AA_EVENT_A,
};
+static struct resource da9061_core_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_VDD_WARN, "VDD_WARN"),
+};
+
+static struct resource da9061_regulators_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_LDO_LIM, "LDO_LIM"),
+};
+
+static struct resource da9061_thermal_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_TEMP, "THERMAL"),
+};
+
+static struct resource da9061_wdt_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_WDG_WARN, "WD_WARN"),
+};
+
+static struct resource da9061_onkey_resources[] = {
+ DEFINE_RES_IRQ_NAMED(DA9061_IRQ_ONKEY, "ONKEY"),
+};
+
+static const struct mfd_cell da9061_devs[] = {
+ {
+ .name = "da9061-core",
+ .num_resources = ARRAY_SIZE(da9061_core_resources),
+ .resources = da9061_core_resources,
+ },
+ {
+ .name = "da9062-regulators",
+ .num_resources = ARRAY_SIZE(da9061_regulators_resources),
+ .resources = da9061_regulators_resources,
+ },
+ {
+ .name = "da9061-watchdog",
+ .num_resources = ARRAY_SIZE(da9061_wdt_resources),
+ .resources = da9061_wdt_resources,
+ .of_compatible = "dlg,da9061-watchdog",
+ },
+ {
+ .name = "da9061-thermal",
+ .num_resources = ARRAY_SIZE(da9061_thermal_resources),
+ .resources = da9061_thermal_resources,
+ .of_compatible = "dlg,da9061-thermal",
+ },
+ {
+ .name = "da9061-onkey",
+ .num_resources = ARRAY_SIZE(da9061_onkey_resources),
+ .resources = da9061_onkey_resources,
+ .of_compatible = "dlg,da9061-onkey",
+ },
+};
+
static struct resource da9062_core_resources[] = {
DEFINE_RES_NAMED(DA9062_IRQ_VDD_WARN, 1, "VDD_WARN", IORESOURCE_IRQ),
};
@@ -200,7 +315,8 @@ static int da9062_clear_fault_log(struct da9062 *chip)
static int da9062_get_device_type(struct da9062 *chip)
{
- int device_id, variant_id, variant_mrc;
+ int device_id, variant_id, variant_mrc, variant_vrc;
+ char *type;
int ret;
ret = regmap_read(chip->regmap, DA9062AA_DEVICE_ID, &device_id);
@@ -219,9 +335,23 @@ static int da9062_get_device_type(struct da9062 *chip)
return -EIO;
}
+ variant_vrc = (variant_id & DA9062AA_VRC_MASK) >> DA9062AA_VRC_SHIFT;
+
+ switch (variant_vrc) {
+ case DA9062_PMIC_VARIANT_VRC_DA9061:
+ type = "DA9061";
+ break;
+ case DA9062_PMIC_VARIANT_VRC_DA9062:
+ type = "DA9062";
+ break;
+ default:
+ type = "Unknown";
+ break;
+ }
+
dev_info(chip->dev,
- "Device detected (device-ID: 0x%02X, var-ID: 0x%02X)\n",
- device_id, variant_id);
+ "Device detected (device-ID: 0x%02X, var-ID: 0x%02X, %s)\n",
+ device_id, variant_id, type);
variant_mrc = (variant_id & DA9062AA_MRC_MASK) >> DA9062AA_MRC_SHIFT;
@@ -234,6 +364,234 @@ static int da9062_get_device_type(struct da9062 *chip)
return ret;
}
+static const struct regmap_range da9061_aa_readable_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_STATUS_B,
+ }, {
+ .range_min = DA9062AA_STATUS_D,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_IRQ_MASK_A,
+ .range_max = DA9062AA_IRQ_MASK_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_GPIO_4,
+ }, {
+ .range_min = DA9062AA_GPIO_WKUP_MODE,
+ .range_max = DA9062AA_GPIO_OUT3_4,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_ID_4_3,
+ }, {
+ .range_min = DA9062AA_ID_12_11,
+ .range_max = DA9062AA_ID_16_15,
+ }, {
+ .range_min = DA9062AA_ID_22_21,
+ .range_max = DA9062AA_ID_32_31,
+ }, {
+ .range_min = DA9062AA_SEQ_A,
+ .range_max = DA9062AA_WAIT,
+ }, {
+ .range_min = DA9062AA_RESET,
+ .range_max = DA9062AA_BUCK_ILIM_C,
+ }, {
+ .range_min = DA9062AA_BUCK1_CFG,
+ .range_max = DA9062AA_BUCK3_CFG,
+ }, {
+ .range_min = DA9062AA_VBUCK1_A,
+ .range_max = DA9062AA_VBUCK4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK3_A,
+ .range_max = DA9062AA_VBUCK3_A,
+ }, {
+ .range_min = DA9062AA_VLDO1_A,
+ .range_max = DA9062AA_VLDO4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK1_B,
+ .range_max = DA9062AA_VBUCK4_B,
+ }, {
+ .range_min = DA9062AA_VBUCK3_B,
+ .range_max = DA9062AA_VBUCK3_B,
+ }, {
+ .range_min = DA9062AA_VLDO1_B,
+ .range_max = DA9062AA_VLDO4_B,
+ }, {
+ .range_min = DA9062AA_BBAT_CONT,
+ .range_max = DA9062AA_BBAT_CONT,
+ }, {
+ .range_min = DA9062AA_INTERFACE,
+ .range_max = DA9062AA_CONFIG_E,
+ }, {
+ .range_min = DA9062AA_CONFIG_G,
+ .range_max = DA9062AA_CONFIG_K,
+ }, {
+ .range_min = DA9062AA_CONFIG_M,
+ .range_max = DA9062AA_CONFIG_M,
+ }, {
+ .range_min = DA9062AA_GP_ID_0,
+ .range_max = DA9062AA_GP_ID_19,
+ }, {
+ .range_min = DA9062AA_DEVICE_ID,
+ .range_max = DA9062AA_CONFIG_ID,
+ },
+};
+
+static const struct regmap_range da9061_aa_writeable_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_PAGE_CON,
+ }, {
+ .range_min = DA9062AA_FAULT_LOG,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_IRQ_MASK_A,
+ .range_max = DA9062AA_IRQ_MASK_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_GPIO_4,
+ }, {
+ .range_min = DA9062AA_GPIO_WKUP_MODE,
+ .range_max = DA9062AA_GPIO_OUT3_4,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_ID_4_3,
+ }, {
+ .range_min = DA9062AA_ID_12_11,
+ .range_max = DA9062AA_ID_16_15,
+ }, {
+ .range_min = DA9062AA_ID_22_21,
+ .range_max = DA9062AA_ID_32_31,
+ }, {
+ .range_min = DA9062AA_SEQ_A,
+ .range_max = DA9062AA_WAIT,
+ }, {
+ .range_min = DA9062AA_RESET,
+ .range_max = DA9062AA_BUCK_ILIM_C,
+ }, {
+ .range_min = DA9062AA_BUCK1_CFG,
+ .range_max = DA9062AA_BUCK3_CFG,
+ }, {
+ .range_min = DA9062AA_VBUCK1_A,
+ .range_max = DA9062AA_VBUCK4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK3_A,
+ .range_max = DA9062AA_VBUCK3_A,
+ }, {
+ .range_min = DA9062AA_VLDO1_A,
+ .range_max = DA9062AA_VLDO4_A,
+ }, {
+ .range_min = DA9062AA_VBUCK1_B,
+ .range_max = DA9062AA_VBUCK4_B,
+ }, {
+ .range_min = DA9062AA_VBUCK3_B,
+ .range_max = DA9062AA_VBUCK3_B,
+ }, {
+ .range_min = DA9062AA_VLDO1_B,
+ .range_max = DA9062AA_VLDO4_B,
+ }, {
+ .range_min = DA9062AA_BBAT_CONT,
+ .range_max = DA9062AA_BBAT_CONT,
+ }, {
+ .range_min = DA9062AA_GP_ID_0,
+ .range_max = DA9062AA_GP_ID_19,
+ },
+};
+
+static const struct regmap_range da9061_aa_volatile_ranges[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_STATUS_B,
+ }, {
+ .range_min = DA9062AA_STATUS_D,
+ .range_max = DA9062AA_EVENT_C,
+ }, {
+ .range_min = DA9062AA_CONTROL_A,
+ .range_max = DA9062AA_CONTROL_B,
+ }, {
+ .range_min = DA9062AA_CONTROL_E,
+ .range_max = DA9062AA_CONTROL_F,
+ }, {
+ .range_min = DA9062AA_BUCK1_CONT,
+ .range_max = DA9062AA_BUCK4_CONT,
+ }, {
+ .range_min = DA9062AA_BUCK3_CONT,
+ .range_max = DA9062AA_BUCK3_CONT,
+ }, {
+ .range_min = DA9062AA_LDO1_CONT,
+ .range_max = DA9062AA_LDO4_CONT,
+ }, {
+ .range_min = DA9062AA_DVC_1,
+ .range_max = DA9062AA_DVC_1,
+ }, {
+ .range_min = DA9062AA_SEQ,
+ .range_max = DA9062AA_SEQ,
+ },
+};
+
+static const struct regmap_access_table da9061_aa_readable_table = {
+ .yes_ranges = da9061_aa_readable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_readable_ranges),
+};
+
+static const struct regmap_access_table da9061_aa_writeable_table = {
+ .yes_ranges = da9061_aa_writeable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_writeable_ranges),
+};
+
+static const struct regmap_access_table da9061_aa_volatile_table = {
+ .yes_ranges = da9061_aa_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(da9061_aa_volatile_ranges),
+};
+
+static const struct regmap_range_cfg da9061_range_cfg[] = {
+ {
+ .range_min = DA9062AA_PAGE_CON,
+ .range_max = DA9062AA_CONFIG_ID,
+ .selector_reg = DA9062AA_PAGE_CON,
+ .selector_mask = 1 << DA9062_I2C_PAGE_SEL_SHIFT,
+ .selector_shift = DA9062_I2C_PAGE_SEL_SHIFT,
+ .window_start = 0,
+ .window_len = 256,
+ }
+};
+
+static struct regmap_config da9061_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .ranges = da9061_range_cfg,
+ .num_ranges = ARRAY_SIZE(da9061_range_cfg),
+ .max_register = DA9062AA_CONFIG_ID,
+ .cache_type = REGCACHE_RBTREE,
+ .rd_table = &da9061_aa_readable_table,
+ .wr_table = &da9061_aa_writeable_table,
+ .volatile_table = &da9061_aa_volatile_table,
+};
+
static const struct regmap_range da9062_aa_readable_ranges[] = {
{
.range_min = DA9062AA_PAGE_CON,
@@ -456,17 +814,38 @@ static struct regmap_config da9062_regmap_config = {
.volatile_table = &da9062_aa_volatile_table,
};
+static const struct of_device_id da9062_dt_ids[] = {
+ { .compatible = "dlg,da9061", .data = (void *)COMPAT_TYPE_DA9061, },
+ { .compatible = "dlg,da9062", .data = (void *)COMPAT_TYPE_DA9062, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, da9062_dt_ids);
+
static int da9062_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct da9062 *chip;
+ const struct of_device_id *match;
unsigned int irq_base;
+ const struct mfd_cell *cell;
+ const struct regmap_irq_chip *irq_chip;
+ const struct regmap_config *config;
+ int cell_num;
int ret;
chip = devm_kzalloc(&i2c->dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
return -ENOMEM;
+ if (i2c->dev.of_node) {
+ match = of_match_node(da9062_dt_ids, i2c->dev.of_node);
+ if (!match)
+ return -EINVAL;
+
+ chip->chip_type = (int)match->data;
+ } else
+ chip->chip_type = id->driver_data;
+
i2c_set_clientdata(i2c, chip);
chip->dev = &i2c->dev;
@@ -475,7 +854,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
return -EINVAL;
}
- chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
+ switch (chip->chip_type) {
+ case(COMPAT_TYPE_DA9061):
+ cell = da9061_devs;
+ cell_num = ARRAY_SIZE(da9061_devs);
+ irq_chip = &da9061_irq_chip;
+ config = &da9061_regmap_config;
+ break;
+ case(COMPAT_TYPE_DA9062):
+ cell = da9062_devs;
+ cell_num = ARRAY_SIZE(da9062_devs);
+ irq_chip = &da9062_irq_chip;
+ config = &da9062_regmap_config;
+ break;
+ default:
+ dev_err(chip->dev, "Unrecognised chip type\n");
+ return -ENODEV;
+ }
+
+ chip->regmap = devm_regmap_init_i2c(i2c, config);
if (IS_ERR(chip->regmap)) {
ret = PTR_ERR(chip->regmap);
dev_err(chip->dev, "Failed to allocate register map: %d\n",
@@ -493,7 +890,7 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
ret = regmap_add_irq_chip(chip->regmap, i2c->irq,
IRQF_TRIGGER_LOW | IRQF_ONESHOT | IRQF_SHARED,
- -1, &da9062_irq_chip,
+ -1, irq_chip,
&chip->regmap_irq);
if (ret) {
dev_err(chip->dev, "Failed to request IRQ %d: %d\n",
@@ -503,8 +900,8 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
irq_base = regmap_irq_chip_get_base(chip->regmap_irq);
- ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, da9062_devs,
- ARRAY_SIZE(da9062_devs), NULL, irq_base,
+ ret = mfd_add_devices(chip->dev, PLATFORM_DEVID_NONE, cell,
+ cell_num, NULL, irq_base,
NULL);
if (ret) {
dev_err(chip->dev, "Cannot register child devices\n");
@@ -526,17 +923,12 @@ static int da9062_i2c_remove(struct i2c_client *i2c)
}
static const struct i2c_device_id da9062_i2c_id[] = {
- { "da9062", 0 },
+ { "da9061", COMPAT_TYPE_DA9061 },
+ { "da9062", COMPAT_TYPE_DA9062 },
{ },
};
MODULE_DEVICE_TABLE(i2c, da9062_i2c_id);
-static const struct of_device_id da9062_dt_ids[] = {
- { .compatible = "dlg,da9062", },
- { }
-};
-MODULE_DEVICE_TABLE(of, da9062_dt_ids);
-
static struct i2c_driver da9062_i2c_driver = {
.driver = {
.name = "da9062",
@@ -549,6 +941,6 @@ static struct i2c_driver da9062_i2c_driver = {
module_i2c_driver(da9062_i2c_driver);
-MODULE_DESCRIPTION("Core device driver for Dialog DA9062");
+MODULE_DESCRIPTION("Core device driver for Dialog DA9061 and DA9062");
MODULE_AUTHOR("Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>");
MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/da9062/core.h b/include/linux/mfd/da9062/core.h
index 376ba84..199c524 100644
--- a/include/linux/mfd/da9062/core.h
+++ b/include/linux/mfd/da9062/core.h
@@ -18,7 +18,31 @@
#include <linux/interrupt.h>
#include <linux/mfd/da9062/registers.h>
-/* Interrupts */
+enum da9062_compatible_types {
+ COMPAT_TYPE_DA9061 = 1,
+ COMPAT_TYPE_DA9062,
+};
+
+enum da9061_irqs {
+ /* IRQ A */
+ DA9061_IRQ_ONKEY,
+ DA9061_IRQ_WDG_WARN,
+ DA9061_IRQ_SEQ_RDY,
+ /* IRQ B*/
+ DA9061_IRQ_TEMP,
+ DA9061_IRQ_LDO_LIM,
+ DA9061_IRQ_DVC_RDY,
+ DA9061_IRQ_VDD_WARN,
+ /* IRQ C */
+ DA9061_IRQ_GPI0,
+ DA9061_IRQ_GPI1,
+ DA9061_IRQ_GPI2,
+ DA9061_IRQ_GPI3,
+ DA9061_IRQ_GPI4,
+
+ DA9061_NUM_IRQ,
+};
+
enum da9062_irqs {
/* IRQ A */
DA9062_IRQ_ONKEY,
@@ -45,6 +69,7 @@ struct da9062 {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irq;
+ enum da9062_compatible_types chip_type;
};
#endif /* __MFD_DA9062_CORE_H__ */
diff --git a/include/linux/mfd/da9062/registers.h b/include/linux/mfd/da9062/registers.h
index 97790d1..4457fdc 100644
--- a/include/linux/mfd/da9062/registers.h
+++ b/include/linux/mfd/da9062/registers.h
@@ -18,6 +18,8 @@
#define DA9062_PMIC_DEVICE_ID 0x62
#define DA9062_PMIC_VARIANT_MRC_AA 0x01
+#define DA9062_PMIC_VARIANT_VRC_DA9061 0x01
+#define DA9062_PMIC_VARIANT_VRC_DA9062 0x02
#define DA9062_I2C_PAGE_SEL_SHIFT 1
--
end-of-patch for RESEND PATCH V4
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" 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] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Maxime Ripard @ 2016-11-28 11:19 UTC (permalink / raw)
To: Emmanuel Vadot
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161124210834.a7da24a53b09364e8ab391d6-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]
On Thu, Nov 24, 2016 at 09:08:34PM +0100, Emmanuel Vadot wrote:
> On Wed, 23 Nov 2016 18:16:10 +0100
> Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org> wrote:
>
> > On Wed, 23 Nov 2016 09:03:50 +0100
> > Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> >
> > > On Mon, Nov 21, 2016 at 05:49:11PM +0100, Emmanuel Vadot wrote:
> > > > UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
> > > > and uart pins along power in one connector and are found on most,
> > > > if not all, Olimex boards.
> > > > The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
> > > > those two connectors.
> > > >
> > > > Signed-off-by: Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
> > >
> > > Fixed the indentation of the spi pinctrl cells, and applied.
> > >
> > > Please note that I'm note planning to send any new pull request, so
> > > this will likely end up in 4.11.
> > >
> > > Thanks!
> > > Maxime
> > >
> > > --
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux and Kernel engineering
> > > http://free-electrons.com
> >
> > Sorry about the indentation, I'll be more carefull next time.
> >
> > Thank you.
> >
> > --
> > Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org> <manu-h+KGxgPPiopAfugRpC6u6w@public.gmane.org>
> >
>
> Hi Maxime,
>
> Re-reading the patch I've seen that I've not enabled the SPI nodes, I
> guess it's easier if you revert my patch and that I send a new one ?
Just send the missing nodes, I'll squash the two commits.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ulf Hansson @ 2016-11-28 11:13 UTC (permalink / raw)
To: Ziji Hu
Cc: Gregory CLEMENT, Adrian Hunter, linux-mmc@vger.kernel.org,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree@vger.kernel.org, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Jimmy Xu, Jisheng Zhang,
Nadav Haklai, Ryan Gao, Doug Jones, Victor Gu, Wei(SOCP) Liu,
Wilson Ding
In-Reply-To: <8359307d-5f44-3db9-aae1-eb1fe8e1141d@marvell.com>
>
> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
> send commands for testing current sampling point set in our host PHY.
>
> According to my test result, it shows that mmc_send_tuning() can only support
> tuning command (CMD21/CMD19).
> As a result, we cannot use mmc_send_tuning() when card is in the speed modes
> which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
> SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
> speed modes.
>
> Could you please provide suggestions for the speed mode in which tuning is
> not available?
>
Normally the mmc host driver shouldn't have to care about what the
card supports, as that is the responsibility of the mmc core to
manage.
The host should only need to implement the ->execute_tuning() ops,
which gets called when the card supports tuning (CMD19/21). Does it
make sense?
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ulf Hansson @ 2016-11-28 11:09 UTC (permalink / raw)
To: Ziji Hu
Cc: Gregory CLEMENT, Adrian Hunter, linux-mmc@vger.kernel.org,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Rob Herring,
devicetree@vger.kernel.org, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Jimmy Xu, Jisheng Zhang,
Nadav Haklai, Ryan Gao, Doug Jones, Victor Gu, Wei(SOCP) Liu,
Wilson Ding
In-Reply-To: <436c6925-cb0d-afe7-e3a2-384eca15ff42@marvell.com>
[...]
>
> Could you please tell me the requirement of "op_code" parameter in
> mmc_send_tuning()?
> According to mmc_send_tuning(),it seems that tuning command(CMD19/CMD21)
> is required. Thus device will not response mmc_send_tuning() if current
> speed mode doesn't support tuning command.
> Please correct me if I am wrong.
>
When the mmc core decides it's time to execute tuning, it invokes the
->execute_tuning() host ops, which has the "opcode" as a parameter.
You should be able to use it when calling mmc_send_tuning().
[...]
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Russell King - ARM Linux @ 2016-11-28 10:58 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König, Michal Hrusecki, Tomas Hlavacek,
Bedřicha Košatu, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4ad1108a-43c4-46f8-4683-1c4b89996036-l3A5Bk7waGM@public.gmane.org>
On Mon, Nov 28, 2016 at 11:52:26AM +0100, Andreas Färber wrote:
> Hi Russell,
>
> Am 28.11.2016 um 11:37 schrieb Russell King - ARM Linux:
> > On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas Färber wrote:
> >> To more consistently reference nodes by label, add labels for sata,
> >> usb2, sdhci and usb3 nodes.
> >>
> >> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
> >
> > Please don't do this for clearfog - there's changes in the pipeline which
> > completely replace armada-388-clearfog.dts because there's a "base" and
> > "pro" versions of this hardware now, and making such a huge change will
> > effectively mean we have to start over with the DT files.
>
> Would it help to split it back up into a series of add-labels,
> use-labels like I had originally? Then you could start using them in
> your refactoring as soon as the add-labels patch gets applied. Or are
> you completely against this style?
What I mentioned is not a case of a work in progress, it's already out
in the wild, and completely changing the clearfog dts file by changing
the style of DT references will make applying the changes _much_ more
difficult - not only obviously impossible to apply the original patch,
but also quite impossible to identify the changes made downstream.
So, I'd rather armada-388-clearfog.dts is not touched at all as it _will_
cause conflicts, but I have nothing against the new style (and I actually
prefer it.)
What I'm asking is that you don't make other people's lives harder than
they need to be.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Andreas Färber @ 2016-11-28 10:58 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Russell King - ARM Linux, linux-arm-kernel, Michal Hrusecki,
Tomas Hlavacek, Bedřicha Košatu, Jason Cooper,
Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Mark Rutland, devicetree, linux-kernel
In-Reply-To: <e29e1a96-c9d5-d9b1-a42d-8afddc2714a7@kleine-koenig.org>
Hi,
Am 28.11.2016 um 11:54 schrieb Uwe Kleine-König:
> On 11/28/2016 11:52 AM, Andreas Färber wrote:
>> Would it help to split it back up into a series of add-labels,
>> use-labels like I had originally? Then you could start using them in
>> your refactoring as soon as the add-labels patch gets applied. Or are
>> you completely against this style?
>
> I'd even go as far as:
>
> 1: add labels to .dtsi
> 2: use labels on .dts#1
> 3: use labels on .dts#2
> ...
That was what I had in mind. :) I even considered reusing the existing
labels first, then adding more and converting more nodes.
Making the patches smaller will hopefully make them more easily
reviewable at the same time.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Uwe Kleine-König @ 2016-11-28 10:54 UTC (permalink / raw)
To: Andreas Färber, Russell King - ARM Linux
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Michal Hrusecki, Tomas Hlavacek, Bedřicha Košatu,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4ad1108a-43c4-46f8-4683-1c4b89996036-l3A5Bk7waGM@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 738 bytes --]
Hello,
On 11/28/2016 11:52 AM, Andreas Färber wrote:
>> Please don't do this for clearfog - there's changes in the pipeline which
>> completely replace armada-388-clearfog.dts because there's a "base" and
>> "pro" versions of this hardware now, and making such a huge change will
>> effectively mean we have to start over with the DT files.
>
> Would it help to split it back up into a series of add-labels,
> use-labels like I had originally? Then you could start using them in
> your refactoring as soon as the add-labels patch gets applied. Or are
> you completely against this style?
I'd even go as far as:
1: add labels to .dtsi
2: use labels on .dts#1
3: use labels on .dts#2
...
Best regards
Uwe
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Andreas Färber @ 2016-11-28 10:52 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, Uwe Kleine-König,
devicetree, Tomas Hlavacek, linux-kernel, Rob Herring,
linux-arm-kernel, Gregory Clement, Sebastian Hesselbarth,
Bedřicha Košatu, Michal Hrusecki
In-Reply-To: <20161128103738.GT14217@n2100.armlinux.org.uk>
Hi Russell,
Am 28.11.2016 um 11:37 schrieb Russell King - ARM Linux:
> On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas Färber wrote:
>> To more consistently reference nodes by label, add labels for sata,
>> usb2, sdhci and usb3 nodes.
>>
>> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
>
> Please don't do this for clearfog - there's changes in the pipeline which
> completely replace armada-388-clearfog.dts because there's a "base" and
> "pro" versions of this hardware now, and making such a huge change will
> effectively mean we have to start over with the DT files.
Would it help to split it back up into a series of add-labels,
use-labels like I had originally? Then you could start using them in
your refactoring as soon as the add-labels patch gets applied. Or are
you completely against this style?
Thanks for pointing this out,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Bartosz Golaszewski @ 2016-11-28 10:43 UTC (permalink / raw)
To: Sekhar Nori
Cc: Mark Rutland, linux-devicetree, Kevin Hilman, Michael Turquette,
Jyri Sarha, Russell King, Rob Herring, LKML, Peter Ujfalusi,
Tomi Valkeinen, linux-drm, Frank Rowand, arm-soc,
Laurent Pinchart
In-Reply-To: <86f2b643-c270-1483-4f35-5bdf399a5919@ti.com>
2016-11-28 8:58 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> On Monday 28 November 2016 01:12 PM, Tomi Valkeinen wrote:
>> On 28/11/16 07:24, Sekhar Nori wrote:
>>> On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote:
>>>> It has been determined that the maximum resolution supported correctly
>>>> by tilcdc rev1 on da850 SoCs is 800x600@60. Due to memory throughput
>>>> constraints we must filter out higher modes.
>>>>
>>>> Specify the max-bandwidth property for the display node for
>>>> da850-based boards.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>> ---
>>>> arch/arm/boot/dts/da850.dtsi | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index 8e30d9b..9b7c444 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>> @@ -452,6 +452,7 @@
>>>> compatible = "ti,da850-tilcdc";
>>>> reg = <0x213000 0x1000>;
>>>> interrupts = <52>;
>>>> + max-bandwidth = <28800000>;
>>>
>>> If this is effectively the max pixel clock that the device supports,
>>> then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns).
>>
>> There's a separate property for max-pixelclock. This one is maximum
>> pixels per second (which does sound almost the same), but the doc says
>> it's about the particular memory interface + LCDC combination.
>
> DA850 supports both mDDR and DDR2, at slightly different speeds. So
> memory bandwidth limitation is also board specific. This should probably
> move to board file.
>
> But I would like to know why using max-pixelclock is not good enough.
> Have experiments shown that LCDC on DA850 LCDK underflows even if pixel
> clock is below the datasheet recommendation?
>
Hi Sekhar,
I've just tested 1024x768 at 37000 KHz - indeed seems like the
underflows are gone as soon as we go below 37500 KHz. I'll submit a
new patch using the max-pixelclock property.
Thanks,
Bartosz Golaszewski
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jean-Francois Moine @ 2016-11-28 10:42 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161128095900.27615-1-icenowy-ymACFijhrKM@public.gmane.org>
On Mon, 28 Nov 2016 17:59:00 +0800
Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
> As there's currently a fork of U-Boot which provides simplefb support
> for H3, a simplefb node can be added to the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
>
> I'm still not sure which pipeline should I use.
>
> And, it seems that HDMI Slow Clock is not needed?
>
> (seems that it's only for EDID, but simplefb won't use EDID)
So, I don't see how this may work.
How can the u-boot know the resolutions of the HDMI display device?
In other words: I have a new H3 board with the last u-boot and kernel.
I plug my (rather old or brand new) HDMI display device.
After powering on the system, I hope to get something on the screen.
How?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Russell King - ARM Linux @ 2016-11-28 10:37 UTC (permalink / raw)
To: Andreas Färber
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, Uwe Kleine-König,
devicetree, Tomas Hlavacek, linux-kernel, Rob Herring,
linux-arm-kernel, Gregory Clement, Sebastian Hesselbarth,
Bedřicha Košatu, Michal Hrusecki
In-Reply-To: <1480272700-28888-1-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas Färber wrote:
> To more consistently reference nodes by label, add labels for sata,
> usb2, sdhci and usb3 nodes.
>
> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
Please don't do this for clearfog - there's changes in the pipeline which
completely replace armada-388-clearfog.dts because there's a "base" and
"pro" versions of this hardware now, and making such a huge change will
effectively mean we have to start over with the DT files.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Sebastian Frias @ 2016-11-28 10:34 UTC (permalink / raw)
To: Florian Fainelli, Martin Blumenstingl, Jerome Brunet
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, khilman-rdvid1DuHRBWk0Htik3J/w,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o,
carlo-KA+7E9HrN00dnm+yROfE0A, Mans Rullgard, Andrew Lunn, mason
In-Reply-To: <1b7f113e-34f9-69f4-a45f-9fd687d87990-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 25/11/16 18:44, Florian Fainelli wrote:
> On 11/25/2016 03:13 AM, Sebastian Frias wrote:
>> On 24/11/16 19:55, Florian Fainelli wrote:
<snip>
>>> Correct, the meaning of PHY_INTERFACE_MODE should be from the
>>> perspective of the PHY device:
>>>
>>> - PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
>>> adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
>>> - PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
>>> adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
>>>
>>
>> Thanks for the explanation.
>> Actually I had thought that the delay was to account for board routing
>> (wires) between the MAC and the PHY.
>> From your explanation it appears that the delay is to account for board
>> routing (wires) between the PHY and the RJ45 socket.
>
> The placement of the (delay) was not meant to be exact, but it was
> wrongly place anyway, so it should be between the MAC and PHY, always.
> This is why you see people either fixing the need for a delay by
> appropriately programming the PHY, or the MAC, or by just inserting a
> fixed delay on the PCB between the PHY and the MAC and programming no
> delays (or using the default values and hoping this works).
Thanks.
Your patch "[PATCH net-next 3/4] Documentation: net: phy: Add blurb about
RGMII" on the documentation makes it clear.
>>>
>>> This also seems reasonable to do, provided that the PHY is also properly
>>> configured not to add delays in both directions, and therefore assumes
>>> that the MAC does it.
>>>
>>> We have a fairly large problem with how RGMII delays are done in PHYLIB
>>> and Ethernet MAC drivers (or just in general), where we can't really
>>> intersect properly what a PHY is supporting (in terms of internal
>>> delays), and what the MAC supports either. One possible approach could
>>> be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
>>> support (ideally, even with normalized nanosecond delay values),
>>
>> Just to make sure I understood this, the DT would say something like:
>>
>> phy-connection-type = "rgmii-txid";
>> txid-delay-ns = <3>;
>>
>> For a 3ns TX delay, would that be good?
>
> That's one possibility, although, see below, some PHYs support
> sub-nanosecond values, but in general, that seems like a good
> representation. If the "txid-delay-ns" property is omitted, a standard
> 2ns delay is assumed.
Sounds good.
I did not see the "txid-delay-ns" property documented in your patches, if
it is not too late, maybe it could be "txid-delay-ps" using picoseconds as
unit, right?
>>> and
>>> then intersect that with the requested phy_interface_t during
>>> phy_{attach,connect} time, and feed this back to the MAC with a special
>>> error code/callback, so we could gracefully try to choose another
>>> PHY_INTERFACE_MODE_* value that the MAC supports....
>>>
>>> A larger problem is that a number of drivers have been deployed, and
>>> Device Trees, possibly with the meaning of "phy-mode" and
>>> "phy-connection-type" being from the MAC perspective, and not the PHY
>>> perspective *sigh*, good luck auditing those.
>>>
>>> So from there, here is possibly what we could do
>>>
>>> - submit a series of patches that update the PHYLIB documentation (there
>>> are other things missing here) and make it clear from which entity (PHY
>>> or MAC) does the delay apply to, document the "intersection" problem here
>>
>> I think documenting is necessary, thanks in advance!
>>
>> However, I'm wondering if there's a way to make this work in all cases.
>> Indeed, if we consider for example that TX delay is required, we have 4
>> cases:
>>
>> PHY | MAC | Who applies?
>> TXID supported | TXID supported | PHY
>> TXID supported | TXID not supported | PHY
>> TXID not supported | TXID supported | MAC
>> TXID not supported | TXID not supported | cannot be done
>>
>> That is basically what my patch:
>>
>> https://marc.info/?l=linux-netdev&m=147869658031783&w=2
>>
>> attempted to achieve. That would allow more combinations of MAC<->PHY to
>> work, right?
>
> Yes, indeed.
Just one thing, from your patch "[PATCH net-next 3/4] Documentation: net:
phy: Add blurb about RGMII" I have the impression that the 3rd option from
the table above, would be a little bit more complex to implement.
I will comment on the patch.
>> Nevertheless, I think we also need to keep in mind that most of this
>> discussion assumes the case where both, MAC and PHY have equal capabilities.
>> Could it happen that the PHY supports only 2ns delay, and the MAC only
>> 1ns delay?
>
> I doubt this exists at the MAC level what we should have is either a 2ns
> delay, in either RX or TX path, or nothing, because that's the value
> that results in shifting the data lines and the RX/TX lines by 90
> degrees at 125Mhz (1/125^6 = 8 ns, one quarter shift is 90 degrees =
> 2ns). The PHY may have a similar set of pre-programmed, fixed 2ns
> delays, but it is not uncommon to see 0.X ns resolution available:
>
> drivers/net/phy/mscc.c
> drivers/net/phy/dp83867.c w/ arch/arm/boot/dts/dra72-evm-revc.dts
>
> In these cases, if you end-up using a non 2ns delay, you are fixing a
> PCB problem more than an interoperability problem between your MAC and PHY.
I see, thanks.
>> Could it happen that the delay is bigger than what is supported by
>> either the PHY or MAC alone? maybe if combined it could work, for example
>> a 3ns delay required and the PHY supporting 2ns and the MAC 1ns, combined
>> it could work?
>
> I suppose such a thing would work yes, but it would be difficult to
> report correctly to the core PHYLIB how this can work considering the
> vast array of options available to introduce delays in that case:
> MAC-level, PHY-level, pinctrl/pad level and possibly at the PCB itself.
>
> Once we can't rely on the fixed 2ns delay to work, we are going to have
> people do various experiments until they can either measure what the
> right delay value is for the specific PCB, or they just found the value
> that happens to work. I don't think we can do much at that point from a
> core PHYLIB perspective other than tell the network driver that the PHY
> supports delay in either RX, TX or both directions, and have the MAC
> decide what to apply that makes sense here, considering that this is
> already kind of an exceptional situation to be in.
Fair enough.
And thanks again for documenting this.
--
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 net-next v3 2/4] dt-bindings: net: add EEE capability constants
From: Yegor Yefremov @ 2016-11-28 10:28 UTC (permalink / raw)
To: Jerome Brunet
Cc: devicetree, Florian Fainelli, Alexandre TORGUE, Andrew Lunn,
Martin Blumenstingl, netdev, Neil Armstrong, kernel list,
Andre Roth, Kevin Hilman, Carlo Caione, Giuseppe Cavallaro,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1480326409-25419-3-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 28, 2016 at 10:46 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested using Baltos ir2110 device (cpsw + at8035 PHY).
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/dt-bindings/net/mdio.h
>
> diff --git a/include/dt-bindings/net/mdio.h b/include/dt-bindings/net/mdio.h
> new file mode 100644
> index 000000000000..99c6d903d439
> --- /dev/null
> +++ b/include/dt-bindings/net/mdio.h
> @@ -0,0 +1,19 @@
> +/*
> + * This header provides generic constants for ethernet MDIO bindings
> + */
> +
> +#ifndef _DT_BINDINGS_NET_MDIO_H
> +#define _DT_BINDINGS_NET_MDIO_H
> +
> +/*
> + * EEE capability Advertisement
> + */
> +
> +#define MDIO_EEE_100TX 0x0002 /* 100TX EEE cap */
> +#define MDIO_EEE_1000T 0x0004 /* 1000T EEE cap */
> +#define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
> +#define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap */
> +#define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap */
> +#define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap */
> +
> +#endif
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH net-next v3 1/4] net: phy: add an option to disable EEE advertisement
From: Yegor Yefremov @ 2016-11-28 10:28 UTC (permalink / raw)
To: Jerome Brunet
Cc: devicetree, Florian Fainelli, Alexandre TORGUE, Andrew Lunn,
Martin Blumenstingl, netdev, Neil Armstrong, kernel list,
Andre Roth, Kevin Hilman, Carlo Caione, Giuseppe Cavallaro,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1480326409-25419-2-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 28, 2016 at 10:46 AM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> This patch adds an option to disable EEE advertisement in the generic PHY
> by providing a mask of prohibited modes corresponding to the value found in
> the MDIO_AN_EEE_ADV register.
>
> On some platforms, PHY Low power idle seems to be causing issues, even
> breaking the link some cases. The patch provides a convenient way for these
> platforms to disable EEE advertisement and work around the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested using Baltos ir2110 device (cpsw + at8035 PHY).
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> drivers/net/phy/phy.c | 3 ++
> drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
> include/linux/phy.h | 3 ++
> 3 files changed, 77 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 73adbaa9ac86..a3981cc6448a 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -1396,6 +1396,9 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
> {
> int val = ethtool_adv_to_mmd_eee_adv_t(data->advertised);
>
> + /* Mask prohibited EEE modes */
> + val &= ~phydev->eee_broken_modes;
> +
> phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, val);
>
> return 0;
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index ba86c191a13e..83e52f1b80f2 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1121,6 +1121,43 @@ static int genphy_config_advert(struct phy_device *phydev)
> }
>
> /**
> + * genphy_config_eee_advert - disable unwanted eee mode advertisement
> + * @phydev: target phy_device struct
> + *
> + * Description: Writes MDIO_AN_EEE_ADV after disabling unsupported energy
> + * efficent ethernet modes. Returns 0 if the PHY's advertisement hasn't
> + * changed, and 1 if it has changed.
> + */
> +static int genphy_config_eee_advert(struct phy_device *phydev)
> +{
> + u32 broken = phydev->eee_broken_modes;
> + u32 old_adv, adv;
> +
> + /* Nothing to disable */
> + if (!broken)
> + return 0;
> +
> + /* If the following call fails, we assume that EEE is not
> + * supported by the phy. If we read 0, EEE is not advertised
> + * In both case, we don't need to continue
> + */
> + adv = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN);
> + if (adv <= 0)
> + return 0;
> +
> + old_adv = adv;
> + adv &= ~broken;
> +
> + /* Advertising remains unchanged with the broken mask */
> + if (old_adv == adv)
> + return 0;
> +
> + phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, adv);
> +
> + return 1;
> +}
> +
> +/**
> * genphy_setup_forced - configures/forces speed/duplex from @phydev
> * @phydev: target phy_device struct
> *
> @@ -1178,15 +1215,20 @@ EXPORT_SYMBOL(genphy_restart_aneg);
> */
> int genphy_config_aneg(struct phy_device *phydev)
> {
> - int result;
> + int err, changed;
> +
> + changed = genphy_config_eee_advert(phydev);
>
> if (AUTONEG_ENABLE != phydev->autoneg)
> return genphy_setup_forced(phydev);
>
> - result = genphy_config_advert(phydev);
> - if (result < 0) /* error */
> - return result;
> - if (result == 0) {
> + err = genphy_config_advert(phydev);
> + if (err < 0) /* error */
> + return err;
> +
> + changed |= err;
> +
> + if (changed == 0) {
> /* Advertisement hasn't changed, but maybe aneg was never on to
> * begin with? Or maybe phy was isolated?
> */
> @@ -1196,16 +1238,16 @@ int genphy_config_aneg(struct phy_device *phydev)
> return ctl;
>
> if (!(ctl & BMCR_ANENABLE) || (ctl & BMCR_ISOLATE))
> - result = 1; /* do restart aneg */
> + changed = 1; /* do restart aneg */
> }
>
> /* Only restart aneg if we are advertising something different
> * than we were before.
> */
> - if (result > 0)
> - result = genphy_restart_aneg(phydev);
> + if (changed > 0)
> + return genphy_restart_aneg(phydev);
>
> - return result;
> + return 0;
> }
> EXPORT_SYMBOL(genphy_config_aneg);
>
> @@ -1563,6 +1605,21 @@ static void of_set_phy_supported(struct phy_device *phydev)
> __set_phy_supported(phydev, max_speed);
> }
>
> +static void of_set_phy_eee_broken(struct phy_device *phydev)
> +{
> + struct device_node *node = phydev->mdio.dev.of_node;
> + u32 broken;
> +
> + if (!IS_ENABLED(CONFIG_OF_MDIO))
> + return;
> +
> + if (!node)
> + return;
> +
> + if (!of_property_read_u32(node, "eee-broken-modes", &broken))
> + phydev->eee_broken_modes = broken;
> +}
> +
> /**
> * phy_probe - probe and init a PHY device
> * @dev: device to probe and init
> @@ -1600,6 +1657,11 @@ static int phy_probe(struct device *dev)
> of_set_phy_supported(phydev);
> phydev->advertising = phydev->supported;
>
> + /* Get the EEE modes we want to prohibit. We will ask
> + * the PHY stop advertising these mode later on
> + */
> + of_set_phy_eee_broken(phydev);
> +
> /* Set the state to READY by default */
> phydev->state = PHY_READY;
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index edde28ce163a..b53177fd38af 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -417,6 +417,9 @@ struct phy_device {
> u32 advertising;
> u32 lp_advertising;
>
> + /* Energy efficient ethernet modes which should be prohibited */
> + u32 eee_broken_modes;
> +
> int autoneg;
>
> int link_timeout;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [RFC PATCH 3/3] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Neil Armstrong @ 2016-11-28 10:25 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, Xing.Xu, victor.wan, airlied, khilman, linux-kernel,
dri-devel, linux-amlogic, carlo, jerry.cao, linux-arm-kernel
In-Reply-To: <1695441.JP1H7VIm1f@avalon>
On 11/28/2016 11:02 AM, Laurent Pinchart wrote:
> Hi Neil,
>
> On Monday 28 Nov 2016 10:56:30 Neil Armstrong wrote:
>> On 11/28/2016 10:37 AM, Laurent Pinchart wrote:
>>> On Monday 28 Nov 2016 10:23:43 Neil Armstrong wrote:
>>>> On 11/28/2016 09:33 AM, Laurent Pinchart wrote:
>>>>> On Friday 25 Nov 2016 17:03:11 Neil Armstrong wrote:
>>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>>>> ---
>>>>>>
>>>>>> .../bindings/display/meson/meson-drm.txt | 134
>>>>>> +++++++++++++++
>>>>>> 1 file changed, 134 insertions(+)
>>>>>> create mode 100644
>>>>>>
>>>>>> Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>>>>> b/Documentation/devicetree/bindings/display/meson/meson-drm.txt new
>>>>>> file
>>>>>> mode 100644
>>>>>> index 0000000..89c1b5f
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/display/meson/meson-drm.txt
>>
>> [...]
>>
>>>>>> +
>>>>>> +VENC CBVS Output
>>>>>> +----------------------
>>>>>> +
>>>>>> +The VENC can output Composite/CVBS output via a decicated VDAC.
>>>>>> +
>>>>>> +Required properties:
>>>>>> + - compatible: value must be one of:
>>>>>> + - compatible: value should be different for each SoC family as :
>>>>> One of those two lines is redundant.
>>>>
>>>> Will fix.
>>>>
>>>>>> + - GXBB (S905) : "amlogic,meson-gxbb-venc-cvbs"
>>>>>> + - GXL (S905X, S905D) : "amlogic,meson-gxl-venc-cvbs"
>>>>>> + - GXM (S912) : "amlogic,meson-gxm-venc-cvbs"
>>>>>> + followed by the common "amlogic,meson-gx-venc-cvbs"
>>>>>> +
>>>>>
>>>>> No registers ? Are the encoders registers part of the VPU register
>>>>> space, intertwined in a way that they can't be specified separately here
>>>>> ?
>>>>
>>>> Exact, all the video registers on the Amlogic SoC are part of a long
>>>> history of fixup/enhance from very old SoCs, it's quite hard to
>>>> distinguish a Venc registers array since they are mixed with the
>>>> multiple encoders registers...
>>>
>>> In that case is there really a reason to model the encoders as separate
>>> nodes in DT ?
>>
>> Here, it more the encoder-connector couple that is represented as a node,
>> and the CVBS output is optional.
>
> You should actually have a DT node for the connector. I would merge the
> encoders into the VPU node (especially given that according to your diagram
> they are part of the VPU), and document the VPU output ports explicitly. If
> the CVBS output is not implemented by some of the SoCs in the family then the
> corresponding DT node should just omit that port.
>
Yes, seems a way better option !
[...]
Thanks for the hints,
Neil
^ permalink raw reply
* Re: Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Chen-Yu Tsai @ 2016-11-28 10:24 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec, Jean-Francois Moine,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <496171480328390-w+qEnKy0EGlxpj1cXAZ9Bg@public.gmane.org>
On Mon, Nov 28, 2016 at 6:19 PM, Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
>
>
> 28.11.2016, 18:07, "Chen-Yu Tsai" <wens-jdAy2FN1RRM@public.gmane.org>:
>> On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
>>> As there's currently a fork of U-Boot which provides simplefb support
>>
>> Please add it when its finalized...
>>
>>> for H3, a simplefb node can be added to the device tree.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>> ---
>>>
>>> I'm still not sure which pipeline should I use.
>>
>> You are supposed to add _all_ the pipelines that are available and
>> supported by U-boot. U-boot is then supposed to enable and update
>> the one it set up.
>
> I mean the pipeline string ;-)
Looks good to me. There's no separate frontend/backend in DE 2.0.
ChenYu
>
>>
>> ChenYu
>>
>>> And, it seems that HDMI Slow Clock is not needed?
>>>
>>> (seems that it's only for EDID, but simplefb won't use EDID)
>>>
>>> arch/arm/boot/dts/sun8i-h3.dtsi | 16 ++++++++++++++++
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 75a8654..cacc8dd 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -50,6 +50,22 @@
>>> / {
>>> interrupt-parent = <&gic>;
>>>
>>> + chosen {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + ranges;
>>> +
>>> + simplefb_hdmi: framebuffer@0 {
>>> + compatible = "allwinner,simple-framebuffer",
>>> + "simple-framebuffer";
>>> + allwinner,pipeline = "de0-lcd0-hdmi";
>>> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_BUS_DE>,
>>> + <&ccu CLK_BUS_HDMI>, <&ccu CLK_DE>,
>>> + <&ccu CLK_TCON0>, <&ccu CLK_HDMI>;
>>> + status = "disabled";
>>> + };
>>> + };
>>> +
>>> cpus {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> --
>>> 2.10.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
^ 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