christianeisendle / nxprdlib-kernel-bal Goto Github PK

Currently only PN5180 is supported. There should be a way to change the used IC, for instance using ioctl

I am trying to use this module with kernel 4.19. baldev_init successfully is called but /dev/bal not exposed. I found that bal_spi_probe is never called, despite there are not any errors. How I can get the /dev/bal? One thing which also looks strange, that I need to load the bal kernel module manually. I build the bal module out of tree. I use the following FDT:
`/dts-v1/;
/plugin/;

#include "sama5d2-pinfunc.h"
#include "dt-bindings/pinctrl/at91.h"
#include <dt-bindings/gpio/gpio.h>

&spi3 {
#address-cells = <1>;
#size-cells = <0>;
cs-gpios = <&pioA PIN_PD0 GPIO_ACTIVE_LOW>;
status = "okay";
bal: nxprdlib-bal@1 {
compatible = "nxp,bal";
reg = <1>;
spi-max-frequency = <24000000>;
busy-pin-gpio = <&pioA PIN_PB3 GPIO_ACTIVE_LOW>;
status = "okay";
};
};

&pioA {
pinctrl_pn5180_busy: pn5180_busy {
pinmux = <PIN_PB3>;
bias-disable;
};
};

&pinctrl_mikrobus2_spi_cs {
bias-pull-up;
};

&pinctrl_mikrobus_spi {
bias-pull-up;
};

&{/} {
model = "Atmel SAMA5D27 SOM1 EK PN5180";
};`

In order to allow firmware updates, PN5180 needs to be put in download mode.
Once in this mode a different host interface mode is required.
In normal mode, the host interface behavior is as such:

• Frames contain of commands which are build up by one instruction byte and one or more payload bytes
• There is no additional header indicating the length for one command
• Half duplex communication is used, i.e. when reading back data from PN5180 another SPI transfer need to be setup, so read commands consist of two SPI frames
• BUSY line is used for flow control, i.e. as long as BUSY is driven high by PN5180 host is not allowed to send another frame

The behavior is sketched by the following wavedrom script (paste in http://wavedrom.com/editor.html):
{signal: [
{name: 'nss', wave: '1...0.........1.0......'},
{name: "mosi", wave: "0....==....0.........", data: ["ins", "payload"] },
{name: 'busy', wave: '0.....1........0....'},
]}

Download mode host interface behavior is like this:

• Frames contains of one direction byte, two length bytes, followed by instruction byte and one or more payload bytes
• Also here half duplex communication is used, the direction byte indicates a read or write request:
  o In case direction byte is 0x7f it is a write request (command send to PN5180)
  o In case direction byte is 0xff it is a read request (read response from PN5180)
• No BUSY is used since a command/response based protocol is used, i.e. a command (write request) is sent to PN5180 and PN5180 always prepares a response which need to be read out using a read request
• The BUSY pin has inverted meaning and is called IRQ in this case: It raises once PN5180 has prepared a response

The behavior is sketched by the following wavedrom script (paste in http://wavedrom.com/editor.html):
{signal: [
{name: 'nss', wave: '1...0..................1.0..........1...'},
{name: "mosi", wave: "0....==.==........=.0......=xx.....0....", data: ["0x7f", "len", "ins", "data", "crc", "0xff","dummy"] },
{name: 'miso', wave: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxx=......0....', data: ["response"]},
{name: 'irq', wave: '0.......................1............0..'},
]}

The BAL module should be extended to support this download mode by using an IOCTL option to switch between normal mode and download mode.

Currently only device tree is supported, i.e. module not working if device tree is disabled/not used.

Current implementation uses static context. This prevents multiple instantiations of the driver and, moreover, doesn't follow Linux Kernel design pattern to separate code from data

cmd parameter of baldev_ioctl doesn't follow the conventions as defined in ioctl.h
Second, arg parameter is used as value, but is intented to be used as a pointer

/dev/bal is always available once the module is loaded, also in case it has not been assigned to an SPI device.

Christian,

Following the instruction in the README to generates the bal module I noticed the following error:
Building the module using make M=/usr/src/nxprdlib-kernel-bal command fails because of the missing Makefile in the directory.
I fixed using the command make M=/usr/src/nxprdlib-kernel-bal/bal instead.

Jeremy.

When setting up transfers (read or write) with > 90 bytes payload, the data transferred is corrupted. This can easily reproduced by writing eg. 100 bytes into the file handle and compare it with the data transferred via SPI.