[linux-sunxi] Re: [PATCH 01/54] ASoC: dt-bindings: Add WM8978 Binding
On Fri, Jul 23, 2021 at 03:32:51PM -0600, Rob Herring wrote: > On Wed, Jul 21, 2021 at 04:03:31PM +0200, Maxime Ripard wrote: > > Even though we had the wm8978 driver for some time and a number of > > boards using it already, we never had a binding for it. Let's add it > > based on what the driver expects and the boards are providing. > > +maintainers: > > + - Mark Brown > No one from Wolfson cares about this device? > Otherwise, > Reviewed-by: Rob Herring Well, Wolfson no longer exists since it was bought by Cirrus but copying in the Cirrus people to see if they want to be listed there. -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210726001713.GA8831%40sirena.org.uk. signature.asc Description: PGP signature
Re: [linux-sunxi] Re: Mainlining Linux Sunxi SoC AW USB
Hi Andre, > On Sat, 24 Jul 2021 18:27:53 +0200 > Petr Vorel wrote: > Hi Petr, > > [ Dropping Greg and linux-...@vger.kernel.org ] > > > Peter, > > > On Sat, 24 Jul 2021 at 15:22, Petr Vorel wrote: > > > > Hi Greg, > > > > > On Sat, Jul 24, 2021 at 03:41:42PM +0200, Petr Vorel wrote: > > > > > > > Why is this even a driver at all, it looks like you can write a > > > > > > > small > > > > > > > userspace program using libusb to do everything it does, right? > > > > > > > What > > > > > > > exactly is this driver needed for? > > > > > > I'm sorry for not providing more info at the beginning. This is a > > > > > > driver for > > > > > > host computer (i.e. developers laptop) used by LiveSuit tool [2] to > > > > > > flash Images > > > > > > to the NAND of Allwinner devices. LiveSuit itself [3] is > > > > > > unfortunately provided > > > > > > only in binary form. The only open source code with GPL v2 license > > > > > > is awusb > > > > > > driver. Thus I thought I could ease my life with upstreaming at > > > > > > least the > > > > > > kernel driver. But maybe it's not a good idea. I'm using LiveSuit > > > > > > for flashing > > > > > > Allwinner A31, but it requires quite old distro due libqtgui4. > > > > > > Maybe sunxi folks > > > > > > use something newer nowadays, but I haven't found anything in their > > > > > > wiki. > > > > > Ah, that's not going to be good then. Really, this doesn't seem to > > > > > need > > > > > to be a driver at all, and the ioctls are really strange so we would > > > > > need to change them anyway before it could be merged. But with no > > > > > access to userspace code, that will be quite difficult, so I would > > > > > push > > > > > back on allwinner and have them work on resolving this. > > > > Understand, it makes sense. Thanks for your time! > > > > @Sunxi community: am I missing something? Using LiveSuit with old > > > > distro chroot > > > > and Xephyr with out-of-tree module isn't fun :(. > > > Suggest you take a look at sunxi-tools - specifically the sunxi-fel > > > tool. This is a libusb-based userland tool to talk to these devices. > > > I'm not sure if it supports flashing to nand on A31 - never tried it - > > > but have used it to flash to eMMC and SPI flash on their other chips. > > Thanks for a tip. Looking into sources it does not look like sunxi-fel > > supports > > NAND. > > Also from Debian wiki [1] (which describes bootable SD Card) it looks like > > only > > old Allwinner u-boot supported access to NAND, thus I'd be surprised if > > sunxi-tools supported it. sunxi-bootinfo does not implement NAND, > > sunxi-nand-image-builder (which is not built by default) creates raw NAND > > images, but now word about flashing. > > I wonder why NAND is (probably) not supported by sunxi? Lack of > > documentation? > Pure NAND is getting rarer these days, on modern boards we see mostly > eMMC now (maybe SPI NAND). So NAND is only a concern for older SoCs. > There is (limited) NAND support for mainline U-Boot on the C.H.I.P. > boards[1], which use an A13 (derivative). But reliable operation is > only possible with SLC NAND, which means only on the Chip Pro board, > IIUC. Most boards will probably utilise MLC (or worse) NAND these days, > where effects like write and read disturb make operation more > complicated. Maxime has some stories to tell about this. > So it would be first good to know if you have SLC NAND or not. I have no idea which type of NAND device has. It's device based on low end tablet. Can I find this info on running system (sysfs, /proc, ...). dmesg does not say anything special. Or is it possible to find it in source code? nand.ko module is some out of tree code in modules/nand (kernel 3.3): description:Generic NAND flash driver code author: nand flash groups But nothing mentions SLC or MLC. Or do I have to have HW spec? > Because of this direct support for NAND in the tools is understandably > "limited" (as in: non-existent). Except for SPI NOR flash there is no > "direct" flashing support (for eMMC) in the tools anyway, it just relies > on U-Boot support. > How this works is that you use sunxi-fel to upload a (mainline) U-Boot > binary directly into DRAM, and launch that. Then you can use the full > functionality of U-Boot to load your image. Most popular for NAND > support seems to be U-Boot's Android Fastboot implementation over a USB > gadget device, so you can use the off-the-shelf fastboot tool on your > host computer to flash the NAND. Other possibilities would be to use > USB host support or TFTP to first load an image into DRAM, then use > U-Boot commands to write that into the NAND flash. > To my knowledge NAND flash in U-Boot *only* works on the A13/R8/GR8 > chips with SLC NAND, and is only enabled and tested on the Chip boards. > Every other combination would require some work; much more work the > farther you move from there (other SoC, MLC, ...). Thanks for detailed
[linux-sunxi] Re: [PATCH v8 00/11] arm64: sunxi: Initial Allwinner H616 SoC support
在 2021-07-23星期五的 16:38 +0100，Andre Przywara写道： > Hi, > > another try on the basic Allwinner H616 support, now on top of 5.14- > rc1. > > This time I dropped the USB support from the basic series, to split > off > the discussion, and simplify the core SoC support. I will post the > USB > series soon, to be applied on top. > I kept the RTC support in, even though this is still under > discussion, > because this is important to keep future DT files compatible with > this > kernel. This gains one fix patch for the existing RTC driver. Well, I think RTC is really a fundmental part of SoC support now. I think if I post my R329 patchset, it will depend on this patchset's RTC part (R329 has linear day too, although it still has external LOSC (and even LOSC fanout) ). BTW Thanks for your code ;-) > > For a complete changelog, see below. > > Based on 5.14-rc1. Let me know if you need a different base. > Relies on this pinctrl fix: > http://lists.infradead.org/pipermail/linux-arm-kernel/2021-July/672813.html > > Also available here: > https://github.com/apritzel/linux/commits/h616-v8 > > Thanks! > Andre > > == > This series gathers patches to support the Allwinner H616 SoC. This > is > a rather uninspired SoC (Quad-A53 with the usual peripherals), but > allows for some cheap development boards and TV boxes, and supports > up to 4GB of DRAM. > > Some DT binding patches are sprinkled throughout the series, to add > the new compatible names right before they are used. > Patch 3-7 add support for the new RTC: the date is now stored as a > linear number, not broken down into day-month-year. The benefit is > that > this lifts the limit of the old date counter, which would have rolled > over around 2032. Also the alarm setting is using the same storage > format as the current time, compared to the number of seconds left > used > in existing SoCs. > Eventually we get the .dtsi for the SoC in patch 8, and the .dts for > the OrangePi Zero2 board[1] in the penultimate patch, followed by > the .dts for the X96 Mate TV box[2] in the final commit. > > U-Boot and Trusted Firmware support is now merged in released > versions, > it allows booting via FEL or SD card, also you can TFTP kernels in on > the OrangePi Zero 2 board. > > Many thanks to Jernej for his tremendous help on this, also for the > awesome input and help from the #linux-sunxi Freenode channel. > > The whole series (including the pinctrl fix) can also be found here: > https://github.com/apritzel/linux/commits/h616-v8 > > Happy reviewing! > > Cheers, > Andre > > [1] https://linux-sunxi.org/Orange_Pi_Zero_2 > [2] https://linux-sunxi.org/X96_Mate > > Changelog v7 .. v8: > - Rebase on top of 5.14-rc1, which already includes the previous v7 > 02/19 > - Drop USB and Ethernet patches (to keep series small) > - Use "clocks: false" in RTC DT binding (2/11) > - Include fix for RTC overflow check (3/11) > - Use div_64() to avoid linking error on some 32-bit platforms > (4+5/11) > - Adjust to changed RTC overflow check (5/11) > - Drop USB nodes from .dtsi file > - Move mmc-ddr-1_8v property from .dtsi file into board .dts > - Fix DTC warnings (underscore in node name, soc@0, #a-c in IRQ > controllers) > > Changelog v6 .. v7: > - Fix AXP305 binding documentation blunder (01/19) > - Improve new linear day support (use existing conversion functions) > (04/19) > - Add support for changed RTC alarm registers (05/19) > - Add support for RTCs without a LOSC clock (06/19) > - Rework USB PHY2 SIDDQ quirk to use PHY clocks directly (14/19) > - Add X96 Mate compatible string to binding doc (17/19) > - Add Rob's ACKs > > Changelog v5 .. v6: > - Drop already merged clock, pinctrl and MMC support from this series > - Properly fix AXP support by skipping power key initialisation > - Add patch to support new RTC date storage encoding > - Re-add USB HCI PHY refactoring > - Add patch to allow USB reset line sharing > - Add patch to introduce quirk for PHY2 SIDDQ clearing > - Re-add USB nodes to the .dtsi > - Add USB gadget support > - Add DT for X96 Mate TV box > > Changelog v4 .. v5: > - Fix CCU binding to pass dtbs_check > - Add RSB compatible string to binding doc > - Rename IR pin name to pass dtbs_check > - Add EMAC compatible string to binding doc > - Drop USB PHY support and binding doc patches > - Drop USB nodes from .dtsi and .dts > - Drop second EMAC node from .dtsi > > Changelog v3 .. v4: > - Drop MMC and pinctrl matches (already in some -next trees) > - Add Maxime's Acks > - Add patch to update the AXP MFD DT bindings > - Add new patch (05/21) to fix axp20x-pek driver > - Change AXP IRQ fix to check for invalid IRQ line number > - Split joint DT bindings patch (v3 18/21) into subsystems > - move dwmac variable to keep christmas tree > - Use enums for USB PHY compatible strings in DT binding > - Enable watchdog (briefly verified to work) > - Add PHY2 to HCI1&3, this fixes USB > - limit r-ccu register frame length to not collide with NMI >
[linux-sunxi] Re: [PATCH v8 07/11] rtc: sun6i: Add Allwinner H616 support
Hi Andre! Dne petek, 23. julij 2021 ob 17:38:34 CEST je Andre Przywara napisal(a): > The H616 RTC changes its day storage to the newly introduced linear day > scheme, so pair the new compatible string with this feature flag. > The clock part is missing an external 32768 Hz oscillator input pin, > for future expansion we must thus ignore any provided clock for now. > > Signed-off-by: Andre Przywara > --- > drivers/rtc/rtc-sun6i.c | 19 +++ > 1 file changed, 19 insertions(+) > Reviewed-by: Jernej Skrabec Best regards, Jernej -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/3759037.3KSXBDaA9l%40kista.
[linux-sunxi] Re: [PATCH v8 06/11] rtc: sun6i: Add support for RTCs without external LOSCs
Hi Andre! Dne petek, 23. julij 2021 ob 17:38:33 CEST je Andre Przywara napisal(a): > Some newer Allwinner RTCs (for instance the one in the H616 SoC) lack > a pin for an external 32768 Hz oscillator. As a consequence, this LOSC > can't be selected as the RTC clock source, and we must rely on the > internal RC oscillator. > To allow additions of clocks to the RTC node, add a feature bit to ignore > any provided clocks for now (the current code would think this is the > external LOSC). Later DTs and code can then for instance add the PLL > based clock input, and older kernel won't get confused. > > Signed-off-by: Andre Przywara > --- > drivers/rtc/rtc-sun6i.c | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > Acked-by: Jernej Skrabec Best regards, Jernej -- 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. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/3166830.bveH9cQ5e6%40kista.
[linux-sunxi] Re: [PATCH v8 05/11] rtc: sun6i: Add support for broken-down alarm registers
Hi Andre!
Dne petek, 23. julij 2021 ob 17:38:32 CEST je Andre Przywara napisal(a):
> Newer versions of the Allwinner RTC, for instance as found in the H616
> SoC, not only store the current day as a linear number, but also change
> the way the alarm is handled: There are now two registers, that
> explicitly store the wakeup time, in the same format as the current
> time.
>
> Add support for that variant by writing the requested wakeup time
> directly into the registers, instead of programming the seconds left, as
> the old SoCs required.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/rtc/rtc-sun6i.c | 60 +
> 1 file changed, 43 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index a02be8bca6f3..f0ee20bfdccb 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -48,7 +48,8 @@
>
> /* Alarm 0 (counter) */
> #define SUN6I_ALRM_COUNTER 0x0020
> -#define SUN6I_ALRM_CUR_VAL 0x0024
> +/* This holds the remaining alarm seconds on older SoCs (current value) */
> +#define SUN6I_ALRM_COUNTER_HMS 0x0024
> #define SUN6I_ALRM_EN0x0028
> #define SUN6I_ALRM_EN_CNT_EN BIT(0)
> #define SUN6I_ALRM_IRQ_EN0x002c
> @@ -523,32 +524,57 @@ static int sun6i_rtc_setalarm(struct device *dev,
struct rtc_wkalrm *wkalrm)
> struct sun6i_rtc_dev *chip = dev_get_drvdata(dev);
> struct rtc_time *alrm_tm = >time;
> struct rtc_time tm_now;
> - time64_t time_now, time_set;
> + time64_t time_set;
> + u32 counter_val, counter_val_hms;
> int ret;
>
> - ret = sun6i_rtc_gettime(dev, _now);
> - if (ret < 0) {
> - dev_err(dev, "Error in getting time\n");
> - return -EINVAL;
> - }
> -
> time_set = rtc_tm_to_time64(alrm_tm);
> - time_now = rtc_tm_to_time64(_now);
> - if (time_set <= time_now) {
> - dev_err(dev, "Date to set in the past\n");
> - return -EINVAL;
> - }
>
> - if ((time_set - time_now) > U32_MAX) {
> - dev_err(dev, "Date too far in the future\n");
> - return -EINVAL;
> + if (chip->flags & RTC_LINEAR_DAY) {
> + time64_t seconds;
> +
> + /*
> + * The alarm registers hold the actual alarm time,
encoded
> + * in the same way (linear day + HMS) as the current
time.
> + */
> + counter_val_hms = SUN6I_TIME_SET_SEC_VALUE(alrm_tm-
>tm_sec) |
> +
SUN6I_TIME_SET_MIN_VALUE(alrm_tm->tm_min) |
> +
SUN6I_TIME_SET_HOUR_VALUE(alrm_tm->tm_hour);
> + seconds = mktime64(alrm_tm->tm_year + 1900, alrm_tm-
>tm_mon,
> +alrm_tm->tm_mday, 0, 0, 0);
While above line should work, it's confusing why you're adding 1900 to years.
In my opinion it would be better to use same trick you used in patch 4 -
rtc_tm_to_time64() with hours, minutes and seconds set to 0. Or maybe you
don't even need to do that, since division by SECS_PER_DAY will round down
anyway. In such way you hide RTC internal representation detail which doesn't
need to be exposed here.
Once fixed:
Reviewed by: Jernej Skrabec
Best regards,
Jernej
> + counter_val = div_u64(seconds, SECS_PER_DAY);
> + } else {
> + /* The alarm register holds the number of seconds left.
*/
> + time64_t time_now;
> +
> + ret = sun6i_rtc_gettime(dev, _now);
> + if (ret < 0) {
> + dev_err(dev, "Error in getting time\n");
> + return -EINVAL;
> + }
> +
> + time_now = rtc_tm_to_time64(_now);
> + if (time_set <= time_now) {
> + dev_err(dev, "Date to set in the past\n");
> + return -EINVAL;
> + }
> + if ((time_set - time_now) > U32_MAX) {
> + dev_err(dev, "Date too far in the future\n");
> + return -EINVAL;
> + }
> +
> + counter_val = time_set - time_now;
> }
>
> sun6i_rtc_setaie(0, chip);
> writel(0, chip->base + SUN6I_ALRM_COUNTER);
> + if (chip->flags & RTC_LINEAR_DAY)
> + writel(0, chip->base + SUN6I_ALRM_COUNTER_HMS);
> usleep_range(100, 300);
>
> - writel(time_set - time_now, chip->base + SUN6I_ALRM_COUNTER);
> + writel(counter_val, chip->base + SUN6I_ALRM_COUNTER);
> + if (chip->flags & RTC_LINEAR_DAY)
> + writel(counter_val_hms, chip->base +
SUN6I_ALRM_COUNTER_HMS);
> chip->alarm = time_set;
>
> sun6i_rtc_setaie(wkalrm->enabled, chip);
> --
> 2.17.6
>
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and
