> -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 W
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 tes
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 a
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.
>>
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
"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
>> >> > fo
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 wakeu
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/us
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
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 consid
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_defcon
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 lit
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 west
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 west
* 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-om
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.
>
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 whi
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...@
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
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
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://f
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:
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
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
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
Signe
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
Review
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
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 regul
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
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
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 drive
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 dri
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
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 i
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
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
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 Semw
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 neede
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 t
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: Se
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: Sen
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
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
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
>
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 th
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 @@ stat
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] ar
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/
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-oma
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_
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_populat
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 thes
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.
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
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/confi
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/
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
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.
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.
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
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
> -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_
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
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 bas
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
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/
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 rese
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 co
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
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 menti
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 require
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,
>
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 as
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 ther
> -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
>
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
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
>-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: pr
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 i
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
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_d
> -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: bc
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_om
> -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: n
84 matches
Mail list logo
