* [PATCH 1/6] OMAPDSS: add omapdss_version
From: Tomi Valkeinen @ 2012-09-28 10:35 UTC (permalink / raw)
To: linux-omap, linux-fbdev
Cc: Archit Taneja, Chandrabhanu Mahapatra, Raphaël Assénat,
Tony Lindgren, Tomi Valkeinen
In-Reply-To: <1348828527-13309-1-git-send-email-tomi.valkeinen@ti.com>
Add new enum, omapdss_version, that is used to tell which DSS hardware
version the SoC has. This enum is initialized during platform init, and
passed in the platform data to omapdss driver.
Note that the versions are not "continuous", that is, you cannot check
if the version is less or greater than something, but you need to check
for exact version match. In other words, this is invalid:
/* test if DSS is 3630 or earlier */
if (ver <= OMAPDSS_VER_OMAP3630)
...
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/display.c | 38 ++++++++++++++++++++++++++++++++++++++
include/video/omapdss.h | 14 ++++++++++++++
2 files changed, 52 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index ee40739..33555da 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -284,6 +284,35 @@ err:
return ERR_PTR(r);
}
+static enum omapdss_version omap_display_get_version(void)
+{
+ if (cpu_is_omap24xx())
+ return OMAPDSS_VER_OMAP24xx;
+ else if (cpu_is_omap3630())
+ return OMAPDSS_VER_OMAP3630;
+ else if (cpu_is_omap34xx()) {
+ if (soc_is_am35xx()) {
+ return OMAPDSS_VER_AM35xx;
+ } else {
+ if (omap_rev() < OMAP3430_REV_ES3_0)
+ return OMAPDSS_VER_OMAP34xx_ES1;
+ else
+ return OMAPDSS_VER_OMAP34xx_ES3;
+ }
+ } else if (omap_rev() = OMAP4430_REV_ES1_0)
+ return OMAPDSS_VER_OMAP4430_ES1;
+ else if (omap_rev() = OMAP4430_REV_ES2_0 ||
+ omap_rev() = OMAP4430_REV_ES2_1 ||
+ omap_rev() = OMAP4430_REV_ES2_2)
+ return OMAPDSS_VER_OMAP4430_ES2;
+ else if (cpu_is_omap44xx())
+ return OMAPDSS_VER_OMAP4;
+ else if (soc_is_omap54xx())
+ return OMAPDSS_VER_OMAP5;
+ else
+ return OMAPDSS_VER_UNKNOWN
+}
+
int __init omap_display_init(struct omap_dss_board_info *board_data)
{
int r = 0;
@@ -291,9 +320,18 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
int i, oh_count;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
struct platform_device *dss_pdev;
+ enum omapdss_version ver;
/* create omapdss device */
+ ver = omap_display_get_version();
+
+ if (ver = OMAPDSS_VER_UNKNOWN) {
+ pr_err("DSS not supported on this SoC\n");
+ return -ENODEV;
+ }
+
+ board_data->version = ver;
board_data->dsi_enable_pads = omap_dsi_enable_pads;
board_data->dsi_disable_pads = omap_dsi_disable_pads;
board_data->get_context_loss_count = omap_pm_get_dev_context_loss_count;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 3729173..88c8294 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -314,6 +314,19 @@ int dsi_vc_send_bta_sync(struct omap_dss_device *dssdev, int channel);
int dsi_enable_video_output(struct omap_dss_device *dssdev, int channel);
void dsi_disable_video_output(struct omap_dss_device *dssdev, int channel);
+enum omapdss_version {
+ OMAPDSS_VER_UNKNOWN = 0,
+ OMAPDSS_VER_OMAP24xx,
+ OMAPDSS_VER_OMAP34xx_ES1, /* OMAP3430 ES1.0, 2.0 */
+ OMAPDSS_VER_OMAP34xx_ES3, /* OMAP3430 ES3.0+ */
+ OMAPDSS_VER_OMAP3630,
+ OMAPDSS_VER_AM35xx,
+ OMAPDSS_VER_OMAP4430_ES1, /* OMAP4430 ES1.0 */
+ OMAPDSS_VER_OMAP4430_ES2, /* OMAP4430 ES2.0, 2.1, 2.2 */
+ OMAPDSS_VER_OMAP4, /* All other OMAP4s */
+ OMAPDSS_VER_OMAP5,
+};
+
/* Board specific data */
struct omap_dss_board_info {
int (*get_context_loss_count)(struct device *dev);
@@ -323,6 +336,7 @@ struct omap_dss_board_info {
int (*dsi_enable_pads)(int dsi_id, unsigned lane_mask);
void (*dsi_disable_pads)(int dsi_id, unsigned lane_mask);
int (*set_min_bus_tput)(struct device *dev, unsigned long r);
+ enum omapdss_version version;
};
/* Init with the board info */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/6] OMAPDSS: remove cpu_is_* calls
From: Tomi Valkeinen @ 2012-09-28 10:35 UTC (permalink / raw)
To: linux-omap, linux-fbdev
Cc: Archit Taneja, Chandrabhanu Mahapatra, Raphaël Assénat,
Tony Lindgren, Tomi Valkeinen
Hi,
This series adds an omapdss_version enum that is passed via platform data to
omapdss driver. This version identifier is then used instead of cpu_is_*()
calls.
After these, omapdss no longer contains any plat/ or mach/ includes. omapfb,
vrfb and vram still do, though.
Tomi
Tomi Valkeinen (6):
OMAPDSS: add omapdss_version
OMAPDSS: use omapdss_version in dss_features.c
OMAPDSS: DISPC: use omapdss_version
OMAPDSS: DSS: use omapdss_version
OMAPDSS: HDMI: use omapdss_version
OMAPDSS: remove <plat/cpu.h> includes
arch/arm/mach-omap2/display.c | 38 +++++++++++++++++++
drivers/video/omap2/dss/core.c | 2 +-
drivers/video/omap2/dss/dispc.c | 41 +++++++++++++-------
drivers/video/omap2/dss/dss.c | 39 +++++++++++++------
drivers/video/omap2/dss/dss_features.c | 64 ++++++++++++++++++++++----------
drivers/video/omap2/dss/dss_features.h | 5 ++-
drivers/video/omap2/dss/hdmi.c | 3 +-
include/video/omapdss.h | 14 +++++++
8 files changed, 157 insertions(+), 49 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH V3 1/3] OMAPDSS: Move definition of DEBUG flag to Makefile
From: Chandrabhanu Mahapatra @ 2012-09-28 10:35 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <cover.1348826106.git.cmahapatra@ti.com>
In OMAPDSS the DEBUG flag is set only after the OMAPDSS module is called, for
which the debugging capabilities are available only after its proper
initialization. As a result of which tracking of bugs prior to or during initial
process becomes difficult. So, the definition of DEBUG is being moved to the
corresponding Makefile.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/Makefile | 1 +
drivers/video/omap2/dss/dss.h | 4 ----
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index 4549869..86493e3 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -8,3 +8,4 @@ omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi.o \
hdmi_panel.o ti_hdmi_4xxx_ip.o
+ccflags-$(CONFIG_OMAP2_DSS_DEBUG_SUPPORT) += -DDEBUG
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 6728892..ffbba7e 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -23,10 +23,6 @@
#ifndef __OMAP2_DSS_H
#define __OMAP2_DSS_H
-#ifdef CONFIG_OMAP2_DSS_DEBUG_SUPPORT
-#define DEBUG
-#endif
-
#ifdef DEBUG
extern bool dss_debug;
#ifdef DSS_SUBSYS_NAME
--
1.7.10
^ permalink raw reply related
* [PATCH V3 0/3] OMAPDSS: Enable dynamic debug printing
From: Chandrabhanu Mahapatra @ 2012-09-28 10:35 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In-Reply-To: <cover.1348636132.git.cmahapatra@ti.com>
Hi everyone,
this patch series aims at cleaning up of DSS of printk()'s enabled with
dss_debug and replace them with generic dynamic debug printing.
The 1st patch
* moved DEBUG flag definition to Makefile
The 2nd patch
* replaces printk() in DSSDBG definition with pr_debug()
* removes DSSDBGF definition and replaces its instances with DSSDBG()
The 3rd patch
* cleans up printk()'s in omap_dispc_unregister_isr() and
_dsi_print_reset_status() with pr_debug()
* removes dss_debug variable
Changes from V1 to V2:
* added debug messages to DSSDBG calls
* added patch "OMAPDSS: Remove dss_debug variable"
Changes from V2 to V3
* added patch "OMAPDSS: Move definition of DEBUG flag to Makefile"
All your comments and suggestions are welcome.
Refenence Tree:
git://gitorious.org/linux-omap-dss2/chandrabhanus-linux.git dss_cleanup
Regards,
Chandrabhanu
Chandrabhanu Mahapatra (3):
OMAPDSS: Move definition of DEBUG flag to Makefile
OMAPDSS: Cleanup DSSDBG with dynamic pr_debug function
OMAPDSS: Remove dss_debug variable
drivers/video/omap2/dss/Makefile | 1 +
drivers/video/omap2/dss/apply.c | 8 +++----
drivers/video/omap2/dss/core.c | 5 ----
drivers/video/omap2/dss/dispc.c | 39 +++++++++++-------------------
drivers/video/omap2/dss/dsi.c | 49 ++++++++++++++++----------------------
drivers/video/omap2/dss/dss.h | 38 +++++------------------------
6 files changed, 45 insertions(+), 95 deletions(-)
--
1.7.10
^ permalink raw reply
* Re: [PATCH V3] video: exynos_dp: Add device tree support to DP driver
From: Sylwester Nawrocki @ 2012-09-28 8:25 UTC (permalink / raw)
To: Jingoo Han
Cc: Tomasz Figa, 'Ajay Kumar', linux-samsung-soc, linux-fbdev,
FlorianSchandinat, thomas.ab, 'devicetree-discuss'
In-Reply-To: <1511551.R6uMubmq1B@flatron>
On 09/28/2012 08:48 AM, Tomasz Figa wrote:
>>>> + display-port-controller {
>>>> + compatible = "samsung,exynos5-dp";
>>>> + reg =<0x145B0000 0x10000>;
>>>> + interrupts =<10 3>;
>>>> + interrupt-parent =<&combiner>;
>>>> + dp_phy =<&dptx_phy>;
>>>
>>> Shouldn't it be "samsung,dp_phy" ?
>>
>> Do you mean this ? It is not working.
>> + dp_phy = "samsung,dp_phy";
>
> I believe he meant:
>
> -+ dp_phy =<&dptx_phy>;
> ++ samsung,dp_phy =<&dptx_phy>;
>
> to mark that this is a Samsung-specific property.
Yes, that's what I meant. Sorry for imprecise wording.
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH V3] video: exynos_dp: Add device tree support to DP driver
From: Jingoo Han @ 2012-09-28 8:09 UTC (permalink / raw)
To: 'Tomasz Figa'
Cc: 'Sylwester Nawrocki', 'Ajay Kumar',
linux-samsung-soc, linux-fbdev, FlorianSchandinat, thomas.ab,
'devicetree-discuss', 'Jingoo Han'
In-Reply-To: <1511551.R6uMubmq1B@flatron>
On Friday, September 28, 2012 3:48 PM Tomasz Figa wrote
>
> Hi,
>
> On Friday 28 of September 2012 09:11:09 Jingoo Han wrote:
> > On Thursday, September 27, 2012 10:45 PM Sylwester Nawrocki wrote
> > > > +Example:
> > > > +
> > > > +SOC specific portion:
> > > > + dptx_phy: dptx_phy@0x10040720 {
> > > > + compatible = "samsung,dp-phy";
> > > > + samsung,dptx_phy_reg =<0x10040720>;
> > > > + samsung,enable_bit =<1>;
> > > > + };
> > > > +
> > > > + display-port-controller {
> > > > + compatible = "samsung,exynos5-dp";
> > > > + reg =<0x145B0000 0x10000>;
> > > > + interrupts =<10 3>;
> > > > + interrupt-parent =<&combiner>;
> > > > + dp_phy =<&dptx_phy>;
> > >
> > > Shouldn't it be "samsung,dp_phy" ?
> >
> > Do you mean this ? It is not working.
> > + dp_phy = "samsung,dp_phy";
>
> I believe he meant:
>
> -+ dp_phy =<&dptx_phy>;
> ++ samsung,dp_phy =<&dptx_phy>;
>
> to mark that this is a Samsung-specific property.
Oh, I see.
Yes, "samsung,dp_phy =<&dptx_phy>" is right.
As you mentioned, this is a Samsung-specific property.
Thank you.
Best regards,
Jingoo Han
>
> Best regards,
> Tomasz Figa
^ permalink raw reply
* Contact Email: dhldeliveryservice21@gmail.com
From: Fabbrica del Talento @ 2012-09-28 7:52 UTC (permalink / raw)
To: linux-fbdev
This is to re-notify you of the 21,870.56 us dollar cheque that was deposited here in the DHL office in your name. You should contact Dispatch Officer Collins Gianni you are therefore advice to contact the delivery officer
Contact Email: dhldeliveryservice21@gmail.com
Contact Person: Collins Gianni
Full Name:............ Address:.............
City:........Country:.......... Phone:.........
Regards,
Eric Morrow
United Nations donation coordinator
^ permalink raw reply
* Re: [PATCH V3] video: exynos_dp: Add device tree support to DP driver
From: Tomasz Figa @ 2012-09-28 6:48 UTC (permalink / raw)
To: Jingoo Han
Cc: 'Sylwester Nawrocki', 'Ajay Kumar',
linux-samsung-soc, linux-fbdev, FlorianSchandinat, thomas.ab,
'devicetree-discuss'
In-Reply-To: <000601cd9d0d$c3296ca0$497c45e0$%han@samsung.com>
Hi,
On Friday 28 of September 2012 09:11:09 Jingoo Han wrote:
> On Thursday, September 27, 2012 10:45 PM Sylwester Nawrocki wrote
> > > +Example:
> > > +
> > > +SOC specific portion:
> > > + dptx_phy: dptx_phy@0x10040720 {
> > > + compatible = "samsung,dp-phy";
> > > + samsung,dptx_phy_reg =<0x10040720>;
> > > + samsung,enable_bit =<1>;
> > > + };
> > > +
> > > + display-port-controller {
> > > + compatible = "samsung,exynos5-dp";
> > > + reg =<0x145B0000 0x10000>;
> > > + interrupts =<10 3>;
> > > + interrupt-parent =<&combiner>;
> > > + dp_phy =<&dptx_phy>;
> >
> > Shouldn't it be "samsung,dp_phy" ?
>
> Do you mean this ? It is not working.
> + dp_phy = "samsung,dp_phy";
I believe he meant:
-+ dp_phy =<&dptx_phy>;
++ samsung,dp_phy =<&dptx_phy>;
to mark that this is a Samsung-specific property.
Best regards,
Tomasz Figa
^ permalink raw reply
* Re: [PATCH V3] video: exynos_dp: Add device tree support to DP driver
From: Jingoo Han @ 2012-09-28 0:11 UTC (permalink / raw)
To: 'Sylwester Nawrocki', 'Ajay Kumar'
Cc: linux-samsung-soc, linux-fbdev, FlorianSchandinat, thomas.ab,
'devicetree-discuss', 'Jingoo Han'
In-Reply-To: <50645848.6080102@gmail.com>
On Thursday, September 27, 2012 10:45 PM Sylwester Nawrocki wrote
>
> Hi,
>
> Cc: devicetree-discuss@lists.ozlabs.org
>
> On 09/24/2012 09:36 PM, Ajay Kumar wrote:
> > This patch enables device tree based discovery support for DP driver.
> > The driver is modified to handle platform data in both the cases:
> > with DT and non-DT.
> > Documentation is also added for the DT bindings.
> >
> > DP-PHY should be regarded as a seperate device node while
> > being passed from device tree list, and device node for
> > DP should contain DP-PHY as child node with property name "dp-phy"
> > associated with it.
> >
> > Signed-off-by: Ajay Kumar<ajaykumar.rs@samsung.com>
> > ---
> > .../devicetree/bindings/video/exynos_dp.txt | 83 ++++++++++
> > drivers/video/exynos/exynos_dp_core.c | 168 ++++++++++++++++++--
> > drivers/video/exynos/exynos_dp_core.h | 2 +
> > 3 files changed, 239 insertions(+), 14 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
> b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > new file mode 100644
> > index 0000000..c27f892
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > @@ -0,0 +1,83 @@
> > +Exynos Displayport driver should configure the displayport interface
>
> Don't we need a whitespace between 'display' and 'port' ?
Either 'display port' or 'DisplayPort' is commonly used.
For clarity, display port would be better.
>
> > +based on the type of panel connected to it.
> > +
> > +We use two nodes:
> > + -dptx_phy node
> > + -display-port-controller node
> > +
> > +For the dp-phy initialization, we use a dptx_phy node.
> > +Required properties for dptx_phy:
> > + -compatible:
> > + Should be "samsung,dp-phy".
> > + -samsung,dptx_phy_reg:
> > + Base address of DP PHY register.
>
> Couldn't just 'reg' be used for this one ?
>
> > + -samsung,enable_bit:
> > + The bit used to enable/disable DP PHY.
>
> Is this the bit mask or the bit index ? In the code it's used as
> a bitmask. But from description it is not clear whether it is
> an index or a mask. Is it different across various SoCs ?
>
> Perhaps it's better to name it samsung,enable_mask (in case some
> SoC need more than one bit) ?
It's the bit mask.
It is different across various SoCs.
OK, enable_mask would be better.
>
> > +
> > +For the Panel initialization, we read data from display-port-controller node.
> > +Required properties for display-port-controller:
> > + -compatible:
> > + Should be "samsung,exynos5-dp".
> > + -reg:
> > + physical base address of the controller and length
> > + of memory mapped region.
> > + -interrupts:
> > + Internet combiner values.
>
> what? :)
Ajay: Please, fix it.
>
> > + -interrupt-parent:
> > + Address of Interrupt combiner node.
> > + -dp_phy:
> > + Address of dptx_phy node.
>
> "A phandle to dptx_phy node" ?
Yes, you're right.
Ajay: Please, replace 'Address of dptx_phy node'
with 'phandle of dptx_phy node'.
>
> > + -samsung,color_space:
> > + input video data format.
> > + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
>
> Can this be changed at run time ?
No, it is not changeable.
It's a default setting according to eDP panel.
>
> > + -samsung,dynamic_range:
> > + dynamic range for input video data.
> > + VESA = 0, CEA = 1
>
> Why is it in the device tree ? Shouldn't it be configurable at runtime ?
> My apologies if this an obvious question, I don't have much experience
> with DP.
Same above.
>
> > + -samsung,ycbcr_coeff:
> > + YCbCr co-efficients for input video.
> > + COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
> > + -samsung,color_depth:
> > + Bit per color component.
>
> "Number of bits per colour component" ? Also same remark as above.
Same above.
>
> > + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
> > + -samsung,link_rate:
> > + link rates supportd by the panel.
>
> typo: supportd -> supported
Ajay: Please fix it.
>
> > + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
>
> Is this really a property of a panel ? Why it is in the PHY node ?
> Also I can see this is just a single property, so "link rates" is a bit
> misleading.
>
Yes, It's a property of LCD panel.
It is not in the 'PHY' node, but 'display-port-controller' node.
Ajay: Please replace 'link rates' with 'link rate'.
> > + -samsung,lane_count:
> > + number of lanes supported by the panel.
> > + LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
>
> What do these symbolic names are needed for ? Is lane_count a number or a
> mask, is this really a _maximum_ number of lanes ? What are the valid values,
> 1, 2 and 4 ? Or maybe 0x3 is also valid which would indicate that we can
> use 1 or 2 data lanes ?
>
These symbolic names are defined in './include/video/exynos_dp.h'.
It seems that Ajay used these definitions.
'lane_count' is a number of used lanes of main link which transfer data
streams as video. The number of lanes of Main Link is 1, 2, or 4 lanes.
It is dependent on eDP panel.
> > + -samsung,interlaced:
> > + Interlace scan mode.
> > + Progressive if defined, Interlaced if not defined
>
> Why do we need this in the device tree ? Is this really a default scan mode ?
> Can it be the changed at runtime ?
No, it is not changeable.
It's a default setting according to eDP panel.
>
> > + -samsung,v_sync_polarity:
> > + VSYNC polarity configuration.
> > + High if defined, Low if not defined
> > + -samsung,h_sync_polarity:
> > + HSYNC polarity configuration.
> > + High if defined, Low if not defined
> > +
> > +Example:
> > +
> > +SOC specific portion:
> > + dptx_phy: dptx_phy@0x10040720 {
> > + compatible = "samsung,dp-phy";
> > + samsung,dptx_phy_reg =<0x10040720>;
> > + samsung,enable_bit =<1>;
> > + };
> > +
> > + display-port-controller {
> > + compatible = "samsung,exynos5-dp";
> > + reg =<0x145B0000 0x10000>;
> > + interrupts =<10 3>;
> > + interrupt-parent =<&combiner>;
> > + dp_phy =<&dptx_phy>;
>
> Shouldn't it be "samsung,dp_phy" ?
Do you mean this ? It is not working.
+ dp_phy = "samsung,dp_phy";
>
> > + };
> > +
> > +Board Specific portion:
> > + display-port-controller {
> > + samsung,color_space =<0>;
> > + samsung,dynamic_range =<0>;
> > + samsung,ycbcr_coeff =<0>;
> > + samsung,color_depth =<1>;
> > + samsung,link_rate =<0x0a>;
> > + samsung,lane_count =<2>;
> > + };
>
> --
>
> Regards,
> Sylwester
^ permalink raw reply
* Re: [PATCH V3] video: exynos_dp: Add device tree support to DP driver
From: Sylwester Nawrocki @ 2012-09-27 13:44 UTC (permalink / raw)
To: Ajay Kumar
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
FlorianSchandinat-Mmb7MZpHnFY, devicetree-discuss,
jg1.han-Sze3O3UU22JBDgjK7y7TUQ, thomas.ab-Sze3O3UU22JBDgjK7y7TUQ
In-Reply-To: <1348515385-22332-1-git-send-email-ajaykumar.rs-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hi,
Cc: devicetree-discuss@lists.ozlabs.org
On 09/24/2012 09:36 PM, Ajay Kumar wrote:
> This patch enables device tree based discovery support for DP driver.
> The driver is modified to handle platform data in both the cases:
> with DT and non-DT.
> Documentation is also added for the DT bindings.
>
> DP-PHY should be regarded as a seperate device node while
> being passed from device tree list, and device node for
> DP should contain DP-PHY as child node with property name "dp-phy"
> associated with it.
>
> Signed-off-by: Ajay Kumar<ajaykumar.rs@samsung.com>
> ---
> .../devicetree/bindings/video/exynos_dp.txt | 83 ++++++++++
> drivers/video/exynos/exynos_dp_core.c | 168 ++++++++++++++++++--
> drivers/video/exynos/exynos_dp_core.h | 2 +
> 3 files changed, 239 insertions(+), 14 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
> new file mode 100644
> index 0000000..c27f892
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -0,0 +1,83 @@
> +Exynos Displayport driver should configure the displayport interface
Don't we need a whitespace between 'display' and 'port' ?
> +based on the type of panel connected to it.
> +
> +We use two nodes:
> + -dptx_phy node
> + -display-port-controller node
> +
> +For the dp-phy initialization, we use a dptx_phy node.
> +Required properties for dptx_phy:
> + -compatible:
> + Should be "samsung,dp-phy".
> + -samsung,dptx_phy_reg:
> + Base address of DP PHY register.
Couldn't just 'reg' be used for this one ?
> + -samsung,enable_bit:
> + The bit used to enable/disable DP PHY.
Is this the bit mask or the bit index ? In the code it's used as
a bitmask. But from description it is not clear whether it is
an index or a mask. Is it different across various SoCs ?
Perhaps it's better to name it samsung,enable_mask (in case some
SoC need more than one bit) ?
> +
> +For the Panel initialization, we read data from display-port-controller node.
> +Required properties for display-port-controller:
> + -compatible:
> + Should be "samsung,exynos5-dp".
> + -reg:
> + physical base address of the controller and length
> + of memory mapped region.
> + -interrupts:
> + Internet combiner values.
what? :)
> + -interrupt-parent:
> + Address of Interrupt combiner node.
> + -dp_phy:
> + Address of dptx_phy node.
"A phandle to dptx_phy node" ?
> + -samsung,color_space:
> + input video data format.
> + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
Can this be changed at run time ?
> + -samsung,dynamic_range:
> + dynamic range for input video data.
> + VESA = 0, CEA = 1
Why is it in the device tree ? Shouldn't it be configurable at runtime ?
My apologies if this an obvious question, I don't have much experience
with DP.
> + -samsung,ycbcr_coeff:
> + YCbCr co-efficients for input video.
> + COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
> + -samsung,color_depth:
> + Bit per color component.
"Number of bits per colour component" ? Also same remark as above.
> + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
> + -samsung,link_rate:
> + link rates supportd by the panel.
typo: supportd -> supported
> + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
Is this really a property of a panel ? Why it is in the PHY node ?
Also I can see this is just a single property, so "link rates" is a bit
misleading.
> + -samsung,lane_count:
> + number of lanes supported by the panel.
> + LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
What do these symbolic names are needed for ? Is lane_count a number or a
mask, is this really a _maximum_ number of lanes ? What are the valid values,
1, 2 and 4 ? Or maybe 0x3 is also valid which would indicate that we can
use 1 or 2 data lanes ?
> + -samsung,interlaced:
> + Interlace scan mode.
> + Progressive if defined, Interlaced if not defined
Why do we need this in the device tree ? Is this really a default scan mode ?
Can it be the changed at runtime ?
> + -samsung,v_sync_polarity:
> + VSYNC polarity configuration.
> + High if defined, Low if not defined
> + -samsung,h_sync_polarity:
> + HSYNC polarity configuration.
> + High if defined, Low if not defined
> +
> +Example:
> +
> +SOC specific portion:
> + dptx_phy: dptx_phy@0x10040720 {
> + compatible = "samsung,dp-phy";
> + samsung,dptx_phy_reg =<0x10040720>;
> + samsung,enable_bit =<1>;
> + };
> +
> + display-port-controller {
> + compatible = "samsung,exynos5-dp";
> + reg =<0x145B0000 0x10000>;
> + interrupts =<10 3>;
> + interrupt-parent =<&combiner>;
> + dp_phy =<&dptx_phy>;
Shouldn't it be "samsung,dp_phy" ?
> + };
> +
> +Board Specific portion:
> + display-port-controller {
> + samsung,color_space =<0>;
> + samsung,dynamic_range =<0>;
> + samsung,ycbcr_coeff =<0>;
> + samsung,color_depth =<1>;
> + samsung,link_rate =<0x0a>;
> + samsung,lane_count =<2>;
> + };
--
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH V2 0/2] OMAPDSS: Enable dynamic debug printing
From: Tomi Valkeinen @ 2012-09-27 11:01 UTC (permalink / raw)
To: Mahapatra, Chandrabhanu; +Cc: linux-omap, linux-fbdev
In-Reply-To: <CAF0AtAvT-NnsREJWpRtYAGpYCS06O32tzQwWTDoFp+xepHyX8w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]
On Thu, 2012-09-27 at 16:20 +0530, Mahapatra, Chandrabhanu wrote:
> On Wed, Sep 26, 2012 at 7:59 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> > This doesn't work quite correctly. The problem is in dss.h, where we
> > define DEBUG if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. The thing is,
> > DEBUG should be defined before including the kernel headers where the
> > pr_debug etc are defined.
> >
> > So if you try the patches without dynamic debugging enabled, you won't
> > get any debug outputs at all, even if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is
> > set.
> >
> > And for dynamic debug, the Kconfig help says:
> >
> > If a source file is compiled with DEBUG flag set, any
> > pr_debug() calls in it are enabled by default, but can be
> > disabled at runtime as below. Note that DEBUG flag is
> > turned on by many CONFIG_*DEBUG* options.
> >
> > So if we have CONFIG_OMAP2_DSS_DEBUG_SUPPORT set, all the pr_debugs
> > should be enabled by default, which is not the case, again because DEBUG
> > is defined too late.
> >
> > I think setting DEBUG in dss.h should be removed, and instead DEBUG
> > should be set in the makefile if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set.
> >
> > Tomi
> >
>
> Well the documentation lags in describing about the DEBUG flag. I
> should have checked DYNAMIC_DEBUG in Kconfig and pr_debug definition
> in printk.h file.
>
> #if defined(CONFIG_DYNAMIC_DEBUG)
> /* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
> #define pr_debug(fmt, ...) \
> dynamic_pr_debug(fmt, ##__VA_ARGS__)
> #elif defined(DEBUG)
> #define pr_debug(fmt, ...) \
> printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> #else
> #define pr_debug(fmt, ...) \
> no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
> #endif
>
> As per the definition above pr_debug is dynamic with
> CONFIG_DYNAMIC_DEBUG set or else with DEBUG set it is just a normal
> kernel debug printk as you have mentioned.
> I still don't get how even if DEBUG is set before DSSDBG() is defined
> in dss.c pr_debug() fails to enable.
Because printk.h is included without DEBUG, thus pr_debug is defined as
no_printk.
> Well anyways, how to do the same in the Makefile? I tried adding
> ccflags-$(CONFIG_OMAP2_DSS_DEBUG_SUPPORT) += -DEBUG
> to makefile in dss directory but of no use.
-D option for the compiler is used to set defines. So it should be
-DDEBUG
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V2 0/2] OMAPDSS: Enable dynamic debug printing
From: Mahapatra, Chandrabhanu @ 2012-09-27 10:50 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1348669792.2376.51.camel@deskari>
On Wed, Sep 26, 2012 at 7:59 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> This doesn't work quite correctly. The problem is in dss.h, where we
> define DEBUG if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. The thing is,
> DEBUG should be defined before including the kernel headers where the
> pr_debug etc are defined.
>
> So if you try the patches without dynamic debugging enabled, you won't
> get any debug outputs at all, even if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is
> set.
>
> And for dynamic debug, the Kconfig help says:
>
> If a source file is compiled with DEBUG flag set, any
> pr_debug() calls in it are enabled by default, but can be
> disabled at runtime as below. Note that DEBUG flag is
> turned on by many CONFIG_*DEBUG* options.
>
> So if we have CONFIG_OMAP2_DSS_DEBUG_SUPPORT set, all the pr_debugs
> should be enabled by default, which is not the case, again because DEBUG
> is defined too late.
>
> I think setting DEBUG in dss.h should be removed, and instead DEBUG
> should be set in the makefile if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set.
>
> Tomi
>
Well the documentation lags in describing about the DEBUG flag. I
should have checked DYNAMIC_DEBUG in Kconfig and pr_debug definition
in printk.h file.
#if defined(CONFIG_DYNAMIC_DEBUG)
/* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
#define pr_debug(fmt, ...) \
dynamic_pr_debug(fmt, ##__VA_ARGS__)
#elif defined(DEBUG)
#define pr_debug(fmt, ...) \
printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#else
#define pr_debug(fmt, ...) \
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#endif
As per the definition above pr_debug is dynamic with
CONFIG_DYNAMIC_DEBUG set or else with DEBUG set it is just a normal
kernel debug printk as you have mentioned.
I still don't get how even if DEBUG is set before DSSDBG() is defined
in dss.c pr_debug() fails to enable.
Well anyways, how to do the same in the Makefile? I tried adding
ccflags-$(CONFIG_OMAP2_DSS_DEBUG_SUPPORT) += -DEBUG
to makefile in dss directory but of no use.
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.
^ permalink raw reply
* [PATCH] video: s3c-fb: use FIMD_V8_VIDTCON0 for EXYNOS5 FIMD
From: Jingoo Han @ 2012-09-27 10:42 UTC (permalink / raw)
To: linux-fbdev
This patch uses FIMD_V8_VIDTCON0 as the address definition
of VIDTCON0 register, because the address offset of VIDTCONx
registers is changed from 0x0 to 0x20000 for EXYNOS5 FIMD.
So, FIMD_V8_VIDTCON0 should be used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 52b744f..8e1555d 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1910,7 +1910,7 @@ static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
static struct s3c_fb_driverdata s3c_fb_data_exynos5 = {
.variant = {
.nr_windows = 5,
- .vidtcon = VIDTCON0,
+ .vidtcon = FIMD_V8_VIDTCON0,
.wincon = WINCON(0),
.winmap = WINxMAP(0),
.keycon = WKEYCON,
--
1.7.1
^ permalink raw reply related
* [PATCH] video: s3c-fb: fix help message for FB_S3C_DEBUG_REGWRITE
From: Jingoo Han @ 2012-09-27 10:41 UTC (permalink / raw)
To: linux-fbdev
The help message of config FB_S3C_DEBUG_REGWRITE is fixed,
because printk(KERN_DEBUG) was replaced with pr_debug().
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ab621f8..d823064 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2057,7 +2057,7 @@ config FB_S3C_DEBUG_REGWRITE
bool "Debug register writes"
depends on FB_S3C
---help---
- Show all register writes via printk(KERN_DEBUG)
+ Show all register writes via pr_debug()
config FB_S3C2410
tristate "S3C2410 LCD framebuffer support"
--
1.7.1
^ permalink raw reply related
* [PATCH] video: s3c-fb: fix typo in comment
From: Jingoo Han @ 2012-09-27 10:40 UTC (permalink / raw)
To: linux-fbdev
"sturucture" should be "structure".
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/s3c-fb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 52b744f..b855867 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -189,7 +189,7 @@ struct s3c_fb_vsync {
/**
* struct s3c_fb - overall hardware state of the hardware
- * @slock: The spinlock protection for this data sturucture.
+ * @slock: The spinlock protection for this data structure.
* @dev: The device that we bound to, for printing, etc.
* @bus_clk: The clk (hclk) feeding our interface and possibly pixclk.
* @lcd_clk: The clk (sclk) feeding pixclk.
--
1.7.1
^ permalink raw reply related
* [PATCH 7/7] video: s3c-fb: add the bit definitions for VIDCON0_VIDOUT_WB
From: Jingoo Han @ 2012-09-27 8:48 UTC (permalink / raw)
To: linux-fbdev
This patch adds the bit definitions for VIDCON0_VIDOUT_WB.
These definitions are used to support writeback for RGB and
i80 interface. Also, output format of writeback is YUV444.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index 634b18b..e755448 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -24,12 +24,15 @@
#define VIDCON0 (0x00)
#define VIDCON0_INTERLACE (1 << 29)
-#define VIDCON0_VIDOUT_MASK (0x3 << 26)
+#define VIDCON0_VIDOUT_MASK (0x7 << 26)
#define VIDCON0_VIDOUT_SHIFT (26)
#define VIDCON0_VIDOUT_RGB (0x0 << 26)
#define VIDCON0_VIDOUT_TV (0x1 << 26)
#define VIDCON0_VIDOUT_I80_LDI0 (0x2 << 26)
#define VIDCON0_VIDOUT_I80_LDI1 (0x3 << 26)
+#define VIDCON0_VIDOUT_WB_RGB (0x4 << 26)
+#define VIDCON0_VIDOUT_WB_I80_LDI0 (0x6 << 26)
+#define VIDCON0_VIDOUT_WB_I80_LDI1 (0x7 << 26)
#define VIDCON0_L1_DATA_MASK (0x7 << 23)
#define VIDCON0_L1_DATA_SHIFT (23)
--
1.7.1
^ permalink raw reply related
* [PATCH 6/7] video: s3c-fb: move the bit definitions for DITHMODE register
From: Jingoo Han @ 2012-09-27 8:47 UTC (permalink / raw)
To: linux-fbdev
The bit definitions for DITHMODE registers are moved according to
address order. Also, the bit definition of VIDCON1_FSTATUS_EVEN
is moved.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 42 ++++++++++++++++++++----------------------
1 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index d5fe38b..634b18b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -77,6 +77,7 @@
#define VIDCON1_LINECNT_MASK (0x7ff << 16)
#define VIDCON1_LINECNT_SHIFT (16)
#define VIDCON1_LINECNT_GET(_v) (((_v) >> 16) & 0x7ff)
+#define VIDCON1_FSTATUS_EVEN (1 << 15)
#define VIDCON1_VSTATUS_MASK (0x3 << 13)
#define VIDCON1_VSTATUS_SHIFT (13)
#define VIDCON1_VSTATUS_VSYNC (0x0 << 13)
@@ -376,6 +377,25 @@
#define WxKEYCON1_COLVAL_LIMIT (0xffffff)
#define WxKEYCON1_COLVAL(_x) ((_x) << 0)
+/* Dithering control */
+#define DITHMODE (0x170)
+#define DITHMODE_R_POS_MASK (0x3 << 5)
+#define DITHMODE_R_POS_SHIFT (5)
+#define DITHMODE_R_POS_8BIT (0x0 << 5)
+#define DITHMODE_R_POS_6BIT (0x1 << 5)
+#define DITHMODE_R_POS_5BIT (0x2 << 5)
+#define DITHMODE_G_POS_MASK (0x3 << 3)
+#define DITHMODE_G_POS_SHIFT (3)
+#define DITHMODE_G_POS_8BIT (0x0 << 3)
+#define DITHMODE_G_POS_6BIT (0x1 << 3)
+#define DITHMODE_G_POS_5BIT (0x2 << 3)
+#define DITHMODE_B_POS_MASK (0x3 << 1)
+#define DITHMODE_B_POS_SHIFT (1)
+#define DITHMODE_B_POS_8BIT (0x0 << 1)
+#define DITHMODE_B_POS_6BIT (0x1 << 1)
+#define DITHMODE_B_POS_5BIT (0x2 << 1)
+#define DITHMODE_DITH_EN (1 << 0)
+
/* Window blanking (MAP) */
#define WINxMAP(_win) (0x180 + ((_win) * 4))
#define WINxMAP_MAP (1 << 24)
@@ -416,28 +436,6 @@
#define BLENDCON_NEW_4BIT_ALPHA_VALUE (0 << 0)
#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */
-#define VIDCON1_FSTATUS_EVEN (1 << 15)
-
-#define DITHMODE (0x170)
-#define DITHMODE_R_POS_MASK (0x3 << 5)
-#define DITHMODE_R_POS_SHIFT (5)
-#define DITHMODE_R_POS_8BIT (0x0 << 5)
-#define DITHMODE_R_POS_6BIT (0x1 << 5)
-#define DITHMODE_R_POS_5BIT (0x2 << 5)
-
-#define DITHMODE_G_POS_MASK (0x3 << 3)
-#define DITHMODE_G_POS_SHIFT (3)
-#define DITHMODE_G_POS_8BIT (0x0 << 3)
-#define DITHMODE_G_POS_6BIT (0x1 << 3)
-#define DITHMODE_G_POS_5BIT (0x2 << 3)
-
-#define DITHMODE_B_POS_MASK (0x3 << 1)
-#define DITHMODE_B_POS_SHIFT (1)
-#define DITHMODE_B_POS_8BIT (0x0 << 1)
-#define DITHMODE_B_POS_6BIT (0x1 << 1)
-#define DITHMODE_B_POS_5BIT (0x2 << 1)
-
-#define DITHMODE_DITH_EN (1 << 0)
/* Notes on per-window bpp settings
*
--
1.7.1
^ permalink raw reply related
* [PATCH 5/7] video: s3c-fb: move the bit definitions for WINxMAP and WPALCON register
From: Jingoo Han @ 2012-09-27 8:47 UTC (permalink / raw)
To: linux-fbdev
The bit definitions for WINxMAP and WPALCON register are moved to
right place.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 22 ++++++----------------
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index 7c9a9bc..d5fe38b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -376,16 +376,20 @@
#define WxKEYCON1_COLVAL_LIMIT (0xffffff)
#define WxKEYCON1_COLVAL(_x) ((_x) << 0)
-
/* Window blanking (MAP) */
-
+#define WINxMAP(_win) (0x180 + ((_win) * 4))
#define WINxMAP_MAP (1 << 24)
#define WINxMAP_MAP_COLOUR_MASK (0xffffff << 0)
#define WINxMAP_MAP_COLOUR_SHIFT (0)
#define WINxMAP_MAP_COLOUR_LIMIT (0xffffff)
#define WINxMAP_MAP_COLOUR(_x) ((_x) << 0)
+/* Winodw palette control */
+#define WPALCON (0x1A0)
#define WPALCON_PAL_UPDATE (1 << 9)
+#define WPALCON_W4PAL_16BPP_A555 (1 << 8)
+#define WPALCON_W3PAL_16BPP_A555 (1 << 7)
+#define WPALCON_W2PAL_16BPP_A555 (1 << 6)
#define WPALCON_W1PAL_MASK (0x7 << 3)
#define WPALCON_W1PAL_SHIFT (3)
#define WPALCON_W1PAL_25BPP_A888 (0x0 << 3)
@@ -395,7 +399,6 @@
#define WPALCON_W1PAL_18BPP (0x4 << 3)
#define WPALCON_W1PAL_16BPP_A555 (0x5 << 3)
#define WPALCON_W1PAL_16BPP_565 (0x6 << 3)
-
#define WPALCON_W0PAL_MASK (0x7 << 0)
#define WPALCON_W0PAL_SHIFT (0)
#define WPALCON_W0PAL_25BPP_A888 (0x0 << 0)
@@ -416,9 +419,6 @@
#define VIDCON1_FSTATUS_EVEN (1 << 15)
#define DITHMODE (0x170)
-#define WINxMAP(_win) (0x180 + ((_win) * 4))
-
-
#define DITHMODE_R_POS_MASK (0x3 << 5)
#define DITHMODE_R_POS_SHIFT (5)
#define DITHMODE_R_POS_8BIT (0x0 << 5)
@@ -439,16 +439,6 @@
#define DITHMODE_DITH_EN (1 << 0)
-#define WPALCON (0x1A0)
-
-/* Palette control */
-/* Note for S5PC100: you can still use those macros on WPALCON (aka WPALCON_L),
- * but make sure that WPALCON_H W2PAL-W4PAL entries are zeroed out */
-#define WPALCON_W4PAL_16BPP_A555 (1 << 8)
-#define WPALCON_W3PAL_16BPP_A555 (1 << 7)
-#define WPALCON_W2PAL_16BPP_A555 (1 << 6)
-
-
/* Notes on per-window bpp settings
*
* Value Win0 Win1 Win2 Win3 Win 4
--
1.7.1
^ permalink raw reply related
* [PATCH 4/7] video: s3c-fb: move the bit definitions for VIDINTCON0 register
From: Jingoo Han @ 2012-09-27 8:46 UTC (permalink / raw)
To: linux-fbdev
The bit definitions for VIDINTCON0 registers are moved to right
place.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index c398728..7c9a9bc 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -308,6 +308,7 @@
/* Interrupt controls and status */
+#define VIDINTCON0 (0x130)
#define VIDINTCON0_FIFOINTERVAL_MASK (0x3f << 20)
#define VIDINTCON0_FIFOINTERVAL_SHIFT (20)
#define VIDINTCON0_FIFOINTERVAL_LIMIT (0x3f)
@@ -336,6 +337,9 @@
#define VIDINTCON0_FIFIOSEL_SHIFT (5)
#define VIDINTCON0_FIFIOSEL_WINDOW0 (0x1 << 5)
#define VIDINTCON0_FIFIOSEL_WINDOW1 (0x2 << 5)
+#define VIDINTCON0_FIFIOSEL_WINDOW2 (0x10 << 5)
+#define VIDINTCON0_FIFIOSEL_WINDOW3 (0x20 << 5)
+#define VIDINTCON0_FIFIOSEL_WINDOW4 (0x40 << 5)
#define VIDINTCON0_FIFOLEVEL_MASK (0x7 << 2)
#define VIDINTCON0_FIFOLEVEL_SHIFT (2)
@@ -411,12 +415,6 @@
#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */
#define VIDCON1_FSTATUS_EVEN (1 << 15)
-#define VIDINTCON0 (0x130)
-
-#define VIDINTCON0_FIFIOSEL_WINDOW2 (0x10 << 5)
-#define VIDINTCON0_FIFIOSEL_WINDOW3 (0x20 << 5)
-#define VIDINTCON0_FIFIOSEL_WINDOW4 (0x40 << 5)
-
#define DITHMODE (0x170)
#define WINxMAP(_win) (0x180 + ((_win) * 4))
--
1.7.1
^ permalink raw reply related
* [PATCH 3/7] video: s3c-fb: move the address definition for VIDOSD register
From: Jingoo Han @ 2012-09-27 8:43 UTC (permalink / raw)
To: linux-fbdev
The address definition for VIDTCON VIDOSD is moved to right
place.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index bc22f3c..c398728 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -237,6 +237,9 @@
/* Local input channels (windows 0-2) */
#define SHADOWCON_CHx_LOCAL_ENABLE(_win) (1 << (5 + (_win)))
+/* VIDOSDx */
+
+#define VIDOSD_BASE (0x40)
#define VIDOSDxA_TOPLEFT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDOSDxA_TOPLEFT_X_MASK (0x7ff << 11)
#define VIDOSDxA_TOPLEFT_X_SHIFT (11)
@@ -408,10 +411,6 @@
#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */
#define VIDCON1_FSTATUS_EVEN (1 << 15)
-/* OSD1 and OSD4 do not have register D */
-
-#define VIDOSD_BASE (0x40)
-
#define VIDINTCON0 (0x130)
#define VIDINTCON0_FIFIOSEL_WINDOW2 (0x10 << 5)
--
1.7.1
^ permalink raw reply related
* [PATCH 2/7] video: s3c-fb: move the address definitions for VIDTCON registers
From: Jingoo Han @ 2012-09-27 8:07 UTC (permalink / raw)
To: linux-fbdev
The address definitions for VIDTCON registers are moved to right
place.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index bd0a04e..bc22f3c 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -116,6 +116,7 @@
/* VIDTCON0 */
+#define VIDTCON0 (0x10)
#define VIDTCON0_VBPDE_MASK (0xff << 24)
#define VIDTCON0_VBPDE_SHIFT (24)
#define VIDTCON0_VBPDE_LIMIT (0xff)
@@ -138,6 +139,7 @@
/* VIDTCON1 */
+#define VIDTCON1 (0x14)
#define VIDTCON1_VFPDE_MASK (0xff << 24)
#define VIDTCON1_VFPDE_SHIFT (24)
#define VIDTCON1_VFPDE_LIMIT (0xff)
@@ -159,6 +161,7 @@
#define VIDTCON1_HSPW(_x) ((_x) << 0)
#define VIDTCON2 (0x18)
+#define VIDTCON2 (0x18)
#define VIDTCON2_LINEVAL_E(_x) ((((_x) & 0x800) >> 11) << 23)
#define VIDTCON2_LINEVAL_MASK (0x7ff << 11)
#define VIDTCON2_LINEVAL_SHIFT (11)
@@ -405,11 +408,6 @@
#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */
#define VIDCON1_FSTATUS_EVEN (1 << 15)
-/* Video timing controls */
-#define VIDTCON0 (0x10)
-#define VIDTCON1 (0x14)
-#define VIDTCON2 (0x18)
-
/* OSD1 and OSD4 do not have register D */
#define VIDOSD_BASE (0x40)
--
1.7.1
^ permalink raw reply related
* [PATCH 1/7] video: s3c-fb: clean the bit definition for WINCON register
From: Jingoo Han @ 2012-09-27 8:06 UTC (permalink / raw)
To: linux-fbdev
This patch cleans the bit definition for WINCON register.
The bit definition for WINCON1 and WINCON2 is removed, because
it is not used.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
include/video/samsung_fimd.h | 76 +++++++----------------------------------
1 files changed, 13 insertions(+), 63 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index 7ae6c07..bd0a04e 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -173,18 +173,27 @@
/* WINCONx */
-
+#define WINCON(_win) (0x20 + ((_win) * 4))
+#define WINCONx_CSCWIDTH_MASK (0x3 << 26)
+#define WINCONx_CSCWIDTH_SHIFT (26)
+#define WINCONx_CSCWIDTH_WIDE (0x0 << 26)
+#define WINCONx_CSCWIDTH_NARROW (0x3 << 26)
+#define WINCONx_ENLOCAL (1 << 22)
+#define WINCONx_BUFSTATUS (1 << 21)
+#define WINCONx_BUFSEL (1 << 20)
+#define WINCONx_BUFAUTOEN (1 << 19)
#define WINCONx_BITSWP (1 << 18)
#define WINCONx_BYTSWP (1 << 17)
#define WINCONx_HAWSWP (1 << 16)
#define WINCONx_WSWP (1 << 15)
+#define WINCONx_YCbCr (1 << 13)
#define WINCONx_BURSTLEN_MASK (0x3 << 9)
#define WINCONx_BURSTLEN_SHIFT (9)
#define WINCONx_BURSTLEN_16WORD (0x0 << 9)
#define WINCONx_BURSTLEN_8WORD (0x1 << 9)
#define WINCONx_BURSTLEN_4WORD (0x2 << 9)
-
#define WINCONx_ENWIN (1 << 0)
+
#define WINCON0_BPPMODE_MASK (0xf << 2)
#define WINCON0_BPPMODE_SHIFT (2)
#define WINCON0_BPPMODE_1BPP (0x0 << 2)
@@ -196,9 +205,8 @@
#define WINCON0_BPPMODE_18BPP_666 (0x8 << 2)
#define WINCON0_BPPMODE_24BPP_888 (0xb << 2)
+#define WINCON1_LOCALSEL_CAMIF (1 << 23)
#define WINCON1_BLD_PIX (1 << 6)
-
-#define WINCON1_ALPHA_SEL (1 << 1)
#define WINCON1_BPPMODE_MASK (0xf << 2)
#define WINCON1_BPPMODE_SHIFT (2)
#define WINCON1_BPPMODE_1BPP (0x0 << 2)
@@ -216,6 +224,7 @@
#define WINCON1_BPPMODE_24BPP_A1887 (0xc << 2)
#define WINCON1_BPPMODE_25BPP_A1888 (0xd << 2)
#define WINCON1_BPPMODE_28BPP_A4888 (0xd << 2)
+#define WINCON1_ALPHA_SEL (1 << 1)
/* S5PV210 */
#define SHADOWCON (0x34)
@@ -401,71 +410,12 @@
#define VIDTCON1 (0x14)
#define VIDTCON2 (0x18)
-/* Window position controls */
-
-#define WINCON(_win) (0x20 + ((_win) * 4))
-
/* OSD1 and OSD4 do not have register D */
#define VIDOSD_BASE (0x40)
#define VIDINTCON0 (0x130)
-/* WINCONx */
-
-#define WINCONx_CSCWIDTH_MASK (0x3 << 26)
-#define WINCONx_CSCWIDTH_SHIFT (26)
-#define WINCONx_CSCWIDTH_WIDE (0x0 << 26)
-#define WINCONx_CSCWIDTH_NARROW (0x3 << 26)
-
-#define WINCONx_ENLOCAL (1 << 22)
-#define WINCONx_BUFSTATUS (1 << 21)
-#define WINCONx_BUFSEL (1 << 20)
-#define WINCONx_BUFAUTOEN (1 << 19)
-#define WINCONx_YCbCr (1 << 13)
-
-#define WINCON1_LOCALSEL_CAMIF (1 << 23)
-
-#define WINCON2_LOCALSEL_CAMIF (1 << 23)
-#define WINCON2_BLD_PIX (1 << 6)
-
-#define WINCON2_ALPHA_SEL (1 << 1)
-#define WINCON2_BPPMODE_MASK (0xf << 2)
-#define WINCON2_BPPMODE_SHIFT (2)
-#define WINCON2_BPPMODE_1BPP (0x0 << 2)
-#define WINCON2_BPPMODE_2BPP (0x1 << 2)
-#define WINCON2_BPPMODE_4BPP (0x2 << 2)
-#define WINCON2_BPPMODE_8BPP_1232 (0x4 << 2)
-#define WINCON2_BPPMODE_16BPP_565 (0x5 << 2)
-#define WINCON2_BPPMODE_16BPP_A1555 (0x6 << 2)
-#define WINCON2_BPPMODE_16BPP_I1555 (0x7 << 2)
-#define WINCON2_BPPMODE_18BPP_666 (0x8 << 2)
-#define WINCON2_BPPMODE_18BPP_A1665 (0x9 << 2)
-#define WINCON2_BPPMODE_19BPP_A1666 (0xa << 2)
-#define WINCON2_BPPMODE_24BPP_888 (0xb << 2)
-#define WINCON2_BPPMODE_24BPP_A1887 (0xc << 2)
-#define WINCON2_BPPMODE_25BPP_A1888 (0xd << 2)
-#define WINCON2_BPPMODE_28BPP_A4888 (0xd << 2)
-
-#define WINCON3_BLD_PIX (1 << 6)
-
-#define WINCON3_ALPHA_SEL (1 << 1)
-#define WINCON3_BPPMODE_MASK (0xf << 2)
-#define WINCON3_BPPMODE_SHIFT (2)
-#define WINCON3_BPPMODE_1BPP (0x0 << 2)
-#define WINCON3_BPPMODE_2BPP (0x1 << 2)
-#define WINCON3_BPPMODE_4BPP (0x2 << 2)
-#define WINCON3_BPPMODE_16BPP_565 (0x5 << 2)
-#define WINCON3_BPPMODE_16BPP_A1555 (0x6 << 2)
-#define WINCON3_BPPMODE_16BPP_I1555 (0x7 << 2)
-#define WINCON3_BPPMODE_18BPP_666 (0x8 << 2)
-#define WINCON3_BPPMODE_18BPP_A1665 (0x9 << 2)
-#define WINCON3_BPPMODE_19BPP_A1666 (0xa << 2)
-#define WINCON3_BPPMODE_24BPP_888 (0xb << 2)
-#define WINCON3_BPPMODE_24BPP_A1887 (0xc << 2)
-#define WINCON3_BPPMODE_25BPP_A1888 (0xd << 2)
-#define WINCON3_BPPMODE_28BPP_A4888 (0xd << 2)
-
#define VIDINTCON0_FIFIOSEL_WINDOW2 (0x10 << 5)
#define VIDINTCON0_FIFIOSEL_WINDOW3 (0x20 << 5)
#define VIDINTCON0_FIFIOSEL_WINDOW4 (0x40 << 5)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH V3] video: exynos_dp: Add device tree support to DP driver
From: Jingoo Han @ 2012-09-27 7:58 UTC (permalink / raw)
To: 'Ajay Kumar', linux-fbdev
Cc: linux-samsung-soc, FlorianSchandinat, thomas.ab,
'Jingoo Han'
In-Reply-To: <1348515385-22332-1-git-send-email-ajaykumar.rs@samsung.com>
On Tuesday, September 25, 2012 4:36 AM Ajay Kumar wrote
>
> This patch enables device tree based discovery support for DP driver.
> The driver is modified to handle platform data in both the cases:
> with DT and non-DT.
> Documentation is also added for the DT bindings.
>
> DP-PHY should be regarded as a seperate device node while
> being passed from device tree list, and device node for
> DP should contain DP-PHY as child node with property name "dp-phy"
> associated with it.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> .../devicetree/bindings/video/exynos_dp.txt | 83 ++++++++++
> drivers/video/exynos/exynos_dp_core.c | 168 ++++++++++++++++++--
> drivers/video/exynos/exynos_dp_core.h | 2 +
> 3 files changed, 239 insertions(+), 14 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
> b/Documentation/devicetree/bindings/video/exynos_dp.txt
> new file mode 100644
> index 0000000..c27f892
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -0,0 +1,83 @@
> +Exynos Displayport driver should configure the displayport interface
> +based on the type of panel connected to it.
> +
> +We use two nodes:
> + -dptx_phy node
> + -display-port-controller node
> +
> +For the dp-phy initialization, we use a dptx_phy node.
> +Required properties for dptx_phy:
> + -compatible:
> + Should be "samsung,dp-phy".
> + -samsung,dptx_phy_reg:
> + Base address of DP PHY register.
> + -samsung,enable_bit:
> + The bit used to enable/disable DP PHY.
> +
> +For the Panel initialization, we read data from display-port-controller node.
> +Required properties for display-port-controller:
> + -compatible:
> + Should be "samsung,exynos5-dp".
> + -reg:
> + physical base address of the controller and length
> + of memory mapped region.
> + -interrupts:
> + Internet combiner values.
> + -interrupt-parent:
> + Address of Interrupt combiner node.
> + -dp_phy:
> + Address of dptx_phy node.
> + -samsung,color_space:
> + input video data format.
> + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
> + -samsung,dynamic_range:
> + dynamic range for input video data.
> + VESA = 0, CEA = 1
> + -samsung,ycbcr_coeff:
> + YCbCr co-efficients for input video.
> + COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
> + -samsung,color_depth:
> + Bit per color component.
> + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
> + -samsung,link_rate:
> + link rates supportd by the panel.
> + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
> + -samsung,lane_count:
> + number of lanes supported by the panel.
> + LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
> + -samsung,interlaced:
> + Interlace scan mode.
> + Progressive if defined, Interlaced if not defined
> + -samsung,v_sync_polarity:
> + VSYNC polarity configuration.
> + High if defined, Low if not defined
> + -samsung,h_sync_polarity:
> + HSYNC polarity configuration.
> + High if defined, Low if not defined
> +
> +Example:
> +
> +SOC specific portion:
> + dptx_phy: dptx_phy@0x10040720 {
> + compatible = "samsung,dp-phy";
> + samsung,dptx_phy_reg = <0x10040720>;
> + samsung,enable_bit = <1>;
> + };
> +
> + display-port-controller {
> + compatible = "samsung,exynos5-dp";
> + reg = <0x145B0000 0x10000>;
> + interrupts = <10 3>;
> + interrupt-parent = <&combiner>;
> + dp_phy = <&dptx_phy>;
> + };
> +
> +Board Specific portion:
> + display-port-controller {
> + samsung,color_space = <0>;
> + samsung,dynamic_range = <0>;
> + samsung,ycbcr_coeff = <0>;
> + samsung,color_depth = <1>;
> + samsung,link_rate = <0x0a>;
> + samsung,lane_count = <2>;
> + };
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index cdc1398..bb0f10c 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -18,6 +18,7 @@
> #include <linux/io.h>
> #include <linux/interrupt.h>
> #include <linux/delay.h>
> +#include <linux/of.h>
>
> #include <video/exynos_dp.h>
>
> @@ -856,6 +857,106 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void *arg)
> return IRQ_HANDLED;
> }
>
> +#ifdef CONFIG_OF
> +struct exynos_dp_platdata *exynos_dp_dt_parse_pdata(struct device *dev)
> +{
> + struct device_node *dp_node = dev->of_node;
> + struct exynos_dp_platdata *pd;
> + struct video_info *dp_video_config;
> +
> + pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
> + if (!pd) {
> + dev_err(dev, "memory allocation for pdata failed\n");
> + return ERR_PTR(-ENOMEM);
> + }
> + dp_video_config = devm_kzalloc(dev,
> + sizeof(*dp_video_config), GFP_KERNEL);
> +
> + if (!dp_video_config) {
> + dev_err(dev, "memory allocation for video config failed\n");
> + return ERR_PTR(-ENOMEM);
> + }
> + pd->video_info = dp_video_config;
> +
> + if (of_get_property(dp_node, "samsung,h-sync-polarity", NULL))
> + dp_video_config->h_sync_polarity = 1;
> +
> + if (of_get_property(dp_node, "samsung,v-sync-polarity", NULL))
> + dp_video_config->v_sync_polarity = 1;
> +
> + if (of_get_property(dp_node, "samsung,interlaced", NULL))
> + dp_video_config->interlaced = 1;
> +
> + of_property_read_u32(dp_node, "samsung,color_space",
> + &dp_video_config->color_space);
> +
> + of_property_read_u32(dp_node, "samsung,dynamic_range",
> + &dp_video_config->dynamic_range);
> +
> + of_property_read_u32(dp_node, "samsung,ycbcr_coeff",
> + &dp_video_config->ycbcr_coeff);
> +
> + of_property_read_u32(dp_node, "samsung,color_depth",
> + &dp_video_config->color_depth);
> +
> + of_property_read_u32(dp_node, "samsung,link_rate",
> + &dp_video_config->link_rate);
> +
> + of_property_read_u32(dp_node, "samsung,lane_count",
> + &dp_video_config->lane_count);
> + return pd;
> +}
> +
> +void exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> +{
> + struct device_node *dp_phy_node;
> + const __be32 *parp;
> + u32 phy_base;
> + void *virt_phy_base;
> +
> + parp = of_get_property(dp->dev->of_node, "dp_phy", NULL);
> + if (!parp) {
> + dp->dp_phy_addr = NULL;
> + return;
> + }
> +
> + dp_phy_node = of_find_node_by_phandle(be32_to_cpup(parp));
> + if (!dp_phy_node) {
> + dp->dp_phy_addr = NULL;
> + return;
> + }
> +
> + of_property_read_u32(dp_phy_node, "samsung,dptx_phy_reg", &phy_base);
> + of_property_read_u32(dp_phy_node, "samsung,enable_bit",
> + &dp->enable_bit);
> + virt_phy_base = ioremap(phy_base, SZ_4);
> + if (!virt_phy_base) {
> + dev_err(dp->dev, "failed to ioremap dp-phy\n");
> + dp->dp_phy_addr = NULL;
> + return;
> + }
> + dp->dp_phy_addr = virt_phy_base;
> +}
> +
> +void exynos_dp_phy_init(struct exynos_dp_device *dp)
> +{
> + u32 reg;
> +
> + reg = __raw_readl(dp->dp_phy_addr);
> + reg |= dp->enable_bit;
> + __raw_writel(reg, dp->dp_phy_addr);
> +}
> +
> +void exynos_dp_phy_exit(struct exynos_dp_device *dp)
> +{
> + u32 reg;
> +
> + reg = __raw_readl(dp->dp_phy_addr);
> + reg &= ~(dp->enable_bit);
> + __raw_writel(reg, dp->dp_phy_addr);
> +}
> +#endif /* CONFIG_OF */
> +
> static int __devinit exynos_dp_probe(struct platform_device *pdev)
> {
> struct resource *res;
> @@ -864,12 +965,6 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
>
> int ret = 0;
>
> - pdata = pdev->dev.platform_data;
> - if (!pdata) {
> - dev_err(&pdev->dev, "no platform data\n");
> - return -EINVAL;
> - }
> -
> dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
> GFP_KERNEL);
> if (!dp) {
> @@ -879,6 +974,21 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
>
> dp->dev = &pdev->dev;
>
> + if (pdev->dev.of_node) {
> + pdata = exynos_dp_dt_parse_pdata(&pdev->dev);
> + if (IS_ERR(pdata))
> + return PTR_ERR(pdata);
> +
> + exynos_dp_dt_parse_phydata(dp);
> + } else {
> + pdata = pdev->dev.platform_data;
> + }
> +
> + if (!pdata) {
> + dev_err(&pdev->dev, "no platform data\n");
> + return -EINVAL;
> + }
> +
> dp->clock = devm_clk_get(&pdev->dev, "dp");
> if (IS_ERR(dp->clock)) {
> dev_err(&pdev->dev, "failed to get clock\n");
> @@ -909,8 +1019,14 @@ static int __devinit exynos_dp_probe(struct platform_device *pdev)
> }
>
> dp->video_info = pdata->video_info;
> - if (pdata->phy_init)
> - pdata->phy_init();
> +
> + if (pdev->dev.of_node) {
> + if (dp->dp_phy_addr)
> + exynos_dp_phy_init(dp);
> + } else {
> + if (pdata->phy_init)
> + pdata->phy_init();
> + }
>
> exynos_dp_init_dp(dp);
>
> @@ -953,8 +1069,13 @@ static int __devexit exynos_dp_remove(struct platform_device *pdev)
> struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
> struct exynos_dp_device *dp = platform_get_drvdata(pdev);
>
> - if (pdata && pdata->phy_exit)
> - pdata->phy_exit();
> + if (pdev->dev.of_node) {
> + if (dp->dp_phy_addr)
> + exynos_dp_phy_exit(dp);
> + } else {
> + if (pdata && pdata->phy_exit)
> + pdata->phy_exit();
> + }
>
> clk_disable(dp->clock);
>
> @@ -968,8 +1089,13 @@ static int exynos_dp_suspend(struct device *dev)
> struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
> struct exynos_dp_device *dp = platform_get_drvdata(pdev);
>
> - if (pdata && pdata->phy_exit)
> - pdata->phy_exit();
> + if (dev->of_node) {
> + if (dp->dp_phy_addr)
> + exynos_dp_phy_exit(dp);
> + } else {
> + if (pdata && pdata->phy_exit)
> + pdata->phy_exit();
> + }
>
> clk_disable(dp->clock);
>
> @@ -982,8 +1108,13 @@ static int exynos_dp_resume(struct device *dev)
> struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
> struct exynos_dp_device *dp = platform_get_drvdata(pdev);
>
> - if (pdata && pdata->phy_init)
> - pdata->phy_init();
> + if (dev->of_node) {
> + if (dp->dp_phy_addr)
> + exynos_dp_phy_init(dp);
> + } else {
> + if (pdata && pdata->phy_init)
> + pdata->phy_init();
> + }
>
> clk_enable(dp->clock);
>
> @@ -1013,6 +1144,14 @@ static const struct dev_pm_ops exynos_dp_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(exynos_dp_suspend, exynos_dp_resume)
> };
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id exynos_dp_match[] = {
> + { .compatible = "samsung,exynos5-dp" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_dp_match);
> +#endif
> +
> static struct platform_driver exynos_dp_driver = {
> .probe = exynos_dp_probe,
> .remove = __devexit_p(exynos_dp_remove),
> @@ -1020,6 +1159,7 @@ static struct platform_driver exynos_dp_driver = {
> .name = "exynos-dp",
> .owner = THIS_MODULE,
> .pm = &exynos_dp_pm_ops,
> + .of_match_table = of_match_ptr(exynos_dp_match),
> },
> };
>
> diff --git a/drivers/video/exynos/exynos_dp_core.h b/drivers/video/exynos/exynos_dp_core.h
> index 57b8a65..c9f8c97 100644
> --- a/drivers/video/exynos/exynos_dp_core.h
> +++ b/drivers/video/exynos/exynos_dp_core.h
> @@ -29,6 +29,8 @@ struct exynos_dp_device {
> struct clk *clock;
> unsigned int irq;
> void __iomem *reg_base;
> + void __iomem *dp_phy_addr;
> + unsigned int enable_bit;
>
> struct video_info *video_info;
> struct link_train link_train;
> --
> 1.7.0.4
^ permalink raw reply
* Re: [PATCH 14/34] dma: ipu: rename mach/ipu.h to include/linux/dma/ipu-dma.h
From: Mauro Carvalho Chehab @ 2012-09-27 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1209171124130.1689@axis700.grange>
Em 17-09-2012 06:26, Guennadi Liakhovetski escreveu:
> On Mon, 17 Sep 2012, Shawn Guo wrote:
>
>> The header ipu.h really belongs to dma subsystem rather than imx
>> platform. Rename it to ipu-dma.h and put it into include/linux/dma/.
>>
>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>> Cc: Vinod Koul <vinod.koul@intel.com>
>> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
>> Cc: linux-media@vger.kernel.org
>> Cc: linux-fbdev@vger.kernel.org
>
> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>
> Thanks
> Guennadi
>
>> ---
>> drivers/dma/ipu/ipu_idmac.c | 3 +--
>> drivers/dma/ipu/ipu_irq.c | 3 +--
>> drivers/media/video/mx3_camera.c | 2 +-
>> drivers/video/mx3fb.c | 2 +-
>> .../mach/ipu.h => include/linux/dma/ipu-dma.h | 6 +++---
>> 5 files changed, 7 insertions(+), 9 deletions(-)
>> rename arch/arm/mach-imx/include/mach/ipu.h => include/linux/dma/ipu-dma.h (97%)
>>
>> diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
>> index c7573e5..6585537 100644
>> --- a/drivers/dma/ipu/ipu_idmac.c
>> +++ b/drivers/dma/ipu/ipu_idmac.c
>> @@ -22,8 +22,7 @@
>> #include <linux/interrupt.h>
>> #include <linux/io.h>
>> #include <linux/module.h>
>> -
>> -#include <mach/ipu.h>
>> +#include <linux/dma/ipu-dma.h>
>>
>> #include "../dmaengine.h"
>> #include "ipu_intern.h"
>> diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
>> index fa95bcc..a5ee37d 100644
>> --- a/drivers/dma/ipu/ipu_irq.c
>> +++ b/drivers/dma/ipu/ipu_irq.c
>> @@ -15,8 +15,7 @@
>> #include <linux/irq.h>
>> #include <linux/io.h>
>> #include <linux/module.h>
>> -
>> -#include <mach/ipu.h>
>> +#include <linux/dma/ipu-dma.h>
>>
>> #include "ipu_intern.h"
>>
>> diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
>> index 1481b0d..892cba5 100644
>> --- a/drivers/media/video/mx3_camera.c
>> +++ b/drivers/media/video/mx3_camera.c
>> @@ -17,6 +17,7 @@
>> #include <linux/vmalloc.h>
>> #include <linux/interrupt.h>
>> #include <linux/sched.h>
>> +#include <linux/dma/ipu-dma.h>
>>
>> #include <media/v4l2-common.h>
>> #include <media/v4l2-dev.h>
>> @@ -24,7 +25,6 @@
>> #include <media/soc_camera.h>
>> #include <media/soc_mediabus.h>
>>
>> -#include <mach/ipu.h>
>> #include <linux/platform_data/camera-mx3.h>
>> #include <linux/platform_data/dma-imx.h>
>>
>> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
>> index d738108..3b63ad8 100644
>> --- a/drivers/video/mx3fb.c
>> +++ b/drivers/video/mx3fb.c
>> @@ -26,10 +26,10 @@
>> #include <linux/console.h>
>> #include <linux/clk.h>
>> #include <linux/mutex.h>
>> +#include <linux/dma/ipu-dma.h>
>>
>> #include <linux/platform_data/dma-imx.h>
>> #include <mach/hardware.h>
>> -#include <mach/ipu.h>
>> #include <linux/platform_data/video-mx3fb.h>
>>
>> #include <asm/io.h>
>> diff --git a/arch/arm/mach-imx/include/mach/ipu.h b/include/linux/dma/ipu-dma.h
>> similarity index 97%
>> rename from arch/arm/mach-imx/include/mach/ipu.h
>> rename to include/linux/dma/ipu-dma.h
>> index 539e559..1803111 100644
>> --- a/arch/arm/mach-imx/include/mach/ipu.h
>> +++ b/include/linux/dma/ipu-dma.h
>> @@ -9,8 +9,8 @@
>> * published by the Free Software Foundation.
>> */
>>
>> -#ifndef _IPU_H_
>> -#define _IPU_H_
>> +#ifndef __LINUX_DMA_IPU_DMA_H
>> +#define __LINUX_DMA_IPU_DMA_H
>>
>> #include <linux/types.h>
>> #include <linux/dmaengine.h>
>> @@ -174,4 +174,4 @@ struct idmac_channel {
>> #define to_tx_desc(tx) container_of(tx, struct idmac_tx_desc, txd)
>> #define to_idmac_chan(c) container_of(c, struct idmac_channel, dma_chan)
>>
>> -#endif
>> +#endif /* __LINUX_DMA_IPU_DMA_H */
>> --
>> 1.7.9.5
>>
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH V2 0/2] OMAPDSS: Enable dynamic debug printing
From: Tomi Valkeinen @ 2012-09-26 14:29 UTC (permalink / raw)
To: Chandrabhanu Mahapatra; +Cc: linux-omap, linux-fbdev
In-Reply-To: <cover.1348636132.git.cmahapatra@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]
Hi,
On Wed, 2012-09-26 at 10:45 +0530, Chandrabhanu Mahapatra wrote:
> Hi everyone,
> this patch series aims at cleaning up of DSS of printk()'s enabled with
> dss_debug and replace them with generic dynamic debug printing.
>
> The 1st patch
> * replaces printk() in DSSDBG definition with pr_debug()
> * removes DSSDBGF definition and replaces its instances with DSSDBG()
> The 2nd patch
> * cleans up printk()'s in omap_dispc_unregister_isr() and
> _dsi_print_reset_status() with pr_debug()
> * removes dss_debug variable
>
> Changes with respect to V1:
> * added debug messages to DSSDBG calls replacing DSSDBGF
> * added patch "OMAPDSS: Remove dss_debug variable"
>
> All your comments and suggestions are welcome.
This doesn't work quite correctly. The problem is in dss.h, where we
define DEBUG if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. The thing is,
DEBUG should be defined before including the kernel headers where the
pr_debug etc are defined.
So if you try the patches without dynamic debugging enabled, you won't
get any debug outputs at all, even if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is
set.
And for dynamic debug, the Kconfig help says:
If a source file is compiled with DEBUG flag set, any
pr_debug() calls in it are enabled by default, but can be
disabled at runtime as below. Note that DEBUG flag is
turned on by many CONFIG_*DEBUG* options.
So if we have CONFIG_OMAP2_DSS_DEBUG_SUPPORT set, all the pr_debugs
should be enabled by default, which is not the case, again because DEBUG
is defined too late.
I think setting DEBUG in dss.h should be removed, and instead DEBUG
should be set in the makefile if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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