[PATCH 4/5] iommu/arm-smmu-v3: move arm_smmu_get_step_for_sid() a little ahead
No functional change, just prepare for the next patch.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm-smmu-v3.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 5bb5dcd..84adecc 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1273,6 +1273,28 @@ static int arm_smmu_init_dummy_l2_strtab(struct
arm_smmu_device *smmu, u32 sid)
return __arm_smmu_init_l2_strtab(smmu, sid, _desc);
}
+static __le64 *arm_smmu_get_step_for_sid(struct arm_smmu_device *smmu, u32 sid)
+{
+ __le64 *step;
+ struct arm_smmu_strtab_cfg *cfg = >strtab_cfg;
+
+ if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
+ struct arm_smmu_strtab_l1_desc *l1_desc;
+ int idx;
+
+ /* Two-level walk */
+ idx = (sid >> STRTAB_SPLIT) * STRTAB_L1_DESC_DWORDS;
+ l1_desc = >l1_desc[idx];
+ idx = (sid & ((1 << STRTAB_SPLIT) - 1)) * STRTAB_STE_DWORDS;
+ step = _desc->l2ptr[idx];
+ } else {
+ /* Simple linear lookup */
+ step = >strtab[sid * STRTAB_STE_DWORDS];
+ }
+
+ return step;
+}
+
/* IRQ and event handlers */
static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
{
@@ -1704,28 +1726,6 @@ static int arm_smmu_domain_finalise(struct iommu_domain
*domain)
return 0;
}
-static __le64 *arm_smmu_get_step_for_sid(struct arm_smmu_device *smmu, u32 sid)
-{
- __le64 *step;
- struct arm_smmu_strtab_cfg *cfg = >strtab_cfg;
-
- if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
- struct arm_smmu_strtab_l1_desc *l1_desc;
- int idx;
-
- /* Two-level walk */
- idx = (sid >> STRTAB_SPLIT) * STRTAB_L1_DESC_DWORDS;
- l1_desc = >l1_desc[idx];
- idx = (sid & ((1 << STRTAB_SPLIT) - 1)) * STRTAB_STE_DWORDS;
- step = _desc->l2ptr[idx];
- } else {
- /* Simple linear lookup */
- step = >strtab[sid * STRTAB_STE_DWORDS];
- }
-
- return step;
-}
-
static void arm_smmu_install_ste_for_dev(struct iommu_fwspec *fwspec)
{
int i, j;
--
1.8.3
[PATCH 1/5] iommu/arm-smmu-v3: make sure the stale caching of L1STD are invalid
Invalidate the caching of the intermediate L1ST descriptor after it has
been updated.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm-smmu-v3.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 0d28402..2072897 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1072,13 +1072,14 @@ static void arm_smmu_write_ctx_desc(struct
arm_smmu_device *smmu,
*dst = cpu_to_le64(val);
}
-static void arm_smmu_sync_ste_for_sid(struct arm_smmu_device *smmu, u32 sid)
+static void
+__arm_smmu_sync_ste_for_sid(struct arm_smmu_device *smmu, u32 sid, bool leaf)
{
struct arm_smmu_cmdq_ent cmd = {
.opcode = CMDQ_OP_CFGI_STE,
.cfgi = {
.sid= sid,
- .leaf = true,
+ .leaf = leaf,
},
};
@@ -1086,6 +1087,16 @@ static void arm_smmu_sync_ste_for_sid(struct
arm_smmu_device *smmu, u32 sid)
arm_smmu_cmdq_issue_sync(smmu);
}
+static void arm_smmu_sync_ste_for_sid(struct arm_smmu_device *smmu, u32 sid)
+{
+ __arm_smmu_sync_ste_for_sid(smmu, sid, true);
+}
+
+static void arm_smmu_sync_std_for_sid(struct arm_smmu_device *smmu, u32 sid)
+{
+ __arm_smmu_sync_ste_for_sid(smmu, sid, false);
+}
+
static void arm_smmu_write_strtab_ent(struct arm_smmu_device *smmu, u32 sid,
__le64 *dst, struct arm_smmu_strtab_ent
*ste)
{
@@ -1233,6 +1244,7 @@ static int arm_smmu_init_l2_strtab(struct arm_smmu_device
*smmu, u32 sid)
arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT);
arm_smmu_write_strtab_l1_desc(strtab, desc);
+ arm_smmu_sync_std_for_sid(smmu, sid);
return 0;
}
--
1.8.3
[PATCH 0/5] iommu/arm-smmu-v3: make smmu can be enabled in kdump kernel
This patch series include two parts: 1. Patch1-2 use dummy STE tables with "ste abort" hardware feature to abort unexpected devices accessing. For more details, see the description in patch 2. 2. If the "ste abort" feature is not support, force the unexpected devices in the secondary kernel to use the memory maps which it used in the first kernel. For more details, see patch 5. Zhen Lei (5): iommu/arm-smmu-v3: make sure the stale caching of L1STD are invalid iommu/arm-smmu-v3: make smmu can be enabled in kdump kernel iommu/arm-smmu-v3: add macro xxx_SIZE to replace xxx_DWORDS shift iommu/arm-smmu-v3: move arm_smmu_get_step_for_sid() a little ahead iommu/arm-smmu-v3: workaround for STE abort in kdump kernel drivers/iommu/arm-smmu-v3.c | 243 +++- 1 file changed, 194 insertions(+), 49 deletions(-) -- 1.8.3
[PATCH 2/5] iommu/arm-smmu-v3: make smmu can be enabled in kdump kernel
To reduce the risk of further crash, the device_shutdown() was not called
by the first kernel. That means some devices may still working in the
secondary kernel. For example, a netcard may still using ring buffer to
receive the broadcast messages in the kdump kernel. No events are reported
utill the related smmu reinitialized by the kdump kernel.
commit b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is
enabled in kdump kernel") set SMMU_GBPA.ABORT to prevent the unexpected
devices accessing, but it also prevent the devices accessing which we
needed, like hard disk, netcard.
In fact, we can use STE.config=0b000 to abort the unexpected devices
accessing only. As below:
1. In the first kernel, all buffers used by the "unexpected" devices are
correctly mapped, and it will not be used by the secondary kernel
because the latter has its dedicated reserved memory.
2. In the secondary kernel, set SMMU_GBPA.ABORT=1 before "disable smmu".
3. In the secondary kernel, after the smmu was disabled, preset all
STE.config=0b000. For 2-level Stream Table, make all L1STD.l2ptr
pointer to a dummy L2ST. The dummy L2ST is shared by all L1STDs.
4. In the secondary kernel, enable smmu. For the needed devices, allocate
new L2STs accordingly.
For phase 1 and 2, the unexpected devices base the old mapping access
memory, it will not corrupt others. For phase 3, SMMU_GBPA abort it. For
phase 4 STE abort it.
Fixes: commit b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions ...")
Signed-off-by: Zhen Lei
---
drivers/iommu/arm-smmu-v3.c | 72 -
1 file changed, 51 insertions(+), 21 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 2072897..c3c4ff2 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1219,35 +1219,57 @@ static void arm_smmu_init_bypass_stes(u64 *strtab,
unsigned int nent)
}
}
-static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
+static int __arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid,
+struct arm_smmu_strtab_l1_desc *desc)
{
- size_t size;
void *strtab;
struct arm_smmu_strtab_cfg *cfg = >strtab_cfg;
- struct arm_smmu_strtab_l1_desc *desc = >l1_desc[sid >>
STRTAB_SPLIT];
- if (desc->l2ptr)
- return 0;
-
- size = 1 << (STRTAB_SPLIT + ilog2(STRTAB_STE_DWORDS) + 3);
strtab = >strtab[(sid >> STRTAB_SPLIT) * STRTAB_L1_DESC_DWORDS];
- desc->span = STRTAB_SPLIT + 1;
- desc->l2ptr = dmam_alloc_coherent(smmu->dev, size, >l2ptr_dma,
- GFP_KERNEL | __GFP_ZERO);
if (!desc->l2ptr) {
- dev_err(smmu->dev,
- "failed to allocate l2 stream table for SID %u\n",
- sid);
- return -ENOMEM;
+ size_t size;
+
+ size = 1 << (STRTAB_SPLIT + ilog2(STRTAB_STE_DWORDS) + 3);
+ desc->l2ptr = dmam_alloc_coherent(smmu->dev, size,
+ >l2ptr_dma,
+ GFP_KERNEL | __GFP_ZERO);
+ if (!desc->l2ptr) {
+ dev_err(smmu->dev,
+ "failed to allocate l2 stream table for SID
%u\n",
+ sid);
+ return -ENOMEM;
+ }
+
+ desc->span = STRTAB_SPLIT + 1;
+ arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT);
}
- arm_smmu_init_bypass_stes(desc->l2ptr, 1 << STRTAB_SPLIT);
arm_smmu_write_strtab_l1_desc(strtab, desc);
+ return 0;
+}
+
+static int arm_smmu_init_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
+{
+ int ret;
+ struct arm_smmu_strtab_cfg *cfg = >strtab_cfg;
+ struct arm_smmu_strtab_l1_desc *desc = >l1_desc[sid >>
STRTAB_SPLIT];
+
+ ret = __arm_smmu_init_l2_strtab(smmu, sid, desc);
+ if (ret)
+ return ret;
+
arm_smmu_sync_std_for_sid(smmu, sid);
return 0;
}
+static int arm_smmu_init_dummy_l2_strtab(struct arm_smmu_device *smmu, u32 sid)
+{
+ static struct arm_smmu_strtab_l1_desc dummy_desc;
+
+ return __arm_smmu_init_l2_strtab(smmu, sid, _desc);
+}
+
/* IRQ and event handlers */
static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
{
@@ -2150,8 +2172,12 @@ static int arm_smmu_init_l1_strtab(struct
arm_smmu_device *smmu)
}
for (i = 0; i < cfg->num_l1_ents; ++i) {
- arm_smmu_write_strtab_l1_desc(strtab, >l1_desc[i]);
- strtab += STRTAB_L1_DESC_DWORDS << 3;
+ if (is_kdump_kernel()) {
+ arm_smmu_init_dummy_l2_strtab(smmu, i << STRTAB_SPLIT);
+ } else {
+ arm_smmu_write_strtab_l1_desc(strtab, >l1_desc[i]);
+
[PATCH 3/5] iommu/arm-smmu-v3: add macro xxx_SIZE to replace xxx_DWORDS shift
The (STRTAB_L1_DESC_DWORDS << 3) appears more than 1 times, replace it
with STRTAB_L1_DESC_SIZE to eliminate the duplication. And the latter
seems more clear when it's used to calculate memory size. And the same is
true for STRTAB_STE_DWORDS and CTXDESC_CD_DWORDS.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm-smmu-v3.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index c3c4ff2..5bb5dcd 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -202,10 +202,12 @@
#define STRTAB_SPLIT 8
#define STRTAB_L1_DESC_DWORDS 1
+#define STRTAB_L1_DESC_SIZE(STRTAB_L1_DESC_DWORDS << 3)
#define STRTAB_L1_DESC_SPANGENMASK_ULL(4, 0)
#define STRTAB_L1_DESC_L2PTR_MASK GENMASK_ULL(51, 6)
#define STRTAB_STE_DWORDS 8
+#define STRTAB_STE_SIZE(STRTAB_STE_DWORDS << 3)
#define STRTAB_STE_0_V (1UL << 0)
#define STRTAB_STE_0_CFG GENMASK_ULL(3, 1)
#define STRTAB_STE_0_CFG_ABORT 0
@@ -251,6 +253,7 @@
/* Context descriptor (stage-1 only) */
#define CTXDESC_CD_DWORDS 8
+#define CTXDESC_CD_SIZE(CTXDESC_CD_DWORDS << 3)
#define CTXDESC_CD_0_TCR_T0SZ GENMASK_ULL(5, 0)
#define ARM64_TCR_T0SZ GENMASK_ULL(5, 0)
#define CTXDESC_CD_0_TCR_TG0 GENMASK_ULL(7, 6)
@@ -1563,7 +1566,7 @@ static void arm_smmu_domain_free(struct iommu_domain
*domain)
if (cfg->cdptr) {
dmam_free_coherent(smmu_domain->smmu->dev,
- CTXDESC_CD_DWORDS << 3,
+ CTXDESC_CD_SIZE,
cfg->cdptr,
cfg->cdptr_dma);
@@ -1590,7 +1593,7 @@ static int arm_smmu_domain_finalise_s1(struct
arm_smmu_domain *smmu_domain,
if (asid < 0)
return asid;
- cfg->cdptr = dmam_alloc_coherent(smmu->dev, CTXDESC_CD_DWORDS << 3,
+ cfg->cdptr = dmam_alloc_coherent(smmu->dev, CTXDESC_CD_SIZE,
>cdptr_dma,
GFP_KERNEL | __GFP_ZERO);
if (!cfg->cdptr) {
@@ -2176,7 +2179,7 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device
*smmu)
arm_smmu_init_dummy_l2_strtab(smmu, i << STRTAB_SPLIT);
} else {
arm_smmu_write_strtab_l1_desc(strtab, >l1_desc[i]);
- strtab += STRTAB_L1_DESC_DWORDS << 3;
+ strtab += STRTAB_L1_DESC_SIZE;
}
}
@@ -2201,7 +2204,7 @@ static int arm_smmu_init_strtab_2lvl(struct
arm_smmu_device *smmu)
"2-level strtab only covers %u/%u bits of SID\n",
size, smmu->sid_bits);
- l1size = cfg->num_l1_ents * (STRTAB_L1_DESC_DWORDS << 3);
+ l1size = cfg->num_l1_ents * STRTAB_L1_DESC_SIZE;
strtab = dmam_alloc_coherent(smmu->dev, l1size, >strtab_dma,
GFP_KERNEL | __GFP_ZERO);
if (!strtab) {
@@ -2228,7 +2231,7 @@ static int arm_smmu_init_strtab_linear(struct
arm_smmu_device *smmu)
u32 size;
struct arm_smmu_strtab_cfg *cfg = >strtab_cfg;
- size = (1 << smmu->sid_bits) * (STRTAB_STE_DWORDS << 3);
+ size = (1 << smmu->sid_bits) * STRTAB_STE_SIZE;
strtab = dmam_alloc_coherent(smmu->dev, size, >strtab_dma,
GFP_KERNEL | __GFP_ZERO);
if (!strtab) {
--
1.8.3
[PATCH 5/5] iommu/arm-smmu-v3: workaround for STE abort in kdump kernel
Some boards may not implement the STE.config=0b000 correctly, it also
reports event C_BAD_STE when a transaction incoming. To make kdump kernel
can be worked well in this situation, backup the strtab_base which is used
in the first kernel, to make the unexpected devices can reuse the old
mapping if we detected the STE.config=0b000 take no effect.
Signed-off-by: Zhen Lei
---
drivers/iommu/arm-smmu-v3.c | 100
1 file changed, 100 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 84adecc..4e95710 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -335,6 +335,9 @@
#define EVTQ_MAX_SZ_SHIFT 7
#define EVTQ_0_ID GENMASK_ULL(7, 0)
+#define EVTQ_0_ID_C_BAD_STE0x4
+#define EVTQ_0_SSV GENMASK_ULL(11, 11)
+#define EVTQ_0_SID GENMASK_ULL(63, 32)
/* PRI queue */
#define PRIQ_ENT_DWORDS2
@@ -525,6 +528,7 @@ struct arm_smmu_strtab_ent {
struct arm_smmu_strtab_cfg {
__le64 *strtab;
dma_addr_t strtab_dma;
+ dma_addr_t former_strtab_dma;
struct arm_smmu_strtab_l1_desc *l1_desc;
unsigned intnum_l1_ents;
@@ -1295,6 +1299,95 @@ static __le64 *arm_smmu_get_step_for_sid(struct
arm_smmu_device *smmu, u32 sid)
return step;
}
+/*
+ * This function is only called in the kdump kernel, and mainly because of the
+ * smmu hardware feature "ste abort" is not effective.
+ *
+ * The first kernel flushed all cache before start the secondary kernel, so
+ * it's safe base on ioremap() to access the former smmu tables.
+ *
+ * If any error detected, just simply give up the attempt, directly return
+ * without any error reported.
+ */
+static void arm_smmu_ste_abort_quirks(struct arm_smmu_device *smmu, u64 evt0)
+{
+ int i;
+ __le64 *dst, *src;
+ u64 val, paddr;
+ u32 sid = FIELD_GET(EVTQ_0_SID, evt0);
+ struct arm_smmu_strtab_cfg *cfg = >strtab_cfg;
+
+ /* SubStreamID is not support yet */
+ if (FIELD_GET(EVTQ_0_SSV, evt0))
+ return;
+
+ /*
+* If no device within this L2ST range has been added, the L1STD.L2Ptr
+* still point to the dummy L2ST, we should allocate one now.
+*/
+ if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
+ int idx, ret;
+
+ idx = (sid >> STRTAB_SPLIT) * STRTAB_L1_DESC_DWORDS;
+ if (!cfg->l1_desc[idx].l2ptr) {
+ ret = arm_smmu_init_l2_strtab(smmu, sid);
+ if (ret)
+ return;
+ }
+ }
+
+ dst = arm_smmu_get_step_for_sid(smmu, sid);
+ val = le64_to_cpu(dst[0]);
+ if (FIELD_GET(STRTAB_STE_0_CFG, val) != STRTAB_STE_0_CFG_ABORT)
+ return;
+
+ /* The value of SMMU_STRTAB_BASE maybe corrupted, sanity check it */
+ if (cfg->former_strtab_dma & ~(STRTAB_BASE_RA | STRTAB_BASE_ADDR_MASK))
+ return;
+
+ /* Find the STE base address of "sid" */
+ if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
+ u32 span;
+
+ paddr = cfg->former_strtab_dma +
+ (sid >> STRTAB_SPLIT) * STRTAB_L1_DESC_SIZE;
+ src = ioremap(paddr, STRTAB_L1_DESC_SIZE);
+ if (!src)
+ return;
+
+ val = le64_to_cpu(*src);
+ paddr = val & STRTAB_L1_DESC_L2PTR_MASK;
+ span = val & STRTAB_L1_DESC_SPAN;
+ iounmap(src);
+
+ /* The content of L1STD maybe corrupted, sanity check it */
+ if (val & ~(STRTAB_L1_DESC_L2PTR_MASK | STRTAB_L1_DESC_SPAN))
+ return;
+ paddr += (sid & ((1 << STRTAB_SPLIT) - 1)) * STRTAB_STE_SIZE;
+ } else {
+ paddr = cfg->former_strtab_dma + (sid * STRTAB_STE_SIZE);
+ }
+
+ src = ioremap(paddr, STRTAB_STE_SIZE);
+ if (!src)
+ return;
+
+ /*
+* Copy the former STE content, so that the device can base the former
+* mapping to access "memory", and does not report any event again.
+*
+* Please note that, the "memory" is legally allocated in the first
+* kernel, so that it will not corrupt the memory of current secondary
+* kernel.
+*/
+ for (i = 1; i < STRTAB_STE_DWORDS; i++)
+ dst[i] = src[i];
+ arm_smmu_sync_ste_for_sid(smmu, sid);
+ dst[0] = src[0];
+ arm_smmu_sync_ste_for_sid(smmu, sid);
+ iounmap(src);
+}
+
/* IRQ and event handlers */
static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
{
@@ -1312,6 +1405,8 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void
*dev)
Re: [PATCH] powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest
On 19/02/2019 04:20, Michael Ellerman wrote:
Hi Michael,
> Mark Cave-Ayland writes:
>> On 08/02/2019 14:45, Christophe Leroy wrote:
>>
>>> Le 08/02/2019 à 15:33, Mark Cave-Ayland a écrit :
Commit 8792468da5e1 "powerpc: Add the ability to save FPU without giving
it up"
>>>
>>> Expected format for the above is:
>>>
>>> Commit 123456789abc ("text")
>>
>> Hi Christophe,
>>
>> Apologies - I'm fairly new at submitting kernel patches, but I can re-send
>> it in the
>> correct format later if required.
>>
unexpectedly removed the MSR_FE0 and MSR_FE1 bits from the bitmask used to
update the MSR of the previous thread in __giveup_fpu() causing a KVM-PR
MacOS
guest to lockup and panic the kernel.
>
> Which kernel is panicking? The guest or the host?
It's the host kernel. As long as you occasionally tap a few keys to keep the
screen
blanking disabled then you can see the panic on the physical console.
I've uploaded a photo I took during the bisection containing the panic when
booting
MacOS X 10.2 under qemu-system-ppc to
https://www.ilande.co.uk/tmp/qemu/macmini-kvm.jpg in case you find it useful.
Given that it's really easy to recreate, let me know if you want me to do a git
pull/rebuild and/or if you need any debugging information as it's easy for me to
reproduce.
Reinstate these bits to the MSR bitmask to enable MacOS guests to run under
32-bit KVM-PR once again without issue.
Signed-off-by: Mark Cave-Ayland
>>>
>>> Should include a Fixes: and a Cc to stable ?
>>>
>>> Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving
>>> it up")
>>> Cc: sta...@vger.kernel.org
>>
>> Indeed, but there are still some questions to be asked here:
>>
>> 1) Why were these bits removed from the original bitmask in the first place
>> without
>> it being documented in the commit message?
>
> It was almost certainly an accident.
Heh, okay :)
>> 2) Is this the right fix? I'm told that MacOS guests already run without
>> this patch
>> on a G5 under 64-bit KVM-PR which may suggest that this is a workaround for
>> another
>> bug elsewhere in the 32-bit powerpc code.
>
> That's slightly worrying. It's hard to say without more detail on why
> the guest is crashing.
>
> I think your patch looks OK based just on the fact that it restores the
> previous behaviour, so I'll pick it up and pass it through my usual
> testing. If nothing breaks I'll merge it.
That would be great! Does it need a CC to stable too? It would be great if this
would
get picked up in the next set of Debian ports kernels, for example.
ATB,
Mark.
[PULL] topic/mei-hdcp
Hi all,
topic/mei-hdcp-2019-02-19:
Prep patches + headers for the mei-hdcp/i915 component interfaces
Also contains the prep work in the component helpers plus adjustements
for the snd-hda/i915 component interface.
Plus one small static inline in the drm_hdcp.h header that both i915
and mei_hdcp will need.
Joonas, please pull into drm-intel-next-queued so I can apply the i915
hdcp patches.
Greg/Arnd, I think there's two options to get the mei-hdcp patches landed
into drivers-misc:
- You pull this topic pull and then apply the mei-hdcp patches on top in
char-misc-next.
- I also pull in char-misc-next to get at 32ea33a04484 ("mei: bus: export
to_mei_cl_device for mei client devices drivers") and then apply all the
mei-hdcp stuff into a new topic branch.
I think 2nd option would be better, allows us to integration test easier,
and we'll have a topic branch in case we need a fixup spanning mei-hdcp
and i915. Also would allow me to start merging the patches, since I think
it's too late for 5.1.
Cheers, Daniel
The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:
Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/topic/mei-hdcp-2019-02-19
for you to fetch changes up to 35c0272502cca0a1b461d310c23aac94a503983d:
drm/audio: declaration of struct device (2019-02-18 20:19:28 +0100)
Prep patches + headers for the mei-hdcp/i915 component interfaces
Also contains the prep work in the component helpers plus adjustements
for the snd-hda/i915 component interface.
Plus one small static inline in the drm_hdcp.h header that both i915
and mei_hdcp will need.
Daniel Vetter (3):
component: Add documentation
components: multiple components for a device
i915/snd_hdac: I915 subcomponent for the snd_hdac
Ramalingam C (5):
drm/i915: enum port definition is moved into i915_drm.h
drm/i915: header for i915 - MEI_HDCP interface
drm/i915: MEI interface definition
drm: helper functions for hdcp2 seq_num to from u32
drm/audio: declaration of struct device
Documentation/driver-api/component.rst | 17 +++
Documentation/driver-api/device_link.rst | 3 +
Documentation/driver-api/index.rst | 1 +
drivers/base/component.c | 206 +--
drivers/gpu/drm/i915/intel_audio.c | 4 +-
drivers/gpu/drm/i915/intel_display.h | 16 +--
include/drm/drm_audio_component.h| 1 +
include/drm/drm_hdcp.h | 18 +++
include/drm/i915_component.h | 5 +
include/drm/i915_drm.h | 15 +++
include/drm/i915_mei_hdcp_interface.h| 149 ++
include/linux/component.h| 76
include/sound/hda_component.h| 5 +-
sound/hda/hdac_component.c | 4 +-
sound/hda/hdac_i915.c| 6 +-
15 files changed, 493 insertions(+), 33 deletions(-)
create mode 100644 Documentation/driver-api/component.rst
create mode 100644 include/drm/i915_mei_hdcp_interface.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC][Patch v8 0/7] KVM: Guest Free Page Hinting
On 19.02.19 01:01, Alexander Duyck wrote: > On Mon, Feb 18, 2019 at 1:04 PM David Hildenbrand wrote: >> >> On 18.02.19 21:40, Nitesh Narayan Lal wrote: >>> On 2/18/19 3:31 PM, Michael S. Tsirkin wrote: On Mon, Feb 18, 2019 at 09:04:57PM +0100, David Hildenbrand wrote: >> So I'm fine with a simple implementation but the interface needs to >> allow the hypervisor to process hints in parallel while guest is >> running. We can then fix any issues on hypervisor without breaking >> guests. > Yes, I am fine with defining an interface that theoretically let's us > change the implementation in the guest later. > I consider this even a > prerequisite. IMHO the interface shouldn't be different, it will be > exactly the same. > > It is just "who" calls the batch freeing and waits for it. And as I > outlined here, doing it without additional threads at least avoids us > for now having to think about dynamic data structures and that we can > sometimes not report "because the thread is still busy reporting or > wasn't scheduled yet". Sorry I wasn't clear. I think we need ability to change the implementation in the *host* later. IOW don't rely on host being synchronous. >>> I actually misread it :) . In any way, there has to be a mechanism to >>> synchronize. >>> >>> If we are going via a bare hypercall (like s390x, like what Alexander >>> proposes), it is going to be a synchronous interface either way. Just a >>> bare hypercall, there will not really be any blocking on the guest side. >> It bothers me that we are now tied to interface being synchronous. We >> won't be able to fix it if there's an issue as that would break guests. > I assume with "fix it" you mean "fix kfree taking longer on every X call"? > > Yes, as I initially wrote, this mimics s390x. That might be good (we > know it has been working for years) and bad (we are inheriting the same > problem class, if it exists). And being synchronous is part of the > approach for now. BTW on s390 are these hypercalls handled by Linux? > I tend to focus on the first part (we don't know anything besides it is > working) while you focus on the second part (there could be a potential > problem). Having a real problem at hand would be great, then we would > know what exactly we actually have to fix. But read below. If we end up doing a hypercall per THP, maybe we could at least not block with interrupts disabled? Poll in guest until hypervisor reports its done? That would already be an improvement IMHO. E.g. perf within guest will point you in the right direction and towards disabling hinting. >>> Via virtio, I guess it is waiting for a response to a requests, right? >> For the buffer to be used, yes. And it could mean putting some pages >> aside until hypervisor is done with them. Then you don't need timers or >> tricks like this, you can get an interrupt and start using the memory. > I am very open to such an approach as long as we can make it work and it > is not too complicated. (-> simple) > > This would mean for example > > 1. Collect entries to be reported per VCPU in a buffer. Say magic number > 256/512. > > 2. Once the buffer is full, do crazy "take pages out of the balloon > action" and report them to the hypervisor via virtio. Let the VCPU > continue. This will require some memory to store the request. Small > hickup for the VCPU to kick of the reporting to the hypervisor. > > 3. On interrupt/response, go over the response and put the pages back to > the buddy. > > (assuming that reporting a bulk of frees is better than reporting every > single free obviously) > > This could allow nice things like "when OOM gets trigger, see if pages > are currently being reported and wait until they have been put back to > the buddy, return "new pages available", so in a real "low on memory" > scenario, no OOM killer would get involved. This could address the issue > Wei had with reporting when low on memory. > > Is that something you have in mind? Yes that seems more future proof I think. > I assume we would have to allocate > memory when crafting the new requests. This is the only reason I tend to > prefer a synchronous interface for now. But if allocation is not a > problem, great. There are two main ways to avoid allocation: 1. do not add extra data on top of each chunk passed >>> If I am not wrong then this is close to what we have right now. >> >> Yes, minus the kthread(s) and eventually with some sort of memory >> allocation for the request. Once you're asynchronous via a notification >> mechanisnm, there is no real need for a thread
Allwinner SID THS calibration data cell representation?
Sorry for resurrecting an old discussion, but since someone posted patches
for H5 and H6, I thought we should resolve this. I'm working on patches to
fix / replace the big-endian issue.
On Thu, Sep 6, 2018 at 7:51 PM Maxime Ripard wrote:
>
> On Thu, Sep 06, 2018 at 01:47:47PM +0200, Philipp Rossak wrote:
> > On 04.09.2018 18:46, Emmanuel Vadot wrote:
> > > > + /* Data cells */
> > > > + thermal_calibration: calib@234 {
> > > > + reg = <0x234 0x8>;
> > > > + };
> > > You are declaring 8 bytes of calibration data but to my knowledge it's
> > > only 2 bytes per sensor, so 2 bytes for H3.
> > > Am I missing something ?
> > >
> > > Thanks,
> >
> > Emmanuel you are right, it is 2 bytes per Sensor and should be 2 bytes for
> > H3, but the thermal calibration data field is on all chips 64 bit wide - so
> > 8 bytes. So I'm reading here the complete calibration data field.
>
> Having one cell per channel would make more sense I guess.
Would it? The 2 32-bit words directly map onto the registers 0x74 / 0x78 in
the THS. As far as the SID is concerned, their is just one consumer for this
data, the thermal sensor. How the thermal sensor uses that data is really not
its concern. And the thermal sensor is really just copying the data from the
e-fuses into its registers. Nothing more.
Furthermore, with the register access interface, the e-fuses are read/write
32 bits at a time. Seems to me it would make more sense to enforce a 32-bit
word size, so cells should be multiples of 32 bits.
Regards
ChenYu
[PATCH] x86/boot/compressed/64: Do not read legacy ROM on EFI system
EFI systems may not provide legacy ROM. The memory may not be mapped
at all.
Trying to dereference values in legacy ROM leads to crash on Macbook
Pro.
Only look for values in the legacy ROM for non-EFI system.
Signed-off-by: Kirill A. Shutemov
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202351
Fixes: 3548e131ec6a ("x86/boot/compressed/64: Find a place for 32-bit
trampoline")
Reported-by: Pitam Mitra
Tested-by: Bockjoo Kim
---
arch/x86/boot/compressed/pgtable_64.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/x86/boot/compressed/pgtable_64.c
b/arch/x86/boot/compressed/pgtable_64.c
index 9e2157371491..f8debf7aeb4c 100644
--- a/arch/x86/boot/compressed/pgtable_64.c
+++ b/arch/x86/boot/compressed/pgtable_64.c
@@ -1,5 +1,7 @@
+#include
#include
#include
+#include
#include "pgtable.h"
#include "../string.h"
@@ -37,9 +39,10 @@ int cmdline_find_option_bool(const char *option);
static unsigned long find_trampoline_placement(void)
{
- unsigned long bios_start, ebda_start;
+ unsigned long bios_start = 0, ebda_start = 0;
unsigned long trampoline_start;
struct boot_e820_entry *entry;
+ char *signature;
int i;
/*
@@ -47,8 +50,18 @@ static unsigned long find_trampoline_placement(void)
* This code is based on reserve_bios_regions().
*/
- ebda_start = *(unsigned short *)0x40e << 4;
- bios_start = *(unsigned short *)0x413 << 10;
+ /*
+* EFI systems may not provide legacy ROM. The memory may not be mapped
+* at all.
+*
+* Only look for values in the legacy ROM for non-EFI system.
+*/
+ signature = (char *)_params->efi_info.efi_loader_signature;
+ if (strncmp(signature, EFI32_LOADER_SIGNATURE, 4) &&
+ strncmp(signature, EFI64_LOADER_SIGNATURE, 4)) {
+ ebda_start = *(unsigned short *)0x40e << 4;
+ bios_start = *(unsigned short *)0x413 << 10;
+ }
if (bios_start < BIOS_START_MIN || bios_start > BIOS_START_MAX)
bios_start = BIOS_START_MAX;
--
2.20.1
[PATCH 8/8] drm/i915/gvt: VFIO device states interfaces
This patch registers 3 VFIO device state regiones of type
VFIO_REGION_TYPE_DEVICE_STATE, and subtype
VFIO_REGION_SUBTYPE_DEVICE_STATE_CTL,
VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_CONFIG,
VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_DIRTYBITMAP.
userspace VFIO will check the existence of those regions to get/set
vGPU's device states.
region of subtype VFIO_REGION_SUBTYPE_DEVICE_STATE_CTL is the control
region, its layout is defined in struct vfio_device_state_ctl.
Reading from userspace into this region will get device state interace's
version and device data caps.
As Intel vGPU does not have device memory, so it does not support cap
VFIO_DEVICE_DATA_CAP_DEVICE_MEMORY.
But Intel vGPU will produce dirty page in system memory, cap
VFIO_DEVICE_DATA_CAP_SYSTEM_MEMORY is reported.
through writing to the control region, vGPU's state can also be set to
one of VFIO_DEVICE_STATE_RUNNING, VFIO_DEVICE_STATE_STOP,
VFIO_DEVICE_STATE_RUNNING & VFIO_DEVICE_STATE_LOGGING,
VFIO_DEVICE_STATE_STOP & VFIO_DEVICE_STATE_LOGGING.
state VFIO_DEVICE_STATE_LOGGING is set to notify logging dirty page in
system memory, but since vGPU's dirty page logging now is implemented by
cache of dma pages for guest gfns in vggtt and ppgtt,
nothing special needs to be done in the two LOGGING states, like
start/stop logging threads...
vGPU's device config data (including vreg, vggtt, vcfg space, workloads,
ppgtt, execlist, which are saved/restored through gvt interface
intel_gvt_save_restore) is hold in region of subtype
VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_CONFIG.
This region is mmaped into userspace VFIO.
Therefore userspace VFIO's reading from this config data
region requires it first write GET_BUFFER to device_config.action in the
above control region, so that GVT can load config data of vGPU into
config data region first;
And after userspace VFIO's writing to config data region, SET_BUFFER
is also needed to write to device_config.action in control region, so
GVT can restore config data into vGPU.
(Also, if device config data region failed to be mmaped into userspace
VFIO, read/write handlers are also provided).
vGPU's region for dirty bitmap logging in system memory is of subtype
VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_DIRTYBITMAP. It's also mmaped into
userspace VFIO. By writing start_addr and page count of a range of
system memory, dirty pages' bitmap produced by vGPU is saved in this
region dirty bitmap. Userspace VFIO can directly read dirty bitmap from
mmaped region or through this region's read/write handlers.
Signed-off-by: Yan Zhao
Signed-off-by: Kevin Tian
Signed-off-by: Yulei Zhang
---
drivers/gpu/drm/i915/gvt/gvt.h | 3 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 412 +--
include/uapi/linux/vfio.h| 38 +++
3 files changed, 437 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index cfde510e9d77..b0580169f595 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -227,6 +227,9 @@ struct intel_vgpu {
struct work_struct release_work;
atomic_t released;
struct vfio_device *vfio_device;
+ struct vfio_device_state_ctl *state_ctl;
+ void *state_config;
+ void *state_bitmap;
} vdev;
#endif
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 223c67e87680..02df2ebaa3f4 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -65,6 +65,8 @@ struct intel_vgpu_regops {
size_t count, loff_t *ppos, bool iswrite);
void (*release)(struct intel_vgpu *vgpu,
struct vfio_region *region);
+ int (*mmap)(struct intel_vgpu *vgpu,
+ struct vm_area_struct *vma);
};
struct vfio_region {
@@ -414,7 +416,7 @@ static size_t intel_vgpu_reg_rw_opregion(struct intel_vgpu
*vgpu, char *buf,
count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
memcpy(buf, base + pos, count);
- return count;
+ return 0;
}
static void intel_vgpu_reg_release_opregion(struct intel_vgpu *vgpu,
@@ -427,6 +429,272 @@ static const struct intel_vgpu_regops
intel_vgpu_regops_opregion = {
.release = intel_vgpu_reg_release_opregion,
};
+static size_t set_device_state(struct intel_vgpu *vgpu, u32 state)
+{
+ int rc = 0;
+
+ switch (state) {
+ case VFIO_DEVICE_STATE_STOP:
+ intel_gvt_ops->vgpu_deactivate(vgpu);
+ break;
+ case VFIO_DEVICE_STATE_RUNNING:
+ intel_gvt_ops->vgpu_activate(vgpu);
+ break;
+ case VFIO_DEVICE_STATE_LOGGING | VFIO_DEVICE_STATE_RUNNING:
+ case VFIO_DEVICE_STATE_LOGGING | VFIO_DEVICE_STATE_STOP:
+ break;
+ default:
+ rc = -EFAULT;
+ }
+
+ return rc;
+}
+
+static void intel_vgpu_get_dirty_bitmap(struct intel_vgpu
Re: [RFC PATCH 0/5] MTD: Add Initial Hyperbus support
+Sergei and Mason who recently worked on an HyperFlash controller. On Tue, 19 Feb 2019 12:06:02 +0530 Vignesh R wrote: > Cypress HyperBus is Low Signal Count, High Performance Double Data Rate Bus > interface between a host system master and one or more slave interfaces. > HyperBus is used to connect microprocessor, microcontroller, or ASIC > devices with random access NOR flash memory(called HyperFlash) or > self refresh DRAM(called HyperRAM). > > Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) > signal and either Single-ended clock(3.0V parts) or Differential clock > (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. > At bus level, it follows a separate protocol described in HyperBus > specification[1]. > > HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar > to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, > its equivalent to x16 parallel NOR flash wrt bits per clk. But Hyperbus > operates at >166MHz frequencies. > HyperRAM provides direct random read/write access to flash memory > array. > Framework is modelled along the lines of spi-nor framework. HyperBus > memory controller(HBMC) drivers call hb_register_device() to register a > single HyperFlash device. HyperFlash core parses MMIO access > information from DT, sets up the map_info struct, probes CFI flash and > registers it with MTD framework. > > This is an early RFC, to know if its okay to use maps framework and existing > CFI compliant flash support code to support Hyperflash > Also would like input on different types of HBMC master IPs out there > and their programming sequences. > Would appreciate any testing/review. > > Tested on modified TI AM654 EVM with Cypress Hyperflash S26KS512 by > creating a UBIFS partition and writing and reading files to it. > Stress tested by writing/reading 16MB flash repeatedly at different > offsets using dd commmand. > > HyperBus specification can be found at[1] > HyperFlash datasheet can be found at[2] > TI's HBMC controller details at[3] > > [1] https://www.cypress.com/file/213356/download > [2] https://www.cypress.com/file/213346/download > [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > Table 12-5741. HyperFlash Access Sequence > > Vignesh R (5): > mtd: cfi_cmdset_0002: Add support for polling status register > dt-bindings: mtd: Add binding documentation for Hyperbus memory > devices > mtd: Add support for Hyperbus memory devices > dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory > controller > mtd: hyperbus: Add driver for TI's Hyperbus memory controller > > .../bindings/mtd/cypress,hyperbus.txt | 6 + > .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++ > MAINTAINERS | 8 + > drivers/mtd/Kconfig | 2 + > drivers/mtd/Makefile | 1 + > drivers/mtd/chips/cfi_cmdset_0002.c | 50 ++ > drivers/mtd/hyperbus/Kconfig | 23 +++ > drivers/mtd/hyperbus/Makefile | 4 + > drivers/mtd/hyperbus/core.c | 167 ++ > drivers/mtd/hyperbus/hbmc_am654.c | 105 +++ > include/linux/mtd/cfi.h | 5 + > include/linux/mtd/hyperbus.h | 73 > 12 files changed, 471 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt > create mode 100644 drivers/mtd/hyperbus/Kconfig > create mode 100644 drivers/mtd/hyperbus/Makefile > create mode 100644 drivers/mtd/hyperbus/core.c > create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c > create mode 100644 include/linux/mtd/hyperbus.h >
[PATCH 7/8] drm/i915/gvt: vGPU device config data save/restore interface
The patch implments the gvt interface intel_gvt_save_restore to
save/restore vGPU's device config data for live migration.
vGPU device config data includes vreg, vggtt, vcfg space, workloads, ppgtt,
execlist.
It does not include dirty pages in system memory produced by vGPU.
Signed-off-by: Yulei Zhang
Signed-off-by: Xiao Zheng
Signed-off-by: Zhenyu Wang
Signed-off-by: Yan Zhao
---
drivers/gpu/drm/i915/gvt/Makefile | 2 +-
drivers/gpu/drm/i915/gvt/execlist.c | 2 +-
drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
drivers/gpu/drm/i915/gvt/gtt.h | 3 +
drivers/gpu/drm/i915/gvt/gvt.c | 1 +
drivers/gpu/drm/i915/gvt/gvt.h | 9 +
drivers/gpu/drm/i915/gvt/migrate.c | 863
drivers/gpu/drm/i915/gvt/migrate.h | 97
drivers/gpu/drm/i915/gvt/mmio.c | 13 +
drivers/gpu/drm/i915/gvt/mmio.h | 1 +
drivers/gpu/drm/i915/gvt/vgpu.c | 1 +
11 files changed, 991 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/migrate.c
create mode 100644 drivers/gpu/drm/i915/gvt/migrate.h
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index b016dc753db9..f863fbed1792 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -3,7 +3,7 @@ GVT_DIR := gvt
GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o
debugfs.o \
- fb_decoder.o dmabuf.o page_track.o
+ fb_decoder.o dmabuf.o page_track.o migrate.o
ccflags-y += -I$(src) -I$(src)/$(GVT_DIR)
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c
b/drivers/gpu/drm/i915/gvt/execlist.c
index 70494e394d2c..992e2260eec9 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -437,7 +437,7 @@ static int complete_execlist_workload(struct
intel_vgpu_workload *workload)
return ret;
}
-static int submit_context(struct intel_vgpu *vgpu, int ring_id,
+int submit_context(struct intel_vgpu *vgpu, int ring_id,
struct execlist_ctx_descriptor_format *desc,
bool emulate_schedule_in)
{
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 753ad975c958..18e3f08b0553 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -589,7 +589,7 @@ static inline void ppgtt_set_shadow_root_entry(struct
intel_vgpu_mm *mm,
_ppgtt_set_root_entry(mm, entry, index, false);
}
-static void ggtt_get_guest_entry(struct intel_vgpu_mm *mm,
+void ggtt_get_guest_entry(struct intel_vgpu_mm *mm,
struct intel_gvt_gtt_entry *entry, unsigned long index)
{
struct intel_gvt_gtt_pte_ops *pte_ops = mm->vgpu->gvt->gtt.pte_ops;
diff --git a/drivers/gpu/drm/i915/gvt/gtt.h b/drivers/gpu/drm/i915/gvt/gtt.h
index d8cb04cc946d..73709768b666 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.h
+++ b/drivers/gpu/drm/i915/gvt/gtt.h
@@ -270,6 +270,9 @@ struct intel_vgpu_mm *intel_vgpu_get_ppgtt_mm(struct
intel_vgpu *vgpu,
int intel_vgpu_put_ppgtt_mm(struct intel_vgpu *vgpu, u64 pdps[]);
+void ggtt_get_guest_entry(struct intel_vgpu_mm *mm,
+ struct intel_gvt_gtt_entry *entry, unsigned long index);
+
int intel_vgpu_emulate_ggtt_mmio_read(struct intel_vgpu *vgpu,
unsigned int off, void *p_data, unsigned int bytes);
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 733a2a0d0c30..3dd9e4ebd39b 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -185,6 +185,7 @@ static const struct intel_gvt_ops intel_gvt_ops = {
.vgpu_query_plane = intel_vgpu_query_plane,
.vgpu_get_dmabuf = intel_vgpu_get_dmabuf,
.write_protect_handler = intel_vgpu_page_track_handler,
+ .vgpu_save_restore = intel_gvt_save_restore,
};
/**
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 1f5ef59a36ac..cfde510e9d77 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -46,6 +46,7 @@
#include "sched_policy.h"
#include "mmio_context.h"
#include "cmd_parser.h"
+#include "migrate.h"
#include "fb_decoder.h"
#include "dmabuf.h"
#include "page_track.h"
@@ -510,6 +511,8 @@ void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu,
bool dmlr,
void intel_gvt_reset_vgpu(struct intel_vgpu *vgpu);
void intel_gvt_activate_vgpu(struct intel_vgpu *vgpu);
void intel_gvt_deactivate_vgpu(struct intel_vgpu *vgpu);
+int intel_gvt_save_restore(struct intel_vgpu *vgpu, char *buf,
+ size_t count, void *base, uint64_t off, bool restore);
/* validating GM functions */
#define vgpu_gmadr_is_aperture(vgpu, gmadr) \
@@ -609,6 +612,9 @@ struct intel_gvt_ops {
int
[PATCH 6/8] drm/i915/gvt: Apply g2h adjustment to buffer start gma for dmabuf
From: Yulei Zhang Adjust the buffer start gma in dmabuf for display in host domain. Signed-off-by: Yulei Zhang --- drivers/gpu/drm/i915/gvt/dmabuf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c b/drivers/gpu/drm/i915/gvt/dmabuf.c index 51ed99a37803..e96c655c40bc 100644 --- a/drivers/gpu/drm/i915/gvt/dmabuf.c +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c @@ -293,6 +293,9 @@ static int vgpu_get_plane_info(struct drm_device *dev, return -EFAULT; } + /* Apply g2h adjust to buffer start gma for display */ + intel_gvt_ggtt_gmadr_g2h(vgpu, info->start, >start); + return 0; } -- 2.17.1
[PATCH 5/8] drm/i915/gvt: Align the guest gm aperture start offset for live migration
From: Yulei Zhang
As guest gm aperture region start offset is initialized when vGPU created,
in order to make sure that start offset is remain the same after migration,
align the aperture start offset to 0 for guest.
Signed-off-by: Yulei Zhang
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +--
drivers/gpu/drm/i915/gvt/vgpu.c | 10 --
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index c1072143da1d..223c67e87680 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1198,8 +1198,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
sparse->header.version = 1;
sparse->nr_areas = nr_areas;
cap_type_id = VFIO_REGION_INFO_CAP_SPARSE_MMAP;
- sparse->areas[0].offset =
- PAGE_ALIGN(vgpu_aperture_offset(vgpu));
+ sparse->areas[0].offset = 0;
sparse->areas[0].size = vgpu_aperture_sz(vgpu);
break;
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index c628be05fbfe..fcccda35a456 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -48,8 +48,7 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_HWSP_EMULATION;
vgpu_vreg_t(vgpu, vgtif_reg(vgt_caps)) |= VGT_CAPS_HUGE_GTT;
- vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base)) =
- vgpu_aperture_gmadr_base(vgpu);
+ vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base)) = 0;
vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.size)) =
vgpu_aperture_sz(vgpu);
vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.nonmappable_gmadr.base)) =
@@ -524,6 +523,9 @@ void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu,
bool dmlr,
{
struct intel_gvt *gvt = vgpu->gvt;
struct intel_gvt_workload_scheduler *scheduler = >scheduler;
+ u64 maddr = vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base));
+ u64 unmaddr = vgpu_vreg_t(vgpu,
+ vgtif_reg(avail_rs.nonmappable_gmadr.base));
unsigned int resetting_eng = dmlr ? ALL_ENGINES : engine_mask;
gvt_dbg_core("--\n");
@@ -556,6 +558,10 @@ void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu,
bool dmlr,
intel_vgpu_reset_mmio(vgpu, dmlr);
populate_pvinfo_page(vgpu);
+ vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base)) =
+ maddr;
+ vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.nonmappable_gmadr.base)) =
+ unmaddr;
intel_vgpu_reset_display(vgpu);
if (dmlr) {
--
2.17.1
[PATCH 4/8] drm/i915/gvt: Retrieve the guest gm base address from PVINFO
From: Yulei Zhang
As after migration the host gm base address will be changed due
to resource re-allocation, in order to make sure the guest gm
address doesn't change with that to retrieve the guest gm base
address from PVINFO.
Signed-off-by: Yulei Zhang
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/cfg_space.c | 3 ++-
drivers/gpu/drm/i915/gvt/gtt.c | 8
drivers/gpu/drm/i915/gvt/gvt.h | 22 ++
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index 19cf1bbe059d..272f8dba7b21 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -33,6 +33,7 @@
#include "i915_drv.h"
#include "gvt.h"
+#include "i915_pvinfo.h"
enum {
INTEL_GVT_PCI_BAR_GTTMMIO = 0,
@@ -133,7 +134,7 @@ static int map_aperture(struct intel_vgpu *vgpu, bool map)
else
val = *(u32 *)(vgpu_cfg_space(vgpu) + PCI_BASE_ADDRESS_2);
- first_gfn = (val + vgpu_aperture_offset(vgpu)) >> PAGE_SHIFT;
+ first_gfn = (val + vgpu_guest_aperture_offset(vgpu)) >> PAGE_SHIFT;
ret = intel_gvt_hypervisor_map_gfn_to_mfn(vgpu, first_gfn,
aperture_pa >> PAGE_SHIFT,
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 8a5d26d1d402..753ad975c958 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -70,10 +70,10 @@ int intel_gvt_ggtt_gmadr_g2h(struct intel_vgpu *vgpu, u64
g_addr, u64 *h_addr)
if (vgpu_gmadr_is_aperture(vgpu, g_addr))
*h_addr = vgpu_aperture_gmadr_base(vgpu)
- + (g_addr - vgpu_aperture_offset(vgpu));
+ + (g_addr - vgpu_guest_aperture_gmadr_base(vgpu));
else
*h_addr = vgpu_hidden_gmadr_base(vgpu)
- + (g_addr - vgpu_hidden_offset(vgpu));
+ + (g_addr - vgpu_guest_hidden_gmadr_base(vgpu));
return 0;
}
@@ -85,10 +85,10 @@ int intel_gvt_ggtt_gmadr_h2g(struct intel_vgpu *vgpu, u64
h_addr, u64 *g_addr)
return -EACCES;
if (gvt_gmadr_is_aperture(vgpu->gvt, h_addr))
- *g_addr = vgpu_aperture_gmadr_base(vgpu)
+ *g_addr = vgpu_guest_aperture_gmadr_base(vgpu)
+ (h_addr - gvt_aperture_gmadr_base(vgpu->gvt));
else
- *g_addr = vgpu_hidden_gmadr_base(vgpu)
+ *g_addr = vgpu_guest_hidden_gmadr_base(vgpu)
+ (h_addr - gvt_hidden_gmadr_base(vgpu->gvt));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 8621d0f5fd26..1f5ef59a36ac 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -424,6 +424,20 @@ int intel_gvt_load_firmware(struct intel_gvt *gvt);
#define vgpu_fence_base(vgpu) (vgpu->fence.base)
#define vgpu_fence_sz(vgpu) (vgpu->fence.size)
+/* Aperture/GM space definitions for vGPU Guest view point */
+#define vgpu_guest_aperture_offset(vgpu) \
+ vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.mappable_gmadr.base))
+#define vgpu_guest_hidden_offset(vgpu) \
+ vgpu_vreg_t(vgpu, vgtif_reg(avail_rs.nonmappable_gmadr.base))
+
+#define vgpu_guest_aperture_gmadr_base(vgpu) (vgpu_guest_aperture_offset(vgpu))
+#define vgpu_guest_aperture_gmadr_end(vgpu) \
+ (vgpu_guest_aperture_gmadr_base(vgpu) + vgpu_aperture_sz(vgpu) - 1)
+
+#define vgpu_guest_hidden_gmadr_base(vgpu) (vgpu_guest_hidden_offset(vgpu))
+#define vgpu_guest_hidden_gmadr_end(vgpu) \
+ (vgpu_guest_hidden_gmadr_base(vgpu) + vgpu_hidden_sz(vgpu) - 1)
+
struct intel_vgpu_creation_params {
__u64 handle;
__u64 low_gm_sz; /* in MB */
@@ -499,12 +513,12 @@ void intel_gvt_deactivate_vgpu(struct intel_vgpu *vgpu);
/* validating GM functions */
#define vgpu_gmadr_is_aperture(vgpu, gmadr) \
- ((gmadr >= vgpu_aperture_gmadr_base(vgpu)) && \
-(gmadr <= vgpu_aperture_gmadr_end(vgpu)))
+ ((gmadr >= vgpu_guest_aperture_gmadr_base(vgpu)) && \
+(gmadr <= vgpu_guest_aperture_gmadr_end(vgpu)))
#define vgpu_gmadr_is_hidden(vgpu, gmadr) \
- ((gmadr >= vgpu_hidden_gmadr_base(vgpu)) && \
-(gmadr <= vgpu_hidden_gmadr_end(vgpu)))
+ ((gmadr >= vgpu_guest_hidden_gmadr_base(vgpu)) && \
+(gmadr <= vgpu_guest_hidden_gmadr_end(vgpu)))
#define vgpu_gmadr_is_valid(vgpu, gmadr) \
((vgpu_gmadr_is_aperture(vgpu, gmadr) || \
--
2.17.1
[PATCH 2/8] drm/i915/gvt: Apply g2h adjustment during fence mmio access
From: Yulei Zhang
Apply the guest to host gma conversion while guest config the
fence mmio registers due to the host gma change after the migration.
Signed-off-by: Yulei Zhang
---
drivers/gpu/drm/i915/gvt/aperture_gm.c | 6 --
drivers/gpu/drm/i915/gvt/gvt.h | 14 ++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index 359d37d5c958..123c475f2f6e 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -146,8 +146,10 @@ void intel_vgpu_write_fence(struct intel_vgpu *vgpu,
I915_WRITE(fence_reg_lo, 0);
POSTING_READ(fence_reg_lo);
- I915_WRITE(fence_reg_hi, upper_32_bits(value));
- I915_WRITE(fence_reg_lo, lower_32_bits(value));
+ I915_WRITE(fence_reg_hi,
+ intel_gvt_reg_g2h(vgpu, upper_32_bits(value), 0xF000));
+ I915_WRITE(fence_reg_lo,
+ intel_gvt_reg_g2h(vgpu, lower_32_bits(value), 0xF000));
POSTING_READ(fence_reg_lo);
}
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index b4ab1dad0143..8621d0f5fd26 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -530,6 +530,20 @@ int intel_gvt_ggtt_index_g2h(struct intel_vgpu *vgpu,
unsigned long g_index,
int intel_gvt_ggtt_h2g_index(struct intel_vgpu *vgpu, unsigned long h_index,
unsigned long *g_index);
+/* apply guest to host gma conversion in GM registers setting */
+static inline u64 intel_gvt_reg_g2h(struct intel_vgpu *vgpu,
+ u32 addr, u32 mask)
+{
+ u64 gma;
+
+ if (addr) {
+ intel_gvt_ggtt_gmadr_g2h(vgpu,
+ addr & mask, );
+ addr = gma | (addr & (~mask));
+ }
+ return addr;
+}
+
void intel_vgpu_init_cfg_space(struct intel_vgpu *vgpu,
bool primary);
void intel_vgpu_reset_cfg_space(struct intel_vgpu *vgpu);
--
2.17.1
[PATCH 3/8] drm/i915/gvt: Patch the gma in gpu commands during command parser
From: Yulei Zhang
Adjust the graphics memory address in gpu commands according to
the shift offset in guests' aperture and hidden gm address, and patch
the commands before submit to execute.
Signed-off-by: Yulei Zhang
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 31 ---
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 77ae634eb11c..90836756b235 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -984,7 +984,8 @@ static int cmd_handler_lrr(struct parser_exec_state *s)
}
static inline int cmd_address_audit(struct parser_exec_state *s,
- unsigned long guest_gma, int op_size, bool index_mode);
+ unsigned long guest_gma, int op_size,
+ bool index_mode, int offset);
static int cmd_handler_lrm(struct parser_exec_state *s)
{
@@ -1006,7 +1007,8 @@ static int cmd_handler_lrm(struct parser_exec_state *s)
gma = cmd_gma(s, i + 1);
if (gmadr_bytes == 8)
gma |= (cmd_gma_hi(s, i + 2)) << 32;
- ret |= cmd_address_audit(s, gma, sizeof(u32), false);
+ ret |= cmd_address_audit(s, gma, sizeof(u32),
+false, i + 1);
if (ret)
break;
}
@@ -1030,7 +1032,8 @@ static int cmd_handler_srm(struct parser_exec_state *s)
gma = cmd_gma(s, i + 1);
if (gmadr_bytes == 8)
gma |= (cmd_gma_hi(s, i + 2)) << 32;
- ret |= cmd_address_audit(s, gma, sizeof(u32), false);
+ ret |= cmd_address_audit(s, gma, sizeof(u32),
+false, i + 1);
if (ret)
break;
}
@@ -1102,7 +1105,7 @@ static int cmd_handler_pipe_control(struct
parser_exec_state *s)
if (cmd_val(s, 1) & (1 << 21))
index_mode = true;
ret |= cmd_address_audit(s, gma, sizeof(u64),
- index_mode);
+ index_mode, 2);
}
}
}
@@ -1432,10 +1435,13 @@ static unsigned long get_gma_bb_from_cmd(struct
parser_exec_state *s, int index)
}
static inline int cmd_address_audit(struct parser_exec_state *s,
- unsigned long guest_gma, int op_size, bool index_mode)
+ unsigned long guest_gma, int op_size,
+ bool index_mode, int offset)
{
struct intel_vgpu *vgpu = s->vgpu;
u32 max_surface_size = vgpu->gvt->device_info.max_surface_size;
+ int gmadr_bytes = vgpu->gvt->device_info.gmadr_bytes_in_cmd;
+ u64 host_gma;
int i;
int ret;
@@ -1453,6 +1459,14 @@ static inline int cmd_address_audit(struct
parser_exec_state *s,
} else if (!intel_gvt_ggtt_validate_range(vgpu, guest_gma, op_size)) {
ret = -EFAULT;
goto err;
+ } else
+ intel_gvt_ggtt_gmadr_g2h(vgpu, guest_gma, _gma);
+
+ if (offset > 0) {
+ patch_value(s, cmd_ptr(s, offset), host_gma & GENMASK(31, 2));
+ if (gmadr_bytes == 8)
+ patch_value(s, cmd_ptr(s, offset + 1),
+ (host_gma >> 32) & GENMASK(15, 0));
}
return 0;
@@ -1497,7 +1511,7 @@ static int cmd_handler_mi_store_data_imm(struct
parser_exec_state *s)
gma = (gma_high << 32) | gma_low;
core_id = (cmd_val(s, 1) & (1 << 0)) ? 1 : 0;
}
- ret = cmd_address_audit(s, gma + op_size * core_id, op_size, false);
+ ret = cmd_address_audit(s, gma + op_size * core_id, op_size, false, 1);
return ret;
}
@@ -1541,7 +1555,7 @@ static int cmd_handler_mi_op_2f(struct parser_exec_state
*s)
gma_high = cmd_val(s, 2) & GENMASK(15, 0);
gma = (gma_high << 32) | gma;
}
- ret = cmd_address_audit(s, gma, op_size, false);
+ ret = cmd_address_audit(s, gma, op_size, false, 1);
return ret;
}
@@ -1581,7 +1595,8 @@ static int cmd_handler_mi_flush_dw(struct
parser_exec_state *s)
/* Store Data Index */
if (cmd_val(s, 0) & (1 << 21))
index_mode = true;
- ret = cmd_address_audit(s, gma, sizeof(u64), index_mode);
+ ret = cmd_address_audit(s, (gma | (1 << 2)),
+ sizeof(u64), index_mode, 1);
}
/* Check notify bit */
if
[PATCH 1/8] drm/i915/gvt: Apply g2h adjust for GTT mmio access
From: Yulei Zhang
Apply guest to host gma conversion while guest try to access the
GTT mmio registers, as after enable live migration the host gma
will be changed due to the resourece re-allocation, but guest
gma should be remaining unchanged, thus g2h conversion is request
for it.
Signed-off-by: Yulei Zhang
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/gtt.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index c7103dd2d8d5..8a5d26d1d402 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -65,8 +65,7 @@ bool intel_gvt_ggtt_validate_range(struct intel_vgpu *vgpu,
u64 addr, u32 size)
/* translate a guest gmadr to host gmadr */
int intel_gvt_ggtt_gmadr_g2h(struct intel_vgpu *vgpu, u64 g_addr, u64 *h_addr)
{
- if (WARN(!vgpu_gmadr_is_valid(vgpu, g_addr),
-"invalid guest gmadr %llx\n", g_addr))
+ if (!vgpu_gmadr_is_valid(vgpu, g_addr))
return -EACCES;
if (vgpu_gmadr_is_aperture(vgpu, g_addr))
@@ -2162,7 +2161,8 @@ static int emulate_ggtt_mmio_write(struct intel_vgpu
*vgpu, unsigned int off,
struct intel_vgpu_mm *ggtt_mm = vgpu->gtt.ggtt_mm;
struct intel_gvt_gtt_pte_ops *ops = gvt->gtt.pte_ops;
unsigned long g_gtt_index = off >> info->gtt_entry_size_shift;
- unsigned long gma, gfn;
+ unsigned long gfn;
+ unsigned long h_gtt_index;
struct intel_gvt_gtt_entry e, m;
dma_addr_t dma_addr;
int ret;
@@ -2172,10 +2172,8 @@ static int emulate_ggtt_mmio_write(struct intel_vgpu
*vgpu, unsigned int off,
if (bytes != 4 && bytes != 8)
return -EINVAL;
- gma = g_gtt_index << I915_GTT_PAGE_SHIFT;
-
/* the VM may configure the whole GM space when ballooning is used */
- if (!vgpu_gmadr_is_valid(vgpu, gma))
+ if (intel_gvt_ggtt_index_g2h(vgpu, g_gtt_index, _gtt_index))
return 0;
e.type = GTT_TYPE_GGTT_PTE;
@@ -2259,11 +2257,12 @@ static int emulate_ggtt_mmio_write(struct intel_vgpu
*vgpu, unsigned int off,
out:
ggtt_set_guest_entry(ggtt_mm, , g_gtt_index);
- ggtt_get_host_entry(ggtt_mm, , g_gtt_index);
+ ggtt_get_host_entry(ggtt_mm, , h_gtt_index);
ggtt_invalidate_pte(vgpu, );
- ggtt_set_host_entry(ggtt_mm, , g_gtt_index);
+ ggtt_set_host_entry(ggtt_mm, , h_gtt_index);
ggtt_invalidate(gvt->dev_priv);
+
return 0;
}
--
2.17.1
[PATCH 0/8] VFIO Device states interface in GVT
This patchset provides GVT vGPU with device states control and
interfaces to get/set device data.
Desgin of device state control and interfaces to get/set device data
CODE STRUCTURES
---
/* Device State region type and sub-type */
#define VFIO_REGION_TYPE_DEVICE_STATE (1 << 1)
#define VFIO_REGION_SUBTYPE_DEVICE_STATE_CTL (1)
#define VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_CONFIG (2)
#define VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_MEMORY (3)
#define VFIO_REGION_SUBTYPE_DEVICE_STATE_DATA_DIRTYBITMAP (4)
#define VFIO_DEVICE_STATE_INTERFACE_VERSION 1
#define VFIO_DEVICE_DATA_CAP_DEVICE_MEMORY 1
#define VFIO_DEVICE_DATA_CAP_SYSTEM_MEMORY 2
#define VFIO_DEVICE_STATE_RUNNING 0
#define VFIO_DEVICE_STATE_STOP 1
#define VFIO_DEVICE_STATE_LOGGING 2
#define VFIO_DEVICE_DATA_ACTION_GET_BUFFER 1
#define VFIO_DEVICE_DATA_ACTION_SET_BUFFER 2
struct vfio_device_state_ctl {
__u32 version;/* ro, version of device control interface*/
__u32 device_state; /* VFIO device state, wo */
__u32 caps; /* ro */
struct {
__u32 action; /* wo, GET_BUFFER or SET_BUFFER */
__u64 size;/*rw, total size of device config*/
} device_config;
struct {
__u32 action;/* wo, GET_BUFFER or SET_BUFFER */
__u64 size; /* rw, total size of device memory*/
__u64 pos;/*chunk offset in total buffer of device memory*/
} device_memory;
struct {
__u64 start_addr; /* wo */
__u64 page_nr; /* wo */
} system_memory;
};
DEVICE DATA
---
A VFIO device's data can be divided into 3 categories: device config,
device memory and system memory dirty pages.
Device Config: such kind of data like MMIOs, page tables...
Every device is supposed to possess device config data.
Usually the size of device config data is small (no big
than 10M), and it needs to be loaded in certain strict
order.
Therefore no dirty data logging is enabled for device
config and it must be got/set as a whole.
Device Memory: device's internal memory, standalone and outside system
memory. It is usually very big.
Not all device has device memory. Like IGD only uses system
memory and has no device memory.
System Memory Dirty Pages: A device can produce dirty pages in system
memory.
DEVICE STATE REGIONS
-
A VFIO device driver needs to register two mandatory regions and optionally
another two regions if it plans to support device state management.
So, there are up to four regions in total.
one is control region (region CTL) which is accessed via read/write system
call from user space;
the left three are data regions which are mmaped into user space and can be
accessed in the same way as accessing memory from user space.
(If data regions failed to be mmaped into user space, the way of read/write
system calls from user space is also valid).
1. region CTL:
Mandatory.
This is a control region.
Its layout is defined in struct vfio_device_state_ctl.
Reading from this region can get version, capabilities and data
size of device state interfaces.
Writing to this region can set device state, data size and
choose which interface to use, i.e, among
"get device config buffer", "set device config buffer",
"get device memory buffer", "set device memory buffer",
"get system memory dirty bitmap".
2. region DEVICE_CONFIG
Mandatory.
This is a data region that holds device config data.
It is able to be mmaped into user space.
3. region DEVICE_MEMORY
Optional.
This is a data region that holds device memory data.
It is able to be mmaped into user space.
4. region DIRTY_BITMAP
Optional.
This is a data region that holds bitmap of dirty pages in system
memory that a VFIO devices produces.
It is able to be mmaped into user space.
DEVICE STATES
-
Four states are defined for a VFIO device:
RUNNING, RUNNING & LOGGING, STOP & LOGGING, STOP.
They can be set by writing to device_state field of vfio_device_state_ctl
region.
LOGGING state is a special state that it CANNOT exist independently.
It must be set alongside with state RUNNING or STOP, i.e,
RUNNING & LOGGING, STOP & LOGGING
It is used for dirty data logging both for device memory and system memory.
LOGGING only impacts device/system memory.
Device config should be always accessible and return whole config snapshot
regardless of LOGGING state.
Typical state transition flows for VFIO devices are:
(a) RUNNING --> RUNNING & LOGGING -->
Re: [PATCH -next] usb: typec: mux: Fix unsigned comparison with less than zero
On Tue, Feb 19, 2019 at 02:57:50PM +0800, YueHaibing wrote:
> The return from the call to fwnode_property_read_u16_array is int,
> it can be a negative error code however this is being assigned to
> an size_t variable 'nval', hence the check is always false.
> Fix this by making 'nval' an int.
>
> Detected by Coccinelle ("Unsigned expression compared with
> zero: nval < 0")
>
> Fixes: 96a6d031ca99 ("usb: typec: mux: Find the muxes by also matching
> against the device node")
> Signed-off-by: YueHaibing
Acked-by: Heikki Krogerus
> ---
> drivers/usb/typec/mux.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
> index a5947d9..54d7497 100644
> --- a/drivers/usb/typec/mux.c
> +++ b/drivers/usb/typec/mux.c
> @@ -126,7 +126,7 @@ static void *typec_mux_match(struct device_connection
> *con, int ep, void *data)
> {
> const struct typec_altmode_desc *desc = data;
> struct typec_mux *mux;
> - size_t nval;
> + int nval;
> bool match;
> u16 *val;
> int i;
thanks,
--
heikki
[PATCH 1/1] of: reserved_mem: fix reserve memory leak
The __reserved_mem_init_node will call region specific reserved memory
init codes, but once all compatibled init codes failed, the memory region
will left in memory.reserved and cause leakage.
Take cma reserve memory DTS for example, if user declare 1MB size,
which is not align to (PAGE_SIZE << max(MAX_ORDER - 1,
pageblock_order)), rmem_cma_setup will return -EINVAL.
Meanwhile, rmem_dma_setup will also return -EINVAL since "reusable"
property is not set. If finally there is no reserved memory init pick up
this memory, kernel will left the 1MB leak in memory.reserved.
This patch will remove this kind of memory from memory.reserved, only
when __reserved_mem_init_node return neither 0 nor -ENOENT.
Signed-off-by: pierre Kuo
---
drivers/of/of_reserved_mem.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0adcb1..d3bde057ec46 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -181,6 +181,7 @@ static int __init __reserved_mem_init_node(struct
reserved_mem *rmem)
{
extern const struct of_device_id __reservedmem_of_table[];
const struct of_device_id *i;
+ int ret = -ENOENT;
for (i = __reservedmem_of_table; i < &__rmem_of_table_sentinel; i++) {
reservedmem_of_init_fn initfn = i->data;
@@ -189,13 +190,14 @@ static int __init __reserved_mem_init_node(struct
reserved_mem *rmem)
if (!of_flat_dt_is_compatible(rmem->fdt_node, compat))
continue;
- if (initfn(rmem) == 0) {
+ ret = initfn(rmem);
+ if (ret == 0) {
pr_info("initialized node %s, compatible id %s\n",
rmem->name, compat);
- return 0;
+ break;
}
}
- return -ENOENT;
+ return ret;
}
static int __init __rmem_cmp(const void *a, const void *b)
@@ -255,7 +257,9 @@ void __init fdt_init_reserved_mem(void)
int len;
const __be32 *prop;
int err = 0;
+ int nomap;
+ nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
prop = of_get_flat_dt_prop(node, "phandle", );
if (!prop)
prop = of_get_flat_dt_prop(node, "linux,phandle", );
@@ -265,8 +269,16 @@ void __init fdt_init_reserved_mem(void)
if (rmem->size == 0)
err = __reserved_mem_alloc_size(node, rmem->name,
>base, >size);
- if (err == 0)
- __reserved_mem_init_node(rmem);
+ if (err == 0) {
+ err = __reserved_mem_init_node(rmem);
+ if (err != 0 && err != -ENOENT) {
+ pr_info("node %s compatible matching fail\n",
+ rmem->name);
+ memblock_free(rmem->base, rmem->size);
+ if (nomap)
+ memblock_add(rmem->base, rmem->size);
+ }
+ }
}
}
--
2.17.1
Re: [PATCH v7 5/6] arm64: dts: mt8183: add pintcrl file
On Fri, Feb 15, 2019 at 2:07 PM Erin Lo wrote: > Subject: [PATCH v7 5/6] arm64: dts: mt8183: add pintcrl file minor spelling mistake in the commit title: pinctrl > > This patch adds pinctrl file for mt8183. > > Signed-off-by: Zhiyong Tao > Signed-off-by: Erin Lo > ---
Re: linux-next: build failure after merge of the asm-generic tree
Hi Stephen, Arnd,
> After merging the asm-generic tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
> ...
> Caused by commit
>
> 8e074c243ed3 ("iomap: add missing const to ioread*/iowrite addr arg")
I have prepared a patch addressing this issue, and am currently building it
with a powerpc cross compiler. I'll submit it once it's done. Please tell
me if I should update the initial patch instead.
> The const qualifiers are also missing in:
>
> arch/parisc/lib/iomap.c
> arch/sh/kernel/iomap.c
I also have patches for these architectures, but it is more complicated for
me to test them with a cross compiler. Should I still submit them?
> I have reverted that commit for today.
>
> BTW, that commit only added the const to the ioread* functions ...
Yes, and it does not even make sense to add a const qualifier to the addr
argument in the iowrite case. That was a bad commit message.
Thanks, and sorry for the trouble.
regards,
Hugo
--
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
Re: [PATCH v2 5/8] arm64: dts: allwinner: Enable AXP803 CHGLED for Olimex boards
On 2/15/19 8:49 PM, Pavel Machek wrote:
On Fri 2019-02-15 13:50:10, Stefan Mavrodiev wrote:
Teres-I and A64-OLinuXino commes with populated LED connected
to AXP803. So to be used as battery indication, pass the LED control
to the charger itself in mode 0 ( FULL while charging, OFF no battery
or completed).
Signed-off-by: Stefan Mavrodiev
---
arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 6 ++
arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index f7a4bccaa5d4..7d6930319fba 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -177,6 +177,12 @@
#include "axp803.dtsi"
+_led {
+ label = "a64-olinuxino:yellow:chgled";
There's little chance userspace will recognize this led.
Can you make it "platform:yellow:charging" and fix it for other
boards, too?
Sure.
Best regards,
Stefan Mavrodiev
Pavel
Re: [PATCH v2 1/8] leds: Add support for AXP20X CHGLED
On 2/15/19 8:32 PM, Pavel Machek wrote:
Hi!
On Fri, Feb 15, 2019 at 01:50:06PM +0200, Stefan Mavrodiev wrote:
+static ssize_t control_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t size)
+{
+ struct led_classdev *cdev = dev_get_drvdata(dev);
+ struct axp20x_led *priv = to_axp20x_led(cdev);
+ unsigned long val;
+ int ret;
+
+ ret = kstrtoul(buf, 0, );
+ if (ret)
+ return ret;
+
+ /**
+* Supported values are:
+* - 0 : Manual control
+* - 1 : Charger control
+*/
...
+static struct attribute *axp20x_led_attrs[] = {
+ _attr_control.attr,
+ _attr_mode.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(axp20x_led);
I can't really say whether adding sysfs handles for this is the right
thing to do, but if it is you should document the interface.
It is not. See "Add Intel Cherry Trail Whiskey Cove PMIC LEDs" thread
in the last few days.
What I understood is that there will be changes in the LED core, exporting
a new sysfs entry "hw_control". Then I should set HW_CONTROL flag for the
device and add hw_control_get/set callback functions. And this can happen
when the LED core is updated. Right?
However I didn't understand how (in my case) hardware controlled pattern
will be selected?
Best regards,
Stefan Mavrodiev
+ if (!of_property_read_u8(np, "x-powers,charger-mode", )) {
+ priv->ctrl = AXP20X_CHGLED_CTRL_CHARGER;
+ priv->mode = (value < 2) ? value : 0;
+ } else {
+ priv->ctrl = AXP20X_CHGLED_CTRL_MANUAL;
+ }
I'm not sure we want to make this a property of the device
tree. Changing the device tree isn't an option for some users, so we
need to make sure we can change it even if we can't change the device
tree.
We want this to be configurable at run time. It can get default from
the device tree.
If we go for the "hardware" trigger, you'll get it for free.
Best regards,
Pavel
Re: [PATCH 2/4] pwm: atmel: add support for controllers with 32 bit counters
Hello Claudiu, On Mon, Jan 21, 2019 at 12:30:53PM +, claudiu.bez...@microchip.com wrote: > From: Claudiu Beznea > > New SAM9X60's PWM controller use 32 bits counters thus it could generate > signals with higher period and duty cycles. Update the current driver > to work with old controller (that uses 16 bits counters) and with the > new SAM9X60's controller. > > Signed-off-by: Claudiu Beznea > --- > drivers/pwm/pwm-atmel.c | 38 +++--- > 1 file changed, 27 insertions(+), 11 deletions(-) > > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c > index 7e86a5266eb6..44f4a1c9f60b 100644 > --- a/drivers/pwm/pwm-atmel.c > +++ b/drivers/pwm/pwm-atmel.c > @@ -48,15 +48,15 @@ > #define PWMV2_CPRD 0x0C > #define PWMV2_CPRDUPD0x10 > > -/* > - * Max value for duty and period > - * > - * Although the duty and period register is 32 bit, > - * however only the LSB 16 bits are significant. > - */ > -#define PWM_MAX_DTY 0x > -#define PWM_MAX_PRD 0x > -#define PRD_MAX_PRES 10 > +/* Max values for period and prescaler */ > + > +/* Only the LSB 16 bits are significant. */ > +#define PWM_MAXV1_PRD0x > + > +/* All 32 bits are significant. */ > +#define PWM_MAXV2_PRD0x This symbol is unused, so I wonder if the patch really does what the commit log promises. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v2 05/15] dt-bindings: timer: Add Milbeaut M10V timer description
Hi, On 2019/02/19 4:53, Rob Herring wrote: On Fri, 8 Feb 2019 21:26:30 +0900, Sugaya Taichi wrote: Add DT bindings document for Milbeaut M10V timer. Signed-off-by: Sugaya Taichi --- .../bindings/timer/socionext,milbeaut-timer.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt Reviewed-by: Rob Herring Thank you!
Re: [RFC PATCH 01/31] mm: migrate: Add exchange_pages to exchange two lists of pages.
On 02/18/2019 11:29 PM, Zi Yan wrote: > On 18 Feb 2019, at 9:52, Matthew Wilcox wrote: > >> On Mon, Feb 18, 2019 at 09:51:33AM -0800, Zi Yan wrote: >>> On 18 Feb 2019, at 9:42, Vlastimil Babka wrote: On 2/18/19 6:31 PM, Zi Yan wrote: > The purpose of proposing exchange_pages() is to avoid allocating any > new > page, > so that we would not trigger any potential page reclaim or memory > compaction. > Allocating a temporary page defeats the purpose. Compaction can only happen for order > 0 temporary pages. Even if you used single order = 0 page to gradually exchange e.g. a THP, it should be better than u64. Allocating order = 0 should be a non-issue. If it's an issue, then the system is in a bad state and physically contiguous layout is a secondary concern. >>> >>> You are right if we only need to allocate one order-0 page. But this also >>> means >>> we can only exchange two pages at a time. We need to add a lock to make sure >>> the temporary page is used exclusively or we need to keep allocating >>> temporary pages >>> when multiple exchange_pages() are happening at the same time. >> >> You allocate one temporary page per thread that's doing an exchange_page(). > > Yeah, you are right. I think at most I need NR_CPU order-0 pages. I will try > it. Thanks. But the location of this temp page matters as well because you would like to saturate the inter node interface. It needs to be either of the nodes where the source or destination page belongs. Any other node would generate two internode copy process which is not what you intend here I guess.
Re: [PATCH v2 03/15] dt-bindings: Add documentation for Milbeaut SoCs
Hi, On 2019/02/19 4:52, Rob Herring wrote: On Fri, Feb 08, 2019 at 09:26:04PM +0900, Sugaya Taichi wrote: This adds a DT binding documentation for the M10V and its evaluation board. Most boards/soc bindings are using DT schema (yaml) now. We're not requiring that just yet, but I'd like to not add more. So can you convert this to schema. Probably yes. I try to convert with looking at references. Thanks, Sugaya Taichi Rob Signed-off-by: Sugaya Taichi --- Documentation/devicetree/bindings/arm/milbeaut.txt | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/milbeaut.txt diff --git a/Documentation/devicetree/bindings/arm/milbeaut.txt b/Documentation/devicetree/bindings/arm/milbeaut.txt new file mode 100644 index 000..9fd053a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/milbeaut.txt @@ -0,0 +1,6 @@ +Milbeaut platforms device tree bindings +--- + +- Milbeaut M10V Evaluation Board +Required root node properties: + - compatible = "socionext,milbeaut-m10v-evb", "socionext,sc2000a"; -- 1.9.1
Re: [PATCH v2 01/15] dt-bindings: sram: milbeaut: Add binding for Milbeaut smp-sram
Hi, On 2019/02/19 4:49, Rob Herring wrote: On Fri, 8 Feb 2019 21:25:33 +0900, Sugaya Taichi wrote: The Milbeaut M10V SoC needs a part of sram for smp, so this adds the M10V sram compatible and binding. Signed-off-by: Sugaya Taichi --- .../devicetree/bindings/sram/milbeaut-smp-sram.txt | 24 ++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/sram/milbeaut-smp-sram.txt Reviewed-by: Rob Herring Thank you!
Re: [PATCH v2 00/15] Add basic support for Socionext Milbeaut M10V SoC
Hi, Thank you for your comments. On 2019/02/18 21:20, Arnd Bergmann wrote: On Fri, Feb 8, 2019 at 1:24 PM Sugaya Taichi wrote: Hi, Here is the series of patches the initial support for SC2000(M10V) of Milbeaut SoCs. "M10V" is the internal name of SC2000, so commonly used in source code. SC2000 is a SoC of the Milbeaut series. equipped with a DSP optimized for computer vision. It also features advanced functionalities such as 360-degree, real-time spherical stitching with multi cameras, image stabilization for without mechanical gimbals, and rolling shutter correction. More detail is below: https://www.socionext.com/en/products/assp/milbeaut/SC2000.html Specifications for developers are below: - Quad-core 32bit Cortex-A7 on ARMv7-A architecture - NEON support - DSP - GPU - MAX 3GB DDR3 - Cortex-M0 for power control - NAND Flash Interface - SD UHS-I - SD UHS-II - SDIO - USB2.0 HOST / Device - USB3.0 HOST / Device - PCI express Gen2 - Ethernet Engine - I2C - UART - SPI - PWM Support is quite minimal for now, since it only includes timer, clock, pictrl and serial controller drivers, so we can only boot to userspace through initramfs. Support for the other peripherals will come eventually. I've looked over the platform once more. Overall, it looks very good, and I'd still like to merge this for linux-5.1, but we are running out of time there. If you send the patches to s...@kernel.org quickly, we can try to still merge them in, but if anything goes wrong, it will have to wait until we start merging patches for 5.2, directly after 5.1 is out. I see. I do my best to make it. I did not look at the device driver patches (clk, clocksource, pinctrl, serial) in much detail. If you have an Ack from the maintainers, feel free to include them in the series, otherwise let's merge the rest now and then you can send the updated patches for inclusion through the subsystem trees in 5.2. OK, I'll add the patches with "Acked" or "Reviewed" tag. I have sent a few comments. The only one that is really important here is the missing platform check in the suspend options. Please try to address most of the other commentsm, either by changing the code, or by explaining why your version is correct. Okay, try to address them. I send the next version as soon as possible. Thanks. Sugaya Taichi Arnd
Re: [PATCH v2 3/3] pwm: hibvt: Add hi3559v100 support
On Wed, Feb 13, 2019 at 04:05:08PM +0100, Mathieu Othacehe wrote:
> Add support for hi3559v100-shub-pwm and hisilicon,hi3559v100-pwm
> platforms. They require a special quirk: pwm has to be enabled again
> to force duty_cycle refresh.
>
> Signed-off-by: Mathieu Othacehe
> ---
> drivers/pwm/pwm-hibvt.c | 28 +++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-hibvt.c b/drivers/pwm/pwm-hibvt.c
> index ffc803818c3c..b6a7942b3367 100644
> --- a/drivers/pwm/pwm-hibvt.c
> +++ b/drivers/pwm/pwm-hibvt.c
> @@ -54,6 +54,7 @@ struct hibvt_pwm_chip {
>
> struct hibvt_pwm_soc {
> u32 num_pwms;
> + bool quirk_force_enable;
> };
>
> static const struct hibvt_pwm_soc hi3516cv300_soc_info = {
> @@ -64,6 +65,16 @@ static const struct hibvt_pwm_soc hi3519v100_soc_info = {
> .num_pwms = 8,
> };
>
> +static const struct hibvt_pwm_soc hi3559v100_shub_soc_info = {
> + .num_pwms = 8,
> + .quirk_force_enable = true,
> +};
> +
> +static const struct hibvt_pwm_soc hi3559v100_soc_info = {
> + .num_pwms = 2,
> + .quirk_force_enable = true,
> +};
> +
> static inline struct hibvt_pwm_chip *to_hibvt_pwm_chip(struct pwm_chip *chip)
> {
> return container_of(chip, struct hibvt_pwm_chip, chip);
> @@ -152,13 +163,24 @@ static void hibvt_pwm_get_state(struct pwm_chip *chip,
> struct pwm_device *pwm,
> static int hibvt_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> struct pwm_state *state)
> {
> + struct hibvt_pwm_chip *hi_pwm_chip = to_hibvt_pwm_chip(chip);
> +
> if (state->polarity != pwm->state.polarity)
> hibvt_pwm_set_polarity(chip, pwm, state->polarity);
>
> if (state->period != pwm->state.period ||
> - state->duty_cycle != pwm->state.duty_cycle)
> + state->duty_cycle != pwm->state.duty_cycle) {
> hibvt_pwm_config(chip, pwm, state->duty_cycle, state->period);
I would prefer to have the continued line in the if condition aligned to
the opening parenthesis. Then it is optically separated from the first
expression in the body of the if.
>
> + /*
> + * On those platforms, it is required to enable the
Which platforms? I think in a previous round it was obvious what was
meant here because there was a test against two specific compatibles.
Now something like
Some implementations require the pwm to be enabled once more
each time the duty cycle is refreshed.
would be more suitable.
Is there a publicly available reference manual available for the newly
supported hardware?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH v5 2/6] arm: dts: mt2701: Add usb2 device nodes
From: Min Guo
Add musb nodes and usb2 phy nodes for MT2701
Signed-off-by: Min Guo
---
changes in v5:
1. Add usb connector child node
changes in v4:
1. no changes
changes in v3:
1. no changes
changes in v2:
1. Remove phy-names
---
arch/arm/boot/dts/mt2701-evb.dts | 26 ++
arch/arm/boot/dts/mt2701.dtsi| 33 +
2 files changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index be0edb3..95458ea 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -6,6 +6,7 @@
*/
/dts-v1/;
+#include
#include "mt2701.dtsi"
/ {
@@ -60,6 +61,20 @@
>;
default-brightness-level = <9>;
};
+
+ extcon_usb: extcon_iddig {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = < 44 GPIO_ACTIVE_HIGH>;
+ };
+
+ usb_vbus: regulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 45 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
{
@@ -229,3 +244,14 @@
{
status = "okay";
};
+
+ {
+ status = "okay";
+ usb_con: connector{
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ extcon = <_usb>;
+ vbus-supply = <_vbus>;
+ };
+};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 180377e..a6b1434 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -670,6 +670,39 @@
};
};
+ usb2: usb@1120 {
+ compatible = "mediatek,mt2701-musb",
+"mediatek,mtk-musb";
+ reg = <0 0x1120 0 0x1000>;
+ interrupts = ;
+ interrupt-names = "mc";
+ phys = < PHY_TYPE_USB2>;
+ dr_mode = "otg";
+ clocks = < CLK_PERI_USB0>,
+< CLK_PERI_USB0_MCU>,
+< CLK_PERI_USB_SLV>;
+ clock-names = "main","mcu","univpll";
+ power-domains = < MT2701_POWER_DOMAIN_IFR_MSC>;
+ status = "disabled";
+ };
+
+ u2phy0: usb-phy@1121 {
+ compatible = "mediatek,generic-tphy-v1";
+ reg = <0 0x1121 0 0x0800>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
+
+ u2port2: usb-phy@1a1c4800 {
+ reg = <0 0x11210800 0 0x0100>;
+ clocks = < CLK_TOP_USB_PHY48M>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b00 0 0x1000>;
--
1.9.1
[PATCH v5 3/6] usb: musb: Add get/set toggle hooks
From: Min Guo
Add get/set toggle hooks in struct musb_io and struct musb_platform_ops
for special platform; remove function musb_save_toggle, use the set/get
callback to handle toggle.
Signed-off-by: Min Guo
---
changes in v5:
1. no changes
new patch based on v4:
---
drivers/usb/musb/musb_core.c | 42
drivers/usb/musb/musb_core.h | 5 +
drivers/usb/musb/musb_host.c | 46 ++--
drivers/usb/musb/musb_io.h | 4
4 files changed, 61 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b7d5627..2fe5225 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -274,6 +274,38 @@ static void musb_default_writew(void __iomem *addr,
unsigned offset, u16 data)
__raw_writew(data, addr + offset);
}
+static u16 musb_default_get_toggle(struct musb_qh *qh, int is_out)
+{
+ void __iomem *epio = qh->hw_ep->regs;
+ u16 csr;
+
+ if (is_out)
+ csr = musb_readw(epio, MUSB_TXCSR) & MUSB_TXCSR_H_DATATOGGLE;
+ else
+ csr = musb_readw(epio, MUSB_RXCSR) & MUSB_RXCSR_H_DATATOGGLE;
+
+ return csr;
+}
+
+static u16 musb_default_set_toggle(struct musb_qh *qh, int is_out,
+ struct urb *urb)
+{
+ u16 csr;
+ u16 toggle;
+
+ toggle = usb_gettoggle(urb->dev, qh->epnum, is_out);
+
+ if (is_out)
+ csr = toggle ? (MUSB_TXCSR_H_WR_DATATOGGLE
+ | MUSB_TXCSR_H_DATATOGGLE)
+ : MUSB_TXCSR_CLRDATATOG;
+ else
+ csr = toggle ? (MUSB_RXCSR_H_WR_DATATOGGLE
+ | MUSB_RXCSR_H_DATATOGGLE) : 0;
+
+ return csr;
+}
+
/*
* Load an endpoint's FIFO
*/
@@ -2277,6 +2309,16 @@ static void musb_deassert_reset(struct work_struct *work)
else
musb->io.write_fifo = musb_default_write_fifo;
+ if (musb->ops->get_toggle)
+ musb->io.get_toggle = musb->ops->get_toggle;
+ else
+ musb->io.get_toggle = musb_default_get_toggle;
+
+ if (musb->ops->set_toggle)
+ musb->io.set_toggle = musb->ops->set_toggle;
+ else
+ musb->io.set_toggle = musb_default_set_toggle;
+
if (!musb->xceiv->io_ops) {
musb->xceiv->io_dev = musb->controller;
musb->xceiv->io_priv = musb->mregs;
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 04203b7..9f5a69c 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -27,6 +27,7 @@
struct musb;
struct musb_hw_ep;
struct musb_ep;
+struct musb_qh;
/* Helper defines for struct musb->hwvers */
#define MUSB_HWVERS_MAJOR(x) ((x >> 10) & 0x1f)
@@ -123,6 +124,8 @@ enum musb_g_ep0_state {
* @writew:write 16 bits
* @read_fifo: reads the fifo
* @write_fifo:writes to fifo
+ * @get_toggle:platform specific get toggle function
+ * @set_toggle:platform specific set toggle function
* @dma_init: platform specific dma init function
* @dma_exit: platform specific dma exit function
* @init: turns on clocks, sets up platform-specific registers, etc
@@ -167,6 +170,8 @@ struct musb_platform_ops {
void(*writew)(void __iomem *addr, unsigned offset, u16 data);
void(*read_fifo)(struct musb_hw_ep *hw_ep, u16 len, u8 *buf);
void(*write_fifo)(struct musb_hw_ep *hw_ep, u16 len, const u8 *buf);
+ u16 (*get_toggle)(struct musb_qh *qh, int is_out);
+ u16 (*set_toggle)(struct musb_qh *qh, int is_out, struct urb *urb);
struct dma_controller *
(*dma_init) (struct musb *musb, void __iomem *base);
void(*dma_exit)(struct dma_controller *c);
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index b59ce9a..b97fbf9 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -286,26 +286,6 @@ static void musb_giveback(struct musb *musb, struct urb
*urb, int status)
spin_lock(>lock);
}
-/* For bulk/interrupt endpoints only */
-static inline void musb_save_toggle(struct musb_qh *qh, int is_in,
- struct urb *urb)
-{
- void __iomem*epio = qh->hw_ep->regs;
- u16 csr;
-
- /*
-* FIXME: the current Mentor DMA code seems to have
-* problems getting toggle correct.
-*/
-
- if (is_in)
- csr = musb_readw(epio, MUSB_RXCSR) & MUSB_RXCSR_H_DATATOGGLE;
- else
- csr = musb_readw(epio, MUSB_TXCSR) & MUSB_TXCSR_H_DATATOGGLE;
-
- usb_settoggle(urb->dev, qh->epnum, !is_in, csr ? 1 : 0);
-}
-
/*
* Advance this hardware endpoint's queue, completing the specified URB and
* advancing to either the next URB queued to that qh, or else invalidating
@@
[PATCH v5 5/6] usb: musb: Add musb_clearb/w() interface
From: Min Guo
Delete the const attribute of addr parameter in readb/w/l hooks, these
changes are for implementing clearing W1C registers.
Replace musb_readb/w with musb_clearb/w to clear the interrupt status.
Signed-off-by: Min Guo
---
changes in v5:
1. Replace musb_readb() with musb_clearb() to clear dma pending interrupts
new patch based on v4:
---
drivers/usb/musb/musb_core.c | 32 +++-
drivers/usb/musb/musb_core.h | 8 ++--
drivers/usb/musb/musb_io.h | 8 +---
drivers/usb/musb/musbhsdma.c | 2 +-
drivers/usb/musb/sunxi.c | 4 ++--
drivers/usb/musb/tusb6010.c | 2 +-
6 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2fe5225..5ef8848 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -246,7 +246,7 @@ static u32 musb_default_busctl_offset(u8 epnum, u16 offset)
return 0x80 + (0x08 * epnum) + offset;
}
-static u8 musb_default_readb(const void __iomem *addr, unsigned offset)
+static u8 musb_default_readb(void __iomem *addr, unsigned offset)
{
u8 data = __raw_readb(addr + offset);
@@ -260,7 +260,7 @@ static void musb_default_writeb(void __iomem *addr,
unsigned offset, u8 data)
__raw_writeb(data, addr + offset);
}
-static u16 musb_default_readw(const void __iomem *addr, unsigned offset)
+static u16 musb_default_readw(void __iomem *addr, unsigned offset)
{
u16 data = __raw_readw(addr + offset);
@@ -396,19 +396,25 @@ static void musb_default_read_fifo(struct musb_hw_ep
*hw_ep, u16 len, u8 *dst)
/*
* Old style IO functions
*/
-u8 (*musb_readb)(const void __iomem *addr, unsigned offset);
+u8 (*musb_readb)(void __iomem *addr, unsigned offset);
EXPORT_SYMBOL_GPL(musb_readb);
void (*musb_writeb)(void __iomem *addr, unsigned offset, u8 data);
EXPORT_SYMBOL_GPL(musb_writeb);
-u16 (*musb_readw)(const void __iomem *addr, unsigned offset);
+u8 (*musb_clearb)(void __iomem *addr, unsigned int offset);
+EXPORT_SYMBOL_GPL(musb_clearb);
+
+u16 (*musb_readw)(void __iomem *addr, unsigned offset);
EXPORT_SYMBOL_GPL(musb_readw);
void (*musb_writew)(void __iomem *addr, unsigned offset, u16 data);
EXPORT_SYMBOL_GPL(musb_writew);
-u32 musb_readl(const void __iomem *addr, unsigned offset)
+u16 (*musb_clearw)(void __iomem *addr, unsigned int offset);
+EXPORT_SYMBOL_GPL(musb_clearw);
+
+u32 musb_readl(void __iomem *addr, unsigned offset)
{
u32 data = __raw_readl(addr + offset);
@@ -1047,7 +1053,6 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
static void musb_disable_interrupts(struct musb *musb)
{
void __iomem*mbase = musb->mregs;
- u16 temp;
/* disable interrupts */
musb_writeb(mbase, MUSB_INTRUSBE, 0);
@@ -1057,9 +1062,9 @@ static void musb_disable_interrupts(struct musb *musb)
musb_writew(mbase, MUSB_INTRRXE, 0);
/* flush pending interrupts */
- temp = musb_readb(mbase, MUSB_INTRUSB);
- temp = musb_readw(mbase, MUSB_INTRTX);
- temp = musb_readw(mbase, MUSB_INTRRX);
+ musb_clearb(mbase, MUSB_INTRUSB);
+ musb_clearw(mbase, MUSB_INTRTX);
+ musb_clearw(mbase, MUSB_INTRRX);
}
static void musb_enable_interrupts(struct musb *musb)
@@ -2284,10 +2289,19 @@ static void musb_deassert_reset(struct work_struct
*work)
musb_readb = musb->ops->readb;
if (musb->ops->writeb)
musb_writeb = musb->ops->writeb;
+ if (musb->ops->clearb)
+ musb_clearb = musb->ops->clearb;
+ else
+ musb_clearb = musb_readb;
+
if (musb->ops->readw)
musb_readw = musb->ops->readw;
if (musb->ops->writew)
musb_writew = musb->ops->writew;
+ if (musb->ops->clearw)
+ musb_clearw = musb->ops->clearw;
+ else
+ musb_clearw = musb_readw;
#ifndef CONFIG_MUSB_PIO_ONLY
if (!musb->ops->dma_init || !musb->ops->dma_exit) {
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 9f5a69c..0d9a35f 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -120,8 +120,10 @@ enum musb_g_ep0_state {
* @fifo_offset: returns the fifo offset
* @readb: read 8 bits
* @writeb:write 8 bits
+ * @clearb:could be clear-on-readb or W1C
* @readw: read 16 bits
* @writew:write 16 bits
+ * @clearw:could be clear-on-readw or W1C
* @read_fifo: reads the fifo
* @write_fifo:writes to fifo
* @get_toggle:platform specific get toggle function
@@ -164,10 +166,12 @@ struct musb_platform_ops {
u16 fifo_mode;
u32 (*fifo_offset)(u8 epnum);
u32 (*busctl_offset)(u8 epnum, u16 offset);
- u8 (*readb)(const void __iomem *addr, unsigned offset);
+ u8 (*readb)(void __iomem *addr, unsigned offset);
void(*writeb)(void __iomem
[PATCH v5 4/6] usb: musb: Add noirq type of dma create interface
From: Min Guo
Add noirq type of dma create interface for platform which do not
have dedicated DMA interrupt line, move musbhsdma macro definition
to musb_dma.h
Signed-off-by: Min Guo
---
changes in v5:
1. no changes
new patch based on v4:
---
drivers/usb/musb/musb_dma.h | 9
drivers/usb/musb/musbhsdma.c | 54 ++--
2 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 8f60271..05103ea 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -35,6 +35,12 @@
*whether shared with the Inventra core or separate.
*/
+#define MUSB_HSDMA_BASE0x200
+#define MUSB_HSDMA_INTR(MUSB_HSDMA_BASE + 0)
+#define MUSB_HSDMA_CONTROL 0x4
+#define MUSB_HSDMA_ADDRESS 0x8
+#define MUSB_HSDMA_COUNT 0xc
+
#defineDMA_ADDR_INVALID(~(dma_addr_t)0)
#ifdef CONFIG_MUSB_PIO_ONLY
@@ -191,6 +197,9 @@ static inline void musb_dma_controller_destroy(struct
dma_controller *d) { }
extern struct dma_controller *
musbhs_dma_controller_create(struct musb *musb, void __iomem *base);
extern void musbhs_dma_controller_destroy(struct dma_controller *c);
+extern struct dma_controller *
+musbhs_dma_controller_create_noirq(struct musb *musb, void __iomem *base);
+extern irqreturn_t dma_controller_irq(int irq, void *private_data);
extern struct dma_controller *
tusb_dma_controller_create(struct musb *musb, void __iomem *base);
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index a688f7f..b2394a7 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -10,12 +10,7 @@
#include
#include
#include "musb_core.h"
-
-#define MUSB_HSDMA_BASE0x200
-#define MUSB_HSDMA_INTR(MUSB_HSDMA_BASE + 0)
-#define MUSB_HSDMA_CONTROL 0x4
-#define MUSB_HSDMA_ADDRESS 0x8
-#define MUSB_HSDMA_COUNT 0xc
+#include "musb_dma.h"
#define MUSB_HSDMA_CHANNEL_OFFSET(_bchannel, _offset) \
(MUSB_HSDMA_BASE + (_bchannel << 4) + _offset)
@@ -268,7 +263,7 @@ static int dma_channel_abort(struct dma_channel *channel)
return 0;
}
-static irqreturn_t dma_controller_irq(int irq, void *private_data)
+irqreturn_t dma_controller_irq(int irq, void *private_data)
{
struct musb_dma_controller *controller = private_data;
struct musb *musb = controller->private_data;
@@ -382,6 +377,7 @@ static irqreturn_t dma_controller_irq(int irq, void
*private_data)
spin_unlock_irqrestore(>lock, flags);
return retval;
}
+EXPORT_SYMBOL_GPL(dma_controller_irq);
void musbhs_dma_controller_destroy(struct dma_controller *c)
{
@@ -397,18 +393,10 @@ void musbhs_dma_controller_destroy(struct dma_controller
*c)
}
EXPORT_SYMBOL_GPL(musbhs_dma_controller_destroy);
-struct dma_controller *musbhs_dma_controller_create(struct musb *musb,
- void __iomem *base)
+static struct musb_dma_controller *
+dma_controller_alloc(struct musb *musb, void __iomem *base)
{
struct musb_dma_controller *controller;
- struct device *dev = musb->controller;
- struct platform_device *pdev = to_platform_device(dev);
- int irq = platform_get_irq_byname(pdev, "dma");
-
- if (irq <= 0) {
- dev_err(dev, "No DMA interrupt line!\n");
- return NULL;
- }
controller = kzalloc(sizeof(*controller), GFP_KERNEL);
if (!controller)
@@ -422,6 +410,25 @@ struct dma_controller *musbhs_dma_controller_create(struct
musb *musb,
controller->controller.channel_release = dma_channel_release;
controller->controller.channel_program = dma_channel_program;
controller->controller.channel_abort = dma_channel_abort;
+ return controller;
+}
+
+struct dma_controller *
+musbhs_dma_controller_create(struct musb *musb, void __iomem *base)
+{
+ struct musb_dma_controller *controller;
+ struct device *dev = musb->controller;
+ struct platform_device *pdev = to_platform_device(dev);
+ int irq = platform_get_irq_byname(pdev, "dma");
+
+ if (irq <= 0) {
+ dev_err(dev, "No DMA interrupt line!\n");
+ return NULL;
+ }
+
+ controller = dma_controller_alloc(musb, base);
+ if (!controller)
+ return NULL;
if (request_irq(irq, dma_controller_irq, 0,
dev_name(musb->controller), >controller)) {
@@ -436,3 +443,16 @@ struct dma_controller *musbhs_dma_controller_create(struct
musb *musb,
return >controller;
}
EXPORT_SYMBOL_GPL(musbhs_dma_controller_create);
+
+struct dma_controller *
+musbhs_dma_controller_create_noirq(struct musb *musb, void __iomem *base)
+{
+ struct musb_dma_controller *controller;
+
+ controller = dma_controller_alloc(musb,
[PATCH v5 6/6] usb: musb: Add support for MediaTek musb controller
From: Min Guo
This adds support for MediaTek musb controller in
host, peripheral and otg mode.
There are some quirk of MediaTek musb controller, such as:
-W1C interrupt status registers
-Private data toggle registers
-No dedicated DMA interrupt line
Signed-off-by: Min Guo
Signed-off-by: Yonglong Wu
---
changes in v5:
1. Replace musb_readb() with musb_clearb() to clear common/tx/rx pending
interrupts
2. Make musb_clearb/w() return the value of musb_readb/w()
3. Add driver to get child nodes of usb connector and extcon device
changes in v4:
1. no changes
changes in v3:
suggested by Bin:
1. Remove 'u8/u16 data' parameter in clearb/w() hooks
2. Replace musb_readb/w() with musb_clearb/w() to clear interrupts status
changes in v2:
suggested by Bin:
1. Add summarize of MediaTek musb controller differences in the commit log
2. Add "|| COMPILE_TEST" in Kconfig
3. Move MediaTek's private toggle registers from musb_regs.h to mediatek.c
4. Replace musb_readl() with musb_readw() to read 16bit toggle register
---
drivers/usb/musb/Kconfig| 8 +-
drivers/usb/musb/Makefile | 1 +
drivers/usb/musb/mediatek.c | 629
3 files changed, 637 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/musb/mediatek.c
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index ad08895..b72b7c1 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -115,6 +115,12 @@ config USB_MUSB_JZ4740
depends on USB_MUSB_GADGET
depends on USB_OTG_BLACKLIST_HUB
+config USB_MUSB_MEDIATEK
+ tristate "MediaTek platforms"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on NOP_USB_XCEIV
+ depends on GENERIC_PHY
+
config USB_MUSB_AM335X_CHILD
tristate
@@ -141,7 +147,7 @@ config USB_UX500_DMA
config USB_INVENTRA_DMA
bool 'Inventra'
- depends on USB_MUSB_OMAP2PLUS
+ depends on USB_MUSB_OMAP2PLUS || USB_MUSB_MEDIATEK
help
Enable DMA transfers using Mentor's engine.
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 3a88c79..63d82d0 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o
obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
obj-$(CONFIG_USB_MUSB_JZ4740) += jz4740.o
obj-$(CONFIG_USB_MUSB_SUNXI) += sunxi.o
+obj-$(CONFIG_USB_MUSB_MEDIATEK)+= mediatek.o
obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/mediatek.c b/drivers/usb/musb/mediatek.c
new file mode 100644
index 000..946b453
--- /dev/null
+++ b/drivers/usb/musb/mediatek.c
@@ -0,0 +1,629 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author:
+ * Min Guo
+ * Yonglong Wu
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "musb_core.h"
+#include "musb_dma.h"
+
+#define USB_L1INTS 0x00a0
+#define USB_L1INTM 0x00a4
+#define MTK_MUSB_TXFUNCADDR0x0480
+
+/* MediaTek controller toggle enable and status reg */
+#define MUSB_RXTOG 0x80
+#define MUSB_RXTOGEN 0x82
+#define MUSB_TXTOG 0x84
+#define MUSB_TXTOGEN 0x86
+
+#define TX_INT_STATUS BIT(0)
+#define RX_INT_STATUS BIT(1)
+#define USBCOM_INT_STATUS BIT(2)
+#define DMA_INT_STATUS BIT(3)
+
+#define DMA_INTR_STATUS_MSKGENMASK(7, 0)
+#define DMA_INTR_UNMASK_SET_MSKGENMASK(31, 24)
+
+enum mtk_vbus_id_state {
+ MTK_ID_FLOAT = 1,
+ MTK_ID_GROUND,
+ MTK_VBUS_OFF,
+ MTK_VBUS_VALID,
+};
+
+struct mtk_glue {
+ struct device *dev;
+ struct musb *musb;
+ struct platform_device *musb_pdev;
+ struct platform_device *usb_phy;
+ struct phy *phy;
+ struct usb_phy *xceiv;
+ enum phy_mode phy_mode;
+ struct clk *main;
+ struct clk *mcu;
+ struct clk *univpll;
+ struct regulator *vbus;
+ struct extcon_dev *edev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+};
+
+static int mtk_musb_clks_get(struct mtk_glue *glue)
+{
+ struct device *dev = glue->dev;
+
+ glue->main = devm_clk_get(dev, "main");
+ if (IS_ERR(glue->main)) {
+ dev_err(dev, "fail to get main clock\n");
+ return PTR_ERR(glue->main);
+ }
+
+ glue->mcu = devm_clk_get(dev, "mcu");
+ if (IS_ERR(glue->mcu)) {
+ dev_err(dev, "fail to get mcu clock\n");
+ return PTR_ERR(glue->mcu);
+ }
+
+ glue->univpll = devm_clk_get(dev, "univpll");
+ if (IS_ERR(glue->univpll)) {
+ dev_err(dev, "fail to get univpll clock\n");
+ return PTR_ERR(glue->univpll);
+ }
+
+ return 0;
+}
+
+static int mtk_musb_clks_enable(struct mtk_glue *glue)
+{
+ int ret;
+
+
[PATCH v5 0/6] Add MediaTek MUSB Controller Driver
From: Min Guo These patches introduce the MediaTek MUSB controller driver. The driver can be configured as Dual-Role Device (DRD), Peripheral Only and Host Only modes. This has beed tested on MT2701 with a variety of devices in host mode and with the f_mass gadget driver in peripheral mode, plugging otg cables in/out a lot of times in all possible imaginable plug orders. changes in v5: changes of dt-bindings suggested by Rob: 1. Modify compatible as - compatible : should be one of: "mediatek,mt-2701" ... followed by "mediatek,mtk-musb" 2. Add usb connector child node changes of DTS: 1. Add usb connector child node changes of driver suggested by Bin: 1. Replace musb_readb() with musb_clearb() to clear dma pending interrupts 2. Replace musb_readb() with musb_clearb() to clear common/tx/rx pending interrupts 3. Make musb_clearb/w() return the value of musb_readb/w() changes in v4: changes of dt-bindings suggested by Sergei: 1. String alignment changes of driver suggested by Tony and Bin: 1. Add a new patch for set/get_toggle() 2. Add a new patch for noirq type of dma 3. Add a new patch musb_clearb/w() 4. Abondon patch "usb: musb: Delete the const attribute of addr parameter in readb/w/l hooks" changes in v3: changes of driver suggested by Bin: 1. Add a new patch for musb_readb/w/l() to remove const attribute 2. Use is_out as function parameter in set_toggle/get_toggle() hooks 3. Remove 'u8/u16 data' parameter in clearb/w() hooks 4. Remove musb_default_clearb/w() 5. Replace musb_readb/w() with musb_clearb/w() to clear pending interrupts 6. Add comments to clearb/w() hooks 7. Replace musb_save_toggle() with musb->io.get_toggle() 8. Replace musb_set_toggle() with musb->io.set_toggle() changes in v2: changes of dt-bindings suggested by Rob and Bin: 1. Modify DRC to DRD 2. Drop the "-musb" in compatible 3. Remove phy-names 4. Add space after comma in clock-names dtsi: 1. Remove phy-names changes of driver suggested by Bin: 1. Add a new patch for musb_set_toggle 2. Add summarize of MediaTek musb controller differences in the commit log 3. Abondon patch "usb: musb: Move musbhsdma macro definition to musb_dma.h" 4. Add "|| COMPILE_TEST" in Kconfig 5. Add musb_clearb() and musb_clearw() hooks 6. Add get_toggle() and set_toggle() hooks 7. Replace musb_readl() with musb_readw() to read 16bit toggle register 8. Move MediaTek's private toggle registers from musb_regs.h to mediatek.c 9. Create musbhs_dma_controller_create_noirq() Min Guo (6): dt-bindings: usb: musb: Add support for MediaTek musb controller arm: dts: mt2701: Add usb2 device nodes usb: musb: Add get/set toggle hooks usb: musb: Add noirq type of dma create interface usb: musb: Add musb_clearb/w() interface usb: musb: Add support for MediaTek musb controller .../devicetree/bindings/usb/mediatek,musb.txt | 54 ++ arch/arm/boot/dts/mt2701-evb.dts | 26 + arch/arm/boot/dts/mt2701.dtsi | 33 ++ drivers/usb/musb/Kconfig | 8 +- drivers/usb/musb/Makefile | 1 + drivers/usb/musb/mediatek.c| 629 + drivers/usb/musb/musb_core.c | 74 ++- drivers/usb/musb/musb_core.h | 13 +- drivers/usb/musb/musb_dma.h| 9 + drivers/usb/musb/musb_host.c | 46 +- drivers/usb/musb/musb_io.h | 12 +- drivers/usb/musb/musbhsdma.c | 56 +- drivers/usb/musb/sunxi.c | 4 +- drivers/usb/musb/tusb6010.c| 2 +- 14 files changed, 895 insertions(+), 72 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt create mode 100644 drivers/usb/musb/mediatek.c -- 1.9.1
[PATCH v5 1/6] dt-bindings: usb: musb: Add support for MediaTek musb controller
From: Min Guo
This adds support for MediaTek musb controller in
host, peripheral and otg mode.
Signed-off-by: Min Guo
---
changes in v5:
suggested by Rob:
1. Modify compatible as
- compatible : should be one of:
"mediatek,mt-2701"
...
followed by "mediatek,mtk-musb"
2. Add usb connector child node
changes in v4:
suggested by Sergei:
1. String alignment
changes in v3:
1. no changes
changes in v2:
suggested by Bin:
1. Modify DRC to DRD
suggested by Rob:
2. Drop the "-musb" in compatible
3. Remove phy-names
4. Add space after comma in clock-names
---
.../devicetree/bindings/usb/mediatek,musb.txt | 54 ++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
new file mode 100644
index 000..0632e6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
@@ -0,0 +1,54 @@
+MediaTek musb DRD/OTG controller
+---
+
+Required properties:
+ - compatible : should be one of:
+ "mediatek,mt-2701"
+ ...
+ followed by "mediatek,mtk-musb"
+ - reg : specifies physical base address and size of
+ the registers
+ - interrupts : interrupt used by musb controller
+ - interrupt-names : must be "mc"
+ - phys: PHY specifier for the OTG phy
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+ refer to usb/generic.txt
+ - clocks : a list of phandle + clock-specifier pairs, one for
+ each entry in clock-names
+ - clock-names : must contain "main", "mcu", "univpll"
+ for clocks of controller
+
+Optional properties:
+ - power-domains : a phandle to USB power domain node to control USB's
+ MTCMOS
+
+Required child nodes:
+ usb connector node as defined in bindings/connector/usb-connector.txt
+ - extcon : for VBUS and ID pin changes detection, needed when
+ supports dual-role mode
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+ dual-role mode
+
+Example:
+
+usb2: usb@1120 {
+ compatible = "mediatek,mt2701-musb",
+"mediatek,mtk-musb";
+ reg = <0 0x1120 0 0x1000>;
+ interrupts = ;
+ interrupt-names = "mc";
+ phys = < PHY_TYPE_USB2>;
+ dr_mode = "otg";
+ clocks = < CLK_PERI_USB0>,
+< CLK_PERI_USB0_MCU>,
+< CLK_PERI_USB_SLV>;
+ clock-names = "main","mcu","univpll";
+ power-domains = < MT2701_POWER_DOMAIN_IFR_MSC>;
+ usb_con: connector{
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ extcon = <_usb>;
+ vbus-supply = <_vbus>;
+ };
+};
--
1.9.1
[PATCH 4/5] dt-bindings: serial: sprd: Add dma properties to support DMA mode
From: Lanqing Liu
This patch adds dmas and dma-names properties for the UART DMA mode.
Signed-off-by: Lanqing Liu
Signed-off-by: Baolin Wang
---
.../devicetree/bindings/serial/sprd-uart.txt |6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt
b/Documentation/devicetree/bindings/serial/sprd-uart.txt
index 6eb5863..9ac28f6 100644
--- a/Documentation/devicetree/bindings/serial/sprd-uart.txt
+++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt
@@ -15,12 +15,18 @@ Required properties:
UART clock and source clock are optional properties, but enable clock
is required.
+Optional properties:
+- dma-names: Should contain "tx" for transmit and "rx" for receive channels.
+- dmas: A list of dma specifiers, one for each entry in dma-names.
+
Example:
uart0: serial@0 {
compatible = "sprd,sc9860-uart",
"sprd,sc9836-uart";
reg = <0x0 0x100>;
interrupts = ;
+ dma-names = "rx", "tx";
+ dmas = <_dma 19 19>, <_dma 20 20>;
clock-names = "enable", "uart", "source";
clocks = <_ap_apb_gates 9>, <_uart0>, <_26m>;
};
--
1.7.9.5
[PATCH 3/5] serial: sprd: Add power management for the Spreadtrum serial controller
From: Lanqing Liu
This patch adds power management for the Spreadtrum serial controller.
Signed-off-by: Lanqing Liu
Signed-off-by: Baolin Wang
---
drivers/tty/serial/sprd_serial.c | 61 +++---
1 file changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index 1891a45..8f45b66 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -100,10 +100,12 @@
#define SPRD_IMSR_TX_FIFO_EMPTYBIT(1)
#define SPRD_IMSR_BREAK_DETECT BIT(7)
#define SPRD_IMSR_TIMEOUT BIT(13)
+#define SPRD_DEFAULT_SOURCE_CLK2600
struct sprd_uart_port {
struct uart_port port;
char name[16];
+ struct clk *clk;
};
static struct sprd_uart_port *sprd_port[UART_NR_MAX];
@@ -491,6 +493,22 @@ static int sprd_verify_port(struct uart_port *port, struct
serial_struct *ser)
return 0;
}
+static void sprd_pm(struct uart_port *port, unsigned int state,
+ unsigned int oldstate)
+{
+ struct sprd_uart_port *sup =
+ container_of(port, struct sprd_uart_port, port);
+
+ switch (state) {
+ case UART_PM_STATE_ON:
+ clk_prepare_enable(sup->clk);
+ break;
+ case UART_PM_STATE_OFF:
+ clk_disable_unprepare(sup->clk);
+ break;
+ }
+}
+
static const struct uart_ops serial_sprd_ops = {
.tx_empty = sprd_tx_empty,
.get_mctrl = sprd_get_mctrl,
@@ -507,6 +525,7 @@ static int sprd_verify_port(struct uart_port *port, struct
serial_struct *ser)
.request_port = sprd_request_port,
.config_port = sprd_config_port,
.verify_port = sprd_verify_port,
+ .pm = sprd_pm,
};
#ifdef CONFIG_SERIAL_SPRD_CONSOLE
@@ -671,11 +690,45 @@ static int sprd_remove(struct platform_device *dev)
return 0;
}
+static int sprd_clk_init(struct uart_port *uport)
+{
+ struct clk *clk_uart, *clk_parent;
+ struct sprd_uart_port *u = sprd_port[uport->line];
+
+ clk_uart = devm_clk_get(uport->dev, "uart");
+ if (IS_ERR(clk_uart)) {
+ dev_warn(uport->dev, "uart%d can't get uart clock\n",
+uport->line);
+ clk_uart = NULL;
+ }
+
+ clk_parent = devm_clk_get(uport->dev, "source");
+ if (IS_ERR(clk_parent)) {
+ dev_warn(uport->dev, "uart%d can't get source clock\n",
+uport->line);
+ clk_parent = NULL;
+ }
+
+ if (!clk_uart || clk_set_parent(clk_uart, clk_parent))
+ uport->uartclk = SPRD_DEFAULT_SOURCE_CLK;
+ else
+ uport->uartclk = clk_get_rate(clk_uart);
+
+ u->clk = devm_clk_get(uport->dev, "enable");
+ if (IS_ERR(u->clk)) {
+ if (PTR_ERR(u->clk) != -EPROBE_DEFER)
+ dev_err(uport->dev, "uart%d can't get enable clock\n",
+ uport->line);
+ return PTR_ERR(u->clk);
+ }
+
+ return 0;
+}
+
static int sprd_probe(struct platform_device *pdev)
{
struct resource *res;
struct uart_port *up;
- struct clk *clk;
int irq;
int index;
int ret;
@@ -704,9 +757,9 @@ static int sprd_probe(struct platform_device *pdev)
up->ops = _sprd_ops;
up->flags = UPF_BOOT_AUTOCONF;
- clk = devm_clk_get(>dev, NULL);
- if (!IS_ERR_OR_NULL(clk))
- up->uartclk = clk_get_rate(clk);
+ ret = sprd_clk_init(up);
+ if (ret)
+ return ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
up->membase = devm_ioremap_resource(>dev, res);
--
1.7.9.5
[PATCH 5/5] serial: sprd: Add DMA mode support
From: Lanqing Liu
Add DMA mode support for the Spreadtrum serial controller.
Signed-off-by: Lanqing Liu
Signed-off-by: Baolin Wang
---
drivers/tty/serial/sprd_serial.c | 440 --
1 file changed, 426 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index 8f45b66..6aebd77 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -10,6 +10,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -75,6 +78,7 @@
/* control register 1 */
#define SPRD_CTL1 0x001C
+#define SPRD_DMA_ENBIT(15)
#define RX_HW_FLOW_CTL_THLDBIT(6)
#define RX_HW_FLOW_CTL_EN BIT(7)
#define TX_HW_FLOW_CTL_EN BIT(8)
@@ -86,6 +90,7 @@
#define THLD_TX_EMPTY 0x40
#define THLD_TX_EMPTY_SHIFT8
#define THLD_RX_FULL 0x40
+#define THLD_RX_FULL_MASK GENMASK(6, 0)
/* config baud rate register */
#define SPRD_CLKD0 0x0024
@@ -102,15 +107,36 @@
#define SPRD_IMSR_TIMEOUT BIT(13)
#define SPRD_DEFAULT_SOURCE_CLK2600
+#define SPRD_RX_DMA_STEP 1
+#define SPRD_RX_FIFO_FULL 1
+#define SPRD_TX_FIFO_FULL 0x20
+#define SPRD_UART_RX_SIZE (UART_XMIT_SIZE / 4)
+
+struct sprd_uart_dma {
+ struct dma_chan *chn;
+ unsigned char *virt;
+ dma_addr_t phys_addr;
+ dma_cookie_t cookie;
+ u32 trans_len;
+ bool enable;
+};
+
struct sprd_uart_port {
struct uart_port port;
char name[16];
struct clk *clk;
+ struct sprd_uart_dma tx_dma;
+ struct sprd_uart_dma rx_dma;
+ dma_addr_t pos;
+ unsigned char *rx_buf_tail;
};
static struct sprd_uart_port *sprd_port[UART_NR_MAX];
static int sprd_ports_num;
+static int sprd_start_dma_rx(struct uart_port *port);
+static int sprd_tx_dma_config(struct uart_port *port);
+
static inline unsigned int serial_in(struct uart_port *port,
unsigned int offset)
{
@@ -141,45 +167,389 @@ static void sprd_set_mctrl(struct uart_port *port,
unsigned int mctrl)
/* nothing to do */
}
-static void sprd_stop_tx(struct uart_port *port)
+static void sprd_stop_rx(struct uart_port *port)
{
+ struct sprd_uart_port *sp =
+ container_of(port, struct sprd_uart_port, port);
unsigned int ien, iclr;
+ if (sp->rx_dma.enable)
+ dmaengine_terminate_all(sp->rx_dma.chn);
+
iclr = serial_in(port, SPRD_ICLR);
ien = serial_in(port, SPRD_IEN);
- iclr |= SPRD_IEN_TX_EMPTY;
- ien &= ~SPRD_IEN_TX_EMPTY;
+ ien &= ~(SPRD_IEN_RX_FULL | SPRD_IEN_BREAK_DETECT);
+ iclr |= SPRD_IEN_RX_FULL | SPRD_IEN_BREAK_DETECT;
- serial_out(port, SPRD_ICLR, iclr);
serial_out(port, SPRD_IEN, ien);
+ serial_out(port, SPRD_ICLR, iclr);
}
-static void sprd_start_tx(struct uart_port *port)
+static void sprd_uart_dma_enable(struct uart_port *port, bool enable)
{
- unsigned int ien;
+ u32 val = serial_in(port, SPRD_CTL1);
- ien = serial_in(port, SPRD_IEN);
- if (!(ien & SPRD_IEN_TX_EMPTY)) {
- ien |= SPRD_IEN_TX_EMPTY;
- serial_out(port, SPRD_IEN, ien);
+ if (enable)
+ val |= SPRD_DMA_EN;
+ else
+ val &= ~SPRD_DMA_EN;
+
+ serial_out(port, SPRD_CTL1, val);
+}
+
+static void sprd_stop_tx_dma(struct uart_port *port)
+{
+ struct sprd_uart_port *sp =
+ container_of(port, struct sprd_uart_port, port);
+ struct circ_buf *xmit = >state->xmit;
+ struct dma_tx_state state;
+ u32 trans_len;
+
+ dmaengine_pause(sp->tx_dma.chn);
+
+ dmaengine_tx_status(sp->tx_dma.chn, sp->tx_dma.cookie, );
+ if (state.residue) {
+ trans_len = state.residue - sp->tx_dma.phys_addr;
+ xmit->tail = (xmit->tail + trans_len) & (UART_XMIT_SIZE - 1);
+ port->icount.tx += trans_len;
+ dma_unmap_single(port->dev, sp->tx_dma.phys_addr,
+sp->tx_dma.trans_len, DMA_TO_DEVICE);
}
+
+ dmaengine_terminate_all(sp->tx_dma.chn);
+ sp->tx_dma.trans_len = 0;
}
-static void sprd_stop_rx(struct uart_port *port)
+static int sprd_tx_buf_remap(struct uart_port *port)
+{
+ struct sprd_uart_port *sp =
+ container_of(port, struct sprd_uart_port, port);
+ struct circ_buf *xmit = >state->xmit;
+
+ sp->tx_dma.trans_len =
+ CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE);
+
+ sp->tx_dma.phys_addr = dma_map_single(port->dev,
+ (void *)&(xmit->buf[xmit->tail]),
+ sp->tx_dma.trans_len,
+ DMA_TO_DEVICE);
+ return dma_mapping_error(port->dev,
[PATCH 2/5] dt-bindings: serial: sprd: Add clocks and clocks-names properties
From: Lanqing Liu
This patch adds clocks and clocks-names properties, which are used to do
power management for our UART driver.
Signed-off-by: Lanqing Liu
Signed-off-by: Baolin Wang
---
.../devicetree/bindings/serial/sprd-uart.txt | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt
b/Documentation/devicetree/bindings/serial/sprd-uart.txt
index cab40f0..6eb5863 100644
--- a/Documentation/devicetree/bindings/serial/sprd-uart.txt
+++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt
@@ -7,7 +7,13 @@ Required properties:
- reg: offset and length of the register set for the device
- interrupts: exactly one interrupt specifier
-- clocks: phandles to input clocks.
+- clock-names: Should contain following entries:
+ "enable" for UART module enable clock,
+ "uart" for UART clock,
+ "source" for UART source (parent) clock.
+- clocks: Should contain a clock specifier for each entry in clock-names.
+ UART clock and source clock are optional properties, but enable clock
+ is required.
Example:
uart0: serial@0 {
@@ -15,5 +21,6 @@ Example:
"sprd,sc9836-uart";
reg = <0x0 0x100>;
interrupts = ;
- clocks = <_26m>;
+ clock-names = "enable", "uart", "source";
+ clocks = <_ap_apb_gates 9>, <_uart0>, <_26m>;
};
--
1.7.9.5
[PATCH 0/5] Add new features for the Spreadtrum serial controller
This patch set fixes the baud rate calculation formula issue, as well as adding power management support and DMA mode support for the Spreadtrum serial controller. Lanqing Liu (5): serial: sprd: Modify the baud rate calculation formula dt-bindings: serial: sprd: Add clocks and clocks-names properties serial: sprd: Add power management for the Spreadtrum serial controller dt-bindings: serial: sprd: Add dma properties to support DMA mode serial: sprd: Add DMA mode support .../devicetree/bindings/serial/sprd-uart.txt | 17 +- drivers/tty/serial/sprd_serial.c | 503 +++- 2 files changed, 499 insertions(+), 21 deletions(-) -- 1.7.9.5
[PATCH 1/5] serial: sprd: Modify the baud rate calculation formula
From: Lanqing Liu
When the source clock is not divisible by the expected baud rate and
the remainder is not less than half of the expected baud rate, the old
formular will round up the frequency division coefficient. This will
make the actual baud rate less than the expected value and can not meet
the external transmission requirements.
Thus this patch modifies the baud rate calculation formula to support
the serial controller output the maximum baud rate.
Signed-off-by: Lanqing Liu
Signed-off-by: Baolin Wang
---
drivers/tty/serial/sprd_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index 4287ca3..1891a45 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -371,7 +371,7 @@ static void sprd_set_termios(struct uart_port *port,
/* ask the core to calculate the divisor for us */
baud = uart_get_baud_rate(port, termios, old, 0, SPRD_BAUD_IO_LIMIT);
- quot = (unsigned int)((port->uartclk + baud / 2) / baud);
+ quot = port->uartclk / baud;
/* set data length */
switch (termios->c_cflag & CSIZE) {
--
1.7.9.5
Re: [PATCH v1 2/5] dt-bindings: pwm: add a property "mediatek,num-pwms"
On Mon, Feb 18, 2019 at 02:36:58PM -0600, Rob Herring wrote:
> On Fri, Jan 18, 2019 at 09:44:49AM +0100, Matthias Brugger wrote:
> >
> >
> > On 18/01/2019 04:24, Ryder Lee wrote:
> > > This adds a property "mediatek,num-pwms" in example so that we could
> > > set the number of PWM channels via device tree.
> > >
> > > Signed-off-by: Ryder Lee
> > > Reviewed-by: Matthias Brugger
> > > ---
> > > Changes since v1: add a Reviewed-by tag.
> > > ---
> > > Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
> > > b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
> > > index 991728c..f9e2d1f 100644
> > > --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
> > > +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
> > > @@ -20,6 +20,7 @@ Required properties:
> > > - pinctrl-names: Must contain a "default" entry.
> > > - pinctrl-0: One property must exist for each entry in pinctrl-names.
> > > See pinctrl/pinctrl-bindings.txt for details of the property values.
> > > + - mediatek,num-pwms: the number of PWM channels.
> > >
> > > Example:
> > > pwm0: pwm@11006000 {
> > > @@ -37,4 +38,5 @@ Example:
> > > "pwm3", "pwm4", "pwm5";
> > > pinctrl-names = "default";
> > > pinctrl-0 = <_pins>;
> > > + mediatek,num-pwms = <5>;
> > > };
> > >
> >
> > Wasn't there a comment in the last version to use num-pwms instead of
> > mediatek,num-pwms?
> >
> > Uwe I think you requested that.
>
> Perhaps, but why is this needed? Typically, this would be implied by the
> compatible or the driver doesn't care and we assume 'pwms' properties
> are not out of range.
I think it is sensible to standardize such a property because there are
a few drivers that support different variants of PWMs that only differ
in the number of supported pwms. See for example pwm-mediatek and
pwm-sun4i. I wrote a longer motivation in a mail that is available at
https://www.spinics.net/lists/linux-pwm/msg08859.html.
The short version is that there are at least four drivers that have to
solve the same task to determine the number of available pwms from the
compatible. While this isn't a hard task it seems sensible to me to
describe this generic property of a piece of hardware that provides PWMs
in the device tree instead of implementing a table in the driver.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
[RFC PATCH] scsi: fix oops in scsi_uninit_cmd()
If we remove the scsi disk when running io with fio, oops occured with
the following condition.
[scsi_eh_0] [fio]
scsi_end_request
->blk_update_request
->end_bio(io returned to userspace)
close
->sd_release
->scsi_disk_put
->scsi_disk_release
->disk->private_data =
NULL;
->scsi_mq_uninit_cmd
->scsi_uninit_cmd
->scsi_cmd_to_driver
->drv is NULL, Oops
There is a small window between blk_update_request() and
scsi_mq_uninit_cmd() that scsi disk may have been released. This will
cause a oops like below:
Unable to handle kernel NULL pointer dereference at virtual address
s/sync.c:67, func=xfer, error=In[11347.116050] Mem abort info:
put/output error
[11347.121598] ESR = 0x9606
[11347.126200] Exception class = DABT (current EL), IL = 32 bits
[11347.132117] SET = 0, FnV = 0
[11347.135170] EA = 0, S1PTW = 0
[11347.138308] Data abort info:
[11347.141186] ISV = 0, ISS = 0x0006
[11347.145019] CM = 0, WnR = 0
[11347.147977] user pgtable: 4k pages, 48-bit VAs, pgdp =
a67aece2
[11347.154591] [] pgd=002f90774003,
pud=002fab098003, pmd=
[11347.163304] Internal error: Oops: 9606 [#1] PREEMPT SMP
[11347.168870] Modules linked in: hisi_sas_v3_hw hisi_sas_main libsas
[11347.175044] CPU: 56 PID: 4294 Comm: scsi_eh_2 Not tainted
4.19.0-g8052059-dirty #2
[11347.182600] Hardware name: Huawei D06/D06, BIOS Hisilicon D06 UEFI
RC0 - B601 (V6.01) 11/08/2018
[11347.191370] pstate: a0c9 (NzCv daif +PAN +UAO)
[11347.196155] pc : scsi_uninit_cmd+0x24/0x3c
[11347.200240] lr : scsi_mq_uninit_cmd+0x1c/0x30
[11347.204583] sp : 24dabb60
[11347.207884] x29: 24dabb60 x28: 24dabd38
[11347.213184] x27: 00f5b3a8 x26: 7df3b0181600
[11347.218484] x25: x24: 803bc5d36778
[11347.223783] x23: 000a x22:
[11347.229082] x21: 803bc7397000 x20: 802f9148e530
[11347.234381] x19: 802f9148e530 x18: 7e00
[11347.239679] x17: x16: 002f9e37d000
[11347.244979] x15: 7e00 x14: 3863206336203839
[11347.250278] x13: 2036302030302038 x12: a46fac3d0d363d00
[11347.255578] x11: x10: a46fac3d0d363d00
[11347.260877] x9 : 4004 x8 : eb4b
[11347.266177] x7 : 09771000 x6 : 00210d00
[11347.271476] x5 : 803bc9f5 x4 :
[11347.276775] x3 : 802fb02b4380 x2 : 802f9148e400
[11347.282075] x1 : x0 : 802f9148e530
[11347.287375] Process scsi_eh_2 (pid: 4294, stack limit =
0x7d2257f8)
[11347.294323] Call trace:
Jobs: 6 (f=6): [R[RRR1XXX1XRR3] 47.296758] scsi_uninit_cmd+0x24/0x3c
[22.7% done] [1516MB/0KB/0KB /s] [754/0/0 iops] [eta 08m:39s]
[11347.308390] scsi_mq_uninit_cmd+0x1c/0x30
[11347.312387] scsi_end_request+0x7c/0x1b8
[11347.316297] scsi_io_completion+0x464/0x668
[11347.320467] scsi_finish_command+0xbc/0x160
[11347.324636] scsi_eh_flush_done_q+0x10c/0x170
[11347.328990] sas_scsi_recover_host+0x84c/0xa98 [libsas]
[11347.334202] scsi_error_handler+0x140/0x5b0
[11347.338374] kthread+0x100/0x12c
[11347.341590] ret_from_fork+0x10/0x18
[11347.345153] Code: 71000c3f 54e9 f9404c41 f941f421 (f9400021)
[11347.351234] ---[ end trace f496aacdaa1dcc51 ]---
To fix this, get a refcount of scsi_disk in sd_init_command() to ensure
it will not be released before sd_uninit_command().
Signed-off-by: Jason Yan
---
drivers/scsi/sd.c | 46 +++---
1 file changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 5464d467e23e..6bdb8fbb570f 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1249,42 +1249,64 @@ static blk_status_t sd_setup_read_write_cmnd(struct
scsi_cmnd *SCpnt)
static blk_status_t sd_init_command(struct scsi_cmnd *cmd)
{
struct request *rq = cmd->request;
+ struct scsi_disk *sdkp = NULL;
+ blk_status_t ret;
switch (req_op(rq)) {
case REQ_OP_DISCARD:
switch (scsi_disk(rq->rq_disk)->provisioning_mode) {
case SD_LBP_UNMAP:
- return sd_setup_unmap_cmnd(cmd);
+ ret = sd_setup_unmap_cmnd(cmd);
+ break;
case SD_LBP_WS16:
- return sd_setup_write_same16_cmnd(cmd, true);
+ ret = sd_setup_write_same16_cmnd(cmd, true);
+ break;
case SD_LBP_WS10:
- return sd_setup_write_same10_cmnd(cmd, true);
+ ret = sd_setup_write_same10_cmnd(cmd, true);
+ break;
case
[PATCH -next] tpm: change the return type of calc_tpm2_event_size to size_t
calc_tpm2_event_size return size of the event which type is
size_t, If it is an invalid event, returns 0. And all the
caller use a size_t variable to check the return value, so
no need to convert to the return value type to int.
Signed-off-by: YueHaibing
---
drivers/char/tpm/eventlog/tpm2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/eventlog/tpm2.c b/drivers/char/tpm/eventlog/tpm2.c
index d8b7713..f824563 100644
--- a/drivers/char/tpm/eventlog/tpm2.c
+++ b/drivers/char/tpm/eventlog/tpm2.c
@@ -37,8 +37,8 @@
*
* Returns size of the event. If it is an invalid event, returns 0.
*/
-static int calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
- struct tcg_pcr_event *event_header)
+static size_t calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
+ struct tcg_pcr_event *event_header)
{
struct tcg_efi_specid_event_head *efispecid;
struct tcg_event_field *event_field;
--
2.7.0
[v2] PCI: mediatek: Remove MSI inner domain
There is no need to create the inner domain as a parent for MSI domian,
some feature has been implemented by MSI framework.
Remove the inner domain and its irq chip, it will be more closer to the
hardware implementation.
Signed-off-by: Jianjun Wang
---
drivers/pci/controller/pcie-mediatek.c | 83 +++---
1 file changed, 36 insertions(+), 47 deletions(-)
diff --git a/drivers/pci/controller/pcie-mediatek.c
b/drivers/pci/controller/pcie-mediatek.c
index 8d05df56158b..cd55c8ae392e 100644
--- a/drivers/pci/controller/pcie-mediatek.c
+++ b/drivers/pci/controller/pcie-mediatek.c
@@ -169,7 +169,6 @@ struct mtk_pcie_soc {
* @slot: port slot
* @irq: GIC irq
* @irq_domain: legacy INTx IRQ domain
- * @inner_domain: inner IRQ domain
* @msi_domain: MSI IRQ domain
* @lock: protect the msi_irq_in_use bitmap
* @msi_irq_in_use: bit map for assigned MSI IRQ
@@ -190,7 +189,6 @@ struct mtk_pcie_port {
u32 slot;
int irq;
struct irq_domain *irq_domain;
- struct irq_domain *inner_domain;
struct irq_domain *msi_domain;
struct mutex lock;
DECLARE_BITMAP(msi_irq_in_use, MTK_MSI_IRQS_NUM);
@@ -420,20 +418,12 @@ static void mtk_msi_ack_irq(struct irq_data *data)
writel(1 << hwirq, port->base + PCIE_IMSI_STATUS);
}
-static struct irq_chip mtk_msi_bottom_irq_chip = {
- .name = "MTK MSI",
- .irq_compose_msi_msg= mtk_compose_msi_msg,
- .irq_set_affinity = mtk_msi_set_affinity,
- .irq_ack= mtk_msi_ack_irq,
-};
-
-static int mtk_pcie_irq_domain_alloc(struct irq_domain *domain, unsigned int
virq,
-unsigned int nr_irqs, void *args)
+static irq_hw_number_t mtk_pcie_msi_get_hwirq(struct msi_domain_info *info,
+ msi_alloc_info_t *arg)
{
- struct mtk_pcie_port *port = domain->host_data;
- unsigned long bit;
+ struct mtk_pcie_port *port = info->chip_data;
+ irq_hw_number_t bit;
- WARN_ON(nr_irqs != 1);
mutex_lock(>lock);
bit = find_first_zero_bit(port->msi_irq_in_use, MTK_MSI_IRQS_NUM);
@@ -446,18 +436,14 @@ static int mtk_pcie_irq_domain_alloc(struct irq_domain
*domain, unsigned int vir
mutex_unlock(>lock);
- irq_domain_set_info(domain, virq, bit, _msi_bottom_irq_chip,
- domain->host_data, handle_edge_irq,
- NULL, NULL);
-
- return 0;
+ return bit;
}
-static void mtk_pcie_irq_domain_free(struct irq_domain *domain,
-unsigned int virq, unsigned int nr_irqs)
+static void mtk_pcie_msi_free(struct irq_domain *domain,
+ struct msi_domain_info *info, unsigned int virq)
{
struct irq_data *d = irq_domain_get_irq_data(domain, virq);
- struct mtk_pcie_port *port = irq_data_get_irq_chip_data(d);
+ struct mtk_pcie_port *port = info->chip_data;
mutex_lock(>lock);
@@ -468,46 +454,50 @@ static void mtk_pcie_irq_domain_free(struct irq_domain
*domain,
__clear_bit(d->hwirq, port->msi_irq_in_use);
mutex_unlock(>lock);
-
- irq_domain_free_irqs_parent(domain, virq, nr_irqs);
}
-static const struct irq_domain_ops msi_domain_ops = {
- .alloc = mtk_pcie_irq_domain_alloc,
- .free = mtk_pcie_irq_domain_free,
+static struct msi_domain_ops mtk_msi_domain_ops = {
+ .get_hwirq = mtk_pcie_msi_get_hwirq,
+ .msi_free = mtk_pcie_msi_free,
};
static struct irq_chip mtk_msi_irq_chip = {
- .name = "MTK PCIe MSI",
- .irq_ack= irq_chip_ack_parent,
- .irq_mask = pci_msi_mask_irq,
- .irq_unmask = pci_msi_unmask_irq,
+ .name = "MTK PCIe",
+ .irq_compose_msi_msg= mtk_compose_msi_msg,
+ .irq_write_msi_msg = pci_msi_domain_write_msg,
+ .irq_set_affinity = mtk_msi_set_affinity,
+ .irq_ack= mtk_msi_ack_irq,
+ .irq_mask = pci_msi_mask_irq,
+ .irq_unmask = pci_msi_unmask_irq,
};
static struct msi_domain_info mtk_msi_domain_info = {
- .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
- MSI_FLAG_PCI_MSIX),
- .chip = _msi_irq_chip,
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
+ MSI_FLAG_USE_DEF_CHIP_OPS | MSI_FLAG_PCI_MSIX),
+ .ops= _msi_domain_ops,
+ .chip = _msi_irq_chip,
+ .handler= handle_edge_irq,
+ .handler_name = "MSI",
};
static int mtk_pcie_allocate_msi_domains(struct mtk_pcie_port *port)
{
- struct fwnode_handle *fwnode =
of_node_to_fwnode(port->pcie->dev->of_node);
+ struct device *dev = port->pcie->dev;
+ struct fwnode_handle *fwnode = of_node_to_fwnode(dev->of_node);
+ struct msi_domain_info *info;
Re: [RFC PATCH 0/5] MTD: Add Initial Hyperbus support
On 19/02/19 12:06 PM, Vignesh R wrote: [...] > > Tested on modified TI AM654 EVM with Cypress Hyperflash S26KS512 by > creating a UBIFS partition and writing and reading files to it. > Stress tested by writing/reading 16MB flash repeatedly at different > offsets using dd commmand. > Here is the enumeration log from dmesg: https://pastebin.ubuntu.com/p/Vd5jYQT4FH/ > HyperBus specification can be found at[1] > HyperFlash datasheet can be found at[2] > TI's HBMC controller details at[3] > > [1] https://www.cypress.com/file/213356/download > [2] https://www.cypress.com/file/213346/download > [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > Table 12-5741. HyperFlash Access Sequence > > Vignesh R (5): > mtd: cfi_cmdset_0002: Add support for polling status register > dt-bindings: mtd: Add binding documentation for Hyperbus memory > devices > mtd: Add support for Hyperbus memory devices > dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory > controller > mtd: hyperbus: Add driver for TI's Hyperbus memory controller > > .../bindings/mtd/cypress,hyperbus.txt | 6 + > .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++ > MAINTAINERS | 8 + > drivers/mtd/Kconfig | 2 + > drivers/mtd/Makefile | 1 + > drivers/mtd/chips/cfi_cmdset_0002.c | 50 ++ > drivers/mtd/hyperbus/Kconfig | 23 +++ > drivers/mtd/hyperbus/Makefile | 4 + > drivers/mtd/hyperbus/core.c | 167 ++ > drivers/mtd/hyperbus/hbmc_am654.c | 105 +++ > include/linux/mtd/cfi.h | 5 + > include/linux/mtd/hyperbus.h | 73 > 12 files changed, 471 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt > create mode 100644 drivers/mtd/hyperbus/Kconfig > create mode 100644 drivers/mtd/hyperbus/Makefile > create mode 100644 drivers/mtd/hyperbus/core.c > create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c > create mode 100644 include/linux/mtd/hyperbus.h > -- Regards Vignesh
[PATCH v2 1/2] usb: dwc3: Add avoiding vbus glitch happen during xhci reset
When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS (or its control signal) will turn on immediately on related Root Hub ports. Then the VBUS will be de-asserted for a little while during xhci reset (conducted by xhci driver) for a little while and back to normal. This VBUS glitch might cause some USB devices emuration fail if kernel boot with them connected. One SW workaround which can fix this is to program all PORTSC[PP] to 0 to turn off VBUS immediately after setting host mode in DWC3 driver(per signal measurement result, it will be too late to do it in xhci-plat.c or xhci.c). Signed-off-by: Ran Wang --- Changes in v2: - Correct typos - Shorten the name to snps,host-vbus-glitches Documentation/devicetree/bindings/usb/dwc3.txt |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 8e5265e..453f562 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -106,6 +106,9 @@ Optional properties: When just one value, which means INCRX burst mode enabled. When more than one value, which means undefined length INCR burst type enabled. The values can be 1, 4, 8, 16, 32, 64, 128 and 256. + - snps,host-vbus-glitches: Power off all Root Hub ports immediately after + setting host mode to avoid vbus (negative) glitch happen in later + xhci reset. And the vbus will back to 5V automatically when reset done. - in addition all properties from usb-xhci.txt from the current directory are supported as well -- 1.7.1
Re: [PATCH] tmpfs: fix link accounting when a tmpfile is linked in
On Tue, 19 Feb 2019, Al Viro wrote:
> On Mon, Feb 18, 2019 at 09:37:52PM -0800, Hugh Dickins wrote:
> > From: "Darrick J. Wong"
> >
> > tmpfs has a peculiarity of accounting hard links as if they were separate
> > inodes: so that when the number of inodes is limited, as it is by default,
> > a user cannot soak up an unlimited amount of unreclaimable dcache memory
> > just by repeatedly linking a file.
> >
> > But when v3.11 added O_TMPFILE, and the ability to use linkat() on the fd,
> > we missed accommodating this new case in tmpfs: "df -i" shows that an
> > extra "inode" remains accounted after the file is unlinked and the fd
> > closed and the actual inode evicted. If a user repeatedly links tmpfiles
> > into a tmpfs, the limit will be hit (ENOSPC) even after they are deleted.
> >
> > Just skip the extra reservation from shmem_link() in this case: there's
> > a sense in which this first link of a tmpfile is then cheaper than a
> > hard link of another file, but the accounting works out, and there's
> > still good limiting, so no need to do anything more complicated.
> >
> > Fixes: f4e0c30c191 ("allow the temp files created by open() to be linked
> > to")
> > Reported-by: Matej Kupljen
> > Signed-off-by: Darrick J. Wong
> > Signed-off-by: Hugh Dickins
>
> FWIW, Acked-by: Al Viro
It's Worth A Lot, thanks Al. And I apologize for the cheeky "Fixes"
line, when a fair view would blame me for earlier adding the
weirdness fixed.
>
> Or I can drop it into vfs.git - up to you.
Andrew usually gathers the mm/shmem.c mods (unless it's you doing an
fs-wide sweep), so I was pointing it towards him; and I don't think it's
in dire need of a last minute rush to 5.0, though no harm in there either.
I'll say leave it to Andrew - and leave it to him to say the reverse :)
Thanks,
Hugh
[PATCH v2 2/2] usb: dwc3: Add workaround for host mode VBUS glitch when boot
When DWC3 is set to host mode by programming register DWC3_GCTL, VBUS
(or its control signal) will be turned on immediately on related Root Hub
ports. Then, the VBUS is turned off for a little while(15us) when do xhci
reset (conducted by xhci driver) and back to normal finally, we can
observe a negative glitch of related signal happen.
This VBUS glitch might cause some USB devices enumeration fail if kernel
boot with them connected. Such as LS1012AFWRY/LS1043ARDB/LX2160AQDS
/LS1088ARDB with Kingston 16GB USB2.0/Kingston USB3.0/JetFlash Transcend
4GB USB2.0 drives. The fail cases include enumerated as full-speed device
or report wrong device descriptor, etc.
One SW workaround which can fix this is by programing all xhci PORTSC[PP]
to 0 to turn off VBUS immediately after setting host mode in DWC3 driver
(per signal measurement result, it will be too late to do it in
xhci-plat.c or xhci.c). Then, after xhci reset complete in xhci driver,
PORTSC[PP]s' value will back to 1 automatically and VBUS on at that time,
no glitch happen and normal enumeration process has no impact.
Signed-off-by: Ran Wang
---
Changes in v2:
- Rename related property to 'snps,host-vbus-glitches'
- Rename related dwc member to 'host_vbus_glitches'
- Add member 'host_vbus_glitches' description in 'dwc3'
drivers/usb/dwc3/core.c | 47 +++
drivers/usb/dwc3/core.h | 12 +++-
2 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a1b126f..02d11bc 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -100,6 +100,41 @@ static int dwc3_get_dr_mode(struct dwc3 *dwc)
return 0;
}
+/*
+ * dwc3_power_of_all_roothub_ports - Power off all Root hub ports
+ * @dwc3: Pointer to our controller context structure
+ */
+static void dwc3_power_off_all_roothub_ports(struct dwc3 *dwc)
+{
+ int i, port_num;
+ u32 reg, op_regs_base, offset;
+ void __iomem*xhci_regs;
+
+ /* xhci regs is not mapped yet, do it temperary here */
+ if (dwc->xhci_resources[0].start) {
+ xhci_regs = ioremap(dwc->xhci_resources[0].start,
+ DWC3_XHCI_REGS_END);
+ if (IS_ERR(xhci_regs)) {
+ dev_err(dwc->dev, "Failed to ioremap xhci_regs\n");
+ return;
+ }
+
+ op_regs_base = HC_LENGTH(readl(xhci_regs));
+ reg = readl(xhci_regs + XHCI_HCSPARAMS1);
+ port_num = HCS_MAX_PORTS(reg);
+
+ for (i = 1; i <= port_num; i++) {
+ offset = op_regs_base + XHCI_PORTSC_BASE + 0x10*(i-1);
+ reg = readl(xhci_regs + offset);
+ reg &= ~PORT_POWER;
+ writel(reg, xhci_regs + offset);
+ }
+
+ iounmap(xhci_regs);
+ } else
+ dev_err(dwc->dev, "xhci base reg invalid\n");
+}
+
void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
{
u32 reg;
@@ -109,6 +144,15 @@ void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
reg |= DWC3_GCTL_PRTCAPDIR(mode);
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ /*
+* We have to power off all Root hub ports immediately after DWC3 set
+* to host mode to avoid VBUS glitch happen when xhci get reset later.
+*/
+ if (dwc->host_vbus_glitches) {
+ if (mode == DWC3_GCTL_PRTCAP_HOST)
+ dwc3_power_off_all_roothub_ports(dwc);
+ }
+
dwc->current_dr_role = mode;
}
@@ -1306,6 +1350,9 @@ static void dwc3_get_properties(struct dwc3 *dwc)
dwc->dis_metastability_quirk = device_property_read_bool(dev,
"snps,dis_metastability_quirk");
+ dwc->host_vbus_glitches = device_property_read_bool(dev,
+ "snps,host-vbus-glitches");
+
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
dwc->tx_de_emphasis = tx_de_emphasis;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index df87641..9b3a7ed 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -606,6 +606,14 @@
#define DWC3_OSTS_VBUSVLD BIT(1)
#define DWC3_OSTS_CONIDSTS BIT(0)
+/* Partial XHCI Register and Bit fields for quirk */
+#define XHCI_HCSPARAMS10x4
+#define XHCI_PORTSC_BASE 0x400
+#define PORT_POWER (1 << 9)
+#define HCS_MAX_PORTS(p) (((p) >> 24) & 0x7f)
+#define XHCI_HC_LENGTH(p) (((p)>>00)&0x00ff)
+#define HC_LENGTH(p) XHCI_HC_LENGTH(p)
+
/* Structures */
struct dwc3_trb;
@@ -1024,6 +1032,8 @@ struct dwc3_scratchpad_array {
* 2 - No de-emphasis
* 3 - Reserved
* @dis_metastability_quirk: set to disable metastability quirk.
+ * @host-vbus-glitches: set to avoid vbus glitch during
+ * xhci reset.
RE: [PATCH V6 1/4] dt-bindings: fsl: scu: add thermal binding
Ping...
Best Regards!
Anson Huang
> -Original Message-
> From: Anson Huang
> Sent: 2019年2月13日 13:36
> To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> catalin.mari...@arm.com; will.dea...@arm.com; rui.zh...@intel.com;
> edubez...@gmail.com; daniel.lezc...@linaro.org; Aisheng Dong
> ; ulf.hans...@linaro.org; Daniel Baluta
> ; horms+rene...@verge.net.au; Andy Gross
> ; he...@sntech.de; a...@arndb.de;
> maxime.rip...@bootlin.com; ja...@amarulasolutions.com;
> bjorn.anders...@linaro.org; enric.balle...@collabora.com;
> marc.w.gonza...@free.fr; o...@lixom.net; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> p...@vger.kernel.org
> Cc: dl-linux-imx
> Subject: RE: [PATCH V6 1/4] dt-bindings: fsl: scu: add thermal binding
>
> Gental ping...
>
> Best Regards!
> Anson Huang
>
> > -Original Message-
> > From: Anson Huang
> > Sent: 2019年2月7日 17:53
> > To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> > catalin.mari...@arm.com; will.dea...@arm.com; rui.zh...@intel.com;
> > edubez...@gmail.com; daniel.lezc...@linaro.org; Aisheng Dong
> > ; ulf.hans...@linaro.org; Daniel Baluta
> > ; horms+rene...@verge.net.au; Andy Gross
> > ; he...@sntech.de; a...@arndb.de;
> > maxime.rip...@bootlin.com; ja...@amarulasolutions.com;
> > bjorn.anders...@linaro.org; enric.balle...@collabora.com;
> > marc.w.gonza...@free.fr; o...@lixom.net; devicet...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > linux- p...@vger.kernel.org
> > Cc: dl-linux-imx
> > Subject: [PATCH V6 1/4] dt-bindings: fsl: scu: add thermal binding
> >
> > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> > controller, the system controller is in charge of system power, clock
> > and thermal sensors etc. management, Linux kernel has to communicate
> > with system controller via MU (message unit) IPC to get temperature
> > from thermal sensors, this patch adds binding doc for i.MX system
> > controller thermal driver.
> >
> > Signed-off-by: Anson Huang
> > Reviewed-by: Rob Herring
> > ---
> > ChangeLog since V5:
> > - add "imx,sensor-resource-id" in each thermal zone to pass resource
> > ID for thermal driver.
> > ---
> > .../devicetree/bindings/arm/freescale/fsl,scu.txt| 20
> >
> > 1 file changed, 20 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > index 72d481c..4b79751 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -122,6 +122,20 @@ RTC bindings based on SCU Message Protocol
> > Required properties:
> > - compatible: should be "fsl,imx8qxp-sc-rtc";
> >
> > +Thermal bindings based on SCU Message Protocol
> > +
> > +
> > +Required properties:
> > +- compatible : Must be "fsl,imx8qxp-sc-thermal";
> > +- tsens-num : Total number of thermal sensors supported;
> > +- #thermal-sensor-cells : Should be 1. See
> > +
> > Documentation/devicetree/bindings/thermal/thermal.txt
> > + for a description.
> > +- imx,sensor-resource-id : This property should be defined in each
> > +thermal
> > zone
> > + of thermal-zones node, it passes each thermal
> > zone's
> > + resource id for thermal driver to get temperature
> > via
> > + SCU IPC.
> > +
> > Example (imx8qxp):
> > -
> > lsio_mu1: mailbox@5d1c {
> > @@ -168,6 +182,12 @@ firmware {
> > rtc: rtc {
> > compatible = "fsl,imx8qxp-sc-rtc";
> > };
> > +
> > + tsens: thermal-sensor {
> > + compatible = "fsl,imx8qxp-sc-thermal";
> > + tsens-num = <1>;
> > + #thermal-sensor-cells = <1>;
> > + };
> > };
> > };
> >
> > --
> > 2.7.4
Re: [PATCHv4] random: Make /dev/random wait for input_pool initialized
> @@ -1826,7 +1830,9 @@ _random_read(int nonblock, char __user *buf, size_t
> nbytes)
>
> nbytes = min_t(size_t, nbytes, SEC_XFER_SIZE);
> while (1) {
> - n = extract_entropy_user(_pool, buf, nbytes);
> + n = input_pool.initialized
> + ? extract_entropy_user(_pool, buf, nbytes)
Aehm, sorry, now I see this creates a race condition with this code here, since
this the crng_reseed here also tries to read from the input_pool,
but input_pool.initialized is already true:
if (crng_init < 2 && entropy_bits >= 128) {
crng_reseed(_crng, r);
entropy_bits = r->entropy_count >> ENTROPY_SHIFT;
I was able to get a system in this behavior by running 3 instances of
#include
#include
#include
int main()
{
int f = open("/dev/random", O_NDELAY);
if (f<0) return 1;
for(;;)
{
unsigned char buf[16];
int x = read(f, buf, sizeof(buf));
if (x>=0)
{
int i;
printf("read %d bytes: ", x);
for (i=0; i + n = input_pool.initialized && crng_ready()
> + ? extract_entropy_user(_pool, buf, nbytes)
Thanks (for your patience :-)
Bernd.
Re: [PATCH v2 04/15] ARM: milbeaut: Add basic support for Milbeaut m10v SoC
Hi,
Thank you for your comments.
On 2019/02/18 21:15, Arnd Bergmann wrote:
On Fri, Feb 8, 2019 at 1:26 PM Sugaya Taichi
wrote:
+static int m10v_pm_enter(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ pr_err("STANDBY\n");
+ asm("wfi");
+ break;
+ case PM_SUSPEND_MEM:
+ pr_err("SUSPEND\n");
+ cpu_pm_enter();
+ cpu_suspend(0, m10v_die);
+ cpu_pm_exit();
+ break;
+ }
+ return 0;
+}
It looks like you left the pr_err() messages from bringup, they should probably
be removed now.
OK. remove the pr_err()s.
+static int __init m10v_pm_init(void)
+{
+ suspend_set_ops(_pm_ops);
+
+ return 0;
+}
+late_initcall(m10v_pm_init);
This requires a check to ensure you are actually on the right platform,
otherwise you break suspend/resume in a multiplatform kernel running
on anything other than milbeaut.
OK.
I think the solution is adding a "if statement with mlbeaut compatible"
above suspend_set_ops(_pm_ops).
Thanks,
Sugaya Taichi
Arnd
Re: [v6] coccinelle: semantic code search for missing put_device()
On Tue, 19 Feb 2019, wen.yan...@zte.com.cn wrote: > > > I would have a hard time saying which one is more reasonable to test, > > I suggest to reconsider the interpretation of this software situation once > > more. > > > since both are extremely unlikely. > > I disagree to this view because two ellipses were intentionally specified > > in published SmPL scripts. > > So some software developers found these “special use cases” important > > enough. > > >> In addition, we feel that we should probably accept this patch first, > > I disagree to this imagination because I would prefer to integrate a source > > code variant > > without a bug (which was copied from a version on 2013-05-08 by Petr > > Strnad). > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/free/pci_free_consistent.cocci?id=f7b167113753e95ae61383e234f8d10142782ace#n12 > > I hope that nicer run time behaviour can become also relevant here. > > Both cases are extremely unlikely. > Although we have tested these two methods in the existing kernel code, > considering the evolution of the kernel code, these special cases may occur, > so we are willing to take them into account. > We plan to modify the code like this: > > id = of_find_device_by_node@p1(x) > -... when != e = id > +... when != e = (T)id > +when != id = (T)e This change is fine with me. julia > > Do you have any other questions? > Thanks. > > Regards, > Wen
[PATCH -next] tee: optee: Fix unsigned comparison with less than zero
The return from the call to tee_client_invoke_func can be a
negative error code however this is being assigned to an
unsigned variable 'ret' hence the check is always false.
Fix this by making 'ret' an int.
Detected by Coccinelle ("Unsigned expression compared with zero:
ret < 0")
Fixes: c3fa24af9244 ("tee: optee: add TEE bus device enumeration support")
Signed-off-by: YueHaibing
---
drivers/tee/optee/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
index 5e4938b..1f22376 100644
--- a/drivers/tee/optee/device.c
+++ b/drivers/tee/optee/device.c
@@ -34,7 +34,7 @@ static int optee_ctx_match(struct tee_ioctl_version_data
*ver, const void *data)
static int get_devices(struct tee_context *ctx, u32 session,
struct tee_shm *device_shm, u32 *shm_size)
{
- u32 ret = 0;
+ int ret = 0;
struct tee_ioctl_invoke_arg inv_arg = {0};
struct tee_param param[4] = {0};
--
2.7.0
Re: [RFC PATCH net-next v3 07/21] ethtool: implement EVENT notifications
On Tue, Feb 19, 2019 at 12:46:08AM +0100, Andrew Lunn wrote: > On Mon, Feb 18, 2019 at 07:21:59PM +0100, Michal Kubecek wrote: > > Three types of netlink notifications are introduced: > > > > - ETHA_EVENT_NEWDEV to notify about newly registered network devices > > - ETHA_EVENT_DELDEV to notify about unregistered network devices > > - ETHA_EVENT_RENAMEDEV to notify about renamed network device > > > > The notifications are triggered by NETDEV_REGISTER, NETDEV_UNREGISTER and > > NETDEV_CHANGENAME notifiers. > > > > These notifications are intended for applications and daemons monitoring > > ethtool events to allow updating the list of existing devices without > > having to open another socket for rtnetlink. > > Hi Michal > > Does ETHA_EVENT_RENAMEDEV actually contain enough information to avoid > needing a rtnetlink lookup? If i understand the code correctly, all > you have is the new name. You don't know the old name? > > Having said that, i don't see an easy way to get access to the old > name when handling the NETDEV_CHANGENAME. We don't have the old name and without modifying the NETDEV_CHANGENAME notifier to pass it, there is probably no way to get it. But the ethtool notification also contains ifindex so that userspace applications which want to track the configuration can remember both and identify the renamed device by ifindex. Michal
Re: [PATCH 2/2] PCI: mediatek: Add controller support for MT7629
On Wed, 2019-01-23 at 15:40 +, Lorenzo Pieralisi wrote: > On Mon, Dec 24, 2018 at 07:40:28PM +0800, Jianjun Wang wrote: > > On Thu, 2018-12-20 at 12:20 -0600, Bjorn Helgaas wrote: > > > On Tue, Dec 18, 2018 at 05:19:24PM +0800, Jianjun Wang wrote: > > > > On Mon, 2018-12-17 at 15:46 +, Lorenzo Pieralisi wrote: > > > > > On Mon, Dec 17, 2018 at 08:32:47AM -0600, Bjorn Helgaas wrote: > > > > > > On Mon, Dec 17, 2018 at 04:19:39PM +0800, Jianjun Wang wrote: > > > > > > > On Thu, 2018-12-13 at 08:55 -0600, Bjorn Helgaas wrote: > > > > > > > > On Thu, Dec 06, 2018 at 09:09:13AM +0800, Jianjun Wang wrote: > > > > > > > > > The read value of BAR0 is 0x_, it's size will be > > > > > > > > > calculated as 4GB in arm64 but bogus alignment values at > > > > > > > > > arm32, the pcie device and devices behind this bridge will > > > > > > > > > not be enabled. Fix it's BAR0 resource size to guarantee > > > > > > > > > the pcie devices will be enabled correctly. > > > > > > > > > > > > > > > > So this is a hardware erratum? Per spec, a memory BAR has > > > > > > > > bit 0 hardwired to 0, and an IO BAR has bit 1 hardwired to > > > > > > > > 0. > > > > > > > > > > > > > > Yes, it only works properly on 64bit platform. > > > > > > > > > > > > I don't understand. BARs are supposed to work the same > > > > > > regardless of whether it's a 32- or 64-bit platform. If this is > > > > > > a workaround for a hardware defect, please just say that > > > > > > explicitly. > > > > > > > > > > I do not understand this either. First thing to do is to describe > > > > > the problem properly so that we can actually find a solution to > > > > > it. > > > > > > > > This BAR0 is a 64-bit memory BAR, the HW default values for this BAR > > > > is 0x___ and it could not be changed except by > > > > config write operation. > > > > > > If you literally get 0x___ when reading the BAR, that > > > is out of spec because the low-order 4 bits of a 64-bit memory BAR > > > cannot all be zero. > > > > > > A 64-bit BAR consumes two DWORDS in config space. For a 64-bit BAR0, > > > the DWORD at 0x10 contains the low-order bits, and the DWORD at 0x14 > > > contains the upper 32 bits. Bits 0-3 of the low-order DWORD (the > > > one at 0x10) are read-only, and in this case should contain the value > > > 0b1100 (0xc). That means the range is prefetchable (bit 3 == 1) and > > > the BAR is 64 bits (bits 2:1 == 10). > > > > Sorry, I have confused the HW default value and the read value of BAR > > size. The hardware default value is 0x___000c, it's a 64-bit > > BAR with prefetchable range. > > > > When we start to decoding the BAR, the read value of BAR0 at 0x10 is > > 0x0c, and the value at 0x14 is 0x_, so the read value of BAR > > size is 0x___, which will be decoded to 0x_, and > > it will be set to the end value of BAR0 resource in the pci_dev. > > > > > > > The calculated BAR size will be 0 in 32-bit platform since the > > > > phys_addr_t is a 32bit value in 32-bit platform. > > > > > > Either (1) this is a hardware defect that feeds incorrect data to the > > > BAR size calculation, or (2) there's a problem in the BAR size > > > calculation code. We need to figure out which one and work around or > > > fix it correctly. > > > > The BAR size is calculated by the code (res->end - res->start + 1) is > > fine, I think it's a hardware defect because that we can not change the > > hardware default value or just disable it since we don't using it. > > Apologies for the delay in getting back to this. > > This looks like a kernel defect, not a HW defect. > > I need some time to make up my mind on what the right fix for this > but it is most certainly not this patch. > > Lorenzo Hi Lorenzo, Is there any better idea about this patch? Thanks.
[PATCH -next] usb: typec: mux: Fix unsigned comparison with less than zero
The return from the call to fwnode_property_read_u16_array is int,
it can be a negative error code however this is being assigned to
an size_t variable 'nval', hence the check is always false.
Fix this by making 'nval' an int.
Detected by Coccinelle ("Unsigned expression compared with
zero: nval < 0")
Fixes: 96a6d031ca99 ("usb: typec: mux: Find the muxes by also matching against
the device node")
Signed-off-by: YueHaibing
---
drivers/usb/typec/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
index a5947d9..54d7497 100644
--- a/drivers/usb/typec/mux.c
+++ b/drivers/usb/typec/mux.c
@@ -126,7 +126,7 @@ static void *typec_mux_match(struct device_connection *con,
int ep, void *data)
{
const struct typec_altmode_desc *desc = data;
struct typec_mux *mux;
- size_t nval;
+ int nval;
bool match;
u16 *val;
int i;
--
2.7.0
RE: [PATCHv6 1/4] dt-bindings: add DT binding for the layerscape PCIe controller with EP mode
-Original Message- From: Lorenzo Pieralisi Sent: 2019年2月6日 2:03 To: Xiaowei Bao Cc: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo Li ; kis...@ti.com; a...@arndb.de; gre...@linuxfoundation.org; M.h. Lian ; Mingkai Hu ; Roy Zang ; kstew...@linuxfoundation.org; cyrille.pitc...@free-electrons.com; pombreda...@nexb.com; shawn@rock-chips.com; linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org Subject: Re: [PATCHv6 1/4] dt-bindings: add DT binding for the layerscape PCIe controller with EP mode On Tue, Jan 22, 2019 at 02:33:25PM +0800, Xiaowei Bao wrote: > Add the documentation for the Device Tree binding for the layerscape > PCIe controller with EP mode. > > Signed-off-by: Xiaowei Bao > Reviewed-by: Minghuan Lian > Reviewed-by: Zhiqiang Hou > Reviewed-by: Rob Herring > --- > v2: > - Add the SoC specific compatibles. > v3: > - modify the commit message. > v4: > - no change. > v5: > - no change. > v6: > - no change. > > .../devicetree/bindings/pci/layerscape-pci.txt |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) Applied the series to pci/layerscape for v5.1, thanks. [Xiaowei Bao] Hi Lorenzo, thank a lot. Lorenzo > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt > index 9b2b8d6..e20ceaa 100644 > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt > @@ -13,6 +13,7 @@ information. > > Required properties: > - compatible: should contain the platform identifier such as: > + RC mode: > "fsl,ls1021a-pcie" > "fsl,ls2080a-pcie", "fsl,ls2085a-pcie" > "fsl,ls2088a-pcie" > @@ -20,6 +21,8 @@ Required properties: > "fsl,ls1046a-pcie" > "fsl,ls1043a-pcie" > "fsl,ls1012a-pcie" > + EP mode: > + "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep" > - reg: base addresses and lengths of the PCIe controller register blocks. > - interrupts: A list of interrupt outputs of the controller. Must contain an >entry for each entry in the interrupt-names property. > -- > 1.7.1 >
Re: [PATCH] crypto: caam: set hwrng quality level
On 2/13/2019 4:49 PM, Philipp Puschmann wrote: > When quality is set to 0 this driver is not used as randomness source by > HWRNG framework at all. So set the quality and finally make this driver > work. The value of the quality was discussed before > ( see see https://patchwork.kernel.org/patch/9850669/ ) and it is still a > rough > value. > In the same thread you mention, the conclusion is that caamrng should be properly configured (TRNG instead of DRBG) before claiming to be a reliable hwrng entropy source. Horia
Re: [PATCH -next] hwrng: Fix unsigned comparison with less than zero
On Tue, 19 Feb 2019 at 12:04, YueHaibing wrote:
>
> The return from the call to tee_client_invoke_func can be a
> negative error code however this is being assigned to an
> unsigned variable 'ret' hence the check is always false.
> Fix this by making 'ret' an int.
>
> Detected by Coccinelle ("Unsigned expression compared with zero:
> ret < 0")
>
> Fixes: 5fe8b1cc6a03 ("hwrng: add OP-TEE based rng driver")
> Signed-off-by: YueHaibing
Reviewed-by: Sumit Garg
> ---
> drivers/char/hw_random/optee-rng.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/char/hw_random/optee-rng.c
> b/drivers/char/hw_random/optee-rng.c
> index 2b9fc8a..e9f4e10 100644
> --- a/drivers/char/hw_random/optee-rng.c
> +++ b/drivers/char/hw_random/optee-rng.c
> @@ -73,7 +73,7 @@ struct optee_rng_private {
> static size_t get_optee_rng_data(struct optee_rng_private *pvt_data,
> void *buf, size_t req_size)
> {
> - u32 ret = 0;
> + int ret = 0;
> u8 *rng_data = NULL;
> size_t rng_size = 0;
> struct tee_ioctl_invoke_arg inv_arg = {0};
> @@ -172,7 +172,7 @@ static struct optee_rng_private pvt_data = {
>
> static int get_optee_rng_info(struct device *dev)
> {
> - u32 ret = 0;
> + int ret = 0;
> struct tee_ioctl_invoke_arg inv_arg = {0};
> struct tee_param param[4] = {0};
>
> --
> 2.7.0
>
>
[PATCH net V2] vhost: correctly check the return value of translate_desc() in log_used()
When fail, translate_desc() returns negative value, otherwise the
number of iovs. So we should fail when the return value is negative
instead of a blindly check against zero.
Detected by CoverityScan, CID# 1442593: Control flow issues (DEADCODE)
Fixes: cc5e71075947 ("vhost: log dirty page correctly")
Acked-by: Michael S. Tsirkin
Reported-by: Stephen Hemminger
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 24a129fcdd61..a2e5dc7716e2 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1788,7 +1788,7 @@ static int log_used(struct vhost_virtqueue *vq, u64
used_offset, u64 len)
ret = translate_desc(vq, (uintptr_t)vq->used + used_offset,
len, iov, 64, VHOST_ACCESS_WO);
- if (ret)
+ if (ret < 0)
return ret;
for (i = 0; i < ret; i++) {
--
2.17.1
Re: [PATCH net] vhost: correctly check the return value of translate_desc() in log_used()
On 2019/2/16 上午12:45, Stephen Hemminger wrote:
On Fri, 15 Feb 2019 15:53:24 +0800
Jason Wang wrote:
When fail, translate_desc() returns negative value, otherwise the
number of iovs. So we should fail when the return value is negative
instead of a blindly check against zero.
Reported-by: Stephen Hemminger
Fixes: cc5e71075947 ("vhost: log dirty page correctly")
Signed-off-by: Jason Wang
Looks good. It is best to put the Addresses-Coverity-Id tag on these kind
of bug fixes so that the automated tools see it.
Ok. Will do this in V2.
Thanks
Re: [PATCH net] vhost: correctly check the return value of translate_desc() in log_used()
On 2019/2/16 上午2:03, David Miller wrote:
From: Jason Wang
Date: Fri, 15 Feb 2019 15:53:24 +0800
When fail, translate_desc() returns negative value, otherwise the
number of iovs. So we should fail when the return value is negative
instead of a blindly check against zero.
Reported-by: Stephen Hemminger
Fixes: cc5e71075947 ("vhost: log dirty page correctly")
Signed-off-by: Jason Wang
Jason, please put the Fixes tag first.
Thank you.
Ok. Will post V2.
Thanks
Re: [RESEND PATCH] amba: Allow pclk to be controlled by power domain
On Tue 05 Feb 06:58 PST 2019, Ulf Hansson wrote:
> On Thu, 31 Jan 2019 at 03:01, Bjorn Andersson
> wrote:
> >
> > On the Qualcomm SDM845 platform the apb_pclk is controlled as part of
> > the QDSS power/clock domain. Handle this by allowing amba to operate
> > without direct apb_pclk control, when a powerdomain is attached and no
> > clock is described.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> >
> > Resending this separate from the series it was originally part of.
> >
> > drivers/amba/bus.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> > index 41b706403ef7..3e13050c6d59 100644
> > --- a/drivers/amba/bus.c
> > +++ b/drivers/amba/bus.c
> > @@ -219,8 +219,13 @@ static int amba_get_enable_pclk(struct amba_device
> > *pcdev)
> > int ret;
> >
> > pcdev->pclk = clk_get(>dev, "apb_pclk");
> > - if (IS_ERR(pcdev->pclk))
> > - return PTR_ERR(pcdev->pclk);
> > + if (IS_ERR(pcdev->pclk)) {
> > + /* Continue with no clock specified, but pm_domain attached
> > */
> > + if (PTR_ERR(pcdev->pclk) == -ENOENT && pcdev->dev.pm_domain)
> > + pcdev->pclk = NULL;
>
> This looks fragile to me.
>
> I would prefer to make a do match with DT, to check whether the clock
> is needed or not.
Can you please elaborate on what you want me to match on?
As an example you can find the patch depending on this here:
https://lore.kernel.org/lkml/60ebf1617f0285c89e921bf3839cba6906d493c9.1548419933.git.saiprakash.ran...@codeaurora.org/
> Moreover, there should be no reason to check for the
> ->dev.pm_domain, because, if there was an error while doing the
> attach, that should already have been reported/propagated.
>
The purpose of this check was to extend the current requirement of a
clock to require either a clock or a power domain, rather than just
making the clock optional - which would be the result if this part is
omitted.
Regards,
Bjorn
> > + else
> > + return PTR_ERR(pcdev->pclk);
> > + }
> >
> > ret = clk_prepare_enable(pcdev->pclk);
> > if (ret)
> > --
> > 2.18.0
> >
>
> Kind regards
> Uffe
Re:[PATCH] x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32
On Mon 2019-02-18 17:22, Petr wrote:
> On Mon 2019-02-18 13:29:11, chengjian (D) wrote:
> > Hi，Jiri
> >
> >
> > This patch should be merged into 4.4 stable,
> >
> > which still use klp_write_module_reloc.
> >
> >
> > https://elixir.bootlin.com/linux/v4.4.174/source/arch/x86/kernel/livep
> > atch.c
> >
> >
> > ZeFeng may have sent a stable(4.4-y) patch to the wrong mail-list(mainline).
>
> ZeFeng or Chengjian, please, send the patch once again with
> sta...@vger.kernel.org in CC and explanation that it is needed only for 4.4
> and why.
>
> This thread is already too long and messed to be proceed by stable people
> effectively.
>
> Best Regards,
> Petr
On x86-64, for 32-bit PC-relacive branches, we can generate PLT32 relocation,
instead of PC32 relocation. and R_X86_64_PLT32 can be treated the same as
R_X86_64_PC32 since linux kernel doesn't use PLT.
commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") been fixed
for the module loading, but not fixed for livepatch relocation, which will fail
to load livepatch with the error message as follow:
relocation failed for symbol at
This issue only effacted the kernel version from 4.0 to 4.6, becauce the
function klp_write_module_reloc is introduced by:
commit b700e7f03df5 ("livepatch: kernel: add support for live patching") and
deleted by: commit 425595a7fc20
("livepatch: reuse module loader code to write relocations")
Signed-off-by: chenzefeng
---
arch/x86/kernel/livepatch.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c index
d1d35cc..579f8f8 100644
--- a/arch/x86/kernel/livepatch.c
+++ b/arch/x86/kernel/livepatch.c
@@ -58,6 +58,7 @@ int klp_write_module_reloc(struct module *mod, unsigned long
type,
val = (s32)value;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
val = (u32)(value - loc);
break;
default:
--
1.8.5.6
Re: [PATCH] KVM: Ignore LBR MSRs with no effect
On 2019/1/29 1:43, Anton Kuchin wrote: Win10 attempts to save these registers during KiSaveDebugRegisterState if LBR or BTF bits are set in MSR_IA32_DEBUGCTLMSR. It uses DR7 GE and LE flags for per-thread switching of these these features so zero value that is returned for MSR_IA32_DEBUGCTLMSR has no effect. These registers are used for debugging and shouldn't cause #GP and guest crash so just return zeroes just like we do for common x86 LBR MSRs (DEBUGCTLMSR, LAST[BRANCH|INT][TO|FROM]IP). Signed-off-by: Anton Kuchin --- arch/x86/kvm/vmx/vmx.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index f6915f10e584..8bc56cf027ed 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -1769,6 +1769,13 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) else msr_info->data = vmx->pt_desc.guest.addr_a[index / 2]; break; + case MSR_LBR_TOS: + case MSR_LBR_NHM_FROM ... MSR_LBR_NHM_FROM + 31: + case MSR_LBR_NHM_TO ... MSR_LBR_NHM_TO + 31: + case MSR_LBR_CORE_FROM ... MSR_LBR_CORE_FROM + 7: + case MSR_LBR_CORE_TO ... MSR_LBR_CORE_TO + 7: + msr_info->data = 0; + break; It's better to move LBR stack MSRs set-up to vmx/pmu_intel.c:intel_pmu_get_msr and using specified sizes (31 or 7) is not a good practice. vLBR is still in an unenabled state and please check https://lkml.org/lkml/2018/12/26/82 for dependency check. case MSR_TSC_AUX: if (!msr_info->host_initiated && !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP))
linux-next: build failure after merge of the asm-generic tree
Hi Arnd, After merging the asm-generic tree, today's linux-next build (powerpc allnoconfig) failed like this: arch/powerpc/kernel/iomap.c:18:14: error: conflicting types for 'ioread8' unsigned int ioread8(void __iomem *addr) ^~~ In file included from arch/powerpc/include/asm/io.h:653, from include/linux/io.h:25, from include/linux/irq.h:20, from arch/powerpc/include/asm/hardirq.h:6, from include/linux/hardirq.h:9, from include/linux/interrupt.h:11, from include/linux/pci.h:32, from arch/powerpc/kernel/iomap.c:7: include/asm-generic/iomap.h:29:21: note: previous declaration of 'ioread8' was here extern unsigned int ioread8(const void __iomem *addr); ^~~ arch/powerpc/kernel/iomap.c:22:14: error: conflicting types for 'ioread16' unsigned int ioread16(void __iomem *addr) ^~~~ In file included from arch/powerpc/include/asm/io.h:653, from include/linux/io.h:25, from include/linux/irq.h:20, from arch/powerpc/include/asm/hardirq.h:6, from include/linux/hardirq.h:9, from include/linux/interrupt.h:11, from include/linux/pci.h:32, from arch/powerpc/kernel/iomap.c:7: include/asm-generic/iomap.h:30:21: note: previous declaration of 'ioread16' was here extern unsigned int ioread16(const void __iomem *addr); ^~~~ arch/powerpc/kernel/iomap.c:26:14: error: conflicting types for 'ioread16be' unsigned int ioread16be(void __iomem *addr) ^~ In file included from arch/powerpc/include/asm/io.h:653, from include/linux/io.h:25, from include/linux/irq.h:20, from arch/powerpc/include/asm/hardirq.h:6, from include/linux/hardirq.h:9, from include/linux/interrupt.h:11, from include/linux/pci.h:32, from arch/powerpc/kernel/iomap.c:7: include/asm-generic/iomap.h:31:21: note: previous declaration of 'ioread16be' was here extern unsigned int ioread16be(const void __iomem *addr); ^~ arch/powerpc/kernel/iomap.c:30:14: error: conflicting types for 'ioread32' unsigned int ioread32(void __iomem *addr) ^~~~ In file included from arch/powerpc/include/asm/io.h:653, from include/linux/io.h:25, from include/linux/irq.h:20, from arch/powerpc/include/asm/hardirq.h:6, from include/linux/hardirq.h:9, from include/linux/interrupt.h:11, from include/linux/pci.h:32, from arch/powerpc/kernel/iomap.c:7: include/asm-generic/iomap.h:32:21: note: previous declaration of 'ioread32' was here extern unsigned int ioread32(const void __iomem *addr); ^~~~ arch/powerpc/kernel/iomap.c:34:14: error: conflicting types for 'ioread32be' unsigned int ioread32be(void __iomem *addr) ^~ In file included from arch/powerpc/include/asm/io.h:653, from include/linux/io.h:25, from include/linux/irq.h:20, from arch/powerpc/include/asm/hardirq.h:6, from include/linux/hardirq.h:9, from include/linux/interrupt.h:11, from include/linux/pci.h:32, from arch/powerpc/kernel/iomap.c:7: include/asm-generic/iomap.h:33:21: note: previous declaration of 'ioread32be' was here extern unsigned int ioread32be(const void __iomem *addr); ^~ arch/powerpc/kernel/iomap.c:142:6: error: conflicting types for 'ioread8_rep' void ioread8_rep(void __iomem *addr, void *dst, unsigned long count) ^~~ In file included from arch/powerpc/include/asm/io.h:653, from include/linux/io.h:25, from include/linux/irq.h:20, from arch/powerpc/include/asm/hardirq.h:6, from include/linux/hardirq.h:9, from include/linux/interrupt.h:11, from include/linux/pci.h:32, from arch/powerpc/kernel/iomap.c:7: include/asm-generic/iomap.h:82:13: note: previous declaration of 'ioread8_rep' was here extern void ioread8_rep(const void __iomem *port, void *buf, unsigned long count); ^~~ arch/powerpc/kernel/iomap.c:146:6: error: conflicting types for 'ioread16_rep' void ioread16_rep(void __iomem *addr, void *dst, unsigned long count) ^~~~ In file included from arch/powerpc/include/asm/io.h:653, from include/linux/io.h:25, from include/linux/irq.h:20, from arch/powerpc/include/asm/hardirq.h:6, from include/linux/hardirq.h:9, from include/linux/interrupt.h:11,
[RFC PATCH 1/5] mtd: cfi_cmdset_0002: Add support for polling status register
HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command
Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c
can be use as is. But these devices do not support DQ polling method of
determining chip ready/good status. These flashes provide Status
Register whose bits can be polled to know status of flash operation.
Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu
Extended Query version 1.5. Bit 0 of "Software Features supported" field
of CFI Primary Vendor-Specific Extended Query table indicates
presence/absence of status register and Bit 1 indicates whether or not
DQ polling is supported. Using these bits, its possible to determine
whether flash supports DQ polling or need to use Status Register.
Add support for polling status register to know device ready/status of
erase/write operations when DQ polling is not supported.
[1] https://www.cypress.com/file/213346/download
Signed-off-by: Vignesh R
---
Note: PRI extended query table size is bigger on 1.5 than on older
revision. Not sure if this causes problems on older rev. because of
reading beyond current size.
drivers/mtd/chips/cfi_cmdset_0002.c | 50 +
include/linux/mtd/cfi.h | 5 +++
2 files changed, 55 insertions(+)
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
b/drivers/mtd/chips/cfi_cmdset_0002.c
index 72428b6bfc47..7a4ef0237750 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -49,6 +49,14 @@
#define SST49LF008A0x005a
#define AT49BV6416 0x00d6
+/*
+ * Bits of Status Register definition for flash devices that don't
+ * support DQ polling (Eg.: Hyperflash)
+ */
+#define CFI_SR_DRB BIT(7)
+#define CFI_SR_ESB BIT(5)
+#define CFI_SR_PSB BIT(4)
+
static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *,
u_char *);
static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *,
const u_char *);
static int cfi_amdstd_write_buffers(struct mtd_info *, loff_t, size_t, size_t
*, const u_char *);
@@ -97,6 +105,18 @@ static struct mtd_chip_driver cfi_amdstd_chipdrv = {
.module = THIS_MODULE
};
+/*
+ * Use status register to poll for Erase/write completion when DQ is not
+ * supported. This is indicated by Bit[1:0] of SoftwareFeatures field in
+ * CFI Primary Vendor-Specific Extended Query table 1.5
+ */
+static int cfi_use_status_reg(struct cfi_private *cfi)
+{
+ struct cfi_pri_amdstd *extp = cfi->cmdset_priv;
+
+ return (extp->MinorVersion >= '5') &&
+ ((extp->SoftwareFeatures & 0x11) == 1);
+}
/* #define DEBUG_CFI_FEATURES */
@@ -744,8 +764,21 @@ static struct mtd_info *cfi_amdstd_setup(struct mtd_info
*mtd)
*/
static int __xipram chip_ready(struct map_info *map, unsigned long addr)
{
+ struct cfi_private *cfi = map->fldrv_priv;
map_word d, t;
+ if (cfi_use_status_reg(cfi)) {
+ /*
+* For chips that support status register, check device
+* ready bit
+*/
+ cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi,
+cfi->device_type, NULL);
+ d = map_read(map, addr);
+
+ return (d.x[0] & CFI_SR_DRB);
+ }
+
d = map_read(map, addr);
t = map_read(map, addr);
@@ -769,8 +802,25 @@ static int __xipram chip_ready(struct map_info *map,
unsigned long addr)
*/
static int __xipram chip_good(struct map_info *map, unsigned long addr,
map_word expected)
{
+ struct cfi_private *cfi = map->fldrv_priv;
map_word oldd, curd;
+ if (cfi_use_status_reg(cfi)) {
+ /*
+* For chips that support status register, check device
+* ready bit and Erase/Program status bit to know if
+* operation succeeded.
+*/
+ cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi,
+cfi->device_type, NULL);
+ curd = map_read(map, addr);
+
+ if (curd.x[0] & CFI_SR_DRB)
+ return !(curd.x[0] & (CFI_SR_PSB | CFI_SR_ESB));
+
+ return 0;
+ }
+
oldd = map_read(map, addr);
curd = map_read(map, addr);
diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index cbf77168658c..92ac82ac2329 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -233,6 +233,11 @@ struct cfi_pri_amdstd {
uint8_t VppMin;
uint8_t VppMax;
uint8_t TopBottom;
+ /* Below field are added from version 1.5 */
+ uint8_t ProgramSuspend;
+ uint8_t UnlockBypass;
+ uint8_t SecureSiliconSector;
+ uint8_t SoftwareFeatures;
} __packed;
/* Vendor-Specific PRI for Atmel chips (command set 0x0002) */
--
2.20.1
[RFC PATCH 0/5] MTD: Add Initial Hyperbus support
Cypress HyperBus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. HyperBus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory(called HyperFlash) or self refresh DRAM(called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in HyperBus specification[1]. HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clk. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller(HBMC) drivers call hb_register_device() to register a single HyperFlash device. HyperFlash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. This is an early RFC, to know if its okay to use maps framework and existing CFI compliant flash support code to support Hyperflash Also would like input on different types of HBMC master IPs out there and their programming sequences. Would appreciate any testing/review. Tested on modified TI AM654 EVM with Cypress Hyperflash S26KS512 by creating a UBIFS partition and writing and reading files to it. Stress tested by writing/reading 16MB flash repeatedly at different offsets using dd commmand. HyperBus specification can be found at[1] HyperFlash datasheet can be found at[2] TI's HBMC controller details at[3] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Vignesh R (5): mtd: cfi_cmdset_0002: Add support for polling status register dt-bindings: mtd: Add binding documentation for Hyperbus memory devices mtd: Add support for Hyperbus memory devices dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller mtd: hyperbus: Add driver for TI's Hyperbus memory controller .../bindings/mtd/cypress,hyperbus.txt | 6 + .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++ MAINTAINERS | 8 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/chips/cfi_cmdset_0002.c | 50 ++ drivers/mtd/hyperbus/Kconfig | 23 +++ drivers/mtd/hyperbus/Makefile | 4 + drivers/mtd/hyperbus/core.c | 167 ++ drivers/mtd/hyperbus/hbmc_am654.c | 105 +++ include/linux/mtd/cfi.h | 5 + include/linux/mtd/hyperbus.h | 73 12 files changed, 471 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/core.c create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c create mode 100644 include/linux/mtd/hyperbus.h -- 2.20.1
[PATCH] checkpatch: warn on bad commit description in 'Fixes' tag
There are some complaints about bad commit description in 'Fixes' tag.
Most cases are SHA1 should be at least 12 digits long. Let's extend
the existing check in checkpatch.pl to include commit description of
'Fixes' tag.
Reference: https://lkml.org/lkml/2019/2/18/1477
Signed-off-by: Changbin Du
Cc: Stephen Rothwell
Cc: Linus Torvalds
Cc: Steven Rostedt (VMware)
---
scripts/checkpatch.pl | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b737ca9d7204..6f0156778a07 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2726,11 +2726,11 @@ sub process {
if ($in_commit_log && !$commit_log_possible_stack_dump &&
$line !~ /^\s*(?:Link|Patchwork|http|https|BugLink):/i &&
$line !~ /^This reverts commit [0-9a-f]{7,40}/ &&
- ($line =~ /\bcommit\s+[0-9a-f]{5,}\b/i ||
+ ($line =~ /\b(?:commit|fixes:)\s+[0-9a-f]{5,}\b/i ||
($line =~ /(?:\s|^)[0-9a-f]{12,40}(?:[\s"'\(\[]|$)/i &&
$line !~ /[\<\[][0-9a-f]{12,40}[\>\]]/i &&
$line !~ /\bfixes:\s*[0-9a-f]{12,40}/i))) {
- my $init_char = "c";
+ my $init_str = "commit";
my $orig_commit = "";
my $short = 1;
my $long = 0;
@@ -2742,29 +2742,29 @@ sub process {
my $orig_desc = "commit description";
my $description = "";
- if ($line =~ /\b(c)ommit\s+([0-9a-f]{5,})\b/i) {
- $init_char = $1;
+ if ($line =~ /\b(commit|fixes:)\s+([0-9a-f]{5,})\b/i) {
+ $init_str = $1;
$orig_commit = lc($2);
} elsif ($line =~ /\b([0-9a-f]{12,40})\b/i) {
$orig_commit = lc($1);
}
- $short = 0 if ($line =~ /\bcommit\s+[0-9a-f]{12,40}/i);
- $long = 1 if ($line =~ /\bcommit\s+[0-9a-f]{41,}/i);
- $space = 0 if ($line =~ /\bcommit [0-9a-f]/i);
- $case = 0 if ($line =~
/\b[Cc]ommit\s+[0-9a-f]{5,40}[^A-F]/);
- if ($line =~
/\bcommit\s+[0-9a-f]{5,}\s+\("([^"]+)"\)/i) {
+ $short = 0 if ($orig_commit =~ /\b[0-9a-f]{12,40}/i);
+ $long = 1 if ($orig_commit =~ /\b[0-9a-f]{41,}/i);
+ $space = 0 if ($line =~ /\b(?:commit|fixes:)
[0-9a-f]/i);
+ $case = 0 if ($line =~
/\b(?:Commit|commit|Fixes:)\s+[0-9a-f]{5,40}[^A-F]/);
+ if ($line =~
/\b(?:commit|fixes:)\s+[0-9a-f]{5,}\s+\("([^"]+)"\)/i) {
$orig_desc = $1;
$hasparens = 1;
- } elsif ($line =~ /\bcommit\s+[0-9a-f]{5,}\s*$/i &&
+ } elsif ($line =~
/\b(?:commit|fixes:)\s+[0-9a-f]{5,}\s*$/i &&
defined $rawlines[$linenr] &&
$rawlines[$linenr] =~ /^\s*\("([^"]+)"\)/) {
$orig_desc = $1;
$hasparens = 1;
- } elsif ($line =~
/\bcommit\s+[0-9a-f]{5,}\s+\("[^"]+$/i &&
+ } elsif ($line =~
/\b(?:commit|fixes:)\s+[0-9a-f]{5,}\s+\("[^"]+$/i &&
defined $rawlines[$linenr] &&
$rawlines[$linenr] =~ /^\s*[^"]+"\)/) {
- $line =~
/\bcommit\s+[0-9a-f]{5,}\s+\("([^"]+)$/i;
+ $line =~
/\b(?:commit|fixes:)\s+[0-9a-f]{5,}\s+\("([^"]+)$/i;
$orig_desc = $1;
$rawlines[$linenr] =~ /^\s*([^"]+)"\)/;
$orig_desc .= " " . $1;
@@ -2776,8 +2776,16 @@ sub process {
if (defined($id) &&
($short || $long || $space || $case || ($orig_desc
ne $description) || !$hasparens)) {
+ if (lc $init_str eq lc "commit") {
+ my @chars = split("", $init_str);
+ $init_str = "$chars[0]ommit";
+ } else {
+ $init_str = "Fixes:"
+ }
+
ERROR("GIT_COMMIT_ID",
- "Please use git commit description style
'commit <12+ chars of sha1> (\"\")' - ie: '${init_char}ommit $id
(\"$description\")'\n" . $herecurr);
+ "Please use git commit description style
'commit/Fixes: <12+ chars of sha1> (\"\")' - ie:
[RFC PATCH 3/5] mtd: Add support for Hyperbus memory devices
Cypress HyperBus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. HyperBus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory(called HyperFlash) or self refresh DRAM(called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in HyperBus specification[1]. HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clk. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. But, Hyperbus memory controllers seem to abstract implementation details and expose a simple MMIO interface to access connected flash. Add support for registering HyperFlash devices with MTD framework. MTD maps framework along with CFI chip support framework are used to support communicate with flash. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller(HBMC) drivers call hb_register_device() to register a single HyperFlash device. HyperFlash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. Some HBMC masters need calibration/training sequence[3] to be carried out, in order for DLL inside the controller to lock, by reading a known string/pattern. This is done by repeatedly reading CFI Query Identification String. Calibration needs to be done before try to detect flash as part of CFI flash probe. HyperRAM is not supported atm. HyperBus specification can be found at[1] HyperFlash datasheet can be found at[2] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Signed-off-by: Vignesh R --- MAINTAINERS | 7 ++ drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/hyperbus/Kconfig | 23 + drivers/mtd/hyperbus/Makefile | 4 + drivers/mtd/hyperbus/core.c | 167 ++ include/linux/mtd/hyperbus.h | 73 +++ 7 files changed, 277 insertions(+) create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/core.c create mode 100644 include/linux/mtd/hyperbus.h diff --git a/MAINTAINERS b/MAINTAINERS index 08bf7418a97f..0808c22807bc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7143,6 +7143,13 @@ F: include/uapi/linux/hyperv.h F: tools/hv/ F: Documentation/ABI/stable/sysfs-bus-vmbus +HYPERBUS SUPPORT +M: Vignesh R +S: Supported +F: drivers/mtd/hyperbus/ +F: include/linux/mtd/hyperbus.h +F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt + HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-...@lists.ozlabs.org S: Odd Fixes diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 79a8ff542883..a915ff300390 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -290,4 +290,6 @@ source "drivers/mtd/spi-nor/Kconfig" source "drivers/mtd/ubi/Kconfig" +source "drivers/mtd/hyperbus/Kconfig" + endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 58fc327a5276..04c154906631 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -35,3 +35,4 @@ obj-y += chips/ lpddr/ maps/ devices/ nand/ tests/ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor/ obj-$(CONFIG_MTD_UBI) += ubi/ +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus/ diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig new file mode 100644 index ..02c38afc5c50 --- /dev/null +++ b/drivers/mtd/hyperbus/Kconfig @@ -0,0 +1,23 @@ +menuconfig MTD_HYPERBUS + tristate "Hyperbus support" + select MTD_CFI + select MTD_MAP_BANK_WIDTH_2 + select MTD_CFI_AMDSTD + select MTD_COMPLEX_MAPPINGS + help + This is the framework for the Hyperbus which can be used by + the Hyperbus Controller driver to commmunicate with + Hyperflash. See Cypress Hyperbus specification for more + details + + +if MTD_HYPERBUS + +config HBMC_AM654 + tristate "Hyperbus controller driver for AM65x SoC" + help +This is the driver for Hyperbus controller on TI's AM65x and +other SoCs + +endif # MTD_HYPERBUS + diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile new file mode 100644 index ..64e377d7f636 --- /dev/null +++ b/drivers/mtd/hyperbus/Makefile @@ -0,0 +1,4 @@ +# SPDX-License-Identifier:
[RFC PATCH 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller
Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming
IP is pretty simple and provides direct memory mapped access to
connected Flash devices.
Add basic support for the IP without DMA. Second ChipSelect is not
supported for now.
Signed-off-by: Vignesh R
---
drivers/mtd/hyperbus/hbmc_am654.c | 105 ++
1 file changed, 105 insertions(+)
create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c
diff --git a/drivers/mtd/hyperbus/hbmc_am654.c
b/drivers/mtd/hyperbus/hbmc_am654.c
new file mode 100644
index ..1f0d2dc52f9f
--- /dev/null
+++ b/drivers/mtd/hyperbus/hbmc_am654.c
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+// Author: Vignesh R
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct am654_hbmc_priv {
+ struct hb_device hbdev;
+ void __iomem*regbase;
+};
+
+static int am654_hbmc_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct am654_hbmc_priv *priv;
+ struct resource *res;
+ int err;
+
+ priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (IS_ERR(res)) {
+ dev_err(>dev, "failed to get memory resource\n");
+ return -ENOENT;
+ }
+
+ priv->regbase = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->regbase)) {
+ dev_err(dev, "Cannot remap controller address.\n");
+ return PTR_ERR(priv->regbase);
+ }
+
+ pm_runtime_enable(>dev);
+ err = pm_runtime_get_sync(>dev);
+ if (err < 0) {
+ pm_runtime_put_noidle(>dev);
+ return err;
+ }
+
+ priv->hbdev.needs_calib = true;
+ priv->hbdev.dev = >dev;
+ priv->hbdev.np = of_get_next_child(dev->of_node, NULL);
+ err = hb_register_device(>hbdev);
+ if (err) {
+ dev_err(>dev, "failed to register controller\n");
+ goto err_destroy;
+ }
+
+ return 0;
+
+err_destroy:
+ hb_unregister_device(>hbdev);
+ pm_runtime_put_sync(>dev);
+ return err;
+}
+
+static int am654_hbmc_remove(struct platform_device *pdev)
+{
+ struct am654_hbmc_priv *priv = platform_get_drvdata(pdev);
+ int ret;
+
+ ret = hb_unregister_device(>hbdev);
+ pm_runtime_put_sync(>dev);
+ pm_runtime_disable(>dev);
+
+ return ret;
+}
+
+static const struct of_device_id am654_hbmc_dt_ids[] = {
+ {
+ .compatible = "ti,am654-hbmc",
+ },
+ { /* end of table */ }
+};
+
+MODULE_DEVICE_TABLE(of, am654_hbmc_dt_ids);
+
+static struct platform_driver am654_hbmc_platform_driver = {
+ .probe = am654_hbmc_probe,
+ .remove = am654_hbmc_remove,
+ .driver = {
+ .name = "hbmc-am654",
+ .of_match_table = am654_hbmc_dt_ids,
+ },
+};
+
+module_platform_driver(am654_hbmc_platform_driver);
+
+MODULE_DESCRIPTION("HBMC driver for AM654 SoC");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:hbmc-am654");
+MODULE_AUTHOR("Vignesh R ");
--
2.20.1
[RFC PATCH 4/5] dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller
Add binding documentation for TI's Hyperbus memory controller present on
AM654 SoC.
Signed-off-by: Vignesh R
---
.../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++
MAINTAINERS | 1 +
2 files changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
new file mode 100644
index ..b70fd1795fc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
@@ -0,0 +1,27 @@
+Bindings for Hyperbus Memory Controller on TI's K3 family of SoCs
+
+Required properties:
+- compatible : "ti,am654-hbmc" for AM654 SoC
+- reg : Two entries:
+ First entry pointed to the register space of HBMC controller
+ Second entry pointing to the memory map region dedicated for
+ MMIO access to attached flash devices
+- ranges : Address range allocated for each Chipselect in the MMIO space
+
+Example:
+ hbmc: hbmc@47034000 {
+ compatible = "ti,am654-hbmc";
+ reg = <0x0 0x47034000 0x0 0x100>,
+ <0x5 0x 0x1 0x000>;
+ power-domains = <_pds 55>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x5 0x 0x400>, /* CS0 - 64MB */
+<0x1 0x5 0x0400 0x400>; /* CS1 - 64MB
+
+ /* Slave flash node */
+ flash@0{
+ compatible = "cypress,hyperflash";
+ reg = <0x0 0x400>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 0808c22807bc..a9760c5e33f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7149,6 +7149,7 @@ S:Supported
F: drivers/mtd/hyperbus/
F: include/linux/mtd/hyperbus.h
F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt
+F: Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt
HYPERVISOR VIRTUAL CONSOLE DRIVER
L: linuxppc-...@lists.ozlabs.org
--
2.20.1
[RFC PATCH 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices
Add DT binding documentation for Hyperbus memory devices. For now only Hyperflash is supported. Signed-off-by: Vignesh R --- Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt new file mode 100644 index ..cb408f80b868 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt @@ -0,0 +1,6 @@ +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus +specification and supports Cypress CFI specification 1.5 command set. + +Required properties: +- compatible : "cypress,hyperflash" for Hyperflash NOR chips +- reg : Address where flash's memory mapped space -- 2.20.1
[PATCH -next] hwrng: Fix unsigned comparison with less than zero
The return from the call to tee_client_invoke_func can be a
negative error code however this is being assigned to an
unsigned variable 'ret' hence the check is always false.
Fix this by making 'ret' an int.
Detected by Coccinelle ("Unsigned expression compared with zero:
ret < 0")
Fixes: 5fe8b1cc6a03 ("hwrng: add OP-TEE based rng driver")
Signed-off-by: YueHaibing
---
drivers/char/hw_random/optee-rng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/optee-rng.c
b/drivers/char/hw_random/optee-rng.c
index 2b9fc8a..e9f4e10 100644
--- a/drivers/char/hw_random/optee-rng.c
+++ b/drivers/char/hw_random/optee-rng.c
@@ -73,7 +73,7 @@ struct optee_rng_private {
static size_t get_optee_rng_data(struct optee_rng_private *pvt_data,
void *buf, size_t req_size)
{
- u32 ret = 0;
+ int ret = 0;
u8 *rng_data = NULL;
size_t rng_size = 0;
struct tee_ioctl_invoke_arg inv_arg = {0};
@@ -172,7 +172,7 @@ static struct optee_rng_private pvt_data = {
static int get_optee_rng_info(struct device *dev)
{
- u32 ret = 0;
+ int ret = 0;
struct tee_ioctl_invoke_arg inv_arg = {0};
struct tee_param param[4] = {0};
--
2.7.0
Re: [PATCH v1 04/12] of: Add bindings of gpu hw throttle for Tegra soctherm
On 19/2/2019 4:33 AM, Rob Herring wrote: > On Tue, Dec 18, 2018 at 03:34:36PM +0800, Wei Ni wrote: >> Add "nvidia,gpu-throt-level" property to set gpu hw >> throttle level. >> >> Signed-off-by: Wei Ni >> --- >> .../bindings/thermal/nvidia,tegra124-soctherm.txt | 17 +++-- >> include/dt-bindings/thermal/tegra124-soctherm.h| 22 >> ++ >> 2 files changed, 33 insertions(+), 6 deletions(-) >> >> diff --git >> a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt >> b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt >> index ab66d6feab4b..cf6d0be56b7a 100644 >> --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt >> +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt >> @@ -52,6 +52,15 @@ Required properties : >> Must set as following values: >> TEGRA_SOCTHERM_THROT_LEVEL_LOW, TEGRA_SOCTHERM_THROT_LEVEL_MED >> TEGRA_SOCTHERM_THROT_LEVEL_HIGH, TEGRA_SOCTHERM_THROT_LEVEL_NONE >> + - nvidia,gpu-throt-level: This property is for Tegra124 and Tegra210. > > Also, why not just use percents like nvidia,cpu-throt-percent? Hi Rob, We have to use "-level" for gpu throttle, can't use percents. It's designed by hardware. BTW, for the cpu-throt, it use "-level" for t132, and use "-percent" for t124 and t210. Thanks. Wei. > >> +It is the level of pulse skippers, which used to throttle clock >> +frequencies. It indicates gpu clock throttling depth and can be >> +programmed to any of the following values which represent a >> throttling >> +percentage: >> +TEGRA_SOCTHERM_THROT_LEVEL_NONE (0%) >> +TEGRA_SOCTHERM_THROT_LEVEL_LOW (50%), >> +TEGRA_SOCTHERM_THROT_LEVEL_MED (75%), >> +TEGRA_SOCTHERM_THROT_LEVEL_HIGH (85%). >>- #cooling-cells: Should be 1. This cooling device only support >> on/off state. >> See ./thermal.txt for a description of this property.
[PATCH v2] arm64: dts: qcs404: evb: Fix voltage for l3
PMS405 L3 is outside the acceptable range, causing PCIe to fail. Fix
this.
Fixes: 0b363f5b871c ("arm64: dts: qcom: qcs404: Add PMS405 RPM regulators")
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Rebased upon
https://lore.kernel.org/lkml/20181213183200.3204-1-bjorn.anders...@linaro.org/
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index 3a7f0d42e35a..6146f3577961 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -87,7 +87,7 @@
};
vreg_l3_1p05: l3 {
- regulator-min-microvolt = <976000>;
+ regulator-min-microvolt = <1048000>;
regulator-max-microvolt = <116>;
};
--
2.18.0
Re: [PATCH v1 11/12] of: Add bindings of OC hw throttle for Tegra soctherm
On 19/2/2019 4:32 AM, Rob Herring wrote:
> On Tue, Dec 18, 2018 at 03:34:43PM +0800, Wei Ni wrote:
>> Add OC HW throttle configuration for soctherm in DT.
>> It is used to describe the OCx throttle events.
>>
>> Signed-off-by: Wei Ni
>> ---
>> .../bindings/thermal/nvidia,tegra124-soctherm.txt | 26
>> ++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> index cf6d0be56b7a..d112a8e59ec3 100644
>> --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> @@ -64,6 +64,21 @@ Required properties :
>>- #cooling-cells: Should be 1. This cooling device only support
>> on/off state.
>> See ./thermal.txt for a description of this property.
>>
>> + Optional properties: The following properties are T210 specific and
>> + valid only for OCx throttle events.
>> + - nvidia,count-threshold: Specifies the number of OC events that are
>> +required for triggering an interrupt. Interrupts are not triggered
>> if
>> +the property is missing. A value of 0 will interrupt on every OC
>> alarm.
>> + - nvidia,polarity-active-low: Configures the polarity of the OC alaram
>> +signal. Accepted values are 1 for assert low and 0 for assert high.
>> +Default value is 0.
>
> Why not boolean?
Ok, will change to use boolean.
>
>> + - nvidia,alarm-filter: Number of clocks to filter event. When the
>> filter
>> +expires (which means the OC event has not occurred for a long time),
>> +the counter is cleared and filter is rearmed. Default value is 0.
>> + - nvidia,throttle-period: Specifies the number of uSec for which
>> +throttling is engaged after the OC event is deasserted. Default
>> value
>> +is 0.
>
> Needs a unit suffix as defined in property-units.txt.
Yes, will add suffix "-us" for it.
>
>> +
>> Optional properties:
>> - nvidia,thermtrips : When present, this property specifies the temperature
>> at
>>which the soctherm hardware will assert the thermal trigger signal to the
>> @@ -134,6 +149,17 @@ Example :
>> * arbiter will select the highest priority as the
>> final throttle
>> * settings to skip cpu pulse.
>> */
>> +
>> +throttle_oc1: oc1 {
>> +nvidia,priority = <50>;
>> +nvidia,polarity-active-low = <1>;
>> +nvidia,count-threshold = <100>;
>> +nvidia,alarm-filter = <510>;
>> +nvidia,throttle-period = <0>;
>> +nvidia,cpu-throt-percent = <75>;
>> +nvidia,gpu-throt-level =
>> +
>> ;
>> +};
>> };
>> };
>>
>> --
>> 2.7.4
>>
Re: [PATCH 4.20 11/50] signal: Always notice exiting tasks
On 13. 02. 19, 19:38, Greg Kroah-Hartman wrote:
> 4.20-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Eric W. Biederman
>
> commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.
>
> Recently syzkaller was able to create unkillablle processes by
> creating a timer that is delivered as a thread local signal on SIGHUP,
> and receiving SIGHUP SA_NODEFERER. Ultimately causing a loop
> failing to deliver SIGHUP but always trying.
>
> Upon examination it turns out part of the problem is actually most of
> the solution. Since 2.5 signal delivery has found all fatal signals,
> marked the signal group for death, and queued SIGKILL in every threads
> thread queue relying on signal->group_exit_code to preserve the
> information of which was the actual fatal signal.
>
> The conversion of all fatal signals to SIGKILL results in the
> synchronous signal heuristic in next_signal kicking in and preferring
> SIGHUP to SIGKILL. Which is especially problematic as all
> fatal signals have already been transformed into SIGKILL.
>
> Instead of dequeueing signals and depending upon SIGKILL to
> be the first signal dequeued, first test if the signal group
> has already been marked for death. This guarantees that
> nothing in the signal queue can prevent a process that needs
> to exit from exiting.
>
> Cc: sta...@vger.kernel.org
> Tested-by: Dmitry Vyukov
> Reported-by: Dmitry Vyukov
> Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
> History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> Signed-off-by: "Eric W. Biederman"
> Signed-off-by: Greg Kroah-Hartman
This patch breaks strace self-tests in 4.20.9. In particular,
"threads-execve":
https://github.com/strace/strace/blob/master/tests/threads-execve.c
https://github.com/strace/strace/blob/master/tests/threads-execve.test
The test received some fix a day ago, but it did not help in this case:
https://github.com/strace/strace/commit/2a50278b9
Only a revert of the above patch helped.
I don't know if the strace's test is broken (which is quite usual in
cases like these) or the patch affects some user-visible behaviour --
e.g. could this be a reason for sh failures in the build farm?
Any ideas?
The failure is (the test output is non-unified diff: "<" lines are
expected, ">" is actual output from strace):
> FAIL: threads-execve
>
>
> 11,12c11
> < 19311 execve("../threads-execve", ["../threads-execve", "8", "2"],
> 0x7ffc2447c258 /* 63 vars */
> < 19181 <... rt_sigsuspend resumed>) = ?
> ---
>> 19311 execve("../threads-execve", ["../threads-execve", "8", "2"],
>> 0x7ffc2447c258 /* 63 vars */
> 17,18c16
> < 19395 execve("../threads-execve", ["../threads-execve", "8", "3"],
> 0x7ffdedb69ee8 /* 63 vars */
> < 19181 <... nanosleep resumed> ) = ?
> ---
>> 19395 execve("../threads-execve", ["../threads-execve", "8", "3"],
>> 0x7ffdedb69ee8 /* 63 vars */
> ...
> 11,12c11
> < 22715 execve("../threads-execve", ["../threads-execve", "8", "2"],
> 0x7fff2ea03388 /* 63 vars */
> < 22657 <... rt_sigsuspend resumed>) = ?
> ---
>> 22715 execve("../threads-execve", ["../threads-execve", "8", "2"],
>> 0x7fff2ea03388 /* 63 vars */
> 17,18c16
> < 22764 execve("../threads-execve", ["../threads-execve", "8", "3"],
> 0x7ffc5ea29658 /* 63 vars */
> < 22657 <... nanosleep resumed> ) = ?
> ---
>> 22764 execve("../threads-execve", ["../threads-execve", "8", "3"],
>> 0x7ffc5ea29658 /* 63 vars */
> threads-execve.test: failed test: ../../strace -a21 -f -esignal=none -e
> trace=execve,exit,nanosleep,rt_sigsuspend ../threads-execve output mismatch
> ---
> kernel/signal.c |6 ++
> 1 file changed, 6 insertions(+)
>
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2393,6 +2393,11 @@ relock:
> goto relock;
> }
>
> + /* Has this task already been marked for death? */
> + ksig->info.si_signo = signr = SIGKILL;
> + if (signal_group_exit(signal))
> + goto fatal;
> +
> for (;;) {
> struct k_sigaction *ka;
>
> @@ -2488,6 +2493,7 @@ relock:
> continue;
> }
>
> + fatal:
> spin_unlock_irq(>siglock);
>
> /*
>
>
--
js
[PATCH] csky: Fixup vdsp issues in kernel
From: Guo Ren This fixup is continue to commit 35ff802af1c4 (csky: fixup remove vdsp implement for kernel.) and in that patch I didn't finish the job. We must forbid gcc to generate any vdsp & fpu instructions and remove vdsp asm in memmove.S. eg: For GCC it's -mcpu=ck860 and For AS it's -Wa,-mcpu=ck860fv Signed-off-by: Guo Ren --- arch/csky/Makefile| 2 +- arch/csky/abiv2/memmove.S | 6 +- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/csky/Makefile b/arch/csky/Makefile index 3607a6e..6b87f6c 100644 --- a/arch/csky/Makefile +++ b/arch/csky/Makefile @@ -36,7 +36,7 @@ endif ifneq ($(CSKYABI),) MCPU_STR = $(CPUTYPE)$(FPUEXT)$(VDSPEXT)$(TEEEXT) -KBUILD_CFLAGS += -mcpu=$(MCPU_STR) +KBUILD_CFLAGS += -mcpu=$(CPUTYPE) -Wa,-mcpu=$(MCPU_STR) KBUILD_CFLAGS += -DCSKYCPU_DEF_NAME=\"$(MCPU_STR)\" KBUILD_CFLAGS += -msoft-float -mdiv KBUILD_CFLAGS += -fno-tree-vectorize diff --git a/arch/csky/abiv2/memmove.S b/arch/csky/abiv2/memmove.S index b0c42ec..5721e73 100644 --- a/arch/csky/abiv2/memmove.S +++ b/arch/csky/abiv2/memmove.S @@ -35,11 +35,7 @@ ENTRY(memmove) .L_len_larger_16bytes: subir1, 16 subir0, 16 -#if defined(__CSKY_VDSPV2__) - vldx.8 vr0, (r1), r19 - PRE_BNEZAD (r18) - vstx.8 vr0, (r0), r19 -#elif defined(__CK860__) +#if defined(__CK860__) ldw r3, (r1, 12) stw r3, (r0, 12) ldw r3, (r1, 8) -- 2.7.4
[PATCH] doc: trace: Fix documentation for uprobe_profile
uprobe_profile has filename and number of probe hits information for each uprobe event. The documentation erroneously talks about probe mis-hits. Update the documentation to the correct information. Cc: Masami Hiramatsu Cc: Steven Rostedt Reported-by: KAUSTUBH RAJENDRA WELANKAR Signed-off-by: Srikar Dronamraju --- Documentation/trace/uprobetracer.rst | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/Documentation/trace/uprobetracer.rst b/Documentation/trace/uprobetracer.rst index 4c3bfde2..4346e23 100644 --- a/Documentation/trace/uprobetracer.rst +++ b/Documentation/trace/uprobetracer.rst @@ -73,10 +73,9 @@ For $comm, the default type is "string"; any other type is invalid. Event Profiling --- -You can check the total number of probe hits and probe miss-hits via -/sys/kernel/debug/tracing/uprobe_profile. -The first column is event name, the second is the number of probe hits, -the third is the number of probe miss-hits. +You can check the total number of probe hits per event via +/sys/kernel/debug/tracing/uprobe_profile. The first column is the filename, +the second is the event name, the third is the number of probe hits. Usage examples -- -- 2.7.4
Re: [PATCH V3 1/5] genirq/affinity: don't mark 'affd' as const
On Tue, 19 Feb 2019, 陈华才 wrote: > > I've tested, this patch can fix the nvme problem, but it can't be applied > to 4.19 because of different context. And, I still think my original solution > (genirq/affinity: Assign default affinity to pre/post vectors) is correct. > There may be similar problems except nvme. As I explained you in great length, it is not correct because it's just papering over the underlying problem. Please stop advertising semantically broken duct tape solutions. Thanks, tglx
Re: [PATCH v2 1/3] arm64: mm: use appropriate ctors for page tables
+ Matthew Wilcox
On 02/19/2019 11:02 AM, Yu Zhao wrote:
> On Tue, Feb 19, 2019 at 09:51:01AM +0530, Anshuman Khandual wrote:
>>
>>
>> On 02/19/2019 04:43 AM, Yu Zhao wrote:
>>> For pte page, use pgtable_page_ctor(); for pmd page, use
>>> pgtable_pmd_page_ctor() if not folded; and for the rest (pud,
>>> p4d and pgd), don't use any.
>> pgtable_page_ctor()/dtor() is not optional for any level page table page
>> as it determines the struct page state and zone statistics.
>
> This is not true. pgtable_page_ctor() is only meant for user pte
> page. The name isn't perfect (we named it this way before we had
> split pmd page table lock, and never bothered to change it).
>
> The commit cccd843f54be ("mm: mark pages in use for page tables")
> clearly states so:
> Note that only pages currently accounted as NR_PAGETABLES are
> tracked as PageTable; this does not include pgd/p4d/pud/pmd pages.
I think the commit is the following one and it does say so. But what is
the rationale of tagging only PTE page as PageTable and updating the zone
stat but not doing so for higher level page table pages ? Are not they
used as page table pages ? Should not they count towards NR_PAGETABLE ?
1d40a5ea01d53251c ("mm: mark pages in use for page tables")
>
> I'm sure if we go back further, we can find similar stories: we
> don't set PageTable on page tables other than pte; and we don't
> account page tables other than pte. I don't have any objection if
> you want change these two. But please make sure they are consistent
> across all archs.
pgtable_page_ctor/dtor() use across arch is not consistent and there is a need
for generalization which has been already acknowledged earlier. But for now we
can atleast fix this on arm64.
https://lore.kernel.org/lkml/1547619692-7946-1-git-send-email-anshuman.khand...@arm.com/
>
>> We should not skip it for any page table page.
>
> In fact, calling it on pmd/pud/p4d is peculiar, and may even be
> considered wrong. AFAIK, no other arch does so.
Why would it be considered wrong ? IIUC archs have their own understanding
of this and there are different implementations. But doing something for
PTE page and skipping for others is plain inconsistent.
>
>> As stated before pgtable_pmd_page_ctor() is not a replacement for
>> pgtable_page_ctor().
>
> pgtable_pmd_page_ctor() must be used on user pmd. For kernel pmd,
> it's okay to use pgtable_page_ctor() instead only because kernel
> doesn't have thp.
The only extra thing to be done for THP is initializing page->pmd_huge_pte
apart from calling pgtable_page_ctor(). Right not it just works on arm64
may be because page->pmd_huge_pte never gets accessed before it's init and
no path checks for it when not THP. Its better to init/reset pmd_huge_pte.
Re: [PATCH v1 04/12] of: Add bindings of gpu hw throttle for Tegra soctherm
On 19/2/2019 4:29 AM, Rob Herring wrote:
> On Tue, Dec 18, 2018 at 03:34:36PM +0800, Wei Ni wrote:
>> Add "nvidia,gpu-throt-level" property to set gpu hw
>> throttle level.
>>
>> Signed-off-by: Wei Ni
>> ---
>> .../bindings/thermal/nvidia,tegra124-soctherm.txt | 17 +++--
>> include/dt-bindings/thermal/tegra124-soctherm.h| 22
>> ++
>> 2 files changed, 33 insertions(+), 6 deletions(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> index ab66d6feab4b..cf6d0be56b7a 100644
>> --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
>> @@ -52,6 +52,15 @@ Required properties :
>> Must set as following values:
>> TEGRA_SOCTHERM_THROT_LEVEL_LOW, TEGRA_SOCTHERM_THROT_LEVEL_MED
>> TEGRA_SOCTHERM_THROT_LEVEL_HIGH, TEGRA_SOCTHERM_THROT_LEVEL_NONE
>> + - nvidia,gpu-throt-level: This property is for Tegra124 and Tegra210.
>> +It is the level of pulse skippers, which used to throttle clock
>> +frequencies. It indicates gpu clock throttling depth and can be
>> +programmed to any of the following values which represent a
>> throttling
>> +percentage:
>> +TEGRA_SOCTHERM_THROT_LEVEL_NONE (0%)
>> +TEGRA_SOCTHERM_THROT_LEVEL_LOW (50%),
>> +TEGRA_SOCTHERM_THROT_LEVEL_MED (75%),
>> +TEGRA_SOCTHERM_THROT_LEVEL_HIGH (85%).
>>- #cooling-cells: Should be 1. This cooling device only support
>> on/off state.
>> See ./thermal.txt for a description of this property.
>>
>> @@ -96,22 +105,26 @@ Example :
>> throttle-cfgs {
>> /*
>> * When the "heavy" cooling device triggered,
>> - * the HW will skip cpu clock's pulse in 85% depth
>> + * the HW will skip cpu clock's pulse in 85% depth,
>> + * skip gpu clock's pulse in 85% level
>> */
>> throttle_heavy: heavy {
>> nvidia,priority = <100>;
>> nvidia,cpu-throt-percent = <85>;
>> +nvidia,gpu-throt-level =
>> ;
>>
>> #cooling-cells = <1>;
>> };
>>
>> /*
>> * When the "light" cooling device triggered,
>> - * the HW will skip cpu clock's pulse in 50% depth
>> + * the HW will skip cpu clock's pulse in 50% depth,
>> + * skip gpu clock's pulse in 50% level
>> */
>> throttle_light: light {
>> nvidia,priority = <80>;
>> nvidia,cpu-throt-percent = <50>;
>> +nvidia,gpu-throt-level =
>> ;
>>
>> #cooling-cells = <1>;
>> };
>> diff --git a/include/dt-bindings/thermal/tegra124-soctherm.h
>> b/include/dt-bindings/thermal/tegra124-soctherm.h
>> index c15e8b709a0d..75853df1c609 100644
>> --- a/include/dt-bindings/thermal/tegra124-soctherm.h
>> +++ b/include/dt-bindings/thermal/tegra124-soctherm.h
>> @@ -1,5 +1,19 @@
>> /* SPDX-License-Identifier: GPL-2.0 */
>> /*
>> + * Copyright (c) 2014 - 2018, NVIDIA CORPORATION. All rights reserved.
>> + *
>> + * Author:
>> + * Mikko Perttunen
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>
> Why are you adding this?
We doesn't need it, will remove it.
>
>> * This header provides constants for binding nvidia,tegra124-soctherm.
>> */
>>
>> @@ -12,9 +26,9 @@
>> #define TEGRA124_SOCTHERM_SENSOR_PLLX 3
>> #define TEGRA124_SOCTHERM_SENSOR_NUM 4
>>
>> -#define TEGRA_SOCTHERM_THROT_LEVEL_LOW 0
>> -#define TEGRA_SOCTHERM_THROT_LEVEL_MED 1
>> -#define TEGRA_SOCTHERM_THROT_LEVEL_HIGH 2
>> -#define TEGRA_SOCTHERM_THROT_LEVEL_NONE -1
>> +#define TEGRA_SOCTHERM_THROT_LEVEL_NONE 0
>> +#define TEGRA_SOCTHERM_THROT_LEVEL_LOW 1
>> +#define TEGRA_SOCTHERM_THROT_LEVEL_MED 2
>> +#define TEGRA_SOCTHERM_THROT_LEVEL_HIGH 3
>
> You are breaking an ABI.
>
> Rob
>
Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel
> /proc/kheaders.txz This is gross. > The feature is also buildable as a module just in case the user desires > it not being part of the kernel image. This makes it possible to load > and unload the headers on demand. A tracing program, or a kernel module > builder can load the module, do its operations, and then unload the > module to save kernel memory. Please explain how keeping headers on the filesystem is not OK due to "licensing and other issues" but keeping a module on the filesystem is OK. > > I can route it via bpf-next tree if there are no objections. Please don't. IKHD_ST IKHD_ED are bogus artifacts as others mentioned. proc_create(S_IFREG) is redundant. seq_file.h is not needed as is THIS_MODULE. I'd say such data should live in their own section for easy extraction with "objdump -j", something /proc/config.gz never did.
[PATCH v2 1/7] clk: gcc-qcs404: Add PCIe resets
Enabling PCIe requires several of the PCIe related resets from GCC, so
add them all.
Reviewed-by: Niklas Cassel
Acked-by: Stephen Boyd
Signed-off-by: Bjorn Andersson
---
drivers/clk/qcom/gcc-qcs404.c | 7 +++
include/dt-bindings/clock/qcom,gcc-qcs404.h | 7 +++
2 files changed, 14 insertions(+)
diff --git a/drivers/clk/qcom/gcc-qcs404.c b/drivers/clk/qcom/gcc-qcs404.c
index 64da032bb9ed..5aed43923239 100644
--- a/drivers/clk/qcom/gcc-qcs404.c
+++ b/drivers/clk/qcom/gcc-qcs404.c
@@ -2675,6 +2675,13 @@ static const struct qcom_reset_map gcc_qcs404_resets[] =
{
[GCC_PCIE_0_PHY_BCR] = { 0x3e004 },
[GCC_PCIE_0_LINK_DOWN_BCR] = { 0x3e038 },
[GCC_PCIEPHY_0_PHY_BCR] = { 0x3e03c },
+ [GCC_PCIE_0_AXI_MASTER_STICKY_ARES] = { 0x3e040, 6},
+ [GCC_PCIE_0_AHB_ARES] = { 0x3e040, 5 },
+ [GCC_PCIE_0_AXI_SLAVE_ARES] = { 0x3e040, 4 },
+ [GCC_PCIE_0_AXI_MASTER_ARES] = { 0x3e040, 3 },
+ [GCC_PCIE_0_CORE_STICKY_ARES] = { 0x3e040, 2 },
+ [GCC_PCIE_0_SLEEP_ARES] = { 0x3e040, 1 },
+ [GCC_PCIE_0_PIPE_ARES] = { 0x3e040, 0 },
[GCC_EMAC_BCR] = { 0x4e000 },
};
diff --git a/include/dt-bindings/clock/qcom,gcc-qcs404.h
b/include/dt-bindings/clock/qcom,gcc-qcs404.h
index 6ceb55ed72c6..00ab0d77b38a 100644
--- a/include/dt-bindings/clock/qcom,gcc-qcs404.h
+++ b/include/dt-bindings/clock/qcom,gcc-qcs404.h
@@ -161,5 +161,12 @@
#define GCC_PCIE_0_LINK_DOWN_BCR 11
#define GCC_PCIEPHY_0_PHY_BCR 12
#define GCC_EMAC_BCR 13
+#define GCC_PCIE_0_AXI_MASTER_STICKY_ARES 14
+#define GCC_PCIE_0_AHB_ARES15
+#define GCC_PCIE_0_AXI_SLAVE_ARES 16
+#define GCC_PCIE_0_AXI_MASTER_ARES 17
+#define GCC_PCIE_0_CORE_STICKY_ARES18
+#define GCC_PCIE_0_SLEEP_ARES 19
+#define GCC_PCIE_0_PIPE_ARES 20
#endif
--
2.18.0
[PATCH v2 3/7] phy: qcom: Add Qualcomm PCIe2 PHY driver
The Qualcomm PCIe2 PHY is based on design from Synopsys and found in
several different platforms where the QMP PHY isn't used.
Reviewed-by: Niklas Cassel
Signed-off-by: Bjorn Andersson
---
drivers/phy/qualcomm/Kconfig | 8 +
drivers/phy/qualcomm/Makefile | 1 +
drivers/phy/qualcomm/phy-qcom-pcie2.c | 331 ++
3 files changed, 340 insertions(+)
create mode 100644 drivers/phy/qualcomm/phy-qcom-pcie2.c
diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
index 32f7d34eb784..8688ce27d0a6 100644
--- a/drivers/phy/qualcomm/Kconfig
+++ b/drivers/phy/qualcomm/Kconfig
@@ -24,6 +24,14 @@ config PHY_QCOM_IPQ806X_SATA
depends on OF
select GENERIC_PHY
+config PHY_QCOM_PCIE2
+ tristate "Qualcomm PCIe Gen2 PHY Driver"
+ depends on OF && COMMON_CLK && (ARCH_QCOM || COMPILE_TEST)
+ select GENERIC_PHY
+ help
+ Enable this to support the Qualcomm PCIe PHY, used with the Synopsys
+ based PCIe controller.
+
config PHY_QCOM_QMP
tristate "Qualcomm QMP PHY Driver"
depends on OF && COMMON_CLK && (ARCH_QCOM || COMPILE_TEST)
diff --git a/drivers/phy/qualcomm/Makefile b/drivers/phy/qualcomm/Makefile
index c56efd3af205..283251d6a5d9 100644
--- a/drivers/phy/qualcomm/Makefile
+++ b/drivers/phy/qualcomm/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_PHY_ATH79_USB)+= phy-ath79-usb.o
obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
+obj-$(CONFIG_PHY_QCOM_PCIE2) += phy-qcom-pcie2.o
obj-$(CONFIG_PHY_QCOM_QMP) += phy-qcom-qmp.o
obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
diff --git a/drivers/phy/qualcomm/phy-qcom-pcie2.c
b/drivers/phy/qualcomm/phy-qcom-pcie2.c
new file mode 100644
index ..5b9409abe4cf
--- /dev/null
+++ b/drivers/phy/qualcomm/phy-qcom-pcie2.c
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2014-2017, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define PCIE20_PARF_PHY_STTS 0x3c
+#define PCIE2_PHY_RESET_CTRL 0x44
+#define PCIE20_PARF_PHY_REFCLK_CTRL2 0xa0
+#define PCIE20_PARF_PHY_REFCLK_CTRL3 0xa4
+#define PCIE20_PARF_PCS_SWING_CTRL1 0x88
+#define PCIE20_PARF_PCS_SWING_CTRL2 0x8c
+#define PCIE20_PARF_PCS_DEEMPH1 0x74
+#define PCIE20_PARF_PCS_DEEMPH2 0x78
+#define PCIE20_PARF_PCS_DEEMPH3 0x7c
+#define PCIE20_PARF_CONFIGBITS 0x84
+#define PCIE20_PARF_PHY_CTRL30x94
+#define PCIE20_PARF_PCS_CTRL 0x80
+
+#define TX_AMP_VAL 120
+#define PHY_RX0_EQ_GEN1_VAL 0
+#define PHY_RX0_EQ_GEN2_VAL 4
+#define TX_DEEMPH_GEN1_VAL 24
+#define TX_DEEMPH_GEN2_3_5DB_VAL 26
+#define TX_DEEMPH_GEN2_6DB_VAL 36
+#define PHY_TX0_TERM_OFFST_VAL 0
+
+struct qcom_phy {
+ struct device *dev;
+ void __iomem *base;
+
+ struct regulator_bulk_data vregs[2];
+
+ struct reset_control *phy_reset;
+ struct reset_control *pipe_reset;
+ struct clk *pipe_clk;
+};
+
+static int qcom_pcie2_phy_init(struct phy *phy)
+{
+ struct qcom_phy *qphy = phy_get_drvdata(phy);
+ int ret;
+
+ ret = reset_control_deassert(qphy->phy_reset);
+ if (ret) {
+ dev_err(qphy->dev, "cannot deassert pipe reset\n");
+ return ret;
+ }
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(qphy->vregs), qphy->vregs);
+ if (ret)
+ reset_control_assert(qphy->phy_reset);
+
+ return ret;
+}
+
+static int qcom_pcie2_phy_power_on(struct phy *phy)
+{
+ struct qcom_phy *qphy = phy_get_drvdata(phy);
+ int ret;
+ u32 val;
+
+ /* Program REF_CLK source */
+ val = readl(qphy->base + PCIE20_PARF_PHY_REFCLK_CTRL2);
+ val &= ~BIT(1);
+ writel(val, qphy->base + PCIE20_PARF_PHY_REFCLK_CTRL2);
+
+ usleep_range(1000, 2000);
+
+ /* Don't use PAD for refclock */
+ val = readl(qphy->base + PCIE20_PARF_PHY_REFCLK_CTRL2);
+ val &= ~BIT(0);
+ writel(val, qphy->base + PCIE20_PARF_PHY_REFCLK_CTRL2);
+
+ /* Program SSP ENABLE */
+ val = readl(qphy->base + PCIE20_PARF_PHY_REFCLK_CTRL3);
+ val |= BIT(0);
+ writel(val, qphy->base + PCIE20_PARF_PHY_REFCLK_CTRL3);
+
+ usleep_range(1000, 2000);
+
+ /* Assert Phy SW Reset */
+ val = readl(qphy->base + PCIE2_PHY_RESET_CTRL);
+ val |= BIT(0);
+ writel(val, qphy->base + PCIE2_PHY_RESET_CTRL);
+
+ /* Program Tx Amplitude */
+ val = readl(qphy->base + PCIE20_PARF_PCS_SWING_CTRL1);
+ val &= ~0x7f;
+ val |= TX_AMP_VAL;
+ writel(val, qphy->base + PCIE20_PARF_PCS_SWING_CTRL1);
+
+ val =
[PATCH v2 2/7] dt-bindings: phy: Add binding for Qualcomm PCIe2 PHY
The Qualcomm PCIe2 PHY is a Synopsys based PCIe PHY found in a number of
Qualcomm platforms, add a binding to describe this.
Signed-off-by: Bjorn Andersson
---
.../bindings/phy/qcom-pcie2-phy.txt | 40 +++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
b/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
new file mode 100644
index ..7da02f9d78c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
@@ -0,0 +1,40 @@
+Qualcomm PCIe2 PHY controller
+=
+
+The Qualcomm PCIe2 PHY is a Synopsys based phy found in a number of Qualcomm
+platforms.
+
+Required properties:
+ - compatible: compatible list, should be:
+ "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy"
+
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - clocks: a clock-specifier pair for the "pipe" clock
+
+ - vdda-vp-supply: phandle to low voltage regulator
+ - vdda-vph-supply: phandle to high voltage regulator
+
+ - resets: reset-specifier pairs for the "phy" and "pipe" resets
+ - reset-names: list of resets, should contain:
+ "phy" and "pipe"
+
+ - clock-output-names: name of the outgoing clock signal from the PHY PLL
+
+Example:
+ phy@7786000 {
+ compatible = "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy";
+ reg = <0x07786000 0xb8>;
+
+ clocks = < GCC_PCIE_0_PIPE_CLK>;
+ resets = < GCC_PCIEPHY_0_PHY_BCR>,
+< GCC_PCIE_0_PIPE_ARES>;
+ reset-names = "phy", "pipe";
+
+ vdda-vp-supply = <_l3_1p05>;
+ vdda-vph-supply = <_l5_1p8>;
+
+ clock-output-names = "pcie_0_pipe_clk";
+ #phy-cells = <0>;
+ };
--
2.18.0
[PATCH v2 4/7] PCI: qcom: Use clk_bulk API for 2.4.0 controllers
Before introducing the QCS404 platform, which uses the same PCIe
controller as IPQ4019, migrate this to use the bulk clock API, in order
to make the error paths slighly cleaner.
Reviewed-by: Niklas Cassel
Signed-off-by: Bjorn Andersson
---
drivers/pci/controller/dwc/pcie-qcom.c | 48 +++---
1 file changed, 13 insertions(+), 35 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
b/drivers/pci/controller/dwc/pcie-qcom.c
index d185ea5fe996..b4d8bcf6eb77 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -113,9 +113,8 @@ struct qcom_pcie_resources_2_3_2 {
};
struct qcom_pcie_resources_2_4_0 {
- struct clk *aux_clk;
- struct clk *master_clk;
- struct clk *slave_clk;
+ struct clk_bulk_data clks[3];
+ int num_clks;
struct reset_control *axi_m_reset;
struct reset_control *axi_s_reset;
struct reset_control *pipe_reset;
@@ -638,18 +637,17 @@ static int qcom_pcie_get_resources_2_4_0(struct qcom_pcie
*pcie)
struct qcom_pcie_resources_2_4_0 *res = >res.v2_4_0;
struct dw_pcie *pci = pcie->pci;
struct device *dev = pci->dev;
+ int ret;
- res->aux_clk = devm_clk_get(dev, "aux");
- if (IS_ERR(res->aux_clk))
- return PTR_ERR(res->aux_clk);
+ res->clks[0].id = "aux";
+ res->clks[1].id = "master_bus";
+ res->clks[2].id = "slave_bus";
- res->master_clk = devm_clk_get(dev, "master_bus");
- if (IS_ERR(res->master_clk))
- return PTR_ERR(res->master_clk);
+ res->num_clks = 3;
- res->slave_clk = devm_clk_get(dev, "slave_bus");
- if (IS_ERR(res->slave_clk))
- return PTR_ERR(res->slave_clk);
+ ret = devm_clk_bulk_get(dev, res->num_clks, res->clks);
+ if (ret < 0)
+ return ret;
res->axi_m_reset = devm_reset_control_get_exclusive(dev, "axi_m");
if (IS_ERR(res->axi_m_reset))
@@ -719,9 +717,7 @@ static void qcom_pcie_deinit_2_4_0(struct qcom_pcie *pcie)
reset_control_assert(res->axi_m_sticky_reset);
reset_control_assert(res->pwr_reset);
reset_control_assert(res->ahb_reset);
- clk_disable_unprepare(res->aux_clk);
- clk_disable_unprepare(res->master_clk);
- clk_disable_unprepare(res->slave_clk);
+ clk_bulk_disable_unprepare(res->num_clks, res->clks);
}
static int qcom_pcie_init_2_4_0(struct qcom_pcie *pcie)
@@ -850,23 +846,9 @@ static int qcom_pcie_init_2_4_0(struct qcom_pcie *pcie)
usleep_range(1, 12000);
- ret = clk_prepare_enable(res->aux_clk);
- if (ret) {
- dev_err(dev, "cannot prepare/enable iface clock\n");
+ ret = clk_bulk_prepare_enable(res->num_clks, res->clks);
+ if (ret)
goto err_clk_aux;
- }
-
- ret = clk_prepare_enable(res->master_clk);
- if (ret) {
- dev_err(dev, "cannot prepare/enable core clock\n");
- goto err_clk_axi_m;
- }
-
- ret = clk_prepare_enable(res->slave_clk);
- if (ret) {
- dev_err(dev, "cannot prepare/enable phy clock\n");
- goto err_clk_axi_s;
- }
/* enable PCIe clocks and resets */
val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
@@ -891,10 +873,6 @@ static int qcom_pcie_init_2_4_0(struct qcom_pcie *pcie)
return 0;
-err_clk_axi_s:
- clk_disable_unprepare(res->master_clk);
-err_clk_axi_m:
- clk_disable_unprepare(res->aux_clk);
err_clk_aux:
reset_control_assert(res->ahb_reset);
err_rst_ahb:
--
2.18.0
[PATCH v2 7/7] arm64: dts: qcom: qcs404: Add PCIe related nodes
The QCS404 has a PCIe2 PHY and a Qualcomm PCIe controller, add these to
the platform dtsi and enable them for the EVB with the perst gpio
and analog supplies defined.
Reviewed-by: Niklas Cassel
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 25 +
arch/arm64/boot/dts/qcom/qcs404.dtsi | 67
2 files changed, 92 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index 50b3589c7f15..579ddaf4f5fa 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -21,6 +21,22 @@
};
};
+ {
+ status = "ok";
+
+ perst-gpio = < 43 GPIO_ACTIVE_LOW>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_state>;
+};
+
+_phy {
+ status = "ok";
+
+ vdda-vp-supply = <_l3_1p05>;
+ vdda-vph-supply = <_l5_1p8>;
+};
+
_adsp {
status = "ok";
};
@@ -137,6 +153,15 @@
};
{
+ perst_state: perst {
+ pins = "gpio43";
+ function = "gpio";
+
+ drive-strength = <2>;
+ bias-disable;
+ output-low;
+ };
+
sdc1_on: sdc1-on {
clk {
pins = "sdc1_clk";
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index e8fd26633d57..c1ba577fc1bc 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -383,6 +384,7 @@
compatible = "qcom,gcc-qcs404";
reg = <0x0180 0x8>;
#clock-cells = <1>;
+ #reset-cells = <1>;
assigned-clocks = < GCC_APSS_AHB_CLK_SRC>;
assigned-clock-rates = <1920>;
@@ -411,6 +413,21 @@
#interrupt-cells = <4>;
};
+ pcie_phy: phy@7786000 {
+ compatible = "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy";
+ reg = <0x07786000 0xb8>;
+
+ clocks = < GCC_PCIE_0_PIPE_CLK>;
+ resets = < GCC_PCIEPHY_0_PHY_BCR>,
+< GCC_PCIE_0_PIPE_ARES>;
+ reset-names = "phy", "pipe";
+
+ clock-output-names = "pcie_0_pipe_clk";
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
sdcc1: sdcc@7804000 {
compatible = "qcom,sdhci-msm-v5";
reg = <0x07804000 0x1000>, <0x7805000 0x1000>;
@@ -777,6 +794,56 @@
status = "disabled";
};
};
+
+ pcie: pci@1000 {
+ compatible = "qcom,pcie-qcs404", "snps,dw-pcie";
+ reg = <0x1000 0xf1d>,
+ <0x1f20 0xa8>,
+ <0x0778 0x2000>,
+ <0x10001000 0x2000>;
+ reg-names = "dbi", "elbi", "parf", "config";
+ device_type = "pci";
+ linux,pci-domain = <0>;
+ bus-range = <0x00 0xff>;
+ num-lanes = <1>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x8100 0 0 0x10003000 0
0x0001>, /* I/O */
+<0x8200 0 0x10013000 0x10013000 0
0x007ed000>; /* memory */
+
+ interrupts = ;
+ interrupt-names = "msi";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 GIC_SPI 68
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 GIC_SPI 224
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 GIC_SPI 267
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 GIC_SPI 268
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+ clocks = < GCC_PCIE_0_CFG_AHB_CLK>,
+< GCC_PCIE_0_AUX_CLK>,
+< GCC_PCIE_0_MSTR_AXI_CLK>,
+< GCC_PCIE_0_SLV_AXI_CLK>;
+ clock-names = "iface", "aux", "master_bus", "slave_bus";
+
+ resets = < GCC_PCIE_0_AXI_MASTER_ARES>,
+< GCC_PCIE_0_AXI_SLAVE_ARES>,
+< GCC_PCIE_0_AXI_MASTER_STICKY_ARES>,
+< GCC_PCIE_0_CORE_STICKY_ARES>,
+< GCC_PCIE_0_BCR>,
+
[PATCH v2 0/7] QCS404 PCIe PHY and controller
This series adds support for the PCIe controller and PHY found in the Qualcomm platform QCS404. Bjorn Andersson (7): clk: gcc-qcs404: Add PCIe resets dt-bindings: phy: Add binding for Qualcomm PCIe2 PHY phy: qcom: Add Qualcomm PCIe2 PHY driver PCI: qcom: Use clk_bulk API for 2.4.0 controllers dt-bindings: PCI: qcom: Add QCS404 to the binding PCI: qcom: Add QCS404 PCIe controller support arm64: dts: qcom: qcs404: Add PCIe related nodes .../devicetree/bindings/pci/qcom,pcie.txt | 25 +- .../bindings/phy/qcom-pcie2-phy.txt | 40 +++ arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 25 ++ arch/arm64/boot/dts/qcom/qcs404.dtsi | 67 drivers/clk/qcom/gcc-qcs404.c | 7 + drivers/pci/controller/dwc/pcie-qcom.c| 108 +++--- drivers/phy/qualcomm/Kconfig | 8 + drivers/phy/qualcomm/Makefile | 1 + drivers/phy/qualcomm/phy-qcom-pcie2.c | 331 ++ include/dt-bindings/clock/qcom,gcc-qcs404.h | 7 + 10 files changed, 558 insertions(+), 61 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt create mode 100644 drivers/phy/qualcomm/phy-qcom-pcie2.c -- 2.18.0
[PATCH v2 5/7] dt-bindings: PCI: qcom: Add QCS404 to the binding
The Qualcomm QCS404 platform contains a PCIe controller, add this to the Qualcomm PCI binding document. The controller is the same version as the one used in IPQ4019, but the PHY part is described separately, hence the difference in clocks and resets. Signed-off-by: Bjorn Andersson --- .../devicetree/bindings/pci/qcom,pcie.txt | 25 +-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index 1fd703bd73e0..ada80b01bf0c 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -10,6 +10,7 @@ - "qcom,pcie-msm8996" for msm8996 or apq8096 - "qcom,pcie-ipq4019" for ipq4019 - "qcom,pcie-ipq8074" for ipq8074 + - "qcom,pcie-qcs404" for qcs404 - reg: Usage: required @@ -116,6 +117,15 @@ - "ahb" AHB clock - "aux" Auxiliary clock +- clock-names: + Usage: required for qcs404 + Value type: + Definition: Should contain the following entries + - "iface" AHB clock + - "aux" Auxiliary clock + - "master_bus" AXI Master clock + - "slave_bus" AXI Slave clock + - resets: Usage: required Value type: @@ -167,6 +177,17 @@ - "ahb" AHB Reset - "axi_m_sticky"AXI Master Sticky reset +- reset-names: + Usage: required for qcs404 + Value type: + Definition: Should contain the following entries + - "axi_m" AXI Master reset + - "axi_s" AXI Slave reset + - "axi_m_sticky"AXI Master Sticky reset + - "pipe_sticky" PIPE sticky reset + - "pwr" PWR reset + - "ahb" AHB reset + - power-domains: Usage: required for apq8084 and msm8996/apq8096 Value type: @@ -195,12 +216,12 @@ Definition: A phandle to the PCIe endpoint power supply - phys: - Usage: required for apq8084 + Usage: required for apq8084 and qcs404 Value type: Definition: List of phandle(s) as listed in phy-names property - phy-names: - Usage: required for apq8084 + Usage: required for apq8084 and qcs404 Value type: Definition: Should contain "pciephy" -- 2.18.0
[PATCH v2 6/7] PCI: qcom: Add QCS404 PCIe controller support
The QCS404 platform contains a PCIe controller of version 2.4.0 and a
Qualcomm PCIe2 PHY. The driver already supports version 2.4.0, for the
IPQ4019, but this support touches clocks and resets related to the PHY
as well, and there's no upstream driver for the PHY.
On QCS404 we must initialize the PHY, so a separate PHY driver is
implemented to take care of this and the controller driver is updated to
not require the PHY related resources. This is done by relying on the
fact that operations in both the clock and reset framework are nops when
passed NULL, so we can isolate this change to only the get_resource
function.
For QCS404 we also need to enable the AHB (iface) clock, in order to
access the register space of the controller, but as this is not part of
the IPQ4019 DT binding this is only added for new users of the 2.4.0
controller.
Reviewed-by: Niklas Cassel
Signed-off-by: Bjorn Andersson
---
drivers/pci/controller/dwc/pcie-qcom.c | 64 +++---
1 file changed, 38 insertions(+), 26 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
b/drivers/pci/controller/dwc/pcie-qcom.c
index b4d8bcf6eb77..3724ab5de956 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -113,7 +113,7 @@ struct qcom_pcie_resources_2_3_2 {
};
struct qcom_pcie_resources_2_4_0 {
- struct clk_bulk_data clks[3];
+ struct clk_bulk_data clks[4];
int num_clks;
struct reset_control *axi_m_reset;
struct reset_control *axi_s_reset;
@@ -637,13 +637,16 @@ static int qcom_pcie_get_resources_2_4_0(struct qcom_pcie
*pcie)
struct qcom_pcie_resources_2_4_0 *res = >res.v2_4_0;
struct dw_pcie *pci = pcie->pci;
struct device *dev = pci->dev;
+ bool is_ipq = of_device_is_compatible(dev->of_node,
"qcom,pcie-ipq4019");
int ret;
res->clks[0].id = "aux";
res->clks[1].id = "master_bus";
res->clks[2].id = "slave_bus";
+ res->clks[3].id = "iface";
- res->num_clks = 3;
+ /* qcom,pcie-ipq4019 is defined without "iface" */
+ res->num_clks = is_ipq ? 3 : 4;
ret = devm_clk_bulk_get(dev, res->num_clks, res->clks);
if (ret < 0)
@@ -657,27 +660,33 @@ static int qcom_pcie_get_resources_2_4_0(struct qcom_pcie
*pcie)
if (IS_ERR(res->axi_s_reset))
return PTR_ERR(res->axi_s_reset);
- res->pipe_reset = devm_reset_control_get_exclusive(dev, "pipe");
- if (IS_ERR(res->pipe_reset))
- return PTR_ERR(res->pipe_reset);
-
- res->axi_m_vmid_reset = devm_reset_control_get_exclusive(dev,
-"axi_m_vmid");
- if (IS_ERR(res->axi_m_vmid_reset))
- return PTR_ERR(res->axi_m_vmid_reset);
-
- res->axi_s_xpu_reset = devm_reset_control_get_exclusive(dev,
- "axi_s_xpu");
- if (IS_ERR(res->axi_s_xpu_reset))
- return PTR_ERR(res->axi_s_xpu_reset);
-
- res->parf_reset = devm_reset_control_get_exclusive(dev, "parf");
- if (IS_ERR(res->parf_reset))
- return PTR_ERR(res->parf_reset);
-
- res->phy_reset = devm_reset_control_get_exclusive(dev, "phy");
- if (IS_ERR(res->phy_reset))
- return PTR_ERR(res->phy_reset);
+ if (is_ipq) {
+ /*
+* These resources relates to the PHY or are secure clocks, but
+* are controlled here for IPQ4019
+*/
+ res->pipe_reset = devm_reset_control_get_exclusive(dev, "pipe");
+ if (IS_ERR(res->pipe_reset))
+ return PTR_ERR(res->pipe_reset);
+
+ res->axi_m_vmid_reset = devm_reset_control_get_exclusive(dev,
+
"axi_m_vmid");
+ if (IS_ERR(res->axi_m_vmid_reset))
+ return PTR_ERR(res->axi_m_vmid_reset);
+
+ res->axi_s_xpu_reset = devm_reset_control_get_exclusive(dev,
+
"axi_s_xpu");
+ if (IS_ERR(res->axi_s_xpu_reset))
+ return PTR_ERR(res->axi_s_xpu_reset);
+
+ res->parf_reset = devm_reset_control_get_exclusive(dev, "parf");
+ if (IS_ERR(res->parf_reset))
+ return PTR_ERR(res->parf_reset);
+
+ res->phy_reset = devm_reset_control_get_exclusive(dev, "phy");
+ if (IS_ERR(res->phy_reset))
+ return PTR_ERR(res->phy_reset);
+ }
res->axi_m_sticky_reset = devm_reset_control_get_exclusive(dev,
"axi_m_sticky");
@@ -697,9 +706,11 @@ static int qcom_pcie_get_resources_2_4_0(struct qcom_pcie
*pcie)
if (IS_ERR(res->ahb_reset))
Re: [PATCH v3 perf,bpf 05/11] perf, bpf: save bpf_prog_info in a rbtree in perf_env
> On Feb 17, 2019, at 3:05 PM, Jiri Olsa wrote:
>
> On Fri, Feb 15, 2019 at 01:53:48PM -0800, Song Liu wrote:
>
> SNIP
>
>> info_linear = bpf_program__get_prog_info_linear(fd, arrays);
>> if (IS_ERR_OR_NULL(info_linear)) {
>> @@ -151,8 +165,8 @@ static int perf_event__synthesize_one_bpf_prog(struct
>> perf_tool *tool,
>> machine, process);
>> }
>>
>> -/* Synthesize PERF_RECORD_BPF_EVENT */
>> if (opts->bpf_event) {
>> +/* Synthesize PERF_RECORD_BPF_EVENT */
>> *bpf_event = (struct bpf_event){
>> .header = {
>> .type = PERF_RECORD_BPF_EVENT,
>> @@ -165,6 +179,19 @@ static int perf_event__synthesize_one_bpf_prog(struct
>> perf_tool *tool,
>> memcpy(bpf_event->tag, info->tag, BPF_TAG_SIZE);
>> memset((void *)event + event->header.size, 0,
>> machine->id_hdr_size);
>> event->header.size += machine->id_hdr_size;
>> +
>> +/* save bpf_prog_info to env */
>> +info_node = malloc(sizeof(struct bpf_prog_info_node));
>> +if (info_node) {
>> +info_node->info_linear = info_linear;
>> +perf_env__insert_bpf_prog_info(env, info_node);
>> +info_linear = NULL;
>> +}
>
> what if the allocation fails? we don't care?
>
> jirka
My original plan is to just ignore it and accept that this program
doesn't have annotation. Any suggestion on what would be a better
approach?
Thanks,
Song
