* [PATCH 0/5] ARM: dts: sun8i: Add touchscreen node to various tablets
From: Maxime Ripard @ 2016-09-14 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fee7e6fe-d22b-9233-121e-b403d6ee20f1@redhat.com>
Hi Hans,
On Tue, Sep 13, 2016 at 10:06:56AM +0200, Hans de Goede wrote:
> On 13-09-16 09:59, Maxime Ripard wrote:
> >On Sun, Sep 11, 2016 at 08:23:22PM +0200, Hans de Goede wrote:
> >>Hi Maxime,
> >>
> >>Now that Dmitry has queued up the firmware-name property changes
> >>in his for-linus branch, these dt patches are ready for merging.
> >
> >I queued this for 4.10.
>
> 4.10 ? Is next already frozen ? Note either way is fine
> just wondering.
Yes, the arm-soc maintainers usually stop merging PR after -rc6. It's
still a bit flexible is something major and not really huge comes up,
but for that kind of patches, I usually start queuing patches for the
next release when -rc6 is out.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160914/0586166c/attachment.sig>
^ permalink raw reply
* [kernel-hardening] Re: [PATCH v3 3/7] arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1
From: Kees Cook @ 2016-09-14 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914085159.GA13121@leverpostej>
On Wed, Sep 14, 2016 at 1:52 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Sep 13, 2016 at 01:45:21PM -0700, Kees Cook wrote:
>> On Tue, Sep 13, 2016 at 10:46 AM, Catalin Marinas
>> > +static inline bool system_uses_ttbr0_pan(void)
>> > +{
>> > + return IS_ENABLED(CONFIG_ARM64_SW_TTBR0_PAN) &&
>> > + !cpus_have_cap(ARM64_HAS_PAN);
>> > +}
>> > +
>
> [...]
>
>> > #define __uaccess_enable(alt) \
>> > do { \
>> > - asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
>> > - CONFIG_ARM64_PAN)); \
>> > + if (system_uses_ttbr0_pan()) \
>> > + uaccess_ttbr0_enable(); \
>> > + else \
>> > + asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
>> > + CONFIG_ARM64_PAN)); \
>> > } while (0)
>>
>> Does this mean that with CONFIG_ARM64_SW_TTBR0_PAN, even with ARMv8.1,
>> a cpu capability bitmask check is done each time we go through
>> __uaccess_{en,dis}able?
>
> Catalin reworked cpus_have_cap() to use static keys [1], and that's
> queued in the arm64 for-next/core branch [2].
Oh awesome! Okay, thanks.
> So this should expand to a single branch or nop that we patch when we
> detect the presence/absence of PAN. There should be no bitmap check.
/me is looking forward to v4.9 :)
>
> Thanks,
> Mark.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/454025.html
> [2] https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/core
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* [PATCH] usb: dwc3: host: inherit dma configuration from parent dev
From: Lorenzo Pieralisi @ 2016-09-14 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874m5skmv9.fsf@linux.intel.com>
On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Robin Murphy <robin.murphy@arm.com> writes:
> > On 07/09/16 10:55, Peter Chen wrote:
> > [...]
> >>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
> >>> I think we should replace
> >>>
> >>> pdev->dev.dma_mask = dev->dma_mask;
> >>> pdev->dev.dma_parms = dev->dma_parms;
> >>> dma_set_coherent_mask(&pdev->dev, dev->coherent_dma_mask);
> >>>
> >>> with of_dma_configure(), which has the chance to configure more than
> >>> just those three, as the dma API might look into different aspects:
> >>>
> >>> - iommu specific configuration
> >>> - cache coherency information
> >>> - bus type
> >>> - dma offset
> >>> - dma_map_ops pointer
> >>>
> >>> We try to handle everything in of_dma_configure() at configuration
> >>> time, and that would be the place to add anything else that we might
> >>> need in the future.
> >>>
> >>
> >> Yes, I agree with you, but just like Felipe mentioned, we also need to
> >> consider PCI device, can we do something like gpiod_get_index does? Are
> >> there any similar APIs like of_dma_configure for ACPI?
> >
> > Not yet, but Lorenzo has one in progress[1], primarily for the sake of
> > abstracting away the IOMMU configuration.
> >
> > Robin.
> >
> > [1]:http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1209911.html
>
> not exported for drivers to use. If Lorenzo is trying to making a
> matching API for ACPI systems, then it needs to follow what
> of_dma_configure() is doing, and add an EXPORT_SYMBOL_GPL()
That's easy enough, not sure I understand though why
of_dma_deconfigure() is not exported then. The second question mark
is about the dma-ranges equivalent in ACPI world; the _DMA method
seems to be the exact equivalent but to the best of my knowledge
it is ignored by the kernel, to really have an of_dma_configure()
equivalent that's really necessary, unless we want to resort to
arch specific methods (is that what x86 is currently doing ?) to
retrieve/build the dma masks.
Lorenzo
^ permalink raw reply
* [PATCH V2 1/7] dt-bindings: Update QorIQ TMU thermal bindings
From: Leo Li @ 2016-09-14 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160608195241.GA6805@rob-hp-laptop>
On Wed, Jun 8, 2016 at 2:52 PM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Jun 07, 2016 at 11:27:34AM +0800, Jia Hongtao wrote:
>> For different types of SoC the sensor id and endianness may vary.
>> "#thermal-sensor-cells" is used to provide sensor id information.
>> "little-endian" property is to tell the endianness of TMU.
>>
>> Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
>> ---
>> Changes for V2:
>> * Remove formatting chnages.
>>
>> Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 7 +++++++
>> 1 file changed, 7 insertions(+)
>
> Acked-by: Rob Herring <robh@kernel.org>
Hi Zhang Rui,
Since you have applied the driver patch, can you also apply the
binding patch? The binding is supposed to go with the driver.
Regards,
Leo
^ permalink raw reply
* [PATCH v3 4/7] arm64: Disable TTBR0_EL1 during normal kernel execution
From: Will Deacon @ 2016-09-14 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473788797-10879-5-git-send-email-catalin.marinas@arm.com>
On Tue, Sep 13, 2016 at 06:46:34PM +0100, Catalin Marinas wrote:
> When the TTBR0 PAN feature is enabled, the kernel entry points need to
> disable access to TTBR0_EL1. The PAN status of the interrupted context
> is stored as part of the saved pstate, reusing the PSR_PAN_BIT (22).
> Restoring access to TTBR0_PAN is done on exception return if returning
> to user or returning to a context where PAN was disabled.
>
> Context switching via switch_mm() must defer the update of TTBR0_EL1
> until a return to user or an explicit uaccess_enable() call.
>
> Special care needs to be taken for two cases where TTBR0_EL1 is set
> outside the normal kernel context switch operation: EFI run-time
> services (via efi_set_pgd) and CPU suspend (via cpu_(un)install_idmap).
> Code has been added to avoid deferred TTBR0_EL1 switching as in
> switch_mm() and restore the reserved TTBR0_EL1 when uninstalling the
> special TTBR0_EL1.
>
> This patch also removes a stale comment on the switch_mm() function.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/include/asm/efi.h | 26 +++++++++++++-
> arch/arm64/include/asm/mmu_context.h | 51 +++++++++++++++++++--------
> arch/arm64/include/asm/ptrace.h | 2 ++
> arch/arm64/kernel/entry.S | 67 ++++++++++++++++++++++++++++++++++++
> arch/arm64/kernel/setup.c | 9 +++++
> arch/arm64/mm/context.c | 7 +++-
> 6 files changed, 146 insertions(+), 16 deletions(-)
[...]
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index ada08b5b036d..458773ac5ec9 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -21,6 +21,8 @@
>
> #include <uapi/asm/ptrace.h>
>
> +#define _PSR_PAN_BIT 22
[...]
> + .if \el != 0
> + tbnz x22, #_PSR_PAN_BIT, 1f // Skip re-enabling TTBR0 access if previously disabled
> + .endif
I really don't like the duplication of the #defines, just because tbnz
takes a bit number rather than a mask. I think for now we should follow
the status quo and use the immediate with a comment (we already do this
with PSR_I_BIT), but perhaps as a followup we should adjust the UAPI
headers to generate the PSR masks using shifts instead?
Not taken a proper look at the series yet, but this jumped out at me :)
Will
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: Add operating-points-v2 tables for TI platforms
From: Dave Gerlach @ 2016-09-14 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913220244.txdiak6ikujvwzjk@atomide.com>
Hi Tony,
On 09/13/2016 05:02 PM, Tony Lindgren wrote:
> Hi,
>
> * Dave Gerlach <d-gerlach@ti.com> [160831 19:49]:
>> Hi,
>> This is v2 of the series to add operating-points-v2 tables for am335x,
>> am437x, dra7, and am57x platforms, but really just updates the already
>> merged v1 found here [1].
>>
>> It seems v1 was merged without the binding being finalized so this series
>> just updates the nodes that are already present in order to work with the
>> new bindings coming in v2 of the ti-cpufreq driver series which will follow
>> shortly.
>
> Assuming this will have to wait based on what you mentioned about
> am335x cpufreq regression. I guess you'll instead send few patches
> to revert?
>
Correct, these should not be merged, I will be sending a fixup series
until this series is ready.
I needed to resend the ti-cpufreq driver at [2] to get a response about
the dt binding and other updates Viresh asked for and sent this to
update the merged nodes so they would work with the driver. But the
driver has not been merged yet, so in order to re-enable the previously
existing cpufreq support on those platforms I must revert three patches
from v1 [1] of this series that got merged, which I will send.
I also found that 7694ca6e1d6f ("cpufreq: omap: Use generic platdev
driver") which went in v4.6-rc1 had already broken the existing cpufreq
support on am335x and dra7xx, so it's been missing for some time. I can
send a patch fixing that as well but I will need to remove it once the
ti-cpufreq driver in [2] below gets merged as that driver must create
the cpufreq-dt platform device instead of cpufreq-dt-platdev. So I will
send a series that can fix cpufreq until ti-cpufreq is ready which will
give us better support for more OPPs on am335x, am437x (which has no
implementation today), and dra7xx.
Regards,
Dave
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/430205.html
[2] http://www.spinics.net/lists/devicetree/msg141152.html
> Regards,
>
> Tony
>
>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/430205.html
>>
>> Dave Gerlach (3):
>> ARM: dts: am33xx: Change operating-points-v2 table to am3352 version
>> ARM: dts: am4372: Change operating-points-v2 table to am4372 version
>> ARM: dts: dra7: Change operating-points-v2 table to dra7 version
>>
>> arch/arm/boot/dts/am33xx.dtsi | 2 +-
>> arch/arm/boot/dts/am4372.dtsi | 2 +-
>> arch/arm/boot/dts/dra7.dtsi | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> --
>> 2.9.0
>>
^ permalink raw reply
* [PATCH v5 0/3] arm64: hibernate: Resume when hibernate image created on non-boot CPU
From: Rafael J. Wysocki @ 2016-09-14 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D905B6.3090504@arm.com>
On Wednesday, September 14, 2016 09:09:26 AM James Morse wrote:
> Hi Rafael,
>
> On 14/09/16 02:07, Rafael J. Wysocki wrote:
> > What's the status of this?
>
> Will has queued it in his for-next/core branch.
OK, thanks!
^ permalink raw reply
* [PATCH v2 0/3] ARM: dts: Add operating-points-v2 tables for TI platforms
From: Tony Lindgren @ 2016-09-14 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D97E9A.90400@ti.com>
* Dave Gerlach <d-gerlach@ti.com> [160914 09:45]:
> On 09/13/2016 05:02 PM, Tony Lindgren wrote:
> > Assuming this will have to wait based on what you mentioned about
> > am335x cpufreq regression. I guess you'll instead send few patches
> > to revert?
> >
>
> Correct, these should not be merged, I will be sending a fixup series until
> this series is ready.
OK
> I needed to resend the ti-cpufreq driver at [2] to get a response about the
> dt binding and other updates Viresh asked for and sent this to update the
> merged nodes so they would work with the driver. But the driver has not been
> merged yet, so in order to re-enable the previously existing cpufreq support
> on those platforms I must revert three patches from v1 [1] of this series
> that got merged, which I will send.
>
> I also found that 7694ca6e1d6f ("cpufreq: omap: Use generic platdev driver")
> which went in v4.6-rc1 had already broken the existing cpufreq support on
> am335x and dra7xx, so it's been missing for some time. I can send a patch
> fixing that as well but I will need to remove it once the ti-cpufreq driver
> in [2] below gets merged as that driver must create the cpufreq-dt platform
> device instead of cpufreq-dt-platdev. So I will send a series that can fix
> cpufreq until ti-cpufreq is ready which will give us better support for more
> OPPs on am335x, am437x (which has no implementation today), and dra7xx.
OK yeah let's fix the regression & thanks for the update.
Regards,
Tony
^ permalink raw reply
* [GIT PULL 4/4] Broadcom devicetree-arm64 changes for 4.9
From: Florian Fainelli @ 2016-09-14 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4089229.OUTltm1bc5@wuerfel>
On 09/14/2016 08:20 AM, Arnd Bergmann wrote:
> On Tuesday, September 6, 2016 6:59:18 PM CEST Florian Fainelli wrote:
>> This pull request contains Broadcom ARM64-based SoC Device Tree changes for
>> v4.9, please pull the folllowing:
>>
>> - Dhanajay adds the PWM Device Tree nodes to the Northstar 2 DTS files
>>
>
> Pulled into next/dt64, thanks!
>
> I did the pull requests for next/dt yesterday but evidently missed yours.
> Don't worry about it, I've already looked at it and it's fine. We'll
> pick it up in the next few days along with your other two pull requests.
(plaintext this time)
No worries, would you need me to change anything in the submission
process to help? Out of curiosity do you have a patchwork or other patch
tracking tool at arm at kernel.org?
--
Florian
^ permalink raw reply
* next-20160914 build: 2 failures 3 warnings (next-20160914)
From: Mark Brown @ 2016-09-14 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1bk5OS-0000Vu-1C@optimist>
On Wed, Sep 14, 2016 at 09:18:08AM +0100, Build bot for Mark Brown wrote:
Today's -next fails to build both arm and arm64 allmodconfig due to:
> arm64-allmodconfig
> ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
>
> arm-allmodconfig
> ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
due to 262d5cc6ceb293 (mfd: tps65217: Add support for IRQs) since
irq_set_parent() isn't exported.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160914/8b4658ac/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: defconfig: enable meson I2C
From: Kevin Hilman @ 2016-09-14 17:21 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 17d26e958a3a..8fa341d645ee 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -181,6 +181,7 @@ CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_IMX=y
+CONFIG_I2C_MESON=y
CONFIG_I2C_MV64XXX=y
CONFIG_I2C_QUP=y
CONFIG_I2C_TEGRA=y
--
2.9.3
^ permalink raw reply related
* [PATCH v2] ARM: dts: da850-lcdk: Add NAND to DT
From: Kevin Hilman @ 2016-09-14 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908183324.32389-1-khilman@baylibre.com>
Hi Sekhar,
On Thu, Sep 8, 2016 at 11:33 AM, Kevin Hilman <khilman@baylibre.com> wrote:
> From: Karl Beldan <kbeldan@baylibre.com>
>
> This adds DT support for the NAND connected to the SoC AEMIF.
> Passed torture hashing a 40MB file on top of UBIFS using subpages.
>
> Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
> [khilman: add back default partitions from an earlier patch]
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> Applies on Sekhar's v4.9/dts branch.
>
Looks like you need to respin your DT series for arm-soc due to build
errors. Can you add this while you're at it so we have 4-bit ECC in
v4.9?
Thanks,
Kevin
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Mark Rutland @ 2016-09-14 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914100949.GA6179@kroah.com>
Hi Greg,
On Wed, Sep 14, 2016 at 12:09:49PM +0200, Greg KH wrote:
> Given that it's never a good idea to keep subsystems out of the mainline
> kernel, I've put together this pull request that adds the greybus driver
> layer to drivers/greybus/. Because this was 2 1/2 years of work, with
> many many developers contributing, I didn't want to flatten all of their
> effort into a few small patches, as that wouldn't be very fair. So I've
> built a git tree with all of the changes going back to the first commit,
> and merged it into the kernel tree, just like btrfs was merged into the
> kernel.
> Unless people point out some major problems with this, I'd like to get
> it merged into 4.9-rc1.
I'm extremely concerned that these patches have *never* seen upstream
review, and this pull request gives no real opportunity for people to
make a judgement regarding the code, as many relevant parties have not
been Cc'd.
>From a quick scan of the git tree, I can see code (that isn't even
placed under staging/) for which I have fundamental objections to as a
maintainer, and has not been Cc'd to a relevant list.
For example, I see commit 5a450477311fbfe2 ("greybus: timesync: Add
timesync core driver"). This states that it directly accesses the ARMv7
architected timer, though it's unclear as to precisely what it's doing
since it introduces an (undocumented) compatible string, and what should
be an unnecessary devicetree property.
That's never gone to the linux-arm-kernel mainline list, myself or Marc
(as maintainers of the arch timer driver), nor has the binding seen any
review on the devicetree mailing list.
Given that, for at least that patch, NAK.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
From: Stephen Boyd @ 2016-09-14 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914093307.GC21674@b29397-desktop>
Quoting Peter Chen (2016-09-14 02:33:07)
> On Tue, Sep 13, 2016 at 11:29:12PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-09-13 19:11:33)
> > > On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> > > > Quoting Peter Chen (2016-09-13 00:03:58)
> > > > > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > > > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > > > > viewport.
> > > > > >
> > > > >
> > > > > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > > > > driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> > > > > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > > > > the system will hang. But I find you call hw_phymode_configure before
> > > > > phy->power_on, doesn't your design have this requirement?
> > > >
> > > > Which clk needs to be enabled? The xcvr_clk? I believe that clk
> > > > corresponds to the "core" clk that we enable in the msm glue driver
> > > > layer. When that clk is enabled, the ULPI phy is able to respond to
> > > > register read/writes via the ULPI viewport.
> > > >
> > >
> > > The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver,
> > > so in your platform, even PHY clock is gated, you can still access
> > > portsc.pts to configure PHY mode at controller register?
> >
> > There are a couple input clocks for this phy. I'm not sure which one the
> > nxp IC guys think needs to be enabled. Typically, the ref_clk is always
> > on so it's hard for me to test a scenario where it isn't enabled. But
> > I'm not sure that the ref_clk is what we're talking about anyway. Would
> > you know the frequency perhaps?
>
> I think this ref_clk is ULPI PHY vendor specific, at USB3317, it is
> 26Mhz.
Ok. Makes sense.
>
> > The ref_clk is usually 19.2MHz on these
> > SoCs. That would match up with the "crystal input" pin in the ULPI
> > spec[1].
> >
> > Do you know if this is documented anywhere in the chipidea manual?
> > I'll have to look again and see if there's something in there, but I
> > didn't see anything like this.
> >
> > I would guess that we're talking about the xcvr clock though, because
> > from what I see in the manual, this is used to clock the interface
> > between the ULPI phy and the controller. In the ULPI spec, this matches
> > up with the "clock" signal for the ULPI phy and that usually runs at
> > something >= 60MHz.
>
> I think you are right, since controller only concerns the output clock.
> So, if you have not enabled xcvr, you may meet hang when set portsc.pts too?
Yes. In the qcom designs the xcvr clk is necessary to read/write any of
the registers in the controller. So we wouldn't be able to touch
portsc.pts or any other controller registers without a hang.
>
> At some designs, ULPI input clock (ref_clk) may from Soc internal,
> without enabling it, the controller will not get PHY clock (60Mhz).
> When visiting portsc.pts, may meet hang.
>
> >
> > >
> > > > >
> > > > > Besides, you read ulpi id before phy->power_on, how can read work before
> > > > > phy power on?
> > > > >
> > > >
> > > > I've found that even having the link clk enabled before phy->power_on
> > > > doesn't mean it's possible to read the id registers though. That's
> > > > because there can be other power supplies, like regulators, which need
> > > > to be on for the phy to operate properly.
> > > >
> > >
> > > Then I am puzzled the current initialization for your case, in my mind,
> > > it should like below:
> > >
> > > qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init
> > >
> > > Like other PHYs, it should get PHY first, then power on it, after that,
> > > you can access its register.
> > >
> >
> > Hmm.. maybe the confusion is in which registers we should be able to
> > access? Are we talking about the ULPI viewport MMIO register space or
> > the ULPI registers that we access through the viewport? I have a
> > hw_phymode_configure() inside of of ci_ulpi_init() so that the
> > identification registers through the ULPI viewport read properly
> > (assuming there aren't other power requirements like regulators). If we
> > don't set the portsc.pts before using the viewport, the viewport doesn't
> > work and reads timeout. So we really don't touch the ULPI registers
> > except for the scratch space and the id registers until after the phy is
> > properly powered on with clks and regulators, because the only place we
> > touch them after doing the id checking is in this phy driver in
> > qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> > we don't know which device driver to probe because the phy needs to be
> > powered on to read the id registers to know which device driver to use
> > by using DT to match up device drivers instead.
> >
> > [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf
>
> Ok, ulpi phy works like USB device on USB bus which create device at
> runtime. So, like some hard-wired USB devices, it may needs power
> sequence too, otherwise, how it knows which driver can loads.
>
Yes. We use the DT compatible string to ignore any issues with reading
the device ids when the device is powered off. Unlike USB though, we
have device drivers for the ULPI PHYs that do the power sequencing along
with other initializations, so using a common pwrseq layer seems like
overkill just so we can read the id registers.
Are there any concerns with this patch? Or can they be reapplied?
^ permalink raw reply
* [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
From: Jagan Teki @ 2016-09-14 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CsrrqqUPaVbU-ya79VSXgxyspa_fbr8HY1voJgpy2LLg@mail.gmail.com>
On Wed, Sep 14, 2016 at 4:06 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Sun, Sep 11, 2016 at 3:30 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
>
>> + reg_3p3v: regulator-3p3v {
>> + compatible = "regulator-fixed";
>> + regulator-name = "3P3V";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-boot-on;
>> + regulator-always-on;
>
> You should remove " regulator-boot-on" and "regulator-always-on" as
> the reg_3p3v regulator is controlled by the can nodes.
OK, but where it showed on the processor manual? I only find LDO_2P5
regulator which is connected to high speed devices, HDMI, SATA etc on
Figure 50-1: Power system overview
thanks!
--
Jagan Teki
Free Software Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
From: Fabio Estevam @ 2016-09-14 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMty3ZDKrXxmwDFxSBvL_anJQPdXEfnJ40uNv5B6KssQyJJKhA@mail.gmail.com>
On Wed, Sep 14, 2016 at 2:43 PM, Jagan Teki <jagan@amarulasolutions.com> wrote:
> OK, but where it showed on the processor manual? I only find LDO_2P5
It is not a SoC regulator. It is the regulator that powers the CAN transceiver.
^ permalink raw reply
* [PATCH v2 5/6] ARM64: meson-gxbb-p20x: Enable USB Nodes
From: Kevin Hilman @ 2016-09-14 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911134111.31141-6-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> From: Jerome Brunet <jbrunet@baylibre.com>
>
> Enable both gxbb USB controller and add a 5V regulator for the OTG port
> VBUS
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
nit: subject should have "ARM64: dts:" prefix.
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 29 ++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index ce105fe..4493bce 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -93,6 +93,18 @@
> compatible = "mmc-pwrseq-emmc";
> reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> };
> +
> + usb_vbus: regulator-usb0-vbus {
nit: I like to use the signal name from the schematics for the node name
(and for regulator-name below). In the schematics, that signal is named
USB_PWR.
> + compatible = "regulator-fixed";
> +
> + regulator-name = "USB0_VBUS";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> +
> + gpio = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>;
Please add a comment above this line with the schematic signal name: USB_PWR_EN.
> + enable-active-high;
> + };
> };
Kevin
^ permalink raw reply
* [GIT PULL] Amlogic DT updates for v4.9
From: Kevin Hilman @ 2016-09-14 18:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
Just a single patch for 32-bit DT changes for Amlogic SoCs this round.
Please pull.
Thanks,
Kevin
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt
for you to fetch changes up to a29c830a28721bb684c212206b2bab6dc53d0cb4:
ARM: dts: meson8b: Add Meson8b PWM Controller nodes (2016-09-07 13:16:13 -0700)
----------------------------------------------------------------
Amlogic DT updates for v4.9
- add PWM support
----------------------------------------------------------------
Neil Armstrong (1):
ARM: dts: meson8b: Add Meson8b PWM Controller nodes
arch/arm/boot/dts/meson8b.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Greg KH @ 2016-09-14 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914173625.GB15356@leverpostej>
On Wed, Sep 14, 2016 at 06:36:26PM +0100, Mark Rutland wrote:
> Hi Greg,
>
> On Wed, Sep 14, 2016 at 12:09:49PM +0200, Greg KH wrote:
> > Given that it's never a good idea to keep subsystems out of the mainline
> > kernel, I've put together this pull request that adds the greybus driver
> > layer to drivers/greybus/. Because this was 2 1/2 years of work, with
> > many many developers contributing, I didn't want to flatten all of their
> > effort into a few small patches, as that wouldn't be very fair. So I've
> > built a git tree with all of the changes going back to the first commit,
> > and merged it into the kernel tree, just like btrfs was merged into the
> > kernel.
>
> > Unless people point out some major problems with this, I'd like to get
> > it merged into 4.9-rc1.
>
> I'm extremely concerned that these patches have *never* seen upstream
> review, and this pull request gives no real opportunity for people to
> make a judgement regarding the code, as many relevant parties have not
> been Cc'd.
As I said, I will send a set of simple patches, I wanted to get this out
as soon as possible and other things came up today. Will do it in the
morning, sorry.
> From a quick scan of the git tree, I can see code (that isn't even
> placed under staging/) for which I have fundamental objections to as a
> maintainer, and has not been Cc'd to a relevant list.
>
> For example, I see commit 5a450477311fbfe2 ("greybus: timesync: Add
> timesync core driver"). This states that it directly accesses the ARMv7
> architected timer, though it's unclear as to precisely what it's doing
> since it introduces an (undocumented) compatible string, and what should
> be an unnecessary devicetree property.
>
> That's never gone to the linux-arm-kernel mainline list, myself or Marc
> (as maintainers of the arch timer driver), nor has the binding seen any
> review on the devicetree mailing list.
Hm, odd, I thought we had Rob review all of the device tree bindings,
but maybe the timesync stuff missed him. And timesync is "odd" to say
the least, wait until you see the firmware side of it :)
Let me post the patches tomorrow and then we can review them.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v26 2/7] arm64: kdump: implement machine_crash_shutdown()
From: James Morse @ 2016-09-14 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160907042908.6232-3-takahiro.akashi@linaro.org>
Hi Akashi,
(CC: Marc who knows how this irqchip wizardry works
Cover letter: https://www.spinics.net/lists/arm-kernel/msg529520.html )
On 07/09/16 05:29, AKASHI Takahiro wrote:
> Primary kernel calls machine_crash_shutdown() to shut down non-boot cpus
> and save registers' status in per-cpu ELF notes before starting crash
> dump kernel. See kernel_kexec().
> Even if not all secondary cpus have shut down, we do kdump anyway.
>
> As we don't have to make non-boot(crashed) cpus offline (to preserve
> correct status of cpus at crash dump) before shutting down, this patch
> also adds a variant of smp_send_stop().
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> ---
> arch/arm64/include/asm/hardirq.h | 2 +-
> arch/arm64/include/asm/kexec.h | 41 ++++++++++++++++++++++++-
> arch/arm64/include/asm/smp.h | 2 ++
> arch/arm64/kernel/machine_kexec.c | 56 ++++++++++++++++++++++++++++++++--
> arch/arm64/kernel/smp.c | 63 +++++++++++++++++++++++++++++++++++++++
> 5 files changed, 159 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/include/asm/hardirq.h b/arch/arm64/include/asm/hardirq.h
> index 8740297..1473fc2 100644
> --- a/arch/arm64/include/asm/hardirq.h
> +++ b/arch/arm64/include/asm/hardirq.h
> @@ -20,7 +20,7 @@
> #include <linux/threads.h>
> #include <asm/irq.h>
>
> -#define NR_IPI 6
> +#define NR_IPI 7
>
> typedef struct {
> unsigned int __softirq_pending;
> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> index 04744dc..a908958 100644
> --- a/arch/arm64/include/asm/kexec.h
> +++ b/arch/arm64/include/asm/kexec.h
> @@ -40,7 +40,46 @@
> static inline void crash_setup_regs(struct pt_regs *newregs,
> struct pt_regs *oldregs)
> {
> - /* Empty routine needed to avoid build errors. */
> + if (oldregs) {
> + memcpy(newregs, oldregs, sizeof(*newregs));
> + } else {
> + u64 tmp1, tmp2;
> +
> + __asm__ __volatile__ (
> + "stp x0, x1, [%2, #16 * 0]\n"
> + "stp x2, x3, [%2, #16 * 1]\n"
> + "stp x4, x5, [%2, #16 * 2]\n"
> + "stp x6, x7, [%2, #16 * 3]\n"
> + "stp x8, x9, [%2, #16 * 4]\n"
> + "stp x10, x11, [%2, #16 * 5]\n"
> + "stp x12, x13, [%2, #16 * 6]\n"
> + "stp x14, x15, [%2, #16 * 7]\n"
> + "stp x16, x17, [%2, #16 * 8]\n"
> + "stp x18, x19, [%2, #16 * 9]\n"
> + "stp x20, x21, [%2, #16 * 10]\n"
> + "stp x22, x23, [%2, #16 * 11]\n"
> + "stp x24, x25, [%2, #16 * 12]\n"
> + "stp x26, x27, [%2, #16 * 13]\n"
> + "stp x28, x29, [%2, #16 * 14]\n"
> + "mov %0, sp\n"
> + "stp x30, %0, [%2, #16 * 15]\n"
> +
> + "/* faked current PSTATE */\n"
> + "mrs %0, CurrentEL\n"
> + "mrs %1, DAIF\n"
> + "orr %0, %0, %1\n"
> + "mrs %1, NZCV\n"
> + "orr %0, %0, %1\n"
> +
What about SPSEL? While we don't use it, it is correctly preserved for
everything except a CPU that calls panic()...
> + /* pc */
> + "adr %1, 1f\n"
> + "1:\n"
> + "stp %1, %0, [%2, #16 * 16]\n"
> + : "=r" (tmp1), "=r" (tmp2), "+r" (newregs)
> + :
> + : "memory"
> + );
> + }
> }
>
> #endif /* __ASSEMBLY__ */
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index 0226447..6b0f2c7 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -136,6 +136,8 @@ static inline void cpu_panic_kernel(void)
> */
> bool cpus_are_stuck_in_kernel(void);
>
> +extern void smp_send_crash_stop(void);
> +
> #endif /* ifndef __ASSEMBLY__ */
>
> #endif /* ifndef __ASM_SMP_H */
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index bc96c8a..8ac9dba8 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -9,6 +9,9 @@
> * published by the Free Software Foundation.
> */
>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/kernel.h>
> #include <linux/kexec.h>
> #include <linux/smp.h>
>
> @@ -22,6 +25,7 @@
> extern const unsigned char arm64_relocate_new_kernel[];
> extern const unsigned long arm64_relocate_new_kernel_size;
>
> +bool in_crash_kexec;
static?
> static unsigned long kimage_start;
>
> /**
> @@ -148,7 +152,8 @@ void machine_kexec(struct kimage *kimage)
> /*
> * New cpus may have become stuck_in_kernel after we loaded the image.
> */
> - BUG_ON(cpus_are_stuck_in_kernel() || (num_online_cpus() > 1));
> + BUG_ON((cpus_are_stuck_in_kernel() || (num_online_cpus() > 1)) &&
> + !WARN_ON(in_crash_kexec));
In the kdump case, num_online_cpus() is unchanged as ipi_cpu_crash_stop()
doesn't update the online cpu masks, so this WARN_ON always fires. This is
confusing as the 'failed to stop secondary CPUs' message doesn't appear, because
those CPUs did stop, and waiting_for_crash_ipi has the expected value...
>
> reboot_code_buffer_phys = page_to_phys(kimage->control_code_page);
> reboot_code_buffer = phys_to_virt(reboot_code_buffer_phys);
> @@ -200,13 +205,58 @@ void machine_kexec(struct kimage *kimage)
> * relocation is complete.
> */
>
> - cpu_soft_restart(1, reboot_code_buffer_phys, kimage->head,
> + cpu_soft_restart(!in_crash_kexec, reboot_code_buffer_phys, kimage->head,
> kimage_start, 0);
>
> BUG(); /* Should never get here. */
> }
> +static void machine_kexec_mask_interrupts(void)
> +{
> + unsigned int i;
> + struct irq_desc *desc;
> +
> + for_each_irq_desc(i, desc) {
> + struct irq_chip *chip;
> + int ret;
> +
> + chip = irq_desc_get_chip(desc);
> + if (!chip)
> + continue;
> +
> + /*
> + * First try to remove the active state. If this
> + * fails, try to EOI the interrupt.
> + */
> + ret = irq_set_irqchip_state(i, IRQCHIP_STATE_ACTIVE, false);
> +
> + if (ret && irqd_irq_inprogress(&desc->irq_data) &&
> + chip->irq_eoi)
> + chip->irq_eoi(&desc->irq_data);
> +
> + if (chip->irq_mask)
> + chip->irq_mask(&desc->irq_data);
> +
> + if (chip->irq_disable && !irqd_irq_disabled(&desc->irq_data))
> + chip->irq_disable(&desc->irq_data);
> + }
> +}
This function is over my head ... I have no idea how this works, I can only
comment that its different to the version under arch/arm
/me adds Marc Z to CC.
> +/**
> + * machine_crash_shutdown - shutdown non-crashing cpus and save registers
> + */
> void machine_crash_shutdown(struct pt_regs *regs)
> {
> - /* Empty routine needed to avoid build errors. */
> + local_irq_disable();
> +
> + in_crash_kexec = true;
> +
> + /* shutdown non-crashing cpus */
> + smp_send_crash_stop();
> +
> + /* for crashing cpu */
> + crash_save_cpu(regs, smp_processor_id());
> + machine_kexec_mask_interrupts();
> +
> + pr_info("Starting crashdump kernel...\n");
> }
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index d93d433..b401b25 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -37,6 +37,7 @@
> #include <linux/completion.h>
> #include <linux/of.h>
> #include <linux/irq_work.h>
> +#include <linux/kexec.h>
>
> #include <asm/alternative.h>
> #include <asm/atomic.h>
> @@ -71,6 +72,7 @@ enum ipi_msg_type {
> IPI_RESCHEDULE,
> IPI_CALL_FUNC,
> IPI_CPU_STOP,
> + IPI_CPU_CRASH_STOP,
> IPI_TIMER,
> IPI_IRQ_WORK,
> IPI_WAKEUP
> @@ -734,6 +736,7 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
> S(IPI_RESCHEDULE, "Rescheduling interrupts"),
> S(IPI_CALL_FUNC, "Function call interrupts"),
> S(IPI_CPU_STOP, "CPU stop interrupts"),
> + S(IPI_CPU_CRASH_STOP, "CPU stop (for crash dump) interrupts"),
> S(IPI_TIMER, "Timer broadcast interrupts"),
> S(IPI_IRQ_WORK, "IRQ work interrupts"),
> S(IPI_WAKEUP, "CPU wake-up interrupts"),
> @@ -808,6 +811,29 @@ static void ipi_cpu_stop(unsigned int cpu)
> cpu_relax();
> }
>
> +#ifdef CONFIG_KEXEC_CORE
> +static atomic_t waiting_for_crash_ipi;
> +#endif
> +
> +static void ipi_cpu_crash_stop(unsigned int cpu, struct pt_regs *regs)
> +{
> +#ifdef CONFIG_KEXEC_CORE
> + crash_save_cpu(regs, cpu);
> +
> + atomic_dec(&waiting_for_crash_ipi);
> +
> + local_irq_disable();
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> + if (cpu_ops[cpu]->cpu_die)
> + cpu_ops[cpu]->cpu_die(cpu);
> +#endif
> +
> + /* just in case */
> + cpu_park_loop();
> +#endif
> +}
> +
> /*
> * Main handler for inter-processor interrupts
> */
> @@ -838,6 +864,15 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
> irq_exit();
> break;
>
> + case IPI_CPU_CRASH_STOP:
> + if (IS_ENABLED(CONFIG_KEXEC_CORE)) {
> + irq_enter();
> + ipi_cpu_crash_stop(cpu, regs);
> +
> + unreachable();
> + }
> + break;
> +
> #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
> case IPI_TIMER:
> irq_enter();
> @@ -910,6 +945,34 @@ void smp_send_stop(void)
> cpumask_pr_args(cpu_online_mask));
> }
>
> +#ifdef CONFIG_KEXEC_CORE
> +void smp_send_crash_stop(void)
> +{
> + cpumask_t mask;
> + unsigned long timeout;
> +
> + if (num_online_cpus() == 1)
> + return;
> +
> + cpumask_copy(&mask, cpu_online_mask);
> + cpumask_clear_cpu(smp_processor_id(), &mask);
> +
> + atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
> +
> + pr_crit("SMP: stopping secondary CPUs\n");
> + smp_cross_call(&mask, IPI_CPU_CRASH_STOP);
> +
> + /* Wait up to one second for other CPUs to stop */
> + timeout = USEC_PER_SEC;
> + while ((atomic_read(&waiting_for_crash_ipi) > 0) && timeout--)
> + udelay(1);
> +
> + if (atomic_read(&waiting_for_crash_ipi) > 0)
> + pr_warning("SMP: failed to stop secondary CPUs %*pbl\n",
> + cpumask_pr_args(cpu_online_mask));
> +}
> +#endif
This is very similar to smp_send_stop() which also has the timeout. Is it
possible to merge them? You could use in_crash_kexec to choose the IPI type.
> +
> /*
> * not supported here
> */
>
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
^ permalink raw reply
* [PATCH v2 1/6] usb: dwc2: add support for Meson8b and GXBB SoCs
From: John Youn @ 2016-09-14 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m24m5ixxyu.fsf@baylibre.com>
On 9/14/2016 9:11 AM, Kevin Hilman wrote:
> Hi John,
>
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>
>> From: Jerome Brunet <jbrunet@baylibre.com>
>>
>> Add compatible strings for amlogic Meson8b and GXBB SoCs with the
>> corresponding configuration parameters.
>>
>> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> Are you OK with adding this platform for v4.9? I know you mentioned
> you're working on new bindings to replace the current way, but since
> that hasn't been posted AFAICT, it would be nice to get this merged now
> and we can help test the new bindings when you're ready.
>
> If you're OK with that, and with your Ack, I can take merge the driver
> changes through the arm-soc tree along with the rest of the DT patches.
>
Sure. Unfortunately, I wasn't able to complete it for 4.9.
You can add my acked-by on this:
Acked-by: John Youn <johnyoun@synopsys.com>
Regards,
John
> Kevin
>
>> ---
>> Documentation/devicetree/bindings/usb/dwc2.txt | 2 ++
>> drivers/usb/dwc2/platform.c | 34 ++++++++++++++++++++++++++
>> 2 files changed, 36 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>> index 20a68bf..2c30a54 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>> @@ -10,6 +10,8 @@ Required properties:
>> - "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 Soc;
>> - "lantiq,arx100-usb": The DWC2 USB controller instance in Lantiq ARX SoCs;
>> - "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
>> + - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
>> + - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
>> - snps,dwc2: A generic DWC2 USB controller with default parameters.
>> - reg : Should contain 1 register range (address and length)
>> - interrupts : Should contain 1 interrupt
>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>> index fc6f525..8f7b34c 100644
>> --- a/drivers/usb/dwc2/platform.c
>> +++ b/drivers/usb/dwc2/platform.c
>> @@ -181,6 +181,38 @@ static const struct dwc2_core_params params_ltq = {
>> .hibernation = -1,
>> };
>>
>> +static const struct dwc2_core_params params_amlogic = {
>> + .otg_cap = DWC2_CAP_PARAM_NO_HNP_SRP_CAPABLE,
>> + .otg_ver = -1,
>> + .dma_enable = 1,
>> + .dma_desc_enable = 0,
>> + .dma_desc_fs_enable = 0,
>> + .speed = DWC2_SPEED_PARAM_HIGH,
>> + .enable_dynamic_fifo = 1,
>> + .en_multiple_tx_fifo = -1,
>> + .host_rx_fifo_size = 512,
>> + .host_nperio_tx_fifo_size = 500,
>> + .host_perio_tx_fifo_size = 500,
>> + .max_transfer_size = -1,
>> + .max_packet_count = -1,
>> + .host_channels = 16,
>> + .phy_type = DWC2_PHY_TYPE_PARAM_UTMI,
>> + .phy_utmi_width = -1,
>> + .phy_ulpi_ddr = -1,
>> + .phy_ulpi_ext_vbus = -1,
>> + .i2c_enable = -1,
>> + .ulpi_fs_ls = -1,
>> + .host_support_fs_ls_low_power = -1,
>> + .host_ls_low_power_phy_clk = -1,
>> + .ts_dline = -1,
>> + .reload_ctl = 1,
>> + .ahbcfg = GAHBCFG_HBSTLEN_INCR8 <<
>> + GAHBCFG_HBSTLEN_SHIFT,
>> + .uframe_sched = 0,
>> + .external_id_pin_ctl = -1,
>> + .hibernation = -1,
>> +};
>> +
>> /*
>> * Check the dr_mode against the module configuration and hardware
>> * capabilities.
>> @@ -464,6 +496,8 @@ static const struct of_device_id dwc2_of_match_table[] = {
>> { .compatible = "lantiq,xrx200-usb", .data = ¶ms_ltq },
>> { .compatible = "snps,dwc2", .data = NULL },
>> { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
>> + { .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
>> + { .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
>
^ permalink raw reply
* [GIT PULL] Allwinner clocks changes for 4.9
From: Stephen Boyd @ 2016-09-14 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160911202104.GA2491@lukather>
On 09/11, Maxime Ripard wrote:
> Hi,
>
> Here is the usual bunch of clock patches for the Allwinner SoCs, this
> time converting more SoCs to the new framework.
>
> Thanks!
> Maxime
>
> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>
> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-clk-for-4.9
>
> for you to fetch changes up to d63a5e7c713a68bd368016f2022326a1a91310d8:
>
> clk: sunxi-ng: Add hardware dependency (2016-09-10 11:41:21 +0200)
Thanks. Pulled.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH -next] meson: clk: Use builtin_platform_driver to simplify the code
From: Stephen Boyd @ 2016-09-14 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473508969-2776-1-git-send-email-weiyj.lk@gmail.com>
On 09/10, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Use the builtin_platform_driver() macro to make the code simpler.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] clk: meson: fix CLKID_GCLK_VENCI_INT typo
From: Stephen Boyd @ 2016-09-14 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160906130130.1645496-1-arnd@arndb.de>
On 09/06, Arnd Bergmann wrote:
> The addition of many gate clocks added two entries in an array for
> the same value:
>
> drivers/clk/meson/meson8b.c:479:10: error: initialized field overwritten [-Werror=override-init]
> [CLKID_GCLK_VENCI_INT] = &meson8b_gclk_venci_int.hw,
> [CLKID_GCLK_VENCI_INT] = &meson8b_gclk_vencp_int.hw,
>
> This was clearly an accident, and since all other identifiers are
> listed in the order in which they are defined, I'm changing the
> first one to CLKID_GCLK_VENCI_INT0, making it all consistent again.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: e31a1900c1ff ("meson: clk: Add support for clock gates")
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/6] usb: dwc2: add support for Meson8b and GXBB SoCs
From: Kevin Hilman @ 2016-09-14 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0d587b46-4c6e-c2ec-a62e-5d0c5a5bd902@synopsys.com>
On Wed, Sep 14, 2016 at 11:12 AM, John Youn <John.Youn@synopsys.com> wrote:
> On 9/14/2016 9:11 AM, Kevin Hilman wrote:
>> Hi John,
>>
>> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>>
>>> From: Jerome Brunet <jbrunet@baylibre.com>
>>>
>>> Add compatible strings for amlogic Meson8b and GXBB SoCs with the
>>> corresponding configuration parameters.
>>>
>>> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>>
>> Are you OK with adding this platform for v4.9? I know you mentioned
>> you're working on new bindings to replace the current way, but since
>> that hasn't been posted AFAICT, it would be nice to get this merged now
>> and we can help test the new bindings when you're ready.
>>
>> If you're OK with that, and with your Ack, I can take merge the driver
>> changes through the arm-soc tree along with the rest of the DT patches.
>>
>
> Sure. Unfortunately, I wasn't able to complete it for 4.9.
>
> You can add my acked-by on this:
>
> Acked-by: John Youn <johnyoun@synopsys.com>
Great, thanks! I assume you're OK with PATCH 2/2 for the bindings as
well (at least for now until you rework them?)
Kevin
^ 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