[linux-sunxi] [PATCH 3.4] arm: Use top 4 bits of machine id for u-boot compatibility check

[Siarhei Siamashka]

This implements ensuring compatibility between the mainline u-boot and the 
legacy
sunxi-3.4 kernels, proposed earlier at
http://lists.denx.de/pipermail/u-boot/2014-October/191777.html

Signed-off-by: Siarhei Siamashka 
---
 arch/arm/boot/compressed/head.S | 56 -
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 77a716b..d1c39b6 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -133,7 +133,61 @@ start:
.word   start   @ absolute load/run zImage 
address
.word   _edata  @ zImage end address
  THUMB(.thumb  )
-1: mov r7, r1  @ save architecture ID
+1:
+
+/**/
+/*
+ * This is a hack to implement the compatibility check between the mainline
+ * U-Boot and the legacy sunxi-3.4 kernel. We interpret the top 4 bits of the
+ * machine id as a some sort of a machine id compatibility revision number.
+ *
+ * The expected workflow:
+ *
+ * 1. U-Boot introduces some changes, which may expose some serious bug in
+ *the sunxi-3.4 kernel. For example, changes the PLL5P clock speed.
+ *So that the kernel needs bugfixes like:
+ *https://github.com/linux-sunxi/linux-sunxi/commit/9a1cd034181af628d41
+ *https://github.com/linux-sunxi/linux-sunxi/commit/ade08aa6e5249a9e75a
+ *
+ *And U-Boot bumps the compatibility revision number in the machine id at
+ *the same time. For example, changes the 'include/configs/sun4i.h' from
+ *
+ *#define CONFIG_MACH_TYPE 4104
+ *
+ *into
+ *
+ *#define CONFIG_MACH_TYPE_COMPAT_REV 1
+ *#define CONFIG_MACH_TYPE (4104 | (CONFIG_MACH_TYPE_COMPAT_REV << 28))
+ *
+ * 2. The sunxi-3.4 kernel applies the necessary bugfixes to the code and also
+ *bumps the CONFIG_MACH_TYPE_COMPAT_REV number in this file in the kernel.
+ *
+ * The effect of this is the following. If somebody tries to boot some old
+ * kernel with the new incompatible U-Boot, then the top bits of the machine
+ * id will be non-zero and the kernel will refuse to load because of the
+ * machine id mismatch. The appropriate error message will show on the serial
+ * console, and this error message is very much googlable. The linux-sunxi wiki
+ * can contain the necessary explanations about how to resolve this situation.
+ *
+ * If somebody tries to boot an appropriately fixed revison of the sunxi-3.4
+ * kernel with the new U-Boot, then the top 4 bits of the machine id will be
+ * cleared by the code in this assembly file after passing the revision check.
+ *
+ * If somebody tries to boot an appropriately fixed revison of the sunxi-3.4
+ * kernel with a very old U-Boot (for example, the legacy u-boot-sunxi), then
+ * everything will be fine too.
+ */
+   #define CONFIG_MACH_TYPE_COMPAT_REV 1
+
+   /* Extract the machine id compatibility revision number */
+   mov r7, r1, lsr #28
+   cmp r7, #CONFIG_MACH_TYPE_COMPAT_REV
+   /* Clear the top 4 bits if the compatibility check succeeded */
+   bicle   r1, r1, #(0xF << 28)
+
+/**/
+
+   mov r7, r1  @ save architecture ID
mov r8, r2  @ save atags pointer
 
 #ifndef __ARM_ARCH_2__
-- 
2.0.5

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [UBOOT] Both Linux-Sunxi and Mainline Uboot have issues

[Siarhei Siamashka]

On Thu, 19 Feb 2015 14:57:14 +0100
Hans de Goede  wrote:

> Hi,
> 
> On 19-02-15 13:38, Siarhei Siamashka wrote:
> > On Wed, 18 Feb 2015 22:29:07 -0800 (PST)
> > TsvetanUsunov  wrote:
> >
> >> Hi
> >>
> >> For A13-OLinuxino till now we conservatively used the Linux-Sunxi uboot,
> >> but we recently got new lot of Samsung memories and we decided to tweak
> >> some parameters for this DDR in Linux-Sunxi uboot and found problems.
> >> As this uboot is with status not maintained anymore I will not discuss the
> >> problems, as probably no one will spend time on it,
> 
> 
> 
> >> The PLL5 and PLL6 values are changed and this cause problems, this is what
> >> we found so far:
> 
> 
> 
> >> 1. mainline u-boot
> >> =
> >> 1.1 pll5
> >> address 0x01c20020, value 0xb1049091 - P=1, N=16, K=2, M=2.
> >>   The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*16*2/2 = 384MHz
> >> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/1 = 768MHz  -
> >> This high frequency cause LCDs connected to the board to flicker
> >
> > Yes, this was already known. And had been addressed a long time ago.
> > Hans has a more detailed reply, so I'm not going to duplicate it.
> >
> >> 1.2 pll6
> >> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1
> 
> This is not the value set by u-boot, u-boot sets this to
> 0xA1009911
> 
> >>   The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz
> 
> And this formula from the A13 user manual is wrong I've run several
> tests and the formula from the A10/A20 user manual, as used by the
> allwinner kernel sources, upstream u-boot and upstream kernel:
> 
> PLL6 = (24MHz*N*K)/2
> 
> Is the correct one. This means that what u-boot is doing:
> 
> PLL6 = 0xA1009911, MBUS = 0x8101
> 
> Results in PLL6 = 600 MHz , MBUS = 600 / 2 = 300 MHz so upstream
> u-boot actually gives you more MBUS bandwidth to work with, as
> intended.
> 
> But then the linux-sunxi-3.4 kernel comes along and sets PLL6 to:
> 0xA1009900 which translates to 300 MHz (in both the wrong and
> correct formula) and you end up with an MBUS of only 150 MHz.
> 
> 
> 
> >> 1.3 MBUS clock
> >> address 0x01c2015c, value 0x8101  - MBUS clock source is PLL6/2 = 300/2
> >> = 150MHz - This is connected to PLL6 setup, at this 150 Mhz the board cant
> >> play video smoothly and sometimes drop video packets when the video is
> >> playing
> >
> > Right. Having a reasonably fast MBUS clock speed is very important for
> > performance.
> >
> >>   2. sunxi u-boot
> >> =
> >> 1.1 pll5
> >> address 0x01c20020, value 0xb1049091 - P=2, N=17, K=2, M=2.
> >>   The PLL5 output for DDR = (24MHz*N*K)/M. DDR=24*17*2/2 = 408MHz
> >> The PLL5 output for other module = (24MHz*N*K)/P. DDR=24*16*2/2 = 408MHz  -
> >> this frequency was OK, There is no problem with LCD flickering, why the
> >> frequency increase was necessary?
> >> 1.2 pll6
> >> address 0x01c20028, value 0xA1009900 - N=25, K=1, M=1
> >>   The PLL6 output is (24MHz*N*K)/M/2 = 24*25*1/1/2 = 300MHz
> >
> > Thanks a lot for finding and reporting this particular problem.
> >
> > Based on a quick look, the most likely culprit seems to be the
> > 'c' function in u-boot, which is providing wrong
> > information to the DRAM code. But Hans is already working on a
> > fix, so I'm not going to get involved yet.
> 
> Nope, the user manual for A13 is wrong (see above).

You are right, thanks.

I felt that something was odd, because I did run some memory benchmarks
on an A13-OLinuXino-Micro board earlier (with the mainline kernel) an
did not notice any PLL6 related anomalies at that time:

http://linux-sunxi.org/A10_DRAM_Controller_Performance

The "300 MHz MBUS" results (MBUS is clocked from PLL6) are more or less
consistent with the others (when MBUS is clocked from PLL5P).

> > Additionally, the sunxi-3.4 kernel is trying to re-configure PLL6 in
> > 'arch/arm/mach-sun5i/clock/clock.c', which is a bit of a mess. As you
> > have the problem, most likely it also ends up being 300MHz there.
> > Probably the sunxi-3.4 kernel should not touch PLL6 at all and keep
> > the settings from u-boot.
> 
> Oh, thanks for pointing that out, that explains why Tsvetan is seeing
> 0xA1009900 for the PLL6 setting, and explains his problem (see analysis
> above).
> 
> I've attached a patch which should fix this, Tsvetan note that you
> need to build with old kernel compatibility enabled for this fix to
> work, as explained in my previous mail. Please let me know if this
> fixes things then I'll push it upstream ASAP.
> 
> And someone should also write a kernel patch for the linux-sunxi kernel
> to not touch pll6 on sun5i.

I have looked at it a bit. And now I don't feel like touching anything
PLL6 related in the sunxi-3.4 kernel. The A20 and A13 manuals contain
some rather confusing information about PLL6 (all these PLL6, PLL6*2,
PLL6/2, the M divisor, etc.). The sunxi-3.4 kernel sources are rather
convoluted too.

So I'm not quite sure whether changing PLL6 from 300MHz to 600MHz (by
kee

Re: [linux-sunxi] simplefb and gpio_backlight?

[Jens Thiele]

Hans de Goede  writes:

> Hi,
>
> On 19-02-15 22:09, Jens Thiele wrote:
>> would dpms-like functionality work using simplefb with gpio_backlight
>> (CONFIG_BACKLIGHT_GPIO) if one provides correct information in the .dts
>> file?
>
> I believe that that would depend on your desktop environments, the
> sysfs backlight interface is typically used by the desktop environment
> and not by X itself, so if the desktop environment not only makes X server
> calls to do dpms but also sets the backlight off then yes it should work.

ah, yes thanks!
would have to take a closer look (again) - but yes, afair x fbdev used
something like:
int fd=open("/dev/fb0",O_RDWR)
ioctl(fd, FBIOBLANK, ...)

as i just use x+wm (no desktop environment) i wouldn't gain that much
(but yes, it would be nicer anyway)

> It would be better to use the pwm backlight devicetree binding though,
> that way we can actually control brightness, and the upstream kernel
> recently has gotten support for the pwm pins on the Axx SOCs.
>
> I would certainly welcome patches adding pwm backlight devicetree nodes
> to supported devices, since we will need those in the future anyways.

Brightness control would be nice. But I will have to learn how this is
supposed to work, first.

> Note that a pwm backlight devicetree node will give you both a brightness
> and a bl_enable attribute, since not all desktop environments will do the
> right thing, we could als patch the fbdev and/or turbfo fb drivers to
> look for a backlight device in sysfs and toggle its bl_enable setting
> when dpms is turned on/off, I believe that that would be the best way
> to fix this until we get a kms driver.

ok, will head into the pwm backlight direction.
thank you very much, again!

greetings, jens

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] linux 3.19, sunxi-mmc: a20-olinuxino-micro second sd card slot: mmc1: card never left busy state

[Jens Thiele]

I _sometimes_ get:
[ 2519.090006] mmc1: card never left busy state
[ 2519.094302] mmc1: error -110 whilst initialising SD card
[ 2519.100518] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 1, RTO !!

seems to depend on SD card / microSD<->SD adapter?! Don't see a clear
pattern, yet.
hardware problem? anybody else seeing this?

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Communication with Allwinner

[mike . valk]

On Tuesday, February 17, 2015 at 6:56:13 PM UTC+1, Manuel Braga wrote:
> On Tue, 17 Feb 2015 12:00:27 +0200 Simos Xenitellis
> > 
> > At http://www.phoronix.com/scan.php?page=news_item&px=MTg4Mjg it
> > mentions that Intel is doing Linux work on the PowerVR VXD392 VPU (as
> > is used on Baytrail).
> > Is the VPU similar to what exists on the A80?
> 
> What is a VPU?, wikipedia says that a VPU is another term for GPU.
> And at the end this is huge confusion, that make people believe that for
> have hardware accelerated video playback is a requirement to have and
> use the GPU.

CPU : Central Processing Unit
GPU : Graphics Processing Unit
VPU : Video Processing unit

GPU, VPU are specialized processing unit/cores for specific workloads to unload 
the CPU or gain performance which is out of reach for a general purpose PU 

GPGPU: General purpose GPU. -> OpeCL etc. 

Not that confusing IMHO, A little archaic perhaps. 

> 
> This is wrong, it come from the fact that in the PC(x86) world are used
> graphic cards that are actually are (gpu + display engine + video codec
> engine), so this is 3 kind of difference hardware types put together in
> this some called graphic card.
> As this graphic card is one identity, it is usually all handled by the
> same software driver.

In x86 land we started with CGA, EGA and VGA cards. Which were a little more 
than "Diplay Controllers". And were called "video cards" which was used pre 
x68. Because the C64 etc used a "composite video signal" to interface with 
tv's/display's

Than came the "graphics accelerators", which would offload graphics processing 
from the CPU and send results back to CPU or directly to the display 
controller. 

http://commons.wikimedia.org/wiki/File:VideoLogic_Apocalypse_3Dx.jpg#mediaviewer/File:VideoLogic_Apocalypse_3Dx.jpg
An ancient PowerVR GPU for x86 without the display controller.


Because the chain CPU->GPU/Display Controller->Display. The display controller 
became embedded to the GPU cards.

Apart from that the came MPEG cards wich would decode MPEG video and 'stream' 
the result back to the system.

Because video decoding, VPU, should at the same place as the GPU the chain is 
broken. 
CPU -> VPU -> CPU -> GPU -> Display

Thus most GPU cards now have a video decoder onboard as well.
CPU -> VPU/GPU/Display Controller -> Display

> 
> In ARM case this is not the case,
> http://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/

The driver issue is more a "Mix and Match" issue. In x86 the GPU/VPU/Display 
Controller are usually on one device. The set is alway the same and using a 
single driver makes sense. 

In ARM land the CPU,GPU,VPU,Display Controller are mixed and matched on a 
single device. Thus a single driver does not make sense. Hence the need for 
seperate drives and some glue (DeviceTree). Also the parts are no longer 
aligned but are placed side by side on the same memory(bus).

Luc has mostly figured out the Mali GPU and is now working on the display 
controller.


For A312 and A80 they chose Imagination's PowerVR as the GPU, I don't know if 
they chose the use Imagination parts for the Display Controller and VPU

> 
> Please lets use a more correct term, that creates no ambiguity of what
> we are speaking about.
> 
> Video Codec Engine, is the correct name for this type hardware in the
> sunxi(allwinner) case. This is the hardware to use for decoding and
> encoding of video codecs.

codec comes from coding and decoding. The VPU does more:
ColorCode conversion
Scaling
etc.

So calling it a mere codec is not more accurate.

"Media Processing Unit" I think is better. It whould also cover the audio codec 
and remove the confusion with "video cards"

But the Market/Marketing is stuck on the "video" term. 

> 
> And in sunxi, sometimes called also "cedar engine" and it is the *same*
> Video Codec Engine in all allwinner socs.
> A10/A10s/A13/A20/A23/A31/A31s/A33/A80/A80T/A83T/H3/H8
> (with some minor and or new feature hardware versions)
> 
> How do i know?
> From the kernel source code make available from allwinner.
> 
> To the best of what could be found, this Video Codec Engine is a custom
> design made by www.chipsbank.com for allwinner. And this makes believe
> that is allwinner propriety and only used in allwinner socs.

That's intersting. I thought, altough it seemed odd me, the VPU was an in house 
development of Allwinner.

So the CedarX code may also be property of chipsbank.

Does chipsbank provide "open" documentation?



-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] linux 3.19, sunxi-mmc: a20-olinuxino-micro second sd card slot: mmc1: card never left busy state

[Jens Thiele]

Jens Thiele  writes:

> seems to depend on SD card / microSD<->SD adapter?! Don't see a clear
> pattern, yet.
> hardware problem? anybody else seeing this?

really looks like a problem with one SD adapter (could reproduce with my
laptop).

sorry for the noise

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Question about libvdpau-sunxi

[Simo Xefil]

Hello,

I've installed 'libvdpau-sunxi' on an A20 board having mali400 gpu.
Until here all ok. In this way I'm able to play video smooth using HW 
decoding vdpau with mplayer or mpv.
To do that I need to have an X11 display, or I get an error. Is there a way 
to obtain the same result sendig the video to framebuffer in a 
virtual-console without X11 or I'm asking something impossible?
AFAYK in mplayer the "-vc" is used to set the video codec, and it's set-up 
to be 'ffmpeg12vdpau,ffh264vdpau'.
The "-vo" is used to set the video output device. Following your 
documentation I need to set it to "vdpau".
Would it be possible to send it so to framebuffer or modified sdl2 that 
uses framebuffer?
I know could be more an mplayer/mpv-mailinglist question but it's only to 
know it it's something that makes sense.

Thanks!

Simon

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Question about libvdpau-sunxi

[Andreas Baierl]

Am 20.02.2015 um 14:47 schrieb Simo Xefil:


Hello,

I've installed 'libvdpau-sunxi' on an A20 board having mali400 gpu.
Until here all ok. In this way I'm able to play video smooth using HW 
decoding vdpau with mplayer or mpv.
To do that I need to have an X11 display, or I get an error. Is there 
a way to obtain the same result sendig the video to framebuffer in a 
virtual-console without X11 or I'm asking something impossible?
libvdpau-sunxi as vdpau in general depend on X, so no, it's not possible 
to directly access framebuffer.
AFAYK in mplayer the "-vc" is used to set the video codec, and it's 
set-up to be 'ffmpeg12vdpau,ffh264vdpau'.
The "-vo" is used to set the video output device. Following your 
documentation I need to set it to "vdpau".
Would it be possible to send it so to framebuffer or modified sdl2 
that uses framebuffer?
I know could be more an mplayer/mpv-mailinglist question but it's only 
to know it it's something that makes sense.


Thanks!

Simon

Regards
Andreas

--
You received this message because you are subscribed to the Google 
Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to linux-sunxi+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Video engine talking (was: Communication with Allwinner)

[Manuel Braga]

Hi,

On Fri, 20 Feb 2015 03:03:08 -0800 (PST) mike.v...@gmail.com wrote:
> On Tuesday, February 17, 2015 at 6:56:13 PM UTC+1, Manuel Braga wrote:
> > On Tue, 17 Feb 2015 12:00:27 +0200 Simos Xenitellis
> > > 
> > > At http://www.phoronix.com/scan.php?page=news_item&px=MTg4Mjg it
> > > mentions that Intel is doing Linux work on the PowerVR VXD392 VPU
> > > (as is used on Baytrail).
> > > Is the VPU similar to what exists on the A80?
> > 
> > What is a VPU?, wikipedia says that a VPU is another term for GPU.
> > And at the end this is huge confusion, that make people believe
> > that for have hardware accelerated video playback is a requirement
> > to have and use the GPU.
> 
> CPU : Central Processing Unit
> GPU : Graphics Processing Unit
> VPU : Video Processing unit
> 
> GPU, VPU are specialized processing unit/cores for specific workloads
> to unload the CPU or gain performance which is out of reach for a
> general purpose PU 
> 
> GPGPU: General purpose GPU. -> OpeCL etc. 
> 
> Not that confusing IMHO, A little archaic perhaps. 

Tell that to wikipedia, for them the V is not for "video", but "visual".
http://en.wikipedia.org/w/index.php?title=Video_processing_unit&redirect=no

> 
> > 
> > This is wrong, it come from the fact that in the PC(x86) world are
> > used graphic cards that are actually are (gpu + display engine +
> > video codec engine), so this is 3 kind of difference hardware types
> > put together in this some called graphic card.
> > As this graphic card is one identity, it is usually all handled by
> > the same software driver.
> 
> In x86 land we started with CGA, EGA and VGA cards. Which were a
> little more than "Diplay Controllers". And were called "video cards"
> which was used pre x68. Because the C64 etc used a "composite video
> signal" to interface with tv's/display's
> 
> Than came the "graphics accelerators", which would offload graphics
> processing from the CPU and send results back to CPU or directly to
> the display controller. 
> 
> http://commons.wikimedia.org/wiki/File:VideoLogic_Apocalypse_3Dx.jpg#mediaviewer/File:VideoLogic_Apocalypse_3Dx.jpg
> An ancient PowerVR GPU for x86 without the display controller.
> 
> 
> Because the chain CPU->GPU/Display Controller->Display. The display
> controller became embedded to the GPU cards.
> 
> Apart from that the came MPEG cards wich would decode MPEG video and
> 'stream' the result back to the system.
> 
> Because video decoding, VPU, should at the same place as the GPU the
> chain is broken. CPU -> VPU -> CPU -> GPU -> Display
> 
> Thus most GPU cards now have a video decoder onboard as well.
> CPU -> VPU/GPU/Display Controller -> Display
> 
> > 
> > In ARM case this is not the case,
> > http://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/
> 
> The driver issue is more a "Mix and Match" issue. In x86 the
> GPU/VPU/Display Controller are usually on one device. The set is
> alway the same and using a single driver makes sense. 
> 
> In ARM land the CPU,GPU,VPU,Display Controller are mixed and matched
> on a single device. Thus a single driver does not make sense. Hence
> the need for seperate drives and some glue (DeviceTree). Also the
> parts are no longer aligned but are placed side by side on the same
> memory(bus).
> 
> Luc has mostly figured out the Mali GPU and is now working on the
> display controller.

Thanks for helping make things more clear.


> 
> For A312 and A80 they chose Imagination's PowerVR as the GPU, I don't
> know if they chose the use Imagination parts for the Display
> Controller and VPU

For the "VPU", there isn't a reason why it is not the same as from all
other socs. Moreover in the datasheets the features match in equal mode.
Also same simple kernel driver. 

But as i don't own A31*/A80 devices, i can't take the 30 minutes that
would take to make this clear without any doubt.


> 
> > 
> > Please lets use a more correct term, that creates no ambiguity of
> > what we are speaking about.
> > 
> > Video Codec Engine, is the correct name for this type hardware in
> > the sunxi(allwinner) case. This is the hardware to use for decoding
> > and encoding of video codecs.
> 
> codec comes from coding and decoding. The VPU does more:
> ColorCode conversion
> Scaling
> etc.
> 
> So calling it a mere codec is not more accurate.
> 
> "Media Processing Unit" I think is better. It whould also cover the
> audio codec and remove the confusion with "video cards"

http://linux-sunxi.org/Category:Video_Engine

Let's call it "Media Accelerate Video Engine"


> 
> But the Market/Marketing is stuck on the "video" term. 

Allwinner is simply calling "video engine".


> 
> > 
> > And in sunxi, sometimes called also "cedar engine" and it is the
> > *same* Video Codec Engine in all allwinner socs.
> > A10/A10s/A13/A20/A23/A31/A31s/A33/A80/A80T/A83T/H3/H8
> > (with some minor and or new feature hardware versions)
> > 
> > How do i know?
> > From the kernel sourc

Re: [linux-sunxi] Question about libvdpau-sunxi

[Andreas Baierl]

Am 20.02.2015 um 16:07 schrieb X3fil:


I was thinking a sort of decode via "-vc" on vdpau and write to 
framebuffer via "-vo" on another device like framebuffer or sdl2, 
btw...Ok



I think this will not work ootb.
See http://mpv.io/manual/master/#video
"vdpau:requires --vo=vdpau or --vo=opengl (Linux only)"

Regards
Andreas


Thanks Andreas!

Simon

Il 20/02/2015 14:52, Andreas Baierl ha scritto:

Am 20.02.2015 um 14:47 schrieb Simo Xefil:


Hello,

I've installed 'libvdpau-sunxi' on an A20 board having mali400 gpu.
Until here all ok. In this way I'm able to play video smooth using 
HW decoding vdpau with mplayer

or mpv.
To do that I need to have an X11 display, or I get an error. Is 
there a way to obtain the same
result sendig the video to framebuffer in a virtual-console without 
X11 or I'm asking something

impossible?
libvdpau-sunxi as vdpau in general depend on X, so no, it's not 
possible to directly access framebuffer.
AFAYK in mplayer the "-vc" is used to set the video codec, and it's 
set-up to be

'ffmpeg12vdpau,ffh264vdpau'.
The "-vo" is used to set the video output device. Following your 
documentation I need to set it to

"vdpau".
Would it be possible to send it so to framebuffer or modified sdl2 
that uses framebuffer?
I know could be more an mplayer/mpv-mailinglist question but it's 
only to know it it's something

that makes sense.

Thanks!

Simon

Regards
Andreas

--
You received this message because you are subscribed to the Google 
Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to
linux-sunxi+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to a topic in 
the Google Groups "linux-sunxi"

group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/linux-sunxi/IlONGzYINYg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
linux-sunxi+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.




--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] simplefb and gpio_backlight?

[Chen-Yu Tsai]

On Fri, Feb 20, 2015 at 5:24 PM, Jens Thiele  wrote:
> Hans de Goede  writes:
>
>> Hi,
>>
>> On 19-02-15 22:09, Jens Thiele wrote:
>>> would dpms-like functionality work using simplefb with gpio_backlight
>>> (CONFIG_BACKLIGHT_GPIO) if one provides correct information in the .dts
>>> file?
>>
>> I believe that that would depend on your desktop environments, the
>> sysfs backlight interface is typically used by the desktop environment
>> and not by X itself, so if the desktop environment not only makes X server
>> calls to do dpms but also sets the backlight off then yes it should work.
>
> ah, yes thanks!
> would have to take a closer look (again) - but yes, afair x fbdev used
> something like:
> int fd=open("/dev/fb0",O_RDWR)
> ioctl(fd, FBIOBLANK, ...)
>
> as i just use x+wm (no desktop environment) i wouldn't gain that much
> (but yes, it would be nicer anyway)
>
>> It would be better to use the pwm backlight devicetree binding though,
>> that way we can actually control brightness, and the upstream kernel
>> recently has gotten support for the pwm pins on the Axx SOCs.
>>
>> I would certainly welcome patches adding pwm backlight devicetree nodes
>> to supported devices, since we will need those in the future anyways.
>
> Brightness control would be nice. But I will have to learn how this is
> supposed to work, first.

I have 2 untested branches with pwm backlight for the 2 tablets I have:

https://github.com/wens/linux/tree/sun5i-hsg-h702-pwm-backlight
https://github.com/wens/linux/tree/sun8i-pwm-backlight

The DT bits are complete, as support for the AXPs is missing.
(regulators for AXP221/223, GPIOs for AXP209)

This should give you a sample to work on.

ChenYu

>> Note that a pwm backlight devicetree node will give you both a brightness
>> and a bl_enable attribute, since not all desktop environments will do the
>> right thing, we could als patch the fbdev and/or turbfo fb drivers to
>> look for a backlight device in sysfs and toggle its bl_enable setting
>> when dpms is turned on/off, I believe that that would be the best way
>> to fix this until we get a kms driver.
>
> ok, will head into the pwm backlight direction.
> thank you very much, again!
>
> greetings, jens
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel

['Al Thomas' via linux-sunxi]

From: Steven Saunderson 
 Sent: Friday, 20 February 2015, 1:50
 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel
   Thanks for the .dts patch info.  I've updated my .dts but it doesn't help 
with the firmware load.  I haven't seen any mainline version of the AP6210 
driver.  Maybe it's not required.  At the moment I'm running the brcmfmac 
driver for wifi and just the standard bt-uart driver for BT.

OK, useful to know hci_uart is the kernel module to use here.


The good news is that bluetooth works with 3.19 once I've managed to load the 
firmware.  

I presume that is full radio communication, e.g. a bluetooth keyboard (HID 
profile) and not just communication with the controller over UART?


But I don't like my current hack with the BT_RESET pin.  I'll see if I can 
monitor the uart2 TX line before the port is opened.

I've done a bit of digging in the docs and have another theory - that BT_WAKE 
needs to be high.

Page 30 of the bluetooth chip manual ( 
http://dl.linux-sunxi.org/users/turl/20710-DS103-RDS.pdf ) says the default 
baud rate is 115200. So I assume that is the rate you are using.

Under the CubieTruck Bluetooth wiki page ( 
http://linux-sunxi.org/Cubietruck/Bluetooth ) I found in the Update 3 section: 
"AP6210 pin 34 is BT-REST and is connected to GPIO pin PH18. AP6210 pin 6 is 
BT-WAKE and is connected to GPIO pin PH24. I've found that setting PH24 to 1 
and then toggling PH18 (0 then 1) is required before loading the firmware using 
the Broadcom program."
Then on page 20 of the chip manual "The polarity of this signal is software 
configurable and can be asserted high or low. By default, BT_WAKE is active-low 
(if BT-WAKE is low it requires the device to wake up or remain awake)."
So if BT_WAKE is zero then the chip is always on and I am thinking there is a 
conflict between BT_RESET and the power management. This is the story I 
imagine: BT_RESET is sent low and then high to initiate a reset but the power 
management doesn't allow the chip to sleep as part of the reset. Page 55 of the 
chip manual says sleep state is held for 4.2ms after reset.

I can't think of a reason to hold BT_WAKE at zero (always on). So maybe it 
should be 1 in the DTS then the boot script toggles the chip awake, resets the 
chip and loads the firmware.
You probably want to 
echo -n "" > /dev/ttyS1so RTS is low before uploading the firmware. See 
http://www.cubieforums.com/index.php/topic,2449.msg18834.html?PHPSESSID=usadn8lim7jp5ghh6rc22j31j7#msg18834
Hope that works.
Al
 
   

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Communication with Allwinner

[Henrik Nordström]

fre 2015-02-20 klockan 03:03 -0800 skrev mike.v...@gmail.com:

> For A312 and A80 they chose Imagination's PowerVR as the GPU, I don't know if 
> they chose the use Imagination parts for the Display Controller and VPU

A80 has mostly the same display controller and video codec engine as the
other Allwinner SoC generations. The main differences in I/O space
compared to sun4i is the GPU and DDR controllers.

I think the PowerVR is also capable of some VPU processing so there may
be some noticeable functional overlap with Allwinner IP parts there.
 
> codec comes from coding and decoding. The VPU does more:
> ColorCode conversion
> Scaling
> etc.

Allwinner have those split in several components, with some overlap in
functionality. Allwinner do not own any GPU and normal video playback do
not use the GPU at all. Video playback is also possible to a memory
region mapped by the GPU but far from as efficient.

Things gets a little different when the VPU is merged into the GPU as
the GPU is then doing many of the transforms needed.

> But the Market/Marketing is stuck on the "video" term.

SoC world is still much more fragmented on terminology and
implementation.

> That's intersting. I thought, altough it seemed odd me, the VPU was an in 
> house development of Allwinner.
> 
> So the CedarX code may also be property of chipsbank.

I very much doubt Allwinner do not have full control of CedarX IP (both
hardware and software), even if initially developed by/with others. It
is what made a market for Allwinner.

But yes, there almost certainly is shared ownership/licensing involved
which likely makes it troublesome for them to publish details.

Regards
Henrik

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel

[Steven Saunderson]

Hi Al,
My bluetooth testing is to a mobile phone for wireless broadband.  I 
haven't tested any other bluetooth functions.

The BT_WAKE pin seems irrelevant to me.  After reading the datasheet I'm 
setting it low now.

Thanks for the details from the linux-sunxi page.  With kernel 3.4 this is 
exactly what I do.  I modified the Broadcom download program to assert RTS 
when starting and to wait for CTS before sending.  For 3.19 I've changed 
the process so I open the serial port before toggling the BT_REST pin.  
This is now working reliably.

The datasheet states the device waits for CTS after a reset before enabling 
async mode.  Perhaps the old kernel left RTS asserted when the port is 
closed whereas the new kernel negates it.  If the AP6210 is not a perfect 
clone of the 20710 it might default to SPI mode if CTS is negated at the 
end of the reset pulse.  I think this CTS theory is more plausible than my 
previous suggestion of noise on the TX line.

I'll keep testing and post details on the linux-sunxi page when I'm sure my 
new procedure is correct.

Thanks for your assistance here.

Cheers,
Steven

  

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.