search for: ttm_bo_kmap_ttm

...eads to these errors. ioremap() or ioremap_nocache() (which are in effect the same on ARM) do not cause this issue. The best way to solve this issue would be to not use the BAR at all since the memory behind these objects can be directly accessed by the CPU. As such it would better be mapped using ttm_bo_kmap_ttm() instead. But right now this is clearly not how nouveau_bo.c is written and it does not look like this can easily be done. :/

...39;m not clear where > a WC read differs from an uncached one. Will check that. > >> The best way to solve this issue would be to not use the BAR at all >> since the memory behind these objects can be directly accessed by the >> CPU. As such it would better be mapped using ttm_bo_kmap_ttm() >> instead. But right now this is clearly not how nouveau_bo.c is written >> and it does not look like this can easily be done. :/ > > Yeah, it sounds like we want this shortcut for stolen VRAM > implementations. Actually, isn't it the case that we do not want to use TTM...

...an error to the read request, though I'm not clear where a WC read differs from an uncached one. > The best way to solve this issue would be to not use the BAR at all > since the memory behind these objects can be directly accessed by the > CPU. As such it would better be mapped using ttm_bo_kmap_ttm() > instead. But right now this is clearly not how nouveau_bo.c is written > and it does not look like this can easily be done. :/ Yeah, it sounds like we want this shortcut for stolen VRAM implementations. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Ind...

On Mon, May 19, 2014 at 6:22 PM, Lucas Stach <l.stach at pengutronix.de> wrote: > Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding: >> On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote: >> > Some architectures (e.g. ARM) need the CPU buffers to be explicitely >> > flushed for a memory write to take effect. Not doing so results in

...> > Forcing the caching to TTM_PL_FLAG_UNCACHED led to the same result. > What is interesting is that while data like vertices and textures got > corrupted, pushbuffers and shader programs seem to be just fine, as I > could not see any runtime error. An interesting fact: if I change ttm_bo_kmap_ttm() such as kernel mappings of BOs are always performed write-combined, and leave the TTM_PL_TT default caching to TTM_PL_FLAG_CACHED so user-space mappings remain cached, the corruptions just vanish. It seems to be the fact of setting user-space mappings to anything non-cached that leads to this puz...

...differs from an uncached one. > > Will check that. > > > > >> The best way to solve this issue would be to not use the BAR at all > >> since the memory behind these objects can be directly accessed by the > >> CPU. As such it would better be mapped using ttm_bo_kmap_ttm() > >> instead. But right now this is clearly not how nouveau_bo.c is written > >> and it does not look like this can easily be done. :/ > > > > Yeah, it sounds like we want this shortcut for stolen VRAM > > implementations. > > Actually, isn't it the...

On 05/19/2014 06:57 PM, Lucas Stach wrote: > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: >> This patch is not meant to be merged, but rather to try and understand >> why this is needed and what a more suitable solution could be. >> >> Allowing BOs to be write-cached results in the following happening when >> trying to run any program on

Am Dienstag, den 24.06.2014, 22:52 +0900 schrieb Alexandre Courbot: > On Tue, Jun 24, 2014 at 10:25 PM, Lucas Stach <l.stach at pengutronix.de> wrote: > > Am Dienstag, den 24.06.2014, 14:27 +0200 schrieb Maarten Lankhorst: > >> op 24-06-14 14:23, Alexandre Courbot schreef: > >> > On Tue, Jun 24, 2014 at 7:55 PM, Alexandre Courbot <acourbot at nvidia.com>

...ore reasons to avoid using the BAR at all. >> >>> >>>> The best way to solve this issue would be to not use the BAR at all >>>> since the memory behind these objects can be directly accessed by the >>>> CPU. As such it would better be mapped using ttm_bo_kmap_ttm() >>>> instead. But right now this is clearly not how nouveau_bo.c is written >>>> and it does not look like this can easily be done. :/ >>> >>> Yeah, it sounds like we want this shortcut for stolen VRAM >>> implementations. >> >> Actua...