* [GIT PULL] ARM: mvebu: defconfig changes for v3.17 (round 2)
From: Olof Johansson @ 2014-07-19 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718221351.GN24496@titan.lakedaemon.net>
On Fri, Jul 18, 2014 at 06:13:51PM -0400, Jason Cooper wrote:
> All,
>
> Here's all the defconfig changes we have for mvebu this time around.
> The big one is the removal of kirkwood_defconfig, cooresponding to the
> mach-kirkwood/ removal in mvebu/soc.
>
> This is an incremental pull request from tags/mvebu-defconfig-3.17 up to
> tags/mvebu-defconfig-3.17-2 on the mvebu/defconfig branch.
>
> Please pull.
>
> thx,
>
> Jason.
>
> The following changes since commit 5658d58545388850c77a070fb3b882ddd958eb88:
>
> ARM: multi_v5: Enable LaCie 2Big and 5Big Network v2 (2014-06-20 20:50:23 +0000)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-defconfig-3.17-2
>
> for you to fetch changes up to c1eed8d2ff67b18f3892016f40ad6899ac6cf477:
>
> ARM: mvebu: update mvebu_v7_defconfig with cpufreq support (2014-07-16 12:51:39 +0000)
>
> ----------------------------------------------------------------
> mvebu defconfig changes for v3.17 (round 2)
>
> - mvebu
> - Add appended_dtb support
> - Add devtmpfs support
> - Add 375 network driver
> - Add cpuidle support
> - Add cpufreq support
>
> - kirkwood
> - Remove kirkwood_defconfig
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu: SoC changes for v3.17 (round 2)
From: Olof Johansson @ 2014-07-19 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718220516.GM24496@titan.lakedaemon.net>
On Fri, Jul 18, 2014 at 06:05:16PM -0400, Jason Cooper wrote:
> All,
>
> Yeah, it's just one patch, but it's a beautiful one! Thanks to the
> efforts of many people over the last couple years, and in particular,
> Andrew Lunn, Kirkwood has been completely converted to DT.
>
> As usual, this is an incremental pull request from tags/mvebu-soc-3.17
> up to tags/mvebu-soc-3.17-2 on the mvebu/soc branch.
>
> Please pull.
Pulled, thanks. Descriptions like the first paragraph above can go in
the tag, btw -- it means it'll make it into the merge commit as well. I
added it manually this time.
-Olof
^ permalink raw reply
* [PATCH v7 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
From: Tobias Jakobi @ 2014-07-19 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CADAEE.2070009@gmail.com>
Tomasz Figa wrote:
> Tobias,
>
> On 19.07.2014 21:20, Tobias Jakobi wrote:
>> Hello,
>>
>> I have a question concerning an older version of this patchset, the one
>> which still included exynos4x12 support and where the clocking data was
>> provided through DT.
>>
>> I tried to get this working for my ODROID-X2, which does work well,
>> including the usage of the boost frequences. Since the X2 has an
>> Exynos4412 Prime I added additional clocking data and operating points.
>>
>> clocking data (comes from the vendor kernel):
>> <1704000 3 7 0 6 1 2 7 0 7>
>> <1600000 3 7 0 6 1 2 6 0 7>
>>
>> operating points (again from vendor kernel):
>> 1704000 1375000
>> 1600000 1350000
>>
>> Doing this I get correct output from scaling_available_frequencies and
>> scaling_boost_frequencies and the driver seems to select these
>> frequences. However when reading from cpufreq_cur_freq, which I think
>> returns the frequency of the armclk, the maximum freq never exceeds
>> 1.5GHz. So effectively the additional clocking data and opps are not used.
>>
>> I wonder this happens? Is there some kind of limit enforced?
>
> Have you also extended the array of allowed APLL settings in
> drivers/clk/clk-exynos4.c?
>
> Best regards,
> Tomasz
>
Thanks Tomasz, that did the trick!
With best wishes,
Tobias
^ permalink raw reply
* [PATCH v7 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
From: Tomasz Figa @ 2014-07-19 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CAC4FB.9030703@gmx.net>
Tobias,
On 19.07.2014 21:20, Tobias Jakobi wrote:
> Hello,
>
> I have a question concerning an older version of this patchset, the one
> which still included exynos4x12 support and where the clocking data was
> provided through DT.
>
> I tried to get this working for my ODROID-X2, which does work well,
> including the usage of the boost frequences. Since the X2 has an
> Exynos4412 Prime I added additional clocking data and operating points.
>
> clocking data (comes from the vendor kernel):
> <1704000 3 7 0 6 1 2 7 0 7>
> <1600000 3 7 0 6 1 2 6 0 7>
>
> operating points (again from vendor kernel):
> 1704000 1375000
> 1600000 1350000
>
> Doing this I get correct output from scaling_available_frequencies and
> scaling_boost_frequencies and the driver seems to select these
> frequences. However when reading from cpufreq_cur_freq, which I think
> returns the frequency of the armclk, the maximum freq never exceeds
> 1.5GHz. So effectively the additional clocking data and opps are not used.
>
> I wonder this happens? Is there some kind of limit enforced?
Have you also extended the array of allowed APLL settings in
drivers/clk/clk-exynos4.c?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 2/4] ARM: add IPI tracepoints
From: Ard Biesheuvel @ 2014-07-19 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140719162810.02285fc8@gandalf.local.home>
On 19 July 2014 22:28, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Sat, 19 Jul 2014 21:10:37 +0200
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> On 18 July 2014 23:22, Steven Rostedt <rostedt@goodmis.org> wrote:
>> > On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
>> > Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> >
>> >>
>> >> Here's the patch I have at the head of the series now, with the above
>> >> ugliness changed to an unconditional __tracepoint_string attribute.
>> >>
>> >
>> > I was thinking of something like this. Feel free to add this to your
>> > series.
>> >
>> > -- Steve
>> >
>>
>> Nico,
>>
>> If this patch addresses the issue where 3 RCU related tracepoint
>> strings turn up /after/ _edata on !CONFIG_TRACING, there is already a
>> patch queued up here
>>
>> http://marc.info/?l=linux-kernel&m=140518452623148&w=2
>>
>> As far as In know, these were the only occurrences using a __used
>> modifier, which is why they weren't dropped by the compiler in the
>> !CONFIG_TRACING case.
>>
>
> Ard,
>
> Similar but different problem. Nicolas's problem was with new use cases
> for tracepoint_string. My patch fixes the issue for the general case.
>
OK, so if the general case has been fixed, perhaps we should ask Paul
to drop my patch?
--
Ard.
^ permalink raw reply
* [PATCH 2/4] ARM: add IPI tracepoints
From: Steven Rostedt @ 2014-07-19 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_71vJFf3aUZso1X7m7fULUMhxj+MZVYq+LGNRLJvGyAA@mail.gmail.com>
On Sat, 19 Jul 2014 21:10:37 +0200
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 18 July 2014 23:22, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
> > Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >
> >>
> >> Here's the patch I have at the head of the series now, with the above
> >> ugliness changed to an unconditional __tracepoint_string attribute.
> >>
> >
> > I was thinking of something like this. Feel free to add this to your
> > series.
> >
> > -- Steve
> >
>
> Nico,
>
> If this patch addresses the issue where 3 RCU related tracepoint
> strings turn up /after/ _edata on !CONFIG_TRACING, there is already a
> patch queued up here
>
> http://marc.info/?l=linux-kernel&m=140518452623148&w=2
>
> As far as In know, these were the only occurrences using a __used
> modifier, which is why they weren't dropped by the compiler in the
> !CONFIG_TRACING case.
>
Ard,
Similar but different problem. Nicolas's problem was with new use cases
for tracepoint_string. My patch fixes the issue for the general case.
-- Steve
^ permalink raw reply
* [GIT PULL 7/7] ARM: tegra: defconfig updates for 3.17
From: Olof Johansson @ 2014-07-19 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405694740-4090-7-git-send-email-thierry.reding@gmail.com>
On Fri, Jul 18, 2014 at 04:45:40PM +0200, Thierry Reding wrote:
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-3.17-defconfig
>
> for you to fetch changes up to dff15d4c2b1a4f3992a670b445e2131a400aef76:
>
> ARM: tegra: enable igb, stmpe, i2c chardev, lm95245, pwm leds (2014-06-16 12:55:49 -0600)
>
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 6/7] ARM: tegra: device tree changes for 3.17
From: Olof Johansson @ 2014-07-19 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405694740-4090-6-git-send-email-thierry.reding@gmail.com>
On Fri, Jul 18, 2014 at 04:45:39PM +0200, Thierry Reding wrote:
> The following changes since commit 69c018268b3bbebbd0d9013a1b72831a8ae9e790:
>
> Merge branch 'for-3.17/xusb-padctl' into for-3.17/dt (2014-07-17 15:01:57 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-3.17-dt
>
> for you to fetch changes up to 2236927d9820199bb6f29f2a89b1783c4513d34f:
>
> ARM: tegra: roth: add display DT node (2014-07-17 15:02:14 +0200)
>
> ----------------------------------------------------------------
> ARM: tegra: device tree changes for 3.17
>
> - New board support:
> - Apalis T30
> - HDA support for Tegra124 and Venice2
> - Display on Medcom Wide and Roth
> - GK20A support on Tegra124
> - XUSB pad controller for Tegra124 and Jetson TK1
> - Various cleanups
>
> This pulls in the for-3.17/fuse-move, for-3.17/dt-cros-ec-kbd and
> for-3.17/xusb-padctl branches to resolve dependencies.
>
> Note that the Apalis T30 support has a runtime dependency on the
> for-3.17/pcie-regulators branch, so they should preferably be applied
> in that order. I didn't merge that branch into this because Apalis T30
> support is new, therefore can't regress, and because the dependency
> exists only at runtime.
Yep, that's the preferred way to do it. Looks good, merged into next/dt.
This also means that the kbd dependency is merged (I didn't do that
separately).
-Olof
^ permalink raw reply
* [GIT PULL 4/7] ARM: tegra: Add XUSB pad controller support
From: Olof Johansson @ 2014-07-19 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405694740-4090-4-git-send-email-thierry.reding@gmail.com>
On Fri, Jul 18, 2014 at 04:45:37PM +0200, Thierry Reding wrote:
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-3.17-xusb-padctl
>
> for you to fetch changes up to dc0a3938668706f3a63cde4ceb431e9189fb2a0a:
>
> pinctrl: Add NVIDIA Tegra XUSB pad controller support (2014-07-11 14:41:06 +0200)
>
> ----------------------------------------------------------------
> ARM: tegra: Add XUSB pad controller support
>
> Adds device tree bindings and a driver for the XUSB pad controller found
> on Tegra114 and later. This is a prerequisites for PCIe, SATA and XUSB
> drivers which are all currently being reviewed or pending for merge.
>
> This is a separate branch in case it needs to be pulled into the pinctrl
> tree to resolve conflicts.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 3/7] ARM: tegra: rework PCIe regulators
From: Olof Johansson @ 2014-07-19 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405694740-4090-3-git-send-email-thierry.reding@gmail.com>
On Fri, Jul 18, 2014 at 04:45:36PM +0200, Thierry Reding wrote:
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-3.17-pcie-regulators
>
> for you to fetch changes up to 122ee17dc2adb5c4a63d3a29af9f4e6e331087e5:
>
> ARM: tegra: Remove legacy PCIe power supply properties (2014-07-18 11:20:10 +0200)
>
> ----------------------------------------------------------------
> ARM: tegra: rework PCIe regulators
>
> This branch reworks the set of regulators that the Tegra PCIe driver
> uses, so that the driver and DT bindings more correctly model what's
> really going on in HW. For backwards-compatibility the driver will
> fallback to using the old set of regulators if the new ones can't be
> found.
>
> I've made this a separate branch in case it needs to be pulled into the
> PCIe tree to resolve any conflicts.
Merged into next/drivers. Again, thanks for respinning and making it handle the
old bindings too. I'm glad it wasn't too hard to sort out.
-Olof
^ permalink raw reply
* [GIT PULL 2/7] ARM: tegra: core code changes for 3.17
From: Olof Johansson @ 2014-07-19 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405694740-4090-2-git-send-email-thierry.reding@gmail.com>
On Fri, Jul 18, 2014 at 04:45:35PM +0200, Thierry Reding wrote:
> The following changes since commit dd849e581d7d23e1729c23bb2d6b85360ce4dd9d:
>
> Merge branch 'for-3.17/fuse-move' into for-3.17/soc (2014-07-17 14:58:18 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-3.17-soc
>
> for you to fetch changes up to 7232398abc6a7186e315425638c367d50c674718:
>
> ARM: tegra: Convert PMC to a driver (2014-07-17 14:58:43 +0200)
>
> ----------------------------------------------------------------
> ARM: tegra: core code changes for 3.17
>
> Some of the code that's currently called from the Tegra machine setup
> code is moved to regular initcalls. To catch dependency violations, the
> various code paths now WARN if they're called to early. Not all of the
> potential candidates are converted yet, but those that were have been
> verified to work across all supported Tegra generations.
>
> A new function, soc_is_tegra(), is also provided to make sure that the
> initcalls can abort early if they aren't run on Tegra, which can happen
> for multi-platform builds.
>
> Finally this also moves out the PMC driver to drivers/soc/tegra so that
> it can be shared with 64-bit ARM.
>
> This is based on the for-3.17/fuse-move branch. The split is somewhat
> arbitrary but allows the dependents of the for-3.17/fuse-move to pull
> in as little code as necessary.
Merged (also into next/cleanup). Thanks!
-Olof
^ permalink raw reply
* [GIT PULL 1/7] ARM: tegra: move fuse code out of arch/arm
From: Olof Johansson @ 2014-07-19 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405694740-4090-1-git-send-email-thierry.reding@gmail.com>
On Fri, Jul 18, 2014 at 04:45:34PM +0200, Thierry Reding wrote:
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-3.17-fuse-move
>
> for you to fetch changes up to 2fa937a767bd0933dfe6017cabd038ce52594171:
>
> soc/tegra: fuse: fix dummy functions (2014-07-17 14:38:29 +0200)
Merged into next/cleanup. Thanks for following up on the previous merge request
and respinning this, Theirry!
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner core additions for 3.17
From: Olof Johansson @ 2014-07-19 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718205523.GA28407@lukather>
On Fri, Jul 18, 2014 at 10:55:23PM +0200, Maxime Ripard wrote:
> Hi Arnd, Kevin, Olof,
>
> Here are the few mach-sunxi patches to merge for the 3.17 release cycle.
>
> Thanks!
> Maxime
>
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-core-for-3.17
>
> for you to fetch changes up to 5ba1657ecdee507df4adcd05b533d09e9934fc11:
>
> ARM: sunxi: select MFD_SUN6I_PRCM when sun8i arch support is enabled (2014-07-07 11:00:06 +0200)
>
> ----------------------------------------------------------------
> Allwinner core additions for 3.17
>
> Nothing very fancy here, only the introduction from the new Allwinner A23 SoC.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner DT additions for 3.17
From: Olof Johansson @ 2014-07-19 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718205031.GA27834@lukather>
On Fri, Jul 18, 2014 at 10:50:31PM +0200, Maxime Ripard wrote:
> Hi Arnd, Kevin, Olof,
>
> Here are the sunxi DT changes for 3.17.
>
> Thanks!
> Maxime
>
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-for-3.17
>
> for you to fetch changes up to c220aec2bb793bf5a1fb451fd3e4db87654c5ba5:
>
> ARM: dts: sun6i: Add Merrii A31 Hummingbird support (2014-07-18 22:40:37 +0200)
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH v7 0/6] cpufreq: use generic cpufreq drivers for exynos platforms
From: Tobias Jakobi @ 2014-07-19 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405345118-4269-1-git-send-email-thomas.ab@samsung.com>
Hello,
I have a question concerning an older version of this patchset, the one
which still included exynos4x12 support and where the clocking data was
provided through DT.
I tried to get this working for my ODROID-X2, which does work well,
including the usage of the boost frequences. Since the X2 has an
Exynos4412 Prime I added additional clocking data and operating points.
clocking data (comes from the vendor kernel):
<1704000 3 7 0 6 1 2 7 0 7>
<1600000 3 7 0 6 1 2 6 0 7>
operating points (again from vendor kernel):
1704000 1375000
1600000 1350000
Doing this I get correct output from scaling_available_frequencies and
scaling_boost_frequencies and the driver seems to select these
frequences. However when reading from cpufreq_cur_freq, which I think
returns the frequency of the armclk, the maximum freq never exceeds
1.5GHz. So effectively the additional clocking data and opps are not used.
I wonder this happens? Is there some kind of limit enforced?
With best wishes,
Tobias Jakobi
^ permalink raw reply
* [GIT PULL] Xilinx Zynq changes for v3.17
From: Olof Johansson @ 2014-07-19 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C8F828.8000804@monstr.eu>
On Fri, Jul 18, 2014 at 12:34:16PM +0200, Michal Simek wrote:
> Hi,
>
> please pull these two patches to your arm-soc tree.
>
> Thanks,
> Michal
>
> The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:
>
> Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
>
> are available in the git repository at:
>
> git://git.xilinx.com/linux-xlnx.git tags/zynq-dt-for-3.17
>
> for you to fetch changes up to 8fe9346b945d76ddb3f08c00e34d701174c62fa0:
>
> ARM: zynq: DT: Migrate UART to Cadence binding (2014-07-18 11:54:24 +0200)
>
> ----------------------------------------------------------------
> arm: Xilinx Zynq dt patches for v3.17
>
> - Document and use new cadence serial binding
>
> ----------------------------------------------------------------
> Soren Brinkmann (2):
> tty: cadence: Document DT binding
> ARM: zynq: DT: Migrate UART to Cadence binding
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: imx: device tree updates for 3.17
From: Olof Johansson @ 2014-07-19 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718092713.GC5485@dragon>
On Fri, Jul 18, 2014 at 05:27:14PM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
>
> For sake of dependency, this pull request is based on imx-soc-3.17
> I just sent. Please pull and take care of the dependency, thanks.
Dependency like is perfectly fine (and even preferred).
Merged.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: imx: SoC changes for 3.17
From: Olof Johansson @ 2014-07-19 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718092140.GB5485@dragon>
Hi,
On Fri, Jul 18, 2014 at 05:21:41PM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
>
> To avoid merge conflict, this pull request is based on imx-fixes-3.16-2
> I just sent you. Please pull, thanks.
>
> Shawn
>
> The following changes since commit 03e97220b99b8b691ea5b130b7b4c135c9662792:
>
> ARM: clk-imx6q: parent lvds_sel input from upstream clock gates (2014-07-18 15:57:17 +0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-soc-3.17
>
> for you to fetch changes up to 4349c4298f676815bf7ad146cf37e76843054783:
>
> ARM: imx: clk-vf610: fix FlexCAN clock gating (2014-07-18 16:11:40 +0800)
>
> ----------------------------------------------------------------
> The i.MX SoC changes for 3.17:
> - Add devicetree support for i.MX1 and i.MX21 clock driver
> - Use CLOCKSOURCE_OF_DECLARE() to initialize timer for DT targets
> - Use of_clk_init() to initialize i.MX25 and i.MX27 clock driver in
> device tree boot
> - Remove i.MX1 camera support
> - Remove i.MX27 IP Camera and Lite-Kit board support
> - Add suspend and cpuidle support for i.mx6sx
> - Clean up unused clk_register_clkdev() lookups
> - Update imx-weim bus driver to support populating devices on a simple
> bus
> - Switch i.MX27 and i.MX6QDL clock driver to use macro for clock IDs
> - Make i.MX51 a DT only platform and clean up the non-DT support code
> - Support disabling supervisor protect via DT
> - Random defconfig updates
>
> ----------------------------------------------------------------
> Alexander Shiyan (22):
> ARM: i.MX: Select HAVE_IMX_SRC for i.MX5 globally
> ARM: i.MX1 clk: Add devicetree support
> ARM: i.MX: Remove registration helper for i.MX1 USB UDC
> ARM: i.MX: Use of_clk_get_by_name() for timer clocks for DT case.
> ARM: i.MX: Remove excess variable
> ARM: i.MX27 clk: Separate DT and non-DT init procedure
> ARM: i.MX27 clk: Use of_clk_init() for DT case
> ARM: i.MX clk: Move clock check function in common location
> ARM: i.MX system: Simplify handling watchdog clock
> ARM: i.MX system: Add a reset fallback if base address of watchdog is not set
> ARM: i.MX: Remove Freescale i.MX27 IP Camera board support
> ARM: i.MX21 clk: Clock initialization rework
> ARM: i.MX21 clk: Remove clk_register_clkdev() for unused clocks
> ARM: i.MX21 clk: Cleanup driver
> ARM: i.MX21 clk: Add devicetree support
> ARM: i.MX: Remove i.MX1 camera support
> ARM: i.MX: Remove excess symbols ARCH_MX1, ARCH_MX25 and MACH_MX27
> ARM: i.MX: Remove Freescale Logic Product Development i.MX27 Lite-Kit board support
> ARM: i.MX27 clk: Introduce DT include for clock provider
> ARM: i.MX27 clk: Remove unused definitions
> ARM: i.MX27 clk: Add 26 MHz oscillator circuit clock gate
> ARM: i.MX: Use CLOCKSOURCE_OF_DECLARE() for DT targets
>
> Anson Huang (4):
> ARM: imx: add suspend support for i.mx6sx
> ARM: imx: add cpuidle support for i.mx6sx
> ARM: imx: mem bit must be cleared before entering DSM mode
> ARM: imx: add standby mode support for suspend
>
> Arnd Bergmann (2):
> ARM: imx: imx6sx uses imx6q cpuidle code
> ARM: imx: build cpu_is_imx6sl function conditionally
>
> Denis Carikli (2):
> ARM i.MX25 clk: Fix gpt timer clock.
> ARM: i.MX25 clk: Use of_clk_init() for DT case
>
> Fabian Frederick (1):
> ARM: imx: use PTR_ERR_OR_ZERO
>
> Fabio Estevam (6):
> ARM: imx: defconfig: Select CONFIG_FHANDLE
> ARM: imx_v6_v7_defconfig: Select CONFIG_SOC_IMX6SX
> ARM: clk-imx51-imx53: Remove clk_register_clkdev()
> ARM: imx_v4_v5_defconfig: Add USB device options
> ARM: mx6: Only check for 1.2GHz for mx6quad
> ARM: imx: clk-imx6sx: register SSI/SSI_IPG as shared gate clocks
>
> Liu Ying (1):
> bus: imx-weim: populate devices on a simple bus
>
> Paul Bolle (1):
> ARM: imx: remove unused defines
>
> Shawn Guo (24):
> Merge tag 'imx-fixes-3.16-2' into imx/soc
> ARM: imx: move EHCI platform defines out of platform_data header
> ARM: imx5: move SOC_IMX5 and SOC_IMX51 into 'Device tree only'
> ARM: imx5: drop option MACH_IMX51_DT
> ARM: imx5: remove imx51 non-DT support files
> ARM: imx5: remove i.MX5 non-DT device registration helpers
> ARM: imx5: make mx51_clocks_init() a DT call
> ARM: imx5: drop arguments from mx5_clocks_common_init()
> ARM: imx5: tzic_init_irq() can directly be .init_irq hook
> ARM: imx5: remove function imx51_soc_init()
> ARM: imx5: call mxc_timer_init_dt() on imx51
> ARM: imx5: retrieve iim base from device tree
> ARM: imx5: remove header crm-regs-imx5.h
> ARM: imx5: use dynamic mapping for CCM block
> ARM: imx5: use dynamic mapping for DPLL block
> ARM: imx5: reuse clock CCM mapping in pm code
> ARM: imx5: use dynamic mapping for Cortex and GPC block
> ARM: imx5: move init hooks into mach-imx5x.c
> ARM: imx5: remove file mm-imx5.c
> ARM: imx5: clean function declarations in mx51.h
> ARM: imx5: remove mx51.h and mx53.h
> ARM: imx6qdl: switch to use macro for clock ID
> ARM: imx: mark .dt_compat as const
> ARM: imx: drop PL310 errata 588369 and 727915
>
> Silvio Fricke (2):
> ARM: imx_v6_v7_defconfig: Enable STMPE gpio support
> ARM: imx_v6_v7_defconfig: Enable flexcan driver for can support
>
> Stefan Agner (2):
> ARM: imx_v6_v7_defconfig: add FSL_EDMA and PRINTK_TIME
> ARM: imx: clk-vf610: fix FlexCAN clock gating
>
> Steffen Trumtrar (2):
> ARM: i.MX: allow disabling supervisor protect via DT
> ARM: i.MX53: globally disable supervisor protect
>
> .../devicetree/bindings/clock/imx1-clock.txt | 26 +
> .../devicetree/bindings/clock/imx21-clock.txt | 28 +
> .../devicetree/bindings/clock/imx27-clock.txt | 127 +---
> .../devicetree/bindings/clock/imx6q-clock.txt | 220 +-----
> arch/arm/configs/imx_v4_v5_defconfig | 5 +-
> arch/arm/configs/imx_v6_v7_defconfig | 9 +-
> arch/arm/configs/multi_v7_defconfig | 2 +-
> arch/arm/configs/mxs_defconfig | 1 +
> arch/arm/mach-imx/Kconfig | 59 +-
> arch/arm/mach-imx/Makefile | 11 +-
> arch/arm/mach-imx/clk-imx1.c | 151 ++--
> arch/arm/mach-imx/clk-imx21.c | 299 ++++----
> arch/arm/mach-imx/clk-imx25.c | 47 +-
> arch/arm/mach-imx/clk-imx27.c | 452 +++++------
> arch/arm/mach-imx/clk-imx31.c | 6 +-
> arch/arm/mach-imx/clk-imx35.c | 6 +-
> arch/arm/mach-imx/clk-imx51-imx53.c | 256 +++----
> arch/arm/mach-imx/clk-imx6q.c | 540 +++++++-------
> arch/arm/mach-imx/clk-imx6sl.c | 11 +-
> arch/arm/mach-imx/clk-imx6sx.c | 25 +-
> arch/arm/mach-imx/clk-vf610.c | 8 +-
> arch/arm/mach-imx/clk.c | 10 +
> arch/arm/mach-imx/clk.h | 9 +
> arch/arm/mach-imx/common.h | 32 +-
> arch/arm/mach-imx/cpu-imx5.c | 25 +-
> arch/arm/mach-imx/cpu.c | 13 +
> arch/arm/mach-imx/cpuidle-imx6q.c | 6 +-
> arch/arm/mach-imx/crm-regs-imx5.h | 600 ---------------
> arch/arm/mach-imx/devices-imx51.h | 66 --
> arch/arm/mach-imx/devices/Kconfig | 9 +-
> arch/arm/mach-imx/devices/Makefile | 2 -
> arch/arm/mach-imx/devices/devices-common.h | 26 -
> arch/arm/mach-imx/devices/platform-fec.c | 12 -
> arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 5 -
> arch/arm/mach-imx/devices/platform-imx-i2c.c | 26 -
> arch/arm/mach-imx/devices/platform-imx-keypad.c | 10 -
> arch/arm/mach-imx/devices/platform-imx-ssi.c | 20 -
> arch/arm/mach-imx/devices/platform-imx-uart.c | 22 -
> arch/arm/mach-imx/devices/platform-imx2-wdt.c | 18 -
> arch/arm/mach-imx/devices/platform-imx_udc.c | 75 --
> arch/arm/mach-imx/devices/platform-mx1-camera.c | 42 --
> arch/arm/mach-imx/devices/platform-mxc-ehci.c | 9 -
> arch/arm/mach-imx/devices/platform-mxc_nand.c | 5 -
> arch/arm/mach-imx/devices/platform-mxc_rnga.c | 5 +-
> arch/arm/mach-imx/devices/platform-pata_imx.c | 10 -
> .../mach-imx/devices/platform-sdhci-esdhc-imx.c | 24 -
> arch/arm/mach-imx/devices/platform-spi_imx.c | 27 -
> arch/arm/mach-imx/ehci-imx25.c | 1 +
> arch/arm/mach-imx/ehci-imx27.c | 1 +
> arch/arm/mach-imx/ehci-imx31.c | 1 +
> arch/arm/mach-imx/ehci-imx35.c | 1 +
> arch/arm/mach-imx/ehci-imx5.c | 171 -----
> arch/arm/mach-imx/ehci.h | 43 ++
> arch/arm/mach-imx/gpc.c | 5 +-
> arch/arm/mach-imx/hardware.h | 2 -
> arch/arm/mach-imx/imx25-dt.c | 6 -
> arch/arm/mach-imx/imx27-dt.c | 6 -
> arch/arm/mach-imx/imx31-dt.c | 2 +-
> arch/arm/mach-imx/imx35-dt.c | 2 +-
> arch/arm/mach-imx/iomux-mx51.h | 827 ---------------------
> arch/arm/mach-imx/mach-armadillo5x0.c | 1 +
> arch/arm/mach-imx/mach-cpuimx27.c | 1 +
> arch/arm/mach-imx/mach-cpuimx35.c | 1 +
> arch/arm/mach-imx/mach-eukrea_cpuimx25.c | 1 +
> arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 1 +
> arch/arm/mach-imx/mach-imx27ipcam.c | 77 --
> arch/arm/mach-imx/mach-imx27lite.c | 83 ---
> arch/arm/mach-imx/mach-imx50.c | 5 +-
> arch/arm/mach-imx/{imx51-dt.c => mach-imx51.c} | 45 +-
> arch/arm/mach-imx/mach-imx53.c | 19 +-
> arch/arm/mach-imx/mach-imx6q.c | 4 +-
> arch/arm/mach-imx/mach-imx6sl.c | 2 +-
> arch/arm/mach-imx/mach-imx6sx.c | 10 +-
> arch/arm/mach-imx/mach-mx25_3ds.c | 1 +
> arch/arm/mach-imx/mach-mx27_3ds.c | 1 +
> arch/arm/mach-imx/mach-mx31_3ds.c | 1 +
> arch/arm/mach-imx/mach-mx31lilly.c | 1 +
> arch/arm/mach-imx/mach-mx31lite.c | 1 +
> arch/arm/mach-imx/mach-mx31moboard.c | 5 +-
> arch/arm/mach-imx/mach-mx35_3ds.c | 1 +
> arch/arm/mach-imx/mach-pca100.c | 1 +
> arch/arm/mach-imx/mach-pcm037.c | 1 +
> arch/arm/mach-imx/mach-pcm038.c | 1 +
> arch/arm/mach-imx/mach-pcm043.c | 1 +
> arch/arm/mach-imx/mach-vf610.c | 2 +-
> arch/arm/mach-imx/mach-vpr200.c | 1 +
> arch/arm/mach-imx/mm-imx5.c | 155 ----
> arch/arm/mach-imx/mx1-camera-fiq-ksym.c | 18 -
> arch/arm/mach-imx/mx1-camera-fiq.S | 35 -
> arch/arm/mach-imx/mx31moboard-devboard.c | 5 +-
> arch/arm/mach-imx/mx31moboard-marxbot.c | 5 +-
> arch/arm/mach-imx/mx31moboard-smartbot.c | 5 +-
> arch/arm/mach-imx/mx51.h | 346 ---------
> arch/arm/mach-imx/mx53.h | 342 ---------
> arch/arm/mach-imx/mxc.h | 7 +
> arch/arm/mach-imx/pm-imx5.c | 98 ++-
> arch/arm/mach-imx/pm-imx6.c | 67 +-
> arch/arm/mach-imx/system.c | 24 +-
> arch/arm/mach-imx/time.c | 55 +-
> arch/arm/mach-imx/tzic.c | 9 +-
> drivers/bus/imx-weim.c | 4 +-
> include/dt-bindings/clock/imx1-clock.h | 40 +
> include/dt-bindings/clock/imx21-clock.h | 80 ++
> include/dt-bindings/clock/imx27-clock.h | 108 +++
> include/dt-bindings/clock/imx6qdl-clock.h | 224 ++++++
> include/dt-bindings/clock/vf610-clock.h | 4 +-
> include/linux/platform_data/camera-mx1.h | 35 -
> include/linux/platform_data/usb-ehci-mxc.h | 46 --
> include/linux/platform_data/usb-imx_udc.h | 23 -
> 109 files changed, 1805 insertions(+), 4663 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/imx1-clock.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx21-clock.txt
> delete mode 100644 arch/arm/mach-imx/crm-regs-imx5.h
> delete mode 100644 arch/arm/mach-imx/devices-imx51.h
> delete mode 100644 arch/arm/mach-imx/devices/platform-imx_udc.c
> delete mode 100644 arch/arm/mach-imx/devices/platform-mx1-camera.c
> delete mode 100644 arch/arm/mach-imx/ehci-imx5.c
> create mode 100644 arch/arm/mach-imx/ehci.h
> delete mode 100644 arch/arm/mach-imx/iomux-mx51.h
> delete mode 100644 arch/arm/mach-imx/mach-imx27ipcam.c
> delete mode 100644 arch/arm/mach-imx/mach-imx27lite.c
> rename arch/arm/mach-imx/{imx51-dt.c => mach-imx51.c} (51%)
> delete mode 100644 arch/arm/mach-imx/mm-imx5.c
> delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c
> delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S
> delete mode 100644 arch/arm/mach-imx/mx51.h
> delete mode 100644 arch/arm/mach-imx/mx53.h
> create mode 100644 include/dt-bindings/clock/imx1-clock.h
> create mode 100644 include/dt-bindings/clock/imx21-clock.h
> create mode 100644 include/dt-bindings/clock/imx27-clock.h
> create mode 100644 include/dt-bindings/clock/imx6qdl-clock.h
> delete mode 100644 include/linux/platform_data/camera-mx1.h
> delete mode 100644 include/linux/platform_data/usb-imx_udc.h
Nice diffstat. I would have liked to see the cleanups split off in a separate
preceding branch (and the soc updates build on top if needed), so please keep
that in mind in the future.
The slightly bigger hassle is the defconfig update, since you touched
multi_v7_defconfig: we tend to want to merge or apply that separately since
they tend to cause a lot of conflicts between our branches.
Still, I'll give you a pass this time, it's a small change so we can manage it.
Please separate more in the future though.
Merged.
Thanks,
-Olof
^ permalink raw reply
* [PATCH 2/4] ARM: add IPI tracepoints
From: Ard Biesheuvel @ 2014-07-19 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718172221.6dbe83e4@gandalf.local.home>
On 18 July 2014 23:22, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
> Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>
>>
>> Here's the patch I have at the head of the series now, with the above
>> ugliness changed to an unconditional __tracepoint_string attribute.
>>
>
> I was thinking of something like this. Feel free to add this to your
> series.
>
> -- Steve
>
Nico,
If this patch addresses the issue where 3 RCU related tracepoint
strings turn up /after/ _edata on !CONFIG_TRACING, there is already a
patch queued up here
http://marc.info/?l=linux-kernel&m=140518452623148&w=2
As far as In know, these were the only occurrences using a __used
modifier, which is why they weren't dropped by the compiler in the
!CONFIG_TRACING case.
Regards,
Ard.
> From: Steven Rostedt <rostedt@goodmis.org>
> Subject: [PATCH] tracing: Do not do anything special with tracepoint_string when tracing is disabled
>
> When CONFIG_TRACING is not enabled, there's no reason to save the trace
> strings either by the linker or as a static variable that can be
> referenced later. Simply pass back the string that is given to
> tracepoint_string().
>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index cff3106..b296363 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -574,6 +574,7 @@ do { \
> __trace_printk(ip, fmt, ##args); \
> } while (0)
>
> +#ifdef CONFIG_TRACING
> /**
> * tracepoint_string - register constant persistent string to trace system
> * @str - a constant persistent string that will be referenced in tracepoints
> @@ -607,6 +608,15 @@ do { \
> ___tp_str; \
> })
> #define __tracepoint_string __attribute__((section("__tracepoint_str")))
> +#else
> +/*
> + * tracepoint_string() is used to save the string address for userspace
> + * tracing tools. When tracing isn't configured, there's no need to save
> + * anything.
> + */
> +# define tracepoint_string(str) str
> +# define __tracepoint_string
> +#endif
>
> #ifdef CONFIG_PERF_EVENTS
> struct perf_event;
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Boards Cleanups Updates for v3.17
From: Olof Johansson @ 2014-07-19 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405641497.git.horms+renesas@verge.net.au>
On Fri, Jul 18, 2014 at 08:59:25AM +0900, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC Boards Cleanups updates for v3.17.
>
> This pull request is based on a merge of:
>
> * "Fourth Round of Renesas ARM Based SoC Defconfig Updates for v3.17",
> tagged as renesas-defconfig4-for-v3.17,
> which I have sent a pull request for.
>
> The reason for this dependency is to avoid attempts to use
> genmai_defconfig after the board code it relies on has been removed.
I'd prefer not to add this dependency. It's not a big deal to have a defconfig
that won't build momentarily, it doesn't cause any real harm and I'd rather
avoid keeping this merge/dependency. Can you respin this?
> * "Renesas ARM Based SoC DT Timers Updates for v3.17",
> tagged as renesas-dt-timers-for-v3.17,
> which I have sent a pull request for.
Hmm. You're doing cleanups on top of new development instead of the other way
around. Try to avoid that in future releases if you can.
-Olof
^ permalink raw reply
* [GIT PULL] Fourth Round of Renesas ARM Based SoC Defconfig Updates for v3.17
From: Olof Johansson @ 2014-07-19 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1405640905.git.horms+renesas@verge.net.au>
On Fri, Jul 18, 2014 at 08:55:47AM +0900, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these fourth round of Renesas ARM based SoC defconfig
> updates for v3.17.
>
> This pull request is based on the previous round of
> such requests, tagged as renesas-defconfig3-for-v3.17,
> which you have merged into renesas/defconfig3.
>
> I will follow-up with a pull request that removes
> the Genmai board code.
>
>
> The following changes since commit 8cbf869a0a278c4d39e50daa4f4101b394a72a93:
>
> ARM: shmobile: Enable R-Car Gen 2 PCIe in shmobile_defconfig (2014-07-09 10:44:12 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig4-for-v3.17
>
> for you to fetch changes up to 92db2b7af591d3c3212183a34856b4cb190b6999:
>
> ARM: shmobile: defconfig: Remove MACH_GENMAI (2014-07-17 00:02:34 +0900)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Keystone DTS update for 3.17
From: Olof Johansson @ 2014-07-19 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405618897-10350-1-git-send-email-santosh.shilimkar@ti.com>
On Thu, Jul 17, 2014 at 01:41:37PM -0400, Santosh Shilimkar wrote:
> Hi Arm-soc folks,
>
> Please pull below keystone DTS updates for 3.17.
>
> The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:
>
> Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone-dts
>
> for you to fetch changes up to 6592f671a4e6ee6308ddd67c2459dd71836770df:
>
> ARM: dts: keystone-evm: add 1g ethernet phys nodes (2014-07-17 13:29:06 -0400)
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH v3 1/3] asm-generic/io.h: Implement generic {read,write}s*()
From: James Bottomley @ 2014-07-19 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140719091156.GA31772@ravnborg.org>
On Sat, 2014-07-19 at 11:11 +0200, Sam Ravnborg wrote:
> On Sat, Jul 19, 2014 at 11:05:33AM +0200, Arnd Bergmann wrote:
> > On Saturday 19 July 2014 10:41:52 Sam Ravnborg wrote:
> > > > >
> > > > > This set:
> > > > > #define inb_p(addr) inb(addr)
> > > > > #define inw_p(addr) inw(addr)
> > > > > #define inl_p(addr) inl(addr)
> > > > > #define outb_p(x, addr) outb((x), (addr))
> > > > > #define outw_p(x, addr) outw((x), (addr))
> > > > > #define outl_p(x, addr) outl((x), (addr))
> > > > >
> > > > > Should have a comment that say they are deprecated.
> > > > > Especially the "b" variants still have many users.
> > > >
> > > > Are they? I don't remember ever seeing a reason to deprecate
> > > > them. We could perhaps enclose them in #ifdef CONFIG_ISA, but
> > > > there may also be some drivers that use the same code for ISA
> > > > and PCI, and it doesn't really hurt on PCI.
> > >
> > > It is my understanding that inl and inl_p are the same these days.
> > > A quick grep indicate that only m68k define the
> > > _p variant different from the other.
> > > But I failed to find and description of the difference between the
> > > two which is why I assumed they were identical and thus no need for both.
> >
> > I don't know why m68k needs it, it's really an x86-specific
> > thing, see slow_down_io() in arch/x86/include/asm/io.h.
>
> I had missed the x86 versions when grepping.
> Hmm, and with the macro tricks they play in asm/io.h this
> file is not at all grep friendly.
>
> So xxx_p is for pause (or something like that).
> This also matches that m68k do some tricks with delay() in the _p variants.
> Thanks for the explanation.
Yes, the original x86 problem is that the CPU has a direct IO output bus
which you can connect to. The in/out instructions activate the I/O pin
of the CPU indicating the address should be decoded by the device space.
Some devices are two slow to latch at the CPU speed, so if you do a
succession of in's or out's, particularly to mailbox locations, the
device misses some of the I/O transactions. Adding the delay slows the
sequence down to the point where the device can react to it.
I/O cycle addressing is also problematic for architectures which don't
have an in/out instruction or the concept of I/O access (parisc uses a
special bridge to translate memory access to I/O cycles).
In theory, modern devices should be memory mapped (so capable of
reacting at CPU bus speed) but the PCI spec keeps the concept of I/O
mapping (triggering an I/O cycle instead of a memory one). Most modern
PCI devices offer both memory and I/O mapped access and we always choose
the memory mapped one in that case. Any device supporting both would
never need the delay. However, the PCI spec still preserves the concept
of a legacy device that only has I/O ports, which would possibly need
the delay ... the PCI SIG keeps threatening to deprecate the I/O BAR,
but haven't yet done so yes (as of PCIe version 3.0).
James
^ permalink raw reply
* [RFC] cpufreq: Add bindings for CPU clock sharing topology
From: Santosh Shilimkar @ 2014-07-19 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpokLqrydV3b=innvOWrW9ijXtZwPKdT5Ew65cjMxsY2Mvw@mail.gmail.com>
Viresh,
On Saturday 19 July 2014 10:46 AM, Viresh Kumar wrote:
> On 19 July 2014 03:22, Olof Johansson <olof@lixom.net> wrote:
>> What is the current API that is being broken, in your opinion?
>
> So, currently the nodes doesn't have any such property. And drivers
> consider all of them as sharing clocks, for eg: cpufreq-cpu0.
>
> Now, if we use those older DT's after the new changes, drivers would
> consider CPUs as having separate clocks. And that would be opposite
> of what currently happens.
>
> Not sure if this counts as broken.
>
>>> But if that isn't the case, the bindings are very simple & clear to handle.
>>> Diff for new bindings:
>>
>> It's somewhat confusing to see a diff to the patch instead of a new
>> version. It seems to remove the cpu 0 entry now?
>
> Not really, I removed an unwanted example. This is how it looks:
>
>
>
> * Generic CPUFreq clock bindings
>
> Clock lines may or may not be shared among different CPUs on a platform.
>
> Possible configurations:
> 1.) All CPUs share a single clock line
> 2.) All CPUs have independent clock lines
> 3.) CPUs within a group/cluster share clock line but each group/cluster have a
> separate line for itself
>
> Optional Properties:
> - clock-master: Contains phandle of the master cpu controlling clocks.
>
> Ideally there is nothing like a "master" CPU as any CPU can play with DVFS
> settings. But we have to choose one cpu out of a group, so that others can
> point to it.
>
> If there is no "clock-master" property for a cpu node, it is considered as
> master. It may or may not have other slave CPUs pointing towards it.
>
Sorry for jumping late, but one of the point I was raising as part of your
other series was to extend the CPU topology bindings to cover the voltage
domain information which is probably what is really needed to let the
CPUfreq extract the information. Not sure if it was already discussed.
After all the CPU clocks, cluster, clock-gating, power domains are pretty much
related. So instead of having new binding for CPUFreq, I was wondering whether
we can extend the CPU topology binding information to include missing information.
Scheduler work anyway needs that information.
Ref: Documentation/devicetree/bindings/arm/topology.txt
Does that make sense ?
> Examples:
> 1.) All CPUs share a single clock line
>
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> cpu0: cpu at 0 {
> compatible = "arm,cortex-a15";
> reg = <0>;
> next-level-cache = <&L2>;
> operating-points = <
> /* kHz uV */
> 792000 1100000
> 396000 950000
> 198000 850000
> >;
> clock-latency = <61036>; /* two CLK32 periods */
> };
>
> cpu1: cpu at 1 {
> compatible = "arm,cortex-a15";
> reg = <1>;
> next-level-cache = <&L2>;
> clock-master = <&cpu0>;
> };
> };
>
> 2.) All CPUs have independent clock lines
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> cpu0: cpu at 0 {
> compatible = "arm,cortex-a15";
> reg = <0>;
> next-level-cache = <&L2>;
> operating-points = <
> /* kHz uV */
> 792000 1100000
> 396000 950000
> 198000 850000
> >;
> clock-latency = <61036>; /* two CLK32 periods */
> };
>
> cpu1: cpu at 1 {
> compatible = "arm,cortex-a15";
> reg = <1>;
> next-level-cache = <&L2>;
> operating-points = <
> /* kHz uV */
> 792000 1100000
> 396000 950000
> 198000 850000
> >;
> clock-latency = <61036>; /* two CLK32 periods */
> };
> };
>
> 3.) CPUs within a group/cluster share single clock line but each group/cluster
> have a separate line for itself
>
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> cpu0: cpu at 0 {
> compatible = "arm,cortex-a15";
> reg = <0>;
> next-level-cache = <&L2>;
> operating-points = <
> /* kHz uV */
> 792000 1100000
> 396000 950000
> 198000 850000
> >;
> clock-latency = <61036>; /* two CLK32 periods */
> };
>
> cpu1: cpu at 1 {
> compatible = "arm,cortex-a15";
> reg = <1>;
> next-level-cache = <&L2>;
> clock-master = <&cpu0>;
> };
>
> cpu2: cpu at 100 {
> compatible = "arm,cortex-a7";
> reg = <100>;
> next-level-cache = <&L2>;
> operating-points = <
> /* kHz uV */
> 792000 950000
> 396000 750000
> 198000 450000
> >;
> clock-latency = <61036>; /* two CLK32 periods */
> };
>
> cpu3: cpu at 101 {
> compatible = "arm,cortex-a7";
> reg = <101>;
> next-level-cache = <&L2>;
> clock-master = <&cpu2>;
> };
> };
>
^ permalink raw reply
* [RFC] cpufreq: Add bindings for CPU clock sharing topology
From: Viresh Kumar @ 2014-07-19 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhuNzVtUkaUjF+JjNgHcgf08WiM0DG-kzwtcyUxkK_zow@mail.gmail.com>
On 19 July 2014 03:22, Olof Johansson <olof@lixom.net> wrote:
> What is the current API that is being broken, in your opinion?
So, currently the nodes doesn't have any such property. And drivers
consider all of them as sharing clocks, for eg: cpufreq-cpu0.
Now, if we use those older DT's after the new changes, drivers would
consider CPUs as having separate clocks. And that would be opposite
of what currently happens.
Not sure if this counts as broken.
>> But if that isn't the case, the bindings are very simple & clear to handle.
>> Diff for new bindings:
>
> It's somewhat confusing to see a diff to the patch instead of a new
> version. It seems to remove the cpu 0 entry now?
Not really, I removed an unwanted example. This is how it looks:
* Generic CPUFreq clock bindings
Clock lines may or may not be shared among different CPUs on a platform.
Possible configurations:
1.) All CPUs share a single clock line
2.) All CPUs have independent clock lines
3.) CPUs within a group/cluster share clock line but each group/cluster have a
separate line for itself
Optional Properties:
- clock-master: Contains phandle of the master cpu controlling clocks.
Ideally there is nothing like a "master" CPU as any CPU can play with DVFS
settings. But we have to choose one cpu out of a group, so that others can
point to it.
If there is no "clock-master" property for a cpu node, it is considered as
master. It may or may not have other slave CPUs pointing towards it.
Examples:
1.) All CPUs share a single clock line
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu at 0 {
compatible = "arm,cortex-a15";
reg = <0>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
clock-latency = <61036>; /* two CLK32 periods */
};
cpu1: cpu at 1 {
compatible = "arm,cortex-a15";
reg = <1>;
next-level-cache = <&L2>;
clock-master = <&cpu0>;
};
};
2.) All CPUs have independent clock lines
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu at 0 {
compatible = "arm,cortex-a15";
reg = <0>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
clock-latency = <61036>; /* two CLK32 periods */
};
cpu1: cpu at 1 {
compatible = "arm,cortex-a15";
reg = <1>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
clock-latency = <61036>; /* two CLK32 periods */
};
};
3.) CPUs within a group/cluster share single clock line but each group/cluster
have a separate line for itself
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu at 0 {
compatible = "arm,cortex-a15";
reg = <0>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
clock-latency = <61036>; /* two CLK32 periods */
};
cpu1: cpu at 1 {
compatible = "arm,cortex-a15";
reg = <1>;
next-level-cache = <&L2>;
clock-master = <&cpu0>;
};
cpu2: cpu at 100 {
compatible = "arm,cortex-a7";
reg = <100>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 950000
396000 750000
198000 450000
>;
clock-latency = <61036>; /* two CLK32 periods */
};
cpu3: cpu at 101 {
compatible = "arm,cortex-a7";
reg = <101>;
next-level-cache = <&L2>;
clock-master = <&cpu2>;
};
};
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox