* Re: [RFC PATCH 16/15] pwm: add informations about polarity, duty cycle and period to debugfs
From: Boris Brezillon @ 2015-07-02 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3365087.n2eEES60JK@diego>
On Wed, 01 Jul 2015 23:50:46 +0200
Heiko Stübner <heiko@sntech.de> wrote:
> The pwm-states make it possible to also output the polarity, duty cycle
> and period information in the debugfs pwm summary-outout.
> This makes it easier to gather overview information about pwms without
> needing to walk through the sysfs attributes of every pwm.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> might be nice to have too ;-)
Yes.
>
> drivers/pwm/core.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 6dafd8e..79037a2 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -951,9 +951,18 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
> if (test_bit(PWMF_REQUESTED, &pwm->flags))
> seq_puts(s, " requested");
>
> - if (pwm_is_enabled(pwm))
> + if (pwm_is_enabled(pwm)) {
> seq_puts(s, " enabled");
>
> + seq_printf(s, " period:%uns",
> + pwm_get_period(pwm));
> + seq_printf(s, " duty:%uns",
> + pwm_get_duty_cycle(pwm));
> + seq_printf(s, " polarity:%s",
> + pwm_get_polarity(pwm) ? "inverse"
> + : "normal");
I would print those values even if the PWM is not enabled.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants
From: Luis R. Rodriguez @ 2015-07-02 18:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Casey Leedom, Arnd Bergmann, Michael S. Tsirkin, Bjorn Helgaas,
Toshi Kani, Andy Lutomirski, Juergen Gross, Tomi Valkeinen,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
xen-devel@lists.xensource.com, linux-fbdev, Suresh Siddha,
Ingo Molnar, Thomas Gleixner, Daniel Vetter, Dave Airlie,
Antonino Daplas, Jean-Christophe Plagniol-Villard, Dave Hansen,
venkatesh.pallipadi@intel.com, Stefan Bader,
ville.syrjala@linux.intel.com, David Vrabel, Jan Beulich,
Roger Pau Monné
In-Reply-To: <1435356048.26815.9.camel@kernel.crashing.org>
On Sat, Jun 27, 2015 at 08:00:48AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2015-06-26 at 16:24 +0000, Casey Leedom wrote:
> > Thanks for looking into this Ben. As it stands now, it seems as
> > if Write Combined mappings simply aren't supported and/or all
> > driver writers trying to utilize Write Combined mappings have to
> > "hand roll" their own solutions which really isn't supportable.
> >
> > One thing that might be considered is simply to treat the desire
> > to utilize the Write Combining hardware as a separate issue and
> > develop writel_wc(), writeq_wc(), etc.
That seems rather sloppy and cumbersome, its best to just provide the
infrastructure for initial mapping for an area and let the hardware do it for
you. With the current design drivers would just use regular read/write on all
areas and the only thing that will set them apart will be the mapping. With
what you propose we'd end up having to shift a whole bunch of reads/writes for
just the purpose of adding WC to an area that didn't have wc before. That's
a waste of code and time.
> > Those could be defined
> > as legal only for Write Combined Mappings and would "do the
> > right thing" for each architecture.
Yuck.
> The question then is what is "the right thing". In the powerpc case,
> we'll have a non-garded mapping, which means we also get no ordering
> between load and stores.
I don't follow, you *ordering* between load and stores for WC? We should
not need that for WC, its why WC is used for only very specific things
such as framebuffer and PIO (which BTw I still don't quite get all this
use case for infiniband to be honest, and I will note I do see some
proprietary hardware extensions like bursts but nothing covering all
this in a general doc, I think I think it all just has to do that this
is a hardware hack in reality, which we sell as a feature).
Luis
^ permalink raw reply
* Re: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants
From: Benjamin Herrenschmidt @ 2015-07-02 22:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Casey Leedom, Arnd Bergmann, Michael S. Tsirkin, Bjorn Helgaas,
Toshi Kani, Andy Lutomirski, Juergen Gross, Tomi Valkeinen,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
xen-devel@lists.xensource.com, linux-fbdev, Suresh Siddha,
Ingo Molnar, Thomas Gleixner, Daniel Vetter, Dave Airlie,
Antonino Daplas, Jean-Christophe Plagniol-Villard, Dave Hansen,
venkatesh.pallipadi@intel.com, Stefan Bader,
ville.syrjala@linux.intel.com, David Vrabel, Jan Beulich,
Roger Pau Monné
In-Reply-To: <20150702184904.GA7021@wotan.suse.de>
On Thu, 2015-07-02 at 20:49 +0200, Luis R. Rodriguez wrote:
> > The question then is what is "the right thing". In the powerpc case,
> > we'll have a non-garded mapping, which means we also get no ordering
> > between load and stores.
>
> I don't follow, you *ordering* between load and stores for WC? We should
> not need that for WC, its why WC is used for only very specific things
> such as framebuffer and PIO (which BTw I still don't quite get all this
> use case for infiniband to be honest, and I will note I do see some
> proprietary hardware extensions like bursts but nothing covering all
> this in a general doc, I think I think it all just has to do that this
> is a hardware hack in reality, which we sell as a feature).
Well, that's the problem, the semantics that we provide to drivers
aren't well defined.
The words "write combine" themselves only specify that writes to subsequent
addresses can be combined into larger transactions. That's in itself is already
quite vague (are their boundaries, limits ? some can depend on bus type, etc...)
though in practice is probably sufficient.
However, overloading a _wc mapping with additional memory model differences
such as loss of ordering between load and stores, etc... is not an obvious
thing to do. I agree it would make *my* life easier if we did it since this
is precisely the semantics provided by a "G=0" mapping on ppc, but we need
to agree and *document* it, otherwise bad things will happen eventually.
We also need to document in that case which barriers can be used to explicitly
enforce the ordering on such a mapping and which barriers can be used to break
write combine (they don't necessarily have to be the same).
We also need to document which accessors will actually provide the write combine
"feature" of a _wc mapping. For example while writel() will do it on Intel, it
will not on ppc and I wouldn't be surprised if a bunch of other archs fall in
the same bucket as ppc (basically anything that has barriers in their writel
implementation to order vs. DMA etc...).
So we might need to explicitly document that writel_relaxed() needs to be used.
Finally what are the precise guaranteed semantics of writeX/readX,
writeX_relaxed/readX_relaxed and __raw_ (everything else) on a _wc mapping, what
do we mandate and document, what do we leave to be implementation dependent ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 1/3] video: fbdev: atyfb: clarify ioremap() base and length used
From: Luis R. Rodriguez @ 2015-07-02 23:23 UTC (permalink / raw)
To: Borislav Petkov
Cc: Ville Syrjälä, Andrew Morton, Ingo Molnar,
Ville Syrjälä, Andy Lutomirski, Tomi Valkeinen,
Michael S. Tsirkin, Benjamin Herrenschmidt,
linux-kernel@vger.kernel.org, linux-fbdev,
linux-pci@vger.kernel.org, Dave Airlie, Toshi Kani, Suresh Siddha,
Linus Torvalds, Thomas Gleixner, Juergen Gross, Daniel Vetter,
Antonino Daplas, Jean-Christophe Plagniol-Villard, Rob Clark,
Mathias Krause, Andrzej Hajda, Mel Gorman, Vlastimil Babka,
Davidlohr Bueso
In-Reply-To: <20150626073028.GA14776@pd.tnic>
On Fri, Jun 26, 2015 at 12:30 AM, Borislav Petkov <bp@suse.de> wrote:
> On Fri, Jun 26, 2015 at 03:09:27AM +0200, Luis R. Rodriguez wrote:
>> Sure, mind this as a follow up patch if its too late?
>
> No need, you can send me an updated one - I'll replace it.
Will do!
Luis
^ permalink raw reply
* Re: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants
From: Casey Leedom @ 2015-07-03 0:14 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Benjamin Herrenschmidt, Arnd Bergmann, Michael S. Tsirkin,
Bjorn Helgaas, Toshi Kani, Andy Lutomirski, Juergen Gross,
Tomi Valkeinen, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
linux-fbdev, Suresh Siddha, Ingo Molnar, Thomas Gleixner,
Daniel Vetter, Dave Airlie, Antonino Daplas,
Jean-Christophe Plagniol-Villard, Dave Hansen,
venkatesh.pallipadi@intel.com, Stefan Bader,
ville.syrjala@linux.intel.com, David Vrabel, Jan Beulich,
Roger Pau Monné
In-Reply-To: <20150702184904.GA7021@wotan.suse.de>
> On Jul 2, 2015, at 11:49 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>
> On Sat, Jun 27, 2015 at 08:00:48AM +1000, Benjamin Herrenschmidt wrote:
>> On Fri, 2015-06-26 at 16:24 +0000, Casey Leedom wrote:
>>> Thanks for looking into this Ben. As it stands now, it seems as
>>> if Write Combined mappings simply aren't supported and/or all
>>> driver writers trying to utilize Write Combined mappings have to
>>> "hand roll" their own solutions which really isn't supportable.
>>>
>>> One thing that might be considered is simply to treat the desire
>>> to utilize the Write Combining hardware as a separate issue and
>>> develop writel_wc(), writeq_wc(), etc.
>
> That seems rather sloppy and cumbersome, its best to just provide the
> infrastructure for initial mapping for an area and let the hardware do it for
> you. With the current design drivers would just use regular read/write on all
> areas and the only thing that will set them apart will be the mapping. With
> what you propose we'd end up having to shift a whole bunch of reads/writes for
> just the purpose of adding WC to an area that didn't have wc before. That's
> a waste of code and time.
>
>>> Those could be defined
>>> as legal only for Write Combined Mappings and would "do the
>>> right thing" for each architecture.
>
> Yuck.
Yeah, probably. But it sounds like from Ben’s response, we should really use write_relaxed() as an already existing API for this. But most of the architectures just define this as writel() so some work would need to be done to get it to work.
>> The question then is what is "the right thing". In the powerpc case,
>> we'll have a non-garded mapping, which means we also get no ordering
>> between load and stores.
>
> I don't follow, you *ordering* between load and stores for WC? We should
> not need that for WC, its why WC is used for only very specific things
> such as framebuffer and PIO (which BTw I still don't quite get all this
> use case for infiniband to be honest, and I will note I do see some
> proprietary hardware extensions like bursts but nothing covering all
> this in a general doc, I think I think it all just has to do that this
> is a hardware hack in reality, which we sell as a feature).
I was talking about the work that our drivers (cxgb4, cxgb4vf, etc.) do to ensure correct ordering between writes to memory and I/O space. For instance, issuing a wmb() between writes to a DMA buffer and the write to a register telling the hardware that the data is available. This isn’t necessary on the Strongly Ordered Intel architectures but is necessary on other architectures.
Casey
^ permalink raw reply
* [GIT PULL] fbdev fixes for 4.2
From: Tomi Valkeinen @ 2015-07-03 8:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
Hi Linus,
The following changes since commit f778dad38a54ca5207d024b5ebe0e6d71b8bad83:
Merge omapdss scaling fixes (2015-06-22 14:56:01 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-fixes-4.2
for you to fetch changes up to 0438ec90b17963662ef619b71c77c5c135b07014:
OMAPDSS: fix probing if rfbi device is enabled (2015-07-02 15:20:10 +0300)
----------------------------------------------------------------
fbdev fixes for 4.2
* Fix display regression on TI AM4xxx boards
----------------------------------------------------------------
Tomi Valkeinen (1):
OMAPDSS: fix probing if rfbi device is enabled
drivers/video/fbdev/omap2/dss/dss.c | 9 +++++++++
1 file changed, 9 insertions(+)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 0/3] video/logo: add option to return largest logo for a given resolution
From: Urs Fässler @ 2015-07-03 8:38 UTC (permalink / raw)
To: daniel.vetter, linux-fbdev, linux-kernel, oliver.staebler,
plagnioj, tomi.valkeinen, urs.fassler
With this patches, the largest boot logo for a given display resolution is used.
We need that functionality since it is common that a product has variants which
differ only minimal in the hardware. Thus, we have the same kernel binary but
different device trees for different hardware / displays.
This patches allow use to show a full screen boot logo for every hardware
variant.
Urs Fässler (3):
video/logo: use list of logos to find logo
logo: add option to return largest logo for a given resolution
fbdev: use largest logo if possible
drivers/video/fbdev/core/fbmem.c | 21 ++++--
drivers/video/logo/Kconfig | 7 ++
drivers/video/logo/logo.c | 146 ++++++++++++++++++++++++++-------------
include/linux/linux_logo.h | 4 ++
4 files changed, 124 insertions(+), 54 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/3] video/logo: use list of logos to find logo
From: Urs Fässler @ 2015-07-03 8:38 UTC (permalink / raw)
To: daniel.vetter, linux-fbdev, linux-kernel, oliver.staebler,
plagnioj, tomi.valkeinen, urs.fassler
In-Reply-To: <1435912696-17546-1-git-send-email-urs.fassler@bytesatwork.ch>
Refactoring of fb_find_logo: declare list of logos explicit and loop over
it to find a match.
Signed-off-by: Urs Fässler <urs.fassler@bytesatwork.ch>
---
drivers/video/logo/logo.c | 109 ++++++++++++++++++++++++++--------------------
1 file changed, 62 insertions(+), 47 deletions(-)
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index 10fbfd8..d0a44db 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -36,82 +36,97 @@ static int __init fb_logo_late_init(void)
late_initcall(fb_logo_late_init);
-/* logo's are marked __initdata. Use __init_refok to tell
- * modpost that it is intended that this function uses data
- * marked __initdata.
- */
-const struct linux_logo * __init_refok fb_find_logo(int depth)
-{
- const struct linux_logo *logo = NULL;
- if (nologo || logos_freed)
- return NULL;
-
- if (depth >= 1) {
+static const struct linux_logo *logos[] __initconst = {
#ifdef CONFIG_LOGO_LINUX_MONO
- /* Generic Linux logo */
- logo = &logo_linux_mono;
+ /* Generic Linux logo */
+ &logo_linux_mono,
#endif
#ifdef CONFIG_LOGO_SUPERH_MONO
- /* SuperH Linux logo */
- logo = &logo_superh_mono;
+ /* SuperH Linux logo */
+ &logo_superh_mono,
#endif
- }
-
- if (depth >= 4) {
#ifdef CONFIG_LOGO_LINUX_VGA16
- /* Generic Linux logo */
- logo = &logo_linux_vga16;
+ /* Generic Linux logo */
+ &logo_linux_vga16,
#endif
#ifdef CONFIG_LOGO_BLACKFIN_VGA16
- /* Blackfin processor logo */
- logo = &logo_blackfin_vga16;
+ /* Blackfin processor logo */
+ &logo_blackfin_vga16,
#endif
#ifdef CONFIG_LOGO_SUPERH_VGA16
- /* SuperH Linux logo */
- logo = &logo_superh_vga16;
+ /* SuperH Linux logo */
+ &logo_superh_vga16,
#endif
- }
-
- if (depth >= 8) {
#ifdef CONFIG_LOGO_LINUX_CLUT224
- /* Generic Linux logo */
- logo = &logo_linux_clut224;
+ /* Generic Linux logo */
+ &logo_linux_clut224,
#endif
#ifdef CONFIG_LOGO_BLACKFIN_CLUT224
- /* Blackfin Linux logo */
- logo = &logo_blackfin_clut224;
+ /* Blackfin Linux logo */
+ &logo_blackfin_clut224,
#endif
#ifdef CONFIG_LOGO_DEC_CLUT224
- /* DEC Linux logo on MIPS/MIPS64 or ALPHA */
- logo = &logo_dec_clut224;
+ /* DEC Linux logo on MIPS/MIPS64 or ALPHA */
+ &logo_dec_clut224,
#endif
-#ifdef CONFIG_LOGO_MAC_CLUT224
- /* Macintosh Linux logo on m68k */
- if (MACH_IS_MAC)
- logo = &logo_mac_clut224;
+#if defined(CONFIG_LOGO_MAC_CLUT224) && MACH_IS_MAC
+ /* Macintosh Linux logo on m68k */
+ &logo_mac_clut224,
#endif
#ifdef CONFIG_LOGO_PARISC_CLUT224
- /* PA-RISC Linux logo */
- logo = &logo_parisc_clut224;
+ /* PA-RISC Linux logo */
+ &logo_parisc_clut224,
#endif
#ifdef CONFIG_LOGO_SGI_CLUT224
- /* SGI Linux logo on MIPS/MIPS64 */
- logo = &logo_sgi_clut224;
+ /* SGI Linux logo on MIPS/MIPS64 */
+ &logo_sgi_clut224,
#endif
#ifdef CONFIG_LOGO_SUN_CLUT224
- /* Sun Linux logo */
- logo = &logo_sun_clut224;
+ /* Sun Linux logo */
+ &logo_sun_clut224,
#endif
#ifdef CONFIG_LOGO_SUPERH_CLUT224
- /* SuperH Linux logo */
- logo = &logo_superh_clut224;
+ /* SuperH Linux logo */
+ &logo_superh_clut224,
#endif
#ifdef CONFIG_LOGO_M32R_CLUT224
- /* M32R Linux logo */
- logo = &logo_m32r_clut224;
+ /* M32R Linux logo */
+ &logo_m32r_clut224,
#endif
+ NULL
+};
+
+static bool type_depth_compatible(int type, int depth)
+{
+ switch (type) {
+ case LINUX_LOGO_MONO:
+ return depth >= 1;
+ case LINUX_LOGO_VGA16:
+ return depth >= 4;
+ case LINUX_LOGO_CLUT224:
+ return depth >= 8;
+ default:
+ return false;
}
+}
+
+/* logo's are marked __initdata. Use __init_refok to tell
+ * modpost that it is intended that this function uses data
+ * marked __initdata.
+ */
+const struct linux_logo * __init_refok fb_find_logo(int depth)
+{
+ const struct linux_logo *logo = NULL;
+ const struct linux_logo **logos_itr;
+
+ if (nologo || logos_freed)
+ return NULL;
+
+ for (logos_itr = logos; *logos_itr != NULL; logos_itr++)
+ if (type_depth_compatible((*logos_itr)->type, depth))
+ logo = *logos_itr;
+
return logo;
}
EXPORT_SYMBOL_GPL(fb_find_logo);
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] logo: add option to return largest logo for a given resolution
From: Urs Fässler @ 2015-07-03 8:38 UTC (permalink / raw)
To: daniel.vetter, linux-fbdev, linux-kernel, oliver.staebler,
plagnioj, tomi.valkeinen, urs.fassler
In-Reply-To: <1435912696-17546-1-git-send-email-urs.fassler@bytesatwork.ch>
New method to return the largest (in number of pixels) logo for a given
resolution.
One use case is for embedded systems when one kernel binary is compiled
but used on different machines (i.e. different device trees) with
different display resolutions.
Signed-off-by: Urs Fässler <urs.fassler@bytesatwork.ch>
---
drivers/video/logo/Kconfig | 7 +++++++
drivers/video/logo/logo.c | 43 ++++++++++++++++++++++++++++++++++++++++---
include/linux/linux_logo.h | 4 ++++
3 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/video/logo/Kconfig b/drivers/video/logo/Kconfig
index 0037104..72bd185 100644
--- a/drivers/video/logo/Kconfig
+++ b/drivers/video/logo/Kconfig
@@ -15,6 +15,13 @@ config FB_LOGO_EXTRA
depends on FB=y
default y if SPU_BASE
+config FB_LOGO_LARGEST
+ bool "Use largest"
+ default n
+ help
+ Returns the largest available bootup logo that fits the given
+ resolution.
+
config LOGO_LINUX_MONO
bool "Standard black and white Linux logo"
default y
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index d0a44db..4a6da90 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -111,11 +111,35 @@ static bool type_depth_compatible(int type, int depth)
}
}
+#ifdef CONFIG_FB_LOGO_LARGEST
+static bool resolution_compatible(const struct linux_logo *logo,
+ unsigned int width, unsigned int height)
+{
+ if (width && height)
+ return (logo->width <= width) && (logo->height <= height);
+ else
+ return true;
+}
+
+static const struct linux_logo * __init_refok fb_logo_larger(
+ const struct linux_logo *logo1, const struct linux_logo *logo2)
+{
+ if (logo1->width*logo1->height > logo2->width*logo2->height)
+ return logo1;
+ else
+ return logo2;
+}
+#else
+#define fb_logo_larger(logo1, logo2, w, h) (logo1)
+#define resolution_compatible(logo, w, h) (true)
+#endif
+
/* logo's are marked __initdata. Use __init_refok to tell
* modpost that it is intended that this function uses data
* marked __initdata.
*/
-const struct linux_logo * __init_refok fb_find_logo(int depth)
+const struct linux_logo * __init_refok fb_find_logo_largest(int depth,
+ unsigned int width, unsigned int height)
{
const struct linux_logo *logo = NULL;
const struct linux_logo **logos_itr;
@@ -124,9 +148,22 @@ const struct linux_logo * __init_refok fb_find_logo(int depth)
return NULL;
for (logos_itr = logos; *logos_itr != NULL; logos_itr++)
- if (type_depth_compatible((*logos_itr)->type, depth))
- logo = *logos_itr;
+ if (type_depth_compatible((*logos_itr)->type, depth) &&
+ resolution_compatible(*logos_itr, width, height)) {
+ if (logo)
+ logo = fb_logo_larger(logo, *logos_itr);
+ else
+ logo = *logos_itr;
+ }
return logo;
}
+#ifdef CONFIG_FB_LOGO_LARGEST
+EXPORT_SYMBOL_GPL(fb_find_logo_largest);
+#endif
+
+const struct linux_logo * __init_refok fb_find_logo(int depth)
+{
+ return fb_find_logo_largest(depth, 0, 0);
+}
EXPORT_SYMBOL_GPL(fb_find_logo);
diff --git a/include/linux/linux_logo.h b/include/linux/linux_logo.h
index ca5bd91..f497e97 100644
--- a/include/linux/linux_logo.h
+++ b/include/linux/linux_logo.h
@@ -49,6 +49,10 @@ extern const struct linux_logo logo_m32r_clut224;
extern const struct linux_logo logo_spe_clut224;
extern const struct linux_logo *fb_find_logo(int depth);
+#ifdef CONFIG_FB_LOGO_LARGEST
+extern const struct linux_logo *fb_find_logo_largest(int depth,
+ unsigned int width, unsigned int height);
+#endif
#ifdef CONFIG_FB_LOGO_EXTRA
extern void fb_append_extra_logo(const struct linux_logo *logo,
unsigned int n);
--
2.1.4
^ permalink raw reply related
* [PATCH 3/3] fbdev: use largest logo if possible
From: Urs Fässler @ 2015-07-03 8:38 UTC (permalink / raw)
To: daniel.vetter, linux-fbdev, linux-kernel, oliver.staebler,
plagnioj, tomi.valkeinen, urs.fassler
In-Reply-To: <1435912696-17546-1-git-send-email-urs.fassler@bytesatwork.ch>
If CONFIG_FB_LOGO_LARGEST is set, fbdev uses the largest boot logo to
display.
Signed-off-by: Urs Fässler <urs.fassler@bytesatwork.ch>
---
drivers/video/fbdev/core/fbmem.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0705d88..319f168 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -595,7 +595,7 @@ static inline int fb_show_extra_logos(struct fb_info *info, int y, int rotate)
int fb_prepare_logo(struct fb_info *info, int rotate)
{
int depth = fb_get_color_depth(&info->var, &info->fix);
- unsigned int yres;
+ unsigned int xres, yres;
memset(&fb_logo, 0, sizeof(struct logo_data));
@@ -616,18 +616,25 @@ int fb_prepare_logo(struct fb_info *info, int rotate)
depth = 4;
}
- /* Return if no suitable logo was found */
+ if (rotate = FB_ROTATE_UR || rotate = FB_ROTATE_UD) {
+ xres = info->var.xres;
+ yres = info->var.yres;
+ } else {
+ xres = info->var.yres;
+ yres = info->var.xres;
+ }
+
+#ifdef CONFIG_FB_LOGO_LARGEST
+ fb_logo.logo = fb_find_logo_largest(depth, xres, yres);
+#else
fb_logo.logo = fb_find_logo(depth);
+#endif
+ /* Return if no suitable logo was found */
if (!fb_logo.logo) {
return 0;
}
- if (rotate = FB_ROTATE_UR || rotate = FB_ROTATE_UD)
- yres = info->var.yres;
- else
- yres = info->var.xres;
-
if (fb_logo.logo->height > yres) {
fb_logo.logo = NULL;
return 0;
--
2.1.4
^ permalink raw reply related
* [PATCH] pwm: add informations about polarity, duty cycle and period to debugfs
From: Heiko Stübner @ 2015-07-03 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20150702150141.5018a791@bbrezillon>
The pwm-states make it possible to also output the polarity, duty cycle
and period information in the debugfs pwm summary-outout.
This makes it easier to gather overview information about pwms without
needing to walk through the sysfs attributes of every pwm.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
now values are printed independent of the enable status :-)
drivers/pwm/core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 6dafd8e..4360ebb 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -954,6 +954,11 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct seq_file *s)
if (pwm_is_enabled(pwm))
seq_puts(s, " enabled");
+ seq_printf(s, " period:%uns", pwm_get_period(pwm));
+ seq_printf(s, " duty:%uns", pwm_get_duty_cycle(pwm));
+ seq_printf(s, " polarity:%s", pwm_get_polarity(pwm) ? "inverse"
+ : "normal");
+
seq_puts(s, "\n");
}
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/3] video/logo: use list of logos to find logo
From: Geert Uytterhoeven @ 2015-07-03 9:13 UTC (permalink / raw)
To: Urs Fässler
Cc: Daniel Vetter, Linux Fbdev development list,
linux-kernel@vger.kernel.org, oliver.staebler,
Jean-Christophe PLAGNIOL-VILLARD, Tomi Valkeinen
In-Reply-To: <1435912696-17546-2-git-send-email-urs.fassler@bytesatwork.ch>
On Fri, Jul 3, 2015 at 10:38 AM, Urs Fässler <urs.fassler@bytesatwork.ch> wrote:
> -#ifdef CONFIG_LOGO_MAC_CLUT224
> - /* Macintosh Linux logo on m68k */
> - if (MACH_IS_MAC)
> - logo = &logo_mac_clut224;
> +#if defined(CONFIG_LOGO_MAC_CLUT224) && MACH_IS_MAC
> + /* Macintosh Linux logo on m68k */
> + &logo_mac_clut224,
> #endif
That won't work, as depending on kernel configuration, MACH_IS_MAC
can be a run-time test, cfr.
arch/m68k/include/asm/setup.h:# define MACH_IS_MAC (0)
arch/m68k/include/asm/setup.h:# define MACH_IS_MAC (m68k_machtype = MACH_MAC)
arch/m68k/include/asm/setup.h:# define MACH_IS_MAC (1)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
From: Thierry Reding @ 2015-07-03 12:32 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, linux-arm-msm,
Linux Kernel Mailing List, dri-devel, Tomi Valkeinen,
Benjamin Gaignard, Thierry Reding
In-Reply-To: <CAKMK7uF=VY54wGEkq6r6Dt9fhSfhT8zYnsf0sPmQstDfUuRdrg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
On Tue, Jun 30, 2015 at 11:04:45AM +0200, Daniel Vetter wrote:
> On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard
> <benjamin.gaignard@linaro.org> wrote:
> > I think that what have been done by Rob with module_param is also a good idea:
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934
> >
> > Can you mix compilation flag and module param ?
>
> Hm, the point of the kconfig is to not require all the legacy baggage
> from fbdev. But I guess a module option could be added later on too.
> bochs has it too.
I think the option would primarily be useful for testing. I've often
needed to test modesetting code without fbdev getting in the way and the
only way to currently do that is by recompiling with legacy fbdev
disabled. The option would allow an fbdev-enabled kernel to be used but
disable the fbdev code if desired.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
From: Rob Clark @ 2015-07-03 13:33 UTC (permalink / raw)
To: Thierry Reding
Cc: Linux Fbdev development list, Benjamin Gaignard, linux-arm-msm,
Linux Kernel Mailing List, dri-devel, Tomi Valkeinen,
Thierry Reding
In-Reply-To: <20150703123246.GA29257@ulmo.nvidia.com>
On Fri, Jul 3, 2015 at 8:32 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Jun 30, 2015 at 11:04:45AM +0200, Daniel Vetter wrote:
>> On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard
>> <benjamin.gaignard@linaro.org> wrote:
>> > I think that what have been done by Rob with module_param is also a good idea:
>> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?idé0dfec78ec288d6c89a7b508a5c5d4ae8b7f934
>> >
>> > Can you mix compilation flag and module param ?
>>
>> Hm, the point of the kconfig is to not require all the legacy baggage
>> from fbdev. But I guess a module option could be added later on too.
>> bochs has it too.
>
> I think the option would primarily be useful for testing. I've often
> needed to test modesetting code without fbdev getting in the way and the
> only way to currently do that is by recompiling with legacy fbdev
> disabled. The option would allow an fbdev-enabled kernel to be used but
> disable the fbdev code if desired.
and for debugging.. when things are going wrong it's nice for the
first modeset to not happen under console_lock ;-)
BR,
-R
> Thierry
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* Re: [PATCH v2 3/3] console_codes.4: Add CSI sequence for cursor blink interval
From: Scot Doyle @ 2015-07-05 17:41 UTC (permalink / raw)
To: Michael Kerrisk
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-man-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.11.1503261356490.2411@local>
On Thu, 26 Mar 2015, Scot Doyle wrote:
> Add a Console Private CSI sequence to specify the current console's
> cursor blink interval. The interval is specified as a number of
> milliseconds until the next cursor display state toggle, from 50 to
> 65535.
>
> Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
> ---
> man4/console_codes.4 | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/man4/console_codes.4 b/man4/console_codes.4
> index 34f7535..7d05076 100644
> --- a/man4/console_codes.4
> +++ b/man4/console_codes.4
> @@ -377,6 +377,7 @@ ESC [ 15 ] T{
> Bring the previous console to the front
> (since Linux 2.6.0).
> T}
> +ESC [ 16 ; \fIn\fP ] Set the cursor blink interval in milliseconds.
> .TE
> .SS Character sets
> The kernel knows about 4 translations of bytes into console-screen
> --
> 2.1.0
>
Hi Michael,
Will you apply now that Linus has pulled the rest?
(see bd63364caa8df38bad2b25b11b2a1b849475cce5)
Thank you,
Scot
^ permalink raw reply
* Re: [PATCH v3] video-lp8788: Delete a check before backlight_device_unregister()
From: Lee Jones @ 2015-07-07 7:13 UTC (permalink / raw)
To: SF Markus Elfring
Cc: Jingoo Han, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, Linux Kernel Mailing List, kernel-janitors,
Julia Lawall
In-Reply-To: <5593C14A.8020700@users.sourceforge.net>
On Wed, 01 Jul 2015, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 1 Jul 2015 12:08:31 +0200
>
> The backlight_device_unregister() function tests whether its argument
> is NULL and then returns immediately.
> Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/video/backlight/lp8788_bl.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Applied, thanks.
> diff --git a/drivers/video/backlight/lp8788_bl.c b/drivers/video/backlight/lp8788_bl.c
> index e418d5b..5d583d7 100644
> --- a/drivers/video/backlight/lp8788_bl.c
> +++ b/drivers/video/backlight/lp8788_bl.c
> @@ -221,8 +221,7 @@ static void lp8788_backlight_unregister(struct lp8788_bl *bl)
> {
> struct backlight_device *bl_dev = bl->bl_dev;
>
> - if (bl_dev)
> - backlight_device_unregister(bl_dev);
> + backlight_device_unregister(bl_dev);
> }
>
> static ssize_t lp8788_get_bl_ctl_mode(struct device *dev,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 0/5] staging: sm7xxfb: few changes
From: Sudip Mukherjee @ 2015-07-07 8:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, devel, Dan Carpenter, Sudip Mukherjee
Few more changes in sm7xxfb, and hopefully the last changes before I
send the patch to move it to drivers/video/fbdev.
Has been tested with:
1) fbtest available at https://git.kernel.org/cgit/linux/kernel/git/geert/fbtest.git/
2) read and write tested on Little-Endian system
regards
sudip
Sudip Mukherjee (5):
staging: sm7xxfb: remove unused macros
staging: sm7xxfb: fix error handling
staging: sm7xxfb: use kernel commandline
staging: sm7xxfb: define new macros
staging: sm7xxfb: usr fb_read and fb_write
drivers/staging/sm7xxfb/sm7xx.h | 39 +++++++++++-----------
drivers/staging/sm7xxfb/sm7xxfb.c | 69 ++++++++++-----------------------------
2 files changed, 37 insertions(+), 71 deletions(-)
--
1.8.1.2
^ permalink raw reply
* [PATCH 1/5] staging: sm7xxfb: remove unused macros
From: Sudip Mukherjee @ 2015-07-07 8:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, devel, Dan Carpenter, Sudip Mukherjee
In-Reply-To: <1436256877-10754-1-git-send-email-sudipm.mukherjee@gmail.com>
These macros were only defined but not used anywhere.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/staging/sm7xxfb/sm7xx.h | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
index 4bed094..31a21bd 100644
--- a/drivers/staging/sm7xxfb/sm7xx.h
+++ b/drivers/staging/sm7xxfb/sm7xx.h
@@ -13,8 +13,6 @@
* more details.
*/
-#define NR_PALETTE 256
-
#define FB_ACCEL_SMI_LYNX 88
#define SCREEN_X_RES 1024
@@ -31,12 +29,8 @@
extern void __iomem *smtc_regbaseaddress;
#define smtc_mmiowb(dat, reg) writeb(dat, smtc_regbaseaddress + reg)
-#define smtc_mmioww(dat, reg) writew(dat, smtc_regbaseaddress + reg)
-#define smtc_mmiowl(dat, reg) writel(dat, smtc_regbaseaddress + reg)
#define smtc_mmiorb(reg) readb(smtc_regbaseaddress + reg)
-#define smtc_mmiorw(reg) readw(smtc_regbaseaddress + reg)
-#define smtc_mmiorl(reg) readl(smtc_regbaseaddress + reg)
#define SIZE_SR00_SR04 (0x04 - 0x00 + 1)
#define SIZE_SR10_SR24 (0x24 - 0x10 + 1)
@@ -48,8 +42,6 @@ extern void __iomem *smtc_regbaseaddress;
#define SIZE_CR00_CR18 (0x18 - 0x00 + 1)
#define SIZE_CR30_CR4D (0x4D - 0x30 + 1)
#define SIZE_CR90_CRA7 (0xA7 - 0x90 + 1)
-#define SIZE_VPR (0x6C + 1)
-#define SIZE_DPR (0x44 + 1)
static inline void smtc_crtcw(int reg, int val)
{
@@ -57,24 +49,12 @@ static inline void smtc_crtcw(int reg, int val)
smtc_mmiowb(val, 0x3d5);
}
-static inline unsigned int smtc_crtcr(int reg)
-{
- smtc_mmiowb(reg, 0x3d4);
- return smtc_mmiorb(0x3d5);
-}
-
static inline void smtc_grphw(int reg, int val)
{
smtc_mmiowb(reg, 0x3ce);
smtc_mmiowb(val, 0x3cf);
}
-static inline unsigned int smtc_grphr(int reg)
-{
- smtc_mmiowb(reg, 0x3ce);
- return smtc_mmiorb(0x3cf);
-}
-
static inline void smtc_attrw(int reg, int val)
{
smtc_mmiorb(0x3da);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/5] staging: sm7xxfb: fix error handling
From: Sudip Mukherjee @ 2015-07-07 8:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, devel, Dan Carpenter, Sudip Mukherjee
In-Reply-To: <1436256877-10754-1-git-send-email-sudipm.mukherjee@gmail.com>
We were checking smtc_regbaseaddress and that too at a place where it
can never be NULL. Real check should be on sfb->lfb immediately after
we do ioremap.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/staging/sm7xxfb/sm7xxfb.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index 2ff4fe7..8fb62af 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -1456,6 +1456,14 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
#else
sfb->lfb = ioremap(mmio_base, 0x00800000);
#endif
+ if (!sfb->lfb) {
+ dev_err(&pdev->dev,
+ "%s: unable to map memory mapped IO!\n",
+ sfb->fb->fix.id);
+ err = -ENOMEM;
+ goto failed_fb;
+ }
+
sfb->mmio = (smtc_regbaseaddress sfb->lfb + 0x00700000);
sfb->dp_regs = sfb->lfb + 0x00408000;
@@ -1466,13 +1474,6 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
dev_info(&pdev->dev, "sfb->lfb=%p\n", sfb->lfb);
}
#endif
- if (!smtc_regbaseaddress) {
- dev_err(&pdev->dev,
- "%s: unable to map memory mapped IO!\n",
- sfb->fb->fix.id);
- err = -ENOMEM;
- goto failed_fb;
- }
/* set MCLK = 14.31818 * (0x16 / 0x2) */
smtc_seqw(0x6a, 0x16);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 3/5] staging: sm7xxfb: use kernel commandline
From: Sudip Mukherjee @ 2015-07-07 8:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, devel, Dan Carpenter, Sudip Mukherjee
In-Reply-To: <1436256877-10754-1-git-send-email-sudipm.mukherjee@gmail.com>
We were only using the kernel commandline to set the mode if this driver
is builtin, but when it is built as a module we were not having any way
to set the mode. Start using commandline even if it is built as a
module.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/staging/sm7xxfb/sm7xxfb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index 8fb62af..4dc9d5f 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -1660,14 +1660,12 @@ static struct pci_driver smtcfb_driver = {
static int __init sm712fb_init(void)
{
-#ifndef MODULE
char *option = NULL;
if (fb_get_options("sm712fb", &option))
return -ENODEV;
if (option && *option)
mode_option = option;
-#endif
sm7xx_vga_setup(mode_option);
return pci_register_driver(&smtcfb_driver);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 4/5] staging: sm7xxfb: define new macros
From: Sudip Mukherjee @ 2015-07-07 8:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, devel, Dan Carpenter, Sudip Mukherjee
In-Reply-To: <1436256877-10754-1-git-send-email-sudipm.mukherjee@gmail.com>
Define and use some new macros to work with different situations
based on little-endian and big-endian.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/staging/sm7xxfb/sm7xx.h | 19 ++++++++++++++++
drivers/staging/sm7xxfb/sm7xxfb.c | 48 ++++++++-------------------------------
2 files changed, 29 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
index 31a21bd..6905177 100644
--- a/drivers/staging/sm7xxfb/sm7xx.h
+++ b/drivers/staging/sm7xxfb/sm7xx.h
@@ -95,3 +95,22 @@ struct modeinit {
unsigned char init_cr30_cr4d[SIZE_CR30_CR4D];
unsigned char init_cr90_cra7[SIZE_CR90_CRA7];
};
+
+#ifdef __BIG_ENDIAN
+#define pal_rgb(r, g, b, val) (((r & 0xf800) >> 8) | \
+ ((g & 0xe000) >> 13) | \
+ ((g & 0x1c00) << 3) | \
+ ((b & 0xf800) >> 3))
+#define big_addr 0x800000
+#define mmio_addr 0x00800000
+#define seqw17 smtc_seqw(0x17, 0x30)
+#define big_pixel_depth(p, d) {if (p = 24) {p = 32; d = 32; } }
+#define big_swap(p) ((p & 0xff00ff00 >> 8) | (p & 0x00ff00ff << 8))
+#else
+#define pal_rgb(r, g, b, val) val
+#define big_addr 0
+#define mmio_addr 0x00c00000
+#define seqw17
+#define big_pixel_depth(p, d)
+#define big_swap(p) p
+#endif
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index 4dc9d5f..252f110a 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -923,25 +923,14 @@ static int smtc_setcolreg(unsigned regno, unsigned red, unsigned green,
val = chan_to_field(red, &sfb->fb->var.red);
val |= chan_to_field(green, &sfb->fb->var.green);
val |= chan_to_field(blue, &sfb->fb->var.blue);
-#ifdef __BIG_ENDIAN
- pal[regno] = ((red & 0xf800) >> 8) |
- ((green & 0xe000) >> 13) |
- ((green & 0x1c00) << 3) |
- ((blue & 0xf800) >> 3);
-#else
- pal[regno] = val;
-#endif
+ pal[regno] = pal_rgb(red, green, blue, val);
} else {
u32 *pal = sfb->fb->pseudo_palette;
val = chan_to_field(red, &sfb->fb->var.red);
val |= chan_to_field(green, &sfb->fb->var.green);
val |= chan_to_field(blue, &sfb->fb->var.blue);
-#ifdef __BIG_ENDIAN
- val = (val & 0xff00ff00 >> 8) |
- (val & 0x00ff00ff << 8);
-#endif
- pal[regno] = val;
+ pal[regno] = big_swap(val);
}
break;
@@ -1002,8 +991,7 @@ static ssize_t smtcfb_read(struct fb_info *info, char __user *buf,
dst = buffer;
for (i = c >> 2; i--;) {
*dst = fb_readl(src++);
- *dst = (*dst & 0xff00ff00 >> 8) |
- (*dst & 0x00ff00ff << 8);
+ *dst = big_swap(*dst);
dst++;
}
if (c & 3) {
@@ -1091,8 +1079,7 @@ static ssize_t smtcfb_write(struct fb_info *info, const char __user *buf,
}
for (i = c >> 2; i--;) {
- fb_writel((*src & 0xff00ff00 >> 8) |
- (*src & 0x00ff00ff << 8), dst++);
+ fb_writel(big_swap(*src), dst++);
src++;
}
if (c & 3) {
@@ -1341,10 +1328,8 @@ static int smtc_map_smem(struct smtcfb_info *sfb,
{
sfb->fb->fix.smem_start = pci_resource_start(pdev, 0);
-#ifdef __BIG_ENDIAN
if (sfb->fb->var.bits_per_pixel = 32)
- sfb->fb->fix.smem_start += 0x800000;
-#endif
+ sfb->fb->fix.smem_start += big_addr;
sfb->fb->fix.smem_len = smem_len;
@@ -1437,10 +1422,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
sfb->fb->var.bits_per_pixel = SCREEN_BPP;
}
-#ifdef __BIG_ENDIAN
- if (sfb->fb->var.bits_per_pixel = 24)
- sfb->fb->var.bits_per_pixel = (smtc_scr_info.lfb_depth = 32);
-#endif
+ big_pixel_depth(sfb->fb->var.bits_per_pixel, smtc_scr_info.lfb_depth);
/* Map address and memory detection */
mmio_base = pci_resource_start(pdev, 0);
pci_read_config_byte(pdev, PCI_REVISION_ID, &sfb->chip_rev_id);
@@ -1451,11 +1433,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
sfb->fb->fix.mmio_start = mmio_base + 0x00400000;
sfb->fb->fix.mmio_len = 0x00400000;
smem_size = SM712_VIDEOMEMORYSIZE;
-#ifdef __BIG_ENDIAN
- sfb->lfb = ioremap(mmio_base, 0x00c00000);
-#else
- sfb->lfb = ioremap(mmio_base, 0x00800000);
-#endif
+ sfb->lfb = ioremap(mmio_base, mmio_addr);
if (!sfb->lfb) {
dev_err(&pdev->dev,
"%s: unable to map memory mapped IO!\n",
@@ -1468,12 +1446,10 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
sfb->lfb + 0x00700000);
sfb->dp_regs = sfb->lfb + 0x00408000;
sfb->vp_regs = sfb->lfb + 0x0040c000;
-#ifdef __BIG_ENDIAN
if (sfb->fb->var.bits_per_pixel = 32) {
- sfb->lfb += 0x800000;
+ sfb->lfb += big_addr;
dev_info(&pdev->dev, "sfb->lfb=%p\n", sfb->lfb);
}
-#endif
/* set MCLK = 14.31818 * (0x16 / 0x2) */
smtc_seqw(0x6a, 0x16);
@@ -1482,10 +1458,8 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
/* enable PCI burst */
smtc_seqw(0x17, 0x20);
/* enable word swap */
-#ifdef __BIG_ENDIAN
if (sfb->fb->var.bits_per_pixel = 32)
- smtc_seqw(0x17, 0x30);
-#endif
+ seqw17;
break;
case 0x720:
sfb->fb->fix.mmio_start = mmio_base;
@@ -1617,10 +1591,8 @@ static int smtcfb_pci_resume(struct device *device)
smtc_seqw(0x62, 0x3e);
/* enable PCI burst */
smtc_seqw(0x17, 0x20);
-#ifdef __BIG_ENDIAN
if (sfb->fb->var.bits_per_pixel = 32)
- smtc_seqw(0x17, 0x30);
-#endif
+ seqw17;
break;
case 0x720:
smtc_seqw(0x62, 0xff);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 5/5] staging: sm7xxfb: usr fb_read and fb_write
From: Sudip Mukherjee @ 2015-07-07 8:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, devel, Dan Carpenter, Sudip Mukherjee
In-Reply-To: <1436256877-10754-1-git-send-email-sudipm.mukherjee@gmail.com>
Now since the Big-Endian and Little-Endian based calculations are moved
into a macro we can make fb_read() and fb_write() common for both
Little-Endian and Big-Endian.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
drivers/staging/sm7xxfb/sm7xxfb.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index 252f110a..b8a1e86 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -946,7 +946,6 @@ static int smtc_setcolreg(unsigned regno, unsigned red, unsigned green,
return 0;
}
-#ifdef __BIG_ENDIAN
static ssize_t smtcfb_read(struct fb_info *info, char __user *buf,
size_t count, loff_t *ppos)
{
@@ -1107,7 +1106,6 @@ static ssize_t smtcfb_write(struct fb_info *info, const char __user *buf,
return (cnt) ? cnt : err;
}
-#endif /* ! __BIG_ENDIAN */
static void sm7xx_set_timing(struct smtcfb_info *sfb)
{
@@ -1303,10 +1301,8 @@ static struct fb_ops smtcfb_ops = {
.fb_fillrect = cfb_fillrect,
.fb_imageblit = cfb_imageblit,
.fb_copyarea = cfb_copyarea,
-#ifdef __BIG_ENDIAN
.fb_read = smtcfb_read,
.fb_write = smtcfb_write,
-#endif
};
/*
--
1.8.1.2
^ permalink raw reply related
* [PATCH RESEND] video: fbdev: s3c-fb: Constify platform_device_id
From: Krzysztof Kozlowski @ 2015-07-07 13:00 UTC (permalink / raw)
To: Jingoo Han, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, linux-kernel
Cc: Krzysztof Kozlowski
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
---
drivers/video/fbdev/s3c-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
index 7e3a05fc47aa..f72dd12456f9 100644
--- a/drivers/video/fbdev/s3c-fb.c
+++ b/drivers/video/fbdev/s3c-fb.c
@@ -1938,7 +1938,7 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
},
};
-static struct platform_device_id s3c_fb_driver_ids[] = {
+static const struct platform_device_id s3c_fb_driver_ids[] = {
{
.name = "s3c-fb",
.driver_data = (unsigned long)&s3c_fb_data_64xx,
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2 v2] video/logo: add option to return largest logo for a given resolution
From: Urs Fässler @ 2015-07-07 14:24 UTC (permalink / raw)
To: daniel.vetter, linux-fbdev, linux-kernel, oliver.staebler,
plagnioj, tomi.valkeinen, urs.fassler, geert
With this patches, the largest boot logo for a given display resolution is used.
We need that functionality since it is common that a product has variants which
differ only minimal in the hardware. Thus, we have the same kernel binary but
different device trees for different hardware / displays.
This patches allow use to show a full screen boot logo for every hardware
variant.
This is a rework of the patch from 3 Jul 2015 which respects the runtime-check
on m68k.
Urs Fässler (2):
logo: add option to return largest logo for a given resolution
fbdev: use largest logo if possible
drivers/video/fbdev/core/fbmem.c | 21 ++++++----
drivers/video/logo/Kconfig | 7 ++++
drivers/video/logo/logo.c | 86 ++++++++++++++++++++++++++++++++--------
include/linux/linux_logo.h | 4 ++
4 files changed, 94 insertions(+), 24 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH 1/2] logo: add option to return largest logo for a given resolution
From: Urs Fässler @ 2015-07-07 14:24 UTC (permalink / raw)
To: daniel.vetter, linux-fbdev, linux-kernel, oliver.staebler,
plagnioj, tomi.valkeinen, urs.fassler, geert
In-Reply-To: <1436279052-17237-1-git-send-email-urs.fassler@bytesatwork.ch>
New method to return the largest (in number of pixels) logo for a given
resolution.
One use case is for embedded systems when one kernel binary is compiled
but used on different machines (i.e. different device trees) with
different display resolutions.
Signed-off-by: Urs Fässler <urs.fassler@bytesatwork.ch>
---
drivers/video/logo/Kconfig | 7 ++++
drivers/video/logo/logo.c | 86 +++++++++++++++++++++++++++++++++++++---------
include/linux/linux_logo.h | 4 +++
3 files changed, 80 insertions(+), 17 deletions(-)
diff --git a/drivers/video/logo/Kconfig b/drivers/video/logo/Kconfig
index 0037104..72bd185 100644
--- a/drivers/video/logo/Kconfig
+++ b/drivers/video/logo/Kconfig
@@ -15,6 +15,13 @@ config FB_LOGO_EXTRA
depends on FB=y
default y if SPU_BASE
+config FB_LOGO_LARGEST
+ bool "Use largest"
+ default n
+ help
+ Returns the largest available bootup logo that fits the given
+ resolution.
+
config LOGO_LINUX_MONO
bool "Standard black and white Linux logo"
default y
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index 10fbfd8..1b0d4c5 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -36,11 +36,55 @@ static int __init fb_logo_late_init(void)
late_initcall(fb_logo_late_init);
+#ifdef CONFIG_FB_LOGO_LARGEST
+bool fb_logo_valid(const struct linux_logo *logo, unsigned int width,
+ unsigned int height)
+{
+ if (!logo)
+ return false;
+ if (logo->width > width)
+ return false;
+ if (logo->height > height)
+ return false;
+
+ return true;
+}
+
+const struct linux_logo * __init_refok fb_logo_larger(
+ const struct linux_logo *logo1, const struct linux_logo *logo2,
+ unsigned int width, unsigned int height)
+{
+ bool logo1_valid;
+ bool logo2_valid;
+
+ if (!width || !height)
+ return logo1;
+
+ logo1_valid = fb_logo_valid(logo1, width, height);
+ logo2_valid = fb_logo_valid(logo2, width, height);
+
+ if (!logo1_valid && !logo2_valid)
+ return NULL;
+ if (logo1_valid && !logo2_valid)
+ return logo1;
+ if (!logo1_valid && logo2_valid)
+ return logo2;
+
+ if (logo1->width*logo1->height > logo2->width*logo2->height)
+ return logo1;
+ else
+ return logo2;
+}
+#else
+#define fb_logo_larger(logo1, logo2, w, h) (logo1)
+#endif
+
/* logo's are marked __initdata. Use __init_refok to tell
* modpost that it is intended that this function uses data
* marked __initdata.
*/
-const struct linux_logo * __init_refok fb_find_logo(int depth)
+const struct linux_logo * __init_refok fb_find_logo_largest(int depth,
+ unsigned int w, unsigned int h)
{
const struct linux_logo *logo = NULL;
@@ -50,68 +94,76 @@ const struct linux_logo * __init_refok fb_find_logo(int depth)
if (depth >= 1) {
#ifdef CONFIG_LOGO_LINUX_MONO
/* Generic Linux logo */
- logo = &logo_linux_mono;
+ logo = fb_logo_larger(&logo_linux_mono, logo, w, h);
#endif
#ifdef CONFIG_LOGO_SUPERH_MONO
/* SuperH Linux logo */
- logo = &logo_superh_mono;
+ logo = fb_logo_larger(&logo_superh_mono, logo, w, h);
#endif
}
-
+
if (depth >= 4) {
#ifdef CONFIG_LOGO_LINUX_VGA16
/* Generic Linux logo */
- logo = &logo_linux_vga16;
+ logo = fb_logo_larger(&logo_linux_vga16, logo, w, h);
#endif
#ifdef CONFIG_LOGO_BLACKFIN_VGA16
/* Blackfin processor logo */
- logo = &logo_blackfin_vga16;
+ logo = fb_logo_larger(&logo_blackfin_vga16, logo, w, h);
#endif
#ifdef CONFIG_LOGO_SUPERH_VGA16
/* SuperH Linux logo */
- logo = &logo_superh_vga16;
+ logo = fb_logo_larger(&logo_superh_vga16, logo, w, h);
#endif
}
-
+
if (depth >= 8) {
#ifdef CONFIG_LOGO_LINUX_CLUT224
/* Generic Linux logo */
- logo = &logo_linux_clut224;
+ logo = fb_logo_larger(&logo_linux_clut224, logo, w, h);
#endif
#ifdef CONFIG_LOGO_BLACKFIN_CLUT224
/* Blackfin Linux logo */
- logo = &logo_blackfin_clut224;
+ logo = fb_logo_larger(&logo_blackfin_clut224, logo, w, h);
#endif
#ifdef CONFIG_LOGO_DEC_CLUT224
/* DEC Linux logo on MIPS/MIPS64 or ALPHA */
- logo = &logo_dec_clut224;
+ logo = fb_logo_larger(&logo_dec_clut224, logo, w, h);
#endif
#ifdef CONFIG_LOGO_MAC_CLUT224
/* Macintosh Linux logo on m68k */
if (MACH_IS_MAC)
- logo = &logo_mac_clut224;
+ logo = fb_logo_larger(&logo_mac_clut224, logo, w, h);
#endif
#ifdef CONFIG_LOGO_PARISC_CLUT224
/* PA-RISC Linux logo */
- logo = &logo_parisc_clut224;
+ logo = fb_logo_larger(&logo_parisc_clut224, logo, w, h);
#endif
#ifdef CONFIG_LOGO_SGI_CLUT224
/* SGI Linux logo on MIPS/MIPS64 */
- logo = &logo_sgi_clut224;
+ logo = fb_logo_larger(&logo_sgi_clut224, logo, w, h);
#endif
#ifdef CONFIG_LOGO_SUN_CLUT224
/* Sun Linux logo */
- logo = &logo_sun_clut224;
+ logo = fb_logo_larger(&logo_sun_clut224, logo, w, h);
#endif
#ifdef CONFIG_LOGO_SUPERH_CLUT224
/* SuperH Linux logo */
- logo = &logo_superh_clut224;
+ logo = fb_logo_larger(&logo_superh_clut224, logo, w, h);
#endif
#ifdef CONFIG_LOGO_M32R_CLUT224
/* M32R Linux logo */
- logo = &logo_m32r_clut224;
+ logo = fb_logo_larger(&logo_m32r_clut224, logo, w, h);
#endif
}
return logo;
}
+#ifdef CONFIG_FB_LOGO_LARGEST
+EXPORT_SYMBOL_GPL(fb_find_logo_largest);
+#endif
+
+const struct linux_logo * __init_refok fb_find_logo(int depth)
+{
+ return fb_find_logo_largest(depth, 0, 0);
+}
EXPORT_SYMBOL_GPL(fb_find_logo);
diff --git a/include/linux/linux_logo.h b/include/linux/linux_logo.h
index ca5bd91..f497e97 100644
--- a/include/linux/linux_logo.h
+++ b/include/linux/linux_logo.h
@@ -49,6 +49,10 @@ extern const struct linux_logo logo_m32r_clut224;
extern const struct linux_logo logo_spe_clut224;
extern const struct linux_logo *fb_find_logo(int depth);
+#ifdef CONFIG_FB_LOGO_LARGEST
+extern const struct linux_logo *fb_find_logo_largest(int depth,
+ unsigned int width, unsigned int height);
+#endif
#ifdef CONFIG_FB_LOGO_EXTRA
extern void fb_append_extra_logo(const struct linux_logo *logo,
unsigned int n);
--
2.1.4
^ permalink raw reply related
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