Just to save work and get it up online. Current status;
GL not working as per usual
VG works - but closing Z160 device locks the driver (seems to be that
device_idle is called after the device is closed and there may be a
driver lock contention going on here).
imxng graphics driver works first run (same as above) but there are
some strange graphical glitches on smaller blits and rectangle fills,
which may be down to some kind of cache coherency problem.
Real (platform device) MMU enable causes the whole thing to explode,
since none of this got updated properly.
Tasks done:
* remove per-process support
* clean up use of device_id -> device since passing the id is a mess
for some reason 3D device isn't inited properly and some parts of
the driver call 3D device functions (notably on closing everything)
possibly because of some off-by-ones
* more global driver locking per qualcomm and to allow below fix
* clean up sharedmem and other APIs which used such semantics e.g.
kgsl_sharedmem_read -> lock, call kgsl_sharedmem_read0, unlock
to just use kgsl_sharedmem_read with manual locks before the call
where required, cleaning up the API a lot
* ditched the requirement for a device argument to sharedmem_alloc
since it never allocated from a per-device pool anyway. This is
a weird hack since the MMU setup needs a real device to set up
on.. Qualcomm's has a much better system and that will be in place
soon
* fixed the cmdstream_issueibcmds wrapper crap
* added kgsl_ringbuffer_issueibcmds to CMDSTREAM_ISSUEIBCMDS ioctl
again (no real effect)
* put kgsl_device_active in kgsl_g12_issueibcmds rather than calling
it manually before executing the function (ensures the autogating
is turned off before telling the Z160 to run a stream) from ioctl
* lots of ioctl debugging code (mostly commented out)
* function renames everywhere
* locks around suspend/resume
* removed a lot of the finegrained locking stuff as qualcomm doesn't
use it. That said, cmdwindow needs some locking (qcom uses a
spinlock) - will be added later
* LOTS of code cleanups/lint/checkpatch fixing
* removed interrupt handler abstraction
* Z160 idle timer update
* move more HAL stuff into the right places to remove the HAL more
* MMU handling cleanups (not complete, lots of it is disabled)
* NOTE: must re-add runpending to sharedmem_alloc? May not be required
when moving to new sharedmem API
* NOTE: check 3D interrupt enables
* ftbl regread/write/idle => kgsl_yamato_*
* remove some unused debug code (will put it back later but qcom removes it in .35)
* remove unused watchdog code (not referenced by anything)
* remove unused pmodeoff code (it's set to 0 in the function so effectively disabled)
* factor out firmware loading code
* header now ordered like qualcomm's
While we're at it, since we now directly call kgsl_pwrctrl (which is
formerly kgsl_hal_setpowerstate), there's nothing stopping us from
removing device_setproperty ioctl and all related code.
Some warnings got added to confirm a configuration change, part of
the "unused path" got converted away from kgsl_device_regwrite and
use yamato since it's ringbuffer-specific.. in case that is actually
the correct configuration
KGSL_PROP_SHMEM and KGSL_PROP_SHMEM_APERTURES are not used in the FSL
userspace. So just get rid of them. DMI properties got removed a while
back so remove it's definition from mxc_kgsl.h.
The only two properties it cares about are shadow memory and the
device info, which matches Qualcomm's driver. CAVEAT FOLLOWS.
There is a weird usage of the power property INTERNALLY which is an
odd way to do it and will be coded out eventually. Userspace does
not touch these properties, only the odd internal kernel usage..
includes kgsl_kmod.c -> kgsl.c and copying all the cleanup stuff in,
will rename it to qualcomm names during further cleanup of cleanup
stuff if necessary.
Missing fix for dst->src in kgsl_sharedmem_write (stashing issue,
sorry)
rename gsl_linux_map_find -> kgsl_sharedmem_find - note, qcom uses
"kgsl_mem_entry" here which is telling.
gsl_linux_map_alloc no longer maps writecombine
we no longer ioremap_wc our memory area (and split some code out)
also refine kgsl_mmap to be more like Qualcomm's (same functionality,
remove writecombining setting, remove a few vars mis/unused)
While we're doing that rationalize some namings. This actually gives us a good
indication of what is used by userspace and what is not - although a few things
like flags in kgsl_types.h may still be referenced, for now we don't move them
(since Qualcomm's driver doesn't expose them to userspace, most of them are
odd power control and/or memdesc definition).
We lose two includes from the main tree (ioctl and properties) since they are
global and for userspace.
Minor cleanups too.
results: tiger works great. es11ex is segfaulting in rb_viewport (rb_state.c)
for some reason now, probably indicative of some data not being copied back
to userspace in an ioctl (context-related?)
remove DMI props as Linux userspace doesn't use them (fix gsl_lib btw)
clean up g12_start and g12_stop and call it directly instead of using
function table while we're at it
Also some minor cleanups and change the prototype to accept a device
pointer instead of a device id, and change a lot of functions to stop
using device ids raw (KGSL_DEVICE_G12) when they have access to the
device pointer.
* mark all non-qualcomm ioctls as NQ
* mark all movements needed to make kgsl_ioctl.h into <linux/mxc_kgsl.h>
* mark all differences between qualcomm and freescale re structure defs
* significantly tidy up kgsl_ioctl.h
kgsl_kmod.c is a horrible mess but the next commit will tidy it somewhat.
* gsl_drawctxt_t -> kgsl_drawctxt (this touches some Z430 stuff too)
* gsl_z1xx_t et al -> kgsl_z1xx
* move some defines to includes
* use symbolic values in addmarker/beginpacket
* remove kgsl_context and opencode it's usage in ioctls etc.
* rename context_* ftbl functions to device_context_* like Qualcomm .35
* add kgsl_g12_cmdstream.c and kgsl_g12_drawctxt.c like Qualcomms .32
but retain functionality from our versions of these functions
behavior change:
* under fbdev, tiger and es11ex work fine most of the time
- es11ex will soft-lockup occasionally
* under imxng, tiger locks occasionally when moving the mouse pointer
- I thought this bug was fixed
* under imxng, es11ex locks after good 30 seconds
- but does NOT hang the system anymore (strange)
Since some gsl_driver.lock usage was moved I wonder if this is the
source of our race condition?
* remove dumpx stuff which was kind of file based
* remove tbdump stuff which was kind of file based
* gsl_driver_t -> struct kgsl_driver since we touched a member
* kgsl_log_write -> KGSL_*_VDBG
This is not identical to the one Qualcomm uses but it's based on
it (include side at least) - debugfs not there, and no proper
setup so in actual fact no debug ever gets printed.
It is also fairly clumsily ported in (kgsl_log_write replacement)
so is just there to keep it compiling and remove some extra code
definitions which were either unused. Refining it will come as
Qualcomm code is ported in.
No side-effects noticed that weren't previously present - the
tiger apps run fine on imxng (which also works fine) and es11ex
still crashes after some frames.
Also while we're at it don't bother using the device table and many
levels of dereference to just call regread/regwrite.
No functional difference, although tiger now is not as happy as it
once was when running on imxng - on fbdev it's absolutely fine (and
marginally faster over 10 runs).
At some point we're going to find this damned race condition :]
As we are poking around, modify the Yamato idle check to use a
timeout just like QCOM do. Also, no functional difference (never
seems to time out)
gsl_ringbuffer_t et al -> struct kgsl_ringbuffer et al
some macros GSL_ -> KGSL_
some macros safer (do/while(0))
some access functions done differently (writel instead of mem access)
some access functions grew barriers
it's used in ioctls but it was
typedef unsigned int gsl_flags_t;
so there is no ABI difference.
Also removed unused types:
typedef unsigned int gsl_devhandle_t;
typedef unsigned int gsl_ctxthandle_t;
* add #include statements where necessary to build. Some of this is a bit hacky.
* fix some things along the way (register defs mmCP_RB_RPTR -> REG_CP_RB_RPTR)
* move klibapi prototypes into the includes for those subsystems
* delete tbdump etc. includes
* delete unreferenced includes that would be touched by userspace using them (not)
Move some code up like Qualcomm's so that the command stream is initialized
before any sharedmem is allocated. This only causes a panic when fine
grained locking is enabled, but it showed up a big difference in code order.
A little research shows the different order in the code path makes no
difference whatsoever (cmdstream does not depend on the memstore pointer)
but it does solve that first panic.
To solve: similar problem with Z160 regwrite call from device_init which
assumes cmdwindow is all set up when it isn't.. Qualcomm's code is MUCH
simpler in this regard and may solve it by simply being so.
