* [PATCH 1/5 v3] usb: host: add DT bindings for faraday fotg2
From: Hans Ulli Kroll @ 2017-04-24 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170421204058.6206-1-linus.walleij@linaro.org>
Hi Linus
On Fri, 21 Apr 2017, Linus Walleij wrote:
> From: Hans Ulli Kroll <ulli.kroll@googlemail.com>
>
> This adds device tree bindings for the Faraday FOTG2
> dual-mode host controller.
>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v3:
> - Change compatible to "faraday,fotg210" as the name of the
> hardware block.
> - Add an elaborate SoC-specific compatible string for the
> Cortina Systems Gemini so that SoC-specific features can
> be enabled.
> - Add cortina,gemini-mini-b to indicate a Gemini PHY with
> a Mini-B adapter connected.
> - Indicated that the Gemini version can handle "wakeup-source".
> - Add optional IP block clock.
> ---
> .../devicetree/bindings/usb/faraday,fotg210.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/faraday,fotg210.txt
>
Got NAK'ed from Rob on some ealier round due missing "device mode" on this
IP. I've blatantly overrided this to a host only driver.
These are the needed changes in DT to support both modes
Note the -dr at the end of fotg210, to reflect this in an dual role device
diff --git a/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
index cf06808303e2..862cda19e9d3 100644
--- a/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
+++ b/Documentation/devicetree/bindings/usb/faraday,fotg210.txt
@@ -13,6 +13,9 @@ Required properties:
Optional properties:
- clocks: should contain the IP block clock
- clock-names: should be "PCLK" for the IP block clock
+- dr_mode : indicates the working mode for "fotg210-dr" compatible
+ controllers. Can be "host", "peripheral". Default to
+ "host" if not defined for backward compatibility.
Required properties for "cortina,gemini-usb" compatible:
- syscon: a phandle to the system controller to access PHY registers
@@ -25,7 +28,7 @@ Optional properties for "cortina,gemini-usb" compatible:
Example for Gemini:
usb at 68000000 {
- compatible = "cortina,gemini-usb", "faraday,fotg210";
+ compatible = "cortina,gemini-usb", "faraday,fotg210-dr";
reg = <0x68000000 0x1000>;
interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cc 12>;
^ permalink raw reply related
* [PATCH] arm64: pmuv3: Support v8.1 PMUv3 extension
From: Mark Rutland @ 2017-04-24 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424164008.GA4657@localhost>
On Mon, Apr 24, 2017 at 04:40:09PM +0000, Jayachandran C wrote:
> On Mon, Apr 24, 2017 at 03:03:48PM +0100, Mark Rutland wrote:
> > On Mon, Apr 24, 2017 at 01:39:30PM +0000, Jayachandran C wrote:
> > > The v8.1 supplement is quite clear on the field definition:
> > >
> > > PMUVer, bits [11:8]
> > > ....
> > > Defined values are:
> > > 0000 Performance Monitors extension System registers not implemented.
> > > 0001 Performance Monitors extension System registers implemented, PMUv3.
> > > 0100 Performance Monitors extension System registers implemented, PMUv3, with a 16-bit
> > > evtCount field, and if EL2 is implemented, the addition of the MDCR_EL2.HPMD bit.
> > > 1111 IMPLEMENTATION DEFINED form of performance monitors supported, PMUv3 not
> > > supported.
> > > All other values are reserved.
> > > In ARMv8-A the permitted values are 0b0000, 0b0001 and 0b1111.
> > > In ARMv8.1 the permitted values are 0b0000, 0b0100 and 0b1111.
> > >
> > > I changed the code to strictly do this. We have to exclude 0xf, since that is not PMUv3.
> > > And we cannot predict what the reserved values will represent, so it is best to skip them
> > > until they are defined to be PMUv3 compatible.
> >
> > My understanding is that ID_AA64DFR0.PMUVer is intended to be covered by
> > the usual ID register principles, and thus at least 0x2-0x7 are reserved
> > for architected backwards compatible extensions to PMUv3.
> >
> > See ARM DDI 0487B.a, D7.1.4, "Principles of the ID scheme for fields in
> > ID registers". It is explicitly stated that the scheme applies to
> > ID_AA64DFR0.
> >
> > Per those rules, we should check >= the minimum PMUv3 implemented value,
> > i.e. val >= 1. Due to both 0x0 and 0xF meaning PMUv3 isn't implemented,
> > it's not clear if the fields should be treated as if it were signed or
> > unsigned, and I'm awaiting clarification on this.
>
> Thanks for the reference. Since 0xf means that there is a PMU (but it is
> not PMUv3), this looks like an unsigned ID with a special case.
>
> > Either way, I believe that 0x1-0x7 must all be compatible with baseline
> > PMUv3 per the ID scheme principles.
>
> In case you don't get authoritative information on this, can you please
> merge a version which does either 'if (pmuver < 1 || pmuver == 0xf)' or
> 'if (pmuver < 1 || pmuver > 7)' to the patchset?
Sure, that's what I proposed:
pmuver = cpuid_feature_extract_signed_field(dfr0,
ID_AA64DFR0_PMUVER_SHIFT);
if (pmuver < 1)
return;
Note that it treats the value as signed, so it will accept 0x1-0x7, and
return for 0x0 or 0x8-0xf.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 3/5] Memory hotplug support for arm64 platform (v2)
From: Maciej Bielski @ 2017-04-24 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170411155843.GC32267@leverpostej>
Hi Mark,
Thank you for having a look on the code and providing comments. Same to others
that replied to the whole patchset. To the large extent, first purpose of this code
was to just to implement the functionality and I am totally aware that it may
be suboptimal at some places and therefore your feedback is very much
appreciated.
More answers below.
On Tue, Apr 11, 2017 at 04:58:43PM +0100, Mark Rutland wrote:
> Hi,
>
> On Tue, Apr 11, 2017 at 03:55:22PM +0100, Andrea Reale wrote:
> > From: Maciej Bielski <m.bielski@virtualopensystems.com>
> >
> > This is a second and improved version of the patch previously released
> > in [3].
> >
> > It builds on the work by Scott Branden [2] and, henceforth,
> > it needs to be applied on top of Scott's patches [2].
> > Comments are very welcome.
> >
> > Changes from the original patchset and known issues:
> >
> > - Compared to Scott's original patchset, this work adds the mapping of
> > the new hotplugged pages into the kernel page tables. This is done by
> > copying the old swapper_pg_dir over a new page, adding the new mappings,
> > and then switching to the newly built pg_dir (see `hotplug_paging` in
> > arch/arm64/mmu.c). There might be better ways to to this: suggestions
> > are more than welcome.
>
> For this reply, I'm just going to focus on the PGD replacement.
>
> It's not clear to me if we need to swap the PGD, since everything we do
> here is strictly additive and non-conflicting, and it should be safe to
> add things to the swapper_pg_dir live.
>
> However, assuming there's something I've missed, I have some comments
> below.
>
> [...]
For one CPU it should work, I have quickly checked on QEMU. More concerns
regarding multiple CPUs below(*).
>
> > +#ifdef CONFIG_MEMORY_HOTPLUG
> > +
> > +/*
> > + * hotplug_paging() is used by memory hotplug to build new page tables
> > + * for hot added memory.
> > + */
> > +void hotplug_paging(phys_addr_t start, phys_addr_t size)
> > +{
> > +
> > + struct page *pg;
> > + phys_addr_t pgd_phys = pgd_pgtable_alloc();
> > + pgd_t *pgd = pgd_set_fixmap(pgd_phys);
> > +
> > + memcpy(pgd, swapper_pg_dir, PAGE_SIZE);
>
> s/PAGE_SIZE/PGD_SIZE/ (and below, too).
>
> See commit 12f043ff2b28fa64 ("arm64: fix warning about swapper_pg_dir
> overflow").
>
Noted, thanks.
> > +
> > + __create_pgd_mapping(pgd, start, __phys_to_virt(start), size,
> > + PAGE_KERNEL, pgd_pgtable_alloc, false);
> > +
> > + cpu_replace_ttbr1(__va(pgd_phys));
>
> Other CPUs may be online at this point, and cpu_replace_ttbr1() was only
> intended for UP operation. Other CPUs will still have swapper_pg_dir in
> their TTBR1_EL1 at this point in time...
>
> > + memcpy(swapper_pg_dir, pgd, PAGE_SIZE);
>
> ... which this will alter, in an unsafe fashion.
>
> The other CPUs are live, and might be altering swapper. e.g. one might
> be using the fixmap to alter code. We will need some stop_machine()-like
> machinery here to synchronise with other CPUs, ensuring that they don't
> have swapper_pg_dir live.
(*)
I am familiar with stop_machine(), for example it is done at later stage, when
pages are onlined (inside build_all_zonelists). But do you think that we should
check if swapper_pg_dir is under modification before stopping (and optionally
wait until this modification is finished)? Is there a mechanism to serialize
the write access to swapper_pg_dir?
>
> Unfortunately, we can't change other to the temporary pgdir in a cross
> call, then fix things up, then do another cross call. If any exception
> is taken when we're in the temporary pgdir, __uaccess_ttbr0_disable will
> install junk into TTBR0, and we risk the usual set of pain junk TLBs
> entail.
>
> We appear to have a latent bug at boot time along those lines, when
> setting up the page tables and initialising KASAN. I'll see about
> cleaning that up.
Great, thank you for any hints.
>
> Thanks,
> Mark.
Best regards,
--
Maciej Bielski
^ permalink raw reply
* [PATCH 1/4] pinctrl: stm32: set pin to gpio input when used as interrupt
From: Alexandre Torgue @ 2017-04-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYZixkJroS-gQxYL6xW47-J9UiNv4hOO9F-1b2eYLr8XQ@mail.gmail.com>
Hi Linus,
On 04/24/2017 02:36 PM, Linus Walleij wrote:
> On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
> <alexandre.torgue@st.com> wrote:
>
>> This patch ensures that pin is correctly set as gpio input when it is used
>> as an interrupt.
>>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
> (...)
>
>> +static int stm32_gpio_irq_request_resources(struct irq_data *irq_data)
>> +{
>> + struct stm32_gpio_bank *bank = irq_data->domain->host_data;
>> + u32 ret;
>> +
>> + if (!gpiochip_is_requested(&bank->gpio_chip, irq_data->hwirq)) {
>> + ret = stm32_gpio_request(&bank->gpio_chip, irq_data->hwirq);
>> + if (ret)
>> + return ret;
>> + }
>
> This is wrong. You should only use gpiochip_lock_as_irq(), because of the
> following in Documentation/gpio/driver.txt:
>
> ---------------
> It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
> if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
> irq_chip are orthogonal, and offering their services independent of each
> other.
> (...)
> So always prepare the hardware and make it ready for action in respective
> callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
> been called first.
Ok, so actually the action to set pin in input mode is necessary in
stm32_gpio_irq_request_resources.
I'll fix it in V2.
>
> This orthogonality leads to ambiguities that we need to solve: if there is
> competition inside the subsystem which side is using the resource (a certain
> GPIO line and register for example) it needs to deny certain operations and
> keep track of usage inside of the gpiolib subsystem. This is why the API
> below exists.
>
> Locking IRQ usage
> -----------------
> Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
> to mark the GPIO as being used as an IRQ:
>
> int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
>
> This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
> is released:
>
> void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
>
> When implementing an irqchip inside a GPIO driver, these two functions should
> typically be called in the .startup() and .shutdown() callbacks from the
> irqchip.
>
> When using the gpiolib irqchip helpers, these callback are automatically
> assigned.
> --------------
>
> It is because of easy to make errors like this that I prefer that people try
> to use GPIOLIB_IRQCHIP helpers insteaf of rolling their own irqchip code.
I understand. It was difficult in our case due to design.
Thanks for review.
Alex
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* [Bug] VCHIQ functional test broken
From: Russell King - ARM Linux @ 2017-04-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <696fb1c1-7751-caf0-e0d9-9c67b059b4cc@i2se.com>
On Mon, Apr 24, 2017 at 06:12:09PM +0200, Stefan Wahren wrote:
> Am 20.04.2017 um 21:58 schrieb Rabin Vincent:
> > On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
> >> I'm confused by what you're saying here. The driver has already been
> >> converted to not use dmac_map_area (commit
> >> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
> >> matching the radeon driver you give as a model as far as I can see.
> >> That commit is in v4.11-rc6 from Stefan's regression report.
> > Right. Sorry. I must have had an old tag checked out when I looked at
> > the driver earlier. The DMA API usage in the driver in v4.11-rc6 and
> > current master looks fine, except for one thing:
> >
> > The flush in flush_dcache_page() (from get_user_pages()) was done with a
> > v6_flush_kern_dcache_page() which always did a clean+invalidate while
> > the DMA API only does what is required by the direction, which is only a
> > invalidate for DMA_FROM_DEVICE. Since the driver calls dma_from_sg() on
> > the entire page, even if userspace sent in an offset into the page,
> > unrelated data in userspace may be thrown away.
> >
> > Does changing the dma API calls to always use DMA_BIDIRECTIONAL make the
> > test pass?
>
> Unfortunately not (at least not that simple).
>
> Do we need special DMA mapping attributes here ? Or a dma_sync_sg_for_* ?
I had a look at the driver when you first reported the problem, but I
don't see an obvious problem.
In drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c, I
see it using get_user_pages(), generating a scatterlist, which it then
uses dma_map_sg() with. It then goes on to populate the DMA coherent
buffer that it allocated with the DMA addresses of these buffers.
The tear-down looks sane too - free_pagelist() looks like it correctly
unmaps the scatterlist, marks the pages dirty if necessary, puts the
pages and frees the DMA coherent memory.
Since you're running on a PIPT cache, the only possible issue is whether
there's a lifetime mismatch between what happens here, and what you're
doing with the pages in userspace. All the rules wrt the DMA API apply
to these userspace pages, just as these same rules apply in kernel space.
Once you have called dma_map_sg() on them, any CPU access (whether
explicit or speculative) will cause cache lines to be populated, and
possibly marked dirty, which can have the effect of corrupting the data
unless it is unmapped prior to the accesses you care about.
What I can't see is how changing flush_dcache_page() has possibly broken
this: it seems to imply that you're getting flush_dcache_page() somehow
called inbetween mapping it for DMA, using it for DMA and CPU accesses
occuring. However, the driver doesn't call flush_dcache_page() other
than through get_user_pages() - and since dma_map_sg() is used in that
path, it should be fine.
So, I don't have much to offer.
However, flush_dcache_page() is probably still a tad heavy - it currently
flushes to the point of coherency, but it's really about making sure that
the user vs kernel mappings are coherent, not about device coherency.
That's the role of the DMA API.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] arm64: pmuv3: Support v8.1 PMUv3 extension
From: Jayachandran C @ 2017-04-24 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424140348.GB5767@leverpostej>
On Mon, Apr 24, 2017 at 03:03:48PM +0100, Mark Rutland wrote:
> On Mon, Apr 24, 2017 at 01:39:30PM +0000, Jayachandran C wrote:
> > The v8.1 supplement is quite clear on the field definition:
> >
> > PMUVer, bits [11:8]
> > ....
> > Defined values are:
> > 0000 Performance Monitors extension System registers not implemented.
> > 0001 Performance Monitors extension System registers implemented, PMUv3.
> > 0100 Performance Monitors extension System registers implemented, PMUv3, with a 16-bit
> > evtCount field, and if EL2 is implemented, the addition of the MDCR_EL2.HPMD bit.
> > 1111 IMPLEMENTATION DEFINED form of performance monitors supported, PMUv3 not
> > supported.
> > All other values are reserved.
> > In ARMv8-A the permitted values are 0b0000, 0b0001 and 0b1111.
> > In ARMv8.1 the permitted values are 0b0000, 0b0100 and 0b1111.
> >
> > I changed the code to strictly do this. We have to exclude 0xf, since that is not PMUv3.
> > And we cannot predict what the reserved values will represent, so it is best to skip them
> > until they are defined to be PMUv3 compatible.
>
> My understanding is that ID_AA64DFR0.PMUVer is intended to be covered by
> the usual ID register principles, and thus at least 0x2-0x7 are reserved
> for architected backwards compatible extensions to PMUv3.
>
> See ARM DDI 0487B.a, D7.1.4, "Principles of the ID scheme for fields in
> ID registers". It is explicitly stated that the scheme applies to
> ID_AA64DFR0.
>
> Per those rules, we should check >= the minimum PMUv3 implemented value,
> i.e. val >= 1. Due to both 0x0 and 0xF meaning PMUv3 isn't implemented,
> it's not clear if the fields should be treated as if it were signed or
> unsigned, and I'm awaiting clarification on this.
Thanks for the reference. Since 0xf means that there is a PMU (but it is
not PMUv3), this looks like an unsigned ID with a special case.
> Either way, I believe that 0x1-0x7 must all be compatible with baseline
> PMUv3 per the ID scheme principles.
In case you don't get authoritative information on this, can you please
merge a version which does either 'if (pmuver < 1 || pmuver == 0xf)' or
'if (pmuver < 1 || pmuver > 7)' to the patchset?
Thanks,
JC.
^ permalink raw reply
* [PATCH] iommu/arm-smmu: Return IOVA in iova_to_phys when SMMU is bypassed
From: Sunil Kovvuri @ 2017-04-24 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160030.GQ12323@arm.com>
On Mon, Apr 24, 2017 at 9:30 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Apr 24, 2017 at 09:23:16PM +0530, Sunil Kovvuri wrote:
>> On Mon, Apr 24, 2017 at 8:14 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Mon, Apr 17, 2017 at 05:27:26PM +0530, sunil.kovvuri at gmail.com wrote:
>> >> From: Sunil Goutham <sgoutham@cavium.com>
>> >>
>> >> For software initiated address translation, when domain type is
>> >> IOMMU_DOMAIN_IDENTITY i.e SMMU is bypassed, mimic HW behavior
>> >> i.e return the same IOVA as translated address.
>> >>
>> >> This patch is an extension to Will Deacon's patchset
>> >> "Implement SMMU passthrough using the default domain".
>> >
>> > Are you actually seeing an issue here? If so, why isn't SMMUv3 affected too?
>> Yes and SMMUv3 should also be effected but as of now I don't see any use case.
>> If needed, i can re-submit the patch with changes in SMMUv3 as well.
>
> Yes, please.
>
>> >> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
>> >> ---
>> >> drivers/iommu/arm-smmu.c | 3 +++
>> >> 1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> >> index 41afb07..2f4a130 100644
>> >> --- a/drivers/iommu/arm-smmu.c
>> >> +++ b/drivers/iommu/arm-smmu.c
>> >> @@ -1405,6 +1405,9 @@ static phys_addr_t arm_smmu_iova_to_phys(struct iommu_domain *domain,
>> >> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> >> struct io_pgtable_ops *ops= smmu_domain->pgtbl_ops;
>> >>
>> >> + if (domain->type == IOMMU_DOMAIN_IDENTITY)
>> >> + return iova;
>> >> +
>> >> if (!ops)
>> >> return 0;
>> >
>> > I'd have thought ops would be NULL, since arm_smmu_init_domain_context
>> > doesn't allocate them for an identity domain.
>> Yes ops is set to NULL.
>
> Argh, sorry, I completely overlooked that we return 0 in that case, rather
> than the iova.
>
>> > I don't understand this patch. Please can you explain the problem more
>> > clearly?
>> AFAIK for any driver outside IOMMU there is only one way to identify
>> if device is attached to
>> IOMMU or not and that is by checking iommu_domain. And I don't think
>> it would be appropriate
>> for the driver to check domain->type before calling 'iommu_iova_to_phys()' API.
>>
>> The difference between IOMMU disabled and IOMMU being in passthrough
>> mode is that, in the
>> later case device is still attached to default domain but in former's
>> case it's NULL. So there is no
>> way to differentiate for the external driver whether IOMMU is in
>> passthrough mode or DMA mode.
>>
>> And since ops is NULL in passthrough mode, 'iommu_iova_to_phys()' will
>> return zero.
>>
>> Use case for your reference
>> https://lkml.org/lkml/2017/3/7/299
>> This driver is for a NIC interface on platform which supports SMMUv2.
>
> Blimey, that driver is horrible, but I take your point on the API. Please
> repost, fixing SMMUv3 at the same time.
Sure, will re-submit the patch with SMMUv3 changes.
On a separate note, if you have time, I would definitely like to know
your feedback and what's horrible in that driver, probably in a different
email to keep that out of scope of this patch.
Thanks,
Sunil.
^ permalink raw reply
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: Catalin Marinas @ 2017-04-24 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424155841.GH25449@e104818-lin.cambridge.arm.com>
On Mon, Apr 24, 2017 at 04:58:41PM +0100, Catalin Marinas wrote:
> On Mon, Apr 24, 2017 at 04:40:23PM +0100, Will Deacon wrote:
> > On Wed, Apr 19, 2017 at 11:33:14AM +0100, Catalin Marinas wrote:
> > > On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
> > > > On 18 April 2017 at 18:01, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > > > On Thu, Apr 13, 2017 at 08:33:52PM +0800, dongbo (E) wrote:
> > > > >> From: Dong Bo <dongbo4@huawei.com>
> > > > >>
> > > > >> In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
> > > > >> the flag is propagated to its child processes, even the elf
> > > > >> files are marked as not requiring executable stack. It may
> > > > >> cause superfluous operations on some arch, e.g.
> > > > >> __sync_icache_dcache on aarch64 due to a PROT_READ mmap is
> > > > >> also marked as PROT_EXEC.
> > > >
> > > > > That's affecting most architectures with a risk of ABI breakage. We
> > > > > could do it on arm64 only, though I'm not yet clear on the ABI
> > > > > implications (at a first look, there shouldn't be any).
> > > >
> > > > Is there a reason why it isn't just straightforwardly a bug
> > > > (which we could fix) to make READ_IMPLIES_EXEC propagate to
> > > > child processes?
> > >
> > > While I agree that it looks like a bug, if there are user programs
> > > relying on such bug we call it "ABI". On arm64, I don't think there is
> > > anything relying on inheriting READ_IMPLIES_EXEC but I wouldn't change
> > > the compat task handling without the corresponding change in arch/arm.
> > >
> > > > AFAICT this should be per-process: just because
> > > > init happens not to have been (re)compiled to permit non-executable
> > > > stacks doesn't mean every process on the system needs to have
> > > > an executable stack.
> > >
> > > I think this also affects the heap if brk(2) is used (via
> > > VM_DATA_DEFAULT_FLAGS though I guess malloc mostly uses mmap these
> > > days).
> >
> > I think it also affects mprotect, which is more worrying imo, particularly
> > for things like JIT code that is ported from 32-bit (although a quick look
> > at v8, ionmonkey and art suggests they all pass PROT_EXEC when needed).
>
> As Peter said, the default behaviour is READ_IMPLIES_EXEC off,
For the record, just to clarify the "default" behaviour: what I meant is
that the (newish) toolchain always generates the GNU_STACK header which
disables the executable stack (and therefore READ_IMPLIES_EXEC is off).
--
Catalin
^ permalink raw reply
* [Bug] VCHIQ functional test broken
From: Stefan Wahren @ 2017-04-24 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420195822.GA22677@laptop>
Am 20.04.2017 um 21:58 schrieb Rabin Vincent:
> On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
>> I'm confused by what you're saying here. The driver has already been
>> converted to not use dmac_map_area (commit
>> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
>> matching the radeon driver you give as a model as far as I can see.
>> That commit is in v4.11-rc6 from Stefan's regression report.
> Right. Sorry. I must have had an old tag checked out when I looked at
> the driver earlier. The DMA API usage in the driver in v4.11-rc6 and
> current master looks fine, except for one thing:
>
> The flush in flush_dcache_page() (from get_user_pages()) was done with a
> v6_flush_kern_dcache_page() which always did a clean+invalidate while
> the DMA API only does what is required by the direction, which is only a
> invalidate for DMA_FROM_DEVICE. Since the driver calls dma_from_sg() on
> the entire page, even if userspace sent in an offset into the page,
> unrelated data in userspace may be thrown away.
>
> Does changing the dma API calls to always use DMA_BIDIRECTIONAL make the
> test pass?
Unfortunately not (at least not that simple).
Do we need special DMA mapping attributes here ? Or a dma_sync_sg_for_* ?
^ permalink raw reply
* [PATCH v4 03/10] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
From: icenowy at aosc.io @ 2017-04-24 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-4-icenowy@aosc.io>
? 2017-04-25 00:00?Icenowy Zheng ???
> Add support for the newly imported compatible for the A64 R_INTC in
> irq-sunxi-nmi driver
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> New patch in v4, which is part of NMI refactor.
>
> drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/irqchip/irq-sunxi-nmi.c
> b/drivers/irqchip/irq-sunxi-nmi.c
> index 668730c5cb66..5f7408b1cd4d 100644
> --- a/drivers/irqchip/irq-sunxi-nmi.c
> +++ b/drivers/irqchip/irq-sunxi-nmi.c
> @@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs =
> {
> .enable = 0x04,
> };
>
> +static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
> + .ctrl = 0x0c,
> + .pend = 0x10,
> + .enable = 0x40,
> +};
> +
> static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32
> off,
> u32 val)
> {
> @@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct
> device_node *node,
> return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
> }
> IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi",
> sun9i_nmi_irq_init);
> +
> +static int __init sun50i_nmi_irq_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
> +}
> +IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a80-nmi",
> sun50i_nmi_irq_init);
Should be:
+IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a64-r-intc",
sun50i_nmi_irq_init);
Sorry!
Thanks,
Icenowy
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Increase SMMU CMD queue poll timeout
From: Will Deacon @ 2017-04-24 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493035176-3633-1-git-send-email-gakula@caviumnetworks.com>
On Mon, Apr 24, 2017 at 05:29:36PM +0530, Geetha sowjanya wrote:
> From: Geetha <gakula@cavium.com>
>
> When large memory is being unmapped, huge no of tlb invalidation cmds are
> submitted followed by a SYNC command. This sometimes hits CMD queue full and
> poll on queue drain is being timedout throwing error message 'CMD_SYNC timeout'.
>
> Although there is no functional issue, error message confuses user. Hence increased
> poll timeout to 500us
Hmm, what are you doing to unmap that much? Is this VFIO teardown? Do you
have 7c6d90e2bb1a ("iommu/io-pgtable-arm: Fix iova_to_phys for block
entries") applied?
Will
>
> Signed-off-by: Geetha <gakula@cavium.com>
> ---
> drivers/iommu/arm-smmu-v3.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 591bb96..1dcd154 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -407,7 +407,7 @@
> #define PRIQ_1_ADDR_MASK 0xfffffffffffffUL
>
> /* High-level queue structures */
> -#define ARM_SMMU_POLL_TIMEOUT_US 100
> +#define ARM_SMMU_POLL_TIMEOUT_US 500
>
> #define MSI_IOVA_BASE 0x8000000
> #define MSI_IOVA_LENGTH 0x100000
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 3/4] pinctrl: stm32: Implement .get_direction gpio_chip callback
From: Alexandre Torgue @ 2017-04-24 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZG-yxMCzBqP2s37QThP7tgWKgd3pVgZGgceB+ihZs3nw@mail.gmail.com>
Hi Linus,
On 04/24/2017 02:37 PM, Linus Walleij wrote:
> On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
> <alexandre.torgue@st.com> wrote:
>
>> Add .get_direction() gpiochip callback in STM32 pinctrl driver.
>>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>
> (...)
>> +#include <linux/gpio.h>
>
> No this is wrong, drivers should never include this file.
> It is a deprecated consumer header.
>
>> + if ((alt == 0) && (mode == 0))
>> + ret = GPIOF_DIR_IN;
>> + else if ((alt == 0) && (mode == 1))
>> + ret = GPIOF_DIR_OUT;
>
> Just return 0 or 1, that is the driver-internal API.
Ok. I will fix it in V2.
Thanks
Alex
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* [PATCH v2 6/7] ARM: Kconfig: Introduce MACH_STM32F469 flag
From: Alexandre Torgue @ 2017-04-24 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZmWFKaZWB8qZaH=jB61xdwvJ=TC8idYH9kJdi=HEZRAA@mail.gmail.com>
Hi
On 04/24/2017 02:30 PM, Linus Walleij wrote:
> On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
> <alexandre.torgue@st.com> wrote:
>
>> This patch introduces the MACH_STM32F469 to make possible to only select
>> STM32F469 pinctrl driver
>>
>> By default, all the MACH_STM32Fxxx flags will be set with STM32 defconfig.
>>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Please funnel this through the ARM SoC tree.
Yes, I'll merge it in future pull request.
Thanks for the series.
Regards
Alex
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* [PATCH] fs: Preventing READ_IMPLIES_EXEC Propagation
From: Will Deacon @ 2017-04-24 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424155841.GH25449@e104818-lin.cambridge.arm.com>
On Mon, Apr 24, 2017 at 04:58:41PM +0100, Catalin Marinas wrote:
> On Mon, Apr 24, 2017 at 04:40:23PM +0100, Will Deacon wrote:
> > On Wed, Apr 19, 2017 at 11:33:14AM +0100, Catalin Marinas wrote:
> > > On Tue, Apr 18, 2017 at 09:01:52PM +0100, Peter Maydell wrote:
> > > > On 18 April 2017 at 18:01, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > > > On Thu, Apr 13, 2017 at 08:33:52PM +0800, dongbo (E) wrote:
> > > > >> From: Dong Bo <dongbo4@huawei.com>
> > > > >>
> > > > >> In load_elf_binary(), once the READ_IMPLIES_EXEC flag is set,
> > > > >> the flag is propagated to its child processes, even the elf
> > > > >> files are marked as not requiring executable stack. It may
> > > > >> cause superfluous operations on some arch, e.g.
> > > > >> __sync_icache_dcache on aarch64 due to a PROT_READ mmap is
> > > > >> also marked as PROT_EXEC.
> > > >
> > > > > That's affecting most architectures with a risk of ABI breakage. We
> > > > > could do it on arm64 only, though I'm not yet clear on the ABI
> > > > > implications (at a first look, there shouldn't be any).
> > > >
> > > > Is there a reason why it isn't just straightforwardly a bug
> > > > (which we could fix) to make READ_IMPLIES_EXEC propagate to
> > > > child processes?
> > >
> > > While I agree that it looks like a bug, if there are user programs
> > > relying on such bug we call it "ABI". On arm64, I don't think there is
> > > anything relying on inheriting READ_IMPLIES_EXEC but I wouldn't change
> > > the compat task handling without the corresponding change in arch/arm.
> > >
> > > > AFAICT this should be per-process: just because
> > > > init happens not to have been (re)compiled to permit non-executable
> > > > stacks doesn't mean every process on the system needs to have
> > > > an executable stack.
> > >
> > > I think this also affects the heap if brk(2) is used (via
> > > VM_DATA_DEFAULT_FLAGS though I guess malloc mostly uses mmap these
> > > days).
> >
> > I think it also affects mprotect, which is more worrying imo, particularly
> > for things like JIT code that is ported from 32-bit (although a quick look
> > at v8, ionmonkey and art suggests they all pass PROT_EXEC when needed).
>
> As Peter said, the default behaviour is READ_IMPLIES_EXEC off, so JIT
> code must already pass PROT_EXEC if it wants executable permission. The
> question is whether any user code relies on READ_IMPLIES_EXEC being
> passed down to child processes. I don't think so but I would be
> reluctant to make an such cross-arch change (happy to do it for arm64
> though).
I was thinking of the case where init has an executable stack, but that's
not the common case and such code would be broken under a different init
anyway, so I agree that we should make this change for arm64 (but not compat
without arch/arm/).
Will
^ permalink raw reply
* [PATCH v4 10/10] arm64: allwinner: a64: enable Wi-Fi for Pine64
From: Icenowy Zheng @ 2017-04-24 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
The Wi-Fi module of Pine64 is powered via DLDO4 and ELDO1 (the latter
one provides I/O voltage).
Add device node for it.
Although the Wi-Fi module is an external module which should be inserted
to a header, according to my personal talk with TL Lim, he does not want
this header to be used as GPIO (so it's with 2.0mm pitch, not 2.54mm as
other GPIO headers).
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index abc1879e91f2..2e4f44800162 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -64,6 +64,11 @@
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+ };
};
&ehci1 {
@@ -91,6 +96,17 @@
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dldo4>;
+ vqmmc-supply = <®_eldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ non-removable;
+ bus-width = <4>;
+ status = "okay";
+};
+
&ohci1 {
status = "okay";
};
--
2.12.2
^ permalink raw reply related
* [PATCH v4 09/10] arm64: allwinner: a64: enable AXP803 regulators for Pine64
From: Icenowy Zheng @ 2017-04-24 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
Add support of AXP803 regulators in the Pine64 device tree, in order to
enable many future functionalities, e.g. Wi-Fi.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109 +++++++++++++++++++++
1 file changed, 109 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 3e1b44292534..abc1879e91f2 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -106,6 +106,115 @@
};
};
+#include "axp803.dtsi"
+
+®_aldo1 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "vcc-csi";
+};
+
+®_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-pl";
+};
+
+®_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+®_dc1sw {
+ regulator-name = "vcc-phy";
+};
+
+®_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-3v3";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-name = "vdd-cpux";
+};
+
+/* DCDC3 is polyphased with DCDC2 */
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vcc-dram";
+};
+
+®_dcdc6 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-sys";
+};
+
+®_dldo1 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-hdmi";
+};
+
+®_dldo2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-mipi";
+};
+
+®_dldo3 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "avdd-csi";
+};
+
+®_dldo4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi";
+};
+
+®_eldo1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "cpvdd";
+};
+
+®_eldo3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vdd-1v8-csi";
+};
+
+®_fldo1 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-name = "vcc-1v2-hsic";
+};
+
+®_fldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "vdd-cpus";
+};
+
+®_rtc_ldo {
+ regulator-name = "vcc-rtc";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.12.2
^ permalink raw reply related
* [PATCH v4 08/10] arm64: allwinner: a64: add DTSI file for AXP803 PMIC
From: Icenowy Zheng @ 2017-04-24 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
As nearly all A64 boards are using AXP803 PMIC, add a DTSI file for it,
like the old DTSI files for AXP20x/22x, for the common parts of the
PMIC.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v4:
- Re-sorted the nodes.
arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++++++++++++++++++++++++++++++
1 file changed, 150 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi b/arch/arm64/boot/dts/allwinner/axp803.dtsi
new file mode 100644
index 000000000000..ff8af52743ff
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2017 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP803 Integrated Power Management Chip
+ * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf
+ */
+
+&axp803 {
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ /* Default work frequency for buck regulators */
+ x-powers,dcdc-freq = <3000>;
+
+ reg_aldo1: aldo1 {
+ regulator-name = "aldo1";
+ };
+
+ reg_aldo2: aldo2 {
+ regulator-name = "aldo2";
+ };
+
+ reg_aldo3: aldo3 {
+ regulator-name = "aldo3";
+ };
+
+ reg_dc1sw: dc1sw {
+ regulator-name = "dc1sw";
+ };
+
+ reg_dcdc1: dcdc1 {
+ regulator-name = "dcdc1";
+ };
+
+ reg_dcdc2: dcdc2 {
+ regulator-name = "dcdc2";
+ };
+
+ reg_dcdc3: dcdc3 {
+ regulator-name = "dcdc3";
+ };
+
+ reg_dcdc4: dcdc4 {
+ regulator-name = "dcdc4";
+ };
+
+ reg_dcdc5: dcdc5 {
+ regulator-name = "dcdc5";
+ };
+
+ reg_dcdc6: dcdc6 {
+ regulator-name = "dcdc6";
+ };
+
+ reg_dldo1: dldo1 {
+ regulator-name = "dldo1";
+ };
+
+ reg_dldo2: dldo2 {
+ regulator-name = "dldo2";
+ };
+
+ reg_dldo3: dldo3 {
+ regulator-name = "dldo3";
+ };
+
+ reg_dldo4: dldo4 {
+ regulator-name = "dldo4";
+ };
+
+ reg_eldo1: eldo1 {
+ regulator-name = "eldo1";
+ };
+
+ reg_eldo2: eldo2 {
+ regulator-name = "eldo2";
+ };
+
+ reg_eldo3: eldo3 {
+ regulator-name = "eldo3";
+ };
+
+ reg_fldo1: fldo1 {
+ regulator-name = "fldo1";
+ };
+
+ reg_fldo2: fldo2 {
+ regulator-name = "fldo2";
+ };
+
+ reg_ldo_io0: ldo-io0 {
+ regulator-name = "ldo-io0";
+ status = "disabled";
+ };
+
+ reg_ldo_io1: ldo-io1 {
+ regulator-name = "ldo-io1";
+ status = "disabled";
+ };
+
+ reg_rtc_ldo: rtc-ldo {
+ /* RTC_LDO is a fixed, always-on regulator */
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "rtc-ldo";
+ };
+ };
+};
--
2.12.2
^ permalink raw reply related
* [PATCH v4 07/10] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Icenowy Zheng @ 2017-04-24 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
As axp20x-regulator now supports AXP803, add a cell for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
Changes in v4:
- Added a trailing comma for new cell, for easier further cell addition.
Changes in v3:
- Make the new cell one-liner.
drivers/mfd/axp20x.c | 3 ++-
drivers/regulator/axp20x-regulator.c | 6 +++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 1dc6235778eb..917b6ddc4f15 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -848,7 +848,8 @@ static struct mfd_cell axp803_cells[] = {
.name = "axp20x-pek",
.num_resources = ARRAY_SIZE(axp803_pek_resources),
.resources = axp803_pek_resources,
- }
+ },
+ { .name = "axp20x-regulator" },
};
static struct mfd_cell axp806_cells[] = {
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 9356ec8a9a1f..e2608fe770b9 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -311,13 +311,13 @@ static const struct regulator_desc axp803_regulators[] = {
AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
- AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+ AXP_DESC_IO(AXP803, LDO_IO0, "ldo-io0", "ips", 700, 3300, 100,
AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
- AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
+ AXP_DESC_IO(AXP803, LDO_IO1, "ldo-io1", "ips", 700, 3300, 100,
AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
- AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc_ldo", "ips", 3000),
+ AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc-ldo", "ips", 3000),
};
static const struct regulator_linear_range axp806_dcdca_ranges[] = {
--
2.12.2
^ permalink raw reply related
* [PATCH v4 06/10] regulator: axp20x-regulator: add support for AXP803
From: Icenowy Zheng @ 2017-04-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
controllable via I2C/RSB bus.
Add support for them.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
Changes in v4:
- Fixed somewhere which mention AXP806 before 803.
Changes in v2:
- Place AXP803 codes before AXP806/809 ones.
- Fixed some errors in regulator description.
- Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.
drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++++++++++++++-----
include/linux/mfd/axp20x.h | 37 +++++++++
2 files changed, 168 insertions(+), 22 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 0b9d4e3e52c7..9356ec8a9a1f 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,82 @@ static const struct regulator_desc axp22x_drivevbus_regulator = {
.ops = &axp20x_ops_sw,
};
+static const struct regulator_linear_range axp803_dcdc234_ranges[] = {
+ REGULATOR_LINEAR_RANGE(500000, 0x0, 0x46, 10000),
+ REGULATOR_LINEAR_RANGE(1220000, 0x47, 0x4b, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc5_ranges[] = {
+ REGULATOR_LINEAR_RANGE(800000, 0x0, 0x20, 10000),
+ REGULATOR_LINEAR_RANGE(1140000, 0x21, 0x44, 20000),
+};
+
+static const struct regulator_linear_range axp803_dcdc6_ranges[] = {
+ REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
+ REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
+};
+
+/* AXP806's CLDO2 and AXP809's DLDO1 shares the same range */
+static const struct regulator_linear_range axp803_dldo2_ranges[] = {
+ REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
+ REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
+};
+
+static const struct regulator_desc axp803_regulators[] = {
+ AXP_DESC(AXP803, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+ AXP803_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+ AXP_DESC_RANGES(AXP803, DCDC2, "dcdc2", "vin2", axp803_dcdc234_ranges,
+ 76, AXP803_DCDC2_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(1)),
+ AXP_DESC_RANGES(AXP803, DCDC3, "dcdc3", "vin3", axp803_dcdc234_ranges,
+ 76, AXP803_DCDC3_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(2)),
+ AXP_DESC_RANGES(AXP803, DCDC4, "dcdc4", "vin4", axp803_dcdc234_ranges,
+ 76, AXP803_DCDC4_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(3)),
+ AXP_DESC_RANGES(AXP803, DCDC5, "dcdc5", "vin5", axp803_dcdc5_ranges,
+ 68, AXP803_DCDC5_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(4)),
+ AXP_DESC_RANGES(AXP803, DCDC6, "dcdc6", "vin6", axp803_dcdc6_ranges,
+ 72, AXP803_DCDC6_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
+ BIT(5)),
+ /* secondary switchable output of DCDC1 */
+ AXP_DESC_SW(AXP803, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+ BIT(7)),
+ AXP_DESC(AXP803, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+ AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(5)),
+ AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+ AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(6)),
+ AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+ AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(7)),
+ AXP_DESC(AXP803, DLDO1, "dldo1", "dldoin", 700, 3300, 100,
+ AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(3)),
+ AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin", axp803_dldo2_ranges,
+ 32, AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+ BIT(4)),
+ AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
+ AXP22X_DLDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+ AXP_DESC(AXP803, DLDO4, "dldo4", "dldoin", 700, 3300, 100,
+ AXP22X_DLDO4_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(6)),
+ AXP_DESC(AXP803, ELDO1, "eldo1", "eldoin", 700, 1900, 50,
+ AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+ AXP_DESC(AXP803, ELDO2, "eldo2", "eldoin", 700, 1900, 50,
+ AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+ AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
+ AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+ AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
+ AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
+ AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
+ AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
+ AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+ AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+ AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+ AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
+ AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
+ AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+ AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc_ldo", "ips", 3000),
+};
+
static const struct regulator_linear_range axp806_dcdca_ranges[] = {
REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
@@ -254,11 +330,6 @@ static const struct regulator_linear_range axp806_dcdcd_ranges[] = {
REGULATOR_LINEAR_RANGE(1600000, 0x2e, 0x3f, 100000),
};
-static const struct regulator_linear_range axp806_cldo2_ranges[] = {
- REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
- REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
-};
-
static const struct regulator_desc axp806_regulators[] = {
AXP_DESC_RANGES(AXP806, DCDCA, "dcdca", "vina", axp806_dcdca_ranges,
72, AXP806_DCDCA_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
@@ -289,7 +360,7 @@ static const struct regulator_desc axp806_regulators[] = {
AXP806_BLDO4_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(3)),
AXP_DESC(AXP806, CLDO1, "cldo1", "cldoin", 700, 3300, 100,
AXP806_CLDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(4)),
- AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp806_cldo2_ranges,
+ AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp803_dldo2_ranges,
32, AXP806_CLDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2,
BIT(5)),
AXP_DESC(AXP806, CLDO3, "cldo3", "cldoin", 700, 3300, 100,
@@ -326,7 +397,7 @@ static const struct regulator_desc axp809_regulators[] = {
AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
- AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp806_cldo2_ranges,
+ AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp803_dldo2_ranges,
32, AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
BIT(3)),
AXP_DESC(AXP809, DLDO2, "dldo2", "dldoin", 700, 3300, 100,
@@ -369,14 +440,21 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
def = 1500;
step = 75;
break;
- case AXP806_ID:
+ case AXP803_ID:
/*
- * AXP806 DCDC work frequency setting has the same range and
+ * AXP803 DCDC work frequency setting has the same range and
* step as AXP22X, but at a different register.
* Fall through to the check below.
* (See include/linux/mfd/axp20x.h)
*/
- reg = AXP806_DCDC_FREQ_CTRL;
+ reg = AXP803_DCDC_FREQ_CTRL;
+ case AXP806_ID:
+ /*
+ * AXP806 also have DCDC work frequency setting register at a
+ * different position.
+ */
+ if (axp20x->variant == AXP806_ID)
+ reg = AXP806_DCDC_FREQ_CTRL;
case AXP221_ID:
case AXP223_ID:
case AXP809_ID:
@@ -475,6 +553,14 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
workmode <<= id - AXP22X_DCDC1;
break;
+ case AXP803_ID:
+ if (id < AXP803_DCDC1 || id > AXP803_DCDC6)
+ return -EINVAL;
+
+ mask = AXP22X_WORKMODE_DCDCX_MASK(id - AXP803_DCDC1);
+ workmode <<= id - AXP803_DCDC1;
+ break;
+
default:
/* should not happen */
WARN_ON(1);
@@ -492,20 +578,38 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
{
u32 reg = 0;
- /* Only AXP806 has poly-phase outputs */
- if (axp20x->variant != AXP806_ID)
- return false;
+ /*
+ * Currently in our supported AXP variants, only AXP803 and AXP806
+ * have polyphase regulators.
+ */
+ switch (axp20x->variant) {
+ case AXP803_ID:
+ regmap_read(axp20x->regmap, AXP803_POLYPHASE_CTRL, ®);
+
+ switch (id) {
+ case AXP803_DCDC3:
+ return !!(reg & BIT(6));
+ case AXP803_DCDC6:
+ return !!(reg & BIT(7));
+ }
+ break;
- regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, ®);
+ case AXP806_ID:
+ regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, ®);
+
+ switch (id) {
+ case AXP806_DCDCB:
+ return (((reg & GENMASK(7, 6)) == BIT(6)) ||
+ ((reg & GENMASK(7, 6)) == BIT(7)));
+ case AXP806_DCDCC:
+ return ((reg & GENMASK(7, 6)) == BIT(7));
+ case AXP806_DCDCE:
+ return !!(reg & BIT(5));
+ }
+ break;
- switch (id) {
- case AXP806_DCDCB:
- return (((reg & GENMASK(7, 6)) == BIT(6)) ||
- ((reg & GENMASK(7, 6)) == BIT(7)));
- case AXP806_DCDCC:
- return ((reg & GENMASK(7, 6)) == BIT(7));
- case AXP806_DCDCE:
- return !!(reg & BIT(5));
+ default:
+ return false;
}
return false;
@@ -540,6 +644,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
"x-powers,drive-vbus-en");
break;
+ case AXP803_ID:
+ regulators = axp803_regulators;
+ nregulators = AXP803_REG_ID_MAX;
+ break;
case AXP806_ID:
regulators = axp806_regulators;
nregulators = AXP806_REG_ID_MAX;
@@ -579,6 +687,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
* name.
*/
if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
+ (regulators == axp803_regulators && i == AXP803_DC1SW) ||
(regulators == axp809_regulators && i == AXP809_DC1SW)) {
new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
GFP_KERNEL);
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index cde56cfe8446..965b027e31b3 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -119,6 +119,17 @@ enum axp20x_variants {
#define AXP806_BUS_ADDR_EXT 0xfe
#define AXP806_REG_ADDR_EXT 0xff
+#define AXP803_POLYPHASE_CTRL 0x14
+#define AXP803_FLDO1_V_OUT 0x1c
+#define AXP803_FLDO2_V_OUT 0x1d
+#define AXP803_DCDC1_V_OUT 0x20
+#define AXP803_DCDC2_V_OUT 0x21
+#define AXP803_DCDC3_V_OUT 0x22
+#define AXP803_DCDC4_V_OUT 0x23
+#define AXP803_DCDC5_V_OUT 0x24
+#define AXP803_DCDC6_V_OUT 0x25
+#define AXP803_DCDC_FREQ_CTRL 0x3b
+
/* Interrupt */
#define AXP152_IRQ1_EN 0x40
#define AXP152_IRQ2_EN 0x41
@@ -350,6 +361,32 @@ enum {
AXP809_REG_ID_MAX,
};
+enum {
+ AXP803_DCDC1 = 0,
+ AXP803_DCDC2,
+ AXP803_DCDC3,
+ AXP803_DCDC4,
+ AXP803_DCDC5,
+ AXP803_DCDC6,
+ AXP803_DC1SW,
+ AXP803_ALDO1,
+ AXP803_ALDO2,
+ AXP803_ALDO3,
+ AXP803_DLDO1,
+ AXP803_DLDO2,
+ AXP803_DLDO3,
+ AXP803_DLDO4,
+ AXP803_ELDO1,
+ AXP803_ELDO2,
+ AXP803_ELDO3,
+ AXP803_FLDO1,
+ AXP803_FLDO2,
+ AXP803_RTC_LDO,
+ AXP803_LDO_IO0,
+ AXP803_LDO_IO1,
+ AXP803_REG_ID_MAX,
+};
+
/* IRQs */
enum {
AXP152_IRQ_LDO0IN_CONNECT = 1,
--
2.12.2
^ permalink raw reply related
* [PATCH v4 05/10] arm64: allwinner: a64: add AXP803 node to Pine64 device tree
From: Icenowy Zheng @ 2017-04-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
The Pine64 (including Pine64+) boards have an AXP803 as its main PMIC.
Add its device node.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index c680ed385da3..3e1b44292534 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -95,6 +95,17 @@
status = "okay";
};
+&r_rsb {
+ status = "okay";
+
+ axp803: pmic at 3a3 {
+ compatible = "x-powers,axp803";
+ reg = <0x3a3>;
+ interrupt-parent = <&r_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.12.2
^ permalink raw reply related
* [PATCH v4 04/10] arm64: allwinner: a64: add NMI (R_INTC) controller on A64
From: Icenowy Zheng @ 2017-04-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
Allwinner A64 SoC features a R_INTC controller, which controls the NMI
line, and this interrupt line is usually connected to the AXP PMIC.
Add support for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
Changes in v4:
- Changes it to use R_INTC binding and change node label to r_intc.
- Fixed MMIO region.
- Dropped Chen-Yu's ACK due to big change.
Changes in v2:
- Added Chen-Yu's ACK.
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 05ec9fc5e81f..a6566d292934 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -403,6 +403,14 @@
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
};
+ r_intc: interrupt-controller at 1f00c00 {
+ compatible = "allwinner,sun50i-a64-r-intc";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x01f00c00 0x400>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
r_ccu: clock at 1f01400 {
compatible = "allwinner,sun50i-a64-r-ccu";
reg = <0x01f01400 0x100>;
--
2.12.2
^ permalink raw reply related
* [PATCH v4 03/10] irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
From: Icenowy Zheng @ 2017-04-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
Add support for the newly imported compatible for the A64 R_INTC in
irq-sunxi-nmi driver
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
New patch in v4, which is part of NMI refactor.
drivers/irqchip/irq-sunxi-nmi.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
index 668730c5cb66..5f7408b1cd4d 100644
--- a/drivers/irqchip/irq-sunxi-nmi.c
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -56,6 +56,12 @@ static struct sunxi_sc_nmi_reg_offs sun9i_reg_offs = {
.enable = 0x04,
};
+static struct sunxi_sc_nmi_reg_offs sun50i_reg_offs = {
+ .ctrl = 0x0c,
+ .pend = 0x10,
+ .enable = 0x40,
+};
+
static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
u32 val)
{
@@ -220,3 +226,10 @@ static int __init sun9i_nmi_irq_init(struct device_node *node,
return sunxi_sc_nmi_irq_init(node, &sun9i_reg_offs);
}
IRQCHIP_DECLARE(sun9i_nmi, "allwinner,sun9i-a80-nmi", sun9i_nmi_irq_init);
+
+static int __init sun50i_nmi_irq_init(struct device_node *node,
+ struct device_node *parent)
+{
+ return sunxi_sc_nmi_irq_init(node, &sun50i_reg_offs);
+}
+IRQCHIP_DECLARE(sun50i_nmi, "allwinner,sun50i-a80-nmi", sun50i_nmi_irq_init);
--
2.12.2
^ permalink raw reply related
* [PATCH v4 02/10] irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
From: Icenowy Zheng @ 2017-04-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
The A31 NMI driver seems to be using wrong base address.
As we're going to convert to use a correct NMI base address (and
correctly name it to R_INTC as the datasheet suggests), add a new
compatible string for the "correct" R_INTC, which we will use for A64
SoC.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
---
New patch in v4, which is part of NMI refactor.
.../bindings/interrupt-controller/allwinner,sunxi-nmi.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
index 81cd3692405e..fea0c6a6211f 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-nmi.txt
@@ -3,8 +3,11 @@ Allwinner Sunxi NMI Controller
Required properties:
-- compatible : should be "allwinner,sun7i-a20-sc-nmi" or
- "allwinner,sun6i-a31-sc-nmi" or "allwinner,sun9i-a80-nmi"
+- compatible : should be one of:
+ "allwinner,sun6i-a31-sc-nmi"
+ "allwinner,sun7i-a20-sc-nmi"
+ "allwinner,sun9i-a80-nmi"
+ "allwinner,sun50i-a64-r-intc"
- reg : Specifies base physical address and size of the registers.
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
--
2.12.2
^ permalink raw reply related
* [PATCH v4 01/10] arm64: allwinner: a64: enable RSB on A64
From: Icenowy Zheng @ 2017-04-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424160103.9447-1-icenowy@aosc.io>
Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
Add it and its pinmux.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
Changes in v2:
- Removed bonus properties in pio node.
- Added Chen-Yu's ACK.
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index c7f669f5884f..05ec9fc5e81f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -422,6 +422,25 @@
#gpio-cells = <3>;
interrupt-controller;
#interrupt-cells = <3>;
+
+ r_rsb_pins: rsb at 0 {
+ pins = "PL0", "PL1";
+ function = "s_rsb";
+ };
+ };
+
+ r_rsb: rsb at 1f03400 {
+ compatible = "allwinner,sun8i-a23-rsb";
+ reg = <0x01f03400 0x400>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu 6>;
+ clock-frequency = <3000000>;
+ resets = <&r_ccu 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_rsb_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
};
};
};
--
2.12.2
^ permalink raw reply related
* [PATCH v4 00/10] AXP803 PMIC support for Pine64
From: Icenowy Zheng @ 2017-04-24 16:00 UTC (permalink / raw)
To: linux-arm-kernel
The Pine64 (including Pine64+) boards have an AXP803 PMIC, which is a PMIC
similar to AXP288, but tweaked to use with Allwinner SoCs rather than Intel
tablets (with DCIN and Vbus re-splitted like other AXP PMICs, and RSB bus
support added).
This patchset adds support for it and enabled it in Pine64 device tree.
The basical part of AXP803 MFD driver is already applied, according to Lee.
Thus this patchset is now still two parts, but a bit different to older
revisions:
- Part1: from PATCH 1/10 to PATCH 5/10, which focus on enabling AXP803 in
the device tree: the RSB bus, the R_INTC interrupt controller (for the
NMI line, which is connected to AXP803 on Pine64), and finally the basical
AXP803 node.
- Part2: from PATCH 5/10 to PATCH 10/10, which are enabling the regulator
function of the AXP803 PMIC. Finally Wi-Fi function is added
as a usage of regulators function.
PATCH 1 adds RSB device nodes, which is used for the communication between
A64 and AXP803.
PATCH 2 adds device tree binding of A64 R_INTC.
PATCH 3 really adds support for A64 R_INTC in NMI driver.
PATCH 4 adds R_INTC node in A64 device tree.
PATCH 5 adds AXP803 node to the Pine64 device tree by using already
applied drivers/bindings.
PATCH 6 adds support for AXP803 regulators in AXP20x regulatoe driver.
(The binding is already applied)
PATCH 7 enables the AXP803 regulator cell in MFD driver.
PATCH 8 adds a DTSI file for AXP803, like other older AXP PMICs.
PATCH 9 enables AXP803 regulators in Pine64 device tree.
PATCH 10 enables Wi-Fi for Pine64.
Icenowy Zheng (10):
arm64: allwinner: a64: enable RSB on A64
irqchip/sunxi-nmi: add A64 R_INTC to the binding doc
irqchip/sunxi-nmi: add support for the NMI in A64 R_INTC
arm64: allwinner: a64: add NMI (R_INTC) controller on A64
arm64: allwinner: a64: add AXP803 node to Pine64 device tree
regulator: axp20x-regulator: add support for AXP803
mfd: axp20x: add axp20x-regulator cell for AXP803
arm64: allwinner: a64: add DTSI file for AXP803 PMIC
arm64: allwinner: a64: enable AXP803 regulators for Pine64
arm64: allwinner: a64: enable Wi-Fi for Pine64
.../interrupt-controller/allwinner,sunxi-nmi.txt | 7 +-
arch/arm64/boot/dts/allwinner/axp803.dtsi | 150 ++++++++++++++++++++
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 136 ++++++++++++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 27 ++++
drivers/irqchip/irq-sunxi-nmi.c | 13 ++
drivers/mfd/axp20x.c | 3 +-
drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++---
include/linux/mfd/axp20x.h | 37 +++++
8 files changed, 501 insertions(+), 25 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/axp803.dtsi
--
2.12.2
^ 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