[PATCH -tip v4 00/27] kprobes: Cleanup jprobe implementation
Hello, Since we decided to remove jprobe from kernel last year, its APIs are disabled and we worked on moving in-kernel jprobe users to kprobes or trace-events. And now no jprobe users are here anymore. This is the 4th version of the series for removing jprobe. Previous version is here: https://lkml.org/lkml/2018/5/16/1052 Unlike previous versions, this version removes jprobe from all architectures, as Ingo asked me in the previous thread. I marked this as RFC again because it introduced changes for many arch. It should be reviewed by some arch which is not simply removing code (e.g. powerpc, arm). BTW, this series are based on -tip tree as same as its previous version, and I'm sure it can be applied to linus tree/linux-next too. Series structure = Basically this series introduces 3 major changes; - Remove jprobe implementation ([2/27] - [12/27]) - Remove break_handler() related code ([13/27] - [23/27]) This should be done after (or with) removing jprobe because break_handler is only used by jprobe. (I'm not so sure, should I merge above patches into one arch-wide patch as next one does?) - Clean current_kprobe and enable preempt if pre_handler() returns !0 ([24/27] and [25/27]<- x86 specific update) This also depends on above patches because those current_kprobe and preemption are expected to be adjusted by jprobe implementation via break_handler. And some minor changes; - Document cleanup and update ([1/27], [26/27]) And finally remove jprobe stub APIs and break_handler from kprobes.h ([27/27]). Of course this depends on above patches. Since removing jprobes and break_handler related code involve archtecture specific changes in some archs, I splitted it for each arch. But "clean current_kprobe and enable preempt if pre_handler() returns !0" patch modifies all architectures, since it changes expected kprobe handler behavior. I think this would be better done in one patch for consistency. Result = I've tested it with kprobe sanity test on x86-64, and arm64 but for other archs, I just did cross-build test. With this series, we finally cleanup all jprobe code and break_handler as below. $ git grep -wi break_handler | wc -l 0 $ git grep -wi jprobe | wc -l 0 Actually, there is one place where mentioning jprobe, Documentation/kprobes.txt explains jprobe is deprecated and how to migrate jprobe user to ftrace or kprobe. I didn't remove it because it might be useful for some users. Thank you, --- Masami Hiramatsu (27): Documentation/kprobes: Fix to remove remaining jprobe kprobes: Remove jprobe API implementation kprobes/x86: Remove jprobe implementation ARC: kprobes: Remove jprobe implementation ARM: kprobes: Remove jprobe arm implementation arm64: kprobes: Remove jprobe implementation powerpc/kprobes: Remove jprobe powerpc implementation ia64: kprobes: Remove jprobe implementation MIPS: kprobes: Remove jprobe implementation s390/kprobes: Remove jprobe implementation sh: kprobes: Remove jprobe implementation sparc64: kprobes: Remove jprobe implementation kprobes: Don't check the ->break_handler() in generic kprobes code kprobes/x86: Don't call ->break_handler() in x86 kprobes ARC: kprobes: Don't call the ->break_handler() in ARC kprobes code ARM: kprobes: Don't call the ->break_handler() in arm kprobes code arm64: kprobes: Don't call the ->break_handler() in arm kprobes code powerpc/kprobes: Don't call the ->break_handler() in arm kprobes code ia64: kprobes: Don't call the ->break_handler() in ia64 kprobes code MIPS: kprobes: Don't call the ->break_handler() in MIPS kprobes code s390/kprobes: Don't call the ->break_handler() in s390 kprobes code sh: kprobes: Don't call the ->break_handler() in SH kprobes code sparc64: kprobes: Don't call the ->break_handler() in sparc64 kprobes code bpf: error-inject: kprobes: Clear current_kprobe and enable preempt in kprobe x86: kprobes: Do not disable preempt on int3 path Documentation: kprobes: Add how to change the execution path kprobes: Remove jprobe stub API Documentation/kprobes.txt | 35 +- arch/arc/include/asm/kprobes.h |2 arch/arc/kernel/kprobes.c | 50 + arch/arm/include/asm/kprobes.h |2 arch/arm/include/asm/probes.h |1 arch/arm/probes/kprobes/core.c | 135 +--- arch/arm64/include/asm/kprobes.h |1 arch/arm64/kernel/probes/kprobes.c | 86 +-- arch/ia64/include/asm/kprobes.h|2 arch/ia64/include/uapi/asm/break.h |1 arch/ia64/kernel/Makefile |2 arch/ia64/kernel/jprobes.S | 90 arch/ia64/kernel/kprobes.c | 93 + arch/mi
Re: [PATCH 05/11] PM / devfreq: governors: Return device frequency limits instead of user limits
Hi,
On 2018년 05월 26일 05:30, Matthias Kaehlcke wrote:
> The performance, powersave and simpleondemand governors can return
> df->min/max_freq, which are the user defined frequency limits.
> update_devfreq() already takes care of adjusting the target frequency
> with the user limits if necessary, therefore we can return
> df->scaling_min/max_freq instead, which is the min/max frequency
> supported by the device at a given time (depending on the
> enabled/disabled OPPs)
As you mentioned on the description, update_devfreq() adjusts
the final target frequency. So, actually, there are no any
benefits when changing from max_freq/min_freq to scaling_max/min_freq.
I think that it is not necessary.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/devfreq/governor_performance.c| 2 +-
> drivers/devfreq/governor_powersave.c | 2 +-
> drivers/devfreq/governor_simpleondemand.c | 6 +++---
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/devfreq/governor_performance.c
> b/drivers/devfreq/governor_performance.c
> index 1c990cb45098..a8e3478b3c43 100644
> --- a/drivers/devfreq/governor_performance.c
> +++ b/drivers/devfreq/governor_performance.c
> @@ -20,7 +20,7 @@ static int devfreq_performance_func(struct devfreq *df,
>* target callback should be able to get floor value as
>* said in devfreq.h
>*/
> - *freq = df->max_freq;
> + *freq = df->scaling_max_freq;
> return 0;
> }
>
> diff --git a/drivers/devfreq/governor_powersave.c
> b/drivers/devfreq/governor_powersave.c
> index 0c42f23249ef..8696efd32e5a 100644
> --- a/drivers/devfreq/governor_powersave.c
> +++ b/drivers/devfreq/governor_powersave.c
> @@ -20,7 +20,7 @@ static int devfreq_powersave_func(struct devfreq *df,
>* target callback should be able to get ceiling value as
>* said in devfreq.h
>*/
> - *freq = df->min_freq;
> + *freq = df->scaling_min_freq;
> return 0;
> }
>
> diff --git a/drivers/devfreq/governor_simpleondemand.c
> b/drivers/devfreq/governor_simpleondemand.c
> index 3da7554b4837..805fee09c754 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -46,7 +46,7 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
>
> /* Assume MAX if it is going to be divided by zero */
> if (stat->total_time == 0) {
> - *freq = df->max_freq;
> + *freq = df->scaling_max_freq;
> return 0;
> }
>
> @@ -59,13 +59,13 @@ static int devfreq_simple_ondemand_func(struct devfreq
> *df,
> /* Set MAX if it's busy enough */
> if (stat->busy_time * 100 >
> stat->total_time * dfso_upthreshold) {
> - *freq = df->max_freq;
> + *freq = df->scaling_max_freq;
> return 0;
> }
>
> /* Set MAX if we do not know the initial frequency */
> if (stat->current_frequency == 0) {
> - *freq = df->max_freq;
> + *freq = df->scaling_max_freq;
> return 0;
> }
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 2/5] media: v4l: cadence: include linux/slab.h
On Fri, May 25, 2018 at 05:25:09PM +0200, Arnd Bergmann wrote:
> I ran into a randconfig build error with the new driver:
>
> drivers/media/platform/cadence/cdns-csi2tx.c: In function 'csi2tx_probe':
> drivers/media/platform/cadence/cdns-csi2tx.c:477:11: error: implicit
> declaration of function 'kzalloc'; did you mean 'd_alloc'?
> [-Werror=implicit-function-declaration]
>
> kzalloc() is declared in linux/slab.h, so let's include this to make it
> build in all configurations.
>
> Fixes: 84b477e6d4bc ("media: v4l: cadence: Add Cadence MIPI-CSI2 TX driver")
> Signed-off-by: Arnd Bergmann
Acked-by: Maxime Ripard
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH v2 7/8] iommu: Remove IOMMU_OF_DECLARE
Hi Rob,
On 2018-05-24 19:50, Rob Herring wrote:
> Now that we use the driver core to stop deferred probe for missing
> drivers, IOMMU_OF_DECLARE can be removed.
>
> This is slightly less optimal than having a list of built-in drivers in
> that we'll now defer probe twice before giving up. This shouldn't have a
> significant impact on boot times as past discussions about deferred
> probe have given no evidence of deferred probe having a substantial
> impact.
>
> Cc: Will Deacon
> Cc: Robin Murphy
> Cc: Joerg Roedel
> Cc: Marek Szyprowski
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: Rob Clark
> Cc: Heiko Stuebner
> Cc: Frank Rowand
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: io...@lists.linux-foundation.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Herring
For Exynos IOMMU:
Acked-by: Marek Szyprowski
> ---
> drivers/iommu/arm-smmu-v3.c| 2 --
> drivers/iommu/arm-smmu.c | 7 ---
> drivers/iommu/exynos-iommu.c | 2 --
> drivers/iommu/ipmmu-vmsa.c | 3 ---
> drivers/iommu/msm_iommu.c | 2 --
> drivers/iommu/of_iommu.c | 19 +--
> drivers/iommu/qcom_iommu.c | 2 --
> drivers/iommu/rockchip-iommu.c | 2 --
> include/linux/of_iommu.h | 4
> 9 files changed, 1 insertion(+), 42 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 1d647104bccc..22bdabd3d8e0 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -2915,8 +2915,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3");
> -
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
> MODULE_AUTHOR("Will Deacon ");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 69e7c60792a8..9dd7cbaa3b0c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2211,13 +2211,6 @@ static struct platform_driver arm_smmu_driver = {
> };
> module_platform_driver(arm_smmu_driver);
>
> -IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1");
> -IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2");
> -IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
> -IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401");
> -IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500");
> -IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2");
> -
> MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
> MODULE_AUTHOR("Will Deacon ");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 85879cfec52f..b128cb4372d3 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1390,5 +1390,3 @@ static int __init exynos_iommu_init(void)
> return ret;
> }
> core_initcall(exynos_iommu_init);
> -
> -IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu");
> diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
> index 40ae6e87cb88..f026aa16d5f1 100644
> --- a/drivers/iommu/ipmmu-vmsa.c
> +++ b/drivers/iommu/ipmmu-vmsa.c
> @@ -1108,9 +1108,6 @@ static void __exit ipmmu_exit(void)
> subsys_initcall(ipmmu_init);
> module_exit(ipmmu_exit);
>
> -IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa");
> -IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795");
> -
> MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
> MODULE_AUTHOR("Laurent Pinchart ");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 0d3350463a3f..27377742600d 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -877,7 +877,5 @@ static void __exit msm_iommu_driver_exit(void)
> subsys_initcall(msm_iommu_driver_init);
> module_exit(msm_iommu_driver_exit);
>
> -IOMMU_OF_DECLARE(msm_iommu_of, "qcom,apq8064-iommu");
> -
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Stepan Moskovchenko ");
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 2aac8387717c..1904ccf9fc4e 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -27,9 +27,6 @@
>
> #define NO_IOMMU1
>
> -static const struct of_device_id __iommu_of_table_sentinel
> - __used __section(__iommu_of_table_end);
> -
> /**
>* of_get_dma_window - Parse *dma-window property and returns 0 if found.
>*
> @@ -98,19 +95,6 @@ int of_get_dma_window(struct device_node *dn, const char
> *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> -static bool of_iommu_driver_present(struct device_node *np)
> -{
> - /*
> - * If the IOMMU still isn't ready by the time we reach init, assume
> - * it never will be. We don't want to defer indefinitely, nor attempt
> - * to dereference _
Re: [PATCH] mmc: sunxi: mark PM functions as __maybe_unused
On Fri, May 25, 2018 at 11:07:42PM +0200, Arnd Bergmann wrote:
> The newly added runtime-pm functions cause a harmless warning
> when CONFIG_PM is disabled:
>
> drivers/mmc/host/sunxi-mmc.c:1452:12: error: 'sunxi_mmc_runtime_suspend'
> defined but not used [-Werror=unused-function]
> static int sunxi_mmc_runtime_suspend(struct device *dev)
> ^
> drivers/mmc/host/sunxi-mmc.c:1435:12: error: 'sunxi_mmc_runtime_resume'
> defined but not used [-Werror=unused-function]
> static int sunxi_mmc_runtime_resume(struct device *dev)
>
> This marks them as __maybe_unused to shut up the warning.
>
> Fixes: 9a8e1e8cc2c0 ("mmc: sunxi: Add runtime_pm support")
> Signed-off-by: Arnd Bergmann
Acked-by: Maxime Ripard
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH] perf test 39 (Session topology) dumps core on s390
On 05/28/2018 05:49 AM, Ravi Bangoria wrote:
> Hi Thomas,
>
> On 05/24/2018 07:26 PM, Thomas Richter wrote:
>> @@ -95,7 +98,7 @@ int test__session_topology(struct test *test
>> __maybe_unused, int subtest __maybe
>> {
>> char path[PATH_MAX];
>> struct cpu_map *map;
>> -int ret = -1;
>> +int ret;
>
> This is failing for me:
>
> tests/topology.c: In function ‘test__session_topology’:
> tests/topology.c:101:6: error: ‘ret’ may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> int ret;
> ^
> cc1: all warnings being treated as errors
> CC util/intlist.o
> mv: cannot stat 'tests/.topology.o.tmp': No such file or directory
> /home/ravi/Workspace/linux/tools/build/Makefile.build:96: recipe for target
> 'tests/topology.o' failed
> make[4]: *** [tests/topology.o] Error 1
> make[4]: *** Waiting for unfinished jobs
>
>
> Thanks,
> Ravi
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Thanks for the pointer, will provide V2.
--
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB
243294
Re: [PATCH V3] scsi: ufs: Add specific callback for setting DMA mask
Hi Bart
On 05/20/2018 07:51 PM, Bart Van Assche wrote:
> On Sun, 2018-05-20 at 07:54 +0530, Alim Akhtar wrote:
>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>> index a355d98..9a1374e 100644
>> --- a/drivers/scsi/ufs/ufshcd.c
>> +++ b/drivers/scsi/ufs/ufshcd.c
>> @@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
>>*/
>> static int ufshcd_set_dma_mask(struct ufs_hba *hba)
>> {
>> +if (hba->vops && hba->vops->set_dma_mask)
>> +return hba->vops->set_dma_mask(hba);
>> +
>> if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
>> if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
>> return 0;
>> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
>> index 1332e54..89c6dae 100644
>> --- a/drivers/scsi/ufs/ufshcd.h
>> +++ b/drivers/scsi/ufs/ufshcd.h
>> @@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
>>* @resume: called during host controller PM callback
>>* @dbg_register_dump: used to dump controller debug information
>>* @phy_initialization: used to initialize phys
>> + * @set_dma_mask: used to set variant specific DMA mask
>>*/
>> struct ufs_hba_variant_ops {
>> const char *name;
>> @@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
>> int (*resume)(struct ufs_hba *, enum ufs_pm_op);
>> void(*dbg_register_dump)(struct ufs_hba *hba);
>> int (*phy_initialization)(struct ufs_hba *);
>> +int (*set_dma_mask)(struct ufs_hba *hba);
>> };
>
> I want to see the code that sets the .set_dma_mask callback function. Where
> is it? If it is outside the upstream kernel, please consider to send it
> upstream before making changes like this. Adding support for out-of-tree
> kernel code is frowned upon big time in the kernel community.
>
Thanks for review and feedback.
Ok, I will include this patch with the series which uses this particular
patch set.
Thanks!
> Bart.
>
>
>
Re: [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU
Hi, On Mon, May 28, 2018 at 10:26:54AM +0800, Shawn Guo wrote: > On Tue, Feb 27, 2018 at 11:17:12AM +0100, Sebastian Reichel wrote: > > Hi, > > > > On Tue, Feb 27, 2018 at 09:10:34AM +0800, Shawn Guo wrote: > > > On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote: > > > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote: > > > > > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote: > > > > > > On i.MX53 it is necessary to set the DBG_EN bit in the > > > > > > platform GPC register to enable access to PMU counters > > > > > > other than the cycle counter. > > > > > > > > > > > > Signed-off-by: Sebastian Reichel > > > > > > --- > > > > > > arch/arm/mach-imx/mach-imx53.c | 39 > > > > > > ++- > > > > > > 1 file changed, 38 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/arch/arm/mach-imx/mach-imx53.c > > > > > > b/arch/arm/mach-imx/mach-imx53.c > > > > > > index 07c2e8dca494..658e28604dca 100644 > > > > > > --- a/arch/arm/mach-imx/mach-imx53.c > > > > > > +++ b/arch/arm/mach-imx/mach-imx53.c > > > > > > @@ -28,10 +28,47 @@ static void __init imx53_init_early(void) > > > > > > mxc_set_cpu_type(MXC_CPU_MX53); > > > > > > } > > > > > > > > > > > > +#define MXC_CORTEXA8_PLAT_GPC 0x63fa0004 > > > > > > > > > > The base address should be retrieved from device tree. > > > > > > > > DT has no entry for 0x63fa-0x63fa3fff. iMX53 TRM lists it as "ARM > > > > Platform" > > > > with 8 platform specific 32 bit registers. Do you think it's worth the > > > > trouble > > > > adding a new binding? Do you have a suggestion for a compatible value? > > > > > > Looking at it more closely, I feel that patching every single platform > > > which needs to set up additional register for secure-reg-access support > > > doesn't really scale. Can we have pmu driver do it with a phandle in > > > DT pointing to the register and bit that need to be configured? > > > > The PMU driver used to have a feature for initialising platform > > specific bits, but it is currently being removed to make the PMU > > code more maintainable. My understanding is, that it's very uncommon > > to require platform specific setup to get secure-reg-access working. > > I.e. it is not needed for newer iMX platforms. > > Are you saying this is a very specific setup required by i.MX53 only? Yes, all other SoCs supported by Linux ARM PMU counters driver can just use the registers without having to enable platform specific bits first. > In that case, I can live with it. What about the DT node? I did not add it, since this is a i.MX53 specific workaround anyways. -- Sebastian signature.asc Description: PGP signature
[PATCH v4 3/9] drm/mediatek: add ddp component AAL1
This patch add component AAL1 and
rename AAL to AAL0
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 47ffa240bd25..7217665f4b5d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -110,7 +110,7 @@ static const unsigned int
mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
};
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
+ [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
[DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
[DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4672317e3ad1..0919039805aa 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -218,7 +218,8 @@ struct mtk_ddp_comp_match {
};
static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] =
{
- [DDP_COMPONENT_AAL] = { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_AAL0]= { MTK_DISP_AAL, 0, &ddp_aal },
+ [DDP_COMPONENT_AAL1]= { MTK_DISP_AAL, 1, &ddp_aal },
[DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
[DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
[DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 0828cf8bf85c..eee3c0cc2632 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -41,7 +41,8 @@ enum mtk_ddp_comp_type {
};
enum mtk_ddp_comp_id {
- DDP_COMPONENT_AAL,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_AAL1,
DDP_COMPONENT_BLS,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_COLOR1,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a2ca90fc403c..a415260f3d5f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -149,7 +149,7 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
- DDP_COMPONENT_AAL,
+ DDP_COMPONENT_AAL0,
DDP_COMPONENT_OD,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_UFOE,
--
2.12.5
[PATCH v4 1/9] drm/mediatek: update dt-bindings for mt2712
Update device tree binding documentation for the display subsystem for Mediatek MT2712 SoCs. Signed-off-by: Stu Hsieh Acked-by: CK Hu --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 383183a89164..8469de510001 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -40,7 +40,7 @@ Required properties (all function blocks): "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt "mediatek,-disp-mutex" - display mutex "mediatek,-disp-od"- overdrive - the supported chips are mt2701 and mt8173. + the supported chips are mt2701, mt2712 and mt8173. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for merge and split function blocks). -- 2.12.5
[PATCH v4 9/9] drm/mediatek: Add support for mediatek SOC MT2712
This patch add support for the Mediatek MT2712 DISP subsystem.
There are two OVL engine and three disp output in MT2712.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 39 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 +
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8bfc0debd2c2..3b22b48a6022 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -61,6 +61,24 @@
#define MT8173_MUTEX_MOD_DISP_PWM1 24
#define MT8173_MUTEX_MOD_DISP_OD 25
+#define MT2712_MUTEX_MOD_DISP_PWM2 10
+#define MT2712_MUTEX_MOD_DISP_OVL0 11
+#define MT2712_MUTEX_MOD_DISP_OVL1 12
+#define MT2712_MUTEX_MOD_DISP_RDMA013
+#define MT2712_MUTEX_MOD_DISP_RDMA114
+#define MT2712_MUTEX_MOD_DISP_RDMA215
+#define MT2712_MUTEX_MOD_DISP_WDMA016
+#define MT2712_MUTEX_MOD_DISP_WDMA117
+#define MT2712_MUTEX_MOD_DISP_COLOR0 18
+#define MT2712_MUTEX_MOD_DISP_COLOR1 19
+#define MT2712_MUTEX_MOD_DISP_AAL0 20
+#define MT2712_MUTEX_MOD_DISP_UFOE 22
+#define MT2712_MUTEX_MOD_DISP_PWM0 23
+#define MT2712_MUTEX_MOD_DISP_PWM1 24
+#define MT2712_MUTEX_MOD_DISP_OD0 25
+#define MT2712_MUTEX_MOD2_DISP_AAL133
+#define MT2712_MUTEX_MOD2_DISP_OD1 34
+
#define MT2701_MUTEX_MOD_DISP_OVL 3
#define MT2701_MUTEX_MOD_DISP_WDMA 6
#define MT2701_MUTEX_MOD_DISP_COLOR7
@@ -110,6 +128,26 @@ static const unsigned int
mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
};
+static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
+ [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
+ [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
+ [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
+ [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
+ [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
+ [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
+ [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
+ [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
+ [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
+ [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
+ [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
+};
+
static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
@@ -430,6 +468,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
static const struct of_device_id ddp_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
+ { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
{ .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
{},
};
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 3d279a299383..3a866e1d6af4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -146,6 +146,32 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
DDP_COMPONENT_DPI0,
};
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_DPI0,
+ DDP_COMPONENT_PWM0,
+};
+
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
+ DDP_COMPONENT_OVL1,
+ DDP_COMPONENT_COLOR1,
+ DDP_COMPONENT_AAL1,
+ DDP_COMPONENT_OD1,
+ DDP_COMPONENT_RDMA1,
+ DDP_COMPONENT_DPI1,
+ DDP_COMPONENT_PWM1,
+};
+
+static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
+ DDP_COMPONENT_RDMA2,
+ DDP_COMPONENT_DSI2,
+ DDP_COMPONENT_PWM2,
+};
+
static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
@@ -173,6 +199,15 @@ static const struct mtk_mmsys_driver_data
mt2701_mmsys_driver_data = {
.shadow_register = true,
};
+static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
+ .main_path = mt2712_mtk_ddp_main,
+ .main_len = ARRAY_SIZE(mt2712_mtk_ddp_main),
+
[PATCH v4 2/9] drm/mediatek: support maximum 64 mutex mod
This patch support that if modules more than 32,
add index more than 31 when using DISP_REG_MUTEX_MOD2 bit
Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 75 +-
1 file changed, 47 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..47ffa240bd25 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -41,31 +41,32 @@
#define DISP_REG_MUTEX_RST(n) (0x28 + 0x20 * (n))
#define DISP_REG_MUTEX_MOD(n) (0x2c + 0x20 * (n))
#define DISP_REG_MUTEX_SOF(n) (0x30 + 0x20 * (n))
+#define DISP_REG_MUTEX_MOD2(n) (0x34 + 0x20 * (n))
#define INT_MUTEX BIT(1)
-#define MT8173_MUTEX_MOD_DISP_OVL0 BIT(11)
-#define MT8173_MUTEX_MOD_DISP_OVL1 BIT(12)
-#define MT8173_MUTEX_MOD_DISP_RDMA0BIT(13)
-#define MT8173_MUTEX_MOD_DISP_RDMA1BIT(14)
-#define MT8173_MUTEX_MOD_DISP_RDMA2BIT(15)
-#define MT8173_MUTEX_MOD_DISP_WDMA0BIT(16)
-#define MT8173_MUTEX_MOD_DISP_WDMA1BIT(17)
-#define MT8173_MUTEX_MOD_DISP_COLOR0 BIT(18)
-#define MT8173_MUTEX_MOD_DISP_COLOR1 BIT(19)
-#define MT8173_MUTEX_MOD_DISP_AAL BIT(20)
-#define MT8173_MUTEX_MOD_DISP_GAMMABIT(21)
-#define MT8173_MUTEX_MOD_DISP_UFOE BIT(22)
-#define MT8173_MUTEX_MOD_DISP_PWM0 BIT(23)
-#define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
-#define MT8173_MUTEX_MOD_DISP_OD BIT(25)
-
-#define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
-#define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
-#define MT2701_MUTEX_MOD_DISP_COLORBIT(7)
-#define MT2701_MUTEX_MOD_DISP_BLS BIT(9)
-#define MT2701_MUTEX_MOD_DISP_RDMA0BIT(10)
-#define MT2701_MUTEX_MOD_DISP_RDMA1BIT(12)
+#define MT8173_MUTEX_MOD_DISP_OVL0 11
+#define MT8173_MUTEX_MOD_DISP_OVL1 12
+#define MT8173_MUTEX_MOD_DISP_RDMA013
+#define MT8173_MUTEX_MOD_DISP_RDMA114
+#define MT8173_MUTEX_MOD_DISP_RDMA215
+#define MT8173_MUTEX_MOD_DISP_WDMA016
+#define MT8173_MUTEX_MOD_DISP_WDMA117
+#define MT8173_MUTEX_MOD_DISP_COLOR0 18
+#define MT8173_MUTEX_MOD_DISP_COLOR1 19
+#define MT8173_MUTEX_MOD_DISP_AAL 20
+#define MT8173_MUTEX_MOD_DISP_GAMMA21
+#define MT8173_MUTEX_MOD_DISP_UFOE 22
+#define MT8173_MUTEX_MOD_DISP_PWM0 23
+#define MT8173_MUTEX_MOD_DISP_PWM1 24
+#define MT8173_MUTEX_MOD_DISP_OD 25
+
+#define MT2701_MUTEX_MOD_DISP_OVL 3
+#define MT2701_MUTEX_MOD_DISP_WDMA 6
+#define MT2701_MUTEX_MOD_DISP_COLOR7
+#define MT2701_MUTEX_MOD_DISP_BLS 9
+#define MT2701_MUTEX_MOD_DISP_RDMA010
+#define MT2701_MUTEX_MOD_DISP_RDMA112
#define MUTEX_SOF_SINGLE_MODE 0
#define MUTEX_SOF_DSI0 1
@@ -278,6 +279,7 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -292,9 +294,17 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
reg = MUTEX_SOF_DPI0;
break;
default:
- reg = readl_relaxed(ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
- reg |= ddp->mutex_mod[id];
- writel_relaxed(reg, ddp->regs + DISP_REG_MUTEX_MOD(mutex->id));
+ if (ddp->mutex_mod[id] < 32) {
+ offset = DISP_REG_MUTEX_MOD(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << ddp->mutex_mod[id];
+ writel_relaxed(reg, ddp->regs + offset);
+ } else {
+ offset = DISP_REG_MUTEX_MOD2(mutex->id);
+ reg = readl_relaxed(ddp->regs + offset);
+ reg |= 1 << (ddp->mutex_mod[id] - 32);
+ writel_relaxed(reg, ddp->regs + offset);
+ }
return;
}
@@ -307,6 +317,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
*mutex,
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
mutex[mutex->id]);
unsigned int reg;
+ unsigned int offset;
WARN_ON(&ddp->mutex[mutex->id] != mutex);
@@ -318,9 +329,17 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex
*mutex,
ddp->regs + DISP_REG_MUTEX_SOF(mutex->id));
break;
default:
- reg = readl_relaxed(ddp
[PATCH v4 5/9] drm/mediatek: add ddp component PWM1
This patch add component PWM1 in mtk_ddp_matches
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 87acf6be87f6..a5c7ac2d162d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -232,6 +232,7 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
+ [DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
--
2.12.5
[PATCH v4 7/9] drm/mediatek: add connection from OD1 to RDMA1
This patch add the connection from OD1 to RDMA1 for ext path.
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 58e44349e315..8bfc0debd2c2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -75,6 +75,7 @@
#define OVL0_MOUT_EN_COLOR00x1
#define OD_MOUT_EN_RDMA0 0x1
+#define OD1_MOUT_EN_RDMA1 BIT(16)
#define UFOE_MOUT_EN_DSI0 0x1
#define COLOR0_SEL_IN_OVL0 0x1
#define OVL1_MOUT_EN_COLOR10x1
@@ -151,6 +152,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
} else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
value = GAMMA_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
+ *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
+ value = OD1_MOUT_EN_RDMA1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
*addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
value = RDMA1_MOUT_DPI0;
--
2.12.5
[PATCH v4 6/9] drm/mediatek: add ddp component PWM2
This patch add component PWM2
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index a5c7ac2d162d..86e8c9e5df41 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -233,6 +233,7 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
[DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
+ [DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 9b19fc4423f1..e00c2e798abd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -56,6 +56,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
+ DDP_COMPONENT_PWM2,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_RDMA2,
--
2.12.5
[PATCH v4 8/9] drm/mediatek: add third ddp path
This patch create third crtc by third ddp path
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +--
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 658b8dd45b83..2d6aa150a9ff 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -539,6 +539,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
int ret;
int i;
+ if (!path)
+ return 0;
+
for (i = 0; i < path_len; i++) {
enum mtk_ddp_comp_id comp_id = path[i];
struct device_node *node;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 08d5d0b47bfe..3d279a299383 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -232,6 +232,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
if (ret < 0)
goto err_component_unbind;
+ ret = mtk_drm_crtc_create(drm, private->data->third_path,
+ private->data->third_len);
+ if (ret < 0)
+ goto err_component_unbind;
+
/* Use OVL device for all DMA memory allocations */
np = private->comp_node[private->data->main_path[0]] ?:
private->comp_node[private->data->ext_path[0]];
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index c3378c452c0a..d867e2683923 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -17,8 +17,8 @@
#include
#include "mtk_drm_ddp_comp.h"
-#define MAX_CRTC 2
-#define MAX_CONNECTOR 2
+#define MAX_CRTC 3
+#define MAX_CONNECTOR 3
struct device;
struct device_node;
@@ -33,6 +33,9 @@ struct mtk_mmsys_driver_data {
unsigned int main_len;
const enum mtk_ddp_comp_id *ext_path;
unsigned int ext_len;
+ const enum mtk_ddp_comp_id *third_path;
+ unsigned int third_len;
+
bool shadow_register;
};
--
2.12.5
[PATCH v4 4/9] drm/mediatek: add ddp component OD1
This patch add the component OD1 and
rename the OD to OD1
Signed-off-by: Stu Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 7217665f4b5d..58e44349e315 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -114,7 +114,7 @@ static const unsigned int
mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
[DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
[DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
- [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
+ [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
[DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
[DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
[DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
@@ -139,7 +139,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
value = OVL_MOUT_EN_RDMA;
- } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
+ } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
} else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 0919039805aa..87acf6be87f6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -227,7 +227,8 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
[DDP_COMPONENT_DSI1]= { MTK_DSI,1, NULL },
[DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
- [DDP_COMPONENT_OD] = { MTK_DISP_OD,0, &ddp_od },
+ [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, &ddp_od },
+ [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, &ddp_od },
[DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index eee3c0cc2632..9b19fc4423f1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -50,7 +50,8 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_DSI0,
DDP_COMPONENT_DSI1,
DDP_COMPONENT_GAMMA,
- DDP_COMPONENT_OD,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_OD1,
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a415260f3d5f..08d5d0b47bfe 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -150,7 +150,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_AAL0,
- DDP_COMPONENT_OD,
+ DDP_COMPONENT_OD0,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_UFOE,
DDP_COMPONENT_DSI0,
--
2.12.5
Re: [alsa-devel] [PATCH v2 1/3] ASoC: topology: Improve backwards compatibility with v4 topology files
On 05/27/2018 11:03 PM, Vinod wrote: [ ... ] diff --git a/sound/soc/intel/skylake/skl-tplg-interface.h b/sound/soc/intel/skylake/skl-tplg-interface.h index f8d1749a2e0c..b0e3d376594c 100644 --- a/sound/soc/intel/skylake/skl-tplg-interface.h +++ b/sound/soc/intel/skylake/skl-tplg-interface.h Don't we want to move these to upai/ as that is right place and use that in alsa-lib. I did that in patch 3 of the series [1]. Guenter --- [1] https://patchwork.kernel.org/patch/10425387/
[PATCH v4 0/9] Add support for mediatek SOC MT2712
This patch add support for the Mediatek MT2712 DISP subsystem. MT2712 is base on MT8173, there are some difference as following: MT2712 support three disp output(two ovl and one rdma) Change in v4: - Move some modification about AAL1 from patch "Add support for mediatek SOC MT2712" to "add ddp component AAL1" - Move some modification about OD1 from patch "Add support for mediatek SOC MT2712" to "add ddp component OD1" - Move some modification about PWM2 from patch "Add support for mediatek SOC MT2712" to "add ddp component PWM2" - Move some modification about third ddp path from patch "Add support for mediatek SOC MT2712" to "add third ddp path" - Move the definition OD1_MOUT_EN_RDMA1 from patch "Add support for mediatek SOC MT2712" to "add connection from OD1 to RDMA1" - Rebase the patch "add connection from OD1 to RDMA1" after "add ddp component OD1" - Rebase the patch "add third ddp path" before "Add support for mediatek SOC MT2712" - Modify the 2712 MUTEX MODULE in the order by index - Added patch for ddp component PWM1 - For patch "add third ddp path" Add the condition in mtk_crtc_create() that if there is no ddp path, then return 0 to avoid the null crtc Change in v3: - Added patch for ddp component AAL1 - Added patch for ddp component OD1 - Added patch for ddp component PWM2 - Added patch to create third ddp path - Rebase patch "support maximum 64 mutex mod" before "Add support for mediatek SOC MT2712" - Rebase patch "add connection from OD1 to RDMA1" before "Add support for mediatek SOC MT2712" - Remove two definition about RDMA0 and RDMA2 - Change the definition about mutex module from bitwise to index Changes in v2: - update dt-bindings for mt2712 - Added patch to connection from OD1 to RDMA1 - Added patch to support maximum 64 mutex mod - rewrite mutex mod condition for reducing one byte - Change the component name AAL/OD to AAL0/OD0 for naming consistency - Move the compatible information about dpi to other patch which modify the dpi driver for mt2712 Stu Hsieh (9): drm/mediatek: update dt-bindings for mt2712 drm/mediatek: support maximum 64 mutex mod drm/mediatek: add ddp component AAL1 drm/mediatek: add ddp component OD1 drm/mediatek: add ddp component PWM1 drm/mediatek: add ddp component PWM2 drm/mediatek: add connection from OD1 to RDMA1 drm/mediatek: add third ddp path drm/mediatek: Add support for mediatek SOC MT2712 .../bindings/display/mediatek/mediatek,disp.txt| 2 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 3 + drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 124 +++-- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 8 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 7 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 +++- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +- 7 files changed, 158 insertions(+), 40 deletions(-) -- 2.12.5
Re: [PATCH 02/11] PM / devfreq: Fix handling of min/max_freq == 0
Hi,
On 2018년 05월 26일 05:30, Matthias Kaehlcke wrote:
> Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the
> devfreq device") initializes df->min/max_freq with the min/max OPP when
> the device is added. Later commit f1d981eaecf8 ("PM / devfreq: Use the
> available min/max frequency") adds df->scaling_min/max_freq and the
> following to the frequency adjustment code:
>
> max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq);
>
> With the current handling of min/max_freq this is incorrect:
>
> Even though df->max_freq is now initialized to a value != 0 user space
> can still set it to 0, in this case max_freq would be 0 instead of
> df->scaling_max_freq as intended. In consequence the frequency adjustment
> is not performed:
>
> if (max_freq && freq > max_freq) {
> freq = max_freq;
>
> To fix this set df->min/max freq to the min/max OPP in max/max_freq_store,
> when the user passes a value of 0. This also prevents df->max_freq from
> being set below the min OPP when df->min_freq is 0, and similar for
> min_freq. Since it is now guaranteed that df->min/max_freq can't be 0 the
> checks for this case can be removed.
>
> Fixes: f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency")
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/devfreq/devfreq.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 0057ef5b0a98..67da4e7b486b 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -283,11 +283,11 @@ int update_devfreq(struct devfreq *devfreq)
> max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq);
> min_freq = MAX(devfreq->scaling_min_freq, devfreq->min_freq);
>
> - if (min_freq && freq < min_freq) {
> + if (freq < min_freq) {
> freq = min_freq;
> flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */
> }
> - if (max_freq && freq > max_freq) {
> + if (freq > max_freq) {
> freq = max_freq;
> flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
> }
> @@ -1123,17 +1123,20 @@ static ssize_t min_freq_store(struct device *dev,
> struct device_attribute *attr,
> struct devfreq *df = to_devfreq(dev);
> unsigned long value;
> int ret;
> - unsigned long max;
>
> ret = sscanf(buf, "%lu", &value);
> if (ret != 1)
> return -EINVAL;
>
> mutex_lock(&df->lock);
> - max = df->max_freq;
> - if (value && max && value > max) {
> - ret = -EINVAL;
> - goto unlock;
> +
> + if (value) {
> + if (value > df->max_freq) {
> + ret = -EINVAL;
> + goto unlock;
> + }
> + } else {
> + value = df->profile->freq_table[df->profile->max_state - 1];
> }
If you want to prevent that df->min_freq is zero,
you should reinitialize 'value' as following.
Because freq_table must be in ascending order.
value = df->profile->freq_table[0];
>
> df->min_freq = value;
> @@ -1158,17 +1161,20 @@ static ssize_t max_freq_store(struct device *dev,
> struct device_attribute *attr,
> struct devfreq *df = to_devfreq(dev);
> unsigned long value;
> int ret;
> - unsigned long min;
>
> ret = sscanf(buf, "%lu", &value);
> if (ret != 1)
> return -EINVAL;
>
> mutex_lock(&df->lock);
> - min = df->min_freq;
> - if (value && min && value < min) {
> - ret = -EINVAL;
> - goto unlock;
> +
> + if (!value) {
> + value = df->profile->freq_table[0];
ditto.
value = df->profile->freq_table[df->profile->max_state - 1];
> + } else {
> + if (value < df->min_freq) {
> + ret = -EINVAL;
> + goto unlock;
> + }
> }
>
> df->max_freq = value;
>
Actually, min_freq_store() and max_freq_store() are very similar.
But, this patch changed the order of conditional statement as following:
If there is no special reason, you better to keep the same format
for the readability.
min_freq_store()
if (value) {
...
} else {
value = df->profile->freq_table[df->profile->max_state - 1];
}
max_freq_store()
if (!value) {
value = df->profile->freq_table[0];
} else {
...
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCHv2 1/2] usb: hub: Per-port setting to use old enumeration scheme
The "old" enumeration scheme is considerably faster (it takes
~244ms instead of ~356ms to get the descriptor).
It is currently only possible to use the old scheme globally
(/sys/module/usbcore/parameters/old_scheme_first), which is not
desirable as the new scheme was introduced to increase compatibility
with more devices.
However, in our case, we care about time-to-active for a specific
USB device (which we make the firmware for), on a specific port
(that is pogo-pin based: not a standard USB port). This new
sysfs option makes it possible to use the old scheme on a single
port only.
Signed-off-by: Nicolas Boichat
---
Changes since v1:
- Added documentation in Documentation/ABI
- Updated timing in commit message to account for recent improvement
in USB core (74072bae88fb3b)
Documentation/ABI/testing/sysfs-bus-usb | 18 ++
drivers/usb/core/hub.c | 13 +
drivers/usb/core/hub.h | 1 +
drivers/usb/core/port.c | 23 +++
include/linux/usb.h | 7 +++
5 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-usb
b/Documentation/ABI/testing/sysfs-bus-usb
index c6e9b30f05b13..a31a66d62cbba 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -189,6 +189,24 @@ Description:
The file will read "hotplug", "wired" and "not used" if the
information is available, and "unknown" otherwise.
+What: /sys/bus/usb/devices/.../(hub interface)/portX/quirks
+Date: May 2018
+Contact: Nicolas Boichat
+Description:
+ In some cases, we care about time-to-active for devices
+ connected on a specific port (e.g. non-standard USB port like
+ pogo pins), where the device to be connected is known in
+ advance, and behaves well according to the specification.
+ This attribute is a bit-field that controls the behavior of
+ a specific port:
+- Bit 0 of this field selects the "old" enumeration scheme,
+ as it is considerably faster (it only causes one USB reset
+ instead of 2).
+ The old enumeration scheme can also be selected globally
+ using /sys/module/usbcore/parameters/old_scheme_first, but
+ it is often not desirable as the new scheme was introduced to
+ increase compatibility with more devices.
+
What: /sys/bus/usb/devices/.../(hub
interface)/portX/over_current_count
Date: February 2018
Contact: Richard Leitner
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index c2d993d3816f0..f900f66a62856 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2636,7 +2636,7 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
#define SET_ADDRESS_TRIES 2
#define GET_DESCRIPTOR_TRIES 2
#define SET_CONFIG_TRIES (2 * (use_both_schemes + 1))
-#define USE_NEW_SCHEME(i) ((i) / 2 == (int)old_scheme_first)
+#define USE_NEW_SCHEME(i, scheme) ((i) / 2 == (int)scheme)
#define HUB_ROOT_RESET_TIME60 /* times are in msec */
#define HUB_SHORT_RESET_TIME 10
@@ -2651,12 +2651,16 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
* enumeration failures, so disable this enumeration scheme for USB3
* devices.
*/
-static bool use_new_scheme(struct usb_device *udev, int retry)
+static bool use_new_scheme(struct usb_device *udev, int retry,
+ struct usb_port *port_dev)
{
+ int old_scheme_first_port =
+ port_dev->quirks & USB_PORT_QUIRK_OLD_SCHEME;
+
if (udev->speed >= USB_SPEED_SUPER)
return false;
- return USE_NEW_SCHEME(retry);
+ return USE_NEW_SCHEME(retry, old_scheme_first_port || old_scheme_first);
}
/* Is a USB 3.0 port in the Inactive or Compliance Mode state?
@@ -4392,6 +4396,7 @@ hub_port_init(struct usb_hub *hub, struct usb_device
*udev, int port1,
{
struct usb_device *hdev = hub->hdev;
struct usb_hcd *hcd = bus_to_hcd(hdev->bus);
+ struct usb_port *port_dev = hub->ports[port1 - 1];
int retries, operations, retval, i;
unsigneddelay = HUB_SHORT_RESET_TIME;
enum usb_device_speed oldspeed = udev->speed;
@@ -4513,7 +4518,7 @@ hub_port_init(struct usb_hub *hub, struct usb_device
*udev, int port1,
for (retries = 0; retries < GET_DESCRIPTOR_TRIES; (++retries,
msleep(100))) {
bool did_new_scheme = false;
- if (use_new_scheme(udev, retry_counter)) {
+ if (use_new_scheme(udev, retry_counter, port_dev)) {
struct usb_device_descriptor *buf;
int r = 0;
diff --git a/drivers/usb/core/hub.h b/drivers/usb/
[PATCH] usb: hub: Per-port setting to reduce TRSTRCY to 10 ms
Currently, the USB hub core waits for 50 ms after enumerating the
device. This was added to help "some high speed devices" to
enumerate (b789696af8 "[PATCH] USB: relax usbcore reset timings").
On some devices, the time-to-active is important, so we provide
a per-port option to reduce the time to what the USB specification
requires: 10 ms.
Signed-off-by: Nicolas Boichat
---
Reduces enumeration time by ~40ms in conjunction with previous
patch/quirk (or ~80ms on its own).
Documentation/ABI/testing/sysfs-bus-usb | 4
drivers/usb/core/hub.c | 6 +-
include/linux/usb.h | 3 +++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-usb
b/Documentation/ABI/testing/sysfs-bus-usb
index a31a66d62cbba..08d456e07b538 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -206,6 +206,10 @@ Description:
using /sys/module/usbcore/parameters/old_scheme_first, but
it is often not desirable as the new scheme was introduced to
increase compatibility with more devices.
+- Bit 1 reduces TRSTRCY to the 10 ms that are required by the
+ USB 2.0 specification, instead of the 50 ms that are normally
+ used to help make enumeration work better on some high speed
+ devices.
What: /sys/bus/usb/devices/.../(hub
interface)/portX/over_current_count
Date: February 2018
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f900f66a62856..26c2438d28893 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2879,7 +2879,11 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
done:
if (status == 0) {
/* TRSTRCY = 10 ms; plus some extra */
- msleep(10 + 40);
+ if (port_dev->quirks & USB_PORT_QUIRK_FAST_ENUM)
+ usleep_range(1, 12000);
+ else
+ msleep(10 + 40);
+
if (udev) {
struct usb_hcd *hcd = bus_to_hcd(udev->bus);
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 2ade17992ed66..4cdd515a4385f 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -496,6 +496,9 @@ enum usb_port_connect_type {
/* For the given port, prefer the old (faster) enumeration scheme. */
#define USB_PORT_QUIRK_OLD_SCHEME BIT(0)
+/* Decrease TRSTRCY to 10ms during device enumeration. */
+#define USB_PORT_QUIRK_FAST_ENUM BIT(1)
+
/*
* USB 2.0 Link Power Management (LPM) parameters.
*/
--
2.17.0.921.gf22659ad46-goog
Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
On Mon, 28 May 2018, Christoph Hellwig wrote: > On Mon, May 28, 2018 at 08:18:46AM +0200, Thomas Gleixner wrote: > > > Which other two? The boot optional removal patches? They just remove > > > the visible interface, but keep the implementation which is converted > > > to the better mechanism here, so I think the order makes sense. > > > But I might be missing something.. > > > > They remove the commandline switch before having the replacement in place > > unless I'm misreading something. > > The command line switch to force 32-bit dma is removed without > replacement. The PCI quirk for force the 32-bit dma for VIA bridges > is kept in place, and switch to a different mechanism in this patch. Fair enough
Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
On Mon, May 28, 2018 at 08:18:46AM +0200, Thomas Gleixner wrote: > > Which other two? The boot optional removal patches? They just remove > > the visible interface, but keep the implementation which is converted > > to the better mechanism here, so I think the order makes sense. > > But I might be missing something.. > > They remove the commandline switch before having the replacement in place > unless I'm misreading something. The command line switch to force 32-bit dma is removed without replacement. The PCI quirk for force the 32-bit dma for VIA bridges is kept in place, and switch to a different mechanism in this patch.
Re: mmc filesystem performance decreased on the first write after filesystem creation
Summary: mke2s uses the BLKDISCARD ioctl to wipe the device, and then uses BLKDISCARDZEROES to check if that zeroed the data. A while ago I made BLKDISCARDZEROES always return 0 because it is basically impossible to have reliably zeroing using discard as the standards leave the devices way to many options to not actually zero data at their own choice when using the discard commands. So IFF mke2fs want to actually free space and zero it it needs to use fallocate to punch a hole, and mmc needs to implement REQ_OP_WRITE_ZEROS IFF it actually has a reliable way to zero blocks. On Tue, May 22, 2018 at 08:48:31PM +0530, Faiz Abbas wrote: > Hi, > > I am debugging a performance reduction in ext2 filesystems on an mmc > device in TI's am335x evm board. > > I see that the performance is reduced on the first write after making a > new filesystem using mkfs.ext2 on one of the mmc partitions. The > performance comes back to normal after the first write. > > commands used: > > => umount /dev/mmcblk1p2 > > => mkfs.ext2 -F /dev/mmcblk1p2 > > => mount -t ext2 -o async /dev/mmcblk1p2 /mnt/partition_mmc > > => dd if=/dev/urandom of=/dev/shm/srctest_file_mmc_1184 bs=1M count=10 > > => ./filesystem_tests -write -src_file /dev/shm/srctest_file_mmc_1184 > -srcfile_size 10 -file /mnt/partition_mmc/test_file_1184 -buffer_size > 102400 -file_size 100 -performance > > The filesystem_tests write utility reads from the file generated at > /dev/shm/srctest_file_mmc_1184, memory maps the file to a buffer, and > then writes it into the newly created /mnt/partition_mmc in multiples of > buffer_size while measuring write performance. > > See here for the implementation of filesystem_tests write utility: > http://arago-project.org/git/projects/?p=test-automation/ltp-ddt.git;a=blob;f=testcases/ddt/filesystem_test_suite/src/testcases/st_filesystem_write_to_file.c;h=80e8e244d7eaa9f0dbd9b21ea705445156c36bef;hb=f7fc06c290333ce08a7d4fba104eee0f0f1d942b > > Complete log with multiple calls to filesystem_tests: > https://pastebin.ubuntu.com/p/BckmTJpqPv/ > > Notice that the first run of filesystem_tests has a lower throughput > reported. > > I was able to bisect the issue to this commit: > 5d1429fead5b (mmc: remove the discard_zeroes_data flag) > > I would assume that after this flag is removed, the filesystem creation > command would explicitly write zeroes to the device which might explain > the performance fall. However, then the mkfs.ext2 command itself should > take more time rather than the first file write after that. > > It would be nice if someone could help me understand why this is happening. > > Thanks for your help. > > Regards, > Faiz ---end quoted text---
Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
On Mon, 28 May 2018, Christoph Hellwig wrote: > On Mon, May 28, 2018 at 08:10:40AM +0200, Thomas Gleixner wrote: > > n Fri, 25 May 2018, Christoph Hellwig wrote: > > > > x86/pci-dma: ... > > > > Please > > > > > Instead of globally disabling > 32bit DMA using the arch_dma_supported > > > hook walk the PCI bus under the actually affected bridge and mark every > > > device with the dma_32bit_limit flag. This also gets rid of the > > > arch_dma_supported hook entirely. > > > > Shouldn't this go before the other two? > > Which other two? The boot optional removal patches? They just remove > the visible interface, but keep the implementation which is converted > to the better mechanism here, so I think the order makes sense. > But I might be missing something.. They remove the commandline switch before having the replacement in place unless I'm misreading something. Thanks, tglx
Re: [PATCH v3] selftests: cgroup/memcontrol: add basic test for socket accounting
Hi,
Are there any updates on this?
On Tue, May 22, 2018 at 11:06:05PM +0300, Mike Rapoport wrote:
> The test verifies that when there is active TCP connection, the
> memory.stat.sock and memory.current values are close.
>
> Signed-off-by: Mike Rapoport
> Acked-by: Roman Gushchin
> ---
> v3 changes:
> * added changelog
>
> v2 changes:
> * bumped error percentage for comparing memory.current with memory.stat.sock
> * added checks that memory.stat.sock == 0 and memory.current >= 0 after TCP
> server exits
> * simplified error handling
>
> tools/testing/selftests/cgroup/test_memcontrol.c | 193
> +++
> 1 file changed, 193 insertions(+)
>
> diff --git a/tools/testing/selftests/cgroup/test_memcontrol.c
> b/tools/testing/selftests/cgroup/test_memcontrol.c
> index beae06c9c899..cf0bddc9d271 100644
> --- a/tools/testing/selftests/cgroup/test_memcontrol.c
> +++ b/tools/testing/selftests/cgroup/test_memcontrol.c
> @@ -9,6 +9,12 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
>
> #include "../kselftest.h"
> #include "cgroup_util.h"
> @@ -772,6 +778,192 @@ static int test_memcg_oom_events(const char *root)
> return ret;
> }
>
> +struct tcp_server_args {
> + unsigned short port;
> + int ctl[2];
> +};
> +
> +static int tcp_server(const char *cgroup, void *arg)
> +{
> + struct tcp_server_args *srv_args = arg;
> + struct sockaddr_in6 saddr = { 0 };
> + socklen_t slen = sizeof(saddr);
> + int sk, client_sk, ctl_fd, yes = 1, ret = -1;
> +
> + close(srv_args->ctl[0]);
> + ctl_fd = srv_args->ctl[1];
> +
> + saddr.sin6_family = AF_INET6;
> + saddr.sin6_addr = in6addr_any;
> + saddr.sin6_port = htons(srv_args->port);
> +
> + sk = socket(AF_INET6, SOCK_STREAM, 0);
> + if (sk < 0)
> + return ret;
> +
> + if (setsockopt(sk, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes)) < 0)
> + goto cleanup;
> +
> + if (bind(sk, (struct sockaddr *)&saddr, slen)) {
> + write(ctl_fd, &errno, sizeof(errno));
> + goto cleanup;
> + }
> +
> + if (listen(sk, 1))
> + goto cleanup;
> +
> + ret = 0;
> + if (write(ctl_fd, &ret, sizeof(ret)) != sizeof(ret)) {
> + ret = -1;
> + goto cleanup;
> + }
> +
> + client_sk = accept(sk, NULL, NULL);
> + if (client_sk < 0)
> + goto cleanup;
> +
> + ret = -1;
> + for (;;) {
> + uint8_t buf[0x10];
> +
> + if (write(client_sk, buf, sizeof(buf)) <= 0) {
> + if (errno == ECONNRESET)
> + ret = 0;
> + break;
> + }
> + }
> +
> + close(client_sk);
> +
> +cleanup:
> + close(sk);
> + return ret;
> +}
> +
> +static int tcp_client(const char *cgroup, unsigned short port)
> +{
> + const char server[] = "localhost";
> + struct addrinfo *ai;
> + char servport[6];
> + int retries = 0x10; /* nice round number */
> + int sk, ret;
> +
> + snprintf(servport, sizeof(servport), "%hd", port);
> + ret = getaddrinfo(server, servport, NULL, &ai);
> + if (ret)
> + return ret;
> +
> + sk = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
> + if (sk < 0)
> + goto free_ainfo;
> +
> + ret = connect(sk, ai->ai_addr, ai->ai_addrlen);
> + if (ret < 0)
> + goto close_sk;
> +
> + ret = KSFT_FAIL;
> + while (retries--) {
> + uint8_t buf[0x10];
> + long current, sock;
> +
> + if (read(sk, buf, sizeof(buf)) <= 0)
> + goto close_sk;
> +
> + current = cg_read_long(cgroup, "memory.current");
> + sock = cg_read_key_long(cgroup, "memory.stat", "sock ");
> +
> + if (current < 0 || sock < 0)
> + goto close_sk;
> +
> + if (current < sock)
> + goto close_sk;
> +
> + if (values_close(current, sock, 10)) {
> + ret = KSFT_PASS;
> + break;
> + }
> + }
> +
> +close_sk:
> + close(sk);
> +free_ainfo:
> + freeaddrinfo(ai);
> + return ret;
> +}
> +
> +/*
> + * This test checks socket memory accounting.
> + * The test forks a TCP server listens on a random port between 1000
> + * and 61000. Once it gets a client connection, it starts writing to
> + * its socket.
> + * The TCP client interleaves reads from the socket with check whether
> + * memory.current and memory.stat.sock are similar.
> + */
> +static int test_memcg_sock(const char *root)
> +{
> + int bind_retries = 5, ret = KSFT_FAIL, pid, err;
> + unsigned short port;
> + char *memcg;
> +
> + memcg = cg_name(root, "memcg_test");
> + if (!memcg)
> + goto cleanup;
> +
> + if (cg_create(memcg))
> + goto cleanup;
> +
> + while (bind_
[PATCH] staging:r8188eu: Use lib80211 to encrypt (WEP) tx frames
Put data to skb, decrypt with lib80211_crypt_wep, and place back to tx buffer.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/core/rtw_security.c | 72 ---
1 file changed, 43 insertions(+), 29 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index bfe0b217e679..80d7569a3108 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -139,17 +139,11 @@ static __le32 getcrc32(u8 *buf, int len)
Need to consider the fragment situation
*/
void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
-{ /* exclude ICV */
-
- unsigned char crc[4];
- struct arc4context mycontext;
-
+{
int curfragnum, length;
- u32 keylength;
- u8 *pframe, *payload, *iv;/* wepkey */
- u8 wepkey[16];
- u8 hw_hdr_offset = 0;
+ u8 *pframe;
+ u8 hw_hdr_offset = 0;
struct pkt_attrib *pattrib = &((struct xmit_frame
*)pxmitframe)->attrib;
struct security_priv *psecuritypriv = &padapter->securitypriv;
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
@@ -165,33 +159,53 @@ void rtw_wep_encrypt(struct adapter *padapter, u8
*pxmitframe)
/* start to encrypt each fragment */
if ((pattrib->encrypt == _WEP40_) || (pattrib->encrypt == _WEP104_)) {
- keylength =
psecuritypriv->dot11DefKeylen[psecuritypriv->dot11PrivacyKeyIndex];
+ const int keyindex = psecuritypriv->dot11PrivacyKeyIndex;
+ void *crypto_private;
+ struct sk_buff *skb;
+ struct lib80211_crypto_ops *crypto_ops =
try_then_request_module(lib80211_get_crypto_ops("WEP"), "lib80211_crypt_wep");
+
+ if (!crypto_ops)
+ goto exit;
+
+ crypto_private = crypto_ops->init(keyindex);
+ if (!crypto_private)
+ goto exit;
+
+ if
(crypto_ops->set_key(psecuritypriv->dot11DefKey[keyindex].skey,
+
psecuritypriv->dot11DefKeylen[keyindex], NULL, crypto_private) < 0)
+ goto exit;
for (curfragnum = 0; curfragnum < pattrib->nr_frags;
curfragnum++) {
- iv = pframe+pattrib->hdrlen;
- memcpy(&wepkey[0], iv, 3);
- memcpy(&wepkey[3],
&psecuritypriv->dot11DefKey[psecuritypriv->dot11PrivacyKeyIndex].skey[0],
keylength);
- payload = pframe+pattrib->iv_len+pattrib->hdrlen;
+ if (curfragnum + 1 == pattrib->nr_frags)
+ length = pattrib->last_txcmdsz;
+ else
+ length = pxmitpriv->frag_len;
+ skb = dev_alloc_skb(length);
+ if (!skb)
+ goto exit;
- if ((curfragnum+1) == pattrib->nr_frags) { /* the
last fragment */
- length =
pattrib->last_txcmdsz-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
+ skb_put_data(skb, pframe, length);
- *((__le32 *)crc) = getcrc32(payload, length);
+ memmove(skb->data + 4, skb->data, pattrib->hdrlen);
+ skb_pull(skb, 4);
+ skb_trim(skb, skb->len - 4);
- arcfour_init(&mycontext, wepkey, 3+keylength);
- arcfour_encrypt(&mycontext, payload, payload,
length);
- arcfour_encrypt(&mycontext, payload+length,
crc, 4);
- } else {
- length =
pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
- *((__le32 *)crc) = getcrc32(payload, length);
- arcfour_init(&mycontext, wepkey, 3+keylength);
- arcfour_encrypt(&mycontext, payload, payload,
length);
- arcfour_encrypt(&mycontext, payload+length,
crc, 4);
-
- pframe += pxmitpriv->frag_len;
- pframe = (u8 *)round_up((size_t)(pframe), 4);
+ if (crypto_ops->encrypt_mpdu(skb, pattrib->hdrlen,
crypto_private)) {
+ kfree_skb(skb);
+ goto exit;
}
+
+ memcpy(pframe, skb->data, skb->len);
+
+ pframe += skb->len;
+ pframe = (u8 *)round_up((size_t)(pframe), 4);
+
+ kfree_skb(skb);
}
+
+exit:
+ if (crypto_ops && crypto_private)
+ crypto_ops->deinit(crypto_private);
Re: [PATCH v3 13/16] mtd: rawnand: qcom: minor code reorganization for bad block check
On 2018-05-26 14:28, Miquel Raynal wrote: Hi Abhishek, @@ -2141,12 +2127,10 @@ static int qcom_nandc_block_bad(struct mtd_info *mtd, loff_t ofs) goto err; } - bbpos = mtd->writesize - host->cw_size * (ecc->steps - 1); - - bad = nandc->data_buffer[bbpos] != 0xff; + bad = bbm_bytes_buf[0] != 0xff; BTW, as there are host->bbm_size bytes that can inform on the block state, don't we need to check all of them? We are checking all of them. host->bbm_size will be either 1 (for NAND_BUSWIDTH_8) or 2 (for NAND_BUSWIDTH_16). https://elixir.bootlin.com/linux/v4.17-rc7/source/drivers/mtd/nand/raw/qcom_nandc.c#L2347 Thanks, Abhishek if (chip->options & NAND_BUSWIDTH_16) - bad = bad || (nandc->data_buffer[bbpos + 1] != 0xff); + bad = bad || (bbm_bytes_buf[1] != 0xff); err: return bad; } Thanks, Miquèl
[PATCH V2] irqchip: gpcv2: remove unnecessary functions
GPC is in always-on domain, it never lost its
content during suspend/resume, so no need to
do save/restore for it during suspend/resume.
Signed-off-by: Anson Huang
---
changes since V1:
Add missing wakeup source write into GPC IMR register;
remove all necessary arrays;
suspend/resume tested passed with u-boot I develop for suspend/resume
support.
drivers/irqchip/irq-imx-gpcv2.c | 50 +++--
1 file changed, 3 insertions(+), 47 deletions(-)
diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c
index 4760307..6bb6ba0 100644
--- a/drivers/irqchip/irq-imx-gpcv2.c
+++ b/drivers/irqchip/irq-imx-gpcv2.c
@@ -21,53 +21,11 @@
struct gpcv2_irqchip_data {
struct raw_spinlock rlock;
void __iomem*gpc_base;
- u32 wakeup_sources[IMR_NUM];
- u32 saved_irq_mask[IMR_NUM];
u32 cpu2wakeup;
};
static struct gpcv2_irqchip_data *imx_gpcv2_instance;
-static int gpcv2_wakeup_source_save(void)
-{
- struct gpcv2_irqchip_data *cd;
- void __iomem *reg;
- int i;
-
- cd = imx_gpcv2_instance;
- if (!cd)
- return 0;
-
- for (i = 0; i < IMR_NUM; i++) {
- reg = cd->gpc_base + cd->cpu2wakeup + i * 4;
- cd->saved_irq_mask[i] = readl_relaxed(reg);
- writel_relaxed(cd->wakeup_sources[i], reg);
- }
-
- return 0;
-}
-
-static void gpcv2_wakeup_source_restore(void)
-{
- struct gpcv2_irqchip_data *cd;
- void __iomem *reg;
- int i;
-
- cd = imx_gpcv2_instance;
- if (!cd)
- return;
-
- for (i = 0; i < IMR_NUM; i++) {
- reg = cd->gpc_base + cd->cpu2wakeup + i * 4;
- writel_relaxed(cd->saved_irq_mask[i], reg);
- }
-}
-
-static struct syscore_ops imx_gpcv2_syscore_ops = {
- .suspend= gpcv2_wakeup_source_save,
- .resume = gpcv2_wakeup_source_restore,
-};
-
static int imx_gpcv2_irq_set_wake(struct irq_data *d, unsigned int on)
{
struct gpcv2_irqchip_data *cd = d->chip_data;
@@ -79,9 +37,9 @@ static int imx_gpcv2_irq_set_wake(struct irq_data *d,
unsigned int on)
raw_spin_lock_irqsave(&cd->rlock, flags);
reg = cd->gpc_base + cd->cpu2wakeup + idx * 4;
mask = 1 << d->hwirq % 32;
- val = cd->wakeup_sources[idx];
-
- cd->wakeup_sources[idx] = on ? (val & ~mask) : (val | mask);
+ val = readl_relaxed(reg);
+ val = on ? (val & ~mask) : (val | mask);
+ writel_relaxed(val, reg);
raw_spin_unlock_irqrestore(&cd->rlock, flags);
/*
@@ -238,7 +196,6 @@ static int __init imx_gpcv2_irqchip_init(struct device_node
*node,
for (i = 0; i < IMR_NUM; i++) {
writel_relaxed(~0, cd->gpc_base + GPC_IMR1_CORE0 + i * 4);
writel_relaxed(~0, cd->gpc_base + GPC_IMR1_CORE1 + i * 4);
- cd->wakeup_sources[i] = ~0;
}
/* Let CORE0 as the default CPU to wake up by GPC */
@@ -252,7 +209,6 @@ static int __init imx_gpcv2_irqchip_init(struct device_node
*node,
writel_relaxed(~0x1, cd->gpc_base + cd->cpu2wakeup);
imx_gpcv2_instance = cd;
- register_syscore_ops(&imx_gpcv2_syscore_ops);
/*
* Clear the OF_POPULATED flag set in of_irq_init so that
--
2.7.4
Re: [PATCH] x86/KVM: Fix incorrect SSBD bit in kvm_cpuid_7_0_edx_x86_features
On Fri, 25 May 2018, Radim Krčmář wrote:
> 2018-05-25 13:16-0400, Waiman Long:
> > As the SSBD bit in kvm_cpuid_7_0_edx_x86_features has been renamed to
> > SPEC_CTRL_SSBD in the commit 52817587e706 ("x86/cpufeatures: Disentangle
> > SSBD enumeration"). The corresponding name change needed to be made in
> > the KVM code as well.
> >
> > Fixes: 52817587e706 ("x86/cpufeatures: Disentangle SSBD enumeration")
> >
> > Signed-off-by: Waiman Long
> > ---
>
> Thomas, are you taking this one?
Konrad sent the same fix, which is already upstream
0aa48468d009 ("KVM/VMX: Expose SSBD properly to guests")
Thanks,
tglx
Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
On Mon, May 28, 2018 at 08:10:40AM +0200, Thomas Gleixner wrote: > n Fri, 25 May 2018, Christoph Hellwig wrote: > > x86/pci-dma: ... > > Please > > > Instead of globally disabling > 32bit DMA using the arch_dma_supported > > hook walk the PCI bus under the actually affected bridge and mark every > > device with the dma_32bit_limit flag. This also gets rid of the > > arch_dma_supported hook entirely. > > Shouldn't this go before the other two? Which other two? The boot optional removal patches? They just remove the visible interface, but keep the implementation which is converted to the better mechanism here, so I think the order makes sense. But I might be missing something..
Re: [PATCH v3 13/16] mtd: rawnand: qcom: minor code reorganization for bad block check
On 2018-05-26 14:16, Miquel Raynal wrote:
Hi Abhishek,
On Fri, 25 May 2018 17:51:41 +0530, Abhishek Sahu
wrote:
The QCOM NAND controller layout is such that, the bad block byte
offset for last codeword will come to first byte in spare area.
"is the first spare byte"?
Currently, the raw read for last codeword is being done with
copy_last_cw function. It does following 2 things:
"It does the following:"
1. Read the last codeword bytes from NAND chip to NAND
controller internal HW buffer.
2. Copy all these bytes from HW buffer to actual buffer.
For bad block check, maximum two bytes are required so instead of
copying the complete bytes in step 2, only those bbm_size bytes
can be copied.
This patch does minor code reorganization for the same. After
this, copy_last_cw function won’t be required.
"This patch does minor code reorganization to just retrieve these two
bytes when checking for bad blocks, allowing to remove
copy_last_cw() now useless."
Thanks Miquel.
I will update all these.
Signed-off-by: Abhishek Sahu
---
* Changes from v2:
1. Changed commit message and comments slightly
* Changes from v1:
NEW CHANGE
drivers/mtd/nand/raw/qcom_nandc.c | 66
+++
1 file changed, 25 insertions(+), 41 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
b/drivers/mtd/nand/raw/qcom_nandc.c
index d693b5f..f72bc8a 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -1769,41 +1769,6 @@ static int read_page_ecc(struct qcom_nand_host
*host, u8 *data_buf,
return parse_read_errors(host, data_buf_start, oob_buf_start);
}
-/*
- * a helper that copies the last step/codeword of a page (containing
free oob)
- * into our local buffer
- */
-static int copy_last_cw(struct qcom_nand_host *host, int page)
-{
- struct nand_chip *chip = &host->chip;
- struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
- int size;
- int ret;
-
- clear_read_regs(nandc);
-
- size = host->use_ecc ? host->cw_data : host->cw_size;
-
- /* prepare a clean read buffer */
- memset(nandc->data_buffer, 0xff, size);
-
- set_address(host, host->cw_size * (ecc->steps - 1), page);
- update_rw_regs(host, 1, true);
-
- config_nand_single_cw_page_read(nandc);
-
- read_data_dma(nandc, FLASH_BUF_ACC, nandc->data_buffer, size, 0);
-
- ret = submit_descs(nandc);
- if (ret)
- dev_err(nandc->dev, "failed to copy last codeword\n");
-
- free_descs(nandc);
-
- return ret;
-}
-
/* implements ecc->read_page() */
static int qcom_nandc_read_page(struct mtd_info *mtd, struct
nand_chip *chip,
uint8_t *buf, int oob_required, int page)
@@ -2118,6 +2083,7 @@ static int qcom_nandc_block_bad(struct mtd_info
*mtd, loff_t ofs)
struct nand_ecc_ctrl *ecc = &chip->ecc;
int page, ret, bbpos, bad = 0;
u32 flash_status;
+ u8 *bbm_bytes_buf = chip->data_buf;
page = (int)(ofs >> chip->page_shift) & chip->pagemask;
@@ -2128,11 +2094,31 @@ static int qcom_nandc_block_bad(struct
mtd_info *mtd, loff_t ofs)
* that contains the BBM
*/
host->use_ecc = false;
+ bbpos = mtd->writesize - host->cw_size * (ecc->steps - 1);
Are we sure there is no layout with only 1 step?
All the layouts are such that, the BBM will come in
first byte of spare area.
For 4 bit ECC, the cw_size is 528 so for 2K page
2048 - 528 * 3 = 464
So for last CW, the 464 is BBM (i.e 2048th byte) in
full page.
clear_bam_transaction(nandc);
- ret = copy_last_cw(host, page);
- if (ret)
+ clear_read_regs(nandc);
+
+ set_address(host, host->cw_size * (ecc->steps - 1), page);
+ update_rw_regs(host, 1, true);
+
+ /*
+* The last codeword data will be copied from NAND device to NAND
+* controller internal HW buffer. Copy only required BBM size bytes
+* from this HW buffer to bbm_bytes_buf which is present at
+* bbpos offset.
+*/
+ nandc_set_read_loc(nandc, 0, bbpos, host->bbm_size, 1);
+ config_nand_single_cw_page_read(nandc);
+ read_data_dma(nandc, FLASH_BUF_ACC + bbpos, bbm_bytes_buf,
+ host->bbm_size, 0);
+
+ ret = submit_descs(nandc);
+ free_descs(nandc);
+ if (ret) {
+ dev_err(nandc->dev, "failed to copy bad block bytes\n");
goto err;
+ }
flash_status = le32_to_cpu(nandc->reg_read_buf[0]);
@@ -2141,12 +2127,10 @@ static int qcom_nandc_block_bad(struct
mtd_info *mtd, loff_t ofs)
goto err;
}
- bbpos = mtd->writesize - host->cw_size * (ecc->steps - 1);
-
- bad = nandc->data_buffer[bbpos] != 0xff;
+ bad = bbm_bytes_buf[0] != 0xff;
This is suspect as it still points to the beginning of the
Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag
n Fri, 25 May 2018, Christoph Hellwig wrote: x86/pci-dma: ... Please > Instead of globally disabling > 32bit DMA using the arch_dma_supported > hook walk the PCI bus under the actually affected bridge and mark every > device with the dma_32bit_limit flag. This also gets rid of the > arch_dma_supported hook entirely. Shouldn't this go before the other two? > Signed-off-by: Christoph Hellwig Reviewed-by: Thomas Gleixner
[PATCH] powerpc/Makefile: set -mcpu=860 flag for the 8xx
When compiled with GCC 8.1, vmlinux is significantly bigger than with GCC 4.8. When looking at the generated code with objdump, we notice that all functions and loops when a 16 bytes alignment. This significantly increases the size of the kernel. It is pointless and even counterproductive as on the 8xx 'nop' also consumes one clock cycle. Size of vmlinux with GCC 4.8: textdata bss dec hex filename 5801948 1626076 457796 7885820 7853fc vmlinux Size of vmlinux with GCC 8.1: textdata bss dec hex filename 6764592 1630652 456476 8851720 871108 vmlinux Size of vmlinux with GCC 8.1 and this patch: textdata bss dec hex filename 6331544 1631756 456476 8419776 8079c0 vmlinux Signed-off-by: Christophe Leroy --- arch/powerpc/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 6a050b42a9f2..26ccd0b91512 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -178,6 +178,7 @@ CFLAGS-$(CONFIG_POWER6_CPU) += $(call cc-option,-mcpu=power6) CFLAGS-$(CONFIG_POWER7_CPU) += $(call cc-option,-mcpu=power7) CFLAGS-$(CONFIG_POWER8_CPU) += $(call cc-option,-mcpu=power8) CFLAGS-$(CONFIG_POWER9_CPU) += $(call cc-option,-mcpu=power9) +CFLAGS-$(CONFIG_PPC_8xx) += $(call cc-option,-mcpu=860) # Altivec option not allowed with e500mc64 in GCC. ifeq ($(CONFIG_ALTIVEC),y) -- 2.13.3
Re: [PATCH 6/7] x86: remove the explicit nodac and allowdac option
On Fri, 25 May 2018, Christoph Hellwig wrote: x86/pci-dma: ... Please > This is something drivers should decide (modulo chipset quirks like > for VIA), which as far as I can tell is how things have been handled > for the last 15 years. > > Note that we keep the usedac option for now, as it is used in the wild > to override the too generic VIA quirk. > > Signed-off-by: Christoph Hellwig Reviewed-by: Thomas Gleixner
Re: [PATCH 5/7] x86: remove the experimental forcesac boot option
On Fri, 25 May 2018, Christoph Hellwig wrote: x86/pci-dma: ... Please > Limiting the dma mask to avoid PCI (pre-PCIe) DAC cycles while paying > the huge overhead of an IOMMU is rather pointless, and this seriously > gets in the way of dma mapping work. > > Signed-off-by: Christoph Hellwig Reviewed-by: Thomas Gleixner
Re: [alsa-devel] [PATCH v2 1/3] ASoC: topology: Improve backwards compatibility with v4 topology files
On 25-05-18, 19:03, Shreyas NC wrote:
> Adding Vinod to help review as well..
Thanks Shreyas,
> > Commit dc31e741db49 ("ASoC: topology: ABI - Add the types for BE
> > DAI") introduced sound topology files version 5. Initially, this
> > change made the topology code incompatible with v4 topology files.
> > Backwards compatibility with v4 configuration files was
> > subsequently added with commit 288b8da7e992 ("ASoC: topology:
> > Support topology file of ABI v4").
> >
> > Unfortunately, backwards compatibility was never fully implemented.
To give the history, we implement the binary method for data. The structures
given here were indeed ABI but we didn't move them to uapi/ as it was still in
development and with help from Takashi we finally zoomed on Tuple method for
describing the data and hence that was implemented and updated and alsa-lib
files also updated.
I am not sure we were able to ship any alsa release with this method due to
complexity of running intel tool to generate binary data and patch the topology
files.
> > First, the manifest size in (Skylake) v4 configuration files is set
> > to 0, which causes manifest_new_ver() to bail out with error messages
> > similar to the following.
So is this issue with Chrome kernel or upstream? We did ask Chrome to
cherry-pick patches for tuple support for SKL but I guess it was late for
release cycle for them and for SKL I dont think Chrome people took it. Yeah
perils of upstream and production racing...
> >
> > snd_soc_skl :00:1f.3: ASoC: invalid manifest size
> > snd_soc_skl :00:1f.3: tplg component load failed-22
> > snd_soc_skl :00:1f.3: Failed to init topology!
> > snd_soc_skl :00:1f.3: ASoC: failed to probe component -22
> > skl_n88l25_m98357a skl_n88l25_m98357a: ASoC: failed to instantiate card -22
> > skl_n88l25_m98357a: probe of skl_n88l25_m98357a failed with error -22
> >
> > After this problem is fixed, the following error message is seen instead.
> >
> > snd_soc_skl :00:1f.3: ASoC: old version of manifest
> > snd_soc_skl :00:1f.3: Invalid descriptor token 1093938482
> > snd_soc_skl :00:1f.3: ASoC: failed to load widget media0_in cpr 0
> > snd_soc_skl :00:1f.3: tPlg component load failed-22
> >
> > This message is seen because backwards compatibility for loading widgets
> > was never implemented.
> >
> > The lack of audio support when running the upstream kernel on recent
> > Chromebooks has been reported in various forums, and can be traced back
> > to this problem. Attempts to fix the problem, usually by providing v5
> > configuration files, were only partially successful.
> >
> > Let's implement backward compatibility properly to solve the problem
> > for good.
Thanks for doing this, great work indeed.
> > diff --git a/sound/soc/intel/skylake/skl-tplg-interface.h
> > b/sound/soc/intel/skylake/skl-tplg-interface.h
> > index f8d1749a2e0c..b0e3d376594c 100644
> > --- a/sound/soc/intel/skylake/skl-tplg-interface.h
> > +++ b/sound/soc/intel/skylake/skl-tplg-interface.h
Don't we want to move these to upai/ as that is right place and use that in
alsa-lib.
--
~Vinod
Re: [PATCH v3 06/16] mtd: rawnand: qcom: use the ecc strength from device parameter
On 2018-05-26 14:13, Miquel Raynal wrote:
Hi Abhishek,
On Fri, 25 May 2018 17:51:34 +0530, Abhishek Sahu
wrote:
Currently the driver uses the ECC strength specified in DT.
The QPIC/EBI2 NAND supports 4 or 8-bit ECC correction. The same
kind of board can have different NAND parts so use the ECC
strength from device parameters if it is not specified in DT.
Signed-off-by: Abhishek Sahu
---
* Changes from v2:
NONE
Yes you did change things:
- s/<< 2/* 4/
- updated the cwperpage location
- the block handling the ecc-step-size property has been removed in a
previous patch
Please be careful with that, it is time consuming to review the patches
all over again.
Sorry Miquel for that.
I Will pay more attention to this.
I can understand the effort require in reviewing and how this can help
in making review quicker.
* Changes from v1:
1. Removed the custom logic and used the helper fuction.
drivers/mtd/nand/raw/qcom_nandc.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
b/drivers/mtd/nand/raw/qcom_nandc.c
index b538390..7377923 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2315,19 +2315,39 @@ static int qcom_nand_ooblayout_free(struct
mtd_info *mtd, int section,
.free = qcom_nand_ooblayout_free,
};
+static int
+qcom_nandc_calc_ecc_bytes(int step_size, int strength)
+{
+ return strength == 4 ? 12 : 16;
+}
+NAND_ECC_CAPS_SINGLE(qcom_nandc_ecc_caps, qcom_nandc_calc_ecc_bytes,
+NANDC_STEP_SIZE, 4, 8);
+
static int qcom_nand_host_setup(struct qcom_nand_host *host)
{
struct nand_chip *chip = &host->chip;
struct mtd_info *mtd = nand_to_mtd(chip);
struct nand_ecc_ctrl *ecc = &chip->ecc;
struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
- int cwperpage, bad_block_byte;
+ int cwperpage, bad_block_byte, ret;
bool wide_bus;
int ecc_mode = 1;
/* controller only supports 512 bytes of data in each step */
ecc->size = NANDC_STEP_SIZE;
wide_bus = chip->options & NAND_BUSWIDTH_16 ? true : false;
+ cwperpage = mtd->writesize / NANDC_STEP_SIZE;
+
+ /*
+ * Each CW has 4 available OOB bytes which will be protected with
ECC
+* so remaining bytes can be used for ECC.
+*/
+ ret = nand_ecc_choose_conf(chip, &qcom_nandc_ecc_caps,
+ mtd->oobsize - cwperpage * 4);
Nitpick: could you add parenthesis around (cwperpage * 4) just for
clarity.
Thanks Miquel.
I will update that.
Regards,
Abhishek
+ if (ret) {
+ dev_err(nandc->dev, "No valid ECC settings possible\n");
+ return ret;
+ }
if (ecc->strength >= 8) {
/* 8 bit ECC defaults to BCH ECC on all platforms */
@@ -2396,7 +2416,6 @@ static int qcom_nand_host_setup(struct
qcom_nand_host *host)
mtd_set_ooblayout(mtd, &qcom_nand_ooblayout_ops);
- cwperpage = mtd->writesize / ecc->size;
nandc->max_cwperpage = max_t(unsigned int, nandc->max_cwperpage,
cwperpage);
@@ -2412,12 +2431,6 @@ static int qcom_nand_host_setup(struct
qcom_nand_host *host)
* for 8 bit ECC
*/
host->cw_size = host->cw_data + ecc->bytes;
-
- if (ecc->bytes * (mtd->writesize / ecc->size) > mtd->oobsize) {
- dev_err(nandc->dev, "ecc data doesn't fit in OOB area\n");
- return -EINVAL;
- }
-
bad_block_byte = mtd->writesize - host->cw_size * (cwperpage - 1) +
1;
host->cfg0 = (cwperpage - 1) << CW_PER_PAGE
Once corrected:
Acked-by: Miquel Raynal
Thanks,
Miquèl
RE: [PATCH 2/2] PM / devfreq: Generic cpufreq governor
>Many CPU architectures have caches that can scale independent of the CPUs. >Frequency scaling of the caches is necessary to make sure the cache is not >a performance bottleneck that leads to poor performance and power. The same >idea applies for RAM/DDR. > >To achieve this, this patch series adds a generic devfreq governor that can >listen to the frequency transitions of each CPU frequency domain and then >adjusts the frequency of the cache (or any devfreq device) based on the >frequency of the CPUs. I agree that we have some hardware pieces that want to configure frequencies based on the CPUfreq. Creating a devfreq governor that configures devfreq-freq based on incoming events (CPUFreq-transition-event in this case) is indeed a good idea. However, I would like to ask the followings: The overall code appears to be overly complex compared what you need. - Do you really need to revive "CPUFREQ POLICY" events for this? especially when you are going to look at "first CPU" only? Cheers, MyungJoo
Re: [PATCH v3 05/16] mtd: rawnand: qcom: remove dt property nand-ecc-step-size
On 2018-05-26 14:12, Miquel Raynal wrote:
Hi Abhishek,
On Fri, 25 May 2018 17:51:33 +0530, Abhishek Sahu
wrote:
QCOM NAND controller supports only one step size (512) so
nand-ecc-step-size DT property is redundant. This property
can be removed and ecc step size can be assigned with 512 value.
Signed-off-by: Abhishek Sahu
---
* Changes from v2:
NEW CHANGE
1. Removed the custom logic and used the helper fuction.
drivers/mtd/nand/raw/qcom_nandc.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
b/drivers/mtd/nand/raw/qcom_nandc.c
index b554fb6..b538390 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2325,15 +2325,8 @@ static int qcom_nand_host_setup(struct
qcom_nand_host *host)
bool wide_bus;
int ecc_mode = 1;
- /*
-* the controller requires each step consists of 512 bytes of data.
-* bail out if DT has populated a wrong step size.
-*/
- if (ecc->size != NANDC_STEP_SIZE) {
- dev_err(nandc->dev, "invalid ecc size\n");
- return -EINVAL;
- }
-
+ /* controller only supports 512 bytes of data in each step */
"512 bytes data steps"
Thanks Miquel.
Will update that.
Regards,
Abhishek
+ ecc->size = NANDC_STEP_SIZE;
wide_bus = chip->options & NAND_BUSWIDTH_16 ? true : false;
if (ecc->strength >= 8) {
Once corrected:
Acked-by: Miquel Raynal
Re: [PATCH v3 03/16] dt-bindings: qcom_nandc: make nand-ecc-strength optional
On 2018-05-26 14:12, Miquel Raynal wrote: Hi Abhishek, On Fri, 25 May 2018 17:51:31 +0530, Abhishek Sahu wrote: If nand-ecc-strength specified in DT, then controller will use this ECC strength otherwise ECC strength will be calculated according to chip requirement and available OOB size. Signed-off-by: Abhishek Sahu --- * Changes from v2: NONE * Changes from v1: NEW PATCH Documentation/devicetree/bindings/mtd/qcom_nandc.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt index 73d336be..f246aa0 100644 --- a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt +++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt @@ -45,11 +45,13 @@ Required properties: number (e.g., 0, 1, 2, etc.) - #address-cells: see partition.txt - #size-cells: see partition.txt -- nand-ecc-strength: see nand.txt - nand-ecc-step-size: must be 512. see nand.txt for more details. I think you can squash the two dt-bindings commits as they are tightly related to each other. Sure Miquel. Earlier made one patch and then split into two. Will squash that and make single patch again :-) Thanks, Abhishek Optional properties: - nand-bus-width: see nand.txt +- nand-ecc-strength: see nand.txt. If not specified, then ECC strength will + be used according to chip requirement and available + OOB size. Each nandcs device node may optionally contain a 'partitions' sub-node, which further contains sub-nodes describing the flash partition mapping. See
Re: [PATCH v3 01/16] mtd: rawnand: helper function for setting up ECC configuration
On 2018-05-26 14:12, Miquel Raynal wrote:
Hi Abhishek,
On Fri, 25 May 2018 17:51:29 +0530, Abhishek Sahu
wrote:
commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
match, maximize ECC settings") provides generic helpers which
drivers can use for setting up ECC parameters.
Since same board can have different ECC strength nand chips so
following is the logic for setting up ECC strength and ECC step
size, which can be used by most of the drivers.
1. If both ECC step size and ECC strength are already set
(usually by DT) then just check whether this setting
is supported by NAND controller.
2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
supported by NAND controller.
3. Otherwise, try to match the ECC step size and ECC strength closest
to the chip's requirement. If available OOB size can't fit the chip
requirement then select maximum ECC strength which can be fit with
available OOB size.
This patch introduces nand_ecc_choose_conf function which calls the
required helper functions for the above logic. The drivers can use
this single function instead of calling the 3 helper functions
individually.
CC: Masahiro Yamada
Signed-off-by: Abhishek Sahu
---
* Changes from v2:
1. Renamed function to nand_ecc_choose_conf.
2. Minor code reorganization to remove warning and 2 function calls
for nand_maximize_ecc.
* Changes from v1:
NEW PATCH
drivers/mtd/nand/raw/nand_base.c | 42
drivers/mtd/nand/raw/nand_base.c | 31 +++
include/linux/mtd/rawnand.h | 3 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_base.c
b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89..e52019d 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -6249,6 +6249,37 @@ int nand_maximize_ecc(struct nand_chip *chip,
}
EXPORT_SYMBOL_GPL(nand_maximize_ecc);
+/**
+ * nand_ecc_choose_conf - Set the ECC strength and ECC step size
+ * @chip: nand chip info structure
+ * @caps: ECC engine caps info structure
+ * @oobavail: OOB size that the ECC engine can use
+ *
+ * Choose the ECC configuration according to following logic
+ *
+ * 1. If both ECC step size and ECC strength are already set (usually
by DT)
+ *then check if it is supported by this controller.
+ * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
+ * 3. Otherwise, try to match the ECC step size and ECC strength
closest
+ *to the chip's requirement. If available OOB size can't fit the
chip
+ *requirement then fallback to the maximum ECC step size and ECC
strength.
+ *
+ * On success, the chosen ECC settings are set.
+ */
+int nand_ecc_choose_conf(struct nand_chip *chip,
+const struct nand_ecc_caps *caps, int oobavail)
+{
+ if (chip->ecc.size && chip->ecc.strength)
+ return nand_check_ecc_caps(chip, caps, oobavail);
+
+ if (!(chip->ecc.options & NAND_ECC_MAXIMIZE) &&
+ !nand_match_ecc_req(chip, caps, oobavail))
+ return 0;
+
+ return nand_maximize_ecc(chip, caps, oobavail);
I personally don't mind if nand_maximize_ecc() is called twice in
the function if it clarifies the logic. Maybe the following will be
more clear for the user?
Thanks Miquel.
Both the implementations are fine.
The above implementation (which was in Denali NAND driver) code was
also
clear. We can go for any of these implementation.
Shall I update this ?
if (chip->ecc.size && chip->ecc.strength)
return nand_check_ecc_caps(chip, caps, oobavail);
if (chip->ecc.options & NAND_ECC_MAXIMIZE)
return nand_maximize_ecc(chip, caps, oobavail);
if (!nand_match_ecc_req(chip, caps, oobavail))
return 0;
return nand_maximize_ecc(chip, caps, oobavail);
Also, I'm not sure we should just error out when nand_check_ecc_caps()
fails. What about something more robust, like:
But again, It will lead in overriding the DT ECC strength parameter.
We started our discussion from that point. :-)
Thanks,
Abhishek
int ret;
if (chip->ecc.size && chip->ecc.strength) {
ret = nand_check_ecc_caps(chip, caps, oobavail);
if (ret)
goto maximize_ecc;
return 0;
}
if (chip->ecc.options & NAND_ECC_MAXIMIZE)
goto maximize_ecc;
ret = nand_match_ecc_req(chip, caps, oobavail);
if (ret)
goto maximize_ecc;
return 0;
maximize_ecc:
return nand_maximize_ecc(chip, caps, oobavail);
+}
+EXPORT_SYMBOL_GPL(nand_ecc_choose_conf);
+
/*
* Check if the chip configuration meet the datasheet requirements.
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 5dad59b..89889fa 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -1627,6 +1627,9 @
[PATCH 3/3] thermal: broadcom: Add Stingray thermal driver
From: Pramod Kumar
This commit adds stingray thermal driver to monitor six
thermal zones temperature and trips at critical temperature.
Signed-off-by: Pramod Kumar
Signed-off-by: Srinath Mannam
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Vikram Prakash
---
drivers/thermal/Kconfig | 3 +-
drivers/thermal/broadcom/Kconfig | 9 ++
drivers/thermal/broadcom/Makefile | 1 +
drivers/thermal/broadcom/sr-thermal.c | 151 ++
4 files changed, 163 insertions(+), 1 deletion(-)
create mode 100644 drivers/thermal/broadcom/sr-thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 8297988..26d39d4 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -416,7 +416,8 @@ config MTK_THERMAL
controller present in Mediatek SoCs
menu "Broadcom thermal drivers"
-depends on ARCH_BCM || ARCH_BRCMSTB || ARCH_BCM2835 || COMPILE_TEST
+depends on ARCH_BCM || ARCH_BRCMSTB || ARCH_BCM2835 || ARCH_BCM_IPROC || \
+ COMPILE_TEST
source "drivers/thermal/broadcom/Kconfig"
endmenu
diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
index c106a15..dc9a9bd 100644
--- a/drivers/thermal/broadcom/Kconfig
+++ b/drivers/thermal/broadcom/Kconfig
@@ -22,3 +22,12 @@ config BCM_NS_THERMAL
BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
Management Unit) block with a thermal sensor that allows checking CPU
temperature.
+
+config BCM_SR_THERMAL
+ tristate "Stingray thermal driver"
+ depends on ARCH_BCM_IPROC || COMPILE_TEST
+ default ARCH_BCM_IPROC
+ help
+ Support for the Stingray family of SoCs. Its different blocks like
+ iHost, CRMU and NITRO has thermal sensor that allows checking its
+ temperature.
diff --git a/drivers/thermal/broadcom/Makefile
b/drivers/thermal/broadcom/Makefile
index fae10ec..79df69e 100644
--- a/drivers/thermal/broadcom/Makefile
+++ b/drivers/thermal/broadcom/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
obj-$(CONFIG_BRCMSTB_THERMAL) += brcmstb_thermal.o
obj-$(CONFIG_BCM_NS_THERMAL) += ns-thermal.o
+obj-$(CONFIG_BCM_SR_THERMAL) += sr-thermal.o
diff --git a/drivers/thermal/broadcom/sr-thermal.c
b/drivers/thermal/broadcom/sr-thermal.c
new file mode 100644
index 000..5baaa6e
--- /dev/null
+++ b/drivers/thermal/broadcom/sr-thermal.c
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+
+#define TMON_CRIT_TEMP 105000 /* temp in millidegree C */
+
+struct sr_thermal {
+ struct thermal_zone_device *tz;
+ struct device *dev;
+ void __iomem *regs;
+ unsigned int crit_temp;
+};
+
+static int sr_get_temp(struct thermal_zone_device *tz, int *temp)
+{
+ struct sr_thermal *sr_thermal = tz->devdata;
+
+ *temp = readl(sr_thermal->regs);
+
+ return 0;
+}
+
+static int sr_get_trip_type(struct thermal_zone_device *tz, int trip,
+ enum thermal_trip_type *type)
+{
+ struct sr_thermal *sr_thermal = tz->devdata;
+
+ switch (trip) {
+ case 0:
+ *type = THERMAL_TRIP_CRITICAL;
+ break;
+ default:
+ dev_dbg(sr_thermal->dev,
+ "Driver does not support more than 1 trip point\n");
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int sr_get_trip_temp(struct thermal_zone_device *tz, int trip, int
*temp)
+{
+ struct sr_thermal *sr_thermal = tz->devdata;
+
+ switch (trip) {
+ case 0:
+ *temp = sr_thermal->crit_temp;
+ break;
+ default:
+ dev_dbg(sr_thermal->dev,
+ "Driver does not support more than 1 trip point\n");
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int sr_set_trip_temp(struct thermal_zone_device *tz, int trip, int temp)
+{
+ struct sr_thermal *sr_thermal = tz->devdata;
+
+ switch (trip) {
+ case 0:
+ /*
+* Allow the user to change critical temperature
+* as per their requirement, could be for debug
+* purpose, even if it's more than the recommended
+* critical temperature.
+*/
+ sr_thermal->crit_temp = temp;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static struct thermal_zone_device_ops sr_thermal_ops = {
+ .get_temp = sr_get_temp,
+ .get_trip_type = sr_get_trip_type,
+ .get_trip_temp = sr_get_trip_temp,
+ .set_trip_temp = sr_set_trip_temp,
+};
+
+static int sr_thermal_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct sr_thermal *sr_thermal;
+ st
[PATCH 2/3] arm64: dts: stingray: Add Stingray Thermal DT support.
From: Pramod Kumar
Add DT nodes for thermal zones memory base address
to read temperature.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Srinath Mannam
---
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 37 ++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 99aaff0..db1cc67 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -593,4 +593,41 @@
status = "disabled";
};
};
+
+ tmons {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x8f10 0x100>;
+
+ tmon_ihost0: thermal@0 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x0 0x4>;
+ };
+
+ tmon_ihost1: thermal@4 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x4 0x4>;
+ };
+
+ tmon_ihost2: thermal@8 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x8 0x4>;
+ };
+
+ tmon_ihost3: thermal@c {
+ compatible = "brcm,sr-thermal";
+ reg = <0xc 0x4>;
+ };
+
+ tmon_crmu: thermal@10 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x10 0x4>;
+ };
+
+ tmon_nitro: thermal@14 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x14 0x4>;
+ };
+ };
};
--
2.7.4
[PATCH 1/3] dt-bindings: thermal: Add binding document for SR thermal
From: Pramod Kumar
Add binding document for supported thermal implementation
in Stingray.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Srinath Mannam
---
.../bindings/thermal/brcm,sr-thermal.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
new file mode 100644
index 000..33f9e11
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
@@ -0,0 +1,45 @@
+* Broadcom Stingray Thermal
+
+This binding describes thermal sensors that is part of Stingray SoCs.
+
+Required properties:
+- compatible : Must be "brcm,sr-thermal"
+- reg : memory where tmon data will be available.
+
+Example:
+ tmons {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ tmon_ihost0: thermal@8f10 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x8f10 0x4>;
+ };
+
+ tmon_ihost1: thermal@8f14 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x8f14 0x4>;
+ };
+
+ tmon_ihost2: thermal@8f18 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x8f18 0x4>;
+ };
+
+ tmon_ihost3: thermal@8f1c {
+ compatible = "brcm,sr-thermal";
+ reg = <0x8f1c 0x4>;
+ };
+
+ tmon_crmu: thermal@8f100010 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x8f100010 0x4>;
+ };
+
+ tmon_nitro: thermal@8f100014 {
+ compatible = "brcm,sr-thermal";
+ reg = <0x8f100014 0x4>;
+ };
+ };
--
2.7.4
[PATCH 0/3] Stingray thermal driver support
These patches adds the stingray thermal driver and its corresponding DT nodes with documentation. Pramod Kumar (3): dt-bindings: thermal: Add binding document for SR thermal arm64: dts: stingray: Add Stingray Thermal DT support. thermal: broadcom: Add Stingray thermal driver .../bindings/thermal/brcm,sr-thermal.txt | 45 ++ .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 37 + drivers/thermal/Kconfig| 3 +- drivers/thermal/broadcom/Kconfig | 9 ++ drivers/thermal/broadcom/Makefile | 1 + drivers/thermal/broadcom/sr-thermal.c | 151 + 6 files changed, 245 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt create mode 100644 drivers/thermal/broadcom/sr-thermal.c -- 2.7.4
Re: [PATCH 04/11] PM / devfreq: Remove redundant frequency adjustment from governors
Hi,
On 2018년 05월 26일 05:30, Matthias Kaehlcke wrote:
> The userspace and simpleondemand governor determine a target frequency and
> then adjust it according to the df->min/max_freq limits that might have
> been set by user space. This adjustment is redundant, it is done in
> update_devfreq() for any governor, right after returning from
> governor->get_target_freq().
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/devfreq/governor_simpleondemand.c | 5 -
> drivers/devfreq/governor_userspace.c | 16
> 2 files changed, 4 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/devfreq/governor_simpleondemand.c
> b/drivers/devfreq/governor_simpleondemand.c
> index 278964783fa6..3da7554b4837 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -84,11 +84,6 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
> b = div_u64(b, (dfso_upthreshold - dfso_downdifferential / 2));
> *freq = (unsigned long) b;
>
> - if (df->min_freq && *freq < df->min_freq)
> - *freq = df->min_freq;
> - if (df->max_freq && *freq > df->max_freq)
> - *freq = df->max_freq;
> -
> return 0;
> }
>
> diff --git a/drivers/devfreq/governor_userspace.c
> b/drivers/devfreq/governor_userspace.c
> index 080607c3f34d..378d84c011df 100644
> --- a/drivers/devfreq/governor_userspace.c
> +++ b/drivers/devfreq/governor_userspace.c
> @@ -26,19 +26,11 @@ static int devfreq_userspace_func(struct devfreq *df,
> unsigned long *freq)
> {
> struct userspace_data *data = df->data;
>
> - if (data->valid) {
> - unsigned long adjusted_freq = data->user_frequency;
> -
> - if (df->max_freq && adjusted_freq > df->max_freq)
> - adjusted_freq = df->max_freq;
> -
> - if (df->min_freq && adjusted_freq < df->min_freq)
> - adjusted_freq = df->min_freq;
> -
> - *freq = adjusted_freq;
> - } else {
> + if (data->valid)
> + *freq = data->user_frequency;
> + else
> *freq = df->previous_freq; /* No user freq specified yet */
> - }
> +
> return 0;
> }
>
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH v9 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs
Hi, On 5/24/2018 4:15 PM, Raju P L S S S N wrote: From: Lina Iyer Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger Control Set (TCS) is a bunch of slots that can house multiple resource state requests, that when triggered will issue those requests through an internal bus to the Resource Power Manager Hardened (RPMH) blocks. These hardware blocks are capable of adjusting clocks, voltages, etc. The resource state request from a DRV are aggregated along with state requests from other processors in the SoC and the aggregate value is applied on the resource. Some important aspects of the RPMH communication - - Requests are with some header information - Multiple requests (upto 16) may be sent through a TCS, at a time - Requests in a TCS are sent in sequence - Requests may be fire-n-forget or completion (response expected) - Multiple TCS from the same DRV may be triggered simultaneously - Cannot send a request if another request for the same addr is in progress from the same DRV - When all the requests from a TCS are complete, an IRQ is raised - The IRQ handler needs to clear the TCS before it is available for reuse - TCS configuration is specific to a DRV - Platform drivers may use DRV from different RSCs to make requests Resource state requests made when CPUs are active are called 'active' state requests. Requests made when all the CPUs are powered down (idle state) are called 'sleep' state requests. They are matched by a corresponding 'wake' state requests which puts the resources back in to previously requested active state before resuming any CPU. TCSes are dedicated for each type of requests. Active mode TCSes (AMC) are used to send requests immediately to the resource, while control TCS are used to provide specific information to the controller. Sleep and Wake TCS send sleep and wake requests, after and before the system halt respectively. Signed-off-by: Lina Iyer Signed-off-by: Raju P.L.S.S.S.N Reviewed-by: Douglas Anderson I have added Reviewed-by: Douglas Anderson tag by mistake while sending v9 patches. Didn't receive the tag. Will remove it in next spin. Thanks, Raju --- Changes in v9: - Remove EXPORT_SYMBOL Changes in v8: - introduce interrupt description in DT for all DRvs Changes in v7: - rename 'm' and 'n' variable names Changes in v6: - Remove tasklet and response object - introduce rpm_write_tcs_cmd() function - rename tcs_irq_handler() - avoid bool in structures. Fix tcs.h. Changes in v4: - lots of variable name changes as suggested by Stephen B - use of const for data pointers - fix comments and other code syntax - use of bitmap for tcs_in_use instead of atomic --- drivers/soc/qcom/Kconfig| 10 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/rpmh-internal.h| 69 + drivers/soc/qcom/rpmh-rsc.c | 482 include/dt-bindings/soc/qcom,rpmh-rsc.h | 14 + include/soc/qcom/tcs.h | 56 6 files changed, 632 insertions(+) create mode 100644 drivers/soc/qcom/rpmh-internal.h create mode 100644 drivers/soc/qcom/rpmh-rsc.c create mode 100644 include/dt-bindings/soc/qcom,rpmh-rsc.h create mode 100644 include/soc/qcom/tcs.h diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index 5c4535b..1887e1b 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -56,6 +56,16 @@ config QCOM_RMTFS_MEM Say y here if you intend to boot the modem remoteproc. +config QCOM_RPMH + bool "Qualcomm RPM-Hardened (RPMH) Communication" + depends on ARCH_QCOM && ARM64 && OF || COMPILE_TEST + help + Support for communication with the hardened-RPM blocks in + Qualcomm Technologies Inc (QTI) SoCs. RPMH communication uses an + internal bus to transmit state requests for shared resources. A set + of hardware components aggregate requests for these resources and + help apply the aggregated state on the resource. + config QCOM_SMEM tristate "Qualcomm Shared Memory Manager (SMEM)" depends on ARCH_QCOM diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile index dcebf28..39d3a05 100644 --- a/drivers/soc/qcom/Makefile +++ b/drivers/soc/qcom/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_QCOM_PM) += spm.o obj-$(CONFIG_QCOM_QMI_HELPERS)+= qmi_helpers.o qmi_helpers-y += qmi_encdec.o qmi_interface.o obj-$(CONFIG_QCOM_RMTFS_MEM) += rmtfs_mem.o +obj-$(CONFIG_QCOM_RPMH)+= rpmh-rsc.o obj-$(CONFIG_QCOM_SMD_RPM)+= smd-rpm.o obj-$(CONFIG_QCOM_SMEM) +=smem.o obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem
On 27.05.2018 22:31, Florian Fainelli wrote:
Le 05/27/18 à 12:01, Gerhard Wiesinger a écrit :
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the current
implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac3ac43fa1d
Florians comment:
c499696e7901bda18385ac723b7bd27c3a4af624 ("net: dsa: b53: Stop using
dev->cpu_port incorrectly") since it would result in no longer setting
the CPU port as tagged for a specific VLAN. Easiest way for you right
now is to just revert it, but this needs some more thoughts for a proper
upstream change. I will think about it some more.
Can confirm 4.14.18-200.fc26.armv7hl works, 4.15.x should be broken.
# Kernel 4.14.x ok
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/net/dsa/b53?h=v4.14.43
# Kernel 4.15.x should be NOT ok
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/net/dsa/b53?h=v4.15.18
Kernel 4.14.18-300.fc27.armv7hl works well so far, even with FC28
update. Florian send me a patch to try for 4.16.x
So does my patch make 4.16 work correctly for you now? If so, can I just
submit it and copy you?
I got the commands below to work with manual script commands.
Afterwards I wrote systemd-networkd config where I've a strage problem
when IPv6 sends a multicast broadcast from another machine to the bridge
this will be sent back via the network interface, but with the source
MAC of the bridge of the other machine. dmesg from the other machine:
[117768.330444] br0: received packet on lan0 with own address as source
address (addr:a0:36:9f:ab:cd:ef, vlan:0)
[117768.334887] br0: received packet on lan0 with own address as source
address (addr:a0:36:9f:ab:cd:ef, vlan:0)
[117768.339281] br0: received packet on lan0 with own address as source
address (addr:a0:36:9f:ab:cd:ef, vlan:0)
And: If I just enter this command after e.g. a systemd-network restart
everything is fine forever:
# Not OK (dmesg message above is triggered on a remote computer, whole
switching network gets unstable, ssh terminals close, packet loss, etc.)
systemctl restart systemd-networkd
# OK again when this command is entered
bridge vlan add dev wan vid 102 pvid untagged
brctl show, ip link, bridge vlan, bridge link commands, etc. look all
the same, also /sys/class/net/br0/bridge, /sys/class/net/br1/bridge
settings
Systemd config correct?
Any ideas?
You should not have eth0.101 and eth0.102 to be enslaved in a bridge at
all, this is what is causing the bridge to be confused. Remember what I
wrote to you before, with the current b53 driver that does not have any
tagging enabled the lanX interfaces and brX interfaces are only used for
control and should not be used for passing any data. The only network
device that will be passing data is eth0, which is why we need to set-up
VLAN interfaces to pop/push the VLAN id accordingly.
I have no idea why manual vs. systemd does not work but you can most
certainly troubleshoot that by comparing the bridge/ip outputs.
So is that then the correct structure?
br1
- lan1 (with VID 101)
- lan2 (with VID 101)
- lan3 (with VID 101)
- lan4 (with VID 101)
brlan
- eth0.101
- wlan0 (currently not active, could be optimized without bridge but for
future comfort)
br2
- wan (with VID 102) (could be optimized without bridge but for future
comfort)
- future1
brwan
- eth0.102 (could be optimized without bridge but for future comfort)
- future2
Ad systemd vs. manual config: As I said I didn't find any difference in
the bridge/ip outputs. As they are broken (see other message) maybe
something else is broken, too.
Thnx.
Ciao,
Gerhard
Can I use 'signed -off-by' to define maintainers' workload?
Hi all, I am a student from Peking University. I'm not sure if it's appropriate to ask questions here. I have already tried other mailing lists, but I got no reply. I am very sorry to bother all of you. I am doing a research about the maintainers' workload in the Linux kernel community. We all know that the commits submitted by the developer will be reviewed layer by layer and eventually merged into the main repository. Most commits have one or several signed-off-by tags. The documentation from community about signed-off-by is described as follows: The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch. The documentation is very clear, which means that only two types of people can sign their name: 1. The author 2. The related maintainer. I want to define the maintainer's workload by this tag. There are several questions that I would like to consult you: 1) Do all the maintainers in the path from the author of the commits to the mainline repository sign their name? 2) If the answer is yes, do the workload of subsystem maintainer and the upper maintainer are the same in the code review? In other words, whether is it possible that the first maintainer who merge the commits submitted by the developer to its own repository spend a lot effort on review? The upper maintainer is based on the trust of the lower layer maintainer, and simply merges it into his/her own repository as long as there is no compiling problem and also sign their name. 3) If the answer is no, why do some maintainers sign their names, and some do not? Is it because these maintainers trust the lower layer very much and feel that it is not necessary to review it? 4) Is there any special situation that leads to signing-off-by not identifying all the maintainers in the path of the commits develiry? For example, the upper maintainer does not trust the lower layer maintainers, and he/she will contribute a new commits by himself instead of passing by, so it will not record the maintainer of the lower layer. Or because this commit contains modification to several files and each file has a specific maintainer, only one maintainer merged it to his repository and signed his name. In short, I would like to know how signed-off-by is used in the actual process. I would be grateful if you could reply to me. Thank you again! Best regards, Xin Tan
Re: [PATCH 03/11] PM / devfreq: Remove check for df->max_freq == 0 from governors
Hi,
On 2018년 05월 26일 05:30, Matthias Kaehlcke wrote:
> Commit "PM / devfreq: Fix handling of min/max_freq == 0" ensures that
> df->max_freq is not 0, remove unnecessary checks.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/devfreq/governor_performance.c| 5 +
> drivers/devfreq/governor_simpleondemand.c | 7 +++
> 2 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/devfreq/governor_performance.c
> b/drivers/devfreq/governor_performance.c
> index 4d23ecfbd948..1c990cb45098 100644
> --- a/drivers/devfreq/governor_performance.c
> +++ b/drivers/devfreq/governor_performance.c
> @@ -20,10 +20,7 @@ static int devfreq_performance_func(struct devfreq *df,
>* target callback should be able to get floor value as
>* said in devfreq.h
>*/
> - if (!df->max_freq)
> - *freq = UINT_MAX;
> - else
> - *freq = df->max_freq;
> + *freq = df->max_freq;
> return 0;
> }
>
> diff --git a/drivers/devfreq/governor_simpleondemand.c
> b/drivers/devfreq/governor_simpleondemand.c
> index 28e0f2de7100..278964783fa6 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -27,7 +27,6 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
> unsigned int dfso_upthreshold = DFSO_UPTHRESHOLD;
> unsigned int dfso_downdifferential = DFSO_DOWNDIFFERENCTIAL;
> struct devfreq_simple_ondemand_data *data = df->data;
> - unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
>
> err = devfreq_update_stats(df);
> if (err)
> @@ -47,7 +46,7 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
>
> /* Assume MAX if it is going to be divided by zero */
> if (stat->total_time == 0) {
> - *freq = max;
> + *freq = df->max_freq;
> return 0;
> }
>
> @@ -60,13 +59,13 @@ static int devfreq_simple_ondemand_func(struct devfreq
> *df,
> /* Set MAX if it's busy enough */
> if (stat->busy_time * 100 >
> stat->total_time * dfso_upthreshold) {
> - *freq = max;
> + *freq = df->max_freq;
> return 0;
> }
>
> /* Set MAX if we do not know the initial frequency */
> if (stat->current_frequency == 0) {
> - *freq = max;
> + *freq = df->max_freq;
> return 0;
> }
>
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 01/11] PM / devfreq: Init user limits from OPP limits, not viceversa
Hi,
On 2018년 05월 26일 05:30, Matthias Kaehlcke wrote:
> Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding
> the devfreq device") introduced the initialization of the user
> limits min/max_freq from the lowest/highest available OPPs. Later
> commit f1d981eaecf8 ("PM / devfreq: Use the available min/max
> frequency") added scaling_min/max_freq, which actually represent
> the frequencies of the lowest/highest available OPP. scaling_min/
> max_freq are initialized with the values from min/max_freq, which
> is totally correct in the context, but a bit awkward to read.
>
> Swap the initialization and assign scaling_min/max_freq with the
> OPP freqs and then the user limts min/max_freq with scaling_min/
> max_freq.
>
> Needless to say that this change is a NOP, intended to improve
> readability.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/devfreq/devfreq.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index fe2af6aa88fc..0057ef5b0a98 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -604,21 +604,21 @@ struct devfreq *devfreq_add_device(struct device *dev,
> mutex_lock(&devfreq->lock);
> }
>
> - devfreq->min_freq = find_available_min_freq(devfreq);
> - if (!devfreq->min_freq) {
> + devfreq->scaling_min_freq = find_available_min_freq(devfreq);
> + if (!devfreq->scaling_min_freq) {
> mutex_unlock(&devfreq->lock);
> err = -EINVAL;
> goto err_dev;
> }
> - devfreq->scaling_min_freq = devfreq->min_freq;
> + devfreq->min_freq = devfreq->scaling_min_freq;
>
> - devfreq->max_freq = find_available_max_freq(devfreq);
> - if (!devfreq->max_freq) {
> + devfreq->scaling_max_freq = find_available_max_freq(devfreq);
> + if (!devfreq->scaling_max_freq) {
> mutex_unlock(&devfreq->lock);
> err = -EINVAL;
> goto err_dev;
> }
> - devfreq->scaling_max_freq = devfreq->max_freq;
> + devfreq->max_freq = devfreq->scaling_max_freq;
>
> dev_set_name(&devfreq->dev, "devfreq%d",
> atomic_inc_return(&devfreq_no));
>
I already replied with my Reviewed-by tag. You are missing my tag.
Again,
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
On Sat, May 26, 2018 at 09:15:05PM -0700, Guenter Roeck wrote: > Good point. Maybe it would be better to limit the warning to SMP systems > instead of (unnecessarily) fixing drivers all over the place ? No. The coherent_dma_mask is the mask used for dma_alloc_coherent and dma_alloc_attrs. It has nothing to do with cache coherent in SMP systems.
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
On Mon, 28 May 2018, Michael Schmitz wrote: > Hi Finn, > > Am 27.05.2018 um 17:49 schrieb Finn Thain: > > On Sun, 27 May 2018, Michael Schmitz wrote: > > > >> That should have fixed the warning already ... > > > > It's still not fixed (hence my "acked-by" for Geunter's patch). > > > > Odd - does link order still matter even though the > arch_setup_dev_archdata() function from the core platform code is > declared as a weak symbol? > > I'll see what I can find out on elgar ... > Any one of the numerous patches/rfcs/suggestions that I sent will avoid the WARN splat. When I said "it's still not fixed", what I meant to say was, "it's still not fixed in mainline and no proposed fix was accepted to the best of my knowledge". -- > Cheers, > > Michael >
Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem
On 27.05.2018 22:35, Florian Fainelli wrote:
Le 05/27/18 à 12:18, Gerhard Wiesinger a écrit :
On 27.05.2018 21:01, Gerhard Wiesinger wrote:
On 24.05.2018 08:22, Gerhard Wiesinger wrote:
On 24.05.2018 07:29, Gerhard Wiesinger wrote:
After some analysis with Florian (thnx) we found out that the
current implementation is broken:
https://patchwork.ozlabs.org/patch/836538/
https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac3ac43fa1d
Florians comment:
c499696e7901bda18385ac723b7bd27c3a4af624 ("net: dsa: b53: Stop using
dev->cpu_port incorrectly") since it would result in no longer setting
the CPU port as tagged for a specific VLAN. Easiest way for you right
now is to just revert it, but this needs some more thoughts for a
proper
upstream change. I will think about it some more.
Can confirm 4.14.18-200.fc26.armv7hl works, 4.15.x should be broken.
# Kernel 4.14.x ok
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/net/dsa/b53?h=v4.14.43
# Kernel 4.15.x should be NOT ok
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/net/dsa/b53?h=v4.15.18
Forgot to mention: What's also strange is that the VLAN ID is very high:
# 4.14.18-300.fc27.armv7hl, iproute-4.15.0-1.fc28.armv7hl
ip -d link show eth0.101 | grep "vlan protocol"
vlan protocol 802.1Q id 3069279796
ip -d link show eth0.102 | grep "vlan protocol"
vlan protocol 802.1Q id 3068673588
On older kernels this looks ok: 4.12.8-200.fc25.armv7hl,
iproute-4.11.0-1.fc25.armv7hl:
ip -d link show eth0.101 | grep "vlan protocol"
vlan protocol 802.1Q id 101
ip -d link show eth0.102 | grep "vlan protocol"
vlan protocol 802.1Q id 102
Ideas?
That is quite likely a kernel/iproute2 issue, if you configured the
switch through bridge vlan to have the ports in VLAN 101 and VLAN 102
and you do indeed see frames entering eth0 with these VLAN IDs, then
clearly the bridge -> switchdev -> dsa -> b53 part is working just fine
and what you are seeing is some for of kernel header/netlink
incompatibility.
Yes, sniffing on eth0 shows the correct VLAN IDs, e.g. 101.
Yes, my guess is that tools are wrong and have random values on 2 calls
in different values (e.g. alsopromiscuity ) , see below
Who can fix it?
BTW: On FC27 same issue with same kernel version, but guess older
iproute version.
Ciao,
Gerhard
ip -d link show eth0.101
13: eth0.101@eth0: mtu 1500 qdisc
noqueue master br0 state UP mode DEFAULT group default qlen 1000
link/ether 02:18:09:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity
3068661300
vlan protocol 802.1Q id 3068661300
bridge_slave state forwarding priority 32 cost 4 hairpin off guard
off root_block off fastleave off learning on flood on port_id 0x8005
port_no 0x5 designa
ted_port 3068661300 designated_cost 3068661300 designated_bridge
8000.66:5d:a2:ab:cd:ef designated_root 8000.66:5d:a2:ab:cd:ef
hold_timer 0.00 message_age_tim
er 0.00 forward_delay_timer 0.00 topology_change_ack 3068661300
config_pending 3068661300 proxy_arp off proxy_arp_wifi off mcast_router
3068661300 mcast_
fast_leave off mcast_flood on vlan_tunnel off addrgenmode eui64
numtxqueues 3068661300 numrxqueues 3068661300 gso_max_size 3068661300
gso_max_segs 3068661300
ip -d link show eth0.101
13: eth0.101@eth0: mtu 1500 qdisc
noqueue master br0 state UP mode DEFAULT group default qlen 1000
link/ether 02:18:09:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity
3068735028
vlan protocol 802.1Q id 3068735028
bridge_slave state forwarding priority 32 cost 4 hairpin off guard
off root_block off fastleave off learning on flood on port_id 0x8005
port_no 0x5 designa
ted_port 3068735028 designated_cost 3068735028 designated_bridge
8000.66:5d:ab:cd:ef designated_root 8000.66:5d:a2:ab:cd:ef hold_timer
0.00 message_age_tim
er 0.00 forward_delay_timer 0.00 topology_change_ack 3068735028
config_pending 3068735028 proxy_arp off proxy_arp_wifi off mcast_router
3068735028 mcast_
fast_leave off mcast_flood on vlan_tunnel off addrgenmode eui64
numtxqueues 3068735028 numrxqueues 3068735028 gso_max_size 3068735028
gso_max_segs 3068735028
RE: [PATCH 08/11] PM / devfreq: Make update_devfreq() public
>Currently update_devfreq() is only visible to devfreq governors outside >of devfreq.c. Make it public to allow drivers that adjust devfreq policies >to cause a re-evaluation of the frequency after a policy change. > >Signed-off-by: Matthias Kaehlcke >--- > drivers/devfreq/governor.h | 3 --- > include/linux/devfreq.h| 8 > 2 files changed, 8 insertions(+), 3 deletions(-) With the requirement from patch 9/11, this commit is reasonable enough. Acked-by: MyungJoo Ham
RE: [PATCH v11 00/26] Speculative page faults
Some regression and improvements is found by LKP-tools(linux kernel performance) on V9 patch series tested on Intel 4s Skylake platform. The regression result is sorted by the metric will-it-scale.per_thread_ops. Branch: Laurent-Dufour/Speculative-page-faults/20180316-151833 (V9 patch series) Commit id: base commit: d55f34411b1b126429a823d06c3124c16283231f head commit: 0355322b3577eeab7669066df42c550a56801110 Benchmark suite: will-it-scale Download link: https://github.com/antonblanchard/will-it-scale/tree/master/tests Metrics: will-it-scale.per_process_ops=processes/nr_cpu will-it-scale.per_thread_ops=threads/nr_cpu test box: lkp-skl-4sp1(nr_cpu=192,memory=768G) THP: enable / disable nr_task: 100% 1. Regressions: a) THP enabled: testcasebasechange head metric page_fault3/ enable THP 10092 -17.5% 8323 will-it-scale.per_thread_ops page_fault2/ enable THP 8300 -17.2% 6869 will-it-scale.per_thread_ops brk1/ enable THP 957.67 -7.6% 885 will-it-scale.per_thread_ops page_fault3/ enable THP172821-5.3%163692 will-it-scale.per_process_ops signal1/ enable THP 9125-3.2% 8834 will-it-scale.per_process_ops b) THP disabled: testcasebasechange head metric page_fault3/ disable THP10107 -19.1% 8180 will-it-scale.per_thread_ops page_fault2/ disable THP 8432 -17.8% 6931 will-it-scale.per_thread_ops context_switch1/ disable THP 215389-6.8%200776 will-it-scale.per_thread_ops brk1/ disable THP 939.67 -6.6% 877.33 will-it-scale.per_thread_ops page_fault3/ disable THP 173145-4.7%165064 will-it-scale.per_process_ops signal1/ disable THP 9162-3.9% 8802 will-it-scale.per_process_ops 2. Improvements: a) THP enabled: testcasebasechange head metric malloc1/ enable THP 66.33+469.8% 383.67 will-it-scale.per_thread_ops writeseek3/ enable THP 2531 +4.5% 2646 will-it-scale.per_thread_ops signal1/ enable THP 989.33 +2.8% 1016 will-it-scale.per_thread_ops b) THP disabled: testcasebasechange head metric malloc1/ disable THP 90.33+417.3% 467.33 will-it-scale.per_thread_ops read2/ disable THP 58934+39.2% 82060 will-it-scale.per_thread_ops page_fault1/ disable THP8607+36.4% 11736 will-it-scale.per_thread_ops read1/ disable THP314063+12.7%353934 will-it-scale.per_thread_ops writeseek3/ disable THP 2452+12.5% 2759 will-it-scale.per_thread_ops signal1/ disable THP 971.33 +5.5% 1024 will-it-scale.per_thread_ops Notes: for above values in column "change", the higher value means that the related testcase result on head commit is better than that on base commit for this benchmark. Best regards Haiyan Song From: owner-linux...@kvack.org [owner-linux...@kvack.org] on behalf of Laurent Dufour [lduf...@linux.vnet.ibm.com] Sent: Thursday, May 17, 2018 7:06 PM To: a...@linux-foundation.org; mho...@kernel.org; pet...@infradead.org; kir...@shutemov.name; a...@linux.intel.com; d...@stgolabs.net; j...@suse.cz; Matthew Wilcox; khand...@linux.vnet.ibm.com; aneesh.ku...@linux.vnet.ibm.com; b...@kernel.crashing.org; m...@ellerman.id.au; pau...@samba.org; Thomas Gleixner; Ingo Molnar; h...@zytor.com; Will Deacon; Sergey Senozhatsky; sergey.senozhatsky.w...@gmail.com; Andrea Arcangeli; Alexei Starovoitov; Wang, Kemi; Daniel Jordan; David Rientjes; Jerome Glisse; Ganesh Mahendran; Minchan Kim; Punit Agrawal; vinayak menon; Yang Shi Cc: linux-kernel@vger.kernel.org; linux...@kvack.org; ha...@linux.vnet.ibm.com; npig...@gmail.com; bsinghar...@gmail.com; paul...@linux.vnet.ibm.com; Tim Chen; linuxppc-...@lists.ozlabs.org; x...@kernel.org Subject: [PATCH v11 00/26] Speculative page faults This is a port on kernel 4.17 of the work done by Peter Zijlstra to handle page fault without holding the mm semaphore [1]. The idea is to try to handle user space page faults without holding the mmap_sem. This should allow better concurrency for massively threaded process since the page fault handler will not wait for other threads memory layout change to be done, assuming that this change is done in another part of the process's memory space. This type page fault is named speculative page fa
RE: [PATCH v2] dcdbas: Add support for WSMT ACPI table
> -Original Message-
> From: Warzecha, Douglas
> Sent: Friday, May 25, 2018 2:02 PM
> To: Stuart Hayes
> Cc: Limonciello, Mario; Dominguez, Jared; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH v2] dcdbas: Add support for WSMT ACPI table
>
>
> On 05/16/2018 9:06 AM, Stuart Hayes wrote:
> > If the WSMT ACPI table is present and indicates that a fixed communication
> > buffer should be used, use the firmware-specified buffer instead of
> > allocating a buffer in memory for communications between the dcdbas driver
> > and firmare.
> >
> > Signed-off-by: Stuart Hayes
> > ---
> > v2 Bumped driver version to 5.6.0-3.3
> >
> >
> > drivers/firmware/Kconfig | 2 +-
> > drivers/firmware/dcdbas.c | 102
> > +++---
> > drivers/firmware/dcdbas.h | 11 +
> > 3 files changed, 109 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index
> > b7c748248e53..a2bd6092bfa1 100644
> > --- a/drivers/firmware/Kconfig
> > +++ b/drivers/firmware/Kconfig
> > @@ -125,7 +125,7 @@ config DELL_RBU
> >
> > config DCDBAS
> > tristate "Dell Systems Management Base Driver"
> > - depends on X86
> > + depends on X86 && ACPI
> > help
> > The Dell Systems Management Base Driver provides a sysfs
> > interface
> > for systems management software to perform System
> > Management diff --git a/drivers/firmware/dcdbas.c
> > b/drivers/firmware/dcdbas.c index 0bdea60c65dd..1699cfdcefe4 100644
> > --- a/drivers/firmware/dcdbas.c
> > +++ b/drivers/firmware/dcdbas.c
> > @@ -36,12 +36,13 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "dcdbas.h"
> >
> > #define DRIVER_NAME"dcdbas"
> > -#define DRIVER_VERSION "5.6.0-3.2"
> > +#define DRIVER_VERSION "5.6.0-3.3"
> > #define DRIVER_DESCRIPTION "Dell Systems Management Base Driver"
> >
> > static struct platform_device *dcdbas_pdev; @@ -49,19 +50,23 @@ static
> > struct platform_device *dcdbas_pdev; static u8 *smi_data_buf; static
> > dma_addr_t smi_data_buf_handle; static unsigned long smi_data_buf_size;
> > +static unsigned long max_smi_data_buf_size = MAX_SMI_DATA_BUF_SIZE;
> > static u32 smi_data_buf_phys_addr;
> > static DEFINE_MUTEX(smi_data_lock);
> > +static u8 *eps_buffer;
> >
> > static unsigned int host_control_action; static unsigned int
> > host_control_smi_type; static unsigned int host_control_on_shutdown;
> >
> > +static bool wsmt_enabled;
> > +
> > /**
> > * smi_data_buf_free: free SMI data buffer
> > */
> > static void smi_data_buf_free(void)
> > {
> > - if (!smi_data_buf)
> > + if (!smi_data_buf || wsmt_enabled)
> > return;
> >
> > dev_dbg(&dcdbas_pdev->dev, "%s: phys: %x size: %lu\n", @@ -86,7
> > +91,7 @@ static int smi_data_buf_realloc(unsigned long size)
> > if (smi_data_buf_size >= size)
> > return 0;
> >
> > - if (size > MAX_SMI_DATA_BUF_SIZE)
> > + if (size > max_smi_data_buf_size)
> > return -EINVAL;
> >
> > /* new buffer is needed */
> > @@ -169,7 +174,7 @@ static ssize_t smi_data_write(struct file *filp, struct
> > kobject *kobj, {
> > ssize_t ret;
> >
> > - if ((pos + count) > MAX_SMI_DATA_BUF_SIZE)
> > + if ((pos + count) > max_smi_data_buf_size)
> > return -EINVAL;
> >
> > mutex_lock(&smi_data_lock);
> > @@ -323,7 +328,8 @@ static ssize_t smi_request_store(struct device *dev,
> > break;
> > case 1:
> > /* Calling Interface SMI */
> > - smi_cmd->ebx = (u32) virt_to_phys(smi_cmd-
> > >command_buffer);
> > + smi_cmd->ebx = smi_data_buf_phys_addr
> > + + offsetof(struct smi_cmd,
> > command_buffer);
> > ret = dcdbas_smi_request(smi_cmd);
> > if (!ret)
> > ret = count;
> > @@ -482,6 +488,85 @@ static void dcdbas_host_control(void)
> > }
> > }
> >
> > +/* WSMT */
> > +
> > +static u8 checksum(u8 *buffer, u8 length) {
> > + u8 sum = 0;
> > + u8 *end = buffer + length;
> > +
> > + while (buffer < end)
> > + sum = (u8)(sum + *(buffer++));
> > + return sum;
> > +}
> > +
> > +static inline struct smm_eps_table *check_eps_table(u8 *addr) {
> > + struct smm_eps_table *eps = (struct smm_eps_table *)addr;
> > +
> > + if (strncmp(SMM_EPS_SIG, eps->smm_comm_buff_anchor, 4) != 0)
> > + return NULL;
> > +
> > + if (checksum(addr, eps->length) != 0)
> > + return NULL;
> > +
> > + return eps;
> > +}
> > +
> > +static int dcdbas_check_wsmt(void)
> > +{
> > + struct acpi_table_wsmt *wsmt = NULL;
> > + struct smm_eps_table *eps = NULL;
> > + u8 *addr;
> > +
> > + acpi_get_table(ACPI_SIG_WSMT, 0, (struct acpi_table_header
> > **)&wsmt);
> > + if (!wsmt)
> > + return 0;
> > +
> > + /* Check if WSMT ACPI table shows that protection is enabled */
> > + if (!(wsmt->protection_flags &
> > ACPI_WSM
Re: [PATCH 3/3] s390:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
On Mon, May 28, 2018 at 11:33:55AM +0800, nixiaoming wrote: > Signed-off-by: nixiaoming Please do not submit patches without any changelog text. I do not accept such patches, but other maintainers might be easier... greg k-h
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
Hi Finn, Am 27.05.2018 um 17:49 schrieb Finn Thain: > On Sun, 27 May 2018, Michael Schmitz wrote: > >> That should have fixed the warning already ... > > It's still not fixed (hence my "acked-by" for Geunter's patch). > Odd - does link order still matter even though the arch_setup_dev_archdata() function from the core platform code is declared as a weak symbol? I'll see what I can find out on elgar ... Cheers, Michael
RE: [PATCH 07/11] PM / devfreg: Add support policy notifiers
>Policy notifiers are called before a frequency change and may narrow >the min/max frequency range in devfreq_policy, which is used to adjust >the target frequency if it is beyond this range. > >Also add a few helpers: > - devfreq_verify_within_[dev_]limits() >- should be used by the notifiers for policy adjustments. > - dev_to_devfreq() >- lookup a devfreq strict from a device pointer > >Signed-off-by: Matthias Kaehlcke >--- > drivers/devfreq/devfreq.c | 47 +--- > include/linux/devfreq.h | 66 +++ > 2 files changed, 102 insertions(+), 11 deletions(-) Hello Matthias, Why should we have yet another notifier from an instance of devfreq? Wouldn't it better to let the current notifier (transition notifier) handle new events as well by adding possible event states to it? Anyway, is this the reason why you've separated some data of devfreq into "policy" struct? (I was wondering why while reading commit 6/11). Cheers MyungJoo
Re: [PATCH v3 1/2] rtmutex: allow specifying a subclass for nested locking
On Thu, May 24, 2018 at 03:52:39PM +0200, Peter Rosin wrote:
> Needed for annotating rt_mutex locks.
>
> Signed-off-by: Peter Rosin
> ---
> include/linux/rtmutex.h | 7 +++
> kernel/locking/rtmutex.c | 29 +
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h
> index 1b92a28dd672..6fd615a0eea9 100644
> --- a/include/linux/rtmutex.h
> +++ b/include/linux/rtmutex.h
> @@ -106,7 +106,14 @@ static inline int rt_mutex_is_locked(struct rt_mutex
> *lock)
> extern void __rt_mutex_init(struct rt_mutex *lock, const char *name, struct
> lock_class_key *key);
> extern void rt_mutex_destroy(struct rt_mutex *lock);
>
> +#ifdef CONFIG_DEBUG_LOCK_ALLOC
> +extern void rt_mutex_lock_nested(struct rt_mutex *lock, unsigned int
> subclass);
> +#define rt_mutex_lock(lock) rt_mutex_lock_nested(lock, 0)
> +#else
> extern void rt_mutex_lock(struct rt_mutex *lock);
> +#define rt_mutex_lock_nested(lock, subclass) rt_mutex_lock(lock)
> +#endif
> +
> extern int rt_mutex_lock_interruptible(struct rt_mutex *lock);
> extern int rt_mutex_timed_lock(struct rt_mutex *lock,
> struct hrtimer_sleeper *timeout);
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
:
> }
>
> +static inline void __rt_mutex_lock(struct rt_mutex *lock, unsigned int
> subclass)
> +{
> + might_sleep();
> +
> + mutex_acquire(&lock->dep_map, subclass, 0, _RET_IP_);
> + rt_mutex_fastlock(lock, TASK_UNINTERRUPTIBLE, rt_mutex_slowlock);
> +}
> +
> +#ifdef CONFIG_DEBUG_LOCK_ALLOC
> +/**
> + * rt_mutex_lock_nested - lock a rt_mutex
This ifdef seems consistent with other nested locking primitives, but its
kind of confusing.
The Kconfig.debug for DEBUG_LOCK_ALLOC says:
config DEBUG_LOCK_ALLOC
bool "Lock debugging: detect incorrect freeing of live locks"
[...]
help
This feature will check whether any held lock (spinlock, rwlock,
mutex or rwsem) is incorrectly freed by the kernel, via any of the
memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
vfree(), etc.), whether a live lock is incorrectly reinitialized via
spin_lock_init()/mutex_init()/etc., or whether there is any lock
held during task exit.
Shouldn't this ideally be ifdef'd under PROVE_LOCKING for this and other
locking primitives? Any idea what's the reason? I know PROVE_LOCKING selects
DEBUG_LOCK_ALLOC but still..
thanks!
- Joel
Re: [PATCH v2] Revert "alx: remove WoL support"
Hi all, Just inform you a news reported by a user who confirmed the wake up issue can't be reproduce by the new kernel. https://bugzilla.kernel.org/show_bug.cgi?id=61651#c126 Guillaume de Jabrun 2018-05-27 15:12:54 UTC I am using this patch for a long time. I was experiencing the "wake up twice" bug, but with recent kernel version, I don't have this issue anymore. I can't tell which version actually fix the bug (I don't remember..). Best regards, AceLan Kao. 2018-05-21 11:18 GMT+08:00 David Miller : > From: AceLan Kao > Date: Mon, 21 May 2018 11:14:00 +0800 > >> We are willing to fix the issue, but we don't have a machine to >> reproduce it, and the WoL feature has been removed 5 years ago, it's >> hard to find those buggy machines. > > Have you bothered to ask the person who did the revert? > >> WoL is a feature that is only used by a very small group of people, >> and the wake up issue looks like only happens on some >> platforms. Which means only small part of the group of people are >> affected. > > One of those people was the wireless networking stack maintainer. > >> So, it's not a serious issue worth to remove it from alx driver. > > I disagree. > > You must fix the regression solved by the revert, before adding > WoL support back to the driver. > > I'm not going to say this again. > > Thank you. >
RE: [PATCH 05/11] PM / devfreq: governors: Return device frequency limits instead of user limits
>The performance, powersave and simpleondemand governors can return >df->min/max_freq, which are the user defined frequency limits. >update_devfreq() already takes care of adjusting the target frequency >with the user limits if necessary, therefore we can return >df->scaling_min/max_freq instead, which is the min/max frequency >supported by the device at a given time (depending on the >enabled/disabled OPPs) > >Signed-off-by: Matthias Kaehlcke >--- > drivers/devfreq/governor_performance.c| 2 +- > drivers/devfreq/governor_powersave.c | 2 +- > drivers/devfreq/governor_simpleondemand.c | 6 +++--- > 3 files changed, 5 insertions(+), 5 deletions(-) > Actually, even scaling_max_freq and scaling_min_freq are covered centerally at devfreq.c:update_devfreq(); Wouldn't it be sufficient to return UINT_MAX for performance and return UINT_MIN (0) for powersave, if the purpose is to remove redundancy? In the same sense, we may return UINT_MAX for freq-increasing case for simpleondemand as well, because they are filtered centrally anyway. (This commit might be better merged to 4/11 in that case as well.) Cheers, MyungJoo
Re: [PATCH v14 1/2] cpufreq: Add Kryo CPU scaling driver
On 25-05-18, 15:41, Ilia Lin wrote: > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors, > the CPU frequency subset and voltage value of each OPP varies > based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables > defines the voltage and frequency value based on the msm-id in SMEM > and speedbin blown in the efuse combination. > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC > to provide the OPP framework with required information. > This is used to determine the voltage and frequency value for each OPP of > operating-points-v2 table when it is parsed by the OPP framework. > > Signed-off-by: Ilia Lin > --- > MAINTAINERS | 7 ++ > drivers/cpufreq/Kconfig.arm | 10 ++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/cpufreq-dt-platdev.c | 3 + > drivers/cpufreq/qcom-cpufreq-kryo.c | 212 > +++ > 5 files changed, 233 insertions(+) > create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c Acked-by: Viresh Kumar -- viresh
RE: [PATCH 04/11] PM / devfreq: Remove redundant frequency adjustment from governors
> The userspace and simpleondemand governor determine a target frequency and > then adjust it according to the df->min/max_freq limits that might have > been set by user space. This adjustment is redundant, it is done in > update_devfreq() for any governor, right after returning from > governor->get_target_freq(). > > Signed-off-by: Matthias Kaehlcke > --- > drivers/devfreq/governor_simpleondemand.c | 5 - > drivers/devfreq/governor_userspace.c | 16 > 2 files changed, 4 insertions(+), 17 deletions(-) > Yes, indeed. Governors are no longer required to be aware of min/max freq. Acked-by: MyungJoo Ham
RE: [PATCH 03/11] PM / devfreq: Remove check for df->max_freq == 0 from governors
>Commit "PM / devfreq: Fix handling of min/max_freq == 0" ensures that >df->max_freq is not 0, remove unnecessary checks. > >Signed-off-by: Matthias Kaehlcke >--- > drivers/devfreq/governor_performance.c| 5 + > drivers/devfreq/governor_simpleondemand.c | 7 +++ > 2 files changed, 4 insertions(+), 8 deletions(-) > >diff --git a/drivers/devfreq/governor_performance.c >b/drivers/devfreq/governor_performance.c >index 4d23ecfbd948..1c990cb45098 100644 > Thanks! Acked-by: MyungJoo Ham
Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix
On Mon, 2018-05-28 at 12:13 +0800, Ian Kent wrote: > On Fri, 2018-05-25 at 20:48 -0700, Andrew Morton wrote: > > On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot wrote: > > > > > Hi Andrey, > > > > > > I love your patch! Yet something to improve: > > > > > > [auto build test ERROR on mmotm/master] > > > [cannot apply to v4.17-rc6] > > > [if your patch is applied to the wrong git tree, please drop us a note to > > > help improve the system] > > > > > > url:https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan- > > > do > > > nt-vfree-nonexistent-vm_area-fix/20180526-093255 > > > base: git://git.cmpxchg.org/linux-mmotm.git master > > > config: sparc-allyesconfig (attached as .config) > > > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > > > reproduce: > > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin > > > /m > > > ake.cross -O ~/bin/make.cross > > > chmod +x ~/bin/make.cross > > > # save the attached .config to linux build tree > > > make.cross ARCH=sparc > > > > > > All errors (new ones prefixed by >>): > > > > > >fs/autofs/inode.o: In function `autofs_new_ino': > > >inode.c:(.text+0x220): multiple definition of `autofs_new_ino' > > >fs/autofs/inode.o:inode.c:(.text+0x220): first defined here > > >fs/autofs/inode.o: In function `autofs_clean_ino': > > >inode.c:(.text+0x280): multiple definition of `autofs_clean_ino' > > >fs/autofs/inode.o:inode.c:(.text+0x280): first defined here > > > > There's bot breakage here - clearly that patch didn't cause this error. > > > > Ian, this autofs glitch may still not be fixed. > > Yes, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch should have > fixed that. > > I tied a bunch of .config combinations and I was unable to find any that > lead to both CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS being defined. Oh, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch was sent as a follow up patch which means it's still possible to have both CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS set between autofs-create-autofs-Kconfig-and-Makefile.patch and the above patch. Perhaps all that's needed is to fold the follow up patch into autofs-create-autofs-Kconfig-and-Makefile.patch to close that possibility. I'll check that can be done without problem. > > I must be missing something else, I'll investigate. And I'll check if there's anything else I'm missing. Sorry for the inconvenience. > > Ian
Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix
On Fri, 2018-05-25 at 20:48 -0700, Andrew Morton wrote: > On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot wrote: > > > Hi Andrey, > > > > I love your patch! Yet something to improve: > > > > [auto build test ERROR on mmotm/master] > > [cannot apply to v4.17-rc6] > > [if your patch is applied to the wrong git tree, please drop us a note to > > help improve the system] > > > > url:https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasan-do > > nt-vfree-nonexistent-vm_area-fix/20180526-093255 > > base: git://git.cmpxchg.org/linux-mmotm.git master > > config: sparc-allyesconfig (attached as .config) > > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > > reproduce: > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/m > > ake.cross -O ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # save the attached .config to linux build tree > > make.cross ARCH=sparc > > > > All errors (new ones prefixed by >>): > > > >fs/autofs/inode.o: In function `autofs_new_ino': > >inode.c:(.text+0x220): multiple definition of `autofs_new_ino' > >fs/autofs/inode.o:inode.c:(.text+0x220): first defined here > >fs/autofs/inode.o: In function `autofs_clean_ino': > >inode.c:(.text+0x280): multiple definition of `autofs_clean_ino' > >fs/autofs/inode.o:inode.c:(.text+0x280): first defined here > > There's bot breakage here - clearly that patch didn't cause this error. > > Ian, this autofs glitch may still not be fixed. Yes, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch should have fixed that. I tied a bunch of .config combinations and I was unable to find any that lead to both CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS being defined. I must be missing something else, I'll investigate. Ian
RE: [PATCH 02/11] PM / devfreq: Fix handling of min/max_freq == 0
> Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the
> devfreq device") initializes df->min/max_freq with the min/max OPP when
> the device is added. Later commit f1d981eaecf8 ("PM / devfreq: Use the
> available min/max frequency") adds df->scaling_min/max_freq and the
> following to the frequency adjustment code:
>
> max_freq = MIN(devfreq->scaling_max_freq, devfreq->max_freq);
>
> With the current handling of min/max_freq this is incorrect:
>
> Even though df->max_freq is now initialized to a value != 0 user space
> can still set it to 0, in this case max_freq would be 0 instead of
> df->scaling_max_freq as intended. In consequence the frequency adjustment
> is not performed:
>
> if (max_freq && freq > max_freq) {
> freq = max_freq;
>
> To fix this set df->min/max freq to the min/max OPP in max/max_freq_store,
> when the user passes a value of 0. This also prevents df->max_freq from
> being set below the min OPP when df->min_freq is 0, and similar for
> min_freq. Since it is now guaranteed that df->min/max_freq can't be 0 the
> checks for this case can be removed.
>
> Fixes: f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency")
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/devfreq/devfreq.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
Thanks a lot! Nice Catch.
Acked-by: MyungJoo Ham
Cheers,
MyungJoo.
[PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
Signed-off-by: nixiaoming
---
arch/arm64/mm/mmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9..849f326 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -491,6 +491,7 @@ static void __init map_mem(pgd_t *pgdp)
#endif
}
+#ifdef CONFIG_STRICT_KERNEL_RWX
void mark_rodata_ro(void)
{
unsigned long section_size;
@@ -505,6 +506,7 @@ void mark_rodata_ro(void)
debug_checkwx();
}
+#endif
static void __init map_kernel_segment(pgd_t *pgdp, void *va_start, void
*va_end,
pgprot_t prot, struct vm_struct *vma,
--
2.10.1
[PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
Signed-off-by: nixiaoming
---
arch/x86/mm/init_32.c | 2 ++
arch/x86/mm/init_64.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index c893c6a..121c567 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -920,6 +920,7 @@ static void mark_nxdata_nx(void)
set_pages_nx(virt_to_page(start), size >> PAGE_SHIFT);
}
+#ifdef CONFIG_STRICT_KERNEL_RWX
void mark_rodata_ro(void)
{
unsigned long start = PFN_ALIGN(_text);
@@ -957,3 +958,4 @@ void mark_rodata_ro(void)
if (__supported_pte_mask & _PAGE_NX)
debug_checkwx();
}
+#endif /*end of CONFIG_STRICT_KERNEL_RWX*/
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 0a40060..1b7a1a7 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1245,6 +1245,7 @@ void set_kernel_text_ro(void)
set_memory_ro(start, (end - start) >> PAGE_SHIFT);
}
+#ifdef CONFIG_STRICT_KERNEL_RWX
void mark_rodata_ro(void)
{
unsigned long start = PFN_ALIGN(_text);
@@ -1298,6 +1299,7 @@ void mark_rodata_ro(void)
*/
pti_clone_kernel_text();
}
+#endif
int kern_addr_valid(unsigned long addr)
{
--
2.10.1
[PATCH 3/3] s390:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
Signed-off-by: nixiaoming
---
arch/s390/mm/init.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index 3fa3e53..a96fc3f 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -116,6 +116,7 @@ void __init paging_init(void)
free_area_init_nodes(max_zone_pfns);
}
+#ifdef CONFIG_STRICT_KERNEL_RWX
void mark_rodata_ro(void)
{
unsigned long size = __end_ro_after_init - __start_ro_after_init;
@@ -123,6 +124,7 @@ void mark_rodata_ro(void)
set_memory_ro((unsigned long)__start_ro_after_init, size >> PAGE_SHIFT);
pr_info("Write protected read-only-after-init data: %luk\n", size >>
10);
}
+#endif
void __init mem_init(void)
{
--
2.10.1
Re: [PATCH] perf test 39 (Session topology) dumps core on s390
Hi Thomas,
On 05/24/2018 07:26 PM, Thomas Richter wrote:
> @@ -95,7 +98,7 @@ int test__session_topology(struct test *test
> __maybe_unused, int subtest __maybe
> {
> char path[PATH_MAX];
> struct cpu_map *map;
> - int ret = -1;
> + int ret;
This is failing for me:
tests/topology.c: In function ‘test__session_topology’:
tests/topology.c:101:6: error: ‘ret’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
int ret;
^
cc1: all warnings being treated as errors
CC util/intlist.o
mv: cannot stat 'tests/.topology.o.tmp': No such file or directory
/home/ravi/Workspace/linux/tools/build/Makefile.build:96: recipe for target
'tests/topology.o' failed
make[4]: *** [tests/topology.o] Error 1
make[4]: *** Waiting for unfinished jobs
Thanks,
Ravi
[v2] ASoC: AMD: make channel 1 dma as circular
channel 1: SYSMEM<->ACP
channel 2: ACP<->I2S
Instead of waiting on period interrupt of ch 2 and then starting
dma on ch1, we make ch1 dma as circular.
This removes dependency of period granularity on hw pointer.
Signed-off-by: Akshu Agrawal
Reviewed-by: Daniel Kurtz
Tested-by: Daniel Kurtz
---
v2: Fixed kbuild error
sound/soc/amd/acp-pcm-dma.c | 74 ++---
1 file changed, 10 insertions(+), 64 deletions(-)
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index ac32dea..7720384 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -337,8 +337,7 @@ static void config_acp_dma(void __iomem *acp_mmio,
}
/* Start a given DMA channel transfer */
-static void acp_dma_start(void __iomem *acp_mmio,
- u16 ch_num, bool is_circular)
+static void acp_dma_start(void __iomem *acp_mmio, u16 ch_num)
{
u32 dma_ctrl;
@@ -369,11 +368,8 @@ static void acp_dma_start(void __iomem *acp_mmio,
break;
}
- /* enable for ACP SRAM to/from I2S DMA channel */
- if (is_circular == true)
- dma_ctrl |= ACP_DMA_CNTL_0__Circular_DMA_En_MASK;
- else
- dma_ctrl &= ~ACP_DMA_CNTL_0__Circular_DMA_En_MASK;
+ /* circular for both DMA channel */
+ dma_ctrl |= ACP_DMA_CNTL_0__Circular_DMA_En_MASK;
acp_reg_write(dma_ctrl, acp_mmio, mmACP_DMA_CNTL_0 + ch_num);
}
@@ -617,7 +613,6 @@ static int acp_deinit(void __iomem *acp_mmio)
/* ACP DMA irq handler routine for playback, capture usecases */
static irqreturn_t dma_irq_handler(int irq, void *arg)
{
- u16 dscr_idx;
u32 intr_flag, ext_intr_status;
struct audio_drv_data *irq_data;
void __iomem *acp_mmio;
@@ -634,33 +629,13 @@ static irqreturn_t dma_irq_handler(int irq, void *arg)
if ((intr_flag & BIT(ACP_TO_I2S_DMA_CH_NUM)) != 0) {
valid_irq = true;
- if (acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_13) ==
- PLAYBACK_START_DMA_DESCR_CH13)
- dscr_idx = PLAYBACK_END_DMA_DESCR_CH12;
- else
- dscr_idx = PLAYBACK_START_DMA_DESCR_CH12;
- config_acp_dma_channel(acp_mmio, SYSRAM_TO_ACP_CH_NUM, dscr_idx,
- 1, 0);
- acp_dma_start(acp_mmio, SYSRAM_TO_ACP_CH_NUM, false);
-
snd_pcm_period_elapsed(irq_data->play_i2ssp_stream);
-
acp_reg_write((intr_flag & BIT(ACP_TO_I2S_DMA_CH_NUM)) << 16,
acp_mmio, mmACP_EXTERNAL_INTR_STAT);
}
if ((intr_flag & BIT(ACP_TO_I2S_DMA_BT_INSTANCE_CH_NUM)) != 0) {
valid_irq = true;
- if (acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_9) ==
- PLAYBACK_START_DMA_DESCR_CH9)
- dscr_idx = PLAYBACK_END_DMA_DESCR_CH8;
- else
- dscr_idx = PLAYBACK_START_DMA_DESCR_CH8;
- config_acp_dma_channel(acp_mmio,
- SYSRAM_TO_ACP_BT_INSTANCE_CH_NUM,
- dscr_idx, 1, 0);
- acp_dma_start(acp_mmio, SYSRAM_TO_ACP_BT_INSTANCE_CH_NUM,
- false);
snd_pcm_period_elapsed(irq_data->play_i2sbt_stream);
acp_reg_write((intr_flag &
BIT(ACP_TO_I2S_DMA_BT_INSTANCE_CH_NUM)) << 16,
@@ -669,38 +644,20 @@ static irqreturn_t dma_irq_handler(int irq, void *arg)
if ((intr_flag & BIT(I2S_TO_ACP_DMA_CH_NUM)) != 0) {
valid_irq = true;
- if (acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_15) ==
- CAPTURE_START_DMA_DESCR_CH15)
- dscr_idx = CAPTURE_END_DMA_DESCR_CH14;
- else
- dscr_idx = CAPTURE_START_DMA_DESCR_CH14;
- config_acp_dma_channel(acp_mmio, ACP_TO_SYSRAM_CH_NUM, dscr_idx,
- 1, 0);
- acp_dma_start(acp_mmio, ACP_TO_SYSRAM_CH_NUM, false);
-
+ snd_pcm_period_elapsed(irq_data->capture_i2ssp_stream);
acp_reg_write((intr_flag & BIT(I2S_TO_ACP_DMA_CH_NUM)) << 16,
acp_mmio, mmACP_EXTERNAL_INTR_STAT);
}
if ((intr_flag & BIT(ACP_TO_SYSRAM_CH_NUM)) != 0) {
valid_irq = true;
- snd_pcm_period_elapsed(irq_data->capture_i2ssp_stream);
acp_reg_write((intr_flag & BIT(ACP_TO_SYSRAM_CH_NUM)) << 16,
acp_mmio, mmACP_EXTERNAL_INTR_STAT);
}
if ((intr_flag & BIT(I2S_TO_ACP_DMA_BT_INSTANCE_CH_NUM)) != 0) {
valid_irq = true;
- if (acp_reg_read(acp_mmio, mmACP_DMA_CUR_DSCR_11) ==
- CAPTURE_START_DMA_DESCR_CH11)
- dscr_idx = CAP
Re: [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip
On 2018-05-24 8:18 PM, Heiko Stuebner wrote:
Hi Levin,
Am Donnerstag, 24. Mai 2018, 03:59:36 CEST schrieb Levin Du:
Hi all, I'd like to quote reply of Robin Murphy at
http://lists.infradead.org/pipermail/linux-rockchip/2018-May/020619.html
I would suggest s/pin number/bit number in the associated GRF register/
here. At least in this RK3328 case there's only one pin, which isn't
numbered, and if you naively considered it pin 0 of this 'bank' you'd
already have the wrong number. Since we're dealing with the "random
SoC-specific controls" region of the GRF as opposed to the
relatively-consistent and organised pinmux parts, I don't think we
should rely on any assumptions about how things are laid out.
I was initially going to suggest a more specific compatible string as
well, but on reflection I think the generic "rockchip,gpio-syscon" for
basic "flip this single GRF bit" functionality actually is the right way
to go. In the specific RK3328 GPIO_MUTE case, there look to be 4 bits in
total related to this pin - the enable, value, and some pull controls
(which I assume apply when the output is disabled) - if at some point in
future we *did* want to start explicitly controlling the rest of them
too, then would be a good time to define a separate
"rockchip,rk3328-gpio-mute" binding (and probably a dedicated driver)
for that specialised functionality, independently of this basic one.
Shall we go the generic "rockchip,gpio-syscon" way, or the specific
"rockchip,rk3328-gpio-mute" way? I prefer the former one.
The property of "gpio,syscon-dev" in gpio-syscon driver should be
documented.
Since the gpio controller is defined in the dtsi file, which inevitably
contains voodoo
register addresses. But at the board level dts file, there won't be more
register
addresses.
Past experience shows that the GRF is not really suitable for
generalization, as it's more of a dumping ground where chip designers
can put everything that's left over. This is especially true for
GRF_SOC_CONx registers, that really only contain pretty random bits.
So personally, I'd really prefer soc-specific compatibles as everywhere
else, instead of trying to push stuff into the devicetree that won't hold
up on future socs.
On 2018-05-24 3:53 AM, Rob Herring wrote:
On Wed, May 23, 2018 at 10:12 AM, Heiko Stübner wrote:
Hi Rob, Levin,
sorry for being late to the party.
Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring:
On Tue, May 22, 2018 at 9:02 PM, Levin Du wrote:
On 2018-05-23 2:02 AM, Rob Herring wrote:
On Fri, May 18, 2018 at 11:52:05AM +0800, d...@t-chip.com.cn wrote:
From: Levin Du
Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
which do not belong to the general pinctrl.
Adding gpio-syscon support makes controlling regulator or
LED using these special pins very easy by reusing existing
drivers, such as gpio-regulator and led-gpio.
Signed-off-by: Levin Du
---
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc
Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
.../bindings/gpio/rockchip,gpio-syscon.txt | 41
++
drivers/gpio/gpio-syscon.c | 30
2 files changed, 71 insertions(+)
create mode 100644
Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
diff --git
a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
new file mode 100644
index 000..b1b2a67
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
@@ -0,0 +1,41 @@
+* Rockchip GPIO support for GRF_SOC_CON registers
+
+Required properties:
+- compatible: Should contain "rockchip,gpio-syscon".
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity:
+0 = Active high,
+1 = Active low.
There's no need for this child node. Just make the parent node a gpio
controller.
Rob
Hi Rob, it is not clear to me. Do you suggest that the grf node should be
a
gpio controller,
like below?
+grf: syscon at ff10 {
+compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf",
"syscon", "simple-mfd";
Yes, but drop "rockchip,gpio-syscon" and "simple-mfd".
I would disagree quite a bit here. The grf are the "general register files",
a bunch of registers used for quite a lot of things, and so it seems
among other users, also a gpio-controller for some more random pins
not controlled through the regular gpio controllers.
For a more fully stocked grf, please see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338
So the gpio controller should definitly als
Re: [REGRESSION] (>= v4.12) IO w/dmcrypt causing audio underruns
On Thu, Jan 25, 2018 at 12:33:21AM -0800, vcap...@pengaru.com wrote: > On Fri, Jan 19, 2018 at 11:57:32AM +0100, Enric Balletbo Serra wrote: > > Hi Vito, > > > > 2018-01-17 23:48 GMT+01:00 : > > > On Mon, Dec 18, 2017 at 10:25:33AM +0100, Enric Balletbo Serra wrote: > > >> Hi Vito, > > >> > > >> 2017-12-01 22:33 GMT+01:00 : > > >> > On Wed, Nov 29, 2017 at 10:39:19AM -0800, vcap...@pengaru.com wrote: > > >> >> Hello, > > >> >> > > >> >> Recently I noticed substantial audio dropouts when listening to MP3s > > >> >> in > > >> >> `cmus` while doing big and churny `git checkout` commands in my linux > > >> >> git > > >> >> tree. > > >> >> > > >> >> It's not something I've done much of over the last couple months so I > > >> >> hadn't noticed until yesterday, but didn't remember this being a > > >> >> problem in > > >> >> recent history. > > >> >> > > >> >> As there's quite an accumulation of similarly configured and built > > >> >> kernels > > >> >> in my grub menu, it was trivial to determine approximately when this > > >> >> began: > > >> >> > > >> >> 4.11.0: no dropouts > > >> >> 4.12.0-rc7: dropouts > > >> >> 4.14.0-rc6: dropouts (seem more substantial as well, didn't > > >> >> investigate) > > >> >> > > >> >> Watching top while this is going on in the various kernel versions, > > >> >> it's > > >> >> apparent that the kworker behavior changed. Both the priority and > > >> >> quantity > > >> >> of running kworker threads is elevated in kernels experiencing > > >> >> dropouts. > > >> >> > > >> >> Searching through the commit history for v4.11..v4.12 uncovered: > > >> >> > > >> >> commit a1b89132dc4f61071bdeaab92ea958e0953380a1 > > >> >> Author: Tim Murray > > >> >> Date: Fri Apr 21 11:11:36 2017 +0200 > > >> >> > > >> >> dm crypt: use WQ_HIGHPRI for the IO and crypt workqueues > > >> >> > > >> >> Running dm-crypt with workqueues at the standard priority results > > >> >> in IO > > >> >> competing for CPU time with standard user apps, which can lead to > > >> >> pipeline bubbles and seriously degraded performance. Move to > > >> >> using > > >> >> WQ_HIGHPRI workqueues to protect against that. > > >> >> > > >> >> Signed-off-by: Tim Murray > > >> >> Signed-off-by: Enric Balletbo i Serra > > >> >> > > >> >> Signed-off-by: Mike Snitzer > > >> >> > > >> >> --- > > >> >> > > >> >> Reverting a1b8913 from 4.14.0-rc6, my current kernel, eliminates the > > >> >> problem completely. > > >> >> > > >> >> Looking at the diff in that commit, it looks like the commit message > > >> >> isn't > > >> >> even accurate; not only is the priority of the dmcrypt workqueues > > >> >> being > > >> >> changed - they're also being made "CPU intensive" workqueues as well. > > >> >> > > >> >> This combination appears to result in both elevated scheduling > > >> >> priority and > > >> >> greater quantity of participant worker threads effectively starving > > >> >> any > > >> >> normal priority user task under periods of heavy IO on dmcrypt > > >> >> volumes. > > >> >> > > >> >> I don't know what the right solution is here. It seems to me we're > > >> >> lacking > > >> >> the appropriate mechanism for charging CPU resources consumed on > > >> >> behalf of > > >> >> user processes in kworker threads to the work-causing process. > > >> >> > > >> >> What effectively happens is my normal `git` user process is able to > > >> >> greatly amplify what share of CPU it takes from the system by > > >> >> generating IO > > >> >> on what happens to be a high-priority CPU-intensive storage volume. > > >> >> > > >> >> It looks potentially complicated to fix properly, but I suspect at > > >> >> its core > > >> >> this may be a fairly longstanding shortcoming of the page cache and > > >> >> its > > >> >> asynchronous design. Something that has been exacerbated > > >> >> substantially by > > >> >> the introduction of CPU-intensive storage subsystems like dmcrypt. > > >> >> > > >> >> If we imagine the whole stack simplified, where all the IO was being > > >> >> done > > >> >> synchronously in-band, and the dmcrypt kernel code simply ran in the > > >> >> IO-causing process context, it would be getting charged to the calling > > >> >> process and scheduled accordingly. The resource accounting and > > >> >> scheduling > > >> >> problems all emerge with the page cache, buffered IO, and async > > >> >> background > > >> >> writeback in a pool of unrelated worker threads, etc. That's how it > > >> >> appears to me anyways... > > >> >> > > >> >> The system used is a X61s Thinkpad 1.8Ghz with 840 EVO SSD, lvm on > > >> >> dmcrypt. > > >> >> The kernel .config is attached in case it's of interest. > > >> >> > > >> >> Thanks, > > >> >> Vito Caputo > > >> > > > >> > > > >> > > > >> > Ping... > > >> > > > >> > Could somebody please at least ACK receiving this so I'm not left > > >> > wondering > > >> > if my mails to lkml are somehow winding up flagged as spam, thanks! > > >> > > >> Sorry I did
[GIT PULL] nds32 fixes for 4.17
Linux 4.17-rc6 (2018-05-20 15:31:38 -0700) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/greentime/linux.git tags/nds32-for-linus-4.17-fixes for you to fetch changes up to a30e7d1e37e8acc37c25420d93af218166cca3ae: nds32: Fix compiler warning, Wstringop-overflow, in vdso.c (2018-05-23 13:26:22 +0800) nds32 patches for 4.17 Here is the nds32 patch set based on 4.17-rc6. Contained in here are the bug fixes and building error fixes for nds32. These are the LTP20170427 testing results. hackbench01 may fail sometimes. We are still investigating this issue. Total Tests: 1902 Total Skipped Tests: 593 Total Failures: 420 Kernel Version: 4.17.0-rc6-00018-ga30e7d1e37e8 Machine Architecture: nds32 Total Tests: 1902 Total Skipped Tests: 593 Total Failures: 419 Kernel Version: 4.17.0-rc5-00018-g27288975a735 Machine Architecture: nds32 Signed-off-by: Greentime Hu Greentime Hu (12): nds32: lib: To use generic lib instead of libgcc to prevent the symbol undefined issue. nds32: Fix building error when CONFIG_FREEZE is enabled. nds32: Fix building error of crypto/xor.c by adding xor.h nds32: Fix drivers/gpu/drm/udl/udl_fb.c building error by defining PAGE_SHARED nds32: Fix xfs_buf built failed by export invalidate_kernel_vmap_range and flush_kernel_vmap_range nds32: Fix the symbols undefined issue by exporting them. nds32: Fix the unknown type u8 issue. nds32: Fix build failed because arch_trace_hardirqs_off is changed to trace_hardirqs_off. nds32: Fix the allmodconfig build. To make sure CONFIG_CPU_LITTLE_ENDIAN is default y nds32: Fix the virtual address may map too much range by tlbop issue. nds32: To refine readability of INT_MASK_INITAIAL_VAL nds32: To fix a cache inconsistency issue by setting correct cacheability of NTC Nickhu (2): nds32: Renaming the file for unaligned access nds32: Fix the unaligned access handler Vincent Chen (4): nds32: Correct flush_dcache_page function nds32: Flush the cache of the page at vmaddr instead of kaddr in flush_anon_page nds32: Disable local irq before calling cpu_dcache_wb_page in copy_user_highpage nds32: Fix compiler warning, Wstringop-overflow, in vdso.c arch/nds32/Kconfig | 7 +++ arch/nds32/Kconfig.cpu | 5 +++-- arch/nds32/Makefile | 7 --- arch/nds32/include/asm/Kbuild | 2 ++ arch/nds32/include/asm/bitfield.h | 3 ++- arch/nds32/include/asm/cacheflush.h | 2 ++ arch/nds32/include/asm/io.h | 2 ++ arch/nds32/include/asm/page.h | 3 +++ arch/nds32/include/asm/pgtable.h| 1 + arch/nds32/kernel/ex-entry.S| 2 +- arch/nds32/kernel/head.S| 28 +++- arch/nds32/kernel/setup.c | 3 +++ arch/nds32/kernel/stacktrace.c | 2 ++ arch/nds32/kernel/vdso.c| 10 +- arch/nds32/lib/copy_page.S | 3 +++ arch/nds32/mm/alignment.c | 9 ++--- arch/nds32/mm/cacheflush.c | 74 -- arch/nds32/mm/init.c| 1 + 18 files changed, 130 insertions(+), 34 deletions(-)
Re: [PATCH] perf tools: Fix indexing for decoder packet queue
On Fri, May 25, 2018 at 05:10:54PM -0600, Mathieu Poirier wrote:
> The tail of a queue is supposed to be pointing to the next available slot
> in a queue. In this implementation the tail is incremented before it is
> used and as such points to the last used element, something that has the
> immense advantage of centralizing tail management at a single location
> and eliminating a lot of redundant code.
>
> But this needs to be taken into consideration on the dequeueing side where
> the head also needs to be incremented before it is used, or the first
> available element of the queue will be skipped.
>
> Signed-off-by: Mathieu Poirier
> ---
> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index c8b98fa22997..4d5fc374e730 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -96,11 +96,19 @@ int cs_etm_decoder__get_packet(struct cs_etm_decoder
> *decoder,
> /* Nothing to do, might as well just return */
> if (decoder->packet_count == 0)
> return 0;
> + /*
> + * The queueing process in function cs_etm_decoder__buffer_packet()
> + * increments the tail *before* using it. This is somewhat counter
> + * intuitive but it has the advantage of centralizing tail management
> + * at a single location. Because of that we need to follow the same
> + * heuristic with the head, i.e we increment it before using its
> + * value. Otherwise the first element of the packet queue is not
> + * used.
> + */
> + decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
>
> *packet = decoder->packet_buffer[decoder->head];
>
> - decoder->head = (decoder->head + 1) & (MAX_BUFFER - 1);
> -
I tested this patch and confirmed it can work well with python
decoding script:
Tested-by: Leo Yan
Actually, I have another idea for this fixing, seems to me
the unchanged code has right logic for decoder->head, and I think this
issue is more related with incorrect initialization index. So we can
change the initialization index for decoder->head as below. How about
you think for this?
diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
index c8b98fa..b133260 100644
--- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
+++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
@@ -249,7 +249,7 @@ static void cs_etm_decoder__clear_buffer(struct
cs_etm_decoder *decoder)
{
int i;
- decoder->head = 0;
+ decoder->head = 1;
decoder->tail = 0;
decoder->packet_count = 0;
for (i = 0; i < MAX_BUFFER; i++) {
Thanks,
Leo Yan
> decoder->packet_count--;
>
> return 1;
> --
> 2.7.4
>
Re: [PATCH] drivers/net/phy/micrel: Fix for PHY KSZ8061 errrata: Potential link-up failure when Ethernet cable is connected slowly
> This e-mail (including any attachments) is confidential and may be > legally privileged. If you are not an intended recipient or an > authorized representative of an intended recipient, you are > prohibited from using, copying or distributing the information in > this e-mail or its attachments. If you have received this e-mail in > error, please notify the sender immediately by return e-mail and > delete all copies of this message and any attachments. Thank you. Once this has been removed, i will have a comment... Andrew
Re: [PATCH v3 8/8] drm/mediatek: add third ddp path
Hi, Stu: On Mon, 2018-05-28 at 10:26 +0800, Stu Hsieh wrote: > Hi, CK: > I've some idea as below. > > On Fri, 2018-05-25 at 13:00 +0800, CK Hu wrote: > > Hi, Stu: > > > > On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote: > > > From: Stu Hsieh > > > > > > This patch create third crtc by third ddp path > > > > > > > Apply this patch before the patch 'Add support for mediatek SOC MT2712' > > because this patch is necessary for mt2712. > > > > > Signed-off-by: Stu Hsieh > > > --- > > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > > index b32c4cc8d051..3a866e1d6af4 100644 > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > > @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm) > > > if (ret < 0) > > > goto err_component_unbind; > > > > > > + ret = mtk_drm_crtc_create(drm, private->data->third_path, > > > + private->data->third_len); > > > > I think you should prevent doing this for mt8173 and mt2701 because that > > two SoC has only two ddp path. > > Now, 8173 and 2701 have only two ddp path, there is a problem on run > time. > There are three crtc for drm resource, and there is nothing in third > crtc. > Because 8173 and 2701 have no third ddp, and the third ddp_len is zero. > So, I want to add the condition like following in mtk_crtc_create() > if (path_len == 0) > return 0; > > Then, the valur ret is zero and it would not create the null third crtc. This sounds good to me. Regards, CK > > > Regards, > Stu > > > > > Regards, > > CK > > > > > + if (ret < 0) > > > + goto err_component_unbind; > > > + > > > /* Use OVL device for all DMA memory allocations */ > > > np = private->comp_node[private->data->main_path[0]] ?: > > >private->comp_node[private->data->ext_path[0]]; > > > > > >
Re: [RESEND PATCH V5 00/33] block: support multipage bvec
On Sun, May 27, 2018 at 07:44:52PM -0600, Jens Axboe wrote: > On 5/27/18 1:23 AM, Ming Lei wrote: > > On Fri, May 25, 2018 at 10:30:46AM -0600, Jens Axboe wrote: > >> On 5/24/18 10:53 PM, Kent Overstreet wrote: > >>> On Fri, May 25, 2018 at 11:45:48AM +0800, Ming Lei wrote: > Hi, > > This patchset brings multipage bvec into block layer: > >>> > >>> patch series looks sane to me. goddamn that's a lot of renaming. > >> > >> Indeed... I actually objected to some of the segment -> page > >> renaming, but it's still in there. The foo2() temporary functions > >> also concern me, we all know there's nothing more permanent than a > >> temporary fixup. > > > > Jens, I remember I explained the renaming story to you in lsfmm a bit: > > > > 1) the current naming of segment is actually wrong, since every segment > > only stores one single-page vector > > > > 2) the most important part is that once multipage bvec is introduced, > > if the old _segment naming is still kept, it can be very confusing, > > especially no good name is left for the helpers of dealing with real > > segment. > > Yes, we discussed exactly this, which is why I'm surprised you went > ahead with the same approach. I told you I don't like tree wide renames, Maybe I misunderstood your point, that isn't strange given my poor english, :-) > if they can be avoided. I'd rather suffer some pain wrt page vs segments > naming, and then later do a rename (if it bothers us) once the dust has > settled on the interesting part of the changes. > > I'm very well away of our current naming and what it signifies. With > #1, you are really splitting hairs, imho. Find a decent name for > multiple segment. Chunk? OK, will try _chunk in next post. > > > For the foo2() temporary change, that is only for avoiding tree-wide > > change in one single tree, with this way, we can change sub-system one > > by one, but if you think it is good to do tree-wide conversion in one > > patch, I am fine to do it in next version. > > It's still a painful middle step. I hate the conversion too, but looks it can't be avoided since bio_for_each_segment_all() has to be changed. Could you share us what your favorite approach is for this conversion? Thanks, Ming
Re: [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU
On Tue, Feb 27, 2018 at 11:17:12AM +0100, Sebastian Reichel wrote: > Hi, > > On Tue, Feb 27, 2018 at 09:10:34AM +0800, Shawn Guo wrote: > > On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote: > > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote: > > > > On Mon, Feb 12, 2018 at 01:39:44PM +0100, Sebastian Reichel wrote: > > > > > On i.MX53 it is necessary to set the DBG_EN bit in the > > > > > platform GPC register to enable access to PMU counters > > > > > other than the cycle counter. > > > > > > > > > > Signed-off-by: Sebastian Reichel > > > > > --- > > > > > arch/arm/mach-imx/mach-imx53.c | 39 > > > > > ++- > > > > > 1 file changed, 38 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/arch/arm/mach-imx/mach-imx53.c > > > > > b/arch/arm/mach-imx/mach-imx53.c > > > > > index 07c2e8dca494..658e28604dca 100644 > > > > > --- a/arch/arm/mach-imx/mach-imx53.c > > > > > +++ b/arch/arm/mach-imx/mach-imx53.c > > > > > @@ -28,10 +28,47 @@ static void __init imx53_init_early(void) > > > > > mxc_set_cpu_type(MXC_CPU_MX53); > > > > > } > > > > > > > > > > +#define MXC_CORTEXA8_PLAT_GPC 0x63fa0004 > > > > > > > > The base address should be retrieved from device tree. > > > > > > DT has no entry for 0x63fa-0x63fa3fff. iMX53 TRM lists it as "ARM > > > Platform" > > > with 8 platform specific 32 bit registers. Do you think it's worth the > > > trouble > > > adding a new binding? Do you have a suggestion for a compatible value? > > > > Looking at it more closely, I feel that patching every single platform > > which needs to set up additional register for secure-reg-access support > > doesn't really scale. Can we have pmu driver do it with a phandle in > > DT pointing to the register and bit that need to be configured? > > The PMU driver used to have a feature for initialising platform > specific bits, but it is currently being removed to make the PMU > code more maintainable. My understanding is, that it's very uncommon > to require platform specific setup to get secure-reg-access working. > I.e. it is not needed for newer iMX platforms. Are you saying this is a very specific setup required by i.MX53 only? In that case, I can live with it. Shawn
Re: [PATCH v3 8/8] drm/mediatek: add third ddp path
Hi, CK: I've some idea as below. On Fri, 2018-05-25 at 13:00 +0800, CK Hu wrote: > Hi, Stu: > > On Fri, 2018-05-25 at 10:34 +0800, stu.hs...@mediatek.com wrote: > > From: Stu Hsieh > > > > This patch create third crtc by third ddp path > > > > Apply this patch before the patch 'Add support for mediatek SOC MT2712' > because this patch is necessary for mt2712. > > > Signed-off-by: Stu Hsieh > > --- > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > index b32c4cc8d051..3a866e1d6af4 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > > @@ -267,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm) > > if (ret < 0) > > goto err_component_unbind; > > > > + ret = mtk_drm_crtc_create(drm, private->data->third_path, > > + private->data->third_len); > > I think you should prevent doing this for mt8173 and mt2701 because that > two SoC has only two ddp path. Now, 8173 and 2701 have only two ddp path, there is a problem on run time. There are three crtc for drm resource, and there is nothing in third crtc. Because 8173 and 2701 have no third ddp, and the third ddp_len is zero. So, I want to add the condition like following in mtk_crtc_create() if (path_len == 0) return 0; Then, the valur ret is zero and it would not create the null third crtc. Regards, Stu > > Regards, > CK > > > + if (ret < 0) > > + goto err_component_unbind; > > + > > /* Use OVL device for all DMA memory allocations */ > > np = private->comp_node[private->data->main_path[0]] ?: > > private->comp_node[private->data->ext_path[0]]; > >
Re: [PATCH] powerpc-opal: fix spelling mistake "Uniterrupted" -> "Uninterrupted"
Colin King writes: > From: Colin Ian King > > Trivial fix to spelling mistake in hmi_error_types text > > Signed-off-by: Colin Ian King Reviewed-by: Stewart Smith -- Stewart Smith OPAL Architect, IBM.
Re: [Nouveau] [PATCH][next] drm/nouveau/disp: avoid potential overflow on shift of int value
On Sun, May 27, 2018 at 5:54 PM, Colin King wrote:
> From: Colin Ian King
>
> The constant values being shifted are 32 bit integers and may potentially
> overflow on the shift. Avoid this potential overflow by making them
> unsigned long long values before the shift.
>
> Detected by CoverityScan, CID#1469383, 1469400 ("Unintentional
> integer overflow")
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/changf119.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/changf119.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/changf119.c
> index 29e6dd58ac48..99b94802ed63 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/changf119.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/changf119.c
> @@ -52,7 +52,7 @@ void
> gf119_disp_chan_intr(struct nv50_disp_chan *chan, bool en)
> {
> struct nvkm_device *device = chan->disp->base.engine.subdev.device;
> - const u64 mask = 0x0001 << chan->chid.user;
> + const u64 mask = 0x0001ULL << chan->chid.user;
I'm pretty sure all of these should just be u32 (below as well). The
registers that this is masking are all 32-bit, more doesn't make
sense.
> if (!en) {
> nvkm_mask(device, 0x610090, mask, 0x);
> nvkm_mask(device, 0x6100a0, mask, 0x);
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> index 57719f675eec..43ae3b092e43 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> @@ -166,7 +166,7 @@ void
> nv50_disp_chan_intr(struct nv50_disp_chan *chan, bool en)
> {
> struct nvkm_device *device = chan->disp->base.engine.subdev.device;
> - const u64 mask = 0x00010001 << chan->chid.user;
> + const u64 mask = 0x00010001ULL << chan->chid.user;
> const u64 data = en ? 0x0001 : 0x;
> nvkm_mask(device, 0x610028, mask, data);
> }
> --
> 2.17.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
[PATCH v6 4/4] vsprintf: Add command line option debug_boot_weak_hash
Currently printing [hashed] pointers requires enough entropy to be
available. Early in the boot sequence this may not be the case
resulting in a dummy string '(ptrval)' being printed. This
makes debugging the early boot sequence difficult. We can relax the
requirement to use cryptographically secure hashing during debugging.
This enables debugging while keeping development/production kernel
behaviour the same.
If new command line option debug_boot_weak_hash is enabled use
cryptographically insecure hashing and hash pointer value immediately.
Cc: Anna-Maria Gleixner
Cc: Steven Rostedt
Cc: Randy Dunlap
Signed-off-by: Tobin C. Harding
---
Documentation/admin-guide/kernel-parameters.txt | 9 +
lib/vsprintf.c | 20
2 files changed, 29 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index f2040d46f095..8a86d895343e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -753,6 +753,15 @@
debug [KNL] Enable kernel debugging (events log level).
+ debug_boot_weak_hash
+ [KNL] Enable printing pointers early in the boot
+ sequence. If enabled, we use a weak hash instead of
+ siphash to hash pointers. Use this option if you need
+ to see pointer values during early boot (i.e you are
+ seeing instances of '(___ptrval___)').
+ Cryptographically insecure, please do not use on
+ production kernels.
+
debug_locks_verbose=
[KNL] verbose self-tests
Format=<0|1>
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 1545a8aa26a9..369623205e2c 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1670,6 +1670,20 @@ char *pointer_string(char *buf, char *end, const void
*ptr,
}
static DEFINE_STATIC_KEY_TRUE(not_filled_random_ptr_key);
+
+/* Make pointers available for printing early in the boot sequence. */
+static int debug_boot_weak_hash __ro_after_init;
+EXPORT_SYMBOL(debug_boot_weak_hash);
+
+static int __init debug_boot_weak_hash_enable(char *str)
+{
+ debug_boot_weak_hash = 1;
+ pr_info("debug_boot_weak_hash enabled\n");
+ return 0;
+}
+early_param("debug_boot_weak_hash", debug_boot_weak_hash_enable);
+
+static bool have_filled_random_ptr_key __read_mostly;
static siphash_key_t ptr_key __read_mostly;
static void enable_ptr_key_workfn(struct work_struct *work)
@@ -1721,6 +1735,12 @@ static char *ptr_to_id(char *buf, char *end, void *ptr,
struct printf_spec spec)
unsigned long hashval;
const int default_width = 2 * sizeof(ptr);
+ /* When debugging early boot use non-cryptographically secure hash */
+ if (unlikely(debug_boot_weak_hash)) {
+ hashval = hash_long((unsigned long)ptr, 32);
+ return pointer_string(buf, end, (const void *)hashval, spec);
+ }
+
if (static_branch_unlikely(¬_filled_random_ptr_key)) {
spec.field_width = default_width;
/* string length must be less than default_width */
--
2.7.4
[PATCH v6 1/4] random: Fix whitespace pre random-bytes work
There are a couple of whitespace issues around the function get_random_bytes_arch(). In preparation for patching this function let's clean them up. Signed-off-by: Tobin C. Harding Acked-by: Theodore Ts'o --- drivers/char/random.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index cd888d4ee605..031d18b31e0f 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1737,7 +1737,7 @@ void get_random_bytes_arch(void *buf, int nbytes) if (!arch_get_random_long(&v)) break; - + memcpy(p, &v, chunk); p += chunk; nbytes -= chunk; @@ -1748,7 +1748,6 @@ void get_random_bytes_arch(void *buf, int nbytes) } EXPORT_SYMBOL(get_random_bytes_arch); - /* * init_std_data - initialize pool with system data * -- 2.7.4
[PATCH v6 3/4] vsprintf: Use hw RNG for ptr_key
Currently we must wait for enough entropy to become available before
hashed pointers can be printed. We can remove this wait by using the
hw RNG if available.
Use hw RNG to get keying material.
Cc: Steven Rostedt (VMware)
Suggested-by: Kees Cook
Signed-off-by: Tobin C. Harding
---
lib/vsprintf.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 23920c5ff728..1545a8aa26a9 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1693,8 +1693,16 @@ static struct random_ready_callback random_ready = {
static int __init initialize_ptr_random(void)
{
- int ret = add_random_ready_callback(&random_ready);
+ int key_size = sizeof(ptr_key);
+ int ret;
+
+ /* Use hw RNG if available */
+ if (get_random_bytes_arch(&ptr_key, key_size) == key_size) {
+ static_branch_disable(¬_filled_random_ptr_key);
+ return 0;
+ }
+ ret = add_random_ready_callback(&random_ready);
if (!ret) {
return 0;
} else if (ret == -EALREADY) {
--
2.7.4
[PATCH v6 2/4] random: Return nbytes filled from hw RNG
Currently the function get_random_bytes_arch() has return value 'void'.
If the hw RNG fails we currently fall back to using get_random_bytes().
This defeats the purpose of requesting random material from the hw RNG
in the first place.
There are currently no intree users of get_random_bytes_arch().
Only get random bytes from the hw RNG, make function return the number
of bytes retrieved from the hw RNG.
Signed-off-by: Tobin C. Harding
Acked-by: Theodore Ts'o
Reviewed-by: Steven Rostedt (VMware)
---
drivers/char/random.c | 16 +---
include/linux/random.h | 2 +-
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 031d18b31e0f..8b9b537ae634 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1725,26 +1725,28 @@ EXPORT_SYMBOL(del_random_ready_callback);
* key known by the NSA). So it's useful if we need the speed, but
* only if we're willing to trust the hardware manufacturer not to
* have put in a back door.
+ *
+ * Return number of bytes filled in.
*/
-void get_random_bytes_arch(void *buf, int nbytes)
+int __must_check get_random_bytes_arch(void *buf, int nbytes)
{
+ int left = nbytes;
char *p = buf;
- trace_get_random_bytes_arch(nbytes, _RET_IP_);
- while (nbytes) {
+ trace_get_random_bytes_arch(left, _RET_IP_);
+ while (left) {
unsigned long v;
- int chunk = min(nbytes, (int)sizeof(unsigned long));
+ int chunk = min_t(int, left, (int)sizeof(unsigned long));
if (!arch_get_random_long(&v))
break;
memcpy(p, &v, chunk);
p += chunk;
- nbytes -= chunk;
+ left -= chunk;
}
- if (nbytes)
- get_random_bytes(p, nbytes);
+ return nbytes - left;
}
EXPORT_SYMBOL(get_random_bytes_arch);
diff --git a/include/linux/random.h b/include/linux/random.h
index 2ddf13b4281e..f1c9bc5cd231 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -38,7 +38,7 @@ extern void get_random_bytes(void *buf, int nbytes);
extern int wait_for_random_bytes(void);
extern int add_random_ready_callback(struct random_ready_callback *rdy);
extern void del_random_ready_callback(struct random_ready_callback *rdy);
-extern void get_random_bytes_arch(void *buf, int nbytes);
+extern int __must_check get_random_bytes_arch(void *buf, int nbytes);
#ifndef MODULE
extern const struct file_operations random_fops, urandom_fops;
--
2.7.4
[PATCH v6 0/4] enable early printing of hashed pointers
Currently printing pointers early in the boot sequence can result in a dummy string '(ptrval)' being printed. While resolving this issue it was noticed that we can use the hw RNG if available for hashing pointers. Patch one and two do the ground work to be able to use hw RNG removing from get_random_bytes_arch() the call to get_random_bytes() and returning the number of bytes of random material successfully returned. Patch three uses the hw RNG to get keying material if it is available. Patch four further assists debugging early in the boot sequence for machines that do not have a hw RNG by adding a command line option 'debug_boot_weak_hash'. If enabled, non-cryptographically secure hashing is used instead of siphash so we can hash at any time. During the versions of this set I have been totally confused about which patches go through which tree. This version again puts all 4 patches together in the hope they will go through Andrew's tree. Steve, Could you please take a quick squiz at the final 2 patches if you get a chance. I assumed we are in preemptible context during early_init based on your code (and code comment) and called static_branch_disable() directly if hw RNG returned keying material. It's a pretty simple change but I'd love to get someone else to check I've not noob'ed it. thanks, Tobin. v6 - Rebase on top of Steve's patch (fixing race condition). Uses static branch instead of memory barrier. v5 - Use 'upside-down-xmas-tree' style to declare local variables (Steve) - Added Reviewed-by tag from Steve (patch 2 and 3). v4 - remove last patch of series (command line option patch) v3 - Add __ro_after_init (suggested by Kees). v2 - Use min_t() instead of min() (thanks checkpatch). - Add __must_check to function declaration (thanks Steve). - Use hw RNG by default if available (as originally suggested by Kees). - Add command line option to use cryptographically insecure hashing. If debug_early_boot is enabled use hash_long() instead of siphash (as requested by Steve, and solves original problem for Anna-Maria). - Added Acked-by tag from Ted (patch 1 and 2) Tobin C. Harding (4): random: Fix whitespace pre random-bytes work random: Return nbytes filled from hw RNG vsprintf: Use hw RNG for ptr_key vsprintf: Add command line option debug_boot_weak_hash Documentation/admin-guide/kernel-parameters.txt | 9 drivers/char/random.c | 19 include/linux/random.h | 2 +- lib/vsprintf.c | 30 - 4 files changed, 49 insertions(+), 11 deletions(-) -- 2.7.4
Re: [RESEND PATCH V5 00/33] block: support multipage bvec
On 5/27/18 1:23 AM, Ming Lei wrote: > On Fri, May 25, 2018 at 10:30:46AM -0600, Jens Axboe wrote: >> On 5/24/18 10:53 PM, Kent Overstreet wrote: >>> On Fri, May 25, 2018 at 11:45:48AM +0800, Ming Lei wrote: Hi, This patchset brings multipage bvec into block layer: >>> >>> patch series looks sane to me. goddamn that's a lot of renaming. >> >> Indeed... I actually objected to some of the segment -> page >> renaming, but it's still in there. The foo2() temporary functions >> also concern me, we all know there's nothing more permanent than a >> temporary fixup. > > Jens, I remember I explained the renaming story to you in lsfmm a bit: > > 1) the current naming of segment is actually wrong, since every segment > only stores one single-page vector > > 2) the most important part is that once multipage bvec is introduced, > if the old _segment naming is still kept, it can be very confusing, > especially no good name is left for the helpers of dealing with real > segment. Yes, we discussed exactly this, which is why I'm surprised you went ahead with the same approach. I told you I don't like tree wide renames, if they can be avoided. I'd rather suffer some pain wrt page vs segments naming, and then later do a rename (if it bothers us) once the dust has settled on the interesting part of the changes. I'm very well away of our current naming and what it signifies. With #1, you are really splitting hairs, imho. Find a decent name for multiple segment. Chunk? > For the foo2() temporary change, that is only for avoiding tree-wide > change in one single tree, with this way, we can change sub-system one > by one, but if you think it is good to do tree-wide conversion in one > patch, I am fine to do it in next version. It's still a painful middle step. >>> Things are going to get interesting when we start sticking compound >>> pages in the page cache, there'll be some interesting questions of >>> semantics to deal with then but I think getting this will only help >>> w.r.t. plumbing that through and not dealing with 4k pages >>> unnecessarily - but I think even if we were to decide that merging >>> in bio_add_page() is not the way to go when the upper layers are >>> passing compound pages around already, this patch series helps >>> because regardless at some point everything under >>> generic_make_request() is going to have to deal with segments that >>> are more than one page, and this patch series makes that happen. So >>> incremental progress. >>> >>> Jens, any objections to getting this in? >> >> I like most of it, but I'd much rather get this way earlier in the >> series. We're basically just one week away from the merge window, it >> needs more simmer and testing time than that. On top of that, it >> hasn't received much review yet. >> >> So as far as I'm concerned, we can kick off the 4.19 block branch >> with iterated versions of this patchset. > > OK, I will post out again once v4.19 is started. Sounds good. -- Jens Axboe
[PATCH v2] sched: Remove obscure comment from select_task_rq_fair
I was playing with cpusets and sched_load_balance flag and notice that
the fast-path (select_idle_sibling) can also be attempted for
exec-balance, not just wake-balance if the waker cpu's cpuset has
sched_load_balance = 0. This patch removes the obscure comment which was
saying this path can be entered only for wake-balance.
To trigger this, I just do:
mkdir /cpuset
mount -t cpuset none /cpuset
echo 0 > sched_load_balance
Then did some random activity and dumped the stack from 'if (!sd)' for
the non wake-balance cases.
Following is one of the stacks:
dump_stack+0x46/0x5b
select_task_rq_fair+0x101d/0x1030
sched_exec+0x4f/0xc0
do_execveat_common.isra.41+0x1e3/0x7c0
__x64_sys_execve+0x2d/0x40
do_syscall_64+0x43/0xf0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Turns out the same case occurs also during boot up when kthreadd tries
to create threads before domains are attached so lets fix the comment.
Cc: Dietmar Eggemann
Cc: Morten Ramussen
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
Cc: Patrick Bellasi
Cc: Rohit Jain
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes (Google)
---
v1->v2: Resending without "XXX" in subject since otherwise LKML thinks
its junk.
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 54dc31e7ab9b..dd07794141d0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6665,7 +6665,7 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu,
int sd_flag, int wake_f
if (!sd) {
pick_cpu:
- if (sd_flag & SD_BALANCE_WAKE) { /* XXX always ? */
+ if (sd_flag & SD_BALANCE_WAKE) {
new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
if (want_affine)
--
2.17.0.921.gf22659ad46-goog
Re: [PATCH] kernel/sched/topology: Clarify root domain(s) debug string
On Thu, May 24, 2018 at 05:29:36PM +0200, Juri Lelli wrote:
> When scheduler debug is enabled, building scheduling domains outputs
> information about how the domains are laid out and to which root domain
> each CPU (or sets of CPUs) belongs, e.g.:
>
> CPU0 attaching sched-domain(s):
> domain-0: span=0-5 level=MC
>groups: 0:{ span=0 }, 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4
> }, 5:{ span=5 }
> CPU1 attaching sched-domain(s):
> domain-0: span=0-5 level=MC
>groups: 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5
> }, 0:{ span=0 }
>
> [...]
>
> span: 0-5 (max cpu_capacity = 1024)
>
> The fact that latest line refers to CPUs 0-5 root domain doesn't however look
last line?
> immediately obvious to me: one might wonder why span 0-5 is reported "again".
>
> Make it more clear by adding "root domain" to it, as to end with the
> following.
>
> CPU0 attaching sched-domain(s):
> domain-0: span=0-5 level=MC
>groups: 0:{ span=0 }, 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4
> }, 5:{ span=5 }
> CPU1 attaching sched-domain(s):
> domain-0: span=0-5 level=MC
>groups: 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5
> }, 0:{ span=0 }
>
> [...]
>
> root domain span: 0-5 (max cpu_capacity = 1024)
>
> Signed-off-by: Juri Lelli
I played the sched_load_balance flag to trigger this and it makes sense to
improve the print with 'root domain'.
Reviewed-by: Joel Fernandes (Google)
One thing I believe is a bit weird is sched_load_balance also can affect the
wake-up path, because a NULL sd is attached to the rq if sched_load_balance
is set to 0.
This could turn off the "for_each_domain(cpu, tmp)" loop in
select_task_rq_fair and hence we would always end up in the
select_idle_sibling path for those CPUs.
It also means that "XXX always" can/should be removed because sd can very
well be NULL for other sd_flag types as well, not just sd_flag ==
SD_BALANCE_WAKE. I'll send a patch to remove that comment as I just tested
this is true.
thanks,
- Joel
Re: [PATCH] cpuidle/powernv : init all present cpus for deep states
Michael Ellerman writes: > Akshay Adiga writes: > >> Init all present cpus for deep states instead of "all possible" cpus. >> Init fails if the possible cpu is gaurded. Resulting in making only >> non-deep states available for cpuidle/hotplug. > > This is basically the opposite of what we just did for IMC. > > There we switched from present to possible, to make it work when some > CPUs are guarded. > > Which makes me think we need a better way of dealing with guarded CPUs, > because working out which code should use present or possible seems to > be basically trial-and-error. > > I'm not actually sure why Guarded CPUs are showing up as possible but > not present, did we do that on purpose or is it just happening by > accident? My guess is that it flows through from firmware putting the guarded out CPUs in the device tree with a not "okay" status (which, I just realised, we're putting something in 'status' that isn't what the current DeviceTree spec says we should... gah - https://github.com/open-power/skiboot/issues/178 filed for that one). The idea behind that is that you can answer "where did all my CPUs go?" by looking at the device tree rather than having to know the platform specific way of how guards are stored. -- Stewart Smith OPAL Architect, IBM.
[PATCH] net: qmi_wwan: Add Netgear Aircard 779S
Add support for Netgear Aircard 779S
Signed-off-by: Josh Hill
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 42565dd..0946808 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1103,6 +1103,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x05c6, 0x920d, 5)},
{QMI_QUIRK_SET_DTR(0x05c6, 0x9625, 4)}, /* YUGA CLM920-NC5 */
{QMI_FIXED_INTF(0x0846, 0x68a2, 8)},
+ {QMI_FIXED_INTF(0x0846, 0x68d3, 8)},/* Netgear Aircard 779S */
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)},/* Huawei E173 */
{QMI_FIXED_INTF(0x12d1, 0x14ac, 1)},/* Huawei E1820 */
{QMI_FIXED_INTF(0x1435, 0xd181, 3)},/* Wistron NeWeb D18Q1 */
--
2.7.4
Re: [PATCH] doc: document scope NOFS, NOIO APIs
On Fri, May 25, 2018 at 10:16:24AM +0200, Michal Hocko wrote: > On Fri 25-05-18 08:17:15, Dave Chinner wrote: > > On Thu, May 24, 2018 at 01:43:41PM +0200, Michal Hocko wrote: > [...] > > > +FS/IO code then simply calls the appropriate save function right at the > > > +layer where a lock taken from the reclaim context (e.g. shrinker) and > > > +the corresponding restore function when the lock is released. All that > > > +ideally along with an explanation what is the reclaim context for easier > > > +maintenance. > > > > This paragraph doesn't make much sense to me. I think you're trying > > to say that we should call the appropriate save function "before > > locks are taken that a reclaim context (e.g a shrinker) might > > require access to." > > > > I think it's also worth making a note about recursive/nested > > save/restore stacking, because it's not clear from this description > > that this is allowed and will work as long as inner save/restore > > calls are fully nested inside outer save/restore contexts. > > Any better? > > -FS/IO code then simply calls the appropriate save function right at the > -layer where a lock taken from the reclaim context (e.g. shrinker) and > -the corresponding restore function when the lock is released. All that > -ideally along with an explanation what is the reclaim context for easier > -maintenance. > +FS/IO code then simply calls the appropriate save function before any > +lock shared with the reclaim context is taken. The corresponding > +restore function when the lock is released. All that ideally along with > +an explanation what is the reclaim context for easier maintenance. > + > +Please note that the proper pairing of save/restore function allows nesting > +so memalloc_noio_save is safe to be called from an existing NOIO or NOFS > scope. It's better, but the talk of this being necessary for locking makes me cringe. XFS doesn't do it for locking reasons - it does it largely for preventing transaction context nesting, which has all sorts of problems that cause hangs (e.g. log space reservations can't be filled) that aren't directly locking related. i.e we should be talking about using these functions around contexts where recursion back into the filesystem through reclaim is problematic, not that "holding locks" is problematic. Locks can be used as an example of a problematic context, but locks are not the only recursion issue that require GFP_NOFS allocation contexts to avoid. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH v2 2/3] Documentation: usb: add documentation for USB CCID Gadget Device
Hi, I have a few documentation comments below... On 05/26/2018 02:19 PM, Marcus Folkesson wrote: > Add documentation to give a brief description on how to use the > CCID Gadget Device. > This includes a description for all attributes followed by an example on > how to setup the device with ConfigFS. > > Signed-off-by: Marcus Folkesson > --- > Documentation/usb/gadget_ccid.rst | 267 > ++ > 1 file changed, 267 insertions(+) > create mode 100644 Documentation/usb/gadget_ccid.rst > > diff --git a/Documentation/usb/gadget_ccid.rst > b/Documentation/usb/gadget_ccid.rst > new file mode 100644 > index ..5ac806b14604 > --- /dev/null > +++ b/Documentation/usb/gadget_ccid.rst > @@ -0,0 +1,267 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > + > +CCID Gadget > + > + > +:Author: Marcus Folkesson > + > +Introduction > + > + > +The CCID Gadget will present itself as a CCID device to the host system. > +The device supports two endpoints for now; BULK IN and BULK OUT. > +These endpoints is exposed to userspace via /dev/ccidg*. are exposed > + > +All CCID commands are sent on the BULK-OUT endpoint. Each command sent to > the CCID > +has an associated ending response. Some commands can also have intermediate > +responses. The response is sent on the BULK-IN endpoint. > +See Figure 3-3 in the CCID Specification [1]_ for more details. > + > +The CCID commands must be handled in userspace since the driver is only > working > +as a transport layer for the TPDUs. > + > + > +CCID Commands > +-- > + > +All CCID commands begins with a 10 bytes header followed by an optional with a 10-byte header (or maybe that's a locale difference) > +data field depending on message type. > + > +++--+---+--+ > +| Offset | Field| Size | Description | > +++==+===+==+ > +| 0 | bMessageType | 1 | Type of message | > +++--+---+--+ > +| 1 | dwLength | 4 | Message specific data length | > +|| | | | > +++--+---+--+ > +| 5 | bSlot| 1 | Identifies the slot number | > +|| | | for this command | > +++--+---+--+ > +| 6 | bSeq | 1 | Sequence number for command | > +++--+---+--+ > +| 7 | ... | 3 | Fields depends on message type | > +++--+---+--+ > +| 10 | abData | array | Message specific data (OPTIONAL) | > +++--+---+--+ > + > + > +Multiple CCID gadgets > +-- > + > +It is possible to create multiple instances of the CCID gadget, however, > +a much more flexible way is to create one gadget and set the `nslots` > attribute > +to the number of desired CCID devices. > + > +All CCID commands specifies which slot that is the receiver in the `bSlot` > field specify which slot is the receiver > +of the CCID header. > + > +Usage > += > + > +Access from userspace > +-- > +All communication is by read(2) and write(2) to the corresponding > /dev/ccidg* device. > +Only one filedescriptor is allowed to be open to the device at a time. file descriptor > + > +The buffer size provided to read(2) **must be at least** 522 (10 bytes > header + 512 bytes payload) > +bytes as we are working with whole commands. > + > +The buffer size provided to write(2) **may not exceed** 522 (10 bytes header > + 512 bytes payload) > +bytes as we are working with whole commands. > + > + > +Configuration with configfs > + > + > +ConfigFS is used to create and configure the CCID gadget. > +In order to get a device to work as intended, a few attributes must > +be considered. > + > +The attributes is described below followed by an example. are > + > +features > +~ > + > +The `feature` attribute writes to the dwFeatures field in the class > descriptor. > +See Table 5.1-1 Smart Card Device Descriptors in the CCID Specification [1]_. > + > +The value indicates what intelligent features the CCID has. > +These values are available to user application as defines in ccid.h [2]_. as defined > +The default value is 0x. [snip] HTH. -- ~Randy
Re: [PATCH] HID: rmi: use HID_QUIRK_NO_INPUT_SYNC
On Fri, May 25, 2018 at 02:51:06PM +0200, Benjamin Tissoires wrote:
> When we receive a RMI4 report, we should not unconditionally send an
> input_sync event. Instead, we should let the rmi4 transport layer do it
> for us.
>
> This fixes a situation where we might receive X in a report and the rest
> in a subsequent one. And this messes up user space.
>
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=100436
>
> Signed-off-by: Benjamin Tissoires
> ---
yes please!
Acked-by: Peter Hutterer
Cheers,
Peter
>
> Hi,
>
> Oscar, do you mind if we add your "Tested-by: Oscar Morante "?
>
> Andrew, can you check for any sides effects please?
>
> Cheers,
> Benjamin
>
> drivers/hid/hid-rmi.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
> index 9c9362149641..9e33165250a3 100644
> --- a/drivers/hid/hid-rmi.c
> +++ b/drivers/hid/hid-rmi.c
> @@ -413,6 +413,24 @@ static int rmi_event(struct hid_device *hdev, struct
> hid_field *field,
> return 0;
> }
>
> +static void rmi_report(struct hid_device *hid, struct hid_report *report)
> +{
> + struct hid_field *field = report->field[0];
> +
> + if (!(hid->claimed & HID_CLAIMED_INPUT))
> + return;
> +
> + switch (report->id) {
> + case RMI_READ_DATA_REPORT_ID:
> + /* fall-through */
> + case RMI_ATTN_REPORT_ID:
> + return;
> + }
> +
> + if (field && field->hidinput && field->hidinput->input)
> + input_sync(field->hidinput->input);
> +}
> +
> #ifdef CONFIG_PM
> static int rmi_suspend(struct hid_device *hdev, pm_message_t message)
> {
> @@ -637,6 +655,7 @@ static int rmi_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
> hid_set_drvdata(hdev, data);
>
> hdev->quirks |= HID_QUIRK_NO_INIT_REPORTS;
> + hdev->quirks |= HID_QUIRK_NO_INPUT_SYNC;
>
> ret = hid_parse(hdev);
> if (ret) {
> @@ -744,6 +763,7 @@ static struct hid_driver rmi_driver = {
> .remove = rmi_remove,
> .event = rmi_event,
> .raw_event = rmi_raw_event,
> + .report = rmi_report,
> .input_mapping = rmi_input_mapping,
> .input_configured = rmi_input_configured,
> #ifdef CONFIG_PM
> --
> 2.14.3
>
