From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Mon, 10 Mar 2014 07:21:47 +0100 Subject: [U-Boot] [PATCH] video: Add support for TI's AM335x LCD-Controller In-Reply-To: <20595.213.33.116.113.1394188112.squirrel@petermaier.org> References: <1394113146-21238-1-git-send-email-oe5hpm@oevsv.at> <53187EF3.1020405@denx.de> <53188506.2090809@petermaier.org> <53196BAA.2050808@denx.de> <20595.213.33.116.113.1394188112.squirrel@petermaier.org> Message-ID: <531D59FB.7060006@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Hannes, Am 07.03.2014 11:28, schrieb Hannes Petermaier: > Hi Heiko, > > Heiko Schocher wrote: >> Hello Hannes, >> >> Am 06.03.2014 15:24, schrieb Hannes Petermaier: >>> On 2014-03-06 14:58, Heiko Schocher wrote: >>>> Hello Hannes, >>>> >>>> Am 06.03.2014 14:39, schrieb Hannes Petermaier: >>>>> - Adds support for a minimal framebuffer driver of TI's AM335x SoC >>>>> to be compatible with Wolfgang Denk's LCD-Framework (CONFIG_LCD, >>>>> common/lcd.c) >>>>> >>>>> Signed-off-by: Hannes Petermaier >>>>> --- >>>>> drivers/video/Makefile | 1 + >>>>> drivers/video/am335x-fb.c | 169 >>>>> +++++++++++++++++++++++++++++++++++++++++++++ >>>>> drivers/video/am335x-fb.h | 67 ++++++++++++++++++ >>>>> 3 files changed, 237 insertions(+) >>>>> create mode 100644 drivers/video/am335x-fb.c >>>>> create mode 100644 drivers/video/am335x-fb.h >>>> >>>> Why you cannot use: >>>> >>>> u-boot:drivers/video/da8xx-fb.c ? >>>> >>>> bye, >>>> Heiko >>> Hi Heiko, >>> >>> for my opinion this clone of the linux-driver is very overloaded and >>> difficult to use/configure. >>> With the words 'small-is-beautiful' and 'keep-it-simple' i've wrote a >>> few lines which do the minimum: >>> - configure raster-controller >>> - setup DMA >>> - powerON Display >>> >>> maybe we can use the small-version in other projects too. >> >> Why is it difficult to use/configure the existing driver? >> >> Look for example into the board/siemens/pxm2/board.c board, which uses >> this driver. You have to define: >> >> static struct da8xx_panel lcd_panels[] >> static const struct display_panel disp_panel >> static const struct lcd_ctrl_config lcd_cfg >> >> and call "da8xx_video_init(&lcd_panels[0],&lcd_cfg, lcd_cfg.bpp);" >> >> Thats all ... > > i've looked around again for using the da8xx-fb driver and found another > detail which motivated me for writing a new instance. > > -- > par->vram_virt = malloc(par->vram_size); > > par->vram_phys = (dma_addr_t) par->vram_virt; > debug("Requesting 0x%x bytes for framebuffer at 0x%x\n", > (unsigned int)par->vram_size, > (unsigned int)par->vram_virt); > if (!par->vram_virt) { > printf("GLCD: malloc for frame buffer failed\n"); > goto err_release_fb; > } > gd->fb_base = (int)par->vram_virt; > -- > > da8xx-fb.c does allocate a new framebuffer by itself. > But in my case lcd-framework allready has reserved memory (on top of ram) > for framebuffer usage and i want use this memory from lcd-framework for > two reasons: > - don't waste memory > - have this memory really on top of ram to give the following OS (in my > case vxWorks) a pointer where it have to write Video-data. > > maybe there are other possibilites to achieve this. > any ideas ? Maybe you can introduce a common function like this? : void *get_vram(size_t size) { if (gd->fb_base) { if (gd->fb_size == size) return gd->fb_base; printf("fb size does not match\n"); } else { void *ret = malloc(size); if (ret) { gd->fb_base = ret; gd->fb_size = size; } return ret } return NULL; } (gd->fb_size is a new variable ...) and use in your driver only: par->vram_virt = get_vram(par->vram_size); or, just only check in the driver, if "gd->fb_base" has a value, and if so, do not malloc the vram ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany