Did anyone integrate MAX14830?

Products Support DragonBoard410c
,
#1

Hi.
I am trying kernel rebuild because I want to use MAX14830.
I refer to http://builds.96boards.org/releases/dragonboard410c/linaro/debian/17.04.1/
git clone -n working/qualcomm/kernel.git - Qualcomm Landing Team kernel
cd kernel
git checkout -b kernel-17.04.1 debian-qcom-dragonboard410c-17.04.1
export ARCH=arm64
export CROSS_COMPILE=/aarch64-linux-gnu-

First, I run “make menuconfig” command to change MAX310 is enable.
make defconfig distro.config
make -j4 Image dtbs KERNELRELEASE=4.9.30-linaro-lt-qcom

I could build kernel and boot it on the board but the kernel does not detect MAX14830.

Is there anyone who solved this issue?

How to use Max14830 as I2c with Dragonboard820c
#2

you need to do make menuconfig, after make defconfig distro.config, since it will override the setting you just did.

#3

Thank you for your reply.

I Tried make menuconfig, after make defconfig distro.config and then I could find max310x.o in drivers/tty/serial/
I boot dragonboad410c to use new kernel image and it was successful and I tried cat /proc/tty/drivers and I could find following line.
max310x         /dev/ttyMAX   204  209-224    serial

But I can not find these messages in dmesg.
max310x spi0.3: ttyMAX0 at I/O 0x0
max310x spi0.3: ttyMAX1 at I/O 0x20
max310x spi0.3: ttyMAX2 at I/O 0x40
max310x spi0.3: ttyMAX3 at I/O 0x60

What should I do ?

#4

Hi @misoragod,

A quick look at the MAX310 driver tells me, it’d need a device tree node in order to enumerate as SPI device.

You can consider the following device tree node and add the same in apq8016-sbc.dtsi file.

http://elixir.free-electrons.com/linux/latest/source/Documentation/devicetree/bindings/serial/maxim,max310x.txt

Hope this helps!

Thanks,
Mani

#5

Hi @Mani,

I’ll try it.

Thanks.

#6

Hi @misoragod

Installing a driver consists of two steps. you did the first step, you need to add the driver using menuconfig, it sounds like you completed this test. The second part of the problem is making the physical connctions,and then describing what you did to the kernel in the dtsi files.

I am guessing that you made the physical connections to the low-speed connector. the SPI connections are pretty simple, the other two connections are not so obvious, you need to connect an interrupt input, and a reset output to the chip. The interrupt and reset connections go to gpios, which ones did you select?

You will need to describe your connections in these two files:

kernel/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
kernel/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi

Unfortunately I do not have a MAX14380 board so I can’t set it up and test it for you. I ‘think’ you need something like this in apq8016-sbc.dtsi

           spi@78b9000 {
           /* On Low speed expansion */
                   label = "LS-SPI0";
                   status = "okay";
                   max14830: max14830@0 {
                           compatible = "maxim,max14830";
                           reg = <0>;
                           spi_max_frequency = <20000000>;
                   };
           };

Full disclosure: I am an employee of Qualcomm Canada, any opinions I may have expressed in this or any other post may not reflect the opinions of my employer.

#7

Hi @ljking

Thanks for your reply.

I want to connect an interrupt to gpios and if possible I do not want to connect a reset to anything.

I explain what we are doing.
we have made mezzanine board that is assembled MAX14830.
We call the board Yatagarasu.
The board has already worked well on HiKey.
So that, I try to work it Dragonboard410c then I have this problems.

This is DTS entry of MAX1480 of HiKey.
We connect a intterupt to GPIO_F on HiKey and a reset does not connect.

max14830: max14830@3 {
                compatible = "maxim,max14830";
                spi-max-frequency = <15000000>;
                reg = <3>;
                clocks = <&clk16m0>;
                clock-names = "osc";
                interrupt-parent = <&gpio12>;
                interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
                gpio-controller;
                #gpio-cells = <2>;
                clk16m0: clk16m0 {
                    compatible = "fixed-clock";
                    #clock-cells = <0>;
                    clock-frequency = <16000000>;
                    clock-accuracy = <100>;
                };
             };

I looked through Dragonboard circuit diagram and then I found that GPIO_F connected to MPP4 on PM8916.
Can I connect a interrupt to GPIO_F ?

#8

Hi, quick question, is the SPI hardware of the Dragonboard capable of 16 bit data transfers?
Based on the conversation here about MAX3100 devices it seems that it should. I’m also trying to interface a MAX3110 chip with the Dragonboard but in Windows IoT Core. The driver reports only 8 bits as valid data sizes. So, it seems to be a driver limitation.

#9

Hi @GUILLERMO

Is there anything specific about the 16-bit aspect? The controller can certainly do multi-byte transfers (the default test we recommend in the docs to check it is configured correctly uses a 32 byte burst).

Note that SPI protocols tend to be big endian so a two-byte transfer will probably require a byte swap.

#10

The SPI controller can do any size transfer, however a 16-bit transfer (which happens all together) is, from the SW point of view, two 8-bit transfers back to back. You really should attach an oscilloscope to the SPI lines and ensure that what you thought you were sending is really what you are sending, it will make diagnosing problems like byte swapping much easier.

#11

Hello All, the reason behind the question was the following: I’m integrating a couple of MAX3100 UART devices in a mezzanine board that attaches to the low speed bus. This device and its variants (MAX3110, MAX3111) have a 16 bit command and answer protocol that requires that CS (Chip Select) to be held low for the duration of the 16 bits transfer. If CS toggles between the 8th and 9th bit, the command is discarded.
Meantime, I did test with a scope. In Windows IoT Core the SPI interface accepts only a byte or a byte array of any length. Although there is a small pause between bytes, CS reminds low for the transmission and reading of the entire array. So, sending an array of two bytes solves my problem. I haven’t tested if in Linux the CS behavior is the same. Worst case, the user must handle CS manually with a GPIO.

#12

Daniel, no byte swap is required as the command table for the device is created in the byte order expected by the device. Received data is also into a byte array were the first byte (array[0]) contains flags and signal status and array[1] is the actual data byte received.