* Re: [PATCH] video: ARM CLCD: Remove duplicated include in amba-clcd.c
From: Pawel Moll @ 2014-11-17 11:07 UTC (permalink / raw)
To: Qiang Chen
Cc: tomi.valkeinen@ti.com, plagnioj@jcrosoft.com,
linux@arm.linux.org.uk, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, qcwj.lk@gmail.com
In-Reply-To: <1416216301-15854-1-git-send-email-qiang2.chen@sonymobile.com>
On Mon, 2014-11-17 at 09:25 +0000, Qiang Chen wrote:
> This patch fixes duplicated include dma-mapping.h in
> drivers/video/fbdev/amba-clcd.c
>
> Signed-off-by: Qiang Chen <qiang2.chen@sonymobile.com>
> ---
> drivers/video/fbdev/amba-clcd.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
> index 6ad23bd..32c0b6b 100644
> --- a/drivers/video/fbdev/amba-clcd.c
> +++ b/drivers/video/fbdev/amba-clcd.c
> @@ -27,7 +27,6 @@
> #include <linux/bitops.h>
> #include <linux/clk.h>
> #include <linux/hardirq.h>
> -#include <linux/dma-mapping.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/of_graph.h>
Acked-by: Pawel Moll <pawel.moll@arm.com>
Thanks!
Pawel
^ permalink raw reply
* [PATCH] video: ARM CLCD: Remove duplicated include in amba-clcd.c
From: Qiang Chen @ 2014-11-17 9:25 UTC (permalink / raw)
To: tomi.valkeinen, plagnioj, linux, pawel.moll
Cc: linux-fbdev, linux-kernel, qcwj.lk
This patch fixes duplicated include dma-mapping.h in
drivers/video/fbdev/amba-clcd.c
Signed-off-by: Qiang Chen <qiang2.chen@sonymobile.com>
---
drivers/video/fbdev/amba-clcd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 6ad23bd..32c0b6b 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -27,7 +27,6 @@
#include <linux/bitops.h>
#include <linux/clk.h>
#include <linux/hardirq.h>
-#include <linux/dma-mapping.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_graph.h>
--
1.8.2.2
^ permalink raw reply related
* Re: SSD1306 OLED driver
From: maxime.ripard @ 2014-11-16 9:50 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BAY176-W246A4D5C3A23D1928FC5D3D38C0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Hi,
On Fri, Nov 14, 2014 at 05:09:09PM +0530, Ssagarr Patil wrote:
> Hi,
>
> I have the SSD1306 oled device connected via spi, will the same
> driver work ? as the current one is based on i2c what all mods would
> be required to have it working with SPI ?
It won't work out of the box, but it should be fairly easy to support.
You need to had support for SPI probing, and then provide some generic
accessors the rest of the code can use to wrap around the i2c and spi
calls.
I'm not sure regmap can be used for this, but this would be something
worth looking into to do that.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
From: Vladimir Zapolskiy @ 2014-11-15 15:52 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen
In-Reply-To: <5466139E.5040308@mentor.com>
Hi Jyri,
On 14.11.2014 16:37, Vladimir Zapolskiy wrote:
> Hi Jyri,
>
> On 12.11.2014 16:41, Jyri Sarha wrote:
>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>> ---
>> drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
>> index a6e08ff..6d129f2 100644
>> --- a/drivers/video/fbdev/omap2/dss/hdmi.h
>> +++ b/drivers/video/fbdev/omap2/dss/hdmi.h
>> @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
>> struct hdmi_audio_format *aud_fmt);
>> void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp,
>> struct hdmi_audio_dma *aud_dma);
>> -static inline bool hdmi_mode_has_audio(int mode)
>> +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg)
>> {
>> - return mode = HDMI_HDMI ? true : false;
>> + return cfg->hdmi_dvi_mode = HDMI_HDMI ? true : false;
>> }
>>
>> /* HDMI DRV data */
>>
>
> would it be possible for you to rearrange the changes preserving the
> following sequence?
>
> 1) 13/19
> 2) 15/19
> 3) 11/19
> 4) 14/19
> 5) 16/19
>
> Otherwise I'm worried that someone's git rebase may fail.
sorry, git bisect of course.
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device
From: Bruno Prémont @ 2014-11-14 22:11 UTC (permalink / raw)
To: Henrik Rydberg
Cc: linux-fbdev, Peter Jones, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, Bjorn Helgaas, linux-kernel
In-Reply-To: <20141114191157.GA1648@polaris.bitmath.org>
Hi Hendrick,
On Fri, 14 November 2014 Henrik Rydberg <rydberg@euromail.se> wrote:
> > So it would need to at least be select VGA_ARB if (PCI && !S390)
> > in order to not have broken kernel configuration (in more or less
> > exotic cases) while depends on VGA_ARB would be the only correct option
> > if the rule 'select only allowed for leafs' is enforced.
>
> Here is a tested patch that does just that, thanks for the suggestion.
Sure it will cover your case but with a few issues.
As you might have noted, VGA_ARB can only be disabled if you select
EXPERT. In that case you kind of give up warranty.
In addition, prior to the patches that landed in 3.17, just selecting
X86_SYSFB would runtime-disable EFI_FB disabling boot_vga tagging
based on screen_info as well.
Stating in the commit message that EFI_FB depends on VGA_ARB is pretty
wrong. A more correct phrasing would be that before the commit EFI_FB
included boot_vga detection which has been moved around, but that
feature is not inherent to EFI_FB. Doing the select only keeps
`make oldconfig` provide the same feature set.
As boot_vga is a PCI thing maybe the whole detection should effectively
be fully dissociated from runtime GPU switching and be adjusted to
really only flag the boot GPU (even when there is no VGA around).
Unfortunately this attribute is not explicitly documented so drawing the
line one way or another may trip on some user's feet.
We have some more or less conflicting information in commit messages though:
217f45de3d2 by Dave Airlie introducing boot_vgain 2009:
PCI: expose boot VGA device via sysfs.
X really would like to know which VGA device was considered the boot
device by the system. The x86 PCI fixups have support for discovering
this but we provide no way to expose it to userspace.
This adds a sysfs file per VGA class device which has the value 0 for
non the boot device or unknown, and 1 if the VGA device is the boot
device.
1a39b310e92 by Matthew Garrett making it variable in 2012:
vgaarb: Add support for setting the default video device (v2)
The default VGA device is a somewhat fluid concept on platforms with
multiple GPUs. Add support for setting it so switching code can update
things appropriately, and make sure that the sysfs code returns the right
device if it's changed.
So should boot_vga now represent the main GPU of the system or should
it represent the one(s) that were used for booting? (I've not heard
of systems with more than one active firmware GPU... but why not!
Matthew covered the case where multiple GPUs are in a set where only one
of them can be active as in driving displays. Maybe this would need some
alternative sysfs attribute kind of "preferred_gpu".
Bruno
> From 43c16bbc7adbcb17aac73d09f046bf2779771c4c Mon Sep 17 00:00:00 2001
> From: Henrik Rydberg <rydberg@euromail.se>
> Date: Fri, 14 Nov 2014 20:01:21 +0100
> Subject: [PATCH v2] x86, ia64: Do not lose track of the EFI default VGA device
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Since commit 20cde694 in the 3.17 merge window, the EFI framebuffer
> depends on the VGA arbitration layer. However, the configuration does
> not reflect this, which leads to a hard-to-find bug when FB_EFI is
> configured without VGA_ARB. Add a select clause to remedy this.
>
> Cc: Bruno Prémont <bonbons@linux-vserver.org>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> drivers/video/fbdev/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index c7bf606..1615a1b 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -761,6 +761,7 @@ config FB_EFI
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> + select VGA_ARB if (PCI && !S390)
> help
> This is the EFI frame buffer device driver. If the firmware on
> your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
^ permalink raw reply
* Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device
From: Henrik Rydberg @ 2014-11-14 19:11 UTC (permalink / raw)
To: Bruno Prémont
Cc: Peter Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Bjorn Helgaas, linux-fbdev, linux-kernel
In-Reply-To: <20141114154252.0fb66bba@pluto.restena.lu>
Hi Bruno,
> So it would need to at least be select VGA_ARB if (PCI && !S390)
> in order to not have broken kernel configuration (in more or less
> exotic cases) while depends on VGA_ARB would be the only correct option
> if the rule 'select only allowed for leafs' is enforced.
Here is a tested patch that does just that, thanks for the suggestion.
Henrik
From 43c16bbc7adbcb17aac73d09f046bf2779771c4c Mon Sep 17 00:00:00 2001
From: Henrik Rydberg <rydberg@euromail.se>
Date: Fri, 14 Nov 2014 20:01:21 +0100
Subject: [PATCH v2] x86, ia64: Do not lose track of the EFI default VGA device
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Since commit 20cde694 in the 3.17 merge window, the EFI framebuffer
depends on the VGA arbitration layer. However, the configuration does
not reflect this, which leads to a hard-to-find bug when FB_EFI is
configured without VGA_ARB. Add a select clause to remedy this.
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
drivers/video/fbdev/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c7bf606..1615a1b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -761,6 +761,7 @@ config FB_EFI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VGA_ARB if (PCI && !S390)
help
This is the EFI frame buffer device driver. If the firmware on
your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
--
2.1.3
^ permalink raw reply related
* Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
From: Tony Lindgren @ 2014-11-14 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5465AFF6.506@ti.com>
* Tero Kristo <t-kristo@ti.com> [141113 23:33]:
> On 11/14/2014 01:58 AM, Tony Lindgren wrote:
>
> The PRCM/clock cleanups that I have under work basically splits the clock
> inits under their respective IP blocks; currently everything is registered
> under generic PRCM. System control module will be one of the clock providers
> (and is going to look like a driver), which will be registering its own
> clocks.
Yes that's nice. The clock modules in the SCM should probably use the
syscon mapping unless there's a clear separate IO area for them. And
then use pinctrl for registers that are muxes for external pins unless
they are in some dedicated clock register area.
> This doesn't change the fact that pinctrl is directly mapping its
> own register space atm though, it might be possible to re-route this to use
> the generic system control module if need be though.
Mapping dedicated IO areas to individual drivers is not a problem. These
drivers can eventually be children of a core SCM driver if needed.
> I guess its just a political decision which way we want to go, currently we
> have lots of system control clocks under the clock data (for
> AM33xx,AM43xx,OMAP3), but we can remove these easily if need be. In some
> cases it is nicer to have the data in the clock tree though, the drivers
> don't need to care if they are touching a clock or a pinctrl entity. Some
> people have been converting additional stuff to CCF outside of PRCM, like
> Archit did some work to try and get control module clock support for DRA7,
> and Tomi has been talking to convert some of the DSS internal clocks to CCF
> also.
Setting up CCF drivers for SCM makes sense to me. I suggest the
following guidelines:
1. If there's a clear separate dedicated IO area in SCM, it can be
a driver implementing a Linux generic framework for CCF, regulators,
pinctrl, or PHY.
2. For the random control registers, we should use syscon or
pinctrl-single to implement Linux generic framwork functions for
CCF, regulators, pinctrl or PHY.
3. For resource management, we can have a core SCM driver that takes
care of the save and restore of registers and clocking if needed.
I believe currently SCM clocks are always enabled though. We can
set the drivers in #1 and #2 abobe to be childer of the core SCM
driver if we ever need to manage clocks during runtime.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
From: Tony Lindgren @ 2014-11-14 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANOLnONkQu-BBvZH5nb+VngCxq=xnk60JkTd6Jha1uFt2j8gJQ@mail.gmail.com>
* Grazvydas Ignotas <notasas@gmail.com> [141114 06:38]:
> On Fri, Nov 14, 2014 at 1:58 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Paul Walmsley <paul@pwsan.com> [141113 15:01]:
> >> Hi
> >>
> >> On Thu, 13 Nov 2014, Tony Lindgren wrote:
> >>
> >> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [141113 03:33]:
> >> > > On 12/11/14 17:02, Tony Lindgren wrote:
> >> > >
> >> > > >> And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple
> >> > > >> places in the kernel. I wonder if adding a pinmux entry for it could
> >> > > >> cause some rather odd problems.
> >> > > >
> >> > > > They can all use pinctrl-single no problem.
> >> > >
> >> > > Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux,
> >> > > and we have code in mach-omap2 that also touch DEVCONF1, without any
> >> > > knowledge (and locking) between those...
> >> >
> >> > Hmm yeah the McBSP clock mux could be racy as the mux register for
> >> > McBSP is treated as a clock. This register muxes the clock between
> >> > external pin and internal clock. Considering that this should be
> >> > selectable at board level as the external clock probably needs to be
> >> > used if level shifters are being used, it should be really handled by
> >> > pinctrl-single.
> >> >
> >> > The other use for hsmmc.c and pdata-quirks.c for the one time mux for
> >> > MMC clock from the MMC clock pin. That can be done with pinctrl-single
> >> > from the MMC driver too for DT based booting.
> >> >
> >> > Then we just have the save and restore of the registers for
> >> > off-idle.
> >> >
> >> > > So _maybe_ that's not an issue, as the pinmux config we have here is
> >> > > fixed, and done once at boot time, and maybe the code in mach-omap2 that
> >> > > touch DEVCONF1 is also ran just once and not at the same time as the
> >> > > pinmux. But I don't know if that's so.
> >> >
> >> > It seems we could just do a read-only check for McBSP in the clock
> >> > code for the mux register, or even completely drop that code from
> >> > cclock3xxx_data.c and start using the pinctrl for that mux.
> >> >
> >> > Paul & Tero, got any comments here?
> >>
> >> It's best to move all of the SCM register reads/writes to an SCM IP block
> >> driver. This driver would be the only entity that would touch the SCM IP
> >> block registers - no other code on the system would touch it (perhaps
> >> aside from anything needed for early init). The SCM driver would enforce
> >> mutual exclusion via a spinlock, so concurrent SCM register modifications
> >> wouldn't flake out. Then the SCM driver would register clocks with the
> >> CCF, register pins with the pinctrl subsystem, etc. etc.
> >
> > We actually do have that with pinctrl-single + syscon. We certainly
> > need to implement more Linux framework drivers for the SCM registers.
> > Things like regulators, clocks, and PHYs, but they should use
> > pinctrl-single + syscon. See the the pbias-regulator.c for example.
> >
> > Looking at the McBSP clock handling, threre's yet more handling of
> > the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets
> > alled from omap_mcbsp_dai_set_dai_sysclk.
> >
> > To me it seems that if we handle the DEVCONF with pinctrl-single, we
> > don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src.
> > Having the mux register as the clock enable register is not nice..
> > Who knows what the clock coming from the external pin might be :)
>
> How will audio do dynamic muxing without that code?
> The pin must be remuxed back to internal clock when audio stops, or
> else PM breaks.
There's a standard way of dealing with that already available. We can
just have runtime_pm functions call pinctrl_pm_select_sleep_state()
and pinctrl_pm_select_default_state().
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 01/15] mfd: add new driver for Sharp LoCoMo
From: Dmitry Eremin-Solenikov @ 2014-11-14 15:30 UTC (permalink / raw)
To: Mark Brown
Cc: Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, Linux Input,
linux-leds@vger.kernel.org, linux-spi@vger.kernel.org,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
Andrea Adami, Russell King, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Lee Jones
In-Reply-To: <20141114151000.GC3815@sirena.org.uk>
2014-11-14 18:10 GMT+03:00 Mark Brown <broonie@kernel.org>:
> On Fri, Nov 14, 2014 at 04:47:00PM +0400, Dmitry Eremin-Solenikov wrote:
>
>> I'm actually looking at the regulator interface. Since this DAC serves mostly
>> like a (semi-)constant voltage interface, would it be rather logical to use
>> regulator subsystem to drive it?
>
> Possibly... it's mostly a function of what the consumers of the
> functionality look like - if that code looks weird calling into the
> regulator API then it's bad, if that code looks OK it's fine. I haven't
> looked at the hardware at all so don't have strong feelings either way
> so long as the result looks tasteful.
The DAC is used in backlight driver (control brightness) and in ASoC
machine driver (master joined volume).
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 01/15] mfd: add new driver for Sharp LoCoMo
From: Mark Brown @ 2014-11-14 15:10 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, Linux Input,
linux-leds@vger.kernel.org, linux-spi@vger.kernel.org,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
Andrea Adami, Russell King, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Lee Jones
In-Reply-To: <CALT56yOtjNbYOWM4ba5yP8pz7bNLY5BWpkkpfmv5QZU-7Y5u_g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 583 bytes --]
On Fri, Nov 14, 2014 at 04:47:00PM +0400, Dmitry Eremin-Solenikov wrote:
> I'm actually looking at the regulator interface. Since this DAC serves mostly
> like a (semi-)constant voltage interface, would it be rather logical to use
> regulator subsystem to drive it?
Possibly... it's mostly a function of what the consumers of the
functionality look like - if that code looks weird calling into the
regulator API then it's bad, if that code looks OK it's fine. I haven't
looked at the hardware at all so don't have strong feelings either way
so long as the result looks tasteful.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device
From: Henrik Rydberg @ 2014-11-14 15:07 UTC (permalink / raw)
To: Bruno Prémont
Cc: Peter Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Bjorn Helgaas, linux-fbdev, linux-kernel
In-Reply-To: <20141114154252.0fb66bba@pluto.restena.lu>
On 11/14/2014 03:42 PM, Bruno Prémont wrote:
> On Fri, 14 Nov 2014 13:53:30 +0100 Henrik Rydberg wrote:
>> Since commit 20cde694027e ("x86, ia64: Move EFI_FB
>> vga_default_device() initialization to pci_vga_fixup()") in the 3.17
>> merge window, the EFI framebuffer depends on the VGA arbitration
>> layer. However, the configuration does not reflect this, which leads
>> to a hard-to-find bug when FB_EFI is configured without VGA_ARB. Add a
>> select clause to remedy this.
>
> Could you be more verbose in why it depends on/needs VGA_ARB?
When the EFI framebuffer is configured but not VGA_ARB, the kernel manages to
lose track of the default VGA device in some cases. As a result, the X11
nouveau driver fails on my MacBookAir3,1 (GeForce 320M, nv50, 0xaf), which
is booting in EFI_STUB mode.
The code to select the right PCI device was literally moved from efifb.c to the
internals of vgaarb. The PCI sysfs layer seems to depend on
vga_default_device(), which is only defined when VGA_ARB is set.
> With EFI starting to show up on ARM this is not necessarily true
> (no PCI -> no VGA_ARB arbitration).
>
> So it would need to at least be select VGA_ARB if (PCI && !S390)
> in order to not have broken kernel configuration (in more or less
> exotic cases) while depends on VGA_ARB would be the only correct option
> if the rule 'select only allowed for leafs' is enforced.
I agree that the tie probably should be somewhere else. I am fine with any
combination of flags that respects the fact that efifb used to define
vga_default_device(), apparently for good reason.
Thanks,
Henrik
^ permalink raw reply
* Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
From: Jyri Sarha @ 2014-11-14 15:05 UTC (permalink / raw)
To: Vladimir Zapolskiy, alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, liam.r.girdwood, tomi.valkeinen, broonie
In-Reply-To: <5466139E.5040308@mentor.com>
On 11/14/2014 04:37 PM, Vladimir Zapolskiy wrote:
> Hi Jyri,
>
> On 12.11.2014 16:41, Jyri Sarha wrote:
>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>> ---
>> drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
>> index a6e08ff..6d129f2 100644
>> --- a/drivers/video/fbdev/omap2/dss/hdmi.h
>> +++ b/drivers/video/fbdev/omap2/dss/hdmi.h
>> @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
>> struct hdmi_audio_format *aud_fmt);
>> void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp,
>> struct hdmi_audio_dma *aud_dma);
>> -static inline bool hdmi_mode_has_audio(int mode)
>> +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg)
>> {
>> - return mode = HDMI_HDMI ? true : false;
>> + return cfg->hdmi_dvi_mode = HDMI_HDMI ? true : false;
>> }
>>
>> /* HDMI DRV data */
>>
>
> would it be possible for you to rearrange the changes preserving the
> following sequence?
>
> 1) 13/19
> 2) 15/19
> 3) 11/19
> 4) 14/19
> 5) 16/19
>
Sure, I can do that. Everything should be fine in that order too.
> Otherwise I'm worried that someone's git rebase may fail.
>
But do not follow why. Did you notice that 10/19 removes the config
options that enable the pieces of code that are deleted in 13/19 and
15/19. IOW, the code that uses hdmi_mode_has_audio() (and would become
broken by 11/19) is already disabled by 10/19. Git-wise I see no problem
either.
I'll rearrange the patches if you still insist there is a problem with
current order, but I would like to understand why.
Best regards,
Jyri
^ permalink raw reply
* Re: [PATCH] x86, ia64: Do not lose track of the EFI default VGA device
From: Bruno Prémont @ 2014-11-14 14:42 UTC (permalink / raw)
To: Henrik Rydberg
Cc: Peter Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Bjorn Helgaas, linux-fbdev, linux-kernel
In-Reply-To: <1415969610-1469-1-git-send-email-rydberg@euromail.se>
On Fri, 14 Nov 2014 13:53:30 +0100 Henrik Rydberg wrote:
> Since commit 20cde694027e ("x86, ia64: Move EFI_FB
> vga_default_device() initialization to pci_vga_fixup()") in the 3.17
> merge window, the EFI framebuffer depends on the VGA arbitration
> layer. However, the configuration does not reflect this, which leads
> to a hard-to-find bug when FB_EFI is configured without VGA_ARB. Add a
> select clause to remedy this.
Could you be more verbose in why it depends on/needs VGA_ARB?
With EFI starting to show up on ARM this is not necessarily true
(no PCI -> no VGA_ARB arbitration).
So it would need to at least be select VGA_ARB if (PCI && !S390)
in order to not have broken kernel configuration (in more or less
exotic cases) while depends on VGA_ARB would be the only correct option
if the rule 'select only allowed for leafs' is enforced.
Bruno
> Cc: Bruno Prémont <bonbons@linux-vserver.org>
> Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> ---
> Hi Peter,
>
> I stumbled upon this bug from the 3.17 merge window when updating to
> Linus's 3.18 git head yesterday. The patch has been tested on two
> different EFI machines; one that needs the patch and one that does not.
>
> Thanks,
> Henrik
>
> drivers/video/fbdev/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index c7bf606..81b21bc 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -761,6 +761,7 @@ config FB_EFI
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> + select VGA_ARB
> help
> This is the EFI frame buffer device driver. If the firmware on
> your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
^ permalink raw reply
* Re: [PATCH v7.1 11/19] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
From: Vladimir Zapolskiy @ 2014-11-14 14:37 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, tomi.valkeinen
In-Reply-To: <8047b50c76efecd72e7219f7871c59cc4a8ee5f5.1415803065.git.jsarha@ti.com>
Hi Jyri,
On 12.11.2014 16:41, Jyri Sarha wrote:
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
> drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h
> index a6e08ff..6d129f2 100644
> --- a/drivers/video/fbdev/omap2/dss/hdmi.h
> +++ b/drivers/video/fbdev/omap2/dss/hdmi.h
> @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
> struct hdmi_audio_format *aud_fmt);
> void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp,
> struct hdmi_audio_dma *aud_dma);
> -static inline bool hdmi_mode_has_audio(int mode)
> +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg)
> {
> - return mode = HDMI_HDMI ? true : false;
> + return cfg->hdmi_dvi_mode = HDMI_HDMI ? true : false;
> }
>
> /* HDMI DRV data */
>
would it be possible for you to rearrange the changes preserving the
following sequence?
1) 13/19
2) 15/19
3) 11/19
4) 14/19
5) 16/19
Otherwise I'm worried that someone's git rebase may fail.
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
From: Grazvydas Ignotas @ 2014-11-14 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141113235840.GS26481@atomide.com>
On Fri, Nov 14, 2014 at 1:58 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Paul Walmsley <paul@pwsan.com> [141113 15:01]:
>> Hi
>>
>> On Thu, 13 Nov 2014, Tony Lindgren wrote:
>>
>> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [141113 03:33]:
>> > > On 12/11/14 17:02, Tony Lindgren wrote:
>> > >
>> > > >> And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple
>> > > >> places in the kernel. I wonder if adding a pinmux entry for it could
>> > > >> cause some rather odd problems.
>> > > >
>> > > > They can all use pinctrl-single no problem.
>> > >
>> > > Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux,
>> > > and we have code in mach-omap2 that also touch DEVCONF1, without any
>> > > knowledge (and locking) between those...
>> >
>> > Hmm yeah the McBSP clock mux could be racy as the mux register for
>> > McBSP is treated as a clock. This register muxes the clock between
>> > external pin and internal clock. Considering that this should be
>> > selectable at board level as the external clock probably needs to be
>> > used if level shifters are being used, it should be really handled by
>> > pinctrl-single.
>> >
>> > The other use for hsmmc.c and pdata-quirks.c for the one time mux for
>> > MMC clock from the MMC clock pin. That can be done with pinctrl-single
>> > from the MMC driver too for DT based booting.
>> >
>> > Then we just have the save and restore of the registers for
>> > off-idle.
>> >
>> > > So _maybe_ that's not an issue, as the pinmux config we have here is
>> > > fixed, and done once at boot time, and maybe the code in mach-omap2 that
>> > > touch DEVCONF1 is also ran just once and not at the same time as the
>> > > pinmux. But I don't know if that's so.
>> >
>> > It seems we could just do a read-only check for McBSP in the clock
>> > code for the mux register, or even completely drop that code from
>> > cclock3xxx_data.c and start using the pinctrl for that mux.
>> >
>> > Paul & Tero, got any comments here?
>>
>> It's best to move all of the SCM register reads/writes to an SCM IP block
>> driver. This driver would be the only entity that would touch the SCM IP
>> block registers - no other code on the system would touch it (perhaps
>> aside from anything needed for early init). The SCM driver would enforce
>> mutual exclusion via a spinlock, so concurrent SCM register modifications
>> wouldn't flake out. Then the SCM driver would register clocks with the
>> CCF, register pins with the pinctrl subsystem, etc. etc.
>
> We actually do have that with pinctrl-single + syscon. We certainly
> need to implement more Linux framework drivers for the SCM registers.
> Things like regulators, clocks, and PHYs, but they should use
> pinctrl-single + syscon. See the the pbias-regulator.c for example.
>
> Looking at the McBSP clock handling, threre's yet more handling of
> the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets
> alled from omap_mcbsp_dai_set_dai_sysclk.
>
> To me it seems that if we handle the DEVCONF with pinctrl-single, we
> don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src.
> Having the mux register as the clock enable register is not nice..
> Who knows what the clock coming from the external pin might be :)
How will audio do dynamic muxing without that code?
The pin must be remuxed back to internal clock when audio stops, or
else PM breaks.
Gražvydas
^ permalink raw reply
* Re: [PATCH v5 1/5] dt-bindings: simplefb: Specify node location and handoff related properties
From: Tomi Valkeinen @ 2014-11-14 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415962996-31712-1-git-send-email-hdegoede@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]
On 14/11/14 13:03, Hans de Goede wrote:
> Since simplefb nodes do not relate directly to hw typically they have been
> placed in the root of the devicetree. As the represent runtime information
> having them as sub-nodes of /chosen is more logical, specify this.
>
> Also specify when to set the chosen stdout-path property to a simplefb node.
>
> For reliable handover to a hardware specific driver, that driver needs to
> know which simplefb to unregister when taking over, specify how the hw driver
> can find the matching simplefb node.
>
> Last add some advice on how to fill and use simplefb nodes from a firmware
> pov.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Ok, so I have pushed this and the other simplefb series to fbdev for-next.
I can still refresh the whole series if need be, but if possible I'd
rather take any new changes as patches on top of the current ones.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND 0/5] arm: sa1100: add cpu clock for fbdev and pcmcia
From: Dmitry Eremin-Solenikov @ 2014-11-14 13:05 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1415259677-18770-1-git-send-email-dbaryshkov@gmail.com>
Dear Russell,
2014-11-06 10:41 GMT+03:00 Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>:
> These patches are required to make SL-5500 (collie) to work properly.
> Framebuffer maintainer added his ack to the respective patch. PCMCIA
> subsystem seems to be unmaintained at this moment. Russell, could you
> please review and hopefully ack these patches?
>
> On SA-1100 framebuffer and PCMCIA drivers make use of cpufreq_get(0)
> function call to determine the cpu frequency. Russell's commit
> 1937f5b91833e2e8e53bcc821fc7a5fbe6ccb9b5 (ARM: fix sa1100 build) fixed
> the build issues, but broke two devices (Collie and Jornada720). For
> those two boards the cpufreq code gets compiled but is not enabled (as
> board files do not provide timing information for the CPUFREQ driver).
> Thus cpufreq_get(0) returns incorrect value and incorrect timings get
> programmed into the hardware.
>
> PXA2xx (the very similar platform) uses Clock API to determine CPU
> frequency both in framebuffer and PCMCIA drivers. These patches make
> similar changes to StrongARM drivers.
We can continue to carry over this patch set in local tree. Having a grave bug
in upstream kernels. What is the purpose of upstream kernel then? Why did
we have so many talks about bad practice of 'vendor/local/private' Linux trees?
Do you see anything wrong with this patchset? Why do you keep on ignoring it?
Did you stop caring about sa11x0?
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] x86, ia64: Do not lose track of the EFI default VGA device
From: Henrik Rydberg @ 2014-11-14 12:53 UTC (permalink / raw)
To: Peter Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: Bjorn Helgaas, linux-fbdev, linux-kernel, Henrik Rydberg,
Bruno Prémont
Since commit 20cde694027e ("x86, ia64: Move EFI_FB
vga_default_device() initialization to pci_vga_fixup()") in the 3.17
merge window, the EFI framebuffer depends on the VGA arbitration
layer. However, the configuration does not reflect this, which leads
to a hard-to-find bug when FB_EFI is configured without VGA_ARB. Add a
select clause to remedy this.
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
Hi Peter,
I stumbled upon this bug from the 3.17 merge window when updating to
Linus's 3.18 git head yesterday. The patch has been tested on two
different EFI machines; one that needs the patch and one that does not.
Thanks,
Henrik
drivers/video/fbdev/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c7bf606..81b21bc 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -761,6 +761,7 @@ config FB_EFI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VGA_ARB
help
This is the EFI frame buffer device driver. If the firmware on
your platform is EFI 1.10 or UEFI 2.0, select Y to add support for
--
2.1.3
^ permalink raw reply related
* Re: [PATCH 02/15] GPIO: port LoCoMo gpio support from old driver
From: Dmitry Eremin-Solenikov @ 2014-11-14 12:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Brown, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, Linux Input,
linux-leds@vger.kernel.org, linux-spi@vger.kernel.org,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
Andrea Adami, Russell King, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Lee Jones, Jingoo
In-Reply-To: <CACRpkdZiari6CtWq1kBCvX3cwwatJiHAuWUb40WSUEfjZjk+Lg@mail.gmail.com>
2014-11-14 13:11 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
> On Tue, Nov 11, 2014 at 2:16 PM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>
>> Just to better understand your suggestions: do you want me to convert
>> to regmap only gpio driver or do you suggest to convert all LoCoMo drivers?
>
> Um... I was just thinking about this one usecase.
I ended up converting all drivers. It allowed me to clean up several points
in the driver.
>
> It's no big deal, the other review comments are more important.
Fixed most of the comments. Last remaining issue is factoring out m62332
interface.
>> That is doable, of course, but the amount of changes is overwhelming.
>> Also I'm concerned about the performance impact from going through
>> regmap layers.
>
> Is it on a critical path? The current locking isn't any less invasive
> AFAICT.
>
> Yours,
> Linus Walleij
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 01/15] mfd: add new driver for Sharp LoCoMo
From: Dmitry Eremin-Solenikov @ 2014-11-14 12:47 UTC (permalink / raw)
To: Mark Brown
Cc: Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-gpio@vger.kernel.org, Linux Input,
linux-leds@vger.kernel.org, linux-spi@vger.kernel.org,
linux-fbdev@vger.kernel.org, alsa-devel@alsa-project.org,
Andrea Adami, Russell King, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie, Samuel Ortiz, Lee Jones
In-Reply-To: <20141105202405.GJ8509@sirena.org.uk>
Hello,
2014-11-05 23:24 GMT+03:00 Mark Brown <broonie@kernel.org>:
> On Thu, Nov 06, 2014 at 12:02:49AM +0400, Dmitry Eremin-Solenikov wrote:
>> 2014-11-03 16:41 GMT+03:00 Linus Walleij <linus.walleij@linaro.org>:
>
>> > The point is still the same: no unrelated code in drivers/mfd,
>> > then either use IIO DAC as a middle layer or sink the DAC handling
>> > into respective subdriver, i.e. push it into the backlight or
>> > volume directly then.
>
>> The problem is that the DAC is equally used by backlight and by sound
>> device (WIP).
>> What about true i2c device driver sitting in drivers/misc and exporting a regmap
>> of 2 8-bit registers?
>
> If it can just export registers that sounds like a MFD. If it needs to
> export functionality then like Linus says the IIO subsystem abstracts
> DACs.
I took a look at IIO subsystem. Thanks for the pointer. Indeed max517 driver
can drive m62332 DAC with minimal modifications. However write support
of the consumer interface is non-existing yet (which would be required
to support DACs in unified manner).
I'm actually looking at the regulator interface. Since this DAC serves mostly
like a (semi-)constant voltage interface, would it be rather logical to use
regulator subsystem to drive it?
--
With best wishes
Dmitry
^ permalink raw reply
* SSD1306 OLED driver
From: Ssagarr Patil @ 2014-11-14 11:51 UTC (permalink / raw)
To: linux-fbdev
Hi,
I have the SSD1306 oled device connected via spi, will the same driver work ? as the current one is based on i2c what all mods would be required to have it working with SPI ?
Thanks & Regards,
Sagar
^ permalink raw reply
* Re: [PATCH 4/7] ARM: dts: sun6i: Add simplefb node
From: Maxime Ripard @ 2014-11-14 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5465D9B1.8010707@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2304 bytes --]
On Fri, Nov 14, 2014 at 11:30:09AM +0100, Hans de Goede wrote:
> Hi,
>
> On 11/14/2014 11:24 AM, Maxime Ripard wrote:
> > On Thu, Nov 13, 2014 at 06:52:57PM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 11/13/2014 05:46 PM, Maxime Ripard wrote:
> >>> Hi,
> >>>
> >>> On Thu, Nov 13, 2014 at 10:31:46AM +0100, Hans de Goede wrote:
> >>>> Add a simplefb template node for u-boot to further fill and activate.
> >>>>
> >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>>> ---
> >>>> arch/arm/boot/dts/sun6i-a31.dtsi | 10 ++++++++++
> >>>> 1 file changed, 10 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> >>>> index 543f895..438952e 100644
> >>>> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> >>>> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> >>>> @@ -62,6 +62,16 @@
> >>>> ethernet0 = &gmac;
> >>>> };
> >>>>
> >>>> + chosen {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <1>;
> >>>> + ranges;
> >>>> +
> >>>> + framebuffer0 {
> >>>> + compatible = "simple-framebuffer";
> >>>> + status = "disabled";
> >>>
> >>> Aren't we suppose to have clocks in there too?
> >>
> >> I deliberately left them out as they are not needed on sun6i, once the blocks
> >> are setup ahb access is not necessary, but it seems that the ahb_gate bits
> >> in sun4i / sun5i / sun7i double as a reset. Toggling them on / off / on breaks
> >> the mode, while toggling module clocks on / off / on only causes a glitch.
> >>
> >> Since the sun6i has a separate reset controller, the clock gates seem to really
> >> only control ahb access which is not necessary once the mode has been set up.
> >
> > Ok. That can always be changed in the future if we ever find we need
> > them anyway.
> >
> > I'll merge these four patches as soon as the bindings doc is
> > acked-by/merged by Grant or any other DT maintainer.
>
> Note these patches are using framebuffer0 rather then framebuffer0-hdmi as node
> name, which may cause issues if we later want to add lcd support. So I've a v2
> coming which changes the name to framebuffer0-hdmi, please merge that instead.
Ok :)
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v5 5/5] simplefb: Change simplefb_init from module_init to fs_initcall
From: Hans de Goede @ 2014-11-14 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415962996-31712-1-git-send-email-hdegoede@redhat.com>
One of the reasons for having the simplefb nodes in /chosen, and doing
explicit enumeration of the nodes there, is too allow enumerating them sooner,
so that we get a console earlier on.
Doing this earlier then fs_initcall is not useful, since the fb only turns
into a console when fbcon intializes, which is a fs_initcall too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
--
Changes in v4 (of the patch-set):
-Drop the comment about using fs_initcall vs module_exit, as we no longer have
a module_exit
---
drivers/video/fbdev/simplefb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 74c5edd..8be9754 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -413,7 +413,7 @@ static int __init simplefb_init(void)
return 0;
}
-module_init(simplefb_init);
+fs_initcall(simplefb_init);
MODULE_AUTHOR("Stephen Warren <swarren@wwwdotorg.org>");
MODULE_DESCRIPTION("Simple framebuffer driver");
--
2.1.0
^ permalink raw reply related
* [PATCH v5 4/5] fbcon: Change fbcon_init from module_init to fs_initcall
From: Hans de Goede @ 2014-11-14 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415962996-31712-1-git-send-email-hdegoede@redhat.com>
Various fb drivers register themselves before module_init so as to have a
console as early as possible, this is of little use if fbcon does not
initialize early too.
Fbcon cannot initialize earlier then fs_initcall, because then the creation
of /sys/class/graphics/fbcon will fail.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/video/console/fbcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index eb976ee..ea43724 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3624,7 +3624,7 @@ static int __init fb_console_init(void)
return 0;
}
-module_init(fb_console_init);
+fs_initcall(fb_console_init);
#ifdef MODULE
--
2.1.0
^ permalink raw reply related
* [PATCH v5 3/5] simplefb: Add support for enumerating simplefb dt nodes in /chosen
From: Hans de Goede @ 2014-11-14 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1415962996-31712-1-git-send-email-hdegoede@redhat.com>
Update simplefb to support the new preferred location for simplefb dt nodes
under /chosen.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
--
Changes in v2:
-Make name array larger in case we ever encounter more then 10000 framebuffers
Changes in v3:
-Switch to for_each_child_of_node to loop over the nodes under chosen
Changes in v4:
-Wrap the chosen enumeration code in #ifdef CONFIG_OF, as simplefb is used on
non devicetree platforms too
-simplefb can only be built-in, so drop the module_exit function calling
platform_driver_unregister
Changes in v5:
-Cleanup #ifdef CONFIG_OF handling
---
drivers/video/fbdev/simplefb.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index d192946..74c5edd 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -27,6 +27,7 @@
#include <linux/platform_data/simplefb.h>
#include <linux/platform_device.h>
#include <linux/clk-provider.h>
+#include <linux/of_platform.h>
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -392,7 +393,27 @@ static struct platform_driver simplefb_driver = {
.probe = simplefb_probe,
.remove = simplefb_remove,
};
-module_platform_driver(simplefb_driver);
+
+static int __init simplefb_init(void)
+{
+ int ret;
+ struct device_node *np;
+
+ ret = platform_driver_register(&simplefb_driver);
+ if (ret)
+ return ret;
+
+ if (IS_ENABLED(CONFIG_OF) && of_chosen) {
+ for_each_child_of_node(of_chosen, np) {
+ if (of_device_is_compatible(np, "simple-framebuffer"))
+ of_platform_device_create(np, NULL, NULL);
+ }
+ }
+
+ return 0;
+}
+
+module_init(simplefb_init);
MODULE_AUTHOR("Stephen Warren <swarren@wwwdotorg.org>");
MODULE_DESCRIPTION("Simple framebuffer driver");
--
2.1.0
^ 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