* [PATCH v2 2/2] net: axienet: Fix compilation warnings
From: David Miller @ 2014-02-13 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9be652e995e74663de1df69e6ea101225cb670a2.1392275432.git.michal.simek@xilinx.com>
From: Michal Simek <michal.simek@xilinx.com>
Date: Thu, 13 Feb 2014 08:10:43 +0100
> Warning log:
> xilinx_axienet_main.c: In function 'axienet_start_xmit_done':
> xilinx_axienet_main.c:617:16: warning: operation on 'lp->tx_bd_ci' may be undefined [-Wsequence-point]
> xilinx_axienet_main.c: In function 'axienet_start_xmit':
> xilinx_axienet_main.c:703:18: warning: operation on 'lp->tx_bd_tail' may be undefined [-Wsequence-point]
> xilinx_axienet_main.c:719:17: warning: operation on 'lp->tx_bd_tail' may be undefined [-Wsequence-point]
> xilinx_axienet_main.c: In function 'axienet_recv':
> xilinx_axienet_main.c:792:16: warning: operation on 'lp->rx_bd_ci' may be undefined [-Wsequence-point]
> xilinx_axienet_main.c: In function 'axienet_of_probe':
> xilinx_axienet_main.c:1501:21: warning: unused variable 'rc' [-Wunused-variable]
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Applied.
^ permalink raw reply
* [PATCH 1/9] ARM: dts: omap3-gta04: Fix 'aux' gpio key flags.
From: Tony Lindgren @ 2014-02-13 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390685343-11663-2-git-send-email-marek@goldelico.com>
* Marek Belisko <marek@goldelico.com> [140125 13:31]:
> From: NeilBrown <neilb@suse.de>
>
> It should be ACTIVE_HIGH.
>
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
> arch/arm/boot/dts/omap3-gta04.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
> index b9b55c9..9d37184 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dts
> +++ b/arch/arm/boot/dts/omap3-gta04.dts
> @@ -32,7 +32,7 @@
> aux-button {
> label = "aux";
> linux,code = <169>;
> - gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
> + gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> gpio-key,wakeup;
> };
> };
Picking this one into omap-for-v3.14/fixes thanks.
Tony
^ permalink raw reply
* [PATCH 3/9] ARM: dts: omap3-gta04: Fix mmc1 properties.
From: Tony Lindgren @ 2014-02-13 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390685343-11663-4-git-send-email-marek@goldelico.com>
* Marek Belisko <marek@goldelico.com> [140125 13:31]:
> Does not have an aux supply, and must be non-removable.
>
> Otherwise it is removed during suspend and filesystem gets confused.
>
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
> arch/arm/boot/dts/omap3-gta04.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
> index e315675..6011151 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dts
> +++ b/arch/arm/boot/dts/omap3-gta04.dts
> @@ -149,8 +149,8 @@
> pinctrl-names = "default";
> pinctrl-0 = <&mmc1_pins>;
> vmmc-supply = <&vmmc1>;
> - vmmc_aux-supply = <&vsim>;
> bus-width = <4>;
> + ti,non-removable;
> };
>
> &mmc2 {
Taking this too into omap-for-v3.14/fixes.
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
From: Tony Lindgren @ 2014-02-13 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391080640-23370-1-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140130 03:19]:
> If CLK_SET_RATE_PARENT is set for a clkoutx2 clock, calling
> clk_set_rate() on the clock "skips" the x2 multiplier as there are no
> set_rate and round_rate functions defined for the clkoutx2.
>
> This results in getting double the requested clock rates, breaking the
> display on omap3430 based devices. This got broken when
> d0f58bd3bba3877fb1af4664c4e33273d36f00e4 and related patches were merged
> for v3.14, as omapdss driver now relies more on the clk-framework and
> CLK_SET_RATE_PARENT.
>
> This patch implements set_rate and round_rate for clkoutx2.
>
> Tested on OMAP3430, OMAP3630, OMAP4460.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Would like to see acks from Paul and Tero on this too before applying.
Tony
> ---
> arch/arm/mach-omap2/cclock3xxx_data.c | 2 +
> arch/arm/mach-omap2/dpll3xxx.c | 92 +++++++++++++++++++++++++++++------
> include/linux/clk/ti.h | 4 ++
> 3 files changed, 83 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
> index 3b05aea56d1f..11ed9152e665 100644
> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -433,7 +433,9 @@ static const struct clk_ops dpll4_m5x2_ck_ops = {
> .enable = &omap2_dflt_clk_enable,
> .disable = &omap2_dflt_clk_disable,
> .is_enabled = &omap2_dflt_clk_is_enabled,
> + .set_rate = &omap3_clkoutx2_set_rate,
> .recalc_rate = &omap3_clkoutx2_recalc,
> + .round_rate = &omap3_clkoutx2_round_rate,
> };
>
> static const struct clk_ops dpll4_m5x2_ck_3630_ops = {
> diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
> index 3185ced807c9..3c418ea54bbe 100644
> --- a/arch/arm/mach-omap2/dpll3xxx.c
> +++ b/arch/arm/mach-omap2/dpll3xxx.c
> @@ -623,6 +623,32 @@ void omap3_dpll_deny_idle(struct clk_hw_omap *clk)
>
> /* Clock control for DPLL outputs */
>
> +/* Find the parent DPLL for the given clkoutx2 clock */
> +static struct clk_hw_omap *omap3_find_clkoutx2_dpll(struct clk_hw *hw)
> +{
> + struct clk_hw_omap *pclk = NULL;
> + struct clk *parent;
> +
> + /* Walk up the parents of clk, looking for a DPLL */
> + do {
> + do {
> + parent = __clk_get_parent(hw->clk);
> + hw = __clk_get_hw(parent);
> + } while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
> + if (!hw)
> + break;
> + pclk = to_clk_hw_omap(hw);
> + } while (pclk && !pclk->dpll_data);
> +
> + /* clk does not have a DPLL as a parent? error in the clock data */
> + if (!pclk) {
> + WARN_ON(1);
> + return NULL;
> + }
> +
> + return pclk;
> +}
> +
> /**
> * omap3_clkoutx2_recalc - recalculate DPLL X2 output virtual clock rate
> * @clk: DPLL output struct clk
> @@ -637,27 +663,14 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
> unsigned long rate;
> u32 v;
> struct clk_hw_omap *pclk = NULL;
> - struct clk *parent;
>
> if (!parent_rate)
> return 0;
>
> - /* Walk up the parents of clk, looking for a DPLL */
> - do {
> - do {
> - parent = __clk_get_parent(hw->clk);
> - hw = __clk_get_hw(parent);
> - } while (hw && (__clk_get_flags(hw->clk) & CLK_IS_BASIC));
> - if (!hw)
> - break;
> - pclk = to_clk_hw_omap(hw);
> - } while (pclk && !pclk->dpll_data);
> + pclk = omap3_find_clkoutx2_dpll(hw);
>
> - /* clk does not have a DPLL as a parent? error in the clock data */
> - if (!pclk) {
> - WARN_ON(1);
> + if (!pclk)
> return 0;
> - }
>
> dd = pclk->dpll_data;
>
> @@ -672,6 +685,55 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
> return rate;
> }
>
> +int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + return 0;
> +}
> +
> +long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate)
> +{
> + const struct dpll_data *dd;
> + u32 v;
> + struct clk_hw_omap *pclk = NULL;
> +
> + if (!*prate)
> + return 0;
> +
> + pclk = omap3_find_clkoutx2_dpll(hw);
> +
> + if (!pclk)
> + return 0;
> +
> + dd = pclk->dpll_data;
> +
> + /* TYPE J does not have a clkoutx2 */
> + if (dd->flags & DPLL_J_TYPE) {
> + *prate = __clk_round_rate(__clk_get_parent(pclk->hw.clk), rate);
> + return *prate;
> + }
> +
> + WARN_ON(!dd->enable_mask);
> +
> + v = omap2_clk_readl(pclk, dd->control_reg) & dd->enable_mask;
> + v >>= __ffs(dd->enable_mask);
> +
> + /* If in bypass, the rate is fixed to the bypass rate*/
> + if (v != OMAP3XXX_EN_DPLL_LOCKED)
> + return *prate;
> +
> + if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
> + unsigned long best_parent;
> +
> + best_parent = (rate / 2);
> + *prate = __clk_round_rate(__clk_get_parent(hw->clk),
> + best_parent);
> + }
> +
> + return *prate * 2;
> +}
> +
> /* OMAP3/4 non-CORE DPLL clkops */
> const struct clk_hw_omap_ops clkhwops_omap3_dpll = {
> .allow_idle = omap3_dpll_allow_idle,
> diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
> index 092b64168d7f..4a21a872dbbd 100644
> --- a/include/linux/clk/ti.h
> +++ b/include/linux/clk/ti.h
> @@ -245,6 +245,10 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
> void omap2_init_clk_clkdm(struct clk_hw *clk);
> unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw,
> unsigned long parent_rate);
> +int omap3_clkoutx2_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate);
> +long omap3_clkoutx2_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate);
> int omap2_clkops_enable_clkdm(struct clk_hw *hw);
> void omap2_clkops_disable_clkdm(struct clk_hw *hw);
> int omap2_clk_disable_autoidle_all(void);
> --
> 1.8.3.2
>
^ permalink raw reply
* [PATCH] ARM: OMAP3+: DPLL: stop reparenting to same parent if already done
From: Tony Lindgren @ 2014-02-13 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391591048-19433-1-git-send-email-nm@ti.com>
* Nishanth Menon <nm@ti.com> [140205 01:06]:
> omap3_noncore_dpll_set_rate forces a reparent to the same clk_ref
> for every call that takes place. This is an can be done only if a change
> is detected.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Would like to see acks on this too before applying.
Tony
> ---
> arch/arm/mach-omap2/dpll3xxx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
> index 3185ced..d9bcbf7 100644
> --- a/arch/arm/mach-omap2/dpll3xxx.c
> +++ b/arch/arm/mach-omap2/dpll3xxx.c
> @@ -525,7 +525,7 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate,
> * stuff is inherited for free
> */
>
> - if (!ret)
> + if (!ret && clk_get_parent(hw->clk) != new_parent)
> __clk_reparent(hw->clk, new_parent);
>
> return 0;
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] arm: dtsi: am335x-bone-common, usb0 is peripheral only
From: Markus Pargmann @ 2014-02-13 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213225438.GF28216@atomide.com>
Hi,
On Thu, Feb 13, 2014 at 02:54:38PM -0800, Tony Lindgren wrote:
> * Markus Pargmann <mpa@pengutronix.de> [140111 06:03]:
> > The PMIC is using usb0 vbus line as power source. It is also connected
> > to the am335x processor as vbus sense. But there is no possibility to
> > pullup usb0 vbus to operate as host. This patch fixes the dr_mode of usb0.
>
> That's the MUSB? AFAIK it's not possible to operate MUSB in peripheral
> only mode because the hardware does what it wants based on the ID
> pin state.
Yes that's MUSB. The am335x reference manual describes that it is
possible to force peripheral/host mode by setting bit 7 (IDDIG_MUX) in
register USBnMODE to 1. Then it uses the bit written in bit 8 (IDDIG) of
register USBnMODE to set host/peripheral mode.
I am not sure if the driver supports it yet but I think the DTS should
contain the correct mode nevertheless, especially to avoid starting the
otg loops in the musb driver.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2 0/9] Samsung PM consolidation part 1 (clocks)
From: Kukjin Kim @ 2014-02-13 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F4C9CB.6060901@samsung.com>
On 02/07/14 20:55, Sylwester Nawrocki wrote:
> On 07/02/14 04:45, Thomas Abraham wrote:
>> On Thu, Feb 6, 2014 at 11:46 PM, Tomasz Figa<t.figa@samsung.com> wrote:
>>>> This series reworks suspend/resume handling of Samsung clock drivers
>>>> to cover more SoC specific aspects that are beyond simple register
>>>> save and restore. The goal is to have all the suspend/resume code
>>>> that touches the clock controller in single place, which is the
>>>> clock driver.
>>>>
>>>> On Exynos4210-based Trats, Exynos4412-based Trats2 and Exynos5250-based
>>>> Arndale boards (except suspend/resume, which is broken because of
>>>> unrelated reasons):
>>>>
>>>> Tested-by: Tomasz Figa<t.figa@samsung.com>
>>>>
>>>> Tomasz Figa (9):
>>>> clk: exynos4: Remove remnants of non-DT support
>>>> clk: samsung: Provide common helpers for register save/restore
>>>> clk: samsung: exynos4: Move suspend/resume handling to SoC driver
>>>> clk: samsung: exynos5250: Move suspend/resume handling to SoC driver
>>>> clk: samsung: exynos5420: Move suspend/resume handling to SoC driver
>>>> clk: samsung: s3c64xx: Move suspend/resume handling to SoC driver
>>>> clk: samsung: Drop old suspend/resume code
>>>> clk: samsung: exynos4: Add remaining suspend/resume handling
>>>> ARM: EXYNOS: pm: Drop legacy Exynos4 clock suspend/resume code
>>>>
>>>> arch/arm/mach-exynos/pm.c | 148 +-----------------------------
>>>> drivers/clk/samsung/clk-exynos4.c | 172 +++++++++++++++++++++++++++++++----
>>>> drivers/clk/samsung/clk-exynos5250.c | 49 +++++++++-
>>>> drivers/clk/samsung/clk-exynos5420.c | 49 +++++++++-
>>>> drivers/clk/samsung/clk-exynos5440.c | 2 +-
>>>> drivers/clk/samsung/clk-s3c64xx.c | 79 +++++++++++++---
>>>> drivers/clk/samsung/clk.c | 71 ++++++---------
>>>> drivers/clk/samsung/clk.h | 14 ++-
>>>> 8 files changed, 348 insertions(+), 236 deletions(-)
>>
>> Nice series!
>> Reviewed-by: Thomas Abraham<thomas.ab@samsung.com>
>
> Yes, that's a nice cleanup.
>
> Reviewed-by: Sylwester Nawrocki<s.nawrocki@samsung.com>
>
+1 Nice
I've applied this whole series.
Thanks, Tomasz.
- Kukjin
^ permalink raw reply
* [PATCH V2 4/4] ARM: OMAP2+: AM43x: Use gptimer as clocksource
From: Tony Lindgren @ 2014-02-13 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391768486-2134-5-git-send-email-lokeshvutla@ti.com>
* Lokesh Vutla <lokeshvutla@ti.com> [140207 02:24]:
> From: Rajendra Nayak <rnayak@ti.com>
>
> The SyncTimer in AM43x is clocked using the following two sources:
> 1) An inaccuarte 32k clock (CLK_32KHZ) derived from PER DPLL, causing system
> time to go slowly (~10% deviation).
> 2) external 32KHz RTC clock, which may not always be available on board like
> in the case of ePOS EVM
>
> Use gptimer as clocksource instead, as is done in the case of AM335x
> (which does not have a SyncTimer). With this, system time keeping works
> accurately.
Hmm doesn't this also mean that PM for any deeper idle states won't
work properly?
Regards,
Tony
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> arch/arm/mach-omap2/board-generic.c | 2 +-
> arch/arm/mach-omap2/timer.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index 8e3daa1..5679464a 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -229,7 +229,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device Tree)")
> .init_late = am43xx_init_late,
> .init_irq = omap_gic_of_init,
> .init_machine = omap_generic_init,
> - .init_time = omap3_sync32k_timer_init,
> + .init_time = omap3_gptimer_timer_init,
> .dt_compat = am43_boards_compat,
> MACHINE_END
> #endif
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 74044aa..b62de9f 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -604,7 +604,8 @@ OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
> 2, "timer_sys_ck", NULL);
> #endif /* CONFIG_ARCH_OMAP3 */
>
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
> +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
> + defined(CONFIG_SOC_AM43XX)
> OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
> 1, "timer_sys_ck", "ti,timer-alwon");
> #endif
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] ARM: OMAP1: nokia770: enable tahvo-usb
From: Tony Lindgren @ 2014-02-13 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391867335-9192-1-git-send-email-aaro.koskinen@iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [140208 05:52]:
> Add platform data for tahvo-usb. This is the last missing piece to get
> Tahvo USB working with 3.14.
Applying into omap-for-v3.14/fixes thanks.
Tony
^ permalink raw reply
* [PATCH 1/2] ARM: dts: N9/N950: fix boot hang with 3.14-rc1
From: Tony Lindgren @ 2014-02-13 23:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FA83DE.70504@ti.com>
* Nishanth Menon <nm@ti.com> [140211 12:13]:
> On 02/09/2014 06:12 AM, Aaro Koskinen wrote:
> > N9/N950 does not boot anymore with 3.14-rc1, because SoC compatible
> > property is missing. Fix that.
> >
> > Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
>
> Reviewed-by: Nishanth Menon <nm@ti.com>
Applying both into omap-for-v3.14/fixes thanks.
Tony
^ permalink raw reply
* [PATCH] arm: dtsi: am335x-bone-common, usb0 is peripheral only
From: Tony Lindgren @ 2014-02-13 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140213231333.GK31787@pengutronix.de>
* Markus Pargmann <mpa@pengutronix.de> [140213 15:16]:
> Hi,
>
> On Thu, Feb 13, 2014 at 02:54:38PM -0800, Tony Lindgren wrote:
> > * Markus Pargmann <mpa@pengutronix.de> [140111 06:03]:
> > > The PMIC is using usb0 vbus line as power source. It is also connected
> > > to the am335x processor as vbus sense. But there is no possibility to
> > > pullup usb0 vbus to operate as host. This patch fixes the dr_mode of usb0.
> >
> > That's the MUSB? AFAIK it's not possible to operate MUSB in peripheral
> > only mode because the hardware does what it wants based on the ID
> > pin state.
>
> Yes that's MUSB. The am335x reference manual describes that it is
> possible to force peripheral/host mode by setting bit 7 (IDDIG_MUX) in
> register USBnMODE to 1. Then it uses the bit written in bit 8 (IDDIG) of
> register USBnMODE to set host/peripheral mode.
OK
> I am not sure if the driver supports it yet but I think the DTS should
> contain the correct mode nevertheless, especially to avoid starting the
> otg loops in the musb driver.
Well there's one more thing to consider.. I think in the OTG role change
case the VBUS is still driven externally from the original host, so the
lack of VBUS does not always mean that host mode should be disabled.
Regards,
Tony
^ permalink raw reply
* [PATCH v10 0/4] ata: Add APM X-Gene SoC SATA host controller support
From: Loc Ho @ 2014-02-13 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPw-ZTkbpOEHowGvp-_3DcW1qW0AK_ZbpdS1LESJfhFU-n_Mtw@mail.gmail.com>
Hi Tejun,
With regard to make use of the standard ahci_platform and recent Hans'
PHY works, the original version of the driver was an ahci_platform
driver. Unfortunately, the APM X-Gene SATA controller is more
complicate than an standard AHCI controller. In order to make it works
properly, the follow additional programming sequences are required:
1. There are a number of errata that require workaround. Some can be
fixed by adding broken flags while others are better to just wrap
around the existent libahci library routines and not overly polluting
the libahci routines.
2. There are additional controller programming sequences to configure.
2a. By default, RAM are powered down and require brought out of shutdown.
2b. The controller has an additional corresponding PHY part that needs
to be programmed after PHY configuration.
2c. The controller requires extra programming sequence for the
hardreset due to errata.
2d. For the IO flush, it requires additional memory resources.
3. With the current AHCI platform data handing and ARM64 arch support,
if I were to add custom AHCI platform data routine, I would need
equivalent functions and that would make the ARCH support having
knowledge of the SATA code which I don't want. Also, the DTS
processing/scanning in ARCH64 is NULL for platform data and would have
make X-Gene to have its own version which I also don't want.
-Loc
> On Thu, Jan 16, 2014 at 8:11 AM, Loc Ho <lho@apm.com> wrote:
>> This patch adds support for the APM X-Gene SoC SATA host controller. In
>> order for the host controller to work, the corresponding PHY driver
>> musts also be available.
>>
>> v10:
>> * Update binding documentation
>>
>> v9:
>> * Remove ACPI/EFI include files
>> * Remove the IO flush support, interrupt routine, and DTS resources
>> * Remove function xgene_rd, xgene_wr, and xgene_wr_flush
>> * Remove PMP support (function xgene_ahci_qc_issue, xgene_ahci_qc_prep,
>> xgene_ahci_qc_fill_rtf, xgene_ahci_softreset, and xgene_ahci_do_softreset)
>> * Rename function xgene_ahci_enable_phy to xgene_ahci_force_phy_rdy
>> * Clean up hardreset functions
>> * Require v7 of the PHY driver
>>
>> v8:
>> * Remove _ADDR from defines
>> * Remove define MSTAWAUX_COHERENT_BYPASS_SET and
>> STARAUX_COHERENT_BYPASS_SET and use direct coding
>> * Remove the un-necessary check for DTS boot with built in ACPI table
>> * Switch to use dma_set_mask_and_coherent for setting DMA mask
>> * Remove ACPI table matching code
>> * Update clock-names for sata01clk, sata23clk, and sata45clk
>>
>> v7:
>> * Update the clock code by toggle the clock
>> * Update the DTS clock mask values due to the clock spilt between host and
>> v5 of the PHY drivers
>>
>> v6:
>> * Update binding documentation
>> * Change select PHY_XGENE_SATA to PHY_XGENE
>> * Add ULL to constants
>> * Change indentation and comments
>> * Clean up the probe functions a bit more
>> * Remove xgene_ahci_remove function
>> * Add the flush register to DTS
>> * Remove the interrupt-parent from DTS
>>
>> v5:
>> * Sync up to v3 of the PHY driver
>> * Remove MSLIM wrapper functions
>> * Change the memory shutdown loop to use usleep_range
>> * Use devm_ioremap_resource instead devm_ioremap
>> * Remove suspend/resume functions as not needed
>>
>> v4:
>> * Remove the ID property in DT
>> * Remove the temporary PHY direct function call and use PHY function
>> * Change printk to pr_debug
>> * Move the IOB flush addresses into the DT
>> * Remove the parameters retrieval function as no longer needed
>> * Remove the header file as no longer needed
>> * Require v2 patch of the SATA PHY driver. Require slightly modification
>> in the Kconfig as it is moved to folder driver/phy and use Kconfig
>> PHY_XGENE_SATA instead SATA_XGENE_PHY.
>>
>> v3:
>> * Move out the SATA PHY to another driver
>> * Remove the clock-cells entry from DTS
>> * Remove debug wrapper
>> * Remove delay functions wrapper
>> * Clean up resource and IRQ query
>> * Remove query clock name
>> * Switch to use dma_set_mask/dma_coherent_mask
>> * Remove un-necessary devm_kfree
>> * Update GPL license header to v2
>> * Spilt up function xgene_ahci_hardreset
>> * Spilt up function xgene_ahci_probe
>> * Remove all reference of CONFIG_ARCH_MSLIM
>> * Clean up chip revision code
>>
>> v2:
>> * Clean up file sata_xgene.c with Lindent and etc
>> * Clean up file sata_xgene_serdes.c with Lindent and etc
>> * Add description to each patch
>>
>> v1:
>> * inital version
>>
>> Signed-off-by: Loc Ho <lho@apm.com>
>> Signed-off-by: Tuan Phan <tphan@apm.com>
>> Signed-off-by: Suman Tripathi <stripathi@apm.com>
>> ---
>> Loc Ho (4):
>> ata: Export required functions by APM X-Gene SATA driver
>> Documentation: Add documentation for APM X-Gene SoC SATA host
>> controller DTS binding
>> ata: Add APM X-Gene SoC SATA host controller driver
>> arm64: Add APM X-Gene SoC SATA host controller DTS entries
>>
>> .../devicetree/bindings/ata/apm-xgene.txt | 70 +++
>> arch/arm64/boot/dts/apm-storm.dtsi | 75 +++
>> drivers/ata/Kconfig | 8 +
>> drivers/ata/Makefile | 1 +
>> drivers/ata/ahci.h | 9 +
>> drivers/ata/libahci.c | 16 +-
>> drivers/ata/sata_xgene.c | 630 ++++++++++++++++++++
>> 7 files changed, 803 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/ata/apm-xgene.txt
>> create mode 100644 drivers/ata/sata_xgene.c
>>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Remove MACH_NOKIA_N800
From: Tony Lindgren @ 2014-02-13 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140209195021.GE573@drone.musicnaut.iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [140209 11:53]:
> Hi,
>
> On Sun, Feb 09, 2014 at 04:01:28PM +0100, Paul Bolle wrote:
> > The last caller of machine_is_nokia_n800() was removed in commit
> > 5a87cde490e1 ("ARM: OMAP2+: Remove legacy booting support for n8x0").
> > That means that the Kconfig symbol MACH_NOKIA_N800 is now unused. It can
> > safely be removed.
> >
> > Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
>
> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Thanks applying into omap-for-v3.14/fixes.
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Remove legacy macros for zoom platforms
From: Tony Lindgren @ 2014-02-13 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392198352.23759.10.camel@x220>
* Paul Bolle <pebolle@tiscali.nl> [140212 01:48]:
> Commit 97411608fd5f ("ARM: OMAP2+: Remove legacy support for zoom
> platforms") removed the Kconfig symbols MACH_OMAP_ZOOM2 and
> MACH_OMAP_ZOOM3. Remove the last usage of the related macros too.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> Untested, but should have zero impact.
Thanks applying into omap-for-v3.14/fixes.
Tony
^ permalink raw reply
* [PATCH v2 0/4] ARM: dts: Fixes for Overo/Tobi against 3.14-rc2
From: Tony Lindgren @ 2014-02-13 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392287116-4548-1-git-send-email-florian.vaussard@epfl.ch>
* Florian Vaussard <florian.vaussard@epfl.ch> [140213 02:28]:
> OMAP36xx-based Overo (Storm and alike) are now failing to boot with 3.14-rc2 [1].
> This series fixes this, by moving model-agnostic DT into a common dtsi file,
> and creating model-specific DT files:
>
> - omap3-overo-tobi.dts -> older OMAP35xx Overo
> - omap3-overo-storm-tobi.dts -> newer OMAP36xx/AM37xx/DM37xx Overo
>
> People will have to use the right Overo / expansion board combination.
>
> (Patch 2 in an unrelated fix that was waiting in my queue.)
>
> omap3-overo-tobi.dts tested with Overo Sand (OMAP3503) and omap3-overo-storm-tobi.dts
> tested with Overo EarthStorm (AM3703). Both boot. With the Overo Sand, I cannot
> mount the ext3 rootfs, but this seems unrelated to the current topic, maybe
> a missing errata.
Applying patches 1 to 3 into omap-for-v3.14/fixes thanks, the last
one still seems to have discussion going.
Tony
^ permalink raw reply
* [PATCH] gpu:drm:tilcdc: backlight node never found
From: Anatolij Gustschin @ 2014-02-13 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392299258-16968-1-git-send-email-hs@denx.de>
On Thu, 13 Feb 2014 14:47:38 +0100
Heiko Schocher <hs@denx.de> wrote:
> In panel_probe() the backlight node is never found, correct this.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
Acked-by: Anatolij Gustschin <agust@denx.de>
> Cc: Anatolij Gustschin <agust@denx.de>
> Cc: Benoit Parrot <bparrot@ti.com>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: David Airlie <airlied@linux.ie>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Cc: devicetree at vger.kernel.org
> ---
> drivers/gpu/drm/tilcdc/tilcdc_panel.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 86c6732..0b97cf4 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -356,6 +356,7 @@ static struct of_device_id panel_of_match[];
> static int panel_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> + struct device_node *backlight_node;
> struct panel_module *panel_mod;
> struct tilcdc_module *mod;
> struct pinctrl *pinctrl;
> @@ -395,9 +396,15 @@ static int panel_probe(struct platform_device *pdev)
>
> mod->preferred_bpp = panel_mod->info->bpp;
>
> - panel_mod->backlight = of_find_backlight_by_node(node);
> - if (panel_mod->backlight)
> - dev_info(&pdev->dev, "found backlight\n");
> + backlight_node = of_parse_phandle(pdev->dev.of_node, "backlight", 0);
> + if (backlight_node) {
> + panel_mod->backlight =
> + of_find_backlight_by_node(backlight_node);
> + if (panel_mod->backlight)
> + dev_info(&pdev->dev, "found backlight\n");
> + } else {
> + dev_warn(&pdev->dev, "backlight node missing...\n");
> + }
>
> return 0;
>
^ permalink raw reply
* [PATCH] thermal: imx: update formula for thermal sensor
From: Anson.Huang at freescale.com @ 2014-02-13 23:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+gwMccQPxxi2N8wTb4ggK2LaaZk1vOS6RtnP_XfpgLgJyYrtw@mail.gmail.com>
Hi, philipp
I know your concern, but from hardware team, they said due to the calibration tool's limitation, the high point calibration data is not reliable even the fuse data is there. If so, then comparing to old formula is not making sense, we should read the temperature in an oven and compare the oven environment's temperature to the result read from thermal sensor using new formula.
We have done the test, and this new formula is included in our BSP release already.
Sent from Anson's iPhone
> ? 2014?2?14??3:09?"Philipp Zabel" <philipp.zabel@gmail.com> ???
>
> Hi,
>
>> On Thu, Feb 13, 2014 at 2:02 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
>>
>> Copy LAKML and pengutronix folks in case they have comments.
>>
>>> On Wed, Feb 12, 2014 at 06:06:35PM +0800, Anson Huang wrote:
>>> Thermal sensor used to need two calibration points which are
>>> in fuse map to get a slope for converting thermal sensor's raw
>>> data to real temperature in degree C. Due to the chip calibration
>>> limitation, hardware team provides an universal formula to get
>>> real temperature from internal thermal sensor raw data:
>>>
>>> Slope = 0.4297157 - (0.0015976 * 25C fuse);
>
> I have an i.MX6Q 1.2 with 1417 counts at 25?C and 1296 counts at 105?C fused.
> Assuming that those values are fused correctly, with the old formula I get:
>
> t1=25, n1=1417, t2=105, n2=1296
> c1=1000*(t1-t2)/(n1-n2)=-662, c2=1000*t2-c1*n2=962952
> T_meas=c2+c1*N_meas=962952-662*N_meas
>
> N_meas=1417 --> T_meas = 24898
> N_meas=1296 --> T_meas = 105000
>
> With the new formula, on the other hand, I would get:
>
> t1=25, n1=1417
> F0=10000000, F1=15976, 4297157
> c1=F0*1000/(F1*n1-F2)=545, c2=n1*c1+1000*25=797265
> T_meas=c2-N_meas*c1=797265-N_meas*545
>
> N_meas=1417 --> T_meas = 25000
> N_meas=1296 --> T_meas = 90945
>
> That's off by over 14?C!
>
> The default passive cooling trip point is at 85?C,
> which translated to 1326 counts before:
> alarm_value=(alarm_temp-c2)/c1=(85000-962952)/(-662)=1326
>
> With the new formula the trip count is only
> alarm_value=(c2-alarm_temp)/c1=(797265-85000)/545=1306
> That translates to 98.4?C according to the old formula. I think
> that is awfully close to the critical trip point at 100?C, which,
> according to the old formula, corresponded to 1303 counts.
>
> The new critical trip point for 100?C is at 1279 counts. According
> to the old formula this corresponds to 116.2?C, well over the
> rated maximum of 105?C.
>
> Do I need to be afraid for my old silicon?
>
>>> Update the formula, as there will be no hot point calibration
>>> data in fuse map from now on.
>
> I wonder if it would be better to keep using the high temperature
> calibration point if it is fused at all.
>
> regards
> Philipp
>
>
^ permalink raw reply
* [PATCH] ARM: DTS: exynos5420: Rename hsi2c compatible to exynos5250-hsi2c
From: Kukjin Kim @ 2014-02-13 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391688477-8124-1-git-send-email-ch.naveen@samsung.com>
On 02/06/14 21:07, Naveen Krishna Chatradhi wrote:
> As per the changes submitted for the i2c-exynos5.c driver with the
> compatible string being named after the first SoC it is observed on.
> This patch modifes the existing hsi2c compatible strings in
> arch/arm/boot/dts.
>
> Signed-off-by: Naveen Krishna Chatradhi<ch.naveen@samsung.com>
> ---
> arch/arm/boot/dts/exynos5420.dtsi | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index 11dd202..c5187d1 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -486,7 +486,7 @@
> };
>
> hsi2c_4: i2c at 12CA0000 {
> - compatible = "samsung,exynos5-hsi2c";
> + compatible = "samsung,exynos5250-hsi2c";
> reg =<0x12CA0000 0x1000>;
> interrupts =<0 60 0>;
> #address-cells =<1>;
> @@ -499,7 +499,7 @@
> };
>
> hsi2c_5: i2c at 12CB0000 {
> - compatible = "samsung,exynos5-hsi2c";
> + compatible = "samsung,exynos5250-hsi2c";
> reg =<0x12CB0000 0x1000>;
> interrupts =<0 61 0>;
> #address-cells =<1>;
> @@ -512,7 +512,7 @@
> };
>
> hsi2c_6: i2c at 12CC0000 {
> - compatible = "samsung,exynos5-hsi2c";
> + compatible = "samsung,exynos5250-hsi2c";
> reg =<0x12CC0000 0x1000>;
> interrupts =<0 62 0>;
> #address-cells =<1>;
> @@ -525,7 +525,7 @@
> };
>
> hsi2c_7: i2c at 12CD0000 {
> - compatible = "samsung,exynos5-hsi2c";
> + compatible = "samsung,exynos5250-hsi2c";
> reg =<0x12CD0000 0x1000>;
> interrupts =<0 63 0>;
> #address-cells =<1>;
> @@ -538,7 +538,7 @@
> };
>
> hsi2c_8: i2c at 12E00000 {
> - compatible = "samsung,exynos5-hsi2c";
> + compatible = "samsung,exynos5250-hsi2c";
> reg =<0x12E00000 0x1000>;
> interrupts =<0 87 0>;
> #address-cells =<1>;
> @@ -551,7 +551,7 @@
> };
>
> hsi2c_9: i2c at 12E10000 {
> - compatible = "samsung,exynos5-hsi2c";
> + compatible = "samsung,exynos5250-hsi2c";
> reg =<0x12E10000 0x1000>;
> interrupts =<0 88 0>;
> #address-cells =<1>;
> @@ -564,7 +564,7 @@
> };
>
> hsi2c_10: i2c at 12E20000 {
> - compatible = "samsung,exynos5-hsi2c";
> + compatible = "samsung,exynos5250-hsi2c";
> reg =<0x12E20000 0x1000>;
> interrupts =<0 203 0>;
> #address-cells =<1>;
Naveen,
Please don't post separately for one series. It's hard to find to look
at regarding patches.
And please post regarding binding doc together. Additionally if you run
checkpatch, you can see see below complaining.
"WARNING: DT compatible string "samsung,exynos5250-hsi2c" appears
un-documented -- check ./Documentation/devicetree/bindings/"
- Kukjin
^ permalink raw reply
* [PATCH] drivers: net: cpsw: fix buggy loop condition
From: David Miller @ 2014-02-13 23:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392299247-16917-1-git-send-email-hs@denx.de>
From: Heiko Schocher <hs@denx.de>
Date: Thu, 13 Feb 2014 14:47:27 +0100
> commit:
> From 0cd8f9cc0654c06adde353c6532114c5f53a18e8 Mon Sep 17 00:00:00 2001
> From: Mugunthan V N <mugunthanvnm@ti.com>
> Date: Thu, 23 Jan 2014 00:03:12 +0530
> Subject: [PATCH] drivers: net: cpsw: enable promiscuous mode support
The correct way to reference a commit is:
$(SHA1_ID) ("Commit message header text.")
So in this case it would be:
Commit 0cd8f9cc0654c06adde353c6532114c5f53a18e8 ("drivers: net: cpsw:
enable promiscuous mode support")
I fixed this up when applying this patch. I will not extend this same
courtesy next time.
> Enable promiscuous mode support for CPSW.
>
> Introduced a crash on an am335x based board (similiar to am335x-evm).
> Reason is buggy end condition in for loop in cpsw_set_promiscious()
>
> for (i = 0; i <= priv->data.slaves; i++)
>
> should be
>
> for (i = 0; i < priv->data.slaves; i++)
>
> Fix this ...
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
Applied, thanks.
^ permalink raw reply
* Samsung-clk patches for 3.15
From: Kukjin Kim @ 2014-02-14 0:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E6F726.1070900@gmail.com>
On 01/28/14 09:17, Tomasz Figa wrote:
>
>
> On 28.01.2014 01:09, Kukjin Kim wrote:
>> Tomasz Figa wrote:
>>>
>>> [Forgot to Cc Mike...]
>>>
>>> On 24.01.2014 15:38, Tomasz Figa wrote:
>>>> Hi,
>>>>
>>
>> Hi,
>>
>>>> Linux 3.14 is going to include Andrzej Hajda's patches converting
>>>> Samsung clock drivers to use clock ID defines in include/dt-bindings,
>>>> instead of local enums, but to avoid unnecessary merge conflicts we
>>>> have converted only the clock driver, leaving DTS files unchanged yet.
>>>>
>>>> We intend to complete the conversion in 3.15, by replacing magic
>>>> numbers in DTS files with respective preprocessor macros, but to
>>>> reduce potential conflicts we need help of you, Samsung clock patches
>>> authors :).
>>>>
>>>> I'd like to ask anybody who already has patches for DTS files adding
>>>> any clock-related contents still using numeric IDs, e.g. clock
>>>> properties in nodes or full nodes containing clock properties, to make
>>>> sure that the patches are merged before Andrzej sends the conversion
>>>> patches. Then Andrzej's script will generate patches updating all
>>>> clock properties, leaving no numeric IDs in DTS files.
>>>>
>>
>> There are several DTS patches in v3.14-drop/soc-exynos-2 branch of my
>> tree
>> for 3.15 and it will be merged after done of multiplatform, I need to
>> rebase
>> them based on v3.14-rc1 though...So I think, would be better if we could
>> update DTS with using Andrzej's script after merging it into arm-soc...
>
> Basically my intention is to:
>
> 1) Have any existing patches using clock numbers merged in reasonable
> period of time (to not miss the merge window with DTS conversion patches).
>
> 2) Stop accepting such patches anymore.
>
> 3) Rerun Andrzej's script and convert all device tree sources to use
> clock macros.
>
> Andrzej's patches for DTSes should go through your tree anyway (as any
> Samsung DTS patches by default), so it shouldn't be a problem,
> regardless of merging anything into arm-soc.
>
Makes sense, OK. I agreed. I'll apply Andrzej's "[PATCH RESEND v2 00/12]
clk/exynos convert clock IDs to macros" and every exynos dt should be
posted based on that from now on.
Thanks,
- Kukjin
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Sarah Sharp @ 2014-02-14 0:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wqh2iymx.fsf@natisbad.org>
On Mon, Feb 10, 2014 at 07:57:42PM +0100, Arnaud Ebalard wrote:
> Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
>
> > On Wed, Jan 22, 2014 at 11:43:16PM +0100, Arnaud Ebalard wrote:
> >> f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts."
> >>
> >> Technically, this is not per se the commit which introduced the
> >> regression but the one that *partially* fixed it by introducing the XHCI
> >> quirk to skip MSI enabling for Fresco Logic chips. The thing is it
> >> should have included the FL1009 in the targets. Sarah, can you confirm
> >> this?
> >
> > I don't know if it should have included FL1009, it was just a guess,
> > based on the fact that the 0x1000 and 0x1400 devices did need MSI
> > disabled. I can attempt to ask the Fresco Logic folks I know, but I'm
> > not sure if/when I'll get a response back.
> >
> > That still doesn't necessarily rule out MSI issues in the Marvell PCI
> > host controller code. Can you attach another PCI device with MSI
> > support under the host and see if it works?
>
> Unless you have some objections or some positive feedback from Fresco
> Logic people, can you queue your quirks for FL1009 for 3.14-rc* and
> -stable? Note that I am just asking, i.e. if you want to wait a bit
> more, I am not that in a hurry.
Sorry for not getting back to you sooner. The Fresco Logic folks said
that the FL1000 and FL1400 hosts are actually the same chipset, and it
doesn't support MSI. However, they say the FL1009 *should* support MSI.
So that doesn't rule out issues with the Marvell PCI MSI code. I
suspect that's actually the root cause, since I haven't gotten any bug
reports that the FL1009 doesn't work with MSI enabled on other systems.
Sarah Sharp
^ permalink raw reply
* [PATCH RESEND v2 00/12] clk/exynos convert clock IDs to macros
From: Kukjin Kim @ 2014-02-14 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127214944.4167.58042@quantum>
On 01/28/14 06:49, Mike Turquette wrote:
> Quoting Tomasz Figa (2014-01-07 07:17:22)
>> Hi Mike,
>>
>> On Tuesday 07 of January 2014 15:47:28 Andrzej Hajda wrote:
>>> Hi,
>>>
>>> This patch set adds header files with macros defining exynos clocks.
>>> Then it converts dts files and drivers to use macros instead
>>> of magic numbers or enums to describe clock bindings.
>>>
>>> The patch set is rebased on the latest samsung-clk/samsung-next branch.
>>>
>>> The patches are generated by script.
>>> Many clocks I have verified by hand.
>>> I have also tested it successfully on exynos4 based board.
>>>
>>> This is the 2nd version of the patchset.
>>> Changes:
>>> - corrected devicetree mailing list,
>>> - added comments to include/dt-bindings/clock/exynos4.h for
>>> clocks present only in particular chip,
>>> - added tab alignement in headers,
>>> - added comment to CLK_NR_CLKS,
>>> - added copyright headers,
>>> - split long lines in dts,
>>> - corrected example in bindings/clock/exynos5250-clock.txt, to point
>>> appropriate clocks.
>>
>> I believe this has been already acked before, so could you still take
>> it for 3.14? For now I'd merge only the patches adding headers and
>> updating clock drivers to avoid merge conflicts and then after
>> release of 3.14-rc1 we could early merge dts patches for 3.15.
>
> Hi Tomasz,
>
> Let's go ahead and merge this after 3.14-rc1. I'll take it in when that
> drops and the DTS data will go in during the same merge window.
>
Hi Mike,
As I talked to Tomasz, would be better to us if this series could be
handled in Samsung tree so I'm going to do it. How do you think?
- Kukjin
^ permalink raw reply
* [PATCH] iommu/exynos: Remove driver
From: Cho KyongHo @ 2014-02-14 0:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhH2WHvkaobewdnPeiThrWTfw0m4WWAZW98-iS2xdr+ow@mail.gmail.com>
> -----Original Message-----
> From: Olof Johansson [mailto:olof at lixom.net]
> Sent: Friday, February 14, 2014 4:34 AM
>
> On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim <kgene.kim@gmail.com> wrote:
>
> > Just adding KyongHo Cho.
> >
> > If he can fixup for this time, it would be best solution because he knows
> > well than others, I think.
>
> It's not so much a matter of "fixup for this time", it's a about
> having ownership of the driver, making sure it works (and keeps
> working if there is related development). The posted patches have not
> been followed through on and the result is a broken driver. :(
>
> I definitely appreciate his expertise, and we should make sure that he
> gets to review the code, but if someone else is able to spend time on
> reworking the driver (or rewriting a newer one) and maintaining it
> longer-term, then we should not stop them from doing so. And there is
> no reason to keep broken stale code in the kernel meanwhile.
>
Thank you for your concerning.
I also definitely agree with you that the driver must work.
I am always concerning about it but it was not easy to make some time
for the patches.
I will continue to post the next version of patches, of course.
I think it is not far from now to show it.
Regards,
Ky0ongHo
^ permalink raw reply
* [PATCH RESEND v2 00/12] clk/exynos convert clock IDs to macros
From: Kukjin Kim @ 2014-02-14 0:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FD5EDA.60909@samsung.com>
On 02/14/14 09:10, Kukjin Kim wrote:
> On 01/28/14 06:49, Mike Turquette wrote:
>> Quoting Tomasz Figa (2014-01-07 07:17:22)
>>> Hi Mike,
>>>
>>> On Tuesday 07 of January 2014 15:47:28 Andrzej Hajda wrote:
>>>> Hi,
>>>>
>>>> This patch set adds header files with macros defining exynos clocks.
>>>> Then it converts dts files and drivers to use macros instead
>>>> of magic numbers or enums to describe clock bindings.
>>>>
>>>> The patch set is rebased on the latest samsung-clk/samsung-next branch.
>>>>
>>>> The patches are generated by script.
>>>> Many clocks I have verified by hand.
>>>> I have also tested it successfully on exynos4 based board.
>>>>
>>>> This is the 2nd version of the patchset.
>>>> Changes:
>>>> - corrected devicetree mailing list,
>>>> - added comments to include/dt-bindings/clock/exynos4.h for
>>>> clocks present only in particular chip,
>>>> - added tab alignement in headers,
>>>> - added comment to CLK_NR_CLKS,
>>>> - added copyright headers,
>>>> - split long lines in dts,
>>>> - corrected example in bindings/clock/exynos5250-clock.txt, to point
>>>> appropriate clocks.
>>>
>>> I believe this has been already acked before, so could you still take
>>> it for 3.14? For now I'd merge only the patches adding headers and
>>> updating clock drivers to avoid merge conflicts and then after
>>> release of 3.14-rc1 we could early merge dts patches for 3.15.
>>
>> Hi Tomasz,
>>
>> Let's go ahead and merge this after 3.14-rc1. I'll take it in when that
>> drops and the DTS data will go in during the same merge window.
>>
>
> Hi Mike,
>
> As I talked to Tomasz, would be better to us if this series could be
> handled in Samsung tree so I'm going to do it. How do you think?
>
Oops, already merged into mainline ;-)
Sorry, please kindly ignore my previous e-mail.
Thanks,
Kukjin
^ permalink raw reply
* [PATCH] ARM: tegra: fix RTC0 alias for Cardhu
From: Stephen Warren @ 2014-02-14 0:18 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
This alias entry was evidently cut/paste from a different board, and
not correctly updated to match Cardhu. Fix this.
Fixes: 553c0a200e20 ("ARM: tegra: set up /aliases entries for RTCs")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This is a fix for v3.14-rc*
arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 004002c8c8a5..0cf0848a82d8 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -28,7 +28,7 @@
compatible = "nvidia,cardhu", "nvidia,tegra30";
aliases {
- rtc0 = "/i2c at 7000d000/tps6586x at 34";
+ rtc0 = "/i2c at 7000d000/tps65911 at 2d";
rtc1 = "/rtc at 7000e000";
};
--
1.8.1.5
^ permalink raw reply related
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