Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Michal Suchanek 
On 8 September 2014 16:33, Maxime Ripard
 wrote:
> On Mon, Sep 08, 2014 at 03:55:19PM +0200, Luc Verhaegen wrote:
>> On Mon, Sep 08, 2014 at 01:37:23PM +0200, Maxime Ripard wrote:
>> > On Mon, Sep 08, 2014 at 01:01:11PM +0200, Luc Verhaegen wrote:
>> > > Signed-off-by: Luc Verhaegen 
>> > > ---
>> > >  meminfo.c |4 ++--
>> > >  1 files changed, 2 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/meminfo.c b/meminfo.c
>> > > index 86b5c1e..24b4772 100644
>> > > --- a/meminfo.c
>> > > +++ b/meminfo.c
>> > > @@ -60,8 +60,8 @@ enum sunxi_soc_version {
>> > >   SUNXI_SOC_SUN6I = 0x1633, /* A31 */
>> > >   SUNXI_SOC_SUN7I = 0x1651, /* A20 */
>> > >   SUNXI_SOC_SUN8I = 0x1650, /* A23 */
>> > > - SUNXI_SOC_SUN9I = 0x1667, /* A33 */
>> > > - SUNXI_SOC_SUN10I = 0x1635, /* A80 */
>> > > + SUNXI_SOC_SUN9I = 0x1635, /* A80 */
>> > > + SUNXI_SOC_SUN10I = 0x1667, /* A33 */
>> >
>> > A33 is actually part of the sun8i family.
>> >
>> > Maxime
>>
>> For those who do not know what Maxime is on about, here is the short
>> explanation:
>> http://linux-sunxi.org/Allwinner_SoC_Family#Naming_confusion
>>
>> I do not buy the modern allwinner sunXi naming.
>>
>> Retro-actively renaming half their line-up sun4i and the other half
>> sun8i, I have seen that before (cfr unichrome.sf.net). A few months in,
>> and that Vendor did another little pirouette. And again, and again.
>>
>> Where Allwinner drew the naming line now is quite arbitrary: the type of
>> the ARM core in there. The one component which is mostly generic and
>> reasonably universal. Sun4i suddenly became all ARM Cortex A8, sun8i
>> became all ARM Cortex A7. Now that they stuck a few A15 in A80, they
>> named that sun9i.
>
> Actually, I do find it consistent.
>
>> If the sunXiwYpZ scheme actually had something to do with the majority
>> of SoC specific component lineage, i would've totally bought into it:
>> that would put A20 close to A10, and would put A31 somewhere else
>> altogether, with A23 and A33 close together...
>
> Yeah, right, as if the sun4i/sun5i was in any way better
>
>> So no, this is purely a marketing driven decision, which will have
>> changed again in 6 months time. Where will Allwinners freshly announced
>> A83 land? Will they stick to their own naming scheme? What will happen
>> when Allwinner produces an ARMv8 chip, will they count beyond 9, or will
>> they rename everything sun7i/sun8i?
>>
>> Sun[4567]i was chronological, and initially sun[89]i were too. So I say
>> we just keep on counting for ourselves.
>
> A10s was released after A13, A31 and A20 at the same time. Not very
> chronological if you ask me...
>
> But I guess what it all boils down is this: do we want to keep
> allwinner's naming and be consistent with it or not. We've been so
> far, it's something I'd like to be kept. Especially since it's *very*
> easy to support (basically, keep the sun6i and sun7i, introduce sun8i
> for A23, A33, and whatever comes next, which should be the best if
> following your "connection" argument), and have sun9i for the A80.
>
> Introducing this sun10i out of nowhere, without any other
> code/documentation referring to it, and with the only argument that
> "some guy thought it was a better idea" is not that great. Especially
> when the time where they will have a new design and come up with
> sun10i chips.
>
>> Another option is to completely switch to AW, which would mimic
>> what i did for unichrome.
>>
>> A10= AW1623 (sun4i)
>> A13/A10s = AW1625 (sun5i)
>> A31= AW1633 (sun6i)
>> A20= AW1651 (sun7i)
>> A23= AW1650 (sun8i)
>> A80= AW1635 (sun9i)
>> A33= AW1667 (...)
>>
>> Now that's going to be real confusing.
>
> That could be an option, but like you said, it's pretty confusing to
> existing user of our code base.

Ok, so how about printing all of the above?

The chip id is something burnt into the SoC and cannot be disputed.
>From the chip id it can be guessed what is probably printed on the
package unless AW marketing got *really* creative. Now there is
codename under which the chip was historically released. That it was
retroactively renamed by AW is something that existing devices cannot
reflect.

Incidentally there is no clash:

>> A10= AW1623 (sun4i)
>> A13/A10s = AW1625 (sun5i)
>> A31= AW1633 (sun6i)
>> A20= AW1651 (sun7i)
>> A23= AW1650 (sun8i or sun8iw3)
>> A80= AW1635 (sun9i or sun9iw1)
>> A33= AW1667 (sun8iw5)

Once A83 comes out or there is enough support for a23 and a33 it may
turn out that keeing a codename for new SoCs is just too insane and
they can be dropped.

Thanks

Michal

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

[linux-sunxi] [PATCH] Update Wexler Tab 7200 fex

2014-09-08 Thread Aleksei Mamlin 
Signed-off-by: Aleksei Mamlin 
---
 sys_config/a20/wexler_tab_7200.fex | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/sys_config/a20/wexler_tab_7200.fex 
b/sys_config/a20/wexler_tab_7200.fex
index 9268eff..3f49b2b 100644
--- a/sys_config/a20/wexler_tab_7200.fex
+++ b/sys_config/a20/wexler_tab_7200.fex
@@ -755,9 +755,11 @@ luns = 2
 
 [gsensor_para]
 gsensor_used = 1
+gsensor_name = "dmard06"
 gsensor_twi_id = 1
-gsensor_int1 =
-gsensor_int2 =
+gsensor_twi_addr = 0x1c
+gsensor_int1 = port:PH00<6><1>
+gsensor_int2 = port:PI10<6><1>
 
 [gps_para]
 gps_used = 0
@@ -784,6 +786,10 @@ ap6xxx_bt_regon = port:PB05<1><0>
 ap6xxx_bt_wake = port:PI20<1><0>
 ap6xxx_bt_host_wake = port:PI21<0><0>
 
+[usb_wifi_para]
+usb_wifi_used = 1
+usb_wifi_usbc_num = 2
+
 [3g_para]
 3g_used = 0
 3g_usbc_num = 2
@@ -852,7 +858,7 @@ ir_rx = port:PB04<2>
 pmu_used = 1
 pmu_twi_addr = 52
 pmu_twi_id = 0
-pmu_irq_id = 0
+pmu_irq_id = 32
 pmu_battery_rdc = 100
 pmu_battery_cap = 4000
 pmu_init_chgcur = 300
@@ -913,7 +919,7 @@ key_min = 4
 key_max = 40
 
 [dvfs_table]
-max_freq = 91200
+max_freq = 100800
 normal_freq = 72000
 min_freq = 6000
 LV_count = 8
-- 
1.8.5.5

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

[linux-sunxi] Re: [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Stefan Monnier 
>> That could be an option, but like you said, it's pretty confusing to
>> existing user of our code base.
> This is going to be a big pain.

Again, using the A10, A23, ... names seems like a much better option for
the end users as well.


Stefan

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

Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Luc Verhaegen 
On Mon, Sep 08, 2014 at 04:33:48PM +0200, Maxime Ripard wrote:
> On Mon, Sep 08, 2014 at 03:55:19PM +0200, Luc Verhaegen wrote:
> > 
> > For those who do not know what Maxime is on about, here is the short 
> > explanation: 
> > http://linux-sunxi.org/Allwinner_SoC_Family#Naming_confusion
> > 
> > I do not buy the modern allwinner sunXi naming.
> > 
> > Retro-actively renaming half their line-up sun4i and the other half 
> > sun8i, I have seen that before (cfr unichrome.sf.net). A few months in, 
> > and that Vendor did another little pirouette. And again, and again.
> > 
> > Where Allwinner drew the naming line now is quite arbitrary: the type of 
> > the ARM core in there. The one component which is mostly generic and 
> > reasonably universal. Sun4i suddenly became all ARM Cortex A8, sun8i 
> > became all ARM Cortex A7. Now that they stuck a few A15 in A80, they 
> > named that sun9i.
> 
> Actually, I do find it consistent.

For now.

> > If the sunXiwYpZ scheme actually had something to do with the majority 
> > of SoC specific component lineage, i would've totally bought into it: 
> > that would put A20 close to A10, and would put A31 somewhere else 
> > altogether, with A23 and A33 close together...
> 
> Yeah, right, as if the sun4i/sun5i was in any way better

It was a consistent scheme, which allwinner followed for many many 
years.

> > So no, this is purely a marketing driven decision, which will have 
> > changed again in 6 months time. Where will Allwinners freshly announced 
> > A83 land? Will they stick to their own naming scheme? What will happen 
> > when Allwinner produces an ARMv8 chip, will they count beyond 9, or will 
> > they rename everything sun7i/sun8i?
> > 
> > Sun[4567]i was chronological, and initially sun[89]i were too. So I say 
> > we just keep on counting for ourselves.
> 
> A10s was released after A13, A31 and A20 at the same time. Not very
> chronological if you ask me...

A10s is A13. The A20 design was a stopgap, and the design started after 
A31 was started. So it was chronological, just not chronological with 
the release dates.

> But I guess what it all boils down is this: do we want to keep
> allwinner's naming and be consistent with it or not. We've been so
> far, it's something I'd like to be kept. Especially since it's *very*
> easy to support (basically, keep the sun6i and sun7i, introduce sun8i
> for A23, A33, and whatever comes next, which should be the best if
> following your "connection" argument), and have sun9i for the A80.

But this is not consistent with Allwinner naming. Being consistent with 
allwinner naming would mean renaming most of the upstream code. And then 
doing it again a few months from now.

Sun8i for A23 and A33 will only work until we see allwinner give out the 
codename for A83, and whether the early marketing noise for it matches 
reality and it really is a octal A7 with powervr. Something tells me 
that this is going to be an A80, with less dram channels, less rogue 
shaders, and with A7s instead of A15.

> Introducing this sun10i out of nowhere, without any other
> code/documentation referring to it, and with the only argument that
> "some guy thought it was a better idea" is not that great. Especially
> when the time where they will have a new design and come up with
> sun10i chips.

It will be a very short pain.

> > Another option is to completely switch to AW, which would mimic 
> > what i did for unichrome.
> > 
> > A10  = AW1623 (sun4i)
> > A13/A10s = AW1625 (sun5i)
> > A31  = AW1633 (sun6i)
> > A20  = AW1651 (sun7i)
> > A23  = AW1650 (sun8i)
> > A80  = AW1635 (sun9i)
> > A33  = AW1667 (...)
> > 
> > Now that's going to be real confusing.
> 
> That could be an option, but like you said, it's pretty confusing to
> existing user of our code base.

This is going to be a big pain.

But ok, so what do you want to call A33, and do we rename A23 away from 
sun8i, by adding suffixes there as well?

The sun8i "solution" is only a band-aid though. Perhaps A83 will 
fit in this scheme, perhaps not. Something tells me that armv8 is going 
to seriously kill this, and will require a more permanent solution to 
this problem.

Luc Verhaegen.

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

Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Maxime Ripard 
On Mon, Sep 08, 2014 at 03:55:19PM +0200, Luc Verhaegen wrote:
> On Mon, Sep 08, 2014 at 01:37:23PM +0200, Maxime Ripard wrote:
> > On Mon, Sep 08, 2014 at 01:01:11PM +0200, Luc Verhaegen wrote:
> > > Signed-off-by: Luc Verhaegen 
> > > ---
> > >  meminfo.c |4 ++--
> > >  1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/meminfo.c b/meminfo.c
> > > index 86b5c1e..24b4772 100644
> > > --- a/meminfo.c
> > > +++ b/meminfo.c
> > > @@ -60,8 +60,8 @@ enum sunxi_soc_version {
> > >   SUNXI_SOC_SUN6I = 0x1633, /* A31 */
> > >   SUNXI_SOC_SUN7I = 0x1651, /* A20 */
> > >   SUNXI_SOC_SUN8I = 0x1650, /* A23 */
> > > - SUNXI_SOC_SUN9I = 0x1667, /* A33 */
> > > - SUNXI_SOC_SUN10I = 0x1635, /* A80 */
> > > + SUNXI_SOC_SUN9I = 0x1635, /* A80 */
> > > + SUNXI_SOC_SUN10I = 0x1667, /* A33 */
> > 
> > A33 is actually part of the sun8i family.
> > 
> > Maxime
> 
> For those who do not know what Maxime is on about, here is the short 
> explanation: 
> http://linux-sunxi.org/Allwinner_SoC_Family#Naming_confusion
> 
> I do not buy the modern allwinner sunXi naming.
> 
> Retro-actively renaming half their line-up sun4i and the other half 
> sun8i, I have seen that before (cfr unichrome.sf.net). A few months in, 
> and that Vendor did another little pirouette. And again, and again.
> 
> Where Allwinner drew the naming line now is quite arbitrary: the type of 
> the ARM core in there. The one component which is mostly generic and 
> reasonably universal. Sun4i suddenly became all ARM Cortex A8, sun8i 
> became all ARM Cortex A7. Now that they stuck a few A15 in A80, they 
> named that sun9i.

Actually, I do find it consistent.

> If the sunXiwYpZ scheme actually had something to do with the majority 
> of SoC specific component lineage, i would've totally bought into it: 
> that would put A20 close to A10, and would put A31 somewhere else 
> altogether, with A23 and A33 close together...

Yeah, right, as if the sun4i/sun5i was in any way better

> So no, this is purely a marketing driven decision, which will have 
> changed again in 6 months time. Where will Allwinners freshly announced 
> A83 land? Will they stick to their own naming scheme? What will happen 
> when Allwinner produces an ARMv8 chip, will they count beyond 9, or will 
> they rename everything sun7i/sun8i?
> 
> Sun[4567]i was chronological, and initially sun[89]i were too. So I say 
> we just keep on counting for ourselves.

A10s was released after A13, A31 and A20 at the same time. Not very
chronological if you ask me...

But I guess what it all boils down is this: do we want to keep
allwinner's naming and be consistent with it or not. We've been so
far, it's something I'd like to be kept. Especially since it's *very*
easy to support (basically, keep the sun6i and sun7i, introduce sun8i
for A23, A33, and whatever comes next, which should be the best if
following your "connection" argument), and have sun9i for the A80.

Introducing this sun10i out of nowhere, without any other
code/documentation referring to it, and with the only argument that
"some guy thought it was a better idea" is not that great. Especially
when the time where they will have a new design and come up with
sun10i chips.

> Another option is to completely switch to AW, which would mimic 
> what i did for unichrome.
> 
> A10= AW1623 (sun4i)
> A13/A10s = AW1625 (sun5i)
> A31= AW1633 (sun6i)
> A20= AW1651 (sun7i)
> A23= AW1650 (sun8i)
> A80= AW1635 (sun9i)
> A33= AW1667 (...)
> 
> Now that's going to be real confusing.

That could be an option, but like you said, it's pretty confusing to
existing user of our code base.

Maxime

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


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Stefan Monnier 
> Where do you stick A10s, which is an A13 in another package.

Under A13?


Stefan

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

Re: [linux-sunxi] Re: [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Luc Verhaegen 
On Mon, Sep 08, 2014 at 04:04:43PM +0200, Luc Verhaegen wrote:
> On Mon, Sep 08, 2014 at 10:02:22AM -0400, Stefan Monnier wrote:
> > > Another option is to completely switch to AW, which would mimic 
> > > what i did for unichrome.
> > 
> > That would make a lot of sense.
> > 
> > > A10= AW1623 (sun4i)
> > > A13/A10s = AW1625 (sun5i)
> > > A31= AW1633 (sun6i)
> > > A20= AW1651 (sun7i)
> > > A23= AW1650 (sun8i)
> > > A80= AW1635 (sun9i)
> > > A33= AW1667 (...)
> > 
> > Wait, no, not *that* chip ID.  I thought you meant to use A10 to refer
> > to the A10 SoC, and A33 to refer to the A33 SoC.  Or would that be
> > simply too obvious?
> 
> Where do you stick A10s, which is an A13 in another package.
> 
> Luc Verhaegen.

It has some merit though, as Allwinner cannot go and remove the printing 
on chips which already shipped.

If their recent marketing based rename is anything to go by, they will 
end up trying to do so though. Somewhere in the middle of production, 
the printing on a fully equal bit of silicon, with equal packaging, is 
bound to get changed.

Luc Verhaegen.

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

Re: [linux-sunxi] Re: [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Luc Verhaegen 
On Mon, Sep 08, 2014 at 10:02:22AM -0400, Stefan Monnier wrote:
> > Another option is to completely switch to AW, which would mimic 
> > what i did for unichrome.
> 
> That would make a lot of sense.
> 
> > A10  = AW1623 (sun4i)
> > A13/A10s = AW1625 (sun5i)
> > A31  = AW1633 (sun6i)
> > A20  = AW1651 (sun7i)
> > A23  = AW1650 (sun8i)
> > A80  = AW1635 (sun9i)
> > A33  = AW1667 (...)
> 
> Wait, no, not *that* chip ID.  I thought you meant to use A10 to refer
> to the A10 SoC, and A33 to refer to the A33 SoC.  Or would that be
> simply too obvious?

Where do you stick A10s, which is an A13 in another package.

Luc Verhaegen.

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

[linux-sunxi] Re: [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Stefan Monnier 
> Another option is to completely switch to AW, which would mimic 
> what i did for unichrome.

That would make a lot of sense.

> A10= AW1623 (sun4i)
> A13/A10s = AW1625 (sun5i)
> A31= AW1633 (sun6i)
> A20= AW1651 (sun7i)
> A23= AW1650 (sun8i)
> A80= AW1635 (sun9i)
> A33= AW1667 (...)

Wait, no, not *that* chip ID.  I thought you meant to use A10 to refer
to the A10 SoC, and A33 to refer to the A33 SoC.  Or would that be
simply too obvious?


Stefan

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

Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Luc Verhaegen 
On Mon, Sep 08, 2014 at 01:37:23PM +0200, Maxime Ripard wrote:
> On Mon, Sep 08, 2014 at 01:01:11PM +0200, Luc Verhaegen wrote:
> > Signed-off-by: Luc Verhaegen 
> > ---
> >  meminfo.c |4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meminfo.c b/meminfo.c
> > index 86b5c1e..24b4772 100644
> > --- a/meminfo.c
> > +++ b/meminfo.c
> > @@ -60,8 +60,8 @@ enum sunxi_soc_version {
> > SUNXI_SOC_SUN6I = 0x1633, /* A31 */
> > SUNXI_SOC_SUN7I = 0x1651, /* A20 */
> > SUNXI_SOC_SUN8I = 0x1650, /* A23 */
> > -   SUNXI_SOC_SUN9I = 0x1667, /* A33 */
> > -   SUNXI_SOC_SUN10I = 0x1635, /* A80 */
> > +   SUNXI_SOC_SUN9I = 0x1635, /* A80 */
> > +   SUNXI_SOC_SUN10I = 0x1667, /* A33 */
> 
> A33 is actually part of the sun8i family.
> 
> Maxime

For those who do not know what Maxime is on about, here is the short 
explanation: 
http://linux-sunxi.org/Allwinner_SoC_Family#Naming_confusion

I do not buy the modern allwinner sunXi naming.

Retro-actively renaming half their line-up sun4i and the other half 
sun8i, I have seen that before (cfr unichrome.sf.net). A few months in, 
and that Vendor did another little pirouette. And again, and again.

Where Allwinner drew the naming line now is quite arbitrary: the type of 
the ARM core in there. The one component which is mostly generic and 
reasonably universal. Sun4i suddenly became all ARM Cortex A8, sun8i 
became all ARM Cortex A7. Now that they stuck a few A15 in A80, they 
named that sun9i.

If the sunXiwYpZ scheme actually had something to do with the majority 
of SoC specific component lineage, i would've totally bought into it: 
that would put A20 close to A10, and would put A31 somewhere else 
altogether, with A23 and A33 close together...

So no, this is purely a marketing driven decision, which will have 
changed again in 6 months time. Where will Allwinners freshly announced 
A83 land? Will they stick to their own naming scheme? What will happen 
when Allwinner produces an ARMv8 chip, will they count beyond 9, or will 
they rename everything sun7i/sun8i?

Sun[4567]i was chronological, and initially sun[89]i were too. So I say 
we just keep on counting for ourselves.

Another option is to completely switch to AW, which would mimic 
what i did for unichrome.

A10  = AW1623 (sun4i)
A13/A10s = AW1625 (sun5i)
A31  = AW1633 (sun6i)
A20  = AW1651 (sun7i)
A23  = AW1650 (sun8i)
A80  = AW1635 (sun9i)
A33  = AW1667 (...)

Now that's going to be real confusing.

So just keep counting up, and wait for Allwinner Marketing to try to 
earn their wage again. We will soon have sun11i and sun12i on 
linux-sunxi, taking us far out of the reach of the current naming 
scheme.

Luc Verhaegen.

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

[linux-sunxi] Re: Report on recently added audio support

2014-09-08 Thread Stefan Monnier 
Hi,

> just add this patch to the head of Emilios branch.

Thanks, will give it a try,


Stefan

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

[linux-sunxi] [PATCH 5/7] ARM: sunxi-mmc: Add mmc support for sun6i / A31

2014-09-08 Thread Chen-Yu Tsai 
From: Hans de Goede 

Signed-off-by: Hans de Goede 
[w...@csie.org: use setbits_le32 for reset control, drop obsolete changes,
squash "sunxi-mmc: sun6i has its fifo at a different address"]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/mmc.h | 2 --
 drivers/mmc/sunxi_mmc.c   | 9 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h 
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 53196e3..bafde4b 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -42,8 +42,6 @@ struct sunxi_mmc {
u32 idie;   /* 0x8c internal DMA interrupt enable */
u32 chda;   /* 0x90 */
u32 cbda;   /* 0x94 */
-   u32 res1[26];
-   u32 fifo;   /* 0x100 FIFO access address */
 };
 
 #define SUNXI_MMC_CLK_POWERSAVE(0x1 << 17)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index d4e574f..b035bba 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -57,7 +57,11 @@ static int mmc_resource_init(int sdc_no)
printf("Wrong mmc number %d\n", sdc_no);
return -1;
}
+#ifdef CONFIG_SUN6I
+   mmchost->database = (unsigned int)mmchost->reg + 0x200;
+#else
mmchost->database = (unsigned int)mmchost->reg + 0x100;
+#endif
mmchost->mmc_no = sdc_no;
 
return 0;
@@ -75,6 +79,11 @@ static int mmc_clk_io_on(int sdc_no)
/* config ahb clock */
setbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_MMC(sdc_no));
 
+#if defined(CONFIG_SUN6I)
+   /* unassert reset */
+   setbits_le32(&ccm->ahb_reset0_cfg, 1 << AHB_RESET_OFFSET_MMC(sdc_no));
+#endif
+
/* config mod clock */
pll_clk = clock_get_pll6();
/* should be close to 100 MHz but no more, so round up */
-- 
2.1.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/d/optout.

[linux-sunxi] [PATCH 2/7] ARM: sun6i: Add base address for the new controllers in A31

2014-09-08 Thread Chen-Yu Tsai 
From: Oliver Schinagl 

A31 has several new and changed memory address. This patch adds them.

Signed-off-by: Oliver Schinagl 
Signed-off-by: Hans de Goede 
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/cpu.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h 
b/arch/arm/include/asm/arch-sunxi/cpu.h
index a987e51d..313e6c8 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -95,6 +95,11 @@
 #define SUNXI_MALI400_BASE 0x01c4
 #define SUNXI_GMAC_BASE0x01c5
 
+#define SUNXI_DRAM_COM_BASE0x01c62000
+#define SUNXI_DRAM_CTL_BASE0x01c63000
+#define SUNXI_DRAM_PHY_CH1_BASE0x01c65000
+#define SUNXI_DRAM_PHY_CH2_BASE0x01c66000
+
 /* module sram */
 #define SUNXI_SRAM_C_BASE  0x01d0
 
@@ -105,6 +110,10 @@
 #define SUNXI_MP_BASE  0x01e8
 #define SUNXI_AVG_BASE 0x01ea
 
+#define SUNXI_PRCM_BASE0x01f01400
+#define SUNXI_R_PIO_BASE   0x01f02c00
+#define SUNXI_P2WI_BASE0x01f03400
+
 /* CoreSight Debug Module */
 #define SUNXI_CSDM_BASE0x3f50
 
-- 
2.1.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/d/optout.

[linux-sunxi] [PATCH 6/7] ARM: sun6i: Setup the A31 UART0 muxing

2014-09-08 Thread Chen-Yu Tsai 
From: Maxime Ripard 

Signed-off-by: Maxime Ripard 
Signed-off-by: Hans de Goede 
[w...@csie.org: commit message was "ARM: sunxi: Setup the A31 UART0 muxing"]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/cpu/armv7/sunxi/board.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index f2cedbb..fc6aa4b 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -54,6 +54,10 @@ int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPB(22), SUN4I_GPB22_UART0_TX);
sunxi_gpio_set_cfgpin(SUNXI_GPB(23), SUN4I_GPB23_UART0_RX);
sunxi_gpio_set_pull(SUNXI_GPB(23), 1);
+#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_SUN6I)
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(20), 2);
+   sunxi_gpio_set_cfgpin(SUNXI_GPH(21), 2);
+   sunxi_gpio_set_pull(SUNXI_GPH(21), 1);
 #elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_SUN5I)
sunxi_gpio_set_cfgpin(SUNXI_GPB(19), SUN5I_GPB19_UART0_TX);
sunxi_gpio_set_cfgpin(SUNXI_GPB(20), SUN5I_GPB20_UART0_RX);
-- 
2.1.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/d/optout.

[linux-sunxi] [PATCH 1/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined

2014-09-08 Thread Chen-Yu Tsai 
BOOT_TARGET_DEVICES includes USB unconditionally. This breaks when
CONFIG_CMD_USB is not defined. Use a secondary macro to conditionally
include it when CONFIG_EHCI is enabled, as we do for CONFIG_AHCI.

Signed-off-by: Chen-Yu Tsai 
---
 include/configs/sunxi-common.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 1d947d7..a31656e 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -233,10 +233,16 @@
 #define BOOT_TARGET_DEVICES_SCSI(func)
 #endif
 
+#ifdef CONFIG_USB_EHCI
+#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
+#else
+#define BOOT_TARGET_DEVICES_USB(func)
+#endif
+
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
BOOT_TARGET_DEVICES_SCSI(func) \
-   func(USB, usb, 0) \
+   BOOT_TARGET_DEVICES_USB(func) \
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
 
-- 
2.1.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/d/optout.

[linux-sunxi] [PATCH 4/7] ARM: sun6i: Add clock support

2014-09-08 Thread Chen-Yu Tsai 
This patch adds the basic clocks support for the Allwinner A31 (sun6i)
processor. This code will not been compiled until the build is hooked
up in a later patch. It has been split out to keep the patches manageable.

This includes changes from the following commits from u-boot-sunxi:

a92051b ARM: sunxi: Add sun6i clock controller structure
1f72c6f ARM: sun6i: Setup the UART0 clocks
5f2e712 ARM: sunxi: Enable pll6 by default on all models
2be2f2a ARM: sunxi-mmc: Add mmc support for sun6i / A31
12e1633 ARM: sun6i: Add initial clock setup for SPL
1a9c9c6 ARM: sunxi: Split clock code into common, sun4i and sun6i code
0b194ee ARM: sun6i: Properly setup the PLL LDO in clock_init_safe
b54c626 sunxi: avoid sr32 for APB1 clock setup.
68fe29c sunxi: remove magic numbers from clock_get_pll{5,6}
c89867d sunxi: clocks: clock_get_pll5 prototype and coding style
501ab1e ARM: sunxi: Fix sun6i PLL6 settings
37f669b ARM: sunxi: Fix macro names for mmc and uart reset offsets
61de1e6 ARM: sunxi: Correct comment for MBUS1 register in sun6i clock 
definitions

Signed-off-by: Maxime Ripard 
Signed-off-by: Ian Campbell 
Signed-off-by: Hans de Goede 
[w...@csie.org: styling fixes reported by checkpatch.pl]
Signed-off-by: Chen-Yu Tsai 
Cc: Tom Cubie 
---
 arch/arm/cpu/armv7/sunxi/Makefile |   1 +
 arch/arm/cpu/armv7/sunxi/clock_sun6i.c| 107 ++
 arch/arm/include/asm/arch-sunxi/clock.h   |   4 +
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 205 ++
 4 files changed, 317 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/sunxi/clock_sun6i.c
 create mode 100644 arch/arm/include/asm/arch-sunxi/clock_sun6i.h

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
b/arch/arm/cpu/armv7/sunxi/Makefile
index f0473d2..2a42dca 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -14,6 +14,7 @@ obj-y += pinmux.o
 obj-$(CONFIG_SUN6I)+= prcm.o
 obj-$(CONFIG_SUN4I)+= clock_sun4i.o
 obj-$(CONFIG_SUN5I)+= clock_sun4i.o
+obj-$(CONFIG_SUN6I)+= clock_sun6i.o
 obj-$(CONFIG_SUN7I)+= clock_sun4i.o
 
 ifndef CONFIG_SPL_BUILD
diff --git a/arch/arm/cpu/armv7/sunxi/clock_sun6i.c 
b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
new file mode 100644
index 000..28fc54f
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/clock_sun6i.c
@@ -0,0 +1,107 @@
+/*
+ * sun6i specific clock code
+ *
+ * (C) Copyright 2007-2012
+ * Allwinner Technology Co., Ltd. 
+ * Tom Cubie 
+ *
+ * (C) Copyright 2013 Luke Kenneth Casson Leighton 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_SPL_BUILD
+void clock_init_safe(void)
+{
+   struct sunxi_ccm_reg * const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+   struct sunxi_prcm_reg * const prcm =
+   (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+
+   /* Set PLL ldo voltage without this PLL6 does not work properly */
+   writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
+   PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
+   PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
+   writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
+   PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140) |
+   PRCM_PLL_CTRL_LDO_KEY, &prcm->pll_ctrl1);
+   writel(PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
+   PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140),
+   &prcm->pll_ctrl1);
+
+   /* AXI and PLL1 settings from boot0 / boot1, PLL1 set to 486 Mhz */
+   writel(AXI_DIV_3 << AXI_DIV_SHIFT |
+  ATB_DIV_2 << ATB_DIV_SHIFT |
+  CPU_CLK_SRC_OSC24M << CPU_CLK_SRC_SHIFT,
+  &ccm->cpu_axi_cfg);
+   writel(PLL1_CFG_DEFAULT, &ccm->pll1_cfg);
+   sdelay(200);
+   writel(AXI_DIV_3 << AXI_DIV_SHIFT |
+  ATB_DIV_2 << ATB_DIV_SHIFT |
+  CPU_CLK_SRC_PLL1 << CPU_CLK_SRC_SHIFT,
+  &ccm->cpu_axi_cfg);
+
+   writel(PLL6_CFG_DEFAULT, &ccm->pll6_cfg);
+}
+#endif
+
+void clock_init_uart(void)
+{
+   struct sunxi_ccm_reg *const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+   /* uart clock source is apb2 */
+   writel(APB2_CLK_SRC_OSC24M|
+  APB2_CLK_RATE_N_1|
+  APB2_CLK_RATE_M(1),
+  &ccm->apb2_div);
+
+   /* open the clock for uart */
+   setbits_le32(&ccm->apb2_gate,
+CLK_GATE_OPEN << (APB2_GATE_UART_SHIFT +
+  CONFIG_CONS_INDEX - 1));
+
+   /* deassert uart reset */
+   setbits_le32(&ccm->apb2_reset_cfg,
+1 << (APB2_RESET_UART_SHIFT +
+  CONFIG_CONS_INDEX - 1));
+
+   /* Dup with clock_init_safe(), drop once sun6i SPL support lands */
+   writel(PLL6_CFG_DEFAULT, &ccm->pll6_cfg);
+}
+
+int clock_twi_onoff(int port,

[linux-sunxi] [PATCH 0/7] ARM: sunxi: Add basic support for Allwinner A31 (sun6i)

2014-09-08 Thread Chen-Yu Tsai 
Hi everyone,

This series add basic support for Allwinner's A31 SoC. The patches,
excluding the first one, were cherry-picked from u-boot-sunxi. Due to
the difference between u-boot mainline and u-boot-sunxi, some patches
were rearranged or squashed to better fit the current state of u-boot,
and not introduce any build breaks. It follows Ian's initial merge
method of sun7i support: introducing various components first, then
enabling them in the last commit. I tried to keep the commits separate,
thus retaining the original author and Signed-off-bys.

Patch 1 adds a wrapper around "func(USB, usb, 0)" in BOOT_TARGET_DEVICES
to deal with breakage when USB support is not enabled.

Patch 2 adds memory addresses for some hardware blocks new in sun6i.

Patch 3 adds support for the new PRCM (power reset and clock management)
block, which also contains PLL bias voltage control.

Patch 4 adds support for the clock module. This patch is a bunch of
different sun6i related patches on the clock code, from when sun6i
support was introduced to u-boot-sunxi, up to its current form.
This is done to avoid various conflicts and needlessly introducing
then removing macros.

Patch 5 adds mmc support on sun6i.

Patch 6 adds uart0 muxing on sun6i.

Patch 7 enables sun6i support and adds defconfig for the Colombus board.



Cheers
ChenYu


Chen-Yu Tsai (2):
  ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined
  ARM: sun6i: Add clock support

Hans de Goede (1):
  ARM: sunxi-mmc: Add mmc support for sun6i / A31

Maxime Ripard (2):
  ARM: sun6i: Setup the A31 UART0 muxing
  ARM: sunxi: Add basic A31 support

Oliver Schinagl (2):
  ARM: sun6i: Add base address for the new controllers in A31
  ARM: sun6i: Add support for the new power control module found on the
A31

 arch/arm/Kconfig  |   3 +
 arch/arm/cpu/armv7/sunxi/Makefile |   2 +
 arch/arm/cpu/armv7/sunxi/board.c  |   4 +
 arch/arm/cpu/armv7/sunxi/clock_sun6i.c| 107 
 arch/arm/cpu/armv7/sunxi/cpu_info.c   |   2 +
 arch/arm/cpu/armv7/sunxi/prcm.c   |  37 
 arch/arm/include/asm/arch-sunxi/clock.h   |   4 +
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 205 ++
 arch/arm/include/asm/arch-sunxi/cpu.h |   9 +
 arch/arm/include/asm/arch-sunxi/mmc.h |   2 -
 arch/arm/include/asm/arch-sunxi/prcm.h| 238 ++
 board/sunxi/Kconfig   |  10 +-
 configs/Colombus_defconfig|   4 +
 drivers/mmc/sunxi_mmc.c   |   9 +
 include/configs/sun6i.h   |  26 +++
 include/configs/sunxi-common.h|   8 +-
 16 files changed, 666 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/sunxi/clock_sun6i.c
 create mode 100644 arch/arm/cpu/armv7/sunxi/prcm.c
 create mode 100644 arch/arm/include/asm/arch-sunxi/clock_sun6i.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/prcm.h
 create mode 100644 configs/Colombus_defconfig
 create mode 100644 include/configs/sun6i.h

-- 
2.1.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/d/optout.

[linux-sunxi] [PATCH 3/7] ARM: sun6i: Add support for the new power control module found on the A31

2014-09-08 Thread Chen-Yu Tsai 
From: Oliver Schinagl 

To setup clocks and control voltages.

HdG: Rename the files from the somewhat generic pmu name to prcm.{c,h}
HdG: Make the prcm code only deal with the prcm, remove axp221 bits

Signed-off-by: Oliver Schinagl 
Signed-off-by: Hans de Goede 
[w...@csie.org: spacing fixes reported by checkpatch.pl]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/cpu/armv7/sunxi/Makefile  |   1 +
 arch/arm/cpu/armv7/sunxi/prcm.c|  37 +
 arch/arm/include/asm/arch-sunxi/prcm.h | 238 +
 3 files changed, 276 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/sunxi/prcm.c
 create mode 100644 arch/arm/include/asm/arch-sunxi/prcm.h

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
b/arch/arm/cpu/armv7/sunxi/Makefile
index e9721b2..f0473d2 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += timer.o
 obj-y  += board.o
 obj-y  += clock.o
 obj-y  += pinmux.o
+obj-$(CONFIG_SUN6I)+= prcm.o
 obj-$(CONFIG_SUN4I)+= clock_sun4i.o
 obj-$(CONFIG_SUN5I)+= clock_sun4i.o
 obj-$(CONFIG_SUN7I)+= clock_sun4i.o
diff --git a/arch/arm/cpu/armv7/sunxi/prcm.c b/arch/arm/cpu/armv7/sunxi/prcm.c
new file mode 100644
index 000..8f9bea9
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/prcm.c
@@ -0,0 +1,37 @@
+/*
+ * Sunxi A31 Power Management Unit
+ *
+ * (C) Copyright 2013 Oliver Schinagl 
+ * http://linux-sunxi.org
+ *
+ * Based on sun6i sources and earlier U-Boot Allwiner A10 SPL work
+ *
+ * (C) Copyright 2006-2013
+ * Allwinner Technology Co., Ltd. 
+ * Berg Xing 
+ * Tom Cubie 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void prcm_init_apb0(void)
+{
+   struct sunxi_prcm_reg *prcm =
+   (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+   u32 reg_val;
+
+   reg_val = readl(&prcm->apb0_gate);
+   reg_val |= PRCM_APB0_GATE_P2WI | PRCM_APB0_GATE_PIO;
+   writel(reg_val, &prcm->apb0_gate);
+
+   reg_val = readl(&prcm->apb0_reset);
+   reg_val |= PRCM_APB0_RESET_P2WI | PRCM_APB0_RESET_PIO;
+   writel(reg_val, &prcm->apb0_reset);
+}
diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h 
b/arch/arm/include/asm/arch-sunxi/prcm.h
new file mode 100644
index 000..1b40f09
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/prcm.h
@@ -0,0 +1,238 @@
+/*
+ * Sunxi A31 Power Management Unit register definition.
+ *
+ * (C) Copyright 2013 Oliver Schinagl 
+ * http://linux-sunxi.org
+ * Allwinner Technology Co., Ltd. 
+ * Berg Xing 
+ * Tom Cubie 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_PRCM_H
+#define _SUNXI_PRCM_H
+
+#define __PRCM_CPUS_CFG_PRE(n) (((n) & 0x3) << 4)
+#define PRCM_CPUS_CFG_PRE_MASK __PRCM_CPUS_CFG_PRE(0x3)
+#define __PRCM_CPUS_CFG_PRE_DIV(n) (((n) >> 1) - 1)
+#define PRCM_CPUS_CFG_PRE_DIV(n) \
+   __PRCM_CPUS_CFG_PRE(__PRCM_CPUS_CFG_CLK_PRE(n))
+#define __PRCM_CPUS_CFG_POST(n) (((n) & 0x1f) << 8)
+#define PRCM_CPUS_CFG_POST_MASK __PRCM_CPUS_CFG_POST(0x1f)
+#define __PRCM_CPUS_CFG_POST_DIV(n) ((n) - 1)
+#define PRCM_CPUS_CFG_POST_DIV(n) \
+   __PRCM_CPUS_CFG_POST_DIV(__PRCM_CPUS_CFG_POST_DIV(n))
+#define __PRCM_CPUS_CFG_CLK_SRC(n) (((n) & 0x3) << 16)
+#define PRCM_CPUS_CFG_CLK_SRC_MASK __PRCM_CPUS_CFG_CLK_SRC(0x3)
+#define __PRCM_CPUS_CFG_CLK_SRC_LOSC 0x0
+#define __PRCM_CPUS_CFG_CLK_SRC_HOSC 0x1
+#define __PRCM_CPUS_CFG_CLK_SRC_PLL6 0x2
+#define __PRCM_CPUS_CFG_CLK_SRC_PDIV 0x3
+#define PRCM_CPUS_CFG_CLK_SRC_LOSC \
+   __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_LOSC)
+#define PRCM_CPUS_CFG_CLK_SRC_HOSC \
+   __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_HOSC)
+#define PRCM_CPUS_CFG_CLK_SRC_PLL6 \
+   __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_PLL6)
+#define PRCM_CPUS_CFG_CLK_SRC_PDIV \
+   __PRCM_CPUS_CFG_CLK_SRC(__PRCM_CPUS_CFG_CLK_SRC_PDIV)
+
+#define __PRCM_APB0_RATIO(n) (((n) & 0x3) << 0)
+#define PRCM_APB0_RATIO_DIV_MASK __PRCM_APB0_RATIO_DIV(0x3)
+#define __PRCM_APB0_RATIO_DIV(n) (((n) >> 1) - 1)
+#define PRCM_APB0_RATIO_DIV(n) \
+   __PRCM_APB0_RATIO(__PRCM_APB0_RATIO_DIV(n))
+
+#define PRCM_CPU_CFG_NEON_CLK_EN (0x1 << 0)
+#define PRCM_CPU_CFG_CPU_CLK_EN (0x1 << 1)
+
+#define PRCM_APB0_GATE_PIO (0x1 << 0)
+#define PRCM_APB0_GATE_IR (0x1 << 1)
+#define PRCM_APB0_GATE_TIMER01 (0x1 << 2)
+#define PRCM_APB0_GATE_P2WI (0x1 << 3)
+#define PRCM_APB0_GATE_UART (0x1 << 4)
+#define PRCM_APB0_GATE_1WIRE (0x1 << 5)
+#define PRCM_APB0_GATE_I2C (0x1 << 6)
+
+#define PRCM_APB0_RESET_PIO (0x1 << 0)
+#define PRCM_APB0_RESET_IR (0x1 << 1)
+#define PRCM_APB0_RESET_TIMER01 (0x1 << 2)
+#define PRCM_APB0_RESET_P2WI (0x1 << 3)
+#define PRCM_APB0_RESET_UART (0x1 << 4)
+#define PRCM_APB0_RESET_1WIRE (0x1 << 5)
+#define PRCM_APB0_RESET_I2C (0x1 << 6)
+
+#define PRCM_PLL_CTRL_PLL_BIAS (0x1 << 0)
+#define PRCM_PLL_CTRL_HOSC_GAIN_ENH (0x1 << 1)
+#define __PRCM_PLL_CTRL_USB_CLK_SRC(n) (((n) & 0x3) << 4)
+#define PRCM_PLL_CTRL_USB_CLK_SRC_MASK \
+

[linux-sunxi] [PATCH 7/7] ARM: sunxi: Add basic A31 support

2014-09-08 Thread Chen-Yu Tsai 
From: Maxime Ripard 

Add a new sun6i machine that doesn't do much for now.

Signed-off-by: Maxime Ripard 
Signed-off-by: Hans de Goede 
[w...@csie.org: use SPDX labels, adapt to Kconfig system, drop ifdef
around mmc and smp code, drop MACH_TYPE]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/Kconfig|  3 +++
 arch/arm/cpu/armv7/sunxi/cpu_info.c |  2 ++
 board/sunxi/Kconfig | 10 +-
 configs/Colombus_defconfig  |  4 
 include/configs/sun6i.h | 26 ++
 5 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 configs/Colombus_defconfig
 create mode 100644 include/configs/sun6i.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 22f0f09..bfbe6f1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -439,6 +439,9 @@ config TARGET_SUN4I
 config TARGET_SUN5I
bool "Support sun5i"
 
+config TARGET_SUN6I
+   bool "Support sun6i"
+
 config TARGET_SUN7I
bool "Support sun7i"
 
diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c 
b/arch/arm/cpu/armv7/sunxi/cpu_info.c
index 5cf35ac..40c4e13 100644
--- a/arch/arm/cpu/armv7/sunxi/cpu_info.c
+++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c
@@ -23,6 +23,8 @@ int print_cpuinfo(void)
case 7: puts("CPU:   Allwinner A10s (SUN5I)\n"); break;
default: puts("CPU:   Allwinner A1X (SUN5I)\n");
}
+#elif defined CONFIG_SUN6I
+   puts("CPU:   Allwinner A31 (SUN6I)\n");
 #elif defined CONFIG_SUN7I
puts("CPU:   Allwinner A20 (SUN7I)\n");
 #else
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 7bdf958..c78750e 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -14,6 +14,14 @@ config SYS_CONFIG_NAME
 
 endif
 
+if TARGET_SUN6I
+
+config SYS_CONFIG_NAME
+   string
+   default "sun6i"
+
+endif
+
 if TARGET_SUN7I
 
 config SYS_CONFIG_NAME
@@ -22,7 +30,7 @@ config SYS_CONFIG_NAME
 
 endif
 
-if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN7I
+if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I
 
 config SYS_CPU
string
diff --git a/configs/Colombus_defconfig b/configs/Colombus_defconfig
new file mode 100644
index 000..16800de
--- /dev/null
+++ b/configs/Colombus_defconfig
@@ -0,0 +1,4 @@
+CONFIG_SYS_EXTRA_OPTIONS="COLOMBUS"
+CONFIG_ARM=y
+CONFIG_TARGET_SUN6I=y
+CONFIG_FDTFILE="sun6i-a31-colombus.dtb"
diff --git a/include/configs/sun6i.h b/include/configs/sun6i.h
new file mode 100644
index 000..93a1d96
--- /dev/null
+++ b/include/configs/sun6i.h
@@ -0,0 +1,26 @@
+/*
+ * (C) Copyright 2012-2013 Henrik Nordstrom 
+ * (C) Copyright 2013 Luke Kenneth Casson Leighton 
+ * (C) Copyright 2013 Maxime Ripard 
+ *
+ * Configuration settings for the Allwinner A31 (sun6i) CPU
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * A31 specific configuration
+ */
+#define CONFIG_SUN6I   /* sun6i SoC generation */
+
+#define CONFIG_SYS_PROMPT  "sun6i# "
+
+/*
+ * Include common sunxi configuration where most the settings are
+ */
+#include 
+
+#endif /* __CONFIG_H */
-- 
2.1.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/d/optout.

Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Maxime Ripard 
On Mon, Sep 08, 2014 at 01:01:11PM +0200, Luc Verhaegen wrote:
> Signed-off-by: Luc Verhaegen 
> ---
>  meminfo.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meminfo.c b/meminfo.c
> index 86b5c1e..24b4772 100644
> --- a/meminfo.c
> +++ b/meminfo.c
> @@ -60,8 +60,8 @@ enum sunxi_soc_version {
>   SUNXI_SOC_SUN6I = 0x1633, /* A31 */
>   SUNXI_SOC_SUN7I = 0x1651, /* A20 */
>   SUNXI_SOC_SUN8I = 0x1650, /* A23 */
> - SUNXI_SOC_SUN9I = 0x1667, /* A33 */
> - SUNXI_SOC_SUN10I = 0x1635, /* A80 */
> + SUNXI_SOC_SUN9I = 0x1635, /* A80 */
> + SUNXI_SOC_SUN10I = 0x1667, /* A33 */

A33 is actually part of the sun8i family.

Maxime

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


signature.asc
Description: Digital signature

Re: [linux-sunxi] Optimus Board

2014-09-08 Thread RFat 
Wow - I will try this tonight!

Do you have any clue why it doesn't boot from the sdcard? (I tried many 
things including what's described here: 
http://linux-sunxi.org/SDK_build_howto)

Thanks a lot!!

On Monday, September 8, 2014 10:52:02 AM UTC+3, Zhao Zhili wrote:
>
> power off the board, connect the board via serial port, unplug the otg 
> wire, press 2 in serial terminal, power on, the board will boot into FEL 
> mode. plug in the otg wire, open Phoenix, done.
>
>
>  原始邮件 
> 主题：Re: [linux-sunxi] Optimus Board
> 发件人：RFat 
> 收件人：linux...@googlegroups.com 
> 抄送：yrz...@gmail.com ,raa...@gmail.com 
>
>
> Some progress to report:
>
> I finally managed to flash the Optimus Board (OB) through the USB 3. It is 
> done using the PhoenixSuit and without installing the USB drivers (I found 
> all the necessary software at PCDuino8 site). Despite not managing to 
> install the usb driver on windows the PhoenixSuit managed to communicate to 
> the board after doing one very important step: apparently the OB does not 
> have a FEL button and what you need to do is enter the u-boot it loads 
> (hitting any key right on boot time) and then running a command "efex" the 
> device will suddenly be identified on windows and bingo.
>
> PCduino site have several interesting images: an android, a linux kernel 
> which waits to boot from an sdcard (the board will not do this otherwise - 
> or at least I didn't managed to get it to..), and well nothing less than a 
> UBUNTU(!) which actually works with visual interface and everything (it 
> says it is a buggy version - but still impressive). The command line says 
> cubie so perhaps it comes from there?? There are no sources for these 
> images. 
>
> I hope this info may be useful to some of you.
>
>
> On Friday, September 5, 2014 7:19:15 PM UTC+3, RFat wrote:
>>
>> Thanks for your reply. I still could not get any progress; I tired 
>> following the dd instruction you sent in the SDK page as well as two 
>> methods described in pcduino8 page. I also got some stuff from Merrii (as 
>> Jhon suggested). I published it in a newer post on this forum.
>>
>> The mmc does work once the android finish loading, so it may not be an 
>> incompatibility issue between the sdcard and the mmc controller - but who 
>> knows.
>>
>> I'll update if I have any news (and would appreciate any ideas..)
>>
>> Thanks again.
>>
>> On Friday, September 5, 2014 6:52:56 PM UTC+3, Jon Smirl wrote:
>>>
>>> On Fri, Sep 5, 2014 at 11:33 AM, Chen-Yu Tsai  wrote: 
>>> > Hi, 
>>> > 
>>> > On Fri, Sep 5, 2014 at 8:44 AM, Jhon Yi  wrote: 
>>> >> If this doesn't work, the only solution is to ask Merrii, or at least 
>>> >> let them provide one bootable sdcard then dd out the content and 
>>> >> search for the position. 
>>> >> 
>>> >> 2014-09-05 4:55 GMT+08:00 RFat : 
>>> >>> Hi Jhon, 
>>> >>> 
>>> >>> Thanks for your suggestion. I tried: 
>>> >>> dd if=boot0_sdcard_sun9iw1p1.bin of=/dev/mmcblk0 bs=1024 seek=X 
>>> >>> 
>>> >>> where X = 0, 4, 8, .. 
>>> > 
>>> > See http://linux-sunxi.org/SDK_build_howto 
>>> > 
>>> >>> and the board never showed any response - it is just booting from 
>>> the nand 
>>> >>> (I presume..). Was this what you were suggesting? 
>>> > 
>>> > For me, sometimes it responds, sometimes it doesn't. 
>>> > Maybe the mmc controller is picky about cards, or the I/O pins 
>>> > are undervolted. Without a user manual and schematics ATM, 
>>> > it is hard to tell. 
>>>
>>> I have had this problem on another CPU. Notes from that board 
>>>
>>> 100ohm series resistor on all of the MMC lines with 10K pull ups 
>>>
>>> > 
>>> > When I did get a response and boot0 was loaded, boot0 then complained 
>>> > it couldn't initialize mmc0, and halted. 
>>> > 
>>> > 
>>> > ChenYu 
>>> > 
>>> >>> If anyone else have a suggestion - I'll be grateful 
>>> >>> 
>>> >>> 
>>> >>> 
>>> >>> On Thursday, September 4, 2014 3:01:34 AM UTC+2, Jhon Yi wrote: 
>>>  
>>>  I suggest that you'd better ask Merrii to give you the parameters. 
>>>  Otherwise you could first try to dd the boot0 to a clean sd card 
>>> from 
>>>  8kB and see if there is any print out from the serial port (just 
>>> set 
>>> >>> 
>>> >>> 
>>>  
>>>  the serial port of you computer to 115200n8), if not work, move up 
>>> 4kB 
>>>  every trial until you see the right output. Do the seem thing to 
>>> uboot 
>>>  begin from the end of boot0, until you find something meaningful. 
>>> Plus 
>>>  good luck. 
>>>  
>>>  2014-09-04 5:00 GMT+08:00 RFat : 
>>>  > Hi everyone, 
>>>  > 
>>>  > I just got the Optimus board (by Merrii). Seems like a nice 
>>> hotrod.. 
>>>  > 
>>>  > I am trying to get u-boot running from the sdcard and I saw the 
>>>  > binaries: 
>>>  > 
>>>  > u-boot-sun9iw1p1.bin 
>>>  > boot0_sdcard_sun9iw1p1.bin 
>>>  > 
>>>  > in the SDK that poped up recently (A80_SDK_20140728). 
>>>  > 
>>>  > I guess I should be DD-ing the

[linux-sunxi] [PATCH 4/4] meminfo: provide info comment when printing register ranges

2014-09-08 Thread Luc Verhaegen 
This prints the soc version, and should aid future use of collected
data.

Signed-off-by: Luc Verhaegen 
---
 meminfo.c |   37 +
 1 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/meminfo.c b/meminfo.c
index bc8bb82..b200224 100644
--- a/meminfo.c
+++ b/meminfo.c
@@ -636,18 +636,37 @@ sun6i_dramphy_regs[] = {
{0, NULL}
 };
 
+
+static int
+sun6i_soc_version_and_clock_print(void)
+{
+   unsigned int clock;
+   int ret;
+
+   printf("/*\n");
+   printf(" * Sunxi meminfo.\n");
+   printf(" * SoC: 0x%04X\n", soc_version);
+
+   ret = sunxi_dram_clock_read(&clock);
+   if (ret)
+   return ret;
+
+   printf(" * DRAM Clock: %dMHz\n", clock);
+   printf(" */\n");
+   printf("\n");
+
+   return 0;
+}
+
 static int
 sun6i_dram_regs_print(void)
 {
-   unsigned int clock;
int ret;
 
-   ret = sunxi_dram_clock_read(&clock);
+   ret = sun6i_soc_version_and_clock_print();
if (ret)
return ret;
 
-   printf("DRAM Clock: %dMHz\n", clock);
-
ret = dram_registers_print(SUN6I_IO_DRAMCOM_BASE,
   SUN6I_IO_DRAMCOM_SIZE,
   &sun6i_dramcom_regs[0],
@@ -678,15 +697,12 @@ sun6i_dram_regs_print(void)
 static int
 sun8i_dram_regs_print(void)
 {
-   unsigned int clock;
int ret;
 
-   ret = sunxi_dram_clock_read(&clock);
+   ret = sun6i_soc_version_and_clock_print();
if (ret)
return ret;
 
-   printf("DRAM Clock: %dMHz\n", clock);
-
ret = dram_register_range_print(SUN6I_IO_DRAMCOM_BASE,
SUN6I_IO_DRAMCOM_SIZE,
"DRAM COM", "SDR_COM");
@@ -726,15 +742,12 @@ sun8i_dram_regs_print(void)
 static int
 sun9i_dram_regs_print(void)
 {
-   unsigned int clock;
int ret;
 
-   ret = sunxi_dram_clock_read(&clock);
+   ret = sun6i_soc_version_and_clock_print();
if (ret)
return ret;
 
-   printf("DRAM Clock: %dMHz\n", clock);
-
ret = dram_register_range_print(SUN9I_IO_DRAMCOM_BASE,
SUN9I_IO_DRAMCOM_SIZE,
"DRAM COM", "SDR_COM");
-- 
1.7.7

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

[linux-sunxi] meminfo patches for a33 and a80

2014-09-08 Thread Luc Verhaegen 
These patches add untested support for dram register dumping on A33 and A80.
We should now be capable of collecting all dram information on A31(s), A23,
A33 and A80. We can then, in future, when Allwinner makes the relevant
information available to us, add board specific dram settings to our Uboot.

This information should be gathered as part of the New Device howto, and i
suggest that we add a meminfo directory to sunxi-board, where we collect the
relevant dumps.

Luc Verhaegen.

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

[linux-sunxi] [PATCH 3/4] meminfo: add a80 register range printing

2014-09-08 Thread Luc Verhaegen 
Signed-off-by: Luc Verhaegen 
---
 meminfo.c |   65 +
 1 files changed, 65 insertions(+), 0 deletions(-)

diff --git a/meminfo.c b/meminfo.c
index 8961fb2..bc8bb82 100644
--- a/meminfo.c
+++ b/meminfo.c
@@ -162,6 +162,7 @@ sunxi_dram_clock_read(unsigned int *clock)
switch (soc_version) {
case SUNXI_SOC_SUN6I:
case SUNXI_SOC_SUN8I:
+   case SUNXI_SOC_SUN9I:
case SUNXI_SOC_SUN10I:
n++;
break;
@@ -708,6 +709,67 @@ sun8i_dram_regs_print(void)
return 0;
 }
 
+/*
+ *
+ */
+#define SUN9I_IO_DRAMCOM_BASE 0x01C62000
+#define SUN9I_IO_DRAMCOM_SIZE 0x1000
+#define SUN9I_IO_DRAMCTL0_BASE 0x01C63000
+#define SUN9I_IO_DRAMCTL0_SIZE 0x1000
+#define SUN9I_IO_DRAMCTL1_BASE 0x01C64000
+#define SUN9I_IO_DRAMCTL1_SIZE 0x1000
+#define SUN9I_IO_DRAMPHY0_BASE 0x01C65000
+#define SUN9I_IO_DRAMPHY0_SIZE 0x1000
+#define SUN9I_IO_DRAMPHY1_BASE 0x01C66000
+#define SUN9I_IO_DRAMPHY1_SIZE 0x1000
+
+static int
+sun9i_dram_regs_print(void)
+{
+   unsigned int clock;
+   int ret;
+
+   ret = sunxi_dram_clock_read(&clock);
+   if (ret)
+   return ret;
+
+   printf("DRAM Clock: %dMHz\n", clock);
+
+   ret = dram_register_range_print(SUN9I_IO_DRAMCOM_BASE,
+   SUN9I_IO_DRAMCOM_SIZE,
+   "DRAM COM", "SDR_COM");
+   if (ret)
+   return ret;
+
+
+   ret = dram_register_range_print(SUN9I_IO_DRAMCTL0_BASE,
+   SUN9I_IO_DRAMCTL0_SIZE,
+   "DRAM CTL0", "SDR_CTL0");
+   if (ret)
+   return ret;
+
+   ret = dram_register_range_print(SUN9I_IO_DRAMCTL1_BASE,
+   SUN9I_IO_DRAMCTL1_SIZE,
+   "DRAM CTL1", "SDR_CTL1");
+   if (ret)
+   return ret;
+
+
+   ret = dram_register_range_print(SUN9I_IO_DRAMPHY0_BASE,
+   SUN9I_IO_DRAMPHY0_SIZE,
+   "DRAM PHY0", "SDR_PHY0");
+   if (ret)
+   return ret;
+
+   ret = dram_register_range_print(SUN9I_IO_DRAMPHY1_BASE,
+   SUN9I_IO_DRAMPHY1_SIZE,
+   "DRAM PHY1", "SDR_PHY1");
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
 static void
 print_usage(const char *name)
 {
@@ -765,6 +827,7 @@ main(int argc, char *argv[])
ret = soc_version_read();
if (ret)
return ret;
+
switch (soc_version) {
case SUNXI_SOC_SUN4I:
case SUNXI_SOC_SUN5I:
@@ -775,6 +838,8 @@ main(int argc, char *argv[])
case SUNXI_SOC_SUN8I:
case SUNXI_SOC_SUN10I:
return sun8i_dram_regs_print();
+   case SUNXI_SOC_SUN9I:
+   return sun9i_dram_regs_print();
default:
fprintf(stderr, "Error: unknown or unhandled Soc: 0x%04X\n",
soc_version);
-- 
1.7.7

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

[linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33

2014-09-08 Thread Luc Verhaegen 
Signed-off-by: Luc Verhaegen 
---
 meminfo.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meminfo.c b/meminfo.c
index 86b5c1e..24b4772 100644
--- a/meminfo.c
+++ b/meminfo.c
@@ -60,8 +60,8 @@ enum sunxi_soc_version {
SUNXI_SOC_SUN6I = 0x1633, /* A31 */
SUNXI_SOC_SUN7I = 0x1651, /* A20 */
SUNXI_SOC_SUN8I = 0x1650, /* A23 */
-   SUNXI_SOC_SUN9I = 0x1667, /* A33 */
-   SUNXI_SOC_SUN10I = 0x1635, /* A80 */
+   SUNXI_SOC_SUN9I = 0x1635, /* A80 */
+   SUNXI_SOC_SUN10I = 0x1667, /* A33 */
 };
 
 static enum sunxi_soc_version soc_version;
-- 
1.7.7

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

[linux-sunxi] [PATCH 2/4] meminfo: add a33 register range printing

2014-09-08 Thread Luc Verhaegen 
Should be the same as a23.

Signed-off-by: Luc Verhaegen 
---
 meminfo.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/meminfo.c b/meminfo.c
index 24b4772..8961fb2 100644
--- a/meminfo.c
+++ b/meminfo.c
@@ -162,6 +162,7 @@ sunxi_dram_clock_read(unsigned int *clock)
switch (soc_version) {
case SUNXI_SOC_SUN6I:
case SUNXI_SOC_SUN8I:
+   case SUNXI_SOC_SUN10I:
n++;
break;
default:
@@ -772,6 +773,7 @@ main(int argc, char *argv[])
case SUNXI_SOC_SUN6I:
return sun6i_dram_regs_print();
case SUNXI_SOC_SUN8I:
+   case SUNXI_SOC_SUN10I:
return sun8i_dram_regs_print();
default:
fprintf(stderr, "Error: unknown or unhandled Soc: 0x%04X\n",
-- 
1.7.7

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

[linux-sunxi] Re: [PATCH v2] ARM: sun5i: Add DT for HSG H702 tablet board

2014-09-08 Thread Chen-Yu Tsai 
On Mon, Sep 8, 2014 at 5:37 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Mon, Sep 01, 2014 at 10:14:39PM +0800, Chen-Yu Tsai wrote:
>> This is a Q8 format 7 inch tablet with an Allwinner A13 SoC.
>> It has 512MB DRAM, 4GB NAND flash, an accelerometer, camera,
>> RTL8188-based WiFi, and micro SD slot for external storage.
>>
>> It is likely made by a subsidiary of Hanns.G (Hannstar).
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>
>> Added missing '>' to the email address in the header.
>>
>> Sorry for the noise.
>>
>> ---
>>  arch/arm/boot/dts/Makefile   |   1 +
>>  arch/arm/boot/dts/sun5i-a13-hsg-h702.dts | 101 
>> +++
>>  2 files changed, 102 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index b8c5cd3..94e61a6 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -406,6 +406,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
>>  dtb-$(CONFIG_MACH_SUN5I) += \
>>   sun5i-a10s-olinuxino-micro.dtb \
>>   sun5i-a10s-r7-tv-dongle.dtb \
>> + sun5i-a13-hsg-h702.dtb \
>>   sun5i-a13-olinuxino.dtb \
>>   sun5i-a13-olinuxino-micro.dtb
>>  dtb-$(CONFIG_MACH_SUN6I) += \
>> diff --git a/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts 
>> b/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
>> new file mode 100644
>> index 000..6335c1e
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
>> @@ -0,0 +1,101 @@
>> +/*
>> + * Copyright 2014 Chen-Yu Tsai 
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>
> Could you relicense the file to match the GPL/X11 dual license we've
> been working on?

Sure. That's the plan. :)
Waiting for that series to be merged before I send a new version.

>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>> +
>> +/dts-v1/;
>> +/include/ "sun5i-a13.dtsi"
>> +/include/ "sunxi-common-regulators.dtsi"
>> +
>> +/ {
>> + model = "HSG H702";
>> + compatible = "hsg,h702", "allwinner,sun5i-a13";
>> +
>> + soc@01c0 {
>> + mmc0: mmc@01c0f000 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_h702>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 6 0 0>; /* PG0 */
>> + cd-inverted;
>> + status = "okay";
>> + };
>> +
>> + usbphy: phy@01c13400 {
>> + usb1_vbus-supply = <®_usb1_vbus>;
>> + status = "okay";
>> + };
>> +
>> + ehci0: usb@01c14000 {
>> + status = "okay";
>> + };
>> +
>> + ohci0: usb@01c14400 {
>> + status = "okay";
>> + };
>> +
>> + pinctrl@01c20800 {
>> + mmc0_cd_pin_h702: mmc0_cd_pin@0 {
>> + allwinner,pins = "PG0";
>> + allwinner,function = "gpio_in";
>> + allwinner,drive = <0>;
>> + allwinner,pull = <1>;
>> + };
>> + };
>> +
>> + uart1: serial@01c28400 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart1_pins_b>;
>> + status = "okay";
>> + };
>> +
>> + i2c0: i2c@01c2ac00 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&i2c0_pins_a>;
>> + status = "okay";
>> +
>> + axp209: pmic@34 {
>> + compatible = "x-powers,axp209";
>> + reg = <0x34>;
>> + interrupts = <0>;
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> + };
>> + };
>> +
>> + i2c1: i2c@01c2b000 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&i2c1_pins_a>;
>> + status = "okay";
>> +
>> + pcf8563: rtc@51 {
>> + compatible = "nxp,pcf8563";
>> + reg = <0x51>;
>> + };
>> + };
>> +
>> + i2c2: i2c@01c2b400 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&i2c2_pins_a>;
>> + status = "okay";
>> + };
>> + };
>> +
>> + reg_usb1_vbus: usb1-vbus {
>> + /*
>> +  * There doesn't seem to be a GPIO for controlling
>> +  * vbus, despi

[linux-sunxi] Re: [PATCH v2] ARM: sun5i: Add DT for HSG H702 tablet board

2014-09-08 Thread Maxime Ripard 
Hi,

On Mon, Sep 01, 2014 at 10:14:39PM +0800, Chen-Yu Tsai wrote:
> This is a Q8 format 7 inch tablet with an Allwinner A13 SoC.
> It has 512MB DRAM, 4GB NAND flash, an accelerometer, camera,
> RTL8188-based WiFi, and micro SD slot for external storage.
> 
> It is likely made by a subsidiary of Hanns.G (Hannstar).
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
> 
> Added missing '>' to the email address in the header.
> 
> Sorry for the noise.
> 
> ---
>  arch/arm/boot/dts/Makefile   |   1 +
>  arch/arm/boot/dts/sun5i-a13-hsg-h702.dts | 101 
> +++
>  2 files changed, 102 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b8c5cd3..94e61a6 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -406,6 +406,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
>  dtb-$(CONFIG_MACH_SUN5I) += \
>   sun5i-a10s-olinuxino-micro.dtb \
>   sun5i-a10s-r7-tv-dongle.dtb \
> + sun5i-a13-hsg-h702.dtb \
>   sun5i-a13-olinuxino.dtb \
>   sun5i-a13-olinuxino-micro.dtb
>  dtb-$(CONFIG_MACH_SUN6I) += \
> diff --git a/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts 
> b/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
> new file mode 100644
> index 000..6335c1e
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
> @@ -0,0 +1,101 @@
> +/*
> + * Copyright 2014 Chen-Yu Tsai 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:

Could you relicense the file to match the GPL/X11 dual license we've
been working on?

> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +/include/ "sun5i-a13.dtsi"
> +/include/ "sunxi-common-regulators.dtsi"
> +
> +/ {
> + model = "HSG H702";
> + compatible = "hsg,h702", "allwinner,sun5i-a13";
> +
> + soc@01c0 {
> + mmc0: mmc@01c0f000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_h702>;
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + cd-gpios = <&pio 6 0 0>; /* PG0 */
> + cd-inverted;
> + status = "okay";
> + };
> +
> + usbphy: phy@01c13400 {
> + usb1_vbus-supply = <®_usb1_vbus>;
> + status = "okay";
> + };
> +
> + ehci0: usb@01c14000 {
> + status = "okay";
> + };
> +
> + ohci0: usb@01c14400 {
> + status = "okay";
> + };
> +
> + pinctrl@01c20800 {
> + mmc0_cd_pin_h702: mmc0_cd_pin@0 {
> + allwinner,pins = "PG0";
> + allwinner,function = "gpio_in";
> + allwinner,drive = <0>;
> + allwinner,pull = <1>;
> + };
> + };
> +
> + uart1: serial@01c28400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins_b>;
> + status = "okay";
> + };
> +
> + i2c0: i2c@01c2ac00 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins_a>;
> + status = "okay";
> +
> + axp209: pmic@34 {
> + compatible = "x-powers,axp209";
> + reg = <0x34>;
> + interrupts = <0>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> + };
> +
> + i2c1: i2c@01c2b000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins_a>;
> + status = "okay";
> +
> + pcf8563: rtc@51 {
> + compatible = "nxp,pcf8563";
> + reg = <0x51>;
> + };
> + };
> +
> + i2c2: i2c@01c2b400 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pins_a>;
> + status = "okay";
> + };
> + };
> +
> + reg_usb1_vbus: usb1-vbus {
> + /*
> +  * There doesn't seem to be a GPIO for controlling
> +  * vbus, despite the fex file saying otherwise.
> +  * Override the original settings with empty ones.
> +  */
> + pinctrl-0 = <>;
> + gpio = <>;
> + status = "okay";

H, no. Just use a regular fixed regulator here, like reg_vcc3v3.

[linux-sunxi] Differences between Allwinner's u-boot and kernel and uboot-sunxi/linux-sunxi on sun7i

2014-09-08 Thread mittorn 
Hello.
I Have A20 tablet Wexler Tab 7200.
It is only partially supported (gt9xx driver is missing and suspend does not 
work. Some fex modification is needed to make wifi and usb work.
Stock kernel won't boot from sdcard and linux-sunxi kernel wont boot from stock 
u-boot
I have compiled linux-3.3 kernel from A20 sdk and flashed it to /dev/nandc, it 
successfully booted and can work with all hardware (including usb, wifi and 
touchscreen).
What is wrong? Why only stock u-boot can be used with Allwinner's SDK? And what 
patches can be used to make Allwinner's kernel boot from sdcard uboot?

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

回复: [linux-sunxi] Optimus Board

2014-09-08 Thread quink 
power off the board, connect the board via serial port, unplug the otg wire, press 2 in serial terminal, power on, the board will boot into FEL mode. plug in the otg wire, open Phoenix, done. 原始邮件 主题：Re: [linux-sunxi] Optimus Board发件人：RFat 收件人：linux-sunxi@googlegroups.com抄送：yrz...@gmail.com,raan...@gmail.comSome progress to report:I finally managed to flash the Optimus Board (OB) through the USB 3. It is done using the PhoenixSuit and without installing the USB drivers (I found all the necessary software at PCDuino8 site). Despite not managing to install the usb driver on windows the PhoenixSuit managed to communicate to the board after doing one very important step: apparently the OB does not have a FEL button and what you need to do is enter the u-boot it loads (hitting any key right on boot time) and then running a command "efex" the device will suddenly be identified on windows and bingo.PCduino site have several interesting images: an android, a linux kernel which waits to boot from an sdcard (the board will not do this otherwise - or at least I didn't managed to get it to..), and well nothing less than a UBUNTU(!) which actually works with visual interface and everything (it says it is a buggy version - but still impressive). The command line says cubie so perhaps it comes from there?? There are no sources for these images. I hope this info may be useful to some of you.On Friday, September 5, 2014 7:19:15 PM UTC+3, RFat wrote:Thanks for your reply. I still could not get any progress; I tired following the dd instruction you sent in the SDK page as well as two methods described in pcduino8 page. I also got some stuff from Merrii (as Jhon suggested). I published it in a newer post on this forum.The mmc does work once the android finish loading, so it may not be an incompatibility issue between the sdcard and the mmc controller - but who knows.I'll update if I have any news (and would appreciate any ideas..)Thanks again.On Friday, September 5, 2014 6:52:56 PM UTC+3, Jon Smirl wrote:On Fri, Sep 5, 2014 at 11:33 AM, Chen-Yu Tsai  wrote:
> Hi,
>
> On Fri, Sep 5, 2014 at 8:44 AM, Jhon Yi  wrote:
>> If this doesn't work, the only solution is to ask Merrii, or at least
>> let them provide one bootable sdcard then dd out the content and
>> search for the position.
>>
>> 2014-09-05 4:55 GMT+08:00 RFat :
>>> Hi Jhon,
>>>
>>> Thanks for your suggestion. I tried:
>>> dd if=boot0_sdcard_sun9iw1p1.bin of=/dev/mmcblk0 bs=1024 seek=X
>>>
>>> where X = 0, 4, 8, ..
>
> See http://linux-sunxi.org/SDK_build_howto
>
>>> and the board never showed any response - it is just booting from the nand
>>> (I presume..). Was this what you were suggesting?
>
> For me, sometimes it responds, sometimes it doesn't.
> Maybe the mmc controller is picky about cards, or the I/O pins
> are undervolted. Without a user manual and schematics ATM,
> it is hard to tell.

I have had this problem on another CPU. Notes from that board

100ohm series resistor on all of the MMC lines with 10K pull ups

>
> When I did get a response and boot0 was loaded, boot0 then complained
> it couldn't initialize mmc0, and halted.
>
>
> ChenYu
>
>>> If anyone else have a suggestion - I'll be grateful
>>>
>>>
>>>
>>> On Thursday, September 4, 2014 3:01:34 AM UTC+2, Jhon Yi wrote:

 I suggest that you'd better ask Merrii to give you the parameters.
 Otherwise you could first try to dd the boot0 to a clean sd card from
 8kB and see if there is any print out from the serial port (just set
>>>
>>>

 the serial port of you computer to 115200n8), if not work, move up 4kB
 every trial until you see the right output. Do the seem thing to uboot
 begin from the end of boot0, until you find something meaningful. Plus
 good luck.

 2014-09-04 5:00 GMT+08:00 RFat :
 > Hi everyone,
 >
 > I just got the Optimus board (by Merrii). Seems like a nice hotrod..
 >
 > I am trying to get u-boot running from the sdcard and I saw the
 > binaries:
 >
 > u-boot-sun9iw1p1.bin
 > boot0_sdcard_sun9iw1p1.bin
 >
 > in the SDK that poped up recently (A80_SDK_20140728).
 >
 > I guess I should be DD-ing these files to the sdcard but I am not sure
 > how.
 > There must be specific values for the seek option -- does anyone have a
 > clue
 > (I am not sure whether I am asking a trivial or a hard question..)
 >
 > Moreover, this board does not have a FEL or U-boot buttons like other
 > boards
 > - will it always look for something readable in the sdcard and then
 > moves on
 > the the nand?
 >
 > I guess everyone is very excited about the availability of these A80
 > boards
 > and this mysterious SDK - the sunxi community is about to have crazy
 > power
 > from a crazily modest device (ah, the late 80's of Acron paid off..)
 >
 > Thanks!
>
> --
> Yo