* [PATCH] pinctrl: meson-axg: adjust spicc pin naming
From: Kevin Hilman @ 2017-12-08 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208152909.15632-1-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> According to datasheet, we should use numbers for the pin naming
> instead of letters. The patch here try to fix this to keep
> the consistency.
>
> This patch should not bring any functional change.
>
> Fixes: 83c566806a68 ("pinctrl: meson-axg: Add new pinctrl driver for Meson AXG SoC")
> Suggested-by: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
> ---
> The issue was raised by Kevin while review the SPI DT part patches, see [1]
> [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005641.html
>
> Note: the 'Fixes' is coming from pinctrl's tree 'for-next' branch
Linus, please consider this change for your next branch. I'd like to
get the names aligned with the datasheet before we have any users in DT.
Thanks,
Kevin
^ permalink raw reply
* [PATCH 1/2] acpi, spcr: Make SPCR avialable to other architectures
From: Prarit Bhargava @ 2017-12-08 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOZdJXV4E6gu=Ed6nOCcEp2afe_g8Ot-H5oO5=6+ye51cv9hUg@mail.gmail.com>
On 12/07/2017 01:43 PM, Timur Tabi wrote:
> On Thu, Dec 7, 2017 at 11:29 AM, Prarit Bhargava <prarit@redhat.com> wrote:
>> Other architectures can use SPCR to setup an early console or console but
>> the current code is ARM64 specific.
>>
>> Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
>> function acpi_arch_setup_console() that can be used for arch-specific
>> setup. Move SPCR initialization flag into ACPI code. Update the
>> Documention on the use of the SPCR earlycon.
>>
>> This patch does not change arm64 behaviour.
>
> Let's hope so. Our E44 erratum work-around has caused lots of
> problems in the past, so the code is a bit fragile.
So it does look like I broke something :( I'll fix this and do more testing.
One thing that I just learned (relative to x86) is that you have to test much
further and wider than on x86.
P.
>
>> +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
>> +{
>> + if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
>> + return false;
>> +
>> + if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
>> + return true;
>> +
>> + if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
>> + h->oem_revision == 1)
>> + return true;
>> +
>> + return false;
>> +}
>
> Please give us a chance to test this patch before merging. We've had a
> lot of problems with our E44 work-around, and we need to make sure
> that qdf2400_erratum_44_present function is called before the pl011
> driver is probed.
>
>> +
>> +/*
>> + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
>> + * register aligned to 32-bit. In addition, the BIOS also encoded the
>> + * access width to be 8 bits. This function detects this errata condition.
>> + */
>> +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
>> +{
>> + bool xgene_8250 = false;
>> +
>> + if (tb->interface_type != ACPI_DBG2_16550_COMPATIBLE)
>> + return false;
>> +
>> + if (memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
>> + memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE))
>> + return false;
>> +
>> + if (!memcmp(tb->header.oem_table_id, "XGENESPC",
>> + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0)
>> + xgene_8250 = true;
>> +
>> + if (!memcmp(tb->header.oem_table_id, "ProLiant",
>> + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1)
>> + xgene_8250 = true;
>> +
>> + return xgene_8250;
>> +}
>
> I suspect that this function has the same issues as
> qdf2400_erratum_44_present().
>
>> +config ACPI_SPCR_TABLE
>> + bool "ACPI Serial Port Console Redirection Support"
>> + default y if ARM64
>> + help
>> + Enable support for Serial Port Console Redirection (SPCR) Table.
>> + This table provides information about the configuration of the
>> + earlycon console.
>> +
>
> So ACPI without SPCR has never been tested by us. Making it optional
> makes me a little nervous. We'll have to evaluate this change.
>
^ permalink raw reply
* [GIT PULL] Amlogic fixes for v4.15-rc (redo v2)
From: Kevin Hilman @ 2017-12-08 19:34 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Here's a re-spin of the Amlogic fixes for v4.15-rc with the DT changes
for new hardware dropped. Will (re)send those for v4.16.
Also, since the last round, I've collected one more fix for a UART clock
naming bug.
Kevin
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-fixes-1
for you to fetch changes up to 39005e562a88c61fa77acef1d2c0cb81ee6b0423:
ARM64: dts: meson-gx: fix UART pclk clock name (2017-12-08 10:39:11 -0800)
----------------------------------------------------------------
Amlogic fixes for v4.15-rc
- GPIO interrupt fixes
- socinfo fix for GX series
- fix typo
----------------------------------------------------------------
Arnaud Patard (1):
meson-gx-socinfo: Fix package id parsing
Colin Ian King (1):
ARM: meson: fix spelling mistake: "Couln't" -> "Couldn't"
Martin Blumenstingl (2):
ARM: dts: meson: correct the sort order for the the gpio_intc node
ARM: dts: meson: fix the memory region of the GPIO interrupt controller
Neil Armstrong (1):
ARM64: dts: meson-gx: fix UART pclk clock name
arch/arm/boot/dts/meson.dtsi | 18 +++++++++---------
arch/arm/mach-meson/platsmp.c | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 6 +++---
drivers/soc/amlogic/meson-gx-socinfo.c | 4 ++--
5 files changed, 17 insertions(+), 17 deletions(-)
^ permalink raw reply
* [PATCH 2/2] usb: musb: davinci: Pass file_mode in platform data
From: Alejandro Mery @ 2017-12-08 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208192355.32735-1-amery@hanoverdisplays.com>
as it was done for glues to allow setting the correct
fifo_mode when multiple MUSB glue layers are built-in
Fixes: 8a77f05aa39b ("usb: musb: Pass fifo_mode in platform data")
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
---
drivers/usb/musb/davinci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 6571f9e59f8f..2632efd3d598 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -472,6 +472,7 @@ static const struct musb_platform_ops davinci_ops = {
.quirks = MUSB_DMA_CPPI,
.init = davinci_musb_init,
.exit = davinci_musb_exit,
+ .fifo_mode = 2,
#ifdef CONFIG_USB_TI_CPPI_DMA
.dma_init = cppi_dma_controller_create,
--
2.15.0
^ permalink raw reply related
* [PATCH 1/2] usb: musb: un-break davinci glue layer
From: Alejandro Mery @ 2017-12-08 19:23 UTC (permalink / raw)
To: linux-arm-kernel
MUSB's davinci glue was made to depend on BROKEN by Felipe Balbi back in
2013 because of lack of active development. needed changes were actually trivial
Fixes: 787f5627bec8 (usb: musb: make davinci and da8xx glues depend on BROKEN)
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
---
drivers/usb/musb/Kconfig | 1 -
drivers/usb/musb/davinci.c | 20 ++++++++++----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 5506a9c03c1f..e13320eebbbf 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -76,7 +76,6 @@ config USB_MUSB_DAVINCI
tristate "DaVinci"
depends on ARCH_DAVINCI_DMx
depends on NOP_USB_XCEIV
- depends on BROKEN
config USB_MUSB_DA8XX
tristate "DA8xx/OMAP-L1x"
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 2ad39dcd2f4c..6571f9e59f8f 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -39,6 +39,7 @@
struct davinci_glue {
struct device *dev;
struct platform_device *musb;
+ struct platform_device *phy;
struct clk *clk;
};
@@ -363,10 +364,8 @@ static int davinci_musb_init(struct musb *musb)
int ret = -ENODEV;
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
- if (IS_ERR_OR_NULL(musb->xceiv)) {
- ret = -EPROBE_DEFER;
- goto unregister;
- }
+ if (IS_ERR_OR_NULL(musb->xceiv))
+ return -EPROBE_DEFER;
musb->mregs += DAVINCI_BASE_OFFSET;
@@ -418,8 +417,6 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb->xceiv);
-unregister:
- usb_phy_generic_unregister();
return ret;
}
@@ -527,7 +524,9 @@ static int davinci_probe(struct platform_device *pdev)
pdata->platform_ops = &davinci_ops;
- usb_phy_generic_register();
+ glue->phy = usb_phy_generic_register();
+ if (IS_ERR(glue->phy))
+ goto err1;
platform_set_drvdata(pdev, glue);
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -563,14 +562,15 @@ static int davinci_probe(struct platform_device *pdev)
if (IS_ERR(musb)) {
ret = PTR_ERR(musb);
dev_err(&pdev->dev, "failed to register musb device: %d\n", ret);
- goto err1;
+ goto err2;
}
return 0;
+err2:
+ usb_phy_generic_unregister(glue->phy);
err1:
clk_disable(clk);
-
err0:
return ret;
}
@@ -580,7 +580,7 @@ static int davinci_remove(struct platform_device *pdev)
struct davinci_glue *glue = platform_get_drvdata(pdev);
platform_device_unregister(glue->musb);
- usb_phy_generic_unregister();
+ usb_phy_generic_unregister(glue->phy);
clk_disable(glue->clk);
return 0;
--
2.15.0
^ permalink raw reply related
* [PATCH v4 4/8] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource
From: Ladislav Michl @ 2017-12-08 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a2f06a16-2468-6b09-171a-ad96e39af3eb@linaro.org>
On Fri, Dec 08, 2017 at 06:50:32PM +0100, Daniel Lezcano wrote:
> On 08/12/2017 18:20, Ladislav Michl wrote:
> > Daniel,
> >
> > On Thu, Dec 07, 2017 at 11:54:27AM +0100, Daniel Lezcano wrote:
> >> On 01/12/2017 06:16, Keerthy wrote:
> >>> Move the dmtimer driver out of plat-omap to clocksource.
> >>> So that non-omap devices also could use this.
> >>>
> >>> No Code changes done to the driver file.
> >>>
> >>> Signed-off-by: Keerthy <j-keerthy@ti.com>
> >>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> >>> ---
> >>>
> >>> Changes in v3:
> >>>
> >>> * Added Sebastian's Reviewed-by.
> >>>
> >>> Changes in v2:
> >>>
> >>> * No code changes in this v2 version. Only enhanced patch
> >>> statistics for renames.
> >>>
> >>> arch/arm/plat-omap/Kconfig | 6 ------
> >>> arch/arm/plat-omap/Makefile | 1 -
> >>> drivers/clocksource/Kconfig | 6 ++++++
> >>> drivers/clocksource/Makefile | 1 +
> >>> {arch/arm/plat-omap => drivers/clocksource}/dmtimer.c | 0
> >>> 5 files changed, 7 insertions(+), 7 deletions(-)
> >>> rename {arch/arm/plat-omap => drivers/clocksource}/dmtimer.c (100%)
> >>
> >> Take the opportunity to rename it timer-dm.c
> >
> > seems the drivers/clocksource subdirectory contains what its name state.
>
> Yes, clocksource, clockevent.
>
> > However OMAP dual mode timers have also event capture capability, which
> > I'd like to use to measure pulse/space width and pass measured values
> > to IR protocol decoders.
> > Do you have any idea how to split code, so that event capture capability
> > could be used by other drivers?
> Not 100% sure but could be drivers/pwm, using the capture API.
I hoped for another answer as pwm_capture is blocking operation while
something event (interrupt) driven would be more usefull.
But that's for different debate, so I'll prepare quick and dirty patch
to start with.
Thank you,
ladis
^ permalink raw reply
* [PATCH v1 1/6] ARM: davinci: clean up map_io functions
From: David Lechner @ 2017-12-08 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0dad9d38-3645-c295-212b-6b66733f633b@ti.com>
On 12/08/2017 09:34 AM, Sekhar Nori wrote:
> On Thursday 07 December 2017 10:44 PM, David Lechner wrote:
>> On 12/07/2017 08:52 AM, Sekhar Nori wrote:
>>> On Saturday 02 December 2017 08:04 AM, David Lechner wrote:
>>>> This cleans up the map_io functions in the board init files for
>>>> mach-davinci.
>>>>
>>>> Most of the boards had a wrapper function around <board>_init(). This
>>>> wrapper is removed and the function is used directly. Additionally, the
>>>> <board>_init() functions are renamed to <board>_map_io() to match the
>>>> field name.
>>>>
>>>> Signed-off-by: David Lechner <david@lechnology.com>
>>>
>>>> diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
>>>> b/arch/arm/mach-davinci/board-dm646x-evm.c
>>>> index cb0a41e..f0e2762 100644
>>>> --- a/arch/arm/mach-davinci/board-dm646x-evm.c
>>>> +++ b/arch/arm/mach-davinci/board-dm646x-evm.c
>>>> @@ -716,16 +716,6 @@ static void __init evm_init_i2c(void)
>>>> ? }
>>>> ? #endif
>>>> ? -#define DM6467T_EVM_REF_FREQ??????? 33000000
>>>> -
>>>> -static void __init davinci_map_io(void)
>>>> -{
>>>> -??? dm646x_init();
>>>
>>> The call to dm646x_init() is dropped here, but I don't see it added
>>> back, at least in this patch.
>>
>> dm646x_init() is renamed to dm646x_map_io(), which is used directly in
>> MACHINE_START().
>
> Ah, I missed that. But I think its a symptom of too many things going on
> in the patch. How about splitting the patch to:
>
> a) Remove trivial <board>_map_io() wrappers and use <soc>_init()
> directly to initialize .map_io
>
> b) Rename <soc>_init() to <soc>_map_io
>
>>
>>>
>>>> diff --git a/arch/arm/mach-davinci/dm646x.c
>>>> b/arch/arm/mach-davinci/dm646x.c
>>>> index da21353..b3be5c8 100644
>>>> --- a/arch/arm/mach-davinci/dm646x.c
>>>> +++ b/arch/arm/mach-davinci/dm646x.c
>>>> @@ -17,6 +17,7 @@
>>>> ? #include <linux/platform_data/edma.h>
>>>> ? #include <linux/platform_data/gpio-davinci.h>
>>>> ? +#include <asm/mach-types.h>
>>>> ? #include <asm/mach/map.h>
>>>> ? ? #include <mach/cputype.h>
>>>> @@ -952,11 +953,16 @@ int __init dm646x_init_edma(struct
>>>> edma_rsv_info *rsv)
>>>> ????? return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
>>>> ? }
>>>> ? -void __init dm646x_init(void)
>>>> +#define DM6467T_EVM_REF_FREQ??????? 33000000
>>>> +
>>>> +void __init dm646x_map_io(void)
>>>> ? {
>>>> ????? davinci_common_init(&davinci_soc_info_dm646x);
>>>> ????? davinci_map_sysmod();
>>>> ????? davinci_clk_init(davinci_soc_info_dm646x.cpu_clks);
>>>> +
>>>> +??? if (machine_is_davinci_dm6467tevm())
>>>> +??????? davinci_set_refclk_rate(DM6467T_EVM_REF_FREQ);
>>>> ? }
>>>
>>> I think we should leave the DM646x case out of this since there are
>>> additional issues like introducing these EVM specific defines in a file
>>> meant for SoC.
>>
>> I agree with the sentiment. This quirk gets moved around several times
>> in this series just to keep things working for a git bisect even if it
>> is not the ideal place for it to be.
>>
>> Currently, all boards use a common reference frequency from the common
>> SoC files instead of the board file. I have not done so in this version
>> of the series, but I could rework it so that this happens, which would
>> remove the need for this quirk altogether. But even then, it would
>> probably get shuffled around a bit before being eliminated.
>
> We should avoid shuffling and modifying the same code repeatedly if we
> can. I think, it will be easier to read if patch 2 and 1 are interchanged.
>
> There is a lot going on and I wasn't sure how that will look so I tried
> it briefly and pushed a branch.
>
> Do have a look, but this seems better to me.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=for-davidl
>
Thank you for the suggestion. I think it will be better as well. I'll
respin the series and we'll see how it works.
^ permalink raw reply
* [PATCH v1 1/6] ARM: davinci: clean up map_io functions
From: David Lechner @ 2017-12-08 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f847539-0425-5d26-a48c-537ed32940ca@ti.com>
On 12/08/2017 09:38 AM, Sekhar Nori wrote:
> On Saturday 02 December 2017 08:04 AM, David Lechner wrote:
>> static int dm355leopard_mmc_get_cd(int module)
>> {
>> if (!gpio_is_valid(leopard_mmc_gpio))
>> @@ -269,7 +264,7 @@ static __init void dm355_leopard_init(void)
>>
>> MACHINE_START(DM355_LEOPARD, "DaVinci DM355 leopard")
>> .atag_offset = 0x100,
>> - .map_io = dm355_leopard_map_io,
>> + .map_io = dm355_map_io,
>> .init_irq = davinci_irq_init,
>> .init_time = davinci_timer_init,
>> .init_machine = dm355_leopard_init,
>
> It seems like spaces were used in original code for indentation. Can you
> please introduce a patch to fix that first since you are now touching
> this part of the code?
Many of the board files have mixed spaces and tabs here. I went with
tabs since the newest commits used tabs. But, yes, I can clean this up.
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gx: fix UART pclk clock name
From: Kevin Hilman @ 2017-12-08 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512378293-22198-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> The clock-names for pclk was wrongly set to "core", but the bindings
> specifies "pclk".
> This was not cathed until the legacy non-documented bindings were removed.
>
> Reported-by: Andreas F?rber <afaerber@suse.de>
> Fixes: f72d6f6037b7 ("ARM64: dts: meson-gx: use stable UART bindings with correct gate clock")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Applied to v4.15/fixes,
Thanks,
Kevin
^ permalink raw reply
* Applied "ASoC: atmel-classd: select correct Kconfig symbol" to the asoc tree
From: Mark Brown @ 2017-12-08 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208141853.3879-1-alexandre.belloni@free-electrons.com>
The patch
ASoC: atmel-classd: select correct Kconfig symbol
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0f0be40ba59c2d5fdfea48e3ff93f6165d616440 Mon Sep 17 00:00:00 2001
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Date: Fri, 8 Dec 2017 15:18:53 +0100
Subject: [PATCH] ASoC: atmel-classd: select correct Kconfig symbol
SND_ATMEL_SOC_CLASSD selects SND_ATMEL_SOC_DMA but the driver itself
handles its own DMA operations and doesn't need anything from
atmel-pcm-dma.c or atmel_ssc_dai.c.
Replace SND_ATMEL_SOC_DMA by SND_SOC_GENERIC_DMAENGINE_PCM which is the
only one actually required.
This may end up in a configuration leading to a link error:
sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
atmel_ssc_dai.c:(.text+0x79c): undefined reference to `atmel_pcm_dma_platform_register'
atmel_ssc_dai.c:(.text+0x79c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_register'
sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_put_audio':
atmel_ssc_dai.c:(.text+0xf24): undefined reference to `atmel_pcm_dma_platform_unregister'
atmel_ssc_dai.c:(.text+0xf24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_unregister'
Tested on sama5d2 xplained with the following configuration
where nothing selects SND_ATMEL_SOC_DMA:
CONFIG_SND_ATMEL_SOC=y
CONFIG_SND_ATMEL_SOC_CLASSD=y
Reported-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e0a25b6d1862 ("ASoC: atmel-classd: add the Audio Class D Amplifier")
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/atmel/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 4a56f3dfba51..dcee145dd179 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -64,7 +64,7 @@ config SND_AT91_SOC_SAM9X5_WM8731
config SND_ATMEL_SOC_CLASSD
tristate "Atmel ASoC driver for boards using CLASSD"
depends on ARCH_AT91 || COMPILE_TEST
- select SND_ATMEL_SOC_DMA
+ select SND_SOC_GENERIC_DMAENGINE_PCM
select REGMAP_MMIO
help
Say Y if you want to add support for Atmel ASoC driver for boards using
--
2.15.1
^ permalink raw reply related
* [PATCH v3 1/3] interconnect: Add generic on-chip interconnect API
From: Amit Kucheria @ 2017-12-08 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170908171830.13813-2-georgi.djakov@linaro.org>
On Fri, Sep 8, 2017 at 10:48 PM, Georgi Djakov <georgi.djakov@linaro.org> wrote:
> This patch introduce a new API to get requirements and configure the
> interconnect buses across the entire chipset to fit with the current demand.
>
> The API is using a consumer/provider-based model, where the providers are
> the interconnect buses and the consumers could be various drivers.
> The consumers request interconnect resources (path) between endpoints and
> set the desired constraints on this data flow path. The providers receive
> requests from consumers and aggregate these requests for all master-slave
> pairs on that path. Then the providers configure each participating in the
> topology node according to the requested data flow path, physical links and
> constraints. The topology could be complicated and multi-tiered and is SoC
> specific.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
> Documentation/interconnect/interconnect.rst | 93 +++++++
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/interconnect/Kconfig | 10 +
> drivers/interconnect/Makefile | 1 +
> drivers/interconnect/interconnect.c | 382 ++++++++++++++++++++++++++++
> include/linux/interconnect-consumer.h | 73 ++++++
> include/linux/interconnect-provider.h | 119 +++++++++
> 8 files changed, 681 insertions(+)
> create mode 100644 Documentation/interconnect/interconnect.rst
> create mode 100644 drivers/interconnect/Kconfig
> create mode 100644 drivers/interconnect/Makefile
> create mode 100644 drivers/interconnect/interconnect.c
> create mode 100644 include/linux/interconnect-consumer.h
> create mode 100644 include/linux/interconnect-provider.h
>
<snip>
> diff --git a/include/linux/interconnect-consumer.h b/include/linux/interconnect-consumer.h
> new file mode 100644
> index 000000000000..6e71bf7a63c0
> --- /dev/null
> +++ b/include/linux/interconnect-consumer.h
> @@ -0,0 +1,73 @@
> +/*
> + * Copyright (c) 2017, Linaro Ltd.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef _LINUX_INTERCONNECT_CONSUMER_H
> +#define _LINUX_INTERCONNECT_CONSUMER_H
> +
> +struct interconnect_node;
> +struct interconnect_path;
> +
> +#if IS_ENABLED(CONFIG_INTERCONNECT)
> +
> +struct interconnect_path *interconnect_get(const char *sdev, const int sid,
> + const char *ddev, const int did);
> +
> +void interconnect_put(struct interconnect_path *path);
> +
> +/**
> + * struct creq - interconnect consumer request
> + * @avg_bw: the average requested bandwidth (over longer period of time) in kbps
> + * @peak_bw: the peak (maximum) bandwidth in kpbs
> + */
> +struct interconnect_creq {
> + u32 avg_bw;
> + u32 peak_bw;
> +};
> +
> +/**
> + * interconnect_set() - set constraints on a path between two endpoints
> + * @path: reference to the path returned by interconnect_get()
> + * @creq: request from the consumer, containing its requirements
> + *
> + * This function is used by an interconnect consumer to express its own needs
> + * in term of bandwidth and QoS for a previously requested path between two
> + * endpoints. The requests are aggregated and each node is updated accordingly.
> + *
> + * Returns 0 on success, or an approproate error code otherwise.
> + */
> +int interconnect_set(struct interconnect_path *path,
> + struct interconnect_creq *creq);
> +
> +#else
> +
> +inline struct interconnect_path *interconnect_get(const char *sdev,
> + const int sid,
> + const char *ddev,
> + const int did)
> +{
> + return ERR_PTR(-ENOTSUPP);
> +}
> +
> +inline void interconnect_put(struct interconnect_path *path)
> +{
> +}
> +
> +inline int interconnect_set(struct interconnect_path *path,
> + struct interconnect_creq *creq);
Remove the semi colon
> +{
> + return -ENOTSUPP
return ERR_PTR(-ENOTSUPP);
> +}
> +
This breaks the build with INTERCONNECT disabled in Kconfig.
^ permalink raw reply
* [PATCH 4/4] PCI: dwc: pci-dra7xx: Fix legacy IRQ handling
From: Lorenzo Pieralisi @ 2017-12-08 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201061311.16691-5-vigneshr@ti.com>
On Fri, Dec 01, 2017 at 11:43:11AM +0530, Vignesh R wrote:
> Legacy INTD IRQ handling is broken on dra7xx due to fact that driver
> uses hwirq in range of 1-4 for INTA, INTD whereas IRQ domain is of size
> 4 which is numbered 0-3. Therefore when INTD IRQ line is used with
> pci-dra7xx driver following warning is seen:
>
> WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:342 irq_domain_associate+0x12c/0x1c4
> error: hwirq 0x4 is too large for dummy
>
> Fix this by using pci_irqd_intx_xlate() helper to translate the INTx 1-4
> range into the 0-3 as done in other PCIe drivers.
>
> Also, iterate over all the INTx bits and call their respective IRQ
> handlers before clearing the status register.
It seems to me that you are fixing two bugs with one patch and therefore
I would ask you to split it in two or explain to me why we should
consider lumping them together.
Thanks,
Lorenzo
> Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
> Reported-by: Chris Welch <Chris.Welch@viavisolutions.com>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
> ---
> drivers/pci/dwc/pci-dra7xx.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index 53f721d1cc40..59e8de34cec6 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -226,6 +226,7 @@ static int dra7xx_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
>
> static const struct irq_domain_ops intx_domain_ops = {
> .map = dra7xx_pcie_intx_map,
> + .xlate = pci_irqd_intx_xlate,
> };
>
> static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
> @@ -256,7 +257,8 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, void *arg)
> struct dra7xx_pcie *dra7xx = arg;
> struct dw_pcie *pci = dra7xx->pci;
> struct pcie_port *pp = &pci->pp;
> - u32 reg;
> + unsigned long reg;
> + u32 virq, bit;
>
> reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI);
>
> @@ -268,8 +270,11 @@ static irqreturn_t dra7xx_pcie_msi_irq_handler(int irq, void *arg)
> case INTB:
> case INTC:
> case INTD:
> - generic_handle_irq(irq_find_mapping(dra7xx->irq_domain,
> - ffs(reg)));
> + for_each_set_bit(bit, ®, PCI_NUM_INTX) {
> + virq = irq_find_mapping(dra7xx->irq_domain, bit);
> + if (virq)
> + generic_handle_irq(virq);
> + }
> break;
> }
>
> --
> 2.15.0
>
^ permalink raw reply
* [PATCH] PCI: xgene: Remove leftover pci_scan_child_bus() call
From: Khuong Dinh @ 2017-12-08 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171121154931.7724-1-lorenzo.pieralisi@arm.com>
Hi Lorenzo,
On Tue, Nov 21, 2017 at 7:49 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> The changes in commit 9af275be15f7 ("PCI: xgene: Convert PCI scan API to
> pci_scan_root_bus_bridge()") converted the xgene PCI host driver to
> the new pci_scan_root_bus_bridge() bus scanning API but erroneously left
> the existing pci_scan_child_bus() call in place which resulted in duplicate
> PCI bus enumerations.
>
> Remove the leftover pci_scan_child_bus() call to properly complete the API
> conversion.
>
> Fixes: 9af275be15f7 ("PCI: xgene: Convert PCI scan API to pci_scan_root_bus_bridge()")
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Tanmay Inamdar <tinamdar@apm.com>
> ---
> drivers/pci/host/pci-xgene.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
> index 465aa2a..e60c457 100644
> --- a/drivers/pci/host/pci-xgene.c
> +++ b/drivers/pci/host/pci-xgene.c
> @@ -668,7 +668,6 @@ static int xgene_pcie_probe(struct platform_device *pdev)
>
> bus = bridge->bus;
>
> - pci_scan_child_bus(bus);
> pci_assign_unassigned_bus_resources(bus);
> list_for_each_entry(child, &bus->children, node)
> pcie_bus_configure_settings(child);
> --
> 2.9.5
>
It is good with X-Gene
Tested-by: Khuong Dinh <kdinh@apm.com>
^ permalink raw reply
* [PATCH v4 4/8] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource
From: Daniel Lezcano @ 2017-12-08 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208172031.GA4146@lenoch>
On 08/12/2017 18:20, Ladislav Michl wrote:
> Daniel,
>
> On Thu, Dec 07, 2017 at 11:54:27AM +0100, Daniel Lezcano wrote:
>> On 01/12/2017 06:16, Keerthy wrote:
>>> Move the dmtimer driver out of plat-omap to clocksource.
>>> So that non-omap devices also could use this.
>>>
>>> No Code changes done to the driver file.
>>>
>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
>>> ---
>>>
>>> Changes in v3:
>>>
>>> * Added Sebastian's Reviewed-by.
>>>
>>> Changes in v2:
>>>
>>> * No code changes in this v2 version. Only enhanced patch
>>> statistics for renames.
>>>
>>> arch/arm/plat-omap/Kconfig | 6 ------
>>> arch/arm/plat-omap/Makefile | 1 -
>>> drivers/clocksource/Kconfig | 6 ++++++
>>> drivers/clocksource/Makefile | 1 +
>>> {arch/arm/plat-omap => drivers/clocksource}/dmtimer.c | 0
>>> 5 files changed, 7 insertions(+), 7 deletions(-)
>>> rename {arch/arm/plat-omap => drivers/clocksource}/dmtimer.c (100%)
>>
>> Take the opportunity to rename it timer-dm.c
>
> seems the drivers/clocksource subdirectory contains what its name state.
Yes, clocksource, clockevent.
> However OMAP dual mode timers have also event capture capability, which
> I'd like to use to measure pulse/space width and pass measured values
> to IR protocol decoders.
> Do you have any idea how to split code, so that event capture capability
> could be used by other drivers?
Not 100% sure but could be drivers/pwm, using the capture API.
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH v4 4/8] arm: OMAP: Move dmtimer driver out of plat-omap to drivers under clocksource
From: Ladislav Michl @ 2017-12-08 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e71f4c7b-e5c7-6305-dc1c-274da6fbf07d@linaro.org>
Daniel,
On Thu, Dec 07, 2017 at 11:54:27AM +0100, Daniel Lezcano wrote:
> On 01/12/2017 06:16, Keerthy wrote:
> > Move the dmtimer driver out of plat-omap to clocksource.
> > So that non-omap devices also could use this.
> >
> > No Code changes done to the driver file.
> >
> > Signed-off-by: Keerthy <j-keerthy@ti.com>
> > Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> > ---
> >
> > Changes in v3:
> >
> > * Added Sebastian's Reviewed-by.
> >
> > Changes in v2:
> >
> > * No code changes in this v2 version. Only enhanced patch
> > statistics for renames.
> >
> > arch/arm/plat-omap/Kconfig | 6 ------
> > arch/arm/plat-omap/Makefile | 1 -
> > drivers/clocksource/Kconfig | 6 ++++++
> > drivers/clocksource/Makefile | 1 +
> > {arch/arm/plat-omap => drivers/clocksource}/dmtimer.c | 0
> > 5 files changed, 7 insertions(+), 7 deletions(-)
> > rename {arch/arm/plat-omap => drivers/clocksource}/dmtimer.c (100%)
>
> Take the opportunity to rename it timer-dm.c
seems the drivers/clocksource subdirectory contains what its name state.
However OMAP dual mode timers have also event capture capability, which
I'd like to use to measure pulse/space width and pass measured values
to IR protocol decoders.
Do you have any idea how to split code, so that event capture capability
could be used by other drivers?
Thank you,
ladis
> > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
> > index 7276afe..afc1a1d 100644
> > --- a/arch/arm/plat-omap/Kconfig
> > +++ b/arch/arm/plat-omap/Kconfig
> > @@ -106,12 +106,6 @@ config OMAP3_L2_AUX_SECURE_SERVICE_SET_ID
> > help
> > PPA routine service ID for setting L2 auxiliary control register.
> >
> > -config OMAP_DM_TIMER
> > - bool "Use dual-mode timer"
> > - depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
> > - help
> > - Select this option if you want to use OMAP Dual-Mode timers.
> > -
> > config OMAP_SERIAL_WAKE
> > bool "Enable wake-up events for serial ports"
> > depends on ARCH_OMAP1 && OMAP_MUX
> > diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
> > index 47e1867..7215ada 100644
> > --- a/arch/arm/plat-omap/Makefile
> > +++ b/arch/arm/plat-omap/Makefile
> > @@ -9,5 +9,4 @@ obj-y := sram.o dma.o counter_32k.o
> >
> > # omap_device support (OMAP2+ only at the moment)
> >
> > -obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
> > obj-$(CONFIG_OMAP_DEBUG_LEDS) += debug-leds.o
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index c729a88..4da66cf 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -46,6 +46,12 @@ config DIGICOLOR_TIMER
> > help
> > Enables the support for the digicolor timer driver.
> >
> > +config OMAP_DM_TIMER
> > + bool "Use dual-mode timer"
> > + depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
> > + help
> > + Select this option if you want to use Dual-Mode timers.
> > +
>
> So in the clocksource directory the rule is the following:
>
> The config option is silent except if COMPILE_TEST is set.
>
> It is the Kconfig's platform which select the driver so there is no deps
> on the ARCH.
>
> config OMAP_DM_TIMER
> bool "Use dual-mode timer" if COMPILE_TEST
> help
> Select this option if you want to use Dual-Mode timers.
>
> Here you will have to make sure the driver compiles on x86.
>
> > config DW_APB_TIMER
> > bool "DW APB timer driver" if COMPILE_TEST
> > help
> > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> > index 72711f1..b077076 100644
> > --- a/drivers/clocksource/Makefile
> > +++ b/drivers/clocksource/Makefile
> > @@ -16,6 +16,7 @@ obj-$(CONFIG_EM_TIMER_STI) += em_sti.o
> > obj-$(CONFIG_CLKBLD_I8253) += i8253.o
> > obj-$(CONFIG_CLKSRC_MMIO) += mmio.o
> > obj-$(CONFIG_DIGICOLOR_TIMER) += timer-digicolor.o
> > +obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
> > obj-$(CONFIG_DW_APB_TIMER) += dw_apb_timer.o
> > obj-$(CONFIG_DW_APB_TIMER_OF) += dw_apb_timer_of.o
> > obj-$(CONFIG_FTTMR010_TIMER) += timer-fttmr010.o
> > diff --git a/arch/arm/plat-omap/dmtimer.c b/drivers/clocksource/dmtimer.c
> > similarity index 100%
> > rename from arch/arm/plat-omap/dmtimer.c
> > rename to drivers/clocksource/dmtimer.c
> >
>
>
> --
> <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4.14] Add support for bq27521 battery monitor
From: Sebastian Reichel @ 2017-12-08 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cfa89227-e08a-849f-c886-723268ae657c@ti.com>
Hi,
On Mon, Dec 04, 2017 at 09:20:33AM -0600, Andrew F. Davis wrote:
> On 12/01/2017 05:06 PM, Pavel Machek wrote:
> > Hi!
> >
> >> This adds basic support for BQ27521 battery monitor, used in Nokia N9
> >> and N950. In particular, battery voltage is important to be able to
> >> tell when the battery is almost empty. Emptying battery on N950 is
> >> pretty painful, as flasher needs to be used to recover phone in such
> >> case.
> >
> > Sebastian, ping? This one should not be too controversial.
>
> Acked-by: Andrew F. Davis <afd@ti.com>
Thanks, queued, I dropped the spurious change in twl.h and added the
dt-binding from the previous patch version, that was lost somehow.
> > If you could also apply the "shut down when battery is low", that
> > would be nice.
I only have one with values specific to N900 hardcoded in the
driver. That one can't be applied for obvious reasons.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171208/e6e946c7/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] firmware: qcom: scm: Fix incorrect of_node_put call in scm_init
From: Stephen Boyd @ 2017-12-08 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c049d689-44f0-3ee6-ca50-af4873545fce@baylibre.com>
On 12/07, Loys Ollivier wrote:
>
>
> On 07/12/2017 09:42, Jerome Forissier wrote:
> >
> >
> > On 12/06/2017 09:06 PM, Stephen Boyd wrote:
> >> On 12/06, Loys Ollivier wrote:
> >>> When using other platform architectures, in the init of the qcom_scm
> >>> driver, of_node_put is called on /firmware if no qcom dt is found.
> >>> This results in a kernel error: Bad of_node_put() on /firmware.
> >>>
> >>> The call to of_node_put from the qcom_scm init is unnecessary as
> >>> of_find_matching_node is calling it automatically.
> >>>
> >>> Remove this of_node_put().
> >>>
> >>> Fixes: d0f6fa7ba2d6 ("firmware: qcom: scm: Convert SCM to platform driver")
> >>> Signed-off-by: Loys Ollivier <lollivier@baylibre.com>
> >>> ---
> >>
> >> This still looks wrong. Especially if of_find_matching_node() is
> >> going to look for siblings of the /firmware node for the
> >> compatible string for scm device. Why do we check at all? Can't
> >> we just delete this and let of_platform_populate() take care of
> >> it? BTW, OP-TEE driver seems to have a similar problem.
> >
> > https://lkml.org/lkml/2017/11/29/230
> >
> Well, the patch I sent is a fix for a specific bug I am encountering.
> I tested the patch and it solves my problem. Stephen, your changes looks
> good but it's a change in the driver's behavior. Maybe it could be
> another patch ?
Sure. But there's another of_node_put(fw_np) in this function, so
why isn't that also removed? Assuming of_find_matching_node() is
calling of_node_put() on what's passed in, then the node is going
to get put twice in the "working" case.
Andy?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* next/master boot: 270 boots: 35 failed, 213 passed with 20 offline, 2 untried/unknown (next-20171207)
From: Stephen Boyd @ 2017-12-08 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ad6d330-d277-85ae-b891-cb76367461ce@samsung.com>
On 12/08, Marek Szyprowski wrote:
> Hi Krzysztof,
>
> On 2017-12-08 13:33, Krzysztof Kozlowski wrote:
> >On Fri, Dec 8, 2017 at 1:27 PM, Mark Brown <broonie@kernel.org> wrote:
> >>On Fri, Dec 08, 2017 at 12:20:07PM +0000, Mark Brown wrote:
> >>>On Thu, Dec 07, 2017 at 03:54:47PM -0800, kernelci.org bot wrote:
> >>>
> >>>Today's -next failed to boot on peach-pi:
> >>>
> >>>> exynos_defconfig:
> >>>> exynos5800-peach-pi:
> >>>> lab-collabora: new failure (last pass: next-20171205)
> >>>with details at https://kernelci.org/boot/id/5a2a2e7859b5141bc2afa17c/
> >>>(including logs and comparisons with other boots, the last good boot was
> >>>Wednesday). It looks like it hangs somewhere late on in boot, the last
> >>>output on the console is:
> >>>
> >>>[ 4.827139] smsc95xx 3-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.3.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:03:c0
> >>>[ 5.781037] dma-pl330 3880000.adma: Loaded driver for PL330 DMAC-241330
> >>>[ 5.786247] dma-pl330 3880000.adma: DBUFF-4x8bytes Num_Chans-6 Num_Peri-16 Num_Events-6
> >>>[ 5.819200] dma-pl330 3880000.adma: PM domain MAU will not be powered off
> >>>[ 64.529228] random: crng init done
> >>>
> >>>and there's failures earlier to instantiate the display.
> >>I just noticed that further up the log there's a lockdep splat with a
> >>conflict between the genpd and clock API locking - an ABBA issue with
> >>genpd->mlock and the clock API prepare_lock.
> >+Cc Marek Szyprowski,
> >
> >The lockdep issue and display failures (including regulator warning)
> >were present for some time. They also appear in boot log for
> >next-20171206 (https://storage.kernelci.org/next/master/next-20171206/arm/exynos_defconfig/lab-collabora/boot-exynos5800-peach-pi.html).
> >The difference is that 20171208 hangs on "random: crng init done"
> >which did not appear before at all.
I haven't looked at the lockdep splat yet, but is that happening
because of runtime PM usage by the clk framework?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3 07/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_sregs
From: David Hildenbrand @ 2017-12-08 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-8-cdall@kernel.org>
>
> int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index f647e121070e..cdf0be02c95a 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1632,18 +1632,25 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> {
> int ret;
>
> + vcpu_load(vcpu);
> +
> + ret = -EINVAL;
you can initialize this directly.
> if (vcpu->arch.pvr != sregs->pvr)
> - return -EINVAL;
> + goto out;
>
> ret = set_sregs_base(vcpu, sregs);
> if (ret < 0)
> - return ret;
> + goto out;
>
> ret = set_sregs_arch206(vcpu, sregs);
> if (ret < 0)
> - return ret;
> + goto out;
> +
> + ret = vcpu->kvm->arch.kvm_ops->set_sregs(vcpu, sregs);
>
> - return vcpu->kvm->arch.kvm_ops->set_sregs(vcpu, sregs);
> +out:
> + vcpu_put(vcpu);
> + return ret;
> }
>
> int kvmppc_get_one_reg(struct kvm_vcpu *vcpu, u64 id,
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 18011fc4ac49..d95b4f15e52b 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2729,8 +2729,12 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> struct kvm_sregs *sregs)
> {
> + vcpu_load(vcpu);
> +
> memcpy(&vcpu->run->s.regs.acrs, &sregs->acrs, sizeof(sregs->acrs));
> memcpy(&vcpu->arch.sie_block->gcr, &sregs->crs, sizeof(sregs->crs));
> +
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 20a5f6776eea..a31a80aee0b9 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7500,15 +7500,19 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> int mmu_reset_needed = 0;
> int pending_vec, max_bits, idx;
> struct desc_ptr dt;
> + int ret;
> +
> + vcpu_load(vcpu);
>
> + ret = -EINVAL;
dito
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH v3 06/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_get_sregs
From: David Hildenbrand @ 2017-12-08 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-7-cdall@kernel.org>
On 04.12.2017 21:35, Christoffer Dall wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_get_sregs().
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/powerpc/kvm/book3s.c | 8 +++++++-
> arch/powerpc/kvm/booke.c | 9 ++++++++-
> arch/s390/kvm/kvm-s390.c | 4 ++++
> arch/x86/kvm/x86.c | 3 +++
> virt/kvm/kvm_main.c | 2 --
> 5 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index 24bc7aabfc44..6cc2377549f7 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -484,7 +484,13 @@ void kvmppc_subarch_vcpu_uninit(struct kvm_vcpu *vcpu)
> int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
> struct kvm_sregs *sregs)
> {
> - return vcpu->kvm->arch.kvm_ops->get_sregs(vcpu, sregs);
> + int ret;
> +
> + vcpu_load(vcpu);
> + ret = vcpu->kvm->arch.kvm_ops->get_sregs(vcpu, sregs);
> + vcpu_put(vcpu);
> +
> + return ret;
> }
>
> int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index bcbbeddc3430..f647e121070e 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1613,11 +1613,18 @@ int kvmppc_set_sregs_ivor(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
> int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
> struct kvm_sregs *sregs)
> {
> + int ret;
> +
> + vcpu_load(vcpu);
> +
> sregs->pvr = vcpu->arch.pvr;
>
> get_sregs_base(vcpu, sregs);
> get_sregs_arch206(vcpu, sregs);
> - return vcpu->kvm->arch.kvm_ops->get_sregs(vcpu, sregs);
> + ret = vcpu->kvm->arch.kvm_ops->get_sregs(vcpu, sregs);
> +
> + vcpu_put(vcpu);
> + return ret;
> }
>
> int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index e3476430578a..18011fc4ac49 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2737,8 +2737,12 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
> int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
> struct kvm_sregs *sregs)
> {
> + vcpu_load(vcpu);
> +
> memcpy(&sregs->acrs, &vcpu->run->s.regs.acrs, sizeof(sregs->acrs));
> memcpy(&sregs->crs, &vcpu->arch.sie_block->gcr, sizeof(sregs->crs));
> +
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 75eacce78f59..20a5f6776eea 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7400,6 +7400,8 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
> {
> struct desc_ptr dt;
>
> + vcpu_load(vcpu);
> +
> kvm_get_segment(vcpu, &sregs->cs, VCPU_SREG_CS);
> kvm_get_segment(vcpu, &sregs->ds, VCPU_SREG_DS);
> kvm_get_segment(vcpu, &sregs->es, VCPU_SREG_ES);
> @@ -7431,6 +7433,7 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
> set_bit(vcpu->arch.interrupt.nr,
> (unsigned long *)sregs->interrupt_bitmap);
>
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 963e249d7b79..779c03e39fa4 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2581,9 +2581,7 @@ static long kvm_vcpu_ioctl(struct file *filp,
> r = -ENOMEM;
> if (!kvm_sregs)
> goto out;
> - vcpu_load(vcpu);
> r = kvm_arch_vcpu_ioctl_get_sregs(vcpu, kvm_sregs);
> - vcpu_put(vcpu);
> if (r)
> goto out;
> r = -EFAULT;
>
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH v3 05/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_regs
From: David Hildenbrand @ 2017-12-08 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-6-cdall@kernel.org>
On 04.12.2017 21:35, Christoffer Dall wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_regs().
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/mips/kvm/mips.c | 3 +++
> arch/powerpc/kvm/book3s.c | 3 +++
> arch/powerpc/kvm/booke.c | 3 +++
> arch/s390/kvm/kvm-s390.c | 2 ++
> arch/x86/kvm/x86.c | 3 +++
> virt/kvm/kvm_main.c | 2 --
> 6 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index adfca57420d1..3a898712d6cd 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -1151,6 +1151,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> int i;
>
> + vcpu_load(vcpu);
> +
> for (i = 1; i < ARRAY_SIZE(vcpu->arch.gprs); i++)
> vcpu->arch.gprs[i] = regs->gpr[i];
> vcpu->arch.gprs[0] = 0; /* zero is special, and cannot be set. */
> @@ -1158,6 +1160,7 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> vcpu->arch.lo = regs->lo;
> vcpu->arch.pc = regs->pc;
>
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index d85bfd733ccd..24bc7aabfc44 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -528,6 +528,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> int i;
>
> + vcpu_load(vcpu);
> +
> kvmppc_set_pc(vcpu, regs->pc);
> kvmppc_set_cr(vcpu, regs->cr);
> kvmppc_set_ctr(vcpu, regs->ctr);
> @@ -548,6 +550,7 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
> kvmppc_set_gpr(vcpu, i, regs->gpr[i]);
>
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index e0e4f04c5535..bcbbeddc3430 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1462,6 +1462,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> int i;
>
> + vcpu_load(vcpu);
> +
> vcpu->arch.pc = regs->pc;
> kvmppc_set_cr(vcpu, regs->cr);
> vcpu->arch.ctr = regs->ctr;
> @@ -1483,6 +1485,7 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
> kvmppc_set_gpr(vcpu, i, regs->gpr[i]);
>
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 37b7caae2484..e3476430578a 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2712,7 +2712,9 @@ static int kvm_arch_vcpu_ioctl_initial_reset(struct kvm_vcpu *vcpu)
>
> int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> + vcpu_load(vcpu);
> memcpy(&vcpu->run->s.regs.gprs, ®s->gprs, sizeof(regs->gprs));
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 597e1f8fc8da..75eacce78f59 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7350,6 +7350,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>
> int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> + vcpu_load(vcpu);
> +
> vcpu->arch.emulate_regs_need_sync_from_vcpu = true;
> vcpu->arch.emulate_regs_need_sync_to_vcpu = false;
>
> @@ -7379,6 +7381,7 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>
> kvm_make_request(KVM_REQ_EVENT, vcpu);
>
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 843d481f58cb..963e249d7b79 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2572,9 +2572,7 @@ static long kvm_vcpu_ioctl(struct file *filp,
> r = PTR_ERR(kvm_regs);
> goto out;
> }
> - vcpu_load(vcpu);
> r = kvm_arch_vcpu_ioctl_set_regs(vcpu, kvm_regs);
> - vcpu_put(vcpu);
> kfree(kvm_regs);
> break;
> }
>
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH v3 04/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_get_regs
From: David Hildenbrand @ 2017-12-08 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-5-cdall@kernel.org>
On 04.12.2017 21:35, Christoffer Dall wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_get_regs().
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/mips/kvm/mips.c | 3 +++
> arch/powerpc/kvm/book3s.c | 3 +++
> arch/powerpc/kvm/booke.c | 3 +++
> arch/s390/kvm/kvm-s390.c | 2 ++
> arch/x86/kvm/x86.c | 3 +++
> virt/kvm/kvm_main.c | 2 --
> 6 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
> index b5c28f0730f8..adfca57420d1 100644
> --- a/arch/mips/kvm/mips.c
> +++ b/arch/mips/kvm/mips.c
> @@ -1165,6 +1165,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> int i;
>
> + vcpu_load(vcpu);
> +
> for (i = 0; i < ARRAY_SIZE(vcpu->arch.gprs); i++)
> regs->gpr[i] = vcpu->arch.gprs[i];
>
> @@ -1172,6 +1174,7 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> regs->lo = vcpu->arch.lo;
> regs->pc = vcpu->arch.pc;
>
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index 72d977e30952..d85bfd733ccd 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -497,6 +497,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> int i;
>
> + vcpu_load(vcpu);
> +
> regs->pc = kvmppc_get_pc(vcpu);
> regs->cr = kvmppc_get_cr(vcpu);
> regs->ctr = kvmppc_get_ctr(vcpu);
> @@ -518,6 +520,7 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
> regs->gpr[i] = kvmppc_get_gpr(vcpu, i);
>
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 83b485810aea..e0e4f04c5535 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1431,6 +1431,8 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> int i;
>
> + vcpu_load(vcpu);
> +
> regs->pc = vcpu->arch.pc;
> regs->cr = kvmppc_get_cr(vcpu);
> regs->ctr = vcpu->arch.ctr;
> @@ -1452,6 +1454,7 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> for (i = 0; i < ARRAY_SIZE(regs->gpr); i++)
> regs->gpr[i] = kvmppc_get_gpr(vcpu, i);
>
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 2b3e874ea76c..37b7caae2484 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2718,7 +2718,9 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
>
> int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> + vcpu_load(vcpu);
> memcpy(®s->gprs, &vcpu->run->s.regs.gprs, sizeof(regs->gprs));
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index d9deb6222055..597e1f8fc8da 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7309,6 +7309,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
>
> int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> {
> + vcpu_load(vcpu);
> +
> if (vcpu->arch.emulate_regs_need_sync_to_vcpu) {
> /*
> * We are here if userspace calls get_regs() in the middle of
> @@ -7342,6 +7344,7 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
> regs->rip = kvm_rip_read(vcpu);
> regs->rflags = kvm_get_rflags(vcpu);
>
> + vcpu_put(vcpu);
> return 0;
> }
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 198f2f9edcaf..843d481f58cb 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2552,9 +2552,7 @@ static long kvm_vcpu_ioctl(struct file *filp,
> kvm_regs = kzalloc(sizeof(struct kvm_regs), GFP_KERNEL);
> if (!kvm_regs)
> goto out;
> - vcpu_load(vcpu);
> r = kvm_arch_vcpu_ioctl_get_regs(vcpu, kvm_regs);
> - vcpu_put(vcpu);
> if (r)
> goto out_free1;
> r = -EFAULT;
>
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
^ permalink raw reply
* [Patch v6 05/12] [media] videodev2.h: Add v4l2 definition for HEVC
From: Mauro Carvalho Chehab @ 2017-12-08 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512748044.24635.1.camel@ndufresne.ca>
Em Fri, 08 Dec 2017 10:47:24 -0500
Nicolas Dufresne <nicolas@ndufresne.ca> escreveu:
> Le vendredi 08 d?cembre 2017 ? 14:38 +0530, Smitha T Murthy a ?crit :
> > Add V4L2 definition for HEVC compressed format
> >
> > Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
> > Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> > Reviewed-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> > Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
> > ---
> > include/uapi/linux/videodev2.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 185d6a0..bd9b5d5 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -634,6 +634,7 @@ struct v4l2_pix_format {
> > #define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE 421M Annex L compliant stream */
> > #define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
> > #define V4L2_PIX_FMT_VP9 v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
> > +#define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /* HEVC aka H.265 */
>
> Wouldn't it be more consistent to call it V4L2_PIX_FMT_H265 as we have
> used H264 for the previous generation, or is there a formal rationale ?
It would, but what I'm afraid on using specs name here, due to what
happened with MPEG-4 specs. Originally, it was referred to one codec
(ASP). Then, part 10 came with a different compression codec (AVC). So,
now, when referring to MPEG-4, one need to explicitly mention if the code
is AVC or not. The ITU-T didn't make the same mistake (yet?), but nobody
can predict what will happen in the future.
So, now that an spec can be modified to include additional parts with
different codecs, it sounds less risky to use the codec name instead
of the spec number, as this shouldn't change :-)
> Also, this is byte-stream right ? With start codes ?
>
> >
> > /* Vendor-specific formats */
> > #define V4L2_PIX_FMT_CPIA1 v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
Thanks,
Mauro
^ permalink raw reply
* [PATCH 0/2] acpi, x86: Add SPCR table support
From: Prarit Bhargava @ 2017-12-08 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd727a15-c697-741f-864b-8b48b8e5e272@codeaurora.org>
On 12/08/2017 10:31 AM, Jeffrey Hugo wrote:
> On 12/8/2017 7:29 AM, Prarit Bhargava wrote:
>>
>>
>> On 12/08/2017 01:29 AM, Ingo Molnar wrote:
>>>
>>> * Prarit Bhargava <prarit@redhat.com> wrote:
>>>
>>>> The SPCR (Serial Port Console Redirection) Table provides information
>>>> about the configuration of serial port. This information can be used
>>>> to configure the early console.
>>>
>>> s/about the configuration of serial port
>>> /about the configuration of the serial port
>>>
>>>> SPCR support was added for arm64 and is made available across all arches
>>>> in this patchset. The first patch adds a weak per-arch configuration function
>>>> and moves the SPCR code into ACPI. The second patch adds support to x86.
>>>>
>>>> The existing behaviour on arm64 is maintained. If the SPCR exists the
>>>> earlycon and console are automatically configured.
>>>
>>> s/arm64
>>> /ARM64
>>>
>>> which is easier to read and it's also the prevalent spelling:
>>>
>>> triton:~/tip> for N in $(git grep -ih arm64 arch/arm64/ | sed
>>> 's/[[:punct:]]/ /g'); do echo $N | grep -iw arm64; done | sort | uniq -c
>>> 412 arm64
>>> 1 Arm64
>>> 854 ARM64
>>>
>>>> The existing default behaviour on x86 is also maintained. If no console or
>>>> earlycon parameter is defined and the SPCR exists , the serial port is not
>>>> configured. If the earlycon parameter is used both the early console
>>>> and the console are configured using the data from the SPCR.
>>>
>>> s/exists , the
>>> /exists, the
>>>
>>> But, the logic to not use the SPCR looks confusing to me.
>>>
>>> The SPCR is only present if the user has explicitly configured a serial console
>>> for that machine, either in the firmware, or remotely via IPMI, correct? I.e.
>>> SPCR
>>> will not be spuriously present by default on systems that have a serial console
>>> but the user never expressed any interest for them, right?
>>
>> If I disable "Serial Port Console Debug" in my BIOS I still see the SPCR
>> configured:
>>
>> [root at prarit-lab ~]# dmesg | grep SPCR
>> [ 0.000000] ACPI: SPCR 0x0000000069031000 000050 (v01
>> 00000000 00000000)
>>
>> AFAICT the SPCR is always enabled on some systems.
>
> "Serial Port Console Debug" sounds like DBG2 to me, although I am unsure of the
> specific platform you are referencing.
>
>>
>>>
>>> If so then we should pick up that serial console configuration and activate it,
>>> regardless of any kernel boot options!
>>
>> I'm worried about someone who doesn't want a console on ttyS0 suddenly ending up
>> with one. The SPCR could contain incorrect data, etc.
>>
>> I originally wanted this on by default, but the chances of breaking someone's
>> setup seems significant doesn't it? Maybe I'm being too cautious. Anyone else
>> want to weigh in? I'm not ignoring your idea Ingo, I'm just worried about being
>> yelled at by a user :) because I broke their default console setup.
>>
>
> SPCR is always present on QDF2400 (ARM64 platform). Firmware will automatically
> update the SPCR table to point to the correct console (IE Serial-over-LAN or SOL
> if configured via IPMI). Unless a user specifically chooses to override the
> SPCR via "console=", we expect that a console will be present based on the data
> in SPCR.
Hey Jeffrey -- I think Ingo's & my conversation is x86-specific. I am *NOT*
changing the behaviour on ARM64.
P.
>
^ permalink raw reply
* [RESEND PATCH V2] ARM: dts: introduce the sama5d2 ptc ek board
From: Alexandre Belloni @ 2017-12-08 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207082453.10593-1-ludovic.desroches@microchip.com>
On 07/12/2017 at 09:24:53 +0100, Ludovic Desroches wrote:
> Add the official SAMA5D2 Peripheral Touch Controller Evaluation
> Kit board.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> ---
> Resend: Put SPDX-License-Identifier at the beginning of the file.
>
> Changes:
> - v2:
> - remove memory node
> - use SPDX-License-Identifier
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts | 401 ++++++++++++++++++++++++++++++
> 2 files changed, 402 insertions(+)
> create mode 100644 arch/arm/boot/dts/at91-sama5d2_ptc_ek.dts
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ 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