* [PATCH v5 1/7] MFD: add bindings for STM32 General Purpose Timer driver
From: Lee Jones @ 2016-12-09 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481199650-22484-2-git-send-email-benjamin.gaignard@st.com>
Sorry to do this Ben. Not much to do now though!
> Add bindings information for STM32 General Purpose Timer
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../bindings/mfd/stm32-general-purpose-timer.txt | 39 ++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> new file mode 100644
> index 0000000..ce67755
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
> @@ -0,0 +1,39 @@
> +STM32 General Purpose Timer driver bindings
This is a great place to describe what we're *actually* trying to
achieve with this driver, and the worst place to use the term "general
purpose", since this IP is so much more than that.
"STM32 Timers
This IP provides 3 types of timer along with PWM functionality.
[...]"
... then go on to explain what the 3 types are and how they can be
used.
> +Required parameters:
> +- compatible: must be "st,stm32-gptimer"
I vehemently disagree that this entire IP is a GP Timer. It contains
GP timers, sure, but it also contains Advanced and Basic timers.
IMHO this compatible should be "st,stm32-timers".
And the file name of both this and the *.c file should reflect that
too.
Remainder looks nice.
> +- reg: Physical base address and length of the controller's
> + registers.
> +- clock-names: Set to "clk_int".
> +- clocks: Phandle to the clock used by the timer module.
> + For Clk properties, please refer to ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets: Phandle to the parent reset controller.
> + See ../reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm: See ../pwm/pwm-stm32.txt
> +- timer: See ../iio/timer/stm32-timer-trigger.txt
> +
> +Example:
> + timers at 40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm at 0 {
Out of interest, do you use the "@0", "@1" for anything now?
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + };
> +
> + timer at 0 {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
> + };
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
From: Maxime Ripard @ 2016-12-09 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87oa0nbldb.fsf@eliezer.anholt.net>
Hi Eric,
On Wed, Dec 07, 2016 at 11:16:32AM -0800, Eric Anholt wrote:
> Maxime Ripard <maxime.ripard@free-electrons.com> writes:
>
> > [ Unknown signature status ]
> > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> >> The panels shipped with Allwinner devices are very "generic", i.e.
> >> they do not have model numbers or reliable sources of information
> >> for the timings (that we know of) other than the fex files shipped
> >> on them. The dot clock frequency provided in the fex files have all
> >> been rounded to the nearest MHz, as that is the unit used in them.
> >>
> >> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> >> for the A13 Q8 tablets in the absence of a specific model for what
> >> may be many different but otherwise timing compatible panels. This
> >> was usable without any visual artifacts or side effects, until the
> >> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> >> rgb: Validate the clock rate").
> >>
> >> The reason this check fails is because the dotclock frequency for
> >> this model is 33.26 MHz, which is not achievable with our dot clock
> >> hardware, and the rate returned by clk_round_rate deviates slightly,
> >> causing the driver to reject the display mode.
> >>
> >> The LCD panels have some tolerance on the dot clock frequency, even
> >> if it's not specified in their datasheets.
> >>
> >> This patch adds a 5% tolerence to the dot clock check.
> >
> > As we discussed already, I really believe this is just as arbitrary as
> > the current behaviour.
> >
> > Some panels require an exact frequency, some have a minimal frequency
> > but no maximum, some have a maximum frequency but no minimal, and I
> > guess most of them deviates by how much exactly they can take (and
> > possibly can take more easily a higher frequency, but are less
> > tolerant if you take a frequency lower than the nominal.
> >
> > And we cannot remove that check entirely, since some bridges will
> > report out of range frequencies for higher modes that we know we
> > cannot reach.
> >
> > We could just try to see if the screen pixel clock frequency is out of
> > the pixel clock range we can generate, but then we will loop back on
> > how much out of range is it exactly, and is it within the screen
> > tolerancy.
> >
> > We have an API to deal with the panel tolerancies in the DRM panel
> > framework, we can (and should) use it.
> >
> > I'm not sure how others usually deal with this though. I think I
> > remember Eric telling me that for the RPi they just adjusted the
> > timings a bit, but they only really had a single panel to deal with.
>
> For RPi, you just adjust the pixel clock of the panel's mode to be
> whatever the platform can support, and expand the blanking intervals to
> get the refresh rate back to desired. This is nothing like what the
> datasheet says, but it's not important what the datasheet says, it's
> important what makes the product work.
Ok, that was what I was recalling from our previous discussion on that
topic.
> Our clock driver looks for the best matching clock that's not over the
> target rate. This is somewhat unfortunate, as you end up slightly
> inflating your requested clocks so that a possible clock lands under
> that. I'd rather we chose the closest matching clock, but then people
> get worried about what if selected clock rate is 1% higher than expected
> (the answer is "nothing").
Whose feedback was that? Users?
> I think this patch is a fine solution, and the alternative would be to
> just drop the mode high/low check and say that if you're pairing a panel
> with some display hardware, it's up to you to make sure that the panel's
> mode actually scans out successfully. Then, since compatible strings
> are cheap, you can use a new one if necessary to attach better modes to
> the panel for a particular clock driver by adjusting your timings to get
> closer to the refresh rates you want.
That's one expectation we can have for panels, but we had that test
for bridges. On some SoCs, the pixel clock is pretty limited and can
only reach around 720p60 or 1080p30. If you have a monitor attached
that will return EDIDs, chances are that it will report modes that you
know have no chance to work.
This check was here to rule out those cases and prevent them from
showing up in the list of modes.
So we basically have two different things to care about. We want to be
tolerant so that most panels just work, but not too tolerant to rule
out modes that we know we can't reach. We're only covering the latter,
and we should take into account the former, but we definitely need
some kind of check.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161209/4b5f65f7/attachment.sig>
^ permalink raw reply
* [PATCH v18 03/15] clocksource/drivers/arm_arch_timer: Improve printk relevant code
From: Fu Wei @ 2016-12-09 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481231430.5946.34.camel@perches.com>
Hi Joe,
On 9 December 2016 at 05:10, Joe Perches <joe@perches.com> wrote:
> On Fri, 2016-12-09 at 01:33 +0800, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei@linaro.org>
>>
>> This patch defines pr_fmt(fmt) for all pr_* functions,
>> then the pr_* doesn't need to add "arch_timer:" everytime.
>
> trivia:
>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> []
>> @@ -966,7 +967,7 @@ static int __init arch_timer_mem_init(struct device_node *np)
>>
>> ret = -EINVAL;
>> if (!irq) {
>> - pr_err("arch_timer: Frame missing %s irq",
>> + pr_err("Frame missing %s irq",
>> arch_timer_mem_use_virtual ? "virt" : "phys");
>> goto out;
>> }
>
> Missing terminating newline
>
> pr_err("Frame missing %s irq\n",
yes, you are right , will fix it. :-)
Thanks
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-12-09 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202150513.34691-2-icenowy@aosc.xyz>
On Fri, Dec 02, 2016 at 11:05:13PM +0800, Icenowy Zheng wrote:
> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a
> SDIO Wi-Fi chip by Allwinner (XR819).
>
> Add a device tree file for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161209/2380b316/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/2] arm: dts: sun8i: reuse the uart1 node of iNet D978 rev2 board
From: Maxime Ripard @ 2016-12-09 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205184745.lfW8ji5w@smtp1m.mail.yandex.net>
On Mon, Dec 05, 2016 at 05:03:35PM +0800, Icenowy Zheng wrote:
>
> 2016?12?5? 16:50? Maxime Ripard <maxime.ripard@free-electrons.com>???
> >
> > On Fri, Dec 02, 2016 at 11:19:13PM +0800, Icenowy Zheng wrote:
> > > As a uart1 node is added into sun8i-reference-design-tablet.dtsi, simply
> > > use it in iNet D978 rev2 device tree.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >
> > I'd like to see more consolidation before that change is needed. If we
> > find more boards using that, it will make sense, but for a single
> > board it's not worth it.
>
> At least 2~3 Q8 A33 tablets in #linux-sunxi are found to have
> rtl8703as, which contains UART bluetooth. (including mine)
Still, I'm not fond of creating a default on such a low count sample
of (out-of-tree) DTs. Support and enable the bluetooth on more boards,
and then consolidate.
> In fact, what I want to do is to get the node ready-to-be-okay in Q8
> dts, so it can be enabled by either u-boot command or (theortically)
> Hans de Goede's q8-hardwaremgr, just like what is done at
> touchscreen node.
If your plan is to enable all the combinations possible accross the Q8
tablets and let the bootloader/user figure it all out, then it's not
going to happen, sorry.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161209/1271c094/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Maxime Ripard @ 2016-12-09 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206080838.7523-1-icenowy@aosc.xyz>
On Tue, Dec 06, 2016 at 04:08:38PM +0800, Icenowy Zheng wrote:
> Some SDIO Wi-Fi chips (such as RTL8703AS) have a UART bluetooth, which
> has a dedicated enable pin (PL8 in the reference design).
>
> Enable the pin in the same way as the WLAN enable pins.
>
> Tested on an A33 Q8 tablet with RTL8703AS.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>
> This patch should be coupled with the uart1 node patch I send before:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/471997.html
>
> For RTL8703AS, the rtl8723bs bluetooth code is used, which can be retrieve from:
> https://github.com/lwfinger/rtl8723bs_bt
>
> arch/arm/boot/dts/sun8i-q8-common.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi
> index c676940..4aeb5bb 100644
> --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
> +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
> @@ -88,7 +88,7 @@
>
> &r_pio {
> wifi_pwrseq_pin_q8: wifi_pwrseq_pin at 0 {
> - pins = "PL6", "PL7", "PL11";
> + pins = "PL6", "PL7", "PL8", "PL11";
> function = "gpio_in";
> bias-pull-up;
> };
There's several things wrong here. The first one is that you rely
solely on the pinctrl state to maintain a reset line. This is very
fragile (especially since the GPIO pinctrl state are likely to go away
at some point), but it also means that if your driver wants to recover
from that situation at some point, it won't work.
The other one is that the bluetooth and wifi chips are two devices in
linux, and you assign that pin to the wrong device (wifi).
rfkill-gpio is made just for that, so please use it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161209/8ee44e83/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] clk: keystone: Add sci-clk driver support
From: Tero Kristo @ 2016-12-09 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208211044.GI5423@codeaurora.org>
On 08/12/16 23:10, Stephen Boyd wrote:
> On 12/08, Tero Kristo wrote:
>> On 08/12/16 02:13, Stephen Boyd wrote:
>>> On 10/21, Tero Kristo wrote:
>>>> diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c
>>>> new file mode 100644
>>>> index 0000000..f6af5bd
>>>> --- /dev/null
>>>> +++ b/drivers/clk/keystone/sci-clk.c
>>
>>>
>>>> +
>>>> + handle = devm_ti_sci_get_handle(dev);
>>>> + if (IS_ERR(handle))
>>>> + return PTR_ERR(handle);
>>>> +
>>>> + provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL);
>>>> + if (!provider)
>>>> + return -ENOMEM;
>>>> +
>>>> + provider->clocks = data;
>>>> +
>>>> + provider->sci = handle;
>>>> + provider->ops = &handle->ops.clk_ops;
>>>> + provider->dev = dev;
>>>> +
>>>> + ti_sci_init_clocks(provider);
>>>
>>> And if this fails?
>>
>> Yea this is kind of controversial. ti_sci_init_clocks() can fail if
>> any of the clocks registered will fail. I decided to have it this
>> way so that at least some clocks might work in failure cause, and
>> you might have a booting device instead of total lock-up.
>>
>> Obviously it could be done so that if any clock fails, we would
>> de-register all clocks at that point, but personally I think this is
>> a worse option.
>>
>> ti_sci_init_clocks could probably be modified to continue
>> registering clocks when a single clock fails though. Currently it
>> aborts at first failure.
>>
>
> That sounds like a better approach if we don't care about
> failures to register a clock. Returning a value from a function
> and not using it isn't really a great design.
>
> I worry that if we start returning errors from clk_hw_register()
> that something will go wrong though, so really I don't know why
> we want to ignore errors at all. Just for debugging a boot hang?
> Can't we use early console to at least see that this driver is
> failing to probe and debug that way?
Early console can be used to debug that, but it is kind of annoying to
recompile most of the kernel when you suddenly need to use it.
How about modifying the ti_sci_init_clocks func to print an error for
each failed clock?
If you insist on aborting the probe though if a single clock fails, I
can do that also.
-Tero
^ permalink raw reply
* [RESEND PATCH v2 0/7] drm/vc4: VEC (SDTV) output support
From: Boris Brezillon @ 2016-12-09 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <68783643.33021.1481268157922@email.1und1.de>
On Fri, 9 Dec 2016 08:22:37 +0100 (CET)
Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi,
>
> > Boris Brezillon <boris.brezillon@free-electrons.com> hat am 2. Dezember 2016 um 14:48 geschrieben:
> >
> >
> > Sorry for the noise, but I forgot to Cc the DT maintainers.
> >
> > Here is the 2nd version of the VC4/VEC series.
> >
> > We still miss the two clock patches mentioned by Eric in the first
> > version to make the encoder work no matter the setting applied by the
> > bootloader.
>
> are there any advices to test this feature?
Apply these patches [1][2][3][4] in addition to this series, and you
should see the SDTV output when running modetest (this is what I used
to test/debug the driver).
This is the command I use to test the SDTV output in NTSC mode
modetest -s 39:720x480
>
> Is it possible to use an old Raspberry Pi B (256 MB RAM) for this?
I did most of my test on a RPi-2, but IIRC, Eric tested it on a RPi
(don't know which model).
>
> Thanks
>
> Stefan
[1]https://patchwork.kernel.org/patch/9442127/
[2]https://patchwork.kernel.org/patch/9456911/
[3]https://patchwork.kernel.org/patch/9456909/
[4]https://patchwork.kernel.org/patch/9456731/
^ permalink raw reply
* [RESEND PATCH v2 0/7] drm/vc4: VEC (SDTV) output support
From: Stefan Wahren @ 2016-12-09 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480686493-4813-1-git-send-email-boris.brezillon@free-electrons.com>
Hi,
> Boris Brezillon <boris.brezillon@free-electrons.com> hat am 2. Dezember 2016 um 14:48 geschrieben:
>
>
> Sorry for the noise, but I forgot to Cc the DT maintainers.
>
> Here is the 2nd version of the VC4/VEC series.
>
> We still miss the two clock patches mentioned by Eric in the first
> version to make the encoder work no matter the setting applied by the
> bootloader.
are there any advices to test this feature?
Is it possible to use an old Raspberry Pi B (256 MB RAM) for this?
Thanks
Stefan
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Vinod Koul @ 2016-12-09 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xy3zqxt7x.fsf@unicorn.mansr.com>
On Thu, Dec 08, 2016 at 04:48:18PM +0000, M?ns Rullg?rd wrote:
> Vinod Koul <vinod.koul@intel.com> writes:
>
> > To make it efficient, disregarding your Sbox HW issue, the solution is
> > virtual channels. You can delink physical channels and virtual channels. If
> > one has SW controlled MUX then a channel can service any client. For few
> > controllers request lines are hard wired so they cant use any channel. But
> > if you dont have this restriction then driver can queue up many transactions
> > from different controllers.
>
> Have you been paying attention at all? This exactly what the driver
> ALREADY DOES.
And have you read what the question was?
--
~Vinod
^ permalink raw reply
* [PATCH] arm64: ls1012a: dts: add eSDHC nodes
From: Yangbo Lu @ 2016-12-09 6:29 UTC (permalink / raw)
To: linux-arm-kernel
There are two eSDHC controllers in LS1012A. This patch is to add
eSDHC nodes for ls1012a dts. Also enable eSDHC for RDB/QDS boards.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
- Added 'broken-cd' in esdhc2 node
- Enabled esdhc in board dts
---
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 25 +++++++++++++++++++++++
3 files changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
index b841251..cc35114 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
@@ -126,3 +126,11 @@
&sai2 {
status = "okay";
};
+
+&esdhc0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
index 62c5c71..0eef319 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
@@ -57,3 +57,11 @@
&i2c0 {
status = "okay";
};
+
+&esdhc0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index 24874d7..18310ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -128,6 +128,31 @@
clocks = <&sysclk>;
};
+ esdhc0: esdhc at 1560000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1560000 0x0 0x10000>;
+ interrupts = <0 62 0x4>;
+ clock-frequency = <0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ esdhc1: esdhc at 1580000 {
+ compatible = "fsl,ls1012a-esdhc", "fsl,esdhc";
+ reg = <0x0 0x1580000 0x0 0x10000>;
+ interrupts = <0 65 0x4>;
+ clock-frequency = <0>;
+ voltage-ranges = <1800 1800 3300 3300>;
+ sdhci,auto-cmd12;
+ big-endian;
+ broken-cd;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
i2c0: i2c at 2180000 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
--
2.1.0.27.g96db324
^ permalink raw reply related
* [PATCH 4/4] dt-bindings: input: Specify the interrupt number of TPS65217 power button
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Specify the power button interrupt number which is from the datasheet.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
index 3e5b979..8682ab6 100644
--- a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
+++ b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
@@ -8,8 +8,9 @@ This driver provides a simple power button event via an Interrupt.
Required properties:
- compatible: should be "ti,tps65217-pwrbutton" or "ti,tps65218-pwrbutton"
-Required properties for TPS65218:
+Required properties:
- interrupts: should be one of the following
+ - <2>: For controllers compatible with tps65217
- <3 IRQ_TYPE_EDGE_BOTH>: For controllers compatible with tps65218
Examples:
@@ -17,6 +18,7 @@ Examples:
&tps {
tps65217-pwrbutton {
compatible = "ti,tps65217-pwrbutton";
+ interrupts = <2>;
};
};
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] dt-bindings: power/supply: Update TPS65217 properties
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Add interrupt specifiers for USB and AC charger input. Interrupt numbers
are from the datasheet.
Fix wrong property for compatible string.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
.../devicetree/bindings/power/supply/tps65217_charger.txt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
index 98d131a..a11072c 100644
--- a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
+++ b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
@@ -2,11 +2,16 @@ TPS65217 Charger
Required Properties:
-compatible: "ti,tps65217-charger"
+-interrupts: TPS65217 interrupt numbers for the AC and USB charger input change.
+ Should be <0> for the USB charger and <1> for the AC adapter.
+-interrupt-names: Should be "USB" and "AC"
This node is a subnode of the tps65217 PMIC.
Example:
tps65217-charger {
- compatible = "ti,tps65090-charger";
+ compatible = "ti,tps65217-charger";
+ interrupts = <0>, <1>;
+ interrupt-names = "USB", "AC";
};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: mfd: Remove TPS65217 interrupts
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Interrupt numbers are from the datasheet, so no need to keep them in
the ABI. Use the number in the DT file.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +++-----
include/dt-bindings/mfd/tps65217.h | 26 --------------------------
2 files changed, 3 insertions(+), 31 deletions(-)
delete mode 100644 include/dt-bindings/mfd/tps65217.h
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 14b6269..3e32dd1 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -6,8 +6,6 @@
* published by the Free Software Foundation.
*/
-#include <dt-bindings/mfd/tps65217.h>
-
/ {
cpus {
cpu at 0 {
@@ -319,13 +317,13 @@
ti,pmic-shutdown-controller;
charger {
- interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
- interrupt-names = "AC", "USB";
+ interrupts = <0>, <1>;
+ interrupt-names = "USB", "AC";
status = "okay";
};
pwrbutton {
- interrupts = <TPS65217_IRQ_PB>;
+ interrupts = <2>;
status = "okay";
};
diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
deleted file mode 100644
index cafb9e6..0000000
--- a/include/dt-bindings/mfd/tps65217.h
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * This header provides macros for TI TPS65217 DT bindings.
- *
- * Copyright (C) 2016 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#ifndef __DT_BINDINGS_TPS65217_H__
-#define __DT_BINDINGS_TPS65217_H__
-
-#define TPS65217_IRQ_USB 0
-#define TPS65217_IRQ_AC 1
-#define TPS65217_IRQ_PB 2
-
-#endif
--
2.9.3
^ permalink raw reply related
* [PATCH 1/4] ARM: dts: am335x: Fix the interrupt name of TPS65217
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-1-woogyom.kim@gmail.com>
Use 'interrupt-names' for getting the charger interrupt number.
Fixes: 1934e89a769b ("ARM: dts: am335x: Add the charger interrupt")
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index dc561d5..14b6269 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -320,7 +320,7 @@
charger {
interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
- interrupts-names = "AC", "USB";
+ interrupt-names = "AC", "USB";
status = "okay";
};
--
2.9.3
^ permalink raw reply related
* [PATCH 0/4] dt-bindings: mfd: Update TPS65217 interrupts
From: Milo Kim @ 2016-12-09 6:28 UTC (permalink / raw)
To: linux-arm-kernel
This patch-set fixes wrong property name and uses TPS65217 HW interrupt
number from the datasheet instead of the DT ABI. DT bindings are also
updated.
Milo Kim (4):
ARM: dts: am335x: Fix the interrupt name of TPS65217
dt-bindings: mfd: Remove TPS65217 interrupts
dt-bindings: power/supply: Update TPS65217 properties
dt-bindings: input: Add interrupt number for TPS65217
.../bindings/input/tps65218-pwrbutton.txt | 4 +++-
.../bindings/power/supply/tps65217_charger.txt | 7 +++++-
arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +++----
include/dt-bindings/mfd/tps65217.h | 26 ----------------------
4 files changed, 12 insertions(+), 33 deletions(-)
delete mode 100644 include/dt-bindings/mfd/tps65217.h
--
2.9.3
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Harini Katakam @ 2016-12-09 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07C910AB6AC6C345A093D5A08F5AF568CB74AF28@CHN-SV-EXMX03.mchp-main.com>
Hi,
On Thu, Dec 8, 2016 at 8:11 PM, <Andrei.Pistirica@microchip.com> wrote:
>
>
>> -----Original Message-----
>> From: Richard Cochran [mailto:richardcochran at gmail.com]
>> Sent: Wednesday, December 07, 2016 11:04 PM
>> To: Andrei Pistirica - M16132
>> Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
>> kernel at lists.infradead.org; davem at davemloft.net;
>> nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com;
>> harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com;
>> anirudh at xilinx.com; boris.brezillon at free-electrons.com;
>> alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com;
>> rafalo at cadence.com
>> Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
>> Cadence GEM.
>>
>> On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
>> > > +static s32 gem_ptp_max_adj(unsigned int f_nom) {
>> > > + u64 adj;
>> > > +
>> > > + /* The 48 bits of seconds for the GEM overflows every:
>> > > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
>> > > + * thus the maximum adjust frequency must not overflow CNS
>> register:
>> > > + *
>> > > + * addend = 10^9/nominal_freq
>> > > + * adj_max = +/- addend*ppb_max/10^9
>> > > + * max_ppb = (2^8-1)*nominal_freq-10^9
>> > > + */
>> > > + adj = f_nom;
>> > > + adj *= 0xffff;
>> > > + adj -= 1000000000ULL;
>> >
>> > What is this computation, and how does it relate to the comment?
>
> I considered the following simple equation: increment value at nominal frequency (which is 10^9/nominal frequency nsecs) + the maximum drift value (nsecs) <= maximum increment value@nominal frequency (which is 8bit:0xffff).
> If maximum drift is written as function of nominal frequency and maximum ppb, then the equation above yields that the maximum ppb is: (2^8 - 1) *nominal_frequency - 10^9. The equation is also simplified by the fact that the drift is written as ppm + 16bit_fractions and the increment value is written as nsec + 16bit_fractions.
>
> Rafal said that this value is hardcoded: 0x64E6, while Harini said: 250000000.
@ Andrei, I may have equated max ppb to max tsu frequency allowed on
the system and set that.
That will be wrong.
>
> I need to dig into this...
>
>>
>> I am not sure what you meant, but it sounds like you are on the wrong track.
>> Let me explain...
>
> Thanks.
>
>>
>> The max_adj has nothing at all to do with the width of the time register.
>> Rather, it should reflect the maximum possible change in the tuning word.
>>
>> For example, with a nominal 8 ns period, the tuning word is 0x80000.
>> Looking at running the clock more slowly, the slowest possible word is
>> 0x00001, meaning a difference of 0x7FFFF. This implies an adjustment of
>> 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can already
>> have 0x100000, twice as fast, or just under 2 billion ppb.
>>
>> You should consider the extreme cases to determine the most limited
>> (smallest) max_adj value:
>>
>> Case 1 - high frequency
>> ~~~~~~~~~~~~~~~~~~~~~~~
>>
>> With a nominal 1 ns period, we have the nominal tuning word 0x10000.
>> The smallest is 0x1 for a difference of 0xFFFF. This corresponds to an
>> adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
>>
>> Case 2 - low frequency
>> ~~~~~~~~~~~~~~~~~~~~~~
>>
>> With a nominal 255 ns period, the nominal word is 0xFF0000, the largest
>> 0xFFFFFF, and the difference is 0xFFFF. This corresponds to and adjustment
>> of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
>>
>> Since 3921508 ppb is a huge adjustment, you can simply use that as a safe
>> maximum, ignoring the actual input clock.
>>
Thanks Richard.
So, if I understand right, this is theoretically limited by the
maximum input clock:
So if the highest frequency allowed (also commonly sourced in my case)
is 200MHz,
then with a 5ns time period, considering the adjustment to slowest
possible word,
0x4FFFF/0x50000 will be 999996948 ppb.
Shouldn't this be the max_adj?
I'm afraid I don't get why we are choosing the most limited max adj..
Sorry if I'm missing something - could you please help me understand?
Regards,
Harini
^ permalink raw reply
* [PATCH 3/3] iio: adc: add a driver for Qualcomm PM8xxx HK/XOADC
From: Bjorn Andersson @ 2016-12-09 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481032279-27115-1-git-send-email-linus.walleij@linaro.org>
On Tue 06 Dec 05:51 PST 2016, Linus Walleij wrote:
> +static struct pm8xxx_chan_info *
> +pm8xxx_get_channel(struct pm8xxx_xoadc *adc, u8 chan)
> +{
> + struct pm8xxx_chan_info *ch;
> + int i;
> +
> + if (chan >= adc->nchans)
> + return NULL;
nchans is the number of children and chan is the channel id, so this
doesn't seem right (I think you should just drop this check).
> +
> + for (i = 0; i < adc->nchans; i++) {
> + ch = &adc->chans[i];
> + if (ch->amux_channel == chan)
> + break;
> + }
> + if (i == adc->nchans)
> + return NULL;
> +
> + return ch;
> +}
> +
> +static int pm8xxx_read_channel_rsv(struct pm8xxx_xoadc *adc,
> + const struct pm8xxx_chan_info *ch,
> + u8 rsv, u16 *adc_code)
> +{
> + int ret;
> + unsigned int val;
> + u8 rsvmask, rsvval;
> + u8 lsb, msb;
> +
> + dev_dbg(adc->dev, "read channel \"%s\", amux %d, mpp %d, rsv %d\n",
> + ch->name, ch->amux_channel, ch->amux_mpp_channel, rsv);
> +
> + /* Mux in this channel */
> + ret = regmap_write(adc->map, ADC_ARB_USRP_AMUX_CNTRL,
> + ch->amux_channel << ADC_AMUX_SEL_SHIFT |
> + ch->amux_mpp_channel << ADC_AMUX_PREMUX_SHIFT);
Does this need synchronization to stop multiple clients to stomp on each
other here?
> + if (ret)
> + return ret;
> +
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 0/2] GXL and GXM SCPI improvements
From: Kevin Hilman @ 2016-12-09 4:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202230849.11422-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> This series adds SCPI support to GXL and GXM SoCs by moving the nodes
> to meson-gx.dtsi.
> Now that we have SCPI support for GXM we can also use it to configure
> the CPU cores using the SCPI DVFS clocks.
>
> Changes since v1:
> - added Tested-By and Acked-By tags from Neil Armstrong (thanks!)
> - rebased to khilman/linux-amlogic.git/amlogic-dt64-2-v2
> - updated description of patch 1 because the "arm,scpi-pre-1.0" change
> is already part of the amlogic-dt64-2-v2 tag
Thanks for the respin. It's now too late for v4.10 (I freeze things
around -rc6 or -rc7, and it's now -rc8), but I'll queue this up for
v4.11.
Thanks,
Kevin
^ permalink raw reply
* [PATCH 16/16] drivers/fsi: Add GPIO based FSI master
From: Jeremy Kerr @ 2016-12-09 4:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481069677-53660-17-git-send-email-christopher.lee.bostic@gmail.com>
Hi Chris,
> +static ssize_t store_scan(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct fsi_master_gpio *master = dev_get_drvdata(dev);
> +
> + fsi_master_gpio_init(master);
> +
> + /* clear out any old scan data if present */
> + fsi_master_unregister(&master->master);
> + fsi_master_register(&master->master);
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(scan, 0200, NULL, store_scan);
I think it would make more sense to have the scan attribute populated by
the fsi core; we want this on all masters, not just GPIO.
Currently, the only GPIO-master-specific functionality here is the
fsi_master_gpio_init() - but isn't this something that we can do at
probe time instead?
> +static int fsi_master_gpio_probe(struct platform_device *pdev)
> +{
> + struct fsi_master_gpio *master;
> + struct gpio_desc *gpio;
> +
> + master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
> + if (!master)
> + return -ENOMEM;
We should be populating master->dev.parent, see
https://github.com/jk-ozlabs/linux/commit/5225d6c47
> + /* Optional pins */
> +
> + gpio = devm_gpiod_get(&pdev->dev, "trans", 0);
> + if (IS_ERR(gpio))
> + dev_dbg(&pdev->dev, "probe: failed to get trans pin\n");
> + else
> + master->gpio_trans = gpio;
I found devm_gpiod_get_optional(), which might make this a little
neater.
Cheers,
Jeremy
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2016-12-09 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58481DD1.6090606@arm.com>
Hi Vladimir,
On 08/12/16 00:33, Vladimir Murzin wrote:
> Hi Linus,
>
> On 07/12/16 14:11, Linus Walleij wrote:
>> Another target I had in mind was the Integrator which
>> incidentally supports a bunch of the old noMMU core
>> tiles where we can swap in an ARM946, which I guess
>> could work with this?
>
> Do you mind trying my "Allow NOMMU for MULTIPLATFORM" series [1]? Greg just
> reported it did a trick for Versatile, there is a good chance it would work
> for Integrator too ;)
>
> [1] https://www.spinics.net/lists/arm-kernel/msg546823.html
I won't speak for Linus...
But I tried building with your patches for Integrator/CP and
that builds (with an appropriate configuration) with CONFIG_MMU
disabled and runs successfully in qemu (with machine target
"integratorcp"). No other patches required.
Regards
Greg
^ permalink raw reply
* boot hang issue on S5PV210 with the latest kernel
From: Yong Li @ 2016-12-09 2:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I am testing the latest kernel(4.8+) on my S5PV210 ARM boards. I found I
have to add the kputc debug in __armv7_mmu_cache_on in
boot/compressed/head.S:
mov r11, r3
kputc #'x'
mov r3, r11
Without the above kputc, the kernel boot hang, there is no any output on UART
Any suggestions?
Thanks,
Yong
^ permalink raw reply
* [PATCH] dt-bindings: Document the hi3660 reset bindings
From: Zhangfei Gao @ 2016-12-09 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480989092-31847-2-git-send-email-zhangfei.gao@linaro.org>
Add DT bindings documentation for hi3660 SoC reset controller.
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
---
.../bindings/reset/hisilicon,hi3660-reset.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
new file mode 100644
index 0000000..2bf3344
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
@@ -0,0 +1,43 @@
+Hisilicon System Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller registers are part of the system-ctl block on
+hi3660 SoC.
+
+Required properties:
+- compatible: should be
+ "hisilicon,hi3660-reset"
+- hisi,rst-syscon: phandle of the reset's syscon.
+- #reset-cells : Specifies the number of cells needed to encode a
+ reset source. The type shall be a <u32> and the value shall be 2.
+
+ Cell #1 : offset of the reset assert control
+ register from the syscon register base
+ offset + 4: deassert control register
+ offset + 8: status control register
+ Cell #2 : bit position of the reset in the reset control register
+
+Example:
+ iomcu: iomcu at ffd7e000 {
+ compatible = "hisilicon,hi3660-iomcu", "syscon";
+ reg = <0x0 0xffd7e000 0x0 0x1000>;
+ };
+
+ iomcu_rst: iomcu_rst_controller {
+ compatible = "hisilicon,hi3660-reset";
+ hisi,rst-syscon = <&iomcu>;
+ #reset-cells = <2>;
+ };
+
+Specifying reset lines connected to IP modules
+==============================================
+example:
+
+ i2c0: i2c at ..... {
+ ...
+ resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
+ ...
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: Document the hi3660 reset bindings
From: zhangfei @ 2016-12-09 2:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481031753.3202.57.camel@pengutronix.de>
On 2016?12?06? 21:42, Philipp Zabel wrote:
> Am Dienstag, den 06.12.2016, 09:51 +0800 schrieb Zhangfei Gao:
>> Add DT bindings documentation for hi3660 SoC reset controller.
>>
>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>> ---
>> .../bindings/reset/hisilicon,hi3660-reset.txt | 36 ++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>> new file mode 100644
>> index 0000000..178e478
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>> @@ -0,0 +1,36 @@
>> +Hisilicon System Reset Controller
>> +======================================
>> +
>> +Please also refer to reset.txt in this directory for common reset
>> +controller binding usage.
>> +
>> +The reset controller registers are part of the system-ctl block on
>> +hi3660 SoC.
>> +
>> +Required properties:
>> +- compatible: should be
>> + "hisilicon,hi3660-reset"
>> +- #reset-cells: 2, see below
>> +- hisi,rst-syscon: phandle of the reset's syscon.
>> +
>> +Example:
>> + iomcu: iomcu at ffd7e000 {
>> + compatible = "hisilicon,hi3660-iomcu", "syscon";
>> + reg = <0x0 0xffd7e000 0x0 0x1000>;
>> + };
>> +
>> + iomcu_rst: iomcu_rst_controller {
>> + compatible = "hisilicon,hi3660-reset";
>> + hisi,rst-syscon = <&iomcu>;
>> + #reset-cells = <2>;
>> + };
>> +
>> +Specifying reset lines connected to IP modules
>> +==============================================
>> +example:
>> +
>> + i2c0: i2c at ..... {
>> + ...
>> + resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
> Should this mention somewhere what register the offset is supposed to
> point to? This is the address offset to the set register, with the
> corresponding clear register being placed at offset + 4.
How about this description.
-- #reset-cells: 2, see below
- hisi,rst-syscon: phandle of the reset's syscon.
+- #reset-cells : Specifies the number of cells needed to encode a
+ reset source. The type shall be a <u32> and the value shall be 2.
+
+ Cell #1 : offset of the reset assert control
+ register from the syscon register base
+ offset + 4: deassert control register
+ offset + 8: status control register
+ Cell #2 : bit position of the reset in the reset control register
May paste in this thread for a clear view.
Thanks
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: Support DTB build for NanoPi M1
From: Milo Kim @ 2016-12-09 1:47 UTC (permalink / raw)
To: linux-arm-kernel
The commit 10efbf5f1633 introduced NanoPi M1 board but it's missing in
Allwinner H3 DTB build.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb..4cbdf6f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -845,6 +845,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+ sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-lite.dtb \
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox