[sprdlinux] Re: Help with spreadtrum kernel
- From: Abhishek Goyal <abgoyal@xxxxxxxxx>
- To: sprdlinux@xxxxxxxxxxxxx
- Date: Fri, 13 Feb 2015 16:38:32 +0530
No, what I did was i wrote some scripts to write bitpatterns to frame
buffer. The reason it is not half screen is this:
LCD expects 16 bits per pixel, Somehow it is only getting 8 bits. So what
happens is, two pixels worth of data: 0x12 0x34 0x56 0x78 is in
framebuffer, but LCD sees only 0x12 0x56. This 16 bit of data LCD sees as
data for ONE pixel.
So, LCD Controller write one-line worth of data (320 pixels x 2 bytes per
pixel = 640 bytes), LCD Module sees only half line worth of data (320
bytes). Then when LCD Controller send the NEXT line of data (line 2) LCD
module thinks this is just for the remaining half of the first line.
So what you get is lines 1, 3, 5, 7 etc get shown on left quarter of
screen, and lines 2, 4, 6, 8 etc get shown on right quarter of screen.
I am not sure I have explained this clearly - it took me many days to
figure this out :D
On Fri, Feb 13, 2015 at 4:31 PM, Orson Zhai (翟京) <Orson.Zhai@xxxxxxxxxxxxxx>
wrote:
> 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> 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 <sprdlinux-bounce@xxxxxxxxxxxxx>
>> on behalf of Abhishek Goyal <abgoyal@xxxxxxxxx>
>> *Sent:* Thursday, February 12, 2015 18:59
>> *To:* 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> 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>
>>> *Sent:* Wednesday, February 11, 2015 16:30
>>> *To:* Orson Zhai (翟京)
>>> *Cc:* Chunyan Zhang (张春艳); Zhizhou Zhang (张治洲); Geng Ren (任赓);
>>> 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> 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 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>
>>>> *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> 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>
>>>>> *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
>
>
--
Take the carbon, leave the bible
Other related posts:
