Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 07:20 PM, Nishanth Menon wrote: [...] > I am running a defconfig set check on next-20140117 and will do one > with next-20140118 once that is ready for comparison results > baseline next-20140120 modified as follows: multi_v7_defconfig - added CONFIG_SOC_DRA7XX omap2plus_defconfig - added CONFIG_SOC_AM43XX few patches for legacy boot platforms added in. next-20140120-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2vfJ5w6Na 2: am335x-sk: Boot PASS: http://slexy.org/raw/s21IdtacuB 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2zrGqzI8r 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21RLq4EzM 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21msOh70k 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2MyM1kbTJ 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2KmkjEQU5 8: crane: No Image built - Missing platform support?: * Pending merge from Benoit's tree 9: dra7: Boot PASS: http://slexy.org/raw/s20GK8ZSrL 10:ldp: Boot FAIL: http://slexy.org/raw/s20I1vJEY6 * Known issue on my setup :( - debug pending. 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s2SVGtHlwx 12:sdp2430: Boot PASS: http://slexy.org/raw/s214WyGCco 13:sdp3430: Boot PASS: http://slexy.org/raw/s21fPHXoOB 14:sdp4430: Boot PASS: http://slexy.org/raw/s20v0UJubl 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2jPgymund TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 next-20140120-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2DcNIdR1p 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2NWkEQIct 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21rOVU9L3 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2xRLmJ9EW 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21487l9Tw 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2198moPea 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s20wdS9zgf 8: crane: No Image built - Missing platform support?: * pending merge from Benoit's tree 9: dra7: Boot PASS: http://slexy.org/raw/s21Vr0foZS 10:ldp: Boot PASS: http://slexy.org/raw/s21PKycvVx 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s20M5bdzFq * kevin already reported this for CPU_IDLE enable 12:sdp2430: v6 platform - wont boot 13:sdp3430: Boot PASS: http://slexy.org/raw/s2pmLQItJb 14:sdp4430: Boot PASS: http://slexy.org/raw/s21FYwSVZz 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21O7xuAJp TOTAL = 15 boards, Booted Boards = 12, No Boot boards = 3 next-20140120-multi_v7_defconfig + CONFIG_ARM_LPAE=y 1: am335x-evm: Boot FAIL: http://slexy.org/raw/s21YHQrdtf 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s20buoWhQw 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s2VfH3LYFf 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20Q4s7tjA 5: am43xx-epos: Boot FAIL: http://slexy.org/raw/s2tMG0ABLi 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s20INrphLO 7: BeagleBone-Black: Boot FAIL: http://slexy.org/raw/s2ZKx9lyGc 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s21EV3vV4E 10:ldp: Boot FAIL: http://slexy.org/raw/s21aQ1vXWH 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s20JMBxQUc 12:sdp2430: v6 platform - wont boot 13:sdp3430: Boot FAIL: http://slexy.org/raw/s20Itj0uX4 14:sdp4430: Boot FAIL: http://slexy.org/raw/s2BEPG9pjN 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20bOKUZev TOTAL = 15 boards, Booted Boards = 2, No Boot boards = 13 in comparison with previous next tag: multi_v7_defconfig - added CONFIG_SOC_DRA7XX omap2plus_defconfig - added CONFIG_SOC_AM43XX few patches for legacy boot platforms added in. next-20140117-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2x6c41m1Q 2: am335x-sk: Boot PASS: http://slexy.org/raw/s24IkMtLwV 3: am3517-evm: Boot PASS: http://slexy.org/raw/s20ahoA1JR 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2hzZbe5fq 5: am43xx-epos: Boot FAIL: http://slexy.org/raw/s20875oeoW 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s20luzJWbj 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2Z1YQqX1A 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s2137kLALM 10:ldp: Boot FAIL: http://slexy.org/raw/s21S66NNnp 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s20XyDcifE 12:sdp2430: Boot PASS: http://slexy.org/raw/s234d7bWzB 13:sdp3430: Boot PASS: http://slexy.org/raw/s250xvaBxy 14:sdp4430: Boot PASS: http://slexy.org/raw/s2g3As3XlA 15: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s21hOhWY4E TOTAL = 15 boards, Booted Boards = 10, No Boot boards = 5 next-20140117-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2M6DZp8D2 2: am335x-sk: Boot PASS: http://slexy.org/raw/s21WdeG7QL 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2PanhpCqK 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On Fri, Jan 17, 2014 at 07:20:06PM -0600, Nishanth Menon wrote: > On 01/17/2014 06:23 PM, Olof Johansson wrote: > > On Fri, Jan 17, 2014 at 4:19 PM, Nishanth Menon wrote: > >> On 01/17/2014 06:12 PM, Olof Johansson wrote: > >>> On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon 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). > > > I suppose, as expected: > clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_ARM_LPAE=y > * .config = http://slexy.org/view/s208uSeQS8 > * Build warnings: http://slexy.org/raw/s20n7YwbwN > 1: am335x-evm: Boot FAIL: http://slexy.org/raw/s20tF2eUZG > 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2uP65lOMQ > 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s2Lx13gsFZ > 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s2eOLXxvsT > 5: am43xx-epos: Boot FAIL: http://slexy.org/raw/s24coJzGvR > 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s240WznuPd > 7: BeagleBone-Black: Boot FAIL: http://slexy.org/raw/s20NG2UVTU > 8: crane: No Image built - Missing platform support?: > 9: dra7: Boot FAIL: http://slexy.org/raw/s21T3RpHx2 > ^^ might probably boot if we enable CONFIG_SOC_DRA7XX in multi_v7 > (this is another A15 target) > 10:ldp: Boot FAIL: http://slexy.org/raw/s2F4VO9hDM > 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s20HpzT1jW > 12:sdp2430: Boot FAIL: http://slexy.org/raw/s21snV1EvL > 13:sdp3430: Boot FAIL: http://slexy.org/raw/s2FwkVfG5R > 14:sdp4430: Boot FAIL: http://slexy.org/raw/s2xiWxlpTj > 15: uevm: Boot PASS: http://slexy.org/raw/s2LWUOmfiG > TOTAL = 15 boards, Booted Boards = 1, No Boot boards = 14 > > I am running a defconfig set check on next-20140117 and will do one > with next-20140118 once that is ready for comparison results Just for reference: I tried booting Nokia N900 using mike's clk-next-omap branch (HEAD = 3e04915): n900: Boot PASS: http://paste.debian.net/77085/ -- Sebastian signature.asc Description: Digital signature
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Mike Turquette [140117 13:00]: > Quoting Tero Kristo (2014-01-17 10:11:06) > > On 01/17/2014 07:53 PM, Tony Lindgren wrote: > > > * Kevin Hilman [140117 09:48]: > > >> Mike Turquette 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. OK works for me now, thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 06:23 PM, Olof Johansson wrote: > On Fri, Jan 17, 2014 at 4:19 PM, Nishanth Menon wrote: >> On 01/17/2014 06:12 PM, Olof Johansson wrote: >>> On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon 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). > I suppose, as expected: clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_ARM_LPAE=y * .config = http://slexy.org/view/s208uSeQS8 * Build warnings: http://slexy.org/raw/s20n7YwbwN 1: am335x-evm: Boot FAIL: http://slexy.org/raw/s20tF2eUZG 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2uP65lOMQ 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s2Lx13gsFZ 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s2eOLXxvsT 5: am43xx-epos: Boot FAIL: http://slexy.org/raw/s24coJzGvR 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s240WznuPd 7: BeagleBone-Black: Boot FAIL: http://slexy.org/raw/s20NG2UVTU 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s21T3RpHx2 ^^ might probably boot if we enable CONFIG_SOC_DRA7XX in multi_v7 (this is another A15 target) 10:ldp: Boot FAIL: http://slexy.org/raw/s2F4VO9hDM 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s20HpzT1jW 12:sdp2430: Boot FAIL: http://slexy.org/raw/s21snV1EvL 13:sdp3430: Boot FAIL: http://slexy.org/raw/s2FwkVfG5R 14:sdp4430: Boot FAIL: http://slexy.org/raw/s2xiWxlpTj 15: uevm: Boot PASS: http://slexy.org/raw/s2LWUOmfiG TOTAL = 15 boards, Booted Boards = 1, No Boot boards = 14 I am running a defconfig set check on next-20140117 and will do one with next-20140118 once that is ready for comparison results -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On Fri, Jan 17, 2014 at 4:19 PM, Nishanth Menon wrote: > On 01/17/2014 06:12 PM, Olof Johansson wrote: >> On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 06:12 PM, Olof Johansson wrote: > On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
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 [140117 09:48]: Mike Turquette 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 su
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Tero Kristo (2014-01-17 10:11:06) > On 01/17/2014 07:53 PM, Tony Lindgren wrote: > > * Kevin Hilman [140117 09:48]: > >> Mike Turquette 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_c
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 11:46 AM, Kevin Hilman wrote: > Mike Turquette 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 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. Here are my logs for the similar configuration(with few patches for legacy boot): next-db23a6c + next-20140117 (omap2plus_defconfig) 1: am335x-evm: Boot PASS: http://slexy.org/raw/s20pGXG1jF 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2ViUqyxYc 3: am3517-evm: Boot PASS: http://slexy.org/raw/s29qMTk2mS 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20aZ0oDHS 5: beag: Boot PASS: http://slexy.org/raw/s2DAKDwqRm 6: bone: Boot PASS: http://slexy.org/raw/s215UVEmq2 7: crane: No Image built - Missing platform support?: (pending merge from Benoit) 8: dra7: Boot PASS: http://slexy.org/raw/s2CbtBGGxE 9:ldp: Boot FAIL: http://slexy.org/raw/s20MOKNvPG (been seeing this behavior on and off for some days now.. not really a regression due to this series - need to debug this - could be setup issues). 10: panda: Boot PASS: http://slexy.org/raw/s20RHdfXjS 11:sdp2430: Boot PASS: http://slexy.org/raw/s21fR9cQap 12:sdp3430: Boot PASS: http://slexy.org/raw/s209eZfYlQ 13:sdp4430: Boot PASS: http://slexy.org/raw/s21jemvEcd 14: uevm: Boot PASS: http://slexy.org/raw/s20OumuRI8 TOTAL = 14 boards, Booted Boards = 12, No Boot boards = 2 clk-next-db23a6c + next-20140117 (multi_v7_defconfig) 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21kek3KDX 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20b6Ypnpr 3: am3517-evm: Boot PASS: http://slexy.org/raw/s200aHOMA1 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2QwHWtLbB 5: beag: Boot PASS: http://slexy.org/raw/s2120qe2nJ 6: bone: Boot PASS: http://slexy.org/raw/s21SnQH1AY 7: crane: No Image built - Missing platform support?: 8: dra7: Boot FAIL: http://slexy.org/raw/s20HxBFzIr missing DRA7 in multi_v7 9:ldp: Boot PASS: http://slexy.org/raw/s21vjb9GeV 10: panda: Boot FAIL: http://slexy.org/raw/s2WahEfqVw kevin already reported this for CPU_IDLE enable 11:sdp2430: Boot FAIL: http://slexy.org/raw/s2ADmtqRhq * multi_v7 does not boot v6 based boards 12:sdp3430: Boot PASS: http://slexy.org/raw/s2qM9hxrfi 13:sdp4430: Boot PASS: http://slexy.org/raw/s2ubbIBRA7 14: uevm: Boot PASS: http://slexy.org/raw/s2Y9xESvfH TOTAL = 14 boards, Booted Boards = 10, No Boot boards = 4 clk-next-db23a6c + next-20140117 (multi_v7_defconfig + CONFIG_LPAE=y) 1: am335x-evm: Boot PASS: http://slexy.org/raw/s26sCQ0zqh 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20BDyQWdB 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21OPwGNo1 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20tpjF0ri 5: beag: Boot PASS: http://slexy.org/raw/s2jzkyRVaS 6: bone: Boot PASS: http://slexy.org/raw/s20XodcZtZ 7: crane: No Image built - Missing platform support?: 8: dra7: Boot FAIL: http://slexy.org/raw/s21cv8ni1H missing DRA7 in multi_v7 9:ldp: Boot PASS: http://slexy.org/raw/s22x4lqV3F 10: panda: Boot FAIL: http://slexy.org/raw/s200ETyoTB kevin already reported this for CPU_IDLE enable 11:sdp2430: Boot FAIL: http://slexy.org/raw/s2lw3baFwx * multi_v7 does not boot v6 based boards 12:sdp3430: Boot PASS: http://slexy.org/raw/s21i0TdsYs 13:sdp4430: Boot PASS: http://slexy.org/raw/s2DaYv6GVp 14: uevm: Boot PASS: http://slexy.org/raw/s2Q5IdWfMQ TOTAL = 14 boards, Booted Boards = 10, No Boot boards = 4 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 07:53 PM, Tony Lindgren wrote: * Kevin Hilman [140117 09:48]: Mike Turquette 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. -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_
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Kevin Hilman [140117 09:48]: > Mike Turquette 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 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+0
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Mike Turquette 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 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. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/16/2014 03:39 PM, Mike Turquette wrote: > Quoting Tony Lindgren (2014-01-15 11:35:48) >> * Mike Turquette [140115 11:25]: >>> Quoting Tony Lindgren (2014-01-15 09:13:23) * Mike Turquette [140114 19:52]: >> >> These 40 patches apply very cleanly on top of clk-next with 2 >> exceptions: >> >> 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" >> because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based >> on 3.13-rc1). >> >> 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I >> resolved correctly but would like verification. >> >> I'd prefer to simply merge these patches into clk-next, which is the >> most straightforward route. Any ideas on how to handle the missing >> AM35xx dtsi data? It can always go as a separate fix after this stuff >> gets merged which, ironically, is how that file was created in the first >> place. You could do something like this to take advantage of fast forward and not have to do a merge back from mainline: $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired -rc $ git am am3517-clk-patch $ git checkout clk-next $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc >>> >>> That makes sense, but is there anything bad about doing that for a >>> branch you intend to send as a pull request? I don't see how any of the >>> commits get re-written or anything... I just wonder if there is some >>> subtlety that I am not accounting for that makes this approach bad for >>> sending to Linus. >> >> No there should not be any issues. That's the preferred way to keep >> development branches updated and pullable in long term without any need >> to rebase. >> >> Note that there will be only a merge commit if there is a conflict, >> otherwise the fast forward will be transparent. So the trick to avoiding >> rebasing and back merges is to apply patches against what they need in a >> local branch, then after testing merge that local branch into the development >> branch. Then for the upsteam pull request, you just need to make it against >> the -rc you merged in. >> >> AFAIK what Linus does not like is doing a back merge to a development >> branch from mainline, probably as it adds a pointless commit. Or rebasing >> a branch as that way it won't stay pullable. > > Hi all, > > 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? multi_v7_defconfig: 1: am335x-evm: Boot FAIL: http://slexy.org/raw/s25jHnIctr mmc/regulator missing stuff 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2e9oDkTbD mmc/regulator missing stuff 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2KL4qBOM6 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20jAHD1DE 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21vXGDma7 6: beag: Boot PASS: http://slexy.org/raw/s25ZJgkM9q 7: bone: Boot PASS: http://slexy.org/raw/s21U0U2lVW 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s24d4sXtTh CONFIG_SOC_DRA7XX not present in multi_v7 10:ldp: No Image built - Missing platform support?: 11: panda: Boot PASS: http://slexy.org/raw/s21KrJmEWB 12:sdp2430: No Image built - Missing platform support?: 13:sdp3430: Boot PASS: http://slexy.org/raw/s21uwA3Swz 14:sdp4430: Boot PASS: http://slexy.org/raw/s21GE8FOPC 15: uevm: Boot FAIL: http://slexy.org/raw/s2E3NAziyb mmc/regulator missing stuff TOTAL = 15 boards, Booted Boards = 8, No Boot boards = 7 omap2plus_defconfig: 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2euW1YeS0 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2nxn1i5Ea 3: am3517-evm: Boot PASS: http://slexy.org/raw/s20knQQExn 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21L1hfSHF 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2EpSMvtnF 6: beag: Boot PASS: http://slexy.org/raw/s21Z8ytsMS 7: bone: Boot PASS: http://slexy.org/raw/s21ZpxRieJ 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s2owXcv5DW 10:ldp: No Image built - Missing platform support?: 11: panda: Boot PASS: http://slexy.org/raw/s215rSL4p0 12:sdp2430: No Image built - Missing platform support?: 13:sdp3430: Boot PASS: http://slexy.org/raw/s21dxlFJn7 14:sdp4430: Boot PASS: http://slexy.org/raw/s20WIfzRqi 15: uevm: Boot PASS: http://slexy.org/raw/s20Ba9mBTv TOTAL = 15 boards, Booted Boards = 12, No Boot boards = 3 the 3 no image built boards have pending dts patches in for-next from Tony and Benoit. So, linux-next should eventually
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Mike Turquette [140115 11:25]: > Quoting Tony Lindgren (2014-01-15 09:13:23) > > * Mike Turquette [140114 19:52]: > > > > > > > > These 40 patches apply very cleanly on top of clk-next with 2 > > > > exceptions: > > > > > > > > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" > > > > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based > > > > on 3.13-rc1). > > > > > > > > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I > > > > resolved correctly but would like verification. > > > > > > > > I'd prefer to simply merge these patches into clk-next, which is the > > > > most straightforward route. Any ideas on how to handle the missing > > > > AM35xx dtsi data? It can always go as a separate fix after this stuff > > > > gets merged which, ironically, is how that file was created in the first > > > > place. > > > > You could do something like this to take advantage of fast forward and > > not have to do a merge back from mainline: > > > > $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi > > $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired > > -rc > > $ git am am3517-clk-patch > > $ git checkout clk-next > > $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc > > That makes sense, but is there anything bad about doing that for a > branch you intend to send as a pull request? I don't see how any of the > commits get re-written or anything... I just wonder if there is some > subtlety that I am not accounting for that makes this approach bad for > sending to Linus. No there should not be any issues. That's the preferred way to keep development branches updated and pullable in long term without any need to rebase. Note that there will be only a merge commit if there is a conflict, otherwise the fast forward will be transparent. So the trick to avoiding rebasing and back merges is to apply patches against what they need in a local branch, then after testing merge that local branch into the development branch. Then for the upsteam pull request, you just need to make it against the -rc you merged in. AFAIK what Linus does not like is doing a back merge to a development branch from mainline, probably as it adds a pointless commit. Or rebasing a branch as that way it won't stay pullable. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Mike Turquette [140114 19:52]: > > > > These 40 patches apply very cleanly on top of clk-next with 2 > > exceptions: > > > > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" > > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based > > on 3.13-rc1). > > > > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I > > resolved correctly but would like verification. > > > > I'd prefer to simply merge these patches into clk-next, which is the > > most straightforward route. Any ideas on how to handle the missing > > AM35xx dtsi data? It can always go as a separate fix after this stuff > > gets merged which, ironically, is how that file was created in the first > > place. You could do something like this to take advantage of fast forward and not have to do a merge back from mainline: $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired -rc $ git am am3517-clk-patch $ git checkout clk-next $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/15/2014 07:41 AM, Tero Kristo wrote: > On 01/15/2014 05:50 AM, Mike Turquette wrote: >> Quoting Mike Turquette (2014-01-14 19:16:32) >>> Quoting Felipe Balbi (2014-01-14 18:04:21) Hi, On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: >> Felipe, care to run your randconfig magic for this? > > This branch builds just fine so far, I still have omap5 multiplaform and > uniplatform builds, but since that was working before i'm assuming it > won't break. No build failures in any of my 18 seeds (5 randconfigs of each), I'd attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can send it. FWIW: Acked-by: Felipe Balbi >>> >>> Felipe, >>> >>> That's great to hear. Thanks for testing. >>> >>> Tero & Tony, >>> >>> These 40 patches apply very cleanly on top of clk-next with 2 >>> exceptions: >>> >>> 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" >>> because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based >>> on 3.13-rc1). >>> >>> 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I >>> resolved correctly but would like verification. >>> >>> I'd prefer to simply merge these patches into clk-next, which is the >>> most straightforward route. Any ideas on how to handle the missing >>> AM35xx dtsi data? It can always go as a separate fix after this stuff >>> gets merged which, ironically, is how that file was created in the first >>> place. >> >> I've pushed my branch. Tero can you take a look and let me know if you >> see any problems? >> >> git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap > > Hey Mike, > > Can't see any issues there, also gave it a quick boot test with the > boards I have access to and seems to work fine. > Here are the logs with commit 12d0a30a45e3a85463a6cb2a9e886192e3123892 ( i need an additional patch for legacy platform testing). 1: am335x-evm: http://slexy.org/raw/s215zNjZFv 2: am335x-sk: http://slexy.org/raw/s20uTrPG7V 3: am3517-evm: http://slexy.org/raw/s21XPhGMCt (we should be based on .13-rc4 to get am3517 baseline patches -> So due to the dropped am3517 patch, we stop booting here). 4: am37x-evm: http://slexy.org/raw/s20W2nuCQa 5: am43xx-epos: http://slexy.org/raw/s2I2qc961B (no boot yet) 6:beag-xm: http://slexy.org/raw/s210lX2EvT 7: bone-black: http://slexy.org/raw/s2NgHa78JC (still have the fixed-regulator bug in rc1 so, wont boot to shell at rc1) 8: am3517-crane: http://slexy.org/raw/s2r1Bt4Hk2 (need benoit' for-next to boot) 9: dra7: http://slexy.org/raw/s21UWF0yYd (same fixed regulator issue) 10:ldp: http://slexy.org/raw/s2oWL6qt2t (dts for this is pending merge in Tony's next) 11:panda-es: http://slexy.org/raw/s20NEXs51M 12:sdp2430: http://slexy.org/raw/s21kyDYjfk (dts for this pending in Tony's next) 13:sdp3430: http://slexy.org/raw/s2EYHpcAW0 14:sdp4430: http://slexy.org/raw/s2QPK7cBUP 15: uevm: http://slexy.org/raw/s21mMF6kN3 (same regulator stuff kicks again) am3517-evm is concerning for 14-rc1 boot, am43xx-epos looks concerning too(not sure if there are follow on fixes in later rcs that allow it to boot) - considering that both did work on tests that I did based on next[1], only thing i am concerned in am3517 patch dropped in clk-next-omap. - will be good to get this merged on clk-next and see what we can get results on linux-next tag. [1] http://marc.info/?l=devicetree&m=138930255330882&w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/15/2014 05:50 AM, Mike Turquette wrote: Quoting Mike Turquette (2014-01-14 19:16:32) Quoting Felipe Balbi (2014-01-14 18:04:21) Hi, On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: Felipe, care to run your randconfig magic for this? This branch builds just fine so far, I still have omap5 multiplaform and uniplatform builds, but since that was working before i'm assuming it won't break. No build failures in any of my 18 seeds (5 randconfigs of each), I'd attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can send it. FWIW: Acked-by: Felipe Balbi Felipe, That's great to hear. Thanks for testing. Tero & Tony, These 40 patches apply very cleanly on top of clk-next with 2 exceptions: 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based on 3.13-rc1). 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I resolved correctly but would like verification. I'd prefer to simply merge these patches into clk-next, which is the most straightforward route. Any ideas on how to handle the missing AM35xx dtsi data? It can always go as a separate fix after this stuff gets merged which, ironically, is how that file was created in the first place. I've pushed my branch. Tero can you take a look and let me know if you see any problems? git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap Hey Mike, Can't see any issues there, also gave it a quick boot test with the boards I have access to and seems to work fine. -Tero Thanks! Mike Regards, Mike cheers -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Mike Turquette (2014-01-14 19:16:32) > Quoting Felipe Balbi (2014-01-14 18:04:21) > > Hi, > > > > On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: > > > > Felipe, care to run your randconfig magic for this? > > > > > > This branch builds just fine so far, I still have omap5 multiplaform and > > > uniplatform builds, but since that was working before i'm assuming it > > > won't break. > > > > No build failures in any of my 18 seeds (5 randconfigs of each), I'd > > attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can > > send it. > > > > FWIW: > > > > Acked-by: Felipe Balbi > > Felipe, > > That's great to hear. Thanks for testing. > > Tero & Tony, > > These 40 patches apply very cleanly on top of clk-next with 2 > exceptions: > > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based > on 3.13-rc1). > > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I > resolved correctly but would like verification. > > I'd prefer to simply merge these patches into clk-next, which is the > most straightforward route. Any ideas on how to handle the missing > AM35xx dtsi data? It can always go as a separate fix after this stuff > gets merged which, ironically, is how that file was created in the first > place. I've pushed my branch. Tero can you take a look and let me know if you see any problems? git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap Thanks! Mike > > Regards, > Mike > > > > > cheers > > > > -- > > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Felipe Balbi (2014-01-14 18:04:21) > Hi, > > On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: > > > Felipe, care to run your randconfig magic for this? > > > > This branch builds just fine so far, I still have omap5 multiplaform and > > uniplatform builds, but since that was working before i'm assuming it > > won't break. > > No build failures in any of my 18 seeds (5 randconfigs of each), I'd > attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can > send it. > > FWIW: > > Acked-by: Felipe Balbi Felipe, That's great to hear. Thanks for testing. Tero & Tony, These 40 patches apply very cleanly on top of clk-next with 2 exceptions: 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based on 3.13-rc1). 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I resolved correctly but would like verification. I'd prefer to simply merge these patches into clk-next, which is the most straightforward route. Any ideas on how to handle the missing AM35xx dtsi data? It can always go as a separate fix after this stuff gets merged which, ironically, is how that file was created in the first place. Regards, Mike > > cheers > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Hi, On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: > > Felipe, care to run your randconfig magic for this? > > This branch builds just fine so far, I still have omap5 multiplaform and > uniplatform builds, but since that was working before i'm assuming it > won't break. No build failures in any of my 18 seeds (5 randconfigs of each), I'd attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can send it. FWIW: Acked-by: Felipe Balbi cheers -- balbi signature.asc Description: Digital signature
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On Tue, Jan 14, 2014 at 02:41:40PM +0200, Tero Kristo wrote: > On 01/10/2014 08:51 PM, Tony Lindgren wrote: > >* Tero Kristo [140110 08:32]: > >>On 01/10/2014 06:13 PM, Felipe Balbi wrote: > >>>On Fri, Jan 10, 2014 at 11:52:49AM +0200, Tero Kristo wrote: > On 01/10/2014 01:15 AM, Felipe Balbi wrote: > >On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: > >> > >>conflicts with be changes on Tony's be branch. > >>commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 > >> ARM: OMAP2+: raw read and write endian fix > >> > >>Conflict: > >>arch/arm/mach-omap2/clkt_clksel.c > >>arch/arm/mach-omap2/clkt_dpll.c > >>arch/arm/mach-omap2/clkt_iclk.c > >>arch/arm/mach-omap2/clock.c > >>arch/arm/mach-omap2/clock36xx.c > >>arch/arm/mach-omap2/dpll3xxx.c > >>arch/arm/mach-omap2/dpll44xx.c > >> > >>Both change raw_readls -> should now be just clk api instead which > >>already does readl_relaxed etc.. If Tony feels like, then we should > >>probably post a branch based on 'be' branch for easy merge. > > > >This should be a trivial merge conflict to handle, so let's not base > >things on the BE changes. > > > I think all of these fails are caused by the initially bugged > Makefile + Kconfig under mach-omap2. Seems like they can be fixed by > the patches I inlined at the end (will also post them as proper > patches to l-o list after this.) The question is, should Mike go > ahead and merge these along with the base clk patches or how should > we handle them? Patch 1 must be merged, patch 2 is a nice to have one > which allows DRA7 only builds (doing DRA7 only build currently seems > not possible.) > >>> > >>>If it's OK with Tony, I would suggest having a branch with both patches > >>>below which both Tony and Mike merge before merging CCF series. That way > >>>we avoid bisection problems. > > > >I can queue those two separately as fixes. > > > >>That reminds me, I think the baseline branch for the mach-omap2 > >>patches is still somewhat unclear to me, what should be used for > >>this? And which patches should be put there (the mach-omap2 patches > >>depend on the drivers/clk/ti part basically, so I need to put at > >>least those there also.) > > > >I would keep the clock patches against some mainline -rc commit if > >possible, and if there are non trivial merge conflicts, the omap > >to use as the base is commit adfe9361b236154215d4b0fc8b6d79995394b15c. > > > >In any case, it's probably best that Mike merges this all via his > >clock tree unless there non-trivial merge conflicts. > > > > I just pushed a branch against rc7 with makefile fixes in place to > fix omap1 and omap2 only builds for this stuff. Inlined the delta > here at the end. Do you want me to repost the series as v14 for this > or is the attached delta ok for review purposes? All the changes have > been squashed to existing patches (except the 2 patches I posted > separately for DRA7xx / AM43xx only builds.) > > The test branch itself can be found here: > > tree: https://github.com/t-kristo/linux-pm.git > branch: 3.13-rc7-dt-clks-v13-build-fixes > > Felipe, care to run your randconfig magic for this? This branch builds just fine so far, I still have omap5 multiplaform and uniplatform builds, but since that was working before i'm assuming it won't break. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/10/2014 08:51 PM, Tony Lindgren wrote: * Tero Kristo [140110 08:32]: On 01/10/2014 06:13 PM, Felipe Balbi wrote: On Fri, Jan 10, 2014 at 11:52:49AM +0200, Tero Kristo wrote: On 01/10/2014 01:15 AM, Felipe Balbi wrote: On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: conflicts with be changes on Tony's be branch. commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 ARM: OMAP2+: raw read and write endian fix Conflict: arch/arm/mach-omap2/clkt_clksel.c arch/arm/mach-omap2/clkt_dpll.c arch/arm/mach-omap2/clkt_iclk.c arch/arm/mach-omap2/clock.c arch/arm/mach-omap2/clock36xx.c arch/arm/mach-omap2/dpll3xxx.c arch/arm/mach-omap2/dpll44xx.c Both change raw_readls -> should now be just clk api instead which already does readl_relaxed etc.. If Tony feels like, then we should probably post a branch based on 'be' branch for easy merge. This should be a trivial merge conflict to handle, so let's not base things on the BE changes. I think all of these fails are caused by the initially bugged Makefile + Kconfig under mach-omap2. Seems like they can be fixed by the patches I inlined at the end (will also post them as proper patches to l-o list after this.) The question is, should Mike go ahead and merge these along with the base clk patches or how should we handle them? Patch 1 must be merged, patch 2 is a nice to have one which allows DRA7 only builds (doing DRA7 only build currently seems not possible.) If it's OK with Tony, I would suggest having a branch with both patches below which both Tony and Mike merge before merging CCF series. That way we avoid bisection problems. I can queue those two separately as fixes. That reminds me, I think the baseline branch for the mach-omap2 patches is still somewhat unclear to me, what should be used for this? And which patches should be put there (the mach-omap2 patches depend on the drivers/clk/ti part basically, so I need to put at least those there also.) I would keep the clock patches against some mainline -rc commit if possible, and if there are non trivial merge conflicts, the omap to use as the base is commit adfe9361b236154215d4b0fc8b6d79995394b15c. In any case, it's probably best that Mike merges this all via his clock tree unless there non-trivial merge conflicts. I just pushed a branch against rc7 with makefile fixes in place to fix omap1 and omap2 only builds for this stuff. Inlined the delta here at the end. Do you want me to repost the series as v14 for this or is the attached delta ok for review purposes? All the changes have been squashed to existing patches (except the 2 patches I posted separately for DRA7xx / AM43xx only builds.) The test branch itself can be found here: tree: https://github.com/t-kristo/linux-pm.git branch: 3.13-rc7-dt-clks-v13-build-fixes Felipe, care to run your randconfig magic for this? -Tero diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index dc21df1..e65948a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -76,6 +76,16 @@ config SOC_AM43XX select ARM_GIC select MACH_OMAP_GENERIC +config SOC_DRA7XX + bool "TI DRA7XX" + depends on ARCH_MULTI_V7 + select ARCH_OMAP2PLUS + select ARM_CPU_SUSPEND if PM + select ARM_GIC + select CPU_V7 + select HAVE_SMP + select HAVE_ARM_ARCH_TIMER + config ARCH_OMAP2PLUS bool select ARCH_HAS_BANDGAP @@ -128,14 +138,6 @@ config SOC_HAS_REALTIME_COUNTER depends on SOC_OMAP5 || SOC_DRA7XX default y -config SOC_DRA7XX - bool "TI DRA7XX" - select ARM_ARCH_TIMER - select CPU_V7 - select ARM_GIC - select HAVE_SMP - select COMMON_CLK - comment "OMAP Core Type" depends on ARCH_OMAP2 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 088305f..8ebe9f3 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -132,6 +132,7 @@ obj-$(CONFIG_SOC_AM33XX)+= $(voltagedomain-common) obj-$(CONFIG_SOC_AM43XX) += $(voltagedomain-common) obj-$(CONFIG_SOC_OMAP5)+= $(voltagedomain-common) obj-$(CONFIG_SOC_OMAP5)+= voltagedomains54xx_data.o +obj-$(CONFIG_SOC_DRA7XX) += $(voltagedomain-common) # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o @@ -191,6 +192,9 @@ obj-$(CONFIG_ARCH_OMAP4)+= dpll3xxx.o dpll44xx.o obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX) += $(clock-common) +obj-$(CONFIG_SOC_DRA7XX) += dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_AM43XX) += $(clock-common) dpll3xxx.o # OMAP2 clock rate set data (old "OPP" data) obj-$(CONFIG_S
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/11/2014 06:35 PM, Joachim Eastwood wrote: On 9 January 2014 15:00, Tero Kristo wrote: Hi, So, bad luck number release for this, as v12 wasn't sufficient still. Changes compared to previous version: - Dropped any changes to generic clock drivers, as it seems impossible to agree anything in short term, this means the patch set shrank in size from 49 patches to 40 (first 9 patches were dropped). - Copy pasted implementation for clk-divider and clk-mux from drivers/clk to drivers/clk/ti, and made the modifications needed to the TI version of the clock drivers only (based on discussions with Mike, this is fine) - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict with any generic implementation we might have at some point, migrating this to the generic version should be easy enough also. - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous versions and resulted into an orphan clock node - Fixed compile problem for omap5 only build reported by Felipe - Fixed a couple of sparse warnings - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed instead of __raw_readl / __raw_writel Testing done: - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) - omap4-panda-es: boot / suspend-resume (RET) - omap5-uevm: boot - am335x-bone: boot - dra7-evm: boot Maintainer friendly branches also available: tree: https://github.com/t-kristo/linux-pm.git clk driver only (Mike): clk-next-dt-clks-v13 DTS data only (Benoit): dts_for_3.14-dt-clks-v13 full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 I tested 3.13-rc7-dt-clks-v13 on top of a next branch I am working on with a OMAP4460 and it's working fine. A couple of things I noticed in the boot log: [ 0.00] ti_dt_clocks_register: failed to lookup clock node bandgap_fclk [ 0.00] smp_twd: clock not found -2 I am get the bandgap_fclk clock lookup fail since it doesn't exist on 4460 and I guess the bandgap_ts_fclk clock will fail the same way on 4430. So maybe you need to differentiate between 4460 and 4430 in clk-44xx.c to get rid of this warning. Yeah thats true. I was kind of lazy with the omap4 clk file (these are supposed to be temporary anyway until we can get rid of the clock aliases through proper driver DT mappings), and didn't separate omap4430 vs omap4460 there. If this print needs to go away, we need to do this similarly to what was done with different omap3 versions (the clock data delta is much more larger there), but the additional code needed for this was rather large for the minimal impact... we would need separate board files, separate io.c setups, and logic within the clk-44xx.c file itself. Just to re-phrase it, this doesn't impact functionality, the resultant clock nodes etc. are exactly the same before-and-after this set, the kernel just tries to register one additional clock alias which it can't find and prints the single line out. -Tero As for the smp_twd clock I assume we can add "clocks = <&mpu_periphclk>" to local-timer@48240600 in omap4.dtsi to get rid of the warning. I can cook up a patch here if it is the right thing to do. I think the smp_twd warning existed before I applied this patch set. regards Joachim Eastwood -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Tero Kristo [140111 01:56]: > On 01/10/2014 08:53 PM, Tony Lindgren wrote: > >* Mike Turquette [140109 14:25]: > >>Quoting Tero Kristo (2014-01-09 06:00:11) > >>>Hi, > >>> > >>>So, bad luck number release for this, as v12 wasn't sufficient still. > >>> > >>>Changes compared to previous version: > >>>- Dropped any changes to generic clock drivers, as it seems impossible > >>> to agree anything in short term, this means the patch set shrank in > >>> size from 49 patches to 40 (first 9 patches were dropped). > >>>- Copy pasted implementation for clk-divider and clk-mux from drivers/clk > >>> to drivers/clk/ti, and made the modifications needed to the TI version > >>> of the clock drivers only (based on discussions with Mike, this is fine) > >>>- Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict > >>> with any generic implementation we might have at some point, migrating > >>> this to the generic version should be easy enough also. > >>>- Fixed trace_clk_div_div_ck for omap4, this node was broken in previous > >>> versions and resulted into an orphan clock node > >>>- Fixed compile problem for omap5 only build reported by Felipe > >>>- Fixed a couple of sparse warnings > >>>- changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed > >>> instead of __raw_readl / __raw_writel > >> > >>Hi Tero, > >> > >>This approach takes care of all of my concerns with this series. Thanks > >>for your long suffering patience on it. > >> > >>It seems some build errors are cropping up, so once those are fixed then > >>I'll be happy to merge clk-next-dt-clks-v13 into clk-next for 3.14. > > > >I'm fine with Mike merging these all via the clock tree assuming no more > >pending comments. For the patches changed from the last time around, > >please feel free to add: > > > >Acked-by: Tony Lindgren > > How about the dts data patches? Should these also go via Mike's > tree? Otherwise we will have boot failures until the dts patches are > merged. Yes I think that's the way to go, they mostly add new files so there should not be major conflicts. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 9 January 2014 15:00, Tero Kristo wrote: > Hi, > > So, bad luck number release for this, as v12 wasn't sufficient still. > > Changes compared to previous version: > - Dropped any changes to generic clock drivers, as it seems impossible > to agree anything in short term, this means the patch set shrank in > size from 49 patches to 40 (first 9 patches were dropped). > - Copy pasted implementation for clk-divider and clk-mux from drivers/clk > to drivers/clk/ti, and made the modifications needed to the TI version > of the clock drivers only (based on discussions with Mike, this is fine) > - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict > with any generic implementation we might have at some point, migrating > this to the generic version should be easy enough also. > - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous > versions and resulted into an orphan clock node > - Fixed compile problem for omap5 only build reported by Felipe > - Fixed a couple of sparse warnings > - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed > instead of __raw_readl / __raw_writel > > Testing done: > - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) > - omap4-panda-es: boot / suspend-resume (RET) > - omap5-uevm: boot > - am335x-bone: boot > - dra7-evm: boot > > Maintainer friendly branches also available: > > tree: https://github.com/t-kristo/linux-pm.git > > clk driver only (Mike): clk-next-dt-clks-v13 > DTS data only (Benoit): dts_for_3.14-dt-clks-v13 > full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 I tested 3.13-rc7-dt-clks-v13 on top of a next branch I am working on with a OMAP4460 and it's working fine. A couple of things I noticed in the boot log: [ 0.00] ti_dt_clocks_register: failed to lookup clock node bandgap_fclk [ 0.00] smp_twd: clock not found -2 I am get the bandgap_fclk clock lookup fail since it doesn't exist on 4460 and I guess the bandgap_ts_fclk clock will fail the same way on 4430. So maybe you need to differentiate between 4460 and 4430 in clk-44xx.c to get rid of this warning. As for the smp_twd clock I assume we can add "clocks = <&mpu_periphclk>" to local-timer@48240600 in omap4.dtsi to get rid of the warning. I can cook up a patch here if it is the right thing to do. I think the smp_twd warning existed before I applied this patch set. regards Joachim Eastwood -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/10/2014 08:53 PM, Tony Lindgren wrote: * Mike Turquette [140109 14:25]: Quoting Tero Kristo (2014-01-09 06:00:11) Hi, So, bad luck number release for this, as v12 wasn't sufficient still. Changes compared to previous version: - Dropped any changes to generic clock drivers, as it seems impossible to agree anything in short term, this means the patch set shrank in size from 49 patches to 40 (first 9 patches were dropped). - Copy pasted implementation for clk-divider and clk-mux from drivers/clk to drivers/clk/ti, and made the modifications needed to the TI version of the clock drivers only (based on discussions with Mike, this is fine) - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict with any generic implementation we might have at some point, migrating this to the generic version should be easy enough also. - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous versions and resulted into an orphan clock node - Fixed compile problem for omap5 only build reported by Felipe - Fixed a couple of sparse warnings - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed instead of __raw_readl / __raw_writel Hi Tero, This approach takes care of all of my concerns with this series. Thanks for your long suffering patience on it. It seems some build errors are cropping up, so once those are fixed then I'll be happy to merge clk-next-dt-clks-v13 into clk-next for 3.14. I'm fine with Mike merging these all via the clock tree assuming no more pending comments. For the patches changed from the last time around, please feel free to add: Acked-by: Tony Lindgren How about the dts data patches? Should these also go via Mike's tree? Otherwise we will have boot failures until the dts patches are merged. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Mike Turquette [140109 14:25]: > Quoting Tero Kristo (2014-01-09 06:00:11) > > Hi, > > > > So, bad luck number release for this, as v12 wasn't sufficient still. > > > > Changes compared to previous version: > > - Dropped any changes to generic clock drivers, as it seems impossible > > to agree anything in short term, this means the patch set shrank in > > size from 49 patches to 40 (first 9 patches were dropped). > > - Copy pasted implementation for clk-divider and clk-mux from drivers/clk > > to drivers/clk/ti, and made the modifications needed to the TI version > > of the clock drivers only (based on discussions with Mike, this is fine) > > - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict > > with any generic implementation we might have at some point, migrating > > this to the generic version should be easy enough also. > > - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous > > versions and resulted into an orphan clock node > > - Fixed compile problem for omap5 only build reported by Felipe > > - Fixed a couple of sparse warnings > > - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed > > instead of __raw_readl / __raw_writel > > Hi Tero, > > This approach takes care of all of my concerns with this series. Thanks > for your long suffering patience on it. > > It seems some build errors are cropping up, so once those are fixed then > I'll be happy to merge clk-next-dt-clks-v13 into clk-next for 3.14. I'm fine with Mike merging these all via the clock tree assuming no more pending comments. For the patches changed from the last time around, please feel free to add: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Tero Kristo [140110 08:32]: > On 01/10/2014 06:13 PM, Felipe Balbi wrote: > >On Fri, Jan 10, 2014 at 11:52:49AM +0200, Tero Kristo wrote: > >>On 01/10/2014 01:15 AM, Felipe Balbi wrote: > >>>On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: > > conflicts with be changes on Tony's be branch. > commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 > ARM: OMAP2+: raw read and write endian fix > > Conflict: > arch/arm/mach-omap2/clkt_clksel.c > arch/arm/mach-omap2/clkt_dpll.c > arch/arm/mach-omap2/clkt_iclk.c > arch/arm/mach-omap2/clock.c > arch/arm/mach-omap2/clock36xx.c > arch/arm/mach-omap2/dpll3xxx.c > arch/arm/mach-omap2/dpll44xx.c > > Both change raw_readls -> should now be just clk api instead which > already does readl_relaxed etc.. If Tony feels like, then we should > probably post a branch based on 'be' branch for easy merge. This should be a trivial merge conflict to handle, so let's not base things on the BE changes. > >>I think all of these fails are caused by the initially bugged > >>Makefile + Kconfig under mach-omap2. Seems like they can be fixed by > >>the patches I inlined at the end (will also post them as proper > >>patches to l-o list after this.) The question is, should Mike go > >>ahead and merge these along with the base clk patches or how should > >>we handle them? Patch 1 must be merged, patch 2 is a nice to have one > >>which allows DRA7 only builds (doing DRA7 only build currently seems > >>not possible.) > > > >If it's OK with Tony, I would suggest having a branch with both patches > >below which both Tony and Mike merge before merging CCF series. That way > >we avoid bisection problems. I can queue those two separately as fixes. > That reminds me, I think the baseline branch for the mach-omap2 > patches is still somewhat unclear to me, what should be used for > this? And which patches should be put there (the mach-omap2 patches > depend on the drivers/clk/ti part basically, so I need to put at > least those there also.) I would keep the clock patches against some mainline -rc commit if possible, and if there are non trivial merge conflicts, the omap to use as the base is commit adfe9361b236154215d4b0fc8b6d79995394b15c. In any case, it's probably best that Mike merges this all via his clock tree unless there non-trivial merge conflicts. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/10/2014 06:13 PM, Felipe Balbi wrote: Hi, On Fri, Jan 10, 2014 at 11:52:49AM +0200, Tero Kristo wrote: On 01/10/2014 01:15 AM, Felipe Balbi wrote: Hi, On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: So, bad luck number release for this, as v12 wasn't sufficient still. Changes compared to previous version: - Dropped any changes to generic clock drivers, as it seems impossible to agree anything in short term, this means the patch set shrank in size from 49 patches to 40 (first 9 patches were dropped). - Copy pasted implementation for clk-divider and clk-mux from drivers/clk to drivers/clk/ti, and made the modifications needed to the TI version of the clock drivers only (based on discussions with Mike, this is fine) - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict with any generic implementation we might have at some point, migrating this to the generic version should be easy enough also. - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous versions and resulted into an orphan clock node - Fixed compile problem for omap5 only build reported by Felipe - Fixed a couple of sparse warnings - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed instead of __raw_readl / __raw_writel Testing done: - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) - omap4-panda-es: boot / suspend-resume (RET) - omap5-uevm: boot - am335x-bone: boot - dra7-evm: boot Maintainer friendly branches also available: tree: https://github.com/t-kristo/linux-pm.git clk driver only (Mike): clk-next-dt-clks-v13 DTS data only (Benoit): dts_for_3.14-dt-clks-v13 full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 -Tero Maintainer branches conflicts (using 3.13-rc7-dt-clks-v13): = Conflict resolution during rebase to maintainer's -14 branches: 1. (trivial) Against mike's clk-next dbdf6ff Merge branch 'clk-next-unregister' into clk-next Could not apply 2edf7ad... CLK: TI: add DT alias clock registration mechanism conflict drivers/clk/Makefile (trivial fix) 2. (manual, but changes are easy) Against Tony's omap-for-v3.14/be fc6ca98 ARM: OMAP: debug-leds: raw read and write endian fix ARM: OMAP2+: clock: use driver API instead of direct memory read/write conflicts with be changes on Tony's be branch. commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 ARM: OMAP2+: raw read and write endian fix Conflict: arch/arm/mach-omap2/clkt_clksel.c arch/arm/mach-omap2/clkt_dpll.c arch/arm/mach-omap2/clkt_iclk.c arch/arm/mach-omap2/clock.c arch/arm/mach-omap2/clock36xx.c arch/arm/mach-omap2/dpll3xxx.c arch/arm/mach-omap2/dpll44xx.c Both change raw_readls -> should now be just clk api instead which already does readl_relaxed etc.. If Tony feels like, then we should probably post a branch based on 'be' branch for easy merge. 3. I could not detect any merge conflict against Benoit's queued up series (but maybe he has'nt pushed everything to remote tree).. Patch verification report: == Report: http://pastebin.mozilla.org/3976492 * sparse warning added in [PATCH 06/40] CLK: ti: add support for ti divider-clock, [PATCH 10/40] clk: ti: add support for basic mux clock +drivers/clk/ti/divider.c: warning: context imbalance in 'ti_clk_divider_set_rate' - different lock contexts for basic block +drivers/clk/ti/mux.c: warning: context imbalance in 'ti_clk_mux_set_parent' - different lock contexts for basic block * checkpatch warning [PATCH 16/40] CLK: TI: add am33xx clock init file, [PATCH 18/40] CLK: TI: add omap3 clock init file WARNING: static const char * array should probably be static const char * const Boot reports: = - previous orphan clocks seem solved. - All available platforms seem to boot fine and no regression could be seen on initial view OMAP2430: 1. SDP2430 before: http://pastebin.mozilla.org/3976359 after: http://pastebin.mozilla.org/3976467 AM335x: 2. am335x-evm before: http://pastebin.mozilla.org/3976284 after: http://pastebin.mozilla.org/3976374 3. am335x-sk before: http://pastebin.mozilla.org/3976295 after: http://pastebin.mozilla.org/3976375 4. BeagleBone Black: before: http://pastebin.mozilla.org/3976321 after: http://pastebin.mozilla.org/3976441 AM3517: 5. am3517-evm before: http://pastebin.mozilla.org/3976297 after: http://pastebin.mozilla.org/3976397 6. craneboard before: http://pastebin.mozilla.org/3976322 after: http://pastebin.mozilla.org/3976452 OMAP3430: 7. ldp before: http://pastebin.mozilla.org/3976356 after: http://pastebin.mozilla.org/3976455 8. sdp3430 before: http://pastebin.mozilla.org/3976360 after: http://pastebin.mozilla.org/3976468 OMAP3630/DM3730: 9. am37x-evm before: http://pastebin.mozilla.org/3976300 after: http://pastebin.mozilla.org/3976398 10. beagle-XM before: http://pastebin.mozilla.org/397
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Hi, On Fri, Jan 10, 2014 at 11:52:49AM +0200, Tero Kristo wrote: > On 01/10/2014 01:15 AM, Felipe Balbi wrote: > >Hi, > > > >On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: > >>>So, bad luck number release for this, as v12 wasn't sufficient still. > >>> > >>>Changes compared to previous version: > >>>- Dropped any changes to generic clock drivers, as it seems impossible > >>> to agree anything in short term, this means the patch set shrank in > >>> size from 49 patches to 40 (first 9 patches were dropped). > >>>- Copy pasted implementation for clk-divider and clk-mux from drivers/clk > >>> to drivers/clk/ti, and made the modifications needed to the TI version > >>> of the clock drivers only (based on discussions with Mike, this is fine) > >>>- Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict > >>> with any generic implementation we might have at some point, migrating > >>> this to the generic version should be easy enough also. > >>>- Fixed trace_clk_div_div_ck for omap4, this node was broken in previous > >>> versions and resulted into an orphan clock node > >>>- Fixed compile problem for omap5 only build reported by Felipe > >>>- Fixed a couple of sparse warnings > >>>- changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed > >>> instead of __raw_readl / __raw_writel > >>> > >>>Testing done: > >>>- omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) > >>>- omap4-panda-es: boot / suspend-resume (RET) > >>>- omap5-uevm: boot > >>>- am335x-bone: boot > >>>- dra7-evm: boot > >>> > >>>Maintainer friendly branches also available: > >>> > >>>tree: https://github.com/t-kristo/linux-pm.git > >>> > >>>clk driver only (Mike): clk-next-dt-clks-v13 > >>>DTS data only (Benoit): dts_for_3.14-dt-clks-v13 > >>>full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 > >>> > >>>-Tero > >>> > >> > >>Maintainer branches conflicts (using 3.13-rc7-dt-clks-v13): > >>= > >>Conflict resolution during rebase to maintainer's -14 branches: > >> > >>1. (trivial) Against mike's clk-next dbdf6ff Merge branch > >>'clk-next-unregister' into clk-next > >> > >>Could not apply 2edf7ad... CLK: TI: add DT alias clock registration > >>mechanism > >>conflict drivers/clk/Makefile (trivial fix) > >> > >>2. (manual, but changes are easy) Against Tony's omap-for-v3.14/be > >>fc6ca98 ARM: OMAP: debug-leds: raw read and write endian fix > >> > >>ARM: OMAP2+: clock: use driver API instead of direct memory read/write > >> > >>conflicts with be changes on Tony's be branch. > >>commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 > >> ARM: OMAP2+: raw read and write endian fix > >> > >>Conflict: > >>arch/arm/mach-omap2/clkt_clksel.c > >>arch/arm/mach-omap2/clkt_dpll.c > >>arch/arm/mach-omap2/clkt_iclk.c > >>arch/arm/mach-omap2/clock.c > >>arch/arm/mach-omap2/clock36xx.c > >>arch/arm/mach-omap2/dpll3xxx.c > >>arch/arm/mach-omap2/dpll44xx.c > >> > >>Both change raw_readls -> should now be just clk api instead which > >>already does readl_relaxed etc.. If Tony feels like, then we should > >>probably post a branch based on 'be' branch for easy merge. > >> > >>3. I could not detect any merge conflict against Benoit's queued up > >>series (but maybe he has'nt pushed everything to remote tree).. > >> > >> > >>Patch verification report: > >>== > >>Report: http://pastebin.mozilla.org/3976492 > >> > >> > >>* sparse warning added in [PATCH 06/40] CLK: ti: add support for ti > >>divider-clock, [PATCH 10/40] clk: ti: add support for basic mux clock > >>+drivers/clk/ti/divider.c: warning: context imbalance in > >>'ti_clk_divider_set_rate' - different lock contexts for basic block > >>+drivers/clk/ti/mux.c: warning: context imbalance in > >>'ti_clk_mux_set_parent' - different lock contexts for basic block > >> > >>* checkpatch warning [PATCH 16/40] CLK: TI: add am33xx clock init > >>file, [PATCH 18/40] CLK: TI: add omap3 clock init file > >>WARNING: static const char * array should probably be static const > >>char * const > >> > >> > >>Boot reports: > >>= > >>- previous orphan clocks seem solved. > >>- All available platforms seem to boot fine and no regression could be > >>seen on initial view > >> > >>OMAP2430: > >> 1. SDP2430 > >> before: http://pastebin.mozilla.org/3976359 > >> after: http://pastebin.mozilla.org/3976467 > >> > >>AM335x: > >> 2. am335x-evm > >> before: http://pastebin.mozilla.org/3976284 > >> after: http://pastebin.mozilla.org/3976374 > >> 3. am335x-sk > >> before: http://pastebin.mozilla.org/3976295 > >> after: http://pastebin.mozilla.org/3976375 > >> 4. BeagleBone Black: > >> before: http://pastebin.mozilla.org/3976321 > >> after: http://pastebin.mozilla.org/3976441 > >> > >>AM3517: > >> 5. am3517-evm > >> before: http://pastebin.mozilla.org/3976297 > >> after: http://pastebin.mozilla.org/3976397 > >> 6. craneboard > >> before: http://pastebin.mozilla.org/
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/10/2014 01:15 AM, Felipe Balbi wrote: Hi, On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: So, bad luck number release for this, as v12 wasn't sufficient still. Changes compared to previous version: - Dropped any changes to generic clock drivers, as it seems impossible to agree anything in short term, this means the patch set shrank in size from 49 patches to 40 (first 9 patches were dropped). - Copy pasted implementation for clk-divider and clk-mux from drivers/clk to drivers/clk/ti, and made the modifications needed to the TI version of the clock drivers only (based on discussions with Mike, this is fine) - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict with any generic implementation we might have at some point, migrating this to the generic version should be easy enough also. - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous versions and resulted into an orphan clock node - Fixed compile problem for omap5 only build reported by Felipe - Fixed a couple of sparse warnings - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed instead of __raw_readl / __raw_writel Testing done: - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) - omap4-panda-es: boot / suspend-resume (RET) - omap5-uevm: boot - am335x-bone: boot - dra7-evm: boot Maintainer friendly branches also available: tree: https://github.com/t-kristo/linux-pm.git clk driver only (Mike): clk-next-dt-clks-v13 DTS data only (Benoit): dts_for_3.14-dt-clks-v13 full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 -Tero Maintainer branches conflicts (using 3.13-rc7-dt-clks-v13): = Conflict resolution during rebase to maintainer's -14 branches: 1. (trivial) Against mike's clk-next dbdf6ff Merge branch 'clk-next-unregister' into clk-next Could not apply 2edf7ad... CLK: TI: add DT alias clock registration mechanism conflict drivers/clk/Makefile (trivial fix) 2. (manual, but changes are easy) Against Tony's omap-for-v3.14/be fc6ca98 ARM: OMAP: debug-leds: raw read and write endian fix ARM: OMAP2+: clock: use driver API instead of direct memory read/write conflicts with be changes on Tony's be branch. commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 ARM: OMAP2+: raw read and write endian fix Conflict: arch/arm/mach-omap2/clkt_clksel.c arch/arm/mach-omap2/clkt_dpll.c arch/arm/mach-omap2/clkt_iclk.c arch/arm/mach-omap2/clock.c arch/arm/mach-omap2/clock36xx.c arch/arm/mach-omap2/dpll3xxx.c arch/arm/mach-omap2/dpll44xx.c Both change raw_readls -> should now be just clk api instead which already does readl_relaxed etc.. If Tony feels like, then we should probably post a branch based on 'be' branch for easy merge. 3. I could not detect any merge conflict against Benoit's queued up series (but maybe he has'nt pushed everything to remote tree).. Patch verification report: == Report: http://pastebin.mozilla.org/3976492 * sparse warning added in [PATCH 06/40] CLK: ti: add support for ti divider-clock, [PATCH 10/40] clk: ti: add support for basic mux clock +drivers/clk/ti/divider.c: warning: context imbalance in 'ti_clk_divider_set_rate' - different lock contexts for basic block +drivers/clk/ti/mux.c: warning: context imbalance in 'ti_clk_mux_set_parent' - different lock contexts for basic block * checkpatch warning [PATCH 16/40] CLK: TI: add am33xx clock init file, [PATCH 18/40] CLK: TI: add omap3 clock init file WARNING: static const char * array should probably be static const char * const Boot reports: = - previous orphan clocks seem solved. - All available platforms seem to boot fine and no regression could be seen on initial view OMAP2430: 1. SDP2430 before: http://pastebin.mozilla.org/3976359 after: http://pastebin.mozilla.org/3976467 AM335x: 2. am335x-evm before: http://pastebin.mozilla.org/3976284 after: http://pastebin.mozilla.org/3976374 3. am335x-sk before: http://pastebin.mozilla.org/3976295 after: http://pastebin.mozilla.org/3976375 4. BeagleBone Black: before: http://pastebin.mozilla.org/3976321 after: http://pastebin.mozilla.org/3976441 AM3517: 5. am3517-evm before: http://pastebin.mozilla.org/3976297 after: http://pastebin.mozilla.org/3976397 6. craneboard before: http://pastebin.mozilla.org/3976322 after: http://pastebin.mozilla.org/3976452 OMAP3430: 7. ldp before: http://pastebin.mozilla.org/3976356 after: http://pastebin.mozilla.org/3976455 8. sdp3430 before: http://pastebin.mozilla.org/3976360 after: http://pastebin.mozilla.org/3976468 OMAP3630/DM3730: 9. am37x-evm before: http://pastebin.mozilla.org/3976300 after: http://pastebin.mozilla.org/3976398 10. beagle-XM before: http://pastebin.mozilla.org/3976319 after: http://pastebin.mozilla.org/3976440 OMAP4430: 11. SDP4430 before: http://pastebin.mozi
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Hi, On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote: > > So, bad luck number release for this, as v12 wasn't sufficient still. > > > > Changes compared to previous version: > > - Dropped any changes to generic clock drivers, as it seems impossible > > to agree anything in short term, this means the patch set shrank in > > size from 49 patches to 40 (first 9 patches were dropped). > > - Copy pasted implementation for clk-divider and clk-mux from drivers/clk > > to drivers/clk/ti, and made the modifications needed to the TI version > > of the clock drivers only (based on discussions with Mike, this is fine) > > - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict > > with any generic implementation we might have at some point, migrating > > this to the generic version should be easy enough also. > > - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous > > versions and resulted into an orphan clock node > > - Fixed compile problem for omap5 only build reported by Felipe > > - Fixed a couple of sparse warnings > > - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed > > instead of __raw_readl / __raw_writel > > > > Testing done: > > - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) > > - omap4-panda-es: boot / suspend-resume (RET) > > - omap5-uevm: boot > > - am335x-bone: boot > > - dra7-evm: boot > > > > Maintainer friendly branches also available: > > > > tree: https://github.com/t-kristo/linux-pm.git > > > > clk driver only (Mike): clk-next-dt-clks-v13 > > DTS data only (Benoit): dts_for_3.14-dt-clks-v13 > > full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 > > > > -Tero > > > > Maintainer branches conflicts (using 3.13-rc7-dt-clks-v13): > = > Conflict resolution during rebase to maintainer's -14 branches: > > 1. (trivial) Against mike's clk-next dbdf6ff Merge branch > 'clk-next-unregister' into clk-next > > Could not apply 2edf7ad... CLK: TI: add DT alias clock registration > mechanism > conflict drivers/clk/Makefile (trivial fix) > > 2. (manual, but changes are easy) Against Tony's omap-for-v3.14/be > fc6ca98 ARM: OMAP: debug-leds: raw read and write endian fix > > ARM: OMAP2+: clock: use driver API instead of direct memory read/write > > conflicts with be changes on Tony's be branch. > commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 > ARM: OMAP2+: raw read and write endian fix > > Conflict: > arch/arm/mach-omap2/clkt_clksel.c > arch/arm/mach-omap2/clkt_dpll.c > arch/arm/mach-omap2/clkt_iclk.c > arch/arm/mach-omap2/clock.c > arch/arm/mach-omap2/clock36xx.c > arch/arm/mach-omap2/dpll3xxx.c > arch/arm/mach-omap2/dpll44xx.c > > Both change raw_readls -> should now be just clk api instead which > already does readl_relaxed etc.. If Tony feels like, then we should > probably post a branch based on 'be' branch for easy merge. > > 3. I could not detect any merge conflict against Benoit's queued up > series (but maybe he has'nt pushed everything to remote tree).. > > > Patch verification report: > == > Report: http://pastebin.mozilla.org/3976492 > > > * sparse warning added in [PATCH 06/40] CLK: ti: add support for ti > divider-clock, [PATCH 10/40] clk: ti: add support for basic mux clock > +drivers/clk/ti/divider.c: warning: context imbalance in > 'ti_clk_divider_set_rate' - different lock contexts for basic block > +drivers/clk/ti/mux.c: warning: context imbalance in > 'ti_clk_mux_set_parent' - different lock contexts for basic block > > * checkpatch warning [PATCH 16/40] CLK: TI: add am33xx clock init > file, [PATCH 18/40] CLK: TI: add omap3 clock init file > WARNING: static const char * array should probably be static const > char * const > > > Boot reports: > = > - previous orphan clocks seem solved. > - All available platforms seem to boot fine and no regression could be > seen on initial view > > OMAP2430: > 1. SDP2430 > before: http://pastebin.mozilla.org/3976359 > after: http://pastebin.mozilla.org/3976467 > > AM335x: > 2. am335x-evm > before: http://pastebin.mozilla.org/3976284 > after: http://pastebin.mozilla.org/3976374 > 3. am335x-sk > before: http://pastebin.mozilla.org/3976295 > after: http://pastebin.mozilla.org/3976375 > 4. BeagleBone Black: > before: http://pastebin.mozilla.org/3976321 > after: http://pastebin.mozilla.org/3976441 > > AM3517: > 5. am3517-evm > before: http://pastebin.mozilla.org/3976297 > after: http://pastebin.mozilla.org/3976397 > 6. craneboard > before: http://pastebin.mozilla.org/3976322 > after: http://pastebin.mozilla.org/3976452 > > OMAP3430: > 7. ldp > before: http://pastebin.mozilla.org/3976356 > after: http://pastebin.mozilla.org/3976455 > 8. sdp3430 > before: http://pastebin.mozilla.org/3976360 > after: http://pastebin.mozilla.org/3976468 > > OMAP3630/DM3730: > 9. am37x-evm > before: ht
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Tero Kristo (2014-01-09 06:00:11) > Hi, > > So, bad luck number release for this, as v12 wasn't sufficient still. > > Changes compared to previous version: > - Dropped any changes to generic clock drivers, as it seems impossible > to agree anything in short term, this means the patch set shrank in > size from 49 patches to 40 (first 9 patches were dropped). > - Copy pasted implementation for clk-divider and clk-mux from drivers/clk > to drivers/clk/ti, and made the modifications needed to the TI version > of the clock drivers only (based on discussions with Mike, this is fine) > - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict > with any generic implementation we might have at some point, migrating > this to the generic version should be easy enough also. > - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous > versions and resulted into an orphan clock node > - Fixed compile problem for omap5 only build reported by Felipe > - Fixed a couple of sparse warnings > - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed > instead of __raw_readl / __raw_writel Hi Tero, This approach takes care of all of my concerns with this series. Thanks for your long suffering patience on it. It seems some build errors are cropping up, so once those are fixed then I'll be happy to merge clk-next-dt-clks-v13 into clk-next for 3.14. Regards, Mike > > Testing done: > - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) > - omap4-panda-es: boot / suspend-resume (RET) > - omap5-uevm: boot > - am335x-bone: boot > - dra7-evm: boot > > Maintainer friendly branches also available: > > tree: https://github.com/t-kristo/linux-pm.git > > clk driver only (Mike): clk-next-dt-clks-v13 > DTS data only (Benoit): dts_for_3.14-dt-clks-v13 > full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 > > -Tero > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/09/2014 08:00 AM, Tero Kristo wrote: > Hi, > > So, bad luck number release for this, as v12 wasn't sufficient still. > > Changes compared to previous version: > - Dropped any changes to generic clock drivers, as it seems impossible > to agree anything in short term, this means the patch set shrank in > size from 49 patches to 40 (first 9 patches were dropped). > - Copy pasted implementation for clk-divider and clk-mux from drivers/clk > to drivers/clk/ti, and made the modifications needed to the TI version > of the clock drivers only (based on discussions with Mike, this is fine) > - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict > with any generic implementation we might have at some point, migrating > this to the generic version should be easy enough also. > - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous > versions and resulted into an orphan clock node > - Fixed compile problem for omap5 only build reported by Felipe > - Fixed a couple of sparse warnings > - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed > instead of __raw_readl / __raw_writel > > Testing done: > - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) > - omap4-panda-es: boot / suspend-resume (RET) > - omap5-uevm: boot > - am335x-bone: boot > - dra7-evm: boot > > Maintainer friendly branches also available: > > tree: https://github.com/t-kristo/linux-pm.git > > clk driver only (Mike): clk-next-dt-clks-v13 > DTS data only (Benoit): dts_for_3.14-dt-clks-v13 > full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 > > -Tero > Maintainer branches conflicts (using 3.13-rc7-dt-clks-v13): = Conflict resolution during rebase to maintainer's -14 branches: 1. (trivial) Against mike's clk-next dbdf6ff Merge branch 'clk-next-unregister' into clk-next Could not apply 2edf7ad... CLK: TI: add DT alias clock registration mechanism conflict drivers/clk/Makefile (trivial fix) 2. (manual, but changes are easy) Against Tony's omap-for-v3.14/be fc6ca98 ARM: OMAP: debug-leds: raw read and write endian fix ARM: OMAP2+: clock: use driver API instead of direct memory read/write conflicts with be changes on Tony's be branch. commit 80f304dd2360cf5d50953c4eb4e902536f6a1263 ARM: OMAP2+: raw read and write endian fix Conflict: arch/arm/mach-omap2/clkt_clksel.c arch/arm/mach-omap2/clkt_dpll.c arch/arm/mach-omap2/clkt_iclk.c arch/arm/mach-omap2/clock.c arch/arm/mach-omap2/clock36xx.c arch/arm/mach-omap2/dpll3xxx.c arch/arm/mach-omap2/dpll44xx.c Both change raw_readls -> should now be just clk api instead which already does readl_relaxed etc.. If Tony feels like, then we should probably post a branch based on 'be' branch for easy merge. 3. I could not detect any merge conflict against Benoit's queued up series (but maybe he has'nt pushed everything to remote tree).. Patch verification report: == Report: http://pastebin.mozilla.org/3976492 * sparse warning added in [PATCH 06/40] CLK: ti: add support for ti divider-clock, [PATCH 10/40] clk: ti: add support for basic mux clock +drivers/clk/ti/divider.c: warning: context imbalance in 'ti_clk_divider_set_rate' - different lock contexts for basic block +drivers/clk/ti/mux.c: warning: context imbalance in 'ti_clk_mux_set_parent' - different lock contexts for basic block * checkpatch warning [PATCH 16/40] CLK: TI: add am33xx clock init file, [PATCH 18/40] CLK: TI: add omap3 clock init file WARNING: static const char * array should probably be static const char * const Boot reports: = - previous orphan clocks seem solved. - All available platforms seem to boot fine and no regression could be seen on initial view OMAP2430: 1. SDP2430 before: http://pastebin.mozilla.org/3976359 after: http://pastebin.mozilla.org/3976467 AM335x: 2. am335x-evm before: http://pastebin.mozilla.org/3976284 after: http://pastebin.mozilla.org/3976374 3. am335x-sk before: http://pastebin.mozilla.org/3976295 after: http://pastebin.mozilla.org/3976375 4. BeagleBone Black: before: http://pastebin.mozilla.org/3976321 after: http://pastebin.mozilla.org/3976441 AM3517: 5. am3517-evm before: http://pastebin.mozilla.org/3976297 after: http://pastebin.mozilla.org/3976397 6. craneboard before: http://pastebin.mozilla.org/3976322 after: http://pastebin.mozilla.org/3976452 OMAP3430: 7. ldp before: http://pastebin.mozilla.org/3976356 after: http://pastebin.mozilla.org/3976455 8. sdp3430 before: http://pastebin.mozilla.org/3976360 after: http://pastebin.mozilla.org/3976468 OMAP3630/DM3730: 9. am37x-evm before: http://pastebin.mozilla.org/3976300 after: http://pastebin.mozilla.org/3976398 10. beagle-XM before: http://pastebin.mozilla.org/3976319 after: http://pastebin.mozilla.org/3976440 OMAP4430: 11. SDP4430 before: http://pastebin.mozilla.org/3976361 after: http://
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On Thu, Jan 09, 2014 at 12:40:59PM -0600, Felipe Balbi wrote: > Hi, > > On Thu, Jan 09, 2014 at 11:22:17AM -0600, Felipe Balbi wrote: > > > Changes compared to previous version: > > > - Dropped any changes to generic clock drivers, as it seems impossible > > > to agree anything in short term, this means the patch set shrank in > > > size from 49 patches to 40 (first 9 patches were dropped). > > > - Copy pasted implementation for clk-divider and clk-mux from drivers/clk > > > to drivers/clk/ti, and made the modifications needed to the TI version > > > of the clock drivers only (based on discussions with Mike, this is fine) > > > - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't > > > conflict > > > with any generic implementation we might have at some point, migrating > > > this to the generic version should be easy enough also. > > > - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous > > > versions and resulted into an orphan clock node > > > - Fixed compile problem for omap5 only build reported by Felipe > > > - Fixed a couple of sparse warnings > > > - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed > > > instead of __raw_readl / __raw_writel > > > > just caught a build breakage. .config attached > > forgot to give you build errors found, they're here: > http://hastebin.com/jibuyuyoto.vbs > > Also, just caught another build breakage: > > http://hastebin.com/reravalupe.vbs > > .config attached hmm, quite a few configs are failing, seems like have DRA7xx without OMAP4 or OMAP5 breaks builds. -- balbi signature.asc Description: Digital signature
[PATCHv13 00/40] ARM: TI SoC clock DT conversion
Hi, So, bad luck number release for this, as v12 wasn't sufficient still. Changes compared to previous version: - Dropped any changes to generic clock drivers, as it seems impossible to agree anything in short term, this means the patch set shrank in size from 49 patches to 40 (first 9 patches were dropped). - Copy pasted implementation for clk-divider and clk-mux from drivers/clk to drivers/clk/ti, and made the modifications needed to the TI version of the clock drivers only (based on discussions with Mike, this is fine) - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict with any generic implementation we might have at some point, migrating this to the generic version should be easy enough also. - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous versions and resulted into an orphan clock node - Fixed compile problem for omap5 only build reported by Felipe - Fixed a couple of sparse warnings - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed instead of __raw_readl / __raw_writel Testing done: - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) - omap4-panda-es: boot / suspend-resume (RET) - omap5-uevm: boot - am335x-bone: boot - dra7-evm: boot Maintainer friendly branches also available: tree: https://github.com/t-kristo/linux-pm.git clk driver only (Mike): clk-next-dt-clks-v13 DTS data only (Benoit): dts_for_3.14-dt-clks-v13 full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html