[linux-sunxi] Re: [PATCH 4/4] pinctrl-sunxi: Fix interrupt register offset calculation
On Mon, Feb 17, 2014 at 10:19:44PM +0100, Hans de Goede wrote: > This fixing setting the interrupt type for eints >= 8. > > Signed-off-by: Hans de Goede Acked-by: Maxime Ripard -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Testing of Line In my A20 board.
Hi Puneet, can you run 'arecord -iL' and paste back the result. I don't think anything else needs to be done to the script as capture is enabled. Is there any sound settings in Android that you can change?, I've not got any Axx devices to hand with audio in so I'm working a bit blind here. Is there anything in the kernel logs that suggest that the device is capturing?, CK On 18 February 2014 08:11, Puneet B wrote: > Hi, > > I ported Android 4.2 in my A20 board to test LINE IN. > > But still i am able to record my voice. > > but audio is coming through hdmi output. > > how to make LINE IN to work. > > so that i can records any voice. > > Is there anything need to change in script. > > Here i am attaching script. > > > Regards > Punith > > > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Testing of Line In my A20 board.
Hi CodeKipper, Now i am trying with ubuntu only. Here is my arecord -iL output: root@linaro-ubuntu-desktop:/# arecord -iL Home directory not accessible: Permission denied null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server default:CARD=sunxicodec sunxi-CODEC, sunxi PCM Default Audio Device sysdefault:CARD=sunxicodec sunxi-CODEC, sunxi PCM Default Audio Device dmix:CARD=sunxicodec,DEV=0 sunxi-CODEC, sunxi PCM Direct sample mixing device dsnoop:CARD=sunxicodec,DEV=0 sunxi-CODEC, sunxi PCM Direct sample snooping device hw:CARD=sunxicodec,DEV=0 sunxi-CODEC, sunxi PCM Direct hardware device without any conversions plughw:CARD=sunxicodec,DEV=0 sunxi-CODEC, sunxi PCM Hardware device with all software conversions root@linaro-ubuntu-desktop:/# i fallow this link. http://jordilin.wordpress.com/2006/07/28/howto-recording-audio-from-the-command-line/ But i am not getting how to save alsamixer configuration. Kinldy suggest me. Regards Punith -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Testing of Line In my A20 board.
Hi Puneet, The only thing that I can recommend at the moment is to probe around the files under /proc/asound. I won't be able to have a look at this on real hardware until tomorrow. You shouldn't have to save alsamixer configuration, from memory this is just interacting with the kernel and therefore settings the values in the hardware's registers. CK On 18 February 2014 10:36, Puneet B wrote: > Hi CodeKipper, > > Now i am trying with ubuntu only. > > Here is my arecord -iL output: > > root@linaro-ubuntu-desktop:/# arecord -iL > Home directory not accessible: Permission denied > > null > Discard all samples (playback) or generate zero samples (capture) > pulse > PulseAudio Sound Server > > default:CARD=sunxicodec > sunxi-CODEC, sunxi PCM > Default Audio Device > sysdefault:CARD=sunxicodec > sunxi-CODEC, sunxi PCM > Default Audio Device > dmix:CARD=sunxicodec,DEV=0 > sunxi-CODEC, sunxi PCM > Direct sample mixing device > dsnoop:CARD=sunxicodec,DEV=0 > sunxi-CODEC, sunxi PCM > Direct sample snooping device > hw:CARD=sunxicodec,DEV=0 > sunxi-CODEC, sunxi PCM > Direct hardware device without any conversions > plughw:CARD=sunxicodec,DEV=0 > sunxi-CODEC, sunxi PCM > Hardware device with all software conversions > root@linaro-ubuntu-desktop:/# > > i fallow this link. > > > http://jordilin.wordpress.com/2006/07/28/howto-recording-audio-from-the-command-line/ > > But i am not getting how to save alsamixer configuration. > > Kinldy suggest me. > > Regards > Punith > > > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: A20 + OV5640 (parallel) issues
Hi Jon, Good to have someone to talk to :) I've already previously found your posts about EU3000 - I even downloaded the Fex file to check mine some time ago, so I'm a bit into the subject. I don't have any Android experience except for my phone, so I can't help you much there, but I can tell you what's currently wrong with the sunxi linux driver for ov5640. For me, anything less than 720p is unacceptable. My first problem was that I get like 7fps in 720p (kernel 3.4.75+ from linux-sunxi) - this was driver issue, as the ov5640 driver (part of sun4i_csix driver) is badly written - there is only a tryout of the format, the sensor actually defaults always to sensor_default_regs[], instead of using regs for, let's say, 720p. So it isn't at all configured correctly. This is only the first problem. The second problem is that register settings included in the kernel driver are mostly useless - almost all of them are either 3.75, 7.5 or 15fps, while I need at least 30. So, since I did some development on Freescale's i.MX6, I used some settings from there - I've got 720p @30fps running like this. It works ok, maybe a bit noisey (although this could easily come from my interface board), but my colors are still bad and as you can see I'm currently debugging this (almost certain that it's the display driver issue). Anyway, I'm debugging the display driver - it seems that some things are wrong there, or at least I'm not really configuring it right. What kernel do you have - in which mode are you using 720p (15fps, 30fps?) and what are the errors you see? BR, Ivan -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] A10 PIC flasher with GPIOs
A10 PIC flasher with GPIOs: http://dangerousprototypes.com/2014/02/18/picberry-r-pi-allwinner-a10-pic-programmer-using-gpio-connector/ -- Benjamin Henrion FFII Brussels - +32-484-566109 - +32-2-4148403 "In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators." -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH] ARM: sun7i: add arch timer node
The Allwinner A20 SoC is built around a pair of Cortex-A7 cores,
which have the usual generic timers. Report this in the DT.
Signed-off-by: Marc Zyngier
---
arch/arm/boot/dts/sun7i-a20.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 9ff0948..894dbe7 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -41,6 +41,14 @@
reg = <0x4000 0x8000>;
};
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <1 13 0xf08>,
+<1 14 0xf08>,
+<1 11 0xf08>,
+<1 10 0xf08>;
+ };
+
clocks {
#address-cells = <1>;
#size-cells = <1>;
--
1.8.3.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/groups/opt_out.
[linux-sunxi] Re: [PATCH v7 1/8] clk: sunxi: factors: automatic reparenting support
On Mon, Feb 17, 2014 at 11:02:15AM +0100, David Lanzendörfer wrote: > From: Emilio López > > This commit implements .determine_rate, so that our factor clocks can be > reparented when needed. > > Signed-off-by: Emilio López Your signed-off-by is missing here. Once you added it, you can add my Acked-by Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v7 3/8] ARM: sunxi: clk: export clk_sunxi_mmc_phase_control
On Mon, Feb 17, 2014 at 11:02:28AM +0100, David Lanzendörfer wrote: > From: Hans de Goede > > Signed-off-by: Hans de Goede Again, your SoB is missing, and that can be squashed with the previous patch. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v7 2/8] clk: sunxi: Implement MMC phase control
Hi, On Mon, Feb 17, 2014 at 11:02:21AM +0100, David Lanzendörfer wrote: > From: Emilio López > > Signed-off-by: Emilio López You're missing your Signed-off-by here too. Remember, for every patch you send, your Signed-off-by must be there, regardless wether you're the author or not. A commit log would be very much welcome too. Now, down to the patch itself, I remember Mike saying that he would prefer adding a function in the framework instead of hardcoding it. Mike, what's your feeling on this? Would merging this seem reasonnable to you as is, or do you want to take this to the framework? > --- > drivers/clk/sunxi/clk-sunxi.c | 35 +++ > 1 file changed, 35 insertions(+) > > diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c > index abb6c5a..33b9977 100644 > --- a/drivers/clk/sunxi/clk-sunxi.c > +++ b/drivers/clk/sunxi/clk-sunxi.c > @@ -377,6 +377,41 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32 > parent_rate, > > > /** > + * clk_sunxi_mmc_phase_control() - configures MMC clock phase control > + */ If you don't go the framework road, some documentation on what are the arguments it takes and what it's supposed to return would be great. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v7 5/8] ARM: dts: sun7i: Add support for mmc
On Mon, Feb 17, 2014 at 11:02:41AM +0100, David Lanzendörfer wrote:
> Signed-off-by: David Lanzendörfer
> Signed-off-by: Hans de Goede
> ---
> arch/arm/boot/dts/sun7i-a20-cubieboard2.dts |8 +++
> arch/arm/boot/dts/sun7i-a20-cubietruck.dts |8 +++
> arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 23 +
> arch/arm/boot/dts/sun7i-a20.dtsi| 61
> +++
> 4 files changed, 100 insertions(+)
>
I'd prefer to have three patches here:
- One that add the controllers
- One that add the pin muxing options
- One that enable the controllers on the various boards.
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> index 5c51cb8..ae800b6 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> @@ -34,6 +34,14 @@
> };
> };
>
> + mmc0: mmc@01c0f000 {
> + pinctrl-names = "default", "default";
> + pinctrl-0 = <&mmc0_pins_a>;
> + pinctrl-1 = <&mmc0_cd_pin_reference_design>;
This can be made a single pinctrl group, you don't need the pinctrl-1
stuff, it only complicates the node.
> + cd-gpios = <&pio 7 1 0>; /* PH1 */
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> led_pins_cubieboard2: led_pins@0 {
> allwinner,pins = "PH20", "PH21";
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> index f9dcb61..370cef84 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> @@ -19,6 +19,14 @@
> compatible = "cubietech,cubietruck", "allwinner,sun7i-a20";
>
> soc@01c0 {
> + mmc0: mmc@01c0f000 {
> + pinctrl-names = "default", "default";
> + pinctrl-0 = <&mmc0_pins_a>;
> + pinctrl-1 = <&mmc0_cd_pin_reference_design>;
> + cd-gpios = <&pio 7 1 0>; /* PH1 */
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> led_pins_cubietruck: led_pins@0 {
> allwinner,pins = "PH7", "PH11", "PH20", "PH21";
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> index ead3013..685ec06 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> @@ -34,7 +34,30 @@
> };
> };
>
> + mmc0: mmc@01c0f000 {
> + pinctrl-names = "default", "default";
> + pinctrl-0 = <&mmc0_pins_a>;
> + pinctrl-1 = <&mmc0_cd_pin_reference_design>;
> + cd-gpios = <&pio 7 1 0>; /* PH1 */
> + status = "okay";
> + };
> +
> + mmc3: mmc@01c12000 {
> + pinctrl-names = "default", "default";
> + pinctrl-0 = <&mmc3_pins_a>;
> + pinctrl-1 = <&mmc3_cd_pin_olinuxinom>;
> + cd-gpios = <&pio 7 11 0>; /* PH11 */
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> + mmc3_cd_pin_olinuxinom: mmc3_cd_pin@0 {
> + allwinner,pins = "PH11";
> + allwinner,function = "gpio_in";
> + allwinner,drive = <0>;
> + allwinner,pull = <1>;
> + };
> +
> led_pins_olinuxino: led_pins@0 {
> allwinner,pins = "PH2";
> allwinner,function = "gpio_out";
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 9ff0948..5b55414 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -355,6 +355,46 @@
> #size-cells = <0>;
> };
>
> + mmc0: mmc@01c0f000 {
> + compatible = "allwinner,sun5i-a13-mmc";
> + reg = <0x01c0f000 0x1000>;
> + clocks = <&ahb_gates 8>, <&mmc0_clk>;
> + clock-names = "ahb", "mod";
> + interrupts = <0 32 4>;
> + bus-width = <4>;
This belongs to the board, the controller itself is able to handle
several bus width.
> + status = "disabled";
> + };
> +
> + mmc1: mmc@01c1 {
> + compatible = "allwinner,sun5i-a13-mmc";
> + reg = <0x01c1 0x1000>;
> + clocks = <&ahb_gates 9>, <&mmc1_clk>;
[linux-sunxi] Re: [PATCH v4 0/8] ARM: sunxi: rename DT clock node names to clk@N
El 07/02/14 16:24, Maxime Ripard escribió: On Mon, Feb 03, 2014 at 09:51:36AM +0800, Chen-Yu Tsai wrote: Hi everyone, This is v4 of the clock node renaming patch series, which renames the clock nodes in sunxi dts to conform to device tree naming conventions, i.e. clk@N. Dummy clocks that will be renamed/removed later, or clocks sharing registers are not renamed. Renamed clock nodes have clock-output-names properties added to desginate their names. Support for this is added in the first patch. Applied the last 4 patches to sunxi/dt-for-3.15. And I've applied the first 4 to sunxi-clk-for-mike some time ago. Thanks for working on this! Emilio -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v4 0/5] clk: sunxi usb clks support
Hi Hans, El 07/02/14 12:21, Hans de Goede escribió: Hi All, And here is v4 of my sunxi usb clks support series. Changes since v2: -rename the compatibilty strings from foo-usb-gates-clk to foo-usb-clk Changes since v3: -rename the compatibilty string for sun4i-usb-clk to sun4i-a10-usb-clk Note the dts bits (patches 3-5) of this series depends on Chen-Yu Tsai's clk rename series. Emilio, should Mike pick patches 1-2 up directly, or should they go through your tree? I have taken 1-2 on sunxi-clk-for-mike with acks from Maxime and Philipp. Maxime, can you please add patches 3-5 to your dts tree ? Assuming that wens clk rename patches are already there. Maxime, please do :) Cheers, and thanks for working on USB! Emilio -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v4 1/5] clk: sunxi: Add support for PLL6 on the A31
El 05/02/14 10:05, Maxime Ripard escribió: The A31 has a slightly different PLL6 clock. Add support for this new clock in our driver. Signed-off-by: Maxime Ripard Taken via sunxi-clk-for-mike. Thanks! Emilio -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v4 0/8] Add Allwinner A20 GMAC ethernet support
El 10/02/14 16:47, Maxime Ripard escribió: Hi Chen-Yu, On Mon, Feb 10, 2014 at 06:35:46PM +0800, Chen-Yu Tsai wrote: Hi, This is the v4 of the remaining Allwinner A20 GMAC glue layer patches. The stmmac driver changes have been merged through net-next. The remaining bits are clock and DT patches. The patches should be applied over my clock renaming patches. The Allwinner A20 SoC integrates an early version of dwmac IP from Synopsys. On top of that is a hardware glue layer. This layer needs to be configured before the dwmac can be used. Part of the glue layer is a clock mux, which controls the source and direction of the TX clock used by GMAC. Just merged patches 2-8. And I just merged patch 1 on my branch for Mike Cheers, Emilio -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v7 5/8] ARM: dts: sun7i: Add support for mmc
Hi,
On 02/18/2014 03:22 PM, Maxime Ripard wrote:
On Mon, Feb 17, 2014 at 11:02:41AM +0100, David Lanzendörfer wrote:
Signed-off-by: David Lanzendörfer
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts |8 +++
arch/arm/boot/dts/sun7i-a20-cubietruck.dts |8 +++
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 23 +
arch/arm/boot/dts/sun7i-a20.dtsi| 61 +++
4 files changed, 100 insertions(+)
I'd prefer to have three patches here:
- One that add the controllers
- One that add the pin muxing options
- One that enable the controllers on the various boards.
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index 5c51cb8..ae800b6 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -34,6 +34,14 @@
};
};
+ mmc0: mmc@01c0f000 {
+ pinctrl-names = "default", "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ pinctrl-1 = <&mmc0_cd_pin_reference_design>;
This can be made a single pinctrl group, you don't need the pinctrl-1
stuff, it only complicates the node.
Then how do we deal with boards which use a different gpio for card-detect ?
In that case we don't want to change the mux setting of the reference
design cd pin. IOW I believe that having 2 separate pinctrl settings for
this is the rigt thing todo. I would prefer using just mmc0_cd_pin_a instead
of _reference_design though.
Oh wait, you're probably talking about using:
pinctrl-0 = <&mmc0_pins_a>,
<&mmc0_cd_pin_reference_design>;
Yes that would be better.
+ cd-gpios = <&pio 7 1 0>; /* PH1 */
+ status = "okay";
+ };
+
pinctrl@01c20800 {
led_pins_cubieboard2: led_pins@0 {
allwinner,pins = "PH20", "PH21";
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index f9dcb61..370cef84 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -19,6 +19,14 @@
compatible = "cubietech,cubietruck", "allwinner,sun7i-a20";
soc@01c0 {
+ mmc0: mmc@01c0f000 {
+ pinctrl-names = "default", "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ pinctrl-1 = <&mmc0_cd_pin_reference_design>;
+ cd-gpios = <&pio 7 1 0>; /* PH1 */
+ status = "okay";
+ };
+
pinctrl@01c20800 {
led_pins_cubietruck: led_pins@0 {
allwinner,pins = "PH7", "PH11", "PH20", "PH21";
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index ead3013..685ec06 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -34,7 +34,30 @@
};
};
+ mmc0: mmc@01c0f000 {
+ pinctrl-names = "default", "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ pinctrl-1 = <&mmc0_cd_pin_reference_design>;
+ cd-gpios = <&pio 7 1 0>; /* PH1 */
+ status = "okay";
+ };
+
+ mmc3: mmc@01c12000 {
+ pinctrl-names = "default", "default";
+ pinctrl-0 = <&mmc3_pins_a>;
+ pinctrl-1 = <&mmc3_cd_pin_olinuxinom>;
+ cd-gpios = <&pio 7 11 0>; /* PH11 */
+ status = "okay";
+ };
+
pinctrl@01c20800 {
+ mmc3_cd_pin_olinuxinom: mmc3_cd_pin@0 {
+ allwinner,pins = "PH11";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <0>;
+ allwinner,pull = <1>;
+ };
+
led_pins_olinuxino: led_pins@0 {
allwinner,pins = "PH2";
allwinner,function = "gpio_out";
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 9ff0948..5b55414 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -355,6 +355,46 @@
#size-cells = <0>;
};
+ mmc0: mmc@01c0f000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ahb_gates 8>, <&mmc0_clk>;
+ clock-names = "ahb",
[linux-sunxi] Re: [PATCH v7 4/8] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
Hi,
Sorry for taking a bit of time to review this.
On Mon, Feb 17, 2014 at 11:02:34AM +0100, David Lanzendörfer wrote:
> This is based on the driver Allwinner ships in their Android kernel sources.
>
> Initial porting to upstream kernels done by David Lanzendörfer, additional
> fixes and cleanups by Hans de Goede.
This belongs to the driver copyright or MODULE_AUTHOR, not really in
the commit log.
What you should describe here is what the driver does, what the device
it drives is capable of, would it be possible to share some common
code with other drivers, why didn't you do it, etc.
>
> It uses dma in bus-master mode using a built-in designware idmac controller,
> which is identical to the one found in the mmc-dw hosts.
> The rest of the host is not identical to mmc-dw.
>
> Signed-off-by: David Lanzendörfer
> Signed-off-by: Hans de Goede
> ---
> drivers/mmc/host/Kconfig |7
> drivers/mmc/host/Makefile|2
> drivers/mmc/host/sunxi-mmc.c | 876
> ++
> drivers/mmc/host/sunxi-mmc.h | 239 +++
> 4 files changed, 1124 insertions(+)
> create mode 100644 drivers/mmc/host/sunxi-mmc.c
> create mode 100644 drivers/mmc/host/sunxi-mmc.h
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 1384f67..7caf266 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -689,3 +689,10 @@ config MMC_REALTEK_PCI
> help
> Say Y here to include driver code to support SD/MMC card interface
> of Realtek PCI-E card reader
> +
> +config MMC_SUNXI
> + tristate "Allwinner sunxi SD/MMC Host Controller support"
> + depends on ARCH_SUNXI
> + help
> + This selects support for the SD/MMC Host Controller on
> + Allwinner sunxi SoCs.
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 3483b6b..f3c7c243 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -54,6 +54,8 @@ obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
>
> obj-$(CONFIG_MMC_REALTEK_PCI)+= rtsx_pci_sdmmc.o
>
> +obj-$(CONFIG_MMC_SUNXI) += sunxi-mmc.o
> +
> obj-$(CONFIG_MMC_SDHCI_PLTFM)+= sdhci-pltfm.o
> obj-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
> obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX)+= sdhci-esdhc-imx.o
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> new file mode 100644
> index 000..752e913
> --- /dev/null
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -0,0 +1,876 @@
> +/*
> + * Driver for sunxi SD/MMC host controllers
> + * (C) Copyright 2007-2011 Reuuimlla Technology Co., Ltd.
> + * (C) Copyright 2007-2011 Aaron Maoye
> + * (C) Copyright 2013-2014 O2S GmbH
> + * (C) Copyright 2013-2014 David Lanzend?rfer
> + * (C) Copyright 2013-2014 Hans de Goede
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sunxi-mmc.h"
Usually, drivers don't have a header of their own.
> +static int sunxi_mmc_init_host(struct mmc_host *mmc)
> +{
> + u32 rval;
> + struct sunxi_mmc_host *smc_host = mmc_priv(mmc);
> + int ret;
> +
> + ret = clk_prepare_enable(smc_host->clk_ahb);
> + if (ret) {
> + dev_err(mmc_dev(smc_host->mmc), "AHB clk err %d\n", ret);
> + return ret;
> + }
Newline.
> + ret = clk_prepare_enable(smc_host->clk_mod);
> + if (ret) {
> + dev_err(mmc_dev(smc_host->mmc), "MOD clk err %d\n", ret);
> + clk_disable_unprepare(smc_host->clk_ahb);
> + return ret;
> + }
> +
> + /* reset controller */
> + rval = mci_readl(smc_host, REG_GCTRL) | SDXC_HARDWARE_RESET;
You seem to be sometimes using either a oneline construct like this
one, or on several lines. It would be great if you were to be using
the same everywhere.
> + mci_writel(smc_host, REG_GCTRL, rval);
> +
> + mci_writel(smc_host, REG_FTRGL, 0x20070008);
> + mci_writel(smc_host, REG_TMOUT, 0x);
> + mci_writel(smc_host, REG_IMASK, smc_host->sdio_imask);
> + mci_writel(smc_host, REG_RINTR, 0x);
> + mci_writel(smc_host, REG_DBGC, 0xdeb);
> + mci_writel(smc_host, REG_FUNS, 0xceaa);
> + mci_writel(smc_host, REG_DLBA, smc_host->sg_dma);
Newline.
> + rval = mci_readl(smc_host, REG_GCTRL)|SDXC_INTERRUPT_ENABLE_BIT;
> + rval &= ~SDXC_ACCESS_DONE_DIRECT;
> +
[linux-sunxi] Re: [PATCH v7 8/8] ARM: sunxi: Add documentation for driver for SD/MMC hosts found on Allwinner sunxi SoCs
On Mon, Feb 17, 2014 at 11:03:02AM +0100, David Lanzendörfer wrote:
> Signed-off-by: David Lanzendörfer
> ---
> .../devicetree/bindings/mmc/sunxi-mmc.txt | 32
>
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> new file mode 100644
> index 000..5ce8c5e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> @@ -0,0 +1,32 @@
> +* Allwinner sunxi MMC controller
> +
> +The highspeed MMC host controller on Allwinner SoCs provides an interface
> +for MMC, SD and SDIO types of memory cards.
> +
> +Supported maximum speeds are the ones of the eMMC standard 4.5 as well
> +as the speed of SD standard 3.0.
> +Absolute maximum transfer rate is 200MB/s
> +
> +Required properties:
> +- compatible: Should be "allwinner,--mmc".
> + The supported chips include a10, a10s, 13, a20 and a31.
Please use the real compatibles here. It's much easier to search
for. Plus, your driver doesn't support all the SoCs you're mentionning here.
> +- base registers are 0x1000 appart, so the base of mmc1
> + would be 0x01c0f000+0x1000=0x01c1(see example)
> + and so on.
Please provide the real property name to use. No need for an example
here, you have a full-fledged one in a few lines.
> +- clocks requires the reference at the ahb clock gate
> + with the correct index (mmc0 -> 8, mmc1 -> 9, and so on)
> + as well as the reference to the correct mod0 clock.
Ditto. Plus, this is not a mod0 clock.
> +- interrupts requires the correct IRQ line
> + (mmc0 -> 32, mmc1 -> 33, and so on)
Ditto.
> +
> +Examples:
> +
> +mmc0: mmc@01c0f000 {
> + compatible = "allwinner,sun5i-a13-mmc";
> + reg = <0x01c0f000 0x1000>;
> + clocks = <&ahb_gates 8>, <&mmc0_clk>;
> + clock-names = "ahb", "mod";
You never talked about the clock-names property, and which clocks were
supposed to be provided.
> + interrupts = <0 32 4>;
> + bus-width = <4>;
And you never talked about bus-width either.
> + status = "disabled";
> +};
>
Isn't the cd-gpios property requested too?
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH] ARM: sun7i: add arch timer node
On Tue, Feb 18, 2014 at 02:04:44PM +, Marc Zyngier wrote: > The Allwinner A20 SoC is built around a pair of Cortex-A7 cores, > which have the usual generic timers. Report this in the DT. > > Signed-off-by: Marc Zyngier Applied, thanks! -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v4 0/5] clk: sunxi usb clks support
Hi, On Tue, Feb 18, 2014 at 11:42:43AM -0300, Emilio López wrote: > >Maxime, can you please add patches 3-5 to your dts tree ? Assuming that > >wens clk rename patches are already there. > > Maxime, please do :) Done. Thanks! -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH v7 4/8] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
Ühel kenal päeval, E, 17.02.2014 kell 11:02, kirjutas David Lanzendörfer: > This is based on the driver Allwinner ships in their Android kernel sources. > ... > diff --git a/drivers/mmc/host/sunxi-mmc.h b/drivers/mmc/host/sunxi-mmc.h > new file mode 100644 > index 000..75eaa02 > --- /dev/null > +++ b/drivers/mmc/host/sunxi-mmc.h > @@ -0,0 +1,239 @@ ... > +#define SDXC_RXWL_FLAG BIT(0) > +#define SDXC_TXWL_FLAG BIT(1) > +#define SDXC_FIFO_EMPTY BIT(2) > +#define SDXC_FIFO_FULL BIT(3) > +#define SDXC_CARD_PRESENTBIT(8) > +#define SDXC_CARD_DATA_BUSY BIT(9) > +#define SDXC_DATA_FSM_BUSY BIT(10) > +#define SDXC_DMA_REQUEST BIT(31) > +#define SDXC_FIFO_SIZE (16) > +/* Function select */ > +#define SDXC_CEATA_ON(0xceaaU << 16) That 0xceaa magic looks bad, but I assume it came from original code? > +#define SDXC_SEND_IRQ_RESPONSE BIT(0) > +#define SDXC_SDIO_READ_WAIT BIT(1) > +#define SDXC_ABORT_READ_DATA BIT(2) > +#define SDXC_SEND_CCSD BIT(8) > +#define SDXC_SEND_AUTO_STOPCCSD BIT(9) > +#define SDXC_CEATA_DEV_INTERRUPT_ENABLE_BIT BIT(10) > +/* IDMA controller bus mod bit field */ > +#define SDXC_IDMAC_SOFT_RESETBIT(0) > +#define SDXC_IDMAC_FIX_BURST BIT(1) > +#define SDXC_IDMAC_IDMA_ON BIT(7) > +#define SDXC_IDMAC_REFETCH_DES BIT(31) > +/* IDMA status bit field */ > +#define SDXC_IDMAC_TRANSMIT_INTERRUPTBIT(0) > +#define SDXC_IDMAC_RECEIVE_INTERRUPT BIT(1) > +#define SDXC_IDMAC_FATAL_BUS_ERROR BIT(2) > +#define SDXC_IDMAC_DESTINATION_INVALID BIT(4) > +#define SDXC_IDMAC_CARD_ERROR_SUMBIT(5) > +#define SDXC_IDMAC_NORMAL_INTERRUPT_SUM BIT(8) > +#define SDXC_IDMAC_ABNORMAL_INTERRUPT_SUM BIT(9) > +#define SDXC_IDMAC_HOST_ABORT_INTERRUPT_TX BIT(10) > +#define SDXC_IDMAC_HOST_ABORT_INTERRUPT_RX BIT(10) That duplicate BIT(10) looks fishy. Päikest, Priit Laes :) -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Purchasing AllWinner chips
Hi, Does anyone know of a reliable supplier who sells the AllWinner A20 chips? I was hoping to find them on digikey, mouser or avnet, but it appears that they're a little bit hard to find. I see that Olimex will sell them in low volumes, but I was hoping for a better known supplier (and higher quantities). I know this is a Linux forum, but I'm not 100% sure who to ask, so I was hoping someone here might have already looked into this. Regards, Andre -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Purchasing AllWinner chips
On Tue, Feb 18, 2014 at 3:09 PM, Andre Renaud wrote: > Hi, > Does anyone know of a reliable supplier who sells the AllWinner A20 > chips? I was hoping to find them on digikey, mouser or avnet, but it > appears that they're a little bit hard to find. I see that Olimex will > sell them in low volumes, but I was hoping for a better known supplier > (and higher quantities). Allwinner is talking with the big distributors currently but AFAIK no deal has been reached yet. Many people have designed their own board locally using a few chips from Olimex. Then when you want to make a larger quantity have them assembled in Shenzhen. The Allwinner chips are plentiful in Shenzhen. Instead of buying chips you might want to consider standard Q88 tablet PCBAs. A20 tablet PCBAs can be bought in the $20-30 range in Shenzhen. An easy way to get a hold of them is to buy Q88 tablets and disassemble them. These PCBA are made by many companies and the price is highly competitive. It is also possible to buy STB PCBAs. Another option is to have a Chinese design house make one for you. For about $5000 they will design whatever you want and provide about ten prototype boards. These designs are easy to put into production since they will use local components. Around $40/board for medium volume but this depends on what you put on the board. Reusing Q88 PCBAs is by far the easiest solution. You can mount one in a case and then use an internal USB cable to talk to your specialized hardware if needed. > > I know this is a Linux forum, but I'm not 100% sure who to ask, so I > was hoping someone here might have already looked into this. > > Regards, > Andre > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v7 4/8] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
Hi,
On 02/18/2014 04:37 PM, Maxime Ripard wrote:
+
+ for (i = 0; i < data->sg_len; i++) {
+ pdes[i].config = SDXC_IDMAC_DES0_CH | SDXC_IDMAC_DES0_OWN |
+SDXC_IDMAC_DES0_DIC;
+
+ if (data->sg[i].length == max_len)
+ pdes[i].buf_size = 0; /* 0 == max_len */
+ else
+ pdes[i].buf_size = data->sg[i].length;
+
+ pdes[i].buf_addr_ptr1 = sg_dma_address(&data->sg[i]);
+ pdes[i].buf_addr_ptr2 = (u32)&pdes_pa[i + 1];
+ }
+
+ pdes[0].config |= SDXC_IDMAC_DES0_FD;
+ pdes[i - 1].config = SDXC_IDMAC_DES0_OWN | SDXC_IDMAC_DES0_LD;
+
+ wmb(); /* Ensure idma_des hit main mem before we start the idmac */
wmb ensure the proper ordering of the instructions, not flushing the
caches like what your comment implies.
Since I put that comment there, allow me to explain. A modern ARM
cpu core has 2 or more units handling stores. One for regular
memory stores, and one for io-mem stores. Regular mem stores can
be re-ordered, io stores cannot. Normally there is no "syncing"
between the 2 store units. Cache flushing is not an issue here
since the memory holding the descriptors for the idma controller
is allocated cache coherent, which on arm means it is not cached.
What is an issue here is the io-store starting the idmac hitting
the io-mem before the descriptors hit the main-mem, the wmb()
ensures this does not happen.
+static int sunxi_mmc_prepare_dma(struct sunxi_mmc_host *smc_host,
+struct mmc_data *data)
+{
+ u32 dma_len;
+ u32 i;
+ u32 temp;
+ struct scatterlist *sg;
+
+ dma_len = dma_map_sg(mmc_dev(smc_host->mmc), data->sg, data->sg_len,
+sunxi_mmc_get_dma_dir(data));
+ if (dma_len == 0) {
+ dev_err(mmc_dev(smc_host->mmc), "dma_map_sg failed\n");
+ return -ENOMEM;
+ }
+
+ for_each_sg(data->sg, sg, data->sg_len, i) {
+ if (sg->offset & 3 || sg->length & 3) {
+ dev_err(mmc_dev(smc_host->mmc),
+ "unaligned scatterlist: os %x length %d\n",
+ sg->offset, sg->length);
+ return -EINVAL;
+ }
+ }
+
+ sunxi_mmc_init_idma_des(smc_host, data);
+
+ temp = mci_readl(smc_host, REG_GCTRL);
+ temp |= SDXC_DMA_ENABLE_BIT;
+ mci_writel(smc_host, REG_GCTRL, temp);
+ temp |= SDXC_DMA_RESET;
+ mci_writel(smc_host, REG_GCTRL, temp);
Does it really need to be done in two steps?
We don't know, so this is probably best left as is.
(Newline)
+ mci_writel(smc_host, REG_DMAC, SDXC_IDMAC_SOFT_RESET);
+
+ if (!(data->flags & MMC_DATA_WRITE))
+ mci_writel(smc_host, REG_IDIE, SDXC_IDMAC_RECEIVE_INTERRUPT);
+
+ mci_writel(smc_host, REG_DMAC, SDXC_IDMAC_FIX_BURST |
SDXC_IDMAC_IDMA_ON);
+
+ return 0;
+}
+
+static void sunxi_mmc_send_manual_stop(struct sunxi_mmc_host *host,
+ struct mmc_request *req)
+{
+ u32 cmd_val = SDXC_START | SDXC_RESP_EXPIRE | SDXC_STOP_ABORT_CMD
+ | SDXC_CHECK_RESPONSE_CRC | MMC_STOP_TRANSMISSION;
+ u32 ri = 0;
+ unsigned long expire = jiffies + msecs_to_jiffies(1000);
+
+ mci_writel(host, REG_CARG, 0);
+ mci_writel(host, REG_CMDR, cmd_val);
+
+ do {
+ ri = mci_readl(host, REG_RINTR);
+ } while (!(ri & (SDXC_COMMAND_DONE | SDXC_INTERRUPT_ERROR_BIT)) &&
+time_before(jiffies, expire));
+
+ if (ri & SDXC_INTERRUPT_ERROR_BIT) {
+ dev_err(mmc_dev(host->mmc), "send stop command failed\n");
+ if (req->stop)
+ req->stop->resp[0] = -ETIMEDOUT;
+ } else {
+ if (req->stop)
+ req->stop->resp[0] = mci_readl(host, REG_RESP0);
+ }
+
+ mci_writel(host, REG_RINTR, 0x);
+}
+
+static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host *smc_host)
+{
+ struct mmc_command *cmd = smc_host->mrq->cmd;
+ struct mmc_data *data = smc_host->mrq->data;
+
+ /* For some cmds timeout is normal with sd/mmc cards */
+ if ((smc_host->int_sum & SDXC_INTERRUPT_ERROR_BIT) == SDXC_RESP_TIMEOUT
&&
+ (cmd->opcode == SD_IO_SEND_OP_COND || cmd->opcode ==
SD_IO_RW_DIRECT))
+ return;
+
+ dev_err(mmc_dev(smc_host->mmc),
I'd rather put it at a debug loglevel.
Erm, this only happens if something is seriously wrong.
+ /* Make sure the controller is in a sane state before enabling irqs */
+ ret = sunxi_mmc_init_host(host->mmc);
+ if (ret)
+ return ret;
+
+ host->irq = platform_get_irq(pdev, 0);
+ ret = devm_request_irq(&pdev->dev, host->irq, sunxi_mmc_irq, 0,
+ "sunxi-mmc
[linux-sunxi] [PATCH] sun7i_deconfig add config option for an usable kernel I add Nand,emac,ir,gpio,mmc option
Signed-off-by: Gerardo Di Iorio --- arch/arm/configs/sun7i_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/configs/sun7i_defconfig b/arch/arm/configs/sun7i_defconfig index 44f9bf4..3de48e4 100644 --- a/arch/arm/configs/sun7i_defconfig +++ b/arch/arm/configs/sun7i_defconfig @@ -436,6 +436,7 @@ CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=2 CONFIG_CDROM_PKTCDVD=m CONFIG_ATA_OVER_ETH=m +CONFIG_SUNXI_NAND=m CONFIG_SUNXI_DBGREG=m CONFIG_TI_DAC7512=m CONFIG_EEPROM_AT24=m @@ -458,6 +459,9 @@ CONFIG_ATA=y # CONFIG_SATA_PMP is not set CONFIG_SW_SATA_AHCI_PLATFORM=y # CONFIG_ATA_SFF is not set +CONFIG_NETDEVICES=y +CONFIG_SUNXI_EMAC=y +CONFIG_PHYLIB=y CONFIG_MD=y CONFIG_BLK_DEV_DM=y CONFIG_DM_DEBUG=y @@ -586,6 +590,7 @@ CONFIG_INPUT_KEYRESET=y CONFIG_KEYBOARD_SUN4IKEYPAD=m CONFIG_KEYBOARD_SUN4I_KEYBOARD=m CONFIG_KEYBOARD_HV2605_KEYBOARD=y +CONFIG_IR_SUNXI=m # CONFIG_MOUSE_PS2 is not set CONFIG_MOUSE_SYNAPTICS_USB=m CONFIG_INPUT_JOYSTICK=y @@ -691,7 +696,9 @@ CONFIG_PPS=m CONFIG_PTP_1588_CLOCK=m CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_SUNXI=m CONFIG_W1=m +CONFIG_W1_SUNXI=m CONFIG_W1_MASTER_GPIO=m CONFIG_POWER_SUPPLY=y CONFIG_AW_AXP=y @@ -1057,6 +1064,7 @@ CONFIG_MMC_PARANOID_SD_INIT=y CONFIG_SDIO_UART=m CONFIG_MMC_USHC=m CONFIG_MMC_SUNXI_POWER_CONTROL=y +CONFIG_MMC_SUNXI=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y -- 1.8.4.2 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v4 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
Quoting Chen-Yu Tsai (2014-02-10 02:35:47)
> The Allwinner A20/A31 clock module controls the transmit clock source
> and interface type of the GMAC ethernet controller. Model this as
> a single clock for GMAC drivers to use.
>
> Signed-off-by: Chen-Yu Tsai
Looks good to me.
Regards,
Mike
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 30 +++
> drivers/clk/sunxi/clk-sunxi.c | 97
> +++
> 2 files changed, 127 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 0cf679b..28421d2 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -37,6 +37,7 @@ Required properties:
> "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
> "allwinner,sun7i-a20-out-clk" - for the external output clocks
> + "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
>
> Required properties for all clocks:
> - reg : shall be the control register address for the clock.
> @@ -50,6 +51,9 @@ Required properties for all clocks:
> If the clock module only has one output, the name shall be the
> module name.
>
> +For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
> +dummy clocks at 25 MHz and 125 MHz, respectively. See example.
> +
> Clock consumers should specify the desired clocks they use with a
> "clocks" phandle cell. Consumers that are using a gated clock should
> provide an additional ID in their clock property. This ID is the
> @@ -96,3 +100,29 @@ mmc0_clk: clk@01c20088 {
> clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> clock-output-names = "mmc0";
> };
> +
> +mii_phy_tx_clk: clk@2 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2500>;
> + clock-output-names = "mii_phy_tx";
> +};
> +
> +gmac_int_tx_clk: clk@3 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "gmac_int_tx";
> +};
> +
> +gmac_clk: clk@01c20164 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun7i-a20-gmac-clk";
> + reg = <0x01c20164 0x4>;
> + /*
> +* The first clock must be fixed at 25MHz;
> +* the second clock must be fixed at 125MHz
> +*/
> + clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
> + clock-output-names = "gmac";
> +};
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 736fb60..da1d5cc 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -379,6 +379,103 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32
> parent_rate,
>
>
> /**
> + * sun7i_a20_gmac_clk_setup - Setup function for A20/A31 GMAC clock module
> + *
> + * This clock looks something like this
> + *
> + * MII TX clock from PHY >-|____|> to GMAC core
> + * GMAC Int. RGMII TX clk >|___\__/__gate---|> to PHY
> + * Ext. 125MHz RGMII TX clk >--|__divider__/|
> + * ||
> + *
> + * The external 125 MHz reference is optional, i.e. GMAC can use its
> + * internal TX clock just fine. The A31 GMAC clock module does not have
> + * the divider controls for the external reference.
> + *
> + * To keep it simple, let the GMAC use either the MII TX clock for MII mode,
> + * and its internal TX clock for GMII and RGMII modes. The GMAC driver should
> + * select the appropriate source and gate/ungate the output to the PHY.
> + *
> + * Only the GMAC should use this clock. Altering the clock so that it doesn't
> + * match the GMAC's operation parameters will result in the GMAC not being
> + * able to send traffic out. The GMAC driver should set the clock rate and
> + * enable/disable this clock to configure the required state. The clock
> + * driver then responds by auto-reparenting the clock.
> + */
> +
> +#define SUN7I_A20_GMAC_GPIT2
> +#define SUN7I_A20_GMAC_MASK0x3
> +#define SUN7I_A20_GMAC_PARENTS 2
> +
> +static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
> +{
> + struct clk *clk;
> + struct clk_mux *mux;
> + struct clk_gate *gate;
> + const char *clk_name = node->name;
> + const char *parents[SUN7I_A20_GMAC_PARENTS];
> + void *reg;
> + int i = 0;
> +
> + if (of_property_read_string(node, "clock-output-names", &clk_name))
> + return;
> +
> + /* allocate mux and gate clock structs */
> + mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
> + if (!mux)
> + return;
> +
> + gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
> +
