Re: [Lager(H2)-V4.10-rc2]: DISPLAY-UNIT: Does not support 640x480 resolution & Does not support 16-bit for color numbers.

2017-02-02 Thread DongCV 

Dear Laurent,

I apologize for the delayed response.
I've understoodyour opinion. Thank you very much.

Regards,
Dong


On 01/31/2017 06:47 PM, Laurent Pinchart wrote:

Hello Dong,

On Tuesday 31 Jan 2017 15:49:34 DongCV wrote:

DearLaurent,
cc: Geert


Cfr. Laurent Pinchart's answer in the thread "Re: The failure summary

report of GEN2 for linux stable v4.10-rc2":
| I confirm your analysis. However, I think this isn't a new issue. Before
| the aforementioned patch, running
|
| # fbset -xres 640 -yres 480 -laced 0
| # fbset -depth 16 -rgba 5,6,5,0
|
| didn't produce any error, but didn't either resize the display to
| 640x480 or changed the pixel format. With the patch applied, the
| commands are rejected as they should be, as they wouldn't produce the
| expected results. The new behaviour is thus in my opinion correct.

http://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg10879.htm
l

I understood your opinion.
However,I wonder why the display size has changed when I implement the
following test procedure.
Could you explain it to me?

* Changed the resolution.
- Perform the following command:
# bmap / dev / fb0 hdmi.bmp (Initial default size is 1024x768.  Please
have look at 1024x768.jpg image)
# fbset -xres 640 -yres 480 -laced 0
# bmap / dev / fb0 hdmi.bmp

I saw the screen size has changed after running the following command.
"#fbset -xres -laced 0 480 640 -yres"(Please have look at 640x480.jpg image)
but I run the following command again
"#bmap / dev / fb0 hdmi.bmp", the image size did not change.

Implement similarly with the 800x600 resolution. (Please have look at
800x600.jpg image)

That's because the screen resolution has not changed. Only the size reported
to the fbdev emulation layer is updated, the screen resolution and framebuffer
stay the same. This is exactly why changing the resolution through the fbdev
device has been disabled recently, it just didn't work. This is a feature that
will never be supported and should thus not be used.

The purpose of the fbdev compatibility layer is to enable the framebuffer
kernel console on top of a DRM/KMS device. The userspace API is available for
applications to use, but they should not expect the full feature set of fbdev.
Applications should be migrated to DRM/KMS.


* Changed the pixel format.
- Perform the following command:
# fbset -depth 16 -rgba 5,6,5,0
# bmap /dev/fb0 hdmi.bmp

(Please have look at pixel_16bit.jpg image)

# fbset -depth 32 -rgba 5,6,5,0
# bmap /dev/fb0 hdmi.bmp

(Please have look at pixel_32bit.jpg image)

I realize that 16bit set image differs from 32bit set image.

Please have a look at the attached image for detail.

This isn't supported for the same reason as above.

Re: [Lager(H2)-V4.10-rc2]: DISPLAY-UNIT: Does not support 640x480 resolution & Does not support 16-bit for color numbers.

2017-01-26 Thread Geert Uytterhoeven 
Hi Dong,

On Fri, Jan 27, 2017 at 6:38 AM, DongCV  wrote:
> I've tested the linux v4.10-rc2 for Gen2 Lager and found two issues about
> DISPLAY-UNIT:  Does not support 640x480 resolution & Does not support 16-bit
> for color numbers.
>
> "root@linaro-naro:~# fbset -xres 640 -yres 480 -laced 0
>  ioctl FBIOPUT_VSCREENINFO: Invalid argument"
>
> "root@linaro-naro:~# fbset -depth 16 -rgba 5,6,5,0
>  ioctl FBIOPUT_VSCREENINFO: Invalid argument"
>
>
> And I found the patch which I think it is the cause of this issues.
> The commit name is '865afb1 drm/fb-helper: reject any changes to the fbdev'
> If I reverted this patch and retested it on H2 board, the issue will be
> gone!
>
> Please have a look at the attached testlog file for detail.

Do you get the correct output on the display after reverting that patch?

Cfr. Laurent Pinchart's answer in the thread "Re: The failure summary
report of GEN2 for linux stable v4.10-rc2":

| I confirm your analysis. However, I think this isn't a new issue. Before
| the aforementioned patch, running
|
| # fbset -xres 640 -yres 480 -laced 0
| # fbset -depth 16 -rgba 5,6,5,0
|
| didn't produce any error, but didn't either resize the display to
| 640x480 or changed the pixel format. With the patch applied, the
| commands are rejected as they should be, as they wouldn't produce the
| expected results. The new behaviour is thus in my opinion correct.

http://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg10879.html

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[Lager(H2)-V4.10-rc2]: DISPLAY-UNIT: Does not support 640x480 resolution & Does not support 16-bit for color numbers.

2017-01-26 Thread DongCV 

Dear Stefan,
Cc: Geert,

I've tested the linux v4.10-rc2 for Gen2 Lager and found two issues 
about DISPLAY-UNIT:  Does not support 640x480 resolution & Does not 
support 16-bit for color numbers.


"root@linaro-naro:~# fbset -xres 640 -yres 480 -laced 0
 ioctl FBIOPUT_VSCREENINFO: Invalid argument"

"root@linaro-naro:~# fbset -depth 16 -rgba 5,6,5,0
 ioctl FBIOPUT_VSCREENINFO: Invalid argument"


And I found the patch which I think it is the cause of this issues.
The commit name is '865afb1 drm/fb-helper: reject any changes to the fbdev'
If I reverted this patch and retested it on H2 board, the issue will be 
gone!


Please have a look at the attached testlog file for detail.


Regards,
Dong

LAGER SPI_LOADER V0.27 2014.06.20
DEVICE S25FL512


U-Boot 2016.01 (Jul 27 2016 - 15:27:42 +0900)

CPU: Renesas Electronics R8A7790 rev 2.0
Board: Lager
I2C:   ready
DRAM:  512 MiB
MMC:   sh_mmcif: 0, sh-sdhi: 1, sh-sdhi: 2
SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, total 
64 MiB
In:serial_sh
Out:   serial_sh
Err:   serial_sh
Net:   sh_eth
Hit any key to stop autoboot:  0 
sh_eth Waiting for PHY auto negotiation to complete.. done
sh_eth: 100Base/Half
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
DHCP client bound to address 192.168.1.235 (5781 ms)
Using sh_eth device
TFTP from server 192.168.1.225; our IP address is 192.168.1.235
Filename 'lager/uImage.dtb'.
Load address: 0x40007fc0
Loading: #
 #
 #
 #
 7.5 MiB/s
done
Bytes transferred = 3750536 (393a88 hex)
## Booting kernel from Legacy Image at 40007fc0 ...
   Image Name:   Linux-v4.10-rc2
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3750472 Bytes = 3.6 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   XIP Kernel Image ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.10.0-rc2-dirty (dong@dong-Jinso) (gcc version 
4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) ) #275 SMP Thu Jan 19 13:29:13 JST 
2017
[0.00] CPU: ARMv7 Processor [413fc0f2] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[0.00] OF: fdt:Machine model: Lager
[0.00] OF: fdt:Ignoring memory block 0x14000 - 0x2
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 262144
[0.00] free_area_init_node: node 0, pgdat c0a32840, node_mem_map 
ef7f9000
[0.00]   Normal zone: 1536 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 196608 pages, LIFO batch:31
[0.00]   HighMem zone: 65536 pages, LIFO batch:15
[0.00] percpu: Embedded 12 pages/cpu @ef775000 s25152 r0 d24000 u49152
[0.00] pcpu-alloc: s25152 r0 d24000 u49152 alloc=12*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260608
[0.00] Kernel command line: console=ttySC0,38400 ignore_loglevel rw 
root=/dev/nfs ip=dhcp
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1029252K/1048576K available (6144K kernel code, 207K 
rwdata, 1488K rodata, 1024K init, 300K bss, 19324K reserved, 0K cma-reserved, 
262144K high)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xf080 - 0xff80   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xf000   ( 768 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00]   .text : 0xc0008000 - 0xc070   (7136 kB)
[0.00]   .init : 0xc090 - 0xc0a0   (1024 kB)
[0.00]   .data : 0xc0a0 - 0xc0a33c60   ( 208 kB)
[0.00].bss : 0xc0a35000 - 0xc0a8020c   ( 301 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] arm_arch_timer: Architected cp15 timer(s) running at 10.00MHz 
(virt).
[0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[0.04] sched_clock: 56