[linux-sunxi] [PATCH] sunxi: Add HSG H702
This is an A13 based Q8 format tablet with 512 MB of DRAM. Signed-off-by: Chen-Yu Tsai --- Note this just uses one of the generic dram configurations, that is, without the zq parameters. --- board/sunxi/Makefile | 1 + boards.cfg | 1 + 2 files changed, 2 insertions(+) diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile index 4166a9b..4eb3556 100644 --- a/board/sunxi/Makefile +++ b/board/sunxi/Makefile @@ -44,6 +44,7 @@ obj-$(CONFIG_H6) += dram_h6.o obj-$(CONFIG_HACKBERRY)+= dram_hackberry.o obj-$(CONFIG_HBD_MID_S906) += dram_sun7i_432_1024_iow16.o obj-$(CONFIG_HCORE_HC860) += dram_sun4i_384_1024_iow16.o +obj-$(CONFIG_HSG_H702) += dram_sun5i_432_512_busw16_iow16.o obj-$(CONFIG_HYUNDAI_A7) += dram_sun4i_360_512.o obj-$(CONFIG_A7HD) += dram_sun4i_360_1024_iow8.o obj-$(CONFIG_I12_TVBOX)+= dram_sun7i_384_1024_iow16.o diff --git a/boards.cfg b/boards.cfg index f364fb9..d6ba4e8 100644 --- a/boards.cfg +++ b/boards.cfg @@ -418,6 +418,7 @@ Active arm armv7 sunxi - sunxi Active arm armv7 sunxi - sunxi Hackberry sun4i:HACKBERRY,SPL,SUNXI_EMAC,MACPWR=SUNXI_GPH(19) - Active arm armv7 sunxi - sunxi HBD_MID_S906 sun7i:HBD_MID_S906,SPL - Active arm armv7 sunxi - sunxi HCore_HC860 sun4i:HCORE_HC860,SPL - +Active arm armv7 sunxi - sunxi HSG_H702 sun5i:HSG_H702,SPL,CONS_INDEX=2 - Active arm armv7 sunxi - sunxi Hyundai_A7 sun4i:HYUNDAI_A7,SPL - Active arm armv7 sunxi - sunxi Hyundai_A7HD sun4i:A7HD,SPL - Active arm armv7 sunxi - sunxi i12-tvbox sun7i:I12_TVBOX,SPL,FAST_MBUS,STATUSLED=244 - -- 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 v3] ARM: sun5i: Add DT for HSG H702 tablet board
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
---
Note that checkpatch.pl is not happy about having the FSF address in
the file. Given that the dts files are intended to be redistributable
independent of the kernel, I think this error can be ignored.
Changes since v2:
- Dual license under GPL/X11.
- Use extra fixed regulator for usb1-vbus.
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun5i-a13-hsg-h702.dts | 138 +++
2 files changed, 139 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..68c78e2
--- /dev/null
+++ b/arch/arm/boot/dts/sun5i-a13-hsg-h702.dts
@@ -0,0 +1,138 @@
+/*
+ * Copyright 2014 Chen-Yu Tsai
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library 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.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/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_h702>;
+ 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>;
+
Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33
On Thu, Sep 11, 2014 at 10:24:04AM +1000, Julian Calaby wrote: > On Wed, Sep 10, 2014 at 5:10 PM, Maxime Ripard > wrote: > > On Tue, Sep 09, 2014 at 02:29:23PM +0200, Luc Verhaegen wrote: > >> On Tue, Sep 09, 2014 at 12:05:54PM +0200, Maxime Ripard wrote: > >> > On Mon, Sep 08, 2014 at 06:01:25PM +0200, Luc Verhaegen wrote: > >> > > It was a consistent scheme, which allwinner followed for many many > >> > > years. > >> > > >> > No, it was not. If it was to be a purely time-driven naming scheme, > >> > A10s should have been sun6i. > >> > >> See below. It was consistent. > >> > >> > > A10s is A13. > >> > > >> > [citation needed] > >> > >> Why else does allwinner call them both sun5i? Why else does A13 have a > >> fully working hdmi block sitting there? > >> > >> Citation: my uboot cfbconsole code where i successfully use HPD > >> detection on A13. This fails nicely, as no hpd pin is exported outside > >> of the chip, and it is never raised to 5V. > >> > >> But please go ask our Allwinner contacts or Tom Cubie or something. > > > > The fact that the internals of the SoC are alike or even the same > > doesn't matter much. What really matters is really what is exposed to > > the user, ie what is routed to the externals pins. And from that point > > of view, they're just "similar", but the fact that the HDMI, EMAC, > > GPS, etc. are not at least usable in the A13 makes it a different SoC. > > > >> > > 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. > >> > > >> > Yeah, right. So it's chronological, but we have no way to tell, except > >> > by fully trusting you. The argument of (which?) authority is not > >> > really something that usually convince me. > >> > >> It is pretty logical. A31 was named sun6i, A20 was named sun7i. A31 was > >> a major redesign. A20 was throwing 2 A7s and a second fragment shader, > >> and some minor fixes onto A10. The latter was either a stopgap, or a > >> deliberate market decision, it at least took a lot less time to > >> complete. Hence them both arriving at the same time. > >> > >> Again, the above is the best logical explanation for events. > > > > Ok. > > > >> > > 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. > >> > > >> > It is. You can find some reference to A31 being sun6i, and A20 being > >> > sun7i. Can you find any reference to A33 being sun10i? > >> > >> You did find A31 and A20 as sun6i and sun7i when Allwinner was still on > >> a relatively sane naming scheme. You cannot find these references > >> anymore on anything allwinner produces today. > >> > >> So either you go allwinner, or you don't. > > > > Probably, but we still have to find a consistent naming. Sticking with > > sun6i and sun7i is somewhat consistent with both ourselves and > > Allwinner. sun10i is just made out of nowhere, as a hack because you > > don't really like the new naming scheme. > > > >> > > 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. > >> > > >> > I guess it could fit into both sun8i and sun9i. But A83 isn't really > >> > the topic here, is it? > >> > >> But it is. Or it very much will be, in about 6 months time. > > > > Ok, let's consider it then. I guess we have four options: > > - It's made part of sun8i by Allwinner > > - It's made part of sun9i by Allwinner > > - It's made sun10i by Allwinner > > - It's made something completely different and crazy. > > > > By introducing sun11i like you suggest, you're making it inconsistent > > with all of these options. > > > > While my proposal doesn't conflict with any of them. > > Why not just use the name(s) they were given at release? > > And if there are conflicts, either use the "sunXiwYpZ" format or > append it with the "A" number or both? > > - So the A10 stays as "sun4i" > > - If they release some A19 part which is a souped up A10 with fancy > stuff and want to call it "sun4i" or "sun4iw3p9" we use the latter. > > - If they re-release the A10 with minor changes, change it's chip ID > and call it the A11 - but insist on keeping the code name as "sun4i" > only, we call it "sun4i_A11". > > No conflicts, no retroactive code changes, minimal confusion. What we've been doing with mainline is that we're using -. Family being here as the "first" family we encountered it (mostly because we only knew it by that name at the time when we added support). So we end up with sun6i-a31, sun7i-a20, sun8i-a23, and will have sun8i-a33. This pattern ha
Re: [linux-sunxi] [PATCH 1/4] meminfo: use correct sunXi naming for a80 an a33
Hi All, On Thu, Sep 11, 2014 at 6:16 PM, Maxime Ripard wrote: > On Thu, Sep 11, 2014 at 10:24:04AM +1000, Julian Calaby wrote: >> On Wed, Sep 10, 2014 at 5:10 PM, Maxime Ripard >> wrote: >> > On Tue, Sep 09, 2014 at 02:29:23PM +0200, Luc Verhaegen wrote: >> >> On Tue, Sep 09, 2014 at 12:05:54PM +0200, Maxime Ripard wrote: >> >> > On Mon, Sep 08, 2014 at 06:01:25PM +0200, Luc Verhaegen wrote: >> >> > > It was a consistent scheme, which allwinner followed for many many >> >> > > years. >> >> > >> >> > No, it was not. If it was to be a purely time-driven naming scheme, >> >> > A10s should have been sun6i. >> >> >> >> See below. It was consistent. >> >> >> >> > > A10s is A13. >> >> > >> >> > [citation needed] >> >> >> >> Why else does allwinner call them both sun5i? Why else does A13 have a >> >> fully working hdmi block sitting there? >> >> >> >> Citation: my uboot cfbconsole code where i successfully use HPD >> >> detection on A13. This fails nicely, as no hpd pin is exported outside >> >> of the chip, and it is never raised to 5V. >> >> >> >> But please go ask our Allwinner contacts or Tom Cubie or something. >> > >> > The fact that the internals of the SoC are alike or even the same >> > doesn't matter much. What really matters is really what is exposed to >> > the user, ie what is routed to the externals pins. And from that point >> > of view, they're just "similar", but the fact that the HDMI, EMAC, >> > GPS, etc. are not at least usable in the A13 makes it a different SoC. >> > >> >> > > 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. >> >> > >> >> > Yeah, right. So it's chronological, but we have no way to tell, except >> >> > by fully trusting you. The argument of (which?) authority is not >> >> > really something that usually convince me. >> >> >> >> It is pretty logical. A31 was named sun6i, A20 was named sun7i. A31 was >> >> a major redesign. A20 was throwing 2 A7s and a second fragment shader, >> >> and some minor fixes onto A10. The latter was either a stopgap, or a >> >> deliberate market decision, it at least took a lot less time to >> >> complete. Hence them both arriving at the same time. >> >> >> >> Again, the above is the best logical explanation for events. >> > >> > Ok. >> > >> >> > > 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. >> >> > >> >> > It is. You can find some reference to A31 being sun6i, and A20 being >> >> > sun7i. Can you find any reference to A33 being sun10i? >> >> >> >> You did find A31 and A20 as sun6i and sun7i when Allwinner was still on >> >> a relatively sane naming scheme. You cannot find these references >> >> anymore on anything allwinner produces today. >> >> >> >> So either you go allwinner, or you don't. >> > >> > Probably, but we still have to find a consistent naming. Sticking with >> > sun6i and sun7i is somewhat consistent with both ourselves and >> > Allwinner. sun10i is just made out of nowhere, as a hack because you >> > don't really like the new naming scheme. >> > >> >> > > 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. >> >> > >> >> > I guess it could fit into both sun8i and sun9i. But A83 isn't really >> >> > the topic here, is it? >> >> >> >> But it is. Or it very much will be, in about 6 months time. >> > >> > Ok, let's consider it then. I guess we have four options: >> > - It's made part of sun8i by Allwinner >> > - It's made part of sun9i by Allwinner >> > - It's made sun10i by Allwinner >> > - It's made something completely different and crazy. >> > >> > By introducing sun11i like you suggest, you're making it inconsistent >> > with all of these options. >> > >> > While my proposal doesn't conflict with any of them. >> >> Why not just use the name(s) they were given at release? >> >> And if there are conflicts, either use the "sunXiwYpZ" format or >> append it with the "A" number or both? >> >> - So the A10 stays as "sun4i" >> >> - If they release some A19 part which is a souped up A10 with fancy >> stuff and want to call it "sun4i" or "sun4iw3p9" we use the latter. >> >> - If they re-release the A10 with minor changes, change it's chip ID >> and call it the A11 - but insist on keeping the code name as "sun4i" >> only, we call it "sun4i_A11". >> >> No conflicts, no retroactive code changes, minimal confusion. > > What we've been doing with mainline is that we're using > -. Family being here as the "first" family we encou
[linux-sunxi] Re: encode video stream to h264 via CedarX VPU !?
Thanks for this information. What I have to do to get this working on a BananaPi? How I undertstand.. 1. installing cedrus like here http://linux-sunxi.org/Cedrus#CedarX_module 2. installing ffmpeg from the forum thread ? Is that correct? Am Donnerstag, 11. September 2014 01:00:28 UTC+2 schrieb ditma...@gmail.com: > > and look here > Re: ffmpeg H264 encoding with cedrus (Cedarx, Transcoding, Allwinner A20, > Mediatomb) > http://www.cubieforums.com/index.php?topic=2810.msg19772;topicseen#msg19772 -- 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
On 11 September 2014 10:16, Maxime Ripard wrote: > On Thu, Sep 11, 2014 at 10:24:04AM +1000, Julian Calaby wrote: >> On Wed, Sep 10, 2014 at 5:10 PM, Maxime Ripard >> wrote: >> > On Tue, Sep 09, 2014 at 02:29:23PM +0200, Luc Verhaegen wrote: >> >> On Tue, Sep 09, 2014 at 12:05:54PM +0200, Maxime Ripard wrote: >> >> > On Mon, Sep 08, 2014 at 06:01:25PM +0200, Luc Verhaegen wrote: >> >> > > It was a consistent scheme, which allwinner followed for many many >> >> > > years. >> >> > >> >> > No, it was not. If it was to be a purely time-driven naming scheme, >> >> > A10s should have been sun6i. >> >> >> >> See below. It was consistent. >> >> >> >> > > A10s is A13. >> >> > >> >> > [citation needed] >> >> >> >> Why else does allwinner call them both sun5i? Why else does A13 have a >> >> fully working hdmi block sitting there? >> >> >> >> Citation: my uboot cfbconsole code where i successfully use HPD >> >> detection on A13. This fails nicely, as no hpd pin is exported outside >> >> of the chip, and it is never raised to 5V. >> >> >> >> But please go ask our Allwinner contacts or Tom Cubie or something. >> > >> > The fact that the internals of the SoC are alike or even the same >> > doesn't matter much. What really matters is really what is exposed to >> > the user, ie what is routed to the externals pins. And from that point >> > of view, they're just "similar", but the fact that the HDMI, EMAC, >> > GPS, etc. are not at least usable in the A13 makes it a different SoC. >> > >> >> > > 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. >> >> > >> >> > Yeah, right. So it's chronological, but we have no way to tell, except >> >> > by fully trusting you. The argument of (which?) authority is not >> >> > really something that usually convince me. >> >> >> >> It is pretty logical. A31 was named sun6i, A20 was named sun7i. A31 was >> >> a major redesign. A20 was throwing 2 A7s and a second fragment shader, >> >> and some minor fixes onto A10. The latter was either a stopgap, or a >> >> deliberate market decision, it at least took a lot less time to >> >> complete. Hence them both arriving at the same time. >> >> >> >> Again, the above is the best logical explanation for events. >> > >> > Ok. >> > >> >> > > 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. >> >> > >> >> > It is. You can find some reference to A31 being sun6i, and A20 being >> >> > sun7i. Can you find any reference to A33 being sun10i? >> >> >> >> You did find A31 and A20 as sun6i and sun7i when Allwinner was still on >> >> a relatively sane naming scheme. You cannot find these references >> >> anymore on anything allwinner produces today. >> >> >> >> So either you go allwinner, or you don't. >> > >> > Probably, but we still have to find a consistent naming. Sticking with >> > sun6i and sun7i is somewhat consistent with both ourselves and >> > Allwinner. sun10i is just made out of nowhere, as a hack because you >> > don't really like the new naming scheme. >> > >> >> > > 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. >> >> > >> >> > I guess it could fit into both sun8i and sun9i. But A83 isn't really >> >> > the topic here, is it? >> >> >> >> But it is. Or it very much will be, in about 6 months time. >> > >> > Ok, let's consider it then. I guess we have four options: >> > - It's made part of sun8i by Allwinner >> > - It's made part of sun9i by Allwinner >> > - It's made sun10i by Allwinner >> > - It's made something completely different and crazy. >> > >> > By introducing sun11i like you suggest, you're making it inconsistent >> > with all of these options. >> > >> > While my proposal doesn't conflict with any of them. >> >> Why not just use the name(s) they were given at release? >> >> And if there are conflicts, either use the "sunXiwYpZ" format or >> append it with the "A" number or both? >> >> - So the A10 stays as "sun4i" >> >> - If they release some A19 part which is a souped up A10 with fancy >> stuff and want to call it "sun4i" or "sun4iw3p9" we use the latter. >> >> - If they re-release the A10 with minor changes, change it's chip ID >> and call it the A11 - but insist on keeping the code name as "sun4i" >> only, we call it "sun4i_A11". >> >> No conflicts, no retroactive code changes, minimal confusion. > > What we've been doing with mainline is that we're using > -. Family being here as the "first" family we encountered > it (m
[linux-sunxi] Re: encode video stream to h264 via CedarX VPU !?
I dont know. Haven`t done this. You need a player or streaming client that is compiled for cedarx usage. -- 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: encode video stream to h264 via CedarX VPU !?
No, didn't really want to play that video on BananaPi, I want to stream it forward to a WiFi device. The BananaPi should "only" transcode the stream. :-) So, ffmpeg would be nice, then I can incoming stream transcode to h264 codec. Am Donnerstag, 11. September 2014 12:32:33 UTC+2 schrieb ditma...@gmail.com: > > I dont know. Haven`t done this. You need a player or streaming client that > is compiled for cedarx usage. -- 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: encode video stream to h264 via CedarX VPU !?
I think it is impissible to run decoder and encoder at the same time because it uses same memory regions. But you can try to write converter you need. Decoder and encoder uses same libraries. Try look at the sample codes and encode each frame after encoding. Other way is decoding some count of frames to buffer, deinit eecoder, init encoder and encode it in cycle. -- 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] sunxi: Add HSG H702
On Thu, Sep 11, 2014 at 03:40:32PM +0800, Chen-Yu Tsai wrote: > This is an A13 based Q8 format tablet with 512 MB of DRAM. > > Signed-off-by: Chen-Yu Tsai > --- > > Note this just uses one of the generic dram configurations, > that is, without the zq parameters. > > --- > board/sunxi/Makefile | 1 + > boards.cfg | 1 + > 2 files changed, 2 insertions(+) Pushed. 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: encode video stream to h264 via CedarX VPU !?
I have a raw byte image stream, that means, I can feed the encoder with raw jpeg files. And this tream, I want to transcode into h264 codec via GPU. This guy, is doing that via ffmpeg. The only diffeerence I want to do is, to write it not to a file, I will write the output to gstreamer. And gstreamer should only be a "rtsp" server, and managing the overlay. Am Donnerstag, 11. September 2014 13:23:59 UTC+2 schrieb Toroshin Dmitry: > > I think it is impissible to run decoder and encoder at the same time > because it uses same memory regions. > But you can try to write converter you need. Decoder and encoder uses same > libraries. Try look at the sample codes and encode each frame after > encoding. > Other way is decoding some count of frames to buffer, deinit eecoder, init > encoder and encode it in cycle. -- 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: Running Linux on a Jesurun A19 Android media player
Thanks for your reply. You've given me some genuinely useful information. If all I need to do is edit the fex file in some way to get wired networking working then it might be worth persevering. I should point out however, that I've already tried the script.bin file that came with the stock Android image. Anyway, I'll upload the fex file and the u-boot batches this weekend, assuming of course that Luc hasn't locked my account by that time. Regards, Jason On Wednesday, September 10, 2014 10:31:30 PM UTC+1, Stefan Monnier wrote: > > > I had another go at this over the weekend and made some progress. > > I managed to extract the DRAM configuration parameters from the board > and > > used them to compile a new version of u-boot for my device. > > Great. Now try to get the script.bin file from flash (while booted in > Android). It should be in the /dev/block/nanda device. > > > Firstly, I'm not sure what networking chipsets are build into my device. > > The Ethernet is built into the SoC, so there's not much to discover on > this front. The wifi is separate, so it can vary. To figure out which > you have, you can look for the info in "dmesg", or you can look at the > chips on the motherboard. > > > I've found the manufacturer of my device (www.rshtech.cn) but there are > no > > specs on their website. Is there some command I can run within Linux to > > find out what chipsets are being used? > > "dmesg" often includes that somewhere. > > > Assuming I can get this information, would someone here be able to tell > me > > what compiler parameters I'll need to set to create a suitable kernel > > image? > > Usually you don't need any special kernel parameters: just use > a run-of-the-mill image for Allwinner. The only thing you need is to > script.fex/script.bin file (which you extracted above). > > > Oh, and to preempt one possible response from a certain person here, > I've > > already read the "New Device Howto". In fact I've read it repeatedly, > and > > attempted to follow it to the letter. However, it glosses over the above > > points. > > If you can point to specific parts of the NDH you don't understand, that > would help. Better yet, after you figured it out, you can fix the > NDH to make it more understandable. > > > 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: Running Linux on a Jesurun A19 Android media player
Right. So your response is to make the message even more aggressive and obnoxious. You just don't get it do you. I've been following this forum for several weeks now, and I have to say the traffic is minimal. All I ever seem to see is patch submissions, and an occasional debate about GPL compliance. And almost every question (not just mine) is either ignored or met with a pointless RTFM style response. This is hardly what I would describe as a "very active and advanced" community. If you're happy with this state of affairs then feel free to continue as you are. But if you want this community to thrive then it needs to attract new members, and that's only going to happen if you become more welcoming. You keep banging on about how people like me are wasting your precious time. But it cuts both ways. No one is under any obligation to participate in this community. For most people, this is just a silly hobby. No one really needs Linux to run on their cheap throwaway Android devices, that will be obsolete in a year anyway. I can assure you that 99% of people reading through your wiki will be massively put off by the aggressive tone, and the crazy hoops they're expected to jump through, and just walk away. Seriously, who needs the aggro. Life's too short. Frankly, I don't think you're an appropriate person to be administering the wiki. You clearly lack the tact and social skills to do the job in a professional way. Has it ever occured to you that maybe, just maybe, your attitude is at least part of the reason why Allwinner is reluctant to engage with this community? On Wednesday, September 10, 2014 10:51:24 PM UTC+1, Luc Verhaegen wrote: > > On Wed, Sep 10, 2014 at 11:23:46PM +0200, Luc Verhaegen wrote: > > I have now spelled this out at the top of our NDH as well: > > > http://linux-sunxi.org/New_Device_howto#.22Why_do_people_keep_on_telling_me_to_NDH_while_I_have_a_specific_question.21.22 > > > But do keep on expecting us to waste our time trying to help you. > > 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: Running Linux on a Jesurun A19 Android media player
On Thu, Sep 11, 2014 at 05:50:23AM -0700, Jason wrote: > Right. So your response is to make the message even more aggressive and > obnoxious. You just don't get it do you. > > I've been following this forum for several weeks now, and I have to say the > traffic is minimal. All I ever seem to see is patch submissions, and an > occasional debate about GPL compliance. And almost every question (not just > mine) is either ignored or met with a pointless RTFM style response. This > is hardly what I would describe as a "very active and advanced" community. > > If you're happy with this state of affairs then feel free to continue as > you are. But if you want this community to thrive then it needs to attract > new members, and that's only going to happen if you become more welcoming. > > You keep banging on about how people like me are wasting your precious > time. But it cuts both ways. No one is under any obligation to participate > in this community. For most people, this is just a silly hobby. No one > really needs Linux to run on their cheap throwaway Android devices, that > will be obsolete in a year anyway. I can assure you that 99% of people > reading through your wiki will be massively put off by the aggressive tone, > and the crazy hoops they're expected to jump through, and just walk away. > Seriously, who needs the aggro. Life's too short. > > Frankly, I don't think you're an appropriate person to be administering the > wiki. You clearly lack the tact and social skills to do the job in a > professional way. Has it ever occured to you that maybe, just maybe, your > attitude is at least part of the reason why Allwinner is reluctant to > engage with this community? Administering the wiki is not the right word for it, and it isn't all that i do. I have been active here for well over 2 years, i have seen many people come and go with the same questions and the same attitude. If it wasn't for the wiki and NDH, you'd be much much further off and you would not be asking specifics today yet. If you think that this is not a highly active community, feel free to buy other hardware with another SoC. Now stop crying, and go fill up your device page in a way that gives us something to work from, so that we at some point might actually be able to answer your questions. 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: Running Linux on a Jesurun A19 Android media player
On Thursday, 11 September 2014 09:07:37 UTC-4, Luc Verhaegen wrote: > > On Thu, Sep 11, 2014 at 05:50:23AM -0700, Jason wrote: > > Right. So your response is to make the message even more aggressive and > > obnoxious. You just don't get it do you. > Aiya! Let's all take it down a notch. Luc is a little gruff sometimes (okay, a lot of times), but he usually has a valid point. The issue is you're asking us to help you make some random wifi device work without giving us any more details about what this random device is or even something that might help us figure that out (like the fex file or even photos of the chips on the board). Usually what you need to do to get a wifi device to work is identify what it is and then load the appropriate module in the kernel. Occasionally the manufacturer has screwed up the fex file (the compiled version being script.bin), but it's best to start with just making sure the proper driver/kernel module is loaded. I also think the wiki points out that the fex file is gotten by using the sunxi-tools to "decompile" the script.bin file and then is stored in the github repo. You can submit a pull request to the boards repo, but it may not be accepted until it's clear that this board is going to work with everything else (which is demonstrated by completing a page in the wiki). The wiki page example also has a link to the wiki's upload page to upload photos of the device and board. As with any open source community, there's a give and take. There's often too many people who just want to take what they need and then go away and that often annoys the people who tend to give a lot more than they take. Luc is a person who gives way more than he takes in this community. Since you're new, and you're simply asking along the lines of "make my device work", it'd be natural to assume that you're in the "just take" column until proven otherwise. Going through the New Device Howto and sharing everything you can about your device shows that you're in the "give" column. -Tim -- 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] Availability of A80 boards to developers
Hi All, I asked Allwinner about the possibility of donation of a few A80 developer boards to developers and I got a positive response. So, I'll be doing the clerical work to arrange the donation. There should be several batches of boards being donated. This first batch is for five A80 OptimusBoard developer boards. I think they should be coming in the packaging that is shown at http://community.arm.com/thread/6449 The criteria are: 1. You have already done some relevant work with other Allwinner SoCs. 2. You plan to do work with the board towards mainline Linux support (describe what). This also includes any work with u-boot or other packages that let the A80 boot with a mainline kernel. Send me mail in private if you are interested to receive one. I'll process the requests and forward to Allwinner so that they can send the boards. If there are more than five requests, I'll keep the details for the subsequent batch. Simos -- 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: Running Linux on a Jesurun A19 Android media player
Ühel kenal päeval, K, 10.09.2014 kell 14:14, kirjutas Jason: > Luc, I deliberately ignored your earlier sarcasm. If you don't want > to help then that's fine no one's forcing you to. But your incessant > (and utterly pointless) RTFM style responses to every question are > now becoming irritating. > > Your request that others respect proper 'netiquette' would carry > more weight if you practiced what you preach. > > I've already read the unnecessarily aggressive (and slightly > obnoxious) message on the 'New Device Howto' page which basically > says you won't provide any help until someone's worked through the > guide. I get it. You don't need to repeat it. > > The problem with the NDH (as you insist on calling it) is that, in > many places, it's vague and/or incomplete. More importantly, it > assumes that the reader already possesses a vast amount of hightly > specialised knowledge. The hoops you expect someone to jump through > before you'll deign to help them are frankly ridiculous. You're > basically saying that you expect someone to spend many days working > everything out from first principles, and finally get to the point > where they don't really need any help, before you'll help them! Ok, I took a look at the Jesurun A19 page in the wiki and the only updated added information there is the stock Android build information under Identification section. > What's even more ridiculous is that I'm trying to work through the > damn NDH! But I can't submit my u-boot patches (or presumably > anything else) until I create a 'complete' (whatever that means) > device page, and I can't complete a device page until I know more > about my device! Hence my questions. While you certainly had time to figure out how to extract dram information, compile a working u-boot and even extract the stock android image from the internal NAND chip, you simply haven't even tried to update the wiki page of your device. If it helps, you might get a lot of information about various drivers from the kernel logs (man dmesg). So that's basically all the info WE could provide you, because you're the one who actually has the device. 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/d/optout.
[linux-sunxi] Re: New device support strategy.
On Tuesday, 9 September 2014 09:45:46 UTC-4, Luc Verhaegen wrote: > > But we have to start using the > SDKs more for A31(s), A23, A33 and A80 and all chips going forwards. > Are we able/allowed to host those SDK's somewhere? I know a few are on the linux-sunxi.org server, but can publicly host them on github or something like that? -- 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/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined
Hi Ian, Hans, On Mon, Sep 8, 2014 at 9:28 PM, Chen-Yu Tsai wrote: > 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. The other patches are for the next release, but maybe this fix could go into 2014.10? Thanks ChenYu > > 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.
Re: [linux-sunxi] Availability of A80 boards to developers
On Thu, Sep 11, 2014 at 05:22:21PM +0300, Simos Xenitellis wrote: > Hi All, > > I asked Allwinner about the possibility of donation of a few A80 developer > boards to developers and I got a positive response. So, I'll be doing the > clerical work to arrange the donation. > > There should be several batches of boards being donated. > This first batch is for five A80 OptimusBoard developer boards. I think > they should be coming in the packaging that is shown at > http://community.arm.com/thread/6449 > > The criteria are: > 1. You have already done some relevant work with other Allwinner SoCs. > 2. You plan to do work with the board towards mainline Linux support > (describe what). > This also includes any work with u-boot or other packages that let the A80 > boot with a mainline kernel. > > Send me mail in private if you are interested to receive one. > I'll process the requests and forward to Allwinner so that they can send > the boards. > If there are more than five requests, I'll keep the details for the > subsequent batch. > > Simos Thanks for doing this. In the past, how this has worked is that someone (Alejandro) went around the usual suspects, asked whether they were interested, and then collected addresses. But you probably have your reasons for approaching this differently. 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: New device support strategy.
On Thu, Sep 11, 2014 at 07:33:19AM -0700, Tim Tisdall wrote: > On Tuesday, 9 September 2014 09:45:46 UTC-4, Luc Verhaegen wrote: > > > > But we have to start using the > > SDKs more for A31(s), A23, A33 and A80 and all chips going forwards. > > > > Are we able/allowed to host those SDK's somewhere? I know a few are on the > linux-sunxi.org server, but can publicly host them on github or something > like that? I am not sure what the legal status of the whole SDK is. We are however able to do whatever we need with the GPLed bits. Whether we are allowed to use boot0 as we see fit, is something else, but somehow i expect that Allwinner does not want to make things worse than they already are. 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/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined
Hi Chen, On 09/11/2014 07:07 PM, Chen-Yu Tsai wrote: > Hi Ian, Hans, > > On Mon, Sep 8, 2014 at 9:28 PM, Chen-Yu Tsai wrote: >> 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. > > The other patches are for the next release, but maybe this fix could > go into 2014.10? I agree that this is a benign bug fix, but since we don't have any boards not setting CONFIG_EHCI atm I don't really see the value for getting it into 2014.10. Regards, Hans > > Thanks > > ChenYu > >> >> 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] Re: [PATCH 1/7] ARM: sunxi: Fix build break when CONFIG_USB_EHCI is not defined
On Thu, 2014-09-11 at 19:19 +0200, Hans de Goede wrote: > Hi Chen, > > On 09/11/2014 07:07 PM, Chen-Yu Tsai wrote: > > Hi Ian, Hans, > > > > On Mon, Sep 8, 2014 at 9:28 PM, Chen-Yu Tsai wrote: > >> 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. > > > > The other patches are for the next release, but maybe this fix could > > go into 2014.10? > > I agree that this is a benign bug fix, but since we don't have any > boards not setting CONFIG_EHCI atm I don't really see the value > for getting it into 2014.10. FWIW I was planning on putting the whole series in #next until the next merge window as soon as I find a some spare moments to look through it (sorry, might take me a few more days, I'm travelling at the w/e). Ian. -- 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: New device support strategy.
tor 2014-09-11 klockan 07:33 -0700 skrev Tim Tisdall: > Are we able/allowed to host those SDK's somewhere? I know a few are > on the linux-sunxi.org server, but can publicly host them on github or > something like that? I don't see any reason why not, as long as github (or whoever you use) accepts it. The SDKs are generally approved for redistribution by Allwinner. Just keep in mind that the SDKs are not a clean blanket in terms of licensing requirements. If you encounter a new valuable SDK release then getting it hosted on dl.linux-sunxi.org is a very good idea. Regards Henrik -- 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: Running Linux on a Jesurun A19 Android media player
Jason, try running lsusb and posting the results. A lot of Wi-Fi chips will be some slight variant that requires its own driver and I have found the id is the best place to start. Keep in mind if your driver isn't in the community's kernel already porting is probably required. Don't give up, you are on the threshold of a very large and rewarding experience but it's going to take some work. On Sep 11, 2014 7:30 AM, "Priit Laes" wrote: > > Ühel kenal päeval, K, 10.09.2014 kell 14:14, kirjutas Jason: > > Luc, I deliberately ignored your earlier sarcasm. If you don't want > > to help then that's fine no one's forcing you to. But your incessant > > (and utterly pointless) RTFM style responses to every question are > > now becoming irritating. > > > > Your request that others respect proper 'netiquette' would carry > > more weight if you practiced what you preach. > > > > I've already read the unnecessarily aggressive (and slightly > > obnoxious) message on the 'New Device Howto' page which basically > > says you won't provide any help until someone's worked through the > > guide. I get it. You don't need to repeat it. > > > > The problem with the NDH (as you insist on calling it) is that, in > > many places, it's vague and/or incomplete. More importantly, it > > assumes that the reader already possesses a vast amount of hightly > > specialised knowledge. The hoops you expect someone to jump through > > before you'll deign to help them are frankly ridiculous. You're > > basically saying that you expect someone to spend many days working > > everything out from first principles, and finally get to the point > > where they don't really need any help, before you'll help them! > > Ok, I took a look at the Jesurun A19 page in the wiki and the only > updated added information there is the stock Android build information > under Identification section. > > > > What's even more ridiculous is that I'm trying to work through the > > damn NDH! But I can't submit my u-boot patches (or presumably > > anything else) until I create a 'complete' (whatever that means) > > device page, and I can't complete a device page until I know more > > about my device! Hence my questions. > > While you certainly had time to figure out how to extract dram > information, compile a working u-boot and even extract the stock > android image from the internal NAND chip, you simply haven't even > tried to update the wiki page of your device. > > If it helps, you might get a lot of information about various drivers > from the kernel logs (man dmesg). > > So that's basically all the info WE could provide you, because you're > the one who actually has the device. > > 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/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 3/4] config:sunxi: set debug uart to 0 for sun5i defconfig
The sun5i defconfig default of CONFIG_SW_DEBUG_UART=1 is wrong on all devices except for those who use CONS_INDEX=2 in uboot. In others, both A10s as A13, it leads to a system which hardlocks. UART0 with the default pinmux can never lead to a working UART on A13, as these pins are not available on the A13 package. When the A13 based device has its accessible UART on UART1, then the UART0 setting does not hurt, it just does not give you a working early UART, but that does not prohibit the system from booting. When U-Boot has been set to use FEL/SDCON, then the UART0 pinmux will have been set to sd pins, and then this setting becomes valid again. Signed-off-by: Luc Verhaegen --- arch/arm/configs/sun5i_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/sun5i_defconfig b/arch/arm/configs/sun5i_defconfig index da0e418..aae0561e 100644 --- a/arch/arm/configs/sun5i_defconfig +++ b/arch/arm/configs/sun5i_defconfig @@ -42,7 +42,7 @@ CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_ARCH_SUN5I=y -CONFIG_SW_DEBUG_UART=1 +CONFIG_SW_DEBUG_UART=0 CONFIG_SWP_EMULATE=y CONFIG_PREEMPT=y CONFIG_AEABI=y -- 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] config:sunxi: add rtl wifi to sun5i_defconfig
Signed-off-by: Luc Verhaegen --- arch/arm/configs/sun5i_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/sun5i_defconfig b/arch/arm/configs/sun5i_defconfig index f837d69..da0e418 100644 --- a/arch/arm/configs/sun5i_defconfig +++ b/arch/arm/configs/sun5i_defconfig @@ -99,6 +99,8 @@ CONFIG_SCSI_MULTI_LUN=y CONFIG_NETDEVICES=y CONFIG_SUNXI_EMAC=y CONFIG_PHYLIB=y +CONFIG_RTL8192CU_SW=m +CONFIG_RTL8188EU=m CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set -- 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 0/4] Mostly defconfig patches.
Just some stuff that i had lying around which is not in our sunxi-3.4 yet. 3/4 is rather important, as it makes a10s and some a13 device actually boot. 4/4 is an older patch by paulk which i think should just go in as upstream has done the same in a much later kernel tree. 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 4/4] include: drm: Proper kernel define check
From: Paul Kocialkowski Signed-off-by: Paul Kocialkowski --- include/drm/drm.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/drm/drm.h b/include/drm/drm.h index 64ff02d..33ed74a 100644 --- a/include/drm/drm.h +++ b/include/drm/drm.h @@ -36,7 +36,7 @@ #ifndef _DRM_H_ #define _DRM_H_ -#if defined(__linux__) +#if defined(__linux__) || defined(__KERNEL__) #include #include -- 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] config:sunxi: remove picofb from sun7i defconfig
Fails to build anyway. Signed-off-by: Luc Verhaegen --- arch/arm/configs/sun7i_defconfig |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/sun7i_defconfig b/arch/arm/configs/sun7i_defconfig index 455ebcc..8e81652 100644 --- a/arch/arm/configs/sun7i_defconfig +++ b/arch/arm/configs/sun7i_defconfig @@ -925,7 +925,6 @@ CONFIG_HID_ORTEK=m CONFIG_HID_PANTHERLORD=m CONFIG_PANTHERLORD_FF=y CONFIG_HID_PETALYNX=m -CONFIG_HID_PICOLCD=m CONFIG_HID_PRIMAX=m CONFIG_HID_ROCCAT=m CONFIG_HID_SAITEK=m -- 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: Running Linux on a Jesurun A19 Android media player
> Anyway, I'll upload the fex file and the u-boot batches this weekend, > assuming of course that Luc hasn't locked my account by that time. Please upload photos 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.
[linux-sunxi] Re: [PATCH 0/7] clk: sun6i: Unify AHB1 clock and fix rate calculation
Hi Chen-Yu, On Sat, Sep 06, 2014 at 06:47:21PM +0800, Chen-Yu Tsai wrote: > Hi everyone, > > This series unifies the mux and divider parts of the AHB1 clock found > on sun6i and sun8i, while also adding support for the pre-divider on > the PLL6 input. > > The rate calculation logic must factor in which parent it is using to > calculate the rate, to decide whether to use the pre-divider or not. > This is beyond the original factors clk design in sunxi. To avoid > feature bloat, this is implemented as a seperate composite clk. > > The new clock driver is registered with a separate OF_CLK_DECLARE. > This is done so that assigned-clocks* properties on the clk provider > node can actually work. The clock framework arranges the clock setup > order by checking whether all clock parents are available, by checking > the node matching OF_CLK_DECLARE. > > However, the sunxi clk driver is based on the root node compatible, > has no defined dependencies (parents), and is setup before the fixed-rate > clocks. Thus when the ahb1 clock is added, all parents have rate = 0. > There is no way to calculate the required clock factors to set a default > clock rate under these circumstances. This happens when we set the > defaults in the clock node (provider), rather than a clock consumer. > > I can think of 2 ways to solve the dependency issue, but neither is > pretty. One would be to move the root fixed-rate clocks into the sunxi > clk driver. The other would be separating all the clocks into individual > OF_CLK_DECLARE statements, which adds a lot of boilerplate code. I don't know what Mike thinks of this, but I'd prefer the second. 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/7] clk: sunxi: Add post clk divider for factor clocks
On Sat, Sep 06, 2014 at 06:47:22PM +0800, Chen-Yu Tsai wrote: > Some factor clocks, mostly PLLs, have an extra fixed divider just before > the clock output. Add an option to the factor clk driver config data to > specify this divider. > > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard 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 2/7] clk: sunxi: Fix PLL6 calculation on sun6i
On Sat, Sep 06, 2014 at 06:47:23PM +0800, Chen-Yu Tsai wrote: > The N factor for PLL6 counts from 1 to 32, as specified in the A23 > manual, and shown in Allwinner's original A31 code. > > Also the PLL6 factors alone calculate the clock rate for PLL6x2, not > the normal halved output for PLL6. This is what the factors clk > .recalc_rate callback expects. > > This patch fixes the N factor in the clock driver, and adds a post > PLL divider of 2 to calculate the rate for PLL6. > > A further patch (to the DT) should add a fixed-factor x2 clock as > the PLL6x2 output. > > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard 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 3/7] clk: sunxi: unify sun6i AHB1 clock with proper PLL6 pre-divider
Hi, On Sat, Sep 06, 2014 at 06:47:24PM +0800, Chen-Yu Tsai wrote: > This patch unifies the sun6i AHB1 clock, originally supported > with separate mux and divider clks. It also adds support for > the pre-divider on the PLL6 input, thus allowing the clock to > be muxed to PLL6 with proper clock rate calculation. > > Signed-off-by: Chen-Yu Tsai It looks fine, but I'd rather see this in a separate file, especially since we don't seem to have any order dependency. 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 7/7] dmaengine: sun6i: Remove obsolete clk muxing code
On Sat, Sep 06, 2014 at 06:47:28PM +0800, Chen-Yu Tsai wrote: > The sun6i DMA controller requires the AHB1 bus clock to be > clocked from PLL6. This was originally done by the dmaengine > driver during probe time. The AHB1 clock driver has since been > unified, so the original code does not work. > > Remove the clk muxing code, and replace it with DT clk default > properties. > > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard 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 6/7] ARM: dts: sun6i: Add required ahb1 clock parent and rates for dma controller
On Sat, Sep 06, 2014 at 06:47:27PM +0800, Chen-Yu Tsai wrote: > The DMA controller requires AHB1 bus clock to be clocked from PLL6. > > Signed-off-by: Chen-Yu Tsai > --- > arch/arm/boot/dts/sun6i-a31.dtsi | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi > b/arch/arm/boot/dts/sun6i-a31.dtsi > index 8eb2c6d..1117989 100644 > --- a/arch/arm/boot/dts/sun6i-a31.dtsi > +++ b/arch/arm/boot/dts/sun6i-a31.dtsi > @@ -317,6 +317,11 @@ > clocks = <&ahb1_gates 6>; > resets = <&ahb1_rst 6>; > #dma-cells = <1>; > + > + /* DMA controller requires AHB1 clocked from PLL6 */ > + assigned-clocks = <&ahb1>; > + assigned-clock-parents = <&pll6>; > + assigned-clock-rates = <2>; Where did you get that from? The user manual says that it should be clocked at 600MHz, and I'm not sure it should be enforced there either. 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 6/7] ARM: dts: sun6i: Add required ahb1 clock parent and rates for dma controller
On Fri, Sep 12, 2014 at 5:15 AM, Maxime Ripard wrote: > On Sat, Sep 06, 2014 at 06:47:27PM +0800, Chen-Yu Tsai wrote: >> The DMA controller requires AHB1 bus clock to be clocked from PLL6. >> >> Signed-off-by: Chen-Yu Tsai >> --- >> arch/arm/boot/dts/sun6i-a31.dtsi | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi >> b/arch/arm/boot/dts/sun6i-a31.dtsi >> index 8eb2c6d..1117989 100644 >> --- a/arch/arm/boot/dts/sun6i-a31.dtsi >> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi >> @@ -317,6 +317,11 @@ >> clocks = <&ahb1_gates 6>; >> resets = <&ahb1_rst 6>; >> #dma-cells = <1>; >> + >> + /* DMA controller requires AHB1 clocked from PLL6 */ >> + assigned-clocks = <&ahb1>; >> + assigned-clock-parents = <&pll6>; >> + assigned-clock-rates = <2>; > > Where did you get that from? > > The user manual says that it should be clocked at 600MHz, and I'm not > sure it should be enforced there either. The bindings mean that ahb1 should be clocked from pll6 and at 200 MHz, not "pll6 should be 200 MHz". I assume you were misled by them. Clocking ahb1 from pll6 and at 200 MHz with the /3 pre-divider is the vendor BSP default: On sun6i, the clock init code calls aw_ccu_switch_ahb_2_pll6(), which muxes ahb1 from pll6 with the highest dividers, then sets the rate for ahb1 to pll6, which sets pre-divider to /3 and divider to /1. Hope this clears it up. :) Cheers ChenYu -- 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 3/7] clk: sunxi: unify sun6i AHB1 clock with proper PLL6 pre-divider
Hi, On Fri, Sep 12, 2014 at 5:02 AM, Maxime Ripard wrote: > Hi, > > On Sat, Sep 06, 2014 at 06:47:24PM +0800, Chen-Yu Tsai wrote: >> This patch unifies the sun6i AHB1 clock, originally supported >> with separate mux and divider clks. It also adds support for >> the pre-divider on the PLL6 input, thus allowing the clock to >> be muxed to PLL6 with proper clock rate calculation. >> >> Signed-off-by: Chen-Yu Tsai > > It looks fine, but I'd rather see this in a separate file, especially > since we don't seem to have any order dependency. Sorry, just to be clear, separate file under clk/sunxi? This cannot be in a separate file, as it shares a spinlock with apb1 divider. They share the same register. We could move apb1 out though. But i would prefer to do that when we split out all the clocks into individual OF_CLK_DECLAREs. ChenYu -- 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] a13: hsg-h702: update dram parameters from meminfo
Pushed, along with a23 memory controller register dumps. On Mon, Sep 1, 2014 at 12:40 PM, Chen-Yu Tsai wrote: > Signed-off-by: Chen-Yu Tsai > --- > > I want to get some input before i push this. > Is the dram_zq parameter suppose to be filled? > or just the lower 8 bits? It seems all the other > sun4/5/7i boards only have the lower 8 bits set. > > > ChenYu > > --- > sys_config/a13/hsg_h702.fex | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/sys_config/a13/hsg_h702.fex b/sys_config/a13/hsg_h702.fex > index 0748b6b..b691df4 100644 > --- a/sys_config/a13/hsg_h702.fex > +++ b/sys_config/a13/hsg_h702.fex > @@ -59,11 +59,11 @@ dram_baseaddr = 0x4000 > dram_clk = 432 > dram_type = 3 > dram_rank_num = 1 > -dram_chip_density = 2048 > -dram_io_width = 8 > +dram_chip_density = 4096 > +dram_io_width = 16 > dram_bus_width = 16 > dram_cas = 9 > -dram_zq = 0x7b > +dram_zq = 0x56b9697b > dram_odt_en = 0 > dram_size = 512 > dram_tpr0 = 0x42d899b7 > -- > 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.
