RE: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK tospeed-up boot
> -Original Message- > From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux- > arm-kernel-boun...@lists.infradead.org] On Behalf Of Russell King - > ARM Linux > Sent: Friday, January 21, 2011 10:46 PM > To: Rob Herring > Cc: linux-omap@vger.kernel.org; Santosh Shilimkar; Linus Walleij; > linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK > tospeed-up boot > [...] > > That means cpufreq scaling on SMP is broken then... Why isn't > cpufreq > marked with a !SMP dependence or something similar (eg, depends on > !SMP || CPU_INDEPENDENT_UDELAY)... Maybe it should be. > Actually it's not broken but documented to use arch specific per-cpu lpj with cpufreq scaling. And that update cab be managed by arch specific cpufreq code based on the way CPUs scale. That's how other arch including x86 doing it. And global lpj can be update as well there which is not done at this moment. > > And delay.S uses the global loops_per_jiffy, not the per cpu > value. The > > only place I see the per cpu value get used is /proc/cpuinfo. > > > > Consider the following sequence: > > > > - scale down the cpu freq > > - hot unplug a core > > - hot plug a core > > - calls calibrate_delay and update the global loops_per_jiffy > > - scale up the cpu freq > > - udelay time is now much too short!!! > > > > So for that reason, I would just remove calibrate_delay > unconditionally. > > Better to have the 1% inaccuracy and longer delays at low > frequency than > > to have too short of a delay at high freq. > > As you've shown above, it makes not a blind bit of difference > whether > calibrate_delay() is called... on SMP the loops_per_jiffy will be > wrong > as soon as you start scaling no matter what. > Surely whichever way we should remove the recalibration otherwise every time secondary cpus spend ~ 200 ms there. Russell, How do you like to address this? 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
Re: [PATCH v8 00/18] OMAP2,3: hwmod DSS Adaptation
Hi Kevin, On Fri, Jan 21, 2011 at 10:05 PM, Kevin Hilman wrote: > Sumit Semwal writes: > >> v8 of the DSS hwmod patch series fixes some issues based on findings of >> Kevin Hilman on beagle. > > Thanks. I re-tested on beagle and it looks good. > > I also briefly tested on beagle with PM. I tested suspend/resume to > verify we could still hit full-chip retention. I also verified idle > with and without screen blanked. As expected, with the screen (external > DVI monitor) active, the DSS power domain did not hit retentiond during > idle, but allowing the screen to blank, DSS powerdomain then hits idle. > > Feel free to add: > > Reviewed-by: Kevin Hilman > Tested-by: Kevin Hilman > > Also, can you repost one more time with the > linux-arm-ker...@lists.infradead.org Cc'd? Thanks. Thanks very much for helping out with the testing! I will post an updated one w/ your reviewed-by and tested-by in a bit. Best regards, ~Sumit. > > Kevin > >> The VENC platform driver was not getting registered due to missed device >> name update for vdda_dac regulator in some board files. This was moved from >> 'omap_display' device to 'omap_venc' device in patch 14/18. >> >> Also, similarly for DSI platform driver, the regulator name 'vdds_dsi' needs >> two >> instances - one for dpi, and one for dsi. >> >> This version corrects the above two for all board files where 'vdda_dac' and >> 'vdds_dsi' regulators are defined. [patches 14/18 and 15/18] >> >> Post this change, boot w/ visible framebuffer and tux was successfully >> validated >> on beagle, 3430SDP and zoom3. >> >> A patch mentioned in >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42384.html >> was needed to get OMAP3 to boot up on top of linux-next of 20110115. >> >> OMAP4 hwmod support will be posted after the acceptance of this basic change >> in >> the dss2 design. >> >> - >> [original patch introduction] >> >> This patch series decouples the "Clocks for DSS in hwmod adaptation" changes >> from this series. Another series would be posted which could be discussed >> w.r.t clocks in DSS across omap2,3. >> >> Removing the SYSCONFIG settings from DSS driver would also be part of these >> clock changes series and not covered in this series as it depends on some of >> the omap_hwmod framework changes w.r.t opt clocks handling. >> >> Summary of the hwmod DSS design: >> >> DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each >> corresponding to the hwmod class in the hwmod database. >> >> Each of these platform drivers' init / deinit are handled from core.c's >> omap_dss_probe() in the exact sequence as required. >> >> No Hardcoding of silicon data: >> hwmod database abstracts the SOC data like base addr, irq numbers and are >> implemented in this patch series. >> >> Continue to have custom bus for display panels: >> "omap_display" driver continues to be a platform driver that registers the >> custom >> bus. It also continues to register the display panels(omap_dss_device) on >> the >> board to the panel drivers (omap_dss_driver) >> For Eg: primary lcd device would be registered with lcd panel driver. >> lcd panel driver if it is on a parallel interface would use library functions >> exported from dpi.o. if it is on a dsi interface would use library functions >> exported from dsi platform driver(dsi.o). >> >> Clocks: >> Handling of clocks in DSS only is one of the design approaches, that does not >> change the existing implementation. If each of the DSS HW IPs had to handle >> their own clocks, then corresponding clock changes can be requested in the >> hwmod >> database as well which is not the current design/implementation. As stated, >> this would be handled in another series seperately. >> For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now >> apart >> for the dss main clocks. Currently VENC driver needs to be aware of this >> and has to >> use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. >> >> >> >> Current dss driver: >> --- >> 1. Omapdss platform driver >> - initialises necessary Ips dss, dispc. >> - also initialises Ips like sdi, dsi, venc, rfbi >> - creates a custom bus and registers the display devices/drivers >> connected on the board to the custom bus. >> >> 2. Suspend/resume of omapdss >> - in turn sends suspend/resume calls for each of the display devices >> registered to it. >> >> Modified change: >> --- >> Platform driver for each DSS HW IP in addition to the software "omap_display" >> driver. >> >> Omapdss platform driver >> - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, >> venc, rfbi] >> and software libraries like dpi, sdi. >> - continues to have a custom bus and registers the display devices >> and drivers connected on the board to the custom bus. >>
RE: [PATCH v4 4/4] TI816X: Add low level debug support
Hilman, Kevin wrote on Saturday, January 22, 2011 5:21 AM: > Hemant Pedanekar writes: > >> This patch adds support for low level debugging on TI816X boards. >> Currently the support for UART3 console on TI816X EVM is added. >> >> Signed-off-by: Hemant Pedanekar > > You can add the UART base addresses in this patch since this is the only > place they are needed/used. > > Kevin > Yes. Thanks. Hemant -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 2/4] TI816X: Update common OMAP machine specific sources
Kevin,
Kevin Hilman wrote on Saturday, January 22, 2011 5:19 AM:
> Hemant Pedanekar writes:
>
>> This patch updates the common machine specific source files with support
>> for TI816X.
>>
>> The approach taken is to have TI816X only build for OMAP3 when
>> CONFIG_SOC_OMAPTI816X is defined.
>>
>> Signed-off-by: Hemant Pedanekar
>> ---
>> arch/arm/mach-omap2/clock3xxx_data.c |5 +++-
>> arch/arm/mach-omap2/common.c | 24 +
>> arch/arm/mach-omap2/control.h | 17
>> arch/arm/mach-omap2/id.c | 33
>> ++- arch/arm/mach-omap2/include/mach/entry-macro.S |
>> 13 + arch/arm/mach-omap2/io.c | 13
>> - arch/arm/mach-omap2/irq.c |5 +++-
>> arch/arm/mach-omap2/serial.c |8 +++---
>> arch/arm/plat-omap/io.c|5 +++-
>> 9 files changed, 113 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
> b/arch/arm/mach-omap2/clock3xxx_data.c
>> index 9ab817e..557de99 100644
>> --- a/arch/arm/mach-omap2/clock3xxx_data.c
>> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
>> @@ -3466,6 +3466,9 @@ int __init omap3xxx_clk_init(void)
>> } else if (cpu_is_omap3630()) {
>> cpu_mask = (RATE_IN_34XX | RATE_IN_36XX);
>> cpu_clkflg = CK_36XX;
>> +} else if (cpu_is_ti816x()) {
>> +cpu_mask = RATE_IN_TI816X;
>> +cpu_clkflg = CK_TI816X;
>> } else if (cpu_is_omap34xx()) {
>> if (omap_rev() == OMAP3430_REV_ES1_0) {
>> cpu_mask = RATE_IN_3430ES1;
>> @@ -3545,7 +3548,7 @@ int __init omap3xxx_clk_init(void) /*
>> * Lock DPLL5 and put it in autoidle.
>> */
>> -if (omap_rev() >= OMAP3430_REV_ES2_0)
>> +if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
>> omap3_clk_lock_dpll5();
>>
>> /* Avoid sleeping during omap3_core_dpll_m2_set_rate() */
>> diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
>> index 778929f..7f58b7f 100644 --- a/arch/arm/mach-omap2/common.c
>> +++ b/arch/arm/mach-omap2/common.c
>> @@ -108,6 +108,30 @@ void __init omap3_map_io(void)
>> omap2_set_globals_3xxx(); omap34xx_map_common_io();
>> }
>> +
>> +/*
>> + * Adjust TAP register base such that omap3_check_revision accesses the
>> correct + * TI816X register for checking device ID (it adds 0x204 to tap
>> base while + * TI816X DEVICE ID register is at offset 0x600 from control
>> base). + */ +#define TI816X_TAP_BASE (TI816X_CTRL_BASE + \
>> +TI816X_CONTROL_DEVICE_ID - 0x204)
>> +
>> +static struct omap_globals ti816x_globals = {
>> +.class = OMAP343X_CLASS,
>> +.tap= OMAP2_L4_IO_ADDRESS(TI816X_TAP_BASE),
>> +.ctrl = TI816X_CTRL_BASE,
>> +.prm= TI816X_PRCM_BASE,
>> +.cm = TI816X_PRCM_BASE,
>> +.uart1_phys = TI816X_UART1_BASE,
>> +.uart2_phys = TI816X_UART2_BASE,
>> +.uart3_phys = TI816X_UART3_BASE,
>
> The uart*_phys are not needed. I just sent a patch to remove these from
> the core code.
>
>> +};
>> +
>> +void __init omap2_set_globals_ti816x(void)
>> +{
>> +__omap2_set_globals(&ti816x_globals);
>> +}
>> #endif
>>
>> #if defined(CONFIG_ARCH_OMAP4)
>> diff --git a/arch/arm/mach-omap2/control.h
> b/arch/arm/mach-omap2/control.h
>> index f0629ae..5c87054 100644
>> --- a/arch/arm/mach-omap2/control.h
>> +++ b/arch/arm/mach-omap2/control.h
>> @@ -52,6 +52,11 @@
>> #define OMAP343X_CONTROL_PADCONFS_WKUP 0xa00
>> #define OMAP343X_CONTROL_GENERAL_WKUP 0xa60
>>
>> +/* TI816X spefic control submodules */
>> +#define TI816X_CONTROL_OCPCONF 0x000
>> +#define TI816X_CONTROL_DEVBOOT 0x040
>> +#define TI816X_CONTROL_DEVCONF 0x600
>
> Not used in this patch (or series)
>
>> /* Control register offsets - read/write with
> omap_ctrl_{read,write}{bwl}() */
>>
>> #define OMAP2_CONTROL_SYSCONFIG
> (OMAP2_CONTROL_INTERFACE + 0x10)
>> @@ -241,6 +246,18 @@
>> #define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
>> #define OMAP3_PADCONF_SAD2D_IDLEACK0x254
>>
>> +/* TI816X CONTROL_DEVBOOT register offsets */
>> +#define TI816X_CONTROL_STATUS
> (TI816X_CONTROL_DEVBOOT + 0x000)
>> +#define TI816X_CONTROL_BOOTSTAT
> (TI816X_CONTROL_DEVBOOT + 0x004)
>> +
>> +/* TI816X CONTROL_DEVCONF register offsets */
>> +#define TI816X_CONTROL_DEVICE_ID(TI816X_CONTROL_DEVCONF + 0x000)
>> +#define TI816X_CONTROL_MAC_ID0_LO (TI816X_CONTROL_DEVCONF + 0x030)
>> +#define TI816X_CONTROL_MAC_ID0_HI (TI816X_CONTROL_DEVCONF + 0x034)
>> +#define TI816X_CONTROL_MAC_ID1_LO (TI816X_CONTROL_DEVCONF + 0x038)
>> +#define TI816X_CONTROL_MAC_ID1_HI (TI816X_CONTROL_DEVCONF + 0x03c)
>> +#define TI816X_CONTROL_PCIE_CFG
> (TI816X_CONTROL_DEVCONF + 0x040)
>
> Not used in this patch (or series)
>
> In general, we don't like to see unuse
RE: [PATCH v4 1/4] TI816X: Update common omap platform files
Hi Kevin, Hilman, Kevin wrote on Saturday, January 22, 2011 4:01 AM: > Hi Hemant, > > Hemant Pedanekar writes: > >> This patch updates the common platform files with TI816X support. Also >> adds new files for TI816X module base addresses and irq definitions. > [...] > >> diff --git a/arch/arm/plat-omap/include/plat/irqs-ti816x.h > b/arch/arm/plat-omap/include/plat/irqs-ti816x.h >> new file mode 100644 >> index 000..3ec5d1b [...] >> +#define TI816X_IRQ_SECPUBINT116 >> +#define TI816X_IRQ_SECSECINT117 >> +#define TI816X_IRQ_SECPUBSWINT 118 >> +#define TI816X_IRQ_SECSECSWINT 119 >> +#define TI816X_IRQ_SMRFLX0 120 >> +#define TI816X_IRQ_SMRFLX1 121 >> +#define TI816X_IRQ_SYS_MMU 122 >> +#define TI816X_IRQ_MC_MMU 123 >> +#define TI816X_IRQ_DMM 124 >> + >> + >> +#endif > > For new platforms, We don't need to have a list of all the > IRQ numbers. > > Driver code should always be getting IRQ numbers (and base addresses > etc.) from struct resource/platform_data, which is populated > from omap_hwmod. > Are you suggesting to get rid of this file altogether or the IRQs which may never be used from kernel be removed from this file (and added later If needed)? Or shall I add this file only in hwmod patch which will be submitted later? [...] >> diff --git a/arch/arm/plat-omap/include/plat/serial.h > b/arch/arm/plat-omap/include/plat/serial.h >> index cec5d56..3c3c319 100644 >> --- a/arch/arm/plat-omap/include/plat/serial.h >> +++ b/arch/arm/plat-omap/include/plat/serial.h >> @@ -51,6 +51,11 @@ >> #define OMAP4_UART3_BASE0x4802 >> #define OMAP4_UART4_BASE0x4806e000 >> >> +/* TI816X serial ports */ >> +#define TI816X_UART1_BASE 0x4802 >> +#define TI816X_UART2_BASE 0x48022000 >> +#define TI816X_UART3_BASE 0x48024000 > >> /* External port on Zoom2/3 */ >> #define ZOOM_UART_BASE 0x1000 >> #define ZOOM_UART_VIRT 0xfa40 >> diff --git a/arch/arm/plat-omap/include/plat/ti816x.h > b/arch/arm/plat-omap/include/plat/ti816x.h >> new file mode 100644 >> index 000..f1729f7 >> --- /dev/null >> +++ b/arch/arm/plat-omap/include/plat/ti816x.h >> @@ -0,0 +1,31 @@ [...] >> + >> +#define L3_TI816X_BASE 0x4400 >> +#define L4_FAST_TI816X_BASE 0x4a00 >> +#define L4_SLOW_TI816X_BASE 0x4800 >> + >> +#define TI816X_SCM_BASE 0x4814 >> +#define TI816X_CTRL_BASETI816X_SCM_BASE >> +#define TI816X_PRCM_BASE0x4818 >> + >> +#define TI816X_ARM_INTC_BASE0x4820 >> + >> +#define TI816X_GPMC_BASE0x5000 >> + >> +#endif /* __ASM_ARCH_TI816X_H */ > > All of these fall into the "not used in this patch" category. > > It is best to add these defines in the patches where they are used so > reviewers can see the usage and/or the need. > > With all of these defines, the subject for this patch should probably > just be about adding the SoC detection infrastructure. > > Thanks, > > Kevin Okay, I will remove some of the unused defs (like GPMC_BASE) and reorganize The patches to have files in correct groups. Thanks. Hemant -- 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] OMAP: Enable Magic SysRq on serial console ttyOx
"G, Manjunath Kondaiah" writes: > On Fri, Jan 21, 2011 at 12:54:29PM +0530, Govindraj wrote: >> On Thu, Jan 20, 2011 at 5:49 PM, Anand Gadiyar wrote: >> >> > Magic SysRq key is not working for OMAP on new serial >> >> > console ttyOx because SUPPORT_SYSRQ is not defined >> >> > for omap-serial. >> >> > >> >> > This patch defines SUPPORT_SYSRQ in omap-serial and >> >> > enables handling of Magic SysRq character. >> >> > >> >> > Signed-off-by: Thomas Weber >> >> > >>> >> >> > >>> Looks fine to me. >> >> > >>> >> >> > >>> Acked-by: Govindraj.R >> >> > >> I tried to use SysRq key on minicom after applying this patch, it >> > looks >> >> > >> like it is not triggering sysrq event. >> >> > >> >> >> > >> Am I missing anything? >> >> > >> >> >> > >> -Manjunath >> >> > >> -- >> >> > > Hello Manjunath, >> >> > > >> >> > > Do you have CONFIG_MAGIC_SYSRQ enabled? >> >> > > Magic SysRq key in Kernel Hacking >> >> > > >> >> > > I tested it on Devkit8000 (beagle board clone). >> >> > > >> >> > >> >> > re-setting lsr_break_flag to 0 in receive chars is causing issues >> >> > in getting sysrq key break sequence on omap-serial.c >> >> > >> >> > Manju, >> >> > >> >> > can you try this change on your environment. >> >> > With below change works for me on 3430SDP/4430SDP. >> >> > key sequence I checked. >> >> > [alt + b + t] => shows trace of tasks running. >> >> > [alt + b + b] => system reboot. >> >> >> >> With below patch, it works fine on TeraTerm. However, I am not able to >> >> perform the same on minicom. >> >> >> >> Tested-by: Manjunath G Kondaiah >> >> >> >> -Manjunath >> >> >> > >> > Not sure what you guys are trying out, but I am able to use sysrq >> > just fine in minicom (using only Thomas' original patch) - you need >> > to send a break sequence, and the way to do this in minicom is to >> > do Ctrl-A followed by F. >> > >> > Works for me, without the "resetting lsr_break_flag to 0" part. >> > >> > @Govind, >> > >> > What are the issues you see in getting sysrq key break sequence >> > without your change? And how is your change fixing this? >> >> Actually I was using teraterm on windows platform. >> using keyboard to send a break char [alt + b] sometimes >> i observed that first break char was getting lost and subsequent break >> chars where getting >> recognized. However using send break option from terterm menu seems to >> work most of times. >> my change can be dropped. > If it is fixing the issue of losing first break character, what is wrong in > having this patch? > > Do you see any other issues because of this change? Were you loosing the first break character because of PM? i.e., if the OMAP is in retention or off while idle, we will always loose the first character. The first character causes the wakeup, but does not make it to the UART. Is the first break character lost if sleep_while_idle == 0? Kevin -- 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] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
Tero Kristo writes:
> On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other
> parts of the chip will be reset. If those parts of the chip are busy,
> the reset will disrupt them, causing unpredictable and generally
> undesirable results. This reset is caused by the core domain wakeup
> (COREDOMAINWKUP_RST), and it can occur for example in a case where
> some peripheral domain is in retention or inactive state and core
> enters off. This will result in the peripheral domain being reset.
>
> Signed-off-by: Tero Kristo
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> Cc: Santosh Shilimkar
> Cc: Vishwanath Sripathy
Thanks Tero.
Will add Paul's reviewed-by and Santosh's ack and queue for 2.6.39 in my
pm-next branch.
Kevin
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 40 +++-
> 1 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index f3e043f..d31b858 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -61,7 +61,7 @@ struct omap3_processor_cx {
> struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
> struct omap3_processor_cx current_cx_state;
> struct powerdomain *mpu_pd, *core_pd, *per_pd;
> -struct powerdomain *cam_pd;
> +struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd, *usb_pd;
>
> /*
> * The latencies/thresholds for various C states have
> @@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
> {
> struct cpuidle_state *new_state = next_valid_state(dev, state);
> u32 core_next_state, per_next_state = 0, per_saved_state = 0;
> - u32 cam_state;
> + u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
> struct omap3_processor_cx *cx;
> int ret;
>
> @@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>*its own code.
>*/
>
> + /* XXX Add CORE-active check here */
> +
> /*
>* Prevent idle completely if CAM is active.
>* CAM does not have wakeup capability in OMAP3.
> @@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct cpuidle_device
> *dev,
> (core_next_state > PWRDM_POWER_RET))
> per_next_state = PWRDM_POWER_RET;
>
> + /* XXX Add prevent-PER-off check here */
> +
> + /*
> + * If we are attempting CORE off, check if any other powerdomains
> + * are at retention or higher. CORE off causes chipwide reset which
> + * would reset these domains also.
> + */
> + if (core_next_state == PWRDM_POWER_OFF) {
> + iva2_state = pwrdm_read_pwrst(iva2_pd);
> + sgx_state = pwrdm_read_pwrst(sgx_pd);
> + usb_state = pwrdm_read_pwrst(usb_pd);
> + dss_state = pwrdm_read_pwrst(dss_pd);
> +
> + if (cam_state > PWRDM_POWER_OFF ||
> + dss_state > PWRDM_POWER_OFF ||
> + iva2_state > PWRDM_POWER_OFF ||
> + per_next_state > PWRDM_POWER_OFF ||
> + sgx_state > PWRDM_POWER_OFF ||
> + usb_state > PWRDM_POWER_OFF)
> + core_next_state = PWRDM_POWER_RET;
> + }
> +
> + /* Fallback to new target core/mpu state */
> + while (cx->core_state < core_next_state) {
> + state--;
> + cx = cpuidle_get_statedata(state);
> + }
> +
> + new_state = state;
> +
> /* Are we changing PER target state? */
> if (per_next_state != per_saved_state)
> pwrdm_set_next_pwrst(per_pd, per_next_state);
> @@ -489,6 +521,10 @@ int __init omap3_idle_init(void)
> core_pd = pwrdm_lookup("core_pwrdm");
> per_pd = pwrdm_lookup("per_pwrdm");
> cam_pd = pwrdm_lookup("cam_pwrdm");
> + dss_pd = pwrdm_lookup("dss_pwrdm");
> + iva2_pd = pwrdm_lookup("iva2_pwrdm");
> + sgx_pd = pwrdm_lookup("sgx_pwrdm");
> + usb_pd = pwrdm_lookup("usbhost_pwrdm");
>
> omap_init_power_states();
> cpuidle_register_driver(&omap3_idle_driver);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] TI816X: Add low level debug support
Hemant Pedanekar writes:
> This patch adds support for low level debugging on TI816X boards. Currently
> the
> support for UART3 console on TI816X EVM is added.
>
> Signed-off-by: Hemant Pedanekar
You can add the UART base addresses in this patch since this is the only
place they are needed/used.
Kevin
> ---
> arch/arm/mach-omap2/include/mach/debug-macro.S | 12
> arch/arm/plat-omap/include/plat/serial.h |3 +++
> arch/arm/plat-omap/include/plat/uncompress.h |7 +++
> 3 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S
> b/arch/arm/mach-omap2/include/mach/debug-macro.S
> index 6a4d413..e1b0f17 100644
> --- a/arch/arm/mach-omap2/include/mach/debug-macro.S
> +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S
> @@ -69,6 +69,12 @@ omap_uart_lsr: .word 0
> beq 34f @ configure OMAP3UART4
> cmp \rp, #OMAP4UART4@ only on 44xx
> beq 44f @ configure OMAP4UART4
> + cmp \rp, #TI816XUART1 @ ti816x UART offsets different
> + beq 81f @ configure UART1
> + cmp \rp, #TI816XUART2 @ ti816x UART offsets different
> + beq 82f @ configure UART2
> + cmp \rp, #TI816XUART3 @ ti816x UART offsets different
> + beq 83f @ configure UART3
> cmp \rp, #ZOOM_UART @ only on zoom2/3
> beq 95f @ configure ZOOM_UART
>
> @@ -91,6 +97,12 @@ omap_uart_lsr: .word 0
> b 98f
> 44: mov \rp, #UART_OFFSET(OMAP4_UART4_BASE)
> b 98f
> +81: mov \rp, #UART_OFFSET(TI816X_UART1_BASE)
> + b 98f
> +82: mov \rp, #UART_OFFSET(TI816X_UART2_BASE)
> + b 98f
> +83: mov \rp, #UART_OFFSET(TI816X_UART3_BASE)
> + b 98f
> 95: ldr \rp, =ZOOM_UART_BASE
> mrc p15, 0, \rv, c1, c0
> tst \rv, #1 @ MMU enabled?
> diff --git a/arch/arm/plat-omap/include/plat/serial.h
> b/arch/arm/plat-omap/include/plat/serial.h
> index 3c3c319..4102bf4 100644
> --- a/arch/arm/plat-omap/include/plat/serial.h
> +++ b/arch/arm/plat-omap/include/plat/serial.h
> @@ -86,6 +86,9 @@
> #define OMAP4UART2 OMAP2UART2
> #define OMAP4UART3 43
> #define OMAP4UART4 44
> +#define TI816XUART1 81
> +#define TI816XUART2 82
> +#define TI816XUART3 83
> #define ZOOM_UART95 /* Only on zoom2/3 */
>
> /* This is only used by 8250.c for omap1510 */
> diff --git a/arch/arm/plat-omap/include/plat/uncompress.h
> b/arch/arm/plat-omap/include/plat/uncompress.h
> index ad98b85..30b891c 100644
> --- a/arch/arm/plat-omap/include/plat/uncompress.h
> +++ b/arch/arm/plat-omap/include/plat/uncompress.h
> @@ -93,6 +93,10 @@ static inline void flush(void)
> #define DEBUG_LL_ZOOM(mach) \
> _DEBUG_LL_ENTRY(mach, ZOOM_UART_BASE, ZOOM_PORT_SHIFT, ZOOM_UART)
>
> +#define DEBUG_LL_TI816X(p, mach) \
> + _DEBUG_LL_ENTRY(mach, TI816X_UART##p##_BASE, OMAP_PORT_SHIFT, \
> + TI816XUART##p)
> +
> static inline void __arch_decomp_setup(unsigned long arch_id)
> {
> int port = 0;
> @@ -166,6 +170,9 @@ static inline void __arch_decomp_setup(unsigned long
> arch_id)
> DEBUG_LL_ZOOM(omap_zoom2);
> DEBUG_LL_ZOOM(omap_zoom3);
>
> + /* TI8168 base boards using UART3 */
> + DEBUG_LL_TI816X(3, ti8168evm);
> +
> } while (0);
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/4] TI816X: Update common OMAP machine specific sources
Hemant Pedanekar writes:
> This patch updates the common machine specific source files with support for
> TI816X.
>
> The approach taken is to have TI816X only build for OMAP3 when
> CONFIG_SOC_OMAPTI816X is defined.
>
> Signed-off-by: Hemant Pedanekar
> ---
> arch/arm/mach-omap2/clock3xxx_data.c |5 +++-
> arch/arm/mach-omap2/common.c | 24 +
> arch/arm/mach-omap2/control.h | 17
> arch/arm/mach-omap2/id.c | 33 ++-
> arch/arm/mach-omap2/include/mach/entry-macro.S | 13 +
> arch/arm/mach-omap2/io.c | 13 -
> arch/arm/mach-omap2/irq.c |5 +++-
> arch/arm/mach-omap2/serial.c |8 +++---
> arch/arm/plat-omap/io.c|5 +++-
> 9 files changed, 113 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
> b/arch/arm/mach-omap2/clock3xxx_data.c
> index 9ab817e..557de99 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3466,6 +3466,9 @@ int __init omap3xxx_clk_init(void)
> } else if (cpu_is_omap3630()) {
> cpu_mask = (RATE_IN_34XX | RATE_IN_36XX);
> cpu_clkflg = CK_36XX;
> + } else if (cpu_is_ti816x()) {
> + cpu_mask = RATE_IN_TI816X;
> + cpu_clkflg = CK_TI816X;
> } else if (cpu_is_omap34xx()) {
> if (omap_rev() == OMAP3430_REV_ES1_0) {
> cpu_mask = RATE_IN_3430ES1;
> @@ -3545,7 +3548,7 @@ int __init omap3xxx_clk_init(void)
> /*
>* Lock DPLL5 and put it in autoidle.
>*/
> - if (omap_rev() >= OMAP3430_REV_ES2_0)
> + if (!cpu_is_ti816x() && (omap_rev() >= OMAP3430_REV_ES2_0))
> omap3_clk_lock_dpll5();
>
> /* Avoid sleeping during omap3_core_dpll_m2_set_rate() */
> diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
> index 778929f..7f58b7f 100644
> --- a/arch/arm/mach-omap2/common.c
> +++ b/arch/arm/mach-omap2/common.c
> @@ -108,6 +108,30 @@ void __init omap3_map_io(void)
> omap2_set_globals_3xxx();
> omap34xx_map_common_io();
> }
> +
> +/*
> + * Adjust TAP register base such that omap3_check_revision accesses the
> correct
> + * TI816X register for checking device ID (it adds 0x204 to tap base while
> + * TI816X DEVICE ID register is at offset 0x600 from control base).
> + */
> +#define TI816X_TAP_BASE (TI816X_CTRL_BASE + \
> + TI816X_CONTROL_DEVICE_ID - 0x204)
> +
> +static struct omap_globals ti816x_globals = {
> + .class = OMAP343X_CLASS,
> + .tap= OMAP2_L4_IO_ADDRESS(TI816X_TAP_BASE),
> + .ctrl = TI816X_CTRL_BASE,
> + .prm= TI816X_PRCM_BASE,
> + .cm = TI816X_PRCM_BASE,
> + .uart1_phys = TI816X_UART1_BASE,
> + .uart2_phys = TI816X_UART2_BASE,
> + .uart3_phys = TI816X_UART3_BASE,
The uart*_phys are not needed. I just sent a patch to remove these from
the core code.
> +};
> +
> +void __init omap2_set_globals_ti816x(void)
> +{
> + __omap2_set_globals(&ti816x_globals);
> +}
> #endif
>
> #if defined(CONFIG_ARCH_OMAP4)
> diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
> index f0629ae..5c87054 100644
> --- a/arch/arm/mach-omap2/control.h
> +++ b/arch/arm/mach-omap2/control.h
> @@ -52,6 +52,11 @@
> #define OMAP343X_CONTROL_PADCONFS_WKUP 0xa00
> #define OMAP343X_CONTROL_GENERAL_WKUP0xa60
>
> +/* TI816X spefic control submodules */
> +#define TI816X_CONTROL_OCPCONF 0x000
> +#define TI816X_CONTROL_DEVBOOT 0x040
> +#define TI816X_CONTROL_DEVCONF 0x600
Not used in this patch (or series)
> /* Control register offsets - read/write with omap_ctrl_{read,write}{bwl}()
> */
>
> #define OMAP2_CONTROL_SYSCONFIG (OMAP2_CONTROL_INTERFACE + 0x10)
> @@ -241,6 +246,18 @@
> #define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250
> #define OMAP3_PADCONF_SAD2D_IDLEACK0x254
>
> +/* TI816X CONTROL_DEVBOOT register offsets */
> +#define TI816X_CONTROL_STATUS(TI816X_CONTROL_DEVBOOT + 0x000)
> +#define TI816X_CONTROL_BOOTSTAT (TI816X_CONTROL_DEVBOOT + 0x004)
> +
> +/* TI816X CONTROL_DEVCONF register offsets */
> +#define TI816X_CONTROL_DEVICE_ID (TI816X_CONTROL_DEVCONF + 0x000)
> +#define TI816X_CONTROL_MAC_ID0_LO(TI816X_CONTROL_DEVCONF + 0x030)
> +#define TI816X_CONTROL_MAC_ID0_HI(TI816X_CONTROL_DEVCONF + 0x034)
> +#define TI816X_CONTROL_MAC_ID1_LO(TI816X_CONTROL_DEVCONF + 0x038)
> +#define TI816X_CONTROL_MAC_ID1_HI(TI816X_CONTROL_DEVCONF + 0x03c)
> +#define TI816X_CONTROL_PCIE_CFG (TI816X_CONTROL_DEVCONF + 0x040)
Not used in this patch (or series)
In general, we don't like to see unused code added in a patch or series.
It is better for review (and also for later
Re: [PATCH v4 1/4] TI816X: Update common omap platform files
Hi Hemant, Hemant Pedanekar writes: > This patch updates the common platform files with TI816X support. Also adds > new > files for TI816X module base addresses and irq definitions. > > The approach taken in this patch is to add TI816X as part of OMAP3 variant > where > the cpu class is considered as OMAP34XX and the type is TI816X. This means, > both > cpu_is_omap34xx() and cpu_is_ti816x() checks return success on TI816X. > > In addition, a kernel config option CONFIG_SOC_OMAPTI816X is also added under > OMAP3 to allow TI816X only build. This option leads to following main > possibilities: > > 1) Multi-OMAP build with CONFIG_SOC_OMAPTI816X: The kernel built only for > TI816X OMAP3 SoCs along with any other OMAP2/4 (e.g., OMAP4s). May not boot > on other OMAP3 SoCs. > > 2) OMAP3 only build with CONFIG_SOC_OMAPTI816X: This will build TI816X > optimized kernel. May not boot on other OMAP3 SoCs. > > 3) OMAP3 only, no CONFIG_SOC_OMAPTI816X: This will build kernel for all > OMAP3s > except TI816X. Note that cpu_is_ti816x checks will return fail. > > Note that OMAP3 only build with support for OMAP3 SoCs as well as TI816X is > not > possible. > > Signed-off-by: Hemant Pedanekar [...] > diff --git a/arch/arm/plat-omap/include/plat/irqs-ti816x.h > b/arch/arm/plat-omap/include/plat/irqs-ti816x.h > new file mode 100644 > index 000..3ec5d1b > --- /dev/null > +++ b/arch/arm/plat-omap/include/plat/irqs-ti816x.h > @@ -0,0 +1,131 @@ > +/* > + * arch/arm/plat-omap/include/plat/irqs-ti816x.h > + * > + * ti816x family interrupts. > + * > + * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/ > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation version 2. > + * > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#ifndef __ARCH_ARM_MACH_OMAP2_TI816X_IRQS_H > +#define __ARCH_ARM_MACH_OMAP2_TI816X_IRQS_H > + > +/* > + * TI816X Interrupts > + */ > +#define TI816X_IRQ_EMU 0 > +#define TI816X_IRQ_COMMTX1 > +#define TI816X_IRQ_COMMRX2 > +#define TI816X_IRQ_BENCH 3 > +#define TI816X_IRQ_ELM 4 > +#define TI816X_IRQ_SSM_WFI 5 > +#define TI816X_IRQ_SSM 6 > +#define TI816X_IRQ_NMI 7 > +#define TI816X_IRQ_SEC_EVNT 8 > +#define TI816X_IRQ_L3_DEBUG 9 > +#define TI816X_IRQ_L3_APP10 > +#define TI816X_IRQ_EDMA_COMP 12 > +#define TI816X_IRQ_EDMA_MPERR13 > +#define TI816X_IRQ_EDMA_ERR 14 > +#define TI816X_IRQ_SATA 16 > +#define TI816X_IRQ_USBSS 17 > +#define TI816X_IRQ_USB0 18 > +#define TI816X_IRQ_USB1 19 > +#define TI816X_IRQ_TPPSS_ERR 20 > +#define TI816X_IRQ_TPPSS_MBOX21 > +#define TI816X_IRQ_TPPSS_STC022 > +#define TI816X_IRQ_TPPSS_STC123 > +#define TI816X_IRQ_TPPSS_DMAPC0 24 > +#define TI816X_IRQ_TPPSS_DMABS0 25 > +#define TI816X_IRQ_TPPSS_ERR026 > +#define TI816X_IRQ_TPPSS_ERR127 > +#define TI816X_IRQ_TPPSS_ERR228 > +#define TI816X_IRQ_TPPSS_ERR329 > +#define TI816X_IRQ_MCARD_TX 30 > +#define TI816X_IRQ_MCARD_RX 31 > +#define TI816X_IRQ_USB_WKUP 34 > +#define TI816X_IRQ_PCIE_WKUP 35 > +#define TI816X_IRQ_DSSINT36 > +#define TI816X_IRQ_GFXINT37 > +#define TI816X_IRQ_HDMIINT 38 > +#define TI816X_IRQ_VLYNQ 39 > +#define TI816X_IRQ_MACRXTHR0 40 > +#define TI816X_IRQ_MACRXINT0 41 > +#define TI816X_IRQ_MACTXINT0 42 > +#define TI816X_IRQ_MACMISC0 43 > +#define TI816X_IRQ_MACRXTHR1 44 > +#define TI816X_IRQ_MACRXINT1 45 > +#define TI816X_IRQ_MACTXINT1 46 > +#define TI816X_IRQ_MACMISC1 47 > +#define TI816X_IRQ_PCIINT0 48 > +#define TI816X_IRQ_PCIINT1 49 > +#define TI816X_IRQ_PCIINT2 50 > +#define TI816X_IRQ_PCIINT3 51 > +#define TI816X_IRQ_SD64 > +#define TI816X_IRQ_SPI 65 > +#define TI816X_IRQ_GPT1 66 > +#define TI816X_IRQ_GPT2 67 > +#define TI816X_IRQ_GPT3 68 > +#define TI816X_IRQ_GPT4 69 > +#define TI816X_IRQ_I2C0 70 > +#define TI816X_IRQ_I2C1 71 > +#define TI816X_IRQ_UART0 72 > +#define TI816X_IRQ_UART1 73 > +#define TI816X_IRQ_UART2 74 > +#define TI816X_IRQ_RTC 75 > +#define TI816X_IRQ_RTC_ALARM 76 > +#define TI816X_IRQ_MBOX 77 > +#define TI816X_IRQ_MCASP0_TX 80 > +#define TI816X_IRQ_MCASP0_RX 81 > +#define TI816X_IRQ_MCASP1_TX 82 > +#define TI816X_IRQ_MCASP1_RX 83 > +#define TI816X_IRQ_MCASP2_TX 84 > +#define TI816X_IRQ_MCASP2_RX 85 > +#define TI816X_IRQ_MCBSP 86 > +#define TI816X_IRQ_SMCD0 87 > +#define TI816X_IRQ_SMCD1 88 > +#define TI816X_IRQ_WDT1 91 > +#defi
[PATCH] OMAP2+: remove unused UART base addresses from omap_globals
Now that omap_hwmod + omap_device is used for OMAP UART device and
driver code, we no longer need the UART physical addresses in
omap_globals.
Note that the #defines for the base addresses are still left in
since they are used by DEBUG_LL and uncompress code.
Build tested for OMAP1 (omap1_defconfig) and OMAP2+ (omap2plus_defconfig)
Signed-off-by: Kevin Hilman
---
Applies on Tony's for-next branch.
arch/arm/mach-omap2/common.c | 14 --
arch/arm/plat-omap/include/plat/common.h |4
2 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index d5eaee3..8044c8a 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -50,9 +50,6 @@ static struct omap_globals omap242x_globals = {
.ctrl = OMAP242X_CTRL_BASE,
.prm= OMAP2420_PRM_BASE,
.cm = OMAP2420_CM_BASE,
- .uart1_phys = OMAP2_UART1_BASE,
- .uart2_phys = OMAP2_UART2_BASE,
- .uart3_phys = OMAP2_UART3_BASE,
};
void __init omap2_set_globals_242x(void)
@@ -71,9 +68,6 @@ static struct omap_globals omap243x_globals = {
.ctrl = OMAP243X_CTRL_BASE,
.prm= OMAP2430_PRM_BASE,
.cm = OMAP2430_CM_BASE,
- .uart1_phys = OMAP2_UART1_BASE,
- .uart2_phys = OMAP2_UART2_BASE,
- .uart3_phys = OMAP2_UART3_BASE,
};
void __init omap2_set_globals_243x(void)
@@ -92,10 +86,6 @@ static struct omap_globals omap3_globals = {
.ctrl = OMAP343X_CTRL_BASE,
.prm= OMAP3430_PRM_BASE,
.cm = OMAP3430_CM_BASE,
- .uart1_phys = OMAP3_UART1_BASE,
- .uart2_phys = OMAP3_UART2_BASE,
- .uart3_phys = OMAP3_UART3_BASE,
- .uart4_phys = OMAP3_UART4_BASE, /* Only on 3630 */
};
void __init omap2_set_globals_3xxx(void)
@@ -119,10 +109,6 @@ static struct omap_globals omap4_globals = {
.prm= OMAP4430_PRM_BASE,
.cm = OMAP4430_CM_BASE,
.cm2= OMAP4430_CM2_BASE,
- .uart1_phys = OMAP4_UART1_BASE,
- .uart2_phys = OMAP4_UART2_BASE,
- .uart3_phys = OMAP4_UART3_BASE,
- .uart4_phys = OMAP4_UART4_BASE,
};
void __init omap2_set_globals_443x(void)
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 29b2afb..1b8095b 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -56,10 +56,6 @@ struct omap_globals {
unsigned long prm;/* Power and Reset Management */
unsigned long cm; /* Clock Management */
unsigned long cm2;
- unsigned long uart1_phys;
- unsigned long uart2_phys;
- unsigned long uart3_phys;
- unsigned long uart4_phys;
};
void omap2_set_globals_242x(void);
--
1.7.3.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4] omap3: Add basic support for 720MHz part
Sanjeev Premi writes: > This patch adds support for new speed enhanced parts with ARM > and IVA running at 720MHz and 520MHz respectively. These parts > can be probed at run-time by reading PRODID.SKUID[3:0] at > 0x4830A20C [1]. >From my earlier review[1] of this patch: Please expand this a little to describe exactly which parts have this feature. All OMAP3? 34xx? 35xx? what about 36xx/37xx? ISTR the runtime probing for this feature is available on 35xx but not on 34xx, but a summary of this should be here. In addition, if I'm recalling correctly about the inability to do runtime detection on non-35xx parts, maybe documenting how board code would enable this OPP would be helpful too. Thanks, Kevin [1] http://marc.info/?l=linux-omap&m=129441890030307&w=2 -- 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] Westbridge software module, fixes errors reported by checkpatch.pl
On Wed, Jan 19, 2011 at 05:31:46PM -0800, Sutharsan Ramamoorthy wrote: > From: Sutharsan Ramamoorthy > > This patch fixes errors in westbridge device controller driver in the > staging tree reported by checkpatch.pl. File containing EXPORT_SYMBOL() > macros for all the APIs exported by the westbridge software has been removed. > EXPORT_SYMBOL() macros are added after the corresponding function definitions. In the future, please wrap your commit messages at 72 characters, so I don't have to edit the patch by hand. Your subject was also quite vague, I've fixed it up, please be more careful in the future. thanks, greg k-h -- 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: Staging: Westbridge: fix EXPORT_SYMBOL errors reported by checkpatch.pl
On Wed, Jan 19, 2011 at 05:31:46PM -0800, Sutharsan Ramamoorthy wrote: > From: Sutharsan Ramamoorthy > > This patch fixes errors in westbridge device controller driver in the > staging tree reported by checkpatch.pl. File containing EXPORT_SYMBOL() > macros for all the APIs exported by the westbridge software has been removed. > EXPORT_SYMBOL() macros are added after the corresponding function definitions. > > Signed-off-by: Sutharsan Ramamoorthy This patch is corrupted and can't be applied. Perhaps it's due to the mime encoding? Anyway, care to fix your email client and resend it so that I can apply it? thanks, greg k-h -- 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 RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc
* Sukumar Ghorai [110119 05:24]:
> add support the irq mode in GPMC.
> gpmc_init() function move after omap_init_irq() as it has dependecy on irq.
>
> diff --git a/arch/arm/mach-omap2/board-2430sdp.c
> b/arch/arm/mach-omap2/board-2430sdp.c
> index e066177..527374f 100644
> --- a/arch/arm/mach-omap2/board-2430sdp.c
> +++ b/arch/arm/mach-omap2/board-2430sdp.c
> @@ -146,6 +146,7 @@ static void __init omap_2430sdp_init_irq(void)
> omap2_init_common_infrastructure();
> omap2_init_common_devices(NULL, NULL);
> omap_init_irq();
> + gpmc_init();
> }
>
> static struct twl4030_gpio_platform_data sdp2430_gpio_data = {
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c
> b/arch/arm/mach-omap2/board-3430sdp.c
> index 8fb5f43..8304d16 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -335,6 +335,7 @@ static void __init omap_3430sdp_init_irq(void)
> omap2_init_common_infrastructure();
> omap2_init_common_devices(hyb18m512160af6_sdrc_params, NULL);
> omap_init_irq();
> + gpmc_init();
> }
...
I think I've commented on this before, but why don't you make gpmc_init
a subsys_initcall? There should be no reason to call this earlier.
If something does not work because of that, then that issue must be
fixed.
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: OMAP3 - PM - Question - Disabling CLKEN and HFCLKOUT signals from TWL4030 scripts
Please see responses inline below.
Hi Nagendra,
> Hi All,
>
> We are working on Power management on OMAP3 (3530) and I am trying to
> disable CLKEN and HFCLKOUT through TWL4030 power scripts. However we have
> not been able to achieve this.
>
> Following are the changes and tests done so far.
>
> - VAUX1, CLKEN and HFCLKOUT were assigned to P1 group.
> - Wrote Singular messages to turn on/off these signals in TWL4030 scripts.
> - We observed that VAUX1 is able to switch ON/OFF properly as per the
script
> but HFCLKOUT and CLKEN are not behaving as expected.
> - However if we try writing CLKEN_DEV_GRP to zero, CLKEN is going low.
> - We have made sure that SYS_OFF_MODE and CLK_REQ signals go low during
the
> system OFF mode, LVL_WAKEUP bit enabled in Px_SW_EVENTS, and STS_CHG bit
in
> STS_HW_CONDITIONS is zero.
>
> Is there anything that I am missing? Kindly let me know.
Did try probing the sys_clkreq from OMAP?
Yes nSLEEP1, nSLEEP2 and SYS_CLK_REQ signals go low during system
OFF mode.
Are you sending SLEEP/OFF command in singular msg?
Yes.
Also check the HFCLKOUT_REMAP register for SLEEP_STATE[3:0], if using SLEEP
cmd.
We are setting SLEEP_STATE field of CLKEN and HFCLKOUT to OFF mode.
PSP version : 3.0.1.6
Following is the TWL4030 power scripts that we are trying to get CLKEN
signal to OFF state. This is based on rx51-peripherals.c
---
static struct twl4030_ins sleep_on_seq[] __initdata = {
{MSG_SINGULAR(DEV_GRP_P1, RES_CLKEN, RES_STATE_OFF), 2},
};
static struct twl4030_script sleep_on_script __initdata = {
.script = sleep_on_seq,
.size = ARRAY_SIZE(sleep_on_seq),
.flags = TWL4030_SLEEP_SCRIPT,
};
static struct twl4030_ins wakeup_seq[] __initdata = {
{MSG_SINGULAR(DEV_GRP_P1, RES_CLKEN, RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wakeup_script __initdata = {
.script = wakeup_seq,
.size = ARRAY_SIZE(wakeup_seq),
.flags = TWL4030_WAKEUP12_SCRIPT,
};
static struct twl4030_ins wakeup_p3_seq[] __initdata = {
{MSG_SINGULAR(DEV_GRP_P3, RES_CLKEN, RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wakeup_p3_script __initdata = {
.script = wakeup_p3_seq,
.size = ARRAY_SIZE(wakeup_p3_seq),
.flags = TWL4030_WAKEUP3_SCRIPT,
};
static struct twl4030_ins wrst_seq[] __initdata = {
/*
* Reset twl4030.
* Reset VDD1 regulator.
* Reset VDD2 regulator.
* Reset VPLL1 regulator.
* Enable sysclk output.
* Reenable twl4030.
*/
{MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
{MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 0, 1, RES_STATE_ACTIVE),
0x13},
{MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_PP, 0, 3, RES_STATE_OFF),
0x13},
{MSG_SINGULAR(DEV_GRP_NULL, RES_VDD1, RES_STATE_WRST), 0x13},
{MSG_SINGULAR(DEV_GRP_NULL, RES_VDD2, RES_STATE_WRST), 0x13},
{MSG_SINGULAR(DEV_GRP_NULL, RES_VPLL1, RES_STATE_WRST), 0x35},
{MSG_SINGULAR(DEV_GRP_P3, RES_HFCLKOUT, RES_STATE_ACTIVE), 2},
{MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wrst_script __initdata = {
.script = wrst_seq,
.size = ARRAY_SIZE(wrst_seq),
.flags = TWL4030_WRST_SCRIPT,
};
static struct twl4030_script *twl4030_scripts[] __initdata = {
/* wakeup12 script should be loaded before sleep script, otherwise a
board might hit retention before loading of wakeup script is
completed. This can cause boot failures depending on timing
issues.
*/
&wakeup_script,
&sleep_on_script,
&wakeup_p3_script,
&wrst_script,
};
static struct twl4030_resconfig twl4030_rconfig[] __initdata = {
{ .resource = RES_CLKEN, .devgroup = DEV_GRP_P1,
.type = -1, .type2 = -1 , .remap_off = RES_STATE_OFF, .remap_sleep
= RES_STATE_OFF
},
{ .resource = RES_HFCLKOUT, .devgroup = -1,
.type = -1, .type2 = -1, .remap_off = RES_STATE_OFF, .remap_sleep
= RES_STATE_OFF
},
{ 0, 0},
};
--
Please let me know your comments.
Regards,
Lesly A M
>
> Part number of TPS used in our board is TPS65950 BZXNR
>
> with regards,
> - Nagendra.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
On Fri, Jan 21, 2011 at 09:00:04AM -0600, Rob Herring wrote:
> Why? If preset_lpj is non-zero, calibrate_delay will effectively be
> skipped which is the same thing your patch does.
Theoretically...
You boot. lpj= sets preset_lpj. calibrate_delay() sets loops_per_jiffy
based on preset_lpj which happens to match the boot CPU speed correctly.
cpufreq initializes, changes the CPU frequency. loops_per_jiffy is
scaled for the new CPU clock rate.
You hot-unplug a CPU, and then hot-plug it back in. calibrate_delay()
gets called again, and it again notices preset_lpj is set. It copies
this value into loops_per_jiffy, overwriting it with what is now a
value which is completely wrong for the current CPU run rate.
> This is the cpfreq loops_per_jiffy adjustment function for SMP:
>
> static inline void adjust_jiffies(unsigned long val, struct
> cpufreq_freqs *ci)
> {
> return;
> }
That means cpufreq scaling on SMP is broken then... Why isn't cpufreq
marked with a !SMP dependence or something similar (eg, depends on
!SMP || CPU_INDEPENDENT_UDELAY)... Maybe it should be.
> And delay.S uses the global loops_per_jiffy, not the per cpu value. The
> only place I see the per cpu value get used is /proc/cpuinfo.
>
> Consider the following sequence:
>
> - scale down the cpu freq
> - hot unplug a core
> - hot plug a core
> - calls calibrate_delay and update the global loops_per_jiffy
> - scale up the cpu freq
> - udelay time is now much too short!!!
>
> So for that reason, I would just remove calibrate_delay unconditionally.
> Better to have the 1% inaccuracy and longer delays at low frequency than
> to have too short of a delay at high freq.
As you've shown above, it makes not a blind bit of difference whether
calibrate_delay() is called... on SMP the loops_per_jiffy will be wrong
as soon as you start scaling no matter what.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
On Fri, Jan 21, 2011 at 07:13:48PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Rob Herring [mailto:robherri...@gmail.com]
> > Sent: Thursday, January 20, 2011 10:05 PM
> > To: Santosh Shilimkar
> > Cc: linux-arm-ker...@lists.infradead.org; Russell King; linux-
> > o...@vger.kernel.org; Linus Walleij
> > Subject: Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK
> > to speed-up boot
>
> [..]
>
> > >>
> > >> There's already one way to do this with pre-calculated lpj.
> > >>
> > > How about the hot-plug path? This is not for just boot.
> >
> > The path is the same for hotplug and secondary boot, so yes for
> > both.
> > Plus you get the added benefit of speeding up the primary core boot
> > as well.
> >
> No 'preset_lpj' will not work for the hotplug path when
> cpufreq is active. It just useful only for boot in
> its current form.
Indeed, it will end up screwing up the loops_per_jiffy value. That
would seem to be a hole on other architectures too. I wonder if
anyone has tested hotplug on a cpufreq-scaled system.
> @@ -332,14 +345,19 @@ void __init smp_cpus_done(unsigned int max_cpus)
> int cpu;
> unsigned long bogosum = 0;
>
> - for_each_online_cpu(cpu)
> - bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
> + if (!skip_secondary_calibrate) {
> + for_each_online_cpu(cpu)
> + bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
>
> - printk(KERN_INFO "SMP: Total of %d processors activated "
> -"(%lu.%02lu BogoMIPS).\n",
> -num_online_cpus(),
> -bogosum / (50/HZ),
> -(bogosum / (5000/HZ)) % 100);
> + printk(KERN_INFO "SMP: Total of %d processors activated "
> +"(%lu.%02lu BogoMIPS).\n",
> + num_online_cpus(),
> + bogosum / (50/HZ),
> + (bogosum / (5000/HZ)) % 100);
> + } else {
> + printk(KERN_INFO "SMP: Total of %d processors
> activated.\n",
> + num_online_cpus());
> + }
Hmm. How about:
char bogosum[32];
if (!skip_secondary_calibrate) {
for_each_online_cpu(cpu)
bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
snprintf(bogosum, sizeof(bogosum), " (%lu.%02lu BogoMIPS).\n",
bogosum / (50/HZ), (bogosum / (5000/HZ)) % 100);
} else
bogosum[0] = '\0';
pr_info("SMP: Total of %d processors activated%s.\n",
num_online_cpus(), bogosum);
Looks neater and more compact and reduces the amount of string space
required.
--
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: [Query] mm: !*pte hit in mm/memory.c:remap_pte_range
Hi Russell,
>
> From: Russell King - ARM Linux [li...@arm.linux.org.uk]
> Sent: Friday, January 21, 2011 4:30 AM
> To: Aguirre, Sergio
> Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
> Subject: Re: [Query] mm: !*pte hit in mm/memory.c:remap_pte_range
>
> On Thu, Jan 20, 2011 at 03:06:30PM -0600, Aguirre, Sergio wrote:
> > And while debugging further, i realized that the point of stall was
> > in mm/memory.c, function:
> >
> > static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
> > unsigned long addr, unsigned long end,
> > unsigned long pfn, pgprot_t prot)
> > {
> > BUG_ON(!pte_none(*pte)); <---*** HERE
> > }
> > How should i interpret this? Does this mean something specific?
>
> It is asserting that the pte we are about to overwrite was empty. In
> other words, there is no existing mapping in place at that virtual
> address.
>
> If there was a pre-existing mapping, you're doing something wrong
> because you're potentially overwriting something else.
Ok. I see.
Thanks for the detailed explanation. I appreciate it.
Regards,
Sergio
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/18] OMAP2,3: hwmod DSS Adaptation
Sumit Semwal writes: > v8 of the DSS hwmod patch series fixes some issues based on findings of > Kevin Hilman on beagle. Thanks. I re-tested on beagle and it looks good. I also briefly tested on beagle with PM. I tested suspend/resume to verify we could still hit full-chip retention. I also verified idle with and without screen blanked. As expected, with the screen (external DVI monitor) active, the DSS power domain did not hit retentiond during idle, but allowing the screen to blank, DSS powerdomain then hits idle. Feel free to add: Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Also, can you repost one more time with the linux-arm-ker...@lists.infradead.org Cc'd? Thanks. Kevin > The VENC platform driver was not getting registered due to missed device > name update for vdda_dac regulator in some board files. This was moved from > 'omap_display' device to 'omap_venc' device in patch 14/18. > > Also, similarly for DSI platform driver, the regulator name 'vdds_dsi' needs > two > instances - one for dpi, and one for dsi. > > This version corrects the above two for all board files where 'vdda_dac' and > 'vdds_dsi' regulators are defined. [patches 14/18 and 15/18] > > Post this change, boot w/ visible framebuffer and tux was successfully > validated > on beagle, 3430SDP and zoom3. > > A patch mentioned in > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42384.html > was needed to get OMAP3 to boot up on top of linux-next of 20110115. > > OMAP4 hwmod support will be posted after the acceptance of this basic change > in > the dss2 design. > > - > [original patch introduction] > > This patch series decouples the "Clocks for DSS in hwmod adaptation" changes > from this series. Another series would be posted which could be discussed > w.r.t clocks in DSS across omap2,3. > > Removing the SYSCONFIG settings from DSS driver would also be part of these > clock changes series and not covered in this series as it depends on some of > the omap_hwmod framework changes w.r.t opt clocks handling. > > Summary of the hwmod DSS design: > > DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each > corresponding to the hwmod class in the hwmod database. > > Each of these platform drivers' init / deinit are handled from core.c's > omap_dss_probe() in the exact sequence as required. > > No Hardcoding of silicon data: > hwmod database abstracts the SOC data like base addr, irq numbers and are > implemented in this patch series. > > Continue to have custom bus for display panels: > "omap_display" driver continues to be a platform driver that registers the > custom > bus. It also continues to register the display panels(omap_dss_device) on the > board to the panel drivers (omap_dss_driver) > For Eg: primary lcd device would be registered with lcd panel driver. > lcd panel driver if it is on a parallel interface would use library functions > exported from dpi.o. if it is on a dsi interface would use library functions > exported from dsi platform driver(dsi.o). > > Clocks: > Handling of clocks in DSS only is one of the design approaches, that does not > change the existing implementation. If each of the DSS HW IPs had to handle > their own clocks, then corresponding clock changes can be requested in the > hwmod > database as well which is not the current design/implementation. As stated, > this would be handled in another series seperately. > For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now > apart > for the dss main clocks. Currently VENC driver needs to be aware of this and > has to > use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. > > > > Current dss driver: > --- > 1. Omapdss platform driver > - initialises necessary Ips dss, dispc. > - also initialises Ips like sdi, dsi, venc, rfbi > - creates a custom bus and registers the display devices/drivers > connected on the board to the custom bus. > > 2. Suspend/resume of omapdss > - in turn sends suspend/resume calls for each of the display devices > registered to it. > > Modified change: > --- > Platform driver for each DSS HW IP in addition to the software "omap_display" > driver. > > Omapdss platform driver > - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, > venc, rfbi] > and software libraries like dpi, sdi. > - continues to have a custom bus and registers the display devices > and drivers connected on the board to the custom bus. > - continues to handle suspend/resume of the display devices registered > to the custom bus. > > DSS platform driver > - initialises DSS IP alone > - Handles the clocks related to the DSS and other DSSHW IPs like RFBI, > DSI, VENC, DISPC. Previously this was a part of "omapdss" driver in > core.c >
RE: [PATCH v4 0/4] Introduce support for TI816X processor series
linux-omap-ow...@vger.kernel.org wrote on : > Pedanekar, Hemant wrote on Monday, January 10, 2011 10:08 PM: > >> This patch set adds support for TI816X processor series. This series >> includes DM8168, C6A816x and AM389x devices. >> >> The details can be found at following links: >> >> http://focus.ti.com/general/docs/gencontent.tsp?contentId=77960 >> http://www.ti.com/ww/en/dsp/davinci-netra/index.shtml >> >> This series is architecturally closer to the OMAP devices. >> Hence, these patches >> are being submitted on linux-omap. >> >> These patches are tested on OMAP3 EVM with multi-omap build. >> >> Note that, additional patches consisting of TI816X specific hwmods, clock >> data and DMTIMER changes, are required to enable successful >> booting on TI816X EVM. >> These patches will follow shortly. >> >> The TI816X support is added as part of OMAP3 variant. The approach taken is >> in accordance to the discussions in thread related to following post: >> http://www.spinics.net/lists/linux-omap/msg41505.html >> >> In addition, TI816X specific customizations/optimizations are handled as a >> part of build configuration CONFIG_SOC_OMAPTI816X. Discussed here: >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41927.html >> >> Hemant Pedanekar (4): >> TI816X: Update common omap platform files >> TI816X: Update common OMAP machine specific sources >> TI816X: Create board support and enable build for TI816X EVM >> TI816X: Add low level debug support >> [...] > > Tony, > Can you please provide the comments on v4 patches? Thanks. - Tony, Do you find this series alright? Please let me know your comments. Thanks. Hemant -- 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: Fail to suspend to ram: "Class driver suspend failed for cpu0"
All right. Thank you. One more question. At this moment, I can wake up the board by keyboard. Can I wake it up on LAN? On Fri, Jan 21, 2011 at 12:09 AM, Kevin Hilman wrote: > Luke Gong writes: > >> Thanks, Kevin. >> >> On Thu, Jan 20, 2011 at 5:54 PM, Kevin Hilman wrote: >>> Luke Gong writes: >>> I have a beagle board with OMAP3530. I ported linux-omap-pm2.6.32 to this board. When I want to let it suspend to ram, >>> >>> This is an old kernel. Any reason you're not using a newer kernel? >> >> I have Angstrom7 with kernel 2.6.32 running on this board. So I >> selected this old version to test. I might try the latest one. >> > > You'll have to get support from the folks making the Angstrom kernel as > I don't keep track of the kernel baseline they use or the local patches > they apply, so can't help you. > > If you can reproduce on current linux-omap, I'll be glad to help. > > Kevin > > >>> it fails and I get the message "Class driver suspend failed for cpu0" >>> >>> This is the CPUfreq driver failing to suspend, probably because there is >>> no CPUfreq driver implemented in your kernel. Try disabling CPU_FREQ in >>> your kernel config. >> >> It seems can suspend to ram after disabling CPU_FREQ. Here is the log: >> >> root@beagleboard:~# echo mem > /sys/power/state >> PM: Syncing filesystems ... done. >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> Suspending console(s) (use no_console_suspend to debug) >> >> * >> Once I hit the keyboard, I get: >> >> root@beagleboard:~# echo mem > /sys/power/state >> PM: Syncing filesystems ... done. >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> Suspending console(s) (use no_console_suspend to debug) >> omapfb omapfb: timeout waiting for FRAME DONE >> Powerdomain (core_pwrdm) didn't enter target state 1 >> Powerdomain (cam_pwrdm) didn't enter target state 1 >> Powerdomain (per_pwrdm) didn't enter target state 1 >> Could not enter target state in pm_suspend >> Restarting tasks ... done. >> root@beagleboard:~# >> *** >> >> I am just curious why the powerdomain didn't enter target state 1. >> >> Another issue is about CPU frequency scaling. Using the original >> Angstrom7, I can scale CPU frequency. But with the linux-omap-pm >> kernel, I cannot do it even though I enable this feature in the config >> file. Is there any solution to support both cpu frequency scaling and >> suspend to ram? >> >> Thanks again for your help. >>> >>> Kevin >>> . Here is the log: root@beagleboard:~# echo mem > /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) omapfb omapfb: timeout waiting for FRAME DONE Class driver suspend failed for cpu0 Restarting tasks ... done. * Is there any idea to fix this problem? Thanks. >>> > -- Luke -- 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: Fail to suspend to ram: "Class driver suspend failed for cpu0"
But at this moment, it seems I cannot use both dvfs and suspend to ram simultaneously :(. On Thu, Jan 20, 2011 at 11:23 PM, Vishwanath Sripathy wrote: > Luke, > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of Luke Gong >> Sent: Friday, January 21, 2011 5:03 AM >> To: Kevin Hilman >> Cc: linux-omap@vger.kernel.org >> Subject: Re: Fail to suspend to ram: "Class driver suspend failed for >> cpu0" >> >> Thanks, Kevin. >> >> On Thu, Jan 20, 2011 at 5:54 PM, Kevin Hilman >> wrote: >> > Luke Gong writes: >> > >> >> I have a beagle board with OMAP3530. I ported linux-omap- >> pm2.6.32 to >> >> this board. When I want to let it suspend to ram, >> > >> > This is an old kernel. Any reason you're not using a newer kernel? >> >> I have Angstrom7 with kernel 2.6.32 running on this board. So I >> selected this old version to test. I might try the latest one. >> >> > >> >> it fails and I get >> >> the message "Class driver suspend failed for cpu0" >> > >> > This is the CPUfreq driver failing to suspend, probably because there > is >> > no CPUfreq driver implemented in your kernel. Try disabling >> CPU_FREQ in >> > your kernel config. >> >> It seems can suspend to ram after disabling CPU_FREQ. Here is the log: >> >> root@beagleboard:~# echo mem > /sys/power/state >> PM: Syncing filesystems ... done. >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> Suspending console(s) (use no_console_suspend to debug) >> >> ** >> *** >> Once I hit the keyboard, I get: >> >> root@beagleboard:~# echo mem > /sys/power/state >> PM: Syncing filesystems ... done. >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> Suspending console(s) (use no_console_suspend to debug) >> omapfb omapfb: timeout waiting for FRAME DONE >> Powerdomain (core_pwrdm) didn't enter target state 1 >> Powerdomain (cam_pwrdm) didn't enter target state 1 >> Powerdomain (per_pwrdm) didn't enter target state 1 >> Could not enter target state in pm_suspend >> Restarting tasks ... done. >> root@beagleboard:~# >> *** >> >> I am just curious why the powerdomain didn't enter target state 1. > It looks like your camera module is not idling upon suspend preventing per > and core to idle. Pls check whether camera driver has implemented > suspend/resume hooks properly. OR you can disable camera module and try. >> >> Another issue is about CPU frequency scaling. Using the original >> Angstrom7, I can scale CPU frequency. But with the linux-omap-pm >> kernel, I cannot do it even though I enable this feature in the config >> file. Is there any solution to support both cpu frequency scaling and >> suspend to ram? > In current linux-omap-pm branch, DVFS feature is not supported and this > work is under progress. Previously DVFS feature was supported in pm branch > using SRF and it has been removed sometime back. > If you really want cpufreq support, you can pick DVFS patches under review > available at: https://patchwork.kernel.org/patch/290542/ > > It's also available in the dvfs tree hosted@ > http://dev.omapzoom.org/?p=thara/omap-dvfs.git;a=shortlog;h=refs/heads/pm- > dvfs > > Vishwa > >> >> Thanks again for your help. >> > >> > Kevin >> > >> >> . Here is the log: >> >> >> >> root@beagleboard:~# echo mem > /sys/power/state >> >> PM: Syncing filesystems ... done. >> >> Freezing user space processes ... (elapsed 0.00 seconds) done. >> >> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. >> >> Suspending console(s) (use no_console_suspend to debug) >> >> omapfb omapfb: timeout waiting for FRAME DONE >> >> Class driver suspend failed for cpu0 >> >> Restarting tasks ... done. >> >> >> >> * >> >> >> >> Is there any idea to fix this problem? Thanks. >> > >> >> >> >> -- >> Luke >> -- >> 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 > -- Luke -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
Santosh,
On 01/21/2011 07:43 AM, Santosh Shilimkar wrote:
-Original Message-
From: Rob Herring [mailto:robherri...@gmail.com]
Sent: Thursday, January 20, 2011 10:05 PM
To: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org; Russell King; linux-
o...@vger.kernel.org; Linus Walleij
Subject: Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK
to speed-up boot
[..]
There's already one way to do this with pre-calculated lpj.
How about the hot-plug path? This is not for just boot.
The path is the same for hotplug and secondary boot, so yes for
both.
Plus you get the added benefit of speeding up the primary core boot
as well.
No 'preset_lpj' will not work for the hotplug path when
cpufreq is active. It just useful only for boot in
its current form.
Why? If preset_lpj is non-zero, calibrate_delay will effectively be
skipped which is the same thing your patch does.
This is the cpfreq loops_per_jiffy adjustment function for SMP:
static inline void adjust_jiffies(unsigned long val, struct
cpufreq_freqs *ci)
{
return;
}
And delay.S uses the global loops_per_jiffy, not the per cpu value. The
only place I see the per cpu value get used is /proc/cpuinfo.
Consider the following sequence:
- scale down the cpu freq
- hot unplug a core
- hot plug a core
- calls calibrate_delay and update the global loops_per_jiffy
- scale up the cpu freq
- udelay time is now much too short!!!
So for that reason, I would just remove calibrate_delay unconditionally.
Better to have the 1% inaccuracy and longer delays at low frequency than
to have too short of a delay at high freq.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 17/18] OMAP2,3: DSS2: Use platform device to get baseaddr
From: Senthilvadivu Guruswamy
DSS, DISPC, DSI, RFBI, VENC baseaddr can be obtained from
platform_get_resource().
This API in turn picks the right silicon baseaddr from the hwmod database.
So hardcoding of base addr could be removed.
Signed-off-by: Sumit Semwal
Reviewed-by: Paul Walmsley
Signed-off-by: Senthilvadivu Guruswamy
---
drivers/video/omap2/dss/dispc.c | 11 ---
drivers/video/omap2/dss/dsi.c | 12 +---
drivers/video/omap2/dss/dss.c | 11 ---
drivers/video/omap2/dss/rfbi.c | 10 +++---
drivers/video/omap2/dss/venc.c | 11 ---
5 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 1c22cf0..381942d 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -42,8 +42,6 @@
#include "dss_features.h"
/* DISPC */
-#define DISPC_BASE 0x48050400
-
#define DISPC_SZ_REGS SZ_4K
struct dispc_reg { u16 idx; };
@@ -3324,6 +3322,8 @@ int dispc_setup_plane(enum omap_plane plane,
static int omap_dispchw_probe(struct platform_device *pdev)
{
u32 rev;
+ struct resource *dispc_mem;
+
dispc.pdev = pdev;
spin_lock_init(&dispc.irq_lock);
@@ -3335,7 +3335,12 @@ static int omap_dispchw_probe(struct platform_device
*pdev)
INIT_WORK(&dispc.error_work, dispc_error_worker);
- dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+ dispc_mem = platform_get_resource(dispc.pdev, IORESOURCE_MEM, 0);
+ if (!dispc_mem) {
+ DSSERR("can't get IORESOURCE_MEM DISPC\n");
+ return -EINVAL;
+ }
+ dispc.base = ioremap(dispc_mem->start, resource_size(dispc_mem));
if (!dispc.base) {
DSSERR("can't ioremap DISPC\n");
return -ENOMEM;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 39a1c04..cab08cb 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -42,8 +42,6 @@
/*#define VERBOSE_IRQ*/
#define DSI_CATCH_MISSING_TE
-#define DSI_BASE 0x4804FC00
-
struct dsi_reg { u16 idx; };
#define DSI_REG(idx) ((const struct dsi_reg) { idx })
@@ -3257,6 +3255,7 @@ static int dsi_init(struct platform_device *pdev)
{
u32 rev;
int r;
+ struct resource *dsi_mem;
spin_lock_init(&dsi.errors_lock);
dsi.errors = 0;
@@ -3283,7 +3282,13 @@ static int dsi_init(struct platform_device *pdev)
dsi.te_timer.function = dsi_te_timeout;
dsi.te_timer.data = 0;
#endif
- dsi.base = ioremap(DSI_BASE, DSI_SZ_REGS);
+ dsi_mem = platform_get_resource(dsi.pdev, IORESOURCE_MEM, 0);
+ if (!dsi_mem) {
+ DSSERR("can't get IORESOURCE_MEM DSI\n");
+ r = -EINVAL;
+ goto err0;
+ }
+ dsi.base = ioremap(dsi_mem->start, resource_size(dsi_mem));
if (!dsi.base) {
DSSERR("can't ioremap DSI\n");
r = -ENOMEM;
@@ -3310,6 +3315,7 @@ err2:
iounmap(dsi.base);
err1:
destroy_workqueue(dsi.workqueue);
+err0:
return r;
}
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 8b7972e..4d7a816 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -34,8 +34,6 @@
#include
#include "dss.h"
-#define DSS_BASE 0x4805
-
#define DSS_SZ_REGSSZ_512
struct dss_reg {
@@ -567,8 +565,15 @@ static int dss_init(bool skip_init)
{
int r;
u32 rev;
+ struct resource *dss_mem;
- dss.base = ioremap(DSS_BASE, DSS_SZ_REGS);
+ dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
+ if (!dss_mem) {
+ DSSERR("can't get IORESOURCE_MEM DSS\n");
+ r = -EINVAL;
+ goto fail0;
+ }
+ dss.base = ioremap(dss_mem->start, resource_size(dss_mem));
if (!dss.base) {
DSSERR("can't ioremap DSS\n");
r = -ENOMEM;
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 93b13c5..fc665a7 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -36,8 +36,6 @@
#include
#include "dss.h"
-#define RFBI_BASE 0x48050800
-
struct rfbi_reg { u16 idx; };
#define RFBI_REG(idx) ((const struct rfbi_reg) { idx })
@@ -1019,6 +1017,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
{
u32 rev;
u32 l;
+ struct resource *rfbi_mem;
rfbi.pdev = pdev;
@@ -1028,7 +1027,12 @@ static int omap_rfbihw_probe(struct platform_device
*pdev)
atomic_set(&rfbi.cmd_fifo_full, 0);
atomic_set(&rfbi.cmd_pending, 0);
- rfbi.base = ioremap(RFBI_BASE, SZ_256);
+ rfbi_mem = platform_get_resource(rfbi.pdev, IORESOURCE_MEM, 0);
+ if (!rfbi_mem) {
+
[PATCH v8 18/18] OMAP2,3: DSS2: Get DSS IRQ from platform device
From: Senthilvadivu Guruswamy
DSS IRQ number can be obtained from platform_get_irq(). This API in turn
picks the right IRQ number belonging to HW IP from the hwmod database.
So hardcoding of IRQ number could be removed.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
Reviewed-by: Paul Walmsley
---
drivers/video/omap2/dss/dss.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 4d7a816..22690e9 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -563,7 +563,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
static int dss_init(bool skip_init)
{
- int r;
+ int r, dss_irq;
u32 rev;
struct resource *dss_mem;
@@ -609,15 +609,18 @@ static int dss_init(bool skip_init)
REG_FLD_MOD(DSS_CONTROL, 0, 2, 2); /* venc clock mode = normal */
#endif
- r = request_irq(INT_24XX_DSS_IRQ,
+ dss_irq = platform_get_irq(dss.pdev, 0);
+ if (dss_irq != -ENXIO) {
+ r = request_irq(dss_irq,
cpu_is_omap24xx()
? dss_irq_handler_omap2
: dss_irq_handler_omap3,
0, "OMAP DSS", NULL);
- if (r < 0) {
- DSSERR("omap2 dss: request_irq failed\n");
- goto fail1;
+ if (r < 0) {
+ DSSERR("omap2 dss: request_irq failed\n");
+ goto fail1;
+ }
}
if (cpu_is_omap34xx()) {
--
1.7.1
--
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 v8 14/18] OMAP2,3: DSS2: VENC: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for VENC is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
Also, venc_vdda_dac reading is moved to venc.c.
VENC platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
drivers/video/omap2/dss/core.c | 28 +--
drivers/video/omap2/dss/dss.h|9 +-
drivers/video/omap2/dss/venc.c | 116 +-
12 files changed, 93 insertions(+), 78 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index d00f356..e0d13ae 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -308,7 +308,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
};
static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
- REGULATOR_SUPPLY("vdda_dac", "omap_display");
+ REGULATOR_SUPPLY("vdda_dac", "omap_venc");
static struct omap_board_config_kernel sdp3430_config[] __initdata = {
};
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 1c36ec8..2e9265e 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -488,7 +488,7 @@ static struct regulator_consumer_supply cm_t35_vsim_supply
= {
};
static struct regulator_consumer_supply cm_t35_vdac_supply =
- REGULATOR_SUPPLY("vdda_dac", "omap_display");
+ REGULATOR_SUPPLY("vdda_dac", "omap_venc");
static struct regulator_consumer_supply cm_t35_vdvi_supply =
REGULATOR_SUPPLY("vdvi", "omap_display");
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 6a2eb49..331b94e 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -199,7 +199,7 @@ static struct omap_dss_board_info devkit8000_dss_data = {
};
static struct regulator_consumer_supply devkit8000_vdda_dac_supply =
- REGULATOR_SUPPLY("vdda_dac", "omap_display");
+ REGULATOR_SUPPLY("vdda_dac", "omap_venc");
static uint32_t board_keymap[] = {
KEY(0, 0, KEY_1),
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index c0a5066..4dd1475 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -229,7 +229,7 @@ static struct omap_dss_board_info beagle_dss_data = {
};
static struct regulator_consumer_supply beagle_vdac_supply =
- REGULATOR_SUPPLY("vdda_dac", "omap_display");
+ REGULATOR_SUPPLY("vdda_dac", "omap_venc");
static struct regulator_consumer_supply beagle_vdvi_supply =
REGULATOR_SUPPLY("vdds_dsi", "omap_display");
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 5f156fe..ec45575 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -493,7 +493,7 @@ static struct twl4030_codec_data omap3evm_codec_data = {
};
static struct regulator_consumer_supply omap3_evm_vdda_dac_supply =
- REGULATOR_SUPPLY("vdda_dac", "omap_display");
+ REGULATOR_SUPPLY("vdda_dac", "omap_venc");
/* VDAC for DSS driving S-Video */
static struct regulator_init_data omap3_evm_vdac = {
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 613ab58..b44e604 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -342,7 +342,7 @@ static struct regulator_consumer_supply
pandora_vmmc3_supply =
REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.2");
static struct regulator_consumer_supply pandora_vdda_dac_supply =
- REGULATOR_SUPPLY("vdda_dac", "omap_display");
+ REGULATOR_SUPPLY("vdda_dac", "omap_venc");
static struct regulator_consumer_supply pandora_vdds_supplies[] = {
REGULATOR_SUPPLY("vdds_sdi", "omap_display"),
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 7671218..ab98a64 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -441,7 +441,7 @@ static struct twl4030_codec_data omap3stalker_codec_data = {
};
static stru
[PATCH v8 15/18] OMAP2,3: DSS2: DSI: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for DSI is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
Also, vdds_dsi regulator handling is copied to dsi.c, since vdds_dsi regulator
is
needed by dpi_init() too. Board files are updated accordingly to add 2
instances of
vdds_dsi regulator.
DSI platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-devkit8000.c | 10 ++--
arch/arm/mach-omap2/board-igep0020.c | 10 ++--
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++--
arch/arm/mach-omap2/board-omap3evm.c | 10 ++--
arch/arm/mach-omap2/board-omap3pandora.c |1 +
arch/arm/mach-omap2/board-omap3stalker.c | 10 ++--
arch/arm/mach-omap2/board-zoom-peripherals.c | 10 ++--
drivers/video/omap2/dss/core.c |8 ++--
drivers/video/omap2/dss/dsi.c| 64 -
drivers/video/omap2/dss/dss.h|8 ++--
11 files changed, 107 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index e0d13ae..33ff4f6 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -533,6 +533,7 @@ static struct regulator_init_data sdp3430_vdac = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+ REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
};
static struct regulator_init_data sdp3430_vpll2 = {
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 331b94e..6cdedd9 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -273,8 +273,10 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
.setup = devkit8000_twl_gpio_setup,
};
-static struct regulator_consumer_supply devkit8000_vpll1_supply =
- REGULATOR_SUPPLY("vdds_dsi", "omap_display");
+static struct regulator_consumer_supply devkit8000_vpll1_supplies[] = {
+ REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+ REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
+};
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data devkit8000_vmmc1 = {
@@ -315,8 +317,8 @@ static struct regulator_init_data devkit8000_vpll1 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = &devkit8000_vpll1_supply,
+ .num_consumer_supplies = ARRAY_SIZE(devkit8000_vpll1_supplies),
+ .consumer_supplies = devkit8000_vpll1_supplies,
};
/* VAUX4 for ads7846 and nubs */
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index d79dcd5..dfbe3a1 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -485,8 +485,10 @@ static struct omap_dss_board_info igep2_dss_data = {
.default_device = &igep2_dvi_device,
};
-static struct regulator_consumer_supply igep2_vpll2_supply =
- REGULATOR_SUPPLY("vdds_dsi", "omap_display");
+static struct regulator_consumer_supply igep2_vpll2_supplies[] = {
+ REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
+ REGULATOR_SUPPLY("vdds_dsi", "omap_dsi1"),
+};
static struct regulator_init_data igep2_vpll2 = {
.constraints = {
@@ -499,8 +501,8 @@ static struct regulator_init_data igep2_vpll2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = &igep2_vpll2_supply,
+ .num_consumer_supplies = ARRAY_SIZE(igep2_vpll2_supplies),
+ .consumer_supplies = igep2_vpll2_supplies,
};
static void __init igep2_display_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 4dd1475..caf6c8a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -231,8 +231,10 @@ static struct omap_dss_board_info beagle_dss_data = {
static struct regulator_consumer_supply beagle_vdac_supply =
REGULATOR_SUPPLY("vdda_dac", "omap_venc");
-static struct regulator_consumer_supply beagle_vdvi_supply =
- REGULATOR_SUPPLY("vdds_dsi", "omap_display");
+static struct regulator_consumer_supply beagle_vdvi_supplies[] = {
+ REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
[PATCH v8 16/18] OMAP2,3: DSS2: replace printk with dev_dbg in init
This patch replaces printk's in the init/probe functions to dev_dbg for boot time optimization. Signed-off-by: Sumit Semwal --- drivers/video/omap2/dss/dispc.c |2 +- drivers/video/omap2/dss/dsi.c |2 +- drivers/video/omap2/dss/rfbi.c |2 +- drivers/video/omap2/dss/venc.c |2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index abfed47..1c22cf0 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -3350,7 +3350,7 @@ static int omap_dispchw_probe(struct platform_device *pdev) dispc_save_context(); rev = dispc_read_reg(DISPC_REVISION); - printk(KERN_INFO "OMAP DISPC rev %d.%d\n", + dev_dbg(&pdev->dev, "OMAP DISPC rev %d.%d\n", FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0)); enable_clocks(0); diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index d854137..39a1c04 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -3300,7 +3300,7 @@ static int dsi_init(struct platform_device *pdev) enable_clocks(1); rev = dsi_read_reg(DSI_REVISION); - printk(KERN_INFO "OMAP DSI rev %d.%d\n", + dev_dbg(&pdev->dev, "OMAP DSI rev %d.%d\n", FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0)); enable_clocks(0); diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c index a64e119..93b13c5 100644 --- a/drivers/video/omap2/dss/rfbi.c +++ b/drivers/video/omap2/dss/rfbi.c @@ -1046,7 +1046,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev) rfbi_write_reg(RFBI_SYSCONFIG, l); rev = rfbi_read_reg(RFBI_REVISION); - printk(KERN_INFO "OMAP RFBI rev %d.%d\n", + dev_dbg(&pdev->dev, "OMAP RFBI rev %d.%d\n", FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0)); rfbi_enable_clocks(0); diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c index 935ae8e..3db9061 100644 --- a/drivers/video/omap2/dss/venc.c +++ b/drivers/video/omap2/dss/venc.c @@ -739,7 +739,7 @@ static int omap_venchw_probe(struct platform_device *pdev) venc_enable_clocks(1); rev_id = (u8)(venc_read_reg(VENC_REV_ID) & 0xff); - printk(KERN_INFO "OMAP VENC rev %d\n", rev_id); + dev_dbg(&pdev->dev, "OMAP VENC rev %d\n", rev_id); venc_enable_clocks(0); -- 1.7.1 -- 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 v8 11/18] OMAP2,3: DSS2: Move clocks from core driver to dss driver
From: Senthilvadivu Guruswamy
All clock management is moved to dss platform driver. clk_get/put APIs use
dss device instead of core platform device.
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So the device name is changed from omap_display to omap_dss in 2420, 2430,
3xxx clock database files. Now the core driver "omap_display" only takes care
of panel registration with the custom bus.
core driver also uses the clk_enable() / clk_disable() APIs exposed by DSS for
clock management.
DSS driver would do clock management of clocks needed by DISPC, RFBI, DSI, VENC
TODO: The clock content would be adapted to omap_hwmod in a seperate series.
Signed-off-by: Senthilvadivu Guruswamy
Acked-by: Paul Walmsley
Signed-off-by: Sumit Semwal
---
arch/arm/mach-omap2/clock2420_data.c |8 +-
arch/arm/mach-omap2/clock2430_data.c |8 +-
arch/arm/mach-omap2/clock3xxx_data.c | 14 +-
drivers/video/omap2/dss/core.c | 343 +-
drivers/video/omap2/dss/dss.c| 334 +-
drivers/video/omap2/dss/dss.h| 13 +-
6 files changed, 360 insertions(+), 360 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index b412958..d2abc2f 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1786,10 +1786,10 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, "gfx_2d_fck", &gfx_2d_fck,CK_242X),
CLK(NULL, "gfx_ick", &gfx_ick, CK_242X),
/* DSS domain clocks */
- CLK("omap_display", "ick", &dss_ick, CK_242X),
- CLK("omap_display", "dss1_fck", &dss1_fck, CK_242X),
- CLK("omap_display", "dss2_fck", &dss2_fck, CK_242X),
- CLK("omap_display", "tv_fck", &dss_54m_fck, CK_242X),
+ CLK("omap_dss", "ick", &dss_ick, CK_242X),
+ CLK("omap_dss", "dss1_fck", &dss1_fck, CK_242X),
+ CLK("omap_dss", "dss2_fck", &dss2_fck, CK_242X),
+ CLK("omap_dss", "tv_fck", &dss_54m_fck, CK_242X),
/* L3 domain clocks */
CLK(NULL, "core_l3_ck", &core_l3_ck,CK_242X),
CLK(NULL, "ssi_fck", &ssi_ssr_sst_fck, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 039155e..663f298 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1890,10 +1890,10 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, "mdm_ick", &mdm_ick, CK_243X),
CLK(NULL, "mdm_osc_ck", &mdm_osc_ck,CK_243X),
/* DSS domain clocks */
- CLK("omap_display", "ick", &dss_ick, CK_243X),
- CLK("omap_display", "dss1_fck", &dss1_fck, CK_243X),
- CLK("omap_display", "dss2_fck", &dss2_fck, CK_243X),
- CLK("omap_display", "tv_fck", &dss_54m_fck, CK_243X),
+ CLK("omap_dss", "ick", &dss_ick, CK_243X),
+ CLK("omap_dss", "dss1_fck", &dss1_fck, CK_243X),
+ CLK("omap_dss", "dss2_fck", &dss2_fck, CK_243X),
+ CLK("omap_dss", "tv_fck", &dss_54m_fck, CK_243X),
/* L3 domain clocks */
CLK(NULL, "core_l3_ck", &core_l3_ck,CK_243X),
CLK(NULL, "ssi_fck", &ssi_ssr_sst_fck, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 8618262..5c97b93 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3357,13 +3357,13 @@ static struct omap_clk omap3xxx_clks[] = {
CLK("omap_rng", "ick", &rng_ick, CK_34XX | CK_36XX),
CLK(NULL, "sha11_ick",&sha11_ick, CK_34XX | CK_36XX),
CLK(NULL, "des1_ick", &des1_ick, CK_34XX | CK_36XX),
- CLK("omap_display", "dss1_fck", &dss1_alwon_fck_3430es1,
CK_3430ES1),
- CLK("omap_display", "dss1_fck", &dss1_alwon_fck_3430es2,
CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
- CLK("omap_display", "tv_fck", &dss_tv_fck,CK_3XXX),
- CLK("omap_display", "video_fck",&dss_96m_fck, CK_3XXX),
- CLK("omap_display", "dss2_fck", &dss2_alwon_fck, CK_3XXX),
- CLK("omap_display", "ick", &dss_ick_3430es1,
CK_3430ES1),
- CLK("omap_display", "ick", &dss_ick_3430es2,
CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
+ CLK("omap_dss", "dss1_fck", &dss1_alwon_fck_3430es1, CK_3430ES1),
+ CLK("omap_dss", "dss1_fck", &dss1_alwon_fck_3430es2, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK("omap_dss", "tv_fck", &dss_tv_fck,CK_3XXX),
+ CLK("omap_dss", "video_fck",&dss_96m_fck, CK_3XXX),
+ CLK("omap_dss", "dss2_fck", &dss2_al
[PATCH v8 12/18] OMAP2,3: DSS2: RFBI: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for RFBI is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
RFBI platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
---
drivers/video/omap2/dss/core.c |8 ++--
drivers/video/omap2/dss/dss.h |8 ++--
drivers/video/omap2/dss/rfbi.c | 110
3 files changed, 74 insertions(+), 52 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index bdb952f..d4b3da3 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -201,9 +201,9 @@ static int omap_dss_probe(struct platform_device *pdev)
/* keep clocks enabled to prevent context saves/restores during init */
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
- r = rfbi_init();
+ r = rfbi_init_platform_driver();
if (r) {
- DSSERR("Failed to initialize rfbi\n");
+ DSSERR("Failed to initialize rfbi platform driver\n");
goto err_rfbi;
}
@@ -285,7 +285,7 @@ err_venc:
err_dispc:
dpi_exit();
err_dpi:
- rfbi_exit();
+ rfbi_uninit_platform_driver();
err_rfbi:
dss_uninit_platform_driver();
err_dss:
@@ -303,7 +303,7 @@ static int omap_dss_remove(struct platform_device *pdev)
venc_exit();
dispc_exit();
dpi_exit();
- rfbi_exit();
+ rfbi_uninit_platform_driver();
if (cpu_is_omap34xx()) {
dsi_exit();
sdi_exit();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index c535ee1..0ba4bdb 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -428,8 +428,8 @@ static inline void venc_exit(void)
/* RFBI */
#ifdef CONFIG_OMAP2_DSS_RFBI
-int rfbi_init(void);
-void rfbi_exit(void);
+int rfbi_init_platform_driver(void);
+void rfbi_uninit_platform_driver(void);
void rfbi_dump_regs(struct seq_file *s);
int rfbi_configure(int rfbi_module, int bpp, int lines);
@@ -440,11 +440,11 @@ void rfbi_set_timings(int rfbi_module, struct
rfbi_timings *t);
unsigned long rfbi_get_max_tx_rate(void);
int rfbi_init_display(struct omap_dss_device *display);
#else
-static inline int rfbi_init(void)
+static inline int rfbi_init_platform_driver(void)
{
return 0;
}
-static inline void rfbi_exit(void)
+static inline void rfbi_uninit_platform_driver(void)
{
}
#endif
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 10a2ffe..a64e119 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -100,6 +100,7 @@ static int rfbi_convert_timings(struct rfbi_timings *t);
static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
static struct {
+ struct platform_device *pdev;
void __iomem*base;
unsigned long l4_khz;
@@ -957,50 +958,6 @@ void rfbi_dump_regs(struct seq_file *s)
#undef DUMPREG
}
-int rfbi_init(void)
-{
- u32 rev;
- u32 l;
-
- spin_lock_init(&rfbi.cmd_lock);
-
- init_completion(&rfbi.cmd_done);
- atomic_set(&rfbi.cmd_fifo_full, 0);
- atomic_set(&rfbi.cmd_pending, 0);
-
- rfbi.base = ioremap(RFBI_BASE, SZ_256);
- if (!rfbi.base) {
- DSSERR("can't ioremap RFBI\n");
- return -ENOMEM;
- }
-
- rfbi_enable_clocks(1);
-
- msleep(10);
-
- rfbi.l4_khz = dss_clk_get_rate(DSS_CLK_ICK) / 1000;
-
- /* Enable autoidle and smart-idle */
- l = rfbi_read_reg(RFBI_SYSCONFIG);
- l |= (1 << 0) | (2 << 3);
- rfbi_write_reg(RFBI_SYSCONFIG, l);
-
- rev = rfbi_read_reg(RFBI_REVISION);
- printk(KERN_INFO "OMAP RFBI rev %d.%d\n",
- FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
-
- rfbi_enable_clocks(0);
-
- return 0;
-}
-
-void rfbi_exit(void)
-{
- DSSDBG("rfbi_exit\n");
-
- iounmap(rfbi.base);
-}
-
int omapdss_rfbi_display_enable(struct omap_dss_device *dssdev)
{
int r;
@@ -1056,3 +1013,68 @@ int rfbi_init_display(struct omap_dss_device *dssdev)
dssdev->caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
return 0;
}
+
+/* RFBI HW IP initialisation */
+static int omap_rfbihw_probe(struct platform_device *pdev)
+{
+ u32 rev;
+ u32 l;
+
+ rfbi.pdev = pdev;
+
+ spin_lock_init(&rfbi.cmd_lock);
+
+ init_completion(&rfbi.cmd_done);
+ atomic_set(&rfbi.cmd_fifo_full, 0);
+ atomic_set(&rfbi.cmd_pending, 0);
+
+ rfbi.base = ioremap(RFBI_BASE, SZ_256);
+ if (!rfbi.base) {
+ DSSERR("can't ioremap RFBI\n");
+ return -ENOMEM;
+ }
+
+ rfbi_enable_clocks(1);
+
+ msleep(10);
+
+
[PATCH v8 13/18] OMAP2,3: DSS2: DISPC: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for DISPC is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
DISPC platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
---
drivers/video/omap2/dss/core.c |8 ++--
drivers/video/omap2/dss/dispc.c | 105 ---
drivers/video/omap2/dss/dss.h |4 +-
3 files changed, 70 insertions(+), 47 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index d4b3da3..5acb5e6 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -213,9 +213,9 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_dpi;
}
- r = dispc_init();
+ r = dispc_init_platform_driver();
if (r) {
- DSSERR("Failed to initialize dispc\n");
+ DSSERR("Failed to initialize dispc platform driver\n");
goto err_dispc;
}
@@ -281,7 +281,7 @@ err_dsi:
err_sdi:
venc_exit();
err_venc:
- dispc_exit();
+ dispc_uninit_platform_driver();
err_dispc:
dpi_exit();
err_dpi:
@@ -301,7 +301,7 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_uninitialize_debugfs();
venc_exit();
- dispc_exit();
+ dispc_uninit_platform_driver();
dpi_exit();
rfbi_uninit_platform_driver();
if (cpu_is_omap34xx()) {
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 9f8c69f..abfed47 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -178,6 +178,7 @@ struct dispc_irq_stats {
};
static struct {
+ struct platform_device *pdev;
void __iomem*base;
u32 fifo_size[3];
@@ -3269,47 +3270,6 @@ static void _omap_dispc_initial_config(void)
dispc_read_plane_fifo_sizes();
}
-int dispc_init(void)
-{
- u32 rev;
-
- spin_lock_init(&dispc.irq_lock);
-
-#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
- spin_lock_init(&dispc.irq_stats_lock);
- dispc.irq_stats.last_reset = jiffies;
-#endif
-
- INIT_WORK(&dispc.error_work, dispc_error_worker);
-
- dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
- if (!dispc.base) {
- DSSERR("can't ioremap DISPC\n");
- return -ENOMEM;
- }
-
- enable_clocks(1);
-
- _omap_dispc_initial_config();
-
- _omap_dispc_initialize_irq();
-
- dispc_save_context();
-
- rev = dispc_read_reg(DISPC_REVISION);
- printk(KERN_INFO "OMAP DISPC rev %d.%d\n",
- FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
-
- enable_clocks(0);
-
- return 0;
-}
-
-void dispc_exit(void)
-{
- iounmap(dispc.base);
-}
-
int dispc_enable_plane(enum omap_plane plane, bool enable)
{
DSSDBG("dispc_enable_plane %d, %d\n", plane, enable);
@@ -3359,3 +3319,66 @@ int dispc_setup_plane(enum omap_plane plane,
return r;
}
+
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+ u32 rev;
+ dispc.pdev = pdev;
+
+ spin_lock_init(&dispc.irq_lock);
+
+#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
+ spin_lock_init(&dispc.irq_stats_lock);
+ dispc.irq_stats.last_reset = jiffies;
+#endif
+
+ INIT_WORK(&dispc.error_work, dispc_error_worker);
+
+ dispc.base = ioremap(DISPC_BASE, DISPC_SZ_REGS);
+ if (!dispc.base) {
+ DSSERR("can't ioremap DISPC\n");
+ return -ENOMEM;
+ }
+
+ enable_clocks(1);
+
+ _omap_dispc_initial_config();
+
+ _omap_dispc_initialize_irq();
+
+ dispc_save_context();
+
+ rev = dispc_read_reg(DISPC_REVISION);
+ printk(KERN_INFO "OMAP DISPC rev %d.%d\n",
+ FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
+
+ enable_clocks(0);
+
+ return 0;
+}
+
+static int omap_dispchw_remove(struct platform_device *pdev)
+{
+ iounmap(dispc.base);
+ return 0;
+}
+
+static struct platform_driver omap_dispchw_driver = {
+ .probe = omap_dispchw_probe,
+ .remove = omap_dispchw_remove,
+ .driver = {
+ .name = "omap_dispc",
+ .owner = THIS_MODULE,
+ },
+};
+
+int dispc_init_platform_driver(void)
+{
+ return platform_driver_register(&omap_dispchw_driver);
+}
+
+void dispc_uninit_platform_driver(void)
+{
+ return platform_driver_unregister(&omap_dispchw_driver);
+}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 0ba4bdb..f4835c8 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -319,8 +319,8 @@ static inline void dpi_exit(void
[PATCH v8 09/18] OMAP2,3: DSS2: Build omap_device for each DSS HWIP
From: Senthilvadivu Guruswamy
Looks up the hwmod database for each of the given DSS HW IP and builds
omap_device which inturn does the platform device register for each of DSS HW IP
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
---
arch/arm/mach-omap2/display.c | 50 +
arch/arm/plat-omap/include/plat/display.h |5 +++
2 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 6e21cb8..5c0a78b 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include
#include
+#include
+#include
static struct platform_device omap_display_device = {
.name = "omap_display",
@@ -32,10 +34,58 @@ static struct platform_device omap_display_device = {
},
};
+static struct omap_device_pm_latency omap_dss_latency[] = {
+ [0] = {
+ .deactivate_func= omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
int __init omap_display_init(struct omap_dss_board_info
*board_data)
{
int r = 0;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ int i;
+ struct omap_display_platform_data pdata;
+
+ /*
+* omap: valid DSS hwmod names
+* omap2,3: dss_core, dss_dispc, dss_rfbi, dss_venc
+* omap3: dss_dsi1
+*/
+ char *oh_name[] = {"dss_core", "dss_dispc", "dss_rfbi", "dss_venc",
"dss_dsi1"};
+ char *dev_name[] = { "omap_dss", "omap_dispc", "omap_rfbi",
"omap_venc", "omap_dsi1" };
+ int oh_count;
+
+ memset(&pdata, 0, sizeof(pdata));
+
+ if (cpu_is_omap24xx())
+ oh_count = ARRAY_SIZE(oh_name) - 1;
+ /* last hwmod dev in oh_name is not available for omap2 */
+ else
+ oh_count = ARRAY_SIZE(oh_name);
+
+ pdata.board_data = board_data;
+ pdata.board_data->get_last_off_on_transaction_id = NULL;
+
+ for (i = 0; i < oh_count; i++) {
+ oh = omap_hwmod_lookup(oh_name[i]);
+ if (!oh) {
+ pr_err("Could not look up %s\n", oh_name[i]);
+ return -ENODEV;
+ }
+ od = omap_device_build(dev_name[i], -1, oh, &pdata,
+ sizeof(struct omap_display_platform_data),
+ omap_dss_latency,
+ ARRAY_SIZE(omap_dss_latency), 0);
+
+ if (WARN((IS_ERR(od)), "Could not build omap_device for %s\n",
+ oh_name[i]))
+ return -ENODEV;
+ }
omap_display_device.dev.platform_data = board_data;
r = platform_device_register(&omap_display_device);
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 0f140ec..2fb057e 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -237,6 +237,11 @@ static inline int omap_display_init(struct
omap_dss_board_info *board_data)
}
#endif
+struct omap_display_platform_data {
+ struct omap_dss_board_info *board_data;
+ /* TODO: Additional members to be added when PM is considered */
+};
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
--
1.7.1
--
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 v8 10/18] OMAP2,3: DSS2: DSS: create platform_driver, move init,exit to driver
From: Senthilvadivu Guruswamy
Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver of DSS is created and init exit methods are moved from
core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.
DSS platform driver is registered from inside omap_dss_probe, in the order
desired.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
---
drivers/video/omap2/dss/core.c | 19 ++---
drivers/video/omap2/dss/dss.c | 55 ++-
drivers/video/omap2/dss/dss.h |4 +-
3 files changed, 64 insertions(+), 14 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 1bbc004..1aace9e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -517,15 +517,9 @@ static int omap_dss_probe(struct platform_device *pdev)
core.ctx_id = dss_get_ctx_id();
DSSDBG("initial ctx id %u\n", core.ctx_id);
-#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
- /* DISPC_CONTROL */
- if (omap_readl(0x48050440) & 1) /* LCD enabled? */
- skip_init = 1;
-#endif
-
- r = dss_init(skip_init);
+ r = dss_init_platform_driver();
if (r) {
- DSSERR("Failed to initialize DSS\n");
+ DSSERR("Failed to initialize DSS platform driver\n");
goto err_dss;
}
@@ -553,6 +547,11 @@ static int omap_dss_probe(struct platform_device *pdev)
goto err_venc;
}
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) & 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
if (cpu_is_omap34xx()) {
r = sdi_init(skip_init);
if (r) {
@@ -610,7 +609,7 @@ err_dispc:
err_dpi:
rfbi_exit();
err_rfbi:
- dss_exit();
+ dss_uninit_platform_driver();
err_dss:
dss_clk_disable_all_no_ctx();
dss_put_clocks();
@@ -635,7 +634,7 @@ static int omap_dss_remove(struct platform_device *pdev)
sdi_exit();
}
- dss_exit();
+ dss_uninit_platform_driver();
/*
* As part of hwmod changes, DSS is not the only controller of dss
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 77c3621..d130f04 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -59,6 +59,7 @@ struct dss_reg {
dss_write_reg(idx, FLD_MOD(dss_read_reg(idx), val, start, end))
static struct {
+ struct platform_device *pdev;
void __iomem*base;
struct clk *dpll4_m4_ck;
@@ -549,7 +550,7 @@ void dss_set_dac_pwrdn_bgz(bool enable)
REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
}
-int dss_init(bool skip_init)
+static int dss_init(bool skip_init)
{
int r;
u32 rev;
@@ -629,7 +630,7 @@ fail0:
return r;
}
-void dss_exit(void)
+static void dss_exit(void)
{
if (cpu_is_omap34xx())
clk_put(dss.dpll4_m4_ck);
@@ -639,3 +640,53 @@ void dss_exit(void)
iounmap(dss.base);
}
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ int r;
+ int skip_init = 0;
+
+ dss.pdev = pdev;
+
+#ifdef CONFIG_FB_OMAP_BOOTLOADER_INIT
+ /* DISPC_CONTROL */
+ if (omap_readl(0x48050440) & 1) /* LCD enabled? */
+ skip_init = 1;
+#endif
+
+ r = dss_init(skip_init);
+ if (r) {
+ DSSERR("Failed to initialize DSS\n");
+ goto err_dss;
+ }
+
+err_dss:
+
+ return r;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ dss_exit();
+
+ return 0;
+}
+
+static struct platform_driver omap_dsshw_driver = {
+ .probe = omap_dsshw_probe,
+ .remove = omap_dsshw_remove,
+ .driver = {
+ .name = "omap_dss",
+ .owner = THIS_MODULE,
+ },
+};
+
+int dss_init_platform_driver(void)
+{
+ return platform_driver_register(&omap_dsshw_driver);
+}
+
+void dss_uninit_platform_driver(void)
+{
+ return platform_driver_unregister(&omap_dsshw_driver);
+}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index b394951..37c4544 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -214,8 +214,8 @@ void dss_overlay_setup_l4_manager(struct
omap_overlay_manager *mgr);
void dss_recheck_connections(struct omap_dss_device *dssdev, bool force);
/* DSS */
-int dss_init(bool skip_init);
-void dss_exit(void);
+int dss_init_platform_driver(void);
+void dss_uninit_platform_driver(void);
void dss_save_context(void);
void dss_restore_context(void);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
[PATCH v8 08/18] OMAP2,3: DSS2: board files: replace platform_device_register with omap_display_init()
From: Senthilvadivu Guruswamy
This patch updated board files to replace platform_device_register or
platform_add_devices of DSS with omap_display_init(). This moves away
registration of DSS from board files into a common place.
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
---
arch/arm/mach-omap2/board-3430sdp.c | 14 +-
arch/arm/mach-omap2/board-am3517evm.c| 16 +---
arch/arm/mach-omap2/board-cm-t35.c | 10 +-
arch/arm/mach-omap2/board-devkit8000.c | 10 +-
arch/arm/mach-omap2/board-igep0020.c | 10 +-
arch/arm/mach-omap2/board-omap3beagle.c | 10 +-
arch/arm/mach-omap2/board-omap3evm.c | 14 +-
arch/arm/mach-omap2/board-omap3pandora.c | 10 +-
arch/arm/mach-omap2/board-omap3stalker.c | 10 +-
arch/arm/mach-omap2/board-rx51-video.c | 15 +--
arch/arm/mach-omap2/board-zoom-display.c | 15 +--
11 files changed, 11 insertions(+), 123 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index d99902c..d00f356 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -307,21 +307,9 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device = &sdp3430_lcd_device,
};
-static struct platform_device sdp3430_dss_device = {
- .name = "omap_display",
- .id = -1,
- .dev= {
- .platform_data = &sdp3430_dss_data,
- },
-};
-
static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
REGULATOR_SUPPLY("vdda_dac", "omap_display");
-static struct platform_device *sdp3430_devices[] __initdata = {
- &sdp3430_dss_device,
-};
-
static struct omap_board_config_kernel sdp3430_config[] __initdata = {
};
@@ -796,7 +784,7 @@ static void __init omap_3430sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3430_i2c_init();
- platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+ omap_display_init(&sdp3430_dss_data);
if (omap_rev() > OMAP3430_REV_ES1_0)
ts_gpio = SDP3430_TS_GPIO_IRQ_SDPV2;
else
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 6bb5f53..548f524 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -378,24 +378,12 @@ static struct omap_dss_board_info am3517_evm_dss_data = {
.default_device = &am3517_evm_lcd_device,
};
-static struct platform_device am3517_evm_dss_device = {
- .name = "omap_display",
- .id = -1,
- .dev= {
- .platform_data = &am3517_evm_dss_data,
- },
-};
-
/*
* Board initialization
*/
static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
};
-static struct platform_device *am3517_evm_devices[] __initdata = {
- &am3517_evm_dss_device,
-};
-
static void __init am3517_evm_init_irq(void)
{
omap_board_config = am3517_evm_config;
@@ -495,9 +483,7 @@ static void __init am3517_evm_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
am3517_evm_i2c_init();
- platform_add_devices(am3517_evm_devices,
- ARRAY_SIZE(am3517_evm_devices));
-
+ omap_display_init(&am3517_evm_dss_data);
omap_serial_init();
/* Configure GPIO for EHCI port */
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 22322d1..1c36ec8 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -401,14 +401,6 @@ static struct omap_dss_board_info cm_t35_dss_data = {
.default_device = &cm_t35_dvi_device,
};
-static struct platform_device cm_t35_dss_device = {
- .name = "omap_display",
- .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 */
@@ -468,7 +460,7 @@ static void __init cm_t35_init_display(void)
msleep(50);
gpio_set_value(lcd_en_gpio, 1);
- err = platform_device_register(&cm_t35_dss_device);
+ err = omap_display_init(&cm_t35_dss_data);
if (err) {
pr_err("CM-T35: failed to register DSS device\n");
goto err_dev_reg;
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index ca8e1b1..6a2eb49 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -198,14 +198,6 @@ static struct omap_dss_board_info devkit8000_dss_data = {
.default_device = &devkit8000_lcd_device,
};
-static struct platform_device devkit
[PATCH v8 06/18] OMAP2,3 DSS2 Use Regulator init with driver name
From: Senthilvadivu Guruswamy
Use driver name in regulator inits needed for display instead of using device
structure name.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
---
arch/arm/mach-omap2/board-3430sdp.c | 11 +++
arch/arm/mach-omap2/board-cm-t35.c | 12
arch/arm/mach-omap2/board-igep0020.c |6 ++
arch/arm/mach-omap2/board-omap3evm.c |6 ++
arch/arm/mach-omap2/board-omap3stalker.c | 12
5 files changed, 15 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 6f4e7cf..d99902c 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -315,10 +315,8 @@ static struct platform_device sdp3430_dss_device = {
},
};
-static struct regulator_consumer_supply sdp3430_vdda_dac_supply = {
- .supply = "vdda_dac",
- .dev= &sdp3430_dss_device.dev,
-};
+static struct regulator_consumer_supply sdp3430_vdda_dac_supply =
+ REGULATOR_SUPPLY("vdda_dac", "omap_display");
static struct platform_device *sdp3430_devices[] __initdata = {
&sdp3430_dss_device,
@@ -546,10 +544,7 @@ static struct regulator_init_data sdp3430_vdac = {
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
- {
- .supply = "vdds_dsi",
- .dev= &sdp3430_dss_device.dev,
- }
+ REGULATOR_SUPPLY("vdds_dsi", "omap_display"),
};
static struct regulator_init_data sdp3430_vpll2 = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 79f87ec..22322d1 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -495,15 +495,11 @@ static struct regulator_consumer_supply
cm_t35_vsim_supply = {
.supply = "vmmc_aux",
};
-static struct regulator_consumer_supply cm_t35_vdac_supply = {
- .supply = "vdda_dac",
- .dev= &cm_t35_dss_device.dev,
-};
+static struct regulator_consumer_supply cm_t35_vdac_supply =
+ REGULATOR_SUPPLY("vdda_dac", "omap_display");
-static struct regulator_consumer_supply cm_t35_vdvi_supply = {
- .supply = "vdvi",
- .dev= &cm_t35_dss_device.dev,
-};
+static struct regulator_consumer_supply cm_t35_vdvi_supply =
+ REGULATOR_SUPPLY("vdvi", "omap_display");
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data cm_t35_vmmc1 = {
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 23abfa3..238c69e 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -493,10 +493,8 @@ static struct platform_device igep2_dss_device = {
},
};
-static struct regulator_consumer_supply igep2_vpll2_supply = {
- .supply = "vdds_dsi",
- .dev= &igep2_dss_device.dev,
-};
+static struct regulator_consumer_supply igep2_vpll2_supply =
+ REGULATOR_SUPPLY("vdds_dsi", "omap_display");
static struct regulator_init_data igep2_vpll2 = {
.constraints = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 4ad3c4d..32ac816 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -500,10 +500,8 @@ static struct twl4030_codec_data omap3evm_codec_data = {
.audio = &omap3evm_audio_data,
};
-static struct regulator_consumer_supply omap3_evm_vdda_dac_supply = {
- .supply = "vdda_dac",
- .dev= &omap3_evm_dss_device.dev,
-};
+static struct regulator_consumer_supply omap3_evm_vdda_dac_supply =
+ REGULATOR_SUPPLY("vdda_dac", "omap_display");
/* VDAC for DSS driving S-Video */
static struct regulator_init_data omap3_evm_vdac = {
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 51c010c..7b675cb 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -448,10 +448,8 @@ static struct twl4030_codec_data omap3stalker_codec_data =
{
.audio = &omap3stalker_audio_data,
};
-static struct regulator_consumer_supply omap3_stalker_vdda_dac_supply = {
- .supply = "vdda_dac",
- .dev= &omap3_stalker_dss_device.dev,
-};
+static struct regulator_consumer_supply omap3_stalker_vdda_dac_supply =
+ REGULATOR_SUPPLY("vdda_dac", "omap_display");
/* VDAC for DSS driving S-Video */
static struct regulator_init_data omap3_stalker_vdac = {
@@ -469,10 +467,8 @@ static struct regulator_init_data omap3_stalker_vdac = {
};
/* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_stalker_vpll2_supply = {
- .supply = "vdds_dsi",
- .dev
[PATCH v8 07/18] OMAP2,3: DSS2: Create new file display.c for central dss driver registration.
A new file display.c is introduced for display driver init, which adds a
function
omap_display_init to do the DSS driver registration. This is the first step in
moving
away registration of DSS from board files into a common place.
Signed-off-by: Senthilvadivu Guruswamy
Signed-off-by: Sumit Semwal
---
arch/arm/mach-omap2/Makefile |3 ++
arch/arm/mach-omap2/display.c | 46 +
arch/arm/plat-omap/include/plat/display.h | 11 +++
3 files changed, 60 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/display.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1c0c2b0..2e81173 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -242,3 +242,6 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
+
+disp-$(CONFIG_OMAP2_DSS) := display.o
+obj-y += $(disp-m) $(disp-y)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
new file mode 100644
index 000..6e21cb8
--- /dev/null
+++ b/arch/arm/mach-omap2/display.c
@@ -0,0 +1,46 @@
+/*
+ * OMAP2plus display device setup / initialization.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Senthilvadivu Guruswamy
+ * Sumit Semwal
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static struct platform_device omap_display_device = {
+ .name = "omap_display",
+ .id= -1,
+ .dev= {
+ .platform_data = NULL,
+ },
+};
+
+int __init omap_display_init(struct omap_dss_board_info
+ *board_data)
+{
+ int r = 0;
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(&omap_display_device);
+ if (r < 0)
+ printk(KERN_ERR "Unable to register OMAP-Display device\n");
+
+ return r;
+}
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 537f4e4..0f140ec 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#define DISPC_IRQ_FRAMEDONE(1 << 0)
@@ -226,6 +227,16 @@ struct omap_dss_board_info {
struct omap_dss_device *default_device;
};
+#if defined(CONFIG_OMAP2_DSS_MODULE) || defined(CONFIG_OMAP2_DSS)
+/* Init with the board info */
+extern int omap_display_init(struct omap_dss_board_info *board_data);
+#else
+static inline int omap_display_init(struct omap_dss_board_info *board_data)
+{
+ return 0;
+}
+#endif
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
--
1.7.1
--
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 v8 04/18] OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC
From: Senthilvadivu Guruswamy
Hwmod needs database of all IPs in a system. This patch generates the hwmod
database for Display Sub System applicable for OMAP3430 and
OMAP36xx. DSS is also considered as an IP as DISPC, RFBI and named as dss_core.
For all the IP modules in DSS, same clock is needed for enabling. Hwmod sees
DSS IPs as independent IPs, so same clock has to be repeated for .main_clk in
each IP.
This patch defines separate hwmod databases for OMAP3430ES1 and (OMAP3430ES2 and
OMAP36xx) as OMAP3430ES1 does not have IDLEST bit to poll on for dss IP, and
also
the firewall regions are different between 3430es1 and later.
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 433
arch/arm/plat-omap/include/plat/l3_3xxx.h | 20 ++
arch/arm/plat-omap/include/plat/l4_3xxx.h | 10 +
3 files changed, 463 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/l3_3xxx.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8d81813..713165d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,12 @@ static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
static struct omap_hwmod omap3xxx_wd_timer2_hwmod;
+static struct omap_hwmod omap3430es1_dss_core_hwmod;
+static struct omap_hwmod omap3xxx_dss_core_hwmod;
+static struct omap_hwmod omap3xxx_dss_dispc_hwmod;
+static struct omap_hwmod omap3xxx_dss_dsi1_hwmod;
+static struct omap_hwmod omap3xxx_dss_rfbi_hwmod;
+static struct omap_hwmod omap3xxx_dss_venc_hwmod;
static struct omap_hwmod omap3xxx_i2c1_hwmod;
static struct omap_hwmod omap3xxx_i2c2_hwmod;
static struct omap_hwmod omap3xxx_i2c3_hwmod;
@@ -84,6 +91,19 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_main_slaves[] =
{
&omap3xxx_mpu__l3_main,
};
+/* DSS -> l3 */
+static struct omap_hwmod_ocp_if omap3xxx_dss__l3 = {
+ .master = &omap3xxx_dss_core_hwmod,
+ .slave = &omap3xxx_l3_main_hwmod,
+ .fw = {
+ .omap2 = {
+ .l3_perm_bit = OMAP3_L3_CORE_FW_INIT_ID_DSS,
+ .flags = OMAP_FIREWALL_L3,
+ }
+ },
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Master interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap3xxx_l3_main_masters[] = {
&omap3xxx_l3_main__l4_core,
@@ -664,6 +684,410 @@ static struct omap_hwmod_class i2c_class = {
.sysc = &i2c_sysc,
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dss_hwmod_class = {
+ .name = "dss",
+ .sysc = &omap3xxx_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap3xxx_dss_irqs[] = {
+ { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_dss_sdma_chs[] = {
+ { .name = "dispc", .dma_req = 5 },
+ { .name = "dsi1", .dma_req = 74 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dss_masters[] = {
+ &omap3xxx_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core -> dss */
+static struct omap_hwmod_ocp_if omap3430es1_l4_core__dss = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap3430es1_dss_core_hwmod,
+ .clk= "dss_ick",
+ .addr = omap3xxx_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_dss_addrs),
+ .fw = {
+ .omap2 = {
+ .l4_fw_region = OMAP3ES1_L4_CORE_FW_DSS_CORE_REGION,
+ .l4_prot_group = OMAP3_L4_CORE_FW_DSS_PROT_GROUP,
+ .flags = OMAP_FIREWALL_L4,
+ }
+ },
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dss = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap3xxx_dss_core_hwmod,
+ .clk= "dss_ick",
+ .addr = omap3xxx_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_dss_addrs),
+ .fw = {
+ .omap2 = {
+ .l4_fw_region = OMAP3_L4_CORE_FW_DSS_CORE_REGION,
+
[PATCH v8 05/18] OMAP2,3 DSS2 Change driver name to omap_display
From: Senthilvadivu Guruswamy
Change the driver name from omapdss to omap_display as the driver takes care of
the display devices ie number of panels, type of panels available in the
platform. Change the device name in the board files and 2420,2430,3xxx clock
files from omapdss to omap_display to match the driver name.
Signed-off-by: Sumit Semwal
Acked-by: Paul Walmsley
for: The clkdev changes in clock2420_data.c, clock2430_data.c, clock3xxx_data.c
Signed-off-by: Senthilvadivu Guruswamy
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |6 +++---
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |6 +++---
arch/arm/mach-omap2/board-omap3evm.c |4 ++--
arch/arm/mach-omap2/board-omap3pandora.c |8
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |4 ++--
arch/arm/mach-omap2/board-rx51-video.c |2 +-
arch/arm/mach-omap2/board-zoom-display.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |4 ++--
arch/arm/mach-omap2/clock2420_data.c |8
arch/arm/mach-omap2/clock2430_data.c |8
arch/arm/mach-omap2/clock3xxx_data.c | 14 +++---
drivers/video/omap2/dss/core.c |2 +-
17 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index d4e41ef..6f4e7cf 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -308,7 +308,7 @@ static struct omap_dss_board_info sdp3430_dss_data = {
};
static struct platform_device sdp3430_dss_device = {
- .name = "omapdss",
+ .name = "omap_display",
.id = -1,
.dev= {
.platform_data = &sdp3430_dss_data,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 10d60b7..6bb5f53 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -379,7 +379,7 @@ static struct omap_dss_board_info am3517_evm_dss_data = {
};
static struct platform_device am3517_evm_dss_device = {
- .name = "omapdss",
+ .name = "omap_display",
.id = -1,
.dev= {
.platform_data = &am3517_evm_dss_data,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index dac1416..79f87ec 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -402,7 +402,7 @@ static struct omap_dss_board_info cm_t35_dss_data = {
};
static struct platform_device cm_t35_dss_device = {
- .name = "omapdss",
+ .name = "omap_display",
.id = -1,
.dev= {
.platform_data = &cm_t35_dss_data,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 00bb1fc..ca8e1b1 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -199,7 +199,7 @@ static struct omap_dss_board_info devkit8000_dss_data = {
};
static struct platform_device devkit8000_dss_device = {
- .name = "omapdss",
+ .name = "omap_display",
.id = -1,
.dev= {
.platform_data = &devkit8000_dss_data,
@@ -207,7 +207,7 @@ static struct platform_device devkit8000_dss_device = {
};
static struct regulator_consumer_supply devkit8000_vdda_dac_supply =
- REGULATOR_SUPPLY("vdda_dac", "omapdss");
+ REGULATOR_SUPPLY("vdda_dac", "omap_display");
static uint32_t board_keymap[] = {
KEY(0, 0, KEY_1),
@@ -282,7 +282,7 @@ static struct twl4030_gpio_platform_data
devkit8000_gpio_data = {
};
static struct regulator_consumer_supply devkit8000_vpll1_supply =
- REGULATOR_SUPPLY("vdds_dsi", "omapdss");
+ REGULATOR_SUPPLY("vdds_dsi", "omap_display");
/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
static struct regulator_init_data devkit8000_vmmc1 = {
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 3be85a1..23abfa3 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -486,7 +486,7 @@ static struct omap_dss_board_info igep2_dss_data = {
};
static struct platform_device igep2_dss_device = {
- .name = "omapdss",
+ .name = "omap_display",
.id = -1,
.dev= {
.platform_data = &igep2_dss_data,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
[PATCH v8 02/18] OMAP2420: hwmod data: add DSS DISPC RFBI VENC
From: Senthilvadivu Guruswamy
Hwmod needs database of all IPs in a system. This patch generates the hwmod
database for OMAP2420 Display Sub System,. Since DSS is also considered as an
IP as DISPC, RFBI, name it as dss_core.
Acked-by: Benoit Cousson
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 311 +++-
arch/arm/plat-omap/include/plat/l3_2xxx.h | 20 ++
arch/arm/plat-omap/include/plat/l4_2xxx.h | 24 +++
3 files changed, 354 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/l3_2xxx.h
create mode 100644 arch/arm/plat-omap/include/plat/l4_2xxx.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b85c630..21014de 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -18,7 +18,8 @@
#include
#include
#include
-
+#include
+#include
#include "omap_hwmod_common_data.h"
#include "cm-regbits-24xx.h"
@@ -38,6 +39,10 @@ static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_iva_hwmod;
static struct omap_hwmod omap2420_l3_main_hwmod;
static struct omap_hwmod omap2420_l4_core_hwmod;
+static struct omap_hwmod omap2420_dss_core_hwmod;
+static struct omap_hwmod omap2420_dss_dispc_hwmod;
+static struct omap_hwmod omap2420_dss_rfbi_hwmod;
+static struct omap_hwmod omap2420_dss_venc_hwmod;
static struct omap_hwmod omap2420_wd_timer2_hwmod;
static struct omap_hwmod omap2420_gpio1_hwmod;
static struct omap_hwmod omap2420_gpio2_hwmod;
@@ -64,6 +69,19 @@ static struct omap_hwmod_ocp_if *omap2420_l3_main_slaves[] =
{
&omap2420_mpu__l3_main,
};
+/* DSS -> l3 */
+static struct omap_hwmod_ocp_if omap2420_dss__l3 = {
+ .master = &omap2420_dss_core_hwmod,
+ .slave = &omap2420_l3_main_hwmod,
+ .fw = {
+ .omap2 = {
+ .l3_perm_bit = OMAP2_L3_CORE_FW_CONNID_DSS,
+ .flags = OMAP_FIREWALL_L3,
+ }
+ },
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Master interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap2420_l3_main_masters[] = {
&omap2420_l3_main__l4_core,
@@ -470,6 +488,291 @@ static struct omap_hwmod omap2420_uart3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dss_hwmod_class = {
+ .name = "dss",
+ .sysc = &omap2420_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2420_dss_irqs[] = {
+ { .irq = 25 },
+};
+
+static struct omap_hwmod_dma_info omap2420_dss_sdma_chs[] = {
+ { .name = "dispc", .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_masters[] = {
+ &omap2420_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2420_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core -> dss */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dss = {
+ .master = &omap2420_l4_core_hwmod,
+ .slave = &omap2420_dss_core_hwmod,
+ .clk= "dss_ick",
+ .addr = omap2420_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_dss_addrs),
+ .fw = {
+ .omap2 = {
+ .l4_fw_region = OMAP2420_L4_CORE_FW_DSS_CORE_REGION,
+ .flags = OMAP_FIREWALL_L4,
+ }
+ },
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dss_slaves[] = {
+ &omap2420_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = "tv_clk", .clk = "dss_54m_fck" },
+ { .role = "sys_clk", .clk = "dss2_fck" },
+};
+
+static struct omap_hwmod omap2420_dss_core_hwmod = {
+ .name = "dss_core",
+ .class = &omap2420_dss_hwmod_class,
+ .main_clk = "dss1_fck", /* instead of dss_fck */
+ .mpu_irqs = omap2420_dss_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_dss_irqs),
+ .sdma_reqs = omap2420_dss_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_dss_sdma_chs),
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_DSS1_SHIFT,
+ .module_offs = CORE_MOD,
[PATCH v8 03/18] OMAP2430: hwmod data: add DSS DISPC RFBI VENC
From: Senthilvadivu Guruswamy
Hwmod needs database of all IPs in a system. This patch generates the hwmod
database for OMAP2430 Display Sub System. Since DSS is also considered as an
IP as DISPC, RFBI, name it as dss_core.
Acked-by: Benoit Cousson
Signed-off-by: Sumit Semwal
Signed-off-by: Senthilvadivu Guruswamy
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 284
1 files changed, 284 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8ecfbcd..1ef3f3f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "omap_hwmod_common_data.h"
@@ -38,6 +39,10 @@ static struct omap_hwmod omap2430_mpu_hwmod;
static struct omap_hwmod omap2430_iva_hwmod;
static struct omap_hwmod omap2430_l3_main_hwmod;
static struct omap_hwmod omap2430_l4_core_hwmod;
+static struct omap_hwmod omap2430_dss_core_hwmod;
+static struct omap_hwmod omap2430_dss_dispc_hwmod;
+static struct omap_hwmod omap2430_dss_rfbi_hwmod;
+static struct omap_hwmod omap2430_dss_venc_hwmod;
static struct omap_hwmod omap2430_wd_timer2_hwmod;
static struct omap_hwmod omap2430_gpio1_hwmod;
static struct omap_hwmod omap2430_gpio2_hwmod;
@@ -65,6 +70,19 @@ static struct omap_hwmod_ocp_if *omap2430_l3_main_slaves[] =
{
&omap2430_mpu__l3_main,
};
+/* DSS -> l3 */
+static struct omap_hwmod_ocp_if omap2430_dss__l3 = {
+ .master = &omap2430_dss_core_hwmod,
+ .slave = &omap2430_l3_main_hwmod,
+ .fw = {
+ .omap2 = {
+ .l3_perm_bit = OMAP2_L3_CORE_FW_CONNID_DSS,
+ .flags = OMAP_FIREWALL_L3,
+ }
+ },
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Master interfaces on the L3 interconnect */
static struct omap_hwmod_ocp_if *omap2430_l3_main_masters[] = {
&omap2430_l3_main__l4_core,
@@ -469,6 +487,266 @@ static struct omap_hwmod omap2430_uart3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
+/*
+ * 'dss' class
+ * display sub-system
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_dss_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dss_hwmod_class = {
+ .name = "dss",
+ .sysc = &omap2430_dss_sysc,
+};
+
+/* dss */
+static struct omap_hwmod_irq_info omap2430_dss_irqs[] = {
+ { .irq = 25 },
+};
+static struct omap_hwmod_dma_info omap2430_dss_sdma_chs[] = {
+ { .name = "dispc", .dma_req = 5 },
+};
+
+/* dss */
+/* dss master ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_masters[] = {
+ &omap2430_dss__l3,
+};
+
+static struct omap_hwmod_addr_space omap2430_dss_addrs[] = {
+ {
+ .pa_start = 0x4805,
+ .pa_end = 0x480503FF,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core -> dss */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dss = {
+ .master = &omap2430_l4_core_hwmod,
+ .slave = &omap2430_dss_core_hwmod,
+ .clk= "dss_ick",
+ .addr = omap2430_dss_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_dss_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dss slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dss_slaves[] = {
+ &omap2430_l4_core__dss,
+};
+
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = "tv_clk", .clk = "dss_54m_fck" },
+ { .role = "sys_clk", .clk = "dss2_fck" },
+};
+
+static struct omap_hwmod omap2430_dss_core_hwmod = {
+ .name = "dss_core",
+ .class = &omap2430_dss_hwmod_class,
+ .main_clk = "dss1_fck", /* instead of dss_fck */
+ .mpu_irqs = omap2430_dss_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_dss_irqs),
+ .sdma_reqs = omap2430_dss_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2430_dss_sdma_chs),
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_DSS1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_stdby_bit = OMAP24XX_ST_DSS_SHIFT,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+ .slaves = omap2430_dss_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_dss_slaves),
+ .masters= omap2430_dss_masters,
+ .masters_cnt= ARRAY_SIZE(omap2430_dss_masters),
+ .omap_chip = OMAP_CHI
[PATCH v8 00/18] OMAP2,3: hwmod DSS Adaptation
v8 of the DSS hwmod patch series fixes some issues based on findings of Kevin Hilman on beagle. The VENC platform driver was not getting registered due to missed device name update for vdda_dac regulator in some board files. This was moved from 'omap_display' device to 'omap_venc' device in patch 14/18. Also, similarly for DSI platform driver, the regulator name 'vdds_dsi' needs two instances - one for dpi, and one for dsi. This version corrects the above two for all board files where 'vdda_dac' and 'vdds_dsi' regulators are defined. [patches 14/18 and 15/18] Post this change, boot w/ visible framebuffer and tux was successfully validated on beagle, 3430SDP and zoom3. A patch mentioned in http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42384.html was needed to get OMAP3 to boot up on top of linux-next of 20110115. OMAP4 hwmod support will be posted after the acceptance of this basic change in the dss2 design. - [original patch introduction] This patch series decouples the "Clocks for DSS in hwmod adaptation" changes from this series. Another series would be posted which could be discussed w.r.t clocks in DSS across omap2,3. Removing the SYSCONFIG settings from DSS driver would also be part of these clock changes series and not covered in this series as it depends on some of the omap_hwmod framework changes w.r.t opt clocks handling. Summary of the hwmod DSS design: DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the hwmod class in the hwmod database. Each of these platform drivers' init / deinit are handled from core.c's omap_dss_probe() in the exact sequence as required. No Hardcoding of silicon data: hwmod database abstracts the SOC data like base addr, irq numbers and are implemented in this patch series. Continue to have custom bus for display panels: "omap_display" driver continues to be a platform driver that registers the custom bus. It also continues to register the display panels(omap_dss_device) on the board to the panel drivers (omap_dss_driver) For Eg: primary lcd device would be registered with lcd panel driver. lcd panel driver if it is on a parallel interface would use library functions exported from dpi.o. if it is on a dsi interface would use library functions exported from dsi platform driver(dsi.o). Clocks: Handling of clocks in DSS only is one of the design approaches, that does not change the existing implementation. If each of the DSS HW IPs had to handle their own clocks, then corresponding clock changes can be requested in the hwmod database as well which is not the current design/implementation. As stated, this would be handled in another series seperately. For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart for the dss main clocks. Currently VENC driver needs to be aware of this and has to use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. Current dss driver: --- 1. Omapdss platform driver - initialises necessary Ips dss, dispc. - also initialises Ips like sdi, dsi, venc, rfbi - creates a custom bus and registers the display devices/drivers connected on the board to the custom bus. 2. Suspend/resume of omapdss - in turn sends suspend/resume calls for each of the display devices registered to it. Modified change: --- Platform driver for each DSS HW IP in addition to the software "omap_display" driver. Omapdss platform driver - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, venc, rfbi] and software libraries like dpi, sdi. - continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus. - continues to handle suspend/resume of the display devices registered to the custom bus. DSS platform driver - initialises DSS IP alone - Handles the clocks related to the DSS and other DSSHW IPs like RFBI, DSI, VENC, DISPC. Previously this was a part of "omapdss" driver in core.c - Continues to handle the DSS IRQs. - No suspend/resume hooks. DISPC platform driver - initialises DISPC IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DISPC library functions. DSI platform driver - initialises DSI IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DSI library functions. RFBI, VENC platform drivers - initialises DSI,VENC IPs - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide RFBI and VENC library functions. Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 343
[PATCH v8 01/18] OMAP2,3: DSS2: remove forced clk-disable from omap_dss_remove
As part of omap hwmod changes, DSS will not be the only controller of its
clocks. hwmod initialization also enables the interface clocks, and
manages them.
So, when DSS is built as a module, omap_dss_remove doesn't try to disable
all clocks that have a higher usecount.
Signed-off-by: Sumit Semwal
---
drivers/video/omap2/dss/core.c | 46 ++-
1 files changed, 7 insertions(+), 39 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 8e89f60..ee56859 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -623,7 +623,6 @@ static int omap_dss_remove(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
int i;
- int c;
dss_uninitialize_debugfs();
@@ -638,44 +637,13 @@ static int omap_dss_remove(struct platform_device *pdev)
dss_exit();
- /* these should be removed at some point */
- c = core.dss_ick->usecount;
- if (c > 0) {
- DSSERR("warning: dss_ick usecount %d, disabling\n", c);
- while (c-- > 0)
- clk_disable(core.dss_ick);
- }
-
- c = core.dss1_fck->usecount;
- if (c > 0) {
- DSSERR("warning: dss1_fck usecount %d, disabling\n", c);
- while (c-- > 0)
- clk_disable(core.dss1_fck);
- }
-
- c = core.dss2_fck->usecount;
- if (c > 0) {
- DSSERR("warning: dss2_fck usecount %d, disabling\n", c);
- while (c-- > 0)
- clk_disable(core.dss2_fck);
- }
-
- c = core.dss_54m_fck->usecount;
- if (c > 0) {
- DSSERR("warning: dss_54m_fck usecount %d, disabling\n", c);
- while (c-- > 0)
- clk_disable(core.dss_54m_fck);
- }
-
- if (core.dss_96m_fck) {
- c = core.dss_96m_fck->usecount;
- if (c > 0) {
- DSSERR("warning: dss_96m_fck usecount %d, disabling\n",
- c);
- while (c-- > 0)
- clk_disable(core.dss_96m_fck);
- }
- }
+ /*
+* As part of hwmod changes, DSS is not the only controller of dss
+* clocks; hwmod framework itself will also enable clocks during hwmod
+* init for dss, and autoidle is set in h/w for DSS. Hence, there's no
+* need to disable clocks if their usecounts > 1.
+*/
+ WARN_ON(core.num_clks_enabled > 0);
dss_put_clocks();
--
1.7.1
--
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: Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1
On Fri, 2011-01-21 at 15:18 +0100, Koen Kooi wrote:
> Hi,
>
> I'm trying to bring up a wl1271 sdio expansion board on beagle with 2.6.37
> and I'm running into a weird problem when enabling MMC_CAP_POWER_OFF_CARD.
>
> My patch basically does:
>
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -270,7 +270,7 @@ static struct omap2_hsmmc_info mmc[] = {
>{
>.name = "wl1271",
>.mmc= 2,
> - .caps = MMC_CAP_4_BIT_DATA,
> + .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
>
> And does NOT touch mmc1. But after adding MMC_CAP_POWER_OFF_CARD I get tons
> of:
>
> [ 22.259490] mmcblk0: error -110 sending status comand
> [ 22.264617] mmcblk0: error -110 sending read/write command, response 0x0,
> card status 0x0
> [ 22.273345] mmcblk0: error -110 transferring data, sector 2338228, nr 3,
> card status 0x0
> [ 22.281799] end_request: I/O error, dev mmcblk0, sector 2338228
> [ 22.288055] mmcblk0: error -110 sending status comand
> [ 22.293151] mmcblk0: error -110 sending read/write command, response 0x0,
> card status 0x0
> [ 22.301879] mmcblk0: error -110 transferring data, sector 2338229, nr 2,
> card status 0x0
> [ 22.310363] end_request: I/O error, dev mmcblk0, sector 2338229
>
> When using mmcblk0p2 as rootfs. Attached is the complete patch. It looks a
> bit weird because it's using the expansionboard infrastucture I hacked
> together.
>
> I suspect that mmc2 is turning off the shared regulator, but I have various
> people claiming this code (minus the expansionboard detection) works with the
> same regulator setup, so I'm extremely puzzled.
>
> The CC: list was partially generated with the get_maintainer.pl script,
> apologies if I screwed it up.
I think Ohad is the right person to answer this question.
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
2011/1/21 Santosh Shilimkar : > How about below approach? > > - > [PATCH] ARM: smp: Skip secondary cpu calibration to speed-up boot Hey this looks like a good way to do it, Acked-by: Linus Walleij Yours, Linus Walleij -- 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
Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1
Hi,
I'm trying to bring up a wl1271 sdio expansion board on beagle with 2.6.37 and
I'm running into a weird problem when enabling MMC_CAP_POWER_OFF_CARD.
My patch basically does:
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -270,7 +270,7 @@ static struct omap2_hsmmc_info mmc[] = {
{
.name = "wl1271",
.mmc= 2,
- .caps = MMC_CAP_4_BIT_DATA,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
And does NOT touch mmc1. But after adding MMC_CAP_POWER_OFF_CARD I get tons of:
[ 22.259490] mmcblk0: error -110 sending status comand
[ 22.264617] mmcblk0: error -110 sending read/write command, response 0x0,
card status 0x0
[ 22.273345] mmcblk0: error -110 transferring data, sector 2338228, nr 3,
card status 0x0
[ 22.281799] end_request: I/O error, dev mmcblk0, sector 2338228
[ 22.288055] mmcblk0: error -110 sending status comand
[ 22.293151] mmcblk0: error -110 sending read/write command, response 0x0,
card status 0x0
[ 22.301879] mmcblk0: error -110 transferring data, sector 2338229, nr 2,
card status 0x0
[ 22.310363] end_request: I/O error, dev mmcblk0, sector 2338229
When using mmcblk0p2 as rootfs. Attached is the complete patch. It looks a bit
weird because it's using the expansionboard infrastucture I hacked together.
I suspect that mmc2 is turning off the shared regulator, but I have various
people claiming this code (minus the expansionboard detection) works with the
same regulator setup, so I'm extremely puzzled.
The CC: list was partially generated with the get_maintainer.pl script,
apologies if I screwed it up.
regards,
Koen
0001-omap3-beagleboard-add-WIP-support-for-beagleboardtoy.patch
Description: Binary data
RE: [QUERY] [AUDIO][OMAP3 EVM] arecord not working on OMAP3 EVM
Thanks Peter, Your comment helped. > -Original Message- > From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] > Sent: Friday, January 21, 2011 1:27 PM > To: Koyamangalath, Abhilash > Cc: linux-omap@vger.kernel.org; alsa-de...@vger.kernel.org > Subject: Re: [QUERY] [AUDIO][OMAP3 EVM] arecord not working on OMAP3 EVM > > On 01/20/11 17:26, ext Koyamangalath, Abhilash wrote: > > Hi all > > While testing audio capture (using arecord e,g.),I'm getting only noise > in the (zeroed out) output buffers on the OMAP3 EVM. > > I have enabled AUXL and AUXR mic inputs through alsamixer, which > according to the schematics are connected to the "Audio In" > > connector on the board, even though the TWL4030 reg list does not allow > me any ways ( or so I think) to specify mic-bias for > > these aux inputs. > > Well, it is auxiliary input (line in). You do not need bias for it. > I do not have access to OMAP3 EVM documentation, but Beagle also have > AUXL/R as input. > I guess you need to use correct cable, and correct source for the input > (stereo jack I suppose). No need of bias precludes using a MIC, so I tried by connecting a Line-in/out audio cable (a cable with a 3.5 mm audio jack on each end) fed from the PC and it worked, thanks. Originally, I had connected a head-phone mic directly to the audio-in port, which it seems, rather expects a dc-biased and/or a pre-amplified signal. > > > With AUXL and AUXR muted - I get only silence, which seems to make > sense. > > Is there any basic startup setting I'm missing, maybe specific to OMAP3 > EVM? > > Beagle? > > > Has anyone seen anything like this before, and could provide pointers? > > My bet goes for the wrong cable/accessory pair. Bang On. > > -- > Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/13] OMAP3: Introduce voltage domain info in the hwmod structures.
From: Thara Gopinath
This patch adds voltage domain info in the relevant
device hwmod structures so as to enable OMAP3 DVFS
support.
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8d81813..c57f34d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -94,6 +94,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_l3_main_masters[] =
{
static struct omap_hwmod omap3xxx_l3_main_hwmod = {
.name = "l3_main",
.class = &l3_hwmod_class,
+ .vdd_name = "core",
.masters= omap3xxx_l3_main_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_l3_main_masters),
.slaves = omap3xxx_l3_main_slaves,
@@ -384,6 +385,7 @@ static struct omap_hwmod omap3xxx_mpu_hwmod = {
.name = "mpu",
.class = &mpu_hwmod_class,
.main_clk = "arm_fck",
+ .vdd_name = "mpu",
.masters= omap3xxx_mpu_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_mpu_masters),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
@@ -412,6 +414,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_iva_masters[] = {
static struct omap_hwmod omap3xxx_iva_hwmod = {
.name = "iva",
.class = &iva_hwmod_class,
+ .vdd_name = "mpu",
.masters= omap3xxx_iva_masters,
.masters_cnt= ARRAY_SIZE(omap3xxx_iva_masters),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/13] OMAP3: cpufreq driver changes for DVFS support
Changes in the omap cpufreq driver for DVFS support.
Signed-off-by: Vishwanath BS
Cc: Santosh Shilimkar
---
arch/arm/plat-omap/cpu-omap.c | 35 ---
1 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 1c1b80b..d965220 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -30,10 +30,12 @@
#include
#include
#include
+#include
#if defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
#include
#include
+#include
#endif
#define VERY_HI_RATE 9
@@ -85,11 +87,11 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
-#ifdef CONFIG_ARCH_OMAP1
struct cpufreq_freqs freqs;
-#endif
#if defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
unsigned long freq;
+ int i;
+ struct cpufreq_freqs freqs_notify;
struct device *mpu_dev = omap2_get_mpuss_device();
#endif
int ret = 0;
@@ -116,9 +118,36 @@ static int omap_target(struct cpufreq_policy *policy,
ret = clk_set_rate(mpu_clk, freqs.new * 1000);
cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
#elif defined(CONFIG_ARCH_OMAP3) && !defined(CONFIG_OMAP_PM_NONE)
+ freqs.old = omap_getspeed(policy->cpu);;
+ freqs_notify.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
+ freqs.cpu = policy->cpu;
+
+ if (freqs.old == freqs.new)
+ return ret;
+
+ /* pre notifiers */
+ for_each_cpu(i, policy->cpus) {
+ freqs.cpu = i;
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ }
+
+ /* scale the frequency */
freq = target_freq * 1000;
if (opp_find_freq_ceil(mpu_dev, &freq))
- omap_pm_cpu_set_freq(freq);
+ omap_device_scale(mpu_dev, mpu_dev, freq);
+
+ /* Update loops per jiffy */
+ freqs.new = omap_getspeed(policy->cpu);
+ for_each_cpu(i, policy->cpus)
+ per_cpu(cpu_data, i).loops_per_jiffy =
+ cpufreq_scale(per_cpu(cpu_data, i).loops_per_jiffy,
+ freqs.old, freqs.new);
+
+ /* post notifiers */
+ for_each_cpu(i, policy->cpus) {
+ freqs.cpu = i;
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+ }
#endif
return ret;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/13] OMAP: Add DVFS Documentation
Add Documentation for DVFS Framework Signed-off-by: Vishwanath BS --- Documentation/arm/OMAP/omap_dvfs | 111 ++ 1 files changed, 111 insertions(+), 0 deletions(-) create mode 100644 Documentation/arm/OMAP/omap_dvfs diff --git a/Documentation/arm/OMAP/omap_dvfs b/Documentation/arm/OMAP/omap_dvfs new file mode 100644 index 000..b026643 --- /dev/null +++ b/Documentation/arm/OMAP/omap_dvfs @@ -0,0 +1,111 @@ +*=* +* DVFS Framework * +*=* +(C) 2011 Vishwnath BS , Texas Instruments Incorporated +Contents + +1. Introduction +2. Data Structure Organization +3. DVFS APIs + +1. Introduction +=== +DVFS is a technique that uses the optimal operating frequency and voltage to +allow a task to be performed in the required amount of time. +OMAP processors have voltage domains whose voltage can be scaled to +various levels depending on which the operating frequencies of certain +devices belonging to the domain will also need to be scaled. This voltage +frequency tuple is known as Operating Performance Point (OPP). A device +can have multiple OPP's. Also a voltage domain could be shared between +multiple devices. Also there could be dependencies between various +voltage domains for maintaining system performance like VDD +should be at voltage v1 when VDD is at voltage v2. + +The design of this framework takes into account all the above mentioned points. +To summarize the basic design of DVFS framework:- + +1. Have device opp tables for each device whose operating frequency can be + scaled. This is easy now due to the existance of hwmod layer which + allow storing of device specific info. The device opp tables contain + the opp pairs (frequency voltage tuples), the voltage domain pointer + to which the device belongs to, the device specific set_rate and + get_rate API's which will do the actual scaling of the device frequency + and retrieve the current device frequency. +2. Introduce use counting on a per VDD basis. This is to take care multiple + requests to scale a VDD. The VDD will be scaled to the maximum of the + voltages requested. +3. Keep track of all scalable devices belonging to a particular voltage + domain the voltage layer. +4. Keep track of frequency requests for each of the device. This will enable + to scale individual devices to different frequency (even w/o scaling voltage + aka frequency throttling) +5. Generic dvfs API that can be called by anybody to scale a device opp. + This API takes the device pointer and frequency to which the device + needs to be scaled to. This API then internally finds out the voltage + domain to which the device belongs to and the voltage to which the voltage + domain needs to be put to for the device to be scaled to the new frequency + from he device opp table. Then this API will add requested frequency into + the corresponding target device frequency list and add voltage request to + the corresponding vdd. Subsequently it calls voltage scale function which + will find out the highest requested voltage for the given vdd and scales + the voltage to the required one. It also runs through the list of all + scalable devices belonging to this voltage domain and scale them to the + appropriate frequencies using the set_rate pointer in the device opp tables. +6. Handle inter VDD dependecies. + + +2. The Core DVFS data structure: += + + |---| |---| + |User2 (dev2, freq2)| |User4 (dev4, freq4)| + |---^---| |---^---| + | | + |---|---| |---|---| + |User1 (dev1, freq1)| |User3 (dev3, freq3)|(omap_dev_user_list) + |---^---| |---^---| +| | + |---|--| |--| +|->| DEV1 (dev) |>| DEV2 (dev) |(omap_vdd_dev_list) +| |omap_dev_user_list| |omap_dev_user_list| +| |--| |--| +| + |-|---| + | VDD_n | + | omap_vdd_dev_list | + | omap_vdd_user_list |(omap_vdd_dvfs_info) + | | + ||| + | +| |--
[PATCH 07/13] OMAP3: Introduce custom set rate and get rate APIs for scalable devices
From: Thara Gopinath
This patch also introduces omap3_mpu_set_rate, omap3_iva_set_rate,
omap3_l3_set_rate, omap3_mpu_get_rate, omap3_iva_get_rate,
omap3_l3_get_rate as device specific set rate and get rate
APIs for OMAP3 mpu, iva and l3_main devices. This patch also
calls into omap_device_populate_rate_fns during system init to register
various set_rate and get_rate APIs with the omap device layer
Signed-off-by: Thara Gopinath
---
arch/arm/mach-omap2/pm.c | 71 ++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d5a102c..1b94ad4 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -23,6 +23,9 @@
#include "powerdomain.h"
#include "clockdomain.h"
#include "pm.h"
+#include "cm2xxx_3xxx.h"
+#include "cm-regbits-34xx.h"
+#include "prm.h"
static struct omap_device_pm_latency *pm_lats;
@@ -31,6 +34,8 @@ static struct device *iva_dev;
static struct device *l3_dev;
static struct device *dsp_dev;
+static struct clk *dpll1_clk, *dpll2_clk, *dpll3_clk;
+
struct device *omap2_get_mpuss_device(void)
{
WARN_ON_ONCE(!mpu_dev);
@@ -77,6 +82,55 @@ static int _init_omap_device(char *name, struct device
**new_dev)
return 0;
}
+static unsigned long omap3_mpu_get_rate(struct device *dev)
+{
+ return dpll1_clk->rate;
+}
+
+static int omap3_mpu_set_rate(struct device *dev, unsigned long rate)
+{
+ int ret;
+
+ ret = clk_set_rate(dpll1_clk, rate);
+ if (ret) {
+ dev_warn(dev, "%s: Unable to set rate to %ld\n",
+ __func__, rate);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int omap3_iva_set_rate(struct device *dev, unsigned long rate)
+{
+ return clk_set_rate(dpll2_clk, rate);
+}
+
+static unsigned long omap3_iva_get_rate(struct device *dev)
+{
+ return dpll2_clk->rate;
+}
+
+static int omap3_l3_set_rate(struct device *dev, unsigned long rate)
+{
+ int l3_div;
+
+ l3_div = omap2_cm_read_mod_reg(CORE_MOD, CM_CLKSEL) &
+ OMAP3430_CLKSEL_L3_MASK;
+
+ return clk_set_rate(dpll3_clk, rate * l3_div);
+}
+
+static unsigned long omap3_l3_get_rate(struct device *dev)
+{
+ int l3_div;
+
+ l3_div = omap2_cm_read_mod_reg(CORE_MOD, CM_CLKSEL) &
+ OMAP3430_CLKSEL_L3_MASK;
+ return dpll3_clk->rate / l3_div;
+}
+
+
/*
* Build omap_devices for processors and bus.
*/
@@ -90,6 +144,23 @@ static void omap2_init_processor_devices(void)
} else {
_init_omap_device("l3_main", &l3_dev);
}
+
+ if (cpu_is_omap34xx()) {
+ dpll1_clk = clk_get(NULL, "dpll1_ck");
+ dpll2_clk = clk_get(NULL, "dpll2_ck");
+ dpll3_clk = clk_get(NULL, "dpll3_m2_ck");
+
+ if (mpu_dev)
+ omap_device_register_dvfs_callbacks(mpu_dev,
+ omap3_mpu_set_rate, omap3_mpu_get_rate);
+ if (iva_dev)
+ omap_device_register_dvfs_callbacks(iva_dev,
+ omap3_iva_set_rate, omap3_iva_get_rate);
+ if (l3_dev)
+ omap_device_register_dvfs_callbacks(l3_dev,
+ omap3_l3_set_rate, omap3_l3_get_rate);
+
+ }
}
/* Types of sleep_switch used in omap_set_pwrdm_state */
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/13] OMAP: Introduce dependent voltage domain support
There could be dependencies between various voltage domains for
maintaining system performance or hardware limitation reasons
like VDD should be at voltage v1 when VDD is at voltage v2.
This patch introduce dependent vdd information structures in the
voltage layer which can be used to populate these dependencies
for a voltage domain. This patch also adds support to scale
the dependent vdd and the scalable devices belonging to it
during the scaling of a main vdd through omap_voltage_scale.
As part of this, some of the voltage layer structure definitions are moved from
voltage.c to voltage.h as it needs to be used in the dvfs layer for dependency
voltage handling.
Based on original patch from Thara.
Signed-off-by: Vishwanath BS
Cc: Thara Gopinath
---
arch/arm/mach-omap2/dvfs.c| 87 +
arch/arm/mach-omap2/voltage.c | 117 ---
arch/arm/plat-omap/include/plat/voltage.h | 148 +
3 files changed, 235 insertions(+), 117 deletions(-)
diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-omap2/dvfs.c
index cefc2be..c9d3894 100755
--- a/arch/arm/mach-omap2/dvfs.c
+++ b/arch/arm/mach-omap2/dvfs.c
@@ -85,6 +85,7 @@ struct omap_vdd_dvfs_info {
struct mutex scaling_mutex; /* dvfs mutex */
struct voltagedomain *voltdm;
struct list_head dev_list;
+ struct device vdd_device;
};
static struct omap_vdd_dvfs_info *omap_dvfs_info_list;
@@ -98,6 +99,7 @@ static struct voltagedomain omap3_vdd[] = {
.name = "core",
},
};
+static int omap_dvfs_voltage_scale(struct omap_vdd_dvfs_info *dvfs_info);
static int __init omap_dvfs_init(void);
@@ -412,6 +414,79 @@ static int omap_dvfs_remove_freq_request(struct
omap_vdd_dvfs_info *dvfs_info,
return ret;
}
+/* Calculate dependency vdd voltage for given vdd voltage */
+static int calc_dep_vdd_volt(struct device *dev,
+ struct omap_vdd_info *main_vdd, unsigned long main_volt)
+{
+ struct omap_vdd_dep_info *dep_vdds;
+ int i, ret = 0;
+
+ if (!main_vdd->dep_vdd_info) {
+ pr_debug("%s: No dependent VDD's for vdd_%s\n",
+ __func__, main_vdd->voltdm.name);
+ return 0;
+ }
+
+ dep_vdds = main_vdd->dep_vdd_info;
+
+ for (i = 0; i < main_vdd->nr_dep_vdd; i++) {
+ struct omap_vdd_dep_volt *volt_table = dep_vdds[i].dep_table;
+ int nr_volt = 0;
+ unsigned long dep_volt = 0, act_volt = 0;
+
+ while (volt_table[nr_volt].main_vdd_volt != 0) {
+ if (volt_table[nr_volt].main_vdd_volt == main_volt) {
+ dep_volt = volt_table[nr_volt].dep_vdd_volt;
+ break;
+ }
+ nr_volt++;
+ }
+ if (!dep_volt) {
+ pr_warning("%s: Not able to find a matching volt for"
+ "vdd_%s corresponding to vdd_%s %ld volt\n",
+ __func__, dep_vdds[i].name,
+ main_vdd->voltdm.name, main_volt);
+ ret = -EINVAL;
+ continue;
+ }
+
+ if (!dep_vdds[i].voltdm)
+ dep_vdds[i].voltdm =
+ omap_voltage_domain_lookup(dep_vdds[i].name);
+
+ act_volt = dep_volt;
+
+ /* See if dep_volt is possible for the vdd*/
+ ret = omap_dvfs_add_vdd_user(get_dvfs_info(dep_vdds[i].voltdm),
+ dev, act_volt);
+ }
+
+ return ret;
+}
+
+/* Scale dependent VDD */
+static int scale_dep_vdd(struct omap_vdd_dvfs_info *vdd_info)
+{
+ struct omap_vdd_dep_info *dep_vdds;
+ int i;
+ struct omap_vdd_info *main_vdd;
+ struct voltagedomain *voltdm = vdd_info->voltdm;
+ main_vdd = container_of(voltdm, struct omap_vdd_info, voltdm);
+
+ if (!main_vdd->dep_vdd_info) {
+ pr_debug("%s: No dependent VDD's for vdd_%s\n",
+ __func__, main_vdd->voltdm.name);
+ return 0;
+ }
+
+ dep_vdds = main_vdd->dep_vdd_info;
+
+ for (i = 0; i < main_vdd->nr_dep_vdd; i++)
+ omap_dvfs_voltage_scale(get_dvfs_info(dep_vdds[i].voltdm));
+
+ return 0;
+}
+
/**
* omap_dvfs_voltage_scale() : API to scale the devices associated with a
* voltage domain vdd voltage.
@@ -435,6 +510,7 @@ static int omap_dvfs_voltage_scale(struct
omap_vdd_dvfs_info *dvfs_info)
int ret = 0;
struct voltagedomain *voltdm;
unsigned long volt;
+ struct omap_vdd_info *vdd;
if (!dvfs_info || IS_ERR(dvfs_info)) {
pr_warning("%s: VDD specified does not exist!\n", __func__);
@@ -442,6 +518,7 @@ static int omap_dvfs_voltage_scale(stru
[PATCH 10/13] OMAP3: Add voltage dependency table for VDD1.
From: Thara Gopinath
In OMAP3, for perfomrance reasons when VDD1 is at voltage above
1.075V, VDD2 should be at 1.15V for perfomrance reasons. This
patch introduce this cross VDD dependency for OMAP3 VDD1.
Signed-off-by: Thara Gopinath
This patch has checkpatch warnings for line over 80 chars. It is not fixed for
code readability.
---
arch/arm/mach-omap2/voltage.c | 42 +++-
1 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 92fe20d..8881c0c 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -191,6 +191,39 @@ static struct omap_volt_data omap44xx_vdd_core_volt_data[]
= {
VOLT_DATA_DEFINE(0, 0, 0, 0),
};
+/* OMAP 3430 MPU Core VDD dependency table */
+static struct omap_vdd_dep_volt omap34xx_vdd1_vdd2_data[] = {
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP1_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP50_UV},
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP2_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP50_UV},
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP3_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP4_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = OMAP3430_VDD_MPU_OPP5_UV, .dep_vdd_volt =
OMAP4430_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = 0, .dep_vdd_volt = 0},
+};
+
+static struct omap_vdd_dep_info omap34xx_vdd1_dep_info[] = {
+ {
+ .name = "core",
+ .dep_table = omap34xx_vdd1_vdd2_data,
+ },
+};
+
+/* OMAP 3630 MPU Core VDD dependency table */
+static struct omap_vdd_dep_volt omap36xx_vdd1_vdd2_data[] = {
+ {.main_vdd_volt = OMAP3630_VDD_MPU_OPP50_UV, .dep_vdd_volt =
OMAP3630_VDD_CORE_OPP50_UV},
+ {.main_vdd_volt = OMAP3630_VDD_MPU_OPP100_UV, .dep_vdd_volt =
OMAP3630_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = OMAP3630_VDD_MPU_OPP120_UV, .dep_vdd_volt =
OMAP3630_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = OMAP3630_VDD_MPU_OPP1G_UV, .dep_vdd_volt =
OMAP3630_VDD_CORE_OPP100_UV},
+ {.main_vdd_volt = 0, .dep_vdd_volt = 0},
+};
+
+static struct omap_vdd_dep_info omap36xx_vdd1_dep_info[] = {
+ {
+ .name = "core",
+ .dep_table = omap36xx_vdd1_vdd2_data,
+ },
+};
+
static struct dentry *voltage_dir;
/* Init function pointers */
@@ -696,10 +729,15 @@ static int __init omap3_vdd_data_configure(struct
omap_vdd_info *vdd)
}
if (!strcmp(vdd->voltdm.name, "mpu")) {
- if (cpu_is_omap3630())
+ if (cpu_is_omap3630()) {
vdd->volt_data = omap36xx_vddmpu_volt_data;
- else
+ vdd->dep_vdd_info = omap36xx_vdd1_dep_info;
+ vdd->nr_dep_vdd = ARRAY_SIZE(omap36xx_vdd1_dep_info);
+ } else {
vdd->volt_data = omap34xx_vddmpu_volt_data;
+ vdd->dep_vdd_info = omap34xx_vdd1_dep_info;
+ vdd->nr_dep_vdd = ARRAY_SIZE(omap34xx_vdd1_dep_info);
+ }
vdd->vp_reg.tranxdone_status = OMAP3430_VP1_TRANXDONE_ST_MASK;
vdd->vc_reg.cmdval_reg = OMAP3_PRM_VC_CMD_VAL_0_OFFSET;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/13] OMAP2PLUS: Replace voltage values with Macros
Currently voltage values on opp tables are hardcoded. As these voltage values
are anyway defined in voltage.h as macros, opp table can reuse these values.
This will avoid opp table and voltage layer having conflicting values.
Signed-off-by: Vishwanath BS
This patch has 2 line over 80 char warning. This is kept for readability
purpose.
---
arch/arm/mach-omap2/opp3xxx_data.c | 47 ++-
arch/arm/mach-omap2/opp4xxx_data.c | 13 +
2 files changed, 31 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index 0486fce..eefd6af 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -19,20 +19,21 @@
#include
#include
+#include
#include "omap_opp_data.h"
static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
/* MPU OPP1 */
- OPP_INITIALIZER("mpu", true, 12500, 975000),
+ OPP_INITIALIZER("mpu", true, 12500, OMAP3430_VDD_MPU_OPP1_UV),
/* MPU OPP2 */
- OPP_INITIALIZER("mpu", true, 25000, 1075000),
+ OPP_INITIALIZER("mpu", true, 25000, OMAP3430_VDD_MPU_OPP2_UV),
/* MPU OPP3 */
- OPP_INITIALIZER("mpu", true, 5, 120),
+ OPP_INITIALIZER("mpu", true, 5, OMAP3430_VDD_MPU_OPP3_UV),
/* MPU OPP4 */
- OPP_INITIALIZER("mpu", true, 55000, 127),
+ OPP_INITIALIZER("mpu", true, 55000, OMAP3430_VDD_MPU_OPP4_UV),
/* MPU OPP5 */
- OPP_INITIALIZER("mpu", true, 6, 135),
+ OPP_INITIALIZER("mpu", true, 6, OMAP3430_VDD_MPU_OPP5_UV),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -42,47 +43,47 @@ static struct omap_opp_def __initdata
omap34xx_opp_def_list[] = {
* impact that frequency will do to the MPU and the whole system in
* general.
*/
- OPP_INITIALIZER("l3_main", false, 4150, 975000),
+ OPP_INITIALIZER("l3_main", false, 4150, OMAP3430_VDD_CORE_OPP1_UV),
/* L3 OPP2 */
- OPP_INITIALIZER("l3_main", true, 8300, 105),
+ OPP_INITIALIZER("l3_main", true, 8300, OMAP3430_VDD_CORE_OPP2_UV),
/* L3 OPP3 */
- OPP_INITIALIZER("l3_main", true, 16600, 115),
+ OPP_INITIALIZER("l3_main", true, 16600, OMAP3430_VDD_CORE_OPP3_UV),
/* DSP OPP1 */
- OPP_INITIALIZER("iva", true, 9000, 975000),
+ OPP_INITIALIZER("iva", true, 9000, OMAP3430_VDD_MPU_OPP1_UV),
/* DSP OPP2 */
- OPP_INITIALIZER("iva", true, 18000, 1075000),
+ OPP_INITIALIZER("iva", true, 18000, OMAP3430_VDD_MPU_OPP2_UV),
/* DSP OPP3 */
- OPP_INITIALIZER("iva", true, 36000, 120),
+ OPP_INITIALIZER("iva", true, 36000, OMAP3430_VDD_MPU_OPP3_UV),
/* DSP OPP4 */
- OPP_INITIALIZER("iva", true, 4, 127),
+ OPP_INITIALIZER("iva", true, 4, OMAP3430_VDD_MPU_OPP4_UV),
/* DSP OPP5 */
- OPP_INITIALIZER("iva", true, 43000, 135),
+ OPP_INITIALIZER("iva", true, 43000, OMAP3430_VDD_MPU_OPP5_UV),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
/* MPU OPP1 - OPP50 */
- OPP_INITIALIZER("mpu", true, 3, 1012500),
+ OPP_INITIALIZER("mpu", true, 3, OMAP3630_VDD_MPU_OPP50_UV),
/* MPU OPP2 - OPP100 */
- OPP_INITIALIZER("mpu", true, 6, 120),
+ OPP_INITIALIZER("mpu", true, 6, OMAP3630_VDD_MPU_OPP100_UV),
/* MPU OPP3 - OPP-Turbo */
- OPP_INITIALIZER("mpu", false, 8, 1325000),
+ OPP_INITIALIZER("mpu", false, 8, OMAP3630_VDD_MPU_OPP120_UV),
/* MPU OPP4 - OPP-SB */
- OPP_INITIALIZER("mpu", false, 10, 1375000),
+ OPP_INITIALIZER("mpu", false, 10, OMAP3630_VDD_MPU_OPP1G_UV),
/* L3 OPP1 - OPP50 */
- OPP_INITIALIZER("l3_main", true, 1, 100),
+ OPP_INITIALIZER("l3_main", true, 1, OMAP3630_VDD_CORE_OPP50_UV),
/* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
- OPP_INITIALIZER("l3_main", true, 2, 120),
+ OPP_INITIALIZER("l3_main", true, 2,
OMAP3630_VDD_CORE_OPP100_UV),
/* DSP OPP1 - OPP50 */
- OPP_INITIALIZER("iva", true, 26000, 1012500),
+ OPP_INITIALIZER("iva", true, 26000, OMAP3630_VDD_MPU_OPP50_UV),
/* DSP OPP2 - OPP100 */
- OPP_INITIALIZER("iva", true, 52000, 120),
+ OPP_INITIALIZER("iva", true, 52000, OMAP3630_VDD_MPU_OPP100_UV),
/* DSP OPP3 - OPP-Turbo */
- OPP_INITIALIZER("iva", false, 66000, 1325000),
+ OPP_INITIALIZER("iva", false, 66000, OMAP3630_VDD_MPU_OPP120_UV),
/* DSP OPP4 - OPP-SB */
- OPP_INITIALIZER("iva", false, 8, 1375000),
+ OPP_INITIALIZER("iva", false, 8, OMAP3630_VDD_MPU_OPP1G_UV),
};
/
[PATCH 12/13] OMAP2PLUS: Enable various options in defconfig
From: Thara Gopinath This patch enables Smartreflex and Cpu Freq in the omap2plus defconfig. Signed-off-by: Thara Gopinath --- arch/arm/configs/omap2plus_defconfig |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index ccedde1..b7888ae 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -291,3 +291,7 @@ CONFIG_CRC_T10DIF=y CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_OMAP_SMARTREFLEX=y +CONFIG_OMAP_SMARTREFLEX_CLASS3=y -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/13] OMAP: Disable Smartreflex across DVFS
From: Thara Gopinath
This patch disables smartreflex for a particular voltage
domain when the the voltage domain and the devices belonging
to it is being scaled and re-enables it back once the scaling
is done.
Signed-off-by: Thara Gopinath
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/dvfs.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-omap2/dvfs.c
index 05a9ce3..1e5492c 100755
--- a/arch/arm/mach-omap2/dvfs.c
+++ b/arch/arm/mach-omap2/dvfs.c
@@ -529,6 +529,9 @@ static int omap_dvfs_voltage_scale(struct
omap_vdd_dvfs_info *dvfs_info)
curr_volt = omap_voltage_get_nom_volt(voltdm);
+ /* Disable smartreflex module across voltage and frequency scaling */
+ omap_sr_disable(voltdm);
+
if (curr_volt == volt) {
is_volt_scaled = 1;
} else if (curr_volt < volt) {
@@ -536,6 +539,7 @@ static int omap_dvfs_voltage_scale(struct
omap_vdd_dvfs_info *dvfs_info)
if (ret) {
pr_warning("%s: Unable to scale the %s to %ld volt\n",
__func__, voltdm->name, volt);
+ omap_sr_enable(voltdm);
mutex_unlock(&dvfs_info->scaling_mutex);
return ret;
}
@@ -570,6 +574,9 @@ static int omap_dvfs_voltage_scale(struct
omap_vdd_dvfs_info *dvfs_info)
if (!is_volt_scaled && !ret)
omap_voltage_scale_vdd(voltdm, volt);
+ /* Enable Smartreflex module */
+ omap_sr_enable(voltdm);
+
mutex_unlock(&dvfs_info->scaling_mutex);
/* calculate the voltages for dependent vdd's */
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/13] OMAP: Implement Basic DVFS
This patch introduces an API to perform DVFS for a given voltage domain.
It takes omap_vdd_dvfs_info pointer as input parameter, computes the highest
requested voltage for that vdd and scales all the devices in that vdd to the
requested frequency along with voltage scaling.
Based on original patch from Thara.
Signed-off-by: Vishwanath BS
Cc: Thara Gopinath
---
arch/arm/mach-omap2/dvfs.c | 87 +++-
1 files changed, 86 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-omap2/dvfs.c
index 8832e4a..cefc2be 100755
--- a/arch/arm/mach-omap2/dvfs.c
+++ b/arch/arm/mach-omap2/dvfs.c
@@ -21,7 +21,7 @@
#include
/**
- * struct omap_dev_user_list - Structure maitain userlist per devide
+ * struct omap_dev_user_list - Structure maitain userlist per device
*
* @dev: The device requesting for a particular frequency
* @node: The list head entry
@@ -413,6 +413,91 @@ static int omap_dvfs_remove_freq_request(struct
omap_vdd_dvfs_info *dvfs_info,
}
/**
+ * omap_dvfs_voltage_scale() : API to scale the devices associated with a
+ * voltage domain vdd voltage.
+ *
+ * @dvfs_info: omap_vdd_dvfs_info pointer for the required vdd
+ *
+ * This API runs through the list of devices associated with the
+ * voltage domain and scales the device rates to the one requested
+ * by the user or those corresponding to the new voltage of the
+ * voltage domain. Target voltage is the highest voltage in the vdd_user_list.
+ *
+ * Returns 0 on success
+ * else the error value.
+ */
+static int omap_dvfs_voltage_scale(struct omap_vdd_dvfs_info *dvfs_info)
+{
+ unsigned long curr_volt;
+ int is_volt_scaled = 0;
+ struct omap_vdd_dev_list *temp_dev;
+ struct plist_node *node;
+ int ret = 0;
+ struct voltagedomain *voltdm;
+ unsigned long volt;
+
+ if (!dvfs_info || IS_ERR(dvfs_info)) {
+ pr_warning("%s: VDD specified does not exist!\n", __func__);
+ return -EINVAL;
+ }
+
+ voltdm = dvfs_info->voltdm;
+
+ mutex_lock(&dvfs_info->scaling_mutex);
+
+ /* Find the highest voltage being requested */
+ node = plist_last(&dvfs_info->user_list);
+ volt = node->prio;
+
+ curr_volt = omap_voltage_get_nom_volt(voltdm);
+
+ if (curr_volt == volt) {
+ is_volt_scaled = 1;
+ } else if (curr_volt < volt) {
+ ret = omap_voltage_scale_vdd(voltdm, volt);
+ if (ret) {
+ pr_warning("%s: Unable to scale the %s to %ld volt\n",
+ __func__, voltdm->name, volt);
+ mutex_unlock(&dvfs_info->scaling_mutex);
+ return ret;
+ }
+ is_volt_scaled = 1;
+ }
+
+ list_for_each_entry(temp_dev, &dvfs_info->dev_list, node) {
+ struct device *dev;
+ struct opp *opp;
+ unsigned long freq;
+
+ dev = temp_dev->dev;
+ if (!plist_head_empty(&temp_dev->user_list)) {
+ node = plist_last(&temp_dev->user_list);
+ freq = node->prio;
+ } else {
+ opp = omap_dvfs_find_voltage(dev, volt);
+ if (IS_ERR(opp))
+ continue;
+ freq = opp_get_freq(opp);
+ }
+
+ if (freq == omap_device_get_rate(dev)) {
+ dev_dbg(dev, "%s: Already at the requested"
+ "rate %ld\n", __func__, freq);
+ continue;
+ }
+
+ ret |= omap_device_set_rate(dev, freq);
+ }
+
+ if (!is_volt_scaled && !ret)
+ omap_voltage_scale_vdd(voltdm, volt);
+
+ mutex_unlock(&dvfs_info->scaling_mutex);
+
+ return 0;
+}
+
+/**
* omap_dvfs_init() - Initialize omap dvfs layer
*
* Initalizes omap dvfs layer. It basically allocates memory for
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/13] OMAP: Introduce device scale implementation
This patch adds omap_device_scale API which can be used to generic
device rate scaling.
Based on original patch from Thara.
Signed-off-by: Vishwanath BS
Cc: Thara Gopinath
---
arch/arm/mach-omap2/dvfs.c | 116
arch/arm/plat-omap/include/plat/dvfs.h |7 ++
2 files changed, 123 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-omap2/dvfs.c
index c9d3894..05a9ce3 100755
--- a/arch/arm/mach-omap2/dvfs.c
+++ b/arch/arm/mach-omap2/dvfs.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/**
* struct omap_dev_user_list - Structure maitain userlist per device
@@ -585,6 +586,121 @@ static int omap_dvfs_voltage_scale(struct
omap_vdd_dvfs_info *dvfs_info)
}
/**
+ * omap_device_scale() - Set a new rate at which the device is to operate
+ * @req_dev: pointer to the device requesting the scaling.
+ * @target_dev:pointer to the device that is to be scaled
+ * @rate: the rnew rate for the device.
+ *
+ * This API gets the device opp table associated with this device and
+ * tries putting the device to the requested rate and the voltage domain
+ * associated with the device to the voltage corresponding to the
+ * requested rate. Since multiple devices can be assocciated with a
+ * voltage domain this API finds out the possible voltage the
+ * voltage domain can enter and then decides on the final device
+ * rate. Return 0 on success else the error value
+ */
+int omap_device_scale(struct device *req_dev, struct device *target_dev,
+ unsigned long rate)
+{
+ struct opp *opp;
+ unsigned long volt, freq, min_freq, max_freq;
+ struct omap_vdd_dvfs_info *dvfs_info;
+ struct platform_device *pdev;
+ struct omap_device *od;
+ int ret = 0;
+
+ pdev = container_of(target_dev, struct platform_device, dev);
+ od = container_of(pdev, struct omap_device, pdev);
+
+ /*
+* Figure out if the desired frquency lies between the
+* maximum and minimum possible for the particular device
+*/
+ min_freq = 0;
+ if (IS_ERR(opp_find_freq_ceil(target_dev, &min_freq))) {
+ dev_err(target_dev, "%s: Unable to find lowest opp\n",
+ __func__);
+ return -ENODEV;
+ }
+
+ max_freq = ULONG_MAX;
+ if (IS_ERR(opp_find_freq_floor(target_dev, &max_freq))) {
+ dev_err(target_dev, "%s: Unable to find highest opp\n",
+ __func__);
+ return -ENODEV;
+ }
+
+ if (rate < min_freq)
+ freq = min_freq;
+ else if (rate > max_freq)
+ freq = max_freq;
+ else
+ freq = rate;
+
+ opp = opp_find_freq_ceil(target_dev, &freq);
+ if (IS_ERR(opp)) {
+ dev_err(target_dev, "%s: Unable to find OPP for freq%ld\n",
+ __func__, rate);
+ return -ENODEV;
+ }
+
+ /* Get the voltage corresponding to the requested frequency */
+ volt = opp_get_voltage(opp);
+
+ /*
+* Call into the voltage layer to get the final voltage possible
+* for the voltage domain associated with the device.
+*/
+
+ if (rate) {
+ dvfs_info = get_dvfs_info(od->hwmods[0]->voltdm);
+
+ ret = omap_dvfs_add_freq_request(dvfs_info, req_dev,
+ target_dev, freq);
+ if (ret) {
+ dev_err(target_dev, "%s: Unable to add frequency
request\n",
+ __func__);
+ return ret;
+ }
+
+ ret = omap_dvfs_add_vdd_user(dvfs_info, req_dev, volt);
+ if (ret) {
+ dev_err(target_dev, "%s: Unable to add voltage
request\n",
+ __func__);
+ omap_dvfs_remove_freq_request(dvfs_info, req_dev,
+ target_dev);
+ return ret;
+ }
+ } else {
+ dvfs_info = get_dvfs_info(od->hwmods[0]->voltdm);
+
+ ret = omap_dvfs_remove_freq_request(dvfs_info, req_dev,
+ target_dev);
+ if (ret) {
+ dev_err(target_dev, "%s: Unable to remove frequency
request\n",
+ __func__);
+ return ret;
+ }
+
+ ret = omap_dvfs_remove_vdd_user(dvfs_info, req_dev);
+ if (ret) {
+ dev_err(target_dev, "%s: Unable to remove voltage
request\n",
+ __func__);
+ return ret;
+ }
+ }
+
+ /* Do the actual scaling */
+ ret = omap_dvfs_voltage_scale(dvfs_info);
+ if (!ret)
+ if
[PATCH 01/13] OMAP: Introduce accessory APIs for DVFS
This patch introduces accessory APIs for DVFS.
Data structures added:
1. omap_dev_user_list: This structure maintains list of frequency requests per
device basis. When a device needs to be scaled to a particular frequency,
This list is searched to find the maximum request for a given device.
If noone has placed any request, device frequency is obtained from device
opp table.
2. omap_vdd_dev_list: This strcucture stores device list per vdd basis.
Whenever a device is registered with a vdd, it is added to this list.
3. omap_vdd_user_list: User list of devices associated with each voltage domain
instance. The user list is implemented using plist structure with priority
node populated with the voltage values.
4. omap_vdd_dvfs_info: This structure is used to abstract DVFS related
information per VDD basis. It holds pointer to corresponding vdd's
voltagedomain instance and pointer to user list.
Following APIs have been added to operate on above data structures:
1. omap_dvfs_add_vdd_user - API to add a user into omap_vdd_user_list
2. omap_vdd_user_list - API to remove a user from omap_vdd_user_list
3. omap_dvfs_register_device - API to register a device with vdd
4. omap_dvfs_add_freq_request - API to add a frequency request into
omap_dev_user_list
5. omap_dvfs_remove_freq_request - API to remove a frequency request from
omap_dev_user_list
6. omap_dvfs_find_voltage - API to find the opp corresponding to given voltage
DVFS layer is initialized and basic data structures are allocated and
initialized as part of this.
This patch is based on Thara's previous DVFS implementation, but with major
rework.
Signed-off-by: Vishwanath BS
Cc: Thara Gopinath
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/dvfs.c | 456
arch/arm/plat-omap/include/plat/dvfs.h | 27 ++
arch/arm/plat-omap/omap_device.c |9 +
4 files changed, 493 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/dvfs.c
create mode 100644 arch/arm/plat-omap/include/plat/dvfs.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4ab82f6..bb2e2bc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -61,7 +61,7 @@ ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o pm_bus.o voltage.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o voltage.o \
- cpuidle34xx.o pm_bus.o
+ cpuidle34xx.o pm_bus.o dvfs.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o voltage.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach-omap2/dvfs.c
new file mode 100644
index 000..8832e4a
--- /dev/null
+++ b/arch/arm/mach-omap2/dvfs.c
@@ -0,0 +1,456 @@
+/*
+ * OMAP3/OMAP4 DVFS Management Routines
+ *
+ * Author: Vishwanath BS
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Vishwanath BS
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct omap_dev_user_list - Structure maitain userlist per devide
+ *
+ * @dev: The device requesting for a particular frequency
+ * @node: The list head entry
+ * @freq: frequency being requested
+ *
+ * Using this structure, user list (requesting dev * and frequency) for
+ * each device is maintained. This is how we can have different devices
+ * at different frequencies (to support frequency locking and throttling).
+ * Even if one of the devices in a given vdd has locked it's frequency,
+ * other's can still scale their frequency using this list.
+ * If no one has placed a frequency request for a device, then device is
+ * set to the frequency from it's opp table.
+ */
+struct omap_dev_user_list {
+ struct device *dev;
+ struct plist_node node;
+ u32 freq;
+};
+
+/**
+ * struct omap_vdd_dev_list - Device list per vdd
+ *
+ * @dev: The device belonging to a particular vdd
+ * @node: The list head entry
+ */
+struct omap_vdd_dev_list {
+ struct device *dev;
+ struct list_head node;
+ struct plist_head user_list;
+ spinlock_t user_lock; /* spinlock for plist */
+};
+
+/**
+ * struct omap_vdd_user_list - The per vdd user list
+ *
+ * @dev: The device asking for the vdd to be set at a particular
+ * voltage
+ * @node: The list head entry
+ * @volt: The voltage requested by the device
+ */
+struct omap_vdd_user_list {
+ struct device *dev;
+ struct plist_node nod
[PATCH 02/13] OMAP: Introduce device specific set rate and get rate in omap_device structure
From: Thara Gopinath
This patch extends the omap_device structure to contain pointers to scale the
operating rate of the device and to retrieve the operating rate of the device.
This patch also adds the three new APIs in the omap device layer
namely omap_device_set_rate that can be called to set a new operating
rate for a device, omap_device_get_rate that can be called to retrieve
the operating frequency for a device and omap_device_register_dvfs_callbacks
to register the device specific set_rate and get_rate functions.
The omap_device_set_rate and omap_device_get_rate does some routine error
checks and finally calls into the device specific set_rate
and get_rate APIs populated through omap_device_populate_rate_fns.
Signed-off-by: Thara Gopinath
Signed-off-by: Vishwanath BS
---
arch/arm/plat-omap/include/plat/omap_device.h |9 +
arch/arm/plat-omap/omap_device.c | 49 +
2 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..204fb0a 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -50,6 +50,8 @@ extern struct device omap_device_parent;
* @hwmods: (one .. many per omap_device)
* @hwmods_cnt: ARRAY_SIZE() of @hwmods
* @pm_lats: ptr to an omap_device_pm_latency table
+ * @set_rate: fn ptr to change the operating rate.
+ * @get_rate: fn ptr to retrieve the current operating rate.
* @pm_lats_cnt: ARRAY_SIZE() of what is passed to @pm_lats
* @pm_lat_level: array index of the last odpl entry executed - -1 if never
* @dev_wakeup_lat: dev wakeup latency in nanoseconds
@@ -73,6 +75,8 @@ struct omap_device {
s8 pm_lat_level;
u8 hwmods_cnt;
u8 _state;
+ int (*set_rate)(struct device *dev, unsigned long rate);
+ unsigned long (*get_rate) (struct device *dev);
};
/* Device driver interface (call via platform_data fn ptrs) */
@@ -107,6 +111,11 @@ void __iomem *omap_device_get_rt_va(struct omap_device
*od);
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
+int omap_device_set_rate(struct device *dev, unsigned long freq);
+unsigned long omap_device_get_rate(struct device *dev);
+void omap_device_register_dvfs_callbacks(struct device *dev,
+ int (*set_rate)(struct device *dev, unsigned long rate),
+ unsigned long (*get_rate) (struct device *dev));
u32 omap_device_get_context_loss_count(struct platform_device *pdev);
/* Other */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index a84e849..4cee430 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -810,6 +810,55 @@ int omap_device_enable_clocks(struct omap_device *od)
return 0;
}
+int omap_device_set_rate(struct device *dev, unsigned long freq)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ pdev = container_of(dev, struct platform_device, dev);
+ od = _find_by_pdev(pdev);
+
+ if (!od->set_rate) {
+ dev_err(dev, "%s: No set_rate API for scaling device\n",
+ __func__);
+ return -ENODATA;
+ }
+
+ return od->set_rate(dev, freq);
+}
+
+unsigned long omap_device_get_rate(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ pdev = container_of(dev, struct platform_device, dev);
+ od = _find_by_pdev(pdev);
+
+
+ if (!od->get_rate) {
+ dev_err(dev, "%s: No get rate API for the device\n",
+ __func__);
+ return 0;
+ }
+
+ return od->get_rate(dev);
+}
+
+void omap_device_register_dvfs_callbacks(struct device *dev,
+ int (*set_rate)(struct device *dev, unsigned long rate),
+ unsigned long (*get_rate) (struct device *dev))
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+
+ pdev = container_of(dev, struct platform_device, dev);
+ od = _find_by_pdev(pdev);
+
+ od->set_rate = set_rate;
+ od->get_rate = get_rate;
+}
+
struct device omap_device_parent = {
.init_name = "omap",
.parent = &platform_bus,
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/13] OMAP: Basic DVFS Framework
This patch series introduces support for Dynamic Voltage and Frequency Scaling (DVFS) for OMAP devices. For detailed design details, refer to DVFS Documentation. Pending Work: 1. OMAP4 support Changes done in this series: 1. Seperated DVFS code from Voltage layer (voltage.c) and introduced DVFS layer in dvfs.c 2. Added support for frequency throttling and frequency locking (by introducing frequency list per device) 3. Added changes in omap cpufreq driver for DVFS support 4. Fixed race condition issues in DVFS layer 5. Added documentation for DVFS framework 5. Addressed comments received on V2 V1: https://patchwork.kernel.org/patch/120132/ V2: https://patchwork.kernel.org/patch/290542/ Contributors to conceptualization of the design include Anand Sawant Benoit Cousson , Kevin Hilman , Paul Wamsley , Parthasarathy Basak Thara Gopinath Vishwanath Sripathy This patch series is generated against latest kevin's pm branch and has been tested on ZOOM3 for mpu, iva and core DVFS. Thara Gopinath (6): OMAP: Introduce device specific set rate and get rate in omap_device structure OMAP3: Introduce custom set rate and get rate APIs for scalable OMAP: Disable Smartreflex across DVFS devices OMAP3: Introduce voltage domain info in the hwmod structures. OMAP3: Add voltage dependency table for VDD1. OMAP2PLUS: Enable various options in defconfig Vishwanath BS (7): OMAP: Introduce accessory APIs for DVFS OMAP: Implement Basic DVFS OMAP: Introduce dependent voltage domain support OMAP: Introduce device scale implementation OMAP3: cpufreq driver changes for DVFS support OMAP2PLUS: Replace voltage values with Macros OMAP: Add DVFS Documentation Documentation/arm/OMAP/omap_dvfs | 111 arch/arm/configs/omap2plus_defconfig |4 + arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/dvfs.c| 751 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c|3 + arch/arm/mach-omap2/opp3xxx_data.c| 47 +- arch/arm/mach-omap2/opp4xxx_data.c| 13 +- arch/arm/mach-omap2/pm.c | 71 +++ arch/arm/mach-omap2/voltage.c | 159 ++ arch/arm/plat-omap/cpu-omap.c | 35 +- arch/arm/plat-omap/include/plat/dvfs.h| 34 ++ arch/arm/plat-omap/include/plat/omap_device.h |9 + arch/arm/plat-omap/include/plat/voltage.h | 148 + arch/arm/plat-omap/omap_device.c | 58 ++ 14 files changed, 1293 insertions(+), 152 deletions(-) create mode 100644 Documentation/arm/OMAP/omap_dvfs create mode 100644 arch/arm/mach-omap2/dvfs.c create mode 100644 arch/arm/plat-omap/include/plat/dvfs.h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
> -Original Message-
> From: Rob Herring [mailto:robherri...@gmail.com]
> Sent: Thursday, January 20, 2011 10:05 PM
> To: Santosh Shilimkar
> Cc: linux-arm-ker...@lists.infradead.org; Russell King; linux-
> o...@vger.kernel.org; Linus Walleij
> Subject: Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK
> to speed-up boot
[..]
> >>
> >> There's already one way to do this with pre-calculated lpj.
> >>
> > How about the hot-plug path? This is not for just boot.
>
> The path is the same for hotplug and secondary boot, so yes for
> both.
> Plus you get the added benefit of speeding up the primary core boot
> as well.
>
No 'preset_lpj' will not work for the hotplug path when
cpufreq is active. It just useful only for boot in
its current form.
> >
> >> Also, this isn't multi-platform friendly. You could accomplish
> the
> >> same
> >> thing using the clock api to get the core frequency of each core
> and
> >> only calculate lpj if the frequency is different.
> > May be but what's wrong with the obvious approach which is
> > completely non-intrusive.
> > Why is not multi-platform friendly ?
> > Archs can choose not to select this option.
>
> I meant you can't have single kernel binary with a platform with
> single
> core freq and a platform with independent core freq.
>
> Looking at this some more, the only reason to call calibrate_delay
> is to
> get a more accurate value. If you have different frequencies per
> core,
> you've got bigger problems as loops_per_jiffy value is not per core.
> So
> your kconfig option name is misleading. Something like
> ARCH_WANT_UDELAY_RECALC would be more accurate. To get a more
> accurate
> calculation, calibrate_delay only needs to be called by 1 secondary
> core. Perhaps it could be called from somewhere that is not in the
> boot/hotplug path or only done once.
>
Similar name was there in my earlier version.
"ARCH_SKIP_SECONDARY_CALIBRATE"
I changed it based on Linus W suggestion. I understand your one
binary point and this patch.
How about below approach?
-
[PATCH] ARM: smp: Skip secondary cpu calibration to speed-up boot
On some architectures, secondary cores shares clock with primiary
core and hence scale together. Hence secondary core lpj calibration
is not necessary and can be skipped to save considerable time.
This can speed up the secondary cpu boot and hotplug cpu online
paths.
Signed-off-by: Santosh Shilimkar
---
arch/arm/include/asm/smp.h |8
arch/arm/kernel/smp.c | 34 ++
arch/arm/mach-omap2/omap-smp.c |3 +++
3 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index 96ed521..7ffdfec 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -69,6 +69,14 @@ asmlinkage void secondary_start_kernel(void);
extern void platform_secondary_init(unsigned int cpu);
/*
+ * Skip the secondary calibration on architectures sharing clock
+ * with primary cpu. Needs to be called for archs inside
+ * platform_secondary_init()
+ */
+extern void secondary_skip_calibrate(void);
+
+
+/*
* Initialize cpu_possible map, and enable coherency
*/
extern void platform_smp_prepare_cpus(unsigned int);
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 4539ebc..b20c408 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -55,6 +55,8 @@ enum ipi_msg_type {
IPI_CPU_STOP,
};
+static unsigned int skip_secondary_calibrate;
+
int __cpuinit __cpu_up(unsigned int cpu)
{
struct cpuinfo_arm *ci = &per_cpu(cpu_data, cpu);
@@ -270,6 +272,16 @@ static void __cpuinit smp_store_cpu_info(unsigned int
cpuid)
}
/*
+ * Skip the secondary calibration on architectures sharing clock
+ * with primary cpu. Needs to be called for archs from
+ * platform_secondary_init()
+ */
+void secondary_skip_calibrate(void)
+{
+ skip_secondary_calibrate = 1;
+}
+
+/*
* This is the secondary CPU boot entry. We're using this CPUs
* idle thread stack, but a set of temporary page tables.
*/
@@ -312,7 +324,8 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
*/
percpu_timer_setup();
- calibrate_delay();
+ if (!skip_secondary_calibrate)
+ calibrate_delay();
smp_store_cpu_info(cpu);
@@ -332,14 +345,19 @@ void __init smp_cpus_done(unsigned int max_cpus)
int cpu;
unsigned long bogosum = 0;
- for_each_online_cpu(cpu)
- bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
+ if (!skip_secondary_calibrate) {
+ for_each_online_cpu(cpu)
+ bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
- printk(KERN_INFO "SMP: Total of %d processors activated "
- "(%lu.%02lu BogoMIPS).\n",
- num_online_cpus(),
- bogosum / (50/HZ),
- (bogosum / (5000/HZ)) % 100);
[PATCH v5 4/6] OMAP4: hwmod data: Add McSPI
From: Benoit Cousson
Update omap4 hwmod file with McSPI info.
Signed-off-by: Benoit Cousson
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked-by: Grant Likely
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267
1 files changed, 267 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c2806bd..9554685 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "omap_hwmod_common_data.h"
@@ -1435,6 +1436,266 @@ static struct omap_hwmod omap44xx_iva_hwmod = {
};
/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_mcspi_hwmod_class = {
+ .name = "mcspi",
+ .sysc = &omap44xx_mcspi_sysc,
+ .rev = OMAP4_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod omap44xx_mcspi1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcspi1_irqs[] = {
+ { .irq = 65 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi1_sdma_reqs[] = {
+ { .name = "tx0", .dma_req = 34 + OMAP44XX_DMA_REQ_START },
+ { .name = "rx0", .dma_req = 35 + OMAP44XX_DMA_REQ_START },
+ { .name = "tx1", .dma_req = 36 + OMAP44XX_DMA_REQ_START },
+ { .name = "rx1", .dma_req = 37 + OMAP44XX_DMA_REQ_START },
+ { .name = "tx2", .dma_req = 38 + OMAP44XX_DMA_REQ_START },
+ { .name = "rx2", .dma_req = 39 + OMAP44XX_DMA_REQ_START },
+ { .name = "tx3", .dma_req = 40 + OMAP44XX_DMA_REQ_START },
+ { .name = "rx3", .dma_req = 41 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcspi1_addrs[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480981ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per -> mcspi1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__mcspi1 = {
+ .master = &omap44xx_l4_per_hwmod,
+ .slave = &omap44xx_mcspi1_hwmod,
+ .clk= "l4_div_ck",
+ .addr = omap44xx_mcspi1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcspi1_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* mcspi1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mcspi1_slaves[] = {
+ &omap44xx_l4_per__mcspi1,
+};
+
+static struct omap2_mcspi_dev_attr omap_mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
+static struct omap_hwmod omap44xx_mcspi1_hwmod = {
+ .name = "mcspi1",
+ .class = &omap44xx_mcspi_hwmod_class,
+ .mpu_irqs = omap44xx_mcspi1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mcspi1_irqs),
+ .sdma_reqs = omap44xx_mcspi1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_mcspi1_sdma_reqs),
+ .main_clk = "mcspi1_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4PER_MCSPI1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_mcspi1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mcspi1_slaves),
+ .dev_attr = &omap_mcspi1_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* mcspi2 */
+static struct omap_hwmod omap44xx_mcspi2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcspi2_irqs[] = {
+ { .irq = 66 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcspi2_sdma_reqs[] = {
+ { .name = "tx0", .dma_req = 42 + OMAP44XX_DMA_REQ_START },
+ { .name = "rx0", .dma_req = 43 + OMAP44XX_DMA_REQ_START },
+ { .name = "tx1", .dma_req = 44 + OMAP44XX_DMA_REQ_START },
+ { .name = "rx1", .dma_req = 45 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcspi2_addrs[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a1ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per -> mcspi2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__mcspi2 = {
+ .master = &omap44xx_l4_per_hwmod,
+ .slave = &omap44xx_mcspi2_hwmod,
+ .clk= "l4_div_ck",
+ .addr = omap44xx_mcspi2_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcspi2_addrs),
+ .user = OCP_USER_MPU | O
[PATCH v5 5/6] OMAP: devices: Modify McSPI device to adapt to hwmod framework
From: Charulatha V
Cleans up all base address definitions for omap_mcspi
and adapts the device registration and driver to hwmod framework.
Changes involves:
1) Removing all base address macro defines.
2) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device attribute(number of chipselect).
3) Appending base address with pdata reg_offset for omap4 boards.
For omap4 all regs used in driver deviate with reg_offset_macros
defined with an value of 0x100. So pass this offset through pdata
and append the same to base address retrieved from hwmod data file
and we are not mapping *_HL_* regs which are not used in driver.
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked-by: Grant Likely
Reviewed-by: Partha Basak
---
arch/arm/mach-omap2/devices.c | 187 +++
arch/arm/plat-omap/include/plat/mcspi.h |3 +
drivers/spi/omap2_mcspi.c | 110 +--
3 files changed, 71 insertions(+), 229 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 381f4eb..8cfc654 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -279,163 +280,55 @@ static inline void omap_init_audio(void) {}
#include
-#define OMAP2_MCSPI1_BASE 0x48098000
-#define OMAP2_MCSPI2_BASE 0x4809a000
-#define OMAP2_MCSPI3_BASE 0x480b8000
-#define OMAP2_MCSPI4_BASE 0x480ba000
-
-#define OMAP4_MCSPI1_BASE 0x48098100
-#define OMAP4_MCSPI2_BASE 0x4809a100
-#define OMAP4_MCSPI3_BASE 0x480b8100
-#define OMAP4_MCSPI4_BASE 0x480ba100
-
-static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
- .num_cs = 4,
-};
-
-static struct resource omap2_mcspi1_resources[] = {
- {
- .start = OMAP2_MCSPI1_BASE,
- .end= OMAP2_MCSPI1_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi1 = {
- .name = "omap2_mcspi",
- .id = 1,
- .num_resources = ARRAY_SIZE(omap2_mcspi1_resources),
- .resource = omap2_mcspi1_resources,
- .dev= {
- .platform_data = &omap2_mcspi1_config,
- },
-};
-
-static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
- .num_cs = 2,
-};
-
-static struct resource omap2_mcspi2_resources[] = {
- {
- .start = OMAP2_MCSPI2_BASE,
- .end= OMAP2_MCSPI2_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi2 = {
- .name = "omap2_mcspi",
- .id = 2,
- .num_resources = ARRAY_SIZE(omap2_mcspi2_resources),
- .resource = omap2_mcspi2_resources,
- .dev= {
- .platform_data = &omap2_mcspi2_config,
- },
-};
-
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
- defined(CONFIG_ARCH_OMAP4)
-static struct omap2_mcspi_platform_config omap2_mcspi3_config = {
- .num_cs = 2,
-};
-
-static struct resource omap2_mcspi3_resources[] = {
- {
- .start = OMAP2_MCSPI3_BASE,
- .end= OMAP2_MCSPI3_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi3 = {
- .name = "omap2_mcspi",
- .id = 3,
- .num_resources = ARRAY_SIZE(omap2_mcspi3_resources),
- .resource = omap2_mcspi3_resources,
- .dev= {
- .platform_data = &omap2_mcspi3_config,
- },
-};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-static struct omap2_mcspi_platform_config omap2_mcspi4_config = {
- .num_cs = 1,
-};
-
-static struct resource omap2_mcspi4_resources[] = {
- {
- .start = OMAP2_MCSPI4_BASE,
- .end= OMAP2_MCSPI4_BASE + 0xff,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device omap2_mcspi4 = {
- .name = "omap2_mcspi",
- .id = 4,
- .num_resources = ARRAY_SIZE(omap2_mcspi4_resources),
- .resource = omap2_mcspi4_resources,
- .dev= {
- .platform_data = &omap2_mcspi4_config,
+struct omap_device_pm_latency omap_mcspi_latency[] = {
+ [0] = {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
-#endif
-#ifdef CONFIG_ARCH_OMAP4
-sta
[PATCH v5 2/6] OMAP2430: hwmod data: Add McSPI
From: Charulatha V
Update the 2430 hwmod data file with McSPI info.
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked-by: Grant Likely
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219
1 files changed, 219 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8ecfbcd..60fe4aa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "omap_hwmod_common_data.h"
@@ -45,6 +46,9 @@ static struct omap_hwmod omap2430_gpio3_hwmod;
static struct omap_hwmod omap2430_gpio4_hwmod;
static struct omap_hwmod omap2430_gpio5_hwmod;
static struct omap_hwmod omap2430_dma_system_hwmod;
+static struct omap_hwmod omap2430_mcspi1_hwmod;
+static struct omap_hwmod omap2430_mcspi2_hwmod;
+static struct omap_hwmod omap2430_mcspi3_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -223,6 +227,60 @@ static struct omap_hwmod_ocp_if *omap2430_l4_wkup_slaves[]
= {
static struct omap_hwmod_ocp_if *omap2430_l4_wkup_masters[] = {
};
+/* l4 core -> mcspi1 interface */
+static struct omap_hwmod_addr_space omap2430_mcspi1_addr_space[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480980ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcspi1 = {
+ .master = &omap2430_l4_core_hwmod,
+ .slave = &omap2430_mcspi1_hwmod,
+ .clk= "mcspi1_ick",
+ .addr = omap2430_mcspi1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_mcspi1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core -> mcspi2 interface */
+static struct omap_hwmod_addr_space omap2430_mcspi2_addr_space[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcspi2 = {
+ .master = &omap2430_l4_core_hwmod,
+ .slave = &omap2430_mcspi2_hwmod,
+ .clk= "mcspi2_ick",
+ .addr = omap2430_mcspi2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_mcspi2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core -> mcspi3 interface */
+static struct omap_hwmod_addr_space omap2430_mcspi3_addr_space[] = {
+ {
+ .pa_start = 0x480b8000,
+ .pa_end = 0x480b80ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcspi3 = {
+ .master = &omap2430_l4_core_hwmod,
+ .slave = &omap2430_mcspi3_hwmod,
+ .clk= "mcspi3_ick",
+ .addr = omap2430_mcspi3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_mcspi3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* L4 WKUP */
static struct omap_hwmod omap2430_l4_wkup_hwmod = {
.name = "l4_wkup",
@@ -919,6 +977,162 @@ static struct omap_hwmod omap2430_dma_system_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_mcspi_class = {
+ .name = "mcspi",
+ .sysc = &omap2430_mcspi_sysc,
+ .rev = OMAP2_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod_irq_info omap2430_mcspi1_mpu_irqs[] = {
+ { .irq = 65 },
+};
+
+static struct omap_hwmod_dma_info omap2430_mcspi1_sdma_reqs[] = {
+ { .name = "tx0", .dma_req = 35 }, /* DMA_SPI1_TX0 */
+ { .name = "rx0", .dma_req = 36 }, /* DMA_SPI1_RX0 */
+ { .name = "tx1", .dma_req = 37 }, /* DMA_SPI1_TX1 */
+ { .name = "rx1", .dma_req = 38 }, /* DMA_SPI1_RX1 */
+ { .name = "tx2", .dma_req = 39 }, /* DMA_SPI1_TX2 */
+ { .name = "rx2", .dma_req = 40 }, /* DMA_SPI1_RX2 */
+ { .name = "tx3", .dma_req = 41 }, /* DMA_SPI1_TX3 */
+ { .name = "rx3", .dma_req = 42 }, /* DMA_SPI1_RX3 */
+};
+
+static struct omap_hwmod_ocp_if *omap2430_mcspi1_slaves[] = {
+ &omap2430_l4_core__mcspi1,
+};
+
[PATCH v5 3/6] OMAP3: hwmod data: Add McSPI
From: Charulatha V
Update omap3 hwmod data file with McSPI info.
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked-by: Grant Likely
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280
1 files changed, 280 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8d81813..800eda4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "omap_hwmod_common_data.h"
@@ -55,6 +56,10 @@ static struct omap_hwmod omap3xxx_gpio5_hwmod;
static struct omap_hwmod omap3xxx_gpio6_hwmod;
static struct omap_hwmod omap34xx_sr1_hwmod;
static struct omap_hwmod omap34xx_sr2_hwmod;
+static struct omap_hwmod omap34xx_mcspi1;
+static struct omap_hwmod omap34xx_mcspi2;
+static struct omap_hwmod omap34xx_mcspi3;
+static struct omap_hwmod omap34xx_mcspi4;
static struct omap_hwmod omap3xxx_dma_system_hwmod;
@@ -1356,6 +1361,275 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
+/* l4 core -> mcspi1 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi1_addr_space[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480980ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi1 = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap34xx_mcspi1,
+ .clk= "mcspi1_ick",
+ .addr = omap34xx_mcspi1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core -> mcspi2 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi2_addr_space[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi2 = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap34xx_mcspi2,
+ .clk= "mcspi2_ick",
+ .addr = omap34xx_mcspi2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core -> mcspi3 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi3_addr_space[] = {
+ {
+ .pa_start = 0x480b8000,
+ .pa_end = 0x480b80ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi3 = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap34xx_mcspi3,
+ .clk= "mcspi3_ick",
+ .addr = omap34xx_mcspi3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core -> mcspi4 interface */
+static struct omap_hwmod_addr_space omap34xx_mcspi4_addr_space[] = {
+ {
+ .pa_start = 0x480ba000,
+ .pa_end = 0x480ba0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap34xx_l4_core__mcspi4 = {
+ .master = &omap3xxx_l4_core_hwmod,
+ .slave = &omap34xx_mcspi4,
+ .clk= "mcspi4_ick",
+ .addr = omap34xx_mcspi4_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_mcspi4_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap34xx_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_mcspi_class = {
+ .name = "mcspi",
+ .sysc = &omap34xx_mcspi_sysc,
+ .rev = OMAP3_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod_irq_info omap34xx_mcspi1_mpu_irqs[] = {
+ { .name = "irq", .irq = 65 },
+};
+
+static struct omap_hwmod_dma_info omap34xx_mcspi1_sdma_reqs[] = {
+ { .name = "tx0", .dma_req = 35 },
+ { .name = "rx0", .dma_req = 36 },
+ { .name = "tx1", .dma_req = 37 },
+ { .name = "rx1", .dma_req = 38 },
+ { .name = "tx2", .dma_req = 39 },
+ {
[PATCH v5 6/6] OMAP: runtime: McSPI driver runtime conversion
McSPI runtime conversion.
Changes involves:
1) remove clock framework apis to use runtime framework apis.
2) context restore from runtime resume which is a callback for get_sync.
3) Remove SYSCONFIG(sysc) register handling
(a) Remove context save and restore of sysc reg and remove soft reset
done from sysc reg as this will be done with hwmod framework.
(b) Also cleanup sysc reg bit macros.
4) Rename the omap2_mcspi_reset function to omap2_mcspi_master_setup
function as with hwmod changes soft reset will be done in
hwmod framework itself and use the return value from clock
enable function to return for failure scenarios.
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked-by: Grant Likely
Reviewed-by: Partha Basak
---
drivers/spi/omap2_mcspi.c | 120 +---
1 files changed, 46 insertions(+), 74 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 6018fe4..6a202a1 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
@@ -46,7 +47,6 @@
#define OMAP2_MCSPI_MAX_CTRL 4
#define OMAP2_MCSPI_REVISION 0x00
-#define OMAP2_MCSPI_SYSCONFIG 0x10
#define OMAP2_MCSPI_SYSSTATUS 0x14
#define OMAP2_MCSPI_IRQSTATUS 0x18
#define OMAP2_MCSPI_IRQENABLE 0x1c
@@ -63,13 +63,6 @@
/* per-register bitmasks: */
-#define OMAP2_MCSPI_SYSCONFIG_SMARTIDLEBIT(4)
-#define OMAP2_MCSPI_SYSCONFIG_ENAWAKEUPBIT(2)
-#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE BIT(0)
-#define OMAP2_MCSPI_SYSCONFIG_SOFTRESETBIT(1)
-
-#define OMAP2_MCSPI_SYSSTATUS_RESETDONEBIT(0)
-
#define OMAP2_MCSPI_MODULCTRL_SINGLE BIT(0)
#define OMAP2_MCSPI_MODULCTRL_MS BIT(2)
#define OMAP2_MCSPI_MODULCTRL_STESTBIT(3)
@@ -122,13 +115,12 @@ struct omap2_mcspi {
spinlock_t lock;
struct list_headmsg_queue;
struct spi_master *master;
- struct clk *ick;
- struct clk *fck;
/* Virtual base address of the controller */
void __iomem*base;
unsigned long phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
+ struct device *dev;
};
struct omap2_mcspi_cs {
@@ -144,7 +136,6 @@ struct omap2_mcspi_cs {
* corresponding registers are modified.
*/
struct omap2_mcspi_regs {
- u32 sysconfig;
u32 modulctrl;
u32 wakeupenable;
struct list_head cs;
@@ -268,9 +259,6 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
omap2_mcspi_ctx[spi_cntrl->bus_num - 1].modulctrl);
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
- omap2_mcspi_ctx[spi_cntrl->bus_num - 1].sysconfig);
-
mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
omap2_mcspi_ctx[spi_cntrl->bus_num - 1].wakeupenable);
@@ -280,20 +268,12 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
}
static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
{
- clk_disable(mcspi->ick);
- clk_disable(mcspi->fck);
+ pm_runtime_put_sync(mcspi->dev);
}
static int omap2_mcspi_enable_clocks(struct omap2_mcspi *mcspi)
{
- if (clk_enable(mcspi->ick))
- return -ENODEV;
- if (clk_enable(mcspi->fck))
- return -ENODEV;
-
- omap2_mcspi_restore_ctx(mcspi);
-
- return 0;
+ return pm_runtime_get_sync(mcspi->dev);
}
static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
@@ -819,8 +799,9 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return ret;
}
- if (omap2_mcspi_enable_clocks(mcspi))
- return -ENODEV;
+ ret = omap2_mcspi_enable_clocks(mcspi);
+ if (ret < 0)
+ return ret;
ret = omap2_mcspi_setup_transfer(spi, NULL);
omap2_mcspi_disable_clocks(mcspi);
@@ -863,10 +844,11 @@ static void omap2_mcspi_work(struct work_struct *work)
struct omap2_mcspi *mcspi;
mcspi = container_of(work, struct omap2_mcspi, work);
- spin_lock_irq(&mcspi->lock);
- if (omap2_mcspi_enable_clocks(mcspi))
- goto out;
+ if (omap2_mcspi_enable_clocks(mcspi) < 0)
+ return;
+
+ spin_lock_irq(&mcspi->lock);
/* We only enable one channel at a time -- the one whose message is
* at the head of the queue -- although this controller would gladly
@@ -979,10 +961,9 @@ static void omap2_mcspi_work(struct work_struct *work)
spin_lock_irq(&mcspi->lock);
}
- omap2_mcspi_disable_clocks(mcspi);
-
-out:
spin_unlock_irq(&mcspi->lock);
+
+
[PATCH v5 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
Changes invloves: 1) Addition of hwmod data for omap2/3/4. 2) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 3) Runtime Conversion of McSPI driver. Changes from v4: --- 1) 4430 hwmod file alignment based on Benoit's comments. http://www.spinics.net/lists/arm-kernel/msg111215.html 4430 Hwmod file now aligned based on: http://gitorious.org/omap-pm/linux/blobs/pm-wip/ hwmods-omap4-full/arch/arm/mach-omap2/omap_hwmod_44xx_data.c Changes from v3: --- 1) Updated proper Author for all patches which was missed in v2. 2) Modified 4430 hwmod data file so that mcspi data gets updated in proper alphabetical order. 3) Update omap2/3 hwmod dat files with SYSS_HAS_RESET_STATUS flag. Changes from v2: --- 1) Fixing minor comments and adding ack from Grant Likely. https://patchwork.kernel.org/patch/371321/ https://patchwork.kernel.org/patch/371331/ Changes from v1: --- 1) Fixing patch 5/5 comments for hwmod+runtime Split the patch 5/5 to hwmod adaptation and then runtime conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html Testing Updates: Was tested using data transfer test module available at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ utils/mcspi_modules/omap_mcspi_datatest.c; h=e42ec10c5c844abdde6a7175a268b379fbbdb655; hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 This test basically involves MISO <--> MOSI lines looped and data transfer test done using the above test module. System wide suspend and ret/off counts observation, ensured that no behavioral difference with and without this patch series. Benoit Cousson (1): OMAP4: hwmod data: Add McSPI Charulatha V (4): OMAP2420: hwmod data: Add McSPI OMAP2430: hwmod data: Add McSPI OMAP3: hwmod data: Add McSPI OMAP: devices: Modify McSPI device to adapt to hwmod framework Govindraj.R (1): OMAP: runtime: McSPI driver runtime conversion arch/arm/mach-omap2/devices.c | 187 --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267 ++ arch/arm/plat-omap/include/plat/mcspi.h| 11 + drivers/spi/omap2_mcspi.c | 224 +++--- 7 files changed, 1044 insertions(+), 300 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
[PATCH v5 1/6] OMAP2420: hwmod data: Add McSPI
From: Charulatha V
Update the omap2420 hwmod data with the McSPI info.
Add a device attribute structure which will be used
for passing number of chipselects from hwmod data.
Add revision macros to be passed from rev field from
hwmod.
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Acked-by: Grant Likely
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156
arch/arm/plat-omap/include/plat/mcspi.h|8 ++
2 files changed, 164 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b85c630..7fffd34 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "omap_hwmod_common_data.h"
@@ -44,6 +45,8 @@ static struct omap_hwmod omap2420_gpio2_hwmod;
static struct omap_hwmod omap2420_gpio3_hwmod;
static struct omap_hwmod omap2420_gpio4_hwmod;
static struct omap_hwmod omap2420_dma_system_hwmod;
+static struct omap_hwmod omap2420_mcspi1_hwmod;
+static struct omap_hwmod omap2420_mcspi2_hwmod;
/* L3 -> L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -88,6 +91,42 @@ static struct omap_hwmod omap2420_uart3_hwmod;
static struct omap_hwmod omap2420_i2c1_hwmod;
static struct omap_hwmod omap2420_i2c2_hwmod;
+/* l4 core -> mcspi1 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi1_addr_space[] = {
+ {
+ .pa_start = 0x48098000,
+ .pa_end = 0x480980ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi1 = {
+ .master = &omap2420_l4_core_hwmod,
+ .slave = &omap2420_mcspi1_hwmod,
+ .clk= "mcspi1_ick",
+ .addr = omap2420_mcspi1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcspi1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4 core -> mcspi2 interface */
+static struct omap_hwmod_addr_space omap2420_mcspi2_addr_space[] = {
+ {
+ .pa_start = 0x4809a000,
+ .pa_end = 0x4809a0ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcspi2 = {
+ .master = &omap2420_l4_core_hwmod,
+ .slave = &omap2420_mcspi2_hwmod,
+ .clk= "mcspi2_ick",
+ .addr = omap2420_mcspi2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcspi2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* L4_CORE -> L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
.master = &omap2420_l4_core_hwmod,
@@ -864,6 +903,119 @@ static struct omap_hwmod omap2420_dma_system_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/*
+ * 'mcspi' class
+ * multichannel serial port interface (mcspi) / master/slave synchronous serial
+ * bus
+ */
+
+static struct omap_hwmod_class_sysconfig omap2420_mcspi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_mcspi_class = {
+ .name = "mcspi",
+ .sysc = &omap2420_mcspi_sysc,
+ .rev = OMAP2_MCSPI_REV,
+};
+
+/* mcspi1 */
+static struct omap_hwmod_irq_info omap2420_mcspi1_mpu_irqs[] = {
+ { .irq = 65 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcspi1_sdma_reqs[] = {
+ { .name = "tx0", .dma_req = 35 }, /* DMA_SPI1_TX0 */
+ { .name = "rx0", .dma_req = 36 }, /* DMA_SPI1_RX0 */
+ { .name = "tx1", .dma_req = 37 }, /* DMA_SPI1_TX1 */
+ { .name = "rx1", .dma_req = 38 }, /* DMA_SPI1_RX1 */
+ { .name = "tx2", .dma_req = 39 }, /* DMA_SPI1_TX2 */
+ { .name = "rx2", .dma_req = 40 }, /* DMA_SPI1_RX2 */
+ { .name = "tx3", .dma_req = 41 }, /* DMA_SPI1_TX3 */
+ { .name = "rx3", .dma_req = 42 }, /* DMA_SPI1_RX3 */
+};
+
+static struct omap_hwmod_ocp_if *omap2420_mcspi1_slaves[] = {
+ &omap2420_l4_core__mcspi1,
+};
+
+static struct omap2_mcspi_dev_attr omap_mcspi1_dev_attr = {
+ .num_chipselect = 4,
+};
+
+static struct omap_hwmod omap2420_mcspi1_hwmod = {
+ .name = "mcspi1_hwmod",
+ .mpu_irqs = omap2420_mcspi1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mcspi1_mpu_irqs),
+ .sdma_reqs = omap2420_mcspi1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_mcspi1_sdma_reqs),
+ .main_clk
Re: [PATCH v7 00/18] OMAP2,3: hwmod DSS Adaptation
Hi Kevin, On Fri, Jan 21, 2011 at 10:36 AM, Kevin Hilman wrote: > Hi Sumit, > > Sumit Semwal writes: > > [...] > >> Testing: >> - >> The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. >> Complete bootup with penguins on panel is done on 3430sdp. >> For the rest of the mentioned platforms, kernel is built with "OMAP2_DSS" >> and bootup is tested so that base address and clk_get calls are successful. > > I think this series needs more validation on the other platforms. > Getting a visible framebuffer w/tux on all tested platforms seems like a > minimal requirement. > > I gave a test of this on 3530/Beagle with CONFIG_PANEL_GENERIC_DPI=y and > driving a DVI monitor, using the following kernel cmdline > > # cat /proc/cmdline > console=ttyO2,115200n8 mpurate=600 vram=12M omapfb.mode=dvi:1024x768MR-16@60 > omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 > rootwait > > Without your series, I see penguin logo and get a console login on the > screen with this boot log (from dmesg |grep -i omapfb): > > [ 2.651885] OMAPFB: omapfb_init > [ 2.652160] OMAPFB: omapfb_probe > [ 2.657653] OMAPFB: create 3 framebuffers > [ 2.657714] OMAPFB: fb_infos allocated > [ 2.657714] OMAPFB: allocating 1572864 bytes for fb 0 > [ 2.668212] OMAPFB: allocated VRAM paddr 8f40, vaddr d0a0 > [ 2.668243] OMAPFB: region0 phys 8f40 virt d0a0 size=1572864 > [ 2.668243] OMAPFB: region1 phys virt (null) size=0 > [ 2.668273] OMAPFB: region2 phys virt (null) size=0 > [ 2.668273] OMAPFB: fbmems allocated > [ 2.668518] OMAPFB: check_fb_var 0 > [ 2.668548] OMAPFB: max frame size 1572864, line size 2048 > [ 2.668548] OMAPFB: xres = 1024, yres = 768, vxres = 1024, vyres = 768 > [ 2.668579] OMAPFB: set_fb_fix > [ 2.669036] OMAPFB: fb_infos initialized > [ 2.673522] OMAPFB: set_par(0) > [ 2.673614] OMAPFB: set_fb_fix > [ 2.673614] OMAPFB: apply_changes, fb 0, ovl 0 > [ 2.673645] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 > [ 2.673645] OMAPFB: paddr 8f40, vaddr d0a0 > [ 2.674346] OMAPFB: pan_display(0) > [ 2.674346] OMAPFB: setcmap > [ 2.674377] OMAPFB: setcmap > [ 2.683746] OMAPFB: pan_display(0) > [ 2.683776] OMAPFB: setcmap > [ 2.692108] OMAPFB: setcmap > [ 2.701599] OMAPFB: framebuffers registered > [ 2.701629] OMAPFB: apply_changes, fb 0, ovl 0 > [ 2.701660] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 > [ 2.701690] OMAPFB: paddr 8f40, vaddr d0a0 > [ 2.701721] OMAPFB: apply_changes, fb 1, ovl 1 > [ 2.701751] OMAPFB: apply_changes, fb 2, ovl 2 > [ 2.701751] OMAPFB: create_framebuffers done > [ 2.702331] OMAPFB: mgr->apply'ed > [ 2.704803] OMAPFB: create sysfs for fbs > [ 2.704833] OMAPFB: create sysfs for fbs > > With your series applied (no other changes), I don't see anything on the > screen because omapfb_probe() fails: > > [ 2.519653] OMAPFB: omapfb_init > [ 2.519958] OMAPFB: omapfb_probe > [ 2.520019] omapfb omapfb: no driver for display > [ 2.525115] OMAPFB: free_resources > [ 2.525146] OMAPFB: free all fbmem > [ 2.525177] omapfb omapfb: failed to setup omapfb > > which indicates that omap_dss_get_device() is failing in omapfb_probe(). Thanks for testing this out - yes, you're right. I was able to reproduce this here, after getting hold of a beagle from someone, and found out the reason. The patch series misses some updates of device names [they were done for 3430sdp, but left out for other platforms somehow in the version of patches I got from the original authors.] I am updating this now, and will send out an updated patchset in some time. Unfortunately, the platforms available to me right now for testing were rather limited, so I would truly appreciate testing on other platforms not mentioned in the mail. Best regards, ~Sumit. > > Kevin > -- 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: [Query] OMAP: DSS2: Margin for downscaling in clock calculations
On Wed, 2011-01-19 at 02:39 +0530, ext Taneja, Archit wrote: > Hi, > > Tomi Valkeinen wrote: > > On Tue, 2011-01-18 at 10:45 +0530, ext Taneja, Archit wrote: > >> Hi, > >> > >> I was going through the DSS2 code which sets up the FCLK coming > >> from PRCM and the DISPC divivors to get the required pixel clock. > >> > >> The function dss_calc_clock_div() does a brute force search across > >> all possible values of: a) DPLL divisor whose output goes to DSS, > >> b) DISPC_DIVISOR.LCD, c) DISPC_DIVISOR.pcd > >> > >> The combination which gives a clock frequency closest to the > >> required pixel clock is chosen. > >> > >> Hence, it seems that the resultant DISPC_FCLK clock frequency > >> doesn't take into account the extra margin needed for downscaling: > >> > >> Req dispc_fclk >= pck * hscale_ratio * vscale_ration * K > >> > >> Do you thing putting a further constraint (like DISPC_FCLK needs > >> to be greater than a given value) should be a part of the > >> calculations to ensure successful scaling? > > > > It's been a while since I looked at the fclk requirements, > > but isn't the current CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK > > enough? It is quite hackish and static, but a proper > > implementation is much harder (dynamically changing the > > clocks depending on the scaling). > > > > I think I ignored this part of the code :), I suppose this should be good > enough for most cases. > > I was wondering why we can't try to get the DSS_FCLK always at the max > clock supported? Which is 173 Mhz on omap2/3. > > Is it because we won't get a close enough pck with the lcd, pcd divisor > combinations or is it needed to save power? Main reason has been power saving. I don't know how much changing the clock itself affects, but then there are things like the lowest OPP is only possible when DSS_FCLK is lower than 96MHz (or someting like that, can't remember), and that may have a bigger impact. > If we stick to 173 Mhz(or something close to it) we could provide the best > possible downscaling(which may need dispc_fck as much as 8 times the pixel > clock) > > Consider 2 hypothetical divisor combinations for a desired pixel clock: > > a)DISPC_FCLK=120Mhz, delta between calculated pck and desired pck ~ 1% > b)DISPC_FCLK=160Mhz, delta between calculated pck and desired pck ~ 2% > > Wouldn't it be better to go with option (b) since it gives me something close > to a desired pixel clock and also ensures better downscaling? It's difficult to say. I have to say I have no idea how picky panels are with the pixels clocks. If your panel works with option a but not with b, then obviously a is a better choice =). > Using CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK may or may not let me arrive at(b), > since > it will ensure jumps at discrete multiples of pck. > > I am not totally sure if I make much sense, but would appreciate comments > anyway :) While I think it's very important to somehow be able to get whatever clock settings one's particular use case requires, and for many cases it may be important to get the FCLK as low as possible, perhaps there's a point in what you say. We could have some kind of "non-power-saving-mode", in which DSS doesn't aim to aim for low clock, but to give best performance and scaling. This would probably be fine for cases where your board is powered from a wall supply, and you are not concerned about a few milliamps. But then again, that would still be a bit hacky. What we should have is a dynamically changed clock depending on the clock requirements. But that's a bit tricky... 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: [Query] mm: !*pte hit in mm/memory.c:remap_pte_range
On Thu, Jan 20, 2011 at 03:06:30PM -0600, Aguirre, Sergio wrote:
> And while debugging further, i realized that the point of stall was
> in mm/memory.c, function:
>
> static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
> unsigned long addr, unsigned long end,
> unsigned long pfn, pgprot_t prot)
> {
> pte_t *pte;
> spinlock_t *ptl;
>
> pte = pte_alloc_map_lock(mm, pmd, addr, &ptl);
> if (!pte)
> return -ENOMEM;
> arch_enter_lazy_mmu_mode();
> do {
>
>
> BUG_ON(!pte_none(*pte)); <---*** HERE
>
>
> set_pte_at(mm, addr, pte, pte_mkspecial(pfn_pte(pfn, prot)));
> pfn++;
> } while (pte++, addr += PAGE_SIZE, addr != end);
> arch_leave_lazy_mmu_mode();
> pte_unmap_unlock(pte - 1, ptl);
> return 0;
> }
>
> This is in 2.6.35.6 kernel + TI Android kernel changes. [1]
>
> How should i interpret this? Does this mean something specific?
It is asserting that the pte we are about to overwrite was empty. In
other words, there is no existing mapping in place at that virtual
address.
If there was a pre-existing mapping, you're doing something wrong
because you're potentially overwriting something else.
--
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: OMAP3 - PM - Question - Disabling CLKEN and HFCLKOUT signals from TWL4030 scripts
Hi Nagendra, > Hi All, > > We are working on Power management on OMAP3 (3530) and I am trying to > disable CLKEN and HFCLKOUT through TWL4030 power scripts. However we have > not been able to achieve this. > > Following are the changes and tests done so far. > > - VAUX1, CLKEN and HFCLKOUT were assigned to P1 group. > - Wrote Singular messages to turn on/off these signals in TWL4030 scripts. > - We observed that VAUX1 is able to switch ON/OFF properly as per the script > but HFCLKOUT and CLKEN are not behaving as expected. > - However if we try writing CLKEN_DEV_GRP to zero, CLKEN is going low. > - We have made sure that SYS_OFF_MODE and CLK_REQ signals go low during the > system OFF mode, LVL_WAKEUP bit enabled in Px_SW_EVENTS, and STS_CHG bit in > STS_HW_CONDITIONS is zero. > > Is there anything that I am missing? Kindly let me know. Did try probing the sys_clkreq from OMAP? Are you sending SLEEP/OFF command in singular msg? Also check the HFCLKOUT_REMAP register for SLEEP_STATE[3:0], if using SLEEP cmd. Regards, Lesly A M > > Part number of TPS used in our board is TPS65950 BZXNR > > with regards, > - Nagendra. > -- 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] OMAP: Enable Magic SysRq on serial console ttyOx
On Fri, Jan 21, 2011 at 3:31 PM, Thomas Weber wrote:
> Magic SysRq key is not working for OMAP on new serial
> console ttyOx because SUPPORT_SYSRQ is not defined
> for omap-serial.
>
> This patch defines SUPPORT_SYSRQ in omap-serial and
> enables handling of Magic SysRq character.
>
> Further there is an issue of losing first break character.
> Removing the reset of the lsr_break_flag fixes this issue.
>
> Signed-off-by: Thomas Weber
Acked-by: Govindraj.R
Tested-by: Manjunath G Kondaiah
> ---
> drivers/serial/omap-serial.c | 5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c
> index 7f2f010..699b344 100644
> --- a/drivers/serial/omap-serial.c
> +++ b/drivers/serial/omap-serial.c
> @@ -20,6 +20,10 @@
> * this driver as required for the omap-platform.
> */
>
> +#if defined(CONFIG_SERIAL_OMAP_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> +#define SUPPORT_SYSRQ
> +#endif
> +
> #include
> #include
> #include
> @@ -190,7 +194,6 @@ static inline void receive_chars(struct uart_omap_port
> *up, int *status)
> if (up->port.line == up->port.cons->index) {
> /* Recover the break flag from console xmit */
> lsr |= up->lsr_break_flag;
> - up->lsr_break_flag = 0;
> }
> #endif
> if (lsr & UART_LSR_BI)
> --
> 1.7.4.rc2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
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] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
> -Original Message- > From: Tero Kristo [mailto:tero.kri...@nokia.com] > Sent: Friday, January 21, 2011 4:07 PM > To: linux-omap@vger.kernel.org > Cc: Paul Walmsley; Kevin Hilman; Santosh Shilimkar; Vishwanath > Sripathy > Subject: [PATCHv2] OMAP3: CPUIdle: prevent CORE from going off if > doing so would reset an active clockdomain > > On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other > parts of the chip will be reset. If those parts of the chip are > busy, > the reset will disrupt them, causing unpredictable and generally > undesirable results. This reset is caused by the core domain wakeup > (COREDOMAINWKUP_RST), and it can occur for example in a case where > some peripheral domain is in retention or inactive state and core > enters off. This will result in the peripheral domain being reset. > > Signed-off-by: Tero Kristo > Cc: Paul Walmsley > Cc: Kevin Hilman > Cc: Santosh Shilimkar > Cc: Vishwanath Sripathy > --- Thanks for update Tero. If you like, Acked-by: Santosh Shilimkar -- 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
[PATCHv3] OMAP: Enable Magic SysRq on serial console ttyOx
Magic SysRq key is not working for OMAP on new serial
console ttyOx because SUPPORT_SYSRQ is not defined
for omap-serial.
This patch defines SUPPORT_SYSRQ in omap-serial and
enables handling of Magic SysRq character.
Further there is an issue of losing first break character.
Removing the reset of the lsr_break_flag fixes this issue.
Signed-off-by: Thomas Weber
---
drivers/serial/omap-serial.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c
index 7f2f010..699b344 100644
--- a/drivers/serial/omap-serial.c
+++ b/drivers/serial/omap-serial.c
@@ -20,6 +20,10 @@
* this driver as required for the omap-platform.
*/
+#if defined(CONFIG_SERIAL_OMAP_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
#include
#include
#include
@@ -190,7 +194,6 @@ static inline void receive_chars(struct uart_omap_port *up,
int *status)
if (up->port.line == up->port.cons->index) {
/* Recover the break flag from console xmit */
lsr |= up->lsr_break_flag;
- up->lsr_break_flag = 0;
}
#endif
if (lsr & UART_LSR_BI)
--
1.7.4.rc2
--
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
[PATCHv2] OMAP3: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
On OMAP3 SoCs, if the CORE powerdomain enters off-mode, many other
parts of the chip will be reset. If those parts of the chip are busy,
the reset will disrupt them, causing unpredictable and generally
undesirable results. This reset is caused by the core domain wakeup
(COREDOMAINWKUP_RST), and it can occur for example in a case where
some peripheral domain is in retention or inactive state and core
enters off. This will result in the peripheral domain being reset.
Signed-off-by: Tero Kristo
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Santosh Shilimkar
Cc: Vishwanath Sripathy
---
arch/arm/mach-omap2/cpuidle34xx.c | 40 +++-
1 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index f3e043f..d31b858 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -61,7 +61,7 @@ struct omap3_processor_cx {
struct omap3_processor_cx omap3_power_states[OMAP3_MAX_STATES];
struct omap3_processor_cx current_cx_state;
struct powerdomain *mpu_pd, *core_pd, *per_pd;
-struct powerdomain *cam_pd;
+struct powerdomain *cam_pd, *dss_pd, *iva2_pd, *sgx_pd, *usb_pd;
/*
* The latencies/thresholds for various C states have
@@ -235,7 +235,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
{
struct cpuidle_state *new_state = next_valid_state(dev, state);
u32 core_next_state, per_next_state = 0, per_saved_state = 0;
- u32 cam_state;
+ u32 cam_state, dss_state, iva2_state, sgx_state, usb_state;
struct omap3_processor_cx *cx;
int ret;
@@ -256,6 +256,8 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
*its own code.
*/
+ /* XXX Add CORE-active check here */
+
/*
* Prevent idle completely if CAM is active.
* CAM does not have wakeup capability in OMAP3.
@@ -275,6 +277,36 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
(core_next_state > PWRDM_POWER_RET))
per_next_state = PWRDM_POWER_RET;
+ /* XXX Add prevent-PER-off check here */
+
+ /*
+* If we are attempting CORE off, check if any other powerdomains
+* are at retention or higher. CORE off causes chipwide reset which
+* would reset these domains also.
+*/
+ if (core_next_state == PWRDM_POWER_OFF) {
+ iva2_state = pwrdm_read_pwrst(iva2_pd);
+ sgx_state = pwrdm_read_pwrst(sgx_pd);
+ usb_state = pwrdm_read_pwrst(usb_pd);
+ dss_state = pwrdm_read_pwrst(dss_pd);
+
+ if (cam_state > PWRDM_POWER_OFF ||
+ dss_state > PWRDM_POWER_OFF ||
+ iva2_state > PWRDM_POWER_OFF ||
+ per_next_state > PWRDM_POWER_OFF ||
+ sgx_state > PWRDM_POWER_OFF ||
+ usb_state > PWRDM_POWER_OFF)
+ core_next_state = PWRDM_POWER_RET;
+ }
+
+ /* Fallback to new target core/mpu state */
+ while (cx->core_state < core_next_state) {
+ state--;
+ cx = cpuidle_get_statedata(state);
+ }
+
+ new_state = state;
+
/* Are we changing PER target state? */
if (per_next_state != per_saved_state)
pwrdm_set_next_pwrst(per_pd, per_next_state);
@@ -489,6 +521,10 @@ int __init omap3_idle_init(void)
core_pd = pwrdm_lookup("core_pwrdm");
per_pd = pwrdm_lookup("per_pwrdm");
cam_pd = pwrdm_lookup("cam_pwrdm");
+ dss_pd = pwrdm_lookup("dss_pwrdm");
+ iva2_pd = pwrdm_lookup("iva2_pwrdm");
+ sgx_pd = pwrdm_lookup("sgx_pwrdm");
+ usb_pd = pwrdm_lookup("usbhost_pwrdm");
omap_init_power_states();
cpuidle_register_driver(&omap3_idle_driver);
--
1.7.1
--
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: CPUIdle: prevent CORE from going off if doing so would reset an active clockdomain
>-Original Message- >From: ext Santosh Shilimkar [mailto:santosh.shilim...@ti.com] >Sent: 19 January, 2011 11:03 >To: Kristo Tero (Nokia-MS/Tampere); Vishwanath Sripathy; linux- >o...@vger.kernel.org >Cc: p...@pwsan.com; khil...@deeprootsystems.com >Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if >doing so would reset an active clockdomain > >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >> ow...@vger.kernel.org] On Behalf Of tero.kri...@nokia.com >> Sent: Wednesday, January 19, 2011 2:09 PM >> To: vishwanath...@ti.com; linux-omap@vger.kernel.org >> Cc: p...@pwsan.com; khil...@deeprootsystems.com >> Subject: RE: [PATCH] OMAP3: CPUIdle: prevent CORE from going off if >> doing so would reset an active clockdomain >> >[...] > >> >> If some parts of the chip are busy, then how can Core domain >> enter off >> >> state? The necessary condition for Core to enter low power state >> is >> >that >> >> all the clock domains (including DSS, CAM, IVA, USB, PER etc) >> should >> >> have >> >> idled. Doesn't it mean that all the modules have idled and >> asserted >> >> idleack when Core is entering off state? >> >Besides these, Core off should reset the modules which are only in >> Core >> >domain. It should not impact other power domains. Also Core domain >> >modules >> >which are reset will restore their context when Core comes out of >> off >> >mode. So why are you saying that "If those parts of the chip are >> busy, >> >the reset will disrupt them, causing unpredictable and generally >> >undesirable results."? >> >> Core off issues reset to peripheral domains when it wakes up, this >> is somehow (badly) visible in TRM (look for COREDOMAINWKUP_RST.) >> When this reset happens, the peripheral domain shows its reset >> status as being high, but the powerdomain itself has not entered off >> (previous state can be e.g. RET), thus its context will not be >> restored. >> >Now its clear. Reseting other independent clockdomains is >certainly bad from CORE PD OFF to ON behavior . > >Please add this additional information to change log. I'll update the patch desc and resend it in a bit. -Tero -- 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] OMAP: Enable Magic SysRq on serial console ttyOx
On Fri, Jan 21, 2011 at 1:15 PM, G, Manjunath Kondaiah wrote: > On Fri, Jan 21, 2011 at 12:54:29PM +0530, Govindraj wrote: >> On Thu, Jan 20, 2011 at 5:49 PM, Anand Gadiyar wrote: >> >> > Magic SysRq key is not working for OMAP on new serial >> >> > console ttyOx because SUPPORT_SYSRQ is not defined >> >> > for omap-serial. >> >> > >> >> > This patch defines SUPPORT_SYSRQ in omap-serial and >> >> > enables handling of Magic SysRq character. >> >> > >> >> > Signed-off-by: Thomas Weber >> >> > >>> >> >> > >>> Looks fine to me. >> >> > >>> >> >> > >>> Acked-by: Govindraj.R >> >> > >> I tried to use SysRq key on minicom after applying this patch, it >> > looks >> >> > >> like it is not triggering sysrq event. >> >> > >> >> >> > >> Am I missing anything? >> >> > >> >> >> > >> -Manjunath >> >> > >> -- >> >> > > Hello Manjunath, >> >> > > >> >> > > Do you have CONFIG_MAGIC_SYSRQ enabled? >> >> > > Magic SysRq key in Kernel Hacking >> >> > > >> >> > > I tested it on Devkit8000 (beagle board clone). >> >> > > >> >> > >> >> > re-setting lsr_break_flag to 0 in receive chars is causing issues >> >> > in getting sysrq key break sequence on omap-serial.c >> >> > >> >> > Manju, >> >> > >> >> > can you try this change on your environment. >> >> > With below change works for me on 3430SDP/4430SDP. >> >> > key sequence I checked. >> >> > [alt + b + t] => shows trace of tasks running. >> >> > [alt + b + b] => system reboot. >> >> >> >> With below patch, it works fine on TeraTerm. However, I am not able to >> >> perform the same on minicom. >> >> >> >> Tested-by: Manjunath G Kondaiah >> >> >> >> -Manjunath >> >> >> > >> > Not sure what you guys are trying out, but I am able to use sysrq >> > just fine in minicom (using only Thomas' original patch) - you need >> > to send a break sequence, and the way to do this in minicom is to >> > do Ctrl-A followed by F. >> > >> > Works for me, without the "resetting lsr_break_flag to 0" part. >> > >> > @Govind, >> > >> > What are the issues you see in getting sysrq key break sequence >> > without your change? And how is your change fixing this? >> >> Actually I was using teraterm on windows platform. >> using keyboard to send a break char [alt + b] sometimes >> i observed that first break char was getting lost and subsequent break >> chars where getting >> recognized. However using send break option from terterm menu seems to >> work most of times. >> my change can be dropped. > If it is fixing the issue of losing first break character, what is wrong in > having this patch? > > Do you see any other issues because of this change? Haven't seen any thing else. Will leave it to Thomas to incorporate if he is willing to take up the change else will post out this change some time later. -- Thanks, Govindraj.R -- 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
OMAP3 - PM - Question - Disabling CLKEN and HFCLKOUT signals from TWL4030 scripts
Hi All, We are working on Power management on OMAP3 (3530) and I am trying to disable CLKEN and HFCLKOUT through TWL4030 power scripts. However we have not been able to achieve this. Following are the changes and tests done so far. - VAUX1, CLKEN and HFCLKOUT were assigned to P1 group. - Wrote Singular messages to turn on/off these signals in TWL4030 scripts. - We observed that VAUX1 is able to switch ON/OFF properly as per the script but HFCLKOUT and CLKEN are not behaving as expected. - However if we try writing CLKEN_DEV_GRP to zero, CLKEN is going low. - We have made sure that SYS_OFF_MODE and CLK_REQ signals go low during the system OFF mode, LVL_WAKEUP bit enabled in Px_SW_EVENTS, and STS_CHG bit in STS_HW_CONDITIONS is zero. Is there anything that I am missing? Kindly let me know. Part number of TPS used in our board is TPS65950 BZXNR with regards, - Nagendra. -- 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] OMAP2/3: clock: fix fint calculation for DPLL_FREQSEL
From: John Ogness
In OMAP35X TRM Rev 2010-05 Figure 7-18 "DPLL With EMI Reduction
Feature", it is shown that the internal frequency is calculated by
CLK_IN/(N+1). However, the value passed to _dpll_test_fint() is
already "N+1" since Linux is using the values to divide by. In the
technical reference manual, "N" is referring to the divider's register
value (0-127).
Signed-off-by: John Ogness
---
patch v3:
Patch against linux-next-20110121.
I have improved the commit message so that it is acceptable for the
git commit log.
arch/arm/mach-omap2/clkt_dpll.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 337392c..acb7ae5 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -77,7 +77,7 @@ static int _dpll_test_fint(struct clk *clk, u8 n)
dd = clk->dpll_data;
/* DPLL divider must result in a valid jitter correction val */
- fint = clk->parent->rate / (n + 1);
+ fint = clk->parent->rate / n;
if (fint < DPLL_FINT_BAND1_MIN) {
pr_debug("rejecting n=%d due to Fint failure, "
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: nand: bch ecc support added
> -Original Message- > From: Kishore Kadiyala [mailto:kishorek.kadiy...@gmail.com] > Sent: Friday, January 21, 2011 1:42 PM > To: Ghorai, Sukumar > Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- > ker...@lists.infradead.org > Subject: Re: [PATCH] omap3: nand: bch ecc support added > > Ghorai, > > > > > #ifdef CONFIG_MTD_PARTITIONS > > diff --git a/drivers/mtd/nand/omap_bch_decoder.c > b/drivers/mtd/nand/omap_bch_decoder.c > > new file mode 100644 > > index 000..da42bda > > --- /dev/null > > +++ b/drivers/mtd/nand/omap_bch_decoder.c > > @@ -0,0 +1,393 @@ > > +/* > > + * drivers/mtd/nand/omap_omap_bch_decoder.c > > + * > > + * Whole BCH ECC Decoder (Post hardware generated syndrome decoding) > > + * > > + * Copyright (c) 2007 Texas Instruments > > + * > > + * Author: Sukumar Ghorai > + * Michael Fillinger > > Vimal was the original author who has created this file > [No change in file name/directory hierarchy]. > It's not fair to remove Vimal's author and add your's. > > Instead you should have kept his name and added your's. [Ghorai] Ok. I will do .. But can you send me working version of these? At least comipled version for any kernel? > > > > Regards, > Kishore -- 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: nand: bch ecc support added
Ghorai, > #ifdef CONFIG_MTD_PARTITIONS > diff --git a/drivers/mtd/nand/omap_bch_decoder.c > b/drivers/mtd/nand/omap_bch_decoder.c > new file mode 100644 > index 000..da42bda > --- /dev/null > +++ b/drivers/mtd/nand/omap_bch_decoder.c > @@ -0,0 +1,393 @@ > +/* > + * drivers/mtd/nand/omap_omap_bch_decoder.c > + * > + * Whole BCH ECC Decoder (Post hardware generated syndrome decoding) > + * > + * Copyright (c) 2007 Texas Instruments > + * > + * Author: Sukumar Ghorai + * Michael Fillinger Vimal was the original author who has created this file [No change in file name/directory hierarchy]. It's not fair to remove Vimal's author and add your's. Instead you should have kept his name and added your's. Regards, Kishore -- 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: nand: bch ecc support added
> -Original Message- > From: Vimal Singh [mailto:vimal.neww...@gmail.com] > Sent: Friday, January 21, 2011 1:08 PM > To: Ghorai, Sukumar > Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- > ker...@lists.infradead.org; Kamat, Nishant > Subject: Re: [PATCH] omap3: nand: bch ecc support added > > On Fri, Jan 21, 2011 at 9:37 AM, Ghorai, Sukumar wrote: > > > >> -Original Message- > >> From: Vimal Singh [mailto:vimal.neww...@gmail.com] > >> Sent: Thursday, January 20, 2011 8:47 PM > >> To: Ghorai, Sukumar > >> Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux- > arm- > >> ker...@lists.infradead.org; Kamat, Nishant > >> Subject: Re: [PATCH] omap3: nand: bch ecc support added > >> > >> Hi Ghorai, > >> > >> I am the initial author of this patch. And I guess this patch still > >> uses most of my work. > > [Ghorai] I know you are working on it, > > > > But I think your code was in a shape for - > > 1. not for up-streamble shape > That's because I never posted it for up-stream. > > > 2. non functional, > No, it was a working (at least for 8-bit correction) patch on that > kernel version (I do not remember the correct version now, may be > .29-.30) [Ghorai] can you send me the version? > It did not work for 4-bit, because of known reason. And I guess while > posting this patch you should also have mentioned/documented about > that. No? > > > So can you check this version matching with your original code? > > In that case I can add your Signed-off. > Yes, you should. I can see this version has got many changes, but > original idea is same. [Ghorai] there is no special idea needed to correct the ecc. Only correct algorithm is nedded. >[Ghorai]And not all code is changed. Does it? [Ghorai] can you send me your latest version? > > Regards, > Vimal -- 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
