* [PATCH 2/4] viafb: fill xres and yres
From: Florian Tobias Schandinat @ 2012-02-14 5:51 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329194838.git.FlorianSchandinat@gmx.de>
This patch fills xres and yres in var which is required when a
temporary var is genereated when viafb_SAMM_ON is set and
viafb_dual_fb is not set. It also removes an obsolete comment.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 08c1036..399d507 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -2125,7 +2125,6 @@ void viafb_set_dpa_gfx(int output_interface, struct GFX_DPA_SETTING\
}
}
-/*According var's xres, yres fill var's other timing information*/
void viafb_fill_var_timing_info(struct fb_var_screeninfo *var,
struct crt_mode_table *mode)
{
@@ -2134,6 +2133,8 @@ void viafb_fill_var_timing_info(struct fb_var_screeninfo *var,
crt_reg = mode->crtc;
var->pixclock = 1000000000 / (crt_reg.hor_total * crt_reg.ver_total)
* 1000 / mode->refresh_rate;
+ var->xres = crt_reg.hor_addr;
+ var->yres = crt_reg.ver_addr;
var->left_margin crt_reg.hor_total - (crt_reg.hor_sync_start + crt_reg.hor_sync_end);
var->right_margin = crt_reg.hor_sync_start - crt_reg.hor_addr;
--
1.7.9
^ permalink raw reply related
* [PATCH 3/4] viafb: make single framebuffer multiple adapter mode work
From: Florian Tobias Schandinat @ 2012-02-14 5:52 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329194838.git.FlorianSchandinat@gmx.de>
This patch implementes this mode (viafb_SAMM_ON set and
viafb_dual_fb not set) in a useful way for CRT and DVI devices.
The same content is shown on both devices in different video modes.
The first (primary) resolution must not be bigger than the secondary
one and determines the visible region. The same content is shown
centered on the secondary output.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/dvi.c | 5 +++--
drivers/video/via/dvi.h | 3 ++-
drivers/video/via/hw.c | 41 +++++++++++++++++++++++------------------
drivers/video/via/hw.h | 3 ++-
4 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/drivers/video/via/dvi.c b/drivers/video/via/dvi.c
index 9138e51..3312c81 100644
--- a/drivers/video/via/dvi.c
+++ b/drivers/video/via/dvi.c
@@ -172,7 +172,8 @@ static int tmds_register_read_bytes(int index, u8 *buff, int buff_len)
}
/* DVI Set Mode */
-void viafb_dvi_set_mode(const struct fb_var_screeninfo *var, int iga)
+void viafb_dvi_set_mode(const struct fb_var_screeninfo *var,
+ u16 cxres, u16 cyres, int iga)
{
struct fb_var_screeninfo dvi_var = *var;
struct crt_mode_table *rb_mode;
@@ -185,7 +186,7 @@ void viafb_dvi_set_mode(const struct fb_var_screeninfo *var, int iga)
viafb_fill_var_timing_info(&dvi_var, rb_mode);
}
- viafb_fill_crtc_timing(&dvi_var, iga);
+ viafb_fill_crtc_timing(&dvi_var, cxres, cyres, iga);
}
/* Sense DVI Connector */
diff --git a/drivers/video/via/dvi.h b/drivers/video/via/dvi.h
index e2116aa..db75785 100644
--- a/drivers/video/via/dvi.h
+++ b/drivers/video/via/dvi.h
@@ -59,6 +59,7 @@ void viafb_dvi_enable(void);
bool __devinit viafb_tmds_trasmitter_identify(void);
void __devinit viafb_init_dvi_size(struct tmds_chip_information *tmds_chip,
struct tmds_setting_information *tmds_setting);
-void viafb_dvi_set_mode(const struct fb_var_screeninfo *var, int iga);
+void viafb_dvi_set_mode(const struct fb_var_screeninfo *var,
+ u16 cxres, u16 cyres, int iga);
#endif /* __DVI_H__ */
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 399d507..e8725c5 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,28 +1467,31 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-static struct display_timing var_to_timing(const struct fb_var_screeninfo *var)
+static struct display_timing var_to_timing(const struct fb_var_screeninfo *var, u16 cxres, u16 cyres)
{
struct display_timing timing;
+ u16 dx = (var->xres - cxres) / 2, dy = (var->yres - cyres) / 2;
- timing.hor_addr = var->xres;
- timing.hor_sync_start = timing.hor_addr + var->right_margin;
+ timing.hor_addr = cxres;
+ timing.hor_sync_start = timing.hor_addr + var->right_margin + dx;
timing.hor_sync_end = timing.hor_sync_start + var->hsync_len;
- timing.hor_total = timing.hor_sync_end + var->left_margin;
- timing.hor_blank_start = timing.hor_addr;
- timing.hor_blank_end = timing.hor_total;
- timing.ver_addr = var->yres;
- timing.ver_sync_start = timing.ver_addr + var->lower_margin;
+ timing.hor_total = timing.hor_sync_end + var->left_margin + dx;
+ timing.hor_blank_start = timing.hor_addr + dx;
+ timing.hor_blank_end = timing.hor_total - dy;
+ timing.ver_addr = cyres;
+ timing.ver_sync_start = timing.ver_addr + var->lower_margin + dy;
timing.ver_sync_end = timing.ver_sync_start + var->vsync_len;
- timing.ver_total = timing.ver_sync_end + var->upper_margin;
- timing.ver_blank_start = timing.ver_addr;
- timing.ver_blank_end = timing.ver_total;
+ timing.ver_total = timing.ver_sync_end + var->upper_margin + dy;
+ timing.ver_blank_start = timing.ver_addr + dy;
+ timing.ver_blank_end = timing.ver_total - dy;
return timing;
}
-void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var, int iga)
+void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
+ u16 cxres, u16 cyres, int iga)
{
- struct display_timing crt_reg = var_to_timing(var);
+ struct display_timing crt_reg = var_to_timing(var,
+ cxres ? cxres : var->xres, cyres ? cyres : var->yres);
if (iga = IGA1)
via_set_primary_timing(&crt_reg);
@@ -1842,7 +1845,7 @@ static void hw_init(void)
int viafb_setmode(int video_bpp, int video_bpp1)
{
- int j;
+ int j, cxres = 0, cyres = 0;
int port;
u32 devices = viaparinfo->shared->iga1_devices
| viaparinfo->shared->iga2_devices;
@@ -1891,6 +1894,8 @@ int viafb_setmode(int video_bpp, int video_bpp1)
} else if (viafb_SAMM_ON) {
viafb_fill_var_timing_info(&var2, viafb_get_best_mode(
viafb_second_xres, viafb_second_yres, viafb_refresh1));
+ cxres = viafbinfo->var.xres;
+ cyres = viafbinfo->var.yres;
var2.bits_per_pixel = viafbinfo->var.bits_per_pixel;
}
@@ -1898,9 +1903,9 @@ int viafb_setmode(int video_bpp, int video_bpp1)
if (viafb_CRT_ON) {
if (viaparinfo->shared->iga2_devices & VIA_CRT
&& viafb_SAMM_ON)
- viafb_fill_crtc_timing(&var2, IGA2);
+ viafb_fill_crtc_timing(&var2, cxres, cyres, IGA2);
else
- viafb_fill_crtc_timing(&viafbinfo->var,
+ viafb_fill_crtc_timing(&viafbinfo->var, 0, 0,
(viaparinfo->shared->iga1_devices & VIA_CRT)
? IGA1 : IGA2);
@@ -1918,9 +1923,9 @@ int viafb_setmode(int video_bpp, int video_bpp1)
if (viafb_DVI_ON) {
if (viaparinfo->shared->tmds_setting_info.iga_path = IGA2
&& viafb_SAMM_ON)
- viafb_dvi_set_mode(&var2, IGA2);
+ viafb_dvi_set_mode(&var2, cxres, cyres, IGA2);
else
- viafb_dvi_set_mode(&viafbinfo->var,
+ viafb_dvi_set_mode(&viafbinfo->var, 0, 0,
viaparinfo->tmds_setting_info->iga_path);
}
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 4db5b6e..f8129e4 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,8 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
-void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var, int iga);
+void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
+ u16 cxres, u16 cyres, int iga);
void viafb_set_vclock(u32 CLK, int set_iga);
void viafb_load_reg(int timing_value, int viafb_load_reg_num,
struct io_register *reg,
--
1.7.9
^ permalink raw reply related
* [PATCH 4/4] viafb: make SAMM to also work on LCD
From: Florian Tobias Schandinat @ 2012-02-14 5:52 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329194838.git.FlorianSchandinat@gmx.de>
This patch enables LCD to handle SAMM without dual fb.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/chip.h | 2 --
drivers/video/via/hw.c | 27 +++++++++++----------------
drivers/video/via/lcd.c | 18 +++++++++---------
drivers/video/via/lcd.h | 3 ++-
4 files changed, 22 insertions(+), 28 deletions(-)
diff --git a/drivers/video/via/chip.h b/drivers/video/via/chip.h
index 3ebf20c..c2ecdb5 100644
--- a/drivers/video/via/chip.h
+++ b/drivers/video/via/chip.h
@@ -146,8 +146,6 @@ struct tmds_setting_information {
struct lvds_setting_information {
int iga_path;
- int h_active;
- int v_active;
int bpp;
int lcd_panel_hres;
int lcd_panel_vres;
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index e8725c5..d35ced7 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1530,11 +1530,7 @@ void viafb_update_device_setting(int hres, int vres, int bpp, int flag)
viaparinfo->tmds_setting_info->h_active = hres;
viaparinfo->tmds_setting_info->v_active = vres;
- viaparinfo->lvds_setting_info->h_active = hres;
- viaparinfo->lvds_setting_info->v_active = vres;
viaparinfo->lvds_setting_info->bpp = bpp;
- viaparinfo->lvds_setting_info2->h_active = hres;
- viaparinfo->lvds_setting_info2->v_active = vres;
viaparinfo->lvds_setting_info2->bpp = bpp;
} else {
@@ -1543,16 +1539,11 @@ void viafb_update_device_setting(int hres, int vres, int bpp, int flag)
viaparinfo->tmds_setting_info->v_active = vres;
}
- if (viaparinfo->lvds_setting_info->iga_path = IGA2) {
- viaparinfo->lvds_setting_info->h_active = hres;
- viaparinfo->lvds_setting_info->v_active = vres;
+ if (viaparinfo->lvds_setting_info->iga_path = IGA2)
viaparinfo->lvds_setting_info->bpp = bpp;
- }
- if (IGA2 = viaparinfo->lvds_setting_info2->iga_path) {
- viaparinfo->lvds_setting_info2->h_active = hres;
- viaparinfo->lvds_setting_info2->v_active = vres;
+
+ if (IGA2 = viaparinfo->lvds_setting_info2->iga_path)
viaparinfo->lvds_setting_info2->bpp = bpp;
- }
}
}
@@ -1933,7 +1924,8 @@ int viafb_setmode(int video_bpp, int video_bpp1)
if (viafb_SAMM_ON &&
(viaparinfo->lvds_setting_info->iga_path = IGA2)) {
viaparinfo->lvds_setting_info->bpp = video_bpp1;
- viafb_lcd_set_mode(viaparinfo->lvds_setting_info,
+ viafb_lcd_set_mode(&var2, cxres, cyres,
+ viaparinfo->lvds_setting_info,
&viaparinfo->chip_info->lvds_chip_info);
} else {
/* IGA1 doesn't have LCD scaling, so set it center. */
@@ -1942,7 +1934,8 @@ int viafb_setmode(int video_bpp, int video_bpp1)
LCD_CENTERING;
}
viaparinfo->lvds_setting_info->bpp = video_bpp;
- viafb_lcd_set_mode(viaparinfo->lvds_setting_info,
+ viafb_lcd_set_mode(&viafbinfo->var, 0, 0,
+ viaparinfo->lvds_setting_info,
&viaparinfo->chip_info->lvds_chip_info);
}
}
@@ -1950,7 +1943,8 @@ int viafb_setmode(int video_bpp, int video_bpp1)
if (viafb_SAMM_ON &&
(viaparinfo->lvds_setting_info2->iga_path = IGA2)) {
viaparinfo->lvds_setting_info2->bpp = video_bpp1;
- viafb_lcd_set_mode(viaparinfo->lvds_setting_info2,
+ viafb_lcd_set_mode(&var2, cxres, cyres,
+ viaparinfo->lvds_setting_info2,
&viaparinfo->chip_info->lvds_chip_info2);
} else {
/* IGA1 doesn't have LCD scaling, so set it center. */
@@ -1959,7 +1953,8 @@ int viafb_setmode(int video_bpp, int video_bpp1)
LCD_CENTERING;
}
viaparinfo->lvds_setting_info2->bpp = video_bpp;
- viafb_lcd_set_mode(viaparinfo->lvds_setting_info2,
+ viafb_lcd_set_mode(&viafbinfo->var, 0, 0,
+ viaparinfo->lvds_setting_info2,
&viaparinfo->chip_info->lvds_chip_info2);
}
}
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 5f3b4e3..02cfdc8 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -55,8 +55,7 @@ static void load_lcd_scaling(int set_hres, int set_vres, int panel_hres,
int panel_vres);
static void via_pitch_alignment_patch_lcd(
struct lvds_setting_information *plvds_setting_info,
- struct lvds_chip_information
- *plvds_chip_info);
+ struct lvds_chip_information *plvds_chip_info, int hres);
static void lcd_patch_skew_dvp0(struct lvds_setting_information
*plvds_setting_info,
struct lvds_chip_information *plvds_chip_info);
@@ -456,14 +455,13 @@ static void load_lcd_scaling(int set_hres, int set_vres, int panel_hres,
static void via_pitch_alignment_patch_lcd(
struct lvds_setting_information *plvds_setting_info,
- struct lvds_chip_information
- *plvds_chip_info)
+ struct lvds_chip_information *plvds_chip_info, int hres)
{
unsigned char cr13, cr35, cr65, cr66, cr67;
unsigned long dwScreenPitch = 0;
unsigned long dwPitch;
- dwPitch = plvds_setting_info->h_active * (plvds_setting_info->bpp >> 3);
+ dwPitch = hres * (plvds_setting_info->bpp >> 3);
if (dwPitch & 0x1F) {
dwScreenPitch = ((dwPitch + 31) & ~31) >> 3;
if (plvds_setting_info->iga_path = IGA2) {
@@ -548,13 +546,14 @@ static void lcd_patch_skew(struct lvds_setting_information
}
/* LCD Set Mode */
-void viafb_lcd_set_mode(struct lvds_setting_information *plvds_setting_info,
+void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres,
+ u16 cyres, struct lvds_setting_information *plvds_setting_info,
struct lvds_chip_information *plvds_chip_info)
{
int set_iga = plvds_setting_info->iga_path;
int mode_bpp = plvds_setting_info->bpp;
- int set_hres = plvds_setting_info->h_active;
- int set_vres = plvds_setting_info->v_active;
+ int set_hres = cxres ? cxres : var->xres;
+ int set_vres = cyres ? cyres : var->yres;
int panel_hres = plvds_setting_info->lcd_panel_hres;
int panel_vres = plvds_setting_info->lcd_panel_vres;
u32 clock;
@@ -613,7 +612,8 @@ void viafb_lcd_set_mode(struct lvds_setting_information *plvds_setting_info,
viafb_write_reg_mask(CR6A, VIACR, 0x01, BIT0);
/* Patch for non 32bit alignment mode */
- via_pitch_alignment_patch_lcd(plvds_setting_info, plvds_chip_info);
+ via_pitch_alignment_patch_lcd(plvds_setting_info, plvds_chip_info,
+ set_hres);
}
static void integrated_lvds_disable(struct lvds_setting_information
diff --git a/drivers/video/via/lcd.h b/drivers/video/via/lcd.h
index 77ca7b8..8f3e4e0 100644
--- a/drivers/video/via/lcd.h
+++ b/drivers/video/via/lcd.h
@@ -76,7 +76,8 @@ void __devinit viafb_init_lvds_output_interface(struct lvds_chip_information
*plvds_chip_info,
struct lvds_setting_information
*plvds_setting_info);
-void viafb_lcd_set_mode(struct lvds_setting_information *plvds_setting_info,
+void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres,
+ u16 cyres, struct lvds_setting_information *plvds_setting_info,
struct lvds_chip_information *plvds_chip_info);
bool __devinit viafb_lvds_trasmitter_identify(void);
void viafb_init_lvds_output_interface(struct lvds_chip_information
--
1.7.9
^ permalink raw reply related
* [PATCH 0/3] viafb auxiliary device support
From: Florian Tobias Schandinat @ 2012-02-14 6:35 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
Hi all,
this patch series aims to add infrastructure to viafb to support
devices that are connected via I2C. Even before these patches viafb
had support for some of these but no structure, instead ranging from
a single file for a device to various places in the code writing to
such devices, probably even sometimes without knowing that it is
talking to the correct device.
This patch series adds just the infrastructure to add such devices
and a few stub driver which print the name of the chips, if detected.
Even this is quite useful for debugging or recruiting testers. The
long term goal is to move all existing support for such devices in
those drivers and extend them to whatever is required.
The chip detection aside the only user visible change is that if no
viafb_mode/viafb_mode1 is given on startup the initial resolution
is derived from EDID data, if present for the desired configuration.
Best regards,
Florian Tobias Schandinat
Florian Tobias Schandinat (3):
viafb: add auxiliary device management infrastructure
viafb: fix I2C emulation on GPIO ports
viafb: add initial EDID support
drivers/video/via/Makefile | 5 ++-
drivers/video/via/via_aux.c | 88 ++++++++++++++++++++++++++++++++
drivers/video/via/via_aux.h | 93 ++++++++++++++++++++++++++++++++++
drivers/video/via/via_aux_ch7301.c | 50 ++++++++++++++++++
drivers/video/via/via_aux_edid.c | 97 ++++++++++++++++++++++++++++++++++++
drivers/video/via/via_aux_sii164.c | 54 ++++++++++++++++++++
drivers/video/via/via_aux_vt1621.c | 44 ++++++++++++++++
drivers/video/via/via_aux_vt1622.c | 50 ++++++++++++++++++
drivers/video/via/via_aux_vt1625.c | 50 ++++++++++++++++++
drivers/video/via/via_aux_vt1631.c | 46 +++++++++++++++++
drivers/video/via/via_aux_vt1632.c | 54 ++++++++++++++++++++
drivers/video/via/via_aux_vt1636.c | 46 +++++++++++++++++
drivers/video/via/via_i2c.c | 10 +++-
drivers/video/via/viafbdev.c | 53 +++++++++++++++++---
drivers/video/via/viafbdev.h | 6 ++
15 files changed, 736 insertions(+), 10 deletions(-)
create mode 100644 drivers/video/via/via_aux.c
create mode 100644 drivers/video/via/via_aux.h
create mode 100644 drivers/video/via/via_aux_ch7301.c
create mode 100644 drivers/video/via/via_aux_edid.c
create mode 100644 drivers/video/via/via_aux_sii164.c
create mode 100644 drivers/video/via/via_aux_vt1621.c
create mode 100644 drivers/video/via/via_aux_vt1622.c
create mode 100644 drivers/video/via/via_aux_vt1625.c
create mode 100644 drivers/video/via/via_aux_vt1631.c
create mode 100644 drivers/video/via/via_aux_vt1632.c
create mode 100644 drivers/video/via/via_aux_vt1636.c
--
1.7.9
^ permalink raw reply
* [PATCH 1/3] viafb: add auxiliary device management infrastructure
From: Florian Tobias Schandinat @ 2012-02-14 6:35 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329200232.git.FlorianSchandinat@gmx.de>
This patch adds the basic infrastructure and a few stub drivers for
devices that are connected via I2C busses. The infrastructure will
be used to replace and extend the support that is scattered
throughout viafb. The stub drivers are not very useful yet but they
show how the infrastructure works, provide information about the
chips integrated into a system and maybe gather some testers as it
would be very difficult for a single person to get a sane test
environment.
The only thing this actually does is probing the I2C busses which
will hopefully not cause any regressions.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/Makefile | 5 ++-
drivers/video/via/via_aux.c | 68 ++++++++++++++++++++++++++++
drivers/video/via/via_aux.h | 87 ++++++++++++++++++++++++++++++++++++
drivers/video/via/via_aux_ch7301.c | 50 ++++++++++++++++++++
drivers/video/via/via_aux_edid.c | 40 ++++++++++++++++
drivers/video/via/via_aux_sii164.c | 54 ++++++++++++++++++++++
drivers/video/via/via_aux_vt1621.c | 44 ++++++++++++++++++
drivers/video/via/via_aux_vt1622.c | 50 ++++++++++++++++++++
drivers/video/via/via_aux_vt1625.c | 50 ++++++++++++++++++++
drivers/video/via/via_aux_vt1631.c | 46 +++++++++++++++++++
drivers/video/via/via_aux_vt1632.c | 54 ++++++++++++++++++++++
drivers/video/via/via_aux_vt1636.c | 46 +++++++++++++++++++
drivers/video/via/viafbdev.c | 27 +++++++++++
drivers/video/via/viafbdev.h | 6 +++
14 files changed, 626 insertions(+), 1 deletions(-)
create mode 100644 drivers/video/via/via_aux.c
create mode 100644 drivers/video/via/via_aux.h
create mode 100644 drivers/video/via/via_aux_ch7301.c
create mode 100644 drivers/video/via/via_aux_edid.c
create mode 100644 drivers/video/via/via_aux_sii164.c
create mode 100644 drivers/video/via/via_aux_vt1621.c
create mode 100644 drivers/video/via/via_aux_vt1622.c
create mode 100644 drivers/video/via/via_aux_vt1625.c
create mode 100644 drivers/video/via/via_aux_vt1631.c
create mode 100644 drivers/video/via/via_aux_vt1632.c
create mode 100644 drivers/video/via/via_aux_vt1636.c
diff --git a/drivers/video/via/Makefile b/drivers/video/via/Makefile
index 5108136..159f26e 100644
--- a/drivers/video/via/Makefile
+++ b/drivers/video/via/Makefile
@@ -6,4 +6,7 @@ obj-$(CONFIG_FB_VIA) += viafb.o
viafb-y :=viafbdev.o hw.o via_i2c.o dvi.o lcd.o ioctl.o accel.o \
via_utility.o vt1636.o global.o tblDPASetting.o viamode.o \
- via-core.o via-gpio.o via_modesetting.o via_clock.o
+ via-core.o via-gpio.o via_modesetting.o via_clock.o \
+ via_aux.o via_aux_edid.o via_aux_vt1636.o via_aux_vt1632.o \
+ via_aux_vt1631.o via_aux_vt1625.o via_aux_vt1622.o via_aux_vt1621.o \
+ via_aux_sii164.o via_aux_ch7301.o
diff --git a/drivers/video/via/via_aux.c b/drivers/video/via/via_aux.c
new file mode 100644
index 0000000..e728b9b
--- /dev/null
+++ b/drivers/video/via/via_aux.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * infrastructure for devices connected via I2C
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+struct via_aux_bus *via_aux_probe(struct i2c_adapter *adap)
+{
+ struct via_aux_bus *bus;
+
+ if (!adap)
+ return NULL;
+
+ bus = kmalloc(sizeof(*bus), GFP_KERNEL);
+ if (!bus)
+ return NULL;
+
+ bus->adap = adap;
+ INIT_LIST_HEAD(&bus->drivers);
+
+ via_aux_edid_probe(bus);
+ via_aux_vt1636_probe(bus);
+ via_aux_vt1632_probe(bus);
+ via_aux_vt1631_probe(bus);
+ via_aux_vt1625_probe(bus);
+ via_aux_vt1622_probe(bus);
+ via_aux_vt1621_probe(bus);
+ via_aux_sii164_probe(bus);
+ via_aux_ch7301_probe(bus);
+
+ return bus;
+}
+
+void via_aux_free(struct via_aux_bus *bus)
+{
+ struct via_aux_drv *pos, *n;
+
+ if (!bus)
+ return;
+
+ list_for_each_entry_safe(pos, n, &bus->drivers, chain) {
+ list_del(&pos->chain);
+ kfree(pos);
+ }
+
+ kfree(bus);
+}
diff --git a/drivers/video/via/via_aux.h b/drivers/video/via/via_aux.h
new file mode 100644
index 0000000..5a4867a
--- /dev/null
+++ b/drivers/video/via/via_aux.h
@@ -0,0 +1,87 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * infrastructure for devices connected via I2C
+ */
+
+#ifndef __VIA_AUX_H__
+#define __VIA_AUX_H__
+
+
+#include <linux/list.h>
+#include <linux/i2c.h>
+
+
+struct via_aux_bus {
+ struct i2c_adapter *adap; /* the I2C device to access the bus */
+ struct list_head drivers; /* drivers for devices on this bus */
+};
+
+struct via_aux_drv {
+ struct list_head chain; /* chain to support multiple drivers */
+
+ struct via_aux_bus *bus; /* the I2C bus used */
+ u8 addr; /* the I2C slave address */
+
+ const char *name; /* human readable name of the driver */
+ void *data; /* private data of this driver */
+};
+
+
+struct via_aux_bus *via_aux_probe(struct i2c_adapter *adap);
+void via_aux_free(struct via_aux_bus *bus);
+
+
+static inline bool via_aux_add(struct via_aux_drv *drv)
+{
+ struct via_aux_drv *data = kmalloc(sizeof(*data), GFP_KERNEL);
+
+ if (!data)
+ return false;
+
+ *data = *drv;
+ list_add_tail(&data->chain, &data->bus->drivers);
+ return true;
+}
+
+static inline bool via_aux_read(struct via_aux_drv *drv, u8 start, u8 *buf,
+ u8 len)
+{
+ struct i2c_msg msg[2] = {
+ {.addr = drv->addr, .flags = 0, .len = 1, .buf = &start},
+ {.addr = drv->addr, .flags = I2C_M_RD, .len = len, .buf = buf} };
+
+ return i2c_transfer(drv->bus->adap, msg, 2) = 2;
+}
+
+
+/* probe functions of existing drivers - should only be called in via_aux.c */
+void via_aux_ch7301_probe(struct via_aux_bus *bus);
+void via_aux_edid_probe(struct via_aux_bus *bus);
+void via_aux_sii164_probe(struct via_aux_bus *bus);
+void via_aux_vt1636_probe(struct via_aux_bus *bus);
+void via_aux_vt1632_probe(struct via_aux_bus *bus);
+void via_aux_vt1631_probe(struct via_aux_bus *bus);
+void via_aux_vt1625_probe(struct via_aux_bus *bus);
+void via_aux_vt1622_probe(struct via_aux_bus *bus);
+void via_aux_vt1621_probe(struct via_aux_bus *bus);
+
+
+#endif /* __VIA_AUX_H__ */
diff --git a/drivers/video/via/via_aux_ch7301.c b/drivers/video/via/via_aux_ch7301.c
new file mode 100644
index 0000000..1cbe503
--- /dev/null
+++ b/drivers/video/via/via_aux_ch7301.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * driver for Chrontel CH7301 DVI Transmitter
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+static const char *name = "CH7301 DVI Transmitter";
+
+
+static void probe(struct via_aux_bus *bus, u8 addr)
+{
+ struct via_aux_drv drv = {
+ .bus = bus,
+ .addr = addr,
+ .name = name};
+ u8 tmp;
+
+ if (!via_aux_read(&drv, 0x4B, &tmp, 1) || tmp != 0x17)
+ return;
+
+ printk(KERN_INFO "viafb: Found %s at address 0x%x\n", name, addr);
+ via_aux_add(&drv);
+}
+
+void via_aux_ch7301_probe(struct via_aux_bus *bus)
+{
+ probe(bus, 0x75);
+ probe(bus, 0x76);
+}
diff --git a/drivers/video/via/via_aux_edid.c b/drivers/video/via/via_aux_edid.c
new file mode 100644
index 0000000..547bff5
--- /dev/null
+++ b/drivers/video/via/via_aux_edid.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * generic EDID driver
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+static const char *name = "EDID";
+
+
+void via_aux_edid_probe(struct via_aux_bus *bus)
+{
+ struct via_aux_drv drv = {
+ .bus = bus,
+ .addr = 0x50,
+ .name = name};
+
+ /* as EDID devices can be connected/disconnected just add the driver */
+ via_aux_add(&drv);
+}
diff --git a/drivers/video/via/via_aux_sii164.c b/drivers/video/via/via_aux_sii164.c
new file mode 100644
index 0000000..ca1b35f
--- /dev/null
+++ b/drivers/video/via/via_aux_sii164.c
@@ -0,0 +1,54 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * driver for Silicon Image SiI 164 PanelLink Transmitter
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+static const char *name = "SiI 164 PanelLink Transmitter";
+
+
+static void probe(struct via_aux_bus *bus, u8 addr)
+{
+ struct via_aux_drv drv = {
+ .bus = bus,
+ .addr = addr,
+ .name = name};
+ /* check vendor id and device id */
+ const u8 id[] = {0x01, 0x00, 0x06, 0x00}, len = ARRAY_SIZE(id);
+ u8 tmp[len];
+
+ if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
+ return;
+
+ printk(KERN_INFO "viafb: Found %s at address 0x%x\n", name, addr);
+ via_aux_add(&drv);
+}
+
+void via_aux_sii164_probe(struct via_aux_bus *bus)
+{
+ u8 i;
+
+ for (i = 0x38; i <= 0x3F; i++)
+ probe(bus, i);
+}
diff --git a/drivers/video/via/via_aux_vt1621.c b/drivers/video/via/via_aux_vt1621.c
new file mode 100644
index 0000000..38eca84
--- /dev/null
+++ b/drivers/video/via/via_aux_vt1621.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * driver for VIA VT1621(M) TV Encoder
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+static const char *name = "VT1621(M) TV Encoder";
+
+
+void via_aux_vt1621_probe(struct via_aux_bus *bus)
+{
+ struct via_aux_drv drv = {
+ .bus = bus,
+ .addr = 0x20,
+ .name = name};
+ u8 tmp;
+
+ if (!via_aux_read(&drv, 0x1B, &tmp, 1) || tmp != 0x02)
+ return;
+
+ printk(KERN_INFO "viafb: Found %s\n", name);
+ via_aux_add(&drv);
+}
diff --git a/drivers/video/via/via_aux_vt1622.c b/drivers/video/via/via_aux_vt1622.c
new file mode 100644
index 0000000..8c79c68
--- /dev/null
+++ b/drivers/video/via/via_aux_vt1622.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * driver for VIA VT1622(M) Digital TV Encoder
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+static const char *name = "VT1622(M) Digital TV Encoder";
+
+
+static void probe(struct via_aux_bus *bus, u8 addr)
+{
+ struct via_aux_drv drv = {
+ .bus = bus,
+ .addr = addr,
+ .name = name};
+ u8 tmp;
+
+ if (!via_aux_read(&drv, 0x1B, &tmp, 1) || tmp != 0x03)
+ return;
+
+ printk(KERN_INFO "viafb: Found %s at address 0x%x\n", name, addr);
+ via_aux_add(&drv);
+}
+
+void via_aux_vt1622_probe(struct via_aux_bus *bus)
+{
+ probe(bus, 0x20);
+ probe(bus, 0x21);
+}
diff --git a/drivers/video/via/via_aux_vt1625.c b/drivers/video/via/via_aux_vt1625.c
new file mode 100644
index 0000000..03eb301
--- /dev/null
+++ b/drivers/video/via/via_aux_vt1625.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * driver for VIA VT1625(M) HDTV Encoder
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+static const char *name = "VT1625(M) HDTV Encoder";
+
+
+static void probe(struct via_aux_bus *bus, u8 addr)
+{
+ struct via_aux_drv drv = {
+ .bus = bus,
+ .addr = addr,
+ .name = name};
+ u8 tmp;
+
+ if (!via_aux_read(&drv, 0x1B, &tmp, 1) || tmp != 0x50)
+ return;
+
+ printk(KERN_INFO "viafb: Found %s at address 0x%x\n", name, addr);
+ via_aux_add(&drv);
+}
+
+void via_aux_vt1625_probe(struct via_aux_bus *bus)
+{
+ probe(bus, 0x20);
+ probe(bus, 0x21);
+}
diff --git a/drivers/video/via/via_aux_vt1631.c b/drivers/video/via/via_aux_vt1631.c
new file mode 100644
index 0000000..06e742f
--- /dev/null
+++ b/drivers/video/via/via_aux_vt1631.c
@@ -0,0 +1,46 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * driver for VIA VT1631 LVDS Transmitter
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+static const char *name = "VT1631 LVDS Transmitter";
+
+
+void via_aux_vt1631_probe(struct via_aux_bus *bus)
+{
+ struct via_aux_drv drv = {
+ .bus = bus,
+ .addr = 0x38,
+ .name = name};
+ /* check vendor id and device id */
+ const u8 id[] = {0x06, 0x11, 0x91, 0x31}, len = ARRAY_SIZE(id);
+ u8 tmp[len];
+
+ if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
+ return;
+
+ printk(KERN_INFO "viafb: Found %s\n", name);
+ via_aux_add(&drv);
+}
diff --git a/drivers/video/via/via_aux_vt1632.c b/drivers/video/via/via_aux_vt1632.c
new file mode 100644
index 0000000..d24f4cd
--- /dev/null
+++ b/drivers/video/via/via_aux_vt1632.c
@@ -0,0 +1,54 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * driver for VIA VT1632 DVI Transmitter
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+static const char *name = "VT1632 DVI Transmitter";
+
+
+static void probe(struct via_aux_bus *bus, u8 addr)
+{
+ struct via_aux_drv drv = {
+ .bus = bus,
+ .addr = addr,
+ .name = name};
+ /* check vendor id and device id */
+ const u8 id[] = {0x06, 0x11, 0x92, 0x31}, len = ARRAY_SIZE(id);
+ u8 tmp[len];
+
+ if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
+ return;
+
+ printk(KERN_INFO "viafb: Found %s at address 0x%x\n", name, addr);
+ via_aux_add(&drv);
+}
+
+void via_aux_vt1632_probe(struct via_aux_bus *bus)
+{
+ u8 i;
+
+ for (i = 0x08; i <= 0x0F; i++)
+ probe(bus, i);
+}
diff --git a/drivers/video/via/via_aux_vt1636.c b/drivers/video/via/via_aux_vt1636.c
new file mode 100644
index 0000000..9e015c1
--- /dev/null
+++ b/drivers/video/via/via_aux_vt1636.c
@@ -0,0 +1,46 @@
+/*
+ * Copyright 2011 Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
+ * the implied warranty of MERCHANTABILITY or FITNESS FOR
+ * A PARTICULAR PURPOSE.See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+/*
+ * driver for VIA VT1636 LVDS Transmitter
+ */
+
+#include <linux/slab.h>
+#include "via_aux.h"
+
+
+static const char *name = "VT1636 LVDS Transmitter";
+
+
+void via_aux_vt1636_probe(struct via_aux_bus *bus)
+{
+ struct via_aux_drv drv = {
+ .bus = bus,
+ .addr = 0x40,
+ .name = name};
+ /* check vendor id and device id */
+ const u8 id[] = {0x06, 0x11, 0x45, 0x33}, len = ARRAY_SIZE(id);
+ u8 tmp[len];
+
+ if (!via_aux_read(&drv, 0x00, tmp, len) || memcmp(id, tmp, len))
+ return;
+
+ printk(KERN_INFO "viafb: Found %s\n", name);
+ via_aux_add(&drv);
+}
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index a13c258..6d5b649 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -24,6 +24,7 @@
#include <linux/slab.h>
#include <linux/stat.h>
#include <linux/via-core.h>
+#include <linux/via_i2c.h>
#include <asm/olpc.h>
#define _MASTER_FILE
@@ -1729,6 +1730,29 @@ static struct viafb_pm_hooks viafb_fb_pm_hooks = {
#endif
+static void __devinit i2c_bus_probe(struct viafb_shared *shared)
+{
+ /* should be always CRT */
+ printk(KERN_INFO "viafb: Probing I2C bus 0x26\n");
+ shared->i2c_26 = via_aux_probe(viafb_find_i2c_adapter(VIA_PORT_26));
+
+ /* seems to be usually DVP1 */
+ printk(KERN_INFO "viafb: Probing I2C bus 0x31\n");
+ shared->i2c_31 = via_aux_probe(viafb_find_i2c_adapter(VIA_PORT_31));
+
+ /* FIXME: what is this? */
+ printk(KERN_INFO "viafb: Probing I2C bus 0x2C\n");
+ shared->i2c_2C = via_aux_probe(viafb_find_i2c_adapter(VIA_PORT_2C));
+
+ printk(KERN_INFO "viafb: Finished I2C bus probing");
+}
+
+static void i2c_bus_free(struct viafb_shared *shared)
+{
+ via_aux_free(shared->i2c_26);
+ via_aux_free(shared->i2c_31);
+ via_aux_free(shared->i2c_2C);
+}
int __devinit via_fb_pci_probe(struct viafb_dev *vdev)
{
@@ -1762,6 +1786,7 @@ int __devinit via_fb_pci_probe(struct viafb_dev *vdev)
&viaparinfo->shared->lvds_setting_info2;
viaparinfo->chip_info = &viaparinfo->shared->chip_info;
+ i2c_bus_probe(viaparinfo->shared);
if (viafb_dual_fb)
viafb_SAMM_ON = 1;
parse_lcd_port();
@@ -1915,6 +1940,7 @@ out_fb1_release:
if (viafbinfo1)
framebuffer_release(viafbinfo1);
out_fb_release:
+ i2c_bus_free(viaparinfo->shared);
framebuffer_release(viafbinfo);
return rc;
}
@@ -1927,6 +1953,7 @@ void __devexit via_fb_pci_remove(struct pci_dev *pdev)
if (viafb_dual_fb)
unregister_framebuffer(viafbinfo1);
viafb_remove_proc(viaparinfo->shared);
+ i2c_bus_free(viaparinfo->shared);
framebuffer_release(viafbinfo);
if (viafb_dual_fb)
framebuffer_release(viafbinfo1);
diff --git a/drivers/video/via/viafbdev.h b/drivers/video/via/viafbdev.h
index d944063..f6b2ddf 100644
--- a/drivers/video/via/viafbdev.h
+++ b/drivers/video/via/viafbdev.h
@@ -26,6 +26,7 @@
#include <linux/fb.h>
#include <linux/spinlock.h>
+#include "via_aux.h"
#include "ioctl.h"
#include "share.h"
#include "chip.h"
@@ -48,6 +49,11 @@ struct viafb_shared {
struct proc_dir_entry *iga2_proc_entry;
struct viafb_dev *vdev; /* Global dev info */
+ /* I2C busses that may have auxiliary devices */
+ struct via_aux_bus *i2c_26;
+ struct via_aux_bus *i2c_31;
+ struct via_aux_bus *i2c_2C;
+
/* All the information will be needed to set engine */
struct tmds_setting_information tmds_setting_info;
struct lvds_setting_information lvds_setting_info;
--
1.7.9
^ permalink raw reply related
* [PATCH 2/3] viafb: fix I2C emulation on GPIO ports
From: Florian Tobias Schandinat @ 2012-02-14 6:35 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329200232.git.FlorianSchandinat@gmx.de>
This patch fixes the I2C emulation on GPIO ports by enabling it
(software controlled) and disabling the output on a GPIO line before
reading it.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/via_i2c.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/video/via/via_i2c.c b/drivers/video/via/via_i2c.c
index 78f1405..dd53058 100644
--- a/drivers/video/via/via_i2c.c
+++ b/drivers/video/via/via_i2c.c
@@ -51,7 +51,7 @@ static void via_i2c_setscl(void *data, int state)
val |= 0x01;
break;
case VIA_PORT_GPIO:
- val |= 0x80;
+ val |= 0x82;
break;
default:
printk(KERN_ERR "viafb_i2c: specify wrong i2c type.\n");
@@ -67,6 +67,9 @@ static int via_i2c_getscl(void *data)
int ret = 0;
spin_lock_irqsave(&i2c_vdev->reg_lock, flags);
+ if (adap_data->type = VIA_PORT_GPIO)
+ via_write_reg_mask(adap_data->io_port, adap_data->ioport_index,
+ 0, 0x80);
if (via_read_reg(adap_data->io_port, adap_data->ioport_index) & 0x08)
ret = 1;
spin_unlock_irqrestore(&i2c_vdev->reg_lock, flags);
@@ -80,6 +83,9 @@ static int via_i2c_getsda(void *data)
int ret = 0;
spin_lock_irqsave(&i2c_vdev->reg_lock, flags);
+ if (adap_data->type = VIA_PORT_GPIO)
+ via_write_reg_mask(adap_data->io_port, adap_data->ioport_index,
+ 0, 0x40);
if (via_read_reg(adap_data->io_port, adap_data->ioport_index) & 0x04)
ret = 1;
spin_unlock_irqrestore(&i2c_vdev->reg_lock, flags);
@@ -103,7 +109,7 @@ static void via_i2c_setsda(void *data, int state)
val |= 0x01;
break;
case VIA_PORT_GPIO:
- val |= 0x40;
+ val |= 0x42;
break;
default:
printk(KERN_ERR "viafb_i2c: specify wrong i2c type.\n");
--
1.7.9
^ permalink raw reply related
* [PATCH 3/3] viafb: add initial EDID support
From: Florian Tobias Schandinat @ 2012-02-14 6:35 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329200232.git.FlorianSchandinat@gmx.de>
This patch adds support for using EDID data on CRT and DVP1 for
initial configuration if viafb_mode or viafb_mode1 are not present.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/via_aux.c | 20 +++++++++++++
drivers/video/via/via_aux.h | 6 ++++
drivers/video/via/via_aux_edid.c | 59 +++++++++++++++++++++++++++++++++++++-
drivers/video/via/viafbdev.c | 26 ++++++++++++----
4 files changed, 103 insertions(+), 8 deletions(-)
diff --git a/drivers/video/via/via_aux.c b/drivers/video/via/via_aux.c
index e728b9b..4a0a55c 100644
--- a/drivers/video/via/via_aux.c
+++ b/drivers/video/via/via_aux.c
@@ -60,9 +60,29 @@ void via_aux_free(struct via_aux_bus *bus)
return;
list_for_each_entry_safe(pos, n, &bus->drivers, chain) {
+ if (pos->cleanup)
+ pos->cleanup(pos);
+
list_del(&pos->chain);
+ kfree(pos->data);
kfree(pos);
}
kfree(bus);
}
+
+const struct fb_videomode *via_aux_get_preferred_mode(struct via_aux_bus *bus)
+{
+ struct via_aux_drv *pos;
+ const struct fb_videomode *mode = NULL;
+
+ if (!bus)
+ return NULL;
+
+ list_for_each_entry(pos, &bus->drivers, chain) {
+ if (pos->get_preferred_mode)
+ mode = pos->get_preferred_mode(pos);
+ }
+
+ return mode;
+}
diff --git a/drivers/video/via/via_aux.h b/drivers/video/via/via_aux.h
index 5a4867a..a8de3f0 100644
--- a/drivers/video/via/via_aux.h
+++ b/drivers/video/via/via_aux.h
@@ -27,6 +27,7 @@
#include <linux/list.h>
#include <linux/i2c.h>
+#include <linux/fb.h>
struct via_aux_bus {
@@ -42,11 +43,16 @@ struct via_aux_drv {
const char *name; /* human readable name of the driver */
void *data; /* private data of this driver */
+
+ void (*cleanup)(struct via_aux_drv *drv);
+ const struct fb_videomode* (*get_preferred_mode)
+ (struct via_aux_drv *drv);
};
struct via_aux_bus *via_aux_probe(struct i2c_adapter *adap);
void via_aux_free(struct via_aux_bus *bus);
+const struct fb_videomode *via_aux_get_preferred_mode(struct via_aux_bus *bus);
static inline bool via_aux_add(struct via_aux_drv *drv)
diff --git a/drivers/video/via/via_aux_edid.c b/drivers/video/via/via_aux_edid.c
index 547bff5..03f7a41 100644
--- a/drivers/video/via/via_aux_edid.c
+++ b/drivers/video/via/via_aux_edid.c
@@ -22,18 +22,75 @@
*/
#include <linux/slab.h>
+#include <linux/fb.h>
#include "via_aux.h"
+#include "../edid.h"
static const char *name = "EDID";
+static void query_edid(struct via_aux_drv *drv)
+{
+ struct fb_monspecs *spec = drv->data;
+ unsigned char edid[EDID_LENGTH];
+ bool valid = false;
+
+ if (spec)
+ fb_destroy_modedb(spec->modedb);
+ else
+ spec = kmalloc(sizeof(*spec), GFP_KERNEL);
+
+ spec->version = spec->revision = 0;
+ if (via_aux_read(drv, 0x00, edid, EDID_LENGTH)) {
+ fb_edid_to_monspecs(edid, spec);
+ valid = spec->version || spec->revision;
+ }
+
+ if (!valid) {
+ kfree(spec);
+ spec = NULL;
+ } else
+ printk(KERN_DEBUG "EDID: %s %s\n", spec->manufacturer, spec->monitor);
+
+ drv->data = spec;
+}
+
+static const struct fb_videomode *get_preferred_mode(struct via_aux_drv *drv)
+{
+ struct fb_monspecs *spec = drv->data;
+ int i;
+
+ if (!spec || !spec->modedb || !(spec->misc & FB_MISC_1ST_DETAIL))
+ return NULL;
+
+ for (i = 0; i < spec->modedb_len; i++) {
+ if (spec->modedb[i].flag & FB_MODE_IS_FIRST &&
+ spec->modedb[i].flag & FB_MODE_IS_DETAILED)
+ return &spec->modedb[i];
+ }
+
+ return NULL;
+}
+
+static void cleanup(struct via_aux_drv *drv)
+{
+ struct fb_monspecs *spec = drv->data;
+
+ if (spec)
+ fb_destroy_modedb(spec->modedb);
+}
+
void via_aux_edid_probe(struct via_aux_bus *bus)
{
struct via_aux_drv drv = {
.bus = bus,
.addr = 0x50,
- .name = name};
+ .name = name,
+ .cleanup = cleanup,
+ .get_preferred_mode = get_preferred_mode};
+
+ query_edid(&drv);
/* as EDID devices can be connected/disconnected just add the driver */
via_aux_add(&drv);
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 6d5b649..4791165 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1671,12 +1671,23 @@ static void viafb_remove_proc(struct viafb_shared *shared)
}
#undef IS_VT1636
-static int parse_mode(const char *str, u32 *xres, u32 *yres)
+static int parse_mode(const char *str, u32 devices, u32 *xres, u32 *yres)
{
+ const struct fb_videomode *mode = NULL;
char *ptr;
if (!str) {
- if (machine_is_olpc()) {
+ if (devices = VIA_CRT)
+ mode = via_aux_get_preferred_mode(
+ viaparinfo->shared->i2c_26);
+ else if (devices = VIA_DVP1)
+ mode = via_aux_get_preferred_mode(
+ viaparinfo->shared->i2c_31);
+
+ if (mode) {
+ *xres = mode->xres;
+ *yres = mode->yres;
+ } else if (machine_is_olpc()) {
*xres = 1200;
*yres = 900;
} else {
@@ -1829,10 +1840,11 @@ int __devinit via_fb_pci_probe(struct viafb_dev *vdev)
viafb_second_size * 1024 * 1024;
}
- parse_mode(viafb_mode, &default_xres, &default_yres);
+ parse_mode(viafb_mode, viaparinfo->shared->iga1_devices,
+ &default_xres, &default_yres);
if (viafb_SAMM_ON = 1)
- parse_mode(viafb_mode1, &viafb_second_xres,
- &viafb_second_yres);
+ parse_mode(viafb_mode1, viaparinfo->shared->iga2_devices,
+ &viafb_second_xres, &viafb_second_yres);
default_var.xres = default_xres;
default_var.yres = default_yres;
@@ -2060,9 +2072,9 @@ int __init viafb_init(void)
if (r < 0)
return r;
#endif
- if (parse_mode(viafb_mode, &dummy_x, &dummy_y)
+ if (parse_mode(viafb_mode, 0, &dummy_x, &dummy_y)
|| !viafb_get_best_mode(dummy_x, dummy_y, viafb_refresh)
- || parse_mode(viafb_mode1, &dummy_x, &dummy_y)
+ || parse_mode(viafb_mode1, 0, &dummy_x, &dummy_y)
|| !viafb_get_best_mode(dummy_x, dummy_y, viafb_refresh1)
|| viafb_bpp < 0 || viafb_bpp > 32
|| viafb_bpp1 < 0 || viafb_bpp1 > 32
--
1.7.9
^ permalink raw reply related
* Re: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
From: Tomi Valkeinen @ 2012-02-14 11:52 UTC (permalink / raw)
To: tony; +Cc: linux-fbdev, archit, linux-omap
In-Reply-To: <1327399231-20826-1-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4994 bytes --]
Hi Tony,
On Tue, 2012-01-24 at 12:00 +0200, Tomi Valkeinen wrote:
> Now that all omap2+ boards have been changed to use the newer omapdss driver,
> this patch series removes omap2+ support from the old omapfb driver
> (drivers/video/omap), and thus makes it an omap1 dss/fb driver.
>
> The use of SRAM for video ram had earlier been disabled by removing the SRAM
> allocation (fee926bb0d399b1eaaf38f9f694bbf2747c4b8a2), and now this series also
> removes the support from the omap fb drivers.
>
> Also various cleanup patches allow us to remove remove OMAP_TAG_LCD and
> OMAP_TAG_FBMEM.
>
> All in all, the series removes quite a bit of unneeded code and cleans up the
> links between the board files and the display drivers, and this should help
> with device tree adaptation.
>
> Some of the patches affect the newer omapdss and omapfb drivers, but mostly the
> patches deal with omap1. I have compile tested the series for both omap1 and
> omap2, but I have only tested this on OMAP3 and OMAP4 boards, as I don't have
> OMAP1/2 boards. I think N770's display won't work after these patches, but
> other OMAP1 boards should be ok. To fix N770's display requires knowledge of
> the hardware setup, which is currently passed from the bootloader.
Tony, do you have any feedback on this? I think the arch/arm changes are
quite clean as such, but are you ok with (possibly) breaking N770's
display? The other OMAP1 boards should, at least in theory, work as well
as before.
For N770, the bootloader passes the reset GPIO number and number of
datalines, and I have no idea what those are.
Tomi
> Tomi
>
> Tomi Valkeinen (16):
> OMAPFB: remove old blizzard driver
> OMAPFB: Remove OMAP2/3 support from old omapfb driver
> OMAPDSS: Remove video SRAM support
> OMAPFB: Remove video SRAM support (old omapfb)
> OMAP2+: remove unneeded #include omapfb.h
> OMAP: N770: remove HWA742 platform data
> OAMPFB: remove unused omapfb_set_ctrl_platform_data()
> OMAPFB: remove early mem alloc from old omapfb
> OMAPFB: remove mem info from platform_data
> OMAPFB: remove unused fb_format_to_dss_mode()
> OMAPFB: Move old omapfb private structs to a private include file
> OMAPFB: remove omapfb_set_platform_data()
> OMAP1: pass LCD config with omapfb_set_lcd_config()
> OMAP: Remove OMAP_TAG_LCD and OMAP_TAG_FBMEM
> OMAP1: Remove unused LCD devices from board files
> OMAPFB: remove remaining OMAP arch checks
>
> arch/arm/mach-omap1/board-ams-delta.c | 9 +-
> arch/arm/mach-omap1/board-fsample.c | 15 +-
> arch/arm/mach-omap1/board-h2.c | 15 +-
> arch/arm/mach-omap1/board-h3.c | 9 +-
> arch/arm/mach-omap1/board-htcherald.c | 9 +-
> arch/arm/mach-omap1/board-innovator.c | 11 +-
> arch/arm/mach-omap1/board-nokia770.c | 19 +-
> arch/arm/mach-omap1/board-osk.c | 14 +-
> arch/arm/mach-omap1/board-palmte.c | 10 +-
> arch/arm/mach-omap1/board-palmtt.c | 10 +-
> arch/arm/mach-omap1/board-palmz71.c | 10 +-
> arch/arm/mach-omap1/board-perseus2.c | 15 +-
> arch/arm/mach-omap1/board-sx1.c | 16 +-
> arch/arm/mach-omap2/io.c | 1 -
> arch/arm/plat-omap/common.c | 2 -
> arch/arm/plat-omap/fb.c | 336 +------
> arch/arm/plat-omap/fb.h | 10 -
> arch/arm/plat-omap/include/plat/blizzard.h | 12 -
> arch/arm/plat-omap/include/plat/board.h | 2 -
> arch/arm/plat-omap/include/plat/hwa742.h | 8 -
> arch/arm/plat-omap/include/plat/vram.h | 21 +-
> drivers/video/omap/Kconfig | 16 +-
> drivers/video/omap/Makefile | 12 +-
> drivers/video/omap/blizzard.c | 1648 ----------------------------
> drivers/video/omap/dispc.c | 1547 --------------------------
> drivers/video/omap/dispc.h | 46 -
> drivers/video/omap/hwa742.c | 21 +-
> drivers/video/omap/omapfb.h | 25 +-
> drivers/video/omap/omapfb_main.c | 30 +-
> drivers/video/omap/rfbi.c | 598 ----------
> drivers/video/omap2/dss/dispc.c | 1 -
> drivers/video/omap2/omapfb/omapfb-ioctl.c | 2 +-
> drivers/video/omap2/omapfb/omapfb-main.c | 101 +--
> drivers/video/omap2/vram.c | 99 +--
> include/linux/omapfb.h | 32 +-
> 35 files changed, 100 insertions(+), 4632 deletions(-)
> delete mode 100644 arch/arm/plat-omap/fb.h
> delete mode 100644 arch/arm/plat-omap/include/plat/blizzard.h
> delete mode 100644 arch/arm/plat-omap/include/plat/hwa742.h
> delete mode 100644 drivers/video/omap/blizzard.c
> delete mode 100644 drivers/video/omap/dispc.c
> delete mode 100644 drivers/video/omap/dispc.h
> delete mode 100644 drivers/video/omap/rfbi.c
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Tomi Valkeinen @ 2012-02-14 11:57 UTC (permalink / raw)
To: Archit Taneja, Benoit Cousson; +Cc: linux-omap, linux, linux-fbdev
In-Reply-To: <1328854552-30714-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]
Hi,
On Fri, 2012-02-10 at 11:45 +0530, Archit Taneja wrote:
> For DSS clock domain to transition from idle to active state. It's necessary
> to enable the optional clock DSS_FCLK before we enable the module using the
> MODULEMODE bits in the clock domain's CM_DSS_DSS_CLKCTRL register.
>
> This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
> to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
> called for hdmi's platform device.
>
> Since the clock domain failed to change it's state to active, the hwmod code
> disables any clocks it had enabled before for this hwmod. This led to the clock
> 'dss_48mhz_clk' gettind disabled.
>
> When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
> correctly enables the DSS clock domain this time. However, the clock
> 'dss_48mhz_clk' is needed for HDMI's PHY to function correctly. Since it was
> disabled previously, the driver fails when it tries to enable HDMI's PHY.
>
> Fix this for now by ensuring that dss_runtime_get() is called before we call
> pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would
> be to modify the DSS related hwmod's mainclks, and also some changes in how
> opt clocks are handled in the DSS driver.
>
> This fixes the issue of HDMI not working when it's the default display. The
> issue is not seen if any other display is already enabled as the first display
> would have correctly enabled the DSS clockdomain.
I think this looks fine, it's shouldn't have any side effects and is
easy to remove later.
Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
hwmod/clk framework at some point, and the drivers could do without
these kinds of hacks? =)
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* OMAP DSS warning in apply.c
From: Russell King - ARM Linux @ 2012-02-14 12:06 UTC (permalink / raw)
To: Archit Taneja, Benoit Cousson; +Cc: linux-omap, linux, linux-fbdev
kautobuildv2 discovered this in its omap4430sdp oldconfig build:
drivers/video/omap2/dss/apply.c:350: warning: 'wait_pending_extra_info_updates' defined but not used
This looks like a valid warning, because wait_pending_extra_info_updates()
seems to be completely unreferenced. Should the function be removed?
It looks like extra_updated_completion can also be removed as well, as
that function is the only place it gets initialized and waited for.
The function also looks weird - it calls extra_info_update_ongoing() first
under a lock, and then outside the lock. It's not particularly nice API
wise to have stuff sometimes called under a lock and sometimes not.
^ permalink raw reply
* Re: [PATCH] OMAP: DSS2: TPO-TD03MTEA1: update default gamma
From: Tomi Valkeinen @ 2012-02-14 12:35 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1328573630-7348-2-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
Hi,
On Tue, 2012-02-07 at 02:13 +0200, Grazvydas Ignotas wrote:
> Over time better gamma has been determined and tuned with some
> equipment so update the defaults. From subjective point of view
> dark shades should be better visible.
Is there even need for default gamma? I'd guess the panel has a default
gamma in its firmware, so it should work fine without setting it. And
there's sysfs interface to set the gamma from userspace.
And, as you said, it's subjective, i.e. there's no right value for it,
so I'm a bit inclined to say that the driver shouldn't even set a
default gamma, and just leave it to userspace.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: OMAP DSS warning in apply.c
From: Cousson, Benoit @ 2012-02-14 12:38 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Archit Taneja, linux-omap, linux-fbdev, Valkeinen, Tomi
In-Reply-To: <20120214120643.GH15338@n2100.arm.linux.org.uk>
+ Tomi
On 2/14/2012 1:06 PM, Russell King - ARM Linux wrote:
> kautobuildv2 discovered this in its omap4430sdp oldconfig build:
>
> drivers/video/omap2/dss/apply.c:350: warning: 'wait_pending_extra_info_updates' defined but not used
>
> This looks like a valid warning, because wait_pending_extra_info_updates()
> seems to be completely unreferenced. Should the function be removed?
> It looks like extra_updated_completion can also be removed as well, as
> that function is the only place it gets initialized and waited for.
>
> The function also looks weird - it calls extra_info_update_ongoing() first
> under a lock, and then outside the lock. It's not particularly nice API
> wise to have stuff sometimes called under a lock and sometimes not.
^ permalink raw reply
* Re: OMAP DSS warning in apply.c
From: Tomi Valkeinen @ 2012-02-14 12:57 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Archit Taneja, Benoit Cousson, linux-omap, linux-fbdev
In-Reply-To: <20120214120643.GH15338@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]
On Tue, 2012-02-14 at 12:06 +0000, Russell King - ARM Linux wrote:
> kautobuildv2 discovered this in its omap4430sdp oldconfig build:
>
> drivers/video/omap2/dss/apply.c:350: warning: 'wait_pending_extra_info_updates' defined but not used
>
> This looks like a valid warning, because wait_pending_extra_info_updates()
> seems to be completely unreferenced. Should the function be removed?
> It looks like extra_updated_completion can also be removed as well, as
> that function is the only place it gets initialized and waited for.
The function will be used when the fifo merge series goes in in the next
merge window.
I added the "extra_info" code before fifo merge, as it's will be used by
the fifo merge code and it kinda belonged with the other apply stuff.
The fifo merge code was also supposed to go in in the previous merge
window with the rest of the rewrites, but due to some complications it
was delayed and missed the merge window.
> The function also looks weird - it calls extra_info_update_ongoing() first
> under a lock, and then outside the lock. It's not particularly nice API
> wise to have stuff sometimes called under a lock and sometimes not.
The second call is actually extra, it was just added for verification
purposes during development to ensure that the wait logic works
correctly.
I'll remove it.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Cousson, Benoit @ 2012-02-14 12:58 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Archit Taneja, linux-omap, linux, linux-fbdev
In-Reply-To: <1329220678.1845.68.camel@deskari>
Hi Tomi,
On 2/14/2012 12:57 PM, Tomi Valkeinen wrote:
> Hi,
>
> On Fri, 2012-02-10 at 11:45 +0530, Archit Taneja wrote:
>> For DSS clock domain to transition from idle to active state. It's necessary
>> to enable the optional clock DSS_FCLK before we enable the module using the
>> MODULEMODE bits in the clock domain's CM_DSS_DSS_CLKCTRL register.
>>
>> This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
>> to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
>> called for hdmi's platform device.
>>
>> Since the clock domain failed to change it's state to active, the hwmod code
>> disables any clocks it had enabled before for this hwmod. This led to the clock
>> 'dss_48mhz_clk' gettind disabled.
>>
>> When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
>> correctly enables the DSS clock domain this time. However, the clock
>> 'dss_48mhz_clk' is needed for HDMI's PHY to function correctly. Since it was
>> disabled previously, the driver fails when it tries to enable HDMI's PHY.
>>
>> Fix this for now by ensuring that dss_runtime_get() is called before we call
>> pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would
>> be to modify the DSS related hwmod's mainclks, and also some changes in how
>> opt clocks are handled in the DSS driver.
>>
>> This fixes the issue of HDMI not working when it's the default display. The
>> issue is not seen if any other display is already enabled as the first display
>> would have correctly enabled the DSS clockdomain.
>
> I think this looks fine, it's shouldn't have any side effects and is
> easy to remove later.
>
> Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
> hwmod/clk framework at some point, and the drivers could do without
> these kinds of hacks? =)
The best way to fix that for my point of view is to go to device tree
or/and to consider the DSS as the parent of all the DSS modules.
pm_runtime will then always ensure that the parent is enabled before any
of the child are used.
Implementing that with hwmod is not the right approach since is will
require to add some more complex OMAP custom stuff in the hwmod fmwk
whereas the LDM is already able to handle that.
The whole point is that going to device tree, we will have to change the
responsibility of hwmod to make it focus mainly on OMAP PRCM stuff and
let the device handles the IRQ/DMA/REG/CLKS resources since it is the
correct place to do that.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH] OMAP: DSS2: TPO-TD03MTEA1: update default gamma
From: Grazvydas Ignotas @ 2012-02-14 13:14 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1329222910.1845.90.camel@deskari>
On Tue, Feb 14, 2012 at 2:35 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> On Tue, 2012-02-07 at 02:13 +0200, Grazvydas Ignotas wrote:
>> Over time better gamma has been determined and tuned with some
>> equipment so update the defaults. From subjective point of view
>> dark shades should be better visible.
>
> Is there even need for default gamma? I'd guess the panel has a default
> gamma in its firmware, so it should work fine without setting it. And
> there's sysfs interface to set the gamma from userspace.
>
> And, as you said, it's subjective, i.e. there's no right value for it,
> so I'm a bit inclined to say that the driver shouldn't even set a
> default gamma, and just leave it to userspace.
Well for pandora, we encourage people to run custom Linux distros on
the device, people reported running Debian, Arch and Slackware on the
device, so we don't have control over everyone's userspace. To reduce
the need for everyone to hack userspace of their distro of choice, it
would be great to have nice display just from the kernel,
out-of-the-box (this gamma has been tuned with some TV studio
equipment so is not totally subjective). Still if you don't want it,
we can keep carrying that in pandora's kernel tree too.
--
Graþvydas
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Tomi Valkeinen @ 2012-02-14 13:15 UTC (permalink / raw)
To: Cousson, Benoit; +Cc: Archit Taneja, linux-omap, linux, linux-fbdev
In-Reply-To: <4F3A5A5D.4020906@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]
On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
> Hi Tomi,
> > Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
> > hwmod/clk framework at some point, and the drivers could do without
> > these kinds of hacks? =)
>
> The best way to fix that for my point of view is to go to device tree
> or/and to consider the DSS as the parent of all the DSS modules.
> pm_runtime will then always ensure that the parent is enabled before any
> of the child are used.
Ah, right. Sounds fine to me.
But is that a proper "fix"? Are we sure the MODULEMODE will then always
be handled correctly? Isn't the core problem still there, it just
doesn't happen with the setup anymore?
I mean, if we have these special requirements regarding MODULEMODE, and
the code doesn't really know about it, would it get broken easily with
restructuring/changes?
And no, I don't have any clear idea why/how it would break, but I have
just gotten the impression that the MODULEMODE is not handled quite
properly (and so we have these current problems), and having dss_core as
the parent of other dss modules doesn't really fix that in any way.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAP: DSS2: TPO-TD03MTEA1: update default gamma
From: Tomi Valkeinen @ 2012-02-14 13:17 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap
In-Reply-To: <CANOLnONLHgRzZ-rez4p9Ou6qCtoWVhZWPXNEgsQarBRVFstTaw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]
On Tue, 2012-02-14 at 15:14 +0200, Grazvydas Ignotas wrote:
> On Tue, Feb 14, 2012 at 2:35 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Hi,
> >
> > On Tue, 2012-02-07 at 02:13 +0200, Grazvydas Ignotas wrote:
> >> Over time better gamma has been determined and tuned with some
> >> equipment so update the defaults. From subjective point of view
> >> dark shades should be better visible.
> >
> > Is there even need for default gamma? I'd guess the panel has a default
> > gamma in its firmware, so it should work fine without setting it. And
> > there's sysfs interface to set the gamma from userspace.
> >
> > And, as you said, it's subjective, i.e. there's no right value for it,
> > so I'm a bit inclined to say that the driver shouldn't even set a
> > default gamma, and just leave it to userspace.
>
> Well for pandora, we encourage people to run custom Linux distros on
> the device, people reported running Debian, Arch and Slackware on the
> device, so we don't have control over everyone's userspace. To reduce
> the need for everyone to hack userspace of their distro of choice, it
> would be great to have nice display just from the kernel,
> out-of-the-box (this gamma has been tuned with some TV studio
> equipment so is not totally subjective). Still if you don't want it,
> we can keep carrying that in pandora's kernel tree too.
Ok, fair enough. It's not a problem, just a few lines of code. But I
don't want to get patches every now and that adjust the default gamma to
whatever is subjectively best at that point of time =).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Tomi Valkeinen @ 2012-02-14 13:33 UTC (permalink / raw)
To: Archit Taneja
Cc: Cousson, Benoit, Archit Taneja, linux-omap, linux, linux-fbdev
In-Reply-To: <4F3A61EF.4030803@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2733 bytes --]
On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
> Hi,
>
> On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
> > On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
> >> Hi Tomi,
> >
> >>> Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
> >>> hwmod/clk framework at some point, and the drivers could do without
> >>> these kinds of hacks? =)
> >>
> >> The best way to fix that for my point of view is to go to device tree
> >> or/and to consider the DSS as the parent of all the DSS modules.
> >> pm_runtime will then always ensure that the parent is enabled before any
> >> of the child are used.
> >
> > Ah, right. Sounds fine to me.
> >
> > But is that a proper "fix"? Are we sure the MODULEMODE will then always
> > be handled correctly? Isn't the core problem still there, it just
> > doesn't happen with the setup anymore?
> >
> > I mean, if we have these special requirements regarding MODULEMODE, and
> > the code doesn't really know about it, would it get broken easily with
> > restructuring/changes?
> >
> > And no, I don't have any clear idea why/how it would break, but I have
> > just gotten the impression that the MODULEMODE is not handled quite
> > properly (and so we have these current problems), and having dss_core as
> > the parent of other dss modules doesn't really fix that in any way.
>
> I agree with that.
>
> In the current approach, we have multiple platform devices for DSS, and
> all of them belong to the same clock domain, and the clock domain has
> just one MODULEMODE bit field.
>
> When shutting off a platform device(by calling pm_runtime_put()), hwmod
> enables/disables MODULEMODE without taking into mind that other active
> platform devices may still need it. So, for example, if we have 2
> platform devices, say dss and dispc, and we have code like:
>
> dispc_foo()
> {
> pm_runtime_get(dispc_pdev);
> ...
> ...
> pm_runtime_put(dispc_pdev);
> }
>
> dss_foo()
> {
> pm_runtime_get(dss_pdev);
> ...
> ...
> dispc_foo(); /* MODULEMODE off after this */
> ...
> ...
> pm_runtime_put(dss_pdev);
> }
>
> This will lead to the situation of one platform device disabling
> MODULEMODE even though other platform devices need it.
>
> This may not be resolved in device tree either. We would need to have
> some use count mechanism for these bits, or attach MODULEMODE only to
> one platform device, and don't give others control to enable/disable it.
Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
mapped to a dss clock (was it "dss_clk")?. And so, the clock's refcount
should keep the MODULEMODE enabled/disabled?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Archit Taneja @ 2012-02-14 13:42 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Cousson, Benoit, Archit Taneja, linux-omap, linux, linux-fbdev
In-Reply-To: <1329225311.1845.109.camel@deskari>
Hi,
On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
> On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
>> Hi Tomi,
>
>>> Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
>>> hwmod/clk framework at some point, and the drivers could do without
>>> these kinds of hacks? =)
>>
>> The best way to fix that for my point of view is to go to device tree
>> or/and to consider the DSS as the parent of all the DSS modules.
>> pm_runtime will then always ensure that the parent is enabled before any
>> of the child are used.
>
> Ah, right. Sounds fine to me.
>
> But is that a proper "fix"? Are we sure the MODULEMODE will then always
> be handled correctly? Isn't the core problem still there, it just
> doesn't happen with the setup anymore?
>
> I mean, if we have these special requirements regarding MODULEMODE, and
> the code doesn't really know about it, would it get broken easily with
> restructuring/changes?
>
> And no, I don't have any clear idea why/how it would break, but I have
> just gotten the impression that the MODULEMODE is not handled quite
> properly (and so we have these current problems), and having dss_core as
> the parent of other dss modules doesn't really fix that in any way.
I agree with that.
In the current approach, we have multiple platform devices for DSS, and
all of them belong to the same clock domain, and the clock domain has
just one MODULEMODE bit field.
When shutting off a platform device(by calling pm_runtime_put()), hwmod
enables/disables MODULEMODE without taking into mind that other active
platform devices may still need it. So, for example, if we have 2
platform devices, say dss and dispc, and we have code like:
dispc_foo()
{
pm_runtime_get(dispc_pdev);
...
...
pm_runtime_put(dispc_pdev);
}
dss_foo()
{
pm_runtime_get(dss_pdev);
...
...
dispc_foo(); /* MODULEMODE off after this */
...
...
pm_runtime_put(dss_pdev);
}
This will lead to the situation of one platform device disabling
MODULEMODE even though other platform devices need it.
This may not be resolved in device tree either. We would need to have
some use count mechanism for these bits, or attach MODULEMODE only to
one platform device, and don't give others control to enable/disable it.
Archit
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Archit Taneja @ 2012-02-14 13:57 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Cousson, Benoit, Archit Taneja, linux-omap, linux, linux-fbdev
In-Reply-To: <1329226404.1845.118.camel@deskari>
On Tuesday 14 February 2012 07:03 PM, Tomi Valkeinen wrote:
> On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
>> Hi,
>>
>> On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
>>> On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
>>>> Hi Tomi,
>>>
>>>>> Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
>>>>> hwmod/clk framework at some point, and the drivers could do without
>>>>> these kinds of hacks? =)
>>>>
>>>> The best way to fix that for my point of view is to go to device tree
>>>> or/and to consider the DSS as the parent of all the DSS modules.
>>>> pm_runtime will then always ensure that the parent is enabled before any
>>>> of the child are used.
>>>
>>> Ah, right. Sounds fine to me.
>>>
>>> But is that a proper "fix"? Are we sure the MODULEMODE will then always
>>> be handled correctly? Isn't the core problem still there, it just
>>> doesn't happen with the setup anymore?
>>>
>>> I mean, if we have these special requirements regarding MODULEMODE, and
>>> the code doesn't really know about it, would it get broken easily with
>>> restructuring/changes?
>>>
>>> And no, I don't have any clear idea why/how it would break, but I have
>>> just gotten the impression that the MODULEMODE is not handled quite
>>> properly (and so we have these current problems), and having dss_core as
>>> the parent of other dss modules doesn't really fix that in any way.
>>
>> I agree with that.
>>
>> In the current approach, we have multiple platform devices for DSS, and
>> all of them belong to the same clock domain, and the clock domain has
>> just one MODULEMODE bit field.
>>
>> When shutting off a platform device(by calling pm_runtime_put()), hwmod
>> enables/disables MODULEMODE without taking into mind that other active
>> platform devices may still need it. So, for example, if we have 2
>> platform devices, say dss and dispc, and we have code like:
>>
>> dispc_foo()
>> {
>> pm_runtime_get(dispc_pdev);
>> ...
>> ...
>> pm_runtime_put(dispc_pdev);
>> }
>>
>> dss_foo()
>> {
>> pm_runtime_get(dss_pdev);
>> ...
>> ...
>> dispc_foo(); /* MODULEMODE off after this */
>> ...
>> ...
>> pm_runtime_put(dss_pdev);
>> }
>>
>> This will lead to the situation of one platform device disabling
>> MODULEMODE even though other platform devices need it.
>>
>> This may not be resolved in device tree either. We would need to have
>> some use count mechanism for these bits, or attach MODULEMODE only to
>> one platform device, and don't give others control to enable/disable it.
>
> Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
> mapped to a dss clock (was it "dss_clk")?. And so, the clock's refcount
> should keep the MODULEMODE enabled/disabled?
Yes, that's how we are currently dealing with it and making things work.
We are forced to represent MODULEMODE as a clock. I forgot to mention
that in the last mail :)
However, other modules don't do this. modulemode control is taken care
by hwmod by itself. We just have to fill the hwmod field
'.prcm.omap4.modulemode' and get done with it. If we try this approach,
we get into the trouble I mentioned before.
We represent MODULEMODE as dss_fck, and make this the l3 slave clock for
all DSS hwmods. This way, we ensure that it gets enabled, and we get a
usecount associated to it. We shouldn't stick to this approach because:
- It isn't exactly correct. MODULEMODE isn't a clock, and others don't
do it.
- DSS requires a particular sequence of disabling clocks to go into
lower power states, and with the current approach, this doesn't happen.
So, DSS doesn't idle, and that's the whole purpose of this :)
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Cousson, Benoit @ 2012-02-14 15:41 UTC (permalink / raw)
To: Archit Taneja
Cc: Tomi Valkeinen, Archit Taneja, linux-omap, linux, linux-fbdev
In-Reply-To: <4F3A61EF.4030803@ti.com>
On 2/14/2012 2:30 PM, Archit Taneja wrote:
> Hi,
>
> On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
>> On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
>>> Hi Tomi,
>>
>>>> Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
>>>> hwmod/clk framework at some point, and the drivers could do without
>>>> these kinds of hacks? =)
>>>
>>> The best way to fix that for my point of view is to go to device tree
>>> or/and to consider the DSS as the parent of all the DSS modules.
>>> pm_runtime will then always ensure that the parent is enabled before any
>>> of the child are used.
>>
>> Ah, right. Sounds fine to me.
>>
>> But is that a proper "fix"? Are we sure the MODULEMODE will then always
>> be handled correctly? Isn't the core problem still there, it just
>> doesn't happen with the setup anymore?
>>
>> I mean, if we have these special requirements regarding MODULEMODE, and
>> the code doesn't really know about it, would it get broken easily with
>> restructuring/changes?
>>
>> And no, I don't have any clear idea why/how it would break, but I have
>> just gotten the impression that the MODULEMODE is not handled quite
>> properly (and so we have these current problems), and having dss_core as
>> the parent of other dss modules doesn't really fix that in any way.
>
> I agree with that.
>
> In the current approach, we have multiple platform devices for DSS, and
> all of them belong to the same clock domain, and the clock domain has
> just one MODULEMODE bit field.
>
> When shutting off a platform device(by calling pm_runtime_put()), hwmod
> enables/disables MODULEMODE without taking into mind that other active
> platform devices may still need it. So, for example, if we have 2
> platform devices, say dss and dispc, and we have code like:
>
> dispc_foo()
> {
> pm_runtime_get(dispc_pdev);
> ...
> ...
> pm_runtime_put(dispc_pdev);
> }
>
> dss_foo()
> {
> pm_runtime_get(dss_pdev);
> ...
> ...
> dispc_foo(); /* MODULEMODE off after this */
> ...
> ...
> pm_runtime_put(dss_pdev);
> }
>
> This will lead to the situation of one platform device disabling
> MODULEMODE even though other platform devices need it.
>
> This may not be resolved in device tree either. We would need to have
> some use count mechanism for these bits, or attach MODULEMODE only to
> one platform device, and don't give others control to enable/disable it.
And this is exactly what the pm_runtime will provide. The fmwk already
handles reference counting.
Moreover the dev->parent will increment the power.child_count and thus
ensure that the parent is always enabled if at least one child is active.
By initializing the dev->parent of each DSS modules to the dss_core, it
will ensure that the power dependency is managed properly.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Cousson, Benoit @ 2012-02-14 16:02 UTC (permalink / raw)
To: Archit Taneja
Cc: Tomi Valkeinen, Archit Taneja, linux-omap, linux, linux-fbdev
In-Reply-To: <4F3A6563.7000108@ti.com>
On 2/14/2012 2:45 PM, Archit Taneja wrote:
> On Tuesday 14 February 2012 07:03 PM, Tomi Valkeinen wrote:
>> On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
>>> Hi,
>>>
>>> On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
>>>> On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
>>>>> Hi Tomi,
>>>>
>>>>>> Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
>>>>>> hwmod/clk framework at some point, and the drivers could do without
>>>>>> these kinds of hacks? =)
>>>>>
>>>>> The best way to fix that for my point of view is to go to device tree
>>>>> or/and to consider the DSS as the parent of all the DSS modules.
>>>>> pm_runtime will then always ensure that the parent is enabled
>>>>> before any
>>>>> of the child are used.
>>>>
>>>> Ah, right. Sounds fine to me.
>>>>
>>>> But is that a proper "fix"? Are we sure the MODULEMODE will then always
>>>> be handled correctly? Isn't the core problem still there, it just
>>>> doesn't happen with the setup anymore?
>>>>
>>>> I mean, if we have these special requirements regarding MODULEMODE, and
>>>> the code doesn't really know about it, would it get broken easily with
>>>> restructuring/changes?
>>>>
>>>> And no, I don't have any clear idea why/how it would break, but I have
>>>> just gotten the impression that the MODULEMODE is not handled quite
>>>> properly (and so we have these current problems), and having
>>>> dss_core as
>>>> the parent of other dss modules doesn't really fix that in any way.
>>>
>>> I agree with that.
>>>
>>> In the current approach, we have multiple platform devices for DSS, and
>>> all of them belong to the same clock domain, and the clock domain has
>>> just one MODULEMODE bit field.
>>>
>>> When shutting off a platform device(by calling pm_runtime_put()), hwmod
>>> enables/disables MODULEMODE without taking into mind that other active
>>> platform devices may still need it. So, for example, if we have 2
>>> platform devices, say dss and dispc, and we have code like:
>>>
>>> dispc_foo()
>>> {
>>> pm_runtime_get(dispc_pdev);
>>> ...
>>> ...
>>> pm_runtime_put(dispc_pdev);
>>> }
>>>
>>> dss_foo()
>>> {
>>> pm_runtime_get(dss_pdev);
>>> ...
>>> ...
>>> dispc_foo(); /* MODULEMODE off after this */
>>> ...
>>> ...
>>> pm_runtime_put(dss_pdev);
>>> }
>>>
>>> This will lead to the situation of one platform device disabling
>>> MODULEMODE even though other platform devices need it.
>>>
>>> This may not be resolved in device tree either. We would need to have
>>> some use count mechanism for these bits, or attach MODULEMODE only to
>>> one platform device, and don't give others control to enable/disable it.
>>
>> Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
>> mapped to a dss clock (was it "dss_clk")?. And so, the clock's refcount
>> should keep the MODULEMODE enabled/disabled?
>
> Yes, that's how we are currently dealing with it and making things work.
> We are forced to represent MODULEMODE as a clock. I forgot to mention
> that in the last mail :)
>
> However, other modules don't do this. modulemode control is taken care
> by hwmod by itself. We just have to fill the hwmod field
> '.prcm.omap4.modulemode' and get done with it. If we try this approach,
> we get into the trouble I mentioned before.
>
> We represent MODULEMODE as dss_fck, and make this the l3 slave clock for
> all DSS hwmods. This way, we ensure that it gets enabled, and we get a
> usecount associated to it. We shouldn't stick to this approach because:
>
> - It isn't exactly correct. MODULEMODE isn't a clock, and others don't
> do it.
Yes, fully agree. This was done like that as a hack to avoid any
regression because at that time we were not sure if that dependency will
have to be handled by the hwmod fmwk or by the driver.
Now, I'm sure it should not be handled by the hwmod fmwk :-)
> - DSS requires a particular sequence of disabling clocks to go into
> lower power states, and with the current approach, this doesn't happen.
> So, DSS doesn't idle, and that's the whole purpose of this :)
I'm just curious, what particular sequence is required?
Thanks,
Benoit
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Shilimkar, Santosh @ 2012-02-14 16:59 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Archit Taneja, Tomi Valkeinen, Archit Taneja, linux-omap, linux,
linux-fbdev
In-Reply-To: <4F3A85B0.906@ti.com>
On Tue, Feb 14, 2012 at 9:32 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> On 2/14/2012 2:45 PM, Archit Taneja wrote:
>>
>> On Tuesday 14 February 2012 07:03 PM, Tomi Valkeinen wrote:
>>>
>>> On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
>>>>>
>>>>> On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
>>>>>>
>>>>>> Hi Tomi,
>>>>>
>>>>>
>>>>>>> Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
>>>>>>> hwmod/clk framework at some point, and the drivers could do without
>>>>>>> these kinds of hacks? =)
>>>>>>
>>>>>>
>>>>>> The best way to fix that for my point of view is to go to device tree
>>>>>> or/and to consider the DSS as the parent of all the DSS modules.
>>>>>> pm_runtime will then always ensure that the parent is enabled
>>>>>> before any
>>>>>> of the child are used.
>>>>>
>>>>>
>>>>> Ah, right. Sounds fine to me.
>>>>>
>>>>> But is that a proper "fix"? Are we sure the MODULEMODE will then always
>>>>> be handled correctly? Isn't the core problem still there, it just
>>>>> doesn't happen with the setup anymore?
>>>>>
>>>>> I mean, if we have these special requirements regarding MODULEMODE, and
>>>>> the code doesn't really know about it, would it get broken easily with
>>>>> restructuring/changes?
>>>>>
>>>>> And no, I don't have any clear idea why/how it would break, but I have
>>>>> just gotten the impression that the MODULEMODE is not handled quite
>>>>> properly (and so we have these current problems), and having
>>>>> dss_core as
>>>>> the parent of other dss modules doesn't really fix that in any way.
>>>>
>>>>
>>>> I agree with that.
>>>>
>>>> In the current approach, we have multiple platform devices for DSS, and
>>>> all of them belong to the same clock domain, and the clock domain has
>>>> just one MODULEMODE bit field.
>>>>
>>>> When shutting off a platform device(by calling pm_runtime_put()), hwmod
>>>> enables/disables MODULEMODE without taking into mind that other active
>>>> platform devices may still need it. So, for example, if we have 2
>>>> platform devices, say dss and dispc, and we have code like:
>>>>
>>>> dispc_foo()
>>>> {
>>>> pm_runtime_get(dispc_pdev);
>>>> ...
>>>> ...
>>>> pm_runtime_put(dispc_pdev);
>>>> }
>>>>
>>>> dss_foo()
>>>> {
>>>> pm_runtime_get(dss_pdev);
>>>> ...
>>>> ...
>>>> dispc_foo(); /* MODULEMODE off after this */
>>>> ...
>>>> ...
>>>> pm_runtime_put(dss_pdev);
>>>> }
>>>>
>>>> This will lead to the situation of one platform device disabling
>>>> MODULEMODE even though other platform devices need it.
>>>>
>>>> This may not be resolved in device tree either. We would need to have
>>>> some use count mechanism for these bits, or attach MODULEMODE only to
>>>> one platform device, and don't give others control to enable/disable it.
>>>
>>>
>>> Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
>>> mapped to a dss clock (was it "dss_clk")?. And so, the clock's refcount
>>> should keep the MODULEMODE enabled/disabled?
>>
>>
>> Yes, that's how we are currently dealing with it and making things work.
>> We are forced to represent MODULEMODE as a clock. I forgot to mention
>> that in the last mail :)
>>
>> However, other modules don't do this. modulemode control is taken care
>> by hwmod by itself. We just have to fill the hwmod field
>> '.prcm.omap4.modulemode' and get done with it. If we try this approach,
>> we get into the trouble I mentioned before.
>>
>> We represent MODULEMODE as dss_fck, and make this the l3 slave clock for
>> all DSS hwmods. This way, we ensure that it gets enabled, and we get a
>> usecount associated to it. We shouldn't stick to this approach because:
>>
>> - It isn't exactly correct. MODULEMODE isn't a clock, and others don't
>> do it.
>
>
> Yes, fully agree. This was done like that as a hack to avoid any regression
> because at that time we were not sure if that dependency will have to be
> handled by the hwmod fmwk or by the driver.
> Now, I'm sure it should not be handled by the hwmod fmwk :-)
>
>
>> - DSS requires a particular sequence of disabling clocks to go into
>> lower power states, and with the current approach, this doesn't happen.
>> So, DSS doesn't idle, and that's the whole purpose of this :)
>
>
> I'm just curious, what particular sequence is required?
>
IIRC, the main issue is the order in which functional clock and what
is so called
optional clock enabled ....
While enabling the module
1. Enable optional clock
2. Enabled module mode.
While disabling module
1. Disable module mode
2. Disable optional clock.
I think only above sequence work. Not following above in either
path leads to modules being stuck in transition.
Is that right Archit ?
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Archit Taneja @ 2012-02-14 19:54 UTC (permalink / raw)
To: Shilimkar, Santosh
Cc: Cousson, Benoit, Archit Taneja, Tomi Valkeinen, linux-omap, linux,
linux-fbdev
In-Reply-To: <CAMQu2gxdWt0rLZYs1SVToD1OExeqgRPTXcKPeR2RkUc-Qgqgqw@mail.gmail.com>
On Tuesday 14 February 2012 10:29 PM, Shilimkar, Santosh wrote:
> On Tue, Feb 14, 2012 at 9:32 PM, Cousson, Benoit<b-cousson@ti.com> wrote:
>> On 2/14/2012 2:45 PM, Archit Taneja wrote:
>>>
>>> On Tuesday 14 February 2012 07:03 PM, Tomi Valkeinen wrote:
>>>>
>>>> On Tue, 2012-02-14 at 19:00 +0530, Archit Taneja wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
>>>>>>
>>>>>> On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
>>>>>>>
>>>>>>> Hi Tomi,
>>>>>>
>>>>>>
>>>>>>>> Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
>>>>>>>> hwmod/clk framework at some point, and the drivers could do without
>>>>>>>> these kinds of hacks? =)
>>>>>>>
>>>>>>>
>>>>>>> The best way to fix that for my point of view is to go to device tree
>>>>>>> or/and to consider the DSS as the parent of all the DSS modules.
>>>>>>> pm_runtime will then always ensure that the parent is enabled
>>>>>>> before any
>>>>>>> of the child are used.
>>>>>>
>>>>>>
>>>>>> Ah, right. Sounds fine to me.
>>>>>>
>>>>>> But is that a proper "fix"? Are we sure the MODULEMODE will then always
>>>>>> be handled correctly? Isn't the core problem still there, it just
>>>>>> doesn't happen with the setup anymore?
>>>>>>
>>>>>> I mean, if we have these special requirements regarding MODULEMODE, and
>>>>>> the code doesn't really know about it, would it get broken easily with
>>>>>> restructuring/changes?
>>>>>>
>>>>>> And no, I don't have any clear idea why/how it would break, but I have
>>>>>> just gotten the impression that the MODULEMODE is not handled quite
>>>>>> properly (and so we have these current problems), and having
>>>>>> dss_core as
>>>>>> the parent of other dss modules doesn't really fix that in any way.
>>>>>
>>>>>
>>>>> I agree with that.
>>>>>
>>>>> In the current approach, we have multiple platform devices for DSS, and
>>>>> all of them belong to the same clock domain, and the clock domain has
>>>>> just one MODULEMODE bit field.
>>>>>
>>>>> When shutting off a platform device(by calling pm_runtime_put()), hwmod
>>>>> enables/disables MODULEMODE without taking into mind that other active
>>>>> platform devices may still need it. So, for example, if we have 2
>>>>> platform devices, say dss and dispc, and we have code like:
>>>>>
>>>>> dispc_foo()
>>>>> {
>>>>> pm_runtime_get(dispc_pdev);
>>>>> ...
>>>>> ...
>>>>> pm_runtime_put(dispc_pdev);
>>>>> }
>>>>>
>>>>> dss_foo()
>>>>> {
>>>>> pm_runtime_get(dss_pdev);
>>>>> ...
>>>>> ...
>>>>> dispc_foo(); /* MODULEMODE off after this */
>>>>> ...
>>>>> ...
>>>>> pm_runtime_put(dss_pdev);
>>>>> }
>>>>>
>>>>> This will lead to the situation of one platform device disabling
>>>>> MODULEMODE even though other platform devices need it.
>>>>>
>>>>> This may not be resolved in device tree either. We would need to have
>>>>> some use count mechanism for these bits, or attach MODULEMODE only to
>>>>> one platform device, and don't give others control to enable/disable it.
>>>>
>>>>
>>>> Hmm, are you sure? Not that I checked the code, but isn't MODULEMODE
>>>> mapped to a dss clock (was it "dss_clk")?. And so, the clock's refcount
>>>> should keep the MODULEMODE enabled/disabled?
>>>
>>>
>>> Yes, that's how we are currently dealing with it and making things work.
>>> We are forced to represent MODULEMODE as a clock. I forgot to mention
>>> that in the last mail :)
>>>
>>> However, other modules don't do this. modulemode control is taken care
>>> by hwmod by itself. We just have to fill the hwmod field
>>> '.prcm.omap4.modulemode' and get done with it. If we try this approach,
>>> we get into the trouble I mentioned before.
>>>
>>> We represent MODULEMODE as dss_fck, and make this the l3 slave clock for
>>> all DSS hwmods. This way, we ensure that it gets enabled, and we get a
>>> usecount associated to it. We shouldn't stick to this approach because:
>>>
>>> - It isn't exactly correct. MODULEMODE isn't a clock, and others don't
>>> do it.
>>
>>
>> Yes, fully agree. This was done like that as a hack to avoid any regression
>> because at that time we were not sure if that dependency will have to be
>> handled by the hwmod fmwk or by the driver.
>> Now, I'm sure it should not be handled by the hwmod fmwk :-)
>>
>>
>>> - DSS requires a particular sequence of disabling clocks to go into
>>> lower power states, and with the current approach, this doesn't happen.
>>> So, DSS doesn't idle, and that's the whole purpose of this :)
>>
>>
>> I'm just curious, what particular sequence is required?
>>
> IIRC, the main issue is the order in which functional clock and what
> is so called
> optional clock enabled ....
>
>
> While enabling the module
> 1. Enable optional clock
> 2. Enabled module mode.
>
> While disabling module
> 1. Disable module mode
> 2. Disable optional clock.
>
> I think only above sequence work. Not following above in either
> path leads to modules being stuck in transition.
>
> Is that right Archit ?
Yes. Also, this transition failure happens when DSS clock domain is set
to hardware supervised wakeup(HWAUTO).
The opt clock which requires this ordering with module mode is DSS_FCLK
by default. However, if some other clock (like DSI PLL, sourced by
SYS_CLK) is the source for DISPC_FCLK, then that clock is the one which
needs to be ordered with module mode.
Archit
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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] OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
From: Archit Taneja @ 2012-02-15 12:13 UTC (permalink / raw)
To: Cousson, Benoit; +Cc: Tomi Valkeinen, linux-omap, linux, linux-fbdev
In-Reply-To: <4F3A809E.3070508@ti.com>
On Tuesday 14 February 2012 09:11 PM, Cousson, Benoit wrote:
> On 2/14/2012 2:30 PM, Archit Taneja wrote:
>> Hi,
>>
>> On Tuesday 14 February 2012 06:45 PM, Tomi Valkeinen wrote:
>>> On Tue, 2012-02-14 at 13:58 +0100, Cousson, Benoit wrote:
>>>> Hi Tomi,
>>>
>>>>> Benoit, do you think we'll get the MODULEMODE mess cleaned up in the
>>>>> hwmod/clk framework at some point, and the drivers could do without
>>>>> these kinds of hacks? =)
>>>>
>>>> The best way to fix that for my point of view is to go to device tree
>>>> or/and to consider the DSS as the parent of all the DSS modules.
>>>> pm_runtime will then always ensure that the parent is enabled before
>>>> any
>>>> of the child are used.
>>>
>>> Ah, right. Sounds fine to me.
>>>
>>> But is that a proper "fix"? Are we sure the MODULEMODE will then always
>>> be handled correctly? Isn't the core problem still there, it just
>>> doesn't happen with the setup anymore?
>>>
>>> I mean, if we have these special requirements regarding MODULEMODE, and
>>> the code doesn't really know about it, would it get broken easily with
>>> restructuring/changes?
>>>
>>> And no, I don't have any clear idea why/how it would break, but I have
>>> just gotten the impression that the MODULEMODE is not handled quite
>>> properly (and so we have these current problems), and having dss_core as
>>> the parent of other dss modules doesn't really fix that in any way.
>>
>> I agree with that.
>>
>> In the current approach, we have multiple platform devices for DSS, and
>> all of them belong to the same clock domain, and the clock domain has
>> just one MODULEMODE bit field.
>>
>> When shutting off a platform device(by calling pm_runtime_put()), hwmod
>> enables/disables MODULEMODE without taking into mind that other active
>> platform devices may still need it. So, for example, if we have 2
>> platform devices, say dss and dispc, and we have code like:
>>
>> dispc_foo()
>> {
>> pm_runtime_get(dispc_pdev);
>> ...
>> ...
>> pm_runtime_put(dispc_pdev);
>> }
>>
>> dss_foo()
>> {
>> pm_runtime_get(dss_pdev);
>> ...
>> ...
>> dispc_foo(); /* MODULEMODE off after this */
>> ...
>> ...
>> pm_runtime_put(dss_pdev);
>> }
>>
>> This will lead to the situation of one platform device disabling
>> MODULEMODE even though other platform devices need it.
>>
>> This may not be resolved in device tree either. We would need to have
>> some use count mechanism for these bits, or attach MODULEMODE only to
>> one platform device, and don't give others control to enable/disable it.
>
> And this is exactly what the pm_runtime will provide. The fmwk already
> handles reference counting.
> Moreover the dev->parent will increment the power.child_count and thus
> ensure that the parent is always enabled if at least one child is active.
>
> By initializing the dev->parent of each DSS modules to the dss_core, it
> will ensure that the power dependency is managed properly.
Yes, a parent/child relation will ensure the required dependencies. It
sounds good!
How do we take care of things in the meanwhile? With the current way of
representing modulemode as a slave clock, the disabling sequence gets
messed up. In arch/arm/mach-omap2/omap_hwmod.c:
static int _disable_clocks(struct omap_hwmod *oh)
{
...
disable mainclk;
disable slave clocks;
...
}
For DSS, mainclk is the DSS_FCLK opt clock, and slave clock is
modulemode bits. We need the opposite sequence to happen here to cleanly
disable DSS.
Any suggestions?
Thanks,
Archit
>
> Regards,
> Benoit
>
>
^ 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