* [PATCH 0/2] Replace /include/ (dtc) with #include
From: Catalin Marinas @ 2014-01-27 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E63DD8.9070909@samsung.com>
On Mon, Jan 27, 2014 at 11:07:04AM +0000, Pankaj Dubey wrote:
> On 01/10/2014 07:16 PM, Pankaj Dubey wrote:
> > Replace /include/ (dtc) with #include (C pre-processor) for all ARM64
> > based SoC dts files.
> >
> > Pankaj Dubey (2):
> > arm64: dts: use #include for all AppliedMicro device tree files
> > arm64: dts: use #include for all ARM fast model device tree file
> >
> > arch/arm64/boot/dts/apm-mustang.dts | 2 +-
> > arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> Gentle ping.
It would be good to include some rationale behind this change and I'm
waiting for the DT guys to ack it.
--
Catalin
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Jyri Sarha @ 2014-01-27 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E6806A.2090109@metafoo.de>
On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
> Hi,
>
> I think you should try to get this in sync with the work Jean-Francois is
> currently doing[1]. Having the HDMI transmitter register a CODEC device is
> definitely the right approach, compared to the rather 'interesting'
> constraints stuff you do in patch 4.
>
Oh, Jean-Francois's patches are now out. I'll take those into use, but I
am afraid it still does not save me from the constraint stuff.
The most complex piece of code comes from limited sample-rate
availability, which is coming Beaglebone-Black desing (available i2s
master clock), not from the HDMI encoder itself. It does not help with
the stereo only limitation either, because it comes from the one wire
only audio data connection on BBB.
Support for S16_LE could maybe be added if the tda998x specific codec
would fiddle with CTS_N predivider-setting (K select) according to the
used sample width. But it appears Cobox plays all the sample formats
fine without this change, so the question is if playing around with
CTS_N predivider would break already working support there (something to
be tested).
Best regards,
Jyri
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Russell King - ARM Linux @ 2014-01-27 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E6175F.1050401@linaro.org>
On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>> ARM and ARM64 are the only two architectures implementing
>> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>>
>> We have secondary_start_kernel() already calling local_fiq_enable() and
>> this is done a second time in arch_cpu_idle_prepare() in that case. And
>> enabling FIQs has nothing to do with idling the CPU to start with.
>>
>> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
>> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
>> at late_initcall time but this shouldn't make a difference in practice
>> i.e. when FIQs are actually used.
>>
>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
What kind of review did you do when giving that attributation?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Russell King - ARM Linux @ 2014-01-27 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401271004060.1652@knanqh.ubzr>
On Mon, Jan 27, 2014 at 10:45:59AM -0500, Nicolas Pitre wrote:
> On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
>
> > On Mon, Jan 27, 2014 at 01:08:16AM -0500, Nicolas Pitre wrote:
> > > ARM and ARM64 are the only two architectures implementing
> > > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> > >
> > > We have secondary_start_kernel() already calling local_fiq_enable() and
> > > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > > enabling FIQs has nothing to do with idling the CPU to start with.
> > >
> > > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > > at late_initcall time but this shouldn't make a difference in practice
> > > i.e. when FIQs are actually used.
> > >
> > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > ---
> > > arch/arm/kernel/process.c | 5 -----
> > > arch/arm/kernel/setup.c | 7 +++++++
> > > 2 files changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > > index 92f7b15dd2..725b8c95e0 100644
> > > --- a/arch/arm/kernel/process.c
> > > +++ b/arch/arm/kernel/process.c
> > > @@ -142,11 +142,6 @@ static void default_idle(void)
> > > local_irq_enable();
> > > }
> > >
> > > -void arch_cpu_idle_prepare(void)
> > > -{
> > > - local_fiq_enable();
> > > -}
> > > -
> > > void arch_cpu_idle_enter(void)
> > > {
> > > ledtrig_cpu(CPU_LED_IDLE_START);
> > > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > index 987a7f5bce..d027b1a6fe 100644
> > > --- a/arch/arm/kernel/setup.c
> > > +++ b/arch/arm/kernel/setup.c
> > > @@ -789,6 +789,13 @@ static int __init init_machine_late(void)
> > > }
> > > late_initcall(init_machine_late);
> > >
> > > +static int __init init_fiq_boot_cpu(void)
> > > +{
> > > + local_fiq_enable();
> > > + return 0;
> > > +}
> > > +late_initcall(init_fiq_boot_cpu);
> >
> > arch_cpu_idle_prepare() gets called from the swapper thread, and changes
> > the swapper thread's CPSR. init_fiq_boot_cpu() gets called from PID1, the
> > init thread, and changes the init thread's CPSR, which will already have
> > FIQs enabled by way of how kernel threads are created.
> >
> > Hence, the above code fragment has no effect what so ever, and those
> > platforms using FIQs will not have FIQs delivered if they're idle
> > (because the swapper will have FIQs masked at the CPU.)
>
> You're right.
>
> What about moving local_fiq_enable() to trap_init() then?
That's potentially unsafe, as we haven't touched any of the IRQ
controllers at that point - we can't guarantee what state they'd be
in. Given that the default FIQ is to just return, a FIQ being raised
at that point will end up with an infinite loop re-entering the FIQ
handler.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Felipe Balbi @ 2014-01-27 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127150855.GA17928@xps8300>
Hi,
On Mon, Jan 27, 2014 at 05:08:55PM +0200, Heikki Krogerus wrote:
> > > Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs),
> > > do not return from probe if the USB PHY library returns -ENODEV as that
> >
> > this isn't correct, they all have PHYs, some of them might not be
> > controllable.
> >
> > > indicates the platform does not have PHY.
> >
> > not really, that indicates the current platform tried to grab a PHY and
> > the PHY doesn't exist. If there's anybody with a non-controllable PHY
> > and someone gives me a really good reason for not using the generic
> > no-op PHY, then we should add a flag and we could:
> >
> > if (!likely(dwc->flags & DWC3_USB2PHY_DRIVER_NOT_NEEDED))
> > dwc3_grab_phys(dwc);
>
> Why would you need to know if the PHY drivers are needed or not
> explicitly in your controller driver?
because, one way or another, they all do need it. Except for quirky ones
like AM437x where a USB3 IP was hardwired into USB2-only mode, so it
really lacks a USB3 PHY.
> > But I really want to see the argument against using no-op. As far as I
> > could see, everybody needs a PHY driver one way or another, some
> > platforms just haven't sent any PHY driver upstream and have their own
> > hacked up solution to avoid using the PHY layer.
>
> Not true in our case. Platforms using Intel's SoCs and chip sets may
> or may not have controllable USB PHY. Quite often they don't. The
> Baytrails have usually ULPI PHY for USB2, but that does not mean they
> provide any vendor specific functions or any need for a driver in any
> case.
that's different from what I heard.
> Are we talking about the old USB PHY library or the new PHY framework
> with the no-op PHY driver?
>
> Well, in any case, I don't understand what is the purpose of the no-op
> PHY driver. What are you drying to achieve with that?
I'm trying to avoid supporting 500 different combinations for a single
driver. We already support old USB PHY layer and generic PHY layer, now
they both need to be made optional. The old USB PHY layer also provides
a no-op, now called phy-generic, which is actually pretty useful.
On top of all that, I'm sure you'll subscribe to the idea of preventing
dwc3 from becoming another MUSB which supports several different
configurations and none work correctly. I much prefer to take baby steps
which are well thought-out and very well exercised, so I'll be very
pedantic about proof of testing.
An invasive change such as $subject needs to be very well-tested in
different architectures with different Kconfig choices before I'd feel
comfortable applying it.
Also, the assumptions made in $subject are just plain wrong, which
gets me really iffy about applying it or not.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/afb7097a/attachment.sig>
^ permalink raw reply
* [PATCH 2/9] ARM64: get rid of arch_cpu_idle_prepare()
From: Catalin Marinas @ 2014-01-27 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401271047240.1652@knanqh.ubzr>
On Mon, Jan 27, 2014 at 03:51:02PM +0000, Nicolas Pitre wrote:
> On Mon, 27 Jan 2014, Catalin Marinas wrote:
>
> > On Mon, Jan 27, 2014 at 06:08:17AM +0000, Nicolas Pitre wrote:
> > > ARM and ARM64 are the only two architectures implementing
> > > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> > >
> > > We have secondary_start_kernel() already calling local_fiq_enable() and
> > > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > > enabling FIQs has nothing to do with idling the CPU to start with.
> > >
> > > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > > at late_initcall time but this shouldn't make a difference in practice
> > > given that FIQs are not currently used on ARM64.
> > >
> > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> >
> > For arm64, we could simply remove any reference to FIQs. I'm not aware
> > of anyone using them.
>
> OK. What if I sumply remove arch_cpu_idle_prepare() and let you do the
> remove the rest?
>
> IMHO I'd simply remove local_fiq_{enable/disable}() from
> arm64/kernel/smp.c and leave the infrastructure in place in case someone
> needs it eventually. In which case I could include that into my patch
> as well.
Sounds good. We can keep the local_fiq_*() functions but remove about 4
calling sites (process.c and smp.c) until needed.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v2 3/4] Update bcm_defconfig with new pinctrl CONFIG
From: Christian Daudt @ 2014-01-27 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390509887-19278-4-git-send-email-syin@broadcom.com>
On Thu, Jan 23, 2014 at 12:44 PM, Sherman Yin <syin@broadcom.com> wrote:
> To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
> driver and its related CONFIG option are renamed to bcm281xx.
>
> This commit updates the defconfig that enables the pinctrl driver.
>
> Signed-off-by: Sherman Yin <syin@broadcom.com>
> Reviewed-by: Matt Porter <mporter@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> arch/arm/configs/bcm_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
> index bede511..53d6d47 100644
> --- a/arch/arm/configs/bcm_defconfig
> +++ b/arch/arm/configs/bcm_defconfig
> @@ -126,4 +126,4 @@ CONFIG_CRC_ITU_T=y
> CONFIG_CRC7=y
> CONFIG_XZ_DEC=y
> CONFIG_AVERAGE=y
> -CONFIG_PINCTRL_CAPRI=y
> +CONFIG_PINCTRL_BCM281XX=y
> --
> 1.7.9.5
>
Acked-by: Christian Daudt <bcm@fixthebug.org>
Olof,
Can you apply this patch directly or do you want me to send a pull
request with it ?
Thanks,
csd
^ permalink raw reply
* [PATCH] sunxi: dts: add a note that memory size is adjusted by boot loader.
From: Ian Campbell @ 2014-01-27 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127145714.GL3867@lukather>
On Mon, 2014-01-27 at 15:57 +0100, Maxime Ripard wrote:
> Hi Ian, Hans,
>
> On Sat, Jan 25, 2014 at 12:03:16PM +0100, Hans de Goede wrote:
> > Hmm, I've no idea what the default / preferred way of handling this is,
> > I assume Maxime knows, so lets wait for his input on this.
>
> I got the habit of setting the memory node to the max size the RAM
> controller can handle from previous work on imx,
I suppose this has the advantage of being static for a given SoC, so
there is no question of what the smallest possible value is, even if it
has the disadvantage of not working as a default on many platforms
(perhaps I'm overestimating the utility of that?).
> but I don't really
> have a preferrence here.
>
> If that confuses people, we can just remove it from the DTSI
> altogether. It will be patched by u-boot anyway, and we won't have to
> create DTS variants this way.
I've occasionally seen issues with u-boot not expanding the fdt itself,
so the placeholder serves the purpose of letting it update without
expanding. That was in my more complex Xen boot script which use "fdt
set" a lot -- probably doesn't apply to properly integrated
functionality like updating the memory node? (Or if it does that's a
u-boot bug).
> Just don't do it for the A31 for the moment, since we don't have
> DT-enabled u-boot for now.
Ack!
Ian.
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Lars-Peter Clausen @ 2014-01-27 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
Hi,
I think you should try to get this in sync with the work Jean-Francois is
currently doing[1]. Having the HDMI transmitter register a CODEC device is
definitely the right approach, compared to the rather 'interesting'
constraints stuff you do in patch 4.
- Lars
[1] http://lkml.org/lkml/2014/1/27/85
On 01/27/2014 04:37 PM, Jyri Sarha wrote:
> Changes since RFC v2 version of the patches:
> - Dropped out already applied:
> ASoC: hdmi-codec: Add devicetree binding with documentation
> - Addresses Mark's comments here:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/070605.html
> - ASoC: davinci-evm: Add named clock reference to DT bindings
> - Get rid of unnecessary castings
> - Add mclk NULL checks
> - Use devm_clk_get()
> - Change clock name from "ti,codec-clock" to "mclk"
> - Address Mark's comments here:
> http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/070606.html - ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
> - Get rid of unnecessary castings
> - Update commit message
> - Add: ASoC: davinci-mcasp: Set BCLK divider if McASP is BCLK master
> - Use snd_soc_params_to_bclk()
>
> Changes since the first RFC version of the patches:
> - Drop out already applied:
> ASoC: hdmi-codec: Add SNDRV_PCM_FMTBIT_32_LE playback format
> - Change sound node's compatible property
> form: "ti,am33xx-beaglebone-black" to "ti,am33xx-beaglebone-black-audio"
> - Some minor style issue fixes from TI internal review
>
> Jyri Sarha (8):
> clk: add gpio controlled clock
> ASoC: davinci-evm: Add named clock reference to DT bindings
> ASoC: davinci-mcasp: Set BCLK divider if McASP is BCLK master
> ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S
> bus
> ASoC: davinci: HDMI audio build for AM33XX and TDA998x
> drm/tilcdc: Add I2C HDMI audio config for tda998x
> ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI
> support
> ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio
> support
>
> .../devicetree/bindings/clock/gpio-clock.txt | 21 ++
> .../bindings/sound/davinci-evm-audio.txt | 13 +-
> arch/arm/configs/omap2plus_defconfig | 5 +
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-gpio.c | 210 +++++++++++++++++++
> drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++-
> include/linux/clk-provider.h | 25 +++
> sound/soc/davinci/Kconfig | 12 ++
> sound/soc/davinci/Makefile | 1 +
> sound/soc/davinci/davinci-evm.c | 211 +++++++++++++++++++-
> sound/soc/davinci/davinci-mcasp.c | 20 ++
> 11 files changed, 534 insertions(+), 9 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt
> create mode 100644 drivers/clk/clk-gpio.c
>
^ permalink raw reply
* [PATCH 2/9] ARM64: get rid of arch_cpu_idle_prepare()
From: Nicolas Pitre @ 2014-01-27 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127154315.GG32608@arm.com>
On Mon, 27 Jan 2014, Catalin Marinas wrote:
> On Mon, Jan 27, 2014 at 06:08:17AM +0000, Nicolas Pitre wrote:
> > ARM and ARM64 are the only two architectures implementing
> > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> >
> > We have secondary_start_kernel() already calling local_fiq_enable() and
> > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > enabling FIQs has nothing to do with idling the CPU to start with.
> >
> > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > at late_initcall time but this shouldn't make a difference in practice
> > given that FIQs are not currently used on ARM64.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> For arm64, we could simply remove any reference to FIQs. I'm not aware
> of anyone using them.
OK. What if I sumply remove arch_cpu_idle_prepare() and let you do the
remove the rest?
IMHO I'd simply remove local_fiq_{enable/disable}() from
arm64/kernel/smp.c and leave the infrastructure in place in case someone
needs it eventually. In which case I could include that into my patch
as well.
Nicolas
^ permalink raw reply
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Jason Cooper @ 2014-01-27 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> A new round, mostly fixing some minor nitpicks.
>
> This entire series depends on latest irqchip-orion fixes by Sebastian.
> Namely, this one: https://lkml.org/lkml/2014/1/23/594.
>
> How should we handle this dependency?
Sorry, I'm short on time atm. Which specific patches now depend on his
changes?
I'll be doing a topic branch for tglx for that, so it shouldn't be
rocket surgery. The big unknown is the MMIO patch currently in
Russell's patch tracker.
We may end up waiting for MMIO and Sebastian's changes to land, then
applying this during the next cycle.
thx,
Jason.
> Changes from v4 are:
>
> * Provided better commit subject and commit log for patch 7:
> "watchdog: orion: Handle the interrupt so it's properly acked".
>
> * Corrected the misnamed fuction try_rstout_ioremap().
>
> * A bunch of s/interruption/interrupt fixes
>
> * Dropped the '0' as a valid IRQ in the platform_get_irq() check, given
> it should return a positive virq-space number.
>
> Changes from v3 are:
>
> * It wasn't nice to break DT compatibility by adding a second resource
> requirement, so we provided a fallback to use the RSTOUT address.
> All in all, the solution doesn't look too bad.
>
> * Added a full watchdog stop at driver probe time, *before* the call
> to request_irq().
>
> Notice that currently the request_irq() doesn't seem to clear the
> pending interrupt. This means the BRIDGE_CAUSE clear removal is
> still not safe.
>
> This should be fixed sooner than later and, of course, before this
> gets merged.
>
> * Rework the interrupt request, to use devm_request_irq() and
> avoid dealing with IRQ releasing.
>
> * Added proper clock error handling and fixed the probe() error path.
>
> * Typos and minor issues got fixed
>
> Changes from v2:
>
> * Add proper error checking on clk_prepare_enable() and return
> PTR_ERR instead of ENODEV. Suggested by Fabio Estevam.
>
> * After the usage of the atomic I/O and considering the watchdog core
> does its own serialization, the driver's spinlock was completely
> redundant and was removed. Also suggested by Fabio.
>
> * Instead of making the driver dependent on PLAT_ORION, added a dependency
> to ARCH_MVEBU. This was proposed by Sebastian and Andrew, given
> we're working on PLAT_ORION removal.
>
> Changes from v1:
>
> * Watchdog RSTOUT enable.
> While v1 enabled the RSTOUT at each machine initialization, Jason Gunthorpe
> later pointed out [2] that such enabling might lead to a spurious watchdog
> trigger, in the event of the watchdog expired event not being cleared.
>
> Therefore, the current patchset adds RSTOUT as a second address resource
> (or 'reg' entry in devicetree words) to allow different platforms specify
> the corresponding address of the register. This change allows to build the
> driver on multiplatforms builds as helps remove a mach-specific header.
>
> The drawback of this is that the DT backwards compatibility gets broken;
> this was timely discussed but no better solution was achieved or proposed.
>
> * BRIDGE CAUSE clear removal
> The watchdog cause clear should be done by the bridge irqchip driver, so
> it's fine to remove it from the watchdog driver and instead request the
> interrupt.
>
> However, there are still a few platforms (orion5x, and legacy
> kirkwood/dove) that doesn't have this bridge irqchip support enabled.
> On these platforms the bridge cause clear is simply *not* done.
>
> If we are paranoid about this, maybe we can simply add the clear on each
> mach-xxx/irq.c, together with the other irq is initialization.
>
> Once again, thanks to everyone who helped reviewing this.
>
> Ezequiel Garcia (20):
> ARM: Introduce atomic MMIO modify
> clocksource: orion: Use atomic access for shared registers
> watchdog: orion: Add clock error handling
> watchdog: orion: Use atomic access for shared registers
> watchdog: orion: Remove unused macros
> watchdog: orion: Make sure the watchdog is initially stopped
> watchdog: orion: Handle the interrupt so it's properly acked
> watchdog: orion: Make RSTOUT register a separate resource
> watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
> watchdog: orion: Introduce an orion_watchdog device structure
> watchdog: orion: Introduce per-compatible of_device_id data
> watchdog: orion: Add per-compatible clock initialization
> watchdog: orion: Add per-compatible watchdog start implementation
> watchdog: orion: Add support for Armada 370 and Armada XP SoC
> ARM: mvebu: Enable Armada 370/XP watchdog in the devicetree
> ARM: kirkwood: Add RSTOUT 'reg' entry to devicetree
> ARM: dove: Enable Dove watchdog in the devicetree
> watchdog: orion: Enable the build on ARCH_MVEBU
> ARM: mvebu: Enable watchdog support in defconfig
> ARM: dove: Enable watchdog support in the defconfig
>
> .../devicetree/bindings/watchdog/marvel.txt | 8 +-
> arch/arm/boot/dts/armada-370-xp.dtsi | 4 +
> arch/arm/boot/dts/armada-370.dtsi | 5 +
> arch/arm/boot/dts/armada-xp.dtsi | 6 +
> arch/arm/boot/dts/dove.dtsi | 8 +
> arch/arm/boot/dts/kirkwood.dtsi | 2 +-
> arch/arm/configs/dove_defconfig | 2 +
> arch/arm/configs/mvebu_defconfig | 2 +
> arch/arm/include/asm/io.h | 6 +
> arch/arm/kernel/io.c | 35 ++
> arch/arm/mach-dove/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-kirkwood/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-mv78xx0/include/mach/bridge-regs.h | 1 +
> arch/arm/mach-orion5x/include/mach/bridge-regs.h | 1 +
> arch/arm/plat-orion/common.c | 10 +-
> drivers/clocksource/time-orion.c | 28 +-
> drivers/watchdog/Kconfig | 2 +-
> drivers/watchdog/orion_wdt.c | 369 ++++++++++++++++-----
> 18 files changed, 383 insertions(+), 108 deletions(-)
>
> --
> 1.8.1.5
>
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Nicolas Pitre @ 2014-01-27 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127124511.GK15937@n2100.arm.linux.org.uk>
On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 01:08:16AM -0500, Nicolas Pitre wrote:
> > ARM and ARM64 are the only two architectures implementing
> > arch_cpu_idle_prepare() simply to call local_fiq_enable().
> >
> > We have secondary_start_kernel() already calling local_fiq_enable() and
> > this is done a second time in arch_cpu_idle_prepare() in that case. And
> > enabling FIQs has nothing to do with idling the CPU to start with.
> >
> > So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> > CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> > at late_initcall time but this shouldn't make a difference in practice
> > i.e. when FIQs are actually used.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > ---
> > arch/arm/kernel/process.c | 5 -----
> > arch/arm/kernel/setup.c | 7 +++++++
> > 2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > index 92f7b15dd2..725b8c95e0 100644
> > --- a/arch/arm/kernel/process.c
> > +++ b/arch/arm/kernel/process.c
> > @@ -142,11 +142,6 @@ static void default_idle(void)
> > local_irq_enable();
> > }
> >
> > -void arch_cpu_idle_prepare(void)
> > -{
> > - local_fiq_enable();
> > -}
> > -
> > void arch_cpu_idle_enter(void)
> > {
> > ledtrig_cpu(CPU_LED_IDLE_START);
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 987a7f5bce..d027b1a6fe 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -789,6 +789,13 @@ static int __init init_machine_late(void)
> > }
> > late_initcall(init_machine_late);
> >
> > +static int __init init_fiq_boot_cpu(void)
> > +{
> > + local_fiq_enable();
> > + return 0;
> > +}
> > +late_initcall(init_fiq_boot_cpu);
>
> arch_cpu_idle_prepare() gets called from the swapper thread, and changes
> the swapper thread's CPSR. init_fiq_boot_cpu() gets called from PID1, the
> init thread, and changes the init thread's CPSR, which will already have
> FIQs enabled by way of how kernel threads are created.
>
> Hence, the above code fragment has no effect what so ever, and those
> platforms using FIQs will not have FIQs delivered if they're idle
> (because the swapper will have FIQs masked at the CPU.)
You're right.
What about moving local_fiq_enable() to trap_init() then?
Nicolas
^ permalink raw reply
* [PATCH 2/9] ARM64: get rid of arch_cpu_idle_prepare()
From: Catalin Marinas @ 2014-01-27 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390802904-28399-3-git-send-email-nicolas.pitre@linaro.org>
On Mon, Jan 27, 2014 at 06:08:17AM +0000, Nicolas Pitre wrote:
> ARM and ARM64 are the only two architectures implementing
> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>
> We have secondary_start_kernel() already calling local_fiq_enable() and
> this is done a second time in arch_cpu_idle_prepare() in that case. And
> enabling FIQs has nothing to do with idling the CPU to start with.
>
> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> at late_initcall time but this shouldn't make a difference in practice
> given that FIQs are not currently used on ARM64.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
For arm64, we could simply remove any reference to FIQs. I'm not aware
of anyone using them.
--
Catalin
^ permalink raw reply
* [PATCH RFC v3 8/8] ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
Select following:
CONFIG_SND_DAVINCI_SOC=m
CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: tony at atomide.com
---
arch/arm/configs/omap2plus_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 9288172..62c4f51 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -214,6 +214,8 @@ CONFIG_SND_OMAP_SOC=m
CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
+CONFIG_SND_DAVINCI_SOC=m
+CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v3 7/8] ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI support
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
This enables HDMI video support on Beaglebone-Black.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: tony at atomide.com
---
arch/arm/configs/omap2plus_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index bfa80a1..9288172 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -180,6 +180,9 @@ CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TPS65217=y
CONFIG_REGULATOR_TPS65910=y
CONFIG_REGULATOR_TWL4030=y
+CONFIG_DRM=m
+CONFIG_DRM_I2C_NXP_TDA998X=m
+CONFIG_DRM_TILCDC=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v3 6/8] drm/tilcdc: Add I2C HDMI audio config for tda998x
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
The configuration is needed for HDMI audio. The "swap" and "mirr"
parameters have to be correctly set in the configuration in order to
have proper colors in the HDMI picture.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: airlied at linux.ie
---
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index 595068b..e43240a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -19,6 +19,7 @@
#include <linux/pinctrl/pinmux.h>
#include <linux/pinctrl/consumer.h>
#include <drm/drm_encoder_slave.h>
+#include <drm/i2c/tda998x.h>
#include "tilcdc_drv.h"
@@ -111,8 +112,29 @@ static const struct drm_encoder_helper_funcs slave_encoder_helper_funcs = {
.restore = drm_i2c_encoder_restore,
};
+static struct tda998x_encoder_params tda998x_pdata = {
+ .swap_b = 0x3,
+ .mirr_b = 0x0,
+ .swap_a = 0x2,
+ .mirr_a = 0x0,
+ .swap_d = 0x1,
+ .mirr_d = 0x0,
+ .swap_c = 0x0,
+ .mirr_c = 0x0,
+ .swap_f = 0x5,
+ .mirr_f = 0x0,
+ .swap_e = 0x4,
+ .mirr_e = 0x0,
+ .audio_cfg = 0x3, /* I2S mode */
+ .audio_clk_cfg = 1, /* select clock pin */
+ .audio_frame[1] = 1, /* channels - 1 */
+ .audio_format = AFMT_I2S,
+ .audio_sample_rate = 48000,
+};
+
static const struct i2c_board_info info = {
- I2C_BOARD_INFO("tda998x", 0x70)
+ I2C_BOARD_INFO("tda998x", 0x70),
+ .platform_data = &tda998x_pdata,
};
static struct drm_encoder *slave_encoder_create(struct drm_device *dev,
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v3 5/8] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
Adds configuration option for HDMI audio support for AM33XX based
boards with NXP TDA998x HDMI transmitter. The audio is connected to
NXP TDA998x trough McASP running in i2s mode.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
sound/soc/davinci/Kconfig | 12 ++++++++++++
sound/soc/davinci/Makefile | 1 +
2 files changed, 13 insertions(+)
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index a8ec1fc..40dd5d1 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -26,6 +26,18 @@ config SND_AM33XX_SOC_EVM
AM335X-EVMSK, and BeagelBone with AudioCape boards have this
setup.
+config SND_AM335X_SOC_NXPTDA_EVM
+ tristate "HDMI Audio for the AM33XX chip based boards with TDA998x"
+ depends on SND_DAVINCI_SOC && SOC_AM33XX
+ depends on DRM_TILCDC && DRM_I2C_NXP_TDA998X
+ select SND_SOC_HDMI_CODEC
+ select SND_DAVINCI_SOC_MCASP
+ help
+ Say Y or M if you want to add support for HDMI SoC audio on
+ AM33XX boards with NXP TDA998x HDMI transmitter. For example
+ BeagleBoneBack. The audio is connected to NXP TDA998x trough
+ McASP running in i2s mode.
+
config SND_DAVINCI_SOC_EVM
tristate "SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM"
depends on SND_DAVINCI_SOC
diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile
index 744d4d9..7587a70 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/davinci/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o
snd-soc-evm-objs := davinci-evm.o
obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o
+obj-$(CONFIG_SND_AM335X_SOC_NXPTDA_EVM) += snd-soc-evm.o
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v3 4/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
Add machine driver support for BeagleBone-Black and other boards with
tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
port in I2S mode. McASP produces the bit clock for the i2s bus from
the masted clock by a simple divider and the available sample rates
depend on the used master clock frequency. The only properly working
sample format appears to be SNDRV_PCM_FORMAT_S32_LE. The other formats
have been disabled. The 8 least significant bits of the 32 bit samples
are ignored.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: bcousson at baylibre.com
---
.../bindings/sound/davinci-evm-audio.txt | 4 +-
sound/soc/davinci/davinci-evm.c | 153 +++++++++++++++++++-
2 files changed, 152 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 963e100..2a535d9 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -1,7 +1,9 @@
* Texas Instruments SoC audio setups with TLV320AIC3X Codec
Required properties:
-- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx
+- compatible :
+ "ti,da830-evm-audio" : for DM365/DA8xx/OMAPL1x/AM33xx
+ "ti,am33xx-beaglebone-black-audio" : for Beaglebone-black HDMI audio
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index d3e4cb0..00f1e83 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -21,6 +21,7 @@
#include <sound/core.h>
#include <sound/pcm.h>
#include <sound/soc.h>
+#include <sound/pcm_params.h>
#include <asm/dma.h>
#include <asm/mach-types.h>
@@ -33,8 +34,13 @@
struct snd_soc_card_drvdata_davinci {
struct clk *mclk;
unsigned sysclk;
+ struct snd_pcm_hw_constraint_list *rate_constraint;
};
+/* If changing sample format the tda998x configuration (REG_CTS_N) needs
+ to be changed. */
+#define TDA998X_SAMPLE_FORMAT SNDRV_PCM_FORMAT_S32_LE
+
static int evm_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
@@ -67,9 +73,10 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
struct snd_soc_codec *codec = rtd->codec;
struct snd_soc_card *soc_card = codec->card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ snd_soc_card_get_drvdata(soc_card);
+ unsigned sysclk = drvdata->sysclk;
int ret = 0;
- unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
- snd_soc_card_get_drvdata(soc_card))->sysclk;
/* set the codec system clock */
ret = snd_soc_dai_set_sysclk(codec_dai, 0, sysclk, SND_SOC_CLOCK_OUT);
@@ -84,12 +91,63 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
return 0;
}
+static int evm_tda998x_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_card *soc_card = rtd->codec->card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ snd_soc_card_get_drvdata(soc_card);
+ struct snd_mask *fmt = constrs_mask(&runtime->hw_constraints,
+ SNDRV_PCM_HW_PARAM_FORMAT);
+ snd_mask_none(fmt);
+ snd_mask_set(fmt, TDA998X_SAMPLE_FORMAT);
+
+ runtime->hw.rate_min = drvdata->rate_constraint->list[0];
+ runtime->hw.rate_max = drvdata->rate_constraint->list[
+ drvdata->rate_constraint->count - 1];
+ runtime->hw.rates = SNDRV_PCM_RATE_KNOT;
+
+ snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+ drvdata->rate_constraint);
+ snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
+ 2, 2);
+
+ return evm_startup(substream);
+}
+
+static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ struct snd_soc_codec *codec = rtd->codec;
+ struct snd_soc_card *soc_card = codec->card;
+ struct platform_device *pdev = to_platform_device(soc_card->dev);
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ snd_soc_card_get_drvdata(soc_card);
+ unsigned sysclk = drvdata->sysclk;
+ int ret;
+
+ ret = snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_IN);
+ if (ret < 0)
+ return ret;
+
+ return ret;
+}
+
static struct snd_soc_ops evm_ops = {
.startup = evm_startup,
.shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
+static struct snd_soc_ops evm_tda998x_ops = {
+ .startup = evm_tda998x_startup,
+ .shutdown = evm_shutdown,
+ .hw_params = evm_tda998x_hw_params,
+};
+
/* davinci-evm machine dapm widgets */
static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = {
SND_SOC_DAPM_HP("Headphone Jack", NULL),
@@ -156,6 +214,79 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
return 0;
}
+static unsigned int tda998x_hdmi_rates[] = {
+ 32000,
+ 44100,
+ 48000,
+ 88200,
+ 96000,
+};
+
+static struct snd_pcm_hw_constraint_list *evm_tda998x_rate_constraint(
+ struct snd_soc_card *soc_card)
+{
+ struct platform_device *pdev = to_platform_device(soc_card->dev);
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ snd_soc_card_get_drvdata(soc_card);
+ unsigned sysclk = drvdata->sysclk;
+ struct snd_pcm_hw_constraint_list *ret;
+ unsigned int *rates;
+ int i, j = 0;
+
+ ret = devm_kzalloc(soc_card->dev, sizeof(*ret), GFP_KERNEL);
+ rates = devm_kzalloc(soc_card->dev, sizeof(tda998x_hdmi_rates),
+ GFP_KERNEL);
+ if (!ret || !rates)
+ return NULL;
+
+ ret->list = rates;
+ ret->mask = 0;
+ for (i = 0; i < ARRAY_SIZE(tda998x_hdmi_rates); i++) {
+ unsigned int bclk_freq = tda998x_hdmi_rates[i] * 2 *
+ snd_pcm_format_width(TDA998X_SAMPLE_FORMAT);
+ if (sysclk % bclk_freq == 0) {
+ rates[j++] = tda998x_hdmi_rates[i];
+ dev_dbg(soc_card->dev, "Allowing rate %u\n",
+ tda998x_hdmi_rates[i]);
+ }
+ }
+ ret->count = j;
+ return ret;
+}
+
+static const struct snd_soc_dapm_widget tda998x_dapm_widgets[] = {
+ SND_SOC_DAPM_OUTPUT("HDMI Out"),
+};
+
+static int evm_tda998x_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ struct snd_soc_dapm_context *dapm = &rtd->codec->dapm;
+ struct snd_soc_card *soc_card = rtd->codec->card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ snd_soc_card_get_drvdata(soc_card);
+ int ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, 0, 1);
+ if (ret < 0)
+ return ret;
+
+ drvdata->rate_constraint = evm_tda998x_rate_constraint(soc_card);
+
+ snd_soc_dapm_new_controls(dapm, tda998x_dapm_widgets,
+ ARRAY_SIZE(tda998x_dapm_widgets));
+
+ ret = snd_soc_of_parse_audio_routing(soc_card, "ti,audio-routing");
+
+ /* not connected */
+ snd_soc_dapm_disable_pin(dapm, "RX");
+
+ /* always connected */
+ snd_soc_dapm_enable_pin(dapm, "HDMI Out");
+
+ return 0;
+}
+
/* davinci-evm digital audio interface glue - connects codec <--> CPU */
static struct snd_soc_dai_link dm6446_evm_dai = {
.name = "TLV320AIC3X",
@@ -341,7 +472,7 @@ static struct snd_soc_card da850_snd_soc_card = {
#if defined(CONFIG_OF)
/*
- * The struct is used as place holder. It will be completely
+ * The structs are used as place holders. They will be completely
* filled with data from dt node.
*/
static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
@@ -354,10 +485,24 @@ static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
SND_SOC_DAIFMT_IB_NF,
};
+static struct snd_soc_dai_link evm_dai_tda998x_hdmi = {
+ .name = "NXP TDA998x HDMI Chip",
+ .stream_name = "HDMI",
+ .codec_dai_name = "hdmi-hifi",
+ .ops = &evm_tda998x_ops,
+ .init = evm_tda998x_init,
+ .dai_fmt = (SND_SOC_DAIFMT_CBS_CFS | SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_IB_NF),
+};
+
static const struct of_device_id davinci_evm_dt_ids[] = {
{
.compatible = "ti,da830-evm-audio",
- .data = (void *) &evm_dai_tlv320aic3x,
+ .data = &evm_dai_tlv320aic3x,
+ },
+ {
+ .compatible = "ti,am33xx-beaglebone-black-audio",
+ .data = &evm_dai_tda998x_hdmi,
},
{ /* sentinel */ }
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v3 3/8] ASoC: davinci-mcasp: Set BCLK divider if McASP is BCLK master
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
Make BCLK divider setting implicite in hw_params call if McASP device
is the bit clock master on the audio serial bus.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
sound/soc/davinci/davinci-mcasp.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
index b7858bf..ae328be 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -53,6 +53,9 @@ struct davinci_mcasp {
u16 bclk_lrclk_ratio;
int streams;
+ int sysclk_freq;
+ bool bclk_master;
+
/* McASP FIFO related */
u8 txnumevt;
u8 rxnumevt;
@@ -292,6 +295,7 @@ static int davinci_mcasp_set_dai_fmt(struct snd_soc_dai *cpu_dai,
mcasp_set_bits(mcasp, DAVINCI_MCASP_PDIR_REG, ACLKX | ACLKR);
mcasp_set_bits(mcasp, DAVINCI_MCASP_PDIR_REG, AFSX | AFSR);
+ mcasp->bclk_master = 1;
break;
case SND_SOC_DAIFMT_CBM_CFS:
/* codec is clock master and frame slave */
@@ -303,6 +307,7 @@ static int davinci_mcasp_set_dai_fmt(struct snd_soc_dai *cpu_dai,
mcasp_clr_bits(mcasp, DAVINCI_MCASP_PDIR_REG, ACLKX | ACLKR);
mcasp_set_bits(mcasp, DAVINCI_MCASP_PDIR_REG, AFSX | AFSR);
+ mcasp->bclk_master = 0;
break;
case SND_SOC_DAIFMT_CBM_CFM:
/* codec is clock and frame master */
@@ -314,6 +319,7 @@ static int davinci_mcasp_set_dai_fmt(struct snd_soc_dai *cpu_dai,
mcasp_clr_bits(mcasp, DAVINCI_MCASP_PDIR_REG,
ACLKX | AHCLKX | AFSX | ACLKR | AHCLKR | AFSR);
+ mcasp->bclk_master = 0;
break;
default:
@@ -405,6 +411,8 @@ static int davinci_mcasp_set_sysclk(struct snd_soc_dai *dai, int clk_id,
mcasp_clr_bits(mcasp, DAVINCI_MCASP_PDIR_REG, AHCLKX);
}
+ mcasp->sysclk_freq = freq;
+
return 0;
}
@@ -607,6 +615,18 @@ static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream,
int channels;
struct snd_interval *pcm_channels = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_CHANNELS);
+
+ /* If mcasp is BCLK master we need to set BCLK divider */
+ if (mcasp->bclk_master) {
+ unsigned int bclk_freq = snd_soc_params_to_bclk(params);
+ if (mcasp->sysclk_freq % bclk_freq != 0) {
+ dev_err(mcasp->dev, "Can't produce requred BCLK\n");
+ return -EINVAL;
+ }
+ davinci_mcasp_set_clkdiv(
+ cpu_dai, 1, mcasp->sysclk_freq / bclk_freq);
+ }
+
channels = pcm_channels->min;
active_serializers = (channels + slots - 1) / slots;
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v3 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
The referenced clock is used to get codec clock rate and the clock is
disabled and enabled in startup and shutdown snd_soc_ops call
backs. The change is also documented in DT bindigs document.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: bcousson at baylibre.com
---
.../bindings/sound/davinci-evm-audio.txt | 9 ++-
sound/soc/davinci/davinci-evm.c | 58 +++++++++++++++++++-
2 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 865178d..963e100 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -5,12 +5,19 @@ Required properties:
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
-- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec
- ti,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
the second being the connection's source. Valid names for sources and
sinks are the codec's pins, and the jacks on the board:
+Optional properties:
+- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec.
+- clocks : Reference to the master clock
+- clock-names : The clock should be named "mclk"
+- Either codec-clock-rate or the codec-clock reference has to be defined. If
+ the both are defined the driver attempts to set referenced clock to the
+ defined rate and takes the rate from the clock reference.
+
Board connectors:
* Headphone Jack
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 70ff377..d3e4cb0 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -17,6 +17,7 @@
#include <linux/platform_data/edma.h>
#include <linux/i2c.h>
#include <linux/of_platform.h>
+#include <linux/clk.h>
#include <sound/core.h>
#include <sound/pcm.h>
#include <sound/soc.h>
@@ -30,9 +31,34 @@
#include "davinci-i2s.h"
struct snd_soc_card_drvdata_davinci {
+ struct clk *mclk;
unsigned sysclk;
};
+static int evm_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_card *soc_card = rtd->codec->card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ snd_soc_card_get_drvdata(soc_card);
+
+ if (drvdata->mclk)
+ return clk_prepare_enable(drvdata->mclk);
+
+ return 0;
+}
+
+static void evm_shutdown(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_card *soc_card = rtd->codec->card;
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ snd_soc_card_get_drvdata(soc_card);
+
+ if (drvdata->mclk)
+ clk_disable_unprepare(drvdata->mclk);
+}
+
static int evm_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
@@ -59,6 +85,8 @@ static int evm_hw_params(struct snd_pcm_substream *substream,
}
static struct snd_soc_ops evm_ops = {
+ .startup = evm_startup,
+ .shutdown = evm_shutdown,
.hw_params = evm_hw_params,
};
@@ -348,6 +376,7 @@ static int davinci_evm_probe(struct platform_device *pdev)
of_match_device(of_match_ptr(davinci_evm_dt_ids), &pdev->dev);
struct snd_soc_dai_link *dai = (struct snd_soc_dai_link *) match->data;
struct snd_soc_card_drvdata_davinci *drvdata = NULL;
+ struct clk *mclk;
int ret = 0;
evm_soc_card.dai_link = dai;
@@ -367,13 +396,38 @@ static int davinci_evm_probe(struct platform_device *pdev)
if (ret)
return ret;
+ mclk = devm_clk_get(&pdev->dev, "mclk");
+ if (PTR_ERR(mclk) == -EPROBE_DEFER) {
+ return -EPROBE_DEFER;
+ } else if (IS_ERR(mclk)) {
+ dev_dbg(&pdev->dev, "mclk not found.\n");
+ mclk = NULL;
+ }
+
drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
if (!drvdata)
return -ENOMEM;
+ drvdata->mclk = mclk;
+
ret = of_property_read_u32(np, "ti,codec-clock-rate", &drvdata->sysclk);
- if (ret < 0)
- return -EINVAL;
+
+ if (ret < 0) {
+ if (!drvdata->mclk) {
+ dev_err(&pdev->dev,
+ "No clock or clock rate defined.\n");
+ return -EINVAL;
+ }
+ drvdata->sysclk = clk_get_rate(drvdata->mclk);
+ } else if (drvdata->mclk) {
+ unsigned int requestd_rate = drvdata->sysclk;
+ clk_set_rate(drvdata->mclk, drvdata->sysclk);
+ drvdata->sysclk = clk_get_rate(drvdata->mclk);
+ if (drvdata->sysclk != requestd_rate)
+ dev_warn(&pdev->dev,
+ "Could not get requested rate %u using %u.\n",
+ requestd_rate, drvdata->sysclk);
+ }
snd_soc_card_set_drvdata(&evm_soc_card, drvdata);
ret = devm_snd_soc_register_card(&pdev->dev, &evm_soc_card);
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v3 1/8] clk: add gpio controlled clock
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1390836773.git.jsarha@ti.com>
The added clk-gpio is a basic clock that can be enabled and disabled
trough a gpio output. The DT binding document for the clock is also
added. For EPROBE_DEFER handling the registering of the clock has to
be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
cc: mturquette at linaro.org
cc: bcousson at baylibre.com
---
.../devicetree/bindings/clock/gpio-clock.txt | 21 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-gpio.c | 210 ++++++++++++++++++++
include/linux/clk-provider.h | 25 +++
4 files changed, 257 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt
create mode 100644 drivers/clk/clk-gpio.c
diff --git a/Documentation/devicetree/bindings/clock/gpio-clock.txt b/Documentation/devicetree/bindings/clock/gpio-clock.txt
new file mode 100644
index 0000000..54fea39
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gpio-clock.txt
@@ -0,0 +1,21 @@
+Binding for simple gpio controlled clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "gpio-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- enable-gpios : GPIO reference for enabling and disabling the clock.
+
+Optional properties:
+- clocks: Maximum of one parent clock is supported.
+
+Example:
+ clock {
+ compatible = "gpio-clock";
+ clocks = <&parentclk>;
+ #clock-cells = <0>;
+ enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 7a10bc9..9616e3a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_COMMON_CLK) += clk-fixed-rate.o
obj-$(CONFIG_COMMON_CLK) += clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
+obj-$(CONFIG_COMMON_CLK) += clk-gpio.o
# SoCs specific
obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
new file mode 100644
index 0000000..e04b0e1
--- /dev/null
+++ b/drivers/clk/clk-gpio.c
@@ -0,0 +1,210 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Jyri Sarha <jsarha@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Gpio controlled clock implementation
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/err.h>
+#include <linux/device.h>
+
+/**
+ * DOC: basic gpio controlled clock which can be enabled and disabled
+ * with gpio output
+ * Traits of this clock:
+ * prepare - clk_(un)prepare only ensures parent is (un)prepared
+ * enable - clk_enable and clk_disable are functional & control gpio
+ * rate - inherits rate from parent. No clk_set_rate support
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw)
+
+static int clk_gpio_enable(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio->active_low ? 0 : 1;
+
+ gpio_set_value(gpio->gpio, value);
+
+ return 0;
+}
+
+static void clk_gpio_disable(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio->active_low ? 1 : 0;
+
+ gpio_set_value(gpio->gpio, value);
+}
+
+static int clk_gpio_is_enabled(struct clk_hw *hw)
+{
+ struct clk_gpio *gpio = to_clk_gpio(hw);
+ int value = gpio_get_value(gpio->gpio);
+
+ return gpio->active_low ? !value : value;
+}
+
+const struct clk_ops clk_gpio_ops = {
+ .enable = clk_gpio_enable,
+ .disable = clk_gpio_disable,
+ .is_enabled = clk_gpio_is_enabled,
+};
+EXPORT_SYMBOL_GPL(clk_gpio_ops);
+
+/**
+ * clk_register_gpio - register a gpip clock with the clock framework
+ * @dev: device that is registering this clock
+ * @name: name of this clock
+ * @parent_name: name of this clock's parent
+ * @flags: framework-specific flags for this clock
+ * @gpio: gpio to control this clock
+ * @active_low: gpio polarity
+ */
+struct clk *clk_register_gpio(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ unsigned int gpio, bool active_low)
+{
+ struct clk_gpio *clk_gpio;
+ struct clk *clk = ERR_PTR(-EINVAL);
+ struct clk_init_data init = { NULL };
+ unsigned long gpio_flags;
+ int err;
+
+ if (active_low)
+ gpio_flags = GPIOF_OUT_INIT_LOW;
+ else
+ gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+ err = gpio_request_one(gpio, gpio_flags, name);
+
+ if (err) {
+ pr_err("%s: %s: Error requesting clock control gpio %u\n",
+ __func__, name, gpio);
+ clk = ERR_PTR(err);
+ goto clk_register_gpio_err;
+ }
+
+ clk_gpio = kzalloc(sizeof(*clk_gpio), GFP_KERNEL);
+
+ if (!clk_gpio) {
+ pr_err("%s: %s: could not allocate gpio clk\n", __func__, name);
+ clk = ERR_PTR(-ENOMEM);
+ goto clk_register_gpio_err;
+ }
+
+ init.name = name;
+ init.ops = &clk_gpio_ops;
+ init.flags = flags | CLK_IS_BASIC;
+ init.parent_names = (parent_name ? &parent_name : NULL);
+ init.num_parents = (parent_name ? 1 : 0);
+
+ clk_gpio->gpio = gpio;
+ clk_gpio->active_low = active_low;
+ clk_gpio->hw.init = &init;
+
+ clk = clk_register(dev, &clk_gpio->hw);
+
+ if (!IS_ERR(clk))
+ return clk;
+
+ kfree(clk_gpio);
+
+clk_register_gpio_err:
+ gpio_free(gpio);
+
+ return clk;
+}
+EXPORT_SYMBOL_GPL(clk_register_gpio);
+
+#ifdef CONFIG_OF
+/**
+ * The clk_register_gpio has to be delayed, because the EPROBE_DEFER
+ * can not be handled properly at of_clk_init() call time.
+ */
+
+struct clk_gpio_delayed_register_data {
+ struct device_node *node;
+ struct mutex lock; /* Protect delayed clk registering */
+ struct clk *clk;
+};
+
+static
+struct clk *of_clk_gpio_delayed_register_get(struct of_phandle_args *clkspec,
+ void *_data)
+{
+ struct clk_gpio_delayed_register_data *data =
+ (struct clk_gpio_delayed_register_data *)_data;
+ struct clk *clk;
+ const char *clk_name = data->node->name;
+ const char *parent_name;
+ enum of_gpio_flags gpio_flags;
+ int gpio;
+ bool active_low;
+
+ mutex_lock(&data->lock);
+
+ if (data->clk) {
+ mutex_unlock(&data->lock);
+ return data->clk;
+ }
+
+ gpio = of_get_named_gpio_flags(data->node, "enable-gpios", 0,
+ &gpio_flags);
+
+ if (gpio < 0) {
+ mutex_unlock(&data->lock);
+ if (gpio != -EPROBE_DEFER)
+ pr_err("%s: %s: Can't get 'enable-gpios' DT property\n",
+ __func__, clk_name);
+ return ERR_PTR(gpio);
+ }
+
+ active_low = gpio_flags & OF_GPIO_ACTIVE_LOW;
+
+ parent_name = of_clk_get_parent_name(data->node, 0);
+
+ clk = clk_register_gpio(NULL, clk_name, parent_name, 0,
+ gpio, active_low);
+ if (IS_ERR(clk)) {
+ mutex_unlock(&data->lock);
+ return clk;
+ }
+
+ data->clk = clk;
+ mutex_unlock(&data->lock);
+
+ return clk;
+}
+
+/**
+ * of_gpio_clk_setup() - Setup function for gpio controlled clock
+ */
+void __init of_gpio_clk_setup(struct device_node *node)
+{
+ struct clk_gpio_delayed_register_data *data;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ pr_err("%s: could not allocate gpio clk\n", __func__);
+ return;
+ }
+
+ data->node = node;
+ mutex_init(&data->lock);
+
+ of_clk_add_provider(node, of_clk_gpio_delayed_register_get, data);
+}
+EXPORT_SYMBOL_GPL(of_gpio_clk_setup);
+CLK_OF_DECLARE(gpio_clk, "gpio-clock", of_gpio_clk_setup);
+#endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7e59253..21082b2 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -407,6 +407,31 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
unsigned long flags);
+/***
+ * struct clk_gpio - gpio controlled clock
+ *
+ * @hw: handle between common and hardware-specific interfaces
+ * @gpio: gpio
+ * @active_low: gpio polarity
+ *
+ * Clock with a gpio control for enabling and disabling the parent clock.
+ * Implements .enable, .disable and .is_enabled
+ */
+
+struct clk_gpio {
+ struct clk_hw hw;
+ unsigned int gpio;
+ bool active_low;
+};
+
+extern const struct clk_ops clk_gpio_ops;
+
+struct clk *clk_register_gpio(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ unsigned int gpio, bool active_low);
+
+void of_gpio_clk_setup(struct device_node *node);
+
/**
* clk_register - allocate a new clock, register it and return an opaque cookie
* @dev: device that is registering this clock
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Jyri Sarha @ 2014-01-27 15:37 UTC (permalink / raw)
To: linux-arm-kernel
Changes since RFC v2 version of the patches:
- Dropped out already applied:
ASoC: hdmi-codec: Add devicetree binding with documentation
- Addresses Mark's comments here:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/070605.html
- ASoC: davinci-evm: Add named clock reference to DT bindings
- Get rid of unnecessary castings
- Add mclk NULL checks
- Use devm_clk_get()
- Change clock name from "ti,codec-clock" to "mclk"
- Address Mark's comments here:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/070606.html - ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
- Get rid of unnecessary castings
- Update commit message
- Add: ASoC: davinci-mcasp: Set BCLK divider if McASP is BCLK master
- Use snd_soc_params_to_bclk()
Changes since the first RFC version of the patches:
- Drop out already applied:
ASoC: hdmi-codec: Add SNDRV_PCM_FMTBIT_32_LE playback format
- Change sound node's compatible property
form: "ti,am33xx-beaglebone-black" to "ti,am33xx-beaglebone-black-audio"
- Some minor style issue fixes from TI internal review
Jyri Sarha (8):
clk: add gpio controlled clock
ASoC: davinci-evm: Add named clock reference to DT bindings
ASoC: davinci-mcasp: Set BCLK divider if McASP is BCLK master
ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S
bus
ASoC: davinci: HDMI audio build for AM33XX and TDA998x
drm/tilcdc: Add I2C HDMI audio config for tda998x
ARM: OMAP2+: omap2plus_defconfig: Enable tilcdc and TDA998X HDMI
support
ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio
support
.../devicetree/bindings/clock/gpio-clock.txt | 21 ++
.../bindings/sound/davinci-evm-audio.txt | 13 +-
arch/arm/configs/omap2plus_defconfig | 5 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-gpio.c | 210 +++++++++++++++++++
drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++-
include/linux/clk-provider.h | 25 +++
sound/soc/davinci/Kconfig | 12 ++
sound/soc/davinci/Makefile | 1 +
sound/soc/davinci/davinci-evm.c | 211 +++++++++++++++++++-
sound/soc/davinci/davinci-mcasp.c | 20 ++
11 files changed, 534 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/gpio-clock.txt
create mode 100644 drivers/clk/clk-gpio.c
--
1.7.9.5
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Guennadi Liakhovetski @ 2014-01-27 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127152457.GA1073@trinity.fluff.org>
Hi Ben,
On Mon, 27 Jan 2014, Ben Dooks wrote:
> On Mon, Jan 27, 2014 at 04:13:56PM +0100, Guennadi Liakhovetski wrote:
> > Hi all,
> >
> > I'm working on an MMC driver with a DMA capability. All has been working
> > well, until at some point I've got a bus error, when the mmc driver had
> > been handed in a buffer at 0x3000 physical RAM address. The reason is,
> > that on Zynq arch bus masters cannot access RAM below 0x80000. Therefore
> > my question: how shall I configure this in software?
> >
> > The way I found was to use ARM-specific struct dmabounce_device_info and
> > implement its .needs_bounce() method to return true for those addresses.
> > Is this the right way or is there a better / more straight-forward one?
> >
> > To do the above I have to enable CONFIG_DMABOUNCE, which then selects
> > CONFIG_ZONE_DMA. Having done just that I suddenly discover, that 0x3000
> > buffers aren't used any more, so, I cannot actually verify my
> > implementation :) Looking at ZONE_DMA it looks like it is still covering
> > the whole RAM range (/proc/zoneinfo shows start_pfn=0 in zone DMA), so, I
> > don't see why 0x3000 should be excluded now.
> >
> > So, is using the .needs_bounce() method the correct way to support DMA on
> > this arch or is there a better one?
>
> I have a similar issue with Renesas R8A7790 where there is a bus bridge
> that can only deal with transactions to one half of the available RAM.
Have you tried enabling CONFIG_DMABOUNCE?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH v5 20/20] ARM: dove: Enable watchdog support in the defconfig
From: Ezequiel Garcia @ 2014-01-27 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
Now that we have watchdog support, let's add it to the defconfig.
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
arch/arm/configs/dove_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/dove_defconfig b/arch/arm/configs/dove_defconfig
index 1101054..a330690 100644
--- a/arch/arm/configs/dove_defconfig
+++ b/arch/arm/configs/dove_defconfig
@@ -80,6 +80,8 @@ CONFIG_SPI_ORION=y
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
CONFIG_DOVE_THERMAL=y
+CONFIG_WATCHDOG=y
+CONFIG_ORION_WATCHDOG=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_EHCI_HCD=y
--
1.8.1.5
^ permalink raw reply related
* [PATCH v5 19/20] ARM: mvebu: Enable watchdog support in defconfig
From: Ezequiel Garcia @ 2014-01-27 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390836440-12744-1-git-send-email-ezequiel.garcia@free-electrons.com>
Now that we have proper support for Armada 370/XP watchdog
let's enable it in the defconfig.
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
arch/arm/configs/mvebu_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 594d706..84ec924 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -60,6 +60,8 @@ CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_THERMAL=y
CONFIG_ARMADA_THERMAL=y
+CONFIG_WATCHDOG=y
+CONFIG_ORION_WATCHDOG=y
CONFIG_USB_SUPPORT=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
--
1.8.1.5
^ 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