Re: [PATCH v2] cmem: Adding New recipe for cmem

[Denys Dmytriyenko <denys@ti.com>]

On Tue, Nov 26, 2013 at 01:56:56PM +0100, Enrico wrote:
> On Wed, Nov 20, 2013 at 4:24 PM, Denys Dmytriyenko <denys@ti.com> wrote:
> > On Wed, Nov 20, 2013 at 01:11:18PM +0000, Maupin, Chase wrote:
> >> Sam,
> >>
> >> Were you going to post an updated set of these patches to meta-ti so you can
> >> align with Mrinmayee? I think your approach of splitting out the packages in
> >> linux-utils is a good one and will be cleaner going forward.  Since both of
> >> your groups share these packages aligning between the two would be helpful.
> >>
> >> As a side note I assume you have other recipes that depend on the cmem
> >> libraries that your cmem recipe provides.  Can you post one of those or
> >> share it with Mrinmayee as an example of how you are able to point to the
> >> right staging location for the libraries and headers for cmem in other
> >> recipes.  I'm hoping we can start getting rid of ti-paths.inc but I'd like
> >> to see how you were working around this.
> >>
> >> Denys,
> >>
> >> Since ti-linuxutils has other modules in it for edma, sdma, and irq but
> >> those are only for legacy devices can we just replace the whole
> >> ti-linuxutils with the cmem package which seems to be the main package
> >> needed?  Or do you want to see additional recipes for the sdma, edma, and
> >> irq moduled?
> >
> > I'd like to see other parts of linuxutils modularized, but that can be done on
> > as needed basis for any of the new platforms when they require those. We can
> > keep the old linuxutils around for a little longer, but it can only be used on
> > the old 35x and 37x plaftorms only and there are many other components (like
> > SGX) removing support for those old platforms already...
> 
> Please keep the linuxutils recipe until it can be replaced with the
> modularized ones, it's useful for 35x and 37x dsp (gstreamer_ti).

Enrico,

Thanks, I'll keep it around for now.

Can you please clarify which kernel you use for 35x and 37x platforms? And 
whether you use the latest versions of other components?

The problem with keeping old components around is that they quickly lose 
compatibility with kernel, toolchain, udev etc. that we use these days and it 
doesn't make much sense to carry them indefinitely w/o updating or replacing.

-- 
Denys