[linux-sunxi] Re: [PATCH v3 1/2] clk: sunxi: Add sun8i MBUS clock support
On Tue, Sep 16, 2014 at 06:04:01PM +0800, Chen-Yu Tsai wrote: The MBUS clock on sun8i is slightly different from the old mod0 clocks. The divider is 3 bits wider, while also needing a divider table for the higher 4 values, which all set the same divider. Signed-off-by: Chen-Yu Tsai w...@csie.org Applied, 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 1/7] clk: sunxi: Add post clk divider for factor clocks
On Wed, Sep 24, 2014 at 11:35:58PM +0800, Chen-Yu Tsai wrote:
Hi Maxime, Emilio,
On Tue, Sep 16, 2014 at 11:57 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
Hi Emilio,
On Sat, Sep 13, 2014 at 11:43:46AM -0300, Emilio López wrote:
Hi,
El 06/09/14 a las 07:47, Chen-Yu Tsai escibió:
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 w...@csie.org
---
drivers/clk/sunxi/clk-factors.c | 3 +++
drivers/clk/sunxi/clk-factors.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/clk/sunxi/clk-factors.c
b/drivers/clk/sunxi/clk-factors.c
index 2057c8a..435111d 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -64,6 +64,9 @@ static unsigned long clk_factors_recalc_rate(struct
clk_hw *hw,
/* Calculate the rate */
rate = (parent_rate * (n + config-n_start) * (k + 1) p) / (m +
1);
+if (config-post_div)
+rate /= config-post_div;
+
return rate;
}
diff --git a/drivers/clk/sunxi/clk-factors.h
b/drivers/clk/sunxi/clk-factors.h
index d2d0efa..ce70c65 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -16,6 +16,7 @@ struct clk_factors_config {
u8 pshift;
u8 pwidth;
u8 n_start;
+u8 post_div;
};
struct clk_factors {
For the record, I liked your solution on[1] more, as it's in line
with what we're doing on the other sunxi platforms, instead of
adding features in factors to cover for some cases. But it's your
and Maxime's call, as I haven't written any of the sun6i code so
far.
No, you still wrote most of the clock support, so your opinion is
always valuable (and valued).
Thing is, unlike what was done in the sun4i driver where there was a
real technical issue that was preventing us from using only
fixed-factor, we're not in such a case in sun6i (and later,
apparently).
PLL6 has only one output, which is then directly multiplied by
fixed-factors, without any (pre|post)-dividers for any of them.
That means that following what you did for the sun4i would just
register 3 dumbs fixed-factors, that we couldn't reference from DT,
or through a cryptic index (which is not even documented in our
bindings).
I'd be fine either way, I just prefer the solution that has less code
and is more explicit.
What's the verdict on this series?
If Emilio prefers to have a single clock node, fine. But please update
the DT bindings documentation.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH v3 0/2] clk: sun8i: Add MBUS support
Hi Chen-Yu, On Tue, Sep 16, 2014 at 06:04:00PM +0800, Chen-Yu Tsai wrote: Hi, This is v3 of my sun8i MBUS clock series. This series depends on Maxime's clk: sunxi: Improve MMC clocks support series, specifically the patches that change the factor clocks and move out mod0 and mbus. Ideally this series should also be merged after my clk: sun6i: Unify AHB1 clock and fix rate calculation for the PLL6 corrections, but I don't think it would cause any issues if it didn't. I'll hold off the second patch, since we're still in discussion for the PLL6 part. And since we're very close to the merge window opening, it would have been merged for 3.19 anyway, and we still have plenty of time. 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 1/7] clk: sunxi: Add post clk divider for factor clocks
On Sat, Sep 27, 2014 at 3:07 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Wed, Sep 24, 2014 at 11:35:58PM +0800, Chen-Yu Tsai wrote:
Hi Maxime, Emilio,
On Tue, Sep 16, 2014 at 11:57 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
Hi Emilio,
On Sat, Sep 13, 2014 at 11:43:46AM -0300, Emilio López wrote:
Hi,
El 06/09/14 a las 07:47, Chen-Yu Tsai escibió:
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 w...@csie.org
---
drivers/clk/sunxi/clk-factors.c | 3 +++
drivers/clk/sunxi/clk-factors.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/clk/sunxi/clk-factors.c
b/drivers/clk/sunxi/clk-factors.c
index 2057c8a..435111d 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -64,6 +64,9 @@ static unsigned long clk_factors_recalc_rate(struct
clk_hw *hw,
/* Calculate the rate */
rate = (parent_rate * (n + config-n_start) * (k + 1) p) / (m +
1);
+if (config-post_div)
+rate /= config-post_div;
+
return rate;
}
diff --git a/drivers/clk/sunxi/clk-factors.h
b/drivers/clk/sunxi/clk-factors.h
index d2d0efa..ce70c65 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -16,6 +16,7 @@ struct clk_factors_config {
u8 pshift;
u8 pwidth;
u8 n_start;
+u8 post_div;
};
struct clk_factors {
For the record, I liked your solution on[1] more, as it's in line
with what we're doing on the other sunxi platforms, instead of
adding features in factors to cover for some cases. But it's your
and Maxime's call, as I haven't written any of the sun6i code so
far.
No, you still wrote most of the clock support, so your opinion is
always valuable (and valued).
Thing is, unlike what was done in the sun4i driver where there was a
real technical issue that was preventing us from using only
fixed-factor, we're not in such a case in sun6i (and later,
apparently).
PLL6 has only one output, which is then directly multiplied by
fixed-factors, without any (pre|post)-dividers for any of them.
That means that following what you did for the sun4i would just
register 3 dumbs fixed-factors, that we couldn't reference from DT,
or through a cryptic index (which is not even documented in our
bindings).
I'd be fine either way, I just prefer the solution that has less code
and is more explicit.
What's the verdict on this series?
If Emilio prefers to have a single clock node, fine. But please update
the DT bindings documentation.
OK. Then this series needs a bit of work. I'll pick the orignal
divs clocks patch from patchwork (as I didn't keep one) and fix
up the DT.
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] How to enable bluetooth power
I have unnamed A10 tablet with RDA bluetooth on serial. Bluetooth adapter seems to be disabled by default. In stock gpl-violating kernel it controls by /sys/class/usb_wifi/rtl_wifi/bt hciattach shows this before bt enabled: ./hciattach -n -s 115200 /dev/ttyS2 rda 150 flow opt=110 opt=115 chenjieaaa --debug argc=8 n=0 opt =/dev/ttyS2 chenjieaaa --debug argc=8 n=1 opt =rda chenjieaaa --debug argc=8 n=2 opt =150 chenjieaaa --debug argc=8 n=3 opt =flow init_uart - flags =0 u-init fd = 3 rda_587x debug --val 0 u-speed =150 u-bdaddr=41:57:73:01:02:03 rda_init--bt debug RDABT_core_Intialization--bt debug rdabt_get_chipid--bt debug Initialization timed out. After echoing on to /sys/class/usb_wifi/rtl_wifi/bt initialisation successful: ./hciattach -n -s 115200 /dev/ttyS2 rda 150 flow opt=110 opt=115 chenjieaaa --debug argc=8 n=0 opt =/dev/ttyS2 chenjieaaa --debug argc=8 n=1 opt =rda chenjieaaa --debug argc=8 n=2 opt =150 chenjieaaa --debug argc=8 n=3 opt =flow init_uart - flags =0 u-init fd = 3 rda_587x debug --val 0 u-speed =150 u-bdaddr=41:57:73:01:02:03 rda_init--bt debug RDABT_core_Intialization--bt debug rdabt_get_chipid--bt debug 5875y is ok --bt debug rda_init1 write here rda_set_bdaddr 1--bt debug BCM_BT start Write_BD_ADDR mac=41:57:73:01:02:03 rda_init2 write here rda_init2 write here val 0 u-speed =150 u-bdaddr=41:57:73:01:02:03 init_uart--u-flags=1 rda_setup_flow_ctl -flow rda_setup_flow_ctl i=0 num_send=14 rda_setup_flow_ctl i=1 num_send=14 rda_setup_flow_ctl Device setup complete sigdelset OK This is bt_para section: [bt_para] bt_used = 1 bt_uart_id = 2 bt_mod_type = 1 bt_pwren = port:PH111defaultdefaultdefault bt_wake = port:PI201defaultdefaultdefault bt_vbat = port:PH121defaultdefaultdefault It seems that i need enaple power on PH11, but how to do that? What full fex: http://dpaste.com/2C4HPFZ Also csi camera, sun4i-keyboard and internal usb modem does not work. -- 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] How to enable bluetooth power
Hi Toroshin, On Sat, Sep 27, 2014 at 9:13 PM, Toroshin Dmitry mitt...@sibmail.com wrote: I have unnamed A10 tablet with RDA bluetooth on serial. Bluetooth adapter seems to be disabled by default. In stock gpl-violating kernel it controls by /sys/class/usb_wifi/rtl_wifi/bt hciattach shows this before bt enabled: We'll be able to give you much better assistance with this if you go through the New Device Howto: http://linux-sunxi.org/New_Device_howto ./hciattach -n -s 115200 /dev/ttyS2 rda 150 flow opt=110 opt=115 chenjieaaa --debug argc=8 n=0 opt =/dev/ttyS2 chenjieaaa --debug argc=8 n=1 opt =rda chenjieaaa --debug argc=8 n=2 opt =150 chenjieaaa --debug argc=8 n=3 opt =flow init_uart - flags =0 u-init fd = 3 rda_587x debug --val 0 u-speed =150 u-bdaddr=41:57:73:01:02:03 rda_init--bt debug RDABT_core_Intialization--bt debug rdabt_get_chipid--bt debug Initialization timed out. After echoing on to /sys/class/usb_wifi/rtl_wifi/bt initialisation successful: ./hciattach -n -s 115200 /dev/ttyS2 rda 150 flow opt=110 opt=115 chenjieaaa --debug argc=8 n=0 opt =/dev/ttyS2 chenjieaaa --debug argc=8 n=1 opt =rda chenjieaaa --debug argc=8 n=2 opt =150 chenjieaaa --debug argc=8 n=3 opt =flow init_uart - flags =0 u-init fd = 3 rda_587x debug --val 0 u-speed =150 u-bdaddr=41:57:73:01:02:03 rda_init--bt debug RDABT_core_Intialization--bt debug rdabt_get_chipid--bt debug 5875y is ok --bt debug rda_init1 write here rda_set_bdaddr 1--bt debug BCM_BT start Write_BD_ADDR mac=41:57:73:01:02:03 rda_init2 write here rda_init2 write here val 0 u-speed =150 u-bdaddr=41:57:73:01:02:03 init_uart--u-flags=1 rda_setup_flow_ctl -flow rda_setup_flow_ctl i=0 num_send=14 rda_setup_flow_ctl i=1 num_send=14 rda_setup_flow_ctl Device setup complete sigdelset OK This is bt_para section: [bt_para] bt_used = 1 bt_uart_id = 2 bt_mod_type = 1 bt_pwren = port:PH111defaultdefaultdefault bt_wake = port:PI201defaultdefaultdefault bt_vbat = port:PH121defaultdefaultdefault It seems that i need enaple power on PH11, but how to do that? This should be handled by the driver, which kernel are you using? What full fex: http://dpaste.com/2C4HPFZ Also csi camera, sun4i-keyboard and internal usb modem does not work. With more info, we should be able to help you with this. Also, what do you mean by a usb modem is there a phone socket on the device? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
Hi All, I just received from Sugar the documentation files (hardware datasheet and user manuals) for the A10, A10s, A13, A20, A31 and A31s. This is part of the release of documents of documents that was announced a few weeks ago. There should be a subsequent release of the remaining SoCs at a later date. I offered to curate the documents, so here we go: In each document there is a revision history that shows what changed between versions. The revision history is consistently followed, thus I did not add any dates in the filenames. The filenames have two decimal digits (instead of one) for the version because some old versions did use the second decimal digit. Here are the version numbers of the new documents compared to what was previously available at http://dl.linux-sunxi.org/ Hardware datasheets A10: version 1.70 (previously known version 1.21) A10s: version 1.40 (previously known version 1.20) A13: version 1.30 (previously known version 1.12) A20: version 1.40 (none) A31: version 1.40 (previously known version 1.00) A31s: version 1.40 (previously known version 1.30) User manual A10: version 1.50 (previously known version 1.20) A10s: version 1.30 (none) A13: version 1.30 (previously known version 1.20) A20: version 1.20 (previously known version 1.00) A31: version 1.20 (previously known version 1.10) A31s: version 1.10 (previously known version 1.00) Here are the SHA1 checksums, b0507d4f96ceafe08eddb3182c5f328614deb606 AllwinnerDocs/A10s/A10s User Manual V1.30.pdf 3cb77cde50d6e720af8ee9de1bc167253670741d AllwinnerDocs/A10s/A10s Datasheet V1.40.pdf 6984efaeb7fbb046df2145d3b988cf7fda1e822a AllwinnerDocs/A31s/A31s User Manual V1.10.pdf 0d2bf1356906c47ccca977449a17bc2aa15008e9 AllwinnerDocs/A31s/A31s Datasheet v1.40.pdf b341bed4e7b2d653265cb2abe088a32aac563222 AllwinnerDocs/A13/A13 Datasheet V1.30.pdf 9c555300f673c2334c821823f83c7af2115a3b81 AllwinnerDocs/A13/A13 User Manual V1.30.pdf ca6c4ae69db8df28b0bf99326f41a87cd6659a24 AllwinnerDocs/A20/A20 Datasheet V1.40.pdf 83526d6f80bdcf22011bbd1ba2b811e91dfac21f AllwinnerDocs/A20/A20 User Manual V1.20.pdf eaa07db283c609b36d19d8b0d014debc42a0d85c AllwinnerDocs/A10/A10 User manual V1.50.pdf 978d45b865c426dbfbfe3f08666f47265fbd2c00 AllwinnerDocs/A10/A10 Datasheet V1.70.pdf 423e8564bc1e190af67262b32b840ae37b2d3a51 AllwinnerDocs/A31/A31 User Manual V1.20.pdf e9c2226d0d16bff66d2d53dd2c08ac3185dc6905 AllwinnerDocs/A31/A31 Datasheet V1.40.pdf You can find the docs at http://dl.linux-sunxi.org/ in their respective directories with the filenames shown above. If you would like to download these files as a set, see http://dl.linux-sunxi.org/users/simos/ 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] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
Is there a specific contact point for documentation issues? For example it looks like the A20 manual is still missing the chapter for the S/PDIF hardware. It is kind of documented here by looking at the source for the S/PDIF drivers in the SDK. http://linux-sunxi.org/SPDIF On Sat, Sep 27, 2014 at 9:26 AM, Simos Xenitellis simos.li...@googlemail.com wrote: Hi All, I just received from Sugar the documentation files (hardware datasheet and user manuals) for the A10, A10s, A13, A20, A31 and A31s. This is part of the release of documents of documents that was announced a few weeks ago. There should be a subsequent release of the remaining SoCs at a later date. I offered to curate the documents, so here we go: In each document there is a revision history that shows what changed between versions. The revision history is consistently followed, thus I did not add any dates in the filenames. The filenames have two decimal digits (instead of one) for the version because some old versions did use the second decimal digit. Here are the version numbers of the new documents compared to what was previously available at http://dl.linux-sunxi.org/ Hardware datasheets A10: version 1.70 (previously known version 1.21) A10s: version 1.40 (previously known version 1.20) A13: version 1.30 (previously known version 1.12) A20: version 1.40 (none) A31: version 1.40 (previously known version 1.00) A31s: version 1.40 (previously known version 1.30) User manual A10: version 1.50 (previously known version 1.20) A10s: version 1.30 (none) A13: version 1.30 (previously known version 1.20) A20: version 1.20 (previously known version 1.00) A31: version 1.20 (previously known version 1.10) A31s: version 1.10 (previously known version 1.00) Here are the SHA1 checksums, b0507d4f96ceafe08eddb3182c5f328614deb606 AllwinnerDocs/A10s/A10s User Manual V1.30.pdf 3cb77cde50d6e720af8ee9de1bc167253670741d AllwinnerDocs/A10s/A10s Datasheet V1.40.pdf 6984efaeb7fbb046df2145d3b988cf7fda1e822a AllwinnerDocs/A31s/A31s User Manual V1.10.pdf 0d2bf1356906c47ccca977449a17bc2aa15008e9 AllwinnerDocs/A31s/A31s Datasheet v1.40.pdf b341bed4e7b2d653265cb2abe088a32aac563222 AllwinnerDocs/A13/A13 Datasheet V1.30.pdf 9c555300f673c2334c821823f83c7af2115a3b81 AllwinnerDocs/A13/A13 User Manual V1.30.pdf ca6c4ae69db8df28b0bf99326f41a87cd6659a24 AllwinnerDocs/A20/A20 Datasheet V1.40.pdf 83526d6f80bdcf22011bbd1ba2b811e91dfac21f AllwinnerDocs/A20/A20 User Manual V1.20.pdf eaa07db283c609b36d19d8b0d014debc42a0d85c AllwinnerDocs/A10/A10 User manual V1.50.pdf 978d45b865c426dbfbfe3f08666f47265fbd2c00 AllwinnerDocs/A10/A10 Datasheet V1.70.pdf 423e8564bc1e190af67262b32b840ae37b2d3a51 AllwinnerDocs/A31/A31 User Manual V1.20.pdf e9c2226d0d16bff66d2d53dd2c08ac3185dc6905 AllwinnerDocs/A31/A31 Datasheet V1.40.pdf You can find the docs at http://dl.linux-sunxi.org/ in their respective directories with the filenames shown above. If you would like to download these files as a set, see http://dl.linux-sunxi.org/users/simos/ 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] How to enable bluetooth power
суббота, 27 сентября 2014 г., 19:03:26 UTC+7 пользователь Julian Calaby написал:
Hi Toroshin,
On Sat, Sep 27, 2014 at 9:13 PM, Toroshin Dmitry mitt...@sibmail.com wrote:
I have unnamed A10 tablet with RDA bluetooth on serial.
Bluetooth adapter seems to be disabled by default.
In stock gpl-violating kernel it controls by /sys/class/usb_wifi/rtl_wifi/bt
hciattach shows this before bt enabled:
We'll be able to give you much better assistance with this if you go
through the New Device Howto: http://linux-sunxi.org/New_Device_howto
./hciattach -n -s 115200 /dev/ttyS2 rda 150 flow
opt=110
opt=115
chenjieaaa --debug argc=8 n=0 opt
=/dev/ttyS2
chenjieaaa --debug argc=8 n=1 opt =rda
chenjieaaa --debug argc=8 n=2 opt =150
chenjieaaa --debug argc=8 n=3 opt =flow
init_uart -
flags =0
u-init fd = 3
rda_587x
debug --val 0 u-speed =150 u-bdaddr=41:57:73:01:02:03
rda_init--bt debug
RDABT_core_Intialization--bt debug
rdabt_get_chipid--bt debug
Initialization timed out.
After echoing on to /sys/class/usb_wifi/rtl_wifi/bt initialisation
successful:
./hciattach -n -s 115200 /dev/ttyS2 rda 150 flow
opt=110
opt=115
chenjieaaa --debug argc=8 n=0 opt
=/dev/ttyS2
chenjieaaa --debug argc=8 n=1 opt =rda
chenjieaaa --debug argc=8 n=2 opt =150
chenjieaaa --debug argc=8 n=3 opt =flow
init_uart -
flags =0
u-init fd = 3
rda_587x
debug --val 0 u-speed =150 u-bdaddr=41:57:73:01:02:03
rda_init--bt debug
RDABT_core_Intialization--bt debug
rdabt_get_chipid--bt debug
5875y is ok --bt debug
rda_init1 write here
rda_set_bdaddr 1--bt debug
BCM_BT start Write_BD_ADDR
mac=41:57:73:01:02:03
rda_init2 write here
rda_init2 write here
val 0 u-speed =150 u-bdaddr=41:57:73:01:02:03
init_uart--u-flags=1
rda_setup_flow_ctl -flow
rda_setup_flow_ctl i=0 num_send=14
rda_setup_flow_ctl i=1 num_send=14
rda_setup_flow_ctl
Device setup complete
sigdelset OK
This is bt_para section:
[bt_para]
bt_used = 1
bt_uart_id = 2
bt_mod_type = 1
bt_pwren = port:PH111defaultdefaultdefault
bt_wake = port:PI201defaultdefaultdefault
bt_vbat = port:PH121defaultdefaultdefault
It seems that i need enaple power on PH11, but how to do that?
This should be handled by the driver, which kernel are you using?
What full fex: http://dpaste.com/2C4HPFZ
Also csi camera, sun4i-keyboard and internal usb modem does not work.
With more info, we should be able to help you with this.
Also, what do you mean by a usb modem is there a phone socket on the device?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Yes, there is a phone SIM socket on main board. Modem is on separate board,
connected with USB and SIM pins.
I can add page, but cannot provide board images and get a serial console
because i have no camera and voltage-compatible serial adapter. And i cannot
fully uncover case because i'm not owner of this tablet.
And i don't know how to name page.
stock kernel is lichee-3.0.8+, sunxi kernel is 3.4.103.
Version of u-boot is unknown, i got it from
http://4pda.ru/forum/index.php?showtopic=400424st=1160#entry25983219 image
because cannot get any u-boot-sunxi version to work.
I cannot find any code fetching bt_para and fex guide does not contain bt_pwren
value, so it seems that bluetooth power configuration is not supported in sunxi
kernel at all.
I added code enabling usb1 end pwren to rtl8192cu usb initialisation code:
--sw_usb_enable_hcd(usb_wifi_host);
--sw_usb_enable_hcd(1);
--u32 pio_hdle = gpio_request_ex(bt_para, NULL);
--if(pio_hdle)
--{
gpio_write_one_pin_value(pio_hdle, 1, bt_pwren);
gpio_release(pio_hdle, 2);
--}
but it doesn't help.
insmod sun4i_keyboard says 'No such device', nothing in dmesg appears.
--
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] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
On Sat, 27/9/14, Simos Xenitellis simos.li...@googlemail.com wrote: I just received from Sugar the documentation Hooray well done to all concerned (AW included). Er, not the A80? John -- 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] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
lör 2014-09-27 klockan 09:35 -0400 skrev jonsm...@gmail.com: Is there a specific contact point for documentation issues? For example it looks like the A20 manual is still missing the chapter for the S/PDIF hardware. The current proposal is that we track errata and shortcomings in our wiki giving us a central point where we record what information is missing. But there also need to be a notification to allwinner somehow. But should be sufficient to send a notice to the mailinglist I hope, with Allwinner being somewhat present here. 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] Availability of A80 boards to developers
On Tue, Sep 23, 2014 at 11:31 PM, Olliver Schinagl oliver+l...@schinagl.nl wrote: On 09/22/2014 11:16 PM, Simos Xenitellis wrote: On Mon, Sep 22, 2014 at 11:14 PM, Olliver Schinagl oli...@schinagl.nl mailto:oli...@schinagl.nl wrote: Hi list, long time, no write. Where did this come from may I ask? I was in contact with Eva about a month or so ago (august) where I supplied them with a list of code committers. Did you meanwhile submit this list? I do hope we are not asking in tripples and making AW feel we're just being greedy. I'll go read the rest of this thread now :) Hi Olliver, My contact for this was Eva as well, thus there should not be an issue about greediness. The way I approached this was to ask for developers to email me if they are interested for the dev board, considering that the initial work on the A80 would be quite low level. I think that there is interest from Allwinner to assist the community with hardware. If these initial boards are put into good use, then it is highly likely that there will be more rounds of donations. Yeah, Eva asked me for a list of members where things like donations etc would go to. She contacted me as I contacted her on several occasions before and made her watch my FOSDEM talk ;) So Allwinner (eva) allready said they want to support the community with donations. I was just wondering if Eva asked you to compile a second list, or if this was your idea and you intend to submit your list to eva 'out of the blue'. It was my idea to request A80 dev boards and I did not know about your efforts. Did you write to this mailing list about your efforts? I did not receive any e-mail about it. I have the impression that Eva assumed we knew each other's efforts as she mentioned something about commits which I did not understand at the time. Simos Olliver Simos Olliver On 09/11/2014 04:22 PM, 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 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+unsubscribe@__googlegroups.com mailto:linux-sunxi%2bunsubscr...@googlegroups.com mailto:linux-sunxi+__unsubscr...@googlegroups.com mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/__optout 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+unsubscribe@__googlegroups.com mailto:linux-sunxi%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/__optout 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 mailto: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. -- 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
Re: [linux-sunxi] Availability of A80 boards to developers
I have the impression that Eva assumed we knew each other's efforts as she mentioned something about commits which I did not understand at the time. No idea if its connected, but Cubietech guys sent linux-sunxi boards two times, cb2 and ct, but that was more than half a year ago. Also don't forget that wild lkcl might appear and Eva might still think that rhombus-tech = linux-sunxi. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
Quoting Maxime Ripard (2014-09-02 02:25:08) On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote: On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote: On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote: I would think the memory should still be reserved anyway to make sure nothing else is writing over it. And it's in the device tree anyway because the driver needs to know where to put framebuffer content. So the point I was trying to make is that we can't treat the memory in the same way as clocks because it needs to be explicitly managed. Whereas clocks don't. The driver is simply too generic to know what to do with the clocks. You agreed on the fact that the only thing we need to do with the clocks is claim them. Really, I don't find what's complicated there (or not generic). That's not what I agreed on. What I said is that the only thing we need to do with the clocks is nothing. They are already in the state that they need to be. Claim was probably a poor choice of words, but still. We have to keep the clock running, and both the solution you've been giving and this patch do so in a generic way. It doesn't know what frequency they should be running at We don't care about that. Just like we don't care about which frequency is the memory bus running at. It will just run at whatever frequency is appropriate. Exactly. And you shouldn't have to care about them at all. Firmware has already configured the clocks to run at the correct frequencies, and it has made sure that they are enabled. or what they're used for And we don't care about that either. You're not interested in what output the framebuffer is setup to use, which is pretty much the same here, this is the same thing here. That's precisely what I've been saying. The only thing that simplefb cares about is the memory it should be using and the format of the pixels (and how many of them) it writes into that memory. Everything else is assumed to have been set up. Including clocks. We're really discussing in circles here. Mike? -EHIGHLATENCYRESPONSE I forgot about this thread. Sorry. In an attempt to provide the least helpful answer possible, I will stay clear of all of the stuff relating to how simple should simplefb be and the related reserved memory discussion. A few times in this thread it is stated that we can't prevent unused clocks from being disabled. That is only partially true. The clock framework DOES provide a flag to prevent UNUSED clocks from being disabled at late_initcall-time by a clock garbage collector mechanism. Maxime and others familiar with the clock framework are aware of this. What the framework doesn't do is to allow for a magic flag in DT, in platform_data or elsewhere that says, don't let me get turned off until the right driver claims me. That would be an external or alternative method for preventing a clock from being disabled. We have a method for preventing clocks from being disabled. It is as follows: struct clk *my_clk = clk_get(...); clk_prepare_enable(my_clk); That is how it should be done. Period. With that said I think that Luc's approach is very sensible. I'm not sure what purpose in the universe DT is supposed to serve if not for _this_exact_case_. We have a nice abstracted driver, usable by many people. The hardware details of how it is hooked up at the board level can all be hidden behind stable DT bindings that everyone already uses. What more could you want? Regards, Mike Your opinion would be very valuable. so by any definition of what DT should describe they're useless for this virtual device. Furthermore it's fairly likely that as your kernel support progresses you'll find that the driver all of a sudden needs to manage some other type of resource that you just haven't needed until now because it may default to being always on. Then you'll have a hard time keeping backwards-compatibility and will have to resort to the kinds of hacks that you don't want to see in the kernel. Not such a hard time. An older DT wouldn't define the new requirements anyway, so they wouldn't be used, and we would end up in pretty much the current case. Except that you have firmware in the wild that sets up an incomplete simplefb node and if you don't want to break compatibility you need to provide fallbacks for the resources that aren't listed in the DT node. And given that those fallbacks are all very board specific you'll need to find ways to keep them enabled if you want to keep existing setups working. How would an *optional* property break those users? If you don't need any clock to be kept running (or are hiding them under the carpet), of course you don't need such a property. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering
Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
On Sat, Sep 27, 2014 at 04:26:26PM +0300, Simos Xenitellis wrote: Hi All, I just received from Sugar the documentation files (hardware datasheet and user manuals) for the A10, A10s, A13, A20, A31 and A31s. This is part of the release of documents of documents that was announced a few weeks ago. There should be a subsequent release of the remaining SoCs at a later date. I offered to curate the documents, so here we go: In each document there is a revision history that shows what changed between versions. The revision history is consistently followed, thus I did not add any dates in the filenames. The filenames have two decimal digits (instead of one) for the version because some old versions did use the second decimal digit. Here are the version numbers of the new documents compared to what was previously available at http://dl.linux-sunxi.org/ Hardware datasheets A10: version 1.70 (previously known version 1.21) A10s: version 1.40 (previously known version 1.20) A13: version 1.30 (previously known version 1.12) A20: version 1.40 (none) A31: version 1.40 (previously known version 1.00) A31s: version 1.40 (previously known version 1.30) User manual A10: version 1.50 (previously known version 1.20) A10s: version 1.30 (none) A13: version 1.30 (previously known version 1.20) A20: version 1.20 (previously known version 1.00) A31: version 1.20 (previously known version 1.10) A31s: version 1.10 (previously known version 1.00) Here are the SHA1 checksums, b0507d4f96ceafe08eddb3182c5f328614deb606 AllwinnerDocs/A10s/A10s User Manual V1.30.pdf 3cb77cde50d6e720af8ee9de1bc167253670741d AllwinnerDocs/A10s/A10s Datasheet V1.40.pdf 6984efaeb7fbb046df2145d3b988cf7fda1e822a AllwinnerDocs/A31s/A31s User Manual V1.10.pdf 0d2bf1356906c47ccca977449a17bc2aa15008e9 AllwinnerDocs/A31s/A31s Datasheet v1.40.pdf b341bed4e7b2d653265cb2abe088a32aac563222 AllwinnerDocs/A13/A13 Datasheet V1.30.pdf 9c555300f673c2334c821823f83c7af2115a3b81 AllwinnerDocs/A13/A13 User Manual V1.30.pdf ca6c4ae69db8df28b0bf99326f41a87cd6659a24 AllwinnerDocs/A20/A20 Datasheet V1.40.pdf 83526d6f80bdcf22011bbd1ba2b811e91dfac21f AllwinnerDocs/A20/A20 User Manual V1.20.pdf eaa07db283c609b36d19d8b0d014debc42a0d85c AllwinnerDocs/A10/A10 User manual V1.50.pdf 978d45b865c426dbfbfe3f08666f47265fbd2c00 AllwinnerDocs/A10/A10 Datasheet V1.70.pdf 423e8564bc1e190af67262b32b840ae37b2d3a51 AllwinnerDocs/A31/A31 User Manual V1.20.pdf e9c2226d0d16bff66d2d53dd2c08ac3185dc6905 AllwinnerDocs/A31/A31 Datasheet V1.40.pdf You can find the docs at http://dl.linux-sunxi.org/ in their respective directories with the filenames shown above. If you would like to download these files as a set, see http://dl.linux-sunxi.org/users/simos/ Simos Why didn't someone from Allwinner send these documents in him/herself? 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: i2s audio codec support for sun7i
Hi Puneet B,
Thanks fir your answer.
I am using sunxi 3.4.61-r1 with this patches:
RT: http://cb2.autostatic.com/linux-sunxi-rt/patch-3.4.61-sunxi-rt77.diff.gz
I2S: http://www.cubieforums.com/index.php/topic,1081.msg12862.html#msg12862
If you like to check the driver for the CS4245 its on github:
https://github.com/portalmod/linux-sunxi/tree/sunxi-3.4.61-r1-rt77-i2s-cs4245,
but it is still a work in progress.
The machine driver is: sound/soc/sunxi/mod-duo.c
The codec driver is sound/soc/codecs/cs4245.c
Best regards,
Rafael Guayer
2014-09-27 2:19 GMT-03:00 Puneet B punit...@gmail.com:
Hi Rafel,
The fex file i have attached in my previous post i did not done any
changes.
and here my machine driver .
in device.c file just add fallowing line.
+static struct i2c_board_info __initdata aic3x_i2c_board_info[] = {
+{
+ .type = tlv320aic31xx,
+ .addr = 0x18,
+}
+};
void __init sw_pdev_init(void)
{
platform_add_devices(sw_pdevs, ARRAY_SIZE(sw_pdevs));
+i2c_register_board_info(2, aic3x_i2c_board_info,
+ ARRAY_SIZE(aic3x_i2c_board_info));
}
which kernel you are using?.
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/d/optout.
--
Rafael Guayer
www.portalmod.com http://www.portalmod.com.br
--
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.
