* [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
* [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 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
* [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
* [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
* [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
* 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
* [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
* [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 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] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-11-18 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACXcFmmMc7U1Qz6A+mvMXVnfSmOmssydcmSugo21jrX3u-95Qg@mail.gmail.com>
On Thu, Nov 17, 2016 at 08:07:09PM -0500, Sandy Harris wrote:
> Add Ted T'so to cc list. Shouldn't he be included on anything affecting
> the random(4) driver?
>
Blindy used get_maintainer.pl, and since the file is in crypto, hw_random people were not set.
Note that get_maintainer.pl on drivers/char/hw_random/, does not give his address also.
My V2 patch will have them in CC/TO.
> On Tue, Oct 18, 2016 at 8:34 AM, Corentin Labbe
> <clabbe.montjoie@gmail.com> wrote:
>
> > From: LABBE Corentin <clabbe.montjoie@gmail.com>
> >
> > The Security System have a PRNG.
> > This patch add support for it as an hwrng.
>
> Which is it? A PRNG & a HW RNG are quite different things.
> It would, in general, be a fairly serious error to treat a PRNG
> as a HWRNG.
>
> If it is just a prng (which it appears to be from a quick look
> at your code) then it is not clear it is useful since the
> random(4) driver already has two PRNGs. It might be
> but I cannot tell.
For me hwrng is a way to give user space an another way to get "random" data via /dev/hwrng.
The only impact of hwrng with random is that just after init some data of hwrng is used for having more entropy.
Grepping prng in drivers/char/hw_random/ and drivers/crypto show me some other PRNG used with hwrng.
Regards
Corentin Labbe
^ permalink raw reply
* [GIT PULL] arm: mediatek: soc changes for v4.10
From: Olof Johansson @ 2016-11-18 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002ed210-0f74-e938-b69f-c91ae98d37e4@gmail.com>
On Mon, Nov 14, 2016 at 07:39:10PM +0100, Matthias Brugger wrote:
> Hi Arnd and Olof,
>
> Although a bit late, please take the following changes into account.
>
> Thanks a lot,
> Matthias
> ---
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-soc
>
> for you to fetch changes up to 112ef1882e12094c823937f9d72f2f598db02df7:
>
> soc: mediatek: Add MT2701 scpsys driver (2016-10-31 00:58:58 +0100)
>
> ----------------------------------------------------------------
> - prepare mtk-scpsys to for multi soc support
> - add support for mt2701 to mtk-scpsys
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] arm: mediatek: kconfig changes for v4.10
From: Olof Johansson @ 2016-11-18 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b9bf2483-533d-ffd1-b23f-d89d20b8a73a@gmail.com>
On Mon, Nov 14, 2016 at 07:37:51PM +0100, Matthias Brugger wrote:
> Hi Arnd and Olof,
>
> although late, please pull the following changes.
>
> Thanks,
> Matthias
> ---
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-kconfig
>
> for you to fetch changes up to 494975c9cc00f69bf71de0991dcebda9b2911aa0:
>
> ARM: mediatek: clean up mach-mediatek/Makefile (2016-10-31 15:26:23 -0600)
>
> ----------------------------------------------------------------
> - clean up mach-mediatek Makefile as kbuild only descends into the folder if
> ARCH_MEDIATEK is enabled
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] arm: mediatek: dts changes for v4.10
From: Olof Johansson @ 2016-11-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c148f205-79fc-3578-84db-cce4063e42ec@gmail.com>
On Mon, Nov 14, 2016 at 07:36:36PM +0100, Matthias Brugger wrote:
> Hi Arnd and Olof,
>
> although late, please pull the following changes.
>
> Thanks,
> Matthias
> ---
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-dts
>
> for you to fetch changes up to 28d6e3647bd7c869bfc251f9a7e283d78cef5fc5:
>
> arm: dts: mt2701: Use real clock for UARTs (2016-11-11 15:25:09 +0100)
>
> ----------------------------------------------------------------
> - Add bindings for mtk-scpsys for mt2701
> - Add clocks for auxadc on mt8173-evb
> - Add nodes needed by clock controller for mt2701
> - Use clocks from the clock controller for the uart of mt2701
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] DaVinci additional driver support for v4.10
From: Olof Johansson @ 2016-11-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fc11bfc7-e218-cd11-8e4e-c48e899d1cb5@ti.com>
On Mon, Nov 14, 2016 at 06:28:22PM +0530, Sekhar Nori wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/drivers
>
> for you to fetch changes up to 8e7223fc8626db7c302136747bb68213100d290c:
>
> bus: davinci: add support for da8xx bus master priority control (2016-11-14 17:20:29 +0530)
>
> ----------------------------------------------------------------
> This pull request adds two new drivers for better
> support for LCD found on DaVinci DA8xx devices.
>
> They allow configuration of memory interface and
> bus priorities on the SoC to allow sufficient
> bandwidth for the LCD and prevent underruns.
>
> The DT bindings have been reviewed by Rob and
> patches have been reviewed by Kevin.
>
> ----------------------------------------------------------------
> Bartosz Golaszewski (2):
> memory: davinci: add support for da8xx DDR2/mDDR controller
> bus: davinci: add support for da8xx bus master priority control
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Qualcomm SoC Updates for v4.10
From: Olof Johansson @ 2016-11-18 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479017736-13564-6-git-send-email-andy.gross@linaro.org>
On Sun, Nov 13, 2016 at 12:15:36AM -0600, Andy Gross wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-soc-for-4.10
>
> for you to fetch changes up to e19811a89d0f566bb781959e151f244bd3bcde8a:
>
> arm64: qcom: enable GPIOLIB in Kconfig (2016-11-12 23:24:26 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM Based SoC Updates for v4.10
>
> * Enable GPIOLIB for QCOM ARM64 platforms
>
> ----------------------------------------------------------------
> Michael Scott (1):
> arm64: qcom: enable GPIOLIB in Kconfig
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Qualcomm Device Tree Changes for v4.10
From: Olof Johansson @ 2016-11-18 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479017736-13564-5-git-send-email-andy.gross@linaro.org>
Hi,
On Sun, Nov 13, 2016 at 12:15:35AM -0600, Andy Gross wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-dts-for-4.10
>
> for you to fetch changes up to 52a1a5f773110f687c34a828ef42fdb882b6b908:
>
> ARM: dts: add SMSC ethernet on the APQ8060 Dragonboard (2016-10-25 08:42:37 -0500)
>
> ----------------------------------------------------------------
> Qualcomm Device Tree Changes for v4.10
>
> * Add EBI2 support to MSM8660
> * Add SMSC ethernet support to APQ8060
> * Add support for display, pstore, iommu, and hdmi to APQ8064
> * Add SDHCI node to MSM8974 Hammerhead
> * Add WP8548 MangOH board support (MDM9615)
>
> ----------------------------------------------------------------
> Archit Taneja (2):
> arm: dts: qcom: apq8064: Add display DT nodes
> arm: dts: qcom: apq8064-ifc6410: Add HDMI support
>
> Bhushan Shah (1):
> ARM: dts: qcom: msm8974-hammerhead: Add sdhci1 node
>
> John Stultz (3):
> arm: dts: qcom: apq8064: Add dsi, gpu and iommu nodes
> arm: dts: qcom: apq8064-nexus7: Add DSI and panel nodes
> arm: dts: qcom: apq8064-nexus7: Add pstore support to nexus7
>
> Linus Walleij (2):
> ARM: dts: add EBI2 to the Qualcomm MSM8660 DTSI
> ARM: dts: add SMSC ethernet on the APQ8060 Dragonboard
>
> Neil Armstrong (5):
> ARM: dts: Add MDM9615 dtsi
> dt-bindings: qcom: Add MDM9615 bindings
> ARM: dts: Add Sierra Wireless WP8548 dtsi
> ARM: dts: Add WP8548 based MangOH Green board DTS
We tend to keep the SoC manufacturer as the topmost prefix here, to keep
things in common.
While the Sierra Wireless products are modules, they are based on QCOM SoCs.
So the expected names would be qcom-<soc>-module. Something like
qcom-mdm9615-wp8548.dtsi and qcom-mdm9615-wp8548-mangoh-green.dts.
Can you respin with this addressed? Thanks!
-Olof
^ permalink raw reply
* [GIT PULL] Qualcomm Driver Updates for v4.10
From: Olof Johansson @ 2016-11-18 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479017736-13564-4-git-send-email-andy.gross@linaro.org>
On Sun, Nov 13, 2016 at 12:15:34AM -0600, Andy Gross wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.10
>
> for you to fetch changes up to bd4760ca03156731674a570e44490986189d8228:
>
> firmware: qcom: scm: Use devm_reset_controller_register() (2016-11-12 23:24:51 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM Based Driver Updates for v4.10
>
> * Fixup QCOM SCM to use devm_reset_controller_register
> * Add QCOM pinctrl to Qualcomm MAINTAINERS entry
> * Add PM8994 regulator definitions
> * Add stub for WCNSS_CTRL API
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Qualcomm Defconfig Updates for v4.10
From: Olof Johansson @ 2016-11-18 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479017736-13564-3-git-send-email-andy.gross@linaro.org>
On Sun, Nov 13, 2016 at 12:15:33AM -0600, Andy Gross wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-defconfig-for-4.10
>
> for you to fetch changes up to 206787737e308bb447d18adef7da7749188212f5:
>
> ARM: qcom_defconfig: Fix MDM9515 LCC and GCC config (2016-10-24 16:04:32 -0500)
>
> ----------------------------------------------------------------
> Qualcomm ARM Based defconfig Updates for v4.10
>
> * Fixup MDM9615 option names
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 DT Updates for v4.10
From: Olof Johansson @ 2016-11-18 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479017736-13564-2-git-send-email-andy.gross@linaro.org>
On Sun, Nov 13, 2016 at 12:15:32AM -0600, Andy Gross wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm64-for-4.10
>
> for you to fetch changes up to feeaf56ac78d283efe65ea60ec999d4bf3cf395e:
>
> arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support (2016-11-12 22:57:56 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM64 Updates for v4.10
>
> * Add Hexagon SMD/PIL nodes
> * Add DB820c PMIC pins
> * Fixup APQ8016 voltage ranges
> * Add various MSM8996 nodes to support SMD/SMEM/SMP2P
> * Add support for Huawei Nexus 6P (Angler)
> * Add support for LG Nexus 5x (Bullhead)
Merged, thanks. Great to start seeing (almost) current phone support, even if
it's very basic hardware descriptions so far.
-Olof
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 Defconfig Updates for v4.10
From: Olof Johansson @ 2016-11-18 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479017736-13564-1-git-send-email-andy.gross@linaro.org>
On Sun, Nov 13, 2016 at 12:15:31AM -0600, Andy Gross wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm64-defconfig-for-4.10
>
> for you to fetch changes up to a77a713395392a7f79d89e634fe3e018c4f83898:
>
> arm64: configs: enable configs for msm899(2/4) basic support (2016-11-12 22:44:09 -0600)
>
> ----------------------------------------------------------------
> Qualcomm ARM64 Based defconfig Updates for v4.10
>
> * Enable defconfig options for MSM8992/8994
>
> ----------------------------------------------------------------
> Jeremy McNicoll (1):
> arm64: configs: enable configs for msm899(2/4) basic support
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 3/3] Rockchip dts64 changes for 4.10
From: Olof Johansson @ 2016-11-18 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4932547.OPNQihgQS9@phil>
On Sat, Nov 12, 2016 at 04:36:25PM +0100, Heiko Stuebner wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.10-rockchip-dts64-1
>
> for you to fetch changes up to c49590691f3819bb6be3f77938ef39038eb76643:
>
> arm64: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max" (2016-11-09 15:08:55 +0100)
>
> ----------------------------------------------------------------
> 64bit devicetree changes including the px5 evaluation board
> a fix for wrong i2c registers on rk3368 a new nvmem cell and
> power-domain on rk3399 as well as moving mmc frequency
> properties to the more generic max-frequency one.
>
> ----------------------------------------------------------------
> Andy Yan (2):
> arm64: dts: rockchip: fix i2c resource error of rk3368
> arm64: dts: rockchip: Add PX5 Evaluation board
>
> Chris Zhong (1):
> arm64: dts: rockchip: add powerdomain for typec on rk3399
>
> Jaehoon Chung (1):
> arm64: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
>
> Shawn Lin (2):
> arm64: dts: rockchip: Add more properties for emmc on px5-evb
> arm64: dts: rockchip: add sdmmc support for px5-evb
>
> Ziyuan Xu (1):
> arm64: dts: rockchip: add cpu-id nvmem cell node for rk3399
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 2/3] Rockchip dts32 changes for 4.10
From: Olof Johansson @ 2016-11-18 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2517910.T56YgEDzxC@phil>
On Sat, Nov 12, 2016 at 04:35:49PM +0100, Heiko Stuebner wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.10-rockchip-dts32-1
>
> for you to fetch changes up to 6a8883d614c7bede1075a4850139daa9723c291e:
>
> ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max" (2016-11-09 14:46:04 +0100)
>
> ----------------------------------------------------------------
> 32bit devicetree changes for Rockchip including removal of skeleton.dtsi
> inclusion, missing unit names for memory nodes, various frequency
> optimizations allowing for better performance on rk3066, the usage of
> pin constants to bridge between the two numbering schemes used (gpio
> controllers using 0-31 and pins being labeled A0-A7,..., D0-D7)
> and UHS/HS modes for the mmc controllers on the popmetal board.
>
> Two new boards, the PX3-based evaluation board, with the PX3 being an
> industrial variant of the rk3188 soc and the Rikomagic MK808 board
> based around the rk3066 are also added.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 1/3] Rockchip driver changes for 4.10
From: Olof Johansson @ 2016-11-18 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1698724.ZQnZMjf8xY@phil>
On Sat, Nov 12, 2016 at 04:34:17PM +0100, Heiko Stuebner wrote:
> Hi Arnd, Kevin, Olof,
>
> please find below and in the following two mails, Rockchip power-domain as
> well as dts32 and dts64 changes for 4.10.
>
> I don't think anything big stands out, just the usual mix of incremental
> improvements, so if stuff looks ok please pull.
>
>
> Thanks
> Heiko
>
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.10-rockchip-drivers1
>
> for you to fetch changes up to dabc0259db63338f0e64107cc92b2241f98a3284:
>
> soc: rockchip: power-domain: Handle errors from of_genpd_add_provider_onecell (2016-11-11 02:14:59 +0100)
>
> ----------------------------------------------------------------
> Changes to the power-domain driver including counter presets now being set
> by firmware on the rk3399, avoiding infite loops when powering on/off a
> domain and actually returning an error if power-domain addition fails.
> The last part requires usage of the (new in 4.9-rc1) pm_genpd_remove
> functionality as well.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 2/2] SoCFPGA defconfig updates for v4.10
From: Olof Johansson @ 2016-11-18 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111205915.22173-2-dinguyen@kernel.org>
On Fri, Nov 11, 2016 at 02:59:15PM -0600, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
>
> Please pull these defconfig updates for v4.10.
>
> Thanks,
> Dinh
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_defconfig_updates_for_v4.10
>
> for you to fetch changes up to cab004fa972f06b236ba6b592bbb0512d5c6c158:
>
> ARM: socfpga_defconfig: enable FS configs to support Angstrom filesystem (2016-11-09 08:11:31 -0600)
>
> ----------------------------------------------------------------
> SoCFPGA defconfig updates for v4.10
> - enable QSPI, HIGHMEM, FPGA bridge and device-tree overlays
> - enable AUTOFS4 and NFS file system support
>
> ----------------------------------------------------------------
> Alan Tull (1):
> ARM: socfpga: updates for socfpga_defconfig
>
> Dinh Nguyen (2):
> ARM: socfpga_defconfig: Enable HIGHMEM
> ARM: socfpga_defconfig: enable FS configs to support Angstrom filesystem
>
> Steffen Trumtrar (1):
> ARM: socfpga: defconfig: enable qspi
Merged, thanks.
-Olof
^ 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