* [RFC] Add co-maintainer for fbdev
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-24 15:38 UTC (permalink / raw)
To: linux-fbdev; +Cc: Arnd Bergmann, Linus Torvalds, linux-kernel, Tomi Valkeinen
Hi Florian,
As you seems very busy I'd like to propose the help you to handle the
fbdev subsystem to easier the rich of the fbdev patch to Linus
As I'm working on fbdev on at91 and others and already Co-Maintain the
at91 mach on ARM
And if you are not willing to continue I could take over
Best Regards,
J.
^ permalink raw reply
* Re: [RFC] Add co-maintainer for fbdev
From: Olof Johansson @ 2013-05-24 17:30 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-fbdev, Arnd Bergmann, Linus Torvalds,
linux-kernel@vger.kernel.org, Tomi Valkeinen, Andrew Morton
In-Reply-To: <20130524153835.GF15839@game.jcrosoft.org>
[+akpm]
On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> Hi Florian,
>
> As you seems very busy I'd like to propose the help you to handle the
> fbdev subsystem to easier the rich of the fbdev patch to Linus
>
> As I'm working on fbdev on at91 and others and already Co-Maintain the
> at91 mach on ARM
>
> And if you are not willing to continue I could take over
Andrew has been fallback fbdev maintainer for a while, we have the
option of formalizing that as well. Adding him on cc so he sees this.
-Olof
^ permalink raw reply
* Re: [RFC] Add co-maintainer for fbdev
From: Arnd Bergmann @ 2013-05-24 18:56 UTC (permalink / raw)
To: Olof Johansson
Cc: Jean-Christophe PLAGNIOL-VILLARD, linux-fbdev, Linus Torvalds,
linux-kernel@vger.kernel.org, Tomi Valkeinen, Andrew Morton,
Florian Tobias Schandinat
In-Reply-To: <CAOesGMj26_=6eQk+=0MPCoobymqrHPwwtiUnv63hz0a9Ou_VMw@mail.gmail.com>
On Friday 24 May 2013, Olof Johansson wrote:
> [+akpm]
[+florian]
> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > Hi Florian,
> >
> > As you seems very busy I'd like to propose the help you to handle the
> > fbdev subsystem to easier the rich of the fbdev patch to Linus
> >
> > As I'm working on fbdev on at91 and others and already Co-Maintain the
> > at91 mach on ARM
> >
> > And if you are not willing to continue I could take over
>
> Andrew has been fallback fbdev maintainer for a while, we have the
> option of formalizing that as well. Adding him on cc so he sees this.
It seems that Florian himself was missing on Cc too, probably by accident.
I would certainly welcome Jean-Christophe to step in for fbdev, since I
frequently have trivial patches for the subsystem, either from myself
or one of the subarch maintainers, and it would be helpful to get feedback
on them in order to merge them through arm-soc when they depend on other
patches we carry, or to have them picked up into a git tree.
Arnd
^ permalink raw reply
* [PATCH v6] video: imxfb: Add DT support
From: Markus Pargmann @ 2013-05-26 10:35 UTC (permalink / raw)
To: linux-arm-kernel
Add devicetree support for imx framebuffer driver. It uses the generic
display bindings and helper functions.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
Notes:
Changed in v6:
- Rebased onto v3.10-rc2
- Dropped alpha support patch in this series
Changed in v5:
- Fix compatible property of the example
- Rename property fsl,bpp to bits-per-pixel
- Add selects for FB_MODE_HELPERS and VIDEOMODE_HELPERS to Kconfig FB_IMX
Changes in v4:
- Remove eukrea specific dmacr property.
- Add optional dmacr property. If not present, the dmacr reset value is not
changed.
Changes in v3:
- Fix returncodes of of_read_mode function and print error messages
- Introduce a lower bound check for bits per pixel
- Calculate correct bytes per pixel value before using it for the calculation of
memory size
- Change DT property names
Changes in v2:
- Removed pwmr register property
- Cleanup of devicetree binding documentation
- Use default values for pwmr and lscr1
.../devicetree/bindings/video/fsl,imx-fb.txt | 51 ++++++
drivers/video/Kconfig | 2 +
drivers/video/imxfb.c | 194 +++++++++++++++++----
3 files changed, 212 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt
diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
new file mode 100644
index 0000000..46da08d
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -0,0 +1,51 @@
+Freescale imx21 Framebuffer
+
+This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
+
+Required properties:
+- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : One interrupt of the fb dev
+
+Required nodes:
+- display: Phandle to a display node as described in
+ Documentation/devicetree/bindings/video/display-timing.txt
+ Additional, the display node has to define properties:
+ - bits-per-pixel: Bits per pixel
+ - fsl,pcr: LCDC PCR value
+
+Optional properties:
+- fsl,dmacr: DMA Control Register value. This is optional. By default, the
+ register is not modified as recommended by the datasheet.
+- fsl,lscr1: LCDC Sharp Configuration Register value.
+
+Example:
+
+ imxfb: fb@10021000 {
+ compatible = "fsl,imx21-fb";
+ interrupts = <61>;
+ reg = <0x10021000 0x1000>;
+ display = <&display0>;
+ };
+
+ ...
+
+ display0: display0 {
+ model = "Primeview-PD050VL1";
+ native-mode = <&timing_disp0>;
+ bits-per-pixel = <16>;
+ fsl,pcr = <0xf0c88080>; /* non-standard but required */
+ display-timings {
+ timing_disp0: 640x480 {
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <112>;
+ hfront-porch = <36>;
+ hsync-len = <32>;
+ vback-porch = <33>;
+ vfront-porch = <33>;
+ vsync-len = <2>;
+ clock-frequency = <25000000>;
+ };
+ };
+ };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d71d60f..588af1d 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -367,6 +367,8 @@ config FB_IMX
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_MODE_HELPERS
+ select VIDEOMODE_HELPERS
config FB_CYBER2000
tristate "CyberPro 2000/2010/5000 support"
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 0abf2bf..a2ed71d 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -31,6 +31,12 @@
#include <linux/dma-mapping.h>
#include <linux/io.h>
#include <linux/math64.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+
+#include <video/of_display_timing.h>
+#include <video/of_videomode.h>
+#include <video/videomode.h>
#include <linux/platform_data/video-imxfb.h>
@@ -112,10 +118,11 @@
#define LCDISR_EOF (1<<1)
#define LCDISR_BOF (1<<0)
+#define IMXFB_LSCR1_DEFAULT 0x00120300
+
/* Used fb-mode. Can be set on kernel command line, therefore file-static. */
static const char *fb_mode;
-
/*
* These are the bitfields for each
* display depth that we support.
@@ -187,6 +194,19 @@ static struct platform_device_id imxfb_devtype[] = {
};
MODULE_DEVICE_TABLE(platform, imxfb_devtype);
+static struct of_device_id imxfb_of_dev_id[] = {
+ {
+ .compatible = "fsl,imx1-fb",
+ .data = &imxfb_devtype[IMX1_FB],
+ }, {
+ .compatible = "fsl,imx21-fb",
+ .data = &imxfb_devtype[IMX21_FB],
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, imxfb_of_dev_id);
+
static inline int is_imx1_fb(struct imxfb_info *fbi)
{
return fbi->devtype = IMX1_FB;
@@ -319,6 +339,9 @@ static const struct imx_fb_videomode *imxfb_find_mode(struct imxfb_info *fbi)
struct imx_fb_videomode *m;
int i;
+ if (!fb_mode)
+ return &fbi->mode[0];
+
for (i = 0, m = &fbi->mode[0]; i < fbi->num_modes; i++, m++) {
if (!strcmp(m->mode.name, fb_mode))
return m;
@@ -474,6 +497,9 @@ static int imxfb_bl_update_status(struct backlight_device *bl)
struct imxfb_info *fbi = bl_get_data(bl);
int brightness = bl->props.brightness;
+ if (!fbi->pwmr)
+ return 0;
+
if (bl->props.power != FB_BLANK_UNBLANK)
brightness = 0;
if (bl->props.fb_blank != FB_BLANK_UNBLANK)
@@ -684,10 +710,14 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
writel(fbi->pcr, fbi->regs + LCDC_PCR);
#ifndef PWMR_BACKLIGHT_AVAILABLE
- writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
+ if (fbi->pwmr)
+ writel(fbi->pwmr, fbi->regs + LCDC_PWMR);
#endif
writel(fbi->lscr1, fbi->regs + LCDC_LSCR1);
- writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
+
+ /* dmacr = 0 is no valid value, as we need DMA control marks. */
+ if (fbi->dmacr)
+ writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
return 0;
}
@@ -723,13 +753,12 @@ static int imxfb_resume(struct platform_device *dev)
#define imxfb_resume NULL
#endif
-static int __init imxfb_init_fbinfo(struct platform_device *pdev)
+static int imxfb_init_fbinfo(struct platform_device *pdev)
{
struct imx_fb_platform_data *pdata = pdev->dev.platform_data;
struct fb_info *info = dev_get_drvdata(&pdev->dev);
struct imxfb_info *fbi = info->par;
- struct imx_fb_videomode *m;
- int i;
+ struct device_node *np;
pr_debug("%s\n",__func__);
@@ -760,41 +789,95 @@ static int __init imxfb_init_fbinfo(struct platform_device *pdev)
info->fbops = &imxfb_ops;
info->flags = FBINFO_FLAG_DEFAULT |
FBINFO_READS_FAST;
- info->var.grayscale = pdata->cmap_greyscale;
- fbi->cmap_inverse = pdata->cmap_inverse;
- fbi->cmap_static = pdata->cmap_static;
- fbi->lscr1 = pdata->lscr1;
- fbi->dmacr = pdata->dmacr;
- fbi->pwmr = pdata->pwmr;
- fbi->lcd_power = pdata->lcd_power;
- fbi->backlight_power = pdata->backlight_power;
-
- for (i = 0, m = &pdata->mode[0]; i < pdata->num_modes; i++, m++)
- info->fix.smem_len = max_t(size_t, info->fix.smem_len,
- m->mode.xres * m->mode.yres * m->bpp / 8);
+ if (pdata) {
+ info->var.grayscale = pdata->cmap_greyscale;
+ fbi->cmap_inverse = pdata->cmap_inverse;
+ fbi->cmap_static = pdata->cmap_static;
+ fbi->lscr1 = pdata->lscr1;
+ fbi->dmacr = pdata->dmacr;
+ fbi->pwmr = pdata->pwmr;
+ fbi->lcd_power = pdata->lcd_power;
+ fbi->backlight_power = pdata->backlight_power;
+ } else {
+ np = pdev->dev.of_node;
+ info->var.grayscale = of_property_read_bool(np,
+ "cmap-greyscale");
+ fbi->cmap_inverse = of_property_read_bool(np, "cmap-inverse");
+ fbi->cmap_static = of_property_read_bool(np, "cmap-static");
+
+ fbi->lscr1 = IMXFB_LSCR1_DEFAULT;
+ of_property_read_u32(np, "fsl,lscr1", &fbi->lscr1);
+
+ of_property_read_u32(np, "fsl,dmacr", &fbi->dmacr);
+
+ /* These two function pointers could be used by some specific
+ * platforms. */
+ fbi->lcd_power = NULL;
+ fbi->backlight_power = NULL;
+ }
+
+ return 0;
+}
+
+static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
+ struct imx_fb_videomode *imxfb_mode)
+{
+ int ret;
+ struct fb_videomode *of_mode = &imxfb_mode->mode;
+ u32 bpp;
+ u32 pcr;
+
+ ret = of_property_read_string(np, "model", &of_mode->name);
+ if (ret)
+ of_mode->name = NULL;
+
+ ret = of_get_fb_videomode(np, of_mode, OF_USE_NATIVE_MODE);
+ if (ret) {
+ dev_err(dev, "Failed to get videomode from DT\n");
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "bits-per-pixel", &bpp);
+ ret |= of_property_read_u32(np, "fsl,pcr", &pcr);
+
+ if (ret) {
+ dev_err(dev, "Failed to read bpp and pcr from DT\n");
+ return -EINVAL;
+ }
+
+ if (bpp < 1 || bpp > 255) {
+ dev_err(dev, "Bits per pixel have to be between 1 and 255\n");
+ return -EINVAL;
+ }
+
+ imxfb_mode->bpp = bpp;
+ imxfb_mode->pcr = pcr;
return 0;
}
-static int __init imxfb_probe(struct platform_device *pdev)
+static int imxfb_probe(struct platform_device *pdev)
{
struct imxfb_info *fbi;
struct fb_info *info;
struct imx_fb_platform_data *pdata;
struct resource *res;
+ struct imx_fb_videomode *m;
+ const struct of_device_id *of_id;
int ret, i;
+ int bytes_per_pixel;
dev_info(&pdev->dev, "i.MX Framebuffer driver\n");
+ of_id = of_match_device(imxfb_of_dev_id, &pdev->dev);
+ if (of_id)
+ pdev->id_entry = of_id->data;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENODEV;
pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev,"No platform_data available\n");
- return -ENOMEM;
- }
info = framebuffer_alloc(sizeof(struct imxfb_info), &pdev->dev);
if (!info)
@@ -802,15 +885,55 @@ static int __init imxfb_probe(struct platform_device *pdev)
fbi = info->par;
- if (!fb_mode)
- fb_mode = pdata->mode[0].mode.name;
-
platform_set_drvdata(pdev, info);
ret = imxfb_init_fbinfo(pdev);
if (ret < 0)
goto failed_init;
+ if (pdata) {
+ if (!fb_mode)
+ fb_mode = pdata->mode[0].mode.name;
+
+ fbi->mode = pdata->mode;
+ fbi->num_modes = pdata->num_modes;
+ } else {
+ struct device_node *display_np;
+ fb_mode = NULL;
+
+ display_np = of_parse_phandle(pdev->dev.of_node, "display", 0);
+ if (!display_np) {
+ dev_err(&pdev->dev, "No display defined in devicetree\n");
+ ret = -EINVAL;
+ goto failed_of_parse;
+ }
+
+ /*
+ * imxfb does not support more modes, we choose only the native
+ * mode.
+ */
+ fbi->num_modes = 1;
+
+ fbi->mode = devm_kzalloc(&pdev->dev,
+ sizeof(struct imx_fb_videomode), GFP_KERNEL);
+ if (!fbi->mode) {
+ ret = -ENOMEM;
+ goto failed_of_parse;
+ }
+
+ ret = imxfb_of_read_mode(&pdev->dev, display_np, fbi->mode);
+ if (ret)
+ goto failed_of_parse;
+ }
+
+ /* Calculate maximum bytes used per pixel. In most cases this should
+ * be the same as m->bpp/8 */
+ m = &fbi->mode[0];
+ bytes_per_pixel = (m->bpp + 7) / 8;
+ for (i = 0; i < fbi->num_modes; i++, m++)
+ info->fix.smem_len = max_t(size_t, info->fix.smem_len,
+ m->mode.xres * m->mode.yres * bytes_per_pixel);
+
res = request_mem_region(res->start, resource_size(res),
DRIVER_NAME);
if (!res) {
@@ -843,7 +966,8 @@ static int __init imxfb_probe(struct platform_device *pdev)
goto failed_ioremap;
}
- if (!pdata->fixed_screen_cpu) {
+ /* Seems not being used by anyone, so no support for oftree */
+ if (!pdata || !pdata->fixed_screen_cpu) {
fbi->map_size = PAGE_ALIGN(info->fix.smem_len);
fbi->map_cpu = dma_alloc_writecombine(&pdev->dev,
fbi->map_size, &fbi->map_dma, GFP_KERNEL);
@@ -868,18 +992,16 @@ static int __init imxfb_probe(struct platform_device *pdev)
info->fix.smem_start = fbi->screen_dma;
}
- if (pdata->init) {
+ if (pdata && pdata->init) {
ret = pdata->init(fbi->pdev);
if (ret)
goto failed_platform_init;
}
- fbi->mode = pdata->mode;
- fbi->num_modes = pdata->num_modes;
INIT_LIST_HEAD(&info->modelist);
- for (i = 0; i < pdata->num_modes; i++)
- fb_add_videomode(&pdata->mode[i].mode, &info->modelist);
+ for (i = 0; i < fbi->num_modes; i++)
+ fb_add_videomode(&fbi->mode[i].mode, &info->modelist);
/*
* This makes sure that our colour bitfield
@@ -909,10 +1031,10 @@ static int __init imxfb_probe(struct platform_device *pdev)
failed_register:
fb_dealloc_cmap(&info->cmap);
failed_cmap:
- if (pdata->exit)
+ if (pdata && pdata->exit)
pdata->exit(fbi->pdev);
failed_platform_init:
- if (!pdata->fixed_screen_cpu)
+ if (pdata && !pdata->fixed_screen_cpu)
dma_free_writecombine(&pdev->dev,fbi->map_size,fbi->map_cpu,
fbi->map_dma);
failed_map:
@@ -921,6 +1043,7 @@ failed_ioremap:
failed_getclock:
release_mem_region(res->start, resource_size(res));
failed_req:
+failed_of_parse:
kfree(info->pseudo_palette);
failed_init:
platform_set_drvdata(pdev, NULL);
@@ -945,7 +1068,7 @@ static int imxfb_remove(struct platform_device *pdev)
unregister_framebuffer(info);
pdata = pdev->dev.platform_data;
- if (pdata->exit)
+ if (pdata && pdata->exit)
pdata->exit(fbi->pdev);
fb_dealloc_cmap(&info->cmap);
@@ -974,6 +1097,7 @@ static struct platform_driver imxfb_driver = {
.shutdown = imxfb_shutdown,
.driver = {
.name = DRIVER_NAME,
+ .of_match_table = imxfb_of_dev_id,
},
.id_table = imxfb_devtype,
};
--
1.8.2.1
^ permalink raw reply related
* [PATCH v8, part3 06/14] mm, acornfb: use free_reserved_area() to simplify code
From: Jiang Liu @ 2013-05-26 13:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Jiang Liu, David Rientjes, Wen Congyang, Mel Gorman, Minchan Kim,
KAMEZAWA Hiroyuki, Michal Hocko, James Bottomley, Sergei Shtylyov,
David Howells, Mark Salter, Jianguo Wu, linux-mm, linux-arch,
linux-kernel, Florian Tobias Schandinat, linux-fbdev
In-Reply-To: <1369575522-26405-1-git-send-email-jiang.liu@huawei.com>
Use common help function free_reserved_area() to simplify code.
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/video/acornfb.c | 45 ++++++---------------------------------------
1 file changed, 6 insertions(+), 39 deletions(-)
diff --git a/drivers/video/acornfb.c b/drivers/video/acornfb.c
index 6488a73..8f7374f 100644
--- a/drivers/video/acornfb.c
+++ b/drivers/video/acornfb.c
@@ -1180,42 +1180,6 @@ static int acornfb_detect_monitortype(void)
return 4;
}
-/*
- * This enables the unused memory to be freed on older Acorn machines.
- * We are freeing memory on behalf of the architecture initialisation
- * code here.
- */
-static inline void
-free_unused_pages(unsigned int virtual_start, unsigned int virtual_end)
-{
- int mb_freed = 0;
-
- /*
- * Align addresses
- */
- virtual_start = PAGE_ALIGN(virtual_start);
- virtual_end = PAGE_ALIGN(virtual_end);
-
- while (virtual_start < virtual_end) {
- struct page *page;
-
- /*
- * Clear page reserved bit,
- * set count to 1, and free
- * the page.
- */
- page = virt_to_page(virtual_start);
- ClearPageReserved(page);
- init_page_count(page);
- free_page(virtual_start);
-
- virtual_start += PAGE_SIZE;
- mb_freed += PAGE_SIZE / 1024;
- }
-
- printk("acornfb: freed %dK memory\n", mb_freed);
-}
-
static int acornfb_probe(struct platform_device *dev)
{
unsigned long size;
@@ -1312,10 +1276,13 @@ static int acornfb_probe(struct platform_device *dev)
#endif
#if defined(HAS_VIDC)
/*
- * Archimedes/A5000 machines use a fixed address for their
- * framebuffers. Free unused pages
+ * We are freeing memory on behalf of the architecture initialisation
+ * code here. Archimedes/A5000 machines use a fixed address for their
+ * framebuffers.
*/
- free_unused_pages(PAGE_OFFSET + size, PAGE_OFFSET + MAX_SIZE);
+ free_reserved_area((void *)(PAGE_OFFSET + size),
+ (void *)PAGE_ALIGN(PAGE_OFFSET + MAX_SIZE),
+ -1, "acornfb");
#endif
fb_info.fix.smem_len = size;
--
1.8.1.2
^ permalink raw reply related
* Re: [RFC] Add co-maintainer for fbdev
From: Florian Tobias Schandinat @ 2013-05-26 23:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Olof Johansson, Jean-Christophe PLAGNIOL-VILLARD, linux-fbdev,
Linus Torvalds, linux-kernel@vger.kernel.org, Tomi Valkeinen,
Andrew Morton
In-Reply-To: <201305242056.42482.arnd@arndb.de>
Hi Jean-Christophe,
On 05/24/2013 06:56 PM, Arnd Bergmann wrote:
> On Friday 24 May 2013, Olof Johansson wrote:
>> [+akpm]
>
> [+florian]
Thanks for CC'ing me. Lately I got dropped frequently from the
mailinglist (after 1 or 2 days). Guess I should try subscribing via my
own mail server.
>> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
>> <plagnioj@jcrosoft.com> wrote:
>>> Hi Florian,
>>>
>>> As you seems very busy I'd like to propose the help you to handle the
>>> fbdev subsystem to easier the rich of the fbdev patch to Linus
>>>
>>> As I'm working on fbdev on at91 and others and already Co-Maintain the
>>> at91 mach on ARM
>>>
>>> And if you are not willing to continue I could take over
Yeah, it would be great if you could help, at the moment I get barely
any sleep, let alone that I could keep up with the majority of mail I
get. I'll let you decide whether you want to be sole maintainer or not.
I still have interest in the subsystem, but it looks like VIA won't
provide any information for their new VX11 chipset IGP for any open
source driver and I'm still looking for a small, quiet mobile device as
a replacement for my precious netbook that broke down last autumn to
allow me working when I'm not at home.
>> Andrew has been fallback fbdev maintainer for a while, we have the
>> option of formalizing that as well. Adding him on cc so he sees this.
At this point I'd like to thank all people who have helped out so far,
especially Tomi and Andrew.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Thank you from Google.
From: Google+ @ 2013-05-27 0:37 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
Dear Google User.
Attached to this email is your anniversary notification for being an active user of Google.
Sincerely.
Dr. Donald Lloyd.
Google Promotion Award Team.
----------------------------------------------------------------
This message was sent using Google Messaging Program (GMP).
[-- Attachment #2: GPA Notification.pdf --]
[-- Type: application/pdf, Size: 54226 bytes --]
^ permalink raw reply
* [PATCH] video: mxsfb: Let device core handle pinctrl
From: Fabio Estevam @ 2013-05-27 1:48 UTC (permalink / raw)
To: linux-fbdev
From: Fabio Estevam <fabio.estevam@freescale.com>
Since commit ab78029 (drivers/pinctrl: grab default handles from device core)
we can rely on device core for handling pinctrl, so remove
devm_pinctrl_get_select_default() from the driver.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/video/mxsfb.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 21223d4..9d6a286 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -46,7 +46,6 @@
#include <linux/clk.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
-#include <linux/pinctrl/consumer.h>
#include <linux/fb.h>
#include <linux/regulator/consumer.h>
#include <video/of_display_timing.h>
@@ -877,7 +876,6 @@ static int mxsfb_probe(struct platform_device *pdev)
struct mxsfb_info *host;
struct fb_info *fb_info;
struct fb_modelist *modelist;
- struct pinctrl *pinctrl;
int ret;
if (of_id)
@@ -909,12 +907,6 @@ static int mxsfb_probe(struct platform_device *pdev)
host->devdata = &mxsfb_devdata[pdev->id_entry->driver_data];
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl)) {
- ret = PTR_ERR(pinctrl);
- goto fb_release;
- }
-
host->clk = devm_clk_get(&host->pdev->dev, NULL);
if (IS_ERR(host->clk)) {
ret = PTR_ERR(host->clk);
--
1.8.1.2
^ permalink raw reply related
* [PATCH v2] video: simplefb: add mode parsing function
From: Alexandre Courbot @ 2013-05-27 3:53 UTC (permalink / raw)
To: linux-arm-kernel
The naming scheme of simplefb's mode is precise enough to allow building
the mode structure from it instead of using a static list of modes. This
patch introduces a function that does this. In case exotic modes that
cannot be represented from their name alone are needed, the static list
of modes is still available as a backup.
It also changes the order in which colors are declared from MSB first to
the more standard LSB first.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Changes from v1:
- amended documentation following Stephen's suggestion
- allow parsing of bitfields larger than 9 bits
- made it clear that the parsing order of bits is changed with respect
to the original patch
Andrew, since this patch introduces a (small) change in the DT bindings,
could we try to merge it during the -rc cycle so we don't have to come
with a more complex solution in the future?
.../bindings/video/simple-framebuffer.txt | 12 +++-
drivers/video/simplefb.c | 72 +++++++++++++++++++++-
2 files changed, 80 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 3ea4605..18d03e2 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -10,8 +10,16 @@ Required properties:
- width: The width of the framebuffer in pixels.
- height: The height of the framebuffer in pixels.
- 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).
+- format: The format of the framebuffer surface. Described as a sequence of
+ channel/num-bits pairs, where each pair describes how many bits are used
+ by a given color channel. Value channels are "r" (red), "g" (green),
+ "b" (blue), "a" (alpha) and "x" (unused). Channels are listed in bit
+ order, starting from the LSB. For instance, a format named "r5g6b5"
+ describes a 16-bit format where red is encoded in the 5 less significant
+ bits, green in the 6 following ones, and blue in the 5 last:
+ BBBBBGGG GGGRRRRR
+ ^ ^
+ MSB LSB
Example:
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index e2e9e3e..1430752 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -21,6 +21,7 @@
*/
#include <linux/errno.h>
+#include <linux/ctype.h>
#include <linux/fb.h>
#include <linux/io.h>
#include <linux/module.h>
@@ -82,8 +83,72 @@ struct simplefb_format {
struct fb_bitfield transp;
};
+static struct simplefb_format *simplefb_parse_format(struct device *dev,
+ const char *str)
+{
+ struct simplefb_format *format;
+ unsigned int offset = 0;
+ unsigned int i = 0;
+
+ format = devm_kzalloc(dev, sizeof(*format), GFP_KERNEL);
+ if (!format)
+ return ERR_PTR(-ENOMEM);
+
+ while (str[i] != 0) {
+ struct fb_bitfield *field = NULL;
+ int length = 0;
+
+ switch (str[i++]) {
+ case 'r':
+ case 'R':
+ field = &format->red;
+ break;
+ case 'g':
+ case 'G':
+ field = &format->green;
+ break;
+ case 'b':
+ case 'B':
+ field = &format->blue;
+ break;
+ case 'a':
+ case 'A':
+ field = &format->transp;
+ break;
+ case 'x':
+ case 'X':
+ break;
+ default:
+ goto error;
+ }
+
+ if (!isdigit(str[i]))
+ goto error;
+
+ while (isdigit(str[i])) {
+ length = length * 10 + (str[i++] - '0');
+ }
+
+ if (field) {
+ field->offset = offset;
+ field->length = length;
+ }
+
+ offset += length;
+ }
+
+ format->bits_per_pixel = (offset + 7) & ~0x7;
+ format->name = str;
+ return format;
+
+error:
+ dev_err(dev, "Invalid format string\n");
+ return ERR_PTR(-EINVAL);
+}
+
+/* if you use exotic modes that simplefb_parse_format cannot decode, you can
+ specify them here. */
static struct simplefb_format simplefb_formats[] = {
- { "r5g6b5", 16, {11, 5}, {5, 6}, {0, 5}, {0, 0} },
};
struct simplefb_params {
@@ -131,7 +196,10 @@ static int simplefb_parse_dt(struct platform_device *pdev,
params->format = &simplefb_formats[i];
break;
}
- if (!params->format) {
+ if (!params->format)
+ params->format = simplefb_parse_format(&pdev->dev, format);
+
+ if (IS_ERR(params->format)) {
dev_err(&pdev->dev, "Invalid format value\n");
return -EINVAL;
}
--
1.8.3
^ permalink raw reply related
* Re: [PATCH] video: mxsfb: Let device core handle pinctrl
From: Shawn Guo @ 2013-05-27 7:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1369619294-10362-1-git-send-email-festevam@gmail.com>
On Sun, May 26, 2013 at 10:48:14PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Since commit ab78029 (drivers/pinctrl: grab default handles from device core)
> we can rely on device core for handling pinctrl, so remove
> devm_pinctrl_get_select_default() from the driver.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* Re: [RFC] Add co-maintainer for fbdev
From: Tomi Valkeinen @ 2013-05-27 7:49 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Florian Tobias Schandinat, Arnd Bergmann, Olof Johansson,
linux-fbdev, Linus Torvalds, linux-kernel@vger.kernel.org,
Andrew Morton
In-Reply-To: <51A29DB9.7030505@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
Hi Jean-Christophe,
>>> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
>>> <plagnioj@jcrosoft.com> wrote:
>>>> Hi Florian,
>>>>
>>>> As you seems very busy I'd like to propose the help you to handle the
>>>> fbdev subsystem to easier the rich of the fbdev patch to Linus
>>>>
>>>> As I'm working on fbdev on at91 and others and already Co-Maintain the
>>>> at91 mach on ARM
>>>>
>>>> And if you are not willing to continue I could take over
I've been collecting fbdev patches for the latest merge windows, so that
Linus doesn't get tons of small separate pull requests. But I haven't
been very proactive with that, and I don't think I have time to really
maintain fbdev.
So I'd also welcome somebody stepping up and taking taking on the
maintainership of fbdev.
Tomi
Ps. I already have a few patches for 3.10 and for 3.11. I'll send them
to you.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [RFC] Add co-maintainer for fbdev
From: Jingoo Han @ 2013-05-27 8:19 UTC (permalink / raw)
To: 'Tomi Valkeinen',
'Jean-Christophe PLAGNIOL-VILLARD'
Cc: 'Florian Tobias Schandinat', 'Arnd Bergmann',
'Olof Johansson', linux-fbdev, 'Linus Torvalds',
linux-kernel, 'Andrew Morton'
In-Reply-To: <51A31013.9010701@ti.com>
On Monday, May 27, 2013 4:50 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> Hi Jean-Christophe,
>
> >>> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
> >>> <plagnioj@jcrosoft.com> wrote:
> >>>> Hi Florian,
> >>>>
> >>>> As you seems very busy I'd like to propose the help you to handle the
> >>>> fbdev subsystem to easier the rich of the fbdev patch to Linus
> >>>>
> >>>> As I'm working on fbdev on at91 and others and already Co-Maintain the
> >>>> at91 mach on ARM
> >>>>
> >>>> And if you are not willing to continue I could take over
>
> I've been collecting fbdev patches for the latest merge windows, so that
> Linus doesn't get tons of small separate pull requests. But I haven't
> been very proactive with that, and I don't think I have time to really
> maintain fbdev.
Hi Tomi,
I really thank you for your previous efforts.
Actually, I thought that you're a good fit for fbdev.
>
> So I'd also welcome somebody stepping up and taking taking on the
> maintainership of fbdev.
Hi Jean-Christophe PLAGNIOL-VILLARD,
I agree with Tomi's opinion.
If you take the maintainership of fbdev, it will be very helpful.
Best regards,
Jingoo Han
>
> Tomi
>
> Ps. I already have a few patches for 3.10 and for 3.11. I'll send them
> to you.
>
^ permalink raw reply
* [PATCH] console/dummy: Move screen size selection from CPP to Kconfig
From: Geert Uytterhoeven @ 2013-05-27 8:36 UTC (permalink / raw)
To: linux-arm-kernel
PA-RISC already handled the dummy console screen size selection in Kconfig,
so generalize this to other platforms.
ARM keeps on using screen_info, which is filled in by platform-specific
code, or from ATAGS.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/video/console/Kconfig | 16 ++++++++++------
drivers/video/console/dummycon.c | 5 +----
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 8af6ad3..7bfe7e1 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -76,18 +76,22 @@ config DUMMY_CONSOLE
config DUMMY_CONSOLE_COLUMNS
int "Initial number of console screen columns"
- depends on PARISC && DUMMY_CONSOLE
- default "160"
+ depends on DUMMY_CONSOLE && !ARM
+ default 160 if PARISC
+ default 80
help
- The default value is 160, which should fit a 1280x1024 monitor.
+ On PA-RISC, the default value is 160, which should fit a 1280x1024
+ monitor.
Select 80 if you use a 640x480 resolution by default.
config DUMMY_CONSOLE_ROWS
int "Initial number of console screen rows"
- depends on PARISC && DUMMY_CONSOLE
- default "64"
+ depends on DUMMY_CONSOLE && !ARM
+ default 64 if PARISC
+ default 25
help
- The default value is 64, which should fit a 1280x1024 monitor.
+ On PA-RISC, the default value is 64, which should fit a 1280x1024
+ monitor.
Select 25 if you use a 640x480 resolution by default.
config FRAMEBUFFER_CONSOLE
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index b63860f..6b1a5d1 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -20,13 +20,10 @@
#if defined(__arm__)
#define DUMMY_COLUMNS screen_info.orig_video_cols
#define DUMMY_ROWS screen_info.orig_video_lines
-#elif defined(__hppa__)
+#else
/* set by Kconfig. Use 80x25 for 640x480 and 160x64 for 1280x1024 */
#define DUMMY_COLUMNS CONFIG_DUMMY_CONSOLE_COLUMNS
#define DUMMY_ROWS CONFIG_DUMMY_CONSOLE_ROWS
-#else
-#define DUMMY_COLUMNS 80
-#define DUMMY_ROWS 25
#endif
static const char *dummycon_startup(void)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v6] video: imxfb: Add DT support
From: Sascha Hauer @ 2013-05-27 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1369564538-21835-1-git-send-email-mpa@pengutronix.de>
On Sun, May 26, 2013 at 12:35:38PM +0200, Markus Pargmann wrote:
> Add devicetree support for imx framebuffer driver. It uses the generic
> display bindings and helper functions.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* RE: Introduce a new helper framework for buffer synchronization
From: Inki Dae @ 2013-05-27 10:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51909DB4.2060208@canonical.com>
Hi all,
I have been removed previous branch and added new one with more cleanup.
This time, the fence helper doesn't include user side interfaces and cache
operation relevant codes anymore because not only we are not sure that
coupling those two things, synchronizing caches and buffer access between
CPU and CPU, CPU and DMA, and DMA and DMA with fences, in kernel side is a
good idea yet but also existing codes for user side have problems with badly
behaved or crashing userspace. So this could be more discussed later.
The below is a new branch,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/?h=dma-f
ence-helper
And fence helper codes,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dma-fence-helper&idcbc0fe7e285ce866e5816e5e21443dcce01005
And example codes for device driver,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
h=dma-fence-helper&idÒce7af23835789602a99d0ccef1f53cdd5caaae
I think the time is not yet ripe for RFC posting: maybe existing dma fence
and reservation need more review and addition work. So I'd glad for somebody
giving other opinions and advices in advance before RFC posting.
Thanks,
Inki Dae
^ permalink raw reply
* [PATCH] video: display_timing: make parameter const
From: Lucas Stach @ 2013-05-27 12:33 UTC (permalink / raw)
To: dri-devel; +Cc: Dave Airlie, linux-fbdev, kernel, Florian Tobias Schandinat
From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
As the device_node pointer is not changed in of_get_display_timing and
parse_timing_property it can be a const pointer.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/video/of_display_timing.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index 56009bc..85c1a41 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -23,7 +23,7 @@
* Every display_timing can be specified with either just the typical value or
* a range consisting of min/typ/max. This function helps handling this
**/
-static int parse_timing_property(struct device_node *np, const char *name,
+static int parse_timing_property(const struct device_node *np, const char *name,
struct timing_entry *result)
{
struct property *prop;
@@ -56,7 +56,8 @@ static int parse_timing_property(struct device_node *np, const char *name,
* of_get_display_timing - parse display_timing entry from device_node
* @np: device_node with the properties
**/
-static struct display_timing *of_get_display_timing(struct device_node *np)
+static struct display_timing *of_get_display_timing(const struct device_node
+ *np)
{
struct display_timing *dt;
u32 val = 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/3] video: display_timing: add doubleclk flag
From: Lucas Stach @ 2013-05-27 12:33 UTC (permalink / raw)
To: dri-devel; +Cc: Dave Airlie, linux-fbdev, kernel, Florian Tobias Schandinat
From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
include/video/display_timing.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/video/display_timing.h b/include/video/display_timing.h
index 5d0259b..28d9d0d 100644
--- a/include/video/display_timing.h
+++ b/include/video/display_timing.h
@@ -27,6 +27,7 @@ enum display_flags {
DISPLAY_FLAGS_PIXDATA_NEGEDGE = BIT(7),
DISPLAY_FLAGS_INTERLACED = BIT(8),
DISPLAY_FLAGS_DOUBLESCAN = BIT(9),
+ DISPLAY_FLAGS_DOUBLECLK = BIT(10),
};
/*
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] video: of: display_timing: add doubleclk flag
From: Lucas Stach @ 2013-05-27 12:33 UTC (permalink / raw)
To: dri-devel; +Cc: Dave Airlie, linux-fbdev, kernel, Florian Tobias Schandinat
In-Reply-To: <1369658015-11743-1-git-send-email-l.stach@pengutronix.de>
From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Documentation/devicetree/bindings/video/display-timing.txt | 1 +
drivers/video/of_display_timing.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt
index 1500385..e1d4a0b 100644
--- a/Documentation/devicetree/bindings/video/display-timing.txt
+++ b/Documentation/devicetree/bindings/video/display-timing.txt
@@ -34,6 +34,7 @@ optional properties:
- ignored = ignored
- interlaced (bool): boolean to enable interlaced mode
- doublescan (bool): boolean to enable doublescan mode
+ - doubleclk (bool): boolean to enable doubleclock mode
All the optional properties that are not bool follow the following logic:
<1>: high active
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index 85c1a41..2894e03 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -98,6 +98,8 @@ static struct display_timing *of_get_display_timing(const struct device_node
dt->flags |= DISPLAY_FLAGS_INTERLACED;
if (of_property_read_bool(np, "doublescan"))
dt->flags |= DISPLAY_FLAGS_DOUBLESCAN;
+ if (of_property_read_bool(np, "doubleclk"))
+ dt->flags |= DISPLAY_FLAGS_DOUBLECLK;
if (ret) {
pr_err("%s: error reading timing properties\n",
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/3] drm_modes: videomode: add doubleclk flag
From: Lucas Stach @ 2013-05-27 12:33 UTC (permalink / raw)
To: dri-devel; +Cc: Dave Airlie, linux-fbdev, kernel, Florian Tobias Schandinat
In-Reply-To: <1369658015-11743-1-git-send-email-l.stach@pengutronix.de>
From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/gpu/drm/drm_modes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index faa79df..875031d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -535,6 +535,8 @@ int drm_display_mode_from_videomode(const struct videomode *vm,
dmode->flags |= DRM_MODE_FLAG_INTERLACE;
if (vm->flags & DISPLAY_FLAGS_DOUBLESCAN)
dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+ if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
+ dmode->flags |= DRM_MODE_FLAG_DBLCLK;
drm_mode_set_name(dmode);
return 0;
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC] Add co-maintainer for fbdev
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-27 12:42 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Florian Tobias Schandinat, Arnd Bergmann, Olof Johansson,
linux-fbdev, Linus Torvalds, linux-kernel@vger.kernel.org,
Andrew Morton
In-Reply-To: <51A31013.9010701@ti.com>
On 10:49 Mon 27 May , Tomi Valkeinen wrote:
> Hi Jean-Christophe,
>
> >>> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
> >>> <plagnioj@jcrosoft.com> wrote:
> >>>> Hi Florian,
> >>>>
> >>>> As you seems very busy I'd like to propose the help you to handle the
> >>>> fbdev subsystem to easier the rich of the fbdev patch to Linus
> >>>>
> >>>> As I'm working on fbdev on at91 and others and already Co-Maintain the
> >>>> at91 mach on ARM
> >>>>
> >>>> And if you are not willing to continue I could take over
>
> I've been collecting fbdev patches for the latest merge windows, so that
> Linus doesn't get tons of small separate pull requests. But I haven't
> been very proactive with that, and I don't think I have time to really
> maintain fbdev.
>
> So I'd also welcome somebody stepping up and taking taking on the
> maintainership of fbdev.
>
> Tomi
>
> Ps. I already have a few patches for 3.10 and for 3.11. I'll send them
> to you.
Just send a pull request
for the 3.10 ASAP the 3.11 later I've ask a tree on kernel.org I'll then
request an inclusion on linux-next
Best Regards,
J.
>
>
^ permalink raw reply
* Re: [RFC] Add co-maintainer for fbdev
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-27 14:38 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: Arnd Bergmann, Olof Johansson, linux-fbdev, Linus Torvalds,
linux-kernel@vger.kernel.org, Tomi Valkeinen, Andrew Morton
In-Reply-To: <51A29DB9.7030505@gmx.de>
On 23:41 Sun 26 May , Florian Tobias Schandinat wrote:
> Hi Jean-Christophe,
>
> On 05/24/2013 06:56 PM, Arnd Bergmann wrote:
> > On Friday 24 May 2013, Olof Johansson wrote:
> >> [+akpm]
> >
> > [+florian]
>
> Thanks for CC'ing me. Lately I got dropped frequently from the
> mailinglist (after 1 or 2 days). Guess I should try subscribing via my
> own mail server.
>
> >> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD
> >> <plagnioj@jcrosoft.com> wrote:
> >>> Hi Florian,
> >>>
> >>> As you seems very busy I'd like to propose the help you to handle the
> >>> fbdev subsystem to easier the rich of the fbdev patch to Linus
> >>>
> >>> As I'm working on fbdev on at91 and others and already Co-Maintain the
> >>> at91 mach on ARM
> >>>
> >>> And if you are not willing to continue I could take over
>
> Yeah, it would be great if you could help, at the moment I get barely
> any sleep, let alone that I could keep up with the majority of mail I
> get. I'll let you decide whether you want to be sole maintainer or not.
I'd like to have feed back from others on this
> I still have interest in the subsystem, but it looks like VIA won't
> provide any information for their new VX11 chipset IGP for any open
> source driver and I'm still looking for a small, quiet mobile device as
> a replacement for my precious netbook that broke down last autumn to
> allow me working when I'm not at home.
I personnaly use a MacBook Air 11" with a powerpack to extend it to 15h of
battery
>
> >> Andrew has been fallback fbdev maintainer for a while, we have the
> >> option of formalizing that as well. Adding him on cc so he sees this.
>
> At this point I'd like to thank all people who have helped out so far,
> especially Tomi and Andrew.
>
>
> Best regards,
>
> Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH 1/3] video: display_timing: add doubleclk flag
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-27 14:43 UTC (permalink / raw)
To: Lucas Stach
Cc: Dave Airlie, linux-fbdev, kernel, dri-devel,
Florian Tobias Schandinat
In-Reply-To: <1369658015-11743-1-git-send-email-l.stach@pengutronix.de>
On 14:33 Mon 27 May , Lucas Stach wrote:
> From: Steffen Trumtrar <s.trumtrar@pengutronix.de>
>
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
If you want to take it via dri I'm fine otherwise via fbdev
Best Regards,
J.
> ---
> include/video/display_timing.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/video/display_timing.h b/include/video/display_timing.h
> index 5d0259b..28d9d0d 100644
> --- a/include/video/display_timing.h
> +++ b/include/video/display_timing.h
> @@ -27,6 +27,7 @@ enum display_flags {
> DISPLAY_FLAGS_PIXDATA_NEGEDGE = BIT(7),
> DISPLAY_FLAGS_INTERLACED = BIT(8),
> DISPLAY_FLAGS_DOUBLESCAN = BIT(9),
> + DISPLAY_FLAGS_DOUBLECLK = BIT(10),
> };
>
> /*
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] video: mxsfb: Let device core handle pinctrl
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-27 14:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1369619294-10362-1-git-send-email-festevam@gmail.com>
On 22:48 Sun 26 May , Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Since commit ab78029 (drivers/pinctrl: grab default handles from device core)
> we can rely on device core for handling pinctrl, so remove
> devm_pinctrl_get_select_default() from the driver.
Linus we should do a pass on the kernel to clean this
Best Regards,
J.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> drivers/video/mxsfb.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
> index 21223d4..9d6a286 100644
> --- a/drivers/video/mxsfb.c
> +++ b/drivers/video/mxsfb.c
> @@ -46,7 +46,6 @@
> #include <linux/clk.h>
> #include <linux/dma-mapping.h>
> #include <linux/io.h>
> -#include <linux/pinctrl/consumer.h>
> #include <linux/fb.h>
> #include <linux/regulator/consumer.h>
> #include <video/of_display_timing.h>
> @@ -877,7 +876,6 @@ static int mxsfb_probe(struct platform_device *pdev)
> struct mxsfb_info *host;
> struct fb_info *fb_info;
> struct fb_modelist *modelist;
> - struct pinctrl *pinctrl;
> int ret;
>
> if (of_id)
> @@ -909,12 +907,6 @@ static int mxsfb_probe(struct platform_device *pdev)
>
> host->devdata = &mxsfb_devdata[pdev->id_entry->driver_data];
>
> - pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> - if (IS_ERR(pinctrl)) {
> - ret = PTR_ERR(pinctrl);
> - goto fb_release;
> - }
> -
> host->clk = devm_clk_get(&host->pdev->dev, NULL);
> if (IS_ERR(host->clk)) {
> ret = PTR_ERR(host->clk);
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Introduce a new helper framework for buffer synchronization
From: Maarten Lankhorst @ 2013-05-27 15:23 UTC (permalink / raw)
To: Inki Dae
Cc: 'Daniel Vetter', 'Rob Clark',
'linux-fbdev', 'YoungJun Cho',
'Kyungmin Park', 'myungjoo.ham',
'DRI mailing list', linux-arm-kernel, linux-media
In-Reply-To: <014501ce5ac6$511a8500$f34f8f00$%dae@samsung.com>
Hey,
Op 27-05-13 12:38, Inki Dae schreef:
> Hi all,
>
> I have been removed previous branch and added new one with more cleanup.
> This time, the fence helper doesn't include user side interfaces and cache
> operation relevant codes anymore because not only we are not sure that
> coupling those two things, synchronizing caches and buffer access between
> CPU and CPU, CPU and DMA, and DMA and DMA with fences, in kernel side is a
> good idea yet but also existing codes for user side have problems with badly
> behaved or crashing userspace. So this could be more discussed later.
>
> The below is a new branch,
>
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/?h=dma-f
> ence-helper
>
> And fence helper codes,
>
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&idcbc0fe7e285ce866e5816e5e21443dcce01005
>
> And example codes for device driver,
>
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&idÒce7af23835789602a99d0ccef1f53cdd5caaae
>
> I think the time is not yet ripe for RFC posting: maybe existing dma fence
> and reservation need more review and addition work. So I'd glad for somebody
> giving other opinions and advices in advance before RFC posting.
>
NAK.
For examples for how to handle locking properly, see Documentation/ww-mutex-design.txt in my recent tree.
I could list what I believe is wrong with your implementation, but real problem is that the approach you're taking is wrong.
~Maarten
^ permalink raw reply
* Re: Introduce a new helper framework for buffer synchronization
From: Rob Clark @ 2013-05-27 15:47 UTC (permalink / raw)
To: Inki Dae
Cc: Maarten Lankhorst, Daniel Vetter, linux-fbdev, YoungJun Cho,
Kyungmin Park, myungjoo.ham, DRI mailing list, linux-arm-kernel,
linux-media
In-Reply-To: <014501ce5ac6$511a8500$f34f8f00$%dae@samsung.com>
On Mon, May 27, 2013 at 6:38 AM, Inki Dae <inki.dae@samsung.com> wrote:
> Hi all,
>
> I have been removed previous branch and added new one with more cleanup.
> This time, the fence helper doesn't include user side interfaces and cache
> operation relevant codes anymore because not only we are not sure that
> coupling those two things, synchronizing caches and buffer access between
> CPU and CPU, CPU and DMA, and DMA and DMA with fences, in kernel side is a
> good idea yet but also existing codes for user side have problems with badly
> behaved or crashing userspace. So this could be more discussed later.
>
> The below is a new branch,
>
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/?h=dma-f
> ence-helper
>
> And fence helper codes,
>
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&idcbc0fe7e285ce866e5816e5e21443dcce01005
>
> And example codes for device driver,
>
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?
> h=dma-fence-helper&idÒce7af23835789602a99d0ccef1f53cdd5caaae
>
> I think the time is not yet ripe for RFC posting: maybe existing dma fence
> and reservation need more review and addition work. So I'd glad for somebody
> giving other opinions and advices in advance before RFC posting.
thoughts from a *really* quick, pre-coffee, first look:
* any sort of helper to simplify single-buffer sort of use-cases (v4l)
probably wouldn't want to bake in assumption that seqno_fence is used.
* I guess g2d is probably not actually a simple use case, since I
expect you can submit blits involving multiple buffers :-P
* otherwise, you probably don't want to depend on dmabuf, which is why
reservation/fence is split out the way it is.. you want to be able to
use a single reservation/fence mechanism within your driver without
having to care about which buffers are exported to dmabuf's and which
are not. Creating a dmabuf for every GEM bo is too heavyweight.
I'm not entirely sure if reservation/fence could/should be made any
simpler for multi-buffer users. Probably the best thing to do is just
get reservation/fence rolled out in a few drivers and see if some
common patterns emerge.
BR,
-R
>
> Thanks,
> Inki Dae
>
^ 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