public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* Pending July patches
@ 2006-08-01 16:44 Dirk Behme
  2006-08-03 11:17 ` Tony Lindgren
  0 siblings, 1 reply; 29+ messages in thread
From: Dirk Behme @ 2006-08-01 16:44 UTC (permalink / raw)
  To: linux-omap-open-source

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

^ permalink raw reply	[flat|nested] 29+ messages in thread
* RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)
@ 2006-08-03 14:20 Woodruff, Richard
  2006-08-03 15:00 ` Tony Lindgren
  2006-08-03 16:00 ` Juha Yrjölä
  0 siblings, 2 replies; 29+ messages in thread
From: Woodruff, Richard @ 2006-08-03 14:20 UTC (permalink / raw)
  To: Tony Lindgren, Komal Shah; +Cc: linux-omap-open-source

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.

^ permalink raw reply	[flat|nested] 29+ messages in thread
* RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)
@ 2006-08-03 15:57 Woodruff, Richard
  2006-08-03 16:22 ` Dirk Behme
                   ` (2 more replies)
  0 siblings, 3 replies; 29+ messages in thread
From: Woodruff, Richard @ 2006-08-03 15:57 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap-open-source

> 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.

^ permalink raw reply	[flat|nested] 29+ messages in thread
* RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)
@ 2006-08-03 16:23 Woodruff, Richard
  0 siblings, 0 replies; 29+ messages in thread
From: Woodruff, Richard @ 2006-08-03 16:23 UTC (permalink / raw)
  To: Juha Yrjölä; +Cc: linux-omap-open-source

> 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.

^ permalink raw reply	[flat|nested] 29+ messages in thread
* RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)
@ 2006-08-03 22:37 Woodruff, Richard
  0 siblings, 0 replies; 29+ messages in thread
From: Woodruff, Richard @ 2006-08-03 22:37 UTC (permalink / raw)
  To: tony; +Cc: linux-omap-open-source

> 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.

^ permalink raw reply	[flat|nested] 29+ messages in thread
* RE: GPMC timings for smc91x on 24xx (WAS: Pending July patches)
@ 2006-08-13 15:49 Woodruff, Richard
  0 siblings, 0 replies; 29+ messages in thread
From: Woodruff, Richard @ 2006-08-13 15:49 UTC (permalink / raw)
  To: Dirk Behme, linux-omap-open-source

> > 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.

^ permalink raw reply	[flat|nested] 29+ messages in thread
end of thread, other threads:[~2006-08-13 15:49 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-01 16:44 Pending July patches Dirk Behme
2006-08-03 11:17 ` Tony Lindgren
2006-08-03 12:08   ` Komal Shah
2006-08-03 13:03     ` GPMC timings for smc91x on 24xx (WAS: Pending July patches) Tony Lindgren
2006-08-03 13:39       ` Need help to understand a #pragma statment Taru Varshney
2006-08-04 11:05     ` Pending July patches Tony Lindgren
2006-08-04 13:20       ` [PATCH] ARM: OMAP: Fix lcd_ams_delta to use new PWL defines Jonathan McDowell
2006-08-07 15:22         ` Tony Lindgren
2006-08-08  8:33           ` mcbsp Arnold
2006-08-08 21:33           ` 2.6.18-rc4 / generic irq etc Jonathan McDowell
2006-08-09  7:26             ` Tony Lindgren
2006-08-04 14:40       ` Pending July patches lamikr
2006-08-07 15:23         ` Tony Lindgren
2006-08-07 23:56           ` lamikr
2006-08-08  1:30             ` andrzej zaborowski
2006-08-10  4:41               ` andrzej zaborowski
2006-08-10  7:32                 ` Tony Lindgren
2006-08-10  8:07                   ` andrzej zaborowski
2006-08-10 10:45                     ` Tony Lindgren
  -- strict thread matches above, loose matches on Subject: below --
2006-08-03 14:20 GPMC timings for smc91x on 24xx (WAS: Pending July patches) Woodruff, Richard
2006-08-03 15:00 ` Tony Lindgren
2006-08-03 16:00 ` Juha Yrjölä
2006-08-03 15:57 Woodruff, Richard
2006-08-03 16:22 ` Dirk Behme
2006-08-03 18:55 ` tony
2006-08-13 14:42 ` Dirk Behme
2006-08-03 16:23 Woodruff, Richard
2006-08-03 22:37 Woodruff, Richard
2006-08-13 15:49 Woodruff, Richard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox