* Re: [PATCH v4 3/17] video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
From: Ingo Molnar @ 2015-05-29 6:41 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: tomi.valkeinen, linux-kernel, linux-fbdev, Luis R. Rodriguez,
Thomas Gleixner, Juergen Gross, Jingoo Han, Daniel Vetter,
Masanari Iida, Suresh Siddha, Ingo Molnar, Andy Lutomirski,
Dave Airlie, Antonino Daplas, Jean-Christophe Plagniol-Villard
In-Reply-To: <1432859434-17821-3-git-send-email-mcgrof@do-not-panic.com>
* Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:
> + gbe_mem = devm_ioremap_wc(&p_dev->dev, gbe_mem_phys,
> + gbe_mem_size);
> + gbe_mem = dma_alloc_writecombine(NULL, gbe_mem_size,
> + &gbe_dma_addr, GFP_KERNEL);
> + par->wc_cookie = arch_phys_wc_add(gbe_mem_phys, gbe_mem_size);
> + arch_phys_wc_del(par->wc_cookie);
> + arch_phys_wc_del(par->wc_cookie);
Could we _please_ rename dma_*_writecombine() to dma_*_wc(), so that the naming is
coherent across the various APIs?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] fbdev: omap2: improve usage of gpiod API
From: Tomi Valkeinen @ 2015-05-29 6:07 UTC (permalink / raw)
To: Uwe Kleine-König, Jean-Christophe Plagniol-Villard
Cc: linux-omap, linux-fbdev, Linus Walleij, kernel
In-Reply-To: <1432800315-25972-1-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]
On 28/05/15 11:05, Uwe Kleine-König wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter that allows to specify direction and initial value for output.
>
> Also make use of gpiod_get*_optional where applicable.
>
> Apart from simplification of the affected drivers this is another step
> towards making the flags argument to gpiod_get*() mandatory.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 12 +++---------
> drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 13 +++----------
> .../fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c | 7 +++----
> .../fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c | 9 ++-------
> 4 files changed, 11 insertions(+), 30 deletions(-)
Thanks, this cleans up nicely those optional cases. Queued for 4.2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/4] pci: add pci_iomap_wc() variants
From: Tomi Valkeinen @ 2015-05-29 5:57 UTC (permalink / raw)
To: Luis R. Rodriguez, Bjorn Helgaas
Cc: Dave Airlie, linux-fbdev, Andy Lutomirski,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
xen-devel@lists.xensource.com, Toshi Kani, Suresh Siddha,
Ingo Molnar, Thomas Gleixner, Juergen Gross, Daniel Vetter,
Dave Airlie, Antonino Daplas, Jean-Christophe Plagniol-Villard,
Dave Hansen, Arnd Bergmann, Michael S. Tsirkin,
venkatesh.pallipadi, Stefan Bader, Ville Syrjälä,
Mel Gorman, Vlastimil Babka, Borislav Petkov, Davidlohr Bueso,
Konrad Rzeszutek Wilk, Ville Syrjälä, David Vrabel,
Jan Beulich, Roger Pau Monné
In-Reply-To: <CAB=NE6Xyd-THK2385W7VfS358PSJfkfHRnjoZRJWP_LFrzOWJA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2457 bytes --]
On 29/05/15 03:36, Luis R. Rodriguez wrote:
> On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>>> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
>>>> On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
>>>>>
>>>>> I tentatively put this (and the rest of the series) on a pci/resource
>>>>> branch. I'm hoping you'll propose some clarification about
>>>>> EXPORT_SYMBOL_GPL().
>>>>
>>>> EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
>>>> only run that code. So for instance although we have "Dual BSD/GPL"
>>>> tags for modules pure "BSD" tags do not exist for module tags and
>>>> cannot run EXPORT_SYMBOL_GPL() code [0]. Also there is some folks
>>>> who do believe tha at run time all kernel modules are GPL [1] [2].
>>>> And to be precise even though the FSF may claim a list of licenses
>>>> are GPL-compatible we cannot rely on this list alone for our own
>>>> goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must
>>>> discuss this on lkml [2].
>>>
>>> By "propose some clarification," I meant that I hoped you would propose a
>>> patch to Documentation/ that would give maintainers some guidance.
>>
>> I *really really* would hate to do so but only because you insist, I'll look
>> into this...
>
> OK done. Please let me know if there is anything else I can do to
> help. Also as per review with Tomi, the framebuffer maintainer, he
> would prefer for only the required symbols to go through your tree.
> We'd then wait for the next merge window for them to perculate to
> Linus' tree and once there I'd send him a pull request for the
> framebuffer device driver changes alone. So this does mean we'll have
> no users of the symbols for a full release, but again, this is as per
> Tomi's preference. This strategy is also the preference then for the
> pci_iomap_wc() series as well. With that in mind, perhaps the lib
> patch can go in as we'd have no users but we do have a few future
> possible expected users.
I don't have any issue with fbdev changes going through other trees, but
I'd rather do that only if there are good reasons to go that way.
These changes to fbdev drivers look like cleanups, so they are not
critical, right? Does delaying the fbdev changes until the dependencies
are in prevent some other development?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Tomi Valkeinen @ 2015-05-29 5:48 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-kernel, linux-fbdev, Luis R. Rodriguez
In-Reply-To: <1432859434-17821-1-git-send-email-mcgrof@do-not-panic.com>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On 29/05/15 03:30, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Tomi,
>
> Upon integration onto your tree of the series, "[PATCH v3 00/17] framebuffer:
> simple conversions to arch_phys_wc_add()" the 0 day build bot found a
> compilation issue on the gbefb driver. I had test compiled drivers with
> allyesconfig and allmodconfig but failed to test compile against MIPS. This
> driver is enabled *only for MIPS*. For the life me I could not get a MIPS
> cross compiler even on debian, so what I did to test this was incorporate into
> my private tree a temporary patch [0] which enables this driver to compile on
> x86 and go test compile with that as a temporary patch. The compilation was
> failing since I used the info struct instead of the actual private data
> structure. This fixes that and moves its assignment early. Sorry about that.
>
> The rest of the series does not require changes for integration after these
> two patch replacements. Let me know if you'd like me to respin the entire
> series though, but I didn't since I figured its pointless as the patches remain
> intact. For your convenience however I've rebased all these 17 patches onto
> your latest tree on the for-next branch, you can pull the changes with the
> details provided below. This v4 iteration only carries the two patches which
> required updates. The details of the full pull request go below this.
Thanks, I've updated the two patches, and pushed the series to my for-next.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/4] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-05-29 0:36 UTC (permalink / raw)
To: Bjorn Helgaas, Tomi Valkeinen
Cc: Luis R. Rodriguez, Dave Airlie, linux-fbdev, Andy Lutomirski,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
xen-devel@lists.xensource.com, Toshi Kani, Suresh Siddha,
Ingo Molnar, Thomas Gleixner, Juergen Gross, Daniel Vetter,
Dave Airlie, Antonino Daplas, Jean-Christophe Plagniol-Villard,
Dave Hansen, Arnd Bergmann, Michael S. Tsirkin,
venkatesh.pallipadi, Stefan Bader, Ville Syrjälä,
Mel Gorman, Vlastimil Babka, Borislav Petkov, Davidlohr Bueso,
Konrad Rzeszutek Wilk, Ville Syrjälä, David Vrabel,
Jan Beulich, Roger Pau Monné
In-Reply-To: <20150527200402.GS23057@wotan.suse.de>
On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
>> > On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
>> > >
>> > > I tentatively put this (and the rest of the series) on a pci/resource
>> > > branch. I'm hoping you'll propose some clarification about
>> > > EXPORT_SYMBOL_GPL().
>> >
>> > EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
>> > only run that code. So for instance although we have "Dual BSD/GPL"
>> > tags for modules pure "BSD" tags do not exist for module tags and
>> > cannot run EXPORT_SYMBOL_GPL() code [0]. Also there is some folks
>> > who do believe tha at run time all kernel modules are GPL [1] [2].
>> > And to be precise even though the FSF may claim a list of licenses
>> > are GPL-compatible we cannot rely on this list alone for our own
>> > goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must
>> > discuss this on lkml [2].
>>
>> By "propose some clarification," I meant that I hoped you would propose a
>> patch to Documentation/ that would give maintainers some guidance.
>
> I *really really* would hate to do so but only because you insist, I'll look
> into this...
OK done. Please let me know if there is anything else I can do to
help. Also as per review with Tomi, the framebuffer maintainer, he
would prefer for only the required symbols to go through your tree.
We'd then wait for the next merge window for them to perculate to
Linus' tree and once there I'd send him a pull request for the
framebuffer device driver changes alone. So this does mean we'll have
no users of the symbols for a full release, but again, this is as per
Tomi's preference. This strategy is also the preference then for the
pci_iomap_wc() series as well. With that in mind, perhaps the lib
patch can go in as we'd have no users but we do have a few future
possible expected users.
Luis
^ permalink raw reply
* [PATCH v4 3/17] video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
From: Luis R. Rodriguez @ 2015-05-29 0:30 UTC (permalink / raw)
To: tomi.valkeinen
Cc: linux-kernel, linux-fbdev, Luis R. Rodriguez, Thomas Gleixner,
Juergen Gross, Jingoo Han, Daniel Vetter, Masanari Iida,
Suresh Siddha, Ingo Molnar, Andy Lutomirski, Dave Airlie,
Antonino Daplas, Jean-Christophe Plagniol-Villard
In-Reply-To: <1432859434-17821-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Masanari Iida <standby24x7@gmail.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
drivers/video/fbdev/gbefb.c | 26 +++++++-------------------
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 4e54faa06..d2601808 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -22,9 +22,6 @@
#include <linux/module.h>
#include <linux/io.h>
-#ifdef CONFIG_X86
-#include <asm/mtrr.h>
-#endif
#ifdef CONFIG_MIPS
#include <asm/addrspace.h>
#endif
@@ -1176,8 +1173,8 @@ static int gbefb_probe(struct platform_device *p_dev)
if (gbe_mem_phys) {
/* memory was allocated at boot time */
- gbe_mem = devm_ioremap_nocache(&p_dev->dev, gbe_mem_phys,
- gbe_mem_size);
+ gbe_mem = devm_ioremap_wc(&p_dev->dev, gbe_mem_phys,
+ gbe_mem_size);
if (!gbe_mem) {
printk(KERN_ERR "gbefb: couldn't map framebuffer\n");
ret = -ENOMEM;
@@ -1188,8 +1185,8 @@ static int gbefb_probe(struct platform_device *p_dev)
} else {
/* try to allocate memory with the classical allocator
* this has high chance to fail on low memory machines */
- gbe_mem = dma_alloc_coherent(NULL, gbe_mem_size, &gbe_dma_addr,
- GFP_KERNEL);
+ gbe_mem = dma_alloc_writecombine(NULL, gbe_mem_size,
+ &gbe_dma_addr, GFP_KERNEL);
if (!gbe_mem) {
printk(KERN_ERR "gbefb: couldn't allocate framebuffer memory\n");
ret = -ENOMEM;
@@ -1200,10 +1197,7 @@ static int gbefb_probe(struct platform_device *p_dev)
}
par = info->par;
-#ifdef CONFIG_X86
- par->wc_cookie = mtrr_add(gbe_mem_phys, gbe_mem_size,
- MTRR_TYPE_WRCOMB, 1);
-#endif
+ par->wc_cookie = arch_phys_wc_add(gbe_mem_phys, gbe_mem_size);
/* map framebuffer memory into tiles table */
for (i = 0; i < (gbe_mem_size >> TILE_SHIFT); i++)
@@ -1242,10 +1236,7 @@ static int gbefb_probe(struct platform_device *p_dev)
return 0;
out_gbe_unmap:
-#ifdef CONFIG_MTRR
- if (par->wc_cookie >= 0)
- mtrr_del(par->wc_cookie, 0, 0);
-#endif
+ arch_phys_wc_del(par->wc_cookie);
if (gbe_dma_addr)
dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
out_tiles_free:
@@ -1266,10 +1257,7 @@ static int gbefb_remove(struct platform_device* p_dev)
unregister_framebuffer(info);
gbe_turn_off();
-#ifdef CONFIG_MTRR
- if (par->wc_cookie >= 0)
- mtrr_del(par->wc_cookie, 0, 0);
-#endif
+ arch_phys_wc_del(par->wc_cookie);
if (gbe_dma_addr)
dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* [PATCH v4 2/17] video: fbdev: gbefb: add missing mtrr_del() calls
From: Luis R. Rodriguez @ 2015-05-29 0:30 UTC (permalink / raw)
To: tomi.valkeinen
Cc: linux-kernel, linux-fbdev, Luis R. Rodriguez, Thomas Gleixner,
Juergen Gross, Jingoo Han, Daniel Vetter, Masanari Iida,
Suresh Siddha, Ingo Molnar, Andy Lutomirski, Dave Airlie,
Antonino Daplas, Jean-Christophe Plagniol-Villard
In-Reply-To: <1432859434-17821-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This driver never removed the MTRRs. Fix that.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Masanari Iida <standby24x7@gmail.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
drivers/video/fbdev/gbefb.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 6d9ef39..4e54faa06 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -38,6 +38,7 @@ static struct sgi_gbe *gbe;
struct gbefb_par {
struct fb_var_screeninfo var;
struct gbe_timing_info timing;
+ int wc_cookie;
int valid;
};
@@ -1198,8 +1199,10 @@ static int gbefb_probe(struct platform_device *p_dev)
gbe_mem_phys = (unsigned long) gbe_dma_addr;
}
+ par = info->par;
#ifdef CONFIG_X86
- mtrr_add(gbe_mem_phys, gbe_mem_size, MTRR_TYPE_WRCOMB, 1);
+ par->wc_cookie = mtrr_add(gbe_mem_phys, gbe_mem_size,
+ MTRR_TYPE_WRCOMB, 1);
#endif
/* map framebuffer memory into tiles table */
@@ -1215,7 +1218,6 @@ static int gbefb_probe(struct platform_device *p_dev)
/* reset GBE */
gbe_reset();
- par = info->par;
/* turn on default video mode */
if (fb_find_mode(&par->var, info, mode_option, NULL, 0,
default_mode, 8) = 0)
@@ -1240,6 +1242,10 @@ static int gbefb_probe(struct platform_device *p_dev)
return 0;
out_gbe_unmap:
+#ifdef CONFIG_MTRR
+ if (par->wc_cookie >= 0)
+ mtrr_del(par->wc_cookie, 0, 0);
+#endif
if (gbe_dma_addr)
dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
out_tiles_free:
@@ -1256,9 +1262,14 @@ out_release_framebuffer:
static int gbefb_remove(struct platform_device* p_dev)
{
struct fb_info *info = platform_get_drvdata(p_dev);
+ struct gbefb_par *par = info->par;
unregister_framebuffer(info);
gbe_turn_off();
+#ifdef CONFIG_MTRR
+ if (par->wc_cookie >= 0)
+ mtrr_del(par->wc_cookie, 0, 0);
+#endif
if (gbe_dma_addr)
dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* [PATCH v4 0/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Luis R. Rodriguez @ 2015-05-29 0:30 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-kernel, linux-fbdev, Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Tomi,
Upon integration onto your tree of the series, "[PATCH v3 00/17] framebuffer:
simple conversions to arch_phys_wc_add()" the 0 day build bot found a
compilation issue on the gbefb driver. I had test compiled drivers with
allyesconfig and allmodconfig but failed to test compile against MIPS. This
driver is enabled *only for MIPS*. For the life me I could not get a MIPS
cross compiler even on debian, so what I did to test this was incorporate into
my private tree a temporary patch [0] which enables this driver to compile on
x86 and go test compile with that as a temporary patch. The compilation was
failing since I used the info struct instead of the actual private data
structure. This fixes that and moves its assignment early. Sorry about that.
The rest of the series does not require changes for integration after these
two patch replacements. Let me know if you'd like me to respin the entire
series though, but I didn't since I figured its pointless as the patches remain
intact. For your convenience however I've rebased all these 17 patches onto
your latest tree on the for-next branch, you can pull the changes with the
details provided below. This v4 iteration only carries the two patches which
required updates. The details of the full pull request go below this.
[0] http://drvbp1.linux-foundation.org/~mcgrof/patches/tmp/enable-gbefb-x86.patch
Luis R. Rodriguez (2):
video: fbdev: gbefb: add missing mtrr_del() calls
video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
drivers/video/fbdev/gbefb.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
The following changes since commit 36520841a443d5ee966f9632c417fcc8a25e07e3:
video/console: use swap() in newport_bmove() (2015-05-27 12:54:49 +0300)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-framebuffer.git simple-arch_phys-20150528
for you to fetch changes up to 29b0c802f84943cac3658927452a2da4c976c632:
video: fbdev: geode gxfb: use ioremap_wc() for framebuffer (2015-05-28 17:16:43 -0700)
----------------------------------------------------------------
Luis R. Rodriguez (17):
video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: gbefb: add missing mtrr_del() calls
video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: i810: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: pm2fb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: pm3fb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: rivafb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: tdfxfb: use arch_phys_wc_add() and ioremap_wc()
video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer
video: fbdev: geode gxfb: use ioremap_wc() for framebuffer
drivers/video/fbdev/atmel_lcdfb.c | 3 +-
drivers/video/fbdev/aty/aty128fb.c | 36 ++++--------------------
drivers/video/fbdev/aty/radeon_base.c | 29 ++++----------------
drivers/video/fbdev/aty/radeonfb.h | 2 +-
drivers/video/fbdev/gbefb.c | 21 +++++++-------
drivers/video/fbdev/geode/gxfb_core.c | 3 +-
drivers/video/fbdev/i810/i810.h | 3 +-
drivers/video/fbdev/i810/i810_main.c | 11 +++++---
drivers/video/fbdev/i810/i810_main.h | 26 ------------------
drivers/video/fbdev/intelfb/intelfb.h | 4 +--
drivers/video/fbdev/intelfb/intelfbdrv.c | 38 +++-----------------------
drivers/video/fbdev/matrox/matroxfb_base.c | 36 +++++++++---------------
drivers/video/fbdev/matrox/matroxfb_base.h | 27 +-----------------
drivers/video/fbdev/neofb.c | 26 +++++-------------
drivers/video/fbdev/nvidia/nv_type.h | 7 +----
drivers/video/fbdev/nvidia/nvidia.c | 37 ++++---------------------
drivers/video/fbdev/pm2fb.c | 31 ++++-----------------
drivers/video/fbdev/pm3fb.c | 30 ++++----------------
drivers/video/fbdev/riva/fbdev.c | 39 +++++---------------------
drivers/video/fbdev/riva/rivafb.h | 4 +--
drivers/video/fbdev/savage/savagefb.h | 4 +--
drivers/video/fbdev/savage/savagefb_driver.c | 17 ++----------
drivers/video/fbdev/sis/sis.h | 2 +-
drivers/video/fbdev/sis/sis_main.c | 27 ++++--------------
drivers/video/fbdev/tdfxfb.c | 41 ++++------------------------
include/video/neomagic.h | 5 +---
include/video/tdfx.h | 2 +-
27 files changed, 106 insertions(+), 405 deletions(-)
^ permalink raw reply
* [PATCH REPOST] staging: xgifb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez @ 2015-05-28 19:39 UTC (permalink / raw)
To: gregkh
Cc: devel, linux-kernel, Luis R. Rodriguez, Arnaud Patard,
Aaro Koskinen, Brian Vandre, Thomas Gummerer, Aya Mahfouz,
Lubomir Rintel, Vitor Braga, Sudip Mukherjee, Suresh Siddha,
Ingo Molnar, Thomas Gleixner, Juergen Gross, Daniel Vetter,
Andy Lutomirski, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
From: "Luis R. Rodriguez" <mcgrof@suse.com>
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help bury MTRR code away, MTRR is architecture specific and on
x86 its replaced by PAT
c) Help with the goal of eventually using _PAGE_CACHE_UC over
_PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
de33c442e titled "x86 PAT: fix performance drop for glx,
use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")
The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.
@ mtrr_found @
expression index, base, size;
@@
-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);
@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@
-mtrr_del(index, base, size);
+arch_phys_wc_del(index);
@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@
-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);
@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@
-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);
@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);
@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@
-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);
Generated-by: Coccinelle SmPL
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Brian Vandre <bvandre@gmail.com>
Cc: Thomas Gummerer <t.gummerer@gmail.com>
Cc: Aya Mahfouz <mahfouz.saif.elyazal@gmail.com>
Cc: Lubomir Rintel <lkundrak@v3.sk>
Cc: Vitor Braga <vitorpybraga@gmail.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devel@driverdev.osuosl.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
Greg, this is a respost from my March 20th submission which seems
to have fallen through the cracks likely due to me not directing it
to you. Apologies for that. This repost goes unchanged and is rebased
on top of linux-next next-20150528.
drivers/staging/xgifb/XGI_main_26.c | 27 ++++++---------------------
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/xgifb/XGI_main_26.c b/drivers/staging/xgifb/XGI_main_26.c
index 74e8820..943d463 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -8,10 +8,7 @@
#include <linux/sizes.h>
#include <linux/module.h>
-
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
+#include <linux/pci.h>
#include "XGI_main.h"
#include "vb_init.h"
@@ -1770,7 +1767,7 @@ static int xgifb_probe(struct pci_dev *pdev,
}
xgifb_info->video_vbase = hw_info->pjVideoMemoryAddress - ioremap(xgifb_info->video_base, xgifb_info->video_size);
+ ioremap_wc(xgifb_info->video_base, xgifb_info->video_size);
xgifb_info->mmio_vbase = ioremap(xgifb_info->mmio_base,
xgifb_info->mmio_size);
@@ -2014,12 +2011,8 @@ static int xgifb_probe(struct pci_dev *pdev,
fb_alloc_cmap(&fb_info->cmap, 256, 0);
-#ifdef CONFIG_MTRR
- xgifb_info->mtrr = mtrr_add(xgifb_info->video_base,
- xgifb_info->video_size, MTRR_TYPE_WRCOMB, 1);
- if (xgifb_info->mtrr >= 0)
- dev_info(&pdev->dev, "Added MTRR\n");
-#endif
+ xgifb_info->mtrr = arch_phys_wc_add(xgifb_info->video_base,
+ xgifb_info->video_size);
if (register_framebuffer(fb_info) < 0) {
ret = -EINVAL;
@@ -2031,11 +2024,7 @@ static int xgifb_probe(struct pci_dev *pdev,
return 0;
error_mtrr:
-#ifdef CONFIG_MTRR
- if (xgifb_info->mtrr >= 0)
- mtrr_del(xgifb_info->mtrr, xgifb_info->video_base,
- xgifb_info->video_size);
-#endif /* CONFIG_MTRR */
+ arch_phys_wc_del(xgifb_info->mtrr);
error_1:
iounmap(xgifb_info->mmio_vbase);
iounmap(xgifb_info->video_vbase);
@@ -2059,11 +2048,7 @@ static void xgifb_remove(struct pci_dev *pdev)
struct fb_info *fb_info = xgifb_info->fb_info;
unregister_framebuffer(fb_info);
-#ifdef CONFIG_MTRR
- if (xgifb_info->mtrr >= 0)
- mtrr_del(xgifb_info->mtrr, xgifb_info->video_base,
- xgifb_info->video_size);
-#endif /* CONFIG_MTRR */
+ arch_phys_wc_del(xgifb_info->mtrr);
iounmap(xgifb_info->mmio_vbase);
iounmap(xgifb_info->video_vbase);
release_mem_region(xgifb_info->mmio_base, xgifb_info->mmio_size);
--
2.3.2.209.gd67f9d5.dirty
^ permalink raw reply related
* [PATCH] fbdev: omap2: improve usage of gpiod API
From: Uwe Kleine-König @ 2015-05-28 8:05 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard
Cc: linux-omap, linux-fbdev, Linus Walleij, kernel
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Also make use of gpiod_get*_optional where applicable.
Apart from simplification of the affected drivers this is another step
towards making the flags argument to gpiod_get*() mandatory.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/video/fbdev/omap2/displays-new/encoder-opa362.c | 12 +++---------
drivers/video/fbdev/omap2/displays-new/panel-dpi.c | 13 +++----------
.../fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c | 7 +++----
.../fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c | 9 ++-------
4 files changed, 11 insertions(+), 30 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c b/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
index 84a6b3367124..a14d993f719d 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-opa362.c
@@ -201,15 +201,9 @@ static int opa362_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
- gpio = devm_gpiod_get(&pdev->dev, "enable");
- if (IS_ERR(gpio)) {
- if (PTR_ERR(gpio) != -ENOENT)
- return PTR_ERR(gpio);
-
- gpio = NULL;
- } else {
- gpiod_direction_output(gpio, 0);
- }
+ gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
ddata->enable_gpio = gpio;
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index eb8fd8140ad0..f7be3489f744 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -209,16 +209,9 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
struct videomode vm;
struct gpio_desc *gpio;
- gpio = devm_gpiod_get(&pdev->dev, "enable");
-
- if (IS_ERR(gpio)) {
- if (PTR_ERR(gpio) != -ENOENT)
- return PTR_ERR(gpio);
- else
- gpio = NULL;
- } else {
- gpiod_direction_output(gpio, 0);
- }
+ gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
ddata->enable_gpio = gpio;
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
index 9974a37a11af..6a1b6a89a928 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
@@ -285,15 +285,14 @@ static int lb035q02_probe_of(struct spi_device *spi)
struct omap_dss_device *in;
struct gpio_desc *gpio;
- gpio = devm_gpiod_get(&spi->dev, "enable");
+ gpio = devm_gpiod_get(&spi->dev, "enable", GPIOD_OUT_LOW);
if (IS_ERR(gpio)) {
dev_err(&spi->dev, "failed to parse enable gpio\n");
return PTR_ERR(gpio);
- } else {
- gpiod_direction_output(gpio, 0);
- ddata->enable_gpio = gpio;
}
+ ddata->enable_gpio = gpio;
+
ddata->backlight_gpio = -ENOENT;
in = omapdss_of_find_source_for_first_ep(node);
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index eae263702964..abfd1f6e3327 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -268,17 +268,12 @@ static int sharp_ls_get_gpio_of(struct device *dev, int index, int val,
const char *desc, struct gpio_desc **gpiod)
{
struct gpio_desc *gd;
- int r;
*gpiod = NULL;
- gd = devm_gpiod_get_index(dev, desc, index);
+ gd = devm_gpiod_get_index(dev, desc, index, GPIOD_OUT_LOW);
if (IS_ERR(gd))
- return PTR_ERR(gd) = -ENOENT ? 0 : PTR_ERR(gd);
-
- r = gpiod_direction_output(gd, val);
- if (r)
- return r;
+ return PTR_ERR(gd);
*gpiod = gd;
return 0;
--
2.1.4
^ permalink raw reply related
* Re: distorted text
From: Geert Uytterhoeven @ 2015-05-28 7:35 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <555C660B.2080808@xsilon.com>
On Wed, May 20, 2015 at 6:03 PM, Simon Vincent <simon.vincent@xsilon.com> wrote:
> I have done some testing and the display works correctly with clear text on
> Linux v4.0 but is distorted/corrupted on v4.1-rc1. (These are tagged
> releases from https://github.com/torvalds/linux).
>
> I have had a look at the changes but I can't find anything that might cause
> the problem although I don't know much about this part of Linux.
> Any ideas?
Can you please try to bisect the problem?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] fixing code style in sm750_accel.c
From: Dan Carpenter @ 2015-05-28 7:23 UTC (permalink / raw)
To: Mario Bambagini
Cc: sudipm.mukherjee, devel, linux-fbdev, teddy.wang, gregkh,
linux-kernel
In-Reply-To: <1432762183-8411-1-git-send-email-mario.bambagini@gmail.com>
You didn't try to compile this.
regards,
dan carpenter
^ permalink raw reply
* Re: distorted text
From: Simon Vincent @ 2015-05-28 7:06 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <555C660B.2080808@xsilon.com>
Has anyone else seen this problem?
Regards
Simon
On 20/05/15 17:03, Simon Vincent wrote:
> Sorry slightly incorrect I upgraded to linux v4.1-rc4.
>
> I have done some testing and the display works correctly with clear
> text on Linux v4.0 but is distorted/corrupted on v4.1-rc1. (These are
> tagged releases from https://github.com/torvalds/linux).
>
> I have had a look at the changes but I can't find anything that might
> cause the problem although I don't know much about this part of Linux.
> Any ideas?
>
> Simon
>
> On 20/05/15 11:46, Simon Vincent wrote:
>> Hi,
>>
>> I have previously been using Linux 3.16 with a OLED 128x32 display
>> setup as a fbconsole. This was working well until I upgraded to linux
>> 4.0. Now the console text is displayed on the OLED but the text is no
>> longer clear, it looks distorted.
>> I have uploaded a photo of the problem here.
>> http://s3.postimg.org/66a7lrp2b/IMG_20150520_114135_2.jpg
>>
>> Is this a known bug?
>>
>> Simon
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-fbdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/21] On-demand device registration
From: Rob Herring @ 2015-05-28 4:33 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: linux-arm-kernel@lists.infradead.org, Stéphane Marchesin,
Thierry Reding, Dmitry Torokhov, Alexander Holler, Grant Likely,
Rob Herring, Mark Rutland, Dan Williams,
devicetree@vger.kernel.org, dmaengine, dri-devel, linux-clk,
linux-fbdev@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com>
On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
<tomeu.vizoso@collabora.com> wrote:
> Hello,
>
> I have a problem with the panel on my Tegra Chromebook taking longer than
> expected to be ready during boot (Stéphane Marchesin reported what is
> basically the same issue in [0]), and have looked into ordered probing as a
> better way of solving this than moving nodes around in the DT or playing with
> initcall levels.
>
> While reading the thread [1] that Alexander Holler started with his series to
> make probing order deterministic, it occurred to me that it should be possible
> to achieve the same by registering devices as they are referenced by other
> devices.
I like the concept and novel approach.
> This basically reuses the information that is already implicit in the probe()
> implementations, saving us from refactoring existing drivers or adding
> information to DTBs.
>
> Something I'm not completely happy with is that I have had to move the call to
> of_platform_populate after all platform drivers have been registered.
> Otherwise I don't see how I could register drivers on demand as we don't have
> yet each driver's compatible strings.
Yeah, this is the opposite of what we'd really like. Ideally, we would
have a solution that works for modules too. However, we're no worse
off. We pretty much build-in dependencies to avoid module ordering
problems.
Perhaps we need to make the probing on-demand rather than simply on
device<->driver match occurring.
> For machs that don't move of_platform_populate() to a later point, these
> patches shouldn't cause any problems but it's not guaranteed that we'll avoid
> all the deferred probes as some drivers may not be registered yet.
Ideally, of_platform_populate is not explicitly called by each
platform. So I think we need to make this work for the default case.
> I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
> patches were enough to eliminate all the deferred probes.
>
> With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s.
That's certainly compelling.
Rob
>
> Regards,
>
> Tomeu
>
> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html
>
> [1] https://lkml.org/lkml/2014/5/12/452
>
> Tomeu Vizoso (21):
> regulator: core: Reduce critical area in _regulator_get
> ARM: tegra: Add gpio-ranges property
> ARM: tegra: Register drivers before devices
> ARM: EXYNOS: Register drivers before devices
> ARM i.MX6q: Register drivers before devices
> of/platform: Add of_platform_device_ensure()
> of/platform: Ensure device registration on lookup
> gpio: Probe GPIO drivers on demand
> gpio: Probe pinctrl devices on demand
> regulator: core: Probe regulators on demand
> drm: Probe panels on demand
> drm/tegra: Probe dpaux devices on demand
> i2c: core: Probe i2c master devices on demand
> pwm: Probe PWM chip devices on demand
> backlight: Probe backlight devices on demand
> usb: phy: Probe phy devices on demand
> clk: Probe clk providers on demand
> pinctrl: Probe pinctrl devices on demand
> phy: core: Probe phy providers on demand
> dma: of: Probe DMA controllers on demand
> power-supply: Probe power supplies on demand
>
> arch/arm/boot/dts/tegra124.dtsi | 1 +
> arch/arm/mach-exynos/exynos.c | 4 +--
> arch/arm/mach-imx/mach-imx6q.c | 12 ++++-----
> arch/arm/mach-tegra/tegra.c | 21 ++++++---------
> drivers/clk/clk.c | 3 +++
> drivers/dma/of-dma.c | 3 +++
> drivers/gpio/gpiolib-of.c | 5 ++++
> drivers/gpu/drm/drm_panel.c | 3 +++
> drivers/gpu/drm/tegra/dpaux.c | 3 +++
> drivers/i2c/i2c-core.c | 3 +++
> drivers/of/platform.c | 53 +++++++++++++++++++++++++++++++++++++
> drivers/phy/phy-core.c | 3 +++
> drivers/pinctrl/devicetree.c | 2 ++
> drivers/power/power_supply_core.c | 3 +++
> drivers/pwm/core.c | 3 +++
> drivers/regulator/core.c | 45 +++++++++++++++----------------
> drivers/usb/phy/phy.c | 3 +++
> drivers/video/backlight/backlight.c | 3 +++
> include/linux/of_platform.h | 2 ++
> 19 files changed, 130 insertions(+), 45 deletions(-)
>
> --
> 2.4.1
>
^ permalink raw reply
* Re: [PATCH] fixing code style in sm750_accel.c
From: Greg KH @ 2015-05-27 22:03 UTC (permalink / raw)
To: Mario Bambagini
Cc: sudipm.mukherjee, teddy.wang, linux-fbdev, devel, linux-kernel
In-Reply-To: <1432762183-8411-1-git-send-email-mario.bambagini@gmail.com>
On Wed, May 27, 2015 at 11:29:43PM +0200, Mario Bambagini wrote:
> From: mbambagini <mario.bambagini@gmail.com>
That doesn't match up with the name you used above, or in the
signed-off-by line.
>
> Signed-off-by: Mario Bambagini <mario.bambagini@gmail.com>
> ---
You are going to have to be really specific as to exactly what you
changed and why you changed it, in the body of the patch. And remember,
you can only do one-thing-per-patch, and that doesn't mean "fix all the
issues!" is one thing.
please fix up and resend.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] fixing code style in sm750_accel.c
From: Mario Bambagini @ 2015-05-27 21:29 UTC (permalink / raw)
To: sudipm.mukherjee
Cc: teddy.wang, gregkh, linux-fbdev, devel, linux-kernel,
mario.bambagini
From: mbambagini <mario.bambagini@gmail.com>
Signed-off-by: Mario Bambagini <mario.bambagini@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.c | 695 +++++++++++++++++-----------------
1 file changed, 354 insertions(+), 341 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 6a04ef8..6c38b40 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -1,437 +1,450 @@
-#include<linux/module.h>
-#include<linux/kernel.h>
-#include<linux/errno.h>
-#include<linux/string.h>
-#include<linux/mm.h>
-#include<linux/slab.h>
-#include<linux/delay.h>
-#include<linux/fb.h>
-#include<linux/ioport.h>
-#include<linux/init.h>
-#include<linux/pci.h>
-#include<linux/vmalloc.h>
-#include<linux/pagemap.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/fb.h>
+#include <linux/ioport.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/vmalloc.h>
+#include <linux/pagemap.h>
#include <linux/console.h>
-#include<linux/platform_device.h>
-#include<linux/screen_info.h>
+#include <linux/platform_device.h>
+#include <linux/screen_info.h>
#include "sm750.h"
#include "sm750_accel.h"
#include "sm750_help.h"
-static inline void write_dpr(struct lynx_accel * accel,int offset,u32 regValue)
+
+static inline void write_dpr(struct lynx_accel *accel, int offset, u32 regValue)
{
- writel(regValue,accel->dprBase + offset);
+ writel(regValue, accel->dprBase + offset);
}
-static inline u32 read_dpr(struct lynx_accel * accel,int offset)
+static inline u32 read_dpr(struct lynx_accel *accel, int offset)
{
return readl(accel->dprBase + offset);
}
-static inline void write_dpPort(struct lynx_accel * accel,u32 data)
+static inline void write_dpPort(struct lynx_accel *accel, u32 data)
{
- writel(data,accel->dpPortBase);
+ writel(data, accel->dpPortBase);
}
-void hw_de_init(struct lynx_accel * accel)
+void hw_de_init(struct lynx_accel *accel)
{
/* setup 2d engine registers */
- u32 reg,clr;
-
- write_dpr(accel,DE_MASKS,0xFFFFFFFF);
+ u32 reg, clr;
+
+ write_dpr(accel, DE_MASKS, 0xFFFFFFFF);
/* dpr1c */
- reg = FIELD_SET(0,DE_STRETCH_FORMAT,PATTERN_XY,NORMAL)|
- FIELD_VALUE(0,DE_STRETCH_FORMAT,PATTERN_Y,0)|
- FIELD_VALUE(0,DE_STRETCH_FORMAT,PATTERN_X,0)|
- FIELD_SET(0,DE_STRETCH_FORMAT,ADDRESSING,XY)|
- FIELD_VALUE(0,DE_STRETCH_FORMAT,SOURCE_HEIGHT,3);
-
- clr = FIELD_CLEAR(DE_STRETCH_FORMAT,PATTERN_XY)&
- FIELD_CLEAR(DE_STRETCH_FORMAT,PATTERN_Y)&
- FIELD_CLEAR(DE_STRETCH_FORMAT,PATTERN_X)&
- FIELD_CLEAR(DE_STRETCH_FORMAT,ADDRESSING)&
- FIELD_CLEAR(DE_STRETCH_FORMAT,SOURCE_HEIGHT);
+ reg = FIELD_SET(0, DE_STRETCH_FORMAT, PATTERN_XY, NORMAL)|
+ FIELD_VALUE(0, DE_STRETCH_FORMAT, PATTERN_Y, 0)|
+ FIELD_VALUE(0, DE_STRETCH_FORMAT, PATTERN_X, 0)|
+ FIELD_SET(0, DE_STRETCH_FORMAT, ADDRESSING, XY)|
+ FIELD_VALUE(0, DE_STRETCH_FORMAT, SOURCE_HEIGHT, 3);
+
+ clr = FIELD_CLEAR(DE_STRETCH_FORMAT, PATTERN_XY)&
+ FIELD_CLEAR(DE_STRETCH_FORMAT, PATTERN_Y)&
+ FIELD_CLEAR(DE_STRETCH_FORMAT, PATTERN_X)&
+ FIELD_CLEAR(DE_STRETCH_FORMAT, ADDRESSING)&
+ FIELD_CLEAR(DE_STRETCH_FORMAT, SOURCE_HEIGHT);
/* DE_STRETCH bpp format need be initilized in setMode routine */
- write_dpr(accel,DE_STRETCH_FORMAT,(read_dpr(accel,DE_STRETCH_FORMAT) & clr) | reg);
+ write_dpr(accel, DE_STRETCH_FORMAT,
+ (read_dpr(accel, DE_STRETCH_FORMAT) & clr) | reg);
/* disable clipping and transparent */
- write_dpr(accel,DE_CLIP_TL,0);//dpr2c
- write_dpr(accel,DE_CLIP_BR,0);//dpr30
+ write_dpr(accel, DE_CLIP_TL, 0);/* dpr2c */
+ write_dpr(accel, DE_CLIP_BR, 0);/* dpr30 */
- write_dpr(accel,DE_COLOR_COMPARE_MASK,0);//dpr24
- write_dpr(accel,DE_COLOR_COMPARE,0);
+ write_dpr(accel, DE_COLOR_COMPARE_MASK, 0);/* dpr24 */
+ write_dpr(accel, DE_COLOR_COMPARE, 0);
- reg = FIELD_SET(0,DE_CONTROL,TRANSPARENCY,DISABLE)|
- FIELD_SET(0,DE_CONTROL,TRANSPARENCY_MATCH,OPAQUE)|
- FIELD_SET(0,DE_CONTROL,TRANSPARENCY_SELECT,SOURCE);
+ reg = FIELD_SET(0, DE_CONTROL, TRANSPARENCY, DISABLE)|
+ FIELD_SET(0, DE_CONTROL, TRANSPARENCY_MATCH, OPAQUE)|
+ FIELD_SET(0, DE_CONTROL, TRANSPARENCY_SELECT, SOURCE);
- clr = FIELD_CLEAR(DE_CONTROL,TRANSPARENCY)&
- FIELD_CLEAR(DE_CONTROL,TRANSPARENCY_MATCH)&
- FIELD_CLEAR(DE_CONTROL,TRANSPARENCY_SELECT);
+ clr = FIELD_CLEAR(DE_CONTROL, TRANSPARENCY) &
+ FIELD_CLEAR(DE_CONTROL, TRANSPARENCY_MATCH) &
+ FIELD_CLEAR(DE_CONTROL, TRANSPARENCY_SELECT);
/* dpr0c */
- write_dpr(accel,DE_CONTROL,(read_dpr(accel,DE_CONTROL)&clr)|reg);
+ write_dpr(accel, DE_CONTROL, (read_dpr(accel, DE_CONTROL) & clr) | reg);
}
/* set2dformat only be called from setmode functions
* but if you need dual framebuffer driver,need call set2dformat
* every time you use 2d function */
-void hw_set2dformat(struct lynx_accel * accel,int fmt)
+void hw_set2dformat(struct lynx_accel *accel, int fmt)
{
u32 reg;
-
+
/* fmt=0,1,2 for 8,16,32,bpp on sm718/750/502 */
- reg = read_dpr(accel,DE_STRETCH_FORMAT);
- reg = FIELD_VALUE(reg,DE_STRETCH_FORMAT,PIXEL_FORMAT,fmt);
- write_dpr(accel,DE_STRETCH_FORMAT,reg);
+ reg = read_dpr(accel, DE_STRETCH_FORMAT);
+ reg = FIELD_VALUE(reg, DE_STRETCH_FORMAT, PIXEL_FORMAT, fmt);
+ write_dpr(accel, DE_STRETCH_FORMAT, reg);
}
-int hw_fillrect(struct lynx_accel * accel,
- u32 base,u32 pitch,u32 Bpp,
- u32 x,u32 y,u32 width,u32 height,
- u32 color,u32 rop)
+int hw_fillrect(struct lynx_accel *accel,
+ u32 base, u32 pitch, u32 Bpp,
+ u32 x, u32 y, u32 width, u32 height,
+ u32 color, u32 rop)
{
u32 deCtrl;
- if(accel->de_wait() != 0)
- {
+ if (accel->de_wait() != 0) {
/* int time wait and always busy,seems hardware
* got something error */
- pr_debug("%s:De engine always bussy\n",__func__);
+ pr_debug("%s:De engine always bussy\n", __func__);
return -1;
}
- write_dpr(accel,DE_WINDOW_DESTINATION_BASE,base);//dpr40
- write_dpr(accel,DE_PITCH,
- FIELD_VALUE(0,DE_PITCH,DESTINATION,pitch/Bpp)|
- FIELD_VALUE(0,DE_PITCH,SOURCE,pitch/Bpp));//dpr10
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
+ write_dpr(accel, DE_PITCH,
+ FIELD_VALUE(0, DE_PITCH, DESTINATION, pitch/Bpp)|
+ FIELD_VALUE(0, DE_PITCH, SOURCE, pitch/Bpp));
+ /* dpr10 */
- write_dpr(accel,DE_WINDOW_WIDTH,
- FIELD_VALUE(0,DE_WINDOW_WIDTH,DESTINATION,pitch/Bpp)|
- FIELD_VALUE(0,DE_WINDOW_WIDTH,SOURCE,pitch/Bpp));//dpr44
+ write_dpr(accel, DE_WINDOW_WIDTH,
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION, pitch/Bpp)|
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, pitch/Bpp));
+ /* dpr44 */
- write_dpr(accel,DE_FOREGROUND,color);//DPR14
+ write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
- write_dpr(accel,DE_DESTINATION,
- FIELD_SET(0,DE_DESTINATION,WRAP,DISABLE)|
- FIELD_VALUE(0,DE_DESTINATION,X,x)|
- FIELD_VALUE(0,DE_DESTINATION,Y,y));//dpr4
+ write_dpr(accel, DE_DESTINATION,
+ FIELD_SET(0, DE_DESTINATION, WRAP, DISABLE)|
+ FIELD_VALUE(0, DE_DESTINATION, X, x)|
+ FIELD_VALUE(0, DE_DESTINATION, Y, y)); /* dpr4 */
- write_dpr(accel,DE_DIMENSION,
- FIELD_VALUE(0,DE_DIMENSION,X,width)|
- FIELD_VALUE(0,DE_DIMENSION,Y_ET,height));//dpr8
+ write_dpr(accel, DE_DIMENSION,
+ FIELD_VALUE(0, DE_DIMENSION, X, width) |
+ FIELD_VALUE(0, DE_DIMENSION, Y_ET, height)); /* dpr8 */
deCtrl - FIELD_SET(0,DE_CONTROL,STATUS,START)|
- FIELD_SET(0,DE_CONTROL,DIRECTION,LEFT_TO_RIGHT)|
- FIELD_SET(0,DE_CONTROL,LAST_PIXEL,ON)|
- FIELD_SET(0,DE_CONTROL,COMMAND,RECTANGLE_FILL)|
- FIELD_SET(0,DE_CONTROL,ROP_SELECT,ROP2)|
- FIELD_VALUE(0,DE_CONTROL,ROP,rop);//dpr0xc
-
- write_dpr(accel,DE_CONTROL,deCtrl);
+ FIELD_SET(0, DE_CONTROL, STATUS, START) |
+ FIELD_SET(0, DE_CONTROL, DIRECTION, LEFT_TO_RIGHT) |
+ FIELD_SET(0, DE_CONTROL, LAST_PIXEL, ON) |
+ FIELD_SET(0, DE_CONTROL, COMMAND, RECTANGLE_FILL) |
+ FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2) |
+ FIELD_VALUE(0, DE_CONTROL, ROP, rop); /* dpr0xc */
+
+ write_dpr(accel, DE_CONTROL, DeCtrl);
+
return 0;
}
-int hw_copyarea(
-struct lynx_accel * accel,
-unsigned int sBase, /* Address of source: offset in frame buffer */
-unsigned int sPitch, /* Pitch value of source surface in BYTE */
-unsigned int sx,
-unsigned int sy, /* Starting coordinate of source surface */
-unsigned int dBase, /* Address of destination: offset in frame buffer */
-unsigned int dPitch, /* Pitch value of destination surface in BYTE */
-unsigned int Bpp, /* Color depth of destination surface */
-unsigned int dx,
-unsigned int dy, /* Starting coordinate of destination surface */
-unsigned int width,
-unsigned int height, /* width and height of rectangle in pixel value */
-unsigned int rop2) /* ROP value */
+int hw_copyarea(struct lynx_accel *accel,
+ unsigned int sBase, /* Address of source: offset in frame buffer */
+ unsigned int sPitch, /* Pitch value of source surface in BYTE */
+ unsigned int sx,
+ unsigned int sy, /* Starting coordinate of source surface */
+ unsigned int dBase, /* Address of destination: offset in frame
+ buffer */
+ unsigned int dPitch, /* Pitch value of destination surface in BYTE */
+ unsigned int Bpp, /* Color depth of destination surface */
+ unsigned int dx,
+ unsigned int dy, /* Starting coordinate of destination surface */
+ unsigned int width,
+ unsigned int height, /* width and height of rectangle in pixel
+ value */
+ unsigned int rop2 /* ROP value */
+)
{
- unsigned int nDirection, de_ctrl;
- int opSign;
- nDirection = LEFT_TO_RIGHT;
- /* Direction of ROP2 operation: 1 = Left to Right, (-1) = Right to Left */
- opSign = 1;
- de_ctrl = 0;
-
- /* If source and destination are the same surface, need to check for overlay cases */
- if (sBase = dBase && sPitch = dPitch)
- {
- /* Determine direction of operation */
- if (sy < dy)
- {
- /* +----------+
- |S |
- | +----------+
- | | | |
- | | | |
- +---|------+ |
- | D|
- +----------+ */
-
- nDirection = BOTTOM_TO_TOP;
- }
- else if (sy > dy)
- {
- /* +----------+
- |D |
- | +----------+
- | | | |
- | | | |
- +---|------+ |
- | S|
- +----------+ */
-
- nDirection = TOP_TO_BOTTOM;
- }
- else
- {
- /* sy = dy */
-
- if (sx <= dx)
- {
- /* +------+---+------+
- |S | | D|
- | | | |
- | | | |
- | | | |
- +------+---+------+ */
-
- nDirection = RIGHT_TO_LEFT;
- }
- else
- {
- /* sx > dx */
-
- /* +------+---+------+
- |D | | S|
- | | | |
- | | | |
- | | | |
- +------+---+------+ */
-
- nDirection = LEFT_TO_RIGHT;
- }
- }
- }
-
- if ((nDirection = BOTTOM_TO_TOP) || (nDirection = RIGHT_TO_LEFT))
- {
- sx += width - 1;
- sy += height - 1;
- dx += width - 1;
- dy += height - 1;
- opSign = (-1);
- }
-
- /* Note:
- DE_FOREGROUND are DE_BACKGROUND are don't care.
- DE_COLOR_COMPARE and DE_COLOR_COMPARE_MAKS are set by set deSetTransparency().
- */
-
- /* 2D Source Base.
- It is an address offset (128 bit aligned) from the beginning of frame buffer.
- */
- write_dpr(accel,DE_WINDOW_SOURCE_BASE, sBase);//dpr40
-
- /* 2D Destination Base.
- It is an address offset (128 bit aligned) from the beginning of frame buffer.
- */
- write_dpr(accel,DE_WINDOW_DESTINATION_BASE, dBase);//dpr44
+ unsigned int nDirection, de_ctrl;
+ int opSign;
+
+ nDirection = LEFT_TO_RIGHT;
+ /* Direction of ROP2 operation: 1 = Left to Right, (-1) = Right to
+ Left */
+ opSign = 1;
+ de_ctrl = 0;
+
+ /* If source and destination are the same surface, need to check for
+ overlay cases */
+ if (sBase = dBase && sPitch = dPitch) {
+ /* Determine direction of operation */
+ if (sy < dy) {
+ /* +----------+
+ |S |
+ | +----------+
+ | | | |
+ | | | |
+ +---|------+ |
+ | D|
+ +----------+ */
+
+ nDirection = BOTTOM_TO_TOP;
+ } else if (sy > dy) {
+ /* +----------+
+ |D |
+ | +----------+
+ | | | |
+ | | | |
+ +---|------+ |
+ | S|
+ +----------+ */
+
+ nDirection = TOP_TO_BOTTOM;
+ } else {
+ /* sy = dy */
+
+ if (sx <= dx) {
+ /* +------+---+------+
+ |S | | D|
+ | | | |
+ | | | |
+ | | | |
+ +------+---+------+ */
+
+ nDirection = RIGHT_TO_LEFT;
+ } else {
+ /* sx > dx */
+
+ /* +------+---+------+
+ |D | | S|
+ | | | |
+ | | | |
+ | | | |
+ +------+---+------+ */
+
+ nDirection = LEFT_TO_RIGHT;
+ }
+ }
+ }
+
+ if ((nDirection = BOTTOM_TO_TOP) || (nDirection = RIGHT_TO_LEFT)) {
+ sx += width - 1;
+ sy += height - 1;
+ dx += width - 1;
+ dy += height - 1;
+ opSign = (-1);
+ }
+
+ /* Note:
+ DE_FOREGROUND are DE_BACKGROUND are don't care.
+ DE_COLOR_COMPARE and DE_COLOR_COMPARE_MAKS are set by set
+ deSetTransparency().
+ */
+
+ /* 2D Source Base.
+ It is an address offset (128 bit aligned) from the beginning of frame
+ buffer. */
+ write_dpr(accel, DE_WINDOW_SOURCE_BASE, sBase); /* dpr40 */
+
+ /* 2D Destination Base.
+ It is an address offset (128 bit aligned) from the beginning of frame
+ buffer. */
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dBase); /* dpr44 */
#if 0
- /* Program pitch (distance between the 1st points of two adjacent lines).
- Note that input pitch is BYTE value, but the 2D Pitch register uses
- pixel values. Need Byte to pixel conversion.
- */
- if(Bpp = 3){
- sx *= 3;
- dx *= 3;
- width *= 3;
- write_dpr(accel,DE_PITCH,
+ /* Program pitch (distance between the 1st points of two adjacent
+ lines).
+ Note that input pitch is BYTE value, but the 2D Pitch register uses
+ pixel values. Need Byte to pixel conversion.
+ */
+ if (Bpp = 3) {
+ sx *= 3;
+ dx *= 3;
+ width *= 3;
+ write_dpr(accel, DE_PITCH,
FIELD_VALUE(0, DE_PITCH, DESTINATION, dPitch) |
- FIELD_VALUE(0, DE_PITCH, SOURCE, sPitch));//dpr10
- }
- else
+ FIELD_VALUE(0, DE_PITCH, SOURCE, sPitch));
+ /* dpr10 */
+ } else
#endif
{
- write_dpr(accel,DE_PITCH,
- FIELD_VALUE(0, DE_PITCH, DESTINATION, (dPitch/Bpp)) |
- FIELD_VALUE(0, DE_PITCH, SOURCE, (sPitch/Bpp)));//dpr10
+ write_dpr(accel, DE_PITCH,
+ FIELD_VALUE(0, DE_PITCH, DESTINATION,
+ (dPitch/Bpp)) |
+ FIELD_VALUE(0, DE_PITCH, SOURCE, (sPitch/Bpp)));
+ /* dpr10 */
}
- /* Screen Window width in Pixels.
- 2D engine uses this value to calculate the linear address in frame buffer for a given point.
- */
- write_dpr(accel,DE_WINDOW_WIDTH,
- FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION, (dPitch/Bpp)) |
- FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, (sPitch/Bpp)));//dpr3c
+ /* Screen Window width in Pixels.
+ 2D engine uses this value to calculate the linear address in frame
+ buffer for a given point. */
+ write_dpr(accel, DE_WINDOW_WIDTH,
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION, (dPitch/Bpp)) |
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE,
+ (sPitch/Bpp))); /* dpr3c */
- if (accel->de_wait() != 0){
+ if (accel->de_wait() != 0)
return -1;
+
+ {
+ write_dpr(accel, DE_SOURCE,
+ FIELD_SET(0, DE_SOURCE, WRAP, DISABLE) |
+ FIELD_VALUE(0, DE_SOURCE, X_K1, sx) |
+ FIELD_VALUE(0, DE_SOURCE, Y_K2, sy)); /* dpr0 */
+ write_dpr(accel, DE_DESTINATION,
+ FIELD_SET(0, DE_DESTINATION, WRAP, DISABLE) |
+ FIELD_VALUE(0, DE_DESTINATION, X, dx) |
+ FIELD_VALUE(0, DE_DESTINATION, Y, dy)); /* dpr04 */
+ write_dpr(accel, DE_DIMENSION,
+ FIELD_VALUE(0, DE_DIMENSION, X, width) |
+ FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));/* dpr08 */
+
+ de_ctrl + FIELD_VALUE(0, DE_CONTROL, ROP, rop2) |
+ FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2) |
+ FIELD_SET(0, DE_CONTROL, COMMAND, BITBLT) |
+ ((nDirection = RIGHT_TO_LEFT) ?
+ FIELD_SET(0, DE_CONTROL, DIRECTION, RIGHT_TO_LEFT)
+ : FIELD_SET(0, DE_CONTROL, DIRECTION, LEFT_TO_RIGHT)) |
+ FIELD_SET(0, DE_CONTROL, STATUS, START);
+ write_dpr(accel, DE_CONTROL, De_ctrl);/* dpr0c */
}
- {
-
- write_dpr(accel,DE_SOURCE,
- FIELD_SET (0, DE_SOURCE, WRAP, DISABLE) |
- FIELD_VALUE(0, DE_SOURCE, X_K1, sx) |
- FIELD_VALUE(0, DE_SOURCE, Y_K2, sy));//dpr0
- write_dpr(accel,DE_DESTINATION,
- FIELD_SET (0, DE_DESTINATION, WRAP, DISABLE) |
- FIELD_VALUE(0, DE_DESTINATION, X, dx) |
- FIELD_VALUE(0, DE_DESTINATION, Y, dy));//dpr04
- write_dpr(accel,DE_DIMENSION,
- FIELD_VALUE(0, DE_DIMENSION, X, width) |
- FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));//dpr08
-
- de_ctrl - FIELD_VALUE(0, DE_CONTROL, ROP, rop2) |
- FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2) |
- FIELD_SET(0, DE_CONTROL, COMMAND, BITBLT) |
- ((nDirection = RIGHT_TO_LEFT) ?
- FIELD_SET(0, DE_CONTROL, DIRECTION, RIGHT_TO_LEFT)
- : FIELD_SET(0, DE_CONTROL, DIRECTION, LEFT_TO_RIGHT)) |
- FIELD_SET(0, DE_CONTROL, STATUS, START);
- write_dpr(accel,DE_CONTROL,de_ctrl);//dpr0c
- }
-
- return 0;
+ return 0;
}
-static unsigned int deGetTransparency(struct lynx_accel * accel)
+static unsigned int deGetTransparency(struct lynx_accel *accel)
{
- unsigned int de_ctrl;
+ unsigned int de_ctrl;
- de_ctrl = read_dpr(accel,DE_CONTROL);
+ de_ctrl = read_dpr(accel, DE_CONTROL);
- de_ctrl &- FIELD_MASK(DE_CONTROL_TRANSPARENCY_MATCH) |
- FIELD_MASK(DE_CONTROL_TRANSPARENCY_SELECT)|
- FIELD_MASK(DE_CONTROL_TRANSPARENCY);
+ de_ctrl &+ FIELD_MASK(DE_CONTROL_TRANSPARENCY_MATCH) |
+ FIELD_MASK(DE_CONTROL_TRANSPARENCY_SELECT)|
+ FIELD_MASK(DE_CONTROL_TRANSPARENCY);
- return de_ctrl;
+ return de_ctrl;
}
int hw_imageblit(struct lynx_accel *accel,
- const char *pSrcbuf, /* pointer to start of source buffer in system memory */
- u32 srcDelta, /* Pitch value (in bytes) of the source buffer, +ive means top down and -ive mean button up */
- u32 startBit, /* Mono data can start at any bit in a byte, this value should be 0 to 7 */
- u32 dBase, /* Address of destination: offset in frame buffer */
- u32 dPitch, /* Pitch value of destination surface in BYTE */
- u32 bytePerPixel, /* Color depth of destination surface */
- u32 dx,
- u32 dy, /* Starting coordinate of destination surface */
- u32 width,
- u32 height, /* width and height of rectange in pixel value */
- u32 fColor, /* Foreground color (corresponding to a 1 in the monochrome data */
- u32 bColor, /* Background color (corresponding to a 0 in the monochrome data */
- u32 rop2) /* ROP value */
+ const char *pSrcbuf, /* pointer to start of source buffer in system
+ memory */
+ u32 srcDelta, /* Pitch value (in bytes) of the source buffer,
+ +ive means top down and -ive mean button up */
+ u32 startBit, /* Mono data can start at any bit in a byte, this
+ value should be 0 to 7 */
+ u32 dBase, /* Address of destination: offset in frame
+ buffer */
+ u32 dPitch, /* Pitch value of destination surface in BYTE */
+ u32 bytePerPixel, /* Color depth of destination surface */
+ u32 dx,
+ u32 dy, /* Starting coordinate of destination surface */
+ u32 width,
+ u32 height, /* width and height of rectange in pixel value */
+ u32 fColor, /* Foreground color (corresponding to a 1 in the
+ monochrome data */
+ u32 bColor, /* Background color (corresponding to a 0 in the
+ monochrome data */
+ u32 rop2 /* ROP value */
+)
{
- unsigned int ulBytesPerScan;
- unsigned int ul4BytesPerScan;
- unsigned int ulBytesRemain;
- unsigned int de_ctrl = 0;
- unsigned char ajRemain[4];
- int i, j;
-
- startBit &= 7; /* Just make sure the start bit is within legal range */
- ulBytesPerScan = (width + startBit + 7) / 8;
- ul4BytesPerScan = ulBytesPerScan & ~3;
- ulBytesRemain = ulBytesPerScan & 3;
-
- if(accel->de_wait() != 0)
- {
-// inf_msg("*** ImageBlit return -1 ***\n");
- return -1;
- }
-
- /* 2D Source Base.
- Use 0 for HOST Blt.
- */
- write_dpr(accel,DE_WINDOW_SOURCE_BASE, 0);
-
- /* 2D Destination Base.
- It is an address offset (128 bit aligned) from the beginning of frame buffer.
- */
- write_dpr(accel,DE_WINDOW_DESTINATION_BASE, dBase);
+ unsigned int ulBytesPerScan;
+ unsigned int ul4BytesPerScan;
+ unsigned int ulBytesRemain;
+ unsigned int de_ctrl = 0;
+ unsigned char ajRemain[4];
+ int i, j;
+
+ startBit &= 7; /* Just make sure the start bit is within legal range */
+ ulBytesPerScan = (width + startBit + 7) / 8;
+ ul4BytesPerScan = ulBytesPerScan & ~3;
+ ulBytesRemain = ulBytesPerScan & 3;
+
+ if (accel->de_wait() != 0) {
+ /* inf_msg("*** ImageBlit return -1 ***\n"); */
+ return -1;
+ }
+
+ /* 2D Source Base.
+ Use 0 for HOST Blt.
+ */
+ write_dpr(accel, DE_WINDOW_SOURCE_BASE, 0);
+
+ /* 2D Destination Base.
+ It is an address offset (128 bit aligned) from the beginning of
+ frame buffer.
+ */
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dBase);
#if 0
- /* Program pitch (distance between the 1st points of two adjacent lines).
- Note that input pitch is BYTE value, but the 2D Pitch register uses
- pixel values. Need Byte to pixel conversion.
- */
- if(bytePerPixel = 3 ){
+ /* Program pitch (distance between the 1st points of two adjacent
+ lines).
+ Note that input pitch is BYTE value, but the 2D Pitch register
+ uses pixel values. Need Byte to pixel conversion.
+ */
+ if (bytePerPixel = 3) {
dx *= 3;
width *= 3;
startBit *= 3;
- write_dpr(accel,DE_PITCH,
+ write_dpr(accel, DE_PITCH,
FIELD_VALUE(0, DE_PITCH, DESTINATION, dPitch) |
- FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch));//dpr10
+ FIELD_VALUE(0, DE_PITCH, SOURCE,
+ dPitch)); /* dpr10 */
- }
- else
+ } else
#endif
{
- write_dpr(accel,DE_PITCH,
- FIELD_VALUE(0, DE_PITCH, DESTINATION, dPitch/bytePerPixel) |
- FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch/bytePerPixel));//dpr10
+ write_dpr(accel, DE_PITCH, FIELD_VALUE(0, DE_PITCH,
+ DESTINATION, dPitch/bytePerPixel) |
+ FIELD_VALUE(0, DE_PITCH, SOURCE,
+ dPitch/bytePerPixel)); /* dpr10 */
}
- /* Screen Window width in Pixels.
- 2D engine uses this value to calculate the linear address in frame buffer for a given point.
- */
- write_dpr(accel,DE_WINDOW_WIDTH,
- FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION, (dPitch/bytePerPixel)) |
- FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, (dPitch/bytePerPixel)));
-
- /* Note: For 2D Source in Host Write, only X_K1_MONO field is needed, and Y_K2 field is not used.
- For mono bitmap, use startBit for X_K1. */
- write_dpr(accel,DE_SOURCE,
- FIELD_SET (0, DE_SOURCE, WRAP, DISABLE) |
- FIELD_VALUE(0, DE_SOURCE, X_K1_MONO, startBit));//dpr00
-
- write_dpr(accel,DE_DESTINATION,
- FIELD_SET (0, DE_DESTINATION, WRAP, DISABLE) |
- FIELD_VALUE(0, DE_DESTINATION, X, dx) |
- FIELD_VALUE(0, DE_DESTINATION, Y, dy));//dpr04
-
- write_dpr(accel,DE_DIMENSION,
- FIELD_VALUE(0, DE_DIMENSION, X, width) |
- FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));//dpr08
-
- write_dpr(accel,DE_FOREGROUND, fColor);
- write_dpr(accel,DE_BACKGROUND, bColor);
-
- de_ctrl = FIELD_VALUE(0, DE_CONTROL, ROP, rop2) |
- FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2) |
+ /* Screen Window width in Pixels.
+ 2D engine uses this value to calculate the linear address in
+ frame buffer for a given point.
+ */
+ write_dpr(accel, DE_WINDOW_WIDTH,
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION,
+ (dPitch/bytePerPixel)) |
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, (dPitch/bytePerPixel)));
+
+ /* Note: For 2D Source in Host Write, only X_K1_MONO field is needed,
+ and Y_K2 field is not used.
+ For mono bitmap, use startBit for X_K1.
+ */
+ write_dpr(accel, DE_SOURCE,
+ FIELD_SET(0, DE_SOURCE, WRAP, DISABLE) |
+ FIELD_VALUE(0, DE_SOURCE, X_K1_MONO, startBit));/* dpr00 */
+
+ write_dpr(accel, DE_DESTINATION,
+ FIELD_SET(0, DE_DESTINATION, WRAP, DISABLE) |
+ FIELD_VALUE(0, DE_DESTINATION, X, dx) |
+ FIELD_VALUE(0, DE_DESTINATION, Y, dy));/* dpr04 */
+
+ write_dpr(accel, DE_DIMENSION,
+ FIELD_VALUE(0, DE_DIMENSION, X, width) |
+ FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));/* dpr08 */
+
+ write_dpr(accel, DE_FOREGROUND, fColor);
+ write_dpr(accel, DE_BACKGROUND, bColor);
+
+ de_ctrl = FIELD_VALUE(0, DE_CONTROL, ROP, rop2) |
+ FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2) |
FIELD_SET(0, DE_CONTROL, COMMAND, HOST_WRITE) |
- FIELD_SET(0, DE_CONTROL, HOST, MONO) |
+ FIELD_SET(0, DE_CONTROL, HOST, MONO) |
FIELD_SET(0, DE_CONTROL, STATUS, START);
- write_dpr(accel,DE_CONTROL, de_ctrl | deGetTransparency(accel));
+ write_dpr(accel, DE_CONTROL, de_ctrl | deGetTransparency(accel));
- /* Write MONO data (line by line) to 2D Engine data port */
- for (i=0; i<height; i++)
- {
- /* For each line, send the data in chunks of 4 bytes */
- for (j=0; j<(ul4BytesPerScan/4); j++)
- {
- write_dpPort(accel, *(unsigned int *)(pSrcbuf + (j * 4)));
- }
+ /* Write MONO data (line by line) to 2D Engine data port */
+ for (i = 0; i < height; i++) {
+ /* For each line, send the data in chunks of 4 bytes */
+ for (j = 0; j < (ul4BytesPerScan/4); j++) {
+ write_dpPort(accel,
+ *(unsigned int *)(pSrcbuf + (j * 4)));
+ }
- if (ulBytesRemain)
- {
- memcpy(ajRemain, pSrcbuf+ul4BytesPerScan, ulBytesRemain);
- write_dpPort(accel, *(unsigned int *)ajRemain);
- }
+ if (ulBytesRemain) {
+ memcpy(ajRemain, pSrcbuf+ul4BytesPerScan,
+ ulBytesRemain);
+ write_dpPort(accel, *(unsigned int *)ajRemain);
+ }
- pSrcbuf += srcDelta;
- }
+ pSrcbuf += srcDelta;
+ }
- return 0;
+ return 0;
}
-
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v6 1/4] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-05-27 20:04 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Luis R. Rodriguez, tomi.valkeinen, airlied, linux-fbdev, luto,
linux-kernel, linux-pci, xen-devel, Toshi Kani, Suresh Siddha,
Ingo Molnar, Thomas Gleixner, Juergen Gross, Daniel Vetter,
Dave Airlie, Antonino Daplas, Jean-Christophe Plagniol-Villard,
Dave Hansen, Arnd Bergmann, Michael S. Tsirkin,
venkatesh.pallipadi, Stefan Bader, Ville Syrjälä,
Mel Gorman, Vlastimil Babka, Borislav Petkov, Davidlohr Bueso,
konrad.wilk, ville.syrjala, david.vrabel, jbeulich,
Roger Pau Monné
In-Reply-To: <20150526174008.GN32152@google.com>
On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
> > On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
> > >
> > > I tentatively put this (and the rest of the series) on a pci/resource
> > > branch. I'm hoping you'll propose some clarification about
> > > EXPORT_SYMBOL_GPL().
> >
> > EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
> > only run that code. So for instance although we have "Dual BSD/GPL"
> > tags for modules pure "BSD" tags do not exist for module tags and
> > cannot run EXPORT_SYMBOL_GPL() code [0]. Also there is some folks
> > who do believe tha at run time all kernel modules are GPL [1] [2].
> > And to be precise even though the FSF may claim a list of licenses
> > are GPL-compatible we cannot rely on this list alone for our own
> > goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must
> > discuss this on lkml [2].
>
> By "propose some clarification," I meant that I hoped you would propose a
> patch to Documentation/ that would give maintainers some guidance.
I *really really* would hate to do so but only because you insist, I'll look
into this...
ASDF
Luis
^ permalink raw reply
* Re: [PATCH] fbcon: Fix incorrect fbcon_del_cursor_timer calls.
From: Greg KH @ 2015-05-27 13:00 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <201505272142.JGF00513.VJHOOLMOFSQFtF@I-love.SAKURA.ne.jp>
On Wed, May 27, 2015 at 09:42:27PM +0900, Tetsuo Handa wrote:
> >From f4976c5f9638633eb31a1c6dbe78861abf5c79c1 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Wed, 27 May 2015 21:36:38 +0900
> Subject: [PATCH] fbcon: Fix incorrect fbcon_del_cursor_timer calls.
Why is this all here?
Anyway, I _just_ committed this same change, from someone else, to fix
this, sorry. It will be in the next linux-next release.
greg k-h
^ permalink raw reply
* [PATCH] fbcon: Fix incorrect fbcon_del_cursor_timer calls.
From: Tetsuo Handa @ 2015-05-27 12:42 UTC (permalink / raw)
To: linux-fbdev
From f4976c5f9638633eb31a1c6dbe78861abf5c79c1 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Wed, 27 May 2015 21:36:38 +0900
Subject: [PATCH] fbcon: Fix incorrect fbcon_del_cursor_timer calls.
Commit 27a4c827c34a ("fbcon: use the cursor blink interval provided by vt")
by error changed to unconditionally call fbcon_del_cursor_timer() at
fbcon_cursor(). As a result, SysRq from keyboard started to hit
WARN_ON(in_irq() && !tbase_get_irqsafe(timer->base));
at del_timer_sync(), making the system unusable due to message flooding.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/console/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 05b1d1a..658c34b 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
return;
ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
- fbcon_del_cursor_timer(info);
- if (!(vc->vc_cursor_type & 0x10))
+ if (vc->vc_cursor_type & 0x10)
+ fbcon_del_cursor_timer(info);
+ else
fbcon_add_cursor_timer(info);
ops->cursor_flash = (mode = CM_ERASE) ? 0 : 1;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] fbcon: Avoid deleting a timer in IRQ context
From: Thierry Reding @ 2015-05-27 12:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Kevin Hilman, Scot Doyle, Daniel Stone,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
linux-kernel
In-Reply-To: <1432195083-25005-1-git-send-email-thierry.reding@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3394 bytes --]
On Thu, May 21, 2015 at 09:58:03AM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Commit 27a4c827c34a ("fbcon: use the cursor blink interval provided by
> vt") unconditionally removes the cursor blink timer. Unfortunately that
> wreaks havoc under some circumstances. An easily reproducible way is to
> use both the framebuffer console and a debug serial port as the console
> output for kernel messages (e.g. "console=ttyS0 console=tty1" on the
> kernel command-line. Upon boot this triggers a warning from within the
> del_timer_sync() function because it is called from IRQ context:
>
> [ 5.070096] ------------[ cut here ]------------
> [ 5.070110] WARNING: CPU: 0 PID: 0 at ../kernel/time/timer.c:1098 del_timer_sync+0x4c/0x54()
> [ 5.070115] Modules linked in:
> [ 5.070120] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc4-next-20150519 #1
> [ 5.070123] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 5.070142] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [ 5.070156] [] (show_stack) from [] (dump_stack+0x70/0xbc)
> [ 5.070164] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
> [ 5.070169] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
> [ 5.070174] [] (warn_slowpath_null) from [] (del_timer_sync+0x4c/0x54)
> [ 5.070183] [] (del_timer_sync) from [] (fbcon_del_cursor_timer+0x2c/0x40)
> [ 5.070190] [] (fbcon_del_cursor_timer) from [] (fbcon_cursor+0x9c/0x180)
> [ 5.070198] [] (fbcon_cursor) from [] (hide_cursor+0x30/0x98)
> [ 5.070204] [] (hide_cursor) from [] (vt_console_print+0x2a8/0x340)
> [ 5.070212] [] (vt_console_print) from [] (call_console_drivers.constprop.23+0xc8/0xec)
> [ 5.070218] [] (call_console_drivers.constprop.23) from [] (console_unlock+0x498/0x4f0)
> [ 5.070223] [] (console_unlock) from [] (vprintk_emit+0x1f0/0x508)
> [ 5.070228] [] (vprintk_emit) from [] (vprintk_default+0x24/0x2c)
> [ 5.070234] [] (vprintk_default) from [] (printk+0x70/0x88)
>
> After which the system starts spewing all kinds of weird and seemingly
> unrelated error messages.
>
> This commit fixes this by restoring the condition under which the call
> to fbcon_del_cursor_timer() happens.
>
> Reported-by: Daniel Stone <daniel@fooishbar.org>
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Tested-by: Kevin Hilman <khilman@linaro.org>
> Tested-by: Scot Doyle <lkml14@scotdoyle.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> drivers/video/console/fbcon.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Ping? This is an important fix, can we get this into linux-next sometime
soon?
Thierry
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index 05b1d1a71ef9..658c34bb9076 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
> return;
>
> ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
> - fbcon_del_cursor_timer(info);
> - if (!(vc->vc_cursor_type & 0x10))
> + if (vc->vc_cursor_type & 0x10)
> + fbcon_del_cursor_timer(info);
> + else
> fbcon_add_cursor_timer(info);
>
> ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
> --
> 2.4.1
>
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbcon: Avoid deleting a timer in IRQ context
From: Tomeu Vizoso @ 2015-05-27 12:10 UTC (permalink / raw)
To: Andrey Wagin
Cc: Thierry Reding, Greg Kroah-Hartman, Kevin Hilman, Scot Doyle,
Daniel Stone, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, LKML
In-Reply-To: <CANaxB-w4ejA-8ytWSL5m+af_KrSrNkqJGxpw9F5Ek8Ergu-sHw@mail.gmail.com>
On 27 May 2015 at 13:19, Andrey Wagin <avagin@gmail.com> wrote:
> 2015-05-21 10:58 GMT+03:00 Thierry Reding <thierry.reding@gmail.com>:
>> From: Thierry Reding <treding@nvidia.com>
>>
>> Commit 27a4c827c34a ("fbcon: use the cursor blink interval provided by
>> vt") unconditionally removes the cursor blink timer. Unfortunately that
>> wreaks havoc under some circumstances. An easily reproducible way is to
>> use both the framebuffer console and a debug serial port as the console
>> output for kernel messages (e.g. "console=ttyS0 console=tty1" on the
>> kernel command-line. Upon boot this triggers a warning from within the
>> del_timer_sync() function because it is called from IRQ context:
>>
>> [ 5.070096] ------------[ cut here ]------------
>> [ 5.070110] WARNING: CPU: 0 PID: 0 at ../kernel/time/timer.c:1098 del_timer_sync+0x4c/0x54()
>> [ 5.070115] Modules linked in:
>> [ 5.070120] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc4-next-20150519 #1
>> [ 5.070123] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [ 5.070142] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>> [ 5.070156] [] (show_stack) from [] (dump_stack+0x70/0xbc)
>> [ 5.070164] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
>> [ 5.070169] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
>> [ 5.070174] [] (warn_slowpath_null) from [] (del_timer_sync+0x4c/0x54)
>> [ 5.070183] [] (del_timer_sync) from [] (fbcon_del_cursor_timer+0x2c/0x40)
>> [ 5.070190] [] (fbcon_del_cursor_timer) from [] (fbcon_cursor+0x9c/0x180)
>> [ 5.070198] [] (fbcon_cursor) from [] (hide_cursor+0x30/0x98)
>> [ 5.070204] [] (hide_cursor) from [] (vt_console_print+0x2a8/0x340)
>> [ 5.070212] [] (vt_console_print) from [] (call_console_drivers.constprop.23+0xc8/0xec)
>> [ 5.070218] [] (call_console_drivers.constprop.23) from [] (console_unlock+0x498/0x4f0)
>> [ 5.070223] [] (console_unlock) from [] (vprintk_emit+0x1f0/0x508)
>> [ 5.070228] [] (vprintk_emit) from [] (vprintk_default+0x24/0x2c)
>> [ 5.070234] [] (vprintk_default) from [] (printk+0x70/0x88)
>>
>> After which the system starts spewing all kinds of weird and seemingly
>> unrelated error messages.
>>
>> This commit fixes this by restoring the condition under which the call
>> to fbcon_del_cursor_timer() happens.
>
> Tested-by: Andrew Vagin <avagin@virtuozzo.com>
>
> It would be good to push this patch into linux-next asap. Without this
> patch I can't execute tests on linux-next. Thanks.
Tested-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Same here, please apply.
Thanks,
Tomeu
>>
>> Reported-by: Daniel Stone <daniel@fooishbar.org>
>> Reported-by: Kevin Hilman <khilman@kernel.org>
>> Tested-by: Kevin Hilman <khilman@linaro.org>
>> Tested-by: Scot Doyle <lkml14@scotdoyle.com>
>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>> ---
>> drivers/video/console/fbcon.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
>> index 05b1d1a71ef9..658c34bb9076 100644
>> --- a/drivers/video/console/fbcon.c
>> +++ b/drivers/video/console/fbcon.c
>> @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
>> return;
>>
>> ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
>> - fbcon_del_cursor_timer(info);
>> - if (!(vc->vc_cursor_type & 0x10))
>> + if (vc->vc_cursor_type & 0x10)
>> + fbcon_del_cursor_timer(info);
>> + else
>> fbcon_add_cursor_timer(info);
>>
>> ops->cursor_flash = (mode = CM_ERASE) ? 0 : 1;
>> --
>> 2.4.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] fbcon: Avoid deleting a timer in IRQ context
From: Andrey Wagin @ 2015-05-27 11:19 UTC (permalink / raw)
To: Thierry Reding
Cc: Greg Kroah-Hartman, Kevin Hilman, Scot Doyle, Daniel Stone,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
LKML
In-Reply-To: <1432195083-25005-1-git-send-email-thierry.reding@gmail.com>
2015-05-21 10:58 GMT+03:00 Thierry Reding <thierry.reding@gmail.com>:
> From: Thierry Reding <treding@nvidia.com>
>
> Commit 27a4c827c34a ("fbcon: use the cursor blink interval provided by
> vt") unconditionally removes the cursor blink timer. Unfortunately that
> wreaks havoc under some circumstances. An easily reproducible way is to
> use both the framebuffer console and a debug serial port as the console
> output for kernel messages (e.g. "console=ttyS0 console=tty1" on the
> kernel command-line. Upon boot this triggers a warning from within the
> del_timer_sync() function because it is called from IRQ context:
>
> [ 5.070096] ------------[ cut here ]------------
> [ 5.070110] WARNING: CPU: 0 PID: 0 at ../kernel/time/timer.c:1098 del_timer_sync+0x4c/0x54()
> [ 5.070115] Modules linked in:
> [ 5.070120] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc4-next-20150519 #1
> [ 5.070123] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 5.070142] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [ 5.070156] [] (show_stack) from [] (dump_stack+0x70/0xbc)
> [ 5.070164] [] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
> [ 5.070169] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24)
> [ 5.070174] [] (warn_slowpath_null) from [] (del_timer_sync+0x4c/0x54)
> [ 5.070183] [] (del_timer_sync) from [] (fbcon_del_cursor_timer+0x2c/0x40)
> [ 5.070190] [] (fbcon_del_cursor_timer) from [] (fbcon_cursor+0x9c/0x180)
> [ 5.070198] [] (fbcon_cursor) from [] (hide_cursor+0x30/0x98)
> [ 5.070204] [] (hide_cursor) from [] (vt_console_print+0x2a8/0x340)
> [ 5.070212] [] (vt_console_print) from [] (call_console_drivers.constprop.23+0xc8/0xec)
> [ 5.070218] [] (call_console_drivers.constprop.23) from [] (console_unlock+0x498/0x4f0)
> [ 5.070223] [] (console_unlock) from [] (vprintk_emit+0x1f0/0x508)
> [ 5.070228] [] (vprintk_emit) from [] (vprintk_default+0x24/0x2c)
> [ 5.070234] [] (vprintk_default) from [] (printk+0x70/0x88)
>
> After which the system starts spewing all kinds of weird and seemingly
> unrelated error messages.
>
> This commit fixes this by restoring the condition under which the call
> to fbcon_del_cursor_timer() happens.
Tested-by: Andrew Vagin <avagin@virtuozzo.com>
It would be good to push this patch into linux-next asap. Without this
patch I can't execute tests on linux-next. Thanks.
>
> Reported-by: Daniel Stone <daniel@fooishbar.org>
> Reported-by: Kevin Hilman <khilman@kernel.org>
> Tested-by: Kevin Hilman <khilman@linaro.org>
> Tested-by: Scot Doyle <lkml14@scotdoyle.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> drivers/video/console/fbcon.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index 05b1d1a71ef9..658c34bb9076 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -1310,8 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
> return;
>
> ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
> - fbcon_del_cursor_timer(info);
> - if (!(vc->vc_cursor_type & 0x10))
> + if (vc->vc_cursor_type & 0x10)
> + fbcon_del_cursor_timer(info);
> + else
> fbcon_add_cursor_timer(info);
>
> ops->cursor_flash = (mode = CM_ERASE) ? 0 : 1;
> --
> 2.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 2/2] fbcon: use the cursor blink interval provided by vt
From: Andrey Wagin @ 2015-05-27 11:07 UTC (permalink / raw)
To: Scot Doyle
Cc: Greg Kroah-Hartman, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Jiri Slaby, Michael Kerrisk,
Pavel Machek, Geert Uytterhoeven, LKML,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.11.1505270737270.6667@local>
2015-05-27 10:52 GMT+03:00 Scot Doyle <lkml14@scotdoyle.com>:
> On Wed, 27 May 2015, Andrey Wagin wrote:
> ...
>> I regularly execute criu tests on linux-next. For this, I use virtual
>> machine from the digitalocean clould. The current version of
>> linux-next hangs after a few seconds. I use git bisect to find the
>> commit where the problem is appeaed. And it looks like the problem is
>> in this patch.
> ...
>> Thanks,
>> Andrew
>
> Perhaps this pending patch will help:
> http://marc.info/?l=linux-kernel&m\x143219509918969&w=2
Yes, it helps. Thanks.
>
> Thanks,
> Scot
>
^ permalink raw reply
* Re: [PATCHv6 00/10] Cleanup and add support for SSD1305
From: Tomi Valkeinen @ 2015-05-27 10:15 UTC (permalink / raw)
To: Thomas Niederprüm, plagnioj, maxime.ripard, kernel,
shawn.guo, robh+dt
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1427826436-21783-1-git-send-email-niederp@physik.uni-kl.de>
[-- Attachment #1: Type: text/plain, Size: 3681 bytes --]
On 31/03/15 21:27, Thomas Niederprüm wrote:
> Hi,
>
> this patch series is the result of making the ssd1307fb driver work with
> a Newhaven OLED display using the Solomon SSD1305 controller. To achieve
> this the intialization code for the SSD1306 and the SSD1307 is merged
> and based on DT configuration to reflect the various possible wirings
> of the SSD130X controller (04/10). Based on these changes it is straight
> forward to add support for the SSD1305 controller (06/10).
>
> While working on the driver I realized that it was not possible to
> correctly mmap the video memory from userspace since the address handed
> to the userspace app is a logical one where it should be a physical one.
> Patch 01/10 fixes this. Furthermore the memory reserved by kzalloc is
> not page aligned while the address handed to userspace is aligned to the
> next page frame. This problem is fixed by using __get_free_pages() in 02/10.
>
> Furthermore a module parameter is added to set the delay for the
> deferred io update (07/10). Also the backlight class is implemented to make
> the contrast setting available in userspace (09/10).
>
> changes since v1 (thanks to Maxime for the feedback):
> - dedicated patch for fixing smem_start address
> - remove page reserve upon vmalloc
> - remove return value check upon display turn-off at module unload
> - use a module parameter refreshrate rather than delaydivider
> - allocate fbdefio dynamically
> - use sysfs_create_groups to create sysfs entries
> - remove contrast, vhcom and dclk properties from DT since they are
> not part of hw description. The contrast module parameter was added
> to set contrast at load time. vhcom and dclk stays at it's default
> values for now.
> - add new DT properties to in tree users of ssd130X
> - rebased to apply on top of linux-next
>
> changes since v2 (thanks to Maxime again):
> - free memory allocated by vmalloc on driver unload
> - set default values in the init code to the ones of the existing ssd1307
> init code
> - added two ACKs (Maxime Ripard)
>
> changes since v3:
> - use backlight class rather than dedicated sysfs files to set the
> contrast (Thanks to Tomi Valkeinen)
> - remove [PATCHv3 08/10] fbdev: ssd1307fb: Add module parameter bitsperpixel
> - add new patch to blank the display (unreviewed)
> - allocate video memory through __get_free_pages() rather than vmalloc
> (Thanks to Geert Uytterhoeven)
> - minor rewordings of the commit messages
>
> changes since v4 (thanks to Maxime):
> - added two ACKs (Maxime Ripard)
> - fixed typo: s/REFRASHRATE/REFRESHRATE
> - updated the documentation to make clear the unit of com-offset
> - move addition of the module parameter contrast to a separate patch (09/11)
> - fix indentation errors
> - get rid of device_id in the device_info struct
>
> changes since v5:
> - remove [PATCHv5 09/11] fbdev: ssd1307fb: Add module parameter to set
> the initial contrast
> - remove unnecessary variable initialization in the deviceinfo struct as
> pointed out by Maxime
> - make the variable dclk_div hold the actual divider rather than the
> corresponding bit value
> - remove ret variable in ssd1307fb_blank() (thanks to Olliver Schinagl)
> - fixed bit mask for com_invdir as indicated by Olliver
> - change initialization of the charge pump as suggested by Olliver
> - change the default value for prechargep2 to 0x2 (thanks to Olliver)
> - change DT property name "com-sequential" to "com-seq"
> - added one ACK (Maxime Ripard)
> - added Tested-by Olliver Schinagl
I have queued this version for 4.2, with all the acks.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: remove duplicate from fb_videomode
From: Dan Carpenter @ 2015-05-27 8:29 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150526152239.GA21887@x230-arch.club.entropia.de>
On Wed, May 27, 2015 at 11:59:21AM +0530, Sudip Mukherjee wrote:
> On Tue, May 26, 2015 at 05:22:39PM +0200, Michel von Czettritz wrote:
> > As suggested by Sudip this patch removes the redundant 1360x768@60
> > option from the fb_videomode struct array.
> this can be in the comments but should not be there in the commit message.
>
No no. It's fine.
I sometimes give credit in the permanent log or in the meta comments
depending on how much credit/blame is deserved. :P
regards,
dan carpenter
^ 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