* 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
* [PATCH 20/20] OMAPDSS: split hdmi muxing function
From: Tomi Valkeinen @ 2012-10-24 9:29 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen, Ricardo Neri
In-Reply-To: <1351070951-18616-1-git-send-email-tomi.valkeinen@ti.com>
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>
---
arch/arm/mach-omap2/display.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 28f5087..282c814e 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -100,17 +100,20 @@ static const struct omap_dss_hwmod_data omap4_dss_hwmod_data[] __initconst = {
{ "dss_hdmi", "omapdss_hdmi", -1 },
};
-static void __init omap4_hdmi_mux_pads(enum omap_hdmi_flags flags)
+static void __init omap4_tpd12s015_mux_pads(void)
{
- u32 reg;
- u16 control_i2c_1;
-
omap_mux_init_signal("hdmi_cec",
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("hdmi_ddc_scl",
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("hdmi_ddc_sda",
OMAP_PIN_INPUT_PULLUP);
+}
+
+static void __init omap4_hdmi_mux_pads(enum omap_hdmi_flags flags)
+{
+ u32 reg;
+ u16 control_i2c_1;
/*
* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
@@ -161,8 +164,10 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
int __init omap_hdmi_init(enum omap_hdmi_flags flags)
{
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
omap4_hdmi_mux_pads(flags);
+ omap4_tpd12s015_mux_pads();
+ }
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 19/20] OMAPDSS: DISPC: remove dssdev depependency from error handler
From: Tomi Valkeinen @ 2012-10-24 9:29 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1351070951-18616-1-git-send-email-tomi.valkeinen@ti.com>
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.
However, the error handling is still horrible. But the problem boils
down to one question, to which I don't have a clear answer: what to do
when a HW error happens?
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 19 ++++---------------
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 070ce30..61b48ca 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3902,15 +3902,12 @@ static void dispc_error_worker(struct work_struct *work)
if (bit & errors) {
int j;
- struct omap_dss_device *dssdev = mgr->get_device(mgr);
- bool enable;
DSSERR("SYNC_LOST on channel %s, restarting the output "
"with video overlays disabled\n",
mgr->name);
- enable = dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
- dssdev->driver->disable(dssdev);
+ dss_mgr_disable(mgr);
for (j = 0; j < omap_dss_get_num_overlays(); ++j) {
struct omap_overlay *ovl;
@@ -3918,14 +3915,10 @@ static void dispc_error_worker(struct work_struct *work)
if (ovl->id != OMAP_DSS_GFX &&
ovl->manager = mgr)
- dispc_ovl_enable(ovl->id, false);
+ dss_ovl_disable(ovl);
}
- dispc_mgr_go(mgr->id);
- msleep(50);
-
- if (enable)
- dssdev->driver->enable(dssdev);
+ dss_mgr_enable(mgr);
}
}
@@ -3933,13 +3926,9 @@ static void dispc_error_worker(struct work_struct *work)
DSSERR("OCP_ERR\n");
for (i = 0; i < omap_dss_get_num_overlay_managers(); ++i) {
struct omap_overlay_manager *mgr;
- struct omap_dss_device *dssdev;
mgr = omap_dss_get_overlay_manager(i);
- dssdev = mgr->get_device(mgr);
-
- if (dssdev && dssdev->driver)
- dssdev->driver->disable(dssdev);
+ dss_mgr_disable(mgr);
}
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 18/20] OMAPDSS: DISPC: fix loop in error handler
From: Tomi Valkeinen @ 2012-10-24 9:29 UTC (permalink / raw)
To: archit, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1351070951-18616-1-git-send-email-tomi.valkeinen@ti.com>
The dispc's error handler has a loop inside another loop, and both use
the same loop variable. This is clearly wrong, and this patch makes a
new variable for the inner loop.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d294873..070ce30 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3901,6 +3901,7 @@ static void dispc_error_worker(struct work_struct *work)
bit = mgr_desc[i].sync_lost_irq;
if (bit & errors) {
+ int j;
struct omap_dss_device *dssdev = mgr->get_device(mgr);
bool enable;
@@ -3911,9 +3912,9 @@ static void dispc_error_worker(struct work_struct *work)
enable = dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
dssdev->driver->disable(dssdev);
- for (i = 0; i < omap_dss_get_num_overlays(); ++i) {
+ for (j = 0; j < omap_dss_get_num_overlays(); ++j) {
struct omap_overlay *ovl;
- ovl = omap_dss_get_overlay(i);
+ ovl = omap_dss_get_overlay(j);
if (ovl->id != OMAP_DSS_GFX &&
ovl->manager = mgr)
--
1.7.9.5
^ 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