* 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
* [PATCH v5 2/5] of.h: Keep extern declaration of of_* variables when !CONFIG_OF
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>
Keep the extern declaration of of_allnodes and friends, when building without
of support, this way code using them can be written like this:
if (IS_ENABLED(CONFIG_OF_PLATFORM) && of_chosen) {
for_each_child_of_node(of_chosen, np)
...
}
And rely on the compiler optimizing it away, avoiding the need for #ifdef-ery.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
include/linux/of.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 6545e7a..f83ca9d 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -105,8 +105,6 @@ static inline struct device_node *of_node_get(struct device_node *node)
static inline void of_node_put(struct device_node *node) { }
#endif /* !CONFIG_OF_DYNAMIC */
-#ifdef CONFIG_OF
-
/* Pointer for first entry in chain of all nodes. */
extern struct device_node *of_allnodes;
extern struct device_node *of_chosen;
@@ -114,6 +112,7 @@ extern struct device_node *of_aliases;
extern struct device_node *of_stdout;
extern raw_spinlock_t devtree_lock;
+#ifdef CONFIG_OF
static inline bool of_have_populated_dt(void)
{
return of_allnodes != NULL;
--
2.1.0
^ permalink raw reply related
* [PATCH v5 1/5] dt-bindings: simplefb: Specify node location and handoff related properties
From: Hans de Goede @ 2014-11-14 11:03 UTC (permalink / raw)
To: linux-arm-kernel
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>
--
Changes in v2:
-Add stdout-path to the example code
Changes in v3:
-Specify that the node name must be "framebuffer@<address>"
-Specify that the link to link simplefb node and display hw nodes to one
another for handover goes into the simplefb node, and must be called "display"
-Specify how aliases may be used to tell the OS how to number displays
-Update the example to reflect these changes
Changes in v4:
-Keep the size of the reg property in the example as it was before
Changes in v5:
-Specify that stdout-path property should work the same way as the aliases,
or just point to an alias
-Document naming scheme for pre-populated simplefb nodes
---
.../bindings/video/simple-framebuffer.txt | 58 +++++++++++++++++++++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 8f35718..f8fb7e6 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -4,6 +4,40 @@ A simple frame-buffer describes a frame-buffer setup by firmware or
the bootloader, with the assumption that the display hardware has already
been set up to scan out from the memory pointed to by the reg property.
+Since simplefb nodes represent runtime information they must be sub-nodes of
+the chosen node (*). Simplefb nodes must be named "framebuffer@<address>".
+
+If the devicetree contains nodes for the display hardware used by a simplefb,
+then the simplefb node must contain a property called "display", which
+contains a phandle pointing to the primary display hw node, so that the OS
+knows which simplefb to disable when handing over control to a driver for the
+real hardware. The bindings for the hw nodes must specify which node is
+considered the primary node.
+
+It is advised to add display# aliases to help the OS determine how to number
+things. If display# aliases are used, then if the simplefb node contains a
+"display" property then the /aliases/display# path must point to the display
+hw node the "display" property points to, otherwise it must point directly
+to the simplefb node.
+
+If a simplefb node represents the preferred console for user interaction,
+then the chosen node's stdout-path property should point to it, or to the
+primary display hw node, as with display# aliases. If display aliases are
+used then it should be set to the alias instead.
+
+It is advised that devicetree files contain pre-filled, disabled framebuffer
+nodes, so that the firmware only needs to update the mode information and
+enable them. This way if e.g. later on support for more display clocks get
+added, the simplefb nodes will already contain this info and the firmware
+does not need to be updated.
+
+If pre-filled framebuffer nodes are used, they should be named
+"framebuffer#-<output>", e.g. "framebuffer0-hdmi". The output should be
+included in the name since different outputs typically require different
+clocks and the clocks are part of the pre-populated nodes. The firmware must
+rename the nodes to the standard "framebuffer@<address>" name using the
+runtime chosen address when enabling the nodes.
+
Required properties:
- compatible: "simple-framebuffer"
- reg: Should contain the location and size of the framebuffer memory.
@@ -19,14 +53,36 @@ Optional properties:
are expected to already be configured correctly. The OS must
ensure these clocks are not modified or disabled while the
simple framebuffer remains active.
+- display : phandle pointing to the primary display hardware node
Example:
- framebuffer {
+aliases {
+ display0 = &lcdc0;
+}
+
+chosen {
+ framebuffer0: framebuffer@1d385000 {
compatible = "simple-framebuffer";
reg = <0x1d385000 (1600 * 1200 * 2)>;
width = <1600>;
height = <1200>;
stride = <(1600 * 2)>;
format = "r5g6b5";
+ clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
+ display = <&lcdc0>;
+ };
+ stdout-path = "display0";
+};
+
+soc@01c00000 {
+ lcdc0: lcdc@1c0c000 {
+ compatible = "allwinner,sun4i-a10-lcdc";
+ ...
};
+};
+
+
+*) Older devicetree files may have a compatible = "simple-framebuffer" node
+in a different place, operating systems must first enumerate any compatible
+nodes found under chosen and then check for other compatible nodes.
--
2.1.0
^ permalink raw reply related
* [PATCH v7] simplefb: add clock handling code
From: Hans de Goede @ 2014-11-14 11:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Luc Verhaegen <libv@skynet.be>
This claims and enables clocks listed in the simple framebuffer dt node.
This is needed so that the display engine, in case the required clocks
are known by the kernel code and are described in the dt, will remain
properly enabled.
Signed-off-by: Luc Verhaegen <libv@skynet.be>
[hdegoede@redhat.com: Change clks from list to dynamic array]
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
--
Changes in v4:
-change clks from linkedlist to dynamic allocated array
-propagate EPROBE_DEFER up from simplefb_clocks_init to simplefb_probe
Changes in v6:
-Wrap the clock code in #ifdef CONFIG_OF, as simplefb is used on non
devicetree platforms too
Changes in v7:
-Put function return type and the rest of the prototype on the same line
-Cleanup #ifdef CONFIG_OF handling
---
drivers/video/fbdev/simplefb.c | 108 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 107 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index cdcf1fe..d192946 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -26,6 +26,7 @@
#include <linux/module.h>
#include <linux/platform_data/simplefb.h>
#include <linux/platform_device.h>
+#include <linux/clk-provider.h>
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -167,8 +168,105 @@ static int simplefb_parse_pd(struct platform_device *pdev,
struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
+#ifdef CONFIG_OF
+ int clk_count;
+ struct clk **clks;
+#endif
};
+#ifdef CONFIG_OF
+/*
+ * Clock handling code.
+ *
+ * Here we handle the clocks property of our "simple-framebuffer" dt node.
+ * This is necessary so that we can make sure that any clocks needed by
+ * the display engine that the bootloader set up for us (and for which it
+ * provided a simplefb dt node), stay up, for the life of the simplefb
+ * driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the clocks.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the clock definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_clocks_init(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct clk *clock;
+ int i, ret;
+
+ if (dev_get_platdata(&pdev->dev) || !np)
+ return 0;
+
+ par->clk_count = of_clk_get_parent_count(np);
+ if (par->clk_count <= 0)
+ return 0;
+
+ par->clks = kcalloc(par->clk_count, sizeof(struct clk *), GFP_KERNEL);
+ if (!par->clks)
+ return -ENOMEM;
+
+ for (i = 0; i < par->clk_count; i++) {
+ clock = of_clk_get(np, i);
+ if (IS_ERR(clock)) {
+ if (PTR_ERR(clock) = -EPROBE_DEFER) {
+ while (--i >= 0) {
+ if (par->clks[i])
+ clk_put(par->clks[i]);
+ }
+ kfree(par->clks);
+ return -EPROBE_DEFER;
+ }
+ dev_err(&pdev->dev, "%s: clock %d not found: %ld\n",
+ __func__, i, PTR_ERR(clock));
+ continue;
+ }
+ par->clks[i] = clock;
+ }
+
+ for (i = 0; i < par->clk_count; i++) {
+ if (par->clks[i]) {
+ ret = clk_prepare_enable(par->clks[i]);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "%s: failed to enable clock %d: %d\n",
+ __func__, i, ret);
+ clk_put(par->clks[i]);
+ par->clks[i] = NULL;
+ }
+ }
+ }
+
+ return 0;
+}
+
+static void simplefb_clocks_destroy(struct simplefb_par *par)
+{
+ int i;
+
+ if (!par->clks)
+ return;
+
+ for (i = 0; i < par->clk_count; i++) {
+ if (par->clks[i]) {
+ clk_disable_unprepare(par->clks[i]);
+ clk_put(par->clks[i]);
+ }
+ }
+
+ kfree(par->clks);
+}
+#else
+static int simplefb_clocks_init(struct simplefb_par *par,
+ struct platform_device *pdev) { return 0; }
+static void simplefb_clocks_destroy(struct simplefb_par *par) { }
+#endif
+
static int simplefb_probe(struct platform_device *pdev)
{
int ret;
@@ -236,6 +334,10 @@ static int simplefb_probe(struct platform_device *pdev)
}
info->pseudo_palette = par->palette;
+ ret = simplefb_clocks_init(par, pdev);
+ if (ret < 0)
+ goto error_unmap;
+
dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to 0x%p\n",
info->fix.smem_start, info->fix.smem_len,
info->screen_base);
@@ -247,13 +349,15 @@ static int simplefb_probe(struct platform_device *pdev)
ret = register_framebuffer(info);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to register simplefb: %d\n", ret);
- goto error_unmap;
+ goto error_clocks;
}
dev_info(&pdev->dev, "fb%d: simplefb registered!\n", info->node);
return 0;
+error_clocks:
+ simplefb_clocks_destroy(par);
error_unmap:
iounmap(info->screen_base);
error_fb_release:
@@ -264,8 +368,10 @@ error_fb_release:
static int simplefb_remove(struct platform_device *pdev)
{
struct fb_info *info = platform_get_drvdata(pdev);
+ struct simplefb_par *par = info->par;
unregister_framebuffer(info);
+ simplefb_clocks_destroy(par);
framebuffer_release(info);
return 0;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v4 2/4] simplefb: Add support for enumerating simplefb dt nodes in /chosen
From: Hans de Goede @ 2014-11-14 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6u3_GJA6pbDGX6puDhyJ2E9T+WujmzASw2VE+5-x9q9sA@mail.gmail.com>
Hi,
On 11/14/2014 10:28 AM, Grant Likely wrote:
> On Thu, Nov 13, 2014 at 7:23 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> 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
>> ---
>> 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 868099a..e381a53 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",
>> @@ -390,7 +391,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 __maybe_unused *np;
>> +
>> + ret = platform_driver_register(&simplefb_driver);
>> + if (ret)
>> + return ret;
>> +
>> +#ifdef CONFIG_OF
>> + for_each_child_of_node(of_chosen, np) {
>> + if (of_device_is_compatible(np, "simple-framebuffer"))
>> + of_platform_device_create(np, NULL, NULL);
>> + }
>> +#endif
>
> Nit: Kind of ugly. This should work instead:
>
> if (IS_ENABLED(CONFIG_OF_PLATFORM) && 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);
> }
>
> And move the forward declaration of of_chosen in include/linux/of.h up
> 5 lines so that it is always declared. gcc will optimize it out, but
> it will still get properly syntax checked on every build.
Ok, fixed for v5.
Regards,
Hans
^ permalink raw reply
* Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support
From: Jean-Francois Moine @ 2014-11-14 10:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Mark Brown, Jyri Sarha, peter.ujfalusi, liam.r.girdwood,
alsa-devel, linux-omap, linux-fbdev
In-Reply-To: <5464D1E6.4050508@ti.com>
On Thu, 13 Nov 2014 17:44:38 +0200
Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
[snip]
> >> a) Always keep the audio device operational, no matter what is the
> >> status of the video side. How should this work if the HDMI videomode or
> >> the HDMI monitor does not support audio? Is it desirable that the
> >> userspace has no idea that the audio is not actually going anywhere?
> >>
> >> b) Remove the audio device when audio support is not available. This
> >> kind of makes sense, as, well, there's no possibility for audio output.
> >> But maybe this is not how linux sound devices are supposed to behave?
> >>
> >> c) Return errors when playback is attempted when audio support is not
> >> available. Again, this kind of makes sense, as audio playback is not
> >> possible. But maybe this is also not how audio devices generally work.
> >>
> >> Jyri, were there some other options we discussed?
> >>
> >> Currently, the OMAP HDMI version does c). It's the easiest solution for us.
> >
> > Same for me, but checking the audio capability is done on audio streaming
> > start only.
>
> Hmm, I understood you have option a)? You said "I even let audio
> streaming start when the HDMI cable is
> disconnected".
The option a) is the one of the patch, but I am moving towards option c).
> With "audio support is not available" I mean also the case when the
> cable is not connected, as then we don't have EDID information, and thus
> we don't have a HDMI monitor with audio support on the other end.
What I was saying is: when the cable is connected, all audio/video
parameters are known. Then, when the cable is disconnected, there is
no reason, a priori, to change these parameters, and audio/video
streaming may continue. The problem might be raised later when an other
monitor with different parameters will be connected.
> So to clarify, our driver only has "audio support available" if:
> - we successfully read EDID
> - EDID shows it's a HDMI monitor
> - EDID shows it has audio support for the format we support (this we
> don't actually do yet)
>
> Otherwise we default to DVI, which means no audio.
>
> If, at any point, the situation changes to "no audio support available",
> the audio playback is aborted and starting new audio playback fails.
[snip]
So, to summarize, you need the information 'audio support available' on
the audio side.
It should not be difficult to export a function in the generic HDMI
driver for this job. This function would have the following arguments:
- device (child device of the HDMI transmitter)
- pin (output widget name)
- status (enable/disable)
and would:
- set the pin status so that the HDMI output would be included or not
in the audio path, and
- abort audio streaming on disabling audio.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* Re: [PATCH 4/7] ARM: dts: sun6i: Add simplefb node
From: Hans de Goede @ 2014-11-14 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20141114102417.GY20972@lukather>
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.
Regards,
Hans
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox