Hello,
-Original Message-
From: Sripathy, Vishwanath
Sent: Thursday, July 08, 2010 7:14 PM
To: Kalliguddi, Hema; linux-...@vger.kernel.org;
linux-omap@vger.kernel.org
Cc: Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Kevin Hilman
Subject: RE: [PATCH] usb: musb: Offmode fix for
While doing powercycles with an OMAP3 board I got several strange
effects on my board.
So even when mounting the root-partiton as read only ( ... noinitrd
root=/dev/mtdblock6 ro rootfstype=jffs2 ... ) I 've got sometimes (1
in a 100 trials) a bunch of message while mounting:
TDO35S samples the data on the falling adge of the pixel clock,
therefore the data strobe should be on the raising edge.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
.../video/omap2/displays/panel-toppoly-tdo35s.c|8 ++--
1
CM-T35 DVI transmitter sampling the data on the raising edge of the
pixel clock, therefore the data strobe should happen on the falling
edge.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c |2 ++
1
On Fri, 2010-07-09 at 16:20 +0300, Artem Bityutskiy wrote:
From: Artem Bityutskiy artem.bityuts...@nokia.com
Do not forget to check the 'platform_device_add_data()' error code
in 'omap_device_build_ss()'.
Signed-off-by: Artem Bityutskiy artem.bityuts...@nokia.com
Please, discard this
Hello Thara,
On Fri, 2 Jul 2010 15:48:25 +0530
Thara Gopinath th...@ti.com wrote:
#include plat/common.h
@@ -38,21 +39,45 @@
*/
struct omap_opp_def {
char *hwmod_name;
+ char *vdd_name;
unsigned long freq;
unsigned long u_volt;
+ int
Hello,
2010/7/8 Artem Bityutskiy dedeki...@gmail.com:
On Thu, 2010-07-08 at 12:11 +0200, Enric Balletbò i Serra wrote:
Hello,
2010/7/8 Artem Bityutskiy dedeki...@gmail.com:
On Thu, 2010-07-08 at 11:55 +0200, Enric Balletbò i Serra wrote:
Hello,
I made new tests regarding this issue.
Hi Linus,
On Wed, Jun 30, 2010 at 12:40:43PM +0200, Uwe Kleine-König wrote:
I think my mail hit your inbox during your vacation. As this is quite
important for the ARM people and there isn't much time left, can you
please comment?
As you havn't replied up to now I wonder if that just means
On Mon, 12 Jul 2010, Thomas Petazzoni wrote:
I know this structure already exists, but do we really need a new
structure for this ? Couldn't these infos (OPP list, set/get rate
methods) be stored in an existing device-specific structure (omap_hwmod
for hardware-related things are omap_device
Hello,
When I disconnect an USB pendrive using twl4030 otg as host (step 2)
the usb_disconnect function is not called. OTOH if I reconnect the
device (step 3), then the usb_disconnect function is called.
Does anyone have any ideas why usb_disconnect is not called when the
device is removed?
On Mon, 12 Jul 2010, Artem Bityutskiy wrote:
From: Artem Bityutskiy artem.bityuts...@nokia.com
Do not forget to check the 'platform_device_add_data()' error code
in 'omap_device_build_ss()'.
Looks fine to me, platform_device_add_data() can return -ENOMEM in the
unlikely event that its
Tony,
by the way,
On Mon, 12 Jul 2010, Paul Walmsley wrote:
On Mon, 12 Jul 2010, Artem Bityutskiy wrote:
From: Artem Bityutskiy artem.bityuts...@nokia.com
Do not forget to check the 'platform_device_add_data()' error code
in 'omap_device_build_ss()'.
Looks fine to me,
2010/7/12 Uwe Kleine-König u.kleine-koe...@pengutronix.de:
As you havn't replied up to now I wonder if that just means that you
still plan to remove all defconfig files or if you are just busy doing
other things.
The reason I haven't replied is that
(a) I don't think this really solves the
On Mon, Jul 12, 2010 at 09:51:47AM -0700, Linus Torvalds wrote:
So if the ARM people decide that your script is a good way to clean up
the mess, I might be happy with that. But that would require that they
NEVER EVER try to push me a update that contains an un-cleaned-up
defconfig file.
Does
On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
When you brought up the problem you seemed absolutely convinced
that nothing except your solution was going to be acceptable.
That's not true. What's true is that you didn't seem to _understand_
my
Hello Linus,
On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
When you brought up the problem you seemed absolutely convinced
that nothing except your solution was going to be
2010/7/12 Uwe Kleine-König u.kleine-koe...@pengutronix.de:
I'm willing to try my solution, some others on the linux-arm-kernel
lists considered it worth trying, too. Feel free to pull my tree[1].
Russell refused to take defconfig changes for a while now, so I don't
expect merge problems if
On Mon, 12 Jul 2010, Uwe Kleine-König wrote:
On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
I hope you at least do agree that the current situation is a steaming
pile of sh*t. And yes, I _will_ remove the crap, both from POWER and
ARM, unless I see some serious tries at
On Mon, 12 Jul 2010, Linus Torvalds wrote:
I'd happily pull it. Just this single line in your email is a very
very powerful thing:
177 files changed, 652 insertions(+), 194157 deletions(-)
However, before I would pull, I'd definitely like to make sure we at
least have some way forward
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote:
Put another way: I realize that fairly late in the -rc series is
actually a really good time to do this, rather than during the merge
window itself when things are in flux. However, while it would be a
good time to
On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote:
I think Uwe could provide his script and add it to the kernel tree.
Then all architectures could benefit from it. Having the defconfig
Hi Linus,
On Mon, Jul 12, 2010 at 12:34:59PM -0700, Linus Torvalds wrote:
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote:
Put another way: I realize that fairly late in the -rc series is
actually a really good time to do this, rather than during the merge
On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
When you brought up the problem you seemed absolutely convinced
that nothing except your solution was going to be acceptable.
That's
On Mon, 12 Jul 2010, Linus Torvalds wrote:
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre n...@fluxnic.net wrote:
Put another way: I realize that fairly late in the -rc series is
actually a really good time to do this, rather than during the merge
window itself when things are in
On Sat, 10 Jul 2010, Anand Gadiyar wrote:
USBTLL Save-and-Restore is broken in 3630 ES1.0. Having it
enabled could result in incorrect register restores as
the OMAP exits off-mode. This could potentially result in
unexpected wakeup events.
This is fixed in ES1.1. So disable it for ES1.0s.
On Fri, 9 Jul 2010, Thomas Weber wrote:
Add a missing break at end of switch statement. At the moment it is a
fall through to WARN_ON(1) and return -EEXIST.
Signed-off-by: Thomas Weber we...@corscience.de
Thanks Thomas.
Tony, this is
Acked-by: Paul Walmsley p...@pwsan.com
if you want it
On Monday 12 July 2010 20:50:29 Uwe Kleine-König wrote:
[1] The following changes since commit
67a3e12b05e055c0415c556a315a3d3eb637e29e:
Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/ukl/linux-2.6.git
On Mon, 12 Jul 2010, Arnd Bergmann wrote:
On Monday 12 July 2010 20:50:29 Uwe Kleine-König wrote:
[1] The following changes since commit
67a3e12b05e055c0415c556a315a3d3eb637e29e:
Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
are available in the git repository at:
On Mon, Jul 12, 2010 at 1:29 PM, Nicolas Pitre n...@fluxnic.net wrote:
For the record, I do support Uwe's work too. I do wish it could go in
now so that from that point going forward we could only focus on
improving the thing instead of having to care about implications during
the merge
bool has standard true and false, we dont need to introduce
our own TRUE and FALSE macros.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c |6 +++---
.../staging/tidspbridge/dynload/dload_internal.h |3 ---
Remove custom globaltypes.h header
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/hw/GlobalTypes.h | 289 --
drivers/staging/tidspbridge/hw/MMURegAcM.h |1 -
drivers/staging/tidspbridge/hw/hw_defs.h |2 -
OPTIONAL modifier makes no sense in linux kernel
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/chnl_sm.c |2 +-
.../staging/tidspbridge/include/dspbridge/cod.h|2 +-
.../tidspbridge/include/dspbridge/dspchnl.h|4 ++--
RET_OK is 0 and RET_FAIL is a -1, replace these custom returns with
a standard errno
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 10 ++---
drivers/staging/tidspbridge/hw/hw_mmu.c | 53 +
2 files changed, 31
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/chnl_sm.c |4 ++--
drivers/staging/tidspbridge/core/io_sm.c |2 +-
drivers/staging/tidspbridge/core/msg_sm.c |2 +-
drivers/staging/tidspbridge/core/tiomap3430.c |2 +-
Commit:
staging: tidspbridge: gen: simplify and clean up
There is recently added hex_to_bin() kernel's method which we could use
instead of custom long function.
Introduced usage of hex_to_bin without defining the temp variable.
this causes the build error:
Series targetted to remove std.h, GlobalTypes.h and dbdefs.h. These
introduce custom types and macros which dont make sense for linux kernel
Nishanth Menon (11):
staging: tidspbridge: remove custom TRUE FALSE
staging: tidspbridge: no need for custom NULL
staging: tidspbridge: remove std.h
use readl, writel to get and set the register instead.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/core/tiomap3430.c | 18 +--
drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 126 ++---
drivers/staging/tidspbridge/core/tiomap_io.c |
Remove yet another custom definition header
Signed-off-by: Nishanth Menon n...@ti.com
---
.../staging/tidspbridge/include/dspbridge/dbdefs.h |1 -
.../staging/tidspbridge/include/dspbridge/dbtype.h | 69
.../tidspbridge/include/dspbridge/host_os.h|1 -
3
kernel has it's own NULL define, we dont need to introduce our own
custom NULL type!
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/staging/tidspbridge/dynload/header.h |4
drivers/staging/tidspbridge/hw/GlobalTypes.h |9 -
std.h introduces _TI_ _FLOAT_ _FIXED_ _TARGET_ ARG_TO_INT ARG_TO_PTR
which are no longer being used anywhere. we dont really need the
custom std.h header. remove it from the repo. where we need types,
introduce standard types.h
Signed-off-by: Nishanth Menon n...@ti.com
---
On Monday 12 July 2010 11:50:29 Uwe Kleine-König wrote:
If it helps the powerpc people I can reduce their defconfigs, too.
Do you have scripts or tools that you did this with, or is a manual
process. We're about to add several new (ARM) targets, and it'd be
nice to be able to make small
Menon, Nishanth had written, on 07/12/2010 05:56 PM, the following:
Commit:
staging: tidspbridge: gen: simplify and clean up
There is recently added hex_to_bin() kernel's method which we could use
instead of custom long function.
Introduced usage of hex_to_bin without defining the temp
2010/7/12 David Brown dav...@codeaurora.org:
Do you have scripts or tools that you did this with, or is a manual
process. We're about to add several new (ARM) targets, and it'd be
nice to be able to make small defconfigs for those targets as well.
Uwe posted it earlier in this thread as an
On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:
2010/7/12 David Brown dav...@codeaurora.org:
Do you have scripts or tools that you did this with, or is a manual
process. We're about to add several new (ARM) targets, and it'd be
nice to be able to make small defconfigs for those
On Mon, 12 Jul 2010, David Brown wrote:
On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:
2010/7/12 David Brown dav...@codeaurora.org:
Do you have scripts or tools that you did this with, or is a manual
process. We're about to add several new (ARM) targets, and it'd be
nice
The following set of patches applies on top of for-next branch. And
is dependent on the following patches
1. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30305.html
v3: Rebase on latest codebase and previous patch(posted).
Configure the FIFO THREASHOLD value different for read and write to keep busy
both
filling and to drain out of FIFO at reading and writing.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 11
This patch enable prefetch-irq mode for NAND.
Signed-off-by: Vimal Singh vimalsi...@ti.com
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/board-flash.c |1 +
arch/arm/mach-omap2/gpmc.c |4 +
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver. And hw ecc layout selected for
sdp and zoom boards, by default.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-laod, u-boot and kernel.
This patch also enables to use romcode ecc for spd and zoom, by default.
Joerg Roedel wrote:
On Fri, Jul 02, 2010 at 12:09:02AM -0700, Zach Pfeffer wrote:
Hari Kanigeri wrote:
He demonstrated the usage of his code in one of the emails he sent out
initially. Did you go over that, and what (or how many) step would you
use with the current code to do the same thing?
Joerg Roedel wrote:
On Thu, Jul 01, 2010 at 03:00:17PM -0700, Zach Pfeffer wrote:
Additionally, the current IOMMU interface does not allow users to
associate one page table with multiple IOMMUs [...]
Thats not true. Multiple IOMMUs are completly handled by the IOMMU
drivers. In the case of
Joerg Roedel wrote:
On Fri, Jul 02, 2010 at 12:33:51AM -0700, Zach Pfeffer wrote:
Daniel Walker wrote:
So if we include this code which map implementations could you
collapse into this implementations ? Generally , what currently existing
code can VCMM help to eliminate?
In theory, it can
This patch series does some clean up of the opp layer
including removal of compilation warnings, avoiding wrong inclusioin
of header files, correcting some srror checks and removing the dependency
of opp layer on cpu freq layer.
Apart from all these there is still one more concern i have in this
Earlier we were checking on !dev_opp where as find_device_opp returns
a error pointer in case of error. So correcting the check as in the earlier
code even if find_device_opp returns an error opp_init_cpufreq_table
was not exiting.
Signed-off-by: Thara Gopinath th...@ti.com
---
This patch removes the dependency of the opp layer on cpufreq layer.
OPP layer is now enabled to compile and exist in the system
irrespective of whether cpu freq layer is enabled or not.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/Makefile |4 ++--
This patch removes the inclusion of plat/opp_twl_tps.h in opp.c.
This header file is included unnecessarily and creats unwanted
dependency between the generic opp layer and TWL4030/5030 PMIC
dependent code.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/opp.c |1 -
1 files
Fix the following warning from the opp layer during
compilation.
arch/arm/plat-omap/opp.c: In function 'opp_enable':
arch/arm/plat-omap/opp.c:405: warning: unused variable 'dev_opp'
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/plat-omap/opp.c |2 --
1 files changed, 0
Joerg Roedel wrote:
On Thu, Jul 01, 2010 at 11:17:34PM -0700, Zach Pfeffer wrote:
Andi Kleen wrote:
Hmm? dma_map_* does not change any CPU mappings. It only sets up
DMA mapping(s).
Sure, but I was saying that iommu_map() doesn't just set up the IOMMU
mappings, its sets up both the iommu
FUJITA Tomonori wrote:
On Thu, 08 Jul 2010 16:59:52 -0700
Zach Pfeffer zpfef...@codeaurora.org wrote:
The problem I'm trying to solve boils down to this: map a set of
contiguous physical buffers to an aligned IOMMU address. I need to
allocate the set of physical buffers in a particular way:
60 matches
Mail list logo
