* [RESEND PATCH 0/6] thermal: sti: Add new Thermal driver
From: Lee Jones @ 2014-07-21 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405935299.2455.3.camel@rzhang1-toshiba>
On Mon, 21 Jul 2014, Zhang Rui wrote:
> On Mon, 2014-07-21 at 10:17 +0100, Lee Jones wrote:
> > On Mon, 14 Jul 2014, Lee Jones wrote:
> >
> > > On Mon, 14 Jul 2014, Zhang Rui wrote:
> > >
> > > > On Mon, 2014-07-14 at 14:08 +0100, Lee Jones wrote:
> > > > > On Wed, 09 Jul 2014, Lee Jones wrote:
> > > > > > On Wed, 09 Jul 2014, Zhang Rui wrote:
> > > > > > > On Wed, 2014-07-09 at 13:08 +0100, Lee Jones wrote:
> > > > > > > > On Tue, 24 Jun 2014, Lee Jones wrote:
> > > > > > > >
> > > > > > > > > > I'm re-sending this set, as one of the maintainers' email addresses
> > > > > > > > > > is incorrect in the MAINTAINERS file.
> > > > > > > > > >
> > > > > > > > > > This patchset adds full support for 2 types of Thermal Controllers
> > > > > > > > > > produced by STMicroelectronics. One is a more traditional memory
> > > > > > > > > > mapped variant, the other is controlled solely by system configuration
> > > > > > > > > > registers.
> > > > > > > > >
> > > > > > > > > Any thing from the Thermal guys? Has this set fallen through the gaps?
> > > > > > > >
> > > > > > > > Anything at all? It's been well over a month now.
> > > > > > > >
> > > > > > > Well, for the soc thermal drivers, I'd prefer to take them via Eduardo,
> > > > > > > but as we didn't get any feedback from Eduardo, I will take them.
> > > > > >
> > > > > > Thanks Rui.
> > > > > >
> > > > > > So have you taken all 4 "thermal: sti: *" patches?
> > > > >
> > > > > Have you taken these yet?
> > > >
> > > > Not yet. will do tomorrow.
> >
> > I waited 7 days and still don't see them?
> >
> Done, they're in my local tree and I forgot to push them.
> thanks for the reminder.
Thanks dude.
> > > Perfect, thanks for the update.
> > >
> > > > > I notice that these aren't in -next yet.
> >
>
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 1/3] cpuidle: exynos: Allow to use the driver without AFTR
From: Krzysztof Kozlowski @ 2014-07-21 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CCE31C.90300@linaro.org>
On pon, 2014-07-21 at 11:53 +0200, Daniel Lezcano wrote:
> On 07/21/2014 10:36 AM, Krzysztof Kozlowski wrote:
> > Allow the driver to be used when AFTR enter function is not provided
> > (device platform data is NULL).
> >
> > This actually does not give any special energy-saving benefits but
> > allows to track the idle time of each core. Additionally it is a safe
> > way to validate supplied platform data.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>
> I think we already talk about this in the mailing list several times.
> It does not make sense to enable the cpuidle driver for WFI just for the
> sake of tracking via sysfs some idle timings.
>
> Using the cpuidle driver means using the underlying cpuidle
> infrastructure with all the stats computation in the governor.
>
> If there is a *real* need of a WFI cpuidle driver, then a generic WFI
> cpuidle driver could be implemented to supersede this one.
>
> It took a while to cleanup this driver and remove all the hacks around
> this AFTR state... :)
Sure, I understand.
Best regards,
Krzysztof
>
> > ---
> > drivers/cpuidle/cpuidle-exynos.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/cpuidle/cpuidle-exynos.c b/drivers/cpuidle/cpuidle-exynos.c
> > index 7c0151263828..5325a394be7e 100644
> > --- a/drivers/cpuidle/cpuidle-exynos.c
> > +++ b/drivers/cpuidle/cpuidle-exynos.c
> > @@ -77,7 +77,10 @@ static int exynos_cpuidle_probe(struct platform_device *pdev)
> > {
> > int ret;
> >
> > + /* If NULL enter only WFI */
> > exynos_enter_aftr = (void *)(pdev->dev.platform_data);
> > + if (!exynos_enter_aftr)
> > + exynos_idle_driver.state_count = 1;
> >
> > ret = cpuidle_register(&exynos_idle_driver, NULL);
> > if (ret) {
> >
>
>
^ permalink raw reply
* [PATCH 2/2] iio: exynos-adc: add experimental touchscreen support
From: Arnd Bergmann @ 2014-07-21 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CC368E.9060506@gmx.de>
On Sunday 20 July 2014 23:37:18 Hartmut Knaack wrote:
> Jonathan Cameron schrieb:
> > On 18/07/14 20:29, Arnd Bergmann wrote:
> >> - I simply register the input device from the adc driver
> >> itself, as the at91 code does. The driver also supports
> >> sub-nodes, but I don't understand how they are meant
> >> to be used, so using those might be better.
> > So, the alternative you are (I think) referring to is to use
> > the buffered in kernel client interface. That way a separate
> > touch screen driver can use the output channels provided by IIO
> > in much the same way you might use a regulator or similar.
> > Note that whilst this is similar to the simple polled interface
> > used for things like the iio_hwmon driver, the data flow is
> > quite different (clearly the polled interfce would be
> > inappropriate here).
> >
> > Whilst we've discussed it in the past for touch screen drivers
> > like this, usually the hardware isn't generic enough to be
> > of any real use if not being used as a touch screen. As such
> > it's often simpler to just have the support directly in the
> > driver (as you've observed the at91 driver does this).
Ok, I see. That's exactly the information I was looking for.
> >
> > Whilst the interface has been there a while, it's not really had
> > all that much use. The original target was the simpler case
> > of 3D accelerometer where we have a generic iio to input
> > bridge driver. Time constraints meant that I haven't yet actually
> > formally submitted the input side of this. Whilst there are lots
> > of other things that can use this interface, right now nothing
> > actually does so.
Ok.
> >> - The new exynos_read_s3c64xx_ts() function is intentionally
> >> very similar to the existing exynos_read_raw() functions.
> >> It should probably be changed, either by merging the two
> >> into one, or by simplifying the exynos_read_s3c64xx_ts()
> >> function. This depends a bit on the answers to the questions
> >> above.
> > I'd be tempted to not bother keeping them that similar. It's
> > not a generic IIO channel so simplify it where possible.
Ok.
> >> index 5f95638513d2..cf1d9f3e2492 100644
> >> --- a/drivers/iio/adc/exynos_adc.c
> >> +++ b/drivers/iio/adc/exynos_adc.c
> >> @@ -34,6 +34,7 @@
> >> #include <linux/regulator/consumer.h>
> >> #include <linux/of_platform.h>
> >> #include <linux/err.h>
> >> +#include <linux/input.h>
> > Might want to make the input side optional at compile time...
> > I supose the existing parts are unlikely to be used much in headless
> > devices, but you never know. Maybe we just leave this until someone
> > shouts they want to be able to avoid compiling it in.
I expected the input stuff to just be left out by the compiler
if CONFIG_INPUT is not set. I'll try it out and change it if necessary.
> >> struct completion completion;
> >>
> >> + bool read_ts;
> >> u32 value;
> >> + u32 value2;
> > As I state further down, I'd rather keep a little
> > clear of the naming used in IIO for bits that aren't
> > going through IIO (less confusing!). Maybe just
> > have
> > u32 x, y;
Ok.
> >> unsigned int version;
> >> };
> >>
> >> @@ -390,12 +396,61 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> >> return ret;
> >> }
> >>
> >> +static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
> >> + struct iio_chan_spec const *chan,
> >> + int *val,
> >> + int *val2,
> >> + long mask)
> >> +{
> >> + struct exynos_adc *info = iio_priv(indio_dev);
> >> + unsigned long timeout;
> >> + int ret;
> >> +
> >> + if (mask != IIO_CHAN_INFO_RAW)
> >> + return -EINVAL;
> >> +
> >> + mutex_lock(&indio_dev->mlock);
> >> + info->read_ts = 1;
> Since info->read_ts is of type bool, use true/false.
Ok
> >> +
> >> + reinit_completion(&info->completion);
> >> +
> >> + writel(ADC_S3C2410_TSC_PULL_UP_DISABLE | ADC_TSC_AUTOPST,
> >> + ADC_V1_TSC(info->regs));
> >> +
> >> + /* Select the ts channel to be used and Trigger conversion */
> >> + info->data->start_conv(info, 0);
> > 0 is a rather magic value. A define perhaps?
I'm not entirely sure about why we pass 0 here, it's either channel zero
being used for touchscreen, or the channel number being ignore after
we write to the TSC register above. I copied it from the original driver,
but it might be helpful if someone with access to the specs could comment
here.
I'll add a macro for now.
> >> +
> >> + timeout = wait_for_completion_timeout
> >> + (&info->completion, EXYNOS_ADC_TIMEOUT);
> >> + if (timeout == 0) {
> >> + dev_warn(&indio_dev->dev, "Conversion timed out! Resetting\n");
> >> + if (info->data->init_hw)
> >> + info->data->init_hw(info);
> >> + ret = -ETIMEDOUT;
> >> + } else {
> >> + *val = info->value;
> >> + *val2 = info->value2;
> > This is definitely abuse as those two values are not intended for
> > different values. If you want to do this please use different naming
> > and don't try to fiddle it into the IIO read raw framework.
> > As you've suggested above, better to simplify this code and drop the
> > bits cloned from the other handler.
Ok, adding ts_x and ts_y members.
> >> + ret = IIO_VAL_INT;
> >> + }
> >> +
> >> + info->read_ts = 0;
> >> + mutex_unlock(&indio_dev->mlock);
> >> +
> >> + return ret;
> >> +}
> >> +
> >> static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
> >> {
> >> struct exynos_adc *info = (struct exynos_adc *)dev_id;
> >>
> >> /* Read value */
> >> - info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
> >> + if (info->read_ts) {
> >> + info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
> >> + info->value2 = readl(ADC_V1_DATY(info->regs)) & ADC_DATX_MASK;
> > ADC_DATY_MASK would be more obviously correct.
Agreed. I thought about it, but then kept it as it was in the original
driver. Will change now.
> >> + writel(ADC_TSC_WAIT4INT | ADC_S3C2443_TSC_UD_SEN, ADC_V1_TSC(info->regs));
> > Perhaps the above is cryptic enough to warrant a comment?
This is also taken directly from the old driver, I have no idea what
it really does...
> >> + /* data from s3c2410_ts driver */
> >> + info->input->name = "S3C24xx TouchScreen";
> >> + info->input->id.bustype = BUS_HOST;
> >> + info->input->id.vendor = 0xDEAD;
> >> + info->input->id.product = 0xBEEF;
> >> + info->input->id.version = 0x0200;
> >> +
> >> + ret = input_register_device(info->input);
> >> + if (ret) {
> >> + input_free_device(info->input);
> >> + goto err;
> Just return ret, without goto (and get rid of label err).
ok
> >> + }
> >> +
> >> + if (info->tsirq > 0)
> >> + ret = request_threaded_irq(info->irq, NULL, exynos_ts_isr,
> >> + 0, "touchscreen", info);
> > info->tsirq
> > (that had me really confused for a moment ;)
> > Also, perhaps a more specific name. touchscreen_updown or similar as the
> > main interrupt is also used during touchscreen operation.
> >> + if (ret < 0) {
> >> + dev_err(info->dev, "failed requesting touchsccreen irq, irq = %d\n",
> >> + info->irq);
> >> + goto err_input;
> >> + }
> >> +
> >> + return 0;
> >> +
> Probably better to get rid of the labels and move the code up, as it is only used once.
Ok. I try not to mix goto and early return, so I've removed all the labels
here.
> >> static int exynos_adc_probe(struct platform_device *pdev)
> >> {
> >> struct exynos_adc *info = NULL;
> >> struct device_node *np = pdev->dev.of_node;
> >> struct iio_dev *indio_dev = NULL;
> >> struct resource *mem;
> >> + bool has_ts;
> >> int ret = -ENODEV;
> >> int irq;
> >>
> >> @@ -498,8 +638,14 @@ static int exynos_adc_probe(struct platform_device *pdev)
> >> dev_err(&pdev->dev, "no irq resource?\n");
> >> return irq;
> >> }
> >> -
> >> info->irq = irq;
> >> +
> >> + irq = platform_get_irq(pdev, 1);
> >> + if (irq == -EPROBE_DEFER)
> >> + return irq;
> What about other possible error codes?
We handle them later, in the request_threaded_irq call. In particular,
if the touchscreen is not used because either the "has-touchscreen" flag
is not set or because the input layer is not available, failing to get
the irq line should not be treated as an error.
Checking -EPROBE_DEFER however makes sense, so we get out of the probe function
early and don't have to undo and later retry everything.
Thanks everybody for the review!
Arnd
^ permalink raw reply
* [alsa-devel] [PATCH 2/4] ASoC: s3c64xx/smartq: use dynamic registration
From: Mark Brown @ 2014-07-21 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKQuvTH=5U8chZeMNLjCkfo78+_r2Gx5WUfy+q3F4QZpQ@mail.gmail.com>
On Mon, Jul 21, 2014 at 12:36:43PM +0900, Alexandre Courbot wrote:
> On Thu, Jul 17, 2014 at 8:05 PM, Mark Brown <broonie@kernel.org> wrote:
> > For set and get, sure - but it's still useful to be able to do bulk
> > requests for GPIOs especially since that's the only bit of the interface
> > that requires error handling.
> I foresee many problems if people start using gpiod_array_get() as a
> way to spare a few lines of error-checking code. First all the GPIOs
> would end into an array instead of members with meaningful names -
> unless they are moved later on, but doing so would add extra code and
> somewhat kill the purpose. It also becomes more difficult to maintain
> as you are dealing with array indexes to update all over the code.
You just need a few defines for the names, it's not a big deal.
> Finally, it will make it more difficult to use gpiod_array_*() the way
> it is intended to be used, as you would have to discriminate between
> GPIOs of the same function and the rest by yourself.
Yes, you probably shouldn't mix and match here but that's fine.
> Also, if such a convenience function is legitimate for GPIO, shouldn't
> it also apply to other sub-systems? E.g. regulator_array_get()?
It's certainly a totally reasonable and expected way of using
regulator_bulk_get().
> Maybe I am missing your point, but I still think some error-handling
> code really doesn't hurt here, and the few drivers that would actually
> benefit from a more automated GPIO request error handling can easily
> implement it themselves. Let's keep gpiod_array_*() single-purposed
> and to the point.
I'm not sure I see the massive complication TBH - it's not so much about
complexity as it is about reducing the amount of boilerplate that people
need to get right.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/ce403552/attachment.sig>
^ permalink raw reply
* [PATCH resend v2] arm64: dmi: Add SMBIOS/DMI support
From: Catalin Marinas @ 2014-07-21 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405079210-30044-1-git-send-email-ard.biesheuvel@linaro.org>
Ard,
I have some technical questions below before merging this patch.
On Fri, Jul 11, 2014 at 12:46:50PM +0100, Ard Biesheuvel wrote:
> --- /dev/null
> +++ b/arch/arm64/include/asm/dmi.h
> @@ -0,0 +1,41 @@
[...]
> +static inline void __iomem *dmi_remap(u64 phys, u64 size)
> +{
> + void __iomem *p = efi_lookup_mapped_addr(phys);
When are dmi_remap/dmi_early_remap() called? A quick grep through the
kernel shows that it is at least called once from dmi_scan_machine().
The latter is a device_initcall() in this patch. However, the comments
for efi_lookup_mapped_addr() state that it should only be called between
efi_enter_virtual_mode and efi_free_boot_services. The latter is invoked
from an early_initcall(). Could you please clarify which part is wrong
here?
> +
> + /*
> + * If the mapping spans multiple pages, do a minimal check to ensure
> + * that the mapping returned by efi_lookup_mapped_addr() covers the
> + * whole requested range (but ignore potential holes)
> + */
> + if ((phys & ~PAGE_MASK) + size > PAGE_SIZE
> + && (p + size - 1) != efi_lookup_mapped_addr(phys + size - 1))
> + return NULL;
> + return p;
> +}
> +
> +/* Reuse existing UEFI mappings for DMI */
> +#define dmi_alloc(l) kzalloc(l, GFP_KERNEL)
> +#define dmi_early_remap(x, l) dmi_remap(x, l)
> +#define dmi_early_unmap(x, l)
> +#define dmi_unmap(x)
Same questions as above, when are these functions called? Can we not
just use early_ioremap/ioremap like x86?
--
Catalin
^ permalink raw reply
* [PATCHv2 11/17] cpuidle: mvebu: rename the driver from armada-370-xp to mvebu-v7
From: Daniel Lezcano @ 2014-07-21 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404913221-17343-12-git-send-email-thomas.petazzoni@free-electrons.com>
On 07/09/2014 03:40 PM, Thomas Petazzoni wrote:
> From: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> This driver will be able to manage the cpuidle for more SoCs than just
> Armada 370 and XP. It will also support Armada 38x and potentially
> other SoC of the Marvell Armada EBU family. To take this into account,
> this patch renames the driver and its symbols.
>
> Note that in order to be bisectable, this commit needs to change both
> the cpuidle driver itself, and the place where the corresponding
> platform_device is registered.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> arch/arm/mach-mvebu/pmsu.c | 2 +-
> drivers/cpuidle/Kconfig.arm | 12 +++----
> drivers/cpuidle/Makefile | 2 +-
> ...{cpuidle-armada-370-xp.c => cpuidle-mvebu-v7.c} | 40 +++++++++++-----------
> 4 files changed, 28 insertions(+), 28 deletions(-)
> rename drivers/cpuidle/{cpuidle-armada-370-xp.c => cpuidle-mvebu-v7.c} (58%)
>
> diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
> index 15e67bf..802edc8 100644
> --- a/arch/arm/mach-mvebu/pmsu.c
> +++ b/arch/arm/mach-mvebu/pmsu.c
> @@ -76,7 +76,7 @@ extern void armada_370_xp_cpu_resume(void);
> static void *mvebu_cpu_resume;
>
> static struct platform_device mvebu_v7_cpuidle_device = {
> - .name = "cpuidle-armada-370-xp",
> + .name = "cpuidle-mvebu-v7",
> };
>
> static struct of_device_id of_pmsu_table[] = {
> diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
> index b6d69e8..a563427 100644
> --- a/drivers/cpuidle/Kconfig.arm
> +++ b/drivers/cpuidle/Kconfig.arm
> @@ -1,12 +1,6 @@
> #
> # ARM CPU Idle drivers
> #
> -config ARM_ARMADA_370_XP_CPUIDLE
> - bool "CPU Idle Driver for Armada 370/XP family processors"
> - depends on ARCH_MVEBU
> - help
> - Select this to enable cpuidle on Armada 370/XP processors.
> -
> config ARM_BIG_LITTLE_CPUIDLE
> bool "Support for ARM big.LITTLE processors"
> depends on ARCH_VEXPRESS_TC2_PM
> @@ -61,3 +55,9 @@ config ARM_EXYNOS_CPUIDLE
> depends on ARCH_EXYNOS
> help
> Select this to enable cpuidle for Exynos processors
> +
> +config ARM_MVEBU_V7_CPUIDLE
> + bool "CPU Idle Driver for mvebu v7 family processors"
> + depends on ARCH_MVEBU
> + help
> + Select this to enable cpuidle on Armada 370, 38x and XP processors.
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index d8bb1ff..11edb31 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -7,7 +7,7 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
>
> ##################################################################################
> # ARM SoC drivers
> -obj-$(CONFIG_ARM_ARMADA_370_XP_CPUIDLE) += cpuidle-armada-370-xp.o
> +obj-$(CONFIG_ARM_MVEBU_V7_CPUIDLE) += cpuidle-mvebu-v7.o
> obj-$(CONFIG_ARM_BIG_LITTLE_CPUIDLE) += cpuidle-big_little.o
> obj-$(CONFIG_ARM_CLPS711X_CPUIDLE) += cpuidle-clps711x.o
> obj-$(CONFIG_ARM_HIGHBANK_CPUIDLE) += cpuidle-calxeda.o
> diff --git a/drivers/cpuidle/cpuidle-armada-370-xp.c b/drivers/cpuidle/cpuidle-mvebu-v7.c
> similarity index 58%
> rename from drivers/cpuidle/cpuidle-armada-370-xp.c
> rename to drivers/cpuidle/cpuidle-mvebu-v7.c
> index 28587d0..302596e 100644
> --- a/drivers/cpuidle/cpuidle-armada-370-xp.c
> +++ b/drivers/cpuidle/cpuidle-mvebu-v7.c
> @@ -21,12 +21,12 @@
> #include <linux/platform_device.h>
> #include <asm/cpuidle.h>
>
> -#define ARMADA_370_XP_MAX_STATES 3
> -#define ARMADA_370_XP_FLAG_DEEP_IDLE 0x10000
> +#define MVEBU_V7_MAX_STATES 3
> +#define MVEBU_V7_FLAG_DEEP_IDLE 0x10000
>
> -static int (*armada_370_xp_cpu_suspend)(int);
> +static int (*mvebu_v7_cpu_suspend)(int);
>
> -static int armada_370_xp_enter_idle(struct cpuidle_device *dev,
> +static int mvebu_v7_enter_idle(struct cpuidle_device *dev,
> struct cpuidle_driver *drv,
> int index)
> {
> @@ -34,10 +34,10 @@ static int armada_370_xp_enter_idle(struct cpuidle_device *dev,
> bool deepidle = false;
> cpu_pm_enter();
>
> - if (drv->states[index].flags & ARMADA_370_XP_FLAG_DEEP_IDLE)
> + if (drv->states[index].flags & MVEBU_V7_FLAG_DEEP_IDLE)
> deepidle = true;
>
> - ret = armada_370_xp_cpu_suspend(deepidle);
> + ret = mvebu_v7_cpu_suspend(deepidle);
> if (ret)
> return ret;
>
> @@ -46,11 +46,11 @@ static int armada_370_xp_enter_idle(struct cpuidle_device *dev,
> return index;
> }
>
> -static struct cpuidle_driver armada_370_xp_idle_driver = {
> - .name = "armada_370_xp_idle",
> +static struct cpuidle_driver mvebu_v7_idle_driver = {
> + .name = "mvebu_v7_idle",
> .states[0] = ARM_CPUIDLE_WFI_STATE,
> .states[1] = {
> - .enter = armada_370_xp_enter_idle,
> + .enter = mvebu_v7_enter_idle,
> .exit_latency = 10,
> .power_usage = 50,
> .target_residency = 100,
> @@ -59,35 +59,35 @@ static struct cpuidle_driver armada_370_xp_idle_driver = {
> .desc = "CPU power down",
> },
> .states[2] = {
> - .enter = armada_370_xp_enter_idle,
> + .enter = mvebu_v7_enter_idle,
> .exit_latency = 100,
> .power_usage = 5,
> .target_residency = 1000,
> .flags = CPUIDLE_FLAG_TIME_VALID |
> - ARMADA_370_XP_FLAG_DEEP_IDLE,
> + MVEBU_V7_FLAG_DEEP_IDLE,
> .name = "MV CPU DEEP IDLE",
> .desc = "CPU and L2 Fabric power down",
> },
> - .state_count = ARMADA_370_XP_MAX_STATES,
> + .state_count = MVEBU_V7_MAX_STATES,
> };
>
> -static int armada_370_xp_cpuidle_probe(struct platform_device *pdev)
> +static int mvebu_v7_cpuidle_probe(struct platform_device *pdev)
> {
>
> - armada_370_xp_cpu_suspend = (void *)(pdev->dev.platform_data);
> - return cpuidle_register(&armada_370_xp_idle_driver, NULL);
> + mvebu_v7_cpu_suspend = (void *)(pdev->dev.platform_data);
> + return cpuidle_register(&mvebu_v7_idle_driver, NULL);
> }
>
> -static struct platform_driver armada_370_xp_cpuidle_plat_driver = {
> +static struct platform_driver mvebu_v7_cpuidle_plat_driver = {
> .driver = {
> - .name = "cpuidle-armada-370-xp",
> + .name = "cpuidle-mvebu-v7",
> .owner = THIS_MODULE,
> },
> - .probe = armada_370_xp_cpuidle_probe,
> + .probe = mvebu_v7_cpuidle_probe,
> };
>
> -module_platform_driver(armada_370_xp_cpuidle_plat_driver);
> +module_platform_driver(mvebu_v7_cpuidle_plat_driver);
>
> MODULE_AUTHOR("Gregory CLEMENT <gregory.clement@free-electrons.com>");
> -MODULE_DESCRIPTION("Armada 370/XP cpu idle driver");
> +MODULE_DESCRIPTION("Marvel EBU v7 cpuidle driver");
> MODULE_LICENSE("GPL");
>
--
<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
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Boris BREZILLON @ 2014-07-21 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1486972.oIqOcvGYCb@avalon>
On Mon, 21 Jul 2014 11:32:55 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Hi Boris,
>
> 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
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/3] cpuidle: exynos: Allow to use the driver without AFTR
From: Daniel Lezcano @ 2014-07-21 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405931771-24100-1-git-send-email-k.kozlowski@samsung.com>
On 07/21/2014 10:36 AM, Krzysztof Kozlowski wrote:
> Allow the driver to be used when AFTR enter function is not provided
> (device platform data is NULL).
>
> This actually does not give any special energy-saving benefits but
> allows to track the idle time of each core. Additionally it is a safe
> way to validate supplied platform data.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
I think we already talk about this in the mailing list several times.
It does not make sense to enable the cpuidle driver for WFI just for the
sake of tracking via sysfs some idle timings.
Using the cpuidle driver means using the underlying cpuidle
infrastructure with all the stats computation in the governor.
If there is a *real* need of a WFI cpuidle driver, then a generic WFI
cpuidle driver could be implemented to supersede this one.
It took a while to cleanup this driver and remove all the hacks around
this AFTR state... :)
> ---
> drivers/cpuidle/cpuidle-exynos.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/cpuidle/cpuidle-exynos.c b/drivers/cpuidle/cpuidle-exynos.c
> index 7c0151263828..5325a394be7e 100644
> --- a/drivers/cpuidle/cpuidle-exynos.c
> +++ b/drivers/cpuidle/cpuidle-exynos.c
> @@ -77,7 +77,10 @@ static int exynos_cpuidle_probe(struct platform_device *pdev)
> {
> int ret;
>
> + /* If NULL enter only WFI */
> exynos_enter_aftr = (void *)(pdev->dev.platform_data);
> + if (!exynos_enter_aftr)
> + exynos_idle_driver.state_count = 1;
>
> ret = cpuidle_register(&exynos_idle_driver, NULL);
> if (ret) {
>
--
<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 6/6] ARM: multi_v7_defconfig: Configure in ST's Thermal Controller
From: Maxime Coquelin @ 2014-07-21 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1401980819-19962-7-git-send-email-lee.jones@linaro.org>
On 06/05/2014 05:06 PM, Lee Jones wrote:
> Signed-off-by: Ajit Pal Singh <ajitpal.singh@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/configs/multi_v7_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
Added to my queue for v3.17.
Thanks,
Maxime
^ permalink raw reply
* [PATCH v4 09/10] ARM: update multi_v7_defconfig for STI
From: Maxime Coquelin @ 2014-07-21 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404918461-25390-10-git-send-email-peter.griffin@linaro.org>
On 07/09/2014 05:07 PM, Peter Griffin wrote:
> This patch enables SDHCI STI platform driver.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
Added to my queue for v3.17.
Thanks,
Maxime
^ permalink raw reply
* [STLinux Kernel] [RESEND PATCH] ARM: multi_v7_defconfig: add ST Keyscan driver
From: Maxime Coquelin @ 2014-07-21 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1403876061-8519-1-git-send-email-gabriel.fernandez@linaro.org>
On 06/27/2014 03:34 PM, Gabriel FERNANDEZ wrote:
> This patch adds KEYBOARD_ST_KEYSCAN config
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
Added to my queue for v3.17.
Thanks,
Maxime
^ permalink raw reply
* [PATCH 2/3] ARM: smp_scu: enable SCU standby support
From: Will Deacon @ 2014-07-21 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721092703.GL8537@dragon>
On Mon, Jul 21, 2014 at 10:27:04AM +0100, Shawn Guo wrote:
> On Mon, Jul 21, 2014 at 09:51:50AM +0100, Will Deacon wrote:
> > On Mon, Jul 21, 2014 at 08:45:54AM +0100, Shawn Guo wrote:
> > > With SCU standby enabled, SCU CLK will be turned off when all processors
> > > are in WFI mode. And the clock will be turned on when any processor
> > > leaves WFI mode.
> > >
> > > This behavior should be preferable in terms of power efficiency of
> > > system idle. So let's set the SCU standby bit to enable the support in
> > > function scu_enable().
> > >
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > ---
> > > arch/arm/kernel/smp_scu.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> > > index c947508f84e6..9f29d167d02c 100644
> > > --- a/arch/arm/kernel/smp_scu.c
> > > +++ b/arch/arm/kernel/smp_scu.c
> > > @@ -18,6 +18,7 @@
> > >
> > > #define SCU_CTRL 0x00
> > > #define SCU_ENABLE (1 << 0)
> > > +#define SCU_STANDBY_ENABLE (1 << 5)
> > > #define SCU_CONFIG 0x04
> > > #define SCU_CPU_STATUS 0x08
> > > #define SCU_INVALIDATE 0x0c
> > > @@ -54,7 +55,7 @@ void scu_enable(void __iomem *scu_base)
> > > if (scu_ctrl & SCU_ENABLE)
> > > return;
> > >
> > > - scu_ctrl |= SCU_ENABLE;
> > > + scu_ctrl |= SCU_ENABLE | SCU_STANDBY_ENABLE;
> >
> > I don't think this bit exists on all revisions of the A9.
>
> Thanks for the info, Will. Is there any side-effect to write the
> standby bit on those revisions which do not define the bit?
I'm not actually sure what happens at the hardware level, but the TRM is
pretty clear in its definition of `RESERVED':
`All reserved bits not used by the implementation must be written as 0 and
read as 0.'
Will
^ permalink raw reply
* [PATCH 2/2] drivers/tty/serial: use correct type for dma_map/unmap
From: Wolfram Sang @ 2014-07-21 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405935725-10457-1-git-send-email-wsa@the-dreams.de>
dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/tty/serial/atmel_serial.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index c4f750314100..7b63677475c1 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -706,7 +706,7 @@ static void atmel_release_tx_dma(struct uart_port *port)
dmaengine_terminate_all(chan);
dma_release_channel(chan);
dma_unmap_sg(port->dev, &atmel_port->sg_tx, 1,
- DMA_MEM_TO_DEV);
+ DMA_TO_DEVICE);
}
atmel_port->desc_tx = NULL;
@@ -804,7 +804,7 @@ static int atmel_prepare_tx_dma(struct uart_port *port)
nent = dma_map_sg(port->dev,
&atmel_port->sg_tx,
1,
- DMA_MEM_TO_DEV);
+ DMA_TO_DEVICE);
if (!nent) {
dev_dbg(port->dev, "need to release resource of dma\n");
@@ -883,7 +883,7 @@ static void atmel_release_rx_dma(struct uart_port *port)
dmaengine_terminate_all(chan);
dma_release_channel(chan);
dma_unmap_sg(port->dev, &atmel_port->sg_rx, 1,
- DMA_DEV_TO_MEM);
+ DMA_FROM_DEVICE);
}
atmel_port->desc_rx = NULL;
@@ -968,7 +968,7 @@ static int atmel_prepare_rx_dma(struct uart_port *port)
nent = dma_map_sg(port->dev,
&atmel_port->sg_rx,
1,
- DMA_DEV_TO_MEM);
+ DMA_FROM_DEVICE);
if (!nent) {
dev_dbg(port->dev, "need to release resource of dma\n");
--
2.0.0
^ permalink raw reply related
* [PATCH 1/2] drivers/i2c/busses: use correct type for dma_map/unmap
From: Wolfram Sang @ 2014-07-21 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405935725-10457-1-git-send-email-wsa@the-dreams.de>
dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/i2c/busses/i2c-at91.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index e95f9ba96790..83c989382be9 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -210,7 +210,7 @@ static void at91_twi_write_data_dma_callback(void *data)
struct at91_twi_dev *dev = (struct at91_twi_dev *)data;
dma_unmap_single(dev->dev, sg_dma_address(&dev->dma.sg),
- dev->buf_len, DMA_MEM_TO_DEV);
+ dev->buf_len, DMA_TO_DEVICE);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_STOP);
}
@@ -289,7 +289,7 @@ static void at91_twi_read_data_dma_callback(void *data)
struct at91_twi_dev *dev = (struct at91_twi_dev *)data;
dma_unmap_single(dev->dev, sg_dma_address(&dev->dma.sg),
- dev->buf_len, DMA_DEV_TO_MEM);
+ dev->buf_len, DMA_FROM_DEVICE);
/* The last two bytes have to be read without using dma */
dev->buf += dev->buf_len - 2;
--
2.0.0
^ permalink raw reply related
* [PATCH 0/2] use correct type for dma_map/unmap
From: Wolfram Sang @ 2014-07-21 9:42 UTC (permalink / raw)
To: linux-arm-kernel
I recently stumbled over the fact that the Atmel I2C driver used a wrong enum
for mapping dma, so I wrote a hackish coccinelle script to check the rest of the
kernel. Luckily, only those two were found.
Wolfram Sang (2):
drivers/i2c/busses: use correct type for dma_map/unmap
drivers/tty/serial: use correct type for dma_map/unmap
drivers/i2c/busses/i2c-at91.c | 4 ++--
drivers/tty/serial/atmel_serial.c | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
--
2.0.0
^ permalink raw reply
* [PATCH v3 00/13] Add support for Hisilicon SMMU architecture
From: Will Deacon @ 2014-07-21 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CC7234.4080703@huawei.com>
[re-adding the lists]
On Mon, Jul 21, 2014 at 02:51:48AM +0100, leizhen wrote:
> Hi, Will
Hello,
> I have sent this patch a week ago. I saw that you and Mitchel Humpherys had
> sent some patches which will impact my code. I list below:
> iommu/arm-smmu: remove support for chained SMMUs
> iommu/arm-smmu: fix some checkpatch issues
There's also all of the development work I'm doing for VFIO and the page-table
rework that Varun's working on, so these patches are going to be difficult
to merge if we ever get to that point. I think Mitchel and Olav are also
busy trying to get their SMMU supported by the driver. Given that they've
actually bothered to follow the architecture, I don't see why they should
be messed about by your patches causing conflicts all over the place.
> I can ajust my patch because of above. I known this patch is not follow what
> you suggested before(fit into arm-smmu.c). But I found when we need to support
> ARM SMMUv3, maybe we should do like this. I really want to know whether or not
> you agree the software framework in this patch? Or what do you think about
> SMMUv3?
The only code I foresee sharing between SMMUv2 and SMMUv3 is the page-table
creation code. The two architectures are significantly different, so I don't
think your split really helps us there. For example, you've left the probing
code in smmu-base.c. Of course, if HiSilicon follow the SMMUv3 spec as well
they did with SMMUv2, then your point is moot anyway and we may as well go
home.
> > I tried to merge hisi-smmu driver into arm-smmu.c, but it looks impossible.
> > The biggest problem is that too many registers are diffrent: the base address,
> > the field definition, or present only on one side. And if I use #if, hisi-smmu
> > and arm-smmu can not coexist in one binary file. Almost need 20 #if.
I don't think #ifdefs are necessarily the right way to go. There are IMPDEF
parts of a compliant SMMU (e.g. power management), so having a new compatible
string and a set of internal ops which can be overridden by a particular
implementation wouldn't be the end of the world and would be far less
invasive.
The problem you have is that your SMMU isn't architecturally compliant, so
you'll end up having to restructure parts of the driver so you can add
internal hooks for operations that aren't actually IMPDEF. That's the part
I'm worried about and we will have to draw the line somewhere, especially
when other people are trying to work with this code for compliant
implementations.
So, NAK to your current approach. You need to try something like I said
above and, if you want to spit the file up, start with the page-table code.
Will
^ permalink raw reply
* [PATCH 5/5] tty: serial: Add 8250-core based omap driver
From: Tony Lindgren @ 2014-07-21 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718062456.GJ18374@atomide.com>
* Tony Lindgren <tony@atomide.com> [140717 23:28]:
> * Sebastian Andrzej Siewior <bigeasy@linutronix.de> [140717 03:09]:
> > On 07/17/2014 10:12 AM, Tony Lindgren wrote:
> > > Hmm it could be that it works for a while because the clocks are on
> > > from the bootloader and pm_runtime calls won't do anything. This
> > > could happen if the interconnect data based on the ti,hwmods entry
> > > is not getting matched to the new driver. This gets initialized when
> > > the device entry gets created in omap_device_build_from_dt().
> > >
> > > Or maybe something now affects the clock aliases? It seems that we
> > > are still missing the clocks entries in the .dtsi files, see the
> > > mappings with $ git grep uart drivers/clk/ti/
> >
> > I've been looking for something completely different while I noticed
> > this:
> >
> > in drivers/tty/serial/omap-serial.c
> > | static struct platform_driver serial_omap_driver = {
> > | .driver = {
> > | .name = DRIVER_NAME,
> > | },
> > | };
> > |
> >
> > and DRIVER_NAME should come from include/linux/platform_data/serial-omap.h
> > Looking further, I've found arch/arm/mach-omap2/serial.c:
> > | void __init omap_serial_init_port(struct omap_board_data *bdata,
> > | struct omap_uart_port_info *info)
> > | {
> > | char *name
> > ?
> > | name = DRIVER_NAME;
> > ?
> > | pdev = omap_device_build(name, uart->num, oh, pdata, pdata_size);
> > ?
> > |
> >
> > Would this explain it?
>
> That would explain it for legacy booting, but not for device tree
> based booting. I can try to debug it further on Monday.
Looks like the following is needed to avoid the error, no idea why..
But this is what we also do in omap-serial.c. It may be needed in
other places too?
Also, no luck yet on runtime PM. If the console is enabled omap won't
idle, and if no serial console is enabled, it just hangs. Will try
to debug this part further, it may be also related to the above.
Regards,
Tony
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2066,8 +2066,8 @@ int serial8250_do_startup(struct uart_port *port)
/*
* Clear the interrupt registers.
*/
- serial_port_in(port, UART_LSR);
- serial_port_in(port, UART_RX);
+ if (serial_port_in(port, UART_LSR) & UART_LSR_DR)
+ serial_port_in(port, UART_RX);
serial_port_in(port, UART_IIR);
serial_port_in(port, UART_MSR);
@@ -2228,8 +2228,8 @@ dont_test_tx_en:
* saved flags to avoid getting false values from polling
* routines or the previous session.
*/
- serial_port_in(port, UART_LSR);
- serial_port_in(port, UART_RX);
+ if (serial_port_in(port, UART_LSR) & UART_LSR_DR)
+ serial_port_in(port, UART_RX);
serial_port_in(port, UART_IIR);
serial_port_in(port, UART_MSR);
up->lsr_saved_flags = 0;
^ permalink raw reply
* [RESEND PATCH 0/6] thermal: sti: Add new Thermal driver
From: Zhang Rui @ 2014-07-21 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721091753.GV30888@lee--X1>
On Mon, 2014-07-21 at 10:17 +0100, Lee Jones wrote:
> On Mon, 14 Jul 2014, Lee Jones wrote:
>
> > On Mon, 14 Jul 2014, Zhang Rui wrote:
> >
> > > On Mon, 2014-07-14 at 14:08 +0100, Lee Jones wrote:
> > > > On Wed, 09 Jul 2014, Lee Jones wrote:
> > > > > On Wed, 09 Jul 2014, Zhang Rui wrote:
> > > > > > On Wed, 2014-07-09 at 13:08 +0100, Lee Jones wrote:
> > > > > > > On Tue, 24 Jun 2014, Lee Jones wrote:
> > > > > > >
> > > > > > > > > I'm re-sending this set, as one of the maintainers' email addresses
> > > > > > > > > is incorrect in the MAINTAINERS file.
> > > > > > > > >
> > > > > > > > > This patchset adds full support for 2 types of Thermal Controllers
> > > > > > > > > produced by STMicroelectronics. One is a more traditional memory
> > > > > > > > > mapped variant, the other is controlled solely by system configuration
> > > > > > > > > registers.
> > > > > > > >
> > > > > > > > Any thing from the Thermal guys? Has this set fallen through the gaps?
> > > > > > >
> > > > > > > Anything at all? It's been well over a month now.
> > > > > > >
> > > > > > Well, for the soc thermal drivers, I'd prefer to take them via Eduardo,
> > > > > > but as we didn't get any feedback from Eduardo, I will take them.
> > > > >
> > > > > Thanks Rui.
> > > > >
> > > > > So have you taken all 4 "thermal: sti: *" patches?
> > > >
> > > > Have you taken these yet?
> > >
> > > Not yet. will do tomorrow.
>
> I waited 7 days and still don't see them?
>
Done, they're in my local tree and I forgot to push them.
thanks for the reminder.
-rui
> > Perfect, thanks for the update.
> >
> > > > I notice that these aren't in -next yet.
>
^ permalink raw reply
* [PATCH 5/6] ARM: STi: DT: STiH416: Supply Thermal Controller Device Tree nodes
From: Maxime Coquelin @ 2014-07-21 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1401980819-19962-6-git-send-email-lee.jones@linaro.org>
Hi Lee,
On 06/05/2014 05:06 PM, Lee Jones wrote:
> We supply two of these. The first is controlled by the System Configuration
> registers and the second one provided is a more traditional 'memory mapped'
> variant. Each are handled by they own sub-driver.
>
> Signed-off-by: Ajit Pal Singh <ajitpal.singh@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/boot/dts/stih416.dtsi | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
Added to my queue for v3.17.
Thanks,
Maxime
^ permalink raw reply
* [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
From: Tony Lindgren @ 2014-07-21 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9251918.dhlInzvbvO@avalon>
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [140721 02:16]:
> Hi Suman, Joerg and Tony,
>
> On Friday 18 July 2014 11:53:56 Suman Anna wrote:
> > On 07/18/2014 05:49 AM, Laurent Pinchart wrote:
> > > Hello,
> > >
> > > The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that is
> > > has been ported to the DMA API, remove the unused virtual memory manager.
> > >
> > > The removal is split in three patches to ease upstream merge. The first
> > > patch removes the omap-iovmm driver, the second patch removes setting of
> > > now unused platform data fields from arch code, and the last patch cleans
> > > up the platform data structure.
> >
> > Thanks for the revised series, it looks good. I have also tested the
> > series on OMAP3, OMAP4 and OMAP5.
> >
> > For the changes in the entire series,
> > Acked-by: Suman Anna <s-anna@ti.com>
>
> Thank you.
>
> > > I'd like to get at least the first patch merged in v3.17. To avoid
> > > splitting the series across three kernel versions, it would be nice to
> > > also merge at least the second patch for v3.17. If there's no risk of
> > > conflict everything could be merged in one go through the ARM SoC tree.
> > > Otherwise a stable branch with patch 1/3 will be needed to base the arch
> > > change on.
> > >
> > > Joerg, Tony, how would you like to proceed ?
>
> The v3.17 merge window is getting close, it's probably too late to merge patch
> 2/3. Joerg, could you please take 1/3 in your tree for v3.17 ? 2/3 and 3/3
> would then get in v3.18. Tony, how would you like to proceed for those ?
How about Joerg maybe do an immutable branch against v3.16-rc1
with just these three patches and merge it into your tree?
That way I too can merge the minimal branch in if there are conflics.
If that works for Joerg, then for arch/arm/*omap* changes:
Acked-by: Tony Lindgren <tony@atomide.com>
If the above is too complicated, then how about Laurent resend patches
2 - 3 once the dependencies have cleared so I can pick them up. This
is assuming nothing breaks with patchs 2 - 3 missing naturally :)
Regards,
Tony
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Laurent Pinchart @ 2014-07-21 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721112438.60452e09@bbrezillon>
Hi Boris,
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 ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 2/3] ARM: smp_scu: enable SCU standby support
From: Shawn Guo @ 2014-07-21 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721085150.GB15666@arm.com>
On Mon, Jul 21, 2014 at 09:51:50AM +0100, Will Deacon wrote:
> On Mon, Jul 21, 2014 at 08:45:54AM +0100, Shawn Guo wrote:
> > With SCU standby enabled, SCU CLK will be turned off when all processors
> > are in WFI mode. And the clock will be turned on when any processor
> > leaves WFI mode.
> >
> > This behavior should be preferable in terms of power efficiency of
> > system idle. So let's set the SCU standby bit to enable the support in
> > function scu_enable().
> >
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > arch/arm/kernel/smp_scu.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> > index c947508f84e6..9f29d167d02c 100644
> > --- a/arch/arm/kernel/smp_scu.c
> > +++ b/arch/arm/kernel/smp_scu.c
> > @@ -18,6 +18,7 @@
> >
> > #define SCU_CTRL 0x00
> > #define SCU_ENABLE (1 << 0)
> > +#define SCU_STANDBY_ENABLE (1 << 5)
> > #define SCU_CONFIG 0x04
> > #define SCU_CPU_STATUS 0x08
> > #define SCU_INVALIDATE 0x0c
> > @@ -54,7 +55,7 @@ void scu_enable(void __iomem *scu_base)
> > if (scu_ctrl & SCU_ENABLE)
> > return;
> >
> > - scu_ctrl |= SCU_ENABLE;
> > + scu_ctrl |= SCU_ENABLE | SCU_STANDBY_ENABLE;
>
> I don't think this bit exists on all revisions of the A9.
Thanks for the info, Will. Is there any side-effect to write the
standby bit on those revisions which do not define the bit?
Shawn
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Boris BREZILLON @ 2014-07-21 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721085908.GI8843@ulmo>
On Mon, 21 Jul 2014 10:59:12 +0200
Thierry Reding <thierry.reding@gmail.com> 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.
Best Regards,
Boris
[1]http://lxr.free-electrons.com/source/include/uapi/linux/v4l2-mediabus.h#L37
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RESEND PATCH 0/6] thermal: sti: Add new Thermal driver
From: Lee Jones @ 2014-07-21 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140714142703.GC3993@lee--X1>
On Mon, 14 Jul 2014, Lee Jones wrote:
> On Mon, 14 Jul 2014, Zhang Rui wrote:
>
> > On Mon, 2014-07-14 at 14:08 +0100, Lee Jones wrote:
> > > On Wed, 09 Jul 2014, Lee Jones wrote:
> > > > On Wed, 09 Jul 2014, Zhang Rui wrote:
> > > > > On Wed, 2014-07-09 at 13:08 +0100, Lee Jones wrote:
> > > > > > On Tue, 24 Jun 2014, Lee Jones wrote:
> > > > > >
> > > > > > > > I'm re-sending this set, as one of the maintainers' email addresses
> > > > > > > > is incorrect in the MAINTAINERS file.
> > > > > > > >
> > > > > > > > This patchset adds full support for 2 types of Thermal Controllers
> > > > > > > > produced by STMicroelectronics. One is a more traditional memory
> > > > > > > > mapped variant, the other is controlled solely by system configuration
> > > > > > > > registers.
> > > > > > >
> > > > > > > Any thing from the Thermal guys? Has this set fallen through the gaps?
> > > > > >
> > > > > > Anything at all? It's been well over a month now.
> > > > > >
> > > > > Well, for the soc thermal drivers, I'd prefer to take them via Eduardo,
> > > > > but as we didn't get any feedback from Eduardo, I will take them.
> > > >
> > > > Thanks Rui.
> > > >
> > > > So have you taken all 4 "thermal: sti: *" patches?
> > >
> > > Have you taken these yet?
> >
> > Not yet. will do tomorrow.
I waited 7 days and still don't see them?
> Perfect, thanks for the update.
>
> > > I notice that these aren't in -next yet.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 00/14] arm64: eBPF JIT compiler
From: Will Deacon @ 2014-07-21 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405708100-13604-1-git-send-email-zlim.lnx@gmail.com>
Hello,
On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
> This series implements eBPF JIT compiler for arm64.
> Please see [14/14] for change log.
>
> Patches [1-13/14] implement code generation functions.
> Patch [14/14] implements the actual eBPF JIT compiler.
>
> Many thanks to everyone who's reviewed the code from
> RFCv1->RFCv3, especially Alexei for BPF bits, and Will
> for ARM64 codegen bits :)
>
> BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits).
> Should I add a patch updating MAINTAINERS as Patch 15?
I don't think that's necessary at the moment, but if we start seeing an
influx of patches to arch/arm64/net, then that could make sense in the
future.
> This series requires a patch that exports a function
> from net/core (resulting from RFCv1 discussion). This patch
> has been merged into net-next @ 9f12fbe603f7
> ("net: filter: move load_pointer() into filter.h").
>
> This series applies against net-next and is tested working
> with lib/test_bpf on ARMv8 Foundation Model.
Looks like it works on my Juno board too, so:
Acked-by: Will Deacon <will.deacon@arm.com>
for the series.
It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
also means the dependency on -next isn't an issue). Perhaps you could repost
around -rc3?
Cheers,
Will
^ 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