On Tuesday 23 August 2011 10:36 PM, Kevin Hilman wrote:
Hi Santosh,
Santoshsantosh.shilim...@ti.com writes:
Rafael, Kevin,
On latest kernel( V3.1-rc1+), the subsystem(driver) suspend
callbacks are not getting called because power domain callbcaks
are populated.
And as per commit
On Wednesday 24 August 2011 09:32 AM, Rajendra Nayak wrote:
On 8/23/2011 8:04 PM, Santosh wrote:
+ Rajendra and Benoit to comment on optional clock
handling.
On Thursday 04 August 2011 04:34 PM, Tarun Kanti DebBarma wrote:
[]
+ if (IS_ERR_VALUE(pm_runtime_get_sync(bank-dev) 0))
+
Hi,
On 08/17/2011 02:43 PM, Keshava Munegowda wrote:
From: Benoit Cousson b-cous...@ti.com
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs
Once again my mailer played me... sending for the second time... sorry
Hi Bryan,
Please, CC linux-arm-ker...@lists.infradead.org for patches like this.
One question below
On 08/23/11 18:16, Bryan DE FARIA wrote:
Set the VAUX2 regulator supply to 1.8V for the HSUSB host interface.
Gpio 2 of
On Tue, Aug 23, 2011 at 04:48:29PM -0700, Kevin Hilman wrote:
Ben,
This series fell through the cracks for v3.1, so I've now rebased it
onto v3.1-rc3 and am submitting it for v3.2. It no longer has any
dependencies on OMAP trees, so could you please pull this into your tree
for
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Sripathy, Vishwanath
Sent: Tuesday, August 23, 2011 7:14 PM
To: Koyamangalath, Abhilash; linux-omap@vger.kernel.org
Cc: p...@pwsan.com; li...@arm.linux.org.uk; Cousson,
Set the VAUX2 regulator supply to 1.8V for the HSUSB host interface.
Gpio 2 of the TPS65950 has to be set to zero in order to enable the HSUBS2
clock.
Signed-off-by: Bryan DE FARIA bdefa...@adeneo-embedded.com
---
arch/arm/mach-omap2/board-omap3evm.c | 25 +
1 files
Hi,
On Tue, Aug 23, 2011 at 12:52:47PM -0700, Randy Dunlap wrote:
From: Randy Dunlap rdun...@xenotime.net
Fix build error when CONFIG_USB_GADGET_DWC3 is not enabled:
ERROR: dwc3_send_gadget_ep_cmd [drivers/usb/dwc3/dwc3.ko] undefined!
Signed-off-by: Randy Dunlap rdun...@xenotime.net
Hi Manju
On 8/23/2011 5:41 PM, G, Manjunath Kondaiah wrote:
On Tue, Aug 23, 2011 at 10:03:28AM +0500, G, Manjunath Kondaiah wrote:
Patch series reworked from:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/61674
Also added support for i2c1 controller on omap4 based panda
board.
On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Fix the build break caused when CONFIG_MEDIA_CONTROLLER
option is disabled and if any sensor driver has to be used
between MC and non MC framework compatible devices.
For example,if tvp514x video
Hi Grant,
Here is the first part of patches to add device-tree support for OMAP4
platforms. It is partially based on initial works done by Manju for i2c.
The main difference is the usage of the notifier to create omap_device and
the addition of the hwmods bindings.
That series mainly clean the
The __initconst introduced some build errors with the following
compiler version:
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010.09-50) 4.5.1
arch/arm/mach-omap2/board-omap3beagle.c:566:20: error:
omap3_beagle_dt_match causes a section type conflict
Replace them by __initdata.
Add initial device-tree support for OMAP4 SoC.
This is based on the original panda board patch done by Manju:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60393
Add the generic GIC interrupt-controller from ARM.
Add an empty soc node to contain non memory mapped IPs
(DSP, MPU, IPU...).
On Sunday 17 July 2011 06:13 PM, Shubhrajyoti D wrote:
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit device off still the
driver may have support for
Add the SDP/Blaze (Software Development Board) support with
device tree.
That file is based on the omap4-panda.dts.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: G, Manjunath Kondaiah manj...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 29
Based on the original omap4-panda.dts file from Manju.
http://www.spinics.net/lists/linux-omap/msg55836.html
Add memory information and a default bootargs to allow
a boot from RAMDISK.
Add missing header.
Include the common omap4.dtsi.
Add a ti,omap4 compatible value for OMAP4 based boards.
In order to avoid conflict with the new omap4-dt.c board file,
remove the .dt_compat entry from the pandaboard regular board
file.
Any DT work for OMAP4 will have to be done on the generic DT
board file to avoid breaking the legacy board support until
DT migration is done.
Signed-off-by: Benoit
Add a documentation to capture the specifics OMAP bindings
needed for device-tree support.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Randy Dunlap rdun...@xenotime.net
Cc: Grant Likely grant.lik...@secretlab.ca
---
.../devicetree/bindings/arm/omap/omap.txt | 38
Create an OMAP4 generic board to start the DT migration.
This file is doing the minimal initialization needed to boot
properly on a RAMDISK filesystem.
As soon as the OMAP4 specifics will be removed, that board will
be converted to an even more generic board-dt.c that will support
every OMAP 2+
On Wed, Aug 24, 2011 at 12:27 PM, Roger Quadros rog...@ti.com wrote:
Hi,
On 08/17/2011 02:43 PM, Keshava Munegowda wrote:
From: Benoit Cousson b-cous...@ti.com
Following 4 hwmod strcuture are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base
On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart
[laurent.pinch...@ideasonboard.com] wrote:
On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Fix the build break caused when CONFIG_MEDIA_CONTROLLER
option is disabled and if any sensor driver has to
Hi,
On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote:
On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote:
On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Fix the build break caused when CONFIG_MEDIA_CONTROLLER
option is
Hi,
Set the VAUX2 regulator supply to 1.8V for the HSUSB host interface.
Gpio 2 of the TPS65950 has to be set to zero in order to enable the
HSUBS2 clock.
TPS65950 GPIO2 is not to enable HSUSB2 clock but to enable chip u131
On omap3evm (rev-G) which latches USB, camera and audio lines.
Hi all,
Here are few patches for review to cleanup mach-omap2 for
Makefile and init_early.
The init_early changes will continue the earlier cleanup
efforts of initializing things later on during the boot
and cutting down dependencies.
Regards,
Tony
---
Tony Lindgren (3):
omap2+: Use
As noted by Grant Likely grant.lik...@secretlab.ca, omap2+ Makefile
unnecessarily
repeats entries for common device init code instead of using Kconfig symbol.
Remove references to hsmmc.o and board-flash.o. Also omap_phy_internal.o
references can be removed once it has some Kconfig symbol to
There's no need to call omap2_init_common_devices from init_early.
It reprograms the memory timings for some boards, so it's better to
do it later so we have a chance to get console messages if something
goes wrong.
Move it to happen after omap_serial_init gets called.
Signed-off-by: Tony
Introduce them for each omap variant and just make them all call
omap2_init_common_infrastructure for now. Do this for each board-*.c
file except for board-generic and board-omap3beagle as they use
the same machine ID for multiple SoCs.
No functional changes.
Signed-off-by: Tony Lindgren
Hi Tony,
On 8/24/2011 1:54 PM, Tony Lindgren wrote:
There's no need to call omap2_init_common_devices from init_early.
It reprograms the memory timings for some boards, so it's better to
do it later so we have a chance to get console messages if something
goes wrong.
BTW, I did some comment
On Wednesday 24 August 2011 05:41 PM, Cousson, Benoit wrote:
Hi Tony,
On 8/24/2011 1:54 PM, Tony Lindgren wrote:
There's no need to call omap2_init_common_devices from init_early.
It reprograms the memory timings for some boards, so it's better to
do it later so we have a chance to get console
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Wednesday, August 24, 2011 5:00 PM
To: Ravi, Deepthy
Cc: mche...@infradead.org; linux-me...@vger.kernel.org; linux-
ker...@vger.kernel.org; linux-omap@vger.kernel.org; Hiremath, Vaibhav
* Cousson, Benoit b-cous...@ti.com [110824 04:38]:
Hi Tony,
On 8/24/2011 1:54 PM, Tony Lindgren wrote:
There's no need to call omap2_init_common_devices from init_early.
It reprograms the memory timings for some boards, so it's better to
do it later so we have a chance to get console
There is no use for omap-alsa.h and board-palmz71.c doesn't need it either.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap1/board-palmz71.c |1 -
arch/arm/plat-omap/include/plat/omap-alsa.h | 123 ---
2 files changed, 0
On Tue, Aug 23, 2011 at 5:59 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Aug 23, 2011 at 5:07 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Can this be easily converted to a spin_lock?
Sure, thanks for reviewing.
Taking a second look, I don't think it's necessary - the mutex isn't
used
Hi Ajay,
TPS65950 GPIO2 is to choose through u131 if we drive the lines to the
evm mother board or to the expansion connector p18. Should not it be
default to the mother board?
The EHCI port on the mother board works with this patch.
Bryan
Hi,
Set the VAUX2 regulator supply to 1.8V for the
Hi Tony,
On 08/24/11 14:54, Tony Lindgren wrote:
Introduce them for each omap variant and just make them all call
omap2_init_common_infrastructure for now. Do this for each board-*.c
file except for board-generic and board-omap3beagle as they use
the same machine ID for multiple SoCs.
No
Fix the build break caused when CONFIG_MEDIA_CONTROLLER
option is disabled and if any sensor driver has to be used
between MC and non MC framework compatible devices.
For example,if tvp514x video decoder driver migrated to
MC framework is being built without
Hi Grant, Tony,
Here are a couple of drivers / devices adaptated to DT on OMAP4.
I focused first on devices that used to be initialized before machine_init
time (postcore_initcall most of the time).
The GPIO adaptation is not taking into account the current cleanup done
by Charu / Tarun. It will
Add device-tree support for the l3-noc driver.
Use platform_driver_register to defer the probing at device init
time.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_l3_noc.c | 16
Used the main OCP node to add bindings with the l3_noc driver.
Remove l3_noc static device creation if CONFIG_OF is defined.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |3
Add nodes for devices used by PM code (mpu, dsp, iva).
Add an empty cpus node as well as recommended in the DT spec.
Remove mpu, dsp, iva devices init if CONFIG_OF is defined.
Ideally the whole function should be removed. It will be doable as
soon as the OMAP3 DT support will be added.
Add documentation for the l3-noc bindings.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Randy Dunlap rdun...@xenotime.net
---
.../devicetree/bindings/arm/omap/l3-noc.txt| 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644
Add documentation for the OMAP4 processors bindings.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Randy Dunlap rdun...@xenotime.net
---
Documentation/devicetree/bindings/arm/omap/dsp.txt | 14
Documentation/devicetree/bindings/arm/omap/iva.txt | 18 ++
Add documentation for the HW spinlock in OMAP4.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Randy Dunlap rdun...@xenotime.net
---
.../bindings/hwspinlock/omap-spinlock.txt |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644
Adapt the GPIO driver to retrieve information from a DT file.
Note that since the driver is currently under cleanup, some hacks
will have to be removed after.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Charulatha V ch...@ti.com
Cc: Tarun Kanti
Add documentation for GPIO properties specific to OMAP.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Randy Dunlap rdun...@xenotime.net
---
.../devicetree/bindings/gpio/gpio-omap.txt | 33
1 files changed, 33 insertions(+), 0 deletions(-)
create mode 100644
-Original Message-
From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
Sent: Wednesday, August 24, 2011 6:26 PM
To: Hiremath, Vaibhav
Cc: Laurent Pinchart; Ravi, Deepthy; mche...@infradead.org; linux-
me...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
Hi Vaibhav,
On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote:
On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote:
On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote:
On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote:
On Friday 19 August 2011 15:48:45
On Wed, Aug 24, 2011 at 08:46:13AM -0400, Ohad Ben-Cohen wrote:
On Tue, Aug 23, 2011 at 5:59 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Aug 23, 2011 at 5:07 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Can this be easily converted to a spin_lock?
Sure, thanks for reviewing.
* Tony Lindgren t...@atomide.com [110824 04:48]:
* Cousson, Benoit b-cous...@ti.com [110824 04:38]:
void __init omap2_init_common_devices(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
if (cpu_is_omap24xx() ||
* Igor Grinberg grinb...@compulab.co.il [110824 05:15]:
On 08/24/11 14:54, Tony Lindgren wrote:
@@ -637,7 +632,7 @@ MACHINE_START(CM_T35, Compulab CM-T35)
.boot_params= 0x8100,
.reserve= omap_reserve,
.map_io = omap3_map_io,
- .init_early =
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Wednesday, August 24, 2011 6:56 PM
To: Hiremath, Vaibhav
Cc: Ravi, Deepthy; mche...@infradead.org; linux-me...@vger.kernel.org;
linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org
From: Keshava Munegowda keshava_mgo...@ti.com
The Hwmod structures and Runtime PM features are implemented
For EHCI and OHCI drivers of OMAP3 and OMAP4.
The global suspend/resume of EHCI and OHCI
is validated on OMAP3430 sdp board with these patches.
these patches are rebased to kevin's pm
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs core driver does not enable/disable the interface and
functional clocks; These clocks are handled by hwmod and runtime pm,
hence instead of the clock enable/disable, the runtime pm APIS are
used. however,the port clocks are handled by the
From: Keshava Munegowda keshava_mgo...@ti.com
device name usbhs clocks are changed from
usbhs-omap.0 to usbhs_omap; this is because
in the hwmod registration the device name is set
as usbhs_omap; The redudant clock nodes are removed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
Following 4 hwmod structure are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
The patch series for the on die temperature sensor driver.
The patch set has the device file, omap4 on die temperature sensor
hwmon driver. hwmod, clk support. The patch set compiles
on top of LO tree Master branch.
This patch series is tested for boot-up on OMAP4460. The temperature
reading and
div_ts_ck feeds only the temperature sensor functional clock
and also has a clksel associated (for divider selection). Mapping this
as the functional clock for the temperature sensor in clkdev table,
so a clk_set_rate() in the driver would have the effect of changing the
temperature sensor clock
OMAP4460 specific temperature sensor register bit fields are added.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
.../include/mach/ctrl_module_core_44xx.h | 70
1 files changed, 57 insertions(+), 13 deletions(-)
diff --git
From: Benoit Cousson b-cous...@ti.com
OMAP4460 temperature sensor hwmod cannot be auto generated
since it is part of ctrl module. Hence populating the
necessary hwmod info manually.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
Cc:
The device file adds the device support for OMAP4
on die temperature sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/temp_sensor_device.c | 188 ++
The hwmod structure of uhh, ohci, ehci and tll are
retrieved and registered with omap device
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 114 +--
1 files changed, 50 insertions(+), 64 deletions(-)
diff --git
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit
From: Benoit Cousson b-cous...@ti.com
Following 4 hwmod structures are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit
On chip temperature sensor driver. The driver monitors the temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user space if
the temperature crosses user defined thresholds via kobject_uevent interface.
The user is allowed to configure the temperature thresholds vis sysfs
Hi,
TPS65950 GPIO2 is to choose through u131 if we drive the lines to the
evm mother board or to the expansion connector p18. Should not it be
default to the mother board?
It's not enabled by default and that’s why we need to enable it through
Tps65950 GPIO2.
Your patch looks fine but the
Shubhrajyoti shubhrajy...@ti.com writes:
On Sunday 17 July 2011 06:13 PM, Shubhrajyoti D wrote:
Restore of context is not done for OMAP4. This patch
adds the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE in the OMAP4
hwmod data which activates the restore for OMAP4.
Currently the OMAP4 does not hit
On Wed, Aug 24, 2011 at 4:15 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
Yes, it should be safe in your context. But the iommu-api is generic and
I would prefer that all functions it provides can be called from any
context.
Not a problem.
I thought you only cared about map/unmap, but if you
Hi,
For the comment what about:
Set the VAUX2 regulator supply to 1.8V for the HSUSB host interface.
Tps65950 GPIO2 has to be set to zero in order to enable the EHCI select
line.
Looks fine.
I see this patch as a fix for the EHCI support, what would you suggest
for the patch name?
This
Set the VAUX2 regulator supply to 1.8V for the HSUSB host interface.
Tps65950 GPIO2 has to be set to zero in order to enable the EHCI select line.
Signed-off-by: Bryan DE FARIA bdefa...@adeneo-embedded.com
---
arch/arm/mach-omap2/board-omap3evm.c | 25 +
1 files
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, August 11, 2011 4:01 PM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; Hilman, Kevin; p...@pwsan.com; linux-arm-
ker...@lists.infradead.org; Mohammed, Afzal; Hiremath, Vaibhav
Subject: [RFC: PATCH 4/4] AM335X: Add low
1. Migrate OMAP's iommu driver to the generic IOMMU API, and move it
to the dedicated iommu folder.
2. Fix omap3isp appropriately so it doesn't break.
3. Adapt OMAP's iovmm appropriately as well, because omap3isp still relies
on it. The plan is eventually to remove iovmm and replace it with the
Move OMAP's iommu drivers to the dedicated iommu drivers folder.
While OMAP's iovmm (virtual memory manager) driver does not strictly
belong to the iommu drivers folder, move it there as well, because
it's by no means OMAP-specific (in concept. technically it is still
coupled with OMAP's iommu).
Migrate OMAP's iommu driver to the generic IOMMU API, so users can stay
generic, and any generic IOMMU functionality can be developed once
in the generic framework.
Migrate omap's iovmm (virtual memory manager) to the generic IOMMU API,
and adapt omap3isp as needed, so the latter won't break.
Use PREFETCH_IOTLB to control the content of the called function,
instead of inlining it in the code.
This improves readability of the code, and also prevents an unused
function warning to show up when PREFETCH_IOTLB isn't set.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Acked-by: Hiroshi DOYU
Remove unused functionality from OMAP's iovmm module.
The intention is to eventually completely replace iovmm with the
generic DMA-API, so new code that'd need this iovmm functionality
will have to extend the DMA-API instead.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Acked-by: Hiroshi DOYU
Remove unused public APIs from OMAP's iommu driver.
IOMMU functionality should be exposed only via the generic IOMMU API;
this way drivers stay generic, and different IOMMU drivers
don't need to duplicate similar functionalities.
The rest of the API still exposed by OMAP's iommu will be
Prepend 'omap_' to OMAP's 'struct iommu' and exposed API, to prevent
namespace pollution and generally to improve readability of the code
that still uses the driver directly.
Update the users as needed as well.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Acked-by: Laurent Pinchart
On Wed, Aug 24, 2011 at 10:37:12AM -0400, Keerthy wrote:
On chip temperature sensor driver. The driver monitors the temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user space if
the temperature crosses user defined thresholds via kobject_uevent interface.
The user
On Wed, Aug 24, 2011 at 10:06 PM, Janakiram Sistla
janakiram.sis...@gmail.com wrote:
Hi Keerthy,
Can you please point me the TRM of 4430 or 4460 where it reads the on die
temperature sensor used is TMP103. I am referring to public TRM on TI site.
Sorry my bad! I shall remove that.
Regards,
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, August 11, 2011 4:00 PM
To: linux-omap@vger.kernel.org
Cc: t...@atomide.com; Hilman, Kevin; p...@pwsan.com; linux-arm-
ker...@lists.infradead.org; Mohammed, Afzal; Hiremath, Vaibhav
Subject: [RFC: PATCH 1/4] AM335X: Update
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
[...]
I think it's much easier to change the existing users of _byname over
to fixed indexes than to come up with a new scheme
As part of an effort to get single ARM kernel binary [1],
multiple definitions of NR_IRQS under various platforms
have to be reconciled and abstracted away from common code.
This patch series takes the small step of populating the
machine descriptors with the pre-existing nr_irqs field.
Machine descriptors in board files should have valid
nr_irqs value so that irq handler code can probe it.
Signed-off-by: Venkatraman S svenk...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c|1 +
arch/arm/mach-omap2/board-3430sdp.c|1 +
arch/arm/mach-omap2/board-3630sdp.c
Machine descriptors in board files should have valid
nr_irqs value so that irq handler code can probe it.
Signed-off-by: Venkatraman S svenk...@ti.com
---
arch/arm/mach-omap1/board-ams-delta.c |1 +
arch/arm/mach-omap1/board-fsample.c |1 +
arch/arm/mach-omap1/board-generic.c |1
Ben Dooks ben-...@fluff.org writes:
On Tue, Aug 23, 2011 at 05:07:56PM -0700, Kevin Hilman wrote:
Hi Ben,
Initially, these fixes were planned to be queued for v3.1-rc, but since
the previous series from Andy didn't make it into v3.1, it should be
queued for v3.2.
This branch is based on
Hi,
On Wed, Aug 24, 2011 at 12:15:03PM -0700, Kevin Hilman wrote:
Grant Likely grant.lik...@secretlab.ca writes:
On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit b-cous...@ti.com wrote:
On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
[...]
I think it's much easier to change the
Santosh santosh.shilim...@ti.com writes:
On Tuesday 23 August 2011 10:36 PM, Kevin Hilman wrote:
Hi Santosh,
Santoshsantosh.shilim...@ti.com writes:
Rafael, Kevin,
On latest kernel( V3.1-rc1+), the subsystem(driver) suspend
callbacks are not getting called because power domain callbcaks
While this fix could go via the OMAP tree, since the original patch
causing the problem went via Rafael's tree (due to dependencies) I'm
submitting the fix to go via Rafael's tree as well.
Applies on v3.1-rc3.
Kevin Hilman (1):
OMAP: omap_device: only override _noirq methods, not normal
commit c03f007a8bf0e092caeb6856a5c8a850df10b974 (OMAP: PM:
omap_device: add system PM methods for PM domain handling) mistakenly
used SET_SYSTEM_SLEEP_PM_OPS() when trying to configure custom methods
for the PM domains noirq methods. Fix that by setting only the
suspend_noirq and resume_noirq
On Thu, Aug 25, 2011 at 1:22 AM, Janakiram Sistla
janakiram.sis...@gmail.com wrote:
On Wed, Aug 24, 2011 at 1:18 PM, J, KEERTHY j-keer...@ti.com wrote:
On Wed, Aug 24, 2011 at 10:06 PM, Janakiram Sistla
janakiram.sis...@gmail.com wrote:
Hi Keerthy,
Can you please point me the TRM of
Hi,
[...]
arch/arm/mach-omap2/board-omap3evm.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index c452b3f..13a2b71 100644
---
Hello,
While checking with memory hole configuration on OMAP3/TI816X (passing mem=x@y),
I see that the whole range from memory start till last bank including the hole
is labelled as 'lowmem' when kernel prints Virtual kernel memory layout during
boot.
E.g., on OMAP3 with mem=32M@0x8000
92 matches
Mail list logo
