[linux-sunxi] Re: [PATCH v2] ARM: dts: sun8i: Add dts file for the NanoPi NEO SBC
Hi James, [auto build test ERROR on mripard/sunxi/for-next] [also build test ERROR on v4.8-rc5 next-20160825] [cannot apply to robh/for-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on] [Check https://git-scm.com/docs/git-format-patch for more information] url: https://github.com/0day-ci/linux/commits/James-Pettigrew/ARM-dts-sun8i-Add-dts-file-for-the-NanoPi-NEO-SBC/20160905-085509 base: https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git sunxi/for-next config: arm-aspeed_g5_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> Error: arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts:65.21-22 syntax error FATAL ERROR: Unable to parse input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- 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. .config.gz Description: Binary data
[linux-sunxi] Re: Some discussion about A64 clocks regulators support
On 26/08/16 22:18, maxime.ripard wrote: > On Thu, Aug 25, 2016 at 12:55:44AM +0100, André Przywara wrote: >> On 24/08/16 20:28, maxime.ripard wrote: >> >> Hi, >> >>> On Sun, Aug 14, 2016 at 06:16:16PM +0800, Icenowy Zheng wrote: Hi, I currently want to work on more peripherals on A64. However, many features needs clocks and regulators support. Maxime have sent out a series of clock driver based on sunxi-ng, and Andre sent out a RFC series of clock driver based on firmware-based SCPI. It's said that SCPI can also hold regulators. Here're some questions: - Can SCPI handle all the functions on AXP803? Or can a private protocol be used to handle the other functions that SCPI do not support? >>> >>> SCPI is defined here: >>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922g/index.html >>> >>> Basically, it supports: >>> - Clocks >>> - Regulators (named power supplies) >>> - Resets? (seems like we could implement them as device power states) >>> - DVFS >>> - Sensors (for voltage, current, temperature, energy and power) >>> >>> However, the AXP803 has the following features: >>> - Regulators: ok >>> - GPIOs: not supported >>> - Power supplies (the Linux ones, ie which power source is connected >>> to the PMIC, the voltage, current they deliver, etc.): not supported >> >> Why can't we model this with some sensors? Since you mention voltage and >> current > > There's really more to it. We need maximum, minimum and current > voltages and current, if the power supply is connected or not, etc. > >>> - Battery Charger: not supported >>> - VBUS monitoring: not supported >> >> Both look like sensors to me. Energy and voltage. > > Again, this is not just a sensor. The battery charger can adjust the > charge voltage and current, and the thresholds it uses to switch > between the various charging modes (constant current, constant > voltage). I think there is a misunderstanding here. I don't suggest to model the AXP through SCPI in a way that covers every kind of functionality that the AXP offers. In fact I never considered to let Linux take care of charging the battery, for instance. If I understand the Allwinner design idea correctly, charging is taken care of in firmware (arisc in their case, but could be ATF as well in our case). > And the same thing goes for VBUS. We want to adjust the current limit > drawn on VBUS, but we also use the PMIC to... > >> >>> - ADCs: I guess that could fall in the sensors category >>> - Timers: not supported >>> - IRQs for all of the above: as far as I understand, SCPI is on the >>> kernel initiative, so that wouldn't work (but I might very well be >>> wrong on this one) >> >> SCPI normally uses a mailbox, which allows perfect asynchronous >> communication from both sides. With the current implementation (not >> using the actual mailbox, but SMC calls) the lack of IRQs is sadly true, >> although I could envision (ab-)using some interrupt (for instance the >> mailbox one) for ATF to tell Linux about updates. And SCPI supports >> sensor alerts using those asynchronous notifications. > > ... get an interrupt when VBUS changes in USB OTG, faster than the > GPIO polling to reduce the possible damages. So interrupts are > mandatory. If this is really critical, wouldn't firmware be a better place to deal with this? If we configure an SPI to be taken to EL3, then ATF would be able to immediately react to it, without any possible delay that (the non-RT capable) Linux has to fight with. >>> So even though we might ignore some of them (I'm not seeing the >>> relevance of implementing the timers support for example), some >>> critical features already used are missing. >>> - Which one will be more easy to implement? (I think it's the kernel-side drivers, as there're mature frameworks in the kernel now) >>> >>> We even have most of the infrastructure thanks to the previous PMIC we >>> support, so it should be rather easy to get in the kernel. >>> - Is it really valuable for a generalized driver? (As different Allwinner SoCs features usually different IP blocks) >>> >>> I guess it's just moving the same stuff to different locations: either >>> in the kernel or in the firmware. Doing it in the kernel would be at >>> almost no cost, it is yet to be entirely implemented in the firmware >>> (including the missing parts of the spec). >> >> So yes, technically SCPI does not cover every feature that the AXP >> provides, but I am quite wary of exposing this chip to Linux - since one >> can play really nasty tricks with it, probably frying a board easily. > > There will always be easy damage to a board. I mean, you can even fry > a board only by poking at the wrong GPIO through sysfs (first hand > experience). The only user you have here is the kernel itself. > > And if you expose all these features to Linux (that we want!), you'll > have exactly the same attack surfac
Re: [linux-sunxi] [PATCH 3/7] drm/sun4i: Add SAT and DRC drivers
> "Maxime" == Maxime Ripard writes: Hi, > The A33 pipeline also has some new components called SAT and DRC. Even > though their exact features and programming model is not known (or > documented), they need to be clocked for the pipeline to carry the video > signal all the way. > Add minimal drivers for those that just claim the needed resources for the > pipeline to operate properly. > Signed-off-by: Maxime Ripard > --- > .../bindings/display/sunxi/sun4i-drm.txt | 37 +++ > drivers/gpu/drm/sun4i/Makefile | 3 +- > drivers/gpu/drm/sun4i/sun6i_drc.c | 117 > + > drivers/gpu/drm/sun4i/sun8i_sat.c | 105 ++ > 4 files changed, 261 insertions(+), 1 deletion(-) > create mode 100644 drivers/gpu/drm/sun4i/sun6i_drc.c > create mode 100644 drivers/gpu/drm/sun4i/sun8i_sat.c > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > index d467ea93ac08..87c3c8dd34cb 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -51,6 +51,43 @@ Required properties: >second the block connected to the TCON channel 1 (usually the TV >encoder) > +SAT > +--- > + > +The SAT, found in the A33, allows to do some color correction. > + > +Required properties: > + - compatible: value must be one of: > +* allwinner,sun8i-a33-sat > + - reg: base address and size of the memory-mapped region. > + - clock: phandles to bus clock feeding the SAT > + - resets: phandles to the reset line driving the SAT > + > +- ports: A ports node with endpoint definitions as defined in > + Documentation/devicetree/bindings/media/video-interfaces.txt. The > + first port should be the input endpoints, the second one the outputs > + > +DRC > +--- > + > +The DRC, found in the latest Allwinner SoCs (A31, A23, A33), allows to > +do some backlight control to enhance the power consumption. 'Enhance the power consumption'? That doesn't sound like something you would want ;) Presumably it is something to allow you to save power by dynamically adjusting LCD backlight and pixel brightness/contrast depending on screen content? I believe this is typically called content adaptive backlight control: https://www.ecnmag.com/article/2010/04/content-adaptive-lcd-backlight-control You spell out what DRC and SAT stands for in the driver source code, perhaps it also makes sense to do it here? Perhaps rewording it to something like this is clearer: .. allows to dynamically adjust pixel brightness/contrast based on histogram measurements for LCD content adaptive backlight control. -- Bye, Peter Korsgaard -- 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] Converting script.bin to device tree file
I think there is a tool from Allwinner in their more recent releases for mapping fex to device tree. In here somewhere... https://gitlab.com/pine64-android/tools/tree/master when you go through the pack step it prints out a bunch of messages on how it is doing the mapping. I have not looked at the tool, I just noticed the messages it was printing. Complete build instructions for A64 Android https://gitlab.com/pine64-android/manifest/wikis/home On Sun, Sep 4, 2016 at 1:35 PM, Saurabh Jain wrote: >> > Is there a straightforward way to convert a script.bin file to a device >> > tree file? Any HOWTO that maps the various options? > > > We at least need a HOWTO mapping script.bin options to device tree > constructs. I am going to start one... because an unanswered question is an > opportunity to do something. > >> >> > Should I first be experimenting with the sunxi Uboot instead of >> > Mainline? > > > u-boot-sunxi worked. It was almost annoyingly easy. I just needed gcc > gnueabihf 4.x installed first. > >> >> > My device has an AXP152 paired with an A20. Looking at Mainline U-boot, >> > this is an unexpected combination. >> >> This is the first time I've heard of this weird pairing yes, but it should >> work with mainline u-boot, >> just add CONFIG_AXP152_POWER=y to your defconfig. > > > AXP_152 worked in mainline u-boot rather easily. It was the SD card that I > couldn't get working. Strange, because that must obviously work for > _everyone_ else for mainline u-boot to be of any use to anyone. > > SD card worked quite smoothly in u-boot-sunxi. Will try and make nand work > now. > >> >> > What is a good defconfig and dts file to begin work with, with this >> > combination? >> >> None, you're the first... > > > Copied the Cubietruck board.cfg entry and made some changes. Modified the > cubietruck dram file. And done! > >> >> > I've been using the CubieTruck defconfig and dts file so far. I copied >> > over and created a new dts file, which I've been mucking around with (and >> > only making things worse). >> >> Cubietruck is likely as good a start as any, and sorry no fex -> dts tool, >> it is usually just a matter of manually copy and pasting the right >> bits together to get a dts. > > > As mentioned above, we still need a guide that maps between script.bin and > the rather confusing dts file format. > > -- > 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] Converting script.bin to device tree file
> > > Is there a straightforward way to convert a script.bin file to a device > tree file? Any HOWTO that maps the various options? > We at least need a HOWTO mapping script.bin options to device tree constructs. I am going to start one... because an unanswered question is an opportunity to do something. > > Should I first be experimenting with the sunxi Uboot instead of > Mainline? > u-boot-sunxi worked. It was almost annoyingly easy. I just needed gcc gnueabihf 4.x installed first. > > My device has an AXP152 paired with an A20. Looking at Mainline U-boot, > this is an unexpected combination. > > This is the first time I've heard of this weird pairing yes, but it should > work with mainline u-boot, > just add CONFIG_AXP152_POWER=y to your defconfig. > AXP_152 worked in mainline u-boot rather easily. It was the SD card that I couldn't get working. Strange, because that must obviously work for _everyone_ else for mainline u-boot to be of any use to anyone. SD card worked quite smoothly in u-boot-sunxi. Will try and make nand work now. > > What is a good defconfig and dts file to begin work with, with this > combination? > > None, you're the first... > Copied the Cubietruck board.cfg entry and made some changes. Modified the cubietruck dram file. And done! > > I've been using the CubieTruck defconfig and dts file so far. I copied > over and created a new dts file, which I've been mucking around with (and > only making things worse). > > Cubietruck is likely as good a start as any, and sorry no fex -> dts tool, > it is usually just a matter of manually copy and pasting the right > bits together to get a dts. > As mentioned above, we still need a guide that maps between script.bin and the rather confusing dts file format. -- 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] [RFC 2/2] ARM: dts: sun8i: Add SPI support to the Allwinner A23/A33 dtsi.
Define the necessary nodes in the A23/A33 dtsi files to make the
SPI0 controller accessible.
The SoCs also have a secondary SPI controller (SPI1), but it
cannot be muxed to any available pins and therefore doesn't get
included in the dtsi.
Signed-off-by: Karsten Merker
---
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 38
arch/arm/boot/dts/sun8i-a23.dtsi | 12
arch/arm/boot/dts/sun8i-a33.dtsi | 12
3 files changed, 62 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 6d6509c..a076b5d 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -3,6 +3,8 @@
*
* Chen-Yu Tsai
*
+ * Copyright 2016 Karsten Merker
+ *
* This file is dual-licensed: you can use it either under the terms
* of the GPL or the X11 license, at your option. Note that this dual
* licensing only applies to this file, and not this project as a
@@ -247,6 +249,14 @@
clock-output-names = "nand";
};
+ spi0_clk: clk@1c200a0 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-a10-mod0-clk";
+ reg = <0x01c200a0 0x4>;
+ clocks = <&osc24M>, <&pll6 0>;
+ clock-output-names = "spi0";
+ };
+
usb_clk: clk@01c200cc {
#clock-cells = <1>;
#reset-cells = <1>;
@@ -435,6 +445,34 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+ spi0_pins_a: spi0@0 {
+ allwinner,pins = "PH7", "PH8", "PH9";
+ allwinner,function = "spi0";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+
+ spi0_cs0_pins_a: spi0_cs0@0 {
+ allwinner,pins = "PH6";
+ allwinner,function = "spi0";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+
+ spi0_pins_b: spi0@1 {
+ allwinner,pins = "PC0", "PC1", "PC2";
+ allwinner,function = "spi0";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+
+ spi0_cs0_pins_b: spi0_cs0@1 {
+ allwinner,pins = "PC3";
+ allwinner,function = "spi0";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
};
ahb1_rst: reset@01c202c0 {
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index 92e6616..f55dc50 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -3,6 +3,8 @@
*
* Chen-Yu Tsai
*
+ * Copyright 2016 Karsten Merker
+ *
* This file is dual-licensed: you can use it either under the terms
* of the GPL or the X11 license, at your option. Note that this dual
* licensing only applies to this file, and not this project as a
@@ -85,6 +87,16 @@
};
soc@01c0 {
+ spi0: spi@01c68000 {
+ compatible = "allwinner,sun8i-a23-spi";
+ reg = <0x01c68000 0x1000>;
+ interrupts = ;
+ clocks = <&ahb1_gates 20>, <&spi0_clk>;
+ clock-names = "ahb", "mod";
+ resets = <&ahb1_rst 20>;
+ status = "disabled";
+ };
+
usb_otg: usb@01c19000 {
compatible = "allwinner,sun6i-a31-musb";
reg = <0x01c19000 0x0400>;
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 001d840..e94aea1 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -3,6 +3,8 @@
*
* Chen-Yu Tsai
*
+ * Copyright 2016 Karsten Merker
+ *
* This file is dual-licensed: you can use it either under the terms
* of the GPL or the X11 license, at your option. Note that this dual
* licensing only applies to this file, and not this project as a
@@ -127,6 +129,16 @@
reset-names = "ahb";
};
+ spi0: spi@01c68000 {
+ compatible = "allwinner,sun8i-a23-spi";
+ reg = <0x01c68000 0x1000>;
+ interrupts = ;
+ clocks = <&ahb1_gates 20>, <&spi0_clk>;
+ clock-names = "ahb", "mod";
+
[linux-sunxi] [RFC 1/2] spi: sunxi: Add Allwinner A23/A33 support to spi-sun6i
The Allwinner A23/A33 SoCs contain an SPI controller that is
largely identical to the one in the A31. The major differences
from A31 to A23/A33 are:
- The TX and RX FIFOs on the A23/A33 are only 64 Bytes deep
compared to 128 Bytes on the A31.
- On A23/A33, the SPI_INTCTL register provides an additional
"Master Sample Data Mode" configuration option.
Currently the FIFO depth is hardcoded to 128 Bytes in the
driver; this patch moves it into SoC-specific platform data
instead of defining it globally and adds a new compatible
"allwinner,sun8i-a23-spi".
Signed-off-by: Karsten Merker
---
.../devicetree/bindings/spi/spi-sun6i.txt | 6 ++-
drivers/spi/spi-sun6i.c| 43 +++---
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-sun6i.txt
b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
index 21de73d..4d3eb86 100644
--- a/Documentation/devicetree/bindings/spi/spi-sun6i.txt
+++ b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
@@ -1,7 +1,9 @@
-Allwinner A31 SPI controller
+Allwinner A31/A23 SPI controller
Required properties:
-- compatible: Should be "allwinner,sun6i-a31-spi".
+- compatible: Should be one of
+ - "allwinner,sun6i-a31-spi"
+ - "allwinner,sun8i-a23-spi"
- reg: Should contain register location and length.
- interrupts: Should contain interrupt.
- clocks: phandle to the clocks feeding the SPI controller. Two are
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 9918a57..c6d88c9 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -5,6 +5,8 @@
* Copyright (C) 2014 Maxime Ripard
* Maxime Ripard
*
+ * Copyright (C) 2016 Karsten Merker
+ *
* 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
@@ -24,6 +26,7 @@
#include
#define SUN6I_FIFO_DEPTH 128
+#define SUN8I_A23_FIFO_DEPTH 64
#define SUN6I_GBL_CTL_REG 0x04
#define SUN6I_GBL_CTL_BUS_ENABLE BIT(0)
@@ -92,6 +95,18 @@ struct sun6i_spi {
int len;
};
+struct sun6i_spi_platform_data {
+ int fifo_depth;
+};
+
+static struct sun6i_spi_platform_data sun6i_a31_spi_platform_data = {
+ .fifo_depth = SUN6I_FIFO_DEPTH,
+};
+
+static struct sun6i_spi_platform_data sun8i_a23_spi_platform_data = {
+ .fifo_depth = SUN8I_A23_FIFO_DEPTH,
+};
+
static inline u32 sun6i_spi_read(struct sun6i_spi *sspi, u32 reg)
{
return readl(sspi->base_addr + reg);
@@ -155,7 +170,10 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool
enable)
static size_t sun6i_spi_max_transfer_size(struct spi_device *spi)
{
- return SUN6I_FIFO_DEPTH - 1;
+ struct sun6i_spi_platform_data *pdata;
+
+ pdata = spi->dev.platform_data;
+ return (pdata->fifo_depth - 1);
}
static int sun6i_spi_transfer_one(struct spi_master *master,
@@ -168,9 +186,14 @@ static int sun6i_spi_transfer_one(struct spi_master
*master,
unsigned int tx_len = 0;
int ret = 0;
u32 reg;
+ int fifo_depth;
+ struct sun6i_spi_platform_data *pdata;
/* We don't support transfer larger than the FIFO */
- if (tfr->len > SUN6I_FIFO_DEPTH)
+ pdata = spi->dev.platform_data;
+ fifo_depth = pdata->fifo_depth;
+
+ if (tfr->len > fifo_depth)
return -EINVAL;
reinit_completion(&sspi->done);
@@ -265,7 +288,7 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
SUN6I_BURST_CTL_CNT_STC(tx_len));
/* Fill the TX FIFO */
- sun6i_spi_fill_fifo(sspi, SUN6I_FIFO_DEPTH);
+ sun6i_spi_fill_fifo(sspi, fifo_depth);
/* Enable the interrupts */
sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, SUN6I_INT_CTL_TC);
@@ -288,7 +311,7 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
goto out;
}
- sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
+ sun6i_spi_drain_fifo(sspi, fifo_depth);
out:
sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, 0);
@@ -470,7 +493,14 @@ static int sun6i_spi_remove(struct platform_device *pdev)
}
static const struct of_device_id sun6i_spi_match[] = {
- { .compatible = "allwinner,sun6i-a31-spi", },
+ {
+ .compatible = "allwinner,sun6i-a31-spi",
+ .data = &sun6i_a31_spi_platform_data,
+ },
+ {
+ .compatible = "allwinner,sun8i-a23-spi",
+ .data = &sun8i_a23_spi_platform_data,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun6i_spi_match);
@@ -493,5 +523,6 @@ module_platform_driver(sun6i_spi_driver);
MODULE_AUTHOR("Pan Nan ");
MODULE_AUTHOR("Maxime Ripard ");
-MODULE_DESCRIPTION("Allwinner A31 SPI controller driver");
+MODULE_AUTHOR("Karsten Merker ");
+MODULE_DESCRIP
[linux-sunxi] [RFC 0/2] A33 SPI support
Hello everybody, during the mainlining discussion in the Olimex blog at https://olimex.wordpress.com/2016/08/30/free-electrons-add-mainline-linux-kernel-support-for-the-a13-allwinner-vpu/#comments the topic of A33 SPI support came up. Chen-Yu and Siarhei have pointed out that the chances are good that the A33 can work with the already existing SPI drivers and that simply nobody has taken a look at those in the context of the A33 yet - so I have taken that as an inspiration to take a look :-). >From the description in the docs published by Allwinner, the A23/A33 SPI controller is clearly derived from the one in the A31, but it is not completely identical. The biggest difference is that the RX and TX FIFOs on the A23/A33 are only 64 Bytes deep while they are 128 Bytes deep on the A31. Documentation source: Page 463 of the A33 manual: https://github.com/allwinner-zh/documents/raw/master/A33/A33%20user%20manual%20release%201.1.pdf Page 889 of the A31 manual: https://github.com/allwinner-zh/documents/raw/master/A31/A31_User_Manual_v1.3_20150510.pdf The current spi-sun6i driver hardcodes the FIFO depth to 128 Bytes, so that needs to be changed depending on the SoC type. Another difference is an additional configuration option influencing the signal sampling on the A23/A33. This is handled by bit 13 of the SPI_INTCTL register. The description states: "Master Sample Data Mode 1-Normal Sample Mode 0-Delay Sample Mode In Normal Sample Mode,SPI Master samples the data at the correct edge for each SPI mode. In Delay Sample Mode,SPI master samples data at the edge that is half cycle delayed by the correct edge defined in respective SPI mode." The manual states that "Delay Sample Mode" is the default, which sounds a bit strange to me. Can somebody with a deeper knowledge of SPI comment on that? There are some additional test modes on the A23/33 compared to the A31, but those should be irrelevant for normal operations. Following are two RFC patches based on Maxime Ripard's sunxi/for-next branch at https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/log/?h=sunxi/for-next that modify the spi-sun6i driver to handle different FIFO depths and add the relevant nodes (clock, pinctrl, spi0 controller) to the A23/A33 dtsi files. Please note that this is largely untested as I currently don't have any A23/A33 hardware (an A33 board is on the way to me but will probably take some time to arrive). All I can say at the moment is that the code compiles. I would apprechiate very much if people could take a look at it and provide feedback, and if somebody has appropriate hardware, I would welcome very much if you could subject the code to some practical tests. Btw, while checking the docs I have stumbled over one thing that strikes me as rather strange: the A23/A33 has two SPI controllers (SPI0 and SPI1), but there is no documented pinmux that makes SPI1 available on any pins, so SPI1 appears to be completely useless? Regards, Karsten Karsten Merker (2): spi: sunxi: Add Allwinner A23/A33 support to spi-sun6i ARM: dts: sun8i: Add SPI support to the Allwinner A23/A33 dtsi. .../devicetree/bindings/spi/spi-sun6i.txt | 6 ++- arch/arm/boot/dts/sun8i-a23-a33.dtsi | 38 +++ arch/arm/boot/dts/sun8i-a23.dtsi | 12 ++ arch/arm/boot/dts/sun8i-a33.dtsi | 12 ++ drivers/spi/spi-sun6i.c| 43 +++--- 5 files changed, 103 insertions(+), 8 deletions(-) -- 2.1.4 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Enable Pull-Up on gpio when accessed through sysfs?
Hi all,
I want to enable the pull-up resistors for some gpio pins on a BananaPi-R1
when the pins are accessed from user space through /sys/class/gpio/.
Therefore I have added the following to the pio node of the device tree:
&pio {
...
switch3: switch3@0 {
allwinner,pins = "PI20";
allwinner,function = "gpio_in";
allwinner,drive = ;
allwinner,pull = ;
gpio = <&pio 8 20 GPIO_ACTIVE_HIGH>;
};
...
};
I could see the corresponding entry in
/proc/device-tree/soc@01c0/pinctrl@01c20800 but the pin (located on the
GPIO-J12 jumper) does not show a high state. I would have expected to
measure +3.3V at this pin, but I get only some milivolts. So it seems, that
enabling the pull up seems not working this way. The log when enabling the
pin:
[ 99.024155] sun7i-a20-pinctrl 1c20800.pinctrl: request pin 276 (PI20)
for 1c20800.pinctrl:276
I use currently kernel 4.7.0. Do I miss something?
Regards,
Uli
--
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] Converting script.bin to device tree file
Hi, On 04-09-16 14:48, Saurabh Jain wrote: Is there a straightforward way to convert a script.bin file to a device tree file? Any HOWTO that maps the various options? Should I first be experimenting with the sunxi Uboot instead of Mainline? My device has an AXP152 paired with an A20. Looking at Mainline U-boot, this is an unexpected combination. This is the first time I've heard of this weird pairing yes, but it should work with mainline u-boot, just add CONFIG_AXP152_POWER=y to your defconfig. What is a good defconfig and dts file to begin work with, with this combination? None, you're the first... I've been using the CubieTruck defconfig and dts file so far. I copied over and created a new dts file, which I've been mucking around with (and only making things worse). Cubietruck is likely as good a start as any, and sorry no fex -> dts tool, it is usually just a matter of manually copy and pasting the right bits together to get a dts. 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/d/optout.
[linux-sunxi] Converting script.bin to device tree file
Is there a straightforward way to convert a script.bin file to a device tree file? Any HOWTO that maps the various options? Should I first be experimenting with the sunxi Uboot instead of Mainline? My device has an AXP152 paired with an A20. Looking at Mainline U-boot, this is an unexpected combination. What is a good defconfig and dts file to begin work with, with this combination? I've been using the CubieTruck defconfig and dts file so far. I copied over and created a new dts file, which I've been mucking around with (and only making things worse). -- 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.
