* [PATCH 2/3] ARM: configs: stm32: Enable ARM_MPU
From: Alexandre Torgue @ 2017-12-12 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513101746-18030-1-git-send-email-alexandre.torgue@st.com>
STM32 MCUs embed a Memory Protection Unit. Enabling this setting will
allow the Kernel to configure the MPU according to devicetree.
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index bb358ff..e642bdf9 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -24,6 +24,7 @@ CONFIG_SET_MEM_PARAM=y
CONFIG_DRAM_BASE=0x90000000
CONFIG_FLASH_MEM_BASE=0x08000000
CONFIG_FLASH_SIZE=0x00200000
+CONFIG_ARM_MPU=y
CONFIG_PREEMPT=y
# CONFIG_ATAGS is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: stm32: enable dma on MCU which embed a cortex-M7
From: Alexandre Torgue @ 2017-12-12 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513101746-18030-1-git-send-email-alexandre.torgue@st.com>
Enable dma1 and dma2 on:
-stm32746g-eval board
-stm32f769-disco board
-stm32h743i-disco board
-stm32h743i-eval board
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
diff --git a/arch/arm/boot/dts/stm32746g-eval.dts b/arch/arm/boot/dts/stm32746g-eval.dts
index 3f52a7b..2662a27 100644
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@ -113,6 +113,14 @@
status = "okay";
};
+&dma1 {
+ status = "okay";
+};
+
+&dma2 {
+ status = "okay";
+};
+
&i2c1 {
pinctrl-0 = <&i2c1_pins_b>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/stm32f769-disco.dts b/arch/arm/boot/dts/stm32f769-disco.dts
index 08699a2..b9b1ffd 100644
--- a/arch/arm/boot/dts/stm32f769-disco.dts
+++ b/arch/arm/boot/dts/stm32f769-disco.dts
@@ -86,6 +86,14 @@
clock-frequency = <25000000>;
};
+&dma1 {
+ status = "okay";
+};
+
+&dma2 {
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins_a>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/stm32h743i-disco.dts b/arch/arm/boot/dts/stm32h743i-disco.dts
index 104545a..2d9e553 100644
--- a/arch/arm/boot/dts/stm32h743i-disco.dts
+++ b/arch/arm/boot/dts/stm32h743i-disco.dts
@@ -79,6 +79,14 @@
clock-frequency = <125000000>;
};
+&dma1 {
+ status = "okay";
+};
+
+&dma2 {
+ status = "okay";
+};
+
&usart2 {
pinctrl-0 = <&usart2_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts b/arch/arm/boot/dts/stm32h743i-eval.dts
index 5bd4b16..3face6a 100644
--- a/arch/arm/boot/dts/stm32h743i-eval.dts
+++ b/arch/arm/boot/dts/stm32h743i-eval.dts
@@ -97,6 +97,14 @@
clock-frequency = <25000000>;
};
+&dma1 {
+ status = "okay";
+};
+
+&dma2 {
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: verify size of zImage
From: Ard Biesheuvel @ 2017-12-12 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mv2oq67r.fsf@free-electrons.com>
On 12 December 2017 at 16:08, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> Hi Ard,
>
> On mar., nov. 28 2017, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> (+ Gregory)
>>
>> On 28 November 2017 at 16:27, Russell King <rmk+kernel@armlinux.org.uk> wrote:
>>> The linker can sometimes add additional sections to the zImage ELF file
>>> which results in the zImage binary being larger than expected. This
>>> causes appended DT blobs to fail.
>>>
>>> Verify that the zImage binary is the expected size, and fail the build
>>> if this is not the case.
>>>
>>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>>> ---
>>> As this patch is different, I've dropped Matthias' tested-by. I'd
>>> appreciate a replacement, thanks. Also, I seem to remember that
>>> Ard's toolchain was giving issues - maybe this alternative will
>>> finally resolve them.
>>>
>>
>> $ nm arch/arm/boot/compressed/vmlinux |grep _edata
>> 007b8200 D _edata
>> 007b8200 D _edata_real
>>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> although I don't remember seeing this fail. It think it may have been
>> Gregory who was having these issues?
>
> Thanks to remember me, I finally find time to test it, and with my setup
> I didn't have anymore issue while building it for a dtb append zImage
> for Armada XP:
>
> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
Thanks for confirming.
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Ladislav Michl @ 2017-12-12 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212170054.GD14441@atomide.com>
On Tue, Dec 12, 2017 at 09:00:54AM -0800, Tony Lindgren wrote:
> Hmm what do you mean? We don't want to export tons of custom functions from
> the timers in and then be in trouble when at some point we have a Linux
> generic hw timer framework. We already had to deal with these custom
> exports earlier with conversion to multiarch and then again with
> device tree.
>
> For now, it's best to pass the timer information to the pwm driver in
> platform data. In the long run that will be much easier to deal with than
> fixing random drivers tinkering with the timer registers directly.
All that register access would happen only in drivers/clocksource/timer-dm.c?
So platform data will hold all function pointers needed for event capture
and the pwm driver will do only interface to pwm framework.
> Ideally the pwm driver would just do a request_irq from the dmtimer code
> where dmtimer code would implement an interrupt controller. That would
> be already most fo the Linux generic hardware timer framework right there :)
I do not follow. Each general-purpose timer module has its own interrupt line,
so claiming that irq directly using request_irq seems enough. Could you
explain interrupt controller idea a bit more?
Thank you,
ladis
^ permalink raw reply
* [PATCH v2] PCI: keystone: fix interrupt-controller-node lookup
From: Lorenzo Pieralisi @ 2017-12-12 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212172537.GB53955@bhelgaas-glaptop.roam.corp.google.com>
On Tue, Dec 12, 2017 at 11:25:37AM -0600, Bjorn Helgaas wrote:
> On Mon, Dec 11, 2017 at 10:42:33AM +0000, Lorenzo Pieralisi wrote:
> > On Mon, Dec 11, 2017 at 11:29:55AM +0100, Johan Hovold wrote:
> > > On Fri, Nov 17, 2017 at 02:38:31PM +0100, Johan Hovold wrote:
> > > > Fix child-node lookup during initialisation which was using the wrong
> > > > OF-helper and ended up searching the whole device tree depth-first
> > > > starting at the parent rather than just matching on its children.
> > > >
> > > > To make things worse, the parent pci node could end up being prematurely
> > > > freed as of_find_node_by_name() drops a reference to its first argument.
> > > > Any matching child interrupt-controller node was also leaked.
> > > >
> > > > Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
> > > > Cc: stable <stable@vger.kernel.org> # 3.18
> > > > Acked-by: Murali Karicheri <m-karicheri2@ti.com>
> > > > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > ---
> > > >
> > > > v2
> > > > - amend commit message and mention explicitly that of_find_node_by_name()
> > > > drops a reference to the start node
> > > > - add Murali's and Lorenzo's acks
> > >
> > > This one hasn't shown up in linux-next, so sending a reminder to make
> > > sure it doesn't fall between the cracks.
> >
> > Hi Johan,
> >
> > yes it is in the list of fixes to be sent upstream - I was about to
> > ask Bjorn to apply it.
>
> Is this something that needs to be merged for v4.15? If so, I need to
> be able to defend it to Linus as being a critical fix. If the issue
> been around for 3 years (v3.18 was tagged Dec 7 2014), that requires
> pretty "clear and present danger."
>
> From the commit log, I see a sub-optimal search (not critical), a
> possible use-after-free (could conceivably be critical if people are
> tripping over this, but would need more specifics about that), and a
> leak (not critical).
>
> Given what I can see now, my inclination would be for Lorenzo to queue
> it for v4.16, which would still get in linux-next soonish.
It is fine by me and I think, as already mentioned, that the stable
tag is dubious so I will probably drop it.
Lorenzo
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Fabio Estevam @ 2017-12-12 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212173450.GD10595@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Dec 12, 2017 at 3:34 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> It's fundamentally unsafe.
>
> You need to test with CONFIG_BL_SWITCHER enabled - there's spinlocks
> in smp_call_function_single() path that are conditional on that symbol.
> If CONFIG_BL_SWITCHER is disabled, then the spinlocks are not present.
Ok, just tested with CONFIG_BL_SWITCHER=y on a imx6q-cubox-i:
# echo enabled > /sys/class/tty/ttymxc0/power/wakeup
# echo mem > /sys/power/state
[ 10.503462] PM: suspend entry (deep)
[ 10.507479] PM: Syncing filesystems ... done.
[ 10.555024] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 10.564511] OOM killer disabled.
[ 10.567760] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) d.
[ 10.577420] Suspending console(s) (use no_console_suspend to debug)
[ 10.657748] PM: suspend devices took 0.080 seconds
[ 10.669329] Disabling non-boot CPUs ...
[ 10.717049] IRQ17 no longer affine to CPU1
[ 10.837141] Enabling non-boot CPUs ...
[ 10.839386] CPU1 is up
[ 10.840342] CPU2 is up
[ 10.841300] CPU3 is up
[ 11.113735] mmc0: queuing unknown CIS tuple 0x80 (2 bytes)
[ 11.115676] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[ 11.117595] mmc0: queuing unknown CIS tuple 0x80 (3 bytes)
[ 11.121014] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[ 11.124454] mmc0: queuing unknown CIS tuple 0x80 (7 bytes)
[ 11.177299] ata1: SATA link down (SStatus 0 SControl 300)
[ 11.181930] PM: resume devices took 0.330 seconds
[ 11.243729] OOM killer enabled.
[ 11.246886] Restarting tasks ... done.
[ 11.253012] PM: suspend exit
^ permalink raw reply
* [PATCH v2] arm64: cpu_errata: Add Kryo to Falkor 1003 errata
From: Will Deacon @ 2017-12-12 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129230353.11809-1-sboyd@codeaurora.org>
Hi Stephen,
On Wed, Nov 29, 2017 at 03:03:53PM -0800, Stephen Boyd wrote:
> The Kryo CPUs are also affected by the Falkor 1003 errata, so
> we need to do the same workaround on Kryo CPUs. The MIDR is
> slightly more complicated here, where the PART number is not
> always the same when looking at all the bits from 15 to 4. Drop
> the lower 8 bits and just look at the top 4 to see if it's '2'
> and then consider those as Kryo CPUs. This covers all the
> combinations without having to list them all out.
>
> Introduce a new hardware cap bit for the combination of hardware
> PAN support and this errata so that we can disable support for
> software PAN at runtime if this errata is present and the CPU
> doesn't support HW PAN. This happens on some Kryo CPUs where the
> HW PAN feature isn't supported but we can't prevent software PAN
> from being selected in the configuration. Previously, Falkor CPUs
> were all known to have HW PAN support, so we didn't need to worry
> about this case.
>
> Fixes: 38fd94b0275c ("arm64: Work around Falkor erratum 1003")
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
Can you respin this on top of for-next/core please? The PAN bits should
be much simpler with the KPTI code.
Will
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Daniel Vetter @ 2017-12-12 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e506908-153f-2782-e7ef-7f2cc2c48662@samsung.com>
On Tue, Dec 12, 2017 at 12:38 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Hi All,
>
>
> On 2017-12-11 23:28, Javier Martinez Canillas wrote:
>>
>> [adding Marek and Shuah to cc list]
>>
>> On Mon, Dec 11, 2017 at 6:05 PM, Daniel Vetter <daniel.vetter@ffwll.ch>
>> wrote:
>>>
>>> On Mon, Dec 11, 2017 at 11:30 AM, Guillaume Tucker
>>> <guillaume.tucker@collabora.com> wrote:
>>>>
>>>> Hi Daniel,
>>>>
>>>> Please see below, I've had several bisection results pointing at
>>>> that commit over the week-end on mainline but also on linux-next
>>>> and net-next. While the peach-pi is a bit flaky at the moment
>>>> and is likely to have more than one issue, it does seem like this
>>>> commit is causing some well reproducible kernel hang.
>>>>
>>>> Here's a re-run with v4.15-rc3 showing the issue:
>>>>
>>>> https://lava.collabora.co.uk/scheduler/job/1018478
>>>>
>>>> and here's another one with the change mentioned below reverted:
>>>>
>>>> https://lava.collabora.co.uk/scheduler/job/1018479
>>>>
>>>> They both show a warning about "unbalanced disables for lcd_vdd",
>>>> I don't know if this is related as I haven't investigated any
>>>> further. It does appear to reliably hang with v4.15-rc3 and
>>>> boot most of the time with the commit reverted though.
>>>>
>>>> The automated kernelci.org bisection is still an experimental
>>>> tool and it may well be a false positive, so please take this
>>>> result with a pinch of salt...
>>>
>>> The patch just very minimal moves the connector cleanup around (so
>>> timing change), but except when you unload a driver (or maybe that
>>> funny EPROBE_DEFER stuff) it shouldn't matter. So if you don't have
>>> more info than "seems to hang a bit more" I have no idea what's wrong.
>>> The patch itself should work, at least it survived quite some serious
>>> testing we do on everything.
>>> -Daniel
>>>
>> Marek was pointing to a different culprit [0] in this [1] thread. I
>> see that both commits made it to v4.15-rc3, which is the first version
>> where boot fails. So maybe is a combination of both? Or rather
>> reverting one patch masks the error in the other.
>>
>> I've access to the machine but unfortunately not a lot of time to dig
>> on this, I could try to do it in the weekend though.
>
>
> After a recent discussion on the Javier's patch:
> https://patchwork.kernel.org/patch/10106417/
> I've managed to reproduce this issue also on Exynos5250 based Samsung
> Snow Chromebook and investigate a bit.
>
> It is caused by a deadlock in the main kernel workqueue. Here are details:
>
> 1. Exynos DRM fails to initialize due to missing regulators and gets moved
> to deferred probe device list
>
> 2. Deferred probe is triggered and kernel "events" workqueue calls
> deferred_probe_work_func()
>
> 3. exynos_drm_bind() is called, component_bind_all() fails due to missing
> Exynos Mixer device
>
> 4. error handling path is executed in exynos_drm_bind(), which calls
> drm_mode_config_cleanup()
>
> 5. drm_mode_config_cleanup() calls flush_scheduled_work(), what causes
> deadlock.
>
> Do You have idea how to fix this issue properly?
>
> Taking a look at git blame, this indeed shows that the issue has been
> introduced by the commit a703c55004e1 ("drm: safely free connectors from
> connector_ite"), which added a call to flush_scheduled_work() in
> drm_mode_config_cleanup().
>
> drm_mode_config_cleanup() should avoid calling flush_scheduled_work() if
> called from the workqueue, but I don't have idea how to check that. The
> other way of fixing it would be to resurrect separate workqueue for DRM
> related events.
We need to flush the work there, or things will go wrong on unload. I
think the real fix is to make sure that the connector cleanup work
isn't run on the same work stuff as any driver bind stuff, which yes
means new separate workqueue just for this.
I guess the simple fix is to do that in the drm, but tbh I'm surprised
that driver bind/deferred probe hasn't run into this problem anywhere
else yet.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [RESEND PATCH V2] arm64: fault: avoid send SIGBUS two times
From: James Morse @ 2017-12-12 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211160536.11600-1-gengdongjiu@huawei.com>
Hi Dongjiu Geng,
On 11/12/17 16:05, Dongjiu Geng wrote:
> do_sea() calls arm64_notify_die() which will always signal
> user-space. It also returns whether APEI claimed the external
> abort as a RAS notification. If it returns failure do_mem_abort()
> will signal user-space too.
>
> do_mem_abort() wants to know if we handled the error, we always
> call arm64_notify_die() so can always return success.
>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
Nit: Your 'RESEND V2' and 'V2' are not the same patch.
'RESEND' is to indicate you're reposting exactly the same patch, usually with a
fixed CC list. Anyone who receives both can ignore one as you've said they are
the same.
Thanks,
James
^ permalink raw reply
* [PATCH] pinctrl: rockchip: enable clock when reading pin direction register
From: Heiko Stuebner @ 2017-12-12 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212174343.192017-1-briannorris@chromium.org>
Hi Brian,
Am Dienstag, 12. Dezember 2017, 09:43:43 CET schrieb Brian Norris:
> We generally leave the GPIO clock disabled, unless an interrupt is
> requested or we're accessing IO registers. We forgot to do this for the
> ->get_direction() callback, which means we can sometimes [1] get
> incorrect results [2] from, e.g., /sys/kernel/debug/gpio.
>
> Enable the clock, so we get the right results!
>
> [1] Sometimes, because many systems have 1 or mor interrupt requested on
> each GPIO bank, so they always leave their clock on.
>
> [2] Incorrect, meaning the register returns 0, and so we interpret that
> as "input".
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
thanks for catching this and it looks good to me, so
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Tony Lindgren @ 2017-12-12 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212180317.GB10337@lenoch>
* Ladislav Michl <ladis@linux-mips.org> [171212 18:06]:
> On Tue, Dec 12, 2017 at 09:00:54AM -0800, Tony Lindgren wrote:
> > Hmm what do you mean? We don't want to export tons of custom functions from
> > the timers in and then be in trouble when at some point we have a Linux
> > generic hw timer framework. We already had to deal with these custom
> > exports earlier with conversion to multiarch and then again with
> > device tree.
> >
> > For now, it's best to pass the timer information to the pwm driver in
> > platform data. In the long run that will be much easier to deal with than
> > fixing random drivers tinkering with the timer registers directly.
>
> All that register access would happen only in drivers/clocksource/timer-dm.c?
> So platform data will hold all function pointers needed for event capture
> and the pwm driver will do only interface to pwm framework.
Yes please.
> > Ideally the pwm driver would just do a request_irq from the dmtimer code
> > where dmtimer code would implement an interrupt controller. That would
> > be already most fo the Linux generic hardware timer framework right there :)
>
> I do not follow. Each general-purpose timer module has its own interrupt line,
> so claiming that irq directly using request_irq seems enough. Could you
> explain interrupt controller idea a bit more?
Well let's assume we have drivers/clocksource/timer-dm.c implement
an irq controller. Then the pwm driver would just do:
pwm9: dmtimer-pwm {
compatible = "ti,omap-dmtimer-pwm";
#pwm-cells = <3>;
ti,timers = <&timer9>;
ti,clock-source = <0x00>; /* timer_sys_ck */
interrupts-extended = <&timer9 IRQ_TYPE_SOMETHING>;
};
Then you can do whatever you need to in the pwm driver with
enable_irq/disable_irq + a handler?
If reading the line status is needed.. Then maybe the GPIO framework
needs to have hardware timer support instead?
Anyways, just thinking out loud how we could have a Linux generic
hardware timer framework that drivers like pwm could then use.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/5] Add Sound support for iWave RZ/G1M board
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
This series aims to add sound support for iWave RZ/G1M board.
This patch series has documentation dependency on
https://patchwork.kernel.org/patch/10108014/
Biju Das (5):
ARM: shmobile: defconfig: Enable SGTL5000 audio codec
ARM: dts: r8a7743: Add audio clocks
ARM: dts: r8a7743: Add audio DMAC support
ARM: dts: r8a7743: Add sound support
ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 24 +++
arch/arm/boot/dts/r8a7743.dtsi | 270 ++++++++++++++++++++++++++++++++
arch/arm/configs/shmobile_defconfig | 1 +
3 files changed, 295 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH 1/5] ARM: shmobile: defconfig: Enable SGTL5000 audio codec
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
The iWave RZ/G1M Q7 carrier board supports I2S audio codec "SGTL5000".
To increase hardware support enable the driver in the shmobile_defconfig
multiplatform configuration.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/configs/shmobile_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 7b4fc01..d60dbe1 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -173,6 +173,7 @@ CONFIG_SND_SOC=y
CONFIG_SND_SOC_SH4_FSI=y
CONFIG_SND_SOC_RCAR=y
CONFIG_SND_SOC_AK4642=y
+CONFIG_SND_SOC_SGTL5000=y
CONFIG_SND_SOC_WM8978=y
CONFIG_SND_SIMPLE_SCU_CARD=y
CONFIG_USB=y
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: r8a7743: Add audio clocks
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
Describe the external audio clocks required by the sound driver.
Boards that provide audio clocks need to override the clock frequencies.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index c09c667..2f0ec9d 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1238,6 +1238,29 @@
clock-frequency = <0>;
};
+ /*
+ * The external audio clocks are configured as 0 Hz fixed frequency
+ * clocks by default.
+ * Boards that provide audio clocks should override them.
+ */
+ audio_clk_a: audio_clk_a {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_b: audio_clk_b {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
+ audio_clk_c: audio_clk_c {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
+ };
+
/* External USB clock - can be overridden by the board */
usb_extal_clk: usb_extal {
compatible = "fixed-clock";
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: r8a7743: Add audio DMAC support
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
Instantiate the two audio DMA controllers on the r8a7743 device tree.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 62 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 2f0ec9d..b60527a 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -359,6 +359,68 @@
dma-channels = <15>;
};
+ audma0: dma-controller at ec700000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xec700000 0 0x10000>;
+ interrupts = <GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12";
+ clocks = <&cpg CPG_MOD 502>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 502>;
+ #dma-cells = <1>;
+ dma-channels = <13>;
+ };
+
+ audma1: dma-controller at ec720000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xec720000 0 0x10000>;
+ interrupts = <GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12";
+ clocks = <&cpg CPG_MOD 501>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 501>;
+ #dma-cells = <1>;
+ dma-channels = <13>;
+ };
+
usb_dmac0: dma-controller at e65a0000 {
compatible = "renesas,r8a7743-usb-dmac",
"renesas,usb-dmac";
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: r8a7743: Add sound support
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
Define the generic r8a7743(RZ/G1M) part of the sound device node.
This patch is based on the r8a7791 sound work by Kuninori Morimoto.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 185 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 185 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index b60527a..59860c8 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1290,6 +1290,191 @@
resets = <&cpg 319>;
status = "disabled";
};
+
+ rcar_sound: sound at ec500000 {
+ /*
+ * #sound-dai-cells is required
+ *
+ * Single DAI : #sound-dai-cells = <0>; <&rcar_sound>;
+ * Multi DAI : #sound-dai-cells = <1>; <&rcar_sound N>;
+ */
+ compatible = "renesas,rcar_sound-r8a7743",
+ "renesas,rcar_sound-gen2";
+ reg = <0 0xec500000 0 0x1000>, /* SCU */
+ <0 0xec5a0000 0 0x100>, /* ADG */
+ <0 0xec540000 0 0x1000>, /* SSIU */
+ <0 0xec541000 0 0x280>, /* SSI */
+ <0 0xec740000 0 0x200>; /* Audio DMAC peri peri*/
+ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+
+ clocks = <&cpg CPG_MOD 1005>,
+ <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+ <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+ <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+ <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+ <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+ <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+ <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+ <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+ <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+ <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+ <&cpg CPG_MOD 1021>, <&cpg CPG_MOD 1020>,
+ <&cpg CPG_MOD 1021>, <&cpg CPG_MOD 1020>,
+ <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+ <&audio_clk_a>, <&audio_clk_b>, <&audio_clk_c>,
+ <&cpg CPG_CORE R8A7743_CLK_M2>;
+ clock-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
+ "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
+ "src.9", "src.8", "src.7", "src.6", "src.5",
+ "src.4", "src.3", "src.2", "src.1", "src.0",
+ "ctu.0", "ctu.1",
+ "mix.0", "mix.1",
+ "dvc.0", "dvc.1",
+ "clk_a", "clk_b", "clk_c", "clk_i";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 1005>,
+ <&cpg 1006>, <&cpg 1007>, <&cpg 1008>, <&cpg 1009>,
+ <&cpg 1010>, <&cpg 1011>, <&cpg 1012>, <&cpg 1013>,
+ <&cpg 1014>, <&cpg 1015>;
+ reset-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
+ "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0";
+ status = "disabled";
+
+ rcar_sound,dvc {
+ dvc0: dvc-0 {
+ dmas = <&audma1 0xbc>;
+ dma-names = "tx";
+ };
+ dvc1: dvc-1 {
+ dmas = <&audma1 0xbe>;
+ dma-names = "tx";
+ };
+ };
+
+ rcar_sound,mix {
+ mix0: mix-0 { };
+ mix1: mix-1 { };
+ };
+
+ rcar_sound,ctu {
+ ctu00: ctu-0 { };
+ ctu01: ctu-1 { };
+ ctu02: ctu-2 { };
+ ctu03: ctu-3 { };
+ ctu10: ctu-4 { };
+ ctu11: ctu-5 { };
+ ctu12: ctu-6 { };
+ ctu13: ctu-7 { };
+ };
+
+ rcar_sound,src {
+ src0: src-0 {
+ interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x85>, <&audma1 0x9a>;
+ dma-names = "rx", "tx";
+ };
+ src1: src-1 {
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x87>, <&audma1 0x9c>;
+ dma-names = "rx", "tx";
+ };
+ src2: src-2 {
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x89>, <&audma1 0x9e>;
+ dma-names = "rx", "tx";
+ };
+ src3: src-3 {
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x8b>, <&audma1 0xa0>;
+ dma-names = "rx", "tx";
+ };
+ src4: src-4 {
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x8d>, <&audma1 0xb0>;
+ dma-names = "rx", "tx";
+ };
+ src5: src-5 {
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x8f>, <&audma1 0xb2>;
+ dma-names = "rx", "tx";
+ };
+ src6: src-6 {
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x91>, <&audma1 0xb4>;
+ dma-names = "rx", "tx";
+ };
+ src7: src-7 {
+ interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x93>, <&audma1 0xb6>;
+ dma-names = "rx", "tx";
+ };
+ src8: src-8 {
+ interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x95>, <&audma1 0xb8>;
+ dma-names = "rx", "tx";
+ };
+ src9: src-9 {
+ interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x97>, <&audma1 0xba>;
+ dma-names = "rx", "tx";
+ };
+ };
+
+ rcar_sound,ssi {
+ ssi0: ssi-0 {
+ interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi1: ssi-1 {
+ interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi2: ssi-2 {
+ interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi3: ssi-3 {
+ interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi4: ssi-4 {
+ interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi5: ssi-5 {
+ interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi6: ssi-6 {
+ interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi7: ssi-7 {
+ interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi8: ssi-8 {
+ interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ ssi9: ssi-9 {
+ interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
+ dma-names = "rx", "tx", "rxu", "txu";
+ };
+ };
+ };
};
/* External root clock */
--
1.9.1
^ permalink raw reply related
* [PATCH 5/5] ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec
From: Biju Das @ 2017-12-12 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513103111-45830-1-git-send-email-biju.das@bp.renesas.com>
This patch enables SGTL5000 audio codec on the carrier board.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 54470c6..2070b14 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -20,6 +20,20 @@
stdout-path = "serial0:115200n8";
};
+ audio_clock: audio_clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+
+ reg_1p5v: 1p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P5V";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ };
+
vcc_sdhi1: regulator-vcc-sdhi1 {
compatible = "regulator-fixed";
@@ -83,6 +97,16 @@
compatible = "ti,bq32000";
reg = <0x68>;
};
+
+ sgtl5000: codec at 0a {
+ compatible = "fsl,sgtl5000";
+ #sound-dai-cells = <0>;
+ reg = <0x0a>;
+ clocks = <&audio_clock>;
+ VDDA-supply = <®_3p3v>;
+ VDDIO-supply = <®_3p3v>;
+ VDDD-supply = <®_1p5v>;
+ };
};
&pci0 {
--
1.9.1
^ permalink raw reply related
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Shuah Khan @ 2017-12-12 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <beef1026-3dbe-5284-d2fa-a2298c52e7c0@osg.samsung.com>
On 12/12/2017 07:47 AM, Shuah Khan wrote:
> On 12/12/2017 01:47 AM, Marek Szyprowski wrote:
>> Hi Javier,
>>
>> On 2017-12-12 09:00, Javier Martinez Canillas wrote:
>>> On Tue, Dec 12, 2017 at 8:54 AM, Marek Szyprowski
>>> <m.szyprowski@samsung.com> wrote:
>>>> On 2017-12-12 00:25, Shuah Khan wrote:
>>>>> On 12/11/2017 04:02 PM, Russell King - ARM Linux wrote:
>>>>>> On Mon, Dec 11, 2017 at 10:58:29PM +0000, Russell King - ARM Linux wrote:
>>>>>>> On Mon, Dec 11, 2017 at 11:54:48PM +0100, Javier Martinez Canillas
>>>>>>> wrote:
>>>>>>>> So I gave a quick look to this, and at the very least there's a bug in
>>>>>>>> the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
>>>>>>>> exynos: Add status property to Exynos 542x Mixer nodes").
>>>>>>>>
>>>>>>>> I've posted a fix for that:
>>>>>>>>
>>>>>>>> https://patchwork.kernel.org/patch/10105921/
>>>>>>>>
>>>>>>>> I believe this could be also be the cause for the boot failure, since
>>>>>>>> I see in the boot log that things start to go wrong after exynos-drm
>>>>>>>> fails to bind the HDMI component:
>>>>>>>>
>>>>>>>> [ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
>>>>>>>> 0xc1398690): -1
>>>>>>> Umm, -1 ?? Looking that error code up in
>>>>>>> include/uapi/asm-generic/errno-base.h says it's -EPERM.
>>>>>>>
>>>>>>> I suspect that's someone just returning -1 because they're lazy...
>>>>>>> which is real bad form and needs fixing.
>>>>>> Oh, it really is -EPERM:
>>>>>>
>>>>>> struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device
>>>>>> *drm_dev,
>>>>>> ???????????????????????????????????????? enum exynos_drm_output_type
>>>>>> out_type)
>>>>>> {
>>>>>> ????????? struct drm_crtc *crtc;
>>>>>>
>>>>>> ????????? drm_for_each_crtc(crtc, drm_dev)
>>>>>> ????????????????? if (to_exynos_crtc(crtc)->type == out_type)
>>>>>> ????????????????????????? return to_exynos_crtc(crtc);
>>>>>>
>>>>>> ????????? return ERR_PTR(-EPERM);
>>>>>> }
>>>>>>
>>>>>> Does "Operation not permitted" really convey the error here?? It doesn't
>>>>>> look like a permission error to me.
>>>>>>
>>>>>> Can we please avoid abusing errno codes?
>>>>> I tried 4.15-rc3 on odroid-xu4 after seeing drm issues reported. 4.15-rc2+
>>>>> with top commit g968edbd worked just fine for me last Friday. I ran
>>>>> several
>>>>> tests and everything checked out except the exynos-gsc lockdep issue I
>>>>> sent
>>>>> a 4.14 patch for.
>>>>>
>>>>> However, with 4.15-rc3, dmesg is gets filled with
>>>>>
>>>>> [? 342.337181] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 342.337470] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 342.337851] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.382346] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.396682] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.399244] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.399496] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.399848] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.400163] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.400495] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.401294] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>> [? 402.401595] [drm] Non-contiguous allocation is not supported without
>>>>> IOMMU, falling back to contiguous buffer
>>>>>
>>>>> Something broke in 4.15-rc3 on odroix-xu4 badly with exynos_defconfig.
>>>>>
>>>>> I will start bisect and try to isolate the problem. I suspect this is
>>>>> related to dts
>>>>> changes perhaps? I used to this problem a while back and it has been
>>>>> fixed.
>>>>
>>>> This warning has been added intentionally, see following discussions:
>>>> https://patchwork.kernel.org/patch/10034919/
>>>> https://patchwork.kernel.org/patch/10070475/
>>>>
>>>> This means that your test apps should be updated or you should enable Exynos
>>>> IOMMU support in your config. Maybe it is a good time to finally enable it
>>>> in exynos_defconfig.
>>>>
>>> Has the issue that the boot-loader keeps the display controller
>>> enabled and scanning pages on the Exynos Chromebooks resolved?
>>>
>>> I think that's that preventing to enable it by default in
>>> exynos_defconfig since it caused boot failures when enabled on these
>>> machines. I don't follow exynos development too closely nowadays so
>>> maybe there's a fix in place now.
>>
>> Not directly. I still didn't find time to properly add support for
>> devices, which were left in-working state (with active DMA
>> transactions) by bootloader, but due to some other changes in the
>> order of operations during boot process, power domains are
>> initialized very early and due to temporary lack of devices (which
>> are not yet added to the system), are turned off. This practically
>> stops FIMD for scanning framebuffer and "solves" this issue.
>>
>> I've checked now and Exynos Snow Chromebook boots fine with IOMMU
>> support enabled, both with v4.15-rc3 and linux-next.
Would it make sense to enable EXYNOS_IOMMU in exynos_defconfig. I sent
a patch to do that a while back. The decision at the time to not pull
that patch is was based on systems not booting with it enabled.
Is it time to revisit that or the recommendation is for IOMMU to be
enabled in configs manually on systems it is safe to do so?
thanks,
-- Shuah
^ permalink raw reply
* [PATCH v2 07/19] arm64: insn: Add encoder for bitwise operations using litterals
From: James Morse @ 2017-12-12 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211144937.4537-8-marc.zyngier@arm.com>
Hi Marc,
On 11/12/17 14:49, Marc Zyngier wrote:
> We lack a way to encode operations such as AND, ORR, EOR that take
> an immediate value. Doing so is quite involved, and is all about
> reverse engineering the decoding algorithm described in the
> pseudocode function DecodeBitMasks().
As this is over my head, I've been pushing random encodings through gas/objdump
and then tracing them through here.... can this encode 0xf80000000fffffff?
gas thinks this is legal:
| 0: 92458000 and x0, x0, #0xf80000000fffffff
I make that N=1, S=0x20, R=0x05.
(I'm still working out what 'S' means)
> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
> index 7e432662d454..326b17016485 100644
> --- a/arch/arm64/kernel/insn.c
> +++ b/arch/arm64/kernel/insn.c
> +static u32 aarch64_encode_immediate(u64 imm,
> + enum aarch64_insn_variant variant,
> + u32 insn)
> +{
> + unsigned int immr, imms, n, ones, ror, esz, tmp;
> + u64 mask;
[...]
> + /* N is only set if we're encoding a 64bit value */
> + n = esz == 64;
> +
> + /* Trim imm to the element size */
> + mask = BIT(esz - 1) - 1;
> + imm &= mask;
Won't this lose the top bit of a 64bit immediate?
(but then you put it back later, so something funny is going on)
This becomes 0x780000000fffffff,
> +
> + /* That's how many ones we need to encode */
> + ones = hweight64(imm);
meaning we're short a one here,
> +
> + /*
> + * imms is set to (ones - 1), prefixed with a string of ones
> + * and a zero if they fit. Cap it to 6 bits.
> + */
> + imms = ones - 1;
> + imms |= 0xf << ffs(esz);
> + imms &= BIT(6) - 1;
so imms is 0x1f, not 0x20.
> + /* Compute the rotation */
> + if (range_of_ones(imm)) {
> + /*
> + * Pattern: 0..01..10..0
> + *
> + * Compute how many rotate we need to align it right
> + */
> + ror = ffs(imm) - 1;
(how come range_of_ones() uses __ffs64() on the same value?)
> + } else {
> + /*
> + * Pattern: 0..01..10..01..1
> + *
> + * Fill the unused top bits with ones, and check if
> + * the result is a valid immediate (all ones with a
> + * contiguous ranges of zeroes).
> + */
> + imm |= ~mask;
but here we put the missing one back,
> + if (!range_of_ones(~imm))
> + return AARCH64_BREAK_FAULT;
meaning we pass this check and carry on, (even though 0x780000000fffffff isn't a
legal value)
(this next bit I haven't worked out yet)
> + /*
> + * Compute the rotation to get a continuous set of
> + * ones, with the first bit set at position 0
> + */
> + ror = fls(~imm);
> + }
> +
> + /*
> + * immr is the number of bits we need to rotate back to the
> + * original set of ones. Note that this is relative to the
> + * element size...
> + */
> + immr = (esz - ror) & (esz - 1);
If I've followed this through correctly, this results in:
| 0: 92457c00 and x0, x0, #0xf800000007ffffff
... which wasn't the immediate I started with.
Unless I've gone wrong, I think the 'Trim imm to the element size' code needs to
move up into the esz-reducing loop so it doesn't happen for a 64bit immediate.
Thanks,
James
^ permalink raw reply
* [PATCH 0/3] Add CMT support to r8a774[35]
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: linux-arm-kernel
This series adds CMT support for r8a7743 and r8a7745.
Thanks,
Fabrizio Castro (3):
dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
ARM: dts: r8a7743: Add CMT SoC specific support
ARM: dts: r8a7745: Add CMT SoC specific support
.../devicetree/bindings/timer/renesas,cmt.txt | 12 ++++++---
arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++
arch/arm/boot/dts/r8a7745.dtsi | 30 ++++++++++++++++++++++
3 files changed, 69 insertions(+), 3 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513104579-6333-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add CMT[01] support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 59860c8..0e2834a 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -262,6 +262,36 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ cmt0: timer at ffca0000 {
+ compatible = "renesas,r8a7743-cmt0",
+ "renesas,rcar-gen2-cmt0";
+ reg = <0 0xffca0000 0 0x1004>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 124>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 124>;
+ };
+
+ cmt1: timer at e6130000 {
+ compatible = "renesas,r8a7743-cmt1",
+ "renesas,rcar-gen2-cmt1";
+ reg = <0 0xe6130000 0 0x1004>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 329>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ resets = <&cpg 329>;
+ };
+
cpg: clock-controller at e6150000 {
compatible = "renesas,r8a7743-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: r8a7745: Add CMT SoC specific support
From: Fabrizio Castro @ 2017-12-12 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513104579-6333-1-git-send-email-fabrizio.castro@bp.renesas.com>
Add CMT[01] support to SoC DT.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
arch/arm/boot/dts/r8a7745.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0fa7861..765a80d 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -235,6 +235,36 @@
IRQ_TYPE_LEVEL_LOW)>;
};
+ cmt0: timer at ffca0000 {
+ compatible = "renesas,r8a7745-cmt0",
+ "renesas,rcar-gen2-cmt0";
+ reg = <0 0xffca0000 0 0x1004>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 124>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 124>;
+ };
+
+ cmt1: timer at e6130000 {
+ compatible = "renesas,r8a7745-cmt1",
+ "renesas,rcar-gen2-cmt1";
+ reg = <0 0xe6130000 0 0x1004>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 329>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ resets = <&cpg 329>;
+ };
+
cpg: clock-controller at e6150000 {
compatible = "renesas,r8a7745-cpg-mssr";
reg = <0 0xe6150000 0 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 07/19] arm64: insn: Add encoder for bitwise operations using litterals
From: Peter Maydell @ 2017-12-12 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211144937.4537-8-marc.zyngier@arm.com>
On 11 December 2017 at 14:49, Marc Zyngier <marc.zyngier@arm.com> wrote:
> We lack a way to encode operations such as AND, ORR, EOR that take
> an immediate value. Doing so is quite involved, and is all about
> reverse engineering the decoding algorithm described in the
> pseudocode function DecodeBitMasks().
Is it possible to borrow the existing tested implementation
which a compiler surely must have for this, rather than having
to reinvent this rather complicated wheel? Here's LLVM's version:
https://github.com/llvm-mirror/llvm/blob/93e6e5414ded14bcbb233baaaa5567132fee9a0c/lib/Target/AArch64/MCTargetDesc/AArch64AddressingModes.h#L209
(confirming that the LLVM license is GPLv2 compatible is
left as an exercise for the reader, but I'm pretty sure it is)
PS: typo in subject: 'literal'.
thanks
-- PMM
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Javier Martinez Canillas @ 2017-12-12 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fcab4daa-678c-ee48-a5ec-9d22c535ff29@osg.samsung.com>
Hello Shuah,
On Tue, Dec 12, 2017 at 7:26 PM, Shuah Khan <shuahkh@osg.samsung.com> wrote:
[snip]
>>>
>>> Not directly. I still didn't find time to properly add support for
>>> devices, which were left in-working state (with active DMA
>>> transactions) by bootloader, but due to some other changes in the
>>> order of operations during boot process, power domains are
>>> initialized very early and due to temporary lack of devices (which
>>> are not yet added to the system), are turned off. This practically
>>> stops FIMD for scanning framebuffer and "solves" this issue.
>>>
>>> I've checked now and Exynos Snow Chromebook boots fine with IOMMU
>>> support enabled, both with v4.15-rc3 and linux-next.
>
> Would it make sense to enable EXYNOS_IOMMU in exynos_defconfig. I sent
> a patch to do that a while back. The decision at the time to not pull
> that patch is was based on systems not booting with it enabled.
>
> Is it time to revisit that or the recommendation is for IOMMU to be
> enabled in configs manually on systems it is safe to do so?
>
Yes, I think it would be good to have it enabled by default if that
doesn't cause boot issues anymore.
Could you please resend your patch and cc Marek and me so we can test
on Snow and Peach Chromebooks?
> thanks,
> -- Shuah
Best regards,
Javier
^ permalink raw reply
* [PATCH v2] PCI: keystone: fix interrupt-controller-node lookup
From: Johan Hovold @ 2017-12-12 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212180731.GA22805@red-moon>
On Tue, Dec 12, 2017 at 06:07:31PM +0000, Lorenzo Pieralisi wrote:
> On Tue, Dec 12, 2017 at 11:25:37AM -0600, Bjorn Helgaas wrote:
> > On Mon, Dec 11, 2017 at 10:42:33AM +0000, Lorenzo Pieralisi wrote:
> > > On Mon, Dec 11, 2017 at 11:29:55AM +0100, Johan Hovold wrote:
> > > > On Fri, Nov 17, 2017 at 02:38:31PM +0100, Johan Hovold wrote:
> > > > > Fix child-node lookup during initialisation which was using the wrong
> > > > > OF-helper and ended up searching the whole device tree depth-first
> > > > > starting at the parent rather than just matching on its children.
> > > > >
> > > > > To make things worse, the parent pci node could end up being prematurely
> > > > > freed as of_find_node_by_name() drops a reference to its first argument.
> > > > > Any matching child interrupt-controller node was also leaked.
> > > > >
> > > > > Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
> > > > > Cc: stable <stable@vger.kernel.org> # 3.18
> > > > > Acked-by: Murali Karicheri <m-karicheri2@ti.com>
> > > > > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > > ---
> > > > >
> > > > > v2
> > > > > - amend commit message and mention explicitly that of_find_node_by_name()
> > > > > drops a reference to the start node
> > > > > - add Murali's and Lorenzo's acks
> > > >
> > > > This one hasn't shown up in linux-next, so sending a reminder to make
> > > > sure it doesn't fall between the cracks.
> > >
> > > Hi Johan,
> > >
> > > yes it is in the list of fixes to be sent upstream - I was about to
> > > ask Bjorn to apply it.
> >
> > Is this something that needs to be merged for v4.15? If so, I need to
> > be able to defend it to Linus as being a critical fix. If the issue
> > been around for 3 years (v3.18 was tagged Dec 7 2014), that requires
> > pretty "clear and present danger."
> >
> > From the commit log, I see a sub-optimal search (not critical), a
> > possible use-after-free (could conceivably be critical if people are
> > tripping over this, but would need more specifics about that), and a
> > leak (not critical).
> >
> > Given what I can see now, my inclination would be for Lorenzo to queue
> > it for v4.16, which would still get in linux-next soonish.
>
> It is fine by me and I think, as already mentioned, that the stable
> tag is dubious so I will probably drop it.
The unbalanced put can indeed cause serious problems, for example, after
probe deferrals. Crashes after probe deferrals has been reported for
other drivers with the same type of bug, and I have reproduced it
locally (using yet another driver).
I'm also fine with holding this one off for 4.16 (as we're at -rc3), but
I do think the stable tag is still warranted.
Johan
^ 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