* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jean-Francois Moine @ 2014-01-22 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122111953.238349a5@armhf>
On Wed, 22 Jan 2014 11:19:53 +0100
Jean-Francois Moine <moinejf@free.fr> wrote:
> As both I2S and S/PDIF may be used for HDMI output in the Cubox,
> I wrote a tda998x CODEC which gets the audio ports from the DT and
> dynamically sets these ports and the audio type (i2s / spdif) on audio
> streaming start. I have not submitted yet this codec and the associated
> changes in tda998x, because I am waiting for a first patch series on the
> tda998x to be applied
> (http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).
Sorry, the last patch request is
http://lists.freedesktop.org/archives/dri-devel/2014-January/052201.html
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* mutual exculsion between clk_prepare_enable /clk_disable_unprepare and clk_set_parent
From: Russell King - ARM Linux @ 2014-01-22 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFgnuDdOKxzFSDCBQTGw=p_t0CvKfjVEudttOCP_wrzyA2K1Og@mail.gmail.com>
On Wed, Jan 22, 2014 at 02:02:57PM +0800, Xiaoguang Chen wrote:
> Hi, Mike
>
> We met a issue between clk_prepare_enable /clk_disable_unprepare and
> clk_set_parent.
clk_prepare_enable/disable_unprepare are perfectly fine in themselves.
You're looking at the problem wrongly - because drivers can perfectly
well call clk_prepare() and clk_unprepare() themselves. There's no
requirement for the enable and prepare to be paired together under any
kind of lock.
> and if below condition occurs, there will be problem
>
> thread1 thread 2
> call clk_disable_unprepare
Okay, if we're calling clk_disable_unprepare(), then the clock
must already have been prepared and enabled - which means that
the current parent is already prepared and enabled.
> 1) clk_disable
> get enable lock
> ...............
> release enable lock
This may result in the parent being disabled too.
>
> call clk_set_parent
> get prepare lock
> set clock's
> parent to another parent
At this point, the existing parent clock should be disabled if this
clock was enabled, and unprepared if this clock was prepared. The
new parent should be prepared and enabled as appropriate too so that
everything is kept balanced.
> release prepare lock
>
> 2) clk_unprepare
> get prepare lock
> unprepare parent clock <<--------------
> release prepare lock
And with the above guarantee - which is required in any case to make
reparenting safe - there's no problem here.
--
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
* Question: about wm8904's regulator consumer nodes
From: Yang, Wenyou @ 2014-01-22 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121181032.GI17314@sirena.org.uk>
Hi Mark,
> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Mark Brown
> Sent: Wednesday, January 22, 2014 2:11 AM
> To: Yang, Wenyou
> Cc: linux-arm-kernel at lists.infradead.org
> Subject: Re: Question: about wm8904's regulator consumer nodes
>
> On Tue, Jan 21, 2014 at 07:10:24AM +0000, Yang, Wenyou wrote:
>
> > DCVDD-supply = <&vcc_1v8_reg>;
> > DBVDD-supply = <&vddana_reg>;
> > AVDD-supply = <&vcc_1v8_reg>;
> > CPVDD-supply = <&vcc_1v8_reg>;
> > MICVDD-supply =
> > <&vddana_reg>;
>
> > But the power of DCVDD, DBVDD, AVDD, CPVDD and MICVDD is not
> supplied by any regulators, not the above regulator nodes.
>
> > How do I deal with this case? Could you give me some advice?
>
> You should set up the supplies to point to whatever regulator is
> supplying the power. If there are supplies on the board which are
> generated using fixed voltage regulators then you should register those
> using the fixed regulator driver. Recent kernels are more tolerant of
> missing supplies but it's still better to be explicit if you can be.
Thank a lot for your answer.
Best Regards,
Wenyou Yang
^ permalink raw reply
* [PATCH v6 0/3] AArch64: KGDB support
From: Will Deacon @ 2014-01-22 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6tn4SJ4BjDGBNwH_8dGt82yHeAVyLzP+97rb8FDJdZSYQ@mail.gmail.com>
On Wed, Jan 22, 2014 at 07:50:46AM +0000, Vijay Kilari wrote:
> On Wed, Jan 22, 2014 at 10:01 AM, Vijay Kilari <vijay.kilari@gmail.com> wrote:
> >>> On Mon, Jan 20, 2014 at 3:53 PM, Will Deacon <will.deacon@arm.com> wrote:
> >> That's a good point: I think we wait until our first exception before they
> >> are unmasked. Perhaps we should:
> >>
> >> (1) Move local_dbg_{save,restore} from debug-monitors.h into irqflags.h
>
> local_dbg_save is setting bit #8 it should be bit #9?
>
> #define local_dbg_save(flags)
> \
> do {
> \
> typecheck(unsigned long, flags);
> \
> asm volatile(
> \
> "mrs %0, daif //
> local_dbg_save\n" \
> "msr daifset, #8"
That uses daifset, so #8 is bit 3 which is D.
> >> (2) Add local_dbg_enable/local_dbg_disable macros
> >> (3) Add a call to local_dbg_enable in the clear_os_lock function after the
> >> isb().
> >>
> >> Does that work for you?
> >
> > Yes, only after first exception occurs the PSTATE.D is unmasked.
> >
> > I have patched (temp) as below and now KGDB boot tests pass
> >
> > diff --git a/arch/arm64/include/asm/debug-monitors.h
> > b/arch/arm64/include/asm/debug-monitors.h
> > index aff3a76..ea2bc46 100644
> > --- a/arch/arm64/include/asm/debug-monitors.h
> > +++ b/arch/arm64/include/asm/debug-monitors.h
> > @@ -64,6 +111,24 @@ struct task_struct;
> >
> > #define DBG_ARCH_ID_RESERVED 0 /* In case of ptrace ABI updates. */
> >
> > +#define local_dbg_enable()
> > \
> > + do {
> > \
> > + asm volatile(
> > \
> > + "msr daifclr, #9 //
I think this is going to unmask fiq as well...
Will
^ permalink raw reply
* [PATCH REPOST 1/5] ARM: kvm: replace push and pop with stdmb and ldmia instrs to enable assembler.h inclusion
From: Will Deacon @ 2014-01-22 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA3XUr3rpEBCWbE0HGu14qgGsmt6J21D_yDeK2nFvK6_-cjPag@mail.gmail.com>
[Adding Nico, as the author of the push/pull macros. Background is that kvm
is using push to store to the stack and would now like to include assembler.h]
On Wed, Jan 22, 2014 at 06:41:09AM +0000, Victor Kamensky wrote:
> On 21 January 2014 01:58, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > How about trying this alternative approach:
> >
> > It looks like all the users of the push/pop macros are located in
> > arch/arm/lib (mostly checksumming code). Can't we move these macros to a
> > separate include file and leave the code that uses push/pop (as defined
> > by the assembler) alone?
>
> Marc, personally I am OK with such proposal. I was considering something
> along these lines as one of the options. It works for me both ways. If
> others agree I am happy to recode it as your suggested. I choose
> proposed above patch because kvm arm code came after push and pop
> defines were introduced in asm/assembler.h and used in other places.
> I am OK either way. I agree that use of push and pop as define names
> seems a bit unfortunate, but I don't have any historic visibility here
>
> Russell, Dave, Will, do you have any opinion on Marc's proposal to
> fix this issue?
I'm perfectly fine with moving those macros into a lib/-local header file.
An alternative is renaming push/pull to something like lspush and lspull
and updating the files under lib.
Will
^ permalink raw reply
* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jean-Francois Moine @ 2014-01-22 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DF8D60.9020505@ti.com>
On Wed, 22 Jan 2014 11:20:32 +0200
Jyri Sarha <jsarha@ti.com> wrote:
> On 01/15/2014 05:51 PM, Jean-Francois Moine wrote:
> > On Wed, 15 Jan 2014 13:27:21 +0200
> > Jyri Sarha <jsarha@ti.com> wrote:
> >
> >> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
> >> register statically to a value that works only with 4 byte samples.
> >> According to my tests it is possible to support 3 and 2 byte samples too
> >> by changing the CTS_N register value, but I am not sure if the
> >> configuration can be changed on the fly. My data sheet of the nxp chip
> >> is very vague about the register definitions, but I suppose the register
> >> configures some clock divider on the chip. HDMI supports only upto 24bit
> >> audio and the data sheet states that any extraneous least significant
> >> bits are ignored.
> >
> > In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is
> > not set).
> >
> > Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits
> > formats are working well with I2S input at any rate.
> >
>
> Could you refer the kernel version (main line?) and the involved ASoC
> drivers so could take I a look if there is something I could do differently?
Both drivers are in the kernel main line.
The ASoC is in sound/soc/kirkwood/. kirkwood-i2s.c defines the DAIs I2S
and S/PDIF outputs.
As both I2S and S/PDIF may be used for HDMI output in the Cubox,
I wrote a tda998x CODEC which gets the audio ports from the DT and
dynamically sets these ports and the audio type (i2s / spdif) on audio
streaming start. I have not submitted yet this codec and the associated
changes in tda998x, because I am waiting for a first patch series on the
tda998x to be applied
(http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Linus Walleij @ 2014-01-22 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5OOx8LgGVN0GFsa5-f=h1kasJVz4r0CfBXdXhK0F8iQAQ@mail.gmail.com>
On Thu, Jan 16, 2014 at 1:02 PM, Jean-Jacques Hiblot
<jjhiblot@traphandler.com> wrote:
> Linus,
> the root of the issue is the fact that a GPIO can't be requested
> twice. But IMO it's safe for a single device to request it more than
> once and use it for different purposes (irq and electrical signal
> value). Maybe we can rework the GPIO request to include this ownership
> information. I can post a draft implementation for this if you think
> it's worthwhile.
You are right and actually Jean-Christophe's patch is a good
start.
You also need to use the gpio_lock_as_irq() API as shown in
other patches to the subsystem e.g. this.
commit eb7cce1ea96b6399672abce787598f6e7a4352c3
Also check my other mail in this thread.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 2/2] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
From: Kishon Vijay Abraham I @ 2014-01-22 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DF7A78.5030700@ti.com>
On Wednesday 22 January 2014 01:29 PM, Roger Quadros wrote:
> On 01/22/2014 08:04 AM, Vivek Gautam wrote:
>> Hi,
>>
>>
>> On Tue, Jan 21, 2014 at 7:30 PM, Roger Quadros <rogerq@ti.com> wrote:
>>> Hi Kishon,
>>>
>>> On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
>>>> Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
>>>> power_on and power_off the following APIs are used phy_init(), phy_exit(),
>>>> phy_power_on() and phy_power_off().
>>>>
>>>> However using the old USB phy library wont be removed till the PHYs of all
>>>> other SoC's using dwc3 core is adapted to the Generic PHY Framework.
>>>>
>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>> ---
>>>> Changes from v3:
>>>> * avoided using quirks
>>>>
>>>> Documentation/devicetree/bindings/usb/dwc3.txt | 6 ++-
>>>> drivers/usb/dwc3/core.c | 60 ++++++++++++++++++++++++
>>>> drivers/usb/dwc3/core.h | 7 +++
>>>> 3 files changed, 71 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> index e807635..471366d 100644
>>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>> @@ -6,11 +6,13 @@ Required properties:
>>>> - compatible: must be "snps,dwc3"
>>>> - reg : Address and length of the register set for the device
>>>> - interrupts: Interrupts used by the dwc3 controller.
>>>> +
>>>> +Optional properties:
>>>> - usb-phy : array of phandle for the PHY device. The first element
>>>> in the array is expected to be a handle to the USB2/HS PHY and
>>>> the second element is expected to be a handle to the USB3/SS PHY
>>>> -
>>>> -Optional properties:
>>>> + - phys: from the *Generic PHY* bindings
>>>> + - phy-names: from the *Generic PHY* bindings
>>>> - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
>>>>
>>>> This is usually a subnode to DWC3 glue to which it is connected.
>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>> index e009d4e..036d589 100644
>>>> --- a/drivers/usb/dwc3/core.c
>>>> +++ b/drivers/usb/dwc3/core.c
>>>> @@ -82,6 +82,11 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
>>>>
>>>> usb_phy_init(dwc->usb2_phy);
>>>> usb_phy_init(dwc->usb3_phy);
>>>> + if (dwc->usb2_generic_phy)
>>>> + phy_init(dwc->usb2_generic_phy);
>>>
>>> What if phy_init() fails? You need to report and fail. Same applies for all PHY apis in this patch.
>>>
>>>> + if (dwc->usb3_generic_phy)
>>>> + phy_init(dwc->usb3_generic_phy);
>>>> +
>>>> mdelay(100);
>>>>
>>>> /* Clear USB3 PHY reset */
>>>> @@ -343,6 +348,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
>>>> {
>>>> usb_phy_shutdown(dwc->usb2_phy);
>>>> usb_phy_shutdown(dwc->usb3_phy);
>>>> + if (dwc->usb2_generic_phy)
>>>> + phy_exit(dwc->usb2_generic_phy);
>>>> + if (dwc->usb3_generic_phy)
>>>> + phy_exit(dwc->usb3_generic_phy);
>>>> +
>>>> }
>>>>
>>>> #define DWC3_ALIGN_MASK (16 - 1)
>>>> @@ -433,6 +443,32 @@ static int dwc3_probe(struct platform_device *pdev)
>>>> }
>>>> }
>>>>
>>>> + dwc->usb2_generic_phy = devm_phy_get(dev, "usb2-phy");
>>>> + if (IS_ERR(dwc->usb2_generic_phy)) {
>>>> + ret = PTR_ERR(dwc->usb2_generic_phy);
>>>> + if (ret == -ENOSYS || ret == -ENODEV) {
>>>> + dwc->usb2_generic_phy = NULL;
>>>> + } else if (ret == -EPROBE_DEFER) {
>>>> + return ret;
>>>> + } else {
>>>> + dev_err(dev, "no usb2 phy configured\n");
>>>> + return ret;
>>>> + }
>>>> + }
>>>> +
>>>> + dwc->usb3_generic_phy = devm_phy_get(dev, "usb3-phy");
>>>> + if (IS_ERR(dwc->usb3_generic_phy)) {
>>>> + ret = PTR_ERR(dwc->usb3_generic_phy);
>>>> + if (ret == -ENOSYS || ret == -ENODEV) {
>>>> + dwc->usb3_generic_phy = NULL;
>>>> + } else if (ret == -EPROBE_DEFER) {
>>>> + return ret;
>>>> + } else {
>>>> + dev_err(dev, "no usb3 phy configured\n");
>>>> + return ret;
>>>> + }
>>>> + }
>>>> +
>>>> dwc->xhci_resources[0].start = res->start;
>>>> dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
>>>> DWC3_XHCI_REGS_END;
>>>> @@ -482,6 +518,11 @@ static int dwc3_probe(struct platform_device *pdev)
>>>> usb_phy_set_suspend(dwc->usb2_phy, 0);
>>>> usb_phy_set_suspend(dwc->usb3_phy, 0);
>>>>
>>>> + if (dwc->usb2_generic_phy)
>>>> + phy_power_on(dwc->usb2_generic_phy);
>>>> + if (dwc->usb3_generic_phy)
>>>> + phy_power_on(dwc->usb3_generic_phy);
>>>> +
>>>
>>> Is it OK to power on the phy before phy_init()?
>>
>> Isn't phy_init() being done before phy_power_on() in the
>> core_soft_reset() in this patch ?
>> Isn't that what you want here ?
>>
>>>
>>> I suggest to move phy_init() from core_soft_reset() to here, just before phy_power_on().
>>
>> core_soft_reset() is called before phy_power_on() itself from
>> dwc3_core_init(), right ?
>> will moving the phy_inti() here make nay difference ?
>
> You are right. This part is fine then.
Yeah.. it was fixed in one of the earlier patches which got merged.
commit 3088f1085d1c08f31f02db26796555a66cdf7ca1
Author: Kishon Vijay Abraham I <kishon@ti.com>
Date: Mon Nov 25 15:31:21 2013 +0530
usb: dwc3: invoke phy_resume after phy_init
usb_phy_set_suspend(phy, 0) is called before usb_phy_init. Fix it.
Reported-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Cheers,
Kishon
>
> cheers,
> -roger
>
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Linus Walleij @ 2014-01-22 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D6C545.6080402@atmel.com>
On Wed, Jan 15, 2014 at 6:28 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> On 13/01/2014 11:35, boris brezillon :
>> You should only request it as a GPIO and then use gpio_to_irq to get the
>> related IRQ.
>> Because what is done here, is to solve the case where only the irq
>> is request, and in this specific case we need to request the pin as a
>> GPIO.
>
> Yes, this is what we do.
>
> It seems simple and obvious to me, but some may say that "you shall not
> do that, it is horrible!". Well... I always tend to choose a solution
> that works. It is one of my weaknesses, I admit ;-)
>
> Linus W. any advice on this, before we hit again one of those infinite
> threads that leads no progress at all?
So we recently established that it is actually OK for any IRQ
consumer to request an IRQ from any irq_chip no matter if
that is a combined GPIO+IRQ driver. This was concluded after
a long discussion involving several parties.
gpio_to_irq() is just a convenience function and should not be
relied upon to have been called before the IRQ is used.
The basic premise is that gpio_chip and irq_chip are
orthogonal, and offering their services independent of each
other.
Especially in the device tree use case it is very hard to
dictate that a certain semantic need to be followed to use
a certain interrupt-controller to have dependencies to a
certain gpio-controller. So they need to be orthogonal.
First step is: always prepare the hardware and make it
ready for action in respective callbacks from the gpio_chip API
and irq_chip API. Do not rely on gpio_to_irq() having been
called first anymore.
This leads to ambiguities that we need to solve: if there is
competition inside the subsystem which side is using
the resource (a certain GPIO line and register for example)
it needs to deny certain operations and keep track of usage
inside of the gpiolib subsystem.
We have added a new API to help with this situation:
gpio_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
gpio_unlock_as_irq(struct gpio_chip *chip,
unsigned int offset)
These should be called from the irq_chip startup() and
.shutdown() callbacks to flag that the line is now in use by
an IRQ. For example the GPIOlib core will deny the line to
be set as output after this.
If we need more infrastructure to help with this, I'm game.
Clear as mud? ;-)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Linus Walleij @ 2014-01-22 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKFfAvSPYLmvWV5jjT-peZFJ8sJ2bbh4F=JAYoWLhjZpA@mail.gmail.com>
On Tue, Jan 21, 2014 at 3:53 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> The good (or bad, rather) thing about DT is that we can do whatever we
> please with the new bindings: decide which name or which index
> (doesn't matter here) a GPIO should have. However we don't have this
> control over ACPI, where nothing guarantees that the same index will
> be used for the same GPIO function.
It's not like ACPI will impose some tables on us and expect us to
use them as-is no matter how crazy they are. Then indeed the whole
idea of unifying ACPI and DT accessors would be moot and it would
only work by mistake or as a good joke.
The situation with ACPI is just like with DT, it is assumed that the
author of these tables also look at the Linux kernel drivers to figure
out what argument goes where and we can influence them.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Linus Walleij @ 2014-01-22 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKFfAvSPYLmvWV5jjT-peZFJ8sJ2bbh4F=JAYoWLhjZpA@mail.gmail.com>
On Tue, Jan 21, 2014 at 3:53 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Tue, Jan 21, 2014 at 9:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday 21 January 2014, Linus Walleij wrote:
>>> As discussed earlier in this thread I'm not sure the con_id is
>>> suitable for labelling GPIOs. It'd be better to have a proper name
>>> specified in DT/ACPI instead.
>>
>> +1
>
> I wonder why you guys prefer to have the name defined in the GPIO
> mapping. Having the driver decide the label makes it easier to look up
> which GPIO does what in debugfs, whereas nothing prevents people to
> name GPIOs whatever inadequate name they want in the device DT node.
> What am I overlooking here?
The proper name of a GPIO does not come from the driver but from the
usecase, i.e. often the name of the rail on the board where it is used.
Remember GPIO are per definition general purpose, they cannot get
any clever names from the driver. They would just be named
"chip-foo-gpio0" thru "chip-foo-gpioN" if the driver was to name them.
Using the rail name on the board is way more useful. A GPIO line
named "HAL_SENSOR" or "MMC_CD" is actually telling us what
that line is used for.
But such names can only come from a DT or ACPI table that has
knowledge of how the GPIO is used on a certain system/board and
not just from the driver.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 05/15] watchdog: orion: Make RSTOUT register a separate resource
From: Arnd Bergmann @ 2014-01-22 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121233321.GR18269@obsidianresearch.com>
On Tuesday 21 January 2014 16:33:21 Jason Gunthorpe wrote:
> On Tue, Jan 21, 2014 at 06:12:31AM -0300, Ezequiel Garcia wrote:
> > In order to support other SoC, it's required to distinguish
> > the 'control' timer register, from the 'rstout' register
> > that enables system reset on watchdog expiration.
>
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > + if (!res)
> > + return -ENODEV;
> ^^^^^^^^^^^^^^^^^^^^^^
>
> This change seems to break compatibility with existing DT files that
> have only a single entry in reg?
>
> Can the value be defaulted some how if missing?
I think this is a direct consequence of the attempt to remove the
header file dependency, since the RSTOUTn_MASK macro is defined
in mach/bridge-regs.h.
I don't see a good way out that would preserve backwards compatibility,
other than hardcoding the physical address in the driver, which seems
just as bad as breaking compatibility. That said, it is always the
same constant (0xf1000000 + 0x20000 + 0x0108) on Dove, Kirkwood and
Orion5x (not on mv78xx0, but that doesn't use the wdt), so hardcoding
a fallback would technically work, but we should print a fat warning at
boot time if we actually fall back to that.
Arnd
^ permalink raw reply
* [Xen-devel] [PATCH v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
From: Ian Campbell @ 2014-01-22 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390311864-19119-1-git-send-email-stefano.stabellini@eu.citrix.com>
On Tue, 2014-01-21 at 13:44 +0000, Stefano Stabellini wrote:
> Remove !GENERIC_ATOMIC64 build dependency:
> - introduce xen_atomic64_xchg
> - use it to implement xchg_xen_ulong
>
> Remove !CPU_V6 build dependency:
> - introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef
> CONFIG_CPU_V6
> - implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
^ permalink raw reply
* [PATCH] tty/serial: atmel_serial: remove dev_dbg in atmel_set_termios
From: Nicolas Ferre @ 2014-01-22 9:38 UTC (permalink / raw)
To: linux-arm-kernel
This fixes a driver bug which stopped the whole system (in case
of serial console).
This log message is not useful anyway as this information is
printed elsewhere.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/tty/serial/atmel_serial.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index a49f10d269b2..3d7206fc532f 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1853,13 +1853,10 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
mode &= ~ATMEL_US_USMODE;
if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
- dev_dbg(port->dev, "Setting UART to RS485\n");
if ((atmel_port->rs485.delay_rts_after_send) > 0)
UART_PUT_TTGR(port,
atmel_port->rs485.delay_rts_after_send);
mode |= ATMEL_US_USMODE_RS485;
- } else {
- dev_dbg(port->dev, "Setting UART to RS232\n");
}
/* set the parity, stop bits and data size */
--
1.8.2.2
^ permalink raw reply related
* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jyri Sarha @ 2014-01-22 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115165100.3bfab96f@armhf>
On 01/15/2014 05:51 PM, Jean-Francois Moine wrote:
> On Wed, 15 Jan 2014 13:27:21 +0200
> Jyri Sarha <jsarha@ti.com> wrote:
>
>> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
>> register statically to a value that works only with 4 byte samples.
>> According to my tests it is possible to support 3 and 2 byte samples too
>> by changing the CTS_N register value, but I am not sure if the
>> configuration can be changed on the fly. My data sheet of the nxp chip
>> is very vague about the register definitions, but I suppose the register
>> configures some clock divider on the chip. HDMI supports only upto 24bit
>> audio and the data sheet states that any extraneous least significant
>> bits are ignored.
>
> In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is
> not set).
>
> Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits
> formats are working well with I2S input at any rate.
>
Could you refer the kernel version (main line?) and the involved ASoC
drivers so could take I a look if there is something I could do differently?
Best regards,
Jyri
^ permalink raw reply
* [PATCHv3 00/41] OMAPDSS: DT support v3
From: Tomi Valkeinen @ 2014-01-22 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DEE6B0.20106@ti.com>
On 2014-01-21 23:29, Nishanth Menon wrote:
> Tomi,
>
> On 01/21/2014 04:56 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> Here's version 3 of the DSS DT series.
>>
>> The previous version can be found from:
>>
>> v1: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108249
>> v2: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108866
>>
>> The main changes to v2 are:
>>
>> - DT Binding documentation
>> - OMAP2 DSS support
>> - Split DSI register space
>> - DSS nodes disabled by default
>> - Hack to have generic DT bindings but OMAP specific drivers (for now)
>>
>> This series can also be found from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-review-3
>>
> http://slexy.org/view/s20JhteOFR is my quick build test report -> few
> checkpatch and build bisect issues would probably need fixing.
Thanks. Shouldn't make trivial changes, and then not run a full
commit-by-commit compile test...
I fixed the issues and pushed the branch again to work/dss-dt-review-3.
The fixes are minor, so the already posted series can be reviewed.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140122/257a5b6c/attachment.sig>
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Linus Walleij @ 2014-01-22 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389961514-13562-19-git-send-email-hanjun.guo@linaro.org>
On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
>
> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
> name from the ACPI timer table is matched with all the registered
> timer controllers and matching initialisation routine is invoked.
>
> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
to TIMER_OF_DECLARE() and I think this macro, if needed, should
be named TIMER_ACPI_DECLARE().
The reason is that "clocksource" is a Linux-internal name and this
macro pertains to the hardware name in respective system
description type.
> +#ifdef CONFIG_ACPI
> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
> + static const struct acpi_device_id __clksrc_acpi_table_##name \
> + __used __section(__clksrc_acpi_table) \
> + = { .id = compat, \
> + .driver_data = (kernel_ulong_t)fn }
> +#else
> +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
> +#endif
This hammers down the world to compile one binary for ACPI
and one binary for device tree. Maybe that's fine, I don't know.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 2/2] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
From: Roger Quadros @ 2014-01-22 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFp+6iFkgD8x4DozhQdRSx=KLWGwR5pOsCxrVgWbcnCMTFT-sg@mail.gmail.com>
On 01/22/2014 08:04 AM, Vivek Gautam wrote:
> Hi,
>
>
> On Tue, Jan 21, 2014 at 7:30 PM, Roger Quadros <rogerq@ti.com> wrote:
>> Hi Kishon,
>>
>> On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
>>> Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
>>> power_on and power_off the following APIs are used phy_init(), phy_exit(),
>>> phy_power_on() and phy_power_off().
>>>
>>> However using the old USB phy library wont be removed till the PHYs of all
>>> other SoC's using dwc3 core is adapted to the Generic PHY Framework.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> Changes from v3:
>>> * avoided using quirks
>>>
>>> Documentation/devicetree/bindings/usb/dwc3.txt | 6 ++-
>>> drivers/usb/dwc3/core.c | 60 ++++++++++++++++++++++++
>>> drivers/usb/dwc3/core.h | 7 +++
>>> 3 files changed, 71 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
>>> index e807635..471366d 100644
>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>> @@ -6,11 +6,13 @@ Required properties:
>>> - compatible: must be "snps,dwc3"
>>> - reg : Address and length of the register set for the device
>>> - interrupts: Interrupts used by the dwc3 controller.
>>> +
>>> +Optional properties:
>>> - usb-phy : array of phandle for the PHY device. The first element
>>> in the array is expected to be a handle to the USB2/HS PHY and
>>> the second element is expected to be a handle to the USB3/SS PHY
>>> -
>>> -Optional properties:
>>> + - phys: from the *Generic PHY* bindings
>>> + - phy-names: from the *Generic PHY* bindings
>>> - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
>>>
>>> This is usually a subnode to DWC3 glue to which it is connected.
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index e009d4e..036d589 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -82,6 +82,11 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
>>>
>>> usb_phy_init(dwc->usb2_phy);
>>> usb_phy_init(dwc->usb3_phy);
>>> + if (dwc->usb2_generic_phy)
>>> + phy_init(dwc->usb2_generic_phy);
>>
>> What if phy_init() fails? You need to report and fail. Same applies for all PHY apis in this patch.
>>
>>> + if (dwc->usb3_generic_phy)
>>> + phy_init(dwc->usb3_generic_phy);
>>> +
>>> mdelay(100);
>>>
>>> /* Clear USB3 PHY reset */
>>> @@ -343,6 +348,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
>>> {
>>> usb_phy_shutdown(dwc->usb2_phy);
>>> usb_phy_shutdown(dwc->usb3_phy);
>>> + if (dwc->usb2_generic_phy)
>>> + phy_exit(dwc->usb2_generic_phy);
>>> + if (dwc->usb3_generic_phy)
>>> + phy_exit(dwc->usb3_generic_phy);
>>> +
>>> }
>>>
>>> #define DWC3_ALIGN_MASK (16 - 1)
>>> @@ -433,6 +443,32 @@ static int dwc3_probe(struct platform_device *pdev)
>>> }
>>> }
>>>
>>> + dwc->usb2_generic_phy = devm_phy_get(dev, "usb2-phy");
>>> + if (IS_ERR(dwc->usb2_generic_phy)) {
>>> + ret = PTR_ERR(dwc->usb2_generic_phy);
>>> + if (ret == -ENOSYS || ret == -ENODEV) {
>>> + dwc->usb2_generic_phy = NULL;
>>> + } else if (ret == -EPROBE_DEFER) {
>>> + return ret;
>>> + } else {
>>> + dev_err(dev, "no usb2 phy configured\n");
>>> + return ret;
>>> + }
>>> + }
>>> +
>>> + dwc->usb3_generic_phy = devm_phy_get(dev, "usb3-phy");
>>> + if (IS_ERR(dwc->usb3_generic_phy)) {
>>> + ret = PTR_ERR(dwc->usb3_generic_phy);
>>> + if (ret == -ENOSYS || ret == -ENODEV) {
>>> + dwc->usb3_generic_phy = NULL;
>>> + } else if (ret == -EPROBE_DEFER) {
>>> + return ret;
>>> + } else {
>>> + dev_err(dev, "no usb3 phy configured\n");
>>> + return ret;
>>> + }
>>> + }
>>> +
>>> dwc->xhci_resources[0].start = res->start;
>>> dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
>>> DWC3_XHCI_REGS_END;
>>> @@ -482,6 +518,11 @@ static int dwc3_probe(struct platform_device *pdev)
>>> usb_phy_set_suspend(dwc->usb2_phy, 0);
>>> usb_phy_set_suspend(dwc->usb3_phy, 0);
>>>
>>> + if (dwc->usb2_generic_phy)
>>> + phy_power_on(dwc->usb2_generic_phy);
>>> + if (dwc->usb3_generic_phy)
>>> + phy_power_on(dwc->usb3_generic_phy);
>>> +
>>
>> Is it OK to power on the phy before phy_init()?
>
> Isn't phy_init() being done before phy_power_on() in the
> core_soft_reset() in this patch ?
> Isn't that what you want here ?
>
>>
>> I suggest to move phy_init() from core_soft_reset() to here, just before phy_power_on().
>
> core_soft_reset() is called before phy_power_on() itself from
> dwc3_core_init(), right ?
> will moving the phy_inti() here make nay difference ?
You are right. This part is fine then.
cheers,
-roger
^ permalink raw reply
* [PATCH v6 0/3] AArch64: KGDB support
From: Vijay Kilari @ 2014-01-22 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6tx9aLmXpai5SFzZeR6cfu7NKF7WipZWY1nrKGBcA-oGA@mail.gmail.com>
On Wed, Jan 22, 2014 at 10:01 AM, Vijay Kilari <vijay.kilari@gmail.com> wrote:
> On Wed, Jan 22, 2014 at 12:06 AM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, Jan 21, 2014 at 02:10:14PM +0000, Vijay Kilari wrote:
>>> Hi Will,
>>
>> Hello Vijay,
>>
>>> On Mon, Jan 20, 2014 at 3:53 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> > Well, the warnings are one thing but the 100 miles of backtrace output that
>>> > appear on every boot (and I think end in an oops) are probably more
>>> > important to fix. Please enable CONFIG_KGDB_TESTS and
>>> > CONFIG_KGDB_TESTS_ON_BOOT and take a look.
>>> >
>>>
>>> I could manage to run KGDB boot tests if I run from sysfs after complete boot
>>>
>>> echo V1F1000 > /sys/module/kgdbts/parameters/kgdbts
>>>
>>> Here the value of PSTATE is 80000145, which means PSTATE.D is unmasked
>>> hence it works fine.
>>>
>>> If I run during boot by enabling CONFIG_KGDB_TESTS_ON_BOOT,
>>> the step debug test fail because value of PSTATE is 80000345.
>>> If I force PSTATE.D to 0, it works fine
>>>
>>> In debug_monitors.c file, only PSTATE.SS & MDSCR.KDE/MDE is managed
>>> but not PSTATE.D
>>>
>>> Can you please let me know if where PSTATE.D is managed in arm64?
>>
>> That's a good point: I think we wait until our first exception before they
>> are unmasked. Perhaps we should:
>>
>> (1) Move local_dbg_{save,restore} from debug-monitors.h into irqflags.h
local_dbg_save is setting bit #8 it should be bit #9?
#define local_dbg_save(flags)
\
do {
\
typecheck(unsigned long, flags);
\
asm volatile(
\
"mrs %0, daif //
local_dbg_save\n" \
"msr daifset, #8"
\
: "=r" (flags) : : "memory");
\
} while (0)
>> (2) Add local_dbg_enable/local_dbg_disable macros
>> (3) Add a call to local_dbg_enable in the clear_os_lock function after the
>> isb().
>>
>> Does that work for you?
>
> Yes, only after first exception occurs the PSTATE.D is unmasked.
>
> I have patched (temp) as below and now KGDB boot tests pass
>
> diff --git a/arch/arm64/include/asm/debug-monitors.h
> b/arch/arm64/include/asm/debug-monitors.h
> index aff3a76..ea2bc46 100644
> --- a/arch/arm64/include/asm/debug-monitors.h
> +++ b/arch/arm64/include/asm/debug-monitors.h
> @@ -64,6 +111,24 @@ struct task_struct;
>
> #define DBG_ARCH_ID_RESERVED 0 /* In case of ptrace ABI updates. */
>
> +#define local_dbg_enable()
> \
> + do {
> \
> + asm volatile(
> \
> + "msr daifclr, #9 //
> arch_local_irq_disable" \
> + :
> \
> + :
> \
> + : "memory");
> \
> + } while (0)
> +
> +#define local_dbg_disable()
> \
> + do {
> \
> + asm volatile(
> \
> + "msr daifset, #9 //
> arch_local_irq_disable" \
> + :
> \
> + :
> \
> + : "memory");
> \
> + } while (0)
> +
> struct step_hook {
> struct list_head node;
> int (*fn)(struct pt_regs *regs, unsigned int insn, unsigned long addr);
>
> diff --git a/arch/arm64/kernel/debug-monitors.c
> b/arch/arm64/kernel/debug-monitors.c
> index f8b90c0..d0e55f7 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -139,6 +142,7 @@ static void clear_os_lock(void *unused)
> {
> asm volatile("msr oslar_el1, %0" : : "r" (0));
> isb();
> + local_dbg_enable();
> }
>
>
> boot test:
>
> [32927.161317] msgmni has been set to 1870
> [32927.212747] alg: No test for stdrng (krng)
> [32927.213953] Key type asymmetric registered
> [32927.214899] Asymmetric key parser 'x509' registered
> [32927.220029] Block layer SCSI generic (bsg) driver version 0.4
> loaded (major 253)
> [32927.225824] io scheduler noop registered
> [32927.226764] io scheduler deadline registered
> [32927.230714] io scheduler cfq registered (default)
> [32927.237895] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> [32927.266066] kgdb: Registered I/O driver kgdbts.
> [32927.266419] kgdb: Waiting for connection from remote gdb...
> [32927.268598] kgdbts:RUN plant and detach test
> [32927.270683] kgdbts:RUN sw breakpoint test
> [32927.287659] kgdbts:RUN bad memory access test
> [32927.290322] kgdbts:RUN singlestep test 1000 iterations
> [32927.330342] kgdbts:RUN singlestep [0/1000]
> [32931.286356] kgdbts:RUN singlestep [100/1000]
> [32935.242536] kgdbts:RUN singlestep [200/1000]
> [32939.205392] kgdbts:RUN singlestep [300/1000]
> [32943.169522] kgdbts:RUN singlestep [400/1000]
> [32947.231868] kgdbts:RUN singlestep [500/1000]
> [32951.188008] kgdbts:RUN singlestep [600/1000]
> [32955.332243] kgdbts:RUN singlestep [700/1000]
> [32959.467109] kgdbts:RUN singlestep [800/1000]
> [32963.430888] kgdbts:RUN singlestep [900/1000]
> [32967.346992] kgdbts:RUN do_fork for 100 breakpoints
>
> kgdb test using sysfs:
>
> ~ # echo V1F1000 > /sys/module/kgdbts/parameters/kgdbts
> [33231.554237] kgdb: Registered I/O driver kgdbts.
> [33231.554677] kgdbts:RUN plant and detach test
> [33231.557072] kgdbts:RUN sw breakpoint test
> [33231.576980] kgdbts:RUN bad memory access test
> [33231.580022] kgdbts:RUN singlestep test 1000 iterations
> [33231.627056] kgdbts:RUN singlestep [0/1000]
> [33235.954027] kgdbts:RUN singlestep [100/1000]
> [33240.429086] kgdbts:RUN singlestep [200/1000]
> [33244.687118] kgdbts:RUN singlestep [300/1000]
> [33248.945191] kgdbts:RUN singlestep [400/1000]
> [33253.203751] kgdbts:RUN singlestep [500/1000]
> [33257.462019] kgdbts:RUN singlestep [600/1000]
> [33261.817809] kgdbts:RUN singlestep [700/1000]
> [33266.081268] kgdbts:RUN singlestep [800/1000]
> [33270.339813] kgdbts:RUN singlestep [900/1000]
> [33274.712404] kgdbts:RUN do_fork for 1000 breakpoints
> ~ #
>
> This works for me. Should I patch it or will you send a patch for this?
>
> PS: cc to mailing list missed
>>
>> Will
^ permalink raw reply
* [PATCH RFC v4 10/10] ahci_imx: Port to library-ised ahci_platform
From: Hans de Goede @ 2014-01-22 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122065151.GC16215@pengutronix.de>
Hi,
On 01/22/2014 07:51 AM, Sascha Hauer wrote:
> Hi Hans,
>
> On Mon, Jan 20, 2014 at 05:45:03PM +0100, Hans de Goede wrote:
>> This avoids the ugliness of creating a nested platform device from probe.
>>
>> Note untested, I've ordered a wandboard to be able to test these changes.
>
> Looks much better now, thanks. I could test this patch aswell, no need
> to buy new hardware for this.
Thanks for the offer, but the wandboard arrived yesterday. Having a bit more
variety in the arm hardware I've to test with is good to have anyways.
Regards,
Hans
^ permalink raw reply
* [PATCH V2] ARM: imx: correct usecount of IPG, ARM and MMDC clk on i.mx6sl
From: Anson Huang @ 2014-01-22 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122064740.GB16215@pengutronix.de>
On Wed, Jan 22, 2014 at 07:47:40AM +0100, Sascha Hauer wrote:
> On Tue, Jan 21, 2014 at 06:50:52PM +0800, Anson Huang wrote:
> > IPG, ARM and MMDC's clock should be enabled during kernel boot up,
> > so we need to maintain their use count, otherwise, they may be
> > disabled unexpectedly if their children's clock are turned off,
> > which is not allowed.
> >
> > Signed-off-by: Anson Huang <b20788@freescale.com>
> > ---
> > arch/arm/mach-imx/clk-imx6sl.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
> > index 78f3bd6..047f4ff 100644
> > --- a/arch/arm/mach-imx/clk-imx6sl.c
> > +++ b/arch/arm/mach-imx/clk-imx6sl.c
> > @@ -291,6 +291,22 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
> > pr_warn("%s: failed to set AHB clock rate %d!\n",
> > __func__, ret);
> >
> > + /*
> > + * Make sure those always on clocks are enabled to maintain the correct
> > + * usecount and enabling/disabling of parent PLLs.
> > + */
> > + ret = clk_prepare_enable(clks[IMX6SL_CLK_IPG]);
> > + if (ret)
> > + pr_warn("%s: failed to enable IPG clock %d\n", __func__, ret);
> > +
> > + ret = clk_prepare_enable(clks[IMX6SL_CLK_ARM]);
> > + if (ret)
> > + pr_warn("%s: failed to enable ARM clock %d\n", __func__, ret);
> > +
> > + ret = clk_prepare_enable(clks[IMX6SL_CLK_MMDC_ROOT]);
> > + if (ret)
> > + pr_warn("%s: failed to enable MMDC clock %d\n", __func__, ret);
> > +
>
> Consider using a clk_init_on array like we have in clk-imx6q.c
>
> Sascha
>
Right, that can make code more clean, thanks for the comment, please help review V3 patch.
Anson.
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
>
^ permalink raw reply
* [PATCH V3] ARM: imx: add always-on clock array for i.mx6sl to maintain correct usecount
From: Anson Huang @ 2014-01-22 7:14 UTC (permalink / raw)
To: linux-arm-kernel
IPG, ARM and MMDC's clock should be enabled during kernel boot up,
so we need to maintain their usecount, otherwise, they may be
disabled unexpectedly if their children's clock are turned off, and
caused their parent PLLs also get disabled, which is incorrect.
Signed-off-by: Anson Huang <b20788@freescale.com>
---
arch/arm/mach-imx/clk-imx6sl.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
index 78f3bd6..04e9f1c 100644
--- a/arch/arm/mach-imx/clk-imx6sl.c
+++ b/arch/arm/mach-imx/clk-imx6sl.c
@@ -66,6 +66,10 @@ static struct clk_div_table video_div_table[] = {
static struct clk *clks[IMX6SL_CLK_END];
static struct clk_onecell_data clk_data;
+static const u32 clks_init_on[] __initconst = {
+ IMX6SL_CLK_IPG, IMX6SL_CLK_ARM, IMX6SL_CLK_MMDC_ROOT,
+};
+
/*
* ERR005311 CCM: After exit from WAIT mode, unwanted interrupt(s) taken
* during WAIT mode entry process could cause cache memory
@@ -291,6 +295,13 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
pr_warn("%s: failed to set AHB clock rate %d!\n",
__func__, ret);
+ /*
+ * Make sure those always on clocks are enabled to maintain the correct
+ * usecount and enabling/disabling of parent PLLs.
+ */
+ for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
+ clk_prepare_enable(clks[clks_init_on[i]]);
+
if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY1_GATE]);
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY2_GATE]);
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
From: Stephen Rothwell @ 2014-01-22 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
Hi Paul,
On Tue, 21 Jan 2014 16:22:03 -0500 Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
> Where: This work exists as a queue of patches that I apply to
> linux-next; since the changes are fixing some things that currently
> can only be found there. The patch series can be found at:
>
> http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git
> git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
>
> I've avoided annoying Stephen with another queue of patches for
> linux-next while the development content was in flux, but now that
> the merge window has opened, and new additions are fewer, perhaps he
> wouldn't mind tacking it on the end... Stephen?
OK, I have added this to the end of linux-next today - we will see how we
go. It is called "init".
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr at canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140122/4f1e8752/attachment.sig>
^ permalink raw reply
* [PATCH RFC v4 10/10] ahci_imx: Port to library-ised ahci_platform
From: Sascha Hauer @ 2014-01-22 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390236303-22538-11-git-send-email-hdegoede@redhat.com>
Hi Hans,
On Mon, Jan 20, 2014 at 05:45:03PM +0100, Hans de Goede wrote:
> This avoids the ugliness of creating a nested platform device from probe.
>
> Note untested, I've ordered a wandboard to be able to test these changes.
Looks much better now, thanks. I could test this patch aswell, no need
to buy new hardware for this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH V2] ARM: imx: correct usecount of IPG, ARM and MMDC clk on i.mx6sl
From: Sascha Hauer @ 2014-01-22 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301452-10143-1-git-send-email-b20788@freescale.com>
On Tue, Jan 21, 2014 at 06:50:52PM +0800, Anson Huang wrote:
> IPG, ARM and MMDC's clock should be enabled during kernel boot up,
> so we need to maintain their use count, otherwise, they may be
> disabled unexpectedly if their children's clock are turned off,
> which is not allowed.
>
> Signed-off-by: Anson Huang <b20788@freescale.com>
> ---
> arch/arm/mach-imx/clk-imx6sl.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
> index 78f3bd6..047f4ff 100644
> --- a/arch/arm/mach-imx/clk-imx6sl.c
> +++ b/arch/arm/mach-imx/clk-imx6sl.c
> @@ -291,6 +291,22 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
> pr_warn("%s: failed to set AHB clock rate %d!\n",
> __func__, ret);
>
> + /*
> + * Make sure those always on clocks are enabled to maintain the correct
> + * usecount and enabling/disabling of parent PLLs.
> + */
> + ret = clk_prepare_enable(clks[IMX6SL_CLK_IPG]);
> + if (ret)
> + pr_warn("%s: failed to enable IPG clock %d\n", __func__, ret);
> +
> + ret = clk_prepare_enable(clks[IMX6SL_CLK_ARM]);
> + if (ret)
> + pr_warn("%s: failed to enable ARM clock %d\n", __func__, ret);
> +
> + ret = clk_prepare_enable(clks[IMX6SL_CLK_MMDC_ROOT]);
> + if (ret)
> + pr_warn("%s: failed to enable MMDC clock %d\n", __func__, ret);
> +
Consider using a clk_init_on array like we have in clk-imx6q.c
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ 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