* Re: [PATCH RFC 24/24] drm/lima: add makefile and kconfig
From: Rob Herring @ 2018-05-23 17:26 UTC (permalink / raw)
To: Marek Vasut, Qiang Yu
Cc: Simon Shields, devicetree, Connor Abbott, Neil Armstrong,
Andrei Paulau, dri-devel, Vasily Khoruzhick, Erico Nunes
In-Reply-To: <7e0835f9-a368-294d-9483-91513211cf24@denx.de>
On Wed, May 23, 2018 at 07:16:41PM +0200, Marek Vasut wrote:
> On 05/18/2018 11:28 AM, Qiang Yu wrote:
> > From: Lima Project Developers <dri-devel@lists.freedesktop.org>
> >
> > Signed-off-by: Qiang Yu <yuq825@gmail.com>
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > Signed-off-by: Simon Shields <simon@lineageos.org>
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
> > drivers/gpu/drm/Kconfig | 2 ++
> > drivers/gpu/drm/Makefile | 1 +
> > drivers/gpu/drm/lima/Kconfig | 9 +++++++++
> > drivers/gpu/drm/lima/Makefile | 19 +++++++++++++++++++
> > 4 files changed, 31 insertions(+)
> > create mode 100644 drivers/gpu/drm/lima/Kconfig
> > create mode 100644 drivers/gpu/drm/lima/Makefile
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index deeefa7a1773..f00d529ee034 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig"
> >
> > source "drivers/gpu/drm/tve200/Kconfig"
> >
> > +source "drivers/gpu/drm/lima/Kconfig"
> > +
> > # Keep legacy drivers last
> >
> > menuconfig DRM_LEGACY
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 50093ff4479b..aba686e41d6b 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/
> > obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
> > obj-$(CONFIG_DRM_PL111) += pl111/
> > obj-$(CONFIG_DRM_TVE200) += tve200/
> > +obj-$(CONFIG_DRM_LIMA) += lima/
> > diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig
> > new file mode 100644
> > index 000000000000..4ce9ac2e8204
> > --- /dev/null
> > +++ b/drivers/gpu/drm/lima/Kconfig
> > @@ -0,0 +1,9 @@
> > +
> > +config DRM_LIMA
> > + tristate "LIMA (DRM support for ARM Mali 400/450 GPU)"
> > + depends on DRM
> > + depends on ARCH_SUNXI || ARCH_ROCKCHIP || ARCH_EXYNOS || ARCH_MESON
>
> You can add ARCH_ZYNQMP here too , it has Mali 400 MP2.
Better yet, just drop them all rather than continually adding to the
list.
But if you keep it, add '|| COMPILE_TEST'.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 07/24] drm/lima: add mali 4xx GPU hardware regs
From: Rob Herring @ 2018-05-23 17:24 UTC (permalink / raw)
To: Qiang Yu
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <20180518092815.25280-8-yuq825@gmail.com>
On Fri, May 18, 2018 at 05:27:58PM +0800, Qiang Yu wrote:
> From: Lima Project Developers <dri-devel@lists.freedesktop.org>
>
> Signed-off-by: Qiang Yu <yuq825@gmail.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/gpu/drm/lima/lima_regs.h | 304 +++++++++++++++++++++++++++++++
> 1 file changed, 304 insertions(+)
> create mode 100644 drivers/gpu/drm/lima/lima_regs.h
>
> diff --git a/drivers/gpu/drm/lima/lima_regs.h b/drivers/gpu/drm/lima/lima_regs.h
> new file mode 100644
> index 000000000000..ea4a37d69b98
> --- /dev/null
> +++ b/drivers/gpu/drm/lima/lima_regs.h
> @@ -0,0 +1,304 @@
> +/*
> + * Copyright (C) 2010-2017 ARM Limited. All rights reserved.
I assume this came from ARM's out of tree kernel driver source. You
should document what it was based on.
> + * Copyright (C) 2017-2018 Lima Project
IANAL, but is Lima Project a legal entity that can copyright things?
> + *
> + * This program is free software and is provided to you under
> + * the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation, and any use by
> + * you of this program is subject to the terms of such GNU
> + * licence.
> + *
> + * A copy of the licence is included with the program, and
> + * can also be obtained from Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
You can use SPDX tags instead.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] slimbus: ngd: dt-bindings: Add slim ngd dt bindings
From: Srinivas Kandagatla @ 2018-05-23 17:17 UTC (permalink / raw)
To: Rob Herring
Cc: gregkh, kramasub, sdharia, girishm, linux-kernel, mark.rutland,
bgoswami, devicetree, broonie, linux-arm-msm, alsa-devel
In-Reply-To: <20180523164023.GA24671@rob-hp-laptop>
Thanks Rob for review,
On 23/05/18 17:40, Rob Herring wrote:
> On Wed, May 16, 2018 at 05:51:17PM +0100, Srinivas Kandagatla wrote:
>> This patch adds bindings for Qualcomm SLIMBus NGD controller found in
>> all new SoCs starting from B family.
>> SLIMBus NGD controller is a light-weight driver responsible for
>> communicating with SLIMBus slaves directly over the bus using messaging
>> interface and communicating with master component residing on ADSP for
>> bandwidth and data-channel management
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> .../bindings/slimbus/slim-ngd-qcom-ctrl.txt | 70 ++++++++++++++++++++++
>> 1 file changed, 70 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
>>
>> diff --git a/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt b/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
>> new file mode 100644
>> index 000000000000..c948fb098819
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
>> @@ -0,0 +1,70 @@
>> +Qualcomm SLIMBus Non Generic Device (NGD) Controller binding
>> +
>> +SLIMBus NGD controller is a light-weight driver responsible for communicating
>> +with SLIMBus slaves directly over the bus using messaging interface and
>> +communicating with master component residing on ADSP for bandwidth and
>> +data-channel management
>> +
>> +Please refer to slimbus/bus.txt for details of the common SLIMBus bindings.
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: must be "qcom,slim-ngd"
>
> SoC specific compatible needed.
Yes, I will add that in v2.
>
>> +
>> +- reg:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: must specify the base address and size of the controller
>> + register blocks.
>
> blocks? Is there more than one? If so, how many?
Its just one. I will fix the text to reflect this.
>
>> +
>> +- reg-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: must be "ctrl"
>
> reg-names is pointless when there is only 1.
>
>> +
>> +- qcom,ngd-id
>> + Usage: required
>> + Value type: <u32>
>> + Definition: ngd instance id in the controller
>
> Why do you need this?
I have removed this totally in my next version, which I will be posting
soon.
Thanks,
srini
^ permalink raw reply
* Re: [PATCH RFC 24/24] drm/lima: add makefile and kconfig
From: Marek Vasut @ 2018-05-23 17:16 UTC (permalink / raw)
To: Qiang Yu, dri-devel, devicetree
Cc: Simon Shields, Connor Abbott, Neil Armstrong, Andrei Paulau,
Vasily Khoruzhick, Erico Nunes
In-Reply-To: <20180518092815.25280-25-yuq825@gmail.com>
On 05/18/2018 11:28 AM, Qiang Yu wrote:
> From: Lima Project Developers <dri-devel@lists.freedesktop.org>
>
> Signed-off-by: Qiang Yu <yuq825@gmail.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/gpu/drm/Kconfig | 2 ++
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/lima/Kconfig | 9 +++++++++
> drivers/gpu/drm/lima/Makefile | 19 +++++++++++++++++++
> 4 files changed, 31 insertions(+)
> create mode 100644 drivers/gpu/drm/lima/Kconfig
> create mode 100644 drivers/gpu/drm/lima/Makefile
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index deeefa7a1773..f00d529ee034 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig"
>
> source "drivers/gpu/drm/tve200/Kconfig"
>
> +source "drivers/gpu/drm/lima/Kconfig"
> +
> # Keep legacy drivers last
>
> menuconfig DRM_LEGACY
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 50093ff4479b..aba686e41d6b 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB) += mxsfb/
> obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
> obj-$(CONFIG_DRM_PL111) += pl111/
> obj-$(CONFIG_DRM_TVE200) += tve200/
> +obj-$(CONFIG_DRM_LIMA) += lima/
> diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig
> new file mode 100644
> index 000000000000..4ce9ac2e8204
> --- /dev/null
> +++ b/drivers/gpu/drm/lima/Kconfig
> @@ -0,0 +1,9 @@
> +
> +config DRM_LIMA
> + tristate "LIMA (DRM support for ARM Mali 400/450 GPU)"
> + depends on DRM
> + depends on ARCH_SUNXI || ARCH_ROCKCHIP || ARCH_EXYNOS || ARCH_MESON
You can add ARCH_ZYNQMP here too , it has Mali 400 MP2.
--
Best regards,
Marek Vasut
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Scott Branden @ 2018-05-23 17:15 UTC (permalink / raw)
To: Ray Jui, Robin Murphy, Guenter Roeck
Cc: Mark Rutland, devicetree, linux-watchdog, Catalin Marinas,
Will Deacon, linux-kernel, Rob Herring, bcm-kernel-feedback-list,
Wim Van Sebroeck, Frank Rowand, linux-arm-kernel
In-Reply-To: <5a996888-d3d3-9ae6-e438-5de4d5e3ea32@broadcom.com>
Raym
On 18-05-23 09:29 AM, Ray Jui wrote:
> Hi Robin,
>
> On 5/23/2018 4:48 AM, Robin Murphy wrote:
>> On 23/05/18 08:52, Scott Branden wrote:
>>>
>>>
>>> On 18-05-22 04:24 PM, Ray Jui wrote:
>>>> Hi Guenter,
>>>>
>>>> On 5/22/2018 1:54 PM, Guenter Roeck wrote:
>>>>> On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
>>>>>> If the watchdog hardware is already enabled during the boot process,
>>>>>> when the Linux watchdog driver loads, it should reset the
>>>>>> watchdog and
>>>>>> tell the watchdog framework. As a result, ping can be generated from
>>>>>> the watchdog framework, until the userspace watchdog daemon takes
>>>>>> over
>>>>>> control
>>>>>>
>>>>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>>>>> Reviewed-by: Vladimir Olovyannikov
>>>>>> <vladimir.olovyannikov@broadcom.com>
>>>>>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
>>>>>> 1 file changed, 22 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/watchdog/sp805_wdt.c
>>>>>> b/drivers/watchdog/sp805_wdt.c
>>>>>> index 1484609..408ffbe 100644
>>>>>> --- a/drivers/watchdog/sp805_wdt.c
>>>>>> +++ b/drivers/watchdog/sp805_wdt.c
>>>>>> @@ -42,6 +42,7 @@
>>>>>> /* control register masks */
>>>>>> #define INT_ENABLE (1 << 0)
>>>>>> #define RESET_ENABLE (1 << 1)
>>>>>> + #define ENABLE_MASK (INT_ENABLE | RESET_ENABLE)
>>>>>> #define WDTINTCLR 0x00C
>>>>>> #define WDTRIS 0x010
>>>>>> #define WDTMIS 0x014
>>>>>> @@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
>>>>>> MODULE_PARM_DESC(nowayout,
>>>>>> "Set to 1 to keep watchdog running after device release");
>>>>>> +/* returns true if wdt is running; otherwise returns false */
>>>>>> +static bool wdt_is_running(struct watchdog_device *wdd)
>>>>>> +{
>>>>>> + struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>>>>>> +
>>>>>> + if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
>>>>>> + ENABLE_MASK)
>>>>>> + return true;
>>>>>> + else
>>>>>> + return false;
>>>>>
>>>>> return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
>>>>>
>>>>
>>>> Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE);
>>>> therefore, a simple !!(expression) would not work? That is, the
>>>> masked result needs to be compared against the mask again to ensure
>>>> both bits are set, right?
>>> Ray - your original code looks correct to me. Easier to read and
>>> less prone to errors as shown in the attempted translation to a
>>> single statement.
>>
>> if (<boolean condition>)
>> return true;
>> else
>> return false;
>>
>> still looks really dumb, though, and IMO is actually harder to read
>> than just "return <boolean condition>;" because it forces you to stop
>> and double-check that the logic is, in fact, only doing the obvious
>> thing.
>
> If you can propose a way to modify my original code above to make it
> more readable, I'm fine to make the change.
>
> As I mentioned, I don't think the following change proposed by Guenter
> will work due to the reason I pointed out:
>
> return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
What they are looking for is:
return ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
ENABLE_MASK);
or maybe:
return !!((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
ENABLE_MASK);
>
>>
>> Robin.
>>
>>
>>
>> p.s. No thanks for making me remember the mind-boggling horror of
>> briefly maintaining part of this legacy codebase... :P
>>
>> $ grep -r '? true : false' --include=*.cpp . | wc -l
>> 951
^ permalink raw reply
* Re: [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate
From: Robin Murphy @ 2018-05-23 17:15 UTC (permalink / raw)
To: Ray Jui, Scott Branden, Guenter Roeck
Cc: Mark Rutland, devicetree, linux-watchdog, Catalin Marinas,
Will Deacon, linux-kernel, Rob Herring, bcm-kernel-feedback-list,
Wim Van Sebroeck, Frank Rowand, linux-arm-kernel
In-Reply-To: <5a996888-d3d3-9ae6-e438-5de4d5e3ea32@broadcom.com>
On 23/05/18 17:29, Ray Jui wrote:
> Hi Robin,
>
> On 5/23/2018 4:48 AM, Robin Murphy wrote:
>> On 23/05/18 08:52, Scott Branden wrote:
>>>
>>>
>>> On 18-05-22 04:24 PM, Ray Jui wrote:
>>>> Hi Guenter,
>>>>
>>>> On 5/22/2018 1:54 PM, Guenter Roeck wrote:
>>>>> On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:
>>>>>> If the watchdog hardware is already enabled during the boot process,
>>>>>> when the Linux watchdog driver loads, it should reset the watchdog
>>>>>> and
>>>>>> tell the watchdog framework. As a result, ping can be generated from
>>>>>> the watchdog framework, until the userspace watchdog daemon takes
>>>>>> over
>>>>>> control
>>>>>>
>>>>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>>>>> Reviewed-by: Vladimir Olovyannikov
>>>>>> <vladimir.olovyannikov@broadcom.com>
>>>>>> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> drivers/watchdog/sp805_wdt.c | 22 ++++++++++++++++++++++
>>>>>> 1 file changed, 22 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/watchdog/sp805_wdt.c
>>>>>> b/drivers/watchdog/sp805_wdt.c
>>>>>> index 1484609..408ffbe 100644
>>>>>> --- a/drivers/watchdog/sp805_wdt.c
>>>>>> +++ b/drivers/watchdog/sp805_wdt.c
>>>>>> @@ -42,6 +42,7 @@
>>>>>> /* control register masks */
>>>>>> #define INT_ENABLE (1 << 0)
>>>>>> #define RESET_ENABLE (1 << 1)
>>>>>> + #define ENABLE_MASK (INT_ENABLE | RESET_ENABLE)
>>>>>> #define WDTINTCLR 0x00C
>>>>>> #define WDTRIS 0x010
>>>>>> #define WDTMIS 0x014
>>>>>> @@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
>>>>>> MODULE_PARM_DESC(nowayout,
>>>>>> "Set to 1 to keep watchdog running after device release");
>>>>>> +/* returns true if wdt is running; otherwise returns false */
>>>>>> +static bool wdt_is_running(struct watchdog_device *wdd)
>>>>>> +{
>>>>>> + struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
>>>>>> +
>>>>>> + if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
>>>>>> + ENABLE_MASK)
>>>>>> + return true;
>>>>>> + else
>>>>>> + return false;
>>>>>
>>>>> return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
>>>>>
>>>>
>>>> Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE);
>>>> therefore, a simple !!(expression) would not work? That is, the
>>>> masked result needs to be compared against the mask again to ensure
>>>> both bits are set, right?
>>> Ray - your original code looks correct to me. Easier to read and
>>> less prone to errors as shown in the attempted translation to a
>>> single statement.
>>
>> if (<boolean condition>)
>> return true;
>> else
>> return false;
>>
>> still looks really dumb, though, and IMO is actually harder to read
>> than just "return <boolean condition>;" because it forces you to stop
>> and double-check that the logic is, in fact, only doing the obvious
>> thing.
>
> If you can propose a way to modify my original code above to make it
> more readable, I'm fine to make the change.
Well,
return readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK == ENABLE_MASK;
would probably be reasonable to anyone other than the 80-column zealots,
but removing the silly boolean-to-boolean translation idiom really only
emphasises the fact that it's fundamentally a big complex statement; for
maximum clarity I'd be inclined to separate the two logical operations
(read and comparison), e.g.:
u32 wdtcontrol = readl_relaxed(wdt->base + WDTCONTROL);
return wdtcontrol & ENABLE_MASK == ENABLE_MASK;
which is still -3 lines vs. the original.
> As I mentioned, I don't think the following change proposed by Guenter
> will work due to the reason I pointed out:
>
> return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));
FWIW, getting the desired result should only need one logical not
swapping for a bitwise one there:
return !(~readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK);
but that's well into "too clever for its own good" territory ;)
Robin.
^ permalink raw reply
* [PATCH 2/2] mtd: partitions: use DT info for parsing partitions with specified type
From: Rafał Miłecki @ 2018-05-23 17:14 UTC (permalink / raw)
To: Brian Norris, David Woodhouse, Boris Brezillon, Marek Vasut,
Richard Weinberger, Rob Herring
Cc: Mark Rutland, devicetree, linux-mtd, Rafał Miłecki,
Jonas Gorski
In-Reply-To: <20180523171448.26234-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
This supports nested partitions in a DT. If selected partition has a
"compatible" property specified it will be parsed looking for
subpartitions.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/mtd/mtdpart.c | 33 +++++++++++++--------------------
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index f8d3a015cdad..52e2cb35fc79 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -322,22 +322,6 @@ static inline void free_partition(struct mtd_part *p)
kfree(p);
}
-/**
- * mtd_parse_part - parse MTD partition looking for subpartitions
- *
- * @slave: part that is supposed to be a container and should be parsed
- * @types: NULL-terminated array with names of partition parsers to try
- *
- * Some partitions are kind of containers with extra subpartitions (volumes).
- * There can be various formats of such containers. This function tries to use
- * specified parsers to analyze given partition and registers found
- * subpartitions on success.
- */
-static int mtd_parse_part(struct mtd_part *slave, const char *const *types)
-{
- return parse_mtd_partitions(&slave->mtd, types, NULL);
-}
-
static struct mtd_part *allocate_partition(struct mtd_info *parent,
const struct mtd_partition *part, int partno,
uint64_t cur_offset)
@@ -735,8 +719,8 @@ int add_mtd_partitions(struct mtd_info *master,
add_mtd_device(&slave->mtd);
mtd_add_partition_attrs(slave);
- if (parts[i].types)
- mtd_parse_part(slave, parts[i].types);
+ /* Look for subpartitions */
+ parse_mtd_partitions(&slave->mtd, parts[i].types, NULL);
cur_offset = slave->offset + slave->mtd.size;
}
@@ -812,6 +796,12 @@ static const char * const default_mtd_part_types[] = {
NULL
};
+/* Check DT only when looking for subpartitions. */
+static const char * const default_subpartition_types[] = {
+ "ofpart",
+ NULL
+};
+
static int mtd_part_do_parse(struct mtd_part_parser *parser,
struct mtd_info *master,
struct mtd_partitions *pparts,
@@ -882,7 +872,9 @@ static int mtd_part_of_parse(struct mtd_info *master,
const char *fixed = "fixed-partitions";
int ret, err = 0;
- np = of_get_child_by_name(mtd_get_of_node(master), "partitions");
+ np = mtd_get_of_node(master);
+ if (!mtd_is_partition(master))
+ np = of_get_child_by_name(np, "partitions");
of_property_for_each_string(np, "compatible", prop, compat) {
parser = mtd_part_get_compatible_parser(compat);
if (!parser)
@@ -945,7 +937,8 @@ int parse_mtd_partitions(struct mtd_info *master, const char *const *types,
int ret, err = 0;
if (!types)
- types = default_mtd_part_types;
+ types = mtd_is_partition(master) ? default_subpartition_types :
+ default_mtd_part_types;
for ( ; *types; types++) {
/*
--
2.13.6
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: mtd: explicitly describe nesting partitions
From: Rafał Miłecki @ 2018-05-23 17:14 UTC (permalink / raw)
To: Brian Norris, David Woodhouse, Boris Brezillon, Marek Vasut,
Richard Weinberger, Rob Herring
Cc: Mark Rutland, devicetree, linux-mtd, Rafał Miłecki,
Jonas Gorski
From: Rafał Miłecki <rafal@milecki.pl>
Documentation was already saying that fixed and dynamic partitioning can
be mixed but was missing a clear description and examples. This commit
adds a proper description of how partitions can be nested and how layout
descriptions can be mixed.
This addition is important for partitions that contain subpartitions.
It's useful to have parent partition registered (e.g. for overwriting
purposes) as well as children ones (for accessing data). It's also
required when a single partition uses different partitioning method
(e.g. vendor custom "firmware" partition with kernel + rootfs).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
Another example (I couldn't put in Documentation yet) could be:
flash@0 {
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "bootloader";
reg = <0x0000000 0x0100000>;
read-only;
};
firmware@100000 {
label = "firmware";
reg = <0x0100000 0x0800000>;
compatible = "brcm,trx";
};
};
};
It's probably even more realistic one, but we don't describe "brcm,trx"
binding yet.
The purpose of above description would be to:
1) Specify fixed partitions (they never change)
2) Tell operating system that "firmware" partition uses Broadcom's TRX
format which is a container for 2 or 3 subpartitions (usually: kernel
and rootfs).
---
.../devicetree/bindings/mtd/partition.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
index a8f382642ba9..2214167ce88a 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -14,6 +14,13 @@ method is used for a given flash device. To describe the method there should be
a subnode of the flash device that is named 'partitions'. It must have a
'compatible' property, which is used to identify the method to use.
+When a single partition is represented with a DT node (it depends on a used
+format) it may also be described using above rules ('compatible' and optionally
+some extra properties / subnodes). It allows describing more complex,
+hierarchical (multi-level) layouts and should be used if there is some
+significant relation between partitions or some partition internally uses
+another partitioning method.
+
Available bindings are listed in the "partitions" subdirectory.
@@ -73,6 +80,24 @@ flash@0 {
uimage@100000 {
reg = <0x0100000 0x200000>;
};
+
+ calibration@200000 {
+ label = "calibration";
+ reg = <0x0200000 0x100000>;
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "wifi0";
+ reg = <0x000000 0x080000>;
+ };
+
+ partition@80000 {
+ label = "wifi1";
+ reg = <0x080000 0x080000>;
+ };
+ };
};
};
--
2.13.6
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* Re: [PATCH RFC 12/24] drm/lima: add GP related functions
From: Marek Vasut @ 2018-05-23 17:12 UTC (permalink / raw)
To: Qiang Yu, dri-devel, devicetree
Cc: Simon Shields, Connor Abbott, Neil Armstrong, Andrei Paulau,
Vasily Khoruzhick, Erico Nunes
In-Reply-To: <20180518092815.25280-13-yuq825@gmail.com>
On 05/18/2018 11:28 AM, Qiang Yu wrote:
> GP is a processor for OpenGL vertex shader
> processing.
>
> Signed-off-by: Qiang Yu <yuq825@gmail.com>
[...]
> +int lima_gp_init(struct lima_ip *ip)
> +{
> + struct lima_device *dev = ip->dev;
> + int err;
> +
> + lima_gp_print_version(ip);
> +
> + ip->data.async_reset = false;
> + lima_gp_soft_reset_async(ip);
> + err = lima_gp_soft_reset_async_wait(ip);
> + if (err)
> + return err;
> +
> + err = devm_request_irq(dev->dev, ip->irq, lima_gp_irq_handler, 0,
> + lima_ip_name(ip), ip);
IRQF_SHARED, since there are designs (like zynqmp) where there is only
one IRQ line for the entire GPU.
> + if (err) {
> + dev_err(dev->dev, "gp %s fail to request irq\n",
> + lima_ip_name(ip));
> + return err;
> + }
> +
> + return 0;
> +}
[...]
--
Best regards,
Marek Vasut
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 01/24] ARM: dts: add gpu node to exynos4
From: Rob Herring @ 2018-05-23 17:06 UTC (permalink / raw)
To: Qiang Yu
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <20180518092815.25280-2-yuq825@gmail.com>
On Fri, May 18, 2018 at 05:27:52PM +0800, Qiang Yu wrote:
> From: Simon Shields <simon@lineageos.org>
>
> v2 (Qiang Yu):
> add vender string to exynos4 mali gpu
This also needs to be added to the binding doc.
>
> Based off a similar commit for the Samsung Mali driver by
> Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> Signed-off-by: Qiang Yu <yuq825@gmail.com>
> ---
> arch/arm/boot/dts/exynos4.dtsi | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 0/4] ARM64: dts: meson-axg: i2c updates
From: Kevin Hilman @ 2018-05-23 17:06 UTC (permalink / raw)
To: Jerome Brunet
Cc: Carlo Caione, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20180517093100.22225-1-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> This patchset fixes a few problems found in the i2c nodes of
> amlogic's meson-axg platform. It also adds the missing pins for
> AO controller so we can use it on the S400
>
> This series has been tested on the S400 board.
>
> Jerome Brunet (4):
> ARM64: dts: meson-axg: clean-up i2c nodes
> ARM64: dts: meson-axg: correct i2c AO clock
> ARM64: dts: meson-axg: add i2c AO pins
> ARM64: dts: meson-axg: enable i2c AO on the S400 board
Applied to v4.18/dt64,
Kevin
^ permalink raw reply
* Re: [PATCH RFC 02/24] dt-bindings: add switch-delay property for mali-utgard
From: Rob Herring @ 2018-05-23 17:04 UTC (permalink / raw)
To: Qiang Yu
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <20180518092815.25280-3-yuq825@gmail.com>
On Fri, May 18, 2018 at 05:27:53PM +0800, Qiang Yu wrote:
> Signed-off-by: Qiang Yu <yuq825@gmail.com>
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> index c1f65d1dac1d..062d4bee216a 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> @@ -58,6 +58,10 @@ Optional properties:
> A power domain consumer specifier as defined in
> Documentation/devicetree/bindings/power/power_domain.txt
>
> + - switch-delay:
> + This value is the number of Mali clock cycles it takes to
> + enable the power gates and turn on the power mesh.
This should be implied by the SoC specific compatible string.
Alternatively, can't the driver just pick a value long enough for
everyone? Does it really vary that much, and is it timing critical?
Rob
P.S. Keep up the great work on this!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] clk: aspeed: Add 24MHz fixed clock
From: Rob Herring @ 2018-05-23 17:00 UTC (permalink / raw)
To: Lei YU
Cc: Michael Turquette, Stephen Boyd, Joel Stanley, Andrew Jeffery,
Mark Rutland, linux-clk, linux-arm-kernel, linux-aspeed,
linux-kernel, devicetree
In-Reply-To: <1526633822-17138-1-git-send-email-mine260309@gmail.com>
On Fri, May 18, 2018 at 04:57:02PM +0800, Lei YU wrote:
> Add a 24MHz fixed clock.
> This clock will be used for certain devices, e.g. pwm.
>
> Signed-off-by: Lei YU <mine260309@gmail.com>
> ---
> drivers/clk/clk-aspeed.c | 9 ++++++++-
> include/dt-bindings/clock/aspeed-clock.h | 1 +
> 2 files changed, 9 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] PM / devfreq: Generic cpufreq governor
From: Rob Herring @ 2018-05-23 16:58 UTC (permalink / raw)
To: Saravana Kannan
Cc: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Mark Rutland,
Rajendra Nayak, Amit Kucheria, linux-pm, devicetree, linux-kernel
In-Reply-To: <1526631889-5084-3-git-send-email-skannan@codeaurora.org>
On Fri, May 18, 2018 at 01:24:48AM -0700, Saravana Kannan wrote:
> This devfreq governor is a generic implementation that can scale any
> devfreq device based on the current CPU frequency of all ONLINE CPUs. It
> allows for specifying CPU freq to devfreq mapping for specific devices.
> When such a mapping is not present, it defaults to scaling the device
> frequency in proportion to the CPU frequency.
>
> Change-Id: I7f786b9059435afe85b9ec8c504a4655731ee20e
drop this.
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> ---
> .../bindings/devfreq/devfreq-cpufreq.txt | 53 ++
Please split bindings to separate patch.
> drivers/devfreq/Kconfig | 8 +
> drivers/devfreq/Makefile | 1 +
> drivers/devfreq/governor_cpufreq.c | 628 +++++++++++++++++++++
> 4 files changed, 690 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/devfreq/devfreq-cpufreq.txt
> create mode 100644 drivers/devfreq/governor_cpufreq.c
>
> diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq.txt b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq.txt
> new file mode 100644
> index 0000000..6537538
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq.txt
> @@ -0,0 +1,53 @@
> +Devfreq CPUfreq governor
> +
> +devfreq-cpufreq is a parent device that contains one or more child devices.
> +Each child device provides CPU frequency to device frequency mapping for a
> +specific device. Examples of devices that could use this are: DDR, cache and
> +CCI.
> +
> +Parent device name shall be "devfreq-cpufreq".
I don't really understand any of this and how it relates to the other
QCom cpufreq and devfreq bindings. Seems like this all needs some
discussion amongst the PM folks first.
Rob
^ permalink raw reply
* Re: [PATCH] ASoC: ssm2602: Fix ADC powerup sequencing
From: Rob Herring @ 2018-05-23 16:53 UTC (permalink / raw)
To: Philipp Zabel
Cc: Mark Rutland, devicetree, Linux-ALSA, Lars-Peter Clausen,
Sascha Hauer, Marco Felsch, Liam Girdwood, Mark Brown,
Sascha Hauer
In-Reply-To: <1526640409.3948.5.camel@pengutronix.de>
On Fri, May 18, 2018 at 12:46:49PM +0200, Philipp Zabel wrote:
> Hi Rob,
>
> On Thu, 2018-05-17 at 11:14 -0500, Rob Herring wrote:
> > On Thu, May 17, 2018 at 8:30 AM, Marco Felsch <m.felsch@pengutronix.de> wrote:
> > > From: Philipp Zabel <p.zabel@pengutronix.de>
> > >
> > > According to the ssm2603 data sheet (control register sequencing), the
> > > digital core should be activated only after all necessary bits in the
> > > power register are enabled, and a delay determined by the decoupling
> > > capacitor on the VMID pin has passed. If the digital core is activated
> > > too early, or even before the ADC is powered up, audible artifacts
> > > appear at the beginning of the recorded signal.
> > >
> > > The digital core is also needed for playback, so when recording starts
> > > it may already be enabled. This means we cannot get the power sequence
> > > correct when we want to be able to start recording after playback.
> > >
> > > As a workaround put the MIC mute switch into the DAPM routes. This
> > > way we can keep the recording disabled until the MIC Bias has settled
> > > and thus get rid of audible artifacts.
> > >
> > > The delay we have to wait depends on a board specific capacitor
> > > connected to the VMID pins, so make the delay configurable in the device
> > > tree.
> > >
> > > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > > ---
> > > .../devicetree/bindings/sound/adi,ssm2602.txt | 7 +++++
> > > sound/soc/codecs/ssm2602.c | 30 +++++++++++++++++--
> > > 2 files changed, 35 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2602.txt b/Documentation/devicetree/bindings/sound/adi,ssm2602.txt
> > > index 3b3302fe399b..9334d48c0462 100644
> > > --- a/Documentation/devicetree/bindings/sound/adi,ssm2602.txt
> > > +++ b/Documentation/devicetree/bindings/sound/adi,ssm2602.txt
> > > @@ -11,9 +11,16 @@ Required properties:
> > > - reg : the I2C address of the device for I2C, the chip select
> > > number for SPI.
> > >
> > > +Optional properties:
> > > +
> > > + - startup-delay-us : delay between powering on and activating the digital
> > > + core, determined by the decoupling capacitor C on the
> > > + VMID pin: delay [µs] = C [µF] * 25000 / 3.5
> > > +
> >
> > We already have similarly defined property. Please reuse that. See mmc
> > pwrseq binding.
>
> Do you mean 'post-power-on-delay-ms' from 'mmc-pwseq-simple'?
> It is documented as:
>
> - post-power-on-delay-ms : Delay in ms after powering the card and
> de-asserting the reset-gpios (if any)
>
> The startup delay here is not after powering the whole IC or deasserting
> resets and before it can be used, but after powering up a specific part
> of the codec (the ADC) and before unmuting the MIC input to the digital
> core during start of decoding. With this in mind, do you still think the
> property should be called the same as the mmc full-chip poweron delay?
> If so, would it be acceptable to use post-power-on-delay-us to keep the
> microsecond resolution?
Okay, then I'd suggest something a bit more specific. Perhaps
"pre-unmute-delay-us" and document in a common location.
Rob
^ permalink raw reply
* Re: [PATCH 2/4] arcnet: com20020: bindings for smsc com20020
From: Rob Herring @ 2018-05-23 16:49 UTC (permalink / raw)
To: Andrea Greco
Cc: tobin, Andrea Greco, Mark Rutland, netdev, devicetree,
linux-kernel
In-Reply-To: <20180517130628.2770-1-andrea.greco.gapmilano@gmail.com>
On Thu, May 17, 2018 at 03:06:26PM +0200, Andrea Greco wrote:
> From: Andrea Greco <a.greco@4sigma.it>
>
> Add devicetree bindings for smsc com20020
>
> Signed-off-by: Andrea Greco <a.greco@4sigma.it>
> ---
> .../devicetree/bindings/net/smsc-com20020.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/smsc-com20020.txt
One typo, otherwise:
Reviewed-by: Rob Herring <robh@kernel.org>
>
> diff --git a/Documentation/devicetree/bindings/net/smsc-com20020.txt b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> new file mode 100644
> index 000000000000..92360b054873
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/smsc-com20020.txt
> @@ -0,0 +1,21 @@
> +SMSC com20020 Arcnet network controller
> +
> +Required propelty:
property
> +- timeout-ns: Arcnet bus timeout, Idle Time (328000 - 20500)
> +- bus-speed-bps: Arcnet bus speed (10000000 - 156250)
> +- smsc,xtal-mhz: External oscillator frequency
> +- smsc,backplane-enabled: Controller use backplane mode
> +- reset-gpios: Chip reset pin
> +- interrupts: Should contain controller interrupt
> +
> +arcnet@28000000 {
> + compatible = "smsc,com20020";
> +
> + timeout-ns = <20500>;
> + bus-speed-bps = <10000000>;
> + smsc,xtal-mhz = <20>;
> + smsc,backplane-enabled;
> +
> + reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>;
> + interrupts = <&gpio2 10 GPIO_ACTIVE_LOW>;
> +};
> --
> 2.14.3
>
^ permalink raw reply
* Re: [PATCH] of: overlay: validate offset from property fixups
From: Rob Herring @ 2018-05-23 16:44 UTC (permalink / raw)
To: frowand.list
Cc: pantelis.antoniou, Pantelis Antoniou, Dan Carpenter, devicetree,
linux-kernel
In-Reply-To: <1526530791-18591-1-git-send-email-frowand.list@gmail.com>
On Wed, May 16, 2018 at 09:19:51PM -0700, frowand.list@gmail.com wrote:
> From: Frank Rowand <frank.rowand@sony.com>
>
> The smatch static checker marks the data in offset as untrusted,
> leading it to warn:
>
> drivers/of/resolver.c:125 update_usages_of_a_phandle_reference()
> error: buffer underflow 'prop->value' 's32min-s32max'
>
> Add check to verify that offset is within the property data.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
> ---
> drivers/of/resolver.c | 5 +++++
> 1 file changed, 5 insertions(+)
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH] perf: hisi: fix uncore PMU index ID
From: Will Deacon @ 2018-05-23 16:42 UTC (permalink / raw)
To: Zhangshaokun
Cc: Mark Rutland, devicetree, Huiqiang Wang, linux-arm-kernel,
Linuxarm
In-Reply-To: <a301d72f-687c-0c4f-1d44-83e5bbad5e60@hisilicon.com>
On Tue, May 22, 2018 at 05:18:51PM +0800, Zhangshaokun wrote:
> On 2018/5/22 1:05, Will Deacon wrote:
> > Whilst I'd normally just accept PMU driver submissions for vendor PMUs,
> > this part rang my alarm bells:
> >
> >> diff --git a/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
> >> index 443906e..dcd8e77 100644
> >> --- a/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
> >> +++ b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
> >> @@ -238,19 +238,10 @@ MODULE_DEVICE_TABLE(acpi, hisi_hha_pmu_acpi_match);
> >> static int hisi_hha_pmu_init_data(struct platform_device *pdev,
> >> struct hisi_pmu *hha_pmu)
> >> {
> >> - unsigned long long id;
> >> struct resource *res;
> >> - acpi_status status;
> >> -
> >> - status = acpi_evaluate_integer(ACPI_HANDLE(&pdev->dev),
> >> - "_UID", NULL, &id);
> >> - if (ACPI_FAILURE(status))
> >> - return -EINVAL;
> >> -
> >> - hha_pmu->index_id = id;
> >>
> >> /*
> >> - * Use SCCL_ID and UID to identify the HHA PMU, while
> >> + * Use SCCL_ID and HHA index ID to identify the HHA PMU, while
> >> * SCCL_ID is in MPIDR[aff2].
> >> */
> >> if (device_property_read_u32(&pdev->dev, "hisilicon,scl-id",
> >> @@ -258,6 +249,13 @@ static int hisi_hha_pmu_init_data(struct platform_device *pdev,
> >> dev_err(&pdev->dev, "Can not read hha sccl-id!\n");
> >> return -EINVAL;
> >> }
> >> +
> >> + if (device_property_read_u32(&pdev->dev, "hisilicon,idx-id",
> >> + &hha_pmu->index_id)) {
> >> + dev_err(&pdev->dev, "Can not read hha index-id!\n");
> >> + return -EINVAL;
> >> + }
> >
> > Is this a new DT property? If so, please can you update the binding
> > documentation and get an Ack from a DT maintainer? It's not clear to me
>
> No, it is not a DT property. We don't support DT mode for this platform and
> only support ACPI mode.
Hmm, but by using the firmware-agnostic "device_property_read_u32"
interface, aren't you implicitly supporting it via DT as well? In fact,
don't you now fail the probe if this new property isn't present? Isn't
that a regression?
> > what a "hisilicon,idx-id" is, nor how I would generate on from firmware.
> >
>
> For HiSilicon this platform, it supports multi-sccl. each sccl has more than one uncore
> PMUs. Like HHA uncore PMUs, each sccl has 2-HHA PMUs and idx-id is in _DSD package and
> used to distinguish different HHA PMUs with the same sccl, as follow:
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"hisilicon,scl-id", 0x03},
> Package () {"hisilicon,idx-id", 0x00},
> }
> })
I'm still none the wiser about what this actually is. How is new _DSD crud
supposed to be documented?
Will
^ permalink raw reply
* Re: [PATCH] dt-bindings: media: rcar_vin: fix style for ports and endpoints
From: Rob Herring @ 2018-05-23 16:42 UTC (permalink / raw)
To: Niklas Söderlund
Cc: devicetree, linux-media, linux-renesas-soc, Geert Uytterhoeven
In-Reply-To: <20180516233212.30931-1-niklas.soderlund+renesas@ragnatech.se>
On Thu, May 17, 2018 at 01:32:12AM +0200, Niklas S�derlund wrote:
> The style for referring to ports and endpoint are wrong. Refer to them
> using lowercase and a unit address, port@x and endpoint@x.
>
> Signed-off-by: Niklas S�derlund <niklas.soderlund+renesas@ragnatech.se>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> .../devicetree/bindings/media/rcar_vin.txt | 20 +++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/2] slimbus: ngd: dt-bindings: Add slim ngd dt bindings
From: Rob Herring @ 2018-05-23 16:40 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: mark.rutland, devicetree, alsa-devel, girishm, gregkh, broonie,
linux-kernel, bgoswami, kramasub, linux-arm-msm, sdharia
In-Reply-To: <20180516165118.16551-2-srinivas.kandagatla@linaro.org>
On Wed, May 16, 2018 at 05:51:17PM +0100, Srinivas Kandagatla wrote:
> This patch adds bindings for Qualcomm SLIMBus NGD controller found in
> all new SoCs starting from B family.
> SLIMBus NGD controller is a light-weight driver responsible for
> communicating with SLIMBus slaves directly over the bus using messaging
> interface and communicating with master component residing on ADSP for
> bandwidth and data-channel management
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> .../bindings/slimbus/slim-ngd-qcom-ctrl.txt | 70 ++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt b/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
> new file mode 100644
> index 000000000000..c948fb098819
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/slimbus/slim-ngd-qcom-ctrl.txt
> @@ -0,0 +1,70 @@
> +Qualcomm SLIMBus Non Generic Device (NGD) Controller binding
> +
> +SLIMBus NGD controller is a light-weight driver responsible for communicating
> +with SLIMBus slaves directly over the bus using messaging interface and
> +communicating with master component residing on ADSP for bandwidth and
> +data-channel management
> +
> +Please refer to slimbus/bus.txt for details of the common SLIMBus bindings.
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be "qcom,slim-ngd"
SoC specific compatible needed.
> +
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: must specify the base address and size of the controller
> + register blocks.
blocks? Is there more than one? If so, how many?
> +
> +- reg-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be "ctrl"
reg-names is pointless when there is only 1.
> +
> +- qcom,ngd-id
> + Usage: required
> + Value type: <u32>
> + Definition: ngd instance id in the controller
Why do you need this?
> +- dmas
> + Usage: required
> + Value type: <array of phandles>
> + Definition: List of rx and tx dma channels
> +
> +- dma-names
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be "rx" and "tx".
> +
> +- interrupts:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: must list controller IRQ.
> +
> +#address-cells
> + Usage: required
> + Refer to slimbus/bus.txt for details of the common SLIMBus bindings.
> +
> +#size-cells
> + Usage: required
> + Refer to slimbus/bus.txt for details of the common SLIMBus bindings.
> +
> += EXAMPLE
> +
> +slim@91c0000 {
> + compatible = "qcom,slim-ngd";
> + reg = <0x91c0000 0x2C000>;
> + reg-names = "ctrl";
> + interrupts = <0 163 0>;
> + qcom,ngd-id = <1>;
> + dmas = <&slimbam 3>, <&slimbam 4>;
> + dma-names = "rx", "tx";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + codec@1 {
> + compatible = "slim217,1a0";
> + reg = <1 0>;
> + };
> +};
> --
> 2.16.2
>
^ permalink raw reply
* Re: [v4 07/11] dt-bindings: hwmon: Add documents for PECI hwmon client drivers
From: Jae Hyun Yoo @ 2018-05-23 16:37 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Haiyue Wang, Vernon Mauery, James Feist, devicetree,
linux-kernel@vger.kernel.org, Andrew Jeffery, Arnd Bergmann,
Jason M Biils, Joel Stanley
In-Reply-To: <CAL_JsqJ8rjRzaqasjbdq-jkYfWxdo72YnmKAVNxDwo6wtyv1xg@mail.gmail.com>
On 5/23/2018 8:11 AM, Rob Herring wrote:
> On Tue, May 22, 2018 at 12:18 PM, Jae Hyun Yoo
> <jae.hyun.yoo@linux.intel.com> wrote:
>> On 5/22/2018 9:42 AM, Rob Herring wrote:
>>>
>>> On Mon, May 21, 2018 at 12:59:05PM -0700, Jae Hyun Yoo wrote:
>>>>
>>>> This commit adds dt-bindings documents for PECI hwmon client drivers.
>>>>
>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>>>> Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
>>>> Reviewed-by: James Feist <james.feist@linux.intel.com>
>>>> Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
>>>> Cc: Andrew Jeffery <andrew@aj.id.au>
>>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>>> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
>>>> Cc: Joel Stanley <joel@jms.id.au>
>>>> ---
>>>> .../bindings/hwmon/peci-cputemp.txt | 23 ++++++++++++++++++
>>>> .../bindings/hwmon/peci-dimmtemp.txt | 24 +++++++++++++++++++
>>>> 2 files changed, 47 insertions(+)
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>>> create mode 100644
>>>> Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>>> b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>>> new file mode 100644
>>>> index 000000000000..2f59aee12d9e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>>> @@ -0,0 +1,23 @@
>>>> +Bindings for Intel PECI (Platform Environment Control Interface) cputemp
>>>> driver.
>>>> +
>>>> +Required properties:
>>>> +- compatible : Should be "intel,peci-cputemp".
>>>> +- reg : Should contain address of a client CPU. Address range of
>>>> CPU
>>>> + clients is starting from 0x30 based on PECI specification.
>>>> +
>>>> +Example:
>>>> + peci-bus@0 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + < more properties >
>>>> +
>>>> + peci-cputemp@30 {
>>>> + compatible = "intel,peci-cputemp";
>>>> + reg = <0x30>;
>>>> + };
>>>
>>>
>>> [...]
>>>
>>>> + peci-dimmtemp@30 {
>>>> + compatible = "intel,peci-dimmtemp";
>>>> + reg = <0x30>;
>>>> + };
>>>
>>>
>>> As I said in the prior version, 2 nodes at the same address is wrong.
>>>
>>> Rob
>>>
>>
>> In PECI bus, there is one and only bus host (adapter) and multiple
>> clients on a PECI bus, and PECI spec doesn't allow multiple originators
>> so only the host device can originate message.
>
> Yes, I get that. A single host still has to address slave devices.
>
>> In this implementation,
>> all message transactions on a bus from client driver modules and user
>> space will be serialized well in the PECI core bus driver so bus
>> occupation and traffic arbitration will be managed well in the PECI core
>> bus driver even in case of a bus has 2 client drivers at the same
>> address. I'm sure that this implementation doesn't make that kind of
>> problem to OS.
>
> Multiple clients to a single device is common, but that is a software
> problem and doesn't belong in DT.
>
> I don't think there is a single other case in the kernel where
> multiple drivers can bind to the same device at a given bus address.
> That is why we have things like MFD. Though in this case, why can't
> one hwmon driver register multiple hwmon devices (cpu and dimm temps)?
>
It was implemented as a single driver until v2 but dimm temps need
delayed creation unlikely the cpu temps on hwmon subsystem because of
memory training behavior of remote x86 cpus. Since hwmon doesn't allow
incremental creation, I had to divide it into two, cputemp and dimmtemp,
so that cputemp can be registered immediately when the remote x86 cpu
turns on and dimmtemp can be registered by delayed creation. It is the
reason why I had to make the two hwmon driver modules that sharing a
single device address. Additionally, PECI isn't limited for temperature
monitoring feature but it can be used for other functions such as
platform management, cpu interface tuning and diagnostics and failure
analysis, so in case of adding a new driver for the functions, we should
add an another DT node which is sharing the same cpu address.
Thanks,
-Jae
^ permalink raw reply
* Re: [PATCH 2/6] dt-bindings: media: rcar-vin: Document data-active
From: Rob Herring @ 2018-05-23 16:37 UTC (permalink / raw)
To: Jacopo Mondi
Cc: devicetree, linux-renesas-soc, horms, geert, laurent.pinchart,
niklas.soderlund, linux-arm-kernel, linux-media
In-Reply-To: <1526488352-898-3-git-send-email-jacopo+renesas@jmondi.org>
On Wed, May 16, 2018 at 06:32:28PM +0200, Jacopo Mondi wrote:
> Document 'data-active' property in R-Car VIN device tree bindings.
> The property is optional when running with explicit synchronization
> (eg. BT.601) but mandatory when embedded synchronization is in use (eg.
> BT.656) as specified by the hardware manual.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index c53ce4e..17eac8a 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -63,6 +63,11 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> If both HSYNC and VSYNC polarities are not specified, embedded
> synchronization is selected.
>
> + - data-active: active state of data enable signal (CLOCKENB pin).
> + 0/1 for LOW/HIGH respectively. If not specified, use HSYNC as
> + data enable signal. When using embedded synchronization this
> + property is mandatory.
This doesn't match the common property's definition which AIUI is for
the data lines' polarity. You need a new property. Perhaps a common one.
> +
> - port 1 - sub-nodes describing one or more endpoints connected to
> the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> use the following schema.
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Rob Herring @ 2018-05-23 16:33 UTC (permalink / raw)
To: Niklas Söderlund
Cc: devicetree, linux-renesas-soc, horms, geert, laurent.pinchart,
Jacopo Mondi, linux-arm-kernel, linux-media
In-Reply-To: <20180516221307.GF17948@bigcity.dyn.berto.se>
On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your work.
>
> On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > driver and only confuse users. Remove them in all Gen2 SoC that used
> > them.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > arch/arm/boot/dts/r8a7790-lager.dts | 3 ---
> > arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> > arch/arm/boot/dts/r8a7791-porter.dts | 1 -
> > arch/arm/boot/dts/r8a7793-gose.dts | 3 ---
> > arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> > arch/arm/boot/dts/r8a7794-silk.dts | 1 -
> > 6 files changed, 12 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> > index 063fdb6..b56b309 100644
> > --- a/arch/arm/boot/dts/r8a7790-lager.dts
> > +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> > @@ -873,10 +873,8 @@
> > port {
> > vin0ep2: endpoint {
> > remote-endpoint = <&adv7612_out>;
> > - bus-width = <24>;
>
> I can't really make up my mind if this is a good thing or not. Device
> tree describes the hardware and not what the drivers make use of. And
> the fact is that this bus is 24 bits wide. So I'm not sure we should
> remove these properties. But I would love to hear what others think
> about this.
IMO, this property should only be present when all the pins are not
connected. And by "all", I mean the minimum of what each end of the
graph can support.
Rob
^ permalink raw reply
* Re: [PATCH 0/3] irqchip: meson-gpio: add support for Meson-AXG SoCs
From: Marc Zyngier @ 2018-05-23 16:29 UTC (permalink / raw)
To: Yixun Lan, Jason Cooper, Thomas Gleixner, Kevin Hilman
Cc: Carlo Caione, Jerome Brunet, Heiner Kallweit, Rob Herring,
Xingyu Chen, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <0c97c61b-c05b-21cf-c880-80cff04ed6f2@amlogic.com>
On 16/05/18 03:50, Yixun Lan wrote:
> Hi Marc (or anyone else)
>
> On 04/08/18 22:56, Yixun Lan wrote:
>> This series try to add GPIO interrupt controller support for Meson-AXG SoCs.
>> The first patch is a trivial typo fix, I can fold the first two patches
>> together if necessary.
>>
>> Yixun Lan (3):
>> dt-bindings: interrupt-controller: fix the double quotes
>> dt-bindings: interrupt-controller: New binding for Meson-AXG SoC
>> irqchip/meson-gpio: add support for Meson-AXG SoCs
>>
>> .../bindings/interrupt-controller/amlogic,meson-gpio-intc.txt | 11 ++++++-----
>> drivers/irqchip/irq-meson-gpio.c | 5 +++++
>> 2 files changed, 11 insertions(+), 5 deletions(-)
>>
>
> please consider this merely a ping..
> will you take this series, or is there anything holding this?
Sure, I'll queue that for 4.18.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: media: rcar-vin: Describe optional ep properties
From: Rob Herring @ 2018-05-23 16:29 UTC (permalink / raw)
To: Jacopo Mondi
Cc: devicetree, linux-renesas-soc, horms, geert, laurent.pinchart,
niklas.soderlund, linux-arm-kernel, linux-media
In-Reply-To: <1526488352-898-2-git-send-email-jacopo+renesas@jmondi.org>
On Wed, May 16, 2018 at 06:32:27PM +0200, Jacopo Mondi wrote:
> Describe the optional endpoint properties for endpoint nodes of port@0
> and port@1 of the R-Car VIN driver device tree bindings documentation.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1..c53ce4e 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -53,6 +53,16 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> from external SoC pins described in video-interfaces.txt[1].
> Describing more then one endpoint in port 0 is invalid. Only VIN
> instances that are connected to external pins should have port 0.
> +
> + - Optional properties for endpoint nodes of port@0:
> + - hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> + respectively. Default is active high.
> + - vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> + respectively. Default is active high.
> +
> + If both HSYNC and VSYNC polarities are not specified, embedded
> + synchronization is selected.
No need to copy-n-paste from video-interfaces.txt. Just "see
video-interfaces.txt" for the description is fine.
> +
> - port 1 - sub-nodes describing one or more endpoints connected to
> the VIN from local SoC CSI-2 receivers. The endpoint numbers must
> use the following schema.
> @@ -62,6 +72,8 @@ from local SoC CSI-2 receivers (port1) depending on SoC.
> - Endpoint 2 - sub-node describing the endpoint connected to CSI40
> - Endpoint 3 - sub-node describing the endpoint connected to CSI41
>
> + Endpoint nodes of port@1 do not support any optional endpoint property.
> +
> Device node example for Gen2 platforms
> --------------------------------------
>
> @@ -112,7 +124,6 @@ Board setup example for Gen2 platforms (vin1 composite video input)
>
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> --
> 2.7.4
>
^ 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