newtrix - geekmaster's new tricks

[geekmaster]

Ahh... Freescale linux documentation package contains many files, including mx50_linux.pdf, chapter 14 "Electrophoretic Display Controller (EPDC) Frame Buffer Driver".

RTFM is *SO* much easier when you know *WHICH* FM to read!

[knc1]

As in:
http://www.freescale.com/webapp/sps/...?code=IMX50_SW

EDIT: I posted that link prior to checking its content, although not the exact manual, that page link might still be useful to someone.
So I didn't not delete the O.T. link above.

Ref in:
https://www.mobileread.com/forums/sho...2&postcount=18

[geekmaster]

Originally Posted by knc1

As in:
http://www.freescale.com/webapp/sps/...?code=IMX50_SW

EDIT: I posted that link prior to checking its content, although not the exact manual, that page link might still be useful to someone.
So I didn't not delete the O.T. link above.

Ref in:
https://www.mobileread.com/forums/sho...2&postcount=18

Yes, that MR ref link is what told me where to look. I found it indirectly via google, and actually ended up at the .mobi version of the page.

The problem is that I tried all the options and variations given in the manual and NONE of them work in 5.1.0. Using strace on eips shows that it is setting an undocumented bit in the call, but when I set that bit it does not help either.

The ONLY way I can trigger updates on 5.1.0 is eips '' even though the ioctl as documented in the manual works on 5.0.4 main and diags, and also on the K4 diags.

The problem with eips is that I want to do small area updates, and updates from alternate overlay buffers, and although eips complains about "invalid overlay image" for some options, I do not know how to use it for that purpose.

[geekmaster]

The "marker" I mentioned in a previous post is an arbitrary value you set in an update call, which gets queued up to 20 levels deep, then you can later set a bit for a BLOCKING call waiting for io competion on an update-in-progress using the specified update marker.

There are 16 pixel processors updating those regions in parallel, and although each region can take up to 300 msec to complete, the manual says the eink display can be updated at 48Hz (16 non-overlapping regions @ 300 msec each).

So for the best control, you need to identify your updates with unique markers, then wait on each one before updating again. I suspect you identify regions like specific buttons.

EDIT: Above info is for Freescale eink controller embedded in i.MX508 SoC used in K4 and K5. The K3 uses an external epson broadsheet controller chip with much less capability.

[geekmaster]

Perhaps the reason I cannot find any of the useful lab126 custom ioctl stuff in the gpl code is because there is a large folder full of PATCHES, and a script to apply them... Maybe the code would make more sense if it was pathched to match what is in the kindle... ?

EDIT: No, those patches were already applied. They are for patching the generic kernel code if you download it. Downloading 5.1.0 source now, to see if diffs that could break the ioctl(), or at least what changed... Perhaps one of their patches makes it incompatible with the freescale reference manual...

[knc1]

From your description of what "MARKER" does (acts like a token to select which one of the multiple pix processing "jobs" to send the ioctl to)...

Maybe the only change is that before 5.1 there was only one MARKER(token) in use by the Amazon application - the one which you where using in your code.

And that now, starting with 5.1 the Amazon application is using more than that single MARKER(token).
I.E: Maybe 5.1 just marks the point where the Amazon application started to use the multiple pixel processing feature.
Not a actual change in the source code of how the ioctl() is handled, a change in the propriatary Amazon code.

Just some additional thoughts, in case you don't find anything of significance in the 5.1 diff's

[geekmaster]

Originally Posted by knc1

From your description of what "MARKER" does (acts like a token to select which one of the multiple pix processing "jobs" to send the ioctl to)...

Maybe the only change is that before 5.1 there was only one MARKER(token) in use by the Amazon application - the one which you where using in your code.

And that now, starting with 5.1 the Amazon application is using more than that single MARKER(token).
I.E: Maybe 5.1 just marks the point where the Amazon application started to use the multiple pixel processing feature.
Not a actual change in the source code of how the ioctl() is handled, a change in the propriatary Amazon code.

Just some additional thoughts, in case you don't find anything of significance in the 5.1 diff's

According to the freescale documentation, the update marker is just a unique arbitrary value that you select when you do an update call that does not have the "wait for completion" bit set. Later when (if) you want to wait for a specific update to complete, you call a "wait for update completion" ioctl call with the unique marker that was used on the update call you want to wait for.

The only exception is marker value zero. According to several different websites, update marker value zero has a special use -- it crashes the driver.

[knc1]

Originally Posted by geekmaster

The only exception is marker value zero. According to several different websites, update marker value zero has a special use -- it crashes the driver.

An interesting feature to include in the driver.
What symbol name did they give that value in the header file?
ECRASHEBURN ??
FLAMEOUT ??

[geekmaster]

They added this new "anti-crash-and-burn" code to the 5.1.0 eink kernel driver:

/* 0 is an invalid update_marker value */
if (update_marker == 0) return -EINVAL;

They added a lot more mutex locks, and for existing locks they moved a chunk of code to the OTHER side of the lock (either before or after) in many places. And they have a lot more eink powerup and powerdown calls scattered in it too...

[geekmaster]

The new 5.1.0 eink drivers add a new eink update mode. It is 1bbp (pure black and pure white) and they named it mode AU, which in the comments calls it "ANIMATION UPDATE MODE". Hmm... I wonder if they got that idea from the mobileread forums...

EDIT: I found a reference to "animation update mode" in eink_panel.c for 5.0.0 -- apparently they added it to more source modules now, so perhaps they plan to use it some time in the future. It is still missing from mxcfb.h though...

[geekmaster]

I see that the eink waveform modes in the mxcfb.h file DO NOT match the new update modes in the eink_panel.c file. Sadly, the new mode was added to the MIDDLE of the table, not the end. Perhaps this is why I can do ioctl() eink updates on everything EXCEPT 5.0.1, and why eips is setting an extra "undefined" bit in the ioctl() call...

EDIT: I see that they added this to magic.h:

#define UNIONFS_SUPER_MAGIC 0xf15f083d

New unionfs support?

[knc1]

@GM - I am sure you know this one, but for some of the other readers of the tech. details in this thread:

[geekmaster]

Originally Posted by knc1

@GM - I am sure you know this one, but for some of the other readers of the tech. details in this thread:

Actually, I was not familiar with that cartoon or the "linux Poker" idiom.

Is that Richard Stallman in the left chair? And the guy with his back to the "camera" looks a lot like Bill Gates, right? But then who are the other two guys?

[geekmaster]

I discovered (the hard way, later confirmed in GPL source code) that although the K4 and K5 use an 8-bit eink framebuffer, the pixels inside it must still be packed two pixels per byte JUST LIKE for the K3 and earlier. The only difference is that each byte must contain the SAME 4-bit value in both packed pixel positions. In other words, the values in these bytes are 4-bit values multiplied by 17 (which copies the bottom 4-bits to the top 4-bits).

According to GPL source code for the K5 eink drivers, some eink panels REQUIRE that the bottom 4-bits be identical to the top 4-bits or strange behavior can be expected (as can be seen in my screenshots for my paldemo program in another thread).

I added the "(c>>4)*17" term to my blitter function and it works a lot better now...

That also explains why we need to dither the framebuffer even for "8-bit grayscale" mode...

Also, when I updated it, I converted my dither tables to logical expressions using Karnaugh maps, and added the dither terms to my "dither/pack/blit" function. Interestingly, it now runs FASTER than when it used a dither lookup table -- cache effects, no doubt. Modern CPUs are MUCH faster than memory accesses in many cases. Back in the day, pre-computed lookup tables were THE WAY to optimize code, but these days it is often much faster to do real-time computation instead of memory accesses, even on embedded processors like we have in the kindles.

[knc1]

Originally Posted by geekmaster

Actually, I was not familiar with that cartoon or the "linux Poker" idiom.

Is that Richard Stallman in the left char? And the guy with his back to the "camera" looks a lot like Bill Gates, right? But then who are the other two guys?

Think: "Apple"
This is a really old cartoon, I forget how old but probably mid-90s.