Re: [linux-sunxi] Re: Build sunxi-next for A20

[hmandevteam]

Hi Priit,

> You need at least version 3.12 of Linus' tree because support for
> A20-OLinuXino was only added then:
> http://linux-sunxi.org/Mainlining_Effort
> To test the latest goodness like SATA and USB follow this page:
> http://linux-sunxi.org/Mainline_Kernel_Howto
i follow howto and using
$ git clone https://github.com/mripard/linux.git -b sunxi-next
$ make ARCH=arm multi_v7_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x40008000 -j4 
uImage
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j4 INSTALL_MOD_PATH=out 
modules
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j4 INSTALL_MOD_PATH=out 
modules_install

i obtained uImage tha is about same size of kernel 3.4 stable (it's a good 
thing) but few modules generated (also i saw that kernel modules folder name 
have a suffix: 3.14.0-rc5-01389-ge8176a3).

i tryed to update my sd with uImage and kernel modules generated but my 
olinuxino A20 don't start.



-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: How to decide NAND boot address?

[hunter hu]

Thanks Pat,

I have used the correct syntax, but still, stuck at the SUNXI logo; at this 
moment I have a few questions:

1> my cpu is A13, your u-boot is for A20, I would think that is not working 
for me?

2> I have been using lichee-dev, sun5i_a13 board, trying to modify the 
configurations as shown before;  when I was adding my board to the 
u-boot-sunxi, I had to add a dram_myboard.c to configure the DRAM by 
following the sunxi wiki instructions, I tried to do with and without the 
DRAM stuff, the same, stuck at the logo, I believe I have to get the serial 
port working first.

Thank you very much for all help so far, I greatly appreciated.

-Hunter

On Wednesday, March 5, 2014 9:35:06 PM UTC-6, Patrick Wood wrote:
>
> fatload nand 0 kernel_address kernel_file
>
> Note that my u-boot is based on a heavily-modified version of the one used 
> by android.
>
> On Wednesday, March 5, 2014 10:10:03 PM UTC-5, hunter hu wrote:
>>
>> Hi Pat,
>>
>> I was not be able to get serial port access yet, work in progress.
>>
>> Regarding the syntax, what are the correct ones?
>>
>> thanks,
>> -Hunter
>>
>> On Wednesday, March 5, 2014 8:51:22 PM UTC-6, Patrick Wood wrote:
>>>
>>> That's not the right syntax for file access. Don't you have a serial 
>>> port you can get boot logs from?
>>
>>

-- 
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/groups/opt_out.

Re: [linux-sunxi] Possible G2D kernel bug

[Siarhei Siamashka]

On Wed, 05 Mar 2014 20:32:42 +0100
Andreas Baierl  wrote:

> Am 04.03.2014 11:56, schrieb Andreas Baierl:
> > Hi all,
> > it seems, that the G2D kernel driver has some issue:
> >
> > libvdpau-sunxi uses G2D_CMD_BITBLT for creating surfaces, so at the 
> > end of mixer_blt, there is g2d_wait_cmd_finish() called.
> > As soon as (timeout==0) gets TRUE in 
> > https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/char/sunxi_g2d/g2d.c#L120
> >  
> > , g2d stops working.
> > It's not possible to interact with /dev/g2d anymore until you reboot 
> > (or possibly un-/reload the module).
> >
> > I'm not sure how to exactly reproduce that. It mostly occurs the 
> > second time i start VDR with libvdpau-sunxi and OSD.
> >
> > Regards
> > rellla
> >
> I don't know if it's related to the above, but unloading the kernel 
> module g2d_23 after it stopped working with the "wait g2d irq pending 
> flag timeout" message shows me the following log:
> 
> [  735.058259] [DISP] layer allocated: 0,102
> [  735.065332] [DISP] layer allocated: 0,103
> [  735.227857] wait g2d irq pending flag timeout
> [  783.215100] [DISP] layer released: 0,102
> [  783.222385] [DISP] layer released: 0,103
> [  792.500779] [DISP] layer released: 0,101
> [  792.541549] UMP<2>: Session closed
> [  795.070534] G2D: g2d_module_exit
> [  795.080032] G2D: Driver unloaded succesfully.
> [  795.092261] [ cut here ]
> [  795.105471] WARNING: at drivers/base/core.c:196 
> device_release+0x78/0x84()
> [  795.122342] Device 'g2d' does not have a release() function, it is 
> broken and must be fixed.
> [  795.135209] Modules linked in: disp_ump mali_drm drm g2d_23(-) 
> sunxi_cedar_mod sw_ahci_platform mali ump
> [  795.162378] [] (unwind_backtrace+0x0/0x138) from 
> [] (warn_slowpath_common+0x4c/0x64)
> [  795.183234] [] (warn_slowpath_common+0x4c/0x64) from 
> [] (warn_slowpath_fmt+0x30/0x40)
> [  795.203586] [] (warn_slowpath_fmt+0x30/0x40) from 
> [] (device_release+0x78/0x84)
> [  795.223412] [] (device_release+0x78/0x84) from [] 
> (kobject_release+0x98/0x1bc)
> [  795.244079] [] (kobject_release+0x98/0x1bc) from 
> [] (g2d_module_exit+0x34/0x68 [g2d_23])
> [  795.266065] [] (g2d_module_exit+0x34/0x68 [g2d_23]) from 
> [] (sys_delete_module+0x1ac/0x28c)
> [  795.287740] [] (sys_delete_module+0x1ac/0x28c) from 
> [] (ret_fast_syscall+0x0/0x30)
> [  795.304222] ---[ end trace ec0a564270cd7879 ]---

It just says that the driver does not provide the release() function.

These drivers are were poorly coded and apparently were never supposed
to be even loaded/unloaded at runtime. I fixed some of the really grave
show stopper problems earlier, but did not touch the rest:
- "sunxi-g2d: Fix mismatch between request_irq and free_irq"
 https://github.com/linux-sunxi/linux-sunxi/commit/bf2445b68175d0f2
- "sunxi: cedar: Fix oops on loading/unloading the cedar module"
 https://github.com/linux-sunxi/linux-sunxi/commit/4457f3998a6f57af

The Allwinner G2D driver bundles its own funky memory allocation API
for the userland and it would make sense to make sure that all the
resources are released properly. However since I have never tried to
use this allocator, I just don't want to touch it and have no means to
test it. I would be even in favour of just dropping this memory
allocation and mapping code, but supposedly this might be used by
Android (by the mythical users of the linux-sunxi kernels).

For Linux it makes a lot of sense to have a new driver for G2D
hardware, leaving the old driver alone just for Android use.

-- 
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/groups/opt_out.

Re: [linux-sunxi] [PATCH] arch/arm/mach-sun7i/pm/standby/mem_printk.c used non-const char arrays. However gcc 4.6.3 likes to replace these by calls to memcpy. memcpy doesn't exist in the kernel. Havin

[Patrick Wood]

On Wednesday, March 5, 2014 5:55:50 PM UTC-5, Alejandro Mery wrote:
>
>
> On 05/03/14 16:14, Andreas Baierl wrote: 
> > Hi Alejandro, 
> > this patch breaks building because it's not applied as Danny sent it :) 
>
> yes, I couldn't "apply" it because of ^Ms... but compiled fine for me 
>
> I'm kind of lost on why is `const char foo* =` instead of `const char 
> foo[] =`. 
>
 
This has to do with how arrays vs. pointers are initialized by the compiler 
at runtime.  A pointer like char *p (or const char *p) is initialized by 
simply setting its value to the address of some string in the data area. 
 An automatic array (on the stack) has storage that must be initialized 
with the actual contents of the string every time the function is called; 
memcpy is one way to do this.  But if memcpy isn't available because libc 
isn't available


> can you show the error? 
>
>  
These should all be declared "const char *" not "const char ...[]"

Pat

-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: How to decide NAND boot address?

[Patrick Wood]

fatload nand 0 kernel_address kernel_file

Note that my u-boot is based on a heavily-modified version of the one used 
by android.

On Wednesday, March 5, 2014 10:10:03 PM UTC-5, hunter hu wrote:
>
> Hi Pat,
>
> I was not be able to get serial port access yet, work in progress.
>
> Regarding the syntax, what are the correct ones?
>
> thanks,
> -Hunter
>
> On Wednesday, March 5, 2014 8:51:22 PM UTC-6, Patrick Wood wrote:
>>
>> That's not the right syntax for file access. Don't you have a serial port 
>> you can get boot logs from?
>
>

-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: How to decide NAND boot address?

[hunter hu]

Hi Pat,

I was not be able to get serial port access yet, work in progress.

Regarding the syntax, what are the correct ones?

thanks,
-Hunter

On Wednesday, March 5, 2014 8:51:22 PM UTC-6, Patrick Wood wrote:
>
> That's not the right syntax for file access. Don't you have a serial port 
> you can get boot logs from?

-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: How to decide NAND boot address?

[Patrick Wood]

That's not the right syntax for file access. Don't you have a serial port you 
can get boot logs from?

-- 
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/groups/opt_out.

Re: [linux-sunxi] [PATCH] arch/arm/mach-sun7i/pm/standby/mem_printk.c used non-const char arrays. However gcc 4.6.3 likes to replace these by calls to memcpy. memcpy doesn't exist in the kernel. Havin

[Alejandro Mery]

On 05/03/14 16:14, Andreas Baierl wrote:

Hi Alejandro,
this patch breaks building because it's not applied as Danny sent it :)


yes, I couldn't "apply" it because of ^Ms... but compiled fine for me

I'm kind of lost on why is `const char foo* =` instead of `const char 
foo[] =`.


can you show the error?

--
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/groups/opt_out.

Re: [linux-sunxi] Re: How to decide NAND boot address?

[hunter hu]

Hi Henrik,

I tried to use fatload in the configurations like these:
182 #define CONFIG_EXTRA_ENV_SETTINGS \
183 "bootdelay=3\0" \
184 "bootcmd=run setargs load_uimage boot_uimage\0" \
185 "console=ttyS0,115200\0" \
186 "nand_root=/dev/nandb\0" \
187 "init=/init\0" \
188 "loglevel=8\0" \
189 "setargs=setenv bootargs console=${console} root=${nand_root}" \
190 "init=${init} loglevel=${loglevel}\0" \
191 "load_uimage=fatload nanda 4400 uImage\0" \
192 "boot_uimage=bootm 4400\0"
193 
194 #define CONFIG_BOOTDELAY1
195 #define CONFIG_BOOTCOMMAND  "fatload nanda 4400 uImage;bootm 
4400"
196 #define CONFIG_SYS_BOOT_GET_CMDLINE
197 #define CONFIG_AUTO_COMPLETE


But I am still stuck at the SUNXI logo(that part I got it :-) ), anything 
wrong with the above configurations?

Thanks,
-Hunter


On Tuesday, March 4, 2014 11:30:43 AM UTC-6, Henrik Nordström wrote:
>
> The lichee u-boot also support fat access, just use fatload instead of 
> nand command to load files. 
>
> mån 2014-03-03 klockan 16:41 -0800 skrev Patrick Wood: 
> > This version of uboot loads the entire partition into RAM, not the 
> > uImage file.  You need a modified uboot that can be set up more like 
> > the one that's used on SD 
> > cards: http://www.cubieforums.com/index.php?topic=511.0 
> > 
> > 
> > Pat 
> > 
> > On Monday, March 3, 2014 4:00:55 PM UTC-5, hunter hu wrote: 
> > Thanks Patrick, 
> > 
> > 
> > Does this mean I don't need to change the default 5000 at 
> > all? 
> > 
> > 
> > My intention is to load Linux instead of Android from NAND and 
> > following this sunxi 
> > wiki: http://linux-sunxi.org/Installing_to_NAND. 
> > 
> > 
> > What changes need to be made in the uboot env besides 
> > the /dev/nandd -> /dev/nandb? 
> > 
> > 
> > -Hunter 
> > 
> > On Monday, March 3, 2014 2:45:21 PM UTC-6, Patrick Wood wrote: 
> > That's not the nand read address; that's the RAM 
> > address where the nand read command stores data read 
> > from nand.  The last argument (boot, recovery) is the 
> > nand partition name where it's reading data. 
> > 
> > 
> > This is how an android kernel+initrd is loaded. 
> > 
> > On Monday, March 3, 2014 2:42:17 PM UTC-5, hunter hu 
> > wrote: 
> > Hi All, 
> > 
> > 
> > I am trying to boot from NAND, and using 
> > Allwinner lichee-dev branch, in the 
> > sun5i_a13.h header, there is a section of hard 
> > coded environment setup like this: 
> > 
> > 
> > 81 #define CONFIG_EXTRA_ENV_SETTINGS \ 
> > 182 "bootdelay=3\0" \ 
> > 183 "bootcmd=run setargs boot_normal\0" \ 
> > 184 "console=ttyS0,115200\0" \ 
> > 185 "nand_root=/dev/nandd\0" \ 
> > 186 "mmc_root=/dev/mmcblk0p4\0" \ 
> > 187 "init=/init\0" \ 
> > 188 "loglevel=8\0" \ 
> > 189 "setargs=setenv bootargs console= 
> > ${console} root=${nand_root}" \ 
> > 190 "init=${init} loglevel=${loglevel}\0" 
> > \ 
> > 191 "boot_normal=nand read 5000 boot; 
> > boota 5000\0" \ 
> > 192 "boot_recovery=nand read 5000 
> > recovery; boota 5000\0" \ 
> > 193 "boot_fastboot=fastboot\0" 
> > 
> > My question is: how do I find the nand read 
> > address of my own instead of default 5000? 
> > 
> > 
> > My nand-part on the tablet looks like: 
> > 
> > 
> >   9 mbr: version 0x0100, magic softw311 
> >  10 2 partitions 
> >  11 partition  1: class = DISK, name = 
> > boot, partition start =32768, partition 
> > size =52768 user_type=0 
> >  12 partition  2: class = DISK, name = 
> > root, partition start =85536, partition 
> > size = 15479264 user_type=0 
> >   
> > Is that 

[linux-sunxi] [PATCH] regulator: helpers: Modify helpers enabling multi-bit control

[Carlo Caione]

This patch extends the regulator helpers to account for device that use
multiple bits for control when using regmap enable/disable/bypass ops.

The actual regulator helpers wrongly assume that the regulator control
is always performed using single bits, using in the regulator_desc
struct only two parameters *_reg and *_mask defining register and mask
for control.

This patch extends this struct and introduces the helpers to take into
account devices where control is performed using multiple bits and
specific multi-bit values are used for enabling/disabling/bypassing the
regulator.

Signed-off-by: Carlo Caione 
---
 drivers/regulator/helpers.c  | 48 ++--
 include/linux/regulator/driver.h |  8 +++
 2 files changed, 40 insertions(+), 16 deletions(-)

diff --git a/drivers/regulator/helpers.c b/drivers/regulator/helpers.c
index e221a27..cbc3909 100644
--- a/drivers/regulator/helpers.c
+++ b/drivers/regulator/helpers.c
@@ -37,10 +37,17 @@ int regulator_is_enabled_regmap(struct regulator_dev *rdev)
if (ret != 0)
return ret;
 
-   if (rdev->desc->enable_is_inverted)
-   return (val & rdev->desc->enable_mask) == 0;
-   else
-   return (val & rdev->desc->enable_mask) != 0;
+   val &= rdev->desc->enable_mask;
+
+   if (rdev->desc->enable_is_inverted) {
+   if (rdev->desc->enable_val)
+   return val != rdev->desc->enable_val;
+   return val == 0;
+   } else {
+   if (rdev->desc->enable_val)
+   return val == rdev->desc->enable_val;
+   return val != 0;
+   }
 }
 EXPORT_SYMBOL_GPL(regulator_is_enabled_regmap);
 
@@ -57,10 +64,13 @@ int regulator_enable_regmap(struct regulator_dev *rdev)
 {
unsigned int val;
 
-   if (rdev->desc->enable_is_inverted)
-   val = 0;
-   else
-   val = rdev->desc->enable_mask;
+   if (rdev->desc->enable_is_inverted) {
+   val = rdev->desc->disable_val;
+   } else {
+   val = rdev->desc->enable_val;
+   if (!val)
+   val = rdev->desc->enable_mask;
+   }
 
return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
  rdev->desc->enable_mask, val);
@@ -80,10 +90,13 @@ int regulator_disable_regmap(struct regulator_dev *rdev)
 {
unsigned int val;
 
-   if (rdev->desc->enable_is_inverted)
-   val = rdev->desc->enable_mask;
-   else
-   val = 0;
+   if (rdev->desc->enable_is_inverted) {
+   val = rdev->desc->enable_val;
+   if (!val)
+   val = rdev->desc->enable_mask;
+   } else {
+   val = rdev->desc->disable_val;
+   }
 
return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
  rdev->desc->enable_mask, val);
@@ -419,10 +432,13 @@ int regulator_set_bypass_regmap(struct regulator_dev 
*rdev, bool enable)
 {
unsigned int val;
 
-   if (enable)
-   val = rdev->desc->bypass_mask;
-   else
-   val = 0;
+   if (enable) {
+   val = rdev->desc->bypass_val_on;
+   if (!val)
+   val = rdev->desc->bypass_mask;
+   } else {
+   val = rdev->desc->bypass_val_off;
+   }
 
return regmap_update_bits(rdev->regmap, rdev->desc->bypass_reg,
  rdev->desc->bypass_mask, val);
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 9370e65..bbe03a1 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -228,10 +228,14 @@ enum regulator_type {
  *output when using regulator_set_voltage_sel_regmap
  * @enable_reg: Register for control when using regmap enable/disable ops
  * @enable_mask: Mask for control when using regmap enable/disable ops
+ * @enable_val: Enabling value for control when using regmap enable/disable ops
+ * @disable_val: Disabling value for control when using regmap enable/disable 
ops
  * @enable_is_inverted: A flag to indicate set enable_mask bits to disable
  *  when using regulator_enable_regmap and friends APIs.
  * @bypass_reg: Register for control when using regmap set_bypass
  * @bypass_mask: Mask for control when using regmap set_bypass
+ * @bypass_val_on: Enabling value for control when using regmap set_bypass
+ * @bypass_val_off: Disabling value for control when using regmap set_bypass
  *
  * @enable_time: Time taken for initial enable of regulator (in uS).
  */
@@ -263,9 +267,13 @@ struct regulator_desc {
unsigned int apply_bit;
unsigned int enable_reg;
unsigned int enable_mask;
+   unsigned int enable_val;
+   unsigned int disable_val;
bool enable_is_inverted;
unsigned int bypass_reg;
unsigne

Re: [linux-sunxi] Re: [PATCH 0/7] mfd: AXP20x: Add support for AXP202 and AXP209

[Carlo Caione]

On Wed, Mar 5, 2014 at 9:02 PM, Hans de Goede  wrote:
>
> So I've added your patches to my sunxi-devel tree and they work as advertised 
> :)

Thank you for keeping the tree updated :)

> I've also added dt support for the axp209 to the cubietruck dts file, to avoid
> things becoming a copy and paste fest I've introduced a new axp209.dtsi file,
> as well as did some fixes to the existing sun?i-a*.dtsi files, see my tree 
> here:
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel

That was also my idea (creating a new axp20x.dtsi) but it has been
turned down by Maxime and Lee

> If you agree this is a good idea feel free to steal it all for the next
> revision of your patch-set :)

I will do for sure, thanks

> Note that I've still left some copy-paste parts inside the per board dts 
> files,
> specifically things which may differ per board, ie we know already that A10
> boards will have a different interrupt parent for the interrupt.

Yep, no prob.

> Thanks for your work on this!

Thank you!

-- 
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/groups/opt_out.

[linux-sunxi] sunxi-devel branch updated to 3.14-rc5

[Hans de Goede]

Hi All,

I've just updated: 
https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel
to 3.14-rc5.

Besides rebasing to 3.14-rc5, this contains the following over the previous
sunxi-devel branch update:
-sun7i nmi irq controller support (by Carlo Caione)
-axp209 support (by Carlo Caione)
-sun6i dma controller support (by Maxime)
-sun6i i2c support (by Maxime)
-sun6i gmac support (by wens)

The sunxi-devel branch now contains 3.14-rc5

+ the following, which should all go upstream for 3.15:
  https://github.com/mripard/linux/commits/dt-for-3.15
  https://bitbucket.org/emiliolopez/linux/branch/sunxi-clk-for-mike
  ahci_platform rework into a library / framework
  sunxi-ahci support
  ehci_ + ohci_platform devicetree support
  sunxi-usb-phy
  sunxi-ohci + sunxi-ehci support
  sunxi-pinctrl bug-fixes

+ the following which is not quite ready for 3.15 yet, but people
are working hard to get it ready so hopefully we will see some of
it in 3.15, and the rest should make 3.16:

  Emilio's sunxi-clk branch: patches not part of the above set
  David's and mine sunxi-mmc work
  Wens cubietruck wifi support patches (wip)
  sun4i-ts resisitive touchscreen controller + temp sensor driver
  sun4i-lradc-keys driver
  sun7i nmi irq controller support (by Carlo Caione)
  axp209 support (by Carlo Caione)
  sun6i dma controller support (by Maxime)
  sun6i i2c support (by Maxime)
  sun6i gmac support (by wens)

Note for this to work properly on sun7i and sun5i you also need my
sunxi-next u-boot branch:
https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next

Enjoy,

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/groups/opt_out.

Re: [linux-sunxi] Re: [PATCH 0/7] mfd: AXP20x: Add support for AXP202 and AXP209

[Hans de Goede]

Hi,

On 03/01/2014 08:29 PM, Hans de Goede wrote:
> Hi,
> 
> On 03/01/2014 06:17 PM, Carlo Caione wrote:
>> On Sat, Mar 1, 2014 at 5:56 PM, Hans de Goede  wrote:
>>> Hi Carlo,
>>>
>>> Great work, thanks for all the time you're putting into this!
>>
>> Hi Hans :)
>>
>>> I've 2 questions:
>>>
>>> 1) What dependencies does this patch-set have? Obviously it needs the NMI 
>>> irq
>>> patches for A20, anything else ?  I no longer see any use of a special flag
>>> for ack on unmask, is that no longer needed ?
>>
>> Yes, the only dependency is on the NMI controller patch.
>> After a discussion with Maxime and Thomas I decided to not push for
>> including the special flag for ack on unmask in the irqchip core but
>> to use the unmask callback as in the v3 version of the NMI controller
>> driver (so no flag needed)
>>
>>> 2) No poweroff functionality ? That would be really great to have.
>>
>> Actually in [PATCH 1/7] I support the poweroff using the pm_power_off hook.
> 
> Ah I missed that, cool.
> 
> I'm doing with sunxi hacking for today, but I'll add these to sunxi-devel
> and them give them a test run tomorrow.

So I've added your patches to my sunxi-devel tree and they work as advertised :)

I've also added dt support for the axp209 to the cubietruck dts file, to avoid
things becoming a copy and paste fest I've introduced a new axp209.dtsi file,
as well as did some fixes to the existing sun?i-a*.dtsi files, see my tree here:
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel

If you agree this is a good idea feel free to steal it all for the next
revision of your patch-set :)

Note that I've still left some copy-paste parts inside the per board dts files,
specifically things which may differ per board, ie we know already that A10
boards will have a different interrupt parent for the interrupt.

Thanks for your work on this!

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/groups/opt_out.

[linux-sunxi] [PATCH v5 2/3] ARM: sun7i/sun6i: dts: Add NMI irqchip support

[Carlo Caione]

This patch adds DTS entries for NMI controller as child of GIC.

Signed-off-by: Carlo Caione 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 9 +
 arch/arm/boot/dts/sun7i-a20.dtsi | 9 +
 2 files changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 5256ad9..4a5050c 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -190,6 +190,15 @@
#size-cells = <1>;
ranges;
 
+   nmi_intc: sc-nmi-intc@01f00c0c {
+   compatible = "allwinner,sun6i-a31-sc-nmi";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x01f00c0c 0x38>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 0 4>;
+   };
+
pio: pinctrl@01c20800 {
compatible = "allwinner,sun6i-a31-pinctrl";
reg = <0x01c20800 0x400>;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 4c25f81..f01a23c 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -310,6 +310,15 @@
#size-cells = <1>;
ranges;
 
+   nmi_intc: sc-nmi-intc@01c00030 {
+   compatible = "allwinner,sun7i-a20-sc-nmi";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x01c00030 0x0c>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 0 4>;
+   };
+
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-emac";
reg = <0x01c0b000 0x1000>;
-- 
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/groups/opt_out.

[linux-sunxi] [PATCH v5 0/3] ARM: sun7i/sun6i: irqchip: Irqchip driver for NMI

[Carlo Caione]

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.

Changes since v1:
- added binding document

Changes since v2:
- fixed trigger type in DTS
- new explanations in binding documentation
- added support for A31 (sun6i)

Changes since v3:
- changed compatibles

Changes since v4:
- fixed binding documentation

Carlo Caione (3):
  ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
  ARM: sun7i/sun6i: dts: Add NMI irqchip support
  ARM: sun7i/sun6i: irqchip: Update the documentation

 .../allwinner,sun67i-sc-nmi.txt|  27 +++
 arch/arm/boot/dts/sun6i-a31.dtsi   |   9 +
 arch/arm/boot/dts/sun7i-a20.dtsi   |   9 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-sunxi-nmi.c| 228 +
 5 files changed, 274 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
 create mode 100644 drivers/irqchip/irq-sunxi-nmi.c

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH v5 3/3] ARM: sun7i/sun6i: irqchip: Update the documentation

[Carlo Caione]

Added documentation for NMI irqchip.

Signed-off-by: Carlo Caione 
---
 .../allwinner,sun67i-sc-nmi.txt| 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
new file mode 100644
index 000..d1c5cda
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
@@ -0,0 +1,27 @@
+Allwinner Sunxi NMI Controller
+==
+
+Required properties:
+
+- compatible : should be "allwinner,sun7i-a20-sc-nmi" or
+  "allwinner,sun6i-a31-sc-nmi"
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 2. The first cell is the IRQ number, the
+  second cell the trigger type as defined in interrupt.txt in this directory.
+- interrupt-parent: Specifies the parent interrupt controller.
+- interrupts: Specifies the interrupt line (NMI) which is handled by
+  the interrupt controller in the parent controller's notation. This value
+  shall be the NMI.
+
+Example:
+
+sc-nmi-intc@01c00030 {
+   compatible = "allwinner,sun7i-a20-sc-nmi";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x01c00030 0x0c>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 0 4>;
+};
-- 
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/groups/opt_out.

[linux-sunxi] [PATCH v5 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller

[Carlo Caione]

Allwinner A20/A31 SoCs have special registers to control / (un)mask /
acknowledge NMI. This NMI controller is separated and independent from GIC.
This patch adds a new irqchip to manage NMI.

Signed-off-by: Carlo Caione 
Acked-by: Maxime Ripard 
---
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/irq-sunxi-nmi.c | 228 
 2 files changed, 229 insertions(+)
 create mode 100644 drivers/irqchip/irq-sunxi-nmi.c

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c60b901..e31d4d6 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)  += irq-metag.o
 obj-$(CONFIG_ARCH_MOXART)  += irq-moxart.o
 obj-$(CONFIG_ORION_IRQCHIP)+= irq-orion.o
 obj-$(CONFIG_ARCH_SUNXI)   += irq-sun4i.o
+obj-$(CONFIG_ARCH_SUNXI)   += irq-sunxi-nmi.o
 obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)  += irq-gic.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
new file mode 100644
index 000..8796ae0
--- /dev/null
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -0,0 +1,228 @@
+/*
+ * Allwinner A20/A31 SoCs NMI IRQ chip driver.
+ *
+ * Carlo Caione 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "irqchip.h"
+
+#define SUNXI_NMI_SRC_TYPE_MASK0x0003
+
+enum {
+   SUNXI_SRC_TYPE_LEVEL_LOW = 0,
+   SUNXI_SRC_TYPE_EDGE_FALLING,
+   SUNXI_SRC_TYPE_LEVEL_HIGH,
+   SUNXI_SRC_TYPE_EDGE_RISING,
+};
+
+struct sunxi_sc_nmi_reg_offs {
+   u32 ctrl;
+   u32 pend;
+   u32 enable;
+};
+
+static struct sunxi_sc_nmi_reg_offs sun7i_reg_offs = {
+   .ctrl   = 0x00,
+   .pend   = 0x04,
+   .enable = 0x08,
+};
+
+static struct sunxi_sc_nmi_reg_offs sun6i_reg_offs = {
+   .ctrl   = 0x00,
+   .pend   = 0x04,
+   .enable = 0x34,
+};
+
+/*
+ * Ack level interrupts right before unmask
+ *
+ * In case of level-triggered interrupt, IRQ line must be acked before it
+ * is unmasked or else a double-interrupt is triggered
+ */
+
+static void sunxi_sc_nmi_ack_and_unmask(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   u32 mask = d->mask;
+
+   if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK)
+   ct->chip.irq_ack(d);
+
+   irq_gc_lock(gc);
+   irq_reg_writel(mask, gc->reg_base + ct->regs.mask);
+   irq_gc_unlock(gc);
+}
+
+static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
+ u32 val)
+{
+   irq_reg_writel(val, gc->reg_base + off);
+}
+
+static inline u32 sunxi_sc_nmi_read(struct irq_chip_generic *gc, u32 off)
+{
+   return irq_reg_readl(gc->reg_base + off);
+}
+
+static void sunxi_sc_nmi_handle_irq(unsigned int irq, struct irq_desc *desc)
+{
+   struct irq_domain *domain = irq_desc_get_handler_data(desc);
+   struct irq_chip *chip = irq_get_chip(irq);
+   unsigned int virq = irq_find_mapping(domain, 0);
+
+   chained_irq_enter(chip, desc);
+   generic_handle_irq(virq);
+   chained_irq_exit(chip, desc);
+}
+
+static int sunxi_sc_nmi_set_type(struct irq_data *data, unsigned int flow_type)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_chip_type *ct = gc->chip_types;
+   u32 src_type_reg;
+   u32 ctrl_off = ct->regs.type;
+   unsigned int src_type;
+   unsigned int i;
+
+   irq_gc_lock(gc);
+
+   switch (flow_type & IRQF_TRIGGER_MASK) {
+   case IRQ_TYPE_EDGE_FALLING:
+   src_type = SUNXI_SRC_TYPE_EDGE_FALLING;
+   break;
+   case IRQ_TYPE_EDGE_RISING:
+   src_type = SUNXI_SRC_TYPE_EDGE_RISING;
+   break;
+   case IRQ_TYPE_LEVEL_HIGH:
+   src_type = SUNXI_SRC_TYPE_LEVEL_HIGH;
+   break;
+   case IRQ_TYPE_NONE:
+   case IRQ_TYPE_LEVEL_LOW:
+   src_type = SUNXI_SRC_TYPE_LEVEL_LOW;
+   break;
+   default:
+   irq_gc_unlock(gc);
+   pr_err("%s: Cannot assign multiple trigger modes to IRQ %d.\n",
+   __func__, data->irq);
+   return -EBADR;
+   }
+
+   irqd_set_trigger_type(data, flow_type);
+   irq_setup_alt_chip(data, flow_type);
+
+   for (i = 0; i <= gc->num_ct; i++, ct++)
+   if (ct->type & flow_type)
+   ctrl_off = ct->regs.type;
+
+   src_type_reg = sunxi_sc_nmi_read(gc, ctrl_off);
+   src_type_reg &= ~SUN

[linux-sunxi] Re: [PATCH] ahci_imx: Put #ifdef CONFIG_PM_SLEEP around suspend / resume functions

[Alexander Shiyan]

Среда,  5 марта 2014, 20:23 +01:00 от Marek Vasut :
> On Wednesday, March 05, 2014 at 08:17:49 PM, Hans de Goede wrote:
> > This fixes the following warnings when CONFIG_PM_SLEEP is not set:
> > 
> > drivers/ata/ahci_imx.c:284:12: warning: ‘imx_ahci_suspend’ defined but not
> > used [-Wunused-function] drivers/ata/ahci_imx.c:299:12: warning:
> > ‘imx_ahci_resume’ defined but not used [-Wunused-function]
> > 
> > Reported-by: Bartlomiej Zolnierkiewicz 
> > Cc: Bartlomiej Zolnierkiewicz 
> > Signed-off-by: Hans de Goede 
> 
> Obviously makes sense.
> 
> Acked-by: Marek Vasut 

But a better way is to use the "__maybe_unused" attribute for such cases.

---

-- 
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/groups/opt_out.

Re: [linux-sunxi] Possible G2D kernel bug

[Andreas Baierl]

Am 04.03.2014 11:56, schrieb Andreas Baierl:

Hi all,
it seems, that the G2D kernel driver has some issue:

libvdpau-sunxi uses G2D_CMD_BITBLT for creating surfaces, so at the 
end of mixer_blt, there is g2d_wait_cmd_finish() called.
As soon as (timeout==0) gets TRUE in 
https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/char/sunxi_g2d/g2d.c#L120 
, g2d stops working.
It's not possible to interact with /dev/g2d anymore until you reboot 
(or possibly un-/reload the module).


I'm not sure how to exactly reproduce that. It mostly occurs the 
second time i start VDR with libvdpau-sunxi and OSD.


Regards
rellla

I don't know if it's related to the above, but unloading the kernel 
module g2d_23 after it stopped working with the "wait g2d irq pending 
flag timeout" message shows me the following log:


[  735.058259] [DISP] layer allocated: 0,102
[  735.065332] [DISP] layer allocated: 0,103
[  735.227857] wait g2d irq pending flag timeout
[  783.215100] [DISP] layer released: 0,102
[  783.222385] [DISP] layer released: 0,103
[  792.500779] [DISP] layer released: 0,101
[  792.541549] UMP<2>: Session closed
[  795.070534] G2D: g2d_module_exit
[  795.080032] G2D: Driver unloaded succesfully.
[  795.092261] [ cut here ]
[  795.105471] WARNING: at drivers/base/core.c:196 
device_release+0x78/0x84()
[  795.122342] Device 'g2d' does not have a release() function, it is 
broken and must be fixed.
[  795.135209] Modules linked in: disp_ump mali_drm drm g2d_23(-) 
sunxi_cedar_mod sw_ahci_platform mali ump
[  795.162378] [] (unwind_backtrace+0x0/0x138) from 
[] (warn_slowpath_common+0x4c/0x64)
[  795.183234] [] (warn_slowpath_common+0x4c/0x64) from 
[] (warn_slowpath_fmt+0x30/0x40)
[  795.203586] [] (warn_slowpath_fmt+0x30/0x40) from 
[] (device_release+0x78/0x84)
[  795.223412] [] (device_release+0x78/0x84) from [] 
(kobject_release+0x98/0x1bc)
[  795.244079] [] (kobject_release+0x98/0x1bc) from 
[] (g2d_module_exit+0x34/0x68 [g2d_23])
[  795.266065] [] (g2d_module_exit+0x34/0x68 [g2d_23]) from 
[] (sys_delete_module+0x1ac/0x28c)
[  795.287740] [] (sys_delete_module+0x1ac/0x28c) from 
[] (ret_fast_syscall+0x0/0x30)

[  795.304222] ---[ end trace ec0a564270cd7879 ]---

rellla

--
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/groups/opt_out.

[linux-sunxi] Re: [PATCH] ahci_imx: Put #ifdef CONFIG_PM_SLEEP around suspend / resume functions

[Marek Vasut]

On Wednesday, March 05, 2014 at 08:17:49 PM, Hans de Goede wrote:
> This fixes the following warnings when CONFIG_PM_SLEEP is not set:
> 
> drivers/ata/ahci_imx.c:284:12: warning: ‘imx_ahci_suspend’ defined but not
> used [-Wunused-function] drivers/ata/ahci_imx.c:299:12: warning:
> ‘imx_ahci_resume’ defined but not used [-Wunused-function]
> 
> Reported-by: Bartlomiej Zolnierkiewicz 
> Cc: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Hans de Goede 

Obviously makes sense.

Acked-by: Marek Vasut 

Best regards,
Marek Vasut

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH] ahci_imx: Put #ifdef CONFIG_PM_SLEEP around suspend / resume functions

[Hans de Goede]

This fixes the following warnings when CONFIG_PM_SLEEP is not set:

drivers/ata/ahci_imx.c:284:12: warning: ‘imx_ahci_suspend’ defined but not used 
[-Wunused-function]
drivers/ata/ahci_imx.c:299:12: warning: ‘imx_ahci_resume’ defined but not used 
[-Wunused-function]

Reported-by: Bartlomiej Zolnierkiewicz 
Cc: Bartlomiej Zolnierkiewicz 
Signed-off-by: Hans de Goede 
---
 drivers/ata/ahci_imx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 3cb5d69..497c7ab 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -281,6 +281,7 @@ static void ahci_imx_host_stop(struct ata_host *host)
imx_sata_disable(hpriv);
 }
 
+#ifdef CONFIG_PM_SLEEP
 static int imx_ahci_suspend(struct device *dev)
 {
struct ata_host *host = dev_get_drvdata(dev);
@@ -308,6 +309,7 @@ static int imx_ahci_resume(struct device *dev)
 
return ahci_platform_resume_host(dev);
 }
+#endif
 
 static SIMPLE_DEV_PM_OPS(ahci_imx_pm_ops, imx_ahci_suspend, imx_ahci_resume);
 
-- 
1.9.0

-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support

[jonsm...@gmail.com]

On Wed, Mar 5, 2014 at 12:19 PM, Dmitriy B.  wrote:
>> That is not in the category of "what Linaro does". The code written at
>> Linaro is open and open lists discuss it.
>
>
> How do I discuss it when I cant even run it?
>
>>
>> It is the vendor pushing
>> those NDAs, not Linaro. Joining Linaro is not going to automatically
>> change Allwinner's position on keeping Cedar source secret.  Do we
>> even know for sure if Allwinner has the ability to open source it and
>> that Cedar is free from a third party licensing mess.
>
>
> Cedar is described well enough right now at linux-sunxi and if Linaro wants
> - they will try to use that. If not - we will see another implementation of
> unusable kernelside V4L2 dec/enc with userspace part that is distributed by
> NDAs (look at Coda/Samsung MFC/whatever is kicking there right now. For MFC
> it took couple months to get it running well enough with XBMC for Exynos4).
>
>> BTW, Hisilicon has never been open source friendly so why did you buy
>> their stuff?
>
>
> I'm happy with my android there. But, its just the fact that HiSilicon spend
> time and money on getting mainline and 3.10.x android kernels that bothers
> me. Why cant I use it? No, lets say different, for exactly *who* it was made
> opensource? For a nice line in press release "we are now opensource"?
> "Not usable" - that is the picture of Linaro that I mean here as a HiSilicon
> device owner. Sorry if it sounds too raw, but thats the facts. :) Hope it
> will be different for Allwinner.
>
>> By any way you slice it, I believe Allwinner joining Linaro will
>> improve their software offerings, not hurt them.
>
>
> Actually, If you had experience working with Linaro, could you please hint
> there that we could enjoy CSI drivers for A1x/A20, since you had/have a

The CSI driver in sunxi is an ancient version.  Recent support for the
CSI unit is in their Android kernel. Nobody has ported this new code
into the sunxi kernel.  I started to do the port but there has been a
lot of divergence between the two kernels and the port is more of a
rewrite. There are more complications to this since Android has
modified the VL4 interface. AFAIK there isn't any missing info
preventing this port.

My current understanding of the Android CSI driver is that I don't
know of any obvious problems with it. Some of the image sensors don't
work right but those are problems in the image sensor drivers. What I
initially thought were problems in the CSI code are actually problems
in the h.264 code.

In general not all features of the CSI unit are supported. For example
the CSI unit supports Transport Stream input but I've never seen a
driver or hardware for it.  Unclear if anyone has written a driver for
it yet.

What isn't working right is h.264 encoding. I can't get Cedar to
compress more than around 10:1 and x86 software encoders can do 50:1
pr more. Not being able to achieve high compression ratios means that
720P consumes too much bandwidth to be used on the Internet. I have
been unable to get it to generate streams less than 10Mb/s while my
desktop has no problem generating 500Kb/s streams.

My next step is to put together a bunch of sample encodings to
demonstrate to Allwinner what it should be doing. If they are given
examples showing exactly what they need to do I suspect they will fix
the h.264 blob.


> project in that field? As I said - everything simple was already done, even
> ARM PSCI is working with help from ARM employee. But things like kernelside
> Cedar, CSI and other multimedia stuff is missing
> http://linux-sunxi.org/Linux_mainlining_effort#Left_to_be_done It would be
> nice for Linaro to start from there, and not with rewriting what is already
> done.
>
> --
> 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/groups/opt_out.



-- 
Jon Smirl
jonsm...@gmail.com

-- 
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/groups/opt_out.

Re: [linux-sunxi] [PATCH] sun4i_csi: fixed null value in camera init, same fix as for csi0

[rdv0011]

пятница, 31 мая 2013 г., 17:21:17 UTC+3 пользователь behrou...@gmail.com 
написал:
> On Thursday, May 30, 2013 11:44:39 PM UTC+4:30, npeacock wrote:
> 
> > On 05/30/2013 11:48 AM, mahdi Chi
> 
> >   wrote:
> 
> > 
> 
> > 
> 
> > 
> 
> >   
> 
> > 
> 
> > 
> 
> > i have same problem
> 
> >   
> 
> > 
> 
> > 
> 
> > 
> 
> > I completed a merge of the latest allwinner code for the CSI system
> 
> > and I thought I submitted the patches.  I think they are just
> 
> > waiting on someone to test them and acknowledge they worked for them
> 
> > as well.  
> 
> > 
> 
> > 
> 
> > 
> 
> > You can see the latest changes on it here
> 
> > https://github.com/npeacock/linux-sunxi/commit/5c7c6f8b0728b6d4b54513675daa921f91f20a71
> 
> > 
> 
> > 
> 
> >   
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > root@cubieboard:~# modprobe sun4i_csi1
> 
> > 
> 
> > <6>[CSI]Welcome to CSI driver
> 
> > 
> 
> > <6>[CSI]csi_init
> 
> > 
> 
> > <6>[CSI]registered sub device,input_num = 0
> 
> > 
> 
> > <6>[CSI]power on and power off camera!
> 
> > 
> 
> > <6>[CSI]V4L2 device registered as video1
> 
> > 
> 
> > root@cubieboard:~# <6>[CSI]sensor initial success
> 
> >   when csi open!
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > but when i try grab a frame 
> 
> > 
> 
> > goot@cubieboard:~# vgrabbj -l 500 -i svga -o jpg -d
> 
> >   /dev/video1 -D 7 -f teste.jp 
> 
> > 
> 
> > Could not open configfile /usr/etc/vgrabbj.conf, ignoring
> 
> > 
> 
> > Set option OutputFile to value "teste.jpg"
> 
> > 
> 
> > Updated pointers to new allocated memory.
> 
> > 
> 
> > Done parsing commandline
> 
> > 
> 
> > Setting tmpout file to teste.jpg.tmp
> 
> > 
> 
> > <6>[CSI]sensor initial success when csi open!
> 
> > 
> 
> > <6>[CSI_ERR]v4l2 sub device queryctrl error!
> 
> > 
> 
> > Floating point exception
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > i try this too but it doesn't work too
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > root@cubieboard:~#  luvcview -s 320x240 -d /dev/video1
> 
> > 
> 
> > luvcview 0.2.6
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > SDL information:
> 
> > 
> 
> >   Video driver: fbcon
> 
> > 
> 
> >   Hardware surfaces are available (7200k video memory)
> 
> > 
> 
> > Device information:
> 
> > 
> 
> >   Device path:  /dev/video1
> 
> > 
> 
> > <6>[CSI]sensor initial success when csi open!
> 
> > 
> 
> > <6>[CSI_ERR]v4l2 sub device queryctrl error!
> 
> > 
> 
> > Stream settings:
> 
> > 
> 
> >   Frame format: 422P (MJPG is not supported by device)
> 
> > 
> 
> >   Frame size:   320x240
> 
> > 
> 
> >   Frame rate:   30 fps
> 
> > 
> 
> > <6>[CSI]buffer_setup, buffer count=4, size=153600
> 
> > 
> 
> > Unable to map buffer: Invalid argument
> 
> > 
> 
> > root@cubieboard:~#  
> 
> >   
> 
> >   
> 
> > 
> 
> > 
> 
> >   
> 
> >   
> 
> > i try 
> 
> >   
> 
> > 
> 
> > 
> 
> >   
> 
> >   
> 
> > root@cubieboard:/home/linaro# fswebcam -d /dev/video1
> 
> >   
> 
> > 
> 
> > 
> 
> >   
> 
> >   
> 
> > too but it make that board hang and need a reboot
> 
> >   
> 
> > 
> 
> > 
> 
> >   
> 
> >   
> 
> > 
> 
> > 
> 
> > my script.bin file is :
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > [csi1_para]
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> >   
> 
> > csi_used = 1
> 
> >   
> 
> > csi_mode = 0
> 
> >   
> 
> > csi_dev_qty = 1
> 
> >   
> 
> > csi_stby_mode = 0
> 
> >   
> 
> > csi_mname = "ov7670"
> 
> >   
> 
> > csi_twi_id = 1
> 
> >   
> 
> > csi_twi_addr = 0x42
> 
> >   
> 
> > ...
> 
> >   
> 
> > csi_pck =
> 
> > port:PG00<3>
> 
> >   
> 
> > csi_ck = port:PG01<3>
> 
> >   
> 
> > csi_hsync =
> 
> > port:PG02<3>
> 
> >   
> 
> > csi_vsync =
> 
> > port:PG03<3>
> 
> >   
> 
> > csi_field =
> 
> >   
> 
> > csi_d0 = port:PG04<3>
> 
> >   
> 
> > csi_d1 = port:PG05<3>
> 
> >   
> 
> > csi_d2 = port:PG06<3>
> 
> >   
> 
> > csi_d3 = port:PG07<3>
> 
> >   
> 
> > csi_d4 = port:PG08<3>
> 
> >   
> 
> > csi_d5 = port:PG09<3>
> 
> >   
> 
> > csi_d6 = port:PG10<3>
> 
> >   
> 
> > csi_d7 = port:PG11<3>
> 
> >   
> 
> > ...
> 
> >   
> 
> > csi_reset =
> 
> > port:PH14<1><0>
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > does somebody have idea about this?
> 
> >   
> 
> 

Re: [linux-sunxi] Re: Build sunxi-next for A20

[Priit Laes]

Ühel kenal päeval, K, 05.03.2014 kell 02:48, kirjutas
hmandevt...@gmail.com:
> Many thanks, i trying to rebuild it.
> I need to use USBTV007 drivers that need at least 3.10 kernel. I saw that 
> exists also some xxx-3.10 branches.
> 
> which branch of 3.10 could be ok to use on olinuxino A20 ?
> i could try to build usbtv module on it

You need at least version 3.12 of Linus' tree because support for
A20-OLinuXino was only added then:
http://linux-sunxi.org/Mainlining_Effort

To test the latest goodness like SATA and USB follow this page:
http://linux-sunxi.org/Mainline_Kernel_Howto


Päikest,
Priit Laes :)

-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support

[Dmitriy B.]

>
> That is not in the category of "what Linaro does". The code written at
> Linaro is open and open lists discuss it.


How do I discuss it when I cant even run it?


> It is the vendor pushing
> those NDAs, not Linaro. Joining Linaro is not going to automatically
> change Allwinner's position on keeping Cedar source secret.  Do we
> even know for sure if Allwinner has the ability to open source it and
> that Cedar is free from a third party licensing mess.
>

Cedar is described well enough right now at linux-sunxi and if Linaro wants
- they will try to use that. If not - we will see another implementation of
unusable kernelside V4L2 dec/enc with userspace part that is distributed by
NDAs (look at Coda/Samsung MFC/whatever is kicking there right now. For MFC
it took couple months to get it running well enough with XBMC for Exynos4).

BTW, Hisilicon has never been open source friendly so why did you buy
> their stuff?
>

I'm happy with my android there. But, its just the fact that HiSilicon
spend time and money on getting mainline and 3.10.x android kernels that
bothers me. Why cant I use it? No, lets say different, for exactly *who* it
was made opensource? For a nice line in press release "we are now
opensource"?
"Not usable" - that is the picture of Linaro that I mean here as a
HiSilicon device owner. Sorry if it sounds too raw, but thats the facts. :)
Hope it will be different for Allwinner.

By any way you slice it, I believe Allwinner joining Linaro will
> improve their software offerings, not hurt them.


Actually, If you had experience working with Linaro, could you please hint
there that we could enjoy CSI drivers for A1x/A20, since you had/have a
project in that field? As I said - everything simple was already done, even
ARM PSCI is working with help from ARM employee. But things like kernelside
Cedar, CSI and other multimedia stuff is missing
http://linux-sunxi.org/Linux_mainlining_effort#Left_to_be_done It would be
nice for Linaro to start from there, and not with rewriting what is already
done.

-- 
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/groups/opt_out.

[linux-sunxi] Re: [PATCH v3 2/5] i2c: mv64xxx: Add support for the Allwinner A31 I2C driver

[Wolfram Sang]

On Tue, Mar 04, 2014 at 05:28:38PM +0100, Maxime Ripard wrote:
> The Allwinner A31 I2C controller is almost identical to the one used in the
> other Allwinner SoCs, except for the fact that it needs to clear the interrupt
> by setting the INT_FLAGS bit in the control register, instead of clearing it.
> 
> Signed-off-by: Maxime Ripard 
> Reviewed-by: Gregory CLEMENT 
> Tested-by: Gregory CLEMENT 

Applied to for-next, thanks!

Still...

> + if (of_device_is_compatible(np, "allwinner,sun6i-a31-i2c"))
> + drv_data->irq_clear_inverted = true;

... next time an errata is needed, I think it makes sense to refactor all
these checks into one struct which can be used as match->data directly.



signature.asc
Description: Digital signature

Re: [linux-sunxi] New u-boot from Hans de Geode's Git Repo won't boot any kernel (Cubieboard2)

[Carlo Caione]

On Wed, Mar 5, 2014 at 5:28 PM, Manfred Kreisl  wrote:
>
>
> Am Mittwoch, 5. März 2014 16:59:21 UTC+1 schrieb Hans de Goede:
>>
>>
>> My sunxi-next u-boot branch is only intended for use with upstream
>> kernels,
>> not with the sunxi 3.4.x kernels. That it fails to boot the 3.4.x kernels
>> is a known issue.
>>
> Ah, I understand.
>
> So, I also tried to boot my new generated 3.14.0-rc3+ kernel and got the
> same issue. Maybe i made a mistake building the new kernel. I took a .config
> File you posted for a 3.13 kernel, perhaps this is not the right way.
>
> Do you have a working .config for the 3.14 kernel  Having a correct
> configuration would be a great help for me

http://linux-sunxi.org/Mainline_Kernel_Howto

-- 
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/groups/opt_out.

[linux-sunxi] Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call

[Wolfram Sang]

On Tue, Mar 04, 2014 at 05:28:37PM +0100, Maxime Ripard wrote:
> The Allwinner A31 SoC using that IP has a reset controller maintaining
> it reset unless told otherwise.
> 
> Add some optional reset support to the driver.
> 
> Signed-off-by: Maxime Ripard 
> Reviewed-by: Gregory CLEMENT 
> Tested-by: Gregory CLEMENT 

Applied to for-next, thanks!



signature.asc
Description: Digital signature

Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support

[jonsm...@gmail.com]

On Wed, Mar 5, 2014 at 11:16 AM, Dmitriy B.  wrote:
>> Besides, why can't linux-sunxi cooperate with the Linaro people?
>> Everything Linaro does is on open mailing lists and servers
>
>
> Because its not. Try to find reference manuals for latest Exynos, HiSilicon
> K3V2 and other Linaro members SoCs and try to join the development, send a

That is not in the category of "what Linaro does". The code written at
Linaro is open and open lists discuss it. It is the vendor pushing
those NDAs, not Linaro. Joining Linaro is not going to automatically
change Allwinner's position on keeping Cedar source secret.  Do we
even know for sure if Allwinner has the ability to open source it and
that Cedar is free from a third party licensing mess?

BTW, Hisilicon has never been open source friendly so why did you buy
their stuff?

> patch there (hint: you wont be able to. Because: NDAs, strict userlist and
> zero documentation).

I haven't had any trouble with getting them to take my patches. But
maybe they are in a gray area since several of the key ARM kernel
maintainers are also Linaro employees.  Here are the mailing lists...
http://lists.linaro.org/mailman/listinfo

I'm not insider but I believe there are two kinds of NDAs inside of
Linaro. 1) Vendors that don't want to be open. 2) NDAs for unannounced
products.

By any way you slice it, I believe Allwinner joining Linaro will
improve their software offerings, not hurt them.

>
> --
> 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/groups/opt_out.



-- 
Jon Smirl
jonsm...@gmail.com

-- 
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/groups/opt_out.

Re: [linux-sunxi] New u-boot from Hans de Geode's Git Repo won't boot any kernel (Cubieboard2)

[Manfred Kreisl]

Am Mittwoch, 5. März 2014 16:59:21 UTC+1 schrieb Hans de Goede:
>
>
> My sunxi-next u-boot branch is only intended for use with upstream 
> kernels, 
> not with the sunxi 3.4.x kernels. That it fails to boot the 3.4.x kernels 
> is a known issue. 
>
> Ah, I understand. 

So, I also tried to boot my new generated 3.14.0-rc3+ kernel and got the 
same issue. Maybe i made a mistake building the new kernel. I took a 
.config File you posted for a 3.13 kernel, perhaps this is not the right 
way.

Do you have a working .config for the 3.14 kernel  Having a correct 
configuration would be a great help for me

Regards,

Manfred

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH 0/5] ARM: sun6i: dt: Add support for GMAC

[Chen-Yu Tsai]

Hi Maxime,

This series add support for the GMAC in A31. The GMAC is the same as in
the A20, except it has an extra reset control. The GMAC clock module is
mostly the same as in the A20, without the extra dividers, which I left
out intentionally from the clock driver.

The register offsets and interrupts were copied from A31 SDK in Rhombus
Tech's repository. The pin muxes were from the EVB fex file. If you have
the A31 datasheet, you could double check them.

This series is based on current sunxi-next ( e8176a3b0 ).

As I don't have actual A31 hardware, this is only compile tested.
Please give it a try, and let me know if it works or not.


Cheers,
ChenYu


Chen-Yu Tsai (5):
  ARM: sun6i: dt: Add pin muxing options for GMAC
  ARM: sun6i: dt: Add GMAC clock node to the A31 DTSI
  ARM: sun6i: dt: Add A31 GMAC gigabit ethernet controller node
  ARM: sun6i: dt: Add ethernet alias for GMAC
  ARM: sun6i: columbus: Enable the GMAC

 arch/arm/boot/dts/sun6i-a31-colombus.dts | 12 +
 arch/arm/boot/dts/sun6i-a31.dtsi | 87 
 2 files changed, 99 insertions(+)

-- 
1.9.0

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH 1/5] ARM: sun6i: dt: Add pin muxing options for GMAC

[Chen-Yu Tsai]

The A31 SoC has a GMAC gigabit ethernet controller supporting
MII, GMII, RGMII modes. Add pin muxing options for these modes.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 42 
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 42f310a..4d2a2bf 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -257,6 +257,48 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+   gmac_pins_mii_a: gmac_mii@0 {
+   allwinner,pins = "PA0", "PA1", "PA2", "PA3",
+   "PA8", "PA9", "PA11",
+   "PA12", "PA13", "PA14", "PA19",
+   "PA20", "PA21", "PA22", "PA23",
+   "PA24", "PA26", "PA27";
+   allwinner,function = "gmac";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
+   gmac_pins_gmii_a: gmac_gmii@0 {
+   allwinner,pins = "PA0", "PA1", "PA2", "PA3",
+   "PA4", "PA5", "PA6", "PA7",
+   "PA8", "PA9", "PA10", "PA11",
+   "PA12", "PA13", "PA14", "PA15",
+   "PA16", "PA17", "PA18", "PA19",
+   "PA20", "PA21", "PA22", "PA23",
+   "PA24", "PA25", "PA26", "PA27";
+   allwinner,function = "gmac";
+   /*
+* data lines in GMII mode run at 125MHz and
+* might need a higher signal drive strength
+*/
+   allwinner,drive = <2>;
+   allwinner,pull = <0>;
+   };
+
+   gmac_pins_rgmii_a: gmac_rgmii@0 {
+   allwinner,pins = "PA0", "PA1", "PA2", "PA3",
+   "PA9", "PA10", "PA11",
+   "PA12", "PA13", "PA14", "PA19",
+   "PA20", "PA25", "PA26", "PA27";
+   allwinner,function = "gmac";
+   /*
+* data lines in RGMII mode use DDR mode
+* and need a higher signal drive strength
+*/
+   allwinner,drive = <3>;
+   allwinner,pull = <0>;
+   };
};
 
ahb1_rst: reset@01c202c0 {
-- 
1.9.0

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH 5/5] ARM: sun6i: columbus: Enable the GMAC

[Chen-Yu Tsai]

The A31 Colombus board uses the GMAC with a Realtek RTL8211E-VB RGMII phy.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31-colombus.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31-colombus.dts 
b/arch/arm/boot/dts/sun6i-a31-colombus.dts
index e5adae3..19a0385 100644
--- a/arch/arm/boot/dts/sun6i-a31-colombus.dts
+++ b/arch/arm/boot/dts/sun6i-a31-colombus.dts
@@ -28,5 +28,17 @@
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
+
+   gmac: ethernet@01c3 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&gmac_pins_rgmii_a>;
+   phy = <&phy1>;
+   phy-mode = "rgmii";
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+   };
};
 };
-- 
1.9.0

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH 2/5] ARM: sun6i: dt: Add GMAC clock node to the A31 DTSI

[Chen-Yu Tsai]

The GMAC uses 1 of 2 sources for its transmit clock, depending on the
PHY interface mode. Add both sources as dummy clocks, and as parents
to the GMAC clock node.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 4d2a2bf..ee09e4c 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -229,6 +229,34 @@
clocks = <&osc24M>, <&pll6>;
clock-output-names = "spi3";
};
+
+   /*
+* The following two are dummy clocks, placeholders used in the 
gmac_tx
+* clock. The gmac driver will choose one parent depending on 
the PHY
+* interface mode, using clk_set_rate auto-reparenting.
+* The actual TX clock rate is not controlled by the gmac_tx 
clock.
+*/
+   mii_phy_tx_clk: clk@1 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   clock-output-names = "mii_phy_tx";
+   };
+
+   gmac_int_tx_clk: clk@2 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_int_tx";
+   };
+
+   gmac_tx_clk: clk@01c200d0 {
+   #clock-cells = <0>;
+   compatible = "allwinner,sun7i-a20-gmac-clk";
+   reg = <0x01c200d0 0x4>;
+   clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
+   clock-output-names = "gmac_tx";
+   };
};
 
soc@01c0 {
-- 
1.9.0

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH 3/5] ARM: sun6i: dt: Add A31 GMAC gigabit ethernet controller node

[Chen-Yu Tsai]

The A31 has the same GMAC found on the A20 SoC, except it has
an extra reset control.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index ee09e4c..e958d5f 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -429,6 +429,22 @@
status = "disabled";
};
 
+   gmac: ethernet@01c3 {
+   compatible = "allwinner,sun7i-a20-gmac";
+   reg = <0x01c3 0x1054>;
+   interrupts = <0 82 4>;
+   interrupt-names = "macirq";
+   clocks = <&ahb1_gates 17>, <&gmac_tx_clk>;
+   clock-names = "stmmaceth", "allwinner_gmac_tx";
+   resets = <&ahb1_rst 17>;
+   snps,pbl = <2>;
+   snps,fixed-burst;
+   snps,force_sf_dma_mode;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
spi0: spi@01c68000 {
compatible = "allwinner,sun6i-a31-spi";
reg = <0x01c68000 0x1000>;
-- 
1.9.0

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH 4/5] ARM: sun6i: dt: Add ethernet alias for GMAC

[Chen-Yu Tsai]

Alias GMAC as ethernet0 so U-boot can fill in the MAC address.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index e958d5f..02d2270 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -23,6 +23,7 @@
serial3 = &uart3;
serial4 = &uart4;
serial5 = &uart5;
+   ethernet0 = &gmac;
};
 
 
-- 
1.9.0

-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support

[Dmitriy B.]

>
> Besides, why can't linux-sunxi cooperate with the Linaro people?
> Everything Linaro does is on open mailing lists and servers


Because its not. Try to find reference manuals for latest Exynos, HiSilicon
K3V2 and other Linaro members SoCs and try to join the development, send a
patch there (hint: you wont be able to. Because: NDAs, strict userlist and
zero 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/groups/opt_out.

Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support

[Dmitriy B.]

>
> For quite a few of the linaro member companies, this is really just
> another consortium. They dispatch some fluff "engineers" that are
> usually not too useful anywhere else, and then pat themselves on the
> back that they are now actively doing the "open source" thing as well.


Linaro is completely useless if company decides to go "sort of
opensource/we-don't-care-about-you".

Recent example is Huawei's daughter, HiSilicon joining Linaro - you cant
use Linaro hisi kernel anywhere, there is just no public devices that can
run it. I'm saying this as an owner of a tablet on HiSilicon K3V2.
HiSilicon got their mainline and android kernel working - but no one,
except themselves, can use it because u-boot/x-loader sources are closed
and zero usage manuals provided. Plus Huawei got into "securityboot/drm"
thing android hype and locked the bootloaders - to get the unlock code for
fastboot you need to know someone from Huawei or wait 2-3 weeks for support
answer (some times, they dont get what you want and you need to write two
or three times until they figure out and send your request properly).
Imagine what happens when 2k users of K3V2 tablets will request drm-off.

I, of course, could spent a week with an osc probe seeking for UART on 45+
testpoints on my tablets 5mil pcb and then infinite amount of time figuring
out their bootsequence, patch x-loader and launch it and it will probably
work, but seriously, why just they don't start with basic plan/reference
documentation of what they are doing and how to test/help?

That is "typical Linaro" picture for me right now, and I do not expect
anything interesting out of Allwinner either. I bet they will push crappy
sun8i/sun9i support and couple missing drivers (as everything simple is
already done) and then forget about it...

Lets just hope we will not see our code with copyrights removed.


> Allwinner joining linaro will only reduce Allwinners
> active contributions to linux-sunxi in future.


Even more - Allwinner joining Linaro will lead to less interest from other
guys like Free-Electrons/RedHat.

-- 
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/groups/opt_out.

Re: [linux-sunxi] New u-boot from Hans de Geode's Git Repo won't boot any kernel (Cubieboard2)

[Hans de Goede]

Hi,

On 03/05/2014 04:34 PM, Manfred Kreisl wrote:
> Hi,
> 
> I want to test the new 3.14-rc3 kernel and the first thing i did is to get 
> and install the new u-boot from here:
> 
> https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next
> 
> After rebooting, everything seems ok but after the message "Starting kernel 
> ..." the system is dead, the green LED lights permanently on the Cb2.

My sunxi-next u-boot branch is only intended for use with upstream kernels,
not with the sunxi 3.4.x kernels. That it fails to boot the 3.4.x kernels
is a known issue.

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/groups/opt_out.

[linux-sunxi] New u-boot from Hans de Geode's Git Repo won't boot any kernel (Cubieboard2)

[Manfred Kreisl]

Hi,

I want to test the new 3.14-rc3 kernel and the first thing i did is to get 
and install the new u-boot from here:

https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next

After rebooting, everything seems ok but after the message "Starting kernel 
..." the system is dead, the green LED lights permanently on the Cb2.

Here are the boot messages i get:

U-Boot SPL 2014.01-rc1-00019-gf509212 (Mar 05 2014 - 01:51:52)
Board: Cubieboard2
DRAM: 1024 MiB
CPU: 96000Hz, AXI/AHB/APB: 3/2/2
spl: not an uImage at 1600


U-Boot 2014.01-rc1-00019-gf509212 (Mar 05 2014 - 01:51:52) Allwinner 
Technology

CPU:   Allwinner A20 (SUN7I)
Board: Cubieboard2
I2C:   ready
DRAM:  1 GiB
WARNING: Caches not enabled
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   mii0
Warning: failed to set MAC address

Hit any key to stop autoboot:  0
reading uEnv.txt
182 bytes read in 3 ms (58.6 KiB/s)
Loaded environment from uEnv.txt
reading boot.scr
** Unable to read file boot.scr **
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
Failed to mount ext2 filesystem...
** Unrecognized filesystem type **
reading script.bin
46096 bytes read in 6 ms (7.3 MiB/s)
reading uImage-3.4.75-sun7i+
4461168 bytes read in 219 ms (19.4 MiB/s)
## Booting kernel from Legacy Image at 4800 ...
   Image Name:   Linux-3.4.75-sun7i+
   Created:  2014-01-04  17:24:40 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4461104 Bytes = 4.3 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel

If I install the u-boot from here 
https://github.com/linux-sunxi/u-boot-sunxi (sunxi branch), i get exactly 
the same output but than the kernel starts correctly.

Typing in the boot commands manually make no difference, neither the 3.4.xx 
nor the new build 3.14-rc3 kernel boots.

So where is the fault, do I need a new script.bin, or does the new u-boot 
not handle a FAT partition correctly?

Any help will be appreciated

Manfred

-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support

[Craig Whitcombe]

What does this mean for the laymen?

Will allwinner provide cedarx source code?
Will allwinner release enough information that essentially linux distros 
(xbmclinux) can easiliy be created for allwinner based STBs and android 
sticks? (im thinking Mele M9 here!)

Thanks,
Craig

On Wednesday, 5 March 2014 11:45:27 UTC, Luc Verhaegen wrote:
>
> On Mon, Mar 03, 2014 at 07:46:21PM -0500, jons...@gmail.com 
> wrote: 
> > Videos of the announcement here... 
> > 
> http://www.linaro.org/linaro-blog/2014/03/03/linaro-connect-asia-2014-kicks-off-in-macau/
>  
> > 
> > 
> http://www.prnewswire.com/news-releases/allwinner-joins-linaro-as-a-founding-member-of-the-linaro-digital-home-group-248195871.html
>  
> > 
> > Let's hope this translates to full corporate support for upstreaming 
> > to mainline. 
> > 
> > On Mon, Mar 3, 2014 at 2:37 PM, jons...@gmail.com  <
> jons...@gmail.com > wrote: 
> > > 
> http://liliputing.com/2014/03/allwinner-joins-linaro-digital-home-group-commits-open-source-chip-support.html
>  
>
> As i stated on irc, i am not too happy with allwinner joining linaro. 
>
> For quite a few of the linaro member companies, this is really just 
> another consortium. They dispatch some fluff "engineers" that are 
> usually not too useful anywhere else, and then pat themselves on the 
> back that they are now actively doing the "open source" thing as well. 
>
> I was getting hopeful with allwinner talking to some of us directly in 
> the last few weeks. But now that i learned that they joined linaro, that 
> hope was lost. Allwinner joining linaro will only reduce Allwinners 
> active contributions to linux-sunxi in future. They have chosen to back 
> linaro instead, and will now dispatch some dispensable "engineers" to 
> linaro, and feel good about themselves. And then they will turn around 
> to us and state: "but we are already doing open source, at linaro". 
>
> 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/groups/opt_out.

Re: [linux-sunxi] Is it possible encode mpeg2 with CedarX?

[Manuel Braga]

On Wed, 5 Mar 2014 00:39:40 -0800 (PST)
xavier.rovira.lanacc...@gmail.com wrote:
> Hi:
> 
> I would like to test if it is possible to encode mpeg2 at 4mbits/s
> 25fps D1 with the A20. 
> 
> For no realtime I suppose FFMEPG is enough.
> 
> Is it possible with the MALI?

I can't answer for software encoding performance or if even makes sense
to use MALI for this.


> Is it possible to encode mpeg2 with CedarX?
> 
> In your page you say encode MPEG must be checked.
> So is it possible but it is not free because of royalties?

Must be checked, because we only see what the binary blob does.
And the hardware could have features that aren't used by the binaries
blob drivers.

If mpeg2 encoding if possible or not, is unknown.
The answer is likely NOT.

If you happen to be a Allwinner customer, they this question should be
directed to them.

-- 

-- 
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/groups/opt_out.

Re: [linux-sunxi] [PATCH] arch/arm/mach-sun7i/pm/standby/mem_printk.c used non-const char arrays. However gcc 4.6.3 likes to replace these by calls to memcpy. memcpy doesn't exist in the kernel. Havin

[Andreas Baierl]

Hi Alejandro,
this patch breaks building because it's not applied as Danny sent it :)
Regards
rellla

Am 02.03.2014 19:54, schrieb Alejandro Mery:


On 01/03/14 20:56, Danny Milosavljevic wrote:

---
  arch/arm/mach-sun7i/pm/standby/mem_printk.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-sun7i/pm/standby/mem_printk.c 
b/arch/arm/mach-sun7i/pm/standby/mem_printk.c

index 357d7d5..840e61a 100644
--- a/arch/arm/mach-sun7i/pm/standby/mem_printk.c
+++ b/arch/arm/mach-sun7i/pm/standby/mem_printk.c
@@ -165,7 +165,7 @@ char *itoa(int value, char *string, int radix)
  int  negative = 0;//defualt is positive value
  int  i;
  int  j;
-char digit_string[] = "0123456789ABCDEF";
+const char *digit_string = "0123456789ABCDEF";

  if(value == 0)
  {
@@ -211,7 +211,7 @@ char *utoa(unsigned int value, char *string, int 
radix)

  char stack[16];
  int  i;
  int  j;
-char digit_string[] = "0123456789ABCDEF";
+const char *digit_string = "0123456789ABCDEF";

  if(value == 0)
  {
@@ -366,7 +366,7 @@ __s32 print_align(char *string, __s32 len, __s32 
align)

  {
  //fill with space ' ' when align request,
  //the max align length is 16 byte.
-char fill_ch[] = "";
+const char *fill_ch = "";
  if (len < align)
  {
  //fill at right


thank you, applied into stage/sunxi-3.4. but next time please don't 
put the whole description of the patch in the first line, only a short 
and contextualized subject goes there.


cheers,
Alejandro Mery



--
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/groups/opt_out.

Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support

[Luc Verhaegen]

On Wed, Mar 05, 2014 at 09:22:45AM -0500, jonsm...@gmail.com wrote:
> 
> I think you are misreading this. Allwinnner is trying to increase
> their appeal in Western markets. Joining Linaro will increase these
> Western ties. Big companies that have already made it send fluff
> engineers, not small companies climbing the ladder. Smartest thing for
> Allwinner to do is rotate their engineers through Linaro relatively
> quickly so that they learn normal Linux practices.
> 
> I would very much like to see Allwinner adopt normal Linux and Android
> build practices and become more involved in upstreaming code. Right
> now they just release tarballs which have no history or any way of
> tracking changes. So if Linaro teaches them about these processes we
> are all winners.
> 
> I'd love to just see the first step of them maintaining forked Android
> repos off from Google's master copies. In turn that would let their
> customers fork the Allwinner repos with their custom changes. Doing
> that would enable security updates to flow through the repo chain.
> Currently there is absolutely no mechanism for pushing security
> updates.
> 
> There are some topnotch Linux engineers working at Linaro. Let's hope
> they mentor the Allwinner people so that they can take the practices
> they learn back to China.
> 
> Besides, why can't linux-sunxi cooperate with the Linaro people?
> Everything Linaro does is on open mailing lists and servers. Maybe
> some of the linux-sunxi developers might poke around inside Linaro now
> and see if they can get themselves hired.

Time will tell.

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/groups/opt_out.

Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support

[jonsm...@gmail.com]

On Wed, Mar 5, 2014 at 6:45 AM, Luc Verhaegen  wrote:
> On Mon, Mar 03, 2014 at 07:46:21PM -0500, jonsm...@gmail.com wrote:
>> Videos of the announcement here...
>> http://www.linaro.org/linaro-blog/2014/03/03/linaro-connect-asia-2014-kicks-off-in-macau/
>>
>> http://www.prnewswire.com/news-releases/allwinner-joins-linaro-as-a-founding-member-of-the-linaro-digital-home-group-248195871.html
>>
>> Let's hope this translates to full corporate support for upstreaming
>> to mainline.
>>
>> On Mon, Mar 3, 2014 at 2:37 PM, jonsm...@gmail.com  
>> wrote:
>> > http://liliputing.com/2014/03/allwinner-joins-linaro-digital-home-group-commits-open-source-chip-support.html
>
> As i stated on irc, i am not too happy with allwinner joining linaro.
>
> For quite a few of the linaro member companies, this is really just
> another consortium. They dispatch some fluff "engineers" that are
> usually not too useful anywhere else, and then pat themselves on the
> back that they are now actively doing the "open source" thing as well.

I think you are misreading this. Allwinnner is trying to increase
their appeal in Western markets. Joining Linaro will increase these
Western ties. Big companies that have already made it send fluff
engineers, not small companies climbing the ladder. Smartest thing for
Allwinner to do is rotate their engineers through Linaro relatively
quickly so that they learn normal Linux practices.

I would very much like to see Allwinner adopt normal Linux and Android
build practices and become more involved in upstreaming code. Right
now they just release tarballs which have no history or any way of
tracking changes. So if Linaro teaches them about these processes we
are all winners.

I'd love to just see the first step of them maintaining forked Android
repos off from Google's master copies. In turn that would let their
customers fork the Allwinner repos with their custom changes. Doing
that would enable security updates to flow through the repo chain.
Currently there is absolutely no mechanism for pushing security
updates.

>
> I was getting hopeful with allwinner talking to some of us directly in
> the last few weeks. But now that i learned that they joined linaro, that
> hope was lost. Allwinner joining linaro will only reduce Allwinners
> active contributions to linux-sunxi in future. They have chosen to back
> linaro instead, and will now dispatch some dispensable "engineers" to
> linaro, and feel good about themselves. And then they will turn around
> to us and state: "but we are already doing open source, at linaro".

There are some topnotch Linux engineers working at Linaro. Let's hope
they mentor the Allwinner people so that they can take the practices
they learn back to China.

Besides, why can't linux-sunxi cooperate with the Linaro people?
Everything Linaro does is on open mailing lists and servers. Maybe
some of the linux-sunxi developers might poke around inside Linaro now
and see if they can get themselves hired.


>
> 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/groups/opt_out.



-- 
Jon Smirl
jonsm...@gmail.com

-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: Build sunxi-next for A20

[Maxime Ripard]

Hi,

On Wed, Mar 05, 2014 at 02:48:20AM -0800, hmandevt...@gmail.com wrote:
> Many thanks, i trying to rebuild it. I need to use USBTV007 drivers
> that need at least 3.10 kernel. I saw that exists also some xxx-3.10
> branches.

The USB support isn't in sunxi-next yet, but should arrive in the few
next weeks.

> which branch of 3.10 could be ok to use on olinuxino A20 ?

I don't know the status of the 3.10 branch, but I'm not sure it works
at all.

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


signature.asc
Description: Digital signature

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

[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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[linux-sunxi] Is it possible encode mpeg2 with CedarX?

[xavier . rovira . lanaccess]

Hi:

I would like to test if it is possible to encode mpeg2 at 4mbits/s 25fps D1 
with the A20. 

For no realtime I suppose FFMEPG is enough.

Is it possible to encode mpeg2 with CedarX?
Is it possible with the MALI?

In your page you say encode MPEG must be checked.
So is it possible but it is not free because of royalties?

Best regards,
Xavier Rovira

-- 
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/groups/opt_out.

[linux-sunxi] mpeg2 CedarX

[xavier . rovira . lanaccess]

Is it possible to encode mpeg2 with CedarX?
in homepate it is said encode mpeg must be checked.

-- 
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/groups/opt_out.

[linux-sunxi] Re: [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Carlo Caione]

On Wed, Mar 5, 2014 at 1:41 AM, Russell King - ARM Linux
 wrote:
> On Tue, Mar 04, 2014 at 05:32:40AM +, Jason Cooper wrote:
>
> Jason, Thomas,
>
> I've just been giving the above a whirl here with the RTC, and it
> doesn't seem to quite work as it should.  Not your problem, because it's
> as the code is originally.
>
> Let's say you set an alarm for 10sec time.  When the alarm fires:
>
> - we read the PMU interrupt status, mask it with the mask register,
>   and find the RTC pending.
> - we call the genirq layer for this interrupt.
> - genirq does the mask + ack thing.
> - the RTC interrupt handler is called, and there's the RTC says there's
>   an interrupt pending.
> - the RTC handler clears the interrupt, and returns.
> - genirq unmasks the interrupt, and returns.
> - dove_pmu_irq_handler() is re-entered, and again, we find that the
>   RTC interrupt is pending.
> - follow the above...
> - the RTC interrupt handler is called, but this time there's no interrupt
>   pending, so returns IRQ_NONE
> - genirq unmasks the interrupt, and returns.
>
> The reason this happens is that the attempt to "ack" - rather "clear" the
> interrupt the first time around has no effect - the RTC is still asserting
> the interrupt, so the write to clear the register results in the bit
> remaining set.
>
> The second time around, we've already cleared the RTC interrupt, so this
> time, the ack clears the interrupt down properly.
>
> In some ways, this is good news - it shows that the bits in this register
> latch '1' when an interrupt is pending, and remain '1' while the block
> continues to assert its interrupt signal - but can we say that the other
> interrupt functions in this register have that behaviour?

I don't know if this could help but I have a very similar problem with
the NMI controller found on sun6i/sun7i for which is pending the
patchset http://comments.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7554

Also in that case the first ACK has no effect and in the end I use the
unmask hook in the irqchip driver to ACK again the line before
unmasking it (the whole discussion about this problem among me, Maxime
and Hans is in this thread
http://www.spinics.net/lists/arm-kernel/msg299952.html )

I also proposed a small (and as it turned out incomplete) patch here
http://www.spinics.net/lists/arm-kernel/msg305616.html but in the end
I preferred to use the unmask hook.

-- 
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/groups/opt_out.

Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support

[Luc Verhaegen]

On Mon, Mar 03, 2014 at 07:46:21PM -0500, jonsm...@gmail.com wrote:
> Videos of the announcement here...
> http://www.linaro.org/linaro-blog/2014/03/03/linaro-connect-asia-2014-kicks-off-in-macau/
> 
> http://www.prnewswire.com/news-releases/allwinner-joins-linaro-as-a-founding-member-of-the-linaro-digital-home-group-248195871.html
> 
> Let's hope this translates to full corporate support for upstreaming
> to mainline.
> 
> On Mon, Mar 3, 2014 at 2:37 PM, jonsm...@gmail.com  wrote:
> > http://liliputing.com/2014/03/allwinner-joins-linaro-digital-home-group-commits-open-source-chip-support.html

As i stated on irc, i am not too happy with allwinner joining linaro.

For quite a few of the linaro member companies, this is really just 
another consortium. They dispatch some fluff "engineers" that are 
usually not too useful anywhere else, and then pat themselves on the 
back that they are now actively doing the "open source" thing as well.

I was getting hopeful with allwinner talking to some of us directly in 
the last few weeks. But now that i learned that they joined linaro, that 
hope was lost. Allwinner joining linaro will only reduce Allwinners 
active contributions to linux-sunxi in future. They have chosen to back 
linaro instead, and will now dispatch some dispensable "engineers" to 
linaro, and feel good about themselves. And then they will turn around 
to us and state: "but we are already doing open source, at linaro".

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/groups/opt_out.

[linux-sunxi] Re: Build sunxi-next for A20

[hmandevteam]

Many thanks, i trying to rebuild it.
I need to use USBTV007 drivers that need at least 3.10 kernel. I saw that 
exists also some xxx-3.10 branches.

which branch of 3.10 could be ok to use on olinuxino A20 ?
i could try to build usbtv module on it

regards
Armando

-- 
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/groups/opt_out.

Re: [linux-sunxi] Build sunxi-next for A20

[Maxime Ripard]

Hi,

On Wed, Mar 05, 2014 at 01:37:10AM -0800, hmandevt...@gmail.com wrote:
> Hi all,
> i trying to build kernel sunxi-next for my A20 Olinuxino. I using
> prev work sd with 3.4 (Debian Wheezy) and update uImage, modules and
> firmware.
> 
> i follow standard steps:
> 
> get linux-sunxi sunxi-next branch:
> $ git clone https://github.com/linux-sunxi/linux-sunxi -b sunxi-next
> 
> get Olinuxino A20 defconfig:
> https://drive.google.com/file/d/0B-bAEPML8fwlNzBNN1N2SGpmblk/edit?usp=sharing

This is where you get it wrong.

The 3.4 configurations are not compatible with the newer kernels. A
lot of options don't exist anymore, new options do.

Please use either sunxi_defconfig or multi_v7_defconfig.

Also, please note that sunxi-next supports less devices than the 3.4
kernel does, so, depending on what you want to do with it, it might or
might not be a good option for you.

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


signature.asc
Description: Digital signature

[linux-sunxi] Build sunxi-next for A20

[hmandevteam]

Hi all,
i trying to build kernel sunxi-next for my A20 Olinuxino. I using prev work sd 
with 3.4 (Debian Wheezy) and update uImage, modules and firmware. 

i follow standard steps:

get linux-sunxi sunxi-next branch:
$ git clone https://github.com/linux-sunxi/linux-sunxi -b sunxi-next

get Olinuxino A20 defconfig:
https://drive.google.com/file/d/0B-bAEPML8fwlNzBNN1N2SGpmblk/edit?usp=sharing

$ cp a20_defconfig linux-sunxi/arch/arm/configs/.
$ make ARCH=arm a20_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x40008000 -j4 
uImage
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j4 INSTALL_MOD_PATH=out 
modules
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j4 INSTALL_MOD_PATH=out 
modules_install

so i had uImage kernel image in linux-sunxi/arch/arm/boot/
modules and firmware in linux-sunxi/out/lib/modules/3.14.0-rc3+

i tryed same steps for same kernel on sd (3.4) and it work fine but when i use 
this new kernel, it doeasn't boot.

could you help me ?

Armando

-- 
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/groups/opt_out.