* [GIT PULL 4/8] ARM: tegra: cpuidle enhancements
From: Stephen Warren @ 2013-01-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359582159-28816-1-git-send-email-swarren@wwwdotorg.org>
This pull request implements a new "LP2" cpuidle state for Tegra20,
which makes use of the couple cpuidle feature.
It is based on (most of) the previous pull request, with tag
tegra-for-3.9-soc-usb.
----------------------------------------------------------------
The following changes since commit 9304512151b0933c454f0842cdb19bec23422bc5:
usb: host: tegra: don't touch EMC clock
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.9-soc-cpuidle
for you to fetch changes up to 1d328606c66b9bb1c0552f585943d596f37ae3b9:
ARM: tegra20: cpuidle: apply coupled cpuidle for powered-down mode
----------------------------------------------------------------
Joseph Lo (5):
ARM: tegra: add pending SGI checking API
ARM: tegra20: cpuidle: add powered-down state for secondary CPU
clk: tegra20: Implementing CPU low-power function for tegra_cpu_car_ops
ARM: tegra20: flowctrl: add support for cpu_suspend_enter/exit
ARM: tegra20: cpuidle: apply coupled cpuidle for powered-down mode
arch/arm/mach-tegra/Kconfig | 1 +
arch/arm/mach-tegra/cpuidle-tegra20.c | 197 ++++++++++++++++++++++++++-
arch/arm/mach-tegra/flowctrl.c | 38 +++++-
arch/arm/mach-tegra/flowctrl.h | 4 +
arch/arm/mach-tegra/irq.c | 15 +++
arch/arm/mach-tegra/irq.h | 22 +++
arch/arm/mach-tegra/pm.c | 3 +
arch/arm/mach-tegra/sleep-tegra20.S | 200 ++++++++++++++++++++++++++++
arch/arm/mach-tegra/sleep.S | 19 +++
arch/arm/mach-tegra/sleep.h | 26 ++++
drivers/clk/tegra/clk-tegra20.c | 93 +++++++++++++
11 files changed, 609 insertions(+), 9 deletions(-)
create mode 100644 arch/arm/mach-tegra/irq.h
^ permalink raw reply
* [GIT PULL 5/8] ARM: tegra: SCU base rework
From: Stephen Warren @ 2013-01-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359582159-28816-1-git-send-email-swarren@wwwdotorg.org>
Tegra currently relies on the SCU to determine the number of CPU
cores, and also hard-codes the SCU physical address.
This series adds a /cpus node to the Tegra device tree, and updates
the code to rely solely on that to determine the CPU count. A new
API is introduced to query for the existence of SCU registers, and the
SCU register address. Tegra and OMAP2 are converted to use these new
APIs.
This pull request is based on a merge of v3.8-rc3, and arm-soc's
depends/rmk-perf branch.
----------------------------------------------------------------
The following changes since commit 5681f76576af872ced97e8c58ccab3c84a6627e6:
Merge remote-tracking branch 'korg_arm-soc/depends/rmk-perf' into for-3.9/scu-base-rework
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.9-scu-base-rework
for you to fetch changes up to 80d9375617f7544f7475e7f07003a08930559d43:
ARM: OMAP: Make use of available scu_a9_get_base() interface
----------------------------------------------------------------
Hiroshi Doyu (5):
ARM: tegra: Add CPU nodes to Tegra20 device tree
ARM: tegra: Add CPU nodes to Tegra30 device tree
ARM: tegra: Use DT /cpu node to detect number of CPU core
ARM: Add API to detect SCU base address from CP15
ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9
Santosh Shilimkar (1):
ARM: OMAP: Make use of available scu_a9_get_base() interface
arch/arm/boot/dts/tegra20.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/tegra30.dtsi | 29 +++++++++++++++++++++++++++++
arch/arm/include/asm/smp_scu.h | 17 +++++++++++++++++
arch/arm/mach-omap2/omap-smp.c | 2 +-
arch/arm/mach-omap2/omap44xx.h | 1 -
arch/arm/mach-tegra/platsmp.c | 20 ++------------------
6 files changed, 66 insertions(+), 20 deletions(-)
^ permalink raw reply
* [GIT PULL 6/8] ARM: tegra: add Tegra114 SoC support
From: Stephen Warren @ 2013-01-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359582159-28816-1-git-send-email-swarren@wwwdotorg.org>
This pull request adds initial support for the Tegra114 SoC, which
integrates a quad-core ARM Cortex-A15 CPU. I'm proud to observe that we
posted the initial versions of these patches before the final official
announcement of this chip.
These patches are enough to boot with a UART-based console, support the
Dalmore and Pluto reference/evaluation boards, instantiate the GPIO and
pinctrl drivers, and enable a cpuidle state. As yet, no clocks or
storage devices are supported, but patches for those will follow shortly.
This pull request is based on (most of) the previous pull request with
tag tegra-for-3.9-soc-cpuidle, followed by a merge of the previous pull
request with tag tegra-for-3.9-scu-base-rework.
----------------------------------------------------------------
The following changes since commit ee059485175b21079d3639f167980d354afb3d4b:
Merge branch 'for-3.9/scu-base-rework' into for-3.9/soc-t114
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.9-soc-t114
for you to fetch changes up to 031b77afc374cf1b86dbcda5dfa6e1bbb989836c:
ARM: DT: tegra114: add pinmux DT entry
----------------------------------------------------------------
Hiroshi Doyu (7):
ARM: tegra: fuse: Add chip ID Tegra114 0x35
ARM: dt: tegra114: Add new SoC base, Tegra114 SoC
ARM: dt: tegra114: Add new board, Dalmore
ARM: dt: tegra114: Add new board, Pluto
ARM: tegra: Add initial support for Tegra114 SoC.
ARM: tegra: add AHB entry to Tegra114 DT
ARM: tegra: Add SMMU entry to Tegra114 DT
Joseph Lo (1):
ARM: tegra: add Tegra114 ARM_CPUIDLE_WFI_STATE support
Laxman Dewangan (3):
ARM: tegra114: select PINCTRL for Tegra114 SoC
ARM: DT: tegra114: add GPIO DT entry
ARM: DT: tegra114: add pinmux DT entry
arch/arm/boot/dts/Makefile | 4 +-
arch/arm/boot/dts/tegra114-dalmore.dts | 21 ++++
arch/arm/boot/dts/tegra114-pluto.dts | 21 ++++
arch/arm/boot/dts/tegra114.dtsi | 153 ++++++++++++++++++++++++++
arch/arm/mach-tegra/Kconfig | 12 ++
arch/arm/mach-tegra/Makefile | 4 +
arch/arm/mach-tegra/board-dt-tegra114.c | 48 ++++++++
arch/arm/mach-tegra/common.c | 1 +
arch/arm/mach-tegra/cpuidle-tegra114.c | 61 ++++++++++
arch/arm/mach-tegra/cpuidle.c | 3 +
arch/arm/mach-tegra/cpuidle.h | 6 +
arch/arm/mach-tegra/fuse.h | 1 +
12 files changed, 334 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/tegra114-dalmore.dts
create mode 100644 arch/arm/boot/dts/tegra114-pluto.dts
create mode 100644 arch/arm/boot/dts/tegra114.dtsi
create mode 100644 arch/arm/mach-tegra/board-dt-tegra114.c
create mode 100644 arch/arm/mach-tegra/cpuidle-tegra114.c
^ permalink raw reply
* [GIT PULL 7/8] ARM: tegra: device tree updates
From: Stephen Warren @ 2013-01-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359582159-28816-1-git-send-email-swarren@wwwdotorg.org>
Numerous updates to the various Tegra device trees are made:
* Addition of NVIDIA Beaver (Tegra30) and Toradex Colibri T20 and Iris
carrier boards.
* Enablement of the HDMI connector on most boards.
* Enablement of the keyboard controller on a few boards.
* Addition of the AC'97 controller to Tegra20.
* Addition of a GPIO poweroff node for TrimSlice.
* Changes to support the new "high speed UART" (DMA-capable) driver for
Tegra serial ports, and enablement for Cardhu's UART C.
* A few cleanups, such as compatible flag fixes, node renames, node
ordering fixes, commonizing properties into SoC .dtsi files, etc..
This pull request is based on (most of) the previous pull request with
tag tegra-for-3.9-soc-t114.
----------------------------------------------------------------
The following changes since commit 5c541b884c09559723f426af2391ab07a4ca10e0:
ARM: tegra: Add initial support for Tegra114 SoC.
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.9-dt
for you to fetch changes up to 3fbf07d80b40f73c304624179381f9038bd03b74:
ARM: dt: tegra30: Rename "smmu" to "iommu"
----------------------------------------------------------------
Bryan Wu (3):
ARM: DT: tegra: Unify the description of Tegra20 boards
ARM: DT: tegra: Add board level compatible properties
ARM: DT: tegra: Add Tegra30 Beaver board support
Hiroshi Doyu (2):
ARM: dt: tegra20: Rename "gart" to "iommu"
ARM: dt: tegra30: Rename "smmu" to "iommu"
Laxman Dewangan (7):
ARM: tegra30: tegra30 gpio is not compatible with tegra20 gpio
ARM: tegra: dts: add aliases and DMA requestor for serial controller
ARM: tegra: add DT entry for KBC controller
ARM: tegra: seaboard: enable keyboard in DT
ARM: tegra: cardhu: register UARTC
ARM: tegra: whistler: enable keyboard in DT
ARM: tegra: harmony: enable keyboard in DT
Lucas Stach (4):
ASoC: tegra: add ac97 host controller to device tree
ARM: tegra: move serial clock-frequency attr into the Tegra20 dtsi
ARM: tegra: Add Colibri T20 512MB COM device tree
ARM: tegra: Add Toradex Iris carrier board DT with T20 512MB COM
Stephen Warren (6):
ARM: tegra: trimslice: add gpio-poweroff node to DT
ARM: tegra: seaboard: enable HDMI port
ARM: tegra: ventana: enable HDMI port
ARM: tegra: paz00: enable HDMI port
ARM: tegra: swap cache-/interrupt-ctrlr nodes in DT
ARM: tegra: move serial clock-frequency attr into the Tegra30 dtsi
Documentation/devicetree/bindings/arm/tegra.txt | 32 +-
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/tegra20-colibri-512.dtsi | 491 ++++++++++++++++++
arch/arm/boot/dts/tegra20-harmony.dts | 120 ++++-
arch/arm/boot/dts/tegra20-iris-512.dts | 89 ++++
arch/arm/boot/dts/tegra20-paz00.dts | 22 +-
arch/arm/boot/dts/tegra20-seaboard.dts | 158 +++++-
arch/arm/boot/dts/tegra20-tamonten.dtsi | 1 -
arch/arm/boot/dts/tegra20-trimslice.dts | 11 +-
arch/arm/boot/dts/tegra20-ventana.dts | 23 +-
arch/arm/boot/dts/tegra20-whistler.dts | 15 +-
arch/arm/boot/dts/tegra20.dtsi | 72 ++-
arch/arm/boot/dts/tegra30-beaver.dts | 373 +++++++++++++
arch/arm/boot/dts/tegra30-cardhu.dtsi | 15 +-
arch/arm/boot/dts/tegra30.dtsi | 66 ++-
15 files changed, 1430 insertions(+), 60 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra20-colibri-512.dtsi
create mode 100644 arch/arm/boot/dts/tegra20-iris-512.dts
create mode 100644 arch/arm/boot/dts/tegra30-beaver.dts
^ permalink raw reply
* [GIT PULL 8/8] ARM: tegra: defconfig update
From: Stephen Warren @ 2013-01-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359582159-28816-1-git-send-email-swarren@wwwdotorg.org>
Various new features are enabled on Tegra:
* RTC_DRV_TPS6586X to enable the RTC on many boards, such as Harmony
and Ventana.
* POWER_RESET_GPIO to provide a power off driver for TrimSlice.
* Tegra KBC controller support, for Seaboard, Harmony, and Whistler.
* Tegra high-speed UART driver, for Cardhu Bluetooth.
* kexec support.
This pull request is based on v3.8-rc3.
----------------------------------------------------------------
The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
Linux 3.8-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.9-defconfig
for you to fetch changes up to a05b0d505e76161b485db360f5eac5436e2fc2c6:
ARM: tegra: defconfig updates
----------------------------------------------------------------
Laxman Dewangan (1):
ARM: tegra: defconfig updates
arch/arm/configs/tegra_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
^ permalink raw reply
* [PATCH] ARM:mach-msm: seting tail NUL after strncpy
From: Stephen Boyd @ 2013-01-30 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ya4nhywe2o.fsf@huya.qualcomm.com>
On 01/30/13 13:33, David Brown wrote:
> Chen Gang <gang.chen@asianux.com> writes:
>
>> temp need NUL terminated, or next ptr may cause issue.
>>
>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>> ---
>> arch/arm/mach-msm/clock-debug.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-msm/clock-debug.c
>> b/arch/arm/mach-msm/clock-debug.c
>> index 4886404..bdca900 100644
>> --- a/arch/arm/mach-msm/clock-debug.c
>> +++ b/arch/arm/mach-msm/clock-debug.c
>> @@ -105,6 +105,8 @@ int __init clock_debug_add(struct clk *clock)
>> return -ENOMEM;
>>
>> strncpy(temp, clock->dbg_name, ARRAY_SIZE(temp)-1);
>> + temp[ARRAY_SIZE(temp)-1] = '\0';
>> +
>> for (ptr = temp; *ptr; ptr++)
> I believe that Stephen Boyd is putting some significant work into this
> code. Stephen, can you see if this bug is still in your current
> version of the code, and make sure that it is fixed there?
>
This entire file is deleted in my set of patches that moves the current
MSM clock code to the common clock framework.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation
From: Francois Romieu @ 2013-01-30 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359572855-12344-2-git-send-email-mugunthanvnm@ti.com>
Mugunthan V N <mugunthanvnm@ti.com> :
[...]
> diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
> index 0e9ccc2..18b88ce 100644
> --- a/drivers/net/ethernet/ti/cpsw_ale.c
> +++ b/drivers/net/ethernet/ti/cpsw_ale.c
[...]
> @@ -274,19 +292,26 @@ int cpsw_ale_flush(struct cpsw_ale *ale, int port_mask)
> return 0;
> }
>
> -int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port, int flags)
> +int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port,
> + int flags, u16 vid)
> {
> u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
> int idx;
>
> - cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
> + if (flags & ALE_VLAN) {
> + cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN_ADDR);
> + cpsw_ale_set_vlan_id(ale_entry, vid);
> + } else {
> + cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
> + }
> +
[...]
> + if (flags & ALE_VLAN) {
> + cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN_ADDR);
> + cpsw_ale_set_vlan_id(ale_entry, vid);
> + } else {
> + cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
> + }
> +
It could be fctored out.
[...]
> @@ -362,6 +395,55 @@ int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask)
> return 0;
> }
>
> +int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
> + int reg_mcast, int unreg_mcast)
> +{
[...]
> +int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port_mask)
[...]
Patch #2 doesn't use the returned status code.
--
Ueimor
^ permalink raw reply
* [PATCH v2 2/2] drivers: net:ethernet: cpsw: add support for VLAN
From: Francois Romieu @ 2013-01-30 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359572855-12344-3-git-send-email-mugunthanvnm@ti.com>
Mugunthan V N <mugunthanvnm@ti.com> :
[...]
> diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
> index 6ddd028..99696bf 100644
> --- a/Documentation/devicetree/bindings/net/cpsw.txt
> +++ b/Documentation/devicetree/bindings/net/cpsw.txt
> @@ -24,6 +24,8 @@ Required properties:
> Optional properties:
> - ti,hwmods : Must be "cpgmac0"
> - no_bd_ram : Must be 0 or 1
> +- default_vlan : Specifies Default VLAN for non tagged packets
> + ALE processing
Isn't it a device-tree hack for what should belong to a common API ?
[...]
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index a40750e..6c66f01 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
[...]
> @@ -607,14 +611,41 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
> }
> }
>
> +static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
> +{
> + writel(priv->data.default_vlan, &priv->host_port_regs->port_vlan);
> + if (priv->version == CPSW_VERSION_1) {
> + slave_write(&priv->slaves[0], priv->data.default_vlan,
> + CPSW1_PORT_VLAN);
> + slave_write(&priv->slaves[1], priv->data.default_vlan,
> + CPSW1_PORT_VLAN);
> + } else {
> + slave_write(&priv->slaves[0], priv->data.default_vlan,
> + CPSW2_PORT_VLAN);
> + slave_write(&priv->slaves[1], priv->data.default_vlan,
> + CPSW2_PORT_VLAN);
> + }
> + cpsw_ale_add_vlan(priv->ale, priv->data.default_vlan,
> + ALE_ALL_PORTS << priv->host_port,
> + ALE_ALL_PORTS << priv->host_port,
> + ALE_ALL_PORTS << priv->host_port,
> + (BIT(1) | BIT(2)) << priv->host_port);
> +}
static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
{
const int vlan = priv->data.default_vlan;
const int port = priv->host_port;
u32 reg;
int i;
reg = (priv->version == CPSW_VERSION_1) ? CPSW1_PORT_VLAN :
CPSW2_PORT_VLAN;
writel(vlan, &priv->host_port_regs->port_vlan);
for (int i = 0; i < 2; i++)
slave_write(priv->slaves + i, vlan, reg);
cpsw_ale_add_vlan(priv->ale, vlan, ALE_ALL_PORTS << port,
ALE_ALL_PORTS << port, ALE_ALL_PORTS << port,
(BIT(1) | BIT(2)) << port);
}
... or somewhere between both. Your call.
[...]
> @@ -933,6 +967,55 @@ static void cpsw_ndo_poll_controller(struct net_device *ndev)
> }
> #endif
>
> +static inline void cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
> + unsigned short vid)
> +{
> + cpsw_ale_add_vlan(priv->ale, vid, ALE_ALL_PORTS << priv->host_port,
> + 0, ALE_ALL_PORTS << priv->host_port,
> + (BIT(1) | BIT(2)) << priv->host_port);
"(BIT(1) | BIT(2))" is repeated a couple of times.
[...]
> +static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
> + unsigned short vid)
> +{
> + struct cpsw_priv *priv = netdev_priv(ndev);
> +
> + if (vid == priv->data.default_vlan)
> + return 0;
> +
> + spin_lock(&priv->lock);
> +
> + dev_info(priv->dev, "Adding vlanid %d to vlan filter\n", vid);
> + cpsw_add_vlan_ale_entry(priv, vid);
> +
> + spin_unlock(&priv->lock);
> + return 0;
> +}
> +
> +static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
> + unsigned short vid)
> +{
> + struct cpsw_priv *priv = netdev_priv(ndev);
> +
> + if (vid == priv->data.default_vlan)
> + return 0;
> +
> + spin_lock(&priv->lock);
> +
> + dev_info(priv->dev, "removing vlanid %d from vlan filter\n", vid);
> + cpsw_ale_del_vlan(priv->ale, vid, 0);
> + cpsw_ale_del_ucast(priv->ale, priv->mac_addr,
> + priv->host_port, ALE_VLAN, vid);
> + cpsw_ale_del_mcast(priv->ale, priv->ndev->broadcast, 0, ALE_VLAN, vid);
> +
> + spin_unlock(&priv->lock);
What are you trying to achieve with the lock ?
It is not used anywhere else and both cpsw_ndo_vlan_rx_{add, kill}_vid are
called under RTNL.
--
Ueimor
^ permalink raw reply
* [GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support
From: Tony Lindgren @ 2013-01-30 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510788B9.9050907@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [130129 00:34]:
> Hi Tony,
>
> On 01/22/2013 11:07 AM, Peter Ujfalusi wrote:
> > Hi Tony,
> >
> > The content of this pull:
> >
> > update for audio support via omap-twl4030 and pwm updates in board level:
> > http://www.spinics.net/lists/linux-omap/msg85085.html
> >
> > and zoom-peripherals update to not request the TWL GPIO7:
> > http://www.spinics.net/lists/linux-omap/msg85187.html
> >
> > All is on top of mainline v3.8-rc4 tag.
>
> Have you already pulled this one? I can not find the patches in linux-next.
Pulled now thanks. Will push out to omap-for-v3.9/twl.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] ARM: OMAP2+: powerdomain & clockdomain cleanup and fixes for 3.9
From: Tony Lindgren @ 2013-01-30 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301292235330.11442@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [130129 14:40]:
> Hi Tony,
>
> The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
>
> Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-b-for-3.9
>
> for you to fetch changes up to 562e54d13b6e0b17f72c9e629e1fd0b71e2a8a36:
>
> ARM: OMAP2+: powerdomain: fix whitespace, improve flag comments (2013-01-29 14:59:58 -0700)
>
> ----------------------------------------------------------------
> Several OMAP2+ power management fixes, optimizations, and cleanup.
> This series is a prerequisite for the functional powerdomain
> conversion series.
>
> Basic test logs for this branch are here:
>
> http://www.pwsan.com/omap/testlogs/pm_cleanup_fixes_3.9/20130129150017/
Thanks pulling both of them into omap-for-v3.9/pm.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] Nomadik devicetree and cleanups
From: Linus Walleij @ 2013-01-30 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129173641.GA17935@quad.lixom.net>
On Tue, Jan 29, 2013 at 6:36 PM, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Jan 28, 2013 at 11:36:59PM +0100, Linus Walleij wrote:
>> On Mon, Jan 28, 2013 at 10:31 PM, Olof Johansson <olof@lixom.net> wrote:
>>
>> > Would you mind rebasing on top of the depends/cleanup branch in arm-soc, sort
>> > out the breakage (and test it) and resubmit?
>>
>> So Olof, please try this instead, based on the ARM depends/cleanup HEAD
>> when I fetched it:
>>
>> The following changes since commit f8060f5446b1f2782f0a8ca9be2d870ea4198aee:
>>
>> Merge tag 'gic-vic-to-irqchip' of
>> git://sources.calxeda.com/kernel/linux into next/cleanup (2013-01-14
>> 19:55:03 -0800)
>>
>> are available in the git repository at:
>>
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
>> tags/nmk-dt-on-cleanups
>
> Beautiful! Pulled. Zero conflicts. :)
So as I heard this blew up for selecting OF instead of USE_OF here
is yet another pull request, with this oneliner change in the relevant
patch ("ARM: nomadik: delete old board files"):
- select OF
+ select USE_OF
I have tried to provoke builderrors with the defconfig but couldn't.
Here is then yet another pull request, and let's hope it works this
time around:
The following changes since commit f8060f5446b1f2782f0a8ca9be2d870ea4198aee:
Merge tag 'gic-vic-to-irqchip' of
git://sources.calxeda.com/kernel/linux into next/cleanup (2013-01-14
19:55:03 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
tags/nomadik-devicetree-v2
for you to fetch changes up to 2cac860881884564c86eeda4f622d8a7ca9b089c:
ARM: nomadik: get rid of <mach/hardware.h> (2013-01-30 22:55:34 +0100)
----------------------------------------------------------------
Nomadik Device Tree conversion rebased on ARM SoC cleanup branch
This patch set converts the Nomadik (mach-nomadik) to
Device Tree and delete the old board files, paving the
road for single zImage.
This version also selects USE_OF instead of just OF.
----------------------------------------------------------------
Linus Walleij (11):
ARM: nomadik: move last custom calls to pinctrl
ARM: nomadik: initial devicetree support
ARM: nomadik: move pin maps to cpu file
ARM: nomadik: move remaining PrimeCells to device tree
ARM: nomadik: add FSMC NAND
ARM: nomadik: move GPIO and pinctrl to device tree
ARM: nomadik: convert SMSC91x ethernet to device tree
ARM: nomadik: migrate MMC/SD card support to device tree
ARM: nomadik: add I2C devices to the device tree
ARM: nomadik: delete old board files
ARM: nomadik: get rid of <mach/hardware.h>
.../devicetree/bindings/arm/ste-nomadik.txt | 27 ++
.../devicetree/bindings/mtd/fsmc-nand.txt | 2 +-
arch/arm/Kconfig | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/ste-nomadik-s8815.dts | 30 ++
arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 256 +++++++++++++++
arch/arm/mach-nomadik/Kconfig | 10 +-
arch/arm/mach-nomadik/Makefile | 6 -
arch/arm/mach-nomadik/board-nhk8815.c | 353 --------------------
arch/arm/mach-nomadik/cpu-8815.c | 358 +++++++++++++++------
arch/arm/mach-nomadik/cpu-8815.h | 4 -
arch/arm/mach-nomadik/i2c-8815nhk.c | 88 -----
arch/arm/mach-nomadik/include/mach/hardware.h | 90 ------
arch/arm/mach-nomadik/include/mach/irqs.h | 2 -
arch/arm/mach-nomadik/include/mach/uncompress.h | 1 -
drivers/mtd/nand/fsmc_nand.c | 1 +
drivers/pinctrl/pinctrl-nomadik.c | 4 +
17 files changed, 588 insertions(+), 647 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/ste-nomadik.txt
create mode 100644 arch/arm/boot/dts/ste-nomadik-s8815.dts
create mode 100644 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
delete mode 100644 arch/arm/mach-nomadik/board-nhk8815.c
delete mode 100644 arch/arm/mach-nomadik/cpu-8815.h
delete mode 100644 arch/arm/mach-nomadik/i2c-8815nhk.c
delete mode 100644 arch/arm/mach-nomadik/include/mach/hardware.h
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-30 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo5NTyrHv8AQkw3hYpJRiZsk1HKHP3jP_MMpEVVhCgjKYg@mail.gmail.com>
Dear Bjorn Helgaas,
On Wed, 30 Jan 2013 11:52:15 -0700, Bjorn Helgaas wrote:
> I'm most concerned about the stuff in drivers/pci. I hesitate to
> merge drivers/pci/sw-pci-pci-bridge.c as-is because it's a model
> that's not connected to hardware and only works in a completely static
> situation, and the rest of the PCI core can't really deal with that.
>
> But I don't think supporting hotplug should be a show-stopper at this
> point, either. It sounds like we might be heading towards hooking
> this up more directly to the Marvell hardware, which will make it more
> arch-dependent. Something like that could either go in arch/arm, or
> in some not-quite-so-generic spot under drivers/pci.
If you really don't want sw-pci-pci-bridge.c in drivers/pci, then I can
make it a part of the drivers/pci/host/pci-mvebu.c driver itself. I
initially followed the idea started by Thierry Redding for the emulated
host bridge, but if you feel that this emulated PCI-to-PCI bridge is
too specific to this driver, then I'm fine with keeping it inside the
driver itself.
> >> I also forgot about the bus number munging in mvebu_pcie_rd_conf().
> >> The PCI core can update the bridge secondary/subordinate registers.
> >> It looks like you don't support writing to them, and the read path
> >> (pci_sw_pci_bridge_read()) looks like it doesn't do any translation
> >> between the hardware and Linux bus numbers. I don't understand the
> >> system well enough to know if this is an issue.
> >
> > Right. Could you explain a little bit for what reasons the PCI core
> > could update the secondary/subordinate registers, and to what
> > values it sets them?
>
> The secondary/subordinate registers effectively define a bus number
> aperture that tells the bridge which transactions to claim and forward
> downstream. When enumerating devices, we may update the subordinate
> bus number to widen the aperture so we can enumerate an arbitrary tree
> behind the bridge. When we're finished, we'll probably narrow it by
> updating the subordinate again, so the unused bus number space can be
> used for other bridges. I don't know the exact details of the
> algorithm, and they're likely to change anyway, but pci_scan_bridge()
> is where most of it happens.
>
> It looks like your current system doesn't support trees below the
> bridges, but hopefully we can make it so the generic enumeration
> algorithms still work.
In practice, in our situation, there isn't a tree below the bridge.
There is one single device. I'd prefer to not implement features that I
cannot effectively test, and let the implementation of those additional
features to whoever will need them, and therefore be able to test them.
I guess that if I integrate the PCI-to-PCI bridge emulation code within
the Marvell driver, then I can keep it fairly limited to whatever the
Marvell PCI driver requires, no?
> > For now, I statically assign the secondary bus register value to be
> > X+1, where X is the number of the PCIe interface, since X=0 is
> > reserved for the root bus (which has the host bridge and the
> > PCI-to-PCI bridges).
>
> That makes sense but limits you to a single bus (and really, a single
> device since this is PCIe) below the bridge.
Which is exactly what is happening here.
> > Also, could you detail what kind of translation I should be doing
> > when reading the hardware and Linux bus numbers?
>
> I'm hoping that the register Jason mentioned is enough to avoid the
> need for translation. If it's not, we can explore this a bit more.
Ok.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] ARM i.MX6: Add regulator delay support
From: Anson Huang @ 2013-01-30 22:33 UTC (permalink / raw)
To: linux-arm-kernel
For ANATOP LDOs, vddcpu, vddsoc and vddpu
have step time settings in the misc2 register, need
to add necessary step time info for these three LDOs,
then regulator driver can add necessary delay based on
these settings.
offset 0x170:
bit [24-25]: vddcpu
bit [26-27]: vddpu
bit [28-29]: vddsoc
field definition:
0'b00: 64 cycles of 24M clock;
0'b01: 128 cycles of 24M clock;
0'b02: 256 cycles of 24M clock;
0'b03: 512 cycles of 24M clock;
Signed-off-by: Anson Huang <b20788@freescale.com>
---
arch/arm/boot/dts/imx6q.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index d6265ca..a2e977d 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -480,6 +480,9 @@
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <0>;
anatop-vol-bit-width = <5>;
+ anatop-delay-reg-offset = <0x170>;
+ anatop-delay-bit-shift = <24>;
+ anatop-delay-bit-width = <2>;
anatop-min-bit-val = <1>;
anatop-min-voltage = <725000>;
anatop-max-voltage = <1450000>;
@@ -494,6 +497,9 @@
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
+ anatop-delay-reg-offset = <0x170>;
+ anatop-delay-bit-shift = <26>;
+ anatop-delay-bit-width = <2>;
anatop-min-bit-val = <1>;
anatop-min-voltage = <725000>;
anatop-max-voltage = <1450000>;
@@ -508,6 +514,9 @@
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <18>;
anatop-vol-bit-width = <5>;
+ anatop-delay-reg-offset = <0x170>;
+ anatop-delay-bit-shift = <28>;
+ anatop-delay-bit-width = <2>;
anatop-min-bit-val = <1>;
anatop-min-voltage = <725000>;
anatop-max-voltage = <1450000>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] regulators: anatop: add set_voltage_time_sel interface
From: Anson Huang @ 2013-01-30 22:37 UTC (permalink / raw)
To: linux-arm-kernel
some of anatop's regulators(vppcpu, vddpu and vddsoc) have
register settings about LDO's step time, which will impact
the LDO ramp up speed, need to use set_voltage_time_sel
interface to add necessary delay everytime LDOs' voltage
is increased.
offset 0x170:
bit [24-25]: vddcpu
bit [26-27]: vddpu
bit [28-29]: vddsoc
field definition:
0'b00: 64 cycles of 24M clock;
0'b01: 128 cycles of 24M clock;
0'b02: 256 cycles of 24M clock;
0'b03: 512 cycles of 24M clock;
Signed-off-by: Anson Huang <b20788@freescale.com>
---
drivers/regulator/anatop-regulator.c | 42 ++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/regulator/anatop-regulator.c b/drivers/regulator/anatop-regulator.c
index 8f39cac..a857b9c 100644
--- a/drivers/regulator/anatop-regulator.c
+++ b/drivers/regulator/anatop-regulator.c
@@ -31,12 +31,18 @@
#include <linux/regulator/driver.h>
#include <linux/regulator/of_regulator.h>
+#define LDO_RAMP_UP_UNIT_IN_CYCLES 64 /* 64 cycles per step */
+#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */
+
struct anatop_regulator {
const char *name;
u32 control_reg;
struct regmap *anatop;
int vol_bit_shift;
int vol_bit_width;
+ u32 delay_reg;
+ int delay_bit_shift;
+ int delay_bit_width;
int min_bit_val;
int min_voltage;
int max_voltage;
@@ -55,6 +61,33 @@ static int anatop_regmap_set_voltage_sel(struct regulator_dev *reg,
return regulator_set_voltage_sel_regmap(reg, selector);
}
+static int anatop_regmap_set_voltage_time_sel(struct regulator_dev *reg,
+ unsigned int old_sel,
+ unsigned int new_sel)
+{
+ struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
+ u32 val;
+ int ret = 0;
+
+ /* check whether need to care about LDO ramp up speed */
+ if (anatop_reg->delay_reg) {
+ /*
+ * the delay for LDO ramp up time is
+ * based on the register setting, we need
+ * to calculate how many steps LDO need to
+ * ramp up, and how much delay needed. (us)
+ */
+ regmap_read(anatop_reg->anatop, anatop_reg->delay_reg, &val);
+ val = (val >> anatop_reg->delay_bit_shift) &
+ ((1 << anatop_reg->delay_bit_width) - 1);
+ ret = new_sel > old_sel ? (new_sel - old_sel) *
+ ((LDO_RAMP_UP_UNIT_IN_CYCLES << val) /
+ LDO_RAMP_UP_FREQ_IN_MHZ + 1) : 0;
+ }
+
+ return ret;
+}
+
static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
{
struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
@@ -67,6 +100,7 @@ static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
static struct regulator_ops anatop_rops = {
.set_voltage_sel = anatop_regmap_set_voltage_sel,
+ .set_voltage_time_sel = anatop_regmap_set_voltage_time_sel,
.get_voltage_sel = anatop_regmap_get_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
.map_voltage = regulator_map_voltage_linear,
@@ -143,6 +177,14 @@ static int anatop_regulator_probe(struct platform_device *pdev)
goto anatop_probe_end;
}
+ /* read LDO ramp up setting, only for core reg */
+ of_property_read_u32(np, "anatop-delay-reg-offset",
+ &sreg->delay_reg);
+ of_property_read_u32(np, "anatop-delay-bit-width",
+ &sreg->delay_bit_width);
+ of_property_read_u32(np, "anatop-delay-bit-shift",
+ &sreg->delay_bit_shift);
+
rdesc->n_voltages = (sreg->max_voltage - sreg->min_voltage) / 25000 + 1
+ sreg->min_bit_val;
rdesc->min_uV = sreg->min_voltage;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-01-30 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51083580.1010900@gmail.com>
> On 01/29/2013 09:32 PM, Jason Cooper wrote:
> >On Tue, Jan 29, 2013 at 09:08:46PM +0100, Sebastian Hesselbarth wrote:
> >>Leaves Issue 3, gbe forgets about its MAC address when gated or powered
> >>down. That should be done with local-mac-address passed by DT enabled
> >>u-boot or any other (dirty) ATAG hack ;)
> >
> >A patch to mv643xx_eth to pull this from DT should solve this.
Somewhere, Jason Gunthorpe shared his patch to do this. I'll poke
around for it and try to get it merged in.
thx,
Jason.
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-01-30 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108F300.7000705@gmail.com>
On Wed, Jan 30, 2013 at 11:16:32AM +0100, Sebastian Hesselbarth wrote:
> On 01/30/2013 09:30 AM, Simon Baatz wrote:
> >On Wed, Jan 30, 2013 at 01:51:18AM +0100, Sebastian Hesselbarth wrote:
> >>- [PATCH v2 2/2] clk: mvebu: Do not gate runit clock on Kirkwood
> >> (no lockup for minimal kernel configs)
> >>
> >>- [PATCH] NET: mv643xx: get smi clock from device tree
> >> (no lockup for modular DT ethernet)
> >>
> >>- Some patch that adds MV643XX_ETH_SHARED_NAME ".0" and ".1" clk aliases
> >> (no lockup for modular non-DT ethernet)
> >
> >I think your patch to get the smi clock is intended for device tree.
> >Thus, the driver won't use these aliases, right?
>
> Actually, both patches above will not fix modular ethernet for 3.8-rc as
> shared driver is probed before core driver and not requesting any clk at
> all. The "NET: mv643xx: get smi clock from device tree" patch is based
> on Jason's attempt to separate shared driver.
>
> If we need to fix modular ethernet now, we also need to add a clk_get
> to shared ethernet.
>
> But yes, DT doesn't need any clock aliases.
>
> >>- Some patch that adds clk_prepare_enable to ge0/ge1 clocks to
> >> kirkwood_legacy_clk_init()
> >> (retain MAC address for modular DT ethernet)
> >
> >I like mine better, since it only enables the clocks of the
> >interfaces that are initialized in the init code. I tested it with
> >non-DT as well. But either is fine with me.
>
> I know the difference, but here it is not only about fixing an issue
> but have it cleanly removed later on. But I don't have a strong opinion
> on that and maybe Andrew or Jason should coordinate what must be fixed
> now and how we do it.
I agree that Simon's is nicer (per device disabling). However,
Sebastian is correct, his is easier to remove later on once we have
proper DT bindings in mv643xx_eth.
As it stands, there are three patches to fix this issue:
ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency
ARM: kirkwood: provide ge clock aliases for shared smi
ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
wrt to runit gating, the only case we are not covering is if of_serial
is a module (and so is everything else using the runit clk). That's
*really* rare. If someone embarks down that path, they get the
responsibility of not writing to all the deactivated registers. ;-)
wrt to ge losing mac addresses, both DT and non-DT booting are covered by
Sebastian's patches, for non-DT aware mv643xx_eth.
Once we add proper DT support to mv643xx_eth, the local-mac-address will
need to be defined in the dtb. We should probably poke the other Jason
to see if there is a cooresponding u-boot patch to his local-mac-address
patch.
thx,
Jason.
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Gunthorpe @ 2013-01-30 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130224300.GU7717@titan.lakedaemon.net>
On Wed, Jan 30, 2013 at 05:43:00PM -0500, Jason Cooper wrote:
> > On 01/29/2013 09:32 PM, Jason Cooper wrote:
> > >On Tue, Jan 29, 2013 at 09:08:46PM +0100, Sebastian Hesselbarth wrote:
> > >>Leaves Issue 3, gbe forgets about its MAC address when gated or powered
> > >>down. That should be done with local-mac-address passed by DT enabled
> > >>u-boot or any other (dirty) ATAG hack ;)
> > >
> > >A patch to mv643xx_eth to pull this from DT should solve this.
>
> Somewhere, Jason Gunthorpe shared his patch to do this. I'll poke
> around for it and try to get it merged in.
Yes, you asked for the doc update and I haven't had a moment to get a
tree setup for that..
Here are some words though:
- local-mac-address : Optional, the MAC address to assign to the
device. If not specified then the MAC address in the HW
registers is used, but the driver can not be made modular.
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 7048d7c..2b2cfcb 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2891,6 +2891,8 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
struct mv643xx_eth_private *mp;
struct net_device *dev;
struct resource *res;
+ const u8 *mac;
+ int len;
int err;
if (pdev->dev.of_node) {
@@ -2912,6 +2914,10 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
else
pd->phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT;
+ mac = of_get_property(pdev->dev.of_node, "local-mac-address", &len);
+ if (mac && len == 6)
+ memcpy(pd->mac_addr, mac, sizeof pd->mac_addr);
+
np = of_parse_phandle(pdev->dev.of_node, "mdio", 0);
if (np) {
pd->shared = of_find_device_by_node(np);
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-01-30 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130232836.1b1fd89b@skate>
On Wed, Jan 30, 2013 at 11:28:36PM +0100, Thomas Petazzoni wrote:
> > It looks like your current system doesn't support trees below the
> > bridges, but hopefully we can make it so the generic enumeration
> > algorithms still work.
>
> In practice, in our situation, there isn't a tree below the bridge.
> There is one single device. I'd prefer to not implement features that I
> cannot effectively test, and let the implementation of those additional
> features to whoever will need them, and therefore be able to test
> them.
Agreed it is hard to test, but be aware that any system that has PCI-E
slots can host an add-in card that has a bridge on it. These are midly
common in some areas like high port count ethernet cards.
If you aren't going to attempt the implementation then a really big
FIXME that the config access routing is not correct and needs to be
based on the bus range assigned to the bridge would be friendly :)
Jason
^ permalink raw reply
* [GIT PULL] ux500 <mach/id.h> removal
From: Arnd Bergmann @ 2013-01-30 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYmTTgpnAOoNM3RJiF_oADgbuGK-vw6JF8J9rPAttA5PQ@mail.gmail.com>
On Wednesday 30 January 2013, Linus Walleij wrote:
> On Wed, Jan 30, 2013 at 1:12 AM, Olof Johansson <olof@lixom.net> wrote:
> > [Me]
> >> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
> >> tags/ux500-no-idh
> >
> > Pulled in.
> >
> > This has a somewhat annoying (but trivial) conflict against your own
> > code (the cpufreq driver changes).
>
> Arnd always told me to split stuff cleanly on branches, which of course
> leads to conflicts like that, but I thought he wanted them, rather than
> huge accumulated patch sets built on to of each othere ... a bit hard to
> do the right thing here, what would have been the right way?
>
> Does it help if I base stuff off ARM SoC tree branches, and which
> ones can be relied upon in that case?
Not sure if it applies here, but in a lot of cases, one can extract the
parts that do conflict and put those patches first in the series, and
merge them together before the pull request.
The classic example of this is two independent features A and B that
both contain some cleanup. By moving the cleanup first, you can merge
the cleanup-A patches with the cleanup-B patches and submit them as one
branch, and then have feature A on top of cleanup-A merge cleanly with
both feature-B (because there are no conflicts) and with cleanup-A-B
(because cleanup-A-B has already resolved the conflict).
Unrelated to this: The mach/id.h removal seems to have caused a few
build errors in the for-next tree with u8500_defconfig. Can you have
a look at what went wrong there?
Arnd
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Gunthorpe @ 2013-01-30 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130230100.GV7717@titan.lakedaemon.net>
On Wed, Jan 30, 2013 at 06:01:00PM -0500, Jason Cooper wrote:
> Once we add proper DT support to mv643xx_eth, the local-mac-address will
> need to be defined in the dtb. We should probably poke the other Jason
> to see if there is a cooresponding u-boot patch to his local-mac-address
> patch.
Sorry I don't have a u-boot fix, we don't use u-boot here - but
local-mac-address is common on other ARM drivers so I'd hope there is
a u-boot facility for stuffing it already?
Jason
^ permalink raw reply
* [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-01-30 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359558091-29251-2-git-send-email-ruslan.bilovol@ti.com>
On 17:01 Wed 30 Jan , Ruslan Bilovol wrote:
> Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> the CPU carrying out the read from the file.
> Userspace using this information may decide what module
> to load or how to configure some specific (and processor-depended)
> settings or so.
> However, since really different SoCs can share same ARM core,
> this information currently is not so useful.
> For example, TI OMAP4460 and OMAP4470 SoCs show the same
> information in the /proc/cpuinfo whereas they are different.
> Since in most cases ARM CPU is a part of some system on a chip (SoC),
> the "cpuinfo" file looks like exactly that place, where this
> information have to be displayed.
>
> So added new line "SoC name" in the "cpuinfo" output for system
> on a chip name. It is placed between CPU information and machine
> information, so the file structure looks gracefully (CPU-SoC-Hardware)
Nack
this break the kernel ABI
and we have now socinfo via sysfs
Best Regards,
J.
>
> Example:
>
> / # cat proc/cpuinfo
> [...]
> CPU variant : 0x2
> CPU part : 0xc09
> CPU revision : 10
>
> SoC name : OMAP4470
>
> Hardware : OMAP4 Blaze Tablet
> Revision : 20edb4
> [...]
>
> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
> ---
> arch/arm/include/asm/setup.h | 1 +
> arch/arm/kernel/setup.c | 9 +++++++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
> index c50f056..621df40 100644
> --- a/arch/arm/include/asm/setup.h
> +++ b/arch/arm/include/asm/setup.h
> @@ -52,5 +52,6 @@ extern struct meminfo meminfo;
> extern int arm_add_memory(phys_addr_t start, phys_addr_t size);
> extern void early_print(const char *str, ...);
> extern void dump_machine_table(void);
> +extern void set_soc_model_name(char *name);
>
> #endif
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 3f6cbb2..bb3805f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -134,6 +134,7 @@ char elf_platform[ELF_PLATFORM_SIZE];
> EXPORT_SYMBOL(elf_platform);
>
> static const char *cpu_name;
> +static const char *soc_name;
> static const char *machine_name;
> static char __initdata cmd_line[COMMAND_LINE_SIZE];
> struct machine_desc *machine_desc __initdata;
> @@ -493,6 +494,11 @@ static void __init setup_processor(void)
> cpu_init();
> }
>
> +void set_soc_model_name(char *name)
> +{
> + soc_name = name;
> +}
> +
> void __init dump_machine_table(void)
> {
> struct machine_desc *p;
> @@ -902,6 +908,9 @@ static int c_show(struct seq_file *m, void *v)
> seq_printf(m, "CPU revision\t: %d\n\n", cpuid & 15);
> }
>
> + if (soc_name)
> + seq_printf(m, "SoC name\t: %s\n\n", soc_name);
> +
> seq_printf(m, "Hardware\t: %s\n", machine_name);
> seq_printf(m, "Revision\t: %04x\n", system_rev);
> seq_printf(m, "Serial\t\t: %08x%08x\n",
> --
> 1.7.9.5
>
>
> _______________________________________________
> 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 v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-30 23:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130230100.GV7717@titan.lakedaemon.net>
On 01/31/2013 12:01 AM, Jason Cooper wrote:
> As it stands, there are three patches to fix this issue:
>
> ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency
> ARM: kirkwood: provide ge clock aliases for shared smi
> ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
Actually, for the second patch I got distracted by the smi split patch
set floating around. But that is not in current kernel and smi will not
request any clock at all.
If Simon can hit another round of testing without second patch included
and agrees, I suggest to keep it for next release.
> wrt to ge losing mac addresses, both DT and non-DT booting are covered by
> Sebastian's patches, for non-DT aware mv643xx_eth.
non-DT already ungates ge0/1 clocks on registration and cannot loose its
mac address, not my fix.
Sebastian
^ permalink raw reply
* [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name
From: Russell King - ARM Linux @ 2013-01-30 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301301402330.6300@xanadu.home>
On Wed, Jan 30, 2013 at 02:07:53PM -0500, Nicolas Pitre wrote:
> On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
>
> > Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> > the CPU carrying out the read from the file.
> > Userspace using this information may decide what module
> > to load or how to configure some specific (and processor-depended)
> > settings or so.
> > However, since really different SoCs can share same ARM core,
> > this information currently is not so useful.
> > For example, TI OMAP4460 and OMAP4470 SoCs show the same
> > information in the /proc/cpuinfo whereas they are different.
> > Since in most cases ARM CPU is a part of some system on a chip (SoC),
> > the "cpuinfo" file looks like exactly that place, where this
> > information have to be displayed.
> >
> > So added new line "SoC name" in the "cpuinfo" output for system
> > on a chip name. It is placed between CPU information and machine
> > information, so the file structure looks gracefully (CPU-SoC-Hardware)
> >
> > Example:
> >
> > / # cat proc/cpuinfo
> > [...]
> > CPU variant : 0x2
> > CPU part : 0xc09
> > CPU revision : 10
> >
> > SoC name : OMAP4470
> >
> > Hardware : OMAP4 Blaze Tablet
>
> Please remove that extra blank line between "SoC name" and "Hardware".
> The blank line after "CPU revision" is fine.
>
> Also, please rename this to "System name". Not all systems are "on
> chip". By using "System name" this is more universally useful.
You may notice I've already suggested that this should be using the SoC
infrastructure to export this information, which was explicitly designed
to do this.
If we're going to have one SoC doing one thing and another SoC exporting
this information a completely different way, we're doomed. We need to
make a decision and do it one way and one way only - and that decision
was made when drivers/base/soc.c was merged.
Unfortunately, I'd forgotten about that when I made my initial comments
about the difference between "CPU" and "SoC".
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Bjorn Helgaas @ 2013-01-30 23:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130232836.1b1fd89b@skate>
On Wed, Jan 30, 2013 at 3:28 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Bjorn Helgaas,
>
> On Wed, 30 Jan 2013 11:52:15 -0700, Bjorn Helgaas wrote:
>> It looks like your current system doesn't support trees below the
>> bridges, but hopefully we can make it so the generic enumeration
>> algorithms still work.
>
> In practice, in our situation, there isn't a tree below the bridge.
> There is one single device. I'd prefer to not implement features that I
> cannot effectively test, and let the implementation of those additional
> features to whoever will need them, and therefore be able to test them.
I understand the concern about testing, but my advice is to not use
that as an excuse to artificially limit the functionality of the code
you're writing :)
You're talking about emulating a bridge, and the bridge really doesn't
know or care what's downstream. If it works with a single device
downstream, it should work with another bridge downstream. Many
aspects of bridge configuration can be tested with creative
application of setpci, so that might be a possibility, too.
> I guess that if I integrate the PCI-to-PCI bridge emulation code within
> the Marvell driver, then I can keep it fairly limited to whatever the
> Marvell PCI driver requires, no?
Yeah, it's just that the pci_dev for this emulated bridge is used by
the generic PCI core code, e.g., pci_scan_bridge(), so whatever
emulation you do has to be robust enough that the core won't notice
it's emulated.
Bjorn
^ permalink raw reply
* [PATCH RFC 1/2] Implementation of pci_fixup_irqs for descendants of a specified bus
From: Bjorn Helgaas @ 2013-01-31 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130118113742.GA9006@arm.com>
On Fri, Jan 18, 2013 at 4:37 AM, Andrew Murray <Andrew.Murray@arm.com> wrote:
> Continuing from discussion with Thierry (lkml.org/lkml/2013/1/18/107) perhaps
> this will be useful to fold into your patchset.
> ---
> This patch provides pci_bus_fixup_irqs which performs the same
> function as pci_fixup_irqs but only to descendants of the specified
> bus.
I think pci_fixup_irqs() is a broken design to begin with because it
is only called once at boot-time and it iterates over all the devices
we've found so far. Any hot-added devices never get the fixups.
Adding pci_bus_fixup_irqs() addresses part of that, by adding a way to
fixup a subset of devices, e.g., maybe it could be done for hot-added
things.
But I think it would be better to do a more extensive refactoring and
do the IRQ fixups directly somewhere in the pci_device_add() path.
That way we can do it a device at a time, for every device (present at
boot and hot-added later), and before any drivers claim the device.
> This can reduce unnecessary fixing up of device irqs when new buses
> are added.
>
> Signed-off-by: Andrew Murray <Andrew.Murray@arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
> drivers/pci/setup-irq.c | 15 +++++++++++++++
> include/linux/pci.h | 3 +++
> 2 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/setup-irq.c b/drivers/pci/setup-irq.c
> index eb219a1..ea91874 100644
> --- a/drivers/pci/setup-irq.c
> +++ b/drivers/pci/setup-irq.c
> @@ -62,3 +62,18 @@ pci_fixup_irqs(u8 (*swizzle)(struct pci_dev *, u8 *),
> for_each_pci_dev(dev)
> pdev_fixup_irq(dev, swizzle, map_irq);
> }
> +
> +void __init
> +pci_bus_fixup_irqs(struct pci_bus *bus,
> + u8 (*swizzle)(struct pci_dev *, u8 *),
> + int (*map_irq)(const struct pci_dev *, u8, u8))
> +{
> + struct pci_dev *dev;
> +
> + list_for_each_entry(dev, &bus->devices, bus_list) {
> + pdev_fixup_irq(dev, swizzle, map_irq);
> +
> + if (dev->subordinate)
> + pci_bus_fixup_irqs(dev->subordinate, swizzle, map_irq);
> + }
> +}
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 5faa831..1b3c2eb 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -953,6 +953,9 @@ void pdev_enable_device(struct pci_dev *);
> int pci_enable_resources(struct pci_dev *, int mask);
> void pci_fixup_irqs(u8 (*)(struct pci_dev *, u8 *),
> int (*)(const struct pci_dev *, u8, u8));
> +void pci_bus_fixup_irqs(struct pci_bus *bus,
> + u8 (*swizzle)(struct pci_dev *, u8 *),
> + int (*map_irq)(const struct pci_dev *, u8, u8));
> #define HAVE_PCI_REQ_REGIONS 2
> int __must_check pci_request_regions(struct pci_dev *, const char *);
> int __must_check pci_request_regions_exclusive(struct pci_dev *, const char *);
> --
> 1.7.0.4
>
>
^ 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