* 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
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: Bjorn Helgaas @ 2015-05-19 22:44 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mst, plagnioj, tomi.valkeinen, airlied, daniel.vetter,
linux-fbdev, luto, cocci, linux-kernel, linux-pci,
Luis R. Rodriguez, 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.wilk,
ville.syrjala, david.vrabel, jbeulich, Roger Pau Monné,
xen-devel
In-Reply-To: <1430415364-19679-1-git-send-email-mcgrof@do-not-panic.com>
On Thu, Apr 30, 2015 at 10:36:04AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This allows drivers to take advantage of write-combining
> when possible. The PCI specification does not allow for us
> to automatically identify a memory region which needs
> write-combining so drivers have to identify these areas
> on their own. There is IORESOURCE_PREFETCH but as clarified
> by Michael and confirmed later by Bjorn, PCI prefetch bit
> merely means bridges can combine writes and prefetch reads.
> Prefetch does not affect ordering rules and does not allow
> writes to be collapsed [0]. WC is stronger, it allows collapsing
> and changes ordering rules. WC can also hurt latency as small
> writes are buffered. Because of all this drivers needs to
> know what they are doing, we can't set a write-combining
> preference flag in the pci core automatically for drivers.
>
> Lastly although there is also arch_phys_wc_add() this makes
> use of architecture specific write-combining *hacks* and
> the only one currently defined and used is MTRR for x86.
> MTRRs are legacy, limited in number, have restrictive size
> constraints, and are known to interact pooly with the BIOS.
> MTRRs should only really be considered on old video framebuffer
> drivers. If we made ioremap_wc() and similar calls start
> automatically adding MTRRs, then performance will vary wildly
> with the order of driver loading because we'll run out of MTRRs
> part-way through bootup.
>
> There are a few motivations for phasing out of MTRR and
> helping driver change over to use write-combining with PAT:
>
> 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()")
>
> [0] https://lkml.org/lkml/2015/4/21/714
>
> Cc: Toshi Kani <toshi.kani@hp.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> 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: Dave Airlie <airlied@redhat.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Antonino Daplas <adaplas@gmail.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: venkatesh.pallipadi@intel.com
> Cc: Stefan Bader <stefan.bader@canonical.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: konrad.wilk@oracle.com
> Cc: ville.syrjala@linux.intel.com
> Cc: david.vrabel@citrix.com
> Cc: jbeulich@suse.com
> Cc: Roger Pau Monné <roger.pau@citrix.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-devel@lists.xensource.com
> Cc: linux-pci@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
>
> This v5 makes the code return NULL for IORESOURCE_IO and fixes the commit
> log to clarify the conclusions reached for MTRR and our review of
> IORESOURCE_PREFETCH.
>
> include/asm-generic/pci_iomap.h | 14 ++++++++++
> lib/pci_iomap.c | 61 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 75 insertions(+)
>
> diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
> index 7389c87..b1e17fc 100644
> --- a/include/asm-generic/pci_iomap.h
> +++ b/include/asm-generic/pci_iomap.h
> @@ -15,9 +15,13 @@ struct pci_dev;
> #ifdef CONFIG_PCI
> /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
> extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max);
> +extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long max);
> extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
> unsigned long offset,
> unsigned long maxlen);
> +extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
> + unsigned long offset,
> + unsigned long maxlen);
> /* Create a virtual mapping cookie for a port on a given PCI device.
> * Do not call this directly, it exists to make it easier for architectures
> * to override */
> @@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned lon
> return NULL;
> }
>
> +static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long max)
> +{
> + return NULL;
> +}
> static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
> unsigned long offset,
> unsigned long maxlen)
> {
> return NULL;
> }
> +static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
> + unsigned long offset,
> + unsigned long maxlen)
> +{
> + return NULL;
> +}
> #endif
>
> #endif /* __ASM_GENERIC_IO_H */
> diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
> index bcce5f1..9604dcb 100644
> --- a/lib/pci_iomap.c
> +++ b/lib/pci_iomap.c
> @@ -52,6 +52,46 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
> EXPORT_SYMBOL(pci_iomap_range);
>
> /**
> + * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
> + * @dev: PCI device that owns the BAR
> + * @bar: BAR number
> + * @offset: map memory at the given offset in BAR
> + * @maxlen: max length of the memory to map
> + *
> + * Using this function you will get a __iomem address to your device BAR.
> + * You can access it using ioread*() and iowrite*(). These functions hide
> + * the details if this is a MMIO or PIO address space and will just do what
> + * you expect from them in the correct way. When possible write combining
> + * is used.
> + *
> + * @maxlen specifies the maximum length to map. If you want to get access to
> + * the complete BAR from offset to the end, pass %0 here.
> + * */
> +void __iomem *pci_iomap_wc_range(struct pci_dev *dev,
> + int bar,
> + unsigned long offset,
> + unsigned long maxlen)
> +{
> + resource_size_t start = pci_resource_start(dev, bar);
> + resource_size_t len = pci_resource_len(dev, bar);
> + unsigned long flags = pci_resource_flags(dev, bar);
> +
> + if (len <= offset || !start)
> + return NULL;
> + len -= offset;
> + start += offset;
> + if (maxlen && len > maxlen)
> + len = maxlen;
> + if (flags & IORESOURCE_IO)
> + return NULL;
> + if (flags & IORESOURCE_MEM)
> + return ioremap_wc(start, len);
> + /* What? */
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(pci_iomap_wc_range);
> +
> +/**
> * pci_iomap - create a virtual mapping cookie for a PCI BAR
> * @dev: PCI device that owns the BAR
> * @bar: BAR number
> @@ -70,4 +110,25 @@ void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
> return pci_iomap_range(dev, bar, 0, maxlen);
> }
> EXPORT_SYMBOL(pci_iomap);
> +
> +/**
> + * pci_iomap_wc - create a virtual WC mapping cookie for a PCI BAR
> + * @dev: PCI device that owns the BAR
> + * @bar: BAR number
> + * @maxlen: length of the memory to map
> + *
> + * Using this function you will get a __iomem address to your device BAR.
> + * You can access it using ioread*() and iowrite*(). These functions hide
> + * the details if this is a MMIO or PIO address space and will just do what
> + * you expect from them in the correct way. When possible write combining
> + * is used.
> + *
> + * @maxlen specifies the maximum length to map. If you want to get access to
> + * the complete BAR without checking for its length first, pass %0 here.
> + * */
> +void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long maxlen)
> +{
> + return pci_iomap_wc_range(dev, bar, 0, maxlen);
> +}
> +EXPORT_SYMBOL_GPL(pci_iomap_wc);
> #endif /* CONFIG_PCI */
> --
> 2.3.2.209.gd67f9d5.dirty
>
^ permalink raw reply
* Re: [Cocci] [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Dave Airlie @ 2015-05-19 22:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150519175802.GJ23057@wotan.suse.de>
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?
Dave.
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Thierry Reding @ 2015-05-19 21:52 UTC (permalink / raw)
To: Kevin Hilman, Scot Doyle, Greg Kroah-Hartman
Cc: 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: <CAMAWPa88E2pfViKLXjxWHuT4ZkVhzYt_BsXGePzc-70ZrEmJFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2589 bytes --]
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.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Kevin Hilman @ 2015-05-19 21:45 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: <20150519214011.GA27047@ulmo.nvidia.com>
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>
Kevin
^ permalink raw reply
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Thierry Reding @ 2015-05-19 21:40 UTC (permalink / raw)
To: Kevin Hilman
Cc: Scot Doyle, Greg Kroah-Hartman, 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: <CAMAWPa-6ZbE5cDkEZq0XpYa2pHcnf3qweSSVHAXhfhUAUCbKcA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
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;
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH v2 2/3] fbcon: use the cursor blink interval provided by vt
From: Kevin Hilman @ 2015-05-19 21:15 UTC (permalink / raw)
To: Scot Doyle
Cc: Greg Kroah-Hartman, 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, Thierry Reding, Arnd Bergmann
In-Reply-To: <alpine.DEB.2.11.1503261354550.2411@local>
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.
Kevin
[1] http://storage.kernelci.org/next/next-20150519/arm-exynos_defconfig/lab-khilman/boot-exynos5800-peach-pi_rootfs:mmc.html
^ permalink raw reply
* Re: [Cocci] [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
From: Luis R. Rodriguez @ 2015-05-19 17:58 UTC (permalink / raw)
To: cocci
In-Reply-To: <20150514142645.GU23057@wotan.suse.de>
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
> > >>
> > >> Hey folks, these are all pretty straight forward, can anyone take them?
> > >
> > > I can take these to fbdev tree. Unfortunately I'm not familiar with x86
> > > nor mtrr, so I can't really say much about the patches themselves.
> > >
> >
> > I'm on vacation and there's no way I'll be able to usefully review
> > these in the next two weeks. I can describe what's going on in case
> > it helps:
> >
> > On x86 there are two ways to get a write-combining MMIO mapping. The
> > sane way is ioremap_wc, and the ridiculous way is mtrr_add.
> > ioremap_wc does exactly what it appears to do, whereas mtrr_add acts
> > on physical addresses, requires power-of-two alignment, and is
> > unreliable.
> >
> > On all recent hardware, ioremap_wc works, and mtrr_add is problematic
> > on all hardware even if it often works. The silly thing is that
> > mtrr_add pokes at the registers it uses even on hardware with working
> > ioremap_wc. This causes problems (those resources are a very limited
> > resource).
> >
> > The solution I came up with a couple years ago is a new API
> > arch_phys_wc_add. It is a hint that a physical address range should
> > be write-combining. On hardware with working ioremap_wc, it's a
> > no-op. On x86 hardware without working ioremap_wc, it just calls
> > mtrr_add.
> >
> > The upshot is that changing mtrr_add with a WC type to
> > arch_phys_wc_add is OK as long as the driver also uses ioremap_wc or
> > similar _wc APIs. Once everything has been converted, we can unexport
> > mtrr_add, which will have all kinds of benefits.
>
> 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.
Hey folks please let me know how I can be of any help with this. Not sure
what else I can do here to help further.
Luis
^ permalink raw reply
* Re: [PATCH v5 1/5] pci: add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-05-19 17:54 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: bhelgaas, mst, plagnioj, tomi.valkeinen, airlied, daniel.vetter,
linux-fbdev, luto, cocci, linux-kernel, linux-pci, 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.wilk, ville.syrjala,
david.vrabel, jbeulich, Roger Pau Monné, xen-devel
In-Reply-To: <1430415364-19679-1-git-send-email-mcgrof@do-not-panic.com>
On Thu, Apr 30, 2015 at 10:36:04AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
<-- snip -->
> ---
>
> This v5 makes the code return NULL for IORESOURCE_IO and fixes the commit
> log to clarify the conclusions reached for MTRR and our review of
> IORESOURCE_PREFETCH.
>
> include/asm-generic/pci_iomap.h | 14 ++++++++++
> lib/pci_iomap.c | 61 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 75 insertions(+)
Hey Bjorn, any feedack on this series? Thanks.
Luis
^ permalink raw reply
* Re: [PATCH v3 0/4] pci: add and use pci_ioremap_wc_bar()
From: Luis R. Rodriguez @ 2015-05-19 17:53 UTC (permalink / raw)
To: cocci
In-Reply-To: <CAB=NE6VYvd-Au58QRJprCquuvJkY9NYe1x8FmbW7qAhVrVE=QQ@mail.gmail.com>
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 ?
Luis
^ permalink raw reply
* Re: [PATCH v3 06/17] video: lcd: add LoCoMo LCD driver
From: Lee Jones @ 2015-05-19 12:34 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Russell King, Daniel Mack, Robert Jarzmik, Linus Walleij,
Alexandre Courbot, Wolfram Sang, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel, linux-gpio@vger.kernel.org,
linux-input, linux-leds, linux-spi, linux-fbdev
In-Reply-To: <CALT56yMwGngNvRWiCux962B=EQODUHW3=-ed6SZWJ9PnSPm09A@mail.gmail.com>
On Tue, 19 May 2015, Dmitry Eremin-Solenikov wrote:
> 2015-05-19 12:36 GMT+03:00 Lee Jones <lee.jones@linaro.org>:
> > On Sun, 17 May 2015, Dmitry Eremin-Solenikov wrote:
> >
> >> 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>
> >> ---
> >> 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
> >
> > This looks like it should be part of patch 16.
> >
> > How much of this file is the same as the one removed later in the set?
>
> This is a completely new driver. Only few comments remained from old
> locomolcd.c.
Okay, thanks for the explanation.
I'm sure Jingoo will be around to review shortly.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v3 01/17] mfd: add new driver for Sharp LoCoMo
From: Lee Jones @ 2015-05-19 12:33 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Dmitry Eremin-Solenikov, Daniel Mack, Robert Jarzmik,
Linus Walleij, Alexandre Courbot, Wolfram Sang, Dmitry Torokhov,
Bryan Wu, Richard Purdie, Samuel Ortiz, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel, linux-gpio, linux-input,
linux-leds, linux-spi, linux-fbdev, alsa-devel
In-Reply-To: <20150519112134.GD2067@n2100.arm.linux.org.uk>
On Tue, 19 May 2015, Russell King - ARM Linux wrote:
> On Tue, May 19, 2015 at 11:38:28AM +0100, Lee Jones wrote:
> > On Sun, 17 May 2015, Dmitry Eremin-Solenikov wrote:
> > > +static void locomo_mask_irq(struct irq_data *d)
> > > +{
> > > + struct locomo *ldev = irq_data_get_irq_chip_data(d);
> > > + unsigned int mask = 0x0010 << d->hwirq;
> >
> > This also needs defining.
> >
> > Why not
> > BIT(d->hwirq + 1)
>
> I think your maths is off...
>
> 0x0010 << d->hwirq != BIT(d->hwirq + 1)
Ah, that's hex. I was blinded by the 1's and 0's. Doh!
Thanks Russell.
---
Why not
BIT(d->hwirq + 4)
... with an explanation as to why you're skipping the first 4 bits?
/me hopes that maths is right now. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] video: exynos: fix modular build
From: Arnd Bergmann @ 2015-05-19 12:17 UTC (permalink / raw)
To: linux-arm-kernel
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>
diff --git a/drivers/video/fbdev/exynos/Kconfig b/drivers/video/fbdev/exynos/Kconfig
index 1f16b4678c71..d916bef94f25 100644
--- a/drivers/video/fbdev/exynos/Kconfig
+++ b/drivers/video/fbdev/exynos/Kconfig
@@ -3,7 +3,7 @@
#
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.
@@ -15,13 +15,13 @@ if EXYNOS_VIDEO
#
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
diff --git a/drivers/video/fbdev/exynos/Makefile b/drivers/video/fbdev/exynos/Makefile
index b5b1bd228abb..02d8dc522fea 100644
--- a/drivers/video/fbdev/exynos/Makefile
+++ b/drivers/video/fbdev/exynos/Makefile
@@ -2,6 +2,8 @@
# Makefile for the exynos video drivers.
#
-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
obj-$(CONFIG_EXYNOS_LCD_S6E8AX0) += s6e8ax0.o
diff --git a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
index b527fe464628..18edc724bf57 100644
--- a/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/fbdev/exynos/exynos_mipi_dsi.c
@@ -263,6 +263,7 @@ int exynos_mipi_dsi_register_lcd_driver(struct mipi_dsim_lcd_driver *lcd_drv)
return 0;
}
+EXPORT_SYMBOL_GPL(exynos_mipi_dsi_register_lcd_driver);
static struct mipi_dsim_ddi *exynos_mipi_dsi_bind_lcd_ddi(
struct mipi_dsim_device *dsim,
^ permalink raw reply related
* Re: [PATCH v3 01/17] mfd: add new driver for Sharp LoCoMo
From: Russell King - ARM Linux @ 2015-05-19 11:21 UTC (permalink / raw)
To: Lee Jones
Cc: Dmitry Eremin-Solenikov, Daniel Mack, Robert Jarzmik,
Linus Walleij, Alexandre Courbot, Wolfram Sang, Dmitry Torokhov,
Bryan Wu, Richard Purdie, Samuel Ortiz, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw
In-Reply-To: <20150519103828.GU22418@x1>
On Tue, May 19, 2015 at 11:38:28AM +0100, Lee Jones wrote:
> On Sun, 17 May 2015, Dmitry Eremin-Solenikov wrote:
> > +static void locomo_mask_irq(struct irq_data *d)
> > +{
> > + struct locomo *ldev = irq_data_get_irq_chip_data(d);
> > + unsigned int mask = 0x0010 << d->hwirq;
>
> This also needs defining.
>
> Why not
> BIT(d->hwirq + 1)
I think your maths is off...
0x0010 << d->hwirq != BIT(d->hwirq + 1)
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH v3 06/17] video: lcd: add LoCoMo LCD driver
From: Dmitry Eremin-Solenikov @ 2015-05-19 9:45 UTC (permalink / raw)
To: 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, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel, linux-gpio@vger.kernel.org,
linux-input, linux-leds, linux-spi, linux-fbdev
In-Reply-To: <20150519093644.GT22418@x1>
2015-05-19 12:36 GMT+03:00 Lee Jones <lee.jones@linaro.org>:
> On Sun, 17 May 2015, Dmitry Eremin-Solenikov wrote:
>
>> 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>
>> ---
>> 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
>
> This looks like it should be part of patch 16.
>
> How much of this file is the same as the one removed later in the set?
This is a completely new driver. Only few comments remained from old
locomolcd.c.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 06/17] video: lcd: add LoCoMo LCD driver
From: Lee Jones @ 2015-05-19 9:36 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Russell King, Daniel Mack, Robert Jarzmik, Linus Walleij,
Alexandre Courbot, Wolfram Sang, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel, linux-gpio, linux-input,
linux-leds, linux-spi, linux-fbdev, alsa-devel
In-Reply-To: <1431880077-26321-7-git-send-email-dbaryshkov@gmail.com>
On Sun, 17 May 2015, Dmitry Eremin-Solenikov wrote:
> 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>
> ---
> 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
This looks like it should be part of patch 16.
How much of this file is the same as the one removed later in the set?
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 6c093e2..b2f995c 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -48,6 +48,16 @@ config LCD_LMS283GF05
> SPI driver for Samsung LMS283GF05. This provides basic support
> for powering the LCD up/down through a sysfs interface.
>
> +config LCD_LOCOMO
> + tristate "Sharp LOCOMO LCD Driver"
> + depends on MFD_LOCOMO
> + select IIO
> + help
> + If you have a Sharp Zaurus SL-5500 (Collie) or SL-5600 (Poodle) say y to
> + enable the LCD driver. The panel starts up in power
> + off state, so you need this driver in order to see any
> + output.
> +
> config LCD_LTV350QV
> tristate "Samsung LTV350QV LCD Panel"
> depends on SPI_MASTER
> diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
> index 2de73d2..686cf1a 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_LCD_L4F00242T03) += l4f00242t03.o
> obj-$(CONFIG_LCD_LD9040) += ld9040.o
> obj-$(CONFIG_LCD_LMS283GF05) += lms283gf05.o
> obj-$(CONFIG_LCD_LMS501KF03) += lms501kf03.o
> +obj-$(CONFIG_LCD_LOCOMO) += locomo_lcd.o
> obj-$(CONFIG_LCD_LTV350QV) += ltv350qv.o
> obj-$(CONFIG_LCD_PLATFORM) += platform_lcd.o
> obj-$(CONFIG_LCD_S6E63M0) += s6e63m0.o
> diff --git a/drivers/video/backlight/locomo_lcd.c b/drivers/video/backlight/locomo_lcd.c
> new file mode 100644
> index 0000000..dc316cb
> --- /dev/null
> +++ b/drivers/video/backlight/locomo_lcd.c
> @@ -0,0 +1,285 @@
> +/*
> + * Backlight control code for Sharp Zaurus SL-5500
> + *
> + * Copyright 2005 John Lenz <lenz@cs.wisc.edu>
> + * Maintainer: Pavel Machek <pavel@ucw.cz> (unless John wants to :-)
> + * GPL v2
> + *
> + * This driver assumes single CPU. That's okay, because collie is
> + * slightly old hardware, and no one is going to retrofit second CPU to
> + * old PDA.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/fb.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/iio/consumer.h>
> +#include <linux/lcd.h>
> +#include <linux/mfd/locomo.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +struct locomo_lcd {
> + struct regmap *regmap;
> + struct platform_device *dev;
> + struct locomo_lcd_platform_data *data;
> + int power;
> + struct iio_channel *comadj;
> + struct gpio_desc *vsha, *vshd, *vee, *mod;
> +};
> +
> +static void locomo_lcd_on(struct locomo_lcd *lcd)
> +{
> + gpiod_set_value(lcd->vsha, 1);
> + usleep_range(2000, 3000);
> +
> + gpiod_set_value(lcd->vshd, 1);
> + usleep_range(2000, 3000);
> +
> + iio_write_channel_raw(lcd->comadj, lcd->data->comadj);
> + usleep_range(5000, 6000);
> +
> + gpiod_set_value(lcd->vee, 1);
> + usleep_range(10000, 11000);
> +
> + /* TFTCRST | CPSOUT=0 | CPSEN */
> + regmap_write(lcd->regmap, LOCOMO_TC, 0x01);
> +
> + /* Set CPSD */
> + regmap_write(lcd->regmap, LOCOMO_CPSD, 6);
> +
> + /* TFTCRST | CPSOUT=0 | CPSEN */
> + regmap_write(lcd->regmap, LOCOMO_TC, 0x04 | 0x01);
> + usleep_range(10000, 11000);
> +
> + gpiod_set_value(lcd->mod, 1);
> +}
> +
> +static void locomo_lcd_off(struct locomo_lcd *lcd)
> +{
> + /* TFTCRST=1 | CPSOUT=1 | CPSEN = 0 */
> + regmap_write(lcd->regmap, LOCOMO_TC, 0x06);
> + usleep_range(1000, 2000);
> +
> + gpiod_set_value(lcd->vsha, 0);
> + msleep(110);
> +
> + gpiod_set_value(lcd->vee, 0);
> + msleep(700);
> +
> + iio_write_channel_raw(lcd->comadj, 0);
> + usleep_range(5000, 6000);
> +
> + /* TFTCRST=0 | CPSOUT=0 | CPSEN = 0 */
> + regmap_write(lcd->regmap, LOCOMO_TC, 0);
> + gpiod_set_value(lcd->mod, 0);
> + gpiod_set_value(lcd->vshd, 0);
> +}
> +
> +static void locomo_lcd_program_adsync(struct locomo_lcd *lcd)
> +{
> + regmap_write(lcd->regmap, LOCOMO_ASD,
> + 6 + 8 + 320 + 30 - 10);
> + regmap_update_bits(lcd->regmap, LOCOMO_ASD,
> + 0x8000,
> + 0x8000);
> +
> + regmap_write(lcd->regmap, LOCOMO_HSD,
> + 6 + 8 + 320 + 30 - 10 - 128 + 4);
> + regmap_update_bits(lcd->regmap, LOCOMO_HSD,
> + 0x8000,
> + 0x8000);
> +
> + regmap_write(lcd->regmap, LOCOMO_HSC, 128 / 8);
> +
> + /* XON */
> + regmap_write(lcd->regmap, LOCOMO_TADC, 0x80);
> + usleep_range(1000, 1100);
> +
> + /* CLK9MEN */
> + regmap_update_bits(lcd->regmap, LOCOMO_TADC,
> + 0x10,
> + 0x10);
> + usleep_range(100, 200);
> +}
> +
> +static void locomo_lcd_disable_adsync(struct locomo_lcd *lcd)
> +{
> + /* ADSTART */
> + regmap_write(lcd->regmap, LOCOMO_ASD, 0x00);
> +
> + /* 18MHz clock off*/
> + regmap_write(lcd->regmap, LOCOMO_TADC, 0x00);
> +}
> +
> +int locomo_lcd_set_power(struct lcd_device *ldev, int power)
> +{
> + struct locomo_lcd *lcd = lcd_get_data(ldev);
> +
> + dev_dbg(&ldev->dev, "LCD power %d (is %d)\n", power, lcd->power);
> +
> + if (!power && lcd->power)
> + locomo_lcd_on(lcd);
> +
> + if (power && !lcd->power)
> + locomo_lcd_off(lcd);
> +
> + lcd->power = power;
> +
> + return 0;
> +}
> +
> +static int locomo_lcd_get_power(struct lcd_device *ldev)
> +{
> + struct locomo_lcd *lcd = lcd_get_data(ldev);
> +
> + return lcd->power;
> +}
> +
> +static struct lcd_ops locomo_lcd_ops = {
> + .set_power = locomo_lcd_set_power,
> + .get_power = locomo_lcd_get_power,
> +};
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int locomo_lcd_suspend(struct device *dev)
> +{
> + struct lcd_device *ldev = dev_get_drvdata(dev);
> + struct locomo_lcd *lcd = lcd_get_data(ldev);
> +
> + locomo_lcd_off(lcd);
> +
> + locomo_lcd_disable_adsync(lcd);
> +
> + return 0;
> +}
> +
> +static int locomo_lcd_resume(struct device *dev)
> +{
> + struct lcd_device *ldev = dev_get_drvdata(dev);
> + struct locomo_lcd *lcd = lcd_get_data(ldev);
> +
> + locomo_lcd_program_adsync(lcd);
> +
> + if (!lcd->power)
> + locomo_lcd_on(lcd);
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(locomo_lcd_pm, locomo_lcd_suspend, locomo_lcd_resume);
> +#define LOCOMOLCD_PM (&locomo_lcd_pm)
> +#else
> +#define LOCOMOLCD_PM NULL
> +#endif
> +
> +static int locomo_lcd_probe(struct platform_device *dev)
> +{
> + struct lcd_device *lcd_dev;
> + struct locomo_lcd *lcd;
> + int rc;
> +
> + lcd = devm_kmalloc(&dev->dev, sizeof(struct locomo_lcd), GFP_KERNEL);
> + if (!lcd)
> + return -ENOMEM;
> +
> + lcd->dev = dev;
> + lcd->power = FB_BLANK_NORMAL;
> +
> + lcd->regmap = dev_get_regmap(dev->dev.parent, NULL);
> + if (!lcd->regmap)
> + return -ENODEV;
> +
> + lcd->data = dev_get_platdata(&dev->dev);
> + if (!lcd->data)
> + return -EINVAL;
> +
> + lcd->vsha = devm_gpiod_get(&dev->dev, "VSHA", GPIOD_OUT_LOW);
> + if (IS_ERR(lcd->vsha))
> + return PTR_ERR(lcd->vsha);
> +
> + lcd->vshd = devm_gpiod_get(&dev->dev, "VSHD", GPIOD_OUT_LOW);
> + if (IS_ERR(lcd->vshd))
> + return PTR_ERR(lcd->vshd);
> +
> + lcd->vee = devm_gpiod_get(&dev->dev, "Vee", GPIOD_OUT_LOW);
> + if (IS_ERR(lcd->vee))
> + return PTR_ERR(lcd->vee);
> +
> + lcd->mod = devm_gpiod_get(&dev->dev, "MOD", GPIOD_OUT_LOW);
> + if (IS_ERR(lcd->mod))
> + return PTR_ERR(lcd->mod);
> +
> + lcd->comadj = iio_channel_get(&dev->dev, "comadj");
> + if (IS_ERR(lcd->comadj)) {
> + rc = PTR_ERR(lcd->comadj);
> + if (rc = -ENODEV)
> + rc = -EPROBE_DEFER;
> +
> + return rc;
> + }
> +
> + locomo_lcd_program_adsync(lcd);
> +
> + lcd_dev = devm_lcd_device_register(&dev->dev, "locomo", &dev->dev, lcd,
> + &locomo_lcd_ops);
> + if (IS_ERR(lcd_dev)) {
> + rc = PTR_ERR(lcd_dev);
> + goto err;
> + }
> +
> + platform_set_drvdata(dev, lcd_dev);
> +
> + lcd_set_power(lcd_dev, FB_BLANK_UNBLANK);
> +
> + return 0;
> +
> +err:
> + locomo_lcd_disable_adsync(lcd);
> + iio_channel_release(lcd->comadj);
> +
> + return rc;
> +}
> +
> +static int locomo_lcd_remove(struct platform_device *dev)
> +{
> + struct lcd_device *ldev = platform_get_drvdata(dev);
> + struct locomo_lcd *lcd = lcd_get_data(ldev);
> +
> + locomo_lcd_off(lcd);
> +
> + locomo_lcd_disable_adsync(lcd);
> +
> + iio_channel_release(lcd->comadj);
> +
> + return 0;
> +}
> +
> +static void locomo_lcd_shutdown(struct platform_device *dev)
> +{
> + struct lcd_device *ldev = platform_get_drvdata(dev);
> + struct locomo_lcd *lcd = lcd_get_data(ldev);
> +
> + locomo_lcd_off(lcd);
> +
> + locomo_lcd_disable_adsync(lcd);
> +}
> +
> +static struct platform_driver locomo_lcd_driver = {
> + .driver = {
> + .name = "locomo-lcd",
> + .pm = LOCOMOLCD_PM,
> + },
> + .probe = locomo_lcd_probe,
> + .remove = locomo_lcd_remove,
> + .shutdown = locomo_lcd_shutdown,
> +};
> +
> +module_platform_driver(locomo_lcd_driver);
> +
> +MODULE_AUTHOR("John Lenz <lenz@cs.wisc.edu>");
> +MODULE_AUTHOR("Pavel Machek <pavel@ucw.cz>");
> +MODULE_DESCRIPTION("LoCoMo LCD driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:locomo-lcd");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] backlight: pwm_bl: Simplify usage of devm_gpiod_get_optional
From: Axel Lin @ 2015-05-19 9:18 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-pwm, linux-fbdev, Thierry Reding, Alexandre Courbot,
Jingoo Han, Lee Jones
In-Reply-To: <20150519075908.GA23505@pengutronix.de>
2015-05-19 15:59 GMT+08:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hello,
>
> On Sat, May 16, 2015 at 10:08:10PM +0800, Axel Lin wrote:
>> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions),
>> the gpiod_get* functions take an additional parameter that allows to
>> specify direction and initial value for output.
>> Simplify the usage of devm_gpiod_get_optional accordingly.
>>
>> Signed-off-by: Axel Lin <axel.lin@ingics.com>
> as I just sent the same patch:
>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> @Axel: Do you have some more patches of this type in the queue? I
No, I don't have other patches of this type in the queue.
Regards,
Axel
^ permalink raw reply
* Re: [PATCH] backlight: pwm_bl: Simplify usage of devm_gpiod_get_optional
From: Uwe Kleine-König @ 2015-05-19 7:59 UTC (permalink / raw)
To: Axel Lin
Cc: linux-pwm, linux-fbdev, Thierry Reding, Alexandre Courbot,
Jingoo Han, Lee Jones
In-Reply-To: <1431785290.6638.1.camel@ingics.com>
Hello,
On Sat, May 16, 2015 at 10:08:10PM +0800, Axel Lin wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions),
> the gpiod_get* functions take an additional parameter that allows to
> specify direction and initial value for output.
> Simplify the usage of devm_gpiod_get_optional accordingly.
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
as I just sent the same patch:
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
@Axel: Do you have some more patches of this type in the queue? I
currently have several fixes on top of 4.1-rc4. Some of them are still
in a single wip patch, some other are already sent out.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] backlight: pwm: make use of 3rd argument to devm_gpiod_get_optional
From: Jingoo Han @ 2015-05-18 23:15 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1431983162-21494-1-git-send-email-u.kleine-koenig@pengutronix.de>
On Tuesday, May 19, 2015 6:06 AM, 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.
>
> This allows to drop the explicit setting of direction.
>
> Furthermore this is one caller less that stops us making the 3rd
> argument mandatory.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+cc Axel Lin
Hi Uwe Kleine-König,
The same patch was already sent by Axel Lin 3 days ago.
Anyway, thank you for sending the patch.
Best regards,
Jingoo Han
> ---
> drivers/video/backlight/pwm_bl.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 3a145a643e0d..57cb9ec8be43 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -241,7 +241,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> pb->dev = &pdev->dev;
> pb->enabled = false;
>
> - pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable");
> + pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
> + GPIOD_OUT_HIGH);
> if (IS_ERR(pb->enable_gpio)) {
> ret = PTR_ERR(pb->enable_gpio);
> goto err_alloc;
> @@ -263,9 +264,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> pb->enable_gpio = gpio_to_desc(data->enable_gpio);
> }
>
> - if (pb->enable_gpio)
> - gpiod_direction_output(pb->enable_gpio, 1);
> -
> pb->power_supply = devm_regulator_get(&pdev->dev, "power");
> if (IS_ERR(pb->power_supply)) {
> ret = PTR_ERR(pb->power_supply);
> --
> 2.1.4
^ permalink raw reply
* [PATCH] backlight: pwm: make use of 3rd argument to devm_gpiod_get_optional
From: Uwe Kleine-König @ 2015-05-18 21:06 UTC (permalink / raw)
To: linux-fbdev
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.
This allows to drop the explicit setting of direction.
Furthermore this is one caller less that stops us making the 3rd
argument mandatory.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/video/backlight/pwm_bl.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 3a145a643e0d..57cb9ec8be43 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -241,7 +241,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->dev = &pdev->dev;
pb->enabled = false;
- pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable");
+ pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
+ GPIOD_OUT_HIGH);
if (IS_ERR(pb->enable_gpio)) {
ret = PTR_ERR(pb->enable_gpio);
goto err_alloc;
@@ -263,9 +264,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->enable_gpio = gpio_to_desc(data->enable_gpio);
}
- if (pb->enable_gpio)
- gpiod_direction_output(pb->enable_gpio, 1);
-
pb->power_supply = devm_regulator_get(&pdev->dev, "power");
if (IS_ERR(pb->power_supply)) {
ret = PTR_ERR(pb->power_supply);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/1 linux-next] video: fbdev: use swap() in ami_set_sprite()
From: Geert Uytterhoeven @ 2015-05-18 20:16 UTC (permalink / raw)
To: Fabian Frederick
Cc: linux-kernel@vger.kernel.org, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Linux Fbdev development list
In-Reply-To: <1431970330-16443-1-git-send-email-fabf@skynet.be>
On Mon, May 18, 2015 at 7:32 PM, Fabian Frederick <fabf@skynet.be> wrote:
> Use kernel.h macro definition.
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
* [PATCH 1/1 linux-next] video/console: use swap() in newport_bmove()
From: Fabian Frederick @ 2015-05-18 17:43 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
Use kernel.h macro definition.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
drivers/video/console/newport_con.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/console/newport_con.c b/drivers/video/console/newport_con.c
index a6ab929..bb4e962 100644
--- a/drivers/video/console/newport_con.c
+++ b/drivers/video/console/newport_con.c
@@ -687,7 +687,7 @@ static int newport_scroll(struct vc_data *vc, int t, int b, int dir,
static void newport_bmove(struct vc_data *vc, int sy, int sx, int dy,
int dx, int h, int w)
{
- short xs, ys, xe, ye, xoffs, yoffs, tmp;
+ short xs, ys, xe, ye, xoffs, yoffs;
xs = sx << 3;
xe = ((sx + w) << 3) - 1;
@@ -701,9 +701,7 @@ static void newport_bmove(struct vc_data *vc, int sy, int sx, int dy,
yoffs = (dy - sy) << 4;
if (xoffs > 0) {
/* move to the right, exchange starting points */
- tmp = xe;
- xe = xs;
- xs = tmp;
+ swap(xe, xs);
}
newport_wait(npregs);
npregs->set.drawmode0 = (NPORT_DMODE0_S2S | NPORT_DMODE0_BLOCK |
--
2.4.0
^ permalink raw reply related
* [PATCH 1/1 linux-next] video: fbdev: use swap() in ami_set_sprite()
From: Fabian Frederick @ 2015-05-18 17:32 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
Use kernel.h macro definition.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
drivers/video/fbdev/amifb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/amifb.c b/drivers/video/fbdev/amifb.c
index 35f7900..a171bd9 100644
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -2052,7 +2052,7 @@ static void ami_set_sprite(const struct amifb_par *par)
{
copins *copl, *cops;
u_short hs, vs, ve;
- u_long pl, ps, pt;
+ u_long pl, ps;
short mx, my;
cops = copdisplay.list[currentcop][0];
@@ -2078,7 +2078,7 @@ static void ami_set_sprite(const struct amifb_par *par)
if (mod2(vs)) {
lofsprite[1 << par->crsr.fmode] = spr2hw_ctl(vs, hs, ve);
shfsprite[1 << par->crsr.fmode] = spr2hw_ctl(vs + 1, hs, ve + 1);
- pt = pl; pl = ps; ps = pt;
+ swap(pl, ps);
} else {
lofsprite[1 << par->crsr.fmode] = spr2hw_ctl(vs, hs, ve + 1);
shfsprite[1 << par->crsr.fmode] = spr2hw_ctl(vs + 1, hs, ve);
--
2.4.0
^ permalink raw reply related
* [PATCH 1/1 linux-next] video: fbdev: matrox: use swap() in matroxfb_decode_var()
From: Fabian Frederick @ 2015-05-18 17:31 UTC (permalink / raw)
To: linux-kernel
Cc: Fabian Frederick, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
Use kernel.h macro definition.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
drivers/video/fbdev/matrox/matroxfb_base.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c b/drivers/video/fbdev/matrox/matroxfb_base.c
index 62539ca..2ba4e54 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -591,12 +591,8 @@ static int matroxfb_decode_var(const struct matrox_fb_info *minfo,
unsigned int max_yres;
while (m1) {
- int t;
-
while (m2 >= m1) m2 -= m1;
- t = m1;
- m1 = m2;
- m2 = t;
+ swap(m1, m2);
}
m2 = linelen * PAGE_SIZE / m2;
*ydstorg = m2 = 0x400000 % m2;
--
2.4.0
^ permalink raw reply related
* Re: [PATCH v3 04/17] input: make LoCoMo keyboard driver support both poodle and collie
From: Dmitry Torokhov @ 2015-05-18 16:50 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Russell King, Daniel Mack, Robert Jarzmik, Linus Walleij,
Alexandre Courbot, Wolfram Sang, Bryan Wu, Richard Purdie,
Samuel Ortiz, Lee Jones, Mark Brown, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Liam Girdwood,
Andrea Adami, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw
In-Reply-To: <1431880077-26321-5-git-send-email-dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sun, May 17, 2015 at 07:27:44PM +0300, Dmitry Eremin-Solenikov wrote:
> Keyboards on collie and poodle differ only in wiring of 'Home' key.
> Instead of complicating the driver with platform data, just check for
> the machine for the time being. This will be converted to DTS property
> sometime in the future.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/keyboard/locomokbd.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/locomokbd.c b/drivers/input/keyboard/locomokbd.c
> index 1657bc0..b422608 100644
> --- a/drivers/input/keyboard/locomokbd.c
> +++ b/drivers/input/keyboard/locomokbd.c
> @@ -33,6 +33,9 @@
> #include <linux/slab.h>
> #include <linux/mfd/locomo.h>
>
> +/* There is one minor difference between mappings on poodle and collie */
> +#include <asm/mach-types.h>
> +
> #define KEY_ACTIVITY KEY_F16
> #define KEY_CONTACT KEY_F18
> #define KEY_CENTER KEY_F15
> @@ -45,7 +48,7 @@
> static const unsigned char
> locomokbd_keycode[LOCOMOKBD_NUMKEYS] = {
> 0, KEY_ESC, KEY_ACTIVITY, 0, 0, 0, 0, 0, 0, 0, /* 0 - 9 */
> - 0, 0, 0, 0, 0, 0, 0, KEY_MENU, KEY_HOME, KEY_CONTACT, /* 10 - 19 */
> + 0, 0, 0, 0, 0, 0, 0, KEY_MENU, 0, KEY_CONTACT, /* 10 - 19 */
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 20 - 29 */
> 0, 0, 0, KEY_CENTER, 0, KEY_MAIL, 0, 0, 0, 0, /* 30 - 39 */
> 0, 0, 0, 0, 0, 0, 0, 0, 0, KEY_RIGHT, /* 40 - 49 */
> @@ -278,6 +281,11 @@ static int locomokbd_probe(struct platform_device *dev)
> locomokbd_keycode,
> sizeof(locomokbd->keycode));
>
> + if (machine_is_collie())
> + locomokbd->keycode[18] = KEY_HOME;
> + else
> + locomokbd->keycode[3] = KEY_HOME;
> +
> for (i = 0; i < LOCOMOKBD_NUMKEYS; i++)
> input_set_capability(input_dev, EV_KEY, locomokbd->keycode[i]);
> input_set_capability(input_dev, EV_PWR, KEY_SUSPEND);
> --
> 2.1.4
>
--
Dmitry
^ 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