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

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

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