* [PATCH 1/2] backlight: platform_lcd: Remove DT compatibility string
From: Alexander Shiyan @ 2014-03-29 10:00 UTC (permalink / raw)
To: linux-fbdev
Driver is written for using platform callback functions and it cannot
be used without these functions, so having "platform-lcd" in the device
tree do nothing. This patch removes DT compatibility string.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/video/backlight/platform_lcd.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/video/backlight/platform_lcd.c b/drivers/video/backlight/platform_lcd.c
index c3d2e20..4afc21f 100644
--- a/drivers/video/backlight/platform_lcd.c
+++ b/drivers/video/backlight/platform_lcd.c
@@ -16,8 +16,6 @@
#include <linux/fb.h>
#include <linux/backlight.h>
#include <linux/lcd.h>
-#include <linux/of.h>
-#include <linux/slab.h>
#include <video/platform_lcd.h>
@@ -137,20 +135,11 @@ static int platform_lcd_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(platform_lcd_pm_ops, platform_lcd_suspend,
platform_lcd_resume);
-#ifdef CONFIG_OF
-static const struct of_device_id platform_lcd_of_match[] = {
- { .compatible = "platform-lcd" },
- {},
-};
-MODULE_DEVICE_TABLE(of, platform_lcd_of_match);
-#endif
-
static struct platform_driver platform_lcd_driver = {
.driver = {
.name = "platform-lcd",
.owner = THIS_MODULE,
.pm = &platform_lcd_pm_ops,
- .of_match_table = of_match_ptr(platform_lcd_of_match),
},
.probe = platform_lcd_probe,
};
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 00/16] move at91 and avr32 to the PWM framework, remove obsolete drivers
From: Alexandre Belloni @ 2014-03-27 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5334633E.6050708@atmel.com>
Hi,
On 27/03/2014 at 18:43:26 +0100, Nicolas Ferre wrote :
> On 19/03/2014 14:03, Alexandre Belloni :
> > Alexandre Belloni (16):
> > ARM: at91: at91sam9g45: switch to generic PWM framework
> > ARM: at91: sam9m10g45ek: use generic leds_pwm driver
> > ARM: at91: at91sam9263: switch to generic PWM framework
> > ARM: at91: sam9263ek: use generic leds_pwm driver
> > ARM: at91: at91sam9rl: switch to generic PWM framework
> > ARM: at91: remove useless at91_pwm_leds()
> > PWM: atmel: allow building for AVR32
> > backlight: pwm_bl: set pwm polarity when using platform data
Please wait for Thierry Reding to comment on this one...
> > avr32/at32ap: switch to the generic PWM framework
> > avr32: MRMT: use generic leds_pwm driver
> > avr32: merisc: use generic leds_pwm driver
> > avr32: favr-32: use generic pwm_bl driver
> > avr32: update defconfig to use the generic PWM framework
> > backlight: atmel-pwm-bl: remove obsolete driver
> > leds: atmel-pwm: remove obsolete driver
...watch out for the small typo (pawm-atmel) I made there...
> > misc: atmel_pwm: remove obsolete driver
>
> I am fine with the whole series. For the AT91 specific bits, you can add my:
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> It is a very nice cleanup and I can take the series with me in the AT91
> git tree (likely the at91-3.16-cleanup or at91-3.16-drivers branch) if
> everybody agree.
>
... but I believe you can take it through your tree as it mostly depends
on AT91 and Hans-Christian seemed fine with the modifications on avr32.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 00/16] move at91 and avr32 to the PWM framework, remove obsolete drivers
From: Nicolas Ferre @ 2014-03-27 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1395234209-15546-1-git-send-email-alexandre.belloni@free-electrons.com>
On 19/03/2014 14:03, Alexandre Belloni :
> Hi,
>
> This patch set swtiches the at91 and avr32 SoCs and board to the generic PWM
> framework. This allows to remove the obsolete leds-atmel-pwm, atmel-pwm-bl and
> atmel_pwm drivers.
>
> The first 6 patches take care of the AT91 boards and removes a useless function
> in the process.
>
> Patch 7 makes pwm-ateml buildable for AVR32
>
> Patch 8 allows setting the pwm polarity for pwm_bl when using platform data.
> This is required afterwards for the favr-32
>
> Patches 9-13 take care of the AVR32 boards. This has only been compile tested as
> I don't own any of those boards.
>
> And the last 3 patches are removing the now obsolete drivers.
>
> As a note, the atmel_pwm driver has two features not yet available through
> pwm-atmel:
> - it is possible to pass an IRQ handler that will get called each time one of
> the channel period has been acheived.
> - it was possible to set clka and clkb, two clock that divided mck before
> feeding the pwm controller.
>
> Those features are not used by anything in the mainline. I'm not sure we can
> implement the first one. We'll get back the second one once all the boards have
> swtiched to the common clock framework.
>
>
> Alexandre Belloni (16):
> ARM: at91: at91sam9g45: switch to generic PWM framework
> ARM: at91: sam9m10g45ek: use generic leds_pwm driver
> ARM: at91: at91sam9263: switch to generic PWM framework
> ARM: at91: sam9263ek: use generic leds_pwm driver
> ARM: at91: at91sam9rl: switch to generic PWM framework
> ARM: at91: remove useless at91_pwm_leds()
> PWM: atmel: allow building for AVR32
> backlight: pwm_bl: set pwm polarity when using platform data
> avr32/at32ap: switch to the generic PWM framework
> avr32: MRMT: use generic leds_pwm driver
> avr32: merisc: use generic leds_pwm driver
> avr32: favr-32: use generic pwm_bl driver
> avr32: update defconfig to use the generic PWM framework
> backlight: atmel-pwm-bl: remove obsolete driver
> leds: atmel-pwm: remove obsolete driver
> misc: atmel_pwm: remove obsolete driver
I am fine with the whole series. For the AT91 specific bits, you can add my:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
It is a very nice cleanup and I can take the series with me in the AT91
git tree (likely the at91-3.16-cleanup or at91-3.16-drivers branch) if
everybody agree.
Bye,
> arch/arm/mach-at91/at91sam9263.c | 1 +
> arch/arm/mach-at91/at91sam9263_devices.c | 11 +-
> arch/arm/mach-at91/at91sam9g45.c | 1 +
> arch/arm/mach-at91/at91sam9g45_devices.c | 11 +-
> arch/arm/mach-at91/at91sam9rl.c | 1 +
> arch/arm/mach-at91/at91sam9rl_devices.c | 11 +-
> arch/arm/mach-at91/board-sam9263ek.c | 56 +++-
> arch/arm/mach-at91/board-sam9m10g45ek.c | 43 ++-
> arch/arm/mach-at91/board.h | 1 -
> arch/arm/mach-at91/leds.c | 37 ---
> arch/avr32/boards/atngw100/mrmt.c | 35 ++-
> arch/avr32/boards/favr-32/setup.c | 49 ++--
> arch/avr32/boards/merisc/setup.c | 34 ++-
> arch/avr32/configs/atngw100_mrmt_defconfig | 5 +-
> arch/avr32/configs/atstk1002_defconfig | 5 +-
> arch/avr32/configs/atstk1003_defconfig | 5 +-
> arch/avr32/configs/atstk1004_defconfig | 5 +-
> arch/avr32/configs/atstk1006_defconfig | 5 +-
> arch/avr32/configs/favr-32_defconfig | 6 +-
> arch/avr32/configs/merisc_defconfig | 5 +-
> arch/avr32/mach-at32ap/at32ap700x.c | 7 +-
> drivers/leds/Kconfig | 8 -
> drivers/leds/Makefile | 1 -
> drivers/leds/leds-atmel-pwm.c | 149 -----------
> drivers/misc/Kconfig | 9 -
> drivers/misc/Makefile | 1 -
> drivers/misc/atmel_pwm.c | 402 -----------------------------
> drivers/pwm/Kconfig | 2 +-
> drivers/video/backlight/Kconfig | 11 -
> drivers/video/backlight/Makefile | 1 -
> drivers/video/backlight/atmel-pwm-bl.c | 223 ----------------
> drivers/video/backlight/pwm_bl.c | 8 +
> include/linux/atmel-pwm-bl.h | 43 ---
> include/linux/atmel_pwm.h | 70 -----
> include/linux/pwm_backlight.h | 1 +
> 35 files changed, 199 insertions(+), 1064 deletions(-)
> delete mode 100644 drivers/leds/leds-atmel-pwm.c
> delete mode 100644 drivers/misc/atmel_pwm.c
> delete mode 100644 drivers/video/backlight/atmel-pwm-bl.c
> delete mode 100644 include/linux/atmel-pwm-bl.h
> delete mode 100644 include/linux/atmel_pwm.h
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 15/16] leds: atmel-pwm: remove obsolete driver
From: Bryan Wu @ 2014-03-27 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1395234209-15546-16-git-send-email-alexandre.belloni@free-electrons.com>
On Wed, Mar 19, 2014 at 6:03 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> The leds-atmel-pwmdriver is now obsolete. It is not used by any mainlined boards
> and is replaced by the generic leds_pwm with the pawm-atmel driver using the
> generic PWM framework.
>
Good to remove.
Acked-by: Bryan Wu <cooloney@gmail.com>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
> drivers/leds/Kconfig | 8 ---
> drivers/leds/Makefile | 1 -
> drivers/leds/leds-atmel-pwm.c | 149 ------------------------------------------
> 3 files changed, 158 deletions(-)
> delete mode 100644 drivers/leds/leds-atmel-pwm.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 72156c123033..e7aca5f1e396 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -32,14 +32,6 @@ config LEDS_88PM860X
> This option enables support for on-chip LED drivers found on Marvell
> Semiconductor 88PM8606 PMIC.
>
> -config LEDS_ATMEL_PWM
> - tristate "LED Support using Atmel PWM outputs"
> - depends on LEDS_CLASS
> - depends on ATMEL_PWM
> - help
> - This option enables support for LEDs driven using outputs
> - of the dedicated PWM controller found on newer Atmel SOCs.
> -
> config LEDS_LM3530
> tristate "LCD Backlight driver for LM3530"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 3cd76dbd9be2..6ee06559db45 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -6,7 +6,6 @@ obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
>
> # LED Platform Drivers
> obj-$(CONFIG_LEDS_88PM860X) += leds-88pm860x.o
> -obj-$(CONFIG_LEDS_ATMEL_PWM) += leds-atmel-pwm.o
> obj-$(CONFIG_LEDS_BD2802) += leds-bd2802.o
> obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
> obj-$(CONFIG_LEDS_LM3530) += leds-lm3530.o
> diff --git a/drivers/leds/leds-atmel-pwm.c b/drivers/leds/leds-atmel-pwm.c
> deleted file mode 100644
> index 56cec8d6a2ac..000000000000
> --- a/drivers/leds/leds-atmel-pwm.c
> +++ /dev/null
> @@ -1,149 +0,0 @@
> -#include <linux/kernel.h>
> -#include <linux/platform_device.h>
> -#include <linux/leds.h>
> -#include <linux/io.h>
> -#include <linux/atmel_pwm.h>
> -#include <linux/slab.h>
> -#include <linux/module.h>
> -
> -
> -struct pwmled {
> - struct led_classdev cdev;
> - struct pwm_channel pwmc;
> - struct gpio_led *desc;
> - u32 mult;
> - u8 active_low;
> -};
> -
> -
> -/*
> - * For simplicity, we use "brightness" as if it were a linear function
> - * of PWM duty cycle. However, a logarithmic function of duty cycle is
> - * probably a better match for perceived brightness: two is half as bright
> - * as four, four is half as bright as eight, etc
> - */
> -static void pwmled_brightness(struct led_classdev *cdev, enum led_brightness b)
> -{
> - struct pwmled *led;
> -
> - /* update the duty cycle for the *next* period */
> - led = container_of(cdev, struct pwmled, cdev);
> - pwm_channel_writel(&led->pwmc, PWM_CUPD, led->mult * (unsigned) b);
> -}
> -
> -/*
> - * NOTE: we reuse the platform_data structure of GPIO leds,
> - * but repurpose its "gpio" number as a PWM channel number.
> - */
> -static int pwmled_probe(struct platform_device *pdev)
> -{
> - const struct gpio_led_platform_data *pdata;
> - struct pwmled *leds;
> - int i;
> - int status;
> -
> - pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata || pdata->num_leds < 1)
> - return -ENODEV;
> -
> - leds = devm_kzalloc(&pdev->dev, pdata->num_leds * sizeof(*leds),
> - GFP_KERNEL);
> - if (!leds)
> - return -ENOMEM;
> -
> - for (i = 0; i < pdata->num_leds; i++) {
> - struct pwmled *led = leds + i;
> - const struct gpio_led *dat = pdata->leds + i;
> - u32 tmp;
> -
> - led->cdev.name = dat->name;
> - led->cdev.brightness = LED_OFF;
> - led->cdev.brightness_set = pwmled_brightness;
> - led->cdev.default_trigger = dat->default_trigger;
> -
> - led->active_low = dat->active_low;
> -
> - status = pwm_channel_alloc(dat->gpio, &led->pwmc);
> - if (status < 0)
> - goto err;
> -
> - /*
> - * Prescale clock by 2^x, so PWM counts in low MHz.
> - * Start each cycle with the LED active, so increasing
> - * the duty cycle gives us more time on (= brighter).
> - */
> - tmp = 5;
> - if (!led->active_low)
> - tmp |= PWM_CPR_CPOL;
> - pwm_channel_writel(&led->pwmc, PWM_CMR, tmp);
> -
> - /*
> - * Pick a period so PWM cycles at 100+ Hz; and a multiplier
> - * for scaling duty cycle: brightness * mult.
> - */
> - tmp = (led->pwmc.mck / (1 << 5)) / 100;
> - tmp /= 255;
> - led->mult = tmp;
> - pwm_channel_writel(&led->pwmc, PWM_CDTY,
> - led->cdev.brightness * 255);
> - pwm_channel_writel(&led->pwmc, PWM_CPRD,
> - LED_FULL * tmp);
> -
> - pwm_channel_enable(&led->pwmc);
> -
> - /* Hand it over to the LED framework */
> - status = led_classdev_register(&pdev->dev, &led->cdev);
> - if (status < 0) {
> - pwm_channel_free(&led->pwmc);
> - goto err;
> - }
> - }
> -
> - platform_set_drvdata(pdev, leds);
> - return 0;
> -
> -err:
> - if (i > 0) {
> - for (i = i - 1; i >= 0; i--) {
> - led_classdev_unregister(&leds[i].cdev);
> - pwm_channel_free(&leds[i].pwmc);
> - }
> - }
> -
> - return status;
> -}
> -
> -static int pwmled_remove(struct platform_device *pdev)
> -{
> - const struct gpio_led_platform_data *pdata;
> - struct pwmled *leds;
> - unsigned i;
> -
> - pdata = dev_get_platdata(&pdev->dev);
> - leds = platform_get_drvdata(pdev);
> -
> - for (i = 0; i < pdata->num_leds; i++) {
> - struct pwmled *led = leds + i;
> -
> - led_classdev_unregister(&led->cdev);
> - pwm_channel_free(&led->pwmc);
> - }
> -
> - return 0;
> -}
> -
> -static struct platform_driver pwmled_driver = {
> - .driver = {
> - .name = "leds-atmel-pwm",
> - .owner = THIS_MODULE,
> - },
> - /* REVISIT add suspend() and resume() methods */
> - .probe = pwmled_probe,
> - .remove = pwmled_remove,
> -};
> -
> -module_platform_driver(pwmled_driver);
> -
> -MODULE_DESCRIPTION("Driver for LEDs with PWM-controlled brightness");
> -MODULE_LICENSE("GPL");
> -MODULE_ALIAS("platform:leds-atmel-pwm");
> --
> 1.8.3.2
>
^ permalink raw reply
* [PATCH 1/1] video: imxfb: Driver depends on status of LCD class device
From: Gaëtan Carlier @ 2014-03-27 15:20 UTC (permalink / raw)
To: linux-fbdev
If LCD_CLASS_DEVICE is disabled, symbol devm_lcd_device_register is
undefined
Signed-off-by: Gaëtan Carlier <gcembed@gmail.com>
---
drivers/video/fbdev/imxfb.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index f6e6216..b979b61 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -30,7 +30,9 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
+#ifdef CONFIG_LCD_CLASS_DEVICE
#include <linux/lcd.h>
+#endif
#include <linux/math64.h>
#include <linux/of.h>
#include <linux/of_device.h>
@@ -718,6 +720,7 @@ static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
return 0;
}
+#ifdef CONFIG_LCD_CLASS_DEVICE
static int imxfb_lcd_check_fb(struct lcd_device *lcddev, struct fb_info *fi)
{
struct imxfb_info *fbi = dev_get_drvdata(&lcddev->dev);
@@ -785,6 +788,7 @@ static struct lcd_ops imxfb_lcd_ops = {
.get_power = imxfb_lcd_get_power,
.set_power = imxfb_lcd_set_power,
};
+#endif
static int imxfb_setup(void)
{
@@ -809,7 +813,9 @@ static int imxfb_setup(void)
static int imxfb_probe(struct platform_device *pdev)
{
struct imxfb_info *fbi;
+#ifdef CONFIG_LCD_CLASS_DEVICE
struct lcd_device *lcd;
+#endif
struct fb_info *info;
struct imx_fb_platform_data *pdata;
struct resource *res;
@@ -967,6 +973,7 @@ static int imxfb_probe(struct platform_device *pdev)
goto failed_lcd;
}
+#ifdef CONFIG_LCD_CLASS_DEVICE
lcd = devm_lcd_device_register(&pdev->dev, "imxfb-lcd", &pdev->dev, fbi,
&imxfb_lcd_ops);
if (IS_ERR(lcd)) {
@@ -975,6 +982,7 @@ static int imxfb_probe(struct platform_device *pdev)
}
lcd->props.max_contrast = 0xff;
+#endif
imxfb_enable_controller(fbi);
fbi->pdev = pdev;
--
1.7.7.4
^ permalink raw reply related
* [PATCH 2/2] Make the diu driver work without board level initilization
From: Jason Jin @ 2014-03-27 11:38 UTC (permalink / raw)
To: b07421, timur; +Cc: linux-fbdev, linuxppc-dev, r58472, jason.jin
So far the DIU driver does not have a mechanism to do the
board specific initialization. So on some platforms,
such as P1022, 8610 and 5121, The board specific initialization
is implmented in the platform file such p10222_ds.
Actually, the DIU is already intialized in the u-boot, the pin sharing
and the signal routing are also set in u-boot. So we can leverage that
in kernel driver to avoid board sepecific initialization, especially
for the corenet platform, which is the abstraction for serveral
platfroms.
The potential problem is that when the system wakeup from the deep
sleep, some platform settings may need to be re-initialized. The CPLD
and FPGA settings will be kept, but the pixel clock register which
usually locate at the global utility space need to be reinitialized.
Generally, the pixel clock setting was implemented in the platform
file, But the pixel clock register itself should be part of the DIU
module, And for P1022,8610 and T1040, the pixel clock register have the
same structure, So we can consider to move the pixel clock setting
from the platform to the diu driver. This patch provide the options
set the pixel clock in the diu driver. But the original platform pixel
clock setting stil can be used for P1022,8610 and 512x without any
update. To implement the pixel clock setting in the diu driver. the
following update in the diu dts node was needed.
display:display@180000 {
compatible = "fsl,t1040-diu", "fsl,diu";
- reg = <0x180000 1000>;
+ reg = <0x180000 1000 0xfc028 4>;
+ pixclk = <0 255 0>;
interrupts = <74 2 0 0>;
}
The 0xfc028 is the offset for pixel clock register. the 3 segment of
the pixclk stand for the PXCKDLYDIR, the max of PXCK and the PXCKDLY
which will be used by the pixel clock register setting.
This was tested on T1040 platform. For other platform, the original
node together with the platform settings still can work.
Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
---
V2: Remove the pixel clock register saving for suspend.
add the pixel clock setting in driver.
drivers/video/fsl-diu-fb.c | 61 ++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 4bc4730..792038f 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -50,6 +50,7 @@
#define INT_PARERR 0x08 /* Display parameters error interrupt */
#define INT_LS_BF_VS 0x10 /* Lines before vsync. interrupt */
+#define PIXCLKCR_PXCKEN 0x80000000
/*
* List of supported video modes
*
@@ -372,6 +373,8 @@ struct fsl_diu_data {
unsigned int irq;
enum fsl_diu_monitor_port monitor_port;
struct diu __iomem *diu_reg;
+ void __iomem *pixelclk_reg;
+ u32 pixclkcr[3];
spinlock_t reg_lock;
u8 dummy_aoi[4 * 4 * 4];
struct diu_ad dummy_ad __aligned(8);
@@ -479,7 +482,10 @@ static enum fsl_diu_monitor_port fsl_diu_name_to_port(const char *s)
port = FSL_DIU_PORT_DLVDS;
}
- return diu_ops.valid_monitor_port(port);
+ if (diu_ops.valid_monitor_port)
+ return diu_ops.valid_monitor_port(port);
+ else
+ return port;
}
/*
@@ -798,6 +804,35 @@ static void set_fix(struct fb_info *info)
fix->ypanstep = 1;
}
+static void set_pixel_clock(struct fsl_diu_data *data, unsigned int pixclock)
+{
+ unsigned long freq;
+ u64 temp;
+ u32 pxclk;
+ u32 pxclkdl_dir, pxckmax, pxclk_delay;
+
+ /* Convert pixclock from a wavelength to a frequency */
+ temp = 1000000000000ULL;
+ do_div(temp, pixclock);
+ freq = temp;
+
+ pxclkdl_dir = data->pixclkcr[0] << 30;
+ pxckmax = data->pixclkcr[1];
+ pxclk_delay = data->pixclkcr[2] << 8;
+
+ /*
+ * 'pxclk' is the ratio of the platform clock to the pixel clock.
+ * This number is programmed into the PIXCLKCR register, and the valid
+ * range of values is 2- pxckmax.
+ */
+ pxclk = DIV_ROUND_CLOSEST(fsl_get_sys_freq(), freq);
+ pxclk = clamp_t(u32, pxclk, 2, pxckmax);
+
+ out_be32(data->pixelclk_reg, 0);
+ out_be32(data->pixelclk_reg, PIXCLKCR_PXCKEN
+ | pxclkdl_dir | (pxclk << 16) | pxclk_delay);
+}
+
static void update_lcdc(struct fb_info *info)
{
struct fb_var_screeninfo *var = &info->var;
@@ -846,7 +881,13 @@ static void update_lcdc(struct fb_info *info)
out_be32(&hw->vsyn_para, temp);
- diu_ops.set_pixel_clock(var->pixclock);
+ /* If the pixel clock setting function can not be used on the platform,
+ * then use the platform one.
+ */
+ if (diu_ops.set_pixel_clock)
+ diu_ops.set_pixel_clock(var->pixclock);
+ else
+ set_pixel_clock(data, var->pixclock);
#ifndef CONFIG_PPC_MPC512x
/*
@@ -1752,6 +1793,22 @@ static int fsl_diu_probe(struct platform_device *pdev)
goto error;
}
+ if (!diu_ops.set_pixel_clock) {
+ data->pixelclk_reg = of_iomap(np, 1);
+ if (!data->pixelclk_reg) {
+ dev_err(&pdev->dev, "Cannot map pixelclk registers, please \
+ provide the diu_ops for pixclk setting instead.\n");
+ ret = -EFAULT;
+ goto error;
+ }
+ /*Get the pixclkcr settings: PXCKDLYDIR; MAXPXCK, PXCKDLY*/
+ ret = of_property_read_u32_array(np, "pixclk", data->pixclkcr, 3);
+ if (ret) {
+ dev_err(&pdev->dev, "Cannot get pixelclk registers information.\n");
+ goto error;
+ }
+ }
+
/* Get the IRQ of the DIU */
data->irq = irq_of_parse_and_map(np, 0);
--
1.8.0
^ permalink raw reply related
* [PATCH 1/2] video/fsl: Fix the sleep function for FSL DIU module
From: Jason Jin @ 2014-03-27 11:37 UTC (permalink / raw)
To: b07421, timur
Cc: linux-fbdev, linuxppc-dev, r58472, jason.jin, Wang Dongsheng
For deep sleep, the diu module will power off, when wake up from the deep
sleep, more registers need to be reinitialized.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
---
V2: Coding style clean up based on Timur's comments.
drivers/video/fsl-diu-fb.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index e8758b9..4bc4730 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -1628,9 +1628,15 @@ static int fsl_diu_suspend(struct platform_device *ofdev, pm_message_t state)
static int fsl_diu_resume(struct platform_device *ofdev)
{
struct fsl_diu_data *data;
+ unsigned int i;
data = dev_get_drvdata(&ofdev->dev);
- enable_lcdc(data->fsl_diu_info);
+ fsl_diu_enable_interrupts(data);
+ update_lcdc(data->fsl_diu_info);
+ for (i = 0; i < NUM_AOIS; i++) {
+ if (data->mfb[i].count)
+ fsl_diu_enable_panel(&data->fsl_diu_info[i]);
+ }
return 0;
}
--
1.8.0
^ permalink raw reply related
* RE: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Jason.Jin @ 2014-03-27 3:57 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <53339F03.7010004@tabi.org>
> Jason.Jin@freescale.com wrote:
> > [Jason Jin-R64188] It's not hackish, we can provide the pixel clock
> register in the DIU node, I did not provide the dts update as this is
> only tested on T1040 platform. For other platforms such as p1022 and 8610,
> we still can use the pixel clock setting function in the platform.
> >
> > The dts node update for T1040 is:
> > display:display@180000 {
> > compatible = "fsl,t1040-diu", "fsl,diu";
> > - reg = <0x180000 1000>;
> > + reg = <0x180000 1000 0xfc028 4>;
> > interrupts = <74 2 0 0>;
> > };
>
> This is hackish because you're specifying a single register that you want
> to preserve in the DTS file, instead of a platform function which is
> where it's supposed to be.
>
[Jason Jin-R64188] The pixel clock register is actually part of the DIU registers although it is not implemented in the diu module. Actually we can use it to set pixel clock in the driver not just saving it in suspend. We can provide the patch for discussion.
> I will think about this some more. I think you are trying too hard to
> avoid a platform file, which is why some of this code is hackish to me.
[Jason Jin-R64188] Thanks. Could you please share you thinking for how to setup the platform file then?
^ permalink raw reply
* Re: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Timur Tabi @ 2014-03-27 3:46 UTC (permalink / raw)
To: Jason.Jin@freescale.com
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <e3e45edb388c482eb53474e18575f227@BLUPR03MB373.namprd03.prod.outlook.com>
Jason.Jin@freescale.com wrote:
> [Jason Jin-R64188] It's not hackish, we can provide the pixel clock register in the DIU node, I did not provide the dts update as this is only tested on T1040 platform. For other platforms such as p1022 and 8610, we still can use the pixel clock setting function in the platform.
>
> The dts node update for T1040 is:
> display:display@180000 {
> compatible = "fsl,t1040-diu", "fsl,diu";
> - reg = <0x180000 1000>;
> + reg = <0x180000 1000 0xfc028 4>;
> interrupts = <74 2 0 0>;
> };
This is hackish because you're specifying a single register that you
want to preserve in the DTS file, instead of a platform function which
is where it's supposed to be.
I will think about this some more. I think you are trying too hard to
avoid a platform file, which is why some of this code is hackish to me.
^ permalink raw reply
* RE: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Jason.Jin @ 2014-03-27 3:42 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <53332168.5050805@tabi.org>
>
> On 03/26/2014 12:41 PM, Jason Jin wrote:
> > + if (!diu_ops.set_pixel_clock) {
> > + data->saved_pixel_clock = 0;
> > + if (of_address_to_resource(ofdev->dev.of_node, 1, &res))
> > + pr_err(KERN_ERR "No pixel clock set func and no pixel
> node!\n");
> > + else {
> > + data->pixelclk_ptr > > + devm_ioremap(&ofdev->dev, res.start,
> resource_size(&res));
> > + if (!data->pixelclk_ptr) {
> > + pr_err(KERN_ERR "fslfb: could not map pixelclk
> register!\n");
> > + ret = -ENOMEM;
> > + } else
> > + data->saved_pixel_clock = in_be32(data-
> >pixelclk_ptr);
> > + }
> > + }
>
> This seems very hackish. What node does ofdev point to? I wonder if
> this code should be in the platform file instead.
>
[Jason Jin-R64188] It's not hackish, we can provide the pixel clock register in the DIU node, I did not provide the dts update as this is only tested on T1040 platform. For other platforms such as p1022 and 8610, we still can use the pixel clock setting function in the platform.
The dts node update for T1040 is:
display:display@180000 {
compatible = "fsl,t1040-diu", "fsl,diu";
- reg = <0x180000 1000>;
+ reg = <0x180000 1000 0xfc028 4>;
interrupts = <74 2 0 0>;
};
If saving the pixel clock register likes a hackish. We can provide more information in the node to move the pixel clock settings to the driver. It seems that we only need to provide another parameter(the ratio) for pixel clock setting.
> Also, use dev_info() instead of pr_err, and never use exclamation marks
> in driver messages.
Ok, Thanks.
^ permalink raw reply
* RE: [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Jason.Jin @ 2014-03-27 3:38 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <53339C96.3070406@tabi.org>
> Jason.Jin@freescale.com wrote:
> >>>>> However, the DIU is already initialized in u-boot and we can rely
> >>>>> on the settings in u-boot for corenet platform,
> >>>
> >>> I don't like that at all.
> > [Jason Jin-R64188] What's the potential issue of this? Most of the IPs
> > need the platform initialization in u-boot. For example, the hwconfig
> > in u-boot used for board specific settings for most platform.
>
> The potential problem is that it's not stable. Power management breaks
> your code.
>
> I won't NACK your patch, but it feels like a band-aid rather than a real
> solution.
>
[Jason Jin-R64188] Thanks. The power management will break the pixel clock only. We can try to fix it separately. I'll try to explain it in that mail.
^ permalink raw reply
* Re: [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Timur Tabi @ 2014-03-27 3:35 UTC (permalink / raw)
To: Jason.Jin@freescale.com
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <f6883c3f759a4544936acec5dc7e542b@BLUPR03MB373.namprd03.prod.outlook.com>
Jason.Jin@freescale.com wrote:
>>>>> However, the DIU is already initialized in u-boot and we can
>>>>> rely on the settings in u-boot for corenet platform,
>>>
>>> I don't like that at all.
> [Jason Jin-R64188] What's the potential issue of this? Most of the
> IPs need the platform initialization in u-boot. For example, the
> hwconfig in u-boot used for board specific settings for most
> platform.
The potential problem is that it's not stable. Power management breaks
your code.
I won't NACK your patch, but it feels like a band-aid rather than a real
solution.
^ permalink raw reply
* RE: [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Jason.Jin @ 2014-03-27 3:30 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <533320A0.8010507@tabi.org>
> On 03/26/2014 12:41 PM, Jason Jin wrote:
> > This board sepecific initialization mechanism is not feasible i for
> > corenet platform as the corenet platform file is a abstraction of
> > serveral platforms.
>
> You can't make it 100% abstract. The DIU driver requires some sort of
> board support. I think you can make a generic platform file for the DIU.
>
[Jason Jin-R64188] Provide the generic diu platform file is reasonable, but it is will be just the board specific initialization file collection, if we really need to reinitialize something in kernel.
> > However, the DIU is already initialized in u-boot and we can rely on
> > the settings in u-boot for corenet platform,
>
> I don't like that at all.
[Jason Jin-R64188] What's the potential issue of this? Most of the IPs need the platform initialization in u-boot. For example, the hwconfig in u-boot used for board specific settings for most platform.
The diu_ops structure is still open for any board specific initialization if the platform needed. We at least can let the platform to select to use the diu_ops or not. This is the purse for this patch.
>
> > the only
> > issue is that when DIU wake up from the deepsleep, some of the board
> > specific initialization will lost, such as the pixel clock setting.
>
> That is a BIG issue. This is why we have a platform file -- to handle
> the platform issues.
[Jason Jin-R64188] Yes, this is an issue, Actually, this is a SOC level issue, We can try to fix it in the driver by saving the pixel clock in suspend function and restored it in resume function.
Thanks.
^ permalink raw reply
* [PATCH] video: Check EDID for HDMI connection
From: cfreeman @ 2014-03-26 22:35 UTC (permalink / raw)
To: linux-fbdev
From: David Ung <davidu@nvidia.com>
Check EDID Vendor Specific Data Block bytes to see if the connection
is HDMI and set FB_MISC_HDMI.
Signed-off-by: David Ung <davidu@nvidia.com>
Signed-off-by: Christopher Freeman<cfreeman@nvidia.com>
---
drivers/video/fbmon.c | 9 ++++++++-
include/linux/fb.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 6103fa6..3ac6367 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1012,13 +1012,20 @@ void fb_edid_add_monspecs(unsigned char *edid, struct fb_monspecs *specs)
while (pos < edid[2]) {
u8 len = edid[pos] & 0x1f, type = (edid[pos] >> 5) & 7;
pr_debug("Data block %u of %u bytes\n", type, len);
- if (type = 2)
+ if (type = 2) {
for (i = pos; i < pos + len; i++) {
u8 idx = edid[pos + i] & 0x7f;
svd[svd_n++] = idx;
pr_debug("N%sative mode #%d\n",
edid[pos + i] & 0x80 ? "" : "on-n", idx);
}
+ } else if (type = 3 && len >= 3) {
+ /* Check Vendor Specific Data Block. For HDMI,
+ it is always 00-0C-03 for HDMI Licensing, LLC. */
+ if (edid[pos + 1] = 3 && edid[pos + 2] = 0xc &&
+ edid[pos + 3] = 0)
+ specs->misc |= FB_MISC_HDMI;
+ }
pos += len + 1;
}
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d49c60f..427d49d 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -47,6 +47,7 @@ struct device_node;
#define FB_MISC_PRIM_COLOR 1
#define FB_MISC_1ST_DETAIL 2 /* First Detailed Timing is preferred */
+#define FB_MISC_HDMI 4
struct fb_chroma {
__u32 redx; /* in fraction of 1024 */
__u32 greenx;
--
1.8.3.2
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply related
* Re: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Timur Tabi @ 2014-03-26 18:50 UTC (permalink / raw)
To: Jason Jin; +Cc: b07421, linux-fbdev, linuxppc-dev, r58472, Wang Dongsheng
In-Reply-To: <1395855704-19908-2-git-send-email-Jason.Jin@freescale.com>
On 03/26/2014 12:41 PM, Jason Jin wrote:
> + if (!diu_ops.set_pixel_clock) {
> + data->saved_pixel_clock = 0;
> + if (of_address_to_resource(ofdev->dev.of_node, 1, &res))
> + pr_err(KERN_ERR "No pixel clock set func and no pixel node!\n");
> + else {
> + data->pixelclk_ptr > + devm_ioremap(&ofdev->dev, res.start, resource_size(&res));
> + if (!data->pixelclk_ptr) {
> + pr_err(KERN_ERR "fslfb: could not map pixelclk register!\n");
> + ret = -ENOMEM;
> + } else
> + data->saved_pixel_clock = in_be32(data->pixelclk_ptr);
> + }
> + }
This seems very hackish. What node does ofdev point to? I wonder if
this code should be in the platform file instead.
Also, use dev_info() instead of pr_err, and never use exclamation marks
in driver messages.
^ permalink raw reply
* Re: [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Timur Tabi @ 2014-03-26 18:46 UTC (permalink / raw)
To: Jason Jin; +Cc: b07421, linux-fbdev, linuxppc-dev, r58472
In-Reply-To: <1395855704-19908-1-git-send-email-Jason.Jin@freescale.com>
On 03/26/2014 12:41 PM, Jason Jin wrote:
> This board sepecific initialization mechanism is not feasible i
> for corenet platform as the corenet platform file is a
> abstraction of serveral platforms.
You can't make it 100% abstract. The DIU driver requires some sort of
board support. I think you can make a generic platform file for the DIU.
> However, the DIU is already initialized in u-boot and we can
> rely on the settings in u-boot for corenet platform,
I don't like that at all.
> the only
> issue is that when DIU wake up from the deepsleep, some of the
> board specific initialization will lost, such as the pixel clock
> setting.
That is a BIG issue. This is why we have a platform file -- to handle
the platform issues.
^ permalink raw reply
* [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Jason Jin @ 2014-03-26 17:41 UTC (permalink / raw)
To: b07421, timur; +Cc: linux-fbdev, linuxppc-dev, r58472, Wang Dongsheng
In-Reply-To: <1395855704-19908-1-git-send-email-Jason.Jin@freescale.com>
For sleep, The diu module will power off and when
wake up for initialization will need.
Some platform such as the corenet plafrom does not provide
the DIU board sepecific initialization, but rely on the
DIU initializtion in u-boot. then the pixel clock resume will
be an issuel on this platform, This patch save the pixel clock
for diu before enter the deepsleep and then restore it after
resume, the extra pixelclock register information will be needed
in this situation.
Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
---
v2: clean up the resume function based on Timur's comments.
Add the pixel clock saving for the platforms without board sepecific
initializaton.
drivers/video/fsl-diu-fb.c | 34 ++++++++++++++++++++++++++++++++--
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 4640846..fbdd166 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -372,6 +372,7 @@ struct fsl_diu_data {
unsigned int irq;
enum fsl_diu_monitor_port monitor_port;
struct diu __iomem *diu_reg;
+ void __iomem *pixelclk_ptr;
spinlock_t reg_lock;
u8 dummy_aoi[4 * 4 * 4];
struct diu_ad dummy_ad __aligned(8);
@@ -383,6 +384,7 @@ struct fsl_diu_data {
__le16 blank_cursor[MAX_CURS * MAX_CURS] __aligned(32);
uint8_t edid_data[EDID_LENGTH];
bool has_edid;
+ u32 saved_pixel_clock;
} __aligned(32);
/* Determine the DMA address of a member of the fsl_diu_data structure */
@@ -1625,19 +1627,47 @@ static irqreturn_t fsl_diu_isr(int irq, void *dev_id)
static int fsl_diu_suspend(struct platform_device *ofdev, pm_message_t state)
{
struct fsl_diu_data *data;
+ struct resource res;
+ int ret;
+ ret = 0;
data = dev_get_drvdata(&ofdev->dev);
disable_lcdc(data->fsl_diu_info);
- return 0;
+ if (!diu_ops.set_pixel_clock) {
+ data->saved_pixel_clock = 0;
+ if (of_address_to_resource(ofdev->dev.of_node, 1, &res))
+ pr_err(KERN_ERR "No pixel clock set func and no pixel node!\n");
+ else {
+ data->pixelclk_ptr + devm_ioremap(&ofdev->dev, res.start, resource_size(&res));
+ if (!data->pixelclk_ptr) {
+ pr_err(KERN_ERR "fslfb: could not map pixelclk register!\n");
+ ret = -ENOMEM;
+ } else
+ data->saved_pixel_clock = in_be32(data->pixelclk_ptr);
+ }
+ }
+
+ return ret;
}
static int fsl_diu_resume(struct platform_device *ofdev)
{
struct fsl_diu_data *data;
+ unsigned int i;
data = dev_get_drvdata(&ofdev->dev);
- enable_lcdc(data->fsl_diu_info);
+ if (!diu_ops.set_pixel_clock && data->pixelclk_ptr)
+ out_be32(data->pixelclk_ptr, data->saved_pixel_clock);
+
+ fsl_diu_enable_interrupts(data);
+ update_lcdc(data->fsl_diu_info);
+
+ for (i = 0; i < NUM_AOIS; i++) {
+ if (data->mfb[i].count)
+ fsl_diu_enable_panel(&data->fsl_diu_info[i]);
+ }
return 0;
}
--
1.8.0
^ permalink raw reply related
* [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Jason Jin @ 2014-03-26 17:41 UTC (permalink / raw)
To: b07421, timur; +Cc: linux-fbdev, linuxppc-dev, r58472
make the diu driver work without platform hooks.
So far the DIU driver does not have a mechanism to do the
board specific initialization. So on some platforms,
such as P1022, 8610 and 5121, The board specific initialization
is implmented in the platform file such p10222_ds.
This board sepecific initialization mechanism is not feasible i
for corenet platform as the corenet platform file is a
abstraction of serveral platforms.
However, the DIU is already initialized in u-boot and we can
rely on the settings in u-boot for corenet platform, the only
issue is that when DIU wake up from the deepsleep, some of the
board specific initialization will lost, such as the pixel clock
setting.
This patch try to make the diu work on the platform without board
specific initialization such as corenet(T1040 so far), and rely on
the board initialization in u-boot. The following patch will try to
fix the pixel clock saving issue for deepsleep.
Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
---
drivers/video/fsl-diu-fb.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index e8758b9..4640846 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -479,7 +479,10 @@ static enum fsl_diu_monitor_port fsl_diu_name_to_port(const char *s)
port = FSL_DIU_PORT_DLVDS;
}
- return diu_ops.valid_monitor_port(port);
+ if (diu_ops.valid_monitor_port)
+ return diu_ops.valid_monitor_port(port);
+ else
+ return port;
}
/*
@@ -846,7 +849,11 @@ static void update_lcdc(struct fb_info *info)
out_be32(&hw->vsyn_para, temp);
- diu_ops.set_pixel_clock(var->pixclock);
+ /*if there is platform function for pixel clock setting, use it.
+ * otherwise we rely on the settings in u-boot.
+ */
+ if (diu_ops.set_pixel_clock)
+ diu_ops.set_pixel_clock(var->pixclock);
#ifndef CONFIG_PPC_MPC512x
/*
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] video: da8xx-fb: Add support for Densitron 84-0023-001T
From: Jon Ringle @ 2014-03-26 16:56 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen
Cc: linux-fbdev, linux-kernel@vger.kernel.org, Jon Ringle
In-Reply-To: <1394042711-7907-1-git-send-email-jon@ringle.org>
I've not heard anything regarding this patch. I just want to make sure
it's not lost :)
Jon
On Wed, Mar 5, 2014 at 1:05 PM, <jon@ringle.org> wrote:
> From: Jon Ringle <jringle@gridpoint.com>
>
> Signed-off-by: Jon Ringle <jringle@gridpoint.com>
> ---
> drivers/video/da8xx-fb.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index e7f5937..83c43b2 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -243,6 +243,20 @@ static struct fb_videomode known_lcd_panels[] = {
> .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
> .flag = 0,
> },
> + [3] = {
> + /* Densitron 84-0023-001T */
> + .name = "Densitron_LCD",
> + .xres = 320,
> + .yres = 240,
> + .pixclock = KHZ2PICOS(6400),
> + .left_margin = 0,
> + .right_margin = 0,
> + .upper_margin = 0,
> + .lower_margin = 0,
> + .hsync_len = 30,
> + .vsync_len = 3,
> + .sync = 0,
> + },
> };
>
> static bool da8xx_fb_is_raster_enabled(void)
> --
> 1.8.5.4
>
^ permalink raw reply
* Re: [PATCH] video: da8xx-fb: Fix casting of info->pseudo_palette
From: Jon Ringle @ 2014-03-26 16:56 UTC (permalink / raw)
To: linux-fbdev, linux-kernel@vger.kernel.org; +Cc: Jon Ringle
In-Reply-To: <1394007599-31429-1-git-send-email-jon@ringle.org>
I've not heard anything regarding this patch. I just want to make sure
it's not lost :)
Jon
On Wed, Mar 5, 2014 at 3:19 AM, <jon@ringle.org> wrote:
> From: Jon Ringle <jringle@gridpoint.com>
>
> (Resending without corporate disclaimer in email footer)
>
> The casting to (u16 *) on info->pseudo_palette is wrong and causes the
> display to show a blue (garbage) vertical line on every other pixel column
>
> Signed-off-by: Jon Ringle <jringle@gridpoint.com>
> ---
> drivers/video/da8xx-fb.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index d042624..83c43b2 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -678,15 +678,7 @@ static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
> (green << info->var.green.offset) |
> (blue << info->var.blue.offset);
>
> - switch (info->var.bits_per_pixel) {
> - case 16:
> - ((u16 *) (info->pseudo_palette))[regno] = v;
> - break;
> - case 24:
> - case 32:
> - ((u32 *) (info->pseudo_palette))[regno] = v;
> - break;
> - }
> + ((u32 *) (info->pseudo_palette))[regno] = v;
> if (palette[0] != 0x4000) {
> update_hw = 1;
> palette[0] = 0x4000;
> --
> 1.8.5.4
>
^ permalink raw reply
* Re: [PATCH] video/fsl: Fix the sleep function for FSL DIU module
From: Timur Tabi @ 2014-03-25 15:54 UTC (permalink / raw)
To: Dongsheng Wang; +Cc: scottwood, linux-fbdev, linuxppc-dev, jason.jin
In-Reply-To: <1395734180-45012-1-git-send-email-dongsheng.wang@freescale.com>
On 03/25/2014 02:56 AM, Dongsheng Wang wrote:
> From: Jason Jin <Jason.Jin@freescale.com>
>
> For deep sleep, the diu module will power off, when wake up
> from the deep sleep, the registers need to be reinitialized.
>
> Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index e8758b9..7ec780c 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
> @@ -1628,9 +1628,18 @@ static int fsl_diu_suspend(struct platform_device *ofdev, pm_message_t state)
> static int fsl_diu_resume(struct platform_device *ofdev)
> {
> struct fsl_diu_data *data;
> + struct mfb_info *mfbi;
You don't need this, if ...
> + int i;
>
> data = dev_get_drvdata(&ofdev->dev);
> - enable_lcdc(data->fsl_diu_info);
> + fsl_diu_enable_interrupts(data);
> + update_lcdc(data->fsl_diu_info);
> +
> + for (i = 0; i < NUM_AOIS; i++) {
> + mfbi = &data->mfb[i];
> + if (mfbi->count)
... you do this:
if (data->mfb[i].count)
Also, 'i' should be an 'unsigned int'.
> + fsl_diu_enable_panel(&data->fsl_diu_info[i]);
> + }
>
> return 0;
> }
>
Other than that, this seems okay.
^ permalink raw reply
* [PATCH] video/fsl: Fix the sleep function for FSL DIU module
From: Dongsheng Wang @ 2014-03-25 7:56 UTC (permalink / raw)
To: scottwood, timur; +Cc: linux-fbdev, linuxppc-dev, Wang Dongsheng, Jason Jin
From: Jason Jin <Jason.Jin@freescale.com>
For deep sleep, the diu module will power off, when wake up
from the deep sleep, the registers need to be reinitialized.
Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index e8758b9..7ec780c 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -1628,9 +1628,18 @@ static int fsl_diu_suspend(struct platform_device *ofdev, pm_message_t state)
static int fsl_diu_resume(struct platform_device *ofdev)
{
struct fsl_diu_data *data;
+ struct mfb_info *mfbi;
+ int i;
data = dev_get_drvdata(&ofdev->dev);
- enable_lcdc(data->fsl_diu_info);
+ fsl_diu_enable_interrupts(data);
+ update_lcdc(data->fsl_diu_info);
+
+ for (i = 0; i < NUM_AOIS; i++) {
+ mfbi = &data->mfb[i];
+ if (mfbi->count)
+ fsl_diu_enable_panel(&data->fsl_diu_info[i]);
+ }
return 0;
}
--
1.8.5
^ permalink raw reply related
* Re: [PATCH 14/16] backlight: atmel-pwm-bl: remove obsolete driver
From: Jingoo Han @ 2014-03-25 0:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140324155412.GA9083@piout.net>
On Tuesday, March 25, 2014 12:54 AM, Alexandre Belloni wrote:
> On 21/03/2014 at 09:51:16 +0900, Jingoo Han wrote :
> > On Wednesday, March 19, 2014 11:23 PM, Hans-Christian Egtvedt wrote:
> > > Around Wed 19 Mar 2014 14:03:27 +0100 or thereabout, Alexandre Belloni wrote:
> > > > The atmel-pwm-bl driver is now obsolete. It is not used by any mainlined boards
> > > > and is replaced by the generic pwm_bl with the pawm-atmel driver using the
> > > > generic PWM framework.
> > > >
> > > > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > >
> > > Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> >
> > Acked-by: Jingoo Han <jg1.han@samsung.com>
> >
>
> You didn't comment on patch 08/16, are you fine with it ? I guess this
> is the only one holding back the full series.
'drivers/video/backlight/pwm_bl.c' is Thierry Reding's domain,
as follows.
PWM SUBSYSTEM
M: Thierry Reding <thierry.reding@gmail.com>
L: linux-pwm@vger.kernel.org
S: Maintained
.....
F: drivers/video/backlight/pwm_bl.c
So, it is required to get Ack from Thierry Reding.
Best regards,
Jingoo Han
>
> Regards,
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 14/16] backlight: atmel-pwm-bl: remove obsolete driver
From: Alexandre Belloni @ 2014-03-24 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000101cf449f$aa609960$ff21cc20$%han@samsung.com>
Hi,
On 21/03/2014 at 09:51:16 +0900, Jingoo Han wrote :
> On Wednesday, March 19, 2014 11:23 PM, Hans-Christian Egtvedt wrote:
> > Around Wed 19 Mar 2014 14:03:27 +0100 or thereabout, Alexandre Belloni wrote:
> > > The atmel-pwm-bl driver is now obsolete. It is not used by any mainlined boards
> > > and is replaced by the generic pwm_bl with the pawm-atmel driver using the
> > > generic PWM framework.
> > >
> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> >
> > Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
>
> Acked-by: Jingoo Han <jg1.han@samsung.com>
>
You didn't comment on patch 08/16, are you fine with it ? I guess this
is the only one holding back the full series.
Regards,
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: How to make framebuffer look like a real monitor?
From: Tormod Volden @ 2014-03-22 10:39 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CADAXeK1HznKm6AuWa1431i0u+GSKkXq0u3FWMFvbHU95FJQbzg@mail.gmail.com>
>> On Fri, Mar 21, 2014 at 3:30 PM, Ivan Drobyshevskyi wrote:
>>> Is there a way to make X treat Linux framebuffer device (e.g. /dev/fb0
>>> backed by virtual framebuffer) as a real display? Ideally it should
>>> appear in system display settings as a configurable monitor. Does it
>>> require writing some kernel code or it's possible to somehow get away
>>> with for example X configuration?
>>
>> If I understand your question correctly, you are asking for the xorg
>> fbdev driver:
>> http://www.x.org/releases/current/doc/man/man4/fbdev.4.xhtml
>
> Thank you, that could work. As I understand, using fbdev doesn't
> support hotplug and the only way to setup it is via xorg.conf editing?
>
> (in short, I need to create a virtual GPU that is treated as a real
> one by desktop environment but instead of actual rendering only
> writing to framebuffer in RAM is required).
Does it have to be a linux-fbdev driver? There are virtual xorg
drivers (xf86-video-dummy?) or servers (Xfvb) that you can use like
this, all in user-space. Or you create a DRM driver (à la the
experimental SimpleDRM driver from dri-devel@lists.freedesktop.org)
and use the xorg xf86-modesetting driver on top of it. However I don't
know if these examples support the kind of hotplug you want in their
current status.
Tormod
^ 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