* [PATCH v7 3/8] KVM: arm/arm64: Don't cache the timer IRQ level
From: Auger Eric @ 2017-12-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <24ae6f9e-8f83-6b95-a7a0-d900c37b4a7f@redhat.com>
On 11/12/17 21:51, Auger Eric wrote:
> Hi Christoffer,
> On 07/12/17 11:54, Christoffer Dall wrote:
>> The timer was modeled after a strict idea of modelling an interrupt line
>> level in software, meaning that only transitions in the level needed to
>> be reported to the VGIC. This works well for the timer, because the
>> arch timer code is in complete control of the device and can track the
>> transitions of the line.
>>
>> However, as we are about to support using the HW bit in the VGIC not
>> just for the timer, but also for VFIO which cannot track transitions of
>> the interrupt line, we have to decide on an interface for level
>> triggered mapped interrupts to the GIC, which both the timer and VFIO
>> can use.
>>
>> VFIO only sees an asserting transition of the physical interrupt line,
>> and tells the VGIC when that happens. That means that part of the
>> interrupt flow is offloaded to the hardware.
>>
>> To use the same interface for VFIO devices and the timer, we therefore
>> have to change the timer (we cannot change VFIO because it doesn't know
>> the details of the device it is assigning to a VM).
>>
>> Luckily, changing the timer is simple, we just need to stop 'caching'
>> the line level, but instead let the VGIC know the state of the timer
>> every time there is a potential change in the line level, and when the
>> line level should be asserted from the timer ISR. The VGIC can ignore
>> extra notifications using its validate mechanism.
>
> I was confused by the fact we say we stop caching the line level but
> vtimer->irq.level still exists, is updated in the vtimer host ISR and
> kvm_timer_update_state() and read in many places.
>
> I feel difficult to figure out if each time we use the vtimer->irq.level
> value it is safe to use it.
>
> Also for the validate() to succeed we need the vgic irq->line_level to
> to be 0. I understand this is properly handled for mapped level irqs in
> next patch which does that on the populate_lr. However I currently fail
> to understand why the timer level sensitive mapped IRQ does not require
> the next patch to work.
OK reading again "[PATCH v7 7/8] KVM: arm/arm64: Provide a
get_input_level for the arch timer", I now understand it works because
we had the
kvm_timer_sync_hwstate toggling down the line on VM exit. After the
changes of next patch this can be safely removed.
Not related to this patch but I noticed
Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt now is outdated.
>
> Thanks
>
> Eric
>
>>
>> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>> ---
>> virt/kvm/arm/arch_timer.c | 20 +++++++++++++-------
>> 1 file changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index 4151250ce8da..dd5aca05c500 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -99,11 +99,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
>> }
>> vtimer = vcpu_vtimer(vcpu);
>>
>> - if (!vtimer->irq.level) {
>> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
>> - if (kvm_timer_irq_can_fire(vtimer))
>> - kvm_timer_update_irq(vcpu, true, vtimer);
>> - }
>> + vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
>> + if (kvm_timer_irq_can_fire(vtimer))
>> + kvm_timer_update_irq(vcpu, true, vtimer);
>>
>> if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
>> kvm_vtimer_update_mask_user(vcpu);
>> @@ -324,12 +322,20 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
>> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>> + bool level;
>>
>> if (unlikely(!timer->enabled))
>> return;
>>
>> - if (kvm_timer_should_fire(vtimer) != vtimer->irq.level)
>> - kvm_timer_update_irq(vcpu, !vtimer->irq.level, vtimer);
>> + /*
>> + * The vtimer virtual interrupt is a 'mapped' interrupt, meaning part
>> + * of its lifecycle is offloaded to the hardware, and we therefore may
>> + * not have lowered the irq.level value before having to signal a new
>> + * interrupt, but have to signal an interrupt every time the level is
>> + * asserted.
>> + */
>> + level = kvm_timer_should_fire(vtimer);
>> + kvm_timer_update_irq(vcpu, level, vtimer);
>>
>> if (kvm_timer_should_fire(ptimer) != ptimer->irq.level)
>> kvm_timer_update_irq(vcpu, !ptimer->irq.level, ptimer);
>>
^ permalink raw reply
* [PATCH 1/4] ASoC: sun4i-i2s: Add support for A83T
From: Maxime Ripard @ 2017-12-12 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-2-wens@csie.org>
On Tue, Dec 12, 2017 at 04:11:45PM +0800, Chen-Yu Tsai wrote:
> The I2S controller in the A83T is mostly compatible with the one found
> in earlier SoCs such as the A20 and A31. While the documents publicly
> available for the A83T do not cover this hardware, the officially
> released BSP kernel does have register definitions for it. These were
> matched against the A20 user manual. The only difference is the TX FIFO
> and interrupt status registers have been swapped around, like what we
> have seen with the SPDIF controller.
>
> This patch adds support for this hardware.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20171212/af34a175/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] [DO NOT MERGE] ARM: dts: sun8i: a83t: bpi-m3: Enable PCM5122 codec with I2S1
From: Maxime Ripard @ 2017-12-12 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-5-wens@csie.org>
Hi,
On Tue, Dec 12, 2017 at 04:11:48PM +0800, Chen-Yu Tsai wrote:
> This patch enables a PiFi DAC+ V2.0, which is a PCM5122-based audio
> output DAC add-on board for the Raspberry Pi B+ and later, connected
> to the GPIO header of the Bananapi M3 via jumper cables. The power,
> ground, and I2C pins are in the same position, but the I2S ones are
> not.
>
> The I2C controller used is I2C2, while the I2S controller is I2S1.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>
> I'm sure I've asked this before, and IIRC the answer was yes: The I2C
> controllers available on the GPIO header all have proper, always-on,
> external pull-ups. Does that mean we can enable them by default, seeing
> as they are likely intended to be used this way (as I2C pins)?
>
> I think we have a few boards where either I2C or UARTs on the GPIO
> header are enabled by default.
The consensus we reached that we would fill the nodes, but leave them
disabled.
In this particular case, I guess it would help for the i2c controller,
but not for the i2s one.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20171212/02cf0807/attachment.sig>
^ permalink raw reply
* [PATCH 3/4] ARM: dts: sun8i: a83t: Add I2C device nodes and pinmux settings
From: Maxime Ripard @ 2017-12-12 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-4-wens@csie.org>
Hi,
On Tue, Dec 12, 2017 at 04:11:47PM +0800, Chen-Yu Tsai wrote:
> + i2c0: i2c at 1c2ac00 {
> + compatible = "allwinner,sun6i-a31-i2c";
Same remark than for Mylene's patch here, you should have a per-SoC
compatible first.
Once fixed,
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20171212/4e78d8eb/attachment.sig>
^ permalink raw reply
* [PATCH 2/4] ARM: dts: sun8i: a83t: Add I2S controller device nodes
From: Maxime Ripard @ 2017-12-12 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-3-wens@csie.org>
Hi,
On Tue, Dec 12, 2017 at 04:11:46PM +0800, Chen-Yu Tsai wrote:
> The A83T has 3 I2S controllers. The first is multiplexed with the TDM
> controller. The pins are generally connected to the codec side of the
> AXP81x PMIC/codec/RTC chip. The second is free for other uses. The
> third only supports output, and is connected internally to the HDMI
> controller for HDMI audio output.
>
> This patch adds device nodes for the controllers, and a default pinmux
> setting for the second controller.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20171212/9a112455/attachment.sig>
^ permalink raw reply
* [RFC PATCH][resend] pciehp: fix a race between pciehp and removing operations by sysfs
From: Xiongfeng Wang @ 2017-12-12 8:29 UTC (permalink / raw)
To: linux-arm-kernel
When the Attention button on a PCIE slot is pressed, 5 seconds later,
pciehp_power_thread() will be scheduled on slot->wq. This function will
get a global mutex lock 'pci_rescan_remove_lock' in
pciehp_unconfigure_device().
At the same time, we remove the pcie port by sysfs, which results in
pci_stop_and_remove_bus_device_locked() called. This function will get
the global mutex lock 'pci_rescan_remove_lock', and then release the
struct 'ctrl', which will wait until the work_struct on slot->wq is
finished.
If pci_stop_and_remove_bus_device_locked() got the mutex lock, and
before it drains workqueue slot->wq, pciehp_power_thread() is scheduled
on slot->wq and tries to get the mutex lock. Then
pci_stop_and_remove_bus_device_locked() tries to drain workqueue
slot->wq and wait until work struct 'pciehp_power_thread()' is finished.
Then a hung_task happens.
This patch solve this problem by schedule 'pciehp_power_thread()' on a
system workqueue instead of slot->wq.
The Call Trace we got is as following.
INFO: task kworker/0:2:4413 blocked for more than 120 seconds.
Tainted: P W O 4.12.0-rc1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:2 D 0 4413 2 0x00000000
Workqueue: pciehp-0 pciehp_power_thread
Call trace:
[<ffff0000080861d4>] __switch_to+0x94/0xa8
[<ffff000008bea9c0>] __schedule+0x1b0/0x708
[<ffff000008beaf58>] schedule+0x40/0xa4
[<ffff000008beb33c>] schedule_preempt_disabled+0x28/0x40
[<ffff000008bec1dc>] __mutex_lock.isra.8+0x148/0x50c
[<ffff000008bec5c4>] __mutex_lock_slowpath+0x24/0x30
[<ffff000008bec618>] mutex_lock+0x48/0x54
[<ffff0000084d8188>] pci_lock_rescan_remove+0x20/0x28
[<ffff0000084f87c0>] pciehp_unconfigure_device+0x54/0x1cc
[<ffff0000084f8260>] pciehp_disable_slot+0x4c/0xbc
[<ffff0000084f8370>] pciehp_power_thread+0xa0/0xb8
[<ffff0000080e9ce8>] process_one_work+0x13c/0x3f8
[<ffff0000080ea004>] worker_thread+0x60/0x3e4
[<ffff0000080f0814>] kthread+0x10c/0x138
[<ffff0000080836c0>] ret_from_fork+0x10/0x50
INFO: task bash:31732 blocked for more than 120 seconds.
Tainted: P W O 4.12.0-rc1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash D 0 31732 1 0x00000009
Call trace:
[<ffff0000080861d4>] __switch_to+0x94/0xa8
[<ffff000008bea9c0>] __schedule+0x1b0/0x708
[<ffff000008beaf58>] schedule+0x40/0xa4
[<ffff000008bee7b4>] schedule_timeout+0x1a0/0x340
[<ffff000008bebb88>] wait_for_common+0x108/0x1bc
[<ffff000008bebc64>] wait_for_completion+0x28/0x34
[<ffff0000080e7594>] flush_workqueue+0x130/0x488
[<ffff0000080e79b0>] drain_workqueue+0xc4/0x164
[<ffff0000080ec3cc>] destroy_workqueue+0x28/0x1f4
[<ffff0000084fa094>] pciehp_release_ctrl+0x34/0xe0
[<ffff0000084f75b0>] pciehp_remove+0x30/0x3c
[<ffff0000084f24d8>] pcie_port_remove_service+0x3c/0x54
[<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
[<ffff00000876b28c>] device_release_driver+0x28/0x34
[<ffff00000876a018>] bus_remove_device+0xe0/0x11c
[<ffff000008766348>] device_del+0x200/0x304
[<ffff00000876646c>] device_unregister+0x20/0x38
[<ffff0000084f2560>] remove_iter+0x44/0x54
[<ffff000008765230>] device_for_each_child+0x4c/0x90
[<ffff0000084f2c98>] pcie_port_device_remove+0x2c/0x48
[<ffff0000084f2f48>] pcie_portdrv_remove+0x60/0x6c
[<ffff0000084e3de4>] pci_device_remove+0x48/0x110
[<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
[<ffff00000876b28c>] device_release_driver+0x28/0x34
[<ffff0000084db028>] pci_stop_bus_device+0x9c/0xac
[<ffff0000084db190>] pci_stop_and_remove_bus_device_locked+0x24/0x3c
[<ffff0000084e5eb0>] remove_store+0x74/0x80
[<ffff000008764680>] dev_attr_store+0x44/0x5c
[<ffff0000082e7e1c>] sysfs_kf_write+0x5c/0x74
[<ffff0000082e7014>] kernfs_fop_write+0xcc/0x1dc
[<ffff0000082602e0>] __vfs_write+0x48/0x13c
[<ffff00000826174c>] vfs_write+0xa8/0x198
[<ffff000008262ce8>] SyS_write+0x54/0xb0
[<ffff000008083730>] el0_svc_naked+0x24/0x28
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
---
drivers/pci/hotplug/pciehp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
index 83f3d4a..9d39d85 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -221,7 +221,7 @@ static void pciehp_queue_power_work(struct slot *p_slot, int req)
info->p_slot = p_slot;
INIT_WORK(&info->work, pciehp_power_thread);
info->req = req;
- queue_work(p_slot->wq, &info->work);
+ schedule_work(&info->work);
}
void pciehp_queue_pushbutton_work(struct work_struct *work)
--
1.7.12.4
^ permalink raw reply related
* [PATCH] arm64: dts: renesas: r8a7795: sort subnodes of root node alphabetically
From: Simon Horman @ 2017-12-12 8:27 UTC (permalink / raw)
To: linux-arm-kernel
Sort root sub-nodes alphabetically for allow for easier maintenance
of this file.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Based on renesas-devel-20171211-v4.15-rc3
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a851c88e1e04..62dfc7781cc1 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -30,11 +30,6 @@
i2c7 = &i2c_dvfs;
};
- psci {
- compatible = "arm,psci-1.0", "arm,psci-0.2";
- method = "smc";
- };
-
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -208,6 +203,11 @@
<&a53_3>;
};
+ psci {
+ compatible = "arm,psci-1.0", "arm,psci-0.2";
+ method = "smc";
+ };
+
soc: soc {
compatible = "simple-bus";
interrupt-parent = <&gic>;
--
2.11.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes
From: Simon Horman @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-1-horms+renesas@verge.net.au>
Add reg properties to pciec[01] placeholder nodes
This is to stop the compiler complaining as follows:
$ make
...
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index bf971979aba8..388229072050 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1762,10 +1762,12 @@
};
pciec0: pcie at fe000000 {
+ reg = <0 0xfe000000 0 0x80000>;
/* placeholder */
};
pciec1: pcie at ee800000 {
+ reg = <0 0xee800000 0 0x80000>;
/* placeholder */
};
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus
From: Simon Horman @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-1-horms+renesas@verge.net.au>
Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
The nodes that have been moved do not have any register properties and thus
shouldn't be placed on the bus.
This problem is flagged by the compiler as follows:
$ make
...
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 156 ++++++++++++++++---------------
1 file changed, 80 insertions(+), 76 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index c1b0d0344329..bf971979aba8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -154,6 +154,26 @@
clock-frequency = <0>;
};
+ pmu_a57 {
+ compatible = "arm,cortex-a57-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&a57_0>,
+ <&a57_1>;
+ };
+
+ pmu_a53 {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&a53_0>,
+ <&a53_1>,
+ <&a53_2>,
+ <&a53_3>;
+ };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
@@ -190,18 +210,6 @@
resets = <&cpg 408>;
};
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
- };
-
wdt0: watchdog at e6020000 {
compatible = "renesas,r8a7796-wdt",
"renesas,rcar-gen3-wdt";
@@ -337,26 +345,6 @@
reg = <0 0xe6060000 0 0x50c>;
};
- pmu_a57 {
- compatible = "arm,cortex-a57-pmu";
- interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&a57_0>,
- <&a57_1>;
- };
-
- pmu_a53 {
- compatible = "arm,cortex-a53-pmu";
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&a53_0>,
- <&a53_1>,
- <&a53_2>,
- <&a53_3>;
- };
-
ipmmu_vi0: mmu at febd0000 {
compatible = "renesas,ipmmu-r8a7796";
reg = <0 0xfebd0000 0 0x1000>;
@@ -1577,50 +1565,6 @@
status = "okay";
};
- thermal-zones {
- sensor_thermal1: sensor-thermal1 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 0>;
-
- trips {
- sensor1_crit: sensor1-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
-
- sensor_thermal2: sensor-thermal2 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 1>;
-
- trips {
- sensor2_crit: sensor2-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
-
- sensor_thermal3: sensor-thermal3 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 2>;
-
- trips {
- sensor3_crit: sensor3-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
- };
-
rcar_sound: sound at ec500000 {
/*
* #sound-dai-cells is required
@@ -2027,4 +1971,64 @@
resets = <&cpg 822>;
};
};
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts-extended = <&gic GIC_PPI 13
+ (GIC_CPU_MASK_SIMPLE(6) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 14
+ (GIC_CPU_MASK_SIMPLE(6) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 11
+ (GIC_CPU_MASK_SIMPLE(6) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 10
+ (GIC_CPU_MASK_SIMPLE(6) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ thermal-zones {
+ sensor_thermal1: sensor-thermal1 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 0>;
+
+ trips {
+ sensor1_crit: sensor1-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ sensor_thermal2: sensor-thermal2 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 1>;
+
+ trips {
+ sensor2_crit: sensor2-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ sensor_thermal3: sensor-thermal3 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 2>;
+
+ trips {
+ sensor3_crit: sensor3-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically
From: Simon Horman @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-1-horms+renesas@verge.net.au>
Sort root sub-nodes alphabetically for allow for easier maintenance
of this file.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 66 ++++++++++++++++----------------
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index cc0cca7c0494..c1b0d0344329 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -30,9 +30,34 @@
i2c7 = &i2c_dvfs;
};
- psci {
- compatible = "arm,psci-1.0", "arm,psci-0.2";
- method = "smc";
+ /*
+ * 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 CAN clock - to be overridden by boards that provide it */
+ can_clk: can {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <0>;
};
cpus {
@@ -122,34 +147,16 @@
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 {
+ /* External PCIe clock - can be overridden by the board */
+ pcie_bus_clk: pcie_bus {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <0>;
};
- /* External CAN clock - to be overridden by boards that provide it */
- can_clk: can {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
+ psci {
+ compatible = "arm,psci-1.0", "arm,psci-0.2";
+ method = "smc";
};
/* External SCIF clock - to be overridden by boards that provide it */
@@ -159,13 +166,6 @@
clock-frequency = <0>;
};
- /* External PCIe clock - can be overridden by the board */
- pcie_bus_clk: pcie_bus {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <0>;
- };
-
soc {
compatible = "simple-bus";
interrupt-parent = <&gic>;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: renesas: r8a7796: cleanup of make dtb W=1
From: Simon Horman @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
this short series makes make dtb W=1 builds clean.
Patch 1 sorts subnodes of the root node into alphabetical order
to... well bring some order to things.
Patch 2 moves nodes without reg properties out of the SoC bus,
this is in keeping with recent work for the r8a7795 SoC.
Patch 3 adds reg property to the place holder peciec[01] nodes
Et voil?, make dtb W=1 no longer emits warnings.
$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (Linaro GCC 5.4-2017.05) 5.4.1 20170404
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Based on renesas-devel-20171211-v4.15-rc3
Simon Horman (3):
arm64: dts: renesas: r8a7796: sort subnodes of root node
alphabetically
arm64: dts: renesas: r8a7796: move nodes which have no reg property
out of bus
arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 216 ++++++++++++++++---------------
1 file changed, 111 insertions(+), 105 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Maxime Ripard @ 2017-12-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211193534.GA3967@Red>
Hi,
On Mon, Dec 11, 2017 at 08:35:34PM +0100, Corentin Labbe wrote:
> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Myl?ne Josserand wrote:
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> >
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be handled.
> > Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg) needed
> > for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
>
> As we discussed in private, Chen Yu's patch should be added in your series.
Not really, she mentionned the dependency in the cover letter, and
it's a good way to do things too. Sure, you can do it your way, but
there's no preference.
> Furthermore, MCPM is not automaticaly selected via imply.
Well, yes, is that an issue?
> With all patchs I hit a bug:
> [ 0.898668] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
I guess this is with CONFIG_PROVE_LOCKING enabled?
> [ 0.911162] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
> [ 0.917776] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
What are the changes you've made?
> [ 0.925418] Hardware name: Allwinner sun8i Family
> [ 0.930118] Backtrace:
> [ 0.932596] [<c010cc50>] (dump_backtrace) from [<c010cf0c>] (show_stack+0x18/0x1c)
> [ 0.940158] r7:c0b261e4 r6:60000013 r5:00000000 r4:c0b51958
> [ 0.945820] [<c010cef4>] (show_stack) from [<c06baccc>] (dump_stack+0x8c/0xa0)
> [ 0.953045] [<c06bac40>] (dump_stack) from [<c0149d40>] (___might_sleep+0x150/0x170)
> [ 0.960779] r7:c0b261e4 r6:00000000 r5:000000ee r4:ee844000
> [ 0.966437] [<c0149bf0>] (___might_sleep) from [<c0149dc8>] (__might_sleep+0x68/0xa0)
> [ 0.974253] r4:c0861690
> [ 0.976796] [<c0149d60>] (__might_sleep) from [<c06d2918>] (mutex_lock+0x24/0x68)
> [ 0.984269] r6:c0892f6c r5:ffffffff r4:c0b1bb24
> [ 0.988891] [<c06d28f4>] (mutex_lock) from [<c01ccb6c>] (perf_pmu_register+0x24/0x3e4)
> [ 0.996795] r5:ffffffff r4:ee98b014
> [ 1.000375] [<c01ccb48>] (perf_pmu_register) from [<c03efabc>] (cci_pmu_probe+0x340/0x484)
> [ 1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4 r6:c0b26240 r5:eea19000
> [ 1.016447] r4:ee98b010
> [ 1.018989] [<c03ef77c>] (cci_pmu_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> [ 1.027158] r10:00000000 r9:c0b2610c r8:00000000 r7:fffffdfb r6:c0b2610c r5:ffffffed
> [ 1.034974] r4:eea19010
> [ 1.037511] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
> [ 1.046371] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea19010
> [ 1.052026] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
> [ 1.061062] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea19010 r5:ee845ac0
> [ 1.068879] r4:c0b2610c r3:00000000
> [ 1.072454] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
> [ 1.081228] r7:00000001 r6:c045cb24 r5:ee845ac0 r4:00000000
> [ 1.086883] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010
> [ 1.099750] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
> [ 1.108263] r7:c0b0a4c8 r6:c0b3e848 r5:eea19010 r4:eea19018
> [ 1.113919] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.122523] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
> [ 1.130429] r7:c0b0a4c8 r6:eea19010 r5:eea18a10 r4:eea19018
> [ 1.136089] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
> [ 1.143564] r10:00000000 r9:00000000 r8:00000000 r7:eedf21a4 r6:eea18a10 r5:00000000
> [ 1.151380] r4:eea19000
> [ 1.153915] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
> [ 1.163210] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
> [ 1.173372] r9:00000000 r8:00000000 r7:00000001 r6:00000000 r5:eedf2154 r4:00000000
> [ 1.181107] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
> [ 1.190229] r10:00000001 r9:eea18a10 r8:00000000 r7:00000000 r6:00000000 r5:eedf1d04
> [ 1.198045] r4:eedf2154
> [ 1.200580] [<c0583300>] (of_platform_populate) from [<c03ef2a8>] (cci_platform_probe+0x3c/0x54)
> [ 1.209356] r10:00000000 r9:c0b26168 r8:00000000 r7:fffffdfb r6:c0b26168 r5:ffffffed
> [ 1.217172] r4:eea18a00
> [ 1.219708] [<c03ef26c>] (cci_platform_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> [ 1.228306] r5:ffffffed r4:eea18a10
> [ 1.231881] [<c045e1c4>] (platform_drv_probe) from [<c045c984>] (driver_probe_device+0x254/0x330)
> [ 1.240742] r7:00000000 r6:c0bff498 r5:c0bff494 r4:eea18a10
> [ 1.246397] [<c045c730>] (driver_probe_device) from [<c045cbc4>] (__device_attach_driver+0xa0/0xd4)
> [ 1.255433] r10:00000000 r9:c0bff470 r8:00000000 r7:00000001 r6:eea18a10 r5:ee845ce8
> [ 1.263250] r4:c0b26168 r3:00000000
> [ 1.266825] [<c045cb24>] (__device_attach_driver) from [<c045ad68>] (bus_for_each_drv+0x68/0x9c)
> [ 1.275598] r7:00000001 r6:c045cb24 r5:ee845ce8 r4:00000000
> [ 1.281253] [<c045ad00>] (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.289506] r6:c0b3e848 r5:eea18a44 r4:eea18a10
> [ 1.294120] [<c045c554>] (__device_attach) from [<c045cc44>] (device_initial_probe+0x14/0x18)
> [ 1.302633] r7:c0b0a4c8 r6:c0b3e848 r5:eea18a10 r4:eea18a18
> [ 1.308288] [<c045cc30>] (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.316890] [<c045bacc>] (bus_probe_device) from [<c0459db8>] (device_add+0x40c/0x5a0)
> [ 1.324796] r7:c0b0a4c8 r6:eea18a10 r5:ee993810 r4:eea18a18
> [ 1.330450] [<c04599ac>] (device_add) from [<c0582a58>] (of_device_add+0x3c/0x44)
> [ 1.337926] r10:00000000 r9:c07759d8 r8:00000000 r7:eedf1d54 r6:ee993810 r5:00000000
> [ 1.345743] r4:eea18a00
> [ 1.348277] [<c0582a1c>] (of_device_add) from [<c0582f80>] (of_platform_device_create_pdata+0x7c/0xac)
> [ 1.357572] [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>] (of_platform_bus_create+0xf4/0x1f0)
> [ 1.367734] r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedf1d04 r4:00000000
> [ 1.375469] [<c058300c>] (of_platform_bus_create) from [<c058315c>] (of_platform_bus_create+0x150/0x1f0)
> [ 1.384938] r10:ee993810 r9:c07759d8 r8:00000000 r7:00000001 r6:00000000 r5:eedefe1c
> [ 1.392754] r4:eedf1d04
> [ 1.395289] [<c058300c>] (of_platform_bus_create) from [<c0583374>] (of_platform_populate+0x74/0xd4)
> [ 1.404411] r10:00000001 r9:00000000 r8:00000000 r7:c07759d8 r6:00000000 r5:eedee844
> [ 1.412228] r4:eedefe1c
> [ 1.414769] [<c0583300>] (of_platform_populate) from [<c0a25ee8>] (of_platform_default_populate_init+0x80/0x94)
> [ 1.424844] r10:c0a37848 r9:00000000 r8:c0b59680 r7:c0a37834 r6:ffffe000 r5:c0775ce8
> [ 1.432661] r4:00000000
> [ 1.435200] [<c0a25e68>] (of_platform_default_populate_init) from [<c0102794>] (do_one_initcall+0x5c/0x194)
> [ 1.444925] r5:c0a25e68 r4:c0b0a4c8
> [ 1.448506] [<c0102738>] (do_one_initcall) from [<c0a00f88>] (kernel_init_freeable+0x1d4/0x268)
> [ 1.457195] r9:00000004 r8:c0b59680 r7:c0a37834 r6:c0b59680 r5:c0a47308 r4:c090cfb8
> [ 1.464932] [<c0a00db4>] (kernel_init_freeable) from [<c06cf3b0>] (kernel_init+0x10/0x118)
> [ 1.473187] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c06cf3a0
> [ 1.481004] r4:00000000
> [ 1.483540] [<c06cf3a0>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> [ 1.491098] Exception stack(0xee845fb0 to 0xee845ff8)
> [ 1.496146] 5fa0: 00000000 00000000 00000000 00000000
> [ 1.504313] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 1.512480] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 1.519084] r5:c06cf3a0 r4:00000000
> [ 1.522737] ARM CCI_400_r1 PMU driver probed
>
> And only CPU 0 show up.
This looks more like a bug in the CCI code, and not in this serie
itself. Can you share your whole boot logs?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20171212/cc5f0a81/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Keerthy @ 2017-12-12 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081923.GA10084@lenoch>
On Tuesday 12 December 2017 01:49 PM, Ladislav Michl wrote:
> On Tue, Dec 12, 2017 at 01:38:04PM +0530, Keerthy wrote:
>> On Tuesday 12 December 2017 01:31 PM, Ladislav Michl wrote:
>>> On Tue, Dec 12, 2017 at 01:01:51PM +0530, Keerthy wrote:
>>>>
>>>>
>>>> On Tuesday 12 December 2017 12:46 PM, Ladislav Michl wrote:
>>>>> Keerthy,
>>>>>
>>>>> On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
>>>>>> Remove all the unwanted exports from the driver
>>>>>
>>>>> I'm adding event capture capability to the pwm-omap driver and so far used
>>>>> v4.15-rc3 as codebase.
>>>>>
>>>>> Intended use is an IR receiver; for that I need to measure pulses width and
>>>>> spaces between pulses. So DM timer was setup to generate interupt after
>>>>> both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
>>>>> TCAR_IT_FLAG is cleared.
>>>>>
>>>>> Of course, this is just proof of concept and needs to be polished and
>>>>> generalized, but to make it at least work I need functions you just
>>>>> unexported (plus some new).
>>>>>
>>>>> Question is whenever we need this level of indirection (omap_dm_timer_ops)
>>>>> or plain exports are enough.
>>>>
>>>> The general guidance is not to do plain exports and go via
>>>> omap_dm_timer_ops.
>>>
>>> ...in contrary what other clocksource drivers are doing.
>>>
>>> Now I'm assuming it is okay to extend omap_dm_timer_ops. That would mean
>>> check for ops members to be assigned should be also extended or we should
>>> delete it altogether and assume all members are populated?
>>
>> It should be fine to extend omap_dm_timer_ops. What are the ops missing
>> for your new implementation?
>
> Read capture registers, configure capture and ack interrupt. Perhaps set_pwm
> could be extended to configure capture as well.
>
> I'll update my code on top of your changes and we'll see how it would work.
Okay Thanks!
>
>> Tony,
>>
>> Your thoughts on the above?
>>
>> R
^ permalink raw reply
* [PATCH] mmc: sdhci-of-arasan: Disable clk_xin clock in the remove
From: Flavio Ceolin @ 2017-12-12 8:19 UTC (permalink / raw)
To: linux-arm-kernel
clk_xin is properly prepared/enabled on sdhci_arasan_probe(), and
unprepared/disabled in the error path, but it is not being
unprepared/disabled on sdhci_arasan_remove().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
---
drivers/mmc/host/sdhci-of-arasan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 0720ea7..69bd260 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -692,6 +692,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
struct clk *clk_ahb = sdhci_arasan->clk_ahb;
+ struct clk *clk_xin = devm_clk_get(&pdev->dev, "clk_xin");
if (!IS_ERR(sdhci_arasan->phy)) {
if (sdhci_arasan->is_phy_on)
@@ -705,6 +706,9 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
clk_disable_unprepare(clk_ahb);
+ if (!IS_ERR(clk_xin))
+ clk_disable_unprepare(clk_xin);
+
return ret;
}
--
2.9.5
^ permalink raw reply related
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Mylene JOSSERAND @ 2017-12-12 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211193534.GA3967@Red>
Hello Corentin,
Le Mon, 11 Dec 2017 20:35:34 +0100,
Corentin Labbe <clabbe.montjoie@gmail.com> a ?crit :
> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Myl?ne Josserand wrote:
> > Hello everyone,
> >
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> >
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be
> > handled. Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg)
> > needed for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
> >
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Myl?ne
> >
>
> Hello
>
> As we discussed in private, Chen Yu's patch should be added in your
> series.
Yep, I will do that.
>
> Furthermore, MCPM is not automaticaly selected via imply.
It is selected if you run again a sunxi_defconfig. I guess I can change
to "select".
>
> With all patchs I hit a bug:
> [ 0.898668] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:238 [ 0.911162] in_atomic(): 1,
> irqs_disabled(): 0, pid: 1, name: swapper/0 [ 0.917776] CPU: 0
> PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> [ 0.925418] Hardware name: Allwinner sun8i Family [ 0.930118]
> Backtrace: [ 0.932596] [<c010cc50>] (dump_backtrace) from
> [<c010cf0c>] (show_stack+0x18/0x1c) [ 0.940158] r7:c0b261e4
> r6:60000013 r5:00000000 r4:c0b51958 [ 0.945820] [<c010cef4>]
> (show_stack) from [<c06baccc>] (dump_stack+0x8c/0xa0) [ 0.953045]
> [<c06bac40>] (dump_stack) from [<c0149d40>]
> (___might_sleep+0x150/0x170) [ 0.960779] r7:c0b261e4 r6:00000000
> r5:000000ee r4:ee844000 [ 0.966437] [<c0149bf0>] (___might_sleep)
> from [<c0149dc8>] (__might_sleep+0x68/0xa0) [ 0.974253]
> r4:c0861690 [ 0.976796] [<c0149d60>] (__might_sleep) from
> [<c06d2918>] (mutex_lock+0x24/0x68) [ 0.984269] r6:c0892f6c
> r5:ffffffff r4:c0b1bb24 [ 0.988891] [<c06d28f4>] (mutex_lock) from
> [<c01ccb6c>] (perf_pmu_register+0x24/0x3e4) [ 0.996795]
> r5:ffffffff r4:ee98b014 [ 1.000375] [<c01ccb48>]
> (perf_pmu_register) from [<c03efabc>] (cci_pmu_probe+0x340/0x484)
> [ 1.008631] r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4
> r6:c0b26240 r5:eea19000 [ 1.016447] r4:ee98b010 [ 1.018989]
> [<c03ef77c>] (cci_pmu_probe) from [<c045e21c>]
> (platform_drv_probe+0x58/0xb8) [ 1.027158] r10:00000000
> r9:c0b2610c r8:00000000 r7:fffffdfb r6:c0b2610c r5:ffffffed
> [ 1.034974] r4:eea19010 [ 1.037511] [<c045e1c4>]
> (platform_drv_probe) from [<c045c984>]
> (driver_probe_device+0x254/0x330) [ 1.046371] r7:00000000
> r6:c0bff498 r5:c0bff494 r4:eea19010 [ 1.052026] [<c045c730>]
> (driver_probe_device) from [<c045cbc4>]
> (__device_attach_driver+0xa0/0xd4) [ 1.061062] r10:00000000
> r9:c0bff470 r8:00000000 r7:00000001 r6:eea19010 r5:ee845ac0
> [ 1.068879] r4:c0b2610c r3:00000000 [ 1.072454] [<c045cb24>]
> (__device_attach_driver) from [<c045ad68>]
> (bus_for_each_drv+0x68/0x9c) [ 1.081228] r7:00000001 r6:c045cb24
> r5:ee845ac0 r4:00000000 [ 1.086883] [<c045ad00>]
> (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.095135] r6:c0b3e848 r5:eea19044 r4:eea19010 [ 1.099750]
> [<c045c554>] (__device_attach) from [<c045cc44>]
> (device_initial_probe+0x14/0x18) [ 1.108263] r7:c0b0a4c8
> r6:c0b3e848 r5:eea19010 r4:eea19018 [ 1.113919] [<c045cc30>]
> (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.122523] [<c045bacc>] (bus_probe_device) from [<c0459db8>]
> (device_add+0x40c/0x5a0) [ 1.130429] r7:c0b0a4c8 r6:eea19010
> r5:eea18a10 r4:eea19018 [ 1.136089] [<c04599ac>] (device_add) from
> [<c0582a58>] (of_device_add+0x3c/0x44) [ 1.143564] r10:00000000
> r9:00000000 r8:00000000 r7:eedf21a4 r6:eea18a10 r5:00000000
> [ 1.151380] r4:eea19000 [ 1.153915] [<c0582a1c>]
> (of_device_add) from [<c0582f80>]
> (of_platform_device_create_pdata+0x7c/0xac) [ 1.163210]
> [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>]
> (of_platform_bus_create+0xf4/0x1f0) [ 1.173372] r9:00000000
> r8:00000000 r7:00000001 r6:00000000 r5:eedf2154 r4:00000000
> [ 1.181107] [<c058300c>] (of_platform_bus_create) from
> [<c0583374>] (of_platform_populate+0x74/0xd4) [ 1.190229]
> r10:00000001 r9:eea18a10 r8:00000000 r7:00000000 r6:00000000
> r5:eedf1d04 [ 1.198045] r4:eedf2154 [ 1.200580] [<c0583300>]
> (of_platform_populate) from [<c03ef2a8>]
> (cci_platform_probe+0x3c/0x54) [ 1.209356] r10:00000000
> r9:c0b26168 r8:00000000 r7:fffffdfb r6:c0b26168 r5:ffffffed
> [ 1.217172] r4:eea18a00 [ 1.219708] [<c03ef26c>]
> (cci_platform_probe) from [<c045e21c>] (platform_drv_probe+0x58/0xb8)
> [ 1.228306] r5:ffffffed r4:eea18a10 [ 1.231881] [<c045e1c4>]
> (platform_drv_probe) from [<c045c984>]
> (driver_probe_device+0x254/0x330) [ 1.240742] r7:00000000
> r6:c0bff498 r5:c0bff494 r4:eea18a10 [ 1.246397] [<c045c730>]
> (driver_probe_device) from [<c045cbc4>]
> (__device_attach_driver+0xa0/0xd4) [ 1.255433] r10:00000000
> r9:c0bff470 r8:00000000 r7:00000001 r6:eea18a10 r5:ee845ce8
> [ 1.263250] r4:c0b26168 r3:00000000 [ 1.266825] [<c045cb24>]
> (__device_attach_driver) from [<c045ad68>]
> (bus_for_each_drv+0x68/0x9c) [ 1.275598] r7:00000001 r6:c045cb24
> r5:ee845ce8 r4:00000000 [ 1.281253] [<c045ad00>]
> (bus_for_each_drv) from [<c045c60c>] (__device_attach+0xb8/0x11c)
> [ 1.289506] r6:c0b3e848 r5:eea18a44 r4:eea18a10 [ 1.294120]
> [<c045c554>] (__device_attach) from [<c045cc44>]
> (device_initial_probe+0x14/0x18) [ 1.302633] r7:c0b0a4c8
> r6:c0b3e848 r5:eea18a10 r4:eea18a18 [ 1.308288] [<c045cc30>]
> (device_initial_probe) from [<c045bb58>] (bus_probe_device+0x8c/0x94)
> [ 1.316890] [<c045bacc>] (bus_probe_device) from [<c0459db8>]
> (device_add+0x40c/0x5a0) [ 1.324796] r7:c0b0a4c8 r6:eea18a10
> r5:ee993810 r4:eea18a18 [ 1.330450] [<c04599ac>] (device_add) from
> [<c0582a58>] (of_device_add+0x3c/0x44) [ 1.337926] r10:00000000
> r9:c07759d8 r8:00000000 r7:eedf1d54 r6:ee993810 r5:00000000
> [ 1.345743] r4:eea18a00 [ 1.348277] [<c0582a1c>]
> (of_device_add) from [<c0582f80>]
> (of_platform_device_create_pdata+0x7c/0xac) [ 1.357572]
> [<c0582f04>] (of_platform_device_create_pdata) from [<c0583100>]
> (of_platform_bus_create+0xf4/0x1f0) [ 1.367734] r9:c07759d8
> r8:00000000 r7:00000001 r6:00000000 r5:eedf1d04 r4:00000000
> [ 1.375469] [<c058300c>] (of_platform_bus_create) from
> [<c058315c>] (of_platform_bus_create+0x150/0x1f0) [ 1.384938]
> r10:ee993810 r9:c07759d8 r8:00000000 r7:00000001 r6:00000000
> r5:eedefe1c [ 1.392754] r4:eedf1d04 [ 1.395289] [<c058300c>]
> (of_platform_bus_create) from [<c0583374>]
> (of_platform_populate+0x74/0xd4) [ 1.404411] r10:00000001
> r9:00000000 r8:00000000 r7:c07759d8 r6:00000000 r5:eedee844
> [ 1.412228] r4:eedefe1c [ 1.414769] [<c0583300>]
> (of_platform_populate) from [<c0a25ee8>]
> (of_platform_default_populate_init+0x80/0x94) [ 1.424844]
> r10:c0a37848 r9:00000000 r8:c0b59680 r7:c0a37834 r6:ffffe000
> r5:c0775ce8 [ 1.432661] r4:00000000 [ 1.435200] [<c0a25e68>]
> (of_platform_default_populate_init) from [<c0102794>]
> (do_one_initcall+0x5c/0x194) [ 1.444925] r5:c0a25e68 r4:c0b0a4c8
> [ 1.448506] [<c0102738>] (do_one_initcall) from [<c0a00f88>]
> (kernel_init_freeable+0x1d4/0x268) [ 1.457195] r9:00000004
> r8:c0b59680 r7:c0a37834 r6:c0b59680 r5:c0a47308 r4:c090cfb8
> [ 1.464932] [<c0a00db4>] (kernel_init_freeable) from [<c06cf3b0>]
> (kernel_init+0x10/0x118) [ 1.473187] r10:00000000 r9:00000000
> r8:00000000 r7:00000000 r6:00000000 r5:c06cf3a0 [ 1.481004]
> r4:00000000 [ 1.483540] [<c06cf3a0>] (kernel_init) from
> [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 1.491098] Exception
> stack(0xee845fb0 to 0xee845ff8) [ 1.496146]
> 5fa0: 00000000 00000000 00000000
> 00000000 [ 1.504313] 5fc0: 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000 [ 1.512480] 5fe0: 00000000
> 00000000 00000000 00000000 00000013 00000000 [ 1.519084]
> r5:c06cf3a0 r4:00000000 [ 1.522737] ARM CCI_400_r1 PMU driver
> probed
>
> And only CPU 0 show up.
I am really sorry about that. I tested the patches but not with my last
modifications, I guess...
I will fix it in a V2.
Thank you for reporting the bug.
Best regards,
--
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Ladislav Michl @ 2017-12-12 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9de9b3dc-09f4-d58b-ba5a-60fcb563c665@ti.com>
On Tue, Dec 12, 2017 at 01:38:04PM +0530, Keerthy wrote:
> On Tuesday 12 December 2017 01:31 PM, Ladislav Michl wrote:
> > On Tue, Dec 12, 2017 at 01:01:51PM +0530, Keerthy wrote:
> >>
> >>
> >> On Tuesday 12 December 2017 12:46 PM, Ladislav Michl wrote:
> >>> Keerthy,
> >>>
> >>> On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
> >>>> Remove all the unwanted exports from the driver
> >>>
> >>> I'm adding event capture capability to the pwm-omap driver and so far used
> >>> v4.15-rc3 as codebase.
> >>>
> >>> Intended use is an IR receiver; for that I need to measure pulses width and
> >>> spaces between pulses. So DM timer was setup to generate interupt after
> >>> both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
> >>> TCAR_IT_FLAG is cleared.
> >>>
> >>> Of course, this is just proof of concept and needs to be polished and
> >>> generalized, but to make it at least work I need functions you just
> >>> unexported (plus some new).
> >>>
> >>> Question is whenever we need this level of indirection (omap_dm_timer_ops)
> >>> or plain exports are enough.
> >>
> >> The general guidance is not to do plain exports and go via
> >> omap_dm_timer_ops.
> >
> > ...in contrary what other clocksource drivers are doing.
> >
> > Now I'm assuming it is okay to extend omap_dm_timer_ops. That would mean
> > check for ops members to be assigned should be also extended or we should
> > delete it altogether and assume all members are populated?
>
> It should be fine to extend omap_dm_timer_ops. What are the ops missing
> for your new implementation?
Read capture registers, configure capture and ack interrupt. Perhaps set_pwm
could be extended to configure capture as well.
I'll update my code on top of your changes and we'll see how it would work.
> Tony,
>
> Your thoughts on the above?
>
> R
^ permalink raw reply
* [PATCH] arm64: allwinner: a64: a64-olinuxino: add usb otg
From: Maxime Ripard @ 2017-12-12 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513058169-25516-1-git-send-email-jagan@amarulasolutions.com>
Hi,
On Tue, Dec 12, 2017 at 11:26:09AM +0530, Jagan Teki wrote:
> Add usb otg support for a64-olinuxino board,
> - USB0-ID connected with PH9
> - USB0-VBUSDET connected with PH6
> - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
How was this tested? Did you test the OTG part, or only the peripheral
part?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- 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/20171212/eaa6fe5e/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] [DO NOT MERGE] ARM: dts: sun8i: a83t: bpi-m3: Enable PCM5122 codec with I2S1
From: Chen-Yu Tsai @ 2017-12-12 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-1-wens@csie.org>
This patch enables a PiFi DAC+ V2.0, which is a PCM5122-based audio
output DAC add-on board for the Raspberry Pi B+ and later, connected
to the GPIO header of the Bananapi M3 via jumper cables. The power,
ground, and I2C pins are in the same position, but the I2S ones are
not.
The I2C controller used is I2C2, while the I2S controller is I2S1.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
I'm sure I've asked this before, and IIRC the answer was yes: The I2C
controllers available on the GPIO header all have proper, always-on,
external pull-ups. Does that mean we can enable them by default, seeing
as they are likely intended to be used this way (as I2C pins)?
I think we have a few boards where either I2C or UARTs on the GPIO
header are enabled by default.
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 33 ++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..a9a208ebda12 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -70,6 +70,23 @@
gpio = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
};
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "PiFi DAC+ v2.0";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,mclk-fs = <512>;
+ simple-audio-card,frame-master = <&link_cpu>;
+ simple-audio-card,bitclock-master = <&link_cpu>;
+
+ link_cpu: simple-audio-card,cpu {
+ sound-dai = <&i2s1>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&pcm5122>;
+ };
+ };
+
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
clocks = <&ac100_rtc 1>;
@@ -100,6 +117,22 @@
status = "okay";
};
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_ph_pins>;
+ status = "okay";
+
+ pcm5122: pcm5122 at 4d {
+ #sound-dai-cells = <0>;
+ compatible = "ti,pcm5122";
+ reg = <0x4d>;
+ };
+};
+
+&i2s1 {
+ status = "okay";
+};
+
&mdio {
rgmii_phy: ethernet-phy at 1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.15.0
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: sun8i: a83t: Add I2C device nodes and pinmux settings
From: Chen-Yu Tsai @ 2017-12-12 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-1-wens@csie.org>
The A83T has 3 I2C controllers under the standard bus. There is one
more in the R_ block section. The pin functions for the 3 controllers
are on PH 0~6. I2C2 can also be used on pins PE14 and PE15, but these
pins can also mux the CSI (camera sensor interface) controller's
embedded I2C controller. The latter seems to be preferred in the
reference designs for I2C camera sensor access, freeing I2C2 for other
uses.
This patch adds device nodes for the three standard I2C controllers,
as well as pinmux settings for the PH pins. For I2C0 and I2C1, since
they only have one possible setting, just set them by default.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 52 +++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 354cb4b48f47..b8c5f0a2c463 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -348,6 +348,21 @@
drive-strength = <40>;
};
+ i2c0_pins: i2c0-pins {
+ pins = "PH0", "PH1";
+ function = "i2c0";
+ };
+
+ i2c1_pins: i2c1-pins {
+ pins = "PH2", "PH3";
+ function = "i2c1";
+ };
+
+ i2c2_ph_pins: i2c2-ph-pins {
+ pins = "PH4", "PH5";
+ function = "i2c2";
+ };
+
i2s1_pins: i2s1-pins {
/* I2S1 does not have external MCLK pin */
pins = "PG10", "PG11", "PG12", "PG13";
@@ -499,6 +514,43 @@
status = "disabled";
};
+ i2c0: i2c at 1c2ac00 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2ac00 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C0>;
+ resets = <&ccu RST_BUS_I2C0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c at 1c2b000 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b000 0x400>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C1>;
+ resets = <&ccu RST_BUS_I2C1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c at 1c2b400 {
+ compatible = "allwinner,sun6i-a31-i2c";
+ reg = <0x01c2b400 0x400>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C2>;
+ resets = <&ccu RST_BUS_I2C2>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
emac: ethernet at 1c30000 {
compatible = "allwinner,sun8i-a83t-emac";
syscon = <&syscon>;
--
2.15.0
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: sun8i: a83t: Add I2S controller device nodes
From: Chen-Yu Tsai @ 2017-12-12 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-1-wens@csie.org>
The A83T has 3 I2S controllers. The first is multiplexed with the TDM
controller. The pins are generally connected to the codec side of the
AXP81x PMIC/codec/RTC chip. The second is free for other uses. The
third only supports output, and is connected internally to the HDMI
controller for HDMI audio output.
This patch adds device nodes for the controllers, and a default pinmux
setting for the second controller.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 47 +++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index a384b766f3dc..354cb4b48f47 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -348,6 +348,12 @@
drive-strength = <40>;
};
+ i2s1_pins: i2s1-pins {
+ /* I2S1 does not have external MCLK pin */
+ pins = "PG10", "PG11", "PG12", "PG13";
+ function = "i2s1";
+ };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2",
"PF3", "PF4", "PF5";
@@ -430,6 +436,47 @@
status = "disabled";
};
+ i2s0: i2s at 1c22000 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a83t-i2s";
+ reg = <0x01c22000 0x400>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2S0>, <&ccu CLK_I2S0>;
+ clock-names = "apb", "mod";
+ dmas = <&dma 3>, <&dma 3>;
+ resets = <&ccu RST_BUS_I2S0>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ i2s1: i2s at 1c22400 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a83t-i2s";
+ reg = <0x01c22400 0x400>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2S1>, <&ccu CLK_I2S1>;
+ clock-names = "apb", "mod";
+ dmas = <&dma 4>, <&dma 4>;
+ resets = <&ccu RST_BUS_I2S1>;
+ dma-names = "rx", "tx";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1_pins>;
+ status = "disabled";
+ };
+
+ i2s2: i2s at 1c22800 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a83t-i2s";
+ reg = <0x01c22800 0x400>;
+ interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2S2>, <&ccu CLK_I2S2>;
+ clock-names = "apb", "mod";
+ dmas = <&dma 27>;
+ resets = <&ccu RST_BUS_I2S2>;
+ dma-names = "tx";
+ status = "disabled";
+ };
+
uart0: serial at 1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
--
2.15.0
^ permalink raw reply related
* [PATCH 1/4] ASoC: sun4i-i2s: Add support for A83T
From: Chen-Yu Tsai @ 2017-12-12 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212081148.9194-1-wens@csie.org>
The I2S controller in the A83T is mostly compatible with the one found
in earlier SoCs such as the A20 and A31. While the documents publicly
available for the A83T do not cover this hardware, the officially
released BSP kernel does have register definitions for it. These were
matched against the A20 user manual. The only difference is the TX FIFO
and interrupt status registers have been swapped around, like what we
have seen with the SPDIF controller.
This patch adds support for this hardware.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
.../devicetree/bindings/sound/sun4i-i2s.txt | 2 ++
sound/soc/sunxi/sun4i-i2s.c | 21 +++++++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
index 05d7135a8d2f..b9d50d6cdef3 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
@@ -8,6 +8,7 @@ Required properties:
- compatible: should be one of the following:
- "allwinner,sun4i-a10-i2s"
- "allwinner,sun6i-a31-i2s"
+ - "allwinner,sun8i-a83t-i2s"
- "allwinner,sun8i-h3-i2s"
- reg: physical base address of the controller and length of memory mapped
region.
@@ -23,6 +24,7 @@ Required properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-i2s"
+ - "allwinner,sun8i-a83t-i2s"
- "allwinner,sun8i-h3-i2s"
- resets: phandle to the reset line for this codec
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index bc147e2dcff5..dca1143c1150 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -921,6 +921,23 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
.field_rxchansel = REG_FIELD(SUN4I_I2S_RX_CHAN_SEL_REG, 0, 2),
};
+static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
+ .has_reset = true,
+ .reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
+ .sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
+ .field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 7, 7),
+ .field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 2, 3),
+ .field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 5),
+ .field_fmt_bclk = REG_FIELD(SUN4I_I2S_FMT0_REG, 6, 6),
+ .field_fmt_lrclk = REG_FIELD(SUN4I_I2S_FMT0_REG, 7, 7),
+ .has_slave_select_bit = true,
+ .field_fmt_mode = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 1),
+ .field_txchanmap = REG_FIELD(SUN4I_I2S_TX_CHAN_MAP_REG, 0, 31),
+ .field_rxchanmap = REG_FIELD(SUN4I_I2S_RX_CHAN_MAP_REG, 0, 31),
+ .field_txchansel = REG_FIELD(SUN4I_I2S_TX_CHAN_SEL_REG, 0, 2),
+ .field_rxchansel = REG_FIELD(SUN4I_I2S_RX_CHAN_SEL_REG, 0, 2),
+};
+
static const struct sun4i_i2s_quirks sun8i_h3_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
@@ -1144,6 +1161,10 @@ static const struct of_device_id sun4i_i2s_match[] = {
.compatible = "allwinner,sun6i-a31-i2s",
.data = &sun6i_a31_i2s_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-a83t-i2s",
+ .data = &sun8i_a83t_i2s_quirks,
+ },
{
.compatible = "allwinner,sun8i-h3-i2s",
.data = &sun8i_h3_i2s_quirks,
--
2.15.0
^ permalink raw reply related
* [PATCH 0/4] ARM: sun8i: a83t: Add support for I2S and I2C
From: Chen-Yu Tsai @ 2017-12-12 8:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This series adds support for I2S and I2C on the Allwinner A83T SoC.
The I2S controllers are similar to the ones found on the A31. However
the TX FIFO and interrupt status registers were swapped around. This
seems to be a recurring theme for the audio related hardware blocks.
Patch 1 adds support for the A83T variant with a compatible string
and associated quirks structure.
Patch 2 adds device nodes and default pinmux settings for the I2S
controllers.
Patch 3 adds device nodes and default pinmux settings for the I2C
controllers.
Patch 4 is an example of a PCM5122 codec tied to I2C2 and I2S1 over
the GPIO header of the Banana Pi M3. This patch should not be merged.
Please have a look.
Regards
ChenYu
Chen-Yu Tsai (4):
ASoC: sun4i-i2s: Add support for A83T
ARM: dts: sun8i: a83t: Add I2S controller device nodes
ARM: dts: sun8i: a83t: Add I2C device nodes and pinmux settings
[DO NOT MERGE] ARM: dts: sun8i: a83t: bpi-m3: Enable PCM5122 codec
with I2S1
.../devicetree/bindings/sound/sun4i-i2s.txt | 2 +
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 33 ++++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 99 ++++++++++++++++++++++
sound/soc/sunxi/sun4i-i2s.c | 21 +++++
4 files changed, 155 insertions(+)
--
2.15.0
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Keerthy @ 2017-12-12 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212080134.GA9589@lenoch>
On Tuesday 12 December 2017 01:31 PM, Ladislav Michl wrote:
> On Tue, Dec 12, 2017 at 01:01:51PM +0530, Keerthy wrote:
>>
>>
>> On Tuesday 12 December 2017 12:46 PM, Ladislav Michl wrote:
>>> Keerthy,
>>>
>>> On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
>>>> Remove all the unwanted exports from the driver
>>>
>>> I'm adding event capture capability to the pwm-omap driver and so far used
>>> v4.15-rc3 as codebase.
>>>
>>> Intended use is an IR receiver; for that I need to measure pulses width and
>>> spaces between pulses. So DM timer was setup to generate interupt after
>>> both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
>>> TCAR_IT_FLAG is cleared.
>>>
>>> Of course, this is just proof of concept and needs to be polished and
>>> generalized, but to make it at least work I need functions you just
>>> unexported (plus some new).
>>>
>>> Question is whenever we need this level of indirection (omap_dm_timer_ops)
>>> or plain exports are enough.
>>
>> The general guidance is not to do plain exports and go via
>> omap_dm_timer_ops.
>
> ...in contrary what other clocksource drivers are doing.
>
> Now I'm assuming it is okay to extend omap_dm_timer_ops. That would mean
> check for ops members to be assigned should be also extended or we should
> delete it altogether and assume all members are populated?
It should be fine to extend omap_dm_timer_ops. What are the ops missing
for your new implementation?
Tony,
Your thoughts on the above?
Regards,
Keerthy
>
> Thanks,
> ladis
>
^ permalink raw reply
* [PATCH v5 1/8] clocksource: dmtimer: Remove all the exports
From: Ladislav Michl @ 2017-12-12 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c6a407a8-41c5-f0fd-931c-a58e7e627c82@ti.com>
On Tue, Dec 12, 2017 at 01:01:51PM +0530, Keerthy wrote:
>
>
> On Tuesday 12 December 2017 12:46 PM, Ladislav Michl wrote:
> > Keerthy,
> >
> > On Tue, Dec 12, 2017 at 11:42:10AM +0530, Keerthy wrote:
> >> Remove all the unwanted exports from the driver
> >
> > I'm adding event capture capability to the pwm-omap driver and so far used
> > v4.15-rc3 as codebase.
> >
> > Intended use is an IR receiver; for that I need to measure pulses width and
> > spaces between pulses. So DM timer was setup to generate interupt after
> > both TCAR1 and TCAR2 are filled, values are passed to IR decoder and
> > TCAR_IT_FLAG is cleared.
> >
> > Of course, this is just proof of concept and needs to be polished and
> > generalized, but to make it at least work I need functions you just
> > unexported (plus some new).
> >
> > Question is whenever we need this level of indirection (omap_dm_timer_ops)
> > or plain exports are enough.
>
> The general guidance is not to do plain exports and go via
> omap_dm_timer_ops.
...in contrary what other clocksource drivers are doing.
Now I'm assuming it is okay to extend omap_dm_timer_ops. That would mean
check for ops members to be assigned should be also extended or we should
delete it altogether and assume all members are populated?
Thanks,
ladis
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Javier Martinez Canillas @ 2017-12-12 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2139f436-5646-7f9f-a6cb-285a0fd31969@samsung.com>
Hello Marek,
On Tue, Dec 12, 2017 at 8:54 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Hi Shuah,
>
>
> 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.
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
Best regards,
Javier
^ 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