[ANNOUNCE] TI DaVinci git tree available

[ANNOUNCE] TI DaVinci git tree available

[Kevin Hilman]

The kernel git tree[1] for the TI DaVinci platform is now available at

  http://source.mvista.com/git/

This kernel is currently based on 2.6.17-rc4 and will follow the
mainline kernel.  

This is currently a minimal kernel with only serial and ethernet
support, but drivers will be added one by one as I forward port them
from the 2.6.10-based MontaVista product.

Included in the tree is a default config (via 'make
davinci_dm644x_defconfig') that should boot.

There are some known issues[2] as well as some areas that could use
updating to the newer kernel and updates for the Linux Driver model.

Patches are welcome!   

Like the OMAP site, TI is maintaining a Linux site for DaVinci at
http://linux.davincidsp.com/  Mailing-list subscription info can be
found there.

-- 
Kevin Hilman <khilman@mvista.com>
MontaVista Software, Inc.



[1] For those new to git, there is an overview, tutorial and man pages
available at http://www.kernel.org/git/  

[2] Known issues:  Something has changed in the 8250 serial driver since
2.6.10 which causes some problems on the serial console.  Interrupts
seem to be lost such that the driver seems to be a few characters behind
what you're typing.  This is still under investigation, but any help
appreciated.

Re: [ANNOUNCE] TI DaVinci git tree available

[Dirk Behme]

Kevin Hilman wrote:
> The kernel git tree[1] for the TI DaVinci platform is now available

What are the pros and cons for having one tree vs. two trees 
for OMAP1 & OMAP2 (& OMAP3?) & DaVinci in the long term?

Dirk

Re: [ANNOUNCE] TI DaVinci git tree available

[Kevin Hilman]

On Wed, 2006-05-17 at 17:43 +0200, Dirk Behme wrote:
> Kevin Hilman wrote:
> > The kernel git tree[1] for the TI DaVinci platform is now available
> 
> What are the pros and cons for having one tree vs. two trees 
> for OMAP1 & OMAP2 (& OMAP3?) & DaVinci in the long term?

It may be a good idea long term, in fact I almost released this tree as
a branch of the OMAP tree instead of Linus' tree.  As I thought about it
though, there's very little shared code between the two trees, so I
assumed it would be more of a burden on the OMAP community.  So in the
end, I decided to wait and see what type of development community
sprouts up around DaVinci and go from there.  If the OMAP community is
interested in absorbing the DaVinci support, I think long-term
maintenance would be easier.

I'm not fixed on one way or the other, and could easily be pursuaded to
rebase the DaVinci tree.  For kicks, I rebased locally, and there's a
patch adding DaVinci support to todays OMAP tree available here:
http://source.mvista.com/~khilman/davinci/

Some existing areas of overlap I can think of off the top of my head:

- CONFIG_DEBUG_LL patch to kernel/printk.c
- AIC23 code: DaVinci has AIC33 and I have a minor patch to support
AIC33
- There's also hack to the 8250.c serial ISR that used to be needed but
is no longer needed on DaVinci.  It seems some mainline fixes have
removed the need for that.  I'm curious if it's still necessary on OMAP.

Kevin

Re: [ANNOUNCE] TI DaVinci git tree available

[Tony Lindgren]

* Kevin Hilman <khilman@mvista.com> [060517 13:46]:
> On Wed, 2006-05-17 at 17:43 +0200, Dirk Behme wrote:
> > Kevin Hilman wrote:
> > > The kernel git tree[1] for the TI DaVinci platform is now available
> > 
> > What are the pros and cons for having one tree vs. two trees 
> > for OMAP1 & OMAP2 (& OMAP3?) & DaVinci in the long term?
> 
> It may be a good idea long term, in fact I almost released this tree as
> a branch of the OMAP tree instead of Linus' tree.  As I thought about it
> though, there's very little shared code between the two trees, so I
> assumed it would be more of a burden on the OMAP community.  So in the
> end, I decided to wait and see what type of development community
> sprouts up around DaVinci and go from there.  If the OMAP community is
> interested in absorbing the DaVinci support, I think long-term
> maintenance would be easier.
> 
> I'm not fixed on one way or the other, and could easily be pursuaded to
> rebase the DaVinci tree.  For kicks, I rebased locally, and there's a
> patch adding DaVinci support to todays OMAP tree available here:
> http://source.mvista.com/~khilman/davinci/

Let's wait and see then. If we have lots of drivers to share then it
makes sense to have them in the same tree. But for few drivers, let's
just work them out and try to have them integrated into the mainline
tree.
 
> Some existing areas of overlap I can think of off the top of my head:
> 
> - CONFIG_DEBUG_LL patch to kernel/printk.c

Hmmm, what are you using for CONFIG_DEBUG_LL then?

> - AIC23 code: DaVinci has AIC33 and I have a minor patch to support
> AIC33

Let's try to get that integrated to the mainline tree.

> - There's also hack to the 8250.c serial ISR that used to be needed but
> is no longer needed on DaVinci.  It seems some mainline fixes have
> removed the need for that.  I'm curious if it's still necessary on OMAP.

I assume you mean this chunk?

@@ -1372,7 +1372,8 @@
 
        DEBUG_INTR("end.\n");
 
-       return IRQ_RETVAL(handled);
+       //return IRQ_RETVAL(handled);
+       return IRQ_HANDLED;     /* FIXME: iir status not ready on 1510 */
 }

I'll see if things work now without that.

Regards,

Tony

Re: [ANNOUNCE] TI DaVinci git tree available

[Kevin Hilman]

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

On Fri, 2006-05-26 at 16:21 -0700, Tony Lindgren wrote:
> * Kevin Hilman <khilman@mvista.com> [060517 13:46]:
> > On Wed, 2006-05-17 at 17:43 +0200, Dirk Behme wrote:
> > > Kevin Hilman wrote:
> > > > The kernel git tree[1] for the TI DaVinci platform is now available
> > > 
> > > What are the pros and cons for having one tree vs. two trees 
> > > for OMAP1 & OMAP2 (& OMAP3?) & DaVinci in the long term?
> > 
> > It may be a good idea long term, in fact I almost released this tree as
> > a branch of the OMAP tree instead of Linus' tree.  As I thought about it
> > though, there's very little shared code between the two trees, so I
> > assumed it would be more of a burden on the OMAP community.  So in the
> > end, I decided to wait and see what type of development community
> > sprouts up around DaVinci and go from there.  If the OMAP community is
> > interested in absorbing the DaVinci support, I think long-term
> > maintenance would be easier.
> > 
> > I'm not fixed on one way or the other, and could easily be pursuaded to
> > rebase the DaVinci tree.  For kicks, I rebased locally, and there's a
> > patch adding DaVinci support to todays OMAP tree available here:
> > http://source.mvista.com/~khilman/davinci/
> 
> Let's wait and see then. If we have lots of drivers to share then it
> makes sense to have them in the same tree. But for few drivers, let's
> just work them out and try to have them integrated into the mainline
> tree.

So you're leaning towards keeping the trees separate?  It would
incentivize pushing things upstream.   In any case, I've attached a
patch which adds core DaVinci support to todays OMAP tree.  You can see
that there no changes to common files (except Makefile/Kconfig) and will
not affect OMAP.
 
> > Some existing areas of overlap I can think of off the top of my head:
> > 
> > - CONFIG_DEBUG_LL patch to kernel/printk.c
> 
> Hmmm, what are you using for CONFIG_DEBUG_LL then?

The change to kernel/printk.c is not in mainline, so I've borrowed the
one from the OMAP tree.

> > - AIC23 code: DaVinci has AIC33 and I have a minor patch to support
> > AIC33
> 
> Let's try to get that integrated to the mainline tree.

I don't think the existing aic23 code is in mainline yet, is it?

> > - There's also hack to the 8250.c serial ISR that used to be needed but
> > is no longer needed on DaVinci.  It seems some mainline fixes have
> > removed the need for that.  I'm curious if it's still necessary on OMAP.
> 
> I assume you mean this chunk?
>
> @@ -1372,7 +1372,8 @@
>  
>         DEBUG_INTR("end.\n");
>  
> -       return IRQ_RETVAL(handled);
> +       //return IRQ_RETVAL(handled);
> +       return IRQ_HANDLED;     /* FIXME: iir status not ready on 1510 */
>  }

Yeah, that's what I"m referring to.

> I'll see if things work now without that.
> 

DaVinci doesn't seem to need it anymore.

I remembered one other driver that will be shared and that's the Mentor
high-speed usb driver which is the same on 243x and DaVinci.  

Kevin


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

RE: [ANNOUNCE] TI DaVinci git tree available

[Woodruff, Richard]

> > - There's also hack to the 8250.c serial ISR that used to be needed
but
> > is no longer needed on DaVinci.  It seems some mainline fixes have
> > removed the need for that.  I'm curious if it's still necessary on
OMAP.
> 
> I assume you mean this chunk?
> 
> @@ -1372,7 +1372,8 @@
> 
>         DEBUG_INTR("end.\n");
> 
> -       return IRQ_RETVAL(handled);
> +       //return IRQ_RETVAL(handled);
> +       return IRQ_HANDLED;     /* FIXME: iir status not ready on 1510
*/
>  }
> 
> I'll see if things work now without that.

Last time I tried it didn't work with out it.  I did send Tony a patch
which may have fixed it.  Where are you at with those patches anyway
Tony?

The serial bit was a bug with respect to watermark handling and status.

On a side note to the above, I have recently unearthed a 15/16xx era
defect where the uart interrupt line could stay asserted some 6interface
+ 6functional cycles after a source condition clear, given certain clock
ratios.  Its possible DaVinci either uses a fixed version of the IP or
they just are not running at a clock combination which brings the
condition out.....or it could just be a software bug.

Regards,
Richard W.