* Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
From: Michael Ellerman @ 2017-04-07 6:40 UTC (permalink / raw)
To: Rob Herring, Nicholas Piggin
Cc: devicetree@vger.kernel.org, linuxppc-dev, Benjamin Herrenschmidt,
Frank Rowand
In-Reply-To: <CAL_JsqLEvjb8S-+-JEa4ALHeCWHiR1A_4ur9kd3pBRJaFYWVKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
> On Wed, Apr 5, 2017 at 9:32 AM, Nicholas Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Wed, 5 Apr 2017 08:35:06 -0500
>> Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>
>>> On Wed, Apr 5, 2017 at 7:37 AM, Nicholas Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> > Introduce primitives for FDT parsing. These will be used for powerpc
>>> > cpufeatures node scanning, which has quite complex structure but should
>>> > be processed early.
>>>
>>> Have you looked at unflattening the FDT earlier?
>>
>> Hi, thanks for taking a look. Did you mean to trim the cc list?
>
> Ugg, no. I've added everyone back.
>
>> It may be possible but I'd like to avoid it if we can. There might
>> turn out to be some errata or feature that requires early setup. And
>> the current cpu feature parsing code does it with flat dt.
>
> Well, I'd like to avoid expanding usage of flat DT parsing in the
> kernel. But you could just put this function into arch/powerpc and I'd
> never see it, but I like that even less. Mainly, I just wanted to
> raise the point.
>
> Your argument works until you need that setup in assembly code, then
> you are in the situation that you need to either handle the setup in
> bootloader/firmware or have an simple way to determine that condition.
Where Nick does this FDT parsing is literally the first C code that runs
in the kernel. The MMU is off, we don't even know how much memory we
have, or where it is.
So it's basically impossible to do the unflattening earlier. What we
could do is move the CPU feature setup *later*.
As Ben & Nick said that would be a pretty intrusive change, and
definitely not something we want to do now.
What we could probably do is split some of the flat tree parsing, so
that we discover memory, even just some of it, then unflatten, and then
do more setup using the unflattened tree.
But that will require a lot of delicate work. So we'd definitely like to
do that separately from this series.
cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/8] v4l: flash led class: Use fwnode_handle instead of device_node in init
From: kbuild test robot @ 2017-04-07 6:35 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all, linux-media, linux-acpi, devicetree, laurent.pinchart
In-Reply-To: <1491484249-11964-2-git-send-email-sakari.ailus@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc5 next-20170406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x014-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
drivers//leds/leds-max77693.c: In function 'max77693_register_led':
>> drivers//leds/leds-max77693.c:933:45: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
sub_led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
^~~~~~~~~~~~~~~~
>> drivers//leds/leds-max77693.c:933:45: warning: passing argument 2 of 'v4l2_flash_init' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers//leds/leds-max77693.c:23:0:
include/media/v4l2-flash-led-class.h:140:34: note: expected 'struct device_node *' but argument is of type 'int'
static inline struct v4l2_flash *v4l2_flash_init(
^~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/of_fwnode_handle +933 drivers//leds/leds-max77693.c
927 if (ret < 0)
928 return ret;
929
930 max77693_init_v4l2_flash_config(sub_led, led_cfg, &v4l2_sd_cfg);
931
932 /* Register in the V4L2 subsystem. */
> 933 sub_led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
934 fled_cdev, NULL, &v4l2_flash_ops,
935 &v4l2_sd_cfg);
936 if (IS_ERR(sub_led->v4l2_flash)) {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25664 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/8] v4l: async: Provide interoperability between OF and fwnode matching
From: kbuild test robot @ 2017-04-07 6:29 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all, linux-media, linux-acpi, devicetree, laurent.pinchart
In-Reply-To: <1491484249-11964-5-git-send-email-sakari.ailus@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc5 next-20170406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x016-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
drivers/media/v4l2-core/v4l2-async.c: In function 'match_of':
>> drivers/media/v4l2-core/v4l2-async.c:63:6: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
of_fwnode_handle(sd->of_node) : sd->fwnode,
^~~~~~~~~~~~~~~~
>> drivers/media/v4l2-core/v4l2-async.c:63:36: warning: pointer/integer type mismatch in conditional expression
of_fwnode_handle(sd->of_node) : sd->fwnode,
^
>> drivers/media/v4l2-core/v4l2-async.c:64:6: warning: passing argument 2 of 'fwnode_cmp' makes pointer from integer without a cast [-Wint-conversion]
of_fwnode_handle(asd->match.of.node));
^~~~~~~~~~~~~~~~
drivers/media/v4l2-core/v4l2-async.c:44:13: note: expected 'struct fwnode_handle *' but argument is of type 'int'
static bool fwnode_cmp(struct fwnode_handle *one,
^~~~~~~~~~
drivers/media/v4l2-core/v4l2-async.c: In function 'match_fwnode':
drivers/media/v4l2-core/v4l2-async.c:70:36: warning: pointer/integer type mismatch in conditional expression
of_fwnode_handle(sd->of_node) : sd->fwnode,
^
cc1: some warnings being treated as errors
vim +/of_fwnode_handle +63 drivers/media/v4l2-core/v4l2-async.c
57 return one == theother;
58 }
59
60 static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
61 {
62 return fwnode_cmp(sd->of_node ?
> 63 of_fwnode_handle(sd->of_node) : sd->fwnode,
> 64 of_fwnode_handle(asd->match.of.node));
65 }
66
67 static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24847 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API
From: kbuild test robot @ 2017-04-07 6:29 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all, linux-media, linux-acpi, devicetree, laurent.pinchart
In-Reply-To: <1491484249-11964-6-git-send-email-sakari.ailus@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20170406]
[cannot apply to v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x011-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from drivers/media//i2c/s5k5baf.c:33:0:
include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/s5k5baf.c: In function 's5k5baf_parse_device_node':
>> drivers/media//i2c/s5k5baf.c:1871:35: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(node_ep), &ep);
^~~~~~~~~~~~~~~~
>> drivers/media//i2c/s5k5baf.c:1871:35: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/s5k5baf.c:33:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media//i2c/tc358743.c:45:0:
include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/tc358743.c: In function 'tc358743_probe_of':
>> drivers/media//i2c/tc358743.c:1719:46: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
endpoint = v4l2_fwnode_endpoint_alloc_parse(of_fwnode_handle(ep));
^~~~~~~~~~~~~~~~
>> drivers/media//i2c/tc358743.c:1719:46: warning: passing argument 1 of 'v4l2_fwnode_endpoint_alloc_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/tc358743.c:45:0:
include/media/v4l2-fwnode.h:97:30: note: expected 'struct fwnode_handle *' but argument is of type 'int'
struct v4l2_fwnode_endpoint *v4l2_fwnode_endpoint_alloc_parse(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/of_fwnode_handle +1871 drivers/media//i2c/s5k5baf.c
1865 if (!node_ep) {
1866 dev_err(dev, "no endpoint defined at node %s\n",
1867 node->full_name);
1868 return -EINVAL;
1869 }
1870
> 1871 ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(node_ep), &ep);
1872 of_node_put(node_ep);
1873 if (ret)
1874 return ret;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25509 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/8] v4l: flash led class: Use fwnode_handle instead of device_node in init
From: kbuild test robot @ 2017-04-07 6:27 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all, linux-media, linux-acpi, devicetree, laurent.pinchart
In-Reply-To: <1491484249-11964-2-git-send-email-sakari.ailus@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3470 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc5 next-20170406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x013-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
drivers/media//v4l2-core/v4l2-flash-led-class.c: In function 'v4l2_flash_init':
>> drivers/media//v4l2-core/v4l2-flash-led-class.c:642:4: error: 'struct v4l2_subdev' has no member named 'fwnode'; did you mean 'of_node'?
sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
^~
>> drivers/media//v4l2-core/v4l2-flash-led-class.c:642:27: error: implicit declaration of function 'dev_fwnode' [-Werror=implicit-function-declaration]
sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
^~~~~~~~~~
>> drivers/media//v4l2-core/v4l2-flash-led-class.c:642:25: warning: pointer/integer type mismatch in conditional expression
sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
^
>> drivers/media//v4l2-core/v4l2-flash-led-class.c:658:2: error: implicit declaration of function 'fwnode_handle_get' [-Werror=implicit-function-declaration]
fwnode_handle_get(sd->fwnode);
^~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-flash-led-class.c:658:22: error: 'struct v4l2_subdev' has no member named 'fwnode'; did you mean 'of_node'?
fwnode_handle_get(sd->fwnode);
^~
drivers/media//v4l2-core/v4l2-flash-led-class.c:667:22: error: 'struct v4l2_subdev' has no member named 'fwnode'; did you mean 'of_node'?
fwnode_handle_put(sd->fwnode);
^~
drivers/media//v4l2-core/v4l2-flash-led-class.c: In function 'v4l2_flash_release':
drivers/media//v4l2-core/v4l2-flash-led-class.c:687:22: error: 'struct v4l2_subdev' has no member named 'fwnode'; did you mean 'of_node'?
fwnode_handle_put(sd->fwnode);
^~
cc1: some warnings being treated as errors
vim +642 drivers/media//v4l2-core/v4l2-flash-led-class.c
636
637 sd = &v4l2_flash->sd;
638 v4l2_flash->fled_cdev = fled_cdev;
639 v4l2_flash->iled_cdev = iled_cdev;
640 v4l2_flash->ops = ops;
641 sd->dev = dev;
> 642 sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
643 v4l2_subdev_init(sd, &v4l2_flash_subdev_ops);
644 sd->internal_ops = &v4l2_flash_subdev_internal_ops;
645 sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
646 strlcpy(sd->name, config->dev_name, sizeof(sd->name));
647
648 ret = media_entity_pads_init(&sd->entity, 0, NULL);
649 if (ret < 0)
650 return ERR_PTR(ret);
651
652 sd->entity.function = MEDIA_ENT_F_FLASH;
653
654 ret = v4l2_flash_init_controls(v4l2_flash, config);
655 if (ret < 0)
656 goto err_init_controls;
657
> 658 fwnode_handle_get(sd->fwnode);
659
660 ret = v4l2_async_register_subdev(sd);
661 if (ret < 0)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34590 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API
From: kbuild test robot @ 2017-04-07 6:19 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all-JC7UmRfGjtg, linux-media-8fOc0yYH5q9zeIdxy0IIJw,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw
In-Reply-To: <1491484249-11964-6-git-send-email-sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 14010 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20170406]
[cannot apply to v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x016-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from drivers/media/i2c/tvp5150.c:19:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media/i2c/tvp5150.c: In function 'tvp5150_parse_dt':
>> drivers/media/i2c/tvp5150.c:1377:35: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &bus_cfg);
^~~~~~~~~~~~~~~~
>> drivers/media/i2c/tvp5150.c:1377:35: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media/i2c/tvp5150.c:19:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media/i2c/tvp514x.c:41:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media/i2c/tvp514x.c: In function 'tvp514x_get_pdata':
>> drivers/media/i2c/tvp514x.c:1012:33: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
^~~~~~~~~~~~~~~~
>> drivers/media/i2c/tvp514x.c:1012:33: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media/i2c/tvp514x.c:41:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media/i2c/tvp7002.c:36:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media/i2c/tvp7002.c: In function 'tvp7002_get_pdata':
>> drivers/media/i2c/tvp7002.c:904:33: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
^~~~~~~~~~~~~~~~
>> drivers/media/i2c/tvp7002.c:904:33: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media/i2c/tvp7002.c:36:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media/v4l2-core/v4l2-fwnode.c:26:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media/v4l2-core/v4l2-fwnode.c: In function 'v4l2_fwnode_endpoint_parse':
>> drivers/media/v4l2-core/v4l2-fwnode.c:170:2: error: implicit declaration of function 'fwnode_graph_parse_endpoint' [-Werror=implicit-function-declaration]
fwnode_graph_parse_endpoint(fwn, &vfwn->base);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/v4l2-core/v4l2-fwnode.c: In function 'v4l2_fwnode_parse_link':
>> drivers/media/v4l2-core/v4l2-fwnode.c:301:8: error: implicit declaration of function 'fwnode_get_parent' [-Werror=implicit-function-declaration]
fwn = fwnode_get_parent(__fwn);
^~~~~~~~~~~~~~~~~
>> drivers/media/v4l2-core/v4l2-fwnode.c:301:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_parent(__fwn);
^
>> drivers/media/v4l2-core/v4l2-fwnode.c:303:8: error: implicit declaration of function 'fwnode_get_next_parent' [-Werror=implicit-function-declaration]
fwn = fwnode_get_next_parent(fwn);
^~~~~~~~~~~~~~~~~~~~~~
drivers/media/v4l2-core/v4l2-fwnode.c:303:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:306:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:309:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
>> drivers/media/v4l2-core/v4l2-fwnode.c:313:8: error: implicit declaration of function 'fwnode_graph_get_remote_endpoint' [-Werror=implicit-function-declaration]
fwn = fwnode_graph_get_remote_endpoint(fwn);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/v4l2-core/v4l2-fwnode.c:313:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_graph_get_remote_endpoint(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:319:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:321:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:324:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:327:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
cc1: some warnings being treated as errors
--
In file included from drivers/media//i2c/tvp5150.c:19:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/tvp5150.c: In function 'tvp5150_parse_dt':
drivers/media//i2c/tvp5150.c:1377:35: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &bus_cfg);
^~~~~~~~~~~~~~~~
drivers/media//i2c/tvp5150.c:1377:35: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/tvp5150.c:19:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media//i2c/tvp514x.c:41:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/tvp514x.c: In function 'tvp514x_get_pdata':
drivers/media//i2c/tvp514x.c:1012:33: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
^~~~~~~~~~~~~~~~
drivers/media//i2c/tvp514x.c:1012:33: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/tvp514x.c:41:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media//i2c/tvp7002.c:36:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/tvp7002.c: In function 'tvp7002_get_pdata':
drivers/media//i2c/tvp7002.c:904:33: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
^~~~~~~~~~~~~~~~
drivers/media//i2c/tvp7002.c:904:33: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/tvp7002.c:36:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media//v4l2-core/v4l2-fwnode.c:26:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//v4l2-core/v4l2-fwnode.c: In function 'v4l2_fwnode_endpoint_parse':
drivers/media//v4l2-core/v4l2-fwnode.c:170:2: error: implicit declaration of function 'fwnode_graph_parse_endpoint' [-Werror=implicit-function-declaration]
fwnode_graph_parse_endpoint(fwn, &vfwn->base);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-fwnode.c: In function 'v4l2_fwnode_parse_link':
drivers/media//v4l2-core/v4l2-fwnode.c:301:8: error: implicit declaration of function 'fwnode_get_parent' [-Werror=implicit-function-declaration]
fwn = fwnode_get_parent(__fwn);
^~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-fwnode.c:301:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_parent(__fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:303:8: error: implicit declaration of function 'fwnode_get_next_parent' [-Werror=implicit-function-declaration]
fwn = fwnode_get_next_parent(fwn);
^~~~~~~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-fwnode.c:303:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:306:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:309:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:313:8: error: implicit declaration of function 'fwnode_graph_get_remote_endpoint' [-Werror=implicit-function-declaration]
fwn = fwnode_graph_get_remote_endpoint(fwn);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-fwnode.c:313:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_graph_get_remote_endpoint(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:319:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:321:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:324:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:327:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
cc1: some warnings being treated as errors
vim +/base +67 include/media/v4l2-fwnode.h
8219f9b0 Sakari Ailus 2017-04-06 61 * @bus_type: bus type
8219f9b0 Sakari Ailus 2017-04-06 62 * @bus: bus configuration data structure
8219f9b0 Sakari Ailus 2017-04-06 63 * @link_frequencies: array of supported link frequencies
8219f9b0 Sakari Ailus 2017-04-06 64 * @nr_of_link_frequencies: number of elements in link_frequenccies array
8219f9b0 Sakari Ailus 2017-04-06 65 */
8219f9b0 Sakari Ailus 2017-04-06 66 struct v4l2_fwnode_endpoint {
8219f9b0 Sakari Ailus 2017-04-06 @67 struct fwnode_endpoint base;
8219f9b0 Sakari Ailus 2017-04-06 68 /*
8219f9b0 Sakari Ailus 2017-04-06 69 * Fields below this line will be zeroed by
8219f9b0 Sakari Ailus 2017-04-06 70 * v4l2_fwnode_parse_endpoint()
:::::: The code at line 67 was first introduced by commit
:::::: 8219f9b04bb5639303351ca63b349966aecb9537 v4l: fwnode: Support generic fwnode for parsing standardised properties
:::::: TO: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
:::::: CC: 0day robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24860 bytes --]
^ permalink raw reply
* Re: [PATCH] of: change fixup of dma-ranges size to error
From: Frank Rowand @ 2017-04-07 5:18 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_Jsq+VreUFtA8ozs0Jcz45PTc-jTT=CEKuezeU7QYviiN-Jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 04/06/17 15:41, Rob Herring wrote:
> On Thu, Apr 6, 2017 at 1:37 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 04/06/17 07:03, Rob Herring wrote:
>>> On Thu, Apr 6, 2017 at 1:18 AM, <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>>>>
>>>> of_dma_get_range() has workaround code to fixup a device tree that
>>>> incorrectly specified a mask instead of a size for property
>>>> dma-ranges. That device tree was fixed a year ago in v4.6, so
>>>> the workaround is no longer needed. Leave a data validation
>>>> check in place, but no longer do the fixup. Move the check
>>>> one level deeper in the call stack so that other possible users
>>>> of dma-ranges will also be protected.
>>>>
>>>> The fix to the device tree was in
>>>> commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree").
>>>
>>> NACK.
>>> This was by design. You can't represent a size of 2^64 or 2^32.
>>
>> I agree that being unable to represent a size of 2^32 in a u32 and
>> a size of 2^64 in a u64 is the underlying issue.
>>
>> But the code to convert a mask to a size is _not_ design, it is a
>> hack that temporarily worked around a device tree that did not follow
>> the dma-ranges binding in the ePAPR.
>
> Since when is (2^64 - 1) not a size. It's a perfectly valid size in
I did not say (2^64 -1) is not a size.
I said that the existing code has a hack that converts what is perceived
to be a mask into a size. The existing code is:
@@ 110,21 @@ void of_dma_configure(struct device *dev, struct device_node *np)
size = dev->coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
/*
* Add a work around to treat the size as mask + 1 in case
* it is defined in DT as a mask.
*/
if (size & 1) {
dev_warn(dev, "Invalid size 0x%llx for dma-range\n",
size);
size = size + 1;
}
if (!size) {
dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
return;
}
dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
}
Note the comment that says "in case it is defined in DT as a mask."
And as you stated in a review comment is 2015: "Also, we need a WARN
here so DTs get fixed."
> DT. And there's probably not a system in the world that needs access
> to that last byte. Is it completely accurate description if we
> subtract off 1? No, but it is still a valid range (so would be
> subtracting 12345).
>
>> That device tree was corrected a year ago to provide a size instead of
>> a mask.
>
> You are letting Linux implementation details influence your DT
> thinking. DT is much more flexible in that it supports a base address
> and size (and multiple of them) while Linux can only deal with a
> single address mask. If Linux dealt with base + size, then we wouldn't
No. of_dma_get_range() returns two addresses and a size from the
dma-ranges property, just as it is defined in the spec.
of_dma_configure() then interprets an odd size as meaning that the
device tree incorrectly contains a mask, and then converts that mask
to a size by adding one to it. Linux is _still_ using address and
size at this point. It does _not_ convert this size into a mask,
but instead passes size on into arch_setup_dma_ops().
The proposed patch is to quit accepting a mask as valid data in
dma-ranges.
> be having this conversation. As long as Linux only deals with masks,
> we're going to have to have some sort of work-around to deal with
> them.
>
>>> Well, technically you can for the latter, but then you have to grow
>>> #size-cells to 2 for an otherwise all 32-bit system which seems kind
>>> of pointless and wasteful. You could further restrict this to only
>>> allow ~0 and not just any case with bit 0 set.
>>>
>>> I'm pretty sure AMD is not the only system. There were 32-bit systems too.
>>
>> I examined all instances of property dma-ranges in in tree dts files in
>> Linux 4.11-rc1. There are none that incorrectly specify mask instead of
>> size.
>
> Okay, but there are ones for ranges at least. See ecx-2000.dts.
The patch does not impact the ranges property. It only impacts the
dma-ranges property.
>
>> #size-cells only changes to 2 for the dma-ranges property and the ranges
>> property when size is 2^32, so that is a very small amount of space.
>>
>> The patch does not allow for a size of 2^64. If a system requires a
>> size of 2^64 then the type of size needs to increase to be larger
>> than a u64. If you would like for the code to be defensive and
>> detect a device tree providing a size of 2^64 then I can add a
>> check to of_dma_get_range() to return -EINVAL if #size-cells > 2.
>> When that error triggers, the type of size can be changed.
>
> #size-cells > 2 is completely broken for anything but PCI. I doubt it
Yes, that is what I said. The current code does not support #size-cells > 2
for dma-ranges.
#size-cells > 2 for dma-ranges will lead to a problem in
of_dma_get_range(), which stuffs the value of the size into a u64.
Clearly, a 3 cell size will not fit into a u64.
> is easily fixed without some special casing (i.e. a different hack)
> until we have 128-bit support. I hope to retire before we need to
> support that.
>
> Rob
>
Can we get back to the basic premise of the proposed patch?
The current code in of_dma_configure() contains a hack that allows the
dma-ranges property to specify a mask instead of a size. The binding
in the specification allows a size and does not allow a mask.
The hack was added to account for one or more dts files that did not
follow the specification. In the mail list discussion of the hack
you said "Also, we need a WARN here so DTs get fixed."
The hack was first present in Linux 4.1. The only in-tree dts that
incorrectly contained a mask instead of a size in dma-ranges was
arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
That .dtsi was fixed by
commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree")
The fix was present in Linux 4.6, May 15, 2016.
I would like to remove the hack. I think that enough time has
elapsed to allow this change.
-Frank
--
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 V7 0/7] da9061: DA9061 driver submission
From: Eduardo Valentin @ 2017-04-07 4:51 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, Dmitry Torokhov, Guenter Roeck, LINUX-INPUT,
LINUX-KERNEL, LINUX-PM, LINUX-WATCHDOG, Lee Jones, Liam Girdwood,
Lukasz Luba, Mark Brown, Mark Rutland, Rob Herring,
Wim Van Sebroeck, Zhang Rui, Support Opensource
In-Reply-To: <cover.1490712213.git.stwiss.opensource@diasemi.com>
[-- Attachment #1: Type: text/plain, Size: 461 bytes --]
Hey,
On Tue, Mar 28, 2017 at 03:43:33PM +0100, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> This patch set adds support for the Dialog DA9061 Power Management IC.
> Support is made by altering the existing DA9062 device driver, where
> appropriate.
>
> Hello,
>
> Previously, there were only minor changes for v6.
> The patch v7 introduces a compile test for x86 64-bit.
>
Applied patches 2 and 7 on my tree.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V5 2/2] thermal: broadcom: add Northstar thermal driver
From: Eduardo Valentin @ 2017-04-07 4:42 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Zhang Rui, Rob Herring, Mark Rutland, Stephen Warren, Lee Jones,
Eric Anholt, Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Rafał Miłecki, Jon Mason
In-Reply-To: <20170403154829.29780-2-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 7189 bytes --]
On Mon, Apr 03, 2017 at 05:48:29PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Northstar is a SoC family commonly used in home routers. This commit
> adds a driver for checking CPU temperature. As Northstar Plus seems to
> also have this IP block this new symbol gets ARCH_BCM_IPROC dependency.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
If no objection, I am applying this series.
> ---
> V2: Make it iProc specific as NSP can also use this driver
> Select proper symbols in config ARCH_BCM_IPROC
> Define PVTMON register bits
> Update code selecting temperature monitor mode
> Thank you Jon!
> V3: More details in help message for BCM_NS_THERMAL
> Use slope & offset
> Drop arch code change (I'll be submitted using a proper tree)
> Thank you Eduardo!
> V4: Comment operations on PVTMON_CONTROL0 register
> ---
> drivers/thermal/Kconfig | 5 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/broadcom/Kconfig | 8 +++
> drivers/thermal/broadcom/Makefile | 1 +
> drivers/thermal/broadcom/ns-thermal.c | 105 ++++++++++++++++++++++++++++++++++
> 5 files changed, 120 insertions(+)
> create mode 100644 drivers/thermal/broadcom/Kconfig
> create mode 100644 drivers/thermal/broadcom/Makefile
> create mode 100644 drivers/thermal/broadcom/ns-thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 3bd24063375e..ac7301703d03 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -392,6 +392,11 @@ config MTK_THERMAL
> Enable this option if you want to have support for thermal management
> controller present in Mediatek SoCs
>
> +menu "Broadcom thermal drivers"
> +depends on ARCH_BCM || COMPILE_TEST
> +source "drivers/thermal/broadcom/Kconfig"
> +endmenu
> +
> menu "Texas Instruments thermal drivers"
> depends on ARCH_HAS_BANDGAP || COMPILE_TEST
> depends on HAS_IOMEM
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index f23cde05dac6..6b7706b9f27c 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -27,6 +27,7 @@ thermal_sys-$(CONFIG_CLOCK_THERMAL) += clock_cooling.o
> thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>
> # platform thermal drivers
> +obj-y += broadcom/
> obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
> new file mode 100644
> index 000000000000..f0dea8a8e002
> --- /dev/null
> +++ b/drivers/thermal/broadcom/Kconfig
> @@ -0,0 +1,8 @@
> +config BCM_NS_THERMAL
> + tristate "Northstar thermal driver"
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + help
> + Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
> + BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
> + with a thermal sensor that allows checking CPU temperature. This
> + driver provides support for it.
> diff --git a/drivers/thermal/broadcom/Makefile b/drivers/thermal/broadcom/Makefile
> new file mode 100644
> index 000000000000..059df9a0ed69
> --- /dev/null
> +++ b/drivers/thermal/broadcom/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_BCM_NS_THERMAL) += ns-thermal.o
> diff --git a/drivers/thermal/broadcom/ns-thermal.c b/drivers/thermal/broadcom/ns-thermal.c
> new file mode 100644
> index 000000000000..eab96b3572b9
> --- /dev/null
> +++ b/drivers/thermal/broadcom/ns-thermal.c
> @@ -0,0 +1,105 @@
> +/*
> + * Copyright (C) 2017 Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +#define PVTMON_CONTROL0 0x00
> +#define PVTMON_CONTROL0_SEL_MASK 0x0000000e
> +#define PVTMON_CONTROL0_SEL_TEMP_MONITOR 0x00000000
> +#define PVTMON_CONTROL0_SEL_TEST_MODE 0x0000000e
> +#define PVTMON_STATUS 0x08
> +
> +struct ns_thermal {
> + struct thermal_zone_device *tz;
> + void __iomem *pvtmon;
> +};
> +
> +static int ns_thermal_get_temp(void *data, int *temp)
> +{
> + struct ns_thermal *ns_thermal = data;
> + int offset = thermal_zone_get_offset(ns_thermal->tz);
> + int slope = thermal_zone_get_slope(ns_thermal->tz);
> + u32 val;
> +
> + val = readl(ns_thermal->pvtmon + PVTMON_CONTROL0);
> + if ((val & PVTMON_CONTROL0_SEL_MASK) != PVTMON_CONTROL0_SEL_TEMP_MONITOR) {
> + /* Clear current mode selection */
> + val &= ~PVTMON_CONTROL0_SEL_MASK;
> +
> + /* Set temp monitor mode (it's the default actually) */
> + val |= PVTMON_CONTROL0_SEL_TEMP_MONITOR;
> +
> + writel(val, ns_thermal->pvtmon + PVTMON_CONTROL0);
> + }
> +
> + val = readl(ns_thermal->pvtmon + PVTMON_STATUS);
> + *temp = slope * val + offset;
> +
> + return 0;
> +}
> +
> +const struct thermal_zone_of_device_ops ns_thermal_ops = {
minor correction here:
-const struct thermal_zone_of_device_ops ns_thermal_ops = {
+static const struct thermal_zone_of_device_ops ns_thermal_ops = {
but I am applying this already in my tree.
> + .get_temp = ns_thermal_get_temp,
> +};
> +
> +static int ns_thermal_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct ns_thermal *ns_thermal;
> +
> + ns_thermal = devm_kzalloc(dev, sizeof(*ns_thermal), GFP_KERNEL);
> + if (!ns_thermal)
> + return -ENOMEM;
> +
> + ns_thermal->pvtmon = of_iomap(dev_of_node(dev), 0);
> + if (WARN_ON(!ns_thermal->pvtmon))
> + return -ENOENT;
> +
> + ns_thermal->tz = devm_thermal_zone_of_sensor_register(dev, 0,
> + ns_thermal,
> + &ns_thermal_ops);
> + if (IS_ERR(ns_thermal->tz)) {
> + iounmap(ns_thermal->pvtmon);
> + return PTR_ERR(ns_thermal->tz);
> + }
> +
> + platform_set_drvdata(pdev, ns_thermal);
> +
> + return 0;
> +}
> +
> +static int ns_thermal_remove(struct platform_device *pdev)
> +{
> + struct ns_thermal *ns_thermal = platform_get_drvdata(pdev);
> +
> + iounmap(ns_thermal->pvtmon);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ns_thermal_of_match[] = {
> + { .compatible = "brcm,ns-thermal", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ns_thermal_of_match);
> +
> +static struct platform_driver ns_thermal_driver = {
> + .probe = ns_thermal_probe,
> + .remove = ns_thermal_remove,
> + .driver = {
> + .name = "ns-thermal",
> + .of_match_table = ns_thermal_of_match,
> + },
> +};
> +module_platform_driver(ns_thermal_driver);
> +
> +MODULE_DESCRIPTION("Northstar thermal driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.11.0
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V10 06/12] of: device: Fix overflow of coherent_dma_mask
From: Sricharan R @ 2017-04-07 4:12 UTC (permalink / raw)
To: Frank Rowand, robin.murphy, will.deacon, joro, lorenzo.pieralisi,
iommu, linux-arm-kernel, linux-arm-msm, m.szyprowski, bhelgaas,
linux-pci, linux-acpi, tn, hanjun.guo, okaya, robh+dt, devicetree,
linux-kernel, sudeep.holla, rjw, lenb, catalin.marinas, arnd,
linux-arch, gregkh
In-Reply-To: <58E69831.6010306@gmail.com>
Hi Frank,
On 4/7/2017 1:04 AM, Frank Rowand wrote:
> On 04/06/17 04:01, Sricharan R wrote:
>> Hi Frank,
>>
>> On 4/6/2017 12:31 PM, Frank Rowand wrote:
>>> On 04/04/17 03:18, Sricharan R wrote:
>>>> Size of the dma-range is calculated as coherent_dma_mask + 1
>>>> and passed to arch_setup_dma_ops further. It overflows when
>>>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF,
>>>> resulting in size getting passed as 0 wrongly. Fix this by
>>>> passsing in max(mask, mask + 1). Note that in this case
>>>> when the mask is set to full 64bits, we will be passing the mask
>>>> itself to arch_setup_dma_ops instead of the size. The real fix
>>>> for this should be to make arch_setup_dma_ops receive the
>>>> mask and handle it, to be done in the future.
>>>>
>>>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>>>> ---
>>>> drivers/of/device.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>>>> index c17c19d..c2ae6bb 100644
>>>> --- a/drivers/of/device.c
>>>> +++ b/drivers/of/device.c
>>>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>>>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>>>> if (ret < 0) {
>>>> dma_addr = offset = 0;
>>>> - size = dev->coherent_dma_mask + 1;
>>>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>>> } else {
>>>> offset = PFN_DOWN(paddr - dma_addr);
>>>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>>>
>>>
>>> NACK.
>>>
>>> Passing an invalid size to arch_setup_dma_ops() is only part of the problem.
>>> size is also used in of_dma_configure() before calling arch_setup_dma_ops():
>>>
>>> dev->coherent_dma_mask = min(dev->coherent_dma_mask,
>>> DMA_BIT_MASK(ilog2(dma_addr + size)));
>>> *dev->dma_mask = min((*dev->dma_mask),
>>> DMA_BIT_MASK(ilog2(dma_addr + size)));
>>>
>>> which would be incorrect for size == 0xffffffffffffffffULL when
>>> dma_addr != 0. So the proposed fix really is not papering over
>>> the base problem very well.
>>>
>>
>> Ok, but with your fix for of_dma_get_range and the above fix,
>> dma_addr will be '0' when size = 0xffffffffffffffffULL,
>> but DMA_BIT_MASK(ilog2(dma_addr + size)) would be wrong though,
>> making coherent_dma_mask to be smaller 0x7fffffffffffffffULL.
>
> Yes, that was my point. Setting size to 0x7fffffffffffffffULL
> affects several places. Another potential location (based only
> on the function header comment, not from reading the code) is
> iommu_dma_init_domain(). The header comment says:
>
> * @base and @size should be exact multiples of IOMMU page granularity to
> * avoid rounding surprises.
>
ok, this is the same problem that should get solved when arch_setup_dma_ops
is prepared to take mask instead of size. It would still work as said above
with a smaller mask than specified.
> I have not read enough context to really understand of_dma_configure(), but
> it seems there is yet another issue in how the error return case from
> of_dma_get_range() is handled (with the existing code, as well as if
> my patch gets accepted). An error return value can mean _either_
> there is no dma-ranges property _or_ "an other problem occurred". Should
> the "an other problem occurred" case be handled by defaulting size to
> a value based on dev->coherent_dma_mask (the current case) or should the
> attempt to set up the DMA configuration just fail?
The handling of return error value looks like separate item, but looks
like its correct with what is there now. (ie) when of_dma_get_range fails
either because 'dma-ranges property' populated in DT (or) because of some
erroneous DT setting, better to set the mask which the driver has specified
and ignore DT. So the above patch just corrects a mistake in that path.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v2 4/4] drm: zte: add VGA driver support
From: Shawn Guo @ 2017-04-07 3:02 UTC (permalink / raw)
To: Sean Paul
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Daniel Vetter,
Baoyou Xie, Xin Zhou, Jun Nie, Shawn Guo
In-Reply-To: <20170406171251.qlzdjmzalunplbdt@art_vandelay>
On Thu, Apr 06, 2017 at 01:12:51PM -0400, Sean Paul wrote:
> On Thu, Apr 06, 2017 at 11:01:10PM +0800, Shawn Guo wrote:
> > +static int zx_vga_connector_get_modes(struct drm_connector *connector)
> > +{
> > + struct zx_vga *vga = to_zx_vga(connector);
> > + unsigned long flags;
> > + struct edid *edid;
> > + int ret;
> > +
> > + /*
> > + * Clear both detection bits to switch I2C bus from device
> > + * detecting to EDID reading.
> > + */
> > + spin_lock_irqsave(&vga->lock, flags);
> > + zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
> > + spin_unlock_irqrestore(&vga->lock, flags);
> > +
> > + edid = drm_get_edid(connector, &vga->ddc->adap);
> > + if (!edid)
> > + return 0;
> > +
> > + /*
> > + * As edid reading succeeds, device must be connected, so we set
> > + * up detection bit for unplug interrupt here.
> > + */
> > + spin_lock_irqsave(&vga->lock, flags);
> > + zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, VGA_DETECT_SEL_HAS_DEVICE);
> > + spin_unlock_irqrestore(&vga->lock, flags);
> > +
> > + drm_mode_connector_update_edid_property(connector, edid);
> > + ret = drm_add_edid_modes(connector, edid);
> > + kfree(edid);
> > +
> > + return ret;
> > +}
<snip>
> > +static irqreturn_t zx_vga_irq_handler(int irq, void *dev_id)
> > +{
> > + struct zx_vga *vga = dev_id;
> > + u32 status;
> > +
> > + status = zx_readl(vga->mmio + VGA_I2C_STATUS);
> > +
> > + /* Clear interrupt status */
> > + zx_writel_mask(vga->mmio + VGA_I2C_STATUS, VGA_CLEAR_IRQ,
> > + VGA_CLEAR_IRQ);
> > +
> > + if (status & VGA_DEVICE_CONNECTED) {
> > + /*
> > + * Since VGA_DETECT_SEL bits need to be reset for switching DDC
> > + * bus from device detection to EDID read, rather than setting
> > + * up HAS_DEVICE bit here, we need to do that in .get_modes
> > + * hook for unplug detecting after EDID read succeeds.
> > + */
> > + vga->connected = true;
> > + return IRQ_WAKE_THREAD;
> > + }
> > +
> > + if (status & VGA_DEVICE_DISCONNECTED) {
> > + spin_lock(&vga->lock);
> > + zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL,
> > + VGA_DETECT_SEL_NO_DEVICE);
> > + spin_unlock(&vga->lock);
>
> I think you still have the race here. If you get a disconnect between get_edid
> successfully finishing, and resetting the DETECT_SEL register, you will end up
> with the device being disconnected and DETECT_SEL == VGA_DETECT_SEL_HAS_DEVICE.
>
> In order to close this, you'll need to hold the lock across the edid read.
We cannot hold a spin lock across the EDID read procedure, which does
sleep.
When you suggested to have a lock for DETECT_SEL register access, I
thought we are accessing it in a read-modify-write way and thus agreed
to add a lock. However, I just found that it's not the case actually.
All the accesses to the register are single direct write.
And here is my understanding about the condition you described above.
Once DETECT_SEL register gets reset (both bits cleared), the hardware
switches DDC bus for EDID read, and hotplug detection will stop working
right away (this is how ZTE hardware works). That said, if we get a
disconnect before drm_get_edid() successfully finishes, two points:
- The irq handler will not be triggered, so it will not get a chance to
update DETECT_SEL register.
- The drm_get_edid() fails, and .get_modes returns with both detect bits
kept cleared.
I think what we can do better in this case is that we should set the
device state into disconnected, before returning from .get_modes,
something like the code below. But still, I do not see we need a lock
for that.
Shawn
static int zx_vga_connector_get_modes(struct drm_connector *connector)
{
struct zx_vga *vga = to_zx_vga(connector);
unsigned long flags;
struct edid *edid;
int ret;
/*
* Clear both detection bits to switch I2C bus from device
* detecting to EDID reading.
*/
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
edid = drm_get_edid(connector, &vga->ddc->adap);
if (!edid) {
/*
* If EDID reading fails, we set the device state into
* disconnected.
*/
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL,
VGA_DETECT_SEL_NO_DEVICE);
vga->connected = false;
return 0;
}
/*
* As edid reading succeeds, device must be connected, so we set
* up detection bit for unplug interrupt here.
*/
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, VGA_DETECT_SEL_HAS_DEVICE);
drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
kfree(edid);
return ret;
}
--
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
* Device Tree Binding for Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong @ 2017-04-07 2:13 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hi Rob,
I am resubmitting the patch again since the last doesn't comply with
the rules of the community.
>From 23a9e274bb517b8e232c5aa4cf9737de1644b708 Mon Sep 17 00:00:00 2001
From: Ong, Hean Loong <hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date: Thu, 30 Mar 2017 17:59:37 +0800
Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite device
tree binding
Device tree binding for Intel FPGA Video and Image
Processing Suite. The binding involved would be generated
from the Altera (Intel) Qsys system. The bindings would
set the max width, max height, buts per pixel and memory
port width. The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as
altr.
Signed-off-by: Ong, Hean Loong <hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
.../devicetree/bindings/gpu/altr,vip-fb2.txt | 24
++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpu/altr,vip-
fb2.txt
diff --git a/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
new file mode 100644
index 0000000..9ba3209
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
@@ -0,0 +1,24 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Arria 10 and above with display port IP
+
+Required properties:
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer
controller's
+ registers.
+- max-width: The width of the framebuffer in pixels.
+- max-height: The height of the framebuffer in pixels.
+- bits-per-symbol: only "8" is currently supported
+- mem-port-width = the bus width of the avalon master port on the
frame reader
+
+Example:
+
+dp_0_frame_buf: vip@0x100000280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x00000001 0x00000280 0x00000040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,bits-per-symbol = <8>;
+ altr,mem-port-width = <128>;
+};
+
--
1.7.1
--
BR
Hean-Loong
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] ARM: dts: aspeed: add a fastread property
From: Joel Stanley @ 2017-04-07 2:10 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
In-Reply-To: <1491498153-26564-1-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Fri, Apr 7, 2017 at 2:32 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> All chips on OpenPOWER platforms support the fastread SPI command.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
Thanks, applied.
Cheers,
Joel
> ---
> arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 ++
> arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 2 ++
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 2 ++
> 3 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-ast2500-evb.dts b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> index 8f82e8ab1875..7c90dac99822 100644
> --- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> +++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> @@ -24,6 +24,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "bmc";
> };
> };
> @@ -32,6 +33,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "pnor";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> index aab1889f702f..112551766275 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> @@ -35,6 +35,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "bmc";
> };
> };
> @@ -43,6 +44,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "pnor";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index e3c6358bc7d9..b82f67eb3dae 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -35,6 +35,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "bmc";
> };
> };
> @@ -43,6 +44,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "pnor";
> };
> };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 5/5] arm64: dts: hisi: enalbe the NIC and SAS for the hip07-d05 board
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, arnd
Cc: wangkefeng.wang, gabriele.paoloni, charles.chenxin, linuxarm,
guohanjun, yankejian, yimin, xuwei5, huangdaode, liudongdong3,
yisen.zhuang, devicetree, john.garry, tanxiaofei, lipeng321,
linux-arm-kernel, salil.mehta, chenxiang66, linux-kernel,
shameerali.kolothum.thodi, wangzhou1, liguozhu, majun258
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5@hisilicon.com>
From: Wei Xu <xuwei5@hisilicon.com>
Enalbe the NIC and SAS nodes for the hip07-d05 board
to support related functions.
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07-d05.dts b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
index e058442..5bdca80 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
@@ -64,3 +64,27 @@
&usb_ehci {
status = "ok";
};
+
+ð0 {
+ status = "ok";
+};
+
+ð1 {
+ status = "ok";
+};
+
+ð2 {
+ status = "ok";
+};
+
+ð3 {
+ status = "ok";
+};
+
+&p0_pcie2_a {
+ status = "ok";
+};
+
+&sas1 {
+ status = "ok";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: hisi: add SAS nodes for the hip07 SoC
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, arnd
Cc: wangkefeng.wang, gabriele.paoloni, charles.chenxin, linuxarm,
guohanjun, yankejian, yimin, xuwei5, huangdaode, liudongdong3,
yisen.zhuang, devicetree, john.garry, tanxiaofei, lipeng321,
linux-arm-kernel, salil.mehta, chenxiang66, linux-kernel,
shameerali.kolothum.thodi, wangzhou1, liguozhu, majun258
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5@hisilicon.com>
From: Wei Xu <xuwei5@hisilicon.com>
Add 3 SAS host controller nodes and the dependent subctrl node
to enable the SAS and SATA function for the hip07 SoC.
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 129 +++++++++++++++++++++++++++++++
1 file changed, 129 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index bc54b61..9512f3a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1127,6 +1127,11 @@
reg = <0x0 0xc0000000 0x0 0x10000>;
};
+ pcie_subctl: pcie_subctl@a0000000 {
+ compatible = "hisilicon,pcie-sas-subctrl", "syscon";
+ reg = <0x0 0xa0000000 0x0 0x10000>;
+ };
+
serdes_ctrl: sds_ctrl@c2200000 {
compatible = "syscon";
reg = <0 0xc2200000 0x0 0x80000>;
@@ -1405,5 +1410,129 @@
"hns-roce-async",
"hns-roce-common";
};
+
+ sas0: sas@c3000000 {
+ compatible = "hisilicon,hip07-sas-v2";
+ reg = <0 0xc3000000 0 0x10000>;
+ sas-addr = [50 01 88 20 16 00 00 00];
+ hisilicon,sas-syscon = <&dsa_subctrl>;
+ ctrl-reset-reg = <0xa60>;
+ ctrl-reset-sts-reg = <0x5a30>;
+ ctrl-clock-ena-reg = <0x338>;
+ queue-count = <16>;
+ phy-count = <8>;
+ dma-coherent;
+ interrupt-parent = <&mbigen_sas0>;
+ interrupts = <64 4>,<65 4>,<66 4>,<67 4>,<68 4>,
+ <69 4>,<70 4>,<71 4>,<72 4>,<73 4>,
+ <74 4>,<75 4>,<76 4>,<77 4>,<78 4>,
+ <79 4>,<80 4>,<81 4>,<82 4>,<83 4>,
+ <84 4>,<85 4>,<86 4>,<87 4>,<88 4>,
+ <89 4>,<90 4>,<91 4>,<92 4>,<93 4>,
+ <94 4>,<95 4>,<96 4>,<97 4>,<98 4>,
+ <99 4>,<100 4>,<101 4>,<102 4>,<103 4>,
+ <104 4>,<105 4>,<106 4>,<107 4>,<108 4>,
+ <109 4>,<110 4>,<111 4>,<112 4>,<113 4>,
+ <114 4>,<115 4>,<116 4>,<117 4>,<118 4>,
+ <119 4>,<120 4>,<121 4>,<122 4>,<123 4>,
+ <124 4>,<125 4>,<126 4>,<127 4>,<128 4>,
+ <129 4>,<130 4>,<131 4>,<132 4>,<133 4>,
+ <134 4>,<135 4>,<136 4>,<137 4>,<138 4>,
+ <139 4>,<140 4>,<141 4>,<142 4>,<143 4>,
+ <144 4>,<145 4>,<146 4>,<147 4>,<148 4>,
+ <149 4>,<150 4>,<151 4>,<152 4>,<153 4>,
+ <154 4>,<155 4>,<156 4>,<157 4>,<158 4>,
+ <159 4>,<601 1>,<602 1>,<603 1>,<604 1>,
+ <605 1>,<606 1>,<607 1>,<608 1>,<609 1>,
+ <610 1>,<611 1>,<612 1>,<613 1>,<614 1>,
+ <615 1>,<616 1>,<617 1>,<618 1>,<619 1>,
+ <620 1>,<621 1>,<622 1>,<623 1>,<624 1>,
+ <625 1>,<626 1>,<627 1>,<628 1>,<629 1>,
+ <630 1>,<631 1>,<632 1>;
+ status = "disabled";
+ };
+
+ sas1: sas@a2000000 {
+ compatible = "hisilicon,hip07-sas-v2";
+ reg = <0 0xa2000000 0 0x10000>;
+ sas-addr = [50 01 88 20 16 00 00 00];
+ hisilicon,sas-syscon = <&pcie_subctl>;
+ hip06-sas-v2-quirk-amt;
+ ctrl-reset-reg = <0xa18>;
+ ctrl-reset-sts-reg = <0x5a0c>;
+ ctrl-clock-ena-reg = <0x318>;
+ queue-count = <16>;
+ phy-count = <8>;
+ dma-coherent;
+ interrupt-parent = <&mbigen_sas1>;
+ interrupts = <64 4>,<65 4>,<66 4>,<67 4>,<68 4>,
+ <69 4>,<70 4>,<71 4>,<72 4>,<73 4>,
+ <74 4>,<75 4>,<76 4>,<77 4>,<78 4>,
+ <79 4>,<80 4>,<81 4>,<82 4>,<83 4>,
+ <84 4>,<85 4>,<86 4>,<87 4>,<88 4>,
+ <89 4>,<90 4>,<91 4>,<92 4>,<93 4>,
+ <94 4>,<95 4>,<96 4>,<97 4>,<98 4>,
+ <99 4>,<100 4>,<101 4>,<102 4>,<103 4>,
+ <104 4>,<105 4>,<106 4>,<107 4>,<108 4>,
+ <109 4>,<110 4>,<111 4>,<112 4>,<113 4>,
+ <114 4>,<115 4>,<116 4>,<117 4>,<118 4>,
+ <119 4>,<120 4>,<121 4>,<122 4>,<123 4>,
+ <124 4>,<125 4>,<126 4>,<127 4>,<128 4>,
+ <129 4>,<130 4>,<131 4>,<132 4>,<133 4>,
+ <134 4>,<135 4>,<136 4>,<137 4>,<138 4>,
+ <139 4>,<140 4>,<141 4>,<142 4>,<143 4>,
+ <144 4>,<145 4>,<146 4>,<147 4>,<148 4>,
+ <149 4>,<150 4>,<151 4>,<152 4>,<153 4>,
+ <154 4>,<155 4>,<156 4>,<157 4>,<158 4>,
+ <159 4>,<576 1>,<577 1>,<578 1>,<579 1>,
+ <580 1>,<581 1>,<582 1>,<583 1>,<584 1>,
+ <585 1>,<586 1>,<587 1>,<588 1>,<589 1>,
+ <590 1>,<591 1>,<592 1>,<593 1>,<594 1>,
+ <595 1>,<596 1>,<597 1>,<598 1>,<599 1>,
+ <600 1>,<601 1>,<602 1>,<603 1>,<604 1>,
+ <605 1>,<606 1>,<607 1>;
+ status = "disabled";
+ };
+
+ sas2: sas@a3000000 {
+ compatible = "hisilicon,hip07-sas-v2";
+ reg = <0 0xa3000000 0 0x10000>;
+ sas-addr = [50 01 88 20 16 00 00 00];
+ hisilicon,sas-syscon = <&pcie_subctl>;
+ ctrl-reset-reg = <0xae0>;
+ ctrl-reset-sts-reg = <0x5a70>;
+ ctrl-clock-ena-reg = <0x3a8>;
+ queue-count = <16>;
+ phy-count = <9>;
+ dma-coherent;
+ interrupt-parent = <&mbigen_sas2>;
+ interrupts = <192 4>,<193 4>,<194 4>,<195 4>,<196 4>,
+ <197 4>,<198 4>,<199 4>,<200 4>,<201 4>,
+ <202 4>,<203 4>,<204 4>,<205 4>,<206 4>,
+ <207 4>,<208 4>,<209 4>,<210 4>,<211 4>,
+ <212 4>,<213 4>,<214 4>,<215 4>,<216 4>,
+ <217 4>,<218 4>,<219 4>,<220 4>,<221 4>,
+ <222 4>,<223 4>,<224 4>,<225 4>,<226 4>,
+ <227 4>,<228 4>,<229 4>,<230 4>,<231 4>,
+ <232 4>,<233 4>,<234 4>,<235 4>,<236 4>,
+ <237 4>,<238 4>,<239 4>,<240 4>,<241 4>,
+ <242 4>,<243 4>,<244 4>,<245 4>,<246 4>,
+ <247 4>,<248 4>,<249 4>,<250 4>,<251 4>,
+ <252 4>,<253 4>,<254 4>,<255 4>,<256 4>,
+ <257 4>,<258 4>,<259 4>,<260 4>,<261 4>,
+ <262 4>,<263 4>,<264 4>,<265 4>,<266 4>,
+ <267 4>,<268 4>,<269 4>,<270 4>,<271 4>,
+ <272 4>,<273 4>,<274 4>,<275 4>,<276 4>,
+ <277 4>,<278 4>,<279 4>,<280 4>,<281 4>,
+ <282 4>,<283 4>,<284 4>,<285 4>,<286 4>,
+ <287 4>,<608 1>,<609 1>,<610 1>,<611 1>,
+ <612 1>,<613 1>,<614 1>,<615 1>,<616 1>,
+ <617 1>,<618 1>,<619 1>,<620 1>,<621 1>,
+ <622 1>,<623 1>,<624 1>,<625 1>,<626 1>,
+ <627 1>,<628 1>,<629 1>,<630 1>,<631 1>,
+ <632 1>,<633 1>,<634 1>,<635 1>,<636 1>,
+ <637 1>,<638 1>,<639 1>;
+ status = "disabled";
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: hisi: add RoCE nodes for the hip07 SoC
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
arnd-r2nGTMty4D4
Cc: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q,
liudongdong3-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA,
majun258-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
guohanjun-hv44wF8Li93QT0dZR+AlfA, linuxarm-hv44wF8Li93QT0dZR+AlfA,
liguozhu-C8/M+/jPZTeaMJb+Lgu22Q, yimin-hv44wF8Li93QT0dZR+AlfA,
chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaofei-hv44wF8Li93QT0dZR+AlfA,
lipeng321-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
huangdaode-C8/M+/jPZTeaMJb+Lgu22Q,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
From: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Add the infiniband node to support the RoCE function
on the hip07 SoC.
Signed-off-by: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 81 ++++++++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2feb362..bc54b61 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1324,5 +1324,86 @@
status = "disabled";
dma-coherent;
};
+
+ infiniband@c4000000 {
+ compatible = "hisilicon,hns-roce-v1";
+ reg = <0x0 0xc4000000 0x0 0x100000>;
+ dma-coherent;
+ eth-handle = <ð2 ð3 0 0 ð0 ð1>;
+ dsaf-handle = <&dsaf0>;
+ node-guid = [00 9A CD 00 00 01 02 03];
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mbigen_dsa_roce>;
+ interrupts = <722 1>,
+ <723 1>,
+ <724 1>,
+ <725 1>,
+ <726 1>,
+ <727 1>,
+ <728 1>,
+ <729 1>,
+ <730 1>,
+ <731 1>,
+ <732 1>,
+ <733 1>,
+ <734 1>,
+ <735 1>,
+ <736 1>,
+ <737 1>,
+ <738 1>,
+ <739 1>,
+ <740 1>,
+ <741 1>,
+ <742 1>,
+ <743 1>,
+ <744 1>,
+ <745 1>,
+ <746 1>,
+ <747 1>,
+ <748 1>,
+ <749 1>,
+ <750 1>,
+ <751 1>,
+ <752 1>,
+ <753 1>,
+ <785 1>,
+ <754 4>;
+
+ interrupt-names = "hns-roce-comp-0",
+ "hns-roce-comp-1",
+ "hns-roce-comp-2",
+ "hns-roce-comp-3",
+ "hns-roce-comp-4",
+ "hns-roce-comp-5",
+ "hns-roce-comp-6",
+ "hns-roce-comp-7",
+ "hns-roce-comp-8",
+ "hns-roce-comp-9",
+ "hns-roce-comp-10",
+ "hns-roce-comp-11",
+ "hns-roce-comp-12",
+ "hns-roce-comp-13",
+ "hns-roce-comp-14",
+ "hns-roce-comp-15",
+ "hns-roce-comp-16",
+ "hns-roce-comp-17",
+ "hns-roce-comp-18",
+ "hns-roce-comp-19",
+ "hns-roce-comp-20",
+ "hns-roce-comp-21",
+ "hns-roce-comp-22",
+ "hns-roce-comp-23",
+ "hns-roce-comp-24",
+ "hns-roce-comp-25",
+ "hns-roce-comp-26",
+ "hns-roce-comp-27",
+ "hns-roce-comp-28",
+ "hns-roce-comp-29",
+ "hns-roce-comp-30",
+ "hns-roce-comp-31",
+ "hns-roce-async",
+ "hns-roce-common";
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: hisi: add network related nodes for the hip07 SoC
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, arnd
Cc: wangkefeng.wang, gabriele.paoloni, charles.chenxin, linuxarm,
guohanjun, yankejian, yimin, xuwei5, huangdaode, liudongdong3,
yisen.zhuang, devicetree, john.garry, tanxiaofei, lipeng321,
linux-arm-kernel, salil.mehta, chenxiang66, linux-kernel,
shameerali.kolothum.thodi, wangzhou1, liguozhu, majun258
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5@hisilicon.com>
From: Wei Xu <xuwei5@hisilicon.com>
Add MDIO, SerDes, Port and realted HNS nodes to support the
network on the hip07 SoC.
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 208 +++++++++++++++++++++++++++++++
1 file changed, 208 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 6077def..2feb362 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1116,5 +1116,213 @@
dma-coherent;
status = "disabled";
};
+
+ peri_c_subctrl: sub_ctrl_c@60000000 {
+ compatible = "hisilicon,peri-subctrl","syscon";
+ reg = <0 0x60000000 0x0 0x10000>;
+ };
+
+ dsa_subctrl: dsa_subctrl@c0000000 {
+ compatible = "hisilicon,dsa-subctrl", "syscon";
+ reg = <0x0 0xc0000000 0x0 0x10000>;
+ };
+
+ serdes_ctrl: sds_ctrl@c2200000 {
+ compatible = "syscon";
+ reg = <0 0xc2200000 0x0 0x80000>;
+ };
+
+ mdio@603c0000 {
+ compatible = "hisilicon,hns-mdio";
+ reg = <0x0 0x603c0000 0x0 0x1000>;
+ subctrl-vbase = <&peri_c_subctrl 0x338 0xa38
+ 0x531c 0x5a1c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+
+ dsaf0: dsa@c7000000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "hisilicon,hns-dsaf-v2";
+ mode = "6port-16rss";
+ reg = <0x0 0xc5000000 0x0 0x890000
+ 0x0 0xc7000000 0x0 0x600000>;
+ reg-names = "ppe-base", "dsaf-base";
+ interrupt-parent = <&mbigen_dsaf0>;
+ subctrl-syscon = <&dsa_subctrl>;
+ reset-field-offset = <0>;
+ interrupts =
+ <576 1>, <577 1>, <578 1>, <579 1>, <580 1>,
+ <581 1>, <582 1>, <583 1>, <584 1>, <585 1>,
+ <586 1>, <587 1>, <588 1>, <589 1>, <590 1>,
+ <591 1>, <592 1>, <593 1>, <594 1>, <595 1>,
+ <596 1>, <597 1>, <598 1>, <599 1>, <600 1>,
+ <960 1>, <961 1>, <962 1>, <963 1>, <964 1>,
+ <965 1>, <966 1>, <967 1>, <968 1>, <969 1>,
+ <970 1>, <971 1>, <972 1>, <973 1>, <974 1>,
+ <975 1>, <976 1>, <977 1>, <978 1>, <979 1>,
+ <980 1>, <981 1>, <982 1>, <983 1>, <984 1>,
+ <985 1>, <986 1>, <987 1>, <988 1>, <989 1>,
+ <990 1>, <991 1>, <992 1>, <993 1>, <994 1>,
+ <995 1>, <996 1>, <997 1>, <998 1>, <999 1>,
+ <1000 1>, <1001 1>, <1002 1>, <1003 1>, <1004 1>,
+ <1005 1>, <1006 1>, <1007 1>, <1008 1>, <1009 1>,
+ <1010 1>, <1011 1>, <1012 1>, <1013 1>, <1014 1>,
+ <1015 1>, <1016 1>, <1017 1>, <1018 1>, <1019 1>,
+ <1020 1>, <1021 1>, <1022 1>, <1023 1>, <1024 1>,
+ <1025 1>, <1026 1>, <1027 1>, <1028 1>, <1029 1>,
+ <1030 1>, <1031 1>, <1032 1>, <1033 1>, <1034 1>,
+ <1035 1>, <1036 1>, <1037 1>, <1038 1>, <1039 1>,
+ <1040 1>, <1041 1>, <1042 1>, <1043 1>, <1044 1>,
+ <1045 1>, <1046 1>, <1047 1>, <1048 1>, <1049 1>,
+ <1050 1>, <1051 1>, <1052 1>, <1053 1>, <1054 1>,
+ <1055 1>, <1056 1>, <1057 1>, <1058 1>, <1059 1>,
+ <1060 1>, <1061 1>, <1062 1>, <1063 1>, <1064 1>,
+ <1065 1>, <1066 1>, <1067 1>, <1068 1>, <1069 1>,
+ <1070 1>, <1071 1>, <1072 1>, <1073 1>, <1074 1>,
+ <1075 1>, <1076 1>, <1077 1>, <1078 1>, <1079 1>,
+ <1080 1>, <1081 1>, <1082 1>, <1083 1>, <1084 1>,
+ <1085 1>, <1086 1>, <1087 1>, <1088 1>, <1089 1>,
+ <1090 1>, <1091 1>, <1092 1>, <1093 1>, <1094 1>,
+ <1095 1>, <1096 1>, <1097 1>, <1098 1>, <1099 1>,
+ <1100 1>, <1101 1>, <1102 1>, <1103 1>, <1104 1>,
+ <1105 1>, <1106 1>, <1107 1>, <1108 1>, <1109 1>,
+ <1110 1>, <1111 1>, <1112 1>, <1113 1>, <1114 1>,
+ <1115 1>, <1116 1>, <1117 1>, <1118 1>, <1119 1>,
+ <1120 1>, <1121 1>, <1122 1>, <1123 1>, <1124 1>,
+ <1125 1>, <1126 1>, <1127 1>, <1128 1>, <1129 1>,
+ <1130 1>, <1131 1>, <1132 1>, <1133 1>, <1134 1>,
+ <1135 1>, <1136 1>, <1137 1>, <1138 1>, <1139 1>,
+ <1140 1>, <1141 1>, <1142 1>, <1143 1>, <1144 1>,
+ <1145 1>, <1146 1>, <1147 1>, <1148 1>, <1149 1>,
+ <1150 1>, <1151 1>, <1152 1>, <1153 1>, <1154 1>,
+ <1155 1>, <1156 1>, <1157 1>, <1158 1>, <1159 1>,
+ <1160 1>, <1161 1>, <1162 1>, <1163 1>, <1164 1>,
+ <1165 1>, <1166 1>, <1167 1>, <1168 1>, <1169 1>,
+ <1170 1>, <1171 1>, <1172 1>, <1173 1>, <1174 1>,
+ <1175 1>, <1176 1>, <1177 1>, <1178 1>, <1179 1>,
+ <1180 1>, <1181 1>, <1182 1>, <1183 1>, <1184 1>,
+ <1185 1>, <1186 1>, <1187 1>, <1188 1>, <1189 1>,
+ <1190 1>, <1191 1>, <1192 1>, <1193 1>, <1194 1>,
+ <1195 1>, <1196 1>, <1197 1>, <1198 1>, <1199 1>,
+ <1200 1>, <1201 1>, <1202 1>, <1203 1>, <1204 1>,
+ <1205 1>, <1206 1>, <1207 1>, <1208 1>, <1209 1>,
+ <1210 1>, <1211 1>, <1212 1>, <1213 1>, <1214 1>,
+ <1215 1>, <1216 1>, <1217 1>, <1218 1>, <1219 1>,
+ <1220 1>, <1221 1>, <1222 1>, <1223 1>, <1224 1>,
+ <1225 1>, <1226 1>, <1227 1>, <1228 1>, <1229 1>,
+ <1230 1>, <1231 1>, <1232 1>, <1233 1>, <1234 1>,
+ <1235 1>, <1236 1>, <1237 1>, <1238 1>, <1239 1>,
+ <1240 1>, <1241 1>, <1242 1>, <1243 1>, <1244 1>,
+ <1245 1>, <1246 1>, <1247 1>, <1248 1>, <1249 1>,
+ <1250 1>, <1251 1>, <1252 1>, <1253 1>, <1254 1>,
+ <1255 1>, <1256 1>, <1257 1>, <1258 1>, <1259 1>,
+ <1260 1>, <1261 1>, <1262 1>, <1263 1>, <1264 1>,
+ <1265 1>, <1266 1>, <1267 1>, <1268 1>, <1269 1>,
+ <1270 1>, <1271 1>, <1272 1>, <1273 1>, <1274 1>,
+ <1275 1>, <1276 1>, <1277 1>, <1278 1>, <1279 1>,
+ <1280 1>, <1281 1>, <1282 1>, <1283 1>, <1284 1>,
+ <1285 1>, <1286 1>, <1287 1>, <1288 1>, <1289 1>,
+ <1290 1>, <1291 1>, <1292 1>, <1293 1>, <1294 1>,
+ <1295 1>, <1296 1>, <1297 1>, <1298 1>, <1299 1>,
+ <1300 1>, <1301 1>, <1302 1>, <1303 1>, <1304 1>,
+ <1305 1>, <1306 1>, <1307 1>, <1308 1>, <1309 1>,
+ <1310 1>, <1311 1>, <1312 1>, <1313 1>, <1314 1>,
+ <1315 1>, <1316 1>, <1317 1>, <1318 1>, <1319 1>,
+ <1320 1>, <1321 1>, <1322 1>, <1323 1>, <1324 1>,
+ <1325 1>, <1326 1>, <1327 1>, <1328 1>, <1329 1>,
+ <1330 1>, <1331 1>, <1332 1>, <1333 1>, <1334 1>,
+ <1335 1>, <1336 1>, <1337 1>, <1338 1>, <1339 1>,
+ <1340 1>, <1341 1>, <1342 1>, <1343 1>;
+
+ desc-num = <0x400>;
+ buf-size = <0x1000>;
+ dma-coherent;
+
+ port@0 {
+ reg = <0>;
+ serdes-syscon = <&serdes_ctrl>;
+ port-rst-offset = <0>;
+ port-mode-offset = <0>;
+ mc-mac-mask = [ff f0 00 00 00 00];
+ media-type = "fiber";
+ };
+
+ port@1 {
+ reg = <1>;
+ serdes-syscon= <&serdes_ctrl>;
+ port-rst-offset = <1>;
+ port-mode-offset = <1>;
+ mc-mac-mask = [ff f0 00 00 00 00];
+ media-type = "fiber";
+ };
+
+ port@4 {
+ reg = <4>;
+ phy-handle = <&phy0>;
+ serdes-syscon= <&serdes_ctrl>;
+ port-rst-offset = <4>;
+ port-mode-offset = <2>;
+ mc-mac-mask = [ff f0 00 00 00 00];
+ media-type = "copper";
+ };
+
+ port@5 {
+ reg = <5>;
+ phy-handle = <&phy1>;
+ serdes-syscon= <&serdes_ctrl>;
+ port-rst-offset = <5>;
+ port-mode-offset = <3>;
+ mc-mac-mask = [ff f0 00 00 00 00];
+ media-type = "copper";
+ };
+ };
+
+ eth0: ethernet@4{
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <4>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth1: ethernet@5{
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <5>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth2: ethernet@0{
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <0>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth3: ethernet@1{
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <1>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/5] arm64: dts: hisi: add mbigen nodes for the hip07 SoC
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
arnd-r2nGTMty4D4
Cc: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q,
liudongdong3-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA,
majun258-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
guohanjun-hv44wF8Li93QT0dZR+AlfA, linuxarm-hv44wF8Li93QT0dZR+AlfA,
liguozhu-C8/M+/jPZTeaMJb+Lgu22Q, yimin-hv44wF8Li93QT0dZR+AlfA,
chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaofei-hv44wF8Li93QT0dZR+AlfA,
lipeng321-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
huangdaode-C8/M+/jPZTeaMJb+Lgu22Q,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
From: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Add mbigen nodes for the hip07 SoC those will be used
for the SAS, XGE and PCIe host controllers.
Signed-off-by: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 61 ++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 5144eb1..6077def 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1014,6 +1014,34 @@
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xa0080000 0x0 0x10000>;
+ mbigen_pcie2_a: intc_pcie2_a {
+ msi-parent = <&p0_its_dsa_a 0x40087>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <10>;
+ };
+
+ mbigen_sas1: intc_sas1 {
+ msi-parent = <&p0_its_dsa_a 0x40000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <128>;
+ };
+
+ mbigen_sas2: intc_sas2 {
+ msi-parent = <&p0_its_dsa_a 0x40040>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <128>;
+ };
+
+ mbigen_smmu_pcie: intc_smmu_pcie {
+ msi-parent = <&p0_its_dsa_a 0x40b0c>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <3>;
+ };
+
mbigen_usb: intc_usb {
msi-parent = <&p0_its_dsa_a 0x40080>;
interrupt-controller;
@@ -1022,6 +1050,39 @@
};
};
+ p0_mbigen_dsa_a: interrupt-controller@c0080000 {
+ compatible = "hisilicon,mbigen-v2";
+ reg = <0x0 0xc0080000 0x0 0x10000>;
+
+ mbigen_dsaf0: intc_dsaf0 {
+ msi-parent = <&p0_its_dsa_a 0x40800>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <409>;
+ };
+
+ mbigen_dsa_roce: intc-roce {
+ msi-parent = <&p0_its_dsa_a 0x40B1E>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <34>;
+ };
+
+ mbigen_sas0: intc-sas0 {
+ msi-parent = <&p0_its_dsa_a 0x40900>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <128>;
+ };
+
+ mbigen_smmu_dsa: intc_smmu_dsa {
+ msi-parent = <&p0_its_dsa_a 0x40b20>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <3>;
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/5] arm64: dts: hisi: add NIC, RoCE and SAS support for hip07
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
arnd-r2nGTMty4D4
Cc: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q,
liudongdong3-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA,
majun258-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
guohanjun-hv44wF8Li93QT0dZR+AlfA, linuxarm-hv44wF8Li93QT0dZR+AlfA,
liguozhu-C8/M+/jPZTeaMJb+Lgu22Q, yimin-hv44wF8Li93QT0dZR+AlfA,
chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaofei-hv44wF8Li93QT0dZR+AlfA,
lipeng321-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
huangdaode-C8/M+/jPZTeaMJb+Lgu22Q,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
This patch series adds Mbigen, NIC, RoCE and SAS nodes for the hip07
SoC and enables the NIC, RoCE and SAS on the hip07 d05 board.
Wei Xu (5):
arm64: dts: hisi: add mbigen nodes for the hip07 SoC
arm64: dts: hisi: add network related nodes for the hip07 SoC
arm64: dts: hisi: add RoCE nodes for the hip07 SoC
arm64: dts: hisi: add SAS nodes for the hip07 SoC
arm64: dts: hisi: enalbe the NIC and SAS for the hip07-d05 board
arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 24 ++
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 479 ++++++++++++++++++++++++++++
2 files changed, 503 insertions(+)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: aspeed: add SPI controller bindings to Romulus
From: Joel Stanley @ 2017-04-07 1:50 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
In-Reply-To: <1490198683-5796-1-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Thu, Mar 23, 2017 at 2:34 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> Romulus systems have one MX25L25635 (32768 Kbytes) flash module for
> the BMC firmware and other MT25QL512A (65536 Kbytes) for the host.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
Thanks, applied.
Cheers,
Joel
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index 7a3b2b50c884..e3c6358bc7d9 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -31,6 +31,26 @@
> };
> };
>
> +&fmc {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + label = "bmc";
> + };
> +};
> +
> +&spi1 {
> + status = "okay";
> + flash@0 {
> + status = "okay";
> + label = "pnor";
> + };
> +};
> +
> +&spi2 {
> + status = "okay";
> +};
> +
> &uart5 {
> status = "okay";
> };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] mtd: spi-nor: add driver for STM32 quad spi flash controller
From: Marek Vasut @ 2017-04-06 23:55 UTC (permalink / raw)
To: Ludovic Barre, Cyrille Pitchen
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Alexandre Torgue, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490979724-10905-3-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>
On 03/31/2017 07:02 PM, Ludovic Barre wrote:
> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>
> The quadspi is a specialized communication interface targeting single,
> dual or quad SPI Flash memories.
>
> It can operate in any of the following modes:
> -indirect mode: all the operations are performed using the quadspi
> registers
> -read memory-mapped mode: the external Flash memory is mapped to the
> microcontroller address space and is seen by the system as if it was
> an internal memory
>
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/mtd/spi-nor/Kconfig | 7 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/stm32-quadspi.c | 690 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 698 insertions(+)
> create mode 100644 drivers/mtd/spi-nor/stm32-quadspi.c
>
[...]
> +struct stm32_qspi_flash {
> + struct spi_nor nor;
> + u32 cs;
> + u32 fsize;
> + u32 presc;
> + struct stm32_qspi *qspi;
> +};
[...]
> +struct stm32_qspi_cmd {
> + struct {
> + u8 addr_width;
> + u8 dummy;
> + u8 data;
> + } conf;
Is there any benefit in having this structure here or could you just
make the struct stm32_qspi_cmd flat ?
> + u8 opcode;
> + u32 framemode;
> + u32 qspimode;
> + u32 addr;
> + size_t len;
> + void *buf;
> +};
[...]
> +static ssize_t stm32_qspi_read(struct spi_nor *nor, loff_t from, size_t len,
> + u_char *buf)
> +{
> + struct stm32_qspi_flash *flash = nor->priv;
> + struct stm32_qspi *qspi = flash->qspi;
> + struct stm32_qspi_cmd cmd;
> + int err;
> +
> + dev_dbg(qspi->dev, "read(%#.2x): buf:%p from:%#.8x len:%#x\n",
> + nor->read_opcode, buf, (u32)from, len);
> +
> + memset(&cmd, 0, sizeof(cmd));
> + cmd.opcode = nor->read_opcode;
> + cmd.conf.addr_width = nor->addr_width;
> + cmd.addr = (u32)from;
loff_t (from) can be 64bit ... how do we handle this ?
> + cmd.conf.data = 1;
> + cmd.conf.dummy = nor->read_dummy;
> + cmd.len = len;
> + cmd.buf = buf;
> + cmd.qspimode = qspi->read_mode;
> +
> + stm32_qspi_set_framemode(nor, &cmd, true);
> + err = stm32_qspi_send(flash, &cmd);
> +
> + return err ? err : len;
> +}
[...]
> +static irqreturn_t stm32_qspi_irq(int irq, void *dev_id)
> +{
> + struct stm32_qspi *qspi = (struct stm32_qspi *)dev_id;
> + u32 cr, sr, fcr = 0;
> +
> + cr = readl_relaxed(qspi->io_base + QUADSPI_CR);
> + sr = readl_relaxed(qspi->io_base + QUADSPI_SR);
> +
> + if ((cr & CR_TCIE) && (sr & SR_TCF)) {
> + /* tx complete */
> + fcr |= FCR_CTCF;
> + complete(&qspi->cmd_completion);
> + } else {
> + dev_info(qspi->dev, "spurious interrupt\n");
You probably want to ratelimit this one ...
> + }
> +
> + writel_relaxed(fcr, qspi->io_base + QUADSPI_FCR);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int stm32_qspi_prep(struct spi_nor *nor, enum spi_nor_ops ops)
> +{
> + struct stm32_qspi_flash *flash = nor->priv;
> + struct stm32_qspi *qspi = flash->qspi;
> +
> + mutex_lock(&qspi->lock);
> + return 0;
> +}
> +
> +static void stm32_qspi_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
> +{
> + struct stm32_qspi_flash *flash = nor->priv;
> + struct stm32_qspi *qspi = flash->qspi;
> +
> + mutex_unlock(&qspi->lock);
> +}
> +
> +static int stm32_qspi_flash_setup(struct stm32_qspi *qspi,
> + struct device_node *np)
> +{
> + u32 width, flash_read, presc, cs_num, max_rate = 0;
> + struct stm32_qspi_flash *flash;
> + struct mtd_info *mtd;
> + int ret;
> +
> + of_property_read_u32(np, "reg", &cs_num);
> + if (cs_num >= STM32_MAX_NORCHIP)
> + return -EINVAL;
> +
> + of_property_read_u32(np, "spi-max-frequency", &max_rate);
> + if (!max_rate)
> + return -EINVAL;
> +
> + presc = DIV_ROUND_UP(qspi->clk_rate, max_rate) - 1;
> +
> + if (of_property_read_u32(np, "spi-rx-bus-width", &width))
> + width = 1;
> +
> + if (width == 4)
> + flash_read = SPI_NOR_QUAD;
> + else if (width == 2)
> + flash_read = SPI_NOR_DUAL;
> + else if (width == 1)
> + flash_read = SPI_NOR_NORMAL;
> + else
> + return -EINVAL;
> +
> + flash = &qspi->flash[cs_num];
> + flash->qspi = qspi;
> + flash->cs = cs_num;
> + flash->presc = presc;
> +
> + flash->nor.dev = qspi->dev;
> + spi_nor_set_flash_node(&flash->nor, np);
> + flash->nor.priv = flash;
> + mtd = &flash->nor.mtd;
> + mtd->priv = &flash->nor;
> +
> + flash->nor.read = stm32_qspi_read;
> + flash->nor.write = stm32_qspi_write;
> + flash->nor.erase = stm32_qspi_erase;
> + flash->nor.read_reg = stm32_qspi_read_reg;
> + flash->nor.write_reg = stm32_qspi_write_reg;
> + flash->nor.prepare = stm32_qspi_prep;
> + flash->nor.unprepare = stm32_qspi_unprep;
> +
> + writel_relaxed(LPTR_DFT_TIMEOUT, qspi->io_base + QUADSPI_LPTR);
> +
> + writel_relaxed(CR_PRESC(presc) | CR_FTHRES(3) | CR_TCEN | CR_SSHIFT
> + | CR_EN, qspi->io_base + QUADSPI_CR);
> +
> + /*
> + * in stm32 qspi controller, QUADSPI_DCR register has a fsize field
> + * which define the size of nor flash.
> + * if fsize is NULL, the controller can't sent spi-nor command.
> + * set a temporary value just to discover the nor flash with
> + * "spi_nor_scan". After, the right value (mtd->size) can be set.
> + */
Is 25 the smallest value ? Use a macro for this ...
> + flash->fsize = 25;
> +
> + ret = spi_nor_scan(&flash->nor, NULL, flash_read);
> + if (ret) {
> + dev_err(qspi->dev, "device scan failed\n");
> + return ret;
> + }
> +
> + /* number of bytes in Flash memory = 2^[FSIZE+1] */
> + flash->fsize = __fls(mtd->size) - 1;
> +
> + writel_relaxed(DCR_CSHT(1), qspi->io_base + QUADSPI_DCR);
> +
> + ret = mtd_device_register(mtd, NULL, 0);
> + if (ret) {
> + dev_err(qspi->dev, "mtd device parse failed\n");
> + return ret;
> + }
> +
> + dev_dbg(qspi->dev, "read mm:%s cs:%d bus:%d\n",
> + qspi->read_mode == CCR_FMODE_MM ? "yes" : "no", cs_num, width);
> +
> + return 0;
> +}
[...]
--
Best regards,
Marek Vasut
--
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 v6 19/39] media: Add i.MX media core driver
From: Steve Longerbeam @ 2017-04-06 23:51 UTC (permalink / raw)
To: Philipp Zabel
Cc: robh+dt, mark.rutland, shawnguo, kernel, fabio.estevam, linux,
mchehab, hverkuil, nick, markus.heiser, laurent.pinchart+renesas,
bparrot, geert, arnd, sudipm.mukherjee, minghsiu.tsai,
tiffany.lin, jean-christophe.trotin, horms+renesas,
niklas.soderlund+renesas, robert.jarzmik, songjun.wu,
andrew-ct.chen, gregkh, shuah, sakari.ailus, pavel, devicetree,
linux-kernel, linux-arm-kernel, linux-media
In-Reply-To: <1491471814.2392.11.camel@pengutronix.de>
On 04/06/2017 02:43 AM, Philipp Zabel wrote:
> On Mon, 2017-03-27 at 17:40 -0700, Steve Longerbeam wrote:
>> Add the core media driver for i.MX SOC.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> [...]
>> diff --git a/drivers/staging/media/imx/imx-media-of.c b/drivers/staging/media/imx/imx-media-of.c
>> new file mode 100644
>> index 0000000..b383be4
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-media-of.c
>> @@ -0,0 +1,267 @@
> [...]
>> +/*
>> + * find the remote device node and remote port id (remote pad #)
>> + * given local endpoint node
>> + */
>> +static void of_get_remote_pad(struct device_node *epnode,
>> + struct device_node **remote_node,
>> + int *remote_pad)
>> +{
>> + struct device_node *rp, *rpp;
>> + struct device_node *remote;
>> +
>> + rp = of_graph_get_remote_port(epnode);
>> + rpp = of_graph_get_remote_port_parent(epnode);
>> +
>> + if (of_device_is_compatible(rpp, "fsl,imx6q-ipu")) {
>> + /* the remote is one of the CSI ports */
>> + remote = rp;
>> + *remote_pad = 0;
>> + of_node_put(rpp);
>> + } else {
>> + remote = rpp;
>> + of_property_read_u32(rp, "reg", remote_pad);
>
> If this fails because there is no reg property, *remote_pad will keep
> the previous value. It should be set to 0 in this case.
Ok, I will apply this change.
Steve
>
> ----------8<----------
> --- a/drivers/staging/media/imx/imx-media-of.c
> +++ b/drivers/staging/media/imx/imx-media-of.c
> @@ -85,7 +85,9 @@ static void of_get_remote_pad(struct device_node *epnode,
> of_node_put(rpp);
> } else {
> remote = rpp;
> - of_property_read_u32(rp, "reg", remote_pad);
> + /* FIXME port number and pad index are not the same */
> + if (of_property_read_u32(rp, "reg", remote_pad))
> + *remote_pad = 0;
> of_node_put(rp);
> }
>
> ---------->8----------
>
> regards
> Philipp
>
^ permalink raw reply
* Re: [PATCH v3 07/12] clk: mediatek: add clk support for MT6797
From: Mars Cheng @ 2017-04-06 23:35 UTC (permalink / raw)
To: Stephen Boyd
Cc: Matthias Brugger, Rob Herring, Marc Zyngier, Michael Turquette,
CC Hwang, Loda Chou, Miles Chen, Jades Shih, Yingjoe Chen,
My Chuang, linux-kernel, linux-mediatek, devicetree, wsd_upstream,
linux-clk, Kevin-CW Chen
In-Reply-To: <20170406200852.GQ7065@codeaurora.org>
Hi Stephen
On Thu, 2017-04-06 at 13:08 -0700, Stephen Boyd wrote:
> On 03/19, Mars Cheng wrote:
> > From: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
> >
> > Add MT6797 clock support, include topckgen, apmixedsys, infracfg
> > and subsystem clocks
> >
> > Signed-off-by: Kevin-CW Chen <kevin-cw.chen@mediatek.com>
> > Signed-off-by: Mars Cheng <mars.cheng@mediatek.com>
> > Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
>
> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
>
> Looks fine to me except for the one comment below. Did you want
> me to merge it into clk tree?
To prevent another run, I really like you to merge it.
However, I also want to make the patch set more cleaner.
So I will send v4 later. :-)
>
> > diff --git a/drivers/clk/mediatek/clk-mt6797.c b/drivers/clk/mediatek/clk-mt6797.c
> > new file mode 100644
> > index 0000000..7ebb7f1
> > --- /dev/null
> > +++ b/drivers/clk/mediatek/clk-mt6797.c
> > @@ -0,0 +1,716 @@
> > +/*
> > + * Copyright (c) 2016 MediaTek Inc.
> > + * Author: Kevin Chen <kevin-cw.chen@mediatek.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/clk.h>
>
> Is this include used? Please include clk-provider if the file is
> a clk driver. Same comment applies to other files in this patch.
>
Should be removed. Will be done in v4.
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +
> > +#include "clk-mtk.h"
> > +#include "clk-gate.h"
> > +
> > +#include <dt-bindings/clock/mt6797-clk.h>
> > +
> > +/*
> > + * For some clocks, we don't care what their actual rates are. And these
> > + * clocks may change their rate on different products or different scenarios.
> > + * So we model these clocks' rate as 0, to denote it's not an actual rate.
> > + */
> > +
> > +static DEFINE_SPINLOCK(mt6797_clk_lock);
> > +
> > +static const struct mtk_fixed_factor top_fixed_divs[] = {
> > + FACTOR(CLK_TOP_SYSPLL_CK, "syspll_ck", "mainpll", 1, 1),
> > + FACTOR(CLK_TOP_SYSPLL_D2, "syspll_d2", "mainpll", 1, 2),
> > + FACTOR(CLK_TOP_SYSPLL1_D2, "syspll1_d2", "syspll_d2", 1, 2),
> [...]
> > + clk_init = of_device_get_match_data(&pdev->dev);
> > + if (!clk_init)
> > + return -EINVAL;
> > +
> > + r = clk_init(pdev);
> > + if (r)
> > + dev_err(&pdev->dev,
> > + "could not register clock provider: %s: %d\n",
> > + pdev->name, r);
> > +
> > + return r;
> > +}
> > +
> > +static struct platform_driver clk_mt6797_drv = {
> > + .probe = clk_mt6797_probe,
> > + .driver = {
> > + .name = "clk-mt6797",
> > + .owner = THIS_MODULE,
>
> This can be removed, platform_driver_register() does it already.
>
got it, will be removed.
> > + .of_match_table = of_match_clk_mt6797,
> > + },
> > +};
> > +
> > +static int __init clk_mt6797_init(void)
> > +{
> > + return platform_driver_register(&clk_mt6797_drv);
> > +}
> > +
> > +arch_initcall(clk_mt6797_init);
> > diff --git a/include/dt-bindings/clock/mt6797-clk.h b/include/dt-bindings/clock/mt6797-clk.h
> > new file mode 100644
> > index 0000000..e48aa47
> > --- /dev/null
> > +++ b/include/dt-bindings/clock/mt6797-clk.h
> > @@ -0,0 +1,281 @@
>
> I think arm-soc folks don't want us merging whole drivers into
> the DT branch anymore, so please split off the dt-bindings header
> into a different patch that we can apply directly. Then we can
> layer the driver on top and just send off the header to arm-soc
> via a stable clk branch.
>
Got it. Will be done in v4.
Thanks for your review.
^ permalink raw reply
* Re: [PATCH] of: change fixup of dma-ranges size to error
From: Rob Herring @ 2017-04-06 22:41 UTC (permalink / raw)
To: Frank Rowand
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <58E68ADC.6040603-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Apr 6, 2017 at 1:37 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 04/06/17 07:03, Rob Herring wrote:
>> On Thu, Apr 6, 2017 at 1:18 AM, <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>>>
>>> of_dma_get_range() has workaround code to fixup a device tree that
>>> incorrectly specified a mask instead of a size for property
>>> dma-ranges. That device tree was fixed a year ago in v4.6, so
>>> the workaround is no longer needed. Leave a data validation
>>> check in place, but no longer do the fixup. Move the check
>>> one level deeper in the call stack so that other possible users
>>> of dma-ranges will also be protected.
>>>
>>> The fix to the device tree was in
>>> commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree").
>>
>> NACK.
>> This was by design. You can't represent a size of 2^64 or 2^32.
>
> I agree that being unable to represent a size of 2^32 in a u32 and
> a size of 2^64 in a u64 is the underlying issue.
>
> But the code to convert a mask to a size is _not_ design, it is a
> hack that temporarily worked around a device tree that did not follow
> the dma-ranges binding in the ePAPR.
Since when is (2^64 - 1) not a size. It's a perfectly valid size in
DT. And there's probably not a system in the world that needs access
to that last byte. Is it completely accurate description if we
subtract off 1? No, but it is still a valid range (so would be
subtracting 12345).
> That device tree was corrected a year ago to provide a size instead of
> a mask.
You are letting Linux implementation details influence your DT
thinking. DT is much more flexible in that it supports a base address
and size (and multiple of them) while Linux can only deal with a
single address mask. If Linux dealt with base + size, then we wouldn't
be having this conversation. As long as Linux only deals with masks,
we're going to have to have some sort of work-around to deal with
them.
>> Well, technically you can for the latter, but then you have to grow
>> #size-cells to 2 for an otherwise all 32-bit system which seems kind
>> of pointless and wasteful. You could further restrict this to only
>> allow ~0 and not just any case with bit 0 set.
>>
>> I'm pretty sure AMD is not the only system. There were 32-bit systems too.
>
> I examined all instances of property dma-ranges in in tree dts files in
> Linux 4.11-rc1. There are none that incorrectly specify mask instead of
> size.
Okay, but there are ones for ranges at least. See ecx-2000.dts.
> #size-cells only changes to 2 for the dma-ranges property and the ranges
> property when size is 2^32, so that is a very small amount of space.
>
> The patch does not allow for a size of 2^64. If a system requires a
> size of 2^64 then the type of size needs to increase to be larger
> than a u64. If you would like for the code to be defensive and
> detect a device tree providing a size of 2^64 then I can add a
> check to of_dma_get_range() to return -EINVAL if #size-cells > 2.
> When that error triggers, the type of size can be changed.
#size-cells > 2 is completely broken for anything but PCI. I doubt it
is easily fixed without some special casing (i.e. a different hack)
until we have 128-bit support. I hope to retire before we need to
support that.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: rockchip: rock2: Setup usb vbus-supply
From: Heiko Stuebner @ 2017-04-06 22:23 UTC (permalink / raw)
To: Sjoerd Simons
Cc: John Youn, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170405140613.4444-3-sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Am Mittwoch, 5. April 2017, 16:06:11 CEST schrieb Sjoerd Simons:
> Now that the rockchip usb phy has a vbus-supply property use that to
> control the vbus regulator on rock2.
>
> Signed-off-by: Sjoerd Simons <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
I've queued this for 4.13 .
Not eligible for 4.12, as the patch alone (when testing my tree or armsoc)
would regress the sata-bridge, due to the regulator-always-on going away.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox