This reverts the Linux for Workgroups thing. And no, before somebody
asks, we're not doing Linux95. Not for a few years, at least.
Sure, the flag added some color to the logo, and could have remained as
a testament to my leet gimp skills. But no. And I'll do this early, to
avoid the chance of forgetting when I'm doing the actual rc1 release on
the road.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
acornfb checks for HAS_VIDC while support for that macro was removed in
v2.6.23 (when the arm26 port was removed). So we can remove a bit of
dead code.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
While cross-building for PPC64 I've got
WARNING: drivers/video/built-in.o(.text+0x9f9ca): Section mismatch in
reference from the function .ps3fb_probe() to th e variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: drivers/video/built-in.o(.text+0x9f9d2): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: drivers/built-in.o(.text+0xe222a): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: drivers/built-in.o(.text+0xe2232): Section mismatch in
reference from the function .ps3fb_probe() to the variable
.init.data:ps3fb_fix The function .ps3fb_probe() references the
variable __initdata ps3fb_fix. This is often because .ps3fb_probe
lacks a __initdata annotation or the annotation of ps3fb_fix is wrong.
WARNING: vmlinux.o(.text+0x561d4a): Section mismatch in reference from
the function .ps3fb_probe() to the variable .init.data:ps3fb_fix The
function .ps3fb_probe() references the variable __initdata ps3fb_fix.
This is often because .ps3fb_probe lacks a __initdata annotation or
the annotation of ps3fb_fix is wrong.
Mismatch was introduced with 48c68c4f "Drivers: video: remove __dev*
attributes."
Remove __init data annotation from ps3fb_fix.
Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The polarities were being set to active low when fbdev was requesting active
high. This patch reverses it so that what is set into the LCD controller is
correct.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
TI LCD controller version 2 adds some extra bits in a register to
increase the available size to represent horizontal timings. This
patch allows the fbdev driver to utilize those extra bits.
This will become important for driving an HDMI encoder from the lcd
controller where some of the VESA/CEA modes require quite large porches.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The LCD controller represents some of the timing fields with a 0
in the register representing 1. This was not taken into account
when these registers were being set. Interestingly enough not
all of the LCDC controller timing registers implement this representation
so carefully went through the technical reference manual to only "fix"
the correct timings.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The driver was mapping the wrong fbdev margins to the
front porch / back porch for both vertical and horizontal
timings.
This patch corrects it so that:
hfp = right margin
hbp = left margin
vbp = upper margin
vfp = lower margin
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Use devm_ioremap_resource instead of devm_request_and_ioremap.
This was done using the semantic patch
scripts/coccinelle/api/devm_ioremap_resource.cocci
The initialization of drvdata->regs_phys was manually moved lower, to take
advantage of the NULL test on res performed by devm_ioremap_resource.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Just a cosmetic thing to bring that file in line with others in the
tree.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
fb_set_cmap() already checks the parameters, so need remove the
redundancy checking.
This redundancy checking is also incorrect, the related warning:
drivers/video/fbcmap.c:288:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
Move the call to platform_get_resource adjacent to the call to
devm_ioremap_resource to make the connection between them more clear.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression pdev,res,n,e,e1;
expression ret != 0;
identifier l;
@@
- res = platform_get_resource(pdev, IORESOURCE_MEM, n);
... when != res
- if (res == NULL) { ... \(goto l;\|return ret;\) }
... when != res
+ res = platform_get_resource(pdev, IORESOURCE_MEM, n);
e = devm_ioremap_resource(e1, res);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Ensure that the definitions of functions match the prototypes used by
other modules by including the header with the prototypes in the files
with the definitions.
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In the old panel device model we had omap_dss_output entities,
representing the encoders in the DSS block. This entity had "device"
field, which pointed to the panel that was using the omap_dss_output.
With the new panel device model, the omap_dss_output is integrated into
omap_dss_device, which now represents a "display entity". Thus the "device"
field, now in omap_dss_device, points to the next entity in the display
entity-chain.
This patch renames the "device" field to "dst", which much better tells
what the field points to.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
In the old panel device model we had "outputs", which were the encoders
inside OMAP DSS block, and panel devices (omap_dss_device). The panel
devices had a reference to the source of the video data, i.e. reference
to an "output", in a field named "output".
That was somewhat confusing even in the old panel device model, but even
more so with the panel device model where we can have longer chains of
display entities.
This patch renames the "output" field to "src", which much better tells
what the field points to.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
With all the old panels removed and all the old panel model APIs removed
from the DSS encoders, we can now remove the custom omapdss-bus which
was used in the old panel model.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
HDMI_IDENTIFIER was felt too generic, rename it to what it is, the IEEE
OUI corresponding to HDMI Licensing, LLC.
http://standards.ieee.org/develop/regauth/oui/oui.txt
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
We just got rid of the version of hdmi_vendor_infoframe that had a byte
array for anyone to poke at. It's now time to shuffle around the naming
of hdmi_hdmi_infoframe to make hdmi_vendor_infoframe become the HDMI
vendor specific structure.
Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
With this last bit, hdmi_infoframe_pack() is now able to pack any
infoframe we support.
At the same time, because it's impractical to make two commits out of
this, we get rid of the version that encourages the open coding of the
vendor infoframe packing. We can do so because the only user of this API
has been ported in:
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Mon Aug 12 18:08:37 2013 +0100
gpu: host1x: Port the HDMI vendor infoframe code the common helpers
v2: Change oui to be an unsigned int (Ville Syrjälä)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Provide the same programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor infoframe we are dealing with.
v2: Fix the value of Side-by-side (half), hmdi typo, pack 3D_Ext_Data
(Ville Syrjälä)
v3: Future proof the sending of 3D_Ext_Data (Ville Syrjälä), Fix
multi-lines comment style (Thierry Reding)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Just like:
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Mon Aug 12 11:53:24 2013 +0100
video/hdmi: Don't let the user of this API create invalid infoframes
But this time for the horizontal/vertical bar data present bits.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Tue Aug 6 20:32:17 2013 +0100
drm: Don't generate invalid AVI infoframes for CEA modes
We can do better and derive the _valid bit from the user wanting to set
the active aspect ratio.
v2: Fix multi-lines comment style (Thierry Reding)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The code handling 'alpha_blending_enabled' sysfs file contains WARN_ONs
in case the feature is not supported on the current platform. Even
though only root can write to the file, anyone can read it, thus causing
the kernel to get tainted and printing an ugly warning.
Instead of having WARN_ONs, return a proper error if the feature is not
supported.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Commit 5391e87d12 (OMAPDSS: remove dispc's dependency to VENC/HDMI)
introduced a possible NULL reference bug in the HDMI driver when setting
timings. In practice the bug shouldn't happen, as the timings have been
verified earlier, and thus the timings should always be ok.
Fix the possible issue by moving the use of the timings pointer inside
the NULL check.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Now that the old panel drivers have been removed, we can remove the
old-model API and related code from the DSS encoder drivers.
This patch removes the code from the RFBI driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Now that the old panel drivers have been removed, we can remove the
old-model API and related code from the DSS encoder drivers.
This patch removes the code from the VENC driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Now that the old panel drivers have been removed, we can remove the
old-model API and related code from the DSS encoder drivers.
This patch removes the code from the SDI driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Now that the old panel drivers have been removed, we can remove the
old-model API and related code from the DSS encoder drivers.
This patch removes the code from the DSI driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Now that the old panel drivers have been removed, we can remove the
old-model API and related code from the DSS encoder drivers.
This patch removes the code from the HDMI driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Now that the old panel drivers have been removed, we can remove the
old-model API and related code from the DSS encoder drivers.
This patch removes the code from the DPI driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
The board files now use the new panel drivers, making the old panel
drivers obsolete.
Remove the old panel drivers, Kconfig and Makefile entries, and the
panels' platform data structs.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Regulator handling for DPI and SDI is currently handled in the core.c,
using the 'virtual' omapdss platform device. Nowadays we have proper
devices for both DPI and SDI, and so we can handle the regulators inside
the respective drivers.
This patch moves the regulator handling for DPI into dpi.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Regulator handling for DPI and SDI is currently handled in the core.c,
using the 'virtual' omapdss platform device. Nowadays we have proper
devices for both DPI and SDI, and so we can handle the regulators inside
the respective drivers.
This patch moves the regulator handling for SDI into sdi.c.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
OMAPDSS's RFBI encoder driver has not been working for some time. The
Nokia N800 is the only board in the mainline that uses RFBI, but it has
never been fully functional.
The RFBI driver needs to be updated to the new panel model, but as
the driver is rather unmaintained and there's no way to test the
changes, let's mark the driver as broken.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Updating Kconfig to allow am33xx to include lcdc fbdev driver
including some extra dependencies needed by device tree mods.
v2: must add FB_MODE_HELPERS as VIDEOMODE_HELPERS alone doesn't
get the correct functions from fbmon.c built in.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Remove use of explicit inline compiler directive and let the compiler
make the decision as per Documentation/CodingStyle.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Clean up the code, so that the names of the various clock variables
are consistent to it is clear what variable is associated with what
clock.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Based on original patch by: Afzal Mohammed <afzal@ti.com>
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:
Another solution would be to model an inherited basic clock divider of
CCF, an advantage would be a better possible resolution for pixel clk.
And trying to instantiate a CCF clock would mean that to be consistent,
3 bits being turned on to enable clocks of LCDC IP would have to be
modeled as gate clocks. Now that would bring in a total of 4 clocks,
including necessity to create a new inherited divider clock, and that
mean a branch of clock tree would be present in LCDC driver. This
would add complexity to LCDC driver bringing in considerable amount
of clock handling code, and this would not bring in much advantage
for existing use cases other than providing a higher resolution of
pixel clock. And existing use cases work without relying on clock
modeling. Another fact is that out of the two platform's using this
driver DaVinci is not yet converted to CCF. In future if higher
resolution of pixel clock is required, and probably after DaVinci is
CCF'ed, modeling clock nodes inside driver may be considered.
v2: purely cosmetic changes to try and clarify what variables are
being used for in the clock rate / divider calculations
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Move panel detection to a separate function, this helps in readability
as well as makes DT support cleaner.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Ensure that platform data contains pointer for lcd_ctrl_config.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Replace existing resource handling in the driver with managed device
resource.
v2: implement some changes as recommended by
Prabhakar Lad <prabhakar.csengg@gmail.com>
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The interrupt handler explicitly has code that handles the sync lost
interrupt. However the sync lost interrupt is never actually being
enabled in the LCD controller, therefore this interrupt code path is not
being exercised. This fix simply enables the generation of the sync
lost interrupt by the LCD controller so it can be dealt with
appropriately by the interrupt handler.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Based on original patch by: Manjunathappa, Prakash <prakash.pm@ti.com>
and Afzal Mohammed <afzal@ti.com>
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.
v2: removes confusing fall through in case statement for pixel
depth configuration.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Change the lcd_disable_raster funtion from using a bool to an enum
as the function is very confusing with the current api. This helps
make it clearer what the parameter is really doing.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
v1: original from Afzal Mohammed <afzal@ti.com>
fb_set_par helps in runtime configuration of lcd controller like
changing resolution, pixel clock etc. (eg. using fbset utility)
Reconfigure lcd controller based on information passed by framework.
Enable raster back if it was already enabled.
As fb_set_par would get invoked indirectly from probe via fb_set_var,
remove existing lcdc initialization in probe and do lcdc reset in
probe so that reset happens only at the begining.
v2: changes from Darren Etheridge <detheridge@ti.com>
remove unnecessary conditional branch where we attempt to disable
something that we already checked to see if it was disabled.
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Update "var" pixclock with the value that is configurable in hardware.
This lets user know the actual pixclock.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
store struct device pointer so that dev_dbg/err can be used outside
of probe.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Based on original patch by: Afzal Mohammed <afzal@ti.com>
Use the new modedb field to store pix clk. Reorganize existing clock
divider functions with names now corresponding to what they do, add
common function prefix.
Fix existing panel modedb pixclock to be in ps instead of Hz. This
needed a change in the way clock divider is calculated. As modedb
pixclock information is now in ps, override on "var" pixclock over
modedb to var conversion is removed.
v2:
Changed pixel clock configuration to use KHZ2PICOS macro
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
store lcd clk rate always, i.e. irrespective of whether CPUFREQ is
enabled or not. This can be used to get clk rate directly instead of
enquiring with clock framework with clk handle every time.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>