[PATCH] arm: omap3: igep0020: Add console default kernel arguments
IGEP v2 boards has console as ttyO2,115200n8.
It's better so simply set this as the default kernel argument
directly in the device tree board file.
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/omap3-igep0020.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..45ffe21 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -15,6 +15,10 @@
model = IGEPv2;
compatible = isee,omap3-igep0020, ti,omap3;
+ chosen {
+ bootargs = console=ttyO2,115200n8 earlyprintk;
+ };
+
leds {
compatible = gpio-leds;
boot {
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Flip on multiplatform support for omap2plus for v3.9
Hello Tony, On Thu, Dec 20, 2012 at 12:55 PM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [121219 11:28]: Hi all, These patches enable multiplatform support for omap2plus. To build and boot it against the current mainline kernel you need the following: [PATCH 1/2] ARM: l2x0: Only set .set_debug on PL310 r3p0 and earlier [PATCH 2/2] ARM: disable errata work-arounds which access secure registers [GIT PULL 1/2] omap fixes for v3.8 merge window [GIT PULL 2/2] omap cleanup for v3.8 merge window [GIT PULL] two trivial omap build error fixes for v3.8 merge window cpts: Fix build error caused by include of plat/clock.h I'm trying this on my IGEP v2 board (using Javier's patches for DT). I've applied these series on top of your branch omap-for-v3.8/fixes-for-merge-window-part2. However, I'm finding some conflicts (fb.c appears in plat-omap, some missing headers, etc.) Could you suggest a better branch to base the series? Thanks! Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Flip on multiplatform support for omap2plus for v3.9
Hi Tony, On Thu, Dec 20, 2012 at 10:05 PM, Tony Lindgren t...@atomide.com wrote: Maybe use Olof's lates pull request for fixes from LAKML + ARM: l2x0: Only set .set_debug on PL310 r3p0 and earlier + ARM: disable errata work-arounds which access secure registers and these patches? FYI, I've successfully booted my IGEPv2 board using: * arm-soc/for-next * igep DT patches * this multiplatform series * the two patches mentioned above With this series CONFIG_MACH_IGEP0020 is not needed, just CONFIG_MACH_OMAP_GENERIC is selected. So I guess this means, for igep v2, Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com Nice job, Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] leds: leds-gpio: set devm_gpio_request_one() flags correctly
On Fri, Dec 21, 2012 at 12:07 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit a99d76f leds: leds-gpio: use gpio_request_one
changed the leds-gpio driver to use gpio_request_one() instead
of gpio_request() + gpio_direction_output()
Unfortunately, it also made a semantic change that breaks the
leds-gpio driver.
The gpio_request_one() flags parameter was set to:
GPIOF_DIR_OUT | (led_dat-active_low ^ state)
Since GPIOF_DIR_OUT is 0, the final flags value will just be the
XOR'ed value of led_dat-active_low and state.
This value were used to distinguish between HIGH/LOW output initial
level and call gpio_direction_output() accordingly.
With this new semantic gpio_request_one() will take the flags value
of 1 as a configuration of input direction (GPIOF_DIR_IN) and will
call gpio_direction_input() instead of gpio_direction_output().
int gpio_request_one(unsigned gpio, unsigned long flags, const char *label)
{
..
if (flags GPIOF_DIR_IN)
err = gpio_direction_input(gpio);
else
err = gpio_direction_output(gpio,
(flags GPIOF_INIT_HIGH) ? 1 : 0);
..
}
The right semantic is to evaluate led_dat-active_low ^ state and
set the output initial level explicitly.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
This makes LEDs to work again on my IGEPv2 board (TI OMAP3 based SoC).
I sent this patch before but then realized that I only cc'ed to linux-leds.
So, I'm resending the patch cc'ing linux-omap,linux-arm-kernel and LKML to
reach a broader audience and have more people review/test the patch.
Sorry for the noise if someone got it twice.
drivers/leds/leds-gpio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index 1885a26..a0d931b 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -127,8 +127,9 @@ static int create_gpio_led(const struct gpio_led
*template,
led_dat-cdev.flags |= LED_CORE_SUSPENDRESUME;
ret = devm_gpio_request_one(parent, template-gpio,
- GPIOF_DIR_OUT | (led_dat-active_low ^ state),
- template-name);
+ (led_dat-active_low ^ state) ?
+ GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
+ template-name);
if (ret 0)
return ret;
--
1.7.7.6
Without this patch my IGEP v2 LEDs were dead,
and this patch brings them back.
Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Thanks,
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3: igep0020: Add console default kernel arguments
Hi Enric and Javier, The u-boot 'bootargs' env overwrites the one from chosen ? I just tested and U-Boot 'bootargs' has precedence over DT bootargs but I didn't find a way to append boot parameters from U-Boot. You can either overwrite it completely or not. Yes. That seems to be the current case. Perhaps we can merge ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER and CMDLINE_EXTEND in one generic config stating the desired bootargs behavior. Does this sound sane? That been said I think that is a good idea to have some default bootargs on the DT but since you can't append any boot option from U-Boot I would also add root=/dev/mmcblk0p2 rw rootwait so at least it will be able to mount the rootfs from the uSD/MMC. True. Will re-send with those. Also, many IGEP COM Module base boards also have serial consoles that are connected to the OMAP3 UART3 (ttyO2), so maybe is better to add this to omap3-igep.dtsi instead of omap3-igep0020.dts to avoid future duplication. Ok. Thanks and merry xmas, Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap3: igep0020: Add console default kernel arguments
On Sun, Dec 23, 2012 at 3:22 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: On Sat, Dec 22, 2012 at 3:17 PM, Ezequiel Garcia elezegar...@gmail.com wrote: Hi Enric and Javier, The u-boot 'bootargs' env overwrites the one from chosen ? I just tested and U-Boot 'bootargs' has precedence over DT bootargs but I didn't find a way to append boot parameters from U-Boot. You can either overwrite it completely or not. Yes. That seems to be the current case. Perhaps we can merge ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER and CMDLINE_EXTEND in one generic config stating the desired bootargs behavior. Does this sound sane? Hi Ezequiel, You could enable ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER on omap2plus_defconfig Actually, ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER depends on ARM_ATAG_DTB_COMPAT being selected and it's only compatibility stuff for bootloaders non DTB capable. I don't think we should add that to omap2plus_defconfig. but just having a sane DTB bootargs default value is better IMHO. Agreed. I'll send a v2 with your proposed default command line. -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Hi Daniel,
Nice job!
On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack zon...@gmail.com wrote:
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instantiated 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 zon...@gmail.com
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 84 ++
.../devicetree/bindings/mtd/gpmc-nand.txt | 76 +
arch/arm/mach-omap2/gpmc.c | 173
+
3 files changed, 333 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 000..5ddb2e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,84 @@
+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 one of the following:
+
+ ti,omap2420-gpmc (omap2420)
+ ti,omap2430-gpmc (omap2430)
+ ti,omap3430-gpmc (omap3430 omap3630)
+ ti,omap4430-gpmc (omap4430 omap4460 omap543x)
+ ti,am3352-gpmc (am335x devices)
+
+ - 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
+ - gpmc,num-cs:The maximum number of chip-select lines that
controller
+ can support.
+ - gpmc,num-waitpins: The maximum number of wait pins that controller can
+ support.
+ - 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
+
+ Currently, calculated values derived from the contents
+ of the per-CS register GPMC_CONFIG7 (as set up by the
+ bootloader) are used for the physical address
decoding.
+ As this will change in the future, filling correct
+ values here is a requirement.
+
+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 applicable to OMAP3+ and AM335x:
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x2000;
+ interrupts = 100;
+
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x1000; /* CS0 @addr 0x800,
size 0x1000 */
+
+ /* 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 000..9f464f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,76 @@
[PATCH 0/3] OMAP GPMC OneNAND DT bindings
Hi everyone, Just in case anyone wants to access his OneNAND device, here's a little patchset. Feedback is more than welcome. It's based on arm-soc/for-next with Daniel Mack's GPMC patches. Ezequiel Garcia (3): mtd: omap-onenand: pass device_node in platform data arm: omap2: gpmc-onenand: drop __init annotation arm: omap2: gpmc: add DT bindings for OneNAND .../devicetree/bindings/mtd/gpmc-onenand.txt | 44 arch/arm/mach-omap2/gpmc-onenand.c |2 +- arch/arm/mach-omap2/gpmc.c | 44 drivers/mtd/onenand/omap2.c|4 +- include/linux/platform_data/mtd-onenand-omap2.h|3 + 5 files changed, 95 insertions(+), 2 deletions(-) Regards, -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] mtd: omap-onenand: pass device_node in platform data
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: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/mtd/onenand/omap2.c |4 +++-
include/linux/platform_data/mtd-onenand-omap2.h |3 +++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 065f3fe..eec2aed 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -637,6 +637,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
struct onenand_chip *this;
int r;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -767,7 +768,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
if ((r = onenand_scan(c-mtd, 1)) 0)
goto err_release_regulator;
- r = mtd_device_parse_register(c-mtd, NULL, NULL,
+ ppdata.of_node = pdata-of_node;
+ r = mtd_device_parse_register(c-mtd, NULL, ppdata,
pdata ? pdata-parts : NULL,
pdata ? pdata-nr_parts : 0);
if (r)
diff --git a/include/linux/platform_data/mtd-onenand-omap2.h
b/include/linux/platform_data/mtd-onenand-omap2.h
index 685af7e..e9a9fb1 100644
--- a/include/linux/platform_data/mtd-onenand-omap2.h
+++ b/include/linux/platform_data/mtd-onenand-omap2.h
@@ -29,5 +29,8 @@ struct omap_onenand_platform_data {
u8 flags;
u8 regulator_can_sleep;
u8 skip_initial_unlocking;
+
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] arm: omap2: gpmc-onenand: drop __init annotation
gpmc_onenand_init() will be called from another driver's probe() function,
so drop the __init annotation, in order to prevent section mismatches.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 94a349e..fadd8743 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -356,7 +356,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
return ret;
}
-void __init gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
+void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
int err;
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
This patch adds device tree bindings for OMAP OneNAND devices.
Tested on an OMAP3 3430 IGEPv2 board.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../devicetree/bindings/mtd/gpmc-onenand.txt | 44
arch/arm/mach-omap2/gpmc.c | 44
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
new file mode 100644
index 000..4108f18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -0,0 +1,44 @@
+Device tree bindings for GPMC connected OneNANDs
+
+GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of onenand.
+
+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
+
+Required properties:
+
+ - reg:The CS line the peripheral is connected to
+
+Optional properties:
+
+ - dma-channel:DMA Channel index
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an OMAP3430 board:
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ onenand@0 {
+ reg = 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 08d580a..b1f0f0b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#defineDEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct platform_device
*pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ gpmc_onenand_data = devm_kzalloc(pdev-dev, sizeof(*gpmc_onenand_data),
+GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data-cs = val;
+ gpmc_onenand_data-of_node = child;
+ gpmc_onenand_data-dma_channel = -1;
+
+ if (!of_property_read_u32(child, dma-channel, val))
+ gpmc_onenand_data-dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
+#else
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ return 0;
+}
+#endif
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ for_each_node_by_name(child, onenand) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ of_node_put(child);
+ if (ret 0)
+ return ret;
+ }
return 0;
}
#else
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
On Sun, Dec 23, 2012 at 9:01 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
This patch adds device tree bindings for OMAP OneNAND devices.
Tested on an OMAP3 3430 IGEPv2 board.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../devicetree/bindings/mtd/gpmc-onenand.txt | 44
arch/arm/mach-omap2/gpmc.c | 44
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
new file mode 100644
index 000..4108f18
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -0,0 +1,44 @@
+Device tree bindings for GPMC connected OneNANDs
+
+GPMC connected OneNAND (found on OMAP boards) are represented as child nodes
of
+the GPMC controller with a name of onenand.
+
+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
+
+Required properties:
+
+ - reg:The CS line the peripheral is connected to
+
+Optional properties:
+
+ - dma-channel:DMA Channel index
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an OMAP3430 board:
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
Before anyone complains, this is wrong:
+ onenand@0 {
+ reg = 0;
+
It should be reg = 0 0 0 of course.
Also, IMHO, I don't like the node to be matched by his name.
Shouldn't we add a compatible tag instead?
That way we could describe the device like
flash@xxx {
compatible = nand;
}
or
flash@xxx {
compatible = onenand;
}
Does this make sense?
Regards,
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap3-igep: Add fixed always-on regulators to common dtsi file
These regulators are common to igep0020 and igep0030 boards
and are needed by smsc911x controller.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Enric Balletbo i Serra eballe...@gmail.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index dd01c46..91a42ce 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -24,6 +24,18 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+vddvario: regulator-vddvario {
+compatible = regulator-fixed;
+regulator-name = vddvario;
+regulator-always-on;
+};
+
+vdd33a: regulator-vdd33a {
+compatible = regulator-fixed;
+regulator-name = vdd33a;
+regulator-always-on;
+};
};
omap3_pmx_core {
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren t...@atomide.com wrote:
* Daniel Mack zon...@gmail.com [130114 15:30]:
On Jan 15, 2013 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [121223 13:49]:
On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack zon...@gmail.com wrote:
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupts = 100;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x2000; /* CS0: NAND
*/
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
I'm a bit confused by this: what are the other two values in reg?
I see you've only added a binding for CS.
I've extended a bit on your work and added a binding to enable OneNAND
device on my IGEP board.
I might send some patches in case anyone wants to give it a try.
Daniel, should this be updated to just pass the CS?
No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
feature will help doing the math for the offset calculation eventually, so
we need to pass all three values.
OK thanks. Applying this set into omap-for-v3.9/gpmc.
Also sounds like Ezequiel needs to update his follow up patches accordingly.
Ok, I'll do that anytime this week.
Thanks,
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd: omap-onenand: pass device_node in platform data
Artem,
On Sun, Dec 23, 2012 at 9:01 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
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: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/mtd/onenand/omap2.c |4 +++-
include/linux/platform_data/mtd-onenand-omap2.h |3 +++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 065f3fe..eec2aed 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -637,6 +637,7 @@ static int omap2_onenand_probe(struct platform_device
*pdev)
struct onenand_chip *this;
int r;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -767,7 +768,8 @@ static int omap2_onenand_probe(struct platform_device
*pdev)
if ((r = onenand_scan(c-mtd, 1)) 0)
goto err_release_regulator;
- r = mtd_device_parse_register(c-mtd, NULL, NULL,
+ ppdata.of_node = pdata-of_node;
+ r = mtd_device_parse_register(c-mtd, NULL, ppdata,
pdata ? pdata-parts : NULL,
pdata ? pdata-nr_parts : 0);
if (r)
diff --git a/include/linux/platform_data/mtd-onenand-omap2.h
b/include/linux/platform_data/mtd-onenand-omap2.h
index 685af7e..e9a9fb1 100644
--- a/include/linux/platform_data/mtd-onenand-omap2.h
+++ b/include/linux/platform_data/mtd-onenand-omap2.h
@@ -29,5 +29,8 @@ struct omap_onenand_platform_data {
u8 flags;
u8 regulator_can_sleep;
u8 skip_initial_unlocking;
+
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.8.6
I saw you have acked the gpmc patch on nand.
Can I add your Acked-by on this one, when I send the rebased patch set?
Thanks,
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
Tony,
On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren t...@atomide.com wrote:
* Daniel Mack zon...@gmail.com [130114 15:30]:
On Jan 15, 2013 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [121223 13:49]:
On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack zon...@gmail.com wrote:
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupts = 100;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x2000; /* CS0: NAND
*/
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
I'm a bit confused by this: what are the other two values in reg?
I see you've only added a binding for CS.
I've extended a bit on your work and added a binding to enable OneNAND
device on my IGEP board.
I might send some patches in case anyone wants to give it a try.
Daniel, should this be updated to just pass the CS?
No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
feature will help doing the math for the offset calculation eventually, so
we need to pass all three values.
OK thanks. Applying this set into omap-for-v3.9/gpmc.
Also sounds like Ezequiel needs to update his follow up patches accordingly.
The patches for OneNAND that were posted on the ML apply cleanly
on top omap-for-v3.9/gpmc.
What do you want me to update?
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Fri, Jan 18, 2013 at 6:11 PM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [130118 11:43]:
Tony,
On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren t...@atomide.com wrote:
* Daniel Mack zon...@gmail.com [130114 15:30]:
On Jan 15, 2013 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [121223 13:49]:
On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack zon...@gmail.com wrote:
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupts = 100;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x2000; /* CS0: NAND
*/
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
I'm a bit confused by this: what are the other two values in reg?
I see you've only added a binding for CS.
I've extended a bit on your work and added a binding to enable OneNAND
device on my IGEP board.
I might send some patches in case anyone wants to give it a try.
Daniel, should this be updated to just pass the CS?
No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
feature will help doing the math for the offset calculation eventually, so
we need to pass all three values.
OK thanks. Applying this set into omap-for-v3.9/gpmc.
Also sounds like Ezequiel needs to update his follow up patches
accordingly.
The patches for OneNAND that were posted on the ML apply cleanly
on top omap-for-v3.9/gpmc.
What do you want me to update?
Oh I though you need to update the binding for the reg for your patches
based on the comments above?
Mmm... I believe there isn't anything to update (feel free to correct me).
Actually, if you take a look at my patches you'll see they're almost
identical to Daniel's NAND patches, adapted for OneNAND.
I'll re-send them, to fix a tiny typo in the added Documentation.
Thanks,
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] mtd: omap-onenand: pass device_node in platform data
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.
Acked-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/mtd/onenand/omap2.c |4 +++-
include/linux/platform_data/mtd-onenand-omap2.h |3 +++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 065f3fe..eec2aed 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -637,6 +637,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
struct onenand_chip *this;
int r;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -767,7 +768,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
if ((r = onenand_scan(c-mtd, 1)) 0)
goto err_release_regulator;
- r = mtd_device_parse_register(c-mtd, NULL, NULL,
+ ppdata.of_node = pdata-of_node;
+ r = mtd_device_parse_register(c-mtd, NULL, ppdata,
pdata ? pdata-parts : NULL,
pdata ? pdata-nr_parts : 0);
if (r)
diff --git a/include/linux/platform_data/mtd-onenand-omap2.h
b/include/linux/platform_data/mtd-onenand-omap2.h
index 685af7e..e9a9fb1 100644
--- a/include/linux/platform_data/mtd-onenand-omap2.h
+++ b/include/linux/platform_data/mtd-onenand-omap2.h
@@ -29,5 +29,8 @@ struct omap_onenand_platform_data {
u8 flags;
u8 regulator_can_sleep;
u8 skip_initial_unlocking;
+
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] arm: omap2: gpmc-onenand: drop __init annotation
gpmc_onenand_init() will be called from another driver's probe() function,
so drop the __init annotation, in order to prevent section mismatches.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 94a349e..fadd8743 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -356,7 +356,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
return ret;
}
-void __init gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
+void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
int err;
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
This patch adds device tree bindings for OMAP OneNAND devices.
Tested on an OMAP3 3430 IGEPv2 board.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v1:
* Fix typo in Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
.../devicetree/bindings/mtd/gpmc-onenand.txt | 43 +++
arch/arm/mach-omap2/gpmc.c | 44
2 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
new file mode 100644
index 000..deec9da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -0,0 +1,43 @@
+Device tree bindings for GPMC connected OneNANDs
+
+GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of onenand.
+
+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
+
+Required properties:
+
+ - reg:The CS line the peripheral is connected to
+
+Optional properties:
+
+ - dma-channel:DMA Channel index
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an OMAP3430 board:
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ onenand@0 {
+ reg = 0 0 0; /* CS0, offset 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 01ce462..f7de9eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#defineDEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct platform_device
*pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ gpmc_onenand_data = devm_kzalloc(pdev-dev, sizeof(*gpmc_onenand_data),
+GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data-cs = val;
+ gpmc_onenand_data-of_node = child;
+ gpmc_onenand_data-dma_channel = -1;
+
+ if (!of_property_read_u32(child, dma-channel, val))
+ gpmc_onenand_data-dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
+#else
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ return 0;
+}
+#endif
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ for_each_node_by_name(child, onenand) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ of_node_put(child);
+ if (ret 0)
+ return ret;
+ }
return 0;
}
#else
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
Hi Mark,
On Mon, Jan 21, 2013 at 9:30 AM, Mark Rutland mark.rutl...@arm.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 01ce462..f7de9eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#define DEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ gpmc_onenand_data = devm_kzalloc(pdev-dev,
sizeof(*gpmc_onenand_data),
+ GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data-cs = val;
+ gpmc_onenand_data-of_node = child;
+ gpmc_onenand_data-dma_channel = -1;
+
+ if (!of_property_read_u32(child, dma-channel, val))
+ gpmc_onenand_data-dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
+#else
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ return 0;
+}
+#endif
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
This doesn't look right to me:
+ for_each_node_by_name(child, onenand) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ of_node_put(child);
+ if (ret 0)
+ return ret;
+ }
for_each_node_by_name automatically calls of_node_put on each node once
passed,
and as far as I can tell, gpmc_probe_onenand_child doesn't do anything that'd
increment a node's refcount.
As far as I can see, you only need the of_node_put in the error case:
for_each_node_by_name(child, onenand) {
ret = gpmc_probe_onenand_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
}
}
Have I missed something here?
Mmm... perhaps I've overlooked that code.
After some digging through source and reading for_each_node_by_name()
it seems to me you're right.
@Daniel: It seems this would also apply to the NAND binding.
What do you think?
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
On Mon, Jan 21, 2013 at 10:32 PM, Daniel Mack zon...@gmail.com wrote:
Hi Tony, Mark, Ezequiel,
Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [130121 09:00]:
Hi Mark,
On Mon, Jan 21, 2013 at 9:30 AM, Mark Rutland mark.rutl...@arm.com
wrote:
[...]
diff --git a/arch/arm/mach-omap2/gpmc.c
b/arch/arm/mach-omap2/gpmc.c
index 01ce462..f7de9eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#define DEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ gpmc_onenand_data = devm_kzalloc(pdev-dev,
sizeof(*gpmc_onenand_data),
+ GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data-cs = val;
+ gpmc_onenand_data-of_node = child;
+ gpmc_onenand_data-dma_channel = -1;
+
+ if (!of_property_read_u32(child, dma-channel, val))
+ gpmc_onenand_data-dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
+#else
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ return 0;
+}
+#endif
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct
platform_device *pdev)
return ret;
}
This doesn't look right to me:
+ for_each_node_by_name(child, onenand) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ of_node_put(child);
+ if (ret 0)
+ return ret;
+ }
for_each_node_by_name automatically calls of_node_put on each node
once passed,
and as far as I can tell, gpmc_probe_onenand_child doesn't do
anything that'd
increment a node's refcount.
As far as I can see, you only need the of_node_put in the error
case:
for_each_node_by_name(child, onenand) {
ret = gpmc_probe_onenand_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
}
}
Have I missed something here?
Mmm... perhaps I've overlooked that code.
After some digging through source and reading for_each_node_by_name()
it seems to me you're right.
@Daniel: It seems this would also apply to the NAND binding.
What do you think?
Would prefer this done as a fix against the omap-for-v3.9/gpmc
branch before we apply Ezequiel's patches.
I'm currently far away from my computer and can't prepare a patch for this,
sorry. But I think you are right, so please just submit a patch for that,
anyone :-)
Ok, I'll try to submit a patch as soon as possible. If anyone wants to
do it instead, fine by me.
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
On Tue, Jan 22, 2013 at 3:27 PM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [130122 10:17]:
On Mon, Jan 21, 2013 at 10:32 PM, Daniel Mack zon...@gmail.com wrote:
I'm currently far away from my computer and can't prepare a patch for
this, sorry. But I think you are right, so please just submit a patch for
that, anyone :-)
Ok, I'll try to submit a patch as soon as possible. If anyone wants to
do it instead, fine by me.
No please go ahead as it seems that you can easily test it too.
No problem.
I now wonder if it's okey to exit upon probe failure.
In particular, the for_each should be like this:
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
}
}
or like this:
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
WARN_ON(ret 0);
}
Ideas?
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap2: gpmc: Remove unneeded of_node_put()
for_each_node_by_name() automatically calls of_node_put() on each
node passed; so don't do it explicitly unless there's an error.
Reported-by: Mark Rutland mark.rutl...@arm.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 01ce462..c6255f7 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1271,9 +1271,10 @@ static int gpmc_probe_dt(struct platform_device *pdev)
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
- of_node_put(child);
- if (ret 0)
+ if (ret 0) {
+ of_node_put(child);
return ret;
+ }
}
return 0;
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] mtd: omap-onenand: pass device_node in platform data
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.
Acked-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
drivers/mtd/onenand/omap2.c |4 +++-
include/linux/platform_data/mtd-onenand-omap2.h |3 +++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 065f3fe..eec2aed 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -637,6 +637,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
struct onenand_chip *this;
int r;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -767,7 +768,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
if ((r = onenand_scan(c-mtd, 1)) 0)
goto err_release_regulator;
- r = mtd_device_parse_register(c-mtd, NULL, NULL,
+ ppdata.of_node = pdata-of_node;
+ r = mtd_device_parse_register(c-mtd, NULL, ppdata,
pdata ? pdata-parts : NULL,
pdata ? pdata-nr_parts : 0);
if (r)
diff --git a/include/linux/platform_data/mtd-onenand-omap2.h
b/include/linux/platform_data/mtd-onenand-omap2.h
index 685af7e..e9a9fb1 100644
--- a/include/linux/platform_data/mtd-onenand-omap2.h
+++ b/include/linux/platform_data/mtd-onenand-omap2.h
@@ -29,5 +29,8 @@ struct omap_onenand_platform_data {
u8 flags;
u8 regulator_can_sleep;
u8 skip_initial_unlocking;
+
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] arm: omap2: gpmc-onenand: drop __init annotation
gpmc_onenand_init() will be called from another driver's probe() function,
so drop the __init annotation, in order to prevent section mismatches.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 94a349e..fadd8743 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -356,7 +356,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
return ret;
}
-void __init gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
+void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
int err;
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
This patch adds device tree bindings for OMAP OneNAND devices.
Tested on an OMAP3 3430 IGEPv2 board.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v2:
* Remove unneeded of_node_put() as reported by Mark Rutland
Changes from v1:
* Fix typo in Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
.../devicetree/bindings/mtd/gpmc-onenand.txt | 43 +++
arch/arm/mach-omap2/gpmc.c | 45
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
new file mode 100644
index 000..deec9da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -0,0 +1,43 @@
+Device tree bindings for GPMC connected OneNANDs
+
+GPMC connected OneNAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of onenand.
+
+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
+
+Required properties:
+
+ - reg:The CS line the peripheral is connected to
+
+Optional properties:
+
+ - dma-channel:DMA Channel index
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an OMAP3430 board:
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ onenand@0 {
+ reg = 0 0 0; /* CS0, offset 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 c6255f7..0636d0a 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#defineDEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct platform_device
*pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ gpmc_onenand_data = devm_kzalloc(pdev-dev, sizeof(*gpmc_onenand_data),
+GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data-cs = val;
+ gpmc_onenand_data-of_node = child;
+ gpmc_onenand_data-dma_channel = -1;
+
+ if (!of_property_read_u32(child, dma-channel, val))
+ gpmc_onenand_data-dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
+#else
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ return 0;
+}
+#endif
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1277,6 +1315,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
}
}
+ for_each_node_by_name(child, onenand) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ if (ret 0) {
+ of_node_put(child);
+ return ret;
+ }
+ }
return 0;
}
#else
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
Hi Mark,
First of all: thanks for reviewing.
On Fri, Jan 25, 2013 at 12:56 PM, Mark Rutland mark.rutl...@arm.com wrote:
Hi,
I have a couple more comments after looking though this a bit more thoroughly.
On Fri, Jan 25, 2013 at 12:23:11PM +, Ezequiel Garcia wrote:
This patch adds device tree bindings for OMAP OneNAND devices.
Tested on an OMAP3 3430 IGEPv2 board.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changes from v2:
* Remove unneeded of_node_put() as reported by Mark Rutland
Changes from v1:
* Fix typo in Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
.../devicetree/bindings/mtd/gpmc-onenand.txt | 43
+++
arch/arm/mach-omap2/gpmc.c | 45
2 files changed, 88 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
new file mode 100644
index 000..deec9da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -0,0 +1,43 @@
+Device tree bindings for GPMC connected OneNANDs
+
+GPMC connected OneNAND (found on OMAP boards) are represented as child
nodes of
+the GPMC controller with a name of onenand.
+
+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
Which tree can I find this in?
GPMC binding was posted by Daniel Mack a while ago.
Tony has recently pushed it to his master branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
+
+Required properties:
+
+ - reg: The CS line the peripheral is connected to
+
+Optional properties:
+
+ - dma-channel: DMA Channel index
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an OMAP3430 board:
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+
+ onenand@0 {
+ reg = 0 0 0; /* CS0, offset 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 c6255f7..0636d0a 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#define DEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
I don't understand the format of the reg property, but it seems odd that you
only need to read one cell from it. Are the remaining address cell and size
cell used anywhere?
Okey, I'll give a shot and try to explain this myself:
As you can see by Daniel's first patch [1]
the reg property originally contained the chip select only, and
after some discussion in that same thread, and in this one [2]
It was decided to use a reg property that would also describe
the base address and size of the gpmc sub-device,
and use ranges for the address translation.
This was reflected in Daniel's changelog when he submitted
the v2 patch series [3].
[1] http://www.spinics.net/lists/arm-kernel/msg202169.html
[2] http://web.archiveorange.com/archive/v/vEQ2yFI0tmpQJdigvAog
[3]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129426.html
+
+ gpmc_onenand_data = devm_kzalloc(pdev-dev,
sizeof(*gpmc_onenand_data),
+ GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data-cs = val;
+ gpmc_onenand_data-of_node = child;
+ gpmc_onenand_data-dma_channel = -1;
+
+ if (!of_property_read_u32(child, dma-channel, val))
+ gpmc_onenand_data-dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
[...]
Otherwise looks good.
Thanks,
--
Ezequiel
--
To unsubscribe
Re: DT GPMC SRAM and NOR flash support ?
Hi Mark,
On Thu, Feb 7, 2013 at 6:51 AM, Mark Jackson mpfj-l...@mimc.co.uk wrote:
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR
16M */
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
bank-width = 2;
gpmc,sync-clk = 0;
gpmc,cs-on = 10;
gpmc,cs-rd-off = 150;
gpmc,cs-wr-off = 150;
gpmc,adv-on = 10;
gpmc,adv-rd-off = 10;
gpmc,adv-wr-off = 10;
gpmc,oe-on = 30;
gpmc,oe-off = 150;
gpmc,we-on = 30;
gpmc,we-off = 150;
gpmc,rd-cycle = 150;
gpmc,wr-cycle = 150;
gpmc,access = 130;
gpmc,page-burst-access = 10;
gpmc,cycle2cycle-diff = 1;
gpmc,cycle2cycle-same = 1;
gpmc,cycle2cycle-delay = 10;
gpmc,wr-data-mux-bus = 60;
};
};
But the physmap driver (of_flash_probe()) is unable to use this information.
It seems that although
I can call of_flash_probe() from my NOR setup code, the platform_device being
reference is wrong.
The platform_device passed to my gpmc_probe_nor_child() routine from
gpmc_probe_dt() points to my
gpmc entry (above), but the physmap probe requires its own DT entry (rather
than a node child such
as my NOR entry with the GPMC device entry).
I think you can call something like:
of_platform_populate();
On your GPMC node and have the child initialize.
This way you don't need to have separate cfi-flash compatible nodes,
you can have them as childs.
Although I'm not sure this is a sane approach, I'm almost sure this should work.
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Prevent potential crash if GPMC probe fails
On Fri, Feb 08, 2013 at 04:56:19PM -0600, Jon Hunter wrote: On 02/01/2013 04:08 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130201 08:42]: If the GPMC probe fails, devices that use the GPMC (such as ethernet chips, flash memories, etc) can still allocate a GPMC chip-select and register the device. On the OMAP2420 H4 board, this was causing the kernel to crash after the gpmc probe failed and the board attempted to start networking. Prevent this by marking all the chip-selects as reserved by default and only make them available for devices to request if the GPMC probe succeeds. Thanks applying into omap-for-v3.9/gpmc. Hi Tony, this one appears to be merged incorrectly. The unreserve ended up in the gpmc_calc_timings() function. Here is a patch to fix. Cheers Jon From ebc0613fb5a70f36fcb119cbe58724f9b442903a Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Fri, 8 Feb 2013 16:48:25 -0600 Subject: [PATCH] ARM: OMAP2+: Fix-up gpmc merge error Commit ARM: OMAP2+: Prevent potential crash if GPMC probe fails added code to ensure that GPMC chip-selects could not be requested until the device probe was successful. The chip-selects should have been unreserved at the end of the probe function, but the code to unreserve them appears to have ended up in the gpmc_calc_timings() function and hence, this is causing problems requesting chip-selects. Fix this merge error by unreserving the chip-selects at the end of the probe, but before we call the gpmc child probe functions (for device-tree) which request a chip-select. Signed-off-by: Jon Hunter jon-hun...@ti.com Without this patch, GPMC is currently broken on my igep board setup, if initialized through a device tree. Tested-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com Thanks a lot for the fix, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] ARM: omap2: GPMC cleanup
This patchset is a small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (7): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 31 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 21 insertions(+), 28 deletions(-) -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] ARM: omap2: gpmc: Mark local scoped functions static
This patch marks a bunch of functions that are local
to gpmc.c file only as static.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c | 14 +++---
arch/arm/mach-omap2/gpmc.h |7 ---
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1e8bcb4..ffe3e1e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -181,7 +181,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
__raw_writel(val, reg_addr);
}
-u32 gpmc_cs_read_reg(int cs, int idx)
+static u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
@@ -190,7 +190,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
}
/* TODO: Add support for gpmc_fck to clock framework and use it */
-unsigned long gpmc_get_fclk_period(void)
+static unsigned long gpmc_get_fclk_period(void)
{
unsigned long rate = clk_get_rate(gpmc_l3_clk);
@@ -205,7 +205,7 @@ unsigned long gpmc_get_fclk_period(void)
return rate;
}
-unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
{
unsigned long tick_ps;
@@ -215,7 +215,7 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
return (time_ns * 1000 + tick_ps - 1) / tick_ps;
}
-unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
{
unsigned long tick_ps;
@@ -230,7 +230,7 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
{
unsigned long ticks = gpmc_ns_to_ticks(time_ns);
@@ -448,7 +448,7 @@ static int gpmc_cs_mem_enabled(int cs)
return l GPMC_CONFIG7_CSVALID;
}
-int gpmc_cs_set_reserved(int cs, int reserved)
+static int gpmc_cs_set_reserved(int cs, int reserved)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
@@ -459,7 +459,7 @@ int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-int gpmc_cs_reserved(int cs)
+static int gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index fe0a844..b79e35c 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -195,20 +195,13 @@ extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
extern int gpmc_get_client_irq(unsigned irq_config);
-extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
-extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
-extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
-extern unsigned long gpmc_get_fclk_period(void);
extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
-extern u32 gpmc_cs_read_reg(int cs, int idx);
extern int gpmc_calc_divider(unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
-extern int gpmc_cs_set_reserved(int cs, int reserved);
-extern int gpmc_cs_reserved(int cs);
extern void omap3_gpmc_save_context(void);
extern void omap3_gpmc_restore_context(void);
extern int gpmc_cs_configure(int cs, int cmd, int wval);
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ffe3e1e..bd3bc93 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -230,13 +230,6 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
-{
- unsigned long ticks = gpmc_ns_to_ticks(time_ns);
-
- return ticks * gpmc_get_fclk_period() / 1000;
-}
-
static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
{
return ticks * gpmc_get_fclk_period();
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
Fix gpmc_cs_reserved() so it returns 0 if the chip select
is available (not reserved) or an error otherwise.
This allows to use the return value directly and return a proper error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bd3bc93..604c1eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -452,12 +452,16 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
+/* Returns 0 if CS is available (not reseverd) or an error otherwise */
static int gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
- return gpmc_cs_map (1 cs);
+ if (gpmc_cs_map (1 cs))
+ return -EBUSY;
+
+ return 0;
}
static unsigned long gpmc_mem_align(unsigned long size)
@@ -516,10 +520,10 @@ int gpmc_cs_request(int cs, unsigned long size, unsigned
long *base)
return -ENOMEM;
spin_lock(gpmc_mem_lock);
- if (gpmc_cs_reserved(cs)) {
- r = -EBUSY;
+ r = gpmc_cs_reserved(cs);
+ if (r 0)
goto out;
- }
+
if (gpmc_cs_mem_enabled(cs))
r = adjust_resource(res, res-start ~(size - 1), size);
if (r 0)
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] ARM: omap2: gpmc-nand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-nand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index afc1e8c..e50e438 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -122,7 +122,8 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
(unsigned long *)gpmc_nand_resource[0].start);
if (err 0) {
- dev_err(dev, Cannot request GPMC CS\n);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_nand_data-cs, err);
return err;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] ARM: omap2: gpmc-onenand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index fadd8743..0ee5317 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -379,7 +379,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS\n, __func__);
+ pr_err(%s: Cannot request GPMC CS %d, error %d\n,
+ __func__, gpmc_onenand_data-cs, err);
return;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 0ee5317..4771945 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -359,6 +359,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
int err;
+ struct device *dev = gpmc_onenand_device.dev;
gpmc_onenand_data = _onenand_data;
gpmc_onenand_data-onenand_setup = gpmc_onenand_setup;
@@ -379,8 +380,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS %d, error %d\n,
- __func__, gpmc_onenand_data-cs, err);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_onenand_data-cs, err);
return;
}
@@ -388,7 +389,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
ONENAND_IO_SIZE - 1;
if (platform_device_register(gpmc_onenand_device) 0) {
- pr_err(%s: Unable to register OneNAND device\n, __func__);
+ dev_err(dev, Unable to register OneNAND device\n);
gpmc_cs_free(gpmc_onenand_data-cs);
return;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
Since the condition is not an error but a warning, replace
printk KERN_ERR with dev_warn.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 4771945..fd6e35b 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -367,7 +367,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
if (cpu_is_omap24xx()
(gpmc_onenand_data-flags ONENAND_SYNC_READWRITE)) {
- printk(KERN_ERR Onenand using only SYNC_READ on 24xx\n);
+ dev_warn(dev, OneNAND using only SYNC_READ on 24xx\n);
gpmc_onenand_data-flags = ~ONENAND_SYNC_READWRITE;
gpmc_onenand_data-flags |= ONENAND_SYNC_READ;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
On Sat, Feb 09, 2013 at 06:55:32PM +0200, Felipe Balbi wrote:
Hi,
On Sat, Feb 09, 2013 at 01:38:16PM -0300, Ezequiel Garcia wrote:
Since the condition is not an error but a warning, replace
printk KERN_ERR with dev_warn.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 4771945..fd6e35b 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -367,7 +367,7 @@ void gpmc_onenand_init(struct
omap_onenand_platform_data *_onenand_data)
if (cpu_is_omap24xx()
(gpmc_onenand_data-flags ONENAND_SYNC_READWRITE)) {
- printk(KERN_ERR Onenand using only SYNC_READ on 24xx\n);
+ dev_warn(dev, OneNAND using only SYNC_READ on 24xx\n);
it would seem more natural to use dev_err() instead.
Are you sure? The error seems more a warning to me,
although I guess it's arguable.
Let me know and I'll fix it in v2.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
Hi Felipe,
On Sat, Feb 09, 2013 at 06:53:35PM +0200, Felipe Balbi wrote:
On Sat, Feb 09, 2013 at 01:38:12PM -0300, Ezequiel Garcia wrote:
Fix gpmc_cs_reserved() so it returns 0 if the chip select
is available (not reserved) or an error otherwise.
This allows to use the return value directly and return a proper error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bd3bc93..604c1eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -452,12 +452,16 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
+/* Returns 0 if CS is available (not reseverd) or an error otherwise */
s/reseverd/reserved/
Indeed.
static int gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
- return gpmc_cs_map (1 cs);
+ if (gpmc_cs_map (1 cs))
+ return -EBUSY;
+
+ return 0;
you could use a ternary operator here:
bit = gpmc_cs_map (1 cs);
return bit ? -EBUSY : 0;
But to be frank, I'm not sure this makes that much sense, I'd expect
gpmc_cs_reserved() to return 0 or 1 depending on the state (just as it
was before). The name of the method asks for a boolean return value.
Well, we can change the return value to a boolean.
However, note that the function 'as it was before' was somewhat inconsistent:
gpmc_cs_reserved returned -ENODEV if the given 'cs' was out of range and
a non-negative integer otherwise, 0 if the cs is available and positive
integer otherwise.
So, what I'm doing here is fixing this by returning an appropriate error
condition or 0 if the CS is available.
If we change it to return a boolean, we won't be able to distinguish
between EBUSY and ENODEV.
Let me know what you prefer and I'll fix it on v2.
Thanks for the review,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DT GPMC SRAM and NOR flash support ?
Hi Jon On Mon, Feb 11, 2013 at 7:21 PM, Jon Hunter jon-hun...@ti.com wrote: This is being call from the mach-omap2/board-generic.c file on boot. Where are you suggesting this is called from? I was suggesting this could be called in gpmc_probe_dt() in gpmc.c. Instead of using for_each_node_by_name() and initialize manually each node, it should be possibly (perhaps with some ugly hack) to use of_platform_populate() to initialize gpmc child devices. But I'm not exactly sure how this would work. -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] ARM: omap2: GPMC cleanup
This patchset is v2 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changelog from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/8] ARM: omap2: gpmc: Mark local scoped functions static
This patch marks a bunch of functions that are local
to gpmc.c file only as static.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c | 14 +++---
arch/arm/mach-omap2/gpmc.h |7 ---
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1e8bcb4..ffe3e1e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -181,7 +181,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
__raw_writel(val, reg_addr);
}
-u32 gpmc_cs_read_reg(int cs, int idx)
+static u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
@@ -190,7 +190,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
}
/* TODO: Add support for gpmc_fck to clock framework and use it */
-unsigned long gpmc_get_fclk_period(void)
+static unsigned long gpmc_get_fclk_period(void)
{
unsigned long rate = clk_get_rate(gpmc_l3_clk);
@@ -205,7 +205,7 @@ unsigned long gpmc_get_fclk_period(void)
return rate;
}
-unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
{
unsigned long tick_ps;
@@ -215,7 +215,7 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
return (time_ns * 1000 + tick_ps - 1) / tick_ps;
}
-unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
{
unsigned long tick_ps;
@@ -230,7 +230,7 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
{
unsigned long ticks = gpmc_ns_to_ticks(time_ns);
@@ -448,7 +448,7 @@ static int gpmc_cs_mem_enabled(int cs)
return l GPMC_CONFIG7_CSVALID;
}
-int gpmc_cs_set_reserved(int cs, int reserved)
+static int gpmc_cs_set_reserved(int cs, int reserved)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
@@ -459,7 +459,7 @@ int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-int gpmc_cs_reserved(int cs)
+static int gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index fe0a844..b79e35c 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -195,20 +195,13 @@ extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
extern int gpmc_get_client_irq(unsigned irq_config);
-extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
-extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
-extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
-extern unsigned long gpmc_get_fclk_period(void);
extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
-extern u32 gpmc_cs_read_reg(int cs, int idx);
extern int gpmc_calc_divider(unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
-extern int gpmc_cs_set_reserved(int cs, int reserved);
-extern int gpmc_cs_reserved(int cs);
extern void omap3_gpmc_save_context(void);
extern void omap3_gpmc_restore_context(void);
extern int gpmc_cs_configure(int cs, int cmd, int wval);
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ffe3e1e..bd3bc93 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -230,13 +230,6 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
-{
- unsigned long ticks = gpmc_ns_to_ticks(time_ns);
-
- return ticks * gpmc_get_fclk_period() / 1000;
-}
-
static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
{
return ticks * gpmc_get_fclk_period();
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/8] ARM: omap2: gpmc-nand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-nand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index afc1e8c..e50e438 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -122,7 +122,8 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
(unsigned long *)gpmc_nand_resource[0].start);
if (err 0) {
- dev_err(dev, Cannot request GPMC CS\n);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_nand_data-cs, err);
return err;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/8] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
Currently gpmc_cs_reserved() return value is somewhat inconsistent,
returning a negative value on an error condition, a positive value
if the chip select is reserved and zero if it's available.
Fix this by returning a boolean value as the function name suggests:
* true if the chip select is reserved,
* false if it's available
Suggested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changelog from v1:
* As suggested by Felipe Balbi, fix return code to a boolean
arch/arm/mach-omap2/gpmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bd3bc93..fa4764f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -452,10 +452,10 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-static int gpmc_cs_reserved(int cs)
+static bool gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
- return -ENODEV;
+ return true;
return gpmc_cs_map (1 cs);
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/8] ARM: omap2: gpmc-onenand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index fadd8743..0ee5317 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -379,7 +379,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS\n, __func__);
+ pr_err(%s: Cannot request GPMC CS %d, error %d\n,
+ __func__, gpmc_onenand_data-cs, err);
return;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/8] ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 0ee5317..4771945 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -359,6 +359,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
int err;
+ struct device *dev = gpmc_onenand_device.dev;
gpmc_onenand_data = _onenand_data;
gpmc_onenand_data-onenand_setup = gpmc_onenand_setup;
@@ -379,8 +380,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS %d, error %d\n,
- __func__, gpmc_onenand_data-cs, err);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_onenand_data-cs, err);
return;
}
@@ -388,7 +389,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
ONENAND_IO_SIZE - 1;
if (platform_device_register(gpmc_onenand_device) 0) {
- pr_err(%s: Unable to register OneNAND device\n, __func__);
+ dev_err(dev, Unable to register OneNAND device\n);
gpmc_cs_free(gpmc_onenand_data-cs);
return;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/8] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
Since the condition is not an error but a warning, replace
printk KERN_ERR with dev_warn.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 4771945..fd6e35b 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -367,7 +367,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
if (cpu_is_omap24xx()
(gpmc_onenand_data-flags ONENAND_SYNC_READWRITE)) {
- printk(KERN_ERR Onenand using only SYNC_READ on 24xx\n);
+ dev_warn(dev, OneNAND using only SYNC_READ on 24xx\n);
gpmc_onenand_data-flags = ~ONENAND_SYNC_READWRITE;
gpmc_onenand_data-flags |= ONENAND_SYNC_READ;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/8] ARM: omap2: gpmc: Remove redundant chip select out of range check
This check is done before the call to gpmc_cs_reserved() and
gpmc_cs_set_reserved() and it's redundant to do it again in each
function. This simplifies the code a bit.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
arch/arm/mach-omap2/gpmc.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index fa4764f..0201ea9 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -441,22 +441,14 @@ static int gpmc_cs_mem_enabled(int cs)
return l GPMC_CONFIG7_CSVALID;
}
-static int gpmc_cs_set_reserved(int cs, int reserved)
+static void gpmc_cs_set_reserved(int cs, int reserved)
{
- if (cs GPMC_CS_NUM)
- return -ENODEV;
-
gpmc_cs_map = ~(1 cs);
gpmc_cs_map |= (reserved ? 1 : 0) cs;
-
- return 0;
}
static bool gpmc_cs_reserved(int cs)
{
- if (cs GPMC_CS_NUM)
- return true;
-
return gpmc_cs_map (1 cs);
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] ARM: omap2: GPMC cleanup
On Tue, Feb 12, 2013 at 09:12:53AM -0800, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130212 08:36]: On 02/12/2013 09:18 AM, Ezequiel Garcia wrote: This patchset is v2 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changelog from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) Looks good to me. I noticed that for some patches there is no changelog and I understand that that is because they are some what trivial clean-ups and the subject explains the patch. However, typically it is good to have a changelog in the patch no matter how trivial it is. Tony may ask you to add a changelog. Otherwise ... Reviewed-by: Jon Hunter jon-hun...@ti.com Yes please add a changelog. Patches with no changelog have no changelog ;-) My usual workflow is to re-send a whole series, and only add a changelog to the ones that actually change. For instance, for this patchset, the only one that actually changed is ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value. The rest is just the same it was in v1. I like to do it this way, because I think it keeps the patches together, and I hope I make maintainers life easier; of course, I might be wrong. So, should I use a different workflow and send only the patches that change with new versions? Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] ARM: omap2: GPMC cleanup
On Tue, Feb 12, 2013 at 10:43:25AM -0800, Tony Lindgren wrote: * Ezequiel Garcia ezequiel.gar...@free-electrons.com [130212 10:29]: On Tue, Feb 12, 2013 at 09:12:53AM -0800, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [130212 08:36]: On 02/12/2013 09:18 AM, Ezequiel Garcia wrote: This patchset is v2 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changelog from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough these patchset is almost trivial, any feedback or testing is more than welcome. Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) Looks good to me. I noticed that for some patches there is no changelog and I understand that that is because they are some what trivial clean-ups and the subject explains the patch. However, typically it is good to have a changelog in the patch no matter how trivial it is. Tony may ask you to add a changelog. Otherwise ... Reviewed-by: Jon Hunter jon-hun...@ti.com Yes please add a changelog. Patches with no changelog have no changelog ;-) My usual workflow is to re-send a whole series, and only add a changelog to the ones that actually change. For instance, for this patchset, the only one that actually changed is ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value. The rest is just the same it was in v1. I like to do it this way, because I think it keeps the patches together, and I hope I make maintainers life easier; of course, I might be wrong. So, should I use a different workflow and send only the patches that change with new versions? Sorry I think there's a misunderstanding here.. Jon and I mean that each patch should have a description in addition to the Subject line even if a trival patch :) Oops, my bad! I'll re-send adding a description to each patch. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/8] ARM: omap2: GPMC cleanup
This patchset is v3 of the small cleanup consisting in: * mark some functions as 'static' when appropriate * remove an unused function from gpmc.c * improve error messages when a CS request fails * migrate to dev_err and dev_warn Changes from v2: * add a commit message to some trivial patches, that omitted it due to author's laziness. Changes from v1: * fix gpmc_cs_reserved to return a boolean instead of an integer error code * add a new patch to the patchset cleaning redundant checks It has been tested on a IGEP v2 board with OneNAND, which means the gpmc-nand patch is tested by compilation only. Altough this patchset is almost trivial, any feedback or testing is more than welcome. Thanks to Jon Hunter for his kind review! Ezequiel Garcia (8): ARM: omap2: gpmc: Mark local scoped functions static ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value ARM: omap2: gpmc-nand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Print something useful on CS request failure ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err() ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn() ARM: omap2: gpmc: Remove redundant chip select out of range check arch/arm/mach-omap2/gpmc-nand.c|3 ++- arch/arm/mach-omap2/gpmc-onenand.c |8 +--- arch/arm/mach-omap2/gpmc.c | 27 ++- arch/arm/mach-omap2/gpmc.h |7 --- 4 files changed, 13 insertions(+), 32 deletions(-) -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/8] ARM: omap2: gpmc: Mark local scoped functions static
This patch marks a bunch of functions that are local
to gpmc.c file only as static.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 14 +++---
arch/arm/mach-omap2/gpmc.h |7 ---
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1e8bcb4..ffe3e1e 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -181,7 +181,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
__raw_writel(val, reg_addr);
}
-u32 gpmc_cs_read_reg(int cs, int idx)
+static u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
@@ -190,7 +190,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
}
/* TODO: Add support for gpmc_fck to clock framework and use it */
-unsigned long gpmc_get_fclk_period(void)
+static unsigned long gpmc_get_fclk_period(void)
{
unsigned long rate = clk_get_rate(gpmc_l3_clk);
@@ -205,7 +205,7 @@ unsigned long gpmc_get_fclk_period(void)
return rate;
}
-unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
{
unsigned long tick_ps;
@@ -215,7 +215,7 @@ unsigned int gpmc_ns_to_ticks(unsigned int time_ns)
return (time_ns * 1000 + tick_ps - 1) / tick_ps;
}
-unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
+static unsigned int gpmc_ps_to_ticks(unsigned int time_ps)
{
unsigned long tick_ps;
@@ -230,7 +230,7 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
+static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
{
unsigned long ticks = gpmc_ns_to_ticks(time_ns);
@@ -448,7 +448,7 @@ static int gpmc_cs_mem_enabled(int cs)
return l GPMC_CONFIG7_CSVALID;
}
-int gpmc_cs_set_reserved(int cs, int reserved)
+static int gpmc_cs_set_reserved(int cs, int reserved)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
@@ -459,7 +459,7 @@ int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-int gpmc_cs_reserved(int cs)
+static int gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
return -ENODEV;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index fe0a844..b79e35c 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -195,20 +195,13 @@ extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
extern int gpmc_get_client_irq(unsigned irq_config);
-extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
-extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
-extern unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns);
-extern unsigned long gpmc_get_fclk_period(void);
extern void gpmc_cs_write_reg(int cs, int idx, u32 val);
-extern u32 gpmc_cs_read_reg(int cs, int idx);
extern int gpmc_calc_divider(unsigned int sync_clk);
extern int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
-extern int gpmc_cs_set_reserved(int cs, int reserved);
-extern int gpmc_cs_reserved(int cs);
extern void omap3_gpmc_save_context(void);
extern void omap3_gpmc_restore_context(void);
extern int gpmc_cs_configure(int cs, int cmd, int wval);
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/8] ARM: omap2: gpmc: Remove unused gpmc_round_ns_to_ticks() function
This function is not used anywhere, so it's safe to remove it.
This means less code to maintain.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ffe3e1e..bd3bc93 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -230,13 +230,6 @@ unsigned int gpmc_ticks_to_ns(unsigned int ticks)
return ticks * gpmc_get_fclk_period() / 1000;
}
-static unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
-{
- unsigned long ticks = gpmc_ns_to_ticks(time_ns);
-
- return ticks * gpmc_get_fclk_period() / 1000;
-}
-
static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
{
return ticks * gpmc_get_fclk_period();
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/8] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
Currently gpmc_cs_reserved() return value is somewhat inconsistent,
returning a negative value on an error condition, a positive value
if the chip select is reserved and zero if it's available.
Fix this by returning a boolean value as the function name suggests:
* true if the chip select is reserved,
* false if it's available
Suggested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
Changelog from v1:
* As suggested by Felipe Balbi, fix return code to a boolean
arch/arm/mach-omap2/gpmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bd3bc93..fa4764f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -452,10 +452,10 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-static int gpmc_cs_reserved(int cs)
+static bool gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
- return -ENODEV;
+ return true;
return gpmc_cs_map (1 cs);
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/8] ARM: omap2: gpmc-nand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index afc1e8c..e50e438 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -122,7 +122,8 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
(unsigned long *)gpmc_nand_resource[0].start);
if (err 0) {
- dev_err(dev, Cannot request GPMC CS\n);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_nand_data-cs, err);
return err;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/8] ARM: omap2: gpmc-onenand: Print something useful on CS request failure
If CS request fails the current error message is rather unhelpful.
Fix it by printing the failing chip select and the error code.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index fadd8743..0ee5317 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -379,7 +379,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS\n, __func__);
+ pr_err(%s: Cannot request GPMC CS %d, error %d\n,
+ __func__, gpmc_onenand_data-cs, err);
return;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/8] ARM: omap2: gpmc-onenand: Replace pr_err() with dev_err()
Do this becasue dev_err() is preferred over pr_err() and because
it will match gpmc-nand, thus the code shows looks more consistent.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 0ee5317..4771945 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -359,6 +359,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
void gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
int err;
+ struct device *dev = gpmc_onenand_device.dev;
gpmc_onenand_data = _onenand_data;
gpmc_onenand_data-onenand_setup = gpmc_onenand_setup;
@@ -379,8 +380,8 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
err = gpmc_cs_request(gpmc_onenand_data-cs, ONENAND_IO_SIZE,
(unsigned long *)gpmc_onenand_resource.start);
if (err 0) {
- pr_err(%s: Cannot request GPMC CS %d, error %d\n,
- __func__, gpmc_onenand_data-cs, err);
+ dev_err(dev, Cannot request GPMC CS %d, error %d\n,
+ gpmc_onenand_data-cs, err);
return;
}
@@ -388,7 +389,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
ONENAND_IO_SIZE - 1;
if (platform_device_register(gpmc_onenand_device) 0) {
- pr_err(%s: Unable to register OneNAND device\n, __func__);
+ dev_err(dev, Unable to register OneNAND device\n);
gpmc_cs_free(gpmc_onenand_data-cs);
return;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/8] ARM: omap2: gpmc-onenand: Replace printk KERN_ERR with dev_warn()
Since the condition is not an error but a warning, replace
printk KERN_ERR with dev_warn.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 4771945..fd6e35b 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -367,7 +367,7 @@ void gpmc_onenand_init(struct omap_onenand_platform_data
*_onenand_data)
if (cpu_is_omap24xx()
(gpmc_onenand_data-flags ONENAND_SYNC_READWRITE)) {
- printk(KERN_ERR Onenand using only SYNC_READ on 24xx\n);
+ dev_warn(dev, OneNAND using only SYNC_READ on 24xx\n);
gpmc_onenand_data-flags = ~ONENAND_SYNC_READWRITE;
gpmc_onenand_data-flags |= ONENAND_SYNC_READ;
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 8/8] ARM: omap2: gpmc: Remove redundant chip select out of range check
This check is done before the call to gpmc_cs_reserved() and
gpmc_cs_set_reserved() and it's redundant to do it again in each
function. This simplifies the code a bit.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index fa4764f..0201ea9 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -441,22 +441,14 @@ static int gpmc_cs_mem_enabled(int cs)
return l GPMC_CONFIG7_CSVALID;
}
-static int gpmc_cs_set_reserved(int cs, int reserved)
+static void gpmc_cs_set_reserved(int cs, int reserved)
{
- if (cs GPMC_CS_NUM)
- return -ENODEV;
-
gpmc_cs_map = ~(1 cs);
gpmc_cs_map |= (reserved ? 1 : 0) cs;
-
- return 0;
}
static bool gpmc_cs_reserved(int cs)
{
- if (cs GPMC_CS_NUM)
- return true;
-
return gpmc_cs_map (1 cs);
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/1] ARM: omap2: gpmc: Move binding documentation
Following current trend of placing memory controllers drivers under
drivers/memory, this patch anticipates this by moving the binding
documentation to Documentation/devicetree/bindings/memory-controller.
Some other SoCs will have similar memory controllers placed under
drivers/memory and it seems a bit strange to put GPMC under drivers/bus.
Ezequiel Garcia (1):
ARM: omap2: gpmc: Move binding documentation to memory-controller
.../ti-gpmc.txt = memory-controllers/ti/gpmc.txt} |0
1 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt =
memory-controllers/ti/gpmc.txt} (100%)
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/1] ARM: omap2: gpmc: Move binding documentation to memory-controller
GPMC stands for General Purpose Memory Controller, and it's primarily
used to handle memories such as NOR, NAND, SRAM.
Note that this controller is also used to handle network controllers
such as smsc911x.
This patch moves the documentation binding to memory-controllers,
where it belongs.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../ti-gpmc.txt = memory-controllers/ti/gpmc.txt} |0
1 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt =
memory-controllers/ti/gpmc.txt} (100%)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/memory-controllers/ti/gpmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/bus/ti-gpmc.txt
rename to Documentation/devicetree/bindings/memory-controllers/ti/gpmc.txt
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DT GPMC SRAM and NOR flash support ?
Hi Jon,
I'm working on a similar memory controller for plat-orion.
I have a few questions about your approach.
On Wed, Feb 13, 2013 at 03:07:06PM -0600, Jon Hunter wrote:
On 02/07/2013 03:51 AM, Mark Jackson wrote:
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR 16M
*/
Is that really 16M? Looks more like 128M :-)
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
I think that cfi-flash is expecting a length here. Here is
what I have ...
+gpmc {
+ ranges = 0 0 0x0800 0x0400;
+
+ nor@0,0 {
+ compatible = cfi-flash;
+ linux,mtd-name= intel,ge28f256l18b85;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0 0 0x0400;
+ bank-width = 2;
+
+ partition@0 {
+ label = bootloader;
+ reg = 0 0x2;
+ };
+ partition@0x2 {
+ label = params;
+ reg = 0x2 0x2;
+ };
+ partition@0x4 {
+ label = kernel;
+ reg = 0x4 0x20;
+ };
+ partition@0x24 {
+ label = file-system;
+ reg = 0x24 0x3dc;
+ };
+ };
nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};
You don't need this extra entry if you add simple-bus to
the gpmc node compatible string.
That would be nice. However, I wonder what happens if cfi-flash probing
fails: will the gpmc cs request by undone? See below...
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6800a000 0x1000;
+ interrupts = 20;
+
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
Currently I have the following and this is working for me.
Please note that on my board the bootloader is configuring
the timings for me and so this is missing from the below
implementation and still needs to be added.
Cheers
Jon
From c0ede833fad704ab452b116154177e3a59166c7e Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Fri, 8 Feb 2013 16:46:13 -0600
Subject: [PATCH] ARM: OMAP2+: Add device-tree support for NOR flash
---
arch/arm/mach-omap2/gpmc.c | 69
1 file changed, 69 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bc90155..421320b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -26,6 +26,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/of.h
+#include linux/of_address.h
#include linux/of_mtd.h
#include linux/of_device.h
#include linux/mtd/nand.h
@@ -517,6 +518,26 @@ static int gpmc_cs_delete_mem(int cs)
return r;
}
+static int gpmc_cs_remap(int cs, u32 base)
+{
+ int r;
+ u32 old_base, size;
+
+ gpmc_cs_get_memconf(cs, old_base, size);
+ if (base == old_base)
+ return 0;
+ gpmc_cs_disable_mem(cs);
+ r = gpmc_cs_delete_mem(cs);
+ if (IS_ERR_VALUE(r))
+ return r;
+ r = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(r))
+ return r;
+ gpmc_cs_enable_mem(cs, base, size);
+
+ return 0;
+}
+
int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
{
struct resource *res = gpmc_cs_mem[cs];
@@ -1305,6 +1326,45 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_nor_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ struct resource res;
+ unsigned long base;
+ int rc, cs;
+
+ if (of_property_read_u32(child, reg, cs) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(child, 0, res)) {
+ dev_err(pdev-dev, %s has malformed 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
Re: [RFC 1/1] ARM: omap2: gpmc: Move binding documentation to memory-controller
On Wed, Feb 13, 2013 at 09:13:27AM -0600, Jon Hunter wrote:
On 02/13/2013 05:13 AM, Ezequiel Garcia wrote:
GPMC stands for General Purpose Memory Controller, and it's primarily
used to handle memories such as NOR, NAND, SRAM.
Note that this controller is also used to handle network controllers
such as smsc911x.
This patch moves the documentation binding to memory-controllers,
where it belongs.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
.../ti-gpmc.txt = memory-controllers/ti/gpmc.txt} |0
1 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt =
memory-controllers/ti/gpmc.txt} (100%)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/memory-controllers/ti/gpmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/bus/ti-gpmc.txt
rename to Documentation/devicetree/bindings/memory-controllers/ti/gpmc.txt
I am fine with that. However, make sure you CC the device-tree mailing list.
Sorry about that. I also forgot to put Daniel Mack in CC, who added this
document in the first place.
@Daniel: what do you think?
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error: OMAP randconfig / mvebu
On Thu, Feb 14, 2013 at 10:09:26AM +, Russell King - ARM Linux wrote: On Fri, Feb 08, 2013 at 02:33:29PM +0100, Arnd Bergmann wrote: On Friday 08 February 2013 12:06:44 Gregory CLEMENT wrote: I don't know what to do here, there is no point to build any of the files in mach-mvebu if no SoCs are selected. So either we force to have at least one SoCS selected if ARCH_MVEBU is selected, or we unselect ARCH_MVEB if no SoCs are selected. The latter does not work, because that would introduce a circular dependency in Kconfig. I suppose rearranging the mvebu Makefile like this would do. Signed-off-by: Arnd Bergmann a...@arndb.de This error is still present in arm-soc. We're getting close to the next merge window, so either something needs to be dropped from arm-soc, or this needs to get fixed. Can you point me to where can I get the config your building with? Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error: OMAP randconfig / mvebu
On Thu, Feb 14, 2013 at 11:08:03AM +, Russell King - ARM Linux wrote: On Thu, Feb 14, 2013 at 08:03:08AM -0300, Ezequiel Garcia wrote: On Thu, Feb 14, 2013 at 10:09:26AM +, Russell King - ARM Linux wrote: On Fri, Feb 08, 2013 at 02:33:29PM +0100, Arnd Bergmann wrote: On Friday 08 February 2013 12:06:44 Gregory CLEMENT wrote: I don't know what to do here, there is no point to build any of the files in mach-mvebu if no SoCs are selected. So either we force to have at least one SoCS selected if ARCH_MVEBU is selected, or we unselect ARCH_MVEB if no SoCs are selected. The latter does not work, because that would introduce a circular dependency in Kconfig. I suppose rearranging the mvebu Makefile like this would do. Signed-off-by: Arnd Bergmann a...@arndb.de This error is still present in arm-soc. We're getting close to the next merge window, so either something needs to be dropped from arm-soc, or this needs to get fixed. Can you point me to where can I get the config your building with? It's all publically available via my website. I'm kind of new around here, and I have no clue where that may be. I hope you don't mind helping me this time. Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error: OMAP randconfig / mvebu
Hi Arnd, On Thu, Feb 14, 2013 at 11:27:07AM +, Arnd Bergmann wrote: On Thursday 14 February 2013, Ezequiel Garcia wrote: On Thu, Feb 14, 2013 at 11:08:03AM +, Russell King - ARM Linux wrote: It's all publically available via my website. I'm kind of new around here, and I have no clue where that may be. I hope you don't mind helping me this time. Please have a look at http://www.arm.linux.org.uk/developer/build/ Okey. FYI, using the random config file for OMAP4430 and also with a manual config that chooses ARCH_MVEBU but doesn't choose MACH_ARMADA_XP or MACH_ARMADA_370, this make error is *gone* after applying your patch: arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_init_cpus': :(.init.text+0x74): undefined reference to `coherency_get_cpu_count' :(.init.text+0xb8): undefined reference to `armada_mpic_send_doorbell' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_prepare_cpus': :(.init.text+0x250): undefined reference to `set_cpu_coherent' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_boot_secondary': :(.cpuinit.text+0x10): undefined reference to `armada_xp_boot_cpu' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_init': :(.cpuinit.text+0x2c): undefined reference to `armada_xp_mpic_smp_cpu_init' arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_startup': :(.cpuinit.text+0x40): undefined reference to `ll_set_cpu_coherent' Now, using the random config there's a new error, unrelated to the previous one: ERROR: twl6030_interrupt_unmask [drivers/usb/otg/twl6030-usb.ko] undefined! ERROR: twl_i2c_read_u8 [drivers/usb/otg/twl6030-usb.ko] undefined! ERROR: twl_i2c_write_u8 [drivers/usb/otg/twl6030-usb.ko] undefined! ERROR: twl6030_interrupt_mask [drivers/usb/otg/twl6030-usb.ko] undefined! Regards, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error: OMAP randconfig / mvebu
Arnd, On Thu, Feb 14, 2013 at 12:21:16PM +, Arnd Bergmann wrote: On Thursday 14 February 2013, Ezequiel Garcia wrote: Now, using the random config there's a new error, unrelated to the previous one: ERROR: twl6030_interrupt_unmask [drivers/usb/otg/twl6030-usb.ko] undefined! ERROR: twl_i2c_read_u8 [drivers/usb/otg/twl6030-usb.ko] undefined! ERROR: twl_i2c_write_u8 [drivers/usb/otg/twl6030-usb.ko] undefined! ERROR: twl6030_interrupt_mask [drivers/usb/otg/twl6030-usb.ko] undefined! Yes, I guess that is an unrelated error. However, my patch also wasn't correct because it is not allowed to have an empty list of objects. There is an updated patch below, I could add that straight to the branch that caused the problem if it looks ok to you. The compile error is fixed here with this patch also. Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Guidelines to move mach-omap2/gpmc to drivers/memory-controller
Hello, I'd like to know which are the current constraints preventing us from moving OMAP's GPMC memory controller driver from mach-omap2/ to drivers/memory-controller. I imagine one of the biggest issues is GPMC's dependency on hwmod code. Can anyone shed some light on how to handle this? Is there any way to move hwmod to some place under drivers/...? Thanks, -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/8] ARM: omap2: gpmc: Fix gpmc_cs_reserved() return value
Hi Anil,
On Fri, Feb 15, 2013 at 09:49:21PM +0530, Anil Kumar wrote:
Hi,
On Tue, Feb 12, 2013 at 8:48 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
Currently gpmc_cs_reserved() return value is somewhat inconsistent,
returning a negative value on an error condition, a positive value
if the chip select is reserved and zero if it's available.
Fix this by returning a boolean value as the function name suggests:
* true if the chip select is reserved,
* false if it's available
Suggested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
---
Changelog from v1:
* As suggested by Felipe Balbi, fix return code to a boolean
arch/arm/mach-omap2/gpmc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index bd3bc93..fa4764f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -452,10 +452,10 @@ static int gpmc_cs_set_reserved(int cs, int reserved)
return 0;
}
-static int gpmc_cs_reserved(int cs)
+static bool gpmc_cs_reserved(int cs)
{
if (cs GPMC_CS_NUM)
- return -ENODEV;
+ return true;
return gpmc_cs_map (1 cs);
}
commit 6797b4fe0e554ce71f47038fd929c9ca929a9f3c
Marking all the chip-selects as reserved by default.
In this case gpmc_cs_map is 0xff. So it will return 0x1 if cs is 0.
So gpmc_cs_request() function will fail in nand (gpmc-nand.c) case.
I am taking reference, branch omap-for-v3.9/gpmc of git tree
http://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
I am sorry if this question is very vague.
If I understand correctly your concern, I believe you've missed this
patch submitted by Jon Hunter and not yet merged:
ARM: OMAP2+: Fix-up gpmc merge error
With this patch every chip-select is cleared on gpmc_probe()
as soon as GPMC driver initializes, and before we can request any
NAND/NOR child.
I hope this answers your question.
Feel free to test the series and send your Tested-by!
Thanks,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: omap3: Add gpmc node
Hi Anil,
On Sat, Feb 16, 2013 at 05:08:27PM +0530, Anil Kumar wrote:
Add gpmc DT node.
Signed-off-by: Anil Kumar anilk...@gmail.com
---
:100644 100644 1acc261... 9f36531... March/arm/boot/dts/omap3.dtsi
arch/arm/boot/dts/omap3.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..9f36531 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,16 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6e00 0x100;
+ interrupts = 20;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 4;
+ #address-cells = 2;
+ #size-cells = 1;
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This patch has been already sent twice to the mailing list.
Perhaps it would be more polite if you could base your work on
one of those instead of sending it yourself again.
Florian Vaussard sent one on January 28th:
[PATCH 1/2] ARM: dts: OMAP3: Add GPMC controller
Javier Martinez Canillas sent another one on February 09th:
[PATCH RFC 6/7] ARM: dts: OMAP: Add an GPMC node for OMAP3
Moreover, you could help to get patches merged faster by sending
your Acked-by or Tested-by.
Thanks,
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Guidelines to move mach-omap2/gpmc to drivers/memory-controller
Hi Jon, On Fri, Feb 15, 2013 at 02:08:08PM -0600, Jon Hunter wrote: On 02/15/2013 01:53 PM, Paul Walmsley wrote: Hi, On Fri, 15 Feb 2013, Ezequiel Garcia wrote: I imagine one of the biggest issues is GPMC's dependency on hwmod code. Can anyone shed some light on how to handle this? What dependency is this? I'm not aware of any GPMC dependency to hwmod; there shouldn't be any. If Ezequiel is referring to the code in omap_gpmc_init() that is looking up the hwmod struct for gpmc, then this not a dependency. This function should remain in mach-omap2/gpmc.c and not be moved into drivers/. Yes, I was referring to that code. Eventually once we have migrated to DT, this function will be removed altogether. Mmm, I see. So I might try to move GPMC and friends to drivers/memory keeping the hwmod code inside mach-omap2. I already did a few tests and I **think** that with a little luck we can have a not-so-intrusive patch that moves GPMC. @Jon: Do you think it's worth the effort? -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/14] ARM: OMAP2+: Add additional GPMC timing parameters
Hi Jon, On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote: [...] + if (!of_property_read_u32(np, gpmc,bus-turnaround, val)) + gpmc_t-bus_turnaround = val; + AFAIK, you don't need to test if the property is defined. You can just read it straightforward, and if the property is not defined then nothing will be stored in your variable: of_property_read_u32(np, gpmc,bus-turnaround, gpmc_t-bus_turnaround); You can simplify *a lot* your patch with this, and I believe you could also clean existent code. -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/14] ARM: OMAP2+: Add additional GPMC timing parameters
On Fri, Mar 1, 2013 at 5:11 PM, Ezequiel Garcia elezegar...@gmail.com wrote: Hi Jon, On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote: [...] + if (!of_property_read_u32(np, gpmc,bus-turnaround, val)) + gpmc_t-bus_turnaround = val; + AFAIK, you don't need to test if the property is defined. You can just read it straightforward, and if the property is not defined then nothing will be stored in your variable: of_property_read_u32(np, gpmc,bus-turnaround, gpmc_t-bus_turnaround); You can simplify *a lot* your patch with this, and I believe you could also clean existent code. Also, since this is somewhat large patchset: would you mind pushing it somewhere so I can just pull a branch? Thanks, -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DT GPMC SRAM and NOR flash support ?
Hi Jon,
Yet more questions :-) See below...
On Wed, Feb 13, 2013 at 7:07 PM, Jon Hunter jon-hun...@ti.com wrote:
You don't need this extra entry if you add simple-bus to
the gpmc node compatible string.
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6800a000 0x1000;
+ interrupts = 20;
+
This simple-bus trick is great and very clean!
I'm working on a new driver, similar to gpmc, called device-bus for Marvell SoC.
One remarkable difference is that I need to *setup* the address space
(sort of allocate the address region) for a child device, before I can
access it.
Using simple-bus is a very clean solution. However I'm facing a strange issue:
the child (physmap driver) probe() is being called *before* the parent
(device-bus driver)
probe(), and so the flash device address space cannot get accessed because
it hasn't been setup yet.
Am I doing something wrong? Or is this the expected behavior?
In the latter case, I won't be able to use a compatible simple-bus
at all, right?
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
Hi Jon,
On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote:
[...]
+static int gpmc_probe_nor_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ struct gpmc_settings gpmc_s;
+ struct gpmc_timings gpmc_t;
+ struct resource res;
+ unsigned long base;
+ int ret, cs;
+
+ if (of_property_read_u32(child, reg, cs) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(child, 0, res)) {
+ dev_err(pdev-dev, %s has malformed 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ ret = gpmc_cs_request(cs, res.end - res.start, base);
How about using resource_size() above?
BTW, I believe it's size = end - start + 1.
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DT GPMC SRAM and NOR flash support ?
On Fri, Mar 1, 2013 at 6:08 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
Hi Jon,
Yet more questions :-) See below...
On Wed, Feb 13, 2013 at 7:07 PM, Jon Hunter jon-hun...@ti.com wrote:
You don't need this extra entry if you add simple-bus to
the gpmc node compatible string.
+ gpmc: gpmc@6800a000 {
+ compatible = ti,omap2420-gpmc, simple-bus;
+ ti,hwmods = gpmc;
+ reg = 0x6800a000 0x1000;
+ interrupts = 20;
+
This simple-bus trick is great and very clean!
I'm working on a new driver, similar to gpmc, called device-bus for Marvell
SoC.
One remarkable difference is that I need to *setup* the address space
(sort of allocate the address region) for a child device, before I can
access it.
Using simple-bus is a very clean solution. However I'm facing a strange issue:
the child (physmap driver) probe() is being called *before* the parent
(device-bus driver)
probe(), and so the flash device address space cannot get accessed because
it hasn't been setup yet.
Ok, now I think I understand that my problem has nothing to do with simple-bus,
but instead related to the driver probing order.
The physmap driver is just being probed before the device bus driver, and so it
won't work.
Now: is there any clean solution?
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
Hi Jon,
On Tue, Feb 26, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote:
+
+Example:
+
+gpmc: gpmc@6e00 {
+ compatible = ti,omap3430-gpmc, simple-bus;
I'm concern about using simple-bus, and I'm not entirely sure this will work.
AFAIK, you can't correlate a parent-child relationship in the device tree
to the order in which drivers will be probed,
so it's only a matter of coincidence if this is working for you right now.
The GPMC code is in arch/arm/mach-omap2, is located *before* the mtd code
in the Makefile, and thus the GPMC driver loads *before* the MTD code.
Morevore, I believe that when we move GPMC from arch/arm/mach-omap2
to drivers/memory where it should be, this 'simple-bus' will stop
working properly.
Of course, I can be wrong, but I think you will have to find some other way
to initialize the GPMC's childs.
--
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
Hi Jon, On Tue, Mar 5, 2013 at 2:30 PM, Jon Hunter jon-hun...@ti.com wrote: This really highlights a weakness in the GPMC driver, particularly for NOR, where the child device can only be probed once the parent is probed. I don't see this as being DT specific issue, because even on older OMAP boards we always registered the NOR flash device independently of the GPMC device. So we have always been susceptible to this problem AFAICT. This is admittedly a hack, but I am curious if you add the pinctrl properties to the NOR node, if this would also defer the probe on the NOR device? Ideally it would be great to defer the probing of the child until the parent has been probed successfully. This seems related to the probing parent-child ordering probing I pointed out in a previous mail, isn't it? (which by the way, I'll answer when I can gather some more convincing feedback). I don't have OMAP NOR boards, so I'm not entirely familiar to the way GPMC registers the NOR device. However, by looking into board-flash.c:board_nor_init() function, it seems to me that: 1. first we request the CS with gpmc_cs_request() and 2. later we register the NOR device explicitly with platform_device_register(). So, unless I'm missing something, we force the NOR device to be probed *after* the GPMC device. This is definitely the way NAND, OneNAND is handled. On the otherside, by using 'simple-bus' you create your devices first, when the whole device-tree is parsed and later the drivers are probed at module_initcall time. So, AFAIK, this problem is DT specific. On the other side, when you say we should defer the probing of the child. Do you mean changing something in physmap/NAND/etc. drivers? Please keep in mind, I have nothing against using simple-bus, since it's a very clean solution. It's just that it seems to me it will be problematic. Moreover, the fix shouldn't be too complicated (still working on this). I'll try to post my Device Bus driver soon (similar to GPMC) and also I'll try to answer the previous discussion with some information on why I think this won't work. (I hope I'm not making too much noise with this) -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
Jon, On Tue, Mar 5, 2013 at 6:34 PM, Jon Hunter jon-hun...@ti.com wrote: By the way, with this version you should remove simple-bus from your gpmc node compatible strings. I now call of_platform_device_create() to create the child device during the GPMC probe. I think that this is a safer approach. FWIW, using of_platform_device_create() works for my driver. It seems as simple as using a compatible 'simple-bus', with the advantage that it allows to create and probe the child device from its parent. I'll submit this driver by the end of this week, in case you want to take a look at it. Thanks a lot, -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On Wed, Mar 6, 2013 at 1:46 PM, Jon Hunter jon-hun...@ti.com wrote: On 03/06/2013 05:58 AM, Ezequiel Garcia wrote: I'll submit this driver by the end of this week, in case you want to take a look at it. Ok, but this is not for omap right? No, this is a new driver for a memory controller that's available on some Marvell SoC. It will be located in drivers/memory/. I don't have any omap boards with a NOR device to test this, but the discussion and the patches were really helpful! Thanks, -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/14] ARM: OMAP2+: Add device-tree support for NOR flash
On Wed, Mar 6, 2013 at 1:54 PM, Ezequiel Garcia elezegar...@gmail.com wrote: On Wed, Mar 6, 2013 at 1:46 PM, Jon Hunter jon-hun...@ti.com wrote: On 03/06/2013 05:58 AM, Ezequiel Garcia wrote: I'll submit this driver by the end of this week, in case you want to take a look at it. Ok, but this is not for omap right? No, this is a new driver for a memory controller that's available on some Marvell SoC. It will be located in drivers/memory/. Slightly OT: if anyone wants to see the memory-controller driver for mvebu platforms, I just posted in lakml. It's this patchset: [PATCH 0/5] Device Bus support for Marvell EBU SoC -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas jav...@dowhile0.org wrote: On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter jon-hun...@ti.com wrote: Yes you are correct. In general, I have been trying to stay some-what consistent with what hwmod was doing as this was being auto-generated by some hardware design specs and I believe they wanted to eventually get to the point where DT files would be auto-generated too for OMAP. Furthermore my understanding is that the smallest page that can be mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or 0x1000 it will map a 4kB page (I could be wrong here). I don't have any strong feelings here but will do what the consensus prefers. Yes, you are right here. I forget that ioremap() does a page-aligned mapping and since the minimum page size for ARM is 4KB as you said, there is no difference between using 0x2d0 and 0x1000. Sorry for the noise. Certainly, I don't have strong feelings about this. FWIW, mvebu maintainers imposes a minimal address space request policy. On the other side, it seems to me we shouldn't look at internal kernel implementation (i.e. ioremap page-alignment) to make this decision. Somehow, I feel this is almost a nitpick, so don't take this too seriously. Regards, -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On Thu, Mar 14, 2013 at 12:50 PM, Jon Hunter jon-hun...@ti.com wrote: Yes, I full agree with that as well. The size should be purely HW related. So we should not take any assumption about the page size / alignment. Ok, what is best to use? The size from hwmod structures or the size from the documentation? My personal vote is: according to hardware documentation is the right thing, and it's what we're doing in mvebu. -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 02/18] ARM: OMAP2+: Add variable to store number of GPMC waitpins
Hi Jon,
On Fri, Mar 15, 2013 at 10:21:00AM -0500, Jon Hunter wrote:
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of wait-pins for a given device. This will
allow us to detect if the wait-pin being selected is valid or not.
When booting with device-tree read the number of wait-pins from the
device-tree blob. When device-tree is not used set the number of
wait-pins to 4 which is valid for OMAP2-5 devices. Newer devices
that have less wait-pins (such as AM335x) only support booting with
device-tree and so hard-coding the wait-pin number when not using
device-tree is fine.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ef655d9..88a261c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -108,6 +108,8 @@
#define GPMC_HAS_WR_ACCESS 0x1
#define GPMC_HAS_WR_DATA_MUX_BUS0x2
+#define GPMC_NR_WAITPINS 4
+
/* XXX: Only NAND irq has been considered,currently these are the only ones
used
*/
#define GPMC_NR_IRQ 2
@@ -153,6 +155,7 @@ static struct resourcegpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
/* Define chip-selects as reserved by default until probe completes */
static unsigned int gpmc_cs_map = ((1 GPMC_CS_NUM) - 1);
+static unsigned int gpmc_nr_waitpins;
static struct device *gpmc_dev;
static int gpmc_irq;
static resource_size_t phys_base, mem_size;
@@ -1297,6 +1300,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
if (!of_id)
return 0;
+ ret = of_property_read_u32(pdev-dev.of_node, gpmc,num-waitpins,
+gpmc_nr_waitpins);
+ if (ret 0) {
+ pr_err(%s: number of wait pins not found!\n, __func__);
+ return ret;
+ }
+
for_each_node_by_name(child, nand) {
ret = gpmc_probe_nand_child(pdev, child);
if (ret 0) {
@@ -1372,6 +1382,12 @@ static int gpmc_probe(struct platform_device *pdev)
if (gpmc_setup_irq() 0)
dev_warn(gpmc_dev, gpmc_setup_irq failed\n);
+ /* Now the GPMC is initialised, unreserve the chip-selects */
+ gpmc_cs_map = 0;
The above seems to be a remanent of another patch.
I think you already sent that one, right?
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 10/18] ARM: OMAP2+: Add function to read GPMC settings from device-tree
Hi Jon,
I have some tiny nitpicks...
On Fri, Mar 15, 2013 at 10:21:08AM -0500, Jon Hunter wrote:
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC device-tree binding documentation to describe these
options.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 23 ++
arch/arm/mach-omap2/gpmc.c| 49
+
arch/arm/mach-omap2/gpmc.h|2 +
3 files changed, 74 insertions(+)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 5ddb2e9..6fde1cf 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -65,6 +65,29 @@ The following are only applicable to OMAP3+ and AM335x:
- gpmc,wr-access
- gpmc,wr-data-mux-bus
+GPMC chip-select settings properties for child nodes. All are optional.
+
+- gpmc,burst-length Page/burst length. Must be 4, 8 or 16.
+- gpmc,burst-wrapEnables wrap bursting
+- gpmc,burst-readEnables read page/burst mode
+- gpmc,burst-write Enables write page/burst mode
+- gpmc,device-nand Device is NAND
+- gpmc,device-width Total width of device(s) connected to a GPMC
+ chip-select in bytes. The GPMC supports 8-bit
+ and 16-bit devices and so this property must be
+ 1 or 2.
+- gpmc,mux-add-data Address and data multiplexing configuration.
+ Valid values are 1 for address-address-data
+ multiplexing mode and 2 for address-data
+ multiplexing mode.
+- gpmc,sync-read Enables synchronous read. Defaults to asynchronous
+ is this is not set.
+- gpmc,sync-writeEnables synchronous writes. Defaults to asynchronous
+ is this is not set.
+- gpmc,wait-pin Wait-pin used by client. Must be less than
+ gpmc,num-waitpins.
+- gpmc,wait-on-read Enables wait monitoring on reads.
+- gpmc,wait-on-write Enables wait monitoring on writes.
Example for an AM33xx board:
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 3ec1937..1e7eef3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1190,6 +1190,55 @@ static struct of_device_id gpmc_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
+/**
+ * gpmc_read_settings_dt - read gpmc settings from device-tree
+ * @np: pointer to device-tree node for a gpmc child device
+ * @p: pointer to gpmc settings structure
+ *
+ * Reads the GPMC settings for a GPMC child device from device-tree and
+ * stores them in the GPMC settings structure passed. The GPMC settings
+ * structure is initialise to zero by this function and so any previously
s/initialise/initialized ?
+ * stored settings will be clearer.
s/clearer/cleared ?
I'm not an english native speaker,
so please bare with me if I'm wrong on these...
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/18] ARM: OMAP2+: GPMC clean-up and DT update
On Fri, Mar 15, 2013 at 10:20:58AM -0500, Jon Hunter wrote: While adding device-tree support for NOR memories, it became apparent that there is no common way for configuring various GPMC settings for devices that interface to the GPMC. These settings include bus-width, synchronous/asynchronous mode, burst settings, wait monitoring etc. Therefore, to simplify the GPMC code and add device-tree support for NOR, it was first necessary to consolidate how these settings are programmed. Series based upon Mark Jackson's patch [1] and Ezequiel Garcia GPMC clean-up series [2]. Entire series available here [3]. V3 changes: - Rebased on RMK's IS_ERR_VALUE() patch and removed usage of IS_ERR_VALUE() from series. - Fixed BUG in NAND code introduced in V2 by making gpmc_settings structure a local variable (I forgot to initialise structure to zero). - Added fix from Javier to correct return value from gpmc_probe_nor(). V2 changes: - Made gpmc_settings structure local in gpmc_nand_init(). - Use resource_size() API in probe_nor(). - Add kernel-doc for gpmc_cs_program_settings() function. - Use of_platform_device_create() to register NOR devices in probe_nor(). - Add support for GPMC address-address-data multiplexing which required changing GPMC DT property gpmc,mux-add-data to store a 32-bit value and changing mux_add_data member of gpmc_settings to be a 32-bit type instead of bool. - Add detection for incorrect GPMC chip-select base addresses. - Cleaned-up code in gpmc_mem_init() and changed gpmc_mem_init() so that it would not return an error when the GPMC driver is being probed. V1 changes: - Clean-up/simplification of ONENAND initialisation code. - Add a new GPMC structure to unify storage of various GPMC settings (that are non-timing related) for client devices and add a new function to program these settings in a common way. - Migrate initialisation code for existing flash, usb and networking devices to use the new structure and function for GPMC settings. - Add device-tree support for NOR flash memories. - Add additional GPMC timing parameters to GPMC device-tree binding. - Update GPMC NAND and ONENAND device-tree support to retrieve GPMC settings from device-tree. Testing includes: - Boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 SDP with and without device-tree present. - OMAP2420 H4 board has NOR flash and OMAP3430 SDP has NOR, NAND and ONENAND flash. So verified that flash is detected on boot as expected. Note additional patches [4] are required for OMAP2420 H4 and OMAP3430 SDP dts files in order to enable flash memory support. - All of the above boards use GPMC for interfacing to a networking chip and so verified that networking is working wit this series. However, please note that networking is not currently supported on these boards when booting with DT and so networking is only tested without DT. [1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/94765 [2] http://comments.gmane.org/gmane.linux.ports.arm.omap/93784 [3] https://github.com/jonhunter/linux/tree/omap-gpmc-for-v3.10 [4] https://github.com/jonhunter/linux/tree/omap-dt-for-v3.10 Javier Martinez Canillas (1): ARM: OMAP2+: return -ENODEV if GPMC child device creation fails Jon Hunter (17): ARM: OMAP2+: Simplify code configuring ONENAND devices ARM: OMAP2+: Add variable to store number of GPMC waitpins ARM: OMAP2+: Add structure for storing GPMC settings ARM: OMAP2+: Add function for configuring GPMC settings ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings() ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings() ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings() ARM: OMAP2+: Don't configure of chip-select options in gpmc_cs_configure() ARM: OMAP2+: Add function to read GPMC settings from device-tree ARM: OMAP2+: Add device-tree support for NOR flash ARM: OMAP2+: Add additional GPMC timing parameters ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT ARM: OMAP2+: Detect incorrectly aligned GPMC base address ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails Documentation/devicetree/bindings/bus/ti-gpmc.txt | 48 +- Documentation/devicetree/bindings/mtd/gpmc-nor.txt | 98 .../devicetree/bindings/mtd/gpmc-onenand.txt |3 + arch/arm/mach-omap2/gpmc-nand.c| 39 +- arch/arm/mach-omap2/gpmc-onenand.c | 110 ++-- arch/arm/mach-omap2/gpmc-smc91x.c | 30 +- arch/arm/mach-omap2/gpmc.c | 524 +++- arch/arm/mach-omap2/gpmc.h | 37 +- arch/arm/mach-omap2/usb-tusb6010.c | 62
Re: musb: dsps: make it work with two instances
Hi Sebastian, On Fri, Jul 5, 2013 at 10:32 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: This enables the two musb instances on am335x to work. I like a lot the idea of splitting the DT representation of the two USB instances. The DT binding looks much better this way. After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. Also, FWIW, I think that having a separate USB phy for am35xx would be much better. Nice job! -- Ezequiel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: use for OMAP5 as well
Hi guys, On Fri, Jun 28, 2013 at 09:27:20PM +0530, Balaji T K wrote: On Friday 28 June 2013 06:04 PM, a-bin...@ti.com wrote: From: Amarinder Bindra a-bin...@ti.com OMAP's hs_mmc driver is also used for OMAP5 MMC controller operation. Considering that the device tree entries are already there for this, allow the driver to be built when only OMAP5 is enabled. This allows MMC root filesystems to be available in OMAP5 only configurations. Signed-off-by: Amarinder Bindra a-bin...@ti.com Acked-by: Felipe Balbi ba...@ti.com Acked-by: Nishanth Menon n...@ti.com Looks good to me, Acked-by: Balaji T K balaj...@ti.com I came across this same issue while trying MMC patches on AM3xx, which is nor OMAP3 neither OMAP4. Now, looking at the driver I don't see any OMAP-specific bits (welcome to the multiplatform world ;-) so I think we can just remove the 'depends' line. Something like this: --- diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index 9ab8f8d..bade7f2 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -273,10 +273,9 @@ config MMC_OMAP config MMC_OMAP_HS tristate TI OMAP High Speed Multimedia Card Interface support - depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4 help This selects the TI OMAP High Speed Multimedia card Interface. - If you have an OMAP2430 or OMAP3 board or OMAP4 board with a + If you have an OMAP2430, OMAP3, OMAP4 or AM3xx board with a Multimedia Card slot, say Y or M here. If unsure, say N. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: use for OMAP5 as well
On Mon, Jul 08, 2013 at 02:58:28PM -0500, Nishanth Menon wrote: On 10:46-20130708, Felipe Balbi wrote: On Sun, Jul 07, 2013 at 05:13:10PM -0300, Ezequiel Garcia wrote: Hi guys, On Fri, Jun 28, 2013 at 09:27:20PM +0530, Balaji T K wrote: On Friday 28 June 2013 06:04 PM, a-bin...@ti.com wrote: From: Amarinder Bindra a-bin...@ti.com OMAP's hs_mmc driver is also used for OMAP5 MMC controller operation. Considering that the device tree entries are already there for this, allow the driver to be built when only OMAP5 is enabled. This allows MMC root filesystems to be available in OMAP5 only configurations. Signed-off-by: Amarinder Bindra a-bin...@ti.com Acked-by: Felipe Balbi ba...@ti.com Acked-by: Nishanth Menon n...@ti.com Looks good to me, Acked-by: Balaji T K balaj...@ti.com I came across this same issue while trying MMC patches on AM3xx, which is nor OMAP3 neither OMAP4. Now, looking at the driver I don't see any OMAP-specific bits (welcome to the multiplatform world ;-) so I think we can just remove the 'depends' line. Something like this: frankly speaking, this driver should be deleted and all users should be moved to sdhci. OMAP's HSMMC controller is compatible with SDHCI except for a couple quirks which can be easily worked around. @Felipe: Do you mind giving me some hints about this quirks? I'm not too familiar with these drivers. Do we take that as a NAK to this specific patch? I am not complaining about the future migration to a solution that is much more generic and scalable, but having fixes for current problems should'nt be ignored IMHO. Of course. How about a depends on CONFIG_ARCH_OMAP2PLUS instead? will that solve our pains with all OMAP2+ usin this? Yes, I think that using ARCH_OMAP2PLUS should do. FWIW, until we have sdhci ready to replace omap_hsmmc, we have no choice but to apply such a patch. @Nishant, Balaji: Can you take care of resending this? Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Add phy support for AM335X platform using Generic PHy framework
Hi, On Mon, Jul 08, 2013 at 09:44:33PM +0200, Sebastian Andrzej Siewior wrote: We need two nodes each one with a glue layer and a musb child node. The instances crap in kernel has to vanish. Also that means your phy nodes are wrong. This is not musb with two ports but two musb instances each with one port. I agree completely. The current DT representation looks definitely odd, and we should be looking at improving it. I wonder if this is now possible, given the DT is supposed to be stable ABI. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mmc: omap_hsmmc: use the generic config for omap2plus devices
On Wed, Jul 10, 2013 at 09:36:24PM +0530, a-bin...@ti.com wrote: From: Amarinder Bindra a-bin...@ti.com OMAP's hs_mmc driver is used for MMC controller operation on many omap2plus SoCs (OMAP2430, OMAP3, 4, 5 and AM335x). Considering that the device tree entries are already present for these, allow the driver to be built using the config ARCH_OMAP2PLUS rather than individually adding a config for each SoC to enable the support. Use COMPILE_TEST to enable the build for other platforms. Signed-off-by: Amarinder Bindra a-bin...@ti.com Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com Cc: Felipe Balbi ba...@ti.com Cc: Nishanth Menon n...@ti.com Acked-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: musb: dsps: make it work with two instances
Hi Sebastian, On Wed, Jul 17, 2013 at 07:12:29PM +0200, Sebastian Andrzej Siewior wrote: After some minor DT tweaking on the current patchset, I've managed to detect an USB mass storage device in the second instance (host / usb1) using a Beaglebone black board. Beaglebone black, that one has a different device tree which is not mainline, right? Beaglebone black it is. But I'm almost sure I just used the ambone.dts file that's mainlined. I just changed the mode or something like that, very minor tweaking indeed, altough right now I don't remember exactly which changes. However, after I unplug the device, it's not recognized when I replug it. Maybe you can take a look at this; i'll do some more testings and see what I can come up with. I figured out why my Host is not recognized on the second plug: At module load time, musb_start() is executed and it sets the MUSB_DEVCTL_SESSION in devctl. After the device is unplugged dsps_musb_try_idle() schedules a timer which executes the local otg_timer() function. Since the phy is in OTG_STATE_A_WAIT_BCON state, the MUSB_DEVCTL_SESSION bit gets removed. If the removal of the bit is ignored, the device is recognized after a re-plug. Mmmm... okey. Interesting insight, thanks! Also, FWIW, I think that having a separate USB phy for am35xx would be much better. So you would prefer a new file with 90% copy of what we already have in the nop_phy? No, of course not. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap2: Use a consistent AM33XX SoC option description
Fix the option description to match the other TI SoCs. This is just a cosmetic change. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- arch/arm/mach-omap2/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 76170dd..56021c6 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -64,7 +64,7 @@ config SOC_OMAP5 select ARM_ERRATA_798181 if SMP config SOC_AM33XX - bool AM33XX support + bool TI AM33XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS select ARM_CPU_SUSPEND if PM -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Add phy support for AM335X platform using Generic PHy framework
On Fri, Jul 19, 2013 at 06:04:33PM +0530, George Cherian wrote: This patch series adds phy support for AM335X platform. This patch series is based on Generic PHY framework [1]. This series has - adds dual musb instances support for am335x platform - adds phy-am-usb driver used in AM platforms - adds OTG callbacks - adds PHY wakeup enable/disable - adds dt bindings for the phys - removes usb-phy and replaced with generic phy apis in glue layer All these changes are avilable at [2] [1] - http://marc.info/?l=linux-usbm=137224750928570w=2 [2] - git://git.ti.com/~georgecherian/ti-linux-kernel/georgec-connectivity-linux-feature-tree.git am335x-phy-driver-v2 George Cherian (4): usb: phy: phy-omap-control: Add API to power and wakeup phy: phy-am-usb: Add PHY driver for am platform arm: dts: Add USB phy nodes for AM33XX Is there any reason why there's no DT binding patch to this series? (aka Documentation/devicetree/... + sent to devicetree list) (sorry if this has been already explained somewhere...) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2: Use a consistent AM33XX SoC option description
On Fri, Aug 09, 2013 at 11:18:43AM +0200, Javier Martinez Canillas wrote: On Thu, Aug 8, 2013 at 11:32 PM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: Fix the option description to match the other TI SoCs. This is just a cosmetic change. Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com --- arch/arm/mach-omap2/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 76170dd..56021c6 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -64,7 +64,7 @@ config SOC_OMAP5 select ARM_ERRATA_798181 if SMP config SOC_AM33XX - bool AM33XX support + bool TI AM33XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS select ARM_CPU_SUSPEND if PM -- 1.8.1.5 Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org ping? -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 04/10] mtd: nand: omap: fix device scan: NAND_CMD_READID, NAND_CMD_RESET, CMD_CMD_PARAM use only x8 bus
Brian, On Tue, Oct 22, 2013 at 11:13:32PM -0700, Brian Norris wrote: On 10/22/2013 10:07 PM, Gupta, Pekon wrote: From: Brian Norris [mailto:computersforpe...@gmail.com] On Sat, Oct 19, 2013 at 02:14:08PM +0530, Pekon Gupta wrote: [...] Thus this patch run nand_scan_ident() with driver configured as x8 device. So are you saying that the driver currently doesn't work if you started in x16 buswidth? Are you having problems with a particular setup? What sort of devices are you testing? No, I'm saying that you cannot read ONFI params in x16 mode. And, that is what was pointed out in following commit log also .. (Reference to 3.3.2. Target Initialization: given above) So, if I run nand_scan_ident() in x16 mode, my ONFI detection would fail for sure .. But you cannot just run nand_scan_ident() with !(chip-options NAND_BUSWIDTH_16) when your devices is x16. You need to solve the ONFI detection problem while correctly specifying NAND_BUSWIDTH_16. Since you didn't answer the other 2 questions there: are you testing any x16 devices? I'm jumping on this thread without having read all the discussion, sorry about that. FWIW, I have a Beaglebone with a 16-bit bus NAND attached to it. Coincidentally, yesterday I was doing some tests as I'm ramping up the NAND and I found that weird double nand_scan_ident() call. The whole thing looks buggy to me, so I'm happy to help, review, test and patches to take care of this. I'm using some TI SDK with some ancient v3.2.x (with no git history!), but from this discussion it seems the issue is still present in mainline. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 04/10] mtd: nand: omap: fix device scan: NAND_CMD_READID, NAND_CMD_RESET, CMD_CMD_PARAM use only x8 bus
Hi Gupta,
On Wed, Oct 23, 2013 at 01:15:20PM +, Gupta, Pekon wrote:
Hi,
From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com]
[...]
FWIW, I have a Beaglebone with a 16-bit bus NAND attached to it.
Coincidentally, yesterday I was doing some tests as I'm ramping up the
NAND and I found that weird double nand_scan_ident() call.
The whole thing looks buggy to me, so I'm happy to help, review, test
and patches to take care of this.
Yes, thanks .. that would be of great help..
And may be your experience of Atmel drivers would help me here..
It's not Atmel, but Marvell :-)
*Correct, should not be double calls to nand_scan_ident()..*
But there is a constrain in nand_base.c, that it does not allow ONFI
page reading in x16 mode.. So how to overcome that..
I see the similar implementation in your ATMEL driver, it does not use
NAND_BUSWIDTH_AUTO so how do you perform ONFI read
for x16 devices ?
drivers/mtd/nand/atmel_nand.c @@atmel_nand_probe()
/* here you move to x16 mode based on your DT or platform data */
if (host-board.bus_width_16) /* 16-bit bus width */
nand_chip-options |= NAND_BUSWIDTH_16;
/* And then you call nand_scan_ident */
/* first scan to find the device and get the page size */
if (nand_scan_ident(mtd, 1, NULL)) {
res = -ENXIO;
goto err_scan_ident;
}
Wouldn't this fail, _unless_ your device is listed in nand_flash_id[] ?
because it would not be able to read ONFI params..
Refer below commit..
commit 0ce82b7f7b7373b16ecf7b5725e21e2975204500
Author: Matthieu CASTET matthieu.cas...@parrot.com
AuthorDate: 2013-01-16
Not my driver, but I'm taking a look at it now. Not sure if I'll get
into something here.
I'm using some TI SDK with some ancient v3.2.x (with no git history!),
but from this discussion it seems the issue is still present in
mainline.
Aah sorry, then you might have some problem here in rebasing the
patches. But still if you can, thanks much ..
I'm currently trying mainline (just for this issue not for my product).
I just need some time to prepare the bootargs and write a DT node for
the NAND cape.
Again, not sure if I'll make some progress, but I'll give it a shot :-)
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 10/10] mtd: nand: omap: remove selection of BCH ecc-scheme via KConfig
Gupta, I already have a question :-) On Sat, Oct 19, 2013 at 02:14:14PM +0530, Pekon Gupta wrote: With OMAP NAND driver updates, selection of ecc-scheme: *DT enabled kernel* depends on ti,nand-ecc-opt and ti,elm-id DT bindings. *Non DT enabled kernel* depends on elm_dev and ecc-scheme passed along with platform-data from board file. So, selection of ecc-scheme (BCH8 or BCH4) from KConfig can be removed Signed-off-by: Pekon Gupta pe...@ti.com --- drivers/mtd/nand/Kconfig | 40 ++-- 1 file changed, 6 insertions(+), 34 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index d885298..93ae6a6 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -96,43 +96,15 @@ config MTD_NAND_OMAP2 config MTD_NAND_OMAP_BCH depends on MTD_NAND MTD_NAND_OMAP2 ARCH_OMAP3 I'm wondering how are you testing this in your SOC_AM33XX board (which is not ARCH_OMAP3). You probably have ARCH_OMAP3 always selected? IMO, no need to depend on any ARCH_xxx, just make it depend on the driver option itself, which already depends on ARCH_OMAP2PLUS (which is the bigger SoC family). Care to send a one-patch fix for that, so this *independent* bug can be taken by Brian? Please add my Reported-by when you do so. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
