* [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Kukjin Kim @ 2016-11-18 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479453418-25314-1-git-send-email-krzk@kernel.org>
2016. 11. 18. 16:16 Krzysztof Kozlowski <krzk@kernel.org> wrote:
> All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
> 200 Hz. Unfortunately in case of multiplatform image this affects also
> other platforms when Exynos is enabled.
>
> This looks like an very old legacy code, dating back to initial
> upstreaming of S3C24xx. Probably it was required for s3c24xx timer
> driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
> unused plat-samsung/time.c").
>
> Since then, this fixed 200 Hz spread everywhere, including out-of-tree
> Samsung kernels (SoC vendor's and Tizen's). I believe this choice
> was rather an effect of coincidence instead of conscious choice.
>
> Exynos uses its own MCT or arch timer and can work with all HZ values.
> Older platforms use newer Samsung PWM timer driver which should handle
> down to 100 Hz.
>
> Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
> A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
> other values.
>
> Reported-by: Lee Jones <lee.jones@linaro.org>
> [Dropping 200_HZ from S3C/S5P suggested by Arnd]
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Kukjin Kim <kgene@kernel.org>
Acked-by: Kukjin Kim <kgene@kernel.org>
> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> Tested on Exynos5422 and Exynos5800 (by Javier). It would be
> appreciated if anyone could test it on S3C24xx or S5PV210.
>
> Changes since v1:
> 1. Add Javier's tested-by.
> 2. Drop HZ_FIXED also from ARCH_S5PV210 and ARCH_S3C24XX after Arnd
> suggestions and analysis.
> ---
> arch/arm/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5d529fdffab..ced2e08a9d08 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1496,8 +1496,7 @@ source kernel/Kconfig.preempt
>
> config HZ_FIXED
> int
> - default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
> - ARCH_S5PV210 || ARCH_EXYNOS4
> + default 200 if ARCH_EBSA110
> default 128 if SOC_AT91RM9200
> default 0
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 3/4] spi: spi-fsl-dspi: Fix continuous selection format
From: maitysanchayan at gmail.com @ 2016-11-18 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1c4a3f3eac6d4e7378971431bd5f595@agner.ch>
Hello Stefan,
On 16-11-17 17:07:24, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Current DMA implementation was not handling the continuous selection
> > format viz. SPI chip select would be deasserted even between sequential
> > serial transfers. Use the cs_change variable and correctly set or
> > reset the CONT bit accordingly for case where peripherals require
> > the chip select to be asserted between sequential transfers.
> >
> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> > ---
> > drivers/spi/spi-fsl-dspi.c | 13 ++++++++++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index aee8c88..164e2e1 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -258,9 +258,16 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
> > }
> >
> > val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
> > - dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > - SPI_PUSHR_PCS(dspi->cs) |
> > - SPI_PUSHR_CTAS(0);
> > + if (dspi->cs_change) {
> > + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > + SPI_PUSHR_PCS(dspi->cs) |
> > + SPI_PUSHR_CTAS(0);
> > + } else {
> > + dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> > + SPI_PUSHR_PCS(dspi->cs) |
> > + SPI_PUSHR_CTAS(0) |
> > + SPI_PUSHR_CONT;
> > + }
>
> How about:
>
>
> dspi->dma->tx_dma_buf[i] = SPI_PUSHR_TXDATA(val) |
> SPI_PUSHR_PCS(dspi->cs) |
> SPI_PUSHR_CTAS(0);
>
> + if (dspi->cs_change)
> + dspi->dma->tx_dma_buf[i] |= SPI_PUSHR_CONT;
>
>
> Avoids code duplication...
Agreed. It's much better. Should be !dspi->cs_change though.
Will include it in next iteration.
Thanks & Regards,
Sanchayan.
>
> --
> Stefan
>
>
>
> > dspi->tx += tx_word + 1;
> >
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
^ permalink raw reply
* [PATCH 2/4] spi: spi-fsl-dspi: Fix incorrect DMA setup
From: maitysanchayan at gmail.com @ 2016-11-18 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc8d9b808b99d3b217361df6fa8853ea@agner.ch>
On 16-11-17 17:03:19, Stefan Agner wrote:
> On 2016-11-17 04:16, Sanchayan Maity wrote:
> > Currently dmaengine_prep_slave_single was being called with length
> > set to the complete DMA buffer size. This resulted in unwanted bytes
> > being transferred to the SPI register leading to clock and MOSI lines
> > having unwanted data even after chip select got deasserted and the
> > required bytes having been transferred.
> >
> > Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
> > ---
> > drivers/spi/spi-fsl-dspi.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index b1ee1f5..aee8c88 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -265,7 +265,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
> >
> > dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
> > dma->tx_dma_phys,
> > - DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
> > + dma->curr_xfer_len *
> > + DMA_SLAVE_BUSWIDTH_4_BYTES /
> > + (tx_word ? 2 : 1),
> > + DMA_MEM_TO_DEV,
>
> Hm, this is getting ridiculous, I think we convert curr_xfer_len from
> bytes to DMA transfers in almost every use.
>
> Can we make it be transfer length in actual 4 byte transfers? We then
> probably have to convert it to bytes once to subtract from
> curr_remaining_bytes, but I think it would simplify code overall...
Will the below be acceptable fix?
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 41422cd..db7f091 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -217,15 +217,13 @@ static void dspi_rx_dma_callback(void *arg)
struct fsl_dspi *dspi = arg;
struct fsl_dspi_dma *dma = dspi->dma;
int rx_word;
- int i, len;
+ int i;
u16 d;
rx_word = is_double_byte_mode(dspi);
- len = rx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
if (!(dspi->dataflags & TRAN_STATE_RX_VOID)) {
- for (i = 0; i < len; i++) {
+ for (i = 0; i < dma->curr_xfer_len; i++) {
d = dspi->dma->rx_dma_buf[i];
rx_word ? (*(u16 *)dspi->rx = d) :
(*(u8 *)dspi->rx = d);
@@ -242,14 +240,12 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
struct device *dev = &dspi->pdev->dev;
int time_left;
int tx_word;
- int i, len;
+ int i;
u16 val;
tx_word = is_double_byte_mode(dspi);
- len = tx_word ? (dma->curr_xfer_len / 2) : dma->curr_xfer_len;
-
- for (i = 0; i < len - 1; i++) {
+ for (i = 0; i < dma->curr_xfer_len - 1; i++) {
val = tx_word ? *(u16 *) dspi->tx : *(u8 *) dspi->tx;
dspi->dma->tx_dma_buf[i] =
SPI_PUSHR_TXDATA(val) | SPI_PUSHR_PCS(dspi->cs) |
@@ -267,7 +263,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
dma->tx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_MEM_TO_DEV,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_MEM_TO_DEV,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->tx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -283,7 +281,9 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
dma->rx_dma_phys,
- DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
+ dma->curr_xfer_len *
+ DMA_SLAVE_BUSWIDTH_4_BYTES,
+ DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!dma->rx_desc) {
dev_err(dev, "Not able to get desc for DMA xfer\n");
@@ -330,17 +330,17 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
struct device *dev = &dspi->pdev->dev;
int curr_remaining_bytes;
int bytes_per_buffer;
- int tx_word;
+ int tx_word = 1;
int ret = 0;
- tx_word = is_double_byte_mode(dspi);
+ if (is_double_byte_mode(dspi))
+ tx_word = 2;
curr_remaining_bytes = dspi->len;
+ bytes_per_buffer = DSPI_DMA_BUFSIZE / DSPI_FIFO_SIZE;
while (curr_remaining_bytes) {
/* Check if current transfer fits the DMA buffer */
- dma->curr_xfer_len = curr_remaining_bytes;
- bytes_per_buffer = DSPI_DMA_BUFSIZE /
- (DSPI_FIFO_SIZE / (tx_word ? 2 : 1));
- if (curr_remaining_bytes > bytes_per_buffer)
+ dma->curr_xfer_len = curr_remaining_bytes / tx_word;
+ if (dma->curr_xfer_len > bytes_per_buffer)
dma->curr_xfer_len = bytes_per_buffer;
ret = dspi_next_xfer_dma_submit(dspi);
@@ -349,7 +349,7 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
goto exit;
} else {
- curr_remaining_bytes -= dma->curr_xfer_len;
+ curr_remaining_bytes -= dma->curr_xfer_len * tx_word;
if (curr_remaining_bytes < 0)
curr_remaining_bytes = 0;
dspi->len = curr_remaining_bytes;
Regards,
Sanchayan.
>
> --
> Stefan
>
>
> > DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> > if (!dma->tx_desc) {
> > dev_err(dev, "Not able to get desc for DMA xfer\n");
> > @@ -281,7 +284,10 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
> >
> > dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
> > dma->rx_dma_phys,
> > - DSPI_DMA_BUFSIZE, DMA_DEV_TO_MEM,
> > + dma->curr_xfer_len *
> > + DMA_SLAVE_BUSWIDTH_4_BYTES /
> > + (tx_word ? 2 : 1),
> > + DMA_DEV_TO_MEM,
> > DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> > if (!dma->rx_desc) {
> > dev_err(dev, "Not able to get desc for DMA xfer\n");
^ permalink raw reply related
* System/uncore PMUs and unit aggregation
From: Anurup M @ 2016-11-18 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117181708.GT22855@arm.com>
Thanks you Mark and Will to initiate this discussion.
On Thursday 17 November 2016 11:47 PM, Will Deacon wrote:
> Hi all,
>
> We currently have support for three arm64 system PMUs in flight:
>
> [Cavium ThunderX] http://lkml.kernel.org/r/cover.1477741719.git.jglauber at cavium.com
> [Hisilicon Hip0x] http://lkml.kernel.org/r/1478151727-20250-1-git-send-email-anurup.m at huawei.com
> [Qualcomm L2] http://lkml.kernel.org/r/1477687813-11412-1-git-send-email-nleeder at codeaurora.org
>
> Each of which have to deal with multiple underlying hardware units in one
> way or another. Mark and I recently expressed a desire to expose these
> units to userspace as individual PMU instances, since this can allow:
>
> * Fine-grained control of events from userspace, when you want to see
> individual numbers as opposed to a summed total
>
> * Potentially ease migration to new SoC revisions, where the units
> are laid out slightly differently
>
> * Easier handling of cases where the units aren't quite identical
>
> however, this received pushback from all of the patch authors, so there's
> clearly a problem with this approach. I'm hoping we can try to resolve
> this here.
>
> Speaking to Mark earlier today, we came up with the following rough rules
> for drivers that present multiple hardware units as a single PMU:
>
> 1. If the units share some part of the programming interface (e.g. control
> registers or interrupts), then they must be handled by the same PMU.
> Otherwise, they should be treated independently as separate PMU
> instances.
The Hisilicon Hip0x chip has units like L3 cache, Miscellaneous nodes,
DDR controller etc.
There are such units in multiple CPU die's in the chip.
The L3 cache is further divided as banks which have separate set of
interface (control registers, interrupts etc..).
As per the suggestion, each L3 cache banks will be exposed as a
individual PMU instance.
So for e.g. in a board using Hip0x chip with 2 sockets and each socket
consists of 2 CPU die,
There will be a total of 16 L3 cache PMU's which will be exposed.
My doubt here is
Each L3 cache PMU has total 22 statistics events. So if registered as a
separate PMU, will it not
create multiple entries (with same event names) in event listing for
multiple L3 cache PMU's.
Is there a way to avoid this? or this is acceptable?
Just a thought, If we can group them as single PMU and add a config
parameter in the event listing to
identify the L3 cache bank(sub unit). e.g: event name will appear as
"hisi_l3c2/read_allocate,bank=?/".
And user can choose count from bank 0x01 as -e
"hisi_l3c2/read_allocate,bank=0x01/".
And for aggregate count, bank=0xff.
Does it over complicate? Please share your comments.
> 2. If the units are handled by the same PMU, then care must be taken to
> handle event groups correctly. That is, if the units cannot be started
> and stopped atomically, cross-unit groups must be rejected by the
> driver. Furthermore, any cross-unit scheduling constraints must be
> honoured so that all the units targetted by a group can schedule the
> group concurrently.
>
> 3. Summing the counters across units is only permitted if the units
> can all be started and stopped atomically. Otherwise, the counters
> should be exposed individually. It's up to the driver author to
> decide what makes sense to sum.
>
> 4. Unit topology can optionally be described in sysfs (we should pick
> some standard directory naming here), and then events targetting
> specific units can have the unit identifier extracted from the topology
> encoded in some configN fields.
Does this unit topology and configN method can solve the duplicate event
listing issue? Please clarify.
> The million dollar question is: how does that fit in with the drivers I
> mentioned at the top? Is this overly restrictive, or have we missed stuff?
>
> We certainly want to allow flexibility in the way in which the drivers
> talk to the hardware, but given that these decisions directly affect the
> user ABI, some consistent ground rules are required.
>
> For Cavium ThunderX, it's not clear whether or not the individual units
> could be expressed as separate PMUs, or whether they're caught by one of
> the rules above. The Qualcomm L2 looks like it's doing the right thing
> and we can't quite work out what the Hisilicon Hip0x topology looks like,
> since the interaction with djtag is confusing.
The djtag is a component which connects with some other components in
the SoC by Debug Bus.
The registers in components like L3 cache, MN etc are accessed only via
djtag.
Please share comments about the confusion. We can discuss to clear them.
Thanks,
Anurup
> If the driver authors (on To:) could shed some light on this, then that
> would be much appreciated!
>
> Thanks,
>
> Will
^ permalink raw reply
* [PATCHv3 1/6] lib/Kconfig.debug: Add ARCH_HAS_DEBUG_VIRTUAL
From: Ingo Molnar @ 2016-11-18 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479431816-5028-2-git-send-email-labbott@redhat.com>
* Laura Abbott <labbott@redhat.com> wrote:
>
> DEBUG_VIRTUAL currently depends on DEBUG_KERNEL && X86. arm64 is getting
> the same support. Rather than add a list of architectures, switch this
> to ARCH_HAS_DEBUG_VIRTUAL and let architectures select it as
> appropriate.
>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v3: No change, x86 maintainers please ack if you are okay with this.
> ---
> arch/x86/Kconfig | 1 +
> lib/Kconfig.debug | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index bada636..f533321 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -23,6 +23,7 @@ config X86
> select ARCH_CLOCKSOURCE_DATA
> select ARCH_DISCARD_MEMBLOCK
> select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
> + select ARCH_HAS_DEBUG_VIRTUAL
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> select ARCH_HAS_FAST_MULTIPLIER
Acked-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
^ permalink raw reply
* [GIT PULL] Integrator DTS and defconfig changes
From: Linus Walleij @ 2016-11-18 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118072506.GC1785@localhost>
On Fri, Nov 18, 2016 at 8:25 AM, Olof Johansson <olof@lixom.net> wrote:
> I also sympathize that it's extra annoying having to split just three
> patches across two branches. So, if it's easier we can just cherry-pick
> apart the patches here across the branches (your comment about next
> coverage makes me suspect you have no direct downstream users of this
> branch). If that's OK, let me know and I'll do that tomorrow.
It's fine to cherry-pick, I can also send two separate branches (or
just 2+1 stand-alone patches).
Any way you like it :) just tell me what to do, all I want is to get this
in for v4.10.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 REPOST 8/9] arm: add sysfs cpu_capacity attribute
From: Juri Lelli @ 2016-11-18 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103052842.GA16920@e106622-lin>
Hi Russell,
On 03/11/16 05:28, Juri Lelli wrote:
> Hi,
>
> apologies for the delay in replying, but I'm attending Linux Plumbers
> this week.
>
> On 30/10/16 20:45, Russell King - ARM Linux wrote:
> > On Mon, Oct 17, 2016 at 04:46:49PM +0100, Juri Lelli wrote:
[...]
>
> I should have addressed your comments with the updated version below. If
> it looks good to you I'll superseed the old version with this new one.
>
The two updated patches are still listed as incoming in your system.
Do you think we will be able to queue them for 4.10? IMHO, it would be
good to have all pieces in together at once (Catalin and Sudeep already
queued their respective bits).
Thanks a lot.
Best,
- Juri
^ permalink raw reply
* [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: kernel at martin.sperl.org @ 2016-11-18 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117151019.GA3115@localhost.localdomain>
> On 17.11.2016, at 16:10, Eduardo Valentin <edubezval@gmail.com> wrote:
>
> Hello Martin,
>
> On Thu, Nov 17, 2016 at 10:51:33AM +0100, Martin Sperl wrote:
>>
>>
>> On 17.11.2016 03:11, Eduardo Valentin wrote:
>>> Hey Martin,
>>>
>>> Very sorry for the late feedback. Not so sure if this one got queued
>>> already or not. Anyways, just minor questions as follows:
>>>
>>> On Wed, Nov 02, 2016 at 10:18:22AM +0000, kernel at martin.sperl.org wrote:
>>>> From: Martin Sperl <kernel@martin.sperl.org>
>>>>
>>>> Add basic thermal driver for bcm2835 SOC.
>>>>
>>>> This driver currently relies on the firmware setting up the
>>>> tsense HW block and does not set it up itself.
>>>>
>>>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>>>> Acked-by: Eric Anholt <eric@anholt.net>
>>>> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>
>> ...
>>>> +static int bcm2835_thermal_adc2temp(
>>>> + const struct bcm2835_thermal_info *info, u32 adc)
>>>> +{
>>>> + return info->offset + (adc * info->slope);
>>>
>>> Any specific reason we cannot use thermal_zone_params->slope and
>>> thermal_zone_params->offset?
>>
>> You could - the patch was just rebased to 4.9 and those slope and
>> offset just got merged during this cycle.
>>
>> Do we really need to modify it - the patch has been around since 4.6.
>>
>>>> +
>>>> +static int bcm2835_thermal_get_trip_temp(
>>>> + struct thermal_zone_device *tz, int trip, int *temp)
>>>> +{
>>>> + struct bcm2835_thermal_data *data = tz->devdata;
>>>> + u32 val = readl(data->regs + BCM2835_TS_TSENSCTL);
>>>> +
>>>> + /* get the THOLD bits */
>>>> + val &= BCM2835_TS_TSENSCTL_THOLD_MASK;
>>>> + val >>= BCM2835_TS_TSENSCTL_THOLD_SHIFT;
>>>> +
>>>> + /* if it is zero then use the info value */
>>>> + if (val)
>>>
>>> Is this a read only register or is this driver supposed to program it?
>>> In which scenario it would be 0? Can this be added as comments?
>>
>> It is RW, but the Firmware typically sets up the thermal device with the
>> correct values already - this is just a fallback.
>
> OK, but how do you differentiate from a buggy firmware or misconfigured
> hardware? How do you know if the firmware is supposed to be loaded and
> ready? There is no firmware loading in this driver. Also, there is no
> dependency with a driver that loads firmware, or at least, I missed it.
>
The way that firmware works on the RPI is quite different from most others I guess.
in principle you got 2 different CPUs on the bcm2835:
* ARM, which runs the linux instance
* VideoCore 4, which runs the firmware (loading from SD initially) and
then booting the ARM.
So this Firmware on VC4 is the one that I am talking about.
Without the working firmware linux can not boot on arm.
As of now he firmware is also checking temperature of the SOC itself and
if it finds ?critical? temperatures it will clock down ARM and the GPU.
Hope that this explains the ?firmware? on bcm2835.
>>
>>>> +static int bcm2835_thermal_get_temp(struct thermal_zone_device *tz,
>>>> + int *temp)
>>>> +{
>>>> + struct bcm2835_thermal_data *data = tz->devdata;
>>>> + u32 val = readl(data->regs + BCM2835_TS_TSENSSTAT);
>>>> +
>>>> + if (!(val & BCM2835_TS_TSENSSTAT_VALID))
>>>
>>> What cases you would get the valid bit not set? Do you need to wait for
>>> the conversion to finish?
>>
>> I guess: if you have just enabled the HW-block (which the FW does much
>> in advance) and start to read the value immediately (before the first sample
>> period has finished), then this will not be valid.
>>
>
> Then again, how does this driver make sure the initialization procedure
> is correct, and that by the time it is using the hardware, the hardware
> is in a sane state?
>
> Back to the original question, does it mean the hardware is in
> some sort of continuous ADC conversion mode or reading the temperature
> requires specific steps to get the conversion done, and therefore you
> are checking the valid bit here?
As far as I understand the conversion is continuous (as soon as the HW is
configured). This case is there primarily to handle the situation where
we initialize the HW ourselves (see line 226 and below), and we immediately
want to read the ADC value before the first conversion is finished.
The above mentioned ?configuration if not running? reflect the values that
the FW is currently setting. We should not change those values as long as the
Firmware is also reading the temperature on its own.
>
>> So do you need another version of the patchset that uses that new API?
>
> I think the API usage is change that can be done together with
> clarification for the above questions too: on hardware state,
> firmware loading, maybe a master driver dependency, and the ADC
> conversion sequence, which are not well clear to me on this driver. As long as
> this is clarified and documented in the code (can be simple comments so
> it is clear to whoever reads in the future), then I would be OK with
> this driver.
So how do you want this to get ?documented? in the driver?
The setup and Firmware is a generic feature of the SOC, so if we would put
some clarifications in this driver, then we would need to put it in every
bcm283X driver (which seems unreasonable).
Thanks,
Martin
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Auger Eric @ 2016-11-18 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <HE1PR0401MB2556607F41972B84F8A48E869AB00@HE1PR0401MB2556.eurprd04.prod.outlook.com>
Hi Bharat,
On 18/11/2016 06:34, Bharat Bhushan wrote:
> Hi Eric,
>
> Have you sent out QEMU side patches based on this new approach? In case I missed please point me the patches?
Upstream QEMU works fine for PCIe/MSI passthrough on ARM since mach virt
address space does not collide with fixed MSI region.
Thanks
Eric
>
> Thanks
> -Bharat
>
>> -----Original Message-----
>> From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
>> bounces at lists.linux-foundation.org] On Behalf Of Eric Auger
>> Sent: Tuesday, November 15, 2016 6:39 PM
>> To: eric.auger at redhat.com; eric.auger.pro at gmail.com;
>> christoffer.dall at linaro.org; marc.zyngier at arm.com;
>> robin.murphy at arm.com; alex.williamson at redhat.com;
>> will.deacon at arm.com; joro at 8bytes.org; tglx at linutronix.de;
>> jason at lakedaemon.net; linux-arm-kernel at lists.infradead.org
>> Cc: drjones at redhat.com; kvm at vger.kernel.org; punit.agrawal at arm.com;
>> linux-kernel at vger.kernel.org; iommu at lists.linux-foundation.org;
>> pranav.sawargaonkar at gmail.com
>> Subject: [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and
>> IOVA reserved regions
>>
>> Following LPC discussions, we now report reserved regions through iommu-
>> group sysfs reserved_regions attribute file.
>>
>> Reserved regions are populated through the IOMMU get_resv_region
>> callback (former get_dm_regions), now implemented by amd-iommu, intel-
>> iommu and arm-smmu.
>>
>> The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an
>> IOMMU_RESV_NOMAP reserved region.
>>
>> arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and 1MB
>> large) and the PCI host bridge windows.
>>
>> The series integrates a not officially posted patch from Robin:
>> "iommu/dma: Allow MSI-only cookies".
>>
>> This series currently does not address IRQ safety assessment.
>>
>> Best Regards
>>
>> Eric
>>
>> Git: complete series available at
>> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
>>
>> History:
>> RFC v2 -> v3:
>> - switch to an iommu-group sysfs API
>> - use new dummy allocator provided by Robin
>> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>> the reserved regions
>> - at the moment ARM MSI base address/size is left unchanged compared
>> to v2
>> - we currently report reserved regions and not usable IOVA regions as
>> requested by Alex
>>
>> RFC v1 -> v2:
>> - fix intel_add_reserved_regions
>> - add mutex lock/unlock in vfio_iommu_type1
>>
>>
>> Eric Auger (10):
>> iommu/dma: Allow MSI-only cookies
>> iommu: Rename iommu_dm_regions into iommu_resv_regions
>> iommu: Add new reserved IOMMU attributes
>> iommu: iommu_alloc_resv_region
>> iommu: Do not map reserved regions
>> iommu: iommu_get_group_resv_regions
>> iommu: Implement reserved_regions iommu-group sysfs file
>> iommu/vt-d: Implement reserved region get/put callbacks
>> iommu/arm-smmu: Implement reserved region get/put callbacks
>> vfio/type1: Get MSI cookie
>>
>> drivers/iommu/amd_iommu.c | 20 +++---
>> drivers/iommu/arm-smmu.c | 52 +++++++++++++++
>> drivers/iommu/dma-iommu.c | 116 ++++++++++++++++++++++++++----
>> ---
>> drivers/iommu/intel-iommu.c | 50 ++++++++++----
>> drivers/iommu/iommu.c | 141
>> ++++++++++++++++++++++++++++++++++++----
>> drivers/vfio/vfio_iommu_type1.c | 26 ++++++++
>> include/linux/dma-iommu.h | 7 ++
>> include/linux/iommu.h | 49 ++++++++++----
>> 8 files changed, 391 insertions(+), 70 deletions(-)
>>
>> --
>> 1.9.1
>>
>> _______________________________________________
>> iommu mailing list
>> iommu at lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v2] ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
From: Arnd Bergmann @ 2016-11-18 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479453418-25314-1-git-send-email-krzk@kernel.org>
On Friday, November 18, 2016 9:16:58 AM CET Krzysztof Kozlowski wrote:
> All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
> 200 Hz. Unfortunately in case of multiplatform image this affects also
> other platforms when Exynos is enabled.
>
> This looks like an very old legacy code, dating back to initial
> upstreaming of S3C24xx. Probably it was required for s3c24xx timer
> driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
> unused plat-samsung/time.c").
>
> Since then, this fixed 200 Hz spread everywhere, including out-of-tree
> Samsung kernels (SoC vendor's and Tizen's). I believe this choice
> was rather an effect of coincidence instead of conscious choice.
>
> Exynos uses its own MCT or arch timer and can work with all HZ values.
> Older platforms use newer Samsung PWM timer driver which should handle
> down to 100 Hz.
>
> Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
> A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
> other values.
>
> Reported-by: Lee Jones <lee.jones@linaro.org>
> [Dropping 200_HZ from S3C/S5P suggested by Arnd]
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Maybe add a paragraph about the specific problem:
"On s3c24xx, the PWM counter is only 16 bit wide, and with the
typical 12MHz input clock that overflows every 5.5ms. This works
with HZ=200 or higher but not with HZ=100 which needs a 10ms
interval between ticks. On Later chips (S3C64xx, S5P and EXYNOS),
the counter is 32 bits and does not have this problem.
The new samsung_pwm_timer driver solves the problem by scaling
the input clock by a factor of 50 on s3c24xx, which makes it
less accurate but allows HZ=100 as well as CONFIG_NO_HZ with
fewer wakeups".
Arnd
^ permalink raw reply
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Thomas Petazzoni @ 2016-11-18 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117230830.31047-10-gregory.clement@free-electrons.com>
Hello,
On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
> - soc {
> + /* The following unit address is composed of the target
> + * value (bit [40-47]), attributes value (bits [32-39],
> + * and the address value in the window memory: [0-31].
> + */
> + soc at f00100000000 {
Where is this value coming from? Why does the soc node needs to have a
unit address? It doesn't have a 'reg' property if I remember correctly.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
From: Thomas Petazzoni @ 2016-11-18 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117230830.31047-7-gregory.clement@free-electrons.com>
Hello,
On Fri, 18 Nov 2016 00:08:23 +0100, Gregory CLEMENT wrote:
> - crypto_sram0: sa-sram0 {
> + /* The following unit addresses (for sa-sram) are composed of
> + * the target value (bit [40-47]), attributes value (bits
> + * [32-39], and the address value in the window memory: [0-31].
> + */
The "address value in the window memory" part doesn't make a lot of
sense. Maybe:
"The following unit addresses are composed of the window target ID
(bits 40-47), the window target attributes (bits 32-39) and the offset
inside the window."
Also, the comment formatting is not compliant with the coding style,
should be:
/*
* ...
* ...
*/
But do we really want this comment above each node? Couldn't we instead
add this explanation in the mvebu-mbus.txt DT binding?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Gregory CLEMENT @ 2016-11-18 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118095455.00bfe007@free-electrons.com>
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 00:08:26 +0100, Gregory CLEMENT wrote:
>
>> - soc {
>> + /* The following unit address is composed of the target
>> + * value (bit [40-47]), attributes value (bits [32-39],
>> + * and the address value in the window memory: [0-31].
>> + */
>> + soc at f00100000000 {
>
> Where is this value coming from? Why does the soc node needs to have a
It cames from the dts files.
> unit address? It doesn't have a 'reg' property if I remember
> correctly.
But it has a range property.
Gregory
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Thomas Petazzoni @ 2016-11-18 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d1htb1qr.fsf@free-electrons.com>
Hello,
On Fri, 18 Nov 2016 10:01:32 +0100, Gregory CLEMENT wrote:
> >> + soc at f00100000000 {
> >
> > Where is this value coming from? Why does the soc node needs to have a
>
> It cames from the dts files.
Where?
> > unit address? It doesn't have a 'reg' property if I remember
> > correctly.
>
> But it has a range property.
And? There are multiple ranges, and you randomly took the first one for
the unit address of the soc node?
You realize that the ranges property is a list of ranges, and they
could be in any order? Why would you pick the base address of one of
the ranges rather than any of the others?
I believe there is simply no unit address for the soc {} node. There is
definitely one for the internal-regs {} node, but not for the soc {}
node.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins
From: Linus Walleij @ 2016-11-18 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ea02ec937a12d6ca2a2e0d8bbea5c484@theobroma-systems.com>
[Notice this reply has little to do with the patch in question: I think
it should be applied. I just want to involve some MMC/SD people here]
On Thu, Nov 17, 2016 at 9:57 PM, <klaus.goger@theobroma-systems.com> wrote:
> On 2016-11-17 10:34, Chen-Yu Tsai wrote:
>>
>> Given that MMC starts in open-drain mode and the pull-ups are required,
>> it's best to enable it for all the pin settings.
>
> It's even more complicated than that with MMC. It starts in open-drain mode
> for
> CMD during initialization but changes to push-pull afterwards. The card has
> internal pull-ups to prevent bus floating during setup and will disable them
> after switching to 4bit mode (or 8bit for eMMC when available).
> But even after switching to push-pull drivers there are states the bus would
> float and pull ups have to ensure a high level on the bus.
>
> See JESD84-A441 chapter 7.15 ff as reference.
>
> The difference between the P-bit and Z-bit is that a P-bit is actively
> driven
> to HIGH by the card respectively host output driver, while Z-bit is driven
> to
> (respectively kept) HIGH by the pull-up resistors Rcmd respectively Rdat.
>
> Enabling the pull ups on the CPU would be the right choice considering that
> most boards will not have external pull-ups. Even if they would have one,
> adding the internal in parallel would work in almost all cases and the
> increase in power consumption would be negligible.
I guess you are referring to software-controlled pull up on the pad ring of
the SoC. Nominally that should be handled by pin control like in this
patch.
It is not clear from context to me which of the lines need to be handled
like this? Just the data lines? DAT0 would be the critical line to pull up
in that case, since the others will not be used until bus switch anyways
right?
But what about CMD?
I assume CLK should always be push-pull?
Also: if the pins have an explicit Open Drain setting, should that
be used? I guess so?
Overall I think this construction is pretty common.
We essentially have two classes of connections:
- Those connecting the eMMC or even MMC/SD card directly to
the SoC. No pull-ups on the board. Here it makes sense to have:
1. A pin control default state with open drain and pull-ups
enabled for those lines
and it then needs
2. A second "4/8bit mode" that will switch these
pins to push-pull mode and turn off the pull-ups.
If the OD+pull-up state is the default we should probably
standardize a default name for the state when we kick in 4/8bit
mode from the IOS operation.
- Those connection the MMC/SD on an external slot through a
levelshifter/EMI filter. In that case I guess it is pretty much
dependent on the levelshifter or EMI thing how the lines out
of the SoC should be configured, and usually it is static so
you do not need to worry about it after boot configuration
of pins. (Mostly no bias, push-pull I think.)
I highly suspect a whole bunch of SoC drivers are not getting
this business right today. Not even in out-of-tree vendor kernels.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Arnd Bergmann @ 2016-11-18 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5825984B.3030303@hisilicon.com>
On Friday, November 11, 2016 6:07:07 PM CET zhichang.yuan wrote:
>
> I have similar idea as your PPC MMIO.
>
> We notice the prototype of {in/out()} is something like that:
>
> static inline u8 inb(unsigned long addr)
> static inline void outb(u8 value, unsigned long addr)
>
> The type of parameter 'addr' is unsigned long. For I/O space, it is big enough.
> So, could you divide this 'addr' into several bit segments? The top 8 bits is
> defined as bus index. For normal direct IO, the bus index is 0. For those bus
> device which need indirectIO or some special I/O accessors, when these devices
> are initializing, can request to allocate an unique ID to them, and register
> their own accessors to the entry which is corresponding to the ID.
Ah, have you looked at the IA64 code? It does exactly this.
For ARM64 we decided to use the same basic approach as powerpc with
a single range of virtual memory for mapping it as that somewhat
simplified all cases we knew about at the time.
> In this way, we can support multiple domains, I think.
> But I am not sure whether it is feasible, for example, are there some
> architectures/platforms had populated the top 8 bits? Do we need to request IO
> region from ioport_resource for those devices? etc...
On a 64-bit architecture, the top 32 bits of the port number are
definitely free to use for this, and 8 bits are probably sufficient.
Even on 32 bit architectures, I can't see why we'd ever need more than
16 bits worth of addressing within a domain, so using 8 bit domain
and 16 bit address leaves 8 or 40 unused bits.
Arnd
^ permalink raw reply
* [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Arnd Bergmann @ 2016-11-18 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114111111.1b753dc3@lxorguk.ukuu.org.uk>
On Monday, November 14, 2016 11:11:11 AM CET One Thousand Gnomes wrote:
> > > It's not a safe assumption for x86 at least. There are a few systems with
> > > multiple ISA busses particularly older laptops with a docking station.
> >
> > But do they have multiple ISA domains? There is no real harm in supporting
> > it, the (small) downsides I can think of are:
>
> I don't believe they x86 class ones have multiple ISA domains. But as
> I've said I don't know how the electronics in the older ThinkPad worked
> when it used two PIIX4s with some LPC or ISA stuff on each.
>
> It works in DOS and unmodified Linux so I'm pretty sure there are no
> additional domains. Likewise the various x86 schemes that route some bits
> of ISA bus off into strange places work in DOS and don't have any
> overlaps.
>
> yenta_socket handles PCI/PCMCIA bridging and routes a range of that flat
> ISA space appropriately to the card.
Right, that's what I had expected, so we still don't even
need to handle multiple ISA I/O address spaces for the
only known case of multiple ISA buses, though we may decide
to generalize the code like that anyway.
Arnd
^ permalink raw reply
* System/uncore PMUs and unit aggregation
From: Peter Zijlstra @ 2016-11-18 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117181708.GT22855@arm.com>
On Thu, Nov 17, 2016 at 06:17:08PM +0000, Will Deacon wrote:
> Hi all,
>
> We currently have support for three arm64 system PMUs in flight:
>
> [Cavium ThunderX] http://lkml.kernel.org/r/cover.1477741719.git.jglauber at cavium.com
> [Hisilicon Hip0x] http://lkml.kernel.org/r/1478151727-20250-1-git-send-email-anurup.m at huawei.com
> [Qualcomm L2] http://lkml.kernel.org/r/1477687813-11412-1-git-send-email-nleeder at codeaurora.org
>
> Each of which have to deal with multiple underlying hardware units in one
> way or another. Mark and I recently expressed a desire to expose these
> units to userspace as individual PMU instances, since this can allow:
>
> * Fine-grained control of events from userspace, when you want to see
> individual numbers as opposed to a summed total
>
> * Potentially ease migration to new SoC revisions, where the units
> are laid out slightly differently
>
> * Easier handling of cases where the units aren't quite identical
This is I think similar to the Intel Uncore situation. We expose every
single individual PMU independently. The Intel uncore is wide and varied
between parts.
Leaving the rest for Kan, who's doing the Intel uncore bits.
~ Peter
> however, this received pushback from all of the patch authors, so there's
> clearly a problem with this approach. I'm hoping we can try to resolve
> this here.
>
> Speaking to Mark earlier today, we came up with the following rough rules
> for drivers that present multiple hardware units as a single PMU:
>
> 1. If the units share some part of the programming interface (e.g. control
> registers or interrupts), then they must be handled by the same PMU.
> Otherwise, they should be treated independently as separate PMU
> instances.
>
> 2. If the units are handled by the same PMU, then care must be taken to
> handle event groups correctly. That is, if the units cannot be started
> and stopped atomically, cross-unit groups must be rejected by the
> driver. Furthermore, any cross-unit scheduling constraints must be
> honoured so that all the units targetted by a group can schedule the
> group concurrently.
>
> 3. Summing the counters across units is only permitted if the units
> can all be started and stopped atomically. Otherwise, the counters
> should be exposed individually. It's up to the driver author to
> decide what makes sense to sum.
>
> 4. Unit topology can optionally be described in sysfs (we should pick
> some standard directory naming here), and then events targetting
> specific units can have the unit identifier extracted from the topology
> encoded in some configN fields.
>
> The million dollar question is: how does that fit in with the drivers I
> mentioned at the top? Is this overly restrictive, or have we missed stuff?
>
> We certainly want to allow flexibility in the way in which the drivers
> talk to the hardware, but given that these decisions directly affect the
> user ABI, some consistent ground rules are required.
>
> For Cavium ThunderX, it's not clear whether or not the individual units
> could be expressed as separate PMUs, or whether they're caught by one of
> the rules above. The Qualcomm L2 looks like it's doing the right thing
> and we can't quite work out what the Hisilicon Hip0x topology looks like,
> since the interaction with djtag is confusing.
>
> If the driver authors (on To:) could shed some light on this, then that
> would be much appreciated!
>
> Thanks,
>
> Will
^ permalink raw reply
* [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Gregory CLEMENT @ 2016-11-18 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118101248.784eff2b@free-electrons.com>
Hi Thomas,
On ven., nov. 18 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 18 Nov 2016 10:01:32 +0100, Gregory CLEMENT wrote:
>
>> >> + soc at f00100000000 {
>> >
>> > Where is this value coming from? Why does the soc node needs to have a
>>
>> It cames from the dts files.
>
> Where?
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -63,7 +63,11 @@
reg = <0x00000000 0x40000000>; /* 1 GB */
};
- soc {
+ /* The following unit address is composed of the target
+ * value (bit [40-47]), attributes value (bits [32-39],
+ * and the address value in the window memory: [0-31].
+ */
+ soc at f00100000000 {
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
just here ---------^
MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
>
>> > unit address? It doesn't have a 'reg' property if I remember
>> > correctly.
>>
>> But it has a range property.
>
> And? There are multiple ranges, and you randomly took the first one for
> the unit address of the soc node?
Not randomly I followed the same rules that for the regs mentioned in
the ePAPR paragraph 2.2.1.1:
"The unit-address should match the first address specified in the reg
property of the node."
>
> You realize that the ranges property is a list of ranges, and they
> could be in any order? Why would you pick the base address of one of
> the ranges rather than any of the others?
It is the same for the regs so as explained I followed the same rules.
>
> I believe there is simply no unit address for the soc {} node. There is
> definitely one for the internal-regs {} node, but not for the soc {}
> node.
It is not the interpretation of the DTC:
"Warning (unit_address_vs_reg): Node /soc has a reg or ranges property,
but no unit name"
Gregory
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PULL] KVM/ARM updates for 4.9-rc6
From: Marc Zyngier @ 2016-11-18 9:39 UTC (permalink / raw)
To: linux-arm-kernel
Paolo, Radim,
Please find below the pull request for a couple of fixes for the
PMU emulation, courtesy of Wei. Both patches are candidates for stable.
Thanks,
M.
The following changes since commit d42c79701a3ee5c38fbbc82f98a140420bd40134:
KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs (2016-11-04 17:56:56 +0000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.9-rc6
for you to fetch changes up to b112c84a6ff035271d41d548c10215f18443d6a6:
KVM: arm64: Fix the issues when guest PMCCFILTR is configured (2016-11-18 09:06:58 +0000)
----------------------------------------------------------------
KVM/ARM updates for v4.9-rc6
- Fix handling of the 32bit cycle counter
- Fix cycle counter filtering
----------------------------------------------------------------
Wei Huang (2):
arm64: KVM: pmu: Fix AArch32 cycle counter access
KVM: arm64: Fix the issues when guest PMCCFILTR is configured
arch/arm64/include/asm/perf_event.h | 10 +++++++++-
arch/arm64/kernel/perf_event.c | 10 +---------
arch/arm64/kvm/sys_regs.c | 10 ++++++++--
virt/kvm/arm/pmu.c | 8 +++++---
4 files changed, 23 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH 1/2] arm64: KVM: pmu: Fix AArch32 cycle counter access
From: Marc Zyngier @ 2016-11-18 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479461966-20136-1-git-send-email-marc.zyngier@arm.com>
From: Wei Huang <wei@redhat.com>
We're missing the handling code for the cycle counter accessed
from a 32bit guest, leading to unexpected results.
Cc: stable at vger.kernel.org # 4.6+
Signed-off-by: Wei Huang <wei@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/kvm/sys_regs.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f302fdb..87e7e66 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -597,8 +597,14 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
idx = ARMV8_PMU_CYCLE_IDX;
} else {
- BUG();
+ return false;
}
+ } else if (r->CRn == 0 && r->CRm == 9) {
+ /* PMCCNTR */
+ if (pmu_access_event_counter_el0_disabled(vcpu))
+ return false;
+
+ idx = ARMV8_PMU_CYCLE_IDX;
} else if (r->CRn == 14 && (r->CRm & 12) == 8) {
/* PMEVCNTRn_EL0 */
if (pmu_access_event_counter_el0_disabled(vcpu))
@@ -606,7 +612,7 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
} else {
- BUG();
+ return false;
}
if (!pmu_counter_idx_valid(vcpu, idx))
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] KVM: arm64: Fix the issues when guest PMCCFILTR is configured
From: Marc Zyngier @ 2016-11-18 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479461966-20136-1-git-send-email-marc.zyngier@arm.com>
From: Wei Huang <wei@redhat.com>
KVM calls kvm_pmu_set_counter_event_type() when PMCCFILTR is configured.
But this function can't deals with PMCCFILTR correctly because the evtCount
bits of PMCCFILTR, which is reserved 0, conflits with the SW_INCR event
type of other PMXEVTYPER<n> registers. To fix it, when eventsel == 0, this
function shouldn't return immediately; instead it needs to check further
if select_idx is ARMV8_PMU_CYCLE_IDX.
Another issue is that KVM shouldn't copy the eventsel bits of PMCCFILTER
blindly to attr.config. Instead it ought to convert the request to the
"cpu cycle" event type (i.e. 0x11).
To support this patch and to prevent duplicated definitions, a limited
set of ARMv8 perf event types were relocated from perf_event.c to
asm/perf_event.h.
Cc: stable at vger.kernel.org # 4.6+
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Wei Huang <wei@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/perf_event.h | 10 +++++++++-
arch/arm64/kernel/perf_event.c | 10 +---------
virt/kvm/arm/pmu.c | 8 +++++---
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 2065f46..38b6a2b 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -46,7 +46,15 @@
#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 */
+/*
+ * PMUv3 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
/*
* Event filters for PMUv3
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index a9310a6..57ae9d9 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -31,17 +31,9 @@
/*
* ARMv8 PMUv3 Performance Events handling code.
- * Common event types.
+ * Common event types (some are defined in asm/perf_event.h).
*/
-/* 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
-
/* At least one of the following is required. */
#define ARMV8_PMUV3_PERFCTR_INST_RETIRED 0x08
#define ARMV8_PMUV3_PERFCTR_INST_SPEC 0x1B
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6e9c40e..69ccce3 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -305,7 +305,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
continue;
type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
& ARMV8_PMU_EVTYPE_EVENT;
- if ((type == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+ if ((type == ARMV8_PMUV3_PERFCTR_SW_INCR)
&& (enable & BIT(i))) {
reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
reg = lower_32_bits(reg);
@@ -379,7 +379,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
/* Software increment event does't need to be backed by a perf event */
- if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+ if (eventsel == ARMV8_PMUV3_PERFCTR_SW_INCR &&
+ select_idx != ARMV8_PMU_CYCLE_IDX)
return;
memset(&attr, 0, sizeof(struct perf_event_attr));
@@ -391,7 +392,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
attr.exclude_kernel = data & ARMV8_PMU_EXCLUDE_EL1 ? 1 : 0;
attr.exclude_hv = 1; /* Don't count EL2 events */
attr.exclude_host = 1; /* Don't count host events */
- attr.config = eventsel;
+ attr.config = (select_idx == ARMV8_PMU_CYCLE_IDX) ?
+ ARMV8_PMUV3_PERFCTR_CPU_CYCLES : eventsel;
counter = kvm_pmu_get_counter_value(vcpu, select_idx);
/* The initial sample period (overflow count) of an event. */
--
2.1.4
^ permalink raw reply related
* [PATCH v2] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Rameshwar Prasad Sahu @ 2016-11-18 9:45 UTC (permalink / raw)
To: linux-arm-kernel
This patch enables NCQ support for APM X-Gene SATA controller hardware v1.1
that was broken with hardware v1.0. Second thing, here we should not assume
XGENE_AHCI_V2 always in case of having valid _CID in ACPI table. I need to
remove this assumption because V1_1 also has a valid _CID for backward
compatibly with v1.
v2 changes:
1. Changed patch description
Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>
---
drivers/ata/ahci_xgene.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 73b19b2..8b88be9 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -87,6 +87,7 @@
enum xgene_ahci_version {
XGENE_AHCI_V1 = 1,
+ XGENE_AHCI_V1_1,
XGENE_AHCI_V2,
};
@@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
#ifdef CONFIG_ACPI
static const struct acpi_device_id xgene_ahci_acpi_match[] = {
{ "APMC0D0D", XGENE_AHCI_V1},
+ { "APMC0D67", XGENE_AHCI_V1_1},
{ "APMC0D32", XGENE_AHCI_V2},
{},
};
@@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
static const struct of_device_id xgene_ahci_of_match[] = {
{.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
+ {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) XGENE_AHCI_V1_1},
{.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
{},
};
@@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
struct resource *res;
const struct of_device_id *of_devid;
enum xgene_ahci_version version = XGENE_AHCI_V1;
- const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
- &xgene_ahci_v2_port_info };
+ const struct ata_port_info *ppi;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "%s: Error reading device info. Assume version1\n",
__func__);
version = XGENE_AHCI_V1;
- } else if (info->valid & ACPI_VALID_CID) {
- version = XGENE_AHCI_V2;
}
}
}
@@ -858,18 +858,20 @@ skip_clk_phy:
switch (version) {
case XGENE_AHCI_V1:
+ ppi = &xgene_ahci_v1_port_info;
hpriv->flags = AHCI_HFLAG_NO_NCQ;
break;
case XGENE_AHCI_V2:
+ ppi = &xgene_ahci_v2_port_info;
hpriv->flags |= AHCI_HFLAG_YES_FBS;
hpriv->irq_handler = xgene_ahci_irq_intr;
break;
default:
+ ppi = &xgene_ahci_v1_port_info;
break;
}
- rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
- &ahci_platform_sht);
+ rc = ahci_platform_init_host(pdev, hpriv, ppi, &ahci_platform_sht);
if (rc)
goto disable_resources;
--
1.7.1
^ permalink raw reply related
* Potential deadlock BUG in Linux 4.9 drivers/dma/coh901318.c
From: Iago Abal @ 2016-11-18 9:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
With the help of a static bug finder (EBA -
https://github.com/models-team/eba) I have found a potential deadlock
in drivers/dma/coh901318.c. This happens due to a recursive
spin_lock_irqsave on `cohc->lock'.
This bug may have been introduced by commit 84c8447c544b ("DMAENGINE:
COH 901 318 fix bytesleft").
The fix seems easy, I would personally just remove the calls to
spin_(un)lock_irqsave in lines 1805 and 1826. Function
`coh901318_config' is only called by `coh901318_alloc_chan_resources'
which already holds that lock when calling it.
If someone can confirm that all the above is correct, I will be happy
to submit a patch.
The trace is as follows:
1. Function `coh901318_alloc_chan_resources' takes the lock first in line 2165:
// see https://github.com/torvalds/linux/blob/master/drivers/dma/coh901318.c#L2165
spin_lock_irqsave(&cohc->lock, flags);
2. Immediately after it calls `coh901318_config' passing the `cohc'
struct to it.
3. The first thing `coh901318_config' does is to take the same
spinlock in line 1805:
// see https://github.com/torvalds/linux/blob/master/drivers/dma/coh901318.c#L1805
spin_lock_irqsave(&cohc->lock, flags);
Hope it helps!
-- iago
^ permalink raw reply
* [PATCH] [media] VPU: mediatek: fix dereference of pdev before checking it is null
From: Matthias Brugger @ 2016-11-18 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116191650.11486-1-colin.king@canonical.com>
On 16/11/16 20:16, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> pdev is dereferenced using platform_get_drvdata before a check to
> see if it is null, hence there could be a potential null pointer
> dereference issue. Instead, first check if pdev is null and only then
> deference pdev when initializing vpu.
>
> Found with static analysis by CoverityScan, CID 1357797
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> drivers/media/platform/mtk-vpu/mtk_vpu.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> index c9bf58c..41f31b2 100644
> --- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
> +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> @@ -523,9 +523,9 @@ static int load_requested_vpu(struct mtk_vpu *vpu,
>
> int vpu_load_firmware(struct platform_device *pdev)
> {
> - struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> + struct mtk_vpu *vpu;
> struct device *dev = &pdev->dev;
> - struct vpu_run *run = &vpu->run;
> + struct vpu_run *run;
> const struct firmware *vpu_fw = NULL;
> int ret;
>
> @@ -533,6 +533,8 @@ int vpu_load_firmware(struct platform_device *pdev)
> dev_err(dev, "VPU platform device is invalid\n");
> return -EINVAL;
> }
> + vpu = platform_get_drvdata(pdev);
> + run = &vpu->run;
>
> mutex_lock(&vpu->vpu_mutex);
> if (vpu->fw_loaded) {
>
^ 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