* Re: [PATCH] video: mxsfb: fix color settings for 18bit data bus and 32bpp
From: maxime.ripard @ 2013-06-07 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51B1957F.40104@digi.com>
Hi Hector,
On Fri, Jun 07, 2013 at 10:10:39AM +0200, Hector Palacios wrote:
> For a combination of 18bit LCD data bus width and a color
> mode of 32bpp, the driver was setting the color mapping to
> rgb666, which is wrong, as the color in memory realy has an
> rgb888 layout.
>
> This patch also removes the setting of flag CTRL_DF24 that
> makes the driver dimiss the upper 2 bits when handling 32/24bpp
> colors in a diplay with 18bit data bus width. This flag made
> true color images display wrong in such configurations.
>
> Finally, the color mapping rgb666 has also been removed as nobody
> is using it and high level applications like Qt5 cannot work
> with it either.
>
> Reference: https://lkml.org/lkml/2013/5/23/220
> Signed-off-by: Hector Palacios <hector.palacios@digi.com>
> Acked-by: Juergen Beisert <jbe@pengutronix.de>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Please also note that fbdev is now maintained by Jean Christophe
Plagniol-Villard (plagnioj@jcrosoft.com, in CC), and that he is away
until the 10th of June, so maybe it should be safe to resend it to him
after this date.
Thanks!
Maxime
^ permalink raw reply
* Re: [PATCH 15/32] OMAPDSS: DPI: cleanup pll & regulator init
From: Tomi Valkeinen @ 2013-06-07 8:45 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <51B182F7.7050002@ti.com>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
On 07/06/13 09:51, Archit Taneja wrote:
>> -static int dpi_init_display(struct omap_dss_device *dssdev)
>> -{
>> - struct platform_device *dsidev;
>> -
>> - DSSDBG("init_display\n");
>> -
>> - if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
>> - dpi.vdds_dsi_reg == NULL) {
>> - struct regulator *vdds_dsi;
>> -
>> - vdds_dsi = dss_get_vdds_dsi();
>> - if (IS_ERR(vdds_dsi)) {
>> - vdds_dsi = regulator_get(&dpi.pdev->dev, "vdds_dsi");
>
> same comment about devm_ usage here, and the next few patches.
Yes, good point. And that allows us to get rid of the 'vdds_dsi_from_core'.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 19/32] OMAPDSS: add videomode conversion support
From: Tomi Valkeinen @ 2013-06-07 8:35 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <51B18687.6000602@ti.com>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On 07/06/13 10:06, Archit Taneja wrote:
> On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
>> Add helper functions to convert between omapdss specific video timings
>> and the common videomode.
>>
>> Eventually omapdss will be changed to use only the common video timings,
>> and these helper functions will make the transition easier.
>
> So we now use omap_video_timings, videomode, drm_display_mode, and
> fb_var_screeninfo, fun! :)
Yes, although videomode is only used when passing videomode from the
board file. I wanted to make that right from the start.
omap_video_timings is still used everywhere else in omapdss.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [RFC 00/50] ARM: at91: move to common clk framework
From: Boris BREZILLON @ 2013-06-07 8:34 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This patch series is a proposal to move at91 clock implementation
to common clk framework.
Most of the clock provided by the PMC (Power Management Controller) are
implemented :
- main clock (main oscillator)
- pll clocks
- master clock
- programmable clocks
- utmi clock
- peripheral clocks
- system clocks
This implementation is compatible with device tree: the goal is
to define the whole clock tree in the device tree (all currently
available dt SoCs and boards are patched to support dt clocks).
Please feel free to comment the dt bindinds (I'm not sure about the
name I choose or the position of clock nodes: children of pmc node).
I removed the register_clocks function in SoC supporting dt boards only:
- at91sam9x5 SoCs
- at91sam9n12 SoC
- sama5d3 SoCs
This patch series also update at91 drivers calling clk_enable/disable
instead of the preferred clk_prepare_enable/disable_unprepare functions.
I know there are a lot of cleanup in progress for at91 arch, so please tell
me if you think this transition to common clk framework should wait.
This patch series has been tested on Kizbox (sam9g20 SoC) board using device
tree. It compiles for other SoCs and both with and without dt support, but it
has not been tested.
The clocks rate/parent change has not been tested.
Best Regards,
Boris
Boris BREZILLON (50):
ARM: at91: move arch/arm/mach-at91/include/mach/at91_pmc.h to
include/linux/clk/at91.h
ARM: at91: add PMC main clock using common clk framework.
ARM: at91: add PMC pll clocks support using common clk framework.
ARM: at91: add PMC master clock support using common clk framework.
ARM: at91: add PMC system clocks support using common clk framework.
ARM: at91: add PMC peripheral clocks support using common clk
framework.
ARM: at91: add PMC programmable clocks support using common clk
framework.
ARM: at91: add PMC utmi clock support using common clk framework.
ARM: at91: add PMC usb clock support using common clk framework.
ARM: at91: add PMC smd clock support using common clk framework.
ARM: at91: add PMC clk device tree binding doc.
ARM: at91: move to common clk framework.
ARM: at91: move at91rm9200 SoC to common clk framework.
ARM: at91: move at91sam9260 SoC to common clk framework.
ARM: at91: move at91sam9263 SoC to common clk framework.
ARM: at91: move at91sam9263 SoC to common clk framework.
ARM: at91: move at91sam9g45 SoC to common clk framework.
ARM: at91: move at91sam9n12 SoC to common clk framework.
ARM: at91: move at91sam9rl SoC to common clk framework.
ARM: at91: move at91sam9x5 SoCs to common clk framework.
ARM: at91: move at91sam9 SoCs to common clk framework.
ARM: at91: move sama5d3 SoCs to common clk framework.
ARM: at91: move at91rm9200 non dt boards to common clk framework.
ARM: at91: move at91sam9 non dt boards to common clk framework.
ARM: at91: move pit timer to common clk framework.
ARM: at91/tc/clocksource: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
at_hdmac: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
ASoC: atmel-ssc: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
mmc: atmel-mci: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
pwm: atmel-tcb: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
tty: atmel_serial: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
usb: gadget: at91_udc: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
drivers/usb/host/ehci-atmel.c: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
USB: ohci-at91: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
ARM: at91/avr32/atmel_lcdfb: replace clk_enable/disable with
clk_prepare_enable/disable_unprepare.
ARM: at91/dt: move at91rm9200 SoC to clk framework.
ARM: at91/dt: move at91sam9260 SoC to common clk framework.
ARM: at91/dt: move at91sam9263 SoC to common clk framework.
ARM: at91/dt: move at91sam9g45 SoC to common clk framework.
ARM: at91/dt: move at91sam9n12 SoC to common clk framework.
ARM: at91/dt: move at91sam9x5 SoCs to common clk framework.
ARM: at91/dt: move at91sam9g20 SoC to common clk framework.
ARM: at91/dt: move sama5d3 SoCs to common clk framework.
ARM: at91/dt: move at91sam9260/sam9g20 boards to common clk
framework.
ARM: at91/dt: move at91rm9200 boards to common clk framework.
ARM: at91/dt: move at91sam9263 boards to common clk framework.
ARM: at91/dt: move at91sam9g45 boards to common clk framework.
ARM: at91/dt: move at91sam9n12 boards to common clk framework.
ARM: at91/dt: move at91sam9x5 boards to common clk framework.
ARM: at91/dt: move sama5d3 boards to common clk framework.
.../devicetree/bindings/clock/at91-clock.txt | 247 +++++
arch/arm/boot/dts/animeo_ip.dts | 17 +-
arch/arm/boot/dts/at91-ariag25.dts | 17 +-
arch/arm/boot/dts/at91rm9200.dtsi | 133 +++
arch/arm/boot/dts/at91rm9200ek.dts | 17 +-
arch/arm/boot/dts/at91sam9260.dtsi | 144 ++-
arch/arm/boot/dts/at91sam9263.dtsi | 135 +++
arch/arm/boot/dts/at91sam9263ek.dts | 17 +-
arch/arm/boot/dts/at91sam9g15.dtsi | 11 +
arch/arm/boot/dts/at91sam9g20.dtsi | 37 +
arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 17 +-
arch/arm/boot/dts/at91sam9g25.dtsi | 3 +
arch/arm/boot/dts/at91sam9g35.dtsi | 23 +
arch/arm/boot/dts/at91sam9g45.dtsi | 157 ++++
arch/arm/boot/dts/at91sam9m10g45ek.dts | 17 +-
arch/arm/boot/dts/at91sam9n12.dtsi | 153 ++++
arch/arm/boot/dts/at91sam9n12ek.dts | 17 +-
arch/arm/boot/dts/at91sam9x25.dtsi | 25 +-
arch/arm/boot/dts/at91sam9x35.dtsi | 3 +
arch/arm/boot/dts/at91sam9x5.dtsi | 226 +++--
arch/arm/boot/dts/at91sam9x5_can.dtsi | 24 +
arch/arm/boot/dts/at91sam9x5_isi.dtsi | 24 +
arch/arm/boot/dts/at91sam9x5_lcdc.dtsi | 32 +
arch/arm/boot/dts/at91sam9x5_macb0.dtsi | 68 ++
arch/arm/boot/dts/at91sam9x5_macb1.dtsi | 56 ++
arch/arm/boot/dts/at91sam9x5_usart3.dtsi | 60 ++
arch/arm/boot/dts/ge863-pro3.dtsi | 16 +-
arch/arm/boot/dts/kizbox.dts | 5 +
arch/arm/boot/dts/mpa1600.dts | 16 +-
arch/arm/boot/dts/pm9g45.dts | 16 +-
arch/arm/boot/dts/sama5d3.dtsi | 358 ++++----
arch/arm/boot/dts/sama5d31ek.dts | 4 +
arch/arm/boot/dts/sama5d33ek.dts | 2 +
arch/arm/boot/dts/sama5d34ek.dts | 4 +
arch/arm/boot/dts/sama5d35ek.dts | 6 +
arch/arm/boot/dts/sama5d3_can.dtsi | 67 ++
arch/arm/boot/dts/sama5d3_emac.dtsi | 56 ++
arch/arm/boot/dts/sama5d3_gmac.dtsi | 89 ++
arch/arm/boot/dts/sama5d3_lcd.dtsi | 73 ++
arch/arm/boot/dts/sama5d3_mci2.dtsi | 59 ++
arch/arm/boot/dts/sama5d3_tcb1.dtsi | 39 +
arch/arm/boot/dts/sama5d3_uart.dtsi | 42 +
arch/arm/boot/dts/sama5d3xcm.dtsi | 17 +-
arch/arm/boot/dts/tny_a9260_common.dtsi | 17 +-
arch/arm/boot/dts/tny_a9263.dts | 17 +-
arch/arm/boot/dts/usb_a9260_common.dtsi | 17 +-
arch/arm/boot/dts/usb_a9263.dts | 17 +-
arch/arm/mach-at91/Kconfig | 26 +
arch/arm/mach-at91/Makefile | 2 +-
arch/arm/mach-at91/at91rm9200.c | 578 +++++++-----
arch/arm/mach-at91/at91sam9260.c | 694 +++++++++-----
arch/arm/mach-at91/at91sam9261.c | 581 ++++++++----
arch/arm/mach-at91/at91sam9263.c | 599 +++++++-----
arch/arm/mach-at91/at91sam926x_time.c | 21 +-
arch/arm/mach-at91/at91sam9g45.c | 705 ++++++++------
arch/arm/mach-at91/at91sam9g45_devices.c | 1 -
arch/arm/mach-at91/at91sam9n12.c | 196 +---
arch/arm/mach-at91/at91sam9rl.c | 514 +++++++----
arch/arm/mach-at91/at91sam9x5.c | 291 +-----
arch/arm/mach-at91/board-1arm.c | 12 +-
arch/arm/mach-at91/board-afeb-9260v1.c | 11 +-
arch/arm/mach-at91/board-cam60.c | 13 +-
arch/arm/mach-at91/board-carmeva.c | 13 +-
arch/arm/mach-at91/board-cpu9krea.c | 12 +-
arch/arm/mach-at91/board-cpuat91.c | 12 +-
arch/arm/mach-at91/board-csb337.c | 11 +-
arch/arm/mach-at91/board-csb637.c | 11 +-
arch/arm/mach-at91/board-dt-rm9200.c | 9 +-
arch/arm/mach-at91/board-dt-sam9.c | 9 +-
arch/arm/mach-at91/board-dt-sama5.c | 9 +-
arch/arm/mach-at91/board-eb9200.c | 11 +-
arch/arm/mach-at91/board-ecbat91.c | 12 +-
arch/arm/mach-at91/board-eco920.c | 13 +-
arch/arm/mach-at91/board-flexibity.c | 12 +-
arch/arm/mach-at91/board-foxg20.c | 12 +-
arch/arm/mach-at91/board-gsia18s.c | 8 +-
arch/arm/mach-at91/board-kafa.c | 12 +-
arch/arm/mach-at91/board-kb9202.c | 12 +-
arch/arm/mach-at91/board-pcontrol-g20.c | 9 +-
arch/arm/mach-at91/board-picotux200.c | 11 +-
arch/arm/mach-at91/board-qil-a9260.c | 11 +-
arch/arm/mach-at91/board-rm9200dk.c | 11 +-
arch/arm/mach-at91/board-rm9200ek.c | 11 +-
arch/arm/mach-at91/board-rsi-ews.c | 12 +-
arch/arm/mach-at91/board-sam9-l9260.c | 11 +-
arch/arm/mach-at91/board-sam9260ek.c | 11 +-
arch/arm/mach-at91/board-sam9261ek.c | 15 +-
arch/arm/mach-at91/board-sam9263ek.c | 11 +-
arch/arm/mach-at91/board-sam9g20ek.c | 15 +-
arch/arm/mach-at91/board-sam9m10g45ek.c | 11 +-
arch/arm/mach-at91/board-sam9rlek.c | 11 +-
arch/arm/mach-at91/board-snapper9260.c | 12 +-
arch/arm/mach-at91/board-stamp9g20.c | 15 +-
arch/arm/mach-at91/board-yl-9200.c | 12 +-
arch/arm/mach-at91/clock.c | 961 --------------------
arch/arm/mach-at91/clock.h | 49 -
arch/arm/mach-at91/generic.h | 10 +-
arch/arm/mach-at91/pm.c | 2 +-
arch/arm/mach-at91/pm_slowclock.S | 2 +-
arch/arm/mach-at91/pmc.c | 58 ++
arch/arm/mach-at91/sama5d3.c | 344 +------
arch/arm/mach-at91/setup.c | 38 +-
arch/arm/mach-at91/stamp9g20.h | 2 +-
drivers/clk/Makefile | 1 +
drivers/clk/at91/Makefile | 11 +
drivers/clk/at91/clk-main.c | 106 +++
drivers/clk/at91/clk-master.c | 317 +++++++
drivers/clk/at91/clk-peripheral.c | 376 ++++++++
drivers/clk/at91/clk-pll.c | 438 +++++++++
drivers/clk/at91/clk-plldiv.c | 125 +++
drivers/clk/at91/clk-programmable.c | 370 ++++++++
drivers/clk/at91/clk-smd.c | 157 ++++
drivers/clk/at91/clk-system.c | 189 ++++
drivers/clk/at91/clk-usb.c | 303 ++++++
drivers/clk/at91/clk-utmi.c | 114 +++
drivers/clocksource/tcb_clksrc.c | 10 +-
drivers/dma/at_hdmac.c | 12 +-
drivers/misc/atmel-ssc.c | 8 +-
drivers/mmc/host/atmel-mci.c | 16 +-
drivers/pwm/pwm-atmel-tcb.c | 4 +-
drivers/tty/serial/atmel_serial.c | 35 +-
drivers/usb/gadget/at91_udc.c | 12 +-
drivers/usb/gadget/atmel_usba_udc.c | 2 +-
drivers/usb/host/ehci-atmel.c | 8 +-
drivers/usb/host/ohci-at91.c | 12 +-
drivers/video/atmel_lcdfb.c | 8 +-
.../mach/at91_pmc.h => include/linux/clk/at91.h | 122 ++-
127 files changed, 7588 insertions(+), 3862 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/at91-clock.txt
create mode 100644 arch/arm/boot/dts/at91sam9x5_can.dtsi
create mode 100644 arch/arm/boot/dts/at91sam9x5_isi.dtsi
create mode 100644 arch/arm/boot/dts/at91sam9x5_lcdc.dtsi
create mode 100644 arch/arm/boot/dts/at91sam9x5_macb0.dtsi
create mode 100644 arch/arm/boot/dts/at91sam9x5_macb1.dtsi
create mode 100644 arch/arm/boot/dts/at91sam9x5_usart3.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3_can.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3_emac.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3_gmac.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3_lcd.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3_mci2.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3_tcb1.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3_uart.dtsi
delete mode 100644 arch/arm/mach-at91/clock.c
delete mode 100644 arch/arm/mach-at91/clock.h
create mode 100644 arch/arm/mach-at91/pmc.c
create mode 100644 drivers/clk/at91/Makefile
create mode 100644 drivers/clk/at91/clk-main.c
create mode 100644 drivers/clk/at91/clk-master.c
create mode 100644 drivers/clk/at91/clk-peripheral.c
create mode 100644 drivers/clk/at91/clk-pll.c
create mode 100644 drivers/clk/at91/clk-plldiv.c
create mode 100644 drivers/clk/at91/clk-programmable.c
create mode 100644 drivers/clk/at91/clk-smd.c
create mode 100644 drivers/clk/at91/clk-system.c
create mode 100644 drivers/clk/at91/clk-usb.c
create mode 100644 drivers/clk/at91/clk-utmi.c
rename arch/arm/mach-at91/include/mach/at91_pmc.h => include/linux/clk/at91.h (76%)
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH 12/32] OMAPDSS: Implement display (dis)connect support
From: Tomi Valkeinen @ 2013-06-07 8:31 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <51B181AC.3070400@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]
On 07/06/13 09:46, Archit Taneja wrote:
>> @@ -384,6 +424,10 @@ int omap_dss_register_driver(struct
>> omap_dss_driver *dssdriver)
>> omapdss_default_get_recommended_bpp;
>> if (dssdriver->get_timings == NULL)
>> dssdriver->get_timings = omapdss_default_get_timings;
>> + if (dssdriver->connect == NULL)
>> + dssdriver->connect = omapdss_default_connect;
>> + if (dssdriver->disconnect == NULL)
>> + dssdriver->disconnect = omapdss_default_disconnect;
>
> I was wondering if these should be apis rather than driver ops. One
> advantage of having them as functions used by omapfb/omapdrm would be
> that a panel driver wouldn't override the default_connect/disconnect ops.
>
> Even though they are named omapdss_default_connect/disconnect, I don't
> think there is another option by which a panel driver may chose to
> connect to omapdss outputs, right?
Those "default" functions are used only for the old panel drivers, and
are removed when the old drivers are not needed anymore. They allow us
to add the connect support without modifying the old drivers.
The new drivers may do other stuff in connect/disconnect. For example,
see panel-dsicm.c.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH] video: mxsfb: fix color settings for 18bit data bus and 32bpp
From: Hector Palacios @ 2013-06-07 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130607074200.GG14209@lukather>
For a combination of 18bit LCD data bus width and a color
mode of 32bpp, the driver was setting the color mapping to
rgb666, which is wrong, as the color in memory realy has an
rgb888 layout.
This patch also removes the setting of flag CTRL_DF24 that
makes the driver dimiss the upper 2 bits when handling 32/24bpp
colors in a diplay with 18bit data bus width. This flag made
true color images display wrong in such configurations.
Finally, the color mapping rgb666 has also been removed as nobody
is using it and high level applications like Qt5 cannot work
with it either.
Reference: https://lkml.org/lkml/2013/5/23/220
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Acked-by: Juergen Beisert <jbe@pengutronix.de>
---
drivers/video/mxsfb.c | 26 --------------------------
1 file changed, 26 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 21223d4..d2c5105 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -239,24 +239,6 @@ static const struct fb_bitfield def_rgb565[] = {
}
};
-static const struct fb_bitfield def_rgb666[] = {
- [RED] = {
- .offset = 16,
- .length = 6,
- },
- [GREEN] = {
- .offset = 8,
- .length = 6,
- },
- [BLUE] = {
- .offset = 0,
- .length = 6,
- },
- [TRANSP] = { /* no support for transparency */
- .length = 0,
- }
-};
-
static const struct fb_bitfield def_rgb888[] = {
[RED] = {
.offset = 16,
@@ -309,9 +291,6 @@ static int mxsfb_check_var(struct fb_var_screeninfo *var,
break;
case STMLCDIF_16BIT:
case STMLCDIF_18BIT:
- /* 24 bit to 18 bit mapping */
- rgb = def_rgb666;
- break;
case STMLCDIF_24BIT:
/* real 24 bit */
rgb = def_rgb888;
@@ -453,11 +432,6 @@ static int mxsfb_set_par(struct fb_info *fb_info)
return -EINVAL;
case STMLCDIF_16BIT:
case STMLCDIF_18BIT:
- /* 24 bit to 18 bit mapping */
- ctrl |= CTRL_DF24; /* ignore the upper 2 bits in
- * each colour component
- */
- break;
case STMLCDIF_24BIT:
/* real 24 bit */
break;
--
1.8.3
^ permalink raw reply related
* [PATCH v3] simplefb: add support for a8b8g8r8 pixel format
From: Alexandre Courbot @ 2013-06-07 7:31 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Stephen Warren,
Olof Johansson
Cc: gnurou, linux-kernel, linux-fbdev, Alexandre Courbot
A framebuffer of this format is set up by SHIELD's bootloader.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Olof Johansson <olof@lixom.net>
---
Changes from v2:
- Fixed typo in format (Thanks Alexander van Heukelum!)
Changes from v1:
- Added description to motivate the change
- Added ack
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 1 +
drivers/video/simplefb.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 3ea4605..70c26f3 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -12,6 +12,7 @@ Required properties:
- stride: The number of bytes in each line of the framebuffer.
- format: The format of the framebuffer surface. Valid values are:
- r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+ - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Example:
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index e2e9e3e..f015482 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -84,6 +84,7 @@ struct simplefb_format {
static struct simplefb_format simplefb_formats[] = {
{ "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+ { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {24, 8} },
};
struct simplefb_params {
--
1.8.3
^ permalink raw reply related
* Re: [PATCH v2] simplefb: add support for a8b8g8r8 pixel format
From: Alex Courbot @ 2013-06-07 7:28 UTC (permalink / raw)
To: Alexander van Heukelum
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Stephen Warren,
Olof Johansson, gnurou@gmail.com, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org
In-Reply-To: <1370589753.21409.140661241005617.2A5614D3@webmail.messagingengine.com>
On 06/07/2013 04:22 PM, Alexander van Heukelum wrote:
>> static struct simplefb_format simplefb_formats[] = {
>> { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
>> + { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },
>
> Hi,
>
> 31? I assume in practice this doesn't influence anything, but I think it should have read 24.
Doh. Thanks for pointing it out.
Alex.
^ permalink raw reply
* Re: [PATCH v2] simplefb: add support for a8b8g8r8 pixel format
From: Alexander van Heukelum @ 2013-06-07 7:22 UTC (permalink / raw)
To: Alexandre Courbot, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Stephen Warren, Olof Johansson
Cc: gnurou, linux-kernel, linux-fbdev
In-Reply-To: <1370584869-2904-1-git-send-email-acourbot@nvidia.com>
On Fri, Jun 7, 2013, at 8:01, Alexandre Courbot wrote:
> A framebuffer of this format is set up by SHIELD's bootloader. This
> allows us to use it as a framebuffer console.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Olof Johansson <olof@lixom.net>
> ---
> Changes from v1:
> - Added description to motivate the change
> - Added ack
>
> Documentation/devicetree/bindings/video/simple-framebuffer.txt | 1 +
> drivers/video/simplefb.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> index 3ea4605..70c26f3 100644
> --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -12,6 +12,7 @@ Required properties:
> - stride: The number of bytes in each line of the framebuffer.
> - format: The format of the framebuffer surface. Valid values are:
> - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> + - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
>
> Example:
>
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> index e2e9e3e..d7041aa 100644
> --- a/drivers/video/simplefb.c
> +++ b/drivers/video/simplefb.c
> @@ -84,6 +84,7 @@ struct simplefb_format {
>
> static struct simplefb_format simplefb_formats[] = {
> { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
> + { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },
Hi,
31? I assume in practice this doesn't influence anything, but I think it should have read 24.
Greetings,
Alexander
> };
>
> struct simplefb_params {
> --
> 1.8.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: [PATCH 19/32] OMAPDSS: add videomode conversion support
From: Archit Taneja @ 2013-06-07 7:18 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1369906493-27538-20-git-send-email-tomi.valkeinen@ti.com>
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
> Add helper functions to convert between omapdss specific video timings
> and the common videomode.
>
> Eventually omapdss will be changed to use only the common video timings,
> and these helper functions will make the transition easier.
So we now use omap_video_timings, videomode, drm_display_mode, and
fb_var_screeninfo, fun! :)
Archit
^ permalink raw reply
* Re: [PATCH 12/32] OMAPDSS: Implement display (dis)connect support
From: Archit Taneja @ 2013-06-07 6:58 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1369906493-27538-13-git-send-email-tomi.valkeinen@ti.com>
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
> We currently have two steps in panel initialization and startup: probing
> and enabling. After the panel has been probed, it's ready and can be
> configured and later enabled.
>
> This model is not enough with more complex display pipelines, where we
> may have, for example, two panels, of which only one can be used at a
> time, connected to the same video output.
>
> To support that kind of scenarios, we need to add new step to the
> initialization: connect.
>
> This patch adds support for connecting and disconnecting panels. After
> probe, but before connect, no panel ops should be called. When the
> connect is called, a proper video pipeline is established, and the panel
> is ready for use. If some part in the video pipeline is already
> connected (by some other panel), the connect call fails.
>
> One key difference with the old style setup is that connect() handles
> also connecting to the overlay manager. This means that the omapfb (or
> omapdrm) no longer needs to figure out which overlay manager to use, but
> it can just call connect() on the panel, and the proper overlay manager
> is connected by omapdss.
>
> This also allows us to add back the support for dynamic switching
> between two exclusive panels. However, the current panel device model is
> not changed to support this, as the new device model is implemented in
> the following patches and the old model will be removed. The new device
> model supports dynamic switching.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 24 +++++++++++++++++
> drivers/gpu/drm/omapdrm/omap_drv.c | 12 ++++++++-
> drivers/video/omap2/dss/apply.c | 14 ++++++++++
> drivers/video/omap2/dss/core.c | 44 +++++++++++++++++++++++++++++++
> drivers/video/omap2/dss/display-sysfs.c | 28 +++++++++++---------
> drivers/video/omap2/dss/manager-sysfs.c | 45 ++++++++++++++++++++------------
> drivers/video/omap2/dss/output.c | 14 ++++++++++
> drivers/video/omap2/omapfb/omapfb-main.c | 25 ++++++++++--------
> include/video/omapdss.h | 23 ++++++++++++++++
> 9 files changed, 188 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 02075bf..b2ab2f5 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -94,6 +94,28 @@ uint32_t pipe2vbl(struct drm_crtc *crtc)
> static struct omap_crtc *omap_crtcs[8];
>
> /* we can probably ignore these until we support command-mode panels: */
> +static int omap_crtc_connect(struct omap_overlay_manager *mgr,
> + struct omap_dss_output *dst)
> +{
> + if (mgr->output)
> + return -EINVAL;
> +
> + if ((mgr->supported_outputs & dst->id) = 0)
> + return -EINVAL;
> +
> + dst->manager = mgr;
> + mgr->output = dst;
> +
> + return 0;
> +}
> +
> +static void omap_crtc_disconnect(struct omap_overlay_manager *mgr,
> + struct omap_dss_output *dst)
> +{
> + mgr->output->manager = NULL;
> + mgr->output = NULL;
> +}
> +
> static void omap_crtc_start_update(struct omap_overlay_manager *mgr)
> {
> }
> @@ -138,6 +160,8 @@ static void omap_crtc_unregister_framedone_handler(
> }
>
> static const struct dss_mgr_ops mgr_ops = {
> + .connect = omap_crtc_connect,
> + .disconnect = omap_crtc_disconnect,
> .start_update = omap_crtc_start_update,
> .enable = omap_crtc_enable,
> .disable = omap_crtc_disable,
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c
> index f8947f9..58bd259 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -97,6 +97,7 @@ static int omap_modeset_init(struct drm_device *dev)
> int num_mgrs = dss_feat_get_num_mgrs();
> int num_crtcs;
> int i, id = 0;
> + int r;
>
> omap_crtc_pre_init();
>
> @@ -118,6 +119,7 @@ static int omap_modeset_init(struct drm_device *dev)
> struct drm_connector *connector;
> struct drm_encoder *encoder;
> enum omap_channel channel;
> + struct omap_overlay_manager *mgr;
>
> if (!dssdev->driver) {
> dev_warn(dev->dev, "%s has no driver.. skipping it\n",
> @@ -133,6 +135,13 @@ static int omap_modeset_init(struct drm_device *dev)
> continue;
> }
>
> + r = dssdev->driver->connect(dssdev);
> + if (r) {
> + dev_err(dev->dev, "could not connect display: %s\n",
> + dssdev->name);
> + continue;
> + }
> +
> encoder = omap_encoder_init(dev, dssdev);
>
> if (!encoder) {
> @@ -174,8 +183,9 @@ static int omap_modeset_init(struct drm_device *dev)
> * other possible channels to which the encoder can connect are
> * not considered.
> */
> - channel = dssdev->output->dispc_channel;
>
> + mgr = omapdss_find_mgr_from_display(dssdev);
> + channel = mgr->id;
> /*
> * if this channel hasn't already been taken by a previously
> * allocated crtc, we create a new crtc for it
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index c844071..dbd3c2f 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -790,6 +790,18 @@ static void mgr_clear_shadow_dirty(struct omap_overlay_manager *mgr)
> }
> }
>
> +static int dss_mgr_connect_compat(struct omap_overlay_manager *mgr,
> + struct omap_dss_output *dst)
> +{
> + return mgr->set_output(mgr, dst);
> +}
> +
> +static void dss_mgr_disconnect_compat(struct omap_overlay_manager *mgr,
> + struct omap_dss_output *dst)
> +{
> + mgr->unset_output(mgr);
> +}
> +
> static void dss_mgr_start_update_compat(struct omap_overlay_manager *mgr)
> {
> struct mgr_priv_data *mp = get_mgr_priv(mgr);
> @@ -1552,6 +1564,8 @@ static void dss_mgr_unregister_framedone_handler_compat(struct omap_overlay_mana
> }
>
> static const struct dss_mgr_ops apply_mgr_ops = {
> + .connect = dss_mgr_connect_compat,
> + .disconnect = dss_mgr_disconnect_compat,
> .start_update = dss_mgr_start_update_compat,
> .enable = dss_mgr_enable_compat,
> .disable = dss_mgr_disable_compat,
> diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
> index 502ec1b..4bd8f79 100644
> --- a/drivers/video/omap2/dss/core.c
> +++ b/drivers/video/omap2/dss/core.c
> @@ -371,6 +371,46 @@ static int dss_driver_remove(struct device *dev)
> return 0;
> }
>
> +static int omapdss_default_connect(struct omap_dss_device *dssdev)
> +{
> + struct omap_dss_output *out;
> + struct omap_overlay_manager *mgr;
> + int r;
> +
> + out = dssdev->output;
> +
> + if (out = NULL)
> + return -ENODEV;
> +
> + mgr = omap_dss_get_overlay_manager(out->dispc_channel);
> + if (!mgr)
> + return -ENODEV;
> +
> + r = dss_mgr_connect(mgr, out);
> + if (r)
> + return r;
> +
> + return 0;
> +}
> +
> +static void omapdss_default_disconnect(struct omap_dss_device *dssdev)
> +{
> + struct omap_dss_output *out;
> + struct omap_overlay_manager *mgr;
> +
> + out = dssdev->output;
> +
> + if (out = NULL)
> + return;
> +
> + mgr = out->manager;
> +
> + if (mgr = NULL)
> + return;
> +
> + dss_mgr_disconnect(mgr, out);
> +}
> +
> int omap_dss_register_driver(struct omap_dss_driver *dssdriver)
> {
> dssdriver->driver.bus = &dss_bus_type;
> @@ -384,6 +424,10 @@ int omap_dss_register_driver(struct omap_dss_driver *dssdriver)
> omapdss_default_get_recommended_bpp;
> if (dssdriver->get_timings = NULL)
> dssdriver->get_timings = omapdss_default_get_timings;
> + if (dssdriver->connect = NULL)
> + dssdriver->connect = omapdss_default_connect;
> + if (dssdriver->disconnect = NULL)
> + dssdriver->disconnect = omapdss_default_disconnect;
I was wondering if these should be apis rather than driver ops. One
advantage of having them as functions used by omapfb/omapdrm would be
that a panel driver wouldn't override the default_connect/disconnect ops.
Even though they are named omapdss_default_connect/disconnect, I don't
think there is another option by which a panel driver may chose to
connect to omapdss outputs, right?
Archit
^ permalink raw reply
* Re: [PATCH 15/32] OMAPDSS: DPI: cleanup pll & regulator init
From: Archit Taneja @ 2013-06-07 6:52 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1369906493-27538-16-git-send-email-tomi.valkeinen@ti.com>
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
> Split regulator and DSI PLL init code to their own functions for
> clarity.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dpi.c | 100 ++++++++++++++++++++++--------------------
> 1 file changed, 53 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index 43f6b26..66ba9a6 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -545,6 +545,53 @@ static int dpi_verify_dsi_pll(struct platform_device *dsidev)
> return 0;
> }
>
> +static int dpi_init_regulator(void)
> +{
> + struct regulator *vdds_dsi;
> +
> + if (!dss_has_feature(FEAT_DPI_USES_VDDS_DSI))
> + return 0;
> +
> + if (dpi.vdds_dsi_reg)
> + return 0;
> +
> + vdds_dsi = dss_get_vdds_dsi();
> +
> + if (!IS_ERR(vdds_dsi)) {
> + dpi.vdds_dsi_from_core = true;
> + dpi.vdds_dsi_reg = vdds_dsi;
> + return 0;
> + }
> +
> + vdds_dsi = regulator_get(&dpi.pdev->dev, "vdds_dsi");
> + if (!IS_ERR(vdds_dsi)) {
> + dpi.vdds_dsi_from_core = false;
> + dpi.vdds_dsi_reg = vdds_dsi;
> + return 0;
> + }
> +
> + return PTR_ERR(vdds_dsi);
> +}
> +
> +static void dpi_init_pll(void)
> +{
> + struct platform_device *dsidev;
> +
> + if (dpi.dsidev)
> + return;
> +
> + dsidev = dpi_get_dsidev(dpi.output.dispc_channel);
> + if (!dsidev)
> + return;
> +
> + if (dpi_verify_dsi_pll(dsidev)) {
> + DSSWARN("DSI PLL not operational\n");
> + return;
> + }
> +
> + dpi.dsidev = dsidev;
> +}
> +
> /*
> * Return a hardcoded channel for the DPI output. This should work for
> * current use cases, but this can be later expanded to either resolve
> @@ -575,46 +622,6 @@ static enum omap_channel dpi_get_channel(void)
> }
> }
>
> -static int dpi_init_display(struct omap_dss_device *dssdev)
> -{
> - struct platform_device *dsidev;
> -
> - DSSDBG("init_display\n");
> -
> - if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
> - dpi.vdds_dsi_reg = NULL) {
> - struct regulator *vdds_dsi;
> -
> - vdds_dsi = dss_get_vdds_dsi();
> - if (IS_ERR(vdds_dsi)) {
> - vdds_dsi = regulator_get(&dpi.pdev->dev, "vdds_dsi");
same comment about devm_ usage here, and the next few patches.
Archit
^ permalink raw reply
* Re: [PATCH 14/32] OMAPDSS: DSI: cleanup regulator init
From: Archit Taneja @ 2013-06-07 6:50 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1369906493-27538-15-git-send-email-tomi.valkeinen@ti.com>
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
> Separate the regulator initialization code to its own function, removing
> duplicate code.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dsi.c | 82 ++++++++++++++++---------------------------
> 1 file changed, 31 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
> index bdddd0d..37ca980 100644
> --- a/drivers/video/omap2/dss/dsi.c
> +++ b/drivers/video/omap2/dss/dsi.c
> @@ -1114,6 +1114,30 @@ void dsi_runtime_put(struct platform_device *dsidev)
> WARN_ON(r < 0 && r != -ENOSYS);
> }
>
> +static int dsi_regulator_init(struct platform_device *dsidev)
> +{
> + struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> + struct regulator *vdds_dsi;
> +
> + if (dsi->vdds_dsi_reg != NULL)
> + return 0;
> +
> + vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
> +
> + /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
> + if (IS_ERR(vdds_dsi))
> + vdds_dsi = regulator_get(&dsi->pdev->dev, "VCXIO");
> +
We could use devm_ versions here too right?
Archit
> + if (IS_ERR(vdds_dsi)) {
> + DSSERR("can't get VDDS_DSI regulator\n");
> + return PTR_ERR(vdds_dsi);
> + }
> +
> + dsi->vdds_dsi_reg = vdds_dsi;
> +
> + return 0;
> +}
> +
> /* source clock for DSI PLL. this could also be PCLKFREE */
> static inline void dsi_enable_pll_clock(struct platform_device *dsidev,
> bool enable)
> @@ -1592,22 +1616,9 @@ int dsi_pll_init(struct platform_device *dsidev, bool enable_hsclk,
> */
> enable_hsclk = enable_hsdiv = true;
>
> - if (dsi->vdds_dsi_reg = NULL) {
> - struct regulator *vdds_dsi;
> -
> - vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
> -
> - /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
> - if (IS_ERR(vdds_dsi))
> - vdds_dsi = regulator_get(&dsi->pdev->dev, "VCXIO");
> -
> - if (IS_ERR(vdds_dsi)) {
> - DSSERR("can't get VDDS_DSI regulator\n");
> - return PTR_ERR(vdds_dsi);
> - }
> -
> - dsi->vdds_dsi_reg = vdds_dsi;
> - }
> + r = dsi_regulator_init(dsidev);
> + if (r)
> + return r;
>
> dsi_enable_pll_clock(dsidev, 1);
> /*
> @@ -5225,34 +5236,6 @@ static enum omap_channel dsi_get_channel(int module_id)
> }
> }
>
> -static int dsi_init_display(struct omap_dss_device *dssdev)
> -{
> - struct platform_device *dsidev > - dsi_get_dsidev_from_id(dssdev->phy.dsi.module);
> - struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> -
> - DSSDBG("DSI init\n");
> -
> - if (dsi->vdds_dsi_reg = NULL) {
> - struct regulator *vdds_dsi;
> -
> - vdds_dsi = regulator_get(&dsi->pdev->dev, "vdds_dsi");
> -
> - /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
> - if (IS_ERR(vdds_dsi))
> - vdds_dsi = regulator_get(&dsi->pdev->dev, "VCXIO");
> -
> - if (IS_ERR(vdds_dsi)) {
> - DSSERR("can't get VDDS_DSI regulator\n");
> - return PTR_ERR(vdds_dsi);
> - }
> -
> - dsi->vdds_dsi_reg = vdds_dsi;
> - }
> -
> - return 0;
> -}
> -
> int omap_dsi_request_vc(struct omap_dss_device *dssdev, int *channel)
> {
> struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
> @@ -5410,19 +5393,16 @@ static int dsi_probe_pdata(struct platform_device *dsidev)
> if (!plat_dssdev)
> return 0;
>
> + r = dsi_regulator_init(dsidev);
> + if (r)
> + return r;
> +
> dssdev = dss_alloc_and_init_device(&dsidev->dev);
> if (!dssdev)
> return -ENOMEM;
>
> dss_copy_device_pdata(dssdev, plat_dssdev);
>
> - r = dsi_init_display(dssdev);
> - if (r) {
> - DSSERR("device %s init failed: %d\n", dssdev->name, r);
> - dss_put_device(dssdev);
> - return r;
> - }
> -
> r = omapdss_output_set_device(&dsi->output, dssdev);
> if (r) {
> DSSERR("failed to connect output to new device: %s\n",
>
^ permalink raw reply
* Re: [PATCH 11/32] OMAPDRM: fix overlay manager handling
From: Archit Taneja @ 2013-06-07 6:33 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1369906493-27538-12-git-send-email-tomi.valkeinen@ti.com>
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
> Currently omapdrm creates crtcs, which map directly to DSS overlay
> managers, only on demand at init time. This would make it difficult to
> manage connecting the display entities in the future, as the code cannot
> just search for a suitable overlay manager.
>
> We cannot fix this the sane way, which would be to create crtcs for each
> overlay manager, because we need an overlay for each crtc. With limited
> number of overlays, that's not possible.
>
> So the solution for now is to detach the overlay manager from the crtc.
> crtcs are still created on demand at init time, but all overlay managers
> are always initialized by the omapdss.
>
> This way we can create and connect whole display pipelines from the
> overlay manager to the display, regardless of which crtcs omapdrm would
> create.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/gpu/drm/omapdrm/omap_crtc.c | 22 +++++++++++++++-------
> drivers/gpu/drm/omapdrm/omap_drv.c | 2 ++
> drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
> drivers/video/omap2/dss/apply.c | 3 ---
> drivers/video/omap2/dss/dispc.c | 4 ++++
> 5 files changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 79b200a..02075bf 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -40,7 +40,7 @@ struct omap_crtc {
> * mgr->id.) Eventually this will be replaced w/ something
> * more common-panel-framework-y
> */
> - struct omap_overlay_manager mgr;
> + struct omap_overlay_manager *mgr;
>
> struct omap_video_timings timings;
> bool enabled;
> @@ -90,6 +90,9 @@ uint32_t pipe2vbl(struct drm_crtc *crtc)
> * job of sequencing the setup of the video pipe in the proper order
> */
>
> +/* ovl-mgr-id -> crtc */
> +static struct omap_crtc *omap_crtcs[8];
> +
> /* we can probably ignore these until we support command-mode panels: */
> static void omap_crtc_start_update(struct omap_overlay_manager *mgr)
> {
> @@ -107,7 +110,7 @@ static void omap_crtc_disable(struct omap_overlay_manager *mgr)
> static void omap_crtc_set_timings(struct omap_overlay_manager *mgr,
> const struct omap_video_timings *timings)
> {
> - struct omap_crtc *omap_crtc = container_of(mgr, struct omap_crtc, mgr);
> + struct omap_crtc *omap_crtc = omap_crtcs[mgr->id];
> DBG("%s", omap_crtc->name);
> omap_crtc->timings = *timings;
> omap_crtc->full_update = true;
> @@ -116,7 +119,7 @@ static void omap_crtc_set_timings(struct omap_overlay_manager *mgr,
> static void omap_crtc_set_lcd_config(struct omap_overlay_manager *mgr,
> const struct dss_lcd_mgr_config *config)
> {
> - struct omap_crtc *omap_crtc = container_of(mgr, struct omap_crtc, mgr);
> + struct omap_crtc *omap_crtc = omap_crtcs[mgr->id];
> DBG("%s", omap_crtc->name);
> dispc_mgr_set_lcd_config(omap_crtc->channel, config);
> }
> @@ -569,7 +572,7 @@ static void omap_crtc_pre_apply(struct omap_drm_apply *apply)
> } else {
> if (encoder) {
> omap_encoder_set_enabled(encoder, false);
> - omap_encoder_update(encoder, &omap_crtc->mgr,
> + omap_encoder_update(encoder, omap_crtc->mgr,
> &omap_crtc->timings);
> omap_encoder_set_enabled(encoder, true);
> omap_crtc->full_update = false;
> @@ -595,6 +598,11 @@ static const char *channel_names[] = {
> [OMAP_DSS_CHANNEL_LCD2] = "lcd2",
> };
Since we are creating overlay managers structs now, we could get rid of
the channel_names strings above and use mgr->name instead. Not
necessary, of course.
Archit
>
> +void omap_crtc_pre_init(void)
> +{
> + dss_install_mgr_ops(&mgr_ops);
> +}
> +
> /* initialize crtc */
> struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> struct drm_plane *plane, enum omap_channel channel, int id)
> @@ -635,9 +643,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> omap_irq_register(dev, &omap_crtc->error_irq);
>
> /* temporary: */
> - omap_crtc->mgr.id = channel;
> -
> - dss_install_mgr_ops(&mgr_ops);
> + omap_crtc->mgr = omap_dss_get_overlay_manager(channel);
>
> /* TODO: fix hard-coded setup.. add properties! */
> info = &omap_crtc->info;
> @@ -651,6 +657,8 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
>
> omap_plane_install_properties(omap_crtc->plane, &crtc->base);
>
> + omap_crtcs[channel] = omap_crtc;
> +
> return crtc;
>
> fail:
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 691e760..f8947f9 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -98,6 +98,8 @@ static int omap_modeset_init(struct drm_device *dev)
> int num_crtcs;
> int i, id = 0;
>
> + omap_crtc_pre_init();
> +
> drm_mode_config_init(dev);
>
> omap_drm_irq_install(dev);
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h b/drivers/gpu/drm/omapdrm/omap_drv.h
> index 215a20d..14f17da 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -157,6 +157,7 @@ const struct omap_video_timings *omap_crtc_timings(struct drm_crtc *crtc);
> enum omap_channel omap_crtc_channel(struct drm_crtc *crtc);
> int omap_crtc_apply(struct drm_crtc *crtc,
> struct omap_drm_apply *apply);
> +void omap_crtc_pre_init(void);
> struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> struct drm_plane *plane, enum omap_channel channel, int id);
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index 74d1d00..c844071 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -1577,7 +1577,6 @@ int omapdss_compat_init(void)
>
> apply_init_priv();
>
> - dss_init_overlay_managers();
> dss_init_overlay_managers_sysfs(pdev);
> dss_init_overlays(pdev);
>
> @@ -1642,7 +1641,6 @@ err_disp_sysfs:
>
> err_mgr_ops:
> dss_uninit_overlay_managers_sysfs(pdev);
> - dss_uninit_overlay_managers();
> dss_uninit_overlays(pdev);
>
> compat_refcnt--;
> @@ -1671,7 +1669,6 @@ void omapdss_compat_uninit(void)
> dss_uninstall_mgr_ops();
>
> dss_uninit_overlay_managers_sysfs(pdev);
> - dss_uninit_overlay_managers();
> dss_uninit_overlays(pdev);
> out:
> mutex_unlock(&compat_init_lock);
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index b33b016..83d7bb9 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -3710,6 +3710,8 @@ static int __init omap_dispchw_probe(struct platform_device *pdev)
>
> dispc_runtime_put();
>
> + dss_init_overlay_managers();
> +
> dss_debugfs_create_file("dispc", dispc_dump_regs);
>
> return 0;
> @@ -3723,6 +3725,8 @@ static int __exit omap_dispchw_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(&pdev->dev);
>
> + dss_uninit_overlay_managers();
> +
> return 0;
> }
>
>
^ permalink raw reply
* Re: [PATCH 10/32] OMAPDSS: split overlay manager creation
From: Archit Taneja @ 2013-06-07 6:31 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1369906493-27538-11-git-send-email-tomi.valkeinen@ti.com>
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
> Split the function that creates overlay manager structs into two: one
> that creates just the structs, and one that creates the sysfs files for
> the manager.
>
> This will help us use the overlay manager structs with omapdrm in the
> following patches, while still leaving the sysfs files out.
Maybe the omapdss Makefile should also reflect this change, we could
move manager.o so that it doesn't look like a compat file any more.
Archit
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/apply.c | 9 ++++++---
> drivers/video/omap2/dss/dss.h | 6 ++++--
> drivers/video/omap2/dss/manager-sysfs.c | 2 ++
> drivers/video/omap2/dss/manager.c | 29 ++++++++++++++++++++++-------
> 4 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
> index b84bd99..74d1d00 100644
> --- a/drivers/video/omap2/dss/apply.c
> +++ b/drivers/video/omap2/dss/apply.c
> @@ -1577,7 +1577,8 @@ int omapdss_compat_init(void)
>
> apply_init_priv();
>
> - dss_init_overlay_managers(pdev);
> + dss_init_overlay_managers();
> + dss_init_overlay_managers_sysfs(pdev);
> dss_init_overlays(pdev);
>
> for (i = 0; i < omap_dss_get_num_overlay_managers(); i++) {
> @@ -1640,7 +1641,8 @@ err_disp_sysfs:
> dss_uninstall_mgr_ops();
>
> err_mgr_ops:
> - dss_uninit_overlay_managers(pdev);
> + dss_uninit_overlay_managers_sysfs(pdev);
> + dss_uninit_overlay_managers();
> dss_uninit_overlays(pdev);
>
> compat_refcnt--;
> @@ -1668,7 +1670,8 @@ void omapdss_compat_uninit(void)
>
> dss_uninstall_mgr_ops();
>
> - dss_uninit_overlay_managers(pdev);
> + dss_uninit_overlay_managers_sysfs(pdev);
> + dss_uninit_overlay_managers();
> dss_uninit_overlays(pdev);
> out:
> mutex_unlock(&compat_init_lock);
> diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
> index 8475893..7964d3b 100644
> --- a/drivers/video/omap2/dss/dss.h
> +++ b/drivers/video/omap2/dss/dss.h
> @@ -194,8 +194,10 @@ void display_uninit_sysfs(struct platform_device *pdev,
> struct omap_dss_device *dssdev);
>
> /* manager */
> -int dss_init_overlay_managers(struct platform_device *pdev);
> -void dss_uninit_overlay_managers(struct platform_device *pdev);
> +int dss_init_overlay_managers(void);
> +void dss_uninit_overlay_managers(void);
> +int dss_init_overlay_managers_sysfs(struct platform_device *pdev);
> +void dss_uninit_overlay_managers_sysfs(struct platform_device *pdev);
> int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
> const struct omap_overlay_manager_info *info);
> int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
> diff --git a/drivers/video/omap2/dss/manager-sysfs.c b/drivers/video/omap2/dss/manager-sysfs.c
> index 5104681..72784b3 100644
> --- a/drivers/video/omap2/dss/manager-sysfs.c
> +++ b/drivers/video/omap2/dss/manager-sysfs.c
> @@ -511,4 +511,6 @@ void dss_manager_kobj_uninit(struct omap_overlay_manager *mgr)
> {
> kobject_del(&mgr->kobj);
> kobject_put(&mgr->kobj);
> +
> + memset(&mgr->kobj, 0, sizeof(mgr->kobj));
> }
> diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c
> index 2551eaa..1aac9b4 100644
> --- a/drivers/video/omap2/dss/manager.c
> +++ b/drivers/video/omap2/dss/manager.c
> @@ -36,9 +36,9 @@
> static int num_managers;
> static struct omap_overlay_manager *managers;
>
> -int dss_init_overlay_managers(struct platform_device *pdev)
> +int dss_init_overlay_managers(void)
> {
> - int i, r;
> + int i;
>
> num_managers = dss_feat_get_num_mgrs();
>
> @@ -76,6 +76,17 @@ int dss_init_overlay_managers(struct platform_device *pdev)
> dss_feat_get_supported_outputs(mgr->id);
>
> INIT_LIST_HEAD(&mgr->overlays);
> + }
> +
> + return 0;
> +}
> +
> +int dss_init_overlay_managers_sysfs(struct platform_device *pdev)
> +{
> + int i, r;
> +
> + for (i = 0; i < num_managers; ++i) {
> + struct omap_overlay_manager *mgr = &managers[i];
>
> r = dss_manager_kobj_init(mgr, pdev);
> if (r)
> @@ -85,18 +96,22 @@ int dss_init_overlay_managers(struct platform_device *pdev)
> return 0;
> }
>
> -void dss_uninit_overlay_managers(struct platform_device *pdev)
> +void dss_uninit_overlay_managers(void)
> +{
> + kfree(managers);
> + managers = NULL;
> + num_managers = 0;
> +}
> +
> +void dss_uninit_overlay_managers_sysfs(struct platform_device *pdev)
> {
> int i;
>
> for (i = 0; i < num_managers; ++i) {
> struct omap_overlay_manager *mgr = &managers[i];
> +
> dss_manager_kobj_uninit(mgr);
> }
> -
> - kfree(managers);
> - managers = NULL;
> - num_managers = 0;
> }
>
> int omap_dss_get_num_overlay_managers(void)
>
^ permalink raw reply
* Re: [PATCH] simplefb: add support for a8b8g8r8 pixel format
From: Alex Courbot @ 2013-06-07 6:08 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Olof Johansson, Stephen Warren, Tomi Valkeinen,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
Alexandre Courbot
In-Reply-To: <20130606163240.GY19468@game.jcrosoft.org>
On 06/07/2013 01:32 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> We're talking about adding a bunch of code instead of one line in a
>> table. Sorry, I NACK your NACK. If we get more entries we'll add the
>> parser, but not just for this.
> as there is no NACK so far I do take as a NACK
... which means?
Anyway, I have sent a new version of this patch that includes a summary
motivating why we need it. Please explain clearly whether you accept it
or not, and if not, what we need to do to add this mode in a
satisfactory way.
Thanks,
Alex.
^ permalink raw reply
* [PATCH v2] simplefb: add support for a8b8g8r8 pixel format
From: Alexandre Courbot @ 2013-06-07 6:01 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Stephen Warren,
Olof Johansson
Cc: gnurou, linux-kernel, linux-fbdev, Alexandre Courbot
A framebuffer of this format is set up by SHIELD's bootloader. This
allows us to use it as a framebuffer console.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Olof Johansson <olof@lixom.net>
---
Changes from v1:
- Added description to motivate the change
- Added ack
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 1 +
drivers/video/simplefb.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 3ea4605..70c26f3 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -12,6 +12,7 @@ Required properties:
- stride: The number of bytes in each line of the framebuffer.
- format: The format of the framebuffer surface. Valid values are:
- r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+ - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Example:
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index e2e9e3e..d7041aa 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -84,6 +84,7 @@ struct simplefb_format {
static struct simplefb_format simplefb_formats[] = {
{ "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
+ { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },
};
struct simplefb_params {
--
1.8.3
^ permalink raw reply related
* Re: [PATCH 06/32] OMAPDSS: DPI: fix regulators for DT
From: Archit Taneja @ 2013-06-07 5:57 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1369906493-27538-7-git-send-email-tomi.valkeinen@ti.com>
On Thursday 30 May 2013 03:04 PM, Tomi Valkeinen wrote:
> On some platforms DPI requires a regulator to be enabled to power up the
> output pins. This regulator is, for some reason, currently attached to
> the virtual omapdss device, instead of the DPI device. This does not
> work for DT, as the regulator mappings need to be described in the DT
> data, and the virtual omapdss device is not present there.
>
> Fix the issue by acquiring the regulator in the DPI device. To retain
> compatibility with the current board files, the old method of getting
> the regulator is kept. The old method can be removed when the board
> files have been changed to pass the regulator to DPI.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/dpi.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
> index ef8fca2..43f6b26 100644
> --- a/drivers/video/omap2/dss/dpi.c
> +++ b/drivers/video/omap2/dss/dpi.c
> @@ -37,7 +37,10 @@
> #include "dss_features.h"
>
> static struct {
> + struct platform_device *pdev;
We don't really need to add a new member here for getting the output's
device pointer. It's already there in dpi.output.dev.
Archit
> +
> struct regulator *vdds_dsi_reg;
> + bool vdds_dsi_from_core;
> struct platform_device *dsidev;
>
> struct mutex lock;
> @@ -583,10 +586,15 @@ static int dpi_init_display(struct omap_dss_device *dssdev)
> struct regulator *vdds_dsi;
>
> vdds_dsi = dss_get_vdds_dsi();
> -
> if (IS_ERR(vdds_dsi)) {
> - DSSERR("can't get VDDS_DSI regulator\n");
> - return PTR_ERR(vdds_dsi);
> + vdds_dsi = regulator_get(&dpi.pdev->dev, "vdds_dsi");
> + if (IS_ERR(vdds_dsi)) {
> + DSSERR("can't get VDDS_DSI regulator\n");
> + return PTR_ERR(vdds_dsi);
> + }
> + dpi.vdds_dsi_from_core = false;
> + } else {
> + dpi.vdds_dsi_from_core = true;
> }
>
> dpi.vdds_dsi_reg = vdds_dsi;
> @@ -702,6 +710,8 @@ static int omap_dpi_probe(struct platform_device *pdev)
> {
> int r;
>
> + dpi.pdev = pdev;
> +
> mutex_init(&dpi.lock);
>
> dpi_init_output(pdev);
> @@ -725,6 +735,11 @@ static int __exit omap_dpi_remove(struct platform_device *pdev)
>
> dpi_uninit_output(pdev);
>
> + if (dpi.vdds_dsi_reg != NULL && dpi.vdds_dsi_from_core = false) {
> + regulator_put(dpi.vdds_dsi_reg);
> + dpi.vdds_dsi_reg = NULL;
> + }
> +
> return 0;
> }
>
>
^ permalink raw reply
* [PATCH] backlight: add CONFIG_PM_SLEEP to suspend/resume functions
From: Jingoo Han @ 2013-06-07 1:39 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: 'Shuah Khan', linux-fbdev, linux-kernel, shuahkhan,
rpurdie, FlorianSchandinat, plagnioj, tomi.valkeinen,
rafael.j.wysocki, 'Arnd Bergmann', 'Jingoo Han'
Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
the CONFIG_PM_SLEEP is enabled.
drivers/video/backlight/backlight.c:211:12: warning: 'backlight_suspend' defined but not used [-Wunused-function]
drivers/video/backlight/backlight.c:225:12: warning: 'backlight_resume' defined but not used [-Wunused-function]
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/backlight/backlight.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index cedbcbe..750807c 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -208,6 +208,7 @@ static ssize_t backlight_show_actual_brightness(struct device *dev,
static struct class *backlight_class;
+#ifdef CONFIG_PM_SLEEP
static int backlight_suspend(struct device *dev)
{
struct backlight_device *bd = to_backlight_device(dev);
@@ -235,6 +236,7 @@ static int backlight_resume(struct device *dev)
return 0;
}
+#endif
static SIMPLE_DEV_PM_OPS(backlight_class_dev_pm_ops, backlight_suspend,
backlight_resume);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v3] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Jingoo Han @ 2013-06-07 1:29 UTC (permalink / raw)
To: 'Arnd Bergmann'
Cc: 'Andrew Morton', 'Shuah Khan', linux-fbdev,
linux-kernel, shuahkhan, rpurdie, FlorianSchandinat, plagnioj,
tomi.valkeinen, rafael.j.wysocki, Jingoo Han
In-Reply-To: <5441622.ypFXsKluBt@wuerfel>
On Friday, June 07, 2013 6:28 AM, Arnd Bergmann wrote:
> On Monday 03 June 2013 13:10:10 Jingoo Han wrote:
> > On Sunday, June 02, 2013 8:07 AM, Shuah Khan wrote:
> > >
> > > Convert drivers/video/backlight/class to use dev_pm_ops for power
> > > management and remove Legacy PM ops hooks. With this change, backlight
> > > class registers suspend/resume callbacks via class->pm (dev_pm_ops)
> > > instead of Legacy class->suspend/resume. When __device_suspend() runs
> > > call-backs, it will find class->pm ops for the backlight class.
> > >
> > > Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
> > > Cc: Shuah Khan <shuahkhan@gmail.com>
> >
> > CC'ed Andrew Morton,
> >
> > It looks good.
> >
> > Acked-by: Jingoo Han <jg1.han@samsung.com>
> >
>
> I'm getting this build warning now:
>
> arnd@wuerfel:/git/arm-soc$ cat build/omap1_defconfig/faillog
> /git/arm-soc/drivers/video/backlight/backlight.c:212:12: warning: 'backlight_suspend' defined but not
> used [-Wunused-function]
> static int backlight_suspend(struct device *dev)
> ^
> /git/arm-soc/drivers/video/backlight/backlight.c:226:12: warning: 'backlight_resume' defined but not
> used [-Wunused-function]
> static int backlight_resume(struct device *dev)
Hi Arnd Bergmann,
I see what happens.
This build warning happens when CONFIG_PM is selected and
CONFIG_PM_SLEEP is not selected.
So, I will add '#ifdef CONFIG_PM_SLEEP' to './drivers/video/backlight/backlight.c'
and send it soon.
Thank you.
Best regards,
Jingoo Han
>
> Arnd
^ permalink raw reply
* Re: [PATCH v3] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Arnd Bergmann @ 2013-06-06 21:27 UTC (permalink / raw)
To: Jingoo Han
Cc: Andrew Morton, 'Shuah Khan', linux-fbdev, linux-kernel,
shuahkhan, rpurdie, FlorianSchandinat, plagnioj, tomi.valkeinen,
rafael.j.wysocki
In-Reply-To: <001a01ce6010$3daaf3c0$b900db40$@samsung.com>
On Monday 03 June 2013 13:10:10 Jingoo Han wrote:
> On Sunday, June 02, 2013 8:07 AM, Shuah Khan wrote:
> >
> > Convert drivers/video/backlight/class to use dev_pm_ops for power
> > management and remove Legacy PM ops hooks. With this change, backlight
> > class registers suspend/resume callbacks via class->pm (dev_pm_ops)
> > instead of Legacy class->suspend/resume. When __device_suspend() runs
> > call-backs, it will find class->pm ops for the backlight class.
> >
> > Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
> > Cc: Shuah Khan <shuahkhan@gmail.com>
>
> CC'ed Andrew Morton,
>
> It looks good.
>
> Acked-by: Jingoo Han <jg1.han@samsung.com>
>
I'm getting this build warning now:
arnd@wuerfel:/git/arm-soc$ cat build/omap1_defconfig/faillog
/git/arm-soc/drivers/video/backlight/backlight.c:212:12: warning: 'backlight_suspend' defined but not used [-Wunused-function]
static int backlight_suspend(struct device *dev)
^
/git/arm-soc/drivers/video/backlight/backlight.c:226:12: warning: 'backlight_resume' defined but not used [-Wunused-function]
static int backlight_resume(struct device *dev)
Arnd
^ permalink raw reply
* Re: [PATCH] simplefb: add support for a8b8g8r8 pixel format
From: Stephen Warren @ 2013-06-06 16:45 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Alex Courbot, Tomi Valkeinen, Olof Johansson, gnurou@gmail.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org
In-Reply-To: <20130606162943.GX19468@game.jcrosoft.org>
On 06/06/2013 10:29 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
...
> I did reject this patch but put a warning I do not want to see a huge table
> if so => factorisation or parser
Did you mean "accept" here not "reject"?
^ permalink raw reply
* Re: [PATCH] simplefb: add support for a8b8g8r8 pixel format
From: Olof Johansson @ 2013-06-06 16:33 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Stephen Warren, Alex Courbot, Tomi Valkeinen, gnurou@gmail.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org
In-Reply-To: <20130606162011.GV19468@game.jcrosoft.org>
On Thu, Jun 6, 2013 at 9:20 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 10:11 Thu 06 Jun , Stephen Warren wrote:
>> On 06/06/2013 02:12 AM, Alex Courbot wrote:
>> > On 06/06/2013 04:59 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> >>
>> >> On Jun 6, 2013, at 9:20 AM, Alexandre Courbot <acourbot@nvidia.com>
>> >> wrote:
>> >>
>> >>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>>
>> No commit description? It'd be useful to at least justify this by
>> mentioning that some platform will actually use this...
>>
>> ...
>> >>> static struct simplefb_format simplefb_formats[] = {
>> >>> { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
>> >>> + { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },
>> >>
>> >> why don't you parse the string?
>> >>
>> >> so you will a real generic bindings
>> >
>> > Tried that already, got NACKed: https://lkml.org/lkml/2013/5/27/330
>> >
>> > The list of modes of this driver should not grow too big. Even in terms
>> > of footprint I'd say the list should remain smaller than the parsing code.
>> >
>> > What we can discuss though is whether we want to keep this a8b8g8r8
>> > syntax or switch to something more standard, say "rgba8888".
>>
>> I would prefer to keep the syntax of the new formats consistent, so that
>> if we ever do add format-parsing code rather than table-based lookup,
>> all the existing formats will continue to work unchanged, without any
>> kind of fallback lookup table.
>
> I do prefer a format-parsing than any long lookup table that take time at boot
> time
We're talking about adding a bunch of code instead of one line in a
table. Sorry, I NACK your NACK. If we get more entries we'll add the
parser, but not just for this.
If you want to make a framebuffer-subsystem generic and shared helper,
go ahead. I'm sure simplefb will move over to it when it's available.
Until then:
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* Re: [PATCH] simplefb: add support for a8b8g8r8 pixel format
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-06-06 16:32 UTC (permalink / raw)
To: Olof Johansson
Cc: Stephen Warren, Alex Courbot, Tomi Valkeinen, gnurou@gmail.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org
In-Reply-To: <CAOesGMgybYe_BBb0M4YS8tmM2C5jawf91OOyOuwwS5HSiUjPpQ@mail.gmail.com>
On 09:33 Thu 06 Jun , Olof Johansson wrote:
> On Thu, Jun 6, 2013 at 9:20 AM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 10:11 Thu 06 Jun , Stephen Warren wrote:
> >> On 06/06/2013 02:12 AM, Alex Courbot wrote:
> >> > On 06/06/2013 04:59 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> >>
> >> >> On Jun 6, 2013, at 9:20 AM, Alexandre Courbot <acourbot@nvidia.com>
> >> >> wrote:
> >> >>
> >> >>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> >>
> >> No commit description? It'd be useful to at least justify this by
> >> mentioning that some platform will actually use this...
> >>
> >> ...
> >> >>> static struct simplefb_format simplefb_formats[] = {
> >> >>> { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
> >> >>> + { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },
> >> >>
> >> >> why don't you parse the string?
> >> >>
> >> >> so you will a real generic bindings
> >> >
> >> > Tried that already, got NACKed: https://lkml.org/lkml/2013/5/27/330
> >> >
> >> > The list of modes of this driver should not grow too big. Even in terms
> >> > of footprint I'd say the list should remain smaller than the parsing code.
> >> >
> >> > What we can discuss though is whether we want to keep this a8b8g8r8
> >> > syntax or switch to something more standard, say "rgba8888".
> >>
> >> I would prefer to keep the syntax of the new formats consistent, so that
> >> if we ever do add format-parsing code rather than table-based lookup,
> >> all the existing formats will continue to work unchanged, without any
> >> kind of fallback lookup table.
> >
> > I do prefer a format-parsing than any long lookup table that take time at boot
> > time
>
> We're talking about adding a bunch of code instead of one line in a
> table. Sorry, I NACK your NACK. If we get more entries we'll add the
> parser, but not just for this.
as there is no NACK so far I do take as a NACK
Best Regards,
J.
>
> If you want to make a framebuffer-subsystem generic and shared helper,
> go ahead. I'm sure simplefb will move over to it when it's available.
>
> Until then:
>
> Acked-by: Olof Johansson <olof@lixom.net>
>
>
>
> -Olof
^ permalink raw reply
* Re: [PATCH] simplefb: add support for a8b8g8r8 pixel format
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-06-06 16:29 UTC (permalink / raw)
To: Stephen Warren
Cc: Alex Courbot, Tomi Valkeinen, Olof Johansson, gnurou@gmail.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org
In-Reply-To: <51B0B61C.2000008@wwwdotorg.org>
On 10:17 Thu 06 Jun , Stephen Warren wrote:
> On 06/06/2013 08:50 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 17:27 Thu 06 Jun , Alex Courbot wrote:
> >> On 06/06/2013 05:24 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>
> >>> On Jun 6, 2013, at 10:12 AM, Alex Courbot <acourbot@nvidia.com> wrote:
> >>>
> >>>> On 06/06/2013 04:59 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>>>
> >>>>> On Jun 6, 2013, at 9:20 AM, Alexandre Courbot <acourbot@nvidia.com> wrote:
> ...
> >>>>>> static struct simplefb_format simplefb_formats[] = {
> >>>>>> { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
> >>>>>> + { "a8b8g8r8", 32, {0, 8}, {8, 8}, {16, 8}, {31, 8} },
> >>>>>
> >>>>> why don't you parse the string?
>
> Jean-Christophe, I'm afraid I can't tell exactly what you're arguing for.
>
> Here, you want code added to parse the string ...
>
> This has already been rejected as being over-engineered, and more than
> this simple driver needs. Even if it were shared code, the only
> practical use of such a parsing function would be to support this
> driver, since presumably any other HW-specific driver already knows
> exactly which format the FB is in, and hence wouldn't need to share this
> code.
>
> >>>>> so you will a real generic bindings
> >>>>
> >>>> Tried that already, got NACKed: https://lkml.org/lkml/2013/5/27/330
> >>>>
> >>>> The list of modes of this driver should not grow too big. Even in terms of footprint I'd say the list should remain smaller than the parsing code.
> >>>>
> >>>> What we can discuss though is whether we want to keep this a8b8g8r8 syntax or switch to something more standard, say "rgba8888".
> >>>
> >>> I'm going to be very honest I do not like the simplefb driver from the beginning
> >>> but I do found it useful. And as said in it's name it need to be *SIMPLE*
> >>>
> >>> Then a huge list of compatible no way
> >>> otherwise we drop this from the simplefb and make it a generic helper
> >>>
> >>> I do not want to see format parser in every drivers this need to handle at video framework level
>
> ... yet here you appear to be arguing against using a format parser, or
> including a format parser ...
>
> Note that a lookup table isn't any kind of shared parser; it's just a
> very tiny and simple table of static data. It seems quite unlikely that
> this could be a maintenance issue, even if over time a few more entries
> get added to the table.
>
> >>> If I see that we start to increase again and again the simplefb I will not accept
> >>> to merge the code as we must keep it simple
> >>
> >> In that case it's probably better to maintain a "simple" list of
> >> supported modes, which is what this patch does.
> >
> > so get out it of the simplefb other drivers can use it
>
> ... yet here you appear to want to move the list of modes into some
> central location ...
>
> I don't think that's useful for the reason I mentioned above: presumably
> any other HW-specific driver already knows exactly which format the FB
> is in, and hence wouldn't need to share this code/table.
>
> Why don't we simply take this patch to extend this table, and then *if*
> any other FB driver needs to parse a format from DT, we can move the
> code(table) to a common location at that time. That will be a trivial
> change, and one this patch does nothing to make any harder. Making the
> code/table common before then seems like over-engineering.
that why I said *if I see that we start ....*
I did reject this patch but put a warning I do not want to see a huge table
if so => factorisation or parser
Best Regards,
J.
^ 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