* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Laurent Pinchart @ 2014-07-21 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721154313.1de8bf6f@bbrezillon>
Hi Boris,
On Monday 21 July 2014 15:43:13 Boris BREZILLON wrote:
> On Mon, 21 Jul 2014 15:30:35 +0200 Thierry Reding wrote:
> > On Mon, Jul 21, 2014 at 03:22:05PM +0200, Laurent Pinchart wrote:
> >> On Monday 21 July 2014 14:55:23 Thierry Reding wrote:
> >>> On Mon, Jul 21, 2014 at 02:34:28PM +0200, Boris BREZILLON wrote:
> >>>> On Mon, 21 Jul 2014 14:16:42 +0200 Laurent Pinchart wrote:
> >>>>> On Monday 21 July 2014 14:12:47 Thierry Reding wrote:
> >>>>>> On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote:
> >>
> >> [snip]
> >>
> >>>>>>> The new drm_display_info structure should look like this [2]
> >>>>>>> (except that color_formats and bpc have not be removed yet), and
> >>>>>>> [1] is just here to show how the video_bus_format enum would look
> >>>>>>> like.
> >>>>>>>
> >>>>>>> [1] http://code.bulix.org/rfd0yx-86557
> >>>>>>> [2] http://code.bulix.org/7n03b4-86556
> >>>>>>
> >>>>>> Quoting from your paste:
> >>>>>> + const enum video_bus_format *bus_formats;
> >>>>>> + int nbus_formats;
> >>>>>>
> >>>>>> Do we really need more than one?
> >>>>>
> >>>>> We do if we want to replace the color_formats and bpc fields.
> >>>>
> >>>> Yes, that's what I was about to answer :-).
> >>>
> >>> Maybe we don't need to replace color_formats and bpc field
> >>> immediately. That could be done in a follow-up patch.
> >>
> >> We don't need to replace them right now, but we should at least agree on
> >> how to replace them. Introducing a new field that would need to be
> >> replaced in the near future when removing color_formats and bpc would
> >> be a waste of time.
> >
> > Sure. One of the problems I see with replacing color_formats and bpc
> > with the above is that some of the bits within color_formats are set
> > when the EDID is parsed. That implies that if they are replaced with
> > an array of formats, the array would need to be reallocated during EDID
> > parsing. That sounds like ugliness.
> >
> > But if you can find a nice way to make it work that'd be great.
>
> How about using a list instead of an array ?
> This way we can add elements to this list when parsing the EDID.
>
> Or we can just define a maximum size for the bus_formats array when
> retrieving this info from EDID. If I'm correct we have at most 18 bus
> formats:
> - 3 color formats:
> * RGB 4:4:4
> * YCbCr 4:4:4
> * YCbCr 4:4:2
> - 6 color depths: 6, 8, 10, 12, 14 and 16 bits per color
bpc isn't a bitmask, so EDID supports up to three formats only.
The color_formats field is computed in the drm_add_display_info() function.
You could easily turn it into a local variable and allocate and fill the
formats array at the end of the function.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Boris BREZILLON @ 2014-07-21 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721133034.GI15238@ulmo>
On Mon, 21 Jul 2014 15:30:35 +0200
Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Jul 21, 2014 at 03:22:05PM +0200, Laurent Pinchart wrote:
> > Hi Thierry,
> >
> > On Monday 21 July 2014 14:55:23 Thierry Reding wrote:
> > > On Mon, Jul 21, 2014 at 02:34:28PM +0200, Boris BREZILLON wrote:
> > > > On Mon, 21 Jul 2014 14:16:42 +0200 Laurent Pinchart wrote:
> > > >> On Monday 21 July 2014 14:12:47 Thierry Reding wrote:
> > > >>> On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote:
> >
> > [snip]
> >
> > > >>>> The new drm_display_info structure should look like this [2] (except
> > > >>>> that color_formats and bpc have not be removed yet), and [1] is just
> > > >>>> here to show how the video_bus_format enum would look like.
> > > >>>>
> > > >>>> [1] http://code.bulix.org/rfd0yx-86557
> > > >>>> [2] http://code.bulix.org/7n03b4-86556
> > > >>>
> > > >>> Quoting from your paste:
> > > >>> + const enum video_bus_format *bus_formats;
> > > >>> + int nbus_formats;
> > > >>>
> > > >>> Do we really need more than one?
> > > >>
> > > >> We do if we want to replace the color_formats and bpc fields.
> > > >
> > > > Yes, that's what I was about to answer :-).
> > >
> > > Maybe we don't need to replace color_formats and bpc field immediately.
> > > That could be done in a follow-up patch.
> >
> > We don't need to replace them right now, but we should at least agree on how
> > to replace them. Introducing a new field that would need to be replaced in the
> > near future when removing color_formats and bpc would be a waste of time.
>
> Sure. One of the problems I see with replacing color_formats and bpc
> with the above is that some of the bits within color_formats are set
> when the EDID is parsed. That implies that if they are replaced with
> an array of formats, the array would need to be reallocated during EDID
> parsing. That sounds like ugliness.
>
> But if you can find a nice way to make it work that'd be great.
How about using a list instead of an array ?
This way we can add elements to this list when parsing the EDID.
Or we can just define a maximum size for the bus_formats array when
retrieving this info from EDID. If I'm correct we have at most 18 bus
formats:
- 3 color formats:
* RGB 4:4:4
* YCbCr 4:4:4
* YCbCr 4:4:2
- 6 color depths: 6, 8, 10, 12, 14 and 16 bits per color
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] ARM: EXYNOS: Fix build with PM_SLEEP=n
From: Bartlomiej Zolnierkiewicz @ 2014-07-21 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <93736288.A8L2I1nMme@amdc1032>
On Monday, July 21, 2014 02:55:52 PM Bartlomiej Zolnierkiewicz wrote:
> On Monday, July 21, 2014 01:11:14 PM Bartlomiej Zolnierkiewicz wrote:
> > On Monday, July 21, 2014 12:38:28 PM Bartlomiej Zolnierkiewicz wrote:
> > >
> > > Hi,
> > >
> > > On Saturday, July 19, 2014 04:42:34 AM Kukjin Kim wrote:
> > > > On 07/16/14 20:59, Tomasz Figa wrote:
> > > > > Hi Krzysztof,
> > > > >
> > > > > On 14.07.2014 09:45, Krzysztof Kozlowski wrote:
> > > > >> Fix building of exynos defconfig with disabled PM_SLEEP:
> > > > >> CONFIG_PM_SLEEP=n
> > > > >> CONFIG_PM_SLEEP_SMP=n
> > > > >> CONFIG_SUSPEND=n
> > > > >> by moving functions for power up/down of CPU and cluster to platsmp.c
> > > > >>
> > > > >> The build error messages:
> > > > >> arch/arm/mach-exynos/built-in.o: In function `exynos_boot_secondary':
> > > > >> arch/arm/mach-exynos/platsmp.c:111: undefined reference to `exynos_cpu_power_state'
> > > > >> arch/arm/mach-exynos/platsmp.c:112: undefined reference to `exynos_cpu_power_up'
> > > > >> arch/arm/mach-exynos/platsmp.c:116: undefined reference to `exynos_cpu_power_state'
> > > > >> make: *** [vmlinux] Error 1
> > > > >>
> > > > >> Signed-off-by: Krzysztof Kozlowski<k.kozlowski@samsung.com>
> > > > >>
> > > > >> ---
> > > > >> Changes since v1:
> > > > >> 1. Use different solution - just move the power up/down functions to a
> > > > >> common place instead of adding stubs in common.h. Suggested by Tomasz
> > > > >> Figa.
> > > > >> ---
> > > > >> arch/arm/mach-exynos/platsmp.c | 66 ++++++++++++++++++++++++++++++++++++++++++
> > > > >> arch/arm/mach-exynos/pm.c | 66 ------------------------------------------
> > > > >> 2 files changed, 66 insertions(+), 66 deletions(-)
> > > > >>
> > > > >
> > > > + Bart,
> > > >
> > > > > Reviewed-by: Tomasz Figa<t.figa@samsung.com>
> > > > >
> > > > Applied, thanks.
> > > >
> > > > Bart, I think this is better at this moment to fix the build breakage
> > > > with disabling PM...if you have any comments, please let me know.
> > >
> > > To fix PM_SLEEP=n build itself (with ARM_EXYNOS_CPUIDLE=n) Krzysztof's
> > > patch is not enough and patch [1] is also needed (this patch is very
> > > simple so I think that it is okay for v3.16).
> >
> > Hmmm, I now see that you've applied Krzysztof's patch for v3.17 not v3.16.
> >
> > In that case how do you want to deal with PM_SLEEP=n build breakages for
> > v3.16 and what do you mean with "fix the build breakage with disabling PM"?
>
> Just a bit of explanation:
>
> The PM_SLEEP=n build breakages show up on automated build tests done by
> various people. Minimal fixes for them (Krzysztof's patch + patch [1] +
> making ARM_EXYNOS_CPUIDLE depend on PM_SLEEP temporally) are really obvious
> and should be pretty safe so it would be great to have them in v3.16.
>
> If that is not possible lets fix the issue completely early in v3.17 cycle.
Okay, so Krzysztof's patch was posted in pull request to Olof on Saturday
and merged already for v3.17. In that case I will just refresh my patches
and resubmit later. Sorry for all the noise.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics
> >
> > > For PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y config more changes are needed
> > > and they are contained in patch [2] (please note that this patch depends
> > > on patch [3] from Tomasz Figa which was redone recently into [4] so my
> > > patch also needs to be refreshed). However if you think that this would
> > > result in too much changes for v3.16 kernel we can make ARM_EXYNOS_CPUIDLE
> > > select (or depend on) PM_SLEEP for now and fix the issue completely later
> > > in v3.17 kernel.
> > >
> > > [1] "[PATCH 1/2] ARM: EXYNOS: Fix build with PM_SLEEP=n part #2"
> > > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34080.html
> > >
> > > [2] "[PATCH 2/2] ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y"
> > > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34081.html
> > >
> > > [3] "[PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies"
> > > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg32809.html
> > >
> > > [4] "[PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences"
> > > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34150.html
> > >
> > > Best regards,
> > > --
> > > Bartlomiej Zolnierkiewicz
> > > Samsung R&D Institute Poland
> > > Samsung Electronics
^ permalink raw reply
* [RFC] cpufreq: Add bindings for CPU clock sharing topology
From: Santosh Shilimkar @ 2014-07-21 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpok-C+JCebjJkZExx6EjBctoyJF7fV71Vjj7bi1TAdXrFQ@mail.gmail.com>
On Sunday 20 July 2014 08:07 AM, Viresh Kumar wrote:
> On 19 July 2014 20:54, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>> Sorry for jumping late
>
> No, you aren't late. Its just 2 days old thread :)
>
>> but one of the point I was raising as part of your
>> other series was to extend the CPU topology bindings to cover the voltage
>> domain information which is probably what is really needed to let the
>> CPUfreq extract the information. Not sure if it was already discussed.
>
> Not it wasn't.
>
>> After all the CPU clocks, cluster, clock-gating, power domains are pretty much
>> related. So instead of having new binding for CPUFreq, I was wondering whether
>> we can extend the CPU topology binding information to include missing information.
>> Scheduler work anyway needs that information.
>>
>> Ref: Documentation/devicetree/bindings/arm/topology.txt
>>
>> Does that make sense ?
>
> Yeah it does, but I am not sure what exactly the bindings should look then.
> So, the most basic step could be moving the new bindings to topology.txt
> and name clock-master to dvfs-master.
>
> What else?
>
> If its going to be much controversial then we *can* go for just dvfs bindings
> for now and then update them later.
>
Would be good to get others opinion. As you said if it is controversial then
it will stall the development.
Regards,
Santosh
^ permalink raw reply
* [PATCH 12/12] ARM: tegra: Convert PMC to a driver
From: Thierry Reding @ 2014-07-21 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721131619.GE12921@htj.dyndns.org>
On Mon, Jul 21, 2014 at 09:16:19AM -0400, Tejun Heo wrote:
> On Mon, Jul 21, 2014 at 03:12:34PM +0200, Thierry Reding wrote:
> > Adding Tejun, since he took this into his tree on Friday I think, just a
> > few hours after I sent out pull requests for this.
> >
> > I hadn't considered this build dependency. We could resolve this in two
> > ways I think:
> >
> > - merge the for-3.17/fuse-move branch from the Tegra tree into
> > the libata tree and apply Arnd's patch to the libata tree
>
> I can pull the tegra tree into the libata if the tegra maintainer is
> okay with it.
It's fine with me, but maybe give Stephen, Arnd and Olof an opportunity
to object.
If you plan to go ahead with merging it in, this would be the right
signed tag to use:
https://git.kernel.org/cgit/linux/kernel/git/tegra/linux.git/tag/?id=tegra-for-3.17-soc
And then you simply need to replace #include <linux/tegra-powergate.h>
with #include <soc/tegra/pmc.h> as Arnd showed.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/11965731/attachment.sig>
^ permalink raw reply
* [PATCH 3/6] tty: serial: 8250 core: add runtime pm
From: Mika Westerberg @ 2014-07-21 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404928177-26554-4-git-send-email-bigeasy@linutronix.de>
On Wed, Jul 09, 2014 at 07:49:34PM +0200, Sebastian Andrzej Siewior wrote:
> While comparing the OMAP-serial and the 8250 part of this I noticed that
> the the latter does not use runtime-pm. Here are the pieces. It is
> basically a get before first register access and a last_busy + put after
> last access.
> If I understand this correct, it should do nothing as long as
> pm_runtime_use_autosuspend() + pm_runtime_enable() isn't invoked on the
> device.
>
> Cc: mika.westerberg at linux.intel.com
Sorry for the delay, just came back from vacation.
Adding Heikki, who knows the 8250_dw driver much better than me.
Unfortunately he is still on vacation for next two weeks.
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> drivers/tty/serial/8250/8250_core.c | 101 +++++++++++++++++++++++++++++++-----
> 1 file changed, 88 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index d37eb08..1a91a89 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -38,6 +38,7 @@
> #include <linux/nmi.h>
> #include <linux/mutex.h>
> #include <linux/slab.h>
> +#include <linux/pm_runtime.h>
> #ifdef CONFIG_SPARC
> #include <linux/sunserialcore.h>
> #endif
> @@ -553,10 +554,11 @@ static void serial8250_set_sleep(struct uart_8250_port *p, int sleep)
> * offset but the UART channel may only write to the corresponding
> * bit.
> */
> + pm_runtime_get_sync(p->port.dev);
> if ((p->port.type == PORT_XR17V35X) ||
> (p->port.type == PORT_XR17D15X)) {
> serial_out(p, UART_EXAR_SLEEP, sleep ? 0xff : 0);
> - return;
> + goto out;
> }
>
> if (p->capabilities & UART_CAP_SLEEP) {
> @@ -571,7 +573,17 @@ static void serial8250_set_sleep(struct uart_8250_port *p, int sleep)
> serial_out(p, UART_EFR, 0);
> serial_out(p, UART_LCR, 0);
> }
> +
> + if (!device_may_wakeup(p->port.dev)) {
> + if (sleep)
> + pm_runtime_forbid(p->port.dev);
> + else
> + pm_runtime_allow(p->port.dev);
> + }
> }
> +out:
> + pm_runtime_mark_last_busy(p->port.dev);
> + pm_runtime_put_autosuspend(p->port.dev);
> }
>
> #ifdef CONFIG_SERIAL_8250_RSA
> @@ -1280,6 +1292,7 @@ static void serial8250_stop_tx(struct uart_port *port)
> struct uart_8250_port *up =
> container_of(port, struct uart_8250_port, port);
>
> + pm_runtime_get_sync(port->dev);
> __stop_tx(up);
>
> /*
> @@ -1289,6 +1302,8 @@ static void serial8250_stop_tx(struct uart_port *port)
> up->acr |= UART_ACR_TXDIS;
> serial_icr_write(up, UART_ACR, up->acr);
> }
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> }
>
> static void serial8250_start_tx(struct uart_port *port)
> @@ -1296,8 +1311,9 @@ static void serial8250_start_tx(struct uart_port *port)
> struct uart_8250_port *up =
> container_of(port, struct uart_8250_port, port);
>
> + pm_runtime_get_sync(port->dev);
> if (up->dma && !serial8250_tx_dma(up)) {
> - return;
> + goto out;
> } else if (!(up->ier & UART_IER_THRI)) {
> up->ier |= UART_IER_THRI;
> serial_port_out(port, UART_IER, up->ier);
> @@ -1318,6 +1334,9 @@ static void serial8250_start_tx(struct uart_port *port)
> up->acr &= ~UART_ACR_TXDIS;
> serial_icr_write(up, UART_ACR, up->acr);
> }
> +out:
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> }
>
> static void serial8250_stop_rx(struct uart_port *port)
> @@ -1325,9 +1344,14 @@ static void serial8250_stop_rx(struct uart_port *port)
> struct uart_8250_port *up =
> container_of(port, struct uart_8250_port, port);
>
> + pm_runtime_get_sync(port->dev);
> +
> up->ier &= ~UART_IER_RLSI;
> up->port.read_status_mask &= ~UART_LSR_DR;
> serial_port_out(port, UART_IER, up->ier);
> +
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> }
>
> static void serial8250_enable_ms(struct uart_port *port)
> @@ -1340,7 +1364,10 @@ static void serial8250_enable_ms(struct uart_port *port)
> return;
>
> up->ier |= UART_IER_MSI;
> + pm_runtime_get_sync(port->dev);
> serial_port_out(port, UART_IER, up->ier);
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> }
>
> /*
> @@ -1530,9 +1557,17 @@ EXPORT_SYMBOL_GPL(serial8250_handle_irq);
>
> static int serial8250_default_handle_irq(struct uart_port *port)
> {
> - unsigned int iir = serial_port_in(port, UART_IIR);
> + unsigned int iir;
> + int ret;
>
> - return serial8250_handle_irq(port, iir);
> + pm_runtime_get_sync(port->dev);
Is this function executed in interrupt context? Calling _sync() variant
might sleep here. At least if the RTPM of the device is backed by ACPI
methods.
> +
> + iir = serial_port_in(port, UART_IIR);
> + ret = serial8250_handle_irq(port, iir);
> +
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> + return ret;
> }
>
> /*
> @@ -1790,11 +1825,16 @@ static unsigned int serial8250_tx_empty(struct uart_port *port)
> unsigned long flags;
> unsigned int lsr;
>
> + pm_runtime_get_sync(port->dev);
> +
> spin_lock_irqsave(&port->lock, flags);
> lsr = serial_port_in(port, UART_LSR);
> up->lsr_saved_flags |= lsr & LSR_SAVE_FLAGS;
> spin_unlock_irqrestore(&port->lock, flags);
>
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> +
> return (lsr & BOTH_EMPTY) == BOTH_EMPTY ? TIOCSER_TEMT : 0;
> }
>
> @@ -1805,7 +1845,10 @@ static unsigned int serial8250_get_mctrl(struct uart_port *port)
> unsigned int status;
> unsigned int ret;
>
> + pm_runtime_get_sync(port->dev);
> status = serial8250_modem_status(up);
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
>
> ret = 0;
> if (status & UART_MSR_DCD)
> @@ -1838,7 +1881,10 @@ static void serial8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
>
> mcr = (mcr & up->mcr_mask) | up->mcr_force | up->mcr;
>
> + pm_runtime_get_sync(port->dev);
> serial_port_out(port, UART_MCR, mcr);
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> }
>
> static void serial8250_break_ctl(struct uart_port *port, int break_state)
> @@ -1847,6 +1893,7 @@ static void serial8250_break_ctl(struct uart_port *port, int break_state)
> container_of(port, struct uart_8250_port, port);
> unsigned long flags;
>
> + pm_runtime_get_sync(port->dev);
> spin_lock_irqsave(&port->lock, flags);
> if (break_state == -1)
> up->lcr |= UART_LCR_SBC;
> @@ -1854,6 +1901,8 @@ static void serial8250_break_ctl(struct uart_port *port, int break_state)
> up->lcr &= ~UART_LCR_SBC;
> serial_port_out(port, UART_LCR, up->lcr);
> spin_unlock_irqrestore(&port->lock, flags);
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> }
>
> /*
> @@ -1898,12 +1947,23 @@ static void wait_for_xmitr(struct uart_8250_port *up, int bits)
>
> static int serial8250_get_poll_char(struct uart_port *port)
> {
> - unsigned char lsr = serial_port_in(port, UART_LSR);
> + unsigned char lsr;
> + int status;
> +
> + pm_runtime_get_sync(port->dev);
>
> - if (!(lsr & UART_LSR_DR))
> - return NO_POLL_CHAR;
> + lsr = serial_port_in(port, UART_LSR);
>
> - return serial_port_in(port, UART_RX);
> + if (!(lsr & UART_LSR_DR)) {
> + status = NO_POLL_CHAR;
> + goto out;
> + }
> +
> + status = serial_port_in(port, UART_RX);
> +out:
> + pm_runtime_mark_last_busy(up->dev);
> + pm_runtime_put_autosuspend(up->dev);
> + return status;
> }
>
>
> @@ -1914,6 +1974,7 @@ static void serial8250_put_poll_char(struct uart_port *port,
> struct uart_8250_port *up =
> container_of(port, struct uart_8250_port, port);
>
> + pm_runtime_get_sync(up->dev);
> /*
> * First save the IER then disable the interrupts
> */
> @@ -1935,6 +1996,9 @@ static void serial8250_put_poll_char(struct uart_port *port,
> */
> wait_for_xmitr(up, BOTH_EMPTY);
> serial_port_out(port, UART_IER, ier);
> + pm_runtime_mark_last_busy(up->dev);
> + pm_runtime_put_autosuspend(up->dev);
> +
> }
>
> #endif /* CONFIG_CONSOLE_POLL */
> @@ -1961,6 +2025,7 @@ int serial8250_do_startup(struct uart_port *port)
> if (port->iotype != up->cur_iotype)
> set_io_from_upio(port);
>
> + pm_runtime_get_sync(port->dev);
> if (port->type == PORT_16C950) {
> /* Wake up and initialize UART */
> up->acr = 0;
> @@ -1981,7 +2046,6 @@ int serial8250_do_startup(struct uart_port *port)
> */
> enable_rsa(up);
> #endif
> -
> /*
> * Clear the FIFO buffers and disable them.
> * (they will be reenabled in set_termios())
> @@ -2005,7 +2069,8 @@ int serial8250_do_startup(struct uart_port *port)
> (serial_port_in(port, UART_LSR) == 0xff)) {
> printk_ratelimited(KERN_INFO "ttyS%d: LSR safety check engaged!\n",
> serial_index(port));
> - return -ENODEV;
> + retval = -ENODEV;
> + goto out;
> }
>
> /*
> @@ -2090,7 +2155,7 @@ int serial8250_do_startup(struct uart_port *port)
> } else {
> retval = serial_link_irq_chain(up);
> if (retval)
> - return retval;
> + goto out;
> }
>
> /*
> @@ -2188,8 +2253,11 @@ int serial8250_do_startup(struct uart_port *port)
> outb_p(0x80, icp);
> inb_p(icp);
> }
> -
> - return 0;
> + retval = 0;
> +out:
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> + return retval;
> }
> EXPORT_SYMBOL_GPL(serial8250_do_startup);
>
> @@ -2207,6 +2275,7 @@ void serial8250_do_shutdown(struct uart_port *port)
> container_of(port, struct uart_8250_port, port);
> unsigned long flags;
>
> + pm_runtime_get_sync(port->dev);
> /*
> * Disable interrupts from this port
> */
> @@ -2246,6 +2315,8 @@ void serial8250_do_shutdown(struct uart_port *port)
> * the IRQ chain.
> */
> serial_port_in(port, UART_RX);
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
>
> del_timer_sync(&up->timer);
> up->timer.function = serial8250_timeout;
> @@ -2365,6 +2436,7 @@ serial8250_do_set_termios(struct uart_port *port, struct ktermios *termios,
> * Ok, we're now changing the port state. Do it with
> * interrupts disabled.
> */
> + pm_runtime_get_sync(port->dev);
> spin_lock_irqsave(&port->lock, flags);
>
> /*
> @@ -2486,6 +2558,9 @@ serial8250_do_set_termios(struct uart_port *port, struct ktermios *termios,
> }
> serial8250_set_mctrl(port, port->mctrl);
> spin_unlock_irqrestore(&port->lock, flags);
> + pm_runtime_mark_last_busy(port->dev);
> + pm_runtime_put_autosuspend(port->dev);
> +
> /* Don't rewrite B0 */
> if (tty_termios_baud_rate(termios))
> tty_termios_encode_baud_rate(termios, baud, baud);
> --
> 2.0.1
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Thierry Reding @ 2014-07-21 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2273675.A51UonkrgF@avalon>
On Mon, Jul 21, 2014 at 03:26:12PM +0200, Laurent Pinchart wrote:
> Hi Thierry,
>
> On Monday 21 July 2014 14:56:26 Thierry Reding wrote:
> > On Mon, Jul 21, 2014 at 02:33:21PM +0200, Boris BREZILLON wrote:
> > > On Mon, 21 Jul 2014 14:15:16 +0200 Thierry Reding wrote:
> > >> On Fri, Jul 18, 2014 at 04:51:52PM +0200, Boris BREZILLON wrote:
> > >>> On Tue, 15 Jul 2014 12:31:37 +0200 Thierry Reding wrote:
> > >>>> On Tue, Jul 15, 2014 at 12:06:19PM +0200, Boris BREZILLON wrote:
> > >>>>> On Mon, 14 Jul 2014 12:05:43 +0200 Thierry Reding wrote:
> > >>>>>> On Mon, Jul 07, 2014 at 06:42:59PM +0200, Boris BREZILLON wrote:
>
> [snip]
>
> > >>>>>>> + - atmel,panel: Should contain a phandle with 2 parameters.
> > >>>>>>> + The first cell is a phandle to a DRM panel device
> > >>>>>>> + The second cell encodes the RGB mode, which can take the
> > >>>>>>> following values: + * 0: RGB444
> > >>>>>>> + * 1: RGB565
> > >>>>>>> + * 2: RGB666
> > >>>>>>> + * 3: RGB888
> > >>>>>>
> > >>>>>> These are properties of the panel and should be obtained from
> > >>>>>> the panel directly rather than an additional cell in this
> > >>>>>> specifier.
> > >>>>>
> > >>>>> Okay.
> > >>>>> What's the preferred way of doing this ?
> > >>>>> What about defining an rgb-mode property in the panel node.
>
> [snip]
>
> > >>>> Also, like Laurent said, this shouldn't go into the device tree,
> > >>>> since it's already implied by the panel's compatible value, so we'd
> > >>>> be duplicating information.
> > >>>
> > >>> Again, this is not necessarily true (depending on your board design).
> > >>> One can decide to connect an RGB888 panel on an RGB666 bus and connect
> > >>> the missing pins to ground.
> > >>
> > >> I think in that case the board design itself could be considered as an
> > >> RGB888 to RGB666 bridge, and I think that's what the device tree should
> > >> be describing rather than a panel with a variable number of input
> > >> formats.
> > >
> > > So, you're suggesting to add an RGB to RGB drm_bridge driver (and
> > > the appropriate DT bindings) to handle this case, right ?
> >
> > Yes, exactly.
>
> Wouldn't it be possible to implement RGB666 -> RGB888 support in a less
> complex way ? A standalone driver to describe signal routing seems like an
> overly complex solution to me. I would prefer making the routing a properly of
> the link instead of a separate device.
I don't think the above is overly complex. After all the panel expects
RGB888, so it makes no sense to make it "configurable" to anything else.
Similarly if the encoder or bridge provides RGB666 then that's a fixed
function, too. So to represent this combination accurately you'll need
some form of translation entity inbetween, and it may just as well be a
bridge than something custom for that particular link.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/59b85ab0/attachment.sig>
^ permalink raw reply
* [PATCH 07/16] i2c: i2c-mv64xxx: Drop class based scanning to improve bootup time
From: Andrew Lunn @ 2014-07-21 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404992799-3705-8-git-send-email-wsa@the-dreams.de>
On Thu, Jul 10, 2014 at 01:46:27PM +0200, Wolfram Sang wrote:
> This driver has been flagged to drop class based instantiation. The removal
> improves boot-up time and is unneeded for embedded controllers. Users have been
> warned to switch for some time now, so we can actually do the removal. Keep the
> DEPRECATED flag, so the core can inform users that the behaviour finally
> changed now. After another transition period, this flag can go, too.
Hi Wolfram
Acked-by: Andrew Lunn <andrew@lunn.ch>
As far as i know, none of the arm boards using this driver make use of
class based instantiation. The majority use DT now, the exception
being Orion5x. So you could jump straight to removing the flag if you
wanted.
Andrew
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> ---
> drivers/i2c/busses/i2c-mv64xxx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
> index 9f4b775e2e39..6dc5ded86f62 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -863,7 +863,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
> drv_data->adapter.dev.parent = &pd->dev;
> drv_data->adapter.algo = &mv64xxx_i2c_algo;
> drv_data->adapter.owner = THIS_MODULE;
> - drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD | I2C_CLASS_DEPRECATED;
> + drv_data->adapter.class = I2C_CLASS_DEPRECATED;
> drv_data->adapter.nr = pd->id;
> drv_data->adapter.dev.of_node = pd->dev.of_node;
> platform_set_drvdata(pd, drv_data);
> --
> 2.0.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Thierry Reding @ 2014-07-21 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2695740.osZpCPIB8S@avalon>
On Mon, Jul 21, 2014 at 03:22:05PM +0200, Laurent Pinchart wrote:
> Hi Thierry,
>
> On Monday 21 July 2014 14:55:23 Thierry Reding wrote:
> > On Mon, Jul 21, 2014 at 02:34:28PM +0200, Boris BREZILLON wrote:
> > > On Mon, 21 Jul 2014 14:16:42 +0200 Laurent Pinchart wrote:
> > >> On Monday 21 July 2014 14:12:47 Thierry Reding wrote:
> > >>> On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote:
>
> [snip]
>
> > >>>> The new drm_display_info structure should look like this [2] (except
> > >>>> that color_formats and bpc have not be removed yet), and [1] is just
> > >>>> here to show how the video_bus_format enum would look like.
> > >>>>
> > >>>> [1] http://code.bulix.org/rfd0yx-86557
> > >>>> [2] http://code.bulix.org/7n03b4-86556
> > >>>
> > >>> Quoting from your paste:
> > >>> + const enum video_bus_format *bus_formats;
> > >>> + int nbus_formats;
> > >>>
> > >>> Do we really need more than one?
> > >>
> > >> We do if we want to replace the color_formats and bpc fields.
> > >
> > > Yes, that's what I was about to answer :-).
> >
> > Maybe we don't need to replace color_formats and bpc field immediately.
> > That could be done in a follow-up patch.
>
> We don't need to replace them right now, but we should at least agree on how
> to replace them. Introducing a new field that would need to be replaced in the
> near future when removing color_formats and bpc would be a waste of time.
Sure. One of the problems I see with replacing color_formats and bpc
with the above is that some of the bits within color_formats are set
when the EDID is parsed. That implies that if they are replaced with
an array of formats, the array would need to be reallocated during EDID
parsing. That sounds like ugliness.
But if you can find a nice way to make it work that'd be great.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/46167207/attachment.sig>
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Laurent Pinchart @ 2014-07-21 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721125624.GF15238@ulmo>
Hi Thierry,
On Monday 21 July 2014 14:56:26 Thierry Reding wrote:
> On Mon, Jul 21, 2014 at 02:33:21PM +0200, Boris BREZILLON wrote:
> > On Mon, 21 Jul 2014 14:15:16 +0200 Thierry Reding wrote:
> >> On Fri, Jul 18, 2014 at 04:51:52PM +0200, Boris BREZILLON wrote:
> >>> On Tue, 15 Jul 2014 12:31:37 +0200 Thierry Reding wrote:
> >>>> On Tue, Jul 15, 2014 at 12:06:19PM +0200, Boris BREZILLON wrote:
> >>>>> On Mon, 14 Jul 2014 12:05:43 +0200 Thierry Reding wrote:
> >>>>>> On Mon, Jul 07, 2014 at 06:42:59PM +0200, Boris BREZILLON wrote:
[snip]
> >>>>>>> + - atmel,panel: Should contain a phandle with 2 parameters.
> >>>>>>> + The first cell is a phandle to a DRM panel device
> >>>>>>> + The second cell encodes the RGB mode, which can take the
> >>>>>>> following values: + * 0: RGB444
> >>>>>>> + * 1: RGB565
> >>>>>>> + * 2: RGB666
> >>>>>>> + * 3: RGB888
> >>>>>>
> >>>>>> These are properties of the panel and should be obtained from
> >>>>>> the panel directly rather than an additional cell in this
> >>>>>> specifier.
> >>>>>
> >>>>> Okay.
> >>>>> What's the preferred way of doing this ?
> >>>>> What about defining an rgb-mode property in the panel node.
[snip]
> >>>> Also, like Laurent said, this shouldn't go into the device tree,
> >>>> since it's already implied by the panel's compatible value, so we'd
> >>>> be duplicating information.
> >>>
> >>> Again, this is not necessarily true (depending on your board design).
> >>> One can decide to connect an RGB888 panel on an RGB666 bus and connect
> >>> the missing pins to ground.
> >>
> >> I think in that case the board design itself could be considered as an
> >> RGB888 to RGB666 bridge, and I think that's what the device tree should
> >> be describing rather than a panel with a variable number of input
> >> formats.
> >
> > So, you're suggesting to add an RGB to RGB drm_bridge driver (and
> > the appropriate DT bindings) to handle this case, right ?
>
> Yes, exactly.
Wouldn't it be possible to implement RGB666 -> RGB888 support in a less
complex way ? A standalone driver to describe signal routing seems like an
overly complex solution to me. I would prefer making the routing a properly of
the link instead of a separate device.
--
Regards,
Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/3e8f6277/attachment-0001.sig>
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Laurent Pinchart @ 2014-07-21 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721125522.GE15238@ulmo>
Hi Thierry,
On Monday 21 July 2014 14:55:23 Thierry Reding wrote:
> On Mon, Jul 21, 2014 at 02:34:28PM +0200, Boris BREZILLON wrote:
> > On Mon, 21 Jul 2014 14:16:42 +0200 Laurent Pinchart wrote:
> >> On Monday 21 July 2014 14:12:47 Thierry Reding wrote:
> >>> On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote:
[snip]
> >>>> The new drm_display_info structure should look like this [2] (except
> >>>> that color_formats and bpc have not be removed yet), and [1] is just
> >>>> here to show how the video_bus_format enum would look like.
> >>>>
> >>>> [1] http://code.bulix.org/rfd0yx-86557
> >>>> [2] http://code.bulix.org/7n03b4-86556
> >>>
> >>> Quoting from your paste:
> >>> + const enum video_bus_format *bus_formats;
> >>> + int nbus_formats;
> >>>
> >>> Do we really need more than one?
> >>
> >> We do if we want to replace the color_formats and bpc fields.
> >
> > Yes, that's what I was about to answer :-).
>
> Maybe we don't need to replace color_formats and bpc field immediately.
> That could be done in a follow-up patch.
We don't need to replace them right now, but we should at least agree on how
to replace them. Introducing a new field that would need to be replaced in the
near future when removing color_formats and bpc would be a waste of time.
--
Regards,
Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/72642444/attachment.sig>
^ permalink raw reply
* [PATCH 12/12] ARM: tegra: Convert PMC to a driver
From: Tejun Heo @ 2014-07-21 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721131233.GG15238@ulmo>
On Mon, Jul 21, 2014 at 03:12:34PM +0200, Thierry Reding wrote:
> Adding Tejun, since he took this into his tree on Friday I think, just a
> few hours after I sent out pull requests for this.
>
> I hadn't considered this build dependency. We could resolve this in two
> ways I think:
>
> - merge the for-3.17/fuse-move branch from the Tegra tree into
> the libata tree and apply Arnd's patch to the libata tree
I can pull the tegra tree into the libata if the tegra maintainer is
okay with it.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs
From: Thomas Abraham @ 2014-07-21 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10657588.befqTi5XsZ@amdc1032>
On Mon, Jul 21, 2014 at 6:40 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
>
> Hi,
>
> On Monday, July 21, 2014 01:43:53 PM Daniel Drake wrote:
>> On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz
>> <b.zolnierkie@samsung.com> wrote:
>> > Recent patch by Tomasz Figa ("irqchip: gic: Fix core ID calculation
>> > when topology is read from DT") fixed GIC driver to filter cluster ID
>> > from values returned by cpu_logical_map() for SoCs having registers
>> > mapped without per-CPU banking making it is possible to add CPU nodes
>> > for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also
>> > required by future changes adding initialization of cpuidle states in
>> > Exynos cpuidle driver through DT.
>>
>> This conflicts with work in the thread "cpufreq: use generic cpufreq
>> drivers for exynos platforms" which is already in its 7th iteration.
>> Perhaps best to work directly with Thomas to help him finish that series?
>
> Patch "[PATCH v7 4/6] ARM: dts: Exynos: add cpu nodes, opp and cpu clock
> configuration data" from Thomas needs another revision anyway since it lacks
> cluster ID in Exynos4210 CPU node. It also mixes addition of CPU nodes
> with cpufreq specific changes and IMHO addition of CPU nodes should be in
> separate patch to ease bisection if any later problems turn up. Therefore
> I think that it would be the best if Thomas would rebase his work on top of
> "irqchip: gic: Fix core ID calculation when topology is read from DT" patch
> and this one. Thomas, are you okay with this?
Hi Bartlomiej,
Yes, I am okay with this.
Regards,
Thomas.
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v10 5/7] arm: add basic support for Mediatek MT6589 boards
From: Daniel Lezcano @ 2014-07-21 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C96DC7.10203@linaro.org>
On 07/18/2014 08:56 PM, Daniel Lezcano wrote:
> On 07/18/2014 12:47 PM, Heiko St?bner wrote:
>> Hi Daniel,
>>
>> Am Freitag, 18. Juli 2014, 11:46:51 schrieb Daniel Lezcano:
>>> On 07/07/2014 05:13 PM, Matthias Brugger wrote:
>>>> This adds a generic devicetree board file and a dtsi for boards
>>>> based on MT6589 SoCs from Mediatek.
>>>>
>>>> Apart from the generic parts (gic, clocks) the only component
>>>> currently supported are the timers.
>>>>
>>>> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
>>>> --
>>>
>>> I will take this patchset through my tree but this patch touches an area
>>> I am not handling.
>>>
>>> Olof, Arnd, do you mind to ack this patch ?
>>
>> wouldn't it be easier to just take patches 1,2,3,4 through your tree
>> and let
>> patches 5,6,7 go through arm-soc?
>>
>> There is no compile-time dependency between the two parts, so they
>> will come
>> together nicely in linux-next and during the merge-window.
>>
>>
>> Also in [0] Olof wrote:
>>
>> ----------
>> Traditionally we usually take the DT changes through arm-soc, but as
>> long as we share the branch we might be ok. We tend to stick them in
>> different branches in our tree though, so rockchip will be a little
>> mis-sorted this release. Not a big deal, and we can deal with it.
>> -----------
>>
>> So I'd assume splitting the patchset this way might be a nice solution?
>>
>>
>> Heiko
>>
>>
>> [0] http://www.spinics.net/lists/arm-kernel/msg347053.html
>
> Indeed.
>
> Olof, Arnd ? Will you take the patches 5-6-7 ?
patches 1-4 applied to my tree.
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Daniel Lezcano @ 2014-07-21 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721143813.6028b6ed@free-electrons.com>
On 07/21/2014 02:38 PM, Thomas Petazzoni wrote:
> Dear Daniel Lezcano,
>
> On Mon, 21 Jul 2014 14:34:23 +0200, Daniel Lezcano wrote:
>
>> So there are three solutions:
>>
>> 1. Pass the flag through the platform data, I am not really in favor of
>> that as mentioned above
>
> That's what is already implemented.
Yes, that was the point :)
>> 2. Use the compatible string like the cpuidle-big-little.c driver, but
>> Arnd is not in favor of that
>>
>> 3. Register 3 platform drivers, in cpuidle-mvebu-v7.c, and let the
>> registering of the cpuidle's platform device to enable the right one
>
> I'm fine with doing (3). Daniel, Arnd, let me know if that's ok for
> you, and I'll respin the patch series accordingly.
Ok for me.
Thanks Thomas
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 12/12] ARM: tegra: Convert PMC to a driver
From: Thierry Reding @ 2014-07-21 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6373493.kzO00ziuYq@wuerfel>
On Mon, Jul 21, 2014 at 02:06:10PM +0200, Arnd Bergmann wrote:
> On Thursday 17 July 2014 13:06:53 Thierry Reding wrote:
> >
> > We could go all the way and make it include/soc/tegra/*.h for better
> > namespacing. I guess either way would be fine, really, since the number
> > of files in those directories should be small by definition, so we
> > should be able to do without the extra SoC directory, too. I have a
> > slight preference for a separate SoC directory, do you have any
> > objections?
>
> I'm fine with it either way. I just noticed that you have now
> moved the file, which resulted in a build error:
>
> ../drivers/ata/ahci_tegra.c:27:35: fatal error: linux/tegra-powergate.h: No such file or directory
> #include <linux/tegra-powergate.h>
> ^
> compilation terminated.
> make[4]: *** [drivers/ata/ahci_tegra.o] Error 1
>
> so somebody needs to pick up this patch:
>
> diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
> index d30bb21afd67..d7c6b1f550cd 100644
> --- a/drivers/ata/ahci_tegra.c
> +++ b/drivers/ata/ahci_tegra.c
> @@ -24,8 +24,8 @@
> #include <linux/module.h>
> #include <linux/of_device.h>
> #include <linux/platform_device.h>
> -#include <linux/tegra-powergate.h>
> #include <linux/regulator/consumer.h>
> +#include <soc/tegra/pmc.h>
> #include "ahci.h"
>
> #define SATA_CONFIGURATION_0 0x180
>
>
> I haven't checked which trees are affected of if you have already posted
> a patch to do this.
>
> Arnd
Adding Tejun, since he took this into his tree on Friday I think, just a
few hours after I sent out pull requests for this.
I hadn't considered this build dependency. We could resolve this in two
ways I think:
- merge the for-3.17/fuse-move branch from the Tegra tree into
the libata tree and apply Arnd's patch to the libata tree
- provide a dummy include/linux/tegra-powergate.h header that
includes soc/tegra/powergate.h
In the latter case the dummy could possibly be removed right after
v3.17-rc1 along with a patch to convert the AHCI driver to use the new
header file. Or we could keep the compatibility header until the v3.18
merge window. I have a slight preference for this, even though it's a
wee bit of churn.
The problem is that we can't simply apply the patch that Arnd provided
because it would break the standalone libata tree if somebody were to
build Tegra with the new driver enabled.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/90b6b262/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs
From: Bartlomiej Zolnierkiewicz @ 2014-07-21 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD8Lp46eB3cDqD+1YMnWOG-V8CG7fCG1s2KH7znL0OrHSazRcQ@mail.gmail.com>
Hi,
On Monday, July 21, 2014 01:43:53 PM Daniel Drake wrote:
> On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
> > Recent patch by Tomasz Figa ("irqchip: gic: Fix core ID calculation
> > when topology is read from DT") fixed GIC driver to filter cluster ID
> > from values returned by cpu_logical_map() for SoCs having registers
> > mapped without per-CPU banking making it is possible to add CPU nodes
> > for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also
> > required by future changes adding initialization of cpuidle states in
> > Exynos cpuidle driver through DT.
>
> This conflicts with work in the thread "cpufreq: use generic cpufreq
> drivers for exynos platforms" which is already in its 7th iteration.
> Perhaps best to work directly with Thomas to help him finish that series?
Patch "[PATCH v7 4/6] ARM: dts: Exynos: add cpu nodes, opp and cpu clock
configuration data" from Thomas needs another revision anyway since it lacks
cluster ID in Exynos4210 CPU node. It also mixes addition of CPU nodes
with cpufreq specific changes and IMHO addition of CPU nodes should be in
separate patch to ease bisection if any later problems turn up. Therefore
I think that it would be the best if Thomas would rebase his work on top of
"irqchip: gic: Fix core ID calculation when topology is read from DT" patch
and this one. Thomas, are you okay with this?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Thierry Reding @ 2014-07-21 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721143321.5bda6ea9@bbrezillon>
On Mon, Jul 21, 2014 at 02:33:21PM +0200, Boris BREZILLON wrote:
> On Mon, 21 Jul 2014 14:15:16 +0200
> Thierry Reding <thierry.reding@gmail.com> wrote:
>
> > On Fri, Jul 18, 2014 at 04:51:52PM +0200, Boris BREZILLON wrote:
> > > Hi Thierry,
> > >
> > > Oops, I missed this reply.
> > >
> > > On Tue, 15 Jul 2014 12:31:37 +0200
> > > Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > > On Tue, Jul 15, 2014 at 12:06:19PM +0200, Boris BREZILLON wrote:
> > > > > On Mon, 14 Jul 2014 12:05:43 +0200 Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > > On Mon, Jul 07, 2014 at 06:42:59PM +0200, Boris BREZILLON wrote:
> > > > [...]
> > > > > > > diff --git a/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
> > > > > > [...]
> > > > > > > +The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
> > > > > > > +See Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt for more details.
> > > > > >
> > > > > > I think it's better to refer to these using relative filenames. When the
> > > > > > device tree bindings are moved out of the kernel tree, they may no
> > > > > > longer use the same hierarchy.
> > > > >
> > > > > Sure.
> > > > > By relative path you mean ../../mfd/atmel-hlcdc.txt or just
> > > > > mfd/atmel-hlcdc.txt ?
> > > >
> > > > I think the former is more explicit.
> > >
> > > Okay.
> > >
> > > >
> > > > > > > + - atmel,panel: Should contain a phandle with 2 parameters.
> > > > > > > + The first cell is a phandle to a DRM panel device
> > > > > > > + The second cell encodes the RGB mode, which can take the following values:
> > > > > > > + * 0: RGB444
> > > > > > > + * 1: RGB565
> > > > > > > + * 2: RGB666
> > > > > > > + * 3: RGB888
> > > > > >
> > > > > > These are properties of the panel and should be obtained from the panel
> > > > > > directly rather than an additional cell in this specifier.
> > > > >
> > > > > Okay.
> > > > > What's the preferred way of doing this ?
> > > > > What about defining an rgb-mode property in the panel node.
> > > >
> > > > There's .bpc in struct drm_display_info, I suspect that it could be used
> > > > for this. Alternatively, maybe we could extend the list of color formats
> > > > that go into drm_display_info.color_formats? RGB444 is already covered.
> > >
> > > I don't think this color_formats field is intended to represent data
> > > stream format going through the bus.
> > > Moreover, AFAIU, RGB444 in this definition represent RGB 4:4:4 (chroma
> > > subsampling rate) and not 12 bits signals (4 bits for each color).
> > >
> > > Anyway I'll propose a patch series adding a new field to
> > > drm_display_info to encode the mediabus format (as discussed with
> > > Laurent and you).
> > >
> > > >
> > > > Also, like Laurent said, this shouldn't go into the device tree, since
> > > > it's already implied by the panel's compatible value, so we'd be
> > > > duplicating information.
> > >
> > > Again, this is not necessarily true (depending on your board design).
> > > One can decide to connect an RGB888 panel on an RGB666 bus and connect
> > > the missing pins to ground.
> >
> > I think in that case the board design itself could be considered as an
> > RGB888 to RGB666 bridge, and I think that's what the device tree should
> > be describing rather than a panel with a variable number of input
> > formats.
>
> So, you're suggesting to add an RGB to RGB drm_bridge driver (and
> the appropriate DT bindings) to handle this case, right ?
Yes, exactly.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/1f75eb5f/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: EXYNOS: Fix build with PM_SLEEP=n
From: Bartlomiej Zolnierkiewicz @ 2014-07-21 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1539661.ni665pgzAx@amdc1032>
On Monday, July 21, 2014 01:11:14 PM Bartlomiej Zolnierkiewicz wrote:
> On Monday, July 21, 2014 12:38:28 PM Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Saturday, July 19, 2014 04:42:34 AM Kukjin Kim wrote:
> > > On 07/16/14 20:59, Tomasz Figa wrote:
> > > > Hi Krzysztof,
> > > >
> > > > On 14.07.2014 09:45, Krzysztof Kozlowski wrote:
> > > >> Fix building of exynos defconfig with disabled PM_SLEEP:
> > > >> CONFIG_PM_SLEEP=n
> > > >> CONFIG_PM_SLEEP_SMP=n
> > > >> CONFIG_SUSPEND=n
> > > >> by moving functions for power up/down of CPU and cluster to platsmp.c
> > > >>
> > > >> The build error messages:
> > > >> arch/arm/mach-exynos/built-in.o: In function `exynos_boot_secondary':
> > > >> arch/arm/mach-exynos/platsmp.c:111: undefined reference to `exynos_cpu_power_state'
> > > >> arch/arm/mach-exynos/platsmp.c:112: undefined reference to `exynos_cpu_power_up'
> > > >> arch/arm/mach-exynos/platsmp.c:116: undefined reference to `exynos_cpu_power_state'
> > > >> make: *** [vmlinux] Error 1
> > > >>
> > > >> Signed-off-by: Krzysztof Kozlowski<k.kozlowski@samsung.com>
> > > >>
> > > >> ---
> > > >> Changes since v1:
> > > >> 1. Use different solution - just move the power up/down functions to a
> > > >> common place instead of adding stubs in common.h. Suggested by Tomasz
> > > >> Figa.
> > > >> ---
> > > >> arch/arm/mach-exynos/platsmp.c | 66 ++++++++++++++++++++++++++++++++++++++++++
> > > >> arch/arm/mach-exynos/pm.c | 66 ------------------------------------------
> > > >> 2 files changed, 66 insertions(+), 66 deletions(-)
> > > >>
> > > >
> > > + Bart,
> > >
> > > > Reviewed-by: Tomasz Figa<t.figa@samsung.com>
> > > >
> > > Applied, thanks.
> > >
> > > Bart, I think this is better at this moment to fix the build breakage
> > > with disabling PM...if you have any comments, please let me know.
> >
> > To fix PM_SLEEP=n build itself (with ARM_EXYNOS_CPUIDLE=n) Krzysztof's
> > patch is not enough and patch [1] is also needed (this patch is very
> > simple so I think that it is okay for v3.16).
>
> Hmmm, I now see that you've applied Krzysztof's patch for v3.17 not v3.16.
>
> In that case how do you want to deal with PM_SLEEP=n build breakages for
> v3.16 and what do you mean with "fix the build breakage with disabling PM"?
Just a bit of explanation:
The PM_SLEEP=n build breakages show up on automated build tests done by
various people. Minimal fixes for them (Krzysztof's patch + patch [1] +
making ARM_EXYNOS_CPUIDLE depend on PM_SLEEP temporally) are really obvious
and should be pretty safe so it would be great to have them in v3.16.
If that is not possible lets fix the issue completely early in v3.17 cycle.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
> > For PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y config more changes are needed
> > and they are contained in patch [2] (please note that this patch depends
> > on patch [3] from Tomasz Figa which was redone recently into [4] so my
> > patch also needs to be refreshed). However if you think that this would
> > result in too much changes for v3.16 kernel we can make ARM_EXYNOS_CPUIDLE
> > select (or depend on) PM_SLEEP for now and fix the issue completely later
> > in v3.17 kernel.
> >
> > [1] "[PATCH 1/2] ARM: EXYNOS: Fix build with PM_SLEEP=n part #2"
> > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34080.html
> >
> > [2] "[PATCH 2/2] ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y"
> > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34081.html
> >
> > [3] "[PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies"
> > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg32809.html
> >
> > [4] "[PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences"
> > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34150.html
> >
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Thierry Reding @ 2014-07-21 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721143428.078b68a4@bbrezillon>
On Mon, Jul 21, 2014 at 02:34:28PM +0200, Boris BREZILLON wrote:
> On Mon, 21 Jul 2014 14:16:42 +0200
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>
> > Hi Thierry,
> >
> > On Monday 21 July 2014 14:12:47 Thierry Reding wrote:
> > > On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote:
> > > > On Mon, 21 Jul 2014 11:32:55 +0200 Laurent Pinchart wrote:
> > > >> On Monday 21 July 2014 11:24:38 Boris BREZILLON wrote:
> > > >>> On Mon, 21 Jul 2014 10:59:12 +0200 Thierry Reding wrote:
> > > >>>> On Fri, Jul 18, 2014 at 05:43:34PM +0200, Boris BREZILLON wrote:
> > > >>>> [...]
> > > >>>>
> > > >>>>>>>>>> + - atmel,panel: Should contain a phandle with 2 parameters.
> > > >>>>>>>>>> + The first cell is a phandle to a DRM panel device
> > > >>>>>>>>>> + The second cell encodes the RGB mode, which can take the
> > > >>>>>>>>>> following values:
> > > >>>>>>>>>> + * 0: RGB444
> > > >>>>>>>>>> + * 1: RGB565
> > > >>>>>>>>>> + * 2: RGB666
> > > >>>>>>>>>> + * 3: RGB888
> > > >>>>>>>>>
> > > >>>>>>>>> These are properties of the panel and should be obtained from
> > > >>>>>>>>> the panel directly rather than an additional cell in this
> > > >>>>>>>>> specifier.
> > > >>>>>>>>
> > > >>>>>>>> Okay.
> > > >>>>>>>> What's the preferred way of doing this ?
> > > >>>>>>>> What about defining an rgb-mode property in the panel node.
> > > >>>>>>>
> > > >>>>>>> There's .bpc in struct drm_display_info, I suspect that it could
> > > >>>>>>> be used for this. Alternatively, maybe we could extend the list
> > > >>>>>>> of color formats that go into drm_display_info.color_formats?
> > > >>>>>>> RGB444 is already covered.
> > > >>>>>
> > > >>>>> I forgot to ask about bpc meaning. If, as I think, it means "bits
> > > >>>>> per color" then it cannot be used to encode RGB565 where green
> > > >>>>> color is encoded on 6 bits and red and blue are encoded on 5 bits.
> > > >>>>
> > > >>>> Yes, I agree that bps is not a good fit for what you need here.
> > > >>>
> > > >>> Okay, then I think we can replace bpc and color_formats by a
> > > >>> bus_formats table containing all supported formats, and use an enum
> > > >>> (something similar to v4l2_mbus_pixelcode defined in v4l2-mediabus.h
> > > >>> [1]) to list the available formats.
> > > >>>
> > > >>> As this implies quite a few changes in crtc core and some drm drivers
> > > >>> (nouveau, i915 and radeon), I'd like to be sure this is what both of
> > > >>> you had in mind.
> > > >>
> > > >> I think it is, but just to make sure I understand you correctly, could
> > > >> you just show how the drm_display_info structure would look like ?
> > > >
> > > > The new drm_display_info structure should look like this [2] (except
> > > > that color_formats and bpc have not be removed yet), and [1] is just
> > > > here to show how the video_bus_format enum would look like.
> > > >
> > > > [1] http://code.bulix.org/rfd0yx-86557
> > > > [2] http://code.bulix.org/7n03b4-86556
> > >
> > > Quoting from your paste:
> > >
> > > + const enum video_bus_format *bus_formats;
> > > + int nbus_formats;
> > >
> > > Do we really need more than one?
> >
> > We do if we want to replace the color_formats and bpc fields.
> >
>
> Yes, that's what I was about to answer :-).
Maybe we don't need to replace color_formats and bpc field immediately.
That could be done in a follow-up patch.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/a5e6d501/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 1/2] clk: samsung: exynos4: Enable ARMCLK down feature
From: Daniel Drake @ 2014-07-21 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405694193-29643-1-git-send-email-k.kozlowski@samsung.com>
On Fri, Jul 18, 2014 at 3:36 PM, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> Enable ARMCLK down feature on all Exynos4 SoCs. The frequency of
> ARMCLK will be reduced upon entering idle mode (WFI or WFE).
>
> The feature behaves like very fast cpufreq ondemand governor. In idle
> mode this reduces energy consumption on full frequency chosen by
> cpufreq governor by approximately:
> - Trats2: 6.5% (153 mA -> 143 mA)
> - Trats: 33.0% (180 mA -> 120 mA)
> - Gear1: 27.0% (180 mA -> 130 mA)
>
> The patch uses simillar settings as Exynos5250 (clk-exynos5250.c),
> except it disables clock up feature and on Exynos4412 ARMCLK down is
> enabled for all 4 cores.
>
> Tested on Trats board (Exynos4210), Trats2 board (Exynos4412) and
> Samsung Gear 1 (Exynos4212).
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Tested on ODROID-U2, seems to be working. I don't have a way of
measuring the power usage, but the system seems as stable as before.
Tested-by: Daniel Drake <drake@endlessm.com>
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Arnd Bergmann @ 2014-07-21 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721143813.6028b6ed@free-electrons.com>
On Monday 21 July 2014 14:38:13 Thomas Petazzoni wrote:
> Dear Daniel Lezcano,
>
> On Mon, 21 Jul 2014 14:34:23 +0200, Daniel Lezcano wrote:
>
> > So there are three solutions:
> >
> > 1. Pass the flag through the platform data, I am not really in favor of
> > that as mentioned above
>
> That's what is already implemented.
It's certainly better than checking a global compatible string in
driver code, IMHO.
Instead of a global header file, I would have put the structure
definition under linux/platform-data, as we do for most other
legacy drivers.
> > 2. Use the compatible string like the cpuidle-big-little.c driver, but
> > Arnd is not in favor of that
> >
> > 3. Register 3 platform drivers, in cpuidle-mvebu-v7.c, and let the
> > registering of the cpuidle's platform device to enable the right one
>
> I'm fine with doing (3). Daniel, Arnd, let me know if that's ok for
> you, and I'll respin the patch series accordingly.
If I understood Daniel correctly, this is temporary anyway until
we have a proper binding, right?
If so, I don't really mind either approach.
Arnd
^ permalink raw reply
* [PATCH v5 0/7] kernel: Add support for restart handler call chain
From: Guenter Roeck @ 2014-07-21 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721123056.GF12817@arm.com>
Hi Catalin,
On 07/21/2014 05:30 AM, Catalin Marinas wrote:
> On Fri, Jul 18, 2014 at 08:34:09AM +0100, Guenter Roeck wrote:
>> Patch 1 of this series implements the restart handler function. Patches 2 and 3
>> implement calling the restart handler chain from arm and arm64 restart code.
>>
>> Patch 4 modifies the restart-poweroff driver to no longer call arm_pm_restart
>> directly but machine_restart. This is done to avoid calling arm_pm_restart
>> from more than one place. The change makes the driver architecture independent,
>> so it would be possible to drop the arm dependency from its Kconfig entry.
>>
>> Patch 5 and 6 convert existing restart handlers in the watchdog subsystem
>> to use the restart handler. Patch 7 unexports arm_pm_restart to ensure
>> that no one gets the idea to implement a restart handler as module.
>
> For the current patches:
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>
> Do you plan to convert more of the power/drivers/reset/ code?
>
Once this series has been accepted, I at least wanted to give it a try.
> BTW, is it worth doing something similar for pm_power_off (there is
> generic code calling it directly, so slightly more complicated than
> pm_restart)?
I have not thought about it yet.
A quick glance suggests it is much more widely used than the reset handler.
It looks like the original idea, like with machine_restart, was to have
one function per architecture, but it seems that is widely abused.
Looks pretty messy to me. Maybe after this one is done, if there is interest
and, more importantly, the need to do something about it.
Thanks,
Guenter
^ permalink raw reply
* [PATCH v8 00/13] Add Maxim 77802 PMIC support
From: Javier Martinez Canillas @ 2014-07-21 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405337769-3741-1-git-send-email-javier.martinez@collabora.co.uk>
Hello Lee,
On 07/14/2014 01:35 PM, Javier Martinez Canillas wrote:
>
> * Patches 1-7 from v7 are not included since those were improvements to
> the max77686 mfd driver and can be applied independently. Lee Jones said
> that he is going to pick them from the posted v7 series.
>
Thanks a lot for picking the max77686 preparatory patches.
>
> Since there are cross-subsystems dependencies, I think that the best way to
> sort this out is if relevant maintainers ack the patches so 01/13 to 012/13
> can be merged through the mfd tree. The patches and the relevant acks are:
>
> Patch 03/13 (regulator - Mark Brown)
> Patches 04/13 to 09/13 (clk - Mike Turquette)
> Patches 10/13 to 12/13 (rtc - Alessandro Zummo)
>
Mark, Mike and Alessandro,
This is a gentle reminder to look at the patches that touches your subsystems
and provide acks if possible so Lee can merge the remainder set through the mfd
tree.
There were only trivial changes for the regulator, clock and rtc drivers since
v5 (posted almost a month ago in Jun 26) and this series is blocking a lot of
other patch-sets so is hurting forward progress on the chromebook2 platform as a
whole.
Lee,
Since I may not be able to get the acks before the merge window opens, do you
think that is possible to merge patch 01/13 "mfd: max77686: Add Maxim 77802 PMIC
support" which already has your ack?
So at least we can get the dependency for the other drivers in 3.17 and avoid
this cross subsystem churn for 3.18 since the rest of the drivers will be able
to go through the relevant trees.
Thanks a lot and best regards,
Javier
^ permalink raw reply
* [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs
From: Daniel Drake @ 2014-07-21 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1863399.9O2S91ZvEO@amdc1032>
On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> Recent patch by Tomasz Figa ("irqchip: gic: Fix core ID calculation
> when topology is read from DT") fixed GIC driver to filter cluster ID
> from values returned by cpu_logical_map() for SoCs having registers
> mapped without per-CPU banking making it is possible to add CPU nodes
> for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also
> required by future changes adding initialization of cpuidle states in
> Exynos cpuidle driver through DT.
This conflicts with work in the thread "cpufreq: use generic cpufreq
drivers for exynos platforms" which is already in its 7th iteration.
Perhaps best to work directly with Thomas to help him finish that series?
Daniel
^ 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