[sprdlinux] Re: Help with spreadtrum kernel
- From: Orson Zhai (翟京) <Orson.Zhai@xxxxxxxxxxxxxx>
- To: "sprdlinux@xxxxxxxxxxxxx" <sprdlinux@xxxxxxxxxxxxx>
- Date: Fri, 13 Feb 2015 11:01:48 +0000
Hacking mode on.
I have downloaded the ili9481 and ili9486 datasheet from internet.
I see they are almost same.
at least for the pin-out of data port, so i think the difference maybe in
commands setting by a lot of send_data() in spreadtrum code.
If only 8 bit of the 16bit color data is shown, the image should be half of the
screen, not quarter.
that means the rows are also reduced.
so i think the display mode of 9481 maybe wrongly set by 9486 commands.
Orson
________________________________
From: sprdlinux-bounce@xxxxxxxxxxxxx <sprdlinux-bounce@xxxxxxxxxxxxx> on behalf
of Abhishek Goyal <abgoyal@xxxxxxxxx>
Sent: Friday, February 13, 2015 18:26
To: sprdlinux@xxxxxxxxxxxxx
Cc: Chunyan Zhang (张春艳)
Subject: [sprdlinux] Re: Help with spreadtrum kernel
Exactly! I think they changed the touch module too (I have not spent much time
on that yet).
Thank you, Orson - lets see what the Zen people say.
On Fri, Feb 13, 2015 at 2:44 PM, Orson Zhai (翟京)
<Orson.Zhai@xxxxxxxxxxxxxx<mailto:Orson.Zhai@xxxxxxxxxxxxxx>> wrote:
Hi, G2,
I know your situation very clear now.
I think Zen changed the LCD themselves and wrote the driver.
Now I get 2 way to go in same time.
one is to ask FAE for Zen driver source.
the other is to ask kernel engineer review your problem and tell us how to use
the register, maybe 1 or 2 bits definition is enough for us.
I have sent them emails just waiting for reply.
Orson
________________________________
From: sprdlinux-bounce@xxxxxxxxxxxxx<mailto:sprdlinux-bounce@xxxxxxxxxxxxx>
<sprdlinux-bounce@xxxxxxxxxxxxx<mailto:sprdlinux-bounce@xxxxxxxxxxxxx>> on
behalf of Abhishek Goyal <abgoyal@xxxxxxxxx<mailto:abgoyal@xxxxxxxxx>>
Sent: Thursday, February 12, 2015 18:59
To: sprdlinux@xxxxxxxxxxxxx<mailto:sprdlinux@xxxxxxxxxxxxx>
Cc: Chunyan Zhang (张春艳); Zhizhou Zhang (张治洲); Geng Ren (任赓)
Subject: [sprdlinux] Re: Help with spreadtrum kernel
Orson,
That was the first thing I tried as thats the default config in the
arch/arm/configs/sp6821a-vlx_defconfig (after git checkout
sprdb2g_gonk4.0_6821):
#
# Frame buffer hardware drivers
#
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_BROADSHEET is not set
CONFIG_FB_SC8810=y
# CONFIG_FB_LCD_NOFMARK is not set
# CONFIG_FB_LCD_HX8369 is not set
# CONFIG_FB_LCD_ILI9486 is not set
# CONFIG_FB_LCD_ILI9341_BOE is not set
# CONFIG_FB_LCD_ILI9341_BOE_MINT is not set
CONFIG_FB_LCD_HX8357=y
# CONFIG_FB_LCD_RM6158_TRULY is not set
# CONFIG_FB_LCD_HX8357_OPENPHONE is not set
# CONFIG_FB_LCD_NT35516 is not set
CONFIG_FB_LCD_OVERLAY_SUPPORT=y
# CONFIG_FB_LCD_NT35510 is not set
# CONFIG_FB_LCD_S6D04H0 is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
It doesn't work - the display shows the Ultrafone boot logo (shown by the boot
loader) and the display flips over (left to right) when the kernel takes over,
and thats it - nothing else shows up. I also checked in the /proc/kmsg. So
first problem was that the driver in hx8357-1.c reports lcd_id = 0x57, but the
bootloader has set lcd_id = 0x99. so the kernel refuses to configure the
driver. I manually changed the lcd_id to 0x99 in hx8357-1.c but that didn't fix
the display - the kernel messages show that the kernel probe completed, and lcd
driver was initialized, but it doesn't work.
Also, I ran a "strings" on the factory 2ndbl image and factory boot.img, and
looked thru everything to see if there was anything looking like an lcd driver,
and the lines i found were:
in the 2ndbl:
ili9481_readid(0): 0x%x
ili9481_readid(1): 0x%x
ili9481_readid(2): 0x%x
ili9481_readid(3): 0x%x
ili9481_readid(4): 0x%x
ili9481_readid: 0x%x
ili9481_set_direction
ili9481_invalidate_rect : (%d, %d, %d, %d)
ili9481_invalidate
ili9481_set_window
ili9481_enter_sleep
ili9481_init
in the boot.img kernel:
lcd_id=
sprd_lcdc_uninit
sprd_lcdc_suspend
sprd_lcdc_resume
sprd_lcd_led_earlysuspend
sprd_lcd_led_lateresume
lcd-backlight
lcd_res
clk_lcdc
<3>lcdc: sprd_lcdc_sync time out!!!!!
sprdfb can not do sprd_lcdc_display_overlay !!!!
sprdfb do sprd_lcdc_display_overlay time out!
<3>sprdfb: sprd_lcdc_enable_overlay fail. (dev not enable)
<3>sprdfb: sprd_lcdc_enable_overlay fail (Invalid parameter)
<3>sprd_fb: sprd_lcdc_enable_overlay fail. (wait done fail)
<3>sprd_fb: sprd_lcdc_enable_overlay fail. (invalid layer index)
<3>lcdc: failed to request irq!
lcd_hx8357
<3>LCD NT53310:could not get lcd regulator
<3>LCD NT53310:could not enable lcd regulator
<3>LCD NT53310:could not set lcd to 3000mv.
<3>LCD NT53310:could not get lcdio regulator
<3>LCD NT53310:could not enable lcdio regulator
<3>LCD NT53310:could not set lcdio to 1800mv.
lcd_nt35510
lcd_ili9481
lcd_nt35310
lcd_hx8357d
lcd_ili9488
lcd_r61581b
vlcd
<6>autotst-> lcd data = 0x%X
lcm_close
<3>can not get clk_lcdc!!!!!
As you can see, the 2ndbl only contains references to the ili9481 LCD module,
and the kernel contains references to many, including ili9481. I tried ALL the
modules one by one, by changing the kernel config. The only one that gave me
anything on the display was lcd_ili9486, which is similar to ili9481. I had the
programming manual of ili9481, so i wrote the driver for it, and that also
works partially, as you can see from the screenshot (attached)
But there is still some problem remaining: Its either due to some issue in the
configuration of the OSD1_CTRL - i think that is the one where DMA from system
memroy framebuffer to LCD module GRAM is configured.
I wrote some scripts to write to the /dev/graphics/fb0 device directly. And
what I found was this: if I write the pattern like
0x12 0x34 0x56 0x78 0x12 0x34 0x56 0x78.....
and fill the framebuffer with it, the LCD module only sees:
0x12 0x56 0x12 0x56
thus it is only recieving 8 bits out of each 16 bits of pixel data from system
framebuffer. Thats is why I am getting that quarter screen display - half
pixels, and then odd lines on left and even lines on right.
So either it is a problem in the timing somehow the LCD module is only latching
8 bits of data out of 16 bits, or its a problem with the DMA controller
configuration in OSD1_CTRL - maybe it is reading 16 bits but only writing 8
bits to the LCD module bus?
I understand about not being able to release the documents...but could you just
ask the folks at Zen to give a copy of their own kernel source? or even just
their kernel .config and contents of their kernel/drivers directory?
-G2
On Thu, Feb 12, 2015 at 8:41 AM, Orson Zhai (翟京)
<Orson.Zhai@xxxxxxxxxxxxxx<mailto:Orson.Zhai@xxxxxxxxxxxxxx>> wrote:
Hi, G2,
I got the info that Zen use hx8357d for their phones.
I see there are hx8357.c and hx8357-1.c files.
And the data in following structure matches the spec listed at Zen website.
357 struct panel_spec lcd_panel_hx8357 = {
358 .width = 320,
359 .height = 480,
Hope this info would be helpful to you.
And regarding the register settings, I am afraid that there is no way to
release the datasheet out even part of them.
What we could do is to hack the code released from open source.
Tell me your progress or any help needed.
Orson
________________________________
From: Abhishek Goyal <abgoyal@xxxxxxxxx<mailto:abgoyal@xxxxxxxxx>>
Sent: Wednesday, February 11, 2015 16:30
To: Orson Zhai (翟京)
Cc: Chunyan Zhang (张春艳); Zhizhou Zhang (张治洲); Geng Ren (任赓);
sprdlinux@xxxxxxxxxxxxx<mailto:sprdlinux@xxxxxxxxxxxxx>
Subject: Re: Help with spreadtrum kernel
Yes, I am also interested in this amazing chip - so many possibilities at such
low cost!
I have also talked to Vance@mozilla - they have also not modified, so its just
Zen that is left. I could not find any way to contact them - I wrote to their
retail customer service, but of course that is not very promising.
I'd appreciate it if you could either talk to your FAE and see if something is
possible. I understand that might not be fast.
In addition - I think I have the LCD driver mostly working, but might be
setting the LCD_CTRL or LCM_CTRL or LCDC_OSD1_CTRL or LCM_TIMING0 or
LCM_TIMING1 registers wrong inside lcdc.c and lcdpanel.c. As you can see from
my posts on mozilla, It seems what is happening is this:
1. The framebuffer in linux memory is 16bpp.
2. LCD controller writes these pixels to lcd panel over MCU8080-type bus
3. I think I have wrongly configured the LCD controller - it reads 16 bits of
data from the main memory framebuffer, but writes only 8 bits to the MCU8080bus
of the LCD panel. So when the next pixel is written, it is also 8 bits only and
the LCD panel sees two pixels as only one pixel. This is the cause of the wrong
display.
So if you could just give me some pointers on the various flags/settings of the
LCD_CTRL, LCM_CTRL, LCDC_OSD1_CTRL, LCM_TIMING0, LCM_TIMING1 - maybe I could
fix it myself?
Of course if Zen released their proper kernel, that would be ideal, but I
believe with a little bit of help from spreadtrum I can get this to work
myself. Only LCD and touchscreen seem to be giving problem, everything else
seems to be working fine.
I will subscribe to the mailing list - thanks for telling me about it!
-G2
On Wed, Feb 11, 2015 at 9:58 AM, Orson Zhai (翟京)
<Orson.Zhai@xxxxxxxxxxxxxx<mailto:Orson.Zhai@xxxxxxxxxxxxxx>> wrote:
Hi, G2,
Thanks for your interest on sc6821 kernel.
Regards on your question, I searched my git tree in internal server of
spreadtrum and I didn't find the LCD driver you request either.
here, the commit 1556da1f seems not a kernel commit id.
I searched my whole tree and I didn't find any keyword of zen, u105 or even
related 105.
I also failed to find any lcd info regards on 0x99 or ili9481.
my tree of video part looks like:
drivers/video/spreadtrum/
├── Kconfig
├── lcdc.c
├── lcd_hx8357_1.c
├── lcd_hx8357.c
├── lcd_hx8357_openphone.c
├── lcd_hx8369.c
├── lcd_ili9341_boe.c
├── lcd_ili9341_boe_mint.c
├── lcd_ili9486.c
├── lcd_nt35510.c
├── lcd_nt35516.c
├── lcdpanel.c
├── lcdpanel.h
├── lcd_rm6158_truly.c
├── lcd_s6d04h0.c
├── Makefile
├── sprdfb.h
└── sprdfb_main.c
I guess they are same as yours.
my branches are
# git branch -r | grep 6821
korg/sprdb2g_gonk4.0_6821
korg/sprdb2g_gonk4.0_6821_mp
So, I guess the Zen 105 code was modified by our FAE (or even mozilla guys)
which is not sync with spreadtrum kernel team.
That makes sense because our customers always have a strong willing on cost
down.
They may make some changes at the last minute.
I will forward this question to FAE for you, but I am not sure if they could
response me soon.
BTW, you could join our public mailing list
sprdlinux@xxxxxxxxxxxxx<mailto:sprdlinux@xxxxxxxxxxxxx> or you also could touch
me at #sprdlinux @ freednode irc.
I am also interesting on sc682x for its amazing low price.
Happy hacking!
Orson
________________________________
From: Abhishek Goyal <abgoyal@xxxxxxxxx<mailto:abgoyal@xxxxxxxxx>>
Sent: Tuesday, February 10, 2015 21:32
To: Zhizhou Zhang (张治洲)
Cc: Orson Zhai (翟京); Chunyan Zhang (张春艳)
Subject: Re: Help with spreadtrum kernel
Thanks for response Zhizhou!
Orrzon/Chunyan: Could you please take a look and see if something can be done:
I am trying to build kernel for Zen 105 Firefox mobile phone which is based on
6821 SoC and sp6821a_gonk. Mostly the kernel is working but I am missing
information about LCD Controller and Touch screen controller. I did a git clone
from spreadtrum git repo at
http://sprdsource.spreadtrum.com:8085/b2g/android/kernel/common
Any information would be useful!
-G2
On Tue, Feb 10, 2015 at 5:26 PM, Zhizhou Zhang (张治洲)
<Zhizhou.Zhang@xxxxxxxxxxxxxx<mailto:Zhizhou.Zhang@xxxxxxxxxxxxxx>> wrote:
Hi Abhishek,
I am very glad that somebody outside our company be insteresting about our
product. I'm now in Korea.
So maybe orrzon and chunyan can help you.
--
Zhizhou
________________________________
From: Abhishek Goyal <abgoyal@xxxxxxxxx<mailto:abgoyal@xxxxxxxxx>>
Sent: Tuesday, February 10, 2015 7:39 PM
To: Zhizhou Zhang (张治洲)
Subject: Help with spreadtrum kernel
Hi Zhizhou,
Sorry for contacting you like this - I found your name attached to spreadtrum
commits on the LKML.
I am trying to build kernel for spreadtrum 6821 SoC, but some problem with LCD
Controller settings.
Is it possible for you to help me a bit, or put me in touch with someone at
spreadtrum?
Details of what I have done till now are found here:
https://groups.google.com/forum/#!topic/mozilla.dev.b2g/G56RgAgcOOM
and here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1128904
I'd really appreciate any help. Thanks!
-G2
--
Take the carbon, leave the bible
--
Take the carbon, leave the bible
--
Take the carbon, leave the bible
--
Take the carbon, leave the bible
Other related posts:
