[linux-sunxi] OV5640 1080@30FPS on CSI

2016-08-02 Thread @lex
I am working on OV5640 to get the best fps i can on 1920x1080 preview mode. 
After a lot of trial and errors i got somewhat near 15 fps, actually ~10 
fps when rendering on screen.
If i set the timings to 30 fps i get the following error:* [VFE]cs/isp 
reset after csi/isp interrupt timeout!*

I have seen it is possible to get 1080p at 30 fps on MIPI CSI for some 
boards and i have exhausted all possible timings / setting i could get that 
i think is correct for the 30 FPS without success.
So the question is, is technically possible to get 30 fps on CSI ? If it is 
possible what i am missing and what exactly '*cs/isp reset after csi/isp 
interrupt timeout!*' means.

-- 
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: sharing a video test with Optimus board A80 octacore simultaneous WebRTC+HLS / VP8+H.264

2016-08-02 Thread zzambia
Javqui,

did you make any progress on that application? It looks like the HW 
encoding support for the A80 is pretty inconsistent in performance (at 
least on the Android version I am actually using on the OptimusBoard).

Could you at least share some details about your setup (FW version, kernel 
version, details of the OMX fingerprints and so on). It could help a lot.

Thanks

Il giorno lunedì 19 gennaio 2015 20:56:11 UTC+1, javqui ha scritto:

> For the youtube demo video, the camera was a OV16825. 
> MIPI interface, cmos bayer and color space transformations run on the A80 
> video specialized hadware with the GPU help.
> The VP8 and H.264 video "hardware" encoders are included as standard 
> encoders in the android stock distribution. ("hardware" means no software 
> encoder implementation). 
> Unfortunately, the standard Google webrtc video engine (and the WebRTC 
> implementation in the Google Chrome browser) does not use the powerful 
> "hardware" encoding capabilities of the A80, so if you test the WebRTC on 
> Chrome browser or any popular Android webrtc app, it will perform poorly (a 
> black output or 8fps at 4k or around 15fps at 1080p). 
> You will need to write your own WebRTC video Engine to take advantage of 
> the A80 "hardware" encoder capabilities. 
> On Android, use the surface input mode for the encoders (this is the only 
> way to get higher FPS and bitrates at 4k). Hope this info help with your 
> project.
>
> Javqui
>
>
> On Fri, Jan 16, 2015 at 9:24 PM,  wrote:
>
>> Le mardi 6 janvier 2015 02:24:55 UTC+1, javqui a écrit :
>> > Just to share a video showing some A80 capabilities.
>> > It's just an initial test. There is room for improvements (particularly 
>> with the 4k video memory handlers and GPU processing). 
>> > YouTube video
>> >
>>
>> Waoouu :D
>> I have a board since few day, what camera do you have? To be sure I will 
>> not have some compatibility problem.
>>
>> I surprise to see a 4K encoding on this board because no OpenMAX 
>> instructions.
>> It's a GPU encoding (?)
>>
>> It will be cool if you can share/explain your test/code.
>>
>> --
>> 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/bUdiLJ0GiH0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> linux-sunxi...@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.


[linux-sunxi] Re: [PATCH v2] mmc: sunxi: Handle the 'New Timings'

2016-08-02 Thread Jean-Francois Moine
On Tue, 2 Aug 2016 12:20:48 +0100
Mark Rutland  wrote:

> > This mode is described at least in the Allwinner's documentation of the
> > A83T, A64 and H3.
> 
> Is this publicly available? If not, can the gist of it be described?

The links are in the kernel Documentation/arm/sunxi/README

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
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] Re: [PATCH v2] mmc: sunxi: Handle the 'New Timings'

2016-08-02 Thread Mark Rutland
On Mon, Aug 01, 2016 at 06:26:03PM +0200, Jean-Francois Moine wrote:
> On Mon, 1 Aug 2016 16:30:19 +0100
> Mark Rutland  wrote:
> 
> > On Mon, Aug 01, 2016 at 03:10:29PM +0200, Jean-Francois Moine wrote:
> > > Some MMC devices as mmc2 in the A83T or mmc1 and mmc2 in the H3 have
> > > a 'New Timings' mode.
> > > Set this capacity in the DT and use it when possible.
> > 
> > What exactly is this "New Timings" mode?
> > 
> > Why do we wnat to set it? Improved performance, power?
> > 
> > Is it *necessary* to use it?
> 
> This mode is described at least in the Allwinner's documentation of the
> A83T, A64 and H3.

Is this publicly available? If not, can the gist of it be described?

> From my tests, it is required to access the eMMC of the Banana Pi M3
> (mmc2).

Ok.

> > > Signed-off-by: Jean-Francois Moine 
> > > ---
> > > I don't know if this mode works or is needed at 25MHz.
> > > ---
> > >  Documentation/devicetree/bindings/mmc/sunxi-mmc.txt |  1 +
> > >  drivers/mmc/host/sunxi-mmc.c| 21 
> > > +++--
> > >  2 files changed, 20 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt 
> > > b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> > > index 4bf41d8..a541bf4 100644
> > > --- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> > > +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> > > @@ -19,6 +19,7 @@ Optional properties:
> > >   - reset-names : must contain "ahb"
> > >   - for cd, bus-width and additional generic mmc parameters
> > > please refer to mmc.txt within this directory
> > > + - allwinner,new-timings: the controller may accept the "New Timings" 
> > > mode
> > 
> > It's not at all clear to me what this means. This needs a better
> > description.
> > 
> > Which devices have this? Can we determine this based on compatible
> > string?
> 
> No, only some devices of the SoCs have this capability: the mmc2 of the
> A83T, the smhc0 and smhc1 of the A64, and the mmc1 and mmc2 of the H3.

Ok.

Thanks,
Mark.

-- 
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: [PATCH 2/3] mmc: sunxi: Set the 'New Timing' register for 8 bits DDR transfers

2016-08-02 Thread Hans de Goede

Hi,

On 01-08-16 15:52, Jean-Francois Moine wrote:

On Sat, 30 Jul 2016 12:19:03 +0200
Hans de Goede  wrote:


Jean-Francois, can you submit a v2 of your patch and make the writing of
SDXC_REG_NTSR depend on a new sun8i-a83t-mmc compatible ?

Also you should probably drop the bits about the clock stuff from the
commit message as that just seems to confuse people.


Hi Hans,

I submitted a new patch (sorry, I forgot the history), but it asks for
some explanation.

- in the old timings, the phase delays are set in the clock.
  That's why there is a function clk_set_phase() which is called from
  the MMC side.

- in the new timings, the delays are in the MMC register SDXC_REG_NTSR
  only.
  In this case, the function clk_set_phase() is of no use
  (also, by test, it seems that the phase delays set by hardware
   reset do work, so, there is no need to set them), but,

- there is a bit in the clock telling that the new timings are used,
  i.e. that the phase delays of the clock must be ignored.

  Not setting this bit prevents the device to work (at least in the
  A83T, the H3 seems more helpful).


Thanks for the explanation, it would be good to put this in the commit
msg of v3 of the patch.

Regards,

Hans

--
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.