* Synopsys Ethernet QoS Driver
From: Giuseppe CAVALLARO @ 2016-11-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <48776f8b-4e06-1456-1b52-3ea08a22b2a4@synopsys.com>
On 11/21/2016 4:00 PM, Joao Pinto wrote:
> On 21-11-2016 14:36, Giuseppe CAVALLARO wrote:
>> Hello Joao
>>
>> On 11/21/2016 2:48 PM, Joao Pinto wrote:
>>> Synopsys QoS IP is a separated hardware component, so it should be reusable by
>>> all implementations using it and so have its own "core driver" and platform +
>>> pci glue drivers. This is necessary for example in hardware validation, where
>>> you prototype an IP and instantiate its drivers and test it.
>>>
>>> Was there a strong reason to integrate QoS features directly in stmmac and not
>>> in synopsys/dwc_eth_qos.*?
>>
>> We decided to enhance the stmmac on supporting the QoS for several
>> reasons; for example the common APIs that the driver already exposed and
>> actually suitable for other SYNP chips. Then, PTP, EEE,
>> S/RGMII, MMC could be shared among different chips with a minimal
>> effort. This meant a lot of code already ready.
>>
>> For sure, the net-core, Ethtool, mdio parts were reused. Same for the
>> glue logic files.
>> For the latter, this helped to easily bring-up new platforms also
>> because the stmmac uses the HW cap register to auto-configure many
>> parts of the MAC core, DMA and modules. This helped many users, AFAIK.
>>
>> For validation purpose, this is my experience, the stmmac helped
>> a lot because people used the same code to validate different HW
>> and it was easy to switch to a platform to another one in order to
>> verify / check if the support was ok or if a regression was introduced.
>> This is important for complex supports like PTP or EEE.
>>
>> Hoping this can help.
>>
>> Do not hesitate to contact me for further details
>
> Thanks for the highly detailed info.
> My target application is to prototype the Ethernet QoS IP in a FPGA, with a PHY
> attached and make hardware validation.
>
> In your opinion a refactored stmmac with the missing QoS features would be
> suitable for it?
I think so; somebody also added code for FPGA.
In any case, step-by-step we can explore and understand
how to proceed. I wonder if you could start looking at the internal
of the stmmac. Then welcome doubts and open question...
>
> Thanks.
welcome
peppe
>
>>
>> peppe
>
>
^ permalink raw reply
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Ryan Harkin @ 2016-11-21 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108174622.GW1041@n2100.armlinux.org.uk>
On 8 November 2016 at 17:46, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>>
>>
>> On 08/11/16 16:06, Russell King - ARM Linux wrote:
>> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> >>As it contains a zero sized Image and .dtb files, I tried copying my
>> >>Image and .dtb over, and also copied my original config.txt (only
>> >>change is AUTORUN: FALSE). It still doesn't appear to boot beyond
>> >>this point.
>> >
>> >Well, it seems that I can't even go back to my original set of firmware
>> >as UEFI has stopped working:
>> >
>> >NOTICE: Booting Trusted Firmware
>> >NOTICE: BL1: v1.0(release):14b6608
>> >NOTICE: BL1: Built : 14:15:51, Sep 1 2014
>> >NOTICE: BL1: Booting BL2
>> >NOTICE: BL2: v1.0(release):14b6608
>> >NOTICE: BL2: Built : 14:15:51, Sep 1 2014
>> >NOTICE: BL1: Booting BL3-1
>> >NOTICE: BL3-1: v1.0(release):14b6608
>> >NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
>> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
>> >Warning: Fail to load FDT file 'juno.dtb'.
>> >
>>
>> This again because of incompatibility of the configuration data saved in
>> NOR flash. The erase command I gave early is to erase that when you
>> switched between the UEFI binaries. It's really horrible mess UEFI
>> created in the initial days of Juno, and hopefully they have moved to
>> some standard format these days.
>
> Yea, what it means is I've no possibility to go back to what was
> originally working now, since I don't understand how to get UEFI to
> behave (Will set the machine up for me, I don't have any information
> on how it was originally configured other than what was on the uSD
> card, which appears incomplete.)
>
>> >and UEFI is the most unfriendly thing going - the "boot manager" thing
>> >doesn't let you view the configuration:
>> >
>>
>> I completely agree. I had real bad times in past dealing with such
>> things in UEFI.
>>
>> >[1] Linux from NOR Flash
>> >[2] Shell
>> >[3] Boot Manager
>> >Start: 3
>> >[1] Add Boot Device Entry
>> >[2] Update Boot Device Entry
>> >[3] Remove Boot Device Entry
>> >[4] Reorder Boot Device Entries
>> >[5] Update FDT path
>> >[6] Set Boot Timeout
>> >[7] Return to main menu
>> >Choice:
>> >
>> >and dropping into the shell... well, I've no idea how to get a listing
>> >of what it thinks is in the NOR device (or even how to refer to the
>> >NOR device.) "devices" shows nothing that's even remotely English.
>> >
Using UEFI is painful enough on Juno. Using a 2 year old version with
"that" menu system is even worse.
So I'll just pitch in here and recommend you switch to using u-boot.
Then you can see your config with "printenv" and you'll probably
understand it too.
The board will boot my prebuilt kernel/DTB using u-boot if you erase
the uSD card and unzip this firmware image to it:
http://releases.linaro.org/members/arm/platforms/16.10/juno-latest-oe-uboot.zip
Then you can copy over your own kernel & DTB for your own testing,
configure u-boot for TFTP, or whatever you like.
Switching to u-boot won't solve any thermal sensor calibration problems.
>>
>> I think startup.nsh needs some edits. Just replace it with something like:
>>
>> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
>> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
>> alike. Currently it just echos and stops.
>>
>> Regarding the new firmware stopping abruptly, I have no clue, except
>> asking you to erase the flash completely when switching between the
>> firmware versions. That has worked for me for all UEFI related issues in
>> the past. It's really annoying I understand.
>>
>> flash> eraseall
>
> I've tried that, it still stops at the same point, after:
>
> FV2 Hob 0xFE07B000 - 0xFE8253BF
>
> and remains unresponsive.
>
> I do notice that the uSD card becomes visible through USB at this point
> though.
>
> Okay, well, I'm going to have to disable Juno from the nightly boots
> until we get some kind of resolution on this, as my Juno is now
> incapable of booting anything.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-21 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ffd3b27c-0bc9-b53b-cc65-c7808595a553@st.com>
On 21-11-2016 14:25, Giuseppe CAVALLARO wrote:
> On 11/21/2016 2:28 PM, Lars Persson wrote:
>>
>>
>>> 21 nov. 2016 kl. 13:53 skrev Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>>>
>>> Hello Joao
>>>
>>>> On 11/21/2016 1:32 PM, Joao Pinto wrote:
>>>> Hello,
>>>>
>>>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a
>>>>>>> single file
>>>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and
>>>>>>> platform
>>>>>>> related stuff.
>>>>>>>
>>>>>>> Our strategy would be:
>>>>>>>
>>>>>>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>>>>>>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>>>>>>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have
>>>>>>> Ethernet QoS
>>>>>>> related stuff to be reused by the platform / pci drivers
>>>>>>> d) Add a set of features to the "core driver" that we have available
>>>>>>> internally
>>>>>>
>>>>>> Note that there are actually two drivers in mainline for this hardware:
>>>>>>
>>>>>> drivers/net/ethernet/synopsis/
>>>>>> drivers/net/ethernet/stmicro/stmmac/
>>>>>
>>>>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>>>>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>>>>> please refer this driver once before you start.
>>>>>
>>>>> You can start adding missing feature of 4.x in stmmac driver.
>>>>
>>>> Thanks you all for all the info.
>>>> Well, I think we are in a good position to organize the ethernet drivers
>>>> concerning Synopsys IPs.
>>>>
>>>> First of all, in my opinion, it does not make sense to have a ethernet/synopsis
>>>> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
>>>> vendor using the same IP it should be able to reuse the commonn operations. But
>>>> I would put that discussion for later :)
>>>>
>>>> For now I suggest that for we create ethernet/qos and create there a folder
>>>> called dwc (designware controller) where all the synopsys qos IP specific code
>>>> in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
>>>> figure out a clean interface for "client drivers" like stmmac to interact with
>>>> the new qos driver.
>>>>
>>>> What do you think about this approach?
>>>
>>> The stmmac drivers run since many years on several platforms
>>> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
>>> configurations starting from 3.1x to 3.7x databooks.
>>>
>>> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
>>> are fully working.
>>>
>>> Also the stmmac has platform, device-tree and pcie supports and
>>> a lot of maintained glue-logic files.
>>>
>>> It is fully documented inside the kernel tree.
>>>
>>> I am happy to have new enhancements from other developers.
>>> So, on my side, if you want to spend your time on improving it on your
>>> platforms please feel free to do it!
>>>
>>> Concerning the stmicro/stmmac naming, these come from a really old
>>> story and have no issue to adopt new folder/file names.
>>>
>>> I am also open to merge fixes and changes from ethernet/synopsis.
>>> I want to point you on some benchmarks made by Alex some months ago
>>> (IIRC) that showed an stmmac winner (due to the several optimizations
>>> analyzed and reviewed in this mailing list).
>>>
>>> Peppe
>>>
>>
>> Hello Joao and others,
>>
Hi Lars,
>> As the maintainer of dwc_eth_qos.c I prefer also that we put efforts on the
>> most mature driver, the stmmac.
>>
>> I hope that the code can migrate into an ethernet/synopsys folder to keep the
>> convention of naming the folder after the vendor. This makes it easy for
>> others to find the driver.
>>
>> The dwc_eth_qos.c will eventually be removed and its DT binding interface can
>> then be implemented in the stmmac driver.
So your ideia is to pick the ethernet/stmmac and rename it to ethernet/synopsys
and try to improve the structure and add the missing QoS features to it?
>
> Thanks Lars, I will be happy to support all you on this transition
> and I agree on renaming all.
>
> peppe
>
>
>> - Lars
>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> (See http://lists.openwall.net/netdev/2016/02/29/127)
>>>>>>
>>>>>> The former only supports 4.x of the hardware.
>>>>>>
>>>>>> The later supports 4.x and 3.x and already has a platform glue driver
>>>>>> with support for several platforms, a PCI glue driver, and a core driver
>>>>>> with several features not present in the former (for example: TX/RX
>>>>>> interrupt coalescing, EEE, PTP).
>>>>>>
>>>>>> Have you evaluated both drivers? Why have you decided to work on the
>>>>>> former rather than the latter?
>>>>>
>>>>>
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Sudeep Holla @ 2016-11-21 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD0U-hK982V+kUArjVSG7pTs5CLpNsgJaC5t8aPg8XuoiMRU0A@mail.gmail.com>
On 21/11/16 15:04, Ryan Harkin wrote:
[...]
> Switching to u-boot won't solve any thermal sensor calibration problems.
>
Indeed. The board Russell had was one of those early ones which was not
calibrated properly. He is now able to use the 16.10 release after
calibration.
--
Regards,
Sudeep
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-21 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7318c77e-3011-03f3-e673-54e3bb0554aa@st.com>
On 21-11-2016 15:03, Giuseppe CAVALLARO wrote:
> On 11/21/2016 4:00 PM, Joao Pinto wrote:
>> On 21-11-2016 14:36, Giuseppe CAVALLARO wrote:
>>> Hello Joao
>>>
>>> On 11/21/2016 2:48 PM, Joao Pinto wrote:
>>>> Synopsys QoS IP is a separated hardware component, so it should be reusable by
>>>> all implementations using it and so have its own "core driver" and platform +
>>>> pci glue drivers. This is necessary for example in hardware validation, where
>>>> you prototype an IP and instantiate its drivers and test it.
>>>>
>>>> Was there a strong reason to integrate QoS features directly in stmmac and not
>>>> in synopsys/dwc_eth_qos.*?
>>>
>>> We decided to enhance the stmmac on supporting the QoS for several
>>> reasons; for example the common APIs that the driver already exposed and
>>> actually suitable for other SYNP chips. Then, PTP, EEE,
>>> S/RGMII, MMC could be shared among different chips with a minimal
>>> effort. This meant a lot of code already ready.
>>>
>>> For sure, the net-core, Ethtool, mdio parts were reused. Same for the
>>> glue logic files.
>>> For the latter, this helped to easily bring-up new platforms also
>>> because the stmmac uses the HW cap register to auto-configure many
>>> parts of the MAC core, DMA and modules. This helped many users, AFAIK.
>>>
>>> For validation purpose, this is my experience, the stmmac helped
>>> a lot because people used the same code to validate different HW
>>> and it was easy to switch to a platform to another one in order to
>>> verify / check if the support was ok or if a regression was introduced.
>>> This is important for complex supports like PTP or EEE.
>>>
>>> Hoping this can help.
>>>
>>> Do not hesitate to contact me for further details
>>
>> Thanks for the highly detailed info.
>> My target application is to prototype the Ethernet QoS IP in a FPGA, with a PHY
>> attached and make hardware validation.
>>
>> In your opinion a refactored stmmac with the missing QoS features would be
>> suitable for it?
>
> I think so; somebody also added code for FPGA.
>
> In any case, step-by-step we can explore and understand
> how to proceed. I wonder if you could start looking at the internal
> of the stmmac. Then welcome doubts and open question...
Yes I am going to do that thanks... taking my first steps in this IP :)
>
>>
>> Thanks.
>
> welcome
>
> peppe
>
>>
>>>
>>> peppe
>>
>>
>
^ permalink raw reply
* spin_lock behavior with ARM64 big.Little/HMP
From: Sudeep Holla @ 2016-11-21 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f9fc9549d801fece7422d97d5d89df8b@codeaurora.org>
On 18/11/16 20:22, Vikram Mulukutla wrote:
>
> Hi Sudeep,
>
> Thanks for taking a look!
>
> On 2016-11-18 02:30, Sudeep Holla wrote:
>> Hi Vikram,
>>
>> On 18/11/16 02:22, Vikram Mulukutla wrote:
>>> Hello,
>>>
>>> This isn't really a bug report, but just a description of a
>>> frequency/IPC
>>> dependent behavior that I'm curious if we should worry about. The
>>> behavior
>>> is exposed by questionable design so I'm leaning towards don't-care.
>>>
>>> Consider these threads running in parallel on two ARM64 CPUs running
>>> mainline
>>> Linux:
>>>
>>
>> Are you seeing this behavior with the mainline kernel on any platforms
>> as we have a sort of workaround for this ?
>>
>
> If I understand that workaround correctly, the ARM timer event stream is
> used
> to periodically wake up CPUs that are waiting in WFE, is that right? I
> think
> my scenario below may be different because LittleCPU doesn't actually wait
> on a WFE event in the loop that is trying to increment lock->next, i.e.
> it's
> stuck in the following loop:
>
> ARM64_LSE_ATOMIC_INSN(
> /* LL/SC */
> " prfm pstl1strm, %3\n"
> "1: ldaxr %w0, %3\n"
> " add %w1, %w0, %w5\n"
> " stxr %w2, %w1, %3\n"
> " cbnz %w2, 1b\n",
>
Interesting. Just curious if this is r0p0/p1 A53 ? If so, is the errata
819472 enabled ?
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: fine-tune L2 cache configuration
From: Dinh Nguyen @ 2016-11-21 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118185218.16653-1-marex@denx.de>
Hi Marek,
On 11/18/2016 12:52 PM, Marek Vasut wrote:
> Enable double-linefill and increase prefetch offset, which gives
> considerable read performance boost. The following numbers were
> obtained using lmbench 3.0 bw_mem tool, for easier comparison, the
> numbers are pasted in two columns. The test machine has Cyclone V
> SoC running at 800MHz MPU clock and 512MiB 333MHz 16bit DDR3 DRAM.
>
> Without patch | With patch
> $ for i in rd wr rdwr cp fwr frd fcp bzero bcopy ; do echo $i ; bw_mem 64M $i ; done
> rd | rd
> 64.00 526.46 | 64.00 1151.06
> wr | wr
> 64.00 329.95 | 64.00 346.14
> rdwr | rdwr
> 64.00 342.07 | 64.00 367.24
> cp | cp
> 64.00 239.79 | 64.00 322.47
> fwr | fwr
> 64.00 1027.90 | 64.00 1025.38
> frd | frd
> 64.00 322.36 | 64.00 641.89
> fcp | fcp
> 64.00 256.99 | 64.00 408.41
> bzero | bzero
> 64.00 1028.43 | 64.00 1025.07
> bcopy | bcopy
> 64.00 294.73 | 64.00 357.19
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Applied!
Thanks,
Dinh
^ permalink raw reply
* [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: linux-arm-kernel
This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
Initially reported as a low Tx throughput issue at gigabit speed, the
platform enters LPI too often. This eventually break the link (both Tx
and Rx), and require to bring the interface down and up again to get the
Rx path working again.
The root cause of this issue is not fully understood yet but disabling EEE
advertisement on the PHY prevent this feature to be negotiated.
With this change, the link is stable and reliable, with the expected
throughput performance.
The patchset adds options in the generic phy driver to disable EEE
advertisement, through device tree. The way it is done is very similar
to the handling of the max-speed property.
This V2 is posted is posted as an RFC. Since it changes the generic PHY
it propably requires to be a bit more careful.
If you are not confortable taking for the coming rc, I can rebase on
net-next instead.
Chnages since V1: [1]
- Disable the advertisement of EEE in the generic code instead of the
realtek driver.
[1] : http://lkml.kernel.org/r/1479220154-25851-1-git-send-email-jbrunet at baylibre.com
Jerome Brunet (3):
net: phy: add an option to disable EEE advertisement
dt: bindings: add ethernet phy eee-disable-advert option documentation
ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
Documentation/devicetree/bindings/net/phy.txt | 5 ++
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 ++++
drivers/net/phy/phy.c | 3 +
drivers/net/phy/phy_device.c | 80 +++++++++++++++++++---
include/linux/phy.h | 3 +
5 files changed, 97 insertions(+), 9 deletions(-)
--
2.7.4
^ permalink raw reply
* [RFC PATCH net v2 1/3] net: phy: add an option to disable EEE advertisement
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479742524-30222-1-git-send-email-jbrunet@baylibre.com>
This patch adds an option to disable EEE advertisement in the generic PHY
by providing a mask of prohibited modes corresponding to the value found in
the MDIO_AN_EEE_ADV register.
On some platforms, PHY Low power idle seems to be causing issues, even
breaking the link some cases. The patch provides a convenient way for these
platforms to disable EEE advertisement and work around the issue.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/net/phy/phy.c | 3 ++
drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
include/linux/phy.h | 3 ++
3 files changed, 77 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index f424b867f73e..a44ee14bd953 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1348,6 +1348,9 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
{
int val = ethtool_adv_to_mmd_eee_adv_t(data->advertised);
+ /* Mask prohibited EEE modes */
+ val &= ~phydev->eee_advert_disabled;
+
phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, val);
return 0;
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1a4bf8acad78..74c628e046cb 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1116,6 +1116,43 @@ static int genphy_config_advert(struct phy_device *phydev)
}
/**
+ * genphy_config_eee_advert - disable unwanted eee mode advertisement
+ * @phydev: target phy_device struct
+ *
+ * Description: Writes MDIO_AN_EEE_ADV after disabling unsupported energy
+ * efficent ethernet modes. Returns 0 if the PHY's advertisement hasn't
+ * changed, and 1 if it has changed.
+ */
+static int genphy_config_eee_advert(struct phy_device *phydev)
+{
+ u32 disabled = phydev->eee_advert_disabled;
+ u32 old_adv, adv;
+
+ /* Nothing to disable */
+ if (!disabled)
+ return 0;
+
+ /* If the following call fails, we assume that EEE is not
+ * supported by the phy. If we read 0, EEE is not advertised
+ * In both case, we don't need to continue
+ */
+ adv = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN);
+ if (adv <= 0)
+ return 0;
+
+ old_adv = adv;
+ adv &= ~disabled;
+
+ /* Advertising remains unchanged with the ban */
+ if (old_adv == adv)
+ return 0;
+
+ phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, adv);
+
+ return 1;
+}
+
+/**
* genphy_setup_forced - configures/forces speed/duplex from @phydev
* @phydev: target phy_device struct
*
@@ -1173,15 +1210,20 @@ EXPORT_SYMBOL(genphy_restart_aneg);
*/
int genphy_config_aneg(struct phy_device *phydev)
{
- int result;
+ int err, changed;
+
+ changed = genphy_config_eee_advert(phydev);
if (AUTONEG_ENABLE != phydev->autoneg)
return genphy_setup_forced(phydev);
- result = genphy_config_advert(phydev);
- if (result < 0) /* error */
- return result;
- if (result == 0) {
+ err = genphy_config_advert(phydev);
+ if (err < 0) /* error */
+ return err;
+
+ changed |= err;
+
+ if (changed == 0) {
/* Advertisement hasn't changed, but maybe aneg was never on to
* begin with? Or maybe phy was isolated?
*/
@@ -1191,16 +1233,16 @@ int genphy_config_aneg(struct phy_device *phydev)
return ctl;
if (!(ctl & BMCR_ANENABLE) || (ctl & BMCR_ISOLATE))
- result = 1; /* do restart aneg */
+ changed = 1; /* do restart aneg */
}
/* Only restart aneg if we are advertising something different
* than we were before.
*/
- if (result > 0)
- result = genphy_restart_aneg(phydev);
+ if (changed > 0)
+ return genphy_restart_aneg(phydev);
- return result;
+ return 0;
}
EXPORT_SYMBOL(genphy_config_aneg);
@@ -1558,6 +1600,21 @@ static void of_set_phy_supported(struct phy_device *phydev)
__set_phy_supported(phydev, max_speed);
}
+static void of_set_phy_eee_disable(struct phy_device *phydev)
+{
+ struct device_node *node = phydev->mdio.dev.of_node;
+ u32 disabled;
+
+ if (!IS_ENABLED(CONFIG_OF_MDIO))
+ return;
+
+ if (!node)
+ return;
+
+ if (!of_property_read_u32(node, "eee-advert-disable", &disabled))
+ phydev->eee_advert_disabled = disabled;
+}
+
/**
* phy_probe - probe and init a PHY device
* @dev: device to probe and init
@@ -1595,6 +1652,11 @@ static int phy_probe(struct device *dev)
of_set_phy_supported(phydev);
phydev->advertising = phydev->supported;
+ /* Get the EEE modes we want to prohibit. We will ask
+ * the PHY stop advertising these mode later on
+ */
+ of_set_phy_eee_disable(phydev);
+
/* Set the state to READY by default */
phydev->state = PHY_READY;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index e25f1830fbcf..7f2ea0af16d1 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -401,6 +401,9 @@ struct phy_device {
u32 advertising;
u32 lp_advertising;
+ /* Energy efficient ethernet modes which should be prohibited */
+ u32 eee_advert_disabled;
+
int autoneg;
int link_timeout;
--
2.7.4
^ permalink raw reply related
* [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479742524-30222-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Documentation/devicetree/bindings/net/phy.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index bc1c3c8bf8fa..7f066b7c1e2c 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -35,6 +35,11 @@ Optional Properties:
- broken-turn-around: If set, indicates the PHY device does not correctly
release the turn around line low at the end of a MDIO transaction.
+- eee-advert-disable: Bits to clear in the MDIO_AN_EEE_ADV register to
+ disable EEE modes. Example
+ * 0x4: disable EEE for 1000T,
+ * 0x6: disable EEE for 100TX and 1000T
+
Example:
ethernet-phy at 0 {
--
2.7.4
^ permalink raw reply related
* [RFC PATCH net v2 3/3] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479742524-30222-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index e6e3491d48a5..b34da077b2f8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -98,3 +98,18 @@
pinctrl-0 = <&i2c_a_pins>;
pinctrl-names = "default";
};
+
+ðmac {
+ phy-handle = <ð_phy0>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy at 0 {
+ reg = <0>;
+ eee-advert-disable = <0x4>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: da850-lcdk: fix mmc card detect polarity
From: Axel Haslam @ 2016-11-21 15:41 UTC (permalink / raw)
To: linux-arm-kernel
The polarity of the card detect pin is inverted.
Change it to reflect the right polarity for the board
which is ACTIVE_LOW.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..07bb40f4 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -122,7 +122,7 @@
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
- cd-gpios = <&gpio 64 GPIO_ACTIVE_HIGH>;
+ cd-gpios = <&gpio 64 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
2.9.3
^ permalink raw reply related
* Synopsys Ethernet QoS Driver
From: Lars Persson @ 2016-11-21 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b126021d-e902-7a53-4d7a-e73ea89a66cf@synopsys.com>
> 21 nov. 2016 kl. 16:06 skrev Joao Pinto <Joao.Pinto@synopsys.com>:
>
>> On 21-11-2016 14:25, Giuseppe CAVALLARO wrote:
>>> On 11/21/2016 2:28 PM, Lars Persson wrote:
>>>
>>>
>>>> 21 nov. 2016 kl. 13:53 skrev Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>>>>
>>>> Hello Joao
>>>>
>>>>> On 11/21/2016 1:32 PM, Joao Pinto wrote:
>>>>> Hello,
>>>>>
>>>>>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>>>>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>>>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a
>>>>>>>> single file
>>>>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and
>>>>>>>> platform
>>>>>>>> related stuff.
>>>>>>>>
>>>>>>>> Our strategy would be:
>>>>>>>>
>>>>>>>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>>>>>>>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>>>>>>>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have
>>>>>>>> Ethernet QoS
>>>>>>>> related stuff to be reused by the platform / pci drivers
>>>>>>>> d) Add a set of features to the "core driver" that we have available
>>>>>>>> internally
>>>>>>>
>>>>>>> Note that there are actually two drivers in mainline for this hardware:
>>>>>>>
>>>>>>> drivers/net/ethernet/synopsis/
>>>>>>> drivers/net/ethernet/stmicro/stmmac/
>>>>>>
>>>>>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>>>>>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>>>>>> please refer this driver once before you start.
>>>>>>
>>>>>> You can start adding missing feature of 4.x in stmmac driver.
>>>>>
>>>>> Thanks you all for all the info.
>>>>> Well, I think we are in a good position to organize the ethernet drivers
>>>>> concerning Synopsys IPs.
>>>>>
>>>>> First of all, in my opinion, it does not make sense to have a ethernet/synopsis
>>>>> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
>>>>> vendor using the same IP it should be able to reuse the commonn operations. But
>>>>> I would put that discussion for later :)
>>>>>
>>>>> For now I suggest that for we create ethernet/qos and create there a folder
>>>>> called dwc (designware controller) where all the synopsys qos IP specific code
>>>>> in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
>>>>> figure out a clean interface for "client drivers" like stmmac to interact with
>>>>> the new qos driver.
>>>>>
>>>>> What do you think about this approach?
>>>>
>>>> The stmmac drivers run since many years on several platforms
>>>> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
>>>> configurations starting from 3.1x to 3.7x databooks.
>>>>
>>>> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
>>>> are fully working.
>>>>
>>>> Also the stmmac has platform, device-tree and pcie supports and
>>>> a lot of maintained glue-logic files.
>>>>
>>>> It is fully documented inside the kernel tree.
>>>>
>>>> I am happy to have new enhancements from other developers.
>>>> So, on my side, if you want to spend your time on improving it on your
>>>> platforms please feel free to do it!
>>>>
>>>> Concerning the stmicro/stmmac naming, these come from a really old
>>>> story and have no issue to adopt new folder/file names.
>>>>
>>>> I am also open to merge fixes and changes from ethernet/synopsis.
>>>> I want to point you on some benchmarks made by Alex some months ago
>>>> (IIRC) that showed an stmmac winner (due to the several optimizations
>>>> analyzed and reviewed in this mailing list).
>>>>
>>>> Peppe
>>>>
>>>
>>> Hello Joao and others,
>>>
>
> Hi Lars,
>
>>> As the maintainer of dwc_eth_qos.c I prefer also that we put efforts on the
>>> most mature driver, the stmmac.
>>>
>>> I hope that the code can migrate into an ethernet/synopsys folder to keep the
>>> convention of naming the folder after the vendor. This makes it easy for
>>> others to find the driver.
>>>
>>> The dwc_eth_qos.c will eventually be removed and its DT binding interface can
>>> then be implemented in the stmmac driver.
>
> So your ideia is to pick the ethernet/stmmac and rename it to ethernet/synopsys
> and try to improve the structure and add the missing QoS features to it?
Indeed this is what I prefer.
>
>>
>> Thanks Lars, I will be happy to support all you on this transition
>> and I agree on renaming all.
>>
>> peppe
>>
>>
>>> - Lars
>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> (See http://lists.openwall.net/netdev/2016/02/29/127)
>>>>>>>
>>>>>>> The former only supports 4.x of the hardware.
>>>>>>>
>>>>>>> The later supports 4.x and 3.x and already has a platform glue driver
>>>>>>> with support for several platforms, a PCI glue driver, and a core driver
>>>>>>> with several features not present in the former (for example: TX/RX
>>>>>>> interrupt coalescing, EEE, PTP).
>>>>>>>
>>>>>>> Have you evaluated both drivers? Why have you decided to work on the
>>>>>>> former rather than the latter?
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* [RFC PATCH v2 4/8] arm64: compat: Add a 32-bit vDSO
From: Kevin Brodsky @ 2016-11-21 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104200321.li3gzztg6p6xkwuh@localhost>
On 04/11/16 20:03, Catalin Marinas wrote:
> On Fri, Oct 28, 2016 at 11:20:07AM +0100, Kevin Brodsky wrote:
>> On 28/10/16 04:09, Jisheng Zhang wrote:
>>> On Thu, 27 Oct 2016 17:30:54 +0100 Kevin Brodsky wrote:
>>>> Provide the files necessary for building a compat (AArch32) vDSO in
>>>> kernel/vdso32.
>>>>
>>>> This is mostly an adaptation of the arm vDSO. The most significant
>>>> change in vgettimeofday.c is the use of the arm64 vdso_data struct,
>>>> allowing the vDSO data page to be shared between the 32 and 64-bit
>>>> vDSOs.
>>>>
>>>> In addition to the time functions, sigreturn trampolines are also
>>>> provided, aiming at replacing those in the vector page. To improve
>>>> debugging, CFI and unwinding directives are used, based on glibc's
>>>> implementation. Symbol offsets are made available to the kernel using
>>>> the same method as the 64-bit vDSO.
>>>>
>>>> There is unfortunately an important caveat to all this: we cannot get
>>>> away with hand-coding 32-bit instructions like in kernel/kuser32.S,
>>>> this time we really need a 32-bit compiler. The compat vDSO Makefile
>>>> relies on CROSS_COMPILE_ARM32 to provide a 32-bit compiler,
>>>> appropriate logic will be added to the arm64 Makefile later on to
>>>> ensure that an attempt to build the compat vDSO is made only if this
>>>> variable has been set properly.
>>>>
>>>> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
>>>> ---
>>>> arch/arm64/kernel/vdso32/Makefile | 121 +++++++++++++
>>>> arch/arm64/kernel/vdso32/sigreturn.S | 86 +++++++++
>>>> arch/arm64/kernel/vdso32/vdso.S | 32 ++++
>>>> arch/arm64/kernel/vdso32/vdso.lds.S | 98 +++++++++++
>>>> arch/arm64/kernel/vdso32/vgettimeofday.c | 294 +++++++++++++++++++++++++++++++
>>>> 5 files changed, 631 insertions(+)
>>>> create mode 100644 arch/arm64/kernel/vdso32/Makefile
>>>> create mode 100644 arch/arm64/kernel/vdso32/sigreturn.S
>>>> create mode 100644 arch/arm64/kernel/vdso32/vdso.S
>>>> create mode 100644 arch/arm64/kernel/vdso32/vdso.lds.S
>>>> create mode 100644 arch/arm64/kernel/vdso32/vgettimeofday.c
>>>>
>>>> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
>>>> new file mode 100644
>>>> index 000000000000..38facc870f6e
>>>> --- /dev/null
>>>> +++ b/arch/arm64/kernel/vdso32/Makefile
>>>> @@ -0,0 +1,121 @@
>>>> +#
>>>> +# Building a vDSO image for AArch32.
>>>> +#
>>>> +# Author: Kevin Brodsky <kevin.brodsky@arm.com>
>>>> +# A mix between the arm64 and arm vDSO Makefiles.
>>>> +
>>>> +CC_ARM32 := $(CROSS_COMPILE_ARM32)gcc
>>>> +
>>>> +# Same as cc-ldoption, but using CC_ARM32 instead of CC
>>>> +cc32-ldoption = $(call try-run,\
>>>> + $(CC_ARM32) $(1) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
>>>> +
>>>> +# Borrow vdsomunge.c from the arm vDSO
>>>> +munge := arch/arm/vdso/vdsomunge
>>>> +hostprogs-y := $(srctree)/$(munge)
>>>> +
>>>> +c-obj-vdso := vgettimeofday.o
>>>> +asm-obj-vdso := sigreturn.o
>>>> +
>>>> +# Build rules
>>>> +targets := $(c-obj-vdso) $(asm-obj-vdso) vdso.so vdso.so.dbg vdso.so.raw
>>>> +c-obj-vdso := $(addprefix $(obj)/, $(c-obj-vdso))
>>>> +asm-obj-vdso := $(addprefix $(obj)/, $(asm-obj-vdso))
>>>> +obj-vdso := $(c-obj-vdso) $(asm-obj-vdso)
>>>> +
>>>> +ccflags-y := -fPIC -fno-common -fno-builtin -fno-stack-protector
>>>> +ccflags-y += -DDISABLE_BRANCH_PROFILING
>>>> +
>>>> +# Force -O2 to avoid libgcc dependencies
>>>> +VDSO_CFLAGS := -march=armv8-a -O2
>>> For completeness, bringing 32bit compiler need to check whether the 32bit
>>> toolchain support some options. IIRC, armv8-a support isn't enabled until
>>> gcc 4.8, so old toolchains such gcc-4.7 will complain:
>>> error: unrecognized argument in option ?-march=armv8-a?
>> That's a fair point. I guess -march=armv8-a is not strictly necessary and
>> the produced vDSO should be fine if arch/arm/vdso also compiles fine.
>> However we would still need to pass -march=armv7-a. I'm not sure what to do
>> between:
>> * Checking that the compiler supports -march=armv8-a when inspecting
>> CROSS_COMPILE_ARM32, and if it doesn't vdso32 will not be built.
>> * Checking whether -march=armv8-a is available here, and if it is not fall
>> back to -march=armv7-a.
> Does v8 vs v7 make any difference in the generated code? If not, we
> could just stick to armv7-a permanently.
I've just tried compiling with -march=armv7-a, and in fact it doesn't compile at all.
It turns out vgettimeofday.c uses smp_rmb(), which expands to dmb ishld on arm64, and
ishld doesn't exist in ARMv7. We could possibly work around that, but I think
requiring GCC 4.8 is reasonable.
Thanks,
Kevin
^ permalink raw reply
* [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Andrew Lunn @ 2016-11-21 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479742524-30222-3-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 21, 2016 at 04:35:23PM +0100, Jerome Brunet wrote:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index bc1c3c8bf8fa..7f066b7c1e2c 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -35,6 +35,11 @@ Optional Properties:
> - broken-turn-around: If set, indicates the PHY device does not correctly
> release the turn around line low at the end of a MDIO transaction.
>
> +- eee-advert-disable: Bits to clear in the MDIO_AN_EEE_ADV register to
> + disable EEE modes. Example
> + * 0x4: disable EEE for 1000T,
> + * 0x6: disable EEE for 100TX and 1000T
> +
Hi Jerome
I like the direction this patchset is taking. But hex values are
pretty unfriendly. Please add a set of boolean properties, and do the
mapping to hex in the C code.
That would also make extending this API easier. e.g. say you have a
10Gbps PHY with EEE, and you need to disable it. This hex value
quickly gets ugly, eee-advert-disable-10000 is nice and simple.
Andrew
^ permalink raw reply
* [PATCH v5] arm64: dts: qcom: Add msm8916 CoreSight components
From: Georgi Djakov @ 2016-11-21 16:03 UTC (permalink / raw)
To: linux-arm-kernel
From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
Add initial set of CoreSight components found on Qualcomm msm8916 and
apq8016 based platforms, including the DragonBoard 410c board.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
---
Changes since v4: (https://lkml.org/lkml/2016/11/17/533)
* Move everything into the SoC dtsi file as suggested by Stephen Boyd.
* Updated commit message.
* Got Ack from Mathieu.
Changes since v3: (https://lkml.org/lkml/2015/5/11/134)
* Include msm8916-coresight.dtsi into msm8916.dtsi
Changes since v2: (https://lkml.org/lkml/2015/4/29/242)
* Added "1x" to "qcom,coresight-replicator" compatible string, to match what
devicetree bindings documentations says.
arch/arm64/boot/dts/qcom/msm8916.dtsi | 241 ++++++++++++++++++++++++++++++++++
1 file changed, 241 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 4221b7d2c0ce..464f2740e512 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -14,6 +14,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8916.h>
#include <dt-bindings/reset/qcom,gcc-msm8916.h>
+#include <dt-bindings/clock/qcom,rpmcc.h>
/ {
model = "Qualcomm Technologies, Inc. MSM8916";
@@ -853,6 +854,246 @@
memory-region = <&mpss_mem>;
};
};
+
+ tpiu at 820000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0x820000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ port {
+ tpiu_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out1>;
+ };
+ };
+ };
+
+ funnel at 821000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0x821000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * Not described input ports:
+ * 0 - connected to Resource and Power Manger CPU ETM
+ * 1 - not-connected
+ * 2 - connected to Modem CPU ETM
+ * 3 - not-connected
+ * 5 - not-connected
+ * 6 - connected trought funnel to Wireless CPU ETM
+ * 7 - connected to STM component
+ */
+
+ port at 4 {
+ reg = <4>;
+ funnel0_in4: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel1_out>;
+ };
+ };
+ port at 8 {
+ reg = <0>;
+ funnel0_out: endpoint {
+ remote-endpoint = <&etf_in>;
+ };
+ };
+ };
+ };
+
+ replicator at 824000 {
+ compatible = "qcom,coresight-replicator1x", "arm,primecell";
+ reg = <0x824000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ replicator_out0: endpoint {
+ remote-endpoint = <&etr_in>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ replicator_out1: endpoint {
+ remote-endpoint = <&tpiu_in>;
+ };
+ };
+ port at 2 {
+ reg = <0>;
+ replicator_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf_out>;
+ };
+ };
+ };
+ };
+
+ etf at 825000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0x825000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ etf_out: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel0_out>;
+ };
+ };
+ port at 1 {
+ reg = <0>;
+ etf_in: endpoint {
+ remote-endpoint = <&replicator_in>;
+ };
+ };
+ };
+ };
+
+ etr at 826000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0x826000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ port {
+ etr_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out0>;
+ };
+ };
+ };
+
+ funnel at 841000 { /* APSS funnel only 4 inputs are used */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0x841000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ funnel1_in0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm0_out>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ funnel1_in1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm1_out>;
+ };
+ };
+ port at 2 {
+ reg = <2>;
+ funnel1_in2: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm2_out>;
+ };
+ };
+ port at 3 {
+ reg = <3>;
+ funnel1_in3: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm3_out>;
+ };
+ };
+ port at 4 {
+ reg = <0>;
+ funnel1_out: endpoint {
+ remote-endpoint = <&funnel0_in4>;
+ };
+ };
+ };
+ };
+
+ etm at 85c000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85c000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU0>;
+
+ port {
+ etm0_out: endpoint {
+ remote-endpoint = <&funnel1_in0>;
+ };
+ };
+ };
+
+ etm at 85d000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85d000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU1>;
+
+ port {
+ etm1_out: endpoint {
+ remote-endpoint = <&funnel1_in1>;
+ };
+ };
+ };
+
+ etm at 85e000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85e000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU2>;
+
+ port {
+ etm2_out: endpoint {
+ remote-endpoint = <&funnel1_in2>;
+ };
+ };
+ };
+
+ etm at 85f000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85f000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU3>;
+
+ port {
+ etm3_out: endpoint {
+ remote-endpoint = <&funnel1_in3>;
+ };
+ };
+ };
};
smd {
^ permalink raw reply related
* [PATCH v2] ARM: dts: qcom: Add apq8064 CoreSight components
From: Georgi Djakov @ 2016-11-21 16:04 UTC (permalink / raw)
To: linux-arm-kernel
From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
Add initial set of CoreSight components found on Qualcomm apq8064 based
platforms, including the IFC6410 board.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
---
Changes since v1 (https://lkml.org/lkml/2016/11/17/474)
* Moved everything into the SoC dtsi file as suggested by Stephen Boyd.
* Updated commit message.
* Got Ack from Mathieu.
arch/arm/boot/dts/qcom-apq8064.dtsi | 191 +++++++++++++++++++++++++++++++++++-
1 file changed, 187 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 268bd470c865..2e8dd5d098f3 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -4,6 +4,7 @@
#include <dt-bindings/clock/qcom,gcc-msm8960.h>
#include <dt-bindings/reset/qcom,gcc-msm8960.h>
#include <dt-bindings/clock/qcom,mmcc-msm8960.h>
+#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/soc/qcom,gsbi.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -27,7 +28,7 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu at 0 {
+ CPU0: cpu at 0 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -38,7 +39,7 @@
cpu-idle-states = <&CPU_SPC>;
};
- cpu at 1 {
+ CPU1: cpu at 1 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -49,7 +50,7 @@
cpu-idle-states = <&CPU_SPC>;
};
- cpu at 2 {
+ CPU2: cpu at 2 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -60,7 +61,7 @@
cpu-idle-states = <&CPU_SPC>;
};
- cpu at 3 {
+ CPU3: cpu at 3 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -1416,6 +1417,187 @@
};
};
};
+
+ etb at 1a01000 {
+ compatible = "coresight-etb10", "arm,primecell";
+ reg = <0x1a01000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ port {
+ etb_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out0>;
+ };
+ };
+ };
+
+ tpiu at 1a03000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0x1a03000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ port {
+ tpiu_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out1>;
+ };
+ };
+ };
+
+ replicator {
+ compatible = "arm,coresight-replicator";
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ replicator_out0: endpoint {
+ remote-endpoint = <&etb_in>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ replicator_out1: endpoint {
+ remote-endpoint = <&tpiu_in>;
+ };
+ };
+ port at 2 {
+ reg = <0>;
+ replicator_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel_out>;
+ };
+ };
+ };
+ };
+
+ funnel at 1a04000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0x1a04000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * Not described input ports:
+ * 2 - connected to STM component
+ * 3 - not-connected
+ * 6 - not-connected
+ * 7 - not-connected
+ */
+ port at 0 {
+ reg = <0>;
+ funnel_in0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm0_out>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ funnel_in1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm1_out>;
+ };
+ };
+ port at 4 {
+ reg = <4>;
+ funnel_in4: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm2_out>;
+ };
+ };
+ port at 5 {
+ reg = <5>;
+ funnel_in5: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm3_out>;
+ };
+ };
+ port at 8 {
+ reg = <0>;
+ funnel_out: endpoint {
+ remote-endpoint = <&replicator_in>;
+ };
+ };
+ };
+ };
+
+ etm at 1a1c000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1c000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU0>;
+
+ port {
+ etm0_out: endpoint {
+ remote-endpoint = <&funnel_in0>;
+ };
+ };
+ };
+
+ etm at 1a1d000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1d000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU1>;
+
+ port {
+ etm1_out: endpoint {
+ remote-endpoint = <&funnel_in1>;
+ };
+ };
+ };
+
+ etm at 1a1e000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1e000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU2>;
+
+ port {
+ etm2_out: endpoint {
+ remote-endpoint = <&funnel_in4>;
+ };
+ };
+ };
+
+ etm at 1a1f000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1f000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU3>;
+
+ port {
+ etm3_out: endpoint {
+ remote-endpoint = <&funnel_in5>;
+ };
+ };
+ };
};
};
#include "qcom-apq8064-pins.dtsi"
^ permalink raw reply related
* [PATCH 1/2] ARM: mm: fix set_memory_*() bounds checks
From: Russell King @ 2016-11-21 16:08 UTC (permalink / raw)
To: linux-arm-kernel
The set_memory_*() bounds checks are buggy on several fronts:
1. They fail to round the region size up if the passed address is not
page aligned.
2. The region check was incomplete, and didn't correspond with what
was being asked of apply_to_page_range()
So, rework change_memory_common() to fix these problems, adding an
"in_region()" helper to determine whether the start & size fit within
the provided region start and stop addresses.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/mm/pageattr.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mm/pageattr.c b/arch/arm/mm/pageattr.c
index d19b1ad29b07..db09f2e7efda 100644
--- a/arch/arm/mm/pageattr.c
+++ b/arch/arm/mm/pageattr.c
@@ -34,28 +34,28 @@ static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long addr,
return 0;
}
+static bool in_range(unsigned long start, unsigned long size,
+ unsigned long range_start, unsigned long range_end)
+{
+ return start >= range_start && start < range_end &&
+ size <= range_end - start;
+}
+
static int change_memory_common(unsigned long addr, int numpages,
pgprot_t set_mask, pgprot_t clear_mask)
{
- unsigned long start = addr;
- unsigned long size = PAGE_SIZE*numpages;
- unsigned long end = start + size;
+ unsigned long start = addr & PAGE_SIZE;
+ unsigned long end = PAGE_ALIGN(addr) + numpages * PAGE_SIZE;
+ unsigned long size = end - start;
int ret;
struct page_change_data data;
- if (!IS_ALIGNED(addr, PAGE_SIZE)) {
- start &= PAGE_MASK;
- end = start + size;
- WARN_ON_ONCE(1);
- }
+ WARN_ON_ONCE(start != addr);
- if (!numpages)
+ if (!size)
return 0;
- if (start < MODULES_VADDR || start >= MODULES_END)
- return -EINVAL;
-
- if (end < MODULES_VADDR || start >= MODULES_END)
+ if (!in_range(start, size, MODULES_VADDR, MODULES_END))
return -EINVAL;
data.set_mask = set_mask;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: mm: allow set_memory_*() to be used on the vmalloc region
From: Russell King @ 2016-11-21 16:08 UTC (permalink / raw)
To: linux-arm-kernel
We can allow modules to be loaded into the vmalloc region, where they
should also benefit from the same protections as those loaded into
the more efficient module region. Allow these functions to operate
there as well.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/mm/pageattr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/pageattr.c b/arch/arm/mm/pageattr.c
index db09f2e7efda..ad8032bfe734 100644
--- a/arch/arm/mm/pageattr.c
+++ b/arch/arm/mm/pageattr.c
@@ -55,7 +55,8 @@ static int change_memory_common(unsigned long addr, int numpages,
if (!size)
return 0;
- if (!in_range(start, size, MODULES_VADDR, MODULES_END))
+ if (!in_range(start, size, MODULES_VADDR, MODULES_END) &&
+ !in_range(start, size, VMALLOC_START, VMALLOC_END))
return -EINVAL;
data.set_mask = set_mask;
--
2.7.4
^ permalink raw reply related
* Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-21 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <A001080B-2DC8-48D9-BD82-8276A9B3BE3D@axis.com>
On 21-11-2016 15:43, Lars Persson wrote:
>
>
>> 21 nov. 2016 kl. 16:06 skrev Joao Pinto <Joao.Pinto@synopsys.com>:
>>
>>> On 21-11-2016 14:25, Giuseppe CAVALLARO wrote:
>>>> On 11/21/2016 2:28 PM, Lars Persson wrote:
>>>>
>>>>
>>>>> 21 nov. 2016 kl. 13:53 skrev Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>>>>>
>>>>> Hello Joao
>>>>>
>>>>>> On 11/21/2016 1:32 PM, Joao Pinto wrote:
>>>>>> Hello,
>>>>>>
>>>>>>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>>>>>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>>>>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a
>>>>>>>>> single file
>>>>>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and
snip (...)
>>>>> The stmmac drivers run since many years on several platforms
>>>>> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
>>>>> configurations starting from 3.1x to 3.7x databooks.
>>>>>
>>>>> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
>>>>> are fully working.
>>>>>
>>>>> Also the stmmac has platform, device-tree and pcie supports and
>>>>> a lot of maintained glue-logic files.
>>>>>
>>>>> It is fully documented inside the kernel tree.
>>>>>
>>>>> I am happy to have new enhancements from other developers.
>>>>> So, on my side, if you want to spend your time on improving it on your
>>>>> platforms please feel free to do it!
>>>>>
>>>>> Concerning the stmicro/stmmac naming, these come from a really old
>>>>> story and have no issue to adopt new folder/file names.
>>>>>
>>>>> I am also open to merge fixes and changes from ethernet/synopsis.
>>>>> I want to point you on some benchmarks made by Alex some months ago
>>>>> (IIRC) that showed an stmmac winner (due to the several optimizations
>>>>> analyzed and reviewed in this mailing list).
>>>>>
>>>>> Peppe
>>>>>
>>>>
>>>> Hello Joao and others,
>>>>
>>
>> Hi Lars,
>>
>>>> As the maintainer of dwc_eth_qos.c I prefer also that we put efforts on the
>>>> most mature driver, the stmmac.
>>>>
>>>> I hope that the code can migrate into an ethernet/synopsys folder to keep the
>>>> convention of naming the folder after the vendor. This makes it easy for
>>>> others to find the driver.
>>>>
>>>> The dwc_eth_qos.c will eventually be removed and its DT binding interface can
>>>> then be implemented in the stmmac driver.
>>
>> So your ideia is to pick the ethernet/stmmac and rename it to ethernet/synopsys
>> and try to improve the structure and add the missing QoS features to it?
>
> Indeed this is what I prefer.
Ok, it makes sense.
Just for curiosity the target setup is the following:
https://www.youtube.com/watch?v=8V-LB5y2Cos
but instead of using internal drivers, we desire to use mainline drivers only.
Thanks!
>
>>
>>>
>>> Thanks Lars, I will be happy to support all you on this transition
>>> and I agree on renaming all.
>>>
>>> peppe
>>>
>>>
>>>> - Lars
>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> (See http://lists.openwall.net/netdev/2016/02/29/127)
>>>>>>>>
>>>>>>>> The former only supports 4.x of the hardware.
>>>>>>>>
>>>>>>>> The later supports 4.x and 3.x and already has a platform glue driver
>>>>>>>> with support for several platforms, a PCI glue driver, and a core driver
>>>>>>>> with several features not present in the former (for example: TX/RX
>>>>>>>> interrupt coalescing, EEE, PTP).
>>>>>>>>
>>>>>>>> Have you evaluated both drivers? Why have you decided to work on the
>>>>>>>> former rather than the latter?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
^ permalink raw reply
* [PATCH 0/3] ARM: davinci: hawk: fix mmc gpio declaration
From: Axel Haslam @ 2016-11-21 16:15 UTC (permalink / raw)
To: linux-arm-kernel
The hawk board does not have a write protect gpio, so remove
it form the platform data. Also the card detect gpio is declared
on the wrong pin. fix it.
After fixing the platform data bugs, change to use a gpio descriptor,
so we can take advantage of the drivers recent updates, and have card
detect irq instead of polling.
DEPENDENCIES:
MMC: davinci: fix card detect and write protect
https://lkml.org/lkml/2016/11/15/592
Axel Haslam (3):
ARM: davinci: hawk: fix mmc card detect gpio
ARM: davinci: hawk: remove mmc ro pin
ARM: davinci: hawk: use gpio descriptor for card detect
arch/arm/mach-davinci/board-omapl138-hawk.c | 44 ++++++++---------------------
1 file changed, 12 insertions(+), 32 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/3] ARM: davinci: hawk: fix mmc card detect gpio
From: Axel Haslam @ 2016-11-21 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121161541.27048-1-ahaslam@baylibre.com>
The card detect gpio on the hawk board is gpio4_0 and not gpio3_12
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a4e8726..c0c24ba9 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -25,7 +25,7 @@
#include <mach/mux.h>
#define HAWKBOARD_PHY_ID "davinci_mdio-0:07"
-#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(3, 12)
+#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
#define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13)
#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
@@ -119,7 +119,7 @@ static struct edma_rsv_info *da850_edma_rsv[2] = {
static const short hawk_mmcsd0_pins[] = {
DA850_MMCSD0_DAT_0, DA850_MMCSD0_DAT_1, DA850_MMCSD0_DAT_2,
DA850_MMCSD0_DAT_3, DA850_MMCSD0_CLK, DA850_MMCSD0_CMD,
- DA850_GPIO3_12, DA850_GPIO3_13,
+ DA850_GPIO4_0, DA850_GPIO3_13,
-1
};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] ARM: davinci: hawk: remove mmc ro pin
From: Axel Haslam @ 2016-11-21 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121161541.27048-1-ahaslam@baylibre.com>
The hawk board does not have a write protect pin to read the card
write protect status.
So remove un-needed platform data declaration for this gpio.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index c0c24ba9..ddc312d 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -26,7 +26,6 @@
#define HAWKBOARD_PHY_ID "davinci_mdio-0:07"
#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
-#define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13)
#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
#define DA850_USB1_OC_PIN GPIO_TO_PIN(6, 13)
@@ -119,22 +118,16 @@ static struct edma_rsv_info *da850_edma_rsv[2] = {
static const short hawk_mmcsd0_pins[] = {
DA850_MMCSD0_DAT_0, DA850_MMCSD0_DAT_1, DA850_MMCSD0_DAT_2,
DA850_MMCSD0_DAT_3, DA850_MMCSD0_CLK, DA850_MMCSD0_CMD,
- DA850_GPIO4_0, DA850_GPIO3_13,
+ DA850_GPIO4_0,
-1
};
-static int da850_hawk_mmc_get_ro(int index)
-{
- return gpio_get_value(DA850_HAWK_MMCSD_WP_PIN);
-}
-
static int da850_hawk_mmc_get_cd(int index)
{
return !gpio_get_value(DA850_HAWK_MMCSD_CD_PIN);
}
static struct davinci_mmc_config da850_mmc_config = {
- .get_ro = da850_hawk_mmc_get_ro,
.get_cd = da850_hawk_mmc_get_cd,
.wires = 4,
.max_freq = 50000000,
@@ -159,14 +152,6 @@ static __init void omapl138_hawk_mmc_init(void)
return;
}
- ret = gpio_request_one(DA850_HAWK_MMCSD_WP_PIN,
- GPIOF_DIR_IN, "MMC WP");
- if (ret < 0) {
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA850_HAWK_MMCSD_WP_PIN);
- goto mmc_setup_wp_fail;
- }
-
ret = da8xx_register_mmcsd0(&da850_mmc_config);
if (ret) {
pr_warn("%s: MMC/SD0 registration failed: %d\n", __func__, ret);
@@ -176,8 +161,6 @@ static __init void omapl138_hawk_mmc_init(void)
return;
mmc_setup_mmcsd_fail:
- gpio_free(DA850_HAWK_MMCSD_WP_PIN);
-mmc_setup_wp_fail:
gpio_free(DA850_HAWK_MMCSD_CD_PIN);
}
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] ARM: davinci: hawk: use gpio descriptor for card detect
From: Axel Haslam @ 2016-11-21 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121161541.27048-1-ahaslam@baylibre.com>
Currently the mmc driver is polling the gpio to know if the
card was removed.
By using a gpio descriptor instead of the platform callbacks, the
driver will be able to register the gpio with the mmc core with API's
designed for this purpose.
This has the advantage that an irq will be registered,
and polling is no longer needed. Also, platform callbacks can be removed.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index ddc312d..8e4f2102 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -15,6 +15,7 @@
#include <linux/gpio.h>
#include <linux/platform_data/gpio-davinci.h>
#include <linux/regulator/machine.h>
+#include <linux/gpio/machine.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -25,7 +26,6 @@
#include <mach/mux.h>
#define HAWKBOARD_PHY_ID "davinci_mdio-0:07"
-#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
#define DA850_USB1_OC_PIN GPIO_TO_PIN(6, 13)
@@ -122,13 +122,16 @@ static const short hawk_mmcsd0_pins[] = {
-1
};
-static int da850_hawk_mmc_get_cd(int index)
-{
- return !gpio_get_value(DA850_HAWK_MMCSD_CD_PIN);
-}
+static struct gpiod_lookup_table mmc_gpios_table = {
+ .dev_id = "da830-mmc.0",
+ .table = {
+ /* gpio4_0: chip 2 contains gpio range 64-95 */
+ GPIO_LOOKUP("davinci_gpio.2", 0, "cd",
+ GPIO_ACTIVE_LOW),
+ },
+};
static struct davinci_mmc_config da850_mmc_config = {
- .get_cd = da850_hawk_mmc_get_cd,
.wires = 4,
.max_freq = 50000000,
.caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
@@ -144,13 +147,7 @@ static __init void omapl138_hawk_mmc_init(void)
return;
}
- ret = gpio_request_one(DA850_HAWK_MMCSD_CD_PIN,
- GPIOF_DIR_IN, "MMC CD");
- if (ret < 0) {
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA850_HAWK_MMCSD_CD_PIN);
- return;
- }
+ gpiod_add_lookup_table(&mmc_gpios_table);
ret = da8xx_register_mmcsd0(&da850_mmc_config);
if (ret) {
@@ -161,7 +158,7 @@ static __init void omapl138_hawk_mmc_init(void)
return;
mmc_setup_mmcsd_fail:
- gpio_free(DA850_HAWK_MMCSD_CD_PIN);
+ gpiod_remove_lookup_table(&mmc_gpios_table);
}
static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id);
--
2.9.3
^ permalink raw reply related
* [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Jerome Brunet @ 2016-11-21 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121160149.GF1922@lunn.ch>
On Mon, 2016-11-21 at 17:01 +0100, Andrew Lunn wrote:
> On Mon, Nov 21, 2016 at 04:35:23PM +0100, Jerome Brunet wrote:
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > ---
> > ?Documentation/devicetree/bindings/net/phy.txt | 5 +++++
> > ?1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/phy.txt
> > b/Documentation/devicetree/bindings/net/phy.txt
> > index bc1c3c8bf8fa..7f066b7c1e2c 100644
> > --- a/Documentation/devicetree/bindings/net/phy.txt
> > +++ b/Documentation/devicetree/bindings/net/phy.txt
> > @@ -35,6 +35,11 @@ Optional Properties:
> > ?- broken-turn-around: If set, indicates the PHY device does not
> > correctly
> > ???release the turn around line low at the end of a MDIO
> > transaction.
> > ?
> > +- eee-advert-disable: Bits to clear in the MDIO_AN_EEE_ADV
> > register to
> > +??disable EEE modes. Example
> > +????* 0x4: disable EEE for 1000T,
> > +????* 0x6: disable EEE for 100TX and 1000T
> > +
>
> Hi Jerome
>
> I like the direction this patchset is taking. But hex values are
> pretty unfriendly.
Agreed
> Please add a set of boolean properties, and do the
> mapping to hex in the C code.
>
> That would also make extending this API easier. e.g. say you have a
> 10Gbps PHY with EEE, and you need to disable it. This hex value
> quickly gets ugly, eee-advert-disable-10000 is nice and simple.
What I did not realize when doing this patch for the realtek driver is
that there is already 6 valid modes defined in the kernel
#define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
100TX EEE cap */
#define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
1000T EEE cap */
#define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
#define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
*/
#define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
*/
#define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
*/
I took care of only 2 in the case of realtek.c since it only support
MDIO_EEE_100TX and MDIO_EEE_1000T.
Defining a property for each is certainly doable but it does not look
very nice either. If it extends in the future, it will get even more
messier, especially if you want to disable everything.
What do you think about keeping a single mask value but use the define
above in the DT ? It would be more readable than hex and easy to
extend, don't you think ?
These defines are already part of the uapi so I guess we can use those
in the DT bindings ?
>
> Andrew
^ 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