ResLock stuff

[g3gg0]

i digged a bit into ResLock stuff and will describe how i think it works.

Code: [Select]

struct struc_LockEntry
{
  char *name;
  int status;
  int semaphore;
  int some_prev;
  int some_next;
  unsigned int *pResource;
  int resourceEntries;
  void (*cbr)(struct struc_LockEntry *lockEntry, void *cbr_priv);
  void *cbr_priv;
};

struct struc_LockEntry *CreateResLockEntry(uint32_t *resIds, resIdCount);
unsigned int LockEngineResources(struct struc_LockEntry *lockEntry);
unsigned int UnLockEngineResources(struct struc_LockEntry *lockEntry);
unsigned int AsyncLockEngineResources(struct struc_LockEntry *lockEntry, void (*cbr)(struct struc_LockEntry *lockEntry, void *cbr_priv), void *cbr_priv);

LockEngineResources:
Lock a previously allocated LockEntry and its associated devices

UnLockEngineResources:
Unlock a previously allocated LockEntry and its associated devices

CreateResLockEntry:
register a lock that will use semaphores to lock all the resources specified in a list.
when registering your lock, the resIds[] is a list of resources to be locked.
the number of entries in this list is passed as second parameter.
initial state of the lock is unlocked.

resId format:
resId = (block << 16) | (entry)

entry specifies the exact "device" in the given block, if any.
blocks are one of those:
 0x00 = EDMAC[0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x20, 0x21]
 0x01 = EDMAC[0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x28, 0x29, 0x2A, 0x2B]
 0x04 = HEAD
 0x36 = encdrwrap
 0x37 (max)
 (...to be continued)

e.g. resId 0x1000C is block 0x01 and entry 0x0C. This is EDMAC 0x28 being locked whenever LockEngineResources is called with the LockEntry.

[a1ex]

around hCopyLumaLockKey: 00010001 00000000 00030006 00020006

code around this uses EDMAC 9, 0 and connection 6 for both read and write. Therefore, blocks 2 and 3 can be read/write connections or viceversa?

LV_ResUnLockTripleRamClearPass seems to confirm that block 2 is for write connections and 3 is for read:
00030006 00030007 00030003 00020006 00020007 00020004 and others
connect calls: r/w for connections 6 and 7, r for 3 and w for 4.

[g3gg0]

updated with information about AsyncLockEngineResources from maqs

[a1ex]

ResLock entries used by ProcessPathForFurikake:

Code: [Select]

5D3 113:
*** LockEngineResources(65d8c8) x8 from ff3c3728:
     1)        1 (write channel 0x1)
     2)    1000c (read channel 0x28)
     3)    50002 (?)
     4)    50005 (?)
     5)    5001d (?)
     6)    5001f (?)
     7)    20010 (write connection 0x10)
     8)    30001 (read connection 0x1)

60D:
*** CreateResLockEntry(2cd58, 8) from ff3c1008:
     1)        3 (write channel 0x3)
     2)    10002 (read channel 0xa)
     3)    50002 (?)
     4)    50005 (?)
     5)    5001d (?)
     6)    5001f (?)
     7)    20010 (write connection 0x10)
     8)    30001 (read connection 0x1)

so, block 5 must cover PACK16, DSUNPACK, DEF(C) and WDMAC16 modules?

My current hypothesis:

Code: [Select]

    50002 (DSUNPACK?)
    50003 (ADUNPACK?)
    50005 (DEFC?)
    50006 (DARK?)
    5001d (PACK16/WDMAC16)
    5001f (PACK16/WDMAC16)