[sprdlinux] Re: Help with spreadtrum kernel
- From: Abhishek Goyal <abgoyal@xxxxxxxxx>
- To: sprdlinux@xxxxxxxxxxxxx
- Date: Sun, 8 Mar 2015 21:37:07 +0530
Lyra, Orson - thanks for the suggestions. I got stuck into something else,
but now I have tried all the combinations :-/
First the byte order combinations, these are the results:
byte order (bit[8:7])
0 = gggrrrrr xxxxxxxx bbbbbGGG xxxxxxxx
1 = xxxxxxxx bbbbbGGG xxxxxxxx gggrrrrr
2 = bbbbbGGG xxxxxxxx gggrrrrr xxxxxxxx
3 = gggrrrrr xxxxxxxx bbbbbGGG xxxxxxxx
r = red
b = blue
g = lower 3 bits of green
G = higher 3 bits of green
x = doesn't matter - no effect on display
So while the quarter screen effect does not get fixed, the pixels do move
around as expected when i change the byte order. The surprise is why "0"
and "3" have the same result. There might be some clue there - the bytes
should have been swapped around, like in the case of "1" and "2".
Then I tried all the combinations of the pixel format
format (bit[6:3])
0,1,2 = invalid - some random crap on screen
3 = 4x4 effect (like 2x2 effect) but screen is split 4x4 instead of 2x2
4 = 4x4 effect but different palette
5 = normal 2x2 effect
6 = normal 2x2 effect
7 = nothing shows up, clear top half, do effect to the fb even with cat
I even tried "3" with bpp set to 32 - but that also doesn't get me
anywhere. In any case, I know that in the factory kernel , the FB memory is
600KB = 320*480*2 bytes per pixel * 2 buffers.
Could one of you tell me what the meaning of these params is:
static uint32_t mcu_calc_timing(struct timing_mcu *timing)
{
uint32_t ahb_clk;
uint32_t rcss, rlpw, rhpw, wcss, wlpw, whpw;
I mean css, hpw, lpw - what do they stand for? If I know that,
I can read the correct values from the data sheet and set those.
Another experiment I am trying is replace the OSD1 DMA with a normal C
loop - it will be slow
but I can control the pixel writing tightly. My first attempt makes
the kernel reboot without adb
so I am still trying.
Also, it seems Zen hired IMG mobile to do the kernel work for this. If
one of you know someone
there, maybe they can give us the required info? Just the details
necessary to hack this?
-G2
PS: Hope you guys had a fun vacation! btw - what do you do on the New
Year? How is it celebrated?
On Sat, Feb 28, 2015 at 9:15 PM, Orson Zhai <orsonzhai@xxxxxxxxx> wrote:
> Hi, G2,
>
>
> On 2015年02月28日 16:20, Lyra Zhang wrote:
>
>> Hi, G2
>>
>> Sorry for late reply, I just came back from CNY holidays.
>> I've just had a look at those registers you pasted below, I think
>> LCDC_OSD1_CTRL configuration might be worth to consider.
>> details are below.
>>
>> On Sat, Feb 21, 2015 at 2:53 AM, Abhishek Goyal <abgoyal@xxxxxxxxx>
>> wrote:
>>
>>> (forgot to CC the list as well :D)
>>>
>>> sorry, forgot to attach.
>>>
>>> Also, this is the settings i see in my *custom* kernel:
>>>
>>> <4>0[ 2.663106] LCDC_CTRL: 0x13
>>> <4>0[ 2.663113] LCDC_DISP_SIZE: 0x1e00140
>>> <4>0[ 2.663121] LCDC_LCM_START: 0x0
>>> <4>0[ 2.663129] LCDC_LCM_SIZE: 0x1e00140
>>> <4>0[ 2.663137] LCDC_BG_COLOR: 0xffffff
>>> <4>0[ 2.663145] LCDC_FIFO_STATUS: 0x295565
>>> <4>0[ 2.663153] LCM_CTRL: 0x200000
>>> <4>0[ 2.663161] LCM_TIMING0: 0x9f90a76
>>> <4>0[ 2.663169] LCM_RDDATA: 0x99
>>> <4>0[ 2.663176] LCDC_IRQ_EN: 0x1
>>> <4>0[ 2.663183] LCDC_OSD1_CTRL: 0x12d
>>>
>> bit[8:7] OSD layer data byte order in a 32bit word, the source is
>> B0B1B2B3, the destination is :
>> 0 - B0B1B2B3
>> 1 - B3B2B1B0
>> 2 - B2B3B0B1
>> 3 - B1B0B3B2
>>
>> bit[6:3] OSD layer format,
>> 0011 - RGB888
>> 0100 - RGB666
>> 0101 - RGB565
>>
> I have get some information of spreadtrum always using rgb888 (24bits
> color) in kernel.
> So the setting to 0101 seems wrong.
> It should be 0011 as usual.
>
> Orson
>
>
> 0110 - RGB555
>> 0111 - GREY
>>
>>
>> Best regards,
>> Chunyan
>>
>> <4>0[ 2.663191] LCDC_OSD1_BASE_ADDR: 0x684b000
>>> <4>0[ 2.663200] LCDC_OSD1_ALPHA_BASE_ADDR: 0x0
>>> <4>0[ 2.663208] LCDC_OSD1_SIZE_XY: 0x1e00140
>>> <4>0[ 2.663217] LCDC_OSD1_PITCH: 0x140
>>> <4>0[ 2.663224] LCDC_OSD1_DISP_XY: 0x0
>>> <4>0[ 2.663232] LCDC_OSD1_ALPHA : 0xff
>>>
>>> just in case some one can spot a problem.
>>>
>>> Also, does this seem like a problem that can happen due to bad timing
>>> configuration in LCM_TIMING0? I have not played with the timing
>>> configuration much, but just in case inside the chip there are two 8-bit
>>> latches (one each for [0:7] and [8:15], and the higher bits latch is
>>> slower?
>>> Do you think this is possible?
>>>
>>> Can someone explaing what is the meaning of the following params:
>>> ***
>>> static uint32_t mcu_calc_timing(struct timing_mcu *timing)
>>> {
>>> uint32_t ahb_clk;
>>> uint32_t rcss, rlpw, rhpw, wcss, wlpw, whpw;
>>>
>>> ***
>>>
>>> in lcdpanel.c? They are configured in the lcd driver. I just took the
>>> same
>>> values as in ILI9486, but maybe there is some problem there? But I don't
>>> understand what rcss, rlpw, rhpw, wcss, wlpw, whpw mean. I guess the
>>> first r
>>> and w are read and write, but what is css, lpw, hpw? How do I find those
>>> out
>>> from the data sheet?
>>>
>>>
>>>
>>>
>>> On Fri, Feb 20, 2015 at 8:00 PM, Abhishek Goyal <abgoyal@xxxxxxxxx>
>>> wrote:
>>>
>>>> Thanks Lyra. Sorry for late reply, I was travelling since sunday and
>>>> have
>>>> just returned.
>>>>
>>>> If I see kernel/drivers/video/spreadtrum/lcdpanel.c (attached), the
>>>> settings seem correct. The only thing I can thing of is maybe the LCD
>>>> panel
>>>> is connected by Zen on CS=1 rather than CS=0 and thats why this is
>>>> happening. I will try and write back.
>>>>
>>>> One more thing:
>>>>
>>>> I was trying to read the register settings in the factory kernel by
>>>> mmap-ing the register area. The MMAP call succeeds, but then I can't
>>>> read
>>>> from the mapped area - the phone hangs! Does anyone have any idea why
>>>> that
>>>> would happen?
>>>>
>>>>
>>>> On Sun, Feb 15, 2015 at 2:55 PM, Lyra Zhang <zhang.lyra@xxxxxxxxx>
>>>> wrote:
>>>>
>>>>> Hi, G2
>>>>>
>>>>> I've looked through the manual, there is a LCM_CTRL register whose
>>>>> offset is 0x0180, hope that it can help you.
>>>>>
>>>>> bit[5:4] Panel pixel data bit width for LCM0, reset value is 2'h0
>>>>> 0 - 16bits
>>>>> 1 - 18bits
>>>>> 2 - 24bits
>>>>>
>>>>> bit[3:1] LCM interface bus width for LCM0, reset value is 3'h0
>>>>> 0 - 8bits
>>>>> 1 - 9bits
>>>>> 2 - 16bits
>>>>> 3 - 18bits
>>>>> 4 - 24bits
>>>>>
>>>>> the same to bit[13:12] & bit[11:9] for LCM1
>>>>>
>>>>> Best regards,
>>>>> Chunyan
>>>>>
>>>>> On Sat, Feb 14, 2015 at 2:13 AM, Abhishek Goyal <abgoyal@xxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>> I am attaching the driver I have been using and the data sheet for
>>>>>> ili9481.
>>>>>> I already tried bus_width = 8 and bus_width = 16.
>>>>>>
>>>>>> If I set bus_width = 8, then the LCD does not get configured properly
>>>>>> and I
>>>>>> can see timeout errors in /proc/kmsg.
>>>>>> If i set bus_width = 16, the lcd works, but as I showed you, it only
>>>>>> sees
>>>>>> half the pixels.
>>>>>>
>>>>>> I can't find anything in the LCD module manual that allows me to set
>>>>>> the
>>>>>> correct bus width in the LCD module configuration. If you look at the
>>>>>> manual
>>>>>> I have attached, page 8, IM[2:0] hardware pins control the bus width.
>>>>>> So bus
>>>>>> width for the LCD is configured by connection these three pins, which
>>>>>> Zen
>>>>>> would have done. Then pixel format which is 565, is set in one of the
>>>>>> registers.
>>>>>>
>>>>>> But how to tell the sp6821 DMA to do 8-bit writes instead of 16 bit
>>>>>> writes.
>>>>>> There must be something in the LCDC_CTRL which allows us to do that.
>>>>>>
>>>>>> See if you can spot something in the driver/manual.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 13, 2015 at 11:33 PM, Orson Zhai <orsonzhai@xxxxxxxxx>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On 2015年02月14日 02:01, Orson Zhai wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 2015年02月14日 01:42, Abhishek Goyal wrote:
>>>>>>>>
>>>>>>>>> On Fri, Feb 13, 2015 at 10:59 PM, Orson Zhai <orsonzhai@xxxxxxxxx>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I am think one possible case is Zen might change the LCD panel
>>>>>>>>>> data
>>>>>>>>>> width
>>>>>>>>>> to 8bit for transferring 16bit color.
>>>>>>>>>> Then in normal, lcd driver should write twice for 1 pixel ---- 1st
>>>>>>>>>> time
>>>>>>>>>> for lower 8 bits and 2nd time for higher 8bit.
>>>>>>>>>> But the driver we used is ili9684 which is still think LCD panel
>>>>>>>>>> is
>>>>>>>>>> with
>>>>>>>>>> 16bits width.
>>>>>>>>>> And the driver copies 16bit as 1 pixel to LCD interface.
>>>>>>>>>> Then, the higher byte (0xff) is ignored by lcd data bus and only
>>>>>>>>>> the
>>>>>>>>>> lower
>>>>>>>>>> byte gets into panel.
>>>>>>>>>> So , if we tell lcd controller " hey, the LCD interface is 8bit
>>>>>>>>>> width,
>>>>>>>>>> pls
>>>>>>>>>> take 16 bits color for 8bit x 2" everything maybe ok.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes - exactly. Now, from reading the sprd source code, what I have
>>>>>>>>> understood (I could be wrong) is the way the LCDC controller works
>>>>>>>>> is:
>>>>>>>>>
>>>>>>>>> 1. You write the PHYSICAL address of frambuffer to
>>>>>>>>> LCDC_OSD1_BASE_ADDR
>>>>>>>>> and
>>>>>>>>> other OSD1 configuration:
>>>>>>>>>
>>>>>>>>> from kernel/drivers/video/spreadtrum/lcdc.c
>>>>>>>>>
>>>>>>>>> uint32_t base = fb->fix.smem_start +
>>>>>>>>> fb->fix.line_length
>>>>>>>>> *
>>>>>>>>> fb->var.yoffset;
>>>>>>>>> <...>
>>>>>>>>>
>>>>>>>>> uint32_t size = (fb->var.xres & 0xffff) |
>>>>>>>>> ((fb->var.yres)
>>>>>>>>> << 16);
>>>>>>>>>
>>>>>>>>> lcdc_write(base, LCDC_OSD1_BASE_ADDR);
>>>>>>>>> lcdc_write(0, LCDC_OSD1_DISP_XY);
>>>>>>>>> lcdc_write(size,LCDC_OSD1_SIZE_XY);
>>>>>>>>> lcdc_write(fb->var.xres, LCDC_OSD1_PITCH);
>>>>>>>>>
>>>>>>>>> lcdc_write(size, LCDC_DISP_SIZE);
>>>>>>>>>
>>>>>>>>> And then when you do:
>>>>>>>>>
>>>>>>>>> lcdc_set_bits((1 << 3), LCDC_CTRL);
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The LCD controller in the 6821 does DMA of frame buffer datafrom
>>>>>>>>> LCDC_OSD1_BASE_ADDR to the LCD module bus.
>>>>>>>>>
>>>>>>>>> So something in the LCDC_CTRL or LCM_CTRL or LCDC_OSD1_CTRL is
>>>>>>>>> misconfigured - it needs to be told that the bus width is only 8
>>>>>>>>> bits.
>>>>>>>>>
>>>>>>>>> Now I tried to set the bus_width = 8 in the ili9481 driver itself,
>>>>>>>>> it
>>>>>>>>> made
>>>>>>>>> the display not work. Nothing showed up on screen and there were
>>>>>>>>> various
>>>>>>>>> timeouts on /proc/kmsg.
>>>>>>>>>
>>>>>>>>> I am looking at the code in ili9684.c:
>>>>>>>>
>>>>>>>
>>>>>>> typo, should be ili9486.c
>>>>>>>
>>>>>>>>
>>>>>>>> static struct info_mcu lcd_ili9486_info = {
>>>>>>>> .bus_mode = LCD_BUS_8080,
>>>>>>>> .bus_width = 18, ^^^^^^^^^^^^^^^^
>>>>>>>> .bpp = 18, /*RGB88*/ ^^^^^^^^^^^^^^^^
>>>>>>>> .timing = &lcd_ili9486_timing,
>>>>>>>> .ops = NULL,
>>>>>>>> };
>>>>>>>> if changes to:
>>>>>>>> .bus_width = 8,
>>>>>>>> .bpp = 16, /*RGB565*/ the driver will auto config the registers? i
>>>>>>>> have
>>>>>>>> attached an ili9684.c which is sent from some guys this evening.
>>>>>>>>
>>>>>>>
>>>>>>> ili9486.c
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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:
