* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Olof Johansson @ 2014-01-18 0:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D9C88C.3020508@ti.com>
On Fri, Jan 17, 2014 at 4:19 PM, Nishanth Menon <nm@ti.com> wrote:
> On 01/17/2014 06:12 PM, Olof Johansson wrote:
>> On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon <nm@ti.com> wrote:
>>
>>> clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y:
>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4
>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h
>>> 3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR
>>> 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec
>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK
>>> 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz
>>> 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk
>>> 8: crane: No Image built - Missing platform support?:
>>> 9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu
>>> * DRA7 not enabled?
>>> 10: ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs
>>> 11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ
>>> * known issue (https://patchwork.kernel.org/patch/3084521/)
>>> 12: sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7
>>> 13: sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe
>>> 14: sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm
>>> 15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN
>>> TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4
>>
>>
>> I have a hard time believing the above; A8/A9 boards are not bootable
>> with CONFIG_LPAE=y...
>
> You are right! Drat!! I had CONFIG_LPAE=y in my script, not
> CONFIG_ARM_LPAE=y! Grrr...
>
> Retest in a around 30 mins..
It's not a huge concern though; it's unlikely that LPAE makes a
functional difference on this patch series. It's still useful to catch
warnings, etc (most likely printk formats and the like).
-Olof
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Nishanth Menon @ 2014-01-18 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMiniMi9xG6ByL0pQE7wzpM82JB40cPvfJcSYkXPs3PrDw@mail.gmail.com>
On 01/17/2014 06:12 PM, Olof Johansson wrote:
> On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon <nm@ti.com> wrote:
>
>> clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y:
>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4
>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h
>> 3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR
>> 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec
>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK
>> 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz
>> 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk
>> 8: crane: No Image built - Missing platform support?:
>> 9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu
>> * DRA7 not enabled?
>> 10: ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs
>> 11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ
>> * known issue (https://patchwork.kernel.org/patch/3084521/)
>> 12: sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7
>> 13: sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe
>> 14: sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm
>> 15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN
>> TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4
>
>
> I have a hard time believing the above; A8/A9 boards are not bootable
> with CONFIG_LPAE=y...
You are right! Drat!! I had CONFIG_LPAE=y in my script, not
CONFIG_ARM_LPAE=y! Grrr...
Retest in a around 30 mins..
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Olof Johansson @ 2014-01-18 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D9C484.6000404@ti.com>
On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon <nm@ti.com> wrote:
> clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y:
> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4
> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h
> 3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR
> 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec
> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK
> 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz
> 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk
> 8: crane: No Image built - Missing platform support?:
> 9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu
> * DRA7 not enabled?
> 10: ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs
> 11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ
> * known issue (https://patchwork.kernel.org/patch/3084521/)
> 12: sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7
> 13: sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe
> 14: sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm
> 15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN
> TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4
I have a hard time believing the above; A8/A9 boards are not bootable
with CONFIG_LPAE=y...
-Olof
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Nishanth Menon @ 2014-01-18 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117205832.4167.95162@quantum>
On 01/17/2014 02:58 PM, Mike Turquette wrote:
> Quoting Tero Kristo (2014-01-17 10:11:06)
>> On 01/17/2014 07:53 PM, Tony Lindgren wrote:
>>> * Kevin Hilman <khilman@linaro.org> [140117 09:48]:
>>>> Mike Turquette <mturquette@linaro.org> writes:
>>>>
>>>> [...]
>>>>
>>>>> I took Tony's advice and fast-forwarded clk-next to -rc7 and applied
>>>>> Tero's series. This includes the AM3517 bits now. I've pushed this
>>>>> branch to clk-next-omap (force update) on my Linaro mirror. Can you do a
>>>>> final sanity test before I merge this into clk-next?
>>
>> I think you accidentally merged wrong branch to clk-next-omap with the
>> latest refresh. This is one is missing the build-fixes now, when it
>> earlier had those in.
>>
>> The correct branch to merge was 3.13-rc7-dt-clks-v13-build-fixes.
>>
>> This also causes the build failure below for omap1.
>
> You are right. I broke the OMAPs. I force updated clk-next-omap (and
> clk-next) with the correct branch this time.
Build tests: omap1_defconfig:
clk-next-6a0cad9: builds fine
clk-next-6a0cad9 + next-20140117: http://slexy.org/view/s2HgtvUtAl
disabling CONFIG_BT, builds fine
Boot tests: clk-next-6a0cad9, clk-next-6a0cad9 + next-20140117 : No
regressions seen
Detailed Boot logs:
clk-next-6a0cad9 omap2plus_defconfig:
1: am335x-evm: Boot PASS: http://slexy.org/raw/s21idEk2IZ
2: am335x-sk: Boot PASS: http://slexy.org/raw/s21Q4w8gWT
3: am3517-evm: Boot PASS: http://slexy.org/raw/s21dT7y2CA
4: am37x-evm: Boot PASS: http://slexy.org/raw/s2VFaOtuDP
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20L0DBt1d
6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20gKsdH3A
7: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ZXTJswqY
8: crane: No Image built - Missing platform support?:
9: dra7: Boot PASS: http://slexy.org/raw/s2XZfjQz67
10: ldp: No Image built - Missing platform support?:
11: panda-es: Boot PASS: http://slexy.org/raw/s2ESRQgBbc
12: sdp2430: No Image built - Missing platform support?:
13: sdp3430: Boot PASS: http://slexy.org/raw/s2YsAO3ZPJ
14: sdp4430: Boot PASS: http://slexy.org/raw/s2MxxggHkh
15: uevm: Boot PASS: http://slexy.org/raw/s2wJT0B7wf
TOTAL = 15 boards, Booted Boards = 12, No Boot boards = 3
clk-next-6a0cad9 multi_v7_defconfig:
1: am335x-evm: Boot FAIL: http://slexy.org/raw/s21AXBDbM9
* regulator/mmc missing here
2: am335x-sk: Boot FAIL: http://slexy.org/raw/s21pQPhupJ
* regulator/mmc missing here
3: am3517-evm: Boot PASS: http://slexy.org/raw/s21iM7TEiQ
4: am37x-evm: Boot PASS: http://slexy.org/raw/s2pBD6nplU
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2X9mnCKhT
6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s21CjzZtZ6
7: beaglebone-black: Boot PASS: http://slexy.org/raw/s2vCfnss8N
8: crane: No Image built - Missing platform support?:
9: dra7: Boot FAIL: http://slexy.org/raw/s21Xn4t22A
* DRA7 not enabled?
10: ldp: No Image built - Missing platform support?:
11: panda-es: Boot PASS: http://slexy.org/raw/s21ZoijL9i
12: sdp2430: No Image built - Missing platform support?:
13: sdp3430: Boot PASS: http://slexy.org/raw/s21rdIfh7S
14: sdp4430: Boot PASS: http://slexy.org/raw/s21HXFj9cw
15: uevm: Boot FAIL: http://slexy.org/raw/s21m26VdbI
* regulator/mmc missing here
TOTAL = 15 boards, Booted Boards = 8, No Boot boards = 7
clk-next-6a0cad9 multi_v7_defconfig+CONFIG_LPAE=y:
1: am335x-evm: Boot FAIL: http://slexy.org/raw/s21GIuprIx
* regulator/mmc missing here
2: am335x-sk: Boot FAIL: http://slexy.org/raw/s20Vy6K9Rg
* regulator/mmc missing here
3: am3517-evm: Boot PASS: http://slexy.org/raw/s20jXaoTYq
4: am37x-evm: Boot PASS: http://slexy.org/raw/s20bk4uHcb
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2gVGjYMXz
6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s26D0F2N1t
7: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ThmugNzC
8: crane: No Image built - Missing platform support?:
9: dra7: Boot FAIL: http://slexy.org/raw/s21HdQFchd
* DRA7 not enabled?
10: ldp: No Image built - Missing platform support?:
11: panda-es: Boot PASS: http://slexy.org/raw/s2042Y9Pyb
12: sdp2430: No Image built - Missing platform support?:
13: sdp3430: Boot PASS: http://slexy.org/raw/s2NCg8nLki
14: sdp4430: Boot PASS: http://slexy.org/raw/s25GxRkWcj
15: uevm: Boot FAIL: http://slexy.org/raw/s2Q7xBYM3a
* regulator/mmc missing here
TOTAL = 15 boards, Booted Boards = 8, No Boot boards = 7
clk-next-6a0cad9 + next-20140117 omap2plus_defconfig:
1: am335x-evm: Boot PASS: http://slexy.org/raw/s2ll3LdMN2
2: am335x-sk: Boot PASS: http://slexy.org/raw/s2jyAF2Och
3: am3517-evm: Boot PASS: http://slexy.org/raw/s20nPsCcUS
4: am37x-evm: Boot PASS: http://slexy.org/raw/s2Rn7Vqh8x
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2frIhnu6Y
6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s2GNee8kHF
7: beaglebone-black: Boot PASS: http://slexy.org/raw/s2G7fD4rGD
8: crane: No Image built - Missing platform support?: (pending
merge from Benoit)
9: dra7: Boot PASS: http://slexy.org/raw/s21W2zLl5q
10: ldp: Boot FAIL: http://slexy.org/raw/s21518Tibq
* intermittent failures seen previously as well -> debug pending
11: panda-es: Boot PASS: http://slexy.org/raw/s20WddZMVp
12: sdp2430: Boot PASS: http://slexy.org/raw/s2cVr3BLLi
13: sdp3430: Boot PASS: http://slexy.org/raw/s21h9oDSCv
14: sdp4430: Boot PASS: http://slexy.org/raw/s21PWBCUKn
15: uevm: Boot PASS: http://slexy.org/raw/s2OxDQtC9E
TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2
clk-next-6a0cad9 + next-20140117 multi_v7_defconfig:
1: am335x-evm: Boot PASS: http://slexy.org/raw/s20MpjXQ71
2: am335x-sk: Boot PASS: http://slexy.org/raw/s2T0vnX8s7
3: am3517-evm: Boot PASS: http://slexy.org/raw/s2hvsW2oVi
4: am37x-evm: Boot PASS: http://slexy.org/raw/s2Li1DqaeQ
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2MHh0c19C
6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s21RnOxxUk
7: beaglebone-black: Boot PASS: http://slexy.org/raw/s2qaKF0lqp
8: crane: No Image built - Missing platform support?:
9: dra7: Boot FAIL: http://slexy.org/raw/s203u2hQ1m
* DRA7 not enabled?
10: ldp: Boot PASS: http://slexy.org/raw/s2ug8MyzzE
11: panda-es: Boot FAIL: http://slexy.org/raw/s2NVPvwb2I
* known issue (https://patchwork.kernel.org/patch/3084521/)
12: sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7
13: sdp3430: Boot PASS: http://slexy.org/raw/s28vswaDnc
14: sdp4430: Boot PASS: http://slexy.org/raw/s21wk2lqiC
15: uevm: Boot PASS: http://slexy.org/raw/s21soF15Dy
TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4
clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y:
1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4
2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h
3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR
4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK
6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz
7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk
8: crane: No Image built - Missing platform support?:
9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu
* DRA7 not enabled?
10: ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs
11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ
* known issue (https://patchwork.kernel.org/patch/3084521/)
12: sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7
13: sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe
14: sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm
15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN
TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: Anson.Huang at freescale.com @ 2014-01-17 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYOgJDMO-xF9GC4Xh7+t6FDk6DwJ0iYX17Hh6LvqSjVa4Q@mail.gmail.com>
Hi, Tobias
I will debug it next week and feedback to you. Thanks.
Sent from Anson's iPhone
> ? 2014?1?18??7:42?"John Tobias" <john.tobias.ph@gmail.com> ???
>
> Hi Anson,
>
> My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
> Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
> called in imx6sl_enter_wait.
>
> [ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from [<80045650>]
> (deactivate_task+0x30/0x34)
> [ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
> [<8050ac88>] (__schedule+0x318/0x58c)
> [ 288.185848] [<8050a970>] (__schedule+0x0/0x58c) from [<8050af34>]
> (schedule+0x38/0x88)
> [ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
> (schedule_preempt_disabled+0x10/0x14)
> [ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14) from
> [<8050bcd4>] (mutex_lock_nested+0x16c/0x334)
> [ 288.215850] [<8050bb68>] (mutex_lock_nested+0x0/0x334) from
> [<8034763c>] (clk_prepare_lock+0x90/0x104)
> [ 288.226041] [<803475ac>] (clk_prepare_lock+0x0/0x104) from
> [<80349254>] (clk_set_rate+0x1c/0xbc)
> [ 288.235535] r6:806fd360 r5:00000000 r4:bf817f80 r3:80713d80
> [ 288.242679] [<80349238>] (clk_set_rate+0x0/0xbc) from [<8001e574>]
> (imx6sl_set_wait_clk+0x28/0x70)
> [ 288.252354] r5:00000043 r4:00000001
> [ 288.256585] [<8001e54c>] (imx6sl_set_wait_clk+0x0/0x70) from
> [<8001def4>] (imx6sl_enter_wait+0x24/0x2c)
> [ 288.266684] r5:00000043 r4:00000001
> [ 288.270949] [<8001ded0>] (imx6sl_enter_wait+0x0/0x2c) from
> [<80317608>] (cpuidle_enter_state+0x44/0xfc)
> [ 288.281051] r4:13bf2645 r3:8001ded0
> [ 288.285682] [<803175c4>] (cpuidle_enter_state+0x0/0xfc) from
> [<803177bc>] (cpuidle_idle_call+0xfc/0x150)
> [ 288.295871] r8:806e00d8 r7:00000001 r6:00000000 r5:80c58034 r4:806fd360
> [ 288.304428] [<803176c0>] (cpuidle_idle_call+0x0/0x150) from
> [<8000fa68>] (arch_cpu_idle+0x10/0x44)
> [ 288.314108] r9:8070970a r8:8070970a r7:806d2000 r6:806da0dc r5:806d2000
> r4:806d2000
> [ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from [<800590f4>]
> (cpu_startup_entry+0xe0/0x120)
> [ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
> [<80503c8c>] (rest_init+0xcc/0xdc)
> [ 288.342810] r7:ffffffff r3:00000000
> [ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from [<806a2b00>]
> (start_kernel+0x348/0x354)
> [ 288.356099] r6:806da040 r5:806da040 r4:806da150
> [ 288.361972] [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
> (0x80008070)
>
>
> Regards,
>
> john
>
>
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: John Tobias @ 2014-01-17 23:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi Anson,
My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
called in imx6sl_enter_wait.
[ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from [<80045650>]
(deactivate_task+0x30/0x34)
[ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
[<8050ac88>] (__schedule+0x318/0x58c)
[ 288.185848] [<8050a970>] (__schedule+0x0/0x58c) from [<8050af34>]
(schedule+0x38/0x88)
[ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
(schedule_preempt_disabled+0x10/0x14)
[ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14) from
[<8050bcd4>] (mutex_lock_nested+0x16c/0x334)
[ 288.215850] [<8050bb68>] (mutex_lock_nested+0x0/0x334) from
[<8034763c>] (clk_prepare_lock+0x90/0x104)
[ 288.226041] [<803475ac>] (clk_prepare_lock+0x0/0x104) from
[<80349254>] (clk_set_rate+0x1c/0xbc)
[ 288.235535] r6:806fd360 r5:00000000 r4:bf817f80 r3:80713d80
[ 288.242679] [<80349238>] (clk_set_rate+0x0/0xbc) from [<8001e574>]
(imx6sl_set_wait_clk+0x28/0x70)
[ 288.252354] r5:00000043 r4:00000001
[ 288.256585] [<8001e54c>] (imx6sl_set_wait_clk+0x0/0x70) from
[<8001def4>] (imx6sl_enter_wait+0x24/0x2c)
[ 288.266684] r5:00000043 r4:00000001
[ 288.270949] [<8001ded0>] (imx6sl_enter_wait+0x0/0x2c) from
[<80317608>] (cpuidle_enter_state+0x44/0xfc)
[ 288.281051] r4:13bf2645 r3:8001ded0
[ 288.285682] [<803175c4>] (cpuidle_enter_state+0x0/0xfc) from
[<803177bc>] (cpuidle_idle_call+0xfc/0x150)
[ 288.295871] r8:806e00d8 r7:00000001 r6:00000000 r5:80c58034 r4:806fd360
[ 288.304428] [<803176c0>] (cpuidle_idle_call+0x0/0x150) from
[<8000fa68>] (arch_cpu_idle+0x10/0x44)
[ 288.314108] r9:8070970a r8:8070970a r7:806d2000 r6:806da0dc r5:806d2000
r4:806d2000
[ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from [<800590f4>]
(cpu_startup_entry+0xe0/0x120)
[ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
[<80503c8c>] (rest_init+0xcc/0xdc)
[ 288.342810] r7:ffffffff r3:00000000
[ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from [<806a2b00>]
(start_kernel+0x348/0x354)
[ 288.356099] r6:806da040 r5:806da040 r4:806da150
[ 288.361972] [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
(0x80008070)
Regards,
john
^ permalink raw reply
* [PATCH] pinctrl: capri: add dependency on OF
From: Stephen Warren @ 2014-01-17 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ9OBkKaLuQbc1oz0uPePBtqttGyOwV02iFWZ+CT1gwnw@mail.gmail.com>
On 01/17/2014 04:13 PM, Linus Walleij wrote:
> On Sat, Jan 18, 2014 at 12:12 AM, Linus Walleij
> <linus.walleij@linaro.org> wrote:
>> On Fri, Jan 17, 2014 at 8:51 PM, Sherman Yin <syin@broadcom.com> wrote:
>>
>>> Thanks for the fix, Linus. While we're visiting this config, should we add
>>> "depends on MACH_BCM_MOBILE" as well?
>>
>> No, it's nice to get the compile coverage.
>
> But maybe you can experiment with that special option that only
> turns on the driver on other platforms to do compile test.
a/k/a
depends on XXX || COMPILE_TEST
^ permalink raw reply
* [PATCH] pinctrl: capri: add dependency on OF
From: Linus Walleij @ 2014-01-17 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYVLF+CNcAc8=MiSRJJMBWy3LriDw271Bx=gjuuzdOatA@mail.gmail.com>
On Sat, Jan 18, 2014 at 12:12 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Fri, Jan 17, 2014 at 8:51 PM, Sherman Yin <syin@broadcom.com> wrote:
>
>> Thanks for the fix, Linus. While we're visiting this config, should we add
>> "depends on MACH_BCM_MOBILE" as well?
>
> No, it's nice to get the compile coverage.
But maybe you can experiment with that special option that only
turns on the driver on other platforms to do compile test.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: capri: add dependency on OF
From: Linus Walleij @ 2014-01-17 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D989C2.6030603@broadcom.com>
On Fri, Jan 17, 2014 at 8:51 PM, Sherman Yin <syin@broadcom.com> wrote:
> Thanks for the fix, Linus. While we're visiting this config, should we add
> "depends on MACH_BCM_MOBILE" as well?
No, it's nice to get the compile coverage.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Linus Walleij @ 2014-01-17 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67UKiyfJbKZ_Frk3OwZupMPoA2Ck3Hj2zsRFXBQPztavg@mail.gmail.com>
On Fri, Jan 17, 2014 at 6:43 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> +- NAME_shutdown-gpios : GPIO phandle to shutdown control
>>> + (phandle must be the second)
>>> +- NAME_reset-gpios : GPIO phandle to reset control
>>> +
>>> +NAME must match the rfkill-name property. NAME_shutdown-gpios or
>>> +NAME_reset-gpios, or both, must be defined.
>>> +
>>
>> I don't understand this part. Why do you include the name in the
>> gpios property, rather than just hardcoding the property strings
>> to "shutdown-gpios" and "reset-gpios"?
>
> This quirk is a result of how gpiod_get_index implements device tree
> lookup.
Why can't it just have a single property "gpios", where the first
element is the reset GPIO and the second is the shutdown GPIO?
rfkill-gpio does this:
gpio = devm_gpiod_get_index(&pdev->dev, rfkill->reset_name, 0);
gpio = devm_gpiod_get_index(&pdev->dev, rfkill->shutdown_name, 1);
The passed con ID name parameter is only there for the device
tree case it seems. (ACPI ignores it.) So what about you just
don't pass it at all and patch it to do like this instead:
gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0);
gpio = devm_gpiod_get_index(&pdev->dev, NULL, 1);
Heikki, are you OK with this change?
I think this is actually necessary if the ACPI and DT unification
pipe dream shall limp forward, we cannot have arguments passed
that have a semantic effect on DT but not on ACPI... Drivers
that are supposed to use both ACPI and DT will always
have to pass NULL as con ID.
> If con_id is given, it is prepended to "gpios" as the property string.
> con_id is also used as the label passed to gpiod_request, which is
> then shown in /sys/kernel/debug/gpio.
If your problem is really what turns up in debugfs, then we need
to figure out a way to label gpios outside of the *gpiod_get* calls.
The string passed in *gpiod_get* is a "connection ID" not a proper
name for the GPIO.
Yours,
Linus Walleij
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Eric Nelson @ 2014-01-17 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117202015.GE25911@pengutronix.de>
Hi Uwe,
On 01/17/2014 01:20 PM, Uwe Kleine-K?nig wrote:
> On Fri, Jan 17, 2014 at 12:40:02PM -0700, Stephen Warren wrote:
>> On 01/17/2014 11:47 AM, Russell King - ARM Linux wrote:
>
> <snip>
>
> Other than that I see five possibilities:
>
> ...
> b) check if for the requested gpio pad the SION bit is set and read the
> pad value if it is, return 0 otherwise. (But note, after thinking
> again I don't believe this to be possible, because there is usually >1
> pad that can output a given gpio. Moreover AFAIK the information to
> which pads a given gpio can be routed is missing in the kernel. That
> could be fixed, that would result in a big table though. (And the
> first problem is still unfixed.))
It would be a hassle to collect the data, but it seems that a table
of 2-byte offsets would be < 500 bytes for the 7 banks of GPIOs
on each platform (MX51,53,6DQ,6DLS).
Using this, it would be possible to set SION if/when a GPIO is
configured as an output, which would be much less intrusive than
setting the bit for all GPIO pads.
The current dts files show less than 10 pads being set up as GPIOs of
any sort for current board files. I suspect that this is because many
are incomplete and leave some pad setup to the boot loader though.
Regards,
Eric
^ permalink raw reply
* [PATCH 1/1] clk: samsung: Remove unneeded semicolon
From: Mike Turquette @ 2014-01-17 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389958552-15889-1-git-send-email-sachin.kamat@linaro.org>
Quoting Sachin Kamat (2014-01-17 03:35:52)
> Semicolon not needed after switch statement.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Taken into clk-next.
Thanks,
Mike
> ---
> drivers/clk/samsung/clk-pll.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index f2372fca0136..8538ffe042ce 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -375,7 +375,7 @@ static int samsung_pll45xx_set_rate(struct clk_hw *hw, unsigned long drate,
> break;
> default:
> break;
> - };
> + }
>
> /* Set new configuration. */
> __raw_writel(con1, pll->con_reg + 0x4);
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH 2/2] mmc: dw_mmc: k3: remove clk_table
From: Chris Ball @ 2014-01-17 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117225631.4167.47840@quantum>
Hi Mike,
On Fri, Jan 17 2014, Mike Turquette wrote:
> Oops, I just read this mail. I have taken in patch #1 through the clk
> tree but have not yet pushed it out to my public mirror.
>
> Chris, I'm happy to take it if you haven't yet.
That's fine. I'd like to take 2/2, just pushed it to mmc-next for 3.14.
Thanks,
- Chris.
--
Chris Ball <chris@printf.net> <http://printf.net/>
^ permalink raw reply
* [PATCH 2/2] mmc: dw_mmc: k3: remove clk_table
From: Mike Turquette @ 2014-01-17 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFt19AB2Yk4U06-R9rMqFgEHFjN_L-pnc1wR35SQUjX28j7tZQ@mail.gmail.com>
Quoting Seungwon Jeon (2014-01-17 08:10:23)
> On Sat, Jan 18, 2014 at 12:01 AM, Chris Ball <chris@printf.net> wrote:
> >
> > Hi,
> >
> > On Tue, Jan 14 2014, Seungwon Jeon wrote:
> > > On Monday, January 13, 2014, Zhangfei Gao wrote:
> > >> Remove clk_table and directly use ios->clock as clock source rate.
> > >> Abstract init clock rate and max clock limitation in clk.c
> > >>
> > >> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> > >
> > > Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
> >
> > It looks like patch 1/2 did not make 3.14. Do you want me to take
> > this patch for 3.14 anyway? (Why?)
> Yes, I hope that it would be merged this time.
> I think that this change should have been applied to (036f29: mmc:
> dw_mmc: add dw_mmc-k3 for k3 platform) originally.
Oops, I just read this mail. I have taken in patch #1 through the clk
tree but have not yet pushed it out to my public mirror.
Chris, I'm happy to take it if you haven't yet.
Regards,
Mike
>
> Thanks,
> sw-j
^ permalink raw reply
* [PATCH v2 1/2] dmaengine: add Qualcomm BAM dma driver
From: Arnd Bergmann @ 2014-01-17 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389380874-22753-2-git-send-email-agross@codeaurora.org>
On Friday 10 January 2014, Andy Gross wrote:
> +static bool bam_dma_filter(struct dma_chan *chan, void *data)
> +{
> + struct bam_filter_args *args = data;
> + struct bam_chan *bchan = to_bam_chan(chan);
> +
> + if (args->dev == chan->device &&
> + args->id == bchan->id) {
> +
> + /* we found the channel, so lets set the EE and dir */
> + bchan->ee = args->ee;
> + bchan->slave.direction = args->dir ?
> + DMA_DEV_TO_MEM : DMA_MEM_TO_DEV;
> + return true;
> + }
> +
> + return false;
> +}
A filter function should no longer be needed.
> +static struct dma_chan *bam_dma_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *of)
> +{
> + struct bam_filter_args args;
> + dma_cap_mask_t cap;
> +
> + if (dma_spec->args_count != 3)
> + return NULL;
> +
> + args.dev = of->of_dma_data;
> + args.id = dma_spec->args[0];
> + args.ee = dma_spec->args[1];
> + args.dir = dma_spec->args[2];
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + return dma_request_channel(cap, bam_dma_filter, &args);
> +}
Instead, call dma_get_slave_channel() with the right channel that you already know
here.
> + if (pdev->dev.of_node) {
> + ret = of_dma_controller_register(pdev->dev.of_node,
> + bam_dma_xlate, &bdev->common);
> +
> + if (ret) {
> + dev_err(bdev->dev, "failed to register of_dma\n");
> + goto err_unregister_dma;
> + }
> + }
No need to check for pdev->dev.of_node when that is the only mode of probing.
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id bam_of_match[] = {
> + { .compatible = "qcom,bam-v1.4.0", },
> + { .compatible = "qcom,bam-v1.4.1", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, bam_of_match);
> +#endif
Also, you can remove the #ifdef here and the of_match_ptr() below.
> +
> +static struct platform_driver bam_dma_driver = {
> + .probe = bam_dma_probe,
> + .remove = bam_dma_remove,
> + .driver = {
> + .name = "bam-dma-engine",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(bam_of_match),
> + },
> +};
> +
> +static int __init bam_dma_init(void)
> +{
> + return platform_driver_register(&bam_dma_driver);
> +}
> +
> +static void __exit bam_dma_exit(void)
> +{
> + return platform_driver_unregister(&bam_dma_driver);
> +}
> +
module_platform_driver()
> diff --git a/drivers/dma/qcom_bam_dma.h b/drivers/dma/qcom_bam_dma.h
> new file mode 100644
> index 0000000..2cb3b5f
> --- /dev/null
> +++ b/drivers/dma/qcom_bam_dma.h
> @@ -0,0 +1,268 @@
> +#ifndef __QCOM_BAM_DMA_H__
> +#define __QCOM_BAM_DMA_H__
> +
> +#include <linux/dmaengine.h>
> +#include "virt-dma.h"
> +
> +enum bam_channel_dir {
> + BAM_PIPE_CONSUMER = 0, /* channel reads from data-fifo or memory */
> + BAM_PIPE_PRODUCER, /* channel writes to data-fifo or memory */
> +};
Since the header does not serve as an interface, just move all the contents
into the driver directly.
> +struct bam_desc_hw {
> + u32 addr; /* Buffer physical address */
> + u16 size; /* Buffer size in bytes */
> + u16 flags;
> +} __packed;
Remove __packed here, it only makes the access less efficient but does not change
the layout, which is already packed.
Arnd
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Linus Walleij @ 2014-01-17 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117205346.GH15937@n2100.arm.linux.org.uk>
On Fri, Jan 17, 2014 at 9:53 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 17, 2014 at 01:42:44PM -0700, Stephen Warren wrote:
>> I believe you want gpio_get_value() to return either the driven or
>> actual pin value where it can on the current HW, but just e.g. hard-code
>> 0 on other HW. That would introduce a core feature that works some
>> places but not others, and hence make drivers that relied on the feature
>> less portable between HW with different actual features.
>
> I can buy that argument, but there's an issue which stands squarely in
> its way, and that is open-drain GPIOs.
>
> These are modelled just as any other GPIO, mainly so that both
> gpio_set_value(gpio, 1) and gpio_direction_input(gpio) both result in
> the signal being high. The only combination which results in the
> signal being driven low is outputting zero - and the state of the signal
> can aways be read back.
>
> The problem here is that such gpios are implemented in things like the
> I2C driver such that they're _always_ outputs, and gpio_set_value() is
> used to pull the signal down. gpio_get_value() is used to read its
> current state.
>
> So, if we say that gpio_get_value() is undefined, we force such
> subsystems to always jump through the non-open-drain paths (using
> gpio_direction_input() to set the line high and
> gpio_direction_output(gpio, 0) to drive it low.)
Incidentally that is what gpiolib is doing internally in
gpiod_direction_output().
You're absolutely right that it makes no sense to have open
drain (or open source) unless the signal can be read back from
the hardware.
I'm thinking something like if the driver manages to obtain a
GPIO with
gpio_request_one(gpio, GPIOF_OPEN_DRAIN |
GPIOF_OUT_INIT_HIGH);
As the I2C core does, and then when that call succeeds, it can
expect that whatever comes back from gpio_get_value() is
always what is actually on the line. If the driver cannot determine
this it should not have allowed that flag to succeed in the first
place, so this might be something we want to enforce.
There are two white spots on the map here:
1. Today this OPEN_DRAIN flag is not even passed down to
the driver so how could it say anything about it :-( it's a pure gpiolib
internal flag. We don't know if the hardware can actually even
do open drain, we just assume it can.
What it should really do - in the best of worlds - is to check if
it can cross-reference the GPIO line to a pin in the pin control
subsystem, and if that is possible, then ask the pin if it
is supporting open drain and set it. It currently has no such
cross-calls, it is just assumed that the configuration is consistent,
and the actual pin is set up as open drain. But it would make
sense to add more cross-calls here, since GPIO is accepting
these flags (OPEN_DRAIN/OPEN_SOURCE).
Like:
int pinctrl_gpio_set_flags(unsigned gpio, unsigned long flags);
Where the pinctrl subsystem would attempt to cross reference
and set the flag, and the pin controller backend will then have
the option to return an error code.
We could atleast support that for the select pin controllers
that use generic pin config. i.MX is another story, but I'm open
to compromises.
2. In the new descriptor API this open drain setting would
be set from the lookup table and be a property on the line,
meaning this flag is not requested explicitly by the consumer,
and the consumer needs to inspect the obtained descriptor
to figure out if it is set to open drain.
Alexandre: do you have plans for how to handle a dynamic
consumer passing flags to its gpio request in the gpiod API?
I noticed that API missing now, there is exactly one user in the
entire kernel, in drivers/i2c/i2c-core.c but a very important one.
I guess to switch the I2C core over to descriptors I could
think of an API like this:
int gpiod_get_flags(const struct gpio_desc *desc);
If the OPEN_DRAIN flag is set on that descriptor we should
always be able to read the input. But as this is not really what the
I2C core wants to know (it really would prefer not to bother with
such GPIO flag details) so is it better if we add a special call to
figure out if the input can be read? Like:
bool gpiod_input_always_valid(const struct gpio_desc *desc);
And leave it up to the core to look at flags, driver characteristics
etc and determine whether the input can be trusted?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/2] i2c: New bus driver for the QUP I2C controller
From: Bjorn Andersson @ 2014-01-17 22:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117003314.GB13785@codeaurora.org>
On Thu 16 Jan 16:33 PST 2014, Stephen Boyd wrote:
> On 01/16, Bjorn Andersson wrote:
> > On Wed 15 Jan 08:46 PST 2014, Stephen Boyd wrote:
> >
> > > On 01/13, Bjorn Andersson wrote:
> > > > +
> > > > +static int
> > > > +qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 req_state, bool only_valid)
> > > > +{
> > > > + int retries = 0;
> > > > + u32 state;
> > > > +
> > > > + do {
> > > > + state = readl(qup->base + QUP_STATE);
> > > > +
> > > > + /*
> > > > + * If only valid bit needs to be checked, requested state is
> > > > + * 'don't care'
> > > > + */
> > >
> > > It looks like req_state == 0 means only_valid == true. Can we
> > > drop the only_valid argument to this function?
> > >
> >
> > In all cases but the reset in the beginning of qup_i2c_xfer, so it seems that
> > it has to stay.
>
> Oh that's because QUP_RESET_STATE is equal to 0? It looks like
> bits 0 and 1 are the state field and bit 2 is a flag indicating
> that bits 0 and 1 are valid. Why not OR in the QUP_STATE_VALID
> flag into the macros that are passed to this function? Then the
> logic would simply be looping looking for a match of the
> req_state (which is really a mask now).
While it's true that req_state == 0 means only_valid, it is not true that
only_valid means req_state == 0. So there would be no way to differentiate
between "valid and reset" and "valid and don't care about run/pause/reset".
So I could move the logic around, but I don't see how we could reduce the
number of parameters to the function.
// Bjorn
^ permalink raw reply
* [PATCH] ARM: kirkwood: kirkwood_pm_init() should return void
From: Andrew Lunn @ 2014-01-17 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389984731-20220-1-git-send-email-ezequiel.garcia@free-electrons.com>
On Fri, Jan 17, 2014 at 03:52:11PM -0300, Ezequiel Garcia wrote:
> This function was originally meant to return void as declared in the
> common.h header. Fix it and include the header to catch these errors
> in the future.
>
> Reported-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Andrew
> ---
> arch/arm/mach-kirkwood/pm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-kirkwood/pm.c b/arch/arm/mach-kirkwood/pm.c
> index 8783a71..c11f7f5 100644
> --- a/arch/arm/mach-kirkwood/pm.c
> +++ b/arch/arm/mach-kirkwood/pm.c
> @@ -18,6 +18,7 @@
> #include <linux/suspend.h>
> #include <linux/io.h>
> #include <mach/bridge-regs.h>
> +#include "common.h"
>
> static void __iomem *ddr_operation_base;
>
> @@ -65,7 +66,7 @@ static const struct platform_suspend_ops kirkwood_suspend_ops = {
> .valid = kirkwood_pm_valid_standby,
> };
>
> -int __init kirkwood_pm_init(void)
> +void __init kirkwood_pm_init(void)
> {
> ddr_operation_base = ioremap(DDR_OPERATION_BASE, 4);
> suspend_set_ops(&kirkwood_suspend_ops);
> --
> 1.8.1.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] clk: sunxi: Add support for PLL6 on the A31
From: Mike Turquette @ 2014-01-17 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389892285-11745-2-git-send-email-maxime.ripard@free-electrons.com>
Quoting Maxime Ripard (2014-01-16 09:11:22)
> The A31 has a slightly different PLL6 clock. Add support for this new clock in
> our driver.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
This looks good to me. I guess it will be going in for 3.15 based on the
comments in the coverletter.
Regards,
Mike
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> drivers/clk/sunxi/clk-sunxi.c | 45 +++++++++++++++++++++++
> 2 files changed, 46 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index c2cb762..954845c 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -11,6 +11,7 @@ Required properties:
> "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
> "allwinner,sun4i-pll5-clk" - for the PLL5 clock
> "allwinner,sun4i-pll6-clk" - for the PLL6 clock
> + "allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
> "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
> "allwinner,sun4i-axi-clk" - for the AXI clock
> "allwinner,sun4i-axi-gates-clk" - for the AXI gates
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 659e4ea..990ad5d 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -249,7 +249,38 @@ static void sun4i_get_pll5_factors(u32 *freq, u32 parent_rate,
> *n = DIV_ROUND_UP(div, (*k+1));
> }
>
> +/**
> + * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
> + * PLL6 rate is calculated as follows
> + * rate = parent_rate * n * (k + 1) / 2
> + * parent_rate is always 24Mhz
> + */
> +
> +static void sun6i_a31_get_pll6_factors(u32 *freq, u32 parent_rate,
> + u8 *n, u8 *k, u8 *m, u8 *p)
> +{
> + u8 div;
> +
> + /*
> + * We always have 24MHz / 2, so we can just say that our
> + * parent clock is 12MHz.
> + */
> + parent_rate = parent_rate / 2;
> +
> + /* Normalize value to a parent_rate multiple (24M / 2) */
> + div = *freq / parent_rate;
> + *freq = parent_rate * div;
> +
> + /* we were called to round the frequency, we can now return */
> + if (n == NULL)
> + return;
> +
> + *k = div / 32;
> + if (*k > 3)
> + *k = 3;
>
> + *n = DIV_ROUND_UP(div, (*k+1));
> +}
>
> /**
> * sun4i_get_apb1_factors() - calculates m, p factors for APB1
> @@ -416,6 +447,13 @@ static struct clk_factors_config sun4i_pll5_config = {
> .kwidth = 2,
> };
>
> +static struct clk_factors_config sun6i_a31_pll6_config = {
> + .nshift = 8,
> + .nwidth = 5,
> + .kshift = 4,
> + .kwidth = 2,
> +};
> +
> static struct clk_factors_config sun4i_apb1_config = {
> .mshift = 0,
> .mwidth = 5,
> @@ -457,6 +495,12 @@ static const struct factors_data sun4i_pll5_data __initconst = {
> .getter = sun4i_get_pll5_factors,
> };
>
> +static const struct factors_data sun6i_a31_pll6_data __initconst = {
> + .enable = 31,
> + .table = &sun6i_a31_pll6_config,
> + .getter = sun6i_a31_get_pll6_factors,
> +};
> +
> static const struct factors_data sun4i_apb1_data __initconst = {
> .table = &sun4i_apb1_config,
> .getter = sun4i_get_apb1_factors,
> @@ -972,6 +1016,7 @@ free_clkdata:
> static const struct of_device_id clk_factors_match[] __initconst = {
> {.compatible = "allwinner,sun4i-pll1-clk", .data = &sun4i_pll1_data,},
> {.compatible = "allwinner,sun6i-a31-pll1-clk", .data = &sun6i_a31_pll1_data,},
> + {.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_data,},
> {.compatible = "allwinner,sun4i-apb1-clk", .data = &sun4i_apb1_data,},
> {.compatible = "allwinner,sun4i-mod0-clk", .data = &sun4i_mod0_data,},
> {.compatible = "allwinner,sun7i-a20-out-clk", .data = &sun7i_a20_out_data,},
> --
> 1.8.4.2
>
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Eric Nelson @ 2014-01-17 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eh462vrf.fsf@lebrac.rtp-net.org>
On 01/17/2014 01:33 PM, Arnaud Patard (Rtp) wrote:
> Eric Nelson <eric.nelson@boundarydevices.com> writes:
>
>> On 01/17/2014 12:57 PM, Arnaud Patard (Rtp) wrote:
>>> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>>>
>>>> So, we have this wonderful GPIO layer which abstracts GPIO stuff and
>>>> hides stuff. It's really wonderful, because you don't have to care
>>>> about how the GPIOs are actually accessed in drivers anymore.
>>>>
>>>> However, what about the behaviour of GPIOs?
>>>>
>>>> What about... for example... this sequence:
>>>>
>>>> gpio_direction_output(gpio, 1);
>>>> val = gpio_get_value(gpio);
>>>>
>>>> What value is "val"? More importantly, what value is reflected in
>>>> /sys/kernel/debug/gpio ? Would it indicate that it's high or low?
>>>>
>>>> Now, while you can make reasonable assumptions, such as "it'll return
>>>> that the output is being driven to the requested state" or "it'll
>>>> return the actual state of the pin", what about this instead, which
>>>> happens on iMX hardware - "it'll _always_ return zero".
>>>>
>>>
>>> this is "expected". gpio layer docs are saying that in output case, the
>>> value may be wrong. Not intuitive but documented.
>>>
>>>> Yes, iMX6 at least has this behaviour. For any output, val as above
>>>> will always be zero, and /proc/sys/kernel/debug/gpio will always
>>>> report that an output is zero... unless the SION bit has been set for
>>>> that GPIO signal.
>>>
>>> afaik at least imx51/53 have some behaviour.
>>>
>>>>
>>>> The reason is that on hardware such as iMX6, reading the GPIO is done
>>>> by reading the pad state register, and this register is _only_ supplied
>>>> the state of the pad when the input path is enabled. The input path
>>>> is only enabled when the output is disabled, or the SION bit is set
>>>> to force the GPIO input path.
>>>
>>> I sent mails about this same issue for imx51 in Dec 2010 and answer were
>>> that the SION bit should not be set for all gpios:
>>> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/100875
>>>
>>
>> Thanks Arnaud,
>>
>> This bit from the 2010 chain really needs some explanation:
>>
>>>> Arnaud Patard (Rtp) writes:
>>>>
>>>> <snip>
>>>>
>>>> I had done the same, but had some trouble with this.
>>>> E.g. on our board GPIO1_7 is used as a generic GPIO to enable an
>>>> external clock oscillator for the USBH1 ULPI PHY. When the SION bit
>>>> for this pad was set, I got strange errors on the USBH1 port
>>>> (disconnecting low speed devices behind a hub would stall the
>>>> bus). When I removed the SION bit for that pin everything worked
>>>> well.
>>>>
>>
>> Did you ever chase down the symptom here? Was the GPIO output not
>> holding a constant value such that the oscillator wasn't functioning?
>>
>
> It was not me who got this issue. The issue I had was not being able to
> read GPIO value if set as output. This link may be clearer:
> http://archive.arm.linux.org.uk/lurker/message/20101215.151016.ea731aa7.en.html
>
Thanks Arnaud. That link is quite a bit easier to follow.
I'm looping in Lothar and Dinh.
Dinh's comment in this thread makes no sense:
>>
>> The SION bit is a "Software Input On" bit. Basically, if
>> you set the GPIO as an output, you cannot set the SION bit.
>>
If that were the case, there's no point to either the bit or the PSR
registers. Dinh, can you or another Freescaler give a definitive
explanation here?
We also had some discussion about this on the U-Boot list regarding
Patch: http://lists.denx.de/pipermail/u-boot/2013-September/163805.html
Discussion:
http://lists.denx.de/pipermail/u-boot/2013-October/thread.html#163916
In the U-Boot case, we decided to flag those pins used as both
input and output specfically with the SION flag, which has the
benefit of pointing out to a reader that there's something unusual
going on.
Regards,
Eric
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Linus Walleij @ 2014-01-17 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117204342.GG15937@n2100.arm.linux.org.uk>
[CC:ing the comaintainer and linux-gpio for generic questions...]
On Fri, Jan 17, 2014 at 9:43 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 17, 2014 at 09:20:15PM +0100, Uwe Kleine-K?nig wrote:
>> e) add a flag to all gpio-chips signalling which case gpio_get_value
>> implements (i.e: return
>> - the actual value on the pad; or
>> - zero.
>> ). This is not orthogonal to b) - d)
>>
>> > > 2. What should be reported in /sys/kernel/debug/gpio for an output?
>> It should report the same thing as gpio_get_value in 1.
>
> There's another solution here. /sys/kernel/debug/gpio is there to allow
> us to see the state of the GPIOs, right? Well, if the asked-for output
> value can be different from the read-back output value, how about fixing
> this so that the _debug_ can report back what the desired output state
> as well as the current input state.
>
> This would mean that this file becomes something like:
>
> gpio-86 (usb_otg_vbus ) dir:out out:hi in:lo
>
> which makes it clear that either the pad is being asked to output a high
> level, but for some reason reading the input side is returning low state.
> It also lets you see what was asked of the output, and what was (in
> theory) written to the output.
I really like the looks of this. That kind of helpful stuff is exactly
what the debugfs files shall be used for.
> It may _also_ be a good idea to do (e) - have a per-gpiochip flag which
> indicates the behaviour here, and omit the "out:" or "in:" as appropriate.
That also seems like a good idea.
> Finally, consider that some drivers should be provided this information.
> For example, the bitbanging I2C driver needs this for:
>
> scllo(adap);
> sda = getsda(adap);
> scl = (adap->getscl == NULL) ? 0 : getscl(adap);
> if (scl) {
> printk(KERN_WARNING "%s: SCL stuck high!\n", name);
> goto bailout;
> }
> if (!sda) {
> printk(KERN_WARNING "%s: SDA unexpected low "
> "while pulling SCL low!\n", name);
> goto bailout;
> }
>
> sclhi(adap);
> sda = getsda(adap);
> scl = (adap->getscl == NULL) ? 1 : getscl(adap);
> if (!scl) {
> printk(KERN_WARNING "%s: SCL stuck low!\n", name);
> goto bailout;
> }
> if (!sda) {
> printk(KERN_WARNING "%s: SDA unexpected low "
> "while pulling SCL high!\n", name);
> goto bailout;
> }
>
> Now, if getscl() always returns zero when scllo() is called (because the
> pin is set as an output) the test is pretty useless - it turns into a
> verification that yes, the hardware does return zero from the pad register
> when the pin is set as an output.
If we can come up with a good API for it this seems useful as
well. The bit-banged I2C is a perfectly valid usecase.
I guess we could discuss adding that to the new gpiod API so
we get some traction around that and start to clean things up properly.
I'd really prefer not to see it in the legacy API.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] clk: qcom: Fix modular build
From: Mike Turquette @ 2014-01-17 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389989380-17441-1-git-send-email-sboyd@codeaurora.org>
Quoting Stephen Boyd (2014-01-17 12:09:40)
> According to Documentation/kbuild/makefiles.txt these symbols
> should be clk-qcom-y. Otherwise the build will fail if
> CONFIG_COMMON_CLK_QCOM=m. Fix it.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Taken into clk-next.
Regards,
Mike
> ---
> drivers/clk/qcom/Makefile | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 190d38433202..f60db2ef1aee 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -1,11 +1,11 @@
> obj-$(CONFIG_COMMON_CLK_QCOM) += clk-qcom.o
>
> -clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-regmap.o
> -clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-pll.o
> -clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-rcg.o
> -clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-rcg2.o
> -clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-branch.o
> -clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += reset.o
> +clk-qcom-y += clk-regmap.o
> +clk-qcom-y += clk-pll.o
> +clk-qcom-y += clk-rcg.o
> +clk-qcom-y += clk-rcg2.o
> +clk-qcom-y += clk-branch.o
> +clk-qcom-y += reset.o
>
> obj-$(CONFIG_MSM_GCC_8660) += gcc-msm8660.o
> obj-$(CONFIG_MSM_GCC_8960) += gcc-msm8960.o
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH 0/3] ARM: OMAP: clk-next-omap emergency fixes
From: Mike Turquette @ 2014-01-17 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389990340-23358-1-git-send-email-t-kristo@ti.com>
Quoting Tero Kristo (2014-01-17 12:25:37)
> Hi,
>
> Quick emergency band-aid for the build breakages introduced in clk-next
> by Mike. I didn't have time to test this out (Nishanth will provide some
> logs) and I will leave the decision whether/how to use these patches or not
> to Tony + Mike.
>
> I also pushed a test branch based on top of clk-next here:
> tree: https://github.com/t-kristo/linux-pm.git
> branch: clk-next-omap-fixes
Thanks Tero. I force updated the clk tree with the right branch, so
these should not be necessary now.
Regards,
Mike
>
> -Tero
>
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Mike Turquette @ 2014-01-17 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D9723A.6000700@ti.com>
Quoting Tero Kristo (2014-01-17 10:11:06)
> On 01/17/2014 07:53 PM, Tony Lindgren wrote:
> > * Kevin Hilman <khilman@linaro.org> [140117 09:48]:
> >> Mike Turquette <mturquette@linaro.org> writes:
> >>
> >> [...]
> >>
> >>> I took Tony's advice and fast-forwarded clk-next to -rc7 and applied
> >>> Tero's series. This includes the AM3517 bits now. I've pushed this
> >>> branch to clk-next-omap (force update) on my Linaro mirror. Can you do a
> >>> final sanity test before I merge this into clk-next?
>
> I think you accidentally merged wrong branch to clk-next-omap with the
> latest refresh. This is one is missing the build-fixes now, when it
> earlier had those in.
>
> The correct branch to merge was 3.13-rc7-dt-clks-v13-build-fixes.
>
> This also causes the build failure below for omap1.
You are right. I broke the OMAPs. I force updated clk-next-omap (and
clk-next) with the correct branch this time.
Regards,
Mike
>
> -Tero
>
> >>
> >> I merged clk-next-omap into next-20140117 and build/boot tested
> >> omap2plus_defconfig, multi_v7_defconfig and
> >> multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for
> >> omap5uevm.
> >>
> >> I'll add OMAP5 to the automated boot testing starting with the next
> >> linux-next.
> >
> > OK that's good news. Looks like omap1_defconfig build has now started
> > failing though:
> >
> > vers/built-in.o: In function `omap5xxx_dt_clk_init':
> > :(.init.text+0x846c): undefined reference to `omap2_clk_disable_autoidle_all'
> > drivers/built-in.o: In function `am43xx_dt_clk_init':
> > :(.init.text+0x856c): undefined reference to `omap2_clk_disable_autoidle_all'
> > drivers/built-in.o:(.rodata+0xc3c4): undefined reference to `omap3_clkoutx2_recalc'
> > drivers/built-in.o:(.rodata+0xc40c): undefined reference to `omap3_noncore_dpll_enable'
> > drivers/built-in.o:(.rodata+0xc410): undefined reference to `omap3_noncore_dpll_disable'
> > drivers/built-in.o:(.rodata+0xc41c): undefined reference to `omap3_dpll_recalc'
> > drivers/built-in.o:(.rodata+0xc420): undefined reference to `omap2_dpll_round_rate'
> > drivers/built-in.o:(.rodata+0xc42c): undefined reference to `omap2_init_dpll_parent'
> > drivers/built-in.o:(.rodata+0xc430): undefined reference to `omap3_noncore_dpll_set_rate'
> > drivers/built-in.o:(.rodata+0xc470): undefined reference to `omap3_dpll_recalc'
> > drivers/built-in.o:(.rodata+0xc474): undefined reference to `omap2_dpll_round_rate'
> > drivers/built-in.o:(.rodata+0xc480): undefined reference to `omap2_init_dpll_parent'
> > drivers/built-in.o:(.rodata+0xc4a0): undefined reference to `omap3_noncore_dpll_enable'
> > drivers/built-in.o:(.rodata+0xc4a4): undefined reference to `omap3_noncore_dpll_disable'
> > drivers/built-in.o:(.rodata+0xc4b0): undefined reference to `omap3_dpll_recalc'
> > drivers/built-in.o:(.rodata+0xc4b4): undefined reference to `omap2_dpll_round_rate'
> > drivers/built-in.o:(.rodata+0xc4c0): undefined reference to `omap2_init_dpll_parent'
> > drivers/built-in.o:(.rodata+0xc4c4): undefined reference to `omap3_dpll4_set_rate'
> > drivers/built-in.o:(.rodata+0xc4e0): undefined reference to `omap3_noncore_dpll_enable'
> > drivers/built-in.o:(.rodata+0xc4e4): undefined reference to `omap3_noncore_dpll_disable'
> > drivers/built-in.o:(.rodata+0xc4f0): undefined reference to `omap3_dpll_recalc'
> > drivers/built-in.o:(.rodata+0xc4f4): undefined reference to `omap2_dpll_round_rate'
> > drivers/built-in.o:(.rodata+0xc500): undefined reference to `omap2_init_dpll_parent'
> > drivers/built-in.o:(.rodata+0xc504): undefined reference to `omap3_noncore_dpll_set_rate'
> > drivers/built-in.o:(.rodata+0xc530): undefined reference to `omap3_dpll_recalc'
> > drivers/built-in.o:(.rodata+0xc540): undefined reference to `omap2_init_dpll_parent'
> > drivers/built-in.o:(.rodata+0xc560): undefined reference to `omap3_noncore_dpll_enable'
> > drivers/built-in.o:(.rodata+0xc564): undefined reference to `omap3_noncore_dpll_disable'
> > drivers/built-in.o:(.rodata+0xc570): undefined reference to `omap4_dpll_regm4xen_recalc'
> > drivers/built-in.o:(.rodata+0xc574): undefined reference to `omap4_dpll_regm4xen_round_rate'
> > drivers/built-in.o:(.rodata+0xc580): undefined reference to `omap2_init_dpll_parent'
> > drivers/built-in.o:(.rodata+0xc584): undefined reference to `omap3_noncore_dpll_set_rate'
> > drivers/built-in.o:(.rodata+0xc5b0): undefined reference to `omap3_dpll_recalc'
> > drivers/built-in.o:(.rodata+0xc5b4): undefined reference to `omap2_dpll_round_rate'
> > drivers/built-in.o:(.rodata+0xc5c0): undefined reference to `omap2_init_dpll_parent'
> > drivers/built-in.o:(.rodata+0xc5c4): undefined reference to `omap3_noncore_dpll_set_rate'
> > drivers/built-in.o:(.rodata+0xc63c): undefined reference to `omap2_dflt_clk_enable'
> > drivers/built-in.o:(.rodata+0xc640): undefined reference to `omap2_dflt_clk_disable'
> > drivers/built-in.o:(.rodata+0xc644): undefined reference to `omap2_dflt_clk_is_enabled'
> > drivers/built-in.o:(.rodata+0xc728): undefined reference to `omap2_clkops_enable_clkdm'
> > drivers/built-in.o:(.rodata+0xc72c): undefined reference to `omap2_clkops_disable_clkdm'
> > drivers/built-in.o:(.rodata+0xc754): undefined reference to `omap2_init_clk_clkdm'
> > drivers/built-in.o:(.rodata+0xc784): undefined reference to `omap2_dflt_clk_disable'
> > drivers/built-in.o:(.rodata+0xc788): undefined reference to `omap2_dflt_clk_is_enabled'
> > drivers/built-in.o:(.rodata+0xc7ac): undefined reference to `omap2_init_clk_clkdm'
> > drivers/built-in.o:(.rodata+0xc7c0): undefined reference to `omap2_dflt_clk_enable'
> > drivers/built-in.o:(.rodata+0xc7c4): undefined reference to `omap2_dflt_clk_disable'
> > drivers/built-in.o:(.rodata+0xc7c8): undefined reference to `omap2_dflt_clk_is_enabled'
> > drivers/built-in.o:(.rodata+0xc7ec): undefined reference to `omap2_init_clk_clkdm'
> > drivers/built-in.o:(.rodata+0xc838): undefined reference to `__clk_mux_determine_rate'
> > drivers/built-in.o:(.rodata+0xc904): undefined reference to `omap2_dflt_clk_enable'
> > drivers/built-in.o:(.rodata+0xc908): undefined reference to `omap2_dflt_clk_disable'
> > drivers/built-in.o:(.rodata+0xc90c): undefined reference to `omap2_dflt_clk_is_enabled'
> > drivers/built-in.o:(.rodata+0xc930): undefined reference to `omap2_init_clk_clkdm'
> >
> > Regards,
> >
> > Tony
> >
>
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Sarah Sharp @ 2014-01-17 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zjmvau23.fsf@nemi.mork.no>
On Fri, Jan 17, 2014 at 09:31:16AM +0100, Bj?rn Mork wrote:
> arno at natisbad.org (Arnaud Ebalard) writes:
> > Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> >
> >>> ... AFAICT, this is exactly what commit 35773dac5f86 does and reverting
> >>> it does not help. If I am mistaken, can you point which part you want me
> >>> to remove in the code to test?
> >>>
> >>> I am slowly starting to see a bisect session coming ;-)
> >>
> >> Try reverting commit 60e102ac73cd40069d077014c93c86dc7205cb68.
> >
> > AFAICT, this commit does not exist in master (Linus tree), i.e. it is
> > not in 3.13.0-rc8.
>
> That commit is a stable backport of 9df89d85b407690afa46ddfbccc80bec6869971d
> which is in v3.13-rc8:
>
> bjorn at nemi:/usr/local/src/git/linux$ git tag --contains 9df89d85b407690afa46ddfbccc80bec6869971d
> usb-3.13-rc1
> usb-3.13-rc3
> usb-3.13-rc5
> v3.13-rc1
> v3.13-rc2
> v3.13-rc3
> v3.13-rc4
> v3.13-rc5
> v3.13-rc6
> v3.13-rc7
> v3.13-rc8
Sorry for using the stable commit ID. Arnaud, please try reverting
commit 9df89d85b407690afa46ddfbccc80bec6869971d "usbcore: set
lpm_capable field for LPM capable root hubs" and see if it fixes your
issues.
Sarah Sharp
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox