* [PATCH 1/8] dma: pl08x: Add support for the DMA slave map
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
This patch adds support for the new channel request API introduced
in commit a8135d0d79e9d0ad3a4ff494fceeaae83
"dmaengine: core: Introduce new, universal API to request a channel".
param field of struct dma_slave_map type entries in the platform
data structure should be pointing to struct pl08x_channel_data
of related DMA channel.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
drivers/dma/amba-pl08x.c | 11 +++++++++++
include/linux/amba/pl08x.h | 4 ++++
2 files changed, 15 insertions(+)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 939a7c3..0b7c6ce 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -1793,6 +1793,13 @@ bool pl08x_filter_id(struct dma_chan *chan, void *chan_id)
}
EXPORT_SYMBOL_GPL(pl08x_filter_id);
+static bool pl08x_filter_fn(struct dma_chan *chan, void *chan_id)
+{
+ struct pl08x_dma_chan *plchan = to_pl08x_chan(chan);
+
+ return plchan->cd == chan_id;
+}
+
/*
* Just check that the device is there and active
* TODO: turn this bit on/off depending on the number of physical channels
@@ -2307,6 +2314,10 @@ static int pl08x_probe(struct amba_device *adev, const struct amba_id *id)
ret = -EINVAL;
goto out_no_platdata;
}
+ } else {
+ pl08x->slave.filter.map = pl08x->pd->slave_map;
+ pl08x->slave.filter.mapcnt = pl08x->pd->slave_map_len;
+ pl08x->slave.filter.fn = pl08x_filter_fn;
}
/* By default, AHB1 only. If dualmaster, from platform */
diff --git a/include/linux/amba/pl08x.h b/include/linux/amba/pl08x.h
index 27e9ec8..5308eae 100644
--- a/include/linux/amba/pl08x.h
+++ b/include/linux/amba/pl08x.h
@@ -84,6 +84,8 @@ struct pl08x_channel_data {
* running any DMA transfer and multiplexing can be recycled
* @lli_buses: buses which LLIs can be fetched from: PL08X_AHB1 | PL08X_AHB2
* @mem_buses: buses which memory can be accessed from: PL08X_AHB1 | PL08X_AHB2
+ * @slave_map: DMA slave matching table
+ * @slave_map_len: number of elements in @slave_map
*/
struct pl08x_platform_data {
struct pl08x_channel_data *slave_channels;
@@ -93,6 +95,8 @@ struct pl08x_platform_data {
void (*put_xfer_signal)(const struct pl08x_channel_data *, int);
u8 lli_buses;
u8 mem_buses;
+ const struct dma_slave_map *slave_map;
+ int slave_map_len;
};
#ifdef CONFIG_AMBA_PL08X
--
1.9.1
^ permalink raw reply related
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Sylwester Nawrocki @ 2016-11-10 15:17 UTC (permalink / raw)
To: linux-arm-kernel
This patch series aims to convert the s3c64xx platform to use
the new DMA channel request API, i.e. this is only meaningful
for non-dt systems using s3c64xx SoCs.
Presumably the first 2 or 4 patches in this series could be queued
for v4.10-rc1 and the remaining patches could be left for subsequent
release, to avoid non-trivial conflict with patches already applied
in the ASoC tree.
The whole series can be pulled from git repository:
git://linuxtv.org/snawrocki/samsung.git
branch: for-v4.10/dma/pl080-s3c64xx-v2
Thanks.
Sylwester Nawrocki (8):
dma: pl08x: Add support for the DMA slave map
ARM: s3c64xx: Add DMA slave maps for PL080 devices
spi: s3c64xx: Do not use platform_data for DMA parameters
ARM: s3c64xx: Drop unused DMA fields from struct s3c64xx_spi_csinfo
ASoC: samsung: i2s: Do not use platform_data for DMA parameters
ASoC: samsung: pcm: Do not use platform_data for DMA parameters
ARM: s3c64xx: Drop initialization of unused struct s3c_audio_pdata
fields
ARM: s3c24xx: Drop unused struct s3c_audio_pdata entries
arch/arm/mach-s3c64xx/dev-audio.c | 19 --------------
arch/arm/mach-s3c64xx/pl080.c | 32 +++++++++++++++++++++++
arch/arm/plat-samsung/devs.c | 43 -------------------------------
drivers/dma/amba-pl08x.c | 11 ++++++++
drivers/spi/spi-s3c64xx.c | 21 +++------------
include/linux/amba/pl08x.h | 4 +++
include/linux/platform_data/spi-s3c64xx.h | 3 ---
sound/soc/samsung/i2s.c | 14 ++--------
sound/soc/samsung/pcm.c | 14 ++++------
9 files changed, 58 insertions(+), 103 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: Corentin Labbe @ 2016-11-10 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025132648.txeo3rw6yz5wutrg@lukather>
On Tue, Oct 25, 2016 at 03:26:48PM +0200, Maxime Ripard wrote:
> On Tue, Oct 25, 2016 at 07:38:55AM +0200, LABBE Corentin wrote:
> > On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> > > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > > Since SID's content is constant over reboot,
> > >
> > > That's not true, at least not across all the Allwinner SoCs, and
> > > especially not on the A10 and A20 that this driver supports.
> > >
> >
> > On my cubieboard2 (A20)
> > hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> > 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000200
> > cubiedev ~ # reboot
> > cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> > 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000200
> >
> > So clearly for me its constant.
>
> It's constant across reboots, but not across devices. Each device have
> a different SID content, therefore it's a relevant source of entropy
> in the system.
>
Not the 3 leading digit and not the tailing zeros which are the same accross device.
So only 50% of data are really different accross devices.
Perhaps a "random-range" property could be used ?
Herbert, does it is safe to add that 50% duplicate content via add_device_randomness() ?
Reading add_device_randomness doc, it seems finally it is safe, but if you could confirm it.
Regards
^ permalink raw reply
* [PATCH 1/2] arm64: perf: Move ARMv8 PMU perf event definitions to asm/perf_event.h
From: Wei Huang @ 2016-11-10 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aa5b2275-374f-4d74-d9d9-0959d90454ca@arm.com>
On 11/10/2016 03:10 AM, Marc Zyngier wrote:
> Hi Wei,
>
> On 09/11/16 19:57, Wei Huang wrote:
>> This patch moves ARMv8-related perf event definitions from perf_event.c
>> to asm/perf_event.h; so KVM code can use them directly. This also help
>> remove a duplicated definition of SW_INCR in perf_event.h.
>>
>> Signed-off-by: Wei Huang <wei@redhat.com>
>> ---
>> arch/arm64/include/asm/perf_event.h | 161 +++++++++++++++++++++++++++++++++++-
>> arch/arm64/kernel/perf_event.c | 161 ------------------------------------
>> 2 files changed, 160 insertions(+), 162 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
>> index 2065f46..6c7b18b 100644
>> --- a/arch/arm64/include/asm/perf_event.h
>> +++ b/arch/arm64/include/asm/perf_event.h
>> @@ -46,7 +46,166 @@
>> #define ARMV8_PMU_EVTYPE_MASK 0xc800ffff /* Mask for writable bits */
>> #define ARMV8_PMU_EVTYPE_EVENT 0xffff /* Mask for EVENT bits */
>>
>> -#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR 0 /* Software increment event */
>> +/*
>> + * ARMv8 PMUv3 Performance Events handling code.
>> + * Common event types.
>> + */
>> +
>> +/* Required events. */
>> +#define ARMV8_PMUV3_PERFCTR_SW_INCR 0x00
>> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE_REFILL 0x03
>> +#define ARMV8_PMUV3_PERFCTR_L1D_CACHE 0x04
>> +#define ARMV8_PMUV3_PERFCTR_BR_MIS_PRED 0x10
>> +#define ARMV8_PMUV3_PERFCTR_CPU_CYCLES 0x11
>> +#define ARMV8_PMUV3_PERFCTR_BR_PRED 0x12
>
> In my initial review, I asked for the "required" events to be moved to a
> shared location. What's the rational for moving absolutely everything?
I did notice the phrase "required" in the original email. However I
think it is weird to have two places for a same set of PMU definitions.
Other developers might think these two are missing if they don't search
kernel files carefully.
If Will Deacon and you insist, I can move only two defs to perf_event.h,
consolidated with the 2nd patch into a single one.
> KVM only needs to know about ARMV8_PMUV3_PERFCTR_SW_INCR and
> ARMV8_PMUV3_PERFCTR_CPU_CYCLES, so I thought that moving the above six
> events (and maybe the following two) would be enough.
>
> Also, you've now broken the build by dropping
> ARMV8_PMU_EVTYPE_EVENT_SW_INCR without amending it use in the KVM PMU
> code (see the kbuild report).
>
My bad. I tested compilation only after two patches applied. Will fix it.
<snip>
>> +
>> /* PMUv3 HW events mapping. */
>>
>> /*
>>
>
> Thanks,
>
> M.
>
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Tony Lindgren @ 2016-11-10 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <621758ce-dd3f-41ad-d9b8-b8e34538700e@redhat.com>
* Hans de Goede <hdegoede@redhat.com> [161110 01:35]:
> Hi,
>
> On 09-11-16 20:23, Tony Lindgren wrote:
> > Hi,
> >
> > Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
> > the sysfs brightness attr for changes.") breaks runtime PM for me.
> >
> > On my omap dm3730 based test system, idle power consumption is over 70
> > times higher now with this patch! It goes from about 6mW for the core
> > system to over 440mW during idle meaning there's some busy timer now
> > active.
>
> Do you have any blinking LEDs or LED triggers defined on the system ?
There are some configured in the dts file:
$ grep -i led arch/arm/boot/dts/*torpedo*.dts*
And the gpio controlled led1 is configured to blink with
linux,default-trigger = "cpu0".
> > Reverting this patch fixes the issue. Any ideas?
>
> All I can think of is something calling led_set_brightness quite often,
> the patch in question makes led_set_brightness somewhat more expensive,
> but it should not cause such a big difference unless something is
> really calling led_set_brightness quite often maybe something is calling
> it with the same value all the time ?
I don't think this one has any brightness control.
Regards,
Tony
^ permalink raw reply
* [PATCH RFC 2/7] ARM: S3C64XX: Add DMA slave maps for PL080 devices
From: Sylwester Nawrocki @ 2016-11-10 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110110323.GG1575@localhost.localdomain>
On 11/10/2016 12:03 PM, Charles Keepax wrote:
>> On Tue, Nov 08, 2016 at 04:53:40PM +0100, Sylwester Nawrocki wrote:
[...]
>> I pushed now to branch for-v4.10/dma/pl080-s3c64xx-v2 with this
>> issue fixed and added initialization of the filer function.
>
> Apologies for the delay got somewhat swamped with internal stuff
> yesterday. Yeah using that branch it looks good to me, the SPI and
> I2S are both working fine. I can download code to the wm0010
> which should be a good work out of the SPI and play audio
> correctly so the I2S should be fine. So for the series:
>
> Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Great, thanks a lot! I'm going to post the next iteration with
modified pl080 DMAC patches, addressing comments from Arnd.
I would be grateful if you could confirm it also works on your
platform.
> I do still need to revert these two patches to get the I2S to
> work properly:
>
> commit d70e861a3154833467023123e218e9b1ba558809
> ASoC: samsung: Remove SND_DMAENGINE_PCM_FLAG_NO_RESIDUE flag
>
> commit acde50a7bf1fd6ae0baa4402f0a02c4b1bd4c990
> ASoC: dmaengine_pcm: Make FLAG_NO_RESIDUE internal
>
> But that is clearly an unrelated issue, which I haven't found
> time to look into yet as we don't use this platform that often
> these days.
Thanks for reporting this, I will see if I can find time to look
into this issue as well.
--
Thanks,
Sylwester
^ permalink raw reply
* [GIT PULL]: ARM ARTPEC changes for 4.10
From: Jesper Nilsson @ 2016-11-10 15:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
Please pull the below signed tag for a trio of minor changes
adding PCIe for the ARM ARTPEC SoC.
Thanks!
/Jesper
The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/artpec.git tags/artpec-for-4.10
for you to fetch changes up to fa5541fc806771a108cd2a48245a229f1ba539ea:
ARM: dts: artpec: add pcie support (2016-11-10 15:51:10 +0100)
----------------------------------------------------------------
ARTPEC changes for 4.10
----------------------------------------------------------------
Niklas Cassel (3):
ARM: ARTPEC-6: add select MFD_SYSCON to MACH_ARTPEC6
ARM: ARTPEC-6: add pcie related options
ARM: dts: artpec: add pcie support
arch/arm/boot/dts/artpec6-devboard.dts | 4 ++++
arch/arm/boot/dts/artpec6.dtsi | 29 ++++++++++++++++++++++++++++-
arch/arm/mach-artpec/Kconfig | 3 +++
3 files changed, 35 insertions(+), 1 deletion(-)
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH V6 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: agustinv at codeaurora.org @ 2016-11-10 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <42ff0a81-7836-11f6-58e0-979bd1d0be20@linaro.org>
Hey Hanjun,
On 2016-11-09 21:36, Hanjun Guo wrote:
> Hi Marc, Rafael, Lorenzo,
>
> Since we agreed to add a probe deferral if we failed to get irq
> resources which mirroring the DT does (patch 1 in this patch set),
> I think the last blocker to make things work both for Agustin and
> me [1] is this patch, which makes the interrupt producer and consumer
> work in ACPI, we have two different solution for one thing, we'd happy
> to work together for one solution, could you give some suggestions
> please?
>
> [1]:
> https://mail-archive.com/linux-kernel at vger.kernel.org/msg1257419.html
>
> Agustin, I have some comments below.
>
> On 2016/10/29 4:48, Agustin Vega-Frias wrote:
>> This allows irqchip drivers to associate an ACPI DSDT device to
>> an IRQ domain and provides support for using the ResourceSource
>> in Extended IRQ Resources to find the domain and map the IRQs
>> specified on that domain.
>>
>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>> ---
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/irqdomain.c | 119
>> +++++++++++++++++++++++++++++++++++++++++++++++
>
> Could we just reuse the gsi.c and not introduce a new
> file, probably we can change the gsi.c to irqdomain.c
> or something similar, then reuse the code in gsi.c.
I was thinking just that after we chatted off-list.
I might revisit and see what I come up with given that we already have
a device argument and we could pass the IRQ source there.
Thanks
>
> Thanks
> Hanjun
>
>> drivers/acpi/resource.c | 21 +++++----
>> include/linux/acpi.h | 25 ++++++++++
>> 4 files changed, 157 insertions(+), 9 deletions(-)
>> create mode 100644 drivers/acpi/irqdomain.c
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 9ed0878..880401b 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
>> acpi-y += acpi_lpat.o
>> acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
>> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
>> +acpi-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
>>
>> # These are (potentially) separate modules
>>
>> diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
>> new file mode 100644
>> index 0000000..11d3658
>> --- /dev/null
>> +++ b/drivers/acpi/irqdomain.c
>> @@ -0,0 +1,119 @@
>> +/*
>> + * ACPI ResourceSource/IRQ domain mapping support
>> + *
>> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +#include <linux/acpi.h>
>> +#include <linux/irq.h>
>> +#include <linux/irqdomain.h>
>> +
>> +/**
>> + * acpi_irq_domain_register_irq() - Register the mapping for an IRQ
>> produced
>> + * by the given acpi_resource_source
>> to a
>> + * Linux IRQ number
>> + * @source: IRQ source
>> + * @hwirq: Hardware IRQ number
>> + * @trigger: trigger type of the IRQ number to be mapped
>> + * @polarity: polarity of the IRQ to be mapped
>> + *
>> + * Returns: a valid linux IRQ number on success
>> + * -ENODEV if the given acpi_resource_source cannot be found
>> + * -EPROBE_DEFER if the IRQ domain has not been registered
>> + * -EINVAL for all other errors
>> + */
>> +int acpi_irq_domain_register_irq(const struct acpi_resource_source
>> *source,
>> + u32 hwirq, int trigger, int polarity)
>> +{
>> + struct irq_fwspec fwspec;
>> + struct acpi_device *device;
>> + acpi_handle handle;
>> + acpi_status status;
>> + int ret;
>> +
>> + /* An empty acpi_resource_source means it is a GSI */
>> + if (!source->string_length)
>> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
>> +
>> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
>> + if (ACPI_FAILURE(status))
>> + return -ENODEV;
>> +
>> + device = acpi_bus_get_acpi_device(handle);
>> + if (!device)
>> + return -ENODEV;
>> +
>> + if (irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY) ==
>> NULL) {
>> + ret = -EPROBE_DEFER;
>> + goto out_put_device;
>> + }
>> +
>> + fwspec.fwnode = &device->fwnode;
>> + fwspec.param[0] = hwirq;
>> + fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
>> + fwspec.param_count = 2;
>> +
>> + ret = irq_create_fwspec_mapping(&fwspec);
>> +
>> +out_put_device:
>> + acpi_bus_put_acpi_device(device);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
>> +
>> +/**
>> + * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ
>> produced
>> + * by the given
>> acpi_resource_source to a
>> + * Linux IRQ number
>> + * @source: IRQ source
>> + * @hwirq: Hardware IRQ number
>> + *
>> + * Returns: 0 on success
>> + * -ENODEV if the given acpi_resource_source cannot be found
>> + * -EINVAL for all other errors
>> + */
>> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source
>> *source,
>> + u32 hwirq)
>> +{
>> + struct irq_domain *domain;
>> + struct acpi_device *device;
>> + acpi_handle handle;
>> + acpi_status status;
>> + int ret = 0;
>> +
>> + if (!source->string_length) {
>> + acpi_unregister_gsi(hwirq);
>> + return 0;
>> + }
>> +
>> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
>> + if (ACPI_FAILURE(status))
>> + return -ENODEV;
>> +
>> + device = acpi_bus_get_acpi_device(handle);
>> + if (!device)
>> + return -ENODEV;
>> +
>> + domain = irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY);
>> + if (!domain) {
>> + ret = -EINVAL;
>> + goto out_put_device;
>> + }
>> +
>> + irq_dispose_mapping(irq_find_mapping(domain, hwirq));
>> +
>> +out_put_device:
>> + acpi_bus_put_acpi_device(device);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>> index 4beda15..ccb6f4f 100644
>> --- a/drivers/acpi/resource.c
>> +++ b/drivers/acpi/resource.c
>> @@ -381,14 +381,15 @@ static void acpi_dev_irqresource_disabled(struct
>> resource *res, u32 gsi)
>> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED |
>> IORESOURCE_UNSET;
>> }
>>
>> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
>> +static void acpi_dev_get_irqresource(struct resource *res, u32 hwirq,
>> + const struct acpi_resource_source *source,
>> u8 triggering, u8 polarity, u8 shareable,
>> bool legacy)
>> {
>> int irq, p, t;
>>
>> - if (!valid_IRQ(gsi)) {
>> - acpi_dev_irqresource_disabled(res, gsi);
>> + if ((source->string_length == 0) && !valid_IRQ(hwirq)) {
>> + acpi_dev_irqresource_disabled(res, hwirq);
>> return;
>> }
>>
>> @@ -402,25 +403,25 @@ static void acpi_dev_get_irqresource(struct
>> resource *res, u32 gsi,
>> * using extended IRQ descriptors we take the IRQ configuration
>> * from _CRS directly.
>> */
>> - if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
>> + if (legacy && !acpi_get_override_irq(hwirq, &t, &p)) {
>> u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
>> u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>>
>> if (triggering != trig || polarity != pol) {
>> - pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi,
>> - t ? "level" : "edge", p ? "low" : "high");
>> + pr_warn("ACPI: IRQ %d override to %s, %s\n", hwirq,
>> + t ? "level" : "edge", p ? "low" : "high");
>> triggering = trig;
>> polarity = pol;
>> }
>> }
>>
>> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
>> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
>> + irq = acpi_irq_domain_register_irq(source, hwirq, triggering,
>> polarity);
>> if (irq >= 0) {
>> res->start = irq;
>> res->end = irq;
>> } else {
>> - acpi_dev_irqresource_disabled(res, gsi);
>> + acpi_dev_irqresource_disabled(res, hwirq);
>> }
>> }
>>
>> @@ -446,6 +447,7 @@ static void acpi_dev_get_irqresource(struct
>> resource *res, u32 gsi,
>> bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int
>> index,
>> struct resource *res)
>> {
>> + const struct acpi_resource_source dummy = { 0, 0, NULL };
>> struct acpi_resource_irq *irq;
>> struct acpi_resource_extended_irq *ext_irq;
>>
>> @@ -460,7 +462,7 @@ bool acpi_dev_resource_interrupt(struct
>> acpi_resource *ares, int index,
>> acpi_dev_irqresource_disabled(res, 0);
>> return false;
>> }
>> - acpi_dev_get_irqresource(res, irq->interrupts[index],
>> + acpi_dev_get_irqresource(res, irq->interrupts[index], &dummy,
>> irq->triggering, irq->polarity,
>> irq->sharable, true);
>> break;
>> @@ -471,6 +473,7 @@ bool acpi_dev_resource_interrupt(struct
>> acpi_resource *ares, int index,
>> return false;
>> }
>> acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
>> + &ext_irq->resource_source,
>> ext_irq->triggering, ext_irq->polarity,
>> ext_irq->sharable, false);
>> break;
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index 40213c4..ce30a12 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -321,6 +321,31 @@ void acpi_set_irq_model(enum acpi_irq_model_id
>> model,
>> */
>> void acpi_unregister_gsi (u32 gsi);
>>
>> +#ifdef CONFIG_IRQ_DOMAIN
>> +
>> +int acpi_irq_domain_register_irq(const struct acpi_resource_source
>> *source,
>> + u32 hwirq, int trigger, int polarity);
>> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source
>> *source,
>> + u32 hwirq);
>> +
>> +#else
>> +
>> +static inline int acpi_irq_domain_register_irq(
>> + const struct acpi_resource_source *source, u32 hwirq, int trigger,
>> + int polarity)
>> +{
>> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
>> +}
>> +
>> +static inline int acpi_irq_domain_unregister_irq(
>> + const struct acpi_resource_source *source, u32 hwirq)
>> +{
>> + acpi_unregister_gsi(hwirq);
>> + return 0;
>> +}
>> +
>> +#endif /* CONFIG_IRQ_DOMAIN */
>> +
>> struct pci_dev;
>>
>> int acpi_pci_irq_enable (struct pci_dev *dev);
>>
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 5/5] drm/sun4i: Add support for the overscan profiles
From: Maxime Ripard @ 2016-11-10 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108085927.ibyett46cjgyfwu2@phenom.ffwll.local>
Hi Daniel,
On Tue, Nov 08, 2016 at 09:59:27AM +0100, Daniel Vetter wrote:
> On Tue, Oct 18, 2016 at 10:29:38AM +0200, Maxime Ripard wrote:
> > Create overscan profiles reducing the displayed zone.
> >
> > For each TV standard (PAL and NTSC so far), we create 4 more reduced modes
> > by steps of 5% that the user will be able to select.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> tbh I think if we agree to do this (and that still seems an open question)
> I think there should be a generic helper to add these overscan modes with
> increased porches. Anything that only depends upon the sink (and
> overscanning is something the sink does) should imo be put into a suitable
> helper library for everyone to share.
>
> Or maybe even stash it into the probe helpers and call it for all TV
> connectors. Definitely not a driver-private thing.
Last time we discussed it, my recollection was that you didn't want to
have generic code for it, but I'd be happy to implement it.
I'll come up with something like that.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/40bb0b9b/attachment.sig>
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Joerg Roedel @ 2016-11-10 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83b6440a-31eb-c1b4-642c-a4c311f37ef2@redhat.com>
On Thu, Nov 10, 2016 at 01:14:42AM +0100, Auger Eric wrote:
> Besides above problematic, I started to prototype the sysfs API. A first
> issue I face is the reserved regions become global to the iommu instead
> of characterizing the iommu_domain, ie. the "reserved_regions" attribute
> file sits below an iommu instance (~
> /sys/class/iommu/dmar0/intel-iommu/reserved_regions ||
> /sys/class/iommu/arm-smmu0/arm-smmu/reserved_regions).
>
> MSI reserved window can be considered global to the IOMMU. However PCIe
> host bridge P2P regions rather are per iommu-domain.
>
> Do you confirm the attribute file should contain both global reserved
> regions and all per iommu_domain reserved regions?
>
> Thoughts?
This information is best attached to the sysfs-representation of
iommu-groups. The file should then contain the superset of all reserved
regions of the devices the group contains. This makes it usable later to
also describe RMRR/Unity-mapped regions on x86 there and make them
assignable to guests as well.
Joerg
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Joerg Roedel @ 2016-11-10 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109130114.3e17bba9@t450s.home>
On Wed, Nov 09, 2016 at 01:01:14PM -0700, Alex Williamson wrote:
> Well, it's not like QEMU or libvirt stumbling through sysfs to figure
> out where holes could be in order to instantiate a VM with matching
> holes, just in case someone might decide to hot-add a device into the
> VM, at some point, and hopefully they don't migrate the VM to another
> host with a different layout first, is all that much less disgusting or
> foolproof. It's just that in order to dynamically remove a page as a
> possible DMA target we require a paravirt channel, such as a balloon
> driver that's able to pluck a specific page. In some ways it's
> actually less disgusting, but it puts some prerequisites on
> enlightening the guest OS. Thanks,
I think it is much simpler if libvirt/qemu just go through all
potentially assignable devices on a system and pre-exclude any addresses
from guest RAM beforehand, rather than doing something like this with
paravirt/ballooning when a device is hot-added. There is no guarantee
that you can take a page away from a linux-guest.
Joerg
^ permalink raw reply
* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-10 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLW4JZHb0ncVUEefnKySA231EDgvCkY3xPdaJGf=uMJYg@mail.gmail.com>
On 10/11/16 14:12, Rob Herring wrote:
> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 10/11/16 01:22, Rob Herring wrote:
>>>
>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>
>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> index d1882c4540d0..ebd03fc93135 100644
>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>> operations.
>>>>
>>>> Required properties:
>>>>
>>>> -- compatible : should be "arm,scpi"
>>>> +- compatible : should be
>>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>> above
>>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>>
>>>
>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>> many?
>>>
>>
>> I understand your concern, but this legacy SCPI protocol was not
>> officially released. It was just WIP which vendors picked up from very
>> early releases. Since they are not numbered, it's hard to have specific
>> compatibles with different versions until v1.0. That's one of the reason
>> to retain platform specific compatible so that we can add any quirks
>> based on them if needed.
>>
>> I will probably add these information in the commit log so that it's
>> clear why we can't do version based compatible.
>
> This is exactly my point. By enumerate, I meant having platform
> specific compatibles. Having "arm,legacy-scpi" is pointless because
> who knows what version they followed and they may all be different.
>
OK, but IIUC Olof's concern wanted a generic one along with the platform
specific compatible which kind of makes sense as so far we have seen
some commonality between Amlogic and Rockchip.
E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.
Is that not acceptable ?
--
Regards,
Sudeep
^ permalink raw reply
* [PATCHv3 2/4] misc: Add Altera Arria10 System Resource Control
From: Greg KH @ 2016-11-10 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097178-24341-3-git-send-email-tthayer@opensource.altera.com>
On Wed, Nov 02, 2016 at 09:32:56AM -0500, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer@opensource.altera.com>
>
> This patch adds the Altera Arria10 control & monitoring
> functions to the Arria10 System Resource chip.
>
> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
> ---
> v2 Change compatible string and filename from -mon to -monitor
> Change CONFIG from module to builtin.
> Make wm_rst register writeable.
> v3 Remove unused ret variable.
> Shorten driver name (remove altr_).
> ---
> MAINTAINERS | 1 +
> drivers/misc/Kconfig | 7 ++
> drivers/misc/Makefile | 1 +
> drivers/misc/altera-a10sr-monitor.c | 175 ++++++++++++++++++++++++++++++++++++
> 4 files changed, 184 insertions(+)
> create mode 100644 drivers/misc/altera-a10sr-monitor.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b180821..baf2404 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -635,6 +635,7 @@ M: Thor Thayer <tthayer@opensource.altera.com>
> S: Maintained
> F: drivers/gpio/gpio-altera-a10sr.c
> F: drivers/mfd/altera-a10sr.c
> +F: drivers/misc/altera-a10sr-monitor.c
> F: include/linux/mfd/altera-a10sr.h
>
> ALTERA TRIPLE SPEED ETHERNET DRIVER
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 64971ba..f42d459 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -766,6 +766,13 @@ config PANEL_BOOT_MESSAGE
> An empty message will only clear the display at driver init time. Any other
> printf()-formatted message is valid with newline and escape codes.
>
> +config ALTERA_A10SR_MONITOR
> + bool "Altera Arria10 System Resource Monitor"
> + depends on MFD_ALTERA_A10SR
> + help
> + This enables the System Resource monitor driver for the Altera
> + Arria10 DevKit.
> +
> source "drivers/misc/c2port/Kconfig"
> source "drivers/misc/eeprom/Kconfig"
> source "drivers/misc/cb710/Kconfig"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 3198336..9f6e77a 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -43,6 +43,7 @@ obj-y += ti-st/
> obj-y += lis3lv02d/
> obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
> obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
> +obj-$(CONFIG_ALTERA_A10SR_MONITOR) += altera-a10sr-monitor.o
> obj-$(CONFIG_INTEL_MEI) += mei/
> obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
> obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
> diff --git a/drivers/misc/altera-a10sr-monitor.c b/drivers/misc/altera-a10sr-monitor.c
> new file mode 100644
> index 0000000..66338e0
> --- /dev/null
> +++ b/drivers/misc/altera-a10sr-monitor.c
> @@ -0,0 +1,175 @@
> +/*
> + * Altera Arria10 DevKit System Resource Chip Monitor Driver
> + *
> + * Author: Thor Thayer <tthayer@opensource.altera.com>
> + *
> + * Copyright Intel Corporation (C) 2014-2016. All Rights Reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Monitor driver for the Altera Arria10 MAX5 System Resource Chip
> + * Adapted from ics932s401.c
> + */
> +
> +#include <linux/err.h>
> +#include <linux/mfd/altera-a10sr.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +struct altr_a10sr_regs {
> + struct regmap *regmap;
> + struct attribute_group attr_grp;
> +};
> +
> +static ssize_t a10sr_show(struct device *dev,
> + struct device_attribute *devattr, char *buf);
> +static ssize_t a10sr_store(struct device *dev,
> + struct device_attribute *devattr, const char *buf,
> + size_t count);
> +
> +/* Define FS entries */
> +static DEVICE_ATTR(max5_version, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_led, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_button, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_button_irq, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_pg1, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_pg2, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_pg3, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_fmcab, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_hps_resets, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_per_resets, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_sfpa, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_sfpb, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_i2c_master, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_wm_rst, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_wm_rst_key, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_pmbus, 0644, a10sr_show, a10sr_store);
Please add a Documentation/ABI file to describe all of thes new sysfs
files that you are saying will be present for all of time.
And do you really want userspace access like this to these values?
Shouldn't things like the led and button use the proper led and input
layers instead?
> +static int altr_a10sr_regs_probe(struct platform_device *pdev)
> +{
> + struct altr_a10sr_regs *a10regs;
> + struct altr_a10sr *a10sr = dev_get_drvdata(pdev->dev.parent);
> +
> + a10regs = devm_kzalloc(&pdev->dev, sizeof(*a10regs), GFP_KERNEL);
> + if (!a10regs)
> + return -ENOMEM;
> +
> + a10regs->regmap = a10sr->regmap;
> + a10regs->attr_grp = a10sr_attr_group;
> +
> + platform_set_drvdata(pdev, a10regs);
> +
> + return sysfs_create_group(&pdev->dev.kobj, &a10sr_attr_group);
You just raced userspace and lost :(
Please set the group file properly, and then the driver core should set
this up for you correctly.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Robin Murphy @ 2016-11-10 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110122420.GH9996@8bytes.org>
On 10/11/16 12:24, Joerg Roedel wrote:
> On Wed, Oct 26, 2016 at 06:43:56PM +0100, Robin Murphy wrote:
>> With the new dma_{map,unmap}_resource() functions added to the DMA API
>> for the benefit of cases like slave DMA, add suitable implementations to
>> the arsenal of our generic layer. Since cache maintenance should not be
>> a concern, these can both be standalone callback implementations without
>> the need for arch code wrappers.
>>
>> CC: Joerg Roedel <joro@8bytes.org>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>
>> v2: Use iommu_dma_unmap_page for symmetry, instead of being sneaky.
>>
>> drivers/iommu/dma-iommu.c | 13 +++++++++++++
>> include/linux/dma-iommu.h | 4 ++++
>> 2 files changed, 17 insertions(+)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index c5ab8667e6f2..a2fd90a6a782 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -624,6 +624,19 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
>> __iommu_dma_unmap(iommu_get_domain_for_dev(dev), sg_dma_address(sg));
>> }
>>
>> +dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
>> + size_t size, enum dma_data_direction dir, unsigned long attrs)
>> +{
>> + return iommu_dma_map_page(dev, phys_to_page(phys), offset_in_page(phys),
>> + size, dma_direction_to_prot(dir, false) | IOMMU_MMIO);
>> +}
>
> Isn't the whole point of map_resource that we can map regions which have
> no 'struct page' associated? The use phys_to_page() will certainly not
> do the right thing here.
Perhaps it's a bit cheeky, but the struct page pointer is never
dereferenced - the only thing iommu_dma_map_page() does with it is
immediately convert it back again. Is there ever a case where
page_to_phys(phys_to_page(phys)) != phys ?
Robin.
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Maxime Ripard @ 2016-11-10 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107154652.GH1041@n2100.armlinux.org.uk>
On Mon, Nov 07, 2016 at 03:46:52PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 07, 2016 at 04:09:09PM +0100, Maxime Ripard wrote:
> > Hi Russell,
> >
> > On Thu, Nov 03, 2016 at 09:54:45AM +0000, Russell King - ARM Linux wrote:
> > > > Yes. And that is an XBMC only solution, that doesn't work with the
> > > > fbdev emulation and is probably doing an additional composition to
> > > > scale down and center their frames through OpenGL.
> > >
> > > Well, it will have to be doing a scaling step anyway. If the video
> > > frame is a different size to the active area, scaling is required
> > > no matter what. A 576p SD image needs to be scaled up, and a 1080p
> > > image would need to be scaled down for a 1080p overscanned display
> > > with a reduced active area to counter the overscanning - no matter
> > > how you do it.
> >
> > Yes, except that scaling is not always an option. In my particular
> > example, there's no scaler after the CRTC, which essentially prevents
> > it from being used in that use case. Which is also why I ended up
> > reducing the mode reported to the user.
>
> I think you completely missed my point. Let me try again.
>
> If you expose a reduced mode to the user, you are reporting that (eg)
> the 1080p-timings mode does not have 1920 pixels horizontally, and
> 1080 lines. You are instead reporting that it has (eg) 1800 pixels
> horizontally and maybe 1000 lines.
>
> So, when you play back a 1080 video, you are going to have to either:
>
> 1. crop the extra 120 pixels horizontally and 80 lines vertically
> or
> 2. scale the image.
>
> However, this is a completely independent issue to how we go about
> setting a video mode that is 1800x1000 in the first place.
>
> What you're suggesting is that we add code to the kernel to report that
> your non-EDID, analogue output transforms the standard 1920x1080 timings
> such that it has a 1800x1000 active area.
>
> I'm suggesting instead that you can do the same thing in userspace by
> specifically adding a mode which has the 1920x1080 standard timings,
> but with the porches increased and the active area reduced - in exactly
> the same way that you'd have to do within the kernel to report your
> active-area-reduced 1800x1000 mode.
Ah, yes, you meant input scaling, not output, sorry.
> > > For graphics, userspace could add mode(s) with increased porches and
> > > reduced active area itself to achieve an underscanned display on a
> > > timing which the display device always overscans - there's no need to
> > > do that in the kernel, all the APIs are there to be able to do it
> > > already.
> > >
> > > That means your framebuffer will be smaller, but that's the case
> > > anyway.
> >
> > Yes, that would be a good idea. But it's not always an option for
> > applications that would rely on the fbdev emulation (like QT's eglfs),
> > which would then have no way to change whatever default there is (and
> > the only one able to know how bad it actually is is the user).
>
> I guess this is the problem with DRM people wanting to deprecate fbdev...
> too much stuff currently relies upon it, but DRM on x86 has always had
> the reduced functionality.
>
> I guess there's two solutions here:
>
> 1. Either DRMs fbdev gains increased functionality, or
> 2. The fbdev-only applications/libraries need to be ported over to
> support DRM natively.
>
> This has been a bar for some time to moving over to DRM, and I've heard
> very little desire on either side to find some sort of compromise on the
> issue, so I guess things are rather stuck where they are.
I guess it really all boils down to this, and whether the userspace
will be able to set a custom mode on its own. "Advanced" stacks like
Xorg and Wayland will, but simpler and / or legacy applications will
depend on the fbdev emulation, either because they've not been
converted through DRM (like you suggested) or because it depends on a
blob that requires it (and then you're stuck).
And since the kernel already deals with overscan through a generic
property, it really feels like it's the place it should be done to
address all needs (and ideally in a generic way).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/a482bcf9/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Andrew Lunn @ 2016-11-10 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110135721.13098-1-uwe@kleine-koenig.org>
On Thu, Nov 10, 2016 at 02:57:20PM +0100, Uwe Kleine-K?nig wrote:
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
Hi Uwe
It is normal to send vendor-prefixes patches directly to the device
tree maintainers as a separate patch. That avoids merge conflicts on
the file.
Andrew
^ permalink raw reply
* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Rob Herring @ 2016-11-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14e563ae-36c5-4bf9-0d51-3b07830de3db@arm.com>
On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 01:22, Rob Herring wrote:
>>
>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>
>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> index d1882c4540d0..ebd03fc93135 100644
>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>> operations.
>>>
>>> Required properties:
>>>
>>> -- compatible : should be "arm,scpi"
>>> +- compatible : should be
>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>> above
>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>
>>
>> I'd prefer that we explicitly enumerate the old versions. Are there
>> many?
>>
>
> I understand your concern, but this legacy SCPI protocol was not
> officially released. It was just WIP which vendors picked up from very
> early releases. Since they are not numbered, it's hard to have specific
> compatibles with different versions until v1.0. That's one of the reason
> to retain platform specific compatible so that we can add any quirks
> based on them if needed.
>
> I will probably add these information in the commit log so that it's
> clear why we can't do version based compatible.
This is exactly my point. By enumerate, I meant having platform
specific compatibles. Having "arm,legacy-scpi" is pointless because
who knows what version they followed and they may all be different.
Rob
^ permalink raw reply
* [PATCH] iommu/dma-iommu: properly respect configured address space size
From: Robin Murphy @ 2016-11-10 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6f2f3d37-dc6c-abdb-9692-8dcc9cad36f3@samsung.com>
On 08/11/16 14:53, Marek Szyprowski wrote:
> Hi Robin,
>
>
> On 2016-11-08 15:44, Robin Murphy wrote:
>> On 08/11/16 13:41, Marek Szyprowski wrote:
>>> On 2016-11-08 12:37, Robin Murphy wrote:
>>>> On 07/11/16 13:06, Marek Szyprowski wrote:
>>>>> When one called iommu_dma_init_domain() with size smaller than
>>>>> device's
>>>>> DMA mask, the alloc_iova() will not respect it and always assume that
>>>>> all
>>>>> IOVA addresses will be allocated from the the (base ...
>>>>> dev->dma_mask) range.
>>>> Is that actually a problem for anything?
>>> Yes, I found this issue while working on next version of ARM & ARM64
>>> DMA-mapping/IOMMU integration patchset and adapting Exynos drivers
>>> for the
>>> new IOMMU/DMA-mapping glue.
>>>
>>> Some Exynos devices (codec and camera isp) operate only on the
>>> limited (and
>>> really small: 256M for example) DMA window. They use non-standard way of
>>> addressing memory: an offset from the firmware base. However they still
>>> have
>>> 32bit DMA mask, as the firmware can be located basically everywhere
>>> in the
>>> real DMA address space, but then they can access only next 256M from
>>> that
>>> firmware base.
>> OK, that's good to know, thanks. However, I think in this case it sounds
>> like it's really the DMA mask that's the underlying problem - if those
>> blocks themselves can only drive 28 address bits, then the struct
>> devices representing them should have 28-bit DMA masks, and the
>> "firmware base" of whoever's driving the upper bits modelled with a
>> dma_pfn_offset. Even if they do have full 32-bit interfaces themselves,
>> but are constrained to segment-offset addressing internally, I still
>> think it would be tidier to represent things that way.
>>
>> At some point in dma-iommu development I did have support for DMA
>> offsets upstream of the IOMMU, and am happy to reinstate it if there's a
>> real use case (assuming you can't simply always set the firmware base to
>> 0 when using the IOMMU).
>
> That would indeed look a bit simpler, but I've already tried such approach
> and the firmware crashes when its base in real DMA address space is set to
> zero.
Ah, sadly I'm not too surprised... ;)
Having pondered it a little more, what if the firmware base is instead
set equal to the max offset, then you can have a power-of-two DMA mask
at twice that size (e.g. 512M) such that the top-down IOVA allocations
start in the right place. That would appear to achieve pretty much the
same result as this patch, but more robustly.
Incidentally, how do the init size and DMA mask end up different in the
first place? Is this another case of the "dma-ranges" info from
of_dma_configure() getting clobbered by a driver calling dma_set_mask()
later?
Robin.
>>>>> This patch fixes this issue by taking the configured address space
>>>>> size
>>>>> parameter into account (if it is smaller than the device's dma_mask).
>>>> TBH I've been pondering ripping the size stuff out of dma-iommu, as it
>>>> all stems from me originally failing to understand what
>>>> dma_32bit_pfn is
>>>> actually for. The truth is that iova_domains just don't have a size or
>>>> upper limit; however if devices with both large and small DMA masks
>>>> share a domain, then the top-down nature of the allocator means that
>>>> allocating for the less-capable devices would involve walking through
>>>> every out-of-range entry in the tree every time. Having cached32_node
>>>> based on dma_32bit_pfn just provides an optimised starting point for
>>>> searching within the smaller mask.
>>> Right, this dma_32bit_pfn was really misleading at the first glance,
>>> but then I found that this was something like end_pfn in case of
>>> dma-iommu
>>> code.
>> Yes, that was my incorrect assumption - at the time I interpreted it as
>> a de-facto upper limit which was still possible to allocate above in
>> special circumstances, which turns out to be almost entirely backwards.
>> I'd rather not bake that into the dma-iommu code any further if we can
>> avoid it (I'll try throwing an RFC together to clear up what's there
>> already).
>
> Okay.
>
> Best regards
^ permalink raw reply
* [PATCH v3 1/2] ARM: EXYNOS: Remove static mapping of SCU SFR
From: Arnd Bergmann @ 2016-11-10 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a43af947-6002-bc65-f73b-02d57a78d6cb@samsung.com>
On Thursday, November 10, 2016 6:07:54 PM CET pankaj.dubey wrote:
> On Thursday 10 November 2016 05:24 PM, Arnd Bergmann wrote:
> > On Wednesday, November 9, 2016 5:45:54 PM CET Pankaj Dubey wrote:
>
> Sorry, I missed this part and did not check with CONFIG_SMP disabled.
>
> > arch/arm/mach-exynos/pm.o: In function `exynos_enter_aftr':
> > pm.c:(.text.exynos_enter_aftr+0xec): undefined reference to `exynos_scu_enable'
> > arch/arm/mach-exynos/suspend.o: In function `exynos_pm_resume':
> > suspend.c:(.text.exynos_pm_resume+0x78): undefined reference to `exynos_scu_enable'
> >
> > Please fix. I have applied a patch locally (see below), but don't know
> > if that is the best solution. As we seem to duplicate that code across
> > several platforms, I wonder why we don't just put it into the core scu
> > implementation.
> >
>
> When I checked scu_enable declaration it is defined in
> arch/arm/include/asm/smp_scu.h as:
>
> #if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> void scu_enable(void __iomem *scu_base);
> #else
> static inline void scu_enable(void __iomem *scu_base) {}
> #endif
>
> So if CONFIG_SMP is disable then there is no sense of exynos_scu_enable
> as well. So wow about using below patch?
>
> --------------------------------------------------------
>
> Subject: [PATCH] ARM: exynos: fix build fail due to exynos_scu_enable
>
> Build failed if we disable CONFIG_SMP as shown below:
>
> arch/arm/mach-exynos/pm.o: In function `exynos_enter_aftr':
> pm.c:(.text.exynos_enter_aftr+0xec): undefined reference to
> `exynos_scu_enable'
> arch/arm/mach-exynos/suspend.o: In function `exynos_pm_resume':
> suspend.c:(.text.exynos_pm_resume+0x78): undefined reference to
> `exynos_scu_enable'
>
> Since scu_enable is defined only in case CONFIG_SMP and CONFIG_HAVE_ARM_SCU
> lets move exynos_scu_enable also under these two macros.
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/mach-exynos/common.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index fb12d11..03fdb79 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -156,7 +156,12 @@ extern void exynos_cpu_restore_register(void);
> extern void exynos_pm_central_suspend(void);
> extern int exynos_pm_central_resume(void);
> extern void exynos_enter_aftr(void);
> +#if defined(CONFIG_SMP) && defined(CONFIG_HAVE_ARM_SCU)
> extern int exynos_scu_enable(void);
> +#else
> +static inline void exynos_scu_enable(void) {}
> +#endif
Yes, I think that would work, but you can drop the CONFIG_HAVE_ARM_SCU
check because of
menuconfig ARCH_EXYNOS
....
select HAVE_ARM_SCU if SMP
...
> Of-course your idea to move it in core SCU file is also good that we
> lots of duplication in different architecture can be avoided.
>
> In that case I can think of following patch:
>
> [PATCH] ARM: scu: use SCU device node to enable SCU
>
> Many platforms are duplicating code for enabling SCU, lets add
> common code to enable SCU using SCU device node so the duplication in
> each platform can be avoided.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
That looks good too. I also checked the other callers of
scu_enable(), and we have only three classes here:
a) of_iomap: berlin, exynos, mvebu, realview, rockchip, socfpga, sti, ux500, vexpress
b) ioremap(scu_a9_get_base()): bcm63xx, bcm, hisi, zx
c) iotable_init, scu_a9_get_base(): imx, omap4, tegra, zynq
d) ioremap(constant): shmobile, spear13xx
I checked that none of the ones in category c) actually use the address early,
so we can easily change four into b).
I also think that we need to keep both a) and b) because the output of
scu_a9_get_base() might be incorrect in some chips, and not all dtb
files have an SCU in them.
If we make the common SCU setup check DT first and then fall back to
scu_a9_get_base(), that means we have covered almost all cases, unless
I'm missing a problem with that approach. It would be nice to
check spear13xx and the Cortex-A9 based mach-shmobile variants
(emev2, r8a7779, and sh73a0) to see if they could also share
that implementation.
Arnd
^ permalink raw reply
* [PATCHv2] PCI: QDF2432 32 bit config space accessors
From: Lorenzo Pieralisi @ 2016-11-10 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9_sdcoN7rjQp-R=2vKY3rECt0BC3eWGpse32o2Q4LHXg@mail.gmail.com>
On Thu, Nov 10, 2016 at 06:25:16PM +0800, Ard Biesheuvel wrote:
> On 10 November 2016 at 06:49, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, Nov 09, 2016 at 08:29:23PM +0000, Ard Biesheuvel wrote:
> >> Hi Bjorn,
> >>
> >> On 9 November 2016 at 20:06, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> > On Wed, Nov 09, 2016 at 02:25:56PM -0500, Christopher Covington wrote:
> >> >> Hi Bjorn,
> >> >>
> >> [...]
> >> >>
> >> >> We're working to add the PNP0C02 resource to future firmware, but it's
> >> >> not in the current firmware. Are dmesg and /proc/iomem from the
> >> >> current firmware interesting or should we wait for the update to file?
> >> >
> >> > Note that the ECAM space is not the only thing that should be
> >> > described via these PNP0C02 devices. *All* non-enumerable resources
> >> > should be described by the _CRS method of some ACPI device. Here's a
> >> > sample from my laptop:
> >> >
> >> > PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000)
> >> > system 00:01: [io 0x1800-0x189f] could not be reserved
> >> > system 00:01: [io 0x0800-0x087f] has been reserved
> >> > system 00:01: [io 0x0880-0x08ff] has been reserved
> >> > system 00:01: [io 0x0900-0x097f] has been reserved
> >> > system 00:01: [io 0x0980-0x09ff] has been reserved
> >> > system 00:01: [io 0x0a00-0x0a7f] has been reserved
> >> > system 00:01: [io 0x0a80-0x0aff] has been reserved
> >> > system 00:01: [io 0x0b00-0x0b7f] has been reserved
> >> > system 00:01: [io 0x0b80-0x0bff] has been reserved
> >> > system 00:01: [io 0x15e0-0x15ef] has been reserved
> >> > system 00:01: [io 0x1600-0x167f] has been reserved
> >> > system 00:01: [io 0x1640-0x165f] has been reserved
> >> > system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
> >> > system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
> >> > system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
> >> > system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
> >> > system 00:01: [mem 0xfeb00000-0xfebfffff] has been reserved
> >> > system 00:01: [mem 0xfed20000-0xfed3ffff] has been reserved
> >> > system 00:01: [mem 0xfed90000-0xfed93fff] has been reserved
> >> > system 00:01: [mem 0xf7fe0000-0xf7ffffff] has been reserved
> >> > system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
> >> >
> >> > Do you have firmware in the field that may not get updated? If so,
> >> > I'd like to see the whole solution for that firmware, including the
> >> > MCFG quirk (which tells the PCI core where the ECAM region is) and
> >> > whatever PNP0C02 quirk you figure out to actually reserve the region.
> >> >
> >> > I proposed a PNP0C02 quirk to Duc along these lines of the below. I
> >> > don't actually know if it's feasible, but it didn't look as bad as I
> >> > expected, so I'd kind of like somebody to try it out. I think you
> >> > would have to call this via a DMI hook (do you have DMI on arm64?),
> >> > maybe from pnp_init() or similar.
> >>
> >> We do have SMBIOS/DMI on arm64, but we have been successful so far not
> >> to rely on it for quirks, and we'd very much like to keep it that way.
> >>
> >> Since this ACPI _CRS method has nothing to do with SMBIOS/DMI, surely
> >> there is a better way to wire up the reservation code to the
> >> information exposed by ACPI?
> >
> > I'm open to other ways, feel free to propose one :)
> >
> > If you do a quirk, you need some way to identify the machine/firmware
> > combination, because you don't want to apply the quirk on every
> > machine. You're trying to work around a firmware issue, so you
> > probably want something tied to the firmware version. On x86, that's
> > typically done with DMI.
> >
>
> I think I misunderstood the purpose of the example: that should only
> be necessary if the _CRS methods are missing from the firmware, right?
> If we update the firmware to cover all non-enumerable resources by
> such a method, we shouldn't need any such quirks at all IIUC
Yes that's correct you need a quirk to fabricate a PNP0c02 motherboard
resource if it is not present in FW.
Lorenzo
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-10 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110135721.13098-1-uwe@kleine-koenig.org>
This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
Compared to the (implict) v1, the following was changed:
- disable rtc
- change compatible to cznic,turris-omnia
The following components are working:
- WAN port
- eMMC
- UART0
- USB
- mSATA
Wireless fails to probe, didn't debug this up to now.
I already see the DSA devices (with an additional change not included here),
but sending and receiving doesn't work yet.
SFP is missing as I cannot test it. UART1 is untested, but I'd be
surprised if it didn't work.
IMHO it makes sense to add the current state and fix the remaining stuff
incrementally.
Best regards
Uwe
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 257 ++++++++++++++++++++++++++
2 files changed, 258 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..f1d3b9ff257e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
+ armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 000000000000..28e45d816120
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,257 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-K?nig <uwe@kleine-koenig.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+ model = "Turris Omnia";
+ compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1024 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+ internal-regs {
+
+ /* USB part of the eSATA/USB 2.0 port */
+ usb at 58000 {
+ status = "okay";
+ };
+
+ rtc at a3800 {
+ /*
+ * There are several errata for this device
+ * still unimplemented. Without some love it only reports
+ * 2016-12-19 22:00:24. So disable for now.
+ */
+ status = "disabled";
+ };
+
+ sata at a8000 {
+ status = "okay";
+ };
+
+ sdhci at d8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhci_pins>;
+ status = "okay";
+
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ };
+
+ usb3 at f0000 {
+ status = "okay";
+ };
+
+ usb3 at f8000 {
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+
+ pcie at 1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 2,0 {
+ /* Port 2, Lane 0 */
+ status = "okay";
+ };
+
+ pcie at 3,0 {
+ /* Port 3, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
+
+ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+ð1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* WAN port */
+ð2 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ i2cmux at 70 {
+ compatible = "nxp,pca9547";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ status = "okay";
+
+ i2c at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+
+ /* STM32F0 at address 0x2a */
+ /* leds device at address 0x2b */
+
+ eeprom at 54 {
+ /* holds configuration about RAM, evaluated by bootloader */
+ compatible = "at,24c64";
+ reg = <0x54>;
+ };
+ };
+
+ i2c at 5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ /* ATSHA204A at address 0x64 */
+ };
+
+ i2c at 6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ /* exposed on pin header */
+ };
+ };
+};
+
+&mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ status = "okay";
+
+ phy1: phy at 1 {
+ status = "okay";
+ compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+
+ /* There is a Switch (MV88E7176) at address 0x10 */
+};
+
+&pinctrl {
+ spi0cs1_pins: spi0-pins-0cs1 {
+ marvell,pins = "mpp26";
+ marvell,function = "spi0";
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+ status = "okay";
+
+ spi-nor at 0 {
+ compatible = "spansion,s25fl164k", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+
+ partition at 0 {
+ reg = <0x0 0x00100000>;
+ label = "U-Boot";
+ };
+
+ partition at 1 {
+ reg = <0x00100000 0x00700000>;
+ label = "Rescue system";
+ };
+ };
+
+ /* @1 is on pin header */
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "okay";
+};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Uwe Kleine-König @ 2016-11-10 13:57 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..ae9fce9fed03 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -67,6 +67,7 @@ creative Creative Technology Ltd
crystalfontz Crystalfontz America, Inc.
cubietech Cubietech, Ltd.
cypress Cypress Semiconductor Corporation
+cznic CZ.NIC, z.s.p.o.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
--
2.10.2
^ permalink raw reply related
* PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-10 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2941e6f-d277-a68d-2837-00b628dd3be7@redhat.com>
Hi,
On 11/10/2016 02:04 PM, Hans de Goede wrote:
> Hi,
>
> On 10-11-16 13:56, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/10/2016 09:49 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 09-11-16 21:45, Jacek Anaszewski wrote:
>>>> Hi Tony,
>>>>
>>>> On 11/09/2016 08:23 PM, Tony Lindgren wrote:
>>>>> Hi,
>>>>>
>>>>> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
>>>>> the sysfs brightness attr for changes.") breaks runtime PM for me.
>>>>>
>>>>> On my omap dm3730 based test system, idle power consumption is over 70
>>>>> times higher now with this patch! It goes from about 6mW for the core
>>>>> system to over 440mW during idle meaning there's some busy timer now
>>>>> active.
>>>>>
>>>>> Reverting this patch fixes the issue. Any ideas?
>>>>
>>>> Thanks for the report. This is probably caused by
>>>> sysfs_notify_dirent().
>>>> I'm afraid that we can't keep this feature in the current shape.
>>>> Hans, I'm dropping the patch. We probably will have to delegate this
>>>> call to a workqueue task. Think about use cases when the LED is blinked
>>>> with high frequency e.g. from ledtrig-disk.c.
>>>
>>> sysfs_notify_dirent() already uses a workqueue, here is the actual
>>> implementation of it (from fs/kernfs/file.c) :
>>>
>>> void kernfs_notify(struct kernfs_node *kn)
>>> {
>>> static DECLARE_WORK(kernfs_notify_work, kernfs_notify_workfn);
>>> unsigned long flags;
>>>
>>> if (WARN_ON(kernfs_type(kn) != KERNFS_FILE))
>>> return;
>>>
>>> spin_lock_irqsave(&kernfs_notify_lock, flags);
>>> if (!kn->attr.notify_next) {
>>> kernfs_get(kn);
>>> kn->attr.notify_next = kernfs_notify_list;
>>> kernfs_notify_list = kn;
>>> schedule_work(&kernfs_notify_work);
>>> }
>>> spin_unlock_irqrestore(&kernfs_notify_lock, flags);
>>> }
>>
>> Indeed. As a next step of this investigation Tony could disable
>> particular calls made in kernfs_notify_workfn to check what
>> exactly causes excessive power consumption.
>>
>>> So using a workqueue is not going to help. Note that I already
>>> feared this, which is why my initial implementation only called
>>> sysfs_notify_dirent() for user initiated changes and not for
>>> triggers / blinking.
>>
>> AFAIR there were no calls to led_notify_brightness_change() in
>> the initial implementation and it was entirely predestined for
>> being called by LED class drivers on brightness changes made
>> by firmware.
>>
>>> I think we may need to reconsider what getting the brightness
>>> sysfs atrribute actually returns. Currently when a LED is
>>> blinking it will return 0 resp. the actual brightness depending
>>> on when in the blink cycle the user reads the brightness
>>> sysfs atrribute.
>>>
>>> So a user can do "echo 128 > brightness && cat brightness" and
>>> get out 0, or 128, depending purely on timing.
>>>
>>> This seems to contradict what Documentation/ABI/testing/sysfs-class-led
>>> has to say:
>>>
>>> What: /sys/class/leds/<led>/brightness
>>> Date: March 2006
>>> KernelVersion: 2.6.17
>>> Contact: Richard Purdie <rpurdie@rpsys.net>
>>> Description:
>>> Set the brightness of the LED. Most LEDs don't
>>> have hardware brightness support, so will just be turned
>>> on for
>>> non-zero brightness settings. The value is between 0 and
>>> /sys/class/leds/<led>/max_brightness.
>>>
>>> Writing 0 to this file clears active trigger.
>>>
>>> Writing non-zero to this file while trigger is active
>>> changes the
>>> top brightness trigger is going to use.
>>>
>>> Even though it only talks about writing, the logical thing would be for
>>> reading to be the exact opposite of writing, so we would get:
>>>
>>> Reading from this file while a trigger is active returns
>>> the
>>> top brightness trigger is going to use.
>>>
>>> The current docs say not about (sw) blinking, but that should be treated
>>> just
>>> like a trigger IMHO.
>>
>> You'r right, we should describe the semantics on reading, but it would
>> have to be as follows:
>>
>> Reading from this file returns LED brightness at given moment, i.e.
>> even though LED class device brightness setting is greater than 0, the
>> momentary brightness can be 0 if the readout occurred during low phase
>> of blink cycle.
>
> Why would it need to read like this, because this is the current behavior ?
We have led_update_brightness() which was introduced long time ago and
is used in brightness_show(). Note that if LED controller changed
actual LED brightness e.g. due to battery voltage dropping below
certain threshold, we wouldn't be able to find it out otherwise
(except if we added separate sysfs file for that).
>
> I doubt anyone is relying on this current behavior because it is really
> unpredictable which value one can get.
>
> I believe it would be better to change the read semantics to follow
> the write semantics, this would be much more consistent.
>
> Making the read behavior match the write behavior should be easy I would
> be happy to write a patch for this.
Let's better agree on the description of the current semantics.
It has been around for a long time.
>>> If we can get consensus on what the read behavior for the brightness
>>> attribute
>>> should be, then I think that a better poll() behavior will automatically
>>> follow
>>> from that.
>>
>> It seems that we should get back to your initial approach. i.e. only
>> brightness changes caused by hardware should be reported.
>
> Ok, if you really want to keep the read behavior as is, I can provide
> an updated patch for this.
Yes please.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] arm64: dts: Add ARM PMU node for exynos7
From: Robin Murphy @ 2016-11-10 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478748643-3081-1-git-send-email-alim.akhtar@samsung.com>
Hi Alim,
On 10/11/16 03:30, Alim Akhtar wrote:
> This patch adds ARM Performance Monitor Unit dt node for exynos7.
> PMU provides various statistics on the operation of the CPU and
> memory system at runtime, which are very useful when debugging or
> profiling code. This enables the same.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index e0d0d01..53ce4be 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -472,6 +472,14 @@
> status = "disabled";
> };
>
> + arm-pmu {
> + compatible = "arm,cortex-a57-pmu", "arm,armv8-pmuv3";
> + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
Per Documentation/devicetree/bindings/arm/pmu.txt there should also be
an "interrupt-affinity" property describing which SPI belongs to which core.
Robin.
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupts = <GIC_PPI 13
>
^ permalink raw reply
* [PATCH 0/2] mmc: allow mmc_alloc_host() and tmio_mmc_host_alloc()
From: Greg Kroah-Hartman @ 2016-11-10 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478784263-18777-1-git-send-email-yamada.masahiro@socionext.com>
On Thu, Nov 10, 2016 at 10:24:21PM +0900, Masahiro Yamada wrote:
>
> sdhci_alloc_host() returns an error pointer when it fails.
> but mmc_alloc_host() cannot.
>
> This series allow to propagate a proper error code
> when host-allocation fails.
Why? What can we really do about the error except give up? Why does
having a explicit error value make any difference to the caller, they
can't do anything different, right?
I suggest just leaving it as-is, it's simple, and you don't have to mess
with PTR_ERR() anywhere.
thanks,
greg k-h
^ 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