Jump to content

robert@axium.co.nz

Members
  • Posts

    4
  • Joined

  • Last visited

Recent Profile Visitors

1201 profile views
  1. With the Orange Pi One and the mainline kernel, I can't get it to work optimally when plugged into a gigabit switch. The eth interface on the Pi One is 100Mb/s and it works perfectly when attached to a switch that is 100Mb/s. When attached to a 1000Mb/s switch: [112776.347520] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off When attached to a 100Mb/s switch: [112882.431555] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
  2. On the whole the driver is good. One thing I noticed on the Orange Pi One was it doesn't work optimally when plugged into a gigabit switch. The eth interface on the Pi One is 100Mb/s and it works perfect when attached to a switch that is 100Mb/s. When attached to a 1000Mb/s switch: [112776.347520] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off When attached to a 100Mb/s switch: [112882.431555] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx Tested on kernels 4.13 - 4.14. Not sure where to do a proper bug report, but figured I'd mention in case someone else has noticed anything.
  3. Using the dev build of Armbian for the OrangePi One, does the SPI driver in the mainline kernel support DMA? According to the mainline status page the work on SPI is done, and DMA has been supported since 4.2 I have enabled the spi interface in the device tree and my driver initialises properly with the master. But in my kernel driver I attempt to allocate some memory with dma_alloc_coherent and it fails. The driver works fine with the legacy kernel and with alternative hardware (raspberry pi). Is there some additional configuration needed or does anyone have any pointers to information on this that I look at? --edit Solved it - the mainline driver doesn't like the GFP_DMA flag being present on the dma_alloc_coherent call.
  4. In my spi protocol driver I send large buffers of data to be transferred. I am not interested in the data received so I leave the rx_buf as NULL. In the controller driver they have code to implement this use case: https://github.com/allwinner-zh/linux-3.4-sunxi/blob/6964d467510849e3e262518cb87bff7ef92e01f5/drivers/spi/spi-sunxi.c#L1003 However the transfer never completes and the kernel logs a time out for each transfer after 120 seconds. I have tried modifying the driver with various options like disabling the SPI_GC_TP_EN, which pauses transmit when the receive fifo is full, but it has no effect. Finally after hours of futile tinkering I decided to change my protocol driver to use what I figured was the better tested code path for both transmit and receive. After adding a dummy receive buffer to my spi transfers, the transmits finally succeed. I don't mind having to do this, but it was very misleading with the code seemingly supporting the options I was using and silently failing. The controller driver should instead log an error message that half-duplex transmit is not supported. This would have saved me a lot of time. Additionally there is the issue that either the bits_per_word or speed_hz fields of the spi_transfer struct must be set in the in order for the protocol driver settings to actually be setup. In the driver, the function that does this is sunxi_spi_xfer_setup, but it's only called if the transfer has those set. That required functionality should also be performed in the sunxi_spi_setup function which occurs when the protocol driver initialises. I'll attach my revised version of the driver soon, in case it might be of benefit to someone. I realise that this is technically a legacy driver, but seeing as the mainline kernel isn't quite ready on a few things, I believe this driver is still most likely to be used for a while yet.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines