Re: [linux-sunxi] A10/A13/A20 interface asyncroneous memory

2014-03-25 Thread Emilio López

Hi,

El 25/03/14 20:23, Dimitar Penev escribió:

 > We need 16bit wide SRAM interface so NAND flash port doesn't suit
us.
 > We plan to build SRAM on top of GPIO system.
 > The interface is going to be used sporadically for a fraction of
second,
 > so I guess we will be able to take the CPU fully (no DMA) while
it is
 > active.
 >
 > Anyone implemented similar thing with AW?


I don't know what you're trying to achieve, but have you considered 
using SPI?


There are SRAM with SPI bus connectivity, like

http://ww1.microchip.com/downloads/en/DeviceDoc/22100D.pdf

Cheers,

Emilio

--
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] A10/A13/A20 interface asyncroneous memory

2014-03-25 Thread Dimitar Penev
Hi Olliver,

Yeah it seems we can get the cycle like 4MHz maximum in the kernel space on 
A20. 
(based on some reports)

Kind of disappointing. 

Thanks
Dimitar
 

25 март 2014, вторник, 22:08:08 UTC+2, Olliver Schinagl написа:
>
> On 03/25/2014 07:18 PM, Dimitar Penev wrote: 
> > Thanks Runzhong for the suggestions. 
> > 
> > We need 16bit wide SRAM interface so NAND flash port doesn't suit us. 
> > We plan to build SRAM on top of GPIO system. 
> > The interface is going to be used sporadically for a fraction of second, 
> > so I guess we will be able to take the CPU fully (no DMA) while it is 
> > active. 
> > 
> > Anyone implemented similar thing with AW? 
> I haven't heard of something as such done yet. 
>
> While it should be possible to talk to an sram via gpio; don't exect it 
> to be super fast, from what I heard, is that the GPIO's are pretty slow. 
> Check the ML archives for more info. 
>
> Olliver 
> > 
> > Thanks 
> > Dimitar 
> > 
> > 
> > 
> > 11 март 2014, вторник, 03:05:45 UTC+2, Runzhong Yi написа: 
> > 
> > It depends on your needs. If simply want to expand some DI/DO, 
> ADC/DAC 
> > or some other peripheral, USB maybe a good, cheap and expandible 
> > option. I don't see too much needs in SRAM interface. If you 
> > desperately need a parellel interface, you can use nand flash 
> > controller with a small CPLD. 
> > 
> > 2014-03-05 17:51 GMT+08:00 Dimitar Penev  > >: 
> >  > Thanks Runzhong, 
> >  > 
> >  > It is as a big limitation of the AW SoC, isn't it? 
> >  > Dimitar 
> >  > 
> >  > 
> >  > 
> >  > 04 март 2014, вторник, 12:00:58 UTC+2, Runzhong Yi написа: 
> >  >> 
> >  >> For A10 or A13, the answer is absolutely NO! I didn't checked 
> the 
> >  >> datasheet for A20, but I think it's the same. 
> >  >> 
> >  >> 2014-03-03 21:24 GMT+08:00  : 
> >  >> > Hi All, 
> >  >> > 
> >  >> > I am wondering if Allwinner A10/A13/A20 SoC can support 
> external 
> >  >> > asynchronous memory. (8/16 bit Data bus, Address bus, \RD, 
> > \WR, \CS) 
> >  >> > I don't see information about this in the A20 datasheet. 
> >  >> > 
> >  >> > Is there some software component in sunxi Linux about this? 
> >  >> > 
> >  >> > Pointers are very welcome. 
> >  >> > 
> >  >> > Thanks 
> >  >> > Dimitar 
> >  >> > 
> >  >> > -- 
> >  >> > 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...@googlegroups.com. 
> >  >> > For more options, visit 
> > https://groups.google.com/groups/opt_out 
> > . 
> >  > 
> >  > -- 
> >  > 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...@googlegroups.com . 
> >  > For more options, visit https://groups.google.com/groups/opt_out 
> > . 
> > 
> > -- 
> > 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...@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] [A20] sunxi framebuffer overlay help needed

2014-03-25 Thread Ivan Kozic
I think that maybe it can be done - I have already started modifying driver 
for Qt and had some limited success - it is supposed to be using layers 
now, but I'm generally having issues with the usage of disp driver. In 
other words it doesn't work yet, but I get a proper layer handle, so good 
so far. The big problem with all this Allwinner stuff is that ioctls are 
almost not documented at all and I usually need to go deep into the driver 
structure to figure out how I should use what.

Forums are also full of unsolved disp issues - I don't think I've seen a 
single post on how to use GUI layer.

Also display driver is very buggy, so it's not really an easy task.

I'm also not sure if the display driver can be opened multiple times - my 
whole idea is based on the fact that it can...

What is this about your KMS driver? Not sure I know what the abbreviation 
stands for.

On Tuesday, March 25, 2014 3:00:07 PM UTC+1, Luc Verhaegen wrote:
>
> On Tue, Mar 25, 2014 at 01:55:40AM -0700, Ivan Kozic wrote: 
> > Hi Luc and thanks for replying, 
> > 
> > Not sure I follow - I went deeper into the Qt structure yesterday. 
> > Basically, Qt uses just a normal linux fb access (opens /dev/fb0 
> directly), 
> > while my current no-GUI application (only used to display video from 
> CSI) 
> > is using more "advanced" way - it opens /dev/disp first and then 
> requests a 
> > layer from it, eventually opening /dev/fb just to execute 
> > FBIOGET_LAYER_HDL_0 ioctl and then closes it. Afterwards, I just have an 
> > endless loop in the program in which buffers from V4L2 exchange 
> addresses 
> > with buffers from display. 
> > 
> > To my understanding (I'm a bit fresh with all this), Qt should actually 
> > also open /dev/disp and request a GUI layer (think it's called YUV layer 
> in 
> > the user manual for A20) for it, while my underlying V4L2 library should 
> do 
> > the same, but only requesting video layer instead of a GUI layer. This 
> way, 
> > underlying lib would do the video and provide controls, while overlay 
> would 
> > be in a different layer providing GUI which is linked with the controls. 
> Is 
> > this true? 
> > 
> > If so, there is no easy way to do it, as I would have to implement a 
> > different display driver for Qt which would use layers instead of 
> stupidly 
> > opening /dev/fb0 (this is quite some work) + update my underlying 
> library 
> > to actually use display, again with layering. Just saying - compared to 
> > Freescale kernel, this is far from walk in the park. As I said before, 
> > Freescale provides a separate /dev/fb for every layer of the screen, 
> which 
> > is much easier to work with. 
> > 
> > But as I said, I might be completely wrong - what did you have in mind? 
>
> You should use the hw differently, i am not sure whether disp allows 
> that though. 
>
> Just wait until i finally deliver on my KMS driver, i still am too 
> lethargic atm to make proper progress on it, although i have added some 
> good lcd code in the last week. 
>
> Luc Verhaegen. 
>

-- 
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 v7 0/3] ARM: sun7i/sun6i: irqchip: Irqchip driver for NMI controller

2014-03-25 Thread Carlo Caione
On Wed, Mar 19, 2014 at 08:21:16PM +0100, Carlo Caione wrote:
> Allwinner A20/A31 SoCs have a special interrupt controller for managing NMI.
> Three register are present to (un)mask, control and acknowledge NMI.
> These two patches add a new irqchip driver in cascade with GIC.

Hi Thomas,
Is this ok with the Maxime ACKs?

-- 
Carlo Caione

-- 
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] performance difference between two A20 boards how to debug?

2014-03-25 Thread Emilio López

Hi,

El 25/03/14 15:27, Rajesh Mallah escribió:


Hi ,

i am using tinymembench to bench mark 2 A20 based 1GB boards
MELE finished in 6mins and the
noname one finishes in 12mins.

pls tell how to systematically debug the issue.

at least dram settings are same. where else should i see?


MELE:

root@ltspmele:~# ./a10-meminfo-static
dram_clk  = 408
dram_type = 3
dram_rank_num = 1
dram_chip_density = 4096
dram_io_width = 16
dram_bus_width= 32
dram_cas  = 9
dram_zq   = 0x7f


zq is different from the other one


dram_odt_en   = 0
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_emr1 = 0x4
dram_emr2 = 0x10


What happened to emr3?



NONAME:

root@ltspenjoy:~# ./a10-meminfo-static
dram_clk  = 408
dram_type = 3
dram_rank_num = 1
dram_chip_density = 4096
dram_io_width = 16
dram_bus_width= 32
dram_cas  = 9
dram_zq   = 0x79
dram_odt_en   = 0
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_emr1 = 0x4
dram_emr2 = 0x10
dram_emr3 = 0x0


Also, as Oliver mentioned, as these are A20 boards, MBUS frequency may 
be different. Do the speeds on tinymembench vary significantly? If you 
are using u-boot-sunxi and booting from MMC you can check the FAST_MBUS 
flag on boards.cfg


Cheers,

Emilio

--
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] performance difference between two A20 boards how to debug?

2014-03-25 Thread Siarhei Siamashka
On Tue, 25 Mar 2014 23:57:22 +0530
Rajesh Mallah  wrote:

> Hi ,
> 
> i am using tinymembench to bench mark 2 A20 based 1GB boards
> MELE finished in 6mins and the
> noname one finishes in 12mins.

You can't compare the times of running tinymembench. That's because
the amount of work they do may differ! The number of repeats for each
individual test increases if they are poorly reproducible. The test
results may be poorly reproducible if you have some other background
activity in the system.

To sum it up: just look at the numbers in the log and don't try to
time the whole program.

And some random advices for getting more stable test environment
with better reproducible results:

1. Ensure that both systems are configured to use exactly the
   same screen resolution. Or blank the display to disable
   framebuffer scanout by running:
  "echo 1 > /sys/devices/platform/disp/graphics/fb0/blank"
  "echo 1 > /sys/devices/platform/disp/graphics/fb1/blank"

2. Check for any possible IRQ spam in /proc/interrupts

3. Run the benchmark as the init process to make sure that
   nothing else is interfering

-- 
Best regards,
Siarhei Siamashka

-- 
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] performance difference between two A20 boards how to debug?

2014-03-25 Thread Olliver Schinagl

On 03/25/2014 07:27 PM, Rajesh Mallah wrote:


Hi ,

i am using tinymembench to bench mark 2 A20 based 1GB boards
MELE finished in 6mins and the
noname one finishes in 12mins.

pls tell how to systematically debug the issue.

at least dram settings are same. where else should i see?
The mbus can be different, this is a compiletime option for u-boot. Then 
again, mbus changing might not work on a10 iirc.


But try using the same bootloader for a fair comparison ...

Olliver



MELE:

root@ltspmele:~# ./a10-meminfo-static
dram_clk  = 408
dram_type = 3
dram_rank_num = 1
dram_chip_density = 4096
dram_io_width = 16
dram_bus_width= 32
dram_cas  = 9
dram_zq   = 0x7f
dram_odt_en   = 0
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_emr1 = 0x4
dram_emr2 = 0x10



NONAME:

root@ltspenjoy:~# ./a10-meminfo-static
dram_clk  = 408
dram_type = 3
dram_rank_num = 1
dram_chip_density = 4096
dram_io_width = 16
dram_bus_width= 32
dram_cas  = 9
dram_zq   = 0x79
dram_odt_en   = 0
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_emr1 = 0x4
dram_emr2 = 0x10
dram_emr3 = 0x0

--
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] A10/A13/A20 interface asyncroneous memory

2014-03-25 Thread Olliver Schinagl

On 03/25/2014 07:18 PM, Dimitar Penev wrote:

Thanks Runzhong for the suggestions.

We need 16bit wide SRAM interface so NAND flash port doesn't suit us.
We plan to build SRAM on top of GPIO system.
The interface is going to be used sporadically for a fraction of second,
so I guess we will be able to take the CPU fully (no DMA) while it is
active.

Anyone implemented similar thing with AW?

I haven't heard of something as such done yet.

While it should be possible to talk to an sram via gpio; don't exect it 
to be super fast, from what I heard, is that the GPIO's are pretty slow. 
Check the ML archives for more info.


Olliver


Thanks
Dimitar



11 март 2014, вторник, 03:05:45 UTC+2, Runzhong Yi написа:

It depends on your needs. If simply want to expand some DI/DO, ADC/DAC
or some other peripheral, USB maybe a good, cheap and expandible
option. I don't see too much needs in SRAM interface. If you
desperately need a parellel interface, you can use nand flash
controller with a small CPLD.

2014-03-05 17:51 GMT+08:00 Dimitar Penev >:
 > Thanks Runzhong,
 >
 > It is as a big limitation of the AW SoC, isn't it?
 > Dimitar
 >
 >
 >
 > 04 март 2014, вторник, 12:00:58 UTC+2, Runzhong Yi написа:
 >>
 >> For A10 or A13, the answer is absolutely NO! I didn't checked the
 >> datasheet for A20, but I think it's the same.
 >>
 >> 2014-03-03 21:24 GMT+08:00  :
 >> > Hi All,
 >> >
 >> > I am wondering if Allwinner A10/A13/A20 SoC can support external
 >> > asynchronous memory. (8/16 bit Data bus, Address bus, \RD,
\WR, \CS)
 >> > I don't see information about this in the A20 datasheet.
 >> >
 >> > Is there some software component in sunxi Linux about this?
 >> >
 >> > Pointers are very welcome.
 >> >
 >> > Thanks
 >> > Dimitar
 >> >
 >> > --
 >> > 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...@googlegroups.com.
 >> > For more options, visit
https://groups.google.com/groups/opt_out
.
 >
 > --
 > 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...@googlegroups.com .
 > For more options, visit https://groups.google.com/groups/opt_out
.

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


[linux-sunxi] performance difference between two A20 boards how to debug?

2014-03-25 Thread Rajesh Mallah
Hi ,

i am using tinymembench to bench mark 2 A20 based 1GB boards
MELE finished in 6mins and the
noname one finishes in 12mins.

pls tell how to systematically debug the issue.

at least dram settings are same. where else should i see?


MELE:

root@ltspmele:~# ./a10-meminfo-static
dram_clk  = 408
dram_type = 3
dram_rank_num = 1
dram_chip_density = 4096
dram_io_width = 16
dram_bus_width= 32
dram_cas  = 9
dram_zq   = 0x7f
dram_odt_en   = 0
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_emr1 = 0x4
dram_emr2 = 0x10



NONAME:

root@ltspenjoy:~# ./a10-meminfo-static
dram_clk  = 408
dram_type = 3
dram_rank_num = 1
dram_chip_density = 4096
dram_io_width = 16
dram_bus_width= 32
dram_cas  = 9
dram_zq   = 0x79
dram_odt_en   = 0
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_emr1 = 0x4
dram_emr2 = 0x10
dram_emr3 = 0x0

-- 
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] A10/A13/A20 interface asyncroneous memory

2014-03-25 Thread Dimitar Penev
Thanks Runzhong for the suggestions.

We need 16bit wide SRAM interface so NAND flash port doesn't suit us.
We plan to build SRAM on top of GPIO system. 
The interface is going to be used sporadically for a fraction of second, 
so I guess we will be able to take the CPU fully (no DMA) while it is 
active.

Anyone implemented similar thing with AW?

Thanks
Dimitar



11 март 2014, вторник, 03:05:45 UTC+2, Runzhong Yi написа:
>
> It depends on your needs. If simply want to expand some DI/DO, ADC/DAC 
> or some other peripheral, USB maybe a good, cheap and expandible 
> option. I don't see too much needs in SRAM interface. If you 
> desperately need a parellel interface, you can use nand flash 
> controller with a small CPLD. 
>
> 2014-03-05 17:51 GMT+08:00 Dimitar Penev >: 
>
> > Thanks Runzhong, 
> > 
> > It is as a big limitation of the AW SoC, isn't it? 
> > Dimitar 
> > 
> > 
> > 
> > 04 март 2014, вторник, 12:00:58 UTC+2, Runzhong Yi написа: 
> >> 
> >> For A10 or A13, the answer is absolutely NO! I didn't checked the 
> >> datasheet for A20, but I think it's the same. 
> >> 
> >> 2014-03-03 21:24 GMT+08:00  : 
> >> > Hi All, 
> >> > 
> >> > I am wondering if Allwinner A10/A13/A20 SoC can support external 
> >> > asynchronous memory. (8/16 bit Data bus, Address bus, \RD, \WR, \CS) 
> >> > I don't see information about this in the A20 datasheet. 
> >> > 
> >> > Is there some software component in sunxi Linux about this? 
> >> > 
> >> > Pointers are very welcome. 
> >> > 
> >> > Thanks 
> >> > Dimitar 
> >> > 
> >> > -- 
> >> > 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...@googlegroups.com. 
> >> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
>

-- 
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] rtl8189es driver?

2014-03-25 Thread gtsitsiridis
Τη Δευτέρα, 22 Απριλίου 2013 12:58:18 π.μ. UTC+3, ο χρήστης theRat έγραψε:
> For anyone else wishing to test this, here is a more detailed description of 
> what I did.
> 
> 
> 1. Delete drivers/net/wireless/rtl8188eu directory
> 2. Remove references to rtl8188 in drivers/net/wireless/Kconfig and 
> drivers/net/wireless/Makefile
> 3. Download Neal's patch from 
> https://github.com/npeacock/linux-sunxi/commit/d37e534b012904c9ac69635120a88864a21341b7.patch
>  and apply it.
> 4. Download https://www.dropbox.com/s/3nvttsp96sjgjnb/mmc_pm.tar.gz and place 
> the files in drivers/mmc/mmc-pm
> 5. Enable the driver in the config and build
> 
> 
> Hope this helps.
> Simon
> 
> On Wednesday, 17 April 2013 17:47:58 UTC+10, theRat  wrote:Neal,
> 
> 
> Today I downloaded you patch for the realtek drivers and applied it to a 
> fresh stage/sunxi-3.0.  I had a problem in that recently another patch has 
> been applied that contains a subset of yours (the 8188eu stuff).  I just blew 
> that away and reverted the Kconfig and Makefile so I could apply you code.
> 
> 
> I ported the extra bits in the pm_mmc directory and now have the 8189es wifi 
> working.
> 
> 
> Are you able to get your patch sorted and submitted?  If you can I will then 
> do a patch for the other bits for the SDIO cards.
> 
> 
> Cheers
> Simon
> 
> On Wednesday, 17 April 2013 08:40:09 UTC+10, theRat  wrote:Neal,
> 
> 
> I believe you have done most of the work as that appears to include all the 
> network drivers.
> 
> 
> There is however one area of the code you missed for the sdio stuff.  Since 
> the the sdio drivers rely on mmc as the underlying hardware interface there 
> are some changes in the /drivers/mmc/pm_mmc directory that also need to be 
> included.
> 
> 
> I will apply your changes (once I figure out how to download them) and apply 
> to a fresh stage-3.0 and then make the changes to the mmc so see if it works.
> 
> 
> Thanks very much for your efforts :)
> 
> 
> Cheers
> Simon
> 
> On Wednesday, 17 April 2013 03:21:44 UTC+10, npeacock  wrote:
>   
> 
>   
>   
> 
> 
> 
> 
> On 04/16/2013 03:53 AM, theRat wrote:
> 
> 
> Hans,
>   
> 
> 
>   
>   
> Thanks for that info.
>   
> After some more scratching around I also found this site.
>   
> 
> 
>   
>   
> http://service.i-onik.de/a10_source_1.5/lichee/
> 
>   
>   
> 
> 
>   
>   
> This source code has a few extra sdio wifi cards including
> the one I am looking for.  Currently downloading to see if it
> actually works.
> 
> I have already merged in the 8188eu wifi driver into my repository
> here
> https://github.com/npeacock/linux-sunxi/commit/d37e534b012904c9ac69635120a88864a21341b7
> 
> 
> 
> I think thats the same one you need.  I have been testing and
> working with it for a few months now, everything seems to fine.  The
> commit was too big to send as a patch to the mailing list.
> 
> 
> 
> 
>   
> 
> 
>   
>   
> Simon
>   
> 
> 
> On Monday, 15 April 2013 20:00:20 UTC+10, Hans de Goede wrote:
> Hi
>   Simon,
>   
> 
>   
> 
>   On 04/15/2013 10:12 AM, theRat wrote:
>   
> 
>   > I recently got a device that looks exactly the same as
>   the minix (mk805?), but instead of it having minix printed on
>   the case it has Smartbox.
>   
> 
>   >
>   
> 
>   > This device actually contains an a10s processor, axp152
>   pmu and a rtl8189es wifi chip.
>   
> 
>   >
>   
> 
>   > Does anyone know if there is a driver available for the
>   rtl8189es?  It is a sdio/mmc based device.  The android
>   script.bin for the device contains the following:
>   
> 
>   >
>   
> 
>   > |
>   
> 
>   > [sdio_wifi_para]
>   
> 
>   > sdio_wifi_used = 1
>   
> 
>   > sdio_wifi_sdc_id = 1
>   
> 
>   > sdio_wifi_mod_sel = 10
>   
> 
>   > rtl8189es_shdn =
>   port:PB18<1><0>
>   
> 
>   > rtl8189es_wakeup =
>   port:PB17<1><1>
>   
> 
>   > rtl8189es_vdd_en =
>   port:PA03<1><0>
>   
> 
>   > rtl8189es_vcc_en =
>   port:PA04<1><0>
>   
> 
>   
> 
>   The driver you are looking for is called rtl8188eu, some more
>   info
>   
> 
>   on it is here:
>   
> 
>   http://www.rikomagic.co.uk/forum/viewtopic.php?f=6&t=3299
>   
> 
>   
> 
>   
> 
>   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 

[linux-sunxi] Cubieboard 2 vs Cubietruck kernel configuration

2014-03-25 Thread Fabian Zaremba
Hello everyone,

I am using Arch Linux ARM on a Cubietruck.
My distribution packages the most current linux-sunxi kernel for use
with both Cubieboard 2 and Cubietruck.

However, I now stumbled upon a kernel configuration problem with the
two boards.

Cubietruck display output does only seem to work when *all* of
FB_SUNXI are statically compiled into the kernel like this:

CONFIG_FB_SUNXI=y
CONFIG_FB_SUNXI_RESERVED_MEM=y
CONFIG_FB_SUNXI_UMP=y
CONFIG_FB_SUNXI_LCD=y
CONFIG_FB_SUNXI_HDMI=y

Neither VGA nor HDMI work if one of these is set to build as module,
regardless of module loading order in modprobe.conf.d, etc.

However, if CONFIG_FB_SUNXI_LCD=y is set in kernel config, the
Cubieboard 2 seems to refuse to boot as the LCD driver causes a kernel oops.

Unfortunately, I can't provide additional information about this LCD driver 
problem,
as I don't own a Cubieboard 2 myself.

I took the issue to my distribution, but they told me that it won't be 
possible to
integrate the needed kernel configuration changes for Cubietruck display as 
long
as the blocking issue with the LCD driver isn't fixed for Cubieboard 2 and 
that this
would be needed to be fixed upstream.

You can see relevant issues here:
https://github.com/archlinuxarm/PKGBUILDs/issues/767
https://github.com/archlinuxarm/PKGBUILDs/commit/9dffd3a07a143e056d66a4f2635c9d26a6e777ab
https://github.com/archlinuxarm/PKGBUILDs/issues/775

Help would be greatly appreciated - many thanks in advance!

Fabian

-- 
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] Cubieboard / Cubietruck kernel configuration

2014-03-25 Thread puckido
Hello everybody,

I am using Arch Linux ARM on a Cubietruck. My distribution packages the most 
current linux-sunxi kernel from here: https://github.com/linux-sunxi/linux-sunxi
for usage on both Cubieboard 2 and Cubietruck.

I now experienced a problem regarding kernel configuration.

Cubietruck seems to need all of FB_SUNXI = y like this:

CONFIG_FB_SUNXI=y
CONFIG_FB_SUNXI_RESERVED_MEM=y
CONFIG_FB_SUNXI_UMP=y
CONFIG_FB_SUNXI_LCD=y
CONFIG_FB_SUNXI_HDMI=y

in order for display output (both VGA & HDMI) to work at all. I couldn't get 
display output to work if these settings were partially or completely set to 
module.

However, according to user reports the Cubieboard 2 stops working if 
CONFIG_FB_SUNXI_LCD gets statically built into the kernel.
("The LCD driver built in is causing a kernel oops and halting the board.")
You can also see this issue here: 
https://github.com/archlinuxarm/PKGBUILDs/issues/767

I can't test or examine this issue myself as I don't own a Cubieboard 2.


I reported this issue with my distribution 
(https://github.com/archlinuxarm/PKGBUILDs/issues/775) and they told me it 
won't be possible until the blocking LCD driver issue with Cubieboard 2 was 
fixed upstream, so that's why I'm taking this to you in hope for help.

Many thanks in advance!

Fabian

-- 
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] [PATCH] sunxi: add board MK808C

2014-03-25 Thread codekipper
From: Marcus Cooper 

Signed-off-by: Marcus Cooper 
---
 board/sunxi/Makefile  |  1 +
 board/sunxi/dram_mk808c_a20.c | 31 +++
 boards.cfg|  1 +
 3 files changed, 33 insertions(+)
 create mode 100644 board/sunxi/dram_mk808c_a20.c

diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index f613ffd..51cac02 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_MK802_1GB)   += dram_sun4i_360_1024_iow16.o
 obj-$(CONFIG_MK802_A10S)   += dram_mk802_a10s.o
 obj-$(CONFIG_MK802II)  += dram_sun4i_408_1024_iow8.o
 obj-$(CONFIG_MK802II_A20)  += dram_mk802ii_a20.o
+obj-$(CONFIG_MK808C_A20)   += dram_mk808c_a20.o
 obj-$(CONFIG_PCDUINO)  += dram_sun4i_408_1024_iow8.o
 obj-$(CONFIG_PENGPOD700)   += dram_sun4i_384_1024_iow8.o
 obj-$(CONFIG_PENGPOD1000)  += dram_sun4i_408_1024_iow16.o
diff --git a/board/sunxi/dram_mk808c_a20.c b/board/sunxi/dram_mk808c_a20.c
new file mode 100644
index 000..04e4b1e
--- /dev/null
+++ b/board/sunxi/dram_mk808c_a20.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include "common.h"
+#include 
+
+static struct dram_para dram_para = {
+   .clock = 384,
+   .type = 3,
+   .rank_num = 1,
+   .density = 4096,
+   .io_width = 16,
+   .bus_width = 32,
+   .cas = 9,
+   .zq = 0x7f,
+   .odt_en = 0,
+   .size = 1024,
+   .tpr0 = 0x42d899b7,
+   .tpr1 = 0xa090,
+   .tpr2 = 0x22a00,
+   .tpr3 = 0,
+   .tpr4 = 0,
+   .tpr5 = 0,
+   .emr1 = 0x4,
+   .emr2 = 0x10,
+   .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+   return dramc_init(&dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index 0debbee..527afb3 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -414,6 +414,7 @@ Active  arm armv7  sunxi   -
   sunxi
 Active  arm armv7  sunxi   -   sunxi   
mk802_a10s   
sun5i:MK802_A10S,SPL,AXP152_POWER,STATUSLED=34  
  -
 Active  arm armv7  sunxi   -   sunxi   
mk802ii_A20  sun7i:MK802II_A20,SPL  

   -
 Active  arm armv7  sunxi   -   sunxi   
mk802ii  sun4i:MK802II,SPL  

   -
+Active  arm armv7  sunxi   -   sunxi   
mk808c_A20   sun7i:MK808C_A20,SPL   

  -
 Active  arm armv7  sunxi   -   sunxi   
pcDuino  sun4i:PCDUINO,SPL,SUNXI_EMAC   

   -
 Active  arm armv7  sunxi   -   sunxi   
pengpod1000  sun4i:PENGPOD1000,SPL  

   -
 Active  arm armv7  sunxi   -   sunxi   
pengpod700   sun4i:PENGPOD700,SPL   

   -
-- 
1.8.2.2

-- 
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] [PATCH] Add MK808C

2014-03-25 Thread codekipper
From: Marcus Cooper 

Signed-off-by: Marcus Cooper 
---
 sys_config/a20/mk808c.fex | 1013 +
 1 file changed, 1013 insertions(+)
 create mode 100644 sys_config/a20/mk808c.fex

diff --git a/sys_config/a20/mk808c.fex b/sys_config/a20/mk808c.fex
new file mode 100644
index 000..8485a4a
--- /dev/null
+++ b/sys_config/a20/mk808c.fex
@@ -0,0 +1,1013 @@
+[product]
+version = "100"
+machine = "sugar-dongel_au8723"
+
+[platform]
+eraseflag = 1
+
+[target]
+boot_clock = 912
+dcdc2_vol = 1400
+dcdc3_vol = 1250
+ldo2_vol = 3000
+ldo3_vol = 2800
+ldo4_vol = 2800
+power_start = 0
+storage_type = -1
+usb_recovery = 1
+
+[clock]
+pll3 = 297
+pll4 = 300
+pll6 = 600
+pll7 = 297
+pll8 = 336
+
+[card_boot]
+logical_start = 40960
+sprite_gpio0 = port:PH20<1><0>
+sprite_work_delay = 500
+sprite_err_delay = 200
+
+[card0_boot_para]
+card_ctrl = 0
+card_high_speed = 1
+card_line = 4
+sdc_d1 = port:PF00<2><1>
+sdc_d0 = port:PF01<2><1>
+sdc_clk = port:PF02<2><1>
+sdc_cmd = port:PF03<2><1>
+sdc_d3 = port:PF04<2><1>
+sdc_d2 = port:PF05<2><1>
+
+[card2_boot_para]
+card_ctrl = 2
+card_high_speed = 1
+card_line = 4
+sdc_cmd = port:PC06<3><1>
+sdc_clk = port:PC07<3><1>
+sdc_d0 = port:PC08<3><1>
+sdc_d1 = port:PC09<3><1>
+sdc_d2 = port:PC10<3><1>
+sdc_d3 = port:PC11<3><1>
+
+[twi_para]
+twi_port = 0
+twi_scl = port:PB00<2>
+twi_sda = port:PB01<2>
+
+[uart_para]
+uart_debug_port = 0
+uart_debug_tx = port:PB22<2><1>
+uart_debug_rx = port:PB23<2><1>
+
+[uart_force_debug]
+uart_debug_port = 0
+uart_debug_tx = port:PF02<4><1>
+uart_debug_rx = port:PF04<4><1>
+
+[jtag_para]
+jtag_enable = 0
+jtag_ms = port:PB14<3>
+jtag_ck = port:PB15<3>
+jtag_do = port:PB16<3>
+jtag_di = port:PB17<3>
+
+[pm_para]
+standby_mode = 0
+usbhid_wakeup_enable = 1
+
+[dram_para]
+dram_baseaddr = 0x4000
+dram_clk = 384
+dram_type = 3
+dram_rank_num = -1
+dram_chip_density = -1
+dram_io_width = -1
+dram_bus_width = -1
+dram_cas = 9
+dram_zq = 0x7f
+dram_odt_en = 0
+dram_size = -1
+dram_tpr0 = 0x42d899b7
+dram_tpr1 = 0xa090
+dram_tpr2 = 0x22a00
+dram_tpr3 = 0x0
+dram_tpr4 = 0x0
+dram_tpr5 = 0x0
+dram_emr1 = 0x4
+dram_emr2 = 0x10
+dram_emr3 = 0x0
+
+[mali_para]
+mali_used = 1
+mali_clkdiv = 1
+
+[emac_para]
+emac_used = 0
+emac_rxd3 = port:PA00<2>
+emac_rxd2 = port:PA01<2>
+emac_rxd1 = port:PA02<2>
+emac_rxd0 = port:PA03<2>
+emac_txd3 = port:PA04<2>
+emac_txd2 = port:PA05<2>
+emac_txd1 = port:PA06<2>
+emac_txd0 = port:PA07<2>
+emac_rxclk = port:PA08<2>
+emac_rxerr = port:PA09<2>
+emac_rxdV = port:PA10<2>
+emac_mdc = port:PA11<2>
+emac_mdio = port:PA12<2>
+emac_txen = port:PA13<2>
+emac_txclk = port:PA14<2>
+emac_crs = port:PA15<2>
+emac_col = port:PA16<2>
+emac_reset = port:PA17<1>
+emac_power =
+
+[twi0_para]
+twi0_used = 1
+twi0_scl = port:PB00<2>
+twi0_sda = port:PB01<2>
+
+[twi1_para]
+twi1_used = 1
+twi1_scl = port:PB18<2>
+twi1_sda = port:PB19<2>
+
+[twi2_para]
+twi2_used = 1
+twi2_scl = port:PB20<2>
+twi2_sda = port:PB21<2>
+
+[twi3_para]
+twi3_used = 1
+twi3_scl = port:PI00<3>
+twi3_sda = port:PI01<3>
+
+[twi4_para]
+twi4_used = 1
+twi4_scl = port:PI02<3>
+twi4_sda = port:PI03<3>
+
+[uart_para0]
+uart_used = 1
+uart_port = 0
+uart_type = 2
+uart_tx = port:PB22<2><1>
+uart_rx = port:PB23<2><1>
+
+[uart_para1]
+uart_used = 0
+uart_port = 1
+uart_type = 8
+uart_tx = port:PA10<4><1>
+uart_rx = port:PA11<4><1>
+uart_rts = port:PA12<4><1>
+uart_cts = port:PA13<4><1>
+uart_dtr = port:PA14<4><1>
+uart_dsr = port:PA15<4><1>
+uart_dcd = port:PA16<4><1>
+uart_ring = port:PA17<4><1>
+
+[uart_para2]
+uart_used = 1
+uart_port = 2
+uart_type = 4
+uart_tx = port:PI18<3><1>
+uart_rx = port:PI19<3><1>
+uart_rts = port:PI16<3><1>
+uart_cts = port:PI17<3><1>
+
+[uart_para3]
+uart_used = 0
+uart_port = 3
+uart_type = 4
+uart_tx = port:PH00<4><1>
+uart_rx = port:PH01<4><1>
+uart_rts = port:PH02<4><1>
+uart_cts = port:PH03<4><1>
+
+[uart_para4]
+uart_used = 0
+uart_port = 4
+uart_type = 2
+uart_tx = port:PH04<4><1>
+uart_rx = port:PH05<4><1>
+
+[uart_para5]
+uart_used = 0
+uart_port = 5
+uart_type = 2
+uart_tx = port:PH06<4><1>
+uart_rx = port:PH07<4><1>
+
+[uart_para6]
+uart_used = 0
+uart_port = 6
+uart_type = 2
+uart_tx = port:PA12<3><1>
+uart_rx = port:PA13<3><1>
+
+[uart_para7]
+uart_used = 0
+uart_port = 7
+uart_type = 2
+uart_tx = port:PA14<3><1>
+uart_rx = port:PA15<3><1>
+
+[spi0_para]
+spi_used = 0
+spi_cs_bitmap = 1
+spi_cs0 = port:PI10<2>
+spi_cs1 = port:PI14<2>
+spi_sclk = port:PI11<2>
+spi_mosi = port:PI12<2>
+spi_miso = port:PI13<2>
+
+[spi1_para]
+spi_used = 0
+spi_cs_bitmap = 1
+spi_cs0 = port:PA00<3>
+spi_cs1 = port:PA04<3>
+spi_sclk = port:PA01<3>
+spi_mosi = port:PA02<3>
+spi_miso = port:PA03<3>
+
+[spi2_para]
+spi_used = 0
+spi_cs_bitmap = 1
+spi_cs0 = port:PC19<3>
+spi_cs1 = port:PB13<2>
+spi_sclk = port:PC20<3>
+spi_mosi = port:PC21<3>
+spi_miso = port:PC22<3>
+
+[spi3_para]
+spi_used = 0
+spi_cs_bitmap = 1
+spi_cs0 = port:PA05<3>
+spi_cs1 = port:PA09<3>
+spi_sclk = port:PA06<3>
+spi_mosi = port:PA07<3>
+spi_miso =

Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed

2014-03-25 Thread Luc Verhaegen
On Tue, Mar 25, 2014 at 01:55:40AM -0700, Ivan Kozic wrote:
> Hi Luc and thanks for replying,
> 
> Not sure I follow - I went deeper into the Qt structure yesterday. 
> Basically, Qt uses just a normal linux fb access (opens /dev/fb0 directly), 
> while my current no-GUI application (only used to display video from CSI) 
> is using more "advanced" way - it opens /dev/disp first and then requests a 
> layer from it, eventually opening /dev/fb just to execute 
> FBIOGET_LAYER_HDL_0 ioctl and then closes it. Afterwards, I just have an 
> endless loop in the program in which buffers from V4L2 exchange addresses 
> with buffers from display.
> 
> To my understanding (I'm a bit fresh with all this), Qt should actually 
> also open /dev/disp and request a GUI layer (think it's called YUV layer in 
> the user manual for A20) for it, while my underlying V4L2 library should do 
> the same, but only requesting video layer instead of a GUI layer. This way, 
> underlying lib would do the video and provide controls, while overlay would 
> be in a different layer providing GUI which is linked with the controls. Is 
> this true?
> 
> If so, there is no easy way to do it, as I would have to implement a 
> different display driver for Qt which would use layers instead of stupidly 
> opening /dev/fb0 (this is quite some work) + update my underlying library 
> to actually use display, again with layering. Just saying - compared to 
> Freescale kernel, this is far from walk in the park. As I said before, 
> Freescale provides a separate /dev/fb for every layer of the screen, which 
> is much easier to work with.
> 
> But as I said, I might be completely wrong - what did you have in mind?

You should use the hw differently, i am not sure whether disp allows 
that though.

Just wait until i finally deliver on my KMS driver, i still am too 
lethargic atm to make proper progress on it, although i have added some 
good lcd code in the last week.

Luc Verhaegen.

-- 
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 u-boot (sc)] Cleanups of various clock macro's

2014-03-25 Thread Olliver Schinagl

And i'll start by commenting on my own patch

On 03/25/2014 11:00 AM, oliver+l...@schinagl.nl wrote:

From: Olliver Schinagl 

This patch cleans up several macro's to remove magic values etc from
clock.c and clock.h. Casualties being dragged in are some macro's from
dram.c and the i2c driver.

Signed-off-by: Olliver Schinagl 
---
  arch/arm/cpu/armv7/sunxi/clock.c| 162 --
  arch/arm/cpu/armv7/sunxi/dram.c |  22 +-
  arch/arm/include/asm/arch-sunxi/clock.h | 370 ++--
  drivers/i2c/sunxi_i2c.c |   2 +-
  4 files changed, 373 insertions(+), 183 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c
index 980fb90..3472fc9 100644
--- a/arch/arm/cpu/armv7/sunxi/clock.c
+++ b/arch/arm/cpu/armv7/sunxi/clock.c
@@ -21,27 +21,38 @@ static void clock_init_safe(void)
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
  
  	/* Set safe defaults until PMU is configured */

-   writel(AXI_DIV_1 << AXI_DIV_SHIFT |
-  AHB_DIV_2 << AHB_DIV_SHIFT |
-  APB0_DIV_1 << APB0_DIV_SHIFT |
-  CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
+   writel(CPU_AXI_CLK_DIV_RATIO(1) |
+  CPU_AHB_CLK_DIV_RATIO_2 |
+  CPU_APB0_CLK_DIV_RATIO_1 |
+  CPU_CLK_SRC_OSC24M,
   &ccm->cpu_ahb_apb0_cfg);
-   writel(PLL1_CFG_DEFAULT, &ccm->pll1_cfg);
+   writel(CCM_PLL1_CFG_N(16) |
+  CCM_PLL1_CFG_LCK_TMR_CTRL(2) |
+  CCM_PLL1_CFG_BIAS_CUR(16) |
+  CCM_PLL1_CFG_VCO_BIAS(8) |
+  CCM_PLL1_CFG_EN,
+  &ccm->pll1_cfg);
sdelay(200);
-   writel(AXI_DIV_1 << AXI_DIV_SHIFT |
-  AHB_DIV_2 << AHB_DIV_SHIFT |
-  APB0_DIV_1 << APB0_DIV_SHIFT |
-  CPU_CLK_SRC_PLL1 << CPU_CLK_SRC_SHIFT,
+   writel(CPU_AXI_CLK_DIV_RATIO(1) |
+  CPU_AHB_CLK_DIV_RATIO_2 |
+  CPU_APB0_CLK_DIV_RATIO_1 |
+  CPU_CLK_SRC_PLL1,
   &ccm->cpu_ahb_apb0_cfg);
  #ifdef CONFIG_SUN5I
/* Power on reset default for PLL6 is 2400 MHz, which is faster then
 * it can reliable do :|  Set it to a 600 MHz instead. */
-   writel(PLL6_CFG_DEFAULT, &ccm->pll6_cfg);
+   writel(CCM_PLL6_CFG_M(1) |
+  CCM_PLL6_CFG_K(1) |
+  CCM_PLL6_CFG_N(25) |
+  CCM_PLL6_CFG_BW_WIDE |
+  CCM_PLL6_BIAS_CUR(16) |
+  CCM_PLL6_VCO_BIAS(16),
+  &ccm->pll6_cfg);
  #endif
  #ifdef CONFIG_SUN7I
writel(0x1 << AHB_GATE_OFFSET_DMA | readl(&ccm->ahb_gate0),
   &ccm->ahb_gate0);
-   writel(0x1 << PLL6_ENABLE_OFFSET | readl(&ccm->pll6_cfg),
+   writel(CCM_PLL6_CFG_EN | readl(&ccm->pll6_cfg),
   &ccm->pll6_cfg);
  #endif
  }
@@ -57,21 +68,33 @@ int clock_init(void)
  #endif
  
  	/* uart clock source is apb1 */

-   sr32(&ccm->apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M);
-   sr32(&ccm->apb1_clk_div_cfg, 16, 2, APB1_FACTOR_N);
-   sr32(&ccm->apb1_clk_div_cfg, 0, 5, APB1_FACTOR_M);
+   clrsetbits_le32(&ccm->apb1_clk_div_cfg,
+   CCM_APB1_CLK_SRC_OSC24M, CCM_APB1_CLK_SRC_OSC24M);
+   clrsetbits_le32(&ccm->apb1_clk_div_cfg,
+   CCM_APB1_CLK_N_1, CCM_APB1_CLK_N_1);
+   clrsetbits_le32(&ccm->apb1_clk_div_cfg,
+   CCM_APB1_CLK_M(1), CCM_APB1_CLK_M(1));
I'm not convinced we always have to clear the bit, before setting it. 
Using setbits is probably enough, but if this gets merged somehow (even 
if only in our own tree for now), i'd rather see it initially merged as 
such, to confirm everything is still working properly, and then with 
tests slowly change it.


I mean, there must be a reason they used sr32 before, right?

Olliver
  
  	/* open the clock for uart */

-   sr32(&ccm->apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
+   clrsetbits_le32(&ccm->apb1_clk_div_cfg,
+   CCM_APB_GATE_UART(
+   SUNXI_CONS_TO_UART(CONFIG_CONS_INDEX)),
+   CCM_APB_GATE_UART(
+   SUNXI_CONS_TO_UART(CONFIG_CONS_INDEX)));
  
  #ifdef CONFIG_NAND_SUNXI

/* nand clock source is osc24m */
-   sr32(&ccm->nand_sclk_cfg, 24, 2, NAND_CLK_SRC_OSC24);
-   sr32(&ccm->nand_sclk_cfg, 16, 2, NAND_CLK_DIV_N);
-   sr32(&ccm->nand_sclk_cfg, 0, 4, NAND_CLK_DIV_M);
-   sr32(&ccm->nand_sclk_cfg, 31, 1, CLK_GATE_OPEN);
+   clrsetbits_le32(&ccm->nand_sclk_cfg,
+   CCM_NAND_SCLK_SRC_OSC24M, CCM_NAND_SCLK_SRC_OSC24M);
+   clrsetbits_le32(&ccm->nand_sclk_cfg,
+   CCM_NAND_SCLK_N_1, CCM_NAND_SCLK_N_1);
+   clrsetbits_le32(&ccm->nand_sclk_cfg,
+   CCM_NAND_SCLK_M(1), CCM_NAND_SCLK_M(1));
+   clrsetbits_le32(&ccm->nand_sclk_cfg,
+   CCM_NAND_SCLK_GATE_EN, CCM_NAND_SCLK_GATE_EN);
/* open clock for

Re: [linux-sunxi] Re: [PATCH v2 6/8] ARM: sunxi: dt: Add x-powers-axp209.dtsi file

2014-03-25 Thread Maxime Ripard
On Sat, Mar 22, 2014 at 03:31:57PM +0100, Carlo Caione wrote:
> > > + compatible = "x-powers,axp209";
> > > + interrupt-controller;
> > > + #interrupt-cells = <1>;
> > 
> > However, I'd move this out of it, and in the board file, so that we
> > actually get an idea by looking at the board DTS of what device we are
> > actually registering at this given address, and what it's capable of.
> 
> Do you mean the whole dtsi or just those three lines?

Just those three lines.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature


Re: [linux-sunxi] Re: [PATCH v2 2/8] mfd: AXP20x: Add bindings documentation

2014-03-25 Thread Maxime Ripard
On Sat, Mar 22, 2014 at 03:11:57PM +0100, Carlo Caione wrote:
> > > +
> > > +Example:
> > > +
> > > +axp: axp20x@34 {
> > > + reg = <0x34>;
> > > + interrupt-parent = <&nmi_intc>;
> > > + interrupts = <0 8>;
> > > +
> > > + compatible = "x-powers,axp209";
> > > + interrupt-controller;
> > > + #interrupt-cells = <1>;
> > > +
> > > + regulators {
> > 
> > Do we really need that subnode ? it looks useless, and we already know
> > that we are defining regulators here.
> 
> What do you mean? We are defining the MFD and regulators are just one of
> the subsystem here.

I mean that it's useless.

> Moveover I'm using the "regulators" node in the
> regulators driver (using of_find_node_by_name()) to get the regulators
> configuration.

Can't you just use the of_node field of whatever struct device you
get?

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature


[linux-sunxi] [PATCH u-boot] Cleanup macro's in clock.c and clock.h

2014-03-25 Thread oliver+list
From: Olliver Schinagl 

I'm sending this patch mostly so I don't loose it. I have only compile tested 
it so far, but wanted to get peoples input anyway. I'm still debating if I 
should investigate the macro's available in u-boot to do log2 to reverse the 
2^n bitfield macro's.

This patch will need to be split into several more sensible chunks and goes 
against ian's cleanup branch v1. There are still a few things that need to be 
addressed, but its a start ;)

Olliver

Olliver Schinagl (1):
  Cleanups of various clock macro's

 arch/arm/cpu/armv7/sunxi/clock.c| 162 --
 arch/arm/cpu/armv7/sunxi/dram.c |  22 +-
 arch/arm/include/asm/arch-sunxi/clock.h | 370 ++--
 drivers/i2c/sunxi_i2c.c |   2 +-
 4 files changed, 373 insertions(+), 183 deletions(-)

-- 
1.8.3.2

-- 
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] [PATCH u-boot (sc)] Cleanups of various clock macro's

2014-03-25 Thread oliver+list
From: Olliver Schinagl 

This patch cleans up several macro's to remove magic values etc from
clock.c and clock.h. Casualties being dragged in are some macro's from
dram.c and the i2c driver.

Signed-off-by: Olliver Schinagl 
---
 arch/arm/cpu/armv7/sunxi/clock.c| 162 --
 arch/arm/cpu/armv7/sunxi/dram.c |  22 +-
 arch/arm/include/asm/arch-sunxi/clock.h | 370 ++--
 drivers/i2c/sunxi_i2c.c |   2 +-
 4 files changed, 373 insertions(+), 183 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c
index 980fb90..3472fc9 100644
--- a/arch/arm/cpu/armv7/sunxi/clock.c
+++ b/arch/arm/cpu/armv7/sunxi/clock.c
@@ -21,27 +21,38 @@ static void clock_init_safe(void)
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 
/* Set safe defaults until PMU is configured */
-   writel(AXI_DIV_1 << AXI_DIV_SHIFT |
-  AHB_DIV_2 << AHB_DIV_SHIFT |
-  APB0_DIV_1 << APB0_DIV_SHIFT |
-  CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
+   writel(CPU_AXI_CLK_DIV_RATIO(1) |
+  CPU_AHB_CLK_DIV_RATIO_2 |
+  CPU_APB0_CLK_DIV_RATIO_1 |
+  CPU_CLK_SRC_OSC24M,
   &ccm->cpu_ahb_apb0_cfg);
-   writel(PLL1_CFG_DEFAULT, &ccm->pll1_cfg);
+   writel(CCM_PLL1_CFG_N(16) |
+  CCM_PLL1_CFG_LCK_TMR_CTRL(2) |
+  CCM_PLL1_CFG_BIAS_CUR(16) |
+  CCM_PLL1_CFG_VCO_BIAS(8) |
+  CCM_PLL1_CFG_EN,
+  &ccm->pll1_cfg);
sdelay(200);
-   writel(AXI_DIV_1 << AXI_DIV_SHIFT |
-  AHB_DIV_2 << AHB_DIV_SHIFT |
-  APB0_DIV_1 << APB0_DIV_SHIFT |
-  CPU_CLK_SRC_PLL1 << CPU_CLK_SRC_SHIFT,
+   writel(CPU_AXI_CLK_DIV_RATIO(1) |
+  CPU_AHB_CLK_DIV_RATIO_2 |
+  CPU_APB0_CLK_DIV_RATIO_1 |
+  CPU_CLK_SRC_PLL1,
   &ccm->cpu_ahb_apb0_cfg);
 #ifdef CONFIG_SUN5I
/* Power on reset default for PLL6 is 2400 MHz, which is faster then
 * it can reliable do :|  Set it to a 600 MHz instead. */
-   writel(PLL6_CFG_DEFAULT, &ccm->pll6_cfg);
+   writel(CCM_PLL6_CFG_M(1) |
+  CCM_PLL6_CFG_K(1) |
+  CCM_PLL6_CFG_N(25) |
+  CCM_PLL6_CFG_BW_WIDE |
+  CCM_PLL6_BIAS_CUR(16) |
+  CCM_PLL6_VCO_BIAS(16),
+  &ccm->pll6_cfg);
 #endif
 #ifdef CONFIG_SUN7I
writel(0x1 << AHB_GATE_OFFSET_DMA | readl(&ccm->ahb_gate0),
   &ccm->ahb_gate0);
-   writel(0x1 << PLL6_ENABLE_OFFSET | readl(&ccm->pll6_cfg),
+   writel(CCM_PLL6_CFG_EN | readl(&ccm->pll6_cfg),
   &ccm->pll6_cfg);
 #endif
 }
@@ -57,21 +68,33 @@ int clock_init(void)
 #endif
 
/* uart clock source is apb1 */
-   sr32(&ccm->apb1_clk_div_cfg, 24, 2, APB1_CLK_SRC_OSC24M);
-   sr32(&ccm->apb1_clk_div_cfg, 16, 2, APB1_FACTOR_N);
-   sr32(&ccm->apb1_clk_div_cfg, 0, 5, APB1_FACTOR_M);
+   clrsetbits_le32(&ccm->apb1_clk_div_cfg,
+   CCM_APB1_CLK_SRC_OSC24M, CCM_APB1_CLK_SRC_OSC24M);
+   clrsetbits_le32(&ccm->apb1_clk_div_cfg,
+   CCM_APB1_CLK_N_1, CCM_APB1_CLK_N_1);
+   clrsetbits_le32(&ccm->apb1_clk_div_cfg,
+   CCM_APB1_CLK_M(1), CCM_APB1_CLK_M(1));
 
/* open the clock for uart */
-   sr32(&ccm->apb1_gate, 16 + CONFIG_CONS_INDEX - 1, 1, CLK_GATE_OPEN);
+   clrsetbits_le32(&ccm->apb1_clk_div_cfg,
+   CCM_APB_GATE_UART(
+   SUNXI_CONS_TO_UART(CONFIG_CONS_INDEX)),
+   CCM_APB_GATE_UART(
+   SUNXI_CONS_TO_UART(CONFIG_CONS_INDEX)));
 
 #ifdef CONFIG_NAND_SUNXI
/* nand clock source is osc24m */
-   sr32(&ccm->nand_sclk_cfg, 24, 2, NAND_CLK_SRC_OSC24);
-   sr32(&ccm->nand_sclk_cfg, 16, 2, NAND_CLK_DIV_N);
-   sr32(&ccm->nand_sclk_cfg, 0, 4, NAND_CLK_DIV_M);
-   sr32(&ccm->nand_sclk_cfg, 31, 1, CLK_GATE_OPEN);
+   clrsetbits_le32(&ccm->nand_sclk_cfg,
+   CCM_NAND_SCLK_SRC_OSC24M, CCM_NAND_SCLK_SRC_OSC24M);
+   clrsetbits_le32(&ccm->nand_sclk_cfg,
+   CCM_NAND_SCLK_N_1, CCM_NAND_SCLK_N_1);
+   clrsetbits_le32(&ccm->nand_sclk_cfg,
+   CCM_NAND_SCLK_M(1), CCM_NAND_SCLK_M(1));
+   clrsetbits_le32(&ccm->nand_sclk_cfg,
+   CCM_NAND_SCLK_GATE_EN, CCM_NAND_SCLK_GATE_EN);
/* open clock for nand */
-   sr32(&ccm->ahb_gate0, AHB_GATE_OFFSET_NAND, 1, CLK_GATE_OPEN);
+   clrsetbits_le32(&ccm->nand_sclk_cfg,
+   CCM_AHB_GATE_NAND, CCM_AHB_GATE_NAND);
 #endif
 
return 0;
@@ -85,9 +108,10 @@ unsigned int clock_get_pll5(void)
struct sunxi_ccm_reg *const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
uint32_t rval = readl(&ccm->pll5_cfg);
-   int n = (rval >> 8) & 0x1f;
-   int k = ((rval >> 4) & 3) + 1;
-

[linux-sunxi] Re: [RFC 3.4] sunxi: try to enable Cortex-A7 performance counters on Allwinner A20

2014-03-25 Thread mrullgard
On Saturday, February 15, 2014 7:29:01 PM UTC, Siarhei Siamashka wrote:
> Based on reading the A20 user manual, it looks like the same
> single PLE/PERFMU IRQ is supposed to be used for the CPU
> performance counters as on Allwinner A10. This is already suspicious,
> because normally each CPU core in a dual-core system should have
> its own performance monitoring unit IRQ as explained in:
> 
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/181392/focus=181597
> 
> Still assuming that this is the case and borrowing the code
> from db8500 does not work. No interrupts are arriving at all.
> 
> Is there anything special needed to make sure that the performance
> monitoring unit interrupts are routed correctly on Allwinner A20?
> 
> Now that Cortex-A7 and GIC are both ARM IP, one might assume that
> they perhaps should be able to play nicely together without
> involving anything that is Allwinner specific.
> 
> Any ideas? The perf/oprofile tools are very useful for identifying
> performance bottlenecks and optimizing software. They work nicely
> on Allwinner A10. It would be great if Allwinner A20 could be
> supported too.

The lack of perf support on this chip is becoming increasingly annoying
to me as well.  I'd be happy to help get it working in any way I can.

-- 
Mans Rullgard

-- 
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: A10-meminfo: DRAMC settings dump utility

2014-03-25 Thread Olliver Schinagl

On 03/25/2014 02:43 AM, ra...@nlss.com wrote:

On Sunday, November 18, 2012 1:16:28 PM UTC-8, Max wrote:

Hi,



I experimented a bit with dumping the A10 memory settings using /dev/mem

under Linux/Android, and that seems to work.

At least on my Cubieboard 1 GB and Hackberry 512 MB.



I was wondering if someone with a different A10 board could give it a

try, and tell me if the results it outputs are correct.





Source code and a static binary is available at:

https://github.com/maxnet/a10-meminfo



On Linux simply execute a10-meminfo-static as root.

To run it under Android use one of the terminal apps to start it.

(If you downloaded the executable with the Android browser to

/sdcard/Downloads, make sure you move it to a different location first

as /sdcard is mounted noexec)



Will see if I can write an easier to use Android app to display the

information, if the utility works correctly.





Yours sincerely,



Floris Bos


Got a question : Since the mmap flag set to O_RDWR|O_SYNC, is it possible to 
write something to the CCM register to alter DRAM PLL to a bit smaller value? 
Seeing a lot of problems with the high DRAM clk and there does not seem to be a 
easy way to alter the DRAM clock setting (booting from Nand)

only the bootloader can modify ram parameters, as changing it results in 
ereased/corrupted ram. So no, there is no easy way.


--
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] [A20] sunxi framebuffer overlay help needed

2014-03-25 Thread Ivan Kozic
Hi Luc and thanks for replying,

Not sure I follow - I went deeper into the Qt structure yesterday. 
Basically, Qt uses just a normal linux fb access (opens /dev/fb0 directly), 
while my current no-GUI application (only used to display video from CSI) 
is using more "advanced" way - it opens /dev/disp first and then requests a 
layer from it, eventually opening /dev/fb just to execute 
FBIOGET_LAYER_HDL_0 ioctl and then closes it. Afterwards, I just have an 
endless loop in the program in which buffers from V4L2 exchange addresses 
with buffers from display.

To my understanding (I'm a bit fresh with all this), Qt should actually 
also open /dev/disp and request a GUI layer (think it's called YUV layer in 
the user manual for A20) for it, while my underlying V4L2 library should do 
the same, but only requesting video layer instead of a GUI layer. This way, 
underlying lib would do the video and provide controls, while overlay would 
be in a different layer providing GUI which is linked with the controls. Is 
this true?

If so, there is no easy way to do it, as I would have to implement a 
different display driver for Qt which would use layers instead of stupidly 
opening /dev/fb0 (this is quite some work) + update my underlying library 
to actually use display, again with layering. Just saying - compared to 
Freescale kernel, this is far from walk in the park. As I said before, 
Freescale provides a separate /dev/fb for every layer of the screen, which 
is much easier to work with.

But as I said, I might be completely wrong - what did you have in mind?

On Monday, March 24, 2014 3:17:42 PM UTC+1, Luc Verhaegen wrote:
>
> On Mon, Mar 24, 2014 at 07:00:39AM -0700, Ivan Kozic wrote: 
> > Hi all, 
> > 
> > Up to now, I have successfully debugged and fixed CSI issues in 3.4 
> kernel 
> > so that it works more-less closer to the spec of sun7i (driver is only 
> > sun4i compatible by default - for more advanced features, you'll need 
> some 
> > changes in the code). For more info, you can visit: 
> > 
> > 
> https://groups.google.com/forum/#!searchin/linux-sunxi/A20$20csi/linux-sunxi/vU5-3Pc3iOs/aVpmpfb1FkAJ
>  
> > 
> > This is all for A20 or sun7i (as I have Olinuxino A20). 
> > 
> > Right now I'd need some help regarding overlay framebuffer - my initial 
> > idea was to have a full screen video, while having a small functional 
> GUI 
> > (more like a widget) on the overlay channel to use for controls (this 
> would 
> > be done using Qt). 
> > However, this seems to be much harder than on i.MX6 for instance (I have 
> > previous experience with i.MX6), mainly because Freescale is using 2 
> > separate framebuffers for one screen. So to sum up: 
> > 1. fb0 is BG (video for instance), 
> > 2. fb1 is FG (overlay, ideal for GUI). 
> > 
> > When I look at the HW layout (especially page 414 of the A20 user 
> manual), 
> > I see that the Allwinner's intent was to make something similar, as DEBE 
> > does the mixing of the overlay/background. However, the driver does not 
> > seem to have such an option (or I am not familiar with this). 
> > 
> > At the end, I can make video show up in Qt - this is not a huge problem 
> (I 
> > have taken libv4l2 made for Qt and I get the output) - the problem is 
> that 
> > it's painfully slow (like barely 3fps), as it doesn't use HW mixer - it 
> > only copies the data from V4L2 buffers into the userland and into QImage 
> > object, which is quite slow. 
> > 
> > So the way it would have worked on i.MX6 is that video is simply driven 
> > into fb0 via small library using DMA, while Qt would be configured to 
> use 
> > fb1 only - I'm after something like this on A20. 
> > Maybe I'm missing something obvious here, but still I couldn't find a 
> good 
> > solution up to now. 
> > 
> > Of course, if I find something out, I'll post back. 
> > 
> > All help greatly appreciated! 
>
> You only need DEFE for your CSI captured information, as that is in some 
> non RGB colour format. 
>
> You can happily attach RGB32 to any layer directly, and achieve your 
> goal that way. 
>
> Luc Verhaegen. 
>
>
>

-- 
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 v5 1/7] clk: sunxi: Remove calls to clk_put

2014-03-25 Thread Maxime Ripard
Hi Mike,

On Mon, Mar 24, 2014 at 02:51:20PM -0700, Mike Turquette wrote:
> Quoting Maxime Ripard (2014-03-13 08:14:13)
> > Callers of clk_put must disable the clock first. This also means that as 
> > long
> > as the clock is enabled the driver should hold a reference to that clock.
> > Hence, the call to clk_put here are bogus and should be removed.
> > 
> > Signed-off-by: Maxime Ripard 
> 
> Looks good to me. There is a balanced clk_put in the module remove
> function?

Actually, this is not part of any module, it's part of the function
called through CLK_OF_DECLARE, so there's never a remove function for
this code.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature