* [PATCH 1/8] ARM: dts: armada-370-rd: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-03 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102022249.10657-2-f.fainelli@gmail.com>
> +
> + switch: switch at 10 {
> + compatible = "marvell,mv88e6085";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <16>;
Hummm, a device tree question. switch at 10, reg = <16>. Is there an
implicit understanding that the 10 is hex?
Andrew
^ permalink raw reply
* [PATCH 0/8] ARM: dts: Switch to new DSA binding
From: Andrew Lunn @ 2017-01-03 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eg0kf75m.fsf@free-electrons.com>
> The series looks OK. However I would like to have a reviewed by from
> Andrew who know well the mvebu platform and the DSA subsystem.
Hi Gregory
Yes, i was planning on reviewing, and testing on at least three of
these platforms.
Since this is mvebu/arm-soc and not netdev, i may take a week or so
before i get around to it. netdev is too fast some times.
Andrew
^ permalink raw reply
* [PATCH 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Krzysztof Kozlowski @ 2017-01-03 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH0tnjkqF_7DChLSvzs3C369mkb_HZmyrf3cc0T-UcBZ4A@mail.gmail.com>
On Wed, Jan 04, 2017 at 12:29:23AM +0900, Chanwoo Choi wrote:
> Hi Andi,
>
> 2017-01-03 23:40 GMT+09:00 Andi Shyti <andi@etezian.org>:
> > Hi,
> >
> >> FWIW, I also agree with Chanwoo that the difference is too small to
> >> need a common .dtsi file.
> >
> > in principle I don't like "switching on and off" properties by
> > overwriting them with "status = disable", unless it's really
> > necessary (and this case is not). Even for small differences. It
> > makes the DTS harder to read and duplicates nodes with different
> > values throughout the DTS include chain.
I agree.
> >
> > In my opinion this approach should be discouraged.
> >
> > Besides, there are other overwritten differences in tm2e.dts that
> > I think should be separated as well. The "common" file approach is
> > widely used in arm/boot/dts/exynos* files.
I agree. Mostly we use:
1. Common DTSI and final addons/customizations in DTS.
2. Several common DTSI for specific parts (like sound).
> > The "status = disable" looks to me more like a temporary hack
> > rather than a permanent solution.
> >
> > In any case, still up to you :)
> >
> > Andi
>
> I think that "status=disabled" of hsi2c_9 is not hack. The overwrite
> is possible for Device-tree. But, there is just difference how to
> support them with some method.
>
> Except for touchkey, all peripheral device are same on both tm2 and
> tm2e. There are only small difference for a few property value.
>
> To understand the difference between tm2 and tm2e, I made the patch
> (it is not complete version). If we implement the following patch, we
> support both tm2 and tm2e. So, I think that it is not complex to
> understand the h/w difference between tm2 and tm2e.
The difference below (I removed it from the quote) is indeed very small,
thanks Chanwoo for pointing this. However having common DTSI should not
end with much bigger final diff between files. I mean that it should be
the same amount of lines in total...
Actually, after applying this patch, the final exynos5433-tm2e.dts is
exactly the same as before. To me, this is a indication that a common
file is a good approach.
>From a separate Javier's mail:
> On 01/03/2017 11:40 AM, Andi Shyti wrote:
> > Hi,
> >
> >> FWIW, I also agree with Chanwoo that the difference is too small to
> >> need a common .dtsi file.
> >
> > in principle I don't like "switching on and off" properties by
> > overwriting them with "status = disable", unless it's really
>
> This is a very good point. It would had been different if it was the
> opposite and tm2e had to enable the device node, but disabling it is
> indeed more confusing.
> On 01/03/2017 11:40 AM, Andi Shyti wrote:
> > Hi,
> >
> >> FWIW, I also agree with Chanwoo that the difference is too small to
> >> need a common .dtsi file.
> >
> > in principle I don't like "switching on and off" properties by
> > overwriting them with "status = disable", unless it's really
>
> This is a very good point. It would had been different if it was the
> opposite and tm2e had to enable the device node, but disabling it is
> indeed more confusing.
I agree, 'status = disable' in final DTS is not a common pattern and
to me when reading, it makes me wonder what was the author's intention.
Also including a DTS in DTS is not a common pattern, neither. It appears
(git grep include arch/arm/boot/dts | grep 'dts"') in few places but it
is not obvious. At least to me.
Overall, I prefer the common approach.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/8] ARM: dts: Switch to new DSA binding
From: Gregory CLEMENT @ 2017-01-03 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102022249.10657-1-f.fainelli@gmail.com>
Hi Florian,
On lun., janv. 02 2017, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Hi all,
>
> This patch series converts the in-tree users to utilize the new (relatively)
> DSA binding that was introduced with commit 8c5ad1d6179d ("net: dsa: Document
> new binding"). The legacy binding node is kept included, but is marked
> disabled.
>
> In about 2-3 releases we may consider removing the old DSA binding entirely
> from the kernel.
The series looks OK. However I would like to have a reviewed by from
Andrew who know well the mvebu platform and the DSA subsystem.
Also there's few fixes needed for the v2.
Thanks,
Gregory
>
> Thank you!
>
> Florian Fainelli (8):
> ARM: dts: armada-370-rd: Utilize new DSA binding
> ARM: dts: armada-38x: Utilize new DSA binding
> ARM: dts: armada-388-clearfog: Utilize new DSA binding
> ARM: dts: armada-xp-linksys-mamba: Utilize new DSA binding
> ARM: dts: kirkwood-dir665: Utilize new DSA binding
> ARM: dts: kirkwood-linksys-viper: Utilize new DSA binding
> ARM: dts: kirkwood-mv88f6281gtw-ge: Utilize new DSA binding
> ARM: dts: kirkwood-rd88f6281: Utilize new DSA binding
>
> arch/arm/boot/dts/armada-370-rd.dts | 44 +++++++++++++++++
> arch/arm/boot/dts/armada-385-linksys.dtsi | 52 ++++++++++++++++++++-
> arch/arm/boot/dts/armada-388-clearfog.dts | 65 ++++++++++++++++++++++++++
> arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 53 +++++++++++++++++++++
> arch/arm/boot/dts/kirkwood-dir665.dts | 49 +++++++++++++++++++
> arch/arm/boot/dts/kirkwood-linksys-viper.dts | 49 +++++++++++++++++++
> arch/arm/boot/dts/kirkwood-mv88f6281gtw-ge.dts | 49 +++++++++++++++++++
> arch/arm/boot/dts/kirkwood-rd88f6281-z0.dts | 11 +++++
> arch/arm/boot/dts/kirkwood-rd88f6281.dtsi | 44 +++++++++++++++++
> 9 files changed, 415 insertions(+), 1 deletion(-)
>
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/8] ARM: dts: armada-38x: Utilize new DSA binding
From: Gregory CLEMENT @ 2017-01-03 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102022249.10657-3-f.fainelli@gmail.com>
Hi Florian,
You should use the board name in the topic, ie:
"ARM: dts: armada-385-linksys: Utilize new DSA binding"
Thanks,
Gregory
On lun., janv. 02 2017, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net: dsa:
> Document new binding"). The legacy binding node is kept included, but is marked
> disabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/boot/dts/armada-385-linksys.dtsi | 52 ++++++++++++++++++++++++++++++-
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-linksys.dtsi b/arch/arm/boot/dts/armada-385-linksys.dtsi
> index 8f0e508f64ae..20d5e8b00f2d 100644
> --- a/arch/arm/boot/dts/armada-385-linksys.dtsi
> +++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
> @@ -103,8 +103,56 @@
> };
> };
>
> - mdio {
> + mdio at 72004 {
> status = "okay";
> +
> + switch at 0 {
> + compatible = "marvell,mv88e6095";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + label = "lan4";
> + };
> +
> + port at 1 {
> + reg = <1>;
> + label = "lan3";
> + };
> +
> + port at 2 {
> + reg = <2>;
> + label = "lan2";
> + };
> +
> + port at 3 {
> + reg = <3>;
> + label = "lan1";
> + };
> +
> + port at 4 {
> + reg = <4>;
> + label = "wan";
> + };
> +
> + port at 5 {
> + reg = <5>;
> + label = "cpu";
> + ethernet = <ð2>;
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> };
>
> sata at a8000 {
> @@ -261,6 +309,8 @@
> };
>
> dsa at 0 {
> + status = "disabled";
> +
> compatible = "marvell,dsa";
> #address-cells = <2>;
> #size-cells = <0>;
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
From: Kirill A. Shutemov @ 2017-01-03 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrV_qejd-Ozqo4vTqz=LuukMUPeQ7EVUQbfTxs_xNbO3oQ@mail.gmail.com>
On Mon, Jan 02, 2017 at 10:08:28PM -0800, Andy Lutomirski wrote:
> On Mon, Jan 2, 2017 at 12:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday, December 27, 2016 4:54:13 AM CET Kirill A. Shutemov wrote:
> >> As with other resources you can set the limit lower than current usage.
> >> It would affect only future virtual address space allocations.
>
> I still don't buy all these use cases:
>
> >>
> >> Use-cases for new rlimit:
> >>
> >> - Bumping the soft limit to RLIM_INFINITY, allows current process all
> >> its children to use addresses above 47-bits.
>
> OK, I get this, but only as a workaround for programs that make
> assumptions about the address space and don't use some mechanism (to
> be designed?) to work correctly in spite of a larger address space.
I guess you've misread the case. It's opt-in for large adrress space, not
other way around.
I believe 47-bit VA by default is right way to go to make the transition
without breaking userspace.
> >> - Bumping the soft limit to RLIM_INFINITY after fork(2), but before
> >> exec(2) allows the child to use addresses above 47-bits.
>
> Ditto.
>
> >>
> >> - Lowering the hard limit to 47-bits would prevent current process all
> >> its children to use addresses above 47-bits, unless a process has
> >> CAP_SYS_RESOURCES.
>
> I've tried and I can't imagine any reason to do this.
That's just if something went wrong and we want to stop an application
from use addresses above 47-bit.
> >> - It?s also can be handy to lower hard or soft limit to arbitrary
> >> address. User-mode emulation in QEMU may lower the limit to 32-bit
> >> to emulate 32-bit machine on 64-bit host.
>
> I don't understand. QEMU user-mode emulation intercepts all syscalls.
> What QEMU would *actually* want is a way to say "allocate me some
> memory with the high N bits clear". mmap-via-int80 on x86 should be
> fixed to do this, but a new syscall with an explicit parameter would
> work, as would a prctl changing the current limit.
Look at mess in mmap_find_vma(). QEmu has to guess where is free virtual
memory. That's unnessesary complex.
prctl would work for this too. new-mmap would *not*: there are more ways
to allocate vitual address space: shmat(), mremap(). Changing all of them
just for this is stupid.
> >>
> >> TODO:
> >> - port to non-x86;
> >>
> >> Not-yet-signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> >> Cc: linux-api at vger.kernel.org
> >
> > This seems to nicely address the same problem on arm64, which has
> > run into the same issue due to the various page table formats
> > that can currently be chosen at compile time.
>
> On further reflection, I think this has very little to do with paging
> formats except insofar as paging formats make us notice the problem.
> The issue is that user code wants to be able to assume an upper limit
> on an address, and it gets an upper limit right now that depends on
> architecture due to paging formats. But someone really might want to
> write a *portable* 64-bit program that allocates memory with the high
> 16 bits clear. So let's add such a mechanism directly.
>
> As a thought experiment, what if x86_64 simply never allocated "high"
> (above 2^47-1) addresses unless a new mmap-with-explicit-limit syscall
> were used? Old glibc would continue working. Old VMs would work.
> New programs that want to use ginormous mappings would have to use the
> new syscall. This would be totally stateless and would have no issues
> with CRIU.
Except, we need more than mmap as I mentioned.
And what about stack? I'm not sure that everybody would be happy with
stack in the middle of address space.
> If necessary, we could also have a prctl that changes a
> "personality-like" limit that is in effect when the old mmap was used.
> I say "personality-like" because it would reset under exactly the same
> conditions that personality resets itself.
>
> Thoughts?
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
--
Kirill A. Shutemov
^ permalink raw reply
* [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Olliver Schinagl @ 2017-01-03 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212122427.4ixo7terrlvnuqmd@lukather>
Hey Maxime,
Happy new year! I'm sorry that I missed your previous mail! I completely
looked over it. Sorry!
On 12-12-16 13:24, Maxime Ripard wrote:
> On Thu, Dec 08, 2016 at 02:23:39PM +0100, Olliver Schinagl wrote:
>> Hey Maxime,
>>
>> first off, also sorry for the slow delay :) (pun not intended)
>>
>> On 27-08-16 00:19, Maxime Ripard wrote:
>>> On Thu, Aug 25, 2016 at 07:50:10PM +0200, Olliver Schinagl wrote:
>>>> When we inform the PWM block to stop toggeling the output, we may end up
>>>> in a state where the output is not what we would expect (e.g. not the
>>>> low-pulse) but whatever the output was at when the clock got disabled.
>>>>
>>>> To counter this we have to wait for maximally the time of one whole
>>>> period to ensure the pwm hardware was able to finish. Since we already
>>>> told the PWM hardware to disable it self, it will not continue toggling
>>>> but merly finish its current pulse.
>>>>
>>>> If a whole period is considered to much, it may be contemplated to use a
>>>> half period + a little bit to ensure we get passed the transition.
>>>>
>>>> Signed-off-by: Olliver Schinagl<oliver@schinagl.nl>
>>>> ---
>>>> drivers/pwm/pwm-sun4i.c | 11 +++++++++++
>>>> 1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
>>>> index 03a99a5..5e97c8a 100644
>>>> --- a/drivers/pwm/pwm-sun4i.c
>>>> +++ b/drivers/pwm/pwm-sun4i.c
>>>> @@ -8,6 +8,7 @@
>>>> #include <linux/bitops.h>
>>>> #include <linux/clk.h>
>>>> +#include <linux/delay.h>
>>>> #include <linux/err.h>
>>>> #include <linux/io.h>
>>>> #include <linux/module.h>
>>>> @@ -245,6 +246,16 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
>>>> spin_lock(&sun4i_pwm->ctrl_lock);
>>>> val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
>>>> val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
>>>> + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
>>>> + spin_unlock(&sun4i_pwm->ctrl_lock);
>>>> +
>>>> + /* Allow for the PWM hardware to finish its last toggle. The pulse
>>>> + * may have just started and thus we should wait a full period.
>>>> + */
>>>> + ndelay(pwm_get_period(pwm));
>>> Can't that use the ready bit as well?
>>
>> I started to implement our earlier discussed suggestions, but I do not think
>> they will work. The read bit is not to let the user know it is ready with
>> all of its commands, but only if the period registers are ready. I think it
>> is some write lock while it copies the data into its internal control loop.
>> From the manual:
>> PWM0 period register ready.
>> 0: PWM0 period register is ready to write,
>> 1: PWM0 period register is busy.
>>
>>
>> So no, I don't think i can use the ready bit here at all. The only thing we
>> can do here, but I doubt it's worth it, is to read the period register,
>> caluclate a time from it, and then ndelay(pwm_get_period(pwm) - ran_time)
>>
>> The only 'win' then is that we could are potentially not waiting the full
>> pwm period, but only a fraction of it. Since we are disabling the hardware
>> (for power reasons) anyway, I don't think this is any significant win,
>> except for extreme situations. E.g. we have a pwm period of 10 seconds, we
>> disable it after 9.9 second, and now we have to wait for 10 seconds before
>> the pwm_disable is finally done. So this could in that case be reduced to
>> then only wait for 0.2 seconds since it is 'done' sooner.
>>
>> However that optimization is also not 'free'. We have to read the period
>> register and calculate back the time. I suggest to do that when reworking
>> this driver to work with atomic mode, and merge this patch 'as is' to
>> atleast fix te bug where simply not finish properly.
>
> That whole discussion made me realise something that is really
> bad. AFAIK, pwm_get_period returns a 32 bits register, which means a
> theorical period of 4s. Busy looping during 4 seconds is already very
> bad, as you basically kill one CPU during that time, but doing so in a
> (potentially) atomic context is even worse.
Well technically, isn't it a 16 bit register? (half for the period,
other half for the duty cycle?) Anyway, I think the delay can be far
exceeding 4 seconds (though I haven't checked what the PWM delay max
option is).
Anyway, you are right, we should absolutely not do this!
>
> NACK.
Absolutely! But what do you suggest? Would usleep (or msleep) instead of
the ndelay work properly?
>
> Maxime
>
^ permalink raw reply
* [PATCH] arm64: defconfig: enable XORv2 for Marvell Armada 7K/8K
From: Gregory CLEMENT @ 2017-01-03 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482420258-13888-1-git-send-email-thomas.petazzoni@free-electrons.com>
Hi Thomas,
On jeu., d?c. 22 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> This commit enables the XORv2 DMA driver, which is used on the ARM64
> Marvell Armada 7K and 8K platforms.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Applied on mvebu/defconfig64
Thanks,
Gregory
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index dab2cb0..f8b6435 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -371,6 +371,7 @@ CONFIG_RTC_DRV_TEGRA=y
> CONFIG_RTC_DRV_XGENE=y
> CONFIG_RTC_DRV_S3C=y
> CONFIG_DMADEVICES=y
> +CONFIG_MV_XOR_V2=y
> CONFIG_PL330_DMA=y
> CONFIG_TEGRA20_APB_DMA=y
> CONFIG_QCOM_BAM_DMA=y
> --
> 2.7.4
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 4/5] arm64: Use __tlbi_dsb() macros in KVM code
From: Mark Rutland @ 2017-01-03 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229224335.13531-4-cov@codeaurora.org>
On Thu, Dec 29, 2016 at 05:43:34PM -0500, Christopher Covington wrote:
> Refactor the KVM code to use the newly introduced __tlbi_dsb macros, which
> will allow an errata workaround that repeats tlbi dsb sequences to only
> change one location. This is not intended to change the generated assembly
> and comparing before and after vmlinux objdump shows no functional changes.
> @@ -40,9 +41,7 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> * complete (S1 + S2) walk based on the old Stage-2 mapping if
> * the Stage-1 invalidation happened first.
> */
> - dsb(ish);
Looks like this got accidentally removed. AFAICT it is still necessary.
> - asm volatile("tlbi vmalle1is" : : );
> - dsb(ish);
> + __tlbi_dsb(vmalle1is, ish);
> isb();
Thanks,
Mark.
^ permalink raw reply
* [PATCH] pwm: sunxi: wait for the READY bit
From: Olliver Schinagl @ 2017-01-03 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103145732.2108-1-alexandre.belloni@free-electrons.com>
Hey Alexandre,
I've sent several patches regarding pwm a while ago, sadly you never
responded [0]. So I guess this is a follow up from that?
I couldn't quickly find the resubmitted version however.
Anyway, see below for my comments.
On 03-01-17 15:57, Alexandre Belloni wrote:
> Most of the call sites in the kernel are not really prepared to handle
> -EBUSY when calling pwm_config(). This means that they will either fail
> silently or fail without letting the user retry at a later time.
>
> This can be seen for example when using pwm-backlight (the most common use
> case for this driver). It will first call pwm_config() with a 0 duty cycle
> and disable the pwm. Then it will call pwm_config() that fails because the
> pwm had no chance to update its period internally and
> pwm_enable() ending up with a duty cycle of 0.
>
> Instead, actually wait for the RDY bit to go low before continuing.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/pwm/pwm-sun4i.c | 26 ++++++++++++++++----------
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index b0803f6c64d9..be489388e006 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -10,6 +10,7 @@
> #include <linux/clk.h>
> #include <linux/err.h>
> #include <linux/io.h>
> +#include <linux/iopoll.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_device.h>
> @@ -103,7 +104,7 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> u32 prd, dty, val, clk_gate;
> u64 clk_rate, div = 0;
> unsigned int prescaler = 0;
> - int err;
> + int err = 0;
>
> clk_rate = clk_get_rate(sun4i_pwm->clk);
>
> @@ -154,18 +155,22 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> spin_lock(&sun4i_pwm->ctrl_lock);
> val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
>
> - if (sun4i_pwm->data->has_rdy && (val & PWM_RDY(pwm->hwpwm))) {
> - spin_unlock(&sun4i_pwm->ctrl_lock);
> - clk_disable_unprepare(sun4i_pwm->clk);
> - return -EBUSY;
> - }
> -
> clk_gate = val & BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> - if (clk_gate) {
> - val &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> +
> + if (sun4i_pwm->data->has_rdy && (val & PWM_RDY(pwm->hwpwm))) {
> + val |= BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> +
> + err = readl_poll_timeout(sun4i_pwm->base + PWM_CTRL_REG, val,
> + !(val & PWM_RDY(pwm->hwpwm)), 400,
> + 500000);
> + if (err)
> + goto finish;
> }
>
What happens on sun4i here? sun4i does not have the RDY flag, but it
does need the PWM_CLK_GATING to be active.
maybe only the readl_poll_timeout() should be guarded by the has_rdy,
where you poll the register as you do now, and in the else just have a
'known safe delay' to emulate the has_rdy behavior? I'm guessing a few
clock cycles of the PWM block. I don't think the documentation states
how long this could/should be.
With my 'wait before disable' patch [1] I run into the same issue, I
think. We do not know how long to wait before the hardware is ready.
> + val &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> +
> val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> val &= ~BIT_CH(PWM_PRESCAL_MASK, pwm->hwpwm);
> val |= BIT_CH(prescaler, pwm->hwpwm);
> @@ -174,6 +179,7 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> val = (dty & PWM_DTY_MASK) | PWM_PRD(prd);
> sun4i_pwm_writel(sun4i_pwm, val, PWM_CH_PRD(pwm->hwpwm));
>
> +finish:
> if (clk_gate) {
> val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> val |= clk_gate;
> @@ -183,7 +189,7 @@ static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> spin_unlock(&sun4i_pwm->ctrl_lock);
> clk_disable_unprepare(sun4i_pwm->clk);
>
> - return 0;
> + return err;
> }
>
> static int sun4i_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm,
>
[0] https://patchwork.kernel.org/patch/9299635/
[1] https://lkml.org/lkml/2016/9/26/91
^ permalink raw reply
* [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
From: Mark Rutland @ 2017-01-03 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229224335.13531-2-cov@codeaurora.org>
Hi,
On Thu, Dec 29, 2016 at 05:43:32PM -0500, Christopher Covington wrote:
> +config QCOM_FALKOR_E1003_RESERVED_ASID
> + int
> + default 1
> + depends on QCOM_FALKOR_ERRATUM_1003
> +
I don't think this needs to be configurable, so let's drop this into a
header, e.g. drop:
#define FALKOR_RESERVED_ASID 1
... in <asm/mmu_context.h>, protecting the rest with an ifndef
__ASSEMBLY__ guard.
[...]
> +#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
> +alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
> + mrs x2, ttbr0_el1 // get cuurent TTBR0_EL1
> + mov x3, #CONFIG_QCOM_FALKOR_ERRATUM_1003 // reserved ASID
Wrong macro? That's not the ASID.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 5/5] mfd: twl: use mfd_add_devices for TWL6032 regulator
From: Lee Jones @ 2017-01-03 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161126181326.14951-6-Nicolae_Rosia@mentor.com>
On Sat, 26 Nov 2016, Nicolae Rosia wrote:
> TWL6032 regulator driver uses the drvdata twl_priv pointer.
> In order to avoid accessing an invalid drvdata
> when the driver gets unbinded, make sure we remove the
> child devices before deleting the drvdata.
This doesn't really describe the change.
Surely we're really just registering the regulator driver?
The fact that we then remove the device during .remove() is
incidental.
> Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
> ---
> drivers/mfd/twl-core.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index 409b836..1e94364 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -43,6 +43,7 @@
> #include <linux/of_platform.h>
> #include <linux/irq.h>
> #include <linux/irqdomain.h>
> +#include <linux/mfd/core.h>
>
> #include <linux/regulator/machine.h>
>
> @@ -155,8 +156,16 @@ int twl4030_init_irq(struct device *dev, int irq_num);
> int twl4030_exit_irq(void);
> int twl4030_init_chip_irq(const char *chip);
>
> +
?
> static struct twlcore *twl_priv;
>
> +static struct mfd_cell twl6032_devs[] = {
> + {
> + .name = "twl6032-regulator",
> + .of_compatible = "ti,twl6032-regulator",
> + },
> +};
> +
> static struct twl_mapping twl4030_map[] = {
> /*
> * NOTE: don't change this table without updating the
> @@ -665,6 +674,8 @@ static int twl_remove(struct i2c_client *client)
> unsigned i, num_slaves;
> int status;
>
> + mfd_remove_devices(&client->dev);
> +
> if (twl_class_is_4030())
> status = twl4030_exit_irq();
> else
> @@ -834,6 +845,17 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> TWL4030_DCDC_GLOBAL_CFG);
> }
>
> + if (id->driver_data & TWL6032_SUBCLASS) {
> + status = mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
> + twl6032_devs, ARRAY_SIZE(twl6032_devs),
> + NULL, 0, NULL);
> + if (status != 0) {
> + dev_err(&client->dev, "failed to add mfd devices: %d\n",
> + status);
> + goto fail;
> + }
> + }
> +
> fail:
> if (status < 0)
> twl_remove(client);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 3/5] mfd: twl: move structure definitions to a public header
From: Lee Jones @ 2017-01-03 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161126181326.14951-4-Nicolae_Rosia@mentor.com>
On Sat, 26 Nov 2016, Nicolae Rosia wrote:
> We want to get rid of exported symbols and have
> the child devices use structure members directly.
> Move the structure definitions to header and set
> drvdata so child devices can access it.
< Please use all 75 chars allocated to the commitlog before line wrapping >
> Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
> ---
> drivers/mfd/twl-core.c | 27 ++++-----------------------
> include/linux/mfd/twl-core.h | 35 +++++++++++++++++++++++++++++++++++
> 2 files changed, 39 insertions(+), 23 deletions(-)
> create mode 100644 include/linux/mfd/twl-core.h
>
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index e16084e..409b836 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -48,6 +48,7 @@
>
> #include <linux/i2c.h>
> #include <linux/i2c/twl.h>
> +#include <linux/mfd/twl-core.h>
>
> /* Register descriptions for audio */
> #include <linux/mfd/twl4030-audio.h>
> @@ -154,28 +155,7 @@ int twl4030_init_irq(struct device *dev, int irq_num);
> int twl4030_exit_irq(void);
> int twl4030_init_chip_irq(const char *chip);
>
> -/* Structure for each TWL4030/TWL6030 Slave */
> -struct twl_client {
> - struct i2c_client *client;
> - struct regmap *regmap;
> -};
> -
> -/* mapping the module id to slave id and base address */
> -struct twl_mapping {
> - unsigned char sid; /* Slave ID */
> - unsigned char base; /* base address */
> -};
> -
> -struct twl_private {
> - bool ready; /* The core driver is ready to be used */
> - u32 twl_idcode; /* TWL IDCODE Register value */
> - unsigned int twl_id;
> -
> - struct twl_mapping *twl_map;
> - struct twl_client *twl_modules;
> -};
> -
> -static struct twl_private *twl_priv;
> +static struct twlcore *twl_priv;
I'm guessing when you remove the exported functions, you can remove this?
> static struct twl_mapping twl4030_map[] = {
> /*
> @@ -745,7 +725,7 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> goto free;
> }
>
> - twl_priv = devm_kzalloc(&client->dev, sizeof(struct twl_private),
> + twl_priv = devm_kzalloc(&client->dev, sizeof(struct twlcore),
> GFP_KERNEL);
> if (!twl_priv) {
> status = -ENOMEM;
> @@ -803,6 +783,7 @@ twl_probe(struct i2c_client *client, const struct i2c_device_id *id)
> }
>
> twl_priv->ready = true;
> + dev_set_drvdata(&client->dev, twl_priv);
>
> /* setup clock framework */
> clocks_init(&pdev->dev);
> diff --git a/include/linux/mfd/twl-core.h b/include/linux/mfd/twl-core.h
> new file mode 100644
> index 0000000..d1c01b3
> --- /dev/null
> +++ b/include/linux/mfd/twl-core.h
> @@ -0,0 +1,35 @@
> +/*
> + * MFD core driver for the Texas Instruments TWL PMIC family
> + *
> + * Copyright (C) 2016 Nicolae Rosia <nicolae.rosia@gmail.com>
Your sign-off and SoB are different? Why?
> + * 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 __TWL_CORE_H__
> +#define __TWL_CORE_H__
_MFD_
> +/* Structure for each TWL4030/TWL6030 Slave */
> +struct twl_client {
> + struct i2c_client *client;
> + struct regmap *regmap;
> +};
> +
> +/* mapping the module id to slave id and base address */
> +struct twl_mapping {
> + unsigned char sid; /* Slave ID */
> + unsigned char base; /* base address */
> +};
> +
> +struct twlcore {
> + bool ready; /* The core driver is ready to be used */
> + u32 twl_idcode; /* TWL IDCODE Register value */
> + unsigned int twl_id;
> +
> + struct twl_mapping *twl_map;
> + struct twl_client *twl_modules;
> +};
> +
> +#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [sample] A sample program for MRS emulation
From: Suzuki K Poulose @ 2017-01-03 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130162720.GN1574@e103592.cambridge.arm.com>
On 30/11/16 16:27, Dave Martin wrote:
> On Wed, Nov 30, 2016 at 03:15:01PM +0000, Suzuki K Poulose wrote:
>> Here is a sample program which demonstrates how to use mrs
>> emulation to fetch the ID registers.
>
> Are we planning to add this in Documentation/? If so, we might want
> some tweaks (noted below).
Dave,
Thanks for taking a look. Apologies for the late response. We could
either add it to the Documentation or stick it into samples/. I prefer
the Documentation, as it would help the text.
>
>>
>> ----8>----
>> /*
>> * Sample program to demonstrate the MRS emulation
>> * ABI.
>
> overwrapped?
will fix it.
>
>> int main()
>
> (void)
>
>> {
>
> We don't wan't people using the MRS emulation without checking for its
> availability first.
>
> Something like this may work (untested), with the caveat that getauxval()
> is a GNU libc extension, and other environments may require a different
> mechanism to obtain the hwcaps.
>
Makes sense.
> --8<--
>
> #include <sys/auxv.h>
> #include <asm/hwcap.h>
>
> /* ... */
>
> if (!getauxval(AT_HWCAP) & HWCAP_CPUID) {
> fputs("CPUID registers unavailable\n", stderr);
> return 1;
> }
>
> -->8--
Cheers
Suzuki
^ permalink raw reply
* [PATCH 2/5] mfd: twl: remove useless header
From: Lee Jones @ 2017-01-03 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161126181326.14951-3-Nicolae_Rosia@mentor.com>
On Sat, 26 Nov 2016, Nicolae Rosia wrote:
> This header has one user, twl-core.c .
> Remove it before it gets more users.
The header is not useless. It prevents us from having to place
external prototypes into C files.
> Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
> ---
> drivers/mfd/twl-core.c | 8 ++++++--
> drivers/mfd/twl-core.h | 10 ----------
> drivers/mfd/twl4030-irq.c | 2 --
> drivers/mfd/twl6030-irq.c | 2 --
> 4 files changed, 6 insertions(+), 16 deletions(-)
> delete mode 100644 drivers/mfd/twl-core.h
>
> diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
> index 48b0668..e16084e 100644
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -52,8 +52,6 @@
> /* Register descriptions for audio */
> #include <linux/mfd/twl4030-audio.h>
>
> -#include "twl-core.h"
> -
> /*
> * The TWL4030 "Triton 2" is one of a family of a multi-function "Power
> * Management and System Companion Device" chips originally designed for
> @@ -150,6 +148,12 @@
>
> /*----------------------------------------------------------------------*/
>
> +int twl6030_init_irq(struct device *dev, int irq_num);
> +int twl6030_exit_irq(void);
> +int twl4030_init_irq(struct device *dev, int irq_num);
> +int twl4030_exit_irq(void);
> +int twl4030_init_chip_irq(const char *chip);
> +
> /* Structure for each TWL4030/TWL6030 Slave */
> struct twl_client {
> struct i2c_client *client;
> diff --git a/drivers/mfd/twl-core.h b/drivers/mfd/twl-core.h
> deleted file mode 100644
> index 6ff99dc..0000000
> --- a/drivers/mfd/twl-core.h
> +++ /dev/null
> @@ -1,10 +0,0 @@
> -#ifndef __TWL_CORE_H__
> -#define __TWL_CORE_H__
> -
> -extern int twl6030_init_irq(struct device *dev, int irq_num);
> -extern int twl6030_exit_irq(void);
> -extern int twl4030_init_irq(struct device *dev, int irq_num);
> -extern int twl4030_exit_irq(void);
> -extern int twl4030_init_chip_irq(const char *chip);
> -
> -#endif /* __TWL_CORE_H__ */
> diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
> index b46c0cf..000c231 100644
> --- a/drivers/mfd/twl4030-irq.c
> +++ b/drivers/mfd/twl4030-irq.c
> @@ -35,8 +35,6 @@
> #include <linux/irqdomain.h>
> #include <linux/i2c/twl.h>
>
> -#include "twl-core.h"
> -
> /*
> * TWL4030 IRQ handling has two stages in hardware, and thus in software.
> * The Primary Interrupt Handler (PIH) stage exposes status bits saying
> diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
> index 5357450..63eca76 100644
> --- a/drivers/mfd/twl6030-irq.c
> +++ b/drivers/mfd/twl6030-irq.c
> @@ -42,8 +42,6 @@
> #include <linux/irqdomain.h>
> #include <linux/of_device.h>
>
> -#include "twl-core.h"
> -
> /*
> * TWL6030 (unlike its predecessors, which had two level interrupt handling)
> * three interrupt registers INT_STS_A, INT_STS_B and INT_STS_C.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Chanwoo Choi @ 2017-01-03 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103144056.4ft2ohmhgmezeney@jack.zhora.eu>
Hi Andi,
2017-01-03 23:40 GMT+09:00 Andi Shyti <andi@etezian.org>:
> Hi,
>
>> FWIW, I also agree with Chanwoo that the difference is too small to
>> need a common .dtsi file.
>
> in principle I don't like "switching on and off" properties by
> overwriting them with "status = disable", unless it's really
> necessary (and this case is not). Even for small differences. It
> makes the DTS harder to read and duplicates nodes with different
> values throughout the DTS include chain.
>
> In my opinion this approach should be discouraged.
>
> Besides, there are other overwritten differences in tm2e.dts that
> I think should be separated as well. The "common" file approach is
> widely used in arm/boot/dts/exynos* files.
>
> The "status = disable" looks to me more like a temporary hack
> rather than a permanent solution.
>
> In any case, still up to you :)
>
> Andi
I think that "status=disabled" of hsi2c_9 is not hack. The overwrite
is possible for Device-tree. But, there is just difference how to
support them with some method.
Except for touchkey, all peripheral device are same on both tm2 and
tm2e. There are only small difference for a few property value.
To understand the difference between tm2 and tm2e, I made the patch
(it is not complete version). If we implement the following patch, we
support both tm2 and tm2e. So, I think that it is not complex to
understand the h/w difference between tm2 and tm2e.
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 1db4e7f..09b6935 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -18,6 +18,17 @@
compatible = "samsung,tm2e", "samsung,exynos5433";
};
+&display_timings {
+ clock-frequency = <16523724>;
+ hactive = <1600>;
+};
+
+&hsi2c_9 {
+ /* TM2E don't use the separate touchkey device. Instead, touchscreen
+ * device support the touchkey device.*/
+ status = "disabled";
+};
+
&ldo23_reg {
regulator-name = "CAM_SEN_CORE_1.025V_AP";
regulator-max-microvolt = <1050000>;
@@ -39,3 +50,7 @@
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
+
+&touchscreen {
+ x-size = "1599";
+};
--
Best Regards,
Chanwoo Choi
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Icenowy Zheng @ 2017-01-03 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103152534.20118-1-icenowy@aosc.xyz>
Lichee Pi Zero features a USB OTG port.
Add support for it.
Note: in order to use the Host mode, the board must be powered via the
+5V and GND pins.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 0099affc6ce3..3d9168cbaeca 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -71,3 +71,13 @@
pinctrl-names = "default";
status = "okay";
};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: sunxi: add usb_otg and usbphy node for V3s SoC
From: Icenowy Zheng @ 2017-01-03 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103152534.20118-1-icenowy@aosc.xyz>
V3s SoC features a USB PHY controller and a MUSB OTG controller.
Add device nodes for them.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 084da7474afb..ebefc0fefef2 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -153,6 +153,33 @@
#size-cells = <0>;
};
+ usb_otg: usb at 01c19000 {
+ compatible = "allwinner,sun8i-h3-musb";
+ reg = <0x01c19000 0x0400>;
+ clocks = <&ccu CLK_BUS_OTG>;
+ resets = <&ccu RST_BUS_OTG>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mc";
+ phys = <&usbphy 0>;
+ phy-names = "usb";
+ extcon = <&usbphy 0>;
+ status = "disabled";
+ };
+
+ usbphy: phy at 01c19400 {
+ compatible = "allwinner,sun8i-v3s-usb-phy";
+ reg = <0x01c19400 0x2c>,
+ <0x01c1a800 0x4>;
+ reg-names = "phy_ctrl",
+ "pmu0";
+ clocks = <&ccu CLK_USB_PHY0>;
+ clock-names = "usb0_phy";
+ resets = <&ccu RST_USB_PHY0>;
+ reset-names = "usb0_reset";
+ status = "disabled";
+ #phy-cells = <1>;
+ };
+
ccu: clock at 01c20000 {
compatible = "allwinner,sun8i-v3s-ccu";
reg = <0x01c20000 0x400>;
--
2.11.0
^ permalink raw reply related
* [PATCH 2/4] musb: sunxi: add support for the variant in H3/V3s SoC
From: Icenowy Zheng @ 2017-01-03 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103152534.20118-1-icenowy@aosc.xyz>
Allwinner H3/V3s features a variant of MUSB controller, which lacks one
endpoint.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
.../bindings/usb/allwinner,sun4i-a10-musb.txt | 4 +--
drivers/usb/musb/sunxi.c | 35 ++++++++++++++++++++--
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
index 862cd7c79805..d9b42da016f3 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -2,8 +2,8 @@ Allwinner sun4i A10 musb DRC/OTG controller
-------------------------------------------
Required properties:
- - compatible : "allwinner,sun4i-a10-musb", "allwinner,sun6i-a31-musb"
- or "allwinner,sun8i-a33-musb"
+ - compatible : "allwinner,sun4i-a10-musb", "allwinner,sun6i-a31-musb",
+ "allwinner,sun8i-a33-musb" or "allwinner,sun8i-h3-musb"
- reg : mmio address range of the musb controller
- clocks : clock specifier for the musb controller ahb gate clock
- reset : reset specifier for the ahb reset (A31 and newer only)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index d0be0eadd0d9..48ecb1580817 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -645,6 +645,20 @@ static struct musb_fifo_cfg sunxi_musb_mode_cfg[] = {
MUSB_EP_FIFO_SINGLE(5, FIFO_RX, 512),
};
+/* H3/V3s OTG supports only 4 endpoints */
+#define SUNXI_MUSB_MAX_EP_NUM_H3 5
+
+static struct musb_fifo_cfg sunxi_musb_mode_cfg_h3[] = {
+ MUSB_EP_FIFO_SINGLE(1, FIFO_TX, 512),
+ MUSB_EP_FIFO_SINGLE(1, FIFO_RX, 512),
+ MUSB_EP_FIFO_SINGLE(2, FIFO_TX, 512),
+ MUSB_EP_FIFO_SINGLE(2, FIFO_RX, 512),
+ MUSB_EP_FIFO_SINGLE(3, FIFO_TX, 512),
+ MUSB_EP_FIFO_SINGLE(3, FIFO_RX, 512),
+ MUSB_EP_FIFO_SINGLE(4, FIFO_TX, 512),
+ MUSB_EP_FIFO_SINGLE(4, FIFO_RX, 512),
+};
+
static struct musb_hdrc_config sunxi_musb_hdrc_config = {
.fifo_cfg = sunxi_musb_mode_cfg,
.fifo_cfg_size = ARRAY_SIZE(sunxi_musb_mode_cfg),
@@ -656,6 +670,18 @@ static struct musb_hdrc_config sunxi_musb_hdrc_config = {
.dma = 0,
};
+static struct musb_hdrc_config sunxi_musb_hdrc_config_h3 = {
+ .fifo_cfg = sunxi_musb_mode_cfg_h3,
+ .fifo_cfg_size = ARRAY_SIZE(sunxi_musb_mode_cfg_h3),
+ .multipoint = true,
+ .dyn_fifo = true,
+ .soft_con = true,
+ .num_eps = SUNXI_MUSB_MAX_EP_NUM_H3,
+ .ram_bits = SUNXI_MUSB_RAM_BITS,
+ .dma = 0,
+};
+
+
static int sunxi_musb_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data pdata;
@@ -698,7 +724,10 @@ static int sunxi_musb_probe(struct platform_device *pdev)
return -EINVAL;
}
pdata.platform_ops = &sunxi_musb_ops;
- pdata.config = &sunxi_musb_hdrc_config;
+ if (!of_device_is_compatible(np, "allwinner,sun8i-h3-musb"))
+ pdata.config = &sunxi_musb_hdrc_config;
+ else
+ pdata.config = &sunxi_musb_hdrc_config_h3;
glue->dev = &pdev->dev;
INIT_WORK(&glue->work, sunxi_musb_work);
@@ -710,7 +739,8 @@ static int sunxi_musb_probe(struct platform_device *pdev)
if (of_device_is_compatible(np, "allwinner,sun6i-a31-musb"))
set_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags);
- if (of_device_is_compatible(np, "allwinner,sun8i-a33-musb")) {
+ if (of_device_is_compatible(np, "allwinner,sun8i-a33-musb") ||
+ of_device_is_compatible(np, "allwinner,sun8i-h3-musb")) {
set_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags);
set_bit(SUNXI_MUSB_FL_NO_CONFIGDATA, &glue->flags);
}
@@ -804,6 +834,7 @@ static const struct of_device_id sunxi_musb_match[] = {
{ .compatible = "allwinner,sun4i-a10-musb", },
{ .compatible = "allwinner,sun6i-a31-musb", },
{ .compatible = "allwinner,sun8i-a33-musb", },
+ { .compatible = "allwinner,sun8i-h3-musb", },
{}
};
MODULE_DEVICE_TABLE(of, sunxi_musb_match);
--
2.11.0
^ permalink raw reply related
* [PATCH 1/4] phy: sun4i-usb: add support for V3s USB PHY
From: Icenowy Zheng @ 2017-01-03 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103152534.20118-1-icenowy@aosc.xyz>
Allwinner V3s come with a USB PHY controller slightly different to other
SoCs, with only one PHY.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
drivers/phy/phy-sun4i-usb.c | 14 +++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 287150db6db4..e42334258185 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -10,6 +10,7 @@ Required properties:
* allwinner,sun8i-a23-usb-phy
* allwinner,sun8i-a33-usb-phy
* allwinner,sun8i-h3-usb-phy
+ * allwinner,sun8i-v3s-usb-phy
* allwinner,sun50i-a64-usb-phy
- reg : a list of offset + length pairs
- reg-names :
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index bf28a0fdd569..4102841a8ad2 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -99,6 +99,7 @@ enum sun4i_usb_phy_type {
sun6i_a31_phy,
sun8i_a33_phy,
sun8i_h3_phy,
+ sun8i_v3s_phy,
sun50i_a64_phy,
};
@@ -188,7 +189,8 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, u32 addr, u32 data,
spin_lock_irqsave(&phy_data->reg_lock, flags);
if (phy_data->cfg->type == sun8i_a33_phy ||
- phy_data->cfg->type == sun50i_a64_phy) {
+ phy_data->cfg->type == sun50i_a64_phy ||
+ phy_data->cfg->type == sun8i_v3s_phy) {
/* A33 or A64 needs us to set phyctl to 0 explicitly */
writel(0, phyctl);
}
@@ -825,6 +827,15 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.enable_pmu_unk1 = true,
};
+static const struct sun4i_usb_phy_cfg sun8i_v3s_cfg = {
+ .num_phys = 1,
+ .type = sun8i_v3s_phy,
+ .disc_thresh = 3,
+ .phyctl_offset = REG_PHYCTL_A33,
+ .dedicated_clocks = true,
+ .enable_pmu_unk1 = true,
+};
+
static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
.num_phys = 2,
.type = sun50i_a64_phy,
@@ -842,6 +853,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] = {
{ .compatible = "allwinner,sun8i-a23-usb-phy", .data = &sun8i_a23_cfg },
{ .compatible = "allwinner,sun8i-a33-usb-phy", .data = &sun8i_a33_cfg },
{ .compatible = "allwinner,sun8i-h3-usb-phy", .data = &sun8i_h3_cfg },
+ { .compatible = "allwinner,sun8i-v3s-usb-phy", .data = &sun8i_v3s_cfg },
{ .compatible = "allwinner,sun50i-a64-usb-phy",
.data = &sun50i_a64_cfg},
{ },
--
2.11.0
^ permalink raw reply related
* [PATCH 0/4] Add support for the USB OTG function of Allwinner V3s
From: Icenowy Zheng @ 2017-01-03 15:25 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner V3s SoC come with a USB OTG controller, which is a bind of a Mentor
Graphics MUSB Dual-role controller and a private USB PHY.
Both the MUSB and the USB PHY slightly changed. (The MUSB is similar to the
one in the popular SBC SoC H3).
Add support for them.
The device tree patches depends on my preivous patchset, but the phy and musb
patches are independent (the device tree patches depend on them).
The MUSB patch may be picked for use on H3.
The clock of the USB part seems to need some hack in the U-Boot, they are at
my WIP u-boot repo:
https://github.com/Icenowy/u-boot-1/tree/v3s .
Icenowy Zheng (4):
phy: sun4i-usb: add support for V3s USB PHY
musb: sunxi: add support for the variant in H3/V3s SoC
ARM: dts: sunxi: add usb_otg and usbphy node for V3s SoC
ARM: dts: sun8i: add OTG function to Lichee Pi Zero
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
.../bindings/usb/allwinner,sun4i-a10-musb.txt | 4 +--
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 +++++++
arch/arm/boot/dts/sun8i-v3s.dtsi | 27 +++++++++++++++++
drivers/phy/phy-sun4i-usb.c | 14 ++++++++-
drivers/usb/musb/sunxi.c | 35 ++++++++++++++++++++--
6 files changed, 86 insertions(+), 5 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH v3] ARM64: dts: marvell: Correct license text
From: Gregory CLEMENT @ 2017-01-03 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227213650.16329-1-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On mar., d?c. 27 2016, Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote:
> The license text has been mangled at some point then copy pasted across
> multiple files. Restore it to what it should be.
> Note that this is not intended as a license change.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> Changes in v3:
> - Rebased on v4.10-rc1 to fix espressobin
>
> arch/arm64/boot/dts/marvell/armada-371x.dtsi | 10 +++++-----
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 10 +++++-----
> arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts | 10 +++++-----
> arch/arm64/boot/dts/marvell/armada-372x.dtsi | 10 +++++-----
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 10 +++++-----
> 5 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
> index c9e5325b8ac3..11226f7b9ed9 100644
> --- a/arch/arm64/boot/dts/marvell/armada-371x.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
> @@ -16,17 +16,17 @@
> * published by the Free Software Foundation; either version 2 of the
> * License, or (at your option) any later version.
> *
> - * This file is distributed in the hope that it will be useful
> + * This file is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> - * Or, alternatively
> + * Or, alternatively,
> *
> * b) Permission is hereby granted, free of charge, to any person
> * obtaining a copy of this software and associated documentation
> * files (the "Software"), to deal in the Software without
> - * restriction, including without limitation the rights to use
> + * restriction, including without limitation the rights to use,
> * copy, modify, merge, publish, distribute, sublicense, and/or
> * sell copies of the Software, and to permit persons to whom the
> * Software is furnished to do so, subject to the following
> @@ -35,11 +35,11 @@
> * The above copyright notice and this permission notice shall be
> * included in all copies or substantial portions of the Software.
> *
> - * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> * OTHER DEALINGS IN THE SOFTWARE.
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> index 89de0a751093..f5f4c94f7070 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> @@ -15,17 +15,17 @@
> * published by the Free Software Foundation; either version 2 of the
> * License, or (at your option) any later version.
> *
> - * This file is distributed in the hope that it will be useful
> + * This file is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> - * Or, alternatively
> + * Or, alternatively,
> *
> * b) Permission is hereby granted, free of charge, to any person
> * obtaining a copy of this software and associated documentation
> * files (the "Software"), to deal in the Software without
> - * restriction, including without limitation the rights to use
> + * restriction, including without limitation the rights to use,
> * copy, modify, merge, publish, distribute, sublicense, and/or
> * sell copies of the Software, and to permit persons to whom the
> * Software is furnished to do so, subject to the following
> @@ -34,11 +34,11 @@
> * The above copyright notice and this permission notice shall be
> * included in all copies or substantial portions of the Software.
> *
> - * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> * OTHER DEALINGS IN THE SOFTWARE.
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
> index 83178d909fc2..d26139ad8331 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts
> @@ -14,17 +14,17 @@
> * published by the Free Software Foundation; either version 2 of the
> * License, or (at your option) any later version.
> *
> - * This file is distributed in the hope that it will be useful
> + * This file is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> - * Or, alternatively
> + * Or, alternatively,
> *
> * b) Permission is hereby granted, free of charge, to any person
> * obtaining a copy of this software and associated documentation
> * files (the "Software"), to deal in the Software without
> - * restriction, including without limitation the rights to use
> + * restriction, including without limitation the rights to use,
> * copy, modify, merge, publish, distribute, sublicense, and/or
> * sell copies of the Software, and to permit persons to whom the
> * Software is furnished to do so, subject to the following
> @@ -33,11 +33,11 @@
> * The above copyright notice and this permission notice shall be
> * included in all copies or substantial portions of the Software.
> *
> - * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> * OTHER DEALINGS IN THE SOFTWARE.
> diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> index 5120296596c2..59d7557d3b1b 100644
> --- a/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> @@ -16,17 +16,17 @@
> * published by the Free Software Foundation; either version 2 of the
> * License, or (at your option) any later version.
> *
> - * This file is distributed in the hope that it will be useful
> + * This file is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> - * Or, alternatively
> + * Or, alternatively,
> *
> * b) Permission is hereby granted, free of charge, to any person
> * obtaining a copy of this software and associated documentation
> * files (the "Software"), to deal in the Software without
> - * restriction, including without limitation the rights to use
> + * restriction, including without limitation the rights to use,
> * copy, modify, merge, publish, distribute, sublicense, and/or
> * sell copies of the Software, and to permit persons to whom the
> * Software is furnished to do so, subject to the following
> @@ -35,11 +35,11 @@
> * The above copyright notice and this permission notice shall be
> * included in all copies or substantial portions of the Software.
> *
> - * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> * OTHER DEALINGS IN THE SOFTWARE.
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index bab5c6ff5745..a02e9bcd190e 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -15,17 +15,17 @@
> * published by the Free Software Foundation; either version 2 of the
> * License, or (at your option) any later version.
> *
> - * This file is distributed in the hope that it will be useful
> + * This file is distributed in the hope that it will be useful,
> * but WITHOUT ANY WARRANTY; without even the implied warranty of
> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> * GNU General Public License for more details.
> *
> - * Or, alternatively
> + * Or, alternatively,
> *
> * b) Permission is hereby granted, free of charge, to any person
> * obtaining a copy of this software and associated documentation
> * files (the "Software"), to deal in the Software without
> - * restriction, including without limitation the rights to use
> + * restriction, including without limitation the rights to use,
> * copy, modify, merge, publish, distribute, sublicense, and/or
> * sell copies of the Software, and to permit persons to whom the
> * Software is furnished to do so, subject to the following
> @@ -34,11 +34,11 @@
> * The above copyright notice and this permission notice shall be
> * included in all copies or substantial portions of the Software.
> *
> - * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> - * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> * OTHER DEALINGS IN THE SOFTWARE.
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
From: Greg Kroah-Hartman @ 2017-01-03 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1456945629-1793533-2-git-send-email-arnd@arndb.de>
On Wed, Mar 02, 2016 at 08:06:46PM +0100, Arnd Bergmann wrote:
> The icn, act2000 and pcbit drivers are all for very old hardware,
> and it is highly unlikely that anyone is actually still using them
> on modern kernels, if at all.
>
> All three drivers apparently are for hardware that predates PCI
> being the common connector, as they are ISA-only and active
> PCI ISDN cards were widely available in the 1990s.
>
> Looking through the git logs, it I cannot find any indication of a
> patch to any of these drivers that has been tested on real hardware,
> only cleanups or global API changes.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Karsten Keil <isdn@linux-pingi.de>
This patch got added in the 4.6 kernel release. As I am now taking
patches for 4.11-rc1, I figure it is time to just delete the
drivers/staging/i4l/ directory now, given that no one has really done
anything with it. If people show up that wish to maintain it, I'll be
glad to revert it, or if someone really screams in the next week.
Otherwise it's time to just move on :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH v1 2/3] dt-bindings: add binding for rk3328 power domains
From: Rob Herring @ 2017-01-03 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482464872-12954-3-git-send-email-zhangqing@rock-chips.com>
On Fri, Dec 23, 2016 at 11:47:51AM +0800, Elaine Zhang wrote:
> Add binding documentation for the power domains
> found on Rockchip RK3328 SoCs.
> But RK3328 SoC just support idle, not support pd.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/3] dt: pwm: lpc32xx: add description of clocks and #pwm-cells properties
From: Sylvain Lemieux @ 2017-01-03 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5a865e27-e673-2f45-6c71-ca1e7d92a346@mleia.com>
Hi Rob,
On Wed, 2016-12-21 at 05:30 +0200, Vladimir Zapolskiy wrote:
> On 12/10/2016 01:51 AM, Vladimir Zapolskiy wrote:
> > Hi Rob,
> >
> > On 12/09/2016 11:41 PM, Rob Herring wrote:
> >> On Mon, Dec 05, 2016 at 03:42:37AM +0200, Vladimir Zapolskiy wrote:
> >>> NXP LPC32xx SoCs have two simple independent PWM controllers with a single
> >>> output each, in this case there is no need to specify PWM channel argument
> >>> on client side, one cell for setting PWM output frequency is sufficient.
> >>>
> >>> Another added to the description property 'clocks' has a standard meaning
> >>> of a controller supply clock, in the LPC32xx User's Manual the clock is
> >>> denoted as PWM1_CLK or PWM2_CLK clock.
> >>>
> >>> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> >>> ---
> >>> Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt | 7 +++++++
> >>> 1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt b/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt
> >>> index 74b5bc5..523d796 100644
> >>> --- a/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt
> >>> +++ b/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt
> >>> @@ -3,15 +3,22 @@ LPC32XX PWM controller
> >>> Required properties:
> >>> - compatible: should be "nxp,lpc3220-pwm"
> >>> - reg: physical base address and length of the controller's registers
> >>> +- clocks: clock phandle and clock specifier pair
> >>> +- #pwm-cells: should be 1, the cell is used to specify the period in
> >>> + nanoseconds.
> >>
> >> This use of the cell is a bit odd as the period is s/w config and this
> >> would typically be a channel selection or such.
> >
> > this is a classic PWM channel configuration property for PWM consumers
> > described in DT, for instance PWM frequency for display panel backlight
> > on boot.
> >
> > I think >90% of PWM controllers with device tree bindings have this
> > argument in #pwm-cells, from bindings/pwm/pwm.txt :
> >
> > pwm-specifier typically encodes the chip-relative PWM number and
> > the PWM period in nanoseconds.
> >
> > You also may skim through phandle arguments of 'pwms' property,
> > commonly the second argument is the requested frequency.
> >
> > In this particular case I just drop PWM channel number, because
> > the LPC32xx PWM controller has a single output channel.
> >
> >> What if I want user specified/changed periods?
> >>
> >
> > The preset period still can be changed over sysfs in runtime.
>
> Rob, have I managed to answer your questions?
>
> If you accept my clarification, could you please ack the change?
>
> --
> With best wishes,
> Vladimir
>
ping
Sylvain
^ 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