* Re: [PATCH 17/22] power: supply: add battery driver for AXP20X and AXP22X PMICs
From: Quentin Schulz @ 2017-01-06 8:29 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Rutland, devicetree, Lars-Peter Clausen, open list:THERMAL,
linux-iio, linux-kernel, Sebastian Reichel, Russell King,
Bruno Prémont, Rob Herring, linux-arm-kernel,
Peter Meerwald-Stadler, knaack.h, Maxime Ripard, Lee Jones,
Thomas Petazzoni, Jonathan Cameron, Icenowy Zheng
In-Reply-To: <CAGb2v66XnWOGcaLeRo+cb6NGqfm_cyJVoK+GURUo5iV4pdZzew@mail.gmail.com>
Hi,
On 06/01/2017 04:39, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Jan 3, 2017 at 12:37 AM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
[...]
>> + case POWER_SUPPLY_PROP_CURRENT_MAX:
>> + ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
>> + if (ret)
>> + return ret;
>> +
>> + reg &= AXP20X_CHRG_CTRL1_TGT_CURR;
>> + val->intval = reg * 100000 + 300000;
>> + break;
>
>
> This controls the charge current. I believe the correct property to use
> is CONSTANT_CHARGE_CURRENT. And you should add CONSTANT_CHARGE_CURRENT_MAX
> which returns the highest possible setting.
>
ACK.
> Also letting the user control this might not always be a good idea.
> IIUC, LiPo batteries can only be charged at 1C, where C is the
> rated capacity (X mAh).
>
OK. Should I get the charge current from a DT property then?
Like "x-powers,charge-current = <300000>;"
It's close to what has been done in bq24257_charger for example.
[...]
>> +static enum power_supply_property axp20x_battery_props[] = {
>> + POWER_SUPPLY_PROP_PRESENT,
>> + POWER_SUPPLY_PROP_ONLINE,
>> + POWER_SUPPLY_PROP_STATUS,
>> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
>> + POWER_SUPPLY_PROP_CURRENT_NOW,
>> + POWER_SUPPLY_PROP_CURRENT_MAX,
>> + POWER_SUPPLY_PROP_HEALTH,
>> + POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
>> + POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
>> + POWER_SUPPLY_PROP_CAPACITY,
>
> You can also add POWER_SUPPLY_PROP_TECHNOLOGY, which would return
> POWER_SUPPLY_TECHNOLOGY_LIPO.
>
Hum.. There are also POWER_SUPPLY_TECHNOLOGY_LION,
POWER_SUPPLY_TECHNOLOGY_LiFe and POWER_SUPPLY_TECHNOLOGY_LiMn which are
all Lithium-based batteries. From the datasheet, it can take a "single
cell Li-battery (Li-Ion/Polymer)". So I guess it's either
POWER_SUPPLY_TECHNOLOGY_LION or POWER_SUPPLY_TECHNOLOGY_LIPO.
> It is also possible to do POWER_SUPPLY_PROP_CHARGE_TYPE. According
> to the manual, if the battery is charging, it is in constant current
> mode (POWER_SUPPLY_CHARGE_TYPE_FAST) when V_battery < V_target.
> When V_battery == V_target, it is in constant voltage mode, though
> I don't think this is the same as POWER_SUPPLY_CHARGE_TYPE_TRICKLE.
> When it is not charging, you can return POWER_SUPPLY_CHARGE_TYPE_NONE.
>
ACK, I'll look into that.
Thanks,
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Inki Dae @ 2017-01-06 8:36 UTC (permalink / raw)
To: Andi Shyti
Cc: linux-samsung-soc, cw00.choi, devicetree, Donghwa Lee,
linux-kernel, krzk, jh80.chung, kgene, dri-devel, Hyungwon Hwang,
Hoegeun Kwon
In-Reply-To: <20170106081806.h4y7o57kjbibau6l@gangnam.samsung>
2017년 01월 06일 17:18에 Andi Shyti 이(가) 쓴 글:
> Hi Inki,
>
> Thanks for the reply, but...
>
>>>> +static const struct drm_display_mode default_mode = {
>>>> + .clock = 222372,
>>>> + .hdisplay = 1440,
>>>> + .hsync_start = 1440 + 1,
>>>> + .hsync_end = 1440 + 1 + 1,
>>>> + .htotal = 1440 + 1 + 1 + 1,
>>>> + .vdisplay = 2560,
>>>> + .vsync_start = 2560 + 1,
>>>> + .vsync_end = 2560 + 1 + 1,
>>>> + .vtotal = 2560 + 1 + 1 + 15,
>>>> + .vrefresh = 60,
>>>> + .flags = 0,
>>>> +};
>>>
>>> how is this working with tm2e? Are these values valid for both
>>> the boards?
>>
>> We don't need to consider tm2e board with two reasones,
>> 1. there is no tm2e board support in mainline
>> 2. the panel on tm2 would be a little bit different from one on tm2e
>
> ... this display in the Tizen Kernel is supported by both:
> tm2 [1] and tm2e [2]. The only differences are:
Why tm2e dts file is in mainline? Seems communication miss with Chanwoo. :(
>
> TM2:
> clock-frequency = <14874444>;
> hactive = <1440>;
>
> TM2E:
> clock-frequency = <16523724>;
> hactive = <1600>;
>
> I don't know much about the differences you mention in point 2,
> but it's a pity to drop support only because we don't want to put
> in the dts the 'hactive', and 'clock-frequency' properties.
Anyway, tm2e board is already in mainline so Panel driver may need to identify what kinds of panel is probed to decide porch values. I think there are relevant registers in MCU of the Panel device to check version or similar thing.
Thanks.
>
> Andi
>
> [1] https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts?h=tizen#n1284
> [2] https://git.tizen.org/cgit/platform/kernel/linux-exynos/tree/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts?h=tizen#n1270
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Krzysztof Kozlowski @ 2017-01-06 8:37 UTC (permalink / raw)
To: Andi Shyti
Cc: Krzysztof Kozlowski, Jaechul Lee, Dmitry Torokhov, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Kukjin Kim,
Javier Martinez Canillas, Chanwoo Choi, beomho.seo, galaxyra,
linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc
In-Reply-To: <20170106075914.y5nuak3bz3zrvvex@gangnam.samsung>
On Fri, Jan 06, 2017 at 04:59:14PM +0900, Andi Shyti wrote:
> Hi,
>
> On Fri, Jan 06, 2017 at 09:09:11AM +0200, Krzysztof Kozlowski wrote:
> > On Fri, Jan 06, 2017 at 12:59:06PM +0900, Jaechul Lee wrote:
> > > From: Andi Shyti <andi.shyti@samsung.com>
> > >
> > > Currently tm2e dts includes tm2 but there are some differences
> > > between the two boards and tm2 has some properties that tm2e
> > > doesn't have.
> > >
> > > That's why it's important to keep the two dts files independent
> > > and put all the commonalities in a tm2-common.dtsi file.
> > >
> > > At the current status the only two differences between the two
> > > dts files (besides the board name) are ldo31 and ldo38.
> > >
> > > Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> > > Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> > > ---
> > > .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1118 +++++++++++++++++++
> > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1153 +-------------------
> >
> > Like talking to a wall. Without any feedback. If my instructions were
> > wrong (and it is not possible to detect rename) then please say it (you
> > can add personal comments after separator ---).
>
> no Krzysztof, I'm sorry, but this patch has been formatted with
> the diff algorithm *you* asked, -B50% both version 2 (where you
> didn't comment) and version 3. If you still don't like it, please
> don't blame me, blame the algorithm.
If you wrote it in cover letter or after '---' I wouldn't complain
because I would know that my feedback was ignored. But here it is like
black hole - I do not know whether I was ignored or it was not working.
>
> Now we can stay here at trying random diff algorithms (as they
> give more or less the same result) or you tell me which exact
> algorithm you want me to use. Besides, for me it's clear,
> tm2-common is all new, while in tm2 you have on one side the '-'
> (if it applies nothing has changed) on the bottom the '+'.
Maybe that depends on the git?
$ git --version
git version 2.9.3
$ git format-patch -2 -B50%
...
21 ...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 24 +-
22 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1153 +-------------------
23 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 22 +-
24 3 files changed, 56 insertions(+), 1143 deletions(-)
25 copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (98%)
26 rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCHv3 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Chris Packham @ 2017-01-06 8:41 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, Mark Rutland, Jason Cooper, Andrew Lunn,
Gregory Clement, Sebastian Hesselbarth, Russell King, Chris Brand,
Florian Fainelli, Geert Uytterhoeven, Lorenzo Pieralisi,
Jayachandran C, Juri Lelli, Magnus Damm, Thierry Reding,
Sudeep Holla, devicetree-u79uwXL29TY
In-Reply-To: <20170106063602.GM17126@codeaurora.org>
On 06/01/17 19:44, Stephen Boyd wrote:
> On 01/06, Chris Packham wrote:
>> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
>> index 46c742d3bd41..3c9ab9a008ad 100644
>> --- a/arch/arm/mach-mvebu/platsmp.c
>> +++ b/arch/arm/mach-mvebu/platsmp.c
>> @@ -182,5 +182,48 @@ const struct smp_operations armada_xp_smp_ops __initconst = {
>> #endif
>> };
>>
>> +static int mv98dx3236_boot_secondary(unsigned int cpu, struct task_struct *idle)
>> +{
>> + int ret, hw_cpu;
>> +
>> + pr_info("Booting CPU %d\n", cpu);
>
> Doesn't the core already print something when bringing up CPUs?
> This message seems redundant.
>
Copied from armada_xp_boot_secondary but that's no reason to keep it.
Will remove in v4.
>> +
>> + hw_cpu = cpu_logical_map(cpu);
>> + set_secondary_cpu_clock(hw_cpu);
>> + mv98dx3236_resume_set_cpu_boot_addr(hw_cpu,
>> + armada_xp_secondary_startup);
>> +
>> + /*
>> + * This is needed to wake up CPUs in the offline state after
>> + * using CPU hotplug.
>> + */
>> + arch_send_wakeup_ipi_mask(cpumask_of(cpu));
>> +
>> + /*
>> + * This is needed to take secondary CPUs out of reset on the
>> + * initial boot.
>> + */
>> + ret = mvebu_cpu_reset_deassert(hw_cpu);
>> + if (ret) {
>> + pr_warn("unable to boot CPU: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +struct smp_operations mv98dx3236_smp_ops __initdata = {
>
> static const __initconst?
>
Will do.
>> + .smp_init_cpus = armada_xp_smp_init_cpus,
>> + .smp_prepare_cpus = armada_xp_smp_prepare_cpus,
>> + .smp_boot_secondary = mv98dx3236_boot_secondary,
>> + .smp_secondary_init = armada_xp_secondary_init,
>> +#ifdef CONFIG_HOTPLUG_CPU
>> + .cpu_die = armada_xp_cpu_die,
>> + .cpu_kill = armada_xp_cpu_kill,
>> +#endif
>> +};
>> +
>> CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
>> &armada_xp_smp_ops);
>> +CPU_METHOD_OF_DECLARE(mv98dx3236_smp, "marvell,98dx3236-smp",
>> + &mv98dx3236_smp_ops);
>> diff --git a/arch/arm/mach-mvebu/pmsu-98dx3236.c b/arch/arm/mach-mvebu/pmsu-98dx3236.c
>> new file mode 100644
>> index 000000000000..1052674dd439
>> --- /dev/null
>> +++ b/arch/arm/mach-mvebu/pmsu-98dx3236.c
>> @@ -0,0 +1,52 @@
>> +/**
>> + * CPU resume support for 98DX3236 internal CPU (a.k.a. MSYS).
>> + */
>> +
>> +#define pr_fmt(fmt) "mv98dx3236-resume: " fmt
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/of_address.h>
>> +#include <linux/io.h>
>> +#include "common.h"
>> +
>> +static void __iomem *mv98dx3236_resume_base;
>> +#define MV98DX3236_CPU_RESUME_CTRL_OFFSET 0x08
>> +#define MV98DX3236_CPU_RESUME_ADDR_OFFSET 0x04
>> +
>> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
>> + {.compatible = "marvell,98dx3336-resume-ctrl",},
>> + { /* end of list */ },
>> +};
>> +
>> +void mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
>> +{
>> + WARN_ON(hw_cpu != 1);
>> +
>> + writel(0, mv98dx3236_resume_base + MV98DX3236_CPU_RESUME_CTRL_OFFSET);
>> + writel(virt_to_phys(boot_addr), mv98dx3236_resume_base +
>> + MV98DX3236_CPU_RESUME_ADDR_OFFSET);
>> +}
>> +
>> +static int __init mv98dx3236_resume_init(void)
>> +{
>> + struct device_node *np;
>> + void __iomem *base;
>> +
>> + np = of_find_matching_node(NULL, of_mv98dx3236_resume_table);
>> + if (!np)
>> + return 0;
>
> Is there any reason we can't just look for this node from the
> smp_ops and map it if it isn't mapped yet? Seems simpler than a
> whole new file and initcall.
>
That's at least 2 votes for rolling it into platsmp.c. The amount of
code has been significantly reduced so I think I will do it for v4.
>> +
>> + base = of_io_request_and_map(np, 0, of_node_full_name(np));
>> + if (IS_ERR(base)) {
>> + pr_err("unable to map registers\n");
>
> Doesn't of_io_request_and_map() spit out an error on failure
> already?
>
Not that I can see. But as has been previously mentioned a CPU failing
to come online is reasonably obvious already.
>> + of_node_put(np);
>
> This could be done before the if statement and then the duplicate
> statement deleted.
>
Will do.
>> + return PTR_ERR(mv98dx3236_resume_base);
>
> Should be PTR_ERR(base)?
Yes. I decided to add the local variable at the last minute.
>
>> + }
>> +
>> + mv98dx3236_resume_base = base;
>> + of_node_put(np);
>> + return 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
* Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding
From: Rajendra Nayak @ 2017-01-06 8:46 UTC (permalink / raw)
To: Viresh Kumar, Rafael Wysocki
Cc: linaro-kernel, linux-pm, linux-kernel, Stephen Boyd,
Nishanth Menon, Vincent Guittot, Rob Herring, Mark Rutland,
Kevin Hilman, Ulf Hansson, Lina Iyer, devicetree
In-Reply-To: <dd95df02a1c3efd00bd4890f8aceeb717ad38788.1481539827.git.viresh.kumar@linaro.org>
On 12/12/2016 04:26 PM, Viresh Kumar wrote:
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
>
> The power-domains until now were only concentrating on the idle state
> management of the device and this needs to change in order to reuse the
> infrastructure of power domains for active state management.
>
> This patch adds binding to describe the performance states of a power
> domain.
The bindings would also need to take into account the fact that a device
could (and is quite often the case with qcom platforms) have 2 separate
powerdomains, one for idle state management and another to manage active
states. I guess the below bindings assume that there's just one.
- Rajendra
>
> If the consumers don't need the capability of switching to different
> domain performance states at runtime, then they can simply define their
> required domain performance state in their node directly. Otherwise the
> consumers can define their requirements with help of other
> infrastructure, for example the OPP table.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> .../devicetree/bindings/power/power_domain.txt | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 723e1ad937da..a456e0dc04e0 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -38,6 +38,40 @@ phandle arguments (so called PM domain specifiers) of length specified by the
> domain's idle states. In the absence of this property, the domain would be
> considered as capable of being powered-on or powered-off.
>
> +- domain-performance-states : A phandle of the performance states node, which
> + defines all the performance states associated with a power
> + domain.
> + The domain-performance-states property reflects the performance states of this
> + PM domain and not the performance states of the devices or sub-domains in the
> + PM domain. Devices and sub-domains have their own performance states, which
> + are dependent on the performance state of the PM domain.
> +
> +* PM domain performance states node
> +
> +This describes the performance states of a PM domain.
> +
> +Required properties:
> +- compatible: Allow performance states to express their compatibility. It should
> + be: "domain-performance-state".
> +
> +- Performance state nodes: This node shall have one or more "Performance State"
> + nodes.
> +
> +* Performance state node
> +
> +Required properties:
> +- performance-level: A positive integer value representing the performance level
> + associated with a performance state. The integer value '1' represents the
> + lowest performance level and the highest value represents the highest
> + performance level.
> +
> +Optional properties:
> +- domain-microvolt: voltage in micro Volts.
> +
> + A single regulator's voltage is specified with an array of size one or three.
> + Single entry is for target voltage and three entries are for <target min max>
> + voltages.
> +
> Example:
>
> power: power-controller@12340000 {
> @@ -118,4 +152,39 @@ The node above defines a typical PM domain consumer device, which is located
> inside a PM domain with index 0 of a power controller represented by a node
> with the label "power".
>
> +Optional properties:
> +- domain-performance-state: A phandle of a Performance state node.
> +
> +Example:
> +
> + parent: power-controller@12340000 {
> + compatible = "foo,power-controller";
> + reg = <0x12340000 0x1000>;
> + #power-domain-cells = <0>;
> + domain-performance-states = <&domain_perf_states>;
> + };
> +
> + domain_perf_states: performance_states {
> + compatible = "domain-performance-state";
> + domain_perf_state1: pstate@1 {
> + performance-level = <1>;
> + domain-microvolt = <970000 975000 985000>;
> + };
> + domain_perf_state2: pstate@2 {
> + performance-level = <2>;
> + domain-microvolt = <1000000 1075000 1085000>;
> + };
> + domain_perf_state3: pstate@3 {
> + performance-level = <3>;
> + domain-microvolt = <1100000 1175000 1185000>;
> + };
> + }
> +
> + leaky-device@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&power 0>;
> + domain-performance-state = <&domain_perf_state2>;
> + };
> +
> [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Boris Brezillon @ 2017-01-06 8:49 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Cyrille Pitchen, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
Marek Vasut, Rob Herring, Joel Stanley, Brian Norris,
David Woodhouse
In-Reply-To: <4c0b4498-12c7-303d-c8f8-4f27a02d6c12-Bxea+6Xhats@public.gmane.org>
Hi Cédric,
On Thu, 5 Jan 2017 14:39:14 +0100
Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> Hello Cyrille, Boris
>
> On 01/04/2017 06:50 PM, Boris Brezillon wrote:
> > Cyrille, Cédric,
> >
> > On Wed, 4 Jan 2017 15:52:07 +0100
> > Cyrille Pitchen <cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org> wrote:
> >
> >>>
> >>>> Anyway, since the review is done now, on my side I won't ask you to remove
> >>>> or split the support of the 'Command' mode in a separated patch.
> >>>> I let you do as you want, if it help you to introduce some part of the
> >>>> support of this 'Command' mode now even if not completed yet, no problem on
> >>>> my side :)
> >>>>
> >>>> I was just giving you some pieces of advice for the next time if you want
> >>>> to speed up the review of another patch introducing new features.
> >>>>
> >>>> However, I will just ask you one more version handling the dummy cycles
> >>>> properly as it would help us for the global maintenance of the spi-nor
> >>>> subsystem. This is the only mandatory modification I ask you, after that I
> >>>> think it would be ok for me and since Marek has already reviewed your
> >>>> driver, it would be ready to be merged into the spi-nor tree.
> >>>
> >>> Sending a v5 which should address your comments.
> >>>
> >>> I have removed the label property and will start a new thread in the
> >>> topic. Any hints on which binding we could add this label prop ?
> >>>
> >>
> >> Here I will provide just few thoughts about this new DT property. I don't
> >> pretend this is what should be done. I still think other mtd maintainers
> >> should be involved to discuss this topic.
> >>
> >> First the DT property name "label" sounds good to me: it is consistent with
> >> "label" DT property used to name mtd partitions. However, I don't think it
> >> should be documented in jedec,spi-nor.txt but *maybe* in partition.txt as
> >> the purpose of this new DT property seems very close to the "label"
> >> property of partition nodes: let's think about some hard-disk device
> >> (/dev/sda) and its partition devices (/dev/sdaX).
>
> yes this is very similar. I first looked at introducing a name to
> an overall containing partition but the partition binding is not
> designed for that. There are constraints on the start address and
> the size which does not fit the purpose.
>
> > Hm, partition.txt may not be appropriate here. We're not documenting
> > the MTD partition binding, but the MTD device one. Maybe we should
> > create mtd.txt and put all generic MTD dev properties here.
> >>
> >> Besides, the concept of this memory label is not limited to SPI NOR but
> >> could also apply to NAND memories or any other MTD handled memories.
> >
> > Definitely. Actually I think I'll need that for the Atmel NAND
> > controller driver rework I'm currently working on, to keep mtdparts
> > parser happy even after changing the NAND device naming scheme.
> >
> >> Hence the DT property might be handled by drivers/mtd/ofpart.c instead of
> >> being handled by spi-nor.c or by each SPI NOR memory controller driver.
> >
> > Actually, that could be done at the mtdcore level in
> > mtd_set_dev_defaults() [1].
>
> that would be perfect.
>
> >> Finally, I guess we should take time to discuss and all agree what should
> >> be done precisely before introducing a new DT property because one general
> >> rule with DTB files is that users should be able to update their kernel
> >> image (zImage, uImage, ...) without changing their DTB: device trees should
> >> be backward compatible. Hence if we make a wrong choice today, we are
> >> likely to have to live with it and keep supporting that bad choice.
> >
> > Rob already acked the patch, so, if all MTD maintainers agree that this
> > new property is acceptable, we should be fine ;-).
>
> yes but we would need to move the binding property to another file.
> What I sent applied to "jedec,spi-nor" and we want to generalize the
> property to other devices.
We could create an new file under
Documentation/devicetree/bindings/mtd/, or we could rename
partition.txt into something else (generic.txt or common.txt) and
document more than the partition binding.
Can you take care of that (in a separate patch series of course)?
Thanks,
Boris
--
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 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25
From: Krzysztof Kozlowski @ 2017-01-06 8:50 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Krzysztof Kozlowski, Jaechul Lee, Dmitry Torokhov, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Kukjin Kim,
Javier Martinez Canillas, Andi Shyti, beomho.seo, galaxyra,
linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc
In-Reply-To: <586F4554.6020206@samsung.com>
On Fri, Jan 06, 2017 at 04:20:52PM +0900, Chanwoo Choi wrote:
> On 2017년 01월 06일 16:05, Krzysztof Kozlowski wrote:
> > On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote:
> >> From: Chanwoo Choi <cw00.choi@samsung.com>
> >>
> >> This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and TM2E.
> >
> > Please describe what is exactly wrong and how it affects the
> > system/user. This is going to the fixes so it needs a good explanation.
>
> When I posted the patch[1], I refer to the old schematic document of both TM2 and TM2E.
> [1] 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
>
> After checking the highest version of schematic document of both TM2 and TM2E,
> there is no difference of ldo23/ldo25 on both TM2 and TM2E.
> - ldo23 is used on TM2/TM2E, but the name/max-microvolt are wrong.
> - ldo25 isn't used on TM2/TM2E. (not connected)
>
> Because ldo23 and lod25 are not used on other device in Exynos5433 and TM2 board.
> this patch does not affect the operation to system/user.
If it does not affect anyone (including TM2/TM2E) then this do not have
to be a fix. Am I right?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/1] spi: imx: support to set watermark level via DTS
From: Jiada Wang @ 2017-01-06 9:00 UTC (permalink / raw)
To: Mark Brown vladimir_zapolskiy@mentor.com
Cc: robh+dt, mark.rutland, linux-spi, devicetree, linux-kernel
In-Reply-To: <20170105175854.gj5xr5drk5tddzyz@sirena.org.uk>
Hello Mark and Vladimir
On 01/05/2017 09:58 AM, Mark Brown wrote:
> On Thu, Jan 05, 2017 at 03:10:15PM +0900, Jiada Wang wrote:
>
>> Previously watermark level is configured to fifosize/2,
>> DMA mode can be used only when transfer length can be divided
>> by 'watermark level * bpw', which makes DMA mode not practical.
>> This patch adds new DTS property 'dma-wml', user can configure
>> DMA watermark level, by specify 'dma-wml' in corresponding ecspi
>> node.
> Doesn't this just move the problem around a bit - can we not have the
> driver figure out a more sensible watermark for each transfer rather
> than fixing one in the DT?
I would like to submit another version of patch to adjust watermark level
based on transfer length. to use largest number (< fifosize / 2 ) which
can divide
(transfer_length / bytes_per_work).
Thanks,
Jiada
^ permalink raw reply
* Re: [PATCH 1/3] ARM: at91: flush the L2 cache before entering cpu idle
From: Alexandre Belloni @ 2017-01-06 9:05 UTC (permalink / raw)
To: Wenyou Yang
Cc: Mark Rutland, devicetree, Russell King, Wenyou Yang,
Nicolas Ferre, linux-kernel, Rob Herring, linux-arm-kernel
In-Reply-To: <20170106065947.30631-2-wenyou.yang@atmel.com>
Hi,
On 06/01/2017 at 14:59:45 +0800, Wenyou Yang wrote :
> For the SoCs such as SAMA5D2 and SAMA5D4 which have L2 cache,
> flush the L2 cache first before entering the cpu idle.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> arch/arm/mach-at91/pm.c | 19 +++++++++++++++++++
> drivers/memory/atmel-sdramc.c | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index b4332b727e9c..1a60dede1a01 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -289,6 +289,24 @@ static void at91_ddr_standby(void)
> at91_ramc_write(1, AT91_DDRSDRC_LPR, saved_lpr1);
> }
>
> +static void at91_ddr_cache_standby(void)
> +{
> + u32 saved_lpr;
> +
> + flush_cache_all();
> + outer_disable();
> +
> + saved_lpr = at91_ramc_read(0, AT91_DDRSDRC_LPR);
> + at91_ramc_write(0, AT91_DDRSDRC_LPR, (saved_lpr &
> + (~AT91_DDRSDRC_LPCB)) | AT91_DDRSDRC_LPCB_SELF_REFRESH);
> +
> + cpu_do_idle();
> +
> + at91_ramc_write(0, AT91_DDRSDRC_LPR, saved_lpr);
> +
> + outer_resume();
> +}
> +
Seems good to me. Did you measure the added latency on sama5d3 if you
add the cache operations in at91_ddr_standby instead of having a new
function?
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25
From: Chanwoo Choi @ 2017-01-06 9:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, Dmitry Torokhov,
Catalin Marinas, Jaechul Lee, Will Deacon, linux-kernel,
Andi Shyti, Javier Martinez Canillas, Rob Herring, Kukjin Kim,
linux-input, galaxyra, beomho.seo, linux-arm-kernel
In-Reply-To: <20170106085026.5pfwyxt2qipzbjpy@kozik-lap>
On 2017년 01월 06일 17:50, Krzysztof Kozlowski wrote:
> On Fri, Jan 06, 2017 at 04:20:52PM +0900, Chanwoo Choi wrote:
>> On 2017년 01월 06일 16:05, Krzysztof Kozlowski wrote:
>>> On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote:
>>>> From: Chanwoo Choi <cw00.choi@samsung.com>
>>>>
>>>> This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and TM2E.
>>>
>>> Please describe what is exactly wrong and how it affects the
>>> system/user. This is going to the fixes so it needs a good explanation.
>>
>> When I posted the patch[1], I refer to the old schematic document of both TM2 and TM2E.
>> [1] 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
>>
>> After checking the highest version of schematic document of both TM2 and TM2E,
>> there is no difference of ldo23/ldo25 on both TM2 and TM2E.
>> - ldo23 is used on TM2/TM2E, but the name/max-microvolt are wrong.
>> - ldo25 isn't used on TM2/TM2E. (not connected)
>>
>> Because ldo23 and lod25 are not used on other device in Exynos5433 and TM2 board.
>> this patch does not affect the operation to system/user.
>
> If it does not affect anyone (including TM2/TM2E) then this do not have
> to be a fix. Am I right?
This patch does not affect the TM2/TM2E's operation
because ldo23/25 are not used on TM2/TM2E. Just fix the wrong information.
--
Best Regards,
Chanwoo Choi
S/W Center, Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1] mtd: spi nor: modify the boot and flash type of FMC
From: linshunquan 00354166 @ 2017-01-06 9:12 UTC (permalink / raw)
To: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, richard-/L3Ra7n9ekc,
cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: xuejiancheng-C8/M+/jPZTeaMJb+Lgu22Q,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
howell.yang-C8/M+/jPZTeaMJb+Lgu22Q,
jalen.hsu-C8/M+/jPZTeaMJb+Lgu22Q,
suwenping-C8/M+/jPZTeaMJb+Lgu22Q, raojun-C8/M+/jPZTeaMJb+Lgu22Q,
kevin.lixu-C8/M+/jPZTeaMJb+Lgu22Q,
lvkuanliang-C8/M+/jPZTeaMJb+Lgu22Q, linshunquan 00354166
(1) The HiSilicon Flash Memory Controller(FMC) is a multi-functions
device which supports SPI Nor flash controller, SPI nand Flash
controller and parallel nand flash controller. So when we are prepare
to operation SPI Nor, we should make sure the flash type is SPI Nor.
(2) Make sure the boot type is Normal Type before initialize the SPI
Nor controller.
Signed-off-by: linshunquan 00354166 <linshunquan1-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
drivers/mtd/spi-nor/hisi-sfc.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c
index 20378b0..7855024 100644
--- a/drivers/mtd/spi-nor/hisi-sfc.c
+++ b/drivers/mtd/spi-nor/hisi-sfc.c
@@ -32,6 +32,8 @@
#define FMC_CFG_OP_MODE_MASK BIT_MASK(0)
#define FMC_CFG_OP_MODE_BOOT 0
#define FMC_CFG_OP_MODE_NORMAL 1
+#define FMC_CFG_OP_MODE_SEL(mode) ((mode) & 0x1)
+#define FMC_CFG_FLASH_SEL_SPI_NOR (0x0 << 1)
#define FMC_CFG_FLASH_SEL(type) (((type) & 0x3) << 1)
#define FMC_CFG_FLASH_SEL_MASK 0x6
#define FMC_ECC_TYPE(type) (((type) & 0x7) << 5)
@@ -141,10 +143,36 @@ static int get_if_type(enum read_mode flash_read)
return if_type;
}
+static void spi_nor_switch_spi_type(struct hifmc_host *host)
+{
+ unsigned int reg;
+
+ reg = readl(host->regbase + FMC_CFG);
+ if ((reg & FMC_CFG_FLASH_SEL_MASK)
+ == FMC_CFG_FLASH_SEL_SPI_NOR)
+ return;
+
+ /* if the flash type isn't spi nor, change it */
+ reg &= ~FMC_CFG_FLASH_SEL_MASK;
+ reg |= FMC_CFG_FLASH_SEL(0);
+ writel(reg, host->regbase + FMC_CFG);
+}
+
static void hisi_spi_nor_init(struct hifmc_host *host)
{
u32 reg;
+ /* switch the flash type to spi nor */
+ spi_nor_switch_spi_type(host);
+
+ /* set the boot mode to normal */
+ reg = readl(host->regbase + FMC_CFG);
+ if ((reg & FMC_CFG_OP_MODE_MASK) == FMC_CFG_OP_MODE_BOOT) {
+ reg |= FMC_CFG_OP_MODE_SEL(FMC_CFG_OP_MODE_NORMAL);
+ writel(reg, host->regbase + FMC_CFG);
+ }
+
+ /* set timming */
reg = TIMING_CFG_TCSH(CS_HOLD_TIME)
| TIMING_CFG_TCSS(CS_SETUP_TIME)
| TIMING_CFG_TSHSL(CS_DESELECT_TIME);
@@ -167,6 +195,8 @@ static int hisi_spi_nor_prep(struct spi_nor *nor, enum spi_nor_ops ops)
if (ret)
goto out;
+ spi_nor_switch_spi_type(host);
+
return 0;
out:
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong information of ldo23 and ldo25
From: Krzysztof Kozlowski @ 2017-01-06 9:12 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Mark Rutland, devicetree, linux-samsung-soc, Dmitry Torokhov,
Andi Shyti, Catalin Marinas, Jaechul Lee, Will Deacon,
linux-kernel, Krzysztof Kozlowski, Javier Martinez Canillas,
Rob Herring, Kukjin Kim, linux-input, galaxyra, beomho.seo,
linux-arm-kernel
In-Reply-To: <73639ec8-028a-56a2-0b47-3465974ec3f3@samsung.com>
On Fri, Jan 06, 2017 at 06:06:43PM +0900, Chanwoo Choi wrote:
> On 2017년 01월 06일 17:50, Krzysztof Kozlowski wrote:
> > On Fri, Jan 06, 2017 at 04:20:52PM +0900, Chanwoo Choi wrote:
> >> On 2017년 01월 06일 16:05, Krzysztof Kozlowski wrote:
> >>> On Fri, Jan 06, 2017 at 12:59:05PM +0900, Jaechul Lee wrote:
> >>>> From: Chanwoo Choi <cw00.choi@samsung.com>
> >>>>
> >>>> This patch fixes the wrong information of ldo23 and ldo25 on both TM2 and TM2E.
> >>>
> >>> Please describe what is exactly wrong and how it affects the
> >>> system/user. This is going to the fixes so it needs a good explanation.
> >>
> >> When I posted the patch[1], I refer to the old schematic document of both TM2 and TM2E.
> >> [1] 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
> >>
> >> After checking the highest version of schematic document of both TM2 and TM2E,
> >> there is no difference of ldo23/ldo25 on both TM2 and TM2E.
> >> - ldo23 is used on TM2/TM2E, but the name/max-microvolt are wrong.
> >> - ldo25 isn't used on TM2/TM2E. (not connected)
> >>
> >> Because ldo23 and lod25 are not used on other device in Exynos5433 and TM2 board.
> >> this patch does not affect the operation to system/user.
> >
> > If it does not affect anyone (including TM2/TM2E) then this do not have
> > to be a fix. Am I right?
>
> This patch does not affect the TM2/TM2E's operation
> because ldo23/25 are not used on TM2/TM2E. Just fix the wrong information.
Ah, okay, thanks for explanation. Please just rebase on current
next/dt64 (or for-next or just my
https://patchwork.kernel.org/patch/9500153/) so the always-off property
won't be copied.
I'll take it then for v4.11.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 1/5] dt-bindings: zte: add bindings document for zx2967 power domain controller
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, gregkh, davem, geert+renesas,
akpm, mchehab, krzk, arnd, claudiu.manoil, amitdanielk,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: devicetree, Baoyou Xie, linux-kernel, linux-arm-kernel
This patch adds device tree bindings document for ZTE zx2967
family power domain controller.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
.../devicetree/bindings/soc/zte/pd-2967xx.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
diff --git a/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
new file mode 100644
index 0000000..7629de1
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
@@ -0,0 +1,19 @@
+* ZTE zx2967 family Power Domains
+
+zx2967 family includes support for multiple power domains which are used
+to gate power to one or more peripherals on the processor.
+
+Required Properties:
+ - compatible: should be one of the following.
+ * zte,zx296718-pcu - for zx296718 power domain.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - #power-domain-cells: Must be 1.
+
+Example:
+
+ pcu_domain: pcu@117000 {
+ compatible = "zte,zx296718-pcu";
+ reg = <0x00117000 0x1000>;
+ #power-domain-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v7 2/5] MAINTAINERS: add zx2967 SoC drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, gregkh, davem, geert+renesas,
akpm, mchehab, krzk, arnd, claudiu.manoil, amitdanielk,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: devicetree, Baoyou Xie, linux-kernel, linux-arm-kernel
In-Reply-To: <1483694164-7668-1-git-send-email-baoyou.xie@linaro.org>
Add the ZTE SoC drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
By the way, this patch adds the maintainer for ARM
ZTE architecture to Baoyou Xie.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ad199da..64f04df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1975,12 +1975,16 @@ F: arch/arm/mach-pxa/include/mach/z2.h
ARM/ZTE ARCHITECTURE
M: Jun Nie <jun.nie@linaro.org>
+M: Baoyou Xie <baoyou.xie@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/soc/zte/
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/soc/zte/
+F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@xilinx.com>
--
2.7.4
^ permalink raw reply related
* [PATCH v7 3/5] soc: zte: Add header for PM domains specifiers
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, gregkh, davem, geert+renesas,
akpm, mchehab, krzk, arnd, claudiu.manoil, amitdanielk,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: devicetree, Baoyou Xie, linux-kernel, linux-arm-kernel
In-Reply-To: <1483694164-7668-1-git-send-email-baoyou.xie@linaro.org>
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
include/dt-bindings/soc/zte,pm_domains.h | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
diff --git a/include/dt-bindings/soc/zte,pm_domains.h b/include/dt-bindings/soc/zte,pm_domains.h
new file mode 100644
index 0000000..a0b4019
--- /dev/null
+++ b/include/dt-bindings/soc/zte,pm_domains.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /* g1v6 */
+#define DM_ZX296718_VCE 2 /* h1v6 */
+#define DM_ZX296718_HDE 3 /* g2v2 */
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v7 4/5] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, gregkh, davem, geert+renesas,
akpm, mchehab, krzk, arnd, claudiu.manoil, amitdanielk,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: devicetree, Baoyou Xie, linux-kernel, linux-arm-kernel
In-Reply-To: <1483694164-7668-1-git-send-email-baoyou.xie@linaro.org>
The ARMv8 zx2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value depending on the compatible.
Multiple domains are prepared for the family, this patch prepares
the common functions.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/zte/Kconfig | 13 ++++
drivers/soc/zte/Makefile | 4 +
drivers/soc/zte/zx2967_pm_domains.c | 143 ++++++++++++++++++++++++++++++++++++
drivers/soc/zte/zx2967_pm_domains.h | 44 +++++++++++
6 files changed, 206 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f31bceb..f09023f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
+source "drivers/soc/zte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 50c23d0..05eae52 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
+obj-$(CONFIG_ARCH_ZX) += zte/
diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
new file mode 100644
index 0000000..20bde38
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# ZTE SoC drivers
+#
+menuconfig SOC_ZTE
+ bool "ZTE SoC driver support"
+
+if SOC_ZTE
+
+config ZX2967_PM_DOMAINS
+ bool "ZX2967 PM domains"
+ depends on PM_GENERIC_DOMAINS
+
+endif
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
new file mode 100644
index 0000000..8a37f2f
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# ZTE SOC drivers
+#
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
diff --git a/drivers/soc/zte/zx2967_pm_domains.c b/drivers/soc/zte/zx2967_pm_domains.c
new file mode 100644
index 0000000..61c8d84
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.c
@@ -0,0 +1,143 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+#include "zx2967_pm_domains.h"
+
+#define PCU_DM_CLKEN(zpd) ((zpd)->reg_offset[REG_CLKEN])
+#define PCU_DM_ISOEN(zpd) ((zpd)->reg_offset[REG_ISOEN])
+#define PCU_DM_RSTEN(zpd) ((zpd)->reg_offset[REG_RSTEN])
+#define PCU_DM_PWREN(zpd) ((zpd)->reg_offset[REG_PWREN])
+#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
+
+static void __iomem *pcubase;
+
+static int zx2967_power_on(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val |= BIT(zpd->bit);
+ else
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && !val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ pr_debug("poweron %s\n", domain->name);
+
+ return 0;
+}
+
+static int zx2967_power_off(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val &= ~BIT(zpd->bit);
+ else
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ pr_debug("poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num)
+{
+ struct genpd_onecell_data *genpd_data;
+ struct resource *res;
+ int i;
+
+ genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
+ if (!genpd_data)
+ return -ENOMEM;
+
+ genpd_data->domains = zx_pm_domains;
+ genpd_data->num_domains = domain_num;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pcubase)) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return PTR_ERR(pcubase);
+ }
+
+ for (i = 0; i < domain_num; ++i) {
+ zx_pm_domains[i]->power_on = zx2967_power_on;
+ zx_pm_domains[i]->power_off = zx2967_power_off;
+
+ pm_genpd_init(zx_pm_domains[i], NULL, false);
+ }
+
+ of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
+ dev_info(&pdev->dev, "powerdomain init ok\n");
+ return 0;
+}
diff --git a/drivers/soc/zte/zx2967_pm_domains.h b/drivers/soc/zte/zx2967_pm_domains.h
new file mode 100644
index 0000000..cb46595
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.h
@@ -0,0 +1,44 @@
+/*
+ * Header for ZTE's Power Domain Driver support
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef __ZTE_ZX2967_PM_DOMAIN_H
+#define __ZTE_ZX2967_PM_DOMAIN_H
+
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+
+enum {
+ REG_CLKEN,
+ REG_ISOEN,
+ REG_RSTEN,
+ REG_PWREN,
+ REG_PWRDN,
+ REG_ACK_SYNC,
+
+ /* The size of the array - must be last */
+ REG_ARRAY_SIZE,
+};
+
+enum zx2967_power_polarity {
+ PWREN,
+ PWRDN,
+};
+
+struct zx2967_pm_domain {
+ struct generic_pm_domain dm;
+ const u16 bit;
+ const enum zx2967_power_polarity polarity;
+ const u16 *reg_offset;
+};
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+
+#endif /* __ZTE_ZX2967_PM_DOMAIN_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v7 5/5] soc: zte: pm_domains: Add support for zx296718
From: Baoyou Xie @ 2017-01-06 9:16 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, gregkh, davem, geert+renesas,
akpm, mchehab, krzk, arnd, claudiu.manoil, amitdanielk,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: devicetree, Baoyou Xie, linux-kernel, linux-arm-kernel
In-Reply-To: <1483694164-7668-1-git-send-email-baoyou.xie@linaro.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
---
drivers/soc/zte/Makefile | 1 +
drivers/soc/zte/zx296718_pm_domains.c | 182 ++++++++++++++++++++++++++++++++++
2 files changed, 183 insertions(+)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 8a37f2f..96b7cd4 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -2,3 +2,4 @@
# ZTE SOC drivers
#
obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx296718_pm_domains.o
diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
new file mode 100644
index 0000000..5ed924f
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <dt-bindings/soc/zte,pm_domains.h>
+#include "zx2967_pm_domains.h"
+
+static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
+ [REG_CLKEN] = 0x18,
+ [REG_ISOEN] = 0x1c,
+ [REG_RSTEN] = 0x20,
+ [REG_PWREN] = 0x24,
+ [REG_ACK_SYNC] = 0x28,
+};
+
+enum {
+ PCU_DM_VOU = 0,
+ PCU_DM_SAPPU,
+ PCU_DM_VDE,
+ PCU_DM_VCE,
+ PCU_DM_HDE,
+ PCU_DM_VIU,
+ PCU_DM_USB20,
+ PCU_DM_USB21,
+ PCU_DM_USB30,
+ PCU_DM_HSIC,
+ PCU_DM_GMAC,
+ PCU_DM_TS,
+};
+
+static struct zx2967_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ },
+ .bit = PCU_DM_VOU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ },
+ .bit = PCU_DM_SAPPU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ },
+ .bit = PCU_DM_VDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ },
+ .bit = PCU_DM_VCE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ },
+ .bit = PCU_DM_HDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ },
+ .bit = PCU_DM_VIU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ },
+ .bit = PCU_DM_USB20,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ },
+ .bit = PCU_DM_USB21,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ },
+ .bit = PCU_DM_USB30,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ },
+ .bit = PCU_DM_HSIC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ },
+ .bit = PCU_DM_GMAC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ },
+ .bit = PCU_DM_TS,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct generic_pm_domain *zx296718_pm_domains[] = {
+ [DM_ZX296718_VOU] = &vou_domain.dm,
+ [DM_ZX296718_SAPPU] = &sappu_domain.dm,
+ [DM_ZX296718_VDE] = &vde_domain.dm,
+ [DM_ZX296718_VCE] = &vce_domain.dm,
+ [DM_ZX296718_HDE] = &hde_domain.dm,
+ [DM_ZX296718_VIU] = &viu_domain.dm,
+ [DM_ZX296718_USB20] = &usb20_domain.dm,
+ [DM_ZX296718_USB21] = &usb21_domain.dm,
+ [DM_ZX296718_USB30] = &usb30_domain.dm,
+ [DM_ZX296718_HSIC] = &hsic_domain.dm,
+ [DM_ZX296718_GMAC] = &gmac_domain.dm,
+ [DM_ZX296718_TS] = &ts_domain.dm,
+};
+
+static int zx296718_pd_probe(struct platform_device *pdev)
+{
+ return zx2967_pd_probe(pdev,
+ zx296718_pm_domains,
+ ARRAY_SIZE(zx296718_pm_domains));
+}
+
+static const struct of_device_id zx296718_pm_domain_matches[] = {
+ { .compatible = "zte,zx296718-pcu", },
+ { },
+};
+
+static struct platform_driver zx296718_pd_driver = {
+ .driver = {
+ .name = "zx296718-powerdomain",
+ .owner = THIS_MODULE,
+ .of_match_table = zx296718_pm_domain_matches,
+ },
+ .probe = zx296718_pd_probe,
+};
+
+static int __init zx296718_pd_init(void)
+{
+ return platform_driver_register(&zx296718_pd_driver);
+}
+subsys_initcall(zx296718_pd_init);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v7 1/5] dt-bindings: zte: add bindings document for zx2967 power domain controller
From: Baoyou Xie @ 2017-01-06 9:19 UTC (permalink / raw)
To: Jun Nie, Rob Herring, mark.rutland, Greg KH, davem, geert+renesas,
akpm, mchehab, krzk, Arnd Bergmann, claudiu.manoil, amit daniel,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: linux-arm-kernel, devicetree, Linux Kernel Mailing List,
Baoyou Xie, Shawn Guo, xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <1483694164-7668-1-git-send-email-baoyou.xie@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]
+ Shawn
On 6 January 2017 at 17:16, Baoyou Xie <baoyou.xie@linaro.org> wrote:
> This patch adds device tree bindings document for ZTE zx2967
> family power domain controller.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> .../devicetree/bindings/soc/zte/pd-2967xx.txt | 19
> +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/
> bindings/soc/zte/pd-2967xx.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
> b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
> new file mode 100644
> index 0000000..7629de1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt
> @@ -0,0 +1,19 @@
> +* ZTE zx2967 family Power Domains
> +
> +zx2967 family includes support for multiple power domains which are used
> +to gate power to one or more peripherals on the processor.
> +
> +Required Properties:
> + - compatible: should be one of the following.
> + * zte,zx296718-pcu - for zx296718 power domain.
> + - reg: physical base address of the controller and length of memory
> mapped
> + region.
> + - #power-domain-cells: Must be 1.
> +
> +Example:
> +
> + pcu_domain: pcu@117000 {
> + compatible = "zte,zx296718-pcu";
> + reg = <0x00117000 0x1000>;
> + #power-domain-cells = <1>;
> + };
> --
> 2.7.4
>
>
[-- Attachment #2: Type: text/html, Size: 2002 bytes --]
^ permalink raw reply
* Re: [PATCH v7 2/5] MAINTAINERS: add zx2967 SoC drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-06 9:19 UTC (permalink / raw)
To: Jun Nie, Rob Herring, mark.rutland, Greg KH, davem, geert+renesas,
akpm, mchehab, krzk, Arnd Bergmann, claudiu.manoil, amit daniel,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: linux-arm-kernel, devicetree, Linux Kernel Mailing List,
Baoyou Xie, Shawn Guo, xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <1483694164-7668-2-git-send-email-baoyou.xie@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
+Shawn
On 6 January 2017 at 17:16, Baoyou Xie <baoyou.xie@linaro.org> wrote:
> Add the ZTE SoC drivers as maintained by ARM ZTE
> architecture maintainers, as they're parts of the core IP.
>
> By the way, this patch adds the maintainer for ARM
> ZTE architecture to Baoyou Xie.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> MAINTAINERS | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ad199da..64f04df 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1975,12 +1975,16 @@ F: arch/arm/mach-pxa/include/mach/z2.h
>
> ARM/ZTE ARCHITECTURE
> M: Jun Nie <jun.nie@linaro.org>
> +M: Baoyou Xie <baoyou.xie@linaro.org>
> L: linux-arm-kernel@lists.infradead.org (moderated for
> non-subscribers)
> S: Maintained
> F: arch/arm/mach-zx/
> F: drivers/clk/zte/
> +F: drivers/soc/zte/
> F: Documentation/devicetree/bindings/arm/zte.txt
> F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
> +F: Documentation/devicetree/bindings/soc/zte/
> +F: include/dt-bindings/soc/zx*.h
>
> ARM/ZYNQ ARCHITECTURE
> M: Michal Simek <michal.simek@xilinx.com>
> --
> 2.7.4
>
>
[-- Attachment #2: Type: text/html, Size: 1989 bytes --]
^ permalink raw reply
* Re: [PATCH v7 3/5] soc: zte: Add header for PM domains specifiers
From: Baoyou Xie @ 2017-01-06 9:19 UTC (permalink / raw)
To: Jun Nie, Rob Herring, mark.rutland, Greg KH, davem, geert+renesas,
akpm, mchehab, krzk, Arnd Bergmann, claudiu.manoil, amit daniel,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: linux-arm-kernel, devicetree, Linux Kernel Mailing List,
Baoyou Xie, Shawn Guo, xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <1483694164-7668-3-git-send-email-baoyou.xie@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]
+ Shawn
On 6 January 2017 at 17:16, Baoyou Xie <baoyou.xie@linaro.org> wrote:
> This patch adds header with values used for ZTE 2967
> SoC's power domain driver.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> include/dt-bindings/soc/zte,pm_domains.h | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
>
> diff --git a/include/dt-bindings/soc/zte,pm_domains.h
> b/include/dt-bindings/soc/zte,pm_domains.h
> new file mode 100644
> index 0000000..a0b4019
> --- /dev/null
> +++ b/include/dt-bindings/soc/zte,pm_domains.h
> @@ -0,0 +1,24 @@
> +/*
> + * Copyright (C) 2017 Linaro Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
> +#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
> +
> +#define DM_ZX296718_SAPPU 0
> +#define DM_ZX296718_VDE 1 /* g1v6 */
> +#define DM_ZX296718_VCE 2 /* h1v6 */
> +#define DM_ZX296718_HDE 3 /* g2v2 */
> +#define DM_ZX296718_VIU 4
> +#define DM_ZX296718_USB20 5
> +#define DM_ZX296718_USB21 6
> +#define DM_ZX296718_USB30 7
> +#define DM_ZX296718_HSIC 8
> +#define DM_ZX296718_GMAC 9
> +#define DM_ZX296718_TS 10
> +#define DM_ZX296718_VOU 11
> +
> +#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
> --
> 2.7.4
>
>
[-- Attachment #2: Type: text/html, Size: 2175 bytes --]
^ permalink raw reply
* Re: [PATCH v7 4/5] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family
From: Baoyou Xie @ 2017-01-06 9:20 UTC (permalink / raw)
To: Jun Nie, Rob Herring, mark.rutland, Greg KH, davem, geert+renesas,
akpm, mchehab, krzk, Arnd Bergmann, claudiu.manoil, amit daniel,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: linux-arm-kernel, devicetree, Linux Kernel Mailing List,
Baoyou Xie, Shawn Guo, xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <1483694164-7668-4-git-send-email-baoyou.xie@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 8686 bytes --]
+ Shawn
On 6 January 2017 at 17:16, Baoyou Xie <baoyou.xie@linaro.org> wrote:
> The ARMv8 zx2967 family (296718, 296716 etc) uses different value
> for controlling the power domain on/off registers, Choose the
> value depending on the compatible.
>
> Multiple domains are prepared for the family, this patch prepares
> the common functions.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/zte/Kconfig | 13 ++++
> drivers/soc/zte/Makefile | 4 +
> drivers/soc/zte/zx2967_pm_domains.c | 143 ++++++++++++++++++++++++++++++
> ++++++
> drivers/soc/zte/zx2967_pm_domains.h | 44 +++++++++++
> 6 files changed, 206 insertions(+)
> create mode 100644 drivers/soc/zte/Kconfig
> create mode 100644 drivers/soc/zte/Makefile
> create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
> create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index f31bceb..f09023f 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
> source "drivers/soc/ti/Kconfig"
> source "drivers/soc/ux500/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> +source "drivers/soc/zte/Kconfig"
>
> endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 50c23d0..05eae52 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_SOC_TI) += ti/
> obj-$(CONFIG_ARCH_U8500) += ux500/
> obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> +obj-$(CONFIG_ARCH_ZX) += zte/
> diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
> new file mode 100644
> index 0000000..20bde38
> --- /dev/null
> +++ b/drivers/soc/zte/Kconfig
> @@ -0,0 +1,13 @@
> +#
> +# ZTE SoC drivers
> +#
> +menuconfig SOC_ZTE
> + bool "ZTE SoC driver support"
> +
> +if SOC_ZTE
> +
> +config ZX2967_PM_DOMAINS
> + bool "ZX2967 PM domains"
> + depends on PM_GENERIC_DOMAINS
> +
> +endif
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> new file mode 100644
> index 0000000..8a37f2f
> --- /dev/null
> +++ b/drivers/soc/zte/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# ZTE SOC drivers
> +#
> +obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
> diff --git a/drivers/soc/zte/zx2967_pm_domains.c
> b/drivers/soc/zte/zx2967_pm_domains.c
> new file mode 100644
> index 0000000..61c8d84
> --- /dev/null
> +++ b/drivers/soc/zte/zx2967_pm_domains.c
> @@ -0,0 +1,143 @@
> +/*
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +
> +#include "zx2967_pm_domains.h"
> +
> +#define PCU_DM_CLKEN(zpd) ((zpd)->reg_offset[REG_CLKEN])
> +#define PCU_DM_ISOEN(zpd) ((zpd)->reg_offset[REG_ISOEN])
> +#define PCU_DM_RSTEN(zpd) ((zpd)->reg_offset[REG_RSTEN])
> +#define PCU_DM_PWREN(zpd) ((zpd)->reg_offset[REG_PWREN])
> +#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
> +
> +static void __iomem *pcubase;
> +
> +static int zx2967_power_on(struct generic_pm_domain *domain)
> +{
> + struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
> + unsigned long loop = 1000;
> + u32 val;
> +
> + val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
> + if (zpd->polarity == PWREN)
> + val |= BIT(zpd->bit);
> + else
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
> +
> + do {
> + udelay(1);
> + val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
> + & BIT(zpd->bit);
> + } while (--loop && !val);
> +
> + if (!loop) {
> + pr_err("Error: %s %s fail\n", __func__, domain->name);
> + return -EIO;
> + }
> +
> + val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
> + udelay(5);
> +
> + pr_debug("poweron %s\n", domain->name);
> +
> + return 0;
> +}
> +
> +static int zx2967_power_off(struct generic_pm_domain *domain)
> +{
> + struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
> + unsigned long loop = 1000;
> + u32 val;
> +
> + val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
> + val &= ~BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
> + udelay(5);
> +
> + val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
> + if (zpd->polarity == PWREN)
> + val &= ~BIT(zpd->bit);
> + else
> + val |= BIT(zpd->bit);
> + writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
> +
> + do {
> + udelay(1);
> + val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
> + & BIT(zpd->bit);
> + } while (--loop && val);
> +
> + if (!loop) {
> + pr_err("Error: %s %s fail\n", __func__, domain->name);
> + return -EIO;
> + }
> +
> + pr_debug("poweroff %s\n", domain->name);
> +
> + return 0;
> +}
> +
> +int zx2967_pd_probe(struct platform_device *pdev,
> + struct generic_pm_domain **zx_pm_domains,
> + int domain_num)
> +{
> + struct genpd_onecell_data *genpd_data;
> + struct resource *res;
> + int i;
> +
> + genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data),
> GFP_KERNEL);
> + if (!genpd_data)
> + return -ENOMEM;
> +
> + genpd_data->domains = zx_pm_domains;
> + genpd_data->num_domains = domain_num;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + pcubase = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(pcubase)) {
> + dev_err(&pdev->dev, "ioremap fail.\n");
> + return PTR_ERR(pcubase);
> + }
> +
> + for (i = 0; i < domain_num; ++i) {
> + zx_pm_domains[i]->power_on = zx2967_power_on;
> + zx_pm_domains[i]->power_off = zx2967_power_off;
> +
> + pm_genpd_init(zx_pm_domains[i], NULL, false);
> + }
> +
> + of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
> + dev_info(&pdev->dev, "powerdomain init ok\n");
> + return 0;
> +}
> diff --git a/drivers/soc/zte/zx2967_pm_domains.h
> b/drivers/soc/zte/zx2967_pm_domains.h
> new file mode 100644
> index 0000000..cb46595
> --- /dev/null
> +++ b/drivers/soc/zte/zx2967_pm_domains.h
> @@ -0,0 +1,44 @@
> +/*
> + * Header for ZTE's Power Domain Driver support
> + *
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#ifndef __ZTE_ZX2967_PM_DOMAIN_H
> +#define __ZTE_ZX2967_PM_DOMAIN_H
> +
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +
> +enum {
> + REG_CLKEN,
> + REG_ISOEN,
> + REG_RSTEN,
> + REG_PWREN,
> + REG_PWRDN,
> + REG_ACK_SYNC,
> +
> + /* The size of the array - must be last */
> + REG_ARRAY_SIZE,
> +};
> +
> +enum zx2967_power_polarity {
> + PWREN,
> + PWRDN,
> +};
> +
> +struct zx2967_pm_domain {
> + struct generic_pm_domain dm;
> + const u16 bit;
> + const enum zx2967_power_polarity polarity;
> + const u16 *reg_offset;
> +};
> +
> +int zx2967_pd_probe(struct platform_device *pdev,
> + struct generic_pm_domain **zx_pm_domains,
> + int domain_num);
> +
> +#endif /* __ZTE_ZX2967_PM_DOMAIN_H */
> --
> 2.7.4
>
>
[-- Attachment #2: Type: text/html, Size: 11064 bytes --]
^ permalink raw reply
* Re: [PATCH v7 5/5] soc: zte: pm_domains: Add support for zx296718
From: Baoyou Xie @ 2017-01-06 9:20 UTC (permalink / raw)
To: Jun Nie, Rob Herring, mark.rutland, Greg KH, davem, geert+renesas,
akpm, mchehab, krzk, Arnd Bergmann, claudiu.manoil, amit daniel,
pankaj.dubey, yangbo.lu, scott.branden, simon.horman
Cc: linux-arm-kernel, devicetree, Linux Kernel Mailing List,
Baoyou Xie, Shawn Guo, xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <1483694164-7668-5-git-send-email-baoyou.xie@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 6219 bytes --]
+ Shawn
On 6 January 2017 at 17:16, Baoyou Xie <baoyou.xie@linaro.org> wrote:
> This patch introduces the power domain driver of zx296718
> which belongs to zte's zx2967 family.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> Reviewed-by: Jun Nie <jun.nie@linaro.org>
> ---
> drivers/soc/zte/Makefile | 1 +
> drivers/soc/zte/zx296718_pm_domains.c | 182
> ++++++++++++++++++++++++++++++++++
> 2 files changed, 183 insertions(+)
> create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
>
> diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
> index 8a37f2f..96b7cd4 100644
> --- a/drivers/soc/zte/Makefile
> +++ b/drivers/soc/zte/Makefile
> @@ -2,3 +2,4 @@
> # ZTE SOC drivers
> #
> obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
> +obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx296718_pm_domains.o
> diff --git a/drivers/soc/zte/zx296718_pm_domains.c
> b/drivers/soc/zte/zx296718_pm_domains.c
> new file mode 100644
> index 0000000..5ed924f
> --- /dev/null
> +++ b/drivers/soc/zte/zx296718_pm_domains.c
> @@ -0,0 +1,182 @@
> +/*
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include <dt-bindings/soc/zte,pm_domains.h>
> +#include "zx2967_pm_domains.h"
> +
> +static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
> + [REG_CLKEN] = 0x18,
> + [REG_ISOEN] = 0x1c,
> + [REG_RSTEN] = 0x20,
> + [REG_PWREN] = 0x24,
> + [REG_ACK_SYNC] = 0x28,
> +};
> +
> +enum {
> + PCU_DM_VOU = 0,
> + PCU_DM_SAPPU,
> + PCU_DM_VDE,
> + PCU_DM_VCE,
> + PCU_DM_HDE,
> + PCU_DM_VIU,
> + PCU_DM_USB20,
> + PCU_DM_USB21,
> + PCU_DM_USB30,
> + PCU_DM_HSIC,
> + PCU_DM_GMAC,
> + PCU_DM_TS,
> +};
> +
> +static struct zx2967_pm_domain vou_domain = {
> + .dm = {
> + .name = "vou_domain",
> + },
> + .bit = PCU_DM_VOU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain sappu_domain = {
> + .dm = {
> + .name = "sappu_domain",
> + },
> + .bit = PCU_DM_SAPPU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain vde_domain = {
> + .dm = {
> + .name = "vde_domain",
> + },
> + .bit = PCU_DM_VDE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain vce_domain = {
> + .dm = {
> + .name = "vce_domain",
> + },
> + .bit = PCU_DM_VCE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain hde_domain = {
> + .dm = {
> + .name = "hde_domain",
> + },
> + .bit = PCU_DM_HDE,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain viu_domain = {
> + .dm = {
> + .name = "viu_domain",
> + },
> + .bit = PCU_DM_VIU,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain usb20_domain = {
> + .dm = {
> + .name = "usb20_domain",
> + },
> + .bit = PCU_DM_USB20,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain usb21_domain = {
> + .dm = {
> + .name = "usb21_domain",
> + },
> + .bit = PCU_DM_USB21,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain usb30_domain = {
> + .dm = {
> + .name = "usb30_domain",
> + },
> + .bit = PCU_DM_USB30,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain hsic_domain = {
> + .dm = {
> + .name = "hsic_domain",
> + },
> + .bit = PCU_DM_HSIC,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain gmac_domain = {
> + .dm = {
> + .name = "gmac_domain",
> + },
> + .bit = PCU_DM_GMAC,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct zx2967_pm_domain ts_domain = {
> + .dm = {
> + .name = "ts_domain",
> + },
> + .bit = PCU_DM_TS,
> + .polarity = PWREN,
> + .reg_offset = zx296718_offsets,
> +};
> +
> +static struct generic_pm_domain *zx296718_pm_domains[] = {
> + [DM_ZX296718_VOU] = &vou_domain.dm,
> + [DM_ZX296718_SAPPU] = &sappu_domain.dm,
> + [DM_ZX296718_VDE] = &vde_domain.dm,
> + [DM_ZX296718_VCE] = &vce_domain.dm,
> + [DM_ZX296718_HDE] = &hde_domain.dm,
> + [DM_ZX296718_VIU] = &viu_domain.dm,
> + [DM_ZX296718_USB20] = &usb20_domain.dm,
> + [DM_ZX296718_USB21] = &usb21_domain.dm,
> + [DM_ZX296718_USB30] = &usb30_domain.dm,
> + [DM_ZX296718_HSIC] = &hsic_domain.dm,
> + [DM_ZX296718_GMAC] = &gmac_domain.dm,
> + [DM_ZX296718_TS] = &ts_domain.dm,
> +};
> +
> +static int zx296718_pd_probe(struct platform_device *pdev)
> +{
> + return zx2967_pd_probe(pdev,
> + zx296718_pm_domains,
> + ARRAY_SIZE(zx296718_pm_domains));
> +}
> +
> +static const struct of_device_id zx296718_pm_domain_matches[] = {
> + { .compatible = "zte,zx296718-pcu", },
> + { },
> +};
> +
> +static struct platform_driver zx296718_pd_driver = {
> + .driver = {
> + .name = "zx296718-powerdomain",
> + .owner = THIS_MODULE,
> + .of_match_table = zx296718_pm_domain_matches,
> + },
> + .probe = zx296718_pd_probe,
> +};
> +
> +static int __init zx296718_pd_init(void)
> +{
> + return platform_driver_register(&zx296718_pd_driver);
> +}
> +subsys_initcall(zx296718_pd_init);
> --
> 2.7.4
>
>
[-- Attachment #2: Type: text/html, Size: 9070 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Andi Shyti @ 2017-01-06 9:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, Dmitry Torokhov,
Chanwoo Choi, Catalin Marinas, Jaechul Lee, Will Deacon,
linux-kernel, Javier Martinez Canillas, Rob Herring, Kukjin Kim,
linux-input, galaxyra, beomho.seo, linux-arm-kernel
In-Reply-To: <20170106083729.4odfu42knjxxudve@kozik-lap>
Hi Krzysztof,
> > > > .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1118 +++++++++++++++++++
> > > > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1153 +-------------------
> > >
> > > Like talking to a wall. Without any feedback. If my instructions were
> > > wrong (and it is not possible to detect rename) then please say it (you
> > > can add personal comments after separator ---).
> >
> > no Krzysztof, I'm sorry, but this patch has been formatted with
> > the diff algorithm *you* asked, -B50% both version 2 (where you
> > didn't comment) and version 3. If you still don't like it, please
> > don't blame me, blame the algorithm.
>
> If you wrote it in cover letter or after '---' I wouldn't complain
> because I would know that my feedback was ignored. But here it is like
> black hole - I do not know whether I was ignored or it was not working.
In the cover letter is written:
"- patch 3 diff has been generated with -B50%"
in "Changes in v2:". In v3 patch 3 has become patch 2.
> > Now we can stay here at trying random diff algorithms (as they
> > give more or less the same result) or you tell me which exact
> > algorithm you want me to use. Besides, for me it's clear,
> > tm2-common is all new, while in tm2 you have on one side the '-'
> > (if it applies nothing has changed) on the bottom the '+'.
>
> Maybe that depends on the git?
> $ git --version
> git version 2.9.3
> $ git format-patch -2 -B50%
> ...
> 21 ...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 24 +-
> 22 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1153 +-------------------
> 23 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 22 +-
> 24 3 files changed, 56 insertions(+), 1143 deletions(-)
> 25 copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (98%)
> 26 rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
I guess you're right, this has been generated from Jaechul's PC
who perhaps has a different version. I have version 2.11.0 and I
have same output as you.
I will send the patch generated from my PC as reply to your mail.
Andi
^ permalink raw reply
* Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding
From: Viresh Kumar @ 2017-01-06 9:27 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Rafael Wysocki, linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd, Nishanth Menon,
Vincent Guittot, Rob Herring, Mark Rutland, Kevin Hilman,
Ulf Hansson, Lina Iyer, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <586F596C.7000807-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 06-01-17, 14:16, Rajendra Nayak wrote:
>
> On 12/12/2016 04:26 PM, Viresh Kumar wrote:
> > Some platforms have the capability to configure the performance state of
> > their Power Domains. The performance levels are represented by positive
> > integer values, a lower value represents lower performance state.
> >
> > The power-domains until now were only concentrating on the idle state
> > management of the device and this needs to change in order to reuse the
> > infrastructure of power domains for active state management.
> >
> > This patch adds binding to describe the performance states of a power
> > domain.
>
> The bindings would also need to take into account the fact that a device
> could (and is quite often the case with qcom platforms) have 2 separate
> powerdomains, one for idle state management and another to manage active
> states. I guess the below bindings assume that there's just one.
I have answered a similar question here..
https://marc.info/?l=linux-kernel&m=148067565219477&w=2
--
viresh
--
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/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Teresa Remmet @ 2017-01-06 9:27 UTC (permalink / raw)
To: Brian Norris, Tony Lindgren
Cc: Mark Rutland, devicetree, linux-omap, Rob Herring, linux-mtd,
Benoît Cousson, Brian Norris, Adam Ford, linux-arm-kernel
In-Reply-To: <20170105175619.GA56877@google.com>
Hello Brian,
Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> >
> > * Tony Lindgren <tony@atomide.com> [170105 07:37]:
> > >
> > > * Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
> > > >
> > > > To improve NAND safety we updated the partition layout.
> > > > Added barebox backup partition and removed kernel and oftree
> > > > partition. They are kept in ubi now.
> > > What about the users with earlier partition tables?
> > >
> > > Please read about "flag day" changes, typically they are not
> > > acceptable.
> > Adding Brian and Adam to Cc. Can you guys come up with some
> > solution on this?
> I don't have much context for this thread, and no I don't plan to
> solve
> your problems for you. But I can provide tips!
>
> >
> > I'm suggesting we leave the kernel nodes empty and let u-boot
> > populate them, so maybe you guys can discuss this on the related
> > lists.
> That's an option. I've worked with platforms that did something like
> this, and that's really one of the only ways you can handle putting
> partition information in the device tree. You're really hamstringing
> yourself when you put all the partition information in the device
> tree.
> And it's just dumb once that gets codified in the kernel source tree.
>
In our case the bootloader does pass the partition table to the kernel.
So it gets overwritten anyway. This was just more for backup,
if someone uses a different bootloader. But I'm fine with removing the
nand partition table completely from the kernel device tree.
Same with the SPI nor partition table.
I will send patches for this.
Regards,
Teresa
> The best solution would be to try to migrate away from static device
> tree representations of partition info entirely. UBI volumes are best
> where possible. If not, then some other kind of on-flash data
> structures
> (along the lines of a GPT) with a corresponding MTD partition parser
> is
> an OK alternative. Unfortunately, there isn't any good standard
> format
> for this on MTD, so it's typically all custom -- and so people use
> the
> easiest approach: device tree. And it's even more difficult with
> NAND,
> which has reliability problems, especially with static data (e.g.,
> read
> disturb).
>
> Anyway, the parser solution is helpful only if one can properly fix
> the
> "flag day" first. And it requires a little bit more work to be
> generally
> useful; I posted some work for this over a year ago, but bikeshedding
> brought it down.
>
> >
> > The rest of the series looks fine to me so applying it into
> > omap-for-v4.11/dt.
> Brian
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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