ACPI notifier chain?
Hi all, Can I use the ACPI notifier chain to get noticed when any change for any peripheral has been occurred ? Like the Video dimming ,can I make a Linux driver module to get informed once any change has been occurred to it?? Regards, tarek -- 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: DSS2 Switch between multiple displays
Hi, On Mon, 2009-11-30 at 20:26 +0100, ext Ashwin Bihari wrote: My system is going to have to support multiple display panels and switch between them using runtime checks. I've got two displays currently registered and confirmed with: # cat displays lcd e:1 u:1 t:0 h:480/2/2/41 v:272/2/6/10 p:1 r:0 i:0 lcd e:0 u:1 t:0 h:480/2/2/41 v:800/2/6/10 p:1 r:0 i:0 Short of adding a new module parameter for me to key off the panel_name to make the choice, is there some other way already implemented for me to indicate which display the DSS2 system should use as the default display panel? You are using an old version of DSS2. With later versions you can use omapdss.def_disp kernel parameter (see DSS documentation), or default_device field in omap_dss_board_info. Tomi -- 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: ACPI notifier chain?
Hi Tarek, On Tue, 2009-12-01 at 09:53 +0100, ext tarek attia wrote: Hi all, Can I use the ACPI notifier chain to get noticed when any change for any peripheral has been occurred ? Like the Video dimming ,can I make a Linux driver module to get informed once any change has been occurred to it?? Regards, tarek I believe ACPI is x86 architecture specific thing. I don't think it has anything to do with ARM / OMAP. Cheers, Ameya. -- 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: omap3evm: touchscreen delays on pm branch
Hi, Have you enabled CPUFREQ? We faced a similar issue and was due to ondemand governor. Selecting performance governors solved the issue. Regards, sriram On Fri, Nov 27, 2009 at 4:04 PM, Hemanth V heman...@ti.com wrote: - Original Message - From: Premi, Sanjeev pr...@ti.com To: Dasgupta, Romit ro...@ti.com Cc: linux-omap@vger.kernel.org Sent: Friday, November 27, 2009 3:20 PM Subject: RE: omap3evm: touchscreen delays on pm branch -Original Message- From: Dasgupta, Romit Sent: Friday, November 27, 2009 2:38 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: RE: omap3evm: touchscreen delays on pm branch On Fri, 2009-11-27 at 14:11 +0530, Premi, Sanjeev wrote: -Original Message- From: Dasgupta, Romit Sent: Friday, November 27, 2009 2:10 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: omap3evm: touchscreen delays on pm branch Premi, Sanjeev wrote: Hi, I am finding the response of touchscreen on the omap3evm very slow. Here is my test: On console, I run : watch -n2 cat /proc/interrupts Then, I tap the touchscreen approximately once per second. However, (usually) no interrupts are registered. As I increase the frequency of 'taps' more and more interrupts are registered. But still not matching exact taps. However, when I keep the cpu busy with cat /dev/zero /dev/null each tap is recognized. Do you see this even if we don't enable OFF? Yes. Sleep_while_idle=0; enable_off_mode=0 ~sanjeev Hopefully you have the same TSC driver. Nevertheless, can you please try this (just to see if clock domain idling is causing any problem or not): It is the same driver at SDP3430. I had earlier tried removing cpuidle altogether and did not see this issue. I too believe that issue is caused by clocks being going to (auto)idle. But then, Hemanth should be seeing the same behavior. Zoom2/Zoom3 use a different touchscreen driver compared to SDP. Its uses Synaptic Touchscreen over I2C. -- 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 -- 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] mfd: twl4030: Driver for twl4030 madc module
Hi Amit,
On Mon, Nov 30, 2009 at 03:58:39PM +0200, Amit Kucheria wrote:
+ * drivers/i2c/chips/twl4030-madc.c
drivers/mfd/twl4030-madc.c
By the way, have you considered moving this one to drivers/hwmon ?
I haven't. I moved it from i2c/chips/ to the most obvious place I
could think of - drivers/mfd. But wasn't this the point of mfd - that
various subcomponents drivers could live there instead of being
scattered across the driver tree?
Not really. Most of the drivers in mfd/ are for the core parts of the
corresponding chip (chip init and setup, subdevices definitions and
declarations, API export, IRQ setups, etc...).
I can take this driver for now, but converting it to a proper hwmon driver
would make sense because that's what it is after all.
+static struct twl4030_madc_data *the_madc;
I dont particularly enjoy that. All of the twl4030 drivers have this bad
habit
of assuming they will be alone on a platform. Although it's certainly very
likely, I still think having this kind of design is not so nice.
I agree. Unfortunately, twl4030-core.c is unable to handle multiple
devices currently. See note from line 779 in twl4030-core below:
Oh, I know about that. That's also something the code maintainers (Nokia I
assume) of that driver should start looking at.
+static int twl4030_madc_read(struct twl4030_madc_data *madc, u8 reg)
+{
+ int ret;
+ u8 val;
+
+ ret = twl4030_i2c_read_u8(TWL4030_MODULE_MADC, val, reg);
+ if (ret) {
+ dev_dbg(madc-dev, unable to read register 0x%X\n, reg);
+ return ret;
+ }
+
+ return val;
+}
FWIW, you're not checking the return value on any of the madc_read calls
below.
I've changed the dev_dbg above to dev_err now. If we see those error
messages, then anything that follows from the higher level functions
is overhead IMHO.
I usually expect code to check for function return values :) And also exit if
a IO fails.
The higher level functions in this case aren't adding any more useful
information to the error. E.g. I could check the return value again in
twl4030_madc_channel_raw_read() below. But if would simply repeat the
same error message we show in twl4030_madc_read().
The error message matter less than the code flow itself. For example if
twl4030_madc_start_conversion() fails because of your i2c failing, you will
still busy loop (Yes, only for 5ms, but still) waiting for a register bit to
toggle.
Hmm, perhaps twl4030_madc_read should return void?
That would be weird, imho. In fact, your write routine returning void is
already weird.
+static void twl4030_madc_work(struct work_struct *ws)
+{
+ const struct twl4030_madc_conversion_method *method;
+ struct twl4030_madc_data *madc;
+ struct twl4030_madc_request *r;
+ int len, i;
+
+ madc = container_of(ws, struct twl4030_madc_data, ws);
+ mutex_lock(madc-lock);
+
+ for (i = 0; i TWL4030_MADC_NUM_METHODS; i++) {
+
+ r = madc-requests[i];
+
+ /* No pending results for this method, move to next one */
+ if (!r-result_pending)
+ continue;
+
+ method = twl4030_conversion_methods[r-method];
+
+ /* Read results */
+ len = twl4030_madc_read_channels(madc, method-rbase,
+ r-channels, r-rbuf);
+
+ /* Return results to caller */
+ if (r-func_cb != NULL) {
+ r-func_cb(len, r-channels, r-rbuf);
+ r-func_cb = NULL;
+ }
+
+ /* Free request */
+ r-result_pending = 0;
+ r-active = 0;
+ }
+
+ mutex_unlock(madc-lock);
+}
I think you may want to consider using a threaded irq here, see
request_threaded_irq().
I am working on moving the entire twl* driver set to use threaded irqs
on the side. Will you consider merging this code with the work_struct
since it is known to work while I work on the conversion?
That's fine, yes. Thanks in advance for the conversion.
+static int twl4030_madc_set_power(struct twl4030_madc_data *madc, int on);
+int twl4030_madc_conversion(struct twl4030_madc_request *req)
+{
+ const struct twl4030_madc_conversion_method *method;
+ u8 ch_msb, ch_lsb;
+ int ret;
+
+ if (unlikely(!req))
+ return -EINVAL;
+
+ mutex_lock(the_madc-lock);
+
+ twl4030_madc_set_power(the_madc, 1);
+
+ /* Do we have a conversion request ongoing */
+ if (the_madc-requests[req-method].active) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ ch_msb = (req-channels 8) 0xff;
+ ch_lsb = req-channels 0xff;
+
+ method = twl4030_conversion_methods[req-method];
+
+ /* Select channels to be converted */
+ twl4030_madc_write(the_madc, method-sel
linux-2.6.28-rc6-omap1
Hi, all! Is there some git repository with kernel version 2.6.28-rc6-omap1? As I understand it is older OMAP3 kernel Nokia n900 and Beagle were based on. I just need it as merge base to move some work, based on 2.6.28-rc6-omap1 to mainline in maintainable way, so I need it to have proper history. Any links? Thanks a lot, S. -- 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: Preventing OMAP3 serial driver to take control of all UARTs
On Mon, Nov 30, 2009 at 10:09:58PM +0100, ext Tony Lindgren wrote:
* Peter Barada pet...@logicpd.com [091130 12:30]:
On Mon, 2009-11-30 at 11:40 -0800, Tony Lindgren wrote:
* Grant Likely grant.lik...@secretlab.ca [091130 09:01]:
On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada pet...@logicpd.com
wrote:
On Mon, 2009-11-30 at 10:46 +0200, Mika Westerberg wrote:
Hi Tony,
Current omap serial driver takes control of all 3 (4 on OMAP3640)
UARTS. However, we have such a setup where UART2 for example is used
by bluetooth driver. It uses the UART as non-standard way (there are
some Nokia extensions to H4 protocol) so we cannot use the standard
driver for driving the UART but have written special one for that
purpose.
Question is: Is there any, upstreamable, way of preventing omap
serial
driver to do this? Currently this is done with custom #ifdef hackery
to
mach-omap2/serial.c. Alternative solution that comes into mind is to
specify UART configuration in board files and let serial driver to
use
that instead of hard-coded one. Or do you have some nice
alternatives?
Previously (back around 2.6.28-rc8) in the board file, the
omap_uart_config struct controlled which serial ports were enabled on
startup. It was used in omap_serial_init, and it looks like that code
went away with the following commit:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/serial.c;h=2e17b57f5b23bb6703a2d621103585af1d8d729b;hp=555e735524381cbf8ef9f20d778ad81f9438e24e;hb=4355c41a635943d30e9396b95185314343dcb551;hpb=7e9ccf7776bb68b5367eb0bb35e519df62bea35c
I'm kinda in the same boat as I want to use some of the unused serial
port pins for GPIO, but they are setup as serial ports
Sounds like we need something back to specify the ports to use
from board-*.c files. Kevin, got any comments?
Not in mainlined yet, but I'm working on porting flattened device tree
support to OMAP to solve exactly this sort of problem. Basically,
instead of hard coding or #ifdeffing things, a data blob gets handed
to the kernel at boot time telling it exactly what hardware is present
in a consistent, parsable format. Device drivers then get probed
based on data in the device tree. Here's some info on the approach:
http://www.elinux.org/Device_Trees
I expect to have my prototype ready for review mid-January, and most
of the common code should be either merged or queued up in linux-next
by that time.
While device tree is a nice solution to some of the problems, it still
leaves all the issues we already have with buggy and and outdated
bootloaders. So we still need to properly initialize the devices in
the kernel.
Just for reference, most of the omap bootloader bugs seem to be
related to not muxing the pins right or using wrong timings for GPMC.
And then things that mostly change during the board development are
the GPIO pins, but those can be easily rewritten in the board-*.c
files based on the omap_rev.
But at least the device tree is a standard model, while the earlier
omap tag approach was non-standard.
Peter, maybe you've already thought through all this.. But would it be
possible to do lightweight device tree that we just use to populate
the platform data?
One possibility is to pass to omap_serial_init() the omap_uart_config
struct pointer to specify which parts are enabled. If a NULL is passed
in, then enable all the ports available. Since omap_serial_early_init()
was already called, the muxing would have to be cleaned up, but since
the kernel should mux all the pins it uses, that shouldn't be a problem.
omap_serial_init would now look something like(warning, coding on the
fly - don't know if it will work as is):
void __init omap_serial_init(struct omap_uart_config *confptr)
{
int i;
for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
/* Only enable
if (!confptr || confptr-port_enabled (1i)) {
omap_uart_reset(uart);
omap_uart_idle_init(uart);
if (WARN_ON(platform_device_register(pdev)))
continue;
if ((cpu_is_omap34xx() uart-padconf) ||
(uart-wk_en uart-wk_mask)) {
device_init_wakeup(dev, true);
DEV_CREATE_FILE(dev, dev_attr_sleep_timeout);
}
}
}
}
Yeah, I guess something like that would be good. We may want to
specify the optional other pins there too,
[PATCH 2/3] omap3: cm-t35: add DSS2 display support
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c | 234 +++-
1 files changed, 233 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 22c4529..2d7a819 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -32,6 +32,9 @@
#include linux/i2c/twl4030.h
#include linux/regulator/machine.h
+#include linux/spi/spi.h
+#include linux/spi/tdo24m.h
+
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -42,6 +45,7 @@
#include plat/nand.h
#include plat/gpmc.h
#include plat/usb.h
+#include plat/display.h
#include mach/hardware.h
@@ -248,7 +252,6 @@ static inline void cm_t35_init_nand(void) {}
#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
-#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include plat/mcspi.h
@@ -304,6 +307,193 @@ static void __init cm_t35_init_ads7846(void)
static inline void cm_t35_init_ads7846(void) {}
#endif
+#define CM_T35_LCD_EN_GPIO 157
+#define CM_T35_LCD_BL_GPIO 58
+#define CM_T35_DVI_EN_GPIO 54
+
+static int lcd_bl_gpio;
+static int lcd_en_gpio;
+static int dvi_en_gpio;
+
+static int lcd_enabled;
+static int dvi_enabled;
+
+static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ if (dvi_enabled) {
+ printk(KERN_ERR cannot enable LCD, DVI is enabled\n);
+ return -EINVAL;
+ }
+
+ gpio_set_value(lcd_en_gpio, 1);
+ gpio_set_value(lcd_bl_gpio, 1);
+
+ lcd_enabled = 1;
+
+ return 0;
+}
+
+static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ lcd_enabled = 0;
+
+ gpio_set_value(lcd_bl_gpio, 0);
+ gpio_set_value(lcd_en_gpio, 0);
+}
+
+static int cm_t35_panel_enable_dvi(struct omap_dss_device *dssdev)
+{
+ if (lcd_enabled) {
+ printk(KERN_ERR cannot enable DVI, LCD is enabled\n);
+ return -EINVAL;
+ }
+
+ gpio_set_value(dvi_en_gpio, 0);
+ dvi_enabled = 1;
+
+ return 0;
+}
+
+static void cm_t35_panel_disable_dvi(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dvi_en_gpio, 1);
+ dvi_enabled = 0;
+}
+
+static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
+{
+}
+
+static struct omap_dss_device cm_t35_lcd_device = {
+ .name = lcd,
+ .driver_name= toppoly_tdo35s_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 18,
+ .platform_enable= cm_t35_panel_enable_lcd,
+ .platform_disable = cm_t35_panel_disable_lcd,
+};
+
+static struct omap_dss_device cm_t35_dvi_device = {
+ .name = dvi,
+ .driver_name= generic_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 24,
+ .platform_enable= cm_t35_panel_enable_dvi,
+ .platform_disable = cm_t35_panel_disable_dvi,
+};
+
+static struct omap_dss_device cm_t35_tv_device = {
+ .name = tv,
+ .driver_name= venc,
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+ .platform_enable= cm_t35_panel_enable_tv,
+ .platform_disable = cm_t35_panel_disable_tv,
+};
+
+static struct omap_dss_device *cm_t35_dss_devices[] = {
+ cm_t35_lcd_device,
+ cm_t35_dvi_device,
+ cm_t35_tv_device,
+};
+
+static struct omap_dss_board_info cm_t35_dss_data = {
+ .num_devices= ARRAY_SIZE(cm_t35_dss_devices),
+ .devices= cm_t35_dss_devices,
+ .default_device = cm_t35_dvi_device,
+};
+
+static struct platform_device cm_t35_dss_device = {
+ .name = omapdss,
+ .id = -1,
+ .dev= {
+ .platform_data = cm_t35_dss_data,
+ },
+};
+
+static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,/* 0: slave, 1: master */
+};
+
+static struct tdo24m_platform_data tdo24m_config = {
+ .model = TDO35S,
+};
+
+static struct spi_board_info cm_t35_lcd_spi_board_info[] __initdata = {
+ {
+ .modalias = tdo24m,
+ .bus_num= 4,
+ .chip_select= 0,
+ .max_speed_hz = 100,
+ .controller_data= tdo24m_mcspi_config,
+ .platform_data = tdo24m_config,
+ },
+};
+
+static void __init cm_t35_display_init(void)
+{
+ int err;
+
+ lcd_en_gpio = CM_T35_LCD_EN_GPIO;
+ lcd_bl_gpio = CM_T35_LCD_BL_GPIO;
+ dvi_en_gpio = CM_T35_DVI_EN_GPIO;
[PATCH 0/3] omap3: cm-t35: enable display subsystem
This patchset adds display support for CM-T35 board. The following changes since commit 82f1d8f22f2c65e70206e40a6f17688bf64a892c: Tony Lindgren (1): Merge branch 'for-next' of git://gitorious.org/linux-omap-dss2/linux Mike Rapoport (3): OMAP: DSS2: add Toppoly TDO35S panel omap3: cm-t35: add DSS2 display support omap3: cm-t35: update defconfig for DSS2 arch/arm/configs/cm_t35_defconfig | 82 +++- arch/arm/mach-omap2/board-cm-t35.c | 234 +++- drivers/video/omap2/displays/Kconfig |6 + drivers/video/omap2/displays/Makefile |1 + .../video/omap2/displays/panel-toppoly-tdo35s.c| 112 ++ 5 files changed, 430 insertions(+), 5 deletions(-) create mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] omap3: cm-t35: update defconfig for DSS2
Signed-off-by: Mike Rapoport m...@compulab.co.il --- arch/arm/configs/cm_t35_defconfig | 82 +++-- 1 files changed, 78 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/cm_t35_defconfig b/arch/arm/configs/cm_t35_defconfig index e42c5c8..bd6f882 100644 --- a/arch/arm/configs/cm_t35_defconfig +++ b/arch/arm/configs/cm_t35_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.32-rc4 -# Tue Oct 13 17:10:40 2009 +# Linux kernel version: 2.6.32-rc8 +# Tue Dec 1 12:08:44 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -215,6 +215,7 @@ CONFIG_OMAP_DM_TIMER=y # CONFIG_OMAP_LL_DEBUG_UART1 is not set # CONFIG_OMAP_LL_DEBUG_UART2 is not set CONFIG_OMAP_LL_DEBUG_UART3=y +# CONFIG_OMAP_LL_DEBUG_NONE is not set # CONFIG_OMAP_PM_NONE is not set CONFIG_OMAP_PM_NOOP=y CONFIG_ARCH_OMAP34XX=y @@ -227,11 +228,15 @@ CONFIG_ARCH_OMAP3430=y # CONFIG_MACH_OMAP_LDP is not set # CONFIG_MACH_OVERO is not set # CONFIG_MACH_OMAP3EVM is not set +# CONFIG_MACH_OMAP3517EVM is not set # CONFIG_MACH_OMAP3_PANDORA is not set # CONFIG_MACH_OMAP_3430SDP is not set # CONFIG_MACH_NOKIA_RX51 is not set # CONFIG_MACH_OMAP_ZOOM2 is not set +# CONFIG_MACH_OMAP_ZOOM3 is not set CONFIG_MACH_CM_T35=y +# CONFIG_MACH_IGEP0020 is not set +# CONFIG_MACH_OMAP_3630SDP is not set # # Processor Type @@ -963,6 +968,7 @@ CONFIG_SSB_POSSIBLE=y # CONFIG_TPS65010 is not set CONFIG_TWL4030_CORE=y # CONFIG_TWL4030_POWER is not set +# CONFIG_TWL4030_CODEC is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set # CONFIG_MFD_TC6387XB is not set @@ -993,8 +999,66 @@ CONFIG_REGULATOR_TWL4030=y # # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set -# CONFIG_FB is not set -# CONFIG_BACKLIGHT_LCD_SUPPORT is not set +CONFIG_FB=y +# CONFIG_FIRMWARE_EDID is not set +# CONFIG_FB_DDC is not set +# CONFIG_FB_BOOT_VESA_SUPPORT is not set +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set +# CONFIG_FB_SYS_FILLRECT is not set +# CONFIG_FB_SYS_COPYAREA is not set +# CONFIG_FB_SYS_IMAGEBLIT is not set +# CONFIG_FB_FOREIGN_ENDIAN is not set +# CONFIG_FB_SYS_FOPS is not set +# CONFIG_FB_SVGALIB is not set +# CONFIG_FB_MACMODES is not set +# CONFIG_FB_BACKLIGHT is not set +# CONFIG_FB_MODE_HELPERS is not set +# CONFIG_FB_TILEBLITTING is not set + +# +# Frame buffer hardware drivers +# +# CONFIG_FB_S1D13XXX is not set +# CONFIG_FB_VIRTUAL is not set +# CONFIG_FB_METRONOME is not set +# CONFIG_FB_MB862XX is not set +# CONFIG_FB_BROADSHEET is not set +# CONFIG_FB_OMAP_BOOTLOADER_INIT is not set +CONFIG_OMAP2_VRAM=y +CONFIG_OMAP2_VRFB=y +CONFIG_OMAP2_DSS=y +CONFIG_OMAP2_VRAM_SIZE=4 +CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y +# CONFIG_OMAP2_DSS_RFBI is not set +CONFIG_OMAP2_DSS_VENC=y +# CONFIG_OMAP2_DSS_SDI is not set +# CONFIG_OMAP2_DSS_DSI is not set +# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set +CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 +CONFIG_FB_OMAP2=y +CONFIG_FB_OMAP2_DEBUG_SUPPORT=y +# CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE is not set +CONFIG_FB_OMAP2_NUM_FBS=3 + +# +# OMAP2/3 Display Device Drivers +# +CONFIG_PANEL_GENERIC=y +# CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set +# CONFIG_PANEL_SHARP_LS037V7DW01 is not set +CONFIG_PANEL_TOPPOLY_TDO35S=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y +# CONFIG_LCD_LMS283GF05 is not set +# CONFIG_LCD_LTV350QV is not set +# CONFIG_LCD_ILI9320 is not set +CONFIG_LCD_TDO24M=y +# CONFIG_LCD_VGG2432A4 is not set +# CONFIG_LCD_PLATFORM is not set +# CONFIG_BACKLIGHT_CLASS_DEVICE is not set # # Display device support @@ -1006,6 +1070,16 @@ CONFIG_REGULATOR_TWL4030=y # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE=y +# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set +# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set +# CONFIG_FONTS is not set +CONFIG_FONT_8x8=y +CONFIG_FONT_8x16=y +CONFIG_LOGO=y +CONFIG_LOGO_LINUX_MONO=y +CONFIG_LOGO_LINUX_VGA16=y +CONFIG_LOGO_LINUX_CLUT224=y # CONFIG_SOUND is not set CONFIG_HID_SUPPORT=y CONFIG_HID=y -- 1.6.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: DSS2: add Toppoly TDO35S panel
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |1 +
.../video/omap2/displays/panel-toppoly-tdo35s.c| 112
3 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 79d2861..0d0d4f3 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -25,4 +25,10 @@ config PANEL_TAAL
help
Taal DSI command mode panel from TPO.
+config PANEL_TOPPOLY_TDO35S
+tristate Toppoly TDO35S LCD Panel support
+depends on OMAP2_DSS
+help
+ LCD Panel used in CM-T35
+
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index d44e765..e299454 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C) +=
panel-samsung-lte430wq-f0c.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
+obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
\ No newline at end of file
diff --git a/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
new file mode 100644
index 000..e744b8c
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-toppoly-tdo35s.c
@@ -0,0 +1,112 @@
+/*
+ * LCD panel driver for Toppoly TDO35S
+ *
+ * Copyright (C) 2009 CompuLab, Ltd.
+ * Author: Mike Rapoport m...@compulab.co.il
+ *
+ * Based on generic panel support
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+
+#include plat/display.h
+
+static struct omap_video_timings toppoly_tdo_panel_timings = {
+ /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = 480,
+ .y_res = 640,
+
+ .pixel_clock= 26000,
+
+ .hfp= 104,
+ .hsw= 8,
+ .hbp= 8,
+
+ .vfp= 4,
+ .vsw= 2,
+ .vbp= 2,
+};
+
+static int toppoly_tdo_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS;
+ dssdev-panel.timings = toppoly_tdo_panel_timings;
+
+ return 0;
+}
+
+static void toppoly_tdo_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int toppoly_tdo_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
+}
+
+static void toppoly_tdo_panel_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+}
+
+static int toppoly_tdo_panel_suspend(struct omap_dss_device *dssdev)
+{
+ toppoly_tdo_panel_disable(dssdev);
+ return 0;
+}
+
+static int toppoly_tdo_panel_resume(struct omap_dss_device *dssdev)
+{
+ return toppoly_tdo_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver generic_driver = {
+ .probe = toppoly_tdo_panel_probe,
+ .remove = toppoly_tdo_panel_remove,
+
+ .enable = toppoly_tdo_panel_enable,
+ .disable= toppoly_tdo_panel_disable,
+ .suspend= toppoly_tdo_panel_suspend,
+ .resume = toppoly_tdo_panel_resume,
+
+ .driver = {
+ .name = toppoly_tdo35s_panel,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init toppoly_tdo_panel_drv_init(void)
+{
+ return omap_dss_register_driver(generic_driver);
+}
+
+static void __exit toppoly_tdo_panel_drv_exit(void)
+{
+ omap_dss_unregister_driver(generic_driver);
+}
+
+module_init(toppoly_tdo_panel_drv_init);
+module_exit(toppoly_tdo_panel_drv_exit);
+MODULE_LICENSE(GPL);
--
1.6.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI notifier chain?
Hi Ameya, I believe ACPI is a standard that doesn't matter it's X86 or ARM ,and it's responsible for power states (S,C,D and P states) ,,and Linux kernel implemented this standard . Am I right ?? BTW :- if it's not like so,,How can I monitor the power changes on the peripherals like LCD connected to my beagleboard ?? How can I make the power management for the peripherals ?? On Tue, Dec 1, 2009 at 11:58 AM, Ameya Palande ameya.pala...@nokia.com wrote: Hi Tarek, On Tue, 2009-12-01 at 09:53 +0100, ext tarek attia wrote: Hi all, Can I use the ACPI notifier chain to get noticed when any change for any peripheral has been occurred ? Like the Video dimming ,can I make a Linux driver module to get informed once any change has been occurred to it?? Regards, tarek I believe ACPI is x86 architecture specific thing. I don't think it has anything to do with ARM / OMAP. Cheers, Ameya. -- 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: linux-2.6.28-rc6-omap1
Hi, all! Is there some git repository with kernel version 2.6.28-rc6-omap1? As I understand it is older OMAP3 kernel Nokia n900 and Beagle were based on. I just need it as merge base to move some work, based on 2.6.28-rc6-omap1 to mainline in maintainable way, so I need it to have proper history. Any links? v2.6.28-omap1 exists as a tag on Tony's linux-omap tree [1]. You can just clone that and checkout that tag. Or browse the gitweb at [2]. - Anand [1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git [2] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=tree;h=refs/tags/v2.6.28-omap1 -- 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: linux-2.6.28-rc6-omap1
On Tue, Dec 1, 2009 at 2:47 PM, Gadiyar, Anand gadi...@ti.com wrote: v2.6.28-omap1 exists as a tag on Tony's linux-omap tree [1]. Actually I need 2.6.28-rc6-omap1, because in v2.6.28 clock subsystem was slightly changed and lots of little somethings are different, so many that it gets out of control :( S. -- 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
SR1: VDD autocomp is not active
Hi, all! on my OMAP3525-based custom board I get SR1: VDD autocomp is not active and SR2: VDD autocomp is not active quite frequently with PM branch. What that means, and how to fix it? Thanks a lot, S. -- 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/6] Basic OMAP4 PRCM register def series
Hi, This series contains patches which define OMAP4430 PRM/CM1/CM2 module register offsets and masks. These patches apply on top of the latest mainline kernel (2.6.32-rc8) and are tested on the OMAP4 simulator platform as well the omap4430sdp based on ES1.0 silicon. These patches are also boot tested on omap3430sdp and compile tested for h4 and 2430. All the headers as part of this series are autogenerated using OMAP4 hardware database and is a joint effort of Paul Walmsley (p...@pwsan.com), Benoit Cousson (b-cous...@ti.com) and me. regards, Rajendra Rajendra Nayak (6): ARM: OMAP4: PM: Fix the PRM and CM base addresses ARM: OMAP4: PM: PRM/CM module offsets for OMAP4 ARM: OMAP4: PM: Adds PRM register defs for OMAP4 ARM: OMAP4: PM: Adds PRM register shift and mask bits ARM: OMAP4: PM: Adds CM1/2 register defs for OMAP4 ARM: OMAP4: PM: Adds CM1/2 register field masks -- 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/6] ARM: OMAP4: PM: PRM/CM module offsets for OMAP4
This patch adds the offsets for new modules in PRM and CM for OMAP4 These are autogenerated using a python script (gen_prcm44xx_h.py) developed by Paul Walmsley and Benoit Cousson. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/prcm-common.h | 67 +++- 1 files changed, 65 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index cb1ae84..4f1b736 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -4,10 +4,12 @@ /* * OMAP2/3 PRCM base and module definitions * - * Copyright (C) 2007-2008 Texas Instruments, Inc. - * Copyright (C) 2007-2008 Nokia Corporation + * Copyright (C) 2007-2009 Texas Instruments, Inc. + * Copyright (C) 2007-2009 Nokia Corporation * * Written by Paul Walmsley + * OMAP4 defines in this file are automatically generated from the OMAP hardware + * databases. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -49,6 +51,67 @@ #define OMAP3430_NEON_MOD 0xb00 #define OMAP3430ES2_USBHOST_MOD0xc00 +/* OMAP44XX specific module offsets */ + +/* CM1 instances */ + +#define OMAP4430_CM1_OCP_SOCKET_MOD0x +#define OMAP4430_CM1_CKGEN_MOD 0x0100 +#define OMAP4430_CM1_MPU_MOD 0x0300 +#define OMAP4430_CM1_TESLA_MOD 0x0400 +#define OMAP4430_CM1_ABE_MOD 0x0500 +#define OMAP4430_CM1_RESTORE_MOD 0x0e00 +#define OMAP4430_CM1_INSTR_MOD 0x0f00 + +/* CM2 instances */ + +#define OMAP4430_CM2_OCP_SOCKET_MOD0x +#define OMAP4430_CM2_CKGEN_MOD 0x0100 +#define OMAP4430_CM2_ALWAYS_ON_MOD 0x0600 +#define OMAP4430_CM2_CORE_MOD 0x0700 +#define OMAP4430_CM2_IVAHD_MOD 0x0f00 +#define OMAP4430_CM2_CAM_MOD 0x1000 +#define OMAP4430_CM2_DSS_MOD 0x1100 +#define OMAP4430_CM2_GFX_MOD 0x1200 +#define OMAP4430_CM2_L3INIT_MOD0x1300 +#define OMAP4430_CM2_L4PER_MOD 0x1400 +#define OMAP4430_CM2_CEFUSE_MOD0x1600 +#define OMAP4430_CM2_RESTORE_MOD 0x1e00 +#define OMAP4430_CM2_INSTR_MOD 0x1f00 + +/* PRM instances */ + +#define OMAP4430_PRM_OCP_SOCKET_MOD0x +#define OMAP4430_PRM_CKGEN_MOD 0x0100 +#define OMAP4430_PRM_MPU_MOD 0x0300 +#define OMAP4430_PRM_TESLA_MOD 0x0400 +#define OMAP4430_PRM_ABE_MOD 0x0500 +#define OMAP4430_PRM_ALWAYS_ON_MOD 0x0600 +#define OMAP4430_PRM_CORE_MOD 0x0700 +#define OMAP4430_PRM_IVAHD_MOD 0x0f00 +#define OMAP4430_PRM_CAM_MOD 0x1000 +#define OMAP4430_PRM_DSS_MOD 0x1100 +#define OMAP4430_PRM_GFX_MOD 0x1200 +#define OMAP4430_PRM_L3INIT_MOD0x1300 +#define OMAP4430_PRM_L4PER_MOD 0x1400 +#define OMAP4430_PRM_CEFUSE_MOD0x1600 +#define OMAP4430_PRM_WKUP_MOD 0x1700 +#define OMAP4430_PRM_WKUP_CM_MOD 0x1800 +#define OMAP4430_PRM_EMU_MOD 0x1900 +#define OMAP4430_PRM_EMU_CM_MOD0x1a00 +#define OMAP4430_PRM_DEVICE_MOD0x1b00 +#define OMAP4430_PRM_INSTR_MOD 0x1f00 + +/* SCRM instances */ + +#define OMAP4430_SCRM_SCRM_MOD 0x + +/* CHIRONSS instances */ + +#define OMAP4430_CHIRONSS_CHIRONSS_OCP_SOCKET_PRCM_MOD 0x +#define OMAP4430_CHIRONSS_CHIRONSS_DEVICE_PRM_MOD 0x0200 +#define OMAP4430_CHIRONSS_CHIRONSS_CPU0_MOD0x0400 +#define OMAP4430_CHIRONSS_CHIRONSS_CPU1_MOD0x0800 /* 24XX register bits shared between CM PRM registers */ -- 1.5.4.7 -- 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/6] ARM: OMAP4: PM: Fix the PRM and CM base addresses
This patch fixes the PRM and CM base addresses and adds
a new CM2 base address for OMAP4
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/prcm.c |2 ++
arch/arm/plat-omap/common.c|2 ++
arch/arm/plat-omap/include/mach/common.h |1 +
arch/arm/plat-omap/include/mach/omap44xx.h |6 --
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index ced555a..256f9fa 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -28,6 +28,7 @@
static void __iomem *prm_base;
static void __iomem *cm_base;
+static void __iomem *cm2_base;
#define MAX_MODULE_ENABLE_WAIT 10
@@ -167,4 +168,5 @@ void __init omap2_set_globals_prcm(struct omap_globals
*omap2_globals)
{
prm_base = omap2_globals-prm;
cm_base = omap2_globals-cm;
+ cm2_base = omap2_globals-cm2;
}
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 3a4768d..bf00f3f 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -281,12 +281,14 @@ static struct omap_globals omap4_globals = {
.ctrl = OMAP2_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm= OMAP2_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_IO_ADDRESS(OMAP4430_CM_BASE),
+ .cm2= OMAP2_IO_ADDRESS(OMAP4430_CM2_BASE),
};
void __init omap2_set_globals_443x(void)
{
omap2_set_globals_tap(omap4_globals);
omap2_set_globals_control(omap4_globals);
+ omap2_set_globals_prcm(omap4_globals);
}
#endif
diff --git a/arch/arm/plat-omap/include/mach/common.h
b/arch/arm/plat-omap/include/mach/common.h
index fdeab42..878c4f9 100644
--- a/arch/arm/plat-omap/include/mach/common.h
+++ b/arch/arm/plat-omap/include/mach/common.h
@@ -55,6 +55,7 @@ struct omap_globals {
void __iomem*ctrl; /* System Control Module */
void __iomem*prm; /* Power and Reset Management */
void __iomem*cm;/* Clock Management */
+ void __iomem*cm2;
};
void omap2_set_globals_242x(void);
diff --git a/arch/arm/plat-omap/include/mach/omap44xx.h
b/arch/arm/plat-omap/include/mach/omap44xx.h
index b3ba5ac..d7b4c28 100644
--- a/arch/arm/plat-omap/include/mach/omap44xx.h
+++ b/arch/arm/plat-omap/include/mach/omap44xx.h
@@ -23,8 +23,10 @@
#define L4_EMU_44XX_BASE 0x5400
#define L3_44XX_BASE 0x4400
#define OMAP4430_32KSYNCT_BASE 0x4a304000
-#define OMAP4430_CM_BASE 0x4a004000
-#define OMAP4430_PRM_BASE 0x48306000
+#define OMAP4430_CM1_BASE 0x4a004000
+#define OMAP4430_CM_BASE OMAP4430_CM1_BASE
+#define OMAP4430_CM2_BASE 0x4a008000
+#define OMAP4430_PRM_BASE 0x4a306000
#define OMAP44XX_GPMC_BASE 0x5000
#define OMAP443X_SCM_BASE 0x4a002000
#define OMAP443X_CTRL_BASE OMAP443X_SCM_BASE
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ARM: OMAP4: PM: Adds PRM register defs for OMAP4
This patch adds OMAP4 specific PRM register defs. Auto generated using a python script (gen_prm_4430_h.py) developed by Paul Walmsley and Benoit Cousson. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/prm.h |8 +- arch/arm/mach-omap2/prm44xx.h | 411 + 2 files changed, 417 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/prm44xx.h diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h index 03c467c..8b2b76d 100644 --- a/arch/arm/mach-omap2/prm.h +++ b/arch/arm/mach-omap2/prm.h @@ -4,8 +4,8 @@ /* * OMAP2/3 Power/Reset Management (PRM) register definitions * - * Copyright (C) 2007 Texas Instruments, Inc. - * Copyright (C) 2007 Nokia Corporation + * Copyright (C) 2007-2009 Texas Instruments, Inc. + * Copyright (C) 2009 Nokia Corporation * * Written by Paul Walmsley * @@ -22,6 +22,10 @@ OMAP2_IO_ADDRESS(OMAP2430_PRM_BASE + (module) + (reg)) #define OMAP34XX_PRM_REGADDR(module, reg) \ OMAP2_IO_ADDRESS(OMAP3430_PRM_BASE + (module) + (reg)) +#define OMAP44XX_PRM_REGADDR(module, reg) \ + OMAP2_IO_ADDRESS(OMAP4430_PRM_BASE + (module) + (reg)) + +#include prm44xx.h /* * Architecture-specific global PRM registers diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h new file mode 100644 index 000..89be97f --- /dev/null +++ b/arch/arm/mach-omap2/prm44xx.h @@ -0,0 +1,411 @@ +/* + * OMAP44xx PRM instance offset macros + * + * Copyright (C) 2009 Texas Instruments, Inc. + * Copyright (C) 2009 Nokia Corporation + * + * Paul Walmsley (p...@pwsan.com) + * Rajendra Nayak (rna...@ti.com) + * Benoit Cousson (b-cous...@ti.com) + * + * This file is automatically generated from the OMAP hardware databases. + * We respectfully ask that any modifications to this file be coordinated + * with the public linux-omap@vger.kernel.org mailing list and the + * authors above to ensure that the autogeneration scripts are kept + * up-to-date with the file contents. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __ARCH_ARM_MACH_OMAP2_PRM44XX_H +#define __ARCH_ARM_MACH_OMAP2_PRM44XX_H + + +/* PRM */ + + +/* PRM.OCP_SOCKET_PRM register offsets */ +#define OMAP4430_REVISION_PRM OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x) +#define OMAP4430_PRM_IRQSTATUS_MPU OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0010) +#define OMAP4430_PRM_IRQSTATUS_MPU_2 OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0014) +#define OMAP4430_PRM_IRQENABLE_MPU OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0018) +#define OMAP4430_PRM_IRQENABLE_MPU_2 OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x001c) +#define OMAP4430_PRM_IRQSTATUS_DUCATI OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0020) +#define OMAP4430_PRM_IRQENABLE_DUCATI OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0028) +#define OMAP4430_PRM_IRQSTATUS_TESLA OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0030) +#define OMAP4430_PRM_IRQENABLE_TESLA OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0038) +#define OMAP4430_PRM_PRM_PROFILING_CLKCTRL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_OCP_SOCKET_MOD, 0x0040) + +/* PRM.CKGEN_PRM register offsets */ +#define OMAP4430_CM_ABE_DSS_SYS_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x) +#define OMAP4430_CM_DPLL_SYS_REF_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x0004) +#define OMAP4430_CM_L4_WKUP_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x0008) +#define OMAP4430_CM_ABE_PLL_REF_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x000c) +#define OMAP4430_CM_SYS_CLKSEL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_CKGEN_MOD, 0x0010) + +/* PRM.MPU_PRM register offsets */ +#define OMAP4430_PM_MPU_PWRSTCTRL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_MPU_MOD, 0x) +#define OMAP4430_PM_MPU_PWRSTST OMAP44XX_PRM_REGADDR(OMAP4430_PRM_MPU_MOD, 0x0004) +#define OMAP4430_RM_MPU_RSTST OMAP44XX_PRM_REGADDR(OMAP4430_PRM_MPU_MOD, 0x0014) +#define OMAP4430_RM_MPU_MPU_CONTEXT OMAP44XX_PRM_REGADDR(OMAP4430_PRM_MPU_MOD, 0x0024) + +/* PRM.TESLA_PRM register offsets */ +#define OMAP4430_PM_TESLA_PWRSTCTRL OMAP44XX_PRM_REGADDR(OMAP4430_PRM_TESLA_MOD, 0x) +#define OMAP4430_PM_TESLA_PWRSTST
RE: [PATCHV3 2/4] OMAP3: Clock Type change for OMAP3 Clocks
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, November 30, 2009 1:57 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHV3 2/4] OMAP3: Clock Type change for OMAP3 Clocks
Hi Vishwanath,
On Thu, 26 Nov 2009, Vishwanath BS wrote:
In omap34xx_clks, CK_343X type is used by all OMAP3 family of
processors. It makes more sense to name clock type as CK_3XXX since it
is common to all OMAP3 processors.
Hmmm. Do all of the CK_3XXX clocks apply to AM3503/3517?
Currently all OMAP3 chip families are using CK_343X as the common clock and
this clock has been renamed to CK_3XXX. So CK_3XXX should be applicable for all.
- Paul
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock.h | 15 +-
arch/arm/mach-omap2/clock34xx.c | 370 +++---
arch/arm/mach-omap2/clock34xx.h | 158 +++---
arch/arm/plat-omap/include/plat/clock.h |2 +-
4 files changed, 274 insertions(+), 271 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 43b6bed..8ceefcc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -79,20 +79,23 @@ extern u8 cpu_mask;
/* clksel_rate data common to 24xx/343x */
static const struct clksel_rate gpt_32k_rates[] = {
-{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
+{ .div = 1, .val = 0, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+ DEFAULT_RATE },
{ .div = 0 }
};
static const struct clksel_rate gpt_sys_rates[] = {
-{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE },
+{ .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+ DEFAULT_RATE },
{ .div = 0 }
};
static const struct clksel_rate gfx_l3_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_343X },
- { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_343X |
DEFAULT_RATE
},
- { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_343X },
- { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_343X },
+ { .div = 1, .val = 1, .flags = RATE_IN_24XX | RATE_IN_3XXX },
+ { .div = 2, .val = 2, .flags = RATE_IN_24XX | RATE_IN_3XXX |
+ DEFAULT_RATE },
+ { .div = 3, .val = 3, .flags = RATE_IN_243X | RATE_IN_3XXX },
+ { .div = 4, .val = 4, .flags = RATE_IN_243X | RATE_IN_3XXX },
{ .div = 0 }
};
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
omap2/clock34xx.c
index 832ed0b..167f075 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -94,69 +94,69 @@ struct omap_clk {
}, \
}
-#define CK_343X(1 0)
+#define CK_3XXX(1 0)
#define CK_3430ES1 (1 1)
#define CK_3430ES2 (1 2)
static struct omap_clk omap34xx_clks[] = {
- CLK(NULL, omap_32k_fck, omap_32k_fck, CK_343X),
- CLK(NULL, virt_12m_ck, virt_12m_ck, CK_343X),
- CLK(NULL, virt_13m_ck, virt_13m_ck, CK_343X),
+ CLK(NULL, omap_32k_fck, omap_32k_fck, CK_3XXX),
+ CLK(NULL, virt_12m_ck, virt_12m_ck, CK_3XXX),
+ CLK(NULL, virt_13m_ck, virt_13m_ck, CK_3XXX),
CLK(NULL, virt_16_8m_ck, virt_16_8m_ck, CK_3430ES2),
- CLK(NULL, virt_19_2m_ck, virt_19_2m_ck, CK_343X),
- CLK(NULL, virt_26m_ck, virt_26m_ck, CK_343X),
- CLK(NULL, virt_38_4m_ck, virt_38_4m_ck, CK_343X),
- CLK(NULL, osc_sys_ck, osc_sys_ck,CK_343X),
- CLK(NULL, sys_ck, sys_ck,CK_343X),
- CLK(NULL, sys_altclk, sys_altclk,CK_343X),
- CLK(NULL, mcbsp_clks, mcbsp_clks,CK_343X),
- CLK(NULL, sys_clkout1, sys_clkout1, CK_343X),
- CLK(NULL, dpll1_ck, dpll1_ck, CK_343X),
- CLK(NULL, dpll1_x2_ck, dpll1_x2_ck, CK_343X),
- CLK(NULL, dpll1_x2m2_ck, dpll1_x2m2_ck, CK_343X),
- CLK(NULL, dpll2_ck, dpll2_ck, CK_343X),
- CLK(NULL, dpll2_m2_ck, dpll2_m2_ck, CK_343X),
- CLK(NULL, dpll3_ck, dpll3_ck, CK_343X),
- CLK(NULL, core_ck, core_ck, CK_343X),
- CLK(NULL, dpll3_x2_ck, dpll3_x2_ck, CK_343X),
- CLK(NULL, dpll3_m2_ck, dpll3_m2_ck, CK_343X),
- CLK(NULL, dpll3_m2x2_ck, dpll3_m2x2_ck, CK_343X),
- CLK(NULL, dpll3_m3_ck, dpll3_m3_ck, CK_343X),
- CLK(NULL, dpll3_m3x2_ck, dpll3_m3x2_ck, CK_343X),
- CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_343X),
- CLK(NULL, dpll4_ck, dpll4_ck, CK_343X),
- CLK(NULL, dpll4_x2_ck,
[PATCH 0/5] OMAP4 clock framework support
Hi, This patch series adds support for OMAP4 clock framework and models all clock nodes in PRM/CM1/CM2 modules and also models all the DPLL nodes. This series has a dependency on [1] and can be applied on top of the latest mainline kernel (2.6.32-rc8). This series is tested on the OMAP4 simulator platform as well the omap4430sdp based on ES1.0 silicon. These patches are also boot tested on omap3430sdp and compile tested for h4 and 2420. The complete omap4 clock tree (clock44xx.h) is autogenerated using OMAP4 hardware database and is a joint effort of Paul Walmsley (p...@pwsan.com), Benoit Cousson (b-cous...@ti.com) and me. regards, Rajendra [1]: http://marc.info/?l=linux-omapm=125966979202578w=2 Rajendra Nayak (5): ARM: OMAP4: PM: Complete OMAP4 clock tree modelling ARM: OMAP4: PM: Basic OMAP4 clock framework ARM: OMAP4: PM: Move DPLL control apis to dpll.c ARM: OMAP4: PM: Add support for OMAP4 dpll api's ARM: OMAP4: PM: Add init api for DPLL nodes -- 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/5] ARM: OMAP4: PM: Basic OMAP4 clock framework
This patch registers the OMAP4430 clock
nodes with the CLKDEV framework.
Enables CLKDEV for OMAP4.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile|8 +-
arch/arm/mach-omap2/clock.c |8 +
arch/arm/mach-omap2/clock44xx.c | 331 +++
arch/arm/mach-omap2/cm.h|4 +
arch/arm/mach-omap2/gpmc.c |2 +-
arch/arm/mach-omap2/io.c|4 +-
arch/arm/plat-omap/Kconfig |1 +
arch/arm/plat-omap/clock.c | 26 ---
arch/arm/plat-omap/include/mach/clock.h |3 +
9 files changed, 354 insertions(+), 33 deletions(-)
create mode 100644 arch/arm/mach-omap2/clock44xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8cb1677..229dac7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -3,11 +3,12 @@
#
# Common support
-obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
+obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o prcm.o
\
+clock.o
omap-2-3-common= irq.o sdrc.o omap_hwmod.o
-prcm-common= prcm.o powerdomain.o
-clock-common = clock.o clockdomain.o
+prcm-common= powerdomain.o
+clock-common = clockdomain.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(clock-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common)
@@ -43,6 +44,7 @@ obj-$(CONFIG_ARCH_OMAP4) += cm4xxx.o
# Clock framework
obj-$(CONFIG_ARCH_OMAP2) += clock24xx.o
obj-$(CONFIG_ARCH_OMAP3) += clock34xx.o
+obj-$(CONFIG_ARCH_OMAP4) += clock44xx.o
iommu-y+= iommu2.o
iommu-$(CONFIG_ARCH_OMAP3) += omap3-iommu.o
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index f2a92d6..adf1a78 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -149,6 +149,7 @@ static int _dpll_test_fint(struct clk *clk, u8 n)
* clockdomain pointer, and save it into the struct clk. Intended to be
* called during clk_register(). No return value.
*/
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
void omap2_init_clk_clkdm(struct clk *clk)
{
struct clockdomain *clkdm;
@@ -166,6 +167,7 @@ void omap2_init_clk_clkdm(struct clk *clk)
clkdm %s\n, clk-name, clk-clkdm_name);
}
}
+#endif
/**
* omap2_init_clksel_parent - set a clksel clk's parent field from the hardware
@@ -437,8 +439,10 @@ void omap2_clk_disable(struct clk *clk)
_omap2_clk_disable(clk);
if (clk-parent)
omap2_clk_disable(clk-parent);
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
if (clk-clkdm)
omap2_clkdm_clk_disable(clk-clkdm, clk);
+#endif
}
}
@@ -448,8 +452,10 @@ int omap2_clk_enable(struct clk *clk)
int ret = 0;
if (clk-usecount++ == 0) {
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
if (clk-clkdm)
omap2_clkdm_clk_enable(clk-clkdm, clk);
+#endif
if (clk-parent) {
ret = omap2_clk_enable(clk-parent);
@@ -468,8 +474,10 @@ int omap2_clk_enable(struct clk *clk)
return ret;
err:
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is in place */
if (clk-clkdm)
omap2_clkdm_clk_disable(clk-clkdm, clk);
+#endif
clk-usecount--;
return ret;
}
diff --git a/arch/arm/mach-omap2/clock44xx.c b/arch/arm/mach-omap2/clock44xx.c
new file mode 100644
index 000..e015200
--- /dev/null
+++ b/arch/arm/mach-omap2/clock44xx.c
@@ -0,0 +1,331 @@
+/*
+ * OMAP4-specific clock framework functions
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Rajendra Nayak (rna...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#undef DEBUG
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/device.h
+#include linux/list.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/limits.h
+#include linux/bitops.h
+
+#include mach/clock.h
+#include mach/sram.h
+#include asm/div64.h
+#include asm/clkdev.h
+
+#include mach/sdrc.h
+#include clock.h
+#include prm.h
+#include prm-regbits-44xx.h
+#include cm.h
+#include cm-regbits-44xx.h
+
+
+static const struct clkops clkops_noncore_dpll_ops;
+
+#include clock44xx.h
+
+struct
[PATCH 4/5] ARM: OMAP4: PM: Add support for OMAP4 dpll api's
Most of the dpll api's from dpll.c are reused for OMAP4.
This patch does extend a few api's for OMAP4 support.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile|4 +++-
arch/arm/mach-omap2/clock.c |5 +
arch/arm/mach-omap2/clock.h |6 ++
arch/arm/mach-omap2/clock44xx.c | 25 -
arch/arm/mach-omap2/dpll.c | 22 ++
5 files changed, 28 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59a568c..ece0d18 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -7,12 +7,14 @@ obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o
timer-gp.o prcm.o \
clock.o
omap-2-3-common= irq.o sdrc.o omap_hwmod.o
+omap-3-4-common= dpll.o
prcm-common= powerdomain.o
clock-common = clockdomain.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(clock-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common) \
- dpll.o
+ $(omap-3-4-common)
+obj-$(CONFIG_ARCH_OMAP4) += $(omap-3-4-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index adf1a78..88b53b9 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -249,6 +249,11 @@ u32 omap2_get_dpll_rate(struct clk *clk)
if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
v == OMAP3XXX_EN_DPLL_FRBYPASS)
return dd-clk_bypass-rate;
+ } else if (cpu_is_omap44xx()) {
+ if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP4XXX_EN_DPLL_FRBYPASS ||
+ v == OMAP4XXX_EN_DPLL_MNBYPASS)
+ return dd-clk_bypass-rate;
}
v = __raw_readl(dd-mult_div1_reg);
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index bc24687..29e6a1a 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -36,6 +36,12 @@
#define OMAP3XXX_EN_DPLL_FRBYPASS 0x6
#define OMAP3XXX_EN_DPLL_LOCKED0x7
+/* OMAP4xxx CM_CLKMODE_DPLL*.EN_*_DPLL bits - for omap2_get_dpll_rate() */
+#define OMAP4XXX_EN_DPLL_MNBYPASS 0x4
+#define OMAP4XXX_EN_DPLL_LPBYPASS 0x5
+#define OMAP4XXX_EN_DPLL_FRBYPASS 0x6
+#define OMAP4XXX_EN_DPLL_LOCKED0x7
+
/* CM_CLKEN_PLL*.EN* bit values - not all are available for every DPLL */
#define DPLL_LOW_POWER_STOP0x1
#define DPLL_LOW_POWER_BYPASS 0x5
diff --git a/arch/arm/mach-omap2/clock44xx.c b/arch/arm/mach-omap2/clock44xx.c
index 785cdeb..8b38aa2 100644
--- a/arch/arm/mach-omap2/clock44xx.c
+++ b/arch/arm/mach-omap2/clock44xx.c
@@ -246,31 +246,6 @@ static struct clk_functions omap2_clk_functions = {
.clk_disable_unused = omap2_clk_disable_unused,
};
-/*
- * Dummy functions for DPLL control. Plan is to re-use
- * existing OMAP3 dpll control functions.
- */
-
-unsigned long omap3_dpll_recalc(struct clk *clk)
-{
- return 0;
-}
-
-int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
-{
- return 0;
-}
-
-int omap3_noncore_dpll_enable(struct clk *clk)
-{
- return 0;
-}
-
-void omap3_noncore_dpll_disable(struct clk *clk)
-{
- return;
-}
-
static const struct clkops clkops_noncore_dpll_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
diff --git a/arch/arm/mach-omap2/dpll.c b/arch/arm/mach-omap2/dpll.c
index 3e1378f..273348e 100644
--- a/arch/arm/mach-omap2/dpll.c
+++ b/arch/arm/mach-omap2/dpll.c
@@ -318,10 +318,12 @@ int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8
n, u16 freqsel)
_omap3_noncore_dpll_bypass(clk);
/* Set jitter correction */
- v = __raw_readl(dd-control_reg);
- v = ~dd-freqsel_mask;
- v |= freqsel __ffs(dd-freqsel_mask);
- __raw_writel(v, dd-control_reg);
+ if (!cpu_is_omap44xx()) {
+ v = __raw_readl(dd-control_reg);
+ v = ~dd-freqsel_mask;
+ v |= freqsel __ffs(dd-freqsel_mask);
+ __raw_writel(v, dd-control_reg);
+ }
/* Set DPLL multiplier, divider */
v = __raw_readl(dd-mult_div1_reg);
@@ -353,7 +355,7 @@ int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8
n, u16 freqsel)
int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
{
struct clk *new_parent = NULL;
- u16 freqsel;
+ u16 freqsel = 0;
struct dpll_data *dd;
int ret;
@@ -389,9 +391,13 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long
[PATCH 5/5] ARM: OMAP4: PM: Add init api for DPLL nodes
An api at init for all dpll nodes seem to be
needed to reparent the dpll clk node to its
bypass clk in case the dpll is in bypass.
If not done this causes sequencing issues at init
during propogate_rate.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/clock.c | 34 +-
arch/arm/mach-omap2/clock.h |1 +
arch/arm/mach-omap2/clock44xx.h |7 +++
3 files changed, 41 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 88b53b9..d0d4bb9 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -70,9 +70,41 @@
u8 cpu_mask;
/*-
- * OMAP2/3 specific clock functions
+ * OMAP2/3/4 specific clock functions
*-*/
+void omap2_init_dpll_parent(struct clk *clk)
+{
+ u32 v;
+ struct dpll_data *dd;
+
+ dd = clk-dpll_data;
+ if (!dd)
+ return;
+
+ /* Return bypass rate if DPLL is bypassed */
+ v = __raw_readl(dd-control_reg);
+ v = dd-enable_mask;
+ v = __ffs(dd-enable_mask);
+
+ /* Reparent in case the dpll is in bypass */
+ if (cpu_is_omap24xx()) {
+ if (v == OMAP2XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP2XXX_EN_DPLL_FRBYPASS)
+ clk_reparent(clk, dd-clk_bypass);
+ } else if (cpu_is_omap34xx()) {
+ if (v == OMAP3XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP3XXX_EN_DPLL_FRBYPASS)
+ clk_reparent(clk, dd-clk_bypass);
+ } else if (cpu_is_omap44xx()) {
+ if (v == OMAP4XXX_EN_DPLL_LPBYPASS ||
+ v == OMAP4XXX_EN_DPLL_FRBYPASS ||
+ v == OMAP4XXX_EN_DPLL_MNBYPASS)
+ clk_reparent(clk, dd-clk_bypass);
+ }
+ return;
+}
+
/**
* _omap2xxx_clk_commit - commit clock parent/rate changes in hardware
* @clk: struct clk *
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 29e6a1a..e914156 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -82,6 +82,7 @@ unsigned long omap2_fixed_divisor_recalc(struct clk *clk);
long omap2_clksel_round_rate(struct clk *clk, unsigned long target_rate);
int omap2_clksel_set_rate(struct clk *clk, unsigned long rate);
u32 omap2_get_dpll_rate(struct clk *clk);
+void omap2_init_dpll_parent(struct clk *clk);
int omap2_wait_clock_ready(void __iomem *reg, u32 cval, const char *name);
void omap2_clk_prepare_for_reboot(void);
int omap2_dflt_clk_enable(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock44xx.h b/arch/arm/mach-omap2/clock44xx.h
index 0f980df..957ede0 100644
--- a/arch/arm/mach-omap2/clock44xx.h
+++ b/arch/arm/mach-omap2/clock44xx.h
@@ -281,6 +281,7 @@ static struct clk dpll_abe_ck = {
.name = dpll_abe_ck,
.parent = abe_dpll_refclk_mux_ck,
.dpll_data = dpll_abe_dd,
+ .init = omap2_init_dpll_parent,
.ops= clkops_noncore_dpll_ops,
.recalc = omap3_dpll_recalc,
.round_rate = omap2_dpll_round_rate,
@@ -442,6 +443,7 @@ static struct clk dpll_core_ck = {
.name = dpll_core_ck,
.parent = dpll_sys_ref_clk,
.dpll_data = dpll_core_dd,
+ .init = omap2_init_dpll_parent,
.ops= clkops_null,
.recalc = omap3_dpll_recalc,
.flags = CLOCK_IN_OMAP4430,
@@ -668,6 +670,7 @@ static struct clk dpll_iva_ck = {
.name = dpll_iva_ck,
.parent = dpll_sys_ref_clk,
.dpll_data = dpll_iva_dd,
+ .init = omap2_init_dpll_parent,
.ops= clkops_noncore_dpll_ops,
.recalc = omap3_dpll_recalc,
.round_rate = omap2_dpll_round_rate,
@@ -730,6 +733,7 @@ static struct clk dpll_mpu_ck = {
.name = dpll_mpu_ck,
.parent = dpll_sys_ref_clk,
.dpll_data = dpll_mpu_dd,
+ .init = omap2_init_dpll_parent,
.ops= clkops_noncore_dpll_ops,
.recalc = omap3_dpll_recalc,
.round_rate = omap2_dpll_round_rate,
@@ -805,6 +809,7 @@ static struct clk dpll_per_ck = {
.name = dpll_per_ck,
.parent = dpll_sys_ref_clk,
.dpll_data = dpll_per_dd,
+ .init = omap2_init_dpll_parent,
.ops= clkops_noncore_dpll_ops,
.recalc = omap3_dpll_recalc,
.round_rate = omap2_dpll_round_rate,
@@ -927,6 +932,7 @@ static struct clk dpll_unipro_ck = {
.name = dpll_unipro_ck,
.parent = dpll_sys_ref_clk,
.dpll_data =
[PATCH 3/5] ARM: OMAP4: PM: Move DPLL control apis to dpll.c
This patch moves all the dpll control api's to a
common file dpll.c. This is in preperation of omap4
support wherein most of these api's can be reused.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/clock.h | 13 +
arch/arm/mach-omap2/clock34xx.c | 511 -
arch/arm/mach-omap2/clock34xx.h | 11 -
arch/arm/mach-omap2/clock44xx.c |8 +-
arch/arm/mach-omap2/clock44xx.h |4 -
arch/arm/mach-omap2/dpll.c | 539 +++
7 files changed, 558 insertions(+), 531 deletions(-)
create mode 100644 arch/arm/mach-omap2/dpll.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 229dac7..59a568c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -11,7 +11,8 @@ prcm-common = powerdomain.o
clock-common = clockdomain.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(clock-common)
-obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common)
+obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(clock-common) \
+ dpll.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 9ae7540..bc24687 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -36,6 +36,11 @@
#define OMAP3XXX_EN_DPLL_FRBYPASS 0x6
#define OMAP3XXX_EN_DPLL_LOCKED0x7
+/* CM_CLKEN_PLL*.EN* bit values - not all are available for every DPLL */
+#define DPLL_LOW_POWER_STOP0x1
+#define DPLL_LOW_POWER_BYPASS 0x5
+#define DPLL_LOCKED0x7
+
int omap2_clk_init(void);
int omap2_clk_enable(struct clk *clk);
void omap2_clk_disable(struct clk *clk);
@@ -44,6 +49,14 @@ int omap2_clk_set_rate(struct clk *clk, unsigned long rate);
int omap2_clk_set_parent(struct clk *clk, struct clk *new_parent);
int omap2_dpll_set_rate_tolerance(struct clk *clk, unsigned int tolerance);
long omap2_dpll_round_rate(struct clk *clk, unsigned long target_rate);
+unsigned long omap3_dpll_recalc(struct clk *clk);
+unsigned long omap3_clkoutx2_recalc(struct clk *clk);
+void omap3_dpll_allow_idle(struct clk *clk);
+void omap3_dpll_deny_idle(struct clk *clk);
+u32 omap3_dpll_autoidle_read(struct clk *clk);
+int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate);
+int omap3_noncore_dpll_enable(struct clk *clk);
+void omap3_noncore_dpll_disable(struct clk *clk);
#ifdef CONFIG_OMAP_RESET_CLOCKS
void omap2_clk_disable_unused(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 7c5c00d..be12879 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -316,12 +316,6 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, wdt1_fck, wdt1_fck, CK_343X),
};
-/* CM_AUTOIDLE_PLL*.AUTO_* bit values */
-#define DPLL_AUTOIDLE_DISABLE 0x0
-#define DPLL_AUTOIDLE_LOW_POWER_STOP 0x1
-
-#define MAX_DPLL_WAIT_TRIES100
-
#define MIN_SDRC_DLL_LOCK_FREQ 8300
#define CYCLES_PER_MHZ 100
@@ -412,394 +406,6 @@ static void omap3430es2_clk_hsotgusb_find_idlest(struct
clk *clk,
*idlest_bit = OMAP3430ES2_ST_HSOTGUSB_IDLE_SHIFT;
}
-/**
- * omap3_dpll_recalc - recalculate DPLL rate
- * @clk: DPLL struct clk
- *
- * Recalculate and propagate the DPLL rate.
- */
-static unsigned long omap3_dpll_recalc(struct clk *clk)
-{
- return omap2_get_dpll_rate(clk);
-}
-
-/* _omap3_dpll_write_clken - write clken_bits arg to a DPLL's enable bits */
-static void _omap3_dpll_write_clken(struct clk *clk, u8 clken_bits)
-{
- const struct dpll_data *dd;
- u32 v;
-
- dd = clk-dpll_data;
-
- v = __raw_readl(dd-control_reg);
- v = ~dd-enable_mask;
- v |= clken_bits __ffs(dd-enable_mask);
- __raw_writel(v, dd-control_reg);
-}
-
-/* _omap3_wait_dpll_status: wait for a DPLL to enter a specific state */
-static int _omap3_wait_dpll_status(struct clk *clk, u8 state)
-{
- const struct dpll_data *dd;
- int i = 0;
- int ret = -EINVAL;
-
- dd = clk-dpll_data;
-
- state = __ffs(dd-idlest_mask);
-
- while (((__raw_readl(dd-idlest_reg) dd-idlest_mask) != state)
- i MAX_DPLL_WAIT_TRIES) {
- i++;
- udelay(1);
- }
-
- if (i == MAX_DPLL_WAIT_TRIES) {
- printk(KERN_ERR clock: %s failed transition to '%s'\n,
- clk-name, (state) ? locked : bypassed);
- } else {
- pr_debug(clock: %s transition to '%s' in %d loops\n,
-clk-name, (state) ? locked : bypassed, i);
-
- ret =
Re: [PATCH] OMAP: omap_device: add to_omap_device() macro
On Tue, 24 Nov 2009, Kevin Hilman wrote: Following the model of to_platform_device(), add to_omap_device() macro so a platform_device pointer can be converted into an omap_device pointer. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Thanks, I'll add this to the rest of the hwmod patches for 2.6.33. - 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
Re: [PATCH 1/5] ARM: OMAP4: PM: Complete OMAP4 clock tree modelling
On Tue, Dec 01, 2009 at 05:57:24PM +0530, Rajendra Nayak wrote: This patch defines all the clock nodes in OMAP4430 platform. Autogenerated using a python script (gen_clock_tree.py) developed by Paul Walmsley, Benoit Cousson and Rajendra Nayak. Can we please get away from this idea of putting major structure definitions in header files? -- 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/5] ARM: OMAP4: PM: Complete OMAP4 clock tree modelling
Hi Russell, On Tue, 1 Dec 2009, Russell King - ARM Linux wrote: On Tue, Dec 01, 2009 at 05:57:24PM +0530, Rajendra Nayak wrote: This patch defines all the clock nodes in OMAP4430 platform. Autogenerated using a python script (gen_clock_tree.py) developed by Paul Walmsley, Benoit Cousson and Rajendra Nayak. Can we please get away from this idea of putting major structure definitions in header files? Any objections to calling the clock data file something like clock44xx_data.c, and including it into clock44xx.c the same way we currently do with the .h file? - 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
Re: [PATCH 1/3] OMAP: omap_device: fix nsec/usec conversion in latency calculations
On Mon, 23 Nov 2009, Kevin Hilman wrote: Use usecs = nsecs / NSEC_PER_USEC; instead of usecs = nsecs * NSEC_PER_USEC; Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Thanks, looks good. Will queue this up with the rest of the hwmod patches for .33. - 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
Re: [PATCH 2/3] OMAP: omap_device: track latency in nanoseconds
On Mon, 23 Nov 2009, Kevin Hilman wrote: Rather than having to do a usecs = nsecs / NSECS_PER_USEC to track latency in usecs, just track it in nanoseconds. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Thanks, looks good. Will queue this up with the rest of the hwmod patches for .33. - 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
Re: DSS2 Switch between multiple displays
On Tue, Dec 1, 2009 at 4:45 AM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, On Mon, 2009-11-30 at 20:26 +0100, ext Ashwin Bihari wrote: My system is going to have to support multiple display panels and switch between them using runtime checks. I've got two displays currently registered and confirmed with: # cat displays lcd e:1 u:1 t:0 h:480/2/2/41 v:272/2/6/10 p:1 r:0 i:0 lcd e:0 u:1 t:0 h:480/2/2/41 v:800/2/6/10 p:1 r:0 i:0 Short of adding a new module parameter for me to key off the panel_name to make the choice, is there some other way already implemented for me to indicate which display the DSS2 system should use as the default display panel? You are using an old version of DSS2. With later versions you can use omapdss.def_disp kernel parameter (see DSS documentation), or default_device field in omap_dss_board_info. Tomi Hi Tomi, Ahh Ok.. I was using the Kernel within Android 1.6 which is 2.6.29-rc3, good to know that there is a scheme for this in the later version. Hopefully when we make the jump to Android 2.0 and 2.6.31, we'll pick up the DSS2 changes as well. Regards -- Ashwin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 4/9] arm: omap: io: kill compile warning
when building omap4 defconfigs, io.c will warn about unused
_omap2_init_reprogram_sdrc, that's because that functio is
only used ifndef CONFIG_ARCH_OMAP4, so add the missing
ifndef CONFIG_ARCH_OMAP4 to _omap2_init_reprogram_sdrc
definition.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/io.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 6a4d8e4..a2be3ce 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -278,6 +278,7 @@ void __init omap2_map_common_io(void)
* -EINVAL if the dpll3_m2_ck cannot be found, 0 if called on OMAP2,
* or passes along the return value of clk_set_rate().
*/
+#ifndef CONFIG_ARCH_OMAP4
static int __init _omap2_init_reprogram_sdrc(void)
{
struct clk *dpll3_m2_ck;
@@ -301,6 +302,7 @@ static int __init _omap2_init_reprogram_sdrc(void)
return v;
}
+#endif
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
--
1.6.6.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 6/9] arm: omap: gpio: kill compile warning in gpio.c
when building linux-omap for omap1510, there will
be a compile warning about the unused flags variable
which is only used on 16xx and onwards.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/plat-omap/gpio.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 055160e..487c651 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1072,7 +1072,10 @@ static inline void _set_gpio_irqenable(struct gpio_bank
*bank, int gpio, int ena
*/
static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
{
+#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP24XX) || \
+ defined(CONFIG_ARCH_OMAP34XX) || defined(CONFIG_ARCH_OMAP4)
unsigned long flags;
+#endif
switch (bank-method) {
#ifdef CONFIG_ARCH_OMAP16XX
--
1.6.6.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 5/9] arm: omap: kill compile warning on board-4430-sdp.c
sdp4430_uart_config isn't used anywhere, so remove it.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/board-4430sdp.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 0c6be6b..a7788b4 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -38,10 +38,6 @@ static struct platform_device *sdp4430_devices[] __initdata
= {
sdp4430_lcd_device,
};
-static struct omap_uart_config sdp4430_uart_config __initdata = {
- .enabled_uarts = (1 0) | (1 1) | (1 2) | (1 3),
-};
-
static struct omap_lcd_config sdp4430_lcd_config __initdata = {
.ctrl_name = internal,
};
--
1.6.6.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 3/9] arm: omap: zoom: use vmmc1 regulator supply
the structure was there but it was used by the
twl4030 pdata. Just adding the missing field.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index f14baa3..221a8e3 100755
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -236,6 +236,7 @@ static struct twl4030_platform_data zoom_twldata = {
.gpio = zoom_gpio_data,
.keypad = zoom_kp_twl4030_data,
.codec = zoom_codec_data,
+ .vmmc1 = zoom_vmmc1,
.vmmc2 = zoom_vmmc2,
.vsim = zoom_vsim,
--
1.6.6.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 2/9] arm: omap: remove unused variables
those are never used, remove it until we need to
actually use them to avoid the compile warning.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/omap_hwmod_2430.h |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430.h
b/arch/arm/mach-omap2/omap_hwmod_2430.h
index 59a208b..49139ad 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430.h
+++ b/arch/arm/mach-omap2/omap_hwmod_2430.h
@@ -62,8 +62,6 @@ static struct omap_hwmod omap2430_l3_hwmod = {
};
static struct omap_hwmod omap2430_l4_wkup_hwmod;
-static struct omap_hwmod omap2430_mmc1_hwmod;
-static struct omap_hwmod omap2430_mmc2_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2430_l4_core__l4_wkup = {
--
1.6.6.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 9/9] arm: omap: mailbox: kill compile warning in mailbox.c
Change %d to %ld to avoid the compile warning.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/mailbox.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 281ab63..2c9fd1c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -93,7 +93,7 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
mbox_ick_handle = clk_get(NULL, mailboxes_ick);
if (IS_ERR(mbox_ick_handle)) {
- printk(KERN_ERR Could not get mailboxes_ick: %d\n,
+ printk(KERN_ERR Could not get mailboxes_ick: %ld\n,
PTR_ERR(mbox_ick_handle));
return PTR_ERR(mbox_ick_handle);
}
--
1.6.6.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 1/9] arm: omap: kill compile warning in irq.c
intc_context is only used when omap3 is to be built,
so also put it under ifdef CONFIG_ARM_OMAP3 to avoid
the compile warning.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/mach-omap2/irq.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index e9bc782..d370052 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -62,7 +62,9 @@ struct omap3_intc_regs {
u32 mir[INTCPS_NR_MIR_REGS];
};
+#ifdef CONFIG_ARCH_OMAP3
static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
+#endif
/* INTC bank register get/set */
--
1.6.6.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 7/9] arm: omap: innovator: kill compile warning on board-innovator.c
that address is used by struct map_desc, which expects
an unsigned long instead of a void __iomem *. Fix it.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/plat-omap/include/plat/fpga.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/fpga.h
b/arch/arm/plat-omap/include/plat/fpga.h
index f1864a6..87a87d2 100644
--- a/arch/arm/plat-omap/include/plat/fpga.h
+++ b/arch/arm/plat-omap/include/plat/fpga.h
@@ -85,7 +85,7 @@ struct h2p2_dbg_fpga {
* OMAP-1510 FPGA
* ---
*/
-#define OMAP1510_FPGA_BASE IOMEM(0xE800) /* VA */
+#define OMAP1510_FPGA_BASE 0xE800 /* VA */
#define OMAP1510_FPGA_SIZE SZ_4K
#define OMAP1510_FPGA_START0x0800 /* PA */
--
1.6.6.rc0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 0/9] omap warning cleanup
The following series removes a few compile warnings from omap builds. It was compile tested with all omap defconfigs for the ones who have the boards, a boot test would be nice, although there aren't any functional changes. Felipe Balbi (9): arm: omap: kill compile warning in irq.c arm: omap: remove unused variables arm: omap: zoom: use vmmc1 regulator supply arm: omap: io: kill compile warning arm: omap: kill compile warning on board-4430-sdp.c arm: omap: gpio: kill compile warning in gpio.c arm: omap: innovator: kill compile warning on board-innovator.c arm: omap: perseus: kill compile warning on board-perseus2.c arm: omap: mailbox: kill compile warning in mailbox.c arch/arm/mach-omap2/board-4430sdp.c |4 arch/arm/mach-omap2/board-zoom-peripherals.c |1 + arch/arm/mach-omap2/io.c |2 ++ arch/arm/mach-omap2/irq.c|2 ++ arch/arm/mach-omap2/mailbox.c|2 +- arch/arm/mach-omap2/omap_hwmod_2430.h|2 -- arch/arm/plat-omap/gpio.c|3 +++ arch/arm/plat-omap/include/plat/fpga.h |4 ++-- 8 files changed, 11 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[rfc/rft/patch 8/9] arm: omap: perseus: kill compile warning on board-perseus2.c
that address is used by struct map_desc, which expects an unsigned long instead of a void __iomem *. Fix it. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- arch/arm/plat-omap/include/plat/fpga.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/fpga.h b/arch/arm/plat-omap/include/plat/fpga.h index 87a87d2..d66164d 100644 --- a/arch/arm/plat-omap/include/plat/fpga.h +++ b/arch/arm/plat-omap/include/plat/fpga.h @@ -34,7 +34,7 @@ extern void omap1510_fpga_init_irq(void); * --- */ /* maps in the FPGA registers and the ETHR registers */ -#define H2P2_DBG_FPGA_BASE IOMEM(0xE800) /* VA */ +#define H2P2_DBG_FPGA_BASE 0xE800 /* VA */ #define H2P2_DBG_FPGA_SIZE SZ_4K /* SIZE */ #define H2P2_DBG_FPGA_START0x0400 /* PA */ -- 1.6.6.rc0 -- 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: [PATCHV3 2/4] OMAP3: Clock Type change for OMAP3 Clocks
Hello Vishwanath, On Tue, 1 Dec 2009, Sripathy, Vishwanath wrote: -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Monday, November 30, 2009 1:57 PM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org Subject: Re: [PATCHV3 2/4] OMAP3: Clock Type change for OMAP3 Clocks Hi Vishwanath, On Thu, 26 Nov 2009, Vishwanath BS wrote: In omap34xx_clks, CK_343X type is used by all OMAP3 family of processors. It makes more sense to name clock type as CK_3XXX since it is common to all OMAP3 processors. Hmmm. Do all of the CK_3XXX clocks apply to AM3503/3517? Currently all OMAP3 chip families are using CK_343X as the common clock and this clock has been renamed to CK_3XXX. So CK_3XXX should be applicable for all. Just based on a quick spot-check, there are several clocks that this patch marks as CK_3XXX that are really only applicable to the 34xx and 36xx families. For example: - CLK(NULL, sdrc_ick, sdrc_ick, CK_343X), + CLK(NULL, sdrc_ick, sdrc_ick, CK_3XXX), - CLK(NULL, iva2_ck, iva2_ck, CK_343X), + CLK(NULL, iva2_ck, iva2_ck, CK_3XXX), We should not mark clocks that are not present on 3503/3517 as being present on 3XXX, otherwise this chip numbering scheme will become even more perplexing than it currently is. How about adding RATE_IN_36XX or CK_36XX as appropriate? - 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
Re: [PATCH v3 1/2] arm: a driver for on-chip ETM and ETB
On Mon, Nov 09, 2009 at 01:48:10 +0200, Artem Bityutskiy wrote: On Fri, 2009-10-30 at 14:10 +0200, Alexander Shishkin wrote: On Thu, Oct 22, 2009 at 07:51:54PM +0300, Alexander Shishkin wrote: Changes: v3 -- major update: * switched from platform device to AMBA device * started using clk API in a more proper way * changed omap3 Kconfig part to select the driver instead of depending on it Russell, I believe this one addresses your concerns about my previous patches. Shall I wait for more comments from you or do you want me to upload them to your patch tracker? Alex, I suggest you to: 1. Double check that you really addressed _everything_ Russel and others pointed - may be this is the reason why your patch is stuck. 2. If you have addressed everything, upload the patch to the patch system. My (very limited) experience was that I re-sent a patch several times, got no response for long time, but then Russel simply asked me to upload it, and it was merged. Thus, the silence may simply mean upload to the patch system. Thanks for the hint. I've double checked the patches and I'm fairly sure I have addressed all of the concerns expressed to the best of my ability. So I did as you said: uploaded the patches to the patch tracker. Regards, -- Alex -- 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/rft/patch 3/9] arm: omap: zoom: use vmmc1 regulator supply
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe Balbi
Sent: Tuesday, December 01, 2009 6:34 PM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh; Kevin
Hilman; Kalle Valo; Jean Pihet; Pandita, Vikram; Paul
Walmsley; Hiroshi DOYU; David Brownell; Felipe Balbi
Subject: [rfc/rft/patch 3/9] arm: omap: zoom: use vmmc1
regulator supply
the structure was there but it was used by the
twl4030 pdata. Just adding the missing field.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
I had already posted this patch.
- Anand
http://marc.info/?l=linux-omapm=125855155611214w=2
---
arch/arm/mach-omap2/board-zoom-peripherals.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index f14baa3..221a8e3 100755
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -236,6 +236,7 @@ static struct twl4030_platform_data
zoom_twldata = {
.gpio = zoom_gpio_data,
.keypad = zoom_kp_twl4030_data,
.codec = zoom_codec_data,
+ .vmmc1 = zoom_vmmc1,
.vmmc2 = zoom_vmmc2,
.vsim = zoom_vsim,
--
1.6.6.rc0
--
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/rft/patch 3/9] arm: omap: zoom: use vmmc1 regulator supply
Hi, On Tue, Dec 01, 2009 at 02:08:26PM +0100, ext Gadiyar, Anand wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Tuesday, December 01, 2009 6:34 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh; Kevin Hilman; Kalle Valo; Jean Pihet; Pandita, Vikram; Paul Walmsley; Hiroshi DOYU; David Brownell; Felipe Balbi Subject: [rfc/rft/patch 3/9] arm: omap: zoom: use vmmc1 regulator supply the structure was there but it was used by the twl4030 pdata. Just adding the missing field. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com I had already posted this patch. sorry for that... let's drop this one then -- balbi -- 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: ACPI notifier chain?
Hi Tarek, On Tue, 2009-12-01 at 12:42 +0100, ext tarek attia wrote: Hi Ameya, I believe ACPI is a standard that doesn't matter it's X86 or ARM ,and it's responsible for power states (S,C,D and P states) ,,and Linux kernel implemented this standard . Am I right ?? You are absolutely right :) It is a specification which can be implemented by a hardware. I think the hardware which supports ACPI is mostly i386, x86_64, and ia64. Also you can see that from drivers/acpi/Kconfig that linux acpi depends on above mentioned hardware. # # ACPI Configuration # menuconfig ACPI bool ACPI (Advanced Configuration and Power Interface) Support depends on !IA64_HP_SIM depends on IA64 || X86 depends on PCI depends on PM BTW :- if it's not like so,,How can I monitor the power changes on the peripherals like LCD connected to my beagleboard ?? How can I make the power management for the peripherals ?? I am not an expert in PM area. But may be this will be helpful: http://elinux.org/OMAP_Power_Management Cheers, Ameya. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/2] omap: serial: handle abort on empty rx fifo read
Pandita, Vikram wrote: introduce OMAP3_HAS_UART_NO_EMPTY_FIFO_READ feature this feature is set for omap3630 and omap4 currently as empty uart rx fifo read causes an abort check on this feature on omap3630 and omap4 for now and extend for future vairants in future Patch history: V1: initial implementation http://patchwork.kernel.org/patch/60785/ http://patchwork.kernel.org/patch/60786/ V2: incorporate review comments from Alan Cox http://patchwork.kernel.org/patch/60785/ to remove 8250.c file changes by override serial_in No 8250 driver change required now V3: incorporate review comments khilman: make function override only for affected silicons nishant m: interoduce has_feature check, rather than cpu_is anand g: minor commit message change Vikram Pandita (2): omap: introduce uart_no_empty_fifo_read feature omap: serial: fix non-empty uart fifo read abort arch/arm/mach-omap2/id.c |7 +++ arch/arm/mach-omap2/serial.c | 21 + arch/arm/plat-omap/include/plat/cpu.h |2 ++ 3 files changed, 30 insertions(+), 0 deletions(-) Ping? Tony, These two patches are the only ones pending to make 3630 platforms boot up nicely. Would you consider taking them? - Anand -- 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/5] ARM: OMAP4: PM: Complete OMAP4 clock tree modelling
On Tue, Dec 01, 2009 at 05:51:39AM -0700, Paul Walmsley wrote: Hi Russell, On Tue, 1 Dec 2009, Russell King - ARM Linux wrote: On Tue, Dec 01, 2009 at 05:57:24PM +0530, Rajendra Nayak wrote: This patch defines all the clock nodes in OMAP4430 platform. Autogenerated using a python script (gen_clock_tree.py) developed by Paul Walmsley, Benoit Cousson and Rajendra Nayak. Can we please get away from this idea of putting major structure definitions in header files? Any objections to calling the clock data file something like clock44xx_data.c, and including it into clock44xx.c the same way we currently do with the .h file? How about having clock44xx_data.c as you suggest, moving the clkdev definitions into there, along with the registration of the clocks, and have it as an entirely separate .c file with no #include games? -- 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: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype
Paul
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Monday, November 30, 2009 3:00 PM
To: Sripathy, Vishwanath
Cc: ext-ari.kau...@nokia.com; linux-omap@vger.kernel.org; Woodruff, Richard;
Menon, Nishanth
Subject: Re: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype
Hello Vishwanath,
a few comments:
On Thu, 26 Nov 2009, Vishwanath BS wrote:
From: Richard Woodruff r-woodru...@ti.com
DPLL4 for 3630 introduces a changed block requiring special divisor bits and
additional reg fields. To allow for silicons to use this, this is introduced
as a omap3_has_jtype_dpll4() and is enabled for 3630 silicon
Tested with 3630 ZOOM3
Could you please consider Ari Kauppi's suggestions that he posted on
30 and 31 October? They look good to me. Here is a link:
Regarding comments from Ari Kauppi on addition of dco_sel_mask and sd_div_mask,
yes I had a look at them. However I feel, it's better to have these masks in
the structure variable. Reason being this approach will help us to support when
dpll types for other dplls get changed in future. For example, if dpll3 block
is changed, then having new mask will help us to support it.
http://patchwork.kernel.org/patch/55009/
Also, finally got the 3630 documents, so some more detailed comments are
now possible:
- One thing that is confusing is that the 3630 Rev A TRM (SWPU176A)
conflicts with the 34xx-36xx Delta TRM (SWPU204). For example, the delta
TRM claims that the FREQSEL bits are all removed, but the 3630 TRM claims
that they are still present. Could you find out which one is correct? If
no FREQSEL bits are present, then the clock code shouldn't write to them.
3630 TRM (Rev A) shows that FREQSEL is no longer present for Per DPLL
(CM_CLKEN_PLL [23:20] is reserved). So we should not write freqsel for PER
dpll.
- Table 3-13 in the delta TRM claims that the DPLL4 multiplier bitfield
can now go to 4096. [This looks like an off-by-one error in the
documentation, since only 12 bits are available, so the max is (2^12 - 1)
= 4095.] But the important point for this patch is that the struct
dpll_data.max_multiplier field for DPLL4 needs to be increased.
I confirmed that DPLL4 Multiplier is 12 bits. So max value is 4095.
A few more questions below:
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 51
++-
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/id.c|4 ++-
arch/arm/plat-omap/include/plat/clock.h |3 ++
arch/arm/plat-omap/include/plat/cpu.h |3 +-
5 files changed, 63 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
omap2/clock34xx.c
index da5bc1f..832ed0b 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -679,6 +679,41 @@ static void omap3_noncore_dpll_disable(struct clk *clk)
_omap3_noncore_dpll_stop(clk);
}
+/**
+ * lookup_dco_sddiv - Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16
+ m, u8 n)
+ {
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+
+ clkinp = clk-parent-rate;
+ fint = (clkinp / n) * m;
+
+ if (fint 10)
+ *dco = 2;
+ else
+ *dco = 4;
+ /*
+* target sigma-delta to near 250MHz
+* sd = ceil[(m/(n+1)) * (clkinp_MHz / 250)]
+*/
+ clkinp /= 10; /* shift from MHz to 10*Hz for 38.4 and 19.2*/
+ mod1 = (clkinp * m) % (250 * n);
+ sd = (clkinp * m) / (250 * n);
+ mod2 = sd % 10;
+ sd /= 10;
+
+ if (mod1 + mod2)
+ sd++;
+ *sd_div = sd;
+}
/* Non-CORE DPLL rate set code */
@@ -711,6 +746,13 @@ static int omap3_noncore_dpll_program(struct clk *clk,
u16 m, u8 n, u16 freqsel)
v = ~(dd-mult_mask | dd-div1_mask);
v |= m __ffs(dd-mult_mask);
v |= (n - 1) __ffs(dd-div1_mask);
+ if (dd-jtype) {
+ u8 dco, sd_div;
+ lookup_dco_sddiv(clk, dco, sd_div, m, n);
+ v = ~(dd-dco_sel_mask | dd-sd_div_mask);
+ v |= dco __ffs(dd-dco_sel_mask);
+ v |= sd_div __ffs(dd-sd_div_mask);
+ }
__raw_writel(v, dd-mult_div1_reg);
/* We let the clock framework set the other output dividers later */
@@ -1026,7 +1068,7 @@ static unsigned long omap3_clkoutx2_recalc(struct clk
*clk)
v = __raw_readl(dd-control_reg)
Re: FEATURES - is it good enough
On Fri, Nov 20, 2009 at 02:09:01 -0600, Nishanth Menon wrote: Aguirre, Sergio had written, on 11/20/2009 01:43 PM, the following: -Original Message- From: Menon, Nishanth Sent: Friday, November 20, 2009 1:24 PM To: Kevin Hilman Cc: Shilimkar, Santosh; Aguirre, Sergio; Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: FEATURES - is it good enough Kevin Hilman had written, on 11/20/2009 12:35 PM, the following: Shilimkar, Santosh santosh.shilim...@ti.com writes: [...] Probably not something ot be attached in this patch, but... I'm a bit curious about something: Why touching omap3_features in OMAP4? Isn't there a omap4_features? Or even better, an omap_features? This is_feature suppose to take care of Errata's also, is it? It's not a bug it's a feature. :) Bug. Santosh pointed out internally to h/w discussion which clearly shows this as a h/w limitation. (thanks santosh) This is errata more than a feature. We better differentiate in this regard I agree, I have a hard time calling this empty fifo read fault a feature. We need a similar thing for errata. Agreed. This is a classic example why we need a common errata handling mechanism scalable across silicon variants on an IP basis. two problems in front of us: a) what do we want to do with 8250 workaround needed for omap3630 and omap4? can we go ahead with features marking it clearly as a misuse of features for the time being IMHO, That for the time being will stay forever if we don't do something now. Most of the big problems are raised because someone says ok, lets have this for the time being. But that time never comes. See that crazy CaMeL-Casing hanging around in /drivers/dsp/bridge/ for a while as an example. When that will ever be fixed? I bet someone said some time: ok, lets fix it later :-) On the other hand. What's the big motivation to have this as a feature? Who else than the serial driver cares about the feature awareness? please see [1] and [2]. this wont be the first time I published something previously that got ignored and got re-discussed. note: The [1] proposal sounds interesting to me, but it's not a very trivial matter. BTW, to be fair, DSPBridge already has plans to get fixed anyways.. Options I can think which were discussed: a) introduce omap3_features omap3_errata: negative: wont read like if I use omap3_has_errata() for OMAP4 code. b) introduce omap_features and omap_errata: negative: how do you link this to IP based usage across silicon (e.g. I2C). How about omap_has_errata(module, errata)? Or even something more generic? Regards, -- Alex -- 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/rft/patch 7/9] arm: omap: innovator: kill compile warning on board-innovator.c
* Felipe Balbi felipe.ba...@nokia.com [091201 05:03]:
that address is used by struct map_desc, which expects
an unsigned long instead of a void __iomem *. Fix it.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
arch/arm/plat-omap/include/plat/fpga.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/fpga.h
b/arch/arm/plat-omap/include/plat/fpga.h
index f1864a6..87a87d2 100644
--- a/arch/arm/plat-omap/include/plat/fpga.h
+++ b/arch/arm/plat-omap/include/plat/fpga.h
@@ -85,7 +85,7 @@ struct h2p2_dbg_fpga {
* OMAP-1510 FPGA
*
---
*/
-#define OMAP1510_FPGA_BASE IOMEM(0xE800) /* VA */
+#define OMAP1510_FPGA_BASE 0xE800 /* VA */
#define OMAP1510_FPGA_SIZE SZ_4K
#define OMAP1510_FPGA_START 0x0800 /* PA */
Instead of removing the IOMEM, can you please move it to the
OMAP1510_FPGA_START physical address where it should be?
Thanks,
Tony
--
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/rft/patch 8/9] arm: omap: perseus: kill compile warning on board-perseus2.c
* Felipe Balbi felipe.ba...@nokia.com [091201 05:03]: that address is used by struct map_desc, which expects an unsigned long instead of a void __iomem *. Fix it. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- arch/arm/plat-omap/include/plat/fpga.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/fpga.h b/arch/arm/plat-omap/include/plat/fpga.h index 87a87d2..d66164d 100644 --- a/arch/arm/plat-omap/include/plat/fpga.h +++ b/arch/arm/plat-omap/include/plat/fpga.h @@ -34,7 +34,7 @@ extern void omap1510_fpga_init_irq(void); * --- */ /* maps in the FPGA registers and the ETHR registers */ -#define H2P2_DBG_FPGA_BASE IOMEM(0xE800) /* VA */ +#define H2P2_DBG_FPGA_BASE 0xE800 /* VA */ #define H2P2_DBG_FPGA_SIZE SZ_4K /* SIZE */ #define H2P2_DBG_FPGA_START 0x0400 /* PA */ The IOMEM should be moved here too to H2P2_DBG_FPGA_START. Tony -- 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
I2C broken on OMAP 2430SDP?
Hi, just wanted to mention that i2c-omap.c has some problems on the 2430SDP with the linux-omap kernel running Linux 2.6.32-rc8, commit 4355c41a635943d30e9396b95185314343dcb551. This shows up at boot: bio: create slab bio-0 at 0 6i2c_omap i2c_omap.1: bus 1 rev3.6 at 400 kHz 6i2c_omap i2c_omap.2: bus 2 rev3.6 at 2600 kHz 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio SIH_CTRL 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing keypad IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing keypad SIH_CTRL 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing bci IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing madc IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing power IMR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing power SIH_CTRL 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing gpio ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing keypad ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing keypad ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing bci ISR 4i2c_omap i2c_omap.2: timeout waiting for bus ready 4i2c_omap i2c_omap.2: timeout waiting for bus ready 3twl4030: err -110 initializing bci ISR ... This is with omap_2430sdp_defconfig. - 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
RE: omap3evm: touchscreen delays on pm branch
-Original Message- From: Sriram V [mailto:vshrir...@gmail.com] Sent: Tuesday, December 01, 2009 3:36 PM To: V, Hemanth Cc: Premi, Sanjeev; Dasgupta, Romit; linux-omap@vger.kernel.org Subject: Re: omap3evm: touchscreen delays on pm branch Hi, Have you enabled CPUFREQ? We faced a similar issue and was due to ondemand governor. Selecting performance governors solved the issue. Nope. No cpufreq. I did notice that CPIO175 was not being set properly; have made local changes. It is a definite improvement; but there are still very noticeable delays. I will post the GPIO related patches in a few days; currently drowned in few debug issues :( Best regards, Sanjeev Regards, sriram On Fri, Nov 27, 2009 at 4:04 PM, Hemanth V heman...@ti.com wrote: - Original Message - From: Premi, Sanjeev pr...@ti.com To: Dasgupta, Romit ro...@ti.com Cc: linux-omap@vger.kernel.org Sent: Friday, November 27, 2009 3:20 PM Subject: RE: omap3evm: touchscreen delays on pm branch -Original Message- From: Dasgupta, Romit Sent: Friday, November 27, 2009 2:38 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: RE: omap3evm: touchscreen delays on pm branch On Fri, 2009-11-27 at 14:11 +0530, Premi, Sanjeev wrote: -Original Message- From: Dasgupta, Romit Sent: Friday, November 27, 2009 2:10 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: omap3evm: touchscreen delays on pm branch Premi, Sanjeev wrote: Hi, I am finding the response of touchscreen on the omap3evm very slow. Here is my test: On console, I run : watch -n2 cat /proc/interrupts Then, I tap the touchscreen approximately once per second. However, (usually) no interrupts are registered. As I increase the frequency of 'taps' more and more interrupts are registered. But still not matching exact taps. However, when I keep the cpu busy with cat /dev/zero /dev/null each tap is recognized. Do you see this even if we don't enable OFF? Yes. Sleep_while_idle=0; enable_off_mode=0 ~sanjeev Hopefully you have the same TSC driver. Nevertheless, can you please try this (just to see if clock domain idling is causing any problem or not): It is the same driver at SDP3430. I had earlier tried removing cpuidle altogether and did not see this issue. I too believe that issue is caused by clocks being going to (auto)idle. But then, Hemanth should be seeing the same behavior. Zoom2/Zoom3 use a different touchscreen driver compared to SDP. Its uses Synaptic Touchscreen over I2C. -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] omap: serial: handle abort on empty rx fifo read
On Tue, Dec 01, 2009 at 06:50:31 +0530, Gadiyar, Anand wrote: Pandita, Vikram wrote: introduce OMAP3_HAS_UART_NO_EMPTY_FIFO_READ feature this feature is set for omap3630 and omap4 currently as empty uart rx fifo read causes an abort check on this feature on omap3630 and omap4 for now and extend for future vairants in future Patch history: V1: initial implementation http://patchwork.kernel.org/patch/60785/ http://patchwork.kernel.org/patch/60786/ V2: incorporate review comments from Alan Cox http://patchwork.kernel.org/patch/60785/ to remove 8250.c file changes by override serial_in No 8250 driver change required now V3: incorporate review comments khilman: make function override only for affected silicons nishant m: interoduce has_feature check, rather than cpu_is anand g: minor commit message change Vikram Pandita (2): omap: introduce uart_no_empty_fifo_read feature omap: serial: fix non-empty uart fifo read abort arch/arm/mach-omap2/id.c |7 +++ arch/arm/mach-omap2/serial.c | 21 + arch/arm/plat-omap/include/plat/cpu.h |2 ++ 3 files changed, 30 insertions(+), 0 deletions(-) Ping? Tony, These two patches are the only ones pending to make 3630 platforms boot up nicely. Would you consider taking them? Tested. ---cut--- [0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp uart_no_empty_fifo_read ) ---cut--- Acked-by: Alexander Shishkin virtu...@slind.org Regards, -- Alex -- 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: SR1: VDD autocomp is not active
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sergey Lapin Sent: Tuesday, December 01, 2009 5:24 PM To: linux-omap@vger.kernel.org Subject: SR1: VDD autocomp is not active Hi, all! on my OMAP3525-based custom board I get SR1: VDD autocomp is not active and SR2: VDD autocomp is not active quite frequently with PM branch. What that means, and how to fix it? Do you see them while trying to set the sr_vdd[1|2]_autocomp? OR During normal execution? What is the silicon version reported when Linux kernel boot up? ~sanjeev Thanks a lot, S. -- 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 -- 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: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Eino-Ville Talvala Sent: Tuesday, December 01, 2009 4:55 AM To: Hiremath, Vaibhav Cc: Tomi Valkeinen; linux-omap@vger.kernel.org Subject: Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation On 11/29/2009 9:47 PM, Hiremath, Vaibhav wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen Sent: Thursday, November 26, 2009 7:50 PM To: ext Eino-Ville Talvala Cc: linux-omap@vger.kernel.org Subject: Re: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation Hi, On Wed, 2009-11-25 at 01:14 +0100, ext Eino-Ville Talvala wrote: Hi, I'm trying to get Xorg running on an Angstrom distro image on the OMAP3 EVM, with a rotated framebuffer. The default screen orientation on the EVM is portrait, and I'm trying to change this to landscape. Without any tweaking, using a kernel with your latest v5 DSS patches added on top (and Vaibhav's OMAP3 EVM DSS patches), DSS works and Angstrom happily displays both its initial bootup screen, and then the X server starts successfully. Using the omapfb.rotate=1 kernel command-line option, the initial bootup screen still works, but as soon as the X server tries to start up, I get the following error on the console: Starting GPE display manager: gpe-dm omapdss MANAGER error: dispc_setup_plane failed for ovl 0 omapdss MANAGER error: configure_overlay 0 failed It sounds to me that gpe-dm (or something running after that) is trying to configure the overlay to 480x640 mode, and failing. If the initial [Hiremath, Vaibhav] I think this is the issue, I have seen many peoples doing same mistakes, and it ends up to the application, which doesn't care about rotation and tries to set 480x640 in all rotation angles. The xorg boot log appears reasonably sane until a crash - 640x480 is what the xf86 omapfb driver picks up, so I assume something else is the problem. I'll try to poke at the omapfb source some to see if something is being passed around wrong - I'd appreciate any suggestions on where to look. === ... (II) LoadModule: omapfb (II) Loading /usr/lib/xorg/modules/drivers//omapfb_drv.so (II) Module omapfb: vendor=X.Org Foundation compiled for 1.6.1, module version = 0.1.1 ABI class: X.Org Video Driver, version 5.0 (II) omapfb: Driver for OMAP framebuffer (omapfb) and external LCD controllers: omap1/2/3, S1D13745, HWA742 (WW) Falling back to old probe method for OMAPFB (II) Running in FRAMEBUFFER Mode (WW) Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or direc tory (WW) Can't autodetect LCD controller, assuming internal (II) LCD controller: internal (II) omapfb(0): VideoRAM: 1920KiB (SDRAM) (--) omapfb(0): Depth 16, (==) framebuffer bpp 16 (==) omapfb(0): RGB weight 565 (==) omapfb(0): Default visual is TrueColor (--) omapfb(0): Virtual size is 640x480 (pitch 640) (**) omapfb(0): Built-in mode current (==) omapfb(0): DPI set to (96, 96) (II) Loading sub module fb (II) LoadModule: fb (II) Loading /usr/lib/xorg/modules//libfb.so (II) Module fb: vendor=X.Org Foundation compiled for 1.6.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) omapfb(0): DPMS enabled (II) omapfb(0): Video plane capabilities: (II) omapfb(0): Video plane supports the following image formats: (II) omapfb(0): XVideo extension initialized (==) RandR enabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE Backtrace: 0: Xorg(xorg_backtrace+0x28) [0xd2540] Fatal server error: Caught signal 11. Server aborting === Does your xorg.conf enable GLX? You may want to try disabling it. ~sanjeev Thanks, Eino-Ville Talvala Stanford University -- 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 -- To unsubscribe from this list: send
Re: SR1: VDD autocomp is not active
On Tue, Dec 1, 2009 at 7:08 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sergey Lapin Sent: Tuesday, December 01, 2009 5:24 PM To: linux-omap@vger.kernel.org Subject: SR1: VDD autocomp is not active Hi, all! on my OMAP3525-based custom board I get SR1: VDD autocomp is not active and SR2: VDD autocomp is not active quite frequently with PM branch. What that means, and how to fix it? Do you see them while trying to set the sr_vdd[1|2]_autocomp? OR During normal execution? During normal execution. What is the silicon version reported when Linux kernel boot up? OMAP3525 ES2.1 (l2cache iva neon isp ) S. -- 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 15/20] DSPBRIDGE: trivial cleanup and indentation for io_sm
From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
On Mon, Nov 30, 2009 at 11:54 PM, Omar Ramirez Luna omar.rami...@ti.com
wrote:
Remove duplicate set of braces from if statement and reduce
indentation.
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index af31831..96a5aa6 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -115,7 +115,7 @@ struct IO_MGR {
/* private extnd proc info; mmu setup */
struct MGR_PROCESSOREXTINFO extProcInfo;
struct CMM_OBJECT *hCmmMgr; /* Shared Mem Mngr */
May be to fix commentary indentation?
- struct work_struct io_workq; /*workqueue */
+ struct work_struct io_workq; /*workqueue */
I didn't get why the space after /* still absent.
Removed on the next patch (trivial fix for multiline comments on io_sm)
- struct CMM_OBJECT *hCmmMgr; /* Shared Mem Mngr*/
- struct work_struct io_workq; /*workqueue */
+ struct CMM_OBJECT *hCmmMgr; /* Shared Mem Mngr */
+ struct work_struct io_workq; /* workqueue */
@@ -319,7 +321,7 @@ DSP_STATUS WMD_IO_Destroy(struct IO_MGR *hIOMgr)
SYNC_DeleteCS(hIOMgr-hCSObj); /* Leak Fix. */
/* Free this IO manager object: */
MEM_FreeObject(hIOMgr);
- } else
+ } else
status = DSP_EHANDLE;
Probably } else { ... } would be better. (1)
Agree
@@ -609,7 +608,7 @@ func_cont1:
}
}
- /* Copy remaining entries from CDB. All entries are 1 MB and should
not
+ /* Copy remaining entries from CDB. All entries are 1 MB and should
not
* conflict with SHM entries on MPU or DSP side */
In previous hunks you fixed * ... */. Why not here? (2)
trivial fix for multiline comments on io_sm, I tried to split the two patches
because I thought there would be a lot of changes
0015-DSPBRIDGE-trivial-cleanup-and-indentation-for-io_sm.patch
0016-DSPBRIDGE-trivial-fix-for-multiline-comments-on-io_.patch
But I guess I can join them into one patch and resend (btw fixed on patch 16)
@@ -1002,15 +995,10 @@ void IO_DPC(IN OUT void *pRefData)
PrintDSPDebugTrace(pIOMgr);
}
#endif
-
-#ifndef DSP_TRACEBUF_DISABLED
- PrintDSPDebugTrace(pIOMgr);
-#endif
func_end:
return;
No comments about this changes. (Intuitively I understand, but...)
@@ -1028,29 +1016,28 @@ irqreturn_t IO_ISR(int irq, IN void *pRefData)
}
- } else
+ } else
/* Ensure that, if WMD didn't claim it, the IRQ is shared. */
DBC_Ensure(hIOMgr-fSharedIRQ);
The same as in (1).
Agree
@@ -1380,10 +1365,10 @@ static void NotifyChnlComplete(struct CHNL_OBJECT
*pChnl,
!pChnl-pIOCompletions || !pChirp)
goto func_end;
- /* Note: we signal the channel event only if the queue of IO
- * completions is empty. If it is not empty, the event is sure to
be
- * signalled by the only IO completion list consumer:
- * WMD_CHNL_GetIOC(). */
+ /* Note: we signal the channel event only if the queue of IO
+ * completions is empty. If it is not empty, the event is sure to
be
+ * signalled by the only IO completion list consumer:
+ * WMD_CHNL_GetIOC(). */
The same as in (2).
Fixed on patch 16, will join both of the patches and resend
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/9] arm: omap: innovator: kill compile warning on board-innovator.c
that address is used by struct map_desc, which expects
an unsigned long instead of a void __iomem *. Fix it.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
Is this what you mean ??
arch/arm/plat-omap/include/plat/fpga.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/fpga.h
b/arch/arm/plat-omap/include/plat/fpga.h
index f1864a6..db2af50 100644
--- a/arch/arm/plat-omap/include/plat/fpga.h
+++ b/arch/arm/plat-omap/include/plat/fpga.h
@@ -85,9 +85,9 @@ struct h2p2_dbg_fpga {
* OMAP-1510 FPGA
* ---
*/
-#define OMAP1510_FPGA_BASE IOMEM(0xE800) /* VA */
+#define OMAP1510_FPGA_BASE 0xE800 /* VA */
#define OMAP1510_FPGA_SIZE SZ_4K
-#define OMAP1510_FPGA_START0x0800 /* PA */
+#define OMAP1510_FPGA_STARTIOMEM(0x0800) /* PA */
/* Revision */
#define OMAP1510_FPGA_REV_LOW (OMAP1510_FPGA_BASE + 0x0)
--
1.6.6.rc0
--
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/9] arm: omap: perseus: kill compile warning on board-perseus2.c
that address is used by struct map_desc, which expects an unsigned long instead of a void __iomem *. Fix it. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- arch/arm/plat-omap/include/plat/fpga.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/fpga.h b/arch/arm/plat-omap/include/plat/fpga.h index db2af50..99edbf8 100644 --- a/arch/arm/plat-omap/include/plat/fpga.h +++ b/arch/arm/plat-omap/include/plat/fpga.h @@ -34,9 +34,9 @@ extern void omap1510_fpga_init_irq(void); * --- */ /* maps in the FPGA registers and the ETHR registers */ -#define H2P2_DBG_FPGA_BASE IOMEM(0xE800) /* VA */ +#define H2P2_DBG_FPGA_BASE 0xE800 /* VA */ #define H2P2_DBG_FPGA_SIZE SZ_4K /* SIZE */ -#define H2P2_DBG_FPGA_START0x0400 /* PA */ +#define H2P2_DBG_FPGA_STARTIOMEM(0x0400) /* PA */ #define H2P2_DBG_FPGA_ETHR_START (H2P2_DBG_FPGA_START + 0x300) #define H2P2_DBG_FPGA_FPGA_REV (H2P2_DBG_FPGA_BASE + 0x10) /* FPGA Revision */ -- 1.6.6.rc0 -- 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 00/20] dspbridge cleanups
-Original Message- From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] Sent: Tuesday, December 01, 2009 12:50 AM To: Ramirez Luna, Omar Cc: linux-omap; Artem Bityutskiy; Felipe Balbi; Felipe Contreras; Hiroshi Doyu; Menon, Nishanth Subject: Re: [PATCH v2 00/20] dspbridge cleanups On Mon, Nov 30, 2009 at 11:54 PM, Omar Ramirez Luna omar.rami...@ti.com wrote: arch/arm/plat-omap/include/dspbridge/list.h | 36 +- DSPBRIDGE: trivial file history cleanup for headers @@ -14,39 +17,6 @@ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ - -/* - * list.h - * Purpose: - * Declarations of list management control structures and definitions - * of inline list management functions. - * - * Public Functions: - * LST_Create - * LST_Delete - * LST_Exit - * LST_First - * LST_GetHead - * LST_InitElem - * LST_Init - * LST_InsertBefore - * LST_IsEmpty - * LST_Next - * LST_PutTail - * LST_RemoveElem - * - * Notes: - * - *! Revision History - *! - *! 10-Aug-2000 ag: Added LST_InsertBefore(). - *! 29-Oct-1999 kc: Cleaned up for code review. - *! 16-Aug-1997 cr: added explicit identifiers. - *! 10-Aug-1996 gp: Acquired from SMM for WinSPOX v.1.1; renamed identifiers. - *! 21-Oct-1994 dh4: Cleaned / commented for code review. - *! 08-Jun-1994 dh4: Converted to SPM (added extern C). - */ - #ifndef LIST_ #define LIST_ drivers/dsp/bridge/services/list.c | 33 - DSPBRIDGE: trivial file history cleanup for driver sources @@ -14,39 +14,6 @@ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ - -/* - * listce.c - * Purpose - * Provides standard circular list handling functions. - * - * Public Functions: - * LST_Create - * LST_Delete - * LST_Exit - * LST_First - * LST_GetHead - * LST_Init - * LST_InitElem - * LST_InsertBefore - * LST_Next - * LST_PutTail - * LST_RemoveElem - * - *! Revision History - *! - *! 06-Mar-2002 jeh Don't set element self to NULL in LST_RemoveElem(). - *! 10-Aug-2000 ag: Added LST_InsertBefore(). - *! 03-Feb-2000 rr: Module init/exit is handled by SERVICES Init/Exit. - *! GT Changes. - *! 22-Nov-1999 kc: Added changes from code review. - *! 10-Aug-1999 kc: Based on wsx-c18. - *! 16-Jun-1997 gp: Removed unnecessary enabling/disabling of interrupts around - *! list manipulation code. - *! 22-Oct-1996 gp: Added LST_RemoveElem, and LST_First/LST_Next iterators. - *! 10-Aug-1996 gp: Acquired from SMM for WinSPOX v. 1.1; renamed identifiers. - */ - The original patch is way too big for the list about 250 KB, I just split those to modify header and sources separately, but they are still big. They can be found on the *temporary* experimental branch. http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=shortlog;h=refs/heads/experimental -- 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: SR1: VDD autocomp is not active
From: Sergey Lapin [slapi...@gmail.com] Sent: Tuesday, December 01, 2009 10:34 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: SR1: VDD autocomp is not active On Tue, Dec 1, 2009 at 7:08 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sergey Lapin Sent: Tuesday, December 01, 2009 5:24 PM To: linux-omap@vger.kernel.org Subject: SR1: VDD autocomp is not active Hi, all! on my OMAP3525-based custom board I get SR1: VDD autocomp is not active and SR2: VDD autocomp is not active quite frequently with PM branch. What that means, and how to fix it? Do you see them while trying to set the sr_vdd[1|2]_autocomp? OR During normal execution? During normal execution. What is the silicon version reported when Linux kernel boot up? OMAP3525 ES2.1 (l2cache iva neon isp ) I did notice an earlier mail where you mentioned about using an older kernel version. have to back-ported patches specific to silicon identification on this kernel/ It appears that efuse data required for SmartReflex to work may not be available on this silicon... leading to these messages. Right now, I am away from source code, will be able to verify in the morning. S. -- 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] arm: omap: Add omap3_defconfig
Having one combined defconfig that is the superset of the individual defconfigs for OMAP3 platforms is useful for easily finding build errors. Not to mention convenient as a base if you want to boot several platforms with a single kernel image. Signed-off-by: Olof Johansson o...@lixom.net --- Changed since v2: * CONFIG_OMAP_LL_DEBUG_NONE=y Changed since v1: * Refreshed to be based on for-next of linux-omap, resulting in minor differences, and: * Disabled OTG_WHITELIST/BLACKLIST * Disabled SYSFS_DEPRECATED.* * Disabled MUSB_PIO_ONLY Tony, I noticed linux-next doesn't build many of the OMAP defconfigs, and a handful of them won't build to date. I suggest adding this config, and I'll as Stephen Rothwell to add it as one of the configs that are tested (and build errors reported) for every release. He's reluctant to add too many individual configs since it adds time to each cycle, but one more can surely be acceptable. -Olof diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig new file mode 100644 index 000..2af28ea --- /dev/null +++ b/arch/arm/configs/omap3_defconfig @@ -0,0 +1,2119 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.32-rc8 +# Tue Dec 1 14:04:02 2009 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +CONFIG_ARCH_HAS_CPUFREQ=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_OPROFILE_ARMV7=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=32 +# CONFIG_RCU_FANOUT_EXACT is not set +# CONFIG_TREE_RCU_TRACE is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +# CONFIG_SYSFS_DEPRECATED_V2 is not set +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_ALL=y +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_COMPAT_BRK=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_PROFILING=y +CONFIG_TRACEPOINTS=y +CONFIG_OPROFILE=y +CONFIG_HAVE_OPROFILE=y +CONFIG_KPROBES=y +CONFIG_KRETPROBES=y +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_GCOV_KERNEL is not set +# CONFIG_SLOW_WORK is not set +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_FORCE_LOAD=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_BLOCK=y +CONFIG_LBDAF=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=cfq +CONFIG_FREEZER=y + +# +# System Type +# +CONFIG_MMU=y +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set
Re: [PATCH v3] arm: omap: Add omap3_defconfig
Hi, * Olof Johansson o...@lixom.net [091201 12:06]: Having one combined defconfig that is the superset of the individual defconfigs for OMAP3 platforms is useful for easily finding build errors. Not to mention convenient as a base if you want to boot several platforms with a single kernel image. Good idea, that's what many people are already doing. snip Tony, I noticed linux-next doesn't build many of the OMAP defconfigs, and a handful of them won't build to date. I suggest adding this config, and I'll as Stephen Rothwell to add it as one of the configs that are tested (and build errors reported) for every release. He's reluctant to add too many individual configs since it adds time to each cycle, but one more can surely be acceptable. I've built tested the for-next patches, they compile just fine except for the omap36xx patches which depend on an update to the mach-types. If you find some other omap related compile errors in for-next, can you please post the errors to this list? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] arm: omap: innovator: kill compile warning on board-innovator.c
* Felipe Balbi felipe.ba...@nokia.com [091201 10:28]:
that address is used by struct map_desc, which expects
an unsigned long instead of a void __iomem *. Fix it.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
Is this what you mean ??
Yeah, thanks!
Tony
arch/arm/plat-omap/include/plat/fpga.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/fpga.h
b/arch/arm/plat-omap/include/plat/fpga.h
index f1864a6..db2af50 100644
--- a/arch/arm/plat-omap/include/plat/fpga.h
+++ b/arch/arm/plat-omap/include/plat/fpga.h
@@ -85,9 +85,9 @@ struct h2p2_dbg_fpga {
* OMAP-1510 FPGA
*
---
*/
-#define OMAP1510_FPGA_BASE IOMEM(0xE800) /* VA */
+#define OMAP1510_FPGA_BASE 0xE800 /* VA */
#define OMAP1510_FPGA_SIZE SZ_4K
-#define OMAP1510_FPGA_START 0x0800 /* PA */
+#define OMAP1510_FPGA_START IOMEM(0x0800) /* PA */
/* Revision */
#define OMAP1510_FPGA_REV_LOW(OMAP1510_FPGA_BASE +
0x0)
--
1.6.6.rc0
--
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] OMAP3: SDRC: Comment out SDRC AC timing and MR changes in CORE DVFS SRAM code
The code that reprograms the SDRC memory controller during CORE DVFS,
mach-omap2/sram34xx.S:omap3_sram_configure_core_dpll(), does not
ensure that all L3 initiators are prevented from accessing the SDRAM
before modifying the SDRC AC timing and MR registers. This can cause
memory to be corrupted or cause the SDRC to enter an unpredictable
state. This patch comments out that code for now and adds a note
explaining what is going on. Ideally it can be added back in once
supporting code is present to ensure that other initiators aren't
touching the SDRAM. At the very least, these registers should be
reprogrammable during kernel init to deal with buggy bootloaders.
This is a modification of a patch originally written by Rajendra Nayak
rna...@ti.com (the original is at http://patchwork.kernel.org/patch/51927/).
Rather than removing the code completely, this patch just comments it out.
Thanks to Benoît Cousson b-cous...@ti.com and Christophe Sucur
c-su...@ti.com for explaining the technical basis for this and for
explaining what can be done to make this path work in future code.
Thanks to Richard Woodruff r-woodru...@ti.com for his comments.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Christophe Sucur c-su...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
---
arch/arm/mach-omap2/sram34xx.S | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index 82aa4a3..8fa8955 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -91,8 +91,18 @@
* new SDRC_ACTIM_CTRL_B_1 register contents
* new SDRC_MR_1 register value
*
- * If the param SDRC_RFR_CTRL_1 is 0, the parameters
- * are not programmed into the SDRC CS1 registers
+ * If the param SDRC_RFR_CTRL_1 is 0, the parameters are not programmed into
+ * the SDRC CS1 registers
+ *
+ * NOTE: This code no longer attempts to program the SDRC AC timing and MR
+ * registers. This is because the code currently cannot ensure that all
+ * L3 initiators (e.g., sDMA, IVA, DSS DISPC, etc.) are not accessing the
+ * SDRAM when the registers are written. If the registers are changed while
+ * an initiator is accessing SDRAM, memory can be corrupted and/or the SDRC
+ * may enter an unpredictable state. The code to reprogram the registers,
+ * however, has been left in -- commented out in #if 0 .. #endif blocks --
+ * since in the future, the intent is to re-enable this code in cases where we
+ * can ensure that no initiators are touching the SDRAM.
*/
ENTRY(omap3_sram_configure_core_dpll)
stmfd sp!, {r1-r12, lr} @ store regs to stack
@@ -219,6 +229,7 @@ configure_sdrc:
ldr r12, omap_sdrc_rfr_ctrl_0_val @ fetch value from SRAM
ldr r11, omap3_sdrc_rfr_ctrl_0 @ fetch addr from SRAM
str r12, [r11] @ store
+#if 0
ldr r12, omap_sdrc_actim_ctrl_a_0_val
ldr r11, omap3_sdrc_actim_ctrl_a_0
str r12, [r11]
@@ -228,11 +239,13 @@ configure_sdrc:
ldr r12, omap_sdrc_mr_0_val
ldr r11, omap3_sdrc_mr_0
str r12, [r11]
+#endif
ldr r12, omap_sdrc_rfr_ctrl_1_val
cmp r12, #0 @ if SDRC_RFR_CTRL_1 is 0,
beq skip_cs1_prog @ do not program cs1 params
ldr r11, omap3_sdrc_rfr_ctrl_1
str r12, [r11]
+#if 0
ldr r12, omap_sdrc_actim_ctrl_a_1_val
ldr r11, omap3_sdrc_actim_ctrl_a_1
str r12, [r11]
@@ -242,6 +255,7 @@ configure_sdrc:
ldr r12, omap_sdrc_mr_1_val
ldr r11, omap3_sdrc_mr_1
str r12, [r11]
+#endif
skip_cs1_prog:
ldr r12, [r11] @ posted-write barrier for SDRC
bx lr
--
1.6.5.GIT
Re: [PATCH v3] arm: omap: Add omap3_defconfig
On Tue, Dec 01, 2009 at 04:08:19PM -0800, Tony Lindgren wrote: Hi, * Olof Johansson o...@lixom.net [091201 12:06]: Having one combined defconfig that is the superset of the individual defconfigs for OMAP3 platforms is useful for easily finding build errors. Not to mention convenient as a base if you want to boot several platforms with a single kernel image. Good idea, that's what many people are already doing. Yeah, we're doing it internally for the boards we use for early software work. In PPC land we had good success booting a wide variety (even cross brands) with single kernels, but ARM isn't quite there yet :) Tony, I noticed linux-next doesn't build many of the OMAP defconfigs, and a handful of them won't build to date. I suggest adding this config, and I'll as Stephen Rothwell to add it as one of the configs that are tested (and build errors reported) for every release. He's reluctant to add too many individual configs since it adds time to each cycle, but one more can surely be acceptable. I've built tested the for-next patches, they compile just fine except for the omap36xx patches which depend on an update to the mach-types. Yep, I noticed that and figured it's no big deal and will happen when Russell pushes that update. If you find some other omap related compile errors in for-next, can you please post the errors to this list? Of course. The build errors I am referring to in this case are not in your for-next branch when built individually though, but instad when I built linux-next which included your branch and other work. I.e. others broke the omap compiles. Having a generic config that Stephen Rothwell can build before he pushes out a new release means others will be notified that they broke OMAP, which will benefit everyone in the long run. He could of course build individual ones but every added config adds to the turnaround time for him so he prefers just one or two. Thus the superset config I'm proposing. :) -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: omap3evm: touchscreen delays on pm branch
Selecting performance governors solved the issue. Nope. No cpufreq. I did notice that CPIO175 was not being set properly; have made local changes. It is a definite improvement; but there are still very noticeable delays. If PER Power domain is entering RET then module wakeups wont work! If at C2 you are seeing this then it might explain. -- 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: FEATURES - is it good enough
Alexander Shishkin said the following on 12/01/2009 05:42 PM: On Fri, Nov 20, 2009 at 02:09:01 -0600, Nishanth Menon wrote: Aguirre, Sergio had written, on 11/20/2009 01:43 PM, the following: -Original Message- From: Menon, Nishanth Sent: Friday, November 20, 2009 1:24 PM To: Kevin Hilman Cc: Shilimkar, Santosh; Aguirre, Sergio; Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: FEATURES - is it good enough Kevin Hilman had written, on 11/20/2009 12:35 PM, the following: Shilimkar, Santosh santosh.shilim...@ti.com writes: [...] Probably not something ot be attached in this patch, but... I'm a bit curious about something: Why touching omap3_features in OMAP4? Isn't there a omap4_features? Or even better, an omap_features? This is_feature suppose to take care of Errata's also, is it? It's not a bug it's a feature. :) Bug. Santosh pointed out internally to h/w discussion which clearly shows this as a h/w limitation. (thanks santosh) This is errata more than a feature. We better differentiate in this regard I agree, I have a hard time calling this empty fifo read fault a feature. We need a similar thing for errata. Agreed. This is a classic example why we need a common errata handling mechanism scalable across silicon variants on an IP basis. two problems in front of us: a) what do we want to do with 8250 workaround needed for omap3630 and omap4? can we go ahead with features marking it clearly as a misuse of features for the time being IMHO, That for the time being will stay forever if we don't do something now. Most of the big problems are raised because someone says ok, lets have this for the time being. But that time never comes. See that crazy CaMeL-Casing hanging around in /drivers/dsp/bridge/ for a while as an example. When that will ever be fixed? I bet someone said some time: ok, lets fix it later :-) On the other hand. What's the big motivation to have this as a feature? Who else than the serial driver cares about the feature awareness? please see [1] and [2]. this wont be the first time I published something previously that got ignored and got re-discussed. note: The [1] proposal sounds interesting to me, but it's not a very trivial matter. BTW, to be fair, DSPBridge already has plans to get fixed anyways.. Options I can think which were discussed: a) introduce omap3_features omap3_errata: negative: wont read like if I use omap3_has_errata() for OMAP4 code. b) introduce omap_features and omap_errata: negative: how do you link this to IP based usage across silicon (e.g. I2C). How about omap_has_errata(module, errata)? Or even something more generic? hmm.. just throwing more ideas up in the air: Call method: omap_ip_has_errata(u32 ip, u32 rev, u8 check_type, u8 erratum) where, ip = I2C, GPMC, MMC, etc.. rev = revision number check_type = GT, LT, NE, EQ erratum = erratum type omap_cpu_has_errata(u32 cpu_id, u32 rev, u8 check_type, u16 erratum) where, cpu_id = 15xx, 16xx etc ( can this be a function pointer to cpu_is..() functions? if so, how do we register this) rev = chip revision number check_type = GT, LT, NE, EQ erratum = erratum type Registration/Initialization: ?? maybe this could be extended to features also.. Regards, Nishanth Menon -- 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] OMAP3: SDRC: Comment out SDRC AC timing and MR changes in CORE DVFS SRAM code
Paul Walmsley said the following on 12/02/2009 03:33 AM:
The code that reprograms the SDRC memory controller during CORE DVFS,
mach-omap2/sram34xx.S:omap3_sram_configure_core_dpll(), does not
ensure that all L3 initiators are prevented from accessing the SDRAM
before modifying the SDRC AC timing and MR registers. This can cause
memory to be corrupted or cause the SDRC to enter an unpredictable
state. This patch comments out that code for now and adds a note
explaining what is going on. Ideally it can be added back in once
supporting code is present to ensure that other initiators aren't
touching the SDRAM. At the very least, these registers should be
reprogrammable during kernel init to deal with buggy bootloaders.
This is a modification of a patch originally written by Rajendra Nayak
rna...@ti.com (the original is at http://patchwork.kernel.org/patch/51927/).
Rather than removing the code completely, this patch just comments it out.
why not make this a #ifdef instead if we need it some other time, a #if
0 and it's intention might not be readable without doing a git annotate
in a few months time..
Thanks to Benoît Cousson b-cous...@ti.com and Christophe Sucur
c-su...@ti.com for explaining the technical basis for this and for
explaining what can be done to make this path work in future code.
Thanks to Richard Woodruff r-woodru...@ti.com for his comments.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Christophe Sucur c-su...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
---
arch/arm/mach-omap2/sram34xx.S | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
index 82aa4a3..8fa8955 100644
--- a/arch/arm/mach-omap2/sram34xx.S
+++ b/arch/arm/mach-omap2/sram34xx.S
@@ -91,8 +91,18 @@
* new SDRC_ACTIM_CTRL_B_1 register contents
* new SDRC_MR_1 register value
*
- * If the param SDRC_RFR_CTRL_1 is 0, the parameters
- * are not programmed into the SDRC CS1 registers
+ * If the param SDRC_RFR_CTRL_1 is 0, the parameters are not programmed into
+ * the SDRC CS1 registers
+ *
+ * NOTE: This code no longer attempts to program the SDRC AC timing and MR
+ * registers. This is because the code currently cannot ensure that all
+ * L3 initiators (e.g., sDMA, IVA, DSS DISPC, etc.) are not accessing the
+ * SDRAM when the registers are written. If the registers are changed while
+ * an initiator is accessing SDRAM, memory can be corrupted and/or the SDRC
+ * may enter an unpredictable state. The code to reprogram the registers,
+ * however, has been left in -- commented out in #if 0 .. #endif blocks
--
+ * since in the future, the intent is to re-enable this code in cases where
we
+ * can ensure that no initiators are touching the SDRAM.
*/
ENTRY(omap3_sram_configure_core_dpll)
stmfd sp!, {r1-r12, lr} @ store regs to stack
@@ -219,6 +229,7 @@ configure_sdrc:
ldr r12, omap_sdrc_rfr_ctrl_0_val @ fetch value from SRAM
ldr r11, omap3_sdrc_rfr_ctrl_0 @ fetch addr from SRAM
str r12, [r11] @ store
+#if 0
ldr r12, omap_sdrc_actim_ctrl_a_0_val
ldr r11, omap3_sdrc_actim_ctrl_a_0
str r12, [r11]
@@ -228,11 +239,13 @@ configure_sdrc:
ldr r12, omap_sdrc_mr_0_val
ldr r11, omap3_sdrc_mr_0
str r12, [r11]
+#endif
ldr r12, omap_sdrc_rfr_ctrl_1_val
cmp r12, #0 @ if SDRC_RFR_CTRL_1 is 0,
beq skip_cs1_prog @ do not program cs1 params
ldr r11, omap3_sdrc_rfr_ctrl_1
str r12, [r11]
+#if 0
ldr r12, omap_sdrc_actim_ctrl_a_1_val
ldr r11, omap3_sdrc_actim_ctrl_a_1
str r12, [r11]
@@ -242,6 +255,7 @@ configure_sdrc:
ldr r12, omap_sdrc_mr_1_val
ldr r11, omap3_sdrc_mr_1
str r12, [r11]
+#endif
skip_cs1_prog:
ldr r12, [r11] @ posted-write barrier for SDRC
bx lr
--
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/5] ARM: OMAP4: PM: Basic OMAP4 clock framework
Rajendra,
Some minor comments / queries
snip
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Rajendra Nayak
Sent: Tuesday, December 01, 2009 5:57 PM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Cc: Nayak, Rajendra; Paul Walmsley; Cousson, Benoit
Subject: [PATCH 2/5] ARM: OMAP4: PM: Basic OMAP4 clock framework
This patch registers the OMAP4430 clock
nodes with the CLKDEV framework.
Enables CLKDEV for OMAP4.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/Makefile|8 +-
arch/arm/mach-omap2/clock.c |8 +
arch/arm/mach-omap2/clock44xx.c | 331
+++
arch/arm/mach-omap2/cm.h|4 +
arch/arm/mach-omap2/gpmc.c |2 +-
arch/arm/mach-omap2/io.c|4 +-
arch/arm/plat-omap/Kconfig |1 +
arch/arm/plat-omap/clock.c | 26 ---
arch/arm/plat-omap/include/mach/clock.h |3 +
9 files changed, 354 insertions(+), 33 deletions(-)
create mode 100644 arch/arm/mach-omap2/clock44xx.c
+#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdm f/w is
in place */
Commenting style. This is at multiple places.
if (clk-clkdm)
omap2_clkdm_clk_disable(clk-clkdm, clk);
+#endif
}
}
@@ -448,8 +452,10 @@ int omap2_clk_enable(struct clk *clk)
int ret = 0;
.
diff --git a/arch/arm/mach-omap2/clock44xx.c b/arch/arm/mach-
omap2/clock44xx.c
new file mode 100644
index 000..e015200
--- /dev/null
+++ b/arch/arm/mach-omap2/clock44xx.c
@@ -0,0 +1,331 @@
+/*
+ * OMAP4-specific clock framework functions
+ *
+ * Copyright (C) 2009 Texas Instruments, Inc.
+ *
+ * Rajendra Nayak (rna...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License version 2
as
+ * published by the Free Software Foundation.
+ */
+#undef DEBUG
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/device.h
+#include linux/list.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/limits.h
+#include linux/bitops.h
+
+#include mach/clock.h
+#include mach/sram.h
+#include asm/div64.h
+#include asm/clkdev.h
+
+#include mach/sdrc.h
+#include clock.h
+#include prm.h
+#include prm-regbits-44xx.h
+#include cm.h
+#include cm-regbits-44xx.h
+
+
+static const struct clkops clkops_noncore_dpll_ops;
+
+#include clock44xx.h
+
+struct omap_clk {
+ u32 cpu;
+ struct clk_lookup lk;
+};
+
+#define CLK(dev, con, ck, cp)\
+ { \
+ .cpu = cp, \
+ .lk = { \
+ .dev_id = dev, \
+ .con_id = con, \
+ .clk = ck, \
+ }, \
+ }
+
+#define CK_443X (1 0)
+
+static struct omap_clk omap44xx_clks[] = {
+ CLK(NULL, extalt_clkin_ck, extalt_clkin_ck,
CK_443X),
Are we still keeping these 'dev as NULL ? This is applicable to most of the
table. May be a follow up patch on this needed. Also lines are exceeding 80
char's in the table.
+ CLK(NULL, pad_clks_ck, pad_clks_ck,
CK_443X),
+ CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck, CK_443X),
+ CLK(NULL, secure_32k_clk_src_ck,
secure_32k_clk_src_ck, CK_443X),
.
+static struct clk_functions omap2_clk_functions = {
+ .clk_enable = omap2_clk_enable,
+ .clk_disable= omap2_clk_disable,
+ .clk_round_rate = omap2_clk_round_rate,
+ .clk_set_rate = omap2_clk_set_rate,
+ .clk_set_parent = omap2_clk_set_parent,
+ .clk_disable_unused = omap2_clk_disable_unused,
+};
+
+/*
+ * Dummy functions for DPLL control. Plan is to re-use
+ * existing OMAP3 dpll control functions.
+ */
+
+static unsigned long omap3_dpll_recalc(struct clk *clk)
+{
+ return 0;
+}
+
+static int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
+{
+ return 0;
+}
+
+static int omap3_noncore_dpll_enable(struct clk *clk)
+{
+ return 0;
+}
+
+static void omap3_noncore_dpll_disable(struct clk *clk)
+{
+ return;
+}
+
+static const struct clkops clkops_noncore_dpll_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+};
+
+void omap2_clk_prepare_for_reboot(void)
+{
+ return;
+}
+
+static int __init omap2_clk_arch_init(void)
+{
+ if (!mpurate)
+ return -EINVAL;
+
+
RE: [PATCH 3/5] ARM: OMAP4: PM: Move DPLL control apis to dpll.c
snip -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Nayak, Rajendra Sent: Tuesday, December 01, 2009 5:57 PM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: Nayak, Rajendra; Paul Walmsley; Cousson, Benoit Subject: [PATCH 3/5] ARM: OMAP4: PM: Move DPLL control apis to dpll.c This patch moves all the dpll control api's to a common file dpll.c. This is in preperation of omap4 support wherein most of these api's can be reused. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/Makefile|3 +- arch/arm/mach-omap2/clock.h | 13 + arch/arm/mach-omap2/clock34xx.c | 511 - arch/arm/mach-omap2/clock34xx.h | 11 - arch/arm/mach-omap2/clock44xx.c |8 +- arch/arm/mach-omap2/clock44xx.h |4 - arch/arm/mach-omap2/dpll.c | 539 +++ 7 files changed, 558 insertions(+), 531 deletions(-) create mode 100644 arch/arm/mach-omap2/dpll.c On OMAP4, we might need an additional API since different DPLL outputs Like M2, M3 , M4 etc have individual gating control ( Bit 8) apart form DPLL gating. 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
