* [GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.10
From: Olof Johansson @ 2016-11-19 1:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479387356.git.horms+renesas@verge.net.au>
On Thu, Nov 17, 2016 at 02:34:25PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these second round of Renesas ARM based SoC updates for v4.10.
>
> This pull request is based on the previous round of
> such requests, tagged as renesas-soc-for-v4.10,
> which I have already sent a pull-request for.
>
>
> The following changes since commit 9652623f8f019edc93a7a934a10b7d0b90421d5a:
>
> ARM: shmobile: r8a7779/marzen: Add board part number to DT bindings (2016-11-04 10:25:45 +0100)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc2-for-v4.10
>
> for you to fetch changes up to 4af239175d00c1866cc6b41f3eabcf93c45dcc40:
>
> ARM: shmobile: document SK-RZG1E board (2016-11-15 10:59:35 +0100)
>
> ----------------------------------------------------------------
> Second Round of Renesas ARM Based SoC Updates for v4.10
>
> * Basic support for r8a7745 SoC
>
> ----------------------------------------------------------------
> Sergei Shtylyov (2):
> ARM: shmobile: r8a7745: basic SoC support
> ARM: shmobile: document SK-RZG1E board
Hi,
Is there a reason you're adding a config option per SoC?
I think you'd be better off not adding these config options, and just adding
support for the SoCs through compatibles (and adding the drivers to defconfigs,
etc).
Anyway, I've merged this branch since this is along the lines of what you
already have, but it could be worth looking at cleaning up and removing
some of these options.
-Olof
^ permalink raw reply
* [GIT PULL 3/5] omap device tree changes for v4.10
From: Tony Lindgren @ 2016-11-19 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119004830.GF15902@localhost>
* Olof Johansson <olof@lixom.net> [161118 17:10]:
> On Tue, Nov 15, 2016 at 01:22:21PM -0800, Tony Lindgren wrote:
> > - Add minimal droid 4 xt894 support
>
> Another phone, cool to see even though it's no longer being sold.
Plenty of them around at about $30 or so used :)
Regards,
Tony
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Stefan Agner @ 2016-11-19 1:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFrpqmvVAKsfQBP1m7vdOjPRx7puVkmmCe3yxe1gVFwgzw@mail.gmail.com>
On 2016-11-16 06:45, Ulf Hansson wrote:
> On 28 October 2016 at 17:37, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
>>> Greetings,
>>>
>>> I have an IMX6 board that has the following:
>>> sdhc1: mmc0: sdio radio
>>> sdhc2: mmc1: /dev/mmcblk1: microSD connector
>>> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
>>>
>>> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
>>> registered as /dev/mmcblk1 so that permanent storage is the first
>>> mmcblk device as I think this is more intuitive however currently
>>> these get instanced in the order they appear in the imx6qdl.dtsi
>>> device-tree configuration and are not able to be mapped the way I want
>>> them in my dts file.
>>>
>>> Is there a way, or if not is there a desire for a way, to specify the
>>> order of /dev/mmcblk devices via device-tree?
>>
>> As with many other devices, there is no standard way of controlling the
>> Linux enumeration (and given the ID space is shared with other dynamic
>> devices it's not something that could generally work).
>>
>> These should be refererd to by UUID if possible.
>>
>> If not, we could cosider adding a by-dt-path or something like that.
>
> So does that mean you think using "DT aliases" would be okay? As
> Javier pointed out, there have been some attempts [1] for that, but
> they didn't make it.
> Perhaps we need to re-consider, and if so please re-review the DT
> bindings patch from that series.
I really would like to see some sort of stable MMC block device
ordering.
by-dt-path solutions requires initramfs, which adds complexity and boot
time. Both not very welcome in simple embedded devices.
PARTUUID is relying on a particular instance of a partition, which is
not the same as to say boot from the second partition of device X.
The main problem I see in my patchset is that it works around the fact
MMC is a bus. Adding the mmc controller number to the block device name
would avoid that issue (mmc0blk0...), not sure if a such a drastic
change would be acceptable.
--
Stefan
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Stefan Agner @ 2016-11-19 1:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115235503.GC1041@n2100.armlinux.org.uk>
On 2016-11-15 15:55, Russell King - ARM Linux wrote:
> On Tue, Nov 15, 2016 at 10:10:02PM +0000, Russell King - ARM Linux wrote:
>> On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
>> > On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
>> > <linux@armlinux.org.uk> wrote:
>> > > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
>> > >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
>> > >> <linux@armlinux.org.uk> wrote:
>> > >> > So, someone merged a patch which makes mmcblk devices follow the
>> > >> > host controller numbering.
>> > >> >
>> > >> > Now my cubox-i fails to boot correctly because the SD card in the
>> > >> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
>> > >> >
>> > >> > USDHC1 is wired to the on-microsom WiFi, and never has anything
>> > >> > remotely near a SD card or eMMC present. So, this change is
>> > >> > confusing on these platforms.
>> > >> >
>> > >> > Moreover, this is _going_ to break SolidRun distros if people upgrade
>> > >> > their kernels.
>> > >> >
>> > >> > It may be appropriate for eMMC, but it's not appropriate everywhere.
>> > >> >
>> > >> > This is a user visible _regression_ in 4.9-rc. Whoever did this,
>> > >> > please revert whatever change caused this, and next time limit it
>> > >> > to only eMMC.
>> > >> >
>> > >> > Thanks.
>> > >>
>> > >> I see the same thing on newer kernels, which is why I asked the
>> > >> question. I didn't expect (or even want honestly) a non mmcblk0 boot
>> > >> device and was looking for a way to control that via dt. Now I'm
>> > >> understanding that to avoid this kind of bootloader/kernel dependence
>> > >> issue I should be using UUID's to identify the boot device.
>> > >>
>> > >> >From my testing it looks like the change your looking for occurred
>> > >> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
>> > >> regression specifically.
>> > >
>> > > That depends how you look at it. Yes, there's a change in 4.5 to 4.6
>> > > which ties the block device number to the host device index, but that's
>> > > really only part of the story here.
>> > >
>> > > 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
>> > > 4.9-rc identifies the SD card as "mmcblk1". This makes it a 4.9 change
>> > > of behaviour - there can be no argument about that.
>> > >
>> > > Now, digging further into this today, it appears that:
>> > >
>> > > v4.8: usdhc2 was probed first, and is given mmc0.
>> > > usdhc1 is probed second, and is given mmc1.
>> > >
>> > > v4.9-rc: usdhc1 is probed first, and is given mmc0.
>> > > usdhc2 is probed second, and is given mmc1.
>> > >
>> > > I haven't yet been able to figure out why there's been this change
>> > > of probe order. There's no change that I can see in the iMX6 DT
>> > > files that would account for this.
>> > >
>> >
>> > I bisected it and the commit your looking for is
>> > 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
>>
>> No it's not.
>>
>> Let me try and put it plainer:
>>
>> * Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
>> device number (mmcblkN) to the mmc host interface number (mmcN).
>> This change happened between 4.5 and 4.6.
>>
>> * The change I'm seeing happened between 4.8 and 4.9-rc. I'm not
>> seeing a change of behaviour between 4.5 and 4.6.
>>
>> * The change I'm seeing changes the order of the physical device
>> associated with the hosts named mmc0 and mmc1 in the kernel.
>>
>> * Because physical devices associated with the mmc0 and mmc1 hosts
>> swap over, the mmcblkN number changes due to the commit you point
>> out.
>>
>> * So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
>> by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
>> else changing the order in which the two usdhc physical hardware
>> blocks get probed.
>>
>> Does this make it clearer?
>
> It turns out to be this commit:
>
> commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
> Author: Masahiro Yamada <yamada.masahiro@socionext.com>
> Date: Mon Sep 19 01:16:44 2016 +0900
>
> clk: probe common clock drivers earlier
>
> Several SoCs implement platform drivers for clocks rather than
> CLK_OF_DECLARE(). Clocks should come earlier because they are
> prerequisites for many of other drivers. It will help to mitigate
> EPROBE_DEFER issues.
>
> Also, drop the comment since it does not carry much value.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Acked-by: Michael Turquette <mturquette@baylibre.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> which changes the init order. In 4.8, we get:
Afaik, init order is not guaranteed, it never was. Usually the order
ends up to be in some order of the device tree, but one could also parse
the device tree in reverse order (which would be an interesting
experiment).
If we want to rely on ordering, we need to add alias support.
--
Stefan
^ permalink raw reply
* [PATCH] ARM: qcom_defconfig: Enable RPM/RPM-SMD clocks
From: Olof Johansson @ 2016-11-19 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117152026.10491-1-georgi.djakov@linaro.org>
On Thu, Nov 17, 2016 at 05:20:26PM +0200, Georgi Djakov wrote:
> Enable support for clocks, controlled by the RPM processor on
> Qualcomm platforms.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Hi,
Please send patches like these to the platform maintainer (i.e. Andy
Gross), and leave arm at kernel.org off of Cc.
We prefer that only maintainers email us at this address to avoid getting
cc:d on everything (and dealing with the volume of email that entails).
Thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic defconfig changes for v4.10
From: Olof Johansson @ 2016-11-19 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hk2c42ugq.fsf@baylibre.com>
On Tue, Nov 15, 2016 at 03:29:09PM -0800, Kevin Hilman wrote:
> Arnd, Olof,
>
> Here are some defconfig change for Amlogic family SoCs for 4.10. Please
> pull.
>
> Thanks,
>
> Kevin
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-defconfig
>
> for you to fetch changes up to 88c9cb7c109e8867fd6ac3a11e5cead37a6a6f1d:
>
> ARM64: configs: Activate Internal PHY for Meson GXL (2016-11-14 08:40:47 -0800)
>
> ----------------------------------------------------------------
> Amlogic defconfig updates for v4.10
> - enable I2C driver
> - enable SPI, watchdog and HW random as modules
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT changes for v4.10
From: Olof Johansson @ 2016-11-19 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hpolw2uih.fsf@baylibre.com>
On Tue, Nov 15, 2016 at 03:28:06PM -0800, Kevin Hilman wrote:
> Arnd, Olof,
>
> Here are the arm64 DT changes for Amlogic family SoCs.
>
> Please pull,
>
> Thanks,
>
> Kevin
>
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64
>
> for you to fetch changes up to ab5b24fdd2d551ea729e8e19e47811a646260331:
>
> ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes (2016-11-15 12:05:54 -0800)
>
> ----------------------------------------------------------------
> Amlogic DT changes for 64-bit platforms for v4.10
>
> Support for new drivers:
> - USB
> - i2c
> - SPI
> - mailbox/MHU
> - PWM
> - ethernet MAC, PHY
> - secure monitor
> - IR
> - watchdog
Merged, thanks. This platform is coming along nicely.
-Olof
^ permalink raw reply
* [GIT PULL 5/5] omap defconfig changes for v4.10
From: Olof Johansson @ 2016-11-19 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582b7c9d.473f630a.d4410.a225SMTPIN_ADDED_BROKEN@mx.google.com>
On Tue, Nov 15, 2016 at 01:22:23PM -0800, Tony Lindgren wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.10/defconfig-signed
>
> for you to fetch changes up to 9c106e4efab2ec96daebb7bdd0bb61602fd52e7a:
>
> ARM: omap2plus_defconfig: Run make savedefconfig to save some space (2016-11-15 11:01:24 -0800)
>
> ----------------------------------------------------------------
> Defconfig changes for omaps for v4.10 merge window:
>
> - Enable tsc2004 touchscreen as a loadable module
>
> - Enable REGULATOR_GPIO, dra71-evm needs this for MMC voltage
>
> - Enable LP873x PMICs for dra71x-evm
>
> - Run make savedefconfig to save some space and make it
> easier to generate minimal patches against it
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 4/5] drop unused omap platform_data for v4.10
From: Olof Johansson @ 2016-11-19 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582b7c9c.5790620a.e95a2.d669SMTPIN_ADDED_BROKEN@mx.google.com>
On Tue, Nov 15, 2016 at 01:22:22PM -0800, Tony Lindgren wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.10/legacy-signed
>
> for you to fetch changes up to 19944b3a4a30163656b26e9d2ca659657113ac3e:
>
> ARM: OMAP2+: Drop legacy sdram timings (2016-11-10 16:07:32 -0700)
>
> ----------------------------------------------------------------
> Legacy platform_data removal for omaps for v4.10 merge window.
> We've dropped the last legacy boot board-*.c files for mach-omap2
> for v4.9 so now we can start removing the unused platform_data.
>
> All of the below has been unused since v4.9 merge window:
>
> - Drop legacy pmic init code
>
> - Apply seq_puts() fixes for legacy mux code, then drop it
>
> - Drop legacy serial init
>
> - Drop legacy i2c init
>
> - Drop legacy PM init
>
> - Drop legacy twl4030 platform init
>
> - Drop legacy USB host init
>
> - Drop legacy muxing for tusb6010, n8x0 is still using it's
> platform init via pdata-quirks.c
>
> - Drop legacy musb init
>
> - Drop hwmod related legacy mux code
>
> - Drop legacy hwmod data for omap3
>
> - Drop legacy smsc911x and smc91x init
>
> - Drop legacy board flash init
>
> - Drop legacy ads7846 init
>
> - Drop legacy sdram timings
[...]
> 45 files changed, 160 insertions(+), 8306 deletions(-)
Nice!!
Merged into next/soc, since we don't really track a cleanup branch any more.
-Olof
^ permalink raw reply
* [GIT PULL 3/5] omap device tree changes for v4.10
From: Olof Johansson @ 2016-11-19 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582b7c9b.0111620a.395b.cabdSMTPIN_ADDED_BROKEN@mx.google.com>
Hi,
On Tue, Nov 15, 2016 at 01:22:21PM -0800, Tony Lindgren wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.10/dt-signed
>
> for you to fetch changes up to 7e2f8c0ae670327cbe0348ad2f3df7d9a55a8e5d:
>
> ARM: dts: Add minimal support for motorola droid 4 xt894 (2016-11-15 10:28:49 -0800)
>
> ----------------------------------------------------------------
> Device tree changes for omaps for v4.10 merge window:
>
> - A series of patches to configure tps65217 PMIC interrupts for
> power button, charger and usb and use them on am335x
>
> - Configure EEPROM, LEDs and USR1 button for omap5 boards
>
> - Add tscadc DMA properites for am33xx and am4372
>
> - Configure baltos-ir5221 both musb channels to host mode
>
> - Configure internal and external RTC clocks for am335x boards
>
> - Don't reset gpio3 block on baltos
>
> - Remove pinmux for dra72-evm for erratum i869, fix the regulators
> and seprate out tps65917 support
>
> - Add dra718-evm support
>
> - Add minimal droid 4 xt894 support
Another phone, cool to see even though it's no longer being sold.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 2/5] omap soc changes for v4.10
From: Olof Johansson @ 2016-11-19 0:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582b7c9a.d549620a.d6a1a.22c0SMTPIN_ADDED_BROKEN@mx.google.com>
On Tue, Nov 15, 2016 at 01:22:20PM -0800, Tony Lindgren wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.10/soc-signed
>
> for you to fetch changes up to 2bb6375f5c03cc5bf510402b646c1a23046b3f12:
>
> Merge branch 'omap-for-v4.10/cpuidle-v2' into omap-for-v4.10/soc (2016-11-14 15:58:18 -0800)
>
> ----------------------------------------------------------------
> SoC changes for omaps for v4.10 merge window:
>
> - Add hwmod interconnect target wrapper module data for crypto
> accelerators for am3xxx, am43xx and dra7
>
> - Add support for dra71x family of SoCs
>
> - PM fixes for omap4/5 needed for omap5 cpuidle
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 1/5] non-urgent omap fixes for v4.10
From: Olof Johansson @ 2016-11-19 0:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582b7c99.5790620a.e95a2.d641SMTPIN_ADDED_BROKEN@mx.google.com>
On Tue, Nov 15, 2016 at 01:22:19PM -0800, Tony Lindgren wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.10/fixes-not-urgent-signed
>
> for you to fetch changes up to 5c02b01d234f8410010c952069d3fb9ec5d9124a:
>
> ARM: OMAP2+: pm-debug: Use seq_putc() in two functions (2016-11-09 15:33:33 -0700)
>
> ----------------------------------------------------------------
> Non-urgent fixes for omaps for v4.10 merge window:
>
> - Fix mismatched interrupt numbers for tps65217, these are not yet
> used
>
> - Remove unused omapdss_early_init_of()
>
> - Use seq_putc() for pm-debug.c
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner arm64 DT changes for 4.9
From: Olof Johansson @ 2016-11-19 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115211333.oqvxfjxxudfkdq7j@lukather>
On Tue, Nov 15, 2016 at 10:13:33PM +0100, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Here are our changes for arm64 DT for the next merge window.
>
> Thanks!
> Maxime
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt64-for-4.10
>
> for you to fetch changes up to 4e3886081848b7ea16452a92c4324acaab644d49:
>
> arm64: dts: add Pine64 support (2016-11-03 09:08:24 +0100)
>
> ----------------------------------------------------------------
> Allwinner arm64 DT changes for 4.10
>
> Support for the Allwinner A64, their first armv8 SoC.
>
> ----------------------------------------------------------------
> Andre Przywara (3):
> arm64: dts: add Allwinner A64 SoC .dtsi
> Documentation: devicetree: add vendor prefix for Pine64
> arm64: dts: add Pine64 support
Hi,
Merged the branch, but please use "arm64: dts: allwinner: <..>" as patch
prefix in the future. Thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner defconfig changes for 4.10
From: Olof Johansson @ 2016-11-19 0:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115210342.vz6k5ihsfl4gx4nu@lukather>
On Tue, Nov 15, 2016 at 10:03:42PM +0100, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Please pull the following changes for the next merge window.
>
> Thanks!
> Maxime
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-defconfig-for-4.10
>
> for you to fetch changes up to a0eb3ee3c8dbe918c397eaf52ea0c887defd35a7:
>
> ARM: multi_v7: enable VGA bridge (2016-10-16 14:31:52 +0200)
>
> ----------------------------------------------------------------
> Allwinner defconfig changes for 4.10
>
> Two patches to enable the dumb VGA bridges in the multi_v7 and sunxi
> defconfig.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner late DT changes for 4.10
From: Olof Johansson @ 2016-11-19 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115210034.mwqnsggmmbzoav77@lukather>
On Tue, Nov 15, 2016 at 10:00:34PM +0100, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Here is a pull request that should be merged after the pinctrl PR,
> hence probably in your late PR.
>
> This is just a mechanic conversion to the generic pinconf bindings and
> removal of the useless pinmux properties we had.
>
> This is based on the previous DT PR I just sent.
>
> Thanks!
> Maxime
>
> The following changes since commit e39a30cf736144814b0bddb3fff28fbbc2a8be0f:
>
> ARM: sunxi: Add the missing clocks to the pinctrl nodes (2016-11-15 18:49:47 +0100)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-late-for-4.10
>
> for you to fetch changes up to 1d20ba07ea57ae227a925302b42221df5b830f2b:
>
> ARM: sunxi: Convert pinctrl nodes to generic bindings (2016-11-15 21:56:30 +0100)
Nice cleanup!
Unfortuantely, see comment on previous pull request, so this would need
to be rebased.
Also, this won't work since this branch does not contain the required
pinctrl changes. If we merge this without basing it on those changes we lose
bisectability.
It'd be easiest if you just held off on these until right after 4.10-rc1, and
we could get them in before -rc2.
Thanks,
-Olof
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.10
From: Olof Johansson @ 2016-11-19 0:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115204122.x3vnb3bkny5esdya@lukather>
Hi,
On Tue, Nov 15, 2016 at 09:41:22PM +0100, Maxime Ripard wrote:
> Hi Arnd, Olof,
>
> Here is our pull request for the next merge window.
>
> Thanks!
> Maxime
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-for-4.10
>
> for you to fetch changes up to e39a30cf736144814b0bddb3fff28fbbc2a8be0f:
>
> ARM: sunxi: Add the missing clocks to the pinctrl nodes (2016-11-15 18:49:47 +0100)
>
> ----------------------------------------------------------------
> Allwinner DT additions for 4.10
>
> The usual bunch of DT additions, but most notably:
> - A31 DRM driver
> - A31 audio codec
> - WiFi for the A80-Based boards and the CHIP
> - Support for the NextThing Co CHIP Pro (the first board with NAND
> enabled)
> - New boards: NanoPi M1,
>
[...]
> Maxime Ripard (16):
> ARM: sun5i: a13-olinuxino: Enable VGA bridge
> ARM: gr8: Add the UART3
> ARM: gr8: Fix typo in the i2s mclk pin group
> ARM: gr8: Add missing pwm channel 1 pin
> ARM: gr8: Add UART2 pins
> ARM: gr8: Add UART3 pins
> ARM: gr8: Add CHIP Pro support
> ARM: sun5i: chip: Enable Wi-Fi SDIO chip
> ARM: sun5i: Rename A10s pins
> ARM: sun5i: Add SPI2 pins
> ARM: sun5i: Add RGB 565 LCD pins
> ARM: sun5i: chip: Add optional buses
> ARM: gr8: evb: Enable SPDIF
> ARM: gr8: evb: Add i2s codec
> ARM: sun8i: sina33: Enable USB gadget
> ARM: sunxi: Add the missing clocks to the pinctrl nodes
>
[...]
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/ntc-gr8-chip-pro.dts | 266 +++++++++++++++++++++
> arch/arm/boot/dts/ntc-gr8-evb.dts | 33 +++
> arch/arm/boot/dts/ntc-gr8.dtsi | 47 +++-
> arch/arm/boot/dts/sun4i-a10.dtsi | 3 +-
NTC isn't the SoC manufacturer, and we try to keep the prefixes down to
manufacturer to keep the namespace a little more manageable, even if
we never got subdirectories setup as on arm64.
I think this should probably be sun4i-a10-gr8 or sun4i-r8-gr8 as prefix?
-Olof
^ permalink raw reply
* [GIT PULL] Reset controller changes for v4.10
From: Olof Johansson @ 2016-11-19 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479237815.2456.59.camel@pengutronix.de>
On Tue, Nov 15, 2016 at 08:23:35PM +0100, Philipp Zabel wrote:
> Dear arm-soc maintainers,
>
> Please consider merging this tag which adds OX820 support, removes
> unused modular code and obsolete STiH41[56] support, and adds support
> for multiple devices sharing a pulsed reset, as long as their
> requirement is just being reset once, some time before use.
>
> regards
> Philipp
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.pengutronix.de/git/pza/linux.git tags/reset-for-4.10
>
> for you to fetch changes up to 7da33a37b48f11ffcb4a718f29a3d4552423fea1:
>
> reset: allow using reset_control_reset with shared reset (2016-11-14 09:58:28 +0100)
>
> ----------------------------------------------------------------
> Reset controller changes for v4.10
>
> - remove obsolete STiH41[56] platform support
> - add Oxford Semiconductor OX820 support
> - add reset index include files for OX810SE and OX820
> - make drivers with boolean Kconfig options explicitly
> non-modular
> - allow shared pulsed resets via reset_control_reset, which
> in this case means that the reset must have been triggered
> once, but possibly earlier, after the function returns, and
> is never triggered again for the lifetime of the reset
> control
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCH] pinctrl: mediatek: use builtin_platform_driver
From: Hongzhou Yang @ 2016-11-18 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <70fcc58b7e9219a9fbe3695df927041b8234dd08.1479457060.git.geliangtang@gmail.com>
On Fri, 2016-11-18 at 22:12 +0800, Geliang Tang wrote:
> Use builtin_platform_driver() helper to simplify the code.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
> ---
> drivers/pinctrl/mediatek/pinctrl-mt6397.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6397.c b/drivers/pinctrl/mediatek/pinctrl-mt6397.c
> index 6eccb85..afcede7 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt6397.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt6397.c
> @@ -64,8 +64,4 @@ static struct platform_driver mtk_pinctrl_driver = {
> },
> };
>
> -static int __init mtk_pinctrl_init(void)
> -{
> - return platform_driver_register(&mtk_pinctrl_driver);
> -}
> -device_initcall(mtk_pinctrl_init);
> +builtin_platform_driver(mtk_pinctrl_driver);
Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
Thanks,
Hongzhou
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-11-18 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478360733.3405.17.camel@intel.com>
Hi all,
[snip]
I did some time measurements on the wifi, mmc and dma driver to compare
the performance between the vendor and the mainline kernel. For this I
toggled some GPIOs and measured the time difference with an osci. I
started measuring the time before calling sdio_readsb() in the wifi
driver [1] and stopped the time when the call returns. Note that the
time was only measured for a packet length of 1536 bytes.
The vendor kernel took about 250 us to return whereas the mainline
kernel took about 325 us. To investigate where this additional time
comes from I divided the whole procedure into seperate parts and
compared their time consumed.
I noticed that the mainline kernel does took much longer to return
after the DMA request is done, signalled in this case by calling
mxs_mmc_dma_irq_callback() [2] in the mxs-mmc driver. From here it
takes about 150 us to get back to sdio_readsb().
An example for consuming much more time is the mainline mmc driver
where it hangs in?mmc_wait_done() [2] about 50 us just calling
complete(), whereas the vendor mmc driver almost immediately returns
here.
I wonder why this call to complete consumes so much time? Any ideas?
[1] http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/
brcm80211/brcmfmac/bcmsdh.c#L488
[2] http://lxr.free-electrons.com/source/drivers/mmc/host/mxs-mmc.c#L17
9
[3] http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L386
Best regards,
J?rg Krause
^ permalink raw reply
* [PATCH 2/4] spi: spi-fsl-dspi: Fix incorrect DMA setup
From: Stefan Agner @ 2016-11-18 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118080403.GB1572@Sanchayan-Arch.localdomain>
On 2016-11-18 00:04, maitysanchayan at gmail.com wrote:
> On 16-11-17 17:03:19, Stefan Agner wrote:
>> On 2016-11-17 04:16, Sanchayan Maity wrote:
>> > Currently dmaengine_prep_slave_single was being called with length
>> > set to the complete DMA buffer size. This resulted in unwanted bytes
>> > being transferred to the SPI register leading to clock and MOSI lines
>> > having unwanted data even after chip select got deasserted and the
>> > required bytes having been transferred.
>> >
>> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
>> > ---
>> > drivers/spi/spi-fsl-dspi.c | 10 ++++++++--
>> > 1 file changed, 8 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
>> > index b1ee1f5..aee8c88 100644
>> > --- a/drivers/spi/spi-fsl-dspi.c
>> > +++ b/drivers/spi/spi-fsl-dspi.c
>> > @@ -265,7 +265,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
>> >
>> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
>> > dma->tx_dma_phys,
>> > - DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
>> > + dma->curr_xfer_len *
>> > + DMA_SLAVE_BUSWIDTH_4_BYTES /
>> > + (tx_word ? 2 : 1),
>> > + DMA_MEM_TO_DEV,
>>
>> Hm, this is getting ridiculous, I think we convert curr_xfer_len from
>> bytes to DMA transfers in almost every use.
>>
>> Can we make it be transfer length in actual 4 byte transfers? We then
>> probably have to convert it to bytes once to subtract from
>> curr_remaining_bytes, but I think it would simplify code overall...
>
> Will the below be acceptable fix?
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 41422cd..db7f091 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -217,15 +217,13 @@ static void dspi_rx_dma_callback(void *arg)
> struct fsl_dspi *dspi = arg;
> struct fsl_dspi_dma *dma = dspi->dma;
> int rx_word;
> - int i, len;
> + int i;
> u16 d;
>
> rx_word = is_double_byte_mode(dspi);
>
> - len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> -
> if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
> - for (i = 0; i < len; i++) {
> + for (i = 0; i < dma->curr_xfer_len; i++) {
> d = dspi->dma->rx_dma_buf[i];
> rx_word ? (*(u16 *)dspi->rx = d) :
> (*(u8 *)dspi->rx = d);
> @@ -242,14 +240,12 @@ static int /(struct
> fsl_dspi *dspi)
> struct device *dev = &dspi->pdev->dev;
> int time_left;
> int tx_word;
> - int i, len;
> + int i;
> u16 val;
>
> tx_word = is_double_byte_mode(dspi);
>
> - len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
> -
> - for (i = 0; i < len - 1; i++) {
> + for (i = 0; i < dma->curr_xfer_len - 1; i++) {
> val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> dspi->dma->tx_dma_buf[i] =
> SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
> @@ -267,7 +263,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
>
> dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> dma->tx_dma_phys,
> - DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
> + dma->curr_xfer_len *
> + DMA_SLAVE_BUSWIDTH_4_BYTES,
> + DMA_MEM_TO_DEV,
> DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> if (!dma->tx_desc) {
> dev_err(dev, "Not able to get desc for DMA xfer\n");
> @@ -283,7 +281,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
>
> dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
> dma->rx_dma_phys,
> - DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
> + dma->curr_xfer_len *
> + DMA_SLAVE_BUSWIDTH_4_BYTES,
> + DMA_DEV_TO_MEM,
> DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> if (!dma->rx_desc) {
> dev_err(dev, "Not able to get desc for DMA xfer\n");
> @@ -330,17 +330,17 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
> struct device *dev = &dspi->pdev->dev;
> int curr_remaining_bytes;
> int bytes_per_buffer;
> - int tx_word;
> + int tx_word = 1;
> int ret = 0;
>
> - tx_word = is_double_byte_mode(dspi);
> + if (is_double_byte_mode(dspi))
> + tx_word = 2;
I would try to be consistent with tx_word. In most other cases it is
used as boolean, whether this is a 2 byte word or not.
Here you change it to represent the length of a single transfer/frame.
Nothing wrong with that, just if you do such changes, also change the
name of the variable so the reader does not get miss lead from other
uses of "tx_word"...
But otherwise looks good, like this variant much better!
Maybe we should add a comment in struct fsl_dspi_dma:
/* Length of transfer in words of DSPI_FIFO_SIZE */
--
Stefan
> curr_remaining_bytes = dspi->len;
> + bytes_per_buffer = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
> while (curr_remaining_bytes) {
> /* Check if current transfer fits the DMA buffer */
> - dma->curr_xfer_len = curr_remaining_bytes;
> - bytes_per_buffer = DSPI_DMA_BUFSIZE /
> - (DSPI_FIFO_SIZE / (tx_word ? 2 : 1));
> - if (curr_remaining_bytes > bytes_per_buffer)
> + dma->curr_xfer_len = curr_remaining_bytes / tx_word;
> + if (dma->curr_xfer_len > bytes_per_buffer)
> dma->curr_xfer_len = bytes_per_buffer;
>
> ret = dspi_next_xfer_dma_submit(dspi);
> @@ -349,7 +349,7 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
> goto exit;
>
> } else {
> - curr_remaining_bytes -= dma->curr_xfer_len;
> + curr_remaining_bytes -= dma->curr_xfer_len * tx_word;
> if (curr_remaining_bytes < 0)
> curr_remaining_bytes = 0;
> dspi->len = curr_remaining_bytes;
>
>
> Regards,
> Sanchayan.
>>
>> --
>> Stefan
>>
>>
>> > DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
>> > if (!dma->tx_desc) {
>> > dev_err(dev, "Not able to get desc for DMA xfer\n");
>> > @@ -281,7 +284,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
>> >
>> > dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
>> > dma->rx_dma_phys,
>> > - DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
>> > + dma->curr_xfer_len *
>> > + DMA_SLAVE_BUSWIDTH_4_BYTES /
>> > + (tx_word ? 2 : 1),
>> > + DMA_DEV_TO_MEM,
>> > DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
>> > if (!dma->rx_desc) {
>> > dev_err(dev, "Not able to get desc for DMA xfer\n");
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-18 23:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region. (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixels _into_ the framebuffer.
This occurs whenever the display mode size is changed - using xrandr
in Xorg shows that changing the resolution triggers the problem
almost every time, but changing the refresh rate does not.
Using devmem2 to disable and re-enable the HDLCD resolves the issue,
and repeated disable/enable cycles do not make the issue re-appear.
So, I patched the HDLCD to do this, and testing it with Xorg after
several repetitions seems to work.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
What I think is going on is that the FIFO or address generator for
reading data from the AXI bus is not properly reset when changing the
resolution, and the enable-disable-enable cycle causes the HDLCD
hardware to sort itself out. It's (eg) significantly out - for example,
to properly align the display, I have to program an address of
0xf4ff0200 into the hardware rather than 0xf5000000 - that's 896 pixels
before the real start of the frame buffer.
With this patch, a patch to TDA998x to avoid the i2c-designware issue,
and xf86-video-armada, I have LXDE running on the Juno.
Something I also noticed is this:
scanout_start = gem->paddr + plane->state->fb->offsets[0] +
plane->state->crtc_y * plane->state->fb->pitches[0] +
plane->state->crtc_x * bpp / 8;
Surely this should be using src_[xy] (which are the position in the
source - iow, memory, and not crtc_[xy] which is the position on the
CRTC displayed window. To put it another way, the src_* define the
region of the source material that is mapped onto a rectangular area
on the display defined by crtc_*.
Another note is that since the CRTC can't place the plane in arbitary
positions and sizes within the active area, should the atomic_check
ensure that crtc_x = crtc_y = 0, and the crtc width/height are the
size of the active area?
drivers/gpu/drm/arm/hdlcd_crtc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 48019ae22ddb..3e97acf6e2a7 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -150,6 +150,8 @@ static void hdlcd_crtc_enable(struct drm_crtc *crtc)
clk_prepare_enable(hdlcd->clk);
hdlcd_crtc_mode_set_nofb(crtc);
hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
+ hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0);
+ hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
}
static void hdlcd_crtc_disable(struct drm_crtc *crtc)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Rafael J. Wysocki @ 2016-11-18 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117175938.17465.45820.stgit@bhelgaas-glaptop.roam.corp.google.com>
On Thu, Nov 17, 2016 at 6:59 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> Add a writeup about how PCI host bridges should be described in ACPI
> using PNP0A03/PNP0A08 devices, PNP0C02 devices, and the MCFG table.
>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Looks great overall, but I have a few comments (below).
> ---
> Documentation/PCI/00-INDEX | 2 +
> Documentation/PCI/acpi-info.txt | 136 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 138 insertions(+)
> create mode 100644 Documentation/PCI/acpi-info.txt
>
> diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
> index 147231f..0780280 100644
> --- a/Documentation/PCI/00-INDEX
> +++ b/Documentation/PCI/00-INDEX
> @@ -1,5 +1,7 @@
> 00-INDEX
> - this file
> +acpi-info.txt
> + - info on how PCI host bridges are represented in ACPI
> MSI-HOWTO.txt
> - the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
> PCIEBUS-HOWTO.txt
> diff --git a/Documentation/PCI/acpi-info.txt b/Documentation/PCI/acpi-info.txt
> new file mode 100644
> index 0000000..ccbcfda
> --- /dev/null
> +++ b/Documentation/PCI/acpi-info.txt
> @@ -0,0 +1,136 @@
> + ACPI considerations for PCI host bridges
> +
> +The basic requirement is that the ACPI namespace should describe
> +*everything* that consumes address space unless there's another
> +standard way for the OS to find it [1, 2]. For example, windows that
> +are forwarded to PCI by a PCI host bridge should be described via ACPI
> +devices, since the OS can't locate the host bridge by itself. PCI
> +devices *below* the host bridge do not need to be described via ACPI,
> +because the resources they consume are inside the host bridge windows,
> +and the OS can discover them via the standard PCI enumeration
> +mechanism (using config accesses to read and size the BARs).
> +
> +This ACPI resource description is done via _CRS methods of devices in
To be painfully precise, those need not be methods. They may be
static objects too.
> +the ACPI namespace [2]. _CRS methods are like generalized PCI BARs:
> +the OS can read _CRS and figure out what resource is being consumed
> +even if it doesn't have a driver for the device [3]. That's important
> +because it means an old OS can work correctly even on a system with
> +new devices unknown to the OS. The new devices won't do anything, but
> +the OS can at least make sure no resources conflict with them.
> +
> +Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
> +reserving address space! The static tables are for things the OS
> +needs to know early in boot, before it can parse the ACPI namespace.
> +If a new table is defined, an old OS needs to operate correctly even
> +though it ignores the table. _CRS allows that because it is generic
> +and understood by the old OS; a static table does not.
> +
> +If the OS is expected to manage an ACPI device, that device will have
I'm not very keen on using the term "ACPI device" in documentation as
it is not particularly well defined. As a rule, I prefer to talk
about "non-discoverable devices described via ACPI" or similar.
Accordingly, I'd change the above line to something like "If the OS is
expected to manage a non-discoverable device described via ACPI, that
device will have".
> +a specific _HID/_CID that tells the OS what driver to bind to it, and
> +the _CRS tells the OS and the driver where the device's registers are.
> +
> +PNP0C02 "motherboard" devices are basically a catch-all. There's no
> +programming model for them other than "don't use these resources for
> +anything else." So any address space that is (1) not claimed by some
> +other ACPI device and (2) should not be assigned by the OS to
Here I'd say "any address space that is (1) not claimed by _CRS under
any other device object in the ACPI namespace and (2) ...".
> +something else, should be claimed by a PNP0C02 _CRS method.
Thanks,
Rafael
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add Macnica Americas vendor prefix
From: Dinh Nguyen @ 2016-11-18 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJv7bBmkWUmd44Ln-=PLLKEch+hbjuD8v8ArhOCZ37jdA@mail.gmail.com>
On 11/18/2016 12:03 PM, Rob Herring wrote:
>
> Sorry, didn't send anything out, but the series is already applied if
> you look at -next or PW.
>
Thanks!
Dinh
^ permalink raw reply
* spin_lock behavior with ARM64 big.Little/HMP
From: Vikram Mulukutla @ 2016-11-18 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8d9d6333-0ebe-65c4-c6f1-3e3475e3e535@arm.com>
Hi Sudeep,
Thanks for taking a look!
On 2016-11-18 02:30, Sudeep Holla wrote:
> Hi Vikram,
>
> On 18/11/16 02:22, Vikram Mulukutla wrote:
>> Hello,
>>
>> This isn't really a bug report, but just a description of a
>> frequency/IPC
>> dependent behavior that I'm curious if we should worry about. The
>> behavior
>> is exposed by questionable design so I'm leaning towards don't-care.
>>
>> Consider these threads running in parallel on two ARM64 CPUs running
>> mainline
>> Linux:
>>
>
> Are you seeing this behavior with the mainline kernel on any platforms
> as we have a sort of workaround for this ?
>
If I understand that workaround correctly, the ARM timer event stream is
used
to periodically wake up CPUs that are waiting in WFE, is that right? I
think
my scenario below may be different because LittleCPU doesn't actually
wait
on a WFE event in the loop that is trying to increment lock->next, i.e.
it's
stuck in the following loop:
ARM64_LSE_ATOMIC_INSN(
/* LL/SC */
" prfm pstl1strm, %3\n"
"1: ldaxr %w0, %3\n"
" add %w1, %w0, %w5\n"
" stxr %w2, %w1, %3\n"
" cbnz %w2, 1b\n",
I have been testing internal platforms; I'll try to test on something
available publicly that's b.L. In any case, the timer event stream was
enabled
when I tried this out.
>> (Ordering of lines between the two columns does not indicate a
>> sequence of
>> execution. Assume flag=0 initially.)
>>
>> LittleARM64_CPU @ 300MHz (e.g.A53) | BigARM64_CPU @ 1.5GHz (e.g.
>> A57)
>> -------------------------------------+----------------------------------
>> spin_lock_irqsave(s) | local_irq_save()
>> /* critical section */
>> flag = 1 | spin_lock(s)
>> spin_unlock_irqrestore(s) | while (!flag) {
>> | spin_unlock(s)
>> | cpu_relax();
>> | spin_lock(s)
>> | }
>> | spin_unlock(s)
>> | local_irq_restore()
>>
[...]
Thanks,
Vikram
^ permalink raw reply
* [PATCH v16 14/15] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer
From: Mark Rutland @ 2016-11-18 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479304148-2965-15-git-send-email-fu.wei@linaro.org>
On Wed, Nov 16, 2016 at 09:49:07PM +0800, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> The patch add memory-mapped timer register support by using the
> information provided by the new GTDT driver of ACPI.
>
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index c494ca8..0aad60a 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -1067,7 +1067,28 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
> arch_timer_mem_of_init);
>
> #ifdef CONFIG_ACPI_GTDT
> -/* Initialize per-processor generic timer */
> +static int __init arch_timer_mem_acpi_init(void)
> +{
> + struct arch_timer_mem *timer_mem;
> + int ret = 0;
> + int i = 0;
> +
> + timer_mem = kzalloc(sizeof(*timer_mem), GFP_KERNEL);
Why do you need it zeroed? You don't clear it between iterations, so
either you don't need this, or you have a bug in the loop.
> + if (!timer_mem)
> + return -ENOMEM;
> +
> + while (!gtdt_arch_timer_mem_init(timer_mem, i)) {
Huh?
Why doesn't GTDT expose a function to fill in the entire arch_timer_mem
in one go?
There shouldn't be multiple instances, as far as I am aware. Am I
mistaken?
> + ret = arch_timer_mem_init(timer_mem);
> + if (ret)
> + break;
> + i++;
> + }
> +
> + kfree(timer_mem);
> + return ret;
> +}
Regardless, arch_timer_mem is small enough that you don't need dynamic
allocaiton. Just put it on the stack, e.g.
static int __init arch_timer_mem_acpi_init(void)
{
int i = 0;
struct arch_timer_mem timer_mem;
while (!gtdt_arch_timer_mem_init(timer_mem, i)) {
int ret = arch_timer_mem_init();
if (ret)
return ret;
i++
}
return 0;
}
Thanks,
Mark.
^ 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