11:29 <mwalle> does anybody know how to "read" that: https://github.com/Freescale/kernel-module-imx-gpu-viv/blob/master/kernel-module-imx-gpu-viv-src/hal/kernel/arch/gc_hal_kernel_hardware_func.c#L2566

11:36 <marex> mwalle: left-to-right, top-to-bottom ? :-)

11:37 <marex> mwalle: it is awful though

11:37 <mwalle> obviously its an expanded macro.. and it seems the vendor also supplies the correct bitmask for a field ;)

11:37 <marex> mwalle: I did experiment with clang formatter a while ago when trying to pull out information from Redpine signals example code drop

11:38 <mwalle> marex: mhh, i'd say there are three bitfields in the first assignment, 31:27, 15:0 and 25:16

11:38 <marex> mwalle: oh yeah, copy .clang-format from Linux kernel, then run clang-format -i <file>

11:39 <marex> mwalle: or just ... stick it into a C file, s@gctUINT32@uint32_t@ , compile and print the resulting value

11:39 <marex> mwalle: it is generated code from some HDL I guess

11:40 <mwalle> marex: mh, i'd have guessed they expanded their HERE_IS_SOME_NICE_NAME_BUT_WE_WANT_TO_KEEP_IT_A_SECRET(val) macro

11:40 <marex> nah, its probably just generated from HDL

11:42 <mwalle> marex: I'm not convinced :p esp. because its nicely formatted and looks like "*buffer = MACRO(bla);" judging from the indendation

11:44 <marex> mwalle: um ... notice those ( 0 ? 0 : 0 ) fields there

11:46 <mwalle> marex: yep, that looks like the beginning and end of the bitfields, like the first always evaluates to the highest and the second to the lowest; granted the macros might be autogenerated

11:47 <mwalle> i wonder about that "== 32 ? ~0U : something_else" though

11:49 <marex> mwalle: (var == val ? value-if-cond-true : value-if-cond-false) ?

11:49 <marex> mwalle: ~0U is 0xffffffff

11:49 <marex> mwalle: I feel like I'm stating the obvious, maybe I dont get the question and need some fresh air

11:50 <mwalle> marex: yeah, but why would you test for 32, I presume the values just range from 0 to 31

11:51 <mwalle> in any case, I'll try pattern matching by eyes with the proper kernel code ;)

11:51 <marex> mwalle: isnt it some addition in that conditional ?

11:52 <marex> add values and if they == 32, return value something, else return value somethingelse ?

11:52 <mwalle> ahhhh

11:52 <marex> because if the generated code does not have 7+1 there, but 31+1, it is 32 ?

11:52 <mwalle> 31:0 would be 32 then the mask will be all-ones

11:52 <mwalle> no?

11:53 <marex> there is some +1 in that expression

11:53 <mwalle> yeah so "31 - 0 + 1 == 32"

11:55 <mwalle> so they special case the all-ones bitfield, because their shift op in the else branch doesn't work for that edge case (?)

11:59 <mwalle> and there is still that mysterious "0 & ~(some long expression)"

12:02 <mwalle> so it's "configEx = (0 & 0xff) | (extSafeAddress & 0xff) | (0 & 0xff0000) |

12:02 <mwalle> argl

12:03 <mwalle> so it's "configEx = (0 & ~0xff) | (extSafeAddress & 0xff) | (0 & ~0xff0000) | ((extMtlb & 0xff) << 16);"

12:05 <mwalle> and that 0 might be used for manipulating only this field

12:05 <mwalle> eg if that 0 would be configEx, you'll be modifying 7:0 and 23:16

15:31 <laanwj> i remember there was some script (either in etna_viv or one or the other repos) that used a regexp to match vivante-isms like that and back-substitutes somewhat readable bitfield macro usage