Hi Noralf, >>> >>> I am now concerned if the driver was tested in first place ? >> No. I just submitted some good looking code that never ever got >> tested. >> >> More seriously, There's a few thing that comes to my mind: >> - Your controller doesn't behave the same way than the ones already >> supported. >> - You haven't posted your changes yet, so maybe you're not doing the >> transfers right >> - Your SPI controller is doing something weird >> >> What happens if you plug a logical analyzer on the bus? >> >> Maxime >> > Hi, > > The major difference between the SSD1306 SPI and I2C interfaces, is that > SPI uses a D/C pin to signal whether it's data or command coming in. > Looking at ssd1307fb, this Data/Command info is embedded as the first > byte in the i2c package/message. > Without looking up the datasheet, I would guess that this is the only > difference, the way the D/C bit is handled. > The rest of the package payload should be the same. > So: > dc=0, spi write command > dc=1, spi write data (optional) > I was working on ssd1306 itself. > > Apart from that, I have SSD1306 SPI support in a project of mine: > > This is the part writing the framebuffer: > https://github.com/notro/fbtft/blob/master/fb_ssd1306.c#L173 > This writes commands (for many controllers): > https://github.com/notro/fbtft/blob/master/fbtft-bus.c#L10 > This is the SPI specific part: > https://github.com/notro/fbtft/blob/master/fbtft-io.c#L10 > Project wiki: https://github.com/notro/fbtft/wiki > Thanks for the pointers that was really helpful. just a quick help the dc pin should be a gpio and be set as output pin to control D/C ? in my case for ssd1306 needs to be added as slave device in board file since I dont have DT. > The code isn't particularly pretty, it was my first venture into the kernel. > It has recently been submitted for the staging tree: > https://github.com/notro/fbtft/issues/161#issuecomment-68431405 > hope it gets accepted soon. Thanks, --Sagar -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html