* [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
* [PATCH v16 11/15] acpi/arm64: Add GTDT table parse driver
From: Mark Rutland @ 2016-11-18 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479304148-2965-12-git-send-email-fu.wei@linaro.org>
On Wed, Nov 16, 2016 at 09:49:04PM +0800, fu.wei at linaro.org wrote:
> +#define for_each_platform_timer(_g) for (; _g; _g = next_platform_timer(_g))
This doesn't fit the usual for_each_* pattern, since _g has to be
manually initialised first. Either come up with a way of maknig this fit
the usual pattern, or get rid of this, and use:
t = however_you_get_the_first_timer();
if (!t)
bailt_out_somehow();
do {
...
} while (t = next_platform_timer(t));
> +/*
> + * Release the memory we have allocated in acpi_gtdt_init.
> + * This should be called, when the driver who called "acpi_gtdt_init" previously
> + * doesn't need the GTDT info anymore.
> + */
> +void __init acpi_gtdt_release(void)
> +{
> + kfree(timer_block);
> + kfree(watchdog);
> + timer_block = NULL;
> + watchdog = NULL;
> +}
Why is this not simply in the error path of acpi_gtdt_init()?
> +
> +/*
> + * Get some basic info from GTDT table, and init the global variables above
> + * for all timers initialization of Generic Timer.
> + * This function does some validation on GTDT table.
> + */
> +int __init acpi_gtdt_init(struct acpi_table_header *table)
> +{
> + timer_block = kcalloc(timer_count,
> + sizeof(struct acpi_gtdt_timer_block *),
> + GFP_KERNEL);
> + if (!timer_block)
> + return -ENOMEM;
> +
> + watchdog = kcalloc(timer_count, sizeof(struct acpi_gtdt_watchdog *),
> + GFP_KERNEL);
> + if (!watchdog) {
> + kfree(timer_block);
> + timer_block = NULL;
> + return -ENOMEM;
> + }
Please have a common error path below, and branch to that when you need
to free these.
> +error:
> + acpi_gtdt_release();
> + return -EINVAL;
> +}
[...]
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 61a3d90..a1611d1 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -577,6 +577,13 @@ enum acpi_reconfig_event {
> int acpi_reconfig_notifier_register(struct notifier_block *nb);
> int acpi_reconfig_notifier_unregister(struct notifier_block *nb);
>
> +#ifdef CONFIG_ACPI_GTDT
> +int acpi_gtdt_init(struct acpi_table_header *table);
> +int acpi_gtdt_map_ppi(int type);
> +bool acpi_gtdt_c3stop(int type);
> +void acpi_gtdt_release(void);
Why do these need to be here?
What possible value is ther in exporting acpi_gtdt_release() !?
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: dts: qcom: msm8996: Fixup smp2p node
From: Bjorn Andersson @ 2016-11-18 20:06 UTC (permalink / raw)
To: linux-arm-kernel
The SMEM state property name changes between the integration branch and
mainline, update to use the correct one.
Fixes: 2f45d9fcd531 ("arm64: dts: msm8996: Add SMP2P and APCS nodes")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Seems we're still carrying this discrepancy somewhere and I missed it in my
review, sorry about that.
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index cde4114bae5a..712d5d043105 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -530,7 +530,7 @@
adsp_smp2p_out: master-kernel {
qcom,entry-name = "master-kernel";
- #qcom,state-cells = <1>;
+ #qcom,smem-state-cells = <1>;
};
adsp_smp2p_in: slave-kernel {
--
2.5.0
^ permalink raw reply related
* [PATCH v16 10/15] clocksource/drivers/arm_arch_timer: Refactor the timer init code to prepare for GTDT
From: Mark Rutland @ 2016-11-18 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479304148-2965-11-git-send-email-fu.wei@linaro.org>
On Wed, Nov 16, 2016 at 09:49:03PM +0800, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> The patch refactor original memory-mapped timer init code:
> (1) Extract a subfunction for detecting a bast time frame:
> is_best_frame.
Please leave this logic in arch_timer_mem_init(). Pulling it out gains
us nothing, but makes the patch harder to review.
> (2) Refactor "arch_timer_mem_init", make it become a common code for
> memory-mapped timer init.
> (3) Add a new function "arch_timer_mem_of_init" for DT init.
These generally look fine.
Thanks,
Mark.
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 162 +++++++++++++++++++++++------------
> 1 file changed, 107 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 9ddc091..0836bb9 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -923,17 +923,35 @@ static int __init arch_timer_of_init(struct device_node *np)
> CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_of_init);
> CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_of_init);
>
> -static int __init arch_timer_mem_init(struct device_node *np)
> +static bool __init is_best_frame(void __iomem *cntctlbase, u32 cnttidr, int n)
> +{
> + u32 cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT | CNTACR_RWVT |
> + CNTACR_RVOFF | CNTACR_RVCT;
> +
> + /* Try enabling everything, and see what sticks */
> + writel_relaxed(cntacr, cntctlbase + CNTACR(n));
> + cntacr = readl_relaxed(cntctlbase + CNTACR(n));
> +
> + if ((cnttidr & CNTTIDR_VIRT(n)) &&
> + !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT)))
> + arch_timer_mem_use_virtual = true;
> + else if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
> + return false;
> +
> + return true;
> +}
> +
> +static int __init arch_timer_mem_init(struct arch_timer_mem *timer_mem)
> {
> - struct device_node *frame, *best_frame = NULL;
> void __iomem *cntctlbase, *base;
> - unsigned int irq, ret = -EINVAL;
> + struct arch_timer_mem_frame *best_frame = NULL;
> + unsigned int irq;
> u32 cnttidr;
> + int i, ret;
>
> - arch_timers_present |= ARCH_TIMER_TYPE_MEM;
> - cntctlbase = of_iomap(np, 0);
> + cntctlbase = ioremap(timer_mem->cntctlbase, timer_mem->size);
> if (!cntctlbase) {
> - pr_err("Can't find CNTCTLBase\n");
> + pr_err("Can't map CNTCTLBase.\n");
> return -ENXIO;
> }
>
> @@ -943,76 +961,110 @@ static int __init arch_timer_mem_init(struct device_node *np)
> * Try to find a virtual capable frame. Otherwise fall back to a
> * physical capable frame.
> */
> - for_each_available_child_of_node(np, frame) {
> - int n;
> - u32 cntacr;
> -
> - if (of_property_read_u32(frame, "frame-number", &n)) {
> - pr_err("Missing frame-number\n");
> - of_node_put(frame);
> - goto out;
> - }
> -
> - /* Try enabling everything, and see what sticks */
> - cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT |
> - CNTACR_RWVT | CNTACR_RVOFF | CNTACR_RVCT;
> - writel_relaxed(cntacr, cntctlbase + CNTACR(n));
> - cntacr = readl_relaxed(cntctlbase + CNTACR(n));
> -
> - if ((cnttidr & CNTTIDR_VIRT(n)) &&
> - !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT))) {
> - of_node_put(best_frame);
> - best_frame = frame;
> - arch_timer_mem_use_virtual = true;
> - break;
> + for (i = 0; i < timer_mem->num_frames; i++) {
> + if (is_best_frame(cntctlbase, cnttidr,
> + timer_mem->frame[i].frame_nr)) {
> + best_frame = &timer_mem->frame[i];
> + if (arch_timer_mem_use_virtual)
> + break;
> }
> -
> - if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
> - continue;
> -
> - of_node_put(best_frame);
> - best_frame = of_node_get(frame);
> }
> + iounmap(cntctlbase);
>
> - ret= -ENXIO;
> - base = arch_counter_base = of_iomap(best_frame, 0);
> - if (!base) {
> - pr_err("Can't map frame's registers\n");
> - goto out;
> + if (!best_frame) {
> + pr_err("Can't find frame for register\n");
> + return -EINVAL;
> }
>
> if (arch_timer_mem_use_virtual)
> - irq = irq_of_parse_and_map(best_frame, ARCH_TIMER_VIRT_SPI);
> + irq = best_frame->virt_irq;
> else
> - irq = irq_of_parse_and_map(best_frame, ARCH_TIMER_PHYS_SPI);
> + irq = best_frame->phys_irq;
>
> - ret = -EINVAL;
> if (!irq) {
> pr_err("Frame missing %s irq",
> arch_timer_mem_use_virtual ? "virt" : "phys");
> - goto out;
> + return -EINVAL;
> }
>
> - /*
> - * Try to determine the frequency from the device tree,
> - * if fail, get the frequency from CNTFRQ.
> - */
> - if (!arch_timer_rate &&
> - of_property_read_u32(np, "clock-frequency", &arch_timer_rate))
> - arch_timer_detect_rate(base);
> + base = ioremap(best_frame->cntbase, best_frame->size);
> + if (!base) {
> + pr_err("Can't map frame's registers\n");
> + return -ENXIO;
> + }
> +
> + arch_timer_detect_rate(base);
>
> ret = arch_timer_mem_register(base, irq);
> - if (ret)
> + if (ret) {
> + iounmap(base);
> + return ret;
> + }
> +
> + arch_counter_base = base;
> + arch_timers_present |= ARCH_TIMER_TYPE_MEM;
> +
> + return 0;
> +}
> +
> +static int __init arch_timer_mem_of_init(struct device_node *np)
> +{
> + struct arch_timer_mem *timer_mem;
> + struct device_node *frame_node;
> + struct resource res;
> + int i, ret = -EINVAL;
> +
> + timer_mem = kzalloc(sizeof(*timer_mem), GFP_KERNEL);
> + if (!timer_mem)
> + return -ENOMEM;
> +
> + if (of_address_to_resource(np, 0, &res))
> goto out;
> + timer_mem->cntctlbase = res.start;
> + timer_mem->size = resource_size(&res);
>
> - return arch_timer_common_init();
> + i = 0;
> + for_each_available_child_of_node(np, frame_node) {
> + int n;
> + struct arch_timer_mem_frame *frame = &timer_mem->frame[i];
> +
> + if (of_property_read_u32(frame_node, "frame-number", &n)) {
> + pr_err("Missing frame-number\n");
> + of_node_put(frame_node);
> + goto out;
> + }
> + frame->frame_nr = n;
> +
> + if (of_address_to_resource(frame_node, 0, &res)) {
> + of_node_put(frame_node);
> + goto out;
> + }
> + frame->cntbase = res.start;
> + frame->size = resource_size(&res);
> +
> + frame->virt_irq = irq_of_parse_and_map(frame_node,
> + ARCH_TIMER_VIRT_SPI);
> + frame->phys_irq = irq_of_parse_and_map(frame_node,
> + ARCH_TIMER_PHYS_SPI);
> +
> + if (++i >= ARCH_TIMER_MEM_MAX_FRAMES)
> + break;
> + }
> + timer_mem->num_frames = i;
> +
> + /* Try to determine the frequency from the device tree */
> + if (!arch_timer_rate)
> + of_property_read_u32(np, "clock-frequency", &arch_timer_rate);
> +
> + ret = arch_timer_mem_init(timer_mem);
> + if (!ret)
> + ret = arch_timer_common_init();
> out:
> - iounmap(cntctlbase);
> - of_node_put(best_frame);
> + kfree(timer_mem);
> return ret;
> }
> CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
> - arch_timer_mem_init);
> + arch_timer_mem_of_init);
>
> #ifdef CONFIG_ACPI
> static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v16 08/15] clocksource/drivers/arm_arch_timer: Refactor arch_timer_needs_probing, and call it only if acpi disabled.
From: Mark Rutland @ 2016-11-18 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479304148-2965-9-git-send-email-fu.wei@linaro.org>
On Wed, Nov 16, 2016 at 09:49:01PM +0800, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> The patch refactor original arch_timer_needs_probing function:
> (1) Separate out arch_timer_needs_probing from arch_timer_common_init,
> and call it only if acpi disabled.
> (2) Rename arch_timer_needs_probing to arch_timer_needs_of_probing.
Please write a real commit message.
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 34 +++++++++++++++++++---------------
> 1 file changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index fe4e812..9ddc091 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -792,15 +792,28 @@ static const struct of_device_id arch_timer_mem_of_match[] __initconst = {
> {},
> };
>
> -static bool __init
> -arch_timer_needs_probing(int type, const struct of_device_id *matches)
> +static bool __init arch_timer_needs_of_probing(void)
> {
> struct device_node *dn;
> bool needs_probing = false;
> + unsigned int mask = ARCH_TIMER_TYPE_CP15 | ARCH_TIMER_TYPE_MEM;
> +
> + /* We have two timers, and both device-tree nodes are probed. */
> + if ((arch_timers_present & mask) == mask)
> + return false;
> +
> + /*
> + * Only one type of timer is probed,
> + * check if we have another type of timer node in device-tree.
> + */
> + if (arch_timers_present & ARCH_TIMER_TYPE_CP15)
> + dn = of_find_matching_node(NULL, arch_timer_mem_of_match);
> + else
> + dn = of_find_matching_node(NULL, arch_timer_of_match);
>
> - dn = of_find_matching_node(NULL, matches);
> - if (dn && of_device_is_available(dn) && !(arch_timers_present & type))
> + if (dn && of_device_is_available(dn))
> needs_probing = true;
> +
> of_node_put(dn);
>
> return needs_probing;
> @@ -808,17 +821,8 @@ arch_timer_needs_probing(int type, const struct of_device_id *matches)
>
> static int __init arch_timer_common_init(void)
> {
> - unsigned int mask = ARCH_TIMER_TYPE_CP15 | ARCH_TIMER_TYPE_MEM;
> -
> - /* Wait until both nodes are probed if we have two timers */
> - if ((arch_timers_present & mask) != mask) {
> - if (arch_timer_needs_probing(ARCH_TIMER_TYPE_MEM,
> - arch_timer_mem_of_match))
> - return 0;
> - if (arch_timer_needs_probing(ARCH_TIMER_TYPE_CP15,
> - arch_timer_of_match))
> - return 0;
> - }
Why can't we just move this into the DT-specific caller of
arch_timer_common_init()?
Thanks
Mark.
> + if (acpi_disabled && arch_timer_needs_of_probing())
> + return 0;
>
> arch_timer_banner(arch_timers_present);
> arch_counter_register(arch_timers_present);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: firmware: scm: Add MSM8996 DT bindings
From: Bjorn Andersson @ 2016-11-18 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479259165-1601-2-git-send-email-spjoshi@codeaurora.org>
On Tue 15 Nov 17:19 PST 2016, Sarangdhar Joshi wrote:
> Add SCM DT bindings for Qualcomm's MSM8996 platform.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> Documentation/devicetree/bindings/firmware/qcom,scm.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> index 3b4436e..20f26fb 100644
> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> @@ -10,8 +10,10 @@ Required properties:
> * "qcom,scm-apq8064" for APQ8064 platforms
> * "qcom,scm-msm8660" for MSM8660 platforms
> * "qcom,scm-msm8690" for MSM8690 platforms
> + * "qcom,scm-msm8996" for MSM8996 platforms
> * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
> - clocks: One to three clocks may be required based on compatible.
> + * No clock required for "qcom,scm-msm8996"
> * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
> * Core, iface, and bus clocks required for "qcom,scm"
> - clock-names: Must contain "core" for the core clock, "iface" for the interface
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* [PATCH v16 07/15] clocksource/drivers/arm_arch_timer: Refactor arch_timer_detect_rate to keep dt code in *_of_init
From: Mark Rutland @ 2016-11-18 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479304148-2965-8-git-send-email-fu.wei@linaro.org>
On Wed, Nov 16, 2016 at 09:49:00PM +0800, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> The patch refactor original arch_timer_detect_rate function:
> (1) Separate out device-tree code, keep them in device-tree init
> function:
> arch_timer_of_init,
> arch_timer_mem_init;
Please write a real commit message.
> (2) Improve original mechanism, if getting from memory-mapped timer
> fail, try arch_timer_get_cntfrq() again.
This is *not* a refactoring. It's completely unrelated to the supposed
refactoring from point (1), and if necessary, should be a separate
patch.
*Why* are you maknig this change? Does some ACPI platform have an MMIO
timer with an ill-configured CNTFRQ register? If so, report that to the
vendor. Don't add yet another needless bodge.
I'd really like to split the MMIO and CP15 timers, and this is yet
another hack that'll make it harder to do so.
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 45 +++++++++++++++++++++++-------------
> 1 file changed, 29 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index af22953..fe4e812 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -487,27 +487,31 @@ static int arch_timer_starting_cpu(unsigned int cpu)
> return 0;
> }
>
> -static void
> -arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
> +static void arch_timer_detect_rate(void __iomem *cntbase)
> {
> /* Who has more than one independent system counter? */
> if (arch_timer_rate)
> return;
> -
> /*
> - * Try to determine the frequency from the device tree or CNTFRQ,
> - * if ACPI is enabled, get the frequency from CNTFRQ ONLY.
> + * If we got memory-mapped timer(cntbase != NULL),
> + * try to determine the frequency from CNTFRQ in memory-mapped timer.
> */
*WHY* ?
If we're sharing arch_timer_rate across MMIO and sysreg timers, the
sysreg value is alreayd sufficient.
If we're not, they should be completely independent.
> - if (!acpi_disabled ||
> - of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
> - if (cntbase)
> - arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
> - else
> - arch_timer_rate = arch_timer_get_cntfrq();
> - }
> + if (cntbase)
> + arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
> + /*
> + * Because in a system that implements both Secure and
> + * Non-secure states, CNTFRQ is only accessible in Secure state.
That's true for the CNTCTLBase frame, but that doesn't matter.
The CNTBase<n> frames should have a readable CNTFRQ.
> + * So the operation above may fail, even if (cntbase != NULL),
> + * especially on ARM64.
> + * In this case, we can try cntfrq_el0(system coprocessor register).
> + */
> + if (!arch_timer_rate)
> + arch_timer_rate = arch_timer_get_cntfrq();
> + else
> + return;
Urrgh.
Please have separate paths to determine the MMIO frequency and the
sysreg frequency, and use the appropriate one for the counter you want
to know the frequency of.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/2] i2c: designware: fix rx fifo depth tracking
From: Russell King @ 2016-11-18 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118193542.GO1041@n2100.armlinux.org.uk>
When loading the TX fifo to receive bytes on the I2C bus, we incorrectly
count the number of bytes:
rx_limit = dev->rx_fifo_depth - dw_readl(dev, DW_IC_RXFLR);
while (buf_len > 0 && tx_limit > 0 && rx_limit > 0) {
if (rx_limit - dev->rx_outstanding <= 0)
break;
rx_limit--;
dev->rx_outstanding++;
}
DW_IC_RXFLR indicates how many bytes are available to be read in the
FIFO, dev->rx_fifo_depth is the FIFO size, and dev->rx_outstanding is
the number of bytes that we've requested to be read so far, but which
have not been read.
Firstly, increasing dev->rx_outstanding and decreasing rx_limit and then
comparing them results in each byte consuming "two" bytes in this
tracking, so this is obviously wrong.
Secondly, the number of bytes that _could_ be received into the FIFO at
any time is the number of bytes we have so far requested but not yet
read from the FIFO - in other words dev->rx_outstanding.
So, in order to request enough bytes to fill the RX FIFO, we need to
request dev->rx_fifo_depth - dev->rx_outstanding bytes.
Modifying the code thusly results in us reaching the maximum number of
bytes outstanding each time we queue more "receive" operations, provided
the transfer allows that to happen.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
With this applied, I now get:
[ 1.726388] i2c_designware 7ffa0000.i2c: transfer terminated early - interrupt latency too high?
[ 1.733813] tda998x 0-0070: Error -5 reading from 0x900
[ 1.737708] tda998x 0-0070: failed to read edid block 0: -5
[ 1.743683] tda998x 0-0070: failed to read EDID
which is a more graceful failure than letting DRM detect the bad
transfer by checking the EDID checksum and hoping that the untransferred
bytes don't result in the EDID checksum succeeding.
drivers/i2c/busses/i2c-designware-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 11e866d05368..9703fe392543 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -611,7 +611,7 @@ i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
if (msgs[dev->msg_write_idx].flags & I2C_M_RD) {
/* avoid rx buffer overrun */
- if (rx_limit - dev->rx_outstanding <= 0)
+ if (dev->rx_outstanding >= dev->rx_fifo_depth)
break;
dw_writel(dev, cmd | 0x100, DW_IC_DATA_CMD);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] i2c: designware: report short transfers
From: Russell King @ 2016-11-18 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118193542.GO1041@n2100.armlinux.org.uk>
Rather than reporting success for a short transfer due to interrupt
latency, report an error both to the caller, as well as to the kernel
log.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/i2c/busses/i2c-designware-core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 9703fe392543..c53058d6139c 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -758,7 +758,7 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
}
/* no error */
- if (likely(!dev->cmd_err)) {
+ if (likely(!dev->cmd_err && !dev->status)) {
ret = num;
goto done;
}
@@ -768,6 +768,11 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
ret = i2c_dw_handle_tx_abort(dev);
goto done;
}
+
+ if (dev->status)
+ dev_err(dev->dev,
+ "transfer terminated early - interrupt latency too high?\n");
+
ret = -EIO;
done:
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox