10 Jul, 2013
1 commit
-
Pull drm updates from Dave Airlie:
"Okay this is the big one, I was stalled on the fbdev pull req as I
stupidly let fbdev guys merge a patch I required to fix a warning with
some patches I had, they ended up merging the patch from the wrong
place, but the warning should be fixed. In future I'll just take the
patch myself!Outside drm:
There are some snd changes for the HDMI audio interactions on haswell,
they've been acked for inclusion via my tree. This relies on the
wound/wait tree from Ingo which is already merged.Major changes:
AMD finally released the dynamic power management code for all their
GPUs from r600->present day, this is great, off by default for now but
also a huge amount of code, in fact it is most of this pull request.Since it landed there has been a lot of community testing and Alex has
sent a lot of fixes for any bugs found so far. I suspect radeon might
now be the biggest kernel driver ever :-P p.s. radeon.dpm=1 to enable
dynamic powermanagement for anyone.New drivers:
Renesas r-car display unit.
Other highlights:
- core: GEM CMA prime support, use new w/w mutexs for TTM
reservations, cursor hotspot, doc updates
- dvo chips: chrontel 7010B support
- i915: Haswell (fbc, ips, vecs, watermarks, audio powerwell),
Valleyview (enabled by default, rc6), lots of pll reworking, 30bpp
support (this time for sure)
- nouveau: async buffer object deletion, context/register init
updates, kernel vp2 engine support, GF117 support, GK110 accel
support (with external nvidia ucode), context cleanups.
- exynos: memory leak fixes, Add S3C64XX SoC series support, device
tree updates, common clock framework support,
- qxl: cursor hotspot support, multi-monitor support, suspend/resume
support
- mgag200: hw cursor support, g200 mode limiting
- shmobile: prime support
- tegra: fixes mostlyI've been banging on this quite a lot due to the size of it, and it
seems to okay on everything I've tested it on."* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (811 commits)
drm/radeon/dpm: implement vblank_too_short callback for si
drm/radeon/dpm: implement vblank_too_short callback for cayman
drm/radeon/dpm: implement vblank_too_short callback for btc
drm/radeon/dpm: implement vblank_too_short callback for evergreen
drm/radeon/dpm: implement vblank_too_short callback for 7xx
drm/radeon/dpm: add checks against vblank time
drm/radeon/dpm: add helper to calculate vblank time
drm/radeon: remove stray line in old pm code
drm/radeon/dpm: fix display_gap programming on rv7xx
drm/nvc0/gr: fix gpc firmware regression
drm/nouveau: fix minor thinko causing bo moves to not be async on kepler
drm/radeon/dpm: implement force performance level for TN
drm/radeon/dpm: implement force performance level for ON/LN
drm/radeon/dpm: implement force performance level for SI
drm/radeon/dpm: implement force performance level for cayman
drm/radeon/dpm: implement force performance levels for 7xx/eg/btc
drm/radeon/dpm: add infrastructure to force performance levels
drm/radeon: fix surface setup on r1xx
drm/radeon: add support for 3d perf states on older asics
drm/radeon: set default clocks for SI when DPM is disabled
...
28 Jun, 2013
3 commits
-
Various fbdev changes for 3.11
* xilinxfb updates
* Small cleanups and fixes to multiple drivers -
OMAP display subsystem changes for 3.11 (part 2/2)
This is the second part of OMAP DSS changes for 3.11. This part contains the
new DSS device model support.The current OMAP panel drivers use a custom DSS bus, and there's a hard limit
of one external display block per video pipeline. In the new DSS device model
the devices/drivers are made according to the control bus of the display block,
usually platform, i2c or spi. The display blocks can also be chained so that we
can have separate drivers for setups with both external encoder and panel.To allow the current board files, which use the old style panels, to function,
the old display drivers are left in their current state, and new ones are added
to drivers/video/omap2/displays-new/. When the board files have been converted
to use the new style panels, we can remove the old code. This is planned to
happen in v3.12.Having to support two very different DSS device models makes the driver
somewhat confusing in some parts, and prevents us from properly cleaning up
some other parts. These cleanups will be done when the old code is removed.The new device model is designed with CDF (Common Display Framework) in mind.
While CDF is still under work, the new DSS device model should be much more
similar to CDF's model than the old device model, which should make the
eventual conversion to CDF much easier. -
OMAP display subsystem changes for 3.11 (part 1/2)
This is the first part of OMAP DSS changes for 3.11. This part contains fixes,
cleanups and reorganizations that are not directly related to the new DSS
device model that is added in part 2, although many of the reorganizations are
made to make the part 2 possible.There should not be any functional changes visible to the user except the few
bug fixes.The main new internal features:
- Display (dis)connect support, which allows us to explicitly (dis)connect a
whole display pipeline- Panel list, which allows us to operate without the specific DSS bus
- Combine omap_dss_output to omap_dss_device, so that we have one generic
"entity" for display pipeline blocks
27 Jun, 2013
2 commits
-
Linux 3.10-rc7
The sdvo lvds fix in this -fixes pull
commit c3456fb3e4712d0448592af3c5d644c9472cd3c1
Author: Daniel Vetter
Date: Mon Jun 10 09:47:58 2013 +0200drm/i915: prefer VBT modes for SVDO-LVDS over EDID
has a silent functional conflict with
commit 990256aec2f10800595dddf4d1c3441fcd6b2616
Author: Ville Syrjälä
Date: Fri May 31 12:17:07 2013 +0000drm: Add probed modes in probe order
in drm-next. W simply need to add the vbt modes before edid modes, i.e. the
other way round than now.Conflicts:
drivers/gpu/drm/drm_prime.c
drivers/gpu/drm/i915/intel_sdvo.c -
Commit ffa3fd21de ("videomode: implement public of_get_display_timing()") causes
the following build warning:include/video/of_display_timing.h:18:10: warning: 'struct display_timing' declared inside parameter list [enabled by default]
include/video/of_display_timing.h:18:10: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]Declare 'display_timing' to avoid the build warning.
Signed-off-by: Fabio Estevam
Signed-off-by: Tomi Valkeinen
17 Jun, 2013
33 commits
-
Add NEC NL8048HL11 panel driver which uses the new DSS device model
and DSS ops.Signed-off-by: Tomi Valkeinen
-
Add TPO TD043MTEA1 panel driver which uses the new DSS device model
and DSS ops.Signed-off-by: Tomi Valkeinen
Tested-by: Grazvydas Ignotas -
Add Sharp LS037V7DW01 panel driver which uses the new DSS device model
and DSS ops.Signed-off-by: Tomi Valkeinen
-
Add LG.Philips LB035Q02 panel driver which uses the new DSS device model
and DSS ops.Signed-off-by: Tomi Valkeinen
-
Add Sony ACX565AKM panel driver which uses the new DSS device model and
DSS ops.Signed-off-by: Tomi Valkeinen
Tested-by: Aaro Koskinen -
Add DSI Command Mode panel driver which uses the new DSS device model
and DSS ops. This driver only supports a very basic set of features
which should be common to all DSI command mode panels.Signed-off-by: Tomi Valkeinen
-
Add simple DPI Panel driver which uses the new DSS device model and DSS
ops. A "simple" panel means one that does not require any special setup.Signed-off-by: Tomi Valkeinen
-
Add Analog TV Connector driver which uses the new DSS device model and
DSS ops.Signed-off-by: Tomi Valkeinen
-
Add HDMI Connector driver which uses the new DSS device model and DSS
ops.Signed-off-by: Tomi Valkeinen
-
Add DVI Connector driver which uses the new DSS device model and DSS
ops.Signed-off-by: Tomi Valkeinen
-
Add TPD12S015 HDMI ESD protection and level shifter encoder driver which
uses the new DSS device model and DSS ops.Signed-off-by: Tomi Valkeinen
-
Add TFP410 DPI-to-DVI Encoder driver which uses the new DSS device
model and DSS ops.Signed-off-by: Tomi Valkeinen
-
Add "ops" style method for using DSI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.Signed-off-by: Tomi Valkeinen
-
Add "ops" style method for using HDMI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.Signed-off-by: Tomi Valkeinen
-
Add "ops" style method for using analog TV functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.Signed-off-by: Tomi Valkeinen
-
Add "ops" style method for using DVI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.Signed-off-by: Tomi Valkeinen
-
Add "ops" style method for using SDI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.Signed-off-by: Tomi Valkeinen
-
Add "ops" style method for using DPI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.Signed-off-by: Tomi Valkeinen
-
Add new display bus type for DVI. This is not used by omapdss driver
itself, but is used by external encoder chips that output DVI.Signed-off-by: Tomi Valkeinen
-
In order to allow multiple display block in a video pipeline, we need to
give the drivers way to register themselves. For now we have
the omapdss_register_display() which is used to register panels, and
dss_register_output() which is used to register DSS encoders.This patch makes dss_register_output() public (with the name of
omapdss_register_output), which can be used to register also external
encoders. The distinction between register_output and register_display
is that a "display" is an entity at the end of the videopipeline, and
"output" is something inside the pipeline.The registration and naming will be made saner in the future, but the
current names and functions are kept to minimize changes during the dss
device model transition.Signed-off-by: Tomi Valkeinen
-
The use of platform callbacks, backlight, DSI TE and reset gpio from the
struct omap_dss_device has been removed. We can thus remove the fields
from omap_dss_device.Signed-off-by: Tomi Valkeinen
-
omap_dss_get_device() should be called for omap_dss_device before it is
used to increase its refcount. Currently we only increase the refcount
for the underlying device.This patch adds managing the ref count to the underlying module also,
which contains the ops for the omap_dss_device.Signed-off-by: Tomi Valkeinen
-
Add struct module *owner field to omap_dss_device, which points to the
module containing the ops for this omap_dss_device. This will be used to
manage the ref count for the module.Signed-off-by: Tomi Valkeinen
-
We currently have omap_dss_device, which represents an external display
device, sometimes an external encoder, sometimes a panel. Then we have
omap_dss_output, which represents DSS's output encoder.In the future with new display device model, we construct a video
pipeline from the display blocks. To accomplish this, all the blocks
need to be presented by the same entity.Thus, this patch combines omap_dss_output into omap_dss_device. Some of
the fields in omap_dss_output are already found in omap_dss_device, but
some are not. This means we'll have DSS output specific fields in
omap_dss_device, which is not very nice. However, it is easier to just
keep those output specific fields there for now, and after transition to
new display device model is made, they can be cleaned up easier than
could be done now.Signed-off-by: Tomi Valkeinen
-
The omap_dss_start_device() and omap_dss_stop_device(), called by the
DSS output drivers, are old relics. They originally did something
totally else, but nowadays they increase the module ref count for panels
that are enabled.This model is quite broken: the panel modules may be used even before
they are enabled. For example, configuring the panel requires calls to
functions located in the panel modules.In the following patches we try to improve the ref count management for
the modules and display devices. The first step, however, is to remove
the omap_dss_start/stop_device() totally.Signed-off-by: Tomi Valkeinen
-
We are about to remove the dss bus support, which also means that the
omap_dss_device won't be a real device anymore. This means that the
embedded "dev" struct needs to be removed from omap_dss_device.After we've finished the removal of the dss bus, we see the following
changes:- struct omap_dss_device won't be a real Linux device anymore, but more
like a "display entity".
- struct omap_dss_driver won't be a Linux device driver, but "display
entity ops".
- The panel devices/drivers won't be omapdss devices/drivers, but
platform/i2c/spi/etc devices/drivers, whichever fits the control
mechanism of the panel.
- The panel drivers will create omap_dss_device and omap_dss_driver,
fill the required fields, and register the omap_dss_device to
omapdss.
- omap_dss_device won't have an embedded dev struct anymore, but a
dev pointer to the actual device that manages the omap_dss_device.The model described above resembles the model that has been discussed
with CDF (common display framework).For the duration of the conversion, we temporarily have two devs in the
dssdev, the old "old_dev", which is a full embedded device struct, and the
new "dev", which is a pointer to the device. "old_dev" will be removed
in the future.For devices belonging to dss bus the dev is initialized to point to
old_dev. This way all the code can just use the dev, for both old and
new style panels.Both the new and old style panel drivers work during the conversion, and
only after the dss bus support is removed will the old style panels stop
to compile.Signed-off-by: Tomi Valkeinen
-
We currently use the omapdss bus (which contains all the available
displays) to iterate the displays. As the omapdss bus is on its way out,
this needs to be changed.Instead of using the dss bus to iterate displays, this patch adds our
own list of displays which we manage. The panels on the dss bus are
automatically added to this new list.An "alias" field is also added to omap_dss_device. This field is
set to "display%d", the same way as omap_dss_device's dev name is set.
This alias is later used to keep backward compatibility, when the
embedded dev is no longer used.Signed-off-by: Tomi Valkeinen
-
Add helper functions to convert between omapdss specific video timings
and the common videomode.Eventually omapdss will be changed to use only the common video timings,
and these helper functions will make the transition easier.Signed-off-by: Tomi Valkeinen
-
We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.To support that kind of scenarios, we need to add new step to the
initialization: connect.This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.Signed-off-by: Tomi Valkeinen
-
Add two helper functions that can be used to find either the DSS output
or the overlay manager that is connected to the given display.This hides how the output and the manager are actually connected, making
it easier to change the connections in the future.Signed-off-by: Tomi Valkeinen
-
Add a support function to find a DSS output by given DT node. This is
used in later patches to link the panels to DSS outputs.Signed-off-by: Tomi Valkeinen
-
Add a support function to find a DSS output by given name. This is used
in later patches to link the panels to DSS outputs.Signed-off-by: Tomi Valkeinen
-
We can currently set the default display (i.e. the initial display) in
the omapdss platform data by using a pointer to the default
omap_dss_device. Internally omapdss uses the device's name to resolve
the default display.As it's difficult to get the omap_dss_device pointer in the future,
after we've changed the omapdss device model, this patch adds a new way
to define the default display, by using the name of the display.Signed-off-by: Tomi Valkeinen
Reviewed-by: Archit Taneja
14 Jun, 2013
1 commit