* [Patch v2 3/4] ASoC: atmel-ssc-dai: register platform from DAIs
From: Mark Brown @ 2012-11-02 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5093312D.4070408@atmel.com>
On Fri, Nov 02, 2012 at 10:34:21AM +0800, Bo Shen wrote:
> On 11/1/2012 22:43, Mark Brown wrote:
> >On Wed, Oct 31, 2012 at 03:26:59PM +0800, Bo Shen wrote:
> >>+dai: dai {
> >>+ compatible = "atmel,atmel-ssc-dai";
> >>+ atmel,dai-master = <&ssc0>;
> >>+};
> >This seems to be a purely virtual device which remaps the SSC onto the
> >Linux audio subsystem? If that is the case then it shouldn't appear in
> >the device tree,
> Yes. This is a purely virtual device. I add this as to the following reason.
> In our case, the ssc can connect to audio codec, DAC and other
> devices. In order to avoid duplicate the code, so keep ssc as a
> library, register it directly in Linux and use remap method to let
> it work onto other different subsystem.
Your quote appears to have deleted the bit of my mail where I told you
how to fix this. Is there something unclear in my suggestion that the
machine driver directly reference the SSC node?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121102/d8cbe679/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] ARM: OMAP: Remove NEED_MACH_GPIO_H
From: Mark Brown @ 2012-11-02 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121101224823.2103.24591.stgit@muffinssi.local>
On Thu, Nov 01, 2012 at 03:48:23PM -0700, Tony Lindgren wrote:
> Omap no longer needs this option, mach/gpio.h is
> empty.
>
> Also remove mach/irqs.h from gpio-omap.h and
> include it directly from the related omap1
> gpio init files.
>
> Otherwise omap2+ build fails for MULTI_PLATFORM.
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121102/00a04e77/attachment-0001.sig>
^ permalink raw reply
* [PATCH 5/8] ARM: zynq: add COMMON_CLK support
From: Lars-Peter Clausen @ 2012-11-02 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121102133850.GO5190@beefymiracle.amer.corp.natinst.com>
On 11/02/2012 02:38 PM, Josh Cartwright wrote:
> Thanks for the review.
>
> On Fri, Nov 02, 2012 at 10:33:44AM +0100, Lars-Peter Clausen wrote:
>> On 10/31/2012 07:58 PM, Josh Cartwright wrote:
>>> [...]
>>> +#define PERIPH_CLK_CTRL_SRC(x) (periph_clk_parent_map[((x)&3)>>4])
>>> +#define PERIPH_CLK_CTRL_DIV(x) (((x)&0x3F00)>>8)
>>
>> A few more spaces wouldn't hurt ;)
>
> Okay, sure.
>
>>> [...]
>>> +static void __init zynq_periph_clk_setup(struct device_node *np)
>>> +{
>>> + struct zynq_periph_clk *periph;
>>> + const char *parent_names[3];
>>> + struct clk_init_data init;
>>> + struct clk *clk;
>>> + int err;
>>> + u32 reg;
>>> + int i;
>>> +
>>> + err = of_property_read_u32(np, "reg", ®);
>>> + WARN_ON(err);
>>
>> Shouldn't the function abort if a error happens somewhere? Continuing here
>> will lead to undefined behavior. Same is probably true for the other WARN_ONs.
>
> The way I see it is: the kernel is will be left in a bad state in the
> case of any failure, regardless of if we bail out or continue. AFAICT,
> there is no clean way to recover from a failure this early.
>
> Given that, it seems simpler (albeit marginally so) just to continue; so
> that's what I chose to do. I'm not opposed to bailing out, just not
> convinced it does anything for us.
>
The issue with this approach is that, while you get a warning, unexpected
seemingly unrelated side-effects may happen later on. E.g. if no reg
property for the clock is specified the reg variable will be uninitialized
and contain whatever was on the stack before. The clock will be registered
nonetheless and the boot process continues. Now if the clock is enabled a
bit in a random register will be modified, which could result in strange and
abnormal behavior, which can be very hard to track down.
Also if for example just one clock has its reg property missing the system
will continue to boot if we bail out here. It is just that the peripherals
using that clock won't work. Which will certainly be easier to diagnose than
random abnormal behavior.
>>> +
>>> + periph = kzalloc(sizeof(*periph), GFP_KERNEL);
>>> + WARN_ON(!periph);
>>> +
>>> + periph->clk_ctrl = slcr_base + reg;
>>> + spin_lock_init(&periph->clkact_lock);
>>> +
>>> + init.name = np->name;
>>> + init.ops = &zynq_periph_clk_ops;
>>> + for (i = 0; i < ARRAY_SIZE(parent_names); i++)
>>> + parent_names[i] = of_clk_get_parent_name(np, i);
>>> + init.parent_names = parent_names;
>>> + init.num_parents = ARRAY_SIZE(parent_names);
>>> +
>>> + periph->hw.init = &init;
>>> +
>>> + clk = clk_register(NULL, &periph->hw);
>>> + WARN_ON(IS_ERR(clk));
>>> +
>>> + err = of_clk_add_provider(np, of_clk_src_simple_get, clk);
>>> + WARN_ON(err);
>>> +
>>> + for (i = 0; i < 2; i++) {
>>
>> Not all of the peripheral clock generators have two output clocks. I think
>> it makes sense to use the number entries in clock-output-names here.
>
> Yes, I agree. I'll also update the bindings documentation.
>
> Thanks again,
> Josh
^ permalink raw reply
* [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Richard Cochran @ 2012-11-02 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293EA09122@DBDE01.ent.ti.com>
On Fri, Nov 02, 2012 at 10:42:04AM +0000, N, Mugunthan V wrote:
>
> I saw those posts. The CPSW ip version changes tracks the internal IP
> changes and there is no possible way to track the offset changes. For
> example CPTS sub module offsets in DM814x and AM335x are different
> though the CPTS version is same in both IP versions. So keeping these
> offset in DT will make the same driver works directly with DT changes
> for future SoC.
But the CPSW versions are different, and the offsets could be
determined that way, couldn't they?
The TRM for the DM814x does not even make the distinction among
CPSW_SS, CPSW_PORT, CPSW_CPDMA, and so on. Instead, it places all of
the registers into one space called CPSW_3G.
So I agree with Benoit. Placing all of the offsets into DT seems like
over-engineering to me, unless you know of TI's plans to release a new
SoC with the same CPSW version but different register offsets.
Thanks,
Richard
^ permalink raw reply
* [PATCH v3 0/4] RFC: OMAP GPMC DT bindings
From: Daniel Mack @ 2012-11-02 15:25 UTC (permalink / raw)
To: linux-arm-kernel
This is a series of patches to support GPMC peripherals on OMAP boards.
Depends on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)
The only supported peripheral for now is NAND, but other types would be
easy to add.
Version 2 addresses details pointed out by Jon Hunter, Afzal Mohammed
and Rob Herring:
- add "reg" and "ti,hwmod" properties to Documentation
- use generic of_mtd functions and the property names defined by them,
namely "nand-bus-width" and "nand-ecc-mode"
- reduce the default register space size in the Documentation to 8K,
as found in the hwmod code
- switch to a DT layout based on ranges and address translation.
Although this property is not currently looked at as long as the
handling code still uses the runtime calculation methods, we now
have these values in the bindings, eventually allowing us to
switch the implementation with less pain.
Version 3 includes fixes pointed out by Jon Hunter:
- better documentation of the 'ranges' property to describe the
fact that it's representing the CS lines
- GPMC_CS_CONFIGx -> GPMC_CONFIGx in comments
- drop interrupt-parent from example bindings
- add of_node_put() at the end of the child iteration
Daniel Mack (4):
mtd: omap-nand: pass device_node in platform data
ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
ARM: OMAP: gpmc: don't create devices from initcall on DT
ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 76 +++++++++++
.../devicetree/bindings/mtd/gpmc-nand.txt | 60 +++++++++
arch/arm/mach-omap2/gpmc-nand.c | 2 +-
arch/arm/mach-omap2/gpmc.c | 148 +++++++++++++++++++++
drivers/mtd/nand/omap2.c | 4 +-
include/linux/platform_data/mtd-nand-omap2.h | 2 +
6 files changed, 290 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
--
1.7.11.7
^ permalink raw reply
* [PATCH v3 1/4] mtd: omap-nand: pass device_node in platform data
From: Daniel Mack @ 2012-11-02 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351869956-2787-1-git-send-email-zonque@gmail.com>
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by: Daniel Mack <zonque@gmail.com>
---
drivers/mtd/nand/omap2.c | 4 +++-
include/linux/platform_data/mtd-nand-omap2.h | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3282b15..a733f15 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1331,6 +1331,7 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
dma_cap_mask_t mask;
unsigned sig;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev->dev.platform_data;
if (pdata == NULL) {
@@ -1556,7 +1557,8 @@ static int __devinit omap_nand_probe(struct platform_device *pdev)
goto out_release_mem_region;
}
- mtd_device_parse_register(&info->mtd, NULL, NULL, pdata->parts,
+ ppdata.of_node = pdata->of_node;
+ mtd_device_parse_register(&info->mtd, NULL, &ppdata, pdata->parts,
pdata->nr_parts);
platform_set_drvdata(pdev, &info->mtd);
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index 24d32ca..5217d6e 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -60,6 +60,8 @@ struct omap_nand_platform_data {
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.11.7
^ permalink raw reply related
* [PATCH v3 2/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
From: Daniel Mack @ 2012-11-02 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351869956-2787-1-git-send-email-zonque@gmail.com>
Signed-off-by: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-omap2/gpmc-nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 8607735..c3616c6 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -92,7 +92,7 @@ static int omap2_nand_gpmc_retime(
static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* support only OMAP3 class */
- if (!cpu_is_omap34xx()) {
+ if (!cpu_is_omap34xx() && !soc_is_am33xx()) {
pr_err("BCH ecc is not supported on this CPU\n");
return 0;
}
--
1.7.11.7
^ permalink raw reply related
* [PATCH v3 3/4] ARM: OMAP: gpmc: don't create devices from initcall on DT
From: Daniel Mack @ 2012-11-02 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351869956-2787-1-git-send-email-zonque@gmail.com>
On DT driven boards, the gpmc node will match the driver. Hence, there's
no need to do that unconditionally from the initcall.
Signed-off-by: Daniel Mack <zonque@gmail.com>
---
arch/arm/mach-omap2/gpmc.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 60f1cce..1dcb30c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -844,6 +844,13 @@ static int __init omap_gpmc_init(void)
struct platform_device *pdev;
char *oh_name = "gpmc";
+ /*
+ * if the board boots up with a populated DT, do not
+ * manually add the device from this initcall
+ */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
oh = omap_hwmod_lookup(oh_name);
if (!oh) {
pr_err("Could not look up %s\n", oh_name);
--
1.7.11.7
^ permalink raw reply related
* [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-11-02 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351869956-2787-1-git-send-email-zonque@gmail.com>
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack <zonque@gmail.com>
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 76 +++++++++++
.../devicetree/bindings/mtd/gpmc-nand.txt | 60 +++++++++
arch/arm/mach-omap2/gpmc.c | 141 +++++++++++++++++++++
3 files changed, 277 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
new file mode 100644
index 0000000..4f4a602
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,76 @@
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+
+The actual devices are instantiated from the child nodes of a GPMC node.
+
+Required properties:
+
+ - compatible: Should be set to "ti,gpmc"
+ - reg: A resource specifier for the register space
+ (see the example below)
+ - ti,hwmods: Should be set to "ti,gpmc" until the DT transition is
+ completed.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells: Must be set to 1 to allow CS address passing
+ - ranges: Must be set up to reflect the memory layout with four
+ integer values for each chip-select line in use:
+
+ <cs-number> 0 <physical address of mapping> <size>
+
+ Note that this property is not currently parsed.
+ Calculated values derived from the contents of the
+ per-CS register GPMC_CONFIG7 (as set up by the
+ bootloader) are used. That will change in the future,
+ so be sure to fill the correct values here.
+
+Timing properties for child nodes. All are optional and default to 0.
+
+ - gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
+
+ Chip-select signal timings corresponding to GPMC_CONFIG2:
+ - gpmc,cs-on: Assertion time
+ - gpmc,cs-rd-off: Read deassertion time
+ - gpmc,cs-wr-off: Write deassertion time
+
+ ADV signal timings corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on: Assertion time
+ - gpmc,adv-rd-off: Read deassertion time
+ - gpmc,adv-wr-off: Write deassertion time
+
+ WE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,we-on: Assertion time
+ - gpmc,we-off: Deassertion time
+
+ OE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,oe-on: Assertion time
+ - gpmc,oe-off: Deassertion time
+
+ Access time and cycle time timings corresponding to GPMC_CONFIG5:
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access: Start-cycle to first data valid delay
+ - gpmc,rd-cycle: Total read cycle time
+ - gpmc,wr-cycle: Total write cycle time
+
+The following are only on OMAP3430:
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+
+
+Example for an AM33xx board:
+
+ gpmc: gpmc at 50000000 {
+ compatible = "ti,gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x2000>;
+ interrupts = <100>;
+
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
+
+ /* child nodes go here */
+ };
+
+
+
+
+
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 0000000..d78bf49
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,60 @@
+Device tree bindings for GPMC connected NANDs
+
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of "nand".
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For NAND specific properties such as ECC modes or bus width, please refer to
+Documentation/devicetree/bindings/mtd/nand.txt
+
+
+Required properties:
+
+ - reg: The CS line the peripheral is connected to
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an AM33xx board:
+
+ gpmc: gpmc at 50000000 {
+ compatible = "ti,gpmc";
+ ti,hwmods = "gpmc";
+ reg = <0x50000000 0x1000000>;
+ interrupts = <100>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
+
+ nand at 0,0 {
+ reg = <0 0 0>; /* CS0, offset 0 */
+ nand-bus-width = <16>;
+ nand-ecc-mode = "none";
+
+ gpmc,sync-clk = <0>;
+ gpmc,cs-on = <0>;
+ gpmc,cs-rd-off = <36>;
+ gpmc,cs-wr-off = <36>;
+ gpmc,adv-on = <6>;
+ gpmc,adv-rd-off = <24>;
+ gpmc,adv-wr-off = <36>;
+ gpmc,we-off = <30>;
+ gpmc,oe-off = <48>;
+ gpmc,access = <54>;
+ gpmc,rd-cycle = <72>;
+ gpmc,wr-cycle = <72>;
+ gpmc,wr-access = <30>;
+ gpmc,wr-data-mux-bus = <0>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* partitions go here */
+ };
+ };
+
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1dcb30c..7ebe4fb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -25,6 +25,10 @@
#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_mtd.h>
+#include <linux/of_device.h>
+#include <linux/mtd/nand.h>
#include <linux/platform_data/mtd-nand-omap2.h>
@@ -37,6 +41,7 @@
#include "soc.h"
#include "common.h"
#include "gpmc.h"
+#include "gpmc-nand.h"
#define DEVICE_NAME "omap-gpmc"
@@ -751,6 +756,133 @@ static int __devinit gpmc_mem_init(void)
return 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id gpmc_dt_ids[] = {
+ { .compatible = "ti,gpmc" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
+
+static void gpmc_read_timings_dt(struct device_node *np,
+ struct gpmc_timings *gpmc_t)
+{
+ u32 val;
+
+ memset(gpmc_t, 0, sizeof(*gpmc_t));
+
+ /* minimum clock period for syncronous mode */
+ if (!of_property_read_u32(np, "gpmc,sync-clk", &val))
+ gpmc_t->sync_clk = val;
+
+ /* chip select timtings */
+ if (!of_property_read_u32(np, "gpmc,cs-on", &val))
+ gpmc_t->cs_on = val;
+
+ if (!of_property_read_u32(np, "gpmc,cs-rd-off", &val))
+ gpmc_t->cs_rd_off = val;
+
+ if (!of_property_read_u32(np, "gpmc,cs-wr-off", &val))
+ gpmc_t->cs_wr_off = val;
+
+ /* ADV signal timings */
+ if (!of_property_read_u32(np, "gpmc,adv-on", &val))
+ gpmc_t->adv_on = val;
+
+ if (!of_property_read_u32(np, "gpmc,adv-rd-off", &val))
+ gpmc_t->adv_rd_off = val;
+
+ if (!of_property_read_u32(np, "gpmc,adv-wr-off", &val))
+ gpmc_t->adv_wr_off = val;
+
+ /* WE signal timings */
+ if (!of_property_read_u32(np, "gpmc,we-on", &val))
+ gpmc_t->we_on = val;
+
+ if (!of_property_read_u32(np, "gpmc,we-off", &val))
+ gpmc_t->we_off = val;
+
+ /* OE signal timings */
+ if (!of_property_read_u32(np, "gpmc,oe-on", &val))
+ gpmc_t->oe_on = val;
+
+ if (!of_property_read_u32(np, "gpmc,oe-off", &val))
+ gpmc_t->oe_off = val;
+
+ /* access and cycle timings */
+ if (!of_property_read_u32(np, "gpmc,page-burst-access", &val))
+ gpmc_t->page_burst_access = val;
+
+ if (!of_property_read_u32(np, "gpmc,access", &val))
+ gpmc_t->access = val;
+
+ if (!of_property_read_u32(np, "gpmc,rd-cycle", &val))
+ gpmc_t->rd_cycle = val;
+
+ if (!of_property_read_u32(np, "gpmc,wr-cycle", &val))
+ gpmc_t->wr_cycle = val;
+
+ /* only for OMAP3430 */
+ if (!of_property_read_u32(np, "gpmc,wr-access", &val))
+ gpmc_t->wr_access = val;
+
+ if (!of_property_read_u32(np, "gpmc,wr-data-mux-bus", &val))
+ gpmc_t->wr_data_mux_bus = val;
+}
+
+static int gpmc_probe_dt(struct platform_device *pdev)
+{
+ u32 val;
+ struct device_node *child;
+ struct gpmc_timings gpmc_t;
+ const struct of_device_id *of_id =
+ of_match_device(gpmc_dt_ids, &pdev->dev);
+
+ if (!of_id)
+ return 0;
+
+ for_each_node_by_name(child, "nand") {
+ struct omap_nand_platform_data *gpmc_nand_data;
+
+ if (of_property_read_u32(child, "reg", &val) < 0) {
+ dev_err(&pdev->dev, "%s has no 'reg' property\n",
+ child->full_name);
+ continue;
+ }
+
+ gpmc_nand_data = devm_kzalloc(&pdev->dev,
+ sizeof(*gpmc_nand_data),
+ GFP_KERNEL);
+ if (!gpmc_nand_data) {
+ dev_err(&pdev->dev, "unable to allocate memory?");
+ return -ENOMEM;
+ }
+
+ gpmc_nand_data->cs = val;
+ gpmc_nand_data->of_node = child;
+
+ val = of_get_nand_ecc_mode(child);
+ if (val >= 0)
+ gpmc_nand_data->ecc_opt = val;
+
+ val = of_get_nand_bus_width(child);
+ if (val == 16)
+ gpmc_nand_data->devsize = NAND_BUSWIDTH_16;
+
+ gpmc_read_timings_dt(child, &gpmc_t);
+ gpmc_nand_init(gpmc_nand_data, &gpmc_t);
+
+ of_node_put(child);
+ }
+
+ return 0;
+}
+#else
+static int gpmc_probe_dt(struct platform_device *pdev)
+{
+ return 0;
+}
+#endif
+
static __devinit int gpmc_probe(struct platform_device *pdev)
{
int rc;
@@ -804,6 +936,14 @@ static __devinit int gpmc_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
+ rc = gpmc_probe_dt(pdev);
+ if (rc < 0) {
+ clk_disable_unprepare(gpmc_l3_clk);
+ clk_put(gpmc_l3_clk);
+ dev_err(gpmc_dev, "failed to probe DT parameters\n");
+ return rc;
+ }
+
return 0;
}
@@ -821,6 +961,7 @@ static struct platform_driver gpmc_driver = {
.driver = {
.name = DEVICE_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(gpmc_dt_ids),
},
};
--
1.7.11.7
^ permalink raw reply related
* [PATCH 5/8] ARM: zynq: add COMMON_CLK support
From: Josh Cartwright @ 2012-11-02 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5093E2D5.2000304@metafoo.de>
On Fri, Nov 02, 2012 at 04:12:21PM +0100, Lars-Peter Clausen wrote:
> On 11/02/2012 02:38 PM, Josh Cartwright wrote:
> > On Fri, Nov 02, 2012 at 10:33:44AM +0100, Lars-Peter Clausen wrote:
> >> On 10/31/2012 07:58 PM, Josh Cartwright wrote:
[...]
> >>> +static void __init zynq_periph_clk_setup(struct device_node *np)
> >>> +{
> >>> + struct zynq_periph_clk *periph;
> >>> + const char *parent_names[3];
> >>> + struct clk_init_data init;
> >>> + struct clk *clk;
> >>> + int err;
> >>> + u32 reg;
> >>> + int i;
> >>> +
> >>> + err = of_property_read_u32(np, "reg", ®);
> >>> + WARN_ON(err);
> >>
> >> Shouldn't the function abort if a error happens somewhere? Continuing here
> >> will lead to undefined behavior. Same is probably true for the other WARN_ONs.
> >
> > The way I see it is: the kernel is will be left in a bad state in the
> > case of any failure, regardless of if we bail out or continue. AFAICT,
> > there is no clean way to recover from a failure this early.
> >
> > Given that, it seems simpler (albeit marginally so) just to continue; so
> > that's what I chose to do. I'm not opposed to bailing out, just not
> > convinced it does anything for us.
> >
> The issue with this approach is that, while you get a warning, unexpected
> seemingly unrelated side-effects may happen later on. E.g. if no reg
> property for the clock is specified the reg variable will be uninitialized
> and contain whatever was on the stack before. The clock will be registered
> nonetheless and the boot process continues. Now if the clock is enabled a
> bit in a random register will be modified, which could result in strange and
> abnormal behavior, which can be very hard to track down.
Okay.....but any reasonable person would start their debugging quest at
the source of the WARN_ON. If someone sees the WARN_ON message but
stupidly chooses to ignore it, they deserves to spend the time trying to
track down abnormal behavior, so I'm still not convinced.
Josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121102/4744adbf/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
From: Tony Lindgren @ 2012-11-02 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50938A69.9040908@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [121102 01:56]:
> On Friday 02 November 2012 02:19 PM, Tomi Valkeinen wrote:
> >On 2012-11-02 08:38, Santosh Shilimkar wrote:
> >>
> >>Lets not move this in DMA code since the above is really related
> >>to frame buffer. It reserves more DMA area for dma_alloc_coherent()
> >>etc than default 2 MB. Infact, we should no longer need this with
> >>CMA and memblock in place.
> >>
> >>Tomi,
> >>Can we not get rid of the above memory reservation ?
> >
> >Yes, I think so. This one is only used for the old omapfb, i.e. omap1,
> >and I have no means to test it out, though. But below is a patch to
> >remove it. I also attached the patch, as it looks like thunderbird wants
> >to reformat the pasted patch... I'll remove the
> >CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file
> >in my tree later.
> >
> Great !!
> Thanks for the patches Tomi.
>
> For both the patches, feel free add.
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Great thanks, will swap in Tomi's patch.
Regards,
Tony
^ permalink raw reply
* [PATCH linux-next] ARM64: dma-mapping: support debug_dma_mapping_error
From: Shuah Khan @ 2012-11-02 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351264983.2712.14.camel@lorien2>
On Fri, 2012-10-26 at 09:23 -0600, Shuah Khan wrote:
> Add support for debug_dma_mapping_error() call to avoid warning from
> debug_dma_unmap() interface when it checks for mapping error checked
> status. Without this patch, device driver failed to check map error
> warning is generated.
>
> Signed-off-by: Shuah Khan <shuah.khan@hp.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Do you want this patch going through linux-next or the ARM64 tree? Let
me know your preference.
-- Shuah
> ---
> arch/arm64/include/asm/dma-mapping.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
> index 538f4b4..9947768 100644
> --- a/arch/arm64/include/asm/dma-mapping.h
> +++ b/arch/arm64/include/asm/dma-mapping.h
> @@ -50,6 +50,7 @@ static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
> static inline int dma_mapping_error(struct device *dev, dma_addr_t dev_addr)
> {
> struct dma_map_ops *ops = get_dma_ops(dev);
> + debug_dma_mapping_error(dev, dev_addr);
> return ops->mapping_error(dev, dev_addr);
> }
>
^ permalink raw reply
* [PATCH] i2c: at91: add a sanity check on i2c message length
From: ludovic.desroches @ 2012-11-02 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121102111432.GD21313@pengutronix.de>
Le 11/02/2012 12:14 PM, Wolfram Sang a ?crit :
> On Fri, Nov 02, 2012 at 12:04:45PM +0100, ludovic.desroches wrote:
>> Hi Wolfram,
>>
>> Le 11/01/2012 11:29 PM, Wolfram Sang a ?crit :
>>> On Wed, Oct 10, 2012 at 04:25:58PM +0200, ludovic.desroches at atmel.com wrote:
>>>> From: Ludovic Desroches <ludovic.desroches@atmel.com>
>>>>
>>>> If the i2c message length is zero, i2c-at91 will directly return an error
>>>> instead of trying to send a zero-length message.
>>>>
>>>> Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>>>
>>> What happens if you send a 0 byte message? Some hardware is able to do
>>> this and it will be used in SMBUS QUICK which the driver states to
>>> support according to at91_twi_func().
>>
>> Without this I had some data corruption when writing to / reading
>> from a serial eeprom (depending on the IP version).
>>
>> Yes SMBUS quick command is supported but is not managed in the
>> driver, we have to tell explicitly the IP that we want to send this
>> command.
>
> Ok, so unless you want to implement the support, please update this
> patch with a comment that SMBUS_QUICK is a TODO and remove the
> SMBUS_QUICK capability.
>
Implementation should not be a huge task, only one bit to set in a
register but I have no device to test it.
So I will choose to remove the SMBUS_QUICK capability.
Hi Nikolaus,
Did you test the driver with SMBus compatible devices? Can I keep other
SMBus capabilities from SMBUS_EMUL?
Thanks
Regards
Ludovic
^ permalink raw reply
* [PATCH v3 5/9] document: devicetree: bind pinconf with pin-single
From: Tony Lindgren @ 2012-11-02 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5092B9A0.9000204@wwwdotorg.org>
* Stephen Warren <swarren@wwwdotorg.org> [121101 11:06]:
> On 10/31/2012 05:04 PM, Haojian Zhuang wrote:
> > Add comments with pinconf & gpio range in the document of
> > pinctrl-single.
>
> I'd tend to suggest separating the series to add GPIO range support and
> pinconf support, especially since didn't Tony suggest a separate driver
> for pinconf? Perhaps that was just for non-generic properties.
Well I was just thinking setting them up as separate driver
instances for the register ranges supporting pinconf and
not supporting pinconf. This combined with some pinconf
property parsed during pinctrl-single.c probe time allows
saving lots of unnecessary parsing of properties for
register ranges that don't support pinconf. At least for
omaps we have few hundred registers that don't support
pinconf, and then some separate random register that do.
Regards,
TOny
^ permalink raw reply
* [PATCH net-next] macb: Keep driver's speed/duplex in sync with actual NCFGR
From: Vitalii Demianets @ 2012-11-02 17:09 UTC (permalink / raw)
To: linux-arm-kernel
When underlying phy driver restores its state very fast after being brought
down and up so that macb driver function macb_handle_link_change() was never
called with link state "down", driver's internal representation of phy speed
and duplex (bp->speed and bp->duplex) didn't change. So, macb driver sees no
reason to perform actual write to the NCFGR register, although the speed and
duplex settings in that register were reset when interface was brought down
and up. In that case actual phy speed and duplex differ from NCFGR settings.
The patch fixes that by keeping internal driver representation of speed and
duplex in sync with actual content of NCFGR.
Signed-off-by: Vitalii Demianets <vitas@nppfactor.kiev.ua>
---
drivers/net/ethernet/cadence/macb.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index c374875..13c3c33 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -1031,6 +1031,8 @@ static void macb_init_hw(struct macb *bp)
config |= MACB_BIT(NBC); /* No BroadCast */
config |= macb_dbw(bp);
macb_writel(bp, NCFGR, config);
+ bp->speed = SPEED_10;
+ bp->duplex = DUPLEX_HALF;
macb_configure_dma(bp);
--
1.7.8.6
^ permalink raw reply related
* [PATCH 1/2] ARM: mxs: apf28dev: Add pinctrl and gpios
From: Gwenhael Goavec-Merou @ 2012-11-02 18:01 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
---
arch/arm/boot/dts/imx28-apf28dev.dts | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-apf28dev.dts b/arch/arm/boot/dts/imx28-apf28dev.dts
index dde09d4..8e765ae 100644
--- a/arch/arm/boot/dts/imx28-apf28dev.dts
+++ b/arch/arm/boot/dts/imx28-apf28dev.dts
@@ -26,6 +26,27 @@
bus-width = <4>;
status = "okay";
};
+
+ pinctrl at 80018000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&hog_pins_apf28dev>;
+
+ hog_pins_apf28dev: hog at 0 {
+ reg = <0>;
+ fsl,pinmux-ids = <
+ 0x1103 /* MX28_PAD_LCD_D16__GPIO_1_16 */
+ 0x1113 /* MX28_PAD_LCD_D17__GPIO_1_17 */
+ 0x1123 /* MX28_PAD_LCD_D18__GPIO_1_18 */
+ 0x1133 /* MX28_PAD_LCD_D19__GPIO_1_19 */
+ 0x1143 /* MX28_PAD_LCD_D20__GPIO_1_20 */
+ 0x1153 /* MX28_PAD_LCD_D21__GPIO_1_21 */
+ 0x1163 /* MX28_PAD_LCD_D22__GPIO_1_22 */
+ >;
+ fsl,drive-strength = <0>;
+ fsl,voltage = <1>;
+ fsl,pull-up = <0>;
+ };
+ };
};
apbx at 80040000 {
--
1.7.8.6
^ permalink raw reply related
* [PATCH 2/2] ARM: mxs: apf28dev: Add LCD and backlight support
From: Gwenhael Goavec-Merou @ 2012-11-02 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351879308-72491-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
---
arch/arm/boot/dts/imx28-apf28dev.dts | 28 ++++++++++++++++++++++++++++
arch/arm/mach-mxs/mach-mxs.c | 24 ++++++++++++++++++++++++
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-apf28dev.dts b/arch/arm/boot/dts/imx28-apf28dev.dts
index 8e765ae..1643d25 100644
--- a/arch/arm/boot/dts/imx28-apf28dev.dts
+++ b/arch/arm/boot/dts/imx28-apf28dev.dts
@@ -46,6 +46,26 @@
fsl,voltage = <1>;
fsl,pull-up = <0>;
};
+
+ lcdif_pins_apf28dev: lcdif-apf28dev at 0 {
+ reg = <0>;
+ fsl,pinmux-ids = <
+ 0x1181 /* MX28_PAD_LCD_RD_E__LCD_VSYNC */
+ 0x1191 /* MX28_PAD_LCD_WR_RWN__LCD_HSYNC */
+ 0x11a1 /* MX28_PAD_LCD_RS__LCD_DOTCLK */
+ 0x11b1 /* MX28_PAD_LCD_CS__LCD_ENABLE */
+ >;
+ fsl,drive-strength = <0>;
+ fsl,voltage = <1>;
+ fsl,pull-up = <0>;
+ };
+ };
+
+ lcdif at 80030000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcdif_16bit_pins_a
+ &lcdif_pins_apf28dev>;
+ status = "okay";
};
};
@@ -110,4 +130,12 @@
linux,default-trigger = "heartbeat";
};
};
+
+ backlight {
+ compatible = "pwm-backlight";
+
+ pwms = <&pwm 3 191000>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ };
};
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index 48c2eba..67ef355 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -100,6 +100,25 @@ static struct fb_videomode apx4devkit_video_modes[] = {
},
};
+static struct fb_videomode apf28dev_video_modes[] = {
+ {
+ .name = "LW700",
+ .refresh = 60,
+ .xres = 800,
+ .yres = 480,
+ .pixclock = 30303, /* picosecond */
+ .left_margin = 96,
+ .right_margin = 96, /* at least 3 & 1 */
+ .upper_margin = 0x14,
+ .lower_margin = 0x15,
+ .hsync_len = 64,
+ .vsync_len = 4,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT |
+ FB_SYNC_DATA_ENABLE_HIGH_ACT |
+ FB_SYNC_DOTCLK_FAILING_ACT,
+ },
+};
+
static struct mxsfb_platform_data mxsfb_pdata __initdata;
/*
@@ -374,6 +393,11 @@ static void __init cfa10049_init(void)
static void __init apf28_init(void)
{
enable_clk_enet_out();
+
+ mxsfb_pdata.mode_list = apf28dev_video_modes;
+ mxsfb_pdata.mode_count = ARRAY_SIZE(apf28dev_video_modes);
+ mxsfb_pdata.default_bpp = 16;
+ mxsfb_pdata.ld_intf_width = STMLCDIF_16BIT;
}
static void __init mxs_machine_init(void)
--
1.7.8.6
^ permalink raw reply related
* idle_sleeptime calculation for hotplugged cpu
From: Taniya Das @ 2012-11-02 18:12 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I was looking at the arch/arm/process.c:cpu_die, I was wondering why we
do not exit from NOHZ for a hotplugged/offline cpu?
If I understand correctly an offlined cpu too will enter
NOHz(tick_nohz_idle_enter) and update the idle_entrytime. The cpu will die
and it will reenter the idle thread and update idle_entrytime onces it
comes back online and only then it will exit NOHz, but time spent in sleep
idle_sleeptime will be wrongly calculated.
void cpu_idle(void)
{
.....
/* endless idle loop with no priority at all */
while (1) {
idle_notifier_call_chain(IDLE_START);
tick_nohz_idle_enter();--> Offline CPU entering NOHZ
rcu_idle_enter();
while (!need_resched()) {
#ifdef CONFIG_HOTPLUG_CPU
if (cpu_is_offline(smp_processor_id()))
cpu_die(); ---> CPU becomes offline and re-enter the idle thread without
exiting from NOHZ,
#endif
...
}
Is it a good idea to exit from NOHZ before cpu_die() or it could be
achieved in some other way? Please provide your
comments.
--
Thanks & Regards,
Taniya Das.
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121102/f2197fc1/attachment-0001.html>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-11-02 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdac=ztY0vXQ8Mu6H8fiAO4aFSSF-A6O1Q==zKOKEsJegw@mail.gmail.com>
On Tue, Oct 30, 2012 at 10:51:11PM +0100, Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
> > More seriously the amount of time we seem to have been spending recently
> > on changes which end up requiring us to go through essentially every
> > driver and add code to them (often several times) doesn't seem like
> > we're doing a good job here.
> If this is your main concern you should be made aware that there
> are people out there planning to supplant the existing DT probe paths
> that are now being added to each and every ARM-related driver
> with an ACPI probe path as ARM servers come into the picture.
That's different as we're adding support for a new external interface
which will need per device configuration parsing rather than
reorganising things within the kernel; I'd expect it won't supplant DT
but rather sit alongside it as it's more a requirement for the server
market than for the embedded market.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121102/2a2e9cba/attachment.sig>
^ permalink raw reply
* [PATCH 1/6 v2] arm: use devicetree to get smp_twd clock
From: Mark Langsdorf @ 2012-11-02 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351882309-733-1-git-send-email-mark.langsdorf@calxeda.com>
From: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Changes from v1
None.
---
arch/arm/kernel/smp_twd.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index b22d700..600fbcc 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -237,12 +237,15 @@ static irqreturn_t twd_handler(int irq, void *dev_id)
return IRQ_NONE;
}
-static struct clk *twd_get_clock(void)
+static struct clk *twd_get_clock(struct device_node *np)
{
- struct clk *clk;
+ struct clk *clk = NULL;
int err;
- clk = clk_get_sys("smp_twd", NULL);
+ if (np)
+ clk = of_clk_get(np, 0);
+ if (!clk)
+ clk = clk_get_sys("smp_twd", NULL);
if (IS_ERR(clk)) {
pr_err("smp_twd: clock not found: %d\n", (int)PTR_ERR(clk));
return clk;
@@ -263,6 +266,7 @@ static struct clk *twd_get_clock(void)
return ERR_PTR(err);
}
+ twd_timer_rate = clk_get_rate(clk);
return clk;
}
@@ -273,12 +277,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
{
struct clock_event_device **this_cpu_clk;
- if (!twd_clk)
- twd_clk = twd_get_clock();
-
- if (!IS_ERR_OR_NULL(twd_clk))
- twd_timer_rate = clk_get_rate(twd_clk);
- else
+ if (IS_ERR_OR_NULL(twd_clk))
twd_calibrate_rate();
__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
@@ -349,6 +348,10 @@ int __init twd_local_timer_register(struct twd_local_timer *tlt)
if (!twd_base)
return -ENOMEM;
+ twd_clk = twd_get_clock(NULL);
+
+ twd_clk = twd_get_clock(NULL);
+
return twd_local_timer_common_register();
}
@@ -383,6 +386,8 @@ void __init twd_local_timer_of_register(void)
goto out;
}
+ twd_clk = twd_get_clock(np);
+
err = twd_local_timer_common_register();
out:
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
From: Tony Lindgren @ 2012-11-02 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121102154901.GU15766@atomide.com>
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [121102 01:56]:
> > On Friday 02 November 2012 02:19 PM, Tomi Valkeinen wrote:
> > >On 2012-11-02 08:38, Santosh Shilimkar wrote:
> > >>
> > >>Lets not move this in DMA code since the above is really related
> > >>to frame buffer. It reserves more DMA area for dma_alloc_coherent()
> > >>etc than default 2 MB. Infact, we should no longer need this with
> > >>CMA and memblock in place.
> > >>
> > >>Tomi,
> > >>Can we not get rid of the above memory reservation ?
> > >
> > >Yes, I think so. This one is only used for the old omapfb, i.e. omap1,
> > >and I have no means to test it out, though. But below is a patch to
> > >remove it. I also attached the patch, as it looks like thunderbird wants
> > >to reformat the pasted patch... I'll remove the
> > >CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file
> > >in my tree later.
Hmm actually, is it safe to remove for omap1, or should we
still keep it around for omap1?
Regards,
Tony
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Tony Lindgren @ 2012-11-02 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030162938.GH11908@atomide.com>
* Tony Lindgren <tony@atomide.com> [121030 09:31]:
>
> OK so are people happy with the patches in this series?
>
> Please everybody ack if no more comments so we can move on
> towards getting CONFIG_MULTIPLATFORM to work for omaps.
Looks like Joerg has a new email address, I'll send this
series out one more time.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
From: Jon Hunter @ 2012-11-02 18:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony,
Please pull the remaining patches to migrate OMAP timers and counters
over to use device-tree. I recommend applying this after Benoit's DT
series for v3.8 [1].
This branch contains ...
- Handling OMAP3 secure timers with device-tree
- Requesting timer by capability/feature
- Adds new DT machine descriptor for OMAP3 GP devices
- Look-up of clocksource/events timers from DT
- Migrate dmtimer driver to use DT
Cheers
Jon
[1] http://marc.info/?l=linux-omap&m=135179007210696&w=2
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linux 3.7-rc3 (2012-10-28 12:24:48 -0700)
are available in the git repository at:
git at github.com:jonhunter/linux.git dev-dt-timer
for you to fetch changes up to 9883f7c8dd21acb90697582ca331f3f8a66ac054:
ARM: OMAP2+: Add device-tree support for 32kHz counter (2012-11-02 13:16:31 -0500)
----------------------------------------------------------------
Jon Hunter (5):
ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
ARM: OMAP: Add function to request a timer by capability
ARM: OMAP3: Add generic machine descriptor for boards with OMAP3 GP devices
ARM: OMAP: Add DT support for timer driver
ARM: OMAP2+: Add device-tree support for 32kHz counter
arch/arm/mach-omap2/board-generic.c | 17 +++
arch/arm/mach-omap2/timer.c | 203 ++++++++++++++++++++++++-----
arch/arm/plat-omap/dmtimer.c | 93 ++++++++++++-
arch/arm/plat-omap/include/plat/dmtimer.h | 1 +
4 files changed, 275 insertions(+), 39 deletions(-)
^ permalink raw reply
* [PATCH 01/15] ARM: OMAP2+: mailbox: Add an API for flushing the FIFO
From: Tony Lindgren @ 2012-11-02 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351859566-24818-2-git-send-email-vaibhav.bedia@ti.com>
* Vaibhav Bedia <vaibhav.bedia@ti.com> [121102 05:35]:
> On AM33XX, the mailbox module between the MPU and the
> WKUP-M3 co-processor facilitates a one-way communication.
> MPU uses the assigned mailbox sub-module to issue the
> interrupt to the WKUP-M3 co-processor which then goes
> and reads the the IPC data from registers in the control
> module.
>
> WKUP-M3 is in the L4_WKUP and does not have any access to
> the Mailbox module. Due to this limitation, the MPU is
> completely responsible for FIFO maintenance and interrupt
> generation. MPU needs to ensure that the FIFO does not
> overflow by reading by the assigned mailbox sub-module.
>
> This patch adds an API in the mailbox code which the MPU
> can use to empty the FIFO by issuing a readback command.
>
> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
> ---
> arch/arm/mach-omap2/mailbox.c | 42 ++++++++++++++++++++---------
> arch/arm/plat-omap/include/plat/mailbox.h | 3 ++
> arch/arm/plat-omap/mailbox.c | 35 ++++++++++++++++++++++++
Patches have been posted to move the mailbox related
files out of arch/arm, so you'll have to update those
for that. Please see thread "[PATCH 0/2] ARM: OMAP:
mailbox out of plat code" for more information.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Jon Hunter @ 2012-11-02 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5093AB14.9090402@gmail.com>
On 11/02/2012 06:14 AM, Daniel Mack wrote:
> Hi Jon,
>
> as all comments so far focussed on patch 4/4, could we agree to merge
> 1-3 of this series already? These are all small and straight-forward
> things that don't depend on 4/4. That way, I only need to resend the
> last one under discussion.
Not sure it makes sense to take 3 without 4.
> On 02.11.2012 11:41, Jon Hunter wrote:
>> Hi Daniel,
>>
>> On 11/01/2012 01:36 PM, Daniel Mack wrote:
>>> This patch adds basic DT bindings for OMAP GPMC.
>>>
>>> The actual peripherals are instanciated from child nodes within the GPMC
>>> node, and the only type of device that is currently supported is NAND.
>>>
>>> Code was added to parse the generic GPMC timing parameters and some
>>> documentation with examples on how to use them.
>>>
>>> Successfully tested on an AM33xx board.
>>>
>>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>>> ---
>>> Documentation/devicetree/bindings/bus/ti-gpmc.txt | 73 +++++++++++
>>> .../devicetree/bindings/mtd/gpmc-nand.txt | 61 +++++++++
>>> arch/arm/mach-omap2/gpmc.c | 139 +++++++++++++++++++++
>>> 3 files changed, 273 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
>>> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>>> new file mode 100644
>>> index 0000000..6f44487
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>>> @@ -0,0 +1,73 @@
>>> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
>>> +
>>> +The actual devices are instantiated from the child nodes of a GPMC node.
>>> +
>>> +Required properties:
>>> +
>>> + - compatible: Should be set to "ti,gpmc"
>>> + - reg: A resource specifier for the register space
>>> + (see the example below)
>>> + - ti,hwmods: Should be set to "ti,gpmc" until the DT transition is
>>> + completed.
>>> + - #address-cells: Must be set to 2 to allow memory address translation
>>> + - #size-cells: Must be set to 1 to allow CS address passing
>>> + - ranges: Must be set up to reflect the memory layout
>>> + Note that this property is not currently parsed.
>>> + Calculated values derived from the contents of
>>> + GPMC_CS_CONFIG7 as set up by the bootloader. That will
>>> + change in the future, so be sure to fill the correct
>>> + values here.
>>
>> I still think it would be good to add number of chip-selects and
>> wait-pins here.
>
> The number of chip-selects can be derived from the ranges property.
> Namely, each 4-value entry to this property maps to one chip-select. I
> can try and make the more clear in the documentation.
Yes but that only tells you how many you are using. The binding should
describe the hardware and so should tell us how many chip-selects we
have. We should get away from using GPMC_CS_NUM in the code.
What about wait-pins?
>>> +Timing properties for child nodes. All are optional and default to 0.
>>> +
>>> + - gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
>>> +
>>> + Chip-select signal timings corresponding to GPMC_CS_CONFIG2:
>>> + - gpmc,cs-on: Assertion time
>>> + - gpmc,cs-rd-off: Read deassertion time
>>> + - gpmc,cs-wr-off: Write deassertion time
>>> +
>>> + ADV signal timings corresponding to GPMC_CONFIG3:
>>> + - gpmc,adv-on: Assertion time
>>> + - gpmc,adv-rd-off: Read deassertion time
>>> + - gpmc,adv-wr-off: Write deassertion time
>>
>> Nit-pick, looks like you are mixing GPMC_CS_CONFIGx and GPMC_CONFIGx
>> naming conventions in the above and below. Would be good to make this
>> consistent.
>
> Ok, but these were just copied from arch/arm/mach-omap2/gpmc.h. So it's
> wrong there, too.
Please feel free to submit a patch.
>>> + WE signals timings corresponding to GPMC_CONFIG4:
>>> + - gpmc,we-on: Assertion time
>>> + - gpmc,we-off: Deassertion time
>>> +
>>> + OE signals timings corresponding to GPMC_CONFIG4
>>> + - gpmc,oe-on: Assertion time
>>> + - gpmc,oe-off: Deassertion time
>>> +
>>> + Access time and cycle time timings corresponding to GPMC_CONFIG5
>>> + - gpmc,page-burst-access: Multiple access word delay
>>> + - gpmc,access: Start-cycle to first data valid delay
>>> + - gpmc,rd-cycle: Total read cycle time
>>> + - gpmc,wr-cycle: Total write cycle time
>>> +
>>> +The following are only on OMAP3430
>>> + - gpmc,wr-access
>>> + - gpmc,wr-data-mux-bus
>>> +
>>> +
>>> +Example for an AM33xx board:
>>> +
>>> + gpmc: gpmc at 50000000 {
>>> + compatible = "ti,gpmc";
>>> + ti,hwmods = "gpmc";
>>> + reg = <0x50000000 0x2000>;
>>> + interrupt-parent = <&intc>;
>>
>> We should drop interrupt-parent. We are declaring the interrupt-parent
>> globally in the dts files and so no need to replicate in each individual
>> binding.
>
> Right, will remove.
Thanks.
>>> + interrupts = <100>;
>>> + #address-cells = <2>;
>>> + #size-cells = <1>;
>>> + ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
>>> +
>>> + nand at 0,0 {
>>> + reg = <0 0 0>; /* CS0, offset 0 */
>>
>> The above description says that this is just the chip-select number. Are
>> the other fields used here? If so, what for?
>
> Thanks to the translation done by the 'ranges' mechanism, these just
> denote the offset to the address range specified above. So they can be
> left 0.
>>> + nand-bus-width = <16>;
>>> + nand-ecc-mode = "none";
>>
>> I am still wondering if the above needs to be mandatory. Or if not then
>> may be these should be documented as optional and if these a omitted
>> then what the default configuration would be.
>
> In my docs, I referred to Documentation/devicetree/bindings/mtd/nand.txt
> which states:
>
> - nand-ecc-mode : String, operation mode of the NAND ecc mode.
> Supported values are: "none", "soft", "hw", "hw_syndrome",
> "hw_oob_first", "soft_bch".
> - nand-bus-width : 8 or 16 bus width if not present 8
>
> So ecc-mode is mandatory, even though the code currently really defaults
> to 0 ("none"). nand-bus-width isn't. I don't know if it makes sense to
> duplicate the Documentation here.
Well maybe there should be some reference?
>>> +static int gpmc_probe_dt(struct platform_device *pdev)
>>> +{
>>> + u32 val;
>>> + struct device_node *child;
>>> + struct gpmc_timings gpmc_t;
>>> + const struct of_device_id *of_id =
>>> + of_match_device(gpmc_dt_ids, &pdev->dev);
>>> +
>>> + if (!of_id)
>>> + return 0;
>>> +
>>> + for_each_node_by_name(child, "nand") {
>>> + struct omap_nand_platform_data *gpmc_nand_data;
>>> +
>>> + if (of_property_read_u32(child, "reg", &val) < 0) {
>>> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
>>> + child->full_name);
>>> + continue;
>>> + }
>>> +
>>> + gpmc_nand_data = devm_kzalloc(&pdev->dev,
>>> + sizeof(*gpmc_nand_data),
>>> + GFP_KERNEL);
>>> + if (!gpmc_nand_data) {
>>> + dev_err(&pdev->dev, "unable to allocate memory?");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + gpmc_nand_data->cs = val;
>>> + gpmc_nand_data->of_node = child;
>>> +
>>> + val = of_get_nand_ecc_mode(child);
>>> + if (val >= 0)
>>> + gpmc_nand_data->ecc_opt = val;
>>> +
>>> + val = of_get_nand_bus_width(child);
>>> + if (val == 16)
>>> + gpmc_nand_data->devsize = NAND_BUSWIDTH_16;
>>
>> Do we need any error checking here? I believe we only support 8-bit and
>> 16-bit width devices and so if 16-bit is not set then we default to 8-bit.
>
> Yes, that's that the code does. If val != 16, ->devsize is left set to 0
> (from kzalloc). There is no NAND_BUSWIDTH_8, so I think that should be ok?
Ok.
>>> +
>>> + gpmc_read_timings_dt(child, &gpmc_t);
>>> + gpmc_nand_init(gpmc_nand_data, &gpmc_t);
>>
>> I believe that you need an "of_node_put()" when you are done with the child.
>
> Good point.
No problem.
Cheers
Jon
^ 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