* [PATCH 3/3] EDAC: armada_xp: Add support for more SoCs
From: Chris Packham @ 2018-01-08 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108223158.21930-1-chris.packham@alliedtelesis.co.nz>
The Armada 38x and other integrated SoCs use a reduced pin count so the
width of the SDRAM interface is smaller than the Armada XP SoCs. This
means that the definition of "full" and "half" width is reduced from
64/32 to 32/16.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
drivers/edac/armada_xp_edac.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
index cb9173b30aa9..40cef261e61b 100644
--- a/drivers/edac/armada_xp_edac.c
+++ b/drivers/edac/armada_xp_edac.c
@@ -347,6 +347,11 @@ static int armada_xp_mc_edac_probe(struct platform_device *pdev)
armada_xp_mc_edac_read_config(mci);
+ /* These SoCs have a reduced width bus */
+ if (of_machine_is_compatible("marvell,armada380") ||
+ of_machine_is_compatible("marvell,armadaxp-98dx3236"))
+ drvdata->width /= 2;
+
/* configure SBE threshold */
/* it seems that SBEs are not captured otherwise */
writel(1 << SDRAM_ERR_CTRL_ERR_THR_OFFSET,
--
2.15.1
^ permalink raw reply related
* [PATCH] arm: omap2: timer: fix a kmemleak caused in omap_get_timer_dt
From: kbuild test robot @ 2018-01-08 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515373733-3658-1-git-send-email-qi.hou@windriver.com>
Hi Qi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on omap/for-next]
[also build test WARNING on v4.15-rc7 next-20180108]
[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/Qi-Hou/arm-omap2-timer-fix-a-kmemleak-caused-in-omap_get_timer_dt/20180109-033316
base: https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git for-next
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
arch/arm/mach-omap2/timer.c: In function 'omap_get_timer_dt':
>> arch/arm/mach-omap2/timer.c:205:12: warning: return makes pointer from integer without a cast [-Wint-conversion]
return -ENOMEM;
^
vim +205 arch/arm/mach-omap2/timer.c
170
171 /**
172 * omap_get_timer_dt - get a timer using device-tree
173 * @match - device-tree match structure for matching a device type
174 * @property - optional timer property to match
175 *
176 * Helper function to get a timer during early boot using device-tree for use
177 * as kernel system timer. Optionally, the property argument can be used to
178 * select a timer with a specific property. Once a timer is found then mark
179 * the timer node in device-tree as disabled, to prevent the kernel from
180 * registering this timer as a platform device and so no one else can use it.
181 */
182 static struct device_node * __init omap_get_timer_dt(const struct of_device_id *match,
183 const char *property)
184 {
185 struct device_node *np;
186
187 for_each_matching_node(np, match) {
188 if (!of_device_is_available(np))
189 continue;
190
191 if (property && !of_get_property(np, property, NULL))
192 continue;
193
194 if (!property && (of_get_property(np, "ti,timer-alwon", NULL) ||
195 of_get_property(np, "ti,timer-dsp", NULL) ||
196 of_get_property(np, "ti,timer-pwm", NULL) ||
197 of_get_property(np, "ti,timer-secure", NULL)))
198 continue;
199
200 if (!of_device_is_compatible(np, "ti,omap-counter32k")) {
201 struct property *prop;
202
203 prop = kzalloc(sizeof(*prop), GFP_KERNEL);
204 if (!prop)
> 205 return -ENOMEM;
206 prop->name = "status";
207 prop->length = sizeof("disabled");
208 prop->value = "disabled";
209 of_add_property(np, prop);
210 }
211 return np;
212 }
213
214 return NULL;
215 }
216
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33066 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180109/116fcc7a/attachment-0001.gz>
^ permalink raw reply
* [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero
From: Kani, Toshi @ 2018-01-08 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0fa1b52-86f5-687e-46b3-78ddd03565d8@huawei.com>
On Sat, 2018-01-06 at 17:46 +0800, Hanjun Guo wrote:
> On 2018/1/6 6:15, Kani, Toshi wrote:
> > On Thu, 2017-12-28 at 19:24 +0800, Hanjun Guo wrote:
> > > From: Hanjun Guo <hanjun.guo@linaro.org>
> > >
> > > When we using iounmap() to free the 4K mapping, it just clear the PTEs
> > > but leave P4D/PUD/PMD unchanged, also will not free the memory of page
> > > tables.
> > >
> > > This will cause issues on ARM64 platform (not sure if other archs have
> > > the same issue) for this case:
> > >
> > > 1. ioremap a 4K size, valid page table will build,
> > > 2. iounmap it, pte0 will set to 0;
> > > 3. ioremap the same address with 2M size, pgd/pmd is unchanged,
> > > then set the a new value for pmd;
> > > 4. pte0 is leaked;
> > > 5. CPU may meet exception because the old pmd is still in TLB,
> > > which will lead to kernel panic.
> > >
> > > Fix it by skip setting up the huge I/O mappings when p4d/pud/pmd is
> > > zero.
> >
> > Hi Hanjun,
> >
> > I tested the above steps on my x86 box, but was not able to reproduce
> > your kernel panic. On x86, a 4K vaddr gets allocated from a small
> > fragmented free range, whereas a 2MB vaddr is from a larger free range.
> > Their addrs have different alignments (4KB & 2MB) as well. So, the
> > steps did not lead to use a same pmd entry.
>
> Thanks for the testing, I can only reproduce this on my ARM64 platform
> which the CPU will cache the PMD in TLB, from my knowledge, only Cortex-A75
> will do this, so ARM64 platforms which are not A75 based can't be reproduced
> either.
>
> Catalin, Will, I can reproduce this issue in about 3 minutes with following
> simplified test case [1], and can trigger panic as [2], could you take a look
> as well?
Yes, the test case looks good to me. (nit - it should check if vir_addr
is not NULL.)
> > However, I agree that zero'd pte entries will be leaked when a pmd map
> > is set if they are present under the pmd.
>
> Thanks for the confirm.
>
> >
> > I also tested your patch on my x86 box. Unfortunately, it effectively
> > disabled 2MB mappings. While a 2MB vaddr gets allocated from a larger
> > free range, it sill comes from a free range covered by zero'd pte
> > entries. So, it ends up with 4KB mappings with your changes.
> >
> > I think we need to come up with other approach.
>
> Yes, As I said in my patch, this is just RFC, comments are welcomed :)
I am wondering if we can follow the same approach in
arch/x86/mm/pageattr.c. Like the ioremap case, populate_pmd() does not
check if there is a pte table under the pmd. But its free function,
unmap_pte_range() calls try_to_free_pte_page() so that a pte table is
freed when all pte entries are zero'd. It then calls pmd_clear().
iounmap()'s free function, vunmap_pte_range() does not free up a pte
table even if all pte entries are zero'd.
Thanks,
-Toshi
^ permalink raw reply
* [PATCH] ASoC: rockchip: i2s: Support mono capture
From: Matthias Kaehlcke @ 2018-01-09 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105221242.22083-1-mka@chromium.org>
El Fri, Jan 05, 2018 at 02:12:42PM -0800 Matthias Kaehlcke ha dit:
> The Rockchip I2S controller only allows to configure even numbers of
> capture channels. It is still possible to capture monophonic audio by
> using dual-channel mode and ignoring the 'data' from the second
> channel.
Due to different issues in our audio recording path I couldn't test
this properly, and only looked at the .wav data in audacity, which
appeared to look ok. After putting some of the missing pieces
together and I noticed that mono capture doesn't work as intended,
the recorded audio is slowed down. I think this is because the I2S
controller keeps generating a two-channel stream, however the sound
system interprets it as a monophonic stream because of the channel
configuration.
Not sure if there is a clean solution for this if we can't tell the
hardware to generate a single-channel stream. Any suggestions or do
we have to revert the patch?
Sorry about the mess :(
> ---
> sound/soc/rockchip/rockchip_i2s.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
> index 908211e1d6fc..cc22ab3d10dd 100644
> --- a/sound/soc/rockchip/rockchip_i2s.c
> +++ b/sound/soc/rockchip/rockchip_i2s.c
> @@ -328,6 +328,7 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream *substream,
> val |= I2S_CHN_4;
> break;
> case 2:
> + case 1:
> val |= I2S_CHN_2;
> break;
> default:
> @@ -460,7 +461,7 @@ static struct snd_soc_dai_driver rockchip_i2s_dai = {
> },
> .capture = {
> .stream_name = "Capture",
> - .channels_min = 2,
> + .channels_min = 1,
> .channels_max = 2,
> .rates = SNDRV_PCM_RATE_8000_192000,
> .formats = (SNDRV_PCM_FMTBIT_S8 |
> @@ -654,7 +655,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
> }
>
> if (!of_property_read_u32(node, "rockchip,capture-channels", &val)) {
> - if (val >= 2 && val <= 8)
> + if (val >= 1 && val <= 8)
> soc_dai->capture.channels_max = val;
> }
>
^ permalink raw reply
* [PATCH] ARM: dts: qcom: Add initial DTS file for Samsung Galaxy S5 phone
From: Daniele Debernardi @ 2018-01-09 1:15 UTC (permalink / raw)
To: linux-arm-kernel
This DTS has support for the Samsung Galaxy S5 (codenamed klte).
Initial version have support just for serial console.
Cc: Andy Gross <andy.gross@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: David Brown <david.brown@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-arm-msm at vger.kernel.org
Signed-off-by: Daniele Debernardi <drebrez@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts | 24 ++++++++++++++++++++++++
2 files changed, 25 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9..abb0ab1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -729,6 +729,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-msm8960-cdp.dtb \
qcom-msm8974-fairphone-fp2.dtb \
qcom-msm8974-lge-nexus5-hammerhead.dtb \
+ qcom-msm8974-samsung-klte.dtb \
qcom-msm8974-sony-xperia-castor.dtb \
qcom-msm8974-sony-xperia-honami.dtb \
qcom-mdm9615-wp8548-mangoh-green.dtb
diff --git a/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts b/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
new file mode 100644
index 0000000..eaa1001
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "qcom-msm8974pro.dtsi"
+#include "qcom-pm8841.dtsi"
+#include "qcom-pm8941.dtsi"
+
+/ {
+ model = "Samsung Galaxy S5";
+ compatible = "samsung,klte", "qcom,msm8974";
+
+ aliases {
+ serial0 = &blsp1_uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&soc {
+ serial at f991e000 {
+ status = "ok";
+ };
+
+};
--
2.7.4
^ permalink raw reply related
* [PATCH] arm: omap2: timer: fix a kmemleak caused in omap_get_timer_dt
From: qhou @ 2018-01-09 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201801090643.8ChygjAc%fengguang.wu@intel.com>
On 2018?01?09? 07:13, kbuild test robot wrote:
> Hi Qi,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on omap/for-next]
> [also build test WARNING on v4.15-rc7 next-20180108]
> [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/Qi-Hou/arm-omap2-timer-fix-a-kmemleak-caused-in-omap_get_timer_dt/20180109-033316
> base: https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git for-next
> config: arm-omap2plus_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm
>
> All warnings (new ones prefixed by >>):
>
> arch/arm/mach-omap2/timer.c: In function 'omap_get_timer_dt':
> >> arch/arm/mach-omap2/timer.c:205:12: warning: return makes pointer from integer without a cast [-Wint-conversion]
> return -ENOMEM;
Yes, it's problem.
I will correct it to "return NULL;".
As omap_get_timer_dt() is called in early time during booting up kernel,
that allocating a little size of memory should
always be alright. Return NULL just in case that it fails.
--
best regards,
Qi Hou
> ^
>
> vim +205 arch/arm/mach-omap2/timer.c
>
> 170
> 171 /**
> 172 * omap_get_timer_dt - get a timer using device-tree
> 173 * @match - device-tree match structure for matching a device type
> 174 * @property - optional timer property to match
> 175 *
> 176 * Helper function to get a timer during early boot using device-tree for use
> 177 * as kernel system timer. Optionally, the property argument can be used to
> 178 * select a timer with a specific property. Once a timer is found then mark
> 179 * the timer node in device-tree as disabled, to prevent the kernel from
> 180 * registering this timer as a platform device and so no one else can use it.
> 181 */
> 182 static struct device_node * __init omap_get_timer_dt(const struct of_device_id *match,
> 183 const char *property)
> 184 {
> 185 struct device_node *np;
> 186
> 187 for_each_matching_node(np, match) {
> 188 if (!of_device_is_available(np))
> 189 continue;
> 190
> 191 if (property && !of_get_property(np, property, NULL))
> 192 continue;
> 193
> 194 if (!property && (of_get_property(np, "ti,timer-alwon", NULL) ||
> 195 of_get_property(np, "ti,timer-dsp", NULL) ||
> 196 of_get_property(np, "ti,timer-pwm", NULL) ||
> 197 of_get_property(np, "ti,timer-secure", NULL)))
> 198 continue;
> 199
> 200 if (!of_device_is_compatible(np, "ti,omap-counter32k")) {
> 201 struct property *prop;
> 202
> 203 prop = kzalloc(sizeof(*prop), GFP_KERNEL);
> 204 if (!prop)
> > 205 return -ENOMEM;
Correct "return -ENOMEM" to "return NULL;" in case that it fails to
allocate a new memory block.
--
Qi Hou
> 206 prop->name = "status";
> 207 prop->length = sizeof("disabled");
> 208 prop->value = "disabled";
> 209 of_add_property(np, prop);
> 210 }
> 211 return np;
> 212 }
> 213
> 214 return NULL;
> 215 }
> 216
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Best regards,
Qi Hou
Phone number: +86-10-8477-8608
Address: Floor 15, Building B, Wangjing Plaza, No.9 Zhong-Huan Nanlu, Chaoyang District
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx7s: add snvs rtc clock
From: Anson Huang @ 2018-01-09 1:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108103915.GD32635@b29396-OptiPlex-7040>
Best Regards!
Anson Huang
> -----Original Message-----
> From: Dong Aisheng [mailto:dongas86 at gmail.com]
> Sent: 2018-01-08 6:39 PM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; linux-clk at vger.kernel.org; linux-
> kernel at vger.kernel.org; devicetree at vger.kernel.org; dl-linux-imx <linux-
> imx at nxp.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio
> Estevam <fabio.estevam@nxp.com>; mturquette at baylibre.com;
> sboyd at codeaurora.org; robh+dt at kernel.org; mark.rutland at arm.com;
> stefan at agner.ch; linux at armlinux.org.uk
> Subject: Re: [PATCH 2/2] ARM: dts: imx7s: add snvs rtc clock
>
> On Thu, Jan 04, 2018 at 11:06:42PM +0800, Anson Huang wrote:
> > Add i.MX7 SNVS RTC clock.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>
> If this clock IMX7D_SNVS_CLK is used for all SNVS sub modules, then
> snvs_poweroff and snvs_pwrkey should also rely on it, right?
>
> How about add them all in one time?
>
> BTW, syscon-poweroff seems still not introduce clock support and fsl,sec-v4.0-
> pwrkey also does not handle clock, they may need to be added later.
>
> Regards
> Dong Aisheng
Yes, I thought about it before sending patch, but currently the poweroff and pwrkey driver do NOT
handle clocks, so I plan to add them later, including handling clocks in driver and dtb.
Anson
>
> > ---
> > arch/arm/boot/dts/imx7s.dtsi | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx7s.dtsi
> > b/arch/arm/boot/dts/imx7s.dtsi index e718fd2..f9b97f3 100644
> > --- a/arch/arm/boot/dts/imx7s.dtsi
> > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > @@ -534,6 +534,8 @@
> > offset = <0x34>;
> > interrupts = <GIC_SPI 19
> IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 20
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clks IMX7D_SNVS_CLK>;
> > + clock-names = "snvs-rtc";
> > };
> >
> > snvs_poweroff: snvs-poweroff {
> > --
> > 1.9.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-clk"
> > in the body of a message to majordomo at vger.kernel.org More majordomo
> > info at
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger
> > .kernel.org%2Fmajordomo-
> info.html&data=02%7C01%7CAnson.Huang%40nxp.com
> > %7Cd10ff23b822b4cd16c2708d5568417c6%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635
> > %7C0%7C0%7C636510047707248763&sdata=FMx22hfKxs7YA%2F1zCVeYCnVX
> 9Ck4MmB9
> > GuolA51V2eg%3D&reserved=0
^ permalink raw reply
* [PATCH v3 0/3] drm/sun4i: hdmi: Fix sun4i_tmds_determine_rate
From: Jonathan Liu @ 2018-01-09 2:03 UTC (permalink / raw)
To: linux-arm-kernel
This patchset fixes several issues in sun4i_tmds_determine_rate that I
discovered while trying to get a projector connected to an Olimex
A20-OLinuXino-LIME using HDMI with a native resolution of 1280x800 and
pixel clock of 83.5 MHz to display at its native resolution.
Changes for v3:
- Improve commit message for unset best_parent
Changes for v2:
- Split into separate patches for each issue
- Add details to commit message for reproducing issue
Jonathan Liu (3):
drm/sun4i: hdmi: Check for unset best_parent in
sun4i_tmds_determine_rate
drm/sun4i: hdmi: Fix incorrect assignment in sun4i_tmds_determine_rate
drm/sun4i: hdmi: Add missing rate halving check in
sun4i_tmds_determine_rate
drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH v3 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate
From: Jonathan Liu @ 2018-01-09 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109020323.11852-1-net147@gmail.com>
It is possible that if there is no exact rate match and
"rounded = clk_hw_round_rate(parent, ideal)" gives high enough values
(e.g. if rounded is 2 * ideal) that the condition
"abs(rate - rounded / i) < abs(rate - best_parent / best_div)" is never
met and best_parent is never set. This results in req->rate and
req->best_parent_rate being assigned 0.
To avoid this, we set best_parent to the first calculated rate if it is
unset. The sun4i_tmds_calc_divider function already has a similar check.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jonathan Liu <net147@gmail.com>
---
drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
index dc332ea56f6c..4d235e5ea31c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
@@ -102,7 +102,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
goto out;
}
- if (abs(rate - rounded / i) <
+ if (!best_parent || abs(rate - rounded / i) <
abs(rate - best_parent / best_div)) {
best_parent = rounded;
best_div = i;
--
2.15.1
^ permalink raw reply related
* [PATCH v3 2/3] drm/sun4i: hdmi: Fix incorrect assignment in sun4i_tmds_determine_rate
From: Jonathan Liu @ 2018-01-09 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109020323.11852-1-net147@gmail.com>
best_div is set to i which corresponds to rate halving when it should be
set to j which corresponds to the divider.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jonathan Liu <net147@gmail.com>
---
drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
index 4d235e5ea31c..88eeeaf34638 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
@@ -105,7 +105,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
if (!best_parent || abs(rate - rounded / i) <
abs(rate - best_parent / best_div)) {
best_parent = rounded;
- best_div = i;
+ best_div = j;
}
}
}
--
2.15.1
^ permalink raw reply related
* [PATCH v3 3/3] drm/sun4i: hdmi: Add missing rate halving check in sun4i_tmds_determine_rate
From: Jonathan Liu @ 2018-01-09 2:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109020323.11852-1-net147@gmail.com>
It was only checking the divider when determing the closest match if
it could not match the requested rate exactly.
For a projector connected to an Olimex A20-OLinuXino-LIME using HDMI
with a native resolution of 1280x800 and pixel clock of 83.5 MHz, this
resulted in 1280x800 mode not being available and the following in dmesg
when the kernel is booted with drm.debug=0x3e:
[drm:drm_mode_debug_printmodeline] Modeline 37:"1280x800" 60 83500 1280 1352 1480 1680 800 810 816 831 0x48 0x5
[drm:drm_mode_prune_invalid] Not using 1280x800 mode: NOCLOCK
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Jonathan Liu <net147@gmail.com>
---
drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
index 88eeeaf34638..3ecffa52c814 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
@@ -102,9 +102,12 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
goto out;
}
- if (!best_parent || abs(rate - rounded / i) <
- abs(rate - best_parent / best_div)) {
+ if (!best_parent ||
+ abs(rate - rounded / i / j) <
+ abs(rate - best_parent / best_half /
+ best_div)) {
best_parent = rounded;
+ best_half = i;
best_div = j;
}
}
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx7s: add snvs rtc clock
From: Dong Aisheng @ 2018-01-09 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM3PR04MB131588945BE9C5504C6EC0E8F5100@AM3PR04MB1315.eurprd04.prod.outlook.com>
On Tue, Jan 09, 2018 at 01:43:25AM +0000, Anson Huang wrote:
>
>
> Best Regards!
> Anson Huang
>
>
> > -----Original Message-----
> > From: Dong Aisheng [mailto:dongas86 at gmail.com]
> > Sent: 2018-01-08 6:39 PM
> > To: Anson Huang <anson.huang@nxp.com>
> > Cc: linux-arm-kernel at lists.infradead.org; linux-clk at vger.kernel.org; linux-
> > kernel at vger.kernel.org; devicetree at vger.kernel.org; dl-linux-imx <linux-
> > imx at nxp.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio
> > Estevam <fabio.estevam@nxp.com>; mturquette at baylibre.com;
> > sboyd at codeaurora.org; robh+dt at kernel.org; mark.rutland at arm.com;
> > stefan at agner.ch; linux at armlinux.org.uk
> > Subject: Re: [PATCH 2/2] ARM: dts: imx7s: add snvs rtc clock
> >
> > On Thu, Jan 04, 2018 at 11:06:42PM +0800, Anson Huang wrote:
> > > Add i.MX7 SNVS RTC clock.
> > >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> >
> > If this clock IMX7D_SNVS_CLK is used for all SNVS sub modules, then
> > snvs_poweroff and snvs_pwrkey should also rely on it, right?
> >
> > How about add them all in one time?
> >
> > BTW, syscon-poweroff seems still not introduce clock support and fsl,sec-v4.0-
> > pwrkey also does not handle clock, they may need to be added later.
> >
> > Regards
> > Dong Aisheng
>
> Yes, I thought about it before sending patch, but currently the poweroff and pwrkey driver do NOT
> handle clocks, so I plan to add them later, including handling clocks in driver and dtb.
>
SNVS RTC binding doc does not claim a optional clock support, you probably may
need update the binding doc as well.
BTW, Should mx6 platforms need the same fixes?
If yes, we'd better fix them all.
Regards
Dong Aisheng
> Anson
>
> >
> > > ---
> > > arch/arm/boot/dts/imx7s.dtsi | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/imx7s.dtsi
> > > b/arch/arm/boot/dts/imx7s.dtsi index e718fd2..f9b97f3 100644
> > > --- a/arch/arm/boot/dts/imx7s.dtsi
> > > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > > @@ -534,6 +534,8 @@
> > > offset = <0x34>;
> > > interrupts = <GIC_SPI 19
> > IRQ_TYPE_LEVEL_HIGH>,
> > > <GIC_SPI 20
> > IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clks IMX7D_SNVS_CLK>;
> > > + clock-names = "snvs-rtc";
> > > };
> > >
> > > snvs_poweroff: snvs-poweroff {
> > > --
> > > 1.9.1
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-clk"
> > > in the body of a message to majordomo at vger.kernel.org More majordomo
> > > info at
> > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger
> > > .kernel.org%2Fmajordomo-
> > info.html&data=02%7C01%7CAnson.Huang%40nxp.com
> > > %7Cd10ff23b822b4cd16c2708d5568417c6%7C686ea1d3bc2b4c6fa92cd99c5c30
> > 1635
> > > %7C0%7C0%7C636510047707248763&sdata=FMx22hfKxs7YA%2F1zCVeYCnVX
> > 9Ck4MmB9
> > > GuolA51V2eg%3D&reserved=0
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx7s: add snvs rtc clock
From: Anson Huang @ 2018-01-09 2:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109021704.GG32635@b29396-OptiPlex-7040>
Best Regards!
Anson Huang
> -----Original Message-----
> From: Dong Aisheng [mailto:dongas86 at gmail.com]
> Sent: 2018-01-09 10:17 AM
> To: Anson Huang <anson.huang@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; linux-clk at vger.kernel.org; linux-
> kernel at vger.kernel.org; devicetree at vger.kernel.org; dl-linux-imx <linux-
> imx at nxp.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio
> Estevam <fabio.estevam@nxp.com>; mturquette at baylibre.com;
> sboyd at codeaurora.org; robh+dt at kernel.org; mark.rutland at arm.com;
> stefan at agner.ch; linux at armlinux.org.uk
> Subject: Re: [PATCH 2/2] ARM: dts: imx7s: add snvs rtc clock
>
> On Tue, Jan 09, 2018 at 01:43:25AM +0000, Anson Huang wrote:
> >
> >
> > Best Regards!
> > Anson Huang
> >
> >
> > > -----Original Message-----
> > > From: Dong Aisheng [mailto:dongas86 at gmail.com]
> > > Sent: 2018-01-08 6:39 PM
> > > To: Anson Huang <anson.huang@nxp.com>
> > > Cc: linux-arm-kernel at lists.infradead.org; linux-clk at vger.kernel.org;
> > > linux- kernel at vger.kernel.org; devicetree at vger.kernel.org;
> > > dl-linux-imx <linux- imx@nxp.com>; shawnguo at kernel.org;
> > > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > mturquette at baylibre.com; sboyd at codeaurora.org; robh+dt at kernel.org;
> > > mark.rutland at arm.com; stefan at agner.ch; linux at armlinux.org.uk
> > > Subject: Re: [PATCH 2/2] ARM: dts: imx7s: add snvs rtc clock
> > >
> > > On Thu, Jan 04, 2018 at 11:06:42PM +0800, Anson Huang wrote:
> > > > Add i.MX7 SNVS RTC clock.
> > > >
> > > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > >
> > > If this clock IMX7D_SNVS_CLK is used for all SNVS sub modules, then
> > > snvs_poweroff and snvs_pwrkey should also rely on it, right?
> > >
> > > How about add them all in one time?
> > >
> > > BTW, syscon-poweroff seems still not introduce clock support and
> > > fsl,sec-v4.0- pwrkey also does not handle clock, they may need to be added
> later.
> > >
> > > Regards
> > > Dong Aisheng
> >
> > Yes, I thought about it before sending patch, but currently the
> > poweroff and pwrkey driver do NOT handle clocks, so I plan to add them later,
> including handling clocks in driver and dtb.
> >
>
> SNVS RTC binding doc does not claim a optional clock support, you probably
> may need update the binding doc as well.
>
> BTW, Should mx6 platforms need the same fixes?
> If yes, we'd better fix them all.
I.MX6 platforms has no such SNVS CCGR clock gate, no need to change.
OK, I will update the SNVS RTC binding doc and send out a V2 patch set.
Anson.
>
> Regards
> Dong Aisheng
>
> > Anson
> >
> > >
> > > > ---
> > > > arch/arm/boot/dts/imx7s.dtsi | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/imx7s.dtsi
> > > > b/arch/arm/boot/dts/imx7s.dtsi index e718fd2..f9b97f3 100644
> > > > --- a/arch/arm/boot/dts/imx7s.dtsi
> > > > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > > > @@ -534,6 +534,8 @@
> > > > offset = <0x34>;
> > > > interrupts = <GIC_SPI 19
> > > IRQ_TYPE_LEVEL_HIGH>,
> > > > <GIC_SPI 20
> > > IRQ_TYPE_LEVEL_HIGH>;
> > > > + clocks = <&clks IMX7D_SNVS_CLK>;
> > > > + clock-names = "snvs-rtc";
> > > > };
> > > >
> > > > snvs_poweroff: snvs-poweroff {
> > > > --
> > > > 1.9.1
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-clk"
> > > > in the body of a message to majordomo at vger.kernel.org More
> > > > majordomo info at
> > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> > > > vger
> > > > .kernel.org%2Fmajordomo-
> > > info.html&data=02%7C01%7CAnson.Huang%40nxp.com
> > > > %7Cd10ff23b822b4cd16c2708d5568417c6%7C686ea1d3bc2b4c6fa92cd99c5
> c30
> > > 1635
> > > > %7C0%7C0%7C636510047707248763&sdata=FMx22hfKxs7YA%2F1zCVeYC
> nVX
> > > 9Ck4MmB9
> > > > GuolA51V2eg%3D&reserved=0
^ permalink raw reply
* [PATCH 2/2] arm64: Branch predictor hardening for Cavium ThunderX2
From: Jayachandran C @ 2018-01-09 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108172341.GV25869@arm.com>
On Mon, Jan 08, 2018 at 05:23:41PM +0000, Will Deacon wrote:
> On Mon, Jan 08, 2018 at 09:19:43AM -0800, Jayachandran C wrote:
> > On Mon, Jan 08, 2018 at 04:46:52PM +0000, Will Deacon wrote:
> > > On Sun, Jan 07, 2018 at 10:53:36PM -0800, Jayachandran C wrote:
> > > > Use PSCI based mitigation for speculative execution attacks targeting
> > > > the branch predictor. The approach is similar to the one used for
> > > > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to
> > > > test if the firmware supports the capability.
> > > >
> > > > If the secure firmware has been updated with the mitigation code to
> > > > invalidate the branch target buffer, we use the PSCI version call to
> > > > invoke it.
> > > >
> > > > Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
> > > > ---
> > > > arch/arm64/kernel/cpu_errata.c | 38 ++++++++++++++++++++++++++++++++++++++
> > > > 1 file changed, 38 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> > > > index cb0fb37..abceb5d 100644
> > > > --- a/arch/arm64/kernel/cpu_errata.c
> > > > +++ b/arch/arm64/kernel/cpu_errata.c
> > > > @@ -124,6 +124,7 @@ static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry,
> > > > __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
> > > > }
> > > >
> > > > +#include <linux/arm-smccc.h>
> > > > #include <linux/psci.h>
> > > >
> > > > static int enable_psci_bp_hardening(void *data)
> > > > @@ -138,6 +139,33 @@ static int enable_psci_bp_hardening(void *data)
> > > >
> > > > return 0;
> > > > }
> > > > +
> > > > +#define CAVIUM_TX2_SIP_SMC_CALL 0xC200FF00
> > > > +#define CAVIUM_TX2_BTB_HARDEN_CAP 0xB0A0
> > > > +
> > > > +static int enable_tx2_psci_bp_hardening(void *data)
> > > > +{
> > > > + const struct arm64_cpu_capabilities *entry = data;
> > > > + struct arm_smccc_res res;
> > > > +
> > > > + if (!entry->matches(entry, SCOPE_LOCAL_CPU))
> > > > + return;
> > > > +
> > > > + arm_smccc_smc(CAVIUM_TX2_SIP_SMC_CALL, CAVIUM_TX2_BTB_HARDEN_CAP, 0, 0, 0, 0, 0, 0, &res);
> > >
> > > One thing to be aware of here is that if somebody configures qemu to emulate
> > > a TX2, this may actually disappear into EL3 and not return. You're better
> > > off sticking with PSCI GET_VERSION in terms of portability, but it's your
> > > call -- I'd expect you to deal with any breakage reports on the list due
> > > to the SMC above. Fair?
> >
> > I don't like having a custom SMC here either. But Overloading PSCI get version
> > is the problem as I wrote earlier - there is no way to check if the firmware
> > implements BTB hardening with overloading. There is a good chance that users
> > with old firmware will just fail without any warning.
>
> That's true, but there is precedent for this elsewhere. For example, CPU
> errata that require a firmware change are often not probable. Also, your SMC
> call won't always work (see the qemu comment below). Note that I'm not
> saying I won't take this code, just that you need to be aware of what
> you're doing.
>
> > Is there a reason for overloading PSCI get version? Allocating a new standard
> > SMC number would make checking for existance and usage much simpler.
>
> PSCI get version is what we have today. We're working on extending PSCI to
> allocate a new standard SMC number, but we need something that can be used
> with existing firmware too and standardisation doesn't happen overnight.
Can you hold this patchset until the SMC number is published? Otherwise we
will end up with two incompatible interfaces, and the mess of supporting
both.
Or if there is a plan standardize this later, I can pickup a vendor specific
SMC for now, and switch over to the standard one later. Any suggestions here?
JC.
^ permalink raw reply
* [PATCH V2 1/2] clk: imx: imx7d: add the snvs clock
From: Anson Huang @ 2018-01-09 2:51 UTC (permalink / raw)
To: linux-arm-kernel
According to the i.MX7D Reference Manual,
SNVS block has a clock gate, accessing SNVS block
would need this clock gate to be enabled, add it
into clock tree so that SNVS module driver can
operate this clock gate.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
no changes since v1.
drivers/clk/imx/clk-imx7d.c | 1 +
include/dt-bindings/clock/imx7d-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 80dc211..f34f1ec 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -795,6 +795,7 @@ static void __init imx7d_clocks_init(struct device_node *ccm_node)
clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] = imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div", base + 0x4130, 0);
clks[IMX7D_DRAM_ALT_ROOT_CLK] = imx_clk_gate4("dram_alt_root_clk", "dram_alt_post_div", base + 0x4130, 0);
clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk", "ipg_root_clk", base + 0x4230, 0);
+ clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk", base + 0x4250, 0);
clks[IMX7D_USB_HSIC_ROOT_CLK] = imx_clk_gate4("usb_hsic_root_clk", "usb_hsic_post_div", base + 0x4420, 0);
clks[IMX7D_SDMA_CORE_CLK] = imx_clk_gate4("sdma_root_clk", "ahb_root_clk", base + 0x4480, 0);
clks[IMX7D_PCIE_CTRL_ROOT_CLK] = imx_clk_gate4("pcie_ctrl_root_clk", "pcie_ctrl_post_div", base + 0x4600, 0);
diff --git a/include/dt-bindings/clock/imx7d-clock.h b/include/dt-bindings/clock/imx7d-clock.h
index e2f99ae..dc51904 100644
--- a/include/dt-bindings/clock/imx7d-clock.h
+++ b/include/dt-bindings/clock/imx7d-clock.h
@@ -452,5 +452,6 @@
#define IMX7D_OCOTP_CLK 439
#define IMX7D_NAND_RAWNAND_CLK 440
#define IMX7D_NAND_USDHC_BUS_RAWNAND_CLK 441
-#define IMX7D_CLK_END 442
+#define IMX7D_SNVS_CLK 442
+#define IMX7D_CLK_END 443
#endif /* __DT_BINDINGS_CLOCK_IMX7D_H */
--
1.9.1
^ permalink raw reply related
* [PATCH V2 2/2] ARM: dts: imx7s: add snvs rtc clock
From: Anson Huang @ 2018-01-09 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515466276-5541-1-git-send-email-Anson.Huang@nxp.com>
Add i.MX7 SNVS RTC clock.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
changes since v1:
update snvs lp rtc binding-doc for clock info.
Documentation/devicetree/bindings/crypto/fsl-sec4.txt | 16 ++++++++++++++++
arch/arm/boot/dts/imx7s.dtsi | 2 ++
2 files changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index 76aec8a..da66ac4 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -415,12 +415,26 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
value type: <u32>
Definition: LP register offset. default it is 0x34.
+ - clocks
+ Usage: required if SNVS LP RTC requires explicit enablement of clocks
+ Value type: <prop_encoded-array>
+ Definition: A list of phandle and clock specifier pairs describing
+ the clocks required for enabling and disabling SNVS LP RTC.
+
+ - clock-names
+ Usage: required if SNVS LP RTC requires explicit enablement of clocks
+ Value type: <string>
+ Definition: A list of clock name strings in the same order as the
+ clocks property.
+
EXAMPLE
sec_mon_rtc_lp at 1 {
compatible = "fsl,sec-v4.0-mon-rtc-lp";
interrupts = <93 2>;
regmap = <&snvs>;
offset = <0x34>;
+ clocks = <&clks IMX7D_SNVS_CLK>;
+ clock-names = "snvs-rtc";
};
=====================================================================
@@ -543,6 +557,8 @@ FULL EXAMPLE
regmap = <&sec_mon>;
offset = <0x34>;
interrupts = <93 2>;
+ clocks = <&clks IMX7D_SNVS_CLK>;
+ clock-names = "snvs-rtc";
};
snvs-pwrkey at 020cc000 {
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 9aa2bb9..02baf42 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -551,6 +551,8 @@
offset = <0x34>;
interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7D_SNVS_CLK>;
+ clock-names = "snvs-rtc";
};
snvs_poweroff: snvs-poweroff {
--
1.9.1
^ permalink raw reply related
* [RFC PATCH] drivers: soc: xilinx: Add ZynqMP PM driver
From: Sean Wang @ 2018-01-09 3:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515449444-5274-1-git-send-email-jollys@xilinx.com>
On Mon, 2018-01-08 at 14:10 -0800, Jolly Shah wrote:
> Add ZynqMP PM driver. PM driver provides power management
> support for ZynqMP.
>
> Signed-off-by: Jolly Shah <jollys@xilinx.com>
> Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> ---
> .../bindings/soc/xilinx/xlnx,zynqmp-pm.txt | 15 ++
The patch should be split into two: one is for dt-bindings part and the
other is for driver part. Where dt-binding part should require
additionally to send to Rob and Cc. devicetree at vger.kernel.org.
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/xilinx/Kconfig | 4 +
> drivers/soc/xilinx/Makefile | 4 +
> drivers/soc/xilinx/zynqmp/Kconfig | 15 ++
> drivers/soc/xilinx/zynqmp/Makefile | 1 +
> drivers/soc/xilinx/zynqmp/pm.c | 265 +++++++++++++++++++++
> 8 files changed, 306 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/xilinx/xlnx,zynqmp-pm.txt
> create mode 100644 drivers/soc/xilinx/Kconfig
> create mode 100644 drivers/soc/xilinx/Makefile
> create mode 100644 drivers/soc/xilinx/zynqmp/Kconfig
> create mode 100644 drivers/soc/xilinx/zynqmp/Makefile
> create mode 100644 drivers/soc/xilinx/zynqmp/pm.c
>
> diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,zynqmp-pm.txt b/Documentation/devicetree/bindings/soc/xilinx/xlnx,zynqmp-pm.txt
> new file mode 100644
> index 0000000..9cfb40d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/xilinx/xlnx,zynqmp-pm.txt
> @@ -0,0 +1,15 @@
> +Xilinx Zynq MPSoC Power Management Device Tree Bindings
> +
> +The zynqmp-pm node describes the power management configurations.
> +
> +Required properties:
> + - compatible : Must contain: "xlnx,zynqmp-pm"
> + - interrupt-parent : Interrupt controller the interrupt is routed through
> + - interrupts : Interrupt specifier
> +
> +Examples:
> + zynqmp-firmware {
> + compatible = "xlnx,zynqmp-pm";
> + interrupt-parent = <&gic>;
> + interrupts = <0 35 4>;
> + };
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index fc9e980..c07b4a8 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -16,6 +16,7 @@ source "drivers/soc/tegra/Kconfig"
> source "drivers/soc/ti/Kconfig"
> source "drivers/soc/ux500/Kconfig"
> source "drivers/soc/versatile/Kconfig"
> +source "drivers/soc/xilinx/Kconfig"
> source "drivers/soc/zte/Kconfig"
>
> endmenu
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index deecb16..abb019a 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> obj-$(CONFIG_SOC_SAMSUNG) += samsung/
> obj-$(CONFIG_ARCH_SUNXI) += sunxi/
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> +obj-$(CONFIG_ARCH_ZYNQMP) += xilinx/
> obj-$(CONFIG_SOC_TI) += ti/
> obj-$(CONFIG_ARCH_U8500) += ux500/
> obj-$(CONFIG_PLAT_VERSATILE) += versatile/
> diff --git a/drivers/soc/xilinx/Kconfig b/drivers/soc/xilinx/Kconfig
> new file mode 100644
> index 0000000..190add7
> --- /dev/null
> +++ b/drivers/soc/xilinx/Kconfig
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Kconfig for Xilinx SoCs
> +
> +source "drivers/soc/xilinx/zynqmp/Kconfig"
> diff --git a/drivers/soc/xilinx/Makefile b/drivers/soc/xilinx/Makefile
> new file mode 100644
> index 0000000..bc9d560
> --- /dev/null
> +++ b/drivers/soc/xilinx/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Makefile for Xilinx SoCs
> +
> +obj-$(CONFIG_ARCH_ZYNQMP) += zynqmp/
> diff --git a/drivers/soc/xilinx/zynqmp/Kconfig b/drivers/soc/xilinx/zynqmp/Kconfig
> new file mode 100644
> index 0000000..d3c784d
> --- /dev/null
> +++ b/drivers/soc/xilinx/zynqmp/Kconfig
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Kconfig for Xilinx zynqmp SoC
> +#
> +menu "Zynq MPSoC SoC Drivers"
> + depends on ARCH_ZYNQMP
> +
> +
> +config ZYNQMP_PM
> + bool "Enable Xilinx Zynq MPSoC Power Management"
> + depends on PM
> + help
> + Say yes to enable power management support for
> + ZyqnMP SoC. In doubt, say N.
> +
> +endmenu
> diff --git a/drivers/soc/xilinx/zynqmp/Makefile b/drivers/soc/xilinx/zynqmp/Makefile
> new file mode 100644
> index 0000000..98034f7
> --- /dev/null
> +++ b/drivers/soc/xilinx/zynqmp/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_ZYNQMP_PM) += pm.o
> diff --git a/drivers/soc/xilinx/zynqmp/pm.c b/drivers/soc/xilinx/zynqmp/pm.c
> new file mode 100644
> index 0000000..7178fb5
> --- /dev/null
> +++ b/drivers/soc/xilinx/zynqmp/pm.c
> @@ -0,0 +1,265 @@
> +/*
> + * Xilinx Zynq MPSoC Power Management
> + *
> + * Copyright (C) 2014-2017 Xilinx, Inc.
should include 2018 ?
> + *
> + * Davorin Mista <davorin.mista@aggios.com>
> + * Jolly Shah <jollys@xilinx.com>
> + * Rajan Vaja <rajanv@xilinx.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include <linux/compiler.h>
> +#include <linux/arm-smccc.h>
> +#include <linux/of.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/interrupt.h>
> +#include <linux/uaccess.h>
> +#include <linux/platform_device.h>
> +#include <linux/debugfs.h>
> +#include <linux/reboot.h>
> +#include <linux/suspend.h>
> +#include <linux/firmware/xilinx/zynqmp/firmware.h>
> +
> +#define DRIVER_NAME "zynqmp_pm"
> +
> +/**
> + * struct zynqmp_pm_work_struct - Wrapper for struct work_struct
> + * @callback_work: Work structure
> + * @args: Callback arguments
> + */
> +struct zynqmp_pm_work_struct {
> + struct work_struct callback_work;
> + u32 args[CB_ARG_CNT];
> +};
> +
> +static struct zynqmp_pm_work_struct *zynqmp_pm_init_suspend_work;
> +
> +enum pm_suspend_mode {
> + PM_SUSPEND_MODE_STD,
> + PM_SUSPEND_MODE_POWER_OFF,
> +};
> +
> +#define PM_SUSPEND_MODE_FIRST PM_SUSPEND_MODE_STD
> +
> +static const char *const suspend_modes[] = {
> + [PM_SUSPEND_MODE_STD] = "standard",
> + [PM_SUSPEND_MODE_POWER_OFF] = "power-off",
> +};
> +
> +static enum pm_suspend_mode suspend_mode = PM_SUSPEND_MODE_STD;
> +
> +enum pm_api_cb_id {
> + PM_INIT_SUSPEND_CB = 30,
> + PM_ACKNOWLEDGE_CB,
> + PM_NOTIFY_CB,
> +};
> +
> +static irqreturn_t zynqmp_pm_isr(int irq, void *data)
> +{
> + u32 payload[CB_PAYLOAD_SIZE];
> + const struct zynqmp_eemi_ops *eemi_ops = get_eemi_ops();
> +
> + if (!eemi_ops || !eemi_ops->get_callback_data)
> + return IRQ_NONE;
> +
> + eemi_ops->get_callback_data(payload);
> +
> + if (!payload[0])
> + return IRQ_NONE;
> +
> + /* First element is callback API ID, others are callback arguments */
> + if (payload[0] == PM_INIT_SUSPEND_CB) {
> + if (work_pending(&zynqmp_pm_init_suspend_work->callback_work))
> + goto done;
> +
> + /* Copy callback arguments into work's structure */
> + memcpy(zynqmp_pm_init_suspend_work->args, &payload[1],
> + sizeof(zynqmp_pm_init_suspend_work->args));
> +
> + queue_work(system_unbound_wq,
> + &zynqmp_pm_init_suspend_work->callback_work);
> + }
> +
> +done:
> + return IRQ_HANDLED;
> +}
> +
> +static const struct of_device_id pm_of_match[] = {
> + { .compatible = "xlnx,zynqmp-pm", },
> + { /* end of table */ },
> +};
> +
> +MODULE_DEVICE_TABLE(of, pm_of_match);
> +
> +/**
> + * zynqmp_pm_init_suspend_work_fn - Initialize suspend
> + * @work: Pointer to work_struct
> + *
> + * Bottom-half of PM callback IRQ handler.
> + */
> +static void zynqmp_pm_init_suspend_work_fn(struct work_struct *work)
> +{
> + struct zynqmp_pm_work_struct *pm_work =
> + container_of(work, struct zynqmp_pm_work_struct, callback_work);
> +
> + if (pm_work->args[0] == ZYNQMP_PM_SUSPEND_REASON_SYSTEM_SHUTDOWN) {
> + orderly_poweroff(true);
> + } else if (pm_work->args[0] ==
> + ZYNQMP_PM_SUSPEND_REASON_POWER_UNIT_REQUEST) {
> + pm_suspend(PM_SUSPEND_MEM);
> + } else {
> + pr_err("%s Unsupported InitSuspendCb reason code %d.\n"
> + , __func__, pm_work->args[0]);
> + }
> +}
> +
> +static ssize_t suspend_mode_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + char *s = buf;
> + int md;
> +
> + for (md = PM_SUSPEND_MODE_FIRST; md < ARRAY_SIZE(suspend_modes); md++)
> + if (suspend_modes[md]) {
> + if (md == suspend_mode)
> + s += sprintf(s, "[%s] ", suspend_modes[md]);
> + else
> + s += sprintf(s, "%s ", suspend_modes[md]);
> + }
> +
> + /* Convert last space to newline */
> + if (s != buf)
> + *(s - 1) = '\n';
> + return (s - buf);
> +}
> +
> +static ssize_t suspend_mode_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int md, ret = -EINVAL;
> + const struct zynqmp_eemi_ops *eemi_ops = get_eemi_ops();
> +
> + if (!eemi_ops || !eemi_ops->set_suspend_mode)
> + return ret;
> +
> + for (md = PM_SUSPEND_MODE_FIRST; md < ARRAY_SIZE(suspend_modes); md++)
> + if (suspend_modes[md] &&
> + sysfs_streq(suspend_modes[md], buf)) {
> + ret = 0;
> + break;
> + }
> +
> + if (!ret && md != suspend_mode) {
> + ret = eemi_ops->set_suspend_mode(md);
> + if (likely(!ret))
> + suspend_mode = md;
> + }
> +
> + return ret ? ret : count;
> +}
> +
> +static DEVICE_ATTR_RW(suspend_mode);
> +
> +/**
> + * zynqmp_pm_sysfs_init - Initialize PM driver sysfs interface
> + * @dev: Pointer to device structure
> + *
> + * Return: 0 on success, negative error code otherwise
> + */
> +static int zynqmp_pm_sysfs_init(struct device *dev)
> +{
> + return sysfs_create_file(&dev->kobj, &dev_attr_suspend_mode.attr);
> +}
> +
> +/**
> + * zynqmp_pm_probe - Probe existence of the PMU Firmware
> + * and initialize debugfs interface
> + *
> + * @pdev: Pointer to the platform_device structure
> + *
> + * Return: Returns 0 on success
> + * Negative error code otherwise
> + */
> +static int zynqmp_pm_probe(struct platform_device *pdev)
> +{
> + int ret, irq;
> + u32 pm_api_version;
> + const struct zynqmp_eemi_ops *eemi_ops = get_eemi_ops();
> +
> + if (!eemi_ops || !eemi_ops->get_api_version)
> + return -ENXIO;
> +
> + eemi_ops->get_api_version(&pm_api_version);
> +
> + /* Check PM API version number */
> + if (pm_api_version != ZYNQMP_PM_VERSION)
> + return -ENODEV;
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq <= 0)
> + return -ENXIO;
> +
> + ret = request_irq(irq, zynqmp_pm_isr, IRQF_SHARED, DRIVER_NAME, pdev);
> + if (ret) {
> + dev_err(&pdev->dev, "request_irq '%d' failed with %d\n",
> + irq, ret);
> + return ret;
> + }
how about use devm_request_irq to simplify error path?
> +
> + zynqmp_pm_init_suspend_work =
> + devm_kzalloc(&pdev->dev, sizeof(struct zynqmp_pm_work_struct),
> + GFP_KERNEL);
> + if (!zynqmp_pm_init_suspend_work) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + INIT_WORK(&zynqmp_pm_init_suspend_work->callback_work,
> + zynqmp_pm_init_suspend_work_fn);
> +
> + ret = zynqmp_pm_sysfs_init(&pdev->dev);
> + if (ret) {
> + dev_err(&pdev->dev, "unable to initialize sysfs interface\n");
> + goto error;
> + }
> +
> + dev_info(&pdev->dev, "Power management API v%d.%d\n",
> + ZYNQMP_PM_VERSION_MAJOR, ZYNQMP_PM_VERSION_MINOR);
> +
> + return 0;
> +
> +error:
> + free_irq(irq, 0);
> + return ret;
> +}
> +
> +static struct platform_driver zynqmp_pm_platform_driver = {
> + .probe = zynqmp_pm_probe,
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = pm_of_match,
> + },
> +};
> +builtin_platform_driver(zynqmp_pm_platform_driver);
> +
> +/**
> + * zynqmp_pm_init - Notify PM firmware that initialization is completed
> + *
> + * Return: Status returned from the PM firmware
> + */
> +static int __init zynqmp_pm_init(void)
> +{
> + const struct zynqmp_eemi_ops *eemi_ops = get_eemi_ops();
> +
> + if (!eemi_ops || !eemi_ops->init_finalize)
> + return -ENXIO;
> +
> + return eemi_ops->init_finalize();
> +}
> +
> +late_initcall_sync(zynqmp_pm_init);
^ permalink raw reply
* [PATCH 06/67] hexagon: remove unused flush_write_buffers definition
From: Richard Kuo @ 2018-01-09 3:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229081911.2802-7-hch@lst.de>
On Fri, Dec 29, 2017 at 09:18:10AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/hexagon/include/asm/io.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/hexagon/include/asm/io.h b/arch/hexagon/include/asm/io.h
> index 66f5e9a61efc..9e8621d94ee9 100644
> --- a/arch/hexagon/include/asm/io.h
> +++ b/arch/hexagon/include/asm/io.h
> @@ -330,8 +330,6 @@ static inline void outsl(unsigned long port, const void *buffer, int count)
> }
> }
>
> -#define flush_write_buffers() do { } while (0)
> -
> #endif /* __KERNEL__ */
>
> #endif
> --
> 2.14.2
>
For Hexagon:
Acked-by: Richard Kuo <rkuo@codeaurora.org>
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 01/12] dt-bindings: clock: mediatek: add missing required #reset-cells
From: Rob Herring @ 2018-01-09 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <084288e2520f9bd3ccdb3cf7aeef8ebcae48e6d7.1515057696.git.sean.wang@mediatek.com>
On Thu, Jan 04, 2018 at 05:40:51PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> All ethsys, pciesys and ssusbsys internally include reset controller, so
> explicitly add back these missing cell definitions to related bindings
> and examples.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> ---
> Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 2 ++
> Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt | 2 ++
> Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt | 2 ++
> 3 files changed, 6 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 05/11] clk: qcom: Add DT bindings for CPU clock driver for msm8996
From: Rob Herring @ 2018-01-09 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515064215-22202-6-git-send-email-ilialin@codeaurora.org>
On Thu, Jan 04, 2018 at 01:10:09PM +0200, Ilia Lin wrote:
> Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> ---
> Documentation/devicetree/bindings/clock/qcom,kryocc.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/qcom,kryocc.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,kryocc.txt b/Documentation/devicetree/bindings/clock/qcom,kryocc.txt
> new file mode 100644
> index 0000000..c45de03
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/qcom,kryocc.txt
> @@ -0,0 +1,17 @@
> +Qualcomm CPUSS clock controller for Kryo CPUs
> +----------------------------------------------------
> +
> +Required properties :
> +- compatible : shall contain only one of the following:
> +
> + "qcom,apcc-msm8996"
qcom-msm8996-apcc is the conventional order.
> +
> +- reg : shall contain base register location and length
> +- #clock-cells : shall contain 1
> +
> +Example:
> + kryocc: clock-controller at 6400000 {
> + compatible = "qcom,apcc-msm8996";
> + reg = <0x6400000 0x90000>;
> + #clock-cells = <1>;
> + };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 6/8] dt-bindings: ARM: sunxi: Document A80 SoC secure SRAM usage by SMP hotplug
From: Rob Herring @ 2018-01-09 3:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104143754.2425-7-wens@csie.org>
On Thu, Jan 04, 2018 at 10:37:52PM +0800, Chen-Yu Tsai wrote:
> On the Allwinner A80 SoC the BROM supports hotplugging the primary core
> (cpu0) by checking two 32bit values at a specific location within the
> secure SRAM block. This region needs to be reserved and accessible to
> the SMP code.
>
> Document its usage.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> .../devicetree/bindings/arm/sunxi/smp-sram.txt | 44 ++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3
From: Jayachandran C @ 2018-01-09 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108175100.GW25869@arm.com>
On Mon, Jan 08, 2018 at 05:51:00PM +0000, Will Deacon wrote:
> On Mon, Jan 08, 2018 at 09:40:17AM -0800, Jayachandran C wrote:
> > On Mon, Jan 08, 2018 at 09:20:09AM +0000, Marc Zyngier wrote:
> > > On 08/01/18 07:24, Jayachandran C wrote:
> > > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > > > index 19ed09b..202b037 100644
> > > > --- a/arch/arm64/kernel/cpufeature.c
> > > > +++ b/arch/arm64/kernel/cpufeature.c
> > > > @@ -862,6 +862,13 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> > > > return __kpti_forced > 0;
> > > > }
> > > >
> > > > + /* Don't force KPTI for CPUs that are not vulnerable */
> > > > + switch (read_cpuid_id() & MIDR_CPU_MODEL_MASK) {
> > > > + case MIDR_CAVIUM_THUNDERX2:
> > > > + case MIDR_BRCM_VULCAN:
> > > > + return false;
> > > > + }
> > > > +
> > > > /* Useful for KASLR robustness */
> > > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> > > > return true;
> > > >
> > >
> > > KPTI is also an improvement for KASLR. Why would you deprive a user of
> > > the choice to further secure their system?
> >
> > The user has a choice with kpti= at the kernel command line, so we are
> > not depriving the user of a choice. KASLR is expected to be enabled by
> > distributions, and KPTI will be enabled by default as well.
> >
> > On systems that are not vulnerable to variant 3, this is an unnecessary
> > overhead.
>
> KASLR can be bypassed on CPUs that are not vulnerable to variant 3 simply
> by timing how long accesses to kernel addresses from EL0 take -- please read
> the original KAISER paper for details about that attack on x86. kpti
> mitigates that. If you don't care about KASLR, don't enable it (arguably
> it's useless without kpti).
The code above assumes that all ARM CPUs (now and future) will be vulnerable
to timing attacks that can bypass KASLR. I don't think that is a correct
assumption to make.
If ThunderX2 is shown to be vulnerable to any timing based attack we can
certainly move the MIDR check after the check for the CONFIG_RANDOMIZE_BASE.
But I don't think that is the case now, if you have any PoC code to check
this I can run on the processor and make the change.
It is pretty clear that we need a whitelist check either before or after the
CONFIG_RANDOMIZE_BASE check.
The kaiser paper seems to say that ARM TTBR0/1 made it more immune, and the
prefetch paper(if I understand correctly) showed that prefetch on some ARM
cores can be used for timing attack. This is probably and area where you will
have better information, so any specific pointers would be appreciated -
especially ones showing that all ARM CPUs are susceptible.
Thanks,
JC.
^ permalink raw reply
* [PATCH] arm64: dts: Hi3660: Remove 'CPU_NAP' idle state
From: Leo Yan @ 2018-01-09 4:32 UTC (permalink / raw)
To: linux-arm-kernel
Thanks a lot for Vincent Guittot careful work to find bug for 'CPU_NAP'
idle state. At early time, the CPU CA73 CPU_NAP idle state has been
supported on Hikey960. Later we found the system has the hang issue
and for resolving this issue Hisilicon released new MCU firmware, but
unfortunately the new MCU firmware has side effect and results in the
CA73 CPU cannot really enter CPU_NAP state and roll back to WFI state.
After discussion we cannot see the possibility to enable CA73 CPU_NAP
state anymore on Hikey960, based on this conclusion we should remove
this state from DT binding.
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Kevin Wang <jean.wangtao@linaro.org>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 32 ++++---------------------------
1 file changed, 4 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ab0b95b..8fddf0d 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -96,11 +96,7 @@
reg = <0x0 0x100>;
enable-method = "psci";
next-level-cache = <&A73_L2>;
- cpu-idle-states = <
- &CPU_NAP
- &CPU_SLEEP
- &CLUSTER_SLEEP_1
- >;
+ cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_1>;
};
cpu5: cpu at 101 {
@@ -109,11 +105,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
next-level-cache = <&A73_L2>;
- cpu-idle-states = <
- &CPU_NAP
- &CPU_SLEEP
- &CLUSTER_SLEEP_1
- >;
+ cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_1>;
};
cpu6: cpu at 102 {
@@ -122,11 +114,7 @@
reg = <0x0 0x102>;
enable-method = "psci";
next-level-cache = <&A73_L2>;
- cpu-idle-states = <
- &CPU_NAP
- &CPU_SLEEP
- &CLUSTER_SLEEP_1
- >;
+ cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_1>;
};
cpu7: cpu at 103 {
@@ -135,24 +123,12 @@
reg = <0x0 0x103>;
enable-method = "psci";
next-level-cache = <&A73_L2>;
- cpu-idle-states = <
- &CPU_NAP
- &CPU_SLEEP
- &CLUSTER_SLEEP_1
- >;
+ cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_1>;
};
idle-states {
entry-method = "psci";
- CPU_NAP: cpu-nap {
- compatible = "arm,idle-state";
- arm,psci-suspend-param = <0x0000001>;
- entry-latency-us = <7>;
- exit-latency-us = <2>;
- min-residency-us = <15>;
- };
-
CPU_SLEEP: cpu-sleep {
compatible = "arm,idle-state";
local-timer-stop;
--
2.7.4
^ permalink raw reply related
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2018-01-09 4:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpNeSNHoUcM9xOq0bjN_okaEUDbaz1qyuqAct7BSNLQqKQ@mail.gmail.com>
Bhupesh,
On Tue, Jan 09, 2018 at 01:30:07AM +0530, Bhupesh Sharma wrote:
> Hello Akashi,
>
> On Tue, Dec 26, 2017 at 8:26 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> > On Tue, Dec 26, 2017 at 7:58 AM, AKASHI Takahiro
> > <takahiro.akashi@linaro.org> wrote:
> >> On Tue, Dec 26, 2017 at 09:35:17AM +0800, Dave Young wrote:
> >>> [snip]
> >>> > > > Well, we may be able to change pr_warn() to pr_warn_once() here, but
> >>> > > > I hope that adding "numa=off" to kernel command line should also work.
> >>> > >
> >>> > > Hmm, adding "numa=off" to crashkernel bootargs works, and TBH it was
> >>> > > my initial thought process as well, but I am not sure if this will
> >>> > > cause any regressions on aarch64 systems which use crashdump feature.
> >>> >
> >>> > It should be fine since we use numa=off by default for all other arches
> >>> > ie. x86, ppc64 and s390. Actually disabling numa in kdump kernel can save
> >>> > mm component memory usage.
> >>> >
> >>>
> >>> Forgot to say I means in RHEL and Fedora we use numa=off for kdump..
> >>
> >> Thank you for the clarification.
> >> (It might be better to make numa off automatically if maxcpus == 0 (and 1?).)
> >>
> >
> > Not sure if we can leave this to the distribution-specific kdump
> > scripts (as the crashkernel boot can be held up for sufficient time
> > and may appear stuck). The distribution scripts may be different (for
> > e.g. ubuntu and RHEL/fedora) across distributions and may have
> > different bootarg options.
> >
> > So how about considering a kernel fix only which doesn't require
> > relying on changing the distribution-specific kdump scripts, as we
> > should avoid introducing a regression while trying to fix a regression
> > :)
> >
> > Just my 2 cents.
> >
>
> Sorry for the delay but I was on holidays in the last week.
>
> Are you planning to send a patch to fix this issue or do you want me
> to send a RFC version instead?
I should have submitted my own patch before my new year holidays,
but I will do so as soon as possible.
Thanks,
-Takahiro AKASHI
> i think this is a blocking issue for aarch64 kdump support on newer
> kernels (v4.14) and we are already hearing about this issue from other
> users as well, so it would be great to get this fixed now that we have
> root-caused the issue and found a possible way around.
>
> Regards,
> Bhupesh
^ permalink raw reply
* [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly
From: Appana Durga Kedareswara Rao @ 2018-01-09 4:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109044858.GN18649@localhost>
Hi,
>On Mon, Jan 08, 2018 at 05:25:01PM +0000, Appana Durga Kedareswara Rao
>wrote:
>> Hi,
>>
>> <Snip>
>> >> >> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
>> >> >> + xdev->common.src_addr_widths = BIT(addr_width / 8);
>> >> >
>> >> >Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers?
>> >> >What is value of addr_width here typically? Usually controllers
>> >> >can support different widths and this is a surprise that you
>> >> >support only one value
>> >>
>> >> Controller supports address width of 32 and 64.
>> >
>> >Then this should have both 32 and 64 values here
>>
>> Address width is configurable parameter at the h/w level.
>> Since this IP is a soft IP user can create a design with either 32-bit
>> or 64-bit address configuration.
>
>and not both right?
Yes not both at the same time...
Axi dma controller can be configured for either 32-bit or 64-bit address...
Regards,
Kedar.
>
>> Currently we are reading this configuration through device-tree (xlnx,
>> addr-width property)
>> https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git/tr
>> ee/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt#n19
>> Based on the h/w configuration setting the dst_addr_widths/src_addr_widths
>variables in this patch.
>> Please let me know if you are still not clear with my explanation will explain in
>detail...
>>
>> Regards,
>> Kedar.
>>
>> >
>> >> addr_width typical values are 32-bit or 64-bit .
>> >> Here addr_width is device-tree parameter...
>> >> my understanding of src_addr_widths/dst_addr_widths is, it is a bit
>> >> mask of the address with in bytes that DMA supports, please correct
>> >> if my
>> >understanding is wrong.
>> >>
>> >> Regards,
>> >> Kedar.
>> >>
>> >> >
>> >> >--
>> >> >~Vinod
>> >
>> >--
>> >~Vinod
>
>--
>~Vinod
>--
>To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body
>of a message to majordomo at vger.kernel.org More majordomo info at
>http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox