* Re: No more new fbdev drivers, please
From: Ondrej Zary @ 2015-09-25 11:00 UTC (permalink / raw)
To: dri-devel
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Aaro Koskinen,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, Tomi Valkeinen,
Laurent Pinchart, Daniel Vetter, Dave Airlie, Sudip Mukherjee
In-Reply-To: <20150925084923.GD5273@blackmetal.musicnaut.iki.fi>
On Friday 25 September 2015, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
> > fbdev is (more or less) maintained, but it's a deprecated framework. All
> > new Linux display drivers should be done on DRM.
> >
> > So let's not add any more new fbdev drivers.
> >
> > I will continue to maintain the current fbdev drivers, and I don't mind
> > adding some new features to those current drivers, as long as the amount
> > of code required to add the features stays sensible.
> >
> > I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> > and the question is what to do with those.
>
> I was still planning to work on xgifb as I need it on some systems for
> the console.
xgifb supports these devices:
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_27
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_42
Two of them are already supported by sisfb:
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40
So I think that support for the remaining two (and missing features, if any)
should be added to sisfb.
--
Ondrej Zary
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Kamil Lulko @ 2015-09-25 10:41 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-kernel, linux-fbdev, dri-devel
In-Reply-To: <5603EC15.9090605@ti.com>
Hi,
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
What about no-mmu platforms? DRM has a big fat MMU dependency in the
kconfig, is there a way to write DRM driver for such devices?
/Kamil
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Aaro Koskinen @ 2015-09-25 8:49 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Greg Kroah-Hartman, linux-fbdev, DRI Development, Sudip Mukherjee,
Teddy Wang, Thomas Petazzoni, Noralf Trønnes,
Laurent Pinchart, Dave Airlie, Daniel Vetter,
linux-kernel@vger.kernel.org
In-Reply-To: <5603EC15.9090605@ti.com>
Hi,
On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
>
> So let's not add any more new fbdev drivers.
>
> I will continue to maintain the current fbdev drivers, and I don't mind
> adding some new features to those current drivers, as long as the amount
> of code required to add the features stays sensible.
>
> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> and the question is what to do with those.
I was still planning to work on xgifb as I need it on some systems for
the console.
A.
^ permalink raw reply
* [PATCH v2 2/2] tridentfb: Add DDC support
From: Ondrej Zary @ 2015-09-24 22:14 UTC (permalink / raw)
To: Krzysztof Helt; +Cc: Tomi Valkeinen, linux-fbdev, Kernel development list
In-Reply-To: <1443132854-31786-1-git-send-email-linux@rainbow-software.org>
Add DDC support for Trident cards.
Tested on TGUI9440, TGUI9680, 3DImage 9750, Blade3D 9880 and Blade XP.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/Kconfig | 2 +
drivers/video/fbdev/tridentfb.c | 182 +++++++++++++++++++++++++++++++++++++--
2 files changed, 179 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8b1d371..5d67226 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1666,6 +1666,8 @@ config FB_TRIDENT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_DDC
+ select FB_MODE_HELPERS
---help---
This is the frame buffer device driver for Trident PCI/AGP chipsets.
Supported chipset families are TGUI 9440/96XX, 3DImage, Blade3D
diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
index 01b43e9..8a5bbc1 100644
--- a/drivers/video/fbdev/tridentfb.c
+++ b/drivers/video/fbdev/tridentfb.c
@@ -25,6 +25,9 @@
#include <video/vga.h>
#include <video/trident.h>
+#include <linux/i2c.h>
+#include <linux/i2c-algo-bit.h>
+
struct tridentfb_par {
void __iomem *io_virt; /* iospace virtual memory address */
u32 pseudo_pal[16];
@@ -40,6 +43,9 @@ struct tridentfb_par {
(struct tridentfb_par *par, const char*,
u32, u32, u32, u32, u32, u32);
unsigned char eng_oper; /* engine operation... */
+ bool ddc_registered;
+ struct i2c_adapter ddc_adapter;
+ struct i2c_algo_bit_data ddc_algo;
};
static struct fb_fix_screeninfo tridentfb_fix = {
@@ -53,7 +59,7 @@ static struct fb_fix_screeninfo tridentfb_fix = {
/* defaults which are normally overriden by user values */
/* video mode */
-static char *mode_option = "640x480-8@60";
+static char *mode_option;
static int bpp = 8;
static int noaccel;
@@ -174,6 +180,121 @@ static inline u32 readmmr(struct tridentfb_par *par, u16 r)
return fb_readl(par->io_virt + r);
}
+#define DDC_SDA_TGUI BIT(0)
+#define DDC_SCL_TGUI BIT(1)
+#define DDC_SCL_DRIVE_TGUI BIT(2)
+#define DDC_SDA_DRIVE_TGUI BIT(3)
+#define DDC_MASK_TGUI (DDC_SCL_DRIVE_TGUI | DDC_SDA_DRIVE_TGUI)
+
+static void tridentfb_ddc_setscl_tgui(void *data, int val)
+{
+ struct tridentfb_par *par = data;
+ u8 reg = vga_mm_rcrt(par->io_virt, I2C) & DDC_MASK_TGUI;
+
+ if (val)
+ reg &= ~DDC_SCL_DRIVE_TGUI; /* disable drive - don't drive hi */
+ else
+ reg |= DDC_SCL_DRIVE_TGUI; /* drive low */
+
+ vga_mm_wcrt(par->io_virt, I2C, reg);
+}
+
+static void tridentfb_ddc_setsda_tgui(void *data, int val)
+{
+ struct tridentfb_par *par = data;
+ u8 reg = vga_mm_rcrt(par->io_virt, I2C) & DDC_MASK_TGUI;
+
+ if (val)
+ reg &= ~DDC_SDA_DRIVE_TGUI; /* disable drive - don't drive hi */
+ else
+ reg |= DDC_SDA_DRIVE_TGUI; /* drive low */
+
+ vga_mm_wcrt(par->io_virt, I2C, reg);
+}
+
+static int tridentfb_ddc_getsda_tgui(void *data)
+{
+ struct tridentfb_par *par = data;
+
+ return !!(vga_mm_rcrt(par->io_virt, I2C) & DDC_SDA_TGUI);
+}
+
+#define DDC_SDA_IN BIT(0)
+#define DDC_SCL_OUT BIT(1)
+#define DDC_SDA_OUT BIT(3)
+#define DDC_SCL_IN BIT(6)
+#define DDC_MASK (DDC_SCL_OUT | DDC_SDA_OUT)
+
+static void tridentfb_ddc_setscl(void *data, int val)
+{
+ struct tridentfb_par *par = data;
+ unsigned char reg;
+
+ reg = vga_mm_rcrt(par->io_virt, I2C) & DDC_MASK;
+ if (val)
+ reg |= DDC_SCL_OUT;
+ else
+ reg &= ~DDC_SCL_OUT;
+ vga_mm_wcrt(par->io_virt, I2C, reg);
+}
+
+static void tridentfb_ddc_setsda(void *data, int val)
+{
+ struct tridentfb_par *par = data;
+ unsigned char reg;
+
+ reg = vga_mm_rcrt(par->io_virt, I2C) & DDC_MASK;
+ if (!val)
+ reg |= DDC_SDA_OUT;
+ else
+ reg &= ~DDC_SDA_OUT;
+ vga_mm_wcrt(par->io_virt, I2C, reg);
+}
+
+static int tridentfb_ddc_getscl(void *data)
+{
+ struct tridentfb_par *par = data;
+
+ return !!(vga_mm_rcrt(par->io_virt, I2C) & DDC_SCL_IN);
+}
+
+static int tridentfb_ddc_getsda(void *data)
+{
+ struct tridentfb_par *par = data;
+
+ return !!(vga_mm_rcrt(par->io_virt, I2C) & DDC_SDA_IN);
+}
+
+static int tridentfb_setup_ddc_bus(struct fb_info *info)
+{
+ struct tridentfb_par *par = info->par;
+
+ strlcpy(par->ddc_adapter.name, info->fix.id,
+ sizeof(par->ddc_adapter.name));
+ par->ddc_adapter.owner = THIS_MODULE;
+ par->ddc_adapter.class = I2C_CLASS_DDC;
+ par->ddc_adapter.algo_data = &par->ddc_algo;
+ par->ddc_adapter.dev.parent = info->device;
+ if (is_oldclock(par->chip_id)) { /* not sure if this check is OK */
+ par->ddc_algo.setsda = tridentfb_ddc_setsda_tgui;
+ par->ddc_algo.setscl = tridentfb_ddc_setscl_tgui;
+ par->ddc_algo.getsda = tridentfb_ddc_getsda_tgui;
+ /* no getscl */
+ } else {
+ par->ddc_algo.setsda = tridentfb_ddc_setsda;
+ par->ddc_algo.setscl = tridentfb_ddc_setscl;
+ par->ddc_algo.getsda = tridentfb_ddc_getsda;
+ par->ddc_algo.getscl = tridentfb_ddc_getscl;
+ }
+ par->ddc_algo.udelay = 10;
+ par->ddc_algo.timeout = 20;
+ par->ddc_algo.data = par;
+
+ i2c_set_adapdata(&par->ddc_adapter, par);
+
+ return i2c_bit_add_bus(&par->ddc_adapter);
+}
+
/*
* Blade specific acceleration.
*/
@@ -1346,6 +1467,7 @@ static int trident_pci_probe(struct pci_dev *dev,
struct tridentfb_par *default_par;
int chip3D;
int chip_id;
+ bool found = false;
err = pci_enable_device(dev);
if (err)
@@ -1499,6 +1621,7 @@ static int trident_pci_probe(struct pci_dev *dev,
info->pixmap.scan_align = 1;
info->pixmap.access_align = 32;
info->pixmap.flags = FB_PIXMAP_SYSTEM;
+ info->var.bits_per_pixel = 8;
if (default_par->image_blit) {
info->flags |= FBINFO_HWACCEL_IMAGEBLIT;
@@ -1511,11 +1634,56 @@ static int trident_pci_probe(struct pci_dev *dev,
info->pixmap.scan_align = 1;
}
- if (!fb_find_mode(&info->var, info,
- mode_option, NULL, 0, NULL, bpp)) {
- err = -EINVAL;
- goto out_unmap2;
+ if (tridentfb_setup_ddc_bus(info) = 0) {
+ u8 *edid = fb_ddc_read(&default_par->ddc_adapter);
+
+ default_par->ddc_registered = true;
+ if (edid) {
+ fb_edid_to_monspecs(edid, &info->monspecs);
+ kfree(edid);
+ if (!info->monspecs.modedb)
+ dev_err(info->device, "error getting mode database\n");
+ else {
+ const struct fb_videomode *m;
+
+ fb_videomode_to_modelist(info->monspecs.modedb,
+ info->monspecs.modedb_len,
+ &info->modelist);
+ m = fb_find_best_display(&info->monspecs,
+ &info->modelist);
+ if (m) {
+ fb_videomode_to_var(&info->var, m);
+ /* fill all other info->var's fields */
+ if (tridentfb_check_var(&info->var,
+ info) = 0)
+ found = true;
+ }
+ }
+ }
}
+
+ if (!mode_option && !found)
+ mode_option = "640x480-8@60";
+
+ /* Prepare startup mode */
+ if (mode_option) {
+ err = fb_find_mode(&info->var, info, mode_option,
+ info->monspecs.modedb,
+ info->monspecs.modedb_len,
+ NULL, info->var.bits_per_pixel);
+ if (!err || err = 4) {
+ err = -EINVAL;
+ dev_err(info->device, "mode %s not found\n",
+ mode_option);
+ fb_destroy_modedb(info->monspecs.modedb);
+ info->monspecs.modedb = NULL;
+ goto out_unmap2;
+ }
+ }
+
+ fb_destroy_modedb(info->monspecs.modedb);
+ info->monspecs.modedb = NULL;
+
err = fb_alloc_cmap(&info->cmap, 256, 0);
if (err < 0)
goto out_unmap2;
@@ -1536,6 +1704,8 @@ static int trident_pci_probe(struct pci_dev *dev,
return 0;
out_unmap2:
+ if (default_par->ddc_registered)
+ i2c_del_adapter(&default_par->ddc_adapter);
kfree(info->pixmap.addr);
if (info->screen_base)
iounmap(info->screen_base);
@@ -1555,6 +1725,8 @@ static void trident_pci_remove(struct pci_dev *dev)
struct tridentfb_par *par = info->par;
unregister_framebuffer(info);
+ if (par->ddc_registered)
+ i2c_del_adapter(&par->ddc_adapter);
iounmap(par->io_virt);
iounmap(info->screen_base);
release_mem_region(tridentfb_fix.smem_start, tridentfb_fix.smem_len);
--
Ondrej Zary
^ permalink raw reply related
* [PATCH v2 1/2] fb_ddc: Allow I2C adapters without SCL read capability
From: Ondrej Zary @ 2015-09-24 22:14 UTC (permalink / raw)
To: Krzysztof Helt; +Cc: Tomi Valkeinen, linux-fbdev, Kernel development list
i2c-algo-bit allows I2C adapters without SCL read capability to work
but fb_ddc_read fails to work on them.
Fix fb_ddc_read to work with I2C adapters not capable of reading SCL.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/core/fb_ddc.c | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_ddc.c b/drivers/video/fbdev/core/fb_ddc.c
index 94322cc..8bf5f2f 100644
--- a/drivers/video/fbdev/core/fb_ddc.c
+++ b/drivers/video/fbdev/core/fb_ddc.c
@@ -67,13 +67,17 @@ unsigned char *fb_ddc_read(struct i2c_adapter *adapter)
msleep(13);
algo_data->setscl(algo_data->data, 1);
- for (j = 0; j < 5; j++) {
- msleep(10);
- if (algo_data->getscl(algo_data->data))
- break;
+ if (algo_data->getscl) {
+ for (j = 0; j < 5; j++) {
+ msleep(10);
+ if (algo_data->getscl(algo_data->data))
+ break;
+ }
+ if (j = 5)
+ continue;
+ } else {
+ udelay(algo_data->udelay);
}
- if (j = 5)
- continue;
algo_data->setsda(algo_data->data, 0);
msleep(15);
@@ -89,10 +93,14 @@ unsigned char *fb_ddc_read(struct i2c_adapter *adapter)
msleep(15);
algo_data->setscl(algo_data->data, 1);
- for (j = 0; j < 10; j++) {
- msleep(10);
- if (algo_data->getscl(algo_data->data))
- break;
+ if (algo_data->getscl) {
+ for (j = 0; j < 10; j++) {
+ msleep(10);
+ if (algo_data->getscl(algo_data->data))
+ break;
+ }
+ } else {
+ udelay(algo_data->udelay);
}
algo_data->setsda(algo_data->data, 1);
--
Ondrej Zary
^ permalink raw reply related
* Re: No more new fbdev drivers, please
From: Daniel Vetter @ 2015-09-24 18:05 UTC (permalink / raw)
To: Ondrej Zary
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, dri-devel, Austin S Hemmelgarn,
Tomi Valkeinen, Laurent Pinchart, Daniel Vetter, Arnaud Patard,
Dave Airlie, Sudip Mukherjee
In-Reply-To: <201509241912.28739.linux@rainbow-software.org>
On Thu, Sep 24, 2015 at 07:12:27PM +0200, Ondrej Zary wrote:
> On Thursday 24 September 2015 17:59:12 Daniel Vetter wrote:
> > On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
> > > On 2015-09-24 08:46, Thomas Petazzoni wrote:
> > > >Hello,
> > > >
> > > >On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
> > > >>fbdev is (more or less) maintained, but it's a deprecated framework.
> > > >> All new Linux display drivers should be done on DRM.
> > > >>
> > > >>So let's not add any more new fbdev drivers.
> > > >>
> > > >>I will continue to maintain the current fbdev drivers, and I don't mind
> > > >>adding some new features to those current drivers, as long as the
> > > >> amount of code required to add the features stays sensible.
> > > >>
> > > >>I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> > > >>and the question is what to do with those.
> > > >>
> > > >>xgifb was added in 2010, and is still in staging.
> > > >>
> > > >>fbtft looks like maybe some kind of framework on top of fbdev, with
> > > >>fbtft specific subdrivers... I didn't look at it in detail, but my gut
> > > >>says "never".
> > > >
> > > >fbtft mainly drives some very simple I2C-based or SPI-based displays,
> > > >and DRM is I believe overkill for such displays. Last time I talked
> > > >with Laurent Pinchart about such drivers, I believe he said that such
> > > >simple drivers could probably continue to use the fbdev subsystem.
> > >
> > > I have to agree, using DRM _really_ doesn't make sense for these, the
> > > devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
> > > chips that are hooked up to equally simple TFT displays. There's no 3d
> > > acceleration at all from what I can tell, there's _very_ limited 2d
> > > acceleration, and most of the stuff that the DRM framework provides
> > > call-backs for would have to be done on the CPU anyway. On top of that,
> > > it's targeted at small embedded systems with limited memory, and the DRM
> > > framework is by no-means lightweight (TBH, fbdev isn't really either, but
> > > it's much more light weight than DRM).
> >
> > See my other mail, but you can write very simple drm drivers. And if
> > there's really a bloat problem for small systems we can add Kconfig knobs
> > to throw out everything not needed for simple drivers. The only problem
> > really is that everyone with such simple drivers doesn't even consider drm
> > "because I don't have a desktop gpu" which is just silly - drm has become
> > rather flexible. And that's essentially why writing simple drm drivers
> > still has a bit too much boilerplate, since no one yet bothered to add a
> > bit of helper support needed.
>
> Is there a simple way to convert existing fbdev drivers to DRM? Let's say I
> want to convert tridentfb to DRM, keeping the 2D acceleration (pan, fillrect,
> copyarea, imageblit) to be usable by the console (and maybe extend it to X11
> using some generic 2D driver?)
DRM doesn't do generic 2d accel, it's all driver specific. And consensus
for 2d accel (at least in X) is pretty much that if you have a 3d gpu use
glamour. If you don't have that then use the cpu. There's a hint for drm
userspace whether to use shadowfb for cpu rendering or not.
What you can do though if you want is keep your accel code for the fbdev
emulation on top of the drm modesetting driver, there's a few oddball
drivers who do that. And panning is of course already supported by the
modeset api.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Ondrej Zary @ 2015-09-24 17:12 UTC (permalink / raw)
To: dri-devel
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, Austin S Hemmelgarn, Tomi Valkeinen,
Laurent Pinchart, Daniel Vetter, Arnaud Patard, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <20150924155912.GW3383@phenom.ffwll.local>
On Thursday 24 September 2015 17:59:12 Daniel Vetter wrote:
> On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
> > On 2015-09-24 08:46, Thomas Petazzoni wrote:
> > >Hello,
> > >
> > >On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
> > >>fbdev is (more or less) maintained, but it's a deprecated framework.
> > >> All new Linux display drivers should be done on DRM.
> > >>
> > >>So let's not add any more new fbdev drivers.
> > >>
> > >>I will continue to maintain the current fbdev drivers, and I don't mind
> > >>adding some new features to those current drivers, as long as the
> > >> amount of code required to add the features stays sensible.
> > >>
> > >>I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> > >>and the question is what to do with those.
> > >>
> > >>xgifb was added in 2010, and is still in staging.
> > >>
> > >>fbtft looks like maybe some kind of framework on top of fbdev, with
> > >>fbtft specific subdrivers... I didn't look at it in detail, but my gut
> > >>says "never".
> > >
> > >fbtft mainly drives some very simple I2C-based or SPI-based displays,
> > >and DRM is I believe overkill for such displays. Last time I talked
> > >with Laurent Pinchart about such drivers, I believe he said that such
> > >simple drivers could probably continue to use the fbdev subsystem.
> >
> > I have to agree, using DRM _really_ doesn't make sense for these, the
> > devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
> > chips that are hooked up to equally simple TFT displays. There's no 3d
> > acceleration at all from what I can tell, there's _very_ limited 2d
> > acceleration, and most of the stuff that the DRM framework provides
> > call-backs for would have to be done on the CPU anyway. On top of that,
> > it's targeted at small embedded systems with limited memory, and the DRM
> > framework is by no-means lightweight (TBH, fbdev isn't really either, but
> > it's much more light weight than DRM).
>
> See my other mail, but you can write very simple drm drivers. And if
> there's really a bloat problem for small systems we can add Kconfig knobs
> to throw out everything not needed for simple drivers. The only problem
> really is that everyone with such simple drivers doesn't even consider drm
> "because I don't have a desktop gpu" which is just silly - drm has become
> rather flexible. And that's essentially why writing simple drm drivers
> still has a bit too much boilerplate, since no one yet bothered to add a
> bit of helper support needed.
Is there a simple way to convert existing fbdev drivers to DRM? Let's say I
want to convert tridentfb to DRM, keeping the 2D acceleration (pan, fillrect,
copyarea, imageblit) to be usable by the console (and maybe extend it to X11
using some generic 2D driver?)
--
Ondrej Zary
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Austin S Hemmelgarn @ 2015-09-24 16:17 UTC (permalink / raw)
To: Thomas Petazzoni, Tomi Valkeinen, Greg Kroah-Hartman, linux-fbdev,
DRI Development, Sudip Mukherjee, Teddy Wang, Noralf Trønnes,
Laurent Pinchart, Dave Airlie, linux-kernel@vger.kernel.org,
Arnaud Patard
In-Reply-To: <20150924155912.GW3383@phenom.ffwll.local>
[-- Attachment #1: Type: text/plain, Size: 3341 bytes --]
On 2015-09-24 11:59, Daniel Vetter wrote:
> On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
>> On 2015-09-24 08:46, Thomas Petazzoni wrote:
>>> Hello,
>>>
>>> On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
>>>
>>>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>>>> new Linux display drivers should be done on DRM.
>>>>
>>>> So let's not add any more new fbdev drivers.
>>>>
>>>> I will continue to maintain the current fbdev drivers, and I don't mind
>>>> adding some new features to those current drivers, as long as the amount
>>>> of code required to add the features stays sensible.
>>>>
>>>> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
>>>> and the question is what to do with those.
>>>>
>>>> xgifb was added in 2010, and is still in staging.
>>>>
>>>> fbtft looks like maybe some kind of framework on top of fbdev, with
>>>> fbtft specific subdrivers... I didn't look at it in detail, but my gut
>>>> says "never".
>>>
>>> fbtft mainly drives some very simple I2C-based or SPI-based displays,
>>> and DRM is I believe overkill for such displays. Last time I talked
>>> with Laurent Pinchart about such drivers, I believe he said that such
>>> simple drivers could probably continue to use the fbdev subsystem.
>> I have to agree, using DRM _really_ doesn't make sense for these, the
>> devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
>> chips that are hooked up to equally simple TFT displays. There's no 3d
>> acceleration at all from what I can tell, there's _very_ limited 2d
>> acceleration, and most of the stuff that the DRM framework provides
>> call-backs for would have to be done on the CPU anyway. On top of that,
>> it's targeted at small embedded systems with limited memory, and the DRM
>> framework is by no-means lightweight (TBH, fbdev isn't really either, but
>> it's much more light weight than DRM).
>
> See my other mail, but you can write very simple drm drivers. And if
> there's really a bloat problem for small systems we can add Kconfig knobs
> to throw out everything not needed for simple drivers. The only problem
> really is that everyone with such simple drivers doesn't even consider drm
> "because I don't have a desktop gpu" which is just silly - drm has become
> rather flexible. And that's essentially why writing simple drm drivers
> still has a bit too much boilerplate, since no one yet bothered to add a
> bit of helper support needed.
>
Rather ironically, I got your other mail right after I sent this one. I
hadn't realized most of the points you made there (it's been a long time
since I looked at any drm related code (largely because I've had
absolutely 0 issues on my systems with it, which is a good thing :))).
I do think being able to compile out some of the drm stuff that isn't
used on a given system would be nice, and some good helper functions to
simplify writing basic drivers would be absolutely wonderful.
As far as not considering it 'because I don't have a desktop GPU' goes,
I agree, that is silly, although for some people it may be 'because my
chip doesn't do any "rendering"', which brings up the rather complicated
discussion of what constitutes a GPU and what 'rendering' means.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Daniel Vetter @ 2015-09-24 15:59 UTC (permalink / raw)
To: Austin S Hemmelgarn
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen,
Laurent Pinchart, Daniel Vetter, Arnaud Patard, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <560414EB.508@gmail.com>
On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
> On 2015-09-24 08:46, Thomas Petazzoni wrote:
> >Hello,
> >
> >On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
> >
> >>fbdev is (more or less) maintained, but it's a deprecated framework. All
> >>new Linux display drivers should be done on DRM.
> >>
> >>So let's not add any more new fbdev drivers.
> >>
> >>I will continue to maintain the current fbdev drivers, and I don't mind
> >>adding some new features to those current drivers, as long as the amount
> >>of code required to add the features stays sensible.
> >>
> >>I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> >>and the question is what to do with those.
> >>
> >>xgifb was added in 2010, and is still in staging.
> >>
> >>fbtft looks like maybe some kind of framework on top of fbdev, with
> >>fbtft specific subdrivers... I didn't look at it in detail, but my gut
> >>says "never".
> >
> >fbtft mainly drives some very simple I2C-based or SPI-based displays,
> >and DRM is I believe overkill for such displays. Last time I talked
> >with Laurent Pinchart about such drivers, I believe he said that such
> >simple drivers could probably continue to use the fbdev subsystem.
> I have to agree, using DRM _really_ doesn't make sense for these, the
> devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
> chips that are hooked up to equally simple TFT displays. There's no 3d
> acceleration at all from what I can tell, there's _very_ limited 2d
> acceleration, and most of the stuff that the DRM framework provides
> call-backs for would have to be done on the CPU anyway. On top of that,
> it's targeted at small embedded systems with limited memory, and the DRM
> framework is by no-means lightweight (TBH, fbdev isn't really either, but
> it's much more light weight than DRM).
See my other mail, but you can write very simple drm drivers. And if
there's really a bloat problem for small systems we can add Kconfig knobs
to throw out everything not needed for simple drivers. The only problem
really is that everyone with such simple drivers doesn't even consider drm
"because I don't have a desktop gpu" which is just silly - drm has become
rather flexible. And that's essentially why writing simple drm drivers
still has a bit too much boilerplate, since no one yet bothered to add a
bit of helper support needed.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Alex Deucher @ 2015-09-24 15:38 UTC (permalink / raw)
To: Austin S Hemmelgarn
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen,
Laurent Pinchart, Daniel Vetter, Arnaud Patard, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <560414EB.508@gmail.com>
On Thu, Sep 24, 2015 at 11:21 AM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2015-09-24 08:46, Thomas Petazzoni wrote:
>>
>> Hello,
>>
>> On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
>>
>>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>>> new Linux display drivers should be done on DRM.
>>>
>>> So let's not add any more new fbdev drivers.
>>>
>>> I will continue to maintain the current fbdev drivers, and I don't mind
>>> adding some new features to those current drivers, as long as the amount
>>> of code required to add the features stays sensible.
>>>
>>> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
>>> and the question is what to do with those.
>>>
>>> xgifb was added in 2010, and is still in staging.
>>>
>>> fbtft looks like maybe some kind of framework on top of fbdev, with
>>> fbtft specific subdrivers... I didn't look at it in detail, but my gut
>>> says "never".
>>
>>
>> fbtft mainly drives some very simple I2C-based or SPI-based displays,
>> and DRM is I believe overkill for such displays. Last time I talked
>> with Laurent Pinchart about such drivers, I believe he said that such
>> simple drivers could probably continue to use the fbdev subsystem.
>
> I have to agree, using DRM _really_ doesn't make sense for these, the
> devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
> chips that are hooked up to equally simple TFT displays. There's no 3d
> acceleration at all from what I can tell, there's _very_ limited 2d
> acceleration, and most of the stuff that the DRM framework provides
> call-backs for would have to be done on the CPU anyway.
Just about all of the acceleration stuff is vendor specific so there's
really nothing you need to provide. As Daniel noted there are several
drm drivers for simple devices that do not support any kind of 2D or
3D acceleration. There are no requirements to provide any sort of
acceleration.
Alex
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Daniel Vetter @ 2015-09-24 15:23 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen,
Laurent Pinchart, Daniel Vetter, Arnaud Patard, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <20150924144621.40e26f0a@free-electrons.com>
On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
>
> > fbdev is (more or less) maintained, but it's a deprecated framework. All
> > new Linux display drivers should be done on DRM.
> >
> > So let's not add any more new fbdev drivers.
> >
> > I will continue to maintain the current fbdev drivers, and I don't mind
> > adding some new features to those current drivers, as long as the amount
> > of code required to add the features stays sensible.
> >
> > I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> > and the question is what to do with those.
> >
> > xgifb was added in 2010, and is still in staging.
> >
> > fbtft looks like maybe some kind of framework on top of fbdev, with
> > fbtft specific subdrivers... I didn't look at it in detail, but my gut
> > says "never".
>
> fbtft mainly drives some very simple I2C-based or SPI-based displays,
> and DRM is I believe overkill for such displays. Last time I talked
> with Laurent Pinchart about such drivers, I believe he said that such
> simple drivers could probably continue to use the fbdev subsystem.
>
> Or are there some plans to make the writing of DRM drivers for very
> simple/trivial devices a bit simpler?
Since years I'm trying to sell someone on implementing support for
drm_simple_outputs which would collapse the crtc->encoder->connector
chain into 1 entity. Would be trivial to implement and then trivial to
write simple drivers on top of that. And besides that drm already has
piles of reallly simple drivers with just one output and one framebuffer.
There's no reason not to use drm for gfx drivers at all.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Austin S Hemmelgarn @ 2015-09-24 15:21 UTC (permalink / raw)
To: Thomas Petazzoni, Tomi Valkeinen
Cc: Greg Kroah-Hartman, linux-fbdev, DRI Development, Sudip Mukherjee,
Teddy Wang, Noralf Trønnes, Laurent Pinchart, Dave Airlie,
Daniel Vetter, linux-kernel@vger.kernel.org, Arnaud Patard
In-Reply-To: <20150924144621.40e26f0a@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]
On 2015-09-24 08:46, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
>
>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>> new Linux display drivers should be done on DRM.
>>
>> So let's not add any more new fbdev drivers.
>>
>> I will continue to maintain the current fbdev drivers, and I don't mind
>> adding some new features to those current drivers, as long as the amount
>> of code required to add the features stays sensible.
>>
>> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
>> and the question is what to do with those.
>>
>> xgifb was added in 2010, and is still in staging.
>>
>> fbtft looks like maybe some kind of framework on top of fbdev, with
>> fbtft specific subdrivers... I didn't look at it in detail, but my gut
>> says "never".
>
> fbtft mainly drives some very simple I2C-based or SPI-based displays,
> and DRM is I believe overkill for such displays. Last time I talked
> with Laurent Pinchart about such drivers, I believe he said that such
> simple drivers could probably continue to use the fbdev subsystem.
I have to agree, using DRM _really_ doesn't make sense for these, the
devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
chips that are hooked up to equally simple TFT displays. There's no 3d
acceleration at all from what I can tell, there's _very_ limited 2d
acceleration, and most of the stuff that the DRM framework provides
call-backs for would have to be done on the CPU anyway. On top of that,
it's targeted at small embedded systems with limited memory, and the DRM
framework is by no-means lightweight (TBH, fbdev isn't really either,
but it's much more light weight than DRM).
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Thomas Petazzoni @ 2015-09-24 12:46 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Greg Kroah-Hartman, linux-fbdev, DRI Development, Sudip Mukherjee,
Teddy Wang, Noralf Trønnes, Laurent Pinchart, Dave Airlie,
Daniel Vetter, linux-kernel@vger.kernel.org, Arnaud Patard
In-Reply-To: <5603EC15.9090605@ti.com>
Hello,
On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
>
> So let's not add any more new fbdev drivers.
>
> I will continue to maintain the current fbdev drivers, and I don't mind
> adding some new features to those current drivers, as long as the amount
> of code required to add the features stays sensible.
>
> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> and the question is what to do with those.
>
> xgifb was added in 2010, and is still in staging.
>
> fbtft looks like maybe some kind of framework on top of fbdev, with
> fbtft specific subdrivers... I didn't look at it in detail, but my gut
> says "never".
fbtft mainly drives some very simple I2C-based or SPI-based displays,
and DRM is I believe overkill for such displays. Last time I talked
with Laurent Pinchart about such drivers, I believe he said that such
simple drivers could probably continue to use the fbdev subsystem.
Or are there some plans to make the writing of DRM drivers for very
simple/trivial devices a bit simpler?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* No more new fbdev drivers, please
From: Tomi Valkeinen @ 2015-09-24 12:27 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-fbdev, DRI Development
Cc: Thomas Petazzoni, Teddy Wang, Daniel Vetter,
linux-kernel@vger.kernel.org, Laurent Pinchart, Arnaud Patard,
Dave Airlie, Sudip Mukherjee
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]
Hi all,
fbdev is (more or less) maintained, but it's a deprecated framework. All
new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind
adding some new features to those current drivers, as long as the amount
of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with
fbtft specific subdrivers... I didn't look at it in detail, but my gut
says "never".
SM750 hardware seems to support multiple outputs, hardware overlays, 2D
accelerator... I think it's pointless to write an fbdev driver for such
a HW, as it's not possible to use those features with fbdev (without
custom API).
So, without spending too much time looking at those drivers, and without
speaking to the authors, my initial suggestion is to remove them.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] staging: sm7xxfb: move sm712fb out of staging
From: Tomi Valkeinen @ 2015-09-24 11:58 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Jean-Christophe Plagniol-Villard, Jonathan Corbet,
Greg Kroah-Hartman, linux-kernel, linux-fbdev, linux-doc, devel
In-Reply-To: <20150902124811.GA25301@sudip-pc>
[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]
On 02/09/15 15:48, Sudip Mukherjee wrote:
> Now I am getting confused. :(
> Since this has already been merged I guess we need to maintain it now.
Oh, ok. I thought it was still in staging. I haven't been able to follow
the list properly lately...
Well, in theory we could still revert it, as it's only -rc2.
> So then should I fix the things you pointed out or should i instead
> give more priority to the DRM driver and fix these things later?
Is there a public datasheet for the HW?
The driver as it is now is quite horrible. Huge tables of raw data,
written directly to the registers. Lots of magic numbers all around.
Even with a datasheet, presuming it's public and it contains all those
values, the driver is rather unmaintainable.
All those need to be sorted out for the DRM driver anyway, so maybe it's
better to clean up the fb driver first.
> And, just to inform you, there are two more fbdev drivers in staging,
> staging/sm750fb and staging/fbtft. And the ultimate goal of any driver
Thanks for pointing this out, I need to check those and think how to
proceed.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] omapdss: acx565akm: Fix module autoload for OF platform driver
From: Tomi Valkeinen @ 2015-09-24 11:37 UTC (permalink / raw)
To: Luis de Bethencourt, linux-kernel
Cc: Jean-Christophe Plagniol-Villard, linux-omap, linux-fbdev,
Javier Martinez Canillas
In-Reply-To: <5603CDD1.7030709@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]
On 24/09/15 13:17, Tomi Valkeinen wrote:
>
>
> On 18/09/15 21:44, Luis de Bethencourt wrote:
>> This platform driver has a OF device ID table but the OF module
>> alias information is not created so module autoloading won't work.
>>
>> Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
>> ---
>>
>> Hello,
>>
>> This patch adds the missing MODULE_DEVICE_TABLE() for OF to export
>> that information so modules have the correct aliases built-in and
>> autoloading works correctly.
>>
>> A longer explanation by Javier Canillas can be found here:
>> https://lkml.org/lkml/2015/7/30/519
>>
>> Thanks,
>> Luis
>>
>> drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
>> index 90cbc4c..c581231 100644
>> --- a/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
>> +++ b/drivers/video/fbdev/omap2/displays-new/panel-sony-acx565akm.c
>> @@ -898,6 +898,7 @@ static const struct of_device_id acx565akm_of_match[] = {
>> { .compatible = "omapdss,sony,acx565akm", },
>> {},
>> };
>> +MODULE_DEVICE_TABLE(of, acx565akm_of_match);
>>
>> static struct spi_driver acx565akm_driver = {
>> .driver = {
>>
>
> Thanks, queued for 4.3 fixes.
Oh, there was an earlier patch from Javier already posted. So I'll pick
that one instead.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] fbdev: omap2: connector-dvi: use of_get_i2c_adapter_by_node interface
From: Tomi Valkeinen @ 2015-09-24 11:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1442322753-32043-1-git-send-email-vladimir_zapolskiy@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]
On 15/09/15 16:12, Vladimir Zapolskiy wrote:
> This change is needed to properly lock I2C bus driver, which serves DDC.
>
> Prior to this change i2c_put_adapter() is misused, which may lead to
> an overflow over zero of I2C bus driver user counter.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> Changes from v1 to v2:
> - none, v1 is http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354990.html
>
> The original series http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354982.html
> is separated to i2c, dri and fbdev parts, at the moment i2c part
> with new of_get_i2c_adapter_by_node() interface has been applied.
>
> drivers/video/fbdev/omap2/displays-new/connector-dvi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/omap2/displays-new/connector-dvi.c b/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
> index a8ce920..d811e6d 100644
> --- a/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
> +++ b/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
> @@ -294,7 +294,7 @@ static int dvic_probe_of(struct platform_device *pdev)
>
> adapter_node = of_parse_phandle(node, "ddc-i2c-bus", 0);
> if (adapter_node) {
> - adapter = of_find_i2c_adapter_by_node(adapter_node);
> + adapter = of_get_i2c_adapter_by_node(adapter_node);
> if (adapter == NULL) {
> dev_err(&pdev->dev, "failed to parse ddc-i2c-bus\n");
> omap_dss_put_device(ddata->in);
>
Thanks, queued for 4.3 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: put module after running driver callback
From: Tomi Valkeinen @ 2015-09-24 11:24 UTC (permalink / raw)
To: David Herrmann, linux-fbdev; +Cc: Jean-Christophe Plagniol-Villard, dri-devel
In-Reply-To: <1441987843-4313-1-git-send-email-dh.herrmann@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]
On 11/09/15 19:10, David Herrmann wrote:
> Currently, for each open() on an fbdev device, we pin the underlying
> fbdev device and driver module. On close(), we release both. This
> guarantees that the fbdev object stays around until the last FD is
> released (even though it might be unregistered already).
>
> However, currently we call module_put() *before* calling put_fb_info().
> This has the side-effect that the driver module might be unloaded before
> put_fb_info() calls into fbinfo->fbops->fb_destroy().
>
> Fix this by keeping the module pinned until after we release our fbdev
> reference. Note that register_framebuffer() and unregister_framebuffer()
> are special as we require the driver to unregister device before
> unloading. Hence, they don't need to pin the module. However, all open
> handlers *have to*.
>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> ---
> drivers/video/fbdev/core/fbmem.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 0705d88..4e78731 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1482,13 +1482,16 @@ __acquires(&info->lock)
> __releases(&info->lock)
> {
> struct fb_info * const info = file->private_data;
> + struct module *owner;
>
> mutex_lock(&info->lock);
> if (info->fbops->fb_release)
> info->fbops->fb_release(info,1);
> - module_put(info->fbops->owner);
> + owner = info->fbops->owner;
> mutex_unlock(&info->lock);
> +
> put_fb_info(info);
> + module_put(owner);
> return 0;
> }
Looking at fb_open(), in error case it calls module_put() followed by
put_fb_info(). Is that broken also?
Have you hit this bug, or did you just find it by looking at the code?
In other words, is this for 4.3 fixes, or 4.4. I guess the user needs to
unload the module just at the right time to trigger this bug.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] SSD1307fb updates
From: Tomi Valkeinen @ 2015-09-24 11:11 UTC (permalink / raw)
To: Olliver Schinagl, Olliver Schinagl, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala,
Jean-Christophe Plagniol-Villard
Cc: Thomas Niederprüm, Maxime Ripard, Prabhakar Lad,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1441739991-4676-1-git-send-email-o.schinagl-U3FVU11NWA554TAoqtyWWQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]
On 08/09/15 22:19, Olliver Schinagl wrote:
> Having a few ssd1309 128x64 OLED displays laying around, I added support for it to the existing 1307fb driver. While doing this I noticed the headers where out of order so I fixed those as well.
>
> For this specific display, the following can be used in a i2c node for example.
>
> ssd1309: oled@3c {
> compatible = "solomon,ssd1309fb-i2c";
> pinctrl-names = "default";
> pinctrl-0 = <&oled_pins>;
> reg = <0x3c>;
> reset-gpios = <&pio 8 13 GPIO_ACTIVE_HIGH>;
> solomon,width = <128>;
> solomon,height = <64>;
> solomon,com-invdir;
> solomon,page-offset = <0>;
> solomon,prechargep1 = <2>;
> solomon,prechargep2 = <8>;
> };
>
> Olliver Schinagl (2):
> fbdev: ssd1307fb: alphabetize headers
> fbdev: ssd1307fb: add ssd1309 support
>
> .../devicetree/bindings/video/ssd1307fb.txt | 3 ++-
> drivers/video/fbdev/ssd1307fb.c | 21 ++++++++++++++++-----
> 2 files changed, 18 insertions(+), 6 deletions(-)
>
Thanks, queued for 4.4.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] [resend #2] tridentfb: Fix set_lwidth on TGUI9440 and CYBER9320
From: Tomi Valkeinen @ 2015-09-24 11:07 UTC (permalink / raw)
To: Ondrej Zary, Krzysztof Helt; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1440445048-24694-2-git-send-email-linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]
On 24/08/15 22:37, Ondrej Zary wrote:
> According to X.Org driver, chips older than TGUI9660 have only 1 width bit
> in AddColReg. Touching the 2nd one causes I2C/DDC to fail on TGUI9440.
>
> Set only 1 bit of width in AddColReg on TGUI9440 and CYBER9320.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> ---
> drivers/video/fbdev/tridentfb.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
> index 7429713..01b43e9 100644
> --- a/drivers/video/fbdev/tridentfb.c
> +++ b/drivers/video/fbdev/tridentfb.c
> @@ -673,8 +673,14 @@ static int get_nativex(struct tridentfb_par *par)
> static inline void set_lwidth(struct tridentfb_par *par, int width)
> {
> write3X4(par, VGA_CRTC_OFFSET, width & 0xFF);
> - write3X4(par, AddColReg,
> - (read3X4(par, AddColReg) & 0xCF) | ((width & 0x300) >> 4));
> + /* chips older than TGUI9660 have only 1 width bit in AddColReg */
> + /* touching the other one breaks I2C/DDC */
> + if (par->chip_id == TGUI9440 || par->chip_id == CYBER9320)
> + write3X4(par, AddColReg,
> + (read3X4(par, AddColReg) & 0xEF) | ((width & 0x100) >> 4));
> + else
> + write3X4(par, AddColReg,
> + (read3X4(par, AddColReg) & 0xCF) | ((width & 0x300) >> 4));
> }
>
> /* For resolutions smaller than FP resolution stretch */
>
Thanks, queued for 4.3 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] [resend #2] tridentfb: fix hang on Blade3D with CONFIG_CC_OPTIMIZE_FOR_SIZE
From: Tomi Valkeinen @ 2015-09-24 11:06 UTC (permalink / raw)
To: Ondrej Zary, Krzysztof Helt; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1440445048-24694-1-git-send-email-linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
On 24/08/15 22:37, Ondrej Zary wrote:
> When the kernel is compiled with -Os (CONFIG_CC_OPTIMIZE_FOR_SIZE), tridentfb
> hangs the machine upon load with Blade3D cards unless acceleration is disabled.
>
> This is caused by memcpy() which copies data byte-by-byte (rep movsb) when
> compiled with -Os. The card does not like that - it requires 32-bit access.
>
> Use iowrite_32() instead.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl>
> ---
> drivers/video/fbdev/tridentfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/tridentfb.c b/drivers/video/fbdev/tridentfb.c
> index 7ed9a22..7429713 100644
> --- a/drivers/video/fbdev/tridentfb.c
> +++ b/drivers/video/fbdev/tridentfb.c
> @@ -226,7 +226,7 @@ static void blade_image_blit(struct tridentfb_par *par, const char *data,
> writemmr(par, DST1, point(x, y));
> writemmr(par, DST2, point(x + w - 1, y + h - 1));
>
> - memcpy(par->io_virt + 0x10000, data, 4 * size);
> + iowrite32_rep(par->io_virt + 0x10000, data, size);
> }
>
> static void blade_copy_rect(struct tridentfb_par *par,
>
Thanks, queued for 4.3 fixes.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] [resend #2] fb_ddc: Allow I2C adapters without SCL read capability
From: Tomi Valkeinen @ 2015-09-24 11:04 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Krzysztof Helt, linux-fbdev, Kernel development list
In-Reply-To: <201509021404.51232.linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]
On 02/09/15 15:04, Ondrej Zary wrote:
> On Wednesday 02 September 2015, Tomi Valkeinen wrote:
>> On 24/08/15 22:37, Ondrej Zary wrote:
>>> i2c-algo-bit allows I2C adapters without SCL read capability to work but
>>> fb_ddc_read fails to work on them.
>>>
>>> Fix fb_ddc_read to work with I2C adapters not capable of reading SCL.
>>>
>>> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
>>> Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl>
>>> ---
>>> drivers/video/fbdev/core/fb_ddc.c | 8 +++++---
>>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/core/fb_ddc.c
>>> b/drivers/video/fbdev/core/fb_ddc.c index 94322cc..22c694a 100644
>>> --- a/drivers/video/fbdev/core/fb_ddc.c
>>> +++ b/drivers/video/fbdev/core/fb_ddc.c
>>> @@ -69,10 +69,11 @@ unsigned char *fb_ddc_read(struct i2c_adapter
>>> *adapter) algo_data->setscl(algo_data->data, 1);
>>> for (j = 0; j < 5; j++) {
>>> msleep(10);
>>> - if (algo_data->getscl(algo_data->data))
>>> + if (algo_data->getscl &&
>>> + algo_data->getscl(algo_data->data))
>>> break;
>>> }
>>> - if (j == 5)
>>> + if (algo_data->getscl && j == 5)
>>> continue;
>>>
>>> algo_data->setsda(algo_data->data, 0);
>>> @@ -91,7 +92,8 @@ unsigned char *fb_ddc_read(struct i2c_adapter *adapter)
>>> algo_data->setscl(algo_data->data, 1);
>>> for (j = 0; j < 10; j++) {
>>> msleep(10);
>>> - if (algo_data->getscl(algo_data->data))
>>> + if (algo_data->getscl &&
>>> + algo_data->getscl(algo_data->data))
>>> break;
>>> }
>>
>> Aren't both of those loops pointless if there's no getscl?
>
> They're reduced to delays - don't know how much critical they are.
I think the code gets somewhat confusing the way you did it.
Maybe instead something like:
if (algo_data->getscl) {
the current loop & delays here;
} else {
msleep(25); // 25 was just a guess...
}
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] [resend #2] tridentfb: Add DDC support
From: Tomi Valkeinen @ 2015-09-24 11:00 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Krzysztof Helt, linux-fbdev, Kernel development list
In-Reply-To: <201509021404.37885.linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 595 bytes --]
On 02/09/15 15:04, Ondrej Zary wrote:
>>> +config FB_TRIDENT_DDC
>>> + bool "DDC for Trident support"
>>> + depends on FB_TRIDENT
>>> + select FB_DDC
>>> + select FB_MODE_HELPERS
>>> + default y
>>> + help
>>> + Say Y here if you want DDC support for your Trident graphics card.
>>> +
>>
>> Why would somebody not want this enabled? Is there some drawback if it's
>> enabled?
>
> It's probably an useless config option but many fbdev drivers have it. I have
> no problem removing it.
Yes, I'd rather see it removed, if no one sees any use for the option.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] fbdev: Debug knob to register without holding console_lock
From: Tomi Valkeinen @ 2015-09-24 10:56 UTC (permalink / raw)
To: Rob Clark
Cc: Daniel Vetter, Intel Graphics Development,
Jean-Christophe Plagniol-Villard, Linux Fbdev development list,
DRI Development
In-Reply-To: <CAF6AEGtV1-tgvA0D-BFZ8NMNyNN7C8-jst5xXBKrQHGFVWCpyA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On 01/09/15 17:34, Rob Clark wrote:
> I hadn't had a chance to look at it further yet.. I think Daniel
> claimed it worked for him, but he was probably on intel-next, where I
> was on drm-next at the time which seemed to be having some unrelated
> i915 issues (when I was trying to debug atomic fb-helper patches). So
> can't really say that the issue I had was actually related to this
> patch. I'll try again later this week or next, when hopefully i915 in
> drm-next is in better shape..
Rob, did you have a chance to test this?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] ocfb: remove incorrect __iomem annotation
From: Tomi Valkeinen @ 2015-09-24 10:54 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On 17/08/15 11:10, Christoph Hellwig wrote:
> Make sparse happy:
Well, I think someone will anyway be unhappy:
- memset_io() is used to clear fb_virt.
- fb_virt is assigned to fbdev->info.screen_base.
I don't know if it's better or worse to have the __iomem in ocfb.c...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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