[linux-sunxi] Re: [PATCH v7 16/19] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Maxime Ripard]

On Wed, Jun 16, 2021 at 11:06:30AM +0100, Andre Przywara wrote:
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > + secmon_reserved: secmon@4000 {
> > > + reg = <0x0 0x4000 0x0 0x8>;
> > > + no-map;
> > > + };
> > > + };  
> > 
> > Can't this be added by ATF directly?
> 
> It actually is, and if you use U-Boot's DT ($fdtcontroladdr), that
> actually works. But as it stands right now, U-Boot fails to propagate
> this to any DTB that gets *loaded*. Fixing this requires generic code
> fixes, so I can't just hack this in for sunxi quickly.
> So I wanted to keep this around for a while, as missing this is a
> showstopper for booting Linux.

It looks like we didn't need it for the H6, what makes it any different?

> > > + mmc0: mmc@402 {
> > > + compatible = "allwinner,sun50i-h616-mmc",
> > > +  "allwinner,sun50i-a100-mmc";
> > > + reg = <0x0402 0x1000>;
> > > + clocks = < CLK_BUS_MMC0>, < CLK_MMC0>;
> > > + clock-names = "ahb", "mmc";
> > > + resets = < RST_BUS_MMC0>;
> > > + reset-names = "ahb";
> > > + interrupts = ;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins>;
> > > + status = "disabled";
> > > + max-frequency = <15000>;
> > > + cap-sd-highspeed;
> > > + cap-mmc-highspeed;
> > > + mmc-ddr-3_3v;
> > > + mmc-ddr-1_8v;  
> > 
> > This is not something you know in the DTSI? It entirely depends on how
> > the board has been designed.
> 
> Are you referring just to the last property?

Initially, yes, but the argument is for both...

> This is copying what the driver unconditionally sets for the other
> SoCs at the moment (minus the H5 screwup):
>   mmc->caps  |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;
> IIUC 1.8V operation requires a 1.8V regulator for vqmmc to actually
> work, so this property alone won't enable anything.
> But if it's just about the 1.8V property, I can of course move this to
> the board dts files.

... Since we've seen boards with only 3.3v or 1.8v wired to vqmmc, so we
should really just push this to the boards for new SoCs

Maxime

-- 
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/20210617154242.iovbze64up4u7wba%40gilmour.


signature.asc
Description: PGP signature

[linux-sunxi] SPI-NOR Flash Errors

[Faruk KILAVUZ]

 Hello all.

I working with Allwinner A13 microprocessor. I use spi-nor flash on device
and I want storing some information belong to about of device. So I want
use spi-nor flash as usb mass storage. And for this I ran tiny linux
(kernel version is 5.12-rc3) on spi-nor flash and I can use spi-nor flash
as mass storage(~5Mb).

But I got some errors like below:
[ 9557.574285] spi_master spi0: spi0.0: timeout transferring 64
bytes@100Hz for 110(100)ms
[ 9557.592685] spi-nor spi0.0: SPI transfer failed: -110
[ 9557.601985] spi_master spi0: failed to transfer one message from queue
[ 9557.613673] jffs2: Write of 68 bytes at 0x0045d264 failed. returned
-110, retlen 0
[ 9557.631970] jffs2: Not marking the space at 0x0045d264 as dirty because
the flash driver returned retlen zero


So I some researched and I found repo of hramrach for spi working with
dma(*https://github.com/hramrach/linux-sunxi
 *branch is: *sunxi-spi-pio-dma*
).
I merged dma works of hramrach to my kernel 5.12-rc3 and unfortunately I
got same error as below.


[  198.747427] Buffer I/O error on dev loop0, logical block 131, lost async
page write
[  198.864358] spi_master spi0: spi0.0: timeout transferring 64
bytes@100Hz for 101250(100)ms
[  198.877517] spi-nor spi0.0: SPI transfer failed: -110
[  198.886939] spi_master spi0: failed to transfer one message from queue
[  198.897785] jffs2: Write of 98 bytes at 0x0043a7c0 failed. returned
-110, retlen 0
[  198.909638] jffs2: Not marking the space at 0x0043a7c0 as dirty because
the flash driver returned retlen zero
[  199.034358] spi_master spi0: spi0.0: timeout transferring 64
bytes@100Hz for 101080(100)ms
[  199.047536] spi-nor spi0.0: SPI transfer failed: -110
[  199.056950] spi_master spi0: failed to transfer one message from queue
[  199.067793] jffs2: Write of 98 bytes at 0x0043a7c0 failed. returned
-110, retlen 0
[  199.079704] jffs2: Not marking the space at 0x0043a7c0 as dirty because
the flash driver returned retlen zero
[  199.098175] loop: Write error at byte offset 68096, length 512.


The difference seems between before and after patch is about time. But
unfortunately error still occurs.
Generally when ran `mkdosfs` command and when I tried transfer file
big size(~2MB) I take error.


My diff patch is:

diff --color -Nuar linux/dmaengine.h linux-new/dmaengine.h
--- linux/dmaengine.h 2021-06-17 13:35:46.033174969 +0300
+++ linux-new/dmaengine.h 2021-06-17 13:35:33.088291303 +0300
@@ -1484,7 +1484,8 @@
 struct dma_chan *__dma_request_channel(const dma_cap_mask_t *mask,
dma_filter_fn fn, void *fn_param,
struct device_node *np);
-
+struct dma_chan *dma_request_slave_channel_reason(struct device *dev,
+  const char *name);
 struct dma_chan *dma_request_chan(struct device *dev, const char *name);
 struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

@@ -1513,6 +1514,11 @@
 {
  return NULL;
 }
+struct dma_chan *dma_request_slave_channel_reason(struct device *dev,
+  const char *name);
+{
+ return ERR_PTR(-ENODEV);
+}
 static inline struct dma_chan *dma_request_chan(struct device *dev,
  const char *name)
 {
diff --color -Nuar spi/spi-sun4i.c spi-new/spi-sun4i.c
--- spi/spi-sun4i.c 2021-06-17 13:17:52.253811064 +0300
+++ spi-new/spi-sun4i.c 2021-06-17 13:16:28.868703981 +0300
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 

@@ -30,6 +32,7 @@
 #define SUN4I_CTL_CPHA BIT(2)
 #define SUN4I_CTL_CPOL BIT(3)
 #define SUN4I_CTL_CS_ACTIVE_LOW BIT(4)
+#define SUN4I_CTL_DMAMC_DEDICATED   BIT(5)
 #define SUN4I_CTL_LMTF BIT(6)
 #define SUN4I_CTL_TF_RST BIT(8)
 #define SUN4I_CTL_RF_RST BIT(9)
@@ -49,6 +52,8 @@
 #define SUN4I_INT_STA_REG 0x10

 #define SUN4I_DMA_CTL_REG 0x14
+#define SUN4I_DMA_CTL_RF_READY BIT(0)
+#define SUN4I_DMA_CTL_TF_NOT_FULL  BIT(10)

 #define SUN4I_WAIT_REG 0x18

@@ -85,6 +90,7 @@
  const u8 *tx_buf;
  u8 *rx_buf;
  int len;
+ bool has_dma;
 };

 static inline u32 sun4i_spi_read(struct sun4i_spi *sspi, u32 reg)
@@ -159,6 +165,14 @@
  }
 }

+static bool sun4i_spi_can_dma(struct spi_master *master,
+  struct spi_device *spi,
+  struct spi_transfer *tfr)
+{
+ struct sun4i_spi *sspi = spi_master_get_devdata(spi->master);
+ return sspi->has_dma && tfr->len >= SUN4I_FIFO_DEPTH;
+}
+
 static void sun4i_spi_set_cs(struct spi_device *spi, bool enable)
 {
  struct sun4i_spi *sspi = spi_master_get_devdata(spi->master);
@@ -206,18 +220,22 @@
   struct spi_transfer *tfr)
 {
  struct sun4i_spi *sspi = spi_master_get_devdata(master);
- unsigned int mclk_rate, div, timeout;
- unsigned int start, end, tx_time;
+ struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
+ // unsigned int mclk_rate, div, timeout;
+ unsigned int speed, mclk_rate, div, timeout;
+ // unsigned int start, end, tx_time;
  unsigned int tx_len = 0;
+ u32 reg, trigger = 0;
  int ret = 0;
- u32 reg;
+ unsigned int start, end, tx_time;
+ //u32 reg;

  /* We don't 

[linux-sunxi] Re: [PATCH v7 16/19] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Jernej Škrabec]

Dne četrtek, 17. junij 2021 ob 17:42:42 CEST je Maxime Ripard napisal(a):
> On Wed, Jun 16, 2021 at 11:06:30AM +0100, Andre Przywara wrote:
> > > > +   reserved-memory {
> > > > +   #address-cells = <2>;
> > > > +   #size-cells = <2>;
> > > > +   ranges;
> > > > +
> > > > +   /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > > +   secmon_reserved: secmon@4000 {
> > > > +   reg = <0x0 0x4000 0x0 0x8>;
> > > > +   no-map;
> > > > +   };
> > > > +   };
> > > 
> > > Can't this be added by ATF directly?
> > 
> > It actually is, and if you use U-Boot's DT ($fdtcontroladdr), that
> > actually works. But as it stands right now, U-Boot fails to propagate
> > this to any DTB that gets *loaded*. Fixing this requires generic code
> > fixes, so I can't just hack this in for sunxi quickly.
> > So I wanted to keep this around for a while, as missing this is a
> > showstopper for booting Linux.
> 
> It looks like we didn't need it for the H6, what makes it any different?

H616 TF-A resides in DRAM and H6 resides in SRAM A2 (IIRC). H616 has much less 
useful SRAM due to ARISC removal.

Best regards,
Jernej

> 
> > > > +   mmc0: mmc@402 {
> > > > +   compatible = "allwinner,sun50i-h616-mmc",
> > > > +"allwinner,sun50i-a100-
mmc";
> > > > +   reg = <0x0402 0x1000>;
> > > > +   clocks = < CLK_BUS_MMC0>, < 
CLK_MMC0>;
> > > > +   clock-names = "ahb", "mmc";
> > > > +   resets = < RST_BUS_MMC0>;
> > > > +   reset-names = "ahb";
> > > > +   interrupts = ;
> > > > +   pinctrl-names = "default";
> > > > +   pinctrl-0 = <_pins>;
> > > > +   status = "disabled";
> > > > +   max-frequency = <15000>;
> > > > +   cap-sd-highspeed;
> > > > +   cap-mmc-highspeed;
> > > > +   mmc-ddr-3_3v;
> > > > +   mmc-ddr-1_8v;
> > > 
> > > This is not something you know in the DTSI? It entirely depends on how
> > > the board has been designed.
> > 
> > Are you referring just to the last property?
> 
> Initially, yes, but the argument is for both...
> 
> > This is copying what the driver unconditionally sets for the other
> > 
> > SoCs at the moment (minus the H5 screwup):
> > mmc->caps  |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;
> > 
> > IIUC 1.8V operation requires a 1.8V regulator for vqmmc to actually
> > work, so this property alone won't enable anything.
> > But if it's just about the 1.8V property, I can of course move this to
> > the board dts files.
> 
> ... Since we've seen boards with only 3.3v or 1.8v wired to vqmmc, so we
> should really just push this to the boards for new SoCs
> 
> Maxime




-- 
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/8040051.UxXjYCDM83%40jernej-laptop.