* Re: [PATCH 08/16] OMAPFB: remove early mem alloc from old omapfb
From: Tony Lindgren @ 2012-02-22 18:09 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-9-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> arch/arm/plat-omap/fb.c contains code to alloc omapfb buffers at early
> boot time according to information given from the bootloader or board
> file.
>
> This code isn't currently used by any board, and is anyway something
> that the newer vram.c could handle. So remove the alloc code and in
> later patches make old omapfb driver use vram.c.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 12/16] OMAPFB: remove omapfb_set_platform_data()
From: Tony Lindgren @ 2012-02-22 18:09 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-13-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> omapfb_set_platform_data() is no longer used, so remove it.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 13/16] OMAP1: pass LCD config with omapfb_set_lcd_config()
From: Tony Lindgren @ 2012-02-22 18:10 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-14-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> LCD config for old omapfb driver is passed with OMAP_TAG_LCD from board
> files or from the bootloader. In an effort to remove OMAP_TAG_LCD, this
> patch adds omapfb_set_lcd_config() function that the board files can
> call to set the LCD config.
>
> This has the drawback that configuration can no longer come from the
> bootloader. Of the boards supported by the kernel, this should only
> affect N770 which depends on the data from the bootloader. This patch
> adds an LCD config for N770 to its board files, but that is most
> probably broken. Fixing this would need information about the HW setup
> in N770 boards.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 14/16] OMAP: Remove OMAP_TAG_LCD and OMAP_TAG_FBMEM
From: Tony Lindgren @ 2012-02-22 18:11 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-15-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> These tags are no longer used and can be removed.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 15/16] OMAP1: Remove unused LCD devices from board files
From: Tony Lindgren @ 2012-02-22 18:11 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-16-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> Some OMAP1 board files define LCD platform_devices, but there are no
> corresponding LCD drivers for those in the kernel. Thus remove these LCD
> devices.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 16/16] OMAPFB: remove remaining OMAP arch checks
From: Tony Lindgren @ 2012-02-22 18:11 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev, archit
In-Reply-To: <1327399231-20826-17-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120124 01:30]:
> Now that the old omapfb driver is only omap1 display driver, there's no
> need to check if the arch is omap1. This patch removes the few remaining
> checks for the arch.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
From: Tony Lindgren @ 2012-02-22 18:50 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, archit, linux-omap
In-Reply-To: <1329220343.1845.65.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120214 03:21]:
> 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.
Great, looks good to me. I've acked the arch/arm/*omap*/* patches.
There may be some trivial merge conflicts with the includes with
my cleanup branch for the io.h changes.
> > 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.
I think they should be:
conf->nreset_gpio = 13
conf->data_lines = 24
Regards,
Tony
^ permalink raw reply
* [PATCH 0/5] viafb misc patches
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
Hi all,
this is another patch series for viafb. 1 and 2 are fixes for
previous patch series; 3 and 4 are fixes for our VX900 support;
5 is a cleanup
Best regards,
Florian Tobias Schandinat
Florian Tobias Schandinat (5):
viafb: another workaround for OLPCs weird wiring
viafb: Fix bug in centering code
viafb: select HW scaling on VX900 for IGA2
viafb: fix IGA1 modesetting on VX900
viafb: LCD bpp cleanup
drivers/video/via/chip.h | 1 -
drivers/video/via/hw.c | 22 +++++++---------------
drivers/video/via/hw.h | 2 +-
drivers/video/via/lcd.c | 21 ++++++++-------------
drivers/video/via/viafbdev.c | 8 +++++---
5 files changed, 21 insertions(+), 33 deletions(-)
--
1.7.9
^ permalink raw reply
* [PATCH 1/5] viafb: another workaround for OLPCs weird wiring
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329936280.git.FlorianSchandinat@gmx.de>
On OLPC we must not touch this I2C bus or it will hang.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/viafbdev.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 4791165..9cfa92e 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -1752,8 +1752,10 @@ static void __devinit i2c_bus_probe(struct viafb_shared *shared)
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));
+ if (!machine_is_olpc()) {
+ 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");
}
--
1.7.9
^ permalink raw reply related
* [PATCH 2/5] viafb: Fix bug in centering code
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329936280.git.FlorianSchandinat@gmx.de>
Obviously this is a typo and although there were no effects observed
it's probably better to fix it.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index d35ced7..4d799c8 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1477,7 +1477,7 @@ static struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
timing.hor_sync_end = timing.hor_sync_start + var->hsync_len;
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.hor_blank_end = timing.hor_total - dx;
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;
--
1.7.9
^ permalink raw reply related
* [PATCH 3/5] viafb: select HW scaling on VX900 for IGA2
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat, stable
In-Reply-To: <cover.1329936280.git.FlorianSchandinat@gmx.de>
VX900 can do hardware scaling for both IGAs in contrast to previous
hardware which could do it only for IGA2. This patch ensures that
we set the parameter for IGA2 and not for IGA1. This fixes hardware
scaling on VX900 until we have the infrastructure to support it for
both IGAs.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: stable@vger.kernel.org
---
drivers/video/via/hw.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 4d799c8..e6e7a8f 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1805,6 +1805,7 @@ static void hw_init(void)
}
/* probably this should go to the scaling code one day */
+ via_write_reg_mask(VIACR, 0xFD, 0, 0x80); /* VX900 hw scale on IGA2 */
viafb_write_regx(scaling_parameters, ARRAY_SIZE(scaling_parameters));
/* Fill VPIT Parameters */
--
1.7.9
^ permalink raw reply related
* [PATCH 4/5] viafb: fix IGA1 modesetting on VX900
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat, stable
In-Reply-To: <cover.1329936280.git.FlorianSchandinat@gmx.de>
Even if the documentation calls this bit "Reserved" it has to be set
to 0 for correct modesetting on IGA1.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: stable@vger.kernel.org
---
drivers/video/via/hw.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index e6e7a8f..376af05 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1804,6 +1804,9 @@ static void hw_init(void)
break;
}
+ /* magic required on VX900 for correct modesetting on IGA1 */
+ via_write_reg_mask(VIACR, 0x45, 0x00, 0x01);
+
/* probably this should go to the scaling code one day */
via_write_reg_mask(VIACR, 0xFD, 0, 0x80); /* VX900 hw scale on IGA2 */
viafb_write_regx(scaling_parameters, ARRAY_SIZE(scaling_parameters));
--
1.7.9
^ permalink raw reply related
* [PATCH 5/5] viafb: LCD bpp cleanup
From: Florian Tobias Schandinat @ 2012-02-22 18:53 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-kernel, Florian Tobias Schandinat
In-Reply-To: <cover.1329936280.git.FlorianSchandinat@gmx.de>
This patch removes redundant bits per pixel information by using the
one storged in var directly. Simplifies code without any functional
changes.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/via/chip.h | 1 -
drivers/video/via/hw.c | 16 ++--------------
drivers/video/via/hw.h | 2 +-
drivers/video/via/lcd.c | 21 ++++++++-------------
drivers/video/via/viafbdev.c | 2 +-
5 files changed, 12 insertions(+), 30 deletions(-)
diff --git a/drivers/video/via/chip.h b/drivers/video/via/chip.h
index c2ecdb5..d32a507 100644
--- a/drivers/video/via/chip.h
+++ b/drivers/video/via/chip.h
@@ -146,7 +146,6 @@ struct tmds_setting_information {
struct lvds_setting_information {
int iga_path;
- int bpp;
int lcd_panel_hres;
int lcd_panel_vres;
int display_method;
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 376af05..411b7e9 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1529,9 +1529,6 @@ void viafb_update_device_setting(int hres, int vres, int bpp, int flag)
if (flag = 0) {
viaparinfo->tmds_setting_info->h_active = hres;
viaparinfo->tmds_setting_info->v_active = vres;
-
- viaparinfo->lvds_setting_info->bpp = bpp;
- viaparinfo->lvds_setting_info2->bpp = bpp;
} else {
if (viaparinfo->tmds_setting_info->iga_path = IGA2) {
@@ -1539,11 +1536,6 @@ 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->bpp = bpp;
-
- if (IGA2 = viaparinfo->lvds_setting_info2->iga_path)
- viaparinfo->lvds_setting_info2->bpp = bpp;
}
}
@@ -1838,7 +1830,7 @@ static void hw_init(void)
load_fix_bit_crtc_reg();
}
-int viafb_setmode(int video_bpp, int video_bpp1)
+int viafb_setmode(void)
{
int j, cxres = 0, cyres = 0;
int port;
@@ -1927,7 +1919,6 @@ int viafb_setmode(int video_bpp, int video_bpp1)
if (viafb_LCD_ON) {
if (viafb_SAMM_ON &&
(viaparinfo->lvds_setting_info->iga_path = IGA2)) {
- viaparinfo->lvds_setting_info->bpp = video_bpp1;
viafb_lcd_set_mode(&var2, cxres, cyres,
viaparinfo->lvds_setting_info,
&viaparinfo->chip_info->lvds_chip_info);
@@ -1937,7 +1928,6 @@ int viafb_setmode(int video_bpp, int video_bpp1)
viaparinfo->lvds_setting_info->display_method LCD_CENTERING;
}
- viaparinfo->lvds_setting_info->bpp = video_bpp;
viafb_lcd_set_mode(&viafbinfo->var, 0, 0,
viaparinfo->lvds_setting_info,
&viaparinfo->chip_info->lvds_chip_info);
@@ -1946,7 +1936,6 @@ int viafb_setmode(int video_bpp, int video_bpp1)
if (viafb_LCD2_ON) {
if (viafb_SAMM_ON &&
(viaparinfo->lvds_setting_info2->iga_path = IGA2)) {
- viaparinfo->lvds_setting_info2->bpp = video_bpp1;
viafb_lcd_set_mode(&var2, cxres, cyres,
viaparinfo->lvds_setting_info2,
&viaparinfo->chip_info->lvds_chip_info2);
@@ -1956,7 +1945,6 @@ int viafb_setmode(int video_bpp, int video_bpp1)
viaparinfo->lvds_setting_info2->display_method LCD_CENTERING;
}
- viaparinfo->lvds_setting_info2->bpp = video_bpp;
viafb_lcd_set_mode(&viafbinfo->var, 0, 0,
viaparinfo->lvds_setting_info2,
&viaparinfo->chip_info->lvds_chip_info2);
@@ -1971,7 +1959,7 @@ int viafb_setmode(int video_bpp, int video_bpp1)
if (!viafb_hotplug) {
viafb_hotplug_Xres = viafbinfo->var.xres;
viafb_hotplug_Yres = viafbinfo->var.yres;
- viafb_hotplug_bpp = video_bpp;
+ viafb_hotplug_bpp = viafbinfo->var.bits_per_pixel;
viafb_hotplug_refresh = viafb_refresh;
if (viafb_DVI_ON)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index f8129e4..cacedc1 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -658,7 +658,7 @@ void viafb_load_FIFO_reg(int set_iga, int hor_active, int ver_active);
void viafb_set_dpa_gfx(int output_interface, struct GFX_DPA_SETTING\
*p_gfx_dpa_setting);
-int viafb_setmode(int video_bpp, int video_bpp1);
+int viafb_setmode(void);
void viafb_fill_var_timing_info(struct fb_var_screeninfo *var,
struct crt_mode_table *mode);
void __devinit viafb_init_chip_info(int chip_type);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 02cfdc8..6e52711 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -53,9 +53,6 @@ static void __devinit fp_id_to_vindex(int panel_id);
static int lvds_register_read(int index);
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, int hres);
static void lcd_patch_skew_dvp0(struct lvds_setting_information
*plvds_setting_info,
struct lvds_chip_information *plvds_chip_info);
@@ -453,19 +450,17 @@ 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, int hres)
+static void via_pitch_alignment_patch_lcd(int iga_path, int hres, int bpp)
{
unsigned char cr13, cr35, cr65, cr66, cr67;
unsigned long dwScreenPitch = 0;
unsigned long dwPitch;
- dwPitch = hres * (plvds_setting_info->bpp >> 3);
+ dwPitch = hres * (bpp >> 3);
if (dwPitch & 0x1F) {
dwScreenPitch = ((dwPitch + 31) & ~31) >> 3;
- if (plvds_setting_info->iga_path = IGA2) {
- if (plvds_setting_info->bpp > 8) {
+ if (iga_path = IGA2) {
+ if (bpp > 8) {
cr66 = (unsigned char)(dwScreenPitch & 0xFF);
viafb_write_reg(CR66, VIACR, cr66);
cr67 = viafb_read_reg(VIACR, CR67) & 0xFC;
@@ -483,7 +478,7 @@ static void via_pitch_alignment_patch_lcd(
cr65 += 2;
viafb_write_reg(CR65, VIACR, cr65);
} else {
- if (plvds_setting_info->bpp > 8) {
+ if (bpp > 8) {
cr13 = (unsigned char)(dwScreenPitch & 0xFF);
viafb_write_reg(CR13, VIACR, cr13);
cr35 = viafb_read_reg(VIACR, CR35) & 0x1F;
@@ -551,7 +546,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres,
struct lvds_chip_information *plvds_chip_info)
{
int set_iga = plvds_setting_info->iga_path;
- int mode_bpp = plvds_setting_info->bpp;
+ int mode_bpp = var->bits_per_pixel;
int set_hres = cxres ? cxres : var->xres;
int set_vres = cyres ? cyres : var->yres;
int panel_hres = plvds_setting_info->lcd_panel_hres;
@@ -612,8 +607,8 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres,
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,
- set_hres);
+ via_pitch_alignment_patch_lcd(plvds_setting_info->iga_path, set_hres,
+ var->bits_per_pixel);
}
static void integrated_lvds_disable(struct lvds_setting_information
diff --git a/drivers/video/via/viafbdev.c b/drivers/video/via/viafbdev.c
index 9cfa92e..7529340 100644
--- a/drivers/video/via/viafbdev.c
+++ b/drivers/video/via/viafbdev.c
@@ -303,7 +303,7 @@ static int viafb_set_par(struct fb_info *info)
info->flags &= ~FBINFO_HWACCEL_DISABLED;
else
info->flags |= FBINFO_HWACCEL_DISABLED;
- viafb_setmode(info->var.bits_per_pixel, viafb_bpp1);
+ viafb_setmode();
viafb_pan_display(&info->var, info);
}
--
1.7.9
^ permalink raw reply related
* Re: [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
From: Tony Lindgren @ 2012-02-22 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1329898441.2070.10.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120221 23:42]:
> On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> > Drivers should no longer use omap_read/write functions
> > but instead use ioremap + read/write functions.
> >
> > As some USB legacy code is still shared between omap1 and
> > omap2420, let's limit the omap_read/write to plat/usb.h.
> >
> > Also, let's make drivers/video/omap/lcdc.c depend on
> > ARCH_OMAP1 as it is not needed for omap2+.
>
> I'm ok with the lcdc.c change, but I also have a patch series that makes
> the same change, plus removes the omap2 code from drivers/video/omap/.
OK, I'll drop the lcdc.c change from my series as that should
only affect randconfig builds.
> Can you check the series, and give ack if the arch/arm side looks fine?
> It's this one: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
Yeah great, I've acked those. Let's do a test merge when I
have these in cleanup branch, looks like the conflicts should
be trivial.
Tony
^ permalink raw reply
* Re: [PATCH 1/8] ARM: OMAP2+: Move DISPC L3 firewall to happen in omap_display_init()
From: Tony Lindgren @ 2012-02-22 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1329898191.2070.6.camel@deskari>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [120221 23:38]:
> Hi,
>
> On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> > Otherwise we cannot move most of plat/io.h to be a local
> > iomap.h for mach-omap2.
> >
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: linux-fbdev@vger.kernel.org
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > arch/arm/mach-omap2/display.c | 3 +++
> > drivers/video/omap2/dss/dispc.c | 5 -----
> > 2 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> > index 3677b1f..5a7f12f 100644
> > --- a/arch/arm/mach-omap2/display.c
> > +++ b/arch/arm/mach-omap2/display.c
> > @@ -191,6 +191,9 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> > memset(&pdata, 0, sizeof(pdata));
> >
> > if (cpu_is_omap24xx()) {
> > + /* L3 firewall setting: enable access to OCM RAM */
> > + __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
> > +
> > curr_dss_hwmod = omap2_dss_hwmod_data;
> > oh_count = ARRAY_SIZE(omap2_dss_hwmod_data);
> > } else if (cpu_is_omap34xx()) {
> > diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> > index e1626a1..cce0820 100644
> > --- a/drivers/video/omap2/dss/dispc.c
> > +++ b/drivers/video/omap2/dss/dispc.c
> > @@ -3272,11 +3272,6 @@ static void _omap_dispc_initial_config(void)
> > if (dss_has_feature(FEAT_FUNCGATED))
> > REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
> >
> > - /* L3 firewall setting: enable access to OCM RAM */
> > - /* XXX this should be somewhere in plat-omap */
> > - if (cpu_is_omap24xx())
> > - __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
> > -
> > _dispc_setup_color_conv_coef();
> >
> > dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
> >
>
> I think the whole raw_writel line can be removed. It's been copied from
> the old omapfb, and my understanding is that it's about using SRAM for
> framebuffer. Using SRAM for fb is no longer supported, and I have a
> patch set that removes the remaining SRAM code from omapfb/omapdss.
OK, I'll remove those from drivers/video/omap2/dss/dispc.c so this
series keeps building.
Tony
^ permalink raw reply
* Re: [PATCH 00/16] OMAPDSS: old OMAPFB cleanup
From: Tony Lindgren @ 2012-02-22 22:09 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, archit, linux-omap
In-Reply-To: <20120222185016.GI18185@atomide.com>
* Tony Lindgren <tony@atomide.com> [120222 10:18]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [120214 03:21]:
> >
> > 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.
>
> I think they should be:
>
> conf->nreset_gpio = 13
> conf->data_lines = 24
Probably should be:
conf->nreset_gpio = 13
conf->data_lines = 16
No luck getting anything on the LCD though with
current kernel though.
Tony
^ permalink raw reply
* Re: [PATCH 1/8] ARM: OMAP2+: Move DISPC L3 firewall to happen in omap_display_init()
From: Tony Lindgren @ 2012-02-22 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120222190531.GK18185@atomide.com>
* Tony Lindgren <tony@atomide.com> [120222 10:34]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [120221 23:38]:
> > Hi,
> >
> > On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> > > Otherwise we cannot move most of plat/io.h to be a local
> > > iomap.h for mach-omap2.
> > >
> > > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > Cc: linux-fbdev@vger.kernel.org
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > ---
> > > arch/arm/mach-omap2/display.c | 3 +++
> > > drivers/video/omap2/dss/dispc.c | 5 -----
> > > 2 files changed, 3 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> > > index 3677b1f..5a7f12f 100644
> > > --- a/arch/arm/mach-omap2/display.c
> > > +++ b/arch/arm/mach-omap2/display.c
> > > @@ -191,6 +191,9 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
> > > memset(&pdata, 0, sizeof(pdata));
> > >
> > > if (cpu_is_omap24xx()) {
> > > + /* L3 firewall setting: enable access to OCM RAM */
> > > + __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
> > > +
> > > curr_dss_hwmod = omap2_dss_hwmod_data;
> > > oh_count = ARRAY_SIZE(omap2_dss_hwmod_data);
> > > } else if (cpu_is_omap34xx()) {
> > > diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> > > index e1626a1..cce0820 100644
> > > --- a/drivers/video/omap2/dss/dispc.c
> > > +++ b/drivers/video/omap2/dss/dispc.c
> > > @@ -3272,11 +3272,6 @@ static void _omap_dispc_initial_config(void)
> > > if (dss_has_feature(FEAT_FUNCGATED))
> > > REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
> > >
> > > - /* L3 firewall setting: enable access to OCM RAM */
> > > - /* XXX this should be somewhere in plat-omap */
> > > - if (cpu_is_omap24xx())
> > > - __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
> > > -
> > > _dispc_setup_color_conv_coef();
> > >
> > > dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
> > >
> >
> > I think the whole raw_writel line can be removed. It's been copied from
> > the old omapfb, and my understanding is that it's about using SRAM for
> > framebuffer. Using SRAM for fb is no longer supported, and I have a
> > patch set that removes the remaining SRAM code from omapfb/omapdss.
>
> OK, I'll remove those from drivers/video/omap2/dss/dispc.c so this
> series keeps building.
Here's this one updated.
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 20 Feb 2012 12:55:07 -0800
Subject: [PATCH] ARM: OMAP2+: Drop DISPC L3 firewall code
This is only needed when using SRAM for framebuffer,
and the support for SRAM framebuffer is about to get
removed.
Otherwise we cannot move most of plat/io.h to be a local
iomap.h for mach-omap2.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3272,11 +3272,6 @@ static void _omap_dispc_initial_config(void)
if (dss_has_feature(FEAT_FUNCGATED))
REG_FLD_MOD(DISPC_CONFIG, 1, 9, 9);
- /* L3 firewall setting: enable access to OCM RAM */
- /* XXX this should be somewhere in plat-omap */
- if (cpu_is_omap24xx())
- __raw_writel(0x402000b0, OMAP2_L3_IO_ADDRESS(0x680050a0));
-
_dispc_setup_color_conv_coef();
dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
^ permalink raw reply
* Re: [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
From: Tony Lindgren @ 2012-02-22 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120222185728.GJ18185@atomide.com>
* Tony Lindgren <tony@atomide.com> [120222 10:27]:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [120221 23:42]:
> > On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> > > Drivers should no longer use omap_read/write functions
> > > but instead use ioremap + read/write functions.
> > >
> > > As some USB legacy code is still shared between omap1 and
> > > omap2420, let's limit the omap_read/write to plat/usb.h.
> > >
> > > Also, let's make drivers/video/omap/lcdc.c depend on
> > > ARCH_OMAP1 as it is not needed for omap2+.
> >
> > I'm ok with the lcdc.c change, but I also have a patch series that makes
> > the same change, plus removes the omap2 code from drivers/video/omap/.
>
> OK, I'll drop the lcdc.c change from my series as that should
> only affect randconfig builds.
Here's this one updated. Noticed one more legacy driver
that needs omap_read/write defined to build on 2420.
Regards,
Tony
Date: Tue, 21 Feb 2012 13:27:33 -0800
Subject: [PATCH] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.
As some USB legacy code is still shared between omap1 and
omap2420, let's limit the omap_read/write to plat/usb.h.
Note that the long term fix is to update the drivers to
use ioremap and read/write functions. That can now be
done as a separate patch series that is limited to the
USB drivers.
Also make sure the legacy omap1-keypad.c driver builds
if selected for 2420 based systems.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 09ca9e9..f78ec4e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -242,15 +242,5 @@ struct omap_sdrc_params;
extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
-/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
- */
-extern u8 omap_readb(u32 pa);
-extern u16 omap_readw(u32 pa);
-extern u32 omap_readl(u32 pa);
-extern void omap_writeb(u8 v, u32 pa);
-extern void omap_writew(u16 v, u32 pa);
-extern void omap_writel(u32 v, u32 pa);
-
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 0119807..3203128 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -487,43 +487,3 @@ void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
_omap2_init_reprogram_sdrc();
}
}
-
-/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
- */
-
-u8 omap_readb(u32 pa)
-{
- return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readb);
-
-u16 omap_readw(u32 pa)
-{
- return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readw);
-
-u32 omap_readl(u32 pa)
-{
- return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readl);
-
-void omap_writeb(u8 v, u32 pa)
-{
- __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writeb);
-
-void omap_writew(u16 v, u32 pa)
-{
- __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writew);
-
-void omap_writel(u32 v, u32 pa)
-{
- __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writel);
diff --git a/arch/arm/plat-omap/include/plat/keypad.h b/arch/arm/plat-omap/include/plat/keypad.h
index 793ce9d..4b35555 100644
--- a/arch/arm/plat-omap/include/plat/keypad.h
+++ b/arch/arm/plat-omap/include/plat/keypad.h
@@ -12,6 +12,8 @@
#ifndef CONFIG_ARCH_OMAP1
#warning Please update the board to use matrix-keypad driver
+#define omap_readw(reg) 0
+#define omap_writew(val, reg) do {} while(0)
#endif
#include <linux/input/matrix_keypad.h>
diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
index dc864b5..5f6ced4 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -3,6 +3,7 @@
#ifndef __ASM_ARCH_OMAP_USB_H
#define __ASM_ARCH_OMAP_USB_H
+#include <linux/io.h>
#include <linux/usb/musb.h>
#include <plat/board.h>
@@ -105,6 +106,45 @@ extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
extern int omap4430_phy_suspend(struct device *dev, int suspend);
+
+/*
+ * NOTE: Please update omap USB drivers to use ioremap + read/write
+ */
+
+#define OMAP2_L4_IO_OFFSET 0xb2000000
+#define OMAP2_L4_IO_ADDRESS(pa) IOMEM((pa) + OMAP2_L4_IO_OFFSET)
+
+static inline u8 omap_readb(u32 pa)
+{
+ return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline u16 omap_readw(u32 pa)
+{
+ return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline u32 omap_readl(u32 pa)
+{
+ return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline void omap_writeb(u8 v, u32 pa)
+{
+ __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+
+
+static inline void omap_writew(u16 v, u32 pa)
+{
+ __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline void omap_writel(u32 v, u32 pa)
+{
+ __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+
#endif
extern void am35x_musb_reset(void);
^ permalink raw reply related
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Alan Cox @ 2012-02-23 0:15 UTC (permalink / raw)
To: Clark, Rob
Cc: Chris Wilson, Tomasz Stanislawski, linux-fbdev, Sakari Ailus,
Pawel Osciak, Marcus Lorentzon, Magnus Damm, dri-devel,
Alexander Deucher, linux-media, Marek Szyprowski
In-Reply-To: <CAO8GWqnVLfu5p3yNbE-BNqXfUu=2JX3S82GoJFS1baRwV126pQ@mail.gmail.com>
> and when doing 2d accel on a 3d core.. it basically amounts to
> putting a shader compiler in the kernel. Wheeee!
What I did for the GMA500 is to use the GTT to do scrolling by rewriting
the framebuffer GTT tables so they work as a circular buffer and doing a
bit of alignment of buffers.
The end result is faster than most accelerated 2D scrolls unsurprisingly.
Even faster would be to map enough of the start of the object on the end
of the range in repeat and just roll the frame buffer base. That would
get it down to a couple of 32bit I/O writes..
Alan
^ permalink raw reply
* Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
From: Michel Dänzer @ 2012-02-23 7:34 UTC (permalink / raw)
To: Rob Clark
Cc: Tomasz Stanislawski, linux-fbdev, Sakari Ailus, Pawel Osciak,
Marcus Lorentzon, Magnus Damm, dri-devel, Alexander Deucher,
linux-media, Marek Szyprowski
In-Reply-To: <CAF6AEGs5iNbZB5SOcGWkvQu4Yh98KbWWkWkv3mS_noA76utExw@mail.gmail.com>
On Mit, 2012-02-22 at 10:28 -0600, Rob Clark wrote:
> On Wed, Feb 22, 2012 at 10:24 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote:
> >>
> >> > > Imo we should ditch this - fb accel doesn't belong into the kernel. Even
> >> > > on hw that still has a blitter for easy 2d accel without a complete 3d
> >> > > state setup necessary, it's not worth it. Chris Wilson from our team once
> >> > > played around with implementing fb accel in the kernel (i915 hw still has
> >> > > a blitter engine in the latest generations). He quickly noticed that to
> >> > > have decent speed, competitive with s/w rendering by the cpu he needs the
> >> > > entire batch and buffer management stuff from userspace. And to really
> >> > > beat the cpu, you need even more magic.
> >> > >
> >> > > If you want fast 2d accel, use something like cairo.
> >> >
> >> > Our conclusion on this is that we should not expose an explicit 2D
> >> > acceleration API at the kernel level. If really needed, hardware 2D
> >> > acceleration could be implemented as a DRM device to handle memory management,
> >> > commands ring setup, synchronization, ... but I'm not even sure if that's
> >> > worth it. I might not have conveyed it well in my notes.
> >>
> >> Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
> >> possible accels; copyarea, imageblit, and fillrect. The first two could be
> >> hooked from the TTM layer. Its something I plan to experiment to see if
> >> its worth it.
> >
> > Let's bite into this ;-) I know that fbcon scrolling totally sucks on big
> > screens, but I also think it's a total waste of time to fix this. Imo
> > fbcon has 2 use-cases:
> > - display an OOSP.
> > - allow me to run fsck (or any other desaster-recovery stuff).
> >
> > It can do that quite fine already.
>
> and for just fbcon scrolling, if you really wanted to you could
> implement it by just shuffling pages around in a GART..
Keep in mind there are still discrete GPUs :), where scanning out from
anything but VRAM may not be feasible, and direct CPU access to
(especially reads from) VRAM tends to be very slow.
However, for fbcon that can be addressed in each driver (as is done e.g.
in nouveau), and has nothing to do with any userspace interface.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* [PATCH] udlfb: Fix invalid return codes in edid sysfs entry store function
From: Olivier Sobrie @ 2012-02-23 7:53 UTC (permalink / raw)
To: linux-fbdev
Return a negative errno instead of zero in the write function of
the sysfs entry in case of error.
Also add a check on the return value of dlfb_setup_modes().
Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
---
drivers/video/udlfb.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index a197731..abbc3fe 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1427,19 +1427,22 @@ static ssize_t edid_store(
struct device *fbdev = container_of(kobj, struct device, kobj);
struct fb_info *fb_info = dev_get_drvdata(fbdev);
struct dlfb_data *dev = fb_info->par;
+ int ret;
/* We only support write of entire EDID at once, no offset*/
if ((src_size != EDID_LENGTH) || (src_off != 0))
- return 0;
+ return -EINVAL;
- dlfb_setup_modes(dev, fb_info, src, src_size);
+ ret = dlfb_setup_modes(dev, fb_info, src, src_size);
+ if (ret)
+ return ret;
if (dev->edid && (memcmp(src, dev->edid, src_size) = 0)) {
pr_info("sysfs written EDID is new default\n");
dlfb_ops_set_par(fb_info);
return src_size;
} else
- return 0;
+ return -EINVAL;
}
static ssize_t metrics_reset_store(struct device *fbdev,
--
1.7.5.4
^ permalink raw reply related
* [GIT PULL] OMAP DSS fixes for 3.3-rc
From: Tomi Valkeinen @ 2012-02-23 9:22 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev@vger.kernel.org, linux-omap mailing list
In-Reply-To: <1327579651.1895.34.camel@deskari>
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]
Hi Florian,
Two fixes for OMAP DSS for 3.3:
First one gets the HDMI output working again. Managing the clocks for
OMAP4 is not very simple, and this patch circumvents the problems we
have in the clock framework. It's a clean but rather hacky fix, but it
shouldn't cause any side-effects. The issue will hopefully be fixed
properly with DT when we'll get proper parent-child hierarchy for DSS HW
submodules.
The second one is a simple fix for HDMI hotplug detection, which I
missed when I wrote the HDMI PHY fix
(c49d005b6cc8491fad5b24f82805be2d6bcbd3dd).
Tomi
The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d:
Linux 3.3-rc3 (2012-02-08 19:21:53 -0800)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-3.3-rc
Archit Taneja (1):
OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled
Rob Clark (1):
OMAPDSS: HDMI: hot plug detect fix
drivers/video/omap2/dss/hdmi.c | 24 +++++++++++++++++++++++-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 9 +--------
2 files changed, 24 insertions(+), 9 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 8/8] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
From: Tony Lindgren @ 2012-02-24 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120222224411.GO18185@atomide.com>
* Tony Lindgren <tony@atomide.com> [120222 14:13]:
> * Tony Lindgren <tony@atomide.com> [120222 10:27]:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [120221 23:42]:
> > > On Tue, 2012-02-21 at 15:40 -0800, Tony Lindgren wrote:
> > > > Drivers should no longer use omap_read/write functions
> > > > but instead use ioremap + read/write functions.
> > > >
> > > > As some USB legacy code is still shared between omap1 and
> > > > omap2420, let's limit the omap_read/write to plat/usb.h.
> > > >
> > > > Also, let's make drivers/video/omap/lcdc.c depend on
> > > > ARCH_OMAP1 as it is not needed for omap2+.
> > >
> > > I'm ok with the lcdc.c change, but I also have a patch series that makes
> > > the same change, plus removes the omap2 code from drivers/video/omap/.
> >
> > OK, I'll drop the lcdc.c change from my series as that should
> > only affect randconfig builds.
>
> Here's this one updated. Noticed one more legacy driver
> that needs omap_read/write defined to build on 2420.
This one needed some updates for usb.h after updating patch 7/8
in this series. Updated patch below.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 22 Feb 2012 14:52:41 -0800
Subject: [PATCH] ARM: OMAP2+: Limit omap_read/write usage to legacy USB drivers
Drivers should no longer use omap_read/write functions
but instead use ioremap + read/write functions.
As some USB legacy code is still shared between omap1 and
omap2420, let's limit the omap_read/write to plat/usb.h.
Note that the long term fix is to update the drivers to
use ioremap and read/write functions. That can now be
done as a separate patch series that is limited to the
USB drivers.
Also make sure the legacy omap1-keypad.c driver builds
if selected for 2420 based systems.
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 09ca9e9..f78ec4e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -242,15 +242,5 @@ struct omap_sdrc_params;
extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
-/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
- */
-extern u8 omap_readb(u32 pa);
-extern u16 omap_readw(u32 pa);
-extern u32 omap_readl(u32 pa);
-extern void omap_writeb(u8 v, u32 pa);
-extern void omap_writew(u16 v, u32 pa);
-extern void omap_writel(u32 v, u32 pa);
-
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 0119807..3203128 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -487,43 +487,3 @@ void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
_omap2_init_reprogram_sdrc();
}
}
-
-/*
- * NOTE: Please use ioremap + __raw_read/write where possible instead of these
- */
-
-u8 omap_readb(u32 pa)
-{
- return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readb);
-
-u16 omap_readw(u32 pa)
-{
- return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readw);
-
-u32 omap_readl(u32 pa)
-{
- return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_readl);
-
-void omap_writeb(u8 v, u32 pa)
-{
- __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writeb);
-
-void omap_writew(u16 v, u32 pa)
-{
- __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writew);
-
-void omap_writel(u32 v, u32 pa)
-{
- __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
-}
-EXPORT_SYMBOL(omap_writel);
diff --git a/arch/arm/plat-omap/include/plat/keypad.h b/arch/arm/plat-omap/include/plat/keypad.h
index 793ce9d..a6b21ed 100644
--- a/arch/arm/plat-omap/include/plat/keypad.h
+++ b/arch/arm/plat-omap/include/plat/keypad.h
@@ -12,6 +12,8 @@
#ifndef CONFIG_ARCH_OMAP1
#warning Please update the board to use matrix-keypad driver
+#define omap_readw(reg) 0
+#define omap_writew(val, reg) do {} while (0)
#endif
#include <linux/input/matrix_keypad.h>
diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
index dc864b5..d0fc9f4 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -3,6 +3,7 @@
#ifndef __ASM_ARCH_OMAP_USB_H
#define __ASM_ARCH_OMAP_USB_H
+#include <linux/io.h>
#include <linux/usb/musb.h>
#include <plat/board.h>
@@ -105,6 +106,46 @@ extern int omap4430_phy_set_clk(struct device *dev, int on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
extern int omap4430_phy_suspend(struct device *dev, int suspend);
+
+/*
+ * NOTE: Please update omap USB drivers to use ioremap + read/write
+ */
+
+#define OMAP2_L4_IO_OFFSET 0xb2000000
+#define IOMEM(x) ((void __force __iomem *)(x))
+#define OMAP2_L4_IO_ADDRESS(pa) IOMEM((pa) + OMAP2_L4_IO_OFFSET)
+
+static inline u8 omap_readb(u32 pa)
+{
+ return __raw_readb(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline u16 omap_readw(u32 pa)
+{
+ return __raw_readw(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline u32 omap_readl(u32 pa)
+{
+ return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline void omap_writeb(u8 v, u32 pa)
+{
+ __raw_writeb(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+
+
+static inline void omap_writew(u16 v, u32 pa)
+{
+ __raw_writew(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+
+static inline void omap_writel(u32 v, u32 pa)
+{
+ __raw_writel(v, OMAP2_L4_IO_ADDRESS(pa));
+}
+
#endif
extern void am35x_musb_reset(void);
^ permalink raw reply related
* [PATCH] pxafb: do console locking before calling fb_blank()
From: Vasily Khoruzhick @ 2012-02-26 13:52 UTC (permalink / raw)
To: linux-arm-kernel
Otherwise we hit WARN_CONSOLE_UNLOCKED in do_unblank_screen
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
drivers/video/pxafb.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 1d1e4f1..c176561 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -54,6 +54,7 @@
#include <linux/mutex.h>
#include <linux/kthread.h>
#include <linux/freezer.h>
+#include <linux/console.h>
#include <mach/hardware.h>
#include <asm/io.h>
@@ -730,9 +731,12 @@ static int overlayfb_open(struct fb_info *info, int user)
if (user = 0)
return -ENODEV;
- if (ofb->usage++ = 0)
+ if (ofb->usage++ = 0) {
/* unblank the base framebuffer */
+ console_lock();
fb_blank(&ofb->fbi->fb, FB_BLANK_UNBLANK);
+ console_unlock();
+ }
return 0;
}
--
1.7.9.2
^ permalink raw reply related
* [PATCH] [trivial] radeon: Fix typo in radeon_gem.c
From: Masanari Iida @ 2012-02-27 14:28 UTC (permalink / raw)
To: benh, linux-fbdev; +Cc: trivial, linux-kernel, Masanari Iida
Correct spelling "withou" to "without" in
drivers/gpu/drm/radeon/radeon_gem.c
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
index 7337850..ff4ff23 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -117,7 +117,7 @@ int radeon_gem_set_domain(struct drm_gem_object *gobj,
}
if (!domain) {
/* Do nothings */
- printk(KERN_WARNING "Set domain withou domain !\n");
+ printk(KERN_WARNING "Set domain without domain !\n");
return 0;
}
if (domain = RADEON_GEM_DOMAIN_CPU) {
--
1.7.9.2.262.gba998
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox