Den 09.01.2015 23:31, skrev maxime.ripard@xxxxxxxxxxxxxxxxxx:
On Fri, Jan 09, 2015 at 06:13:43PM +0530, Ssagarr Patil wrote:
Hi Maxime,
Thanks for your response!
On Fri, Jan 09, 2015 at 03:45:01PM +0530, Ssagarr Patil wrote:
Hi Maxime,
Thanks for the pointer, I am using spi_write() call and I see /dev/fb0 node created.
but when I do echo "1121"> /dev/fb0 nothing comes up on oled any pointers on this ?
You can't use it like that. It's a standard framebuffer, that is
represented as an array of pixels, so you need to use a font rendering
software if you want to output some text.
can fbtest
(https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/)
be used to to draw something ?
how do I set pixels of it ? Please if you can point me to some stuff that would be helpful.
Last time I tried, fbtest didn't support monochrome display.
And you'll find anything you need in the documentation.
https://www.kernel.org/doc/Documentation/fb/framebuffer.txt
In my case I see that init is done but I dont see any pixels on the
screen at all.
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)
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
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
I'm currently rewriting the project armed with better knowledge of the
kernel and the various LCD controllers.
I haven't done the SSD1306 controller yet, but the principle is almost
the same for all these MIPI DBI like controllers.
The major difference is that it's monochrome and has a different
register map.
In my rewrite I have made an abstraction for the LCD register:
https://github.com/notro/fbdbi/blob/master/core/lcdreg.h#L46
SPI part matching several controller variations:
https://github.com/notro/fbdbi/blob/master/core/lcdreg-spi.c
In case you wonder: In my code I set the the window where the update is
to take place every time, whereas ssd1307fb does this only once in init.
I do this because controllers supporting higher resolutions can be sped
up using partial updates (set_addr_win).
Regards,
Noralf Trønnes
--
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
