From: Afzal Mohammed <hidden> Date: 2013-01-15 13:41:00
Hi,
This series adds DT support to da8xx-fb driver (device found on
DaVinci and AM335x SoC's). It does certain cleanup's in the process.
This series as compared to previous version handles configuration of
the LCDC input clock to required value if clock divider in IP cannot
take care of required pixel clock. In the case of AM335x (where there
is requirement of configuring input clock), it's clock tree has to be
updated with proper flags, relevant patch is,
"ARM: AM33XX: clock: SET_RATE_PARENT in lcd path".
There is an additional patch in this new series to make io operations
safe.
This makes use of Steffen Trumtrar's v16 of display timing DT support.
Testing has been done on AM335x SoC based boards like AM335x EVM and
AM335x EVM-SK. It has also been verified that display on DA850 EVM
(non-DT boot) works as earlier.
This series is based on v3.8-rc3,
and is dependent on,
1. Series v16 "of: add display helper" by,
Steffen Trumtrar [off-list ref]
2. Patch "da8xx: Allow use by am33xx based devices" by,
Pantelis Antoniou [off-list ref]
3. Series v3 "video: da8xx-fb: runtime timing configuration" by,
me (Afzal Mohammed [off-list ref])
To test this series on AM335x based boards,
1. Series v2 "ARM: dts: AM33XX: lcdc support" by,
me (Afzal Mohammed [off-list ref]),
2. Patch "ARM: AM33XX: clock: SET_RATE_PARENT in lcd path" by,
me (Afzal Mohammed [off-list ref]),
3. Series "HWMOD fixes for AM33xx PWM submodules and device tree nodes" by,
Philip, Avinash [off-list ref]
would be needed.
All above dependencies along with those required for testing is available
@git://gitorious.org/x0148406-public/linux-kernel.git tags/da8xx-fb-dt-v3.8-rc3
Regards
Afzal
v2: 2 new patches - one to configure clock rate properly (12/12)and
other to make io operations safe (1/12)
Afzal Mohammed (11):
video: da8xx-fb: make io operations safe
video: da8xx-fb: enable sync lost intr for v2 ip
video: da8xx-fb: use devres
video: da8xx-fb: ensure non-null cfg in pdata
video: da8xx-fb: reorganize panel detection
video: da8xx-fb: minimal dt support
video: da8xx-fb: invoke platform callback safely
video: da8xx-fb: obtain fb_videomode info from dt
video: da8xx-fb: ensure pdata only for non-dt
video: da8xx-fb: setup struct lcd_ctrl_config for dt
video: da8xx-fb: set upstream clock rate (if reqd)
Manjunathappa, Prakash (1):
video: da8xx-fb: fix 24bpp raster configuration
.../devicetree/bindings/video/fb-da8xx.txt | 37 ++++
drivers/video/da8xx-fb.c | 226 ++++++++++++++------
2 files changed, 194 insertions(+), 69 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt
--
1.7.9.5
From: Afzal Mohammed <hidden> Date: 2013-01-15 13:41:09
From: "Manjunathappa, Prakash" <redacted>
Set only LCD_V2_TFT_24BPP_MODE bit for 24bpp and LCD_V2_TFT_24BPP_UNPACK
bit along with LCD_V2_TFT_24BPP_MODE for 32bpp configuration.
Patch is tested on am335x-evm for 24bpp and da850-evm for 16bpp
configurations.
Signed-off-by: Manjunathappa, Prakash <redacted>
Signed-off-by: Afzal Mohammed <redacted>
---
drivers/video/da8xx-fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Afzal Mohammed <hidden> Date: 2013-01-15 13:41:19
interrupt handler is checking for sync lost interrupt, but it was not
enabled, enable it.
Signed-off-by: Afzal Mohammed <redacted>
---
drivers/video/da8xx-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Afzal Mohammed <hidden> Date: 2013-01-15 13:41:49
Driver is provided a means to have the probe triggered by DT.
Signed-off-by: Afzal Mohammed <redacted>
---
.../devicetree/bindings/video/fb-da8xx.txt | 16 ++++++++++++++++
drivers/video/da8xx-fb.c | 7 +++++++
2 files changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt
From: Afzal Mohammed <hidden> Date: 2013-01-15 13:41:56
Ensure that platform data is present before checking whether platform
callback is present (the one used to control backlight). So far this
was not an issue as driver was purely non-DT triggered, but now DT
support has been added.
Signed-off-by: Afzal Mohammed <redacted>
---
drivers/video/da8xx-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -6,6 +6,12 @@ Required properties: AM335x SoC's - "ti,am3352-lcdc", "ti,da830-lcdc" - reg: Address range of lcdc register set - interrupts: lcdc interrupt+- display-timings: typical videomode of lcd panel, represented as child.+ Refer Documentation/devicetree/bindings/video/display-timing.txt for+ display timing binding details. If multiple videomodes are mentioned+ in display timings node, typical videomode has to be mentioned as the+ native mode or it has to be first child (driver cares only for native+ videomode). Example:
From: Afzal Mohammed <hidden> Date: 2013-01-15 13:42:16
This driver is DT probe-able, hence ensure presence of platform data
only for non-DT boot.
Signed-off-by: Afzal Mohammed <redacted>
---
drivers/video/da8xx-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -1303,7 +1303,7 @@ static int fb_probe(struct platform_device *device)intret;unsignedlongulcm;-if(fb_pdata=NULL){+if(fb_pdata=NULL&&!device->dev.of_node){dev_err(&device->dev,"Can not get platform data\n");return-ENOENT;}
From: Afzal Mohammed <hidden> Date: 2013-01-15 13:42:23
strcut lcd_ctrl_config information required for driver is currently
obtained via platform data. To handle DT probing, create
lcd_ctrl_config and populate it with default values, these values are
sufficient for the panels so far used with this controller to work.
Signed-off-by: Afzal Mohammed <redacted>
---
drivers/video/da8xx-fb.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
From: Afzal Mohammed <hidden> Date: 2013-01-15 13:43:04
Move panel detection to a separate function, this helps in readability
as well as makes DT support cleaner.
Signed-off-by: Afzal Mohammed <redacted>
---
drivers/video/da8xx-fb.c | 42 ++++++++++++++++++++++++++----------------
1 file changed, 26 insertions(+), 16 deletions(-)
@@ -1036,12 +1036,9 @@ static int fb_remove(struct platform_device *dev)par->p_palette_base);dma_free_coherent(NULL,par->vram_size,par->vram_virt,par->vram_phys);-free_irq(par->irq,par);pm_runtime_put_sync(&dev->dev);pm_runtime_disable(&dev->dev);framebuffer_release(info);-iounmap(da8xx_fb_reg_base);-release_mem_region(lcdc_regs->start,resource_size(lcdc_regs));}return0;
@@ -1265,7 +1262,6 @@ static int fb_probe(struct platform_device *device)structfb_info*da8xx_fb_info;structclk*fb_clk=NULL;structda8xx_fb_par*par;-resource_size_tlen;intret,i;unsignedlongulcm;
@@ -1275,29 +1271,16 @@ static int fb_probe(struct platform_device *device)}lcdc_regs=platform_get_resource(device,IORESOURCE_MEM,0);-if(!lcdc_regs){-dev_err(&device->dev,-"Can not get memory resource for LCD controller\n");-return-ENOENT;-}--len=resource_size(lcdc_regs);--lcdc_regs=request_mem_region(lcdc_regs->start,len,lcdc_regs->name);-if(!lcdc_regs)-return-EBUSY;--da8xx_fb_reg_base=ioremap(lcdc_regs->start,len);+da8xx_fb_reg_base=devm_request_and_ioremap(&device->dev,lcdc_regs);if(!da8xx_fb_reg_base){-ret=-EBUSY;-gotoerr_request_mem;+dev_err(&device->dev,"memory resource setup failed\n");+return-EADDRNOTAVAIL;}-fb_clk=clk_get(&device->dev,"fck");+fb_clk=devm_clk_get(&device->dev,"fck");if(IS_ERR(fb_clk)){dev_err(&device->dev,"Can not get device clock\n");-ret=-ENODEV;-gotoerr_ioremap;+return-ENODEV;}pm_runtime_enable(&device->dev);
@@ -1458,7 +1441,7 @@ static int fb_probe(struct platform_device *device)lcdc_irq_handler=lcdc_irq_handler_rev02;}-ret=request_irq(par->irq,lcdc_irq_handler,0,+ret=devm_request_irq(&device->dev,par->irq,lcdc_irq_handler,0,DRIVER_NAME,par);if(ret)gotoirq_freq;
From: Afzal Mohammed <hidden> Date: 2013-01-15 13:43:55
LCDC IP has a clock divider to adjust pixel clock, this limits pixel
clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP).
In the case of AM335x, where this IP is present, default fck is not
sufficient to provide normal pixel clock rates, hence rendering this
driver unusable on AM335x.
If input clock too is configurable, allowable range of pixel clock
would increase. Here initially it is checked whether with present fck,
divider in IP could be configured to obtain required rate, if not,
fck is adjusted. This makes it usable on AM335x.
Note:
A better (if allowable) solution may be to represent clock divider in
LCDC IP as a basic divider clock - the one defined in common clock
framework. But for this to happen, all the platform's using this driver
should be using common clock framework (DaVinci is yet to be converted
to use common clock framework). And it has to be determined whether
common clock framework allows this kind of a clock modelling inside a
driver and for this to be part of clock tree. Advantage of doing so
would be better resolution for pixel clock, even though without this
existing use cases are working properly. Or another extreme alternative
would be to replicate clk-divider of common clock framework inside the
driver, but that probably is not preferred and not worth as it would be
duplication and without much advantage to existing users.
Signed-off-by: Afzal Mohammed <redacted>
---
v2: new patch
drivers/video/da8xx-fb.c | 76 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 58 insertions(+), 18 deletions(-)
@@ -683,23 +686,21 @@ static void da8xx_fb_lcd_reset(void)}}-staticinlineunsignedda8xx_fb_calc_clk_divider(structda8xx_fb_par*par,-unsignedpixclock)-{-returnpar->lcd_fck_rate/(PICOS2KHZ(pixclock)*1000);-}--staticinlineunsignedda8xx_fb_round_clk(structda8xx_fb_par*par,-unsignedpixclock)+staticintda8xx_fb_config_clk_divider(structda8xx_fb_par*par,+unsigneddiv,unsignedrate){-unsigneddiv;+intret;-div=da8xx_fb_calc_clk_divider(par,pixclock);-returnKHZ2PICOS(par->lcd_fck_rate/(1000*div));-}+if(par->lcd_fck_rate!=rate){+ret=clk_set_rate(par->lcdc_clk,rate);+if(IS_ERR_VALUE(ret)){+dev_err(par->dev,+"unable to set clock rate at %u\n",rate);+returnret;+}+par->lcd_fck_rate=clk_get_rate(par->lcdc_clk);+}-staticinlinevoidda8xx_fb_config_clk_divider(unsigneddiv)-{/* Configure the LCD clock divisor. */lcdc_write(LCD_CLK_DIVISOR(div)|(LCD_RASTER_MODE&0x1),LCD_CTRL_REG);
From: Mike Turquette <hidden> Date: 2013-01-15 15:32:33
Quoting Afzal Mohammed (2013-01-15 05:44:36)
LCDC IP has a clock divider to adjust pixel clock, this limits pixel
clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP).
In the case of AM335x, where this IP is present, default fck is not
sufficient to provide normal pixel clock rates, hence rendering this
driver unusable on AM335x.
If input clock too is configurable, allowable range of pixel clock
would increase. Here initially it is checked whether with present fck,
divider in IP could be configured to obtain required rate, if not,
fck is adjusted. This makes it usable on AM335x.
Note:
A better (if allowable) solution may be to represent clock divider in
LCDC IP as a basic divider clock - the one defined in common clock
framework. But for this to happen, all the platform's using this driver
should be using common clock framework (DaVinci is yet to be converted
to use common clock framework). And it has to be determined whether
common clock framework allows this kind of a clock modelling inside a
driver and for this to be part of clock tree. Advantage of doing so
would be better resolution for pixel clock, even though without this
existing use cases are working properly. Or another extreme alternative
would be to replicate clk-divider of common clock framework inside the
driver, but that probably is not preferred and not worth as it would be
duplication and without much advantage to existing users.
Afzal,
Modeling the divider inside your IP block as a clock is supported in the
common clock framework. Linking up these sorts of clocks to the clock
tree was one of the original design goals of CCF.
Regarding DaVinci: converting that platform over to use CCF would be the
best approach. An alternative would be that you could break
single-image boot for AM335x and DaVinci, by having AM335x use CCF and
DaVinci use the legacy clock framework. From the LCDC driver's
perspective this should not matter and is indeed the purpose of the
clk.h api and clkdev interfaces, however looking at this driver I can
see there would still be a lot ifdef-ery going on... better to just
convert everything over to CCF.
Regards,
Mike
quoted hunk
Signed-off-by: Afzal Mohammed <redacted>
---
v2: new patch
drivers/video/da8xx-fb.c | 76 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 58 insertions(+), 18 deletions(-)
@@ -683,23 +686,21 @@ static void da8xx_fb_lcd_reset(void)}}-staticinlineunsignedda8xx_fb_calc_clk_divider(structda8xx_fb_par*par,-unsignedpixclock)-{-returnpar->lcd_fck_rate/(PICOS2KHZ(pixclock)*1000);-}--staticinlineunsignedda8xx_fb_round_clk(structda8xx_fb_par*par,-unsignedpixclock)+staticintda8xx_fb_config_clk_divider(structda8xx_fb_par*par,+unsigneddiv,unsignedrate){-unsigneddiv;+intret;-div=da8xx_fb_calc_clk_divider(par,pixclock);-returnKHZ2PICOS(par->lcd_fck_rate/(1000*div));-}+if(par->lcd_fck_rate!=rate){+ret=clk_set_rate(par->lcdc_clk,rate);+if(IS_ERR_VALUE(ret)){+dev_err(par->dev,+"unable to set clock rate at %u\n",rate);+returnret;+}+par->lcd_fck_rate=clk_get_rate(par->lcdc_clk);+}-staticinlinevoidda8xx_fb_config_clk_divider(unsigneddiv)-{/* Configure the LCD clock divisor. */lcdc_write(LCD_CLK_DIVISOR(div)|(LCD_RASTER_MODE&0x1),LCD_CTRL_REG);
From: Sekhar Nori <hidden> Date: 2013-01-16 05:02:35
On 1/15/2013 9:02 PM, Mike Turquette wrote:
Quoting Afzal Mohammed (2013-01-15 05:44:36)
quoted
LCDC IP has a clock divider to adjust pixel clock, this limits pixel
clock range to fck/255 - fck/2(fck - rate of input clock to LCDC IP).
In the case of AM335x, where this IP is present, default fck is not
sufficient to provide normal pixel clock rates, hence rendering this
driver unusable on AM335x.
If input clock too is configurable, allowable range of pixel clock
would increase. Here initially it is checked whether with present fck,
divider in IP could be configured to obtain required rate, if not,
fck is adjusted. This makes it usable on AM335x.
Note:
A better (if allowable) solution may be to represent clock divider in
LCDC IP as a basic divider clock - the one defined in common clock
framework. But for this to happen, all the platform's using this driver
should be using common clock framework (DaVinci is yet to be converted
to use common clock framework). And it has to be determined whether
common clock framework allows this kind of a clock modelling inside a
driver and for this to be part of clock tree. Advantage of doing so
would be better resolution for pixel clock, even though without this
existing use cases are working properly. Or another extreme alternative
would be to replicate clk-divider of common clock framework inside the
driver, but that probably is not preferred and not worth as it would be
duplication and without much advantage to existing users.
Afzal,
Modeling the divider inside your IP block as a clock is supported in the
common clock framework. Linking up these sorts of clocks to the clock
tree was one of the original design goals of CCF.
Regarding DaVinci: converting that platform over to use CCF would be the
best approach.
This is work in progress. There are patches that have been posted. Work
has been slow on this though due to lack of bandwidth.
An alternative would be that you could break
single-image boot for AM335x and DaVinci, by having AM335x use CCF and
DaVinci use the legacy clock framework. From the LCDC driver's
Single image for DaVinci and AM335x is not possible anyway since ARMv5
and ARMv6+ cannot be supported in a single image.
perspective this should not matter and is indeed the purpose of the
clk.h api and clkdev interfaces, however looking at this driver I can
see there would still be a lot ifdef-ery going on... better to just
convert everything over to CCF.
Waiting for DaVinci CCF to complete will be too long a wait. Probably
convert to CCF just for AM335x ATM. There would be some ifdef'ry but
hopefully that need not be inside function bodies. Would have to see the
implementation, I guess.
Thanks,
Sekhar