* Re: [PATCH] mtd: use dev_of_node helper in mtd_get_of_node
From: Boris Brezillon @ 2017-03-31 9:49 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170331091148.19816-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 31 Mar 2017 11:11:48 +0200
Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> This allows better compile-time optimizations with CONFIG_OF disabled.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Not sure we care about such micro-optimizations, but it shouldn't hurst
so,
Acked-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> include/linux/mtd/mtd.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index eebdc63cf6af..f8db5b2e4028 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -393,7 +393,7 @@ static inline void mtd_set_of_node(struct mtd_info *mtd,
>
> static inline struct device_node *mtd_get_of_node(struct mtd_info *mtd)
> {
> - return mtd->dev.of_node;
> + return dev_of_node(&mtd->dev);
> }
>
> static inline int mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 14/37] mtd: nand: denali: support "nand-ecc-strength" DT property
From: Boris Brezillon @ 2017-03-31 9:46 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, Enrico Jorns, Artem Bityutskiy, Dinh Nguyen,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, devicetree, Linux Kernel Mailing List,
Brian Norris, Richard Weinberger, Cyrille Pitchen, Rob Herring,
Mark Rutland
In-Reply-To: <CAK7LNARUKwMHd79ALDx_SDY9XKcHPY96xTAOMQx6XarFgwb-AA@mail.gmail.com>
On Fri, 31 Mar 2017 14:06:32 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi Boris,
>
>
> 2017-03-30 23:02 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>:
> > On Thu, 30 Mar 2017 15:46:00 +0900
> > Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> >
> >> Historically, this driver tried to choose as big ECC strength as
> >> possible, but it would be reasonable to allow DT to set a particular
> >> ECC strength with "nand-ecc-strength" property. This is useful
> >> when a particular ECC setting is hard-coded by firmware (or hard-
> >> wired by boot ROM).
> >>
> >> If no ECC strength is specified in DT, "nand-ecc-maximize" is implied
> >> since this was the original behavior.
> >
> > You said there is currently no DT users,
>
> Right. No DT users ever in upstream.
>
>
> > so how about changing the
> > "fallback to ECC maximization" behavior for DT users, and instead of
> > maximizing the ECC strength take the NAND requirements into account
> > (chip->ecc_strength_ds).
>
> This is difficult to judge in some cases.
>
> As I said before, 4/512 and 8/1024 are not equivalent.
>
> If chip's requirement chip->ecc_step_ds matches
> to the ecc->size supported by the controller,
> this is easy.
>
>
> If a chip requests 1024B, then the controller can only support 512B chunk
> (or vice versa), it is difficult to simply compare
> ecc strength.
You can try something like that when no explicit ecc.strength and
ecc.size has been set in the DT and when ECC_MAXIMIZE was not passed.
static int
denali_get_closest_ecc_strength(struct denali_nand_info *denali,
int strength)
{
/*
* Whatever you need to select a strength that is greater than
* or equal to strength.
*/
return X;
}
static int denali_try_to_match_ecc_req(struct denali_nand_info *denali)
{
struct nand_chip *chip = &denali->nand;
struct mtd_info *mtd = nand_to_mtd(chip);
int max_ecc_bytes = mtd->oobsize - denali->bbtskipbytes;
int ecc_steps, ecc_strength, ecc_bytes;
int ecc_size = chip->ecc_step_ds;
int ecc_strength = chip->ecc_strength_ds;
/*
* No information provided by the NAND chip, let the core
* maximize the strength.
*/
if (!ecc_size || !ecc_strength)
return -ENOTSUPP;
if (ecc_size > 512)
ecc_size = 1024;
else
ecc_size = 512;
/* Adjust ECC step size based on hardware support. */
if (ecc_size == 1024 &&
!(denali->caps & DENALI_CAP_ECC_SIZE_1024))
ecc_size = 512;
else if(ecc_size == 512 &&
!(denali->caps & DENALI_CAP_ECC_SIZE_512))
ecc_size = 1024;
if (ecc_size < chip->ecc_size_ds) {
/*
* When the selected size if smaller than the expected
* one we try to use the same strength but on 512 blocks
* so that we can still fix the same number of errors
* even if they are concentrated in the first 512bytes
* of a 1024bytes portion.
*/
ecc_strength = chip->ecc_strength_ds;
ecc_strength = denali_get_closest_ecc_strength(denali,
ecc_strength);
} else {
/* Always prefer 1024bytes ECC blocks when possible. */
if (ecc_size != 1024 &&
(denali->caps & DENALI_CAP_ECC_SIZE_1024) &&
mtd->writesize > 1024)
ecc_size = 1024;
/*
* Adjust the strength based on the selected ECC step
* size.
*/
ecc_strength = DIV_ROUND_UP(ecc_size,
chip->ecc_step_ds) *
chip->ecc_strength_ds;
}
ecc_bytes = denali_calc_ecc_bytes(ecc_size,
ecc_strength);
ecc_bytes *= mtd->writesize / ecc_size;
/*
* If we don't have enough space, let the core maximize
* the strength.
*/
if (ecc_bytes > max_ecc_bytes)
return -ENOTSUPP;
chip->ecc.strength = ecc_strength;
chip->ecc.size = ecc_size;
return 0;
}
>
> Is it a bad thing if we use too strong ECC strength?
>
> The disadvantage I see is we will have less OOB-free bytes,
> but this will not be fatal, I guess.
Not a bad thing in general, but I'd prefer to leave the choice to the
user. If one doesn't need the extra-safety brought by ECC strength
maximization and wants to have more OOB bytes it's better to follow
NAND requirements.
^ permalink raw reply
* Re: [PATCH v6 2/2] arm64: dts: move from ARCH_VULCAN to ARCH_THUNDER2
From: Arnd Bergmann @ 2017-03-31 9:44 UTC (permalink / raw)
To: Jayachandran C
Cc: arm-soc, Linux ARM, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Florian Fainelli, Matthias Brugger
In-Reply-To: <1489495634-2920-3-git-send-email-jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On Tue, Mar 14, 2017 at 1:47 PM, Jayachandran C
<jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
> Move and update device tree files as part of transition from Broadcom
> Vulcan to Cavium ThunderX2.
>
> The changes are to:
> * rename dts/broadcom/vulcan.dtsi to cavium/thunder2-99xx.dtsi,
> update cpu cores to be "cavium,thunder2", and update SoC to be
> "cavium,thunderx2-cn9900"
> * move SoC dts/broadcom/vulcan-eval.dtsi to cavium/thunder2-99xx.dtsi
> and update board name string
> * Update dts/broadcom/Makefile not to build vulcan dtbs
> * Update dts/cavium/Makefile to build thunder2 dtbs
>
> No changes to the dts contents except the updated "compatible" and
> "model" properties.
>
> Signed-off-by: Jayachandran C <jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Reviewed-by: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied to next/dt64.
The contents are fine, but I'd recommend using 'git format-patch -M'
when creating a submission for easier review, in case you do another
patch with a rename in the future.
Arnd
--
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 1/3] dt-bindings: Add arm64 ARCH_THUNDER2 platform documentation
From: Arnd Bergmann @ 2017-03-31 9:40 UTC (permalink / raw)
To: Jayachandran C
Cc: arm-soc, Linux ARM, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Florian Fainelli, Matthias Brugger
In-Reply-To: <1489608662-4434-2-git-send-email-jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On Wed, Mar 15, 2017 at 9:11 PM, Jayachandran C
<jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
> Add documentation for Cavium's ThunderX2 CN99XX ARM64 processor. This
> SoC will use "cavium,thunderx2-cn9900" as the compatible property.
>
> Also add a documentation entry for the "cavium,thunder2" cpu core
> present in these SoCs.
>
> Signed-off-by: Jayachandran C <jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Applied on next/dt64, thanks!
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 2/2] dt-bindings: mtd: document linux,part-probe property
From: Rafał Miłecki @ 2017-03-31 9:30 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170331093013.29123-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Support for this property has been introduced in 2010 with commit
9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
parition probe") but it was never documented. Fix this by adding a
proper description and example.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
index fc068b923d7a..1ada70e718b2 100644
--- a/Documentation/devicetree/bindings/mtd/common.txt
+++ b/Documentation/devicetree/bindings/mtd/common.txt
@@ -6,10 +6,17 @@ Optional properties:
controller based name) in order to ease flash device identification
and/or describe what they are used for.
+- linux,part-probe: if present, this property should contain a list of strings
+ with partition probes to be used for the flash device. A role of partition
+ probe (parser) is to read/construct partition table and register found
+ partitions. Getting partition table may be platform or device specific so
+ various devices may use various Linux drivers for this purpose.
+
Example:
flash@0 {
label = "System-firmware";
+ linux,part-probe = "cmdlinepart", "ofpart";
/* flash type specific properties */
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 1/2] mtd: move code reading DT specified part probes to the core
From: Rafał Miłecki @ 2017-03-31 9:30 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170330215332.32699-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Handling (creating) partitions for flash devices requires using a proper
driver that will read partition table (out of somewhere). We can't
simply try all existing drivers one by one, so MTD subsystem allows
drivers to specify a list of applicable part probes.
So far physmap_of was the only driver with support for linux,part-probe
DT property. Other ones had list or probes hardcoded which wasn't making
them really flexible. It prevented using common flash drivers on
platforms that required some specific partition table access.
This commit moves support for mentioned DT property to the MTD core
file. Thanks to calling it on device parse registration (as suggested by
Boris) all drivers gain support for it for free.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
drivers/mtd/maps/physmap_of.c | 36 +-----------------------------------
drivers/mtd/mtdcore.c | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 62fa6836f218..49dbb7235848 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -114,37 +114,9 @@ static struct mtd_info *obsolete_probe(struct platform_device *dev,
static const char * const part_probe_types_def[] = {
"cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
-static const char * const *of_get_probes(struct device_node *dp)
-{
- const char **res;
- int count;
-
- count = of_property_count_strings(dp, "linux,part-probe");
- if (count < 0)
- return part_probe_types_def;
-
- res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
- if (!res)
- return NULL;
-
- count = of_property_read_string_array(dp, "linux,part-probe", res,
- count);
- if (count < 0)
- return NULL;
-
- return res;
-}
-
-static void of_free_probes(const char * const *probes)
-{
- if (probes != part_probe_types_def)
- kfree(probes);
-}
-
static const struct of_device_id of_flash_match[];
static int of_flash_probe(struct platform_device *dev)
{
- const char * const *part_probe_types;
const struct of_device_id *match;
struct device_node *dp = dev->dev.of_node;
struct resource res;
@@ -310,14 +282,8 @@ static int of_flash_probe(struct platform_device *dev)
info->cmtd->dev.parent = &dev->dev;
mtd_set_of_node(info->cmtd, dp);
- part_probe_types = of_get_probes(dp);
- if (!part_probe_types) {
- err = -ENOMEM;
- goto err_out;
- }
- mtd_device_parse_register(info->cmtd, part_probe_types, NULL,
+ mtd_device_parse_register(info->cmtd, part_probe_types_def, NULL,
NULL, 0);
- of_free_probes(part_probe_types);
kfree(mtd_list);
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 66a9dedd1062..a7ab0a24ba1e 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -664,6 +664,32 @@ static void mtd_set_dev_defaults(struct mtd_info *mtd)
}
}
+static const char * const *mtd_of_get_probes(struct device_node *np)
+{
+ const char **res;
+ int count;
+
+ count = of_property_count_strings(np, "linux,part-probe");
+ if (count < 0)
+ return NULL;
+
+ res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
+ if (!res)
+ return NULL;
+
+ count = of_property_read_string_array(np, "linux,part-probe", res,
+ count);
+ if (count < 0)
+ return NULL;
+
+ return res;
+}
+
+static inline void mtd_of_free_probes(const char * const *probes)
+{
+ kfree(probes);
+}
+
/**
* mtd_device_parse_register - parse partitions and register an MTD device.
*
@@ -698,11 +724,16 @@ int mtd_device_parse_register(struct mtd_info *mtd, const char * const *types,
const struct mtd_partition *parts,
int nr_parts)
{
+ const char * const *part_probe_types;
struct mtd_partitions parsed;
int ret;
mtd_set_dev_defaults(mtd);
+ part_probe_types = mtd_of_get_probes(mtd_get_of_node(mtd));
+ if (!part_probe_types)
+ part_probe_types = types;
+
memset(&parsed, 0, sizeof(parsed));
ret = parse_mtd_partitions(mtd, types, &parsed, parser_data);
@@ -720,6 +751,9 @@ int mtd_device_parse_register(struct mtd_info *mtd, const char * const *types,
memset(&parsed, 0, sizeof(parsed));
}
+ if (part_probe_types != types)
+ mtd_of_free_probes(part_probe_types);
+
ret = mtd_add_device_partitions(mtd, &parsed);
if (ret)
goto out;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Jacek Anaszewski @ 2017-03-31 9:28 UTC (permalink / raw)
To: Pavel Machek, Bjorn Andersson
Cc: Rob Herring, Richard Purdie, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170330074309.GA28533@amd>
Hi Bjorn and Pavel,
On 03/30/2017 09:43 AM, Pavel Machek wrote:
> Hi!
>
>>>> There is a binding for ti,lp55xx, but there's nothing I can reuse from
>>>> that binding...because it's completely different hardware.
>>>
>>> Agreed, if you drop the pattern stuff from the binding, at least for now.
>>
>> I do not have a strong preference to expose these knobs in devicetree
>> and I do fear that finding some common "pattern" bindings that suits
>> everyone will be very difficult.
>>
>> So I'll drop them from the binding for now.
>
> Ok.
>
>>> If you want driver merged quickly, I believe the best way would be to
>>> leave out pattern support for now. We can merge the basic driver
>>> easily to 4.12.
>>>
>>
>> I'm not that much in a hurry and would rather see that we resolve any
>> outstanding issues with the implementation of the pattern handling.
>
> Ok, good.
>
>> But regardless of this we still have the problem that the typical
>> Qualcomm PMIC has 8 LPG-blocks and any triple could be driving a
>> RGB-LED. So we would have to create some sort of in-driver-wrapper
>> around any three instances exposing them as a single LED to the user.
>
> Yes, I believe we should do the wrapping. In N900 case,
>
>> I rather expose the individual channels and make sure that when we
>> trigger a blink operation or enable a pattern (i.e. the two operations
>> that do require synchronization) we will perform that synchronization
>> under the hood.
>
> First, we need a way to tell userspace which LEDs are synchronized,
> because otherwise it will be confusing.
There is one year old discussion [0] about the possible approaches
to RGB sub-LEDs synchronization problem and patterns in general.
My last message with API design proposal has been left unanswered.
Probably we continue that discussion here.
Generally Bjorn's drivers touch two yet to be addressed issues:
- RGB LED support
- Generic support for patterns
It is likely that both issues can be solved by utilizing trigger
mechanism. The possible solution to the problem Bjorn tried to
address with /sys/class/leds/<led>/pattern comma separated list
could be a trigger with adjustable number of pattern intervals.
The trigger once activated would create a directory with the
number of files corresponding to the number of requested intervals,
and then user could write an interval value by writing it to the
corresponding file. Somehow related approach has been implemented
for USB port LED trigger:
0f247626cbbf ('usb: core: Introduce a USB port LED trigger")
In both RGB and pattern approaches we should assess
if it is acceptable to provide a pattern for trigger name,
e.g. blink-pattern-{num_intervals}.
If so, then "echo transition-pattern-15" would create a directory
e.g. transition_intervals with files interval_0 to interval_14,
that could be adjusted by userspace.
> Second, there are more issues than just patterns with the RGB
> LED. Most important is ability to set particular colors. You want to
> set the RGB LED to "white", but that does not mean you can set
> red=green=blue=1.0. You want color to look the same on LCD and on the
> LED, which means coefficients for white and some kind of function for
> brightness-to-PWM conversion.
Shouldn't we leave that entirely to the userspace? Can we come up
with coefficients that will guarantee the same result on all existing
LCD devices?
>>> Incremental patches sound like a good idea, yes.
>>>
>>> I'd say that testing with actual RGB LED is not a requirement... as
>>> long as we design reasonable interface where the synchronizaction will
>>> be easy.
>>>
>>
>> As this relates to the board layout (which LPG-channels are hooked to a
>> RGB) I think it makes sense to expose a mechanism in devicetree to
>> indicate which channels should have their pattern/blink synchronized.
>>
>> We should be able to extend the LUT (the hardware that actually
>> implements the pattern-walker logic) with a DT-property like:
>>
>> qcom,synchronize-group-0 = <1, 2, 3>;
>> qcom,synchronize-group-1 = <5, 6, 7>;
>>
>> And whenever we configure a pattern involving one of the affected LEDs
>> from a group we start all of them.
>
> Yes we need some kind of grouping.
>
> Additional complexity in the N900 case... groups can actually be
> configured at run time. Original Maemo used that ability to group 6
> keyboard backlight leds, and then run pattern on them. OTOH... I don't
> think we _need_ to support that functionality.
>
> Best regards,
> Pavel
>
[0] https://lkml.org/lkml/2016/4/18/179
--
Best regards,
Jacek Anaszewski
--
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] drm: rcar-du: Document the vsps property in the DT bindings
From: Geert Uytterhoeven @ 2017-03-31 9:21 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Laurent Pinchart, Sergei Shtylyov,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
DRI Development, Linux-Renesas
In-Reply-To: <8105647.ANSr0hWnZy@avalon>
Hi Laurent,
On Fri, Mar 31, 2017 at 11:19 AM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
>> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
>> > The property is used by the driver but is missing from the DT bindings.
>> > Document it.
>> >
>> > Reported-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
>> > Signed-off-by: Laurent Pinchart
>> > <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>> > ---
>> > Documentation/devicetree/bindings/display/renesas,du.txt | 5 +++++
>> > 1 file changed, 5 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
>> > 1a02f099a0ff..cf34893a1b53 100644
>> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>> >
>> > @@ -36,6 +36,11 @@ Required Properties:
>> > When supplied they must be named "dclkin.x" with "x" being the
>> > input
>> > clock numerical index.
>> >
>> > +Optional Properties:
>> > +
>> > + - vsps: A list of phandles to the VSP nodes that handle the memory
>> > + interfaces for the DU channels (Gen3 only).
>>
>> ", one per channel"?
>>
>> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
>
> How about making it mandatory on Gen2 as well ? The VSPs are there, even if
> the driver doesn't use them, it makes sense to describe the connection. Of
Fine for me, as this is hardware description.
> course the driver will treat the property as optional for backward
> compatibility.
OK.
Disclaimer: I didn't follow the discussion about using or not using the vsps
on Gen2 that closely, and don't remember the outcome.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] drm: rcar-du: Document the vsps property in the DT bindings
From: Laurent Pinchart @ 2017-03-31 9:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart, Sergei Shtylyov, devicetree@vger.kernel.org,
DRI Development, Linux-Renesas
In-Reply-To: <CAMuHMdUiDzGt6bz96D-5yRLF-HiZfpQTTxKP5Y4+j-9HiF1LLQ@mail.gmail.com>
Hi Geert,
On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
> > The property is used by the driver but is missing from the DT bindings.
> > Document it.
> >
> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >
> > Documentation/devicetree/bindings/display/renesas,du.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
> > 1a02f099a0ff..cf34893a1b53 100644
> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> >
> > @@ -36,6 +36,11 @@ Required Properties:
> > When supplied they must be named "dclkin.x" with "x" being the
> > input
> > clock numerical index.
> >
> > +Optional Properties:
> > +
> > + - vsps: A list of phandles to the VSP nodes that handle the memory
> > + interfaces for the DU channels (Gen3 only).
>
> ", one per channel"?
>
> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
How about making it mandatory on Gen2 as well ? The VSPs are there, even if
the driver doesn't use them, it makes sense to describe the connection. Of
course the driver will treat the property as optional for backward
compatibility.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] mtd: use dev_of_node helper in mtd_get_of_node
From: Rafał Miłecki @ 2017-03-31 9:11 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger
Cc: Cyrille Pitchen, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This allows better compile-time optimizations with CONFIG_OF disabled.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
include/linux/mtd/mtd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index eebdc63cf6af..f8db5b2e4028 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -393,7 +393,7 @@ static inline void mtd_set_of_node(struct mtd_info *mtd,
static inline struct device_node *mtd_get_of_node(struct mtd_info *mtd)
{
- return mtd->dev.of_node;
+ return dev_of_node(&mtd->dev);
}
static inline int mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [Patch v3 02/11] [media] s5p-mfc: Adding initial support for MFC v10.10
From: Smitha T Murthy @ 2017-03-31 9:06 UTC (permalink / raw)
To: linux-arm-kernel, linux-media, linux-kernel
Cc: kyungmin.park, kamil, jtp.park, a.hajda, mchehab, pankaj.dubey,
krzk, m.szyprowski, s.nawrocki, Smitha T Murthy, Rob Herring,
devicetree
In-Reply-To: <1490951200-32070-1-git-send-email-smitha.t@samsung.com>
Adding the support for MFC v10.10, with new register file and
necessary hw control, decoder, encoder and structural changes.
CC: Rob Herring <robh+dt@kernel.org>
CC: devicetree@vger.kernel.org
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/media/s5p-mfc.txt | 1 +
drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 36 ++++++++++++++++++++++
drivers/media/platform/s5p-mfc/s5p_mfc.c | 30 ++++++++++++++++++
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 9 +++++-
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 4 +++
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 32 ++++++++-----------
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 16 ++++------
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 9 ++++--
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 2 ++
9 files changed, 106 insertions(+), 33 deletions(-)
create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 2c90128..b83727b 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -13,6 +13,7 @@ Required properties:
(c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
(d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
(e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
+ (f) "samsung,mfc-v10" for MFC v10 present in Exynos7880 SoC
- reg : Physical base address of the IP registers and length of memory
mapped region.
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
new file mode 100644
index 0000000..1ca09d6
--- /dev/null
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
@@ -0,0 +1,36 @@
+/*
+ * Register definition file for Samsung MFC V10.x Interface (FIMV) driver
+ *
+ * Copyright (c) 2017 Samsung Electronics Co., Ltd.
+ * http://www.samsung.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.
+ */
+
+#ifndef _REGS_MFC_V10_H
+#define _REGS_MFC_V10_H
+
+#include <linux/sizes.h>
+#include "regs-mfc-v8.h"
+
+/* MFCv10 register definitions*/
+#define S5P_FIMV_MFC_CLOCK_OFF_V10 0x7120
+#define S5P_FIMV_MFC_STATE_V10 0x7124
+
+/* MFCv10 Context buffer sizes */
+#define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)
+#define MFC_H264_DEC_CTX_BUF_SIZE_V10 (2 * SZ_1M)
+#define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K)
+#define MFC_H264_ENC_CTX_BUF_SIZE_V10 (100 * SZ_1K)
+#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)
+
+/* MFCv10 variant defines */
+#define MAX_FW_SIZE_V10 (SZ_1M)
+#define MAX_CPB_SIZE_V10 (3 * SZ_1M)
+#define MFC_VERSION_V10 0xA0
+#define MFC_NUM_PORTS_V10 1
+
+#endif /*_REGS_MFC_V10_H*/
+
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index c6f0754..443ff7e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1547,6 +1547,33 @@ static struct s5p_mfc_variant mfc_drvdata_v8_5433 = {
.num_clocks = 3,
};
+static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
+ .dev_ctx = MFC_CTX_BUF_SIZE_V10,
+ .h264_dec_ctx = MFC_H264_DEC_CTX_BUF_SIZE_V10,
+ .other_dec_ctx = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
+ .h264_enc_ctx = MFC_H264_ENC_CTX_BUF_SIZE_V10,
+ .other_enc_ctx = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
+};
+
+static struct s5p_mfc_buf_size buf_size_v10 = {
+ .fw = MAX_FW_SIZE_V10,
+ .cpb = MAX_CPB_SIZE_V10,
+ .priv = &mfc_buf_size_v10,
+};
+
+static struct s5p_mfc_buf_align mfc_buf_align_v10 = {
+ .base = 0,
+};
+
+static struct s5p_mfc_variant mfc_drvdata_v10 = {
+ .version = MFC_VERSION_V10,
+ .version_bit = MFC_V10_BIT,
+ .port_num = MFC_NUM_PORTS_V10,
+ .buf_size = &buf_size_v10,
+ .buf_align = &mfc_buf_align_v10,
+ .fw_name[0] = "s5p-mfc-v10.fw",
+};
+
static const struct of_device_id exynos_mfc_match[] = {
{
.compatible = "samsung,mfc-v5",
@@ -1563,6 +1590,9 @@ static const struct of_device_id exynos_mfc_match[] = {
}, {
.compatible = "samsung,exynos5433-mfc",
.data = &mfc_drvdata_v8_5433,
+ }, {
+ .compatible = "samsung,mfc-v10",
+ .data = &mfc_drvdata_v10,
},
{},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index b45d18c..3a4ca55 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -23,7 +23,7 @@
#include <media/v4l2-ioctl.h>
#include <media/videobuf2-v4l2.h>
#include "regs-mfc.h"
-#include "regs-mfc-v8.h"
+#include "regs-mfc-v10.h"
#define S5P_MFC_NAME "s5p-mfc"
@@ -723,11 +723,18 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq);
#define IS_MFCV6_PLUS(dev) (dev->variant->version >= 0x60 ? 1 : 0)
#define IS_MFCV7_PLUS(dev) (dev->variant->version >= 0x70 ? 1 : 0)
#define IS_MFCV8_PLUS(dev) (dev->variant->version >= 0x80 ? 1 : 0)
+#define IS_MFCV10(dev) (dev->variant->version >= 0xA0 ? 1 : 0)
#define MFC_V5_BIT BIT(0)
#define MFC_V6_BIT BIT(1)
#define MFC_V7_BIT BIT(2)
#define MFC_V8_BIT BIT(3)
+#define MFC_V10_BIT BIT(5)
+#define MFC_V5PLUS_BITS (MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT | \
+ MFC_V8_BIT | MFC_V10_BIT)
+#define MFC_V6PLUS_BITS (MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT | \
+ MFC_V10_BIT)
+#define MFC_V7PLUS_BITS (MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT)
#endif /* S5P_MFC_COMMON_H_ */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 484af6b..0ded23c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -267,6 +267,10 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
}
else
mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
+
+ if (IS_MFCV10(dev))
+ mfc_write(dev, 0x0, S5P_FIMV_MFC_CLOCK_OFF_V10);
+
mfc_debug(2, "Will now wait for completion of firmware transfer\n");
if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_FW_STATUS_RET)) {
mfc_err("Failed to load firmware\n");
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 0ec2928..db6d9fa 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -54,7 +54,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
{
.name = "4:2:0 2 Planes Y/CrCb",
@@ -62,7 +62,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
{
.name = "H264 Encoded Stream",
@@ -70,8 +70,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H264_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "H264/MVC Encoded Stream",
@@ -79,7 +78,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H264_MVC_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
{
.name = "H263 Encoded Stream",
@@ -87,8 +86,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H263_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "MPEG1 Encoded Stream",
@@ -96,8 +94,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG2_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "MPEG2 Encoded Stream",
@@ -105,8 +102,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG2_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "MPEG4 Encoded Stream",
@@ -114,8 +110,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG4_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "XviD Encoded Stream",
@@ -123,8 +118,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG4_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "VC1 Encoded Stream",
@@ -132,8 +126,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_VC1_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "VC1 RCV Encoded Stream",
@@ -141,8 +134,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_VC1RCV_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "VP8 Encoded Stream",
@@ -150,7 +142,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_VP8_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index e39d9e0..e81b359 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -57,8 +57,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "4:2:0 2 Planes Y/CrCb",
@@ -66,7 +65,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
{
.name = "H264 Encoded Stream",
@@ -74,8 +73,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H264_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "MPEG4 Encoded Stream",
@@ -83,8 +81,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG4_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "H263 Encoded Stream",
@@ -92,8 +89,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H263_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "VP8 Encoded Stream",
@@ -101,7 +97,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_VP8_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V7PLUS_BITS,
},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 7682b0e..9dc106e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -358,6 +358,7 @@ static int calc_plane(int width, int height)
static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
{
+ struct s5p_mfc_dev *dev = ctx->dev;
ctx->buf_width = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
ctx->buf_height = ALIGN(ctx->img_height, S5P_FIMV_NV12MT_VALIGN_V6);
mfc_debug(2, "SEQ Done: Movie dimensions %dx%d,\n"
@@ -374,8 +375,12 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
ctx->codec_mode == S5P_MFC_CODEC_H264_MVC_DEC) {
- ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V6(ctx->img_width,
- ctx->img_height);
+ if (IS_MFCV10(dev))
+ ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V10(ctx->img_width,
+ ctx->img_height);
+ else
+ ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V6(ctx->img_width,
+ ctx->img_height);
ctx->mv_size = ALIGN(ctx->mv_size, 16);
} else {
ctx->mv_size = 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
index 8055848..021b8db 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
@@ -24,6 +24,8 @@
#define MB_HEIGHT(y_size) DIV_ROUND_UP(y_size, 16)
#define S5P_MFC_DEC_MV_SIZE_V6(x, y) (MB_WIDTH(x) * \
(((MB_HEIGHT(y)+1)/2)*2) * 64 + 128)
+#define S5P_MFC_DEC_MV_SIZE_V10(x, y) (MB_WIDTH(x) * \
+ (((MB_HEIGHT(y)+1)/2)*2) * 64 + 512)
/* Definition */
#define ENC_MULTI_SLICE_MB_MAX ((1 << 30) - 1)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v5 4/9] coresight: refactor with function of_coresight_get_cpu
From: Suzuki K Poulose @ 2017-03-31 9:05 UTC (permalink / raw)
To: Leo Yan, Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Michael Turquette, Stephen Boyd, Mathieu Poirier, Guodong Xu,
John Stultz, linux-doc, linux-kernel, devicetree,
linux-arm-kernel, linux-arm-msm, linux-soc, linux-clk, mike.leach,
sudeep.ho
In-Reply-To: <1490466197-29163-5-git-send-email-leo.yan@linaro.org>
On 25/03/17 18:23, Leo Yan wrote:
> This is refactor to add function of_coresight_get_cpu(), so it's used to
> retrieve CPU id for coresight component. Finally can use it as a common
> function for multiple places.
>
> Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> - if (found)
> - break;
> - }
> - of_node_put(dn);
> -
> - /* Affinity to CPU0 if no cpu nodes are found */
> - pdata->cpu = found ? cpu : 0;
> + pdata->cpu = of_coresight_get_cpu(node);
>
> return pdata;
> }
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index 2a5982c..bf96678 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -263,9 +263,11 @@ static inline int coresight_timeout(void __iomem *addr, u32 offset,
> #endif
>
> #ifdef CONFIG_OF
> +extern int of_coresight_get_cpu(struct device_node *node);
> extern struct coresight_platform_data *of_get_coresight_platform_data(
> struct device *dev, struct device_node *node);
> #else
> +static inline int of_coresight_get_cpu(struct device_node *node) { return 0; }
> static inline struct coresight_platform_data *of_get_coresight_platform_data(
> struct device *dev, struct device_node *node) { return NULL; }
> #endif
>
^ permalink raw reply
* Re: [PATCH v5 1/9] coresight: bindings for CPU debug module
From: Suzuki K Poulose @ 2017-03-31 9:04 UTC (permalink / raw)
To: Leo Yan, Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Michael Turquette, Stephen Boyd, Mathieu Poirier, Guodong Xu,
John Stultz, linux-doc, linux-kernel, devicetree,
linux-arm-kernel, linux-arm-msm, linux-soc, linux-clk, mike.leach,
sudeep.ho
In-Reply-To: <1490466197-29163-2-git-send-email-leo.yan@linaro.org>
On 25/03/17 18:23, Leo Yan wrote:
> According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
> Chapter 'Part H: External debug', the CPU can integrate debug module
> and it can support self-hosted debug and external debug. Especially
> for supporting self-hosted debug, this means the program can access
> the debug module from mmio region; and usually the mmio region is
> integrated with coresight.
>
> So add document for binding debug component, includes binding to APB
> clock; and also need specify the CPU node which the debug module is
> dedicated to specific CPU.
>
> Suggested-by: Mike Leach <mike.leach@linaro.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
From: Cyrille Pitchen @ 2017-03-31 8:56 UTC (permalink / raw)
To: Guochun Mao, Marek Vasut
Cc: Boris Brezillon, Mark Rutland, devicetree, Richard Weinberger,
Russell King, linux-kernel, Rob Herring, linux-mtd,
Matthias Brugger, linux-mediatek, Cyrille Pitchen,
David Woodhouse, linux-arm-kernel
In-Reply-To: <1490927207.7262.7.camel@mhfsdcap03>
Le 31/03/2017 à 04:26, Guochun Mao a écrit :
> Hi Cyrille, Marek,
>
> Thanks for your suggestions.
>
> On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
>> Hi Guochun,
>>
>> Le 30/03/2017 à 10:23, Guochun Mao a écrit :
>>> when nor's size larger than 16MByte, nor and controller should
>>> enter 4Byte mode simultaneously.
>>>
>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
>>> ---
>>> drivers/mtd/spi-nor/mtk-quadspi.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> index e661877..05cd8a8 100644
>>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
>>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>>> /* We only handle 1 byte */
>>> ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
>>> break;
>>> + case SPINOR_OP_EN4B:
>>> + /* Set nor controller to 4-byte address mode,
>>> + * and simultaneously set nor flash.
>>> + * This case should cooperate with default operation.
>>> + */
>>> + writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
>>> + mt8173_nor->base + MTK_NOR_DUAL_REG);
>>
>> This is not good: you should check in both mt8173_nor_read() and
>> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
>>
>> from include/linux/mtd/spi-nor.h:
>> * @addr_width: number of address bytes
>>
>> Besides SPI commands using an op code from 4-byte address instruction
>> set always carry a 4-byte address. They can be used directly, without
>> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
>> will be 4-byte long only if your SPI controller driver has seen a
>> SPINOR_OP_EN4B command before. This assumption is wrong.
> Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
> modified in later process.
> Does it means that we will not switch nor between 3Byte address and
> 4Byte?
> So, is it better to check nor->addr_width when do nor initialization?
>
Currently yes, nor->addr_width, nor->read_opcode, nor->read_dummy, and
nor->program_opcode are set once for all in spi_nor_scan().
However, nor->read() is likely to be called soon from spi_nor_scan()
with values of nor->addr_width, nor->read_opcode and nor->read_dummy
different from those selected when exiting spi_nor_scan().
So nor->read() / mt8173_nor_read should check nor->addr_width,
nor->read_opcode and nor->read_dummy at each call.
More precisely, I plan to use nor->read() from spi_nor_scan() to read
SFDP (Serial Flash Discoverable Parameters) data.
Whatever op code, numbers of address bytes and dummy cycles used for
(Fast) Read commands, the Read SFDP command uses fixed settings
standardized for all manufacturers and all memory parts:
- op code: 5Ah
- number of bytes for the address: 3 (even for memory > 128Mbits)
- number of dummy clock cycles: 8 clocks
https://patchwork.ozlabs.org/patch/742380/
Please have a look at the spi_nor_read_sfdp().
spi_nor_read_sfdp() is likely to be called from and only from
spi_nor_scan().
Best regards,
Cyrille
>>
>> SPI controller driver should never check SPINOR_OP_* op codes like this.
> I agree that SPI controller driver should not check SPINOR_OP_* op codes
> like what I do.
> I will correct it next version.
>
> Best Regards,
> Guochun
>>
>> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
>> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
>> op codes may change depending on the memory manufacturer. So testing op
>> code values like you do can work with some memories but maybe not all.
>>
>> Finally, don't use 0x10, please define a macro instead.
>>
>> Best regards,
>>
>> Cyrille
>>
>>> default:
>>> ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
>>> if (ret)
>>>
>>
>
>
>
^ permalink raw reply
* Device Tree Binding for Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong @ 2017-03-31 8:50 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
Hi Rob,
I would like to upstream the attached device tree binding patch to the
community. This is required for the support of framebuffer drivers of
the Intel FPGA Video and Image Processing Suite intended for the
Arria10 devkit.
The device tree information includes the maximum width and height
supported by the framebuffer display. These are fixed parameters
determined by the use who the Quartus design system to program the
FPGA in the Arria10 devkit and its variants.
BR
Hean Loong
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Intel-FPGA-Video-and-Image-Processing-Suite-device-t.patch --]
[-- Type: text/x-patch; name="0001-Intel-FPGA-Video-and-Image-Processing-Suite-device-t.patch", Size: 1918 bytes --]
From 23a9e274bb517b8e232c5aa4cf9737de1644b708 Mon Sep 17 00:00:00 2001
From: Ong, Hean Loong <hean.loong.ong@intel.com>
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@intel.com>
---
.../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
^ permalink raw reply related
* [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register
From: Neil Armstrong @ 2017-03-31 8:47 UTC (permalink / raw)
To: khilman, carlo
Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <1490950079-10145-1-git-send-email-narmstrong@baylibre.com>
Add node for the Amlogic Meson GX SoC information register.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 886efa5..c8e42d4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -357,6 +357,11 @@
#reset-cells = <1>;
};
+ chipid@220 {
+ compatible = "amlogic,meson-gx-socinfo";
+ reg = <0x0 0x00220 0x0 0x4>;
+ };
+
uart_AO: serial@4c0 {
compatible = "amlogic,meson-uart";
reg = <0x0 0x004c0 0x0 0x14>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
From: Neil Armstrong @ 2017-03-31 8:47 UTC (permalink / raw)
To: khilman, carlo
Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <1490950079-10145-1-git-send-email-narmstrong@baylibre.com>
Add bindings for the SoC information register of the Amlogic SoCs.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
index bfd5b55..b850985 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -52,3 +52,23 @@ Board compatible values:
- "amlogic,q201" (Meson gxm s912)
- "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
- "nexbox,a1" (Meson gxm s912)
+
+Amlogic Meson GX SoCs Information
+----------------------------------
+
+The Meson SoCs have a Product Register that allows to retrieve SoC type,
+package and revision information. If present, a device node for this register
+should be added.
+
+Required properties:
+ - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
+ - reg: Base address and length of the register block.
+
+Examples
+--------
+
+ chipid@220 {
+ compatible = "amlogic,meson-gx-socinfo";
+ reg = <0x0 0x00220 0x0 0x4>;
+ };
+
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 4/6] arm64: dts: rockchip: add core dtsi file for RK3328 SoCs
From: Shawn Lin @ 2017-03-31 8:27 UTC (permalink / raw)
To: cl
Cc: heiko, robh+dt, mark.rutland, zhengxing, andy.yan, jay.xu,
matthias.bgg, paweljarosz3691, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, wsa, linux-i2c, jic23, knaack.h,
lars, pmeerw, wxt, david.wu, linux-iio, akpm, dianders,
yamada.masahiro, catalin.marinas, will.deacon, afaerber, shawnguo,
khilman, arnd, fabio.estevam, zhangqing, kever.yang
In-Reply-To: <1490607650-18650-4-git-send-email-cl@rock-chips.com>
Hi Liang,
On 2017/3/27 17:40, cl@rock-chips.com wrote:
> From: Liang Chen <cl@rock-chips.com>
>
> This patch adds core dtsi file for Rockchip RK3328 SoCs.
>
> Signed-off-by: Liang Chen <cl@rock-chips.com>
> ---
----8<------
> +
> + sdmmc1 {
> + sdmmc1_clk: sdmmc1-clk {
> + rockchip,pins =
> + <1 RK_PB4 1 &pcfg_pull_none_8ma>;
> + };
> +
> + sdmmc1_cmd: sdmmc1-cmd {
> + rockchip,pins = <1 RK_PB5 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_pwren: sdmmc1-pwren {
> + rockchip,pins = <1 RK_PC2 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_wrprt: sdmmc1-wrprt {
> + rockchip,pins = <1 RK_PC4 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_dectn: sdmmc1-dectn {
> + rockchip,pins = <1 RK_PC3 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_bus1: sdmmc1-bus1 {
> + rockchip,pins = <1 RK_PB6 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_bus4: sdmmc1-bus4 {
> + rockchip,pins = <1 RK_PB4 1 &pcfg_pull_up_8ma>,
> + <1 RK_PB5 1 &pcfg_pull_up_8ma>,
I'm pretty sure this isn't correct as sdmmc1_bus1 even doesn't contain
one same pinctrl(data0) as sdmmc1_bus4. So, the first two pins should be
"1 RK_PB6" and "1 RK_PB7".....
> + <1 RK_PC0 1 &pcfg_pull_up_8ma>,
> + <1 RK_PC1 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_gpio: sdmmc1-gpio {
> + rockchip,pins =
> + <1 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PB7 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC0 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_up_4ma>;
> + };
> + };
> +
> + emmc {
> + emmc_clk: emmc-clk {
> + rockchip,pins =
> + <3 RK_PC5 2 &pcfg_pull_none_12ma>;
> + };
> +
> + emmc_cmd: emmc-cmd {
> + rockchip,pins =
> + <3 RK_PC3 2 &pcfg_pull_up_12ma>;
> + };
> +
> + emmc_pwren: emmc-pwren {
> + rockchip,pins = <3 RK_PC6 2 &pcfg_pull_none>;
> + };
> +
> + emmc_rstnout: emmc-rstnout {
> + rockchip,pins = <3 RK_PC4 2 &pcfg_pull_none>;
> + };
> +
> + emmc_bus1: emmc-bus1 {
> + rockchip,pins =
> + <0 RK_PA7 2 &pcfg_pull_up_12ma>;
> + };
> +
> + emmc_bus4: emmc-bus4 {
> + rockchip,pins =
> + <0 RK_PA7 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD4 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD5 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD6 2 &pcfg_pull_up_12ma>;
> + };
> +
> + emmc_bus8: emmc-bus8 {
> + rockchip,pins =
> + <0 RK_PA7 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD4 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD5 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD6 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD7 2 &pcfg_pull_up_12ma>,
> + <3 RK_PC0 2 &pcfg_pull_up_12ma>,
> + <3 RK_PC1 2 &pcfg_pull_up_12ma>,
> + <3 RK_PC2 2 &pcfg_pull_up_12ma>;
> + };
> + };
> +
> + pwm0 {
> + pwm0_pin: pwm0-pin {
> + rockchip,pins = <2 RK_PA4 1 &pcfg_pull_none>;
> + };
> + };
> +
> + pwm1 {
> + pwm1_pin: pwm1-pin {
> + rockchip,pins = <2 RK_PA5 1 &pcfg_pull_none>;
> + };
> + };
> +
> + pwm2 {
> + pwm2_pin: pwm2-pin {
> + rockchip,pins = <2 RK_PA6 1 &pcfg_pull_none>;
> + };
> + };
> +
> + pwmir {
> + pwmir_pin: pwmir-pin {
> + rockchip,pins = <2 RK_PA2 1 &pcfg_pull_none>;
> + };
> + };
> +
> + gmac-1 {
> + rgmiim1_pins: rgmiim1-pins {
> + rockchip,pins =
> + /* mac_txclk */
> + <1 RK_PB4 2 &pcfg_pull_none_12ma>,
> + /* mac_rxclk */
> + <1 RK_PB5 2 &pcfg_pull_none_2ma>,
> + /* mac_mdio */
> + <1 RK_PC3 2 &pcfg_pull_none_2ma>,
> + /* mac_txen */
> + <1 RK_PD1 2 &pcfg_pull_none_12ma>,
> + /* mac_clk */
> + <1 RK_PC5 2 &pcfg_pull_none_2ma>,
> + /* mac_rxdv */
> + <1 RK_PC6 2 &pcfg_pull_none_2ma>,
> + /* mac_mdc */
> + <1 RK_PC7 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd1 */
> + <1 RK_PB2 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd0 */
> + <1 RK_PB3 2 &pcfg_pull_none_2ma>,
> + /* mac_txd1 */
> + <1 RK_PB0 2 &pcfg_pull_none_12ma>,
> + /* mac_txd0 */
> + <1 RK_PB1 2 &pcfg_pull_none_12ma>,
> + /* mac_rxd3 */
> + <1 RK_PB6 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd2 */
> + <1 RK_PB7 2 &pcfg_pull_none_2ma>,
> + /* mac_txd3 */
> + <1 RK_PC0 2 &pcfg_pull_none_12ma>,
> + /* mac_txd2 */
> + <1 RK_PC1 2 &pcfg_pull_none_12ma>,
> +
> + /* mac_txclk */
> + <0 RK_PB0 1 &pcfg_pull_none>,
> + /* mac_txen */
> + <0 RK_PB4 1 &pcfg_pull_none>,
> + /* mac_clk */
> + <0 RK_PD0 1 &pcfg_pull_none>,
> + /* mac_txd1 */
> + <0 RK_PC0 1 &pcfg_pull_none>,
> + /* mac_txd0 */
> + <0 RK_PC1 1 &pcfg_pull_none>,
> + /* mac_txd3 */
> + <0 RK_PC7 1 &pcfg_pull_none>,
> + /* mac_txd2 */
> + <0 RK_PC6 1 &pcfg_pull_none>;
> + };
> +
> + rmiim1_pins: rmiim1-pins {
> + rockchip,pins =
> + /* mac_mdio */
> + <1 RK_PC3 2 &pcfg_pull_none_2ma>,
> + /* mac_txen */
> + <1 RK_PD1 2 &pcfg_pull_none_12ma>,
> + /* mac_clk */
> + <1 RK_PC5 2 &pcfg_pull_none_2ma>,
> + /* mac_rxer */
> + <1 RK_PD0 2 &pcfg_pull_none_2ma>,
> + /* mac_rxdv */
> + <1 RK_PC6 2 &pcfg_pull_none_2ma>,
> + /* mac_mdc */
> + <1 RK_PC7 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd1 */
> + <1 RK_PB2 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd0 */
> + <1 RK_PB3 2 &pcfg_pull_none_2ma>,
> + /* mac_txd1 */
> + <1 RK_PB0 2 &pcfg_pull_none_12ma>,
> + /* mac_txd0 */
> + <1 RK_PB1 2 &pcfg_pull_none_12ma>,
> +
> + /* mac_mdio */
> + <0 RK_PB3 1 &pcfg_pull_none>,
> + /* mac_txen */
> + <0 RK_PB4 1 &pcfg_pull_none>,
> + /* mac_clk */
> + <0 RK_PD0 1 &pcfg_pull_none>,
> + /* mac_mdc */
> + <0 RK_PC3 1 &pcfg_pull_none>,
> + /* mac_txd1 */
> + <0 RK_PC0 1 &pcfg_pull_none>,
> + /* mac_txd0 */
> + <0 RK_PC1 1 &pcfg_pull_none>;
> + };
> + };
> +
> + gmac2phy {
> + fephyled_speed100: fephyled-speed100 {
> + rockchip,pins = <0 RK_PD7 1 &pcfg_pull_none>;
> + };
> +
> + fephyled_speed10: fephyled-speed10 {
> + rockchip,pins = <0 RK_PD6 1 &pcfg_pull_none>;
> + };
> +
> + fephyled_duplex: fephyled-duplex {
> + rockchip,pins = <0 RK_PD6 2 &pcfg_pull_none>;
> + };
> +
> + fephyled_rxm0: fephyled-rxm0 {
> + rockchip,pins = <0 RK_PD5 1 &pcfg_pull_none>;
> + };
> +
> + fephyled_txm0: fephyled-txm0 {
> + rockchip,pins = <0 RK_PD5 2 &pcfg_pull_none>;
> + };
> +
> + fephyled_linkm0: fephyled-linkm0 {
> + rockchip,pins = <0 RK_PD4 1 &pcfg_pull_none>;
> + };
> +
> + fephyled_rxm1: fephyled-rxm1 {
> + rockchip,pins = <2 RK_PD1 2 &pcfg_pull_none>;
> + };
> +
> + fephyled_txm1: fephyled-txm1 {
> + rockchip,pins = <2 RK_PD1 3 &pcfg_pull_none>;
> + };
> +
> + fephyled_linkm1: fephyled-linkm1 {
> + rockchip,pins = <2 RK_PD0 2 &pcfg_pull_none>;
> + };
> + };
> +
> + tsadc_pin {
> + tsadc_int: tsadc-int {
> + rockchip,pins = <2 RK_PB5 2 &pcfg_pull_none>;
> + };
> + tsadc_gpio: tsadc-gpio {
> + rockchip,pins =
> + <2 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + hdmi_pin {
> + hdmi_cec: hdmi-cec {
> + rockchip,pins = <0 RK_PA3 1 &pcfg_pull_none>;
> + };
> +
> + hdmi_hpd: hdmi-hpd {
> + rockchip,pins = <0 RK_PA4 1 &pcfg_pull_down>;
> + };
> + };
> +
> + cif-0 {
> + dvp_d2d9_m0:dvp-d2d9-m0 {
> + rockchip,pins =
> + /* cif_d0 */
> + <3 RK_PA4 2 &pcfg_pull_none>,
> + /* cif_d1 */
> + <3 RK_PA5 2 &pcfg_pull_none>,
> + /* cif_d2 */
> + <3 RK_PA6 2 &pcfg_pull_none>,
> + /* cif_d3 */
> + <3 RK_PA7 2 &pcfg_pull_none>,
> + /* cif_d4 */
> + <3 RK_PB0 2 &pcfg_pull_none>,
> + /* cif_d5m0 */
> + <3 RK_PB1 2 &pcfg_pull_none>,
> + /* cif_d6m0 */
> + <3 RK_PB2 2 &pcfg_pull_none>,
> + /* cif_d7m0 */
> + <3 RK_PB3 2 &pcfg_pull_none>,
> + /* cif_href */
> + <3 RK_PA1 2 &pcfg_pull_none>,
> + /* cif_vsync */
> + <3 RK_PA0 2 &pcfg_pull_none>,
> + /* cif_clkoutm0 */
> + <3 RK_PA3 2 &pcfg_pull_none>,
> + /* cif_clkin */
> + <3 RK_PA2 2 &pcfg_pull_none>;
> + };
> + };
> +
> + cif-1 {
> + dvp_d2d9_m1:dvp-d2d9-m1 {
> + rockchip,pins =
> + /* cif_d0 */
> + <3 RK_PA4 2 &pcfg_pull_none>,
> + /* cif_d1 */
> + <3 RK_PA5 2 &pcfg_pull_none>,
> + /* cif_d2 */
> + <3 RK_PA6 2 &pcfg_pull_none>,
> + /* cif_d3 */
> + <3 RK_PA7 2 &pcfg_pull_none>,
> + /* cif_d4 */
> + <3 RK_PB0 2 &pcfg_pull_none>,
> + /* cif_d5m1 */
> + <2 RK_PC0 4 &pcfg_pull_none>,
> + /* cif_d6m1 */
> + <2 RK_PC1 4 &pcfg_pull_none>,
> + /* cif_d7m1 */
> + <2 RK_PC2 4 &pcfg_pull_none>,
> + /* cif_href */
> + <3 RK_PA1 2 &pcfg_pull_none>,
> + /* cif_vsync */
> + <3 RK_PA0 2 &pcfg_pull_none>,
> + /* cif_clkoutm1 */
> + <2 RK_PB7 4 &pcfg_pull_none>,
> + /* cif_clkin */
> + <3 RK_PA2 2 &pcfg_pull_none>;
> + };
> + };
> + };
> +};
>
^ permalink raw reply
* Re: [PATCH v3 00/37] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb
From: Boris Brezillon @ 2017-03-31 8:27 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, Enrico Jorns, Artem Bityutskiy, Dinh Nguyen,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, devicetree, Linux Kernel Mailing List,
Brian Norris, Richard Weinberger, Cyrille Pitchen, Rob Herring,
Mark Rutland
In-Reply-To: <CAK7LNATUyc821uQTECkkQj2SDKkbrioFfHVsttnsnc8QuT1P-A@mail.gmail.com>
On Fri, 31 Mar 2017 13:05:20 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi Boris,
>
>
> 2017-03-31 1:38 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>:
>
> > The rest looks almost good, except for a few comments I had on patch
> > 14, 18, 25, 26 and 32.
> >
> > I'll probably apply 33 and 34 soon.
> >
>
> Thank you!
> Please note I left a minor comment on 34.
> (Accidental addition of braces.)
Yep, I noticed. Applied both after fixing the alignment and removing
unneeded braces in patch 34.
Thanks,
Boris
^ permalink raw reply
* Re: [PATCH] mtd: physmap_of: use OF helpers for reading strings
From: Boris Brezillon @ 2017-03-31 8:02 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Linus Walleij, Jason Gunthorpe,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170330155853.30349-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 30 Mar 2017 17:58:53 +0200
Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> OF core code provides helpers for counting strings and reading them so
> use them instead of doing this manually. This simplifies the code a bit.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Reviewed-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> drivers/mtd/maps/physmap_of.c | 30 ++++++++++--------------------
> 1 file changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
> index 14e8909c9955..62fa6836f218 100644
> --- a/drivers/mtd/maps/physmap_of.c
> +++ b/drivers/mtd/maps/physmap_of.c
> @@ -116,32 +116,22 @@ static const char * const part_probe_types_def[] = {
>
> static const char * const *of_get_probes(struct device_node *dp)
> {
> - const char *cp;
> - int cplen;
> - unsigned int l;
> - unsigned int count;
> const char **res;
> + int count;
>
> - cp = of_get_property(dp, "linux,part-probe", &cplen);
> - if (cp == NULL)
> + count = of_property_count_strings(dp, "linux,part-probe");
> + if (count < 0)
> return part_probe_types_def;
>
> - count = 0;
> - for (l = 0; l != cplen; l++)
> - if (cp[l] == 0)
> - count++;
> -
> - res = kzalloc((count + 1)*sizeof(*res), GFP_KERNEL);
> + res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
> if (!res)
> return NULL;
> - count = 0;
> - while (cplen > 0) {
> - res[count] = cp;
> - l = strlen(cp) + 1;
> - cp += l;
> - cplen -= l;
> - count++;
> - }
> +
> + count = of_property_read_string_array(dp, "linux,part-probe", res,
> + count);
> + if (count < 0)
> + return NULL;
> +
> return res;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] mtd: move code reading DT specified part probes to the common place
From: Boris Brezillon @ 2017-03-31 7:55 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Frank Rowand,
Linus Walleij, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170331094213.055149e1@bbrezillon>
On Fri, 31 Mar 2017 09:42:13 +0200
Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Rafal,
>
> On Thu, 30 Mar 2017 23:53:31 +0200
> Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> >
> > Handling (creating) partitions for flash devices requires using a proper
> > driver that will read partition table (out of somewhere). We can't
> > simply try all existing drivers one by one, so MTD subsystem allows
> > drivers to specify a list of applicable part probes.
> >
> > So far physmap_of was the only driver with support for linux,part-probe
> > DT property. Other ones had list or probes hardcoded which wasn't making
> > them really flexible. It prevented using common flash drivers on
> > platforms that required some specific partition table access.
>
> I agree that having each flash device driver specify the set of
> partition parsers it supports is a bad idea (most of the time,
> partition table format are devicetype agnostic). On the other hand, I'm
> not a big fan of this property, and I would prefer a solution where all
> parsers are tested on each MTD device.
> But testing all parsers sequentially is not a perfect solution either
> because it increases boot-time and you can't really define the order in
> which partition parsers are tested (which means that if you have 2
> different partition table in 2 different format, you can't choose the
> one that has precedence on the other).
>
> I guess I can live with this "linux,part-probe" property, even if,
> as the names implies, it's not really describing hardware, and as
> such, does not have its place in DT :-P.
>
> >
> > This commit moves support for mentioned DT property to the common place
> > so it can be reused by other drivers.
>
> This property does not seem to be documented. Can you add a patch
> documenting it in Documentation/devicetree/bindings/mtd/common.txt and
> Cc the DT maintainers.
Please ignore this comment, it's already done in patch 2 :).
> Only then we'll see if this property is
> acceptable for them.
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] mtd: move code reading DT specified part probes to the common place
From: Boris Brezillon @ 2017-03-31 7:42 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Frank Rowand,
Linus Walleij, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170330215332.32699-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Rafal,
On Thu, 30 Mar 2017 23:53:31 +0200
Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Handling (creating) partitions for flash devices requires using a proper
> driver that will read partition table (out of somewhere). We can't
> simply try all existing drivers one by one, so MTD subsystem allows
> drivers to specify a list of applicable part probes.
>
> So far physmap_of was the only driver with support for linux,part-probe
> DT property. Other ones had list or probes hardcoded which wasn't making
> them really flexible. It prevented using common flash drivers on
> platforms that required some specific partition table access.
I agree that having each flash device driver specify the set of
partition parsers it supports is a bad idea (most of the time,
partition table format are devicetype agnostic). On the other hand, I'm
not a big fan of this property, and I would prefer a solution where all
parsers are tested on each MTD device.
But testing all parsers sequentially is not a perfect solution either
because it increases boot-time and you can't really define the order in
which partition parsers are tested (which means that if you have 2
different partition table in 2 different format, you can't choose the
one that has precedence on the other).
I guess I can live with this "linux,part-probe" property, even if,
as the names implies, it's not really describing hardware, and as
such, does not have its place in DT :-P.
>
> This commit moves support for mentioned DT property to the common place
> so it can be reused by other drivers.
This property does not seem to be documented. Can you add a patch
documenting it in Documentation/devicetree/bindings/mtd/common.txt and
Cc the DT maintainers. Only then we'll see if this property is
acceptable for them.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> This patch is based on top of
> [PATCH] mtd: physmap_of: use OF helpers for reading strings
> ---
> drivers/mtd/maps/physmap_of.c | 39 ++++++---------------------------------
> drivers/of/Kconfig | 6 ++++++
> drivers/of/Makefile | 1 +
> drivers/of/of_mtd.c | 30 ++++++++++++++++++++++++++++++
> include/linux/of_mtd.h | 25 +++++++++++++++++++++++++
No please, don't add these files back. If you need specific OF helpers
for the MTD subsystem, put them in drivers/mtd/mtdcore.c or
drivers/mtd/of.c if you think it really deserves a dedicated file (but
given the number of lines you add, I'm not sure it's the case).
> 5 files changed, 68 insertions(+), 33 deletions(-)
> create mode 100644 drivers/of/of_mtd.c
> create mode 100644 include/linux/of_mtd.h
>
> diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
> index 62fa6836f218..fa54c07eb118 100644
> --- a/drivers/mtd/maps/physmap_of.c
> +++ b/drivers/mtd/maps/physmap_of.c
> @@ -22,6 +22,7 @@
> #include <linux/mtd/concat.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <linux/of_mtd.h>
> #include <linux/of_platform.h>
> #include <linux/slab.h>
> #include "physmap_of_gemini.h"
> @@ -114,33 +115,6 @@ static struct mtd_info *obsolete_probe(struct platform_device *dev,
> static const char * const part_probe_types_def[] = {
> "cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
>
> -static const char * const *of_get_probes(struct device_node *dp)
> -{
> - const char **res;
> - int count;
> -
> - count = of_property_count_strings(dp, "linux,part-probe");
> - if (count < 0)
> - return part_probe_types_def;
> -
> - res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
> - if (!res)
> - return NULL;
> -
> - count = of_property_read_string_array(dp, "linux,part-probe", res,
> - count);
> - if (count < 0)
> - return NULL;
> -
> - return res;
> -}
> -
> -static void of_free_probes(const char * const *probes)
> -{
> - if (probes != part_probe_types_def)
> - kfree(probes);
> -}
> -
> static const struct of_device_id of_flash_match[];
> static int of_flash_probe(struct platform_device *dev)
> {
> @@ -310,14 +284,13 @@ static int of_flash_probe(struct platform_device *dev)
>
> info->cmtd->dev.parent = &dev->dev;
> mtd_set_of_node(info->cmtd, dp);
> - part_probe_types = of_get_probes(dp);
> - if (!part_probe_types) {
> - err = -ENOMEM;
> - goto err_out;
> - }
> + part_probe_types = of_mtd_get_probes(dp);
> + if (!part_probe_types)
> + part_probe_types = part_probe_types_def;
Let's automate that a bit. The OF node is attached to the MTD device
when you call mtd_set_of_node(), so you have everything you need to
extract the partition parser list in mtd_device_parse_register().
If you do that, all MTD drivers would gain "linux,part-probe" support
for free.
> mtd_device_parse_register(info->cmtd, part_probe_types, NULL,
> NULL, 0);
> - of_free_probes(part_probe_types);
> + if (part_probe_types != part_probe_types_def)
> + of_mtd_free_probes(part_probe_types);
>
> kfree(mtd_list);
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index ba7b034b2b91..18ac835a1ce4 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -78,6 +78,12 @@ config OF_MDIO
> help
> OpenFirmware MDIO bus (Ethernet PHY) accessors
>
> +config OF_MTD
> + def_tristate MTD
> + depends on MTD
> + help
> + OpenFirmware MTD accessors
> +
> config OF_PCI
> def_tristate PCI
> depends on PCI
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index d7efd9d458aa..965c2a691337 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_OF_IRQ) += irq.o
> obj-$(CONFIG_OF_NET) += of_net.o
> obj-$(CONFIG_OF_UNITTEST) += unittest.o
> obj-$(CONFIG_OF_MDIO) += of_mdio.o
> +obj-$(CONFIG_OF_MTD) += of_mtd.o
> obj-$(CONFIG_OF_PCI) += of_pci.o
> obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
> obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
> diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
> new file mode 100644
> index 000000000000..ff851d7742d5
> --- /dev/null
> +++ b/drivers/of/of_mtd.c
> @@ -0,0 +1,30 @@
> +/*
> + * 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/of.h>
> +#include <linux/of_mtd.h>
> +
> +const char * const *of_mtd_get_probes(struct device_node *np)
> +{
> + const char **res;
> + int count;
> +
> + count = of_property_count_strings(np, "linux,part-probe");
> + if (count < 0)
> + return NULL;
> +
> + res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
> + if (!res)
> + return NULL;
> +
> + count = of_property_read_string_array(np, "linux,part-probe", res,
> + count);
> + if (count < 0)
> + return NULL;
> +
> + return res;
> +}
> +EXPORT_SYMBOL(of_mtd_get_probes);
> diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
> new file mode 100644
> index 000000000000..d55f4aa684c5
> --- /dev/null
> +++ b/include/linux/of_mtd.h
> @@ -0,0 +1,25 @@
> +#ifndef __OF_MTD_H
> +#define __OF_MTD_H
> +
> +#include <linux/slab.h>
> +
> +struct device_node;
> +
> +#ifdef CONFIG_OF_MTD
> +const char * const *of_mtd_get_probes(struct device_node *np);
> +static inline void of_mtd_free_probes(const char * const *probes)
> +{
> + kfree(probes);
> +}
> +#else
> +const char * const *of_mtd_get_probes(struct device_node *np)
> +{
> + return NULL;
> +}
> +
> +static inline void of_mtd_free_probes(const char * const *probes)
> +{
> +}
> +#endif
> +
> +#endif
--
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] ARM: dts: armada-38x: label USB and SATA nodes
From: Ralph Sennhauser @ 2017-03-31 7:41 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Ralph Sennhauser, Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Recently most nodes got labels to make them referenceable. The USB 3.0
nodes as well as the nodes for the SATA controllers were left out,
rectify the omission.
Signed-off-by: Ralph Sennhauser <ralph.sennhauser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Hi everybody
In preparation to add support for the Linksys WRT3200ACM (Rango) some
rework of the "dts-stack" is highly desirable. This patch is part of the
preparatory work but independent.
The label for the USB 2.0 port is "usb0:", so using "usb1:" and "usb2:"
would be the logical continuation. Guess you realized the catch already,
"usb2:" for an USB 3.0 controller might be very confusing.
I'm sending this patch ahead of the rest so the labels can be discussed
and finalized.
Ralph
---
arch/arm/boot/dts/armada-38x.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index ba27ec1..78c838a 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -530,7 +530,7 @@
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
};
- sata@a8000 {
+ satac0: sata@a8000 {
compatible = "marvell,armada-380-ahci";
reg = <0xa8000 0x2000>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
@@ -546,7 +546,7 @@
status = "disabled";
};
- sata@e0000 {
+ satac1: sata@e0000 {
compatible = "marvell,armada-380-ahci";
reg = <0xe0000 0x2000>;
interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
@@ -590,7 +590,7 @@
status = "disabled";
};
- usb3@f0000 {
+ usb3_0: usb3@f0000 {
compatible = "marvell,armada-380-xhci";
reg = <0xf0000 0x4000>,<0xf4000 0x4000>;
interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
@@ -598,7 +598,7 @@
status = "disabled";
};
- usb3@f8000 {
+ usb3_1: usb3@f8000 {
compatible = "marvell,armada-380-xhci";
reg = <0xf8000 0x4000>,<0xfc000 0x4000>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
--
2.10.2
--
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: r7s72100: fix ethernet clock parent
From: Geert Uytterhoeven @ 2017-03-31 7:41 UTC (permalink / raw)
To: Chris Brandt
Cc: Simon Horman, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <20170330211609.598-1-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Thu, Mar 30, 2017 at 11:16 PM, Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> Technically, the Ethernet block is run off the 133MHz Bus (B) clock, not
> the 33MHz Peripheral 0 (P0) clock.
>
> Fixes: 969244f9c720 ("ARM: dts: r7s72100: add ethernet clock to device tree")
> Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v5 9/9] dt-bindings: phy-mt65xx-usb: add support for new version phy
From: Chunfeng Yun @ 2017-03-31 7:35 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Matthias Brugger, Felipe Balbi, Rob Herring, Mark Rutland,
Ian Campbell, Chunfeng Yun, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490945735-9531-1-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
add a new compatible string for "mt2712", and move reference clock
into each port node;
Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/phy/phy-mt65xx-usb.txt | 93 +++++++++++++++++---
1 file changed, 80 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
index 33a2b1e..0acc5a9 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -6,12 +6,11 @@ This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
Required properties (controller (parent) node):
- compatible : should be one of
"mediatek,mt2701-u3phy"
+ "mediatek,mt2712-u3phy"
"mediatek,mt8173-u3phy"
- - reg : offset and length of register for phy, exclude port's
- register.
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain
+ - clocks : (deprecated, use port's clocks instead) a list of phandle +
+ clock-specifier pairs, one for each entry in clock-names
+ - clock-names : (deprecated, use port's one instead) must contain
"u3phya_ref": for reference clock of usb3.0 analog phy.
Required nodes : a sub-node is required for each port the controller
@@ -19,8 +18,19 @@ Required nodes : a sub-node is required for each port the controller
'reg' property is used inside these nodes to describe
the controller's topology.
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register. It is needed on mt2701
+ and mt8173, but not on mt2712.
+
Required properties (port (child) node):
- reg : address and length of the register set for the port.
+- clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names : must contain
+ "ref": 48M reference clock for HighSpeed analog phy; and 26M
+ reference clock for SuperSpeed analog phy, sometimes is
+ 24M, 25M or 27M, depended on platform.
- #phy-cells : should be 1 (See second example)
cell after port phandle is phy type from:
- PHY_TYPE_USB2
@@ -31,21 +41,31 @@ Example:
u3phy: usb-phy@11290000 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x11290000 0 0x800>;
- clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
- clock-names = "u3phya_ref";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "okay";
- phy_port0: port@11290800 {
- reg = <0 0x11290800 0 0x800>;
+ u2port0: usb-phy@11290800 {
+ reg = <0 0x11290800 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
- phy_port1: port@11291000 {
- reg = <0 0x11291000 0 0x800>;
+ u3port0: usb-phy@11290900 {
+ reg = <0 0x11290800 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u2port1: usb-phy@11291000 {
+ reg = <0 0x11291000 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref";
#phy-cells = <1>;
status = "okay";
};
@@ -64,7 +84,54 @@ Example:
usb30: usb@11270000 {
...
- phys = <&phy_port0 PHY_TYPE_USB3>;
- phy-names = "usb3-0";
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+ phy-names = "usb2-0", "usb3-0";
...
};
+
+
+Layout differences of banks between mt8173/mt2701 and mt2712
+-------------------------------------------------------------
+mt8173 and mt2701:
+port offset bank
+shared 0x0000 SPLLC
+ 0x0100 FMREG
+u2 port0 0x0800 U2PHY_COM
+u3 port0 0x0900 U3PHYD
+ 0x0a00 U3PHYD_BANK2
+ 0x0b00 U3PHYA
+ 0x0c00 U3PHYA_DA
+u2 port1 0x1000 U2PHY_COM
+u3 port1 0x1100 U3PHYD
+ 0x1200 U3PHYD_BANK2
+ 0x1300 U3PHYA
+ 0x1400 U3PHYA_DA
+u2 port2 0x1800 U2PHY_COM
+ ...
+
+mt2712:
+port offset bank
+u2 port0 0x0000 MISC
+ 0x0100 FMREG
+ 0x0300 U2PHY_COM
+u3 port0 0x0700 SPLLC
+ 0x0800 CHIP
+ 0x0900 U3PHYD
+ 0x0a00 U3PHYD_BANK2
+ 0x0b00 U3PHYA
+ 0x0c00 U3PHYA_DA
+u2 port1 0x1000 MISC
+ 0x1100 FMREG
+ 0x1300 U2PHY_COM
+u3 port1 0x1700 SPLLC
+ 0x1800 CHIP
+ 0x1900 U3PHYD
+ 0x1a00 U3PHYD_BANK2
+ 0x1b00 U3PHYA
+ 0x1c00 U3PHYA_DA
+u2 port2 0x2000 MISC
+ ...
+
+ SPLLC shared by u3 ports and FMREG shared by u2 ports on
+mt8173/mt2701 are put back into each port; a new bank MISC for
+u2 ports and CHIP for u3 ports are added on mt2712.
--
1.7.9.5
--
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
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