- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "arm64: dma-mapping: Only swizzle DMA ops for IOMMU_DOMAIN_DMA" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: dma-mapping: Only swizzle DMA ops for IOMMU_DOMAIN_DMA to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-dma-mapping-only-swizzle-dma-ops-for-iommu_domain_dma.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Nov 9 09:48:01 CET 2017 From: Will Deacon <will.deacon(a)arm.com> Date: Fri, 6 Jan 2017 10:49:12 +0000 Subject: arm64: dma-mapping: Only swizzle DMA ops for IOMMU_DOMAIN_DMA From: Will Deacon <will.deacon(a)arm.com> [ Upstream commit 4a8d8a14c0d08c2437cb80c05e88f6cc1ca3fb2c ] The arm64 DMA-mapping implementation sets the DMA ops to the IOMMU DMA ops if we detect that an IOMMU is present for the master and the DMA ranges are valid. In the case when the IOMMU domain for the device is not of type IOMMU_DOMAIN_DMA, then we have no business swizzling the ops, since we're not in control of the underlying address space. This patch leaves the DMA ops alone for masters attached to non-DMA IOMMU domains. Reviewed-by: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/mm/dma-mapping.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) --- a/arch/arm64/mm/dma-mapping.c +++ b/arch/arm64/mm/dma-mapping.c @@ -836,14 +836,21 @@ static bool do_iommu_attach(struct devic * then the IOMMU core will have already configured a group for this * device, and allocated the default domain for that group. */ - if (!domain || iommu_dma_init_domain(domain, dma_base, size, dev)) { - pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n", - dev_name(dev)); - return false; + if (!domain) + goto out_err; + + if (domain->type == IOMMU_DOMAIN_DMA) { + if (iommu_dma_init_domain(domain, dma_base, size, dev)) + goto out_err; + + dev->archdata.dma_ops = &iommu_dma_ops; } - dev->archdata.dma_ops = &iommu_dma_ops; return true; +out_err: + pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n", + dev_name(dev)); + return false; } static void queue_iommu_attach(struct device *dev, const struct iommu_ops *ops, Patches currently in stable-queue which might be from will.deacon(a)arm.com are queue-4.9/iommu-arm-smmu-v3-clear-prior-settings-when-updating-stes.patch queue-4.9/arm64-dma-mapping-only-swizzle-dma-ops-for-iommu_domain_dma.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-omap2plus_defconfig-fix-probe-errors-on-uarts-5-and-6.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Nov 9 09:48:01 CET 2017 From: Tony Lindgren <tony(a)atomide.com> Date: Fri, 20 Jan 2017 12:13:19 -0800 Subject: ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6 From: Tony Lindgren <tony(a)atomide.com> [ Upstream commit 4cd6a59f5c1a9b0cca0da09fbba42b9450ffc899 ] We have more than four uarts on some SoCs and that can cause noise with errors while booting. Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/configs/omap2plus_defconfig | 1 + 1 file changed, 1 insertion(+) --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -216,6 +216,7 @@ CONFIG_SERIO=m CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=32 +CONFIG_SERIAL_8250_RUNTIME_UARTS=6 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y Patches currently in stable-queue which might be from tony(a)atomide.com are queue-4.9/arm-omap2plus_defconfig-fix-probe-errors-on-uarts-5-and-6.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: dts: STiH410-family: fix wrong parent clock frequency" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: STiH410-family: fix wrong parent clock frequency to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-stih410-family-fix-wrong-parent-clock-frequency.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Nov 9 09:48:01 CET 2017 From: Patrice Chotard <patrice.chotard(a)st.com> Date: Fri, 6 Jan 2017 14:30:21 +0100 Subject: ARM: dts: STiH410-family: fix wrong parent clock frequency From: Patrice Chotard <patrice.chotard(a)st.com> [ Upstream commit b9ec866d223f38eb0bf2a7c836e10031ee17f7af ] The clock parent was lower than child clock which is not correct. In some use case, it leads to division by zero. Signed-off-by: Gabriel Fernandez <gabriel.fernandez(a)st.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/stih410.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/boot/dts/stih410.dtsi +++ b/arch/arm/boot/dts/stih410.dtsi @@ -131,7 +131,7 @@ <&clk_s_d2_quadfs 0>; assigned-clock-rates = <297000000>, - <108000000>, + <297000000>, <0>, <400000000>, <400000000>; Patches currently in stable-queue which might be from patrice.chotard(a)st.com are queue-4.9/arm-dts-stih410-family-fix-wrong-parent-clock-frequency.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: dts: imx53-qsb-common: fix FEC pinmux config" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: imx53-qsb-common: fix FEC pinmux config to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Nov 9 09:48:01 CET 2017 From: Patrick Bruenn <p.bruenn(a)beckhoff.com> Date: Wed, 25 Jan 2017 06:25:48 +0100 Subject: ARM: dts: imx53-qsb-common: fix FEC pinmux config From: Patrick Bruenn <p.bruenn(a)beckhoff.com> [ Upstream commit 8b649e426336d7d4800ff9c82858328f4215ba01 ] The pinmux configuration in device tree was different from manual muxing in <u-boot>/board/freescale/mx53loco/mx53loco.c All pins were configured as NO_PAD_CTL(1 << 31), which was fine as the bootloader already did the correct pinmuxing for us. But recently u-boot is migrating to reuse device tree files from the kernel tree, so it seems to be better to have the correct pinmuxing in our files, too. Signed-off-by: Patrick Bruenn <p.bruenn(a)beckhoff.com> Signed-off-by: Shawn Guo <shawnguo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) --- a/arch/arm/boot/dts/imx53-qsb-common.dtsi +++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi @@ -215,16 +215,16 @@ pinctrl_fec: fecgrp { fsl,pins = < - MX53_PAD_FEC_MDC__FEC_MDC 0x80000000 - MX53_PAD_FEC_MDIO__FEC_MDIO 0x80000000 - MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x80000000 - MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x80000000 - MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x80000000 - MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x80000000 - MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x80000000 - MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x80000000 - MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x80000000 - MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x80000000 + MX53_PAD_FEC_MDC__FEC_MDC 0x4 + MX53_PAD_FEC_MDIO__FEC_MDIO 0x1fc + MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 0x180 + MX53_PAD_FEC_RX_ER__FEC_RX_ER 0x180 + MX53_PAD_FEC_CRS_DV__FEC_RX_DV 0x180 + MX53_PAD_FEC_RXD1__FEC_RDATA_1 0x180 + MX53_PAD_FEC_RXD0__FEC_RDATA_0 0x180 + MX53_PAD_FEC_TX_EN__FEC_TX_EN 0x4 + MX53_PAD_FEC_TXD1__FEC_TDATA_1 0x4 + MX53_PAD_FEC_TXD0__FEC_TDATA_0 0x4 >; }; Patches currently in stable-queue which might be from p.bruenn(a)beckhoff.com are queue-4.9/arm-dts-imx53-qsb-common-fix-fec-pinmux-config.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "apparmor: fix undefined reference to `aa_g_hash_policy'" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled apparmor: fix undefined reference to `aa_g_hash_policy' to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: apparmor-fix-undefined-reference-to-aa_g_hash_policy.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Nov 9 09:48:01 CET 2017 From: John Johansen <john.johansen(a)canonical.com> Date: Mon, 16 Jan 2017 13:21:27 -0800 Subject: apparmor: fix undefined reference to `aa_g_hash_policy' From: John Johansen <john.johansen(a)canonical.com> [ Upstream commit 3ccb76c5dfe0d25c1d0168d5b726d0b43d19a485 ] The kernel build bot turned up a bad config combination when CONFIG_SECURITY_APPARMOR is y and CONFIG_SECURITY_APPARMOR_HASH is n, resulting in the build error security/built-in.o: In function `aa_unpack': (.text+0x841e2): undefined reference to `aa_g_hash_policy' Signed-off-by: John Johansen <john.johansen(a)canonical.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/apparmor/lsm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -671,9 +671,9 @@ enum profile_mode aa_g_profile_mode = AP module_param_call(mode, param_set_mode, param_get_mode, &aa_g_profile_mode, S_IRUSR | S_IWUSR); -#ifdef CONFIG_SECURITY_APPARMOR_HASH /* whether policy verification hashing is enabled */ bool aa_g_hash_policy = IS_ENABLED(CONFIG_SECURITY_APPARMOR_HASH_DEFAULT); +#ifdef CONFIG_SECURITY_APPARMOR_HASH module_param_named(hash_policy, aa_g_hash_policy, aabool, S_IRUSR | S_IWUSR); #endif Patches currently in stable-queue which might be from john.johansen(a)canonical.com are queue-4.9/apparmor-fix-undefined-reference-to-aa_g_hash_policy.patch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] Patch "[media] adv7604: Initialize drive strength to default when using DT" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [media] adv7604: Initialize drive strength to default when using DT to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: adv7604-initialize-drive-strength-to-default-when-using-dt.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Nov 9 09:48:01 CET 2017 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Tue, 29 Nov 2016 09:23:48 -0200 Subject: [media] adv7604: Initialize drive strength to default when using DT From: Lars-Peter Clausen <lars(a)metafoo.de> [ Upstream commit da8892d410db224d9a24104529794e6e37e0c100 ] The adv7604 driver platform data contains fields for configuring the drive strength of the output pins. When probing the driver through DT these fields are not explicitly initialized, which means they are left at 0. This is a reserved setting for the drive strength configuration though and can cause signal integrity issues. Whether these signal integrity issues are visible depends on the PCB specifics (e.g. the higher the load capacitance for the output the more visible the issue). But it has been observed on existing solutions at high pixel clock rates. Initialize the drive strength settings to the power-on-reset value of the device when probing through devicetree to avoid this issue. Fixes: 0e158be0162b ("adv7604: Add DT support") Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Tested-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/i2c/adv7604.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -3118,6 +3118,9 @@ static int adv76xx_parse_dt(struct adv76 state->pdata.blank_data = 1; state->pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0; state->pdata.bus_order = ADV7604_BUS_ORDER_RGB; + state->pdata.dr_str_data = ADV76XX_DR_STR_MEDIUM_HIGH; + state->pdata.dr_str_clk = ADV76XX_DR_STR_MEDIUM_HIGH; + state->pdata.dr_str_sync = ADV76XX_DR_STR_MEDIUM_HIGH; return 0; } Patches currently in stable-queue which might be from lars(a)metafoo.de are queue-4.9/adv7604-initialize-drive-strength-to-default-when-using-dt.patch

7 years, 6 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

by Daniel Vetter

On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote: > Ville Syrjälä <ville.syrjala(a)linux.intel.com> writes: > > > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: > >> Ville Syrjala <ville.syrjala(a)linux.intel.com> writes: > >> > >> > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > >> > > >> > Apparently some sinks look at the YQ bits even when receiving RGB, > >> > and they get somehow confused when they see a non-zero YQ value. > >> > So we can't just blindly follow CEA-861-F and set YQ to match the > >> > RGB range. > >> > > >> > Unfortunately there is no good way to tell whether the sink > >> > designer claims to have read CEA-861-F. The CEA extension block > >> > revision number has generally been stuck at 3 since forever, > >> > and even a very recently manufactured sink might be based on > >> > an old design so the manufacturing date doesn't seem like > >> > something we can use. In lieu of better information let's > >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is > >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0. > >> > > >> > The alternative would of course be to always set YQ=0. And if > >> > we ever encounter a HDMI 2.0+ sink with this bug that's what > >> > we'll probably have to do. > >> > >> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4 > >> source? > > > > As long as you stick to < 340 MHz modes you shouldn't have to do > > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features. > > > > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up > > to bridges/encoders to filter out most things that aren't supported? > > I had a patch for that at > https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run > into trouble with 4k monitors. Ack on the clock limiting patch, silly that it's stuck. No idea about CEC, better for Hans/Boris I guess. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH] ALSA: hda - fix headset mic problem for Dell machines with alc274

by Hui Wang

Confirmed with Kailang of Realtek, the pin 0x19 is for Headset Mic, and the pin 0x1a is for Headphone Mic, he suggested to apply ALC269_FIXUP_DELL1_MIC_NO_PRESENCE to fix this problem. And we verified applying this FIXUP can fix this problem. Cc: <stable(a)vger.kernel.org> Cc: Kailang Yang <kailang(a)realtek.com> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 9b77d43..db1a376 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6568,6 +6568,11 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = { {0x14, 0x90170110}, {0x1b, 0x90a70130}, {0x21, 0x03211020}), + SND_HDA_PIN_QUIRK(0x10ec0274, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0xb7a60130}, + {0x13, 0xb8a61140}, + {0x16, 0x90170110}, + {0x21, 0x04211020}), SND_HDA_PIN_QUIRK(0x10ec0280, 0x103c, "HP", ALC280_FIXUP_HP_GPIO4, {0x12, 0x90a60130}, {0x14, 0x90170110}, -- 2.7.4

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] [PATCH 2/2] ARM: mm: dump: check hardware RO bit for LPAE

by Philip Derrin

When CONFIG_ARM_LPAE is set, the PMD dump relies on the software read-only bit to determine whether a page is writable. This concealed a bug which left the kernel text section writable (AP2=0) while marked read-only in the software bit. In a kernel with the AP2 bug, the dump looks like this: ---[ Kernel Mapping ]--- 0xc0000000-0xc0200000 2M RW NX SHD 0xc0200000-0xc0600000 4M ro x SHD 0xc0600000-0xc0800000 2M ro NX SHD 0xc0800000-0xc4800000 64M RW NX SHD The fix is to check that the software and hardware bits are both set before displaying "ro". The dump then shows the true perms: ---[ Kernel Mapping ]--- 0xc0000000-0xc0200000 2M RW NX SHD 0xc0200000-0xc0600000 4M RW x SHD 0xc0600000-0xc0800000 2M RW NX SHD 0xc0800000-0xc4800000 64M RW NX SHD Fixes: ded947798469 ("ARM: 8109/1: mm: Modify pte_write and pmd_write logic for LPAE") Signed-off-by: Philip Derrin <philip(a)cog.systems> Tested-by: Neil Dick <neil(a)cog.systems> Cc: stable(a)vger.kernel.org --- arch/arm/mm/dump.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c index 35ff45470dbf..fc3b44028cfb 100644 --- a/arch/arm/mm/dump.c +++ b/arch/arm/mm/dump.c @@ -129,8 +129,8 @@ static const struct prot_bits section_bits[] = { .val = PMD_SECT_USER, .set = "USR", }, { - .mask = L_PMD_SECT_RDONLY, - .val = L_PMD_SECT_RDONLY, + .mask = L_PMD_SECT_RDONLY | PMD_SECT_AP2, + .val = L_PMD_SECT_RDONLY | PMD_SECT_AP2, .set = "ro", .clear = "RW", #elif __LINUX_ARM_ARCH__ >= 6 -- 2.15.0

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/2] ARM: mm: make STRICT_KERNEL_RWX effective for LPAE

by Philip Derrin

Currently, for ARM kernels with CONFIG_ARM_LPAE and CONFIG_STRICT_KERNEL_RWX enabled, the 2MiB pages mapping the kernel code and rodata are writable. They are marked read-only in a software bit (L_PMD_SECT_RDONLY) but the hardware read-only bit is not set (PMD_SECT_AP2). For user mappings, the logic that propagates the software bit to the hardware bit is in set_pmd_at(); but for the kernel, section_update() writes the PMDs directly, skipping this logic. The fix is to set PMD_SECT_AP2 for read-only sections in section_update(), at the same time as L_PMD_SECT_RDONLY. Fixes: 1e3479225acb ("ARM: 8275/1: mm: fix PMD_SECT_RDONLY undeclared compile error") Signed-off-by: Philip Derrin <philip(a)cog.systems> Reported-by: Neil Dick <neil(a)cog.systems> Tested-by: Neil Dick <neil(a)cog.systems> Tested-by: Laura Abbott <labbott(a)redhat.com> Cc: stable(a)vger.kernel.org --- arch/arm/mm/init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index ad80548325fe..0f6d1537f330 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -639,8 +639,8 @@ static struct section_perm ro_perms[] = { .start = (unsigned long)_stext, .end = (unsigned long)__init_begin, #ifdef CONFIG_ARM_LPAE - .mask = ~L_PMD_SECT_RDONLY, - .prot = L_PMD_SECT_RDONLY, + .mask = ~(L_PMD_SECT_RDONLY | PMD_SECT_AP2), + .prot = L_PMD_SECT_RDONLY | PMD_SECT_AP2, #else .mask = ~(PMD_SECT_APX | PMD_SECT_AP_WRITE), .prot = PMD_SECT_APX | PMD_SECT_AP_WRITE, -- 2.15.0

7 years, 6 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH AUTOSEL for-4.9 04/53] spi: imx: adjust watermark level according to transfer length

by Levin, Alexander (Sasha Levin)

On Wed, Nov 08, 2017 at 11:11:11PM +0000, Mark Brown wrote: >On Wed, Nov 08, 2017 at 10:48:14PM +0000, Levin, Alexander (Sasha Levin) wrote: >> On Wed, Nov 08, 2017 at 10:11:02PM +0000, Mark Brown wrote: > >> >expose problems if we start using it. If you look at the history of the >> >driver there's some quirks were added later on for example, and I didn't >> >check the DMA controller drivers or anything and obviously can't see any >> >out of tree code users may have. > >> I'm considering these commits to be on the safer side because they're >> much older than the ones Greg usually grabs. There were no upstream >> fixes to this commit for 10 months now, and given the code changes >> upstream in that subsystem, this patch seemed to be safe to backport. > >Like I say I'm seeing some potentially relevant variant handling added >later and you also have to consider the DMA drivers it might be used >with (imx-dma looks safe but perhaps there's other things, never mind >out of tree code). It just doesn't feel good. > >We have also had problems in the past with SPI performance enhancements >exposing exising problems elsewhere though not so much with this sort of >area so I'm less worried about that. Sure, I'll drop it. Thanks! -- Thanks, Sasha

7 years, 6 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH AUTOSEL for-4.9 04/53] spi: imx: adjust watermark level according to transfer length

by Levin, Alexander (Sasha Levin)

On Wed, Nov 08, 2017 at 10:11:02PM +0000, Mark Brown wrote: >On Wed, Nov 08, 2017 at 09:39:11PM +0000, Levin, Alexander (Sasha Levin) wrote: >> >On Wed, Nov 08, 2017 at 08:49:55PM +0000, Levin, Alexander (Sasha Levin) wrote: >> >This seems like an optimization not a bug fix... > >> Hm, is it? I read it as "DMA is not being used at all even though we >> thought we're using it". > >Yes, that's how I read it too. > >> Yes, the impact is "just" performance, but doesn't it result in quite >> a significat impact? > >Only about double according to the initial commit adding DMA support >which is frankly a bit disappointing although yeah, it's a big win. My >worry is that if there's a problem with DMA on some device for which a >fix wasn't backported (or where we're using a fallback) this could >expose problems if we start using it. If you look at the history of the >driver there's some quirks were added later on for example, and I didn't >check the DMA controller drivers or anything and obviously can't see any >out of tree code users may have. > >*Probably* it doesn't break anything but since it's not fixing anything >and the risk is data corruption I'd be much more comfortable with a more >thorough risk analysis. I'm considering these commits to be on the safer side because they're much older than the ones Greg usually grabs. There were no upstream fixes to this commit for 10 months now, and given the code changes upstream in that subsystem, this patch seemed to be safe to backport. -- Thanks, Sasha

7 years, 6 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH AUTOSEL for-4.9 04/53] spi: imx: adjust watermark level according to transfer length

by Levin, Alexander (Sasha Levin)

On Wed, Nov 08, 2017 at 08:57:52PM +0000, Mark Brown wrote: >On Wed, Nov 08, 2017 at 08:49:55PM +0000, Levin, Alexander (Sasha Levin) wrote: >> From: Jiada Wang <jiada_wang(a)mentor.com> >> >> [ Upstream commit 66459c5a50a787c474b734b586328f7111ab6df0 ] >> >> Previously DMA watermark level is configured to fifosize/2, >> DMA mode can be used only when transfer length can be divided >> by 'watermark level * bpw', which makes DMA mode not pratical. >> >> This patch adjusts watermark level to largest number (no bigger >> than fifosize/2) which can divide 'tranfer length / bpw' for >> each transfer. > >This seems like an optimization not a bug fix... Hm, is it? I read it as "DMA is not being used at all even though we thought we're using it". Yes, the impact is "just" performance, but doesn't it result in quite a significat impact? -- Thanks, Sasha

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH 3/3] ASoC: sun8i-codec: Fix left and right channels inversion

by Maxime Ripard

Since its introduction, the codec had an inversion of the left and right channels. It turned out to be pretty simple as it appears that the codec doesn't have the same polarity on the LRCK signal than the I2S block. Fix this by inverting our bit value for the LRCK inversion. Fixes: 36c684936fae ("ASoC: Add sun8i digital audio codec") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> --- sound/soc/sunxi/sun8i-codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c index 522546e6b153..c8dcb1502d74 100644 --- a/sound/soc/sunxi/sun8i-codec.c +++ b/sound/soc/sunxi/sun8i-codec.c @@ -200,7 +200,7 @@ static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) value << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV); regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL, BIT(SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV), - value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV); + !value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV); /* DAI format */ switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) { -- 2.14.3

7 years, 6 months

3
2
0 0

[Linux-stable-mirror] v4.9.61 build: 0 failures 0 warnings (v4.9.61)

by Build bot for Mark Brown

Tree/Branch: v4.9.61 Git describe: v4.9.61 Commit: 5caae9d141 Linux 4.9.61 Build Time: 82 min 53 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for-3.18 01/27] extcon: palmas: Check the parent instance to prevent the NULL

by Levin, Alexander (Sasha Levin)

From: Roger Quadros <rogerq(a)ti.com> [ Upstream commit 9fe172b9be532acc23e35ba693700383ab775e66 ] extcon-palmas must be child of palmas and expects parent's drvdata to be valid. Check for non NULL parent drvdata and fail if it is NULL. Not doing so will result in a NULL pointer dereference later in the probe() parent drvdata is NULL (e.g. misplaced extcon-palmas node in device tree). Signed-off-by: Roger Quadros <rogerq(a)ti.com> Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- drivers/extcon/extcon-palmas.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c index 230e1220ce48..1cee9f4909db 100644 --- a/drivers/extcon/extcon-palmas.c +++ b/drivers/extcon/extcon-palmas.c @@ -150,6 +150,11 @@ static int palmas_usb_probe(struct platform_device *pdev) struct palmas_usb *palmas_usb; int status; + if (!palmas) { + dev_err(&pdev->dev, "failed to get valid parent\n"); + return -EINVAL; + } + palmas_usb = devm_kzalloc(&pdev->dev, sizeof(*palmas_usb), GFP_KERNEL); if (!palmas_usb) return -ENOMEM; -- 2.11.0

7 years, 6 months

1
26
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for-4.9 01/53] extcon: Remove potential problem when calling extcon_register_notifier()

by Levin, Alexander (Sasha Levin)

From: Chanwoo Choi <cw00.choi(a)samsung.com> [ Upstream commit 01b4c9a1ae07a25d208cad0da7dd288007a22984 ] This patch removes the potential problem of extcon_register_notifier() when edev parameter is NULL. When edev is NULL, this function returns the first extcon device which includes the sepecific external connector of second paramter. But, it don't guarantee the same operation in all cases. To remove this confusion and potential problem, this patch fixes it. Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- drivers/extcon/extcon.c | 33 +++++++-------------------------- 1 file changed, 7 insertions(+), 26 deletions(-) diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c index 7c1e3a7b14e0..d0e367959c91 100644 --- a/drivers/extcon/extcon.c +++ b/drivers/extcon/extcon.c @@ -906,35 +906,16 @@ int extcon_register_notifier(struct extcon_dev *edev, unsigned int id, unsigned long flags; int ret, idx = -EINVAL; - if (!nb) + if (!edev || !nb) return -EINVAL; - if (edev) { - idx = find_cable_index_by_id(edev, id); - if (idx < 0) - return idx; - - spin_lock_irqsave(&edev->lock, flags); - ret = raw_notifier_chain_register(&edev->nh[idx], nb); - spin_unlock_irqrestore(&edev->lock, flags); - } else { - struct extcon_dev *extd; - - mutex_lock(&extcon_dev_list_lock); - list_for_each_entry(extd, &extcon_dev_list, entry) { - idx = find_cable_index_by_id(extd, id); - if (idx >= 0) - break; - } - mutex_unlock(&extcon_dev_list_lock); + idx = find_cable_index_by_id(edev, id); + if (idx < 0) + return idx; - if (idx >= 0) { - edev = extd; - return extcon_register_notifier(extd, id, nb); - } else { - ret = -ENODEV; - } - } + spin_lock_irqsave(&edev->lock, flags); + ret = raw_notifier_chain_register(&edev->nh[idx], nb); + spin_unlock_irqrestore(&edev->lock, flags); return ret; } -- 2.11.0

7 years, 6 months

1
52
0 0

Re: [Linux-stable-mirror] [PATCH v2] lib/mpi: call cond_resched() from mpi_powm() loop

by David Howells

Eric Biggers <ebiggers3(a)gmail.com> wrote: > On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the > largest permitted inputs (16384 bits), the kernel spends 10+ seconds > doing modular exponentiation in mpi_powm() without rescheduling. If all > threads do it, it locks up the system. Moreover, it can cause > rcu_sched-stall warnings. Do you want this to go in immediately, or I should I push it to James for the next merge window? David

7 years, 6 months

3
4
0 0

Re: [Linux-stable-mirror] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

by Ville Syrjälä

On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: > Ville Syrjala <ville.syrjala(a)linux.intel.com> writes: > > > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > > > > Apparently some sinks look at the YQ bits even when receiving RGB, > > and they get somehow confused when they see a non-zero YQ value. > > So we can't just blindly follow CEA-861-F and set YQ to match the > > RGB range. > > > > Unfortunately there is no good way to tell whether the sink > > designer claims to have read CEA-861-F. The CEA extension block > > revision number has generally been stuck at 3 since forever, > > and even a very recently manufactured sink might be based on > > an old design so the manufacturing date doesn't seem like > > something we can use. In lieu of better information let's > > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is > > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0. > > > > The alternative would of course be to always set YQ=0. And if > > we ever encounter a HDMI 2.0+ sink with this bug that's what > > we'll probably have to do. > > Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4 > source? As long as you stick to < 340 MHz modes you shouldn't have to do anything. For >=340 MHz you'd need to use some new HDMI 2.0 features. Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up to bridges/encoders to filter out most things that aren't supported? > > That said, as far as vc4, this patch is > > Acked-by: Eric Anholt <eric(a)anholt.net> Ta. -- Ville Syrjälä Intel OTC

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] v4.4.97 build: 0 failures 0 warnings (v4.4.97)

by Build bot for Mark Brown

Tree/Branch: v4.4.97 Git describe: v4.4.97 Commit: c54d0707aa Linux 4.4.97 Build Time: 71 min 11 sec Passed: 9 / 9 (100.00 %) Failed: 0 / 9 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/3] ASoC: sun8i-codec: Invert Master / Slave condition

by Maxime Ripard

The current code had the condition backward when checking if the codec should be running in slave or master mode. Fix it, and make the comment a bit more readable. Fixes: 36c684936fae ("ASoC: Add sun8i digital audio codec") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> --- sound/soc/sunxi/sun8i-codec.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c index abfb710df7cb..038107baf414 100644 --- a/sound/soc/sunxi/sun8i-codec.c +++ b/sound/soc/sunxi/sun8i-codec.c @@ -170,11 +170,11 @@ static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) /* clock masters */ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { - case SND_SOC_DAIFMT_CBS_CFS: /* DAI Slave */ - value = 0x0; /* Codec Master */ + case SND_SOC_DAIFMT_CBS_CFS: /* Codec slave, DAI master */ + value = 0x1; break; - case SND_SOC_DAIFMT_CBM_CFM: /* DAI Master */ - value = 0x1; /* Codec Slave */ + case SND_SOC_DAIFMT_CBM_CFM: /* Codec Master, DAI slave */ + value = 0x0; break; default: return -EINVAL; -- 2.14.3

7 years, 6 months

3
2
0 0

[Linux-stable-mirror] [PATCH v2] drm/i915: Move init_clock_gating() back to where it was

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Apparently setting up a bunch of GT registers before we've properly initialized the rest of the GT hardware leads to these setting being lost. So looks like I broke HSW with commit b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") by doing init_clock_gating() too early. This should actually affect other platforms as well, but apparently not to such a great degree. What I was ultimately after in that commit was to move the ilk_init_lp_watermarks() call earlier. So let's undo the damage and move init_clock_gating() back to where it was, and call ilk_init_lp_watermarks() just before the watermark state readout. This highlights how fragile and messed up our init order really is. I wonder why we even initialize the display before gem. The opposite order would make much more sense to me... v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must be done before all planes might get disabled. Cc: stable(a)vger.kernel.org Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Mark Janes <mark.a.janes(a)intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Oscar Mateo <oscar.mateo(a)intel.com> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Reported-by: Mark Janes <mark.a.janes(a)intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549 Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks") References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/intel_display.c | 14 ++++++++++-- drivers/gpu/drm/i915/intel_pm.c | 44 +++++++++++++++--------------------- 2 files changed, 30 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 737de251d0f8..8174392acc18 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3676,6 +3676,7 @@ void intel_finish_reset(struct drm_i915_private *dev_priv) intel_pps_unlock_regs_wa(dev_priv); intel_modeset_init_hw(dev); + intel_init_clock_gating(dev_priv); spin_lock_irq(&dev_priv->irq_lock); if (dev_priv->display.hpd_irq_setup) @@ -14365,8 +14366,6 @@ void intel_modeset_init_hw(struct drm_device *dev) intel_update_cdclk(dev_priv); intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK"); dev_priv->cdclk.logical = dev_priv->cdclk.actual = dev_priv->cdclk.hw; - - intel_init_clock_gating(dev_priv); } /* @@ -15079,6 +15078,15 @@ intel_modeset_setup_hw_state(struct drm_device *dev, struct intel_encoder *encoder; int i; + if (IS_HASWELL(dev_priv)) { + /* + * WaRsPkgCStateDisplayPMReq:hsw + * System hang if this isn't done before disabling all planes! + */ + I915_WRITE(CHICKEN_PAR1_1, + I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES); + } + intel_modeset_readout_hw_state(dev); /* HW state is read out, now we need to sanitize this mess. */ @@ -15176,6 +15184,8 @@ void intel_modeset_gem_init(struct drm_device *dev) intel_init_gt_powersave(dev_priv); + intel_init_clock_gating(dev_priv); + intel_setup_overlay(dev_priv); } diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 07118c0b69d3..b712ee30a06c 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5754,12 +5754,30 @@ void vlv_wm_sanitize(struct drm_i915_private *dev_priv) mutex_unlock(&dev_priv->wm.wm_mutex); } +/* + * FIXME should probably kill this and improve + * the real watermark readout/sanitation instead + */ +static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv) +{ + I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN); + I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN); + I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN); + + /* + * Don't touch WM1S_LP_EN here. + * Doing so could cause underruns. + */ +} + void ilk_wm_get_hw_state(struct drm_device *dev) { struct drm_i915_private *dev_priv = to_i915(dev); struct ilk_wm_values *hw = &dev_priv->wm.hw; struct drm_crtc *crtc; + ilk_init_lp_watermarks(dev_priv); + for_each_crtc(dev, crtc) ilk_pipe_wm_get_hw_state(crtc); @@ -8213,18 +8231,6 @@ static void g4x_disable_trickle_feed(struct drm_i915_private *dev_priv) } } -static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv) -{ - I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN); - I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN); - I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN); - - /* - * Don't touch WM1S_LP_EN here. - * Doing so could cause underruns. - */ -} - static void ilk_init_clock_gating(struct drm_i915_private *dev_priv) { uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE; @@ -8258,8 +8264,6 @@ static void ilk_init_clock_gating(struct drm_i915_private *dev_priv) (I915_READ(DISP_ARB_CTL) | DISP_FBC_WM_DIS)); - ilk_init_lp_watermarks(dev_priv); - /* * Based on the document from hardware guys the following bits * should be set unconditionally in order to enable FBC. @@ -8372,8 +8376,6 @@ static void gen6_init_clock_gating(struct drm_i915_private *dev_priv) I915_WRITE(GEN6_GT_MODE, _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4)); - ilk_init_lp_watermarks(dev_priv); - I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB)); @@ -8600,8 +8602,6 @@ static void bdw_init_clock_gating(struct drm_i915_private *dev_priv) I915_GTT_PAGE_SIZE_2M); enum pipe pipe; - ilk_init_lp_watermarks(dev_priv); - /* WaSwitchSolVfFArbitrationPriority:bdw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); @@ -8652,8 +8652,6 @@ static void bdw_init_clock_gating(struct drm_i915_private *dev_priv) static void hsw_init_clock_gating(struct drm_i915_private *dev_priv) { - ilk_init_lp_watermarks(dev_priv); - /* L3 caching of data atomics doesn't work -- disable it. */ I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE); I915_WRITE(HSW_ROW_CHICKEN3, @@ -8697,10 +8695,6 @@ static void hsw_init_clock_gating(struct drm_i915_private *dev_priv) /* WaSwitchSolVfFArbitrationPriority:hsw */ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL); - /* WaRsPkgCStateDisplayPMReq:hsw */ - I915_WRITE(CHICKEN_PAR1_1, - I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES); - lpt_init_clock_gating(dev_priv); } @@ -8708,8 +8702,6 @@ static void ivb_init_clock_gating(struct drm_i915_private *dev_priv) { uint32_t snpcr; - ilk_init_lp_watermarks(dev_priv); - I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE); /* WaDisableEarlyCull:ivb */ -- 2.13.6

7 years, 6 months

3
3
0 0

[Linux-stable-mirror] [PATCH 2/3] ASoC: sun8i-codec: Set the BCLK divider

by Maxime Ripard

While the current code was reporting to be able to work in master mode, it failed to do so because the BCLK divider wasn't programmed, meaning that the BCLK would run at the PLL's frequency no matter the sample rate. It was obviously a bit too fast. Add support to retrieve the divider to use, and set it. Since our PLL is not always able to generate a perfect multiple of the sample rate, we'll have to choose the closest divider that matches our setup. Fixes: 36c684936fae ("ASoC: Add sun8i digital audio codec") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> --- sound/soc/sunxi/sun8i-codec.c | 53 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c index 038107baf414..522546e6b153 100644 --- a/sound/soc/sunxi/sun8i-codec.c +++ b/sound/soc/sunxi/sun8i-codec.c @@ -73,6 +73,7 @@ #define SUN8I_SYS_SR_CTRL_AIF2_FS_MASK GENMASK(11, 8) #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_MASK GENMASK(5, 4) #define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_MASK GENMASK(8, 6) +#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV_MASK GENMASK(12, 9) struct sun8i_codec { struct device *dev; @@ -226,12 +227,57 @@ static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) return 0; } +struct sun8i_codec_clk_div { + u8 div; + u8 val; +}; + +static const struct sun8i_codec_clk_div sun8i_codec_bclk_div[] = { + { .div = 1, .val = 0 }, + { .div = 2, .val = 1 }, + { .div = 4, .val = 2 }, + { .div = 6, .val = 3 }, + { .div = 8, .val = 4 }, + { .div = 12, .val = 5 }, + { .div = 16, .val = 6 }, + { .div = 24, .val = 7 }, + { .div = 32, .val = 8 }, + { .div = 48, .val = 9 }, + { .div = 64, .val = 10 }, + { .div = 96, .val = 11 }, + { .div = 128, .val = 12 }, + { .div = 192, .val = 13 }, +}; + +static u8 sun8i_codec_get_bclk_div(struct sun8i_codec *scodec, + unsigned int rate, + unsigned int word_size) +{ + unsigned long clk_rate = clk_get_rate(scodec->clk_module); + unsigned int div = clk_rate / rate / word_size / 2; + unsigned int best_val = 0, best_diff = ~0; + int i; + + for (i = 0; i < ARRAY_SIZE(sun8i_codec_bclk_div); i++) { + const struct sun8i_codec_clk_div *bdiv = &sun8i_codec_bclk_div[i]; + unsigned int diff = abs(bdiv->div - div); + + if (diff < best_diff) { + best_diff = diff; + best_val = bdiv->val; + } + } + + return best_val; +} + static int sun8i_codec_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params, struct snd_soc_dai *dai) { struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec); int sample_rate; + u8 bclk_div; /* * The CPU DAI handles only a sample of 16 bits. Configure the @@ -241,6 +287,13 @@ static int sun8i_codec_hw_params(struct snd_pcm_substream *substream, SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_MASK, SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16); + bclk_div = sun8i_codec_get_bclk_div(scodec, params_rate(params), + params_width(params)); + + regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL, + SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV_MASK, + bclk_div << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV); + regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL, SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_MASK, SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_16); -- 2.14.3

7 years, 6 months

2
1
0 0

[Linux-stable-mirror] v4.13.12 build: 0 failures 0 warnings (v4.13.12)

by Build bot for Mark Brown

Tree/Branch: v4.13.12 Git describe: v4.13.12 Commit: 0da74753f7 Linux 4.13.12 Build Time: 92 min 4 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 6 months

1
0
0 0

[Linux-stable-mirror] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Apparently some sinks look at the YQ bits even when receiving RGB, and they get somehow confused when they see a non-zero YQ value. So we can't just blindly follow CEA-861-F and set YQ to match the RGB range. Unfortunately there is no good way to tell whether the sink designer claims to have read CEA-861-F. The CEA extension block revision number has generally been stuck at 3 since forever, and even a very recently manufactured sink might be based on an old design so the manufacturing date doesn't seem like something we can use. In lieu of better information let's follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0. The alternative would of course be to always set YQ=0. And if we ever encounter a HDMI 2.0+ sink with this bug that's what we'll probably have to do. Cc: stable(a)vger.kernel.org Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: Eric Anholt <eric(a)anholt.net> Cc: Neil Kownacki <njkkow(a)gmail.com> Reported-by: Neil Kownacki <njkkow(a)gmail.com> Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639 Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_edid.c | 12 ++++++++++-- drivers/gpu/drm/i915/intel_hdmi.c | 3 ++- drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++- include/drm/drm_edid.h | 3 ++- 4 files changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 749d07a01772..8567890f47a7 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4838,7 +4838,8 @@ void drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, const struct drm_display_mode *mode, enum hdmi_quantization_range rgb_quant_range, - bool rgb_quant_range_selectable) + bool rgb_quant_range_selectable, + bool is_hdmi2_sink) { /* * CEA-861: @@ -4862,8 +4863,15 @@ drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, * YQ-field to match the RGB Quantization Range being transmitted * (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, * set YQ=1) and the Sink shall ignore the YQ-field." + * + * Unfortunate certain sinks (eg. VIZ Model 67/E261VA) get confused + * by non-zero YQ when receiving RGB. There doesn't seem to be any + * good way to tell which version of CEA-861 the sink supports, so + * we limit non-zero YQ to HDMI 2.0 sinks only as HDMI 2.0 is based + * on on CEA-861-F. */ - if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED) + if (!is_hdmi2_sink || + rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED) frame->ycc_quantization_range = HDMI_YCC_QUANTIZATION_RANGE_LIMITED; else diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index fa1c793a21ef..2b23d3662eec 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -487,7 +487,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder, crtc_state->limited_color_range ? HDMI_QUANTIZATION_RANGE_LIMITED : HDMI_QUANTIZATION_RANGE_FULL, - intel_hdmi->rgb_quant_range_selectable); + intel_hdmi->rgb_quant_range_selectable, + is_hdmi2_sink); /* TODO: handle pixel repetition for YCBCR420 outputs */ intel_write_infoframe(encoder, crtc_state, &frame); diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 9a9a6b4acccf..d645df0c6d15 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -423,7 +423,8 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder *encoder) vc4_encoder->limited_rgb_range ? HDMI_QUANTIZATION_RANGE_LIMITED : HDMI_QUANTIZATION_RANGE_FULL, - vc4_encoder->rgb_range_selectable); + vc4_encoder->rgb_range_selectable, + false); vc4_hdmi_write_infoframe(encoder, &frame); } diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index 9e4e23524840..58ffb68efdc5 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -361,7 +361,8 @@ void drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame, const struct drm_display_mode *mode, enum hdmi_quantization_range rgb_quant_range, - bool rgb_quant_range_selectable); + bool rgb_quant_range_selectable, + bool is_hdmi2_sink); /** * drm_eld_mnl - Get ELD monitor name length in bytes. -- 2.13.6

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror