* Re: [PATCH v3 1/4] pci: add pci_ioremap_wc_bar()
From: Bjorn Helgaas @ 2015-05-20 21:02 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mst, plagnioj, tomi.valkeinen, linux-fbdev, luto, cocci,
Luis R. Rodriguez, Toshi Kani, Suresh Siddha, Ingo Molnar,
Thomas Gleixner, Juergen Gross, Daniel Vetter, Dave Airlie,
Antonino Daplas, Ville Syrjälä, Mel Gorman,
Vlastimil Babka, Borislav Petkov, Davidlohr Bueso, linux-kernel
In-Reply-To: <1429647634-17169-2-git-send-email-mcgrof@do-not-panic.com>
On Tue, Apr 21, 2015 at 01:20:31PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This lets drivers take advantage of PAT when available. This
> should help with the transition of converting video drivers over
> to ioremap_wc() to help with the goal of eventually using
> _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
> ioremap_nocache() (de33c442e titled "x86 PAT: fix performance
> drop for glx, use UC minus for ioremap(), ioremap_nocache() and
> pci_mmap_page_range()")
>
> Cc: Toshi Kani <toshi.kani@hp.com>
> Cc: Bjorn Helgaas <bhelgaas@google.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: Ville Syrjälä <syrjala@sci.fi>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Davidlohr Bueso <dbueso@suse.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
I don't have any objection to this, and I can apply the follow-on patches
as well, given the appropriate acks and prerequisite patches (ioremap_wc()
implementation).
> ---
> drivers/pci/pci.c | 14 ++++++++++++++
> include/linux/pci.h | 1 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 687af72..fd14f10 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -138,6 +138,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar)
> return ioremap_nocache(res->start, resource_size(res));
> }
> EXPORT_SYMBOL_GPL(pci_ioremap_bar);
> +
> +void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
> +{
> + /*
> + * Make sure the BAR is actually a memory resource, not an IO resource
> + */
> + if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
> + WARN_ON(1);
> + return NULL;
> + }
> + return ioremap_wc(pci_resource_start(pdev, bar),
> + pci_resource_len(pdev, bar));
> +}
> +EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
> #endif
>
> #define PCI_FIND_CAP_TTL 48
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index bc50bb0..490ca41 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1667,6 +1667,7 @@ static inline void pci_mmcfg_late_init(void) { }
> int pci_ext_cfg_avail(void);
>
> void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar);
> +void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar);
>
> #ifdef CONFIG_PCI_IOV
> int pci_iov_virtfn_bus(struct pci_dev *dev, int id);
> --
> 2.3.2.209.gd67f9d5.dirty
>
^ permalink raw reply
* Re: [PATCH v4 6/6] video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez @ 2015-05-20 20:57 UTC (permalink / raw)
To: Luis R. Rodriguez, Borislav Petkov, Tomi Valkeinen, Bjorn Helgaas
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
Jean-Christophe Plagniol-Villard, Daniel Vetter, Dave Airlie,
Doug Ledford, Andy Walls, Ville Syrjälä,
Andy Lutomirski, Michael S. Tsirkin, cocci@systeme.lip6.fr,
linux-kernel@vger.kernel.org, Toshi Kani, Suresh Siddha,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Rob Clark, Mathias Krause, Andrzej Hajda, Mel Gorman,
Vlastimil Babka, Davidlohr Bueso, linux-fbdev
In-Reply-To: <20150520195333.GZ23057@wotan.suse.de>
On Wed, May 20, 2015 at 12:53 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> Tomi,
>
> the new required ioremap_uc() which was added in the initial patch set here is
> now merged on linux-next but I just noticed a small issue with this atyfb
> specific patch, I'll fix that and respin and send to you as v5.
Actually since this series depends on ioremap_uc() and since I need to
respin the last patch in this series for atyfb provided I get an
Acked-by from you for the fbdev changes do you mind if this goes
through the x86 tree as that already has the ioremap_uc() required
call? Otherwise we will have one kernel release with that call
available but not used, and we'll have to wait for 2 releases before
these changes get merged.
Thoughts?
Luis
^ permalink raw reply
* Re: [Cocci] [PATCH v3 0/4] pci: add and use pci_ioremap_wc_bar()
From: Luis R. Rodriguez @ 2015-05-20 20:54 UTC (permalink / raw)
To: cocci
In-Reply-To: <20150519175310.GH23057@wotan.suse.de>
On Tue, May 19, 2015 at 10:53 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Wed, Apr 29, 2015 at 02:08:47PM -0700, Luis R. Rodriguez wrote:
>> On Tue, Apr 21, 2015 at 1:20 PM, Luis R. Rodriguez
>> <mcgrof@do-not-panic.com> wrote:
>> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
>> >
>> > This series adds pci_ioremap_wc_bar() and makes use of it
>> > on a few framebuffer device drivers.
>> >
>> > Luis R. Rodriguez (4):
>> > pci: add pci_ioremap_wc_bar()
>> > video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
>> > video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
>> > video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer
>>
>> Bjorn,
>>
>> any feedback on this series?
>
> Hey Bjorn, any feedback on this series ?
I meant this series. Also Tomi, do I get your Acks for these as well?
Since they depend on pci parts do you mind if we route them through
the PCI tree? I'll poke you soon about another similar type of patch
which has dependencies on another development tree.
Luis
^ permalink raw reply
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-05-20 20:52 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: David Airlie, Tomi Valkeinen, Michael S. Tsirkin,
Jean-Christophe Plagniol-Villard, Dave Airlie, Daniel Vetter,
linux-fbdev, Andy Lutomirski, cocci@systeme.lip6.fr,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Toshi Kani, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Antonino Daplas, Dave Hansen,
Arnd Bergmann, 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é, xen-devel@lists.xensource.com
In-Reply-To: <20150520203936.GC32152@google.com>
On Wed, May 20, 2015 at 1:39 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Tue, May 19, 2015 at 04:45:30PM -0700, Luis R. Rodriguez wrote:
>> On Tue, May 19, 2015 at 4:29 PM, David Airlie <airlied@redhat.com> wrote:
>> >
>> >> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> >> > [-cc Venkatesh (bouncing)
>> >> >
>> >> > On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
>> >> > <mcgrof@do-not-panic.com> wrote:
>> >> >> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas <bhelgaas@google.com>
>> >> >> wrote:
>> >> >>> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>> >> >>
>> >> >> Thanks! Who's tree should this go through?
>> >> >
>> >> > I don't know. This is the only patch that went to linux-pci, so I
>> >> > haven't seen the rest.
>> >>
>> >> Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
>> >> asking for changes.
>> >>
>> >> Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
>> >> had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
>> >> yet used. I replied. This patch can then be ignored but again, I'd
>> >> hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
>> >> symbol of this.
>
> I'm not really a fan of adding code before it's needed.
OK I'll skip this patch.
> But even when we have a user and that objection is resolved, I'd
> like to have a little more guidance on the difference between
> EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(), e.g., a patch to clarify
> what's in Documentation/DocBook/kernel-hacking.tmpl. I can't
> evaluate that issue based on "current trends and reality"; I need
> something a little more formal.
>
> If we want to allow non-GPL modules and we want to give them a
> consistent kernel interface, even though it might be lacking some
> implementation-specific things, I can follow that guideline.
>
> That's how I read the current kernel-hacking.tmpl text
> ("[EXPORT_SYMBOL_GPL()] implies that the function is considered
> an internal implementation issue, and not really an interface"),
> and that would lead me to suggest EXPORT_SYMBOL() in this case.
>
> If we don't care about consistency, and EXPORT_SYMBOL_GPL()
> should be used at the developer's preference, I can follow that
> guideline instead, but it would be easier if it were made more
> explicit.
I think that's fair for a maintainer to ask, provided that some
maintainers may not be aware of some history, I'll send a patch to
update the documentation to reflect reality. Note that this is not
just about allowing or not proprietary drivers, some folks also take
code from the kernel and use it or sell it on proprietary systems. The
rabbit hole is pretty big.
>> >> Patches v4 3-5 remain intact, I had addressed it to you, but failed to
>> >> Cc linux-pci, I'll go ahead and bounce those now.
>> >>
>> >> Just today Dave Arlie provided a Reviewed-by to some simple
>> >> framebuffer device driver changes. I wonder if these changes should go
>> >> through the framebuffer tree provided you already gave the Acked-by
>> >> for the PCI parts, or if the PCI parts should go in first and only
>> >> later (I guess we'd have to wait) then intake the driver changes that
>> >> use the symbol.
>> >>
>> >> What we decide should likely also apply to the series that adds
>> >> pci_ioremap_wc_bar() and makes use of it on drivers.
>> >>
>> >> Dave, Tomi, any preference?
>> >>
>> >
>> > Maybe send Bjorn a pull request with a tree with the pci changes, and the fb changes reviewed-by me and acked by Tomi.
>> >
>> > Seems like it could be the simplest path forward.
>>
>> Works with me, Bjorn, are you OK with that?
>
> Can you incorporate the acks and just post a complete v6? I don't like
> trying to assemble patches from different versions of a series; it's too
> much administrative hassle and too easy for me to screw up.
Yeah sure, will do. While at it, can you also review the patch that
adds pci_ioremap_wc_bar() as well? I'll bundle that series up too.
Luis
^ permalink raw reply
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: Bjorn Helgaas @ 2015-05-20 20:39 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: David Airlie, Tomi Valkeinen, Michael S. Tsirkin,
Jean-Christophe Plagniol-Villard, Dave Airlie, Daniel Vetter,
linux-fbdev, Andy Lutomirski, cocci@systeme.lip6.fr,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Toshi Kani, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Antonino Daplas, Dave Hansen,
Arnd Bergmann, 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é, xen-devel@lists.xensource.com
In-Reply-To: <CAB=NE6VkAT7JidB4ty0C1tAWTc__-tgTvzHa5OdPazrDzCv0-g@mail.gmail.com>
On Tue, May 19, 2015 at 04:45:30PM -0700, Luis R. Rodriguez wrote:
> On Tue, May 19, 2015 at 4:29 PM, David Airlie <airlied@redhat.com> wrote:
> >
> >> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> >> > [-cc Venkatesh (bouncing)
> >> >
> >> > On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
> >> > <mcgrof@do-not-panic.com> wrote:
> >> >> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas <bhelgaas@google.com>
> >> >> wrote:
> >> >>> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >> >>
> >> >> Thanks! Who's tree should this go through?
> >> >
> >> > I don't know. This is the only patch that went to linux-pci, so I
> >> > haven't seen the rest.
> >>
> >> Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
> >> asking for changes.
> >>
> >> Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
> >> had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
> >> yet used. I replied. This patch can then be ignored but again, I'd
> >> hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
> >> symbol of this.
I'm not really a fan of adding code before it's needed.
But even when we have a user and that objection is resolved, I'd
like to have a little more guidance on the difference between
EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(), e.g., a patch to clarify
what's in Documentation/DocBook/kernel-hacking.tmpl. I can't
evaluate that issue based on "current trends and reality"; I need
something a little more formal.
If we want to allow non-GPL modules and we want to give them a
consistent kernel interface, even though it might be lacking some
implementation-specific things, I can follow that guideline.
That's how I read the current kernel-hacking.tmpl text
("[EXPORT_SYMBOL_GPL()] implies that the function is considered
an internal implementation issue, and not really an interface"),
and that would lead me to suggest EXPORT_SYMBOL() in this case.
If we don't care about consistency, and EXPORT_SYMBOL_GPL()
should be used at the developer's preference, I can follow that
guideline instead, but it would be easier if it were made more
explicit.
> >> Patches v4 3-5 remain intact, I had addressed it to you, but failed to
> >> Cc linux-pci, I'll go ahead and bounce those now.
> >>
> >> Just today Dave Arlie provided a Reviewed-by to some simple
> >> framebuffer device driver changes. I wonder if these changes should go
> >> through the framebuffer tree provided you already gave the Acked-by
> >> for the PCI parts, or if the PCI parts should go in first and only
> >> later (I guess we'd have to wait) then intake the driver changes that
> >> use the symbol.
> >>
> >> What we decide should likely also apply to the series that adds
> >> pci_ioremap_wc_bar() and makes use of it on drivers.
> >>
> >> Dave, Tomi, any preference?
> >>
> >
> > Maybe send Bjorn a pull request with a tree with the pci changes, and the fb changes reviewed-by me and acked by Tomi.
> >
> > Seems like it could be the simplest path forward.
>
> Works with me, Bjorn, are you OK with that?
Can you incorporate the acks and just post a complete v6? I don't like
trying to assemble patches from different versions of a series; it's too
much administrative hassle and too easy for me to screw up.
Bjorn
^ permalink raw reply
* Re: [PATCH v4 6/6] video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc()
From: Luis R. Rodriguez @ 2015-05-20 19:53 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mingo, tglx, hpa, bp, plagnioj, tomi.valkeinen, daniel.vetter,
airlied, dledford, awalls, syrjala, luto, mst, cocci,
linux-kernel, Toshi Kani, Suresh Siddha, Juergen Gross,
Daniel Vetter, Dave Airlie, Antonino Daplas, Rob Clark,
Mathias Krause, Andrzej Hajda, Mel Gorman, Vlastimil Babka,
Davidlohr Bueso, linux-fbdev
In-Reply-To: <1430343851-967-7-git-send-email-mcgrof@do-not-panic.com>
Tomi,
the new required ioremap_uc() which was added in the initial patch set here is
now merged on linux-next but I just noticed a small issue with this atyfb
specific patch, I'll fix that and respin and send to you as v5.
Luis
^ permalink raw reply
* Re: [PATCH v3 2/3] video: fbdev: vesafb: add missing mtrr_del() for added MTRR
From: Luis R. Rodriguez @ 2015-05-20 19:46 UTC (permalink / raw)
To: cocci
In-Reply-To: <555C594E.1010607@ti.com>
On Wed, May 20, 2015 at 12:52:14PM +0300, Tomi Valkeinen wrote:
> Hi Luis,
>
> On 21/04/15 23:40, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > The MTRR added was never being deleted.
> >
> > Cc: Toshi Kani <toshi.kani@hp.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: Rob Clark <robdclark@gmail.com>
> > Cc: Jingoo Han <jg1.han@samsung.com>
> > Cc: Wolfram Sang <wsa@the-dreams.de>
> > 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/vesafb.c | 30 ++++++++++++++++++++++++------
> > 1 file changed, 24 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> > index 191156b..a2261d0 100644
> > --- a/drivers/video/fbdev/vesafb.c
> > +++ b/drivers/video/fbdev/vesafb.c
> > @@ -29,6 +29,10 @@
> >
> > /* --------------------------------------------------------------------- */
> >
> > +struct vesafb_par {
> > + int wc_cookie;
> > +};
> > +
> > static struct fb_var_screeninfo vesafb_defined = {
> > .activate = FB_ACTIVATE_NOW,
> > .height = -1,
> > @@ -175,7 +179,16 @@ static int vesafb_setcolreg(unsigned regno, unsigned red, unsigned green,
> >
> > static void vesafb_destroy(struct fb_info *info)
> > {
> > +#ifdef CONFIG_MTRR
> > + struct vesafb_par *par = info->par;
> > +#endif
> > +
> > fb_dealloc_cmap(&info->cmap);
> > +
> > +#ifdef CONFIG_MTRR
> > + if (par->wc_cookie >= 0)
> > + mtrr_del(par->wc_cookie, 0, 0);
> > +#endif
> > if (info->screen_base)
> > iounmap(info->screen_base);
> > release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size);
> > @@ -228,6 +241,7 @@ static int vesafb_setup(char *options)
> > static int vesafb_probe(struct platform_device *dev)
> > {
> > struct fb_info *info;
> > + struct vesafb_par *par;
> > int i, err;
> > unsigned int size_vmode;
> > unsigned int size_remap;
> > @@ -297,8 +311,8 @@ static int vesafb_probe(struct platform_device *dev)
> > return -ENOMEM;
> > }
> > platform_set_drvdata(dev, info);
> > - info->pseudo_palette = info->par;
> > - info->par = NULL;
> > + info->pseudo_palette = NULL;
> > + par = info->par;
> >
> > /* set vesafb aperture size for generic probing */
> > info->apertures = alloc_apertures(1);
> > @@ -407,17 +421,17 @@ static int vesafb_probe(struct platform_device *dev)
> > if (mtrr = 3) {
> > #ifdef CONFIG_MTRR
> > unsigned int temp_size = size_total;
> > - int rc;
> >
> > /* Find the largest power-of-two */
> > temp_size = roundup_pow_of_two(temp_size);
> >
> > /* Try and find a power of two to add */
> > do {
> > - rc = mtrr_add(vesafb_fix.smem_start, temp_size,
> > - MTRR_TYPE_WRCOMB, 1);
> > + par->wc_cookie = mtrr_add(vesafb_fix.smem_start,
> > + temp_size,
> > + MTRR_TYPE_WRCOMB, 1);
> > temp_size >>= 1;
> > - } while (temp_size >= PAGE_SIZE && rc = -EINVAL);
> > + } while (temp_size >= PAGE_SIZE && par->wc_cookie = -EINVAL);
> > #endif
> > info->screen_base = ioremap_wc(vesafb_fix.smem_start, vesafb_fix.smem_len);
> > } else {
> > @@ -462,6 +476,10 @@ static int vesafb_probe(struct platform_device *dev)
> > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > return 0;
> > err:
> > +#ifdef CONFIG_MTRR
> > + if (par->wc_cookie >= 0)
> > + mtrr_del(par->wc_cookie, 0, 0);
> > +#endif
> > if (info->screen_base)
> > iounmap(info->screen_base);
> > framebuffer_release(info);
>
> Hmm, this looks a bit odd... You're removing the pseudo_palette, and
> using its memory for mtrr cookie?
You are totally right, sorry, will spin a v3.
Luis
^ permalink raw reply
* Re: [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Luis R. Rodriguez @ 2015-05-20 18:58 UTC (permalink / raw)
To: cocci
In-Reply-To: <555C4ADE.6030400@ti.com>
On Wed, May 20, 2015 at 11:50:38AM +0300, Tomi Valkeinen wrote:
>
>
> On 14/05/15 17:26, Luis R. Rodriguez wrote:
>
> > Tomi,
> >
> > Any chance you can consider this series again? I realize you say you are
> > not familiar with MTRR but given its prevalence use on framebuffer device
> > drivers and since you are a framebuffer subsystem maintainer I think its
> > perhaps fair to ask one of you become familiar with this stuff, or ask
> > questions if there are any. If its of any help this patch which adds
> > ioremap_uc() already got merged and the logic to phase MTRR is described
> > there too:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?idäb6be33c28923d8cde53023e0888b1c5d1a9027
> >
> > That patch won't even be needed on this series, this series happens to be
> > straight forward: if you just ioremap_nocache() once and use mtrr_add()
> > then conver over to ioremap_wc() and use arch_phys_wc_add(). If it already
> > used ioremap_wc() just convert over from mtrr_add() to arch_phys_wc_add()
> >
> > Not sure if you will get an Acked-by by x86 folks on this series as they
> > are busy, but I'm adding bp and hpa just in case.
>
> These are now queued for 4.2. Sorry it took so long. I've been away and
> my bandwidth for the fbdev maintainership has been rather limited lately.
Great thanks for the heads up!
Luis
^ permalink raw reply
* Re: distorted text
From: Simon Vincent @ 2015-05-20 16:03 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <555C660B.2080808@xsilon.com>
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
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Thierry Reding @ 2015-05-20 12:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Kevin Hilman, Scot Doyle, Tomi Valkeinen, Michael Kerrisk,
Jiri Slaby, Jean-Christophe Plagniol-Villard, Pavel Machek,
Geert Uytterhoeven, lkml, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Tyler Baker, Olof Johansson,
Daniel Stone, Arnd Bergmann
In-Reply-To: <20150519234112.GA25218-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3049 bytes --]
On Tue, May 19, 2015 at 04:41:12PM -0700, Greg Kroah-Hartman wrote:
> On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
> > On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
> > > On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
> > > <thierry.reding@gmail.com> wrote:
> > > > On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
> > > >> On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle <lkml14@scotdoyle.com> wrote:
> > > >> > vt now provides a cursor blink interval via vc_data. Use this
> > > >> > interval instead of the currently hardcoded 200 msecs. Store it in
> > > >> > fbcon_ops to avoid locking the console in cursor_timer_handler().
> > > >> >
> > > >> > Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
> > > >> > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > >>
> > > >> This patch hit next-20150519 in the form of commit 27a4c827c34a
> > > >> (fbcon: use the cursor blink interval provided by vt) and has caused
> > > >> boot failure on a handful of ARM platforms when booting a MMC root
> > > >> filesystem. This error was spotted by the kernelci.org bot on
> > > >> exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
> > > >> some tegra platforms too.
> > > >>
> > > >> Thierry spotted this commit as a potential cause, and both Daniel and
> > > >> I have reverted and boot tested on exynos5 and tegra respectively and
> > > >> the boot panics disappear.
> > > >
> > > > FWIW, if I apply the below on top of next-20150519 things seem to be
> > > > back to normal as well:
> > > >
> > > > 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;
> > >
> > > Applying this on next-20150519 makes my exynos board happily boot again as well.
> > >
> > > Tested-by: Kevin Hilman <khilman@linaro.org>
> >
> > Excellent. Greg, Scot, any opinions on whether or not this is the right
> > thing to do? It restores a bit that looks suspiciously like it snuck in
> > in the original (at least it isn't documented in the commit message).
> >
> > Greg, feel free to squash this in if everybody agrees this is good to
> > go. If you prefer a patch on top let me know and I'll come up with a
> > proper commit message.
>
> Please send a real patch and I'll apply it on top, as I can't rebase my
> public tree.
Attached.
Thierry
[-- Attachment #1.2: 0001-fbcon-Avoid-deleting-a-timer-in-IRQ-context.patch --]
[-- Type: text/x-diff, Size: 3279 bytes --]
From 4f2f70dbbe9de54c0da9b03a1f384e1464755eab Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Wed, 20 May 2015 13:41:52 +0200
Subject: [PATCH] fbcon: Avoid deleting a timer in IRQ context
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(-)
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 related
* Re: [PATCH v3 06/17] video: lcd: add LoCoMo LCD driver
From: Jingoo Han @ 2015-05-20 12:26 UTC (permalink / raw)
To: 'Dmitry Eremin-Solenikov', 'Lee Jones'
Cc: 'Russell King', 'Daniel Mack',
'Robert Jarzmik', 'Linus Walleij',
'Alexandre Courbot', 'Wolfram Sang',
'Dmitry Torokhov', 'Bryan Wu',
'Richard Purdie', 'Samuel Ortiz',
'Mark Brown', 'Jean-Christophe PLAGNIOL-VILLARD',
'Tomi Valkeinen', 'Liam Girdwood',
'Andrea Adami', linux-arm-kernel, linux-gpiol,
linux-input, linux-leds, linux-spi, linux-fbdev, alsa-devel
In-Reply-To: <1431880077-26321-7-git-send-email-dbaryshkov@gmail.com>
> LoCoMo has some special handling for TFT screens attached to Collie and
> Poodle. Implement that as a separate driver.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
> ---
> drivers/video/backlight/Kconfig | 10 ++
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/locomo_lcd.c | 285 +++++++++++++++++++++++++++++++++++
> 3 files changed, 296 insertions(+)
> create mode 100644 drivers/video/backlight/locomo_lcd.c
^ permalink raw reply
* distorted text
From: Simon Vincent @ 2015-05-20 10:46 UTC (permalink / raw)
To: linux-fbdev
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
^ permalink raw reply
* Re: [PATCH v3 2/3] video: fbdev: vesafb: add missing mtrr_del() for added MTRR
From: Tomi Valkeinen @ 2015-05-20 9:52 UTC (permalink / raw)
To: Luis R. Rodriguez, plagnioj, hpa
Cc: linux-fbdev, luto, cocci, Luis R. Rodriguez, Toshi Kani,
Suresh Siddha, Ingo Molnar, Thomas Gleixner, Juergen Gross,
Daniel Vetter, Dave Airlie, Antonino Daplas, Rob Clark,
Jingoo Han, Wolfram Sang, linux-kernel
In-Reply-To: <1429648850-17902-3-git-send-email-mcgrof@do-not-panic.com>
[-- Attachment #1: Type: text/plain, Size: 3913 bytes --]
Hi Luis,
On 21/04/15 23:40, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> The MTRR added was never being deleted.
>
> Cc: Toshi Kani <toshi.kani@hp.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: Rob Clark <robdclark@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> 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/vesafb.c | 30 ++++++++++++++++++++++++------
> 1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> index 191156b..a2261d0 100644
> --- a/drivers/video/fbdev/vesafb.c
> +++ b/drivers/video/fbdev/vesafb.c
> @@ -29,6 +29,10 @@
>
> /* --------------------------------------------------------------------- */
>
> +struct vesafb_par {
> + int wc_cookie;
> +};
> +
> static struct fb_var_screeninfo vesafb_defined = {
> .activate = FB_ACTIVATE_NOW,
> .height = -1,
> @@ -175,7 +179,16 @@ static int vesafb_setcolreg(unsigned regno, unsigned red, unsigned green,
>
> static void vesafb_destroy(struct fb_info *info)
> {
> +#ifdef CONFIG_MTRR
> + struct vesafb_par *par = info->par;
> +#endif
> +
> fb_dealloc_cmap(&info->cmap);
> +
> +#ifdef CONFIG_MTRR
> + if (par->wc_cookie >= 0)
> + mtrr_del(par->wc_cookie, 0, 0);
> +#endif
> if (info->screen_base)
> iounmap(info->screen_base);
> release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size);
> @@ -228,6 +241,7 @@ static int vesafb_setup(char *options)
> static int vesafb_probe(struct platform_device *dev)
> {
> struct fb_info *info;
> + struct vesafb_par *par;
> int i, err;
> unsigned int size_vmode;
> unsigned int size_remap;
> @@ -297,8 +311,8 @@ static int vesafb_probe(struct platform_device *dev)
> return -ENOMEM;
> }
> platform_set_drvdata(dev, info);
> - info->pseudo_palette = info->par;
> - info->par = NULL;
> + info->pseudo_palette = NULL;
> + par = info->par;
>
> /* set vesafb aperture size for generic probing */
> info->apertures = alloc_apertures(1);
> @@ -407,17 +421,17 @@ static int vesafb_probe(struct platform_device *dev)
> if (mtrr == 3) {
> #ifdef CONFIG_MTRR
> unsigned int temp_size = size_total;
> - int rc;
>
> /* Find the largest power-of-two */
> temp_size = roundup_pow_of_two(temp_size);
>
> /* Try and find a power of two to add */
> do {
> - rc = mtrr_add(vesafb_fix.smem_start, temp_size,
> - MTRR_TYPE_WRCOMB, 1);
> + par->wc_cookie = mtrr_add(vesafb_fix.smem_start,
> + temp_size,
> + MTRR_TYPE_WRCOMB, 1);
> temp_size >>= 1;
> - } while (temp_size >= PAGE_SIZE && rc == -EINVAL);
> + } while (temp_size >= PAGE_SIZE && par->wc_cookie == -EINVAL);
> #endif
> info->screen_base = ioremap_wc(vesafb_fix.smem_start, vesafb_fix.smem_len);
> } else {
> @@ -462,6 +476,10 @@ static int vesafb_probe(struct platform_device *dev)
> fb_info(info, "%s frame buffer device\n", info->fix.id);
> return 0;
> err:
> +#ifdef CONFIG_MTRR
> + if (par->wc_cookie >= 0)
> + mtrr_del(par->wc_cookie, 0, 0);
> +#endif
> if (info->screen_base)
> iounmap(info->screen_base);
> framebuffer_release(info);
Hmm, this looks a bit odd... You're removing the pseudo_palette, and
using its memory for mtrr cookie?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: Tomi Valkeinen @ 2015-05-20 9:04 UTC (permalink / raw)
To: Luis R. Rodriguez, David Airlie
Cc: Bjorn Helgaas, Michael S. Tsirkin,
Jean-Christophe Plagniol-Villard, Dave Airlie, Daniel Vetter,
linux-fbdev, Andy Lutomirski, cocci@systeme.lip6.fr,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Toshi Kani, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Antonino Daplas, Dave Hansen,
Arnd Bergmann, 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é, xen-devel@lists.xensource.com
In-Reply-To: <CAB=NE6VkAT7JidB4ty0C1tAWTc__-tgTvzHa5OdPazrDzCv0-g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]
On 20/05/15 02:45, Luis R. Rodriguez wrote:
> On Tue, May 19, 2015 at 4:29 PM, David Airlie <airlied@redhat.com> wrote:
>>
>>> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>>>> [-cc Venkatesh (bouncing)
>>>>
>>>> On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
>>>> <mcgrof@do-not-panic.com> wrote:
>>>>> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas <bhelgaas@google.com>
>>>>> wrote:
>>>>>> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>>>>>
>>>>> Thanks! Who's tree should this go through?
>>>>
>>>> I don't know. This is the only patch that went to linux-pci, so I
>>>> haven't seen the rest.
>>>
>>> Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
>>> asking for changes.
>>>
>>> Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
>>> had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
>>> yet used. I replied. This patch can then be ignored but again, I'd
>>> hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
>>> symbol of this.
>>>
>>> Patches v4 3-5 remain intact, I had addressed it to you, but failed to
>>> Cc linux-pci, I'll go ahead and bounce those now.
>>>
>>> Just today Dave Arlie provided a Reviewed-by to some simple
>>> framebuffer device driver changes. I wonder if these changes should go
>>> through the framebuffer tree provided you already gave the Acked-by
>>> for the PCI parts, or if the PCI parts should go in first and only
>>> later (I guess we'd have to wait) then intake the driver changes that
>>> use the symbol.
>>>
>>> What we decide should likely also apply to the series that adds
>>> pci_ioremap_wc_bar() and makes use of it on drivers.
>>>
>>> Dave, Tomi, any preference?
>>>
>>
>> Maybe send Bjorn a pull request with a tree with the pci changes, and the fb changes reviewed-by me and acked by Tomi.
>>
>> Seems like it could be the simplest path forward.
>
> Works with me, Bjorn, are you OK with that?
>
> Dave, Tomi, I still need your Reviewed-by and Acked-by's Tomi on these
> two PCI series. Please let me know if I should resend those first, but
> I think I had Cc'd you folks already on them.
For the fb parts:
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
I don't have anything in my fbdev-next branch touching the fbdev drivers
changed in this series, so merging via some other tree might go fine
without conflicts.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Tomi Valkeinen @ 2015-05-20 8:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1429647398-16983-1-git-send-email-mcgrof@do-not-panic.com>
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
On 14/05/15 17:26, Luis R. Rodriguez wrote:
> Tomi,
>
> Any chance you can consider this series again? I realize you say you are
> not familiar with MTRR but given its prevalence use on framebuffer device
> drivers and since you are a framebuffer subsystem maintainer I think its
> perhaps fair to ask one of you become familiar with this stuff, or ask
> questions if there are any. If its of any help this patch which adds
> ioremap_uc() already got merged and the logic to phase MTRR is described
> there too:
>
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=e4b6be33c28923d8cde53023e0888b1c5d1a9027
>
> That patch won't even be needed on this series, this series happens to be
> straight forward: if you just ioremap_nocache() once and use mtrr_add()
> then conver over to ioremap_wc() and use arch_phys_wc_add(). If it already
> used ioremap_wc() just convert over from mtrr_add() to arch_phys_wc_add()
>
> Not sure if you will get an Acked-by by x86 folks on this series as they
> are busy, but I'm adding bp and hpa just in case.
These are now queued for 4.2. Sorry it took so long. I've been away and
my bandwidth for the fbdev maintainership has been rather limited lately.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [Cocci] [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Tomi Valkeinen @ 2015-05-20 8:45 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150519175802.GJ23057@wotan.suse.de>
[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]
Hi,
On 20/05/15 01:17, Dave Airlie wrote:
> On 20 May 2015 at 03:58, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>> On Thu, May 14, 2015 at 04:26:45PM +0200, Luis R. Rodriguez wrote:
>>> On Tue, May 05, 2015 at 06:47:31AM -0700, Andy Lutomirski wrote:
>>>> On Mon, May 4, 2015 at 3:33 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>>> On 29/04/15 22:18, Luis R. Rodriguez wrote:
>>>>>> On Tue, Apr 21, 2015 at 1:16 PM, Luis R. Rodriguez
>>>>>> <mcgrof@do-not-panic.com> wrote:
>>>>>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>>>>>
>>>>>>> This series addresses simple changes to framebuffer drivers to use
>>>>>>> arch_phys_wc_add() and ioremap_wc() as well as fixing gbefb to add
>>>>>>> missing mtrr_del() calls. These changes are pretty straight forward.
>>>>>>>
>>>>>>> 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
>>>>>>
>
> These 17 are all
>
> Reviewed-by: Dave Airlie <airlied@redhat.com>
>
> Tomi, can you please take them via the fbdev tree?
Thanks. Yep, I'll queue them for 4.2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: exynos: fix modular build
From: Paul Bolle @ 2015-05-20 7:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2708563.ADEZz3igC5@wuerfel>
On Tue, 2015-05-19 at 14:17 +0200, Arnd Bergmann wrote:
> Finally, the EXYNOS_VIDEO option is turned into tristate as well
> for good measure, as all framebuffer drivers should be configurable
> as modules.
EXYNOS_MIPI_DSI and EXYNOS_LCD_S6E8AX0 are made tristate too. And that
is, I think, what counts. See below.
For anyone wondering how these two drivers can be made modular with only
a few tweaks to the build system: that is because exynos_mipi_dsi.c and
s6e8ax0.c already contain module specific boilerplate. They probably
already contained that boilerplate when they were added three years ago.
(Perhaps the changelog should mention this.)
> --- a/drivers/video/fbdev/exynos/Kconfig
> +++ b/drivers/video/fbdev/exynos/Kconfig
> menuconfig EXYNOS_VIDEO
> - bool "Exynos Video driver support"
> + tristate "Exynos Video driver support"
> depends on ARCH_S5PV210 || ARCH_EXYNOS
> help
> This enables support for EXYNOS Video device.
I have tested this only lightly but I do think this hunk is not needed.
Because basically all that this entry does is making EXYNOS_MIPI_DSI and
EXYNOS_LCD_S6E8AX0 available. And that works just as well if it's a
bool. Correct?
> config EXYNOS_MIPI_DSI
> - bool "EXYNOS MIPI DSI driver support."
> + tristate "EXYNOS MIPI DSI driver support."
> select GENERIC_PHY
> help
> This enables support for MIPI-DSI device.
>
> config EXYNOS_LCD_S6E8AX0
> - bool "S6E8AX0 MIPI AMOLED LCD Driver"
> + tristate "S6E8AX0 MIPI AMOLED LCD Driver"
> depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE
> depends on (LCD_CLASS_DEVICE = y)
> default n
> --- a/drivers/video/fbdev/exynos/Makefile
> +++ b/drivers/video/fbdev/exynos/Makefile
> -obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
> - exynos_mipi_dsi_lowlevel.o
> +obj-$(CONFIG_EXYNOS_MIPI_DSI) += exynos-mipi-dsi-mod.o
> +
> +exynos-mipi-dsi-mod-objs += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
> + exynos_mipi_dsi_lowlevel.o
I don't speak Makefilese fluently, so I have to ask. Is the -mod
extension needed because a module built from multiple files can't have a
name that matches the name of one of its .c files (minus the .c
extension, of course)?
> obj-$(CONFIG_EXYNOS_LCD_S6E8AX0) += s6e8ax0.o
Thanks,
Paul Bolle
^ permalink raw reply
* Re: [PATCH] video: exynos: fix modular build
From: Krzysztof Kozlowski @ 2015-05-20 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2708563.ADEZz3igC5@wuerfel>
On 19.05.2015 21:17, Arnd Bergmann wrote:
> The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
> which can be configured as a loadable module, so we have to
> make the driver a tristate symbol as well, to avoid this error:
>
> drivers/built-in.o: In function `s6e8ax0_probe':
> :(.text+0x23a48): undefined reference to `devm_backlight_device_register'
>
> This also means we get another error from a missing export, which
> this fixes as well:
>
> ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
>
> Finally, the EXYNOS_VIDEO option is turned into tristate as well
> for good measure, as all framebuffer drivers should be configurable
> as modules.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Looks good:
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Scot Doyle @ 2015-05-20 0:36 UTC (permalink / raw)
To: Thierry Reding
Cc: Kevin Hilman, Scot Doyle, Greg Kroah-Hartman, Tomi Valkeinen,
Michael Kerrisk, Jiri Slaby, Jean-Christophe Plagniol-Villard,
Pavel Machek, Geert Uytterhoeven, lkml, linux-fbdev, linux-man,
linux-api, Tyler Baker, Olof Johansson, Daniel Stone,
Arnd Bergmann
In-Reply-To: <20150519215228.GA27163@ulmo.nvidia.com>
On Tue, 19 May 2015, Thierry Reding wrote:
> On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
> > On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
> > <thierry.reding@gmail.com> wrote:
...
> > >
> > > FWIW, if I apply the below on top of next-20150519 things seem to be
> > > back to normal as well:
> > >
> > > 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;
> >
> > Applying this on next-20150519 makes my exynos board happily boot again as well.
> >
> > Tested-by: Kevin Hilman <khilman@linaro.org>
>
> Excellent. Greg, Scot, any opinions on whether or not this is the right
> thing to do? It restores a bit that looks suspiciously like it snuck in
> in the original (at least it isn't documented in the commit message).
>
> Greg, feel free to squash this in if everybody agrees this is good to
> go. If you prefer a patch on top let me know and I'll come up with a
> proper commit message.
>
> Thierry
Hi all, sorry for the trouble.
The timer delete was to prevent blink stutter when updating the interval.
Since the stutter isn't so noticable when changing from the default 200ms,
and since most people seem to prefer leaving the fbcon code alone if
possible, I agree with Thierry's approach.
Tested-by: Scot Doyle <lkml14@scotdoyle.com>
^ permalink raw reply
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-05-19 23:45 UTC (permalink / raw)
To: David Airlie
Cc: Bjorn Helgaas, Tomi Valkeinen, Michael S. Tsirkin,
Jean-Christophe Plagniol-Villard, Dave Airlie, Daniel Vetter,
linux-fbdev, Andy Lutomirski, cocci@systeme.lip6.fr,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Toshi Kani, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Antonino Daplas, Dave Hansen,
Arnd Bergmann, 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é, xen-devel@lists.xensource.com
In-Reply-To: <1347189446.1486831.1432078140756.JavaMail.zimbra@redhat.com>
On Tue, May 19, 2015 at 4:29 PM, David Airlie <airlied@redhat.com> wrote:
>
>> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> > [-cc Venkatesh (bouncing)
>> >
>> > On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
>> > <mcgrof@do-not-panic.com> wrote:
>> >> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas <bhelgaas@google.com>
>> >> wrote:
>> >>> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>> >>
>> >> Thanks! Who's tree should this go through?
>> >
>> > I don't know. This is the only patch that went to linux-pci, so I
>> > haven't seen the rest.
>>
>> Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
>> asking for changes.
>>
>> Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
>> had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
>> yet used. I replied. This patch can then be ignored but again, I'd
>> hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
>> symbol of this.
>>
>> Patches v4 3-5 remain intact, I had addressed it to you, but failed to
>> Cc linux-pci, I'll go ahead and bounce those now.
>>
>> Just today Dave Arlie provided a Reviewed-by to some simple
>> framebuffer device driver changes. I wonder if these changes should go
>> through the framebuffer tree provided you already gave the Acked-by
>> for the PCI parts, or if the PCI parts should go in first and only
>> later (I guess we'd have to wait) then intake the driver changes that
>> use the symbol.
>>
>> What we decide should likely also apply to the series that adds
>> pci_ioremap_wc_bar() and makes use of it on drivers.
>>
>> Dave, Tomi, any preference?
>>
>
> Maybe send Bjorn a pull request with a tree with the pci changes, and the fb changes reviewed-by me and acked by Tomi.
>
> Seems like it could be the simplest path forward.
Works with me, Bjorn, are you OK with that?
Dave, Tomi, I still need your Reviewed-by and Acked-by's Tomi on these
two PCI series. Please let me know if I should resend those first, but
I think I had Cc'd you folks already on them.
Luis
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Greg Kroah-Hartman @ 2015-05-19 23:41 UTC (permalink / raw)
To: Thierry Reding
Cc: Kevin Hilman, Scot Doyle, Tomi Valkeinen, Michael Kerrisk,
Jiri Slaby, Jean-Christophe Plagniol-Villard, Pavel Machek,
Geert Uytterhoeven, lkml, linux-fbdev, linux-man, linux-api,
Tyler Baker, Olof Johansson, Daniel Stone, Arnd Bergmann
In-Reply-To: <20150519215228.GA27163@ulmo.nvidia.com>
On Tue, May 19, 2015 at 11:52:29PM +0200, Thierry Reding wrote:
> On Tue, May 19, 2015 at 02:45:19PM -0700, Kevin Hilman wrote:
> > On Tue, May 19, 2015 at 2:40 PM, Thierry Reding
> > <thierry.reding@gmail.com> wrote:
> > > On Tue, May 19, 2015 at 02:15:41PM -0700, Kevin Hilman wrote:
> > >> On Thu, Mar 26, 2015 at 6:56 AM, Scot Doyle <lkml14@scotdoyle.com> wrote:
> > >> > vt now provides a cursor blink interval via vc_data. Use this
> > >> > interval instead of the currently hardcoded 200 msecs. Store it in
> > >> > fbcon_ops to avoid locking the console in cursor_timer_handler().
> > >> >
> > >> > Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
> > >> > Acked-by: Pavel Machek <pavel@ucw.cz>
> > >>
> > >> This patch hit next-20150519 in the form of commit 27a4c827c34a
> > >> (fbcon: use the cursor blink interval provided by vt) and has caused
> > >> boot failure on a handful of ARM platforms when booting a MMC root
> > >> filesystem. This error was spotted by the kernelci.org bot on
> > >> exynos5800-peach-pi[1] and Thierry and Daniel (Cc'd) have seen it on
> > >> some tegra platforms too.
> > >>
> > >> Thierry spotted this commit as a potential cause, and both Daniel and
> > >> I have reverted and boot tested on exynos5 and tegra respectively and
> > >> the boot panics disappear.
> > >
> > > FWIW, if I apply the below on top of next-20150519 things seem to be
> > > back to normal as well:
> > >
> > > 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;
> >
> > Applying this on next-20150519 makes my exynos board happily boot again as well.
> >
> > Tested-by: Kevin Hilman <khilman@linaro.org>
>
> Excellent. Greg, Scot, any opinions on whether or not this is the right
> thing to do? It restores a bit that looks suspiciously like it snuck in
> in the original (at least it isn't documented in the commit message).
>
> Greg, feel free to squash this in if everybody agrees this is good to
> go. If you prefer a patch on top let me know and I'll come up with a
> proper commit message.
Please send a real patch and I'll apply it on top, as I can't rebase my
public tree.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: David Airlie @ 2015-05-19 23:29 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bjorn Helgaas, Tomi Valkeinen, Michael S. Tsirkin,
Jean-Christophe Plagniol-Villard, Dave Airlie, Daniel Vetter,
linux-fbdev, Andy Lutomirski, cocci, linux-kernel, linux-pci,
Toshi Kani, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Antonino Daplas, Dave Hansen,
Arnd Bergmann, 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é, xen-devel
In-Reply-To: <CAB=NE6U8Fg1TuU9ceVCBHJwR2j+DetDz+L3ZqcJzvSy3_wvPUA@mail.gmail.com>
> On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > [-cc Venkatesh (bouncing)
> >
> > On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
> > <mcgrof@do-not-panic.com> wrote:
> >> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas <bhelgaas@google.com>
> >> wrote:
> >>> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >>
> >> Thanks! Who's tree should this go through?
> >
> > I don't know. This is the only patch that went to linux-pci, so I
> > haven't seen the rest.
>
> Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
> asking for changes.
>
> Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
> had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
> yet used. I replied. This patch can then be ignored but again, I'd
> hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
> symbol of this.
>
> Patches v4 3-5 remain intact, I had addressed it to you, but failed to
> Cc linux-pci, I'll go ahead and bounce those now.
>
> Just today Dave Arlie provided a Reviewed-by to some simple
> framebuffer device driver changes. I wonder if these changes should go
> through the framebuffer tree provided you already gave the Acked-by
> for the PCI parts, or if the PCI parts should go in first and only
> later (I guess we'd have to wait) then intake the driver changes that
> use the symbol.
>
> What we decide should likely also apply to the series that adds
> pci_ioremap_wc_bar() and makes use of it on drivers.
>
> Dave, Tomi, any preference?
>
Maybe send Bjorn a pull request with a tree with the pci changes, and the fb changes reviewed-by me and acked by Tomi.
Seems like it could be the simplest path forward.
Dave.
^ permalink raw reply
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-05-19 23:15 UTC (permalink / raw)
To: Bjorn Helgaas, Dave Airlie, Tomi Valkeinen
Cc: Michael S. Tsirkin, Jean-Christophe Plagniol-Villard, Dave Airlie,
Daniel Vetter, linux-fbdev, Andy Lutomirski,
cocci@systeme.lip6.fr, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Toshi Kani, Suresh Siddha, Ingo Molnar,
Thomas Gleixner, Juergen Gross, Daniel Vetter, Antonino Daplas,
Dave Hansen, Arnd Bergmann, 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é, xen-devel@lists.xensource.com
In-Reply-To: <CAErSpo6B3_vRq-4YTSPg4f927WChZ4MXnZRY7wWCvQgZJ=9eOQ@mail.gmail.com>
On Tue, May 19, 2015 at 4:02 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> [-cc Venkatesh (bouncing)
>
> On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
> <mcgrof@do-not-panic.com> wrote:
>> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>>> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>>
>> Thanks! Who's tree should this go through?
>
> I don't know. This is the only patch that went to linux-pci, so I
> haven't seen the rest.
Oh I only rev'd a v5 for 1/5 as that's the only one that had feedback
asking for changes.
Patch v4 2/5 was for "lib: devres: add pcim_iomap_wc() variants", you
had questions about EXPORT_SYMBOL_GPL() and the fact that this is not
yet used. I replied. This patch can then be ignored but again, I'd
hate for folks to go in and try to add a non EXPORT_SYMBOL_GPL()
symbol of this.
Patches v4 3-5 remain intact, I had addressed it to you, but failed to
Cc linux-pci, I'll go ahead and bounce those now.
Just today Dave Arlie provided a Reviewed-by to some simple
framebuffer device driver changes. I wonder if these changes should go
through the framebuffer tree provided you already gave the Acked-by
for the PCI parts, or if the PCI parts should go in first and only
later (I guess we'd have to wait) then intake the driver changes that
use the symbol.
What we decide should likely also apply to the series that adds
pci_ioremap_wc_bar() and makes use of it on drivers.
Dave, Tomi, any preference?
Luis
^ permalink raw reply
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: Bjorn Helgaas @ 2015-05-19 23:02 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Michael S. Tsirkin, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Dave Airlie, Daniel Vetter, linux-fbdev,
Andy Lutomirski, cocci@systeme.lip6.fr,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Toshi Kani, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Dave Hansen, Arnd Bergmann, 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é, xen-devel@lists.xensource.com
In-Reply-To: <CAB=NE6VhdEpiTrxW=VqjsJ94pDzcL5XwEgJyJ07D3-14KAdt9g@mail.gmail.com>
[-cc Venkatesh (bouncing)
On Tue, May 19, 2015 at 5:46 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>
> Thanks! Who's tree should this go through?
I don't know. This is the only patch that went to linux-pci, so I
haven't seen the rest.
Bjorn
^ permalink raw reply
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-05-19 22:46 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Michael S. Tsirkin, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Dave Airlie, daniel.vetter, linux-fbdev,
Andy Lutomirski, cocci@systeme.lip6.fr,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Toshi Kani, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Juergen Gross, Daniel Vetter, Dave Airlie, Antonino Daplas,
Dave Hansen, Arnd Bergmann, 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é, xen-devel@lists.xensource.com
In-Reply-To: <20150519224452.GT31666@google.com>
On Tue, May 19, 2015 at 3:44 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Thanks! Who's tree should this go through?
Luis
^ 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