* 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
* Re: How to make framebuffer look like a real monitor?
From: Ivan Drobyshevskyi @ 2014-03-22 8:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <CADAXeK1HznKm6AuWa1431i0u+GSKkXq0u3FWMFvbHU95FJQbzg@mail.gmail.com>
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).
On Fri, Mar 21, 2014 at 10:27 PM, Tormod Volden <lists.tormod@gmail.com> wrote:
> 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
>
> HTH,
> Tormod
^ permalink raw reply
* Re: [PATCH] drivers/video: fix mb862xx_i2c depends issue build failure
From: Randy Dunlap @ 2014-03-21 23:11 UTC (permalink / raw)
To: Paul Gortmaker, Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel,
Jim Davis, Fengguang Wu
In-Reply-To: <532C4476.2030706@windriver.com>
On 03/21/2014 06:53 AM, Paul Gortmaker wrote:
> On 14-03-21 09:32 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 20/03/14 17:16, Paul Gortmaker wrote:
>>> Any randconfig that sets I2C=m and FB_MB862XX_I2C=y will
>>> encounter a final link failure that looks like this:
>>
>> It compiles fine with I2C=m, FB_MB862XX=m and FB_MB862XX_I2C=y.
>>
>>> drivers/built-in.o: In function `mb862xx_i2c_init':
>>> drivers/video/mb862xx/mb862xx-i2c.c:165: undefined reference to `i2c_add_adapter'
>>> drivers/built-in.o: In function `mb862xx_i2c_exit':
>>> drivers/video/mb862xx/mb862xx-i2c.c:176: undefined reference to `i2c_del_adapter'
>>>
>>> Since FB_MB862XX_I2C is a bool and not tristate, simply
>>> don't offer it at all if core I2C support is not built in.
>>
>> FB_MB862XX_I2C is not a driver, it just adds the i2c support to
>> FB_MB862XX. The relevant thing is whether FB_MB862XX is m or y, so
>> compiling with:
>>
>> I2C=m, FB_MB862XX=y and FB_MB862XX_I2C=y
>>
>> will fail.
>
> How would you suggest we fix it then? Perhaps we could simplify the
> Kconfig space and just get rid of FB_MB862XX_I2C entirely? Is there
> ever a reason why someone would want it turned off when I2C is present?
>
> Paul.
> --
>
>>
>>> Reported-by: Jim Davis <jim.epost@gmail.com>
>>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
>>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index dade5b7699bc..aefd1b9a3cbd 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -2338,7 +2338,7 @@ endchoice
>>>
>>> config FB_MB862XX_I2C
>>> bool "Support I2C bus on MB862XX GDC"
>>> - depends on FB_MB862XX && I2C
>>> + depends on FB_MB862XX && I2C=y
>>> default y
>>> help
>>> Selecting this option adds Coral-P(A)/Lime GDC I2C bus adapter
>>
>> This fix is not correct, as it prevents the following, valid, config:
>>
>> I2C=m, FB_MB862XX=m and FB_MB862XX_I2C=y
If I am following this correctly, this kconfig situation is often handled
by something like
depends on I2C=y || I2Cû_MB862XX
--
~Randy
^ permalink raw reply
* Re: How to make framebuffer look like a real monitor?
From: Tormod Volden @ 2014-03-21 20:27 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
HTH,
Tormod
^ permalink raw reply
* Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
From: Grant Likely @ 2014-03-21 15:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Philipp Zabel,
Laurent Pinchart, Russell King - ARM Linux, Sascha Hauer,
Sebastian Hesselbarth, Rob Clark, Inki Dae, Andrzej Hajda,
Tomasz Figa, Thierry Reding
In-Reply-To: <5326FECF.9070104-l0cyMroinI0@public.gmane.org>
On Mon, 17 Mar 2014 15:55:27 +0200, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi Grant,
>
> Ping.
>
> Are you fine with me proceeding with the current V4L2 port/endpoint
> bindings?
Sorry, this thread didn't make it past my email filters. Yes, go ahead.
g.
^ permalink raw reply
* How to make framebuffer look like a real monitor?
From: Ivan Drobyshevskyi @ 2014-03-21 14:30 UTC (permalink / raw)
To: linux-fbdev
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?
Thanks,
Ivan.
^ permalink raw reply
* Re: [PATCH] drivers/video: fix mb862xx_i2c depends issue build failure
From: Tomi Valkeinen @ 2014-03-21 14:07 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel,
Jim Davis, Fengguang Wu
In-Reply-To: <532C4476.2030706@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]
On 21/03/14 15:53, Paul Gortmaker wrote:
> On 14-03-21 09:32 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 20/03/14 17:16, Paul Gortmaker wrote:
>>> Any randconfig that sets I2C=m and FB_MB862XX_I2C=y will
>>> encounter a final link failure that looks like this:
>>
>> It compiles fine with I2C=m, FB_MB862XX=m and FB_MB862XX_I2C=y.
>>
>>> drivers/built-in.o: In function `mb862xx_i2c_init':
>>> drivers/video/mb862xx/mb862xx-i2c.c:165: undefined reference to `i2c_add_adapter'
>>> drivers/built-in.o: In function `mb862xx_i2c_exit':
>>> drivers/video/mb862xx/mb862xx-i2c.c:176: undefined reference to `i2c_del_adapter'
>>>
>>> Since FB_MB862XX_I2C is a bool and not tristate, simply
>>> don't offer it at all if core I2C support is not built in.
>>
>> FB_MB862XX_I2C is not a driver, it just adds the i2c support to
>> FB_MB862XX. The relevant thing is whether FB_MB862XX is m or y, so
>> compiling with:
>>
>> I2C=m, FB_MB862XX=y and FB_MB862XX_I2C=y
>>
>> will fail.
>
> How would you suggest we fix it then? Perhaps we could simplify the
> Kconfig space and just get rid of FB_MB862XX_I2C entirely? Is there
> ever a reason why someone would want it turned off when I2C is present?
I'm not familiar with the driver and devices that use it, so I can't
really say. But you could probably have a board with the FB_MB862XX,
without i2c displays, while still you'd have I2C for other uses. So
there you could minimally reduce the kernel size by leaving out the
FB_MB862XX_I2C.
I'm fine with that solution, though. But how would it work in practice?
Did you mean that FB_MB862XX would depend on I2C? That's not a good
option, but how would you otherwise make the i2c dependency correct?
Actually, I'm fine with the original patch also, as I believe the case
where I2C=m is somewhat theoretical (correct me if I'm wrong). But the
patch description was totally wrong, and if that solution is preferred,
it should also clearly state that the patch prevents the I2C support
when I2C is built as a module. But I think your proposal in this mail is
better.
Maybe there are even better ways to handle it in the Kconfig, as such
"add feature X to the driver" sounds quite common to me.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/video: fix mb862xx_i2c depends issue build failure
From: Paul Gortmaker @ 2014-03-21 13:53 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel,
Jim Davis, Fengguang Wu
In-Reply-To: <532C3F64.2020601@ti.com>
On 14-03-21 09:32 AM, Tomi Valkeinen wrote:
> Hi,
>
> On 20/03/14 17:16, Paul Gortmaker wrote:
>> Any randconfig that sets I2C=m and FB_MB862XX_I2C=y will
>> encounter a final link failure that looks like this:
>
> It compiles fine with I2C=m, FB_MB862XX=m and FB_MB862XX_I2C=y.
>
>> drivers/built-in.o: In function `mb862xx_i2c_init':
>> drivers/video/mb862xx/mb862xx-i2c.c:165: undefined reference to `i2c_add_adapter'
>> drivers/built-in.o: In function `mb862xx_i2c_exit':
>> drivers/video/mb862xx/mb862xx-i2c.c:176: undefined reference to `i2c_del_adapter'
>>
>> Since FB_MB862XX_I2C is a bool and not tristate, simply
>> don't offer it at all if core I2C support is not built in.
>
> FB_MB862XX_I2C is not a driver, it just adds the i2c support to
> FB_MB862XX. The relevant thing is whether FB_MB862XX is m or y, so
> compiling with:
>
> I2C=m, FB_MB862XX=y and FB_MB862XX_I2C=y
>
> will fail.
How would you suggest we fix it then? Perhaps we could simplify the
Kconfig space and just get rid of FB_MB862XX_I2C entirely? Is there
ever a reason why someone would want it turned off when I2C is present?
Paul.
--
>
>> Reported-by: Jim Davis <jim.epost@gmail.com>
>> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index dade5b7699bc..aefd1b9a3cbd 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -2338,7 +2338,7 @@ endchoice
>>
>> config FB_MB862XX_I2C
>> bool "Support I2C bus on MB862XX GDC"
>> - depends on FB_MB862XX && I2C
>> + depends on FB_MB862XX && I2C=y
>> default y
>> help
>> Selecting this option adds Coral-P(A)/Lime GDC I2C bus adapter
>
> This fix is not correct, as it prevents the following, valid, config:
>
> I2C=m, FB_MB862XX=m and FB_MB862XX_I2C=y
>
> Tomi
>
>
^ permalink raw reply
* Re: [PATCH] fbdev: Make the switch from generic to native driver less alarming
From: Tomi Valkeinen @ 2014-03-21 13:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1345223444-15852-1-git-send-email-ajax@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 977 bytes --]
On 12/02/14 23:02, Adam Jackson wrote:
> Calling this "conflicting" just makes people think there's a problem
> when there's not.
>
> Signed-off-by: Adam Jackson <ajax@redhat.com>
> ---
> drivers/video/fbmem.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 7309ac7..b6d5008 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1596,8 +1596,7 @@ static int do_remove_conflicting_framebuffers(struct apertures_struct *a,
> (primary && gen_aper && gen_aper->count &&
> gen_aper->ranges[0].base == VGA_FB_PHYS)) {
>
> - printk(KERN_INFO "fb: conflicting fb hw usage "
> - "%s vs %s - removing generic driver\n",
> + printk(KERN_INFO "fb: switching to %s from %s\n",
> name, registered_fb[i]->fix.id);
> ret = do_unregister_framebuffer(registered_fb[i]);
> if (ret)
>
Thanks, queued for 3.15.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/video: fix mb862xx_i2c depends issue build failure
From: Tomi Valkeinen @ 2014-03-21 13:32 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Jean-Christophe Plagniol-Villard, linux-fbdev, linux-kernel,
Jim Davis, Fengguang Wu
In-Reply-To: <1395328560-48497-1-git-send-email-paul.gortmaker@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]
Hi,
On 20/03/14 17:16, Paul Gortmaker wrote:
> Any randconfig that sets I2C=m and FB_MB862XX_I2C=y will
> encounter a final link failure that looks like this:
It compiles fine with I2C=m, FB_MB862XX=m and FB_MB862XX_I2C=y.
> drivers/built-in.o: In function `mb862xx_i2c_init':
> drivers/video/mb862xx/mb862xx-i2c.c:165: undefined reference to `i2c_add_adapter'
> drivers/built-in.o: In function `mb862xx_i2c_exit':
> drivers/video/mb862xx/mb862xx-i2c.c:176: undefined reference to `i2c_del_adapter'
>
> Since FB_MB862XX_I2C is a bool and not tristate, simply
> don't offer it at all if core I2C support is not built in.
FB_MB862XX_I2C is not a driver, it just adds the i2c support to
FB_MB862XX. The relevant thing is whether FB_MB862XX is m or y, so
compiling with:
I2C=m, FB_MB862XX=y and FB_MB862XX_I2C=y
will fail.
> Reported-by: Jim Davis <jim.epost@gmail.com>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index dade5b7699bc..aefd1b9a3cbd 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2338,7 +2338,7 @@ endchoice
>
> config FB_MB862XX_I2C
> bool "Support I2C bus on MB862XX GDC"
> - depends on FB_MB862XX && I2C
> + depends on FB_MB862XX && I2C=y
> default y
> help
> Selecting this option adds Coral-P(A)/Lime GDC I2C bus adapter
This fix is not correct, as it prevents the following, valid, config:
I2C=m, FB_MB862XX=m and FB_MB862XX_I2C=y
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] video: clps711x: Add bindings documentation for CLPS711X framebuffer
From: Mark Rutland @ 2014-03-21 9:47 UTC (permalink / raw)
To: Alexander Shiyan
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Russell King,
Olof Johansson, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Pawel Moll, Ian Campbell, Kumar Gala,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
In-Reply-To: <1395332818-23193-1-git-send-email-shc_work-JGs/UdohzUI@public.gmane.org>
On Thu, Mar 20, 2014 at 04:26:58PM +0000, Alexander Shiyan wrote:
> Add OF document for Cirrus Logic CLPS711X framebuffer driver.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> ---
> .../bindings/video/cirrus,clps711x-fb.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt
>
> diff --git a/Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt b/Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt
> new file mode 100644
> index 0000000..9d59ad3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt
> @@ -0,0 +1,48 @@
> +* Currus Logic CLPS711X Framebuffer
> +
> +Required properties:
> +- compatible: Shall contain "cirrus,clps711x-fb".
> +- reg: Physical base address and length of the controller's registers +
> + location and size of the framebuffer memory.
> +- clocks: phandle + clock specifier pair of the FB reference clock.
> +
> +Required nodes:
> +- display: Phandle to a display node as described in display-timing.txt.
Is this a node or a property?
It looks like you need a node and a phandle to it, please describe these
separately.
Cheers,
Mark.
> + Additionally, the display node has to define properties:
> + - bits-per-pixel: Bits per pixel.
> + - ac-prescale: LCD AC bias frequency. This frequency is the required
> + AC bias frequency for a given manufacturer's LCD plate.
> + - cmap-invert: Invert the color levels (Optional).
> +
> +Optional properties:
> +- lcd-supply: Regulator for LCD supply voltage.
> +
> +Example:
> + fb: fb@800002c0 {
> + compatible = "cirrus,ep7312-fb", "cirrus,clps711x-fb";
> + reg = <0x800002c0 0xd44>, <0x60000000 0xc000>;
> + clocks = <&clks 2>;
> + lcd-supply = <®5v0>;
> + display = <&display>;
> + };
> +
> + display: display {
> + model = "320x240x4";
> + native-mode = <&timing0>;
> + bits-per-pixel = <4>;
> + ac-prescale = <17>;
> +
> + display-timings {
> + timing0: 320x240 {
> + hactive = <320>;
> + hback-porch = <0>;
> + hfront-porch = <0>;
> + hsync-len = <0>;
> + vactive = <240>;
> + vback-porch = <0>;
> + vfront-porch = <0>;
> + vsync-len = <0>;
> + clock-frequency = <6500000>;
> + };
> + };
> + };
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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 14/16] backlight: atmel-pwm-bl: remove obsolete driver
From: Jingoo Han @ 2014-03-21 0:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140319142231.GF20872@samfundet.no>
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>
Best regards,
Jingoo Han
>
> > ---
> > drivers/video/backlight/Kconfig | 11 --
> > drivers/video/backlight/Makefile | 1 -
> > drivers/video/backlight/atmel-pwm-bl.c | 223 ---------------------------------
> > include/linux/atmel-pwm-bl.h | 43 -------
> > 4 files changed, 278 deletions(-)
> > delete mode 100644 drivers/video/backlight/atmel-pwm-bl.c
> > delete mode 100644 include/linux/atmel-pwm-bl.h
^ 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