* [PATCH 1/2] [media] v4l2: Add settings for Horizontal and Vertical MV Search Range
From: Amit Grover @ 2014-02-04 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391507999-31437-1-git-send-email-amit.grover@samsung.com>
Adding V4L2 controls for horizontal and vertical search range in pixels
for motion estimation module in video encoder.
Signed-off-by: Swami Nathan <swaminath.p@samsung.com>
Signed-off-by: Amit Grover <amit.grover@samsung.com>
---
Documentation/DocBook/media/v4l/controls.xml | 20 ++++++++++++++++++++
drivers/media/v4l2-core/v4l2-ctrls.c | 6 ++++++
include/uapi/linux/v4l2-controls.h | 2 ++
3 files changed, 28 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index a5a3188..0e1770c 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2258,6 +2258,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
VBV buffer control.</entry>
</row>
+ <row><entry></entry></row>
+ <row id=""v4l2-mpeg-video-hor-search-range">
+ <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant> </entry>
+ <entry>integer</entry>
+ </row>
+ <row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
+horizontal search range for motion estimation module in video encoder.</entry>
+ </row>
+
+ <row><entry></entry></row>
+ <row id="v4l2-mpeg-video-vert-search-range">
+ <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant> </entry>
+ <entry>integer</entry>
+ </row>
+ <row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
+vertical search range for motion estimation module in video encoder.</entry>
+ </row>
+
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry>
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index 6ff002b..e9e12c4 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -735,6 +735,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_DEC_PTS: return "Video Decoder PTS";
case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Video Decoder Frame Count";
case V4L2_CID_MPEG_VIDEO_VBV_DELAY: return "Initial Delay for VBV Control";
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE: return "Horizontal MV Search Range";
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return "Vertical MV Search Range";
case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat Sequence Header";
/* VPX controls */
@@ -910,6 +912,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
*min = 0;
*max = *step = 1;
break;
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
+ *type = V4L2_CTRL_TYPE_INTEGER;
+ break;
case V4L2_CID_PAN_RESET:
case V4L2_CID_TILT_RESET:
case V4L2_CID_FLASH_STROBE:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 2cbe605..cda6fa0 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -376,6 +376,8 @@ enum v4l2_mpeg_video_multi_slice_mode {
#define V4L2_CID_MPEG_VIDEO_DEC_FRAME (V4L2_CID_MPEG_BASE+224)
#define V4L2_CID_MPEG_VIDEO_VBV_DELAY (V4L2_CID_MPEG_BASE+225)
#define V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER (V4L2_CID_MPEG_BASE+226)
+#define V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE (V4L2_CID_MPEG_BASE+227)
+#define V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE (V4L2_CID_MPEG_BASE+228)
#define V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP (V4L2_CID_MPEG_BASE+300)
#define V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP (V4L2_CID_MPEG_BASE+301)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 0/2] drivers/media: Add controls for Horizontal and Vertical MV Search Range
From: Amit Grover @ 2014-02-04 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0ED10.2020901@samsung.com>
This is v3 version for the patch:
s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks
(https://lkml.org/lkml/2013/12/30/83)
Changes from v1:
1) Splitted the patch into V4L2 and MFC driver patches.
2) Incorporated review comments on v1.
Changes from v2:
1) Removed the range restrictions from drivers/media/v4l2-core/v4l2-ctrls.c.
2) Rebased the patch to git://linuxtv.org/mchehab/media-next.git.
3) Added [media] tag in title.
Amit Grover (2):
[media] v4l2: Add settings for Horizontal and Vertical MV Search
Range
[media] s5p-mfc: Add Horizontal and Vertical MV Search Range
Documentation/DocBook/media/v4l/controls.xml | 20 +++++++++++++++++++
drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 1 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24 +++++++++++++++++++++++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 8 ++------
drivers/media/v4l2-core/v4l2-ctrls.c | 6 ++++++
include/uapi/linux/v4l2-controls.h | 2 ++
7 files changed, 57 insertions(+), 6 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v3 4/4] ARM/ARM64: KVM: Allow KVM_ARM_VCPU_PSCI_0_2 feature for user space
From: Anup Patel @ 2014-02-04 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391507296-2099-1-git-send-email-anup.patel@linaro.org>
Allow user space to set KVM_ARM_VCPU_PSCI_0_2 feature because all
mandatory PSCI v0.2 functions (i.e. complete PSCI v0.2) are available.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
arch/arm/kvm/guest.c | 3 ---
arch/arm64/kvm/guest.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 89929b6..b23a59c 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -307,9 +307,6 @@ int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
if (test_bit(i, (void *)init->features)) {
if (i >= KVM_VCPU_MAX_FEATURES)
return -ENOENT;
- /* Don't allow setting experimental features */
- if (i == KVM_ARM_VCPU_PSCI_0_2)
- return -ENOENT;
set_bit(i, vcpu->arch.features);
}
}
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index b27877c..0874557 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -246,9 +246,6 @@ int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
if (init->features[i / 32] & (1 << (i % 32))) {
if (i >= KVM_VCPU_MAX_FEATURES)
return -ENOENT;
- /* Don't allow setting experimental features */
- if (i == KVM_ARM_VCPU_PSCI_0_2)
- return -ENOENT;
set_bit(i, vcpu->arch.features);
}
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 3/4] KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature
From: Anup Patel @ 2014-02-04 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391507296-2099-1-git-send-email-anup.patel@linaro.org>
We have in-kernel emulation of PSCI v0.2 in KVM ARM/ARM64. To provide
PSCI v0.2 interface to VCPUs, we have to enable KVM_ARM_VCPU_PSCI_0_2
feature when doing KVM_ARM_VCPU_INIT ioctl.
The patch updates documentation of KVM_ARM_VCPU_INIT ioctl to provide
info regarding KVM_ARM_VCPU_PSCI_0_2 feature.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
Documentation/virtual/kvm/api.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 6cd63a9..73cb211 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2347,6 +2347,8 @@ Possible features:
Depends on KVM_CAP_ARM_PSCI.
- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
+ - KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
+ Depends on KVM_CAP_ARM_PSCI_0_2.
4.83 KVM_ARM_PREFERRED_TARGET
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 2/4] KVM: Add capability to advertise PSCI v0.2 support
From: Anup Patel @ 2014-02-04 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391507296-2099-1-git-send-email-anup.patel@linaro.org>
User space (i.e. QEMU or KVMTOOL) should be able to check whether KVM
ARM/ARM64 supports in-kernel PSCI v0.2 emulation. For this purpose, we
define KVM_CAP_ARM_PSCI_0_2 in KVM user space interface header.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
arch/arm/kvm/arm.c | 1 +
include/uapi/linux/kvm.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 1d8248e..c8a71df 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -197,6 +197,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
case KVM_CAP_ONE_REG:
case KVM_CAP_ARM_PSCI:
+ case KVM_CAP_ARM_PSCI_0_2:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 932d7f2..fb3c3f3 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -675,6 +675,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_SPAPR_MULTITCE 94
#define KVM_CAP_EXT_EMUL_CPUID 95
#define KVM_CAP_HYPERV_TIME 96
+#define KVM_CAP_ARM_PSCI_0_2 97
#ifdef KVM_CAP_IRQ_ROUTING
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 1/4] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Anup Patel @ 2014-02-04 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391507296-2099-1-git-send-email-anup.patel@linaro.org>
Currently, the in-kernel PSCI emulation provides PSCI v0.1 interface to
VCPUs. This patch extends current in-kernel PSCI emulation to provide
PSCI v0.2 interface to VCPUs.
By default, ARM/ARM64 KVM will always provide PSCI v0.1 interface for
keeping the ABI backward-compatible.
To select PSCI v0.2 interface for VCPUs, the user space (i.e. QEMU or
KVMTOOL) will have to set KVM_ARM_VCPU_PSCI_0_2 feature when doing VCPU
init using KVM_ARM_VCPU_INIT ioctl.
Please note that we do not provide all mandatory functions required
by PSCI v0.2 which makes this implemenation as a base for extension
by subsequent patches. This also means KVM_ARM_VCPU_PSCI_0_2 feature
is experimental and will not be available to user space untill all
PSCI v0.2 mandatory functions are provided by KVM ARM/ARM64.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm/include/asm/kvm_psci.h | 4 ++
arch/arm/include/uapi/asm/kvm.h | 35 ++++++++++++++-
arch/arm/kvm/guest.c | 3 ++
arch/arm/kvm/psci.c | 85 +++++++++++++++++++++++++++++++------
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/kvm_psci.h | 4 ++
arch/arm64/include/uapi/asm/kvm.h | 35 ++++++++++++++-
arch/arm64/kvm/guest.c | 3 ++
9 files changed, 157 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 09af149..193ceaf 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -36,7 +36,7 @@
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
#define KVM_HAVE_ONE_REG
-#define KVM_VCPU_MAX_FEATURES 1
+#define KVM_VCPU_MAX_FEATURES 2
#include <kvm/arm_vgic.h>
diff --git a/arch/arm/include/asm/kvm_psci.h b/arch/arm/include/asm/kvm_psci.h
index 9a83d98..4c0e3e1 100644
--- a/arch/arm/include/asm/kvm_psci.h
+++ b/arch/arm/include/asm/kvm_psci.h
@@ -18,6 +18,10 @@
#ifndef __ARM_KVM_PSCI_H__
#define __ARM_KVM_PSCI_H__
+#define KVM_ARM_PSCI_0_1 1
+#define KVM_ARM_PSCI_0_2 2
+
+int kvm_psci_version(struct kvm_vcpu *vcpu);
bool kvm_psci_call(struct kvm_vcpu *vcpu);
#endif /* __ARM_KVM_PSCI_H__ */
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index ef0c878..9c922d9 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -83,6 +83,7 @@ struct kvm_regs {
#define KVM_VGIC_V2_CPU_SIZE 0x2000
#define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
+#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
struct kvm_vcpu_init {
__u32 target;
@@ -192,7 +193,7 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX 127
-/* PSCI interface */
+/* PSCI v0.1 interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
@@ -201,9 +202,41 @@ struct kvm_arch_memory_slot {
#define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
#define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
+/* PSCI v0.2 interface */
+#define KVM_PSCI_0_2_FN_BASE 0x84000000
+#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
+#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
+#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
+
+#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
+#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
+#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
+#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
+#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
+#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
+ KVM_PSCI_0_2_FN(6)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN(7)
+#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
+#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
+
+#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
+#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
+#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
+#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
+#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN64(7)
+
+/* PSCI return values */
#define KVM_PSCI_RET_SUCCESS 0
#define KVM_PSCI_RET_NI ((unsigned long)-1)
#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
#define KVM_PSCI_RET_DENIED ((unsigned long)-3)
+#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
+#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
+#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
+#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
+#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
#endif /* __ARM_KVM_H__ */
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index b23a59c..89929b6 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -307,6 +307,9 @@ int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
if (test_bit(i, (void *)init->features)) {
if (i >= KVM_VCPU_MAX_FEATURES)
return -ENOENT;
+ /* Don't allow setting experimental features */
+ if (i == KVM_ARM_VCPU_PSCI_0_2)
+ return -ENOENT;
set_bit(i, vcpu->arch.features);
}
}
diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
index 448f60e..e4ec4af 100644
--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -85,17 +85,57 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
return KVM_PSCI_RET_SUCCESS;
}
-/**
- * kvm_psci_call - handle PSCI call if r0 value is in range
- * @vcpu: Pointer to the VCPU struct
- *
- * Handle PSCI calls from guests through traps from HVC instructions.
- * The calling convention is similar to SMC calls to the secure world where
- * the function number is placed in r0 and this function returns true if the
- * function number specified in r0 is withing the PSCI range, and false
- * otherwise.
- */
-bool kvm_psci_call(struct kvm_vcpu *vcpu)
+int kvm_psci_version(struct kvm_vcpu *vcpu)
+{
+ if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
+ return KVM_ARM_PSCI_0_2;
+
+ return KVM_ARM_PSCI_0_1;
+}
+
+static bool kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
+{
+ unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
+ unsigned long val;
+
+ switch (psci_fn) {
+ case KVM_PSCI_0_2_FN_PSCI_VERSION:
+ /*
+ * Bits[31:16] = Major Version = 0
+ * Bits[15:0] = Minor Version = 2
+ */
+ val = 2;
+ break;
+ case KVM_PSCI_0_2_FN_CPU_OFF:
+ kvm_psci_vcpu_off(vcpu);
+ val = KVM_PSCI_RET_SUCCESS;
+ break;
+ case KVM_PSCI_0_2_FN_CPU_ON:
+ case KVM_PSCI_0_2_FN64_CPU_ON:
+ val = kvm_psci_vcpu_on(vcpu);
+ break;
+ case KVM_PSCI_0_2_FN_CPU_SUSPEND:
+ case KVM_PSCI_0_2_FN_AFFINITY_INFO:
+ case KVM_PSCI_0_2_FN_MIGRATE:
+ case KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
+ case KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
+ case KVM_PSCI_0_2_FN_SYSTEM_OFF:
+ case KVM_PSCI_0_2_FN_SYSTEM_RESET:
+ case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
+ case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
+ case KVM_PSCI_0_2_FN64_MIGRATE:
+ case KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
+ val = KVM_PSCI_RET_NI;
+ break;
+ default:
+ return false;
+ }
+
+ *vcpu_reg(vcpu, 0) = val;
+ return true;
+}
+
+static bool kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
{
unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
@@ -112,7 +152,6 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
case KVM_PSCI_FN_MIGRATE:
val = KVM_PSCI_RET_NI;
break;
-
default:
return false;
}
@@ -120,3 +159,25 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
*vcpu_reg(vcpu, 0) = val;
return true;
}
+
+/**
+ * kvm_psci_call - handle PSCI call if r0 value is in range
+ * @vcpu: Pointer to the VCPU struct
+ *
+ * Handle PSCI calls from guests through traps from HVC instructions.
+ * The calling convention is similar to SMC calls to the secure world where
+ * the function number is placed in r0 and this function returns true if the
+ * function number specified in r0 is withing the PSCI range, and false
+ * otherwise.
+ */
+bool kvm_psci_call(struct kvm_vcpu *vcpu)
+{
+ switch (kvm_psci_version(vcpu)) {
+ case KVM_ARM_PSCI_0_2:
+ return kvm_psci_0_2_call(vcpu);
+ case KVM_ARM_PSCI_0_1:
+ return kvm_psci_0_1_call(vcpu);
+ default:
+ return false;
+ };
+}
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 0a1d697..92242ce 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -39,7 +39,7 @@
#include <kvm/arm_vgic.h>
#include <kvm/arm_arch_timer.h>
-#define KVM_VCPU_MAX_FEATURES 2
+#define KVM_VCPU_MAX_FEATURES 3
struct kvm_vcpu;
int kvm_target_cpu(void);
diff --git a/arch/arm64/include/asm/kvm_psci.h b/arch/arm64/include/asm/kvm_psci.h
index e301a48..e25c658 100644
--- a/arch/arm64/include/asm/kvm_psci.h
+++ b/arch/arm64/include/asm/kvm_psci.h
@@ -18,6 +18,10 @@
#ifndef __ARM64_KVM_PSCI_H__
#define __ARM64_KVM_PSCI_H__
+#define KVM_ARM_PSCI_0_1 1
+#define KVM_ARM_PSCI_0_2 2
+
+int kvm_psci_version(struct kvm_vcpu *vcpu);
bool kvm_psci_call(struct kvm_vcpu *vcpu);
#endif /* __ARM64_KVM_PSCI_H__ */
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 495ab6f..31c2f54 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -77,6 +77,7 @@ struct kvm_regs {
#define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
#define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
+#define KVM_ARM_VCPU_PSCI_0_2 2 /* CPU uses PSCI v0.2 */
struct kvm_vcpu_init {
__u32 target;
@@ -168,7 +169,7 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX 127
-/* PSCI interface */
+/* PSCI v0.1 interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
@@ -177,10 +178,42 @@ struct kvm_arch_memory_slot {
#define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
#define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
+/* PSCI v0.2 interface */
+#define KVM_PSCI_0_2_FN_BASE 0x84000000
+#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
+#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
+#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
+
+#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
+#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
+#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
+#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
+#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
+#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
+ KVM_PSCI_0_2_FN(6)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN(7)
+#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
+#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
+
+#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
+#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
+#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
+#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
+#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN64(7)
+
+/* PSCI return values */
#define KVM_PSCI_RET_SUCCESS 0
#define KVM_PSCI_RET_NI ((unsigned long)-1)
#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
#define KVM_PSCI_RET_DENIED ((unsigned long)-3)
+#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
+#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
+#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
+#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
+#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
#endif
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 0874557..b27877c 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -246,6 +246,9 @@ int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
if (init->features[i / 32] & (1 << (i % 32))) {
if (i >= KVM_VCPU_MAX_FEATURES)
return -ENOENT;
+ /* Don't allow setting experimental features */
+ if (i == KVM_ARM_VCPU_PSCI_0_2)
+ return -ENOENT;
set_bit(i, vcpu->arch.features);
}
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 0/4] In-kernel PSCI v0.2 emulation for KVM ARM/ARM64
From: Anup Patel @ 2014-02-04 9:48 UTC (permalink / raw)
To: linux-arm-kernel
Currently, KVM ARM/ARM64 only provides in-kernel emulation of Power State
and Coordination Interface (PSCI) v0.1.
This patchset aims at providing newer PSCI v0.2 for KVM ARM/ARM64 VCPUs
such that it does not break current KVM ARM/ARM64 ABI. Also, the patchset
provides emulation of only few PSCI v0.2 functions such as PSCI_VERSION,
CPU_ON, and CPU_OFF. Emulation of other PSCI v0.2 functions will be added
later.
The user space tools (i.e. QEMU or KVMTOOL) will have to explicitly enable
KVM_ARM_VCPU_PSCI_0_2 feature using KVM_ARM_VCPU_INIT ioctl for providing
PSCI v0.2 to VCPUs.
Changlog:
V3:
- Make KVM_ARM_VCPU_PSCI_0_2 feature experiementatl for now so that
it fails for user space till all mandatory PSCI v0.2 functions are
emulated by KVM ARM/ARM64
- Have separate patch for making KVM_ARM_VCPU_PSCI_0_2 feature available
to user space. This patch can be defferred for now.
V2:
- Don't rename PSCI return values KVM_PSCI_RET_NI and KVM_PSCI_RET_INVAL
- Added kvm_psci_version() to get PSCI version available to VCPU
- Fixed grammer in Documentation/virtual/kvm/api.txt
V1:
- Initial RFC PATCH
Anup Patel (4):
ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
KVM: Add capability to advertise PSCI v0.2 support
KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature
ARM/ARM64: KVM: Allow KVM_ARM_VCPU_PSCI_0_2 feature for user space
Documentation/virtual/kvm/api.txt | 2 +
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm/include/asm/kvm_psci.h | 4 ++
arch/arm/include/uapi/asm/kvm.h | 35 ++++++++++++++-
arch/arm/kvm/arm.c | 1 +
arch/arm/kvm/psci.c | 85 +++++++++++++++++++++++++++++++------
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/kvm_psci.h | 4 ++
arch/arm64/include/uapi/asm/kvm.h | 35 ++++++++++++++-
include/uapi/linux/kvm.h | 1 +
10 files changed, 155 insertions(+), 16 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH] ARM64: KVM: Fix VGIC compile error for Linux-3.14-rc1
From: Anup Patel @ 2014-02-04 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F0B5BB.3060901@arm.com>
On 4 February 2014 15:11, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 04/02/14 09:37, Anup Patel wrote:
>> This patch fixes VGIC compilation for Linux-3.14-rc1 ARM64 kernel.
>>
>> Signed-off-by: Anup Patel <anup.patel@linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
>
> Already posted by Christoffer, and hopefully on its way to mainline.
Thanks,
Anup
>
> M.
>
>> ---
>> arch/arm64/include/uapi/asm/kvm.h | 9 +++++++++
>> virt/kvm/arm/vgic.c | 1 +
>> 2 files changed, 10 insertions(+)
>>
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 31c2f54..cadc318 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -149,6 +149,15 @@ struct kvm_arch_memory_slot {
>> #define KVM_REG_ARM_TIMER_CNT ARM64_SYS_REG(3, 3, 14, 3, 2)
>> #define KVM_REG_ARM_TIMER_CVAL ARM64_SYS_REG(3, 3, 14, 0, 2)
>>
>> +/* Device Control API: ARM VGIC */
>> +#define KVM_DEV_ARM_VGIC_GRP_ADDR 0
>> +#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1
>> +#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS 2
>> +#define KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
>> +#define KVM_DEV_ARM_VGIC_CPUID_MASK (0xffULL << KVM_DEV_ARM_VGIC_CPUID_SHIFT)
>> +#define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
>> +#define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> +
>> /* KVM_IRQ_LINE irq field index values */
>> #define KVM_ARM_IRQ_TYPE_SHIFT 24
>> #define KVM_ARM_IRQ_TYPE_MASK 0xff
>> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
>> index be456ce..55b0609 100644
>> --- a/virt/kvm/arm/vgic.c
>> +++ b/virt/kvm/arm/vgic.c
>> @@ -21,6 +21,7 @@
>> #include <linux/kvm_host.h>
>> #include <linux/interrupt.h>
>> #include <linux/io.h>
>> +#include <linux/uaccess.h>
>> #include <linux/of.h>
>> #include <linux/of_address.h>
>> #include <linux/of_irq.h>
>>
>
>
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-04 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203233137.GH2519@obsidianresearch.com>
On Monday 03 February 2014 16:31:37 Jason Gunthorpe wrote:
> Specifying 'use EHCI, AHCI, etc' - which are all PCI based standards
> without clearly specifying exactly how PCI is suppose to work is
> completely bonkers.
>
> What is needed is a spec that says:
> 1) Here is how you generate config TLPs. A MMIO region that
> conforms to the already specified x86 ECAM would
> be perfect
> 2) Here is a dword by dword break down of the entire config space in
> a SOC. Here is where a on-board AHCI controller must show up in
> config space. Here is how an external PCI-E port must show
> up. Etc. Most of this is already specified, but it clearly needs
> to be layed out explicitly for ARM SOCs to actually follow it.
> 3) Here is how you specify the aperture(s) associated with PCI BAR's
> and bridge windows in config space. And yes: The CONFIG SPACE
> BARS MUST WORK.
> 4) Here is how MSI works, these are the values you put in the
> address/data and here is how you collect the interrupt.
> 5) Here is how Legacy INTx must be mapped into the GIC.
>
> This is what x86 does, and they have been doing it well for 10
> years. If you want to play in the server game you have to properly
> implement PCI.
I'm pretty sure the authors of the SBSA actually thought that was
what they wrote, by referring to external specifications (pci-3.0,
ehci, ahci, ...). However, it seems they were either foolish enough
to believe that hardware designers would follow these specs, or
they were intentionally misled and got talked into putting ambiguous
terminology in because there were already hardware designs that
are not exactly in line with the spirit of the SBSA but can be
argued to be conforming to the text for a lax interpretation.
I think EHCI is a much better example than PCI here, because the
spec has exactly one line to say about it, where it spends a whole
chapter on PCI.
Here is how a sane person would read SBSA to create a compliant
implementation:
I have to use EHCI version 1.1 to provide USB-2.0 support. EHCI
is a PCI device, so I'll put it behind a PCIe port that complies
to the PCIe section of the SBSA. Since EHCI by itself only provides
high-speed USB, and USB-2.0 mandates I provide low-speed and
full-speed as well, I have to add a USB hub device. It would have
been easier to just use OHCI for these, but SBSA says I can't.
Now I want to integrate the EHCI into my SoC and not waste one
of my precious PCIe root ports, so I have to create another PCI
domain with its own ECAM compliant config space to put it into.
Fortunately SBSA lets me add an arbitrary number of PCI domains,
as long as they are all strictly compliant. To software it will
look exactly as if it was on an external card, I just have to
ensure the boot loader correctly sets up the clocks and the phy
before an SBSA compliant OS gets loaded, all runtime power
management will get handled through the EHCI-1.1 energy-efficiency
extensions.
Here is how a crazy person would read the same sentence in the SBSA:
I have an IP block that implements the EHCI register set, that
should be good enough. It's not a fast device, so I can put it
on a non-coherent bus. Since the SoC will be used for networking,
I'll put the registers into big-endian configuration to make it
easier for the OS to access. I'm not allowed to have USB-1.1
according to SBSA, so I can get away without a hub or an extra
OHCI. I can't support MSI because it's not a PCI device, and
the GIC is pretty full, so I'll just connect the IRQ line to
the GPIO controller. In order to do better power management,
I'll design a fancy PHY that the device driver will manage
for implementing autosuspend. I should also give the OS
fine-grained control over the clocks, but it will have to share
the clock domain with the other devices on the same edge of the
chip. The EHCI device is not part of PCI, which measn I don't
have to use the standard SMMU. However, my EHCI implementation
can only do 32-bit DMA, and I'll have to design my own IOMMU
to let it access the entire memory range. USB-OTG is a great
feature and we already paid for having this in our EHCI
implementation, better make sure it comes up in endpoint mode
after waking up from power saving.
Arnd
^ permalink raw reply
* [PATCH v5 13/14] ARM: sun4i: dts: Add ahci / sata support
From: Maxime Ripard @ 2014-02-04 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EF70E2.6070803@redhat.com>
On Mon, Feb 03, 2014 at 11:35:14AM +0100, Hans de Goede wrote:
> Hi,
>
> On 01/31/2014 02:45 PM, Maxime Ripard wrote:
> >Hi Hans,
> >
> >On Wed, Jan 22, 2014 at 08:04:48PM +0100, Hans de Goede wrote:
> >>From: Oliver Schinagl <oliver@schinagl.nl>
> >>
> >>This patch adds sunxi sata support to A10 boards that have such a connector.
> >>Some boards also feature a regulator via a GPIO and support for this is also
> >>added.
> >>
> >>Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
> >>Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>---
> >> arch/arm/boot/dts/sun4i-a10-a1000.dts | 4 ++++
> >> arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 6 +++++
> >> arch/arm/boot/dts/sun4i-a10.dtsi | 8 +++++++
> >> arch/arm/boot/dts/sunxi-ahci-reg.dtsi | 38 ++++++++++++++++++++++++++++++
> >
> >I'm still half convinced about this at the moment, given the number of
> >platforms we support, we can always change it back if things become too messy.
>
> I assume that this == sunxi-ahci-reg.dtsi ? To be sure I understand
> you correctly, you're ok with going this route for now, right ?
Yep.
> How about the same for the usb ohci/ehci controller dts patches ? Currently they
> are still using the put a regulator node in each dts file model, which leads to
> a lot of boilerplate code. So I would like to move to the same model as I'm
> using here for the sata supply.
That would make sense too.
> >> 4 files changed, 56 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/sunxi-ahci-reg.dtsi
> >>
> >>diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> >>index aef8207..3fb7305 100644
> >>--- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
> >>+++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> >>@@ -48,6 +48,10 @@
> >> status = "okay";
> >> };
> >>
> >>+ ahci: sata at 01c18000 {
> >>+ status = "okay";
> >>+ };
> >>+
> >> pinctrl at 01c20800 {
> >> mmc0_cd_pin_a1000: mmc0_cd_pin at 0 {
> >> allwinner,pins = "PH1";
> >>diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> >>index f50fb2b..6ae1110 100644
> >>--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> >>+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> >>@@ -12,6 +12,7 @@
> >>
> >> /dts-v1/;
> >> /include/ "sun4i-a10.dtsi"
> >>+/include/ "sunxi-ahci-reg.dtsi"
> >>
> >> / {
> >> model = "Cubietech Cubieboard";
> >>@@ -51,6 +52,11 @@
> >> status = "okay";
> >> };
> >>
> >>+ ahci: sata at 01c18000 {
> >>+ target-supply = <®_ahci_5v>;
> >>+ status = "okay";
> >>+ };
> >>+
> >> pinctrl at 01c20800 {
> >> mmc0_cd_pin_cubieboard: mmc0_cd_pin at 0 {
> >> allwinner,pins = "PH1";
> >>diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
> >>index 4736dd2..198dcda 100644
> >>--- a/arch/arm/boot/dts/sun4i-a10.dtsi
> >>+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> >>@@ -331,6 +331,14 @@
> >> status = "disabled";
> >> };
> >>
> >>+ ahci: sata at 01c18000 {
> >>+ compatible = "allwinner,sun4i-a10-ahci";
> >
> >To be consistent with the rest of the sun4i devices compatible, It
> >should be sun4i-ahci.
> >
> >However, since these devices don't use the same compatible pattern as
> >their own machine compatible, and are consisent with the rest of the
> >compatibles for the other SoCs, we can probably make this a go to
> >transition progressively to this pattern.
>
> Ack, I think it would be good to be consistent and try to use
> sun?i-aXX-foo everywhere. I noticed that we already use that in various
> places, so I thought it would be good to do that for all new dts bindings.
Yes, that's my plan.
> >I'll cook up some patches for the other devices.
>
> Thanks.
And I sent them on sunday.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/a627150d/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/2] Documentation: devicetree: Add boost-opp binding to list boost mode OPPs
From: Thomas Abraham @ 2014-02-04 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391506890-7335-1-git-send-email-thomas.ab@samsung.com>
From: Thomas Abraham <thomas.ab@samsung.com>
Certain CPUs or devices can support optional boost operating modes. Add a new
binding to list OPPs to be additionally made available in boost operating modes.
Cc: Nishanth Menon <nm@ti.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
Documentation/devicetree/bindings/power/opp.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt
index 74499e5..4df5cca 100644
--- a/Documentation/devicetree/bindings/power/opp.txt
+++ b/Documentation/devicetree/bindings/power/opp.txt
@@ -10,6 +10,10 @@ Properties:
freq: clock frequency in kHz
vol: voltage in microvolt
+Optional Properties:
+- boost-opp: Similar to "operating-points" property but usable only in
+ optional boost operating modes.
+
Examples:
cpu at 0 {
@@ -22,4 +26,9 @@ cpu at 0 {
396000 950000
198000 850000
>;
+ boost-opp = <
+ /* kHz uV */
+ 1500000 1350000
+ 1400000 1285000
+ >;
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] PM / OPP: Add support for 'boost' mode OPP
From: Thomas Abraham @ 2014-02-04 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391506890-7335-1-git-send-email-thomas.ab@samsung.com>
From: Thomas Abraham <thomas.ab@samsung.com>
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode. This patch adds support for finding available
boost OPPs from device tree and marking them as usable in boost mode.
Cc: Nishanth Menon <nm@ti.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
---
drivers/base/power/opp.c | 69 +++++++++++++++++++++++++++++++++++++---------
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 2553867..de4d52d 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -62,6 +62,7 @@ struct dev_pm_opp {
struct list_head node;
bool available;
+ bool boost;
unsigned long rate;
unsigned long u_volt;
@@ -380,10 +381,12 @@ struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct device *dev,
EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
/**
- * dev_pm_opp_add() - Add an OPP table from a table definitions
+ * dev_pm_opp_add_flags() - Add an OPP to device OPP list with flags
* @dev: device for which we do this operation
* @freq: Frequency in Hz for this OPP
* @u_volt: Voltage in uVolts for this OPP
+ * @available: initial availability of the OPP with adding it to the list.
+ * @boost: availability of this opp in controller's boost operating mode.
*
* This function adds an opp definition to the opp list and returns status.
* The opp is made available by default and it can be controlled using
@@ -395,7 +398,8 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_find_freq_floor);
* that this function is *NOT* called under RCU protection or in contexts where
* mutex cannot be locked.
*/
-int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
+static int dev_pm_opp_add_flags(struct device *dev, unsigned long freq,
+ unsigned long u_volt, bool available, bool boost)
{
struct device_opp *dev_opp = NULL;
struct dev_pm_opp *opp, *new_opp;
@@ -441,7 +445,8 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
new_opp->dev_opp = dev_opp;
new_opp->rate = freq;
new_opp->u_volt = u_volt;
- new_opp->available = true;
+ new_opp->available = available;
+ new_opp->boost = boost;
/* Insert new OPP in order of increasing frequency */
head = &dev_opp->opp_list;
@@ -462,6 +467,27 @@ int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
srcu_notifier_call_chain(&dev_opp->head, OPP_EVENT_ADD, new_opp);
return 0;
}
+
+/**
+ * dev_pm_opp_add() - Add an OPP table from a table definitions
+ * @dev: device for which we do this operation
+ * @freq: Frequency in Hz for this OPP
+ * @u_volt: Voltage in uVolts for this OPP
+ *
+ * This function adds an opp definition to the opp list and returns status.
+ * The opp is made available by default and it can be controlled using
+ * dev_pm_opp_enable/disable functions.
+ *
+ * Locking: The internal device_opp and opp structures are RCU protected.
+ * Hence this function internally uses RCU updater strategy with mutex locks
+ * to keep the integrity of the internal data structures. Callers should ensure
+ * that this function is *NOT* called under RCU protection or in contexts where
+ * mutex cannot be locked.
+ */
+int dev_pm_opp_add(struct device *dev, unsigned long freq, unsigned long u_volt)
+{
+ return dev_pm_opp_add_flags(dev, freq, u_volt, true, false);
+}
EXPORT_SYMBOL_GPL(dev_pm_opp_add);
/**
@@ -651,7 +677,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
list_for_each_entry(opp, &dev_opp->opp_list, node) {
if (opp->available) {
- freq_table[i].driver_data = i;
+ freq_table[i].driver_data =
+ opp->boost ? CPUFREQ_BOOST_FREQ : i;
freq_table[i].frequency = opp->rate / 1000;
i++;
}
@@ -701,19 +728,14 @@ struct srcu_notifier_head *dev_pm_opp_get_notifier(struct device *dev)
}
#ifdef CONFIG_OF
-/**
- * of_init_opp_table() - Initialize opp table from device tree
- * @dev: device pointer used to lookup device OPPs.
- *
- * Register the initial OPP table with the OPP library for given device.
- */
-int of_init_opp_table(struct device *dev)
+static int of_parse_opp_table(struct device *dev, const char *prop_name,
+ bool boost)
{
const struct property *prop;
const __be32 *val;
int nr;
- prop = of_find_property(dev->of_node, "operating-points", NULL);
+ prop = of_find_property(dev->of_node, prop_name, NULL);
if (!prop)
return -ENODEV;
if (!prop->value)
@@ -734,7 +756,7 @@ int of_init_opp_table(struct device *dev)
unsigned long freq = be32_to_cpup(val++) * 1000;
unsigned long volt = be32_to_cpup(val++);
- if (dev_pm_opp_add(dev, freq, volt)) {
+ if (dev_pm_opp_add_flags(dev, freq, volt, true, boost)) {
dev_warn(dev, "%s: Failed to add OPP %ld\n",
__func__, freq);
continue;
@@ -744,5 +766,26 @@ int of_init_opp_table(struct device *dev)
return 0;
}
+
+/**
+ * of_init_opp_table() - Initialize opp table from device tree
+ * @dev: device pointer used to lookup device OPPs.
+ *
+ * Register the initial OPP table with the OPP library for given device.
+ * Additional "boost" operating points of the controller, if any, are
+ * specified with "boost-opp" property.
+ */
+int of_init_opp_table(struct device *dev)
+{
+ int ret;
+
+ ret = of_parse_opp_table(dev, "operating-points", false);
+ if (!ret) {
+ ret = of_parse_opp_table(dev, "boost-opp", true);
+ if (ret == -ENODEV)
+ ret = 0;
+ }
+ return ret;
+}
EXPORT_SYMBOL_GPL(of_init_opp_table);
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] Add device tree based lookup of boost mode OPPs
From: Thomas Abraham @ 2014-02-04 9:41 UTC (permalink / raw)
To: linux-arm-kernel
Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
support for CPU boost mode for CPUfreq drivers. To use the new boost
mode, CPUfreq drivers have to specify the boost mode frequency and
voltage within the CPUfreq driver, which is the case for Exynos4x12
CPUfreq driver.
But for CPUfreq drivers which obtain the OPPs from cpus node, this
patch series adds support to specify boost mode OPPs in dt node. This
requirement came up when Lukasz pointed out the regression caused by
the Exynos CPUfreq driver consolidation patches.
Thomas Abraham (2):
PM / OPP: Add support for 'boost' mode OPP
Documentation: devicetree: Add boost-opp binding to list boost mode OPPs
Documentation/devicetree/bindings/power/opp.txt | 9 +++
drivers/base/power/opp.c | 69 ++++++++++++++++++-----
2 files changed, 65 insertions(+), 13 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH] ARM64: KVM: Fix VGIC compile error for Linux-3.14-rc1
From: Marc Zyngier @ 2014-02-04 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391506640-1901-1-git-send-email-anup.patel@linaro.org>
On 04/02/14 09:37, Anup Patel wrote:
> This patch fixes VGIC compilation for Linux-3.14-rc1 ARM64 kernel.
>
> Signed-off-by: Anup Patel <anup.patel@linaro.org>
> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Already posted by Christoffer, and hopefully on its way to mainline.
M.
> ---
> arch/arm64/include/uapi/asm/kvm.h | 9 +++++++++
> virt/kvm/arm/vgic.c | 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 31c2f54..cadc318 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -149,6 +149,15 @@ struct kvm_arch_memory_slot {
> #define KVM_REG_ARM_TIMER_CNT ARM64_SYS_REG(3, 3, 14, 3, 2)
> #define KVM_REG_ARM_TIMER_CVAL ARM64_SYS_REG(3, 3, 14, 0, 2)
>
> +/* Device Control API: ARM VGIC */
> +#define KVM_DEV_ARM_VGIC_GRP_ADDR 0
> +#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1
> +#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS 2
> +#define KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
> +#define KVM_DEV_ARM_VGIC_CPUID_MASK (0xffULL << KVM_DEV_ARM_VGIC_CPUID_SHIFT)
> +#define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
> +#define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> +
> /* KVM_IRQ_LINE irq field index values */
> #define KVM_ARM_IRQ_TYPE_SHIFT 24
> #define KVM_ARM_IRQ_TYPE_MASK 0xff
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index be456ce..55b0609 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -21,6 +21,7 @@
> #include <linux/kvm_host.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> +#include <linux/uaccess.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/of_irq.h>
>
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
From: Maxime Ripard @ 2014-02-04 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E77FCD.5050701@redhat.com>
Hi Hans,
On Tue, Jan 28, 2014 at 11:00:45AM +0100, Hans de Goede wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> On 01/28/2014 10:44 AM, Maxime Ripard wrote:
> > On Mon, Jan 27, 2014 at 03:54:14PM +0100, Hans de Goede wrote:
> >>>> "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13
> >>>
> >>> Maybe we can just remove the gates from there? Even though they
> >>> are gates, they are also (a bit) more than that.
> >>
> >> To be clear you mean s/usb-gates-clk/usb-clk/ right ?
> >
> > Yep, exactly
> >
> >>> I guess that means that we will have the OHCI0 gate declared
> >>> with <&...-gates-clk 6>, while it's actually the first gate for
> >>> this clock?
> >>
> >> Correct.
> >>
> >>> Maybe introducing an offset field in the gates_data would be a
> >>> good idea, so that we always start from indexing the gates from
> >>> 0 in the DT?
> >>
> >> Well for the other "gates" type clks we also have holes in the
> >> range, and we always refer to the clk with the bit number in the
> >> reg as the clock-cell value.
> >
> > Yes, we have holes, but I see two majors differences here: - the
> > other gates are just gates, while the usb clocks are a bit more
> > than that.
>
> The usb-clk registers contain more then that, but the bits we are
> talking about now are gates.
>
> > - the other gates' gating bits thus all start at bit 0, while
> > - here, since it's kind of a "mixed" clock, the gating bits start
> > - at bit 6 (on the A20 at least)
>
> Right, still I believe that the consistent thing to do is keeping
> the bit-number for the bit in the register controlling the gate as
> the specifier. When adding new dts entries / reviewing existing
> ones I'm used to matching the specifier to the bit-nr in the
> data-sheet, I think making things different just for this one
> register is counter productive.
And if you turn it the other way around, it would be inconsistent that
all gates indices start at 0, and we would start at 6 here :)
Plus, this clock is already a special case, since it's the only gate
that is more than just a gate so far.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/a602e9cd/attachment.sig>
^ permalink raw reply
* [PATCH] security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64
From: Will Deacon @ 2014-02-04 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391480133-27149-1-git-send-email-ccross@android.com>
On Tue, Feb 04, 2014 at 02:15:32AM +0000, Colin Cross wrote:
> Binaries compiled for arm may run on arm64 if CONFIG_COMPAT is
> selected. Set LSM_MMAP_MIN_ADDR to 32768 if ARM64 && COMPAT to
> prevent selinux failures launching 32-bit static executables that
> are mapped at 0x8000.
>
> Signed-off-by: Colin Cross <ccross@android.com>
> ---
> security/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/Kconfig b/security/Kconfig
> index e9c6ac724fef..beb86b500adf 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -103,7 +103,7 @@ config INTEL_TXT
> config LSM_MMAP_MIN_ADDR
> int "Low address space for LSM to protect from user allocation"
> depends on SECURITY && SECURITY_SELINUX
> - default 32768 if ARM
> + default 32768 if ARM || (ARM64 && COMPAT)
> default 65536
> help
> This is the portion of low virtual memory which should be protected
Since ARM64 && COMPAT implies 4k pages, this change looks ok to me.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] ARM64: KVM: Fix VGIC compile error for Linux-3.14-rc1
From: Anup Patel @ 2014-02-04 9:37 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes VGIC compilation for Linux-3.14-rc1 ARM64 kernel.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
arch/arm64/include/uapi/asm/kvm.h | 9 +++++++++
virt/kvm/arm/vgic.c | 1 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 31c2f54..cadc318 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -149,6 +149,15 @@ struct kvm_arch_memory_slot {
#define KVM_REG_ARM_TIMER_CNT ARM64_SYS_REG(3, 3, 14, 3, 2)
#define KVM_REG_ARM_TIMER_CVAL ARM64_SYS_REG(3, 3, 14, 0, 2)
+/* Device Control API: ARM VGIC */
+#define KVM_DEV_ARM_VGIC_GRP_ADDR 0
+#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1
+#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS 2
+#define KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
+#define KVM_DEV_ARM_VGIC_CPUID_MASK (0xffULL << KVM_DEV_ARM_VGIC_CPUID_SHIFT)
+#define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
+#define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
+
/* KVM_IRQ_LINE irq field index values */
#define KVM_ARM_IRQ_TYPE_SHIFT 24
#define KVM_ARM_IRQ_TYPE_MASK 0xff
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index be456ce..55b0609 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -21,6 +21,7 @@
#include <linux/kvm_host.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/uaccess.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Maxime Ripard @ 2014-02-04 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64+qiBqYtWyc23b6p4aWyWj7a9K1qveTsW7ZGh0ti8_Wg@mail.gmail.com>
On Tue, Feb 04, 2014 at 10:43:33AM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Feb 4, 2014 at 3:31 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Mon, Feb 03, 2014 at 11:32:19AM +0800, Chen-Yu Tsai wrote:
> >> The Allwinner A20/A31 clock module controls the transmit clock source
> >> and interface type of the GMAC ethernet controller. Model this as
> >> a single clock for GMAC drivers to use.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> ---
> >> Documentation/devicetree/bindings/clock/sunxi.txt | 26 +++++++
> >> drivers/clk/sunxi/clk-sunxi.c | 83 +++++++++++++++++++++++
> >> 2 files changed, 109 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> >> index 0cf679b..f43b4c0 100644
> >> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> >> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> >> @@ -37,6 +37,7 @@ Required properties:
> >> "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> >> "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
> >> "allwinner,sun7i-a20-out-clk" - for the external output clocks
> >> + "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
> >>
> >> Required properties for all clocks:
> >> - reg : shall be the control register address for the clock.
> >> @@ -50,6 +51,9 @@ Required properties for all clocks:
> >> If the clock module only has one output, the name shall be the
> >> module name.
> >>
>
>
> >> +For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
> >> +dummy clocks at 25 MHz and 125 MHz, respectively. See example.
> >> +
>
>
> >> Clock consumers should specify the desired clocks they use with a
> >> "clocks" phandle cell. Consumers that are using a gated clock should
> >> provide an additional ID in their clock property. This ID is the
> >> @@ -96,3 +100,25 @@ mmc0_clk: clk at 01c20088 {
> >> clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> >> clock-output-names = "mmc0";
> >> };
> >> +
> >> +mii_phy_tx_clk: clk at 2 {
> >> + #clock-cells = <0>;
> >> + compatible = "fixed-clock";
> >> + clock-frequency = <25000000>;
> >> + clock-output-names = "mii_phy_tx";
> >> +};
> >> +
> >> +gmac_int_tx_clk: clk at 3 {
> >> + #clock-cells = <0>;
> >> + compatible = "fixed-clock";
> >> + clock-frequency = <125000000>;
> >> + clock-output-names = "gmac_int_tx";
> >> +};
> >> +
> >> +gmac_clk: clk at 01c20164 {
> >> + #clock-cells = <0>;
> >> + compatible = "allwinner,sun7i-a20-gmac-clk";
> >> + reg = <0x01c20164 0x4>;
> >> + clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
> >
> > You should also document in which order you expect the parents to
> > be. Or it will probably be easier to just use clock-names here.
>
> Is it not clear from the "Required properties" section above?
I'd make it clearer. But again, using clock-names would avoid any
ambiguity, and be more flexible.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/e48653e2/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/8] ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
From: Maxime Ripard @ 2014-02-04 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v660qoKDC6SKjoD29b-r5y9OwkeKoWZ9PWBF5tC5PgeEYQ@mail.gmail.com>
On Tue, Feb 04, 2014 at 11:06:24AM +0800, Chen-Yu Tsai wrote:
> On Tue, Feb 4, 2014 at 3:34 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Mon, Feb 03, 2014 at 11:32:20AM +0800, Chen-Yu Tsai wrote:
> >> The GMAC uses 1 of 2 sources for its transmit clock, depending on the
> >> PHY interface mode. Add both sources as dummy clocks, and as parents
> >> to the GMAC clock node.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> ---
> >> arch/arm/boot/dts/sun7i-a20.dtsi | 28 ++++++++++++++++++++++++++++
> >> 1 file changed, 28 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> >> index 1595e9a..fc7f470 100644
> >> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> >> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> >> @@ -314,6 +314,34 @@
> >> };
> >>
> >> /*
> >> + * The following two are dummy clocks, placeholders used
> >> + * on gmac_tx clock. The actual frequency and availability
> >> + * depends on the external PHY, operation mode and link
> >> + * speed.
> >> + */
> >
> > If it depends on the external PHY, I guess that means it also depends
> > on the board, right? Or is the GMAC supposed to always have that clock
> > running at 25MHz, no matter what PHY is connected to it?
>
> What I meant in the comment is that we cannot control the actual clock
> rate of the TX clock. We can only select the source, and this is what
> gmac_tx clock does. It is just a clock mux. The 125MHz and 25MHz clock
> rates are used by the clk_set_rate in the stmmac glue layer to do
> auto-reparenting.
>
> The board dependent factor is what _type_ of PHY it is using, i.e.
> MII, GMII, or RGMII. If it's MII, the PHY should provide the clock.
> If it's RGMII, the internal clock would be used. GMII is a mix of
> both. The actual clock rate depends on the link speed.
>
> I should rephrase the comment along the lines of:
>
> The following two are dummy clocks, placeholders used in the gmac_tx
> clock. The gmac driver will choose one parent depending on the PHY
> interface mode, using clk_set_rate auto-reparenting.
> The actual TX clock rate is not controlled by the gmac_tx clock.
Ok, thanks for the clarification.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/e5b2cc87/attachment.sig>
^ permalink raw reply
* PCIe trouble on imx6q
From: Kamel BOUHARA @ 2014-02-04 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM9uW_6rrXrwEKSXBZd+B=WzyoFqjrBgrmXNk0u42JFuMcTJ=g@mail.gmail.com>
2014-01-29 Kamel BOUHARA <k.bouhara@gmail.com>:
> 2014-01-29 Bjorn Helgaas <bhelgaas@google.com>:
>> [+cc linux-arm, Richard, Shawn (please keep the cc list)]
>>
>> On Wed, Jan 29, 2014 at 2:28 AM, Kamel BOUHARA <k.bouhara@gmail.com> wrote:
>>> ---------- Forwarded message ----------
>>> From: Kamel BOUHARA <k.bouhara@gmail.com>
>>> Date: 2014-01-29
>>> Subject: Re: PCIe trouble on imx6q
>>> To: Bjorn Helgaas <bhelgaas@google.com>
>>>
>>>
>>> 2014-01-28 Bjorn Helgaas <bhelgaas@google.com>:
>>>> [+cc Richard, Shawn, linux-arm-kernel (all from MAINTAINERS)]
>>>>
>>>> On Tue, Jan 28, 2014 at 1:02 AM, Kamel BOUHARA <k.bouhara@gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> Im getting trouble with kernel 3.13 at boot time, the pcie link failed
>>>>> to get up with the following log:
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:159 gpio_to_desc+0x34/0x48()
>>>>> invalid GPIO -2
>>>>> Modules linked in:
>>>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0+ #4
>>>>> Backtrace:
>>>>> [<8001217c>] (dump_backtrace) from [<80012460>] (show_stack+0x18/0x1c)
>>>>> r6:802b9548 r5:00000000 r4:808d3060 r3:00000000
>>>>> [<80012448>] (show_stack) from [<806414fc>] (dump_stack+0x84/0x9c)
>>>>> [<80641478>] (dump_stack) from [<800289f8>] (warn_slowpath_common+0x70/0x94)
>>>>> r5:00000009 r4:bf05bcb0
>>>>> [<80028988>] (warn_slowpath_common) from [<80028a54>]
>>>>> (warn_slowpath_fmt+0x38/0x40)
>>>>> r8:01f00000 r7:00000000 r6:0011cc11 r5:808b68c0 r4:bf24fa30
>>>>> [<80028a20>] (warn_slowpath_fmt) from [<802b9548>] (gpio_to_desc+0x34/0x48)
>>>>> r3:fffffffe r2:807d23fc
>>>>> [<802b9514>] (gpio_to_desc) from [<802d9de0>] (imx6_pcie_host_init+0x174/0x434)
>>>>> [<802d9c6c>] (imx6_pcie_host_init) from [<80886dbc>]
>>>>> (dw_pcie_host_init+0x348/0x41c)
>>>>> r6:00000000 r5:808d52cc r4:00000020 r3:802d9c6c
>>>>> [<80886a74>] (dw_pcie_host_init) from [<808871d4>] (imx6_pcie_probe+0x320/0x3dc)
>>>>> r10:00000000 r9:000000c4 r8:808d539c r7:bf7e3384 r6:bf24fa30 r5:bf135810
>>>>> r4:bf24fa10
>>>>> [<80886eb4>] (imx6_pcie_probe) from [<8034b670>] (platform_drv_probe+0x20/0x50)
>>>>> r8:808d539c r7:00000000 r6:00000000 r5:808d539c r4:bf135810
>>>>> [<8034b650>] (platform_drv_probe) from [<80349c74>]
>>>>> (driver_probe_device+0x118/0x234)
>>>>> r5:bf135810 r4:80e526b8
>>>>> [<80349b5c>] (driver_probe_device) from [<80349e78>] (__driver_attach+0x9c/0xa0)
>>>>> r8:80886e90 r7:00000000 r6:bf135844 r5:808d539c r4:bf135810 r3:00000000
>>>>> [<80349ddc>] (__driver_attach) from [<8034806c>] (bus_for_each_dev+0x68/0x9c)
>>>>> r6:80349ddc r5:808d539c r4:00000000 r3:00000000
>>>>> [<80348004>] (bus_for_each_dev) from [<8034972c>] (driver_attach+0x20/0x28)
>>>>> r6:808df6a8 r5:bf1f5e00 r4:808d539c
>>>>> [<8034970c>] (driver_attach) from [<803493b0>] (bus_add_driver+0x148/0x1f4)
>>>>> [<80349268>] (bus_add_driver) from [<8034a4c8>] (driver_register+0x80/0x100)
>>>>> r7:8090e640 r6:8090e640 r5:00000005 r4:808d539c
>>>>> [<8034a448>] (driver_register) from [<8034b63c>]
>>>>> (__platform_driver_register+0x50/0x64)
>>>>> r5:00000005 r4:808d5388
>>>>> [<8034b5ec>] (__platform_driver_register) from [<8034b6e0>]
>>>>> (platform_driver_probe+0x28/0xac)
>>>>> [<8034b6b8>] (platform_driver_probe) from [<80886ea8>]
>>>>> (imx6_pcie_init+0x18/0x24)
>>>>> r5:00000005 r4:808aa104
>>>>> [<80886e90>] (imx6_pcie_init) from [<80008978>] (do_one_initcall+0x100/0x164)
>>>>> [<80008878>] (do_one_initcall) from [<8085ecc0>]
>>>>> (kernel_init_freeable+0x10c/0x1d0)
>>>>> r10:8089e060 r9:000000c4 r8:8089e050 r7:8090e640 r6:8090e640 r5:00000005
>>>>> r4:808aa104
>>>>> [<8085ebb4>] (kernel_init_freeable) from [<8063b67c>] (kernel_init+0x10/0x120)
>>>>> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8063b66c
>>>>> r4:00000000
>>>>> [<8063b66c>] (kernel_init) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
>>>>> r4:00000000 r3:ffffffff
>>>>> ---[ end trace b5e746dfc2398cd6 ]---
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:159 gpio_to_desc+0x34/0x48()
>>>>> invalid GPIO -2
>>>>> Modules linked in:
>>>>> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.13.0+ #4
>>>>> Backtrace:
>>>>> [<8001217c>] (dump_backtrace) from [<80012460>] (show_stack+0x18/0x1c)
>>>>> r6:802b9548 r5:00000000 r4:808d3060 r3:00000000
>>>>> [<80012448>] (show_stack) from [<806414fc>] (dump_stack+0x84/0x9c)
>>>>> [<80641478>] (dump_stack) from [<800289f8>] (warn_slowpath_common+0x70/0x94)
>>>>> r5:00000009 r4:bf05bcb0
>>>>> [<80028988>] (warn_slowpath_common) from [<80028a54>]
>>>>> (warn_slowpath_fmt+0x38/0x40)
>>>>> r8:01f00000 r7:00000000 r6:0011cc11 r5:808b68c0 r4:bf24fa30
>>>>> [<80028a20>] (warn_slowpath_fmt) from [<802b9548>] (gpio_to_desc+0x34/0x48)
>>>>> r3:fffffffe r2:807d23fc
>>>>> [<802b9514>] (gpio_to_desc) from [<802d9df8>] (imx6_pcie_host_init+0x18c/0x434)
>>>>> [<802d9c6c>] (imx6_pcie_host_init) from [<80886dbc>]
>>>>> (dw_pcie_host_init+0x348/0x41c)
>>>>> r6:00000000 r5:808d52cc r4:00000020 r3:802d9c6c
>>>>> [<80886a74>] (dw_pcie_host_init) from [<808871d4>] (imx6_pcie_probe+0x320/0x3dc)
>>>>> r10:00000000 r9:000000c4 r8:808d539c r7:bf7e3384 r6:bf24fa30 r5:bf135810
>>>>> r4:bf24fa10
>>>>> [<80886eb4>] (imx6_pcie_probe) from [<8034b670>] (platform_drv_probe+0x20/0x50)
>>>>> r8:808d539c r7:00000000 r6:00000000 r5:808d539c r4:bf135810
>>>>> [<8034b650>] (platform_drv_probe) from [<80349c74>]
>>>>> (driver_probe_device+0x118/0x234)
>>>>> r5:bf135810 r4:80e526b8
>>>>> [<80349b5c>] (driver_probe_device) from [<80349e78>] (__driver_attach+0x9c/0xa0)
>>>>> r8:80886e90 r7:00000000 r6:bf135844 r5:808d539c r4:bf135810 r3:00000000
>>>>> [<80349ddc>] (__driver_attach) from [<8034806c>] (bus_for_each_dev+0x68/0x9c)
>>>>> r6:80349ddc r5:808d539c r4:00000000 r3:00000000
>>>>> [<80348004>] (bus_for_each_dev) from [<8034972c>] (driver_attach+0x20/0x28)
>>>>> r6:808df6a8 r5:bf1f5e00 r4:808d539c
>>>>> [<8034970c>] (driver_attach) from [<803493b0>] (bus_add_driver+0x148/0x1f4)
>>>>> [<80349268>] (bus_add_driver) from [<8034a4c8>] (driver_register+0x80/0x100)
>>>>> r7:8090e640 r6:8090e640 r5:00000005 r4:808d539c
>>>>> [<8034a448>] (driver_register) from [<8034b63c>]
>>>>> (__platform_driver_register+0x50/0x64)
>>>>> r5:00000005 r4:808d5388
>>>>> [<8034b5ec>] (__platform_driver_register) from [<8034b6e0>]
>>>>> (platform_driver_probe+0x28/0xac)
>>>>> [<8034b6b8>] (platform_driver_probe) from [<80886ea8>]
>>>>> (imx6_pcie_init+0x18/0x24)
>>>>> r5:00000005 r4:808aa104
>>>>> [<80886e90>] (imx6_pcie_init) from [<80008978>] (do_one_initcall+0x100/0x164)
>>>>> [<80008878>] (do_one_initcall) from [<8085ecc0>]
>>>>> (kernel_init_freeable+0x10c/0x1d0)
>>>>> r10:8089e060 r9:000000c4 r8:8089e050 r7:8090e640 r6:8090e640 r5:00000005
>>>>> r4:808aa104
>>>>> [<8085ebb4>] (kernel_init_freeable) from [<8063b67c>] (kernel_init+0x10/0x120)
>>>>> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8063b66c
>>>>> r4:00000000
>>>>> [<8063b66c>] (kernel_init) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
>>>>> r4:00000000 r3:ffffffff
>>>>> ---[ end trace b5e746dfc2398cd7 ]---
>>>>> imx6q-pcie 1ffc000.pcie: phy link never came up
>>>>> PCI host bridge to bus 0000:00
>>>>> pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
>>>>> pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
>>>>> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
>>>>
>>>> Not related to the GPIO/link problem, but something's wrong here --
>>>> the host bridge driver should be telling us what bus numbers are
>>>> behind the host bridge. Since it didn't, the PCI core had to guess.
>>>>
>>>>> PCI: bus0: Fast back to back transfers disabled
>>>>> PCI: bus1: Fast back to back transfers enabled
>>>>> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
>>>>> pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
>>>>> pci 0000:00:00.0: PCI bridge to [bus 01]
>>>>> pci 0000:00:00.0: PCI bridge to [bus 01]
>>>>>
>>>>> Please, any help is welcome.
>>>>> Regards,
>>>>> Kamel.B
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> So I suppose, this is not a hardware issue rather a bad configuration ?
>>> Maybe the following log from lspci will be helpful ?
>>
>> It looks like a configuration issue or an imx6q host bridge issue. In
>> either case, it looks like something *before* we get to PCIe, so
>> something like your DT description of the host bridge is more likely
>> to be useful.
>>
>>> root at phyFLEX-i:~ lspci -vvv
>>> 00:00.0 PCI bridge: Device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr+ Stepping- SERR+ FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> Latency: 0, Cache Line Size: 64 bytes
>>> Region 0: Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
>>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>>> I/O behind bridge: 0000f000-00000fff
>>> Memory behind bridge: fff00000-000fffff
>>> Prefetchable memory behind bridge: fff00000-000fffff
>>> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- <SERR- <PERR-
>>> [virtual] Expansion ROM at 01100000 [disabled] [size=64K]
>>> BridgeCtl: Parity+ SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>>> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>> Capabilities: [40] Power Management version 3
>>> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>>> PME(D0+,D1+,D2-,D3hot+,D3cold+)
>>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>>> Capabilities: [50] MSI: Mask+ 64bit+ Count=1/1 Enable+
>>> Address: 0000000090000000 Data: 0000
>>> Masking: 00000000 Pending: 00000000
>>> Capabilities: [70] Express (v2) Root Port (Slot-), MSI 00
>>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
>>> <64ns, L1 <1us
>>> ExtTag- RBE+ FLReset-
>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
>>> Unsupported+
>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
>>> AuxPwr+ TransPend-
>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
>>> Latency L0 <1us, L1 <8us
>>> ClockPM- Surprise- LLActRep+ BwNot-
>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
>>> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>>> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal-
>>> PMEIntEna+ CRSVisible-
>>> RootCap: CRSVisible-
>>> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
>>> DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ ARIFwd-
>>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
>>> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance-
>>> SpeedDis-, Selectable De-emphasis: -6dB
>>> Transmit Margin: Normal Operating Range,
>>> EnterModifiedCompliance- ComplianceSOS-
>>> Compliance De-emphasis: -6dB
>>> LnkSta2: Current De-emphasis Level: -3.5dB
>>> Capabilities: [100] Advanced Error Reporting
>>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
>>> UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>>> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>>> Capabilities: [140] Virtual Channel <?>
>>> Kernel driver in use: pcieport
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Ok, actually I didn't get the host bridge set properly for my board,
> here is my DT:
>
>
> /dts-v1/;
> #include "imx6q-phytec-pfla02.dtsi"
>
> / {
> model = "Phytec phyFLEX-i.MX6 Quad Carrier-Board";
> compatible = "phytec,imx6q-pbab01", "phytec,imx6q-pfla02", "fsl,imx6q";
> };
>
> &fec {
> status = "okay";
> };
>
> &uart4 {
> status = "okay";
> };
>
> &usdhc2 {
> status = "okay";
> };
>
> &usdhc3 {
> status = "okay";
> };
>
> &pcie {
> status = "okay";
> };
>
>
> Can you give me a example of host configuration ?
>
>
> BR, Kamel.B
I finally found that I missed the disable-gpio that has to be at high level:
&pcie {
/*module pfla02 rev1 */
#if 0
reset-gpio = <&gpio2 23 0>; /* active low */
wake-up-gpio = <&gpio1 7 0>; /* active low */
disable-gpio = <&gpio1 21 1>; /* active low, don't disable endpoint gpios */
#endif
#if 1
/*module pfla02 rev2*/
reset-gpio = <&gpio2 23 0>;
wake-up-gpio = <&gpio1 7 0>;
disable-gpio = <&gpio4 17 1>;
#endif
};
But Im still stuck on the bus ressource affectation, Bjorn Helgaas
said that normally it is auto affected by the host bridge driver ?
Is there a patch to fix this ?
imx6q-pcie 1ffc000.pcie: reset-gpio number is 55
imx6q-pcie 1ffc000.pcie: power-on-gpio number is -2
imx6q-pcie 1ffc000.pcie: wake-up-gpio number is 7
imx6q-pcie 1ffc000.pcie: disable-gpio number is 113
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
PCI: bus1: Fast back to back transfers disabled
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
pci 0000:00:00.0: BAR 9: assigned [mem 0x01100000-0x011fffff pref]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01200000-0x0120ffff pref]
pci 0000:01:00.0: BAR 0: assigned [mem 0x01100000-0x01100fff 64bit pref]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff pref]
BR, Kamel B.
^ permalink raw reply
* [PATCH v3 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Maxime Ripard @ 2014-02-04 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204002110.GP22609@sirena.org.uk>
Hi Mark,
On Tue, Feb 04, 2014 at 12:21:10AM +0000, Mark Brown wrote:
> On Fri, Jan 31, 2014 at 11:47:04PM +0100, Maxime Ripard wrote:
> > On Fri, Jan 31, 2014 at 12:48:09PM +0000, Mark Brown wrote:
> > > On Fri, Jan 31, 2014 at 11:55:50AM +0100, Maxime Ripard wrote:
>
> > > > + pm_runtime_enable(&pdev->dev);
> > > > + if (!pm_runtime_enabled(&pdev->dev)) {
> > > > + ret = sun6i_spi_runtime_resume(&pdev->dev);
> > > > + if (ret) {
> > > > + dev_err(&pdev->dev, "Couldn't resume the device\n");
> > > > + return ret;
> > > > + }
> > > > + }
>
> > > No, as discussed don't do this - notice how other drivers aren't written
> > > this way either. Like I said leave the device powered on startup and
> > > then let it be idled by runtime PM.
>
> > Well, some SPI drivers are actually written like that (all the tegra
>
> It's not been done consistently, no - that should be fixed.
>
> > SPI drivers for example). It's not an excuse, but waking up the device
> > only to put it back in suspend right away seems kind of
>
> It isn't awesome, no. Ideally the runtime PM code would do this but
> then you couldn't ifdef the operations which as far as I can tell is the
> main thing people want from disabling it and it gets complicated for
> devices that genuinely do power up on startup so here we are.
We discussed it with Kevin on IRC, and he suggested that we move that
pm_runtime initialization to the SPI core, but I guess that would also
mean that all drivers shouldn't ifdef the operations, so that the core
can call the runtime_resume callback directly.
However, I don't really get why any driver should be doing so, since
you still need these functions to at least to the device
suspend/resume in the probe/remove, and you don't really want to
duplicate the code.
Right now, about half of the SPI drivers using auto_runtime_pm are
using a ifdef, the other half is not.
> > inefficient. Plus, the pm_runtime_idle callback you suggested are
> > actually calling runtime_idle, while we want to call runtime_suspend.
>
> Yeah, I didn't actually check if I was looking at the right call there.
I was actually wrong, it does so in its very last line.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/60ce6bb9/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] clk: at91: propagate rate change on system clks
From: Nicolas Ferre @ 2014-02-04 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-4-git-send-email-b.brezillon@overkiz.com>
On 03/02/2014 12:25, Boris BREZILLON :
> System clks are just gates, and thus do not provide any rate operations.
> Authorize clk rate change to be propagated to system clk parents.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/clk/at91/clk-system.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/at91/clk-system.c b/drivers/clk/at91/clk-system.c
> index 8f7c043..a98557b 100644
> --- a/drivers/clk/at91/clk-system.c
> +++ b/drivers/clk/at91/clk-system.c
> @@ -84,7 +84,8 @@ at91_clk_register_system(struct at91_pmc *pmc, const char *name,
> * (see drivers/memory) which would request and enable the ddrck clock.
> * When this is done we will be able to remove CLK_IGNORE_UNUSED flag.
> */
> - init.flags = CLK_IGNORE_UNUSED;
> + init.flags = CLK_SET_RATE_GATE | CLK_SET_RATE_PARENT |
> + CLK_IGNORE_UNUSED;
>
> sys->id = id;
> sys->hw.init = &init;
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 2/3] clk: at91: replace prog clk round_rate with determine_rate
From: Nicolas Ferre @ 2014-02-04 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-3-git-send-email-b.brezillon@overkiz.com>
On 03/02/2014 12:25, Boris BREZILLON :
> Implement the determine_rate callback to choose the best parent clk that
> fulfills the requested rate.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Nice feature, thanks!
> ---
> drivers/clk/at91/clk-programmable.c | 56 +++++++++++++++++------------------
> 1 file changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 02f62a0..8e242c7 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -105,40 +105,40 @@ static unsigned long clk_programmable_recalc_rate(struct clk_hw *hw,
> return parent_rate >> prog->pres;
> }
>
> -static long clk_programmable_round_rate(struct clk_hw *hw, unsigned long rate,
> - unsigned long *parent_rate)
> +static long clk_programmable_determine_rate(struct clk_hw *hw,
> + unsigned long rate,
> + unsigned long *best_parent_rate,
> + struct clk **best_parent_clk)
> {
> - unsigned long best_rate = *parent_rate;
> - unsigned long best_diff;
> - unsigned long new_diff;
> - unsigned long cur_rate;
> - int shift = shift;
> -
> - if (rate > *parent_rate)
> - return *parent_rate;
> - else
> - best_diff = *parent_rate - rate;
> -
> - if (!best_diff)
> - return best_rate;
> + struct clk *parent = NULL;
> + long best_rate = -EINVAL;
> + unsigned long parent_rate;
> + unsigned long tmp_rate;
> + int shift;
> + int i;
>
> - for (shift = 1; shift < PROG_PRES_MASK; shift++) {
> - cur_rate = *parent_rate >> shift;
> + for (i = 0; i < __clk_get_num_parents(hw->clk); i++) {
> + parent = clk_get_parent_by_index(hw->clk, i);
> + if (!parent)
> + continue;
>
> - if (cur_rate > rate)
> - new_diff = cur_rate - rate;
> - else
> - new_diff = rate - cur_rate;
> + parent_rate = __clk_get_rate(parent);
> + for (shift = 0; shift < PROG_PRES_MASK; shift++) {
> + tmp_rate = parent_rate >> shift;
> + if (tmp_rate <= rate)
> + break;
> + }
>
> - if (!new_diff)
> - return cur_rate;
> + if (tmp_rate > rate)
> + continue;
>
> - if (new_diff < best_diff) {
> - best_diff = new_diff;
> - best_rate = cur_rate;
> + if (best_rate < 0 || (rate - tmp_rate) < (rate - best_rate)) {
> + best_rate = tmp_rate;
> + *best_parent_rate = parent_rate;
> + *best_parent_clk = parent;
> }
>
> - if (rate > cur_rate)
> + if (!best_rate)
> break;
> }
>
> @@ -231,7 +231,7 @@ static const struct clk_ops programmable_ops = {
> .prepare = clk_programmable_prepare,
> .is_prepared = clk_programmable_is_ready,
> .recalc_rate = clk_programmable_recalc_rate,
> - .round_rate = clk_programmable_round_rate,
> + .determine_rate = clk_programmable_determine_rate,
> .get_parent = clk_programmable_get_parent,
> .set_parent = clk_programmable_set_parent,
> .set_rate = clk_programmable_set_rate,
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 1/3] clk: at91: fix programmable clk irq handling
From: Nicolas Ferre @ 2014-02-04 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-2-git-send-email-b.brezillon@overkiz.com>
On 03/02/2014 12:25, Boris BREZILLON :
> The prog irq is a level irq reflecting the prog clk status. As a result the
> irq line will stay high when the prog clk is ready and the system will
> hang.
> Disable the irq when it is handled to avoid this problem.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/clk/at91/clk-programmable.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index fd792b2..02f62a0 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -55,6 +55,7 @@ static irqreturn_t clk_programmable_irq_handler(int irq, void *dev_id)
> struct clk_programmable *prog = (struct clk_programmable *)dev_id;
>
> wake_up(&prog->wait);
> + disable_irq_nosync(prog->irq);
>
> return IRQ_HANDLED;
> }
> @@ -74,8 +75,10 @@ static int clk_programmable_prepare(struct clk_hw *hw)
>
> pmc_write(pmc, AT91_PMC_PCKR(id), tmp);
>
> - while (!(pmc_read(pmc, AT91_PMC_SR) & mask))
> + while (!(pmc_read(pmc, AT91_PMC_SR) & mask)) {
> + enable_irq(prog->irq);
> wait_event(prog->wait, pmc_read(pmc, AT91_PMC_SR) & mask);
> + }
>
> return 0;
> }
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Nicolas Ferre @ 2014-02-04 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391502105-24612-1-git-send-email-jjhiblot@traphandler.com>
On 04/02/2014 09:21, Jean-Jacques Hiblot :
> The name provided to request_irq() must be valid until the irq is released.
> This patch stores the name in the internal data structure.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks. Bye,
> ---
> drivers/clk/at91/clk-programmable.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 8e242c7..799b75c 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -44,6 +44,7 @@ struct clk_programmable {
> u8 css;
> u8 pres;
> u8 slckmck;
> + char irq_name[11];
> const struct clk_programmable_layout *layout;
> };
>
> @@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> struct clk_programmable *prog;
> struct clk *clk = NULL;
> struct clk_init_data init;
> - char irq_name[11];
>
> if (id > PROG_ID_MAX)
> return ERR_PTR(-EINVAL);
> @@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> prog->irq = irq;
> init_waitqueue_head(&prog->wait);
> irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
> - snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
> + snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
> ret = request_irq(prog->irq, clk_programmable_irq_handler,
> - IRQF_TRIGGER_HIGH, irq_name, prog);
> + IRQF_TRIGGER_HIGH, prog->irq_name, prog);
> if (ret)
> return ERR_PTR(ret);
>
>
--
Nicolas Ferre
^ 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