Re: [linux-sunxi] [PATCH] MAINTAINERS: Update Allwinner entry and add new maintainer

2015-10-07 Thread Chen-Yu Tsai 
On Thu, Oct 8, 2015 at 1:39 AM, Maxime Ripard
 wrote:
> Add Chen-Yu Tsai as a co-maintainer to the ARM sunxi support.
>
> While we are doing so, also update the entry for new SoCs.
>
> Signed-off-by: Maxime Ripard 
> ---
>  MAINTAINERS | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 797236befd27..d6a9a016f3d4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -894,11 +894,12 @@ M:Lennert Buytenhek 
>  L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  S: Maintained
>
> -ARM/Allwinner A1X SoC support
> +ARM/Allwinner sunXi SoC support
>  M: Maxime Ripard 
> +M: Chen-Yu Tsai 

Acked-by: Chen-Yu Tsai 

>  L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  S: Maintained
> -N: sun[x4567]i
> +N: sun[x456789]i

I thought we updated this already, in d30dbc6de5732 ("ARM: sunxi: Add sun[89]i
 to MAINTAINERS entry"). It's in your sunxi/core-for-4.4 branch.

>
>  ARM/Allwinner SoC Clock Support
>  M: Emilio López 
> --
> 2.5.3
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[linux-sunxi] [PATCH v3] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

2015-10-07 Thread Timo Sigurdsson 
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt. Also
add board-specific OPP to use slightly higher voltages at lower
frequencies since Kevin Hilman reported that not all BananaPi boards run
stable at the default voltages inherited by sun7i-a20.dtsi.

Signed-off-by: Timo Sigurdsson 
---
Changes since v2:

- (Re)Added board-specific OPP after Kevin Hilman reported problems with
the default voltages at lower frequencies
---
 arch/arm/boot/dts/sun7i-a20-bananapi.dts | 45 +---
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts 
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,20 @@
status = "okay";
 };
 
+&cpu0 {
+   cpu-supply = <®_dcdc2>;
+   operating-points = <
+   /* kHzuV */
+   96  140
+   912000  140
+   864000  135
+   72  125
+   528000  115
+   312000  110
+   144000  105
+   >;
+};
+
 &ehci0 {
status = "okay";
 };
@@ -119,13 +133,9 @@
status = "okay";
 
axp209: pmic@34 {
-   compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-   interrupt-controller;
-   #interrupt-cells = <1>;
};
 };
 
@@ -182,6 +192,33 @@
};
 };
 
+#include "axp209.dtsi"
+
+®_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+   regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
 ®_usb1_vbus {
status = "okay";
 };
-- 
2.1.4

-- 
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 v3 1/5] clk: Add a basic multiplier clock

2015-10-07 Thread Stephen Boyd 
On 10/07, Maxime Ripard wrote:
> On Mon, Oct 05, 2015 at 11:09:29AM -0700, Stephen Boyd wrote:
> > On 10/05, Maxime Ripard wrote:
> > > 
> > > Actually, the logic is also reversed.
> > > 
> > > The divider driver will always try to find some rate that is higher
> > > than the one we already have, without going above than the one
> > > requested.
> > > 
> > > Here, we're tring to be lower than the best rate, without going below
> > > the requested rate.
> > 
> > So then a tri-state flag that indicates, closest, less than,
> > greater than?
> 
> Still, the computation itself is different, and the only consolidation
> we could possibly do is by not duplicating the ROUND_CLOSEST. We would
> end up with two different code pathes in the same function, which I
> feel would make it unnecessarily complex.

Ok. No worries.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

-- 
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: dts: sunxi: Add regulators for LeMaker BananaPi

2015-10-07 Thread Timo Sigurdsson 
Hi Maxime,

Maxime Ripard schrieb am 07.10.2015 19:49:

> Hi Timo,
> 
> On Wed, Oct 07, 2015 at 05:49:18PM +0200, Timo Sigurdsson wrote:
>> Hi Kevin,
>> Hi Maxime,
>> 
>> Kevin Hilman schrieb am 07.10.2015 16:36:
>> 
>> > "Timo Sigurdsson"  writes:
>> >> I still think that the lower voltages may be the cause of your problem
>> >> with that specific board, so could you please test the attached patch on
>> >> top of my patch that you first experienced the problem with? Please let 
>> >> us know whether this solves your issue or whether we need to dig deeper.
>> > 
>> > Thanks for the patch.  Looks like it's the OPPs.
>> > 
>> > I went back to next-20150923 and verified it still fails.  Then, I
>> > applied your patch and saw that it boots just fine.
>> 
>> Good. Then we can easily fix this, I guess.
>> 
>> @Maxime: How should we handle this? In its current form, the patch applies
>> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
>> In an earlier discussion, it was said that this can be done, even though it
>> might not be the most elegant approach. But then again, I think it
>> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
>> boards since this is - to my knowledge - the first and only report that an
>> A20 board has stability issues at the lower voltages (although not too many
>> boards use voltage scaling yet).
> 
> If you count only the number of boards, indeed, but if you count the
> number of devices actually used in the field, we cover already a
> significant portion of them.
> 
>> So, would you prefer to keep this as a patch for BananaPi only, or
>> change the dtsi for all A20 devices instead?
> 
> Yeah, we probably can keep that for bananapi only at the moment, and
> try to generalize that afterwards.

Ok.

> 
>> In case we keep it as it is, what is the correct commit to point to as
>> "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since
>> that's where these voltages were defined. But then again, if we don't
>> change the dtsi, should I point to my regulator patch instead?
> 
> I don't think it fixes anything at this point. We droped your commit
> that was using the A20 OPPs, so in the history so far we don't have
> anything to fix, just enable cpufreq again.

Ok. I'll send a third version of the regulator patch then with the
updated opp included.

Thanks,

Timo

-- 
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: dts: sunxi: Add regulators for LeMaker BananaPi

2015-10-07 Thread Maxime Ripard 
Hi Timo,

On Wed, Oct 07, 2015 at 05:49:18PM +0200, Timo Sigurdsson wrote:
> Hi Kevin,
> Hi Maxime,
> 
> Kevin Hilman schrieb am 07.10.2015 16:36:
> 
> > "Timo Sigurdsson"  writes:
> >> I still think that the lower voltages may be the cause of your problem
> >> with that specific board, so could you please test the attached patch on
> >> top of my patch that you first experienced the problem with? Please let 
> >> us know whether this solves your issue or whether we need to dig deeper.
> > 
> > Thanks for the patch.  Looks like it's the OPPs.
> > 
> > I went back to next-20150923 and verified it still fails.  Then, I
> > applied your patch and saw that it boots just fine.
> 
> Good. Then we can easily fix this, I guess.
> 
> @Maxime: How should we handle this? In its current form, the patch applies
> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
> In an earlier discussion, it was said that this can be done, even though it
> might not be the most elegant approach. But then again, I think it
> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
> boards since this is - to my knowledge - the first and only report that an
> A20 board has stability issues at the lower voltages (although not too many
> boards use voltage scaling yet).

If you count only the number of boards, indeed, but if you count the
number of devices actually used in the field, we cover already a
significant portion of them.

> So, would you prefer to keep this as a patch for BananaPi only, or
> change the dtsi for all A20 devices instead?

Yeah, we probably can keep that for bananapi only at the moment, and
try to generalize that afterwards.

> In case we keep it as it is, what is the correct commit to point to as
> "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since
> that's where these voltages were defined. But then again, if we don't
> change the dtsi, should I point to my regulator patch instead?

I don't think it fixes anything at this point. We droped your commit
that was using the A20 OPPs, so in the history so far we don't have
anything to fix, just enable cpufreq again.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/d/optout.


signature.asc
Description: Digital signature

[linux-sunxi] [PATCH] MAINTAINERS: Update Allwinner entry and add new maintainer

2015-10-07 Thread Maxime Ripard 
Add Chen-Yu Tsai as a co-maintainer to the ARM sunxi support.

While we are doing so, also update the entry for new SoCs.

Signed-off-by: Maxime Ripard 
---
 MAINTAINERS | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 797236befd27..d6a9a016f3d4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -894,11 +894,12 @@ M:Lennert Buytenhek 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 
-ARM/Allwinner A1X SoC support
+ARM/Allwinner sunXi SoC support
 M: Maxime Ripard 
+M: Chen-Yu Tsai 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
-N: sun[x4567]i
+N: sun[x456789]i
 
 ARM/Allwinner SoC Clock Support
 M: Emilio López 
-- 
2.5.3

-- 
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: dts: sunxi: Add regulators for LeMaker BananaPi

2015-10-07 Thread Stefan Monnier 
> @Maxime: How should we handle this? In its current form, the patch applies
> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
> In an earlier discussion, it was said that this can be done, even though it
> might not be the most elegant approach. But then again, I think it
> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
> boards since this is - to my knowledge - the first and only report that an
> A20 board has stability issues at the lower voltages (although not too many
> boards use voltage scaling yet).

IIUC this setting doesn't affect signals external to the A20, so it
seems like it should be board-agnostic.


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] Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

2015-10-07 Thread Timo Sigurdsson 
Hi Kevin,
Hi Maxime,

Kevin Hilman schrieb am 07.10.2015 16:36:

> "Timo Sigurdsson"  writes:
>> I still think that the lower voltages may be the cause of your problem
>> with that specific board, so could you please test the attached patch on
>> top of my patch that you first experienced the problem with? Please let 
>> us know whether this solves your issue or whether we need to dig deeper.
> 
> Thanks for the patch.  Looks like it's the OPPs.
> 
> I went back to next-20150923 and verified it still fails.  Then, I
> applied your patch and saw that it boots just fine.

Good. Then we can easily fix this, I guess.

@Maxime: How should we handle this? In its current form, the patch applies
only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
In an earlier discussion, it was said that this can be done, even though it
might not be the most elegant approach. But then again, I think it
shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
boards since this is - to my knowledge - the first and only report that an
A20 board has stability issues at the lower voltages (although not too many
boards use voltage scaling yet). So, would you prefer to keep this as a
patch for BananaPi only, or change the dtsi for all A20 devices instead?

In case we keep it as it is, what is the correct commit to point to as
"Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since
that's where these voltages were defined. But then again, if we don't
change the dtsi, should I point to my regulator patch instead?


Thanks and regards,

Timo

-- 
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: dts: sunxi: Add regulators for LeMaker BananaPi

2015-10-07 Thread Kevin Hilman 
"Timo Sigurdsson"  writes:

> Kevin Hilman schrieb am 24.09.2015 19:57:
>> kernelci.org started finding boot faiulres[1] on bananapi linux-next
>> around next-20150918, but it was only failing in some labs and not
>> others.  I finally bisected it down to this patch, which landed in
>> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
>> for LeMaker BananaPi.  Reverting that commit on top of next-20150923
>> gets my bananapi booting again.
>> 
>> Note it's kind of an interesting boot failure.  The kernel boots fully
>> to a shell, but panics after running a few commands.  In particular
>> 'dmesg -n1' seems to trigger it usually[2].
>> 
>> Kevin
>> 
>> [1]
>> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
>> [2]
>> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html
>
> following up on my last email: I'm back from my vacation and I tried to
> reproduce your problem, but my board doesn't seem to be affected, so I
> cannot trigger it.
>
> I still think that the lower voltages may be the cause of your problem
> with that specific board, so could you please test the attached patch on
> top of my patch that you first experienced the problem with? Please let 
> us know whether this solves your issue or whether we need to dig deeper.

Thanks for the patch.  Looks like it's the OPPs.

I went back to next-20150923 and verified it still fails.  Then, I
applied your patch and saw that it boots just fine.

Kevin

-- 
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: SD Linux support for Allwinner A10s

2015-10-07 Thread Сергей Санников 
I stated debian for Olimex
,
but all usb don't work :(((

2015-10-07 13:27 GMT+03:00 :

> суббота, 11 января 2014 г., 14:26:49 UTC+3 пользователь Vitaliy Blats
> написал:
> > 1) Why Debian ?)
> > Try to use lubuntu.
> > 2) Could you please show us result of "ifconfig" -a and "dmesg" ?
> >
> > суббота, 11 января 2014 г., 7:33:06 UTC+2 пользователь ebina написал:A
> data point for future readers who get this far.  I ordered an MK802 which
> seems to also be a clone with an A10s processor.  The Fedora18r2 image
> finally booted and ran for me, Yeah!  If you want Ubuntu instead of Fedora,
> I found this post:
> http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/2079
> which shows after you get Fedora 18 working, you can replace the rootfs
> with that from the melee-ububtu-lucid image to get a working Ubuntu 10.04
> on this clone.
> > Also, if you prefer debian, I found this post:
> http://www.modlog.net/?p=763 which says you can actually use the image
> from the A10s-OLinuXino-MICRO to boot the mk802_a10s.  I tried this, and it
> also worked for me.  Finally I found similar to above that if after setting
> up the OlinuXino image I replace the rootfs with that from debian wheezy:
> https://www.miniand.com/forums/forums/development/topics/debian-wheezy-lxde-armhf-build
> this works.  Still no networking with the debian, but I see there is a
> debian-testing:
> https://www.miniand.com/forums/forums/development/topics/debian-testing-lxde-armhf-build
> so I will try that combined with the OlinuXino and see what I get.
>
> Are you started lubuntu on a10s?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "linux-sunxi" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/linux-sunxi/-HfHG-yyCVs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [linux-sunxi] Re: OV2643 Camera on A20

2015-10-07 Thread jonsm...@gmail.com 
On Wed, Oct 7, 2015 at 6:19 AM,   wrote:
> On Sunday, 5 January 2014 11:02:07 UTC+5:30, Jon Smirl  wrote:
>> I have an A20 system here that has a lot of noise in the camera. Does anyone 
>> have experience with noise like this? Is this something that software can 
>> impact or is it a problem in PCB? It is OV2643 image sensor.
>>
>>
>>
>> Looks like it is using this driver.
>> http://files.virt2real.ru/docs/
>>
>>
>>
>>  P1050011_1.JPG
>>
>>
>>
>>  P1050013_1.JPG
>>
>>
>> --
>> Jon Smirl
>> jons...@gmail.com
>
> I am not able to establish SCCB communication with OV2643 (my 2MP sensor on 
> board). I was not able to use the existing I2C controller to communicate over 
> SCCB. Please note I2C needs an ACK from Slave -- in SCCB there is no ACK 
> concept. Also there is one don't care or NA bit in described in SCCB that is 
> not there in I2C.

I tossed this system about a year ago since I never could get it
working correctly. The Android A20 source has the semi-working OV2643
driver in it. AFAIK it has never been ported over to mainline.

I am having much more success with external camera boards based on the
Hi3518e and then hooking them up to the main CPU via USB. You can buy
nice camera PCBA for under $10.  For these chips the camera is the
main line of business and they do a much better job of making it work.
Plus it is way easy to attach multiple cameras.


>
> Hence I wrote my own APB to SCCB controller and started the HW validation.
>
> But I am still not getting the correct data from if I read a register over 
> SCCB.
>
> Requesting for help -- if there is any know issue etc and how they are 
> resolved.
> if someone used the I2C to communicate over SCCB, what you did for ACK and 
> Don't care / NA bit.
>
> Please give me some information -- I am ok to use i2c or SCCB controller 
> whatever it works.
>
> --
> 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.



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

Re: [linux-sunxi] Re: SD Linux support for Allwinner A10s

2015-10-07 Thread wanderingxsx 
суббота, 11 января 2014 г., 14:26:49 UTC+3 пользователь Vitaliy Blats написал:
> 1) Why Debian ?)
> Try to use lubuntu.
> 2) Could you please show us result of "ifconfig" -a and "dmesg" ?
> 
> суббота, 11 января 2014 г., 7:33:06 UTC+2 пользователь ebina написал:A data 
> point for future readers who get this far.  I ordered an MK802 which seems to 
> also be a clone with an A10s processor.  The Fedora18r2 image finally booted 
> and ran for me, Yeah!  If you want Ubuntu instead of Fedora, I found this 
> post: http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/2079 
> which shows after you get Fedora 18 working, you can replace the rootfs with 
> that from the melee-ububtu-lucid image to get a working Ubuntu 10.04 on this 
> clone.
> Also, if you prefer debian, I found this post: http://www.modlog.net/?p=763 
> which says you can actually use the image from the A10s-OLinuXino-MICRO to 
> boot the mk802_a10s.  I tried this, and it also worked for me.  Finally I 
> found similar to above that if after setting up the OlinuXino image I replace 
> the rootfs with that from debian wheezy: 
> https://www.miniand.com/forums/forums/development/topics/debian-wheezy-lxde-armhf-build
>  this works.  Still no networking with the debian, but I see there is a 
> debian-testing: 
> https://www.miniand.com/forums/forums/development/topics/debian-testing-lxde-armhf-build
>  so I will try that combined with the OlinuXino and see what I get.

Are you started lubuntu on a10s?

-- 
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: OV2643 Camera on A20

2015-10-07 Thread nskabra76 
On Sunday, 5 January 2014 11:02:07 UTC+5:30, Jon Smirl  wrote:
> I have an A20 system here that has a lot of noise in the camera. Does anyone 
> have experience with noise like this? Is this something that software can 
> impact or is it a problem in PCB? It is OV2643 image sensor.
> 
> 
> 
> Looks like it is using this driver.
> http://files.virt2real.ru/docs/
> 
> 
> 
>  P1050011_1.JPG
> 
> 
> 
>  P1050013_1.JPG
> 
> 
> -- 
> Jon Smirl
> jons...@gmail.com

I am not able to establish SCCB communication with OV2643 (my 2MP sensor on 
board). I was not able to use the existing I2C controller to communicate over 
SCCB. Please note I2C needs an ACK from Slave -- in SCCB there is no ACK 
concept. Also there is one don't care or NA bit in described in SCCB that is 
not there in I2C.

Hence I wrote my own APB to SCCB controller and started the HW validation.

But I am still not getting the correct data from if I read a register over SCCB.

Requesting for help -- if there is any know issue etc and how they are resolved.
if someone used the I2C to communicate over SCCB, what you did for ACK and 
Don't care / NA bit.

Please give me some information -- I am ok to use i2c or SCCB controller 
whatever it works.

-- 
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: SD Linux support for Allwinner A10s

2015-10-07 Thread wanderingxsx 
Hello!
Sorry for bad English.
So is it possible to run Ubuntu on A10s?

-- 
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 v3 1/5] clk: Add a basic multiplier clock

2015-10-07 Thread Maxime Ripard 
On Mon, Oct 05, 2015 at 11:09:29AM -0700, Stephen Boyd wrote:
> On 10/05, Maxime Ripard wrote:
> > Hi,
> > 
> > On Fri, Oct 02, 2015 at 01:43:08PM -0700, Stephen Boyd wrote:
> > > On 09/29, Maxime Ripard wrote:
> > > > +
> > > > +   if (!val && mult->flags & CLK_MULTIPLIER_ZERO_BYPASS)
> > > > +   val = 1;
> > > > +   
> > > > +   return parent_rate * val;
> > > > +}
> > > > +
> > > > +static bool __is_best_rate(unsigned long rate, unsigned long new,
> > > > +  unsigned long best, unsigned long flags)
> > > > +{
> > > > +   if (flags & CLK_MULTIPLIER_ROUND_CLOSEST)
> > > 
> > > Is the only difference in this function vs the divider one that
> > > flag? Maybe we should make this function generic to the framework
> > > and pass a flag indicating closest or not.
> > 
> > Actually, the logic is also reversed.
> > 
> > The divider driver will always try to find some rate that is higher
> > than the one we already have, without going above than the one
> > requested.
> > 
> > Here, we're tring to be lower than the best rate, without going below
> > the requested rate.
> 
> So then a tri-state flag that indicates, closest, less than,
> greater than?

Still, the computation itself is different, and the only consolidation
we could possibly do is by not duplicating the ROUND_CLOSEST. We would
end up with two different code pathes in the same function, which I
feel would make it unnecessarily complex.

> 
> > 
> > > 
> > > > +   unsigned long val;
> > > > +
> > > > +   if (mult->lock)
> > > > +   spin_lock_irqsave(mult->lock, flags);
> > > 
> > > This needs the same "trick" that we did in the generic clock
> > > types to avoid sparse warnings.
> > 
> > The __acquire call ?
> 
> Yes.

Ok.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/d/optout.


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v2 3/3] ARM: dts: sun6i: hummingbird: Drop AXP221 DC1SW and DC5LDO supplies

2015-10-07 Thread Maxime Ripard 
On Wed, Sep 30, 2015 at 02:39:47PM +0800, Chen-Yu Tsai wrote:
> "dcdc1-supply" and "dcdc5-supply" have been dropped, as they are
> internally connected and should not be represented in the device
> tree.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/d/optout.


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v5 0/5] ARM: sunxi: Add Reduced Serial Bus support

2015-10-07 Thread Maxime Ripard 
On Thu, Oct 01, 2015 at 07:57:46PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
> 
> This is my fifth attempt at adding support for Allwinner's Reduced
> Serial Bus (RSB), which is used to communicate with PMICs and other
> peripherals on their newer SoCs, such as the A23/A33/A80.
> 
> RSB is a simplified two wire interface using push-pull outputs,
> supporting multiple slaves, address and data parity checks, and
> clock speeds up to 20 MHz. The bus only supports simple register
> read/writes, with possible register sizes of 8/16/32 bits. Access
> sizes not matching the slave device register sizes result in NACKs
> or errors. 32 bit registers in devices have yet to be seen.
> 
> v4 and later adds a platform driver for the RSB controller under
> drivers/soc/sunxi, which adds a custom driver type and bus type
> for slave drivers to use. Custom regmap support is also merged
> into the controller driver. Currently the driver only exports 2
> symbols: sunxi_rsb_driver_register() & __devm_regmap_init_sunxi_rsb().

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/d/optout.


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

2015-10-07 Thread Maxime Ripard 
Hi Timo,

On Mon, Oct 05, 2015 at 07:39:57PM +0200, Timo Sigurdsson wrote:
> Hi Kevin,
> 
> Kevin Hilman schrieb am 24.09.2015 19:57:
> > kernelci.org started finding boot faiulres[1] on bananapi linux-next
> > around next-20150918, but it was only failing in some labs and not
> > others.  I finally bisected it down to this patch, which landed in
> > linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> > for LeMaker BananaPi.  Reverting that commit on top of next-20150923
> > gets my bananapi booting again.
> > 
> > Note it's kind of an interesting boot failure.  The kernel boots fully
> > to a shell, but panics after running a few commands.  In particular
> > 'dmesg -n1' seems to trigger it usually[2].
> > 
> > Kevin
> > 
> > [1]
> > http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> > [2]
> > http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html
> 
> following up on my last email: I'm back from my vacation and I tried to
> reproduce your problem, but my board doesn't seem to be affected, so I
> cannot trigger it.

weird.

> I still think that the lower voltages may be the cause of your problem
> with that specific board, so could you please test the attached patch on
> top of my patch that you first experienced the problem with? Please let 
> us know whether this solves your issue or whether we need to dig deeper.
> 
> Has anybody else been able to reproduce Kevin's issue?

I've talked to Kevin yesterday about that issue, and he's been away
from his boards for quite some time too, so we'll have to wait a bit
to solve that issue.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/d/optout.


signature.asc
Description: Digital signature

Re: [linux-sunxi] [PATCH v2 5/5] ARM: sun5i: Add C.H.I.P DTS

2015-10-07 Thread Maxime Ripard 
On Wed, Oct 07, 2015 at 09:24:07AM +1100, Julian Calaby wrote:
> >> > +   chosen {
> >> > +   stdout-path = "serial0:115200n8";
> >>
> >> Should the composite output be enabled here too?
> >
> > AFAIK, the stdout-path only supports a single output device, and I
> > don't think it really is an issue since framebuffer console will
> > attach to the framebuffer automatically.
> 
> I was referring to enabling it in chosen, not stdout-path, but I
> couldn't remember if uboot does that for us or not.

It's not really u-boot that does that. the framebuffer console stuff
will attach automatically to the first framebuffer that comes in and
log the kernel logs there, it's all in-kernel.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/d/optout.


signature.asc
Description: Digital signature

Re: [linux-sunxi] [PATCH v2 1/2] mmc: Add support for marking hpi as broken through devicetree

2015-10-07 Thread Olliver Schinagl 

Hey Hans,

On 01-04-15 17:26, Hans de Goede wrote:

The eMMC on a tablet I've will stop working / communicating as soon as
the kernel executes:

mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_HPI_MGMT, 1,
card->ext_csd.generic_cmd6_time);

There seems to be no way to reliable identify eMMC-s which have a broken
hpi implementation, but at least for eMMC's which are soldered onto a board
we can work around this by specifying that hpi is broken in devicetree.
We've been talking about this a little off-list, and I was just 
triggered again by this so I'm following up on it again.


The same issue bit me in the ass on a Micron 'industrial' grade eMMC 
(MTFC4GACAANA) and luckily you found this back then to help me.


As we discussed, this may very well be a limitation of the mmc 
controller, rather then the MMC chip. While we only have a sample size 
of 2 on 2 different socs (with likely the same mmc IP) (A13/A20) I found 
in the JEDEC spec in the appendix on changes from 4.4 to 4.41:
Introduce of High Priority Interrupt mechanism, HPI background and one 
of possible solutions.


Which leaves me to believe, that HPI was added to eMMC in version 4.41 
and was not available before. Both the A13 and A20 user manuals state 
that the MMC controller in these socs is only version 4.3.


Obviously I know far to little as to what does and what does not work 
with an MMC-host, since it's just a simple data-bus, but I would not be 
surprised if these things are somewhere somewhat related, so hopefully 
someone on this list can give their opinion on this.


I already checked the core/mmc.c where the version is read from the mmc 
controller to see if we can trigger on this based on version, however it 
seems only the major version number is stored here [0]?


So in my opinion, it is quite likely that this setting be moved up to 
the mmc-core level, for the SoC, rather then the card itself?


[0] http://lxr.free-electrons.com/source/drivers/mmc/core/mmc.c#L148


Signed-off-by: Hans de Goede 
---
Changes in v2:
-Fix of_node leakage
---
  Documentation/devicetree/bindings/mmc/mmc-card.txt | 31 ++
  drivers/mmc/core/mmc.c | 10 ++-
  2 files changed, 40 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt

diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.txt 
b/Documentation/devicetree/bindings/mmc/mmc-card.txt
new file mode 100644
index 000..a70fcd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.txt
@@ -0,0 +1,31 @@
+mmc-card / eMMC bindings
+
+
+This documents describes the devicetree bindings for a mmc-host controller
+child node describing a mmc-card / an eMMC, see "Use of Function subnodes"
+in mmc.txt
+
+Required properties:
+-compatible : Must be "mmc-card"
+-reg: Must be <0>
+
+Optional properties:
+-broken-hpi : Use this to indicate that the mmc-card has a broken hpi
+  implementation, and that hpi should not be used
+
+Example:
+
+&mmc2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc2_pins_a>;
+   vmmc-supply = <®_vcc3v3>;
+   bus-width = <8>;
+   non-removable;
+   status = "okay";
+
+   mmccard: mmccard@0 {
+   reg = <0>;
+   compatible = "mmc-card";
+   broken-hpi;
+   };
+};
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 1d41e85..c84131e 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -11,6 +11,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -336,6 +337,8 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
  {
int err = 0, idx;
unsigned int part_size;
+   struct device_node *np;
+   bool broken_hpi = false;
  
  	/* Version is coded in the CSD_STRUCTURE byte in the EXT_CSD register */

card->ext_csd.raw_ext_csd_structure = ext_csd[EXT_CSD_STRUCTURE];
@@ -349,6 +352,11 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
}
}
  
+	np = mmc_of_find_child_device(card->host, 0);

+   if (np && of_device_is_compatible(np, "mmc-card"))
+   broken_hpi = of_property_read_bool(np, "broken-hpi");
+   of_node_put(np);
+
/*
 * The EXT_CSD format is meant to be forward compatible. As long
 * as CSD_STRUCTURE does not change, all values for EXT_CSD_REV
@@ -494,7 +502,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
}
  
  		/* check whether the eMMC card supports HPI */

-   if (ext_csd[EXT_CSD_HPI_FEATURES] & 0x1) {
+   if (!broken_hpi && (ext_csd[EXT_CSD_HPI_FEATURES] & 0x1)) {
card->ext_csd.hpi = 1;
if (ext_csd[EXT_CSD_HPI_FEATURES] & 0x2)
card->ext_csd.hpi

[linux-sunxi] Re: [PATCH v5 2/5] soc: sunxi: Add driver for Allwinner Reduced Serial Bus

2015-10-07 Thread Maxime Ripard 
Hi,

On Mon, Oct 05, 2015 at 11:43:48PM +0800, Chen-Yu Tsai wrote:
> On Sun, Oct 4, 2015 at 10:16 PM, Maxime Ripard
>  wrote:
> > Hi,
> >
> > On Thu, Oct 01, 2015 at 07:57:48PM +0800, Chen-Yu Tsai wrote:
> >> Reduced Serial Bus (RSB) is an Allwinner proprietery interface
> >> used to communicate with PMICs and other peripheral ICs.
> >>
> >> RSB is a two-wire push-pull serial bus that supports 1 master
> >> device and up to 15 active slave devices.
> >>
> >> Signed-off-by: Chen-Yu Tsai 
> >
> > Acked-by: Maxime Ripard 
> 
> Slightly confused. Are we merging this through your tree or directly
> through arm-soc?

I thought Arnd was the maintainer of drivers/soc, but it doesn't seem
like there's any. I'll apply your patches.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/d/optout.


signature.asc
Description: Digital signature