On Friday 15 March 2013 10:30 AM, Will Deacon wrote:
On Thu, Mar 14, 2013 at 01:08:00PM +0530, Santosh Shilimkar wrote:
Will,
Hi guys,
I'm out of the office at the moment and have really terrible connectivity,
so I can't do too much until next week. However, I don't think adding the
On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130315 05:31]:
On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130314 05:44]:
OMAP clock inits happen quite early, even before the slab is available.
As part of the
of_get_hsmmc_pdata() may return NULL, thus ensure pdata is not NULL
before dereference it.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
Hi Tony,
I have rebased the branch on 3.9-rc3 tag.
Is it still possible to send this for 3.9?
Regards,
Péter
---
The following changes since commit a937536b868b8369b98967929045f1df54234323:
Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
are available in the git repository at:
Hi Anil,
On 03/17/2013 10:35 AM, Anil Kumar wrote:
Hi Benoit,
On Fri, Mar 15, 2013 at 8:00 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Jon,
On 03/15/2013 02:57 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP
The first patch is a rearrangement of a macro OMAP_MAX_HSUART_PORTS
to a header file so that it can be used in other file.
The second patch fixes the wakeup from uart issue while using
no_console_suspend in the
bootargs.
These patches are developed on 3.8 custom kernel containing omap5
OMAP_MAX_HSUART_PORTS is moved to omap_serial header file.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Rajendra nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/tty/serial/omap-serial.c |2 --
With dt boot on omap5, uart wakeup after suspend is non functional while using
no_console_suspend in the bootargs. With no_console_suspend used, od-flags
should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not allowing the
console
to idle in the suspend path. For non-dt case, this was
On 03/15/2013 06:12 PM, Tony Lindgren wrote:
Hi,
I think you can get rid of quite a bit more of the repeated data for
most boards, see below.
* Roger Quadros rog...@ti.com [130315 08:21]:
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 32 +-
1 files changed, 22 insertions(+), 10 deletions(-)
diff --git
This helper allows board support code to add the PHY's
VCC and RESET regulators which are GPIO controlled as well
as the NOP PHY device.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 177 +++-
arch/arm/mach-omap2/usb.h |
Hi Tony,
I've revised the patches based on your comments. For now I've just
adapted Panda and Beagleboard.
If this looks OK then I can adapt the other boards as well.
cheers,
-roger
Roger Quadros (4):
usb: phy: nop: Add some parameters to platform data
ARM: OMAP2+: omap-usb-host: Add
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators and the NOP PHY device.
Get rid of managing the PHY clock as it will be done by the PHY driver.
For that to work we create a clock alias that links the PHY clock name
to the PHY device name.
Signed-off-by: Roger Quadros
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will bail out with -EPROBE_DEFER.
Signed-off-by: Roger
Hi,
On Monday 18 March 2013 04:24 PM, Sourav Poddar wrote:
The first patch is a rearrangement of a macro OMAP_MAX_HSUART_PORTS
to a header file so that it can be used in other file.
The second patch fixes the wakeup from uart issue while using
no_console_suspend in the
bootargs.
These patches
With dt boot, uart wakeup after suspend is non functional on omap4/5 while using
no_console_suspend in the bootargs. With no_console_suspend used, od-flags
should be ORed with OMAP_DEVICE_NO_IDLE_ON_SUSPEND, thereby not allowing the
console
to idle in the suspend path. For non-dt case, this was
On 03/17/2013 12:24 AM, Ezequiel Garcia wrote:
Hi Jon,
I have some tiny nitpicks...
On Fri, Mar 15, 2013 at 10:21:08AM -0500, Jon Hunter wrote:
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC
On 03/16/2013 03:59 PM, Ezequiel Garcia wrote:
Hi Jon,
On Fri, Mar 15, 2013 at 10:21:00AM -0500, Jon Hunter wrote:
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of
On 03/17/2013 08:57 PM, Paul Walmsley wrote:
Hi Jon,
On Sat, 16 Mar 2013, Paul Walmsley wrote:
Looks like commit 6797b4fe0e554ce71f47038fd929c9ca929a9f3c (ARM: OMAP2+:
Prevent potential crash if GPMC probe fails) causes hangs on boot. I
suspect it may only occur when the root
On 03/15/2013 10:21 AM, Jon Hunter wrote:
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them.
The existing code in gpmc_read_timings_dt() is checking the value of
On 03/18/2013 09:07 AM, Rob Herring wrote:
On 03/15/2013 10:21 AM, Jon Hunter wrote:
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them.
The existing code in
Greg, Dan,
On 16-03-2013 12:16, Greg KH wrote:
On Sat, Mar 16, 2013 at 08:46:03AM -0400, Eduardo Valentin wrote:
Hello Dan,
On 16-03-2013 05:05, Dan Carpenter wrote:
I've reviewed this set.
I hate to make people redo whole patchset sets, and I hate
re-reviewing code. Obviously, I don't
Hi Greg,
I am sending extra patches on omap-thermal driver, under staging.
There are couple of fixes based on Dan Carpenter's review on
the last patch set I sent. On top of these, there are some
changes on the naming convention for this driver. This rename
is based on previous review cycles that
Return the proper error value in _omap_bandgap_read_threshold.
Cc: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index 33bfe3b..cb7aa35 100644
Even if the IRQ is not firing because it is ONE_SHOT and disable
at INTC level, the IRQ handler must use spin_lock_irqsave.
It is necessary to disable IRQs from the current
CPU while it is holding a spin_lock which is need.
Cc: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Eduardo
Use a shorter name to bandgap pointer.
Cc: Benoit b-cous...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c
b/drivers/staging/omap-thermal/omap-bandgap.c
index a4ac06c..89361fe 100644
---
Move _ti_bandgap_write_threshold and _ti_bandgap_read_threshold to static
area, as they are local functions.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index 6a0b1ac..c850e13
This patch changes the data structures of this driver so
that readonly data can reside only in the conf pointer.
Now each register has a struct to hold its configuration info,
to be used base on chip version for instance, and a
struct of values to be written, like register shadow and priv data.
Follow Documentation/CodingStyle and use sizeof(*pointer)
instead of sizeof(struct type).
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
b/drivers/staging/ti-soc-thermal/ti-bandgap.c
index b74e847..4382c0c 100644
---
This patch updates the documentation to remove
all warnings and errors reported by scripts/kernel-doc.
Most are missing arguments due to wrong format.
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
diff --git a/drivers/staging/ti-soc-thermal/ti-bandgap.c
Hi Santosh,
On Mon, Mar 18, 2013 at 06:51:30AM +, Santosh Shilimkar wrote:
On Friday 15 March 2013 10:30 AM, Will Deacon wrote:
Furthermore, I was under the impression that hw_breakpoint did actually
work on panda, which implies that a cold boot *does* manage to reset the
registers
Hi Anil,
On 03/17/2013 06:23 AM, Anil Kumar wrote:
Hi Benoit,
On Thu, Mar 7, 2013 at 12:21 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi,
On 03/06/2013 06:53 PM, Tony Lindgren wrote:
* Anil Kumar anilk...@gmail.com [130305 18:40]:
Hi Tony,
From: linux-arm-kernel
Here are some basic OMAP test results for Linux v3.9-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130314094808/
Test summary
Build:
FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only,
On Monday 18 March 2013 08:37 PM, Will Deacon wrote:
Hi Santosh,
On Mon, Mar 18, 2013 at 06:51:30AM +, Santosh Shilimkar wrote:
On Friday 15 March 2013 10:30 AM, Will Deacon wrote:
Furthermore, I was under the impression that hw_breakpoint did actually
work on panda, which implies that
On 03/18/2013 09:32 AM, Jon Hunter wrote:
On 03/18/2013 09:07 AM, Rob Herring wrote:
On 03/15/2013 10:21 AM, Jon Hunter wrote:
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to
You are not planning any resources to solve this ?
You are listing this for a number of months now. It is time to solve them.
On Mon, Mar 18, 2013 at 5:38 PM, Paul Walmsley p...@pwsan.com wrote:
Here are some basic OMAP test results for Linux v3.9-rc3.
Logs and other details at:
On Mon, 18 Mar 2013, Anca Emanuel wrote:
You are not planning any resources to solve this ?
You are listing this for a number of months now. It is time to solve them.
Absolutely, thanks for volunteering! Patches welcome.
- Paul
--
To unsubscribe from this list: send the line unsubscribe
On Fri 2013-02-22 08:00:44, Olof Johansson wrote:
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
Any comments on this approach? Is it better to merge mkfitsrc.sh with
mkuboot.sh?
I know this was discussed quite extensively yesterday, but here is my take on
it:
Given
* Rajendra Nayak rna...@ti.com [130318 01:25]:
On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130315 05:31]:
On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130314 05:44]:
OMAP clock inits happen quite early,
Thanks.
Acked-by: Dan Carpenter dan.carpen...@orcle.com
regards,
dan carpenter
--
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
* Roger Quadros rog...@ti.com [130318 05:55]:
Hi Tony,
I've revised the patches based on your comments. For now I've just
adapted Panda and Beagleboard.
If this looks OK then I can adapt the other boards as well.
Thanks yes looks good to me now.
Regards,
Tony
--
To unsubscribe from this
On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote:
On Fri 2013-02-22 08:00:44, Olof Johansson wrote:
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
Any comments on this approach? Is it better to merge mkfitsrc.sh with
mkuboot.sh?
I know this was
On Mon, Mar 18, 2013 at 03:46:28PM +, Santosh Shilimkar wrote:
On Monday 18 March 2013 08:37 PM, Will Deacon wrote:
That really sucks :( Does this affect all OMAP-based boards?
All OMAP4 based boards..
Brilliant. Is there any way that the secure code can be fixed in future
products?
On Mon, 18 Mar 2013, Paul Walmsley wrote:
On Mon, 18 Mar 2013, Anca Emanuel wrote:
You are not planning any resources to solve this ?
You are listing this for a number of months now. It is time to solve them.
Absolutely, thanks for volunteering! Patches welcome.
Also, if you are a TI
Dan,
On 18-03-2013 12:39, Dan Carpenter wrote:
Thanks.
Acked-by: Dan Carpenter dan.carpen...@orcle.com
regards,
dan carpenter
Thanks for taking the time to check this code.
Eduardo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
On Mon 2013-03-18 16:44:26, Russell King - ARM Linux wrote:
On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote:
On Fri 2013-02-22 08:00:44, Olof Johansson wrote:
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
Any comments on this approach? Is it better to
On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote:
What I wanted to say is that kernel build traditionaly produced
something useful, something bootloader can actually boot. Currently,
make uImage produces u-boot image. Please keep that capability.
Unfortunately, there is a
On Mon 2013-03-18 17:57:46, Russell King - ARM Linux wrote:
On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote:
What I wanted to say is that kernel build traditionaly produced
something useful, something bootloader can actually boot. Currently,
make uImage produces u-boot image.
On 03/18/2013 12:04 PM, Pavel Machek wrote:
On Mon 2013-03-18 17:57:46, Russell King - ARM Linux wrote:
On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote:
What I wanted to say is that kernel build traditionaly produced
something useful, something bootloader can actually boot.
On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote:
On Fri 2013-02-22 08:00:44, Olof Johansson wrote:
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote:
Any comments on this approach? Is it better to merge mkfitsrc.sh with
mkuboot.sh?
I know this was
Sourav Poddar sourav.pod...@ti.com writes:
OMAP_MAX_HSUART_PORTS is moved to omap_serial header file.
Why?
You started to explain it in the cover letter, but a full description
belongs here for the permanent git history.
Kevin
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Felipe
On Mon, Mar 18, 2013 at 10:59:10AM -0400, Eduardo Valentin wrote:
Even if the IRQ is not firing because it is ONE_SHOT and disable
at INTC level, the IRQ handler must use spin_lock_irqsave.
It is necessary to disable IRQs from the current
CPU while it is holding a spin_lock which is need.
On Mon, Mar 18, 2013 at 10:59:12AM -0400, Eduardo Valentin wrote:
Because this driver will support also OMAP derivatives,
this patch does a big rename inside this driver, so it
better fits its usage.
It would be better to do a minimal move patch which just renames the
files and updated the
On 18-03-2013 15:16, Dan Carpenter wrote:
On Mon, Mar 18, 2013 at 10:59:10AM -0400, Eduardo Valentin wrote:
Even if the IRQ is not firing because it is ONE_SHOT and disable
at INTC level, the IRQ handler must use spin_lock_irqsave.
It is necessary to disable IRQs from the current
CPU while it
Dear Russell,
In message 20130318175746.gj30...@n2100.arm.linux.org.uk you wrote:
Unfortunately, there is a fundamental problem with uImage. It encodes
the load address, and that is utterly incompatible with the goal of
having a kernel image which boots on multiple platforms.
I'm not sure
Dear Stephen,
In message 51475997.2060...@wwwdotorg.org you wrote:
Raw zImage /is/ the useful format that should be adopted.
This one size fits all approch does fit everywhere. There are a
number of users (including _big_ commercial ones, with _large_ numebrs
of systems in the field) that
On Mon, Mar 18, 2013 at 03:38:38PM -0400, Eduardo Valentin wrote:
On 18-03-2013 15:16, Dan Carpenter wrote:
On Mon, Mar 18, 2013 at 10:59:10AM -0400, Eduardo Valentin wrote:
Even if the IRQ is not firing because it is ONE_SHOT and disable
at INTC level, the IRQ handler must use
On Thu, Mar 14, 2013 at 03:07:01PM +0530, Santosh Shilimkar wrote:
(Looping Greg KH.)
Greg,
On Wednesday 20 February 2013 09:14 PM, Santosh Shilimkar wrote:
On Wednesday 20 February 2013 08:54 PM, Kevin Hilman wrote:
Santosh Shilimkar santosh.shilim...@ti.com writes:
UART IP slave
Quoting Tony Lindgren (2013-03-18 09:37:58)
* Rajendra Nayak rna...@ti.com [130318 01:25]:
On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130315 05:31]:
On Thursday 14 March 2013 10:36 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com
On Tuesday 19 March 2013 06:53 AM, Mike Turquette wrote:
Quoting Tony Lindgren (2013-03-18 09:37:58)
* Rajendra Nayak rna...@ti.com [130318 01:25]:
On Friday 15 March 2013 09:50 PM, Tony Lindgren wrote:
* Rajendra Nayak rna...@ti.com [130315 05:31]:
On Thursday 14 March 2013 10:36 PM, Tony
Hi,
restating these to reflect some bugfixes in the test log parsing scripts.
On Thu, 14 Mar 2013, Paul Walmsley wrote:
vmlinux object size
(delta in bytes from test_v3.9-rc1
(6dbe51c251a327e012439c4772097a13df43c5b8)):
text data bsstotal kernel
+13528 +640
Hi,
here's the restated delta from v3.8 - v3.9-rc1, after some script bug
fixes.
On Tue, 12 Mar 2013, Paul Walmsley wrote:
vmlinux object size
(delta in bytes from test_v3.8 (19f949f52599ba7c3f67a5897ac6be14bfcb1200)):
text data bsstotal kernel
+195310 +37968+1364
62 matches
Mail list logo
