* [PATCH] serial: sirf: Simplify a test
From: Christophe JAILLET @ 2016-11-01 7:03 UTC (permalink / raw)
To: linux-arm-kernel
'dmaengine_prep_dma_cyclic()' does not return an error pointer, so the test
can be simplified to be more consistent.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/tty/serial/sirfsoc_uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sirfsoc_uart.c b/drivers/tty/serial/sirfsoc_uart.c
index b186c9c4f850..666ca3156961 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -609,7 +609,7 @@ static void sirfsoc_uart_start_next_rx_dma(struct uart_port *port)
sirfport->rx_dma_items.dma_addr, SIRFSOC_RX_DMA_BUF_SIZE,
SIRFSOC_RX_DMA_BUF_SIZE / 2,
DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
- if (IS_ERR_OR_NULL(sirfport->rx_dma_items.desc)) {
+ if (!sirfport->rx_dma_items.desc) {
dev_err(port->dev, "DMA slave single fail\n");
return;
}
--
2.9.3
^ permalink raw reply related
* [PATCH] [media] atmel-isc: release the filehandle if it's not the only one.
From: Songjun Wu @ 2016-11-01 8:08 UTC (permalink / raw)
To: linux-arm-kernel
Release the filehandle in 'isc_open' if it's not the only filehandle
opened for the associated video_device.
Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
---
drivers/media/platform/atmel/atmel-isc.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
index 8e25d3f..5e08404 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -926,21 +926,21 @@ static int isc_open(struct file *file)
if (ret < 0)
goto unlock;
- if (!v4l2_fh_is_singular_file(file))
- goto unlock;
+ ret = !v4l2_fh_is_singular_file(file);
+ if (ret)
+ goto fh_rel;
ret = v4l2_subdev_call(sd, core, s_power, 1);
- if (ret < 0 && ret != -ENOIOCTLCMD) {
- v4l2_fh_release(file);
- goto unlock;
- }
+ if (ret < 0 && ret != -ENOIOCTLCMD)
+ goto fh_rel;
ret = isc_set_fmt(isc, &isc->fmt);
- if (ret) {
+ if (ret)
v4l2_subdev_call(sd, core, s_power, 0);
- v4l2_fh_release(file);
- }
+fh_rel:
+ if (ret)
+ v4l2_fh_release(file);
unlock:
mutex_unlock(&isc->lock);
return ret;
--
2.7.4
^ permalink raw reply related
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Michael Zoran @ 2016-11-01 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1795308650.27171.9a53158f-312d-40ce-80ce-8bf792d8db34.open-xchange@email.1und1.de>
On Mon, 2016-10-31 at 21:34 +0100, Stefan Wahren wrote:
> I inspired by this issue [1] i build up a slightly modified setup
> with a
> Raspberry Pi B (mainline kernel 4.9rc3), a powered 7 port USB hub and
> 5 Prolific
> PL2303 USB to serial convertors. I modified the usb_test for dwc2
> [2], which
> only tries to open all ttyUSB devices one after the other.?
>
> Unfortunately the complete system stuck after opening the first
> ttyUSB device (
> heartbeat LED stop blinking, no reaction to debug UART). The only way
> to
> reanimate the system is to powerdown the USB hub with the USB to
> serial
> convertors.
>
> [1] - https://github.com/raspberrypi/linux/issues/1692
> [2] - https://gist.github.com/lategoodbye/dd0d30af27b6f101b03d5923b27
> 9dbaa
>
> pi at raspberrypi:~$ lsusb -t
> /:??Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
> ????|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/3p, 480M
> ????????|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class,
> Driver=smsc95xx,
> 480M
> ????????|__ Port 2: Dev 11, If 0, Class=Hub, Driver=hub/4p, 480M
> ????????????|__ Port 3: Dev 15, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> ????????????|__ Port 1: Dev 12, If 0, Class=Hub, Driver=hub/4p, 480M
> ????????????????|__ Port 2: Dev 14, If 0, Class=Vendor Specific
> Class,
> Driver=pl2303, 12M
> ????????????????|__ Port 3: Dev 16, If 0, Class=Vendor Specific
> Class,
> Driver=pl2303, 12M
> ????????????|__ Port 4: Dev 17, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
> ????????????|__ Port 2: Dev 13, If 0, Class=Vendor Specific Class,
> Driver=pl2303, 12M
>
Since I didn't see a response, I'll go ahead and add my two cents.
Hopefully nobody minds me chiming in here.
I see these kinds of issues with USB on the RPI all the time.
Typically, it's just the USB that breaks down not a hang in the CPU.
The issue is that I think the USB controller in the RPI chipset was
designed for the cellphone/set top box market. In those markets, the
USB port is only used to connect to one device at a time. For example,
with a cell phone you might connect it to a PC to transfer data. On a
set top box, you might plug in a USB flash drive with video to play.
The RPI doesn't have a proper USB controller like you find in a PC.
Instead it has a fixed number of hardware slots(I think the number is
between 5-7) that are used for pending transfers. Once the slots are
full, very little can be done. And because USB 2.0 is based on
polling, the connected USB devices are constantly polled even if
nothing is happening.
The DWC_OTG driver works a bit better even though it's not perfect.
That driver makes an attempt to schedule USB activity and send it to
the hardware a bit at a time just like a PC USB controller does.
Unfortunatly, to get the precision required on some of the lower end
RPIs, it's necessary to use FIQ which is somewhat outside the Linux
driver model.
Although I don't completely agree that FIQ is necessary on the high end
RPIs with multiple cores. In fact, I have a few local modifications
to the interrupt controller driver to round robin dispatch IRQs between
core to get more concurrency at the expense of more CPU cache misses. I
think this reduces the need for FIQ, but some other disagree...
^ permalink raw reply
* [PATCH v2 0/4] ARM: imx31: clock initialization fixes
From: Shawn Guo @ 2016-11-01 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-1-git-send-email-vz@mleia.com>
On Mon, Sep 26, 2016 at 03:03:39AM +0300, Vladimir Zapolskiy wrote:
> Vladimir Zapolskiy (4):
> ARM: dts: imx31: fix clock control module interrupts description
> ARM: dts: imx31: move CCM device node to AIPS2 bus devices
> clk: imx31: fix rewritten input argument of mx31_clocks_init()
> ARM: clk: imx31: properly init clocks for machines with DT
Applied all, thanks.
^ permalink raw reply
* [PATCH] [media] atmel-isc: release the filehandle if it's not the only one.
From: Hans Verkuil @ 2016-11-01 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477987726-4257-1-git-send-email-songjun.wu@microchip.com>
On 01/11/16 09:08, Songjun Wu wrote:
> Release the filehandle in 'isc_open' if it's not the only filehandle
> opened for the associated video_device.
What's wrong with that? You should always be able to open the device
multiple times. v4l2-compliance will fail after this patch. I'm not sure
what you intended to do here, but this patch is wrong.
Regards,
Hans
>
> Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
> ---
>
> drivers/media/platform/atmel/atmel-isc.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
> index 8e25d3f..5e08404 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -926,21 +926,21 @@ static int isc_open(struct file *file)
> if (ret < 0)
> goto unlock;
>
> - if (!v4l2_fh_is_singular_file(file))
> - goto unlock;
> + ret = !v4l2_fh_is_singular_file(file);
> + if (ret)
> + goto fh_rel;
>
> ret = v4l2_subdev_call(sd, core, s_power, 1);
> - if (ret < 0 && ret != -ENOIOCTLCMD) {
> - v4l2_fh_release(file);
> - goto unlock;
> - }
> + if (ret < 0 && ret != -ENOIOCTLCMD)
> + goto fh_rel;
>
> ret = isc_set_fmt(isc, &isc->fmt);
> - if (ret) {
> + if (ret)
> v4l2_subdev_call(sd, core, s_power, 0);
> - v4l2_fh_release(file);
> - }
>
> +fh_rel:
> + if (ret)
> + v4l2_fh_release(file);
> unlock:
> mutex_unlock(&isc->lock);
> return ret;
>
^ permalink raw reply
* [PATCH] [media] atmel-isc: release the filehandle if it's not the only one.
From: Wu, Songjun @ 2016-11-01 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c90098d4-4d53-d2e1-2d3e-e38e7d548f45@xs4all.nl>
Sorry, my mistake, the device should be able to opened multiple times.
It's a wrong patch.
On 11/1/2016 16:52, Hans Verkuil wrote:
> On 01/11/16 09:08, Songjun Wu wrote:
>> Release the filehandle in 'isc_open' if it's not the only filehandle
>> opened for the associated video_device.
>
> What's wrong with that? You should always be able to open the device
> multiple times. v4l2-compliance will fail after this patch. I'm not sure
> what you intended to do here, but this patch is wrong.
>
> Regards,
>
> Hans
>
>>
>> Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
>> ---
>>
>> drivers/media/platform/atmel/atmel-isc.c | 18 +++++++++---------
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/platform/atmel/atmel-isc.c
>> b/drivers/media/platform/atmel/atmel-isc.c
>> index 8e25d3f..5e08404 100644
>> --- a/drivers/media/platform/atmel/atmel-isc.c
>> +++ b/drivers/media/platform/atmel/atmel-isc.c
>> @@ -926,21 +926,21 @@ static int isc_open(struct file *file)
>> if (ret < 0)
>> goto unlock;
>>
>> - if (!v4l2_fh_is_singular_file(file))
>> - goto unlock;
>> + ret = !v4l2_fh_is_singular_file(file);
>> + if (ret)
>> + goto fh_rel;
>>
>> ret = v4l2_subdev_call(sd, core, s_power, 1);
>> - if (ret < 0 && ret != -ENOIOCTLCMD) {
>> - v4l2_fh_release(file);
>> - goto unlock;
>> - }
>> + if (ret < 0 && ret != -ENOIOCTLCMD)
>> + goto fh_rel;
>>
>> ret = isc_set_fmt(isc, &isc->fmt);
>> - if (ret) {
>> + if (ret)
>> v4l2_subdev_call(sd, core, s_power, 0);
>> - v4l2_fh_release(file);
>> - }
>>
>> +fh_rel:
>> + if (ret)
>> + v4l2_fh_release(file);
>> unlock:
>> mutex_unlock(&isc->lock);
>> return ret;
>>
^ permalink raw reply
* [PATCH v2] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Christoffer Dall @ 2016-11-01 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477650470-19104-1-git-send-email-marc.zyngier@arm.com>
On Fri, Oct 28, 2016 at 11:27:50AM +0100, Marc Zyngier wrote:
> Architecturally, TLBs are private to the (physical) CPU they're
> associated with. But when multiple vcpus from the same VM are
> being multiplexed on the same CPU, the TLBs are not private
> to the vcpus (and are actually shared across the VMID).
>
> Let's consider the following scenario:
>
> - vcpu-0 maps PA to VA
> - vcpu-1 maps PA' to VA
>
> If run on the same physical CPU, vcpu-1 can hit TLB entries generated
> by vcpu-0 accesses, and access the wrong physical page.
>
> The solution to this is to keep a per-VM map of which vcpu ran last
> on each given physical CPU, and invalidate local TLBs when switching
> to a different vcpu from the same VM.
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> Fixed comments, added Mark's RB.
>
> arch/arm/include/asm/kvm_host.h | 11 ++++++++++-
> arch/arm/include/asm/kvm_hyp.h | 1 +
> arch/arm/kvm/arm.c | 35 ++++++++++++++++++++++++++++++++++-
> arch/arm/kvm/hyp/switch.c | 9 +++++++++
> arch/arm64/include/asm/kvm_host.h | 11 ++++++++++-
> arch/arm64/kvm/hyp/switch.c | 8 ++++++++
> 6 files changed, 72 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 2d19e02..7290de6 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -57,6 +57,9 @@ struct kvm_arch {
> /* VTTBR value associated with below pgd and vmid */
> u64 vttbr;
>
> + /* The last vcpu id that ran on each physical CPU */
> + int __percpu *last_vcpu_ran;
> +
> /* Timer */
> struct arch_timer_kvm timer;
>
> @@ -174,6 +177,13 @@ struct kvm_vcpu_arch {
> /* vcpu power-off state */
> bool power_off;
>
> + /*
> + * Local TLBs potentially contain conflicting entries from
> + * another vCPU within this VMID. All entries for this VMID must
> + * be invalidated from (local) TLBs before we run this vCPU.
> + */
> + bool tlb_vmid_stale;
> +
> /* Don't run the guest (internal implementation need) */
> bool pause;
>
> @@ -292,7 +302,6 @@ struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
> static inline void kvm_arch_hardware_unsetup(void) {}
> static inline void kvm_arch_sync_events(struct kvm *kvm) {}
> static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> -static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
> static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>
> static inline void kvm_arm_init_debug(void) {}
> diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
> index 343135e..5850890 100644
> --- a/arch/arm/include/asm/kvm_hyp.h
> +++ b/arch/arm/include/asm/kvm_hyp.h
> @@ -71,6 +71,7 @@
> #define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0)
> #define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0)
> #define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0)
> +#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0)
> #define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4)
> #define PRRR __ACCESS_CP15(c10, 0, c2, 0)
> #define NMRR __ACCESS_CP15(c10, 0, c2, 1)
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 08bb84f..e0d93cd 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -114,11 +114,18 @@ void kvm_arch_check_processor_compat(void *rtn)
> */
> int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> {
> - int ret = 0;
> + int ret, cpu;
>
> if (type)
> return -EINVAL;
>
> + kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
> + if (!kvm->arch.last_vcpu_ran)
> + return -ENOMEM;
> +
> + for_each_possible_cpu(cpu)
> + *per_cpu_ptr(kvm->arch.last_vcpu_ran, cpu) = -1;
> +
> ret = kvm_alloc_stage2_pgd(kvm);
> if (ret)
> goto out_fail_alloc;
> @@ -141,6 +148,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> out_free_stage2_pgd:
> kvm_free_stage2_pgd(kvm);
> out_fail_alloc:
> + free_percpu(kvm->arch.last_vcpu_ran);
> + kvm->arch.last_vcpu_ran = NULL;
> return ret;
> }
>
> @@ -168,6 +177,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> {
> int i;
>
> + free_percpu(kvm->arch.last_vcpu_ran);
> + kvm->arch.last_vcpu_ran = NULL;
> +
> for (i = 0; i < KVM_MAX_VCPUS; ++i) {
> if (kvm->vcpus[i]) {
> kvm_arch_vcpu_free(kvm->vcpus[i]);
> @@ -310,6 +322,27 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> +void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu)
> +{
why is calling this from here sufficient?
You only get a notification from preempt notifiers if you were preempted
while running (or rather while the vcpu was loaded). I think this needs
to go in kvm_arch_vcpu_load, but be aware that the vcpu_load gets called
for other vcpu ioctls and doesn't necessarily imply that the vcpu will
actually run, which is also the case for the sched_in notification, btw.
The worst that will happen in that case is a bit of extra TLB
invalidation, so sticking with kvm_arch_vcpu_load is probably fine.
> + int *last_ran;
> +
> + last_ran = per_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran, cpu);
> +
> + /*
> + * We might get preempted before the vCPU actually runs, but
> + * this is fine. Our TLBI stays pending until we actually make
> + * it to __activate_vm, so we won't miss a TLBI. If another
> + * vCPU gets scheduled, it will see our vcpu_id in last_ran,
> + * and pend a TLBI for itself.
> + */
> + if (*last_ran != vcpu->vcpu_id) {
> + if (*last_ran != -1)
> + vcpu->arch.tlb_vmid_stale = true;
> +
> + *last_ran = vcpu->vcpu_id;
> + }
> +}
> +
> void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> {
> vcpu->cpu = cpu;
> diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
> index 92678b7..a411762 100644
> --- a/arch/arm/kvm/hyp/switch.c
> +++ b/arch/arm/kvm/hyp/switch.c
> @@ -75,6 +75,15 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> {
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> write_sysreg(kvm->arch.vttbr, VTTBR);
> + if (vcpu->arch.tlb_vmid_stale) {
> + /* Force vttbr to be written */
> + isb();
> + /* Local invalidate only for this VMID */
> + write_sysreg(0, TLBIALL);
> + dsb(nsh);
> + vcpu->arch.tlb_vmid_stale = false;
> + }
> +
why not call this directly when you notice it via kvm_call_hyp as
opposed to adding another conditional in the critical path?
> write_sysreg(vcpu->arch.midr, VPIDR);
> }
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index bd94e67..0f62829 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -62,6 +62,9 @@ struct kvm_arch {
> /* VTTBR value associated with above pgd and vmid */
> u64 vttbr;
>
> + /* The last vcpu id that ran on each physical CPU */
> + int __percpu *last_vcpu_ran;
> +
> /* The maximum number of vCPUs depends on the used GIC model */
> int max_vcpus;
>
> @@ -252,6 +255,13 @@ struct kvm_vcpu_arch {
> /* vcpu power-off state */
> bool power_off;
>
> + /*
> + * Local TLBs potentially contain conflicting entries from
> + * another vCPU within this VMID. All entries for this VMID must
> + * be invalidated from (local) TLBs before we run this vCPU.
> + */
> + bool tlb_vmid_stale;
> +
> /* Don't run the guest (internal implementation need) */
> bool pause;
>
> @@ -368,7 +378,6 @@ static inline void __cpu_reset_hyp_mode(unsigned long vector_ptr,
> static inline void kvm_arch_hardware_unsetup(void) {}
> static inline void kvm_arch_sync_events(struct kvm *kvm) {}
> static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> -static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
> static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>
> void kvm_arm_init_debug(void);
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 83037cd..99d0f33 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -131,6 +131,14 @@ static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> {
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> write_sysreg(kvm->arch.vttbr, vttbr_el2);
> + if (vcpu->arch.tlb_vmid_stale) {
> + /* Force vttbr_el2 to be written */
> + isb();
> + /* Local invalidate only for this VMID */
> + asm volatile("tlbi vmalle1" : : );
> + dsb(nsh);
> + vcpu->arch.tlb_vmid_stale = false;
> + }
> }
>
> static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
> --
> 2.1.4
>
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH] ARM: dts: r8a7794: remove Z clock
From: Simon Horman @ 2016-11-01 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2289596.xFBEUD1OgK@wasted.cogentembedded.com>
On Sun, Oct 30, 2016 at 12:31:27AM +0300, Sergei Shtylyov wrote:
> R8A7794 doesn't have Cortex-A15 CPUs, thus there's no Z clock...
>
> Fixes: 0dce5454d5c2 ("ARM: shmobile: Initial r8a7794 SoC device tree")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> The patch is against the 'master' branch of Simon Horman's 'renesas.git' repo.
Thanks, I have queued this up.
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Russell King - ARM Linux @ 2016-11-01 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <847975190.29034.38a9c7fa-bdf8-4732-ac8b-cf15c21e3ce8.open-xchange@email.1und1.de>
On Mon, Oct 31, 2016 at 08:54:33PM +0100, Stefan Wahren wrote:
> [ 366.696043] INFO: task ext4lazyinit:70 blocked for more than 120 seconds.
> [ 366.703046] Not tainted 4.9.0-rc1 #7
> [ 366.707188] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
> message.
> [ 366.715161] ext4lazyinit D c05aa6ac 0 70 2 0x00000000
This looks like a very different problem - I guess one for ext4 people.
> [ 366.721713] [<c05aa6ac>] (__schedule) from [<c05aafb8>] (schedule+0x3c/0xbc)
> [ 366.728972] [<c05aafb8>] (schedule) from [<c05aee38>]
> (schedule_timeout+0x23c/0x3d8)
> [ 366.736917] [<c05aee38>] (schedule_timeout) from [<c05aa398>]
> (io_schedule_timeout+0xb8/0x13c)
> [ 366.745721] [<c05aa398>] (io_schedule_timeout) from [<c05ab9d8>]
> (T.1434+0xac/0x12c)
> [ 366.753671] [<c05ab9d8>] (T.1434) from [<c02c7668>]
> (submit_bio_wait+0x50/0x68)
> [ 366.761078] [<c02c7668>] (submit_bio_wait) from [<c02d9a58>]
> (blkdev_issue_zeroout+0x174/0x1ec)
> [ 366.769984] [<c02d9a58>] (blkdev_issue_zeroout) from [<c0196e4c>]
> (ext4_init_inode_table+0x1ac/0x3b0)
> [ 366.779410] [<c0196e4c>] (ext4_init_inode_table) from [<c01ba770>]
> (ext4_lazyinit_thread+0x280/0x398)
> [ 366.788803] [<c01ba770>] (ext4_lazyinit_thread) from [<c003bce4>]
> (kthread+0xc4/0xe0)
> [ 366.796828] [<c003bce4>] (kthread) from [<c000a34c>]
> (ret_from_fork+0x14/0x28)
> [ 366.804200]
> [ 366.804200] Showing all locks held in the system:
> [ 366.810465] 2 locks held by khungtaskd/10:
> [ 366.814707] #0: [ 366.816500] (
> rcu_read_lock[ 366.819360] ){......}
> , at: [ 366.822236] [<c0093a10>] watchdog+0xb4/0x61c
> [ 366.826656] #1: [ 366.828450] (
> tasklist_lock[ 366.831312] ){.+.+..}
> , at: [ 366.834320] [<c0051dbc>] debug_show_all_locks+0x28/0x1bc
> [ 366.839701] 4 locks held by ext4lazyinit/70:
> [ 366.844107] #0: [ 366.845897] (
> &type->s_umount_key[ 366.849280] #22
> ){++++++}[ 366.851866] , at:
> [ 366.854044] [<c01ba5c4>] ext4_lazyinit_thread+0xd4/0x398
> [ 366.859400] #1: [ 366.861178] (
> sb_writers[ 366.863897] #3
> ){.+.+.+}[ 366.866412] , at:
> [ 366.868475] [<c01ba5dc>] ext4_lazyinit_thread+0xec/0x398
> [ 366.873925] #2: [ 366.875716] (
> jbd2_handle[ 366.878405] ){++++..}
> , at: [ 366.881292] [<c01f661c>] start_this_handle+0xec/0x404
> [ 366.886492] #3: [ 366.888284] (
> &meta_group_info[i]->alloc_sem[ 366.892620] ){++++..}
> , at: [ 366.895624] [<c0196d58>] ext4_init_inode_table+0xb8/0x3b0
> [ 366.901093] 4 locks held by bash/385:
> [ 366.904895] #0: [ 366.906686] (
> sb_writers[ 366.909288] #4
> ){.+.+.+}[ 366.911787] , at:
> [ 366.913972] [<c011f7d4>] vfs_write+0x194/0x1a4
> [ 366.918456] #1: [ 366.920234] (
> &of->mutex[ 366.922824] ){+.+.+.}
> , at: [ 366.925940] [<c019029c>] kernfs_fop_write+0xc0/0x1d0
> [ 366.930942] #2: [ 366.932714] (
> s_active[ 366.935265] #43
> ){.+.+.+}[ 366.937864] , at:
> [ 366.939927] [<c01902a4>] kernfs_fop_write+0xc8/0x1d0
> [ 366.945029] #3: [ 366.946818] (
> pm_mutex[ 366.949242] ){+.+.+.}
> , at: [ 366.952111] [<c005b7e4>] pm_suspend+0x90/0x81c
> [ 366.956697]
> [ 366.958229] =============================================
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v14 1/4] clk: mediatek: Add MT2701 clock support
From: James Liao @ 2016-11-01 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031180647.GR16026@codeaurora.org>
Hi Stephen,
On Mon, 2016-10-31 at 11:06 -0700, Stephen Boyd wrote:
> On 10/31, James Liao wrote:
> > On Thu, 2016-10-27 at 18:17 -0700, Stephen Boyd wrote:
> > > On 10/21, Erin Lo wrote:
> > > > @@ -244,3 +256,31 @@ void mtk_clk_register_composites(const struct mtk_composite *mcs,
> > > > clk_data->clks[mc->id] = clk;
> > > > }
> > > > }
> > > > +
> > > > +void mtk_clk_register_dividers(const struct mtk_clk_divider *mcds,
> > > > + int num, void __iomem *base, spinlock_t *lock,
> > > > + struct clk_onecell_data *clk_data)
> > > > +{
> > > > + struct clk *clk;
> > > > + int i;
> > > > +
> > > > + for (i = 0; i < num; i++) {
> > > > + const struct mtk_clk_divider *mcd = &mcds[i];
> > > > +
> > > > + if (clk_data && !IS_ERR_OR_NULL(clk_data->clks[mcd->id]))
> > >
> > > NULL is a valid clk. IS_ERR_OR_NULL is usually wrong.
> >
> > Why NULL is a valid clk?
>
> Perhaps at some point we'll want to return a NULL pointer to
> clk_get() callers so that they can handle things like optional
> clocks easily without having any storage requirements. I don't
> know if we'll ever do that, but that's just a possibility.
>
> >
> > clk_data is designed for multiple initialization from different clock
> > types, such as infra_clk_data in clk-mt2701.c. So it will ignore valid
> > clocks to avoid duplicated clock registration. Here I assume a clock
> > pointer with error code or NULL to be an invalid (not initialized)
> > clock.
> >
>
> Ok. Would it be possible to initialize the array with all error
> pointers? That would make things less error prone, but it
Yes. Current mtk_alloc_clk_data() implementation init all elements with
ERR_PTR(-ENOENT).
> probably doesn't matter at all anyway because this is done during
> registration time. IS_ERR_OR_NULL makes me take a second look
> each time, because it's usually wrong.
I see. Although currently all Mediatek clk drivers use
mtk_alloc_clk_data() to allocate clk_data, I would like to keep the
flexibility to support zero-initialized clk_data such as a static
structure. So I prefer to treat a NULL pointer as an uninitialized
clock.
Best regards,
James
^ permalink raw reply
* [PATCH v2] ARM: davinci: da850: Fix pwm name matching
From: Sekhar Nori @ 2016-11-01 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477944264-18637-1-git-send-email-david@lechnology.com>
On Tuesday 01 November 2016 01:34 AM, David Lechner wrote:
> This fixes pwm name matching for DA850 familiy devices. When using device
> tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact
> same name, which caused errors when trying to register the devices.
>
> We cannot have multiple entries for the same clock in in da850_clks[], so
> we have added child clocks to the EHRPWM and ECAP LPSC clocks so that each
> PWM device will have its own clock for proper name matching.
>
> Signed-off-by: David Lechner <david@lechnology.com>
This looks good to me. Thanks!
I have added it to my fixes branch for further testing before sending
upstream.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] staging: vc04_services: setup DMA and coherent mask
From: Russell King - ARM Linux @ 2016-11-01 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477943593.30971.3.camel@crowfest.net>
On Mon, Oct 31, 2016 at 12:53:13PM -0700, Michael Zoran wrote:
> On Mon, 2016-10-31 at 11:40 -0700, Michael Zoran wrote:
> > The comment is easy to change.
> >
> > I don't have the log available ATM, but if I remember the DMA API's
> > bugcheck the first time that are used.??
> >
> > I think this was a policy decision or something because the
> > information
> > should be available in the dma-ranges.
> >
> > If it's important, I can setup a test again without the change and e-
> > mail the logs.
> >
> > If you look at the DWC2 driver you will see that it also sets this
> > mask.
>
> OK, I'm begging to understand this. It appears the architecture
> specific paths are very different.
>
> In arm the mask and coherent is set to DMA_BIT_MASK(32) in mm/dma-
> mapping.c the first time the dma APIs are used.
I'm not sure where you get that from, this is absolutely not the case.
> On arm64, it appears
> this variable is uninitialized and will contain random crude.
>
> Like I said, I don't know if this is a policy decision or if it just
> slipped through the cracks.
>
> arch/arm/mm/dma-mapping.c(Note the call to get_coherent_dma_mask(dev))
>
> static u64 get_coherent_dma_mask(struct device *dev)
> {
> u64 mask = (u64)DMA_BIT_MASK(32);
>
> if (dev) {
> mask = dev->coherent_dma_mask;
>
> /*
> ?* Sanity check the DMA mask - it must be non-zero, and
> ?* must be able to be satisfied by a DMA allocation.
> ?*/
> if (mask == 0) {
> dev_warn(dev, "coherent DMA mask is unset\n");
> return 0;
If the mask is unset (iow, zero) this function returns zero. There
is no "the first time" here anywhere - dev->coherent_dma_mask remains
at zero and doesn't change as a result of calling this path.
> }
>
> if (!__dma_supported(dev, mask, true))
> return 0;
> }
>
> return mask;
> }
>
> static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t
> *handle,
> ?gfp_t gfp, pgprot_t prot, bool is_coherent,
> ?unsigned long attrs, const void *caller)
> {
> u64 mask = get_coherent_dma_mask(dev);
> struct page *page = NULL;
> void *addr;
> bool allowblock, cma;
> struct arm_dma_buffer *buf;
> struct arm_dma_alloc_args args = {
> .dev = dev,
> .size = PAGE_ALIGN(size),
> .gfp = gfp,
> .prot = prot,
> .caller = caller,
> .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) ==
> 0),
> .coherent_flag = is_coherent ? COHERENT : NORMAL,
> };
which then causes:
if (!mask)
return NULL;
this function to return NULL, hence failing the request. Rightfully
so, because we don't know what an acceptable allocation for the device
would be, as the device is effectively saying "I support 0 bits of DMA
address."
Now, firstly, the driver is required to call one of:
dma_set_mask_and_coherent()
dma_set_coherent_mask()
if it is to use coherent DMA - see Documentation/DMA-API-HOWTO.txt.
However, the bus code should already have setup a default mask in both
dev->dma_mask and the coherent DMA mask if DMA is possible, which
normally will be the 32-bit mask.
As explained in the document, if the device and driver supports 64-bit
addressing, and wants to make use of it, it must successfully negotiate
with the kernel before using it, which includes making calls to change
the DMA masks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH V4 10/10] arm64: KVM: add guest SEA support
From: Russell King - ARM Linux @ 2016-11-01 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <85443ee1-9981-c7e8-fe88-a3aac48c3e80@codeaurora.org>
On Mon, Oct 31, 2016 at 04:36:33PM -0600, Baicar, Tyler wrote:
> Hello Russell,
>
> On 10/31/2016 4:02 AM, Russell King - ARM Linux wrote:
> >The subject line on this patch is misleading - it's not only ARM64
> >specific...
> Thank you for the feedback!
>
> I only put ARM64 in the subject line because this patch only really adds
> guest SEA support for the ARM64 KVM code. The ARM code had to be edited
> since both the ARM and ARM64 KVM code use arch/arm/kvm/mmu.c. I can change
> the subject line to "arm/arm64: KVM: add guest SEA support" if you think
> that is better.
Yes please, I almost skipped over it while catching up because it didn't
say "arm", it was only that I'd happened to read the cover message that
I'd spotted arch/arm in the diffstat, and then had to go digging for the
changes to review.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: shmobile: r8a7779/marzen: Add board part number to DT bindings
From: Simon Horman @ 2016-11-01 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477921384-1812-1-git-send-email-geert+renesas@glider.be>
On Mon, Oct 31, 2016 at 02:43:04PM +0100, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, I have queued this up.
^ permalink raw reply
* [RFC PATCH v2 3/5] ARM64: dts: meson-gxl: Add ethernet nodes with internal PHY
From: Sergei Shtylyov @ 2016-11-01 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477932987-27871-4-git-send-email-narmstrong@baylibre.com>
Hello.
On 10/31/2016 7:56 PM, Neil Armstrong wrote:
> Add Ethernet node with Internal PHY selection for the Amlogic GXL SoCs
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 45 ++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index d1bf381..71670c3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -47,6 +47,24 @@
>
> / {
> compatible = "amlogic,meson-gxl";
> +
> +
No need for these empty lines.
> +};
> +
> +ðmac {
> + reg = <0x0 0xc9410000 0x0 0x10000
> + 0x0 0xc8834540 0x0 0x4>;
> +
> + clocks = <&clkc CLKID_ETH>,
> + <&clkc CLKID_FCLK_DIV2>,
> + <&clkc CLKID_MPLL2>;
> + clock-names = "stmmaceth", "clkin0", "clkin1";
> +
> + mdio0: mdio0 {
Should be "mdio0: mdio {" in oprder to comply woth the DT spec.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "snps,dwmac-mdio";
> + };
> };
>
> &aobus {
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH] ARM: OMAP2+: avoid NULL pointer dereference
From: Nicolae Rosia @ 2016-11-01 9:49 UTC (permalink / raw)
To: linux-arm-kernel
For OMAP4, volt_data is set in omap44xx_voltagedomains_init.
If the SoC is neither OMAP443X or OMAP446X, we end up with a
NULL in volt_data which causes a kernel oops.
This is the case when booting OMAP4470.
Signed-off-by: Nicolae Rosia <Nicolae_Rosia@mentor.com>
---
arch/arm/mach-omap2/voltage.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index cba8cad..cd15dbd 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -87,6 +87,12 @@ int voltdm_scale(struct voltagedomain *voltdm,
return -ENODATA;
}
+ if (!voltdm->volt_data) {
+ pr_err("%s: No voltage data defined for vdd_%s\n",
+ __func__, voltdm->name);
+ return -ENODATA;
+ }
+
/* Adjust voltage to the exact voltage from the OPP table */
for (i = 0; voltdm->volt_data[i].volt_nominal != 0; i++) {
if (voltdm->volt_data[i].volt_nominal >= target_volt) {
--
2.5.5
^ permalink raw reply related
* [PATCH v8 1/3] ARM: dts: da850: Add cfgchip syscon node
From: Sekhar Nori @ 2016-11-01 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477946841-16126-2-git-send-email-david@lechnology.com>
Hi David,
On Tuesday 01 November 2016 02:17 AM, David Lechner wrote:
> Add a syscon node for the SoC CFGCHIPn registers. It includes a child node
> for the USB PHY that is part of this range of registers.
>
> Also have to add OF_DEV_AUXDATA() entry so that clock lookup will work for
> the the USB PHY driver.
>
> Signed-off-by: David Lechner <david@lechnology.com>
For future, please do not combine device-tree addition and other C code into a
single patch. I have applied this patch while splitting it into two as
attached.
Thanks,
Sekhar
---8<---
From: David Lechner <david@lechnology.com>
Date: Mon, 31 Oct 2016 15:47:19 -0500
Subject: [PATCH] ARM: dts: da850: Add cfgchip syscon node
Add a syscon node for the SoC CFGCHIPn registers. It includes a child node
for the USB PHY that is part of this range of registers.
Signed-off-by: David Lechner <david@lechnology.com>
[nsekhar at ti.com: drop OF_DEV_AUXDATA() addition]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4c836133a183..2534aab851e1 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -209,6 +209,16 @@
};
};
+ cfgchip: chip-controller at 1417c {
+ compatible = "ti,da830-cfgchip", "syscon", "simple-mfd";
+ reg = <0x1417c 0x14>;
+
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+ };
edma0: edma at 0 {
compatible = "ti,edma3-tpcc";
/* eDMA3 CC0: 0x01c0 0000 - 0x01c0 7fff */
--
2.9.0
---8<---
From: David Lechner <david@lechnology.com>
Date: Mon, 31 Oct 2016 15:47:19 -0500
Subject: [PATCH] ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for USB phy
Add OF_DEV_AUXDATA() entry for USB phy. This is required for
so that clock lookup will work for the USB PHY driver.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
arch/arm/mach-davinci/da8xx-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 0e45cbd57273..5e67618180a7 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -41,6 +41,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
+ OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
{}
};
--
2.9.0
^ permalink raw reply related
* [PATCH v8 2/3] ARM: davinci: da8xx: add usb phy clocks
From: Sekhar Nori @ 2016-11-01 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477946841-16126-3-git-send-email-david@lechnology.com>
On Tuesday 01 November 2016 02:17 AM, David Lechner wrote:
> Up to this point, the USB phy clock configuration was handled manually in
> the board files and in the usb drivers. This adds proper clocks so that
> the usb drivers can use clk_get and clk_enable and not have to worry about
> the details. Also, the related code is removed from the board files and
> replaced with the new clock registration functions.
>
> This also removes the #if IS_ENABLED(CONFIG_USB_MUSB_HDRC) around the musb
> declaration and renames the musb platform device so that we can reference
> it from the usb20 clock even if the musb device is not used.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
Applied to v4.10/soc
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v8 3/3] ARM: davinci: da8xx: register USB PHY clocks in the DT file
From: Sekhar Nori @ 2016-11-01 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477946841-16126-4-git-send-email-david@lechnology.com>
On Tuesday 01 November 2016 02:17 AM, David Lechner wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> The usb20_phy clock needs to be registered for the driver to be able
> to get and enable a clock. Currently the usb phy clocks are registered
> form board files, which will not be called during a device tree based
> boot.
>
> To be able to probe correctly usb form a device tree boot, register
> the usb phy clocks form the DT specific init.
>
> Unfourtunatly, davinci does not have proper clock support on device tree
> yet, so by registering the clock form de DT specific file we are
> forced to hardcode the parent clock, and cannot select refclkin as
> parent for any of the phy clocks of the da850 family.
>
> As none of the current da850 based boards currently in mainline use
> refclkin as source. I guess we can live with this limitation until clocks
> are correctly represented through CCF/device tree.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> [Added error checking]
> Signed-off-by: David Lechner <david@lechnology.com>
Applied to v4.10/soc with some typo fixes.
s/form/from
s/Unfourtunatly/Unfortunately
s/de/the
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Sekhar Nori @ 2016-11-01 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-2-git-send-email-bgolaszewski@baylibre.com>
On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver
From: Sekhar Nori @ 2016-11-01 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-3-git-send-email-bgolaszewski@baylibre.com>
On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 5/5] ARM: dts: da850-lcdk: add tilcdc panel node
From: Sekhar Nori @ 2016-11-01 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-6-git-send-email-bgolaszewski@baylibre.com>
On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
> The tilcdc driver is not yet ready for working together with the
> dumb-vga-dac drm bridge. While the work on enabling drm_bridge
> support in tilcdc continues, enable the VGA connector on da850-lcdk
> with the following workaround: use the tilcdc-panel driver with
> a set of common (and tested) resolutions.
>
> Once the drm bridge support is complete, we'll remove the node added
> by this patch and use the correct solution. This change will be
> transparent for the user.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
I dont think this can be applied. If this goes in v4.10, then the DT
blob becomes an ABI and driver will have to support tilcdc-panel driver
for DA850 forever.
Its probably better to wait for the proper driver support to arrive.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/3] ARM: imx: mach-imx6ul: add imx6ull support
From: Fabio Estevam @ 2016-11-01 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477969343-19887-3-git-send-email-peter.chen@nxp.com>
On Tue, Nov 1, 2016 at 1:02 AM, Peter Chen <peter.chen@nxp.com> wrote:
> imx6ull is derived SoC from imx6ul.
>
> Signed-off-by: Peter Chen <peter.chen@nxp.com>
> ---
> arch/arm/mach-imx/mach-imx6ul.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/mach-imx6ul.c b/arch/arm/mach-imx/mach-imx6ul.c
> index 58a2b88..0b24630 100644
> --- a/arch/arm/mach-imx/mach-imx6ul.c
> +++ b/arch/arm/mach-imx/mach-imx6ul.c
> @@ -89,10 +89,11 @@ static void __init imx6ul_init_late(void)
>
> static const char * const imx6ul_dt_compat[] __initconst = {
> "fsl,imx6ul",
> + "fsl,imx6ull",
> NULL,
> };
>
> -DT_MACHINE_START(IMX6UL, "Freescale i.MX6 Ultralite (Device Tree)")
> +DT_MACHINE_START(IMX6UL, "Freescale i.MX6 UltraLite (Device Tree)")
Is this change really needed?
^ permalink raw reply
* [PATCH] ARM: davinci: da850: Fix pwm name matching
From: Sekhar Nori @ 2016-11-01 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3fd93d1b-8ba2-5440-e37d-0c55928e7e51@lechnology.com>
On Monday 31 October 2016 08:18 PM, David Lechner wrote:
> On 10/31/2016 05:18 AM, Sekhar Nori wrote:
>> On Tuesday 25 October 2016 11:24 PM, David Lechner wrote:
>>> This fixes pwm name matching for DA850 familiy devices. When using
>>> device
>>> tree, the da850_auxdata_lookup[] table caused pwm devices to have the
>>> exact
>>> same name, which caused errors when trying to register the devices.
>>>
>>> The names for clock matching in da850_clks[] also have to be updated to
>>> to exactly match in order for the clock lookup to work correctly.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>> ---
>>>
>>> Tested working on LEGO MINDSTORMS EV3.
>>>
>>>
>>> arch/arm/mach-davinci/da850.c | 10 +++++++---
>>> arch/arm/mach-davinci/da8xx-dt.c | 10 +++++-----
>>> 2 files changed, 12 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-davinci/da850.c
>>> b/arch/arm/mach-davinci/da850.c
>>> index ed3d0e9..6b78a8f 100644
>>> --- a/arch/arm/mach-davinci/da850.c
>>> +++ b/arch/arm/mach-davinci/da850.c
>>> @@ -510,9 +510,13 @@ static struct clk_lookup da850_clks[] = {
>>> CLK("vpif", NULL, &vpif_clk),
>>> CLK("ahci_da850", NULL, &sata_clk),
>>> CLK("davinci-rproc.0", NULL, &dsp_clk),
>>> - CLK("ehrpwm", "fck", &ehrpwm_clk),
>>> - CLK("ehrpwm", "tbclk", &ehrpwm_tbclk),
>>> - CLK("ecap", "fck", &ecap_clk),
>>> + CLK("ehrpwm.0", "fck", &ehrpwm_clk),
>>> + CLK("ehrpwm.0", "tbclk", &ehrpwm_tbclk),
>>> + CLK("ehrpwm.1", "fck", &ehrpwm_clk),
>>> + CLK("ehrpwm.1", "tbclk", &ehrpwm_tbclk),
>>> + CLK("ecap.0", "fck", &ecap_clk),
>>> + CLK("ecap.1", "fck", &ecap_clk),
>>> + CLK("ecap.2", "fck", &ecap_clk),
>>
>> This has exposed a limitation of DaVinci clock framework. The struct clk
>> are stored as a linked list themselves. So a node repeating in the table
>> above will create a loop in the linked list. This is easily seen on the
>> LCDK board. davinci_clk_disable_unused() never returns. PWMs are unused
>> on that board.
>>
>> There is no "simple" solution to this AFAICS. One solution is to
>> separate the iterator from the clock hardware structure and use struct
>> clk_hw available in struct clk_lookup.
>>
>> Or move DaVinci to common clock framework. This is of course preferred
>> but much more involved as all 6 supported SoCs have to be moved together.
>>
>> Thanks,
>> Sekhar
>>
>>
>
> The simple solution for now could be to make child clocks for each of
> these that simply enable the parent clock. e.g. ehrpwm0_clk and
> ehpwm1_clk are children of ehrpwm_clk, etc.
That sounds good. I saw the v2 patch you sent and it looks good. I
noticed that aemif clock is repeated in da850.c too. That needs fixing.
> Looking at da830.c, it looks like the solution was to make multiple
> clocks that use the same LPSC, but this does not seem right to me.
The PWM clock definitions there are definitely wrong. It should be
fixed. Looks like its been like that forever.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 5/5] ARM: dts: da850-lcdk: add tilcdc panel node
From: Tomi Valkeinen @ 2016-11-01 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3e8671aa-e59d-4595-c323-af9e6a0ad615@ti.com>
On 01/11/16 12:26, Sekhar Nori wrote:
> On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
>> The tilcdc driver is not yet ready for working together with the
>> dumb-vga-dac drm bridge. While the work on enabling drm_bridge
>> support in tilcdc continues, enable the VGA connector on da850-lcdk
>> with the following workaround: use the tilcdc-panel driver with
>> a set of common (and tested) resolutions.
>>
>> Once the drm bridge support is complete, we'll remove the node added
>> by this patch and use the correct solution. This change will be
>> transparent for the user.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> I dont think this can be applied. If this goes in v4.10, then the DT
> blob becomes an ABI and driver will have to support tilcdc-panel driver
> for DA850 forever.
>
> Its probably better to wait for the proper driver support to arrive.
Agreed, NAK for this.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161101/c00353af/attachment.sig>
^ 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