* alignment faults in 3.6
From: Maxime Bizon @ 2012-10-11 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349956456.21172.8820.camel@edumazet-glaptop>
On Thu, 2012-10-11 at 13:54 +0200, Eric Dumazet wrote:
> Of course, if you use a forwarding setup, and the tx driver is not SG
> capable, performance will be bad (You have to copy the data into a
> single skb (linearize the skb))
>
> But in 2012, having to use hardware without SG for a router sounds a bad
> joke (if cpu speed is _also_ too low)
Hey I cannot go back in time, when that hardware was built in 2004 (mips
@250Mhz), it was considered good, and we did manufacture a lot of it, so
it's still maintained.
People run recent kernels on older hardware because they are *encouraged
to do so*.
I fought inside my company to be good kernel citizen, not using
proprietary BSP, rewrite & mainline the drivers, because that was the
community promise: mainline it, we will support it for you, you will get
the latest kernel features for free.
That worked, but with some drawbacks:
- kernel footprint grew that much (we started from 2.4) that it does
not fit in device flash anymore
- performance took a hit each time we upgrade, mostly because of cache
footprint growth.
- as kernel footprint grew, available RAM for conntrack & route cache
entries was smaller each time
But I had to stop upgrading after 2.6.20. Everything below is not
anybody's fault. Bloat is unavoidable for software project that big.
I'm perfectly ok with that, but I don't want to be ridiculed for running
mainline kernel on old hardware.
> Adding get_unaligned() everywhere in linux network stacks is not an
> option.
>
> We actually want to be able to read the code and fix the bugs, not only
> run it on a cheap low end router.
That was not a request, I just needed a clarification.
Documentation/unaligned-memory-access.txt does not say it's a big no-no,
it says you can give unaligned pointers to the networking stack if you
arch can do unaligned access (with an "efficiency" notion).
MIPS and ARM have a software handler for this, and performance wise in
my case it's better to take the faults, a driver writer may think a
benchmark will dictate what to do.
--
Maxime
^ permalink raw reply
* [PATCH v2 00/15] pinctrl: samsung: Usability and extensibiltiy improvements
From: Thomas Abraham @ 2012-10-11 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349943081-27939-1-git-send-email-t.figa@samsung.com>
On 11 October 2012 16:11, Tomasz Figa <t.figa@samsung.com> wrote:
> This patch series is a work on improving usability and extensibiltiy of
> the pinctrl-samsung driver. It consists of three main parts:
> - improving flexibility of SoC-specific data specification
> - converting the driver to one GPIO chip and IRQ domain per pin bank
> - improving wake-up IRQ setup and handling
>
> 1) What the first part does, in addition to various related fixes, is
> removing any unnecessary static data from pinctrl-exynos driver.
>
> This is achieved mostly thanks to assigning pin numbers dynamically,
> with help of only pin counts of particular banks. It also simplifies
> adding next SoC variants, since much less static data needs to be
> specified.
>
> 2) The second part attempts to simplify usage of the driver and fix several
> problems of current implementation, in particular:
>
> - Simplifies GPIO pin specification in device tree by using pin
> namespace local to pin bank instead of local to pin controller, e.g.
>
> gpios = <&gpj0 3 0>;
>
> instead of
>
> gpios = <&pinctrl0 115 0>;
>
> - Simplifies GPIO interrupt specification in device tree by using
> namespace local to pin bank (and equal to GPIO namespace), e.g.
>
> interrupt-parent = <&gpj0>;
> interrupts = <3 0>;
>
> instead of
>
> interrupt-parent = <&pinctrl0>;
> interrupts = <115 0>;
>
> - Simplifies internal GPIO pin to bank translation thanks to
> correspondence of particular GPIO chips to pin banks. This allows
> to remove the (costly in case of GPIO bit-banging drivers) lookup
> over all banks to find the one that the pin is from.
>
> 3) Third part is focused on removing the hard-coded description of wake-up
> interrupt layout.
>
> It moves wake-up interrupt description to bank struct and device tree,
> which allows to specify which pin banks support wake-up interrupts and
> how they are handled (direct or multiplexed/chained).
>
> See particular patches for more detailed descriptions and the last patch for
> updated device tree bindings.
>
> Changes since v1:
> - dropped moving SoC-specific data to device tree
> (might be added in further patches)
> - dropped per-bank specification of configuration register offsets
> (thus limiting scope of the driver to Exynos SoCs; will be added in
> further patches)
>
> Tomasz Figa (15):
> pinctrl: samsung: Detect and handle unsupported configuration types
> pinctrl: samsung: Do not pass gpio_chip to pin_to_reg_bank
> pinctrl: samsung: Assing pin numbers dynamically
> pinctrl: samsung: Remove static pin enumerations
> pinctrl: samsung: Distinguish between pin group and bank nodes
> ARM: dts: exynos4210-pinctrl: Add nodes for pin banks
> pinctrl: samsung: Match pin banks with their device nodes
> pinctrl: samsung: Hold pointer to driver data in bank struct
> pinctrl: samsung: Include bank-specific eint offset in bank struct
> pinctrl: exynos: Use one IRQ domain per pin bank
> pinctrl: samsung: Use one GPIO chip per pin bank
> pinctrl: samsung: Use per-bank IRQ domain for wake-up interrupts
> pinctrl: exynos: Set pin function to EINT in irq_set_type of wake-up
> EINT
> pinctrl: samsung: Add GPIO to IRQ translation
> Documentation: Update samsung-pinctrl device tree bindings
> documentation
>
> .../bindings/pinctrl/samsung-pinctrl.txt | 118 +++++--
> arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 278 ++++++++++++++++
> arch/arm/boot/dts/exynos4210.dtsi | 241 +-------------
> drivers/pinctrl/pinctrl-exynos.c | 367 ++++++++++-----------
> drivers/pinctrl/pinctrl-exynos.h | 170 ++--------
> drivers/pinctrl/pinctrl-samsung.c | 203 ++++++++----
> drivers/pinctrl/pinctrl-samsung.h | 29 +-
> 7 files changed, 741 insertions(+), 665 deletions(-)
Hi Tomasz,
Thanks for this excellent series. This is a nice improvement for the
samsung pinctrl driver.
For this series:
Acked-by: Thomas Abraham <thomas.abraham@linaro.org>
Regards,
Thomas.
>
> --
> 1.7.12
>
^ permalink raw reply
* [PATCH V2 3/3] ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
From: Lokesh Vutla @ 2012-10-11 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959669-16366-1-git-send-email-lokeshvutla@ti.com>
Samsung's K3PE0E000B memory part is used in OMAP5-evm board.
Adding timings and geometry details for Samsung's memory part and
attaching the same to device-handle of EMIF1/2.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/omap5-evm.dts | 11 +++++
arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 +++++++++++++++++++++++++++++
2 files changed, 78 insertions(+)
create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 6f87e1a..ed1d1b5 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ "omap5.dtsi"
+/include/ "samsung_k3pe0e000b.dtsi"
/ {
model = "TI OMAP5 EVM board";
@@ -82,3 +83,13 @@
0x020700d9>; /* SEARCH */
linux,input-no-autorepeat;
};
+
+&emif1 {
+ cs1-used;
+ device-handle = <&samsung_K3PE0E000B>;
+};
+
+&emif2 {
+ cs1-used;
+ device-handle = <&samsung_K3PE0E000B>;
+};
diff --git a/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
new file mode 100644
index 0000000..b352d69
--- /dev/null
+++ b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Timings and Geometry for Samsung K3PE0E000B memory part
+ */
+
+/ {
+ samsung_K3PE0E000B: lpddr2 {
+ compatible = "Samsung,K3PE0E000B","jedec,lpddr2-s4";
+ density = <4096>;
+ io-width = <32>;
+
+ tRPab-min-tck = <3>;
+ tRCD-min-tck = <3>;
+ tWR-min-tck = <3>;
+ tRASmin-min-tck = <3>;
+ tRRD-min-tck = <2>;
+ tWTR-min-tck = <2>;
+ tXP-min-tck = <2>;
+ tRTP-min-tck = <2>;
+ tCKE-min-tck = <3>;
+ tCKESR-min-tck = <3>;
+ tFAW-min-tck = <8>;
+
+ timings_samsung_K3PE0E000B_533mhz: lpddr2-timings at 0 {
+ compatible = "jedec,lpddr2-timings";
+ min-freq = <10000000>;
+ max-freq = <533333333>;
+ tRPab = <21000>;
+ tRCD = <18000>;
+ tWR = <15000>;
+ tRAS-min = <42000>;
+ tRRD = <10000>;
+ tWTR = <7500>;
+ tXP = <7500>;
+ tRTP = <7500>;
+ tCKESR = <15000>;
+ tDQSCK-max = <5500>;
+ tFAW = <50000>;
+ tZQCS = <90000>;
+ tZQCL = <360000>;
+ tZQinit = <1000000>;
+ tRAS-max-ns = <70000>;
+ tDQSCK-max-derated = <6000>;
+ };
+
+ timings_samsung_K3PE0E000B_266mhz: lpddr2-timings at 1 {
+ compatible = "jedec,lpddr2-timings";
+ min-freq = <10000000>;
+ max-freq = <266666666>;
+ tRPab = <21000>;
+ tRCD = <18000>;
+ tWR = <15000>;
+ tRAS-min = <42000>;
+ tRRD = <10000>;
+ tWTR = <7500>;
+ tXP = <7500>;
+ tRTP = <7500>;
+ tCKESR = <15000>;
+ tDQSCK-max = <5500>;
+ tFAW = <50000>;
+ tZQCS = <90000>;
+ tZQCL = <360000>;
+ tZQinit = <1000000>;
+ tRAS-max-ns = <70000>;
+ tDQSCK-max-derated = <6000>;
+ };
+ };
+};
--
1.7.10.4
^ permalink raw reply related
* [PATCH V2 2/3] ARM: dts: omap5: EMIF device tree data for OMAP5 boards
From: Lokesh Vutla @ 2012-10-11 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959669-16366-1-git-send-email-lokeshvutla@ti.com>
Adding EMIF device tree data for OMAP5 boards.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5db33f4..445aeea 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -319,5 +319,29 @@
ti,buffer-size = <128>;
ti,hwmods = "mcbsp3";
};
+
+ emif1: emif at 0x4c000000 {
+ compatible = "ti,emif-4d5";
+ ti,hwmods = "emif1";
+ phy-type = <2>;
+ reg = <0x4c000000 0x3ff>;
+ interrupts = <0 110 0x4>;
+ interrupt-parent = <&gic>;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
+
+ emif2: emif at 0x4d000000 {
+ compatible = "ti,emif-4d5";
+ ti,hwmods = "emif2";
+ phy-type = <2>;
+ reg = <0x4d000000 0x3ff>;
+ interrupts = <0 111 0x4>;
+ interrupt-parent = <&gic>;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH V2 1/3] ARM: dts: omap5-evm: Fix size of memory defined for EVM
From: Lokesh Vutla @ 2012-10-11 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349959669-16366-1-git-send-email-lokeshvutla@ti.com>
Memory present for OMAP5-evm is 2GB. But in dts file
it is specified as 1GB. Correcting the same.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/omap5-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 9c41a3f..6f87e1a 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -15,7 +15,7 @@
memory {
device_type = "memory";
- reg = <0x80000000 0x40000000>; /* 1 GB */
+ reg = <0x80000000 0x80000000>; /* 2 GB */
};
vmmcsd_fixed: fixedregulator-mmcsd {
--
1.7.10.4
^ permalink raw reply related
* [PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
From: Lokesh Vutla @ 2012-10-11 12:47 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds Device tree data for the EMIF
sdram controllers in OMAP5 and LPDDR2 memory devices
in OMAP5-evm board.
Testing:
- Boot tested on OMAP5430 evm.
- Built EMIF as a module.
Changes from v1:
* Created a seperate dtsi file for Samsung LPDDR2 memory device
used in OMAP5-evm.
* Passing reg and interrupt fields from dt for EMIF1 and EMIF2.
Lokesh Vutla (3):
ARM: dts: omap5-evm: Fix size of memory defined for EVM
ARM: dts: omap5: EMIF device tree data for OMAP5 boards
ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
arch/arm/boot/dts/omap5-evm.dts | 13 +++++-
arch/arm/boot/dts/omap5.dtsi | 24 +++++++++++
arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 +++++++++++++++++++++++++++++
3 files changed, 103 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
--
1.7.10.4
^ permalink raw reply
* [PATCH 0/4] OMAP-GPMC generic timing migration
From: Mohammed, Afzal @ 2012-10-11 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5076B166.2020006@gmail.com>
Hi Daniel,
On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote:
> Admittedly, I lost track on the multiple GPMC series here, and they also
> cause major merge conflicts with Linus' current master branch.
>
> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
Series [1-2] plus this series would be the required.
Note that 1st patch of series [2] has already reached mainline.
Another easy way would be, pull,
git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing
git checkout -b gpmc <myremote/gpmc-timing>
git rebase --onto <Linus-current-master> next-20121005 (or "080aa9c")
> would like to augment this to make GPMC attached NAND probable in DT, in
> case this is still an open topic.
I would be doing gpmc DT conversion next. Hoping that this
series too will be picked up by Tony, as once this series is
accepted, during DT conversion we need not rely on
auxdata (a last resort option) for timings.
> Thanks for you hard work,
Thanks, it was a pleasure to read the above.
Regards
Afzal
[1] http://marc.info/?l=linux-omap&m=134945131602622&w=2
[2] http://marc.info/?l=linux-omap&m=134967458329531&w=2
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Rob Herring @ 2012-10-11 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1210100939160.16518@xanadu.home>
From: Rob Herring <rob.herring@calxeda.com>
With recent compilers and move to generic unaligned.h in commit d25c881
(ARM: 7493/1: use generic unaligned.h), unaligned accesses will be used
by the LZO decompressor on v7 cores. So we need to make sure unaligned
accesses are allowed by clearing the SCTLR A bit.
While v6 can support unaligned accesses, it is optional and current
compilers won't emit unaligned accesses. So we don't clear the A bit for
v6.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
---
The contents of this were already reviewed on this thread, so I sent this
to the patch system and this was Russell's reply:
> NAK for two reasons.
>
> 1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
> in my mailbox)
>
> 2. The behaviour of unaligned accesses vary depending on CPU. Some
> fix-up the access, others load the word and then rotate it. If we have
> decompressors which perform unaligned accesses, we need to fix this
> properly to avoid the CPU specific behaviour, rather than tweaking
> control bits to hide the problem.
I'm simply matching the behavior of the kernel itself. The A bit is cleared
for v7 kernels and compilers only generate unaligned accesses for v7.
Without this the initial state of the A bit is undefined as a bootloader
could have cleared it already. We should document the required state or set
it to what we want.
Rob
arch/arm/boot/compressed/head.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index bc67cbf..b2e30b8 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -654,6 +654,7 @@ __armv7_mmu_cache_on:
#endif
mrc p15, 0, r0, c1, c0, 0 @ read control reg
bic r0, r0, #1 << 28 @ clear SCTLR.TRE
+ bic r0, r0, #1 << 1 @ clear SCTLR.A
orr r0, r0, #0x5000 @ I-cache enable, RR cache replacement
orr r0, r0, #0x003c @ write buffer
#ifdef CONFIG_MMU
--
1.7.9.5
^ permalink raw reply related
* [PATCH] pinctrl/nomadik: provide stubs for legacy Nomadik
From: Linus Walleij @ 2012-10-11 12:41 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
The compilation of the pinctrl driver failed on the legacy
Nomadik NHK8815 platform because it was not providing the PRCMU
interfaces needed to support the extended alternate functions
used by the ux500 series.
Solve this by providing some stubs for the legacy platform, to
avoid too much #ifdefs in the code per se. Theoretically this
actually allows the Nomadik and Ux500 to have a single kernel
image with support for the PRCM registers on the Ux500 (though
they have incompatible archs, but the spirit is there).
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-nomadik.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index fec9c30..f640f13 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -30,7 +30,20 @@
#include <linux/pinctrl/pinconf.h>
/* Since we request GPIOs from ourself */
#include <linux/pinctrl/consumer.h>
+/*
+ * For the U8500 archs, use the PRCMU register interface, for the older
+ * Nomadik, provide some stubs. The functions using these will only be
+ * called on the U8500 series.
+ */
+#ifdef CONFIG_ARCH_U8500
#include <linux/mfd/dbx500-prcmu.h>
+#else
+static inline u32 prcmu_read(unsigned int reg) {
+ return 0;
+}
+static inline void prcmu_write(unsigned int reg, u32 value) {}
+static inline void prcmu_write_masked(unsigned int reg, u32 mask, u32 value) {}
+#endif
#include <asm/mach/irq.h>
--
1.7.11.3
^ permalink raw reply related
* alignment faults in 3.6
From: Eric Dumazet @ 2012-10-11 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210111228.25995.arnd@arndb.de>
On Thu, 2012-10-11 at 12:28 +0000, Arnd Bergmann wrote:
>
> Rob Herring as the original reporter has dropped off the Cc list, adding
> him back.
>
> I assume that the calxeda xgmac driver is the culprit then. It uses
> netdev_alloc_skb() rather than netdev_alloc_skb_ip_align() in
> xgmac_rx_refill but it is not clear whether it does so intentionally
> or by accident.
Thanks Arnd
It seems an accident, since driver doesnt check skb->data alignment at
all (this can change with SLAB debug on/off)
It also incorrectly adds 64 bytes to bfsize, there is no need for this.
(or if its needed, a comment would be nice, because on prior kernels,
this makes skb->head allocations uses kmalloc-4096 instead of
kmalloc-2048 slab cache... With 3.7 its less an issue now we use order-3
pages to deliver fragments for rx skbs
So the following patch should fix the alignment, and makes driver uses
half memory than before for stable kernels
diff --git a/drivers/net/ethernet/calxeda/xgmac.c b/drivers/net/ethernet/calxeda/xgmac.c
index 16814b3..a895e18 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -671,7 +671,8 @@ static void xgmac_rx_refill(struct xgmac_priv *priv)
p = priv->dma_rx + entry;
if (priv->rx_skbuff[entry] == NULL) {
- skb = netdev_alloc_skb(priv->dev, priv->dma_buf_sz);
+ skb = netdev_alloc_skb_ip_align(priv->dev,
+ priv->dma_buf_sz);
if (unlikely(skb == NULL))
break;
@@ -703,7 +704,7 @@ static int xgmac_dma_desc_rings_init(struct net_device *dev)
/* Set the Buffer size according to the MTU;
* indeed, in case of jumbo we need to bump-up the buffer sizes.
*/
- bfsize = ALIGN(dev->mtu + ETH_HLEN + ETH_FCS_LEN + NET_IP_ALIGN + 64,
+ bfsize = ALIGN(dev->mtu + ETH_HLEN + ETH_FCS_LEN,
64);
netdev_dbg(priv->dev, "mtu [%d] bfsize [%d]\n", dev->mtu, bfsize);
^ permalink raw reply related
* [PATCH v2 04/13] clk: davinci - common clk driver initialization
From: Sekhar Nori @ 2012-10-11 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348683037-9705-5-git-send-email-m-karicheri2@ti.com>
Hi Murali,
I have given this patch a partial review. I suspect this patch will
change much based on the comment I gave for 9/13.
On 9/26/2012 11:40 PM, Murali Karicheri wrote:
> This is the common clk driver initialization function for DaVinci
> SoCs and other SoCs that uses similar hardware architecture.
> Different clocks present in the SoC are passed to this function
> using a clk table and this function initialize the various drivers.
> Existing driver such as clk-fixed-rate, clk-divider, clk-mux and
> DaVinci specific clk drivers are initialized by this function.
> Also adds clock lookup for shared clocks used by various drivers.
> davinci-clock.h declares the various structures used for defining
> the DaVinci clocks.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>
> diff --git a/drivers/clk/davinci/davinci-clock.c b/drivers/clk/davinci/davinci-clock.c
> new file mode 100644
> index 0000000..cbd5201
> --- /dev/null
> +++ b/drivers/clk/davinci/davinci-clock.c
> @@ -0,0 +1,232 @@
> +/*
> + * Clock initialization code for DaVinci devices
> + *
> + * Copyright (C) 2006-2012 Texas Instruments.
> + * Copyright (C) 2008-2009 Deep Root Systems, LLC
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include <linux/init.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
> +#include <linux/platform_data/clk-davinci-pll.h>
> +#include <linux/platform_data/clk-keystone-pll.h>
> +#include <linux/platform_data/clk-davinci-psc.h>
> +#include <linux/platform_data/davinci-clock.h>
Needs to be kept sorted.
> +
> +static DEFINE_SPINLOCK(_lock);
No need of the underscore prefix.
> +
> +struct clk *davinci_lookup_clk(struct davinci_clk_lookup *clocks,
> + const char *con_id)
> +{
> + struct davinci_clk_lookup *c;
> +
> + for (c = clocks; c->_clk; c++) {
> + if (c->con_id && !strcmp(c->con_id, con_id))
> + return c->clk;
> + }
> + return NULL;
> +}
This is a global function, but it is not exported in a header file.
Should this be static instead?
> +
> +#ifdef CONFIG_CLK_DAVINCI_PLL
> +static void register_davinci_pll_clk(struct davinci_clk_lookup *c,
> + struct clk_davinci_pll_data *pll_data)
> +{
> +
> + WARN_ON(!pll_data->phy_pllm);
I don't think it is right to check for zero physical address. It is not
true on any of the DaVinci platforms, but it is possible to design
hardware where physical address of the PLL multipler is zero.
> + pll_data->pllm = ioremap(pll_data->phy_pllm, 4);
> + WARN_ON(!pll_data->pllm);
Along with the warning for users, you also need to return an -ENOMEM so
callers are aware? Or you can skip the WARN_ON and simply return -ENOMEM.
> + if (pll_data->phy_prediv) {
> + pll_data->prediv = ioremap(pll_data->phy_prediv, 4);
> + WARN_ON(!pll_data->prediv);
> + }
> + if (pll_data->phy_postdiv) {
> + pll_data->postdiv = ioremap(pll_data->phy_postdiv, 4);
> + WARN_ON(!pll_data->postdiv);
> + }
Comments above apply here as well.
> + c->clk = clk_register_davinci_pll(NULL,
> + c->_clk->name, c->_clk->parent->name,
> + pll_data);
> +}
> +#else
> +static void register_davinci_pll_clk(struct davinci_clk_lookup *c,
> + struct clk_davinci_pll_data *pll_data)
> +{
> + return;
> +}
> +#endif
> +
> +#ifdef CONFIG_CLK_KEYSTONE_PLL
> +static void register_keystone_pll_clk(struct davinci_clk_lookup *c,
> + struct clk_keystone_pll_data *pll_data)
> +{
> + WARN_ON(!pll_data->phy_pllm);
> + pll_data->pllm = ioremap(pll_data->phy_pllm, 4);
> + WARN_ON(!pll_data->pllm);
> + WARN_ON(!pll_data->phy_main_pll_ctl0);
> + pll_data->main_pll_ctl0 =
> + ioremap(pll_data->phy_main_pll_ctl0, 4);
> + WARN_ON(!pll_data->main_pll_ctl0);
> + c->clk = clk_register_keystone_pll(NULL,
> + c->_clk->name, c->_clk->parent->name,
> + pll_data);
> +}
> +#else
> +static void register_keystone_pll_clk(struct davinci_clk_lookup *c,
> + struct clk_keystone_pll_data *pll_data)
> +{
> + return;
> +}
> +#endif
> +
> +int __init davinci_common_clk_init(struct davinci_clk_lookup *clocks,
> + struct davinci_dev_lookup *dev_clk_lookups,
> + u8 num_gpscs, u32 *psc_bases)
psc_bases should be of type phys_add_t.
> +{
> + void __iomem **base = NULL, *reg;
> + struct davinci_clk_lookup *c;
> + struct davinci_clk *_clk;
> + unsigned long rate;
> + int i, skip;
> +
> + WARN_ON(!num_gpscs);
Need to return error if this is hit. In general revisit the need to
return an error wherever you have WARN_ON().
Thanks,
Sekhar
^ permalink raw reply
* alignment faults in 3.6
From: Arnd Bergmann @ 2012-10-11 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349952574.21172.8604.camel@edumazet-glaptop>
On Thursday 11 October 2012, Eric Dumazet wrote:
> On Thu, 2012-10-11 at 11:32 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 11, 2012 at 12:22:06PM +0200, Eric Dumazet wrote:
> > > I took a look, and I dont see why/how gcc could use a ldm instruction
> > >
> > > Doing so assumed the alignment of the structure was 8 bytes, but its
> > > not.
> > >
> > > Networking stack mandates that IP headers are aligned on 4 bytes
> > > boundaries, not 8 bytes.
> >
> > Err, no. ldm is "load multiple" not "load double". It loads multiple
> > 32-bit registers, and its requirement for non-faulting behaviour is for
> > the pointer to be 4 byte aligned. However, "load double" requires 8
> > byte alignment.
>
> So if you have an alignment fault, thats because IP header is not
> aligned on 4 bytes ?
>
> If so a driver is buggy and must be fixed.
>
> Please send us full stack trace
Rob Herring as the original reporter has dropped off the Cc list, adding
him back.
I assume that the calxeda xgmac driver is the culprit then. It uses
netdev_alloc_skb() rather than netdev_alloc_skb_ip_align() in
xgmac_rx_refill but it is not clear whether it does so intentionally
or by accident.
Arnd
^ permalink raw reply
* [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers
From: Sekhar Nori @ 2012-10-11 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348683037-9705-10-git-send-email-m-karicheri2@ti.com>
Murali,
On 9/26/2012 11:40 PM, Murali Karicheri wrote:
> The clock tree for dm644x is defined using the new structure davinci_clk.
> The SoC specific code re-uses clk-fixed-rate, clk-divider and clk-mux
> drivers in addition to the davinci specific clk drivers, clk-davinci-pll
> and clk-davinci-psc. Macros are defined to define the various clocks in
> the SoC.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
You have chosen to keep all clock related data in platform files while
using the common clock framework to provide just the infrastructure. If
you look at how mxs and spear have been migrated, they have migrated the
soc specific clock data to drivers/clk as well. See
"drivers/clk/spear/spear3xx_clock.c" or "drivers/clk/mxs/clk-imx23.c". I
feel the latter way is better and I also think it will simplify some of
the look-up infrastructure you had to build. This will also help some
real code reduction from arch/arm/mach-davinci/.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] pinctrl/nomadik: support other alternate-C functions
From: Arnd Bergmann @ 2012-10-11 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349185041-1810-1-git-send-email-linus.walleij@stericsson.com>
On Tuesday 02 October 2012, Linus Walleij wrote:
> --- a/drivers/pinctrl/pinctrl-nomadik.c
> +++ b/drivers/pinctrl/pinctrl-nomadik.c
> @@ -30,6 +30,7 @@
> #include <linux/pinctrl/pinconf.h>
> /* Since we request GPIOs from ourself */
> #include <linux/pinctrl/consumer.h>
> +#include <linux/mfd/dbx500-prcmu.h>
>
> #include <asm/mach/irq.h>
>
This patch just showed up in linux-next and caused this error
when building nhk8815_defconfig:
In file included from /home/arnd/linux-arm/drivers/pinctrl/pinctrl-nomadik.c:33:0:
/home/arnd/linux-arm/include/linux/mfd/dbx500-prcmu.h:459:90: error: redefinition of 'prcmu_abb_read'
/home/arnd/linux-arm/include/linux/mfd/db8500-prcmu.h:673:90: note: previous definition of 'prcmu_abb_read' was here
/home/arnd/linux-arm/include/linux/mfd/dbx500-prcmu.h:464:90: error: redefinition of 'prcmu_abb_write'
/home/arnd/linux-arm/include/linux/mfd/db8500-prcmu.h:678:90: note: previous definition of 'prcmu_abb_write' was here
/home/arnd/linux-arm/include/linux/mfd/dbx500-prcmu.h:475:90: error: redefinition of 'prcmu_config_clkout'
/home/arnd/linux-arm/include/linux/mfd/db8500-prcmu.h:643:90: note: previous definition of 'prcmu_config_clkout' was here
/home/arnd/linux-arm/include/linux/mfd/dbx500-prcmu.h:537:90: error: redefinition of 'prcmu_ac_wake_req'
/home/arnd/linux-arm/include/linux/mfd/db8500-prcmu.h:683:90: note: previous definition of 'prcmu_ac_wake_req' was here
/home/arnd/linux-arm/include/linux/mfd/dbx500-prcmu.h:542:91: error: redefinition of 'prcmu_ac_sleep_req'
/home/arnd/linux-arm/include/linux/mfd/db8500-prcmu.h:688:91: note: previous definition of 'prcmu_ac_sleep_req' was here
make[2]: *** [drivers/pinctrl/pinctrl-nomadik.o] Error 1
make[1]: *** [drivers/pinctrl/] Error 2
make: *** [sub-make] Error 2
Arnd
^ permalink raw reply
* alignment faults in 3.6
From: Eric Dumazet @ 2012-10-11 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349956456.21172.8820.camel@edumazet-glaptop>
On Thu, 2012-10-11 at 13:54 +0200, Eric Dumazet wrote:
> On Thu, 2012-10-11 at 13:47 +0200, Maxime Bizon wrote:
> > On Thu, 2012-10-11 at 13:28 +0200, Eric Dumazet wrote:
> >
> > > You probably are aware that a driver can use :
> > >
> > > - a fragment to hold the frame given by the hardware, with whatever
> > > alignment is needed by the hardware.
> > >
> > > Then allocate an skb with enough room (128 bytes) to pull the headers as
> > > needed later.
> > >
> > > skb = netdev_alloc_skb_ip_align(dev, 128);
> >
> > What happen at tx time, supposing that same hardware cannot do SG ?
> >
> > Aren't we going to memcpy the data into the head ?
> >
>
> Of course, if you use a forwarding setup, and the tx driver is not SG
> capable, performance will be bad (You have to copy the data into a
> single skb (linearize the skb))
By the way, if said driver also has alignments issues, it will probably
copy the packet given by the stack. (Think you added an IPIP
encapsulation)
It would be better for such driver to still pretend it can do SG,
and it does the copy itself, avoiding the prior copies in core stack.
^ permalink raw reply
* [PATCH v4 1/8] dt: add helper inline for retrieving timeout-sec property
From: Fabio Porcedda @ 2012-10-11 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5075865C.3010606@gmail.com>
On Wed, Oct 10, 2012 at 4:29 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 10/09/2012 07:04 AM, Fabio Porcedda wrote:
>> The first user of this function is the watchdog framework.
>
> Who is the 2nd user because I don't see any others. I don't see this
> being a widely used property.
Hi Rob, thanks for reviewing.
There is only one use of this function in my patchset.
I added this function after Jean-Christophe repeatedly suggested to add it.
On Fri, Oct 5, 2012 at 1:16 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> why I bother to comment
> *make this of generic* this is not watchdog specific other driver can use it
Maybe the idea was to have the helper ready when the dt support it's
added to a drivers that use a "timeout" parameter.
If it's for better i can just get rid of this function.
I don't mind.
Best regards
>
>>
>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> ---
>> include/linux/of.h | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index 72843b7..5870818 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -470,4 +470,15 @@ static inline int of_property_read_u32(const struct device_node *np,
>> return of_property_read_u32_array(np, propname, out_value, 1);
>> }
>>
>> +/**
>> + * of_get_timeout_sec() - Helper to read the timeout_sec property
>> + * @np: device node from which the property value is to be read.
>> + * @timeout: adress of the output value
>> + */
>> +static inline int of_get_timeout_sec(const struct device_node *np,
>> + u32 *timeout)
>> +{
>> + return of_property_read_u32(np, "timeout-sec", timeout);
>> +}
>> +
>> #endif /* _LINUX_OF_H */
>>
>
--
Fabio Porcedda
^ permalink raw reply
* alignment faults in 3.6
From: Eric Dumazet @ 2012-10-11 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349956055.1232.9.camel@sakura.staff.proxad.net>
On Thu, 2012-10-11 at 13:47 +0200, Maxime Bizon wrote:
> On Thu, 2012-10-11 at 13:28 +0200, Eric Dumazet wrote:
>
> > You probably are aware that a driver can use :
> >
> > - a fragment to hold the frame given by the hardware, with whatever
> > alignment is needed by the hardware.
> >
> > Then allocate an skb with enough room (128 bytes) to pull the headers as
> > needed later.
> >
> > skb = netdev_alloc_skb_ip_align(dev, 128);
>
> What happen at tx time, supposing that same hardware cannot do SG ?
>
> Aren't we going to memcpy the data into the head ?
>
Of course, if you use a forwarding setup, and the tx driver is not SG
capable, performance will be bad (You have to copy the data into a
single skb (linearize the skb))
But in 2012, having to use hardware without SG for a router sounds a bad
joke (if cpu speed is _also_ too low)
Adding get_unaligned() everywhere in linux network stacks is not an
option.
We actually want to be able to read the code and fix the bugs, not only
run it on a cheap low end router.
^ permalink raw reply
* alignment faults in 3.6
From: Maxime Bizon @ 2012-10-11 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349954899.21172.8728.camel@edumazet-glaptop>
On Thu, 2012-10-11 at 13:28 +0200, Eric Dumazet wrote:
> You probably are aware that a driver can use :
>
> - a fragment to hold the frame given by the hardware, with whatever
> alignment is needed by the hardware.
>
> Then allocate an skb with enough room (128 bytes) to pull the headers as
> needed later.
>
> skb = netdev_alloc_skb_ip_align(dev, 128);
What happen at tx time, supposing that same hardware cannot do SG ?
Aren't we going to memcpy the data into the head ?
--
Maxime
^ permalink raw reply
* [PATCH 0/4] OMAP-GPMC generic timing migration
From: Daniel Mack @ 2012-10-11 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1349450723.git.afzal@ti.com>
Hi,
On 05.10.2012 18:00, Afzal Mohammed wrote:
> This series provides a generic gpmc timing calculation routine. There
> were three peripherals (OneNAND, tusb6010, smc91x) using custom timing
> calculations, they are migrated to use the generic timing calculation.
>
> Such a generic routine would help create a driver out of gpmc platform
> code, which would be peripheral agnostic and thus lead to DT finally.
> Input to generic timing calculation routine would be gpmc peripheral
> timings, output - translated timings that gpmc can understand. Later,
> to DT'ify, gpmc peripheral timings could be passed through DT. Input
> timings that has been used here are selected such that it represents
> those that are present in peripheral timing datasheets.
Admittedly, I lost track on the multiple GPMC series here, and they also
cause major merge conflicts with Linus' current master branch.
Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
would like to augment this to make GPMC attached NAND probable in DT, in
case this is still an open topic.
Thanks for you hard work,
Daniel
> This series has been created by pulling out last 4 patches in v7
> of the series,
> "OMAP-GPMC: generic time calc, prepare for driver"
> This was done to have easy path for common zImage gpmc cleanup patches.
>
> Proposed generic routine has been tested on OneNAND (async) on
> OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
> local patch were used to test). For other cases of custom timing
> calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
> calculation routine was verified by simulating on OMAP3EVM.
>
> This series is available
> @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing-v1
> and is based on
> linux-next (next-20121005)
> and is dependent on
> http://marc.info/?l=linux-omap&m=134945131602622&w=2
> http://marc.info/?l=linux-omap&m=134945239306131&w=2
>
> This series as such is only the first version, but these patches has
> already undergone one change before being made as this series. The
> change was in using ps instead of ns to prevent rounding errors.
> Also along with this series documentation has been improved.
>
> Regards
> Afzal
>
>
> Afzal Mohammed (4):
> ARM: OMAP2+: gpmc: generic timing calculation
> ARM: OMAP2+: onenand: generic timing calculation
> ARM: OMAP2+: smc91x: generic timing calculation
> ARM: OMAP2+: tusb6010: generic timing calculation
>
> Documentation/bus-devices/ti-gpmc.txt | 122 +++++++++++++
> arch/arm/mach-omap2/gpmc-onenand.c | 124 +++++--------
> arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++---
> arch/arm/mach-omap2/gpmc.c | 325 ++++++++++++++++++++++++++++++++++
> arch/arm/mach-omap2/gpmc.h | 102 ++++++++---
> arch/arm/mach-omap2/usb-tusb6010.c | 182 +++++--------------
> 6 files changed, 633 insertions(+), 265 deletions(-)
> create mode 100644 Documentation/bus-devices/ti-gpmc.txt
>
^ permalink raw reply
* alignment faults in 3.6
From: Eric Dumazet @ 2012-10-11 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349952970.1232.5.camel@sakura.staff.proxad.net>
On Thu, 2012-10-11 at 12:56 +0200, Maxime Bizon wrote:
> On Thu, 2012-10-11 at 12:49 +0200, Eric Dumazet wrote:
>
>
> > So if you have an alignment fault, thats because IP header is not
> > aligned on 4 bytes ?
> >
> > If so a driver is buggy and must be fixed.
>
> So a driver that does not align the ip header is buggy ?
>
exactly.
> I always thought it was ok not to do so (with a potential performance
> penalty).
>
Apparently not for some arches.
> I have some MIPS hardware that is not able to DMA on anything but 32bits
> aligned addresses (bcm63xx). I tried once to add a memcpy instead of
> taking unaligned faults and the result was *much slower* on a ipv4
> forwarding test (which is what the hardware is used for).
>
You probably are aware that a driver can use :
- a fragment to hold the frame given by the hardware, with whatever
alignment is needed by the hardware.
Then allocate an skb with enough room (128 bytes) to pull the headers as
needed later.
skb = netdev_alloc_skb_ip_align(dev, 128);
Attach the fragment to the skb, and feed stack with this skb.
(pull the ethernet header before calling eth_type_trans()
Most modern drivers exactly use this strategy and get nice performance.
Of course, if hardware doesnt need a strange alignment, we can avoid the
fragment and directly use
skb = netdev_alloc_skb_ip_align(dev, 1536);
So all drivers can be fixed if needed.
^ permalink raw reply
* [PATCH 7/7] ARM: tegra30: cpuidle: add LP2 driver for CPU0
From: Joseph Lo @ 2012-10-11 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5074AA0E.2080508@wwwdotorg.org>
On Wed, 2012-10-10 at 06:49 +0800, Stephen Warren wrote:
> On 10/08/2012 04:26 AM, Joseph Lo wrote:
> > The cpuidle LP2 is a power gating idle mode. It support power gating
> > vdd_cpu rail after all cpu cores in LP2. For Tegra30, the CPU0 must
> > be last one to go into LP2. We need to take care and make sure whole
> > secondary CPUs were in LP2 by checking CPU and power gate status.
> > After that, the CPU0 can go into LP2 safely. Then power gating the
> > CPU rail.
>
> > diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
>
> > +static bool tegra30_idle_enter_lp2_cpu_0(struct cpuidle_device *dev,
> > + struct cpuidle_driver *drv,
> > + int index)
> > +{
> > + struct cpuidle_state *state = &drv->states[index];
> > + u32 cpu_on_time = state->exit_latency;
> > + u32 cpu_off_time = state->target_residency - state->exit_latency;
> > +
> > + if (num_online_cpus() > 1 && !tegra_cpu_rail_off_ready()) {
>
> Should that be || not &&?
>
> Isn't the "num_online_cpus() > 1" condition effectively checked at the
> call site, i.e. in tegra30_idle_lp2() below via the if (last_cpu) check?
>
Should be "&&" here.
Because we need to check if there are still multi CPUs online, then we
need to make sure all the secondary CPUs be power gated first. After all
the secondary CPUs been power gated, the CPU0 could go into LP2 and the
CPU rail could be shut off.
If all the secondary CPUs been hot plugged, then the "num_online_cpus()
>1" would be always false. Then the CPU0 can go into LP2 directly.
So it was used to check are there multi cpus online or not? It's
difference with the last_cpu check below. The last_cpu was used to check
all the CPUs were in LP2 process or not. If the CPU0 is the last one
went into LP2 process, then it would be true.
So the point here is. We can avoid to check the power status of the
secodarys CPUs if they be unplugged.
> > @@ -85,16 +108,22 @@ static int __cpuinit tegra30_idle_lp2(struct cpuidle_device *dev,
> > int index)
> > {
> > bool entered_lp2 = false;
> > + bool last_cpu;
> >
> > local_fiq_disable();
> >
> > + last_cpu = tegra_set_cpu_in_lp2(dev->cpu);
> > + if (dev->cpu == 0) {
> > + if (last_cpu)
> > + entered_lp2 = tegra30_idle_enter_lp2_cpu_0(dev, drv,
> > + index);
> > + else
> > + cpu_do_idle();
> > + } else {
> > entered_lp2 = tegra30_idle_enter_lp2_cpu_n(dev, drv, index);
> > + }
>
> Hmm. That means that if the last CPU to enter LP2 is e.g. CPU1, then
> even though all CPUs are now in LP2, the complex as a whole doesn't
> enter LP2. Is there a way to make the cluster as a whole enter LP2 in
> this case? Isn't that what coupled cpuidle is for?
>
It may look like the coupled cpuidle can satisfy the usage here. But it
didn't. Please check the criteria of coupled cpuidle.
/*
* To use coupled cpuidle states, a cpuidle driver must:
*
* Set struct cpuidle_device.coupled_cpus to the mask of all
* coupled cpus, usually the same as cpu_possible_mask if all cpus
* are part of the same cluster. The coupled_cpus mask must be
* set in the struct cpuidle_device for each cpu.
*
* Set struct cpuidle_device.safe_state to a state that is not a
* coupled state. This is usually WFI.
*
* Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
* state that affects multiple cpus.
*
* Provide a struct cpuidle_state.enter function for each state
* that affects multiple cpus. This function is guaranteed to be
* called on all cpus at approximately the same time. The driver
* should ensure that the cpus all abort together if any cpu tries
* to abort once the function is called. The function should return
* with interrupts still disabled.
*/
The Tegra30 can support the secondary CPUs go into LP2 (power-gate)
independently. The limitation of the CPU0 is the CPU0 must be the last
one to go into LP2 to shut off CPU rail.
It also no need for every CPU to leave LP2 at the same time. The CPU0
would be always the first one that woken up from LP2. But all the other
secondary CPUs can still keep in LP2. One of the secondary CPUs can also
be woken up alone, if the CPU0 already up.
> > diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
>
> > +static void set_power_timers(unsigned long us_on, unsigned long us_off)
>
> > + if (tegra_pclk == NULL) {
> > + tegra_pclk = clk_get_sys(NULL, "pclk");
> > + if (IS_ERR(tegra_pclk)) {
> > + /*
> > + * pclk not been init or not exist.
> > + * Use sclk to take the place of it.
> > + * The default setting was pclk=sclk.
> > + */
> > + tegra_pclk = clk_get_sys(NULL, "sclk");
> > + }
> > + }
>
> That's a little odd. Surely the HW has pclk or it doesn't? Why use
> different clocks at different times for what is apparently the same thing?
It just because the "pclk" is not available on the Tegra30's clock
framework but Tegra20 right now.
Thanks,
Joseph
^ permalink raw reply
* [PATCH 1/1] mtd: st fsmc_nand: pass the ale and cmd resource via resource
From: Artem Bityutskiy @ 2012-10-11 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349356456-13371-1-git-send-email-plagnioj@jcrosoft.com>
On Thu, 2012-10-04 at 15:14 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> Do not use the platform_data to pass resource and be smart in the drivers.
> Just pass it via resource
>
> Switch to devm_request_and_ioremap at the sametime
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Pushed to l2-mtd.git, thanks!
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121011/85228016/attachment.sig>
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Russell King - ARM Linux @ 2012-10-11 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50769D8C.8030401@ti.com>
On Thu, Oct 11, 2012 at 03:51:00PM +0530, Sourav wrote:
> True. I missed that point while doing the testing. Sorry for that.
> I further looked into it and saw some two options in my minicom
> settings(Hardware Flow Control/ Software Flow Control) Which I am
> thinking are the ones used to enable the flow control ? and they are
> both set to NO.
>
> I already enable software flow control and did the testing on beagle,
> where things are working fine
> after off mode.
> But if I enable hardware flow control, the teraterm does not allow me to
> load my fs and uImage from mmc.
> If you have any pointers on how to test hardware flow control, I will
> like to do that on my beagle board.
Okay, it sounds like I need to do a teach-in on flow control...
First, hardware flow control. Hardware flow control is operated by two
signals: RTS and CTS.
In conventional setups, CTS is an input to the transmitter, and controls
whether the transmitter may start the transmission of a new character.
If CTS is deasserted, the transmitter will stop after the completion of
the previous character. When hardware flow control is disabled, the
transmitter ignores this signal.
RTS is an output, and is generally used to control the remote transmitter.
(There are setups where RTS means something else, but the kernel doesn't
support other schemes directly.) RTS is asserted when either hardware
flow control is disabled, or there is sufficient space to receive more
characters from the remote end.
This is a symetrical setup, so that two UARTs connected together using
this scheme will have the RTS of one connected to the CTS of the other.
This way, each can signal whether characters should be transmitted.
So, in minicom, when hardware flow control is disabled, your hosts
transmitter will ignore the state of the CTS signal, and will hold its
RTS asserted.
If hardware flow control in minicom is enabled, then that tells the
kernel (and possibly hardware) to take note of the CTS signal, and pause
transmission when CTS is deasserted. It will also cause the RTS signal
to be manipulated according to available buffer space on the receive
side.
Obviously minicom will try to ensure that any characters received are
displayed as quickly as possible, so it's unlikely that the receive side
will fill up.
When you're logged into a system via a serial line, the hardware flow
control state is controlled by the CRTSCTS termios flag. That can be
seen and manipulated by stty. stty -a to see all flags. stty -crtscts
to disable, stty crtscts to enable.
Now, for software flow control. It operates in the same way as above,
but instead of a hardware signal reporting the state, characters are
embedded into the stream.
In normal situations, these characters are the standard ^Q (noramlly XON)
and ^S (XOFF) characters. You'll find that works in gnome-terminals,
xterms, and many places because it's part of the standard terminal
interface. You can type these characters into minicom with or without
software flow control disabled; it just passes them through unmodified.
When software flow control is enabled, and the tty receive buffers start
to fill up, the kernel will queue a high-priority XOFF character for the
UART to transmit to the remote end. Once the tty buffers have emptied
sufficiently, it will queue a high-priority XON character. If software
flow control is disabled, it will ignore this.
When hardware assisted software flow control is enabled, this will be
done by the hardware itself in response to the UART FIFO filling up and
emptying.
For the target, software flow control has more configuration options:
ixon: controls whether the transmitter starts/stops on reception
of xon/xoff characters
ixoff: controls the generation of xon/xoff characters
ixany: permits any received character (including xon) to restart
transmission
stop <char>: sets the xoff character to the specified character
start <char>: sets the xon character to the specified character
xon and xoff default to ^Q and ^S respectively, there's no need to
'initialize' them prior to use. So, to enable software flow control
(which is probably already enabled on the target):
stty ixon ixoff
and then you can type ^S and ^Q into minicom to stop/start the target's
transmit output.
Finally, to make the target's input buffer fill up, arrange for the
target not to read from the controlling tty at all. sleep 120 will
do that for two minutes, after which the input will be gobbled up by
the shell (which it'll try to interpret as commands.) So, probably
better to do:
sleep 120; echo Finished; cat >/dev/null
instead, and then send lots of data, and check whether the transmission
stops, whether the right xon/xoff characters are transmitted, and whether
any overrun errors are reported.
Going the other way, you can suspend minicom (^a z) and then arrange for
the target to send lots of data, and again check what happens.
There's a gotcha there though: with standard 8250-based serial ports,
we have /proc/tty/driver/serial which gives easy access to the port
statistics. With USB stuff, those statistics are not available, so it
becomes much harder to test. You have to arrange for the target to send
a known pattern, and find some way to check at the host end that it was
correctly received, including over the flow control events.
No characters should be lost when flow control is being used; after
all, that's the whole point of the facility.
^ permalink raw reply
* [PATCH 1/2] ARM: nomadik: switch over to using the FSMC driver
From: Artem Bityutskiy @ 2012-10-11 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349335709-13399-1-git-send-email-linus.walleij@linaro.org>
On Thu, 2012-10-04 at 09:28 +0200, Linus Walleij wrote:
> The Nomadik NAND driver is really just a subset of the existing
> FSMC driver, so let's switch over to using that driver instead,
> since it handles more variants of this chip. The callbacks for
> setting up the chip is doing stuff now handled by the FSMC
> driver.
>
> Cc: Alessandro Rubini <rubini@unipv.it>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pushed both to l2-mtd.git, thanks!
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121011/fdb275c4/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 01/13] clk: davinci - add Main PLL clock driver
From: Sekhar Nori @ 2012-10-11 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348683037-9705-2-git-send-email-m-karicheri2@ti.com>
On 9/26/2012 11:40 PM, Murali Karicheri wrote:
> +struct clk_davinci_pll_data {
> + /* physical addresses set by platform code */
> + u32 phy_pllm;
> + /* if PLL has a prediv register this should be non zero */
> + u32 phy_prediv;
> + /* if PLL has a postdiv register this should be non zero */
> + u32 phy_postdiv;
"phys" is typically used for physical addresses. I couldn't immediately
related this to physical address when I looked at this variable outside
of this file.
Also, physical addresses should be of type phys_addr_t.
> + /* mapped addresses. should be initialized by */
> + void __iomem *pllm;
> + void __iomem *prediv;
> + void __iomem *postdiv;
> + u32 pllm_mask;
> + u32 prediv_mask;
> + u32 postdiv_mask;
> + u32 num;
Wondering what num is for? May be it will be clear once you document the
complete structure as Linus suggested.
> + /* framework flags */
> + u32 flags;
> + /* pll flags */
> + u32 pll_flags;
> + /* use this value for prediv */
> + u32 fixed_prediv;
Why is this called "fixed". Isn't this the pre-divider value that user
can configure? Also, shouldn't there be a post-divider value that you
need as well.
> + /* multiply PLLM by this factor. By default most SOC set this to zero
> + * that translates to a multiplier of 1 and incrementer of 1.
> + * To override default, set this factor
> + */
> + u32 pllm_multiplier;
'm' in pllm stands for multiplier. So, instead of calling it
"pllm_multiplier", call it "pllm_val" instead?
Sorry about late comments on this, looks like I missed looking at this
structure altogether yesterday and had to go back to this only when I
tried understanding whats going on in 4/13
Thanks,
Sekhar
^ 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