* Re: [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
From: Brian Masney @ 2019-09-16 12:02 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: mark.rutland, devicetree, jernej.skrabec, dri-devel, narmstrong,
airlied, linux-arm-msm, linus.walleij, jonas, linux-kernel,
robh+dt, bjorn.andersson, Andrzej Hajda, robdclark, agross,
Laurent Pinchart, daniel, freedreno, sean, linux-arm-kernel
In-Reply-To: <3ec4f0bc-f3c5-aebf-8213-bc4f80915902@collabora.com>
On Mon, Sep 16, 2019 at 01:32:58PM +0200, Enric Balletbo i Serra wrote:
> Hi,
>
> On 16/9/19 12:49, Laurent Pinchart wrote:
> > Hi Brian,
> >
> > On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
> >> On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
> >>> On 15.08.2019 02:48, Brian Masney wrote:
> >>>> When attempting to configure this driver on a Nexus 5 phone (msm8974),
> >>>> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
> >>>> error. The downstream MSM kernel sources [1] shows that the proper value
> >>>> for TX_P0 is 0x78, not 0x70, so correct the value to allow device
> >>>> probing to succeed.
> >>>>
> >>>> [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h
> >>>>
> >>>> Signed-off-by: Brian Masney <masneyb@onstation.org>
> >>>> ---
> >>>> drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> >>>> index 25e063bcecbc..bc511fc605c9 100644
> >>>> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
> >>>> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
> >>>> @@ -6,7 +6,7 @@
> >>>> #ifndef __ANX78xx_H
> >>>> #define __ANX78xx_H
> >>>>
> >>>> -#define TX_P0 0x70
> >>>> +#define TX_P0 0x78
> >>>
> >>>
> >>> This bothers me little. There are no upstream users, grepping android
> >>> sources suggests that both values can be used [1][2] (grep for "#define
> >>> TX_P0"), moreover there is code suggesting both values can be valid [3].
> >>>
> >>> Could you verify datasheet which i2c slave addresses are valid for this
> >>> chip, if both I guess this patch should be reworked.
> >>>
> >>>
> >>> [1]:
> >>> https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-jb-mr2/drivers/misc/slimport_anx7808/slimport_tx_reg.h
> >>>
> >>> [2]:
> >>> https://github.com/AndroidGX/SimpleGX-MM-6.0_H815_20d/blob/master/drivers/video/slimport/anx7812/slimport7812_tx_reg.h
> >>>
> >>> [3]:
> >>> https://github.com/commaai/android_kernel_leeco_msm8996/blob/master/drivers/video/msm/mdss/dp/slimport_custom_declare.h#L73
> >>
> >> This address is 0x78 on my Nexus 5. Given [3] above it looks like we
> >> need to support both addresses. What do you think about moving these
> >> addresses into device tree?
> >
> > Assuming that the device supports different addresses (I can't validate
> > that as I don't have access to the datasheet), and different addresses
> > need to be used on different systems, then the address to be used needs
> > to be provided by the firmware (DT in this case). Two options are
> > possible, either specifying the address explicitly in the device's DT
> > node, or specifying free addresses (in the form of a white list or black
> > list) and allocating an address from that pool. The latter has been
> > discussed in a BoF at the Linux Plumbers Conference last week,
> > https://linuxplumbersconf.org/event/4/contributions/542/.
> >
> >> The downstream and upstream kernel sources divide these addresses by two
> >> to get the i2c address. Here's the code in upstream:
> >>
> >> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L1353
> >> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L41
> >>
> >> I'm not sure why the actual i2c address isn't used in this code.
> >
>
> The ANX7802/12/14/16 has a slave I2C bus that provides the interface to access
> or control the chip from the AP. The I2C slave addresses used to control the
> ANX7802/12/14/16 are 70h, 72h, 7Ah, 7Eh and 80h. Every address allows you to
> access to different registers of the chip and AFAICS is not configurable.
>
> I don't think these addresses should be configured via DT but for the driver itself.
>
> My wild guess is that the ANX7808 has different addresses, but I don't have the
> datasheet of this version.
I'm able to communicate with the 7808 on my Nexus 5 using the 0x78
address. Given that the addresses appear to be fixed per model, maybe it
makes sense to drop the address #defines and add the addresses to the
data pointer in the driver's of_match_table like so:
static const struct of_device_id anx78xx_match_table[] = {
{ .compatible = "analogix,anx7808", .data = PTR_TO_7808_ADDRS },
{ .compatible = "analogix,anx7812", .data = PTR_TO_781X_ADDRS },
{ .compatible = "analogix,anx7814", .data = PTR_TO_781X_ADDRS },
{ .compatible = "analogix,anx7818", .data = PTR_TO_781X_ADDRS },
{ /* sentinel */ },
};
Brian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 00/11] Add arm64/signal initial kselftest support
From: Dave Martin @ 2019-09-16 12:14 UTC (permalink / raw)
To: Cristian Marussi
Cc: amit.kachhap, andreyknvl, shuah, linux-kselftest,
linux-arm-kernel
In-Reply-To: <74165b2e-eb4c-994f-20ca-b69f71f3f5bc@arm.com>
On Tue, Sep 10, 2019 at 01:25:31PM +0100, Cristian Marussi wrote:
> On 04/09/2019 12:47, Dave Martin wrote:
> > On Mon, Sep 02, 2019 at 12:29:21pm +0100, Cristian Marussi wrote:
> >> Hi
> >>
> >> this patchset aims to add the initial arch-specific arm64 support to
> >> kselftest starting with signals-related test-cases.
> >> A common internal test-case layout is proposed which then it is anyway
> >> wired-up to the toplevel kselftest Makefile, so that it should be possible
> >> at the end to run it on an arm64 target in the usual way with KSFT.
> >
> > BTW, it's helpful to state the base branch / commit as clearly as
> > possible near the top of the cover letter, say,
> >
> > --8<--
> >
> > This series is based on arm64/for-next/core [1]
> > commit 9ce1263033cd ("selftests, arm64: add a selftest for passing tagged pointers to kernel")
> >
> > [1] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
> >
> > -->8--
> >
> > This is particularly important if you expect the maintainer to pick up
> > the patches.
> >
> > You don't need to reference a specific commit unless there's a
> > significant chance of conflicts if the wrong commit is used, but it can
> > help provide a clue as to why you're basing on this alternate branch.
> >
>
> Ok, thanks I'll do.
>
> >> ~/linux# make TARGETS=arm64 kselftest
> >>
> >> New KSFT arm64 testcases live inside tools/testing/selftests/arm64 grouped by
> >> family inside subdirectories: arm64/signal is the first family proposed with
> >> this series.
> >> This series converts also to this subdirectory scheme the pre-existing
> >> (already queued on arm64/for-next/core) KSFT arm64 tags tests, moving them
> >> into arm64/tags.
> >>
> >> Thanks
> >>
> >> Cristian
> >>
> >>
> >> Notes:
> >> -----
> >> - further details in the included READMEs
> >>
> >> - more tests still to be written (current strategy is going through the related
> >> Kernel signal-handling code and write a test for each possible and sensible code-path)
> >> A few ideas for more TODO testcases:
> >> - fake_sigreturn_unmapped_sp: SP into unmapped addrs
> >> - fake_sigreturn_kernelspace_sp: SP into kernel addrs
> >> - fake_sigreturn_sve_bad_extra_context: SVE extra context badly formed
> >> - mangle_sve_invalid_extra_context: SVE extra_context invalid
> >>
> >> - SVE signal testcases and special handling will be part of an additional patch
> >> still to be released
> >
> > What's your approach to checking that the test failure paths work?
> >
> > We could either hack the kernel or the tests to provoke "fake" failures,
> > and I don't think it's necessary to test everything in this way,
> > providing we have confidence that the test strategy and framework works
> > in general.
> >
>
> So my approach to testing the tests itself has been as follows:
>
> - PASS path: instrumented Kernel itself to print the exact line where the SEGV
> is supposed to be called and manually check once for all (just redone now).
> Something like:
>
> # FAKE_SIGRETURN_MISALIGNED_SP :: Triggers a sigreturn with a misaligned sigframe
> Registered handlers for all signals.
> Detected MINSTKSIGSZ:9984
> Testcase initialized.
> uc context validated.
> GOOD CONTEXT grabbed from sig_copyctx handler
> Handled SIG_COPYCTX
> Calling sigreturn with fake sigframe sized:4688 at SP @FFFFCAAE5253
> [ 188.206911] Kernel SEGV @ 571 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> SIG_OK -- SP:0xFFFFCAAE5253 si_addr@:0xffffcaae5253 si_code:2 token@:0xffffcaae5253 offset:0
> ==>> completed. PASS(1)
>
>
> - FAIL path: tried at first the same approach (instrument to avoid the SEGV), but thinking that
> this could have led to general Kernel instability while processing bad sigframes,
> I instead instrumented tests and utils as follows:
>
> - mangle_ TESTS:
>
> + removed the "mangling" for each test, and observed test FAIL (NO SEGV)
>
> # MANGLE_PSTATE_INVALID_MODE_EL1h :: Mangling uc_mcontext INVALID MODE EL1h
> Registered handlers for all signals.
> Detected MINSTKSIGSZ:9984
> Testcase initialized.
> uc context validated.
> Handled SIG_TRIG
> ==>> completed. FAIL(0)
>
> + SSBS: being this a peculiar mangle_ test, where we check that SSBS is PRESERVED as it is
> on Kernel restoring sigframe (no expected SEGV), I used a kernel patched to NOT preserve
> the SSBS bit (so clearing it). Moreover I experimented with the various SSBS support levels
> (no_supp/SSBS_BIT/MRS+SSBS_BIT) and observed how test behaved related to the detected SSBS support
>
> + verify that an anomalous SEGV (no SEGV_ACCER) is detected (say a *(* int)0x00= inside handler)
>
> # MANGLE_PSTATE_INVALID_DAIF_BITS :: Mangling uc_mcontext with INVALID DAIF_BITS
> Registered handlers for all signals.
> Detected MINSTKSIGSZ:9984
> Testcase initialized.
> uc context validated.
> SIG_OK -- SP:0xFFFFFBE96DA0 si_addr@:(nil) si_code:1 token@:(nil) offset:0
> si_code != SEGV_ACCERR...test is probably broken! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> -- RX UNEXPECTED SIGNAL: 6
> ==>> completed. FAIL(0)
>
>
> - fake_sigreturn_ TESTS:
>
> + verify placing on the stack the good context grabbed from get_current_context() as it is
> (GOOD), execution flow is anomalously restored inside get_current_context() and such
> anomaly is spotted (without deadly loops)
>
> # FAKE_SIGRETURN_BAD_MAGIC :: Trigger a sigreturn with a sigframe with a bad magic
> Registered handlers for all signals.
> Detected MINSTKSIGSZ:9984
> Testcase initialized.
> uc context validated.
> GOOD CONTEXT grabbed from sig_copyctx handler
> Handled SIG_COPYCTX
> Calling sigreturn with fake sigframe sized:4688 at SP @FFFFCAC61F80
> Unexpected successful sigreturn detected: live_uc is stale ! <<<<<<<<<<<<<<<<<<<<<<<<<<<
> ==>> completed. FAIL(0)
>
> + verify that an early SEGV is detected as anomalous (say a *(* int)0x00 before fake sigframe
> has been placed on the stack)
>
> # FAKE_SIGRETURN_BAD_MAGIC :: Trigger a sigreturn with a sigframe with a bad magic
> Registered handlers for all signals.
> Detected MINSTKSIGSZ:9984
> Testcase initialized.
> uc context validated.
> GOOD CONTEXT grabbed from sig_copyctx handler
> Handled SIG_COPYCTX
> Available space:3552
> Using badly built context - ERR: BAD MAGIC !
> Calling sigreturn with fake sigframe sized:4688 at SP @FFFFE77C96D0
> SIG_OK -- SP:0xFFFFE77C96D0 si_addr@:(nil) si_code:1 token@:(nil) offset:0
> current->token ZEROED...test is probably broken! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> -- RX UNEXPECTED SIGNAL: 6
> ==>> completed. FAIL(0)
OK, seems reasonable.
I was just curious as to how you'd approached it.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: use generic free_initrd_mem()
From: Laura Abbott @ 2019-09-16 12:23 UTC (permalink / raw)
To: Mike Rapoport, Catalin Marinas, Will Deacon, Mark Rutland
Cc: linux-kernel, linux-arm-kernel, Mike Rapoport
In-Reply-To: <1568618488-19055-1-git-send-email-rppt@kernel.org>
On 9/16/19 8:21 AM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> arm64 calls memblock_free() for the initrd area in its implementation of
> free_initrd_mem(), but this call has no actual effect that late in the boot
> process. By the time initrd is freed, all the reserved memory is managed by
> the page allocator and the memblock.reserved is unused, so there is no
> point to update it.
>
People like to use memblock for keeping track of memory even if it has no
actual effect. We made this change explicitly (see 05c58752f9dc ("arm64: To remove
initrd reserved area entry from memblock") That said, moving to the generic
APIs would be nice. Maybe we can find another place to update the accounting?
> Without the memblock_free() call the only difference between arm64 and the
> generic versions of free_initrd_mem() is the memory poisoning. Switching
> arm64 to the generic version will enable the poisoning.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>
> I've boot tested it on qemu and I've checked that kexec works.
>
> arch/arm64/mm/init.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f3c7952..8ad2934 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -567,14 +567,6 @@ void free_initmem(void)
> unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
> }
>
> -#ifdef CONFIG_BLK_DEV_INITRD
> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> -{
> - free_reserved_area((void *)start, (void *)end, 0, "initrd");
> - memblock_free(__virt_to_phys(start), end - start);
> -}
> -#endif
> -
> /*
> * Dump out memory limit information on panic.
> */
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 03/15] spi: make `cs_change_delay` the first user of the `spi_delay` logic
From: Mark Brown @ 2019-09-16 12:25 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: f.fainelli, baolin.wang, linux-iio, zhang.lyra, linus.walleij,
linux-kernel, linux-spi, bcm-kernel-feedback-list, jic23,
linux-tegra, orsonzhai, linux-arm-kernel
In-Reply-To: <20190913114550.956-4-alexandru.ardelean@analog.com>
[-- Attachment #1.1: Type: text/plain, Size: 224 bytes --]
On Fri, Sep 13, 2019 at 02:45:38PM +0300, Alexandru Ardelean wrote:
> - u16 cs_change_delay;
> - u8 cs_change_delay_unit;
> + struct spi_delay cs_change_delay;
This breaks the build as there is a user of this interface.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/11] drm/bridge: analogix-anx78xx: correct value of TX_P0
From: Andrzej Hajda @ 2019-09-16 12:25 UTC (permalink / raw)
To: Brian Masney, Enric Balletbo i Serra
Cc: mark.rutland, devicetree, jernej.skrabec, dri-devel, narmstrong,
airlied, linux-arm-msm, linus.walleij, jonas, linux-kernel,
robh+dt, bjorn.andersson, robdclark, agross, Laurent Pinchart,
daniel, freedreno, sean, linux-arm-kernel
In-Reply-To: <20190916120228.GA3045@onstation.org>
On 16.09.2019 14:02, Brian Masney wrote:
> On Mon, Sep 16, 2019 at 01:32:58PM +0200, Enric Balletbo i Serra wrote:
>> Hi,
>>
>> On 16/9/19 12:49, Laurent Pinchart wrote:
>>> Hi Brian,
>>>
>>> On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
>>>> On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
>>>>> On 15.08.2019 02:48, Brian Masney wrote:
>>>>>> When attempting to configure this driver on a Nexus 5 phone (msm8974),
>>>>>> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
>>>>>> error. The downstream MSM kernel sources [1] shows that the proper value
>>>>>> for TX_P0 is 0x78, not 0x70, so correct the value to allow device
>>>>>> probing to succeed.
>>>>>>
>>>>>> [1] https://github.com/AICP/kernel_lge_hammerhead/blob/n7.1/drivers/video/slimport/slimport_tx_reg.h
>>>>>>
>>>>>> Signed-off-by: Brian Masney <masneyb@onstation.org>
>>>>>> ---
>>>>>> drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.h b/drivers/gpu/drm/bridge/analogix-anx78xx.h
>>>>>> index 25e063bcecbc..bc511fc605c9 100644
>>>>>> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.h
>>>>>> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.h
>>>>>> @@ -6,7 +6,7 @@
>>>>>> #ifndef __ANX78xx_H
>>>>>> #define __ANX78xx_H
>>>>>>
>>>>>> -#define TX_P0 0x70
>>>>>> +#define TX_P0 0x78
>>>>>
>>>>> This bothers me little. There are no upstream users, grepping android
>>>>> sources suggests that both values can be used [1][2] (grep for "#define
>>>>> TX_P0"), moreover there is code suggesting both values can be valid [3].
>>>>>
>>>>> Could you verify datasheet which i2c slave addresses are valid for this
>>>>> chip, if both I guess this patch should be reworked.
>>>>>
>>>>>
>>>>> [1]:
>>>>> https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-jb-mr2/drivers/misc/slimport_anx7808/slimport_tx_reg.h
>>>>>
>>>>> [2]:
>>>>> https://github.com/AndroidGX/SimpleGX-MM-6.0_H815_20d/blob/master/drivers/video/slimport/anx7812/slimport7812_tx_reg.h
>>>>>
>>>>> [3]:
>>>>> https://github.com/commaai/android_kernel_leeco_msm8996/blob/master/drivers/video/msm/mdss/dp/slimport_custom_declare.h#L73
>>>> This address is 0x78 on my Nexus 5. Given [3] above it looks like we
>>>> need to support both addresses. What do you think about moving these
>>>> addresses into device tree?
>>> Assuming that the device supports different addresses (I can't validate
>>> that as I don't have access to the datasheet), and different addresses
>>> need to be used on different systems, then the address to be used needs
>>> to be provided by the firmware (DT in this case). Two options are
>>> possible, either specifying the address explicitly in the device's DT
>>> node, or specifying free addresses (in the form of a white list or black
>>> list) and allocating an address from that pool. The latter has been
>>> discussed in a BoF at the Linux Plumbers Conference last week,
>>> https://linuxplumbersconf.org/event/4/contributions/542/.
>>>
>>>> The downstream and upstream kernel sources divide these addresses by two
>>>> to get the i2c address. Here's the code in upstream:
>>>>
>>>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L1353
>>>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/analogix-anx78xx.c#L41
>>>>
>>>> I'm not sure why the actual i2c address isn't used in this code.
>> The ANX7802/12/14/16 has a slave I2C bus that provides the interface to access
>> or control the chip from the AP. The I2C slave addresses used to control the
>> ANX7802/12/14/16 are 70h, 72h, 7Ah, 7Eh and 80h. Every address allows you to
>> access to different registers of the chip and AFAICS is not configurable.
>>
>> I don't think these addresses should be configured via DT but for the driver itself.
>>
>> My wild guess is that the ANX7808 has different addresses, but I don't have the
>> datasheet of this version.
> I'm able to communicate with the 7808 on my Nexus 5 using the 0x78
> address. Given that the addresses appear to be fixed per model, maybe it
> makes sense to drop the address #defines and add the addresses to the
> data pointer in the driver's of_match_table like so:
>
> static const struct of_device_id anx78xx_match_table[] = {
> { .compatible = "analogix,anx7808", .data = PTR_TO_7808_ADDRS },
> { .compatible = "analogix,anx7812", .data = PTR_TO_781X_ADDRS },
> { .compatible = "analogix,anx7814", .data = PTR_TO_781X_ADDRS },
> { .compatible = "analogix,anx7818", .data = PTR_TO_781X_ADDRS },
> { /* sentinel */ },
> };
>
> Brian
>
>
I have spotted following comment on chromium's ML[1]:
> The locations are hard coded in the register spec. Furthermore, each
> one can be changed independently--for example the Android driver puts
> 0x38 at 0x3c but leaves the rest alone.
It is not entirely clear, but IMO it suggests these addresses are
hardware configurable.
[1]:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/44601/2/drivers/auxdisplay/slimport.c#331
Regards
Andrzej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] [PATCH v3 2/3] scsi: ufs: override auto suspend tunables for ufs
From: Bean Huo (beanhuo) @ 2019-09-16 12:33 UTC (permalink / raw)
To: Stanley Chu, linux-scsi@vger.kernel.org,
martin.petersen@oracle.com, avri.altman@wdc.com,
alim.akhtar@samsung.com, pedrom.sousa@synopsys.com,
sthumma@codeaurora.org, jejb@linux.ibm.com, bvanassche@acm.org
Cc: marc.w.gonzalez@free.fr, andy.teng@mediatek.com,
chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com,
evgreen@chromium.org, subhashj@codeaurora.org,
linux-mediatek@lists.infradead.org, peter.wang@mediatek.com,
vivek.gautam@codeaurora.org, matthias.bgg@gmail.com,
kernel-team@android.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1568616437-16271-3-git-send-email-stanley.chu@mediatek.com>
>
>Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
>Reviewed-by: Avri Altman <avri.altman@wdc.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFCv4 0/7] interconnect: Add imx support via devfreq
From: Leonard Crestez @ 2019-09-16 12:34 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org
Cc: Aisheng Dong, Artur Świgoń, Saravana Kannan,
linux-pm@vger.kernel.org, Stephen Boyd, Viresh Kumar,
Michael Turquette, Krzysztof Kozlowski, Chanwoo Choi,
Kyungmin Park, MyungJoo Ham, Alexandre Bailon,
kernel@pengutronix.de, Fabio Estevam, Shawn Guo,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <cover.1566570260.git.leonard.crestez@nxp.com>
On 23.08.2019 17:37, Leonard Crestez wrote:
> This series add imx support for interconnect via devfreq: the ICC
> framework is used to aggregate requests from devices and then those are
> converted to DEV_PM_QOS_MIN_FREQUENCY requests for devfreq.
>
> Since there is no single devicetree node that can represent the "interconnect"
> new API is added to allow individual devfreq nodes to act as parsing proxies
> all mapping to a single soc-level icc provider. This is still RFC
> because of this
Any comments? I made a lot of changes relative to previous versions,
most of them solely to avoid adding a virtual node in DT bindings.
The only current interconnect provider implementation is for qcom and it
uses a firmware node as the provider node (with #interconnect-cells).
However there is no obvious equivalent of that for imx and many other SOCs.
On imx there are multiple pieces of scalable fabric which can be defined
in DT as devfreq devices and it sort of makes sense to add
#interconnect-cells to those. However when it comes to describing the
SOC interconnect graph it's much more convenient to have a single
per-SOC platform driver.
My solution is to add an "icc_proxy" API so that a single platform-level
interconnect provider can be referenced through multiple DT nodes. Does
this make sense?
The implementation is not very pretty, the interconnect platform devices
ends up enumerating the entire devicetree in order to find proxies.
Right now the interconnect API use a relatively standard split between
consumer and "provider" but I think it might make sense to have a
separate abstractions for "graph" and "midnode". A "midnode" could act
as a DT proxy if there is no single representation of the "interconnect"
and it could support custom scaling for itself (with the default being
scaling kbps into MIN_FREQ).
There are also other options:
* Pick one "main" bus and bless it as the "interconnect provider". I
want to represent buses as devfreq devices so I would have to call from
devfreq to ICC for registration somehow.
* Maybe the "no virtual device" rule could be relaxed for the
interconnect subsystem?
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: tegra: Add CPU and cache topology for Tegra194
From: Thierry Reding @ 2019-09-16 12:36 UTC (permalink / raw)
To: Thierry Reding; +Cc: linux-tegra, Joseph Lo, linux-arm-kernel, Jon Hunter
From: Thierry Reding <treding@nvidia.com>
Tegra194 has four CPU clusters, each with their own cache hierarchy.
This patch creates the CPU map for these clusters and adds the second-
and third-level caches and associates them with the CPUs.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 148 +++++++++++++++++++++--
1 file changed, 140 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index dc2e3cc71558..177e1240c081 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1583,60 +1583,192 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu@0 {
+ cpu0_0: cpu@0 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x10000>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_0>;
};
- cpu@1 {
+ cpu0_1: cpu@1 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x10001>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_0>;
};
- cpu@2 {
+ cpu1_0: cpu@2 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x100>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_1>;
};
- cpu@3 {
+ cpu1_1: cpu@3 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x101>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_1>;
};
- cpu@4 {
+ cpu2_0: cpu@4 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x200>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_2>;
};
- cpu@5 {
+ cpu2_1: cpu@5 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x201>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_2>;
};
- cpu@6 {
+ cpu3_0: cpu@6 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x10300>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_3>;
};
- cpu@7 {
+ cpu3_1: cpu@7 {
compatible = "nvidia,tegra194-carmel";
device_type = "cpu";
reg = <0x10301>;
enable-method = "psci";
+ i-cache-size = <131072>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <512>;
+ d-cache-size = <65536>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <256>;
+ next-level-cache = <&l2c_3>;
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0_0>;
+ };
+
+ core1 {
+ cpu = <&cpu0_1>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu1_0>;
+ };
+
+ core1 {
+ cpu = <&cpu1_1>;
+ };
+ };
+
+ cluster2 {
+ core0 {
+ cpu = <&cpu2_0>;
+ };
+
+ core1 {
+ cpu = <&cpu2_1>;
+ };
+ };
+
+ cluster3 {
+ core0 {
+ cpu = <&cpu3_0>;
+ };
+
+ core1 {
+ cpu = <&cpu3_1>;
+ };
+ };
+ };
+
+ l2c_0: l2-cache0 {
+ cache-size = <2097152>;
+ cache-line-size = <64>;
+ cache-sets = <2048>;
+ next-level-cache = <&l3c>;
+ };
+
+ l2c_1: l2-cache1 {
+ cache-size = <2097152>;
+ cache-line-size = <64>;
+ cache-sets = <2048>;
+ next-level-cache = <&l3c>;
+ };
+
+ l2c_2: l2-cache2 {
+ cache-size = <2097152>;
+ cache-line-size = <64>;
+ cache-sets = <2048>;
+ next-level-cache = <&l3c>;
+ };
+
+ l2c_3: l2-cache3 {
+ cache-size = <2097152>;
+ cache-line-size = <64>;
+ cache-sets = <2048>;
+ next-level-cache = <&l3c>;
+ };
+
+ l3c: l3-cache {
+ cache-size = <4194304>;
+ cache-line-size = <64>;
+ cache-sets = <4096>;
};
};
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH 03/15] spi: make `cs_change_delay` the first user of the `spi_delay` logic
From: Ardelean, Alexandru @ 2019-09-16 12:37 UTC (permalink / raw)
To: broonie@kernel.org
Cc: f.fainelli@gmail.com, baolin.wang@linaro.org,
linux-iio@vger.kernel.org, zhang.lyra@gmail.com,
linus.walleij@linaro.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org,
orsonzhai@gmail.com, jic23@kernel.org
In-Reply-To: <20190916122505.GC4352@sirena.co.uk>
On Mon, 2019-09-16 at 13:25 +0100, Mark Brown wrote:
> [External]
>
> On Fri, Sep 13, 2019 at 02:45:38PM +0300, Alexandru Ardelean wrote:
>
> > - u16 cs_change_delay;
> > - u8 cs_change_delay_unit;
> > + struct spi_delay cs_change_delay;
>
> This breaks the build as there is a user of this interface.
Ack.
Jonathan pointed this out.
There's a V3 that changes both this and it's user (in IIO).
V3:
https://lore.kernel.org/linux-iio/20190916071024.21447-1-alexandru.ardelean@analog.com/T/#t
V2:
https://lore.kernel.org/linux-iio/20190913115549.3823-1-alexandru.ardelean@analog.com/T/#t
[ archive is from the IIO list ]
Well, I'm hoping you are referring to the same user.
On a general note: I apologise for the amount of noise/spam I am doing here. Still adjusting to how to do things/changes
that touch 2 subsystems, especially when trees are not quite in-sync.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 03/15] spi: make `cs_change_delay` the first user of the `spi_delay` logic
From: Mark Brown @ 2019-09-16 12:47 UTC (permalink / raw)
To: Ardelean, Alexandru
Cc: f.fainelli@gmail.com, baolin.wang@linaro.org,
linux-iio@vger.kernel.org, zhang.lyra@gmail.com,
linus.walleij@linaro.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org,
orsonzhai@gmail.com, jic23@kernel.org
In-Reply-To: <ae469c65828443524f9ff0409f1c7a81bf64cf6b.camel@analog.com>
[-- Attachment #1.1: Type: text/plain, Size: 285 bytes --]
On Mon, Sep 16, 2019 at 12:37:12PM +0000, Ardelean, Alexandru wrote:
> > This breaks the build as there is a user of this interface.
> Ack.
> Jonathan pointed this out.
> There's a V3 that changes both this and it's user (in IIO).
That v3 seems to be a small subset of this series?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/6] PCI: amlogic: Fix probed clock names
From: Neil Armstrong @ 2019-09-16 12:50 UTC (permalink / raw)
To: khilman, lorenzo.pieralisi, kishon, bhelgaas, andrew.murray
Cc: gouwa, Neil Armstrong, linux-pci, nick, linux-kernel, yue.wang,
repk, maz, linux-amlogic, linux-arm-kernel
In-Reply-To: <20190916125022.10754-1-narmstrong@baylibre.com>
Fix the clock names used in the probe function according
to the bindings.
Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
---
drivers/pci/controller/dwc/pci-meson.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c
index 541f37a6f6a5..ab79990798f8 100644
--- a/drivers/pci/controller/dwc/pci-meson.c
+++ b/drivers/pci/controller/dwc/pci-meson.c
@@ -250,15 +250,15 @@ static int meson_pcie_probe_clocks(struct meson_pcie *mp)
if (IS_ERR(res->port_clk))
return PTR_ERR(res->port_clk);
- res->mipi_gate = meson_pcie_probe_clock(dev, "pcie_mipi_en", 0);
+ res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
if (IS_ERR(res->mipi_gate))
return PTR_ERR(res->mipi_gate);
- res->general_clk = meson_pcie_probe_clock(dev, "pcie_general", 0);
+ res->general_clk = meson_pcie_probe_clock(dev, "general", 0);
if (IS_ERR(res->general_clk))
return PTR_ERR(res->general_clk);
- res->clk = meson_pcie_probe_clock(dev, "pcie", 0);
+ res->clk = meson_pcie_probe_clock(dev, "pclk", 0);
if (IS_ERR(res->clk))
return PTR_ERR(res->clk);
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/6] arm64: dts: meson-g12: add support for PCIe
From: Neil Armstrong @ 2019-09-16 12:50 UTC (permalink / raw)
To: khilman, lorenzo.pieralisi, kishon, bhelgaas, andrew.murray
Cc: gouwa, Neil Armstrong, linux-pci, nick, linux-kernel, yue.wang,
repk, maz, linux-amlogic, linux-arm-kernel
This patchset :
- updates the Amlogic PCI bindings for G12A
- reworks the Amlogic PCIe driver to make use of the
G12a USB3+PCIe Combo PHY instead of directly writing in
the PHY register
- adds the necessary operations to the G12a USB3+PCIe Combo PHY driver
- adds the PCIe Node for G12A, G12B and SM1 SoCs
- adds the commented support for the S922X, A311D and S905D3 based
VIM3 boards.
The VIM3 schematic can be found at [1].
This patchset is dependent on Remi's "Fix reset assertion via gpio descriptor"
patch at [2].
This patchset has been tested in a A311D VIM3 and S905D3 VIM3L using a
128Go TS128GMTE110S NVMe PCIe module.
For indication, here is a bonnie++ run as ext4 formatted on the VIM3:
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
4G 93865 99 312837 96 194487 23 102808 97 415501 21 +++++ +++
and the S905D3 VIM3L version:
------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
4G 52144 95 71766 21 47302 10 57078 98 415469 44 +++++ +++
Changes since v1 at [3]:
- Collected Andrew's and Rob's Reviewed-by tags
- Added missing calls to phy_init/phy_exit
- Fixes has_shared_phy handling for MIPI clock
- Add comment in the DT concerning firmware setting the right properties
- Added SM1 Power Domain to PCIe node
[1] https://docs.khadas.com/vim3/HardwareDocs.html
[2] https://patchwork.kernel.org/patch/11125261/
[3] https://patchwork.kernel.org/cover/11136927/
Neil Armstrong (6):
dt-bindings: pci: amlogic,meson-pcie: Add G12A bindings
PCI: amlogic: Fix probed clock names
PCI: amlogic: meson: Add support for G12A
phy: meson-g12a-usb3-pcie: Add support for PCIe mode
arm64: dts: meson-g12a: Add PCIe node
arm64: dts: khadas-vim3: add commented support for PCIe
.../bindings/pci/amlogic,meson-pcie.txt | 12 +-
.../boot/dts/amlogic/meson-g12-common.dtsi | 33 +++++
.../amlogic/meson-g12b-a311d-khadas-vim3.dts | 25 ++++
.../amlogic/meson-g12b-s922x-khadas-vim3.dts | 25 ++++
.../boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 +
.../dts/amlogic/meson-sm1-khadas-vim3l.dts | 25 ++++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 4 +
drivers/pci/controller/dwc/pci-meson.c | 132 ++++++++++++++----
.../phy/amlogic/phy-meson-g12a-usb3-pcie.c | 70 ++++++++--
9 files changed, 292 insertions(+), 38 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/6] dt-bindings: pci: amlogic, meson-pcie: Add G12A bindings
From: Neil Armstrong @ 2019-09-16 12:50 UTC (permalink / raw)
To: khilman, lorenzo.pieralisi, kishon, bhelgaas, andrew.murray,
devicetree
Cc: Rob Herring, gouwa, Neil Armstrong, linux-pci, nick, linux-kernel,
yue.wang, repk, maz, linux-amlogic, linux-arm-kernel
In-Reply-To: <20190916125022.10754-1-narmstrong@baylibre.com>
Add PCIE bindings for the Amlogic G12A SoC, the support is the same
but the PHY is shared with USB3 to control the differential lines.
Thus this adds a phy phandle to control the PHY, and only requires the
MIPI clock for the Amlogic AXG SoC Family.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/pci/amlogic,meson-pcie.txt | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
index efa2c8b9b85a..84fdc422792e 100644
--- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
@@ -9,13 +9,16 @@ Additional properties are described here:
Required properties:
- compatible:
- should contain "amlogic,axg-pcie" to identify the core.
+ should contain :
+ - "amlogic,axg-pcie" for AXG SoC Family
+ - "amlogic,g12a-pcie" for G12A SoC Family
+ to identify the core.
- reg:
should contain the configuration address space.
- reg-names: Must be
- "elbi" External local bus interface registers
- "cfg" Meson specific registers
- - "phy" Meson PCIE PHY registers
+ - "phy" Meson PCIE PHY registers for AXG SoC Family
- "config" PCIe configuration space
- reset-gpios: The GPIO to generate PCIe PERST# assert and deassert signal.
- clocks: Must contain an entry for each entry in clock-names.
@@ -23,12 +26,13 @@ Required properties:
- "pclk" PCIe GEN 100M PLL clock
- "port" PCIe_x(A or B) RC clock gate
- "general" PCIe Phy clock
- - "mipi" PCIe_x(A or B) 100M ref clock gate
+ - "mipi" PCIe_x(A or B) 100M ref clock gate for AXG SoC Family
- resets: phandle to the reset lines.
- reset-names: must contain "phy" "port" and "apb"
- - "phy" Share PHY reset
+ - "phy" Share PHY reset for AXG SoC Family
- "port" Port A or B reset
- "apb" Share APB reset
+- phys: should contain a phandle to the shared phy for G12A SoC Family
- device_type:
should be "pci". As specified in designware-pcie.txt
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/6] phy: meson-g12a-usb3-pcie: Add support for PCIe mode
From: Neil Armstrong @ 2019-09-16 12:50 UTC (permalink / raw)
To: khilman, lorenzo.pieralisi, kishon, bhelgaas, andrew.murray
Cc: gouwa, Neil Armstrong, linux-pci, nick, linux-kernel, yue.wang,
repk, maz, linux-amlogic, linux-arm-kernel
In-Reply-To: <20190916125022.10754-1-narmstrong@baylibre.com>
This adds extended PCIe PHY functions for the Amlogic G12A
USB3+PCIE Combo PHY to support reset, power_on and power_off for
PCIe exclusively.
With these callbacks, we can handle all the needed operations of the
Amlogic PCIe controller driver.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../phy/amlogic/phy-meson-g12a-usb3-pcie.c | 70 ++++++++++++++++---
1 file changed, 61 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
index ac322d643c7a..08e322789e59 100644
--- a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
+++ b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
@@ -50,6 +50,8 @@
#define PHY_R5_PHY_CR_ACK BIT(16)
#define PHY_R5_PHY_BS_OUT BIT(17)
+#define PCIE_RESET_DELAY 500
+
struct phy_g12a_usb3_pcie_priv {
struct regmap *regmap;
struct regmap *regmap_cr;
@@ -196,6 +198,10 @@ static int phy_g12a_usb3_init(struct phy *phy)
struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
int data, ret;
+ ret = reset_control_reset(priv->reset);
+ if (ret)
+ return ret;
+
/* Switch PHY to USB3 */
/* TODO figure out how to handle when PCIe was set in the bootloader */
regmap_update_bits(priv->regmap, PHY_R0,
@@ -272,24 +278,64 @@ static int phy_g12a_usb3_init(struct phy *phy)
return 0;
}
-static int phy_g12a_usb3_pcie_init(struct phy *phy)
+static int phy_g12a_usb3_pcie_power_on(struct phy *phy)
+{
+ struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
+
+ if (priv->mode == PHY_TYPE_USB3)
+ return 0;
+
+ regmap_update_bits(priv->regmap, PHY_R0,
+ PHY_R0_PCIE_POWER_STATE,
+ FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
+
+ return 0;
+}
+
+static int phy_g12a_usb3_pcie_power_off(struct phy *phy)
+{
+ struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
+
+ if (priv->mode == PHY_TYPE_USB3)
+ return 0;
+
+ regmap_update_bits(priv->regmap, PHY_R0,
+ PHY_R0_PCIE_POWER_STATE,
+ FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1d));
+
+ return 0;
+}
+
+static int phy_g12a_usb3_pcie_reset(struct phy *phy)
{
struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
int ret;
- ret = reset_control_reset(priv->reset);
+ if (priv->mode == PHY_TYPE_USB3)
+ return 0;
+
+ ret = reset_control_assert(priv->reset);
if (ret)
return ret;
+ udelay(PCIE_RESET_DELAY);
+
+ ret = reset_control_deassert(priv->reset);
+ if (ret)
+ return ret;
+
+ udelay(PCIE_RESET_DELAY);
+
+ return 0;
+}
+
+static int phy_g12a_usb3_pcie_init(struct phy *phy)
+{
+ struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
+
if (priv->mode == PHY_TYPE_USB3)
return phy_g12a_usb3_init(phy);
- /* Power UP PCIE */
- /* TODO figure out when the bootloader has set USB3 mode before */
- regmap_update_bits(priv->regmap, PHY_R0,
- PHY_R0_PCIE_POWER_STATE,
- FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
-
return 0;
}
@@ -297,7 +343,10 @@ static int phy_g12a_usb3_pcie_exit(struct phy *phy)
{
struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
- return reset_control_reset(priv->reset);
+ if (priv->mode == PHY_TYPE_USB3)
+ return reset_control_reset(priv->reset);
+
+ return 0;
}
static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
@@ -326,6 +375,9 @@ static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
static const struct phy_ops phy_g12a_usb3_pcie_ops = {
.init = phy_g12a_usb3_pcie_init,
.exit = phy_g12a_usb3_pcie_exit,
+ .power_on = phy_g12a_usb3_pcie_power_on,
+ .power_off = phy_g12a_usb3_pcie_power_off,
+ .reset = phy_g12a_usb3_pcie_reset,
.owner = THIS_MODULE,
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/6] PCI: amlogic: meson: Add support for G12A
From: Neil Armstrong @ 2019-09-16 12:50 UTC (permalink / raw)
To: khilman, lorenzo.pieralisi, kishon, bhelgaas, andrew.murray
Cc: gouwa, Neil Armstrong, linux-pci, nick, linux-kernel, yue.wang,
repk, maz, linux-amlogic, linux-arm-kernel
In-Reply-To: <20190916125022.10754-1-narmstrong@baylibre.com>
Add support for the Amlogic G12A SoC using a separate shared PHY.
This adds support for fetching a PHY phandle and call the PHY init,
reset and power on/off calls instead of writing in the PHY register or
toggling the PHY reset line.
The MIPI clock and the PHY memory resource are only required for the
Amlogic AXG SoC PCIe PHY setup, thus these elements are ignored for
the Amlogic G12A having a separate shared PHY.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/pci/controller/dwc/pci-meson.c | 128 ++++++++++++++++++++-----
1 file changed, 105 insertions(+), 23 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c
index ab79990798f8..3772b02a5c55 100644
--- a/drivers/pci/controller/dwc/pci-meson.c
+++ b/drivers/pci/controller/dwc/pci-meson.c
@@ -16,6 +16,7 @@
#include <linux/reset.h>
#include <linux/resource.h>
#include <linux/types.h>
+#include <linux/phy/phy.h>
#include "pcie-designware.h"
@@ -96,12 +97,18 @@ struct meson_pcie_rc_reset {
struct reset_control *apb;
};
+struct meson_pcie_param {
+ bool has_shared_phy;
+};
+
struct meson_pcie {
struct dw_pcie pci;
struct meson_pcie_mem_res mem_res;
struct meson_pcie_clk_res clk_res;
struct meson_pcie_rc_reset mrst;
struct gpio_desc *reset_gpio;
+ struct phy *phy;
+ const struct meson_pcie_param *param;
};
static struct reset_control *meson_pcie_get_reset(struct meson_pcie *mp,
@@ -123,10 +130,12 @@ static int meson_pcie_get_resets(struct meson_pcie *mp)
{
struct meson_pcie_rc_reset *mrst = &mp->mrst;
- mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
- if (IS_ERR(mrst->phy))
- return PTR_ERR(mrst->phy);
- reset_control_deassert(mrst->phy);
+ if (!mp->param->has_shared_phy) {
+ mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
+ if (IS_ERR(mrst->phy))
+ return PTR_ERR(mrst->phy);
+ reset_control_deassert(mrst->phy);
+ }
mrst->port = meson_pcie_get_reset(mp, "port", PCIE_NORMAL_RESET);
if (IS_ERR(mrst->port))
@@ -180,27 +189,52 @@ static int meson_pcie_get_mems(struct platform_device *pdev,
if (IS_ERR(mp->mem_res.cfg_base))
return PTR_ERR(mp->mem_res.cfg_base);
- /* Meson SoC has two PCI controllers use same phy register*/
- mp->mem_res.phy_base = meson_pcie_get_mem_shared(pdev, mp, "phy");
- if (IS_ERR(mp->mem_res.phy_base))
- return PTR_ERR(mp->mem_res.phy_base);
+ /* Meson AXG SoC has two PCI controllers use same phy register */
+ if (!mp->param->has_shared_phy) {
+ mp->mem_res.phy_base =
+ meson_pcie_get_mem_shared(pdev, mp, "phy");
+ if (IS_ERR(mp->mem_res.phy_base))
+ return PTR_ERR(mp->mem_res.phy_base);
+ }
return 0;
}
-static void meson_pcie_power_on(struct meson_pcie *mp)
+static int meson_pcie_power_on(struct meson_pcie *mp)
{
- writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
+ int ret = 0;
+
+ if (mp->param->has_shared_phy) {
+ ret = phy_init(mp->phy);
+ if (ret)
+ return ret;
+
+ ret = phy_power_on(mp->phy);
+ if (ret) {
+ phy_exit(mp->phy);
+ return ret;
+ }
+ } else
+ writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
+
+ return 0;
}
-static void meson_pcie_reset(struct meson_pcie *mp)
+static int meson_pcie_reset(struct meson_pcie *mp)
{
struct meson_pcie_rc_reset *mrst = &mp->mrst;
-
- reset_control_assert(mrst->phy);
- udelay(PCIE_RESET_DELAY);
- reset_control_deassert(mrst->phy);
- udelay(PCIE_RESET_DELAY);
+ int ret = 0;
+
+ if (mp->param->has_shared_phy) {
+ ret = phy_reset(mp->phy);
+ if (ret)
+ return ret;
+ } else {
+ reset_control_assert(mrst->phy);
+ udelay(PCIE_RESET_DELAY);
+ reset_control_deassert(mrst->phy);
+ udelay(PCIE_RESET_DELAY);
+ }
reset_control_assert(mrst->port);
reset_control_assert(mrst->apb);
@@ -208,6 +242,8 @@ static void meson_pcie_reset(struct meson_pcie *mp)
reset_control_deassert(mrst->port);
reset_control_deassert(mrst->apb);
udelay(PCIE_RESET_DELAY);
+
+ return 0;
}
static inline struct clk *meson_pcie_probe_clock(struct device *dev,
@@ -250,9 +286,11 @@ static int meson_pcie_probe_clocks(struct meson_pcie *mp)
if (IS_ERR(res->port_clk))
return PTR_ERR(res->port_clk);
- res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
- if (IS_ERR(res->mipi_gate))
- return PTR_ERR(res->mipi_gate);
+ if (!mp->param->has_shared_phy) {
+ res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
+ if (IS_ERR(res->mipi_gate))
+ return PTR_ERR(res->mipi_gate);
+ }
res->general_clk = meson_pcie_probe_clock(dev, "general", 0);
if (IS_ERR(res->general_clk))
@@ -524,6 +562,7 @@ static const struct dw_pcie_ops dw_pcie_ops = {
static int meson_pcie_probe(struct platform_device *pdev)
{
+ const struct meson_pcie_param *match_data;
struct device *dev = &pdev->dev;
struct dw_pcie *pci;
struct meson_pcie *mp;
@@ -537,6 +576,19 @@ static int meson_pcie_probe(struct platform_device *pdev)
pci->dev = dev;
pci->ops = &dw_pcie_ops;
+ match_data = of_device_get_match_data(dev);
+ if (!match_data) {
+ dev_err(dev, "failed to get match data\n");
+ return -ENODEV;
+ }
+ mp->param = match_data;
+
+ if (mp->param->has_shared_phy) {
+ mp->phy = devm_phy_get(dev, "pcie");
+ if (IS_ERR(mp->phy))
+ return PTR_ERR(mp->phy);
+ }
+
mp->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(mp->reset_gpio)) {
dev_err(dev, "get reset gpio failed\n");
@@ -555,13 +607,22 @@ static int meson_pcie_probe(struct platform_device *pdev)
return ret;
}
- meson_pcie_power_on(mp);
- meson_pcie_reset(mp);
+ ret = meson_pcie_power_on(mp);
+ if (ret) {
+ dev_err(dev, "phy power on failed, %d\n", ret);
+ return ret;
+ }
+
+ ret = meson_pcie_reset(mp);
+ if (ret) {
+ dev_err(dev, "reset failed, %d\n", ret);
+ goto err_phy;
+ }
ret = meson_pcie_probe_clocks(mp);
if (ret) {
dev_err(dev, "init clock resources failed, %d\n", ret);
- return ret;
+ goto err_phy;
}
platform_set_drvdata(pdev, mp);
@@ -569,15 +630,36 @@ static int meson_pcie_probe(struct platform_device *pdev)
ret = meson_add_pcie_port(mp, pdev);
if (ret < 0) {
dev_err(dev, "Add PCIe port failed, %d\n", ret);
- return ret;
+ goto err_phy;
}
return 0;
+
+err_phy:
+ if (mp->param->has_shared_phy) {
+ phy_power_off(mp->phy);
+ phy_exit(mp->phy);
+ }
+
+ return ret;
}
+static struct meson_pcie_param meson_pcie_axg_param = {
+ .has_shared_phy = false,
+};
+
+static struct meson_pcie_param meson_pcie_g12a_param = {
+ .has_shared_phy = true,
+};
+
static const struct of_device_id meson_pcie_of_match[] = {
{
.compatible = "amlogic,axg-pcie",
+ .data = &meson_pcie_axg_param,
+ },
+ {
+ .compatible = "amlogic,g12a-pcie",
+ .data = &meson_pcie_g12a_param,
},
{},
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 6/6] arm64: dts: khadas-vim3: add commented support for PCIe
From: Neil Armstrong @ 2019-09-16 12:50 UTC (permalink / raw)
To: khilman, lorenzo.pieralisi, kishon, bhelgaas, andrew.murray
Cc: gouwa, Neil Armstrong, linux-pci, nick, linux-kernel, yue.wang,
repk, maz, linux-amlogic, linux-arm-kernel
In-Reply-To: <20190916125022.10754-1-narmstrong@baylibre.com>
The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
an USB3.0 Type A connector and a M.2 Key M slot.
The PHY driving these differential lines is shared between
the USB3.0 controller and the PCIe Controller, thus only
a single controller can use it.
The needed DT configuration when the MCU is configured to mux
the PCIe/USB3.0 differential lines to the M.2 Key M slot is
added commented and may be uncommented to disable USB3.0 from the
USB Complex and enable the PCIe controller.
The End User is not expected to uncomment the following except for
testing purposes, but instead rely on the firmware/bootloader to
update these nodes accordingly if PCIe mode is selected by the MCU.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../amlogic/meson-g12b-a311d-khadas-vim3.dts | 25 +++++++++++++++++++
.../amlogic/meson-g12b-s922x-khadas-vim3.dts | 25 +++++++++++++++++++
.../boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 +++
.../dts/amlogic/meson-sm1-khadas-vim3l.dts | 25 +++++++++++++++++++
4 files changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
index 3a6a1e0c1e32..124a80901084 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
@@ -14,3 +14,28 @@
/ {
compatible = "khadas,vim3", "amlogic,a311d", "amlogic,g12b";
};
+
+/*
+ * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
+ * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
+ * an USB3.0 Type A connector and a M.2 Key M slot.
+ * The PHY driving these differential lines is shared between
+ * the USB3.0 controller and the PCIe Controller, thus only
+ * a single controller can use it.
+ * If the MCU is configured to mux the PCIe/USB3.0 differential lines
+ * to the M.2 Key M slot, uncomment the following block to disable
+ * USB3.0 from the USB Complex and enable the PCIe controller.
+ * The End User is not expected to uncomment the following except for
+ * testing purposes, but instead rely on the firmware/bootloader to
+ * update these nodes accordingly if PCIe mode is selected by the MCU.
+ */
+/*
+&pcie {
+ status = "okay";
+};
+
+&usb {
+ phys = <&usb2_phy0>, <&usb2_phy1>;
+ phy-names = "usb2-phy0", "usb2-phy1";
+};
+ */
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
index b73deb282120..bba98f982ad6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
@@ -14,3 +14,28 @@
/ {
compatible = "khadas,vim3", "amlogic,s922x", "amlogic,g12b";
};
+
+/*
+ * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
+ * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
+ * an USB3.0 Type A connector and a M.2 Key M slot.
+ * The PHY driving these differential lines is shared between
+ * the USB3.0 controller and the PCIe Controller, thus only
+ * a single controller can use it.
+ * If the MCU is configured to mux the PCIe/USB3.0 differential lines
+ * to the M.2 Key M slot, uncomment the following block to disable
+ * USB3.0 from the USB Complex and enable the PCIe controller.
+ * The End User is not expected to uncomment the following except for
+ * testing purposes, but instead rely on the firmware/bootloader to
+ * update these nodes accordingly if PCIe mode is selected by the MCU.
+ */
+/*
+&pcie {
+ status = "okay";
+};
+
+&usb {
+ phys = <&usb2_phy0>, <&usb2_phy1>;
+ phy-names = "usb2-phy0", "usb2-phy1";
+};
+ */
diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
index 4fe7d33ebe8a..90815fa25ec6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
@@ -246,6 +246,10 @@
linux,rc-map-name = "rc-khadas";
};
+&pcie {
+ reset-gpios = <&gpio GPIOA_8 GPIO_ACTIVE_LOW>;
+};
+
&pwm_ef {
status = "okay";
pinctrl-0 = <&pwm_e_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
index 5233bd7cacfb..dbbf29a0dbf6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
@@ -68,3 +68,28 @@
clock-names = "clkin1";
status = "okay";
};
+
+/*
+ * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
+ * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
+ * an USB3.0 Type A connector and a M.2 Key M slot.
+ * The PHY driving these differential lines is shared between
+ * the USB3.0 controller and the PCIe Controller, thus only
+ * a single controller can use it.
+ * If the MCU is configured to mux the PCIe/USB3.0 differential lines
+ * to the M.2 Key M slot, uncomment the following block to disable
+ * USB3.0 from the USB Complex and enable the PCIe controller.
+ * The End User is not expected to uncomment the following except for
+ * testing purposes, but instead rely on the firmware/bootloader to
+ * update these nodes accordingly if PCIe mode is selected by the MCU.
+ */
+/*
+&pcie {
+ status = "okay";
+};
+
+&usb {
+ phys = <&usb2_phy0>, <&usb2_phy1>;
+ phy-names = "usb2-phy0", "usb2-phy1";
+};
+ */
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/6] arm64: dts: meson-g12a: Add PCIe node
From: Neil Armstrong @ 2019-09-16 12:50 UTC (permalink / raw)
To: khilman, lorenzo.pieralisi, kishon, bhelgaas, andrew.murray
Cc: gouwa, Neil Armstrong, linux-pci, nick, linux-kernel, yue.wang,
repk, maz, linux-amlogic, linux-arm-kernel
In-Reply-To: <20190916125022.10754-1-narmstrong@baylibre.com>
This adds the Amlogic G12A PCI Express controller node, also
using the USB3+PCIe Combo PHY.
The PHY mode selection is static, thus the USB3+PCIe Combo PHY
phandle would need to be removed from the USB control node if the
shared differential lines are used for PCIe instead of USB3.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../boot/dts/amlogic/meson-g12-common.dtsi | 33 +++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 4 +++
2 files changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 852cf9cf121b..7330dc37b7a6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -95,6 +95,39 @@
#size-cells = <2>;
ranges;
+ pcie: pcie@fc000000 {
+ compatible = "amlogic,g12a-pcie", "snps,dw-pcie";
+ reg = <0x0 0xfc000000 0x0 0x400000
+ 0x0 0xff648000 0x0 0x2000
+ 0x0 0xfc400000 0x0 0x200000>;
+ reg-names = "elbi", "cfg", "config";
+ interrupts = <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
+ bus-range = <0x0 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges = <0x81000000 0 0 0x0 0xfc600000 0 0x00100000
+ 0x82000000 0 0xfc700000 0x0 0xfc700000 0 0x1900000>;
+
+ clocks = <&clkc CLKID_PCIE_PHY
+ &clkc CLKID_PCIE_COMB
+ &clkc CLKID_PCIE_PLL>;
+ clock-names = "general",
+ "pclk",
+ "port";
+ resets = <&reset RESET_PCIE_CTRL_A>,
+ <&reset RESET_PCIE_APB>;
+ reset-names = "port",
+ "apb";
+ num-lanes = <1>;
+ phys = <&usb3_pcie_phy PHY_TYPE_PCIE>;
+ phy-names = "pcie";
+ status = "disabled";
+ };
+
ethmac: ethernet@ff3f0000 {
compatible = "amlogic,meson-axg-dwmac",
"snps,dwmac-3.70a",
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
index 91492819d0d8..ee9ea3c69433 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
@@ -135,6 +135,10 @@
power-domains = <&pwrc PWRC_SM1_ETH_ID>;
};
+&pcie {
+ power-domains = <&pwrc PWRC_SM1_PCIE_ID>;
+};
+
&pwrc {
compatible = "amlogic,meson-sm1-pwrc";
};
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file
From: Jean-Philippe Brucker @ 2019-09-16 12:57 UTC (permalink / raw)
To: Guo Ren, Will Deacon
Cc: aou, Linux Kernel Mailing List, Arnd Bergmann, suzuki.poulose,
Marc Zyngier, Catalin Marinas, Palmer Dabbelt, christoffer.dall,
iommu, Mike Rapoport, Anup Patel, Atish Patra, Julien Grall,
james.morse, gary, Paul Walmsley, linux-riscv, kvmarm,
linux-arm-kernel
In-Reply-To: <CAJF2gTTsHCsSpf1ncVb=ZJS2d=r+AdDi2=5z-REVS=uUg9138A@mail.gmail.com>
Hi,
On 13/09/2019 09:13, Guo Ren wrote:
> Another idea is seperate remote TLB invalidate into two instructions:
>
> - sfence.vma.b.asyc
> - sfence.vma.b.barrier // wait all async TLB invalidate operations
> finished for all harts.
It's not clear to me how this helps, but I probably don't have the whole
picture. If you have a place where it is safe to wait for the barrier to
complete, why not do the whole invalidate there?
> (I remember who mentioned me separate them into two instructions after
> session. Anup? Is the idea right ?)
>
> Actually, I never consider asyc TLB invalidate before, because current our
> light iommu did not need it.
>
> Thx all people attend the session :) Let's continue the talk.
>
>
> Guo Ren <guoren@kernel.org <mailto:guoren@kernel.org>> 于 2019年9月12日周
> 四 22:59写道：
>
> Thx Will for reply.
>
> On Thu, Sep 12, 2019 at 3:03 PM Will Deacon <will@kernel.org
> <mailto:will@kernel.org>> wrote:
> >
> > On Sun, Sep 08, 2019 at 07:52:55AM +0800, Guo Ren wrote:
> > > On Mon, Jun 24, 2019 at 6:40 PM Will Deacon <will@kernel.org
> <mailto:will@kernel.org>> wrote:
> > > > > I'll keep my system use the same ASID for SMP + IOMMU :P
> > > >
> > > > You will want a separate allocator for that:
> > > >
> > > >
> https://lkml.kernel.org/r/20190610184714.6786-2-jean-philippe.brucker@arm.com
> > >
> > > Yes, it is hard to maintain ASID between IOMMU and CPUMMU or different
> > > system, because it's difficult to synchronize the IO_ASID when the CPU
> > > ASID is rollover.
> > > But we could still use hardware broadcast TLB invalidation instruction
> > > to uniformly manage the ASID and IO_ASID, or OTHER_ASID in our IOMMU.
> >
> > That's probably a bad idea, because you'll likely stall execution on the
> > CPU until the IOTLB has completed invalidation. In the case of ATS,
> I think
> > an endpoint ATC is permitted to take over a minute to respond. In
> reality, I
> > suspect the worst you'll ever see would be in the msec range, but that's
> > still an unacceptable period of time to hold a CPU.
> Just as I've said in the session that IOTLB invalidate delay is
> another topic, My main proposal is to introduce stage1.pgd and
> stage2.pgd as address space identifiers between different TLB systems
> based on vmid, asid. My last part of sildes will show you how to
> translate stage1/2.pgd to as/vmid in PCI ATS system and the method
> could work with SMMU-v3 and intel Vt-d. (It's regret for me there is
> no time to show you the whole slides.)
>
> In our light IOMMU implementation, there's no IOTLB invalidate delay
> problem. Becasue IOMMU is very close to CPU MMU and interconnect's
> delay is the same with SMP CPUs MMU (no PCI, VM supported).
>
> To solve the problem, we could define a async mode in sfence.vma.b to
> slove the problem and finished with per_cpu_irq/exception.
The solution I had to this problem is pinning the ASID [1] used by the
IOMMU, to prevent the CPU from recycling the ASID on rollover. This way
the CPU doesn't have to wait for IOMMU invalidations to complete, when
scheduling a task that might not even have anything to do with the IOMMU.
In the Arm SMMU, ASID and IOASID (PASID) are separate identifiers. IOASID
indexes an entry in the context descriptor table, which contains the ASID.
So with unpinned shared ASID you don't need to invalidate the ATC on
rollover, since the IOASID doesn't change, but you do need to modify the
context descriptor and invalidate cached versions of it.
Once you have pinned ASIDs, you could also declare that IOASID = ASID. I
don't remember finding an argument to strictly forbid it, even though ASID
and IOASID have different sizes on Arm (respectively 8/16 and 20 bits).
Thanks,
Jean
[1]
https://lore.kernel.org/linux-iommu/20180511190641.23008-17-jean-philippe.brucker@arm.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 03/15] spi: make `cs_change_delay` the first user of the `spi_delay` logic
From: Ardelean, Alexandru @ 2019-09-16 13:04 UTC (permalink / raw)
To: broonie@kernel.org
Cc: f.fainelli@gmail.com, baolin.wang@linaro.org,
linux-iio@vger.kernel.org, zhang.lyra@gmail.com,
linus.walleij@linaro.org, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org,
orsonzhai@gmail.com, jic23@kernel.org
In-Reply-To: <20190916124707.GD4352@sirena.co.uk>
On Mon, 2019-09-16 at 13:47 +0100, Mark Brown wrote:
> [External]
>
> On Mon, Sep 16, 2019 at 12:37:12PM +0000, Ardelean, Alexandru wrote:
>
> > > This breaks the build as there is a user of this interface.
> > Ack.
> > Jonathan pointed this out.
> > There's a V3 that changes both this and it's user (in IIO).
>
> That v3 seems to be a small subset of this series?
Ack.
V3 is the first 4 patches from this series.
Well, patches 3 & 4 are squashed.
I am 100% convinced that the entire series is a good idea.
In the sense that a `struct spi_delay` may be a good idea, but at the same time, it may be un-needed.
All I wanted to do, was to add another delay somewhere, and got lost in the rework of current delays.
I thought about proposing just the first 4 patches [on their own], but I thought that showing the current series as-is
now, may be a good idea as well [to gather some feedback].
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1] arm64: dts: freescale: add initial support for colibri imx8x
From: Marcel Ziswiler @ 2019-09-16 13:04 UTC (permalink / raw)
To: devicetree
Cc: Aisheng Dong, Mark Rutland, Sascha Hauer, Pramod Kumar,
Marcel Ziswiler, Shawn Guo, Bhaskar Upadhaya, Jon Nettleton,
linux-kernel, Li Yang, Rob Herring, Vabhav Sharma, linux-imx,
Pengutronix Kernel Team, Manivannan Sadhasivam, Fabio Estevam,
Richard Hu, linux-arm-kernel, Lucas Stach
From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
This patch adds the device tree to support Toradex Colibri iMX8X a
computer on module which can be used on different carrier boards.
The module consists of a NXP i.MX 8X family SoC (either i.MX 8DualX or
8QuadXPlus), a PF8100 PMIC, a FastEthernet PHY, 1 or 2 GB of LPDDR4
RAM, some level shifters, a Micron eMMC, a USB hub, an AD7879 resistive
touch controller, a SGTL5000 audio codec and on-module CSI as well as
DSI-LVDS FFC receptacles plus an optional Bluetooth/Wi-Fi module.
Anything that is not self-contained on the module is disabled by
default.
The device tree for the Colibri Evaluation Board includes the module's
device tree and enables the supported peripherals of the carrier board
(the Colibri Evaluation Board supports almost all of them).
So far there is no display or USB functionality supported at all but
basic console UART, eMMC and Ethernet functionality work fine.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8qxp-colibri-eval-v3.dts | 15 +
.../freescale/imx8qxp-colibri-eval-v3.dtsi | 62 ++
.../boot/dts/freescale/imx8qxp-colibri.dtsi | 592 ++++++++++++++++++
4 files changed, 670 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 93fce8f0c66d..bd3764e52cfd 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -31,4 +31,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-pico-pi.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qxp-ai_ml.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8qxp-colibri-eval-v3.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts b/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts
new file mode 100644
index 000000000000..85fc800c348f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex
+ */
+
+/dts-v1/;
+
+#include "imx8qxp-colibri.dtsi"
+#include "imx8qxp-colibri-eval-v3.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX8QXP/DX on Colibri Evaluation Board V3";
+ compatible = "toradex,colibri-imx8qxp-eval-v3",
+ "toradex,colibri-imx8qxp", "fsl,imx8qxp";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dtsi
new file mode 100644
index 000000000000..f5e4f380755c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dtsi
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex
+ */
+
+#include "dt-bindings/input/linux-event-codes.h"
+
+/ {
+ aliases {
+ rtc0 = &rtc_i2c;
+ rtc1 = &rtc;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpiokeys>;
+
+ power {
+ label = "Wake-Up";
+ gpios = <&lsio_gpio3 10 GPIO_ACTIVE_HIGH>;
+ linux,code = <KEY_WAKEUP>;
+ debounce-interval = <10>;
+ gpio-key,wakeup;
+ };
+ };
+};
+
+/* Colibri Ethernet */
+&fec1 {
+ status = "okay";
+};
+
+&adma_i2c1 {
+ status = "okay";
+
+ /* M41T0M6 real time clock on carrier board */
+ rtc_i2c: rtc@68 {
+ compatible = "st,m41t0";
+ reg = <0x68>;
+ };
+};
+
+/* Colibri UART_B */
+&adma_lpuart0 {
+ status= "okay";
+};
+
+/* Colibri UART_C */
+&adma_lpuart2 {
+ status= "okay";
+};
+
+/* Colibri UART_A */
+&adma_lpuart3 {
+ status= "okay";
+};
+
+/* Colibri SDCard */
+&usdhc2 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
new file mode 100644
index 000000000000..efdc332d082e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
@@ -0,0 +1,592 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex
+ */
+
+#include "imx8qxp.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX8QXP/DX Module";
+ compatible = "toradex,colibri-imx8x", "fsl,imx8qxp";
+
+ chosen {
+ stdout-path = &adma_lpuart3;
+ };
+
+ reg_module_3v3: regulator-module-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "+V3.3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+/* Colibri Ethernet */
+&fec1 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_fec1>;
+ pinctrl-1 = <&pinctrl_fec1_sleep>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ fsl,magic-packet;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@2 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ max-speed = <100>;
+ reg = <2>;
+ };
+ };
+};
+
+/* On-module I2C */
+&adma_i2c0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c0>, <&pinctrl_sgtl5000_usb_clk>;
+ status = "okay";
+
+ /* Touch controller */
+ ad7879@2c {
+ compatible = "adi,ad7879-1";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ad7879_int>;
+ reg = <0x2c>;
+ interrupt-parent = <&lsio_gpio3>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-max-pressure = <4096>;
+ adi,resistance-plate-x = <120>;
+ adi,first-conversion-delay = /bits/ 8 <3>;
+ adi,acquisition-time = /bits/ 8 <1>;
+ adi,median-filter-size = /bits/ 8 <2>;
+ adi,averaging = /bits/ 8 <1>;
+ adi,conversion-interval = /bits/ 8 <255>;
+ };
+};
+
+/* Colibri I2C */
+&adma_i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog0>, <&pinctrl_hog1>, <&pinctrl_ext_io0>;
+
+ colibri-imx8qxp {
+ /* On-module touch pen-down interrupt */
+ pinctrl_ad7879_int: ad7879-int {
+ fsl,pins = <
+ IMX8QXP_MIPI_CSI0_I2C0_SCL_LSIO_GPIO3_IO05 0x21
+ >;
+ };
+
+ /* Colibri Analogue Inputs */
+ pinctrl_adc0: adc0grp {
+ fsl,pins = <
+ IMX8QXP_ADC_IN0_ADMA_ADC_IN0 0x60 /* SODIMM 8 */
+ IMX8QXP_ADC_IN1_ADMA_ADC_IN1 0x60 /* SODIMM 6 */
+ IMX8QXP_ADC_IN4_ADMA_ADC_IN4 0x60 /* SODIMM 4 */
+ IMX8QXP_ADC_IN5_ADMA_ADC_IN5 0x60 /* SODIMM 2 */
+ >;
+ };
+
+ pinctrl_can_int: can-int-grp {
+ fsl,pins = <
+ IMX8QXP_QSPI0A_DQS_LSIO_GPIO3_IO13 0x40 /* SODIMM 73 */
+ >;
+ };
+
+ pinctrl_csi_ctl: csictlgrp {
+ fsl,pins = <
+ IMX8QXP_QSPI0A_SS0_B_LSIO_GPIO3_IO14 0x20 /* SODIMM 77 */
+ IMX8QXP_QSPI0A_SS1_B_LSIO_GPIO3_IO15 0x20 /* SODIMM 89 */
+ >;
+ };
+
+ pinctrl_gpiokeys: gpiokeysgrp {
+ fsl,pins = <
+ IMX8QXP_QSPI0A_DATA1_LSIO_GPIO3_IO10 0x20 /* SODIMM 45 */
+ >;
+ };
+
+ /* Colibri UART_B */
+ pinctrl_lpuart0: lpuart0grp {
+ fsl,pins = <
+ IMX8QXP_UART0_RX_ADMA_UART0_RX 0x06000020 /* SODIMM 36 */
+ IMX8QXP_UART0_TX_ADMA_UART0_TX 0x06000020 /* SODIMM 38 */
+ IMX8QXP_FLEXCAN0_RX_ADMA_UART0_RTS_B 0x06000020 /* SODIMM 34 */
+ IMX8QXP_FLEXCAN0_TX_ADMA_UART0_CTS_B 0x06000020 /* SODIMM 32 */
+ >;
+ };
+
+ /* Colibri UART_C */
+ pinctrl_lpuart2: lpuart2grp {
+ fsl,pins = <
+ IMX8QXP_UART2_RX_ADMA_UART2_RX 0x06000020 /* SODIMM 19 */
+ IMX8QXP_UART2_TX_ADMA_UART2_TX 0x06000020 /* SODIMM 21 */
+ >;
+ };
+
+ /* Colibri UART_A */
+ pinctrl_lpuart3: lpuart3grp {
+ fsl,pins = <
+ IMX8QXP_FLEXCAN2_RX_ADMA_UART3_RX 0x06000020 /* SODIMM 33 */
+ IMX8QXP_FLEXCAN2_TX_ADMA_UART3_TX 0x06000020 /* SODIMM 35 */
+ >;
+ };
+
+ /* Colibri UART_A Control */
+ pinctrl_lpuart3_ctrl: lpuart3ctrlgrp {
+ fsl,pins = <
+ IMX8QXP_MIPI_DSI1_GPIO0_01_LSIO_GPIO2_IO00 0x20 /* SODIMM 23 */
+ IMX8QXP_SAI1_RXD_LSIO_GPIO0_IO29 0x20 /* SODIMM 25 */
+ IMX8QXP_SAI1_RXC_LSIO_GPIO0_IO30 0x20 /* SODIMM 27 */
+ IMX8QXP_CSI_RESET_LSIO_GPIO3_IO03 0x20 /* SODIMM 29 */
+ IMX8QXP_USDHC1_CD_B_LSIO_GPIO4_IO22 0x20 /* SODIMM 31 */
+ IMX8QXP_CSI_EN_LSIO_GPIO3_IO02 0x20 /* SODIMM 37 */
+ >;
+ };
+
+ /* Colibri Ethernet: On-module 100Mbps PHY Micrel KSZ8041 */
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ IMX8QXP_ENET0_MDC_CONN_ENET0_MDC 0x06000020
+ IMX8QXP_ENET0_MDIO_CONN_ENET0_MDIO 0x06000020
+ IMX8QXP_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL 0x61
+ IMX8QXP_ENET0_RGMII_TXC_CONN_ENET0_RCLK50M_OUT 0x06000061
+ IMX8QXP_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0 0x61
+ IMX8QXP_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1 0x61
+ IMX8QXP_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL 0x61
+ IMX8QXP_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0 0x61
+ IMX8QXP_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1 0x61
+ IMX8QXP_ENET0_RGMII_RXD2_CONN_ENET0_RMII_RX_ER 0x61
+ >;
+ };
+
+ pinctrl_fec1_sleep: fec1-sleep-grp {
+ fsl,pins = <
+ IMX8QXP_ENET0_MDC_LSIO_GPIO5_IO11 0x06000041
+ IMX8QXP_ENET0_MDIO_LSIO_GPIO5_IO10 0x06000041
+ IMX8QXP_ENET0_RGMII_TX_CTL_LSIO_GPIO4_IO30 0x41
+ IMX8QXP_ENET0_RGMII_TXC_LSIO_GPIO4_IO29 0x41
+ IMX8QXP_ENET0_RGMII_TXD0_LSIO_GPIO4_IO31 0x41
+ IMX8QXP_ENET0_RGMII_TXD1_LSIO_GPIO5_IO00 0x41
+ IMX8QXP_ENET0_RGMII_RX_CTL_LSIO_GPIO5_IO04 0x41
+ IMX8QXP_ENET0_RGMII_RXD0_LSIO_GPIO5_IO05 0x41
+ IMX8QXP_ENET0_RGMII_RXD1_LSIO_GPIO5_IO06 0x41
+ IMX8QXP_ENET0_RGMII_RXD2_LSIO_GPIO5_IO07 0x41
+ >;
+ };
+
+ /* Colibri LCD Back-Light GPIO */
+ pinctrl_gpio_bl_on: gpio-bl-on {
+ fsl,pins = <
+ IMX8QXP_QSPI0A_DATA3_LSIO_GPIO3_IO12 0x60 /* SODIMM 71 */
+ >;
+ };
+
+ pinctrl_hog0: hog0grp {
+ fsl,pins = <
+ IMX8QXP_ENET0_RGMII_TXD3_LSIO_GPIO5_IO02 0x06000020 /* SODIMM 65 */
+ IMX8QXP_CSI_D07_CI_PI_D09 0x61 /* SODIMM 65 */
+ IMX8QXP_QSPI0A_DATA2_LSIO_GPIO3_IO11 0x20 /* SODIMM 69 */
+ IMX8QXP_SAI0_TXC_LSIO_GPIO0_IO26 0x20 /* SODIMM 79 */
+ IMX8QXP_CSI_D02_CI_PI_D04 0x61 /* SODIMM 79 */
+ IMX8QXP_ENET0_RGMII_RXC_LSIO_GPIO5_IO03 0x06000020 /* SODIMM 85 */
+ IMX8QXP_CSI_D06_CI_PI_D08 0x61 /* SODIMM 85 */
+ IMX8QXP_QSPI0B_SCLK_LSIO_GPIO3_IO17 0x20 /* SODIMM 95 */
+ IMX8QXP_SAI0_RXD_LSIO_GPIO0_IO27 0x20 /* SODIMM 97 */
+ IMX8QXP_CSI_D03_CI_PI_D05 0x61 /* SODIMM 97 */
+ IMX8QXP_QSPI0B_DATA0_LSIO_GPIO3_IO18 0x20 /* SODIMM 99 */
+ IMX8QXP_SAI0_TXFS_LSIO_GPIO0_IO28 0x20 /* SODIMM 101 */
+ IMX8QXP_CSI_D00_CI_PI_D02 0x61 /* SODIMM 101 */
+ IMX8QXP_SAI0_TXD_LSIO_GPIO0_IO25 0x20 /* SODIMM 103 */
+ IMX8QXP_CSI_D01_CI_PI_D03 0x61 /* SODIMM 103 */
+ IMX8QXP_QSPI0B_DATA1_LSIO_GPIO3_IO19 0x20 /* SODIMM 105 */
+ IMX8QXP_QSPI0B_DATA2_LSIO_GPIO3_IO20 0x20 /* SODIMM 107 */
+ IMX8QXP_USB_SS3_TC2_LSIO_GPIO4_IO05 0x20 /* SODIMM 127 */
+ IMX8QXP_USB_SS3_TC3_LSIO_GPIO4_IO06 0x20 /* SODIMM 131 */
+ IMX8QXP_USB_SS3_TC1_LSIO_GPIO4_IO04 0x20 /* SODIMM 133 */
+ IMX8QXP_CSI_PCLK_LSIO_GPIO3_IO00 0x20 /* SODIMM 96 */
+ IMX8QXP_QSPI0B_DATA3_LSIO_GPIO3_IO21 0x20 /* SODIMM 98 */
+ IMX8QXP_SAI1_RXFS_LSIO_GPIO0_IO31 0x20 /* SODIMM 100 */
+ IMX8QXP_QSPI0B_DQS_LSIO_GPIO3_IO22 0x20 /* SODIMM 102 */
+ IMX8QXP_QSPI0B_SS0_B_LSIO_GPIO3_IO23 0x20 /* SODIMM 104 */
+ IMX8QXP_QSPI0B_SS1_B_LSIO_GPIO3_IO24 0x20 /* SODIMM 106 */
+ >;
+ };
+
+ pinctrl_hog1: hog1grp {
+ fsl,pins = <
+ IMX8QXP_CSI_MCLK_LSIO_GPIO3_IO01 0x20 /* SODIMM 75 */
+ IMX8QXP_QSPI0A_SCLK_LSIO_GPIO3_IO16 0x20 /* SODIMM 93 */
+ >;
+ };
+
+ /*
+ * This pin is used in the SCFW as a UART. Using it from
+ * Linux would require rewritting the SCFW board file.
+ */
+ pinctrl_hog_scfw: hogscfwgrp {
+ fsl,pins = <
+ IMX8QXP_SCU_GPIO0_00_LSIO_GPIO2_IO03 0x20 /* SODIMM 144 */
+ >;
+ };
+
+ /* On Module I2C */
+ pinctrl_i2c0: i2c0grp {
+ fsl,pins = <
+ IMX8QXP_MIPI_CSI0_GPIO0_00_ADMA_I2C0_SCL 0x06000021
+ IMX8QXP_MIPI_CSI0_GPIO0_01_ADMA_I2C0_SDA 0x06000021
+ >;
+ };
+
+ /* Colibri I2C */
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ IMX8QXP_MIPI_DSI0_GPIO0_00_ADMA_I2C1_SCL 0x06000021 /* SODIMM 196 */
+ IMX8QXP_MIPI_DSI0_GPIO0_01_ADMA_I2C1_SDA 0x06000021 /* SODIMM 194 */
+ >;
+ };
+
+ /* Colibri optional CAN on UART_B RTS/CTS */
+ pinctrl_flexcan1: flexcan0grp {
+ fsl,pins = <
+ IMX8QXP_FLEXCAN0_TX_ADMA_FLEXCAN0_TX 0x21 /* SODIMM 32 */
+ IMX8QXP_FLEXCAN0_RX_ADMA_FLEXCAN0_RX 0x21 /* SODIMM 34 */
+ >;
+ };
+
+ /* Colibri optional CAN on PS2 */
+ pinctrl_flexcan2: flexcan1grp {
+ fsl,pins = <
+ IMX8QXP_FLEXCAN1_TX_ADMA_FLEXCAN1_TX 0x21 /* SODIMM 55 */
+ IMX8QXP_FLEXCAN1_RX_ADMA_FLEXCAN1_RX 0x21 /* SODIMM 63 */
+ >;
+ };
+
+ /* On module wifi module */
+ pinctrl_pcieb: pciebgrp {
+ fsl,pins = <
+ IMX8QXP_PCIE_CTRL0_CLKREQ_B_LSIO_GPIO4_IO01 0x04000061 /* SODIMM 178 */
+ IMX8QXP_PCIE_CTRL0_WAKE_B_LSIO_GPIO4_IO02 0x04000061 /* SODIMM 94 */
+ IMX8QXP_PCIE_CTRL0_PERST_B_LSIO_GPIO4_IO00 0x60 /* SODIMM 81 */
+ >;
+ };
+
+ /* Colibri PWM_A */
+ pinctrl_pwm_a: pwma {
+ /* both pins are connected together, reserve the unused CSI_D05 */
+ fsl,pins = <
+ IMX8QXP_CSI_D05_CI_PI_D07 0x61 /* SODIMM 59 */
+ IMX8QXP_SPI0_CS1_ADMA_LCD_PWM0_OUT 0x60 /* SODIMM 59 */
+ >;
+ };
+
+ /* Colibri PWM_B */
+ pinctrl_pwm_b: pwmb {
+ fsl,pins = <
+ IMX8QXP_UART1_TX_LSIO_PWM0_OUT 0x60 /* SODIMM 28 */
+ >;
+ };
+
+ /* Colibri PWM_C */
+ pinctrl_pwm_c: pwmc {
+ fsl,pins = <
+ IMX8QXP_UART1_RX_LSIO_PWM1_OUT 0x60 /* SODIMM 30 */
+ >;
+ };
+
+ /* Colibri PWM_D */
+ pinctrl_pwm_d: pwmd {
+ /* both pins are connected together, reserve the unused CSI_D04 */
+ fsl,pins = <
+ IMX8QXP_CSI_D04_CI_PI_D06 0x61 /* SODIMM 67 */
+ IMX8QXP_UART1_RTS_B_LSIO_PWM2_OUT 0x60 /* SODIMM 67 */
+ >;
+ };
+
+ /* On-module I2S */
+ pinctrl_sai0: sai0grp {
+ fsl,pins = <
+ IMX8QXP_SPI0_SDI_ADMA_SAI0_TXD 0x06000040
+ IMX8QXP_SPI0_CS0_ADMA_SAI0_RXD 0x06000040
+ IMX8QXP_SPI0_SCK_ADMA_SAI0_TXC 0x06000040
+ IMX8QXP_SPI0_SDO_ADMA_SAI0_TXFS 0x06000040
+ >;
+ };
+
+ /* Colibri Audio Analogue Microphone GND */
+ pinctrl_sgtl5000: sgtl5000 {
+ fsl,pins = <
+ /* MIC GND EN */
+ IMX8QXP_MIPI_CSI0_I2C0_SDA_LSIO_GPIO3_IO06 0x41
+ >;
+ };
+
+ /* On-module SGTL5000 clock */
+ pinctrl_sgtl5000_usb_clk: sgtl5000-usb-clk {
+ fsl,pins = <
+ IMX8QXP_ADC_IN3_ADMA_ACM_MCLK_OUT0 0x21
+ >;
+ };
+
+ /* On-module USB interrupt */
+ pinctrl_usb3503a: usb3503a-grp {
+ fsl,pins = <
+ IMX8QXP_MIPI_CSI0_MCLK_OUT_LSIO_GPIO3_IO04 0x61
+ >;
+ };
+
+ /* Colibri USB Client Cable Detect */
+ pinctrl_usbc_det: usbc-det {
+ fsl,pins = <
+ IMX8QXP_ENET0_REFCLK_125M_25M_LSIO_GPIO5_IO09 0x06000040 /* SODIMM 137 */
+ >;
+ };
+
+ pinctrl_ext_io0: ext-io0 {
+ fsl,pins = <
+ IMX8QXP_ENET0_RGMII_RXD3_LSIO_GPIO5_IO08 0x06000040 /* SODIMM 135 */
+ >;
+ };
+
+ /* Colibri Parallel RGB LCD Interface */
+ pinctrl_lcdif: lcdif-pins {
+ fsl,pins = <
+ IMX8QXP_MCLK_OUT0_ADMA_LCDIF_CLK 0x60 /* SODIMM 56 */
+ IMX8QXP_SPI3_CS0_ADMA_LCDIF_HSYNC 0x60 /* SODIMM 68 */
+ IMX8QXP_MCLK_IN0_ADMA_LCDIF_VSYNC 0x60 /* SODIMM 82 */
+ IMX8QXP_MCLK_IN1_ADMA_LCDIF_EN 0x60 /* SODIMM 44 */
+ IMX8QXP_USDHC1_RESET_B_LSIO_GPIO4_IO19 0x60 /* SODIMM 44 */
+ IMX8QXP_ESAI0_FSR_ADMA_LCDIF_D00 0x60 /* SODIMM 76 */
+ IMX8QXP_USDHC1_WP_LSIO_GPIO4_IO21 0x60 /* SODIMM 76 */
+ IMX8QXP_ESAI0_FST_ADMA_LCDIF_D01 0x60 /* SODIMM 70 */
+ IMX8QXP_ESAI0_SCKR_ADMA_LCDIF_D02 0x60 /* SODIMM 60 */
+ IMX8QXP_ESAI0_SCKT_ADMA_LCDIF_D03 0x60 /* SODIMM 58 */
+ IMX8QXP_ESAI0_TX0_ADMA_LCDIF_D04 0x60 /* SODIMM 78 */
+ IMX8QXP_ESAI0_TX1_ADMA_LCDIF_D05 0x60 /* SODIMM 72 */
+ IMX8QXP_ESAI0_TX2_RX3_ADMA_LCDIF_D06 0x60 /* SODIMM 80 */
+ IMX8QXP_ESAI0_TX3_RX2_ADMA_LCDIF_D07 0x60 /* SODIMM 46 */
+ IMX8QXP_ESAI0_TX4_RX1_ADMA_LCDIF_D08 0x60 /* SODIMM 62 */
+ IMX8QXP_ESAI0_TX5_RX0_ADMA_LCDIF_D09 0x60 /* SODIMM 48 */
+ IMX8QXP_SPDIF0_RX_ADMA_LCDIF_D10 0x60 /* SODIMM 74 */
+ IMX8QXP_SPDIF0_TX_ADMA_LCDIF_D11 0x60 /* SODIMM 50 */
+ IMX8QXP_SPDIF0_EXT_CLK_ADMA_LCDIF_D12 0x60 /* SODIMM 52 */
+ IMX8QXP_SPI3_SCK_ADMA_LCDIF_D13 0x60 /* SODIMM 54 */
+ IMX8QXP_SPI3_SDO_ADMA_LCDIF_D14 0x60 /* SODIMM 66 */
+ IMX8QXP_SPI3_SDI_ADMA_LCDIF_D15 0x60 /* SODIMM 64 */
+ IMX8QXP_SPI3_CS1_ADMA_LCDIF_D16 0x60 /* SODIMM 57 */
+ IMX8QXP_ENET0_RGMII_TXD2_LSIO_GPIO5_IO01 0x60 /* SODIMM 57 */
+ IMX8QXP_UART1_CTS_B_ADMA_LCDIF_D17 0x60 /* SODIMM 61 */
+ >;
+ };
+
+ /* USB Host Power Enable */
+ pinctrl_usbh1_reg: usbh1-reg {
+ fsl,pins = <
+ IMX8QXP_USB_SS3_TC0_LSIO_GPIO4_IO03 0x06000040 /* SODIMM 129 */
+ >;
+ };
+
+ /* On-module eMMC */
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
+ IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD 0x21
+ IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0 0x21
+ IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1 0x21
+ IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2 0x21
+ IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3 0x21
+ IMX8QXP_EMMC0_DATA4_CONN_EMMC0_DATA4 0x21
+ IMX8QXP_EMMC0_DATA5_CONN_EMMC0_DATA5 0x21
+ IMX8QXP_EMMC0_DATA6_CONN_EMMC0_DATA6 0x21
+ IMX8QXP_EMMC0_DATA7_CONN_EMMC0_DATA7 0x21
+ IMX8QXP_EMMC0_STROBE_CONN_EMMC0_STROBE 0x41
+ IMX8QXP_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x21
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ fsl,pins = <
+ IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
+ IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD 0x21
+ IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0 0x21
+ IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1 0x21
+ IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2 0x21
+ IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3 0x21
+ IMX8QXP_EMMC0_DATA4_CONN_EMMC0_DATA4 0x21
+ IMX8QXP_EMMC0_DATA5_CONN_EMMC0_DATA5 0x21
+ IMX8QXP_EMMC0_DATA6_CONN_EMMC0_DATA6 0x21
+ IMX8QXP_EMMC0_DATA7_CONN_EMMC0_DATA7 0x21
+ IMX8QXP_EMMC0_STROBE_CONN_EMMC0_STROBE 0x41
+ IMX8QXP_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x21
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
+ IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD 0x21
+ IMX8QXP_EMMC0_DATA0_CONN_EMMC0_DATA0 0x21
+ IMX8QXP_EMMC0_DATA1_CONN_EMMC0_DATA1 0x21
+ IMX8QXP_EMMC0_DATA2_CONN_EMMC0_DATA2 0x21
+ IMX8QXP_EMMC0_DATA3_CONN_EMMC0_DATA3 0x21
+ IMX8QXP_EMMC0_DATA4_CONN_EMMC0_DATA4 0x21
+ IMX8QXP_EMMC0_DATA5_CONN_EMMC0_DATA5 0x21
+ IMX8QXP_EMMC0_DATA6_CONN_EMMC0_DATA6 0x21
+ IMX8QXP_EMMC0_DATA7_CONN_EMMC0_DATA7 0x21
+ IMX8QXP_EMMC0_STROBE_CONN_EMMC0_STROBE 0x41
+ IMX8QXP_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x21
+ >;
+ };
+
+ /* Colibri SDCard CardDetect */
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ IMX8QXP_QSPI0A_DATA0_LSIO_GPIO3_IO09 0x06000021 /* SODIMM 43 */
+ >;
+ };
+
+ pinctrl_usdhc2_gpio_sleep: usdhc2gpioslpgrp {
+ fsl,pins = <
+ IMX8QXP_QSPI0A_DATA0_LSIO_GPIO3_IO09 0x60 /* SODIMM 43 */
+ >;
+ };
+
+ /* Colibri SDCard */
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041 /* SODIMM 47 */
+ IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD 0x21 /* SODIMM 190 */
+ IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0 0x21 /* SODIMM 192 */
+ IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1 0x21 /* SODIMM 49 */
+ IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2 0x21 /* SODIMM 51 */
+ IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3 0x21 /* SODIMM 53 */
+ IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x21
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ fsl,pins = <
+ IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041 /* SODIMM 47 */
+ IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD 0x21 /* SODIMM 190 */
+ IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0 0x21 /* SODIMM 192 */
+ IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1 0x21 /* SODIMM 49 */
+ IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2 0x21 /* SODIMM 51 */
+ IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3 0x21 /* SODIMM 53 */
+ IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x21
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ fsl,pins = <
+ IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK 0x06000041 /* SODIMM 47 */
+ IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD 0x21 /* SODIMM 190 */
+ IMX8QXP_USDHC1_DATA0_CONN_USDHC1_DATA0 0x21 /* SODIMM 192 */
+ IMX8QXP_USDHC1_DATA1_CONN_USDHC1_DATA1 0x21 /* SODIMM 49 */
+ IMX8QXP_USDHC1_DATA2_CONN_USDHC1_DATA2 0x21 /* SODIMM 51 */
+ IMX8QXP_USDHC1_DATA3_CONN_USDHC1_DATA3 0x21 /* SODIMM 53 */
+ IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x21
+ >;
+ };
+
+ pinctrl_usdhc2_sleep: usdhc2slpgrp {
+ fsl,pins = <
+ IMX8QXP_USDHC1_CLK_LSIO_GPIO4_IO23 0x60 /* SODIMM 47 */
+ IMX8QXP_USDHC1_CMD_LSIO_GPIO4_IO24 0x60 /* SODIMM 190 */
+ IMX8QXP_USDHC1_DATA0_LSIO_GPIO4_IO25 0x60 /* SODIMM 192 */
+ IMX8QXP_USDHC1_DATA1_LSIO_GPIO4_IO26 0x60 /* SODIMM 49 */
+ IMX8QXP_USDHC1_DATA2_LSIO_GPIO4_IO27 0x60 /* SODIMM 51 */
+ IMX8QXP_USDHC1_DATA3_LSIO_GPIO4_IO28 0x60 /* SODIMM 53 */
+ IMX8QXP_USDHC1_VSELECT_CONN_USDHC1_VSELECT 0x21
+ >;
+ };
+
+ /* MIPI DSI I2C accessible on SODIMM (X1) and FFC (X2) */
+ pinctrl_i2c0_mipi_lvds0: mipi_lvds0_i2c0_grp {
+ fsl,pins = <
+ IMX8QXP_MIPI_DSI0_I2C0_SCL_MIPI_DSI0_I2C0_SCL 0xc6000020 /* SODIMM 140 */
+ IMX8QXP_MIPI_DSI0_I2C0_SDA_MIPI_DSI0_I2C0_SDA 0xc6000020 /* SODIMM 142 */
+ >;
+ };
+
+ /* MIPI CSI I2C accessible on SODIMM (X1) and FFC (X3) */
+ pinctrl_i2c0_mipi_lvds1: mipi_lvds1_i2c0_grp {
+ fsl,pins = <
+ IMX8QXP_MIPI_DSI1_I2C0_SCL_MIPI_DSI1_I2C0_SCL 0xc6000020 /* SODIMM 186 */
+ IMX8QXP_MIPI_DSI1_I2C0_SDA_MIPI_DSI1_I2C0_SDA 0xc6000020 /* SODIMM 188 */
+ >;
+ };
+
+ /* Colibri SPI */
+ pinctrl_lpspi2: lpspi2 {
+ fsl,pins = <
+ IMX8QXP_SPI2_CS0_LSIO_GPIO1_IO00 0x21 /* SODIMM 86 */
+ IMX8QXP_SPI2_SDO_ADMA_SPI2_SDO 0x06000040 /* SODIMM 92 */
+ IMX8QXP_SPI2_SDI_ADMA_SPI2_SDI 0x06000040 /* SODIMM 90 */
+ IMX8QXP_SPI2_SCK_ADMA_SPI2_SCK 0x06000040 /* SODIMM 88 */
+ >;
+ };
+
+ pinctrl_wifi: wifigrp {
+ fsl,pins = <
+ IMX8QXP_SCU_BOOT_MODE3_SCU_DSC_RTC_CLOCK_OUTPUT_32K 0x20
+ >;
+ };
+ };
+};
+
+/* Colibri UART_B */
+&adma_lpuart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart0>;
+};
+
+/* Colibri UART_C */
+&adma_lpuart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart2>;
+};
+
+/* Colibri UART_A */
+&adma_lpuart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart3>, <&pinctrl_lpuart3_ctrl>;
+};
+
+/* On-module eMMC */
+&usdhc1 {
+ bus-width = <8>;
+ non-removable;
+ no-sd;
+ no-sdio;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ status = "okay";
+};
+
+/* Colibri SDCard */
+&usdhc2 {
+ bus-width = <4>;
+ cd-gpios = <&lsio_gpio3 9 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_module_3v3>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_gpio_sleep>;
+ disable-wp;
+};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] ARM: dts: imx6qdl-udoo: Add Pincfgs for OTG
From: Markus Kueffner @ 2019-09-16 13:06 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree, Sascha Hauer, linux-kernel, Rob Herring,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
linux-arm-kernel
In-Reply-To: <20190415091150.GB18917@X250.skyworth_vap>
On Mon, Apr 15, 2019 at 05:11:51PM +0800, Shawn Guo wrote:
> On Sat, Apr 13, 2019 at 03:19:36PM +0200, Markus Kueffner wrote:
> > Add Pincfgs to enable the i.MX6's OTG feature for UDOO
> >
> > Signed-off-by: Markus Kueffner <kueffner.markus@gmail.com>
>
> Applied, thanks.
Hello,
I was wondering when this might get merged into a release.
Is there anything else I need to fix?
Best Regards,
Markus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/stm: dsi: higher pll out only in video burst mode
From: Benjamin Gaignard @ 2019-09-16 13:16 UTC (permalink / raw)
To: Yannick Fertré
Cc: Daniel Vetter, David Airlie, Philippe Cornu, ML dri-devel,
Linux Kernel Mailing List, Alexandre Torgue, Maxime Coquelin,
Vincent Abriou, linux-stm32, Linux ARM, Benjamin Gaignard
In-Reply-To: <1568278589-20400-1-git-send-email-yannick.fertre@st.com>
Le jeu. 12 sept. 2019 à 10:57, Yannick Fertré <yannick.fertre@st.com> a écrit :
>
> In order to better support video non-burst modes,
> the +20% on pll out is added only in burst mode.
>
> Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
> Reviewed-by: Yannick FERTRE <yannick.fertre@st.com>
Applied on drm-misc-next,
Thanks,
Benjamin
> ---
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index a03a642..514efef 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -260,8 +260,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
> /* Compute requested pll out */
> bpp = mipi_dsi_pixel_format_to_bpp(format);
> pll_out_khz = mode->clock * bpp / lanes;
> +
> /* Add 20% to pll out to be higher than pixel bw (burst mode only) */
> - pll_out_khz = (pll_out_khz * 12) / 10;
> + if (mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> + pll_out_khz = (pll_out_khz * 12) / 10;
> +
> if (pll_out_khz > dsi->lane_max_kbps) {
> pll_out_khz = dsi->lane_max_kbps;
> DRM_WARN("Warning max phy mbps is used\n");
> --
> 2.7.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] ARM, arm64: Remove arm_pm_restart()
From: Guenter Roeck @ 2019-09-16 13:17 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Thierry Reding, linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <CAK8P3a3G_9EeK-Xp7ZeA0EN7WNzrL7AxoQcNZ8z-oe5NsTYW6g@mail.gmail.com>
On 9/16/19 12:49 AM, Arnd Bergmann wrote:
> On Sat, Sep 14, 2019 at 5:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> On Mon, Jan 30, 2017 at 12:05:06PM +0100, Thierry Reding wrote:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> Hi everyone,
>>>
>>> This small series is preparatory work for a series that I'm working on
>>> which attempts to establish a formal framework for system restart and
>>> power off.
>>>
>>> Guenter has done a lot of good work in this area, but it never got
>>> merged. I think this set is a valuable addition to the kernel because
>>> it converts all odd providers to the established mechanism for restart.
>>>
>>> Since this is stretched across both 32-bit and 64-bit ARM, as well as
>>> PSCI, and given the SoC/board level of functionality, I think it might
>>> make sense to take this through the ARM SoC tree in order to simplify
>>> the interdependencies. But it should also be possible to take patches
>>> 1-4 via their respective trees this cycle and patches 5-6 through the
>>> ARM and arm64 trees for the next cycle, if that's preferred.
>>>
>>
>> We tried this twice now, and it seems to go nowhere. What does it take
>> to get it applied ?
>
> Can you send a pull request to soc@kernel.org after the merge window,
> with everyone else on Cc? If nobody objects, I'll merge it through
> the soc tree.
>
Sure, I'll rebase and do that.
Thanks,
Guenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/6] PCI: amlogic: meson: Add support for G12A
From: Andrew Murray @ 2019-09-16 13:20 UTC (permalink / raw)
To: Neil Armstrong
Cc: maz, lorenzo.pieralisi, gouwa, khilman, nick, linux-kernel,
kishon, repk, linux-pci, bhelgaas, linux-amlogic, yue.wang,
linux-arm-kernel
In-Reply-To: <20190916125022.10754-4-narmstrong@baylibre.com>
On Mon, Sep 16, 2019 at 02:50:19PM +0200, Neil Armstrong wrote:
> Add support for the Amlogic G12A SoC using a separate shared PHY.
>
> This adds support for fetching a PHY phandle and call the PHY init,
> reset and power on/off calls instead of writing in the PHY register or
> toggling the PHY reset line.
>
> The MIPI clock and the PHY memory resource are only required for the
> Amlogic AXG SoC PCIe PHY setup, thus these elements are ignored for
> the Amlogic G12A having a separate shared PHY.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/pci/controller/dwc/pci-meson.c | 128 ++++++++++++++++++++-----
> 1 file changed, 105 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c
> index ab79990798f8..3772b02a5c55 100644
> --- a/drivers/pci/controller/dwc/pci-meson.c
> +++ b/drivers/pci/controller/dwc/pci-meson.c
> @@ -16,6 +16,7 @@
> #include <linux/reset.h>
> #include <linux/resource.h>
> #include <linux/types.h>
> +#include <linux/phy/phy.h>
>
> #include "pcie-designware.h"
>
> @@ -96,12 +97,18 @@ struct meson_pcie_rc_reset {
> struct reset_control *apb;
> };
>
> +struct meson_pcie_param {
> + bool has_shared_phy;
> +};
> +
> struct meson_pcie {
> struct dw_pcie pci;
> struct meson_pcie_mem_res mem_res;
> struct meson_pcie_clk_res clk_res;
> struct meson_pcie_rc_reset mrst;
> struct gpio_desc *reset_gpio;
> + struct phy *phy;
> + const struct meson_pcie_param *param;
> };
>
> static struct reset_control *meson_pcie_get_reset(struct meson_pcie *mp,
> @@ -123,10 +130,12 @@ static int meson_pcie_get_resets(struct meson_pcie *mp)
> {
> struct meson_pcie_rc_reset *mrst = &mp->mrst;
>
> - mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
> - if (IS_ERR(mrst->phy))
> - return PTR_ERR(mrst->phy);
> - reset_control_deassert(mrst->phy);
> + if (!mp->param->has_shared_phy) {
> + mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
> + if (IS_ERR(mrst->phy))
> + return PTR_ERR(mrst->phy);
> + reset_control_deassert(mrst->phy);
> + }
>
> mrst->port = meson_pcie_get_reset(mp, "port", PCIE_NORMAL_RESET);
> if (IS_ERR(mrst->port))
> @@ -180,27 +189,52 @@ static int meson_pcie_get_mems(struct platform_device *pdev,
> if (IS_ERR(mp->mem_res.cfg_base))
> return PTR_ERR(mp->mem_res.cfg_base);
>
> - /* Meson SoC has two PCI controllers use same phy register*/
> - mp->mem_res.phy_base = meson_pcie_get_mem_shared(pdev, mp, "phy");
> - if (IS_ERR(mp->mem_res.phy_base))
> - return PTR_ERR(mp->mem_res.phy_base);
> + /* Meson AXG SoC has two PCI controllers use same phy register */
> + if (!mp->param->has_shared_phy) {
> + mp->mem_res.phy_base =
> + meson_pcie_get_mem_shared(pdev, mp, "phy");
> + if (IS_ERR(mp->mem_res.phy_base))
> + return PTR_ERR(mp->mem_res.phy_base);
> + }
>
> return 0;
> }
>
> -static void meson_pcie_power_on(struct meson_pcie *mp)
> +static int meson_pcie_power_on(struct meson_pcie *mp)
> {
> - writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
> + int ret = 0;
> +
> + if (mp->param->has_shared_phy) {
> + ret = phy_init(mp->phy);
> + if (ret)
> + return ret;
> +
> + ret = phy_power_on(mp->phy);
> + if (ret) {
> + phy_exit(mp->phy);
> + return ret;
> + }
> + } else
> + writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
> +
> + return 0;
> }
>
> -static void meson_pcie_reset(struct meson_pcie *mp)
> +static int meson_pcie_reset(struct meson_pcie *mp)
> {
> struct meson_pcie_rc_reset *mrst = &mp->mrst;
> -
> - reset_control_assert(mrst->phy);
> - udelay(PCIE_RESET_DELAY);
> - reset_control_deassert(mrst->phy);
> - udelay(PCIE_RESET_DELAY);
> + int ret = 0;
> +
> + if (mp->param->has_shared_phy) {
> + ret = phy_reset(mp->phy);
> + if (ret)
> + return ret;
> + } else {
> + reset_control_assert(mrst->phy);
> + udelay(PCIE_RESET_DELAY);
> + reset_control_deassert(mrst->phy);
> + udelay(PCIE_RESET_DELAY);
> + }
>
> reset_control_assert(mrst->port);
> reset_control_assert(mrst->apb);
> @@ -208,6 +242,8 @@ static void meson_pcie_reset(struct meson_pcie *mp)
> reset_control_deassert(mrst->port);
> reset_control_deassert(mrst->apb);
> udelay(PCIE_RESET_DELAY);
> +
> + return 0;
> }
>
> static inline struct clk *meson_pcie_probe_clock(struct device *dev,
> @@ -250,9 +286,11 @@ static int meson_pcie_probe_clocks(struct meson_pcie *mp)
> if (IS_ERR(res->port_clk))
> return PTR_ERR(res->port_clk);
>
> - res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
> - if (IS_ERR(res->mipi_gate))
> - return PTR_ERR(res->mipi_gate);
> + if (!mp->param->has_shared_phy) {
> + res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
> + if (IS_ERR(res->mipi_gate))
> + return PTR_ERR(res->mipi_gate);
> + }
>
> res->general_clk = meson_pcie_probe_clock(dev, "general", 0);
> if (IS_ERR(res->general_clk))
> @@ -524,6 +562,7 @@ static const struct dw_pcie_ops dw_pcie_ops = {
>
> static int meson_pcie_probe(struct platform_device *pdev)
> {
> + const struct meson_pcie_param *match_data;
> struct device *dev = &pdev->dev;
> struct dw_pcie *pci;
> struct meson_pcie *mp;
> @@ -537,6 +576,19 @@ static int meson_pcie_probe(struct platform_device *pdev)
> pci->dev = dev;
> pci->ops = &dw_pcie_ops;
>
> + match_data = of_device_get_match_data(dev);
> + if (!match_data) {
> + dev_err(dev, "failed to get match data\n");
> + return -ENODEV;
> + }
> + mp->param = match_data;
> +
> + if (mp->param->has_shared_phy) {
> + mp->phy = devm_phy_get(dev, "pcie");
> + if (IS_ERR(mp->phy))
> + return PTR_ERR(mp->phy);
> + }
> +
> mp->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> if (IS_ERR(mp->reset_gpio)) {
> dev_err(dev, "get reset gpio failed\n");
> @@ -555,13 +607,22 @@ static int meson_pcie_probe(struct platform_device *pdev)
> return ret;
> }
>
> - meson_pcie_power_on(mp);
> - meson_pcie_reset(mp);
> + ret = meson_pcie_power_on(mp);
> + if (ret) {
> + dev_err(dev, "phy power on failed, %d\n", ret);
> + return ret;
> + }
> +
> + ret = meson_pcie_reset(mp);
> + if (ret) {
> + dev_err(dev, "reset failed, %d\n", ret);
> + goto err_phy;
> + }
>
> ret = meson_pcie_probe_clocks(mp);
> if (ret) {
> dev_err(dev, "init clock resources failed, %d\n", ret);
> - return ret;
> + goto err_phy;
> }
>
> platform_set_drvdata(pdev, mp);
> @@ -569,15 +630,36 @@ static int meson_pcie_probe(struct platform_device *pdev)
> ret = meson_add_pcie_port(mp, pdev);
> if (ret < 0) {
> dev_err(dev, "Add PCIe port failed, %d\n", ret);
> - return ret;
> + goto err_phy;
> }
>
> return 0;
> +
> +err_phy:
> + if (mp->param->has_shared_phy) {
> + phy_power_off(mp->phy);
> + phy_exit(mp->phy);
> + }
Interestingly for AXG, if the probe fails we don't seem to do the opposite
of MESON_PCIE_PHY_POWERUP. Though I can see this is a pre-existing issue that
has little impact and probably rarely gets hit, so:
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
However it would be *super really nice* to write a meson_pcie_power_off that
mirrors meson_pcie_power_on that you could call here instead.
Thanks,
Andrew Murray
> +
> + return ret;
> }
>
> +static struct meson_pcie_param meson_pcie_axg_param = {
> + .has_shared_phy = false,
> +};
> +
> +static struct meson_pcie_param meson_pcie_g12a_param = {
> + .has_shared_phy = true,
> +};
> +
> static const struct of_device_id meson_pcie_of_match[] = {
> {
> .compatible = "amlogic,axg-pcie",
> + .data = &meson_pcie_axg_param,
> + },
> + {
> + .compatible = "amlogic,g12a-pcie",
> + .data = &meson_pcie_g12a_param,
> },
> {},
> };
> --
> 2.22.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/6] phy: meson-g12a-usb3-pcie: Add support for PCIe mode
From: Andrew Murray @ 2019-09-16 13:23 UTC (permalink / raw)
To: Neil Armstrong
Cc: maz, lorenzo.pieralisi, gouwa, khilman, nick, linux-kernel,
kishon, repk, linux-pci, bhelgaas, linux-amlogic, yue.wang,
linux-arm-kernel
In-Reply-To: <20190916125022.10754-5-narmstrong@baylibre.com>
On Mon, Sep 16, 2019 at 02:50:20PM +0200, Neil Armstrong wrote:
> This adds extended PCIe PHY functions for the Amlogic G12A
> USB3+PCIE Combo PHY to support reset, power_on and power_off for
> PCIe exclusively.
>
> With these callbacks, we can handle all the needed operations of the
> Amlogic PCIe controller driver.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../phy/amlogic/phy-meson-g12a-usb3-pcie.c | 70 ++++++++++++++++---
> 1 file changed, 61 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
> index ac322d643c7a..08e322789e59 100644
> --- a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
> +++ b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
> @@ -50,6 +50,8 @@
> #define PHY_R5_PHY_CR_ACK BIT(16)
> #define PHY_R5_PHY_BS_OUT BIT(17)
>
> +#define PCIE_RESET_DELAY 500
> +
> struct phy_g12a_usb3_pcie_priv {
> struct regmap *regmap;
> struct regmap *regmap_cr;
> @@ -196,6 +198,10 @@ static int phy_g12a_usb3_init(struct phy *phy)
> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> int data, ret;
>
> + ret = reset_control_reset(priv->reset);
> + if (ret)
> + return ret;
Reviewed-by: Andrew Murray <andrew.murray@arm.com>
> +
> /* Switch PHY to USB3 */
> /* TODO figure out how to handle when PCIe was set in the bootloader */
> regmap_update_bits(priv->regmap, PHY_R0,
> @@ -272,24 +278,64 @@ static int phy_g12a_usb3_init(struct phy *phy)
> return 0;
> }
>
> -static int phy_g12a_usb3_pcie_init(struct phy *phy)
> +static int phy_g12a_usb3_pcie_power_on(struct phy *phy)
> +{
> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> +
> + if (priv->mode == PHY_TYPE_USB3)
> + return 0;
> +
> + regmap_update_bits(priv->regmap, PHY_R0,
> + PHY_R0_PCIE_POWER_STATE,
> + FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
> +
> + return 0;
> +}
> +
> +static int phy_g12a_usb3_pcie_power_off(struct phy *phy)
> +{
> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> +
> + if (priv->mode == PHY_TYPE_USB3)
> + return 0;
> +
> + regmap_update_bits(priv->regmap, PHY_R0,
> + PHY_R0_PCIE_POWER_STATE,
> + FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1d));
> +
> + return 0;
> +}
> +
> +static int phy_g12a_usb3_pcie_reset(struct phy *phy)
> {
> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> int ret;
>
> - ret = reset_control_reset(priv->reset);
> + if (priv->mode == PHY_TYPE_USB3)
> + return 0;
> +
> + ret = reset_control_assert(priv->reset);
> if (ret)
> return ret;
>
> + udelay(PCIE_RESET_DELAY);
> +
> + ret = reset_control_deassert(priv->reset);
> + if (ret)
> + return ret;
> +
> + udelay(PCIE_RESET_DELAY);
> +
> + return 0;
> +}
> +
> +static int phy_g12a_usb3_pcie_init(struct phy *phy)
> +{
> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> +
> if (priv->mode == PHY_TYPE_USB3)
> return phy_g12a_usb3_init(phy);
>
> - /* Power UP PCIE */
> - /* TODO figure out when the bootloader has set USB3 mode before */
> - regmap_update_bits(priv->regmap, PHY_R0,
> - PHY_R0_PCIE_POWER_STATE,
> - FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
> -
> return 0;
> }
>
> @@ -297,7 +343,10 @@ static int phy_g12a_usb3_pcie_exit(struct phy *phy)
> {
> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
>
> - return reset_control_reset(priv->reset);
> + if (priv->mode == PHY_TYPE_USB3)
> + return reset_control_reset(priv->reset);
> +
> + return 0;
> }
>
> static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
> @@ -326,6 +375,9 @@ static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
> static const struct phy_ops phy_g12a_usb3_pcie_ops = {
> .init = phy_g12a_usb3_pcie_init,
> .exit = phy_g12a_usb3_pcie_exit,
> + .power_on = phy_g12a_usb3_pcie_power_on,
> + .power_off = phy_g12a_usb3_pcie_power_off,
> + .reset = phy_g12a_usb3_pcie_reset,
> .owner = THIS_MODULE,
> };
>
> --
> 2.22.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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