ac100 team mailing list archive

[Marc Dietrich <marvin24@xxxxxx>]

Am Freitag, 27. September 2013, 10:10:13 schrieb Gordan Bobic:
>  On Fri, 27 Sep 2013 11:03:13 +0200, Marc Dietrich <marvin24@xxxxxx>
> 
>  wrote:
> > Am Freitag, 27. September 2013, 08:50:05 schrieb Gordan Bobic:
> >>  On Wed, 25 Sep 2013 13:47:25 +0400, Andrey Danin
> >>  
> >>  <andrey.danin@xxxxxxxxx> wrote:
> >> > On Wed, 2013-09-25 at 10:10 +0100, Gordan Bobic wrote:
> >> >> The default Tegra memory carve-out is 64MB. But my
> >> >> 
> >> >>  Xorg.0.log says:
> >> >>  
> >> >>  (--) TEGRA(0): VideoRAM: 32768 kByte
> >> >>  
> >> >>  tegra_drv.so does not understand a "VideoRAM" option.
> >> >>  
> >> >>  I tried experimenting with reclaiming some memory from
> >> >>  the top 64MB with the Tegra driver loaded, and Xorg
> >> >>  crashes instantly if this is attempted (62MB memory
> >> >>  reclaim works fine with fbdev_drv.so).
> >> >>  
> >> >>  Does anybody know what is eating those other 32MB of
> >> >>  RAM if the tegra_drv.so is only using 32MB? I tried
> >> >>  playign with the nvmem parameter but that seems to
> >> >>  get ignored on everything but the most ancient of AC100
> >> >>  kernels.
> > 
> > There is also some space needed for lp0 support code.
> 
>  I tried various permutations of leaving an extra 4MB
>  untouched at 448MB, and around 480MB, being unsure
>  whether the binary driver might try to use the memory from
>  top or bottom, but it didn't really work out.
> 
>  With a fbdev, I can safely use
>  mem=448MB@0M mem=62M@450M
>  to gain an extra 62MB of RAM. The difference is very
>  very noticeable if you are running on slow-storage and
>  swapping, although it's not all that noticeable on my
>  heavily modified AC100 with a 2000 IOPS internal USB
>  SSD (Supertalent RC8).
> 
> >>  Not that I think it's relevant since it is a fairly low
> >>  
> >>  level tegra memory usage map question, but here goes:
> >> > What is your kernel version?
> >>  
> >>  2.6.38.8 from my gitorious tree (includes 1280x720
> >>  screen patches and overclocking patches.
> >>  
> >> > What cmdline do you use?
> >>  
> >>  $ dmesg | grep "command line"
> >>  Kernel command line: vmalloc=320M video=tegrafb console=tty0 ro
> >>  usbcore.old_scheme_first=1 elevator=deadline zcache quiet
> >>  tegraboot=sdmmc
> >>  tegrapart=recovery:700:a00:800,boot:1100:1000:800,mbr:2100:200:800
> >>  
> >> > What is tegra driver version ?
> >>  
> >>  The latest available for soft-float distributions,
> >>  from Alpha 15-something release. Xorg ABI v10 (ABI v7
> >>  until yesterday).
> > 
> > You should really try a newer kernel, but you may run into problems
> > with the
> > kernel graphics abi becuase you require softfloat. I think 3.0 is the
> > lastest kernel which may work with soft-float drivers.
> 
>  I thought kernel and userspace don't need to follow the same ABI. I
>  have

Sure they need to. Especially if the closed source driver is designed to fit a 
certain kernel ABI (or better in kernel graphics driver release).

>  certainly run hard-float kernels with soft-float userspace and vice
>  versa. Samsung Chromebook, for example, has a soft-float kernel
>  (armv7l)
>  but hard-float userspace.

There is no "hard float" kernel thing. The kernel is always soft float. The 
problem is that newer kernels provide a different graphics related interface 
to userspace than the latest soft float userspace drivers expect.

>  Either way, I don't see what the kernel has to do with clawing back
>  memory
>  from GPU usage.

Ideally, this should be flexible (and it is with newer kernel version > 3.0). 
On older kernels, this is kinda hard coded.

Marc