Hi Santosh,
On 3/17/2011 6:52 AM, Shilimkar, Santosh wrote:
-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-
arm-kernel-boun...@lists.infradead.org] On Behalf Of Aaro Koskinen
Sent: Wednesday, March 16, 2011 10:46 PM
To: linux-omap@vger.kernel.org;
-Original Message-
From: Sripathy, Vishwanath
Sent: Wednesday, March 16, 2011 4:33 PM
To: Premi, Sanjeev; linux-omap@vger.kernel.org
Subject: RE: [RFCv2 2/2] AM35x: voltage: Basic initialization
-Original Message-
From: linux-omap-ow...@vger.kernel.org
-Original Message-
From: Cousson, Benoit [mailto:b-cous...@ti.com]
Sent: Thursday, March 17, 2011 1:50 PM
To: Shilimkar, Santosh
Cc: Aaro Koskinen; linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; t...@atomide.com
Subject: Re: [PATCH 1/2] arm: mach-omap2: devices:
David Anders wrote:
the pandaboard does not use the VUSIM or VAUX1 power regulators on the
TWL6030
and are left floating. if the VUSIM and VAUX1 power regulators are
initilized,
noise on the unloaded regulators generates an overcurrent interrupt
causing the
system to power down. this patch
Hi,
On Wed, 2011-03-16 at 18:49 -0500, Stephan Raue wrote:
i tried this test tree with omap2plus_defconfig.
it seems the kernel crashes and poweroff the board on loading this hdmi
stuff, but dont print any crashlog. is there a way any backtraces will
be printed?
output from serial
User push button in Beagleboard xM is 4 instead of 7.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
arch/arm/mach-omap2/board-omap3beagle.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
David Anders x0132...@ti.com writes:
the pandaboard does not use the VUSIM or VAUX1 power regulators on the TWL6030
and are left floating. if the VUSIM and VAUX1 power regulators are initilized,
noise on the unloaded regulators generates an overcurrent interrupt causing
the
system to power
Hi Nishanth,
Nishanth Menon n...@ti.com writes:
OMAP3 SmartReflex IRQs in hwmod structures with the same naming as
present in OMAP4. Without these IRQs being registered, SmartReflex
driver will be unable to get the IRQ numbers to handle notifications
Signed-off-by: Nishanth Menon
Nishanth Menon n...@ti.com writes:
Handle the case for a future SoC where sys_ck_name might be
uninitialized. Fixes the build warning:
arch/arm/mach-omap2/voltage.c: In function 'omap_voltage_late_init':
arch/arm/mach-omap2/voltage.c:86:8: warning: 'sys_ck_name' may be used
uninitialized in
Nishanth Menon n...@ti.com writes:
Blindly setting a 1.2V setting in the initial structure may not even
match the default voltages stored in the voltage table which are
supported for the domain. For example, OMAP3430 core domain does not
use 1.2V and ends up generating a warning on the first
Nishanth Menon n...@ti.com writes:
cat of debugfs entry for vp_volt provides voltage. The additional pr_notice
is just spam on console and provides no additional information.
Signed-off-by: Nishanth Menon n...@ti.com
Thanks, queueing for 2.6.39-rc fixes cycle.
Kevin
---
It is not necessary to pass the params prm_mod and
prm_irqst_mod to omap_voltage_early_init().
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/voltage.c | 18 ++
arch/arm/mach-omap2/voltage.h |3 +--
In all usages, variables prm_mod_offs and prm_irqst_ocp_mod_offs
are expected to be u16 but have been declared as s16.
In addition, renamed prm_irqst_ocp_mod_offs to ocp_sysreg_prm_offs
for better association with the TRM. Original name perhaps came
from the current usage of this offset to reach
Applies on omap-for-linus branch
Boot tested on OMAP4430 SDP and OMAP3630SDP
Balaji T K (3):
ARM: OMAP2+: correct GPMC IRQ
ARM: OMAP2+: GPMC set dummy irq chip
ARM: OMAP4: correct GPMC IRQ number
arch/arm/mach-omap2/gpmc.c | 13 -
OMAP4 GPMC IRQ is not same as OMAP3 IRQ. Fix it.
Resolve following warning in OMAP4
[0.429290] gpmc: irq-20 could not claim: err -22
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git
Raue,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Thursday, March 17, 2011 4:41 PM
To: Stephan Raue
Cc: K, Mythri P; linux-omap@vger.kernel.org
Subject: Re: [PATCH v5 00/10] OMAP4 : DSS2 :
Nishanth Menon n...@ti.com writes:
Voltage values can get confusing in meaning with various SmartReflex
classes being active. Depending on the class used, the actual voltage
selected might be a variant. For example:
With SmartReflex AVS class 3:
a) If we don't have SR enabled, we will go to
Nishanth Menon n...@ti.com writes:
We will enable and disable interrupt on a need basis in the class
driver. We need to keep the IRQ disabled by default else the
forceupdate or vcbypass events could trigger events that we don't
need/expect to handle.
This is a preparation for SmartReflex
Nishanth Menon n...@ti.com writes:
Since we already know the state of the autocomp enablement, we can
see if the requested state is different from the current state and
enable/disable SR only on the need basis.
Signed-off-by: Nishanth Menon n...@ti.com
Thanks, queuing for 2.6.40.
Kevin
Nishanth Menon n...@ti.com writes:
Error label case seems to have a 2 tab indentation when just 1 is
necessary.
Signed-off-by: Nishanth Menon n...@ti.com
Thanks, queuing for 2.6.40.
Kevin
---
arch/arm/mach-omap2/smartreflex.c | 20 ++--
1 files changed, 10
Nishanth Menon n...@ti.com writes:
Certain class drivers such as class 1.5 drivers, will need specific
notification that they have to be started up or stopped independent
of smart reflex operation. They also may need private data to be
used for operations of their own, provide the same.
This
Nishanth Menon n...@ti.com writes:
From: Jarkko Nikula jhnik...@gmail.com
sr_start_vddautocomp and sr_stop_autocomp functions can be reused from
omap_sr_enable, omap_sr_disable and omap_sr_disable_reset_volt and by
adding one additional argument sr_stop_autocomp. This allows us to have
a
Nishanth Menon n...@ti.com writes:
SmartReflex IP V1 and V2 have different registers and offsets.
Currently, we pass the status as is to the class driver. However,
since we don't pass the version of the underlying SR hardware
to the Class driver, it will not be unable to make consistent
Nishanth Menon n...@ti.com writes:
We need some mechanism from class drivers to control when notifiers
should be triggered and when not, currently we have none, which makes
Class driver usage of the interrupt events almost impossible.
Introduce an SmartReflex driver API for doing the same.
Nishanth Menon n...@ti.com writes:
Passing the volt_data pointers across allows us to save us the effort
of looking up the voltage data pointer from the voltage value at
multiple layers, we need to look at the voltage data in DVFS layer
for further processing, so modify the APIs to pass the
Hi Linus,
Please pull omap changes for this merge window from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-for-linus
To summarize, this contains omap3 and 4 PM updates, new ti816x
processor support, changes many drivers to use common hwmod
platform code,
Nishanth Menon n...@ti.com writes:
Traditional SmartReflex AVS(Automatic Voltage Scaling) classes are:
* Class 0 - Product test calibration
Silicon is calibration at production floor and fused with voltages
for each OPP
* Class 1 - Boot time calibration
Silicon is
Aaro Koskinen aaro.koski...@nokia.com writes:
Hi,
On Thu, 17 Mar 2011, Kevin Hilman wrote:
Thanks, queuing for 2.6.40.
[...]
- iounmap(sr_info-base);
- mem = platform_get_resource(sr_info-pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem-start,
Sanjeev Premi pr...@ti.com writes:
It is not necessary to pass the params prm_mod and
prm_irqst_mod to omap_voltage_early_init().
Signed-off-by: Sanjeev Premi pr...@ti.com
Hi Sanjeev,
I also started working on cleaning some of this up, but I took a
slightly different approach[1], namely I
Sanjeev Premi pr...@ti.com writes:
In all usages, variables prm_mod_offs and prm_irqst_ocp_mod_offs
are expected to be u16 but have been declared as s16.
What kind of problem is that causing?
Kevin
In addition, renamed prm_irqst_ocp_mod_offs to ocp_sysreg_prm_offs
for better association
On Thu, 17 Mar 2011, Premi, Sanjeev wrote:
The things, however, get stuck in HWMOD again when the parent of
[sp] Being more specific:
The parent here refers to parent vdd i.e. vdd_name.
~sanjeev
omap3xxx_l3_main_hwmod is set as core. Changing this causes
another
Am 17.03.2011 17:20, schrieb Janorkar, Mayuresh:
Raue,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Valkeinen, Tomi
Sent: Thursday, March 17, 2011 4:41 PM
To: Stephan Raue
Cc: K, Mythri P; linux-omap@vger.kernel.org
Jean Pihet jean.pi...@newoldbits.com writes:
Implement the wake-up latency constraints using an internal
unified function _set_dev_constraint at OMAP PM level,
which calls the corresponding function at omap device level.
The actual constraints management code is at the omap device level.
Jean Pihet jean.pi...@newoldbits.com writes:
The code at omap device level manages the constraints: storage,
tracking of requesters and dispatching to the low level
code (e.g. powerdomain for the wake-up latency constraints).
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency
Jean Pihet jean.pi...@newoldbits.com writes:
Hwmod is queried from the omap device layer to change the power domains
next power state. Hwmod retrieves the correct power domain and if it
exists it calls the corresponding power domain function.
Tested on OMAP3 Beagleboard in RET/OFF using
Jean Pihet jean.pi...@newoldbits.com writes:
When a wake-up constraint is requested or removed the omap device layer
dispatches the updated strongest constraint value.
The power domains get the next power state programmed directly in the
registers via pwrdm_wakeuplat_update_pwrst.
Note
Jean Pihet jean.pi...@newoldbits.com writes:
Figures are added to the power domains structs.
Note: the figures are preliminary figures. More accurate measurements
are needed. Also the conditions of measurements shall be investigated
and described.
Tested on OMAP3 Beagleboard in RET/OFF
Am 17.03.2011 21:16, schrieb Stephan Raue:
Am 17.03.2011 17:20, schrieb Janorkar, Mayuresh:
...
Is it possible for you to enable low-level debugging and pass
omapfb.debug=1 omapdss.debug=1 in your bootargs?
This would show the Framebuffer and DSSDBG prints. We would get an
idea if kernel is
G, Manjunath Kondaiah manj...@ti.com writes:
Patch series to support mstandby mode handling and enabling runtime PM
support for DMA driver.
I still have the same problems as with the previous revision:
This is still not runtime-suspending when I use my DMA test in linking
mode.
If I put a
Am 17.03.2011 22:13, schrieb Stephan Raue:
Am 17.03.2011 21:16, schrieb Stephan Raue:
an update:
compiled with DSS/HDMI support as modules, loading modules with:
modprobe omapdss
modprobe omapfb
and doing a
dmesg
in the init script gives me:
modprobe: can't load module omapdss
Nishanth Menon n...@ti.com writes:
pm44xx.c is built only when CONFIG_PM is setup,
remove redundant CONFIG_PM check.
This also fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=25022
Reported-by: Martin Etti ettl.mar...@gmx.de
Signed-off-by: Nishanth Menon n...@ti.com
Thanks, queuing
Santosh Shilimkar santosh.shilim...@ti.com writes:
This series is an attempt to clean-up OMAP CPUfreq driver.
- The OMAP1 and OMAP2PLUS cpufreq support is split to avoid
any #ifdefery
- The omap2plus_cupfreq support is updated to work on
SMP_ON_UP builds
-
Tony Lindgren t...@atomide.com writes:
* Kevin Hilman khil...@ti.com [110311 16:00]:
Tony Lindgren t...@atomide.com writes:
* DebBarma, Tarun Kanti tarun.ka...@ti.com [110310 20:18]:
From: Hilman, Kevin
I guess Tony has the final say here, but personally, I don't really like
Vishwanath BS vishwanath...@ti.com writes:
Voltage layer takes various parameters which can be broadly classified as
1. OMAP/VP specific parameters
2. PMIC specific parameters
3. Board specific parameters
For readability sake, this could be broken up along into 3 patches for
these 3 items.
Menon, Nishanth n...@ti.com writes:
[...]
my overall suggestion - when I fill in board file params - I should say:
I use PMIC x, i have oscillator with ramp y uSec - the params should
talk my language as a board developers - I dont want to know indepth
details of voltage VP/VC registers and
On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren t...@atomide.com wrote:
Please pull omap changes for this merge window from:
Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.
You need to stop stepping on each others toes. There is no way that
your changes to those crazy clock-data
On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren t...@atomide.com wrote:
Please pull omap changes for this merge window from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-for-linus
Btw, that generic hardware spinlock thing needs to be hidden from
sane people
On Thu, 2011-03-17 at 16:13 -0500, Stephan Raue wrote:
compiled with DSS/HDMI support as modules, loading modules with:
modprobe omapdss
modprobe omapfb
and doing a
dmesg
in the init script gives me:
modprobe: can't load module omapdss
Hi all,
While trying to understand the voltage layer, i have few comments and
doubts. This is not a comprehensive list, but for starters:
1) Functions omap3_voltage_read_reg(), omap3_voltage_write_reg()
which in turn call omap2_prm_read_mod_reg and omap2_prm_write_mod_reg()
These
-Original Message-
From: Hilman, Kevin
Sent: Friday, March 18, 2011 1:42 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] omap3: voltage: fix variable type and name
Sanjeev Premi pr...@ti.com writes:
In all usages, variables prm_mod_offs and
-Original Message-
From: Hilman, Kevin
Sent: Friday, March 18, 2011 1:41 AM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/2] omap3: voltage: remove unnecessary
param passing
Sanjeev Premi pr...@ti.com writes:
It is not necessary to pass the params
i tried this test tree with omap2plus_defconfig.
it seems the kernel crashes and poweroff the board on loading
this hdmi stuff, but dont print any crashlog. is there a
way any backtraces will be printed?
output from serial console: http://paste.pocoo.org/show/354850/
kernel config
i tried this test tree with omap2plus_defconfig.
it seems the kernel crashes and poweroff the board on loading
this hdmi stuff, but dont print any crashlog. is there a
way any backtraces will be printed?
output from serial console: http://paste.pocoo.org/show/354850/
kernel config
i tried this test tree with omap2plus_defconfig.
it seems the kernel crashes and poweroff the board on loading
this hdmi stuff, but dont print any crashlog. is there a
way any backtraces will be printed?
output from serial console: http://paste.pocoo.org/show/354850/
kernel config
i tried this test tree with omap2plus_defconfig.
it seems the kernel crashes and poweroff the board on loading
this hdmi stuff, but dont print any crashlog. is there a
way any backtraces will be printed?
output from serial console: http://paste.pocoo.org/show/354850/
kernel config
i tried this test tree with omap2plus_defconfig.
it seems the kernel crashes and poweroff the board on loading
this hdmi stuff, but dont print any crashlog. is there a
way any backtraces will be printed?
output from serial console: http://paste.pocoo.org/show/354850/
kernel config
i tried this test tree with omap2plus_defconfig.
it seems the kernel crashes and poweroff the board on loading
this hdmi stuff, but dont print any crashlog. is there a
way any backtraces will be printed?
output from serial console: http://paste.pocoo.org/show/354850/
kernel config
57 matches
Mail list logo
