Re: [linux-sunxi] Re: Upstreaming sunxi mmc support
On Thu, Jan 2, 2014 at 10:10 PM, Hans de Goede wrote: [snip] > I've also taken a quick look at your patches, I've one remark about: > https://github.com/linux-sunxi/linux-sunxi/commit/796b36502919bd4327029d0f0b10180af279c72e Hi David, in the patch Hans noted, it seems you missed mmc3 when renaming compatibles for sun7i-a20.dtsi. Looking forward to this getting into mainline. Need it for WiFi. :) 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/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On Fri, Jan 3, 2014 at 5:03 AM, Arend van Spriel wrote: > On 01/02/2014 06:09 PM, Chen-Yu Tsai wrote: >> Hi, >> >> On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel wrote: >> [snip] >>> Hi Chen-Yu, >>> >>> I confirmed the patch is working with a revision 0 of the device. What >>> chip revision does it give in your log (need to load brcmfmac with >>> module parameter debug=4). >> >> Mine is revision 1. Managed mode confirmed working. > > Which firmware did you use. Can you provide 'hexdump -C' output > (especially the last part). > I used fw_bcm40181a2.bin. MD5 sum: ce95e81aa95f9dc1a32fb8acf691dbd8 fw_bcm40181a2.bin Here's the last part of the dump. root@cubietruck:/lib/firmware/brcm# hexdump -C brcmfmac43362-sdio.bin | tail 00035920 01 bd 32 08 01 00 34 33 33 36 32 61 32 2d 72 6f |..2...43362a2-ro| 00035930 6d 6c 2f 73 64 69 6f 2d 67 2d 70 6e 6f 2d 70 6b |ml/sdio-g-pno-pk| 00035940 74 66 69 6c 74 65 72 2d 6b 65 65 70 61 6c 69 76 |tfilter-keepaliv| 00035950 65 2d 77 61 70 69 2d 77 6d 65 2d 70 32 70 20 56 |e-wapi-wme-p2p V| 00035960 65 72 73 69 6f 6e 3a 20 35 2e 39 30 2e 31 39 35 |ersion: 5.90.195| 00035970 2e 38 39 20 43 52 43 3a 20 62 64 31 65 33 65 35 |.89 CRC: bd1e3e5| 00035980 61 20 44 61 74 65 3a 20 4d 6f 6e 20 32 30 31 33 |a Date: Mon 2013| 00035990 2d 30 34 2d 32 32 20 31 37 3a 32 34 3a 34 34 20 |-04-22 17:24:44 | 000359a0 43 53 54 7d 00|CST}.| 000359a5 ChenYu > Gr. AvS > >> Logs: >> brcmfmac: F1 signature read @0x1800=0x1591a962 >> brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1 >> brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore >> rev/type=10/0x829 >> >> >> 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/groups/opt_out.
Re: [linux-sunxi] [PATCH] a20: fix up inet_k70hc wifi
On Fri, Jan 03, 2014 at 02:01:54AM +0100, Luc Verhaegen wrote: > Signed-off-by: Luc Verhaegen > --- > sys_config/a20/inet_k70hc.fex |6 +- > 1 files changed, 5 insertions(+), 1 deletions(-) With this patch on top, i think that the inet k70hc is well enough supported to be included in sunxi-boards. The OTG port is still useless, but i will document that for the time being. I will have to get back to this soon, as i rather rely on g_ether for doing development while travelling at 300+kmph. But first i have to buy myself a male micro usb connector where i can solder a wire to the id pin. 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/groups/opt_out.
[linux-sunxi] [PATCH] a20: fix up inet_k70hc wifi
Signed-off-by: Luc Verhaegen --- sys_config/a20/inet_k70hc.fex |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/sys_config/a20/inet_k70hc.fex b/sys_config/a20/inet_k70hc.fex index 66fd3cc..cec3b97 100644 --- a/sys_config/a20/inet_k70hc.fex +++ b/sys_config/a20/inet_k70hc.fex @@ -747,7 +747,7 @@ usb_port_type = 1 usb_detect_type = 0 usb_drv_vbus_gpio = port:PH03<1><0><0> usb_restrict_gpio = -usb_host_init_state = 0 +usb_host_init_state = 1 usb_restric_flag = 0 [usb_feature] @@ -815,6 +815,10 @@ ap6xxx_bt_regon = port:PB05<1><0> ap6xxx_bt_wake = port:PI20<1><0> ap6xxx_bt_host_wake = port:PI21<0><0> +[usb_wifi_para] +usb_wifi_used = 1 +usb_wifi_usbc_num = 2 + [3g_para] 3g_used = 0 3g_usbc_num = 2 -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers
On Thu, Jan 02, 2014 at 09:20:22PM +0100, Maxime Ripard wrote:
> On Thu, Jan 02, 2014 at 02:45:29PM +0100, Hans de Goede wrote:
> > >Also, instead of inventing yet another vendor-specific property, why not
> > >re-use
> > >a button binding similar to gpio-keys like:
> > >
> > >lradc: lradc@01c22800 {
> > >compatible = "allwinner,sun4i-lradc-keys";
> > >reg = <0x01c22800 0x100>;
> > >interrupts = <31>;
> > >allwinner,chan0-step = <200>;
> > >
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > button@0 {
> > > reg = <0>; /* your channel index from above */
> > > linux,code = <115>; /* already used as dt-property */
> > > };
> > >
> > > button@1 {
> > > reg = <1>;
> > > linux,code = <114>;
> > > };
> >
> > Ugh no. Having a vendor specific property which is KISS certainly
> > beats this, both wrt ease of writing dts files as well as wrt the
> > dts parsing code in the driver.
>
> I'd agree with Heiko here. This is pretty much the same construct
> that's already in use in other input drivers, like gpio-keys.
>
> This is also something that can really easily be made generic, since
> this is something that is rather common.
Except that button definition from gpio-keys does not use 'reg' property
but rather gpio. I'd rather we did not cram non-applicable attributes
into that definition just to make it "reusable" like that.
I'd be OK with having similar (but not claiming to be the same) mappings
though.
Thanks.
--
Dmitry
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH] sunxi: Add Inet K70HC device
On Thu, Jan 02, 2014 at 03:17:16PM +0100, Hans de Goede wrote: > Hi, > > On 01/02/2014 12:37 PM, Luc Verhaegen wrote: >> Signed-off-by: Luc Verhaegen > > Thanks, added to the u-boot-sunxi git repo sunxi branch. > > Regards, > > Hans Thanks! 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/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers
Hi,
On 01/02/2014 09:20 PM, Maxime Ripard wrote:
On Thu, Jan 02, 2014 at 02:45:29PM +0100, Hans de Goede wrote:
Also, instead of inventing yet another vendor-specific property, why not re-use
a button binding similar to gpio-keys like:
lradc: lradc@01c22800 {
compatible = "allwinner,sun4i-lradc-keys";
reg = <0x01c22800 0x100>;
interrupts = <31>;
allwinner,chan0-step = <200>;
#address-cells = <1>;
#size-cells = <0>;
button@0 {
reg = <0>; /* your channel index from above */
linux,code = <115>; /* already used as dt-property */
};
button@1 {
reg = <1>;
linux,code = <114>;
};
Ugh no. Having a vendor specific property which is KISS certainly
beats this, both wrt ease of writing dts files as well as wrt the
dts parsing code in the driver.
I'd agree with Heiko here. This is pretty much the same construct
that's already in use in other input drivers, like gpio-keys.
In the gpio case there is a 1 on 1 relation between a single hw
entity (the gpio-pin) and a single keycode. Here there is 1 hw entity
which maps to an array of key-codes, certainly using an array rather
then a much more complicated construct is the correct data-structure
to represent this.
This is also something that can really easily be made generic, since
this is something that is rather common.
Speaking of which. I believe this should actually come in two
different drivers:
- The ADC driver itself, using IIO
- A generic button handler driver on top of IIO.
>
> The fact that on most board this adc is used for buttons doesn't make
> any difference, it's actually a hardware designer choice, we should
> support that choice, but we should also be able to use it just as an
> ADC.
No, this is not a generic adc, as mentioned in the commit msg, this
adc is specifically designed to be used this way.
The adc won't start sampling data, and won't generate any interrupts
until a button is pressed. That is until the input voltage drops below
2/3 of Vref, this is checked through a built-in analog comparator, which
hooks into the control logic.
It has button down and button up interrupts, and can detect long
presses (unused) and generate a second type of down interrupt for those.
This really is an input device, which happens to use an adc.
Carlo Caione already started to work on an IIO driver for the LRADC:
https://github.com/carlocaione/linux/tree/sunxi-lradc
maybe you can take over his work.
That won't work because the adc won't sample if the input gets above
2/3 of Vref. There may be some other mode which does not do that, but
that is not clearly documented.
Even if an IIO driver turns out to be doable, I strongly believe that
having a separate input driver for this is best, since this device
was designed to be used as such. Building input on top of IIO would
mean polling the adc, while with my driver it actually generates
button down / up interrupts without any polling being involved.
And no boards I know of are using this as a generic analog input,
where as many boards are using it as designed.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH] wireless:rtl8188eu: add usb id for rtl8188etv
On Thursday, January 2, 2014 4:43:27 PM UTC-5, Luc Verhaegen wrote: > > On Thu, Jan 02, 2014 at 12:51:27PM -0800, Patrick Wood wrote: > > Searching for "0x0179" on this list shows this is the third time this > > exact patch has been submitted. Since this is something that's > > already in the upstream code, I don't see why it was never applied. > > Ouch :( > +1 Pat -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH] wireless:rtl8188eu: add usb id for rtl8188etv
On Thu, Jan 02, 2014 at 12:51:27PM -0800, Patrick Wood wrote: > Searching for "0x0179" on this list shows this is the third time this > exact patch has been submitted. Since this is something that's > already in the upstream code, I don't see why it was never applied. Ouch :( And still our wiki is littered with the workarounds/patches :( 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/groups/opt_out.
Re: [linux-sunxi] FOSDEM 2014, what do we want
On Wednesday, January 1, 2014 8:13:12 AM UTC-5, Tim Fletcher wrote: > > On 01/01/14 13:06, Oliver Schinagl wrote: > > Hey list, > > > > as you should remember, I applied for FOSDEM and got accepted. As I'm > > working on the presentation, I am curious what you guys think others > > would be interested in hearing about. > > > > So please, pretend this is a blank slate, and suggest whatever should be > > mentioned during FOSDEM and I will try to take that into account. > > I think that a lot of people aren't aware of how far the sunxi project > has come towards making the allwinner SoCs well supported and part of > the main line kernel. I know I wasn't aware of it until I read Rich's > blog post about the cubietruck and KVM. > > Being able to point people towards a few good cheap boards they can get > Linux up and running on quickly and easily would help too. Too many (to > my mind) of the postings on the debian-arm list are about bodging debian > onto ancient arm5 devices. > > I think you should put up a slide or two comparing the AW SoCs with other low-cost, high-integration ARM SoCs out there, like Rockchip, Broadcom, AMLogic, and maybe Freescale. Include things like HW features, current level of FOS support (or lack thereof) for IP blocks, level of kernel support (or lack thereof) from the manufacturer, status of reverse-engineered blocks, etc. Also include a "high-end" SoC like Tegra or OMAP as a reference. Rhombus Tech has some useful information comparing different SoCs. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On 01/02/2014 06:09 PM, Chen-Yu Tsai wrote: > Hi, > > On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel wrote: > [snip] >> Hi Chen-Yu, >> >> I confirmed the patch is working with a revision 0 of the device. What >> chip revision does it give in your log (need to load brcmfmac with >> module parameter debug=4). > > Mine is revision 1. Managed mode confirmed working. Which firmware did you use. Can you provide 'hexdump -C' output (especially the last part). Gr. AvS > Logs: > brcmfmac: F1 signature read @0x1800=0x1591a962 > brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1 > brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore > rev/type=10/0x829 > > > 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/groups/opt_out.
[linux-sunxi] [PATCH] wireless:rtl8188eu: add usb id for rtl8188etv
Searching for "0x0179" on this list shows this is the third time this exact patch has been submitted. Since this is something that's already in the upstream code, I don't see why it was never applied. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On 01/02/2014 08:22 PM, Rosimildo DaSilva wrote: > It would be nice to be precise about what is working: > > a) Wifi + BT > b) WIFI only > c) BT only > > Reading the thread, it seems you got (a) WIFI + BT working. Is this correct > ? I think you need to read the thread once more. Wifi is working, no life sign from the BT using UART, ie. (b). Gr. AvS > R > > > On Thursday, January 2, 2014 11:09:12 AM UTC-6, Chen-Yu Tsai wrote: >> >> Hi, >> >> On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel >> > >> wrote: >> [snip] >>> Hi Chen-Yu, >>> >>> I confirmed the patch is working with a revision 0 of the device. What >>> chip revision does it give in your log (need to load brcmfmac with >>> module parameter debug=4). >> >> Mine is revision 1. Managed mode confirmed working. >> >> Logs: >> brcmfmac: F1 signature read @0x1800=0x1591a962 >> brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1 >> brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore >> rev/type=10/0x829 >> >> >> 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/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers
On Thu, Jan 02, 2014 at 02:45:29PM +0100, Hans de Goede wrote:
> >Also, instead of inventing yet another vendor-specific property, why not
> >re-use
> >a button binding similar to gpio-keys like:
> >
> >lradc: lradc@01c22800 {
> >compatible = "allwinner,sun4i-lradc-keys";
> >reg = <0x01c22800 0x100>;
> >interrupts = <31>;
> >allwinner,chan0-step = <200>;
> >
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > button@0 {
> > reg = <0>; /* your channel index from above */
> > linux,code = <115>; /* already used as dt-property */
> > };
> >
> > button@1 {
> > reg = <1>;
> > linux,code = <114>;
> > };
>
> Ugh no. Having a vendor specific property which is KISS certainly
> beats this, both wrt ease of writing dts files as well as wrt the
> dts parsing code in the driver.
I'd agree with Heiko here. This is pretty much the same construct
that's already in use in other input drivers, like gpio-keys.
This is also something that can really easily be made generic, since
this is something that is rather common.
Speaking of which. I believe this should actually come in two
different drivers:
- The ADC driver itself, using IIO
- A generic button handler driver on top of IIO.
The fact that on most board this adc is used for buttons doesn't make
any difference, it's actually a hardware designer choice, we should
support that choice, but we should also be able to use it just as an
ADC.
Carlo Caione already started to work on an IIO driver for the LRADC:
https://github.com/carlocaione/linux/tree/sunxi-lradc
maybe you can take over his work.
I also wonder wether it would be possible in that case to use reg as
the "button" voltage, to get rid of both the chan0-step property, and
those big fat arrays in the driver.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[linux-sunxi] sunxi-3.4: make life easier for rtl8188etv users.
This trivial patch is several times over present in our wiki, but no-one apparently has bothered with just sending it as an actual git patch for inclusion in our sunxi-3.4 branch, or when it did happen, it just sat rotting on our ML. Please fasttrack it, there is no point in putting this trivial change which affects only a single driver in the stage branch. There is nothing that can break which cannot be either build tested or which could be a regression. With this change in sunxi-3.4 some wiki cleanup will take place. 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/groups/opt_out.
[linux-sunxi] [PATCH] wireless:rtl8188eu: add usb id for rtl8188etv
Signed-off-by: Luc Verhaegen
---
.../net/wireless/rtl8188eu/os_dep/linux/usb_intf.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
b/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
index 8b85338..fbe0a7f 100644
--- a/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
+++ b/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
@@ -186,6 +186,7 @@ static struct usb_device_id rtw_usb_id_tbl[] ={
#ifdef CONFIG_RTL8188E
/*=== Realtek demoboard ===*/
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8179)},//Default ID
+ {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)},//RTL8188ETV
#endif
{} /* Terminating entry */
};
--
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/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On 2 January 2014 20:22, Rosimildo DaSilva wrote: > It would be nice to be precise about what is working: > > a) Wifi + BT > b) WIFI only > c) BT only > > Reading the thread, it seems you got (a) WIFI + BT working. Is this correct No, it's b) There is some bit missing for BT. Possibly setting the power and reset gpio pins correctly. Or maybe the uart is set up with wrong parameters. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
It would be nice to be precise about what is working: a) Wifi + BT b) WIFI only c) BT only Reading the thread, it seems you got (a) WIFI + BT working. Is this correct ? R On Thursday, January 2, 2014 11:09:12 AM UTC-6, Chen-Yu Tsai wrote: > > Hi, > > On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel > > > wrote: > [snip] > > Hi Chen-Yu, > > > > I confirmed the patch is working with a revision 0 of the device. What > > chip revision does it give in your log (need to load brcmfmac with > > module parameter debug=4). > > Mine is revision 1. Managed mode confirmed working. > > Logs: > brcmfmac: F1 signature read @0x1800=0x1591a962 > brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1 > brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore > rev/type=10/0x829 > > > 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/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On Fri, Jan 3, 2014 at 12:52 AM, Michal Suchanek wrote: > Hello, > > On 19 December 2013 11:12, Chen-Yu Tsai wrote: [snip] >> Bluetooth still isn't responding. >> > > Well, bluetooth is supposed to be attached to an UART, not SDIO. > That's what the datasheets of the chip I found looked like. Correct. CubieTruck schematics indicate it's connected to UART2. > Not sure how firmware is supposed to fit in in this case but this > would not be the first serial BT chip requiring firmware, would it? Broadcom has a utility called brcm_patchram_plus that loads the firmware. However I can't get my chip to respond to its first reset command. 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/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel wrote: [snip] > Hi Chen-Yu, > > I confirmed the patch is working with a revision 0 of the device. What > chip revision does it give in your log (need to load brcmfmac with > module parameter debug=4). Mine is revision 1. Managed mode confirmed working. Logs: brcmfmac: F1 signature read @0x1800=0x1591a962 brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1 brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore rev/type=10/0x829 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/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hello, On 19 December 2013 11:12, Chen-Yu Tsai wrote: > Hi, > > On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai wrote: >> Hi, >> >> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel >> wrote: >>> On 12/18/2013 02:12 PM, Hans de Goede wrote: Hi, On 12/18/2013 11:31 AM, Arend van Spriel wrote: > On 12/05/2013 10:46 PM, Julian Calaby wrote: >> Firstly, are there any plans to support the BCM43362 chipset with the >> brcmfmac driver in the near future? > > Hi Julian, > > I am working on a patch to support this chip. It is looking promising. > Just have to go after a firmware image to be sure. Cool. Do you have a cubietruck? With my latest wip tree: https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next >>> >>> No cubietruck here. I googled the term last week because it came up and >>> found embeddedcomputer.nl selling it. >>> We've mmc/sdio controller support on top of 3.13-rc4, it would be nice if we could also get the wifi and bluetooth to work here. > > I got the chip to respond to probing. It is BCM43362 for sure. > > root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device > 0xa962 > root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor > 0x02d0 > > Vendor ID is Broadcom. Device ID is 43362. > But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know > if this is normal or not. > > Bluetooth still isn't responding. > Well, bluetooth is supposed to be attached to an UART, not SDIO. That's what the datasheets of the chip I found looked like. Not sure how firmware is supposed to fit in in this case but this would not be the first serial BT chip requiring firmware, would it? Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers
Hi Hans, Dmitry,
Am Donnerstag, 2. Januar 2014, 10:37:47 schrieb Hans de Goede:
> Hi,
>
> On 01/01/2014 09:56 PM, Dmitry Torokhov wrote:
> > Hi Hans,
> >
> > On Wed, Jan 01, 2014 at 08:30:07PM +0100, Hans de Goede wrote:
> >> +Required properties:
> >> + - compatible: "allwinner,sun4i-lradc-keys"
> >> + - reg: mmio address range of the chip
> >> + - interrupts: interrupt to which the chip is connected
> >> + - allwinner,chan0-step: step in mV between keys must be 150 or 200
> >> + - allwinner,chan0-keycodes: array of include/uapi/linux/input.h KEY_
> >> codes>
> > I think this should be "linux,chan0-keycodes".
>
> Right, because the codes are Linux specific, will fix in v2.
but the property with its "chan0-" thingy would be allwinner-specific if I'm
not mistaken.
Also, instead of inventing yet another vendor-specific property, why not re-use
a button binding similar to gpio-keys like:
lradc: lradc@01c22800 {
compatible = "allwinner,sun4i-lradc-keys";
reg = <0x01c22800 0x100>;
interrupts = <31>;
allwinner,chan0-step = <200>;
#address-cells = <1>;
#size-cells = <0>;
button@0 {
reg = <0>; /* your channel index from above */
linux,code = <115>; /* already used as dt-property */
};
button@1 {
reg = <1>;
linux,code = <114>;
};
...
};
But I may be on the wrong track here, so I've included the devicetree-people
for help, which I guess should've been included from the beginning.
Heiko
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] sunxi-devel branch updated to 3.13-rc6
Hi, Would you like to merge v2 of the gmac series as it is now? It has proper MII/RGMII support, so it doesn't need u-boot. https://github.com/wens/linux/tree/wip/stmmac-v2 Cheers, ChenYu On Thu, Jan 2, 2014 at 10:12 PM, Hans de Goede wrote: > Hi All, > > I've just updated: > https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel > to 3.13-rc6. Also new is an updated version of the mmc driver (mostly > cosmetic fixes > to get it ready for upstream) and a sun4i-lradc-keys driver > > The sunxi-devel branch now contains 3.13-rc6 > > + the following, which should all go upstream for 3.14: > > https://github.com/mripard/linux/commits/sunxi-clk-for-3.13 > https://github.com/mripard/linux/commits/sunxi-drivers-for-3.14 > https://github.com/mripard/linux/commits/sunxi-core-for-3.14 > https://github.com/mripard/linux/commits/sunxi-dt-for-3.14 > sunxi-bits of: > > https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/clockevents/next > Emilio's "[PATCH v3 00/13] clk: sunxi: add PLL5 and PLL6 support" series > Chen's external oscillator work > sun4i-ts resisitive touchscreen controller + temp sensor driver > sun4i-lradc-keys driver > > + the following which is not quite ready for 3.14 yet, but people > are working hard to get it ready so hopefully we will see some of > it in 3.14, and the rest should make 3.15: > > Emilio's sunxi-clk branch: patches not part of the above set > David's and mine sunxi-mmc work > Chen's gmac work > Oliver's ahci work > Arokux' ehci work > > Note for this to work properly on sun7i and sun5i you also need my > sunxi-next u-boot branch: > https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next > > Enjoy, > > Hans > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Explain the contents of bootloader...
On 02-01-14 10:49, Puneet B wrote: Hi i flashed the cubieboard image to sd card from this link. https://docs.google.com/file/d/0B-bAEPML8fwlUFd5OHVOaFJIRmc/edit. then in Volumn(bootlaoder) folder of sdcard i got fallowing binaries. 1.boot.axf This is the allwinner 'battery charging app' that also chainloads u-boot if need so. 2.boot_signature.axf this is some sort of signature required by boot.axf i assume 3.drv_hdmi.drv this is the HDMI driver to output over ... hdmi yes 4.font32.sft a font 5.magic.bin some secret sauce 6.prvt.axf some private data 7.script.bin the famous script.bin/fex 8.boot.ini a dos file for boot.axf to parse to decide what to boot 9.drv_de.drv display engine driver 10.font24.sft a nother font! 11.linux -> linux.bmp linux.ini u-boot.bin (sub contents). the linux splash screen (android actually) an ini file to tell boot.axf what and how to boot it (it being u-boot). u-boot here is the lichee-u-boot, one that does NOT init dram, but DOES support NAND 12.os_show ->bat0.bmp bat2.bmp bat5.bmp bat8.bmp bempty.bmp full.bmplinux2.bmp melis2.bmp wince1.bmp bat10.bmp bat3.bmp bat6.bmp bat9.bmp bootlogo.bmp head.bmplow_pwr.bmp startup.bmp wince2.bmp bat1.bmp bat4.bmp bat7.bmp battery.bmp empty.bmp linux1.bmp melis1.bmp tail.bmp boot.axf image files (like empty battery, charging, some pics they intended to use as boot selector that never happened. 13.script0.bin backup copy of script.bin, in case 1 is broken it tries to read this one 14.sprite.axf helper program to handle the loading of bitmaps it would seem. Out of these i know script.bin , and u-boot.bin (but i flashed to /dev/sdc ). you cannot flash that u-boot to a SD card, it works only on nand, and you shouldn't mess with it. Kindly tell what will be purpose of remaining binaries. and tell me what will be difference between boot0 ,boot1 and sunxi-spl.bin ,u-boot.bin. YOu really don't know this yet? Have you ever looked at our wiki? boot0 is allwinner's version of what we call u-boot-sunxi-spl. boot1 is allwinners variant of what we call u-boot.bin boot0/1 is what we call u-boot-sunxi-with-spl.bin which is inteded to be flashed to an mmc card, starting at the 8k marker. Oliver Regards Punith -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] FOSDEM 2014, what do we want
On 02-01-14 15:26, Luc Verhaegen wrote: On Thu, Jan 02, 2014 at 03:18:58PM +0100, Hans de Goede wrote: Hi, On 01/01/2014 10:55 PM, Oliver Schinagl wrote: Hehe, I too think it would be could to spend most of the talk on upstream progress. If possible I would also add maybe one sheet about the android derived 3.4 kernel, where you can basically summarize things by saying that everything more or less works :) Regards, Hans I do not agree. Upstream linux kernel support is not what this talk is about, and the talk should very broadly cover many aspects of the linux-sunxi project. If you wanted an upstream linux kernel talk for sunxi, you should've filed a separate talk. I think this subject is so broad, that all (kernel) directions should and could be talked about. 3.4 is interesting, 3.10 is interesting, mainline is interesting. 3.0 btw is not, but even talking a little about 3.3 is important to the crowd to know what's out there (and what to avoid). This is about new people that don't know what's going on here, all information is good :) oliver 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/groups/opt_out.
Re: [linux-sunxi] FOSDEM 2014, what do we want
On Thu, Jan 02, 2014 at 03:18:58PM +0100, Hans de Goede wrote: > Hi, > > On 01/01/2014 10:55 PM, Oliver Schinagl wrote: > > Hehe, I too think it would be could to spend most of the talk on upstream > progress. If possible I would also add maybe one sheet about the android > derived 3.4 kernel, where you can basically summarize things by saying that > everything more or less works :) > > Regards, > > Hans I do not agree. Upstream linux kernel support is not what this talk is about, and the talk should very broadly cover many aspects of the linux-sunxi project. If you wanted an upstream linux kernel talk for sunxi, you should've filed a separate talk. 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/groups/opt_out.
Re: [linux-sunxi] FOSDEM 2014, what do we want
Hi, On 01/01/2014 10:55 PM, Oliver Schinagl wrote: On 01/01/14 14:13, Tim Fletcher wrote: On 01/01/14 13:06, Oliver Schinagl wrote: Hey list, as you should remember, I applied for FOSDEM and got accepted. As I'm working on the presentation, I am curious what you guys think others would be interested in hearing about. So please, pretend this is a blank slate, and suggest whatever should be mentioned during FOSDEM and I will try to take that into account. I think that a lot of people aren't aware of how far the sunxi project has come towards making the allwinner SoCs well supported and part of the main line kernel. I know I wasn't aware of it until I read Rich's blog post about the cubietruck and KVM. Well the status of the sunxi community obviously should be one of the main reasons for holding this talk :) Hehe, I too think it would be could to spend most of the talk on upstream progress. If possible I would also add maybe one sheet about the android derived 3.4 kernel, where you can basically summarize things by saying that everything more or less works :) Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH] sunxi: Add Inet K70HC device
Hi,
On 01/02/2014 12:37 PM, Luc Verhaegen wrote:
Signed-off-by: Luc Verhaegen
Thanks, added to the u-boot-sunxi git repo sunxi branch.
Regards,
Hans
---
board/sunxi/Makefile |1 +
board/sunxi/dram_inet_k70hc.c | 31 +++
boards.cfg|1 +
3 files changed, 33 insertions(+), 0 deletions(-)
create mode 100644 board/sunxi/dram_inet_k70hc.c
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 7fefdf0..f274a1d 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_HACKBERRY) += dram_hackberry.o
obj-$(CONFIG_A7HD)+= dram_sun4i_360_1024_iow8.o
obj-$(CONFIG_INTERRA3)+= dram_mk802ii_a20.o
obj-$(CONFIG_INET97F_II) += dram_sun4i_408_512.o
+obj-$(CONFIG_INET_K70HC) += dram_inet_k70hc.o
obj-$(CONFIG_JESURUN_Q5) += dram_sun4i_312_1024_iow8.o
obj-$(CONFIG_K1001L1C)+= dram_a20_olinuxino_m.o
obj-$(CONFIG_MEFAFEIS_A08)+= dram_megafeis_a08.o
diff --git a/board/sunxi/dram_inet_k70hc.c b/board/sunxi/dram_inet_k70hc.c
new file mode 100644
index 000..d5ddc13
--- /dev/null
+++ b/board/sunxi/dram_inet_k70hc.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include
+#include
+
+static struct dram_para dram_para = {
+ .clock = 384,
+ .type = 3,
+ .rank_num = 1,
+ .density = 4096,
+ .io_width = 16,
+ .bus_width = 32,
+ .cas = 9,
+ .zq = 0x12331a7f,
+ .odt_en = 0,
+ .size = 1024,
+ .tpr0 = 0x42d899b7,
+ .tpr1 = 0xa090,
+ .tpr2 = 0x22a00,
+ .tpr3 = 0,
+ .tpr4 = 1,
+ .tpr5 = 0,
+ .emr1 = 0x4,
+ .emr2 = 0x10,
+ .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+ return dramc_init(&dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index 7eeb17a..eda05de 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -380,6 +380,7 @@ Active arm armv7 sunxi -
sunxi
Active arm armv7 sunxi - sunxi
Hyundai_A7HD sun4i:A7HD,SPL
-
Active arm armv7 sunxi - sunxi
Interra-3
sun7i:INTERRA3,SPL,SUNXI_GMAC,FAST_MBUS,MMC_SUNXI_SLOT=2
-
Active arm armv7 sunxi - sunxi
INet97F-II sun4i:INET97F_II,SPL
-
+Active arm armv7 sunxi - sunxi
INet_K70HC sun7i:INET_K70HC,SPL
-
Active arm armv7 sunxi - sunxi
Jesurun-Q5
sun4i:JESURUN_Q5,SPL,SUNXI_EMAC,STATUSLED=244
-
Active arm armv7 sunxi - sunxi
K1001L1C sun7i:K1001L1C,SPL
-
Active arm armv7 sunxi - sunxi
Marsboard_A10
sun4i:MARSBOARD_A10,SPL,SUNXI_EMAC,NO_AXP
-
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] sunxi-devel branch updated to 3.13-rc6
Hi All, I've just updated: https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel to 3.13-rc6. Also new is an updated version of the mmc driver (mostly cosmetic fixes to get it ready for upstream) and a sun4i-lradc-keys driver The sunxi-devel branch now contains 3.13-rc6 + the following, which should all go upstream for 3.14: https://github.com/mripard/linux/commits/sunxi-clk-for-3.13 https://github.com/mripard/linux/commits/sunxi-drivers-for-3.14 https://github.com/mripard/linux/commits/sunxi-core-for-3.14 https://github.com/mripard/linux/commits/sunxi-dt-for-3.14 sunxi-bits of: https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/clockevents/next Emilio's "[PATCH v3 00/13] clk: sunxi: add PLL5 and PLL6 support" series Chen's external oscillator work sun4i-ts resisitive touchscreen controller + temp sensor driver sun4i-lradc-keys driver + the following which is not quite ready for 3.14 yet, but people are working hard to get it ready so hopefully we will see some of it in 3.14, and the rest should make 3.15: Emilio's sunxi-clk branch: patches not part of the above set David's and mine sunxi-mmc work Chen's gmac work Oliver's ahci work Arokux' ehci work Note for this to work properly on sun7i and sun5i you also need my sunxi-next u-boot branch: https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next Enjoy, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: Upstreaming sunxi mmc support
Hi, On 01/02/2014 02:09 AM, David Lanzendörfer wrote: Hi Hans, Maxime et al, I've made a first approach to incorporate the changes we've disscussed. I'm not quite done yet. You can have a look at it under: http://git.o2s.ch/?p=linux-next.git;a=shortlog;h=refs/heads/20131224 My recent issue: I appear to be missing certain patchsets which haven't been merged into linux-next yet. Mainly some subfunction for the clock. I always get 0 when I try to round a clock frequency, which of course makes testing of my code impossible. It would be great if someone would take the time and would have a look through the commitlog... Or maybe Maxime? Do you have an idea where the problem with clk_round_rate could come from? Thanks for working on this. I've merged your updated version of the patches into the sunxi-devel branch. That branch has several sunxi-clk commits which are not in -next (and I don't know when they will be send there, Emilio?). With those patches your updated version of the mmc driver works fine for me. I think it would be a good idea for you to use sunxi-devel as a base for your work, you can just checkout: https://github.com/linux-sunxi/linux-sunxi/commit/c213f86956991b20f847dca9846e7cd112032f67 As a start point for further work, that gives you all the bits I believe to be headed for 3.14 + the few extra patches you need from Emilio + your work sofar. I've also taken a quick look at your patches, I've one remark about: https://github.com/linux-sunxi/linux-sunxi/commit/796b36502919bd4327029d0f0b10180af279c72e For newer soc models where the ip-block is unchanged you should use the same compatible string as the first model with that version of the ip-block. IOW for sun5i-a10s and sun7i-a20 the compatible string should be "allwinner,sun5i-a13-mmc" And more in general when making changes to the dts files, please do one commit for each of sun4i, sun5i and sun7i, that will making squashing things together later much easier. Thanks & Regards, Hans p.s. If you run out of time and/or steam please let me know and I can do a v2 of this patch-set if you want me to. In that case, I assume it is ok I add a Signed-off-by: David Lanzendörfer to all the patches ? -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote: > Hi, > > On Fri, Dec 27, 2013 at 7:47 PM, Arend van Spriel wrote: >> On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote: >>> Hi, >>> >>> On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai wrote: Hi, On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai wrote: > Hi, > > On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel > wrote: >> On 12/18/2013 02:12 PM, Hans de Goede wrote: >>> Hi, >>> >>> On 12/18/2013 11:31 AM, Arend van Spriel wrote: On 12/05/2013 10:46 PM, Julian Calaby wrote: > Firstly, are there any plans to support the BCM43362 chipset with the > brcmfmac driver in the near future? Hi Julian, I am working on a patch to support this chip. It is looking promising. Just have to go after a firmware image to be sure. >>> >>> Cool. Do you have a cubietruck? With my latest wip tree: >>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next >> >> No cubietruck here. I googled the term last week because it came up and >> found embeddedcomputer.nl selling it. >> >>> We've mmc/sdio controller support on top of 3.13-rc4, it would be >>> nice if we could also get the wifi and bluetooth to work here. I got the chip to respond to probing. It is BCM43362 for sure. root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device 0xa962 root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor 0x02d0 Vendor ID is Broadcom. Device ID is 43362. But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know if this is normal or not. >> >> There might be three devices/functions. The last digit of the device >> indicates the SDIO function number. Function 1 allows access to F1 >> registers in the SDIO core of the device and F2 is for WLAN >> functionality. F3 could be providing BT functionality, but I am not >> familiar with that part. >> >>> Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline >>> brcmfmac driver. I only tested managed mode. Monitor mode does not work. >>> You can use firmware from CubieTech images. >> >> brcmfmac does not support monitor mode. It does support AP mode and P2P >> modes. >> >>> Things missing: >>> >>> 1. output clock is using default 32KHz from 24M / 750. >>> need to find some place to put clk_set_rate call. >> >> What clock is this? You mean there is a clock output driven by the >> AP6210 module or Cubieboard provides it to the module. > > Cubieboard provides it to the module. > > BCM43362 (WiFi) and BCM20710 (BT) both accept an external 32768 Hz > clock as low power clock. They can also use internal oscillator for > this, so it is optional. But according to BCM20710 datasheet, this > external clock is required to auto-detect the frequency of the main > oscillator if it's not the default 20MHz. On the CubieTruck, it is > 26 MHz. For just WiFi, I think we don't need it. > >>> 2. BCM43362 out-of-band interrupts not supported. >>> OOB interrupt in brcmfmac is set using platform data. >>> Need to put this is board code, or add device tree support. >> >> It would be good to add device tree support so the driver can first look >> for device tree data and have platform data and in-band as backup mechanism. > > I'm not sure how to add support. Add a child node to the SD/MMC > controller, perhaps? I thought SDIO devices were like USB, in > that the system scans the bus and detects them. > >>> Core ID and addresses were found using bcmdhd driver debug output. >>> Arend might want to take a look at the patch: >>> >>> >>> https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865 >> >> I have different addresses from the chip documentation, but my test spin >> went poorly. So much for hardware documentation. I will give these >> values a try. In my patch there is also bcm43362 specific SDIO drive >> strength programming (see attachment). The patch won't apply as my tree >> is a bit different due to some rework in the SDIO part of brcmfmac. So >> you probably need to pick the missing part from it. > > Maybe it's a remarked chip? (is that possible?) > The firmware CubieTech has is for a BCM40181 though. > > Added the drive strength programming by hand. Changed the table variable > name to match the others. Pushed on to my tree. Beware there are some > hacks trying to get BT to work. :p > >> >>> Working tree: >>> >>> https://github.com/wens/linux/tree/wip/sunxi-next-wifi >>> >>> Comments welcome :) >> >> No comment, but: Nice work! > > Thanks. BTW, who should submit the patch? :) Hi Chen-Yu, I confirmed the patch is working with a revision 0 of the device. What chip revision does it give in your log (need to load brcmfmac with module parameter debug=4). Regards, Arend >> Bluetooth still isn't responding. >>> >>> Bluetooth still not working. :( >>> H
Re: [linux-sunxi] Sd card partition for A20 booting...
Hi arete74, Can you tell what problem you are facing while booting android 4.2 over sd card. Regards Punith -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers
Hi,
On 01/02/2014 12:59 PM, Heiko Stübner wrote:
Hi Hans, Dmitry,
Am Donnerstag, 2. Januar 2014, 10:37:47 schrieb Hans de Goede:
Hi,
On 01/01/2014 09:56 PM, Dmitry Torokhov wrote:
Hi Hans,
On Wed, Jan 01, 2014 at 08:30:07PM +0100, Hans de Goede wrote:
+Required properties:
+ - compatible: "allwinner,sun4i-lradc-keys"
+ - reg: mmio address range of the chip
+ - interrupts: interrupt to which the chip is connected
+ - allwinner,chan0-step: step in mV between keys must be 150 or 200
+ - allwinner,chan0-keycodes: array of include/uapi/linux/input.h KEY_
codes>
I think this should be "linux,chan0-keycodes".
Right, because the codes are Linux specific, will fix in v2.
but the property with its "chan0-" thingy would be allwinner-specific if I'm
not mistaken.
Correct, but denoting that this is linux only is more important, so as to
avoid namespace collisions.
Also, instead of inventing yet another vendor-specific property, why not re-use
a button binding similar to gpio-keys like:
lradc: lradc@01c22800 {
compatible = "allwinner,sun4i-lradc-keys";
reg = <0x01c22800 0x100>;
interrupts = <31>;
allwinner,chan0-step = <200>;
#address-cells = <1>;
#size-cells = <0>;
button@0 {
reg = <0>; /* your channel index from above */
linux,code = <115>; /* already used as dt-property */
};
button@1 {
reg = <1>;
linux,code = <114>;
};
Ugh no. Having a vendor specific property which is KISS certainly beats this,
both wrt ease of writing dts files as well as wrt the dts parsing code in the
driver.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: The realistic Cortex-A7 clock frequency limit for Allwinner A20 (CubieBoard2)?
четверг, 2 января 2014 г., 3:11:31 UTC+4 пользователь Siarhei Siamashka написал:
> On Fri, 27 Dec 2013 06:47:42 -0800 (PST)
>
> nils wrote:
>
>
>
> > пятница, 27 декабря 2013 г., 14:56:11 UTC+4 пользователь Oliver Schinagl
> > написал:
>
> > > On 12/25/13 13:28, nils@gmail.com wrote:
>
> > >
>
> > > > With default 1.4V it segfaults.
>
> > >
>
> > > Do you mean you are UNDERvolting it? that seems a little strange ...
>
> > >
>
> >
>
> > Yes,I think that without heatsink, compilation segfaults due to overheating
> > .
>
> >
>
> > 1,008/1.4V - segfaults .
>
> > 1,008/1.275V - gcc compiled ok, takes about 5 hours.
>
> > 1,056/1.325V - system freezes .
>
> > Back to 1,008Gz/1.275V - gcc compiled ok again.
>
> >
>
> > Also i have Mele A100(A10/512) with heatsink, gcc compilation allways
> > segfaults
>
> > on it with any freq ,probably due to overclocked(480) ram.
>
>
>
> It seems like you are either having extremely bad luck (2 bad devices
>
> out of 2 is impressive), or something is really messed up on the
>
> software side.
>
>
>
> I have 4 devices with Allwinner-A10/Allwinner-A20. All of them are
>
> working fine when used with the normal default configuration (the
>
> unmodified linux sunxi-3.4 kernel, sunxi u-boot and fex files).
>
>
>
> --
>
> Best regards,
>
> Siarhei Siamashka
Hardware without box, like cubie, may perform better as it better cooled on
open air. I have tested Mele M3 as is(in box, and without heatsink), so
overheating comes quicker.
Yes, with default 912Mhz/1.4V it probably works ok, but i am not tried this.
For now with 1,008Ghz/1.275V and governor "perfomance", it absolutely stable.
Tried compilation of gcc-gentoo-4.7.3-r1, gcc-linaro-4.6.4, gcc-linaro-4.7.4,
sunxi-3.0, sunxi-3.4 and other code sources with no errors.
Ordered 20x20x10mm heatsink, i think A20 can more when better cooled.
As for A10(Mele A100 with heatsink), my problem was OVERvolting that i used
previously, eg 1.200Ghz/1.65V .
Get it stable with 1.200Ghz/1.5V. No segfaults more.
Tested with sunxi-3.4.75/Gentoo, sunxi-3.0.101/ICS.
Just for information - A10 stable minimal freq/volt combinations i've found on
my hardware :
{.freq = 12, .volt = 1500},
{.freq = 115200, .volt = 1450},
{.freq = 110400, .volt = 1400},
{.freq = 105600, .volt = 1350},
{.freq = 100800, .volt = 1300},
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH] add inet k70hc
On Thu, Jan 02, 2014 at 01:23:22PM +0100, Luc Verhaegen wrote: > Signed-off-by: Luc Verhaegen > --- > sys_config/a20/inet_k70hc.fex | 1008 > + > 1 files changed, 1008 insertions(+), 0 deletions(-) > create mode 100644 sys_config/a20/inet_k70hc.fex Hold off on this, i need to adjust the .fex file for 8188eu. 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/groups/opt_out.
Re: [linux-sunxi] Re: [PATCH 04/10] net: stmmac: sunxi platfrom extensions for GMAC in Allwinner A20 SoC's
Hi Chen, On 24/12/13 03:27, Chen-Yu Tsai wrote: > Srinivas, > > Let's keep platform data as of_data, so SoC compatibles can pass > hardware feature flags for cores that don't support auto-detection. I understand your concern here, But making platform_data as of_data would just open a wide door for other hacky stuff too. So other glue drivers would just use this interface instead, ignoring standard interfaces. Also there would be issues on who takes the priority if the parameters are specified in multiple places. Can't this field/s be one of the variable in the struct stmmac_of_data rather than reusing platform data? > > We can adjust the callbacks as you suggested, and I added a .free > to complement .setup. Driver private data and platform data are > off limits to the callbacks. My version of the callbacks: > > void (*fix_mac_speed)(void *priv, unsigned int speed); > void (*bus_setup)(void __iomem *ioaddr); In reply to your question in last email: bus_setup this is something very specific to ST which configures the bus parameters of AMBA-to-STBUS converter. This register falls inside the memory map of stmmac. > void *(*setup)(struct platform_device *pdev); > void (*free)(struct platform_device *pdev, void *priv); > int (*init)(struct platform_device *pdev, void *priv); > void (*exit)(struct platform_device *pdev, void *priv); > The callbacks to Ok to me, unless Peppe has more comments on this. Thanks, srini > > 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/groups/opt_out.
Re: [linux-sunxi] USB issues in linux-sunxi 3.4.x
I am sorry that I have not respond sooner, but I was quite busy. It seems that it's related only to A20, since Michal could reproduce it on CT, but it seems OK on CB1. I tested it today on CB2 with following versions: v3.4.61-r1 -- broken v3.4.67-r1 -- broken I used RTL8188 dongle for testing. It "sticks" in connected state when disconnected. Reconnecting the device while "stuck" (showed in lsusb) results in kernel oops. If you need further information, I have access to Cubieboard2, Cubietruck and Hackberry boards. Thanks! Dne středa, 6. listopadu 2013 21:09:48 UTC+1 Michal Suchanek napsal(a): > > On 14 October 2013 13:48, EGM > wrote: > > While using sunxi-3.4.43 on Cubieboard2 board, I noticed some odd > behavior > > of USB devices. > > > > For certain devices, it seems like kernel does not register > disconnection of > > that USB device (or registers it, but does not do reset/cleanup for the > > device). So for example, when I connect wifi dongle (RTL8188-based) and > > disconnect it, it will be still shown in lsusb as a device, in iwconfig > as a > > wlan# and so on. What makes the device disappear as expected is removing > the > > kernel module using rmmod. > > > > I talked about it with guys on IRC today (thanks for help), and tested > it > > out of few more versions of kernel. So I can confirm that this happens > in > > 3.4.43-r2, stage/sunxi-3.4 and sunxi-3.4 (not sure about revision right > now, > > but I can retest it using the latest one). I used kernel configuration > shown > > here: http://sprunge.us/SFMD > > > > When using hramrach's wheezy image > > ( > http://dl.linux-sunxi.org/users/hramrach/cubieboard2-linux3.3-SD-card-image/) > > > or just kernel 3.3.0 from his repository > > (https://github.com/hramrach/linux-sunxi/commits/sunxi-3.3-cb2), USB > devices > > works as expected (ie. disconnection is detected and handled properly). > > > > What is really odd is fact, that I am able to workaround this problem > using > > external USB hub (D-Link DUB-H4, enumerates as ActionStar with VID/PID > > 2101:8500 and 2101:8501). When I connect devices to this hub, everything > > works as expected, but when I disconnect the hub from Cubieboard, it > will > > stuck in "connected" state as I described above. When I disconnect the > hub > > and replug it, I got following messages in dmesg: > > > > ehci_irq: port change detect > > <3>hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling... > > <6>usb 3-1: USB disconnect, device number 5 > > <6>usb 3-1.1: USB disconnect, device number 6 > > <6>usb 3-1: new high-speed USB device number 7 using sw-ehci > > <6>hub 3-1:1.0: USB hub found > > <6>hub 3-1:1.0: 5 ports detected > > <6>usb 3-1.1: new high-speed USB device number 8 using sw-ehci > > <6>generic-usb 0003:2101:8501.0003: hiddev0,hidraw0: USB HID v1.11 > Device > > [Action Star USB HID] on usb-sw-ehci-1.1/input0 > > It appears that port change does not get delivered for the AW EHCI > controller ports (but works for OHCI - usb1 devices). > > The hub manages its ports fine so the port change gets delivered for > those. I can reproduce on CT with an USB Ethernet (high-spped) but not > with an USB serial convertor (full speed). 3.4.67+ #6 SMP PREEMPT Sun > Nov 3 11:50:44 CET 2013 armv7l GNU/Linux > > It's not broken on cb1 3.4.61+ #15 PREEMPT Tue Sep 17 19:11:17 CEST > 2013 armv7l GNU/Linux > > > Thanks > > Michal > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH] add inet k70hc
Signed-off-by: Luc Verhaegen --- sys_config/a20/inet_k70hc.fex | 1008 + 1 files changed, 1008 insertions(+), 0 deletions(-) create mode 100644 sys_config/a20/inet_k70hc.fex diff --git a/sys_config/a20/inet_k70hc.fex b/sys_config/a20/inet_k70hc.fex new file mode 100644 index 000..66fd3cc --- /dev/null +++ b/sys_config/a20/inet_k70hc.fex @@ -0,0 +1,1008 @@ +[product] +version = "100" +machine = "K701HC" + +[platform] +eraseflag = 1 + +[target] +boot_clock = 912 +dcdc2_vol = 1400 +dcdc3_vol = 1250 +ldo2_vol = 3000 +ldo3_vol = 2800 +ldo4_vol = 2800 +power_start = 0 +storage_type = -1 + +[clock] +pll3 = 297 +pll4 = 300 +pll6 = 600 +pll7 = 297 +pll8 = 336 + +[card_boot] +logical_start = 40960 +sprite_gpio0 = + +[card0_boot_para] +card_ctrl = 0 +card_high_speed = 1 +card_line = 4 +sdc_d1 = port:PF00<2><1> +sdc_d0 = port:PF01<2><1> +sdc_clk = port:PF02<2><1> +sdc_cmd = port:PF03<2><1> +sdc_d3 = port:PF04<2><1> +sdc_d2 = port:PF05<2><1> + +[card2_boot_para] +card_ctrl = 2 +card_high_speed = 1 +card_line = 4 +sdc_cmd = port:PC06<3><1> +sdc_clk = port:PC07<3><1> +sdc_d0 = port:PC08<3><1> +sdc_d1 = port:PC09<3><1> +sdc_d2 = port:PC10<3><1> +sdc_d3 = port:PC11<3><1> + +[twi_para] +twi_port = 0 +twi_scl = port:PB00<2> +twi_sda = port:PB01<2> + +[uart_para] +uart_debug_port = 0 +uart_debug_tx = port:PB22<2><1> +uart_debug_rx = port:PB23<2><1> + +[uart_force_debug] +uart_debug_port = 0 +uart_debug_tx = port:PF02<4><1> +uart_debug_rx = port:PF04<4><1> + +[jtag_para] +jtag_enable = 0 +jtag_ms = port:PB14<3> +jtag_ck = port:PB15<3> +jtag_do = port:PB16<3> +jtag_di = port:PB17<3> + +[pm_para] +standby_mode = 1 + +[dram_para] +dram_baseaddr = 0x4000 +dram_clk = 384 +dram_type = 3 +dram_rank_num = -1 +dram_chip_density = -1 +dram_io_width = -1 +dram_bus_width = -1 +dram_cas = 9 +dram_zq = 0x7f +dram_odt_en = 0 +dram_size = -1 +dram_tpr0 = 0x42d899b7 +dram_tpr1 = 0xa090 +dram_tpr2 = 0x22a00 +dram_tpr3 = 0x0 +dram_tpr4 = 0x1 +dram_tpr5 = 0x0 +dram_emr1 = 0x4 +dram_emr2 = 0x10 +dram_emr3 = 0x0 + +[mali_para] +mali_used = 1 +mali_clkdiv = 1 + +[emac_para] +emac_used = 0 +emac_rxd3 = port:PA00<2> +emac_rxd2 = port:PA01<2> +emac_rxd1 = port:PA02<2> +emac_rxd0 = port:PA03<2> +emac_txd3 = port:PA04<2> +emac_txd2 = port:PA05<2> +emac_txd1 = port:PA06<2> +emac_txd0 = port:PA07<2> +emac_rxclk = port:PA08<2> +emac_rxerr = port:PA09<2> +emac_rxdV = port:PA10<2> +emac_mdc = port:PA11<2> +emac_mdio = port:PA12<2> +emac_txen = port:PA13<2> +emac_txclk = port:PA14<2> +emac_crs = port:PA15<2> +emac_col = port:PA16<2> +emac_reset = port:PA17<1> + +[twi0_para] +twi0_used = 1 +twi0_scl = port:PB00<2> +twi0_sda = port:PB01<2> + +[twi1_para] +twi1_used = 1 +twi1_scl = port:PB18<2> +twi1_sda = port:PB19<2> + +[twi2_para] +twi2_used = 1 +twi2_scl = port:PB20<2> +twi2_sda = port:PB21<2> + +[uart_para0] +uart_used = 1 +uart_port = 0 +uart_type = 2 +uart_tx = port:PB22<2><1> +uart_rx = port:PB23<2><1> + +[uart_para1] +uart_used = 0 +uart_port = 1 +uart_type = 8 +uart_tx = port:PA10<4><1> +uart_rx = port:PA11<4><1> +uart_rts = port:PA12<4><1> +uart_cts = port:PA13<4><1> +uart_dtr = port:PA14<4><1> +uart_dsr = port:PA15<4><1> +uart_dcd = port:PA16<4><1> +uart_ring = port:PA17<4><1> + +[uart_para2] +uart_used = 0 +uart_port = 2 +uart_type = 4 +uart_tx = port:PI18<3><1> +uart_rx = port:PI19<3><1> +uart_rts = port:PI16<3><1> +uart_cts = port:PI17<3><1> + +[uart_para3] +uart_used = 0 +uart_port = 3 +uart_type = 4 +uart_tx = port:PH00<4><1> +uart_rx = port:PH01<4><1> +uart_rts = port:PH02<4><1> +uart_cts = port:PH03<4><1> + +[uart_para4] +uart_used = 0 +uart_port = 4 +uart_type = 2 +uart_tx = port:PH04<4><1> +uart_rx = port:PH05<4><1> + +[uart_para5] +uart_used = 0 +uart_port = 5 +uart_type = 2 +uart_tx = port:PH06<4><1> +uart_rx = port:PH07<4><1> + +[uart_para6] +uart_used = 0 +uart_port = 6 +uart_type = 2 +uart_tx = port:PA12<3><1> +uart_rx = port:PA13<3><1> + +[uart_para7] +uart_used = 0 +uart_port = 7 +uart_type = 2 +uart_tx = port:PA14<3><1> +uart_rx = port:PA15<3><1> + +[spi0_para] +spi_used = 0 +spi_cs_bitmap = 1 +spi_cs0 = port:PI10<2> +spi_cs1 = port:PI14<2> +spi_sclk = port:PI11<2> +spi_mosi = port:PI12<2> +spi_miso = port:PI13<2> + +[spi1_para] +spi_used = 0 +spi_cs_bitmap = 1 +spi_cs0 = port:PA00<3> +spi_cs1 = port:PA04<3> +spi_sclk = port:PA01<3> +spi_mosi = port:PA02<3> +spi_miso = port:PA03<3> + +[spi2_para] +spi_used = 0 +spi_cs_bitmap = 1 +spi_cs0 = port:PC19<3> +spi_cs1 = port:PB13<2> +spi_sclk = port:PC20<3> +spi_mosi = port:PC21<3> +spi_miso = port:PC22<3> + +[spi3_para] +spi_used = 0 +spi_cs_bitmap = 1 +spi_cs0 = port:PA05<3> +spi_cs1 = port:PA09<3> +spi_sclk = port:PA06<3> +spi_mosi = port:PA07<3> +spi_miso = port:PA08<3> + +[ctp_para] +ctp_used = 1 +ctp_twi_id = 2 +ctp_twi_addr = 0x40 +ctp_screen_max_x = 1024 +ctp_screen_max_y = 600 +ctp_revert_x_flag = 0 +ctp_revert_y_flag = 0 +ctp_exchange_x_y_flag = 0 +ctp_cob_gslX680 = 4 +ctp_int_port = port:PH21<6> +ctp_wakeup = port:PB13<1><1> +ctp
[linux-sunxi] [PATCH] sunxi: Add Inet K70HC device
Signed-off-by: Luc Verhaegen
---
board/sunxi/Makefile |1 +
board/sunxi/dram_inet_k70hc.c | 31 +++
boards.cfg|1 +
3 files changed, 33 insertions(+), 0 deletions(-)
create mode 100644 board/sunxi/dram_inet_k70hc.c
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 7fefdf0..f274a1d 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_HACKBERRY) += dram_hackberry.o
obj-$(CONFIG_A7HD) += dram_sun4i_360_1024_iow8.o
obj-$(CONFIG_INTERRA3) += dram_mk802ii_a20.o
obj-$(CONFIG_INET97F_II) += dram_sun4i_408_512.o
+obj-$(CONFIG_INET_K70HC) += dram_inet_k70hc.o
obj-$(CONFIG_JESURUN_Q5) += dram_sun4i_312_1024_iow8.o
obj-$(CONFIG_K1001L1C) += dram_a20_olinuxino_m.o
obj-$(CONFIG_MEFAFEIS_A08) += dram_megafeis_a08.o
diff --git a/board/sunxi/dram_inet_k70hc.c b/board/sunxi/dram_inet_k70hc.c
new file mode 100644
index 000..d5ddc13
--- /dev/null
+++ b/board/sunxi/dram_inet_k70hc.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include
+#include
+
+static struct dram_para dram_para = {
+ .clock = 384,
+ .type = 3,
+ .rank_num = 1,
+ .density = 4096,
+ .io_width = 16,
+ .bus_width = 32,
+ .cas = 9,
+ .zq = 0x12331a7f,
+ .odt_en = 0,
+ .size = 1024,
+ .tpr0 = 0x42d899b7,
+ .tpr1 = 0xa090,
+ .tpr2 = 0x22a00,
+ .tpr3 = 0,
+ .tpr4 = 1,
+ .tpr5 = 0,
+ .emr1 = 0x4,
+ .emr2 = 0x10,
+ .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+ return dramc_init(&dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index 7eeb17a..eda05de 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -380,6 +380,7 @@ Active arm armv7 sunxi -
sunxi
Active arm armv7 sunxi - sunxi
Hyundai_A7HD sun4i:A7HD,SPL
-
Active arm armv7 sunxi - sunxi
Interra-3
sun7i:INTERRA3,SPL,SUNXI_GMAC,FAST_MBUS,MMC_SUNXI_SLOT=2
-
Active arm armv7 sunxi - sunxi
INet97F-II sun4i:INET97F_II,SPL
-
+Active arm armv7 sunxi - sunxi
INet_K70HC sun7i:INET_K70HC,SPL
-
Active arm armv7 sunxi - sunxi
Jesurun-Q5
sun4i:JESURUN_Q5,SPL,SUNXI_EMAC,STATUSLED=244
-
Active arm armv7 sunxi - sunxi
K1001L1C sun7i:K1001L1C,SPL
-
Active arm armv7 sunxi - sunxi
Marsboard_A10
sun4i:MARSBOARD_A10,SPL,SUNXI_EMAC,NO_AXP
-
--
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/groups/opt_out.
Re: [linux-sunxi] ARM: PSCI: fix PSCI DT nodes generation failure
Hi, On 01/02/2014 06:42 AM, Ma Haijun wrote: Hi, This patch fix non-boot CPU bringing up failure due to lack of PSCI node, which is reported by Tim Fletcher. It is patched against the sunxi-next branch of https://github.com/jwrdegoede/u-boot-sunxi.git Thanks, added to my sunxi-next branch and pushed to the above repository. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v2 4/4] ARM: dts: sun7i: Add lradc node
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 9 +
arch/arm/boot/dts/sun7i-a20.dtsi| 7 +++
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index 0ee2641..2c9a38f 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -13,6 +13,7 @@
/dts-v1/;
/include/ "sun7i-a20.dtsi"
+#include
/ {
model = "Olimex A20-Olinuxino Micro";
@@ -86,6 +87,14 @@
};
};
+ lradc: lradc@01c22800 {
+ allwinner,chan0-step = <200>;
+ linux,chan0-keycodes = ;
+ status = "okay";
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 68e825a..3484275 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -531,6 +531,13 @@
interrupts = <0 24 1>;
};
+ lradc: lradc@01c22800 {
+ compatible = "allwinner,sun4i-lradc-keys";
+ reg = <0x01c22800 0x100>;
+ interrupts = <0 31 4>;
+ status = "disabled";
+ };
+
sid: eeprom@01c23800 {
compatible = "allwinner,sun7i-a20-sid";
reg = <0x01c23800 0x200>;
--
1.8.4.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v2 1/4] input: Add new sun4i-lradc-keys driver
Allwinnner sunxi SoCs have a low resolution adc (called lradc) which is
specifically designed to have various (tablet) keys (ie home, back, search,
etc). attached to it using a resistor network. This adds a driver for this.
There are 2 channels, currently this driver only supports chan0 since there
are no boards known to use chan1. The devicetree properties are already
prefixed with chan0 as preparation for chan1 support in the future.
This has been tested on an olimex a10s-olinuxino-micro, a13-olinuxino, and
a20-olinuxino-micro.
Signed-off-by: Hans de Goede
---
.../devicetree/bindings/input/sun4i-lradc-keys.txt | 22 ++
drivers/input/keyboard/Kconfig | 10 +
drivers/input/keyboard/Makefile| 1 +
drivers/input/keyboard/sun4i-lradc-keys.c | 243 +
4 files changed, 276 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
create mode 100644 drivers/input/keyboard/sun4i-lradc-keys.c
diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
new file mode 100644
index 000..7801264
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
@@ -0,0 +1,22 @@
+Allwinner sun4i low res adc attached tablet keys
+
+
+Required properties:
+ - compatible: "allwinner,sun4i-lradc-keys"
+ - reg: mmio address range of the chip
+ - interrupts: interrupt to which the chip is connected
+ - allwinner,chan0-step: step in mV between keys must be 150 or 200
+ - linux,chan0-keycodes: array of dt-bindings/input/input.h KEY_ codes
+
+Example:
+
+#include
+
+ lradc: lradc@01c22800 {
+ compatible = "allwinner,sun4i-lradc-keys";
+ reg = <0x01c22800 0x100>;
+ interrupts = <31>;
+ allwinner,chan0-step = <200>;
+ linux,chan0-keycodes = ;
+ };
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index bb174c1..d95e6e4 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -544,6 +544,16 @@ config KEYBOARD_STMPE
To compile this driver as a module, choose M here: the module will be
called stmpe-keypad.
+config KEYBOARD_SUN4I_LRADC
+ tristate "Allwinner sun4i low res adc attached tablet keys support"
+ depends on ARCH_SUNXI
+ help
+ This selects support for the Allwinner low res adc attached tablet
+ keys found on Allwinner sunxi SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sun4i-lradc-keys.
+
config KEYBOARD_DAVINCI
tristate "TI DaVinci Key Scan"
depends on ARCH_DAVINCI_DM365
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index a699b61..f3265bd 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_KEYBOARD_SH_KEYSC) += sh_keysc.o
obj-$(CONFIG_KEYBOARD_SPEAR) += spear-keyboard.o
obj-$(CONFIG_KEYBOARD_STMPE) += stmpe-keypad.o
obj-$(CONFIG_KEYBOARD_STOWAWAY)+= stowaway.o
+obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
obj-$(CONFIG_KEYBOARD_SUNKBD) += sunkbd.o
obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c
b/drivers/input/keyboard/sun4i-lradc-keys.c
new file mode 100644
index 000..5c55e17
--- /dev/null
+++ b/drivers/input/keyboard/sun4i-lradc-keys.c
@@ -0,0 +1,243 @@
+/*
+ * Allwinner sun4i low res adc attached tablet keys driver
+ *
+ * Copyright (C) 2014 Hans de Goede
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program 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.
+ */
+
+/*
+ * Allwinnner sunxi SoCs have a lradc which is specifically designed to have
+ * various (tablet) keys (ie home, back, search, etc). attached to it using
+ * a resistor network. This driver is for the keys on such boards.
+ *
+ * There are 2 channels, currently this driver only supports chan0 since there
+ * are no boards known to use chan1. The devicetree properties are already
+ * prefixed with chan0 as preparation for chan1 support in the future.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LRADC_CTRL 0x00
+#define LRADC_INTC 0x04
+#define LRA
[linux-sunxi] [PATCH v2 2/4] ARM: dts: sun4i: Add lradc node
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun4i-a10.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 502f3e2..88f119a 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -447,6 +447,13 @@
interrupts = <24>;
};
+ lradc: lradc@01c22800 {
+ compatible = "allwinner,sun4i-lradc-keys";
+ reg = <0x01c22800 0x100>;
+ interrupts = <31>;
+ status = "disabled";
+ };
+
sid: eeprom@01c23800 {
compatible = "allwinner,sun4i-sid";
reg = <0x01c23800 0x10>;
--
1.8.4.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v2 3/4] ARM: dts: sun5i: Add lradc node
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 8
arch/arm/boot/dts/sun5i-a10s.dtsi| 7 +++
arch/arm/boot/dts/sun5i-a13-olinuxino.dts| 8
arch/arm/boot/dts/sun5i-a13.dtsi | 7 +++
4 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index e53fb12..d93318a 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -13,6 +13,7 @@
/dts-v1/;
/include/ "sun5i-a10s.dtsi"
+#include
/ {
model = "Olimex A10s-Olinuxino Micro";
@@ -75,6 +76,13 @@
};
};
+ lradc: lradc@01c22800 {
+ allwinner,chan0-step = <200>;
+ linux,chan0-keycodes = ;
+ status = "okay";
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 34dd303..8775bad 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -404,6 +404,13 @@
reg = <0x01c20c90 0x10>;
};
+ lradc: lradc@01c22800 {
+ compatible = "allwinner,sun4i-lradc-keys";
+ reg = <0x01c22800 0x100>;
+ interrupts = <31>;
+ status = "disabled";
+ };
+
sid: eeprom@01c23800 {
compatible = "allwinner,sun4i-sid";
reg = <0x01c23800 0x10>;
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index ab566f7..4e99f43 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -13,6 +13,7 @@
/dts-v1/;
/include/ "sun5i-a13.dtsi"
+#include
/ {
model = "Olimex A13-Olinuxino";
@@ -55,6 +56,13 @@
};
};
+ lradc: lradc@01c22800 {
+ allwinner,chan0-step = <200>;
+ linux,chan0-keycodes = ;
+ status = "okay";
+ };
+
uart1: serial@01c28400 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins_b>;
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 264cfa4..90c1ed3 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -362,6 +362,13 @@
reg = <0x01c20c90 0x10>;
};
+ lradc: lradc@01c22800 {
+ compatible = "allwinner,sun4i-lradc-keys";
+ reg = <0x01c22800 0x100>;
+ interrupts = <31>;
+ status = "disabled";
+ };
+
sid: eeprom@01c23800 {
compatible = "allwinner,sun4i-sid";
reg = <0x01c23800 0x10>;
--
1.8.4.2
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v2 0/4] input: Add new sun4i-lradc-keys driver
Hi Dimitri et al, Here is v2 of the sun4i-lradc-keys driver, changes since v1: - Use include/dt-bindings/input/input.h - Rename the keycodes property to linux,chan0-keycodes Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Explain the contents of bootloader...
Hi i flashed the cubieboard image to sd card from this link. https://docs.google.com/file/d/0B-bAEPML8fwlUFd5OHVOaFJIRmc/edit. then in Volumn(bootlaoder) folder of sdcard i got fallowing binaries. 1.boot.axf 2.boot_signature.axf 3.drv_hdmi.drv 4.font32.sft 5.magic.bin 6.prvt.axf 7.script.bin 8.boot.ini 9.drv_de.drv 10.font24.sft 11.linux -> linux.bmp linux.ini u-boot.bin (sub contents). 12.os_show ->bat0.bmp bat2.bmp bat5.bmp bat8.bmp bempty.bmp full.bmplinux2.bmp melis2.bmp wince1.bmp bat10.bmp bat3.bmp bat6.bmp bat9.bmp bootlogo.bmp head.bmplow_pwr.bmp startup.bmp wince2.bmp bat1.bmp bat4.bmp bat7.bmp battery.bmp empty.bmp linux1.bmp melis1.bmp tail.bmp 13.script0.bin 14.sprite.axf Out of these i know script.bin , and u-boot.bin (but i flashed to /dev/sdc ). Kindly tell what will be purpose of remaining binaries. and tell me what will be difference between boot0 ,boot1 and sunxi-spl.bin ,u-boot.bin. Regards Punith -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers
Hi, On 01/01/2014 09:56 PM, Dmitry Torokhov wrote: Hi Hans, On Wed, Jan 01, 2014 at 08:30:07PM +0100, Hans de Goede wrote: +Required properties: + - compatible: "allwinner,sun4i-lradc-keys" + - reg: mmio address range of the chip + - interrupts: interrupt to which the chip is connected + - allwinner,chan0-step: step in mV between keys must be 150 or 200 + - allwinner,chan0-keycodes: array of include/uapi/linux/input.h KEY_ codes I think this should be "linux,chan0-keycodes". Right, because the codes are Linux specific, will fix in v2. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: [PATCH 3/4] ARM: dts: sun5i: Add lradc node
Hi,
On 01/01/2014 08:45 PM, Andrew Lunn wrote:
On Wed, Jan 01, 2014 at 08:30:09PM +0100, Hans de Goede wrote:
Signed-off-by: Hans de Goede
---
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 7 +++
arch/arm/boot/dts/sun5i-a10s.dtsi| 7 +++
arch/arm/boot/dts/sun5i-a13-olinuxino.dts| 7 +++
arch/arm/boot/dts/sun5i-a13.dtsi | 7 +++
4 files changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index e53fb12..c32162e 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -75,6 +75,13 @@
};
};
+ lradc: lradc@01c22800 {
+ allwinner,chan0-step = <200>;
+ /* KEY_VOLUMEUP VOLUMEDOWN MENU ENTER HOME */
+ allwinner,chan0-keycodes = <115 114 139 28 102>;
Hi Hans
You might want to consider using
arch/arm/boot/dts/include/dt-bindings/input/input.h
and then you could have the node:
+ lradc: lradc@01c22800 {
+ allwinner,chan0-step = <200>;
+ allwinner,chan0-keycodes = ;
which is much more readable.
Ah, I did not know about that include. Good tip, will fix this in v2.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH 3.4] sunxi: Enable ZONE_DMA for sun4i and sun5i (dma_zone_size=256MB)
Hi, On 01/02/2014 12:57 AM, Siarhei Siamashka wrote: Maybe just send a mail to the relevant upstream list explaining we've an ip block which (seems) to be limited to dma below 256MB and needs cma, so we want a cma block below 256MB, but we don't want to set the DMA_ZONE for the entire system to that as other ip blocks in the SoC don't have this limit, and see what kind of solutions get suggested ? CMA is quite flexible, and it is possible to have multiple CMA areas in different places. So that we can have a dedicated area for cedar below 256MB, and separate CMA area somewhere else for disp and g2d. DMA_ZONE is just one of the ways to specify an upper limit. And because sun7i was already using DMA_ZONE (for whatever reason), there is some additional value in unification between sun4i/sun5i/sun7i. Ok. And by the way, the 256MB cedar addressing limitation got confirmed. It just seems to be inconsistent for different supported media formats: http://irclog.whitequark.org/linux-sunxi/2013-12-27#5993708; So I have not been fighting with windmills after all ;) Note I realize we won't have cedar support upstream any time soon, Why not? Cedar appears to be a relatively simple hardware and needs a relatively simple driver. This of course does not make the reverse engineering achievement less impressive. Oh, I'm all in favor of getting cedar support upstream, I was just thinking that since we also lack any display output capability atm, getting it upstream would be something to do later. but it seems like a good idea to get this discussion started, and maybe a solution created, well before we even start looking into upstream cedar support. The biggest design problem of the current allwiner cedar kernel driver is total lack of any security. Now an interesting question is what kind of frameworks are mandatory in the kernel for safely sharing the buffers between different drivers and the userspace. And whether they are going to skyrocket the complexity and hinder performance. I think the cedar is best exported to userspace as a v4l2 mem 2 mem device. the v4l2 api is quite efficient wrt sending large amounts of buffers. And the v4l2 core has code to make v4l2 buffers accessible through dmabuf, so that they could for example be shared with the gpu. But first we can do a better VDPAU integration with X11 for sunxi-3.4 kernel. So that the end users can become really happy sooner. And this kind of research/prototyping work is not a wasted effort anyway. Agreed. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] fails to get TouchScreen ft5x_ts working on CB2/A20
在 2014年1月1日星期三UTC+8下午4时37分03秒，Carlo Caione写道： > > On Wed, Jan 1, 2014 at 8:10 AM, Patrick Wood > > > wrote: > > I'm thinking you may need to remove the "IRQF_TRIGGER_FALLING |" for the > > A20. > > Right, no DTS for 3.4. > Thanks for your help. Just like you said, ft5x_ts driver works without irq mod "IRQF_TRIGGER_FALLING' on CB2. And I do my test (suggested by Patrick in the cubieforum thread) on CB1, clicking works as well. My testing lab: - CB1(A10) and CB2(A20) - kernel pat-3.4.43 - touchscreen ft5406 (9.7 inch) -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v3 3/5] ARM: dts: sun7i: external clock outputs
On Thu, Jan 02, 2014 at 10:41:23AM +0800, Chen-Yu Tsai wrote: > Hi, > > On Thu, Jan 2, 2014 at 7:10 AM, Maxime Ripard > > On Wed, Jan 01, 2014 at 10:30:48AM +0800, Chen-Yu Tsai wrote: > >> This commit adds the two external clock outputs available on A20 to > >> its device tree. A dummy fixed factor clock is also added to serve as > >> the first input of the clock outputs, which according to AW's A20 user > >> manual, is the 24MHz oscillator divided by 750. > >> > >> Signed-off-by: Chen-Yu Tsai > > > > I'm ok with this patch, but I'll let Emilio and Mike give their > > opinion on the driver before merging it. > > The driver has not changed since v1. > Mike merged it via Emilio's pull request. Ah, right, I forgot about this. I just merged this patch as well. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
