* [PATCH 02/12] OMAPFB: improve mode selection from EDID
From: Tomi Valkeinen @ 2012-10-30 16:09 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
The current omapfb code goes over all the modes found from the monitors
EDID data, and searches for a mode that is compatible with the DSS
hardware and has the highest x-res.
While this works ok as such, it proves problematic when using DSI PLL
for pixel clock. Calculating DSI PLL dividers is not the fastest of the
operations, and while doing it for one mode is usually ok, doing it for
20 modes is noticable.
Also, the first mode given in the EDID data should be the native mode of
the monitor, and thus also the best mode, so if that can be used, no
need to look further.
This patch changes the code to use the first mode that is compatible
with the DSS hardware.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 0358b14..6e5334c 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2258,7 +2258,7 @@ static int omapfb_find_best_mode(struct omap_dss_device *display,
{
struct fb_monspecs *specs;
u8 *edid;
- int r, i, best_xres, best_idx, len;
+ int r, i, best_idx, len;
if (!display->driver->read_edid)
return -ENODEV;
@@ -2274,7 +2274,6 @@ static int omapfb_find_best_mode(struct omap_dss_device *display,
fb_edid_to_monspecs(edid, specs);
- best_xres = 0;
best_idx = -1;
for (i = 0; i < specs->modedb_len; ++i) {
@@ -2290,16 +2289,20 @@ static int omapfb_find_best_mode(struct omap_dss_device *display,
if (m->xres = 2880 || m->xres = 1440)
continue;
+ if (m->vmode & FB_VMODE_INTERLACED ||
+ m->vmode & FB_VMODE_DOUBLE)
+ continue;
+
fb_videomode_to_omap_timings(m, display, &t);
r = display->driver->check_timings(display, &t);
- if (r = 0 && best_xres < m->xres) {
- best_xres = m->xres;
+ if (r = 0) {
best_idx = i;
+ break;
}
}
- if (best_xres = 0) {
+ if (best_idx = -1) {
r = -ENOENT;
goto err2;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 01/12] OMAPFB: remove use of extended edid block
From: Tomi Valkeinen @ 2012-10-30 16:09 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
In-Reply-To: <1351613409-21186-1-git-send-email-tomi.valkeinen@ti.com>
It seems that using the second EDID block causes more problems than is
of any help. The first mode in the extended block will get
FB_MODE_IS_FIRST set, which will override the first mode from the first
EDID block, thus making the default videomode selection not to work
properly.
This patch removes the use of the extended edid block for now.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index bc225e4..0358b14 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2274,9 +2274,6 @@ static int omapfb_find_best_mode(struct omap_dss_device *display,
fb_edid_to_monspecs(edid, specs);
- if (edid[126] > 0)
- fb_edid_add_monspecs(edid + 0x80, specs);
-
best_xres = 0;
best_idx = -1;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 00/12] OMAPDSS: use DSI PLL clk for DPI
From: Tomi Valkeinen @ 2012-10-30 16:09 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: rob, Tomi Valkeinen
Hi,
The aim of this series is to enable using DSI PLL as the pixel clock source for
DPI output. There are the following main parts:
* first 4 patches are slightly related generic improvements/fixes
* fix DSI PLL problem related to non-50% duty cycle
* fix DSI PLL problem related to powering
* changes to the clock handling to always use DSI PLL for DPI when possible
I've tested the series on OMAP4 Panda, OMAP4 SDP and OMAP3 Beagle.
Tomi
Tomi Valkeinen (12):
OMAPFB: remove use of extended edid block
OMAPFB: improve mode selection from EDID
OMAPDSS: fix DPI & DSI init order
OMAPDSS: fix DSI2 PLL clk names
OMAPDSS: DSI: skip odd dividers when pck >= 100MHz
OMAPDSS: DSI: workaround for HSDiv problem
OMAPDSS: add dss_calc_clock_rates() back
OMAPDSS: setup default dss fck
OMAPDSS: hide dss_select_dispc_clk_source()
OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll
OMAPDSS: DPI: verify if DSI PLL is operational
OMAPDSS: DPI: always use DSI PLL if available
drivers/video/omap2/dss/core.c | 12 ++--
drivers/video/omap2/dss/dpi.c | 99 +++++++++++++++++++++---------
drivers/video/omap2/dss/dsi.c | 14 ++++-
drivers/video/omap2/dss/dss.c | 67 +++++++++++++++++++-
drivers/video/omap2/dss/dss.h | 2 +-
drivers/video/omap2/dss/hdmi.c | 8 ---
drivers/video/omap2/omapfb/omapfb-main.c | 16 ++---
7 files changed, 160 insertions(+), 58 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: [PATCH v3] video: Versatile Express DVI output driver
From: Pawel Moll @ 2012-10-30 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350405036-17997-1-git-send-email-pawel.moll@arm.com>
Hello again Florian,
On Tue, 2012-10-16 at 17:30 +0100, Pawel Moll wrote:
> Versatile Express' DVI video output can be connected to one the three
> sources - motherboard's CLCD controller or a video signal generated
> by one of the daughterboards.
>
> This driver configures the muxer FPGA so the output displays content
> of one of the framebuffers in the system (0 by default, can be changed
> by user writing to the "fb" sysfs attribute of the muxfpga device).
>
> It will also set up the display formatter mode and keep it up
> to date with mode changes requested by the user (eg. with fbset
> tool).
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
It's just a polite a friendly nag regarding this patch - it's been 2
weeks since I posted this version (and 1.5 month since the first one)...
Does it look good enough or completely wrong?
Cheers!
Paweł
^ permalink raw reply
* Re: [PATCH 05/20] OMAPDSS: remove initial display code from omapdss
From: Archit Taneja @ 2012-10-29 10:48 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <508E597F.60406@ti.com>
On Monday 29 October 2012 03:55 PM, Tomi Valkeinen wrote:
> On 2012-10-29 12:04, Archit Taneja wrote:
>> On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote:
>>> Currently omapdss driver sets up the initial connections between
>>> overlays, overlay manager and a panel, based on default display
>>> parameter coming from the board file or via module parameters.
>>>
>>> This is unnecessary, as it's the higher level component that should
>>> decide what display to use and how. This patch removes the code from
>>> omapdss, and implements similar code to omapfb.
>>>
>>> The def_disp module parameter and the default display platform_data
>>> parameter are kept in omapdss, but omapdss doesn't do anything with
>>> them. It will just return the default display name with
>>> dss_get_default_display_name() call, which omapfb uses. This is done to
>>> keep the backward compatibility.
>>
>> We might need to do something similar for omap_vout and omapdrm also to
>> set the initial connections.
>
> I believe omapdrm already does this.
>
> For omap_vout... I'm not sure if we can do that. Both omapfb and
> omap_vout work at the same time, so they could be setting up the
> settings at the same time, perhaps with conflicting values. The reason I
> left omap_vout out is that I think omapfb is always used with omap_vout,
> thus the config can be left for omapfb. I didn't test this, though.
I thought we could have omap_vout without omapfb, at least we can build
it separately. Anyway, setting initial connections in omap_vout doesn't
seem very important as we generally have both of them together.
>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> drivers/video/omap2/dss/core.c | 1 +
>>> drivers/video/omap2/dss/display.c | 78
>>> +++---------------------------
>>> drivers/video/omap2/omapfb/omapfb-main.c | 77
>>> ++++++++++++++++++++++++-----
>>> include/video/omapdss.h | 1 +
>>> 4 files changed, 75 insertions(+), 82 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/dss/core.c
>>> b/drivers/video/omap2/dss/core.c
>>> index 685d9a9..4cb669e 100644
>>> --- a/drivers/video/omap2/dss/core.c
>>> +++ b/drivers/video/omap2/dss/core.c
>>> @@ -57,6 +57,7 @@ const char *dss_get_default_display_name(void)
>>> {
>>> return core.default_display_name;
>>> }
>>> +EXPORT_SYMBOL(dss_get_default_display_name);
>>
>> Since we are exporting this, it might be better to name it
>> omapdss_get_default_display_name
>
> True.
>
>>> enum omapdss_version omapdss_get_version(void)
>>> {
>>> diff --git a/drivers/video/omap2/dss/display.c
>>> b/drivers/video/omap2/dss/display.c
>>> index 1e58730..6d33112 100644
>>> --- a/drivers/video/omap2/dss/display.c
>>> +++ b/drivers/video/omap2/dss/display.c
>>> @@ -320,86 +320,21 @@ void omapdss_default_get_timings(struct
>>> omap_dss_device *dssdev,
>>> }
>>> EXPORT_SYMBOL(omapdss_default_get_timings);
>>>
>>> -/*
>>> - * Connect dssdev to a manager if the manager is free or if force is
>>> specified.
>>> - * Connect all overlays to that manager if they are free or if force is
>>> - * specified.
>>> - */
>>> -static int dss_init_connections(struct omap_dss_device *dssdev, bool
>>> force)
>>> +int dss_init_device(struct platform_device *pdev,
>>> + struct omap_dss_device *dssdev)
>>> {
>>> + struct device_attribute *attr;
>>> struct omap_dss_output *out;
>>> - struct omap_overlay_manager *mgr;
>>> int i, r;
>>>
>>> out = omapdss_get_output_from_dssdev(dssdev);
>>>
>>> - WARN_ON(dssdev->output);
>>> - WARN_ON(out->device);
>>> -
>>> r = omapdss_output_set_device(out, dssdev);
>>> if (r) {
>>> DSSERR("failed to connect output to new device\n");
>>> return r;
>>> }
>>
>> So, we still manage the output-device links in the omapdss driver, but
>> move the manager-output and overlay-manager links to omapfb. I guess
>> this is fine. But maybe this split might change based on how generic
>> panel framework looks like, and how much we want to expose outputs to
>> fb/drm.
>
> We can set the output-device link in omapdss because it's a hardware
> configuration. A panel is connected to an output, so there's nothing to
> configure there. ovls and ovl-mgrs, on the other hand, may be configured
> depending on the use cases.
Yes, that makes sense.
Archit
^ permalink raw reply
* Re: [PATCH 11/20] OMAPDSS: HDMI: split power_on/off to two parts
From: Tomi Valkeinen @ 2012-10-29 10:30 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev, Ricardo Neri
In-Reply-To: <508E570D.1000101@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3819 bytes --]
On 2012-10-29 12:14, Archit Taneja wrote:
> On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
>> There's currently just one power-on function for HDMI, which enables the
>> IP and the video output. When reading EDID or detecting if a monitor is
>> connected, we don't need the video output.
>>
>> Enabling the video output for these operations is not a big problem in
>> itself, but the quick enable/disable cycles caused by the operations
>> seem to cause sync lost errors from time to time. Also, this makes it
>> possible to read the EDID before the full video path has been set up.
>>
>> This patch splits the hdmi_power_on into two parts, hdmi_power_on_core
>> and hdmi_power_on_full. The "full" version does what hdmi_power_on does
>> currently, and hdmi_power_on_core only enables the core IP. Similar
>> changes are made for power_off.
>>
>> Note that these don't allow the HDMI IP to be first enabled, and later
>> enable the video output, but the HDMI IP will first need to be powered
>> off before calling the full version. So this is rather limited
>> implementation, but it fills the needs for reading EDID.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Cc: Ricardo Neri <ricardo.neri@ti.com>
>> ---
>> drivers/video/omap2/dss/hdmi.c | 75
>> ++++++++++++++++++++++++----------------
>> 1 file changed, 46 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/hdmi.c
>> b/drivers/video/omap2/dss/hdmi.c
>> index c1c5488..50d5a10 100644
>> --- a/drivers/video/omap2/dss/hdmi.c
>> +++ b/drivers/video/omap2/dss/hdmi.c
>> @@ -500,12 +500,9 @@ static void hdmi_compute_pll(struct
>> omap_dss_device *dssdev, int phy,
>> DSSDBG("range = %d sd = %d\n", pi->dcofreq, pi->regsd);
>> }
>>
>> -static int hdmi_power_on(struct omap_dss_device *dssdev)
>> +static int hdmi_power_on_core(struct omap_dss_device *dssdev)
>> {
>> int r;
>> - struct omap_video_timings *p;
>> - struct omap_overlay_manager *mgr = dssdev->output->manager;
>> - unsigned long phy;
>>
>> gpio_set_value(hdmi.ct_cp_hpd_gpio, 1);
>> gpio_set_value(hdmi.ls_oe_gpio, 1);
>> @@ -521,6 +518,46 @@ static int hdmi_power_on(struct omap_dss_device
>> *dssdev)
>> if (r)
>> goto err_runtime_get;
>>
>> + /* Make selection of HDMI in DSS */
>> + dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
>> +
>> + /* Select the dispc clock source as PRCM clock, to ensure that it
>> is not
>> + * DSI PLL source as the clock selected by DSI PLL might not be
>> + * sufficient for the resolution selected / that can be changed
>> + * dynamically by user. This can be moved to single location , say
>> + * Boardfile.
>> + */
>> + dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
>> +
>> + return 0;
>> +
>> +err_runtime_get:
>> + regulator_disable(hdmi.vdda_hdmi_dac_reg);
>> +err_vdac_enable:
>> + gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
>> + gpio_set_value(hdmi.ls_oe_gpio, 0);
>> + return r;
>> +}
>> +
>> +static void hdmi_power_off_core(struct omap_dss_device *dssdev)
>> +{
>> + hdmi_runtime_put();
>> + regulator_disable(hdmi.vdda_hdmi_dac_reg);
>> + gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
>> + gpio_set_value(hdmi.ls_oe_gpio, 0);
>
> We might want to set the DISPC clock source back to DSS_FCK here. Just
> in case it was using something else. Having this still won't make things
> full proof, but probably slightly better.
In this patch I only split the code, keeping the current behavior. But
true, setting the clk src back to DSS_FCK makes sense. Although I'd
rather remove the whole dispc clk src call, as the output drivers
calling it can easily mess things up.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* Re: [PATCH 19/20] OMAPDSS: DISPC: remove dssdev depependency from error handler
From: Archit Taneja @ 2012-10-29 10:30 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <508E389C.8080503@ti.com>
On Monday 29 October 2012 01:34 PM, Tomi Valkeinen wrote:
> On 2012-10-29 09:12, Archit Taneja wrote:
>> Hi,
>>
>> On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
>>> The dispc error handler tries to "fix" issues by disabling and enabling
>>> panel. This is problematic, as we're trying to remove the dependency
>>> from omapdss to the omap_dss_devices. It's also racy, and doesn't really
>>> fix anything.
>>>
>>> This patch removes the use of omap_dss_device from the error handler,
>>> and just disables and enables the associated overlay manager. This
>>> should produce similar results as the previous solution, without using
>>> dssdev.
>>
>> Calling APPLY functions from the DISPC driver seems a bit incorrect.
>> Instead of disabling/enabling the panel, can't we disable/enable the
>> manger by just using DISPC funcs?
>
> I agree, but if we don't call apply functions, we're bypassing the
> locks/etc from apply, and we could end up messing up what apply.c thinks
> is going on.
>
> With my omapdss+omapdrm compatibility patch series I'm moving the error
> handler to the apply mechanism, so it becomes a bit saner.
Okay. Having the error handler in apply would make things better.
Archit
^ permalink raw reply
* Re: [PATCH 09/20] OMAPDSS: add dispc_ovl_enabled()
From: Tomi Valkeinen @ 2012-10-29 10:28 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <508E55BC.5060607@ti.com>
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
On 2012-10-29 12:09, Archit Taneja wrote:
> On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
>> Add new dispc function, dispc_ovl_enabled(). This returns if the overlay
>> enable bit is set in the registers.
>
> Is this function used by omapdrm? I can't see it being used in the later
> patches.
Yes, it will be used by omapdrm (or, at least, it can be used). I guess
some of these patches don't quite make sense without the final
compat-layer work, and modifications to omapdrm. But mostly the "doesn't
make sense" parts are probably just exposing functions that aren't used yet.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* Re: [PATCH 11/20] OMAPDSS: HDMI: split power_on/off to two parts
From: Archit Taneja @ 2012-10-29 10:26 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, Ricardo Neri
In-Reply-To: <1351070951-18616-12-git-send-email-tomi.valkeinen@ti.com>
On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
> There's currently just one power-on function for HDMI, which enables the
> IP and the video output. When reading EDID or detecting if a monitor is
> connected, we don't need the video output.
>
> Enabling the video output for these operations is not a big problem in
> itself, but the quick enable/disable cycles caused by the operations
> seem to cause sync lost errors from time to time. Also, this makes it
> possible to read the EDID before the full video path has been set up.
>
> This patch splits the hdmi_power_on into two parts, hdmi_power_on_core
> and hdmi_power_on_full. The "full" version does what hdmi_power_on does
> currently, and hdmi_power_on_core only enables the core IP. Similar
> changes are made for power_off.
>
> Note that these don't allow the HDMI IP to be first enabled, and later
> enable the video output, but the HDMI IP will first need to be powered
> off before calling the full version. So this is rather limited
> implementation, but it fills the needs for reading EDID.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ricardo Neri <ricardo.neri@ti.com>
> ---
> drivers/video/omap2/dss/hdmi.c | 75 ++++++++++++++++++++++++----------------
> 1 file changed, 46 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
> index c1c5488..50d5a10 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -500,12 +500,9 @@ static void hdmi_compute_pll(struct omap_dss_device *dssdev, int phy,
> DSSDBG("range = %d sd = %d\n", pi->dcofreq, pi->regsd);
> }
>
> -static int hdmi_power_on(struct omap_dss_device *dssdev)
> +static int hdmi_power_on_core(struct omap_dss_device *dssdev)
> {
> int r;
> - struct omap_video_timings *p;
> - struct omap_overlay_manager *mgr = dssdev->output->manager;
> - unsigned long phy;
>
> gpio_set_value(hdmi.ct_cp_hpd_gpio, 1);
> gpio_set_value(hdmi.ls_oe_gpio, 1);
> @@ -521,6 +518,46 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
> if (r)
> goto err_runtime_get;
>
> + /* Make selection of HDMI in DSS */
> + dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
> +
> + /* Select the dispc clock source as PRCM clock, to ensure that it is not
> + * DSI PLL source as the clock selected by DSI PLL might not be
> + * sufficient for the resolution selected / that can be changed
> + * dynamically by user. This can be moved to single location , say
> + * Boardfile.
> + */
> + dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
> +
> + return 0;
> +
> +err_runtime_get:
> + regulator_disable(hdmi.vdda_hdmi_dac_reg);
> +err_vdac_enable:
> + gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
> + gpio_set_value(hdmi.ls_oe_gpio, 0);
> + return r;
> +}
> +
> +static void hdmi_power_off_core(struct omap_dss_device *dssdev)
> +{
> + hdmi_runtime_put();
> + regulator_disable(hdmi.vdda_hdmi_dac_reg);
> + gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
> + gpio_set_value(hdmi.ls_oe_gpio, 0);
We might want to set the DISPC clock source back to DSS_FCK here. Just
in case it was using something else. Having this still won't make things
full proof, but probably slightly better.
Archit
^ permalink raw reply
* Re: [PATCH 05/20] OMAPDSS: remove initial display code from omapdss
From: Tomi Valkeinen @ 2012-10-29 10:25 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <508E54C8.9070209@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4181 bytes --]
On 2012-10-29 12:04, Archit Taneja wrote:
> On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote:
>> Currently omapdss driver sets up the initial connections between
>> overlays, overlay manager and a panel, based on default display
>> parameter coming from the board file or via module parameters.
>>
>> This is unnecessary, as it's the higher level component that should
>> decide what display to use and how. This patch removes the code from
>> omapdss, and implements similar code to omapfb.
>>
>> The def_disp module parameter and the default display platform_data
>> parameter are kept in omapdss, but omapdss doesn't do anything with
>> them. It will just return the default display name with
>> dss_get_default_display_name() call, which omapfb uses. This is done to
>> keep the backward compatibility.
>
> We might need to do something similar for omap_vout and omapdrm also to
> set the initial connections.
I believe omapdrm already does this.
For omap_vout... I'm not sure if we can do that. Both omapfb and
omap_vout work at the same time, so they could be setting up the
settings at the same time, perhaps with conflicting values. The reason I
left omap_vout out is that I think omapfb is always used with omap_vout,
thus the config can be left for omapfb. I didn't test this, though.
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/dss/core.c | 1 +
>> drivers/video/omap2/dss/display.c | 78
>> +++---------------------------
>> drivers/video/omap2/omapfb/omapfb-main.c | 77
>> ++++++++++++++++++++++++-----
>> include/video/omapdss.h | 1 +
>> 4 files changed, 75 insertions(+), 82 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/core.c
>> b/drivers/video/omap2/dss/core.c
>> index 685d9a9..4cb669e 100644
>> --- a/drivers/video/omap2/dss/core.c
>> +++ b/drivers/video/omap2/dss/core.c
>> @@ -57,6 +57,7 @@ const char *dss_get_default_display_name(void)
>> {
>> return core.default_display_name;
>> }
>> +EXPORT_SYMBOL(dss_get_default_display_name);
>
> Since we are exporting this, it might be better to name it
> omapdss_get_default_display_name
True.
>> enum omapdss_version omapdss_get_version(void)
>> {
>> diff --git a/drivers/video/omap2/dss/display.c
>> b/drivers/video/omap2/dss/display.c
>> index 1e58730..6d33112 100644
>> --- a/drivers/video/omap2/dss/display.c
>> +++ b/drivers/video/omap2/dss/display.c
>> @@ -320,86 +320,21 @@ void omapdss_default_get_timings(struct
>> omap_dss_device *dssdev,
>> }
>> EXPORT_SYMBOL(omapdss_default_get_timings);
>>
>> -/*
>> - * Connect dssdev to a manager if the manager is free or if force is
>> specified.
>> - * Connect all overlays to that manager if they are free or if force is
>> - * specified.
>> - */
>> -static int dss_init_connections(struct omap_dss_device *dssdev, bool
>> force)
>> +int dss_init_device(struct platform_device *pdev,
>> + struct omap_dss_device *dssdev)
>> {
>> + struct device_attribute *attr;
>> struct omap_dss_output *out;
>> - struct omap_overlay_manager *mgr;
>> int i, r;
>>
>> out = omapdss_get_output_from_dssdev(dssdev);
>>
>> - WARN_ON(dssdev->output);
>> - WARN_ON(out->device);
>> -
>> r = omapdss_output_set_device(out, dssdev);
>> if (r) {
>> DSSERR("failed to connect output to new device\n");
>> return r;
>> }
>
> So, we still manage the output-device links in the omapdss driver, but
> move the manager-output and overlay-manager links to omapfb. I guess
> this is fine. But maybe this split might change based on how generic
> panel framework looks like, and how much we want to expose outputs to
> fb/drm.
We can set the output-device link in omapdss because it's a hardware
configuration. A panel is connected to an output, so there's nothing to
configure there. ovls and ovl-mgrs, on the other hand, may be configured
depending on the use cases.
But yes, I wouldn't be surprised if this will be changed with common
panel framework.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* Re: [PATCH 09/20] OMAPDSS: add dispc_ovl_enabled()
From: Archit Taneja @ 2012-10-29 10:21 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1351070951-18616-10-git-send-email-tomi.valkeinen@ti.com>
On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
> Add new dispc function, dispc_ovl_enabled(). This returns if the overlay
> enable bit is set in the registers.
Is this function used by omapdrm? I can't see it being used in the later
patches.
Archit
^ permalink raw reply
* Re: [PATCH 05/20] OMAPDSS: remove initial display code from omapdss
From: Archit Taneja @ 2012-10-29 10:16 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1351070951-18616-6-git-send-email-tomi.valkeinen@ti.com>
On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote:
> Currently omapdss driver sets up the initial connections between
> overlays, overlay manager and a panel, based on default display
> parameter coming from the board file or via module parameters.
>
> This is unnecessary, as it's the higher level component that should
> decide what display to use and how. This patch removes the code from
> omapdss, and implements similar code to omapfb.
>
> The def_disp module parameter and the default display platform_data
> parameter are kept in omapdss, but omapdss doesn't do anything with
> them. It will just return the default display name with
> dss_get_default_display_name() call, which omapfb uses. This is done to
> keep the backward compatibility.
We might need to do something similar for omap_vout and omapdrm also to
set the initial connections.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/core.c | 1 +
> drivers/video/omap2/dss/display.c | 78 +++---------------------------
> drivers/video/omap2/omapfb/omapfb-main.c | 77 ++++++++++++++++++++++++-----
> include/video/omapdss.h | 1 +
> 4 files changed, 75 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
> index 685d9a9..4cb669e 100644
> --- a/drivers/video/omap2/dss/core.c
> +++ b/drivers/video/omap2/dss/core.c
> @@ -57,6 +57,7 @@ const char *dss_get_default_display_name(void)
> {
> return core.default_display_name;
> }
> +EXPORT_SYMBOL(dss_get_default_display_name);
Since we are exporting this, it might be better to name it
omapdss_get_default_display_name
>
> enum omapdss_version omapdss_get_version(void)
> {
> diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
> index 1e58730..6d33112 100644
> --- a/drivers/video/omap2/dss/display.c
> +++ b/drivers/video/omap2/dss/display.c
> @@ -320,86 +320,21 @@ void omapdss_default_get_timings(struct omap_dss_device *dssdev,
> }
> EXPORT_SYMBOL(omapdss_default_get_timings);
>
> -/*
> - * Connect dssdev to a manager if the manager is free or if force is specified.
> - * Connect all overlays to that manager if they are free or if force is
> - * specified.
> - */
> -static int dss_init_connections(struct omap_dss_device *dssdev, bool force)
> +int dss_init_device(struct platform_device *pdev,
> + struct omap_dss_device *dssdev)
> {
> + struct device_attribute *attr;
> struct omap_dss_output *out;
> - struct omap_overlay_manager *mgr;
> int i, r;
>
> out = omapdss_get_output_from_dssdev(dssdev);
>
> - WARN_ON(dssdev->output);
> - WARN_ON(out->device);
> -
> r = omapdss_output_set_device(out, dssdev);
> if (r) {
> DSSERR("failed to connect output to new device\n");
> return r;
> }
So, we still manage the output-device links in the omapdss driver, but
move the manager-output and overlay-manager links to omapfb. I guess
this is fine. But maybe this split might change based on how generic
panel framework looks like, and how much we want to expose outputs to
fb/drm.
Archit
^ permalink raw reply
* Re: [PATCH 04/20] OMAPDSS: DISPC: fix dispc_mgr_lclk_rate for DIGIT output
From: Tomi Valkeinen @ 2012-10-29 9:56 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <508E5161.2060202@ti.com>
[-- Attachment #1: Type: text/plain, Size: 763 bytes --]
On 2012-10-29 11:50, Archit Taneja wrote:
> On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote:
>> dispc_mgr_lclk_rate() cannot currently be called with DIGIT channel
>> parameter, even if dispc_ovl_lclk_rate() can. Fix this by making
>
> It's called dispc_plane_lclk_rate() right now.
Right, that was a typo on the description.
>> dispc_mgr_lclk_rate() handle DIGIT channel also.
>
> Did you see a bug with this? Or is this just a cleanup?
Yes, I had a crash when I was implementing a function to check the
scaling and overlay parameters in such a way that all the parameters are
given to the function, i.e. the func doesn't get any config from the
hardware registers. So not a bug that happens in the current driver.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* Re: [PATCH 04/20] OMAPDSS: DISPC: fix dispc_mgr_lclk_rate for DIGIT output
From: Archit Taneja @ 2012-10-29 9:50 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1351070951-18616-5-git-send-email-tomi.valkeinen@ti.com>
On Wednesday 24 October 2012 02:58 PM, Tomi Valkeinen wrote:
> dispc_mgr_lclk_rate() cannot currently be called with DIGIT channel
> parameter, even if dispc_ovl_lclk_rate() can. Fix this by making
It's called dispc_plane_lclk_rate() right now.
> dispc_mgr_lclk_rate() handle DIGIT channel also.
Did you see a bug with this? Or is this just a cleanup?
Archit
^ permalink raw reply
* Re: [PATCH 19/20] OMAPDSS: DISPC: remove dssdev depependency from error handler
From: Tomi Valkeinen @ 2012-10-29 8:04 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <508E2C48.6020008@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
On 2012-10-29 09:12, Archit Taneja wrote:
> Hi,
>
> On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
>> The dispc error handler tries to "fix" issues by disabling and enabling
>> panel. This is problematic, as we're trying to remove the dependency
>> from omapdss to the omap_dss_devices. It's also racy, and doesn't really
>> fix anything.
>>
>> This patch removes the use of omap_dss_device from the error handler,
>> and just disables and enables the associated overlay manager. This
>> should produce similar results as the previous solution, without using
>> dssdev.
>
> Calling APPLY functions from the DISPC driver seems a bit incorrect.
> Instead of disabling/enabling the panel, can't we disable/enable the
> manger by just using DISPC funcs?
I agree, but if we don't call apply functions, we're bypassing the
locks/etc from apply, and we could end up messing up what apply.c thinks
is going on.
With my omapdss+omapdrm compatibility patch series I'm moving the error
handler to the apply mechanism, so it becomes a bit saner.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* [PATCH 2/2] video: da8xx-fb: add device tree binding information
From: Manjunathappa, Prakash @ 2012-10-29 7:33 UTC (permalink / raw)
To: linux-fbdev, devicetree-discuss
Cc: FlorianSchandinat, grant.likely, rob.herring,
davinci-linux-open-source, linux-doc, rob, s.trumtrar,
Manjunathappa, Prakash
In-Reply-To: <1351495266-1202-1-git-send-email-prakash.pm@ti.com>
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
Documentation/devicetree/bindings/fb/da8xx-fb.txt | 86 +++++++++++++++++++++
1 files changed, 86 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/da8xx-fb.txt
diff --git a/Documentation/devicetree/bindings/fb/da8xx-fb.txt b/Documentation/devicetree/bindings/fb/da8xx-fb.txt
new file mode 100644
index 0000000..3fc2ef9
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/da8xx-fb.txt
@@ -0,0 +1,86 @@
+* Texas Instruments DaVinci da8xx-fb
+
+This file provides information of da830-fb device node.
+
+Required properties:
+- compatible : "ti,da830-lcd" : for DA830, DA850 and am335x platforms
+- reg : Offset and length of the register set for the device.
+- interrupts : standard interrupt property.
+- interrupt-parent : The phandle for the interrupt controller that
+ services interrupts for this device.
+- panel_shade : panel shade for-ex MONOCHROME, PASSIVE, ACTIVE.
+- bpp : bits per pixel resolution.
+- display-timings: Panel timing information.
+
+Optional properties:
+- ac-bias : AC Bias Pin Frequency. This value defines the
+ number of Line Clock (LCD_HSYNC) cycles to count
+ before transitioning signal LCD_AC_ENB_CS. This
+ output may be used to periodically invert the
+ polarity of the power supply in order to prevent a
+ display DC charge build-up on the LCD panel.
+
+- ac-bias-intrpt : This value is used to specify the number of AC
+ Bias(LCD_AC_ENB_CS) output transition counts
+ before setting the AC bias interrupt bit in
+ register LCD_STAT. This counter is stopped when
+ the interrupt is set and remains stopped until the
+ AC bias interrupt status is cleared. A value of
+ zero will not produce an interrupt.
+
+- tft-alt-mode : TFT Alternative Signal Mapping
+- stn-565-mode : 12-Bit-Per-Pixel (5-6-5) Mode. This is only
+ available in passive-color (STN) mode when 12 BPP
+ is specified in the palette.
+
+- mono-8bit-mode : Mono 8-bit Mode
+
+- sync-edge : This determines whether the HSYNC/VSYNC is driven
+ on the rising or falling edge of the pixel clock
+
+- raster-order : Decides data order, if 0 frame buffer data is
+ ordered from least-to-most significant bit/nibble/
+ byte/word/d-word else most-to- least significant..
+
+- panel : panel name along manufacturer name.
+- dma-burst-sz : Burst Size setting for DMA transfers
+- fifo-threshold : DMA FIFO threshold. The input FIFO becomes ready
+ so that the Raster controller can start reading
+ its content only when the number of dwords (1
+ dword is 4 bytes) specified by TH_FIFO_READY have
+ been loaded by the DMA from the frame buffer to
+ the input FIFO.
+
+- fdd : FIFO DMA Request Delay. Encoded value used to
+ specify the number of clocks the input FIFO DMA
+ request should be disabled. The delay clock count
+ starts after 16 words are loaded into the input
+ FIFO.
+
+Example for da850-evm:
+ lcd0: lcd@1e13000 {
+ compatible = "ti,da8xx-lcd";
+ reg = <0x213000 0x1000>;
+ clock-frequency = <150000000>;
+ interrupts = <52>;
+ interrupt-parent = <&intc>;
+ panel_shade = <1>;
+ bpp = <16>;
+ display-timings {
+ default-timing = <&timing0>;
+ timing0: 480x272p53 {
+ clock = <7833600>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <2>;
+ hback-porch = <2>;
+ hsync-len = <41>;
+ vback-porch = <3>;
+ vfront-porch = <3>;
+ vsync-len = <10>;
+ hsync-active-high;
+ vsync-active-high;
+ };
+ };
+ };
+
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] da8xx-fb: add DT support
From: Manjunathappa, Prakash @ 2012-10-29 7:33 UTC (permalink / raw)
To: linux-fbdev, devicetree-discuss
Cc: FlorianSchandinat, grant.likely, rob.herring,
davinci-linux-open-source, linux-doc, rob, s.trumtrar,
Manjunathappa, Prakash
adds device tree support for da8xx-fb driver.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
Depends on "of: Add display helper" [1] submitted by Steffen.
Above mentioned patch under review in community and has got
review comments. Preparing this patch to keep things moving.
@Steffen: Could you please include this in your next version of
your patch.
Applies on top of LCDC cleanup patches under community review [2].
[1]:http://marc.info/?l=dri-devel&m\x134937362110396&w=2
[2]:http://marc.info/?l=linux-fbdev&m\x135036440702662&w=2
drivers/video/da8xx-fb.c | 165 +++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 149 insertions(+), 16 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index f0f21c8..8a2b0f8 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -36,6 +36,7 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/lcm.h>
+#include <linux/of_videomode.h>
#include <video/da8xx-fb.h>
#include <asm/div64.h>
@@ -1211,12 +1212,134 @@ static unsigned int da8xxfb_pixel_clk_period(struct da8xx_fb_par *par)
return pix_clk_period_picosec;
}
+#ifdef CONFIG_OF
+static struct da8xx_lcdc_platform_data
+ *da8xx_lcdc_of_get_pdata(struct platform_device *pdev,
+ struct fb_videomode **lcdc_info)
+{
+ struct device_node *np;
+ struct da8xx_lcdc_platform_data *pdata = NULL;
+ struct lcd_ctrl_config *lcd_cfg;
+ struct fb_videomode *panel_data = NULL;
+ u32 data;
+ int ret;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(&pdev->dev, "Failed to allocate memory for struct da8xx_lcdc_platform_data\n");
+ goto nodata;
+ }
+ }
+
+ np = pdev->dev.of_node;
+ if (!np)
+ goto nodata;
+
+ *lcdc_info = devm_kzalloc(&pdev->dev, sizeof(struct fb_videomode),
+ GFP_KERNEL);
+ if (!*lcdc_info) {
+ dev_err(&pdev->dev, "Failed to allocate memory for struct fb_videomode\n");
+ pdata = NULL;
+ goto nodata;
+ }
+ panel_data = *lcdc_info;
+
+ lcd_cfg = devm_kzalloc(&pdev->dev, sizeof(struct lcd_ctrl_config),
+ GFP_KERNEL);
+ if (!lcd_cfg) {
+ dev_err(&pdev->dev, "Failed to allocate memory for struct lcd_ctrl_config\n");
+ pdata = NULL;
+ goto nodata;
+ }
+ pdata->controller_data = lcd_cfg;
+
+ ret = of_get_fb_videomode(np, panel_data, 0);
+ if (ret) {
+ dev_err(&pdev->dev, "fb videomode data not specified\n");
+ pdata = NULL;
+ goto nodata;
+ }
+ /* Pixel clock is expected in Hertz */
+ panel_data->pixclock = PICOS2KHZ(panel_data->pixclock) * 1000;
+
+ /* Required properties */
+ ret = of_property_read_u32(np, "panel-shade", &data);
+ if (ret) {
+ dev_err(&pdev->dev, "panel-shade not specified\n");
+ pdata = NULL;
+ goto nodata;
+ }
+ lcd_cfg->panel_shade = data;
+
+ ret = of_property_read_u32(np, "bpp", &data);
+ if (ret) {
+ dev_err(&pdev->dev, "BPP of panel not specified\n");
+ pdata = NULL;
+ goto nodata;
+ }
+ lcd_cfg->bpp = data;
+
+ /* Optional properties */
+ ret = of_property_read_u32(np, "ac-bias", &data);
+ if (!ret)
+ lcd_cfg->ac_bias = data;
+
+ ret = of_property_read_u32(np, "ac-bias-intrpt", &data);
+ if (!ret)
+ lcd_cfg->ac_bias_intrpt = data;
+
+ ret = of_property_read_u32(np, "dma-burst-sz", &data);
+ if (!ret)
+ lcd_cfg->dma_burst_sz = data;
+
+ ret = of_property_read_u32(np, "fdd", &data);
+ if (!ret)
+ lcd_cfg->fdd = data;
+
+ ret = of_property_read_u32(np, "tft-alt-mode", &data);
+ if (!ret)
+ lcd_cfg->tft_alt_mode = data;
+
+ ret = of_property_read_u32(np, "stn-565-mode", &data);
+ if (!ret)
+ lcd_cfg->stn_565_mode = data;
+
+ ret = of_property_read_u32(np, "mono-8bit-mode", &data);
+ if (!ret)
+ lcd_cfg->mono_8bit_mode = data;
+
+ ret = of_property_read_u32(np, "sync-edge", &data);
+ if (!ret)
+ lcd_cfg->sync_edge = data;
+
+ ret = of_property_read_u32(np, "raster-order", &data);
+ if (!ret)
+ lcd_cfg->raster_order = data;
+
+ ret = of_property_read_u32(np, "fifo-threshold", &data);
+ if (!ret)
+ lcd_cfg->fifo_th = data;
+
+ pdev->dev.platform_data = pdata;
+nodata:
+ return pdata;
+}
+#else
+static struct da8xx_lcdc_platform_data
+ *da8xx_lcdc_of_get_pdata(struct platform_device *pdev,
+ struct fb_videomode **lcdc_info)
+{
+ return pdev->dev.platform_data;
+}
+#endif
+
static int __devinit fb_probe(struct platform_device *device)
{
- struct da8xx_lcdc_platform_data *fb_pdata - device->dev.platform_data;
+ struct da8xx_lcdc_platform_data *fb_pdata = NULL;
struct lcd_ctrl_config *lcd_cfg;
- struct fb_videomode *lcdc_info;
+ struct fb_videomode *lcdc_info = NULL;
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
@@ -1224,6 +1347,7 @@ static int __devinit fb_probe(struct platform_device *device)
int ret, i;
unsigned long ulcm;
+ fb_pdata = da8xx_lcdc_of_get_pdata(device, &lcdc_info);
if (fb_pdata = NULL) {
dev_err(&device->dev, "Can not get platform data\n");
return -ENOENT;
@@ -1274,20 +1398,22 @@ static int __devinit fb_probe(struct platform_device *device)
break;
}
- for (i = 0, lcdc_info = known_lcd_panels;
- i < ARRAY_SIZE(known_lcd_panels);
- i++, lcdc_info++) {
- if (strcmp(fb_pdata->type, lcdc_info->name) = 0)
- break;
- }
+ if (device->dev.of_node = NULL) {
+ for (i = 0, lcdc_info = known_lcd_panels;
+ i < ARRAY_SIZE(known_lcd_panels);
+ i++, lcdc_info++) {
+ if (strcmp(fb_pdata->type, lcdc_info->name) = 0)
+ break;
+ }
- if (i = ARRAY_SIZE(known_lcd_panels)) {
- dev_err(&device->dev, "GLCD: No valid panel found\n");
- ret = -ENODEV;
- goto err_pm_runtime_disable;
- } else
- dev_info(&device->dev, "GLCD: Found %s panel\n",
- fb_pdata->type);
+ if (i = ARRAY_SIZE(known_lcd_panels)) {
+ dev_err(&device->dev, "GLCD: No valid panel found\n");
+ ret = -ENODEV;
+ goto err_pm_runtime_disable;
+ } else
+ dev_info(&device->dev, "GLCD: Found %s panel\n",
+ fb_pdata->type);
+ }
lcd_cfg = (struct lcd_ctrl_config *)fb_pdata->controller_data;
@@ -1577,6 +1703,12 @@ static int fb_resume(struct platform_device *dev)
#define fb_resume NULL
#endif
+static const struct of_device_id da830_lcdc_of_match[] = {
+ {.compatible = "ti,da830-lcd", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, da830_lcdc_of_match);
+
static struct platform_driver da8xx_fb_driver = {
.probe = fb_probe,
.remove = __devexit_p(fb_remove),
@@ -1585,6 +1717,7 @@ static struct platform_driver da8xx_fb_driver = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(da830_lcdc_of_match),
},
};
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 19/20] OMAPDSS: DISPC: remove dssdev depependency from error handler
From: Archit Taneja @ 2012-10-29 7:24 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1351070951-18616-20-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Wednesday 24 October 2012 02:59 PM, Tomi Valkeinen wrote:
> The dispc error handler tries to "fix" issues by disabling and enabling
> panel. This is problematic, as we're trying to remove the dependency
> from omapdss to the omap_dss_devices. It's also racy, and doesn't really
> fix anything.
>
> This patch removes the use of omap_dss_device from the error handler,
> and just disables and enables the associated overlay manager. This
> should produce similar results as the previous solution, without using
> dssdev.
Calling APPLY functions from the DISPC driver seems a bit incorrect.
Instead of disabling/enabling the panel, can't we disable/enable the
manger by just using DISPC funcs?
Archit
^ permalink raw reply
* [GIT PULL] SH Mobile LCDC patches
From: Laurent Pinchart @ 2012-10-28 23:33 UTC (permalink / raw)
To: linux-fbdev
Hi Florian,
The following changes since commit cd9d6f10d07f26dd8a70e519c22b6b4f8a9e3e7a:
gbefb: fix compile error (2012-10-11 00:23:15 +0000)
are available in the git repository at:
git://linuxtv.org/pinchartl/fbdev.git lcdc-next
Both Paul Mundt (arch/sh maintainer) and Simon Horman (arch/arm/mach-shmobile
maintainer) have agreed to get the arch patches in through your tree.
Hideki EIRAKU (1):
fbdev: sh_mobile_lcdc: use dma_mmap_coherent
Laurent Pinchart (19):
fbdev: sh_mobile_lcdc: Get display dimensions from the channel structure
fbdev: sh_mobile_lcdc: Rename mode argument to modes
fbdev: sh_mobile_lcdc: Remove priv argument from channel and overlay
init
ARM: mach-shmobile: ag5evm: Add LCDC tx_dev field to platform data
fbdev: sh_mipi_dsi: Add channel field to platform data
ARM: mach-shmobile: Initiliaze the new sh_mipi_dsi_info channel field
fbdev: sh_mipi_dsi: Use the sh_mipi_dsi_info channel field
fbdev: sh_mipi_dsi: Use the LCDC entity default mode
fbdev: sh_mipi_dsi: Remove last reference to LCDC platform data
ARM: mach-shmobile: Remove the unused sh_mipi_dsi_info lcd_chan field
fbdev: sh_mipi_dsi: Remove the unused sh_mipi_dsi_info lcd_chan field
fbdev: sh_mobile_lcdc: Store the backlight brightness internally
ARM: mach-shmobile: mackerel: Removed unused get_brightness callback
sh: ap325rxa: Remove unused get_brightness LCDC callback
sh: ecovec24: Remove unused get_brightness LCDC callback
fbdev: sh_mobile_lcdc: Remove unused get_brightness pdata callback
ARM: mach-shmobile: ag5evm: Use the backlight API for brightness control
sh: kfr2r09: Use the backlight API for brightness control
fbdev: sh_mobile_lcdc: Make sh_mobile_lcdc_sys_bus_ops static
arch/arm/mach-shmobile/board-ag5evm.c | 198 ++++++++++++++------------
arch/arm/mach-shmobile/board-ap4evb.c | 4 +-
arch/arm/mach-shmobile/board-mackerel.c | 6 -
arch/sh/boards/mach-ap325rxa/setup.c | 6 -
arch/sh/boards/mach-ecovec24/setup.c | 6 -
arch/sh/boards/mach-kfr2r09/lcd_wqvga.c | 16 +--
arch/sh/boards/mach-kfr2r09/setup.c | 7 +-
arch/sh/include/mach-kfr2r09/mach/kfr2r09.h | 6 +-
drivers/video/sh_mipi_dsi.c | 69 ++++------
drivers/video/sh_mobile_lcdcfb.c | 74 +++++++----
drivers/video/sh_mobile_lcdcfb.h | 1 +
include/video/sh_mipi_dsi.h | 4 +-
include/video/sh_mobile_lcdc.h | 1 -
13 files changed, 192 insertions(+), 206 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] lms283gf05: add suspend/resume handlers
From: Marek Vasut @ 2012-10-28 21:53 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1351439357-9843-1-git-send-email-anarsoul@gmail.com>
Dear Vasily Khoruzhick,
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/video/backlight/lms283gf05.c | 42
> ++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/video/backlight/lms283gf05.c
> b/drivers/video/backlight/lms283gf05.c index ea43f22..ed15752 100644
> --- a/drivers/video/backlight/lms283gf05.c
> +++ b/drivers/video/backlight/lms283gf05.c
> @@ -22,6 +22,7 @@
> struct lms283gf05_state {
> struct spi_device *spi;
> struct lcd_device *ld;
> + unsigned int power;
> };
>
> struct lms283gf05_seq {
> @@ -130,6 +131,8 @@ static int lms283gf05_power_set(struct lcd_device *ld,
> int power) struct spi_device *spi = st->spi;
> struct lms283gf05_pdata *pdata = spi->dev.platform_data;
>
> + st->power = power;
> +
> if (power <= FB_BLANK_NORMAL) {
> if (pdata)
> lms283gf05_reset(pdata->reset_gpio,
> @@ -193,6 +196,43 @@ static int __devinit lms283gf05_probe(struct
> spi_device *spi) return 0;
> }
>
> +#if defined(CONFIG_PM)
> +static unsigned int before_power;
NAK, this won't work if you have two different LCDs connected, use private data.
> +static int lms283gf05_suspend(struct spi_device *spi, pm_message_t mesg)
> +{
> + int ret = 0;
Redundant assignment.
> + struct lms283gf05_state *state = dev_get_drvdata(&spi->dev);
> +
> + dev_dbg(&spi->dev, "lcd->power = %d\n", state->power);
> +
> + before_power = state->power;
> +
> + /*
> + * when lcd panel is suspend, lcd panel becomes off
> + * regardless of status.
> + */
> + ret = lms283gf05_power_set(state->ld, FB_BLANK_POWERDOWN);
Why not just return lms...(); ?
> + return ret;
> +}
> +
> +static int lms283gf05_resume(struct spi_device *spi)
> +{
> + int ret = 0;
Redundant assignment.
> + struct lms283gf05_state *state = dev_get_drvdata(&spi->dev);
> +
> + dev_dbg(&spi->dev, "before_power = %d\n", before_power);
> +
> + ret = lms283gf05_power_set(state->ld, before_power);
> +
> + return ret;
> +}
> +#else
> +#define lms283gf05_suspend NULL
> +#define lms283gf05_resume NULL
> +#endif
> +
> static int __devexit lms283gf05_remove(struct spi_device *spi)
> {
> struct lms283gf05_state *st = dev_get_drvdata(&spi->dev);
> @@ -209,6 +249,8 @@ static struct spi_driver lms283gf05_driver = {
> },
> .probe = lms283gf05_probe,
> .remove = __devexit_p(lms283gf05_remove),
> + .suspend = lms283gf05_suspend,
> + .resume = lms283gf05_resume,
> };
>
> module_spi_driver(lms283gf05_driver);
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] lms283gf05: add suspend/resume handlers
From: Vasily Khoruzhick @ 2012-10-28 15:49 UTC (permalink / raw)
To: linux-fbdev
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/video/backlight/lms283gf05.c | 42 ++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/video/backlight/lms283gf05.c b/drivers/video/backlight/lms283gf05.c
index ea43f22..ed15752 100644
--- a/drivers/video/backlight/lms283gf05.c
+++ b/drivers/video/backlight/lms283gf05.c
@@ -22,6 +22,7 @@
struct lms283gf05_state {
struct spi_device *spi;
struct lcd_device *ld;
+ unsigned int power;
};
struct lms283gf05_seq {
@@ -130,6 +131,8 @@ static int lms283gf05_power_set(struct lcd_device *ld, int power)
struct spi_device *spi = st->spi;
struct lms283gf05_pdata *pdata = spi->dev.platform_data;
+ st->power = power;
+
if (power <= FB_BLANK_NORMAL) {
if (pdata)
lms283gf05_reset(pdata->reset_gpio,
@@ -193,6 +196,43 @@ static int __devinit lms283gf05_probe(struct spi_device *spi)
return 0;
}
+#if defined(CONFIG_PM)
+static unsigned int before_power;
+
+static int lms283gf05_suspend(struct spi_device *spi, pm_message_t mesg)
+{
+ int ret = 0;
+ struct lms283gf05_state *state = dev_get_drvdata(&spi->dev);
+
+ dev_dbg(&spi->dev, "lcd->power = %d\n", state->power);
+
+ before_power = state->power;
+
+ /*
+ * when lcd panel is suspend, lcd panel becomes off
+ * regardless of status.
+ */
+ ret = lms283gf05_power_set(state->ld, FB_BLANK_POWERDOWN);
+
+ return ret;
+}
+
+static int lms283gf05_resume(struct spi_device *spi)
+{
+ int ret = 0;
+ struct lms283gf05_state *state = dev_get_drvdata(&spi->dev);
+
+ dev_dbg(&spi->dev, "before_power = %d\n", before_power);
+
+ ret = lms283gf05_power_set(state->ld, before_power);
+
+ return ret;
+}
+#else
+#define lms283gf05_suspend NULL
+#define lms283gf05_resume NULL
+#endif
+
static int __devexit lms283gf05_remove(struct spi_device *spi)
{
struct lms283gf05_state *st = dev_get_drvdata(&spi->dev);
@@ -209,6 +249,8 @@ static struct spi_driver lms283gf05_driver = {
},
.probe = lms283gf05_probe,
.remove = __devexit_p(lms283gf05_remove),
+ .suspend = lms283gf05_suspend,
+ .resume = lms283gf05_resume,
};
module_spi_driver(lms283gf05_driver);
--
1.7.12.4
^ permalink raw reply related
* Re: tty, vt: lockdep warnings
From: Alan Cox @ 2012-10-26 13:37 UTC (permalink / raw)
To: Sasha Levin
Cc: Greg Kroah-Hartman, Jiri Slaby, linux-kernel@vger.kernel.org,
Dave Jones, linux-fbdev, florianSchandinat
In-Reply-To: <50899507.1040900@oracle.com>
On Thu, 25 Oct 2012 15:37:43 -0400
Sasha Levin <sasha.levin@oracle.com> wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools (lkvm) guest running latest -next kernel,
> I've stumbled on the following spew:
Looks real enough but its not a tty/vt layer spew. This is all coming out
of the core framebuffer code which doesn't seem to be able to decide what
the locking rules at the invocation of fb_notifier_call_chain are.
It might need some console layer tweaking to provide 'register console
and I already hold the locks' or similar but that notifier needs some
kind of sanity applying as well.
Cc'ing the fbdev folks
Alan
^ permalink raw reply
* [PATCH 3/3] video: s3c-fb: fix red offset and lengh for ARGB232 format
From: Jingoo Han @ 2012-10-26 7:02 UTC (permalink / raw)
To: linux-fbdev
Green pixel and blue pixel are 3 bits and 2 bits respectively
at ARGB232 format. Thus, the value of red offset should be 5,
not 4. Also, the value of red length should be 2, because
red pixel is 2 bits at ARGB232 format.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index f453b8b..d8bfb4a 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -268,10 +268,10 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
case 8:
if (sfb->variant.palette[win->index] != 0) {
/* non palletised, A:1,R:2,G:3,B:2 mode */
- var->red.offset = 4;
+ var->red.offset = 5;
var->green.offset = 2;
var->blue.offset = 0;
- var->red.length = 5;
+ var->red.length = 2;
var->green.length = 3;
var->blue.length = 2;
var->transp.offset = 7;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] video: s3c-fb: return an error when bpp is invalid
From: Jingoo Han @ 2012-10-26 7:01 UTC (permalink / raw)
To: linux-fbdev
This patch returns an error, when bpp is invalid in
s3c_fb_check_var(). If invalid bpp is requested,
an error should be returned.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 89cd278..f453b8b 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -330,6 +330,7 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
default:
dev_err(sfb->dev, "invalid bpp\n");
+ return -EINVAL;
}
dev_dbg(sfb->dev, "%s: verified parameters\n", __func__);
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] video: s3c-fb: add "drop through" comment
From: Jingoo Han @ 2012-10-26 7:00 UTC (permalink / raw)
To: linux-fbdev
This patch adds a "drop through" comment to improve
the readability.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 2ed7b63..89cd278 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -288,6 +288,7 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
/* 666 with one bit alpha/transparency */
var->transp.offset = 18;
var->transp.length = 1;
+ /* drop through */
case 18:
var->bits_per_pixel = 32;
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox