* 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
* Re: [PATCH] omapdss: dss: Fix clocks on OMAP363x
From: Tomi Valkeinen @ 2012-10-26 6:17 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <1351190530-16863-1-git-send-email-laurent.pinchart@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]
On 2012-10-25 21:42, Laurent Pinchart wrote:
> Commit 185bae1095188aa199c9be64d6030d8dbfc65e0a ("OMAPDSS: DSS: Cleanup
> cpu_is_xxxx checks") broke the DSS clocks configuration by erroneously
> using the clock parameters applicable to all other OMAP34xx SoCs for the
> OMAP363x. This went unnoticed probably because the cpu_is_omap34xx()
> class check wasn't seen as matching the OMAP363x subclass.
>
> Fix it by checking for the OMAP363x subclass before checking for the
> OMAP34xx class.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/video/omap2/dss/dss.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> Hi Tomi,
>
> The patch has been tested on the Beagleboard-xM and restores the DVI output
> operation. This is a regression fix that should be pushed to v3.7.
>
> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
> index 2ab1c3e..0bb7406 100644
> --- a/drivers/video/omap2/dss/dss.c
> +++ b/drivers/video/omap2/dss/dss.c
> @@ -805,10 +805,10 @@ static int __init dss_init_features(struct device *dev)
>
> if (cpu_is_omap24xx())
> src = &omap24xx_dss_feats;
> - else if (cpu_is_omap34xx())
> - src = &omap34xx_dss_feats;
> else if (cpu_is_omap3630())
> src = &omap3630_dss_feats;
> + else if (cpu_is_omap34xx())
> + src = &omap34xx_dss_feats;
> else if (cpu_is_omap44xx())
> src = &omap44xx_dss_feats;
> else if (soc_is_omap54xx())
>
Good catch, thanks. I don't have a 36xx board, so this went unnoticed.
I'll push it for 3.7-rc.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* [PATCH] omapdss: dss: Fix clocks on OMAP363x
From: Laurent Pinchart @ 2012-10-25 18:42 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
Commit 185bae1095188aa199c9be64d6030d8dbfc65e0a ("OMAPDSS: DSS: Cleanup
cpu_is_xxxx checks") broke the DSS clocks configuration by erroneously
using the clock parameters applicable to all other OMAP34xx SoCs for the
OMAP363x. This went unnoticed probably because the cpu_is_omap34xx()
class check wasn't seen as matching the OMAP363x subclass.
Fix it by checking for the OMAP363x subclass before checking for the
OMAP34xx class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/video/omap2/dss/dss.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Hi Tomi,
The patch has been tested on the Beagleboard-xM and restores the DVI output
operation. This is a regression fix that should be pushed to v3.7.
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 2ab1c3e..0bb7406 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -805,10 +805,10 @@ static int __init dss_init_features(struct device *dev)
if (cpu_is_omap24xx())
src = &omap24xx_dss_feats;
- else if (cpu_is_omap34xx())
- src = &omap34xx_dss_feats;
else if (cpu_is_omap3630())
src = &omap3630_dss_feats;
+ else if (cpu_is_omap34xx())
+ src = &omap34xx_dss_feats;
else if (cpu_is_omap44xx())
src = &omap44xx_dss_feats;
else if (soc_is_omap54xx())
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* Re: [PATCH 20/20] OMAPDSS: split hdmi muxing function
From: Tony Lindgren @ 2012-10-24 16:23 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: archit, linux-omap, linux-fbdev, Ricardo Neri
In-Reply-To: <1351070951-18616-21-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121024 02:32]:
> Split the omap4_hdmi_mux_pads() function into two parts, one handles the
> tpd12s015 gpio muxing, the other handles the hdmi pins.
>
> This is clearer, as hdmi and tpd12s015 are separate devices, and it also
> allows us to mux those separately with DT.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ricardo Neri <ricardo.neri@ti.com>
Looks OK to me to merge with the rest of the DSS patches:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
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