AW: USB problem on beagleboard clone
Hi, -Ursprüngliche Nachricht- Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] Im Auftrag von Paul Walmsley Gesendet: Mittwoch, 19. September 2012 03:24 An: Maximilian Schwerin Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Betreff: Re: USB problem on beagleboard clone Hi On Fri, 14 Sep 2012, Maximilian Schwerin wrote: we've designed two beagle board clones (two different layouts) for a customer. After quite some time without any problems they are now seeing USB problems on some of the boards. I have so far not been able to reproduce the problem... The USB port of the OMAP the problems appear on is connected through a TPS65950 to a LAN9514 USB Hub + Ethernet Chip. Attached is the kernel output. I'm not even sure if this is related to our board, or if this might be a misbehaving device?! If someone has an idea what this could be and what I could do to fix or at least further debug the problem please speak up. Are these BeagleBoard 3530 or BeagleBoard XM 3730 clones? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html They're BeagleBoard XM clones. We're still trying to find out what the real problem is. The problem persists across three separate layouts using the same USB device and application. We're currently trying to see if this is related to MUSB only by using an EHCI port on the same board with the same device and application. Regards, m. pgprNnJzTfbdi.pgp Description: PGP signature
Re: [PATCH 2/3] OMAP i2c: pinctrl-ify i2c-omap.c
On Wednesday 19 September 2012 09:37 PM, Pantelis Antoniou wrote: #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h +#include linux/err.h err.h include may be removed. -- 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: Initialising omapfb on AM3517 issues
Hi,
On Tue, 2012-09-18 at 16:41 +, Marc Murphy wrote:
Hello all,
I have been moving from the ti 2.6.37 BSP to the 3.x kernel with quite a bit
of success, the main issue I have at the moment is trying to get the frame
buffer and any displays I have initialised.
[2.805358] omapfb omapfb: no driver for display: lcd
[2.810729] omapfb omapfb: no displays
[2.814666] omapfb omapfb: failed to setup omapfb
I have tried a few versions of release and none of them will initialise;
Currently on
[0.00] Linux version 3.6.0-rc3
I have started with board-am3517evm display config and even that doesn't
initialise. Is there something I am missing with the configs or is there a
patch required to get the feature to work.
My current config options use;
#
# Graphics support
#
CONFIG_DRM=y
omapdrm and omapfb cannot be used at the same time. That said, you don't
seem to enable omapdrm, only the core drm support, so it shouldn't
matter. But you don't need CONFIG_DRM if you use omapfb.
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
#
# Frame buffer hardware drivers
#
CONFIG_OMAP2_VRAM=y
CONFIG_OMAP2_VRFB=y
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_VRAM_SIZE=12
CONFIG_OMAP2_DSS_DPI=y
CONFIG_OMAP2_DSS_VENC=y
CONFIG_OMAP2_DSS_DSI=y
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=1
CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET=y
CONFIG_FB_OMAP2=y
CONFIG_FB_OMAP2_NUM_FBS=3
#
# OMAP2/3 Display Device Drivers
#
CONFIG_PANEL_GENERIC_DPI=y
CONFIG_PANEL_SHARP_LS037V7DW01=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
And the init structs are
static int am3517_evm_panel_enable_lcd(struct omap_dss_device *dssdev)
{
gpio_set_value(TAM3517_DVI_PON_GPIO, 0);
gpio_set_value(TAM3517_LCD_ENVDD_GPIO, 0);
gpio_set_value(TAM3517_LCD_PON_GPIO, 1);
printk(LCD voltage on\n);
return 0;
}
static void am3517_evm_panel_disable_lcd(struct omap_dss_device *dssdev)
{
gpio_set_value(TAM3517_LCD_ENVDD_GPIO, 1);
gpio_set_value(TAM3517_LCD_PON_GPIO, 0);
}
static struct panel_generic_dpi_data lcd_panel = {
//.name = generic_dpi_panel,
You need to define name for the panel you have. You can see the list of
supported panels in drivers/video/omap2/displays/panel-generic-dpi.c. If
you don't give a name, the panel driver doesn't start.
There's also a problem with the vdds_dsi regulator. Search the list for
[PATCH] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx. The
patch to fix it hasn't been merged yet.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx
On Tue, 2012-08-21 at 13:39 +0300, Tomi Valkeinen wrote: Hi, On Wed, 2012-08-15 at 15:16 -0400, Raphael Assenat wrote: On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator and the framebuffer cannot be enabled. However, this check does not seem to apply to AM3505/17 chips. Taking into account comments received after my first patch[1], I have added entries to dss_features.c to support the am35xx soc. Then in dpi.c, instead of using cpu_is_omap34xx() and soc_is_am35xx(), a call to dss_has_feature() is used. [1] http://marc.info/?l=linux-fbdevm=134272967203409w=2 Signed-off-by: Raphaël Assénat r...@8d.com Chandrabhanu has posted a series that removes a bunch of cpu_is checks from omapdss. On of them is the use of VDDS_DSI in dpi.c. Can you wait until I've merged those patches to omapdss master branch (probably a few days), and then create a new patch that adds AM35xx to dss_features? If you have time, can you revisit this? The current omapdss master branch has some cleanups for the cpu check: git://gitorious.org/linux-omap-dss2/linux.git master Tomi signature.asc Description: This is a digitally signed message part
[GIT PULL] ARM: OMAP5: Enable arch timer support
Tony, Here is the pull request which enables the architected cpu local timer support for OMAP5 devices. The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2: Linux 3.6-rc6 (2012-09-16 14:58:51 -0700) are available in the git repository at: g...@github.com:SantoshShilimkar/linux.git for_3.7/omap5_arch_timer for you to fetch changes up to 3c7c5dab44d6c8861bc86dab924353d8d40344f8: ARM: OMAP5: Enable arch timer support (2012-09-19 13:00:37 +0530) Santosh Shilimkar (2): ARM: OMAP: Add initialisation for the real-time counter. ARM: OMAP5: Enable arch timer support arch/arm/boot/dts/omap5.dtsi | 12 ++ arch/arm/mach-omap2/Kconfig |5 +++ arch/arm/mach-omap2/timer.c | 97 +- 3 files changed, 113 insertions(+), 1 deletion(-) -- 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: [GIT PULL] ARM: OMAP5: Enable arch timer support
(With fixed git URL) On Wed, Sep 19, 2012 at 1:21 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Tony, Here is the pull request which enables the architected cpu local timer support for OMAP5 devices. The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2: Linux 3.6-rc6 (2012-09-16 14:58:51 -0700) are available in the git repository at: g...@github.com:SantoshShilimkar/linux.git for_3.7/omap5_arch_timer git://github.com/SantoshShilimkar/linux.git for_3.7/omap5_arch_timer for you to fetch changes up to 3c7c5dab44d6c8861bc86dab924353d8d40344f8: ARM: OMAP5: Enable arch timer support (2012-09-19 13:00:37 +0530) Santosh Shilimkar (2): ARM: OMAP: Add initialisation for the real-time counter. ARM: OMAP5: Enable arch timer support arch/arm/boot/dts/omap5.dtsi | 12 ++ arch/arm/mach-omap2/Kconfig |5 +++ arch/arm/mach-omap2/timer.c | 97 +- 3 files changed, 113 insertions(+), 1 deletion(-) -- 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 2/2] ARM: OMAP5: Enable arch timer support
On Tue, Sep 18, 2012 at 11:23 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120917 23:07]: On Tue, Sep 18, 2012 at 3:09 AM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [120917 14:39]: * Benoit Cousson b-cous...@ti.com [120913 01:57]: Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yes makes sense to me. These may cause bad merge conflicts with Jon's timer patches though? These patches can be applied against any branch so not necessary to only apply against the DT tree. Have you merged Jon's series ? I can refresh the patches against that branch. Another option is I can split the patch so that DT change and timer change is seperated. Let me know what is your preference. Maybe do a pull request for the arch timer and dtimer DT changes? Just sent. It seems that Jon is still working on the fixes series, so let's assume that will need to wait a bit. Ok. Thanks for clarification. Regards Santosh -- 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/8] OMAPDSS: dss device model changes
Hi, This series contains patches that change how omapdss's panel devices (omap_dss_device) are initialized and registered. There are two patches that change behaviour, the rest should be just cleanups: The patch omap_dss_register_device() doesn't take display index affects the number for the displayX sysfs files. This hopefully doesn't affect the userspace, as the number has never been a clear indication of what the particular display is. The patch register only one display device per output affects how panel devices are created. Currently we support multiple panels per output, i.e. you could have DVI and an LCD displays using the same DPI output, as long as the DVI and LCD are not used at the same time. This patch changes the omapdss driver to only register one display device per output. If there are multiple displays for the output, either the first one is picked or, if def_display has been defined in kernel parameters and the def_display is one of the displays for this output, the def_display is picked. See the patch for more information. My belief is that neither patch should break things, but there's the possibility. So I've tried to cc people who might have an opinion about this, or perhaps test their setup with these patches. The series is based on the latest omapdss master branch, and is available at: git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base Tomi Tomi Valkeinen (8): OMAPDSS: omap_dss_register_device() doesn't take display index OMAPDSS: Add dss_get_default_display_name() OMAPDSS: register only one display device per output OMAPDSS: explicitely initialize dssdev-channel for new displays OMAPDSS: handle errors in dss_init_device OMAPDSS: cleanup dss_recheck_connections OMAPDSS: cleanup dss_recheck_connections further OMAPDSS: alloc dssdevs dynamically drivers/video/omap2/dss/core.c| 91 +++-- drivers/video/omap2/dss/display.c | 85 +++--- drivers/video/omap2/dss/dpi.c | 58 ++- drivers/video/omap2/dss/dsi.c | 62 +++-- drivers/video/omap2/dss/dss.h | 15 +++--- drivers/video/omap2/dss/hdmi.c| 70 ++-- drivers/video/omap2/dss/overlay.c | 69 drivers/video/omap2/dss/rfbi.c| 58 ++- drivers/video/omap2/dss/sdi.c | 58 ++- drivers/video/omap2/dss/venc.c| 60 +++- 10 files changed, 428 insertions(+), 198 deletions(-) -- 1.7.9.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
[PATCH 2/8] OMAPDSS: Add dss_get_default_display_name()
Add function dss_get_default_display_name() which returns the name of
the default display, given from the board file or via module parameters.
The default display name can be used by output drivers to decide which
display is the wanted one.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 20c8bc8..315f557 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -57,6 +57,11 @@ bool dss_debug;
module_param_named(debug, dss_debug, bool, 0644);
#endif
+const char *dss_get_default_display_name(void)
+{
+ return core.default_display_name;
+}
+
/* REGULATORS */
struct regulator *dss_get_vdds_dsi(void)
--
1.7.9.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
[PATCH 1/8] OMAPDSS: omap_dss_register_device() doesn't take display index
We used to have all the displays of the board in one list, and we made a
displayX directory in the sysfs, where X was the index of the display
in the list.
This doesn't work anymore with device tree, as there's no single list to
get the number from, and it doesn't work very well even with non-DT as
we need to do some tricks to get the index nowadays.
This patch changes omap_dss_register_device() so that it doesn't take
disp_num as a parameter anymore, but uses a private increasing counter
for the display number.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |9 +
drivers/video/omap2/dss/dpi.c |2 +-
drivers/video/omap2/dss/dsi.c |2 +-
drivers/video/omap2/dss/dss.h |2 +-
drivers/video/omap2/dss/hdmi.c |2 +-
drivers/video/omap2/dss/rfbi.c |2 +-
drivers/video/omap2/dss/sdi.c |2 +-
drivers/video/omap2/dss/venc.c |2 +-
8 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 58bd9c2..20c8bc8 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -450,16 +450,17 @@ static void omap_dss_dev_release(struct device *dev)
reset_device(dev, 0);
}
+static int disp_num_counter;
+
int omap_dss_register_device(struct omap_dss_device *dssdev,
- struct device *parent, int disp_num)
+ struct device *parent)
{
- WARN_ON(!dssdev-driver_name);
-
reset_device(dssdev-dev, 1);
+
dssdev-dev.bus = dss_bus_type;
dssdev-dev.parent = parent;
dssdev-dev.release = omap_dss_dev_release;
- dev_set_name(dssdev-dev, display%d, disp_num);
+ dev_set_name(dssdev-dev, display%d, disp_num_counter++);
return device_register(dssdev-dev);
}
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 5ccce9b..703fc1d 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -388,7 +388,7 @@ static void __init dpi_probe_pdata(struct platform_device
*pdev)
continue;
}
- r = omap_dss_register_device(dssdev, pdev-dev, i);
+ r = omap_dss_register_device(dssdev, pdev-dev);
if (r)
DSSERR(device %s register failed: %d\n,
dssdev-name, r);
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8d815e3..f7078fc 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5027,7 +5027,7 @@ static void __init dsi_probe_pdata(struct platform_device
*dsidev)
continue;
}
- r = omap_dss_register_device(dssdev, dsidev-dev, i);
+ r = omap_dss_register_device(dssdev, dsidev-dev);
if (r)
DSSERR(device %s register failed: %d\n,
dssdev-name, r);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 5e9fd769..7bac8ee 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -185,7 +185,7 @@ int dss_set_min_bus_tput(struct device *dev, unsigned long
tput);
int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file
*));
int omap_dss_register_device(struct omap_dss_device *dssdev,
- struct device *parent, int disp_num);
+ struct device *parent);
void omap_dss_unregister_device(struct omap_dss_device *dssdev);
void omap_dss_unregister_child_devices(struct device *parent);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 83f1845..bb07143 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -923,7 +923,7 @@ static void __init hdmi_probe_pdata(struct platform_device
*pdev)
continue;
}
- r = omap_dss_register_device(dssdev, pdev-dev, i);
+ r = omap_dss_register_device(dssdev, pdev-dev);
if (r)
DSSERR(device %s register failed: %d\n,
dssdev-name, r);
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 2e520d3..845b4e7 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -959,7 +959,7 @@ static void __init rfbi_probe_pdata(struct platform_device
*pdev)
continue;
}
- r = omap_dss_register_device(dssdev, pdev-dev, i);
+ r = omap_dss_register_device(dssdev, pdev-dev);
if (r)
DSSERR(device %s register failed: %d\n,
dssdev-name, r);
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 66c8de4..c9a9045 100644
--- a/drivers/video/omap2/dss/sdi.c
+++
[PATCH 3/8] OMAPDSS: register only one display device per output
We have boards with multiple panel devices connected to the same
physical output, of which only one panel can be enabled at one time.
Examples of these are Overo, where you can use different daughter boards
that have different LCDs, and 3430SDP which has an LCD and a DVI output
and a physical switch to select the active display.
These are supported by omapdss so that we add all the possible display
devices at probe, but the displays are inactive until somebody enables
one. At this point the panel driver starts using the DSS, thus reserving
the physcal resource and excluding the other panels.
This is problematic:
- Panel drivers can't allocate their resources properly at probe(),
because the resources can be shared with other panels. Thus they can
be only reserved at enable time.
- Managing this in omapdss is confusing. It's not natural to have
child devices, which may not even exist (for example, a daughterboard
that is not connected).
Only some boards have multiple displays per output, and of those, only
very few have possibility of switching the display during runtime.
Because of the above points:
- We don't want to make omapdss and all the panel drivers more complex
just because some boards have complex setups.
- Only few boards support runtime switching, and afaik even then it's
not required. So we don't need to support runtime switching.
Thus we'll change to a model where we will have only one display device
per output and this cannot be (currently) changed at runtime. We'll
still have the possibility to select the display from multiple options
during boot with the default display option.
This patch accomplishes the above by changing how the output drivers
register the display device. Instead of registering all the devices
given from the board file, we'll only register one. If the default
display option is set, the output driver selects that display from its
displays. If the default display is not set, or the default display is
not one of the output's displays, the output driver selects the first
display.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 47 ++---
drivers/video/omap2/dss/dsi.c | 51 ++-
drivers/video/omap2/dss/dss.h |1 +
drivers/video/omap2/dss/hdmi.c | 57 ++--
drivers/video/omap2/dss/rfbi.c | 47 ++---
drivers/video/omap2/dss/sdi.c | 47 ++---
drivers/video/omap2/dss/venc.c | 47 ++---
7 files changed, 231 insertions(+), 66 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 703fc1d..6f9a199 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -371,10 +371,14 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
return 0;
}
-static void __init dpi_probe_pdata(struct platform_device *pdev)
+static struct omap_dss_device * __init dpi_find_dssdev(struct platform_device
*pdev)
{
struct omap_dss_board_info *pdata = pdev-dev.platform_data;
- int i, r;
+ const char *def_disp_name = dss_get_default_display_name();
+ struct omap_dss_device *def_dssdev;
+ int i;
+
+ def_dssdev = NULL;
for (i = 0; i pdata-num_devices; ++i) {
struct omap_dss_device *dssdev = pdata-devices[i];
@@ -382,16 +386,39 @@ static void __init dpi_probe_pdata(struct platform_device
*pdev)
if (dssdev-type != OMAP_DISPLAY_TYPE_DPI)
continue;
- r = dpi_init_display(dssdev);
- if (r) {
- DSSERR(device %s init failed: %d\n, dssdev-name, r);
- continue;
+ if (def_dssdev == NULL)
+ def_dssdev = dssdev;
+
+ if (def_disp_name != NULL
+ strcmp(dssdev-name, def_disp_name) == 0) {
+ def_dssdev = dssdev;
+ break;
}
+ }
- r = omap_dss_register_device(dssdev, pdev-dev);
- if (r)
- DSSERR(device %s register failed: %d\n,
- dssdev-name, r);
+ return def_dssdev;
+}
+
+static void __init dpi_probe_pdata(struct platform_device *pdev)
+{
+ struct omap_dss_device *dssdev;
+ int r;
+
+ dssdev = dpi_find_dssdev(pdev);
+
+ if (!dssdev)
+ return;
+
+ r = dpi_init_display(dssdev);
+ if (r) {
+ DSSERR(device %s init failed: %d\n, dssdev-name, r);
+ return;
+ }
+
+ r = omap_dss_register_device(dssdev, pdev-dev);
+ if (r) {
+ DSSERR(device %s register failed: %d\n, dssdev-name, r);
+ return;
}
}
diff --git a/drivers/video/omap2/dss/dsi.c
[PATCH 5/8] OMAPDSS: handle errors in dss_init_device
Add error handling to dss_init_device(), which has, for some reason,
been missing.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c|4 +++-
drivers/video/omap2/dss/display.c | 23 ++-
drivers/video/omap2/dss/dss.h |2 +-
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 315f557..9315ece 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -358,7 +358,9 @@ static int dss_driver_probe(struct device *dev)
dev_name(dev), dssdev-driver_name,
dssdrv-driver.name);
- dss_init_device(core.pdev, dssdev);
+ r = dss_init_device(core.pdev, dssdev);
+ if (r)
+ return r;
force = core.default_display_name
strcmp(core.default_display_name, dssdev-name) == 0;
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 5f09d503..f719010 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -320,26 +320,39 @@ void omapdss_default_get_timings(struct omap_dss_device
*dssdev,
}
EXPORT_SYMBOL(omapdss_default_get_timings);
-void dss_init_device(struct platform_device *pdev,
+int dss_init_device(struct platform_device *pdev,
struct omap_dss_device *dssdev)
{
struct device_attribute *attr;
- int i;
- int r;
+ int i, r;
/* create device sysfs files */
i = 0;
while ((attr = display_sysfs_attrs[i++]) != NULL) {
r = device_create_file(dssdev-dev, attr);
- if (r)
+ if (r) {
+ for (i = i - 2; i = 0; i--) {
+ attr = display_sysfs_attrs[i];
+ device_remove_file(dssdev-dev, attr);
+ }
+
DSSERR(failed to create sysfs file\n);
+ return r;
+ }
}
/* create display? sysfs links */
r = sysfs_create_link(pdev-dev.kobj, dssdev-dev.kobj,
dev_name(dssdev-dev));
- if (r)
+ if (r) {
+ while ((attr = display_sysfs_attrs[i++]) != NULL)
+ device_remove_file(dssdev-dev, attr);
+
DSSERR(failed to create sysfs display link\n);
+ return r;
+ }
+
+ return 0;
}
void dss_uninit_device(struct platform_device *pdev,
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index a977826..98e8273 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -228,7 +228,7 @@ int dss_suspend_all_devices(void);
int dss_resume_all_devices(void);
void dss_disable_all_devices(void);
-void dss_init_device(struct platform_device *pdev,
+int dss_init_device(struct platform_device *pdev,
struct omap_dss_device *dssdev);
void dss_uninit_device(struct platform_device *pdev,
struct omap_dss_device *dssdev);
--
1.7.9.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
[PATCH 4/8] OMAPDSS: explicitely initialize dssdev-channel for new displays
HDMI and VENC outputs always use the DIGIT output from DISPC. The dssdev
struct contains channel field which is used to specify the DISPC
output for the display, but this was not used for HDMI and VENC.
This patch fills the channel field explicitely for HDMI and VENC
displays so that we can always rely on the channel field.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c |2 ++
drivers/video/omap2/dss/venc.c |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 76d100b..3b10e18 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -946,6 +946,8 @@ static void __init hdmi_probe_pdata(struct platform_device
*pdev)
hdmi.ls_oe_gpio = priv-ls_oe_gpio;
hdmi.hpd_gpio = priv-hpd_gpio;
+ dssdev-channel = OMAP_DSS_CHANNEL_DIGIT;
+
r = hdmi_init_display(dssdev);
if (r) {
DSSERR(device %s init failed: %d\n, dssdev-name, r);
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index b9c0a8f..88fa6ea 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -773,6 +773,8 @@ static void __init venc_probe_pdata(struct platform_device
*pdev)
if (!dssdev)
return;
+ dssdev-channel = OMAP_DSS_CHANNEL_DIGIT;
+
r = venc_init_display(dssdev);
if (r) {
DSSERR(device %s init failed: %d\n, dssdev-name, r);
--
1.7.9.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
[PATCH 8/8] OMAPDSS: alloc dssdevs dynamically
We currently create omap_dss_devices statically in board files, and use
those devices directly in the omapdss driver. This model prevents us
from having the platform data (which the dssdevs in board files
practically are) as read-only, and it's also different than what we will
use with device tree.
This patch changes the model to be in line with DT model: we allocate
the dssdevs dynamically, and initialize them according to the data in
the board file's dssdev (basically we memcopy the dssdev fields).
The allocation and registration is done in the following steps in the
output drivers:
- Use dss_alloc_and_init_device to allocate and initialize the device.
The function uses kalloc and device_initialize to accomplish this.
- Call dss_copy_device_pdata to copy the data from the board file's
dssdev
- Use dss_add_device to register the device.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 72
drivers/video/omap2/dss/dpi.c | 17 +++---
drivers/video/omap2/dss/dsi.c | 15 +++--
drivers/video/omap2/dss/dss.h | 11 +++---
drivers/video/omap2/dss/hdmi.c | 15 +++--
drivers/video/omap2/dss/rfbi.c | 17 +++---
drivers/video/omap2/dss/sdi.c | 17 +++---
drivers/video/omap2/dss/venc.c | 17 +++---
8 files changed, 119 insertions(+), 62 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index c4fd768..b2af72d 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -33,6 +33,7 @@
#include linux/device.h
#include linux/regulator/consumer.h
#include linux/suspend.h
+#include linux/slab.h
#include video/omapdss.h
@@ -418,55 +419,44 @@ void omap_dss_unregister_driver(struct omap_dss_driver
*dssdriver)
EXPORT_SYMBOL(omap_dss_unregister_driver);
/* DEVICE */
-static void reset_device(struct device *dev, int check)
-{
- u8 *dev_p = (u8 *)dev;
- u8 *dev_end = dev_p + sizeof(*dev);
- void *saved_pdata;
-
- saved_pdata = dev-platform_data;
- if (check) {
- /*
-* Check if there is any other setting than platform_data
-* in struct device; warn that these will be reset by our
-* init.
-*/
- dev-platform_data = NULL;
- while (dev_p dev_end) {
- if (*dev_p) {
- WARN(%s: struct device fields will be
- discarded\n,
-__func__);
- break;
- }
- dev_p++;
- }
- }
- memset(dev, 0, sizeof(*dev));
- dev-platform_data = saved_pdata;
-}
-
static void omap_dss_dev_release(struct device *dev)
{
- reset_device(dev, 0);
+ struct omap_dss_device *dssdev = to_dss_device(dev);
+ kfree(dssdev);
}
static int disp_num_counter;
-int omap_dss_register_device(struct omap_dss_device *dssdev,
- struct device *parent)
+struct omap_dss_device *dss_alloc_and_init_device(struct device *parent)
{
- reset_device(dssdev-dev, 1);
+ struct omap_dss_device *dssdev;
+
+ dssdev = kzalloc(sizeof(*dssdev), GFP_KERNEL);
+ if (!dssdev)
+ return NULL;
dssdev-dev.bus = dss_bus_type;
dssdev-dev.parent = parent;
dssdev-dev.release = omap_dss_dev_release;
dev_set_name(dssdev-dev, display%d, disp_num_counter++);
- return device_register(dssdev-dev);
+
+ device_initialize(dssdev-dev);
+
+ return dssdev;
}
-void omap_dss_unregister_device(struct omap_dss_device *dssdev)
+int dss_add_device(struct omap_dss_device *dssdev)
+{
+ return device_add(dssdev-dev);
+}
+
+void dss_put_device(struct omap_dss_device *dssdev)
+{
+ put_device(dssdev-dev);
+}
+
+void dss_unregister_device(struct omap_dss_device *dssdev)
{
device_unregister(dssdev-dev);
}
@@ -474,15 +464,25 @@ void omap_dss_unregister_device(struct omap_dss_device
*dssdev)
static int dss_unregister_dss_dev(struct device *dev, void *data)
{
struct omap_dss_device *dssdev = to_dss_device(dev);
- omap_dss_unregister_device(dssdev);
+ dss_unregister_device(dssdev);
return 0;
}
-void omap_dss_unregister_child_devices(struct device *parent)
+void dss_unregister_child_devices(struct device *parent)
{
device_for_each_child(parent, NULL, dss_unregister_dss_dev);
}
+void dss_copy_device_pdata(struct omap_dss_device *dst,
+ const struct omap_dss_device *src)
+{
+ u8 *d = (u8 *)dst;
+ u8 *s = (u8 *)src;
+ size_t dsize = sizeof(struct device);
+
+ memcpy(d + dsize, s + dsize, sizeof(struct omap_dss_device) - dsize);
+}
+
/* BUS */
static int __init omap_dss_bus_register(void)
{
diff --git a/drivers/video/omap2/dss/dpi.c
[PATCH 7/8] OMAPDSS: cleanup dss_recheck_connections further
Cleanup dss_recheck_connections, move and rename it to a static
dss_init_connections function inside display.c. Improve the function to
return errors, and implement a matching dss_uninit_connections that can
be used to free the mgr-dssdev link.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c|5 ---
drivers/video/omap2/dss/display.c | 62 +++--
drivers/video/omap2/dss/dss.h |1 -
drivers/video/omap2/dss/overlay.c | 32 ---
4 files changed, 60 insertions(+), 40 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 9315ece..c4fd768 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -352,7 +352,6 @@ static int dss_driver_probe(struct device *dev)
int r;
struct omap_dss_driver *dssdrv = to_dss_driver(dev-driver);
struct omap_dss_device *dssdev = to_dss_device(dev);
- bool force;
DSSDBG(driver_probe: dev %s/%s, drv %s\n,
dev_name(dev), dssdev-driver_name,
@@ -362,10 +361,6 @@ static int dss_driver_probe(struct device *dev)
if (r)
return r;
- force = core.default_display_name
- strcmp(core.default_display_name, dssdev-name) == 0;
- dss_recheck_connections(dssdev, force);
-
r = dssdrv-probe(dssdev);
if (r) {
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index f719010..db83ae8 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -320,11 +320,66 @@ void omapdss_default_get_timings(struct omap_dss_device
*dssdev,
}
EXPORT_SYMBOL(omapdss_default_get_timings);
+/*
+ * Connect dssdev to a manager if the manager is free or if force is specified.
+ * Connect all overlays to that manager if they are free or if force is
+ * specified.
+ */
+static int dss_init_connections(struct omap_dss_device *dssdev, bool force)
+{
+ struct omap_overlay_manager *mgr;
+ int i, r;
+
+ WARN_ON(dssdev-manager);
+
+ mgr = omap_dss_get_overlay_manager(dssdev-channel);
+
+ if (mgr-device !force)
+ return 0;
+
+ if (mgr-device)
+ mgr-unset_device(mgr);
+
+ r = mgr-set_device(mgr, dssdev);
+ if (r) {
+ DSSERR(failed to set initial manager\n);
+ return r;
+ }
+
+ for (i = 0; i omap_dss_get_num_overlays(); ++i) {
+ struct omap_overlay *ovl = omap_dss_get_overlay(i);
+
+ if (!ovl-manager || force) {
+ if (ovl-manager)
+ ovl-unset_manager(ovl);
+
+ r = ovl-set_manager(ovl, mgr);
+ if (r) {
+ DSSERR(failed to set initial overlay\n);
+ return r;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static void dss_uninit_connections(struct omap_dss_device *dssdev)
+{
+ if (dssdev-manager)
+ dssdev-manager-unset_device(dssdev-manager);
+}
+
int dss_init_device(struct platform_device *pdev,
struct omap_dss_device *dssdev)
{
struct device_attribute *attr;
int i, r;
+ const char *def_disp_name = dss_get_default_display_name();
+ bool force;
+
+ force = def_disp_name strcmp(def_disp_name, dssdev-name) == 0;
+ dss_init_connections(dssdev, force);
/* create device sysfs files */
i = 0;
@@ -336,6 +391,8 @@ int dss_init_device(struct platform_device *pdev,
device_remove_file(dssdev-dev, attr);
}
+ dss_uninit_connections(dssdev);
+
DSSERR(failed to create sysfs file\n);
return r;
}
@@ -348,6 +405,8 @@ int dss_init_device(struct platform_device *pdev,
while ((attr = display_sysfs_attrs[i++]) != NULL)
device_remove_file(dssdev-dev, attr);
+ dss_uninit_connections(dssdev);
+
DSSERR(failed to create sysfs display link\n);
return r;
}
@@ -366,8 +425,7 @@ void dss_uninit_device(struct platform_device *pdev,
while ((attr = display_sysfs_attrs[i++]) != NULL)
device_remove_file(dssdev-dev, attr);
- if (dssdev-manager)
- dssdev-manager-unset_device(dssdev-manager);
+ dss_uninit_connections(dssdev);
}
static int dss_suspend_device(struct device *dev, void *data)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 98e8273..7a3fea6 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -263,7 +263,6 @@ void dss_manager_kobj_uninit(struct omap_overlay_manager
*mgr);
void dss_init_overlays(struct platform_device
[PATCH 6/8] OMAPDSS: cleanup dss_recheck_connections
dss_recheck_connections is quite a mess. With the previous commit that
initializes the channel field for HDMI and VENC displays, we can greatly
simplify the dss_recheck_connections.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/overlay.c | 49 +
1 file changed, 6 insertions(+), 43 deletions(-)
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index e3d4068..1bf05ef 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -109,52 +109,15 @@ void dss_init_overlays(struct platform_device *pdev)
* selected, connect always. */
void dss_recheck_connections(struct omap_dss_device *dssdev, bool force)
{
- int i;
- struct omap_overlay_manager *lcd_mgr;
- struct omap_overlay_manager *tv_mgr;
- struct omap_overlay_manager *lcd2_mgr = NULL;
- struct omap_overlay_manager *lcd3_mgr = NULL;
struct omap_overlay_manager *mgr = NULL;
+ int i;
- lcd_mgr = omap_dss_get_overlay_manager(OMAP_DSS_CHANNEL_LCD);
- tv_mgr = omap_dss_get_overlay_manager(OMAP_DSS_CHANNEL_DIGIT);
- if (dss_has_feature(FEAT_MGR_LCD3))
- lcd3_mgr = omap_dss_get_overlay_manager(OMAP_DSS_CHANNEL_LCD3);
- if (dss_has_feature(FEAT_MGR_LCD2))
- lcd2_mgr = omap_dss_get_overlay_manager(OMAP_DSS_CHANNEL_LCD2);
-
- if (dssdev-channel == OMAP_DSS_CHANNEL_LCD3) {
- if (!lcd3_mgr-device || force) {
- if (lcd3_mgr-device)
- lcd3_mgr-unset_device(lcd3_mgr);
- lcd3_mgr-set_device(lcd3_mgr, dssdev);
- mgr = lcd3_mgr;
- }
- } else if (dssdev-channel == OMAP_DSS_CHANNEL_LCD2) {
- if (!lcd2_mgr-device || force) {
- if (lcd2_mgr-device)
- lcd2_mgr-unset_device(lcd2_mgr);
- lcd2_mgr-set_device(lcd2_mgr, dssdev);
- mgr = lcd2_mgr;
- }
- } else if (dssdev-type != OMAP_DISPLAY_TYPE_VENC
-dssdev-type != OMAP_DISPLAY_TYPE_HDMI) {
- if (!lcd_mgr-device || force) {
- if (lcd_mgr-device)
- lcd_mgr-unset_device(lcd_mgr);
- lcd_mgr-set_device(lcd_mgr, dssdev);
- mgr = lcd_mgr;
- }
- }
+ mgr = omap_dss_get_overlay_manager(dssdev-channel);
- if (dssdev-type == OMAP_DISPLAY_TYPE_VENC
- || dssdev-type == OMAP_DISPLAY_TYPE_HDMI) {
- if (!tv_mgr-device || force) {
- if (tv_mgr-device)
- tv_mgr-unset_device(tv_mgr);
- tv_mgr-set_device(tv_mgr, dssdev);
- mgr = tv_mgr;
- }
+ if (!mgr-device || force) {
+ if (mgr-device)
+ mgr-unset_device(mgr);
+ mgr-set_device(mgr, dssdev);
}
if (mgr) {
--
1.7.9.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 v4 00/14] MFD/ASoC/Input: twl4030-audio submodule DT support
Hi Samuel, On 09/19/2012 03:24 AM, Samuel Ortiz wrote: Hi Peter, On Mon, Sep 10, 2012 at 01:46:18PM +0300, Peter Ujfalusi wrote: Hello, Generated on top of: git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/omap I applied the first 8 patches, but I'd like to get Mark's ACK for the rest of the serie. Unless you're expecting Mark to take the whole thing, in which case you can add my: Acked-by: Samuel Ortiz sa...@linux.intel.com to the MFD patches. Please let me know how you'd like to proceed. If Mark is still OK with it I think it would be better to queue this series via ASoC so we can keep them in one place (also I think patch 14 needs patch 6 in order to not break x86/x86_64 allmodconfig). On the other hand if they go separately (1-8 via MFD, 9-14 via ASoC) they will meet in linux-next where this matters the most. Thank you, Péter -- 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 2/3] OMAP i2c: pinctrl-ify i2c-omap.c
Hi On Sep 19, 2012, at 10:09 AM, Shubhrajyoti wrote: On Wednesday 19 September 2012 09:37 PM, Pantelis Antoniou wrote: #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h +#include linux/err.h err.h include may be removed. Right, Updated patch series (without the message patch follows)... Regards -- Pantelis -- 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/2] Pinctrl-fy OMAP I2C driver (V2)
Pinctrl-fy the OMAP I2C driver. Due to the requirement of early usage of I2C for regulators and such, earlier initialization of pinctrl is required. This patch series is against git://gitorious.org/linus-tree/linus-tree.git for_3.7/i2c/big_cleanups Note that the I2C DT bindings are against the linux-omap-dt tree and that without https://patchwork.kernel.org/patch/1468531 queued for 3.7 scary messages will be printed on !DT platforms Pantelis Antoniou (2): pinctrl: pinctrl-single must be initialized early. OMAP i2c: pinctrl-ify i2c-omap.c drivers/i2c/busses/i2c-omap.c| 6 ++ drivers/pinctrl/pinctrl-single.c | 12 +++- 2 files changed, 17 insertions(+), 1 deletion(-) -- 1.7.12 -- 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/2] OMAP i2c: pinctrl-ify i2c-omap.c
Add support for pinctrl mux settings in the OMAP I2C driver. If no such pinctl bindings are found a warning message is printed. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/i2c/busses/i2c-omap.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index b149e32..d192614 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -43,6 +43,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_2 0x20 @@ -1057,6 +1058,7 @@ omap_i2c_probe(struct platform_device *pdev) const struct of_device_id *match; int irq; int r; + struct pinctrl *pinctrl; /* NOTE: driver uses the static register mapping */ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); @@ -1197,6 +1199,10 @@ omap_i2c_probe(struct platform_device *pdev) of_i2c_register_devices(adap); + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(dev-dev, pins are not configured from the driver\n); + pm_runtime_mark_last_busy(dev-dev); pm_runtime_put_autosuspend(dev-dev); -- 1.7.12 -- 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/2] pinctrl: pinctrl-single must be initialized early.
When using pinctrl-single to handle i2c initialization, it has
to be done early.
On the beaglebone the regulator is connected to the i2c0 bus,
and for sure that's the case for many other am33xx boards.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/pinctrl/pinctrl-single.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 76a4260..3acf7f9 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -980,7 +980,17 @@ static struct platform_driver pcs_driver = {
},
};
-module_platform_driver(pcs_driver);
+static int __init pcs_init(void)
+{
+ return platform_driver_register(pcs_driver);
+}
+postcore_initcall(pcs_init);
+
+static void __exit pcs_exit(void)
+{
+ platform_driver_unregister(pcs_driver);
+}
+module_exit(pcs_exit);
MODULE_AUTHOR(Tony Lindgren t...@atomide.com);
MODULE_DESCRIPTION(One-register-per-pin type device tree based pinctrl
driver);
--
1.7.12
--
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: [PATCHv4 8/8] ARM: OMAP3: do not delete per_clkdm autodeps during idle
On Tue, 2012-09-18 at 22:25 +, Paul Walmsley wrote: Hi Tero, just looking at the usecounting series to see what is mergeable and noticed this: On Fri, 13 Jul 2012, Tero Kristo wrote: Secondly, there are multiple erratas for omap3, which say that the wakedeps should be enabled for the PER domain, see e.g. errata i582 for omap3630. Erratum i582 mentions that a wakeup dependency needs to exist between PER and WKUP such that PER will wake when CORE_L3 does. Our autodeps would not add this dependency; they just would attempt to add a wakeup dependency between PER and MPU/IVA2. So we need a different mechanism. What do you think about the following patch to handle part of the i582 workaround? Yes, that looks good to me, someone will need to test it though. Also, do you have any of the other errata information handy, so we can track those down also? I'm pretty sure we need to enable the wakeup dependency between PER and CORE also for OMAP3, but can't recall the reference. GPIO errata i467 has a workaround which involves wakedeps. i582 is valid for omap3430 also. I am not able to find anything else regarding wakedeps right now, at least nothing regarding per vs core. -Tero - Paul From: Paul Walmsley p...@pwsan.com Date: Tue, 18 Sep 2012 16:02:38 -0600 Subject: [PATCH] ARM: OMAP36xx: PM: apply part of the erratum i582 workaround On OMAP36xx chips with ES 1.2, if the PER powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if, upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be unusable. This is erratum i582 in the OMAP36xx Silicon Errata document. This patch implements one of several parts of the workaround: the addition of the wakeup dependency between the PER and WKUP clockdomains, such that PER will wake up at the same time CORE_L3 does. This is not a complete workaround. For it to be complete: 1. the PER powerdomain's next power state must not be set to OSWR or OFF if the CORE powerdomain's next power state is set to CSWR or ON; 2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that PER went OFF while CORE stayed on. If loopback tests fail, then those devices will be unusable until PER and CORE can undergo a transition from ON to OSWR/OFF and back ON. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Tero Kristo t-kri...@ti.com Cc: Kevin Hilman khil...@ti.com --- arch/arm/mach-omap2/pm.h |1 + arch/arm/mach-omap2/pm34xx.c | 24 +++- 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index 686137d..67d6613 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -91,6 +91,7 @@ extern void omap3_save_scratchpad_contents(void); #define PM_RTA_ERRATUM_i608 (1 0) #define PM_SDRC_WAKEUP_ERRATUM_i583 (1 1) +#define PM_PER_MEMORIES_ERRATUM_i582 (1 2) #if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) extern u16 pm34xx_errata; diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 05bd8f0..5e99345 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -651,7 +651,8 @@ static void __init pm_errata_configure(void) /* Enable the l2 cache toggling in sleep logic */ enable_omap3630_toggle_l2_on_restore(); if (omap_rev() OMAP3630_REV_ES1_2) - pm34xx_errata |= PM_SDRC_WAKEUP_ERRATUM_i583; + pm34xx_errata |= (PM_SDRC_WAKEUP_ERRATUM_i583 | + PM_PER_ERRATUM_i582); } } @@ -726,6 +727,27 @@ int __init omap3_pm_init(void) if (IS_PM34XX_ERRATUM(PM_RTA_ERRATUM_i608)) omap3630_ctrl_disable_rta(); + /* + * The UART3/4 FIFO and the sidetone memory in McBSP2/3 are + * not correctly reset when the PER powerdomain comes back + * from OFF or OSWR when the CORE powerdomain is kept active. + * See OMAP36xx Erratum i582 PER Domain reset issue after + * Domain-OFF/OSWR Wakeup. This wakeup dependency is not a + * complete workaround. The kernel must also prevent the PER + * powerdomain from going to OSWR/OFF while the CORE + * powerdomain is not going to OSWR/OFF. And if PER last + * power state was off while CORE last power state was ON, the + * UART3/4 and McBSP2/3 SIDETONE devices need to run a + * self-test using their loopback tests; if that fails, those + * devices are unusable until the PER/CORE can complete a transition + * from ON to OSWR/OFF and then back to ON. + * + * XXX Technically this workaround is only needed if off-mode + * or OSWR is enabled. + */ + if
[PATCH v3 1/3] ARM: dts: Add twl6030-usb data
Add twl6030-usb data node in twl6030 device tree file. twl6030-usb is the
comparator driver for USB that detects VBUS and ID events. The dt data is
comprised of two interrupts, one for ID and one for VBUS and a phandle to the
regulator.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts |4
arch/arm/boot/dts/omap4-sdp.dts |4
arch/arm/boot/dts/twl6030.dtsi|5 +
3 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 20b966e..6640fd9 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -137,3 +137,7 @@
cs1-used;
device-handle = elpida_ECB240ABACN;
};
+
+twl_usb_comparator {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 94a23b3..406dab1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -349,3 +349,7 @@
pinctrl-names = default;
pinctrl-0 = uart4_pins;
};
+
+twl_usb_comparator {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 123e2c4..9996cfc 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -86,4 +86,9 @@
clk32kg: regulator-clk32kg {
compatible = ti,twl6030-clk32kg;
};
+
+ twl_usb_comparator: usb-comparator {
+ compatible = ti,twl6030-usb;
+ interrupts = 4, 10;
+ };
};
--
1.7.9.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
[PATCH v3 3/3] ARM: dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host mode.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts |6 ++
arch/arm/boot/dts/omap3-overo.dtsi|6 ++
arch/arm/boot/dts/omap3.dtsi | 11 +++
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts |6 ++
arch/arm/boot/dts/omap4.dtsi | 12
7 files changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index c38cf76..ca37f19 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -113,3 +113,9 @@
*/
ti,pulldowns = 0x03a1c4;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..afb9ba9 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -59,3 +59,9 @@
twl_gpio {
ti,use-leds;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index 89808ce..4b3d157 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -55,3 +55,9 @@
twl_gpio {
ti,use-leds;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f38ea87..5c7324b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -300,5 +300,16 @@
ti,buffer-size = 128;
ti,hwmods = mcbsp5;
};
+
+ usb_otg_hs: usb_otg_hs@480ab000 {
+ compatible = ti,omap3-musb;
+ reg = 0x480ab000 0x1000;
+ interrupts = 0 92 0x4, 0 93 0x4;
+ interrupt-names = mc, dma;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 6640fd9..c3ff134 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -141,3 +141,9 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 406dab1..22f7ec1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -353,3 +353,9 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5d1c484..79611b4 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -430,5 +430,17 @@
hw-caps-ll-interface;
hw-caps-temp-alert;
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,omap4-musb;
+ reg = 0x4a0ab000 0x7ff,
+ 0x4a00233c 0x4; /* TO BE REMOVED:SCM Register */
+ interrupts = 0 92 0x4, 0 93 0x4;
+ interrupt-names = mc, dma;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
--
1.7.9.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
[PATCH v3 2/3] ARM: dts: Add twl4030-usb data
Add twl4030-usb data node in twl4030 device tree file. twl4030-usb is the phy
driver for MUSB used in omap3 chipsets. The dt data is comprised of two
interrupts, one for ID and one for VBUS and three phandles to regulator.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index ff00017..18fa7a4 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = 315;
};
+ vusb1v5: regulator-vusb1v5 {
+ compatible = ti,twl4030-vusb1v5;
+ };
+
+ vusb1v8: regulator-vusb1v8 {
+ compatible = ti,twl4030-vusb1v8;
+ };
+
+ vusb3v1: regulator-vusb3v1 {
+ compatible = ti,twl4030-vusb3v1;
+ };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10, 4;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+ };
};
--
1.7.9.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
[PATCH v3 0/3] ARM: dts: omap: add dt data for MUSB
This patch series adds dt data to get MUSB working in omap4 and omap3 Changes from v2: * Changes the subject of all the patches to include ARM: dts: * Added reg property and interrupt property for usb_otg_hs. Previously these were obtained from ti,hwmods property. * Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt Changes from v1: Just removed the omap-usb2 dt data and sent that as a separate patch. Kishon Vijay Abraham I (3): ARM: dts: Add twl6030-usb data ARM: dts: Add twl4030-usb data ARM: dts: omap: Add usb_otg and glue data arch/arm/boot/dts/omap3-beagle-xm.dts |6 ++ arch/arm/boot/dts/omap3-evm.dts |6 ++ arch/arm/boot/dts/omap3-overo.dtsi|6 ++ arch/arm/boot/dts/omap3.dtsi | 11 +++ arch/arm/boot/dts/omap4-panda.dts | 10 ++ arch/arm/boot/dts/omap4-sdp.dts | 10 ++ arch/arm/boot/dts/omap4.dtsi | 12 arch/arm/boot/dts/twl4030.dtsi| 21 + arch/arm/boot/dts/twl6030.dtsi|5 + 9 files changed, 87 insertions(+) -- 1.7.9.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 1/9] ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
On Wednesday 12 September 2012 14:45:44 Omar Ramirez Luna wrote:
If included without IOMMU_API being selected it will break
compilation:
arch/arm/plat-omap/include/plat/iommu.h:
In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:148:
error: 'struct dev_archdata' has no member named 'iommu'
This will be seen when hwmod includes iommu.h to get the
structure for attributes. Also needed for tidspbridge
incremental migration to use iommu code.
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
I had the same patch in my tree already :-)
---
arch/arm/plat-omap/include/plat/iommu.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h index 88be3e6..e58d571 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -126,6 +126,7 @@ struct omap_iommu_arch_data {
struct omap_iommu *iommu_dev;
};
+#ifdef CONFIG_IOMMU_API
/**
* dev_to_omap_iommu() - retrieves an omap iommu object from a user device
* @dev: iommu client device
@@ -136,6 +137,7 @@ static inline struct omap_iommu
*dev_to_omap_iommu(struct device *dev)
return arch_data-iommu_dev;
}
+#endif
/* IOMMU errors */
#define OMAP_IOMMU_ERR_TLB_MISS (1 0)
--
Regards,
Laurent Pinchart
--
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/2] ARM/dts: OMAP4: Enable twl6040 GPO functionality
Hello, The following two patch is needed for the twl6040 GPO driver (going via MFD tree) to work correctly. Regards, Peter --- Peter Ujfalusi (2): ARM/dts: omap4-sdp: Enable GPO functionality for twl6040 ARM/dts: omap4-panda: Enable GPO functionality for twl6040 arch/arm/boot/dts/omap4-panda.dts | 3 +++ arch/arm/boot/dts/omap4-sdp.dts | 3 +++ 2 files changed, 6 insertions(+) -- 1.7.12 -- 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/2] ARM/dts: omap4-sdp: Enable GPO functionality for twl6040
Add the needed properties for twl6040 so the GPO functionality can be used
by other drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 94a23b3..2c4fc1e 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -155,6 +155,9 @@
twl6040: twl@4b {
compatible = ti,twl6040;
+ gpio-controller;
+ #gpio-cells = 1;
+
reg = 0x4b;
/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
interrupts = 0 119 4; /* IRQ_SYS_2N cascaded to gic */
--
1.7.12
--
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/2] ARM/dts: omap4-panda: Enable GPO functionality for twl6040
Add the needed properties for twl6040 so the GPO functionality can be used
by other drivers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 20b966e..94adabb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -71,6 +71,9 @@
twl6040: twl@4b {
compatible = ti,twl6040;
+ gpio-controller;
+ #gpio-cells = 1;
+
reg = 0x4b;
/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
interrupts = 0 119 4; /* IRQ_SYS_2N cascaded to gic */
--
1.7.12
--
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] i2c: OMAP fix driver initialization message
Hi Benoit, On Sep 18, 2012, at 10:24 PM, a0919096 wrote: Hi Panto, That patch is good, but a similar one was already posted by Florian. https://patchwork.kernel.org/patch/1392671/ Checking the email thread it seems that Wolfram pulled it. Regards, Benoit Great. One less thing to look after :) Regards -- Pantelis On 9/19/2012 11:07 AM, Pantelis Antoniou wrote: The message spit out when the i2c-omap driver load is printing the platform device's id as a bus number. However when booting from OF id is -1, which is not so nice. Fix it by printing the adapter number. [0.210467] omap_i2c 44e0b000.i2c: bus -1 rev2.4.0 at 400 kHz vs [0.210467] omap_i2c 44e0b000.i2c: bus 0 rev2.4.0 at 400 kHz Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/i2c/busses/i2c-omap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index f722478..87bb705 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1178,9 +1178,6 @@ omap_i2c_probe(struct platform_device *pdev) goto err_unuse_clocks; } -dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, pdev-id, - dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed); - adap = dev-adapter; i2c_set_adapdata(adap, dev); adap-owner = THIS_MODULE; @@ -1204,6 +1201,9 @@ omap_i2c_probe(struct platform_device *pdev) if (IS_ERR(pinctrl)) dev_warn(dev-dev, pins are not configured from the driver\n); +dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, adap-nr, + dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed); + pm_runtime_mark_last_busy(dev-dev); pm_runtime_put_autosuspend(dev-dev); -- 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 2/2] OMAP i2c: pinctrl-ify i2c-omap.c
On Thu, Sep 20, 2012 at 12:04 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Add support for pinctrl mux settings in the OMAP I2C driver. If no such pinctl bindings are found a warning message is printed. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- looks good Acked-by: Shubhrajyoti D shubhrajy...@ti.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/3] MFD/GPIO: Add twl6040 GPO driver
Hi Peter, On Thu, Aug 16, 2012 at 03:13:12PM +0300, Peter Ujfalusi wrote: Hello, Changes since v1: - Removed the ti,use-gpo property from DT bindings - Register the GPO driver if we booted with DT blob or in legacy if the pdata for the GPO driver is present - DT binding Documentation update The Documentation update has reference to the twl6040.dtsi file which will be created to hold the common/static properties for the twl6040. To avoid cross tree merge issues later I have only included the Documentation update to this series and I will send the actual .dtsi/.dts changes via linux-omap. If this is not a problem. The dependencies for this series are in mainline and I think this series can go via GPIO if Samuel agrees with the changes. Intro mail from v1: The following series adds support for the GPO (General Purpose Output) on the twl6040/41 audio chip. The series has been tested on SDP4430, compile tested for x86_64 and x86_32 bit to be sure it does not introduce build breakage. Regards, Peter --- Peter Ujfalusi (3): mfd: twl6040: Fix GPO mask mfd: twl6040: Add twl6040-gpio child gpio: Add basic support for TWL6040 GPOs All 3 patches applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 V6 1/2] of: Add generic device tree DMA helpers
On Tuesday 18 September 2012, Mitch Bradley wrote: There is a delicious irony here with respect to Shark. Shark has real Open Firmware. It's the platform that I used for the first OFW port to ARM. We (the Shark design team) had a version of NetBSD that would run on Shark without any native drivers, calling into the Open Firmware drivers. It was very useful for bringup. Very interesting, thanks for sharing this bit of history. Are you aware of other ARM systems using open firmware that we still support in Linux (besides the XO-1.75)? Is there ever a point when old architectures leave the Linux tree, or will people have to see grep hits from them until the end of time? As long as someone is interested in keeping an architecture or driver alive, it stays. If something is causing problems and we have reason to assume it will never be used again with current kernels, we toss them out. Russell has recently removed support for ARMv3 CPUs, but some of the StrongARM targets (especially SA-1100) are still being actively used, so the CPU support is not going away any time soon. If you have a bunch of Shark machines for testing and would like to port it over to device tree passing from its open firmware, you are definitely welcome ;-) Arnd -- 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/3] MFD/GPIO: Add twl6040 GPO driver
Hi Peter, On Thu, Aug 16, 2012 at 03:13:12PM +0300, Peter Ujfalusi wrote: Hello, Changes since v1: - Removed the ti,use-gpo property from DT bindings - Register the GPO driver if we booted with DT blob or in legacy if the pdata for the GPO driver is present - DT binding Documentation update The Documentation update has reference to the twl6040.dtsi file which will be created to hold the common/static properties for the twl6040. To avoid cross tree merge issues later I have only included the Documentation update to this series and I will send the actual .dtsi/.dts changes via linux-omap. If this is not a problem. The dependencies for this series are in mainline and I think this series can go via GPIO if Samuel agrees with the changes. Intro mail from v1: The following series adds support for the GPO (General Purpose Output) on the twl6040/41 audio chip. The series has been tested on SDP4430, compile tested for x86_64 and x86_32 bit to be sure it does not introduce build breakage. Regards, Peter --- Peter Ujfalusi (3): mfd: twl6040: Fix GPO mask mfd: twl6040: Add twl6040-gpio child gpio: Add basic support for TWL6040 GPOs All 3 patches applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 V4 0/5] ARM: OMAP: HOST: TLL driver implementation
Hi Keshava, On Mon, Jul 16, 2012 at 07:01:06PM +0530, Keshava Munegowda wrote: The TLL (Transceiver Less Link) is an separate IP block, independent of the host controller. Basically this TLL operates like USB PHY which allows the user to connect two USB transceiver interfaces together directly without the use of differential transceivers in omap3 and later chips. The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com In v4: - rebased on top of linux kernel version 3.5.rc7 - reworked as per the comments given by Paul Walmsley p...@pwsan.com In v3: - rebased on top V3 of Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller http://permalink.gmane.org/gmane.linux.usb.general/65988 - rebased on top of patch OMAP: USB : Fix the EHCI enumeration and core retention issue http://permalink.gmane.org/gmane.linux.usb.general/66239 In V2: - covered review comments from linux omap and usb community - rebased on top Russ dill's patch 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' fixes an issue where the ULPI PHYs were not held in reset while initializing the EHCI controller Keshava Munegowda (5): ARM: OMAP: Add the USB TLL clocks device name ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: USB: Remove TLL specific code from USB HS core driver ARM: OMAP: Remove older device name of the USB TLL clocks All 5 patches applied now. I had to manually apply patches #1 and #5. Could you please check that it's looking good to you ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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/4] usb: phy: add usb3 phy driver
Added a driver for usb3 phy that handles the interaction between usb phy device and dwc3 controller. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Also included the patch from Moiz to fix gadget pullup in SS mode. This patch series has been lying in my local tree for some time and it's been tested in my tree. git://gitorious.org/linux-usb/linux-usb.git dwc3 This patch series was rebased on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv However the dependent modules are not yet upstreamed and hence only compile tested in this tree Kishon Vijay Abraham I (3): usb: phy: add a new driver for usb3 phy usb: phy: omap-usb3: Decrease the number of transitions to recovery usb: phy: omap-usb2: enable 960Mhz clock for omap5 Moiz Sonasath (1): usb: dwc3: Fix gadget pullup in SS mode Documentation/devicetree/bindings/usb/usb-phy.txt | 21 ++ drivers/usb/dwc3/gadget.c | 21 +- drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 28 +- drivers/usb/phy/omap-usb3.c | 416 + include/linux/usb/omap_usb.h | 73 include/linux/usb/phy.h | 10 +- 8 files changed, 571 insertions(+), 8 deletions(-) create mode 100644 drivers/usb/phy/omap-usb3.c -- 1.7.9.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
[PATCH 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28 -
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct platform_device
*pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
+
usb_add_phy(phy-phy, USB_PHY_TYPE_USB2);
platform_set_drvdata(pdev, phy);
@@ -204,6 +214,7 @@ static int __devexit omap_usb2_remove(struct
platform_device *pdev)
struct omap_usb *phy = platform_get_drvdata(pdev);
clk_unprepare(phy-wkupclk);
+ clk_unprepare(phy-optclk);
usb_remove_phy(phy-phy);
return 0;
@@ -217,6 +228,7 @@ static int omap_usb2_runtime_suspend(struct device *dev)
struct omap_usb *phy = platform_get_drvdata(pdev);
clk_disable(phy-wkupclk);
+ clk_disable(phy-optclk);
return 0;
}
@@ -228,8 +240,22 @@ static int omap_usb2_runtime_resume(struct device *dev)
struct omap_usb *phy = platform_get_drvdata(pdev);
ret = clk_enable(phy-wkupclk);
- if (ret 0)
+ if (ret 0) {
dev_err(phy-dev, Failed to enable wkupclk %d\n, ret);
+ return ret;
+ }
+
+ if (phy-optclk) {
+ ret = clk_enable(phy-optclk);
+ if (ret) {
+ dev_err(phy-dev, Failed to enable optclk %d\n, ret);
+ goto err;
+ }
+ }
+
+ return 0;
+err:
+ clk_disable(phy-wkupclk);
return ret;
}
--
1.7.9.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
[PATCH 2/4] usb: dwc3: Fix gadget pullup in SS mode
From: Moiz Sonasath m-sonas...@ti.com
For the gadget pullup functionality to work in
SS mode it requires a particular sequence of
toggling the run-stop bit. Here is the required
sequence:
- Set DCTL[31]
- Clear DCTL[31]
- Clear OMAP5430_CONTROL_CORE__PHY_POWER_USB[14]
- Clear DCTL[8:5] = 0x00
- Set DCTL[8:5] = 0x05
- Wait 25 Ms
- Set DCTL[31]
- Set OMAP5430_CONTROL_CORE__PHY_POWER_USB[14]
Tested rigourously the gadget pull-up functionality
in bot HS and SS modes.
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/gadget.c | 21 +++--
drivers/usb/phy/omap-usb3.c | 16
include/linux/usb/phy.h | 10 +-
3 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 58fdfad..bcc0102 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -49,6 +49,7 @@
#include linux/usb/ch9.h
#include linux/usb/gadget.h
+#include linux/usb/otg.h
#include core.h
#include gadget.h
@@ -1417,19 +1418,27 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on)
reg = dwc3_readl(dwc-regs, DWC3_DCTL);
if (is_on) {
if (dwc-revision = DWC3_REVISION_187A) {
- reg = ~DWC3_DCTL_TRGTULST_MASK;
- reg |= DWC3_DCTL_TRGTULST_RX_DET;
+ reg = ~DWC3_DCTL_ULSTCHNGREQ_MASK;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ reg |= DWC3_DCTL_ULSTCHNG_RX_DETECT;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ mdelay(25);
+ reg |= DWC3_DCTL_RUN_STOP;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ usb_phy_poweron(dwc-usb3_phy);
}
- if (dwc-revision = DWC3_REVISION_194A)
+ if (dwc-revision = DWC3_REVISION_194A) {
reg = ~DWC3_DCTL_KEEP_CONNECT;
- reg |= DWC3_DCTL_RUN_STOP;
+ reg |= DWC3_DCTL_RUN_STOP;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ }
} else {
reg = ~DWC3_DCTL_RUN_STOP;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ usb_phy_shutdown(dwc-usb3_phy);
}
- dwc3_writel(dwc-regs, DWC3_DCTL, reg);
-
do {
reg = dwc3_readl(dwc-regs, DWC3_DSTS);
if (is_on) {
diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
index 4dc84ca..26402d5 100644
--- a/drivers/usb/phy/omap-usb3.c
+++ b/drivers/usb/phy/omap-usb3.c
@@ -212,6 +212,20 @@ static int omap_usb3_init(struct usb_phy *x)
return 0;
}
+static void omap_usb3_poweron(struct usb_phy *x)
+{
+ struct omap_usb *phy = phy_to_omapusb(x);
+
+ omap5_usb_phy_power(phy, 1);
+}
+
+static void omap_usb3_shutdown(struct usb_phy *x)
+{
+ struct omap_usb *phy = phy_to_omapusb(x);
+
+ omap5_usb_phy_power(phy, 0);
+}
+
static int __devinit omap_usb3_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
@@ -253,6 +267,8 @@ static int __devinit omap_usb3_probe(struct platform_device
*pdev)
phy-phy.dev= phy-dev;
phy-phy.label = omap-usb3;
phy-phy.init = omap_usb3_init;
+ phy-phy.poweron= omap_usb3_poweron;
+ phy-phy.shutdown = omap_usb3_shutdown;
phy-phy.set_suspend= omap_usb3_suspend;
phy-is_suspended = 1;
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 06b5bae..aaa8e16 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -86,8 +86,9 @@ struct usb_phy {
/* to support controllers that have multiple transceivers */
struct list_headhead;
- /* initialize/shutdown the OTG controller */
+ /* initialize/poweron/shutdown the OTG controller */
int (*init)(struct usb_phy *x);
+ void(*poweron)(struct usb_phy *x);
void(*shutdown)(struct usb_phy *x);
/* effective for B devices, ignored for A-peripheral */
@@ -135,6 +136,13 @@ usb_phy_init(struct usb_phy *x)
}
static inline void
+usb_phy_poweron(struct usb_phy *x)
+{
+ if (x-poweron)
+ x-poweron(x);
+}
+
+static inline void
usb_phy_shutdown(struct usb_phy *x)
{
if (x-shutdown)
--
1.7.9.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
[PATCH 1/4] usb: phy: add a new driver for usb3 phy
Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller.
This also includes device tree support for usb3 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 18 +
drivers/usb/phy/Kconfig |9 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-usb3.c | 369 +
include/linux/usb/omap_usb.h | 72
5 files changed, 469 insertions(+)
create mode 100644 drivers/usb/phy/omap-usb3.c
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148..7c5fd89 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -15,3 +15,21 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58,
0x4a002300 0x4;
};
+
+OMAP USB3 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb3
+ - reg : Address and length of the register set for the device. Also
+add the address of control module phy power register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40,
+ 0x4a002370 0x4;
+};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 63c339b..353dc0c 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -13,6 +13,15 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config OMAP_USB3
+ tristate OMAP USB3 PHY Driver
+ select USB_OTG_UTILS
+ help
+ Enable this to support the USB3 PHY that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b069f29..973b1e6 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
+obj-$(CONFIG_OMAP_USB3)+= omap-usb3.o
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
new file mode 100644
index 000..4dc84ca
--- /dev/null
+++ b/drivers/usb/phy/omap-usb3.c
@@ -0,0 +1,369 @@
+/*
+ * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/usb/omap_usb.h
+#include linux/of.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+
+static struct usb_dpll_params omap_usb3_dpll_params[NUM_SYS_CLKS] = {
+ {1250, 5, 4, 20, 0},/* 12 MHz */
+ {3125, 20, 4, 20, 0}, /* 16.8 MHz */
+ {1172, 8, 4, 20, 65537},/* 19.2 MHz */
+ {1250, 12, 4, 20, 0}, /* 26 MHz */
+ {3125, 47, 4, 20, 92843}, /* 38.4 MHz */
+};
+
+/**
+ * omap5_usb_phy_power - power on/off the serializer using control module
+ * @phy: struct omap_usb *
+ * @on: 0 to off and 1 to on based on powering on or off the PHY
+ *
+ * omap_usb3 can call this API to power on or off the PHY.
+ */
+static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
+{
+ u32 val;
+ unsigned long rate;
+ struct clk *sys_clk;
+
+ sys_clk = clk_get(NULL, sys_clkin);
+ if (IS_ERR(sys_clk)) {
+ pr_err(%s:
[PATCH 3/4] usb: phy: omap-usb3: Decrease the number of transitions to recovery
Power-cycling the PHY (partially) decreases the number of transitions to
Recovery state. Hence changed the power up sequence to a partial
power-up before a full power-up of the PHY.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
---
drivers/usb/phy/omap-usb3.c | 43 --
include/linux/usb/omap_usb.h |1 +
2 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
index 26402d5..fb3c5e6 100644
--- a/drivers/usb/phy/omap-usb3.c
+++ b/drivers/usb/phy/omap-usb3.c
@@ -35,13 +35,15 @@ static struct usb_dpll_params
omap_usb3_dpll_params[NUM_SYS_CLKS] = {
};
/**
- * omap5_usb_phy_power - power on/off the serializer using control module
+ * omap5_usb_phy_partial_powerup - power on the serializer using control module
* @phy: struct omap_usb *
- * @on: 0 to off and 1 to on based on powering on or off the PHY
*
- * omap_usb3 can call this API to power on or off the PHY.
+ * After the dwc3 module is disabled and enabled again the synchronization
+ * between dwc3 and phy goes bad and the device does not get enumerated
+ * in superspeed mode. After some trials it was found powering up TX and
+ * part of RX PHY helped to solve the issue.
*/
-static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
+static int omap5_usb_phy_partial_powerup(struct omap_usb *phy)
{
u32 val;
unsigned long rate;
@@ -58,10 +60,32 @@ static int omap5_usb_phy_power(struct omap_usb *phy, bool
on)
val = readl(phy-control_dev);
+ val = ~(USB_PWRCTL_CLK_CMD_MASK | USB_PWRCTL_CLK_FREQ_MASK);
+ val |= (USB3_PHY_PARTIAL_RX_POWERON | USB3_PHY_TX_RX_POWERON)
+USB_PWRCTL_CLK_CMD_SHIFT;
+ val |= rate USB_PWRCTL_CLK_FREQ_SHIFT;
+
+ writel(val, phy-control_dev);
+
+ return 0;
+}
+
+/**
+ * omap5_usb_phy_power - power on/off the serializer using control module
+ * @phy: struct omap_usb *
+ * @on: 0 to off and 1 to on based on powering on or off the PHY
+ *
+ * omap_usb3 can call this API to power on or off the PHY.
+ */
+static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
+{
+ u32 val;
+
+ val = readl(phy-control_dev);
+
if (on) {
- val = ~(USB_PWRCTL_CLK_CMD_MASK | USB_PWRCTL_CLK_FREQ_MASK);
+ val = ~USB_PWRCTL_CLK_CMD_MASK;
val |= USB3_PHY_TX_RX_POWERON USB_PWRCTL_CLK_CMD_SHIFT;
- val |= rate USB_PWRCTL_CLK_FREQ_SHIFT;
} else {
val = ~USB_PWRCTL_CLK_CMD_MASK;
val |= USB3_PHY_TX_RX_POWEROFF USB_PWRCTL_CLK_CMD_SHIFT;
@@ -207,6 +231,13 @@ static int omap_usb3_init(struct usb_phy *x)
struct omap_usb *phy = phy_to_omapusb(x);
omap_usb_dpll_lock(phy);
+ omap5_usb_phy_partial_powerup(phy);
+ /*
+* Give enough time for the PHY to partially power-up before
+* powering it up completely. delay value suggested by the HW
+* team.
+*/
+ mdelay(100);
omap5_usb_phy_power(phy, 1);
return 0;
diff --git a/include/linux/usb/omap_usb.h b/include/linux/usb/omap_usb.h
index 01ed008..62b637c 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/usb/omap_usb.h
@@ -92,6 +92,7 @@ struct omap_usb {
#defineUSB3_PHY_TX_RX_POWERON 0x3
#defineUSB3_PHY_TX_RX_POWEROFF 0x0
+#defineUSB3_PHY_PARTIAL_RX_POWERON (0x1 6)
#definephy_to_omapusb(x) container_of((x), struct omap_usb, phy)
--
1.7.9.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: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
On Tue, Sep 18, 2012 at 5:02 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Sep 18, 2012 at 06:10:50PM +0530, Sourav Poddar wrote: Greg's tty-next is not booting on 2420 based N800. The failure is observed at serial init itself. The reason might be that n800 tries to resume even though it is not suspended before. Reported-by: Paul Walmsley p...@pwsan.com Signed-off-by: Sourav Poddar sourav.pod...@ti.com FWIW: Reviewed-by: Felipe Balbi ba...@ti.com Paul does this fix the issue for you ? Note that it depends on a previous patch Sourav sent [1] [1] http://marc.info/?l=linux-omapm=134796819607889w=2 There's one thing that gets my attention, though, why only n800 would fail here ? I wonder if we should be using: pm_runtime_set_active(dev); pm_runtime_get_enable(dev); to prevent our runtime_resume() to be called from probe, but Sourav tested and it doesn't work on BeagleBoard, but it works on PandaBoard. Does it ring any bell ?? Well I guess it's normal resume callback is called during probe as pm_runtime_get_sync() is called there, and according to documentation [1], devices are assumed to be suspended before probe is called. According to [1], pm_runtime_set_active() should be called before pm_runtime_enable() to indicate to the core that device is active during probe if that's the case, I guess this means pm_runtime_get_sync() is not needed in that case, but I'm not sure what's the actual serial state during probe nowadays. [1] chapter 5 of Documentation/power/runtime_pm.txt: The initial runtime PM status of all devices is 'suspended', but it need not reflect the actual physical state of the device. Thus, if the device is initially active (i.e. it is able to process I/O), its runtime PM status must be changed to 'active', with the help of pm_runtime_set_active(), before pm_runtime_enable() is called for the device. -- Gražvydas -- 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 2/4] usb: dwc3: Fix gadget pullup in SS mode
Hi,
On Wed, Sep 19, 2012 at 05:00:27PM +0530, Kishon Vijay Abraham I wrote:
From: Moiz Sonasath m-sonas...@ti.com
For the gadget pullup functionality to work in
SS mode it requires a particular sequence of
toggling the run-stop bit. Here is the required
sequence:
- Set DCTL[31]
- Clear DCTL[31]
- Clear OMAP5430_CONTROL_CORE__PHY_POWER_USB[14]
- Clear DCTL[8:5] = 0x00
- Set DCTL[8:5] = 0x05
- Wait 25 Ms
- Set DCTL[31]
- Set OMAP5430_CONTROL_CORE__PHY_POWER_USB[14]
Tested rigourously the gadget pull-up functionality
in bot HS and SS modes.
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
this needs to split into three patches:
add new poweron field, implement it on omap-usb3, use it on
dwc3/gadget.c
btw, I don't think the changes to run_stop bit are necessary and if they
are, that'd either be a silicon errata or it would've been mentioned on
the databook. I don't remember seeing that on the databook so I'm
assuming that this is caused by a bad use of the PHY.
Why that mdelay(25) ? why 25 ms ? That's quite a long time, actually.
---
drivers/usb/dwc3/gadget.c | 21 +++--
drivers/usb/phy/omap-usb3.c | 16
include/linux/usb/phy.h | 10 +-
3 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 58fdfad..bcc0102 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -49,6 +49,7 @@
#include linux/usb/ch9.h
#include linux/usb/gadget.h
+#include linux/usb/otg.h
#include core.h
#include gadget.h
@@ -1417,19 +1418,27 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on)
reg = dwc3_readl(dwc-regs, DWC3_DCTL);
if (is_on) {
if (dwc-revision = DWC3_REVISION_187A) {
- reg = ~DWC3_DCTL_TRGTULST_MASK;
- reg |= DWC3_DCTL_TRGTULST_RX_DET;
+ reg = ~DWC3_DCTL_ULSTCHNGREQ_MASK;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ reg |= DWC3_DCTL_ULSTCHNG_RX_DETECT;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ mdelay(25);
+ reg |= DWC3_DCTL_RUN_STOP;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ usb_phy_poweron(dwc-usb3_phy);
}
- if (dwc-revision = DWC3_REVISION_194A)
+ if (dwc-revision = DWC3_REVISION_194A) {
reg = ~DWC3_DCTL_KEEP_CONNECT;
- reg |= DWC3_DCTL_RUN_STOP;
+ reg |= DWC3_DCTL_RUN_STOP;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ }
} else {
reg = ~DWC3_DCTL_RUN_STOP;
+ dwc3_writel(dwc-regs, DWC3_DCTL, reg);
+ usb_phy_shutdown(dwc-usb3_phy);
}
- dwc3_writel(dwc-regs, DWC3_DCTL, reg);
I'd prefer to hold all values on the variable and write only one.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/4] usb: phy: omap-usb3: Decrease the number of transitions to recovery
On Wed, Sep 19, 2012 at 05:00:28PM +0530, Kishon Vijay Abraham I wrote:
Power-cycling the PHY (partially) decreases the number of transitions to
Recovery state. Hence changed the power up sequence to a partial
power-up before a full power-up of the PHY.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
this can be amended to patch 1. Why would you introduce a driver with a
known problem ? ;-)
---
drivers/usb/phy/omap-usb3.c | 43
--
include/linux/usb/omap_usb.h |1 +
2 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
index 26402d5..fb3c5e6 100644
--- a/drivers/usb/phy/omap-usb3.c
+++ b/drivers/usb/phy/omap-usb3.c
@@ -35,13 +35,15 @@ static struct usb_dpll_params
omap_usb3_dpll_params[NUM_SYS_CLKS] = {
};
/**
- * omap5_usb_phy_power - power on/off the serializer using control module
+ * omap5_usb_phy_partial_powerup - power on the serializer using control
module
* @phy: struct omap_usb *
- * @on: 0 to off and 1 to on based on powering on or off the PHY
*
- * omap_usb3 can call this API to power on or off the PHY.
+ * After the dwc3 module is disabled and enabled again the synchronization
+ * between dwc3 and phy goes bad and the device does not get enumerated
+ * in superspeed mode. After some trials it was found powering up TX and
+ * part of RX PHY helped to solve the issue.
*/
-static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
+static int omap5_usb_phy_partial_powerup(struct omap_usb *phy)
{
u32 val;
unsigned long rate;
@@ -58,10 +60,32 @@ static int omap5_usb_phy_power(struct omap_usb *phy, bool
on)
val = readl(phy-control_dev);
+ val = ~(USB_PWRCTL_CLK_CMD_MASK | USB_PWRCTL_CLK_FREQ_MASK);
+ val |= (USB3_PHY_PARTIAL_RX_POWERON | USB3_PHY_TX_RX_POWERON)
+ USB_PWRCTL_CLK_CMD_SHIFT;
+ val |= rate USB_PWRCTL_CLK_FREQ_SHIFT;
+
+ writel(val, phy-control_dev);
+
+ return 0;
+}
+
+/**
+ * omap5_usb_phy_power - power on/off the serializer using control module
+ * @phy: struct omap_usb *
+ * @on: 0 to off and 1 to on based on powering on or off the PHY
+ *
+ * omap_usb3 can call this API to power on or off the PHY.
+ */
+static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
+{
+ u32 val;
+
+ val = readl(phy-control_dev);
+
if (on) {
- val = ~(USB_PWRCTL_CLK_CMD_MASK | USB_PWRCTL_CLK_FREQ_MASK);
+ val = ~USB_PWRCTL_CLK_CMD_MASK;
val |= USB3_PHY_TX_RX_POWERON USB_PWRCTL_CLK_CMD_SHIFT;
- val |= rate USB_PWRCTL_CLK_FREQ_SHIFT;
} else {
val = ~USB_PWRCTL_CLK_CMD_MASK;
val |= USB3_PHY_TX_RX_POWEROFF USB_PWRCTL_CLK_CMD_SHIFT;
@@ -207,6 +231,13 @@ static int omap_usb3_init(struct usb_phy *x)
struct omap_usb *phy = phy_to_omapusb(x);
omap_usb_dpll_lock(phy);
+ omap5_usb_phy_partial_powerup(phy);
+ /*
+ * Give enough time for the PHY to partially power-up before
+ * powering it up completely. delay value suggested by the HW
+ * team.
+ */
+ mdelay(100);
why 100 ms ? Has this been measured ? Again, 100 ms is a loong time.
Soon enough user will be waiting for a bit over a second to see that
after connecting usb cable, there's activity. We don't want user to
notice that kind of thing ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
instead, can't you just always try to get the clock but ignore the error
if it fails ?
If it works you can set a flag to let you know that you can use that
optional clock.
--
balbi
signature.asc
Description: Digital signature
[PATCH v2 00/15] tidspbridge driver MMU-related cleanups
Hello, Here's the second version of my tidspbridge MMU-related cleanup patches. The first version has been sent privately only, don't try to search the mailing list archive for it :-) Replacing hw/hw_mmu.c and part of core/tiomap3430.c with generic IOMMU calls should be less difficult now. Anyone would like to give it a try? Laurent Pinchart (14): tidspbridge: hw_mmu: Reorder functions to avoid forward declarations tidspbridge: hw_mmu: Removed unused functions tidspbridge: tiomap3430: Reorder functions to avoid forward declarations tidspbridge: tiomap3430: Remove unneeded dev_context local variables tidspbridge: tiomap3430: Factor out common page release code tidspbridge: tiomap3430: Remove ul_ prefix tidspbridge: tiomap3430: Remove unneeded local variables tidspbridge: Fix VM_PFNMAP mapping tidspbridge: Remove unused hw_mmu_map_attrs_t::donotlockmpupage field arm: omap: iommu: Include required headers in iommu.h and iopgtable.h tidspbridge: Use constants defined in IOMMU platform headers tidspbridge: Simplify pte_update and mem_map_vmalloc functions tidspbridge: Use correct types to describe physical, MPU, DSP addresses tidspbridge: Replace hw_mmu_map_attrs_t structure with a prot bitfield Omar Ramirez Luna (1): ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected arch/arm/plat-omap/include/plat/iommu.h|6 + arch/arm/plat-omap/include/plat/iopgtable.h|2 + drivers/staging/tidspbridge/core/io_sm.c |7 +- drivers/staging/tidspbridge/core/tiomap3430.c | 1484 +--- drivers/staging/tidspbridge/core/tiomap_io.c |2 +- drivers/staging/tidspbridge/core/ue_deh.c | 21 +- drivers/staging/tidspbridge/hw/hw_defs.h | 22 - drivers/staging/tidspbridge/hw/hw_mmu.c| 332 ++ drivers/staging/tidspbridge/hw/hw_mmu.h| 67 +- .../staging/tidspbridge/include/dspbridge/drv.h|1 + .../tidspbridge/include/dspbridge/dspdefs.h| 27 +- .../tidspbridge/include/dspbridge/dspioctl.h | 25 + drivers/staging/tidspbridge/rmgr/proc.c| 119 +- 13 files changed, 899 insertions(+), 1216 deletions(-) -- Regards, Laurent Pinchart -- 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 01/15] tidspbridge: hw_mmu: Reorder functions to avoid forward declarations
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/hw/hw_mmu.c | 95 +--
1 files changed, 39 insertions(+), 56 deletions(-)
diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.c
b/drivers/staging/tidspbridge/hw/hw_mmu.c
index 8a93d55..2194a3f 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.c
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.c
@@ -70,7 +70,16 @@ enum hw_mmu_page_size_t {
* METHOD:: Check the Input parameter and Flush a
* single entry in the TLB.
*/
-static hw_status mmu_flush_entry(const void __iomem *base_address);
+static hw_status mmu_flush_entry(const void __iomem *base_address)
+{
+ hw_status status = 0;
+ u32 flush_entry_data = 0x1;
+
+ /* write values to register */
+ MMUMMU_FLUSH_ENTRY_WRITE_REGISTER32(base_address, flush_entry_data);
+
+ return status;
+}
/*
* FUNCTION : mmu_set_cam_entry
@@ -116,7 +125,20 @@ static hw_status mmu_set_cam_entry(const void __iomem
*base_address,
const u32 page_sz,
const u32 preserved_bit,
const u32 valid_bit,
- const u32 virtual_addr_tag);
+ const u32 virtual_addr_tag)
+{
+ hw_status status = 0;
+ u32 mmu_cam_reg;
+
+ mmu_cam_reg = (virtual_addr_tag 12);
+ mmu_cam_reg = (mmu_cam_reg) | (page_sz) | (valid_bit 2) |
+ (preserved_bit 3);
+
+ /* write values to register */
+ MMUMMU_CAM_WRITE_REGISTER32(base_address, mmu_cam_reg);
+
+ return status;
+}
/*
* FUNCTION : mmu_set_ram_entry
@@ -161,7 +183,21 @@ static hw_status mmu_set_ram_entry(const void __iomem
*base_address,
const u32 physical_addr,
enum hw_endianism_t endianism,
enum hw_element_size_t element_size,
- enum hw_mmu_mixed_size_t mixed_size);
+ enum hw_mmu_mixed_size_t mixed_size)
+{
+ hw_status status = 0;
+ u32 mmu_ram_reg;
+
+ mmu_ram_reg = (physical_addr MMU_ADDR_MASK);
+ mmu_ram_reg = (mmu_ram_reg) | ((endianism 9) | (element_size 7) |
+ (mixed_size 6));
+
+ /* write values to register */
+ MMUMMU_RAM_WRITE_REGISTER32(base_address, mmu_ram_reg);
+
+ return status;
+
+}
/* HW FUNCTIONS */
@@ -503,59 +539,6 @@ hw_status hw_mmu_pte_clear(const u32 pg_tbl_va, u32
virtual_addr, u32 page_size)
return status;
}
-/* mmu_flush_entry */
-static hw_status mmu_flush_entry(const void __iomem *base_address)
-{
- hw_status status = 0;
- u32 flush_entry_data = 0x1;
-
- /* write values to register */
- MMUMMU_FLUSH_ENTRY_WRITE_REGISTER32(base_address, flush_entry_data);
-
- return status;
-}
-
-/* mmu_set_cam_entry */
-static hw_status mmu_set_cam_entry(const void __iomem *base_address,
- const u32 page_sz,
- const u32 preserved_bit,
- const u32 valid_bit,
- const u32 virtual_addr_tag)
-{
- hw_status status = 0;
- u32 mmu_cam_reg;
-
- mmu_cam_reg = (virtual_addr_tag 12);
- mmu_cam_reg = (mmu_cam_reg) | (page_sz) | (valid_bit 2) |
- (preserved_bit 3);
-
- /* write values to register */
- MMUMMU_CAM_WRITE_REGISTER32(base_address, mmu_cam_reg);
-
- return status;
-}
-
-/* mmu_set_ram_entry */
-static hw_status mmu_set_ram_entry(const void __iomem *base_address,
- const u32 physical_addr,
- enum hw_endianism_t endianism,
- enum hw_element_size_t element_size,
- enum hw_mmu_mixed_size_t mixed_size)
-{
- hw_status status = 0;
- u32 mmu_ram_reg;
-
- mmu_ram_reg = (physical_addr MMU_ADDR_MASK);
- mmu_ram_reg = (mmu_ram_reg) | ((endianism 9) | (element_size 7) |
- (mixed_size 6));
-
- /* write values to register */
- MMUMMU_RAM_WRITE_REGISTER32(base_address, mmu_ram_reg);
-
- return status;
-
-}
-
void hw_mmu_tlb_flush_all(const void __iomem *base)
{
__raw_writel(1, base + MMU_GFLUSH);
--
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 02/15] tidspbridge: hw_mmu: Removed unused functions
The hw_mmu_tlb_flush() function is unused, and the mmu_flush_entry()
function is used by hw_mmu_tlb_flush() only. Remove them both.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/hw/hw_mmu.c | 72 ---
drivers/staging/tidspbridge/hw/hw_mmu.h |3 -
2 files changed, 0 insertions(+), 75 deletions(-)
diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.c
b/drivers/staging/tidspbridge/hw/hw_mmu.c
index 2194a3f..981794d 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.c
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.c
@@ -48,40 +48,6 @@ enum hw_mmu_page_size_t {
};
/*
- * FUNCTION : mmu_flush_entry
- *
- * INPUTS:
- *
- * Identifier : base_address
- * Type : const u32
- * Description : Base Address of instance of MMU module
- *
- * RETURNS:
- *
- * Type : hw_status
- * Description : 0-- No errors occurred
- * RET_BAD_NULL_PARAM -- A Pointer
- * Paramater was set to NULL
- *
- * PURPOSE: : Flush the TLB entry pointed by the
- * lock counter register
- * even if this entry is set protected
- *
- * METHOD:: Check the Input parameter and Flush a
- * single entry in the TLB.
- */
-static hw_status mmu_flush_entry(const void __iomem *base_address)
-{
- hw_status status = 0;
- u32 flush_entry_data = 0x1;
-
- /* write values to register */
- MMUMMU_FLUSH_ENTRY_WRITE_REGISTER32(base_address, flush_entry_data);
-
- return status;
-}
-
-/*
* FUNCTION : mmu_set_cam_entry
*
* INPUTS:
@@ -321,44 +287,6 @@ hw_status hw_mmu_twl_disable(const void __iomem
*base_address)
return status;
}
-hw_status hw_mmu_tlb_flush(const void __iomem *base_address, u32 virtual_addr,
- u32 page_sz)
-{
- hw_status status = 0;
- u32 virtual_addr_tag;
- enum hw_mmu_page_size_t pg_size_bits;
-
- switch (page_sz) {
- case HW_PAGE_SIZE4KB:
- pg_size_bits = HW_MMU_SMALL_PAGE;
- break;
-
- case HW_PAGE_SIZE64KB:
- pg_size_bits = HW_MMU_LARGE_PAGE;
- break;
-
- case HW_PAGE_SIZE1MB:
- pg_size_bits = HW_MMU_SECTION;
- break;
-
- case HW_PAGE_SIZE16MB:
- pg_size_bits = HW_MMU_SUPERSECTION;
- break;
-
- default:
- return -EINVAL;
- }
-
- /* Generate the 20-bit tag from virtual address */
- virtual_addr_tag = ((virtual_addr MMU_ADDR_MASK) 12);
-
- mmu_set_cam_entry(base_address, pg_size_bits, 0, 0, virtual_addr_tag);
-
- mmu_flush_entry(base_address);
-
- return status;
-}
-
hw_status hw_mmu_tlb_add(const void __iomem *base_address,
u32 physical_addr,
u32 virtual_addr,
diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.h
b/drivers/staging/tidspbridge/hw/hw_mmu.h
index 1458a2c..7f960cd 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.h
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.h
@@ -76,9 +76,6 @@ extern hw_status hw_mmu_twl_enable(const void __iomem
*base_address);
extern hw_status hw_mmu_twl_disable(const void __iomem *base_address);
-extern hw_status hw_mmu_tlb_flush(const void __iomem *base_address,
- u32 virtual_addr, u32 page_sz);
-
extern hw_status hw_mmu_tlb_add(const void __iomem *base_address,
u32 physical_addr,
u32 virtual_addr,
--
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 03/15] tidspbridge: tiomap3430: Reorder functions to avoid forward declarations
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 1123 -
1 files changed, 537 insertions(+), 586 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index f9609ce..fa5b7b9 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -79,55 +79,6 @@
#define OMAP343X_CONTROL_IVA2_BOOTADDR (OMAP2_CONTROL_GENERAL + 0x0190)
#define OMAP343X_CONTROL_IVA2_BOOTMOD (OMAP2_CONTROL_GENERAL + 0x0194)
-/* Forward Declarations: */
-static int bridge_brd_monitor(struct bridge_dev_context *dev_ctxt);
-static int bridge_brd_read(struct bridge_dev_context *dev_ctxt,
- u8 *host_buff,
- u32 dsp_addr, u32 ul_num_bytes,
- u32 mem_type);
-static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
- u32 dsp_addr);
-static int bridge_brd_status(struct bridge_dev_context *dev_ctxt,
- int *board_state);
-static int bridge_brd_stop(struct bridge_dev_context *dev_ctxt);
-static int bridge_brd_write(struct bridge_dev_context *dev_ctxt,
- u8 *host_buff,
- u32 dsp_addr, u32 ul_num_bytes,
- u32 mem_type);
-static int bridge_brd_set_state(struct bridge_dev_context *dev_ctxt,
- u32 brd_state);
-static int bridge_brd_mem_copy(struct bridge_dev_context *dev_ctxt,
- u32 dsp_dest_addr, u32 dsp_src_addr,
- u32 ul_num_bytes, u32 mem_type);
-static int bridge_brd_mem_write(struct bridge_dev_context *dev_ctxt,
- u8 *host_buff, u32 dsp_addr,
- u32 ul_num_bytes, u32 mem_type);
-static int bridge_brd_mem_map(struct bridge_dev_context *dev_ctxt,
- u32 ul_mpu_addr, u32 virt_addr,
- u32 ul_num_bytes, u32 ul_map_attr,
- struct page **mapped_pages);
-static int bridge_brd_mem_un_map(struct bridge_dev_context *dev_ctxt,
-u32 virt_addr, u32 ul_num_bytes);
-static int bridge_dev_create(struct bridge_dev_context
- **dev_cntxt,
- struct dev_object *hdev_obj,
- struct cfg_hostres *config_param);
-static int bridge_dev_ctrl(struct bridge_dev_context *dev_context,
- u32 dw_cmd, void *pargs);
-static int bridge_dev_destroy(struct bridge_dev_context *dev_ctxt);
-static u32 user_va2_pa(struct mm_struct *mm, u32 address);
-static int pte_update(struct bridge_dev_context *dev_ctxt, u32 pa,
-u32 va, u32 size,
-struct hw_mmu_map_attrs_t *map_attrs);
-static int pte_set(struct pg_table_attrs *pt, u32 pa, u32 va,
- u32 size, struct hw_mmu_map_attrs_t *attrs);
-static int mem_map_vmalloc(struct bridge_dev_context *dev_context,
- u32 ul_mpu_addr, u32 virt_addr,
- u32 ul_num_bytes,
- struct hw_mmu_map_attrs_t *hw_attrs);
-
-bool wait_for_start(struct bridge_dev_context *dev_context, u32 dw_sync_addr);
-
/* --- Globals */
/* Attributes of L2 page tables for DSP MMU */
@@ -166,96 +117,10 @@ struct pg_table_attrs {
struct page_info *pg_info;
};
-/*
- * This Bridge driver's function interface table.
- */
-static struct bridge_drv_interface drv_interface_fxns = {
- /* Bridge API ver. for which this bridge driver is built. */
- BRD_API_MAJOR_VERSION,
- BRD_API_MINOR_VERSION,
- bridge_dev_create,
- bridge_dev_destroy,
- bridge_dev_ctrl,
- bridge_brd_monitor,
- bridge_brd_start,
- bridge_brd_stop,
- bridge_brd_status,
- bridge_brd_read,
- bridge_brd_write,
- bridge_brd_set_state,
- bridge_brd_mem_copy,
- bridge_brd_mem_write,
- bridge_brd_mem_map,
- bridge_brd_mem_un_map,
- /* The following CHNL functions are provided by chnl_io.lib: */
- bridge_chnl_create,
- bridge_chnl_destroy,
- bridge_chnl_open,
- bridge_chnl_close,
- bridge_chnl_add_io_req,
- bridge_chnl_get_ioc,
- bridge_chnl_cancel_io,
- bridge_chnl_flush_io,
- bridge_chnl_get_info,
- bridge_chnl_get_mgr_info,
- bridge_chnl_idle,
- bridge_chnl_register_notify,
- /* The following IO functions are provided by chnl_io.lib: */
- bridge_io_create,
-
[PATCH v2 04/15] tidspbridge: tiomap3430: Remove unneeded dev_context local variables
Most function that takes a device context as argument immediately assign
it to a local variable of the same type and use the local variable.
Remove the variable and use the function parameter directly. Rename all
remaining occurences of dev_context to dev_ctxt to be consistent with
the rest of the code.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 216 -
1 files changed, 101 insertions(+), 115 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index fa5b7b9..5113da8 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -132,7 +132,6 @@ static struct notifier_block dsp_mbox_notifier = {
*/
static int bridge_brd_monitor(struct bridge_dev_context *dev_ctxt)
{
- struct bridge_dev_context *dev_context = dev_ctxt;
u32 temp;
struct omap_dsp_platform_data *pdata =
omap_dspbridge_dev-dev.platform_data;
@@ -161,7 +160,7 @@ static int bridge_brd_monitor(struct bridge_dev_context
*dev_ctxt)
dsp_clk_enable(DSP_CLK_IVA2);
/* set the device state to IDLE */
- dev_context-brd_state = BRD_IDLE;
+ dev_ctxt-brd_state = BRD_IDLE;
return 0;
}
@@ -176,20 +175,19 @@ static int bridge_brd_read(struct bridge_dev_context
*dev_ctxt,
u32 ul_num_bytes, u32 mem_type)
{
int status = 0;
- struct bridge_dev_context *dev_context = dev_ctxt;
u32 offset;
u32 dsp_base_addr = dev_ctxt-dsp_base_addr;
- if (dsp_addr dev_context-dsp_start_add) {
+ if (dsp_addr dev_ctxt-dsp_start_add) {
status = -EPERM;
return status;
}
/* change here to account for the 3 bands of the DSP internal memory */
- if ((dsp_addr - dev_context-dsp_start_add)
- dev_context-internal_size) {
- offset = dsp_addr - dev_context-dsp_start_add;
+ if ((dsp_addr - dev_ctxt-dsp_start_add)
+ dev_ctxt-internal_size) {
+ offset = dsp_addr - dev_ctxt-dsp_start_add;
} else {
- status = read_ext_dsp_data(dev_context, host_buff, dsp_addr,
+ status = read_ext_dsp_data(dev_ctxt, host_buff, dsp_addr,
ul_num_bytes, mem_type);
return status;
}
@@ -207,18 +205,17 @@ static int bridge_brd_write(struct bridge_dev_context
*dev_ctxt,
u32 ul_num_bytes, u32 mem_type)
{
int status = 0;
- struct bridge_dev_context *dev_context = dev_ctxt;
- if (dsp_addr dev_context-dsp_start_add) {
+ if (dsp_addr dev_ctxt-dsp_start_add) {
status = -EPERM;
return status;
}
- if ((dsp_addr - dev_context-dsp_start_add)
- dev_context-internal_size) {
+ if ((dsp_addr - dev_ctxt-dsp_start_add)
+ dev_ctxt-internal_size) {
status = write_dsp_data(dev_ctxt, host_buff, dsp_addr,
ul_num_bytes, mem_type);
} else {
- status = write_ext_dsp_data(dev_context, host_buff, dsp_addr,
+ status = write_ext_dsp_data(dev_ctxt, host_buff, dsp_addr,
ul_num_bytes, mem_type, false);
}
@@ -234,9 +231,8 @@ static int bridge_brd_set_state(struct bridge_dev_context
*dev_ctxt,
u32 brd_state)
{
int status = 0;
- struct bridge_dev_context *dev_context = dev_ctxt;
- dev_context-brd_state = brd_state;
+ dev_ctxt-brd_state = brd_state;
return status;
}
@@ -244,7 +240,7 @@ static int bridge_brd_set_state(struct bridge_dev_context
*dev_ctxt,
* wait_for_start
* Wait for the singal from DSP that it has started, or time out.
*/
-bool wait_for_start(struct bridge_dev_context *dev_context, u32 dw_sync_addr)
+bool wait_for_start(struct bridge_dev_context *dev_ctxt, u32 dw_sync_addr)
{
u16 timeout = TIHELEN_ACKTIMEOUT;
@@ -274,7 +270,6 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
u32 dsp_addr)
{
int status = 0;
- struct bridge_dev_context *dev_context = dev_ctxt;
u32 dw_sync_addr = 0;
u32 ul_shm_base;/* Gpp Phys SM base addr(byte) */
u32 ul_shm_base_virt; /* Dsp Virt SM base addr */
@@ -299,15 +294,15 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
* last dsp base image was loaded. The first entry is always
* SHMMEM base. */
/* Get SHM_BEG - convert to byte address */
- (void)dev_get_symbol(dev_context-dev_obj, SHMBASENAME,
+
[PATCH v2 05/15] tidspbridge: tiomap3430: Factor out common page release code
The same block of code is used in two places to release pages. Factor it
out to a function.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 81 ++---
1 files changed, 31 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 5113da8..a01e9c5e 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1266,6 +1266,31 @@ static void bad_page_dump(u32 pa, struct page *pg)
dump_stack();
}
+/* Release all pages associated with a physical addresses range. */
+static void bridge_release_pages(u32 paddr, u32 pte_size, u32 num_bytes)
+{
+ struct page *pg;
+ u32 num_pages;
+
+ num_pages = pte_size / PAGE_SIZE;
+
+ for (; num_pages 0; --num_pages, paddr += HW_PAGE_SIZE4KB) {
+ if (!pfn_valid(__phys_to_pfn(paddr)))
+ continue;
+
+ pg = PHYS_TO_PAGE(paddr);
+ if (page_count(pg) 1) {
+ pr_info(DSPBRIDGE: UNMAP function:
+ COUNT 0 FOR PA 0x%x, size =
+ 0x%x\n, paddr, num_bytes);
+ bad_page_dump(paddr, pg);
+ } else {
+ set_page_dirty(pg);
+ page_cache_release(pg);
+ }
+ }
+}
+
/*
* bridge_brd_mem_un_map
* Invalidate the PTEs for the DSP VA block to be unmapped.
@@ -1289,12 +1314,8 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
u32 rem_bytes;
u32 rem_bytes_l2;
u32 va_curr;
- struct page *pg = NULL;
int status = 0;
struct pg_table_attrs *pt = dev_ctxt-pt_attrs;
- u32 temp;
- u32 paddr;
- u32 numof4k_pages = 0;
va_curr = virt_addr;
rem_bytes = ul_num_bytes;
@@ -1354,30 +1375,9 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
break;
}
- /* Collect Physical addresses from VA */
- paddr = (pte_val ~(pte_size - 1));
- if (pte_size == HW_PAGE_SIZE64KB)
- numof4k_pages = 16;
- else
- numof4k_pages = 1;
- temp = 0;
- while (temp++ numof4k_pages) {
- if (!pfn_valid(__phys_to_pfn(paddr))) {
- paddr += HW_PAGE_SIZE4KB;
- continue;
- }
- pg = PHYS_TO_PAGE(paddr);
- if (page_count(pg) 1) {
- pr_info(DSPBRIDGE: UNMAP function:
- COUNT 0 FOR PA 0x%x, size =
- 0x%x\n, paddr, ul_num_bytes);
- bad_page_dump(paddr, pg);
- } else {
- set_page_dirty(pg);
- page_cache_release(pg);
- }
- paddr += HW_PAGE_SIZE4KB;
- }
+ bridge_release_pages(pte_val ~(pte_size - 1),
pte_size,
+ul_num_bytes);
+
if (hw_mmu_pte_clear(pte_addr_l2, va_curr, pte_size)) {
status = -EPERM;
goto EXIT_LOOP;
@@ -1419,28 +1419,9 @@ skip_coarse_page:
break;
}
- if (pte_size == HW_PAGE_SIZE1MB)
- numof4k_pages = 256;
- else
- numof4k_pages = 4096;
- temp = 0;
- /* Collect Physical addresses from VA */
- paddr = (pte_val ~(pte_size - 1));
- while (temp++ numof4k_pages) {
- if (pfn_valid(__phys_to_pfn(paddr))) {
- pg = PHYS_TO_PAGE(paddr);
- if (page_count(pg) 1) {
- pr_info(DSPBRIDGE: UNMAP function:
- COUNT 0 FOR PA 0x%x, size =
- 0x%x\n, paddr, ul_num_bytes);
- bad_page_dump(paddr, pg);
- } else {
- set_page_dirty(pg);
- page_cache_release(pg);
- }
-
[PATCH v2 07/15] tidspbridge: tiomap3430: Remove unneeded local variables
Several local variables just hold copies of function arguments.
Remove them and use the function arguments directly.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 60 +++-
1 files changed, 28 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 3dfb663..2c5be89 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1308,23 +1308,21 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
u32 pte_addr_l2 = 0;
u32 rem_bytes;
u32 rem_bytes_l2;
- u32 va_curr;
int status = 0;
struct pg_table_attrs *pt = dev_ctxt-pt_attrs;
- va_curr = virt_addr;
rem_bytes = num_bytes;
rem_bytes_l2 = 0;
l1_base_va = pt-l1_base_va;
- pte_addr_l1 = hw_mmu_pte_addr_l1(l1_base_va, va_curr);
+ pte_addr_l1 = hw_mmu_pte_addr_l1(l1_base_va, virt_addr);
dev_dbg(bridge, %s dev_ctxt %p, va %x, NumBytes %x l1_base_va %x,
pte_addr_l1 %x\n, __func__, dev_ctxt, virt_addr,
num_bytes, l1_base_va, pte_addr_l1);
while (rem_bytes !status) {
- u32 va_curr_orig = va_curr;
+ u32 virt_addr_orig = virt_addr;
/* Find whether the L1 PTE points to a valid L2 PT */
- pte_addr_l1 = hw_mmu_pte_addr_l1(l1_base_va, va_curr);
+ pte_addr_l1 = hw_mmu_pte_addr_l1(l1_base_va, virt_addr);
pte_val = *(u32 *) pte_addr_l1;
pte_size = hw_mmu_pte_size_l1(pte_val);
@@ -1345,7 +1343,7 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
* page, and the size of VA space that needs to be
* cleared on this L2 page
*/
- pte_addr_l2 = hw_mmu_pte_addr_l2(l2_base_va, va_curr);
+ pte_addr_l2 = hw_mmu_pte_addr_l2(l2_base_va, virt_addr);
pte_count = pte_addr_l2 (HW_MMU_COARSE_PAGE_SIZE - 1);
pte_count = (HW_MMU_COARSE_PAGE_SIZE - pte_count) / sizeof(u32);
if (rem_bytes (pte_count * PG_SIZE4K))
@@ -1363,9 +1361,9 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
while (rem_bytes_l2 !status) {
pte_val = *(u32 *) pte_addr_l2;
pte_size = hw_mmu_pte_size_l2(pte_val);
- /* va_curr aligned to pte_size? */
+ /* virt_addr aligned to pte_size? */
if (pte_size == 0 || rem_bytes_l2 pte_size ||
- va_curr (pte_size - 1)) {
+ virt_addr (pte_size - 1)) {
status = -EPERM;
break;
}
@@ -1373,14 +1371,14 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
bridge_release_pages(pte_val ~(pte_size - 1),
pte_size,
num_bytes);
- if (hw_mmu_pte_clear(pte_addr_l2, va_curr, pte_size)) {
+ if (hw_mmu_pte_clear(pte_addr_l2, virt_addr, pte_size))
{
status = -EPERM;
goto EXIT_LOOP;
}
status = 0;
rem_bytes_l2 -= pte_size;
- va_curr += pte_size;
+ virt_addr += pte_size;
pte_addr_l2 += (pte_size 12) * sizeof(u32);
}
spin_lock(pt-pg_lock);
@@ -1390,7 +1388,7 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
/*
* Clear the L1 PTE pointing to the L2 PT
*/
- if (!hw_mmu_pte_clear(l1_base_va, va_curr_orig,
+ if (!hw_mmu_pte_clear(l1_base_va,
virt_addr_orig,
HW_MMU_COARSE_PAGE_SIZE))
status = 0;
else {
@@ -1406,10 +1404,10 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
spin_unlock(pt-pg_lock);
continue;
skip_coarse_page:
- /* va_curr aligned to pte_size? */
+ /* virt_addr aligned to pte_size? */
/* pte_size = 1 MB or 16 MB */
if (pte_size == 0 || rem_bytes pte_size ||
- va_curr (pte_size - 1)) {
+ virt_addr (pte_size - 1)) {
status = -EPERM;
break;
[PATCH v2 09/15] tidspbridge: Remove unused hw_mmu_map_attrs_t::donotlockmpupage field
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c |4
drivers/staging/tidspbridge/hw/hw_mmu.h |1 -
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index cc538ea..5cd85dc 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1508,10 +1508,6 @@ static int bridge_brd_mem_map(struct bridge_dev_context
*dev_ctxt,
return -EINVAL;
}
}
- if (attrs DSP_MAPDONOTLOCK)
- hw_attrs.donotlockmpupage = 1;
- else
- hw_attrs.donotlockmpupage = 0;
if (attrs DSP_MAPVMALLOCADDR) {
return mem_map_vmalloc(dev_ctxt, mpu_addr, virt_addr,
diff --git a/drivers/staging/tidspbridge/hw/hw_mmu.h
b/drivers/staging/tidspbridge/hw/hw_mmu.h
index 7f960cd..37fc4d4 100644
--- a/drivers/staging/tidspbridge/hw/hw_mmu.h
+++ b/drivers/staging/tidspbridge/hw/hw_mmu.h
@@ -39,7 +39,6 @@ struct hw_mmu_map_attrs_t {
enum hw_endianism_t endianism;
enum hw_element_size_t element_size;
enum hw_mmu_mixed_size_t mixed_size;
- bool donotlockmpupage;
};
extern hw_status hw_mmu_enable(const void __iomem *base_address);
--
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 06/15] tidspbridge: tiomap3430: Remove ul_ prefix
There's no need to prefix all u32 variables with ul_.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 183 -
1 files changed, 87 insertions(+), 96 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index a01e9c5e..3dfb663 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -172,7 +172,7 @@ static int bridge_brd_monitor(struct bridge_dev_context
*dev_ctxt)
*/
static int bridge_brd_read(struct bridge_dev_context *dev_ctxt,
u8 *host_buff, u32 dsp_addr,
- u32 ul_num_bytes, u32 mem_type)
+ u32 num_bytes, u32 mem_type)
{
int status = 0;
u32 offset;
@@ -188,11 +188,11 @@ static int bridge_brd_read(struct bridge_dev_context
*dev_ctxt,
offset = dsp_addr - dev_ctxt-dsp_start_add;
} else {
status = read_ext_dsp_data(dev_ctxt, host_buff, dsp_addr,
- ul_num_bytes, mem_type);
+ num_bytes, mem_type);
return status;
}
/* copy the data from DSP memory, */
- memcpy(host_buff, (void *)(dsp_base_addr + offset), ul_num_bytes);
+ memcpy(host_buff, (void *)(dsp_base_addr + offset), num_bytes);
return status;
}
@@ -202,7 +202,7 @@ static int bridge_brd_read(struct bridge_dev_context
*dev_ctxt,
*/
static int bridge_brd_write(struct bridge_dev_context *dev_ctxt,
u8 *host_buff, u32 dsp_addr,
- u32 ul_num_bytes, u32 mem_type)
+ u32 num_bytes, u32 mem_type)
{
int status = 0;
@@ -213,10 +213,10 @@ static int bridge_brd_write(struct bridge_dev_context
*dev_ctxt,
if ((dsp_addr - dev_ctxt-dsp_start_add)
dev_ctxt-internal_size) {
status = write_dsp_data(dev_ctxt, host_buff, dsp_addr,
- ul_num_bytes, mem_type);
+ num_bytes, mem_type);
} else {
status = write_ext_dsp_data(dev_ctxt, host_buff, dsp_addr,
- ul_num_bytes, mem_type, false);
+ num_bytes, mem_type, false);
}
return status;
@@ -271,21 +271,21 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
{
int status = 0;
u32 dw_sync_addr = 0;
- u32 ul_shm_base;/* Gpp Phys SM base addr(byte) */
- u32 ul_shm_base_virt; /* Dsp Virt SM base addr */
- u32 ul_tlb_base_virt; /* Base of MMU TLB entry */
+ u32 shm_base; /* Gpp Phys SM base addr(byte) */
+ u32 shm_base_virt; /* Dsp Virt SM base addr */
+ u32 tlb_base_virt; /* Base of MMU TLB entry */
/* Offset of shm_base_virt from tlb_base_virt */
- u32 ul_shm_offset_virt;
+ u32 shm_offset_virt;
s32 entry_ndx;
s32 itmp_entry_ndx = 0; /* DSP-MMU TLB entry base address */
struct cfg_hostres *resources = NULL;
u32 temp;
- u32 ul_dsp_clk_rate;
- u32 ul_dsp_clk_addr;
- u32 ul_bios_gp_timer;
+ u32 dsp_clk_rate;
+ u32 dsp_clk_addr;
+ u32 bios_gp_timer;
u32 clk_cmd;
struct io_mgr *hio_mgr;
- u32 ul_load_monitor_timer;
+ u32 load_monitor_timer;
u32 wdt_en = 0;
struct omap_dsp_platform_data *pdata =
omap_dspbridge_dev-dev.platform_data;
@@ -294,21 +294,19 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
* last dsp base image was loaded. The first entry is always
* SHMMEM base. */
/* Get SHM_BEG - convert to byte address */
- (void)dev_get_symbol(dev_ctxt-dev_obj, SHMBASENAME,
-ul_shm_base_virt);
- ul_shm_base_virt *= DSPWORDSIZE;
+ (void)dev_get_symbol(dev_ctxt-dev_obj, SHMBASENAME, shm_base_virt);
+ shm_base_virt *= DSPWORDSIZE;
/* DSP Virtual address */
- ul_tlb_base_virt = dev_ctxt-atlb_entry[0].dsp_va;
- ul_shm_offset_virt =
- ul_shm_base_virt - (ul_tlb_base_virt * DSPWORDSIZE);
+ tlb_base_virt = dev_ctxt-atlb_entry[0].dsp_va;
+ shm_offset_virt = shm_base_virt - (tlb_base_virt * DSPWORDSIZE);
/* Kernel logical address */
- ul_shm_base = dev_ctxt-atlb_entry[0].gpp_va + ul_shm_offset_virt;
+ shm_base = dev_ctxt-atlb_entry[0].gpp_va + shm_offset_virt;
/* 2nd wd is used as sync field */
- dw_sync_addr = ul_shm_base + SHMSYNCOFFSET;
+ dw_sync_addr = shm_base + SHMSYNCOFFSET;
/* Write a signature into the shm base
[PATCH v2 10/15] ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
From: Omar Ramirez Luna omar.l...@linaro.org
If included without IOMMU_API being selected it will break
compilation:
arch/arm/plat-omap/include/plat/iommu.h:
In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:148:
error: 'struct dev_archdata' has no member named 'iommu'
This will be seen when hwmod includes iommu.h to get the
structure for attributes.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/plat-omap/include/plat/iommu.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 88be3e6..e58d571 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -126,6 +126,7 @@ struct omap_iommu_arch_data {
struct omap_iommu *iommu_dev;
};
+#ifdef CONFIG_IOMMU_API
/**
* dev_to_omap_iommu() - retrieves an omap iommu object from a user device
* @dev: iommu client device
@@ -136,6 +137,7 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
return arch_data-iommu_dev;
}
+#endif
/* IOMMU errors */
#define OMAP_IOMMU_ERR_TLB_MISS(1 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 v2 11/15] arm: omap: iommu: Include required headers in iommu.h and iopgtable.h
Both headers make use of externally defined structures, types or
functions. Include the appropriate headers.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/plat-omap/include/plat/iommu.h |4
arch/arm/plat-omap/include/plat/iopgtable.h |2 ++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index e58d571..6661eec 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -13,6 +13,10 @@
#ifndef __MACH_IOMMU_H
#define __MACH_IOMMU_H
+#include linux/device.h
+#include linux/mutex.h
+#include linux/spinlock.h
+
struct iotlb_entry {
u32 da;
u32 pa;
diff --git a/arch/arm/plat-omap/include/plat/iopgtable.h
b/arch/arm/plat-omap/include/plat/iopgtable.h
index 66a8139..ebb6e21 100644
--- a/arch/arm/plat-omap/include/plat/iopgtable.h
+++ b/arch/arm/plat-omap/include/plat/iopgtable.h
@@ -13,6 +13,8 @@
#ifndef __PLAT_OMAP_IOMMU_H
#define __PLAT_OMAP_IOMMU_H
+#include linux/string.h
+
/*
* L2 table address mask and size definitions.
*/
--
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 13/15] tidspbridge: Simplify pte_update and mem_map_vmalloc functions
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 148 +++-
1 files changed, 68 insertions(+), 80 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 7f1372e..7d074fc 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1079,47 +1079,46 @@ static int pte_set(struct pg_table_attrs *pt, u32 pa,
u32 va,
return status;
}
+static unsigned max_alignment(u32 addr, u32 size)
+{
+ unsigned pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(pagesize); i++) {
+ if ((addr (pagesize[i] - 1)) == 0 size = pagesize[i])
+ return pagesize[i];
+ }
+
+ return 0;
+}
+
/*
* pte_update
* This function calculates the optimum page-aligned addresses and sizes
* Caller must pass page-aligned values
*/
-static int pte_update(struct bridge_dev_context *dev_ctxt, u32 pa,
-u32 va, u32 size,
-struct hw_mmu_map_attrs_t *map_attrs)
+static int pte_update(struct bridge_dev_context *dev_ctxt, u32 pa, u32 va,
+ u32 size, struct hw_mmu_map_attrs_t *map_attrs)
{
- u32 i;
- u32 all_bits;
- u32 pa_curr = pa;
- u32 va_curr = va;
- u32 num_bytes = size;
- int status = 0;
- u32 page_size[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K };
-
- while (num_bytes !status) {
+ while (size) {
/* To find the max. page size with which both PA VA are
* aligned */
- all_bits = pa_curr | va_curr;
+ unsigned int ent_sz = max_alignment(va | pa, size);
+ int ret;
- for (i = 0; i 4; i++) {
- if ((num_bytes = page_size[i]) ((all_bits
-(page_size[i] -
- 1)) == 0)) {
- status =
- pte_set(dev_ctxt-pt_attrs, pa_curr,
- va_curr, page_size[i], map_attrs);
- pa_curr += page_size[i];
- va_curr += page_size[i];
- num_bytes -= page_size[i];
- /* Don't try smaller sizes. Hopefully we have
-* reached an address aligned to a bigger page
-* size */
- break;
- }
- }
+ if (WARN_ON(ent_sz == 0))
+ return -EINVAL;
+
+ ret = pte_set(dev_ctxt-pt_attrs, pa, va, ent_sz, map_attrs);
+ if (ret 0)
+ return ret;
+
+ pa += ent_sz;
+ va += ent_sz;
+ size -= ent_sz;
}
- return status;
+ return 0;
}
/*
@@ -1167,70 +1166,58 @@ static inline void flush_all(struct bridge_dev_context
*dev_ctxt)
}
/* Memory map kernel VA -- memory allocated with vmalloc */
-static int mem_map_vmalloc(struct bridge_dev_context *dev_ctxt,
- u32 mpu_addr, u32 virt_addr, u32 num_bytes,
+static int mem_map_vmalloc(struct bridge_dev_context *dev_ctxt, u32 mpu_addr,
+ u32 virt_addr, size_t num_bytes,
struct hw_mmu_map_attrs_t *hw_attrs)
{
- int status = 0;
- struct page *page[1];
- u32 i;
- u32 pa_curr;
- u32 pa_next;
- u32 va_curr;
- u32 size_curr;
- u32 num_pages;
- u32 pa;
- u32 num_of4k_pages;
- u32 temp = 0;
+ struct page *page_next;
+ int ret;
/*
* Do Kernel va to pa translation.
* Combine physically contiguous regions to reduce TLBs.
* Pass the translated pa to pte_update.
*/
- num_pages = num_bytes / PAGE_SIZE; /* PAGE_SIZE = OS page size */
- i = 0;
- va_curr = mpu_addr;
- page[0] = vmalloc_to_page((void *)va_curr);
- pa_next = page_to_phys(page[0]);
- while (!status (i num_pages)) {
- /*
-* Reuse pa_next from the previous iteraion to avoid
-* an extra va2pa call
-*/
- pa_curr = pa_next;
- size_curr = PAGE_SIZE;
+ page_next = vmalloc_to_page((void *)mpu_addr);
+
+ while (num_bytes 0) {
+ struct page *page = page_next;
+ size_t chunk_size = PAGE_SIZE;
+ u32 num_pages = 1;
+
+ get_page(page);
+
/*
-*
[PATCH v2 12/15] tidspbridge: Use constants defined in IOMMU platform headers
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/io_sm.c |7 +-
drivers/staging/tidspbridge/core/tiomap3430.c | 38 +++-
drivers/staging/tidspbridge/core/tiomap_io.c |2 +-
drivers/staging/tidspbridge/core/ue_deh.c | 13 +--
drivers/staging/tidspbridge/hw/hw_defs.h |6 --
drivers/staging/tidspbridge/hw/hw_mmu.c | 121 ++---
drivers/staging/tidspbridge/hw/hw_mmu.h | 19 +++--
7 files changed, 83 insertions(+), 123 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/io_sm.c
b/drivers/staging/tidspbridge/core/io_sm.c
index 480a384..78e6fe3 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -361,10 +361,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
u32 pa_curr, va_curr, da_curr;
u32 bytes;
u32 all_bits = 0;
- u32 page_size[] = {
- HW_PAGE_SIZE16MB, HW_PAGE_SIZE1MB,
- HW_PAGE_SIZE64KB, HW_PAGE_SIZE4KB
- };
+ u32 page_size[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K };
u32 map_attrs = DSP_MAPLITTLEENDIAN | DSP_MAPPHYSICALADDR |
DSP_MAPELEMSIZE32 | DSP_MAPDONOTLOCK;
@@ -616,7 +613,7 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
status = hio_mgr-intf_fxns-brd_mem_map(dc,
l4_peripheral_table[i].phys_addr,
l4_peripheral_table[i].dsp_virt_addr,
- HW_PAGE_SIZE4KB, map_attrs, NULL);
+ SZ_4K, map_attrs, NULL);
if (status)
goto free_eproc;
i++;
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 5cd85dc..7f1372e 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -62,10 +62,6 @@
#define TIHELEN_ACKTIMEOUT 1
-#define MMU_SECTION_ADDR_MASK0xFFF0
-#define MMU_SSECTION_ADDR_MASK 0xFF00
-#define MMU_LARGE_PAGE_MASK 0x
-#define MMU_SMALL_PAGE_MASK 0xF000
#define OMAP3_IVA2_BOOTADDR_MASK 0xFC00
#define PAGES_II_LVL_TABLE 512
#define PHYS_TO_PAGE(phys) pfn_to_page((phys) PAGE_SHIFT)
@@ -486,8 +482,7 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
/* Let DSP go */
dev_dbg(bridge, %s Unreset\n, __func__);
/* Enable DSP MMU Interrupts */
- hw_mmu_event_enable(resources-dmmu_base,
- HW_MMU_ALL_INTERRUPTS);
+ hw_mmu_event_enable(resources-dmmu_base, OMAP_IOMMU_ERR_ALL);
/* release the RST1, DSP starts executing now .. */
(*pdata-dsp_prm_rmw_bits)(OMAP3430_RST1_IVA2_MASK, 0,
OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
@@ -1013,7 +1008,7 @@ static int pte_set(struct pg_table_attrs *pt, u32 pa, u32
va,
l1_base_va = pt-l1_base_va;
pg_tbl_va = l1_base_va;
- if ((size == HW_PAGE_SIZE64KB) || (size == HW_PAGE_SIZE4KB)) {
+ if (size == SZ_64K || size == SZ_4K) {
/* Find whether the L1 PTE points to a valid L2 PT */
pte_addr_l1 = hw_mmu_pte_addr_l1(l1_base_va, va);
if (pte_addr_l1 = (pt-l1_base_va + pt-l1_size)) {
@@ -1061,7 +1056,7 @@ static int pte_set(struct pg_table_attrs *pt, u32 pa, u32
va,
}
if (!status) {
pg_tbl_va = l2_base_va;
- if (size == HW_PAGE_SIZE64KB)
+ if (size == SZ_64K)
pt-pg_info[l2_page_num].num_entries += 16;
else
pt-pg_info[l2_page_num].num_entries++;
@@ -1099,9 +1094,7 @@ static int pte_update(struct bridge_dev_context
*dev_ctxt, u32 pa,
u32 va_curr = va;
u32 num_bytes = size;
int status = 0;
- u32 page_size[] = { HW_PAGE_SIZE16MB, HW_PAGE_SIZE1MB,
- HW_PAGE_SIZE64KB, HW_PAGE_SIZE4KB
- };
+ u32 page_size[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K };
while (num_bytes !status) {
/* To find the max. page size with which both PA VA are
@@ -1228,10 +1221,10 @@ static int mem_map_vmalloc(struct bridge_dev_context
*dev_ctxt,
break;
}
pa = pa_curr;
- num_of4k_pages = size_curr / HW_PAGE_SIZE4KB;
+ num_of4k_pages = size_curr / SZ_4K;
while (temp++ num_of4k_pages) {
get_page(PHYS_TO_PAGE(pa));
- pa += HW_PAGE_SIZE4KB;
+ pa += SZ_4K;
}
status =
[PATCH v2 14/15] tidspbridge: Use correct types to describe physical, MPU, DSP addresses
Physical addresses: name them 'pa' and use the phys_addr_t type
MPU virtual addresses: name them 'va' and use the unsigned long type
DSP virtual addresses: name them 'da' and use the u32 type
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 180 ++--
drivers/staging/tidspbridge/hw/hw_mmu.c| 74 -
drivers/staging/tidspbridge/hw/hw_mmu.h| 24 +--
.../tidspbridge/include/dspbridge/dspdefs.h| 24 ++--
4 files changed, 140 insertions(+), 162 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 7d074fc..c9d240c 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -988,8 +988,8 @@ static int bridge_brd_mem_write(struct bridge_dev_context
*dev_ctxt,
* This function calculates PTE address (MPU virtual) to be updated
* It also manages the L2 page tables
*/
-static int pte_set(struct pg_table_attrs *pt, u32 pa, u32 va,
- u32 size, struct hw_mmu_map_attrs_t *attrs)
+static int pte_set(struct pg_table_attrs *pt, phys_addr_t pa, u32 da,
+ size_t size, struct hw_mmu_map_attrs_t *attrs)
{
u32 i;
u32 pte_val;
@@ -1010,7 +1010,7 @@ static int pte_set(struct pg_table_attrs *pt, u32 pa, u32
va,
pg_tbl_va = l1_base_va;
if (size == SZ_64K || size == SZ_4K) {
/* Find whether the L1 PTE points to a valid L2 PT */
- pte_addr_l1 = hw_mmu_pte_addr_l1(l1_base_va, va);
+ pte_addr_l1 = hw_mmu_pte_addr_l1(l1_base_va, da);
if (pte_addr_l1 = (pt-l1_base_va + pt-l1_size)) {
pte_val = *(u32 *) pte_addr_l1;
pte_size = hw_mmu_pte_size_l1(pte_val);
@@ -1043,7 +1043,7 @@ static int pte_set(struct pg_table_attrs *pt, u32 pa, u32
va,
/* Endianness attributes are ignored for
* HW_MMU_COARSE_PAGE_SIZE */
status =
- hw_mmu_pte_set(l1_base_va, l2_base_pa, va,
+ hw_mmu_pte_set(l1_base_va, l2_base_pa, da,
HW_MMU_COARSE_PAGE_SIZE,
attrs);
} else {
@@ -1068,18 +1068,18 @@ static int pte_set(struct pg_table_attrs *pt, u32 pa,
u32 va,
spin_unlock(pt-pg_lock);
}
if (!status) {
- dev_dbg(bridge, PTE: pg_tbl_va %x, pa %x, va %x, size %x\n,
- pg_tbl_va, pa, va, size);
+ dev_dbg(bridge, PTE: pg_tbl_va %x, pa %x, da %x, size %x\n,
+ pg_tbl_va, pa, da, size);
dev_dbg(bridge, PTE: endianism %x, element_size %x,
mixed_size %x\n, attrs-endianism,
attrs-element_size, attrs-mixed_size);
- status = hw_mmu_pte_set(pg_tbl_va, pa, va, size, attrs);
+ status = hw_mmu_pte_set(pg_tbl_va, pa, da, size, attrs);
}
return status;
}
-static unsigned max_alignment(u32 addr, u32 size)
+static unsigned max_alignment(u32 addr, size_t size)
{
unsigned pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
unsigned int i;
@@ -1097,24 +1097,24 @@ static unsigned max_alignment(u32 addr, u32 size)
* This function calculates the optimum page-aligned addresses and sizes
* Caller must pass page-aligned values
*/
-static int pte_update(struct bridge_dev_context *dev_ctxt, u32 pa, u32 va,
- u32 size, struct hw_mmu_map_attrs_t *map_attrs)
+static int pte_update(struct bridge_dev_context *dev_ctxt, phys_addr_t pa, u32
da,
+ size_t size, struct hw_mmu_map_attrs_t *map_attrs)
{
while (size) {
/* To find the max. page size with which both PA VA are
* aligned */
- unsigned int ent_sz = max_alignment(va | pa, size);
+ unsigned int ent_sz = max_alignment(da | pa, size);
int ret;
if (WARN_ON(ent_sz == 0))
return -EINVAL;
- ret = pte_set(dev_ctxt-pt_attrs, pa, va, ent_sz, map_attrs);
+ ret = pte_set(dev_ctxt-pt_attrs, pa, da, ent_sz, map_attrs);
if (ret 0)
return ret;
pa += ent_sz;
- va += ent_sz;
+ da += ent_sz;
size -= ent_sz;
}
@@ -1127,26 +1127,26 @@ static int pte_update(struct bridge_dev_context
*dev_ctxt, u32 pa, u32 va,
* This function walks through the page tables to convert a userland
* virtual address to physical address
*/
[PATCH v2 15/15] tidspbridge: Replace hw_mmu_map_attrs_t structure with a prot bitfield
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 83 ---
drivers/staging/tidspbridge/core/ue_deh.c |8 +--
drivers/staging/tidspbridge/hw/hw_defs.h | 16
drivers/staging/tidspbridge/hw/hw_mmu.c| 80 ---
drivers/staging/tidspbridge/hw/hw_mmu.h| 20 +
.../tidspbridge/include/dspbridge/dspioctl.h | 25 ++
6 files changed, 82 insertions(+), 150 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index c9d240c..669b126 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -357,11 +357,9 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
for (entry_ndx = 0; entry_ndx BRDIOCTL_NUMOFMMUTLB;
entry_ndx++) {
struct bridge_ioctl_extproc *e =
dev_ctxt-atlb_entry[entry_ndx];
- struct hw_mmu_map_attrs_t map_attrs = {
- .endianism = e-endianism,
- .element_size = e-elem_size,
- .mixed_size = e-mixed_mode,
- };
+ int prot = (e-endianism MMU_RAM_ENDIAN_SHIFT)
+| (e-elem_size MMU_RAM_ELSZ_SHIFT)
+| (e-mixed_mode MMU_RAM_MIXED_SHIFT);
if (!e-gpp_pa || !e-dsp_va)
continue;
@@ -378,7 +376,7 @@ static int bridge_brd_start(struct bridge_dev_context
*dev_ctxt,
e-dsp_va,
e-size,
itmp_entry_ndx,
- map_attrs, 1, 1);
+ prot, 1, 1);
itmp_entry_ndx++;
}
@@ -989,7 +987,7 @@ static int bridge_brd_mem_write(struct bridge_dev_context
*dev_ctxt,
* It also manages the L2 page tables
*/
static int pte_set(struct pg_table_attrs *pt, phys_addr_t pa, u32 da,
- size_t size, struct hw_mmu_map_attrs_t *attrs)
+ size_t size, int prot)
{
u32 i;
u32 pte_val;
@@ -1045,7 +1043,7 @@ static int pte_set(struct pg_table_attrs *pt, phys_addr_t
pa, u32 da,
status =
hw_mmu_pte_set(l1_base_va, l2_base_pa, da,
HW_MMU_COARSE_PAGE_SIZE,
- attrs);
+ prot);
} else {
status = -ENOMEM;
}
@@ -1070,10 +1068,8 @@ static int pte_set(struct pg_table_attrs *pt,
phys_addr_t pa, u32 da,
if (!status) {
dev_dbg(bridge, PTE: pg_tbl_va %x, pa %x, da %x, size %x\n,
pg_tbl_va, pa, da, size);
- dev_dbg(bridge, PTE: endianism %x, element_size %x,
- mixed_size %x\n, attrs-endianism,
- attrs-element_size, attrs-mixed_size);
- status = hw_mmu_pte_set(pg_tbl_va, pa, da, size, attrs);
+ dev_dbg(bridge, PTE: prot %x, prot);
+ status = hw_mmu_pte_set(pg_tbl_va, pa, da, size, prot);
}
return status;
@@ -1098,7 +1094,7 @@ static unsigned max_alignment(u32 addr, size_t size)
* Caller must pass page-aligned values
*/
static int pte_update(struct bridge_dev_context *dev_ctxt, phys_addr_t pa, u32
da,
- size_t size, struct hw_mmu_map_attrs_t *map_attrs)
+ size_t size, int prot)
{
while (size) {
/* To find the max. page size with which both PA VA are
@@ -1109,7 +1105,7 @@ static int pte_update(struct bridge_dev_context
*dev_ctxt, phys_addr_t pa, u32 d
if (WARN_ON(ent_sz == 0))
return -EINVAL;
- ret = pte_set(dev_ctxt-pt_attrs, pa, da, ent_sz, map_attrs);
+ ret = pte_set(dev_ctxt-pt_attrs, pa, da, ent_sz, prot);
if (ret 0)
return ret;
@@ -1167,8 +1163,7 @@ static inline void flush_all(struct bridge_dev_context
*dev_ctxt)
/* Memory map kernel VA -- memory allocated with vmalloc */
static int mem_map_vmalloc(struct bridge_dev_context *dev_ctxt,
- unsigned long va, u32 da, size_t bytes,
- struct hw_mmu_map_attrs_t *hw_attrs)
+ unsigned long va, u32 da, size_t bytes, int prot)
{
struct page *page_next;
int ret;
@@ -1208,7 +1203,7 @@ static int
[PATCH v2 08/15] tidspbridge: Fix VM_PFNMAP mapping
VMAs marked with the VM_PFNMAP flag have no struct page associated with
the memory PFNs. Don't call get_page()/put_page() on the pages
supposedly associated with the PFNs.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 30 +++--
.../staging/tidspbridge/include/dspbridge/drv.h|1 +
.../tidspbridge/include/dspbridge/dspdefs.h|9 +-
drivers/staging/tidspbridge/rmgr/proc.c| 119 ++--
4 files changed, 84 insertions(+), 75 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 2c5be89..cc538ea 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1262,7 +1262,8 @@ static void bad_page_dump(u32 pa, struct page *pg)
}
/* Release all pages associated with a physical addresses range. */
-static void bridge_release_pages(u32 paddr, u32 pte_size, u32 num_bytes)
+static void bridge_release_pages(u32 paddr, u32 pte_size, u32 num_bytes,
+struct dmm_map_object *map_obj)
{
struct page *pg;
u32 num_pages;
@@ -1270,7 +1271,8 @@ static void bridge_release_pages(u32 paddr, u32 pte_size,
u32 num_bytes)
num_pages = pte_size / PAGE_SIZE;
for (; num_pages 0; --num_pages, paddr += HW_PAGE_SIZE4KB) {
- if (!pfn_valid(__phys_to_pfn(paddr)))
+ if (!pfn_valid(__phys_to_pfn(paddr)) ||
+ (map_obj map_obj-vm_flags VM_PFNMAP))
continue;
pg = PHYS_TO_PAGE(paddr);
@@ -1295,7 +1297,8 @@ static void bridge_release_pages(u32 paddr, u32 pte_size,
u32 num_bytes)
* we clear consecutive PTEs until we unmap all the bytes
*/
static int bridge_brd_mem_un_map(struct bridge_dev_context *dev_ctxt,
-u32 virt_addr, u32 num_bytes)
+u32 virt_addr, u32 num_bytes,
+struct dmm_map_object *map_obj)
{
u32 l1_base_va;
u32 l2_base_va;
@@ -1369,7 +1372,7 @@ static int bridge_brd_mem_un_map(struct
bridge_dev_context *dev_ctxt,
}
bridge_release_pages(pte_val ~(pte_size - 1),
pte_size,
-num_bytes);
+num_bytes, map_obj);
if (hw_mmu_pte_clear(pte_addr_l2, virt_addr, pte_size))
{
status = -EPERM;
@@ -1413,7 +1416,7 @@ skip_coarse_page:
}
bridge_release_pages(pte_val ~(pte_size - 1), pte_size,
-num_bytes);
+num_bytes, map_obj);
if (!hw_mmu_pte_clear(l1_base_va, virt_addr, pte_size)) {
status = 0;
@@ -1448,7 +1451,7 @@ EXIT_LOOP:
*/
static int bridge_brd_mem_map(struct bridge_dev_context *dev_ctxt,
u32 mpu_addr, u32 virt_addr, u32 num_bytes,
- u32 map_attr, struct page **mapped_pages)
+ u32 map_attr, struct dmm_map_object *map_obj)
{
u32 attrs;
int status = 0;
@@ -1559,6 +1562,9 @@ static int bridge_brd_mem_map(struct bridge_dev_context
*dev_ctxt,
goto func_cont;
}
+ if (map_obj)
+ map_obj-vm_flags = vma-vm_flags;
+
if (vma-vm_flags VM_IO) {
num_usr_pgs = num_bytes / PG_SIZE4K;
@@ -1571,7 +1577,8 @@ static int bridge_brd_mem_map(struct bridge_dev_context
*dev_ctxt,
address is invalid\n);
break;
}
- if (pfn_valid(__phys_to_pfn(pa))) {
+ if (!(vma-vm_flags VM_PFNMAP)
+ pfn_valid(__phys_to_pfn(pa))) {
pg = PHYS_TO_PAGE(pa);
get_page(pg);
if (page_count(pg) 1) {
@@ -1610,8 +1617,8 @@ static int bridge_brd_mem_map(struct bridge_dev_context
*dev_ctxt,
if (status)
break;
- if (mapped_pages)
- mapped_pages[pg_i] = pg;
+ if (map_obj)
+ map_obj-pages[pg_i] = pg;
virt_addr += HW_PAGE_SIZE4KB;
mpu_addr += HW_PAGE_SIZE4KB;
@@ -1635,10 +1642,9 @@ func_cont:
* Roll out the mapped pages incase it failed in middle of
* mapping
*/
- if (pg_i) {
+ if (pg_i)
Re: [RFC PATCH v2 1/5] ARM: mm: implement LoUIS API for cache maintenance ops
On Tue, Sep 18, 2012 at 07:12:52PM +0100, Nicolas Pitre wrote: On Tue, 18 Sep 2012, Lorenzo Pieralisi wrote: ARM v7 architecture introduced the concept of cache levels and related control registers. New processors like A7 and A15 embed an L2 unified cache controller that becomes part of the cache level hierarchy. Some operations in the kernel like cpu_suspend and __cpu_disable do not require a flush of the entire cache hierarchy to DRAM but just the cache levels belonging to the Level of Unification Inner Shareable (LoUIS), which in most of ARM v7 systems correspond to L1. The current cache flushing API used in cpu_suspend and __cpu_disable, flush_cache_all(), ends up flushing the whole cache hierarchy since for v7 it cleans and invalidates all cache levels up to Level of Coherency (LoC) which cripples system performance when used in hot paths like hotplug and cpuidle. Therefore a new kernel cache maintenance API must be added to cope with latest ARM system requirements. This patch adds flush_cache_louis() to the ARM kernel cache maintenance API. This function cleans and invalidates all data cache levels up to the Level of Unification Inner Shareable (LoUIS) and invalidates the instruction cache for processors that support it ( v7). This patch also creates an alias of the cache LoUIS function to flush_kern_all for all processor versions prior to v7, so that the current cache flushing behaviour is unchanged for those processors. v7 cache maintenance code implements a cache LoUIS function that cleans and invalidates the D-cache up to LoUIS and invalidates the I-cache, according to the new API. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com Reviewed-by: Nicolas Pitre n...@linaro.org Thanks a lot for reviewing the series. Lorenzo -- 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 v7 00/11] OMAP-GPMC: generic time calc, prepare for driver
Hi, This version - v7 as compared to previous version, takes care of rounding issues due to the usage of nanoseconds in generic timing routine. All calculations are now in picoseconds. Once all timings are calculated it is converted to nanoseconds so that calculated timing values are compatible with existing custom timing routines (this will help in reverting back to custom routines easily in case of any issues). And documentation has been added on gpmc timings. Also redundant rounding of nand timings has been removed as part of this series. ** Abstract: This series provides a generic gpmc timing calculation routine. There were three peripherals (OneNAND, tusb6010, smc91x) using custom timing calculations, they are migrated to use the generic timing calculation. Such a generic routine would help create a driver out of gpmc platform code, which would be peripheral agnostic and thus lead to DT finally. Input to generic timing calculation routine would be gpmc peripheral timings, output - translated timings that gpmc can understand. Later, to DT'ify, gpmc peripheral timings could be passed through DT. Input timings that has been used here are selected such that it represents those that are present in peripheral timing datasheets. Also this series contains minor cleanups that were low hanging fruits came across upon implementing generic timing routine. One such is credited to Jon Hunter, relevant patch is 1/2 of his series @ http://marc.info/?l=linux-omapm=134090910321284w=2 ** Proposed generic routine has been tested on OneNAND (async) on OMAP3EVM rev C (as mainline does not have the OneNAND support for this, local patch were used to test). For other cases of custom timing calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing calculation routine was verified by simulating on OMAP3EVM. This series is available @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-prep-v7 and is based on linux-next (next-20120918) Regards Afzal v7: 1. Use picoseconds throughout generic timing routine to prevent rounding error. 2. Documentation on gpmc timings 3. Remove redundant rounding of nand timings (a new patch) v6: 1. Generic timing calculation, move existing users of custom calculation to use the new generic one 2. Set OneNAND part to async mode before gpmc configuration 3. Move extra delay time user handling to proper patch (3/10 - 2/10) 4. Modify nand init for OMAP3EVM too as support got added v5: Use flags for sync_read/write, hv, vhf v4: Reorganize OneNAND set_sync/async functions in a better way v3: 1. Refactor OneNAND set_sync/async functions to separate out timing and configurations 2. Handle bool type timings too 3. Swap patches 2 3 due to dependency of OneNAND change on newly added bool type timings v2: 1. Make use of timing api for setting clock activation time, and remove direct writing to register for clock activation. 2. Move ensuring that async mode in OneNAND has been setup from set_sync to setup function, improve commit message Afzal Mohammed (10): ARM: OMAP2+: nand: unify init functions ARM: OMAP2+: nand: remove redundant rounding ARM: OMAP2+: gpmc: handle additional timings ARM: OMAP2+: onenand: refactor for clarity ARM: OMAP2+: gpmc: find features by ip rev check ARM: OMAP2+: gpmc: remove cs# in sync clk div calc ARM: OMAP2+: gpmc: generic timing calculation ARM: OMAP2+: onenand: generic timing calculation ARM: OMAP2+: smc91x: generic timing calculation ARM: OMAP2+: tusb6010: generic timing calculation Jon Hunter (1): ARM: OMAP2+: GPMC: Remove unused OneNAND get_freq() platform function Documentation/bus-devices/ti-gpmc.txt | 77 ++ arch/arm/mach-omap2/board-devkit8000.c | 8 +- arch/arm/mach-omap2/board-flash.c | 45 ++-- arch/arm/mach-omap2/board-flash.h | 6 +- arch/arm/mach-omap2/board-igep0020.c | 2 +- arch/arm/mach-omap2/board-ldp.c| 4 +- arch/arm/mach-omap2/board-omap3beagle.c| 8 +- arch/arm/mach-omap2/board-omap3evm.c | 8 +- arch/arm/mach-omap2/board-omap3touchbook.c | 8 +- arch/arm/mach-omap2/board-overo.c | 7 +- arch/arm/mach-omap2/board-zoom.c | 5 +- arch/arm/mach-omap2/common-board-devices.c | 45 arch/arm/mach-omap2/common-board-devices.h | 1 - arch/arm/mach-omap2/gpmc-nand.c| 30 +-- arch/arm/mach-omap2/gpmc-onenand.c | 334 +++-- arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++-- arch/arm/mach-omap2/gpmc.c | 383 - arch/arm/mach-omap2/usb-tusb6010.c | 181 --
[PATCH v7 01/11] ARM: OMAP2+: nand: unify init functions
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on bootloader setting. As CS# is hardwired for a given
board, acquiring gpmc CS# has been removed, and updated with
the value on board.
NAND CS# used in beagle board omap3evm was found to be CS0.
Thomas Weber thomas.weber.li...@googlemail.com reported
that value of devkit8000 to be CS0. Overo board was found
to be using CS0 based on u-boot, while google grep says
omap3touchbook too has CS0.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
v6: Modify nand init for OMAP3EVM too as support got added
arch/arm/mach-omap2/board-devkit8000.c | 8 --
arch/arm/mach-omap2/board-flash.c | 45 +++---
arch/arm/mach-omap2/board-flash.h | 6 ++--
arch/arm/mach-omap2/board-igep0020.c | 2 +-
arch/arm/mach-omap2/board-ldp.c| 4 +--
arch/arm/mach-omap2/board-omap3beagle.c| 8 --
arch/arm/mach-omap2/board-omap3evm.c | 8 --
arch/arm/mach-omap2/board-omap3touchbook.c | 8 --
arch/arm/mach-omap2/board-overo.c | 7 +++--
arch/arm/mach-omap2/board-zoom.c | 5 ++--
arch/arm/mach-omap2/common-board-devices.c | 45 --
arch/arm/mach-omap2/common-board-devices.h | 1 -
12 files changed, 62 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 3435cc5..59c93f9 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -55,8 +55,11 @@
#include sdram-micron-mt46h32m32lf-6.h
#include mux.h
#include hsmmc.h
+#include board-flash.h
#include common-board-devices.h
+#defineNAND_CS 0
+
#define OMAP_DM9000_GPIO_IRQ 25
#define OMAP3_DEVKIT_TS_GPIO 27
@@ -621,8 +624,9 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
-ARRAY_SIZE(devkit8000_nand_partitions));
+ board_nand_init(devkit8000_nand_partitions,
+ ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
+ NAND_BUSWIDTH_16, NULL);
omap_twl4030_audio_init(omap3beagle);
/* Ensure SDRC pins are mux'd for self-refresh */
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 9017813..a078d89 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -104,41 +104,41 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
defined(CONFIG_MTD_NAND_OMAP2_MODULE)
/* Note that all values in this struct are in nanoseconds */
-static struct gpmc_timings nand_timings = {
+struct gpmc_timings nand_default_timings[1] = {
+ {
+ .sync_clk = 0,
- .sync_clk = 0,
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
- .cs_on = 0,
- .cs_rd_off = 36,
- .cs_wr_off = 36,
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
- .adv_on = 6,
- .adv_rd_off = 24,
- .adv_wr_off = 36,
+ .we_off = 30,
+ .oe_off = 48,
- .we_off = 30,
- .oe_off = 48,
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
- .access = 54,
- .rd_cycle = 72,
- .wr_cycle = 72,
-
- .wr_access = 30,
- .wr_data_mux_bus = 0,
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+ },
};
-static struct omap_nand_platform_data board_nand_data = {
- .gpmc_t = nand_timings,
-};
+static struct omap_nand_platform_data board_nand_data;
void
-__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+ int nand_type, struct gpmc_timings *gpmc_t)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+ board_nand_data.gpmc_t = gpmc_t;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
gpmc_nand_init(board_nand_data);
@@ -238,5 +238,6 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err(NAND: Unable to find configuration in GPMC\n);
else
[PATCH v7 02/11] ARM: OMAP2+: nand: remove redundant rounding
gpmc_cs_set_timings() calculate ticks to be programmed by
rounding time in ns to next tick value. Hence remove
redundant rounding of nanosecond timing.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 9e9f47a..cd1dc41 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -50,31 +50,27 @@ static int omap2_nand_gpmc_retime(struct
omap_nand_platform_data *gpmc_nand_data
memset(t, 0, sizeof(t));
t.sync_clk = gpmc_nand_data-gpmc_t-sync_clk;
- t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_on);
- t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-adv_on);
+ t.cs_on = gpmc_nand_data-gpmc_t-cs_on;
+ t.adv_on = gpmc_nand_data-gpmc_t-adv_on;
/* Read */
- t.adv_rd_off = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-adv_rd_off);
+ t.adv_rd_off = gpmc_nand_data-gpmc_t-adv_rd_off;
t.oe_on = t.adv_on;
- t.access = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-access);
- t.oe_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-oe_off);
- t.cs_rd_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_rd_off);
- t.rd_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-rd_cycle);
+ t.access = gpmc_nand_data-gpmc_t-access;
+ t.oe_off = gpmc_nand_data-gpmc_t-oe_off;
+ t.cs_rd_off = gpmc_nand_data-gpmc_t-cs_rd_off;
+ t.rd_cycle = gpmc_nand_data-gpmc_t-rd_cycle;
/* Write */
- t.adv_wr_off = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-adv_wr_off);
+ t.adv_wr_off = gpmc_nand_data-gpmc_t-adv_wr_off;
t.we_on = t.oe_on;
if (cpu_is_omap34xx()) {
- t.wr_data_mux_bus = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-wr_data_mux_bus);
- t.wr_access = gpmc_round_ns_to_ticks(
- gpmc_nand_data-gpmc_t-wr_access);
+ t.wr_data_mux_bus = gpmc_nand_data-gpmc_t-wr_data_mux_bus;
+ t.wr_access = gpmc_nand_data-gpmc_t-wr_access;
}
- t.we_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-we_off);
- t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
- t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
+ t.we_off = gpmc_nand_data-gpmc_t-we_off;
+ t.cs_wr_off = gpmc_nand_data-gpmc_t-cs_wr_off;
+ t.wr_cycle = gpmc_nand_data-gpmc_t-wr_cycle;
/* Configure GPMC */
if (gpmc_nand_data-devsize == NAND_BUSWIDTH_16)
--
1.7.12
--
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 v7 03/11] ARM: OMAP2+: gpmc: handle additional timings
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader. Also configure bool type
timings like extradelay.
This needed change to the existing users that were configuring
clk activation time and extra delay by directly writing to
registers. Thanks to Tony for making me aware of users of clk
activation and being kind enough to test the modified one.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v6: Move extra delay time user handling to present one from 3/10
v3: Handle bool type timings too
v2: Make use of timing api for setting clock activation time,
and remove direct writing to register for clock activation
arch/arm/mach-omap2/gpmc-onenand.c | 28 +---
arch/arm/mach-omap2/gpmc.c | 48 ++
arch/arm/mach-omap2/usb-tusb6010.c | 3 ++-
arch/arm/plat-omap/include/plat/gpmc.h | 19 ++
4 files changed, 75 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index b66fb8e..379d126 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -284,27 +284,10 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
sync_read, sync_write, hf, vhf);
if (div == 1) {
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
- reg |= (1 7);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, reg);
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG3);
- reg |= (1 7);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG3, reg);
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG4);
- reg |= (1 7);
- reg |= (1 23);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG4, reg);
- } else {
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
- reg = ~(1 7);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, reg);
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG3);
- reg = ~(1 7);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG3, reg);
- reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG4);
- reg = ~(1 7);
- reg = ~(1 23);
- gpmc_cs_write_reg(cs, GPMC_CS_CONFIG4, reg);
+ t.bool_timings.cs_extra_delay = true;
+ t.bool_timings.adv_extra_delay = true;
+ t.bool_timings.oe_extra_delay = true;
+ t.bool_timings.we_extra_delay = true;
}
/* Set synchronous read timings */
@@ -329,6 +312,8 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
t.rd_cycle = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div +
ticks_cez);
+ t.clk_activation = fclk_offset_ns;
+
/* Write */
if (sync_write) {
t.adv_wr_off = t.adv_rd_off;
@@ -362,7 +347,6 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
(sync_read ? GPMC_CONFIG1_READTYPE_SYNC : 0) |
(sync_write ? GPMC_CONFIG1_WRITEMULTIPLE_SUPP : 0) |
(sync_write ? GPMC_CONFIG1_WRITETYPE_SYNC : 0) |
- GPMC_CONFIG1_CLKACTIVATIONTIME(fclk_offset) |
GPMC_CONFIG1_PAGE_LEN(2) |
(cpu_is_omap34xx() ? 0 :
(GPMC_CONFIG1_WAIT_READ_MON |
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 72428bd..a481816 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -69,6 +69,13 @@
#define GPMC_ECC_CTRL_ECCREG8 0x008
#define GPMC_ECC_CTRL_ECCREG9 0x009
+#defineGPMC_CONFIG2_CSEXTRADELAY BIT(7)
+#defineGPMC_CONFIG3_ADVEXTRADELAY BIT(7)
+#defineGPMC_CONFIG4_OEEXTRADELAY BIT(7)
+#defineGPMC_CONFIG4_WEEXTRADELAY BIT(23)
+#defineGPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6)
+#defineGPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7)
+
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -225,6 +232,39 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
return ticks * gpmc_get_fclk_period() / 1000;
}
+static inline void gpmc_cs_modify_reg(int cs, int reg, u32 mask, bool value)
+{
+ u32 l;
+
+ l = gpmc_cs_read_reg(cs, reg);
+ if (value)
+ l |= mask;
+ else
+ l = ~mask;
+ gpmc_cs_write_reg(cs, reg, l);
+}
+
+static void gpmc_cs_bool_timings(int cs, const struct gpmc_bool_timings *p)
+{
+ gpmc_cs_modify_reg(cs, GPMC_CS_CONFIG1,
+
[PATCH v7 04/11] ARM: OMAP2+: onenand: refactor for clarity
Refactor set_async_mode set_sync_mode functions to
separate out timing calculation actual configuration
(GPMC OneNAND side).
Thanks to Jon for his suggestions.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
v6:
1. Set OneNAND part to async mode before gpmc configuration
2. Move extra delay time user handling away from this patch
(3/10 - 2/10)
v5: Use flags for sync_read/write, hv, vhf
v4: Reorganize OneNAND set_sync/async functions in a better way
v3: Refactor OneNAND set_sync/async functions to separate out
timing and configurations
v2: Move ensuring that async mode in OneNAND has been setup from
set_sync to setup function, improve commit message
arch/arm/mach-omap2/gpmc-onenand.c | 174 +++--
1 file changed, 109 insertions(+), 65 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 379d126..15908e8 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/mtd/onenand_regs.h
#include linux/io.h
+#include linux/err.h
#include asm/mach/flash.h
@@ -25,6 +26,14 @@
#defineONENAND_IO_SIZE SZ_128K
+#defineONENAND_FLAG_SYNCREAD (1 0)
+#defineONENAND_FLAG_SYNCWRITE (1 1)
+#defineONENAND_FLAG_HF (1 2)
+#defineONENAND_FLAG_VHF(1 3)
+
+static unsigned onenand_flags;
+static unsigned latency;
+
static struct omap_onenand_platform_data *gpmc_onenand_data;
static struct resource gpmc_onenand_resource = {
@@ -38,11 +47,9 @@ static struct platform_device gpmc_onenand_device = {
.resource = gpmc_onenand_resource,
};
-static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
+static struct gpmc_timings omap2_onenand_calc_async_timings(void)
{
struct gpmc_timings t;
- u32 reg;
- int err;
const int t_cer = 15;
const int t_avdp = 12;
@@ -55,11 +62,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem
*onenand_base)
const int t_wpl = 40;
const int t_wph = 30;
- /* Ensure sync read and sync write are disabled */
- reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
- reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
- writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
memset(t, 0, sizeof(t));
t.sync_clk = 0;
t.cs_on = 0;
@@ -86,25 +88,30 @@ static int omap2_onenand_set_async_mode(int cs, void
__iomem *onenand_base)
t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
+ return t;
+}
+
+static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
+{
/* Configure GPMC for asynchronous read */
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
GPMC_CONFIG1_DEVICESIZE_16 |
GPMC_CONFIG1_MUXADDDATA);
- err = gpmc_cs_set_timings(cs, t);
- if (err)
- return err;
+ return gpmc_cs_set_timings(cs, t);
+}
+
+static void omap2_onenand_set_async_mode(void __iomem *onenand_base)
+{
+ u32 reg;
/* Ensure sync read and sync write are disabled */
reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
reg = ~ONENAND_SYS_CFG1_SYNC_READ ~ONENAND_SYS_CFG1_SYNC_WRITE;
writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
- return 0;
}
-static void set_onenand_cfg(void __iomem *onenand_base, int latency,
- int sync_read, int sync_write, int hf, int vhf)
+static void set_onenand_cfg(void __iomem *onenand_base)
{
u32 reg;
@@ -112,19 +119,19 @@ static void set_onenand_cfg(void __iomem *onenand_base,
int latency,
reg = ~((0x7 ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 9));
reg |= (latency ONENAND_SYS_CFG1_BRL_SHIFT) |
ONENAND_SYS_CFG1_BL_16;
- if (sync_read)
+ if (onenand_flags ONENAND_FLAG_SYNCREAD)
reg |= ONENAND_SYS_CFG1_SYNC_READ;
else
reg = ~ONENAND_SYS_CFG1_SYNC_READ;
- if (sync_write)
+ if (onenand_flags ONENAND_FLAG_SYNCWRITE)
reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
else
reg = ~ONENAND_SYS_CFG1_SYNC_WRITE;
- if (hf)
+ if (onenand_flags ONENAND_FLAG_HF)
reg |= ONENAND_SYS_CFG1_HF;
else
reg = ~ONENAND_SYS_CFG1_HF;
- if (vhf)
+ if (onenand_flags ONENAND_FLAG_VHF)
reg |= ONENAND_SYS_CFG1_VHF;
else
reg = ~ONENAND_SYS_CFG1_VHF;
@@ -172,9 +179,9 @@ static int omap2_onenand_get_freq(struct
omap_onenand_platform_data *cfg,
return freq;
}
-static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
-
[PATCH v7 05/11] ARM: OMAP2+: GPMC: Remove unused OneNAND get_freq() platform function
From: Jon Hunter jon-hun...@ti.com
A platform function pointer for getting the frequency of a OneNAND device
was added so that a platform could specify a custom function for returning
the frequency and not just rely on the OneNAND version to determine the
frequency. However, this platform function pointer is not currently being
used and I am not sure if it ever has.
OneNAND devices are not so common these days and as far as I know not being
used with new devices. Therefore, it is most likely that this get_freq()
function pointer will not be used and so remove it.
Given that the get_freq() function pointer is not used, neither is the
clk_dep variable and so all references to it can also be removed.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c| 39 ---
arch/arm/plat-omap/include/plat/onenand.h | 8 ---
2 files changed, 5 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 15908e8..1e6fce6 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -139,21 +139,10 @@ static void set_onenand_cfg(void __iomem *onenand_base)
}
static int omap2_onenand_get_freq(struct omap_onenand_platform_data *cfg,
- void __iomem *onenand_base, bool *clk_dep)
+ void __iomem *onenand_base)
{
u16 ver = readw(onenand_base + ONENAND_REG_VERSION_ID);
- int freq = 0;
-
- if (cfg-get_freq) {
- struct onenand_freq_info fi;
-
- fi.maf_id = readw(onenand_base + ONENAND_REG_MANUFACTURER_ID);
- fi.dev_id = readw(onenand_base + ONENAND_REG_DEVICE_ID);
- fi.ver_id = ver;
- freq = cfg-get_freq(fi, clk_dep);
- if (freq)
- return freq;
- }
+ int freq;
switch ((ver 4) 0xf) {
case 0:
@@ -181,7 +170,7 @@ static int omap2_onenand_get_freq(struct
omap_onenand_platform_data *cfg,
static struct gpmc_timings
omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
- int freq, bool clk_dep)
+ int freq)
{
struct gpmc_timings t;
const int t_cer = 15;
@@ -259,22 +248,6 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
else
latency = 4;
- if (clk_dep) {
- if (gpmc_clk_ns 12) { /* 83Mhz */
- t_ces = 3;
- t_avds = 4;
- } else if (gpmc_clk_ns 15) { /* 66Mhz */
- t_ces = 5;
- t_avds = 4;
- } else if (gpmc_clk_ns 25) { /* 40Mhz */
- t_ces = 6;
- t_avds = 5;
- } else {
- t_ces = 7;
- t_avds = 7;
- }
- }
-
/* Set synchronous read timings */
memset(t, 0, sizeof(t));
@@ -381,16 +354,14 @@ static int omap2_onenand_setup_sync(void __iomem
*onenand_base, int *freq_ptr)
{
int ret, freq = *freq_ptr;
struct gpmc_timings t;
- bool clk_dep = false;
if (!freq) {
/* Very first call freq is not known */
- freq = omap2_onenand_get_freq(gpmc_onenand_data,
- onenand_base, clk_dep);
+ freq = omap2_onenand_get_freq(gpmc_onenand_data, onenand_base);
set_onenand_cfg(onenand_base);
}
- t = omap2_onenand_calc_sync_timings(gpmc_onenand_data, freq, clk_dep);
+ t = omap2_onenand_calc_sync_timings(gpmc_onenand_data, freq);
ret = gpmc_set_sync_mode(gpmc_onenand_data-cs, t);
if (IS_ERR_VALUE(ret))
diff --git a/arch/arm/plat-omap/include/plat/onenand.h
b/arch/arm/plat-omap/include/plat/onenand.h
index 2858667..21bb0ff 100644
--- a/arch/arm/plat-omap/include/plat/onenand.h
+++ b/arch/arm/plat-omap/include/plat/onenand.h
@@ -15,20 +15,12 @@
#define ONENAND_SYNC_READ (1 0)
#define ONENAND_SYNC_READWRITE (1 1)
-struct onenand_freq_info {
- u16 maf_id;
- u16 dev_id;
- u16 ver_id;
-};
-
struct omap_onenand_platform_data {
int cs;
int gpio_irq;
struct mtd_partition*parts;
int nr_parts;
int (*onenand_setup)(void __iomem *, int *freq_ptr);
- int (*get_freq)(const struct onenand_freq_info *freq_info,
- bool *clk_dep);
int dma_channel;
u8 flags;
u8 regulator_can_sleep;
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe
[PATCH v7 06/11] ARM: OMAP2+: gpmc: find features by ip rev check
Newer IP's have wr_access and wr_data_mux_bus fields. Use
IP revision values to determine availability of these
fields and hence decide on whether to configure them.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a481816..d0916e9 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -90,6 +90,11 @@
#define ENABLE_PREFETCH(0x1 7)
#define DMA_MPU_MODE 2
+#defineGPMC_REVISION_MAJOR(l) ((l 4) 0xf)
+
+#defineGPMC_HAS_WR_ACCESS 0x1
+#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
+
/* XXX: Only NAND irq has been considered,currently these are the only ones
used
*/
#defineGPMC_NR_IRQ 2
@@ -136,6 +141,7 @@ static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
+static unsigned gpmc_capability;
static void __iomem *gpmc_base;
static struct clk *gpmc_l3_clk;
@@ -364,10 +370,10 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
- if (cpu_is_omap34xx()) {
+ if (gpmc_capability GPMC_HAS_WR_DATA_MUX_BUS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
+ if (gpmc_capability GPMC_HAS_WR_ACCESS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
- }
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
@@ -930,6 +936,8 @@ static int __init gpmc_init(void)
clk_enable(gpmc_l3_clk);
l = gpmc_read_reg(GPMC_REVISION);
+ if (GPMC_REVISION_MAJOR(l) 0x4)
+ gpmc_capability = GPMC_HAS_WR_ACCESS | GPMC_HAS_WR_DATA_MUX_BUS;
printk(KERN_INFO GPMC revision %d.%d\n, (l 4) 0x0f, l 0x0f);
/* Set smart idle mode and automatic L3 clock gating */
l = gpmc_read_reg(GPMC_SYSCONFIG);
--
1.7.12
--
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 v7 07/11] ARM: OMAP2+: gpmc: remove cs# in sync clk div calc
Divider value for a certain sync clk is determined solely
based on gpmc fclk. CS# does not have any role here, thus
remove presence of CS# in clock divider calculation API.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 3 +--
arch/arm/mach-omap2/gpmc.c | 4 ++--
arch/arm/plat-omap/include/plat/gpmc.h | 2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index 1e6fce6..f2bf9d2 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -182,7 +182,6 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns;
int ticks_cez;
- int cs = cfg-cs;
if (cfg-flags ONENAND_SYNC_READ)
onenand_flags = ONENAND_FLAG_SYNCREAD;
@@ -229,7 +228,7 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
break;
}
- div = gpmc_cs_calc_divider(cs, min_gpmc_clk_period);
+ div = gpmc_calc_divider(min_gpmc_clk_period);
gpmc_clk_ns = gpmc_ticks_to_ns(div);
if (gpmc_clk_ns 15) /* 66Mhz */
onenand_flags |= ONENAND_FLAG_HF;
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d0916e9..35e4e7d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -321,7 +321,7 @@ static int set_gpmc_timing_reg(int cs, int reg, int st_bit,
int end_bit,
return -1
#endif
-int gpmc_cs_calc_divider(int cs, unsigned int sync_clk)
+int gpmc_calc_divider(unsigned int sync_clk)
{
int div;
u32 l;
@@ -341,7 +341,7 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
int div;
u32 l;
- div = gpmc_cs_calc_divider(cs, t-sync_clk);
+ div = gpmc_calc_divider(t-sync_clk);
if (div 0)
return div;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index b7c9ea6..1cafbfd 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -179,7 +179,7 @@ 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_cs_calc_divider(int cs, unsigned int sync_clk);
+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);
--
1.7.12
--
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 v7 08/11] ARM: OMAP2+: gpmc: generic timing calculation
Presently there are three peripherals that gets it timing by runtime calculation. Those peripherals can work with frequency scaling that affects gpmc clock. But timing calculation for them are in different ways. Here a generic runtime calculation method is proposed. Input to this function were selected so that they represent timing variables that are present in peripheral datasheets. Motive behind this was to achieve DT bindings for the inputs as is. Even though a few of the tusb6010 timings could not be made directly related to timings normally found on peripherals, expressions used were translated to those that could be justified. There are possibilities of improving the calculations, like calculating timing for read write operations in a more similar way. Expressions derived here were tested for async onenand on omap3evm (as vanilla Kernel does not have omap3evm onenand support, local patch was used). Other peripherals, tusb6010, smc91x calculations were validated by simulating on omap3evm. Regarding we_on for onenand async, it was found that even for muxed address/data, it need not be greater than adv_wr_off, but rather could be derived from write setup time for peripheral from start of access time, hence would more be in line with peripheral timings. With this method it was working fine. If it is required in some cases to have we_on same as wr_data_mux_bus (i.e. greater than adv_wr_off), another variable could be added to indicate it. But such a requirement is not expected though. It has been observed that adv_rd_off adv_wr_off are currently calculated by adding an offset over oe_on and we_on respectively in the case of smc91x. But peripheral datasheet does not specify so and so adv_rd(wr)_off has been derived (to be specific, made ignorant of oe_on and we_on) observing datasheet rather than adding an offset. Hence this generic routine is expected to work for smc91x (91C96 RX51 board). This was verified on smsc911x (9220 on OMAP3EVM) - a similar ethernet controller. Timings are calculated in ps to prevent rounding errors and converted to ns at final stage so that these values can be directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings() would be modified to take ps once all custom timing routines are replaced by the generic routine, at the same time generic timing routine would be modified to provide timings in ps. struct gpmc_timings field types are upgraded from u16 = u32 so that it can hold ps values. Whole of this exercise is being done to achieve driver and DT conversion. If timings could not be calculated in a peripheral agnostic way, either gpmc driver would have to be peripheral gnostic or a wrapper arrangement over gpmc driver would be required. Signed-off-by: Afzal Mohammed af...@ti.com --- v7: 1. Use picoseconds throughout generic timing routine to prevent rounding error. 2. Documentation on gpmc timings Documentation/bus-devices/ti-gpmc.txt | 77 arch/arm/mach-omap2/gpmc.c | 319 + arch/arm/plat-omap/include/plat/gpmc.h | 101 --- 3 files changed, 477 insertions(+), 20 deletions(-) create mode 100644 Documentation/bus-devices/ti-gpmc.txt diff --git a/Documentation/bus-devices/ti-gpmc.txt b/Documentation/bus-devices/ti-gpmc.txt new file mode 100644 index 000..2c88a88 --- /dev/null +++ b/Documentation/bus-devices/ti-gpmc.txt @@ -0,0 +1,77 @@ +GPMC (General Purpose Memory Controller): += + +GPMC is an unified memory controller dedicated to interfacing external +memory devices like + * Asynchronous SRAM like memories and application specific integrated + circuit devices. + * Asynchronous, synchronous, and page mode burst NOR flash devices + NAND flash + * Pseudo-SRAM devices + +GPMC is found on Texas Instruments SoC's (OMAP based) + + +GPMC generic timing calculation: + + +GPMC has certain timings that has to be programmed for proper +functioning of the peripheral, while peripheral has another set of +timings. To have peripheral work with gpmc, peripheral timings has to +be translated to the form gpmc can understand. The way it has to be +translated depends on the connected peripheral. Also there is a +dependency for certain gpmc timings on gpmc clock frequency. Hence a +generic timing routine was developed to achieve above requirements. + +Generic routine provides a generic method to calculate gpmc timings +from gpmc peripheral timings. struct gpmc_device_timings fields has to +be updated with timings from the datasheet of the peripheral that is +connected to gpmc. A few of the peripheral timings can be fed either +in time or in cycles, provision to handle this scenario has been +provided (refer struct gpmc_device_timings definition). It may so +happen that timing as specified by peripheral datasheet is not present +in timing structure, in this scenario, try to correlate peripheral +timing to the one
[PATCH v7 09/11] ARM: OMAP2+: onenand: generic timing calculation
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 124 +
1 file changed, 43 insertions(+), 81 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index f2bf9d2..837c77f 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -49,6 +49,7 @@ static struct platform_device gpmc_onenand_device = {
static struct gpmc_timings omap2_onenand_calc_async_timings(void)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
const int t_cer = 15;
@@ -58,35 +59,24 @@ static struct gpmc_timings
omap2_onenand_calc_async_timings(void)
const int t_aa = 76;
const int t_oe = 20;
const int t_cez = 20; /* max of t_cez, t_oez */
- const int t_ds = 30;
const int t_wpl = 40;
const int t_wph = 30;
- memset(t, 0, sizeof(t));
- t.sync_clk = 0;
- t.cs_on = 0;
- t.adv_on = 0;
-
- /* Read */
- t.adv_rd_off = gpmc_round_ns_to_ticks(max_t(int, t_avdp, t_cer));
- t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(t_aavdh);
- t.access = t.adv_on + gpmc_round_ns_to_ticks(t_aa);
- t.access = max_t(int, t.access, t.cs_on + gpmc_round_ns_to_ticks(t_ce));
- t.access = max_t(int, t.access, t.oe_on + gpmc_round_ns_to_ticks(t_oe));
- t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
- t.cs_rd_off = t.oe_off;
- t.rd_cycle = t.cs_rd_off + gpmc_round_ns_to_ticks(t_cez);
-
- /* Write */
- t.adv_wr_off = t.adv_rd_off;
- t.we_on = t.oe_on;
- if (cpu_is_omap34xx()) {
- t.wr_data_mux_bus = t.we_on;
- t.wr_access = t.we_on + gpmc_round_ns_to_ticks(t_ds);
- }
- t.we_off = t.we_on + gpmc_round_ns_to_ticks(t_wpl);
- t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
- t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
+ memset(dev_t, 0, sizeof(dev_t));
+
+ dev_t.mux = true;
+ dev_t.t_avdp_r = max_t(int, t_avdp, t_cer) * 1000;
+ dev_t.t_avdp_w = dev_t.t_avdp_r;
+ dev_t.t_aavdh = t_aavdh * 1000;
+ dev_t.t_aa = t_aa * 1000;
+ dev_t.t_ce = t_ce * 1000;
+ dev_t.t_oe = t_oe * 1000;
+ dev_t.t_cez_r = t_cez * 1000;
+ dev_t.t_cez_w = dev_t.t_cez_r;
+ dev_t.t_wpl = t_wpl * 1000;
+ dev_t.t_wph = t_wph * 1000;
+
+ gpmc_calc_timings(t, dev_t);
return t;
}
@@ -172,16 +162,15 @@ static struct gpmc_timings
omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
int freq)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
const int t_cer = 15;
const int t_avdp = 12;
const int t_cez = 20; /* max of t_cez, t_oez */
- const int t_ds = 30;
const int t_wpl = 40;
const int t_wph = 30;
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
- int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns;
- int ticks_cez;
+ int div, gpmc_clk_ns;
if (cfg-flags ONENAND_SYNC_READ)
onenand_flags = ONENAND_FLAG_SYNCREAD;
@@ -248,62 +237,35 @@ omap2_onenand_calc_sync_timings(struct
omap_onenand_platform_data *cfg,
latency = 4;
/* Set synchronous read timings */
- memset(t, 0, sizeof(t));
-
- if (div == 1) {
- t.bool_timings.cs_extra_delay = true;
- t.bool_timings.adv_extra_delay = true;
- t.bool_timings.oe_extra_delay = true;
- t.bool_timings.we_extra_delay = true;
- }
+ memset(dev_t, 0, sizeof(dev_t));
- t.sync_clk = min_gpmc_clk_period;
- t.cs_on = 0;
- t.adv_on = 0;
- fclk_offset_ns = gpmc_round_ns_to_ticks(max_t(int, t_ces, t_avds));
- fclk_offset = gpmc_ns_to_ticks(fclk_offset_ns);
- t.page_burst_access = gpmc_clk_ns;
-
- /* Read */
- t.adv_rd_off = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_avdh));
- t.oe_on = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_ach));
- /* Force at least 1 clk between AVD High to OE Low */
- if (t.oe_on = t.adv_rd_off)
- t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(1);
- t.access = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div);
- t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
- t.cs_rd_off = t.oe_off;
- ticks_cez = ((gpmc_ns_to_ticks(t_cez) + div - 1) / div) * div;
- t.rd_cycle = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div +
-ticks_cez);
-
- t.clk_activation = fclk_offset_ns;
-
- /* Write */
+ dev_t.mux = true;
+ dev_t.sync_read = true;
if (onenand_flags ONENAND_FLAG_SYNCWRITE) {
-
[PATCH v7 10/11] ARM: OMAP2+: smc91x: generic timing calculation
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-smc91x.c | 43 ---
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
index 245839d..2d19fd8 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -58,6 +58,7 @@ static struct platform_device gpmc_smc91x_device = {
static int smc91c96_gpmc_retime(void)
{
struct gpmc_timings t;
+ struct gpmc_device_timings dev_t;
const int t3 = 10; /* Figure 12.2 read and 12.4 write */
const int t4_r = 20;/* Figure 12.2 read */
const int t4_w = 5; /* Figure 12.4 write */
@@ -68,32 +69,6 @@ static int smc91c96_gpmc_retime(void)
const int t20 = 185;/* Figure 12.2 read and 12.4 write */
u32 l;
- memset(t, 0, sizeof(t));
-
- /* Read timings */
- t.cs_on = 0;
- t.adv_on = t.cs_on;
- t.oe_on = t.adv_on + t3;
- t.access = t.oe_on + t5;
- t.oe_off = t.access;
- t.adv_rd_off = t.oe_off + max(t4_r, t6);
- t.cs_rd_off = t.oe_off;
- t.rd_cycle = t20 - t.oe_on;
-
- /* Write timings */
- t.we_on = t.adv_on + t3;
-
- if (cpu_is_omap34xx() (gpmc_cfg-flags GPMC_MUX_ADD_DATA)) {
- t.wr_data_mux_bus = t.we_on;
- t.we_off = t.wr_data_mux_bus + t7;
- } else
- t.we_off = t.we_on + t7;
- if (cpu_is_omap34xx())
- t.wr_access = t.we_off;
- t.adv_wr_off = t.we_off + max(t4_w, t8);
- t.cs_wr_off = t.we_off + t4_w;
- t.wr_cycle = t20 - t.we_on;
-
l = GPMC_CONFIG1_DEVICESIZE_16;
if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
l |= GPMC_CONFIG1_MUXADDDATA;
@@ -115,6 +90,22 @@ static int smc91c96_gpmc_retime(void)
if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
return 0;
+ memset(dev_t, 0, sizeof(dev_t));
+
+ dev_t.t_oeasu = t3 * 1000;
+ dev_t.t_oe = t5 * 1000;
+ dev_t.t_cez_r = t4_r * 1000;
+ dev_t.t_oez = t6 * 1000;
+ dev_t.t_rd_cycle = (t20 - t3) * 1000;
+
+ dev_t.t_weasu = t3 * 1000;
+ dev_t.t_wpl = t7 * 1000;
+ dev_t.t_wph = t8 * 1000;
+ dev_t.t_cez_w = t4_w * 1000;
+ dev_t.t_wr_cycle = (t20 - t3) * 1000;
+
+ gpmc_calc_timings(t, dev_t);
+
return gpmc_cs_set_timings(gpmc_cfg-cs, t);
}
--
1.7.12
--
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 v7 11/11] ARM: OMAP2+: tusb6010: generic timing calculation
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c | 182 +
1 file changed, 44 insertions(+), 138 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index 7a85ebe..6f850f4 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -26,182 +26,88 @@ static u8 async_cs, sync_cs;
static unsignedrefclk_psec;
-/* t2_ps, when quantized to fclk units, must happen no earlier than
- * the clock after after t1_NS.
- *
- * Return a possibly updated value of t2_ps, converted to nsec.
- */
-static unsigned
-next_clk(unsigned t1_NS, unsigned t2_ps, unsigned fclk_ps)
-{
- unsignedt1_ps = t1_NS * 1000;
- unsignedt1_f, t2_f;
-
- if ((t1_ps + fclk_ps) t2_ps)
- return t2_ps / 1000;
-
- t1_f = (t1_ps + fclk_ps - 1) / fclk_ps;
- t2_f = (t2_ps + fclk_ps - 1) / fclk_ps;
-
- if (t1_f = t2_f)
- t2_f = t1_f + 1;
-
- return (t2_f * fclk_ps) / 1000;
-}
-
/* NOTE: timings are from tusb 6010 datasheet Rev 1.8, 12-Sept 2006 */
-static int tusb_set_async_mode(unsigned sysclk_ps, unsigned fclk_ps)
+static int tusb_set_async_mode(unsigned sysclk_ps)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
unsignedt_acsnh_advnh = sysclk_ps + 3000;
- unsignedtmp;
-
- memset(t, 0, sizeof(t));
-
- /* CS_ON = t_acsnh_acsnl */
- t.cs_on = 8;
- /* ADV_ON = t_acsnh_advnh - t_advn */
- t.adv_on = next_clk(t.cs_on, t_acsnh_advnh - 7000, fclk_ps);
-
- /*
-* READ ... from omap2420 TRM fig 12-13
-*/
-
- /* ADV_RD_OFF = t_acsnh_advnh */
- t.adv_rd_off = next_clk(t.adv_on, t_acsnh_advnh, fclk_ps);
-
- /* OE_ON = t_acsnh_advnh + t_advn_oen (then wait for nRDY) */
- t.oe_on = next_clk(t.adv_on, t_acsnh_advnh + 1000, fclk_ps);
-
- /* ACCESS = counters continue only after nRDY */
- tmp = t.oe_on * 1000 + 300;
- t.access = next_clk(t.oe_on, tmp, fclk_ps);
-
- /* OE_OFF = after data gets sampled */
- tmp = t.access * 1000;
- t.oe_off = next_clk(t.access, tmp, fclk_ps);
-
- t.cs_rd_off = t.oe_off;
-
- tmp = t.cs_rd_off * 1000 + 7000 /* t_acsn_rdy_z */;
- t.rd_cycle = next_clk(t.cs_rd_off, tmp, fclk_ps);
-
- /*
-* WRITE ... from omap2420 TRM fig 12-15
-*/
- /* ADV_WR_OFF = t_acsnh_advnh */
- t.adv_wr_off = t.adv_rd_off;
+ memset(dev_t, 0, sizeof(dev_t));
- /* WE_ON = t_acsnh_advnh + t_advn_wen (then wait for nRDY) */
- t.we_on = next_clk(t.adv_wr_off, t_acsnh_advnh + 1000, fclk_ps);
+ dev_t.mux = true;
- /* WE_OFF = after data gets sampled */
- tmp = t.we_on * 1000 + 300;
- t.we_off = next_clk(t.we_on, tmp, fclk_ps);
+ dev_t.t_ceasu = 8 * 1000;
+ dev_t.t_avdasu = t_acsnh_advnh - 7000;
+ dev_t.t_ce_avd = 1000;
+ dev_t.t_avdp_r = t_acsnh_advnh;
+ dev_t.t_oeasu = t_acsnh_advnh + 1000;
+ dev_t.t_oe = 300;
+ dev_t.t_cez_r = 7000;
+ dev_t.t_cez_w = dev_t.t_cez_r;
+ dev_t.t_avdp_w = t_acsnh_advnh;
+ dev_t.t_weasu = t_acsnh_advnh + 1000;
+ dev_t.t_wpl = 300;
+ dev_t.cyc_aavdh_we = 1;
- t.cs_wr_off = t.we_off;
-
- tmp = t.cs_wr_off * 1000 + 7000 /* t_acsn_rdy_z */;
- t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
+ gpmc_calc_timings(t, dev_t);
return gpmc_cs_set_timings(async_cs, t);
}
-static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
+static int tusb_set_sync_mode(unsigned sysclk_ps)
{
+ struct gpmc_device_timings dev_t;
struct gpmc_timings t;
unsignedt_scsnh_advnh = sysclk_ps + 3000;
- unsignedtmp;
-
- memset(t, 0, sizeof(t));
- t.cs_on = 8;
-
- /* ADV_ON = t_acsnh_advnh - t_advn */
- t.adv_on = next_clk(t.cs_on, t_scsnh_advnh - 7000, fclk_ps);
-
- /* GPMC_CLK rate = fclk rate / div */
- t.sync_clk = 11100 /* 11.1 nsec */;
- tmp = (t.sync_clk + fclk_ps - 1) / fclk_ps;
- if (tmp 4)
- return -ERANGE;
- if (tmp == 0)
- tmp = 1;
- t.page_burst_access = (fclk_ps * tmp) / 1000;
-
- /*
-* READ ... based on omap2420 TRM fig 12-19, 12-20
-*/
-
- /* ADV_RD_OFF = t_scsnh_advnh */
- t.adv_rd_off = next_clk(t.adv_on, t_scsnh_advnh, fclk_ps);
-
- /* OE_ON = t_scsnh_advnh + t_advn_oen * fclk_ps (then wait for nRDY) */
- tmp = (t.adv_rd_off * 1000) + (3 * fclk_ps);
- t.oe_on = next_clk(t.adv_on, tmp, fclk_ps);
-
- /* ACCESS = number of clock cycles after t_adv_eon */
- tmp = (t.oe_on * 1000) + (5
RE: [PATCH v6 10/10] ARM: OMAP2+: tusb6010: generic timing calculation
Hi Tony,
On Tue, Sep 18, 2012 at 04:40:02, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120917 15:54]:
Can you please try with the attached patch ?
Gave it a quick try and it seemed to work.. But when I tried
rebasing my patches for the cbus to keep things working with
the watchdog, I ran into multiple merge conflicts with
current linux next and gave up.
OK went back to my original branch without current linux
next and with the new cbus + retu driver from Aaro applied.
Confirmed it's now working on n800 tusb6010.
Thanks for checking and confirming.
Care to repost this series updated against current linux
next?
I'm afraid I've pretty much lost track of all the patches
and rather not start resolving the conflicts as I'm sure
I'll break something else :)
You should still repost the whole updated series against
linux next.
New updated version - v7, based over linux next has been posted.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Tue, Sep 18, 2012 at 05:35:33PM +0100, Lorenzo Pieralisi wrote:
In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
all cache levels up to Level of Coherency (LoC) that includes
the L2 unified cache.
When a single CPU is suspended (CPU idle) a complete L2 clean is not
required, so generic cpu_suspend code must clean the data cache using the
newly introduced cache LoUIS function.
For patches 3-5 in this series, we know that the assumption that
flushing LoUIS is sufficient for safely powering the CPU down is not
valid in the general case, though we've agreed it's a sensible
compromise for the CPU variants we know about today.
I think we do need to document this assumption, though.
At this point I don't mind whether it appears in code comments or in the
commit messages.
Cheers
---Dave
The context and stack pointer (context pointer) are cleaned to main memory
using cache area functions that operate on MVA and guarantee that the data
is written back to main memory (perform cache cleaning up to the Point of
Coherency - PoC) so that the processor can fetch the context when the MMU
is off in the cpu_resume code path.
outer_cache management remains unchanged.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
---
arch/arm/kernel/suspend.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 1794cc3..358bca3 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -17,6 +17,8 @@ extern void cpu_resume_mmu(void);
*/
void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
{
+ u32 *ctx = ptr;
+
*save_ptr = virt_to_phys(ptr);
/* This must correspond to the LDM in cpu_resume() assembly */
@@ -26,7 +28,20 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32
*save_ptr)
cpu_do_suspend(ptr);
- flush_cache_all();
+ flush_cache_louis();
+
+ /*
+ * flush_cache_louis does not guarantee that
+ * save_ptr and ptr are cleaned to main memory,
+ * just up to the Level of Unification Inner Shareable.
+ * Since the context pointer and context itself
+ * are to be retrieved with the MMU off that
+ * data must be cleaned from all cache levels
+ * to main memory using area cache primitives.
+ */
+ __cpuc_flush_dcache_area(ctx, ptrsz);
+ __cpuc_flush_dcache_area(save_ptr, sizeof(*save_ptr));
+
outer_clean_range(*save_ptr, *save_ptr + ptrsz);
outer_clean_range(virt_to_phys(save_ptr),
virt_to_phys(save_ptr) + sizeof(*save_ptr));
--
1.7.12
--
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 V6 1/2] of: Add generic device tree DMA helpers
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
...
Typo nits in the binding examples below...
Documentation/devicetree/bindings/dma/dma.txt | 81 +
drivers/of/Makefile |2 +-
drivers/of/dma.c | 219
+
include/linux/of_dma.h| 45 +
4 files changed, 346 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..a4f59a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,81 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver using DMA Engine to retrieve
the
+DMA request or channel information that goes from a hardware device to a DMA
+controller.
+
+
+* DMA controller
+
+Required property:
+- #dma-cells:Must be at least 1. Used to provide DMA
controller
+ specific information. See DMA client binding below for
+ more details.
+
+Optional properties:
+- #dma-channels: Number of DMA channels supported by the controller.
+- #dma-requests: Number of DMA requests signals supported by the
+ controller.
+
+Example:
+
+ dma: dma@4800 {
+ compatible = ti,omap-sdma
; here
+ reg = 0x4800 0x1000;
+ interrupts = 0 12 0x4
+ 0 13 0x4
+ 0 14 0x4
+ 0 15 0x4;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 127;
+ };
+
+
+* DMA client
+
+Client drivers should specify the DMA property using a phandle to the
controller
+followed by DMA controller specific data.
+
+Required property:
+- dmas: List of one or more DMA specifiers, each
consisting of
+ - A phandle pointing to DMA controller node
+ - A number of integer cells, as determined by the
+ #dma-cells property in the node referenced by phandle
+ containing DMA controller specific information. This
+ typically contains a DMA request line number or a
+ channel number, but can contain any data that is used
+ required for configuring a channel.
+- dma-names: Contains one identifier string for each DMA
specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
+ Multiple DMA specifiers can be used to represent
+ alternatives and in this case the dma-names for those
+ DMA specifiers must be identical (see examples).
+
+Examples:
+
+1. A device with one DMA read channel, one DMA write channel:
+
+ i2c1: i2c@1 {
+ ...
+ dmas = dma 2 /* read channel */
+ dma 3;/* write channel */
+ dma-names = rx, tx
; here too
+ ...
+ };
+
+2. A single read-write channel with three alternative DMA controllers:
+
+ dmas = dma1 5
+ dma2 7
+ dma3 2;
+ dma-names = rx-tx, rx-tx, rx-tx
again ;
+
+3. A device with three channels, one of which has two alternatives:
+
+ dmas = dma1 2 /* read channel */
+ dma1 3 /* write channel */
+ dma2 0 /* error read */
+ dma3 0; /* alternative error read */
+ dma-names = rx, tx, error, error;
Patch for these posted separately.
-Matt
--
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] of: dma: fix typos in generic dma binding definition
Some semicolons were left out in the examples.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/dma.txt |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index a4f59a5..b4cde0b 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -20,7 +20,7 @@ Optional properties:
Example:
dma: dma@4800 {
- compatible = ti,omap-sdma
+ compatible = ti,omap-sdma;
reg = 0x4800 0x1000;
interrupts = 0 12 0x4
0 13 0x4
@@ -61,7 +61,7 @@ Examples:
...
dmas = dma 2 /* read channel */
dma 3;/* write channel */
- dma-names = rx, tx
+ dma-names = rx, tx;
...
};
@@ -70,7 +70,7 @@ Examples:
dmas = dma1 5
dma2 7
dma3 2;
- dma-names = rx-tx, rx-tx, rx-tx
+ dma-names = rx-tx, rx-tx, rx-tx;
3. A device with three channels, one of which has two alternatives:
--
1.7.9.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: [RFC PATCH v2 2/5] ARM: mm: rename jump labels in v7_flush_dcache_all function
On Tue, Sep 18, 2012 at 05:35:32PM +0100, Lorenzo Pieralisi wrote: This patch renames jump labels in v7_flush_dcache_all in order to define a specific flush cache levels entry point. TODO: factor out the level flushing loop if considered worthwhile and define the input registers requirements. In the context of this series, this patch seems to do nothing at all (?) Maybe it would make sense to defer this patch until you post something that uses it. Given that I have a fair expectation that you will build something useful on top of this in the near future, I don't have a strong feeling about it, though. Cheers ---Dave Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com --- arch/arm/mm/cache-v7.S | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index d1fa2f6..140b294 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -48,7 +48,7 @@ ENTRY(v7_flush_dcache_louis) mov r3, r3, lsr #20 @ r3 = LoUIS * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 - b loop1 @ start flushing cache levels + b flush_levels@ start flushing cache levels ENDPROC(v7_flush_dcache_louis) /* @@ -67,7 +67,7 @@ ENTRY(v7_flush_dcache_all) mov r3, r3, lsr #23 @ left align loc bit field beq finished@ if loc is 0, then no need to clean mov r10, #0 @ start clean at cache level 0 -loop1: +flush_levels: add r2, r10, r10, lsr #1@ work out 3x current cache level mov r1, r0, lsr r2 @ extract cache type bits from clidr and r1, r1, #7 @ mask of the bits for current cache only @@ -89,9 +89,9 @@ loop1: clz r5, r4 @ find bit position of way size increment ldr r7, =0x7fff andsr7, r7, r1, lsr #13 @ extract max number of the index size -loop2: +loop1: mov r9, r4 @ create working copy of max way size -loop3: +loop2: ARM(orr r11, r10, r9, lsl r5) @ factor way and cache number into r11 THUMB( lsl r6, r9, r5 ) THUMB( orr r11, r10, r6) @ factor way and cache number into r11 @@ -100,13 +100,13 @@ loop3: THUMB( orr r11, r11, r6) @ factor index number into r11 mcr p15, 0, r11, c7, c14, 2 @ clean invalidate by set/way subsr9, r9, #1 @ decrement the way - bge loop3 - subsr7, r7, #1 @ decrement the index bge loop2 + subsr7, r7, #1 @ decrement the index + bge loop1 skip: add r10, r10, #2@ increment cache number cmp r3, r10 - bgt loop1 + bgt flush_levels finished: mov r10, #0 @ swith back to cache level 0 mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr -- 1.7.12 -- 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 V6 1/2] of: Add generic device tree DMA helpers
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt new file mode 100644 index 000..a4f59a5 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/dma.txt @@ -0,0 +1,81 @@ +* Generic DMA Controller and DMA request bindings + +Generic binding to provide a way for a driver using DMA Engine to retrieve the +DMA request or channel information that goes from a hardware device to a DMA +controller. + + +* DMA controller + +Required property: +- #dma-cells:Must be at least 1. Used to provide DMA controller + specific information. See DMA client binding below for + more details. + +Optional properties: +- #dma-channels: Number of DMA channels supported by the controller. +- #dma-requests: Number of DMA requests signals supported by the + controller. Shouldn't these two optional properties drop the prefix #? By convention adopted from the various original OF/ePAPR/etc specs, the only properties I would expect to see with this prefix are the *-cells cell sizes. A quick search indicates this is the case throughout all the current bindings. -Matt -- 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 V6 1/2] of: Add generic device tree DMA helpers
On 09/14/2012 05:41 PM, Jon Hunter wrote: This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2] to add some basic helpers to retrieve a DMA controller device_node and the DMA request/channel information. [snip] Reviewed-by: Arnd Bergmann a...@arndb.de Reviewed-by: Nicolas Ferre nicolas.fe...@atmel.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- Documentation/devicetree/bindings/dma/dma.txt | 81 + drivers/of/Makefile |2 +- drivers/of/dma.c | 219 + We've been moving in the direction of not putting subsystem related code under drivers/of, but rather with the subsystem. Although in some cases (i2c), the maintainers didn't want the OF code there. In any case, I guess this will go thru Vinod's tree, so: Acked-by: Rob Herring rob.herr...@calxeda.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 V6 1/2] of: Add generic device tree DMA helpers
On Wednesday 19 September 2012, Matt Porter wrote: +Optional properties: +- #dma-channels: Number of DMA channels supported by the controller. +- #dma-requests: Number of DMA requests signals supported by the + controller. Shouldn't these two optional properties drop the prefix #? By convention adopted from the various original OF/ePAPR/etc specs, the only properties I would expect to see with this prefix are the *-cells cell sizes. A quick search indicates this is the case throughout all the current bindings. I always assumed that the # prefix is used to indicate that we are counting things instead of listing them. Arnd -- 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 V6 1/2] of: Add generic device tree DMA helpers
On 09/19/2012 09:24 AM, Arnd Bergmann wrote: On Wednesday 19 September 2012, Matt Porter wrote: +Optional properties: +- #dma-channels: Number of DMA channels supported by the controller. +- #dma-requests: Number of DMA requests signals supported by the + controller. Shouldn't these two optional properties drop the prefix #? By convention adopted from the various original OF/ePAPR/etc specs, the only properties I would expect to see with this prefix are the *-cells cell sizes. A quick search indicates this is the case throughout all the current bindings. I always assumed that the # prefix is used to indicate that we are counting things instead of listing them. Lots of properties count things, but don't have a #. nr_gpios or spi chipselect counts for example. I'd say drop the #. Rob -- 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 V6 1/2] of: Add generic device tree DMA helpers
On Wed, Sep 19, 2012 at 09:36:36AM -0500, Rob Herring wrote: On 09/19/2012 09:24 AM, Arnd Bergmann wrote: On Wednesday 19 September 2012, Matt Porter wrote: +Optional properties: +- #dma-channels: Number of DMA channels supported by the controller. +- #dma-requests: Number of DMA requests signals supported by the + controller. Shouldn't these two optional properties drop the prefix #? By convention adopted from the various original OF/ePAPR/etc specs, the only properties I would expect to see with this prefix are the *-cells cell sizes. A quick search indicates this is the case throughout all the current bindings. I always assumed that the # prefix is used to indicate that we are counting things instead of listing them. Lots of properties count things, but don't have a #. nr_gpios or spi chipselect counts for example. I'd say drop the #. Ok, I can drop another trivial patch since I hear Jon is on vacation. Yeah, I grepped all the bindings and it's only ever encountered on cell sizes. There's not even one example of it used as above. -Matt -- 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/4] usb: phy: add a new driver for usb3 phy
On 09/19/2012 01:30 PM, Kishon Vijay Abraham I wrote:
Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller.
This also includes device tree support for usb3 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 18 +
drivers/usb/phy/Kconfig |9 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-usb3.c | 369
+
include/linux/usb/omap_usb.h | 72
5 files changed, 469 insertions(+)
create mode 100644 drivers/usb/phy/omap-usb3.c
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148..7c5fd89 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -15,3 +15,21 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58,
0x4a002300 0x4;
};
+
+OMAP USB3 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb3
+ - reg : Address and length of the register set for the device. Also
+add the address of control module phy power register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40,
+ 0x4a002370 0x4;
+};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 63c339b..353dc0c 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -13,6 +13,15 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config OMAP_USB3
+ tristate OMAP USB3 PHY Driver
+ select USB_OTG_UTILS
+ help
+ Enable this to support the USB3 PHY that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b069f29..973b1e6 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_OMAP_USB2) += omap-usb2.o
+obj-$(CONFIG_OMAP_USB3) += omap-usb3.o
obj-$(CONFIG_USB_ISP1301)+= isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
new file mode 100644
index 000..4dc84ca
--- /dev/null
+++ b/drivers/usb/phy/omap-usb3.c
@@ -0,0 +1,369 @@
+/*
+ * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/usb/omap_usb.h
+#include linux/of.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+
+static struct usb_dpll_params omap_usb3_dpll_params[NUM_SYS_CLKS] = {
+ {1250, 5, 4, 20, 0},/* 12 MHz */
+ {3125, 20, 4, 20, 0}, /* 16.8 MHz */
+ {1172, 8, 4, 20, 65537},/* 19.2 MHz */
+ {1250, 12, 4, 20, 0}, /* 26 MHz */
+ {3125, 47, 4, 20, 92843}, /* 38.4 MHz */
+};
+
+/**
+ * omap5_usb_phy_power - power on/off the serializer using control module
+ * @phy: struct omap_usb *
+ * @on: 0 to off and 1 to on based on powering on or off the PHY
+ *
+ * omap_usb3 can call this API to power on or off the PHY.
+ */
+static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
+{
+ u32 val;
+ unsigned long rate;
+
Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers
On 9/19/2012 7:09 PM, Arnd Bergmann wrote: On Tuesday 18 September 2012, Mitch Bradley wrote: There is a delicious irony here with respect to Shark. Shark has real Open Firmware. It's the platform that I used for the first OFW port to ARM. We (the Shark design team) had a version of NetBSD that would run on Shark without any native drivers, calling into the Open Firmware drivers. It was very useful for bringup. Very interesting, thanks for sharing this bit of history. Are you aware of other ARM systems using open firmware that we still support in Linux (besides the XO-1.75)? There is the successor to the XO-1.75 that we working on now. I don't know of any others. We just did a big push to convert a bunch of drivers to DT so we will able to use the same kernel on XO-1.75 and XO-4. The conversion went pretty smoothly, but there is still a fair amount of testing, integration, and coordination to do. When things get a bit less hectic, we'll start submitting patches. Is there ever a point when old architectures leave the Linux tree, or will people have to see grep hits from them until the end of time? As long as someone is interested in keeping an architecture or driver alive, it stays. If something is causing problems and we have reason to assume it will never be used again with current kernels, we toss them out. Russell has recently removed support for ARMv3 CPUs, but some of the StrongARM targets (especially SA-1100) are still being actively used, so the CPU support is not going away any time soon. If you have a bunch of Shark machines for testing and would like to port it over to device tree passing from its open firmware, you are definitely welcome ;-) I'm too busy working on new machines :-) Old machines are an exercise in frustration, due to hardware that stops working over time and insufficient hardware resources to meet the expectations of modern software. Not to mention the financial advantages of doing work that someone cares about ... Arnd -- 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 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
On 09/19/2012 01:56 PM, Felipe Balbi wrote:
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+if (of_property_read_bool(np, has960mhzclk)) {
+phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+if (IS_ERR(phy-optclk)) {
+dev_err(pdev-dev, unable to get refclk960m\n);
+return PTR_ERR(phy-optclk);
+}
+clk_prepare(phy-optclk);
+}
instead, can't you just always try to get the clock but ignore the error
if it fails ?
On imx we add no-op dummy clocks, so that the drivers will always find
all needed clocks. If a clk_get fails it's an error.
If it works you can set a flag to let you know that you can use that
optional clock.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
On Wed, Sep 19, 2012 at 04:45:01PM +0200, Marc Kleine-Budde wrote:
On 09/19/2012 01:56 PM, Felipe Balbi wrote:
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
instead, can't you just always try to get the clock but ignore the error
if it fails ?
On imx we add no-op dummy clocks, so that the drivers will always find
all needed clocks. If a clk_get fails it's an error.
It's an error from a clk API point of view, it doesn't mean device can't
work without that optional clock. Drivers are free to treat errors
however they like, even by ignoring it and defaulting to some other
behavior.
Adding dummy clocks just bloats the kernel with useless data IMHO.
my 2 cents.
--
balbi
signature.asc
Description: Digital signature
[PATCH v2] of: dma: fix typos in generic dma binding definition
Some semicolons were left out in the examples.
The #dma-channels and #dma-requests properties have a prefix
that is, by convention, reserved for cell size properties.
Rename those properties to dma-channels and dma-requests.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/dma.txt | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index a4f59a5..8f504e6 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -13,22 +13,22 @@ Required property:
more details.
Optional properties:
-- #dma-channels: Number of DMA channels supported by the controller.
-- #dma-requests: Number of DMA requests signals supported by the
+- dma-channels:Number of DMA channels supported by the controller.
+- dma-requests:Number of DMA requests signals supported by the
controller.
Example:
dma: dma@4800 {
- compatible = ti,omap-sdma
+ compatible = ti,omap-sdma;
reg = 0x4800 0x1000;
interrupts = 0 12 0x4
0 13 0x4
0 14 0x4
0 15 0x4;
#dma-cells = 1;
- #dma-channels = 32;
- #dma-requests = 127;
+ dma-channels = 32;
+ dma-requests = 127;
};
@@ -61,7 +61,7 @@ Examples:
...
dmas = dma 2 /* read channel */
dma 3;/* write channel */
- dma-names = rx, tx
+ dma-names = rx, tx;
...
};
@@ -70,7 +70,7 @@ Examples:
dmas = dma1 5
dma2 7
dma3 2;
- dma-names = rx-tx, rx-tx, rx-tx
+ dma-names = rx-tx, rx-tx, rx-tx;
3. A device with three channels, one of which has two alternatives:
--
1.7.9.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 13/16] ARM: omap: move platform_data definitions
On Tuesday 18 September 2012, Peter Ujfalusi wrote: I thought I have replied to this... Whichever way you prefer. I can craft a series to clean up the plat/mcbsp.h usage and move the mcbsp header via ASoC tree. I'm also fine if you do the move. Let me know what you prefer. I think I'll just keep all my patches together then, and leave this one in. Arnd -- 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 4/4] usb: phy: omap-usb2: enable 960Mhz clock for omap5
On 09/19/2012 04:42 PM, Felipe Balbi wrote:
On Wed, Sep 19, 2012 at 04:45:01PM +0200, Marc Kleine-Budde wrote:
On 09/19/2012 01:56 PM, Felipe Balbi wrote:
On Wed, Sep 19, 2012 at 05:00:29PM +0530, Kishon Vijay Abraham I wrote:
usb_otg_ss_refclk960m is needed by usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt |3 +++
drivers/usb/phy/omap-usb2.c | 28
-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 7c5fd89..d5626de 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -24,6 +24,9 @@ Required properties:
add the address of control module phy power register until a driver for
control module is added
+Optional properties:
+ - has960mhzclk: should be added if the phy needs 960mhz clock
+
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..d6612ba 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -146,6 +146,7 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
struct omap_usb *phy;
struct usb_otg *otg;
struct resource *res;
+ struct device_node *np = pdev-dev.of_node;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -190,6 +191,15 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ if (of_property_read_bool(np, has960mhzclk)) {
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk)) {
+ dev_err(pdev-dev, unable to get refclk960m\n);
+ return PTR_ERR(phy-optclk);
+ }
+ clk_prepare(phy-optclk);
+ }
instead, can't you just always try to get the clock but ignore the error
if it fails ?
On imx we add no-op dummy clocks, so that the drivers will always find
all needed clocks. If a clk_get fails it's an error.
It's an error from a clk API point of view, it doesn't mean device can't
work without that optional clock. Drivers are free to treat errors
however they like, even by ignoring it and defaulting to some other
behavior.
Sure.
Adding dummy clocks just bloats the kernel with useless data IMHO.
Just wanted to point out there's more than one way to do it.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V6 1/2] of: Add generic device tree DMA helpers
On Wednesday 19 September 2012, Matt Porter wrote: On Wed, Sep 19, 2012 at 09:36:36AM -0500, Rob Herring wrote: On 09/19/2012 09:24 AM, Arnd Bergmann wrote: On Wednesday 19 September 2012, Matt Porter wrote: +Optional properties: +- #dma-channels: Number of DMA channels supported by the controller. +- #dma-requests: Number of DMA requests signals supported by the + controller. Shouldn't these two optional properties drop the prefix #? By convention adopted from the various original OF/ePAPR/etc specs, the only properties I would expect to see with this prefix are the *-cells cell sizes. A quick search indicates this is the case throughout all the current bindings. I always assumed that the # prefix is used to indicate that we are counting things instead of listing them. Lots of properties count things, but don't have a #. nr_gpios or spi chipselect counts for example. I'd say drop the #. Ok, I can drop another trivial patch since I hear Jon is on vacation. Yeah, I grepped all the bindings and it's only ever encountered on cell sizes. There's not even one example of it used as above. Ok, sounds good. Arnd -- 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/1] drivers: bus: Move the OMAP interconnect driver to drivers/bus/
On Monday 17 September 2012, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120914 02:21]: OMAP interconnect drivers are used for the interconnect error handling. Since they are bus driver, lets move it to newly created drivers/bus. Cc: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- Patch just moves OMAP interconnect drivers as is to the newly created driver/bus/* directory. Patch is generated against arm-soc/drivers/ocp2scp tree and test on all OMAP boards. Great, looks like this should not conflict with other omap patches queued, so Arnd should probably take this into the bus branch: Acked-by: Tony Lindgren t...@atomide.com Ok, added to the branch. In the future please Cc both Olof and me when submitting patches for inclusion. Olof: I figured it would be easier if I just add this one than relaying it to you. Arnd -- 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/1] drivers: bus: Move the OMAP interconnect driver to drivers/bus/
On Wed, Sep 19, 2012 at 7:58 AM, Arnd Bergmann a...@arndb.de wrote: On Monday 17 September 2012, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120914 02:21]: OMAP interconnect drivers are used for the interconnect error handling. Since they are bus driver, lets move it to newly created drivers/bus. Cc: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- Patch just moves OMAP interconnect drivers as is to the newly created driver/bus/* directory. Patch is generated against arm-soc/drivers/ocp2scp tree and test on all OMAP boards. Great, looks like this should not conflict with other omap patches queued, so Arnd should probably take this into the bus branch: Acked-by: Tony Lindgren t...@atomide.com Ok, added to the branch. In the future please Cc both Olof and me when submitting patches for inclusion. Olof: I figured it would be easier if I just add this one than relaying it to you. Sounds good, thanks for the heads up. -Olof -- 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] of: dma: fix typos in generic dma binding definition
On Wednesday 19 September 2012, Matt Porter wrote: Some semicolons were left out in the examples. The #dma-channels and #dma-requests properties have a prefix that is, by convention, reserved for cell size properties. Rename those properties to dma-channels and dma-requests. Signed-off-by: Matt Porter mpor...@ti.com Acked-by: Arnd Bergmann a...@arndb.de -- 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] usb: otg: Resolving a config conflict between omap4030_usb/omap6030 and usb_musb_omap2plus
From: Jerome Kurtz jrm.ku...@gmail.com When I try to compile with TWL6030_USB=y, TWL4030_USB=y and USB_MUSB_OMAP2PLUS=m, I get the following error: drivers/built-in.o: In function `twl4030_usb_irq': /home/xxx/kernel/linux/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl6030_usb_irq': /home/xxx/kernel/linux/drivers/usb/otg/twl6030-usb.c:272: undefined reference to `omap_musb_mailbox' /home/xxx/kernel/linux/drivers/usb/otg/twl6030-usb.c:277: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl6030_usbotg_irq': /home/xxx/kernel/linux/drivers/usb/otg/twl6030-usb.c:306: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/xxx/kernel/linux/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' make: *** [vmlinux] Error 1 To solve this we must add to depends of TWL4030_USB and TWL6030_USB the option : USB_MUSB_OMAP2PLUS as done here. Signed-off-by: Jerome Kurtz jrm.ku...@gmail.com --- drivers/usb/otg/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 13fd1ddf..62ea57b 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -58,7 +58,7 @@ config USB_ULPI_VIEWPORT config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE REGULATOR_TWL4030 + depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL4030 @@ -68,7 +68,7 @@ config TWL4030_USB config TWL6030_USB tristate TWL6030 USB Transceiver Driver - depends on TWL4030_CORE + depends on TWL4030_CORE USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL6030 -- 1.7.2.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] backlight: Add TPS65217 WLED driver
Hi Matthias, On Tue, Sep 18, 2012 at 10:05:07PM +0200, Matthias Kaehlcke wrote: The MFD API probably allows you to do exactly that by defining a specific cell for bl. Could you please try to use this API or otherwise justify not using it? you seem to have missed v3 of the patch which addresses this, it was sent on 22 Aug 2012 Indeed, I missed it. Looks much better. in the next days i'll submit v4, with changes based on the comments received for v3 Sounds good. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [RFC PATCH 2/5] mfd: introduce retu-mfd driver
Hi Aaro, On Wed, Aug 29, 2012 at 12:34:24AM +0300, Aaro Koskinen wrote: Retu is a multi-function device found on Nokia Internet Tablets implementing at least watchdog, RTC, headset detection and power button functionality. This patch implements a minimum functionality providing only register access functions. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: sa...@linux.intel.com --- drivers/mfd/Kconfig |8 +++ drivers/mfd/Makefile |1 + drivers/mfd/retu-mfd.c | 114 ++ include/linux/mfd/retu.h | 20 4 files changed, 143 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/retu-mfd.c create mode 100644 include/linux/mfd/retu.h Besides Felipe's comments, you probably want to use regmap I2C for this driver. diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index b1a1462..8ca1270 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1003,6 +1003,14 @@ config MFD_PALMAS If you say yes here you get support for the Palmas series of PMIC chips from Texas Instruments. +config MFD_RETU + tristate Support for Retu multi-function device + select MFD_CORE + depends on I2C + help + Retu is a multi-function device found on Nokia Internet Tables + (770, N800 and N810). Which sub devices does it come with ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 2/4] mfd: introduce retu-mfd driver
Hi Aaro, On Mon, Sep 03, 2012 at 11:23:23PM +0300, Aaro Koskinen wrote: Retu is a multi-function device found on Nokia Internet Tablets implementing at least watchdog, RTC, headset detection and power button functionality. This patch implements minimum functionality providing register access, IRQ handling and power off functions. Cc: sa...@linux.intel.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- drivers/mfd/Kconfig |8 + drivers/mfd/Makefile |1 + drivers/mfd/retu-mfd.c | 347 ++ include/linux/mfd/retu.h | 22 +++ 4 files changed, 378 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/retu-mfd.c create mode 100644 include/linux/mfd/retu.h Now with the IRQ chip code, using the regmap APIs would be even more benefitial. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: AW: USB problem on beagleboard clone
On Wed, 19 Sep 2012, Maximilian Schwerin wrote: They're BeagleBoard XM clones. We're still trying to find out what the real problem is. The problem persists across three separate layouts using the same USB device and application. We're currently trying to see if this is related to MUSB only by using an EHCI port on the same board with the same device and application. Perhaps you might try this patch: http://marc.info/?l=linux-omapm=132976109928744w=2 Background is here: http://comments.gmane.org/gmane.linux.ports.arm.omap/71633 The patch is for an EHCI issue, but MUSB is clocked from the same DPLL. - Paul -- 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
