* [PATCH v2 0/2] ARM: sun8i: a83t: device tree cleanup
From: Maxime Ripard @ 2017-05-01 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501031408.10469-1-wens@csie.org>
On Mon, May 01, 2017 at 11:14:06AM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> Here's v2 of the A83T device tree cleanup patches. I dropped the change
> to the uart device node name for now.
>
> Also added a second patch changing the underscores in device node names
> I just added to hyphens. AFAIK that is the preferred naming scheme.
> Please squash it into "ARM: sun8i: a83t: Rename pinmux setting names".
Applied both, thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170501/c9f9feaa/attachment.sig>
^ permalink raw reply
* [GIT PULL] Mailbox changes for v4.12
From: Jassi Brar @ 2017-05-01 17:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit ad0376eb1483bd9880770b346f6592aece669e4c:
Merge tag 'edac_for_4.11_2' of
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp (2017-03-27
11:09:00 -0700)
are available in the git repository at:
https://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-for-next
for you to fetch changes up to cb710ab1d8a23f68ff8f45aedf3e552bb90e70de:
mailbox: handle empty message in tx_tick (2017-04-27 16:20:04 +0530)
----------------------------------------------------------------
- New driver for Broadcom FlexRM controller
- Constify data structures of callback functions in some drivers
- Few bug fixes uncovered by multi-threaded use of mailbox channels
in blocking mode.
----------------------------------------------------------------
Alexey Klimov (1):
mailbox: check ->last_tx_done for NULL in case of timer-based polling
Anup Patel (3):
mailbox: Add driver for Broadcom FlexRM ring manager
dt-bindings: Add DT bindings info for FlexRM ring manager
mailbox: Remove depends on COMPILE_TEST for BCM_FLEXRM_MBOX
Bhumika Goyal (1):
mailbox: constify mbox_chan_ops structures
Steve Lin (2):
mailbox: bcm-pdc: Add Northstar Plus support to PDC driver
dt-bindings: mailbox: Update doc with NSP PDC/mailbox support
Sudeep Holla (3):
mailbox: always wait in mbox_send_message for blocking Tx mode
mailbox: skip complete wait event if timer expired
mailbox: handle empty message in tx_tick
.../bindings/mailbox/brcm,iproc-flexrm-mbox.txt | 59 +
.../bindings/mailbox/brcm,iproc-pdc-mbox.txt | 6 +-
drivers/mailbox/Kconfig | 18 +-
drivers/mailbox/Makefile | 2 +
drivers/mailbox/bcm-flexrm-mailbox.c | 1595 ++++++++++++++++++++
drivers/mailbox/bcm-pdc-mailbox.c | 61 +-
drivers/mailbox/hi6220-mailbox.c | 2 +-
drivers/mailbox/mailbox-xgene-slimpro.c | 2 +-
drivers/mailbox/mailbox.c | 19 +-
include/linux/mailbox/brcm-message.h | 14 +-
10 files changed, 1746 insertions(+), 32 deletions(-)
create mode 100644
Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
create mode 100644 drivers/mailbox/bcm-flexrm-mailbox.c
^ permalink raw reply
* [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501155856.GA1957@Red>
> > > > Does the internal PHY have a phy driver? It seems like
> > > > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > > > should be in the phy driver, if it has one.
> > >
> > > Nope. These affect the delay lines for the external PHY interface.
>
> I will add some sentences in the documentation to be more clear about that.
Thanks
>
> >
> > Oh, yes. I understood the patch wrong.
> >
> > None of the patches actually use these properties. Are they actually
> > needed? We should avoid adding vendor specific properties, if they are
> > not used.
> >
>
> The board that use it is the BananaPi M3, but the SoC A83T still lack clocks support.
> So theses properties is already used out of tree, and will be used in tree soon.
Fair enough.
Thanks
Andrew
^ permalink raw reply
* [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
From: Jayachandran C @ 2017-05-01 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170428163823.GX13675@arm.com>
On Fri, Apr 28, 2017 at 05:38:23PM +0100, Will Deacon wrote:
> Hi guys,
>
> On Fri, Apr 28, 2017 at 01:46:24PM +0000, Jayachandran C wrote:
> > On Thu, Apr 27, 2017 at 06:37:59PM +0100, Will Deacon wrote:
> > > > If my understanding is correct, the sysfs suggestion above is going to
> > > > add API complexity without solving the issue. Ignoring the exclude_hv if
> > > > it cannot be honored would be a better solution.
> > >
> > > Better for HHVM, sure, but I don't think it's better in general. It means
> > > that we silently do the opposite of what the user has requested in some
> > > configurations.
> >
> > If my understanding is correct, when is_kernel_in_hyp_mode() is true,
> > the kernel is in EL2 and there is no real hypervisor with hvc calls
> > from kernel. Ignoring the exclude_hv would be correct.
> >
> > When kernel is in EL1, it would be correct to consider exclude_hv to
> > skip events in EL2 (reached with hvc).
> >
> > I don't see the issue, can you please give more detail on the config
> > with unexpected behavior?
>
> This got me thinking, so I tried to look at the history of exclude_hv. It
> turns out it was added in 0475f9ea8e2c ("perf_counters: allow users to
> count user, kernel and/or hypervisor events") for PowerPC, not x86 (where
> this doesn't seem to be supported).
>
> Notably, it looks like it's always ignored for the x86 CPU PMU, and ignored
> on PowerPC when a hypervisor is not present. I think that backs up your
> suggestion that we should ignore it when is_kernel_in_hyp_mode() is true.
>
> In which case, I withdraw my objection to ignoring exclude_hv when running
> in hyp mode, but please add a comment explaining the rationale!
Thanks, we will send out an updated patch with a commit message summarizing
this disucssion.
JC
^ permalink raw reply
* [PATCH v3 4/5] ARM: sun7i: Convert to CCU
From: Maxime Ripard @ 2017-05-01 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <560676328328d23f344468f5c43ff1b1533f36f0.1493235134.git-series.plaes@plaes.org>
Hi,
On Wed, Apr 26, 2017 at 10:32:24PM +0300, Priit Laes wrote:
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0-hdmi";
> - clocks = <&ahb_gates 36>, <&ahb_gates 43>,
> - <&ahb_gates 44>, <&de_be0_clk>,
> - <&tcon0_ch1_clk>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI0>,
> + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_DE_BE0>,
> + <&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_DE_BE0>,
> + <&ccu CLK_HDMI>;
In order to make merging those patches *much* easier, could you just
use the raw IDs (ie not the defines, but the numbers) for now?
And ideally, send a patch after 4.13-rc1 that will switch to the
defines.
Thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170501/22a331f8/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/5] clk: sunxi-ng: Add sun4i/sun7i CCU driver
From: Maxime Ripard @ 2017-05-01 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <528b9b3895e654b6d3cf95187433f9fb7b4eb50c.1493235134.git-series.plaes@plaes.org>
Hi Priit,
Almost good, thanks!
On Wed, Apr 26, 2017 at 10:32:21PM +0300, Priit Laes wrote:
> +/* TODO: GPS CLK 0x0d0 */
You should still create a define in the header for this one.
> +/* Following only exist on sun7i-a20 */
> +#define CLK_MBUS 165
> +#define CLK_HDMI1_SLOW 166
> +#define CLK_HDMI1 167
> +#define CLK_OUT_A 168
> +#define CLK_OUT_B 169
Wouldn't it be better to simply create a new A20-only header that
would include the A10's and add the A20 specific clocks on top?
Thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170501/f4c3ee78/attachment.sig>
^ permalink raw reply
* [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Corentin Labbe @ 2017-05-01 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501144541.GB1285@lunn.ch>
On Mon, May 01, 2017 at 04:45:41PM +0200, Andrew Lunn wrote:
> On Mon, May 01, 2017 at 10:28:46PM +0800, Chen-Yu Tsai wrote:
> > On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > > On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> > >> Hello
> > >>
> > >> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > >> present on Allwinner H3/H5/A83T/A64 SoCs.
> > >>
> > >> This driver is the continuation of the sun8i-emac driver.
> > >> During the development, it appeared that in fact the hardware was a modified
> > >> version of some dwmac.
> > >> So the driver is now written as a glue driver for stmmac.
> > >>
> > >> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> > >> It can use an internal PHY (MII 10/100) or an external PHY
> > >> via RGMII/RMII.
> > >
> > > Hi Corentin
> > >
> > > Sorry if this has been asked before....
> > >
> > > Does the internal PHY have a phy driver? It seems like
> > > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > > should be in the phy driver, if it has one.
> >
> > Nope. These affect the delay lines for the external PHY interface.
I will add some sentences in the documentation to be more clear about that.
>
> Oh, yes. I understood the patch wrong.
>
> None of the patches actually use these properties. Are they actually
> needed? We should avoid adding vendor specific properties, if they are
> not used.
>
The board that use it is the BananaPi M3, but the SoC A83T still lack clocks support.
So theses properties is already used out of tree, and will be used in tree soon.
Regards
^ permalink raw reply
* [PATCH 1/3] ARM: dts: rockchip: Move cros-ec-sbs to rk3288-veyron-chromebook-sbs
From: Doug Anderson @ 2017-05-01 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2337202.q9Cdx8Nyxy@phil>
Hi,
On Mon, May 1, 2017 at 7:07 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> Am Sonntag, 30. April 2017, 22:56:52 CEST schrieb Paul Kocialkowski:
>> Le dimanche 30 avril 2017 ? 22:37 +0200, Heiko Stuebner a ?crit :
>> > Hi Paul,
>> >
>> > Am Sonntag, 30. April 2017, 20:30:52 CEST schrieb Paul Kocialkowski:
>> > > This moves the cros-ec-sbs dtsi to a new rk3288-veyron-chromebook-sbs
>> > > dtsi since it only concerns rk3288 veyron Chromebooks.
>> > >
>> > > Other Chromebooks (such as the tegra124 nyans) also have sbs batteries
>> > > and don't use this dtsi, that only makes sense when used with
>> > > rk3288-veyron-chromebook anyway.
>> >
>> > That isn't true. The gru series (rk3399-based) also uses the
>> > sbs-battery [0]. And while it is currently limited to Rockchip-based
>> > Chromebooks it is nevertheless used on more than one platform, so
>> > the probability is high that it will be used in future series as well.
>>
>> That's good to know, but as pointed out, other cros devices are using a sbs
>> battery without this header, so such a generic name isn't really a good fit.
It would be interesting to know if the "retry-count" ought to be the
same across all Chromebooks. I guess you could argue that maybe
someone found it needed to be 10 in all "nyan" variants and needed to
be 1 in all "veyron" variants, but it seems more likely that the
difference is arbitrary, or that one of the two values would work for
everyone. It sure looks like we've just been copying values from
device to device. Given that all the "veyron" devices have vastly
different batteries (and probably all the nyan ones too), it seems
likely there ought to be one value.
In terms of setting the "charger", that also could potentially be
something that could be for all Chromebooks, or at least older ones
that don't have their charger implemented by the type C driver. ...or
nyan devices could simply have a line in their dts like:
&battery {
power-supplies = <&charger>;
};
>> Note that &charger has to be defined (after my subsequent patches), which it is
>> for devices that also include rk3288-veyron-chromebook, but not necessarily
>> others.
>>
>> Overall, I think having one -sbs dtsi file makes sense here because there is
>> already a rk3288-veyron-chromebook dtsi that veyron chromebooks use. That file
>> cannot contain the battery bindings because minnie has a different one and it
>> would be a bit silly to copy it over all devices. That definitely makes sense.
>>
>> As for other devices, I don't see why we should have a separate include file for
>> the battery instead of having it in the device's dts. I think this should be the
>> case on gru/kevin.
>>
>> Also maybe not *all* gru-based devices will turn out to use a SBS battery, so it
>> seems early to include this header in the gru dtsi.
For gru devices, we've moved to a "virtual sbs battery" provided by
the EC. I'm not 100% positive that everything will just magically
work and be converted in the EC if we put a non-sbs battery on a board
with this EC feature, but I would hope we'd convert everything
properly.
>> One last point, gru/kevin
>> currently don't define a charger, which will break my subsequent patch (that is
>> however needed for the veyrons that use this file).
Arguably this should be fixed. On veyron-chromebook we just use
"gpio-charger". We didn't add a special charger driver w/ a property
like "ti,external-control" since the only piece of information that
Linux really needed from the charger was whether or not AC was
connected.
>> To me, it seems that there's little advantage and major drawbacks in keeping
>> this file the way it is.
>
> I don't have any set opinion right now but after looking through the
> other uses of the sbs-battery the cros-ec-sbs.dtsi snippet really seems
> somewhat veyron/gru-specific - especially wrt. the retry-count values.
>
> What I'm not sure about is whether it is actually better to keep the include
> around under a new name or just move the (rather tiny) sbs-battery node
> into the relevant devicetrees directly, when there aren't that many users
> anyway.
I'm fine with whatever you guys choose to do here. It's nice not to
have copied "code", but with device tree sometimes copies are cleaner
than trying to share something.
-Doug
^ permalink raw reply
* [PATCH 0/9] [v3] arm64: defconfig: enable several options useful for ARM64 server platforms
From: Timur Tabi @ 2017-05-01 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493413563-18375-1-git-send-email-timur@codeaurora.org>
On 04/28/2017 04:05 PM, Timur Tabi wrote:
> Timur Tabi (9):
> [v3] arm64: defconfig: resynchronize the defconfig
> arm64: defconfig: enable ACPI_CPPC_CPUFREQ
> arm64: defconfig: enable BLK_DEV_NVME
> [v2] arm64: defconfig: enable EFI_CAPSULE_LOADER
> arm64: defconfig: enable support for PCIe hotplug
> arm64: defconfig: enable APEI and GHES features
> [v2] arm64: defconfig: enable EDAC options
> arm64: defconfig: enable QCOM_L2_PMU and QCOM_L3_PMU
> arm64: defconfig: enable the Qualcomm Technologies EMAC Ethernet
> driver
Catalin,
Any chance of getting these into 4.12?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt @ 2017-05-01 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170430.224852.172293736555378453.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Eric Anholt <eric@anholt.net>
> Date: Fri, 28 Apr 2017 15:22:03 -0700
>
>> Cygnus is a small family of SoCs, of which we currently have
>> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
>> same as 58xx, just requiring a tiny bit of setup that was previously
>> missing.
>>
>> v2: Reorder the entry in the docs (suggestion by Scott Branden), add
>> missing '"'
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> The second patch with the DTS file update doesn't apply cleanly
> at all to net-next.
>
> So I'm dropping this series.
DTS updates go through arm-soc branches through Florian. The first
patch is the one I would like you to apply.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170501/bc8cb0ef/attachment.sig>
^ permalink raw reply
* [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67qGqswdz_JcDaD5jTkcvtBuzqqP8KZh=S_5pkp=o6cUQ@mail.gmail.com>
On Mon, May 01, 2017 at 10:28:46PM +0800, Chen-Yu Tsai wrote:
> On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> >> Hello
> >>
> >> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> >> present on Allwinner H3/H5/A83T/A64 SoCs.
> >>
> >> This driver is the continuation of the sun8i-emac driver.
> >> During the development, it appeared that in fact the hardware was a modified
> >> version of some dwmac.
> >> So the driver is now written as a glue driver for stmmac.
> >>
> >> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> >> It can use an internal PHY (MII 10/100) or an external PHY
> >> via RGMII/RMII.
> >
> > Hi Corentin
> >
> > Sorry if this has been asked before....
> >
> > Does the internal PHY have a phy driver? It seems like
> > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > should be in the phy driver, if it has one.
>
> Nope. These affect the delay lines for the external PHY interface.
Oh, yes. I understood the patch wrong.
None of the patches actually use these properties. Are they actually
needed? We should avoid adding vendor specific properties, if they are
not used.
Andrew
^ permalink raw reply
* [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Chen-Yu Tsai @ 2017-05-01 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501140133.GD31281@lunn.ch>
On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
>> Hello
>>
>> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
>> present on Allwinner H3/H5/A83T/A64 SoCs.
>>
>> This driver is the continuation of the sun8i-emac driver.
>> During the development, it appeared that in fact the hardware was a modified
>> version of some dwmac.
>> So the driver is now written as a glue driver for stmmac.
>>
>> It supports 10/100/1000 Mbit/s speed with half/full duplex.
>> It can use an internal PHY (MII 10/100) or an external PHY
>> via RGMII/RMII.
>
> Hi Corentin
>
> Sorry if this has been asked before....
>
> Does the internal PHY have a phy driver? It seems like
> tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> should be in the phy driver, if it has one.
Nope. These affect the delay lines for the external PHY interface.
These have existed since the A20, when the GMAC hardware block and
glue layer controls were introduced.
ChenYu
^ permalink raw reply
* [PATCH 1/3] ARM: dts: rockchip: Move cros-ec-sbs to rk3288-veyron-chromebook-sbs
From: Heiko Stuebner @ 2017-05-01 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493585812.6493.4.camel@paulk.fr>
Am Sonntag, 30. April 2017, 22:56:52 CEST schrieb Paul Kocialkowski:
> Le dimanche 30 avril 2017 ? 22:37 +0200, Heiko Stuebner a ?crit :
> > Hi Paul,
> >
> > Am Sonntag, 30. April 2017, 20:30:52 CEST schrieb Paul Kocialkowski:
> > > This moves the cros-ec-sbs dtsi to a new rk3288-veyron-chromebook-sbs
> > > dtsi since it only concerns rk3288 veyron Chromebooks.
> > >
> > > Other Chromebooks (such as the tegra124 nyans) also have sbs batteries
> > > and don't use this dtsi, that only makes sense when used with
> > > rk3288-veyron-chromebook anyway.
> >
> > That isn't true. The gru series (rk3399-based) also uses the
> > sbs-battery [0]. And while it is currently limited to Rockchip-based
> > Chromebooks it is nevertheless used on more than one platform, so
> > the probability is high that it will be used in future series as well.
>
> That's good to know, but as pointed out, other cros devices are using a sbs
> battery without this header, so such a generic name isn't really a good fit.
>
> Note that &charger has to be defined (after my subsequent patches), which it is
> for devices that also include rk3288-veyron-chromebook, but not necessarily
> others.
>
> Overall, I think having one -sbs dtsi file makes sense here because there is
> already a rk3288-veyron-chromebook dtsi that veyron chromebooks use. That file
> cannot contain the battery bindings because minnie has a different one and it
> would be a bit silly to copy it over all devices. That definitely makes sense.
>
> As for other devices, I don't see why we should have a separate include file for
> the battery instead of having it in the device's dts. I think this should be the
> case on gru/kevin.
>
> Also maybe not *all* gru-based devices will turn out to use a SBS battery, so it
> seems early to include this header in the gru dtsi. One last point, gru/kevin
> currently don't define a charger, which will break my subsequent patch (that is
> however needed for the veyrons that use this file).
>
> To me, it seems that there's little advantage and major drawbacks in keeping
> this file the way it is.
I don't have any set opinion right now but after looking through the
other uses of the sbs-battery the cros-ec-sbs.dtsi snippet really seems
somewhat veyron/gru-specific - especially wrt. the retry-count values.
What I'm not sure about is whether it is actually better to keep the include
around under a new name or just move the (rather tiny) sbs-battery node
into the relevant devicetrees directly, when there aren't that many users
anyway.
Heiko
>
> > Also, it might be nice to also include some Chromeos people (there should
> > be some in the git logs, like Brian who submitted the Gru patches), as they
> > might be able to provide more detailed input.
>
> That's a good point, thanks for including them.
>
> >
> > Heiko
> >
> > [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/a
> > rch/arm64/boot/dts/rockchip/rk3399-gru.dtsi#n886
> >
> > >
> > > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> > > ---
> > > .../boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-sbs.dtsi} | 0
> > > arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2
> > > +-
> > > arch/arm/boot/dts/rk3288-veyron-jerry.dts | 2
> > > +-
> > > arch/arm/boot/dts/rk3288-veyron-pinky.dts | 2
> > > +-
> > > arch/arm/boot/dts/rk3288-veyron-speedy.dts | 2
> > > +-
> > > 5 files changed, 4 insertions(+), 4 deletions(-)
> > > rename arch/arm/boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-
> > > sbs.dtsi} (100%)
> > >
> > > diff --git a/arch/arm/boot/dts/cros-ec-sbs.dtsi b/arch/arm/boot/dts/rk3288-
> > > veyron-chromebook-sbs.dtsi
> > > similarity index 100%
> > > rename from arch/arm/boot/dts/cros-ec-sbs.dtsi
> > > rename to arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
> > > diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > > b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > > index d33f5763c39c..f217a978e47a 100644
> > > --- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > > +++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > > @@ -45,7 +45,7 @@
> > > /dts-v1/;
> > >
> > > #include "rk3288-veyron-chromebook.dtsi"
> > > -#include "cros-ec-sbs.dtsi"
> > > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> > >
> > > / {
> > > model = "Google Jaq";
> > > diff --git a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > > b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > > index cdea751f2a8c..bec607574165 100644
> > > --- a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > > +++ b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > > @@ -44,7 +44,7 @@
> > >
> > > /dts-v1/;
> > > #include "rk3288-veyron-chromebook.dtsi"
> > > -#include "cros-ec-sbs.dtsi"
> > > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> > >
> > > / {
> > > model = "Google Jerry";
> > > diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > > b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > > index 995cff42fa43..c81ad5bf1121 100644
> > > --- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > > +++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > > @@ -44,7 +44,7 @@
> > >
> > > /dts-v1/;
> > > #include "rk3288-veyron-chromebook.dtsi"
> > > -#include "cros-ec-sbs.dtsi"
> > > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> > >
> > > / {
> > > model = "Google Pinky";
> > > diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > > b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > > index cc0b78cefe34..8aea9c3ff6e2 100644
> > > --- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > > +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > > @@ -44,7 +44,7 @@
> > >
> > > /dts-v1/;
> > > #include "rk3288-veyron-chromebook.dtsi"
> > > -#include "cros-ec-sbs.dtsi"
> > > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> > >
> > > / {
> > > model = "Google Speedy";
> > >
> >
> >
>
^ permalink raw reply
* [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> Hello
>
> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> present on Allwinner H3/H5/A83T/A64 SoCs.
>
> This driver is the continuation of the sun8i-emac driver.
> During the development, it appeared that in fact the hardware was a modified
> version of some dwmac.
> So the driver is now written as a glue driver for stmmac.
>
> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> It can use an internal PHY (MII 10/100) or an external PHY
> via RGMII/RMII.
Hi Corentin
Sorry if this has been asked before....
Does the internal PHY have a phy driver? It seems like
tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
should be in the phy driver, if it has one.
Andrew
^ permalink raw reply
* [PATCH v5 03/20] dt-bindings: net: Add DT bindings documentation for Allwinner dwmac-sun8i
From: Andrew Lunn @ 2017-05-01 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-4-clabbe.montjoie@gmail.com>
On Mon, May 01, 2017 at 02:45:03PM +0200, Corentin Labbe wrote:
> +emac: ethernet at 1c0b000 {
> + compatible = "allwinner,sun8i-h3-emac";
> + syscon = <&syscon>;
> + reg = <0x01c0b000 0x104>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "macirq";
> + resets = <&ccu RST_BUS_EMAC>;
> + reset-names = "stmmaceth";
> + clocks = <&ccu CLK_BUS_EMAC>;
> + clock-names = "stmmaceth";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + phy = <&int_mii_phy>;
Hi Corentin
Should this be phy-handle?
Andrew
^ permalink raw reply
* [PATCH v5 20/20] arm64: defconfig: Enable dwmac-sun8i driver on defconfig
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
Enable the dwmac-sun8i ethernet driver as a module in the ARM64 defconfig.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ce07285..4575fbb 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -193,6 +193,7 @@ CONFIG_RAVB=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=m
+CONFIG_DWMAC_SUN8I=m
CONFIG_REALTEK_PHY=m
CONFIG_MESON_GXL_PHY=m
CONFIG_MICREL_PHY=y
--
2.10.2
^ permalink raw reply related
* [PATCH v5 19/20] arm: multi_v7: Enable dwmac-sun8i driver on multi_v7_defconfig
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
Enable the dwmac-sun8i driver in the multi_v7 default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2685e03..6da6af8 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -257,6 +257,7 @@ CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_PLATFORM=y
CONFIG_DWMAC_DWC_QOS_ETH=y
+CONFIG_DWMAC_SUN8I=y
CONFIG_TI_CPSW=y
CONFIG_XILINX_EMACLITE=y
CONFIG_AT803X_PHY=y
--
2.10.2
^ permalink raw reply related
* [PATCH v5 18/20] arm: sunxi: Enable dwmac-sun8i driver on sunxi_defconfig
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
Enable the dwmac-sun8i driver in the sunxi default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 5cd5dd70..504e022 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -40,6 +40,7 @@ CONFIG_ATA=y
CONFIG_AHCI_SUNXI=y
CONFIG_NETDEVICES=y
CONFIG_SUN4I_EMAC=y
+CONFIG_DWMAC_SUN8I=y
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
--
2.10.2
^ permalink raw reply related
* [PATCH v5 17/20] arm64: allwinner: bananapi-m64: Enable dwmac-sun8i
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the BananaPi M64.
It uses an external PHY rtl8211e via RGMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 6872135..0d1f026 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -67,6 +67,14 @@
};
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ status = "okay";
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -77,6 +85,13 @@
bias-pull-up;
};
+&mdio {
+ ext_rgmii_phy: ethernet-phy at 1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.10.2
^ permalink raw reply related
* [PATCH v5 16/20] arm64: allwinner: pine64-plus: Enable dwmac-sun8i
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the pine64 plus.
It uses an external PHY rtl8211e via RGMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
.../arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
index 790d14d..24f1aac 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -46,5 +46,20 @@
model = "Pine64+";
compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
- /* TODO: Camera, Ethernet PHY, touchscreen, etc. */
+ /* TODO: Camera, touchscreen, etc. */
+};
+
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ status = "okay";
+};
+
+&mdio {
+ ext_rgmii_phy: ethernet-phy at 1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
};
--
2.10.2
^ permalink raw reply related
* [PATCH v5 15/20] arm64: allwinner: pine64: Enable dwmac-sun8i
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the pine64
It uses an external PHY via RMII.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index c680ed3..3b491c0 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -70,6 +70,15 @@
status = "okay";
};
+&emac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rmii_pins>;
+ phy-mode = "rmii";
+ phy-handle = <&ext_rmii_phy1>;
+ status = "okay";
+
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -80,6 +89,13 @@
bias-pull-up;
};
+&mdio {
+ ext_rmii_phy1: ethernet-phy at 1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
--
2.10.2
^ permalink raw reply related
* [PATCH v5 14/20] arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit
connections. It is very similar to the device found in the Allwinner
H3, but lacks the internal 100 Mbit PHY and its associated control
bits.
This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps
it disabled at this level.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 35 +++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index d7341ba..18b3642 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -287,6 +287,21 @@
bias-pull-up;
};
+ rmii_pins: rmii_pins {
+ pins = "PD10", "PD11", "PD13", "PD14", "PD17",
+ "PD18", "PD19", "PD20", "PD22", "PD23";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
+ rgmii_pins: rgmii_pins {
+ pins = "PD8", "PD9", "PD10", "PD11", "PD12",
+ "PD13", "PD15", "PD16", "PD17", "PD18",
+ "PD19", "PD20", "PD21", "PD22", "PD23";
+ function = "emac";
+ drive-strength = <40>;
+ };
+
uart0_pins_a: uart0 at 0 {
pins = "PB8", "PB9";
function = "uart0";
@@ -391,6 +406,26 @@
#size-cells = <0>;
};
+ emac: ethernet at 1c30000 {
+ compatible = "allwinner,sun50i-a64-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x100>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
gic: interrupt-controller at 1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
2.10.2
^ permalink raw reply related
* [PATCH v5 13/20] arm64: allwinner: sun50i-a64: Add dt node for the syscon control module
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
This patch add the dt node for the syscon register present on the
Allwinner A64.
Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index c7f669f..d7341ba 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -129,6 +129,12 @@
#size-cells = <1>;
ranges;
+ syscon: syscon at 1c00000 {
+ compatible = "allwinner,sun50i-a64-system-controller",
+ "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
mmc0: mmc at 1c0f000 {
compatible = "allwinner,sun50i-a64-mmc";
reg = <0x01c0f000 0x1000>;
--
2.10.2
^ permalink raw reply related
* [PATCH v5 12/20] arm: sun8i: orangepi-pc-plus: Set EMAC activity LEDs to active high
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
On the Orange Pi PC Plus, the polarity of the LEDs on the RJ45 Ethernet
port were changed from active low to active high.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
index 8b93f5c..a10281b 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts
@@ -53,6 +53,11 @@
};
};
+&emac {
+ /* LEDs changed to active high on the plus */
+ /delete-property/ allwinner,leds-active-low;
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins_a>;
--
2.10.2
^ permalink raw reply related
* [PATCH v5 11/20] arm: sun8i: orangepi-2: Enable dwmac-sun8i
From: Corentin Labbe @ 2017-05-01 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Orange PI 2.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index 5b6d145..cedd326 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -54,6 +54,7 @@
aliases {
serial0 = &uart0;
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet0 = &emac;
ethernet1 = &rtl8189;
};
@@ -108,6 +109,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
--
2.10.2
^ permalink raw reply related
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