* [GIT PULL 5/5] arm64: tegra: Changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-5-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:19 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> arm64: tegra: Changes for v4.16-rc1
>
> This set of patches enables a bunch of new features on Jetson TX2 that
> were finally unblocked by the GPIO driver getting merged for v4.15.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 4/5] ARM: tegra: Device tree changes for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-4-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> ARM: tegra: Device tree changes for v4.16-rc1
>
> These changes enable the video decoder engine found on Tegra20 SoCs.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 1/5] dt-bindings: Updates for v4.16-rc1
From: Arnd Bergmann @ 2017-12-21 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-1-thierry.reding@gmail.com>
On Wed, Dec 20, 2017 at 8:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> ----------------------------------------------------------------
> dt-bindings: Updates for v4.16-rc1
>
> This contains a set of patches that extend existing bindings with support
> for Tegra186.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v3 4/5] ARM: davinci: convert to common clock framework
From: David Lechner @ 2017-12-21 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d8833055-51ad-a71f-f326-22719cfc1770@ti.com>
On 12/21/2017 06:34 AM, Sekhar Nori wrote:
>
> All I can say is that issue has been noted within TI and I believe
> (hope) that help is on the way!
>
> If we do go the completely separate clock driver route, I think even
> migrating outside of mach-davinci should not be that tough.
>
Based on your responses, I think we have a pretty clear path forward
now. I'm sold on the all at once approach.
If you can pick up the first 3 patches from this series, I have one or
two more I can send that depend on those changes that are not
intermediate steps.
If TI is able to spend some time on this, it would be nice if they could
look at fixing up the reset framework since that is something I haven't
attempted yet.
And I can work on fixing up the PLL and PSC drivers I already have in
drivers/clk/davinci.
^ permalink raw reply
* [GIT PULL 3/3] ARM: defconfig: exynos: config for v4.16
From: Arnd Bergmann @ 2017-12-21 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220173643.5840-2-krzk@kernel.org>
On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.16
>
> for you to fetch changes up to 6b732dfb698991b5f518be1ddf329c1c2eb3d7cb:
>
> ARM: exynos_defconfig: Enable CONFIG_EXYNOS_IOMMU (2017-12-14 18:57:38 +0100)
>
> ----------------------------------------------------------------
> Samsung defconfig changes for v4.16
>
> 1. Enable missing drivers for supported Exynos boards (PMU, CEC, MHL
> bridge, ASoC for Odroid XU3/XU4).
> 2. Enable Exynos IOMMU driver on exynos_defconfig.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/3] arm64: dts: exynos: DTS for v4.16
From: Arnd Bergmann @ 2017-12-21 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220173643.5840-4-krzk@kernel.org>
On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Samsung DTS ARM64 changes for v4.16
>
> 1. Add CPU perf counters to Exynos5433.
> 2. Add missing power domains to Exynos5433.
> 3. Add NFC chip to Exynos5433 TM2/TM2E.
> 4. Fix obscure bugs on I2C transfers to MHL chip on TM2/TM2E.
Pulled into next/dt, thanks!
One question: do you know if anyone is working on support for the newer
Exynos chips, or the Nexell S5P6818 series? It seems odd that none of
the chips from the past three years are supported yet.
Arnd
^ permalink raw reply
* [PATCH 03/10] arm64: handle 52-bit addresses in TTBR
From: Catalin Marinas @ 2017-12-21 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e887ef9f-8d68-8f1f-8bc5-ea5ad4cb2b51@arm.com>
On Thu, Dec 14, 2017 at 06:50:05PM +0000, Marc Zyngier wrote:
> On 13/12/17 17:07, Kristina Martsenko wrote:
> > diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
> > index eb0c2bd90de9..2b3104af79d0 100644
> > --- a/arch/arm64/include/asm/pgtable-hwdef.h
> > +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> > @@ -16,6 +16,8 @@
> > #ifndef __ASM_PGTABLE_HWDEF_H
> > #define __ASM_PGTABLE_HWDEF_H
> >
> > +#include <asm/memory.h>
> > +
> > /*
> > * Number of page-table levels required to address 'va_bits' wide
> > * address, without section mapping. We resolve the top (va_bits - PAGE_SHIFT)
> > @@ -277,4 +279,11 @@
> > #define TCR_HA (UL(1) << 39)
> > #define TCR_HD (UL(1) << 40)
> >
> > +/*
> > + * TTBR
> > + */
> > +#ifdef CONFIG_ARM64_PA_BITS_52
> > +#define TTBR_BADDR_MASK_52 (((UL(1) << 46) - 1) << 2)
>
> This really hurts by brain. How about
>
> #define TTBR_BADDR_MASK_52 GENMASK_UL(47, 2)
This file is included in assembly code and GENMASK_ULL has a C-only
version (include/linux/bitops.h). I'll leave Kristina's original code in
place.
> instead, together with a comment saying that TTBR[1] is RES0.
I can add the comment.
--
Catalin
^ permalink raw reply
* [PATCH v2] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Linus Walleij @ 2017-12-21 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2+oa+yzAcpmB+YMuCYMxtFdYknETUtKShZX56G6m76Gg@mail.gmail.com>
On Thu, Dec 21, 2017 at 4:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Dec 20, 2017 at 1:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> Alter the DaVinci GPIO recovery fetch to use descriptors
>> all the way down into the board files.
>>
>> Cc: arm at kernel.org
>> Cc: Kevin Hilman <khilman@kernel.org>
>> Cc: Keerthy <j-keerthy@ti.com>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Acked-by: Sekhar Nori <nsekhar@ti.com>
>> Tested-by: Sekhar Nori <nsekhar@ti.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v1->v2:
>> - Change gpiochip name from gpio_davinci.0 to gpio_davinci, simply.
>
> This seems to clash with "i2c: davinci: Add PM Runtime Support", please
> rebase on top of v4.15-rc and resend.
Since it is dependent on changes in the I2C tree and the
current patch is based on linux-next I guess something
got applied ahead of me, I guess I should just rebase
on Wolfram's tree.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL 1/3] ARM: dts: exynos: DTS for v4.16
From: Arnd Bergmann @ 2017-12-21 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220173643.5840-3-krzk@kernel.org>
On Wed, Dec 20, 2017 at 6:36 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> ----------------------------------------------------------------
> Samsung DTS ARM changes for 4.16
>
> 1. Add sound support to Odroid XU4 (and adjustments to Odroid XU3).
> 2. Enable WiFi on Trats2.
> 3. Add CPU perf counters to Exynos54xx.
> 4. Add power domains to certain chipsets.
> 5. Add Exynos4412 ISP clock controller which finally solves freezes when
> accessing ISP clocks while having the ISP power domain turned off.
> 6. Add Pseudo and True RNG to Exynos5.
> 7. Minor fixes for Trats2, Odroid XU3/XU4, Exynos5410.
> 8. Cleanup of some of DTC warnings
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] Gemini DTS updates for v4.16 take one
From: Arnd Bergmann @ 2017-12-21 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYDy202SZ5kOGU5vVsTAgH4kAAMWzaQ1O9jR3d9zGAPPw@mail.gmail.com>
On Sat, Dec 16, 2017 at 8:37 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Hi ARM SoC folks,
>
> I was hoping to send more DTS updates but the drivers are
> waiting for review, so might as well get the DTS updates that
> are finished upstream for linux-next.
>
> Please pull this to some gemini DTS branch, I'll build more
> patches on top of this if need be.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH V2 3/9] ARM: stm32: prepare stm32 family to welcome armv7 architecture
From: Ludovic BARRE @ 2017-12-21 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8092d8f9-c097-136f-4f6f-0b7ffea17c91@st.com>
hi Arnd
just a ping, on Alex's proposal (below) about armv7m_restart
(Currently "restart" is not functional on stm32 MCU).
BR
Ludo
On 12/19/2017 03:38 PM, Alexandre Torgue wrote:
>
>
> On 12/18/2017 09:24 PM, Arnd Bergmann wrote:
>> On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com>
>> wrote:
>>> From: Ludovic Barre <ludovic.barre@st.com>
>>>
>>> This patch prepares the STM32 machine for the integration of Cortex-A
>>> based microprocessor (MPU), on top of the existing Cortex-M
>>> microcontroller family (MCU). Since both MCUs and MPUs are sharing
>>> common hardware blocks we can keep using ARCH_STM32 flag for most of
>>> them. If a hardware block is specific to one family we can use either
>>> ARM_SINGLE_ARMV7M or ARCH_MULTI_V7 flag.
>>>
>>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>>
>> Looks good overall. Two more small comments:
>>
>>
>>>
>>> +if ARCH_STM32
>>> +
>>> ? config MACH_STM32F429
>>> -?????? bool "STMicrolectronics STM32F429"
>>> -?????? depends on ARCH_STM32
>>> +?????? bool "STMicroelectronics STM32F429"
>>> +?????? depends on ARM_SINGLE_ARMV7M
>>> ???????? default y
>>
>> Instead of the explicit dependency for each board, I'd leave the
>> surrounding
>> 'if ARM_SINGLE_ARMV7M'. I think you had in v1.
>>
>>> diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
>>> index bd0b7b5..5940af1 100644
>>> --- a/arch/arm/mach-stm32/Makefile
>>> +++ b/arch/arm/mach-stm32/Makefile
>>> @@ -1 +1 @@
>>> -obj-y += board-dt.o
>>> +obj-$(CONFIG_ARM_SINGLE_ARMV7M) += board-mcu-dt.o
>>> diff --git a/arch/arm/mach-stm32/board-dt.c
>>> b/arch/arm/mach-stm32/board-mcu-dt.c
>>> similarity index 100%
>>> rename from arch/arm/mach-stm32/board-dt.c
>>> rename to arch/arm/mach-stm32/board-mcu-dt.c
>>
>> Why the rename? I don't expect the new machines to have any notable
>> contents in a board file, if any at all, so just use one file for both.
>> I see the board-dt.c file refers to armv7m_restart, we can either put
>> that in an #ifdef, or find a way to make it the default for all armv7-m
>> platforms that don't provide any other restart method.
>>
> Currently "restart" is not functional on stm32 MCU (at least for
> stm32f746, I will check on others MCU). My fear is if Ludovic made some
> patches to make "armv7m_restart" the default ".restart" function for all
> armv7-m platform, he will not be able to test it on stm32 MCU (as it is
> not currently working). I propose to do it in 2 steps:
>
> 1-Keep as you suggest only one board-dt.c file for both (MCU and MPU)
> and remove ".restart" function.
>
> 2-Investigate and send patches around ".restart" for both in an other
> series.
I resend
>
> regards
> Alex
>
>
>> ????? Arnd
>>
^ permalink raw reply
* [PATCH] PCI: exynos: remove redundant code in exynos_pcie_establish_link
From: Jingoo Han @ 2017-12-21 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b81a09be-1873-ab81-dcb2-c3b29ff7e430@samsung.com>
On Tuesday, October 10, 2017 9:46 AM, Pankaj Dubey wrote:
>
> Hi Jingoo,
>
>
> On 10/09/2017 09:50 PM, Jingoo Han wrote:
> > On Monday, October 9, 2017 10:44 AM, Krzysztof Kozlowski wrote:
> >> On Mon, Oct 9, 2017 at 4:14 PM, Pankaj Dubey <pankaj.dubey@samsung.com>
> >> wrote:
> >>> From: Anvesh Salveru <anvesh.s@samsung.com>
> >>>
> >>> In exynos_pcie_establish_link if driver is not using generic phy,
> >>> we are resetting PHY twice, which is redundant, so this patch removes
> >> Hi Pankaj,
> >>
> >> This lacks the information why it is redundant.
> > (I resend this mail, because email address of pci list was corrupted.)
> Thanks, somehow I typed wrong email id.
> > I think so, too.
> >
> > Did you test this code on some boards with Exynos PCIe?
> > Or did hardware engineers confirm this?
> > Please add more information on this patch.
> I have replied reason behind this patch in reply to Krzysztof, hope I am
> able to
> explain logic behind this change.
>
> I do not have access to Exynos5440 PCIe, and this PHY_COMMON_RESET is not
> applicable to other Exynos SoC which I have with me, so I can't test
> this change,
> but if you see the change it is an obvious change, before introducing
> generic phy
> support to this driver PHY_COMMON_RESET was programmed only once, then
> in case platform is not using PHY it suppose to be done only once during
> linkup.
> I am not sure when Jaehoon introduced this patch, he verified this on
> Exynos5440 or
> not. We are just trying to make the logic as it was before without
> affecting anything.
>
> Thanks,
> Pankaj Dubey
> > Best regards,
> > Jingoo Han
> >
> >>> repeated lines of code for PHY reset.
> >>>
> >>> Signed-off-by: Anvesh Salveru <anvesh.s@samsung.com>
> >> Your Signed-off-by is needed here.
Sorry for being late.
I checked that this patch is right.
Can you send this patch again with your Signed-off-by?
Also, you can add my Acked-by to your new patch.
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>> ---
> >>> drivers/pci/dwc/pci-exynos.c | 7 -------
> >>> 1 file changed, 7 deletions(-)
> >>>
> >>> diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-
> exynos.c
> >>> index 5596fde..85d2f4b 100644
> >>> --- a/drivers/pci/dwc/pci-exynos.c
> >>> +++ b/drivers/pci/dwc/pci-exynos.c
> >>> @@ -423,13 +423,6 @@ static int exynos_pcie_establish_link(struct
> >> exynos_pcie *ep)
> >>> exynos_pcie_deassert_phy_reset(ep);
> >>> exynos_pcie_power_on_phy(ep);
> >>> exynos_pcie_init_phy(ep);
> >>> -
> >>> - /* pulse for common reset */
> >>> - exynos_pcie_writel(ep->mem_res->block_base, 1,
> >>> - PCIE_PHY_COMMON_RESET);
> >>> - udelay(500);
> >>> - exynos_pcie_writel(ep->mem_res->block_base, 0,
> >>> - PCIE_PHY_COMMON_RESET);
> >>> }
> >>>
> >>> /* pulse for common reset */
> >>> --
> >>> 2.7.4
> >>>
> >
> >
> >
> >
^ permalink raw reply
* [PATCH] clk: divider: fix incorrect usage of container_of
From: Jerome Brunet @ 2017-12-21 16:30 UTC (permalink / raw)
To: linux-arm-kernel
divider_recalc_rate() is an helper function used by clock divider of
different types, so the structure containing the 'hw' pointer is not
always a 'struct clk_divider'
At the following line:
> div = _get_div(table, val, flags, divider->width);
in several cases, the value of 'divider->width' is garbage as the actual
structure behind this memory is not a 'struct clk_divider'
Fortunately, this width value is used by _get_val() only when
CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so
far when the structure is not a 'struct clk_divider'. This is probably
why we did not notice this bug before
Fixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Hi Stephen, Mike,
In addition to clock, this patch also touch the rtc and drm directories.
As it is changing the API of the helper function, I have this fix in a
single commit to avoid breaking bisect.
Please let me know if you prefer to do differently.
Cheers
Jerome
drivers/clk/clk-divider.c | 7 +++----
drivers/clk/hisilicon/clkdivider-hi6220.c | 2 +-
drivers/clk/nxp/clk-lpc32xx.c | 2 +-
drivers/clk/qcom/clk-regmap-divider.c | 2 +-
drivers/clk/sunxi-ng/ccu_div.c | 2 +-
drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 2 +-
drivers/rtc/rtc-ac100.c | 6 ++++--
include/linux/clk-provider.h | 2 +-
8 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 4ed516cb7276..b49942b9fe50 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -118,12 +118,11 @@ static unsigned int _get_val(const struct clk_div_table *table,
unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate,
unsigned int val,
const struct clk_div_table *table,
- unsigned long flags)
+ unsigned long flags, unsigned long width)
{
- struct clk_divider *divider = to_clk_divider(hw);
unsigned int div;
- div = _get_div(table, val, flags, divider->width);
+ div = _get_div(table, val, flags, width);
if (!div) {
WARN(!(flags & CLK_DIVIDER_ALLOW_ZERO),
"%s: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set\n",
@@ -145,7 +144,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
val &= div_mask(divider->width);
return divider_recalc_rate(hw, parent_rate, val, divider->table,
- divider->flags);
+ divider->flags, divider->width);
}
static bool _is_valid_table_div(const struct clk_div_table *table,
diff --git a/drivers/clk/hisilicon/clkdivider-hi6220.c b/drivers/clk/hisilicon/clkdivider-hi6220.c
index a1c1f684ad58..9f46cf9dcc65 100644
--- a/drivers/clk/hisilicon/clkdivider-hi6220.c
+++ b/drivers/clk/hisilicon/clkdivider-hi6220.c
@@ -56,7 +56,7 @@ static unsigned long hi6220_clkdiv_recalc_rate(struct clk_hw *hw,
val &= div_mask(dclk->width);
return divider_recalc_rate(hw, parent_rate, val, dclk->table,
- CLK_DIVIDER_ROUND_CLOSEST);
+ CLK_DIVIDER_ROUND_CLOSEST, dclk->width);
}
static long hi6220_clkdiv_round_rate(struct clk_hw *hw, unsigned long rate,
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index b669a5c10fee..f5d815f577e0 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -956,7 +956,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
val &= div_mask(divider->width);
return divider_recalc_rate(hw, parent_rate, val, divider->table,
- divider->flags);
+ divider->flags, divider->width);
}
static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
diff --git a/drivers/clk/qcom/clk-regmap-divider.c b/drivers/clk/qcom/clk-regmap-divider.c
index 53484912301e..928fcc16ee27 100644
--- a/drivers/clk/qcom/clk-regmap-divider.c
+++ b/drivers/clk/qcom/clk-regmap-divider.c
@@ -59,7 +59,7 @@ static unsigned long div_recalc_rate(struct clk_hw *hw,
div &= BIT(divider->width) - 1;
return divider_recalc_rate(hw, parent_rate, div, NULL,
- CLK_DIVIDER_ROUND_CLOSEST);
+ CLK_DIVIDER_ROUND_CLOSEST, divider->width);
}
const struct clk_ops clk_regmap_div_ops = {
diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index baa3cf96507b..302a18efd39f 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -71,7 +71,7 @@ static unsigned long ccu_div_recalc_rate(struct clk_hw *hw,
parent_rate);
val = divider_recalc_rate(hw, parent_rate, val, cd->div.table,
- cd->div.flags);
+ cd->div.flags, cd->div.width);
if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
val /= cd->fixed_post_div;
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c
index fe15aa64086f..71fe60e5f01f 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c
@@ -698,7 +698,7 @@ static unsigned long dsi_pll_14nm_postdiv_recalc_rate(struct clk_hw *hw,
val &= div_mask(width);
return divider_recalc_rate(hw, parent_rate, val, NULL,
- postdiv->flags);
+ postdiv->flags, width);
}
static long dsi_pll_14nm_postdiv_round_rate(struct clk_hw *hw,
diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c
index 9e336184491c..0282ccc6181c 100644
--- a/drivers/rtc/rtc-ac100.c
+++ b/drivers/rtc/rtc-ac100.c
@@ -137,13 +137,15 @@ static unsigned long ac100_clkout_recalc_rate(struct clk_hw *hw,
div = (reg >> AC100_CLKOUT_PRE_DIV_SHIFT) &
((1 << AC100_CLKOUT_PRE_DIV_WIDTH) - 1);
prate = divider_recalc_rate(hw, prate, div,
- ac100_clkout_prediv, 0);
+ ac100_clkout_prediv, 0,
+ AC100_CLKOUT_PRE_DIV_WIDTH);
}
div = (reg >> AC100_CLKOUT_DIV_SHIFT) &
(BIT(AC100_CLKOUT_DIV_WIDTH) - 1);
return divider_recalc_rate(hw, prate, div, NULL,
- CLK_DIVIDER_POWER_OF_TWO);
+ CLK_DIVIDER_POWER_OF_TWO,
+ AC100_CLKOUT_DIV_WIDTH);
}
static long ac100_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 73ac87f34df9..4c4001086447 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -412,7 +412,7 @@ extern const struct clk_ops clk_divider_ro_ops;
unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate,
unsigned int val, const struct clk_div_table *table,
- unsigned long flags);
+ unsigned long flags, unsigned long width);
long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
unsigned long rate, unsigned long *prate,
const struct clk_div_table *table,
--
2.14.3
^ permalink raw reply related
* [GIT PULL] tee dynamic shm for v4.16
From: Arnd Bergmann @ 2017-12-21 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215132057.ang2xawtpzp5eb6o@jax>
On Fri, Dec 15, 2017 at 2:21 PM, Jens Wiklander
<jens.wiklander@linaro.org> wrote:
> Hello arm-soc maintainers,
>
> Please pull these tee driver changes. This implements support for dynamic
> shared memory support in OP-TEE. More specifically is enables mapping of
> user space memory in secure world to be used as shared memory.
>
> This has been reviewed and refined by the OP-TEE community at various
> places on Github during the last year. An earlier version of this pull
> request is used in the latest OP-TEE release (2.6.0). This has also been
> reviewed recently at the kernel mailing lists, with all comments from
> Mark Rutland <mark.rutland@arm.com> and Yury Norov
> <ynorov@caviumnetworks.com> addressed as far as I can tell.
>
> This isn't a bugfix so I'm aiming for the next merge window.
Given that Mark and Yury reviewed this, I'm assuming this is all
good and have now merged it. However I missed the entire discussion
about it, so I have one question about the implementation:
What happens when user space passes a buffer that is not
backed by regular memory but instead is something it has itself
mapped from a device with special page attributes or physical
properties? Could this be inconsistent when optee and user
space disagree on the caching attributes? Can you get into
trouble if you pass an area from a device that is read-only
in user space but writable from secure world?
Arnd
^ permalink raw reply
* [GIT PULL 3/3] dts changes for omaps for v4.16 merge window
From: Arnd Bergmann @ 2017-12-21 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <pull-1513266986-900907@atomide.com-3>
On Thu, Dec 14, 2017 at 4:58 PM, Tony Lindgren <tony@atomide.com> wrote:
> Dts related changes for omaps for v4.16 merge window
>
> These changes are mostly improvments for various devices.
> Note that these are based on my earlier fixes branch
> omap-for-v4.15/fixes-dt to avoid a pointless merge conflict
> between a fix and removal. The summary of changes is:
>
> - Fix audio codec reset pin for am335x-pepper and n900, this
> has been always broken and won't get fixed until the related
> driver changes are also merged in for v4.16, so not urgent
>
> - Fix tps65917 powerhold property for dra76-evm
>
> - Changes to logicpd boards to remove MTD partition information
> and to add support for omap35xx variants by setting up common
> dts files for the logicpd boards
>
> - Disable dra7 USB metastability workaround, this won't do
> anything until the related driver changes are also merged
> into v4.16, so not urgent
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/3] clock related dts changes for omaps for v4.16
From: Arnd Bergmann @ 2017-12-21 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <pull-1513266986-900907@atomide.com-2>
On Thu, Dec 14, 2017 at 4:58 PM, Tony Lindgren <tony@atomide.com> wrote:
> Clock related dts changes for omaps for v4.16 merge window
>
> This branch contains a series of dts changes from Tero Kristo to
> start using clkctrl clocks.
>
> Note that this branch is based on a merge of omap-for-v4.16/soc-signed
> and an immutable commit from Tero Kristo fe7020e64f04 ("clk: ti: omap4:
> clkctrl data fixes for opt-clocks") that is also in clk-next.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 1/3] soc changes for omaps for v4.16 merge window
From: Arnd Bergmann @ 2017-12-21 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <pull-1513266986-900907@atomide.com>
On Thu, Dec 14, 2017 at 4:58 PM, Tony Lindgren <tony@atomide.com> wrote:
> From: "Tony Lindgren" <tony@atomide.com>
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.16/soc-signed
>
> for you to fetch changes up to fdf3632938a646c13f7407f2f8c33ff81eed9c76:
>
> Merge branch '4.15-rc1-clkctrl-mach-omap2' of https://github.com/t-kristo/linux-pm into omap-for-v4.16/soc (2017-12-11 07:46:40 -0800)
>
> ----------------------------------------------------------------
> SoC changes for omaps for v4.16 merge window
>
> For most part this is a series from Tero Kristo to prepare things
> for using clkctrl clocks with DTS data. The other changes are to
> make few data structures const.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL v2 2/5] soc/tegra: Changes for v4.16-rc1
From: Thierry Reding @ 2017-12-21 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220191900.757-2-thierry.reding@gmail.com>
Hi ARM SoC maintainers,
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.16-soc-2
for you to fetch changes up to ccf151847b81a3ad779b64f5f71f0632f2009eb6:
soc/tegra: fuse: Explicitly request DMA channel from APB DMA driver (2017-12-21 17:04:12 +0100)
This includes two additional patches that have been sitting in patchwork
for a long time and that I had forgotten to include. Please ignore the
first pull request and pull this instead.
Thanks,
Thierry
----------------------------------------------------------------
soc/tegra: Changes for v4.16-rc1
Fuse and chip ID support for Tegra186 is added in this set of changes,
followed by some unification work for the PMC driver in order to avoid
code duplication between Tegra186 and prior chips.
This also contains a couple of fixes for reading fuses on Tegra20.
----------------------------------------------------------------
Dmitry Osipenko (2):
soc/tegra: fuse: Fix reading registers using DMA on Tegra20
soc/tegra: fuse: Explicitly request DMA channel from APB DMA driver
Thierry Reding (7):
dt-bindings: misc: Add Tegra186 MISC registers bindings
Merge branch 'for-4.16/dt-bindings' into for-4.16/soc
soc/tegra: fuse: Move register mapping check
soc/tegra: fuse: Warn if accessing unmapped registers
soc/tegra: fuse: Add Tegra186 chip ID support
soc/tegra: pmc: Parameterize driver
soc/tegra: pmc: Consolidate Tegra186 support
Timo Alho (1):
soc/tegra: fuse: Add Tegra186 support
.../bindings/misc/nvidia,tegra186-misc.txt | 12 +
drivers/soc/tegra/Kconfig | 5 +-
drivers/soc/tegra/Makefile | 1 -
drivers/soc/tegra/fuse/fuse-tegra.c | 4 +
drivers/soc/tegra/fuse/fuse-tegra20.c | 13 +-
drivers/soc/tegra/fuse/fuse-tegra30.c | 24 +-
drivers/soc/tegra/fuse/fuse.h | 4 +
drivers/soc/tegra/fuse/tegra-apbmisc.c | 11 +-
drivers/soc/tegra/pmc-tegra186.c | 169 ------------
drivers/soc/tegra/pmc.c | 304 +++++++++++++++++----
include/soc/tegra/pmc.h | 12 +
11 files changed, 322 insertions(+), 237 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.txt
delete mode 100644 drivers/soc/tegra/pmc-tegra186.c
^ permalink raw reply
* [PATCH 2/2] clk: rockchip: limit clock rate in the rockchip_fractional_approximation()
From: Alexander Kochetkov @ 2017-12-21 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513872282-5370-1-git-send-email-al.kochet@gmail.com>
rockchip_fractional_approximation() can choose clock rate that can
be larger than one configured using clk_set_max_rate(). Request
to setup correct clock rate whose parent rate will be adjusted
to out of range value will fail with -EINVAL.
Fixes: commit 5d890c2df900 ("clk: rockchip: add special approximation
to fix up fractional clk's jitter").
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
drivers/clk/rockchip/clk.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index 35dbd63..3c1fb0d 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -175,6 +175,7 @@ static void rockchip_fractional_approximation(struct clk_hw *hw,
{
struct clk_fractional_divider *fd = to_clk_fd(hw);
unsigned long p_rate, p_parent_rate;
+ unsigned long min_rate = 0, max_rate = 0;
struct clk_hw *p_parent;
unsigned long scale;
@@ -182,6 +183,12 @@ static void rockchip_fractional_approximation(struct clk_hw *hw,
if ((rate * 20 > p_rate) && (p_rate % rate != 0)) {
p_parent = clk_hw_get_parent(clk_hw_get_parent(hw));
p_parent_rate = clk_hw_get_rate(p_parent);
+ clk_hw_get_boundaries(clk_hw_get_parent(hw),
+ &min_rate, &max_rate);
+ if (p_parent_rate < min_rate)
+ p_parent_rate = min_rate;
+ if (p_parent_rate > max_rate)
+ p_parent_rate = max_rate;
*parent_rate = p_parent_rate;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] clk: rename clk_core_get_boundaries() to clk_hw_get_boundaries() and expose
From: Alexander Kochetkov @ 2017-12-21 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513872282-5370-1-git-send-email-al.kochet@gmail.com>
In order to provide a way to know clock limits to clock providers.
The patch is needed for fixing commit 5d890c2df900 ("clk: rockchip:
add special approximation to fix up fractional clk's jitter").
Custom approximation function introduced by the patch, can
select frequency rate larger than one configured using
clk_set_max_rate().
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
drivers/clk/clk.c | 14 ++++++++------
include/linux/clk-provider.h | 2 ++
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index c8d83ac..8943aac 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -421,10 +421,11 @@ struct clk *__clk_lookup(const char *name)
return !core ? NULL : core->hw->clk;
}
-static void clk_core_get_boundaries(struct clk_core *core,
- unsigned long *min_rate,
- unsigned long *max_rate)
+void clk_hw_get_boundaries(struct clk_hw *hw,
+ unsigned long *min_rate,
+ unsigned long *max_rate)
{
+ struct clk_core *core = hw->core;
struct clk *clk_user;
*min_rate = core->min_rate;
@@ -436,6 +437,7 @@ static void clk_core_get_boundaries(struct clk_core *core,
hlist_for_each_entry(clk_user, &core->clks, clks_node)
*max_rate = min(*max_rate, clk_user->max_rate);
}
+EXPORT_SYMBOL_GPL(clk_hw_get_boundaries);
void clk_hw_set_rate_range(struct clk_hw *hw, unsigned long min_rate,
unsigned long max_rate)
@@ -894,7 +896,7 @@ unsigned long clk_hw_round_rate(struct clk_hw *hw, unsigned long rate)
int ret;
struct clk_rate_request req;
- clk_core_get_boundaries(hw->core, &req.min_rate, &req.max_rate);
+ clk_hw_get_boundaries(hw, &req.min_rate, &req.max_rate);
req.rate = rate;
ret = clk_core_round_rate_nolock(hw->core, &req);
@@ -924,7 +926,7 @@ long clk_round_rate(struct clk *clk, unsigned long rate)
clk_prepare_lock();
- clk_core_get_boundaries(clk->core, &req.min_rate, &req.max_rate);
+ clk_hw_get_boundaries(clk->core->hw, &req.min_rate, &req.max_rate);
req.rate = rate;
ret = clk_core_round_rate_nolock(clk->core, &req);
@@ -1353,7 +1355,7 @@ static struct clk_core *clk_calc_new_rates(struct clk_core *core,
if (parent)
best_parent_rate = parent->rate;
- clk_core_get_boundaries(core, &min_rate, &max_rate);
+ clk_hw_get_boundaries(core->hw, &min_rate, &max_rate);
/* find the closest rate and parent clk/rate */
if (core->ops->determine_rate) {
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5100ec1..2f10999 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -755,6 +755,8 @@ int __clk_mux_determine_rate_closest(struct clk_hw *hw,
void clk_hw_reparent(struct clk_hw *hw, struct clk_hw *new_parent);
void clk_hw_set_rate_range(struct clk_hw *hw, unsigned long min_rate,
unsigned long max_rate);
+void clk_hw_get_boundaries(struct clk_hw *hw, unsigned long *min_rate,
+ unsigned long *max_rate);
static inline void __clk_hw_set_clk(struct clk_hw *dst, struct clk_hw *src)
{
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] Fix clock rate in the rockchip_fractional_approximation()
From: Alexander Kochetkov @ 2017-12-21 16:04 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here are two patches fixing issue in the rockchip_fractional_approximation().
rockchip_fractional_approximation() can select clock rate whose
value will violate clock limit settings (i.e. one configured with
clk_set_max_rate() and clk_set_min_rate()).
rockchip_fractional_approximation() was introduced by commit 5d890c2df900
("clk: rockchip: add special approximation to fix up fractional clk's jitter")
whose description states that setting denominator 20 times larger than
numerator will generate precise clock frequency. It's strange, because
on my custom rk3188-based board and on radxa rock I've observed strange
hardware issues. I2S, for example, sometimes doesn't setup correct
rate on external SCLK_I2S0. UART0, for example, started to receive '\0'
characters instead of valid symbols, signals on UART_RX was good.
So, I use clk_set_max_rate() to limit max value of i2s0_pre, uart0_pre,
uart1_pre, uart2_pre, uart3_pre to value of aclk_cpu_pre. That fixes
strange I2S and UART issues for me. If that make sense, than I can
send the patch. But it will logically conflict with commit 5d890c2df900
("clk: rockchip: add special approximation to fix up fractional clk's jitter").
Alexander Kochetkov (2):
clk: rename clk_core_get_boundaries() to clk_hw_get_boundaries() and
expose
clk: rockchip: limit clock rate in the
rockchip_fractional_approximation()
drivers/clk/clk.c | 14 ++++++++------
drivers/clk/rockchip/clk.c | 7 +++++++
include/linux/clk-provider.h | 2 ++
3 files changed, 17 insertions(+), 6 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [GIT PULL] TI DaVinci fixes for v4.15
From: Arnd Bergmann @ 2017-12-21 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7d86583e-a4e7-fd44-3caf-9bfa7e1a1491@ti.com>
On Tue, Dec 19, 2017 at 7:15 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.15
>
> for you to fetch changes up to 451df7d110b82998c04a80d0de0f1e79aaa7792a:
>
> ARM: davinci: fix mmc entries in dm365's dma_slave_map (2017-12-08 16:12:21 +0530)
>
> ----------------------------------------------------------------
> DaVinci fixes for v4.15 consiting of fixes to make EDMA and MMC/SD
> work on DM365 and a fix for battery voltage monitoring on Lego EV3.
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: at91: Fixes for 4.15
From: Arnd Bergmann @ 2017-12-21 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220101614.GA844@piout.net>
On Wed, Dec 20, 2017 at 11:16 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> Arnd, Olof,
>
> A single fix for 4.15. The driver part of it will land in 4.15 through
> the hwmon tree.
>
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.15-dt-fixes
>
> for you to fetch changes up to bc53e3aa88e8240823c1c440e6bab3c3a5ba5f59:
>
> ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850 (2017-12-04 20:30:38 +0100)
>
> ----------------------------------------------------------------
> Fixes for 4.15:
>
> - tse850-3: fix an i2c timeout issue
>
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/2] Rockchip dts64 fixes for 4.15
From: Arnd Bergmann @ 2017-12-21 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2690908.kxVfvpsLEa@phil>
On Wed, Dec 13, 2017 at 7:57 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.15-rockchip-dts64fixes-1
>
> for you to fetch changes up to bc631943faba6fc3f755748091ada31798fb7d50:
>
> arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now (2017-12-06 01:14:20 +0100)
>
> ----------------------------------------------------------------
> Another trailing interrupt-cell 0 removed.
>
> Removed as well got the vdd_log regulator from the rk3399-puma board.
> While it is there, the absence of any user makes it prone to configuration
> problems when the pwm-regulator takes over the boot-up default and wiggles
> settings there. Case in question was the PCIe host not working anymore.
> With vdd_log removed for the time being, PCIe on Puma works again.
>
> And a second stopgap is limiting the speed of the gmac on the rk3328-rock64
> to 100MBit. While the hardware can reach 1GBit, currently it is not stable.
> Limiting it to 100MBit for the time being allows nfsroots to be used again
> until the problem is identified.
Pulled into fixes, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 1/2] Rockchip dts32 fixes for 4.15
From: Arnd Bergmann @ 2017-12-21 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6469701.IcmEy0bVhn@phil>
On Wed, Dec 13, 2017 at 7:56 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> Hi Arnd, Kevin, Olof,
>
> please find below and in the next mail some fixes for things cropping up
> recently, which may hopefully go into 4.15-rc.
Pulled into fixes, thanks!
Arnd
^ 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