IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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 <tomi.valkeinen@ti.com>
The n8x0 panel driver now manages the gpios required to configure the panel.
This was previously done in panel_n8x0_data's platform_enable/disable callbacks
defined in board files using this panel.
All the board files using this panel now pass the gpio information as platform
data via the panel_n8x0_data struct, which is needed by the panel driver to
configure the gpios connected to the panel. Hence, the uses of
platform_enable/disable ops can be safely removed now.
Signed-off-by: Archit Taneja <archit@ti.com>
The n8x0 panel driver leaves gpio configurations to the platform_enable and
disable calls in the platform's board file. These should happen in the panel
driver itself.
A platform data struct called panel_n8x0_data already exists to hold gpio
numbers and other platform data. However, the gpio requests are expected to be
done in the board file and not the panel driver.
Request all the gpios in the panel driver so that the board files which use
the the panel don't need to do it. This will help in removing the need for the
panel drivers to have platform related callbacks.
Signed-off-by: Archit Taneja <archit@ti.com>
The n8x0 panel contains support to call platform backlight functions.
These are not used by any board, and can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Structs for platform data of omapdss panels are found in headers in the
'include/video/' path. Board files populate these structs with platform
specific values, and the panel driver uses these to configure the panel.
Currently, each panel has it's own header in the above path. Move all the
omapdss panel platform data structs to a single header omap-panel-data.h.
This is useful because:
- All other omapdss panel drivers will be modified to use platform data. This
would lead to a lot of panel headers usable only by omapdss. A lot of these
platform data structs are trivial, and don't really need a separate header.
- Platform data would be eventually removed, and platform information would be
passed via device tree. Therefore, omapdss panel platform data structs are
temporary, and will be easier to remove if they are all in the same header.
- All board files will have to include the same header to configure a panel's
platform data, that makes the board files more consistent.
Signed-off-by: Archit Taneja <archit@ti.com>
CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
markings need to be removed.
This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.
Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.
Cc: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Register the DSS driver after SPI probe. This simplifies the
initialization. This is similar to what is being done e.g.
in panel-acx565akm.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The panel drivers contain enable, disable, suspend and resume calls.
The suspend and resume are effectively identical to disable and enable.
This patch removes panel suspend and enable code from omapdss and the
panel drivers, and replaces their use with enable and disable.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Recent commit dca2b1522ccab28d03fb79f6e70e70ea78033d52 (OMAPDSS: DSI:
Maintain copy of operation mode in driver data) broke DSI for video mode
displays. The commit changed the way dssdev->caps are initialized, and
the result was that every DSI display is initialized with manual-update
and tear-elim caps.
The code that sets dssdev->caps is not very good, even when fixed.
omapdss driver shouldn't be writing dssdev->caps at all.
This patch fixes the problem with video mode displays by moving the
initialization of dssdev->caps to the panel driver. The same change is
done for RFBI.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The RFBI driver currently relies on the omap_dss_device struct to receive the
rfbi specific timings requested by the panel driver. This makes the RFBI
interface driver dependent on the omap_dss_device struct.
Make the RFBI driver data maintain it's own rfbi specific timings field. The
panel driver is expected to call omapdss_rfbi_set_interface_timings() to
configure the rfbi timings before the interface is enabled.
Signed-off-by: Archit Taneja <archit@ti.com>
The RFBI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the RFBI interface
driver dependent on the omap_dss_device struct.
Make the RFBI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_rfbi_set_data_lines() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().
Signed-off-by: Archit Taneja <archit@ti.com>
The RFBI driver currently relies on the omap_dss_device struct to receive the
desired pixel size of the panel. This makes the RFBI interface driver dependent
on the omap_dss_device struct.
Make the RFBI driver data maintain it's own pixel format field. A panel driver
is expected to call omapdss_rfbi_set_pixel_size() to configure the pixel format
before enabling the interface or calling omap_rfbi_configure().
Signed-off-by: Archit Taneja <archit@ti.com>
RFBI drivers requires configuration of the update area. Since we don't support
partial updates, the size to be configures is the panel size itself.
Add a timings field in RFBI's driver data. Apart from x_res and y_res, all the
other fields are configured to an initial value when RFBI is enabled. A panel
driver is expected to call omapdss_rfbi_set_size() configure the size of the
panel.
Signed-off-by: Archit Taneja <archit@ti.com>
Partial update suppport was removed from DISPC and DSI sometime back. The RFBI
driver still tries to support partial update without the underlying support in
DISPC.
Remove partial update support from RFBI, only support updates which span acros
the whole panel size. This also helps in DSI and RFBI having similar update
ops.
Signed-off-by: Archit Taneja <archit@ti.com>
Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.
We don't support passive matrix displays any more. Remove this flag from all the
panel drivers.
Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
In ancient times it was necessary to manually initialize the bus field of an
spi_driver to spi_bus_type. These days this is done in spi_driver_register(),
so we can drop the manual assignment.
The patch was generated using the following coccinelle semantic patch:
// <smpl>
@@
identifier _driver;
@@
struct spi_driver _driver = {
.driver = {
- .bus = &spi_bus_type,
},
};
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
This is a driver for N800's display, ported from the old omapfb. This is
a slightly lighter version of the driver as not all features of the old
driver can be ported without big changes to DSS2, and also because some
of the HW features used in the old driver are unclear (e.g. the power
management part).
That said, the new driver works fine for basic use.
Architecturally the driver is not as neat as it could be. N800's display
HW consists of a display buffer chip and a panel, and ideally they would
be represented by separate, independent drivers. This is not currently
possible, and this driver contains both buffer chip and panel driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
