* [PATCH V2 1/8] SPEAr13xx: Set dt field entry <stmmac,phy-addr> for phy probe
From: Chen-Yu Tsai @ 2014-01-24 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x=mQLyMV_0Swf3o2c9bW_DNCLT-fQFc3Qs6yt1+9prabmw@mail.gmail.com>
Hi,
On Fri, Jan 24, 2014 at 1:02 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
>> DT field name for the phy address changed since kernel 3.10. Set the
>> snps,phy-addr to 0xffffffff so that the driver probes for the phy.
This will no longer be required. The default behavior for
DT based setups has been changed to auto-detecting the phy.
See http://patchwork.ozlabs.org/patch/312063/
Cheers
ChenYu
>>
>> Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
>> Cc: Pratyush Anand <pratyush.anand@st.com>
>> Cc: Viresh Kumar <viresh.linux@gmail.com>
>> Cc: spear-devel at list.st.com
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: devicetree at vger.kernel.org
>> ---
>> arch/arm/boot/dts/spear13xx.dtsi | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
>> index 4382547..3518803 100644
>> --- a/arch/arm/boot/dts/spear13xx.dtsi
>> +++ b/arch/arm/boot/dts/spear13xx.dtsi
>> @@ -155,6 +155,7 @@
>>
>> gmac0: eth at e2000000 {
>> compatible = "st,spear600-gmac";
>> + snps,phy-addr = <0xffffffff>;
>> reg = <0xe2000000 0x8000>;
>> interrupts = <0 33 0x4
>> 0 34 0x4>;
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] PWM: let of_xlate handlers check args count
From: Lothar Waßmann @ 2014-01-24 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123173642.GZ15937@n2100.arm.linux.org.uk>
Hi,
Russell King - ARM Linux wrote:
> On Thu, Jan 23, 2014 at 04:53:50PM +0000, Russell King - ARM Linux wrote:
> > On Thu, Jan 23, 2014 at 12:04:44PM +0100, Sascha Hauer wrote:
> > > On Thu, Jan 23, 2014 at 11:56:32AM +0100, Lothar Wa?mann wrote:
> > > > Hi,
> > > >
> > > > Sascha Hauer wrote:
> > > > > of_pwm_n_cells for the of_xlate handler is stored in struct pwm_chip,
> > > > > but it is only ever used by the of_xlate handler itsel. Remove
> > > > > of_pwm_n_cells from struct pwm_chip and let the handler do the argument
> > > > > count checking to simplify the code.
> > > > >
> > > > This still does not make the PWM_POLARITY flag in the pwms node
> > > > optional as was the goal because of_parse_phandle_with_args() requires
> > > > at least #pwm-cells arguments in the node.
> > > >
> > > > So, with a DT configuration like:
> > > > pwm0: pwm at 0 {
> > > > #pwm-cells = <3>;
> > > > };
> > > > backlight {
> > > > pwms = <&pwm0 0 100000>;
> > > > };
> > >
> > > We misunderstood each other. My goal was to allow the driver to also
> > > work with old devicetrees which specify #pwm-cells = <2>, not to allow
> > > inconsistent devicetrees like the snippet above.
> >
> > In which case, the patch I've posted seems to do that job too... I'm
> > just about to test out the three-cell version.
>
> Okay, this works, but there's a problem with pwm-leds.
>
> When the duty cycle is set to zero (when you set the brightness to zero)
> pwm-leds decides to disable the PWM after configuring it. This causes
> the PWM output to be driven low, causing the LED to go to maximum
> brightness.
>
> So, using the inversion at PWM level doesn't work.
>
The problem is that the driver calls pwm_disable() when the duty cycle is 0.
This sets the PWM output low independent from the output polarity setting.
> To make this work correctly, we really need pwm-leds to do the inversion
> rather than setting the inversion bit in hardware.
>
The same holds for the pwm-backlight driver.
The easiest fix would be not to call pwm_disable() even for a zero duty
cycle.
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH V2 6/8] SPEAr13xx: Fix static mapping table
From: Pratyush Anand @ 2014-01-24 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x=nAUxyx+5y4yA=NSEQPTAPLfdxaFjc=k8r1NyRUgZLu8A@mail.gmail.com>
On Fri, Jan 24, 2014 at 01:07:38PM +0800, Viresh Kumar wrote:
> On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> > From: Pratyush Anand <pratyush.anand@st.com>
> >
> > SPEAr13xx was using virtual address space 0xFE000000 to map physical address
> > space 0xB3000000. pci_remap_io uses 0xFEE00000 as virtual address. So
> > change 0xFE000000 to 0xF9000000.
> >
> > Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> > Tested-by: Mohit Kumar <mohit.kumar@st.com>
> > Cc: Viresh Kumar <viresh.linux@gmail.com>
> > Cc: spear-devel at list.st.com
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > ---
> > arch/arm/mach-spear/include/mach/spear.h | 4 ++--
> > arch/arm/mach-spear/spear13xx.c | 2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-spear/include/mach/spear.h b/arch/arm/mach-spear/include/mach/spear.h
> > index 5cdc53d..f2d6a01 100644
> > --- a/arch/arm/mach-spear/include/mach/spear.h
> > +++ b/arch/arm/mach-spear/include/mach/spear.h
> > @@ -52,10 +52,10 @@
> > #ifdef CONFIG_ARCH_SPEAR13XX
> >
> > #define PERIP_GRP2_BASE UL(0xB3000000)
> > -#define VA_PERIP_GRP2_BASE IOMEM(0xFE000000)
> > +#define VA_PERIP_GRP2_BASE IOMEM(0xF9000000)
> > #define MCIF_SDHCI_BASE UL(0xB3000000)
> > #define SYSRAM0_BASE UL(0xB3800000)
> > -#define VA_SYSRAM0_BASE IOMEM(0xFE800000)
> > +#define VA_SYSRAM0_BASE IOMEM(0xF9800000)
> > #define SYS_LOCATION (VA_SYSRAM0_BASE + 0x600)
> >
> > #define PERIP_GRP1_BASE UL(0xE0000000)
> > diff --git a/arch/arm/mach-spear/spear13xx.c b/arch/arm/mach-spear/spear13xx.c
> > index 7aa6e8c..20ce885 100644
> > --- a/arch/arm/mach-spear/spear13xx.c
> > +++ b/arch/arm/mach-spear/spear13xx.c
> > @@ -52,10 +52,10 @@ void __init spear13xx_l2x0_init(void)
> > /*
> > * Following will create 16MB static virtual/physical mappings
> > * PHYSICAL VIRTUAL
> > - * 0xB3000000 0xFE000000
> > * 0xE0000000 0xFD000000
> > * 0xEC000000 0xFC000000
> > * 0xED000000 0xFB000000
> > + * 0xB3000000 0xF9000000
>
>
> Why have you moved this to bottom of list? It was probably kept
> in increasing order and so please keep the same.
Oh,yes..ll be corrected in v3 of series.
>
> Other than that:
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Thanks.
Regards
Pratyush
^ permalink raw reply
* [PATCH V2 6/8] SPEAr13xx: Fix static mapping table
From: Viresh Kumar @ 2014-01-24 5:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22d2e7d6fbd5a291cdecf6a4d1e294d9c9ede617.1390471111.git.mohit.kumar@st.com>
On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> From: Pratyush Anand <pratyush.anand@st.com>
>
> SPEAr13xx was using virtual address space 0xFE000000 to map physical address
> space 0xB3000000. pci_remap_io uses 0xFEE00000 as virtual address. So
> change 0xFE000000 to 0xF9000000.
>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> Tested-by: Mohit Kumar <mohit.kumar@st.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-spear/include/mach/spear.h | 4 ++--
> arch/arm/mach-spear/spear13xx.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-spear/include/mach/spear.h b/arch/arm/mach-spear/include/mach/spear.h
> index 5cdc53d..f2d6a01 100644
> --- a/arch/arm/mach-spear/include/mach/spear.h
> +++ b/arch/arm/mach-spear/include/mach/spear.h
> @@ -52,10 +52,10 @@
> #ifdef CONFIG_ARCH_SPEAR13XX
>
> #define PERIP_GRP2_BASE UL(0xB3000000)
> -#define VA_PERIP_GRP2_BASE IOMEM(0xFE000000)
> +#define VA_PERIP_GRP2_BASE IOMEM(0xF9000000)
> #define MCIF_SDHCI_BASE UL(0xB3000000)
> #define SYSRAM0_BASE UL(0xB3800000)
> -#define VA_SYSRAM0_BASE IOMEM(0xFE800000)
> +#define VA_SYSRAM0_BASE IOMEM(0xF9800000)
> #define SYS_LOCATION (VA_SYSRAM0_BASE + 0x600)
>
> #define PERIP_GRP1_BASE UL(0xE0000000)
> diff --git a/arch/arm/mach-spear/spear13xx.c b/arch/arm/mach-spear/spear13xx.c
> index 7aa6e8c..20ce885 100644
> --- a/arch/arm/mach-spear/spear13xx.c
> +++ b/arch/arm/mach-spear/spear13xx.c
> @@ -52,10 +52,10 @@ void __init spear13xx_l2x0_init(void)
> /*
> * Following will create 16MB static virtual/physical mappings
> * PHYSICAL VIRTUAL
> - * 0xB3000000 0xFE000000
> * 0xE0000000 0xFD000000
> * 0xEC000000 0xFC000000
> * 0xED000000 0xFB000000
> + * 0xB3000000 0xF9000000
Why have you moved this to bottom of list? It was probably kept
in increasing order and so please keep the same.
Other than that:
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH V2 5/8] clk: SPEAr13xx: Fix pcie clock name
From: Viresh Kumar @ 2014-01-24 5:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1d96a68894439fa9a571e6234745ab60d4c0f1f5.1390471111.git.mohit.kumar@st.com>
On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> From: Pratyush Anand <pratyush.anand@st.com>
>
> Follow dt clock naming convention for PCIe clocks.
>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> Tested-by: Mohit Kumar <mohit.kumar@st.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/clk/spear/spear1310_clock.c | 6 +++---
> drivers/clk/spear/spear1340_clock.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH V2 2/8] SPEAr13xx: defconfig: Update
From: Viresh Kumar @ 2014-01-24 5:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e60c36509dd5d9a39ae7671f8ac80ad1f4506e29.1390471111.git.mohit.kumar@st.com>
On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> Enable EABI, OEABI, VFP and NFS configs in default configuration file for
> SPEAr13xx.
>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
> Cc: Mohit Kumar <mohit.kumar@st.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH V2 1/8] SPEAr13xx: Set dt field entry <stmmac,phy-addr> for phy probe
From: Viresh Kumar @ 2014-01-24 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12754927160d11063aad96c011c4807cb0aa1775.1390471111.git.mohit.kumar@st.com>
On Thu, Jan 23, 2014 at 4:02 PM, Mohit Kumar <mohit.kumar@st.com> wrote:
> DT field name for the phy address changed since kernel 3.10. Set the
> snps,phy-addr to 0xffffffff so that the driver probes for the phy.
>
> Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
> Cc: Pratyush Anand <pratyush.anand@st.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: devicetree at vger.kernel.org
> ---
> arch/arm/boot/dts/spear13xx.dtsi | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
> index 4382547..3518803 100644
> --- a/arch/arm/boot/dts/spear13xx.dtsi
> +++ b/arch/arm/boot/dts/spear13xx.dtsi
> @@ -155,6 +155,7 @@
>
> gmac0: eth at e2000000 {
> compatible = "st,spear600-gmac";
> + snps,phy-addr = <0xffffffff>;
> reg = <0xe2000000 0x8000>;
> interrupts = <0 33 0x4
> 0 34 0x4>;
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH V2 4/8] SPEAr13xx: Fixup: Move SPEAr1340 SATA platform code to system cfg driver
From: Pratyush Anand @ 2014-01-24 4:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401231322.54914.arnd@arndb.de>
Hi Arnd,
Thanks for your valuable comments.
On Thu, Jan 23, 2014 at 08:22:54PM +0800, Arnd Bergmann wrote:
> On Thursday 23 January 2014, Mohit Kumar wrote:
> > diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
> > index 3518803..2b4e58e 100644
> > --- a/arch/arm/boot/dts/spear13xx.dtsi
> > +++ b/arch/arm/boot/dts/spear13xx.dtsi
> > @@ -78,6 +78,10 @@
> > status = "disabled";
> > };
> >
> > + cfg {
> > + compatible = "st,spear13xx-cfg";
> > + };
> > +
> > ahb {
> > #address-cells = <1>;
> > #size-cells = <1>;
>
> I only saw some of the patches, and did not get a patch with the binding
> description for this device. Please forward that patch to me, or add it
> to the series if you didn't have one.
It was not there.
Will add a patch for the same in v3.
>
> I assume you'd want a phandle pointing to the syscon device in here
> as well?
Since there is only one syscon device in the whole DT, so do I really
need to add phandle? Currently I am using
syscon_regmap_lookup_by_compatible to find syscon device.
>
> Regarding the naming, please do not use 'xx' wildcards in DT compatible
> strings. Instead, use the exact model name of the first supported
> version of the hardware (e.g. spear1300 or spear600) that remains
> compatible. If there are minor variations between the versions,
> use a list with the most specific version as well as the older ones
> it's compatible with.
Ok..ll take care.
>
> > @@ -221,6 +225,11 @@
> > 0xd8000000 0xd8000000 0x01000000
> > 0xe0000000 0xe0000000 0x10000000>;
> >
> > + misc: misc at e0700000 {
> > + compatible = "st,spear13xx-misc", "syscon";
> > + reg = <0xe0700000 0x1000>;
> > + };
> > +
>
> Same here. Also, I would make this 'misc: syscon at e0700000', since 'misc'
> does not seem like an appropriate device name.
Ok.
>
>
> > +/* SPEAr1340 Registers */
> > +/* Power Management Registers */
> > +#define SPEAR1340_PCM_CFG 0x100
> > + #define SPEAR1340_PCM_CFG_SATA_POWER_EN 0x800
> > +#define SPEAR1340_PCM_WKUP_CFG 0x104
> > +#define SPEAR1340_SWITCH_CTR 0x108
> > +
> > +#define SPEAR1340_PERIP1_SW_RST 0x318
> > + #define SPEAR1340_PERIP1_SW_RST_SATA 0x1000
> > +#define SPEAR1340_PERIP2_SW_RST 0x31C
> > +#define SPEAR1340_PERIP3_SW_RST 0x320
> > +
> > +/* PCIE - SATA configuration registers */
> > +#define SPEAR1340_PCIE_SATA_CFG 0x424
> > + /* PCIE CFG MASks */
> > + #define SPEAR1340_PCIE_CFG_DEVICE_PRESENT (1 << 11)
> > + #define SPEAR1340_PCIE_CFG_POWERUP_RESET (1 << 10)
> > + #define SPEAR1340_PCIE_CFG_CORE_CLK_EN (1 << 9)
> > + #define SPEAR1340_PCIE_CFG_AUX_CLK_EN (1 << 8)
> > + #define SPEAR1340_SATA_CFG_TX_CLK_EN (1 << 4)
> > + #define SPEAR1340_SATA_CFG_RX_CLK_EN (1 << 3)
> > + #define SPEAR1340_SATA_CFG_POWERUP_RESET (1 << 2)
> > + #define SPEAR1340_SATA_CFG_PM_CLK_EN (1 << 1)
> > + #define SPEAR1340_PCIE_SATA_SEL_PCIE (0)
> > + #define SPEAR1340_PCIE_SATA_SEL_SATA (1)
> > + #define SPEAR1340_PCIE_SATA_CFG_MASK 0xF1F
> > + #define SPEAR1340_PCIE_CFG_VAL (SPEAR1340_PCIE_SATA_SEL_PCIE | \
> > + SPEAR1340_PCIE_CFG_AUX_CLK_EN | \
> > + SPEAR1340_PCIE_CFG_CORE_CLK_EN | \
> > + SPEAR1340_PCIE_CFG_POWERUP_RESET | \
> > + SPEAR1340_PCIE_CFG_DEVICE_PRESENT)
> > + #define SPEAR1340_SATA_CFG_VAL (SPEAR1340_PCIE_SATA_SEL_SATA | \
> > + SPEAR1340_SATA_CFG_PM_CLK_EN | \
> > + SPEAR1340_SATA_CFG_POWERUP_RESET | \
> > + SPEAR1340_SATA_CFG_RX_CLK_EN | \
> > + SPEAR1340_SATA_CFG_TX_CLK_EN)
> > +
> > +#define SPEAR1340_PCIE_MIPHY_CFG 0x428
> > + #define SPEAR1340_MIPHY_OSC_BYPASS_EXT (1 << 31)
> > + #define SPEAR1340_MIPHY_CLK_REF_DIV2 (1 << 27)
> > + #define SPEAR1340_MIPHY_CLK_REF_DIV4 (2 << 27)
> > + #define SPEAR1340_MIPHY_CLK_REF_DIV8 (3 << 27)
> > + #define SPEAR1340_MIPHY_PLL_RATIO_TOP(x) (x << 0)
> > + #define SPEAR1340_PCIE_MIPHY_CFG_MASK 0xF80000FF
> > + #define SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA \
> > + (SPEAR1340_MIPHY_OSC_BYPASS_EXT | \
> > + SPEAR1340_MIPHY_CLK_REF_DIV2 | \
> > + SPEAR1340_MIPHY_PLL_RATIO_TOP(60))
> > + #define SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA_25M_CRYSTAL_CLK \
> > + (SPEAR1340_MIPHY_PLL_RATIO_TOP(120))
> > + #define SPEAR1340_PCIE_SATA_MIPHY_CFG_PCIE \
> > + (SPEAR1340_MIPHY_OSC_BYPASS_EXT | \
> > + SPEAR1340_MIPHY_PLL_RATIO_TOP(25))
> > +
> > +struct spear13xx_cfg_priv {
> > + struct regmap *misc;
> > +};
> > +
> > +/* SATA device registration */
> > +static void spear1340_sata_miphy_init(struct spear13xx_cfg_priv *cfgpriv)
> > +{
> > + regmap_update_bits(cfgpriv->misc, SPEAR1340_PCIE_SATA_CFG,
> > + SPEAR1340_PCIE_SATA_CFG_MASK, SPEAR1340_SATA_CFG_VAL);
> > + regmap_update_bits(cfgpriv->misc, SPEAR1340_PCIE_MIPHY_CFG,
> > + SPEAR1340_PCIE_MIPHY_CFG_MASK,
> > + SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA_25M_CRYSTAL_CLK);
> > + /* Switch on sata power domain */
> > + regmap_update_bits(cfgpriv->misc, SPEAR1340_PCM_CFG,
> > + SPEAR1340_PCM_CFG_SATA_POWER_EN,
> > + SPEAR1340_PCM_CFG_SATA_POWER_EN);
> > + msleep(20);
> > + /* Disable PCIE SATA Controller reset */
> > + regmap_update_bits(cfgpriv->misc, SPEAR1340_PERIP1_SW_RST,
> > + SPEAR1340_PERIP1_SW_RST_SATA, 0);
> > + msleep(20);
> > +}
>
> Looking at the actual code now, this very much looks like it ought to
> be a "phy" driver and get put in drivers/phy/.
Actually these registers are part of common system configurations
register space (called as misc space) for SPEAr SOC. So we opted for
syscon framework.
PHY registers space starts from 0xEB800000, which can be
programmed for various phy specific functions like power management,
tx/rx settings, comparator settings etc. In most of the cases phy
works with default settings, however there are few exceptions for
which we will be adding a phy driver for further improvement of SPEAr
drivers.
Regards
Pratyush
>
> Please see the recent mailing list discussions about making the ahci
> driver more generic. Once you put this code in a proper phy driver,
> you should be able to avoid a lot of your workaround and just use
> the regular ahci-platform driver without any hand-crafted platform
> data callbacks.
>
> Arnd
^ permalink raw reply
* [PATCH V2 6/8] SPEAr13xx: Fix static mapping table
From: Pratyush Anand @ 2014-01-24 3:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401231312.15885.arnd@arndb.de>
On Thu, Jan 23, 2014 at 08:12:15PM +0800, Arnd Bergmann wrote:
> On Thursday 23 January 2014, Mohit Kumar wrote:
> > From: Pratyush Anand <pratyush.anand@st.com>
> >
> > SPEAr13xx was using virtual address space 0xFE000000 to map physical address
> > space 0xB3000000. pci_remap_io uses 0xFEE00000 as virtual address. So
> > change 0xFE000000 to 0xF9000000.
> >
> > Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> > Tested-by: Mohit Kumar <mohit.kumar@st.com>
> > Cc: Viresh Kumar <viresh.linux@gmail.com>
> > Cc: spear-devel at list.st.com
> > Cc: linux-arm-kernel at lists.infradead.org
> > Cc: Arnd Bergmann <arnd@arndb.de>
>
> Surely this is needed in backports, so please add stable at vger.kernel.org
> to the Cc list in the changeset text. Otherwise
While sending v3 of series will cc stable list.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks :)
Regards
Pratyush
^ permalink raw reply
* [PATCH V2 3/8] ahci: Add a driver_data field to struct ahci_platform_data
From: Pratyush Anand @ 2014-01-24 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123113644.GA28621@htj.dyndns.org>
On Thu, Jan 23, 2014 at 07:36:44PM +0800, Tejun Heo wrote:
> On Thu, Jan 23, 2014 at 04:02:43PM +0530, Mohit Kumar wrote:
> > diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
> > index 73a2500..76d35e8 100644
> > --- a/include/linux/ahci_platform.h
> > +++ b/include/linux/ahci_platform.h
> > @@ -28,6 +28,7 @@ struct ahci_platform_data {
> > const struct ata_port_info *ata_port_info;
> > unsigned int force_port_map;
> > unsigned int mask_port_map;
> > + void *driver_data;
>
> Please use private_data instead for consistency with other ata data
> structures.
Ok.. ll do that in V3.
Thanks for your review.
Regards
Pratyush
>
> Thanks.
>
> --
> tejun
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: Anson.Huang at freescale.com @ 2014-01-24 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYPMApJ_uwMYgfDEDVWfBZ5et0pt+JVJxg_t-gZMn4PJSg@mail.gmail.com>
It may be enough, but I am afraid that there is chance that the time_after function's actual delay is shorter than 60us, as the timeout is only one jiffy(10ms), if the jiffy update comes right between the timeout value initialization and the time_after, then the delay may be not enough, is there such possibility? Correct me if I am wrong.
Best Regards.
Anson huang ???
?
Freescale Semiconductor Shanghai
?????????192?A?2?
201203
Tel:021-28937058
>-----Original Message-----
>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>Sent: Friday, January 24, 2014 10:24 AM
>To: Huang Yongcai-B20788
>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>
>Does the time_after function inside the loop is not enough to handle the
>situation?
>
>On Thu, Jan 23, 2014 at 6:05 PM, Anson.Huang at freescale.com
><Anson.Huang@freescale.com> wrote:
>> Hi, Tobias
>> Yes, the root cause is the reschedule introduced by the usleep, for
>our internal release, we use busy loop for PLL wait lock, just removing the
>usleep is not good enough, as the PLL hardware may need about 60~90us to lock,
>during this period, there will be no clock output in PLL. So, we need to
>figure out a way to fix this issue, either using busy loop instead of usleep
>or access the ccm register to adjust ARM divider instead of calling clk APIs.
>>
>> Best Regards.
>> Anson huang ???
>>
>> Freescale Semiconductor Shanghai
>> ?????????192?A?2?
>> 201203
>> Tel:021-28937058
>>
>>
>>>-----Original Message-----
>>>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>>>Sent: Friday, January 24, 2014 4:17 AM
>>>To: Huang Yongcai-B20788
>>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>
>>>Hi Anson / Shawn,
>>>
>>>I compared the clk_pllv3_wait_lock to the clk_pllv3_wait_for_lock of
>>>Freescale alpha release. In alpha, the usleep_range did not exist. I
>>>tried removing it, build the kernel again and it works.
>>>I didn't get crashes anymore...
>>>
>>>Regards,
>>>
>>>john
>>>
>>>
>>>
>>>On Mon, Jan 20, 2014 at 1:03 AM, Anson.Huang at freescale.com
>>><Anson.Huang@freescale.com> wrote:
>>>> Hi, Tobias and Shawn
>>>> I debug into this issue today, the root cause is that we
>>>> have a
>>>usleep_range(50, 500); in arch/arm/mach-imx/clk-pllv3.c's
>>>clk_pllv3_wait_lock function, which will cause kernel schedule during
>>>cpufreq change, and the idle thread has another clk operation which
>>>will cause mutex nest, and it will try to wake up previous mutex hold by
>cpufreq change's pll1 clk_set_rate.
>>>> So, to fix this issue, we should not use any usleep in the
>>>> wait
>>>function of pllv3's code, or we should not call any clk API in the
>>>imx6sl_set_wait_clk function. What do you think?
>>>>
>>>> BTW, I found another issue, if EVK board boot up with
>>>> 396MHz, then
>>>the initialized clock parent status is wrong, as ARM is from PFD
>>>396MHz, I will generate another patch to fix that once I have bandwidth.
>>>>
>>>> Best Regards.
>>>> Anson huang ???
>>>>
>>>> Freescale Semiconductor Shanghai
>>>> ?????????192?A?2?
>>>> 201203
>>>> Tel:021-28937058
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Huang Yongcai-B20788
>>>>>Sent: Saturday, January 18, 2014 7:53 AM
>>>>>To: John Tobias
>>>>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>>>
>>>>>Hi, Tobias
>>>>> I will debug it next week and feedback to you. Thanks.
>>>>>
>>>>>Sent from Anson's iPhone
>>>>>
>>>>>> ? 2014?1?18??7:42?"John Tobias" <john.tobias.ph@gmail.com> ???
>>>>>>
>>>>>> Hi Anson,
>>>>>>
>>>>>> My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
>>>>>> Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
>>>>>> called in imx6sl_enter_wait.
>>>>>>
>>>>>> [ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from
>>>>>> [<80045650>]
>>>>>> (deactivate_task+0x30/0x34)
>>>>>> [ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
>>>>>> [<8050ac88>] (__schedule+0x318/0x58c) [ 288.185848] [<8050a970>]
>>>>>> (__schedule+0x0/0x58c) from [<8050af34>]
>>>>>> (schedule+0x38/0x88)
>>>>>> [ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
>>>>>> (schedule_preempt_disabled+0x10/0x14)
>>>>>> [ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14)
>>>>>> from [<8050bcd4>] (mutex_lock_nested+0x16c/0x334) [ 288.215850]
>>>>>> [<8050bb68>] (mutex_lock_nested+0x0/0x334) from [<8034763c>]
>>>>>> (clk_prepare_lock+0x90/0x104) [ 288.226041] [<803475ac>]
>>>>>> (clk_prepare_lock+0x0/0x104) from [<80349254>]
>>>>>> (clk_set_rate+0x1c/0xbc) [ 288.235535] r6:806fd360 r5:00000000
>>>>>> r4:bf817f80 r3:80713d80 [ 288.242679] [<80349238>]
>>>>>> (clk_set_rate+0x0/0xbc) from [<8001e574>]
>>>>>> (imx6sl_set_wait_clk+0x28/0x70)
>>>>>> [ 288.252354] r5:00000043 r4:00000001 [ 288.256585]
>>>>>> [<8001e54c>]
>>>>>> (imx6sl_set_wait_clk+0x0/0x70) from [<8001def4>]
>>>>>> (imx6sl_enter_wait+0x24/0x2c) [ 288.266684] r5:00000043
>>>>>> r4:00000001 [ 288.270949] [<8001ded0>]
>>>>>> (imx6sl_enter_wait+0x0/0x2c) from [<80317608>]
>>>>>> (cpuidle_enter_state+0x44/0xfc) [ 288.281051]
>>>>>> r4:13bf2645 r3:8001ded0 [ 288.285682] [<803175c4>]
>>>>>> (cpuidle_enter_state+0x0/0xfc) from [<803177bc>]
>>>>>> (cpuidle_idle_call+0xfc/0x150) [ 288.295871] r8:806e00d8
>>>>>> r7:00000001
>>>>>> r6:00000000 r5:80c58034 r4:806fd360 [ 288.304428] [<803176c0>]
>>>>>> (cpuidle_idle_call+0x0/0x150) from [<8000fa68>]
>>>>>> (arch_cpu_idle+0x10/0x44) [ 288.314108] r9:8070970a r8:8070970a
>>>>>> r7:806d2000 r6:806da0dc r5:806d2000
>>>>>> r4:806d2000
>>>>>> [ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from
>>>>>> [<800590f4>]
>>>>>> (cpu_startup_entry+0xe0/0x120)
>>>>>> [ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
>>>>>> [<80503c8c>] (rest_init+0xcc/0xdc) [ 288.342810] r7:ffffffff
>>>>>> r3:00000000 [ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from
>>>>>> [<806a2b00>]
>>>>>> (start_kernel+0x348/0x354)
>>>>>> [ 288.356099] r6:806da040 r5:806da040 r4:806da150 [ 288.361972]
>>>>>> [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
>>>>>> (0x80008070)
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> john
>>>>>>
>>>>>>
>>>
>>
>
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: John Tobias @ 2014-01-24 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3acb9ee4a574bbaa1cdc5fa77050408@BY2PR03MB315.namprd03.prod.outlook.com>
Does the time_after function inside the loop is not enough to handle
the situation?
On Thu, Jan 23, 2014 at 6:05 PM, Anson.Huang at freescale.com
<Anson.Huang@freescale.com> wrote:
> Hi, Tobias
> Yes, the root cause is the reschedule introduced by the usleep, for our internal release, we use busy loop for PLL wait lock, just removing the usleep is not good enough, as the PLL hardware may need about 60~90us to lock, during this period, there will be no clock output in PLL. So, we need to figure out a way to fix this issue, either using busy loop instead of usleep or access the ccm register to adjust ARM divider instead of calling clk APIs.
>
> Best Regards.
> Anson huang ???
>
> Freescale Semiconductor Shanghai
> ?????????192?A?2?
> 201203
> Tel:021-28937058
>
>
>>-----Original Message-----
>>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>>Sent: Friday, January 24, 2014 4:17 AM
>>To: Huang Yongcai-B20788
>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>
>>Hi Anson / Shawn,
>>
>>I compared the clk_pllv3_wait_lock to the clk_pllv3_wait_for_lock of Freescale
>>alpha release. In alpha, the usleep_range did not exist. I tried removing it,
>>build the kernel again and it works.
>>I didn't get crashes anymore...
>>
>>Regards,
>>
>>john
>>
>>
>>
>>On Mon, Jan 20, 2014 at 1:03 AM, Anson.Huang at freescale.com
>><Anson.Huang@freescale.com> wrote:
>>> Hi, Tobias and Shawn
>>> I debug into this issue today, the root cause is that we have a
>>usleep_range(50, 500); in arch/arm/mach-imx/clk-pllv3.c's clk_pllv3_wait_lock
>>function, which will cause kernel schedule during cpufreq change, and the idle
>>thread has another clk operation which will cause mutex nest, and it will try
>>to wake up previous mutex hold by cpufreq change's pll1 clk_set_rate.
>>> So, to fix this issue, we should not use any usleep in the wait
>>function of pllv3's code, or we should not call any clk API in the
>>imx6sl_set_wait_clk function. What do you think?
>>>
>>> BTW, I found another issue, if EVK board boot up with 396MHz, then
>>the initialized clock parent status is wrong, as ARM is from PFD 396MHz, I
>>will generate another patch to fix that once I have bandwidth.
>>>
>>> Best Regards.
>>> Anson huang ???
>>>
>>> Freescale Semiconductor Shanghai
>>> ?????????192?A?2?
>>> 201203
>>> Tel:021-28937058
>>>
>>>
>>>>-----Original Message-----
>>>>From: Huang Yongcai-B20788
>>>>Sent: Saturday, January 18, 2014 7:53 AM
>>>>To: John Tobias
>>>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>>
>>>>Hi, Tobias
>>>> I will debug it next week and feedback to you. Thanks.
>>>>
>>>>Sent from Anson's iPhone
>>>>
>>>>> ? 2014?1?18??7:42?"John Tobias" <john.tobias.ph@gmail.com> ???
>>>>>
>>>>> Hi Anson,
>>>>>
>>>>> My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
>>>>> Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
>>>>> called in imx6sl_enter_wait.
>>>>>
>>>>> [ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from
>>>>> [<80045650>]
>>>>> (deactivate_task+0x30/0x34)
>>>>> [ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
>>>>> [<8050ac88>] (__schedule+0x318/0x58c) [ 288.185848] [<8050a970>]
>>>>> (__schedule+0x0/0x58c) from [<8050af34>]
>>>>> (schedule+0x38/0x88)
>>>>> [ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
>>>>> (schedule_preempt_disabled+0x10/0x14)
>>>>> [ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14)
>>>>> from [<8050bcd4>] (mutex_lock_nested+0x16c/0x334) [ 288.215850]
>>>>> [<8050bb68>] (mutex_lock_nested+0x0/0x334) from [<8034763c>]
>>>>> (clk_prepare_lock+0x90/0x104) [ 288.226041] [<803475ac>]
>>>>> (clk_prepare_lock+0x0/0x104) from [<80349254>]
>>>>> (clk_set_rate+0x1c/0xbc) [ 288.235535] r6:806fd360 r5:00000000
>>>>> r4:bf817f80 r3:80713d80 [ 288.242679] [<80349238>]
>>>>> (clk_set_rate+0x0/0xbc) from [<8001e574>]
>>>>> (imx6sl_set_wait_clk+0x28/0x70)
>>>>> [ 288.252354] r5:00000043 r4:00000001 [ 288.256585] [<8001e54c>]
>>>>> (imx6sl_set_wait_clk+0x0/0x70) from [<8001def4>]
>>>>> (imx6sl_enter_wait+0x24/0x2c) [ 288.266684] r5:00000043
>>>>> r4:00000001 [ 288.270949] [<8001ded0>] (imx6sl_enter_wait+0x0/0x2c)
>>>>> from [<80317608>] (cpuidle_enter_state+0x44/0xfc) [ 288.281051]
>>>>> r4:13bf2645 r3:8001ded0 [ 288.285682] [<803175c4>]
>>>>> (cpuidle_enter_state+0x0/0xfc) from [<803177bc>]
>>>>> (cpuidle_idle_call+0xfc/0x150) [ 288.295871] r8:806e00d8
>>>>> r7:00000001
>>>>> r6:00000000 r5:80c58034 r4:806fd360 [ 288.304428] [<803176c0>]
>>>>> (cpuidle_idle_call+0x0/0x150) from [<8000fa68>]
>>>>> (arch_cpu_idle+0x10/0x44) [ 288.314108] r9:8070970a r8:8070970a
>>>>> r7:806d2000 r6:806da0dc r5:806d2000
>>>>> r4:806d2000
>>>>> [ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from
>>>>> [<800590f4>]
>>>>> (cpu_startup_entry+0xe0/0x120)
>>>>> [ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
>>>>> [<80503c8c>] (rest_init+0xcc/0xdc) [ 288.342810] r7:ffffffff
>>>>> r3:00000000 [ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from
>>>>> [<806a2b00>]
>>>>> (start_kernel+0x348/0x354)
>>>>> [ 288.356099] r6:806da040 r5:806da040 r4:806da150 [ 288.361972]
>>>>> [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
>>>>> (0x80008070)
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> john
>>>>>
>>>>>
>>
>
^ permalink raw reply
* [PATCH] ARM: moxart: DT fixups
From: Olof Johansson @ 2014-01-24 2:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390317973-24110-1-git-send-email-jonas.jensen@gmail.com>
On Tue, Jan 21, 2014 at 04:26:13PM +0100, Jonas Jensen wrote:
> Change DT files to remain coherent with changes in
> accompanying drivers.
>
> 1. replace "sdhci" with "mmc"
> 2. add bus-width property to mmc node
> 3. drop device_type property
> 4. replace "mac@" with "ethernet@"
> 5. replace CONFIG_MMC_SDHCI_MOXART with CONFIG_MMC_MOXART
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
> ---
>
> Notes:
> Applies on top of:
>
> "[PATCH] ARM: moxart: move fixed rate clock child node to board level dts"
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226141.html
>
> Applies to next-20140121
Since the prereqs for this patch are in different branches right now, I'll have
to apply it after the merges have been done by Linus. I'll include it in
a batch of fixes later on -- remind me if we forget.
-Olof
^ permalink raw reply
* [PATCH] ARM: moxart: move fixed rate clock child node to board level dts
From: Olof Johansson @ 2014-01-24 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389886746-972-1-git-send-email-jonas.jensen@gmail.com>
On Thu, Jan 16, 2014 at 04:39:06PM +0100, Jonas Jensen wrote:
> When a skeleton "clocks { .. }" remain in .dtsi, the child node can
> be moved to .dts, "ref12" is then found by of_clk_get().
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
Applied to late/misc branch, will likely be included in 3.14-rc1
-Olof
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: Anson.Huang at freescale.com @ 2014-01-24 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACUGKYOuuPzPHyUSm_zyq1iq1FeaCoQ03Ko4yO8mmM+PDGm5gw@mail.gmail.com>
Hi, Tobias
Yes, the root cause is the reschedule introduced by the usleep, for our internal release, we use busy loop for PLL wait lock, just removing the usleep is not good enough, as the PLL hardware may need about 60~90us to lock, during this period, there will be no clock output in PLL. So, we need to figure out a way to fix this issue, either using busy loop instead of usleep or access the ccm register to adjust ARM divider instead of calling clk APIs.
Best Regards.
Anson huang ???
?
Freescale Semiconductor Shanghai
?????????192?A?2?
201203
Tel:021-28937058
>-----Original Message-----
>From: John Tobias [mailto:john.tobias.ph at gmail.com]
>Sent: Friday, January 24, 2014 4:17 AM
>To: Huang Yongcai-B20788
>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>
>Hi Anson / Shawn,
>
>I compared the clk_pllv3_wait_lock to the clk_pllv3_wait_for_lock of Freescale
>alpha release. In alpha, the usleep_range did not exist. I tried removing it,
>build the kernel again and it works.
>I didn't get crashes anymore...
>
>Regards,
>
>john
>
>
>
>On Mon, Jan 20, 2014 at 1:03 AM, Anson.Huang at freescale.com
><Anson.Huang@freescale.com> wrote:
>> Hi, Tobias and Shawn
>> I debug into this issue today, the root cause is that we have a
>usleep_range(50, 500); in arch/arm/mach-imx/clk-pllv3.c's clk_pllv3_wait_lock
>function, which will cause kernel schedule during cpufreq change, and the idle
>thread has another clk operation which will cause mutex nest, and it will try
>to wake up previous mutex hold by cpufreq change's pll1 clk_set_rate.
>> So, to fix this issue, we should not use any usleep in the wait
>function of pllv3's code, or we should not call any clk API in the
>imx6sl_set_wait_clk function. What do you think?
>>
>> BTW, I found another issue, if EVK board boot up with 396MHz, then
>the initialized clock parent status is wrong, as ARM is from PFD 396MHz, I
>will generate another patch to fix that once I have bandwidth.
>>
>> Best Regards.
>> Anson huang ???
>>
>> Freescale Semiconductor Shanghai
>> ?????????192?A?2?
>> 201203
>> Tel:021-28937058
>>
>>
>>>-----Original Message-----
>>>From: Huang Yongcai-B20788
>>>Sent: Saturday, January 18, 2014 7:53 AM
>>>To: John Tobias
>>>Cc: <linux-arm-kernel@lists.infradead.org>; Shawn Guo
>>>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>>>
>>>Hi, Tobias
>>> I will debug it next week and feedback to you. Thanks.
>>>
>>>Sent from Anson's iPhone
>>>
>>>> ? 2014?1?18??7:42?"John Tobias" <john.tobias.ph@gmail.com> ???
>>>>
>>>> Hi Anson,
>>>>
>>>> My kernel for iMX6SL has a imx6q-cpufreq and I used your patch.
>>>> Unfortunately, the kernel crashes if the imx6sl_set_wait_clk being
>>>> called in imx6sl_enter_wait.
>>>>
>>>> [ 288.166905] [<80044b80>] (dequeue_task+0x0/0xc8) from
>>>> [<80045650>]
>>>> (deactivate_task+0x30/0x34)
>>>> [ 288.176403] [<80045620>] (deactivate_task+0x0/0x34) from
>>>> [<8050ac88>] (__schedule+0x318/0x58c) [ 288.185848] [<8050a970>]
>>>> (__schedule+0x0/0x58c) from [<8050af34>]
>>>> (schedule+0x38/0x88)
>>>> [ 288.194758] [<8050aefc>] (schedule+0x0/0x88) from [<8050b1c8>]
>>>> (schedule_preempt_disabled+0x10/0x14)
>>>> [ 288.204858] [<8050b1b8>] (schedule_preempt_disabled+0x0/0x14)
>>>> from [<8050bcd4>] (mutex_lock_nested+0x16c/0x334) [ 288.215850]
>>>> [<8050bb68>] (mutex_lock_nested+0x0/0x334) from [<8034763c>]
>>>> (clk_prepare_lock+0x90/0x104) [ 288.226041] [<803475ac>]
>>>> (clk_prepare_lock+0x0/0x104) from [<80349254>]
>>>> (clk_set_rate+0x1c/0xbc) [ 288.235535] r6:806fd360 r5:00000000
>>>> r4:bf817f80 r3:80713d80 [ 288.242679] [<80349238>]
>>>> (clk_set_rate+0x0/0xbc) from [<8001e574>]
>>>> (imx6sl_set_wait_clk+0x28/0x70)
>>>> [ 288.252354] r5:00000043 r4:00000001 [ 288.256585] [<8001e54c>]
>>>> (imx6sl_set_wait_clk+0x0/0x70) from [<8001def4>]
>>>> (imx6sl_enter_wait+0x24/0x2c) [ 288.266684] r5:00000043
>>>> r4:00000001 [ 288.270949] [<8001ded0>] (imx6sl_enter_wait+0x0/0x2c)
>>>> from [<80317608>] (cpuidle_enter_state+0x44/0xfc) [ 288.281051]
>>>> r4:13bf2645 r3:8001ded0 [ 288.285682] [<803175c4>]
>>>> (cpuidle_enter_state+0x0/0xfc) from [<803177bc>]
>>>> (cpuidle_idle_call+0xfc/0x150) [ 288.295871] r8:806e00d8
>>>> r7:00000001
>>>> r6:00000000 r5:80c58034 r4:806fd360 [ 288.304428] [<803176c0>]
>>>> (cpuidle_idle_call+0x0/0x150) from [<8000fa68>]
>>>> (arch_cpu_idle+0x10/0x44) [ 288.314108] r9:8070970a r8:8070970a
>>>> r7:806d2000 r6:806da0dc r5:806d2000
>>>> r4:806d2000
>>>> [ 288.323611] [<8000fa58>] (arch_cpu_idle+0x0/0x44) from
>>>> [<800590f4>]
>>>> (cpu_startup_entry+0xe0/0x120)
>>>> [ 288.333460] [<80059014>] (cpu_startup_entry+0x0/0x120) from
>>>> [<80503c8c>] (rest_init+0xcc/0xdc) [ 288.342810] r7:ffffffff
>>>> r3:00000000 [ 288.347115] [<80503bc0>] (rest_init+0x0/0xdc) from
>>>> [<806a2b00>]
>>>> (start_kernel+0x348/0x354)
>>>> [ 288.356099] r6:806da040 r5:806da040 r4:806da150 [ 288.361972]
>>>> [<806a27b8>] (start_kernel+0x0/0x354) from [<80008070>]
>>>> (0x80008070)
>>>>
>>>>
>>>> Regards,
>>>>
>>>> john
>>>>
>>>>
>
^ permalink raw reply
* Freescale FEC packet loss
From: fugang.duan at freescale.com @ 2014-01-24 1:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401231520.56990.marex@denx.de>
From: Marek Vasut <marex@denx.de>
Data: Thursday, January 23, 2014 10:21 PM
>To: Duan Fugang-B38611
>Cc: netdev at vger.kernel.org; Li Frank-B20596; Estevam Fabio-R49496; Hector
>Palacios; linux-arm-kernel at lists.infradead.org; Detlev Zundel; Eric Nelson
>Subject: Re: Freescale FEC packet loss
>
>On Thursday, January 23, 2014 at 02:49:48 AM, fugang.duan at freescale.com wrote:
>[...]
>
>> >[ 3] 71.0-72.0 sec 23.4 MBytes 196 Mbits/sec
>> >[ 3] 72.0-73.0 sec 12.2 MBytes 103 Mbits/sec
>> >[ 3] 73.0-74.0 sec 0.00 Bytes 0.00 bits/sec [ 3] 74.0-75.0 sec
>> >0.00 Bytes 0.00 bits/sec [ 3] 75.0-76.0 sec 10.9 MBytes 91.2 Mbits/sec
>> >[ 3] 76.0-77.0 sec 22.4 MBytes 188 Mbits/sec
>> >[ 3] 77.0-78.0 sec 23.0 MBytes 193 Mbits/sec
>>
>> I will debug the issue when I am free, and then report the result to you.
>> Thanks for your reporting the issue.
>
>Hi Andy,
>
>Thanks for looking into this. Is there any way I can help you with figuring out
>the issue ? Do you need any more feedback or anything please ?
>
No, the information is enough. Thanks for your testing.
Best Regards,
Andy
^ permalink raw reply
* [PATCH v3 2/2] i2c: New bus driver for the QUP I2C controller
From: Philip Elcan @ 2014-01-24 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389999819-10648-3-git-send-email-bjorn.andersson@sonymobile.com>
On 01/17/2014 06:03 PM, Bjorn Andersson wrote:
> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
>
> This bus driver supports the QUP i2c hardware controller in the Qualcomm
> MSM SOCs. The Qualcomm Universal Peripheral Engine (QUP) is a general
> purpose data path engine with input/output FIFOs and an embedded i2c
> mini-core. The driver supports FIFO mode (for low bandwidth applications)
> and block mode (interrupt generated for each block-size data transfer).
> The driver currently does not support DMA transfers.
>
> Shamelessly based on codeaurora version of the driver.
>
> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> [bjorn: updated to reflect i2c framework changes
> splited up qup_i2c_enable() in enable/disable
> don't overwrite ret value on error in xfer functions
> initilize core for each transfer
> remove explicit pinctrl selection
> use existing clock instead of setting new core clock]
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> ---
<snip>
> +
> + io_mode = readl(qup->base + QUP_IO_MODE);
> +
> + size = QUP_OUTPUT_BLOCK_SIZE(io_mode);
> + if (size)
> + qup->out_blk_sz = size * 16;
> + else
> + qup->out_blk_sz = 16;
> +
> + size = QUP_INPUT_BLOCK_SIZE(io_mode);
> + if (size)
> + qup->in_blk_sz = size * 16;
> + else
> + qup->in_blk_sz = 16;
> +
> + qup->xfer_time = msecs_to_jiffies(qup->out_fifo_sz);
qup->xfer_time should be set after you calculate qup->out_fifo_sz below.
> +
> + /*
> + * The block/fifo size w.r.t. 'actual data' is 1/2 due to 'tag'
> + * associated with each byte written/received
> + */
> + qup->out_blk_sz /= 2;
> + qup->in_blk_sz /= 2;
> +
> + size = QUP_OUTPUT_FIFO_SIZE(io_mode);
> + qup->out_fifo_sz = qup->out_blk_sz * (2 << size);
> +
> + size = QUP_INPUT_FIFO_SIZE(io_mode);
> + qup->in_fifo_sz = qup->in_blk_sz * (2 << size);
> +
> + /*
> + * Wait for FIFO number of bytes to be absolutely sure
> + * that I2C write state machine is not idle. Each byte
> + * takes 9 clock cycles. (8 bits + 1 ack)
> + */
> + qup->wait_idle = qup->one_bit_t * 9;
> + qup->wait_idle *= qup->out_fifo_sz;
> +
> + dev_info(qup->dev, "IN:block:%d, fifo:%d, OUT:block:%d, fifo:%d\n",
> + qup->in_blk_sz, qup->in_fifo_sz,
> + qup->out_blk_sz, qup->out_fifo_sz);
> +
> + i2c_set_adapdata(&qup->adap, qup);
> + qup->adap.algo = &qup_i2c_algo;
> + qup->adap.nr = pdev->id;
> + qup->adap.dev.parent = qup->dev;
> + qup->adap.dev.of_node = pdev->dev.of_node;
> + strlcpy(qup->adap.name, "QUP I2C adapter", sizeof(qup->adap.name));
> +
> + ret = i2c_add_numbered_adapter(&qup->adap);
> + if (!ret) {
> + pm_runtime_set_autosuspend_delay(qup->dev, MSEC_PER_SEC);
> + pm_runtime_use_autosuspend(qup->dev);
> + pm_runtime_enable(qup->dev);
> + return 0;
> + }
> +fail:
> + qup_i2c_disable_clocks(qup);
> + return ret;
> +}
> +
> +static int qup_i2c_remove(struct platform_device *pdev)
> +{
> + struct qup_i2c_dev *qup = platform_get_drvdata(pdev);
> +
> + disable_irq(qup->irq);
> + qup_i2c_disable_clocks(qup);
> + i2c_del_adapter(&qup->adap);
> + pm_runtime_disable(qup->dev);
> + pm_runtime_set_suspended(qup->dev);
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int qup_i2c_pm_suspend_runtime(struct device *device)
> +{
> + struct qup_i2c_dev *qup = dev_get_drvdata(device);
> +
> + dev_dbg(device, "pm_runtime: suspending...\n");
> + qup_i2c_disable_clocks(qup);
> + return 0;
> +}
> +
> +static int qup_i2c_pm_resume_runtime(struct device *device)
> +{
> + struct qup_i2c_dev *qup = dev_get_drvdata(device);
> +
> + dev_dbg(device, "pm_runtime: resuming...\n");
> + qup_i2c_enable_clocks(qup);
> + return 0;
> +}
> +#endif
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int qup_i2c_suspend(struct device *device)
> +{
> + dev_dbg(device, "system suspend");
> + qup_i2c_pm_suspend_runtime(device);
> + return 0;
> +}
> +
> +static int qup_i2c_resume(struct device *device)
> +{
> + dev_dbg(device, "system resume");
> + qup_i2c_pm_resume_runtime(device);
> + pm_runtime_mark_last_busy(device);
> + pm_request_autosuspend(device);
> + return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops qup_i2c_qup_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(
> + qup_i2c_suspend,
> + qup_i2c_resume)
> + SET_RUNTIME_PM_OPS(
> + qup_i2c_pm_suspend_runtime,
> + qup_i2c_pm_resume_runtime,
> + NULL)
> +};
> +
> +static const struct of_device_id qup_i2c_dt_match[] = {
> + {.compatible = "qcom,i2c-qup"},
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, qup_i2c_dt_match);
> +
> +static struct platform_driver qup_i2c_driver = {
> + .probe = qup_i2c_probe,
> + .remove = qup_i2c_remove,
> + .driver = {
> + .name = "i2c_qup",
> + .owner = THIS_MODULE,
> + .pm = &qup_i2c_qup_pm_ops,
> + .of_match_table = qup_i2c_dt_match,
> + },
> +};
> +
> +module_platform_driver(qup_i2c_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:i2c_qup");
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] ARM: shmobile: r8a7790.dtsi: ficx i2c[0-3] clock reference
From: Simon Horman @ 2014-01-24 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390525593.git.horms+renesas@verge.net.au>
From: Ben Dooks <ben.dooks@codethink.co.uk>
The R8A7790's dtsi file i2c0, i2c1, i2c2, and i2c3 nodes have clock
references to the mstp3_clks clock node, however these clocks are in the
mstp9_clks node.
The error was introducted in 72197ca7a1cb1cea5 ("ARM: shmobile: r8a7790:
Reference clocks") which is in Simon's current development tree.
This patch fixes the following error:
of_clk_src_onecell_get: invalid clock index 31
i2c-rcar e6508000.i2c: cannot get clock
i2c-rcar: probe of e6508000.i2c failed with error -2
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7790.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index a179125..46ac214 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -197,7 +197,7 @@
reg = <0 0xe6508000 0 0x40>;
interrupt-parent = <&gic>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp3_clks R8A7790_CLK_I2C0>;
+ clocks = <&mstp9_clks R8A7790_CLK_I2C0>;
status = "disabled";
};
@@ -208,7 +208,7 @@
reg = <0 0xe6518000 0 0x40>;
interrupt-parent = <&gic>;
interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp3_clks R8A7790_CLK_I2C1>;
+ clocks = <&mstp9_clks R8A7790_CLK_I2C1>;
status = "disabled";
};
@@ -219,7 +219,7 @@
reg = <0 0xe6530000 0 0x40>;
interrupt-parent = <&gic>;
interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp3_clks R8A7790_CLK_I2C2>;
+ clocks = <&mstp9_clks R8A7790_CLK_I2C2>;
status = "disabled";
};
@@ -230,7 +230,7 @@
reg = <0 0xe6540000 0 0x40>;
interrupt-parent = <&gic>;
interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&mstp3_clks R8A7790_CLK_I2C3>;
+ clocks = <&mstp9_clks R8A7790_CLK_I2C3>;
status = "disabled";
};
--
1.8.4
^ permalink raw reply related
* [GIT PULL] Second Round of Renesas ARM Based SoC DT Fixes for v3.14
From: Simon Horman @ 2014-01-24 1:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Kevin, Hi Arnd,
please consider this second round of renesas ARM Based SoC DT fixes for v3.14.
This pull-request is based on the first round of such fixes,
tagged as renesas-dt-fixes-for-v3.14, which you have previously pulled.
The following changes since commit 3effae8c26f451a9d572255c08dfbe342dd1dc98:
Revert "ARM: shmobile: r8a7791: Add SSI clocks in device tree" (2013-12-26 14:16:54 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-fixes2-for-v3.14
for you to fetch changes up to 2450badfc19b67340d3570665cc02a22df03dfab:
ARM: shmobile: r8a7790.dtsi: ficx i2c[0-3] clock reference (2014-01-21 09:45:50 +0900)
----------------------------------------------------------------
Second Round of Renesas ARM Based SoC DT Fixes for v3.14
Correct i2c clock references for r8a7790 (R-Car H2) SoC
The error was introduced in 72197ca7a1cb1cea5 ("ARM: shmobile: r8a7790:
Reference clocks") which is queued up for v3.14.
----------------------------------------------------------------
Ben Dooks (1):
ARM: shmobile: r8a7790.dtsi: ficx i2c[0-3] clock reference
arch/arm/boot/dts/r8a7790.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Hanjun Guo @ 2014-01-24 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122114616.GB15591@e106331-lin.cambridge.arm.com>
On 2014?01?22? 19:46, Mark Rutland wrote:
> On Mon, Jan 20, 2014 at 09:08:32AM +0000, Hanjun Guo wrote:
>> On 2014-1-17 22:21, Arnd Bergmann wrote:
>>> On Friday 17 January 2014, Hanjun Guo wrote:
>>>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>>>
>>>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
>>>> name from the ACPI timer table is matched with all the registered
>>>> timer controllers and matching initialisation routine is invoked.
>>> I wouldn't anticipate this infrastructure to be required. Shouldn't all
>>> ARMv8 machines have an architected timer?
>> I not sure of this, could anyone can give some guidance? if only arch
>> timer is available for ARM64, this will make thing very simple.
> All ARMv8 systems should have an architected timer.
Thanks for the clarification :)
>
> However, they may also have other timers (e.g. global timers for use
> when CPUs are in low power states and their local architected timers
> aren't active).
Only arch timer (generic timer) is defined as a table in ACPI 5.0
spec at now, so other timers will not described as table and will
described as device object in DSDT table, so do you think we need
this framework or not?
Thanks
Hanjun
^ permalink raw reply
* [PATCH] ARM: multi_v7: copy most options from tegra_defconfig
From: Olof Johansson @ 2014-01-24 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjwDg0TzhEGi-sZhtngXPbg=5u54ew6USpq3P7J9QQWjg@mail.gmail.com>
On Thu, Jan 23, 2014 at 4:20 PM, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Jan 23, 2014 at 4:16 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 12/23/2013 10:37 AM, Olof Johansson wrote:
>>> On Sun, Dec 22, 2013 at 12:05 PM, Olof Johansson <olof@lixom.net> wrote:
>>>> On Fri, Dec 20, 2013 at 01:26:17PM -0700, Stephen Warren wrote:
>>>>> On 12/20/2013 01:16 PM, Olof Johansson wrote:
>>>>>> On Fri, Dec 20, 2013 at 12:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>>> multi_v7_defconfig was missing a large number of options that were in
>>>>>> tegra_defconfig. This patch adds them. The changes fall into the
>>>>>> following categories:
>> ...
>>>> Ok, fair enough. Applied.
>>>
>>> Actually, this one ended up getting messy. We've had
>>> multi_v7_defconfig updates in several branches so this doesn't apply
>>> cleanly anywhere.
>>>
>>> I'll apply it on top of for-next where the various branches are
>>> merged. It means we'll have to merge it late. Not a big deal, but
>>> please help me remember it in case it for some reason gets lost in the
>>> shuffle.
>>
>> I guess this is the correct time to remind you about this? That said,
>> the patch is in linux-next, so perhaps that counts as not having been
>> lost:-)
(Gah, fumbled the send button).
Yeah, i'm aware of this one, we'll include it with the late/* branches
once Linus merges our initial set of stuff.
-Olof
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Hanjun Guo @ 2014-01-24 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122114537.GA15591@e106331-lin.cambridge.arm.com>
On 2014?01?22? 19:45, Mark Rutland wrote:
> On Wed, Jan 22, 2014 at 08:26:50AM +0000, Linus Walleij wrote:
>> On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>
>>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>>
>>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
>>> name from the ACPI timer table is matched with all the registered
>>> timer controllers and matching initialisation routine is invoked.
>>>
>>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
>> to TIMER_OF_DECLARE() and I think this macro, if needed, should
>> be named TIMER_ACPI_DECLARE().
>>
>> The reason is that "clocksource" is a Linux-internal name and this
>> macro pertains to the hardware name in respective system
>> description type.
>>
>>> +#ifdef CONFIG_ACPI
>>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
>>> + static const struct acpi_device_id __clksrc_acpi_table_##name \
>>> + __used __section(__clksrc_acpi_table) \
>>> + = { .id = compat, \
>>> + .driver_data = (kernel_ulong_t)fn }
>>> +#else
>>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
>>> +#endif
>> This hammers down the world to compile one binary for ACPI
>> and one binary for device tree. Maybe that's fine, I don't know.
> How does it do that?
>
> As far as I could tell CONFIG_ACPI and CONFIG_OF are not mutually
> exclusive, and this just means that we only build the datastructures for
> matching from ACPI when CONFIG_ACPI is enabled.
>
> Have I missed something?
>
> I definitely don't want to see mutually exclusive ACPI and DT support.
ACPI and DT did the same job so I think they should mutually exclusive.
if we enable both DT and ACPI in one system, this will leading confusions.
Further more, firmware guys will be happy to present all the devices
in one way, not both of them.
Thanks
Hanjun
^ permalink raw reply
* [PATCH] ARM: multi_v7: copy most options from tegra_defconfig
From: Olof Johansson @ 2014-01-24 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E1B0EE.6080808@wwwdotorg.org>
On Thu, Jan 23, 2014 at 4:16 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 12/23/2013 10:37 AM, Olof Johansson wrote:
>> On Sun, Dec 22, 2013 at 12:05 PM, Olof Johansson <olof@lixom.net> wrote:
>>> On Fri, Dec 20, 2013 at 01:26:17PM -0700, Stephen Warren wrote:
>>>> On 12/20/2013 01:16 PM, Olof Johansson wrote:
>>>>> On Fri, Dec 20, 2013 at 12:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>> multi_v7_defconfig was missing a large number of options that were in
>>>>> tegra_defconfig. This patch adds them. The changes fall into the
>>>>> following categories:
> ...
>>> Ok, fair enough. Applied.
>>
>> Actually, this one ended up getting messy. We've had
>> multi_v7_defconfig updates in several branches so this doesn't apply
>> cleanly anywhere.
>>
>> I'll apply it on top of for-next where the various branches are
>> merged. It means we'll have to merge it late. Not a big deal, but
>> please help me remember it in case it for some reason gets lost in the
>> shuffle.
>
> I guess this is the correct time to remind you about this? That said,
> the patch is in linux-next, so perhaps that counts as not having been
> lost:-)
^ permalink raw reply
* [PATCH] ARM: multi_v7: copy most options from tegra_defconfig
From: Stephen Warren @ 2014-01-24 0:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMj-nvMZhoX4fCe-mf0pBS27=EsS0o2bX7MgmZzjWhYVzQ@mail.gmail.com>
On 12/23/2013 10:37 AM, Olof Johansson wrote:
> On Sun, Dec 22, 2013 at 12:05 PM, Olof Johansson <olof@lixom.net> wrote:
>> On Fri, Dec 20, 2013 at 01:26:17PM -0700, Stephen Warren wrote:
>>> On 12/20/2013 01:16 PM, Olof Johansson wrote:
>>>> On Fri, Dec 20, 2013 at 12:04 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> multi_v7_defconfig was missing a large number of options that were in
>>>> tegra_defconfig. This patch adds them. The changes fall into the
>>>> following categories:
...
>> Ok, fair enough. Applied.
>
> Actually, this one ended up getting messy. We've had
> multi_v7_defconfig updates in several branches so this doesn't apply
> cleanly anywhere.
>
> I'll apply it on top of for-next where the various branches are
> merged. It means we'll have to merge it late. Not a big deal, but
> please help me remember it in case it for some reason gets lost in the
> shuffle.
I guess this is the correct time to remind you about this? That said,
the patch is in linux-next, so perhaps that counts as not having been
lost:-)
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Hanjun Guo @ 2014-01-24 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYKwaH5DX27irzmcTDAMhQMUhuzz6N7mjKWv9tZchv0Ug@mail.gmail.com>
Hi Linus,
Sorry for the late reply.
On 2014?01?22? 16:26, Linus Walleij wrote:
> On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>
>> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
>>
>> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
>> name from the ACPI timer table is matched with all the registered
>> timer controllers and matching initialisation routine is invoked.
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
> to TIMER_OF_DECLARE() and I think this macro, if needed, should
> be named TIMER_ACPI_DECLARE().
>
> The reason is that "clocksource" is a Linux-internal name and this
> macro pertains to the hardware name in respective system
> description type.
That make sense to me too, I will update in next version if
this patch is still needed.
>
>> +#ifdef CONFIG_ACPI
>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
>> + static const struct acpi_device_id __clksrc_acpi_table_##name \
>> + __used __section(__clksrc_acpi_table) \
>> + = { .id = compat, \
>> + .driver_data = (kernel_ulong_t)fn }
>> +#else
>> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
>> +#endif
> This hammers down the world to compile one binary for ACPI
> and one binary for device tree. Maybe that's fine, I don't know.
This is a problem we can have some discussion on it.
I prefer mutually exclusive ACPI and DT support.
Thanks
Hanjun
^ 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