Pending July patches

Pending July patches

[Dirk Behme]

Hi,

my list of pending OMAP patches from July. Maybe its useful 
for someone.

Start:                07/01/2006
Last updated: 07/31/2006

1. [PATCH] fix PWL macro names
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007503.html

2. [PATCH] ARM: OMAP: Fix missing channel using 
omap_set_dma_priority()
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007508.html

Note: Needs check if channel 0 is really okay for OMAP24xx.

3. ARM: OMAP: omapfb: Fix 444 mode after recent LCD changes
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007525.html

4. [PATCH] ARM: OMAP: omapfb: Add Amstrad Delta LCD driver
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007526.html

5. 2420 boot BUG(): failure to map SRAM
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007578.html

6.[PATCH] ARM: OMAP: mux: add config for 16xx SPI pins
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007596.html

Please add, correct, comment if anything is wrong or 
missing. Are there any older patches pending?

Note that some patches from July were already applied to git 
by Imre (especially the omapfb/ads7846 stuff)

Cheers

Dirk

Re: Pending July patches

[Tony Lindgren]

* Dirk Behme <dirk.behme@googlemail.com> [060801 19:45]:
> Hi,
> 
> my list of pending OMAP patches from July. Maybe its useful 
> for someone.

Cool, thanks. I'll start digging through these patches, and then
tag 2.6.17-omap2 before we pull from Linus' tree.

Tony

Re: Pending July patches

[Komal Shah]

--- Tony Lindgren <tony@atomide.com> wrote:

> 
> Cool, thanks. I'll start digging through these patches, and then
> tag 2.6.17-omap2 before we pull from Linus' tree.
> 

Also, my patches on using gpmc_* apis for board_h4.c was not on the
list of upstream patches for 2.6.18 window. So, please consider them
for 2.6.19 :)

---Komal Shah
http://komalshah.blogspot.com/

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Tony Lindgren]

* Komal Shah <komal_shah802003@yahoo.com> [060803 15:09]:
> --- Tony Lindgren <tony@atomide.com> wrote:
> 
> > 
> > Cool, thanks. I'll start digging through these patches, and then
> > tag 2.6.17-omap2 before we pull from Linus' tree.
> > 
> 
> Also, my patches on using gpmc_* apis for board_h4.c was not on the
> list of upstream patches for 2.6.18 window. So, please consider them
> for 2.6.19 :)

In general we want to have everything in sync with the mainline, and be
able to use the mainline tree for omap boards.

The reason I did not send h4 smc91x gpmc yet is that we should update it
to use gpmc_cs_set_timings() to have a nice example available for others :)

Could you try something like the sample code below for h4? You most likely
need to modify the values, but this is how Juha intended the gpmc being used.

static int __init smc91x_set_async_mode(int cs)
{
	struct gpmc_timings t;
	u32 reg;

	memset(&t, 0, sizeof(t));
	t.sync_clk = 0;
	t.cs_on = 0;
	t.adv_on = gpmc_round_ns_to_ticks(1);

	/* Read */
	t.adv_rd_off = t.adv_on + gpmc_round_ns_to_ticks(7);
	t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(1);
	t.access = t.oe_on + gpmc_round_ns_to_ticks(1);
	t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
	t.cs_rd_off = t.oe_off;
	t.rd_cycle = t.cs_rd_off + gpmc_round_ns_to_ticks(1);

	/* Write */
	t.adv_wr_off = t.adv_on + gpmc_round_ns_to_ticks(7);
	t.we_on = t.adv_wr_off + gpmc_round_ns_to_ticks(1);
	t.we_off = t.we_on + gpmc_round_ns_to_ticks(1);
	t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(1);
	t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(1);

	reg =	GPMC_CONFIG1_PAGE_LEN(2) |
		GPMC_CONFIG1_WAIT_READ_MON |
		GPMC_CONFIG1_WAIT_WRITE_MON |
		GPMC_CONFIG1_WAIT_PIN_SEL(2) |
		GPMC_CONFIG1_READTYPE_ASYNC |
		GPMC_CONFIG1_WRITETYPE_ASYNC |
		GPMC_CONFIG1_DEVICESIZE_16 |
		GPMC_CONFIG1_DEVICETYPE_NOR |
		GPMC_CONFIG1_MUXADDDATA;

	gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, reg);

	return gpmc_cs_set_timings(cs, &t);
}

Then just do something like:

ret = smc91x_set_async_mode(SMC91X_CS);
if (ret != 0) {
	printk(KERN_ERR "dklfjdkfjdkfj\n");
	return ret;
}

Also, do you have a patch to improve the 2422 vs 2423 detection? It
would be nice to get rid of this in board-h4.c:

/* FIXME: This function should be moved to some other file, gpmc.c? */

/* H4-2420's always used muxed mode, H4-2422's always use non-muxed
 *
 * Note: OMAP-GIT doesn't correctly do is_cpu_omap2422 and
 * is_cpu_omap2423
 *  correctly.  The macro needs to look at production_id not just
 *  hawkeye.
 */
static u32 is_gpmc_muxed(void)
{
	u32 mux;
	mux = get_sysboot_value();
	if ((mux & 0xF) == 0xd)
		return 1;	/* NAND config (could be either) */
	if (mux & 0x2)		/* if mux'ed */
		return 1;
	else
		return 0;
}

Regards,

Tony

Need help to understand a #pragma statment.

[Taru Varshney]

 

Hi all,
I'm trying to load bootloader on DM320's Flash memory. Flash writer is
working fine. But it's somebody else's code. I'm not able to understand what
the folowing line in the flash Writer code is doing:

#pragma DATA_SECTION (ucBOOT320Code,".bin"). 

Can anybody help me to understand the above line ??

Thanks in Advance,
Taru
  

RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Woodruff, Richard]

Hello Tony,

> The reason I did not send h4 smc91x gpmc yet is that we should update
it
> to use gpmc_cs_set_timings() to have a nice example available for
> others :)

So your reasoning for not including was you want something perfect to
start with?  That bar seems a bit high especially when what is there is
broken. The below is pretty nice, I don't know that this approach works
for all parts which can be connected given the interface, but it should
work well for many.

In general I certainly favor having something which works, then evolving
it into something nicer.  This can result in cut and past proliferation;
however there are not that many boards.  Once one is done nicely the
others can be manually updated with out huge effort.  Which OMAP1 port
currently uses this style?  If it does at what point did it start doing
this (probably not the first pass)?

As far as 2420 vs. 2420POP vs. 2422 vs. 2423 unfortunately early chips
did not follow a common schema, later ones do, doing things which
captures them all can be messy.  The mechanism in the OMAP1 port was not
constructed to work with the multi-stage check which is now necessary.
This simple example highlights one basic issue.  The current level of
code sharing as the processors diverge can make it harder to add trivial
code with out breaking other ones.  This will slow the tree's adoption
of new chips.  It is hard to say what the sharing balance should be.  If
chips have a long lifetime then code sharing at the low level seems
pretty good, if they only live for a couple of years adding some extra
indirection and maintaining high levels of sharing in the old ones
starts to lose its value.  Production volume vendor time lines and their
compromises does force branching and fragmentation.  Perhaps one tree
can not and should not meet all needs.  Keeping high level interface
compatibly is really good the level of low level can be less.

One measure might be I know of several vendors in production of OMAP2
chips for over a year using less well structured trees.  I don't think
the same can happen from this tree yet.  Now, those less well structured
trees many not have been able to exist with out a good branch off point
which this tree provides...  balance...

Thanks for the good work.
 
> Could you try something like the sample code below for h4? You most
likely
> need to modify the values, but this is how Juha intended the gpmc
being
> used.
> 
> static int __init smc91x_set_async_mode(int cs)
> {
> 	struct gpmc_timings t;
> 	u32 reg;
> 
> 	memset(&t, 0, sizeof(t));
> 	t.sync_clk = 0;
> 	t.cs_on = 0;
> 	t.adv_on = gpmc_round_ns_to_ticks(1);
> 
> 	/* Read */
> 	t.adv_rd_off = t.adv_on + gpmc_round_ns_to_ticks(7);
> 	t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(1);
> 	t.access = t.oe_on + gpmc_round_ns_to_ticks(1);
> 	t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
> 	t.cs_rd_off = t.oe_off;
> 	t.rd_cycle = t.cs_rd_off + gpmc_round_ns_to_ticks(1);
> 
> 	/* Write */
> 	t.adv_wr_off = t.adv_on + gpmc_round_ns_to_ticks(7);
> 	t.we_on = t.adv_wr_off + gpmc_round_ns_to_ticks(1);
> 	t.we_off = t.we_on + gpmc_round_ns_to_ticks(1);
> 	t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(1);
> 	t.wr_cycle = t.cs_wr_off + gpmc_round_ns_to_ticks(1);
> 
> 	reg =	GPMC_CONFIG1_PAGE_LEN(2) |
> 		GPMC_CONFIG1_WAIT_READ_MON |
> 		GPMC_CONFIG1_WAIT_WRITE_MON |
> 		GPMC_CONFIG1_WAIT_PIN_SEL(2) |
> 		GPMC_CONFIG1_READTYPE_ASYNC |
> 		GPMC_CONFIG1_WRITETYPE_ASYNC |
> 		GPMC_CONFIG1_DEVICESIZE_16 |
> 		GPMC_CONFIG1_DEVICETYPE_NOR |
> 		GPMC_CONFIG1_MUXADDDATA;

Regards,
Richard W.

Re: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [060803 17:20]:
> Hello Tony,
> 
> > The reason I did not send h4 smc91x gpmc yet is that we should update
> it
> > to use gpmc_cs_set_timings() to have a nice example available for
> > others :)
> 
> So your reasoning for not including was you want something perfect to
> start with?  That bar seems a bit high especially when what is there is
> broken. The below is pretty nice, I don't know that this approach works
> for all parts which can be connected given the interface, but it should
> work well for many.

Excuse me but Komal's patch is already in the linux-omap tree and usable
with that tree. What we send to the mainline kernel should be the code
we want to live with in the long run.
 
> In general I certainly favor having something which works, then evolving
> it into something nicer.  This can result in cut and past proliferation;
> however there are not that many boards.  Once one is done nicely the
> others can be manually updated with out huge effort.  Which OMAP1 port
> currently uses this style?  If it does at what point did it start doing
> this (probably not the first pass)?

I'm not sure I understand you correctly here. Working code is in linux-omap
tree and once we're happy with it we send it upstream.

Sure if you take a snapshot of the code and hack it for your board for a
year the merge back to the current tree is a big pain. If you want to
merge something then, you need to allocate the resouces to do that.
 
> As far as 2420 vs. 2420POP vs. 2422 vs. 2423 unfortunately early chips
> did not follow a common schema, later ones do, doing things which
> captures them all can be messy.  The mechanism in the OMAP1 port was not
> constructed to work with the multi-stage check which is now necessary.
> This simple example highlights one basic issue.  The current level of
> code sharing as the processors diverge can make it harder to add trivial
> code with out breaking other ones.  This will slow the tree's adoption
> of new chips.  It is hard to say what the sharing balance should be.  If
> chips have a long lifetime then code sharing at the low level seems
> pretty good, if they only live for a couple of years adding some extra
> indirection and maintaining high levels of sharing in the old ones
> starts to lose its value.  Production volume vendor time lines and their
> compromises does force branching and fragmentation.  Perhaps one tree
> can not and should not meet all needs.  Keeping high level interface
> compatibly is really good the level of low level can be less.

Product vendors can certainly do their board specific hacks on the
common code. Who's saying you have to wait for something instead of
doing your own board specific hacks?
 
> One measure might be I know of several vendors in production of OMAP2
> chips for over a year using less well structured trees.  I don't think
> the same can happen from this tree yet.  Now, those less well structured
> trees many not have been able to exist with out a good branch off point
> which this tree provides...  balance...

Sure. Then go use your hacked 2.6.10 tree. If you're in a rush you must
use what's available and hack the available code for your board. However
somebody needs to look after the integration too. Hack and forget
attitude means duplicating the work over and over again. Think about
the MMC drivers Linux has seen for example: Because of lack of
coordination it was written 3 times for omap.
 
> Thanks for the good work.

Whatever. Rather thank Komal for all the good work on merging TI code.

Regards,

Tony

RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Woodruff, Richard]

> Sure if you take a snapshot of the code and hack it for your board for
a
> year the merge back to the current tree is a big pain. If you want to
> merge something then, you need to allocate the resouces to do that.

We did make some effort at that time. Our resource window as defined at
that time wasn't so big.  What we got was, we don't like this, and there
should only be mach-omap directory and not mach-omap2.  Keeping it all
in a shared structure at that time meant a higher bar of entry.  After
more people outside of TI started working on it, it did eventually go to
OMAP2 + Plat.

Practically speaking available time is limited.  Perhaps it needs to be
more but those are not the parameters I set.

> Product vendors can certainly do their board specific hacks on the
> common code. Who's saying you have to wait for something instead of
> doing your own board specific hacks?

No body waits.

Better aligning capabilities windows results in more functionality
getting in.  Having working things evolving would seem to be better for
many interests.

OMAP3 isn't so far off.  One of the side goals of my chip centric point
of view is to look at how OMAP2 went and see if there are any factors
which can make OMAP3 come in easier (aside from the obvious adding
resources).  It is pretty safe to say there will be an OMAP3 directory,
for some reason that wasn't an easy call for OMAP2.  By putting high
coupling between the chips like was started in OMAP2 means things won't
move well.

> > One measure might be I know of several vendors in production of
OMAP2
> > chips for over a year using less well structured trees.  I don't
think
> > the same can happen from this tree yet.  Now, those less well
structured
> > trees many not have been able to exist with out a good branch off
point
> > which this tree provides...  balance...
> 
> Sure. Then go use your hacked 2.6.10 tree. If you're in a rush you
must
> use what's available and hack the available code for your board.
However
> somebody needs to look after the integration too. Hack and forget
> attitude means duplicating the work over and over again. Think about
> the MMC drivers Linux has seen for example: Because of lack of
> coordination it was written 3 times for omap.

Yes, that is true.  And the USB subsystem has been rewritten 3 times
also.  In some sense that is the way of Linux and why it has evolved
faster than others.  Like I lobbied it's a balance.

> > Thanks for the good work.
> 
> Whatever. Rather thank Komal for all the good work on merging TI code.

Generally we try and help where we can in this forum.  I do help Komal
and you and others where I can.  Boards, data clarification, some
code...

I saw a 2430 patch recently which seemed reasonable which hasn't had
many comments.  A little tweak here and there and it boots.  What holds
such things back from being merged?  Many people benefit from it
working.

Regards,
Richard W.

Re: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Juha Yrjölä]

Woodruff, Richard wrote:

> As far as 2420 vs. 2420POP vs. 2422 vs. 2423 unfortunately early chips
> did not follow a common schema, later ones do, doing things which
> captures them all can be messy.  The mechanism in the OMAP1 port was not
> constructed to work with the multi-stage check which is now necessary.
> This simple example highlights one basic issue.  The current level of
> code sharing as the processors diverge can make it harder to add trivial
> code with out breaking other ones.

Harder, sure, as in "requires more competence to do the initial work". 
Any additional time spent on cleaning up the architecture is saved 
several times over when the bug fixing and maintenance period starts, or 
when support for yet new CPUs are added.  And besides, the more we move 
into a more generic direction with the code, the easier it gets to add 
support for new hardware, and bug fixes for generic code will benefit 
all platforms.

The fact is that the community development model simply does not favor 
branching the code.  I'd also argue that having several code bases does 
not suit proprietary software development that well either, but that is 
another matter altogether.

> This will slow the tree's adoption of new chips. It is hard to say
 > what the sharing balance should be. If
> chips have a long lifetime then code sharing at the low level seems 
> pretty good, if they only live for a couple of years adding some
> extra indirection and maintaining high levels of sharing in the old
> ones starts to lose its value.

Lifetime from whose point of view?  There are users who will be using 
products based on current generation CPUs ten years from now.  The Linux 
kernel still supports hardware and CPUs that existed back when the very 
first version of the kernel was released.

> Production volume vendor time lines
> and their compromises does force branching and fragmentation.

Simply not true.  There are numerous examples of both silicon and device 
volume vendors being able to do quality kernel code and in the end being 
able to get the code merged into mainline without compromising schedules.

> Perhaps one tree can not and should not meet all needs. Keeping high level
> interface compatibly is really good the level of low level can be
> less.

Linus' tree does seem to be doing a fairly good job of meeting almost 
everyone's needs.  Branching the code is simply impossible from 
maintenance point of view due to rapid development speed of the kernel. 
  New features that also benefit the embedded people are added every 
month, bugs and vulnerabilities are fixed daily.  Back-porting them to 
older versions will start consuming more and more time until it just 
becomes impossible.

> One measure might be I know of several vendors in production of OMAP2
> chips for over a year using less well structured trees.

Too bad I don't remember seeing any OMAP2 patches from said vendors. 
The end result is that each vendor will have to spend extra resources 
implementing their drivers separately, with each driver having bugs of 
their own.

Cheers,
Juha

Re: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Dirk Behme]

Woodruff, Richard wrote:
> I saw a 2430 patch recently which seemed reasonable which hasn't had
> many comments.  A little tweak here and there and it boots.  What holds
> such things back from being merged?  Many people benefit from it
> working.

I think I recently asked for (older) pending patches (we 
missed) ;) Feel free to add anything to [1] you like.

Regards

Dirk

[1] 
http://linux.omap.com/pipermail/linux-omap-open-source/2006-August/007611.html

RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Woodruff, Richard]

> Lifetime from whose point of view?  There are users who will be using
> products based on current generation CPUs ten years from now.  The Linux
> kernel still supports hardware and CPUs that existed back when the very
> first version of the kernel was released.

Though I've cut away much of your mail I can't say I disagree with many of the points.  And lifetime is from my biased current point of view.  We all work with in some dynamic and recognizing and working with in this allows us to deliver.  Delivery in production is one metric which chip's get measured against.  As long as that is happening things are ok, but that doesn't mean they can't be better.  My biased point of view is that balanced sharing will facilitate functional flow into the tree.  I would ague this is a good thing.

Oh, well, enough fluff for now...

Regards,
Richard W.

Re: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[tony]

* Woodruff, Richard <r-woodruff2@ti.com> [060803 08:57]:
> > Sure if you take a snapshot of the code and hack it for your board for
> a
> > year the merge back to the current tree is a big pain. If you want to
> > merge something then, you need to allocate the resouces to do that.
> 
> We did make some effort at that time. Our resource window as defined at
> that time wasn't so big.  What we got was, we don't like this, and there
> should only be mach-omap directory and not mach-omap2.  Keeping it all
> in a shared structure at that time meant a higher bar of entry.  After
> more people outside of TI started working on it, it did eventually go to
> OMAP2 + Plat.

Maybe TI should have somebody working on doing the merging? And if
it's done early enough customers would have decent Linux support for new
processors and then only have to deal with writing the board specific device
drivers.
 
> Practically speaking available time is limited.  Perhaps it needs to be
> more but those are not the parameters I set.

I don't think it's reasonable to expect somebody else will take care
of cleaning up TI code except little bits here and there as needed
for own use.
 
> > Product vendors can certainly do their board specific hacks on the
> > common code. Who's saying you have to wait for something instead of
> > doing your own board specific hacks?
> 
> No body waits.
> 
> Better aligning capabilities windows results in more functionality
> getting in.  Having working things evolving would seem to be better for
> many interests.

Yes indeed. How about posting some patches for upcoming processors for
discussion a bit earlier if possible?
 
> OMAP3 isn't so far off.  One of the side goals of my chip centric point
> of view is to look at how OMAP2 went and see if there are any factors
> which can make OMAP3 come in easier (aside from the obvious adding
> resources).  It is pretty safe to say there will be an OMAP3 directory,
> for some reason that wasn't an easy call for OMAP2.  By putting high
> coupling between the chips like was started in OMAP2 means things won't
> move well.

Let me guess... You copy clock.c, gpio.c, dma.c, pm.c, etc to omap3
directory and hack on it to make it work on omap3 and then call it
omap3 and it's totally different from earlier code? :)

AFAIK from chip to chip estimated 60 - 80% of internal omap devices are
same except for the bus address. And maybe some added features. What is
so different with omap3 if you can tell us something?
 
> > > One measure might be I know of several vendors in production of
> OMAP2
> > > chips for over a year using less well structured trees.  I don't
> think
> > > the same can happen from this tree yet.  Now, those less well
> structured
> > > trees many not have been able to exist with out a good branch off
> point
> > > which this tree provides...  balance...
> > 
> > Sure. Then go use your hacked 2.6.10 tree. If you're in a rush you
> must
> > use what's available and hack the available code for your board.
> However
> > somebody needs to look after the integration too. Hack and forget
> > attitude means duplicating the work over and over again. Think about
> > the MMC drivers Linux has seen for example: Because of lack of
> > coordination it was written 3 times for omap.
> 
> Yes, that is true.  And the USB subsystem has been rewritten 3 times
> also.  In some sense that is the way of Linux and why it has evolved
> faster than others.  Like I lobbied it's a balance.

Heh, not quite the same scale of complexity luckily :)
 
> > > Thanks for the good work.
> > 
> > Whatever. Rather thank Komal for all the good work on merging TI code.
> 
> Generally we try and help where we can in this forum.  I do help Komal
> and you and others where I can.  Boards, data clarification, some
> code...

I appreciate all that for sure. But it sure would be nice to have
somebody dedicated to merging code for new processors at TI.
 
> I saw a 2430 patch recently which seemed reasonable which hasn't had
> many comments.  A little tweak here and there and it boots.  What holds
> such things back from being merged?  Many people benefit from it
> working.

>From what I can see it looks pretty good. I just have not had time to
take a look at it yet, sorry. I should have more time now with some
other stuff out of the way. Anyways, compared to LKML we've been
quite fast merging patches in general.

Regards,

Tony

RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Woodruff, Richard]

> Let me guess... You copy clock.c, gpio.c, dma.c, pm.c, etc to omap3
> directory and hack on it to make it work on omap3 and then call it
> omap3 and it's totally different from earlier code? :)

The process does go something like that.  PRCM is a huge change so clock
and pm won't be able to do much sharing. Many of the modules have been
upgraded.  Carrying around bug work arounds for dma or compatibility
modes isn't so great.  Backward compatible code sharing at bring up time
is less important as compared to validating things are working to
specification.

> AFAIK from chip to chip estimated 60 - 80% of internal omap devices
are
> same except for the bus address. And maybe some added features. What
is
> so different with omap3 if you can tell us something?

Camera with ISP is way different for one, Davainci can help there.
Other things are not so far from 2430.  More later on others...

Early access isn't always so great. Many parts of the system are staged
so major functional parts change (on SDP and sometimes silicon) through
the development process.  There are also generally a good number of
silicon/board/documentation bugs.  In previous cases there was no TRM
until you were about done.  Much less friendly documents exist before
that.

> I appreciate all that for sure. But it sure would be nice to have
> somebody dedicated to merging code for new processors at TI.

I can certainly pass that on.  It is not a new thought.

Regards,
Richard W.

Re: Pending July patches

[Tony Lindgren]

Hi all,

I've pushed some patches. Does anybody else have patches that should go in
before I tag 2.6.17-omap2?

 Here's the current status:

1. [PATCH] fix PWL macro names
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007503.html

Pushed.

2. [PATCH] ARM: OMAP: Fix missing channel using
omap_set_dma_priority()
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007508.html

Note: Needs check if channel 0 is really okay for OMAP24xx.

This gets only called for omap1, channel does not matter. Pushed.

3. ARM: OMAP: omapfb: Fix 444 mode after recent LCD changes
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007525.html

Pushed.

4. [PATCH] ARM: OMAP: omapfb: Add Amstrad Delta LCD driver
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007526.html

Pushed.

5. 2420 boot BUG(): failure to map SRAM
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007578.html

Pushed.

6.[PATCH] ARM: OMAP: mux: add config for 16xx SPI pins
http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007596.html

Pushed.

7. [PATCH] ARM: OMAP: Apollon MMC support using OMAP2 MMC interface
http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007373.html

Pushed.

8. [PATCH] ARM: OMAP: LEDs dirver support
http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007478.html

Pushed.

9. [PATCH] USB device support on OMAP2
http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007471.html

Not pushed yet, need to leave out MMC code out of the patch and test
first.

Regards,

Tony

[PATCH] ARM: OMAP: Fix lcd_ams_delta to use new PWL defines

[Jonathan McDowell]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Fri, Aug 04, 2006 at 02:05:31PM +0300, Tony Lindgren wrote:
 
> I've pushed some patches. Does anybody else have patches that should go in
> before I tag 2.6.17-omap2?

The attached is necessary to move the Amstrad Delta LCD driver over to
the new PWL defines that have been pushed.

Signed-Off-By: Jonathan McDowell <noodles@earth.li>

J.

-- 
/-\                             |   noodles is a quick meal that is
|@/  Debian GNU/Linux Developer |               healthy
\-                              |

[-- Attachment #2: ams-delta-lcd-pwl-fix.diff --]
[-- Type: text/plain, Size: 741 bytes --]

--- drivers/video/omap/lcd_ams_delta.c.orig	2006-08-04 14:16:22.000000000 +0100
+++ drivers/video/omap/lcd_ams_delta.c	2006-08-04 14:17:59.000000000 +0100
@@ -29,7 +29,7 @@
 #include <asm/io.h>
 
 #include <asm/arch/board-ams-delta.h>
-#include <asm/arch/omap16xx.h>
+#include <asm/arch/hardware.h>
 #include <asm/arch/omapfb.h>
 
 #define AMS_DELTA_DEFAULT_CONTRAST	112
@@ -51,8 +51,8 @@ static int ams_delta_panel_enable(struct
 	ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN,
 			AMS_DELTA_LATCH2_LCD_VBLEN);
 
-	omap_writeb(1, OMAP16XX_PWL_CLK_ENABLE);
-	omap_writeb(AMS_DELTA_DEFAULT_CONTRAST, OMAP16XX_PWL_ENABLE);
+	omap_writeb(1, OMAP_PWL_CLK_ENABLE);
+	omap_writeb(AMS_DELTA_DEFAULT_CONTRAST, OMAP_PWL_ENABLE);
 
 	return 0;
 }

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Pending July patches

[lamikr]

It would be nice if somebody could test the functionality of usbnet and
mmc/sd with omap1 devices (omap1510)
before tagging. I got the lcd working by using the fixes now already
applied to OMAP kernel but both the MMC/SD
and usbnet failed to work at least for me & h6300.
(2.6.16 kernel worked ok.)

I can also try to test again these but for me it will go over the weekend...

Mika

Tony Lindgren wrote:
> Hi all,
>
> I've pushed some patches. Does anybody else have patches that should go in
> before I tag 2.6.17-omap2?
>
>  Here's the current status:
>
> 1. [PATCH] fix PWL macro names
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007503.html
>
> Pushed.
>
> 2. [PATCH] ARM: OMAP: Fix missing channel using
> omap_set_dma_priority()
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007508.html
>
> Note: Needs check if channel 0 is really okay for OMAP24xx.
>
> This gets only called for omap1, channel does not matter. Pushed.
>
> 3. ARM: OMAP: omapfb: Fix 444 mode after recent LCD changes
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007525.html
>
> Pushed.
>
> 4. [PATCH] ARM: OMAP: omapfb: Add Amstrad Delta LCD driver
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007526.html
>
> Pushed.
>
> 5. 2420 boot BUG(): failure to map SRAM
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007578.html
>
> Pushed.
>
> 6.[PATCH] ARM: OMAP: mux: add config for 16xx SPI pins
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-July/007596.html
>
> Pushed.
>
> 7. [PATCH] ARM: OMAP: Apollon MMC support using OMAP2 MMC interface
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007373.html
>
> Pushed.
>
> 8. [PATCH] ARM: OMAP: LEDs dirver support
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007478.html
>
> Pushed.
>
> 9. [PATCH] USB device support on OMAP2
> http://linux.omap.com/pipermail/linux-omap-open-source/2006-June/007471.html
>
> Not pushed yet, need to leave out MMC code out of the patch and test
> first.
>
> Regards,
>
> Tony
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>
>   

Re: [PATCH] ARM: OMAP: Fix lcd_ams_delta to use new PWL defines

[Tony Lindgren]

* Jonathan McDowell <noodles@earth.li> [060804 16:21]:
> On Fri, Aug 04, 2006 at 02:05:31PM +0300, Tony Lindgren wrote:
>  
> > I've pushed some patches. Does anybody else have patches that should go in
> > before I tag 2.6.17-omap2?
> 
> The attached is necessary to move the Amstrad Delta LCD driver over to
> the new PWL defines that have been pushed.

Pushed this one and tagged 2.6.17-omap2.

Also updating the tree to 2.6.18-rc4 so some things will probably break
a bit with the generic irq framework :)

Regards,

Tony

Re: Pending July patches

[Tony Lindgren]

* lamikr <lamikr@cc.jyu.fi> [060804 17:40]:
> It would be nice if somebody could test the functionality of usbnet and
> mmc/sd with omap1 devices (omap1510)
> before tagging. I got the lcd working by using the fixes now already
> applied to OMAP kernel but both the MMC/SD
> and usbnet failed to work at least for me & h6300.
> (2.6.16 kernel worked ok.)
> 
> I can also try to test again these but for me it will go over the weekend...

No patches so I tagged it already :)

Tony

Re: Pending July patches

[lamikr]

Tony Lindgren wrote:
> * lamikr <lamikr@cc.jyu.fi> [060804 17:40]:
>> It would be nice if somebody could test the functionality of usbnet and
>> mmc/sd with omap1 devices (omap1510)
>> before tagging. I got the lcd working by using the fixes now already
>> applied to OMAP kernel but both the MMC/SD
>> and usbnet failed to work at least for me & h6300.
>> (2.6.16 kernel worked ok.)
>>
>> I can also try to test again these but for me it will go over the
weekend...
>
> No patches so I tagged it already :)
Well, I suppose2.6.17-omap2 tag means that it works with omap2 devices :-)

I tried that with my h6340 that but unfortunately I could not find fix
for the usbnet and MMC/SD card problems.
So it probably means that they are failing also for other OMAP1 devices?

I tested usbnet both with the DMA enabled and disabled in omap_udc.c
(#define USE_DMA / #undef USE_DMA) and with both of the options
the usb link was not created to my desktop.
I also tried to mount both the "Kingston Elite Pro 512 MB" SD card and
San Disk 256 MB RC-MMC MMC cards without success.

With 2.6.16 kernel, both the SD, MMC cards were working as well as the
usbnet.
Any idea, which would be the best place to add debug in in the MMC/SD
card subsystem to get more info?

Mika

Re: Pending July patches

[andrzej zaborowski]

On 08/08/06, lamikr <lamikr@cc.jyu.fi> wrote:
> Tony Lindgren wrote:
> > * lamikr <lamikr@cc.jyu.fi> [060804 17:40]:
> >> It would be nice if somebody could test the functionality of usbnet and
> >> mmc/sd with omap1 devices (omap1510)
> >> before tagging. I got the lcd working by using the fixes now already
> >> applied to OMAP kernel but both the MMC/SD
> >> and usbnet failed to work at least for me & h6300.
> >> (2.6.16 kernel worked ok.)
> >>
> >> I can also try to test again these but for me it will go over the
> weekend...
> >
> > No patches so I tagged it already :)
> Well, I suppose2.6.17-omap2 tag means that it works with omap2 devices :-)
>
> I tried that with my h6340 that but unfortunately I could not find fix
> for the usbnet and MMC/SD card problems.
> So it probably means that they are failing also for other OMAP1 devices?
>
> I tested usbnet both with the DMA enabled and disabled in omap_udc.c
> (#define USE_DMA / #undef USE_DMA) and with both of the options
> the usb link was not created to my desktop.
> I also tried to mount both the "Kingston Elite Pro 512 MB" SD card and
> San Disk 256 MB RC-MMC MMC cards without success.
>
> With 2.6.16 kernel, both the SD, MMC cards were working as well as the
> usbnet.
> Any idea, which would be the best place to add debug in in the MMC/SD
> card subsystem to get more info?

Try enabling CONFIG_MMC_DEBUG in the config, it should give at least
some basic info, e.g. what commands are sent to the card and what
error they give (timeouts, crc..).

Personally I didn't have problems with MMC/SD support on OMAP1 with
current git, except the 2GB and 4GB cards (but we have a workaround
for those). Instead I see strange things happen with the LCD -- It
takes about 1 second to initialise (in 2.6.16 you couldn't notice
this) and for some reason I had to change the .pixclock field from
12500 to 29000. The weird part is that it's not anything in the LCD
driver because I reverted this driver alone to 2.6.16 and nothing
changed. I will be investigating this.

>
> Mika
>
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>

Greetings,
Andrew
-- 
balrog 2oo6

mcbsp

[Arnold]

Hi guys,

Is there anyone who knows about mcbsp? Is it possible
to connect a button or a led to it? If yes, how is it
done? Is it the same as programming the gpio? I hope
there's someone who could help me.

Thanks,
Oj

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: 2.6.18-rc4 / generic irq etc.

[Jonathan McDowell]

On Mon, Aug 07, 2006 at 06:22:02PM +0300, Tony Lindgren wrote:
 
> Also updating the tree to 2.6.18-rc4 so some things will probably break
> a bit with the generic irq framework :)

As a data point latest git seems to work fine on the E3 for at least
the serial console and USB host.

J.

-- 
                                            jid: noodles@jabber.earth.li
Everybody needs a little love sometime;
                                            stop hacking and fall in
love!

Re: 2.6.18-rc4 / generic irq etc.

[Tony Lindgren]

* Jonathan McDowell <noodles@earth.li> [060809 00:33]:
> On Mon, Aug 07, 2006 at 06:22:02PM +0300, Tony Lindgren wrote:
>  
> > Also updating the tree to 2.6.18-rc4 so some things will probably break
> > a bit with the generic irq framework :)
> 
> As a data point latest git seems to work fine on the E3 for at least
> the serial console and USB host.

Good to hear. GPIO is the most likely candidate to have some issues..

Tony

Re: Pending July patches

[andrzej zaborowski]

On 08/08/06, andrzej zaborowski <balrog@zabor.org> wrote:
> On 08/08/06, lamikr <lamikr@cc.jyu.fi> wrote:
> > Tony Lindgren wrote:
> > > * lamikr <lamikr@cc.jyu.fi> [060804 17:40]:
> > >> It would be nice if somebody could test the functionality of usbnet and
> > >> mmc/sd with omap1 devices (omap1510)
> > >> before tagging. I got the lcd working by using the fixes now already
> > >> applied to OMAP kernel but both the MMC/SD
> > >> and usbnet failed to work at least for me & h6300.
> > >> (2.6.16 kernel worked ok.)
> > >>
> > >> I can also try to test again these but for me it will go over the
> > weekend...
> > >
> > > No patches so I tagged it already :)
> > Well, I suppose2.6.17-omap2 tag means that it works with omap2 devices :-)
> >
> > I tried that with my h6340 that but unfortunately I could not find fix
> > for the usbnet and MMC/SD card problems.
> > So it probably means that they are failing also for other OMAP1 devices?
> >
> > I tested usbnet both with the DMA enabled and disabled in omap_udc.c
> > (#define USE_DMA / #undef USE_DMA) and with both of the options
> > the usb link was not created to my desktop.
> > I also tried to mount both the "Kingston Elite Pro 512 MB" SD card and
> > San Disk 256 MB RC-MMC MMC cards without success.
> >
> > With 2.6.16 kernel, both the SD, MMC cards were working as well as the
> > usbnet.
> > Any idea, which would be the best place to add debug in in the MMC/SD
> > card subsystem to get more info?
>
> Try enabling CONFIG_MMC_DEBUG in the config, it should give at least
> some basic info, e.g. what commands are sent to the card and what
> error they give (timeouts, crc..).
>
> Personally I didn't have problems with MMC/SD support on OMAP1 with
> current git, except the 2GB and 4GB cards (but we have a workaround
> for those). Instead I see strange things happen with the LCD -- It
> takes about 1 second to initialise (in 2.6.16 you couldn't notice

Oops, actually it was in the MMC/SD driver. Because the lines
        if (!irqs_disabled())
                return -EAGAIN;
in mmc_omap_suspend were removed, LCD & backlight are now suspended
before MMC and resumed first which results in a weird visual effect
while cards are detected but no slowdown as far as I can tell.

A more serious issue I found in this version on my board (OMAP311) is
that Linux gets really confused if a card is inserted or ejected while
suspended. For example the sequence: suspend the system, eject the
card, resume, suspend again -- results in a lockup in 100% cases while
it worked in 2.6.16. I *think* it's not only me and I *think* it's not
even OMAP specific but can't test it. The lock-up is in
mmc_deselect_cards(), the MMC layer thinks a card is selected (even
though no card is inserted).

> this) and for some reason I had to change the .pixclock field from
> 12500 to 29000. The weird part is that it's not anything in the LCD

I haven't figured out why I had to change the pixclock (debugging is
difficult because 1 in 5 tries it works with the old value so you're
never sure).

> driver because I reverted this driver alone to 2.6.16 and nothing
> changed. I will be investigating this.
>
> >
> > Mika
> >
> > _______________________________________________
> > Linux-omap-open-source mailing list
> > Linux-omap-open-source@linux.omap.com
> > http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> >
>
> Greetings,
> Andrew
> --
> balrog 2oo6
>

It seems a number of things were fixed which weren't broken :P
-- 
balrog 2oo6

Re: Pending July patches

[Tony Lindgren]

* andrzej zaborowski <balrog@zabor.org> [060810 07:41]:
> >
> >Personally I didn't have problems with MMC/SD support on OMAP1 with
> >current git, except the 2GB and 4GB cards (but we have a workaround
> >for those). Instead I see strange things happen with the LCD -- It
> >takes about 1 second to initialise (in 2.6.16 you couldn't notice
> 
> Oops, actually it was in the MMC/SD driver. Because the lines
>        if (!irqs_disabled())
>                return -EAGAIN;
> in mmc_omap_suspend were removed, LCD & backlight are now suspended
> before MMC and resumed first which results in a weird visual effect
> while cards are detected but no slowdown as far as I can tell.

Do you have a patch for that?

Tony

Re: Pending July patches

[andrzej zaborowski]

On 10/08/06, Tony Lindgren <tony@atomide.com> wrote:
> * andrzej zaborowski <balrog@zabor.org> [060810 07:41]:
> > >
> > >Personally I didn't have problems with MMC/SD support on OMAP1 with
> > >current git, except the 2GB and 4GB cards (but we have a workaround
> > >for those). Instead I see strange things happen with the LCD -- It
> > >takes about 1 second to initialise (in 2.6.16 you couldn't notice
> >
> > Oops, actually it was in the MMC/SD driver. Because the lines
> >        if (!irqs_disabled())
> >                return -EAGAIN;
> > in mmc_omap_suspend were removed, LCD & backlight are now suspended
> > before MMC and resumed first which results in a weird visual effect
> > while cards are detected but no slowdown as far as I can tell.
>
> Do you have a patch for that?

Well, it's just aesthetics. If you put these two lines back in
mmc_omap_suspend(), resuming will look better because LCD & backlight
resumes last, but there's a trade-off, according to
Documentation/power/devices.txt (which I only found out about today):
when a driver returns -EAGAIN, it will be suspended as last but it can
only be suspended with the whole system. Run-time suspending won't
work (i.e. "echo 1 > /sys/devices/platform/mmci-omap.1/power/state"
will fail) so it's probably not desirable.
I don't know how to force LCD to be resumed last.

>
> Tony
>

Regards,
Andrzej
-- 
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

Re: Pending July patches

[Tony Lindgren]

* andrzej zaborowski <balrog@zabor.org> [060810 11:07]:
> On 10/08/06, Tony Lindgren <tony@atomide.com> wrote:
> >* andrzej zaborowski <balrog@zabor.org> [060810 07:41]:
> >> >
> >> >Personally I didn't have problems with MMC/SD support on OMAP1 with
> >> >current git, except the 2GB and 4GB cards (but we have a workaround
> >> >for those). Instead I see strange things happen with the LCD -- It
> >> >takes about 1 second to initialise (in 2.6.16 you couldn't notice
> >>
> >> Oops, actually it was in the MMC/SD driver. Because the lines
> >>        if (!irqs_disabled())
> >>                return -EAGAIN;
> >> in mmc_omap_suspend were removed, LCD & backlight are now suspended
> >> before MMC and resumed first which results in a weird visual effect
> >> while cards are detected but no slowdown as far as I can tell.
> >
> >Do you have a patch for that?
> 
> Well, it's just aesthetics. If you put these two lines back in
> mmc_omap_suspend(), resuming will look better because LCD & backlight
> resumes last, but there's a trade-off, according to
> Documentation/power/devices.txt (which I only found out about today):
> when a driver returns -EAGAIN, it will be suspended as last but it can
> only be suspended with the whole system. Run-time suspending won't
> work (i.e. "echo 1 > /sys/devices/platform/mmci-omap.1/power/state"
> will fail) so it's probably not desirable.

OK, let's keep as it is then.

> I don't know how to force LCD to be resumed last.

Maybe the makefile order?

Tony

Re: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Dirk Behme]

Woodruff, Richard wrote:
...
> No body waits.
...
> OMAP3 isn't so far off. 
...
>>>Thanks for the good work.
>>
>>Whatever. Rather thank Komal for all the good work on merging TI code.
> 
> Generally we try and help where we can in this forum.  I do help Komal
> and you and others where I can.  Boards, data clarification, some
> code...

Maybe TI can consider to create something like a OSK for 
OMAP2 and/or OMAP3? It's my feeling that there are many 
people who are able and willing to work on OMAP code, and 
OSK was a big success regarding this.

But I think for this easy access to HW and documentation is 
necessary. I think not everybody who is able and willing to 
help improving OMAP code has a purchasing department, 
lawyers, project managers and all this stuff which sometimes 
seems to be necessary to get the HW and information to help.

Opinions?

Regards

Dirk

RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)

[Woodruff, Richard]

> > Generally we try and help where we can in this forum.  I do help
Komal
> > and you and others where I can.  Boards, data clarification, some
> > code...
> 
> Maybe TI can consider to create something like a OSK for
> OMAP2 and/or OMAP3? It's my feeling that there are many
> people who are able and willing to work on OMAP code, and
> OSK was a big success regarding this.
> 
> But I think for this easy access to HW and documentation is
> necessary. I think not everybody who is able and willing to
> help improving OMAP code has a purchasing department,
> lawyers, project managers and all this stuff which sometimes
> seems to be necessary to get the HW and information to help.
> 
> Opinions?

OSK like programs have progressed to different levels on a few OMAP2
platforms. Hopefully one will make it out.  There is a good amount of
effort/cost and negotiations in getting one out.

I agree it is a good idea which does help.

Regards,
Richard W.