* Re: [PATCH] n900 device tree: cleanup
From: Sebastian Reichel @ 2016-12-07 3:10 UTC (permalink / raw)
To: Pavel Machek
Cc: pali.rohar, kernel list, linux-arm-kernel, linux-omap, tony,
khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge,
bcousson, robh+dt, mark.rutland, devicetree
In-Reply-To: <20161011081243.GA24580@amd>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
Hi Tony,
It looks like this fell through the cracks. Apart from inconsistent
patch subject:
Reviewed-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
On Tue, Oct 11, 2016 at 10:12:43AM +0200, Pavel Machek wrote:
> Fix GPIO comment to be consistent with rest of file and add comment what
> tpa6130 is.
>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index bfffd6c..ca9fe8c 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -47,7 +47,7 @@
> compatible = "gpio-leds";
> heartbeat {
> label = "debug::sleep";
> - gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* gpio162 */
> + gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* 162 */
> linux,default-trigger = "default-on";
> pinctrl-names = "default";
> pinctrl-0 = <&debug_leds>;
> @@ -637,6 +637,7 @@
> reg = <0x55>;
> };
>
> + /* Stereo headphone amplifier */
> tpa6130a2: tpa6130a2@60 {
> compatible = "ti,tpa6130a2";
> reg = <0x60>;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: rk3x: keep i2c irq ON in suspend
From: David.Wu @ 2016-12-07 3:37 UTC (permalink / raw)
To: Doug Anderson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Heiko Stuebner, Wolfram Sang,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC...,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAD=FV=VgGy5hA4+7nvLs4NPNRuopak+bTW34S6X6S_vWgtnkjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Doug,
在 2016/12/7 0:31, Doug Anderson 写道:
> Hi,
>
> On Tue, Dec 6, 2016 at 12:12 AM, David.Wu <david.wu@rock-chips.com> wrote:
>> Hi Heiko,
>>
>> 在 2016/12/5 18:54, Heiko Stuebner 写道:
>>>
>>> Hi David,
>>>
>>> Am Montag, 5. Dezember 2016, 16:02:59 CET schrieb David Wu:
>>>>
>>>> During suspend there may still be some i2c access happening.
>>>> And if we don't keep i2c irq ON, there may be i2c access timeout if
>>>> i2c is in irq mode of operation.
>>>
>>>
>>> can you describe the issue you're trying to fix a bit more please?
>>
>>
>> Sometimes we could see the i2c timeout errors during suspend/resume, which
>> makes the duration of suspend/resume too longer.
>>
>> [ 484.171541] CPU4: Booted secondary processor [410fd082]
>> [ 485.172777] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>> [ 486.172760] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>> [ 487.172759] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>> [ 487.172840] cpu cpu4: _set_opp_voltage: failed to set voltage (800000
>> 800000 800000 mV): -110
>> [ 487.172874] cpu cpu4: failed to set volt 800000
>>
>>>
>>> I.e. I'd think the i2c-core does suspend i2c-client devices first, so that
>>> these should be able to finish up their ongoing transfers and not start
>>> any
>>> new ones instead?
>>>
>>> Your irq can still happen slightly after the system started going to
>>> actually
>>> sleep, so to me it looks like you just widened the window where irqs can
>>> be
>>> handled. Especially as your irq could also just simply stem from the start
>>> state, so you cannot even be sure if your transaction actually is
>>> finished.
>>
>>
>> Okay, you are right. I want to give it a double insurance at first, but it
>> may hide the unhappend issue.
>>
>>>
>>> So to me it looks like the i2c-connected device driver should be fixed
>>> instead?
>>
>>
>> I tell them to fix it in rk808 driver.
>
> To me it seems like perhaps cpufreq should not be changing frequencies
> until it is resumed properly. Presumably if all the ordering is done
> right then cpufreq should be resumed _after_ the i2c regulator so you
> should be OK. ...or am I somehow confused about that?
yes，the cpufreq and regulator should start i2c job after they resume
properly.
>
> Also note that previous i2c busses I worked with simply returned -EIO
> in the case where they were called when suspended. See
> "i2c-exynos5.c" and "i2c-s3c2410.c".
In "i2c-exynos5.c", it seems that using the "i2c->suspended" to protect
i2c transfer works most of the time. Of course it could prevent the next
new i2c transfer to start. But in one case, if the current i2c job was
not finished until the i2c irq was disabled by system suspend, the i2c
timeout error would also happen, as the current i2c job may have a large
data to transfer and it lasts from a long time.
So is it necessary to add a mutex lock to wait the current job to be
finished before the "i2c->suspended" is changed in i2c_suspend_noirq()?
However, the i2c_suspend_noirq() is called after suspend_device_irqs()
in system suspend, it means that the i2c timeout errors could happen
during the time between suspend_device_irqs() and i2c_suspend_noirq(),
if there were i2c transfers started.
>
> -Doug
>
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Chanwoo Choi @ 2016-12-07 4:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc, tomasz.figa, robh+dt, linux-kernel,
javier, kyungmin.park, myungjoo.ham, kgene, s.nawrocki,
linux-arm-kernel
In-Reply-To: <20161206190756.GA12683@kozik-lap>
On 2016년 12월 07일 04:07, Krzysztof Kozlowski wrote:
> On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
>> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
>> to measure the utilization of each IP in Exynos SoC.
>>
>> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
>> block with VDD_MIF power source.
>> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
>> block with VDD_INT power source.
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index 64226d5ae471..8c4ee84d5232 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -599,6 +599,30 @@
>> clock-names = "fin_pll", "mct";
>> };
>>
>> + ppmu_d0_cpu: ppmu@10480000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x10480000 0x2000>;
>> + status = "disabled";
>
> Why these are disabled? They have some external dependencies?
There is no any dependency. If you want to remain it always enabled,
I'm OK.
Best Regards,
Chanwoo Choi
>
> Best regards,
> Krzysztof
>
>> + };
>> +
>> + ppmu_d0_general: ppmu@10490000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x10490000 0x2000>;
>> + status = "disabled";
>> + };
>> +
>> + ppmu_d1_cpu: ppmu@104b0000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x104b0000 0x2000>;
>> + status = "disabled";
>> + };
>> +
>> + ppmu_d1_general: ppmu@104c0000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x104c0000 0x2000>;
>> + status = "disabled";
>> + };
>> +
>> pinctrl_alive: pinctrl@10580000 {
>> compatible = "samsung,exynos5433-pinctrl";
>> reg = <0x10580000 0x1a20>, <0x11090000 0x100>;
>> --
>> 1.9.1
>>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 0/4] dtc: Dynamic DT support
From: David Gibson @ 2016-12-07 4:31 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Jon Loeliger, Grant Likely, Frank Rowand, Rob Herring, Jan Luebbe,
Sascha Hauer, Phil Elwell, Simon Glass, Maxime Ripard,
Thomas Petazzoni, Boris Brezillon, Antoine Tenart, Stephen Boyd,
Devicetree Compiler, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480957528-8367-1-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2665 bytes --]
On Mon, Dec 05, 2016 at 07:05:21PM +0200, Pantelis Antoniou wrote:
> This patchset adds Dynamic DT support in the DTC compiler
> as used in a number of boards like the beaglebone/rpi/chip and others.
>
> The first patch documents the internals of overlay generation, while
> the second one adds dynamic object/overlay support proper.
>
> The third patch adds a test method that can is used by the subsequent
> patch which adds a few overlay tests verifying operation.
>
> The following 3 patches add support for the syntactic sugar version
> of &foo { }; in a similar manner.
>
> This patchset is against DTC mainline and is also available for a pull
> request from https://github.com/pantoniou/dtc/tree/overlays
>
> Regards
>
> -- Pantelis
Ok, I've taken a step back and realized I was getting bogged down
trying to lay plans for possible future design improvements for the
overlays, at the expense of getting something merged to handle the
existing syntax. Sorry.
Re-examining this from that perspective, here are the (small, I
believe) things I'd still like to see done before merging this. Some
of these require backing out changes I suggested myself earlier,
again, sorry - I still think they are good changes for the future, but
for now they're just confusing the issue.
1. Drop support for the "new style" /dts-v1/ /plugin/' tag - only allow
the existing /dts-v1/; /plugin/; format. Rationale: as we clean up
the overlay syntax further in future, we can use the old-style tag
to distinguish old-style overlays and avoid a special backwards
compatibility flag.
2. Drop support for the new magic number. Rationale: we can
use a new magic number to distinguish future improved dtbo
encodings. It'd be nice to distinguish plugins in the existing
format, but they're already out there, so we have to cope anyway,
putting a new magic number in at this stage doesn't really help.
3. Drop the -F command line option. Rationale: output with unresolved
references and no fixups doesn't make sense in any circumstances.
Instead generate fixups if and only if we're in plugin mode
(regardless of -@). Optionally you can omit the fixups nodes if
there are no fixups to be generated.
4. Rename 'versioninfo' in the parser etc. to 'dtsflags'. Rationale:
plugin mode isn't really a "version", and calling it "version"
invites confusion with the dtb output version.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Chanwoo Choi @ 2016-12-07 5:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: javier-JPH+aEBZ4P+UEJcrhfAQsw, kgene-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ,
tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ,
kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <58478C41.5090500-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On 2016년 12월 07일 13:12, Chanwoo Choi wrote:
> On 2016년 12월 07일 04:07, Krzysztof Kozlowski wrote:
>> On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
>>> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
>>> to measure the utilization of each IP in Exynos SoC.
>>>
>>> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
>>> block with VDD_MIF power source.
>>> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
>>> block with VDD_INT power source.
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
>>> 1 file changed, 24 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> index 64226d5ae471..8c4ee84d5232 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> @@ -599,6 +599,30 @@
>>> clock-names = "fin_pll", "mct";
>>> };
>>>
>>> + ppmu_d0_cpu: ppmu@10480000 {
>>> + compatible = "samsung,exynos-ppmu-v2";
>>> + reg = <0x10480000 0x2000>;
>>> + status = "disabled";
>>
>> Why these are disabled? They have some external dependencies?
>
> There is no any dependency. If you want to remain it always enabled,
> I'm OK.
One more comment. Each PPMU has the four events which is used for devfreq driver
to get the utilization. If I remove the 'status = "disabled"' from exynos5433.dtsi,
first probe of PPMU device is fail on case1.
Case1. Disable PPMU device and then enable it on exynos5433-tm2.dts
[ 2.560126] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
[ 2.565957] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
Case2. Enable PPMU device always. First probe is failed and then second probe is successful.
[ 2.898781] exynos-ppmu 10480000.ppmu: failed to get child node of devfreq-event devices
[ 2.899077] exynos-ppmu 10480000.ppmu: failed to parse exynos ppmu dt node
[ 2.899289] exynos-ppmu 10480000.ppmu: failed to parse devicetree for resource
[ 2.899602] exynos-ppmu: probe of 10480000.ppmu failed with error -22
[ 2.905364] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
[ 2.913535] exynos-ppmu 104b0000.ppmu: failed to get child node of devfreq-event devices
[ 2.921402] exynos-ppmu 104b0000.ppmu: failed to parse exynos ppmu dt node
[ 2.928250] exynos-ppmu 104b0000.ppmu: failed to parse devicetree for resource
[ 2.935571] exynos-ppmu: probe of 104b0000.ppmu failed with error -22
[ 2.942144] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
Best Regards,
Chanwoo Choi
[snip]
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Krzysztof Kozlowski @ 2016-12-07 6:13 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Javier Martinez Canillas, kgene-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Sylwester Nawrocki, Tomasz Figa,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ,
kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5847A419.9050801-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, Dec 7, 2016 at 7:54 AM, Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> On 2016년 12월 07일 13:12, Chanwoo Choi wrote:
>> On 2016년 12월 07일 04:07, Krzysztof Kozlowski wrote:
>>> On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
>>>> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
>>>> to measure the utilization of each IP in Exynos SoC.
>>>>
>>>> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
>>>> block with VDD_MIF power source.
>>>> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
>>>> block with VDD_INT power source.
>>>>
>>>> Signed-off-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>> ---
>>>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
>>>> 1 file changed, 24 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>> index 64226d5ae471..8c4ee84d5232 100644
>>>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>>> @@ -599,6 +599,30 @@
>>>> clock-names = "fin_pll", "mct";
>>>> };
>>>>
>>>> + ppmu_d0_cpu: ppmu@10480000 {
>>>> + compatible = "samsung,exynos-ppmu-v2";
>>>> + reg = <0x10480000 0x2000>;
>>>> + status = "disabled";
>>>
>>> Why these are disabled? They have some external dependencies?
>>
>> There is no any dependency. If you want to remain it always enabled,
>> I'm OK.
>
> One more comment. Each PPMU has the four events which is used for devfreq driver
> to get the utilization. If I remove the 'status = "disabled"' from exynos5433.dtsi,
> first probe of PPMU device is fail on case1.
>
> Case1. Disable PPMU device and then enable it on exynos5433-tm2.dts
> [ 2.560126] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
> [ 2.565957] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
>
> Case2. Enable PPMU device always. First probe is failed and then second probe is successful.
> [ 2.898781] exynos-ppmu 10480000.ppmu: failed to get child node of devfreq-event devices
> [ 2.899077] exynos-ppmu 10480000.ppmu: failed to parse exynos ppmu dt node
> [ 2.899289] exynos-ppmu 10480000.ppmu: failed to parse devicetree for resource
> [ 2.899602] exynos-ppmu: probe of 10480000.ppmu failed with error -22
> [ 2.905364] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
> [ 2.913535] exynos-ppmu 104b0000.ppmu: failed to get child node of devfreq-event devices
> [ 2.921402] exynos-ppmu 104b0000.ppmu: failed to parse exynos ppmu dt node
> [ 2.928250] exynos-ppmu 104b0000.ppmu: failed to parse devicetree for resource
> [ 2.935571] exynos-ppmu: probe of 104b0000.ppmu failed with error -22
> [ 2.942144] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
I got it, so leaving it as disabled makes sense. For the reference:
Reviewed-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Re: [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-12-07 7:01 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Rob Herring, Vishnu Patekar, Andre Przywara,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Hans de Goede, Arnd Bergmann,
Maxime Ripard, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
2016年12月7日 05:52于 Alexey Kardashevskiy <aik@ozlabs.ru>写道：
>
> On 06/12/16 18:43, Icenowy Zheng wrote:
> >
> > 2016年12月6日 09:51于 Alexey Kardashevskiy <aik-sLpHqDYs0B2HXe+LvDLADg@public.gmane.org>写道：
> >>
> >> On 03/12/16 02:05, 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-ymACFijhrKM@public.gmane.org>
> >>> ---
> >>> Changes since v2:
> >>> - Merged SDIO Wi-Fi patch into it.
> >>> - SDIO Wi-Fi: add a ethernet1 alias to it, as it has no internal NVRAM.
> >>> - SDIO Wi-Fi: changed pinctrl binding to generic pinconf
> >>> - removed all gpio pinctrl nodes
> >>> - changed h2plus to h2-plus
> >>> Changes since v1:
> >>> - Convert to generic pinconf bindings.
> >>> - SDIO Wi-Fi: add patch.
> >>>
> >>> Some notes:
> >>> - The uart1 and uart2 is available on the unsoldered gpio header.
> >>> - The onboard USB connector has its Vbus directly connected to DCIN-5V (the
> >>> power jack)
> >>>
> >>> arch/arm/boot/dts/Makefile | 1 +
> >>> arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 159 ++++++++++++++++++++++
> >>> 2 files changed, 160 insertions(+)
> >>> create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> >>>
> >>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >>> index 6447abc..59f6e86 100644
> >>> --- a/arch/arm/boot/dts/Makefile
> >>> +++ b/arch/arm/boot/dts/Makefile
> >>> @@ -844,6 +844,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> >>> sun8i-a33-sinlinx-sina33.dtb \
> >>> sun8i-a83t-allwinner-h8homlet-v2.dtb \
> >>> sun8i-a83t-cubietruck-plus.dtb \
> >>> + sun8i-h2-plus-orangepi-zero.dtb \
> >>> sun8i-h3-bananapi-m2-plus.dtb \
> >>> sun8i-h3-nanopi-neo.dtb \
> >>> sun8i-h3-orangepi-2.dtb \
> >>> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> >>> new file mode 100644
> >>> index 0000000..d18807f
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
> >>> @@ -0,0 +1,159 @@
> >>> +/*
> >>> + * Copyright (C) 2016 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >>> + *
> >>> + * Based on sun8i-h3-orangepi-one.dts, which is:
> >>> + * Copyright (C) 2016 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>> + *
> >>> + * This file is dual-licensed: you can use it either under the terms
> >>> + * of the GPL or the X11 license, at your option. Note that this dual
> >>> + * licensing only applies to this file, and not this project as a
> >>> + * whole.
> >>> + *
> >>> + * a) This file is free software; you can redistribute it and/or
> >>> + * modify it under the terms of the GNU General Public License as
> >>> + * 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,
> >>> + * 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,
> >>> + *
> >>> + * 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,
> >>> + * 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
> >>> + * conditions:
> >>> + *
> >>> + * The above copyright notice and this permission notice shall be
> >>> + * included in all copies or substantial portions of the Software.
> >>> + *
> >>> + * 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,
> >>> + * 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.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +#include "sun8i-h3.dtsi"
> >>> +#include "sunxi-common-regulators.dtsi"
> >>> +
> >>> +#include <dt-bindings/gpio/gpio.h>
> >>> +#include <dt-bindings/input/input.h>
> >>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> >>> +
> >>> +/ {
> >>> + model = "Xunlong Orange Pi Zero";
> >>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus";
> >>> +
> >>> + aliases {
> >>> + serial0 = &uart0;
> >>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
> >>
> >>
> >> It is not defined there as for:
> >>
> >> cef87e9 (tag: next-20161205) 20 hours ago Stephen Rothwell Add linux-next
> >> specific files for 20161205
> >
> > The driver of H3's obfuscated DesignWare MAC is not yet mainlined, so there won't be one ethernet0 now.
> >
> > But it's reserved for the onboard Ethernet.
>
>
> Could you please elaborate how you tested this patch (ideally some tree
> somewhere on github)? This patch added RX819, it assumes EMAC support is
> there, neither is there nor there is a way to test this... Thanks.
It do not assume EMAC is there.
It only assume EMAC will be there someday :-)
For tree... wait for my push :-)
>
>
> >
> >>
> >>
> >>
> >>
> >>
> >>> + ethernet1 = &xr819;
> >>> + };
> >>> +
> >>> + chosen {
> >>> + stdout-path = "serial0:115200n8";
> >>> + };
> >>> +
> >>> + leds {
> >>> + compatible = "gpio-leds";
> >>> +
> >>> + pwr_led {
> >>> + label = "orangepi:green:pwr";
> >>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> >>> + default-state = "on";
> >>> + };
> >>> +
> >>> + status_led {
> >>> + label = "orangepi:red:status";
> >>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
> >>> + };
> >>> + };
> >>> +
> >>> + reg_vcc_wifi: reg_vcc_wifi {
> >>> + compatible = "regulator-fixed";
> >>> + regulator-min-microvolt = <3300000>;
> >>> + regulator-max-microvolt = <3300000>;
> >>> + regulator-name = "vcc-wifi";
> >>> + enable-active-high;
> >>> + gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
> >>> + };
> >>> +
> >>> + wifi_pwrseq: wifi_pwrseq {
> >>> + compatible = "mmc-pwrseq-simple";
> >>> + reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
> >>> + };
> >>> +};
> >>> +
> >>> +&ehci1 {
> >>> + status = "okay";
> >>> +};
> >>> +
> >>> +&mmc0 {
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&mmc0_pins_a>;
> >>> + vmmc-supply = <®_vcc3v3>;
> >>> + bus-width = <4>;
> >>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> >>> + cd-inverted;
> >>> + status = "okay";
> >>> +};
> >>> +
> >>> +&mmc1 {
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&mmc1_pins_a>;
> >>> + vmmc-supply = <®_vcc_wifi>;
> >>> + mmc-pwrseq = <&wifi_pwrseq>;
> >>> + bus-width = <4>;
> >>> + non-removable;
> >>> + status = "okay";
> >>> +
> >>> + /*
> >>> + * Explicitly define the sdio device, so that we can add an ethernet
> >>> + * alias for it (which e.g. makes u-boot set a mac-address).
> >>> + */
> >>> + xr819: sdio_wifi@1 {
> >>> + reg = <1>;
> >>> + };
> >>> +};
> >>> +
> >>> +&mmc1_pins_a {
> >>> + bias-pull-up;
> >>> +};
> >>> +
> >>> +&ohci1 {
> >>> + status = "okay";
> >>> +};
> >>> +
> >>> +&uart0 {
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&uart0_pins_a>;
> >>> + status = "okay";
> >>> +};
> >>> +
> >>> +&uart1 {
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&uart1_pins>;
> >>> + status = "disabled";
> >>> +};
> >>> +
> >>> +&uart2 {
> >>> + pinctrl-names = "default";
> >>> + pinctrl-0 = <&uart2_pins>;
> >>> + status = "disabled";
> >>> +};
> >>> +
> >>> +&usbphy {
> >>> + /* USB VBUS is always on */
> >>> + status = "okay";
> >>> +};
> >>>
> >>
> >>
> >> --
> >> Alexey
>
>
> --
> Alexey
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* RE: [v2,2/3] powerpc/fsl/dts: add QMan and BMan portal nodes on t1024
From: Madalin-Cristian Bucur @ 2016-12-07 7:12 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20161207005904.GA12811-vONcSABrMOVpTrP2zolEsF6hYfS7NtTn@public.gmane.org>
> From: Scott Wood [mailto:oss-fOR+EgIDQEHk1uMJSBkQmQ@public.gmane.org]
> Sent: Wednesday, December 07, 2016 2:59 AM
>
> On Tue, Dec 06, 2016 at 03:13:38PM +0200, Madalin Bucur wrote:
> > Signed-off-by: Madalin Bucur <madalin.bucur-3arQi8VN3Tc@public.gmane.org>
> > ---
> > arch/powerpc/boot/dts/fsl/t1024qds.dts | 29
> +++++++++++++++++++++++++++++
> > arch/powerpc/boot/dts/fsl/t1024rdb.dts | 33
> +++++++++++++++++++++++++++++++++
> > 2 files changed, 62 insertions(+)
>
> So, in patch 1/3 you add qman and bman nodes to t1023si-post.dtsi and
> call it "add QMan and BMan portal nodes on t1023rdb" as if it were
> board-specific (the only board-specific part is the reserved-memory
> nodes, not the portals).
>
> Then, in this patch you only touch board-specific files, and label it
> "add QMan and BMan portal nodes on t1024"...
That needs fixing...
> > diff --git a/arch/powerpc/boot/dts/fsl/t1024rdb.dts
> b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
> > index 302cdd2..73a6453 100644
> > --- a/arch/powerpc/boot/dts/fsl/t1024rdb.dts
> > +++ b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
> > @@ -41,6 +41,31 @@
> > #size-cells = <2>;
> > interrupt-parent = <&mpic>;
> >
> > + aliases {
> > + sg_2500_aqr105_phy4 = &sg_2500_aqr105_phy4;
> > + };
>
> What does this have to do with the qman and bman portal nodes? Why is
> this alias needed?
>
> -Scott
It's needed by u-boot, should be a separate patch.
I'll resend.
Madalin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 1/5] ARM: BCM5301X: Fix LAN LED labels for Luxul XWR-3100
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Rob Herring, Mark Rutland, Russell King,
Hauke Mehrtens, bcm-kernel-feedback-list, devicetree,
linux-arm-kernel, linux-kernel, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
They were named incorrectly most likely due to copy & paste mistake.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
index 2f4a651..93cc91d 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
@@ -31,13 +31,13 @@
};
lan3 {
- label = "bcm53xx:green:lan1";
+ label = "bcm53xx:green:lan3";
gpios = <&chipcommon 1 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
lan4 {
- label = "bcm53xx:green:lan0";
+ label = "bcm53xx:green:lan4";
gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
@@ -49,7 +49,7 @@
};
lan1 {
- label = "bcm53xx:green:lan3";
+ label = "bcm53xx:green:lan1";
gpios = <&chipcommon 4 GPIO_ACTIVE_LOW>;
linux,default-trigger = "default-off";
};
--
2.10.1
^ permalink raw reply related
* [PATCH V2 2/5] ARM: BCM5301X: Specify USB controllers in DT
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Rob Herring, Mark Rutland, Russell King,
Hauke Mehrtens, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161207075655.7396-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
There are 3 separated controllers, one per USB /standard/. With PHY
drivers in place they can be simply supported with generic drivers.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Fix node names and reorder ehci with ohci. Thanks Ray!
---
arch/arm/boot/dts/bcm5301x.dtsi | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index f09a2bb..a4614c9 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -248,8 +248,26 @@
#address-cells = <1>;
#size-cells = <1>;
+ ranges;
- phys = <&usb2_phy>;
+ interrupt-parent = <&gic>;
+
+ ehci: ehci@21000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-ehci";
+ reg = <0x00021000 0x1000>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb2_phy>;
+ };
+
+ ohci: ohci@22000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-ohci";
+ reg = <0x00022000 0x1000>;
+ interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ };
};
usb3: usb3@23000 {
@@ -257,6 +275,19 @@
#address-cells = <1>;
#size-cells = <1>;
+ ranges;
+
+ interrupt-parent = <&gic>;
+
+ xhci: xhci@23000 {
+ #usb-cells = <0>;
+
+ compatible = "generic-xhci";
+ reg = <0x00023000 0x1000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&usb3_phy>;
+ phy-names = "usb";
+ };
};
spi@29000 {
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 3/5] ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Rob Herring, Mark Rutland, Russell King,
Hauke Mehrtens, bcm-kernel-feedback-list, devicetree,
linux-arm-kernel, linux-kernel, Rafał Miłecki
In-Reply-To: <20161207075655.7396-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
There is one GPIO controlling power for both USB ports.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V2: Avoid double Signed-off-by due to different e-mail address
---
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index 0225d82..7ab1176 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -100,3 +100,11 @@
};
};
};
+
+&usb2 {
+ vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
+};
+
+&usb3 {
+ vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
+};
--
2.10.1
^ permalink raw reply related
* [PATCH V2 4/5] ARM: BCM5301X: Specify all RAM by including an extra block
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Rob Herring, Mark Rutland, Russell King,
Hauke Mehrtens, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161207075655.7396-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
The first 128 MiB of RAM can be accessed using an alias at address 0x0.
In theory we could access whole RAM using 0x80000000 - 0xbfffffff range
(up to 1 GiB) but it doesn't seem to work on Northstar. For some reason
(hardware setup left by the bootloader maybe?) 0x80000000 - 0x87ffffff
range can't be used. I reproduced this problem on:
1) Buffalo WZR-600DHP2 (BCM47081)
2) Netgear R6250 (BCM4708)
3) D-Link DIR-885L (BCM47094)
So it seems we're forced to access first 128 MiB using alias at 0x0 and
the rest using real base address + 128 MiB offset which is 0x88000000.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Updated commit message, thanks Jon!
Included XWR-3100
---
arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts | 3 ++-
arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts | 3 ++-
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 3 ++-
arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 3 ++-
arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 3 ++-
arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts | 3 ++-
arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 3 ++-
arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 3 ++-
arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 3 ++-
arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 3 ++-
arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 3 ++-
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 ++-
arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 3 ++-
arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 ++-
16 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
index 112a5a8..d241cee 100644
--- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
+++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
index 3600f56..b0e6204 100644
--- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
+++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
index d49afec0..c9ba6b9 100644
--- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
+++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
spi {
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
index 8519548..b9f66c0 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
index 6229ef2..ae0199f 100644
--- a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
+++ b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
index 74cfcd3..36b628b1 100644
--- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
+++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
index 71b98cf..db8608b 100644
--- a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
+++ b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
index 2922536..d51586d 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
spi {
diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
index 184fd92..de041b8 100644
--- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
+++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
gpio-keys {
diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
index eac0f52..eaca687 100644
--- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
+++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
index aab39c9..b32957c 100644
--- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
+++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
index 7ab1176..f459a98 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
index 56d38a3..cd13534 100644
--- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
+++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
index 7fb9270..64ded76 100644
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -21,7 +21,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
nand: nand@18028000 {
diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
index 93cc91d..5cf4ab1 100644
--- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
+++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
@@ -18,7 +18,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x08000000>;
};
leds {
diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
index 7ecd57c..600795e 100644
--- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
+++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
@@ -18,7 +18,8 @@
};
memory {
- reg = <0x00000000 0x08000000>;
+ reg = <0x00000000 0x08000000
+ 0x88000000 0x18000000>;
};
leds {
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 5/5] ARM: BCM53573: Specify USB ports of on-SoC controllers
From: Rafał Miłecki @ 2016-12-07 7:56 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, Rob Herring, Mark Rutland, Russell King,
Hauke Mehrtens, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161207075655.7396-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Broadcom OHCI and EHCI controllers always have 2 ports each on the root
hub. Describe them in DT to allow specifying extra info or referencing
port nodes.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
arch/arm/boot/dts/bcm53573.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/bcm53573.dtsi b/arch/arm/boot/dts/bcm53573.dtsi
index e2c496a..2da04d0 100644
--- a/arch/arm/boot/dts/bcm53573.dtsi
+++ b/arch/arm/boot/dts/bcm53573.dtsi
@@ -124,6 +124,17 @@
reg = <0x4000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ehci_port1: port@1 {
+ reg = <1>;
+ };
+
+ ehci_port2: port@2 {
+ reg = <2>;
+ };
};
ohci: ohci@d000 {
@@ -133,6 +144,17 @@
reg = <0xd000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ohci_port1: port@1 {
+ reg = <1>;
+ };
+
+ ohci_port2: port@2 {
+ reg = <2>;
+ };
};
};
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ARM: EXYNOS: remove smp hook from machine descriptor
From: Pankaj Dubey @ 2016-12-07 8:30 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: krzk-DgEjT+Ai2ygdnm+yROfE0A, kgene-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, thomas.ab-Sze3O3UU22JBDgjK7y7TUQ,
Pankaj Dubey
Use CPU_METHOD_OF_DECLARE() for smp_ops instead of using it
via machine descriptor.
Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/exynos3250.dtsi | 1 +
arch/arm/boot/dts/exynos4210.dtsi | 1 +
arch/arm/boot/dts/exynos4212.dtsi | 1 +
arch/arm/boot/dts/exynos4412.dtsi | 1 +
arch/arm/boot/dts/exynos5250.dtsi | 1 +
arch/arm/boot/dts/exynos5260.dtsi | 1 +
arch/arm/boot/dts/exynos5410.dtsi | 1 +
arch/arm/boot/dts/exynos5420-cpus.dtsi | 1 +
arch/arm/boot/dts/exynos5422-cpus.dtsi | 1 +
arch/arm/boot/dts/exynos5440.dtsi | 1 +
arch/arm/mach-exynos/common.h | 2 --
arch/arm/mach-exynos/exynos.c | 1 -
arch/arm/mach-exynos/platsmp.c | 2 ++
13 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index ba17ee1..f28f669 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -53,6 +53,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 7f3a18c..6dfd98d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -35,6 +35,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu@900 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
index 5389011..3e8982e 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -25,6 +25,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu@A00 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 40beede..faf2fb8 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -25,6 +25,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu@A00 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index b6d7444..580897c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -52,6 +52,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
index 5818718..1af6e76 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -32,6 +32,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index 2b6adaf..b092cdc 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -33,6 +33,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index 5c052d7..a587704 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -24,6 +24,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index bf3c6f1..7fcdfd0 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -23,6 +23,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu0: cpu@100 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 2a2e570..0a958e8 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -50,6 +50,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "samsung,exynos-smp";
cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index fb12d11..051e1ab 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -143,8 +143,6 @@ static inline void exynos_pm_init(void) {}
extern void exynos_cpu_resume(void);
extern void exynos_cpu_resume_ns(void);
-extern const struct smp_operations exynos_smp_ops;
-
extern void exynos_cpu_power_down(int cpu);
extern void exynos_cpu_power_up(int cpu);
extern int exynos_cpu_power_state(int cpu);
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index fa08ef9..f0a766e 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -211,7 +211,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
/* Maintainer: Kukjin Kim <kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> */
.l2c_aux_val = 0x3c400001,
.l2c_aux_mask = 0xc20fffff,
- .smp = smp_ops(exynos_smp_ops),
.map_io = exynos_init_io,
.init_early = exynos_firmware_init,
.init_irq = exynos_init_irq,
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 94405c7..43eec10 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -474,3 +474,5 @@ const struct smp_operations exynos_smp_ops __initconst = {
.cpu_die = exynos_cpu_die,
#endif
};
+
+CPU_METHOD_OF_DECLARE(exynos_smp, "samsung,exynos-smp", &exynos_smp_ops);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v5 00/13] net: ethernet: ti: cpts: update and fixes
From: Richard Cochran @ 2016-12-07 8:58 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA, Mugunthan V N,
Sekhar Nori, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Murali Karicheri, Wingman Kwok,
Thomas Gleixner
In-Reply-To: <20161207000045.28333-1-grygorii.strashko-l0cyMroinI0@public.gmane.org>
On Tue, Dec 06, 2016 at 06:00:32PM -0600, Grygorii Strashko wrote:
> It is preparation series intended to clean up and optimize TI CPTS driver to
> facilitate further integration with other TI's SoCs like Keystone 2.
>
> Changes in v5:
> - fixed copy paste error in cpts_release
> - reworked cc.mult/shift and cc_mult initialization
Looks good to me now. For the series:
Acked-by: Richard Cochran <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 08/16] drivers/fsi: Add crc4 helpers
From: Greg KH @ 2016-12-07 9:02 UTC (permalink / raw)
To: Chris Bostic
Cc: mark.rutland, devicetree, benh, geert+renesas, andrew,
linux-kernel, mturquette, linux, Chris Bostic, sre, robh+dt,
Jeremy Kerr, alistair, linux-arm-kernel, joel
In-Reply-To: <1481076574-54711-2-git-send-email-christopher.lee.bostic@gmail.com>
On Tue, Dec 06, 2016 at 08:09:31PM -0600, Chris Bostic wrote:
> From: Jeremy Kerr <jk@ozlabs.org>
>
> Add some helpers for the crc checks for the slave configuration table.
> This works 4-bits-at-a-time, using a simple table approach.
>
> We will need this in the FSI core code, as well as any master
> implementations that need to calculate CRCs in software.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
> ---
> drivers/fsi/fsi-core.c | 21 +++++++++++++++++++++
> drivers/fsi/fsi-master.h | 21 +++++++++++++++++++++
> 2 files changed, 42 insertions(+)
Why not just create lib/crc4.c with these functions, like the other crc
functions in the kernel? Don't bury these in some random driver
subsystem please.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/2] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
From: Nicolas Ferre @ 2016-12-07 9:04 UTC (permalink / raw)
To: Peter Rosin, linux-kernel, alsa-devel
Cc: Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
Arnd Bergmann, Greg Kroah-Hartman, Jaroslav Kysela, Takashi Iwai,
devicetree, linux-arm-kernel
In-Reply-To: <1481052157-23400-2-git-send-email-peda@axentia.se>
Le 06/12/2016 à 20:22, Peter Rosin a écrit :
> The SSC is currently not usable with the ASoC simple-audio-card, as
> every SSC audio user has to build a platform driver that may do as
> little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
> allocates the SSC and registers a DAI with the ASoC subsystem).
>
> So, have that happen automatically, if the #sound-dai-cells property
> is present in devicetree, which it has to be anyway for simple audio
> card to work.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Sounds okay: thanks Peter.
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
I don't think my tag is needed for second patch but you can add it if
you wish.
Regards,
> ---
> .../devicetree/bindings/misc/atmel-ssc.txt | 2 +
> drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
> include/linux/atmel-ssc.h | 1 +
> 3 files changed, 53 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> index efc98ea1f23d..f8629bb73945 100644
> --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> @@ -24,6 +24,8 @@ Optional properties:
> this parameter to choose where the clock from.
> - By default the clock is from TK pin, if the clock from RK pin, this
> property is needed.
> + - #sound-dai-cells: Should contain <0>.
> + - This property makes the SSC into an automatically registered DAI.
>
> Examples:
> - PDC transfer:
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index 0516ecda54d3..b2a0340f277e 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -20,6 +20,8 @@
>
> #include <linux/of.h>
>
> +#include "../../sound/soc/atmel/atmel_ssc_dai.h"
> +
> /* Serialize access to ssc_list and user count */
> static DEFINE_SPINLOCK(user_lock);
> static LIST_HEAD(ssc_list);
> @@ -145,6 +147,49 @@ static inline const struct atmel_ssc_platform_data * __init
> platform_get_device_id(pdev)->driver_data;
> }
>
> +#ifdef CONFIG_SND_ATMEL_SOC_SSC
> +static int ssc_sound_dai_probe(struct ssc_device *ssc)
> +{
> + struct device_node *np = ssc->pdev->dev.of_node;
> + int ret;
> + int id;
> +
> + ssc->sound_dai = false;
> +
> + if (!of_property_read_bool(np, "#sound-dai-cells"))
> + return 0;
> +
> + id = of_alias_get_id(np, "ssc");
> + if (id < 0)
> + return id;
> +
> + ret = atmel_ssc_set_audio(id);
> + ssc->sound_dai = !ret;
> +
> + return ret;
> +}
> +
> +static void ssc_sound_dai_remove(struct ssc_device *ssc)
> +{
> + if (!ssc->sound_dai)
> + return;
> +
> + atmel_ssc_put_audio(of_alias_get_id(ssc->pdev->dev.of_node, "ssc"));
> +}
> +#else
> +static inline int ssc_sound_dai_probe(struct ssc_device *ssc)
> +{
> + if (of_property_read_bool(ssc->pdev->dev.of_node, "#sound-dai-cells"))
> + return -ENOTSUPP;
> +
> + return 0;
> +}
> +
> +static inline void ssc_sound_dai_remove(struct ssc_device *ssc)
> +{
> +}
> +#endif
> +
> static int ssc_probe(struct platform_device *pdev)
> {
> struct resource *regs;
> @@ -204,6 +249,9 @@ static int ssc_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n",
> ssc->regs, ssc->irq);
>
> + if (ssc_sound_dai_probe(ssc))
> + dev_err(&pdev->dev, "failed to auto-setup ssc for audio\n");
> +
> return 0;
> }
>
> @@ -211,6 +259,8 @@ static int ssc_remove(struct platform_device *pdev)
> {
> struct ssc_device *ssc = platform_get_drvdata(pdev);
>
> + ssc_sound_dai_remove(ssc);
> +
> spin_lock(&user_lock);
> list_del(&ssc->list);
> spin_unlock(&user_lock);
> diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
> index 7c0f6549898b..fdb545101ede 100644
> --- a/include/linux/atmel-ssc.h
> +++ b/include/linux/atmel-ssc.h
> @@ -20,6 +20,7 @@ struct ssc_device {
> int user;
> int irq;
> bool clk_from_rk_pin;
> + bool sound_dai;
> };
>
> struct ssc_device * __must_check ssc_request(unsigned int ssc_num);
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 04/16] drivers/fsi: Add fsi master definition
From: Greg KH @ 2016-12-07 9:06 UTC (permalink / raw)
To: Chris Bostic
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sre-DgEjT+Ai2ygdnm+yROfE0A,
mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jeremy Kerr,
joel-U3u1mxZcP9KHXe+LvDLADg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andrew-zrmu5oMJ5Fs, alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, Chris Bostic
In-Reply-To: <1481076574-54711-1-git-send-email-christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Dec 06, 2016 at 08:09:30PM -0600, Chris Bostic wrote:
> From: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
>
> Signed-off-by: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/fsi/fsi-core.c | 20 ++++++++++++++++++++
> drivers/fsi/fsi-master.h | 37 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 57 insertions(+)
> create mode 100644 drivers/fsi/fsi-master.h
>
> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
> index 3d55bd5..ce9428d 100644
> --- a/drivers/fsi/fsi-core.c
> +++ b/drivers/fsi/fsi-core.c
> @@ -17,6 +17,26 @@
> #include <linux/fsi.h>
> #include <linux/module.h>
>
> +#include "fsi-master.h"
> +
> +static atomic_t master_idx = ATOMIC_INIT(-1);
You don't really want/need an atomic variable, please use the simple ida
interface instead.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 11/16] drivers/fsi: Add device read/write/peek functions
From: Greg KH @ 2016-12-07 9:29 UTC (permalink / raw)
To: Chris Bostic
Cc: mark.rutland, devicetree, benh, geert+renesas, andrew,
linux-kernel, mturquette, linux, Chris Bostic, sre, robh+dt,
Jeremy Kerr, alistair, linux-arm-kernel, joel
In-Reply-To: <1481076574-54711-4-git-send-email-christopher.lee.bostic@gmail.com>
On Tue, Dec 06, 2016 at 08:09:33PM -0600, Chris Bostic wrote:
> diff --git a/include/linux/fsi.h b/include/linux/fsi.h
> index efa55ba..66bce48 100644
> --- a/include/linux/fsi.h
> +++ b/include/linux/fsi.h
> @@ -27,6 +27,12 @@ struct fsi_device {
> uint32_t size;
> };
>
> +extern int fsi_device_read(struct fsi_device *dev, uint32_t addr,
> + void *val, size_t size);
> +extern int fsi_device_write(struct fsi_device *dev, uint32_t addr,
> + const void *val, size_t size);
> +extern int fsi_device_peek(struct fsi_device *dev, void *val);
> +
> struct fsi_device_id {
> u8 engine_type;
> u8 version;
> @@ -40,7 +46,6 @@ struct fsi_device_id {
> #define FSI_DEVICE_VERSIONED(t, v) \
> .engine_type = (t), .version = (v),
>
> -
> struct fsi_driver {
> struct device_driver drv;
> const struct fsi_device_id *id_table;
Strange whitespace change here :)
Not a real problem, I like the fact that you have broken this down into
very logical pieces making it much easier to review, thanks so much for
doing this.
greg k-h
^ permalink raw reply
* Re: [PATCH 14/16] drivers/fsi: Add master unscan
From: Greg KH @ 2016-12-07 9:31 UTC (permalink / raw)
To: Chris Bostic
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sre-DgEjT+Ai2ygdnm+yROfE0A,
mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chris Bostic,
joel-U3u1mxZcP9KHXe+LvDLADg, jk-mnsaURCQ41sdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-zrmu5oMJ5Fs,
alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
In-Reply-To: <1481069677-53660-15-git-send-email-christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Dec 06, 2016 at 06:14:35PM -0600, Chris Bostic wrote:
> From: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> Allow a master to undo a previous scan. Should a master scan a bus
> twice it will need to ensure it doesn't double register any
> previously detected device.
>
> Signed-off-by: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> ---
> drivers/fsi/fsi-core.c | 36 +++++++++++++++++++++++++++++++++++-
> drivers/fsi/fsi-master.h | 2 ++
> include/linux/fsi.h | 1 +
> 3 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
> index a28434b..8ccfe50 100644
> --- a/drivers/fsi/fsi-core.c
> +++ b/drivers/fsi/fsi-core.c
> @@ -41,6 +41,8 @@
> static atomic_t master_idx = ATOMIC_INIT(-1);
>
> struct fsi_slave {
> + struct list_head list_link; /* Master's list of slaves */
> + struct list_head my_engines;
> struct device dev;
> struct fsi_master *master;
> int link;
> @@ -196,6 +198,8 @@ static int fsi_slave_scan(struct fsi_slave *slave)
> uint32_t conf;
> int rc, i;
>
> + INIT_LIST_HEAD(&slave->my_engines);
> +
> /*
> * scan engines
> *
> @@ -264,7 +268,9 @@ static int fsi_slave_scan(struct fsi_slave *slave)
> if (rc) {
> dev_warn(&slave->dev, "add failed: %d\n", rc);
> put_device(&dev->dev);
> + continue;
> }
> + list_add(&dev->link, &slave->my_engines);
> }
>
> engine_addr += slots * engine_page_size;
> @@ -357,7 +363,7 @@ static int fsi_slave_init(struct fsi_master *master,
> put_device(&slave->dev);
> return rc;
> }
> -
> + list_add(&slave->list_link, &master->my_slaves);
> fsi_slave_scan(slave);
> return 0;
> }
> @@ -388,6 +394,11 @@ static int fsi_master_scan(struct fsi_master *master)
> int link, slave_id, rc;
> uint32_t smode;
>
> + if (!master->slave_list) {
> + INIT_LIST_HEAD(&master->my_slaves);
> + master->slave_list = true;
> + }
> +
> for (link = 0; link < master->n_links; link++) {
> rc = fsi_master_link_enable(master, link);
> if (rc) {
> @@ -423,9 +434,31 @@ static int fsi_master_scan(struct fsi_master *master)
> return 0;
> }
>
> +static void fsi_master_unscan(struct fsi_master *master)
> +{
> + struct fsi_slave *slave, *slave_tmp;
> + struct fsi_device *fsi_dev, *fsi_dev_tmp;
> +
> + if (!master->slave_list)
> + return;
> +
> + list_for_each_entry_safe(slave, slave_tmp, &master->my_slaves,
> + list_link) {
> + list_del(&slave->list_link);
> + list_for_each_entry_safe(fsi_dev, fsi_dev_tmp,
> + &slave->my_engines, link) {
> + list_del(&fsi_dev->link);
> + put_device(&fsi_dev->dev);
> + }
> + device_unregister(&slave->dev);
> + }
> + master->slave_list = false;
> +}
> +
> int fsi_master_register(struct fsi_master *master)
> {
> master->idx = atomic_inc_return(&master_idx);
> + master->slave_list = false;
> get_device(master->dev);
> fsi_master_scan(master);
> return 0;
> @@ -434,6 +467,7 @@ int fsi_master_register(struct fsi_master *master)
>
> void fsi_master_unregister(struct fsi_master *master)
> {
> + fsi_master_unscan(master);
> put_device(master->dev);
> }
> EXPORT_SYMBOL_GPL(fsi_master_unregister);
> diff --git a/drivers/fsi/fsi-master.h b/drivers/fsi/fsi-master.h
> index 56aad0e..454af2b 100644
> --- a/drivers/fsi/fsi-master.h
> +++ b/drivers/fsi/fsi-master.h
> @@ -20,6 +20,8 @@
> #include <linux/device.h>
>
> struct fsi_master {
> + struct list_head my_slaves;
> + bool slave_list;
> struct device *dev;
> int idx;
> int n_links;
> diff --git a/include/linux/fsi.h b/include/linux/fsi.h
> index 66bce48..924502b 100644
> --- a/include/linux/fsi.h
> +++ b/include/linux/fsi.h
> @@ -18,6 +18,7 @@
> #include <linux/device.h>
>
> struct fsi_device {
> + struct list_head link; /* for slave's list */
Can't you use the device list on the bus instead? Putting a device on
multiple lists gets tricky very quickly :(
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 14/22] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation
From: Laurent Pinchart @ 2016-12-07 9:53 UTC (permalink / raw)
To: Rob Herring
Cc: Fabio Estevam, Jose Abreu, Laurent Pinchart, Ulrich Hecht,
devicetree, Kieran Bingham, dri-devel, linux-renesas-soc,
Russell King, Andy Yan, Vladimir Zapolskiy
In-Reply-To: <20161206211550.oprrw3m76locagfo@rob-hp-laptop>
Hi Rob,
On Tuesday 06 Dec 2016 15:15:50 Rob Herring wrote:
> On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote:
> > Make it clear that the core bridge/dw_hdmi.txt document isn't a device
> > tree binding by itself but is meant to be referenced by platform device
> > tree bindings, and update the Rockchip and Freescale DWC HDMI TX
> > bindings to reference it.
> >
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >
> > .../devicetree/bindings/display/bridge/dw_hdmi.txt | 85 +++++++----------
> > .../devicetree/bindings/display/imx/hdmi.txt | 51 +++++++------
> > .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 43 +++++++----
> > 3 files changed, 91 insertions(+), 88 deletions(-)
>
> Acked-by: Rob Herring <robh@kernel.org>
>
> Really, the ddc-i2c-bus prop needs to move to a connector node, but
> that's a separate problem.
I fully agree. One step at a time though :-)
> We might also want to drop the 'ddc-' part and have a generic way to refer
> to an i2c bus. There's a couple of other cases.
Right, but a DT node might need to refer to multiple I2C buses (probably not
for connectors though). The ddc- prefix serves a similar purpose than the
power supply or GPIO name in the *-supply or *-gpios properties.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 3/8] rtc: add STM32 RTC driver
From: Amelie DELAUNAY @ 2016-12-07 10:16 UTC (permalink / raw)
To: Mathieu Poirier, a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Alexandre TORGUE, linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Gabriel FERNANDEZ
In-Reply-To: <20161205163212.GA10458-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 12/05/2016 05:32 PM, Mathieu Poirier wrote:
> On Mon, Dec 05, 2016 at 10:43:14AM +0100, Amelie DELAUNAY wrote:
>> Hi Mathieu,
>>
>> Thanks for reviewing
>>
>> On 12/02/2016 06:56 PM, Mathieu Poirier wrote:
>>> On Fri, Dec 02, 2016 at 03:09:56PM +0100, Amelie Delaunay wrote:
>>>> This patch adds support for the STM32 RTC.
>>>
>>> Hello Amelie,
>>>
>>>>
>>>> Signed-off-by: Amelie Delaunay <amelie.delaunay-qxv4g6HH51o@public.gmane.org>
>>>> ---
>>>> drivers/rtc/Kconfig | 10 +
>>>> drivers/rtc/Makefile | 1 +
>>>> drivers/rtc/rtc-stm32.c | 777
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 788 insertions(+)
>>>> create mode 100644 drivers/rtc/rtc-stm32.c
>>>>
>>>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>>>> index e859d14..dd8b218 100644
>>>> --- a/drivers/rtc/Kconfig
>>>> +++ b/drivers/rtc/Kconfig
>>>> @@ -1706,6 +1706,16 @@ config RTC_DRV_PIC32
>>>> This driver can also be built as a module. If so, the module
>>>> will be called rtc-pic32
>>>>
>>>> +config RTC_DRV_STM32
>>>> + tristate "STM32 On-Chip RTC"
>>>> + depends on ARCH_STM32
>>>> + help
>>>> + If you say yes here you get support for the STM32 On-Chip
>>>> + Real Time Clock.
>>>> +
>>>> + This driver can also be built as a module, if so, the module
>>>> + will be called "rtc-stm32".
>>>> +
>>>> comment "HID Sensor RTC drivers"
>>>>
>>>> config RTC_DRV_HID_SENSOR_TIME
>>>> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
>>>> index 1ac694a..87bd9cc 100644
>>>> --- a/drivers/rtc/Makefile
>>>> +++ b/drivers/rtc/Makefile
>>>> @@ -144,6 +144,7 @@ obj-$(CONFIG_RTC_DRV_SNVS) += rtc-snvs.o
>>>> obj-$(CONFIG_RTC_DRV_SPEAR) += rtc-spear.o
>>>> obj-$(CONFIG_RTC_DRV_STARFIRE) += rtc-starfire.o
>>>> obj-$(CONFIG_RTC_DRV_STK17TA8) += rtc-stk17ta8.o
>>>> +obj-$(CONFIG_RTC_DRV_STM32) += rtc-stm32.o
>>>> obj-$(CONFIG_RTC_DRV_STMP) += rtc-stmp3xxx.o
>>>> obj-$(CONFIG_RTC_DRV_ST_LPC) += rtc-st-lpc.o
>>>> obj-$(CONFIG_RTC_DRV_SUN4V) += rtc-sun4v.o
>>>> diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
>>>> new file mode 100644
>>>> index 0000000..9e710ff
>>>> --- /dev/null
>>>> +++ b/drivers/rtc/rtc-stm32.c
>>>> @@ -0,0 +1,777 @@
>>>> +/*
>>>> + * Copyright (C) Amelie Delaunay 2015
>>>> + * Author: Amelie Delaunay <adelaunay.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> + * License terms: GNU General Public License (GPL), version 2
>>>> + */
>>>> +
>>>> +#include <linux/bcd.h>
>>>> +#include <linux/clk.h>
>>>> +#include <linux/init.h>
>>>> +#include <linux/io.h>
>>>> +#include <linux/iopoll.h>
>>>> +#include <linux/ioport.h>
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/mfd/syscon.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_device.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/regmap.h>
>>>> +#include <linux/rtc.h>
>>>> +#include <linux/spinlock.h>
>>>> +
>>>> +#define DRIVER_NAME "stm32_rtc"
>>>> +
>>>> +/* STM32 RTC registers */
>>>> +#define STM32_RTC_TR 0x00
>>>> +#define STM32_RTC_DR 0x04
>>>> +#define STM32_RTC_CR 0x08
>>>> +#define STM32_RTC_ISR 0x0C
>>>> +#define STM32_RTC_PRER 0x10
>>>> +#define STM32_RTC_ALRMAR 0x1C
>>>> +#define STM32_RTC_WPR 0x24
>>>> +
>>>> +/* STM32_RTC_TR bit fields */
>>>> +#define STM32_RTC_TR_SEC_SHIFT 0
>>>> +#define STM32_RTC_TR_SEC GENMASK(6, 0)
>>>> +#define STM32_RTC_TR_MIN_SHIFT 8
>>>> +#define STM32_RTC_TR_MIN GENMASK(14, 8)
>>>> +#define STM32_RTC_TR_HOUR_SHIFT 16
>>>> +#define STM32_RTC_TR_HOUR GENMASK(21, 16)
>>>> +
>>>> +/* STM32_RTC_DR bit fields */
>>>> +#define STM32_RTC_DR_DATE_SHIFT 0
>>>> +#define STM32_RTC_DR_DATE GENMASK(5, 0)
>>>> +#define STM32_RTC_DR_MONTH_SHIFT 8
>>>> +#define STM32_RTC_DR_MONTH GENMASK(11, 8)
>>>> +#define STM32_RTC_DR_WDAY_SHIFT 13
>>>> +#define STM32_RTC_DR_WDAY GENMASK(15, 13)
>>>> +#define STM32_RTC_DR_YEAR_SHIFT 16
>>>> +#define STM32_RTC_DR_YEAR GENMASK(23, 16)
>>>> +
>>>> +/* STM32_RTC_CR bit fields */
>>>> +#define STM32_RTC_CR_FMT BIT(6)
>>>> +#define STM32_RTC_CR_ALRAE BIT(8)
>>>> +#define STM32_RTC_CR_ALRAIE BIT(12)
>>>> +
>>>> +/* STM32_RTC_ISR bit fields */
>>>> +#define STM32_RTC_ISR_ALRAWF BIT(0)
>>>> +#define STM32_RTC_ISR_INITS BIT(4)
>>>> +#define STM32_RTC_ISR_RSF BIT(5)
>>>> +#define STM32_RTC_ISR_INITF BIT(6)
>>>> +#define STM32_RTC_ISR_INIT BIT(7)
>>>> +#define STM32_RTC_ISR_ALRAF BIT(8)
>>>> +
>>>> +/* STM32_RTC_PRER bit fields */
>>>> +#define STM32_RTC_PRER_PRED_S_SHIFT 0
>>>> +#define STM32_RTC_PRER_PRED_S GENMASK(14, 0)
>>>> +#define STM32_RTC_PRER_PRED_A_SHIFT 16
>>>> +#define STM32_RTC_PRER_PRED_A GENMASK(22, 16)
>>>> +
>>>> +/* STM32_RTC_ALRMAR and STM32_RTC_ALRMBR bit fields */
>>>> +#define STM32_RTC_ALRMXR_SEC_SHIFT 0
>>>> +#define STM32_RTC_ALRMXR_SEC GENMASK(6, 0)
>>>> +#define STM32_RTC_ALRMXR_SEC_MASK BIT(7)
>>>> +#define STM32_RTC_ALRMXR_MIN_SHIFT 8
>>>> +#define STM32_RTC_ALRMXR_MIN GENMASK(14, 8)
>>>> +#define STM32_RTC_ALRMXR_MIN_MASK BIT(15)
>>>> +#define STM32_RTC_ALRMXR_HOUR_SHIFT 16
>>>> +#define STM32_RTC_ALRMXR_HOUR GENMASK(21, 16)
>>>> +#define STM32_RTC_ALRMXR_PM BIT(22)
>>>> +#define STM32_RTC_ALRMXR_HOUR_MASK BIT(23)
>>>> +#define STM32_RTC_ALRMXR_DATE_SHIFT 24
>>>> +#define STM32_RTC_ALRMXR_DATE GENMASK(29, 24)
>>>> +#define STM32_RTC_ALRMXR_WDSEL BIT(30)
>>>> +#define STM32_RTC_ALRMXR_WDAY_SHIFT 24
>>>> +#define STM32_RTC_ALRMXR_WDAY GENMASK(27, 24)
>>>> +#define STM32_RTC_ALRMXR_DATE_MASK BIT(31)
>>>> +
>>>> +/* STM32_RTC_WPR key constants */
>>>> +#define RTC_WPR_1ST_KEY 0xCA
>>>> +#define RTC_WPR_2ND_KEY 0x53
>>>> +#define RTC_WPR_WRONG_KEY 0xFF
>>>> +
>>>> +/*
>>>> + * RTC registers are protected agains parasitic write access.
>>>> + * PWR_CR_DBP bit must be set to enable write access to RTC registers.
>>>> + */
>>>> +/* STM32_PWR_CR */
>>>> +#define PWR_CR 0x00
>>>> +/* STM32_PWR_CR bit field */
>>>> +#define PWR_CR_DBP BIT(8)
>>>> +
>>>> +static struct regmap *dbp;
>>>> +
>>>> +struct stm32_rtc {
>>>> + struct rtc_device *rtc_dev;
>>>> + void __iomem *base;
>>>> + struct clk *pclk;
>>>> + struct clk *ck_rtc;
>>>> + unsigned int clksrc;
>>>> + spinlock_t lock; /* Protects registers accesses */
>>>> + int irq_alarm;
>>>> + struct regmap *pwrcr;
>>>> +};
>>>> +
>>>> +static inline unsigned int stm32_rtc_readl(struct stm32_rtc *rtc,
>>>> + unsigned int offset)
>>>> +{
>>>> + return readl_relaxed(rtc->base + offset);
>>>> +}
>>>> +
>>>> +static inline void stm32_rtc_writel(struct stm32_rtc *rtc,
>>>> + unsigned int offset, unsigned int value)
>>>> +{
>>>> + writel_relaxed(value, rtc->base + offset);
>>>> +}
>>>
>>> I'm not sure wrapping the readl/writel_relaxed function does anything
>> special
>>> other than simply redirecting the reader to another section of the code.
>> During development phase, it is useful to add debug traces but you're right,
>> this can be remove.
>>>
>>>> +
>>>> +static void stm32_rtc_wpr_unlock(struct stm32_rtc *rtc)
>>>> +{
>>>> +// if (dbp)
>>>> +// regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, PWR_CR_DBP);
>>>
>>> Did checkpatch let you get away with this? What did you intend to do
>> here?
>> Hum, as surprising as it may seem, checkpatch didn't complained about these
>> comments! But anyway, this has to be removed, it was a tentative to
>> enable/disable backup domain write protection any time we have to write in a
>> protected RTC register, but it is not functionnal. I have commented this
>> just to keep it in mind and forget to remove it before sending.
>>>
>>>> +
>>>> + stm32_rtc_writel(rtc, STM32_RTC_WPR, RTC_WPR_1ST_KEY);
>>>> + stm32_rtc_writel(rtc, STM32_RTC_WPR, RTC_WPR_2ND_KEY);
>>>> +}
>>>> +
>>>> +static void stm32_rtc_wpr_lock(struct stm32_rtc *rtc)
>>>> +{
>>>> + stm32_rtc_writel(rtc, STM32_RTC_WPR, RTC_WPR_WRONG_KEY);
>>>> +
>>>> +// if (dbp)
>>>> +// regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
>>>> +}
>>>> +
>>>> +static int stm32_rtc_enter_init_mode(struct stm32_rtc *rtc)
>>>> +{
>>>> + unsigned int isr = stm32_rtc_readl(rtc, STM32_RTC_ISR);
>>>> +
>>>> + if (!(isr & STM32_RTC_ISR_INITF)) {
>>>> + isr |= STM32_RTC_ISR_INIT;
>>>> + stm32_rtc_writel(rtc, STM32_RTC_ISR, isr);
>>>> +
>>>> + return readl_relaxed_poll_timeout_atomic(
>>>> + rtc->base + STM32_RTC_ISR,
>>>> + isr, (isr & STM32_RTC_ISR_INITF),
>>>> + 10, 100000);
>>>
>>> When using hard coded numerics please add comments that explains the
>> reason
>>> behind the selected values.
>> Sure. It takes around 2 RTCCLK clock cycles to enter in initialization phase
>> mode. So it depends on the frequency of the ck_rtc parent clock.
>> Either I keep parent clock frequency and compute the exact timeout, or I use
>> the "best and worst cases": slowest RTCCLK frequency is 32kHz, so it can
>> take up to 62us, highest RTCCLK frequency should be 1MHz, so it can take
>> only 2us. Polling every 10us with a timeout of 100ms seemed reasonable and
>> be a good compromise.
>
> I think this is a resonnable approach - please add that explanation as a comment
> in the code.
Ok I'll do that.
>
>>>
>>>> + }
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static void stm32_rtc_exit_init_mode(struct stm32_rtc *rtc)
>>>> +{
>>>> + unsigned int isr = stm32_rtc_readl(rtc, STM32_RTC_ISR);
>>>> +
>>>> + isr &= ~STM32_RTC_ISR_INIT;
>>>> + stm32_rtc_writel(rtc, STM32_RTC_ISR, isr);
>>>> +}
>>>> +
>>>> +static int stm32_rtc_wait_sync(struct stm32_rtc *rtc)
>>>> +{
>>>> + unsigned int isr;
>>>> +
>>>> + isr = stm32_rtc_readl(rtc, STM32_RTC_ISR);
>>>> +
>>>> + isr &= ~STM32_RTC_ISR_RSF;
>>>> + stm32_rtc_writel(rtc, STM32_RTC_ISR, isr);
>>>> +
>>>> + /* Wait the registers to be synchronised */
>>>> + return readl_relaxed_poll_timeout_atomic(rtc->base + STM32_RTC_ISR,
>>>> + isr,
>>>> + (isr & STM32_RTC_ISR_RSF),
>>>> + 10, 100000);
>>>
>>> Shouldn't the break condition be !((isr & STM32_RTC_ISR_RSF) ? If not
>> this
>>> probably deserve a better comment.
>> RSF bit is set by hardware each time the calendar registers are synchronized
>> (it takes up to 2 RTCCLK). So the break condition is correct: we poll until
>> RSF flag is set or timeout is reached.
>>>
>>>> +}
>>>> +
>>>> +static irqreturn_t stm32_rtc_alarm_irq(int irq, void *dev_id)
>>>> +{
>>>> + struct stm32_rtc *rtc = (struct stm32_rtc *)dev_id;
>>>> + unsigned long irqflags, events = 0;
>>>> + unsigned int isr, cr;
>>>> +
>>>> + spin_lock_irqsave(&rtc->lock, irqflags);
>>>> +
>>>> + isr = stm32_rtc_readl(rtc, STM32_RTC_ISR);
>>>> + cr = stm32_rtc_readl(rtc, STM32_RTC_CR);
>>>> +
>>>> + if ((isr & STM32_RTC_ISR_ALRAF) &&
>>>> + (cr & STM32_RTC_CR_ALRAIE)) {
>>>> + /* Alarm A flag - Alarm interrupt */
>>>> + events |= RTC_IRQF | RTC_AF;
>>>> + isr &= ~STM32_RTC_ISR_ALRAF;
>>>> + }
>>>> +
>>>> + /* Clear event irqflags, otherwise new events won't be received */
>>>> + stm32_rtc_writel(rtc, STM32_RTC_ISR, isr);
>>>> +
>>>> + spin_unlock_irqrestore(&rtc->lock, irqflags);
>>>> +
>>>> + if (events) {
>>>> + dev_info(&rtc->rtc_dev->dev, "Alarm occurred\n");
>>>> +
>>>> + /* Pass event to the kernel */
>>>> + rtc_update_irq(rtc->rtc_dev, 1, events);
>>>> + return IRQ_HANDLED;
>>>> + } else {
>>>> + return IRQ_NONE;
>>>> + }
>>>> +}
>>>> +
>>>> +/* Convert rtc_time structure from bin to bcd format */
>>>> +static void tm2bcd(struct rtc_time *tm)
>>>> +{
>>>> + tm->tm_sec = bin2bcd(tm->tm_sec);
>>>> + tm->tm_min = bin2bcd(tm->tm_min);
>>>> + tm->tm_hour = bin2bcd(tm->tm_hour);
>>>> +
>>>> + tm->tm_mday = bin2bcd(tm->tm_mday);
>>>> + tm->tm_mon = bin2bcd(tm->tm_mon + 1);
>>>> + tm->tm_year = bin2bcd(tm->tm_year - 100);
>>>> + /*
>>>> + * Number of days since Sunday
>>>> + * - on kernel side, 0=Sunday...6=Saturday
>>>> + * - on rtc side, 0=invalid,1=Monday...7=Sunday
>>>> + */
>>>> + tm->tm_wday = (!tm->tm_wday) ? 7 : tm->tm_wday;
>>>> +}
>>>> +
>>>> +/* Convert rtc_time structure from bcd to bin format */
>>>> +static void bcd2tm(struct rtc_time *tm)
>>>> +{
>>>> + tm->tm_sec = bcd2bin(tm->tm_sec);
>>>> + tm->tm_min = bcd2bin(tm->tm_min);
>>>> + tm->tm_hour = bcd2bin(tm->tm_hour);
>>>> +
>>>> + tm->tm_mday = bcd2bin(tm->tm_mday);
>>>> + tm->tm_mon = bcd2bin(tm->tm_mon) - 1;
>>>> + tm->tm_year = bcd2bin(tm->tm_year) + 100;
>>>> + /*
>>>> + * Number of days since Sunday
>>>> + * - on kernel side, 0=Sunday...6=Saturday
>>>> + * - on rtc side, 0=invalid,1=Monday...7=Sunday
>>>> + */
>>>> + tm->tm_wday %= 7;
>>>> +}
>>>> +
>>>> +static int stm32_rtc_read_time(struct device *dev, struct rtc_time *tm)
>>>> +{
>>>> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
>>>> + unsigned int tr, dr;
>>>> + unsigned long irqflags;
>>>> +
>>>> + spin_lock_irqsave(&rtc->lock, irqflags);
>>>> +
>>>> + /* Time and Date in BCD format */
>>>> + tr = stm32_rtc_readl(rtc, STM32_RTC_TR);
>>>> + dr = stm32_rtc_readl(rtc, STM32_RTC_DR);
>>>> +
>>>> + spin_unlock_irqrestore(&rtc->lock, irqflags);
>>>> +
>>>> + tm->tm_sec = (tr & STM32_RTC_TR_SEC) >> STM32_RTC_TR_SEC_SHIFT;
>>>> + tm->tm_min = (tr & STM32_RTC_TR_MIN) >> STM32_RTC_TR_MIN_SHIFT;
>>>> + tm->tm_hour = (tr & STM32_RTC_TR_HOUR) >> STM32_RTC_TR_HOUR_SHIFT;
>>>> +
>>>> + tm->tm_mday = (dr & STM32_RTC_DR_DATE) >> STM32_RTC_DR_DATE_SHIFT;
>>>> + tm->tm_mon = (dr & STM32_RTC_DR_MONTH) >> STM32_RTC_DR_MONTH_SHIFT;
>>>> + tm->tm_year = (dr & STM32_RTC_DR_YEAR) >> STM32_RTC_DR_YEAR_SHIFT;
>>>> + tm->tm_wday = (dr & STM32_RTC_DR_WDAY) >> STM32_RTC_DR_WDAY_SHIFT;
>>>> +
>>>> + /* We don't report tm_yday and tm_isdst */
>>>> +
>>>> + bcd2tm(tm);
>>>> +
>>>> + if (rtc_valid_tm(tm) < 0) {
>>>> + dev_err(dev, "%s: rtc_time is not valid.\n", __func__);
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int stm32_rtc_set_time(struct device *dev, struct rtc_time *tm)
>>>> +{
>>>> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
>>>> + unsigned int tr, dr;
>>>> + unsigned long irqflags;
>>>> + int ret = 0;
>>>> +
>>>> + if (rtc_valid_tm(tm) < 0) {
>>>> + dev_err(dev, "%s: rtc_time is not valid.\n", __func__);
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + tm2bcd(tm);
>>>> +
>>>> + /* Time in BCD format */
>>>> + tr = ((tm->tm_sec << STM32_RTC_TR_SEC_SHIFT) & STM32_RTC_TR_SEC) |
>>>> + ((tm->tm_min << STM32_RTC_TR_MIN_SHIFT) & STM32_RTC_TR_MIN) |
>>>> + ((tm->tm_hour << STM32_RTC_TR_HOUR_SHIFT) & STM32_RTC_TR_HOUR);
>>>> +
>>>> + /* Date in BCD format */
>>>> + dr = ((tm->tm_mday << STM32_RTC_DR_DATE_SHIFT) & STM32_RTC_DR_DATE)
>> |
>>>> + ((tm->tm_mon << STM32_RTC_DR_MONTH_SHIFT) & STM32_RTC_DR_MONTH)
>> |
>>>> + ((tm->tm_year << STM32_RTC_DR_YEAR_SHIFT) & STM32_RTC_DR_YEAR)
>> |
>>>> + ((tm->tm_wday << STM32_RTC_DR_WDAY_SHIFT) & STM32_RTC_DR_WDAY);
>>>> +
>>>> + spin_lock_irqsave(&rtc->lock, irqflags);
>>>> +
>>>> + stm32_rtc_wpr_unlock(rtc);
>>>> +
>>>> + ret = stm32_rtc_enter_init_mode(rtc);
>>>> + if (ret) {
>>>> + dev_err(dev, "Can't enter in init mode. Set time aborted.\n");
>>>> + goto end;
>>>> + }
>>>> +
>>>> + stm32_rtc_writel(rtc, STM32_RTC_TR, tr);
>>>> + stm32_rtc_writel(rtc, STM32_RTC_DR, dr);
>>>> +
>>>> + stm32_rtc_exit_init_mode(rtc);
>>>> +
>>>> + ret = stm32_rtc_wait_sync(rtc);
>>>> +end:
>>>> + stm32_rtc_wpr_lock(rtc);
>>>> +
>>>> + spin_unlock_irqrestore(&rtc->lock, irqflags);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int stm32_rtc_read_alarm(struct device *dev, struct rtc_wkalrm
>> *alrm)
>>>> +{
>>>> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
>>>> + struct rtc_time *tm = &alrm->time;
>>>> + unsigned int alrmar, cr, isr;
>>>> + unsigned long irqflags;
>>>> +
>>>> + spin_lock_irqsave(&rtc->lock, irqflags);
>>>> +
>>>> + alrmar = stm32_rtc_readl(rtc, STM32_RTC_ALRMAR);
>>>> + cr = stm32_rtc_readl(rtc, STM32_RTC_CR);
>>>> + isr = stm32_rtc_readl(rtc, STM32_RTC_ISR);
>>>> +
>>>> + spin_unlock_irqrestore(&rtc->lock, irqflags);
>>>> +
>>>> + if (alrmar & STM32_RTC_ALRMXR_DATE_MASK) {
>>>> + /*
>>>> + * Date/day don't care in Alarm comparison so alarm triggers
>>>> + * every day
>>>> + */
>>>> + tm->tm_mday = -1;
>>>> + tm->tm_wday = -1;
>>>> + } else {
>>>> + if (alrmar & STM32_RTC_ALRMXR_WDSEL) {
>>>> + /* Alarm is set to a day of week */
>>>> + tm->tm_mday = -1;
>>>> + tm->tm_wday = (alrmar & STM32_RTC_ALRMXR_WDAY) >>
>>>> + STM32_RTC_ALRMXR_WDAY_SHIFT;
>>>> + tm->tm_wday %= 7;
>>>> + } else {
>>>> + /* Alarm is set to a day of month */
>>>> + tm->tm_wday = -1;
>>>> + tm->tm_mday = (alrmar & STM32_RTC_ALRMXR_DATE) >>
>>>> + STM32_RTC_ALRMXR_DATE_SHIFT;
>>>> + }
>>>> + }
>>>> +
>>>> + if (alrmar & STM32_RTC_ALRMXR_HOUR_MASK) {
>>>> + /* Hours don't care in Alarm comparison */
>>>> + tm->tm_hour = -1;
>>>> + } else {
>>>> + tm->tm_hour = (alrmar & STM32_RTC_ALRMXR_HOUR) >>
>>>> + STM32_RTC_ALRMXR_HOUR_SHIFT;
>>>> + if (alrmar & STM32_RTC_ALRMXR_PM)
>>>> + tm->tm_hour += 12;
>>>> + }
>>>> +
>>>> + if (alrmar & STM32_RTC_ALRMXR_MIN_MASK) {
>>>> + /* Minutes don't care in Alarm comparison */
>>>> + tm->tm_min = -1;
>>>> + } else {
>>>> + tm->tm_min = (alrmar & STM32_RTC_ALRMXR_MIN) >>
>>>> + STM32_RTC_ALRMXR_MIN_SHIFT;
>>>> + }
>>>> +
>>>> + if (alrmar & STM32_RTC_ALRMXR_SEC_MASK) {
>>>> + /* Seconds don't care in Alarm comparison */
>>>> + tm->tm_sec = -1;
>>>> + } else {
>>>> + tm->tm_sec = (alrmar & STM32_RTC_ALRMXR_SEC) >>
>>>> + STM32_RTC_ALRMXR_SEC_SHIFT;
>>>> + }
>>>> +
>>>> + bcd2tm(tm);
>>>> +
>>>> + alrm->enabled = (cr & STM32_RTC_CR_ALRAE) ? 1 : 0;
>>>> + alrm->pending = (isr & STM32_RTC_ISR_ALRAF) ? 1 : 0;
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int stm32_rtc_alarm_irq_enable(struct device *dev, unsigned int
>> enabled)
>>>> +{
>>>> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
>>>> + unsigned long irqflags;
>>>> + unsigned int isr, cr;
>>>> +
>>>> + cr = stm32_rtc_readl(rtc, STM32_RTC_CR);
>>>
>>> Is the STM32_RTC_CR garanteed to be valid, i.e updated atomically? If not
>> this
>>> should probably be below the spinlock.
>> You're right.
>>>
>>>> +
>>>> + spin_lock_irqsave(&rtc->lock, irqflags);
>>>> +
>>>> + stm32_rtc_wpr_unlock(rtc);
>>>> +
>>>> + /* We expose Alarm A to the kernel */
>>>> + if (enabled)
>>>> + cr |= (STM32_RTC_CR_ALRAIE | STM32_RTC_CR_ALRAE);
>>>> + else
>>>> + cr &= ~(STM32_RTC_CR_ALRAIE | STM32_RTC_CR_ALRAE);
>>>> + stm32_rtc_writel(rtc, STM32_RTC_CR, cr);
>>>> +
>>>> + /* Clear event irqflags, otherwise new events won't be received */
>>>> + isr = stm32_rtc_readl(rtc, STM32_RTC_ISR);
>>>> + isr &= ~STM32_RTC_ISR_ALRAF;
>>>> + stm32_rtc_writel(rtc, STM32_RTC_ISR, isr);
>>>> +
>>>> + stm32_rtc_wpr_lock(rtc);
>>>> +
>>>> + spin_unlock_irqrestore(&rtc->lock, irqflags);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int stm32_rtc_set_alarm(struct device *dev, struct rtc_wkalrm
>> *alrm)
>>>> +{
>>>> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
>>>> + struct rtc_time *tm = &alrm->time;
>>>> + unsigned long irqflags;
>>>> + unsigned int cr, isr, alrmar;
>>>> + int ret = 0;
>>>> +
>>>> + if (rtc_valid_tm(tm)) {
>>>> + dev_err(dev, "Alarm time not valid.\n");
>>>> + return -EINVAL;
>>>> + }
>>>> +
>>>> + tm2bcd(tm);
>>>> +
>>>> + spin_lock_irqsave(&rtc->lock, irqflags);
>>>> +
>>>> + stm32_rtc_wpr_unlock(rtc);
>>>> +
>>>> + /* Disable Alarm */
>>>> + cr = stm32_rtc_readl(rtc, STM32_RTC_CR);
>>>> + cr &= ~STM32_RTC_CR_ALRAE;
>>>> + stm32_rtc_writel(rtc, STM32_RTC_CR, cr);
>>>> +
>>>> + /* Poll Alarm write flag to be sure that Alarm update is allowed */
>>>> + ret = readl_relaxed_poll_timeout_atomic(rtc->base + STM32_RTC_ISR,
>>>> + isr,
>>>> + (isr & STM32_RTC_ISR_ALRAWF),
>>>> + 10, 100);
>>>> +
>>>> + if (ret) {
>>>> + dev_err(dev, "Alarm update not allowed\n");
>>>> + goto end;
>>>> + }
>>>> +
>>>> + alrmar = 0;
>>>> +
>>>> + if (tm->tm_mday < 0 && tm->tm_wday < 0) {
>>>> + /*
>>>> + * Date/day don't care in Alarm comparison so alarm triggers
>>>> + * every day
>>>> + */
>>>> + alrmar |= STM32_RTC_ALRMXR_DATE_MASK;
>>>> + } else {
>>>> + if (tm->tm_mday > 0) {
>>>> + /* Date is selected (ignoring wday) */
>>>> + alrmar |= (tm->tm_mday << STM32_RTC_ALRMXR_DATE_SHIFT) &
>>>> + STM32_RTC_ALRMXR_DATE;
>>>> + } else {
>>>> + /* Day of week is selected */
>>>> + int wday = (tm->tm_wday == 0) ? 7 : tm->tm_wday;
>>>> +
>>>> + alrmar |= STM32_RTC_ALRMXR_WDSEL;
>>>> + alrmar |= (wday << STM32_RTC_ALRMXR_WDAY_SHIFT) &
>>>> + STM32_RTC_ALRMXR_WDAY;
>>>> + }
>>>> + }
>>>> +
>>>> + if (tm->tm_hour < 0) {
>>>> + /* Hours don't care in Alarm comparison */
>>>> + alrmar |= STM32_RTC_ALRMXR_HOUR_MASK;
>>>> + } else {
>>>> + /* 24-hour format */
>>>> + alrmar &= ~STM32_RTC_ALRMXR_PM;
>>>> + alrmar |= (tm->tm_hour << STM32_RTC_ALRMXR_HOUR_SHIFT) &
>>>> + STM32_RTC_ALRMXR_HOUR;
>>>> + }
>>>> +
>>>> + if (tm->tm_min < 0) {
>>>> + /* Minutes don't care in Alarm comparison */
>>>> + alrmar |= STM32_RTC_ALRMXR_MIN_MASK;
>>>> + } else {
>>>> + alrmar |= (tm->tm_min << STM32_RTC_ALRMXR_MIN_SHIFT) &
>>>> + STM32_RTC_ALRMXR_MIN;
>>>> + }
>>>> +
>>>> + if (tm->tm_sec < 0) {
>>>> + /* Seconds don't care in Alarm comparison */
>>>> + alrmar |= STM32_RTC_ALRMXR_SEC_MASK;
>>>> + } else {
>>>> + alrmar |= (tm->tm_sec << STM32_RTC_ALRMXR_SEC_SHIFT) &
>>>> + STM32_RTC_ALRMXR_SEC;
>>>> + }
>>>> +
>>>> + /* Write to Alarm register */
>>>> + stm32_rtc_writel(rtc, STM32_RTC_ALRMAR, alrmar);
>>>> +
>>>> + if (alrm->enabled)
>>>> + stm32_rtc_alarm_irq_enable(dev, 1);
>>>> + else
>>>> + stm32_rtc_alarm_irq_enable(dev, 0);
>>>> +
>>>> +end:
>>>> + stm32_rtc_wpr_lock(rtc);
>>>> +
>>>> + spin_unlock_irqrestore(&rtc->lock, irqflags);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static const struct rtc_class_ops stm32_rtc_ops = {
>>>> + .read_time = stm32_rtc_read_time,
>>>> + .set_time = stm32_rtc_set_time,
>>>> + .read_alarm = stm32_rtc_read_alarm,
>>>> + .set_alarm = stm32_rtc_set_alarm,
>>>> + .alarm_irq_enable = stm32_rtc_alarm_irq_enable,
>>>> +};
>>>> +
>>>> +#ifdef CONFIG_OF
>>>> +static const struct of_device_id stm32_rtc_of_match[] = {
>>>> + { .compatible = "st,stm32-rtc" },
>>>> + {}
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, stm32_rtc_of_match);
>>>> +#endif
>>>> +
>>>> +static int stm32_rtc_init(struct platform_device *pdev,
>>>> + struct stm32_rtc *rtc)
>>>> +{
>>>> + unsigned int prer, pred_a, pred_s, pred_a_max, pred_s_max, cr;
>>>> + unsigned int rate;
>>>> + unsigned long irqflags;
>>>> + int ret = 0;
>>>> +
>>>> + rate = clk_get_rate(rtc->ck_rtc);
>>>> +
>>>> + /* Find prediv_a and prediv_s to obtain the 1Hz calendar clock */
>>>> + pred_a_max = STM32_RTC_PRER_PRED_A >> STM32_RTC_PRER_PRED_A_SHIFT;
>>>> + pred_s_max = STM32_RTC_PRER_PRED_S >> STM32_RTC_PRER_PRED_S_SHIFT;
>>>> +
>>>> + for (pred_a = pred_a_max; pred_a >= 0; pred_a--) {
>>>> + pred_s = (rate / (pred_a + 1)) - 1;
>>>> +
>>>> + if (((pred_s + 1) * (pred_a + 1)) == rate)
>>>> + break;
>>>> + }
>>>> +
>>>> + /*
>>>> + * Can't find a 1Hz, so give priority to RTC power consumption
>>>> + * by choosing the higher possible value for prediv_a
>>>> + */
>>>> + if ((pred_s > pred_s_max) || (pred_a > pred_a_max)) {
>>>> + pred_a = pred_a_max;
>>>> + pred_s = (rate / (pred_a + 1)) - 1;
>>>> +
>>>> + dev_warn(&pdev->dev, "ck_rtc is %s\n",
>>>> + (rate - ((pred_a + 1) * (pred_s + 1)) < 0) ?
>>>> + "fast" : "slow");
>>>> + }
>>>> +
>>>> + spin_lock_irqsave(&rtc->lock, irqflags);
>>>> +
>>>> + stm32_rtc_wpr_unlock(rtc);
>>>> +
>>>> + ret = stm32_rtc_enter_init_mode(rtc);
>>>> + if (ret) {
>>>> + dev_err(&pdev->dev,
>>>> + "Can't enter in init mode. Prescaler config failed.\n");
>>>> + goto end;
>>>> + }
>>>> +
>>>> + prer = (pred_s << STM32_RTC_PRER_PRED_S_SHIFT) &
>> STM32_RTC_PRER_PRED_S;
>>>> + stm32_rtc_writel(rtc, STM32_RTC_PRER, prer);
>>>> + prer |= (pred_a << STM32_RTC_PRER_PRED_A_SHIFT) &
>> STM32_RTC_PRER_PRED_A;
>>>> + stm32_rtc_writel(rtc, STM32_RTC_PRER, prer);
>>>> +
>>>> + /* Force 24h time format */
>>>> + cr = stm32_rtc_readl(rtc, STM32_RTC_CR);
>>>> + cr &= ~STM32_RTC_CR_FMT;
>>>> + stm32_rtc_writel(rtc, STM32_RTC_CR, cr);
>>>> +
>>>> + stm32_rtc_exit_init_mode(rtc);
>>>> +
>>>> + ret = stm32_rtc_wait_sync(rtc);
>>>> +
>>>> + if (stm32_rtc_readl(rtc, STM32_RTC_ISR) & STM32_RTC_ISR_INITS)
>>>> + dev_warn(&pdev->dev, "Date/Time must be initialized\n");
>>>> +end:
>>>> + stm32_rtc_wpr_lock(rtc);
>>>> +
>>>> + spin_unlock_irqrestore(&rtc->lock, irqflags);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int stm32_rtc_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct stm32_rtc *rtc;
>>>> + struct resource *res;
>>>> + int ret;
>>>> +
>>>> + rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
>>>> + if (!rtc)
>>>> + return -ENOMEM;
>>>> +
>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>
>>> The value of 'res' should be checked before using it.
>> res is checked in devm_ioremap_resource just below :
>> if (!res || resource_type(res) != IORESOURCE_MEM) {
>> dev_err(dev, "invalid resource\n");
>> return IOMEM_ERR_PTR(-EINVAL);
>> }
>> That's why it is not checked here.
>>>
>>>> + rtc->base = devm_ioremap_resource(&pdev->dev, res);
>>>> + if (IS_ERR(rtc->base))
>>>> + return PTR_ERR(rtc->base);
>>>> +
>>>> + dbp = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
>> "st,syscfg");
>>>> + if (IS_ERR(dbp)) {
>>>> + dev_err(&pdev->dev, "no st,syscfg\n");
>>>> + return PTR_ERR(dbp);
>>>> + }
>>>> +
>>>> + spin_lock_init(&rtc->lock);
>>>> +
>>>> + rtc->ck_rtc = devm_clk_get(&pdev->dev, "ck_rtc");
>>>> + if (IS_ERR(rtc->ck_rtc)) {
>>>> + dev_err(&pdev->dev, "no ck_rtc clock");
>>>> + return PTR_ERR(rtc->ck_rtc);
>>>> + }
>>>> +
>>>> + ret = clk_prepare_enable(rtc->ck_rtc);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + if (dbp)
>>>> + regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, PWR_CR_DBP);
>>>
>>> The code above exits if there is a problem with the dbp, there is no point
>> in
>>> checking again.
>> You're right.
>>>
>>>> +
>>>> + ret = stm32_rtc_init(pdev, rtc);
>>>> + if (ret)
>>>> + goto err;
>>>> +
>>>> + rtc->irq_alarm = platform_get_irq_byname(pdev, "alarm");
>>>> + if (rtc->irq_alarm <= 0) {
>>>> + dev_err(&pdev->dev, "no alarm irq\n");
>>>> + ret = -ENOENT;
>>>> + goto err;
>>>> + }
>>>> +
>>>> + platform_set_drvdata(pdev, rtc);
>>>> +
>>>> + device_init_wakeup(&pdev->dev, true);
>>>
>>> What happens if device_init_wakeup() returns an error?
>> It means that RTC won't be able to wake up the board with RTC alarm. I can
>> add a warning for the user in this case ?
>
> Not really sure - it really depends on the kind of system will use this.
> For some not being able to wake up the board might a minor problem while
> for others a reason to fail the probing.
>
> Do we need a new binging for this, i.e one that would indicate this RTC can (and
> should) be able to wake up the board and fail driver probing if this can't be
> done?
>
> I'll let Alessandro and Alexander be the judge of that.
>
> Thanks,
> Mathieu
>
Ok, I wait for Alessandro and Alexandre advice to send a V2.
Thanks,
Amelie
>>>
>>>> +
>>>> + rtc->rtc_dev = devm_rtc_device_register(&pdev->dev, pdev->name,
>>>> + &stm32_rtc_ops, THIS_MODULE);
>>>> + if (IS_ERR(rtc->rtc_dev)) {
>>>> + ret = PTR_ERR(rtc->rtc_dev);
>>>> + dev_err(&pdev->dev, "rtc device registration failed, err=%d\n",
>>>> + ret);
>>>> + goto err;
>>>> + }
>>>> +
>>>> + /* Handle RTC alarm interrupts */
>>>> + ret = devm_request_irq(&pdev->dev, rtc->irq_alarm,
>>>> + stm32_rtc_alarm_irq, IRQF_TRIGGER_RISING,
>>>> + dev_name(&rtc->rtc_dev->dev), rtc);
>>>> + if (ret) {
>>>> + dev_err(&pdev->dev, "IRQ%d (alarm interrupt) already claimed\n",
>>>> + rtc->irq_alarm);
>>>> + goto err;
>>>> + }
>>>> +
>>>> + return 0;
>>>> +err:
>>>> + clk_disable_unprepare(rtc->ck_rtc);
>>>> +
>>>> + if (dbp)
>>>> + regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
>>>
>>> Same comment as above.
>> OK.
>>>
>>>> +
>>>> + device_init_wakeup(&pdev->dev, false);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static int __exit stm32_rtc_remove(struct platform_device *pdev)
>>>> +{
>>>> + struct stm32_rtc *rtc = platform_get_drvdata(pdev);
>>>> + unsigned int cr;
>>>> +
>>>> + /* Disable interrupts */
>>>> + stm32_rtc_wpr_unlock(rtc);
>>>> + cr = stm32_rtc_readl(rtc, STM32_RTC_CR);
>>>> + cr &= ~STM32_RTC_CR_ALRAIE;
>>>> + stm32_rtc_writel(rtc, STM32_RTC_CR, cr);
>>>> + stm32_rtc_wpr_lock(rtc);
>>>> +
>>>> + clk_disable_unprepare(rtc->ck_rtc);
>>>> +
>>>> + /* Enable backup domain write protection */
>>>> + if (dbp)
>>>> + regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
>>>> +
>>>> + device_init_wakeup(&pdev->dev, false);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +#ifdef CONFIG_PM_SLEEP
>>>> +static int stm32_rtc_suspend(struct device *dev)
>>>> +{
>>>> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
>>>> +
>>>> + if (device_may_wakeup(dev))
>>>> + return enable_irq_wake(rtc->irq_alarm);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int stm32_rtc_resume(struct device *dev)
>>>> +{
>>>> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
>>>> + int ret = 0;
>>>> +
>>>> + ret = stm32_rtc_wait_sync(rtc);
>>>> + if (ret < 0)
>>>> + return ret;
>>>> +
>>>> + if (device_may_wakeup(dev))
>>>> + return disable_irq_wake(rtc->irq_alarm);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +#endif
>>>> +
>>>> +static SIMPLE_DEV_PM_OPS(stm32_rtc_pm_ops,
>>>> + stm32_rtc_suspend, stm32_rtc_resume);
>>>> +
>>>> +static struct platform_driver stm32_rtc_driver = {
>>>> + .probe = stm32_rtc_probe,
>>>> + .remove = stm32_rtc_remove,
>>>> + .driver = {
>>>> + .name = DRIVER_NAME,
>>>> + .pm = &stm32_rtc_pm_ops,
>>>> + .of_match_table = stm32_rtc_of_match,
>>>> + },
>>>> +};
>>>> +
>>>> +module_platform_driver(stm32_rtc_driver);
>>>> +
>>>> +MODULE_ALIAS("platform:" DRIVER_NAME);
>>>> +MODULE_AUTHOR("Amelie Delaunay <amelie.delaunay-qxv4g6HH51o@public.gmane.org>");
>>>> +MODULE_DESCRIPTION("STMicroelectronics STM32 Real Time Clock driver");
>>>> +MODULE_LICENSE("GPL v2");
>>>> --
>>>> 1.9.1
>>>>
>>
>> Best regards,
>> Amelie
>>
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH 0/2] i2c: sh_mobile: fallback enhancements
From: Simon Horman @ 2016-12-07 10:31 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Simon Horman
Hi,
this short series aims to improve the fallback compatibility strings
for the i2c-sh_mobile driver.
Simon Horman (2):
i2c: sh_mobile: List rmobile fallback compatibility last
i2c: sh_mobile: Add per-Generation fallback bindings
Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt | 17 ++++++++++++++---
drivers/i2c/busses/i2c-sh_mobile.c | 4 +++-
2 files changed, 17 insertions(+), 4 deletions(-)
--
2.7.0.rc3.207.g0ac5344
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] i2c: sh_mobile: List rmobile fallback compatibility last
From: Simon Horman @ 2016-12-07 10:39 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c, linux-renesas-soc, devicetree,
Simon Horman
In-Reply-To: <1481106689-22312-1-git-send-email-horms+renesas@verge.net.au>
Improve readability by listing the rmobile fallback compatibility string
after the more-specific compatibility strings they provide a fallback for.
This does not effect run-time behaviour as it is the order in the DTB that
determines which compatibility string is used.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
drivers/i2c/busses/i2c-sh_mobile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 192f36f00e4d..6335ad35902d 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -827,7 +827,6 @@ static const struct sh_mobile_dt_config r8a7740_dt_config = {
};
static const struct of_device_id sh_mobile_i2c_dt_ids[] = {
- { .compatible = "renesas,rmobile-iic", .data = &default_dt_config },
{ .compatible = "renesas,iic-r8a73a4", .data = &fast_clock_dt_config },
{ .compatible = "renesas,iic-r8a7740", .data = &r8a7740_dt_config },
{ .compatible = "renesas,iic-r8a7790", .data = &fast_clock_dt_config },
@@ -837,6 +836,7 @@ static const struct of_device_id sh_mobile_i2c_dt_ids[] = {
{ .compatible = "renesas,iic-r8a7794", .data = &fast_clock_dt_config },
{ .compatible = "renesas,iic-r8a7795", .data = &fast_clock_dt_config },
{ .compatible = "renesas,iic-sh73a0", .data = &fast_clock_dt_config },
+ { .compatible = "renesas,rmobile-iic", .data = &default_dt_config },
{},
};
MODULE_DEVICE_TABLE(of, sh_mobile_i2c_dt_ids);
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 2/2] i2c: sh_mobile: Add per-Generation fallback bindings
From: Simon Horman @ 2016-12-07 10:39 UTC (permalink / raw)
To: Wolfram Sang
Cc: Magnus Damm, linux-i2c, linux-renesas-soc, devicetree,
Simon Horman
In-Reply-To: <1481106689-22312-1-git-send-email-horms+renesas@verge.net.au>
Add per-Generation fallback bindings for R-Car SoCs.
This is in keeping with the compatibility string scheme is being adopted
for drivers for Renesas SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt | 17 ++++++++++++++---
drivers/i2c/busses/i2c-sh_mobile.c | 2 ++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
index 214f94c25d37..7716acc55dec 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
@@ -1,8 +1,7 @@
Device tree configuration for Renesas IIC (sh_mobile) driver
Required properties:
-- compatible : "renesas,iic-<soctype>". "renesas,rmobile-iic" as fallback
- Examples with soctypes are:
+- compatible :
- "renesas,iic-r8a73a4" (R-Mobile APE6)
- "renesas,iic-r8a7740" (R-Mobile A1)
- "renesas,iic-r8a7790" (R-Car H2)
@@ -12,6 +11,17 @@ Required properties:
- "renesas,iic-r8a7794" (R-Car E2)
- "renesas,iic-r8a7795" (R-Car H3)
- "renesas,iic-sh73a0" (SH-Mobile AG5)
+ - "renesas,rcar-gen2-iic" (generic R-Car Gen2 compatible device)
+ - "renesas,rcar-gen3-iic" (generic R-Car Gen3 compatible device)
+ - "renesas,rmobile-iic" (generic device)
+
+ When compatible with a generic R-Car version, nodes
+ must list the SoC-specific version corresponding to
+ the platform first followed by the generic R-Car
+ version.
+
+ renesas,rmobile-iic must always follow.
+
- reg : address start and address range size of device
- interrupts : interrupt of device
- clocks : clock for device
@@ -31,7 +41,8 @@ Pinctrl properties might be needed, too. See there.
Example:
iic0: i2c@e6500000 {
- compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6500000 0 0x425>;
interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7790_CLK_IIC0>;
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index 6335ad35902d..3d9ebe6e5716 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -834,7 +834,9 @@ static const struct of_device_id sh_mobile_i2c_dt_ids[] = {
{ .compatible = "renesas,iic-r8a7792", .data = &fast_clock_dt_config },
{ .compatible = "renesas,iic-r8a7793", .data = &fast_clock_dt_config },
{ .compatible = "renesas,iic-r8a7794", .data = &fast_clock_dt_config },
+ { .compatible = "renesas,rcar-gen2-iic", .data = &fast_clock_dt_config },
{ .compatible = "renesas,iic-r8a7795", .data = &fast_clock_dt_config },
+ { .compatible = "renesas,rcar-gen3-iic", .data = &fast_clock_dt_config },
{ .compatible = "renesas,iic-sh73a0", .data = &fast_clock_dt_config },
{ .compatible = "renesas,rmobile-iic", .data = &default_dt_config },
{},
--
2.7.0.rc3.207.g0ac5344
^ 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