* [PATCH v3 8/8] arm64: exception: check shared writable page in SEI handler
From: Xiongfeng Wang @ 2017-04-12 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58E7B6BD.3000401@arm.com>
Hi James,
On 2017/4/7 23:56, James Morse wrote:
> Hi Xie XiuQi,
>
> On 30/03/17 11:31, Xie XiuQi wrote:
>> From: Wang Xiongfeng <wangxiongfeng2@huawei.com>
>>
>> Since SEI is asynchronous, the error data has been consumed. So we must
>> suppose that all the memory data current process can write are
>> contaminated. If the process doesn't have shared writable pages, the
>> process will be killed, and the system will continue running normally.
>> Otherwise, the system must be terminated, because the error has been
>> propagated to other processes running on other cores, and recursively
>> the error may be propagated to several another processes.
>
> This is pretty complicated. We can't guarantee that another CPU hasn't modified
> the page tables while we do this, (so its racy). We can't guarantee that the
> corrupt data hasn't been sent over the network or written to disk in the mean
> time (so its not enough).
>
> The scenario you have is a write of corrupt data to memory where another CPU
> reading it doesn't know the value is corrupt.
>
> The hardware gives us quite a lot of help containing errors. The RAS
> specification (DDI 0587A) describes your scenario as error propagation in '2.1.2
> Architectural error propagation', and then classifies it in '2.1.3
> Architecturally infected, containable and uncontainable' as uncontained because
> the value is no longer in the general-purpose registers. For uncontained errors
> we should panic().
>
> We shouldn't need to try to track errors after we get a notification as the
> hardware has done this for us.
>
Thanks for your comments. I think what you said is reasonable. We will remove this
patch and use AET fields of ESR_ELx to determine whether we should kill current
process or just panic.
>
> Firmware-first does complicate this if events like this are not delivered using
> a synchronous external abort, as Linux may have PSTATE.A masked preventing
> SError Interrupts from being taken. It looks like PSTATE.A is masked much more
> often than is necessary. I will look into cleaning this up.
>
>
> Thanks,
>
> James
>
> .
>
Thanks,
Wang Xiongfeng
^ permalink raw reply
* "Consolidate get_dma_ops" breaks Xen on ARM
From: Catalin Marinas @ 2017-04-12 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1704111411350.2759@sstabellini-ThinkPad-X260>
On Tue, Apr 11, 2017 at 04:39:09PM -0700, Stefano Stabellini wrote:
> On Tue, 11 Apr 2017, Catalin Marinas wrote:
> > On Tue, Apr 11, 2017 at 01:43:28PM +0100, Julien Grall wrote:
> > > On 11/04/17 02:14, Bart Van Assche wrote:
> > > > On 04/10/17 17:31, Stefano Stabellini wrote:
> > > >> I think the reason is that, as you can see, if (dev && dev->dma_ops),
> > > >> dev->dma_ops is returned, while before this changes, xen_dma_ops was
> > > >> returned on Xen on ARM.
> > > >>
> > > >> Unfortunately DMA cannot work properly without using the appropriate
> > > >> xen_dma_ops. See drivers/xen/swiotlb-xen.c and arch/arm/xen/mm.c for
> > > >> more details. (The problem is easy to spot, but I wasn't CC'ed on the
> > > >> patch.)
> > > >>
> > > >> I don't know how to solve this problem without introducing some sort of
> > > >> if (xen()) in include/linux/dma-mapping.h.
> > > >
> > > > Sorry but I don't have access to an ARM development system. Does your
> > > > comment apply to dev == NULL only, dev != NULL only or perhaps to both?
> > > > If your comment applies to dev != NULL only, can you check whether
> > > > adding something like set_dma_ops(dev, get_arch_dma_ops(NULL)) to the
> > > > appropriate ARM arch_setup_dma_ops() function is sufficient?
> > >
> > > If I understand correctly, set_dma_ops will replace dev->dma_ops with
> > > Xen DMA ops.
[...]
> > Yet another way would be for dom0 to always set dev->dma_ops to
> > xen_dma_ops and preserve the real dma_ops somewhere under dev->archdata.
> > You could intercept the arch_setup_dma_ops() function for this or use
> > bus_register_notifier() (though I think the former is easier). The Xen
> > code making use of the real dma_ops would have to dig them out from
> > dev->archdata.
>
> This is a good suggestion, Catalin. Thank you. See below. Is that what
> you have in mind? Julien could you test it, please? If it is the right
> approach, I'll submit the patch properly and rename __generic_dma_ops to
> xen_generic_dma_ops or something.
It looks fine to me (subject to testing successfully).
--
Catalin
^ permalink raw reply
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region
From: Domenico Andreoli @ 2017-04-12 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412082606.17151-1-ard.biesheuvel@linaro.org>
On Wed, Apr 12, 2017 at 09:26:06AM +0100, Ard Biesheuvel wrote:
> When running lscpu on an AArch64 system that has SMBIOS version 2.0
> tables, it will segfault in the following way:
>
> Unable to handle kernel paging request at virtual address ffff8000bfff0000
> pgd = ffff8000f9615000
> [ffff8000bfff0000] *pgd=0000000000000000
> Internal error: Oops: 96000007 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> task: ffff8000fa78e800 task.stack: ffff8000f9780000
> PC is at __arch_copy_to_user+0x90/0x220
> LR is at read_mem+0xcc/0x140
>
> This is caused by the fact that lspci issues a read() on /dev/mem at the
> offset where it expects to find the SMBIOS structure array. However, this
> region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec),
> and so it is omitted from the linear mapping.
>
> So let's restrict /dev/mem read/write access to those areas that are
> covered by the linear region.
>
> Reported-by: Alexander Graf <agraf@suse.de>
> Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/mm/mmap.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
> index 7b0d55756eb1..2956240d17d7 100644
> --- a/arch/arm64/mm/mmap.c
> +++ b/arch/arm64/mm/mmap.c
> @@ -18,6 +18,7 @@
>
> #include <linux/elf.h>
> #include <linux/fs.h>
> +#include <linux/memblock.h>
> #include <linux/mm.h>
> #include <linux/mman.h>
> #include <linux/export.h>
> @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm)
> */
> int valid_phys_addr_range(phys_addr_t addr, size_t size)
> {
> - if (addr < PHYS_OFFSET)
> - return 0;
> - if (addr + size > __pa(high_memory - 1) + 1)
> - return 0;
> -
> - return 1;
> + return memblock_is_map_memory(addr) &&
> + memblock_is_map_memory(addr + size - 1);
> }
>
> /*
Does arch/arm/mm/mmap.c need the same treatment?
Regards,
Domenico
--
3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
^ permalink raw reply
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region
From: Ard Biesheuvel @ 2017-04-12 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a65b0a0b-aeb8-0dcd-2d80-e77962206d7c@suse.de>
On 12 April 2017 at 09:29, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 12.04.17 10:26, Ard Biesheuvel wrote:
>>
>> When running lscpu on an AArch64 system that has SMBIOS version 2.0
>> tables, it will segfault in the following way:
>>
>> Unable to handle kernel paging request at virtual address
>> ffff8000bfff0000
>> pgd = ffff8000f9615000
>> [ffff8000bfff0000] *pgd=0000000000000000
>> Internal error: Oops: 96000007 [#1] PREEMPT SMP
>> Modules linked in:
>> CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
>> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
>> task: ffff8000fa78e800 task.stack: ffff8000f9780000
>> PC is at __arch_copy_to_user+0x90/0x220
>> LR is at read_mem+0xcc/0x140
>>
>> This is caused by the fact that lspci issues a read() on /dev/mem at the
>> offset where it expects to find the SMBIOS structure array. However, this
>> region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec),
>> and so it is omitted from the linear mapping.
>>
>> So let's restrict /dev/mem read/write access to those areas that are
>> covered by the linear region.
>>
>> Reported-by: Alexander Graf <agraf@suse.de>
>> Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as
>> MEMBLOCK_NOMAP")
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> arch/arm64/mm/mmap.c | 9 +++------
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
>> index 7b0d55756eb1..2956240d17d7 100644
>> --- a/arch/arm64/mm/mmap.c
>> +++ b/arch/arm64/mm/mmap.c
>> @@ -18,6 +18,7 @@
>>
>> #include <linux/elf.h>
>> #include <linux/fs.h>
>> +#include <linux/memblock.h>
>> #include <linux/mm.h>
>> #include <linux/mman.h>
>> #include <linux/export.h>
>> @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm)
>> */
>> int valid_phys_addr_range(phys_addr_t addr, size_t size)
>> {
>> - if (addr < PHYS_OFFSET)
>> - return 0;
>> - if (addr + size > __pa(high_memory - 1) + 1)
>> - return 0;
>> -
>> - return 1;
>> + return memblock_is_map_memory(addr) &&
>> + memblock_is_map_memory(addr + size - 1);
>
>
> Is that safe? Are we guaranteed that size is less than one page? Otherwise,
> someone could map a region that spans over a reserved one:
>
> [conv mem]
> [reserved]
> [conv mem]
>
Well, I will leave it to the maintainers to decide how elaborate they
want this logic to become, given that read()ing from /dev/mem is
something we are not eager to support in the first place.
But indeed, if the start and end of the region are covered by the
linear region, there could potentially be an uncovered hole in the
middle.
^ permalink raw reply
* [PATCH 1/2] dt-bindings: Document STM32 I2S bindings
From: Olivier MOYSAN @ 2017-04-12 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170411211040.htrcedus3c57fbed@sirena.org.uk>
Hello Mark,
On 04/11/2017 11:10 PM, Mark Brown wrote:
> On Tue, Apr 11, 2017 at 03:44:52PM +0000, Olivier MOYSAN wrote:
>
>> However, regarding STM32 I2S driver, I'm wondering if selecting DAI
>> is the best way to configure interface as tx, rx or fd.
>
> Why do you even need to configure this?
>
The IP provides two data wires, SD in and SD out. So it can be
configured either as capture or playback only, or full-duplex.
This corresponds to a mode selection through a register configuration.
>> Maybe, it is more relevant to configure DAI according to DMA
>> configuration from I2S node.
>> This would moreover avoid to allocate 2 dmas channels when not
>> necessary (tx or rx only).
>> If you agree with this, I will implement this change in a v2.
>
> That sounds wrong, I'd expect this wiring to be done statically as part
> of the .dtsi for the SoC (or just grabbed as needed at runtime if
> things are flexbile enough) rather than being a configuration thing done
> per board... I had thought that this was configuration reflecting
> different ways of taping out the IP with different feature sets, is that
> not the case?
>
This configuration is board dependent. The IP may be used as rx, tx or
fd depending on board. So I think it can make sense to have a DMA
configuration linked to board, and to set IP mode accordingly.
BRs
olivier
^ permalink raw reply
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region
From: Alexander Graf @ 2017-04-12 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412082606.17151-1-ard.biesheuvel@linaro.org>
On 12.04.17 10:26, Ard Biesheuvel wrote:
> When running lscpu on an AArch64 system that has SMBIOS version 2.0
> tables, it will segfault in the following way:
>
> Unable to handle kernel paging request at virtual address ffff8000bfff0000
> pgd = ffff8000f9615000
> [ffff8000bfff0000] *pgd=0000000000000000
> Internal error: Oops: 96000007 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> task: ffff8000fa78e800 task.stack: ffff8000f9780000
> PC is at __arch_copy_to_user+0x90/0x220
> LR is at read_mem+0xcc/0x140
>
> This is caused by the fact that lspci issues a read() on /dev/mem at the
> offset where it expects to find the SMBIOS structure array. However, this
> region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec),
> and so it is omitted from the linear mapping.
>
> So let's restrict /dev/mem read/write access to those areas that are
> covered by the linear region.
>
> Reported-by: Alexander Graf <agraf@suse.de>
> Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/mm/mmap.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
> index 7b0d55756eb1..2956240d17d7 100644
> --- a/arch/arm64/mm/mmap.c
> +++ b/arch/arm64/mm/mmap.c
> @@ -18,6 +18,7 @@
>
> #include <linux/elf.h>
> #include <linux/fs.h>
> +#include <linux/memblock.h>
> #include <linux/mm.h>
> #include <linux/mman.h>
> #include <linux/export.h>
> @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm)
> */
> int valid_phys_addr_range(phys_addr_t addr, size_t size)
> {
> - if (addr < PHYS_OFFSET)
> - return 0;
> - if (addr + size > __pa(high_memory - 1) + 1)
> - return 0;
> -
> - return 1;
> + return memblock_is_map_memory(addr) &&
> + memblock_is_map_memory(addr + size - 1);
Is that safe? Are we guaranteed that size is less than one page?
Otherwise, someone could map a region that spans over a reserved one:
[conv mem]
[reserved]
[conv mem]
Alex
^ permalink raw reply
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region
From: Ard Biesheuvel @ 2017-04-12 8:26 UTC (permalink / raw)
To: linux-arm-kernel
When running lscpu on an AArch64 system that has SMBIOS version 2.0
tables, it will segfault in the following way:
Unable to handle kernel paging request at virtual address ffff8000bfff0000
pgd = ffff8000f9615000
[ffff8000bfff0000] *pgd=0000000000000000
Internal error: Oops: 96000007 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103
Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
task: ffff8000fa78e800 task.stack: ffff8000f9780000
PC is at __arch_copy_to_user+0x90/0x220
LR is at read_mem+0xcc/0x140
This is caused by the fact that lspci issues a read() on /dev/mem at the
offset where it expects to find the SMBIOS structure array. However, this
region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec),
and so it is omitted from the linear mapping.
So let's restrict /dev/mem read/write access to those areas that are
covered by the linear region.
Reported-by: Alexander Graf <agraf@suse.de>
Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/mm/mmap.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index 7b0d55756eb1..2956240d17d7 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -18,6 +18,7 @@
#include <linux/elf.h>
#include <linux/fs.h>
+#include <linux/memblock.h>
#include <linux/mm.h>
#include <linux/mman.h>
#include <linux/export.h>
@@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm)
*/
int valid_phys_addr_range(phys_addr_t addr, size_t size)
{
- if (addr < PHYS_OFFSET)
- return 0;
- if (addr + size > __pa(high_memory - 1) + 1)
- return 0;
-
- return 1;
+ return memblock_is_map_memory(addr) &&
+ memblock_is_map_memory(addr + size - 1);
}
/*
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-12 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8676554.1IW2xieEGM@diego>
Hi Heiko,
On 11/04/17 21:52, Heiko St?bner wrote:
> Hi Guillaume,
>
> Am Dienstag, 11. April 2017, 18:40:37 CEST schrieb Guillaume Tucker:
>> On 03/04/17 09:12, Neil Armstrong wrote:
>>> On 04/02/2017 09:59 AM, Guillaume Tucker wrote:
>>>> +Optional:
>>>> +
>>>> +- clocks : Phandle to clock for the Mali Midgard device.
>>>> +- clock-names : Shall be "clk_mali".
>>>> +- mali-supply : Phandle to regulator for the Mali device. Refer to
>>>> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
>>>> +- operating-points : Refer to
>>>> Documentation/devicetree/bindings/power/opp.txt + for details.
>>>
>>> Please add :
>>> * Must be one of the following:
>>> "arm,mali-t820"
>>>
>>> * And, optionally, one of the vendor specific compatible:
>>> "amlogic,meson-gxm-mali"
>>>
>>> with my Ack for the amlogic platform.
>>
>> It seems to me that as long as the GPU architecture hasn't been
>> modified (I don't think I've ever encountered such a case) then
>> it has to be a standard ARM Mali type regardless of the SoC
>> vendor. So unless a Mali-T820 in the Amlogic S912 SoC is not the
>> same as a T820 in a different SoC, please forgive me but I don't
>> understand why a vendor compatible string is needed. My main
>> concern is that it's going to be very hard to keep that list
>> up-to-date with all existing Midgard SoC variants. If do we need
>> to add vendor compatible strings to correctly describe the
>> hardware then I'm happy to add the amlogic one in my patch v3; I
>> would just like to understand why that's necessary.
>
> SoC vendors in most cases hook ip blocks into their socs in different
> and often strange ways. After all it's not some discrete ic you solder
> onto a board, but instead a part of the soc itself.
Thanks for your explanation. I see, it's really about special
things that are not supported by the standard Midgard kernel
driver.
> So in most cases you will have some hooks outside the actual gpu iospace
> that can be used to tune different things about how the gpu interacts with
> the system. Which is probably also the reason the midgard kernel driver
> has this ugly "platform" subdirectory for compile-time platform selection.
I see the "platform" directory approach as an old and deprecated
way of supporting platforms, upstreaming the dt bindings goes in
the direction of using solely the device tree to describe the GPU
hardware (i.e. CONFIG_MALI_PLATFORM_DEVICETREE). If something
quirky is needed in the platform, it should be possible to
support it outside the GPU driver (platform devfreq etc...).
Back to the original intent of enabling distros to make Mali GPU
driver packages, when using the device tree you can have a single
kernel driver package for all Midgard platforms. When using the
third-party platform sources approach, you need to make an extra
package for each one of them.
So if there is value in supporting platforms that absolutely
require something special due to their hardware GPU integration,
then yes I see why vendor dt bindings might be useful. However
it seems to me that this should really be an exception and
avoided whenever possible.
> On my rk3288 for example we have [0] in the chromeos tree, that handles
> the oddities of the midgard on the rk3288 used in a lot of Chromebooks.
> There are soc-specific oddities of frequencies, frequency-scaling and
> whatnot. And there are also more gpu-specific setting in syscon areas
> of the soc (pmu and grf) that can also influence the gpus performance
> and might need tweaking at some point.
For the rk3288, this is purely a software implementation issue on
the chromeos-3.14 branch. With mainline kernel, you can use
devfreq and no platform files at all (that's how I tested these
dt bindings). So as far as I know, there's no need for a vendor
compatible string on rk3288.
> That doesn't even take into account that there may even be differences
> on how things are synthesized that we don't know about. See all the
> variants of the dw_hdmi ip block (imx, rockchip, meson [more?]) .
I'm not too familiar with that driver, just had a quick look and
it seems to be a different issue as there's a kernel config for
each platform to build separate driver modules. And it looks
like they are actually needed to cope with variants of the
hardware inside the display processor block, unlike with the Mali
GPU which in principle should always be the same. I've run this
Midgard driver without any platform files and using devfreq at
least on rk3288 Firefly, Exynos 5422 ODROID-XU3 and Juno and they
all have a vanilla Mali GPU hw block. It's just wired
differently in each SoC.
> So we really want to have the special compatibles in place, to be prepared
> for the future per-soc oddities that always appear :-) .
How about aiming for the ideal case where vendor-specific things
are not needed and add them if and when they really become
inevitable and worth the cost?
Thanks,
Guillaume
> [0] https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.14/drivers/gpu/arm/midgard/platform/rk/
^ permalink raw reply
* linux-next: manual merge of the mvebu tree with the arm-soc tree
From: Gregory CLEMENT @ 2017-04-12 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170412083404.76cda3b3@canb.auug.org.au>
Hi Olof and Arnd,
On mer., avril 12 2017, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the mvebu tree got a conflict in:
>
> arch/arm64/configs/defconfig
>
> between commit:
>
> 3c9d36192802 ("arm64: set CONFIG_MMC_BCM2835=y in defconfig")
>
> from the arm-soc tree and commit:
>
> 6ff829553345 ("arm64: configs: enable SDHCI driver for Xenon")
>
> from the mvebu tree.
How do you want to proceed with this conflict?
Do you want that I merged arm-soc/next/arm64 in my mvebu/defconfig64
branch before applying my patch ?
Or do you prefer that I continue to base my branch on v4.11-rc1 and then
you will take care of the conflict when pulling the branch?
Thanks,
Gregory
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> BTW, that arm-soc commit has no Signed-off-by from its committer :-(
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/configs/defconfig
> index ab4461b6b226,93b0aab959c0..000000000000
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@@ -402,7 -401,7 +402,8 @@@ CONFIG_MMC_DW_EXYNOS=
> CONFIG_MMC_DW_K3=y
> CONFIG_MMC_DW_ROCKCHIP=y
> CONFIG_MMC_SUNXI=y
> +CONFIG_MMC_BCM2835=y
> + CONFIG_MMC_SDHCI_XENON=y
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
> CONFIG_LEDS_GPIO=y
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge
From: Marc Zyngier @ 2017-04-12 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b59b81ea-bc1b-bff5-4a78-8a69538b0de3@free.fr>
On 11/04/17 18:52, Mason wrote:
> On 11/04/2017 18:43, Marc Zyngier wrote:
>
>> On 11/04/17 17:26, Mason wrote:
>>
>>> Is there a function to map virq to the hwirq in any domain?
>>
>> Be more precise. If you want the hwirq associated with the view of a
>> virq in a given domain, that's the hwirq field in the corresponding
>> irq_data structure. Or are you after something else?
>
> I registered an unmask method for my irq_chip.
> (IIUC, I'm supposed to unmask a specific MSI in this callback.)
>
> # cat /proc/interrupts
> CPU0 CPU1
> 30: 0 0 MSIfoo 0 Edge aerdrv
> 34: 0 0 MSIfoo 524288 Edge xhci_hcd
> 35: 0 0 MSIfoo 524289 Edge xhci_hcd
> 36: 0 0 MSIfoo 524290 Edge xhci_hcd
>
>
> void foo_unmask(struct irq_data *data)
> {
> int xx,yy;
> struct irq_domain *dom = data->domain;
> printk("%s: irq_data=%p irq=%u hwirq=%lu chip=%p dom=%p pdata=%p data=%p\n",
> __func__, data, data->irq, data->hwirq, data->chip, data->domain,
> data->parent_data, data->chip_data);
> printk("%s ops=%p data=%p parent=%p\n\n",
> dom->name, dom->ops, dom->host_data, dom->parent);
> printk("pcie=%p\n", dom->parent->host_data);
> //dump_stack();
> pci_msi_unmask_irq(data);
> struct tango_pcie *pcie = data->domain->parent->host_data;
> printk("\n%s: pcie=%p irq=%u hwirq=%lu\n\n",
> __func__, pcie, data->irq, data->hwirq);
> xx = irq_find_mapping(pcie->irq_domain, data->hwirq);
> yy = irq_find_mapping(pcie->msi_domain, data->hwirq);
Do you realize that hwirq is *per domain*, and only makes sense to *one*
irqchip? What you've written here doesn't make any sense.
> printk("xx=%d yy=%d\n", xx, yy);
> }
>
> so data->irq is the virq (30, 34, 35, 36)
> and data->hwirq is the domain hwirq (0, 524288, 524289, 524290)
>
> Is there a way to map hwirq 524288 to MSI 0, hwirq 524289 to MSI 1, etc?
Why would you need to do such a thing?
- In MSI domain: IRQ34 -> hwirq 524288
- In foo domain: IRQ34 -> hwirq [whatever your driver has allocated]
The data is already there, at your fingertips. Just deal with with your
"foo" irqchip.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2 03/11] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Lee Jones @ 2017-04-12 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170411180844.9176B125521@relay.mailchannels.net>
On Wed, 12 Apr 2017, Icenowy Zheng wrote:
>
> 2017?4?12? ??12:29? Lee Jones <lee.jones@linaro.org>???
> >
> > On Tue, 11 Apr 2017, Chen-Yu Tsai wrote:
> >
> > > Hi,
> > >
> > > On Tue, Apr 11, 2017 at 11:00 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> > > >
> > > >
> > > > On Tue, 11 Apr 2017, Lee Jones wrote:
> > > >
> > > >> On Sat, 08 Apr 2017, Icenowy Zheng wrote:
> > > >>
> > > >>> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> > > >>> bus.
> > > >>>
> > > >>> Add a compatible for it.
> > > >>>
> > > >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > >>> Acked-by: Chen-Yu Tsai <wens@csie.org>
> > > >>> ---
> > > >>> Changes in v2:
> > > >>> - Place AXP803 before AXP806/809.
> > > >>> - Added Chen-Yu's ACK.
> > > >>>
> > > >>>? Documentation/devicetree/bindings/mfd/axp20x.txt | 5 +++--
> > > >>>? 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >>
> > > >>
> > > >> For my own reference:
> > > >>? Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > >
> > > >
> > > > Excuse me... Who will apply this patch?
> >
> > Excuse you?? Are you trying to be polite, or rude?
> >
> > I'm guessing due to the lagging '...', that it's the latter?
>
> Oh sorry, I mean the former...
Okay, no problem then.
> > > > I think this patch should be applied by you as it's in bindings/mfd
> > > > directory, however, if I'm wrong, please point out ;-)
> > >
> > > We need the DT maintainers to ack it first. :)
> >
> > We don't really need the DT Maintainers to get involved here.
> >
> > What I do need is either clear direction as to how this
> > patch-set should be applied, or an indication of which patches are
> > dependant on others and which are orthogonal and can be applied
> > independently.
>
> This patch is independent, although the regulator binding patch
> depends on it.
>
> The real driver patches will need the binding patches to be merged
> first.
Right, so Acking and not applying wasn't such a strange practice
after all then. =;-)
> And the dt patches depend on also the binding patches.
The issue I have now is; because your email client replies as a new
mail i.e. non-threaded, now I have no reference to the patch-set.
Since time is a valuable resource, I will not be dredging though my
inbox looking for all your replies.
Please fix your client before replying to another mail.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Lee Jones @ 2017-04-12 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170411211936.GT2078@mai>
On Tue, 11 Apr 2017, Daniel Lezcano wrote:
> On Tue, Apr 11, 2017 at 03:06:13PM +0100, Lee Jones wrote:
> > On Sat, 08 Apr 2017, Daniel Lezcano wrote:
> >
> > > The hi655x multi function device is a PMIC providing regulators.
> > >
> > > The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement
> > > this clock in order to add it in the hi655x MFD and allow proper wireless
> > > initialization.
> > >
> > > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > > ---
> > >
> > > Changelog:
> > >
> > > V2:
> > > - Added COMPILE_TEST option, compiled on x86
> > > - Removed useless parenthesis
> > > - Used of_clk_hw_simple_get() instead of deref dance
> > > - Do bailout if the clock-names is not specified
> > > - Rollback on error
> > > - Folded mfd line change and binding
> >
> > Why did you do that?
>
> I thought as the V1 had comments you would have waited for the V2 and as it was
> trivial enough, it could be folded and picked up via the clk tree via with your
> acked-by.
It's *always* a good idea to keep patches subsystem orthogonal if
at all possible.
> I realize it was not a good idea.
>
> Do you want to drop it from your tree or shall I resubmit a V3 without the mfd
> change?
The latter please.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 01/20] net: stmmac: export stmmac_set_mac_addr/stmmac_get_mac_addr
From: Corentin Labbe @ 2017-04-12 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9514c077-1738-ea49-ca18-fbc46bac6144@st.com>
On Mon, Apr 03, 2017 at 02:39:03PM +0200, Giuseppe CAVALLARO wrote:
> Hello Alex
>
> do you can check if this has to be done for ST platforms?
> I do not remember that it was necessary when build as module so
> I cannot expect this should be only for dwmac-sun8i.
>
> Regards
> peppe
>
dwmac-sun8i is simply the first "user" of stmmac_[sg]et_mac_addr outside of stmmac-objs
Regards
^ permalink raw reply
* [PATCH v5 3/3] DT nodes for Broadcom Northstar2 USB DRD Phy
From: Raviteja Garimella @ 2017-04-12 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491981125-6859-1-git-send-email-raviteja.garimella@broadcom.com>
This patch adds device tree nodes for USB Dual Role Device Phy for
Broadcom's Northstar2 SoC.
Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index bcb03fc..c71f330 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -436,6 +436,20 @@
};
};
+ usbdrd_phy: phy at 66000960 {
+ #phy-cells = <0>;
+ compatible = "brcm,ns2-drd-phy";
+ reg = <0x66000960 0x24>,
+ <0x67012800 0x4>,
+ <0x6501d148 0x4>,
+ <0x664d0700 0x4>;
+ reg-names = "icfg", "rst-ctrl",
+ "crmu-ctrl", "usb2-strap";
+ id-gpios = <&gpio_g 30 0>;
+ vbus-gpios = <&gpio_g 31 0>;
+ status = "disabled";
+ };
+
pwm: pwm at 66010000 {
compatible = "brcm,iproc-pwm";
reg = <0x66010000 0x28>;
--
2.1.0
^ permalink raw reply related
* [PATCH v5 2/3] phy:phy-bcm-ns2-usbdrd:Broadcom USB DRD Phy driver for Northstar2
From: Raviteja Garimella @ 2017-04-12 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491981125-6859-1-git-send-email-raviteja.garimella@broadcom.com>
This is driver for USB DRD Phy used in Broadcom's Northstar2
SoC. The phy can be configured to be in Device mode or Host
mode based on the type of cable connected to the port. The
driver registers to extcon framework to get appropriate
connect events for Host/Device cables connect/disconnect
states based on VBUS and ID interrupts.
Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
---
drivers/phy/Kconfig | 13 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-bcm-ns2-usbdrd.c | 595 +++++++++++++++++++++++++++++++++++++++
3 files changed, 609 insertions(+)
create mode 100644 drivers/phy/phy-bcm-ns2-usbdrd.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 005cadb..c9de9a9 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -488,6 +488,19 @@ config PHY_CYGNUS_PCIE
Enable this to support the Broadcom Cygnus PCIe PHY.
If unsure, say N.
+config PHY_NS2_USB_DRD
+ tristate "Broadcom Northstar2 USB DRD PHY support"
+ depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GENERIC_PHY
+ select EXTCON
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Northstar2 USB DRD PHY.
+ This driver initializes the PHY in either HOST or DEVICE mode.
+ The host or device configuration is read from device tree.
+
+ If unsure, say N.
+
source "drivers/phy/tegra/Kconfig"
config PHY_NS2_PCIE
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index dd8f3b5..9285f88 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
obj-$(CONFIG_PHY_BRCM_SATA) += phy-brcm-sata.o
obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
+obj-$(CONFIG_PHY_NS2_USB_DRD) += phy-bcm-ns2-usbdrd.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
obj-$(CONFIG_PHY_MESON8B_USB2) += phy-meson8b-usb2.o
diff --git a/drivers/phy/phy-bcm-ns2-usbdrd.c b/drivers/phy/phy-bcm-ns2-usbdrd.c
new file mode 100644
index 0000000..92b68b1
--- /dev/null
+++ b/drivers/phy/phy-bcm-ns2-usbdrd.c
@@ -0,0 +1,595 @@
+/*
+ * Copyright (C) 2016 Broadcom
+ *
+ * This program 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/extcon.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+
+#define ICFG_DRD_AFE 0x0
+#define ICFG_MISC_STAT 0x18
+#define ICFG_DRD_P0CTL 0x1C
+#define ICFG_STRAP_CTRL 0x20
+#define ICFG_FSM_CTRL 0x24
+
+#define ICFG_DEV_BIT BIT(2)
+#define IDM_RST_BIT BIT(0)
+#define AFE_CORERDY_VDDC BIT(18)
+#define PHY_PLL_RESETB BIT(15)
+#define PHY_RESETB BIT(14)
+#define PHY_PLL_LOCK BIT(0)
+
+#define DRD_DEV_MODE BIT(20)
+#define OHCI_OVRCUR_POL BIT(11)
+#define ICFG_OFF_MODE BIT(6)
+#define PLL_LOCK_RETRY 1000
+
+#define EVT_DEVICE 0
+#define EVT_HOST 1
+#define EVT_IDLE 2
+
+#define DRD_HOST_MODE (BIT(2) | BIT(3))
+#define DRD_DEVICE_MODE (BIT(4) | BIT(5))
+#define DRD_HOST_VAL 0x803
+#define DRD_DEV_VAL 0x807
+#define GPIO_DELAY 20
+#define PHY_WQ_DELAY msecs_to_jiffies(600)
+
+struct ns2_phy_data;
+struct ns2_phy_driver {
+ void __iomem *icfgdrd_regs;
+ void __iomem *idmdrd_rst_ctrl;
+ void __iomem *crmu_usb2_ctrl;
+ void __iomem *usb2h_strap_reg;
+ spinlock_t lock; /* spin lock for phy driver */
+ struct ns2_phy_data *data;
+ struct extcon_specific_cable_nb extcon_dev;
+ struct extcon_specific_cable_nb extcon_host;
+ struct notifier_block host_nb;
+ struct notifier_block dev_nb;
+ struct delayed_work conn_work;
+ struct extcon_dev *edev;
+ struct gpio_desc *vbus_gpiod;
+ struct gpio_desc *id_gpiod;
+ int id_irq;
+ int vbus_irq;
+ unsigned long debounce_jiffies;
+ struct delayed_work wq_extcon;
+};
+
+struct ns2_phy_data {
+ struct ns2_phy_driver *driver;
+ struct phy *phy;
+ int new_state;
+};
+
+static const unsigned int usb_extcon_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
+ EXTCON_NONE,
+};
+
+static inline int pll_lock_stat(u32 usb_reg, int reg_mask,
+ struct ns2_phy_driver *driver)
+{
+ int retry = PLL_LOCK_RETRY;
+ u32 val;
+
+ do {
+ udelay(1);
+ val = readl(driver->icfgdrd_regs + usb_reg);
+ if (val & reg_mask)
+ return 0;
+ } while (--retry > 0);
+
+ return -EBUSY;
+}
+
+static int ns2_drd_phy_init(struct phy *phy)
+{
+ struct ns2_phy_data *data = phy_get_drvdata(phy);
+ struct ns2_phy_driver *driver = data->driver;
+ unsigned long flags;
+ u32 val;
+
+ spin_lock_irqsave(&driver->lock, flags);
+
+ val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+ if (data->new_state == EVT_HOST) {
+ val &= ~DRD_DEVICE_MODE;
+ val |= DRD_HOST_MODE;
+ } else {
+ val &= ~DRD_HOST_MODE;
+ val |= DRD_DEVICE_MODE;
+ }
+ writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+ spin_unlock_irqrestore(&driver->lock, flags);
+ return 0;
+}
+
+static int ns2_drd_phy_shutdown(struct phy *phy)
+{
+ struct ns2_phy_data *data = phy_get_drvdata(phy);
+ struct ns2_phy_driver *driver = data->driver;
+ unsigned long flags;
+ u32 val;
+
+ spin_lock_irqsave(&driver->lock, flags);
+
+ val = readl(driver->crmu_usb2_ctrl);
+ val &= ~AFE_CORERDY_VDDC;
+ writel(val, driver->crmu_usb2_ctrl);
+
+ val = readl(driver->crmu_usb2_ctrl);
+ val &= ~DRD_DEV_MODE;
+ writel(val, driver->crmu_usb2_ctrl);
+
+ /* Disable Host and Device Mode */
+ val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
+ val &= ~(DRD_HOST_MODE | DRD_DEVICE_MODE | ICFG_OFF_MODE);
+ writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+ spin_unlock_irqrestore(&driver->lock, flags);
+ return 0;
+}
+
+static int ns2_drd_phy_poweron(struct phy *phy)
+{
+ struct ns2_phy_data *data = phy_get_drvdata(phy);
+ struct ns2_phy_driver *driver = data->driver;
+ u32 extcon_event = data->new_state;
+ unsigned long flags;
+ int ret;
+ u32 val;
+
+ spin_lock_irqsave(&driver->lock, flags);
+ if (extcon_event == EVT_DEVICE) {
+ writel(DRD_DEV_VAL, driver->icfgdrd_regs + ICFG_DRD_P0CTL);
+
+ val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
+ val &= ~(DRD_HOST_MODE | ICFG_OFF_MODE);
+ val |= DRD_DEVICE_MODE;
+ writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+ val = readl(driver->idmdrd_rst_ctrl);
+ val &= ~IDM_RST_BIT;
+ writel(val, driver->idmdrd_rst_ctrl);
+
+ val = readl(driver->crmu_usb2_ctrl);
+ val |= (AFE_CORERDY_VDDC | DRD_DEV_MODE);
+ writel(val, driver->crmu_usb2_ctrl);
+
+ /* Bring PHY and PHY_PLL out of Reset */
+ val = readl(driver->crmu_usb2_ctrl);
+ val |= (PHY_PLL_RESETB | PHY_RESETB);
+ writel(val, driver->crmu_usb2_ctrl);
+
+ ret = pll_lock_stat(ICFG_MISC_STAT, PHY_PLL_LOCK, driver);
+ if (ret < 0) {
+ dev_err(&phy->dev, "Phy PLL lock failed\n");
+ goto err_shutdown;
+ }
+ } else {
+ writel(DRD_HOST_VAL, driver->icfgdrd_regs + ICFG_DRD_P0CTL);
+
+ val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
+ val &= ~(DRD_DEVICE_MODE | ICFG_OFF_MODE);
+ val |= DRD_HOST_MODE;
+ writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+ val = readl(driver->crmu_usb2_ctrl);
+ val |= AFE_CORERDY_VDDC;
+ writel(val, driver->crmu_usb2_ctrl);
+
+ ret = pll_lock_stat(ICFG_MISC_STAT, PHY_PLL_LOCK, driver);
+ if (ret < 0) {
+ dev_err(&phy->dev, "Phy PLL lock failed\n");
+ goto err_shutdown;
+ }
+
+ val = readl(driver->idmdrd_rst_ctrl);
+ val &= ~IDM_RST_BIT;
+ writel(val, driver->idmdrd_rst_ctrl);
+
+ /* port over current Polarity */
+ val = readl(driver->usb2h_strap_reg);
+ val |= OHCI_OVRCUR_POL;
+ writel(val, driver->usb2h_strap_reg);
+ }
+ spin_unlock_irqrestore(&driver->lock, flags);
+ return 0;
+
+err_shutdown:
+ spin_unlock_irqrestore(&driver->lock, flags);
+ ns2_drd_phy_shutdown(phy);
+ return ret;
+}
+
+static void connect_work(struct work_struct *work)
+{
+ struct ns2_phy_driver *driver;
+ u32 extcon_event;
+ u32 val;
+
+ driver = container_of(to_delayed_work(work),
+ struct ns2_phy_driver, conn_work);
+ extcon_event = driver->data->new_state;
+
+ val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+ switch (extcon_event) {
+ case EVT_DEVICE:
+ val = (val & ~DRD_HOST_MODE) | DRD_DEVICE_MODE;
+ writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+ val = readl(driver->icfgdrd_regs + ICFG_DRD_P0CTL);
+ val |= ICFG_DEV_BIT;
+ writel(val, driver->icfgdrd_regs + ICFG_DRD_P0CTL);
+ break;
+
+ case EVT_HOST:
+ val = (val & ~DRD_DEVICE_MODE) | DRD_HOST_MODE;
+ writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+
+ val = readl(driver->usb2h_strap_reg);
+ val |= OHCI_OVRCUR_POL;
+ writel(val, driver->usb2h_strap_reg);
+
+ val = readl(driver->icfgdrd_regs + ICFG_DRD_P0CTL);
+ val &= ~ICFG_DEV_BIT;
+ writel(val, driver->icfgdrd_regs + ICFG_DRD_P0CTL);
+ break;
+
+ case EVT_IDLE:
+ val &= ~(DRD_HOST_MODE | DRD_DEVICE_MODE);
+ writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
+ break;
+
+ default:
+ pr_err("Invalid extcon event\n");
+ break;
+ }
+}
+
+static int drd_device_notify(struct notifier_block *self,
+ unsigned long event, void *ptr)
+{
+ struct ns2_phy_driver *driver = container_of(self,
+ struct ns2_phy_driver, dev_nb);
+
+ if (event) {
+ pr_debug("Device connected\n");
+ driver->data->new_state = EVT_DEVICE;
+ schedule_delayed_work(&driver->conn_work, 0);
+ } else {
+ pr_debug("Device disconnected\n");
+ driver->data->new_state = EVT_IDLE;
+ schedule_delayed_work(&driver->conn_work, PHY_WQ_DELAY);
+ }
+
+ return NOTIFY_DONE;
+}
+
+static int drd_host_notify(struct notifier_block *self,
+ unsigned long event, void *ptr)
+{
+ struct ns2_phy_driver *driver = container_of(self,
+ struct ns2_phy_driver, host_nb);
+
+ if (event) {
+ pr_debug("Host connected\n");
+ driver->data->new_state = EVT_HOST;
+ schedule_delayed_work(&driver->conn_work, 0);
+ } else {
+ pr_debug("Host disconnected\n");
+ driver->data->new_state = EVT_IDLE;
+ schedule_delayed_work(&driver->conn_work, PHY_WQ_DELAY);
+ }
+
+ return NOTIFY_DONE;
+}
+
+static void extcon_work(struct work_struct *work)
+{
+ struct ns2_phy_driver *driver;
+ int vbus;
+ int id;
+
+ driver = container_of(to_delayed_work(work),
+ struct ns2_phy_driver, wq_extcon);
+
+ id = gpiod_get_value_cansleep(driver->id_gpiod);
+ vbus = gpiod_get_value_cansleep(driver->vbus_gpiod);
+
+ if (!id && vbus) {
+ extcon_set_cable_state_(driver->edev, EXTCON_USB_HOST, true);
+ } else if (id && !vbus) {
+ extcon_set_cable_state_(driver->edev, EXTCON_USB_HOST, false);
+ extcon_set_cable_state_(driver->edev, EXTCON_USB, false);
+ } else if (id && vbus) {
+ extcon_set_cable_state_(driver->edev, EXTCON_USB, true);
+ }
+}
+
+static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
+{
+ struct ns2_phy_driver *driver = dev_id;
+
+ queue_delayed_work(system_power_efficient_wq, &driver->wq_extcon,
+ driver->debounce_jiffies);
+
+ return IRQ_HANDLED;
+}
+
+static int register_extcon_notifier(struct ns2_phy_driver *phy_driver,
+ struct device *dev)
+{
+ struct extcon_dev *edev;
+ int ret;
+
+ phy_driver->host_nb.notifier_call = drd_host_notify;
+ phy_driver->dev_nb.notifier_call = drd_device_notify;
+
+ edev = phy_driver->edev;
+
+ /* Register for device change notification */
+ ret = extcon_register_notifier(edev, EXTCON_USB,
+ &phy_driver->dev_nb);
+ if (ret < 0) {
+ dev_err(dev, "can't register extcon_dev\n");
+ return ret;
+ }
+
+ /* Register for host change notification */
+ ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
+ &phy_driver->host_nb);
+ if (ret < 0) {
+ dev_err(dev, "can't register extcon_dev\n");
+ goto err_dev;
+ }
+
+ /* Check the device cable connect state */
+ ret = extcon_get_cable_state_(edev, EXTCON_USB);
+ if (ret < 0) {
+ dev_err(dev, "can't get extcon_dev state\n");
+ goto err_host;
+ } else if (ret) {
+ phy_driver->data->new_state = EVT_DEVICE;
+ }
+
+ /* Check the host cable connect state */
+ ret = extcon_get_cable_state_(edev, EXTCON_USB_HOST);
+ if (ret < 0) {
+ dev_err(dev, "can't get extcon_dev state\n");
+ goto err_host;
+ } else if (ret) {
+ phy_driver->data->new_state = EVT_HOST;
+ }
+
+ return 0;
+
+err_host:
+ ret = extcon_unregister_notifier(edev, EXTCON_USB_HOST,
+ &phy_driver->host_nb);
+err_dev:
+ ret = extcon_unregister_notifier(edev, EXTCON_USB,
+ &phy_driver->dev_nb);
+ return ret;
+}
+
+static struct phy_ops ops = {
+ .init = ns2_drd_phy_init,
+ .power_on = ns2_drd_phy_poweron,
+ .power_off = ns2_drd_phy_shutdown,
+ .owner = THIS_MODULE,
+};
+
+static const struct of_device_id ns2_drd_phy_dt_ids[] = {
+ { .compatible = "brcm,ns2-drd-phy", },
+ { }
+};
+
+static int ns2_drd_phy_remove(struct platform_device *pdev)
+{
+ struct ns2_phy_driver *driver = dev_get_drvdata(&pdev->dev);
+
+ if (driver->edev) {
+ extcon_unregister_notifier(driver->edev, EXTCON_USB_HOST,
+ &driver->host_nb);
+ extcon_unregister_notifier(driver->edev, EXTCON_USB,
+ &driver->dev_nb);
+ }
+
+ return 0;
+}
+static int ns2_drd_phy_probe(struct platform_device *pdev)
+{
+ struct phy_provider *phy_provider;
+ struct device *dev = &pdev->dev;
+ struct ns2_phy_driver *driver;
+ struct ns2_phy_data *data;
+ struct resource *res;
+ int ret;
+ u32 val;
+
+ driver = devm_kzalloc(dev, sizeof(struct ns2_phy_driver),
+ GFP_KERNEL);
+ if (!driver)
+ return -ENOMEM;
+
+ driver->data = devm_kzalloc(dev, sizeof(struct ns2_phy_data),
+ GFP_KERNEL);
+ if (!driver->data)
+ return -ENOMEM;
+
+ spin_lock_init(&driver->lock);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "icfg");
+ driver->icfgdrd_regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(driver->icfgdrd_regs))
+ return PTR_ERR(driver->icfgdrd_regs);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "rst-ctrl");
+ driver->idmdrd_rst_ctrl = devm_ioremap_resource(dev, res);
+ if (IS_ERR(driver->idmdrd_rst_ctrl))
+ return PTR_ERR(driver->idmdrd_rst_ctrl);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "crmu-ctrl");
+ driver->crmu_usb2_ctrl = devm_ioremap_resource(dev, res);
+ if (IS_ERR(driver->crmu_usb2_ctrl))
+ return PTR_ERR(driver->crmu_usb2_ctrl);
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "usb2-strap");
+ driver->usb2h_strap_reg = devm_ioremap_resource(dev, res);
+ if (IS_ERR(driver->usb2h_strap_reg))
+ return PTR_ERR(driver->usb2h_strap_reg);
+
+ /* create extcon */
+ driver->id_gpiod = devm_gpiod_get(&pdev->dev, "id", GPIOD_IN);
+ if (IS_ERR(driver->id_gpiod)) {
+ dev_err(dev, "failed to get ID GPIO\n");
+ return PTR_ERR(driver->id_gpiod);
+ }
+ driver->vbus_gpiod = devm_gpiod_get(&pdev->dev, "vbus", GPIOD_IN);
+ if (IS_ERR(driver->vbus_gpiod)) {
+ dev_err(dev, "failed to get VBUS GPIO\n");
+ return PTR_ERR(driver->vbus_gpiod);
+ }
+
+ driver->edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
+ if (IS_ERR(driver->edev)) {
+ dev_err(dev, "failed to allocate extcon device\n");
+ return -ENOMEM;
+ }
+
+ ret = devm_extcon_dev_register(dev, driver->edev);
+ if (ret < 0) {
+ dev_err(dev, "failed to register extcon device\n");
+ goto extcon_free;
+ }
+
+ ret = gpiod_set_debounce(driver->id_gpiod, GPIO_DELAY * 1000);
+ if (ret < 0)
+ driver->debounce_jiffies = msecs_to_jiffies(GPIO_DELAY);
+
+ INIT_DELAYED_WORK(&driver->wq_extcon, extcon_work);
+
+ driver->id_irq = gpiod_to_irq(driver->id_gpiod);
+ if (driver->id_irq < 0) {
+ dev_err(dev, "failed to get ID IRQ\n");
+ ret = driver->id_irq;
+ goto extcon_unregister;
+ }
+ driver->vbus_irq = gpiod_to_irq(driver->vbus_gpiod);
+ if (driver->vbus_irq < 0) {
+ dev_err(dev, "failed to get ID IRQ\n");
+ ret = driver->vbus_irq;
+ goto extcon_unregister;
+ }
+
+ ret = devm_request_threaded_irq(dev, driver->id_irq, NULL,
+ gpio_irq_handler,
+ IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ "usb_id", driver);
+ if (ret < 0) {
+ dev_err(dev, "failed to request handler for ID IRQ\n");
+ goto extcon_unregister;
+ }
+ ret = devm_request_threaded_irq(dev, driver->vbus_irq, NULL,
+ gpio_irq_handler,
+ IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ "usb_vbus", driver);
+ if (ret < 0) {
+ dev_err(dev, "failed to request handler for VBUS IRQ\n");
+ goto extcon_unregister;
+ }
+
+ dev_set_drvdata(dev, driver);
+
+ /* Shutdown all ports. They can be powered up as required */
+ val = readl(driver->crmu_usb2_ctrl);
+ val &= ~(AFE_CORERDY_VDDC | PHY_RESETB);
+ writel(val, driver->crmu_usb2_ctrl);
+
+ data = driver->data;
+ data->phy = devm_phy_create(dev, dev->of_node, &ops);
+ if (IS_ERR(data->phy)) {
+ dev_err(dev, "Failed to create usb drd phy\n");
+ ret = PTR_ERR(data->phy);
+ goto extcon_unregister;
+ }
+
+ data->driver = driver;
+ phy_set_drvdata(data->phy, data);
+
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ if (IS_ERR(phy_provider)) {
+ dev_err(dev, "Failed to register as phy provider\n");
+ ret = PTR_ERR(phy_provider);
+ goto extcon_unregister;
+ }
+
+ INIT_DELAYED_WORK(&driver->conn_work, connect_work);
+ platform_set_drvdata(pdev, driver);
+
+ ret = register_extcon_notifier(driver, dev);
+ if (ret < 0) {
+ dev_err(dev, "register extcon notifier failed (%d)\n", ret);
+ goto extcon_unregister;
+ }
+ dev_info(dev, "Registered extcon device\n");
+ queue_delayed_work(system_power_efficient_wq, &driver->wq_extcon,
+ driver->debounce_jiffies);
+
+ return 0;
+
+extcon_unregister:
+ devm_extcon_dev_unregister(dev, driver->edev);
+extcon_free:
+ devm_extcon_dev_free(dev, driver->edev);
+ return ret;
+}
+
+MODULE_DEVICE_TABLE(of, ns2_drd_phy_dt_ids);
+
+static struct platform_driver ns2_drd_phy_driver = {
+ .probe = ns2_drd_phy_probe,
+ .remove = ns2_drd_phy_remove,
+ .driver = {
+ .name = "bcm-ns2-usbphy",
+ .of_match_table = of_match_ptr(ns2_drd_phy_dt_ids),
+ },
+};
+module_platform_driver(ns2_drd_phy_driver);
+
+MODULE_ALIAS("platform:bcm-ns2-drd-phy");
+MODULE_AUTHOR("Broadcom");
+MODULE_DESCRIPTION("Broadcom NS2 USB2 PHY driver");
+MODULE_LICENSE("GPL v2");
--
2.1.0
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings:phy:Add DT bindings documentation for NS2 USB DRD phy
From: Raviteja Garimella @ 2017-04-12 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491981125-6859-1-git-send-email-raviteja.garimella@broadcom.com>
This patch adds documentation for NS2 DRD Phy driver DT bindings
Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/phy/brcm,ns2-drd-phy.txt | 30 ++++++++++++++++++++++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
new file mode 100644
index 0000000..04f063a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
@@ -0,0 +1,30 @@
+BROADCOM NORTHSTAR2 USB2 (DUAL ROLE DEVICE) PHY
+
+Required properties:
+ - compatible: brcm,ns2-drd-phy
+ - reg: offset and length of the NS2 PHY related registers.
+ - reg-names
+ The below registers must be provided.
+ icfg - for DRD ICFG configurations
+ rst-ctrl - for DRD IDM reset
+ crmu-ctrl - for CRMU core vdd, PHY and PHY PLL reset
+ usb2-strap - for port over current polarity reversal
+ - #phy-cells: Must be 0. No args required.
+ - vbus-gpios: vbus gpio binding
+ - id-gpios: id gpio binding
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+ usbdrd_phy: phy at 66000960 {
+ #phy-cells = <0>;
+ compatible = "brcm,ns2-drd-phy";
+ reg = <0x66000960 0x24>,
+ <0x67012800 0x4>,
+ <0x6501d148 0x4>,
+ <0x664d0700 0x4>;
+ reg-names = "icfg", "rst-ctrl",
+ "crmu-ctrl", "usb2-strap";
+ id-gpios = <&gpio_g 30 0>;
+ vbus-gpios = <&gpio_g 31 0>;
+ };
--
2.1.0
^ permalink raw reply related
* [PATCH v5 0/3] Support for USB DRD Phy driver for NS2
From: Raviteja Garimella @ 2017-04-12 7:12 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v5:
=============
Removed references to phy_ops in the same driver by connect_work
event handler to change the phy modes.
To support dynamically changing the mode of the phy, it does
not require doing a phy reset/programming of PHY PLL. Changes
are made to the connect_work routine to just program the required
register bits to achieve this purpose.
<clip: as before>
Changes in v4:
=============
Remove references to edev->name in debug prints.
Changes in v3:
=============
Remove unnecessary checks for poweron as suggested in review.
Changes in v2:
=============
1. Initialize file operations .owner field with THIS_MODULE.
2. Remove unnecessary gpio example in DT bindings documentation.
This is previously acked by Rob Herring <robh@kernel.org>
Introduction for PATCH v1:
This patch adds support for USB Dual Role Device Phy for Broadcom
Northstar2 SoC. Apart from the new phy driver, this patchset contains
changes to Kconfig, Makefile, and Device tree files.
This patchset is tested on Broadcom NS2 BCM958712K reference board.
Repo: https://github.com/Broadcom/arm64-linux.git
Branch: ns2_drdphy_v5
Raviteja Garimella (3):
dt-bindings:phy:Add DT bindings documentation for NS2 USB DRD phy
phy:phy-bcm-ns2-usbdrd:Broadcom USB DRD Phy driver for Northstar2
DT nodes for Broadcom Northstar2 USB DRD Phy
.../devicetree/bindings/phy/brcm,ns2-drd-phy.txt | 30 ++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 14 +
drivers/phy/Kconfig | 13 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-bcm-ns2-usbdrd.c | 595 +++++++++++++++++++++
5 files changed, 653 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
create mode 100644 drivers/phy/phy-bcm-ns2-usbdrd.c
--
2.1.0
^ permalink raw reply
* [PATCH 4/4] arm64: dts: rk3399: add pinctrl for some peripheral
From: Kever Yang @ 2017-04-12 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491981044-24635-1-git-send-email-kever.yang@rock-chips.com>
Add pinctrl for sdio, sdmmc, pcie, spdif, hdmi.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 113 +++++++++++++++++++++++++++++++
1 file changed, 113 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 54a5340..0096c70 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1737,6 +1737,91 @@
};
};
+ sdio0 {
+ sdio0_bus1: sdio0-bus1 {
+ rockchip,pins =
+ <2 RK_PC4 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdio0_bus4: sdio0-bus4 {
+ rockchip,pins =
+ <2 RK_PC4 RK_FUNC_1 &pcfg_pull_up>,
+ <2 RK_PC5 RK_FUNC_1 &pcfg_pull_up>,
+ <2 RK_PC6 RK_FUNC_1 &pcfg_pull_up>,
+ <2 RK_PC7 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdio0_cmd: sdio0-cmd {
+ rockchip,pins =
+ <2 RK_PD0 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdio0_clk: sdio0-clk {
+ rockchip,pins =
+ <2 RK_PD1 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ sdio0_cd: sdio0-cd {
+ rockchip,pins =
+ <2 RK_PD2 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdio0_pwr: sdio0-pwr {
+ rockchip,pins =
+ <2 RK_PD3 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdio0_bkpwr: sdio0-bkpwr {
+ rockchip,pins =
+ <2 RK_PD4 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdio0_wp: sdio0-wp {
+ rockchip,pins =
+ <0 RK_PA3 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdio0_int: sdio0-int {
+ rockchip,pins =
+ <0 RK_PA4 RK_FUNC_1 &pcfg_pull_up>;
+ };
+ };
+
+ sdmmc {
+ sdmmc_bus1: sdmmc-bus1 {
+ rockchip,pins =
+ <4 RK_PB0 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdmmc_bus4: sdmmc-bus4 {
+ rockchip,pins =
+ <4 RK_PB0 RK_FUNC_1 &pcfg_pull_up>,
+ <4 RK_PB1 RK_FUNC_1 &pcfg_pull_up>,
+ <4 RK_PB2 RK_FUNC_1 &pcfg_pull_up>,
+ <4 RK_PB3 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdmmc_clk: sdmmc-clk {
+ rockchip,pins =
+ <4 RK_PB4 RK_FUNC_1 &pcfg_pull_none>;
+ };
+
+ sdmmc_cmd: sdmmc-cmd {
+ rockchip,pins =
+ <4 RK_PB5 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdmmc_cd: sdmcc-cd {
+ rockchip,pins =
+ <0 RK_PA7 RK_FUNC_1 &pcfg_pull_up>;
+ };
+
+ sdmmc_wp: sdmmc-wp {
+ rockchip,pins =
+ <0 RK_PB0 RK_FUNC_1 &pcfg_pull_up>;
+ };
+ };
+
sleep {
ap_pwroff: ap-pwroff {
rockchip,pins = <1 RK_PA5 RK_FUNC_1 &pcfg_pull_none>;
@@ -1752,6 +1837,11 @@
rockchip,pins =
<4 RK_PC5 RK_FUNC_1 &pcfg_pull_none>;
};
+
+ spdif_bus_1: spdif-bus-1 {
+ rockchip,pins =
+ <3 RK_PC0 RK_FUNC_3 &pcfg_pull_none>;
+ };
};
spi0 {
@@ -2011,6 +2101,19 @@
};
};
+ hdmi {
+ hdmi_i2c_xfer: hdmi-i2c-xfer {
+ rockchip,pins =
+ <4 RK_PC1 RK_FUNC_3 &pcfg_pull_none>,
+ <4 RK_PC0 RK_FUNC_3 &pcfg_pull_none>;
+ };
+
+ hdmi_cec: hdmi-cec {
+ rockchip,pins =
+ <4 RK_PC7 RK_FUNC_1 &pcfg_pull_none>;
+ };
+ };
+
pcie {
pcie_clkreqn: pci-clkreqn {
rockchip,pins =
@@ -2021,6 +2124,16 @@
rockchip,pins =
<4 RK_PD0 RK_FUNC_1 &pcfg_pull_none>;
};
+
+ pcie_clkreqn_cpm: pci-clkreqn-cpm {
+ rockchip,pins =
+ <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ pcie_clkreqnb_cpm: pci-clkreqnb-cpm {
+ rockchip,pins =
+ <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] arm64: dts: rk3399: add power domain for some peripheral
From: Kever Yang @ 2017-04-12 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491981044-24635-1-git-send-email-kever.yang@rock-chips.com>
Add power domain for sd, usb, edp.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 36 +++++++++++++++++++++++++++-----
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 387ae34..9d44c19 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -947,6 +947,10 @@
};
/* These power domains are grouped by VD_LOGIC */
+ pd_edp at RK3399_PD_EDP {
+ reg = <RK3399_PD_EDP>;
+ clocks = <&cru PCLK_EDP_CTRL>;
+ };
pd_emmc at RK3399_PD_EMMC {
reg = <RK3399_PD_EMMC>;
clocks = <&cru ACLK_EMMC>;
@@ -958,11 +962,33 @@
<&cru PCLK_GMAC>;
pm_qos = <&qos_gmac>;
};
- pd_sd at RK3399_PD_SD {
- reg = <RK3399_PD_SD>;
- clocks = <&cru HCLK_SDMMC>,
- <&cru SCLK_SDMMC>;
- pm_qos = <&qos_sd>;
+ pd_perihp at RK3399_PD_PERIHP {
+ reg = <RK3399_PD_PERIHP>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cru ACLK_PERIHP>;
+ pm_qos = <&qos_perihp>,
+ <&qos_pcie>,
+ <&qos_usb_host0>,
+ <&qos_usb_host1>;
+
+ pd_sd at RK3399_PD_SD {
+ reg = <RK3399_PD_SD>;
+ clocks = <&cru HCLK_SDMMC>,
+ <&cru SCLK_SDMMC>;
+ pm_qos = <&qos_sd>;
+ };
+ };
+ pd_sdioaudio at RK3399_PD_SDIOAUDIO {
+ reg = <RK3399_PD_SDIOAUDIO>;
+ clocks = <&cru HCLK_SDIO>;
+ pm_qos = <&qos_sdioaudio>;
+ };
+ pd_usb3 at RK3399_PD_USB3 {
+ reg = <RK3399_PD_USB3>;
+ clocks = <&cru ACLK_USB3>;
+ pm_qos = <&qos_usb_otg0>,
+ <&qos_usb_otg1>;
};
pd_vio at RK3399_PD_VIO {
reg = <RK3399_PD_VIO>;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] arm64: dts: rk3399: add missing qos node
From: Kever Yang @ 2017-04-12 7:10 UTC (permalink / raw)
To: linux-arm-kernel
Add qos setting reg for some peripheral like sd, usb, pcie.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 45 ++++++++++++++++++++++++++++----
1 file changed, 40 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index f4f3c96..387ae34 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -769,11 +769,6 @@
status = "disabled";
};
- qos_sd: qos at ffa74000 {
- compatible = "syscon";
- reg = <0x0 0xffa74000 0x0 0x20>;
- };
-
qos_emmc: qos at ffa58000 {
compatible = "syscon";
reg = <0x0 0xffa58000 0x0 0x20>;
@@ -784,6 +779,41 @@
reg = <0x0 0xffa5c000 0x0 0x20>;
};
+ qos_pcie: qos at ffa60080 {
+ compatible = "syscon";
+ reg = <0x0 0xffa60080 0x0 0x20>;
+ };
+
+ qos_usb_host0: qos at ffa60100 {
+ compatible = "syscon";
+ reg = <0x0 0xffa60100 0x0 0x20>;
+ };
+
+ qos_usb_host1: qos at ffa60180 {
+ compatible = "syscon";
+ reg = <0x0 0xffa60180 0x0 0x20>;
+ };
+
+ qos_usb_otg0: qos at ffa70000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa70000 0x0 0x20>;
+ };
+
+ qos_usb_otg1: qos at ffa70080 {
+ compatible = "syscon";
+ reg = <0x0 0xffa70080 0x0 0x20>;
+ };
+
+ qos_sd: qos at ffa74000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa74000 0x0 0x20>;
+ };
+
+ qos_sdioaudio: qos at ffa76000 {
+ compatible = "syscon";
+ reg = <0x0 0xffa76000 0x0 0x20>;
+ };
+
qos_hdcp: qos at ffa90000 {
compatible = "syscon";
reg = <0x0 0xffa90000 0x0 0x20>;
@@ -854,6 +884,11 @@
reg = <0x0 0xffad0000 0x0 0x20>;
};
+ qos_perihp: qos at ffad8080 {
+ compatible = "syscon";
+ reg = <0x0 0xffad8080 0x0 0x20>;
+ };
+
qos_gpu: qos at ffae0000 {
compatible = "syscon";
reg = <0x0 0xffae0000 0x0 0x20>;
--
1.9.1
^ permalink raw reply related
* [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default
From: Hans Verkuil @ 2017-04-12 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491494481.2392.102.camel@pengutronix.de>
On 04/06/2017 06:01 PM, Philipp Zabel wrote:
> On Thu, 2017-04-06 at 17:43 +0200, Hans Verkuil wrote:
>> On 04/06/2017 04:54 PM, Philipp Zabel wrote:
>>> On Thu, 2017-04-06 at 16:20 +0200, Hans Verkuil wrote:
>>>> On 04/06/2017 03:55 PM, Philipp Zabel wrote:
>>>>> If the the field order is set to ANY in set_fmt, choose the currently
>>>>> set field order. If the colorspace is set to DEFAULT, choose the current
>>>>> colorspace. If any of xfer_func, ycbcr_enc or quantization are set to
>>>>> DEFAULT, either choose the current setting, or the default setting for the
>>>>> new colorspace, if non-DEFAULT colorspace was given.
>>>>>
>>>>> This allows to let field order and colorimetry settings be propagated
>>>>> from upstream by calling media-ctl on the upstream entity source pad,
>>>>> and then call media-ctl on the sink pad to manually set the input frame
>>>>> interval, without changing the already set field order and colorimetry
>>>>> information.
>>>>>
>>>>> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>>>>> ---
>>>>> This is based on imx-media-staging-md-v14, and it is supposed to allow
>>>>> configuring the pipeline with media-ctl like this:
>>>>>
>>>>> 1) media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY8_1X16/1920x1080]"
>>>>> 2) media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY8_1X16/1920x108]"
>>>>> 3) media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080]"
>>>>> 4) media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080 at 1/60]"
>>>>> 5) media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/1920x1080 at 1/30]"
>>>>>
>>>>> Without having step 4) overwrite the colorspace and field order set on
>>>>> 'ipu1_csi0':0 by the propagation in step 3).
>>>>> ---
>>>>> drivers/staging/media/imx/imx-media-csi.c | 34 +++++++++++++++++++++++++++++++
>>>>> 1 file changed, 34 insertions(+)
>>>>>
>>>>> diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c
>>>>> index 64dc454f6b371..d94ce1de2bf05 100644
>>>>> --- a/drivers/staging/media/imx/imx-media-csi.c
>>>>> +++ b/drivers/staging/media/imx/imx-media-csi.c
>>>>> @@ -1325,6 +1325,40 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
>>>>> csi_try_fmt(priv, sensor, cfg, sdformat, crop, compose, &cc);
>>>>>
>>>>> fmt = __csi_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
>>>>> +
>>>>> + /* Retain current field setting as default */
>>>>> + if (sdformat->format.field == V4L2_FIELD_ANY)
>>>>> + sdformat->format.field = fmt->field;
>>>>
>>>> sdformat->format.field should never be FIELD_ANY. If it is, then that's a
>>>> subdev bug and I'm pretty sure FIELD_NONE was intended.
>>>
>>> This is the subdev. sdformat is passed in from userspace, so we have to
>>> deal with it being set to ANY. I'm trying hard right now not to return
>>> ANY though. The values in sdformat->format are applied to fmt down
>>> below.
>>
>> Do you have a git tree with this patch? It is really hard to review without
>> having the full imx-media-csi.c source.
>
> The patch applies on top of
>
> https://github.com/slongerbeam/mediatree.git imx-media-staging-md-v14
>
> I have uploaded a branch
>
> git://git.pengutronix.de/git/pza/linux imx-media-staging-md-v14+color
>
> with the patch applied on top.
>
>> I think one problem is that it is not clearly defined how subdevs and colorspace
>> information should work.
Ah, having the full source helped.
Ignore my previous review, it was incorrect.
I'll have to think about this some more. I'll get back to this, but it may take some
time since my vacation starts tomorrow. The spec is simply unclear about how to handle
this so we have to come up with some guidelines.
Regards,
Hans
^ permalink raw reply
* [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Raviteja Garimella @ 2017-04-12 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1727318a-7ef8-1ea7-a657-241bbc96bc89@ti.com>
Hi,
On Mon, Apr 10, 2017 at 2:07 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Wednesday 05 April 2017 07:40 PM, Raviteja Garimella wrote:
>> Hi Kishon,
>>
>> On Wed, Apr 5, 2017 at 7:04 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>> Hi Ravi,
>>>
>>> On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
>>>> Hi Kishon,
>>>>
>>>> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>>>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>>>>> SoC. The phy can be configured to be in Device mode or Host
>>>>>> mode based on the type of cable connected to the port. The
>>>>>> driver registers to extcon framework to get appropriate
>>>>>> connect events for Host/Device cables connect/disconnect
>>>>>> states based on VBUS and ID interrupts.
>>>>>
>>>>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>>>>> Northstar2.
>>>>>
>>>>
>>>> Will do.
>>>>
>>>>> Sorry for not letting you know this earlier. But I feel the design of the
>>>>> driver should be changed. Extcon shouldn't be used here. The extcon
>>>>> notifications should be sent to the consumer driver and the consumer driver
>>>>> should be responsible for invoking the phy ops.
>>>>>
>>>>
>>>> The consumer drivers here would be a UDC driver (USB device
>>>> controller), EHCI and OHCI host controller drivers.
>>>> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>>>>
>>>> This phy connects to 2 host controllers, and one device controller.
>>>> That's the design in Broadcom Northstar2
>>>> platform. The values of the VBUS and ID pins of this port are
>>>> determined based on the type of the cable (device cable
>>>> or host cable). And. phy has to be configured accordingly.
>>>>
>>>>> The phy ops being invoked during extcon events doesn't look right.
>>>>
>>>> Could you please elaborate on the concern, so that we can think of
>>>> mitigating those issues in this driver?
>>>> Since we are dealing with phy init/shutdown in this driver itself, are
>>>> you okay with moving the extcon handling code
>>>> out of phy ops ?
>>>
>>> yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
>>> extcon events too. Can a phy which is initialized by a phy consumer (say your
>>> UDC invokes phy_init) can be shutdown by an extcon event?
>>>
>>> Maybe a clear explanation of when phy_ops here will be invoked and when it will
>>> set using extcon events might help.
>>>
>>
>> Say, we have a USB pendrive which is connected to the DRD port through
>> a host cable.
>> Now the PHY will be initialized to be in host mode.
>> When the pendrive is unplugged, and we now connect the NS2 device to
>> some linux PC,
>> now the PHY has to be shutdown, and re-initialized to be in Device mode.
>>
>> On unplug event, it is set neither to Host nor Device mode (basically
>> shutdown). Next time which ever cable is connected, the PHY is
>> initialized to the respective
>> mode.
>>
>> Please let me know if it's fine to do these initializations outside
>> phy ops, because those will
>> be irrelevant for phy consumers (the controllers) as it's anyways
>> dealt in the phy driver through
>> extcon.
>
> Yes. We shouldn't add phy_ops just for the sake of it. I think this should be
> made as a purely extcon driver (though there are a couple of bits that looks
> like initializing PHY) and keep it in drivers/extcon.
>
Actually phy_ops would be required when we want phy to be shutdown/init
during power management, where USB controllers would call them.
I reworked on this driver to address the concerns raised here. Please check
PATCH v5 that I will submit shortly.
If we want to dynamically change the mode of PHY either to be in host mode
or device mode or idle, we don't have to do a full PHY init/power on (that
earlier required doing a PHY PLL lock and other resets). We just have to
program couple of register bits that are dedicated for this purpose.
I made those changes, now we don't have to call phy ops in the driver.
Phy_ops will be called only by the consumer drivers.
Thanks,
Ravi
> Thanks
> Kishon
^ permalink raw reply
* [PATCHv3 00/14] arm_pmu: ACPI support
From: Hanjun Guo @ 2017-04-12 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1491899997-32210-1-git-send-email-mark.rutland@arm.com>
On 2017/4/11 16:39, Mark Rutland wrote:
> Hi,
>
> This series implements ACPI support in the ARM PMU code. It borrows some code
> from Jeremy's series [1], but takes a different approach to probing and
> association, using the usual hotplug state machine, minimising external changes
> required, and simplifying the relationship with the common arm_pmu code.
>
> The first few patches are preparatory cleanup/refactoring, with the latter half
> of the series being specific to ACPI support.
>
> The series is based on Will's perf/updates branch [2]. I've pushed the whole
> series out to the arm/perf/acpi branch [3] of my kernel.org repo.
>
> Due to the innards of the hotplug callback framework, it's not entirely
> safe to register a PMU in a hotplug callback. Due to this, we can only
> associated hotplugged CPUs with a PMU if a matching CPU was around at
> probe time. A similar restriction already applies to DT systems. We may
> be able to relax this with some future work.
>
> I've given this some testing on a Juno platform (using SPIs). To see that IRQs
> are correctly associated, I've tested with the following:
>
> $ taskset -c ${SOME_CPU_HERE} perf record \
> -e armv8_pmuv3_0/cpu_cycles/ \
> -e armv8_pmuv3_1/cpu_cycles/ \
> cat /proc/interrupts
>
> I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the
> association logic. This has also been tested in a VM using PPIs; I do not have
> access to a host machine which itself uses PPIs.
Hisilicon D03 using PPIs, I tested this patch set on D03 and basic perf events
work well.
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Thanks
Hanjun
^ permalink raw reply
* [PATCH 1/1] ARM: dts: dra7: Reduce cpu thermal shutdown temperature
From: Ravikumar Kattekola @ 2017-04-12 6:24 UTC (permalink / raw)
To: linux-arm-kernel
On dra7, as per TRM, the HW shutdown (TSHUT) temperature is hardcoded
to 123C and cannot be modified by SW. This means when the temperature
reaches 123C HW asserts TSHUT output which signals a warm reset.
This reset is held until the temperature goes below the TSHUT low (105C).
While in SW, the thermal driver continuously monitors current temperature
and takes decisions based on whether it reached an alert or a critical point.
The intention of setting a SW critical point is to prevent force reset by HW
and instead do an orderly_poweroff(). But if the SW critical temperature is
greater than or equal to that of HW then it defeats the purpose. To address
this and let SW take action before HW does keep the SW critical temperature
less than HW TSHUT value.
The value for SW critical temperature was chosen as 120C just to ensure
we give SW sometime before HW catches up.
Document reference
SPRUI30C ? DRA75x, DRA74x Technical Reference Manual - November 2016
SPRUHZ6H - AM572x Technical Reference Manual - November 2016
Tested on:
DRA75x PG 2.0 Rev H EVM
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 57892f2..e714466 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -2017,4 +2017,8 @@
coefficients = <0 2000>;
};
+&cpu_crit {
+ temperature = <120000>; /* milli Celsius */
+};
+
/include/ "dra7xx-clocks.dtsi"
--
2.8.0.GIT
^ permalink raw reply related
* [PATCH 0/7] arm64: marvell: add cryptographic engine support for 7k/8k
From: Herbert Xu @ 2017-04-12 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87efwyj53q.fsf@free-electrons.com>
On Tue, Apr 11, 2017 at 06:12:25PM +0200, Gregory CLEMENT wrote:
>
> > I have no problems with the crypto bits.
>
> Does it means that you agree that I apply the arm-soc related patches
> (from 4 to 7) to my mvebu trees?
Yes sure.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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