* [PATCH v3 03/14] ARM: DT: STiH4xx: Simplify clock binding of STiH4xx platforms
From: Patrice Chotard @ 2016-09-15 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472473626-15398-4-git-send-email-gabriel.fernandez@st.com>
On 08/29/2016 02:26 PM, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch simplifies the clock binding because we had too much detail.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> arch/arm/boot/dts/stih407-clock.dtsi | 18 +++++++++---------
> arch/arm/boot/dts/stih410-clock.dtsi | 16 ++++++++--------
> arch/arm/boot/dts/stih418-clock.dtsi | 16 ++++++++--------
> 3 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/boot/dts/stih407-clock.dtsi b/arch/arm/boot/dts/stih407-clock.dtsi
> index ad45f5e..38a56d7 100644
> --- a/arch/arm/boot/dts/stih407-clock.dtsi
> +++ b/arch/arm/boot/dts/stih407-clock.dtsi
> @@ -42,7 +42,7 @@
[...]
> @@ -309,7 +309,7 @@
>
> clk_s_d3_quadfs: clk-s-d3-quadfs at 9107000 {
> #clock-cells = <1>;
> - compatible = "st,stih407-quadfs660-D", "st,quadfs";
> + compatible = "st,quadfs";
> reg = <0x9107000 0x1000>;
>
> clocks = <&clk_sysin>;
>
Hi Gabriel
Applied on STi tree for v4.9
Thanks
^ permalink raw reply
* [GIT PULL] arm64: X-Gene platforms DTS changes queued for 4.9 - part1
From: Will Deacon @ 2016-09-15 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDmMEWEd4o-tf4Kcqy7PP-abBg=Q1-Qdvv5CoDdoLEvi=Q@mail.gmail.com>
On Wed, Sep 14, 2016 at 06:57:59PM -0700, Duc Dang wrote:
> On Wed, Sep 14, 2016 at 7:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday, September 2, 2016 11:46:31 AM CEST Duc Dang wrote:
> >> Hi Arnd, Olof,
> >>
> >> This is the first part of DTS changes for X-Gene platforms targeted for 4.9.
> >>
> >> The changes include:
> >> + X-Gene Soc PMU support patch set from Tai Nguyen (v10 reviewed by
> >> Mark, DT binding document acked by Rob [1] and was suggested to merge
> >> via am-soc tree by Will [2])
> >> + Follow up patch to enable DT entry for SoC PMU on X-Gene v2
> >> + Correct PCIe legacy interrupt mode to level-active high
> >> + DTS entry for X-Gene hwmon (v4 acked by Guenter, DT binding document
> >> and driver is in linux-next now [3])
> >>
> >> Regards,
> >> Duc Dang.
> >
> > Sorry for the long delay, I've just now started looking at the dts changes
> > for arm64. The changes to arch/arm64/boot/dts look fine, but I don't
> > want to mix driver changes with dts changes, as we use separate
> > branches for those.
> >
> > Please send this again as two pull requests, one for the dts changes, and
> > one for the rest (pmu driver, binding and MAINTAINERS file). Please
> > also include an explanation in the tag description about why this gets
> > merged through arm-soc. I see that Will suggested doing it that way,
> > but I don't see what the reason is. We normally don't touch that directory.
> Hi Arnd,
>
> I am not clear about the reason either. Probably we don't have a
> dedicated tree for SoC PMU?
That's right, there isn't a dedicated tree for SoC PMUs. I tend to handle
the architected PMUs (e.g. the ones in the CPUs), but other PMUs have
been ad-hoc in the past. That said, Mark and I do tend to review PMU
drivers, because the internal perf interface is pretty easy to get wrong.
Arnd -- what would you like to see here? I could collect SoC PMU patches
together and send you a pull request, or would you like me to take them via
the arm64 tree? It's worth noting that we have PMU drivers under drivers/bus
and drivers/hwtracing too, and I *think* arm-soc has handled those in the
past.
Will
^ permalink raw reply
* [PATCH v7 22/22] iommu/dma: Avoid PCI host bridge windows
From: Marek Szyprowski @ 2016-09-15 7:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbdc42fa-ea35-945f-3e2a-e0ab03fc997d@arm.com>
Hi Robin,
On 2016-09-14 15:25, Robin Murphy wrote:
> On 14/09/16 13:35, Marek Szyprowski wrote:
>> On 2016-09-14 13:10, Robin Murphy wrote:
>>> On 14/09/16 11:55, Marek Szyprowski wrote:
>>>> On 2016-09-12 18:14, Robin Murphy wrote:
>>>>> With our DMA ops enabled for PCI devices, we should avoid allocating
>>>>> IOVAs which a host bridge might misinterpret as peer-to-peer DMA and
>>>>> lead to faults, corruption or other badness. To be safe, punch out
>>>>> holes
>>>>> for all of the relevant host bridge's windows when initialising a DMA
>>>>> domain for a PCI device.
>>>>>
>>>>> CC: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>> CC: Inki Dae <inki.dae@samsung.com>
>>>>> Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>>> I don't know much about PCI and their IOMMU integration, but can't we
>>>> use
>>>> the direct mapping region feature of iommu core for it? There are
>>>> already
>>>> iommu_get_dm_regions(), iommu_put_dm_regions() and
>>>> iommu_request_dm_for_dev()
>>>> functions for handling them...
>>> It's rather the opposite problem - in the direct-mapping case, we're
>>> making sure the iommu_domain has translations installed for the given
>>> IOVAs (which are also the corresponding physical address) before it goes
>>> live, whereas what we need to do here is make sure the these addresses
>>> never get used as IOVAs at all, because any attempt to do so them will
>>> likely go wrong. Thus we carve them out of the iova_domain such that
>>> they will never get near an actual IOMMU API call.
>>>
>>> This is a slightly generalised equivalent of e.g. amd_iommu.c's
>>> init_reserved_iova_ranges().
>> Hmmm. Each dm_region have protection parameter. Can't we reuse them to
>> create prohibited/reserved regions by setting it to 0 (no read / no write)
>> and mapping to physical 0 address? That's just a quick idea, because
>> dm_regions and the proposed code for pci looks a bit similar for me...
> It might look similar, but at different levels (iommu_domain vs.
> iova_domain) and with the opposite intent. The dm_region prot flag is
> just the standard flag as passed to iommu_map() - trying to map a region
> with no access in an empty pagetable isn't going to achieve anything
> anyway (it's effectively unmapping addresses that are already unmapped).
>
> But for this case, even if you _did_ map something in the pagetable
> (i.e. the iommu_domain), it wouldn't make any difference, because the
> thing we're mitigating against is handing out addresses which are going
> to cause a device's accesses to blow up inside the PCI root complex
> without ever even reaching the IOMMU. In short, dm_regions are about
> "these addresses are already being used for DMA, so make sure the IOMMU
> API doesn't block them", whereas reserved ranges are about "these
> addresses are unusable for DMA, so make sure the DMA API can't allocate
> them".
Okay, thanks for the explanation.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 00/19] [RESEND] Remove STiH415 and STiH416 SoC platform support
From: Peter Griffin @ 2016-09-15 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7524458.uFhxDUCqEo@wuerfel>
Hi Arnd,
On Wed, 14 Sep 2016, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 2:27:38 PM CEST Peter Griffin wrote:
> > Resending due to incorrect Cc tags.
> >
> > ST have sent patches which remove clock support for these SoCs [1]
> > which once applied mean the platform will no longer boot.
> >
> > This series cleans up various STi platform drivers which have
> > support for these SoC's, by removing code, and updating the DT
> > documentation accordingly. Some drivers such as miphy365 and
> > stih41x-usb can be removed completely because the IP is only
> > found on these legacy SoC's.
> >
> > Once this series is applied, drm display driver, and ALSA SoC
> > are the main two remaining references to the legacy SoCs, other
> > than clocks which already have patches on the ML.
>
> It would be good to have a better explanation that "it's already
> broken by some other commit". Is this a platform that never shipped
> to end-users, or is it possible that someone out there actually
> has a machine with one of these SoCs?
STiH415 I'm sure never shipped. I'm reasonably sure STiH416 didn't
either. These SoCs were considered legacy even when I was at ST
~3 years ago.
Also remember these are STB SoC's, so JTAG fuses are blown in
production boxes, and also full security is enabled. This means the
primary bootloader will only boot a signed kernel. So if a end user
did happen to have a box they would be unable to upgrade their kernel.
>From the landing team perspective they were interesting in that they
shared many IPs with the STiH407 family on which future chipsets were
based, and were available to us when that silicon was harder to get
hold of. So we used it as a vehicle for upstreaming so that upstream
support was already quite good when STiH407 silicon did land on our
desk.
regards,
Peter.
^ permalink raw reply
* [PATCH v3 00/14] Clock improvement for video playback
From: Patrice Chotard @ 2016-09-15 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914183620.GV7243@codeaurora.org>
On 09/14/2016 08:36 PM, Stephen Boyd wrote:
> On 08/29, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> v3:
>> - Rebase to v4.8-rc1
>> - Tipo fix in st,clkgen-pll.txt
>> - Add Ack of Peter for the series
>> - Add missed patch: "ARM: DT: STiH4xx: Simplify clock binding of STiH4xx platforms"
>>
>> v2:
>> - Simpliflication of clock binding
>> remark from Rob https://lkml.org/lkml/2016/5/25/492
>> - Suppression of stih415-416 support for the clocks (in order
>> to help simplification of clock binding)
>> (others patchs for the machine and drivers will come)
>>
>> This serie allows to increase video resolutions and make audio
>> adjustment during a video playback.
>>
>> Gabriel Fernandez (14):
>> drivers: clk: st: Remove stih415-416 clock support
>> drivers: clk: st: Simplify clock binding of STiH4xx platforms
>> ARM: DT: STiH4xx: Simplify clock binding of STiH4xx platforms
>> drivers: clk: st: Add fs660c32 synthesizer algorithm
>> drivers: clk: st: Add clock propagation for audio clocks
>> drivers: clk: st: Handle clk synchronous mode for video clocks
>> ARM: DT: STiH407: Enable clock propagation for audio clocks
>> ARM: DT: STiH410: Enable clock propagation for audio clocks
>> ARM: DT: STiH418: Enable clock propagation for audio clocks
>> ARM: DT: STiH407: Enable synchronous clock mode for video clocks
>> ARM: DT: STiH410: Enable synchronous clock mode for video clocks
>> ARM: DT: STiH418: Enable synchronous clock mode for video clocks
>> ARM: DT: STi: STiH407: clock configuration to address 720p and 1080p
>> ARM: DT: STi: STiH410: clock configuration to address 720p and 1080p
>
Hi Stephen
> The order of patches intermingles clk changes and dts changes.
> I'd prefer to not take any patches for dts through the clk tree,
> so can those be deferred to an arm-soc PR?
No problem, i will take all DTS patches and submit a pull request to arm-soc.
Assuming that works,
> I'd just pick 1-2, and 4-6 into the clk tree and the rest can go
> on top through arm-soc.
>
Perfect
Thanks
^ permalink raw reply
* [PATCH 3/3] clk: sunxi-ng: sun6i-a31: Fix register offset for mipi-csi clk
From: Chen-Yu Tsai @ 2016-09-15 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915065740.13664-1-wens@csie.org>
The register offset for the mipi-csi clk is off by 4, a copy paste
error from the mipi-dsi clk.
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index ff0d621495fd..79596463e0d9 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -633,7 +633,7 @@ static SUNXI_CCU_M_WITH_MUX_GATE(mipi_dsi_dphy_clk, "mipi-dsi-dphy",
lcd_ch1_parents, 0x168, 0, 3, 8, 2,
BIT(15), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mipi_csi_dphy_clk, "mipi-csi-dphy",
- lcd_ch1_parents, 0x168, 0, 3, 8, 2,
+ lcd_ch1_parents, 0x16c, 0, 3, 8, 2,
BIT(15), 0);
static SUNXI_CCU_M_WITH_MUX_GATE(iep_drc0_clk, "iep-drc0", de_parents,
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] clk: sunxi-ng: sun6i-a31: set CLK_SET_RATE_UNGATE for all PLLs
From: Chen-Yu Tsai @ 2016-09-15 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915065740.13664-1-wens@csie.org>
The PLLs have a "lock" bit in their configuration registers which
indicate if the PLL has locked on to the requested clock rate. We
check this bit in the .set_rate op. The PLL cannot lock on if it's
not running, which might be a false positive (warning).
Set the CLK_SET_RATE_UNGATE flag for all PLLs so whenever clk_set_rate
is called on them, they get enabled and the "lock" check is really
checking the PLL.
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index bb488e8baea8..ff0d621495fd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -59,7 +59,7 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
0, 5, /* M */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
"osc24M", 0x010,
@@ -71,7 +71,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
"osc24M", 0x018,
@@ -83,7 +83,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr_clk, "pll-ddr",
"osc24M", 0x020,
@@ -92,7 +92,7 @@ static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr_clk, "pll-ddr",
0, 2, /* M */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph_clk, "pll-periph",
"osc24M", 0x028,
@@ -101,7 +101,7 @@ static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph_clk, "pll-periph",
BIT(31), /* gate */
BIT(28), /* lock */
2, /* post-div */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
"osc24M", 0x030,
@@ -113,7 +113,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
"osc24M", 0x038,
@@ -125,7 +125,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
/*
* The MIPI PLL has 2 modes: "MIPI" and "HDMI".
@@ -145,7 +145,7 @@ static SUNXI_CCU_NKM_WITH_MUX_GATE_LOCK(pll_mipi_clk, "pll-mipi",
21, 0, /* mux */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll9_clk, "pll9",
"osc24M", 0x044,
@@ -157,7 +157,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll9_clk, "pll9",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll10_clk, "pll10",
"osc24M", 0x048,
@@ -169,7 +169,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll10_clk, "pll10",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static const char * const cpux_parents[] = { "osc32k", "osc24M",
"pll-cpu", "pll-cpu" };
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] clk: sunxi-ng: sun6i-a31: Set CLK_SET_RATE_PARENT for display output clocks
From: Chen-Yu Tsai @ 2016-09-15 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915065740.13664-1-wens@csie.org>
The LCD controller and HDMI controller use the LCDx-CHy and HDMI clocks
to generate their dot clocks. To be able to generate a full range of
possible clock rates, the parent PLL clock rates should also be changed.
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index f1d61faa5bd9..bb488e8baea8 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -543,17 +543,19 @@ static const char * const lcd_ch0_parents[] = { "pll-video0", "pll-video1",
"pll-video0-2x",
"pll-video1-2x", "pll-mipi" };
static SUNXI_CCU_MUX_WITH_GATE(lcd0_ch0_clk, "lcd0-ch0", lcd_ch0_parents,
- 0x118, 24, 2, BIT(31), 0);
+ 0x118, 24, 2, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_MUX_WITH_GATE(lcd1_ch0_clk, "lcd1-ch0", lcd_ch0_parents,
- 0x11c, 24, 2, BIT(31), 0);
+ 0x11c, 24, 2, BIT(31), CLK_SET_RATE_PARENT);
static const char * const lcd_ch1_parents[] = { "pll-video0", "pll-video1",
"pll-video0-2x",
"pll-video1-2x" };
static SUNXI_CCU_M_WITH_MUX_GATE(lcd0_ch1_clk, "lcd0-ch1", lcd_ch1_parents,
- 0x12c, 0, 4, 24, 3, BIT(31), 0);
+ 0x12c, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(lcd1_ch1_clk, "lcd1-ch1", lcd_ch1_parents,
- 0x12c, 0, 4, 24, 3, BIT(31), 0);
+ 0x12c, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static const char * const csi_sclk_parents[] = { "pll-video0", "pll-video1",
"pll9", "pll10", "pll-mipi",
@@ -601,7 +603,8 @@ static SUNXI_CCU_GATE(digital_mic_clk, "digital-mic", "pll-audio",
0x148, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", lcd_ch1_parents,
- 0x150, 0, 4, 24, 2, BIT(31), 0);
+ 0x150, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(hdmi_ddc_clk, "hdmi-ddc", "osc24M", 0x150, BIT(31), 0);
@@ -624,10 +627,11 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(mbus1_clk, "mbus1", mbus_parents, 0x160,
CLK_IS_CRITICAL);
static SUNXI_CCU_M_WITH_MUX_GATE(mipi_dsi_clk, "mipi-dsi", lcd_ch1_parents,
- 0x168, 16, 3, 24, 2, BIT(31), 0);
+ 0x168, 16, 3, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mipi_dsi_dphy_clk, "mipi-dsi-dphy",
lcd_ch1_parents, 0x168, 0, 3, 8, 2,
- BIT(15), 0);
+ BIT(15), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mipi_csi_dphy_clk, "mipi-csi-dphy",
lcd_ch1_parents, 0x168, 0, 3, 8, 2,
BIT(15), 0);
@@ -956,9 +960,9 @@ static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
static CLK_FIXED_FACTOR(pll_periph_2x_clk, "pll-periph-2x",
"pll-periph", 1, 2, 0);
static CLK_FIXED_FACTOR(pll_video0_2x_clk, "pll-video0-2x",
- "pll-video0", 1, 2, 0);
+ "pll-video0", 1, 2, CLK_SET_RATE_PARENT);
static CLK_FIXED_FACTOR(pll_video1_2x_clk, "pll-video1-2x",
- "pll-video1", 1, 2, 0);
+ "pll-video1", 1, 2, CLK_SET_RATE_PARENT);
static struct clk_hw_onecell_data sun6i_a31_hw_clks = {
.hws = {
--
2.9.3
^ permalink raw reply related
* [PATCH 0/3] clk: sunxi-ng: sun6i-a31: Register offset and clk flag fixes
From: Chen-Yu Tsai @ 2016-09-15 6:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here are 3 fixes for the new sunxi-ng clk driver for sun6i-a31 recently
introduced for 4.9. The issues were noticed while working on the display
pipeline for the A31/A31s. The second patch follows what Maxime has done
for the A33 CCU driver. The third issue was noticed while doing the first
patch.
I hope we can get this into 4.9 as well, either right in -rc1, or in a
later -rc.
Thanks!
Regards
ChenYu
Chen-Yu Tsai (3):
clk: sunxi-ng: sun6i-a31: Set CLK_SET_RATE_PARENT for display output
clocks
clk: sunxi-ng: sun6i-a31: set CLK_SET_RATE_UNGATE for all PLLs
clk: sunxi-ng: sun6i-a31: Fix register offset for mipi-csi clk
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 44 ++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 20 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/3] misc: Add Aspeed BT IPMI host driver
From: Cédric Le Goater @ 2016-09-15 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7db5ada0-49ea-55eb-089e-d979941ceff5@gmail.com>
On 09/12/2016 10:33 PM, Corey Minyard wrote:
> On 09/12/2016 02:15 PM, Arnd Bergmann wrote:
>> On Monday, September 12, 2016 1:55:40 PM CEST Corey Minyard wrote:
>>> On 09/02/2016 08:22 AM, C?dric Le Goater wrote:
>>>> Hello,
>>>>
>>>> Adding Corey in cc: . I guess I should have done that in the first place.
>>> Yes, probably so. I've been travelling and didn't see it on the mailing
>>> lists until now.
>>>
>>> There is already a BT driver in the kernel, in drivers/char/ipmi, why
>>> won't that work?
>> The new driver is the host side (running on the BMC), the existing one
>> is the client (running on the PC).
>>
>> Arnd
>
> Ok, that's not really clear from the documentation or the Kconfig.
> In the IPMI spec the "host" side is the computer side, not the BMC
> side. Like:
>
> 11.6.1 BT Host Interface Registers
> The Host BT interface provides an independent set of registers and
> interrupts to allow the Host driver to
> communicate with the baseboard management controller without
> conflicting with the O/S ACPI driver.
>
> In light of that, this should probably be named the bt-bmc driver.
>
> I haven't reviewed this in detail, but I'm ok with putting it in
> drivers/char/ipmi. The state machine part looks reasonably
> generic. The configuration part isn't, but that could be split
> out later if necessary.
what do you mean by configuration ? I am ready to send a v2. May be
I can add a few other things.
Thanks,
C.
^ permalink raw reply
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Krzeminski, Marcin (Nokia - PL/Wroclaw) @ 2016-09-15 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+EcR20NkBzFjMJ_ArWw9ALZY-x1SqwS1nUyGYAnjsygTk8K-Q@mail.gmail.com>
Hello,
> -----Original Message-----
> From: linux-mtd [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf
> Of Han Xu
> Sent: Wednesday, September 14, 2016 9:49 PM
> To: Yunhui Cui <B56489@freescale.com>
> Cc: Yunhui Cui <yunhui.cui@nxp.com>; David Woodhouse
> <dwmw2@infradead.org>; linux-kernel at vger.kernel.org; linux-
> mtd at lists.infradead.org; han.xu at freescale.com; Brian Norris
> <computersforpeace@gmail.com>; jagannadh.teki at gmail.com; linux-arm-
> kernel at lists.infradead.org; Yao Yuan <yao.yuan@nxp.com>
> Subject: Re: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family
> flash
>
> On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui <B56489@freescale.com>
> wrote:
> > From: Yunhui Cui <yunhui.cui@nxp.com>
> >
> > With the physical sectors combination, S25FS-S family flash requires
> > some special operations for read/write functions.
> >
> > Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 56
> > +++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 56 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -39,6 +39,10 @@
> >
> > #define SPI_NOR_MAX_ID_LEN 6
> > #define SPI_NOR_MAX_ADDR_WIDTH 4
> > +/* Added for S25FS-S family flash */
> > +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
> > +#define CR3V_4KB_ERASE_UNABLE 0x8
> > +#define SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
> >
> > struct flash_info {
> > char *name;
> > @@ -78,6 +82,7 @@ struct flash_info {
> > };
> >
> > #define JEDEC_MFR(info) ((info)->id[0])
> > +#define EXT_JEDEC(info) ((info)->id[5])
> >
> > static const struct flash_info *spi_nor_match_id(const char *name);
> >
> > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> > */
> > { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128,
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024, 512, 0)},
> > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256,
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6 +1042,50
> @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
> > return ERR_PTR(-ENODEV);
> > }
> >
> > +/*
> > + * The S25FS-S family physical sectors may be configured as a
> > + * hybrid combination of eight 4-kB parameter sectors
> > + * at the top or bottom of the address space with all
> > + * but one of the remaining sectors being uniform size.
> > + * The Parameter Sector Erase commands (20h or 21h) must
> > + * be used to erase the 4-kB parameter sectors individually.
> > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > + * must be used to erase any of the remaining
> > + * sectors, including the portion of highest or lowest address
> > + * sector that is not overlaid by the parameter sectors.
> > + * The uniform sector erase command has no effect on parameter
> sectors.
> > + */
> > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> > + u8 cr3v = 0x0;
> > + int ret = 0x0;
> > +
> > + nor->cmd_buf[2] = cr3v_addr >> 16;
> > + nor->cmd_buf[1] = cr3v_addr >> 8;
> > + nor->cmd_buf[0] = cr3v_addr >> 0;
> > +
> > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > + if (ret)
> > + return ret;
> > + if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > + return 0;
> > + ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > + if (ret)
> > + return ret;
> > + cr3v = CR3V_4KB_ERASE_UNABLE;
> > + nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > + nor->write(nor, cr3v_addr, 1, &cr3v);
> > +
> > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > + if (ret)
> > + return ret;
> > + if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > + return -EPERM;
> > +
> > + return 0;
> > +}
> > +
> > static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
> > size_t *retlen, u_char *buf) { @@ -1361,6
> > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> enum read_mode mode)
> > spi_nor_wait_till_ready(nor);
> > }
> >
> > + if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
> > + ret = spansion_s25fs_disable_4kb_erase(nor);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > if (!mtd->name)
> > mtd->name = dev_name(dev);
> > mtd->priv = nor;
> > --
> > 2.1.0.27.g96db324
> >
> >
> Hi Brian, I will ack this change but still feel it's kind of hacking code.
>
> Acked-by: Han xu <han.xu@nxp.com>
I am new on the list so I am not sure if this topic has been discussed.
Generally our product functionality relay on those 4KiB sectors.
I know that this hack is already in u-boot, but if you mainstream this
you will force users of those 4KiB sectors to do hack the hack...
I believe the proper solution here is to use erase regions functionality,
I send and RFS about that some time ago.
Thanks,
Marcin
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
>
> --
> Sincerely,
>
> Han XU
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH] cpufreq: ti: Use generic platdev driver
From: Viresh Kumar @ 2016-09-15 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914204137.20346-1-d-gerlach@ti.com>
On 14-09-16, 15:41, Dave Gerlach wrote:
> Now that the cpufreq-dt-platdev is used to create the cpufreq-dt platform
> device for all OMAP platforms and the platform code that did it
> before has been removed, add ti,am33xx and ti,dra7xx to the machine list
> in cpufreq-dt-platdev which had relied on the removed platform code to do
> this previously.
>
> Fixes: 7694ca6e1d6f ("cpufreq: omap: Use generic platdev driver")
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Any stable trees you want this to be added to ?
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 0bb44d5b5df4..d5e8ba50f8a3 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -68,6 +68,8 @@ static const struct of_device_id machines[] __initconst = {
>
> { .compatible = "sigma,tango4" },
>
> + { .compatible = "ti,am33xx", },
> + { .compatible = "ti,dra7", },
> { .compatible = "ti,omap2", },
> { .compatible = "ti,omap3", },
> { .compatible = "ti,omap4", },
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH 2/2 v5] dmaengine: mv_xor: Add support for IO (PCIe) src/dst areas
From: Stefan Roese @ 2016-09-15 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915053731.25263-1-sr@denx.de>
To enable the access to a specific area, the MVEBU XOR controllers needs
to have this area enabled / mapped via an address window. Right now,
only the DRAM memory area is enabled via such memory windows. So
using this driver to DMA to / from a e.g. PCIe memory region is
currently not supported.
This patch now adds support for such PCIe / IO regions by checking
if the src / dst address is located in an IO memory area in contrast
to being located in DRAM. This is done by using the newly introduced
MBus function mvebu_mbus_get_io_win_info(). If the src / dst address
is located in such an IO area, a new address window is created in
the XOR DMA controller. Enabling the controller to access this area.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vinod Koul <vinod.koul@intel.com>
---
v4 -> v5:
- Added Andrew to Cc
v3 -> v4:
- Don't try to add the IO windows on Armada 3700 which does not implement
the MBus driver
v2 -> v3:
- Included separate patch to add a stub function for mvebu_mbus_get_io_win_info()
to this patch series
- COMPILE_TEST added again, as the stub function now allows compilation on
all platforms
v1 -> v2:
- Removed COMPILE_TEST from Kconfig entry as this results in compilation
errors on non-Marvell platforms because of references to MBus driver
functions. Since this driver will never be used on non-Marvell platforms
this should be okay.
RFC -> v1:
- Use a cache for the already mapped areas for performance reasons, as
the MMIO registers don't need to get queried any more if the area is
already mapped now
drivers/dma/mv_xor.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++-
drivers/dma/mv_xor.h | 7 ++++
2 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index f4c9f98..ff4a094 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -470,12 +470,90 @@ static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
return mv_chan->slots_allocated ? : -ENOMEM;
}
+/*
+ * Check if source or destination is an PCIe/IO address (non-SDRAM) and add
+ * a new MBus window if necessary. Use a cache for these check so that
+ * the MMIO mapped registers don't have to be accessed for this check
+ * to speed up this process.
+ */
+static int mv_xor_add_io_win(struct mv_xor_chan *mv_chan, u32 addr)
+{
+ struct mv_xor_device *xordev = mv_chan->xordev;
+ void __iomem *base = mv_chan->mmr_high_base;
+ u32 win_enable;
+ u32 size;
+ u8 target, attr;
+ int ret;
+ int i;
+
+ /* Nothing needs to get done for the Armada 3700 */
+ if (xordev->xor_type == XOR_ARMADA_37XX)
+ return 0;
+
+ /*
+ * Loop over the cached windows to check, if the requested area
+ * is already mapped. If this the case, nothing needs to be done
+ * and we can return.
+ */
+ for (i = 0; i < WINDOW_COUNT; i++) {
+ if (addr >= xordev->win_start[i] &&
+ addr <= xordev->win_end[i]) {
+ /* Window is already mapped */
+ return 0;
+ }
+ }
+
+ /*
+ * The window is not mapped, so we need to create the new mapping
+ */
+
+ /* If no IO window is found that addr has to be located in SDRAM */
+ ret = mvebu_mbus_get_io_win_info(addr, &size, &target, &attr);
+ if (ret < 0)
+ return 0;
+
+ /*
+ * Mask the base addr 'addr' according to 'size' read back from the
+ * MBus window. Otherwise we might end up with an address located
+ * somewhere in the middle of this area here.
+ */
+ size -= 1;
+ addr &= ~size;
+
+ /*
+ * Reading one of both enabled register is enough, as they are always
+ * programmed to the identical values
+ */
+ win_enable = readl(base + WINDOW_BAR_ENABLE(0));
+
+ /* Set 'i' to the first free window to write the new values to */
+ i = ffs(~win_enable) - 1;
+ if (i >= WINDOW_COUNT)
+ return -ENOMEM;
+
+ writel((addr & 0xffff0000) | (attr << 8) | target,
+ base + WINDOW_BASE(i));
+ writel(size & 0xffff0000, base + WINDOW_SIZE(i));
+
+ /* Fill the caching variables for later use */
+ xordev->win_start[i] = addr;
+ xordev->win_end[i] = addr + size;
+
+ win_enable |= (1 << i);
+ win_enable |= 3 << (16 + (2 * i));
+ writel(win_enable, base + WINDOW_BAR_ENABLE(0));
+ writel(win_enable, base + WINDOW_BAR_ENABLE(1));
+
+ return 0;
+}
+
static struct dma_async_tx_descriptor *
mv_xor_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
unsigned int src_cnt, size_t len, unsigned long flags)
{
struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
struct mv_xor_desc_slot *sw_desc;
+ int ret;
if (unlikely(len < MV_XOR_MIN_BYTE_COUNT))
return NULL;
@@ -486,6 +564,11 @@ mv_xor_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
"%s src_cnt: %d len: %zu dest %pad flags: %ld\n",
__func__, src_cnt, len, &dest, flags);
+ /* Check if a new window needs to get added for 'dest' */
+ ret = mv_xor_add_io_win(mv_chan, dest);
+ if (ret)
+ return NULL;
+
sw_desc = mv_chan_alloc_slot(mv_chan);
if (sw_desc) {
sw_desc->type = DMA_XOR;
@@ -493,8 +576,13 @@ mv_xor_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
mv_desc_init(sw_desc, dest, len, flags);
if (mv_chan->op_in_desc == XOR_MODE_IN_DESC)
mv_desc_set_mode(sw_desc);
- while (src_cnt--)
+ while (src_cnt--) {
+ /* Check if a new window needs to get added for 'src' */
+ ret = mv_xor_add_io_win(mv_chan, src[src_cnt]);
+ if (ret)
+ return NULL;
mv_desc_set_src_addr(sw_desc, src_cnt, src[src_cnt]);
+ }
}
dev_dbg(mv_chan_to_devp(mv_chan),
@@ -959,6 +1047,7 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
mv_chan->op_in_desc = XOR_MODE_IN_DESC;
dma_dev = &mv_chan->dmadev;
+ mv_chan->xordev = xordev;
/*
* These source and destination dummy buffers are used to implement
@@ -1086,6 +1175,10 @@ mv_xor_conf_mbus_windows(struct mv_xor_device *xordev,
dram->mbus_dram_target_id, base + WINDOW_BASE(i));
writel((cs->size - 1) & 0xffff0000, base + WINDOW_SIZE(i));
+ /* Fill the caching variables for later use */
+ xordev->win_start[i] = cs->base;
+ xordev->win_end[i] = cs->base + cs->size - 1;
+
win_enable |= (1 << i);
win_enable |= 3 << (16 + (2 * i));
}
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index bf56e08..88eeab2 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -80,12 +80,17 @@
#define WINDOW_BAR_ENABLE(chan) (0x40 + ((chan) << 2))
#define WINDOW_OVERRIDE_CTRL(chan) (0xA0 + ((chan) << 2))
+#define WINDOW_COUNT 8
+
struct mv_xor_device {
void __iomem *xor_base;
void __iomem *xor_high_base;
struct clk *clk;
struct mv_xor_chan *channels[MV_XOR_MAX_CHANNELS];
int xor_type;
+
+ u32 win_start[WINDOW_COUNT];
+ u32 win_end[WINDOW_COUNT];
};
/**
@@ -127,6 +132,8 @@ struct mv_xor_chan {
char dummy_dst[MV_XOR_MIN_BYTE_COUNT];
dma_addr_t dummy_src_addr, dummy_dst_addr;
u32 saved_config_reg, saved_int_mask_reg;
+
+ struct mv_xor_device *xordev;
};
/**
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2 v3] bus: mvebu-mbus: Provide stub function for mvebu_mbus_get_io_win_info()
From: Stefan Roese @ 2016-09-15 5:37 UTC (permalink / raw)
To: linux-arm-kernel
This patch provides a stub function for mvebu_mbus_get_io_win_info(),
which will be used for all non-Orion (ARM32 MVEBU) platforms for
compile test coverage.
On such platforms this function will return an error so that drivers
might detect a potential problem.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vinod Koul <vinod.koul@intel.com>
---
v3:
- Include errno.h to fix the compile breakage on ARM64
- Change comment as suggested by Andrew
- Added Andrew to Cc
v2:
- Return error code in stub function. This may be useful on Armada 3700
boards. As Armada 3700 does not implement the MBus driver but some
device driver might call into these functions anyways (e.g. mvneta).
include/linux/mbus.h | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index d610232..2931aa4 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -11,6 +11,8 @@
#ifndef __LINUX_MBUS_H
#define __LINUX_MBUS_H
+#include <linux/errno.h>
+
struct resource;
struct mbus_dram_target_info
@@ -55,6 +57,8 @@ struct mbus_dram_target_info
#ifdef CONFIG_PLAT_ORION
extern const struct mbus_dram_target_info *mv_mbus_dram_info(void);
extern const struct mbus_dram_target_info *mv_mbus_dram_info_nooverlap(void);
+int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
+ u8 *attr);
#else
static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
{
@@ -64,14 +68,24 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info_nooverlap(vo
{
return NULL;
}
+static inline int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size,
+ u8 *target, u8 *attr)
+{
+ /*
+ * On all ARM32 MVEBU platforms with MBus support, this stub
+ * function will not get called. The real function from the
+ * MBus driver is called instead. ARM64 MVEBU platforms like
+ * the Armada 3700 could use the mv_xor device driver which calls
+ * into this function
+ */
+ return -EINVAL;
+}
#endif
int mvebu_mbus_save_cpu_target(u32 __iomem *store_addr);
void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr);
-int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
- u8 *attr);
int mvebu_mbus_add_window_remap_by_id(unsigned int target,
unsigned int attribute,
phys_addr_t base, size_t size,
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2 v3] bus: mvebu-mbus: Provide stub function for mvebu_mbus_get_io_win_info()
From: Stefan Roese @ 2016-09-15 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914134559.GM13920@localhost>
Hi Vinod,
On 14.09.2016 15:45, Vinod Koul wrote:
> On Wed, Sep 14, 2016 at 03:06:07PM +0200, Gregory CLEMENT wrote:
>> Hi,
>>
>> On lun., sept. 05 2016, Stefan Roese <sr@denx.de> wrote:
>>
>>> This patch provides a stub function for mvebu_mbus_get_io_win_info(),
>>> which will be used for all non-Orion (ARM32 MVEBU) platforms for
>>> compile test coverage.
>>>
>>> On such platforms this function will return an error so that drivers
>>> might detect a potential problem.
>>
>> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>
>> Vinod, if you happy with the second patch of the series you can apply
>> both patches on your tree. It will allow to keep the bisactibility, and
>> as I didn't have any commit modifying these file in my trees it won't
>> generate merge conflict.
>
> Okay, somehow I dont see this in my queue. Can you guys pls resend.
Sure. I'll resend it in a minute...
Thanks,
Stefan
^ permalink raw reply
* [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
From: Peter Chen @ 2016-09-15 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147387497029.16543.5921198225528254345@sboyd-linaro>
On Wed, Sep 14, 2016 at 10:42:50AM -0700, Stephen Boyd wrote:
> > >
> > > Hmm.. maybe the confusion is in which registers we should be able to
> > > access? Are we talking about the ULPI viewport MMIO register space or
> > > the ULPI registers that we access through the viewport? I have a
> > > hw_phymode_configure() inside of of ci_ulpi_init() so that the
> > > identification registers through the ULPI viewport read properly
> > > (assuming there aren't other power requirements like regulators). If we
> > > don't set the portsc.pts before using the viewport, the viewport doesn't
> > > work and reads timeout. So we really don't touch the ULPI registers
> > > except for the scratch space and the id registers until after the phy is
> > > properly powered on with clks and regulators, because the only place we
> > > touch them after doing the id checking is in this phy driver in
> > > qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> > > we don't know which device driver to probe because the phy needs to be
> > > powered on to read the id registers to know which device driver to use
> > > by using DT to match up device drivers instead.
> > >
> > > [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf
> >
> > Ok, ulpi phy works like USB device on USB bus which create device at
> > runtime. So, like some hard-wired USB devices, it may needs power
> > sequence too, otherwise, how it knows which driver can loads.
> >
>
> Yes. We use the DT compatible string to ignore any issues with reading
> the device ids when the device is powered off. Unlike USB though, we
> have device drivers for the ULPI PHYs that do the power sequencing along
> with other initializations, so using a common pwrseq layer seems like
> overkill just so we can read the id registers.
If the attempt to read id registers will not hang the system, it can
work. Like the case [1], without PHY ref_clk, it will hang when
configure PHY mode (visit portsc.pts), it has no chance to read id
registers. So, I still think the ULPI bus driver needs to do power
sequence for its children, unless you have some place to open the
ref_clk.
>
> Are there any concerns with this patch? Or can they be reapplied?
For this patch, it is ok for me.
[1] http://www.spinics.net/lists/linux-usb/msg146336.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH 1/6] PCI: xilinx: Keep both legacy and MSI interrupt references.
From: Bharat Kumar Gogada @ 2016-09-15 5:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914191704.GA9208@localhost>
On Wed, Sep 14, 2016 at 03:32:44PM +0000, Bharat Kumar Gogada wrote:
> On Thu, Sep 01, 2016 at 03:44:41PM +0530, Bharat Kumar Gogada wrote:
> > When built with MSI support the legacy domain reference is being
> > overwritten with MSI.
> > Instead creating two separate domains for MSI and legacy interrupts.
> >
> > Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
>
> Applied all these (except [5/6]) with Michal's ack to pci/host-xilinx for v4.9, thanks!
>
> I already applied Po Liu's patch ("PCI: xilinx: Relax device number checking to allow SR-IOV") to pci/virtualization. This is identical to [5/6], so I dropped [5/6] to avoid a conflict.
>
> Thanks Bjorn.
> Some how I couldn't find Po Liu's patch, can you provide git link of patch that was applied.
Sure, here it is: https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8e7ca8ca5fd8a3242289105723c429733be8b73b
Thanks Bjorn, this patch is similar to [5/6] patch.
^ permalink raw reply
* [PATCH v4] arm64: Improve kprobes test for atomic sequence
From: Masami Hiramatsu @ 2016-09-15 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D7515C.30704@linaro.org>
On Mon, 12 Sep 2016 21:07:40 -0400
David Long <dave.long@linaro.org> wrote:
>
> After the patch the function reads as follows:
>
> > enum kprobe_insn __kprobes
> > arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi)
> > {
> > enum kprobe_insn decoded;
> > kprobe_opcode_t insn = le32_to_cpu(*addr);
> > kprobe_opcode_t *scan_end = NULL;
> > unsigned long size = 0, offset = 0;
> >
> > /*
> > * If there's a symbol defined in front of and near enough to
> > * the probe address assume it is the entry point to this
> > * code and use it to further limit how far back we search
> > * when determining if we're in an atomic sequence. If we could
> > * not find any symbol skip the atomic test altogether as we
> > * could otherwise end up searching irrelevant text/literals.
> > * KPROBES depends on KALLSYMS so this last case should never
> > * happen.
> > */
> > if (kallsyms_lookup_size_offset((unsigned long) addr, &size, &offset)) {
> > if (offset < (MAX_ATOMIC_CONTEXT_SIZE*sizeof(kprobe_opcode_t)))
> > scan_end = addr - (offset / sizeof(kprobe_opcode_t));
> > else
> > scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
> > }
> > decoded = arm_probe_decode_insn(insn, asi);
> >
> > if (decoded != INSN_REJECTED && scan_end)
> > if (is_probed_address_atomic(addr - 1, scan_end))
> > return INSN_REJECTED;
> >
> > return decoded;
> > }
>
> A failed kallsyms_lookup_size_offset() call means scan_end will be left
> as NULL, which in turn means arm_kprobe_decode_insn() will simply return
> the result of the arm_probe_decode_insn() call. In other words it does
> the normal analysis of the instruction to be probed, but does not do the
> atomic sequence search that normally follows that (since it doesn't
> really know how far back to search).
OK, my idea was just rejecting it when kallsyms_lookup_size_offset() is
failed, because we can not ensure that the address is in the kernel
text. But anyway, that should be tested in general code like kernel/kprobes.c.
OK, now I think it is clear to apply.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
>
> Thanks,
> -dl
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH -next] drm/sun4i: backend: remove redundant dev_err call in sun4i_backend_bind()
From: Wei Yongjun @ 2016-09-15 3:25 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 91a7022..fcd4e91 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -288,10 +288,8 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
- if (IS_ERR(regs)) {
- dev_err(dev, "Couldn't map the backend registers\n");
+ if (IS_ERR(regs))
return PTR_ERR(regs);
- }
backend->regs = devm_regmap_init_mmio(dev, regs,
&sun4i_backend_regmap_config);
^ permalink raw reply related
* [PATCH] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board
From: Icenowy Zheng @ 2016-09-15 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915021504.65483-1-icenowy@aosc.xyz>
15.09.2016, 10:15, "Icenowy Zheng" <icenowy@aosc.xyz>:
> UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
> on iNet D978 Rev2 board.
>
> Enable the UART1 to make it possible to use the modified hciattach by
> Realtek to drive the BT part of RTL8723BS.
>
> On the board no r_uart pins are found now (the onboard RX/TX pins are
> wired to PF2/PF4, which is muxed with mmc0), so also disabled it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Oh I forgot to add a patch version number...
It's PATCH v3.
(But it seems that I should send a v4 to split the dtsi change and dts change.)
> ---
> ?arch/arm/boot/dts/sun8i-a23-a33.dtsi | 14 ++++++++++++++
> ?arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 20 ++++++++++++++++++++
> ?2 files changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> index 7e05e09..c340885 100644
> --- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> @@ -361,6 +361,20 @@
> ?????????????????????????????????allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> ?????????????????????????};
>
> + uart1_pins_a: uart1 at 0 {
> + allwinner,pins = "PG6", "PG7";
> + allwinner,function = "uart1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + uart1_pins_cts_rts_a: uart1-cts-rts at 0 {
> + allwinner,pins = "PG8", "PG9";
> + allwinner,function = "uart1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> ?????????????????????????mmc0_pins_a: mmc0 at 0 {
> ?????????????????????????????????allwinner,pins = "PF0", "PF1", "PF2",
> ??????????????????????????????????????????????????"PF3", "PF4", "PF5";
> diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> index 0f52cd9..fb46655 100644
> --- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> +++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> @@ -49,6 +49,15 @@
> ?????????model = "INet-D978 Rev 02";
> ?????????compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
>
> + aliases {
> + serial0 = &uart1;
> + };
> +
> + chosen {
> + /* Delete debug UART as serial0 is the UART for bluetooth */
> + /delete-property/stdout-path;
> + };
> +
> ?????????leds {
> ?????????????????compatible = "gpio-leds";
> ?????????????????pinctrl-names = "default";
> @@ -86,3 +95,14 @@
> ?????????????????allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> ?????????};
> ?};
> +
> +&r_uart {
> + status = "disabled";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins_a>,
> + <&uart1_pins_cts_rts_a>;
> + status = "okay";
> +};
> --
> 2.9.3
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board
From: Icenowy Zheng @ 2016-09-15 2:15 UTC (permalink / raw)
To: linux-arm-kernel
UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
on iNet D978 Rev2 board.
Enable the UART1 to make it possible to use the modified hciattach by
Realtek to drive the BT part of RTL8723BS.
On the board no r_uart pins are found now (the onboard RX/TX pins are
wired to PF2/PF4, which is muxed with mmc0), so also disabled it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 14 ++++++++++++++
arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 20 ++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 7e05e09..c340885 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -361,6 +361,20 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+ uart1_pins_a: uart1 at 0 {
+ allwinner,pins = "PG6", "PG7";
+ allwinner,function = "uart1";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ uart1_pins_cts_rts_a: uart1-cts-rts at 0 {
+ allwinner,pins = "PG8", "PG9";
+ allwinner,function = "uart1";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
mmc0_pins_a: mmc0 at 0 {
allwinner,pins = "PF0", "PF1", "PF2",
"PF3", "PF4", "PF5";
diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
index 0f52cd9..fb46655 100644
--- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
+++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
@@ -49,6 +49,15 @@
model = "INet-D978 Rev 02";
compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
+ aliases {
+ serial0 = &uart1;
+ };
+
+ chosen {
+ /* Delete debug UART as serial0 is the UART for bluetooth */
+ /delete-property/stdout-path;
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -86,3 +95,14 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
};
+
+&r_uart {
+ status = "disabled";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins_a>,
+ <&uart1_pins_cts_rts_a>;
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [GIT PULL] arm64: X-Gene platforms DTS changes queued for 4.9 - part1
From: Duc Dang @ 2016-09-15 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6041122.z65jfDXEcc@wuerfel>
On Wed, Sep 14, 2016 at 7:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday, September 2, 2016 11:46:31 AM CEST Duc Dang wrote:
>> Hi Arnd, Olof,
>>
>> This is the first part of DTS changes for X-Gene platforms targeted for 4.9.
>>
>> The changes include:
>> + X-Gene Soc PMU support patch set from Tai Nguyen (v10 reviewed by
>> Mark, DT binding document acked by Rob [1] and was suggested to merge
>> via am-soc tree by Will [2])
>> + Follow up patch to enable DT entry for SoC PMU on X-Gene v2
>> + Correct PCIe legacy interrupt mode to level-active high
>> + DTS entry for X-Gene hwmon (v4 acked by Guenter, DT binding document
>> and driver is in linux-next now [3])
>>
>> Regards,
>> Duc Dang.
>
> Sorry for the long delay, I've just now started looking at the dts changes
> for arm64. The changes to arch/arm64/boot/dts look fine, but I don't
> want to mix driver changes with dts changes, as we use separate
> branches for those.
>
> Please send this again as two pull requests, one for the dts changes, and
> one for the rest (pmu driver, binding and MAINTAINERS file). Please
> also include an explanation in the tag description about why this gets
> merged through arm-soc. I see that Will suggested doing it that way,
> but I don't see what the reason is. We normally don't touch that directory.
Hi Arnd,
I am not clear about the reason either. Probably we don't have a
dedicated tree for SoC PMU?
Hi Will,
Can you please comment?
Regards,
Duc Dang.
>
> Arnd
>
>>
>> [1]: https://lkml.org/lkml/2016/7/15/563
>> [2]: https://lkml.org/lkml/2016/7/20/224
>> [3]: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=893485e74c37669aeecf0b648dbfbd8e2f0471c3
>> ------
>>
>> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>>
>> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>>
>> are available in the git repository at:
>>
>> https://github.com/AppliedMicro/xgene-next.git tags/xgene-dts-for-v4.9-part1
>>
>> for you to fetch changes up to 1c983fc9369420748192712bde2429af3e580390:
>>
>> arm64: dts: apm: Add X-Gene SoC hwmon to device tree (2016-09-02
>> 10:43:41 -0700)
>>
>> ----------------------------------------------------------------
>> X-Gene DTS changes queued for v4.9 - part 1
>>
>> This patch set includes:
>> + X-Gene v1 SoC Performance Monitoring Unit (PMU) support
>> + DTS entry to enable SoC PMU for X-Gene v2 SoC
>> + PCIe legacy interrupt polarity fix for X-Gene
>> + X-Gene SoC hwmon DTS entry
>>
>
>
^ permalink raw reply
* [clk:clk-next 19/25] drivers/clk/zte/clk-zx296718.c:554:35: warning: cast from pointer to integer of different size
From: kbuild test robot @ 2016-09-15 0:48 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
head: f5644f10dcfbab90ffd27da1d8d51ffc13e1bc84
commit: ca0233285a93222b2b0c7384b9345711b3d68b5c [19/25] clk: zx: register ZX296718 clocks
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ca0233285a93222b2b0c7384b9345711b3d68b5c
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
drivers/clk/zte/clk-zx296718.c: In function 'top_clocks_init':
>> drivers/clk/zte/clk-zx296718.c:554:35: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
zx296718_pll_clk[i].reg_base += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:579:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
top_mux_clk[i].mux.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:592:31: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
top_gate_clk[i].gate.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:605:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
top_div_clk[i].div.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c: In function 'lsp0_clocks_init':
drivers/clk/zte/clk-zx296718.c:745:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp0_mux_clk[i].mux.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:758:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp0_gate_clk[i].gate.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:771:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp0_div_clk[i].div.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c: In function 'lsp1_clocks_init':
drivers/clk/zte/clk-zx296718.c:850:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp1_mux_clk[i].mux.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:863:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp1_gate_clk[i].gate.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:876:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp1_div_clk[i].div.reg += (u64)reg_base;
^
vim +554 drivers/clk/zte/clk-zx296718.c
538 [TOP_NR_CLKS - 1] = NULL,
539 },
540 };
541
542 static int __init top_clocks_init(struct device_node *np)
543 {
544 void __iomem *reg_base;
545 int i, ret;
546
547 reg_base = of_iomap(np, 0);
548 if (!reg_base) {
549 pr_err("%s: Unable to map clk base\n", __func__);
550 return -ENXIO;
551 }
552
553 for (i = 0; i < ARRAY_SIZE(zx296718_pll_clk); i++) {
> 554 zx296718_pll_clk[i].reg_base += (u64)reg_base;
555 ret = clk_hw_register(NULL, &zx296718_pll_clk[i].hw);
556 if (ret) {
557 pr_warn("top clk %s init error!\n",
558 zx296718_pll_clk[i].hw.init->name);
559 }
560 }
561
562 for (i = 0; i < ARRAY_SIZE(top_ffactor_clk); i++) {
---
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/octet-stream
Size: 58522 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160915/1d2cc8ea/attachment-0001.obj>
^ permalink raw reply
* [PATCH v2 0/5] AT91: sckc improvements
From: Stephen Boyd @ 2016-09-15 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908145146.20422-1-alexandre.belloni@free-electrons.com>
On 09/08, Alexandre Belloni wrote:
> Hi,
>
> This patch set improves the slow clock controller driver.
>
> The first patch simply moves some code around to avoid having extern
> functions declared.
>
> The second patch adds support for the SCKC found on sama5d4 and later.
> It is notably missing the OSC32EN bit.
> The third and fourth patches make use of this new driver (DT ABI is not
> broken \o/)
>
> Finally, there is an optimization. Trying to find wether the slow
> oscillator is already stable to avoid waiting 1.2s twice in the boot
> process.
clk patches look ok. We'll need to move this to use clk_hw
registration based APIs some time, but that isn't critical to
handle now. Will you resend?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 02/34] clk: at91: Migrate to clk_hw based registration and OF APIs
From: Stephen Boyd @ 2016-09-15 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160607184059.6c83477f@bbrezillon>
On 06/07, Boris Brezillon wrote:
> On Tue, 7 Jun 2016 18:36:21 +0200
> Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote:
>
> > On 01/06/2016 at 16:15:01 -0700, Stephen Boyd wrote :
> > > Now that we have clk_hw based provider APIs to register clks, we
> > > can get rid of struct clk pointers in this driver, allowing us to
> > > move closer to a clear split of consumer and provider clk APIs.
> > >
> > > Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> >
> > Well, apart the same comment about alignement:
> >
> > Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > Tested-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>
> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>
Ok I fixed the alignment and pushed to clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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