* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Florian Fainelli @ 2020-05-20 16:03 UTC (permalink / raw)
To: Dan Murphy, Andrew Lunn
Cc: hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <95ab99bf-2fb5-c092-ad14-1b0a47c782a4@ti.com>
On 5/20/2020 8:56 AM, Dan Murphy wrote:
> Andrew
>
> On 5/20/20 10:36 AM, Andrew Lunn wrote:
>>>> Hi Dan
>>>>
>>>> Having it required with PHY_INTERFACE_MODE_RGMII_ID or
>>>> PHY_INTERFACE_MODE_RGMII_RXID is pretty unusual. Normally these
>>>> properties are used to fine tune the delay, if the default of 2ns does
>>>> not work.
>>> Also if the MAC phy-mode is configured with RGMII-ID and no internal
>>> delay
>>> values defined wouldn't that be counter intuitive?
>> Most PHYs don't allow the delay to be fine tuned. You just pass for
>> example PHY_INTERFACE_MODE_RGMII_ID to the PHY driver and it enables a
>> 2ns delay. That is what people expect, and is documented.
>
>> Being able to tune the delay is an optional extra, which some PHYs
>> support, but that is always above and beyond
>> PHY_INTERFACE_MODE_RGMII_ID.
>
> I am interested in knowing where that is documented. I want to RTM I
> grepped for a few different words but came up empty
>
> Since this is a tuneable phy we need to program the ID. 2ns is the
> default value
>
> Maybe I can change it from Required to Configurable or Used.
I do not think this is properly documented, it is an established
practice, but it should be clearly documented somewhere, I do not know
whether that belongs in the PHY Device Tree binding or if this belongs
to the PHY documentation.
--
Florian
^ permalink raw reply
* Re: [next] i2c: mediatek: Use div_u64 for 64-bit division to fix 32-bit kernels
From: Randy Dunlap @ 2020-05-20 16:15 UTC (permalink / raw)
To: qii.wang, wsa
Cc: linux-i2c, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, srv_heupstream, leilk.liu
In-Reply-To: <1589970713-19944-1-git-send-email-qii.wang@mediatek.com>
On 5/20/20 3:31 AM, qii.wang@mediatek.com wrote:
> From: Qii Wang <qii.wang@mediatek.com>
>
> Use div_u64 for 64-bit division, and change sample_ns type to
> unsigned int. Otherwise, the module will reference __udivdi3
> under 32-bit kernels, which is not allowed in kernel space.
>
> Signed-off-by: Qii Wang <qii.wang@mediatek.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
thanks.
> ---
> drivers/i2c/busses/i2c-mt65xx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 7020618..deef69e 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -551,7 +551,8 @@ static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
> const struct i2c_spec_values *spec;
> unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
> unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
> - long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
> + unsigned int sample_ns = div_u64(1000000000ULL * (sample_cnt + 1),
> + clk_src);
>
> if (!i2c->dev_comp->timing_adjust)
> return 0;
>
--
~Randy
^ permalink raw reply
* Re: [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips
From: Bjorn Helgaas @ 2020-05-20 16:15 UTC (permalink / raw)
To: Jim Quinlan
Cc: Nicolas Saenz Julienne,
open list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE,
Greg Kroah-Hartman, Heikki Krogerus,
open list:DMA MAPPING HELPERS, Julien Grall,
moderated list:ARM PORT,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list, open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Saravana Kannan,
Stefano Stabellini, Suzuki K Poulose, Ulf Hansson
In-Reply-To: <20200519203419.12369-1-james.quinlan@broadcom.com>
On Tue, May 19, 2020 at 04:33:58PM -0400, Jim Quinlan wrote:
> This patchset expands the usefulness of the Broadcom Settop Box PCIe
> controller by building upon the PCIe driver used currently by the
> Raspbery Pi. Other forms of this patchset were submitted by me years
> ago and not accepted; the major sticking point was the code required
> for the DMA remapping needed for the PCIe driver to work [1].
>
> There have been many changes to the DMA and OF subsystems since that
> time, making a cleaner and less intrusive patchset possible. This
> patchset implements a generalization of "dev->dma_pfn_offset", except
> that instead of a single scalar offset it provides for multiple
> offsets via a function which depends upon the "dma-ranges" property of
> the PCIe host controller. This is required for proper functionality
> of the BrcmSTB PCIe controller and possibly some other devices.
>
> [1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101024@gmail.com/
>
> Jim Quinlan (15):
> PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
> ahci_brcm: fix use of BCM7216 reset controller
> dt-bindings: PCI: Add bindings for more Brcmstb chips
> PCI: brcmstb: Add compatibily of other chips
> PCI: brcmstb: Add suspend and resume pm_ops
> PCI: brcmstb: Asserting PERST is different for 7278
> PCI: brcmstb: Add control of rescal reset
> of: Include a dev param in of_dma_get_range()
> device core: Add ability to handle multiple dma offsets
> dma-direct: Invoke dma offset func if needed
> arm: dma-mapping: Invoke dma offset func if needed
> PCI: brcmstb: Set internal memory viewport sizes
> PCI: brcmstb: Accommodate MSI for older chips
> PCI: brcmstb: Set bus max burst side by chip type
> PCI: brcmstb: add compatilbe chips to match list
If you have occasion to post a v2 for other reasons,
s/PCIE_BRCMSTB depends on ARCH_BRCMSTB/Allow PCIE_BRCMSTB on ARCH_BRCMSTB also/
s/ahci_brcm: fix use of BCM7216 reset controller/ata: ahci_brcm: Fix .../
s/Add compatibily of other chips/Add bcm7278 register info/
s/Asserting PERST is different for 7278/Add bcm7278 PERST support/
s/Set bus max burst side/Set bus max burst size/
s/add compatilbe chips.*/Add bcm7211, bcm7216, bcm7445, bcm7278 to match list/
Rewrap commit logs to use full 75 character lines (to allow for the 4
spaces added by git log).
In commit logs, s/This commit// (use imperative mood instead).
In "Accommodate MSI for older chips" commit log, s/commont/common/.
> .../bindings/pci/brcm,stb-pcie.yaml | 40 +-
> arch/arm/include/asm/dma-mapping.h | 17 +-
> drivers/ata/ahci_brcm.c | 14 +-
> drivers/of/address.c | 54 ++-
> drivers/of/device.c | 2 +-
> drivers/of/of_private.h | 8 +-
> drivers/pci/controller/Kconfig | 4 +-
> drivers/pci/controller/pcie-brcmstb.c | 403 +++++++++++++++---
> include/linux/device.h | 9 +-
> include/linux/dma-direct.h | 16 +
> include/linux/dma-mapping.h | 44 ++
> kernel/dma/Kconfig | 12 +
> 12 files changed, 542 insertions(+), 81 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [TEGRA194_CPUFREQ Patch 1/3] firmware: tegra: adding function to get BPMP data
From: Rob Herring @ 2020-05-20 16:21 UTC (permalink / raw)
To: Thierry Reding
Cc: Viresh Kumar, Rafael J. Wysocki, Mikko Perttunen, Sumit Gupta,
Catalin Marinas, Will Deacon, Jon Hunter, Timo Alho,
open list:THERMAL, linux-tegra,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-kernel@vger.kernel.org, bbasu, Mikko Perttunen, devicetree
In-Reply-To: <20200520153854.GA2154237@ulmo>
On Wed, May 20, 2020 at 9:39 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, May 20, 2020 at 08:43:03AM -0600, Rob Herring wrote:
> > On Tue, Apr 7, 2020 at 4:05 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > >
> > > On Wed, Dec 04, 2019 at 03:21:38PM +0530, Viresh Kumar wrote:
> > > > On 04-12-19, 10:33, Thierry Reding wrote:
> > > > > Yeah, the code that registers this device is in drivers/base/cpu.c in
> > > > > register_cpu(). It even retrieves the device tree node for the CPU from
> > > > > device tree and stores it in cpu->dev.of_node, so we should be able to
> > > > > just pass &cpu->dev to tegra_bpmp_get() in order to retrieve a reference
> > > > > to the BPMP.
> > > > >
> > > > > That said, I'm wondering if perhaps we could just add a compatible
> > > > > string to the /cpus node for cases like this where we don't have an
> > > > > actual device representing the CPU complex. There are a number of CPU
> > > > > frequency drivers that register dummy devices just so that they have
> > > > > something to bind a driver to.
> > > > >
> > > > > If we allow the /cpus node to represent the CPU complex (if no other
> > > > > "device" does that yet), we can add a compatible string and have the
> > > > > cpufreq driver match on that.
> > > > >
> > > > > Of course this would be slightly difficult to retrofit into existing
> > > > > drivers because they'd need to remain backwards compatible with existing
> > > > > device trees. But it would allow future drivers to do this a little more
> > > > > elegantly. For some SoCs this may not matter, but especially once you
> > > > > start depending on additional resources this would come in handy.
> > > > >
> > > > > Adding Rob and the device tree mailing list for feedback on this idea.
> > > >
> > > > Took some time to find this thread, but something around this was
> > > > suggested by Rafael earlier.
> > > >
> > > > https://lore.kernel.org/lkml/8139001.Q4eV8YG1Il@vostro.rjw.lan/
> > >
> > > I gave this a try and came up with the following:
> > >
> > > --- >8 ---
> > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > index f4ede86e32b4..e4462f95f0b3 100644
> > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > @@ -1764,6 +1764,9 @@ bpmp_thermal: thermal {
> > > };
> > >
> > > cpus {
> > > + compatible = "nvidia,tegra194-ccplex";
> > > + nvidia,bpmp = <&bpmp>;
> >
> > Is there more than 1 bpmp? If not you don't need this. Just lookup the
> > node by compatible.
>
> There no SoCs currently than need to differentiate between multiple
> BPMPs, so yes, it would be possible to look up the node by compatible.
> But we also used to assume that PCs would only ever come with a single
> GPU or audio card and that's always caused a lot of work to clean up
> when it turned out to no longer be true.
Job security. ;)
> Also, we already have a couple of devices referencing the BPMP by
> phandle like this, so having this in a CCPLEX node would keep things
> consistent.
>
> One of the reasons why we initially did it this way was also so that we
> could make the dependencies explicit within device tree. If we look up
> by compatible string, then the driver is the only one with the knowledge
> about where to get at it. If we have the explicit reference we at least
> have a chance of determining the dependency by just looking at the
> device tree.
This case probably makes sense, but then driver dependencies can
evolve and you'd be updating the DT for every dependency. There's just
this general mindset that a driver can't look at the DT outside of its
own node.
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > --- >8 ---
> > >
> > > Now I can do something rougly like this, although I have a more complete
> > > patch locally that also gets rid of all the global variables because we
> > > now actually have a struct platform_device that we can anchor everything
> > > at:
> > >
> > > --- >8 ---
> > > static const struct of_device_id tegra194_cpufreq_of_match[] = {
> > > { .compatible = "nvidia,tegra194-ccplex", },
> > > { /* sentinel */ }
> > > };
> > > MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
> > >
> > > static struct platform_driver tegra194_ccplex_driver = {
> > > .driver = {
> > > .name = "tegra194-cpufreq",
> > > .of_match_table = tegra194_cpufreq_of_match,
> > > },
> > > .probe = tegra194_cpufreq_probe,
> > > .remove = tegra194_cpufreq_remove,
> > > };
> > > module_platform_driver(tegra194_ccplex_driver);
> > > --- >8 ---
> > >
> > > I don't think that's exactly what Rafael (Cc'ed) had in mind, since the
> > > above thread seems to have mostly talked about binding a driver to each
> > > individual CPU.
> > >
> > > But this seems a lot better than having to instantiate a device from
> > > scratch just so that a driver can bind to it and it allows additional
> > > properties to be associated with the CCPLEX device.
> >
> > What additional properties? A continual stream of properties added 1
> > by 1 would negatively affect my opinion of this.
>
> I don't expect there would be many. I think there's an earlier
> generation of Tegra that requires a regulator and I can imagine that's
> pretty common. But other than that I would expect this to be a fairly
> narrow set of properties.
>
> > > Rob, any thoughts on this from a device tree point of view? The /cpus
> > > bindings don't mention the compatible property, but there doesn't seem
> > > to be anything in the bindings that would prohibit its use.
> >
> > What happens when you have more than one cpu related driver in
> > addition to cpufreq? You may still have to end up creating child
> > platform devices and then gained very little.
>
> That's only if you absolutely want to stick with the "one driver per
> subsystem" model. I personally think that's completely obsolete these
> days. If you have a CPU complex device that can do both CPU frequency
> scaling and put the CPU into idle states, for example, then there is
> really no reason to artificially split that into two separate drivers
> just to match the subsystems that we have.
>
> Most subsystems that I've come across work just fine if a single driver
> registers with multiple subsystems.
Yes exactly. If only everyone thought this way...
> I also know that some people like it better when things are nicely split
> up into multiple drivers. But I really don't see how that simplifies
> things. In fact in my opinion that makes things only more complicated
> because you have additional boilerplate and then you need to be extra
> careful about how these different drivers are ordered, and you need to
> take extra precautions when sharing things like clocks and register
> regions.
I just cleaned up this exact mess with VExpress drivers...
It's just a constant issue to deal with.
> > You could solve this without DT changes. You can bind on node names.
> > The driver probe can then check the parent compatible and return if
> > not matching. I'm not sure if you could get module auto loading to
> > work in that case. It would have to be based on the root compatible
> > (rather than the driver match table) and be able to load multiple
> > matching modules.
>
> That sounds like it would get very complicated for something this
> simple. Having a compatible string in /cpus seemed like the most logical
> option because it would basically just work out of the box and the same
> way we're used to from other devices.
That's also why I get the node per driver...
That said, I'm fine with adding the compatible. I hope I don't regret it.
Rob
^ permalink raw reply
* Re: [PATCH v9 0/2] PCI: Microchip: Add host driver for Microchip PCIe controller
From: Bjorn Helgaas @ 2020-05-20 16:31 UTC (permalink / raw)
To: Daire.McNamara
Cc: amurray, lorenzo.pieralisi, linux-pci, bhelgaas, Rob Herring,
devicetree
In-Reply-To: <d7b32f86783f0e4883dbf917146f1c2bdb9f9589.camel@microchip.com>
[fixed Rob's email address ("robh+dt", not "robh-dt"]
On Wed, May 20, 2020 at 11:43:43AM +0000, Daire.McNamara@microchip.com wrote:
>
> This v9 patch adds support for the Microchip PCIe PolarFire PCIe
> controller when configured in host (Root Complex) mode.
Nit: v7 and v8 used "PCI: microchip:" subject prefixes, which matches
the convention for driver names in drivers/pci/controllers. This v9
uses "Microchip" again, which doesn't.
Patch 2/2 has extraneous "Subject:" in the subject line. Again, just
a nit, but it makes a little extra work for somebody to remove that
when applying.
It's also more convenient if 1/2 and 2/2 are sent as replies to the
0/2 cover letter, as you did for v3.
s/This patch// in commit logs (use imperative mood instead).
Rewrap commit logs to fill 75 columns (leaving room for the 4 spaces
added by git log).
No need to repost for these unless you make other fixes, but things
you can consider for the future.
> Updates since v8:
> * Refactored as per Rob Herring's comments:
> - bindings in schema format
> - Adjusted licence to GPLv2.0
> - Refactored access to config space between driver and common eCAM code
> - Adopted pci_host_probe()
> - Miscellanous other improvements
>
> Updates since v7:
> * Build for 64bit RISCV architecture only
>
> Updates since v6:
> * Refactored to use common eCAM driver
> * Updated to CONFIG_PCIE_MICROCHIP_HOST etc
> * Formatting improvements
> * Removed code for selection between bridge 0 and 1
>
> Updates since v5:
> * Fixed Kconfig typo noted by Randy Dunlap
> * Updated with comments from Bjorn Helgaas
>
> Updates since v4:
> * Fix compile issues.
>
> Updates since v3:
> * Update all references to Microsemi to Microchip
> * Separate MSI functionality from legacy PCIe interrupt handling functionality
>
> Updates since v2:
> * Split out DT bindings and Vendor ID updates into their own patch
> from PCIe driver.
> * Updated Change Log
>
> Updates since v1:
> * Incorporate feedback from Bjorn Helgaas
>
> Daire McNamara (2):
> PCI: Microchip: Add host driver for Microchip PCIe controller
> PCI: Microchip: Add host driver for Microchip PCIe controller
>
> .../bindings/pci/microchip,pcie-host.yaml | 94 +++
> drivers/pci/controller/Kconfig | 9 +
> drivers/pci/controller/Makefile | 1 +
> drivers/pci/controller/pcie-microchip-host.c | 664 ++++++++++++++++++
> 4 files changed, 768 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
> create mode 100644 drivers/pci/controller/pcie-microchip-host.c
>
>
> base-commit: c0cc271173b2e1c2d8d0ceaef14e4dfa79eefc0d
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH v5 0/4] iio: magnetometer: ak8975: Add gpio reset support
From: Jonathan Albrieux @ 2020-05-20 16:34 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner
v5:
- add maintainer
v4:
- fix some typo
- use gpio's dt-bindings for more clarity in documentation
- set compatible properties without vendor prefix as deprecated
https://lore.kernel.org/linux-iio/20200520073125.30808-1-jonathan.albrieux@gmail.com/
v3:
- fix patch messages style
- align reset gpio comment to kernel doc reccomendation
- introduce changelog
https://lore.kernel.org/linux-iio/20200519124402.26076-1-jonathan.albrieux@gmail.com/
v2:
- rewording of reset gpio comment and patch messages to better clarify
reset gpio behaviour
https://lore.kernel.org/linux-iio/20200518133645.19127-1-jonathan.albrieux@gmail.com/
v1:
- initial patch submission
https://lore.kernel.org/linux-iio/20200519065749.4624-1-jonathan.albrieux@gmail.com/
Convert documentation from txt format to yaml. Add documentation about
reset-gpio.
Deassert reset on ak8975_power_on(), assert reset on ak8975_power_off().
Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheet says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.
Jonathan Albrieux (4):
dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add
maintainer
dt-bindings: iio: magnetometer: ak8975: add gpio reset support
iio: magnetometer: ak8975: Fix typo, uniform measurement unit style
iio: magnetometer: ak8975: Add gpio reset support
.../bindings/iio/magnetometer/ak8975.txt | 30 --------
.../bindings/iio/magnetometer/ak8975.yaml | 77 +++++++++++++++++++
drivers/iio/magnetometer/ak8975.c | 22 +++++-
3 files changed, 97 insertions(+), 32 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
--
2.17.1
^ permalink raw reply
* [PATCH v5 1/4] dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add maintainer
From: Jonathan Albrieux @ 2020-05-20 16:34 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200520163417.27805-1-jonathan.albrieux@gmail.com>
Converts documentation from txt format to yaml.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
.../bindings/iio/magnetometer/ak8975.txt | 30 --------
.../bindings/iio/magnetometer/ak8975.yaml | 71 +++++++++++++++++++
2 files changed, 71 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
deleted file mode 100644
index aa67ceb0d4e0..000000000000
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* AsahiKASEI AK8975 magnetometer sensor
-
-Required properties:
-
- - compatible : should be "asahi-kasei,ak8975"
- - reg : the I2C address of the magnetometer
-
-Optional properties:
-
- - gpios : should be device tree identifier of the magnetometer DRDY pin
- - vdd-supply: an optional regulator that needs to be on to provide VDD
- - mount-matrix: an optional 3x3 mounting rotation matrix
-
-Example:
-
-ak8975@c {
- compatible = "asahi-kasei,ak8975";
- reg = <0x0c>;
- gpios = <&gpj0 7 0>;
- vdd-supply = <&ldo_3v3_gnss>;
- mount-matrix = "-0.984807753012208", /* x0 */
- "0", /* y0 */
- "-0.173648177666930", /* z0 */
- "0", /* x1 */
- "-1", /* y1 */
- "0", /* z1 */
- "-0.173648177666930", /* x2 */
- "0", /* y2 */
- "0.984807753012208"; /* z2 */
-};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
new file mode 100644
index 000000000000..8bde423a2ffa
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/magnetometer/ak8975.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: AsahiKASEI AK8975 magnetometer sensor
+
+maintainers:
+ - Jonathan Albrieux <jonathan.albrieux@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: asahi-kasei,ak8975
+ - const: asahi-kasei,ak8963
+ - const: asahi-kasei,ak09911
+ - const: asahi-kasei,ak09912
+ - const: ak8975
+ deprecated: true
+ - const: ak8963
+ deprecated: true
+ - const: ak09911
+ deprecated: true
+ - const: ak09912
+ deprecated: true
+
+ reg:
+ maxItems: 1
+ description: the I2C address of the magnetometer
+
+ gpios:
+ description: should be device tree identifier of the magnetometer DRDY pin
+
+ vdd-supply:
+ maxItems: 1
+ description: |
+ an optional regulator that needs to be on to provide VDD power to
+ the sensor.
+
+ mount-matrix:
+ description: an optional 3x3 mounting rotation matrix
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c@78b7000 {
+ reg = <0x78b6000 0x600>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ magnetometer@c {
+ compatible = "asahi-kasei,ak8975";
+ reg = <0x0c>;
+ gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
+ vdd-supply = <&ldo_3v3_gnss>;
+ mount-matrix = "-0.984807753012208", /* x0 */
+ "0", /* y0 */
+ "-0.173648177666930", /* z0 */
+ "0", /* x1 */
+ "-1", /* y1 */
+ "0", /* z1 */
+ "-0.173648177666930", /* x2 */
+ "0", /* y2 */
+ "0.984807753012208"; /* z2 */
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v5 2/4] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Jonathan Albrieux @ 2020-05-20 16:34 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Rob Herring
In-Reply-To: <20200520163417.27805-1-jonathan.albrieux@gmail.com>
Add reset-gpio support.
Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheet says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
---
.../devicetree/bindings/iio/magnetometer/ak8975.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
index 8bde423a2ffa..aba9ced7b6da 100644
--- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
@@ -41,6 +41,11 @@ properties:
mount-matrix:
description: an optional 3x3 mounting rotation matrix
+ reset-gpio:
+ description: |
+ an optional pin needed for AK09911 to set the reset state. This should
+ be usually active low
+
required:
- compatible
- reg
@@ -58,6 +63,7 @@ examples:
reg = <0x0c>;
gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
vdd-supply = <&ldo_3v3_gnss>;
+ reset-gpio = <&msmgpio 111 GPIO_ACTIVE_LOW>;
mount-matrix = "-0.984807753012208", /* x0 */
"0", /* y0 */
"-0.173648177666930", /* z0 */
--
2.17.1
^ permalink raw reply related
* [PATCH v5 3/4] iio: magnetometer: ak8975: Fix typo, uniform measurement unit style
From: Jonathan Albrieux @ 2020-05-20 16:34 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron, Allison Randal
In-Reply-To: <20200520163417.27805-1-jonathan.albrieux@gmail.com>
Minor comment style edits.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/iio/magnetometer/ak8975.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
index 3c881541ae72..fd368455cd7b 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -385,9 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
return ret;
}
/*
- * According to the datasheet the power supply rise time i 200us
+ * According to the datasheet the power supply rise time is 200us
* and the minimum wait time before mode setting is 100us, in
- * total 300 us. Add some margin and say minimum 500us here.
+ * total 300us. Add some margin and say minimum 500us here.
*/
usleep_range(500, 1000);
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH v5 4/4] iio: magnetometer: ak8975: Add gpio reset support
From: Jonathan Albrieux @ 2020-05-20 16:34 UTC (permalink / raw)
To: linux-kernel
Cc: ~postmarketos/upstreaming, Jonathan Albrieux, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron
In-Reply-To: <20200520163417.27805-1-jonathan.albrieux@gmail.com>
According to AK09911 datasheet, if reset gpio is provided then
deassert reset on ak8975_power_on() and assert reset on ak8975_power_off().
Without reset's deassertion during ak8975_power_on(), driver's probe fails
on ak8975_who_i_am() while checking for device identity for AK09911 chip.
AK09911 has an active low reset gpio to handle register's reset.
AK09911 datasheet says that, if not used, reset pin should be connected
to VID. This patch emulates this situation.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
---
drivers/iio/magnetometer/ak8975.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/iio/magnetometer/ak8975.c b/drivers/iio/magnetometer/ak8975.c
index fd368455cd7b..a23422aad97d 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -358,6 +358,7 @@ struct ak8975_data {
u8 asa[3];
long raw_to_gauss[3];
struct gpio_desc *eoc_gpiod;
+ struct gpio_desc *reset_gpiod;
int eoc_irq;
wait_queue_head_t data_ready_queue;
unsigned long flags;
@@ -384,6 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
"Failed to enable specified Vid supply\n");
return ret;
}
+
+ gpiod_set_value_cansleep(data->reset_gpiod, 0);
+
/*
* According to the datasheet the power supply rise time is 200us
* and the minimum wait time before mode setting is 100us, in
@@ -396,6 +400,8 @@ static int ak8975_power_on(const struct ak8975_data *data)
/* Disable attached power regulator if any. */
static void ak8975_power_off(const struct ak8975_data *data)
{
+ gpiod_set_value_cansleep(data->reset_gpiod, 1);
+
regulator_disable(data->vid);
regulator_disable(data->vdd);
}
@@ -839,6 +845,7 @@ static int ak8975_probe(struct i2c_client *client,
struct ak8975_data *data;
struct iio_dev *indio_dev;
struct gpio_desc *eoc_gpiod;
+ struct gpio_desc *reset_gpiod;
const void *match;
unsigned int i;
int err;
@@ -856,6 +863,16 @@ static int ak8975_probe(struct i2c_client *client,
if (eoc_gpiod)
gpiod_set_consumer_name(eoc_gpiod, "ak_8975");
+ /*
+ * According to AK09911 datasheet, if reset GPIO is provided then
+ * deassert reset on ak8975_power_on() and assert reset on
+ * ak8975_power_off().
+ */
+ reset_gpiod = devm_gpiod_get_optional(&client->dev,
+ "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(reset_gpiod))
+ return PTR_ERR(reset_gpiod);
+
/* Register with IIO */
indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
if (indio_dev == NULL)
@@ -866,6 +883,7 @@ static int ak8975_probe(struct i2c_client *client,
data->client = client;
data->eoc_gpiod = eoc_gpiod;
+ data->reset_gpiod = reset_gpiod;
data->eoc_irq = 0;
err = iio_read_mount_matrix(&client->dev, "mount-matrix", &data->orientation);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Andrew Lunn @ 2020-05-20 16:43 UTC (permalink / raw)
To: Dan Murphy
Cc: f.fainelli, hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <95ab99bf-2fb5-c092-ad14-1b0a47c782a4@ti.com>
> I am interested in knowing where that is documented. I want to RTM I
> grepped for a few different words but came up empty
Hi Dan
It probably is not well documented, but one example would be
Documentation/devicetree/bindings/net/ethernet-controller.yaml
says:
# RX and TX delays are added by the MAC when required
- rgmii
# RGMII with internal RX and TX delays provided by the PHY,
# the MAC should not add the RX or TX delays in this case
- rgmii-id
# RGMII with internal RX delay provided by the PHY, the MAC
# should not add an RX delay in this case
- rgmii-rxid
# RGMII with internal TX delay provided by the PHY, the MAC
# should not add an TX delay in this case
Andrew
^ permalink raw reply
* Re: [PATCH net 1/4] net: ethernet: fec: move GPR register offset and bit into DT
From: Jakub Kicinski @ 2020-05-20 16:54 UTC (permalink / raw)
To: fugang.duan; +Cc: davem, netdev, martin.fuzzey, robh+dt, shawnguo, devicetree
In-Reply-To: <1589963516-26703-2-git-send-email-fugang.duan@nxp.com>
On Wed, 20 May 2020 16:31:53 +0800 fugang.duan@nxp.com wrote:
> From: Fugang Duan <fugang.duan@nxp.com>
>
> The commit da722186f654(net: fec: set GPR bit on suspend by DT
> configuration) set the GPR reigster offset and bit in driver for
> wake on lan feature.
>
> But it introduces two issues here:
> - one SOC has two instances, they have different bit
> - different SOCs may have different offset and bit
>
> So to support wake-on-lan feature on other i.MX platforms, it should
> configure the GPR reigster offset and bit from DT.
>
> Fixes: da722186f654(net: fec: set GPR bit on suspend by DT configuration)
> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Fixes tag: Fixes: da722186f654(net: fec: set GPR bit on suspend by DT configuration)
Has these problem(s):
- missing space between the SHA1 and the subject
^ permalink raw reply
* Re: [PATCH net 3/4] ARM: dts: imx6: update fec gpr property to match new format
From: Andrew Lunn @ 2020-05-20 17:03 UTC (permalink / raw)
To: fugang.duan; +Cc: davem, netdev, martin.fuzzey, robh+dt, shawnguo, devicetree
In-Reply-To: <1589963516-26703-4-git-send-email-fugang.duan@nxp.com>
On Wed, May 20, 2020 at 04:31:55PM +0800, fugang.duan@nxp.com wrote:
> From: Fugang Duan <fugang.duan@nxp.com>
>
> Update the gpr property to define gpr register offset and
> bit in DT.
>
> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
> ---
> arch/arm/boot/dts/imx6qdl.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 98da446..a4a68b7 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -1045,7 +1045,7 @@
> <&clks IMX6QDL_CLK_ENET>,
> <&clks IMX6QDL_CLK_ENET_REF>;
> clock-names = "ipg", "ahb", "ptp";
> - gpr = <&gpr>;
> + gpr = <&gpr 0x34 27>;
> status = "disabled";
> };
Hi Andy
This is the same values as hard coded, so no change here.
The next patch does not use grp at all. So it is unclear to me if you
actually make use of what you just added. I don't see anywhere
gpr = <&gpr 0x42 24>;
which is the whole point of this change, being able to specify
different values.
Andrew
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: edt-ft5x06: change reg property
From: Dmitry Torokhov @ 2020-05-20 17:13 UTC (permalink / raw)
To: Johan Jonker
Cc: heiko, robh+dt, linux-input, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20200520073327.6016-1-jbx6244@gmail.com>
Hi Johan,
On Wed, May 20, 2020 at 09:33:27AM +0200, Johan Jonker wrote:
> A test with the command below gives this error:
>
> arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml:
> touchscreen@3e: reg:0:0: 56 was expected
>
> The touchscreen chip on 'rk3188-bqedison2qc' and other BQ models
> was shipped with different addresses then the binding currently allows.
> Change the reg property that any address will pass.
>
> make ARCH=arm dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/input/touchscreen/
> edt-ft5x06.yaml
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
> Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> index 383d64a91..baa8e8f7e 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
> @@ -42,7 +42,7 @@ properties:
> - focaltech,ft6236
>
> reg:
> - const: 0x38
> + maxItems: 1
Should we have a list of valid addresses instead of allowing any
address? Controllers usually have only a couple of addresses that they
support.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-05-20 17:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: f.fainelli, hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <20200520164313.GI652285@lunn.ch>
Andrew/Florian
On 5/20/20 11:43 AM, Andrew Lunn wrote:
>> I am interested in knowing where that is documented. I want to RTM I
>> grepped for a few different words but came up empty
> Hi Dan
>
> It probably is not well documented, but one example would be
>
> Documentation/devicetree/bindings/net/ethernet-controller.yaml
>
> says:
>
> # RX and TX delays are added by the MAC when required
> - rgmii
>
> # RGMII with internal RX and TX delays provided by the PHY,
> # the MAC should not add the RX or TX delays in this case
> - rgmii-id
>
> # RGMII with internal RX delay provided by the PHY, the MAC
> # should not add an RX delay in this case
> - rgmii-rxid
>
> # RGMII with internal TX delay provided by the PHY, the MAC
> # should not add an TX delay in this case
>
> Andrew
OKI I read that. I also looked at a couple other drivers too.
I am wondering if rx-internal-delay and tx-internal-delay should become
a common property like tx/rx fifo-depth
And properly document how to use it or at least the expectation on use.
Dan
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Alan Cooper @ 2020-05-20 17:29 UTC (permalink / raw)
To: Florian Fainelli
Cc: Alan Stern, Greg Kroah-Hartman, : Linux Kernel Mailing List,
Andy Shevchenko, DTML, Krzysztof Kozlowski, USB list,
Mathias Nyman, Rob Herring, Yoshihiro Shimoda, Andy Shevchenko
In-Reply-To: <CAOGqxeU=LjAmAYR9wGeKZo_eLj+ehkrANTM+04E7xWNAp82EJA@mail.gmail.com>
Greg, Alan,
The other 4 related patches were accepted into usb-next and I just
realized that this one didn't make it. This patch will not fix the
"insmod out of order" issue, but will help our controllers work with
some poorly behaved USB devices when the drivers are builtin.
Thanks
Al
On Wed, May 13, 2020 at 3:42 PM Alan Cooper <alcooperx@gmail.com> wrote:
>
> On Wed, May 13, 2020 at 1:46 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> >
> >
> > On 5/13/2020 10:39 AM, Alan Stern wrote:
> > > On Wed, May 13, 2020 at 07:05:05PM +0200, Greg Kroah-Hartman wrote:
> > >> On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
> > >>>
> > >>>
> > >>> On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> > >>>> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> > >>>>>
> > >>>>>
> > >>>>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> > >>>>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> > >>>>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> > >>>>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> > >>>>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
> > >>>>>>> has XHCI linking at the bottom which will result in the XHIC driver
> > >>>>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
> > >>>>>>> device will be seen as a 2.0 device. Moving the XHCI linking
> > >>>>>>> above the EHCI and OHCI linking fixes the issue.
> > >>>>>>
> > >>>>>> What happens if all of these are modules and they are loaded in a
> > >>>>>> different order? This makefile change will not help with that, you need
> > >>>>>> to have logic in the code in order to properly coordinate this type of
> > >>>>>> mess, sorry.
> > >>>>>
> > >>>>> I believe we should be using module soft dependencies to instruct the
> > >>>>> module loaders to load the modules in the correct order, so something
> > >>>>> like this would do (not tested) for xhci-plat-hcd.c:
> > >>>>>
> > >>>>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> > >>>>>
> > >>>>> and I am not sure whether we need to add the opposite for ehci-hcd and
> > >>>>> ohci-hcd:
> > >>>>>
> > >>>>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> > >>>>
> > >>>> That's a nice start, but what happens if that isn't honored? This
> > >>>> really needs to work properly for any order as you never can guarantee
> > >>>> module/driver loading order in a system of modules.
> > >>>
> > >>> I also suggested that device links may help, though I am not sure. What
> > >>> do you suggest to be done?
> > >>
> > >> No idea. device links will help if you defer the probe properly until
> > >> you see the proper drivers binding correctly.
> > >
> > > I suspect that in general there is no way to do this properly.
> > >
> > > We can't modify ehci-hcd and ohci-hcd to make them wait. In fact, for
> > > all they know, xhci-hcd will _never_ be loaded.
> > >
> > > One thing that might be possible (although not all platforms may support
> > > it) is if xhci-hcd could somehow disconnect all devices attached to a
> > > peer port when it starts up. But that would be disruptive to any
> > > devices that aren't USB-3.
> > >
> > > We faced a very similar ordering problem between ehci-hcd and
> > > [ou]hci-hcd many years ago, and we never found a good solution.
> > > We did arrange the link order so that ehci-hcd precedes the others, and
> > > we added a warning message to ehci-hcd which gets printed if the module
> > > initialization routine runs after [ou]hci-hcd is loaded. Also, there
> > > are MODULE_SOFTDEP lines in ohci-pci.c and uhci-pci.c.
> >
> > Given that these modules are used on specific SoC platforms, where we
> > usually provide a reference implementation of user space and kernel
> > space and documentation, it seems to me that the MODULE_SOFTDEP(),
> > despite being a hint and best effort from user space module loaders is
> > probably acceptable.
> > --
> > Florian
>
> What I found in the past is that things work. For example if the ehci
> driver starts first, the USB device will come up as a 2.0 device and
> when the XHCI driver comes up the device will switch to 3.0. I've see
> the same thing happen if OHCI starts before EHCI. It's just that there
> are some poorly behaved USB devices that have trouble with this.
>
> Al
^ permalink raw reply
* Re: [PATCH v4 06/11] net: ethernet: mtk-eth-mac: new driver
From: Bartosz Golaszewski @ 2020-05-20 17:34 UTC (permalink / raw)
To: Arnd Bergmann, Stephane Le Provost, Pedro Tsai, Andrew Perepech
Cc: Rob Herring, David S . Miller, Matthias Brugger, John Crispin,
Sean Wang, Mark Lee, Jakub Kicinski, Fabien Parent,
Heiner Kallweit, Edwin Peer, DTML, linux-kernel@vger.kernel.org,
Networking, Linux ARM, moderated list:ARM/Mediatek SoC...,
Bartosz Golaszewski
In-Reply-To: <CAK8P3a3jhrQ3p1JsqMNMOOnfo9t=rAPWaOAwAdDuFMh7wUtZQw@mail.gmail.com>
śr., 20 maj 2020 o 16:37 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> On Wed, May 20, 2020 at 1:25 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> > family. For now we only support full-duplex.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Looks much better, thanks for addressing my feedback. A few more things
> about this version:
>
> > ---
> > drivers/net/ethernet/mediatek/Kconfig | 6 +
> > drivers/net/ethernet/mediatek/Makefile | 1 +
> > drivers/net/ethernet/mediatek/mtk_eth_mac.c | 1668 +++++++++++++++++++
> > 3 files changed, 1675 insertions(+)
> > create mode 100644 drivers/net/ethernet/mediatek/mtk_eth_mac.c
> >
> > diff --git a/drivers/net/ethernet/mediatek/Kconfig b/drivers/net/ethernet/mediatek/Kconfig
> > index 5079b8090f16..5c3793076765 100644
> > --- a/drivers/net/ethernet/mediatek/Kconfig
> > +++ b/drivers/net/ethernet/mediatek/Kconfig
> > @@ -14,4 +14,10 @@ config NET_MEDIATEK_SOC
> > This driver supports the gigabit ethernet MACs in the
> > MediaTek SoC family.
> >
> > +config NET_MEDIATEK_MAC
> > + tristate "MediaTek Ethernet MAC support"
> > + select PHYLIB
> > + help
> > + This driver supports the ethernet IP on MediaTek MT85** SoCs.
>
> I just noticed how the naming of NET_MEDIATEK_MAC and NET_MEDIATEK_SOC
> for two different drivers doing the same thing is really confusing.
>
> Maybe someone can come up with a better name, such as one
> based on the soc it first showed up in.
>
This has been discussed under one of the previous submissions.
MediaTek wants to use this IP on future designs as well and it's
already used on multiple SoCs so they want the name to be generic. I
also argued that this is a driver strongly tied to a specific
platform(s) so if someone wants to compile it - they probably know
what they're doing.
That being said: I verified with MediaTek and the name of the IP I can
use is "star" so they proposed "mtk-star-eth". I would personally
maybe go with "mtk-star-mac". How about those two?
> > + struct mtk_mac_ring_desc *desc = &ring->descs[ring->head];
> > + unsigned int status;
> > +
> > + status = desc->status;
> > +
> > + ring->skbs[ring->head] = desc_data->skb;
> > + ring->dma_addrs[ring->head] = desc_data->dma_addr;
> > + desc->data_ptr = desc_data->dma_addr;
> > +
> > + status |= desc_data->len;
> > + if (flags)
> > + status |= flags;
> > + desc->status = status;
> > +
> > + /* Flush previous modifications before ownership change. */
> > + dma_wmb();
> > + desc->status &= ~MTK_MAC_DESC_BIT_COWN;
>
> You still do the read-modify-write on the word here, which is
> expensive on uncached memory. You have read the value already,
> so better use an assignment rather than &=, or (better)
> READ_ONCE() and WRITE_ONCE() to prevent the compiler
> from adding further accesses.
>
Will do.
>
> > +static void mtk_mac_lock(struct mtk_mac_priv *priv)
> > +{
> > + spin_lock_bh(&priv->lock);
> > +}
> > +
> > +static void mtk_mac_unlock(struct mtk_mac_priv *priv)
> > +{
> > + spin_unlock_bh(&priv->lock);
> > +}
>
> I think open-coding the locks would make this more readable,
> and let you use spin_lock() instead of spin_lock_bh() in
> those functions that are already in softirq context.
>
Will do.
> > +static void mtk_mac_intr_enable_tx(struct mtk_mac_priv *priv)
> > +{
> > + regmap_update_bits(priv->regs, MTK_MAC_REG_INT_MASK,
> > + MTK_MAC_BIT_INT_STS_TNTC, 0);
> > +}
> > +static void mtk_mac_intr_enable_rx(struct mtk_mac_priv *priv)
> > +{
> > + regmap_update_bits(priv->regs, MTK_MAC_REG_INT_MASK,
> > + MTK_MAC_BIT_INT_STS_FNRC, 0);
> > +}
>
> These imply reading the irq mask register and then writing it again,
> which is much more expensive than just writing it. It's also not
> atomic since the regmap does not use a lock.
>
> I don't think you actually need to enable/disable rx and tx separately,
> but if you do, then writing to the Ack register as I suggested instead
> of updating the mask would let you do this.
>
> > +/* All processing for TX and RX happens in the napi poll callback. */
> > +static irqreturn_t mtk_mac_handle_irq(int irq, void *data)
> > +{
> > + struct mtk_mac_priv *priv;
> > + struct net_device *ndev;
> > + bool need_napi = false;
> > + unsigned int status;
> > +
> > + ndev = data;
> > + priv = netdev_priv(ndev);
> > +
> > + if (netif_running(ndev)) {
> > + status = mtk_mac_intr_read(priv);
> > +
> > + if (status & MTK_MAC_BIT_INT_STS_TNTC) {
> > + mtk_mac_intr_disable_tx(priv);
> > + need_napi = true;
> > + }
> > +
> > + if (status & MTK_MAC_BIT_INT_STS_FNRC) {
> > + mtk_mac_intr_disable_rx(priv);
> > + need_napi = true;
> > + }
>
> I think you mixed up the rx and tx bits here: when you get
> an rx interrupt, that one is already blocked until it gets
> acked and you just need to disable tx until the end of the
> poll function.
>
> However, I suspect that the overhead of turning them off
> is higher than what you can save, and simply ignoring
> the mask with
>
> if (status & (MTK_MAC_BIT_INT_STS_FNRC | MTK_MAC_BIT_INT_STS_TNTC))
> napi_schedule(&priv->napi);
>
> would be simpler and faster.
>
> + /* One of the counters reached 0x8000000 - update stats and
> > + * reset all counters.
> > + */
> > + if (unlikely(status & MTK_MAC_REG_INT_STS_MIB_CNT_TH)) {
> > + mtk_mac_intr_disable_stats(priv);
> > + schedule_work(&priv->stats_work);
> > + }
> > + befor
> > + mtk_mac_intr_ack_all(priv);
>
> The ack here needs to be dropped, otherwise you can get further
> interrupts before the bottom half has had a chance to run.
>
My thinking was this: if I mask the relevant interrupt (TX/RX
complete) and ack it right away, the status bit will be asserted on
the next packet received/sent but the process won't get interrupted
and when I unmask it, it will fire right away and I won't have to
recheck the status register. I noticed that if I ack it at the end of
napi poll callback, I end up missing certain TX complete interrupts
and end up seeing a lot of retransmissions even if I reread the status
register. I'm not yet sure where this race happens.
> You might be lucky because you had already disabled the individual
> bits earlier, but I don't think that was intentional here.
>
> > +static int mtk_mac_netdev_start_xmit(struct sk_buff *skb,
> > + struct net_device *ndev)
> > +{
> > + struct mtk_mac_priv *priv = netdev_priv(ndev);
> > + struct mtk_mac_ring *ring = &priv->tx_ring;
> > + struct device *dev = mtk_mac_get_dev(priv);
> > + struct mtk_mac_ring_desc_data desc_data;
> > +
> > + desc_data.dma_addr = mtk_mac_dma_map_tx(priv, skb);
> > + if (dma_mapping_error(dev, desc_data.dma_addr))
> > + goto err_drop_packet;
> > +
> > + desc_data.skb = skb;
> > + desc_data.len = skb->len;
> > +
> > + mtk_mac_lock(priv);
> > +
> > + mtk_mac_ring_push_head_tx(ring, &desc_data);
> > +
> > + netdev_sent_queue(ndev, skb->len);
> > +
> > + if (mtk_mac_ring_full(ring))
> > + netif_stop_queue(ndev);
> > +
> > + mtk_mac_unlock(priv);
> > +
> > + mtk_mac_dma_resume_tx(priv);
>
> mtk_mac_dma_resume_tx() is an expensive read-modify-write
> on an mmio register, so it would make sense to defer it based
> on netdev_xmit_more(). (I had missed this in the previous
> review)
>
Thanks for bringing it to my attention, I'll see about using it.
> > +static void mtk_mac_tx_complete_all(struct mtk_mac_priv *priv)
> > +{
> > + struct mtk_mac_ring *ring = &priv->tx_ring;
> > + struct net_device *ndev = priv->ndev;
> > + int ret, pkts_compl, bytes_compl;
> > + bool wake = false;
> > +
> > + mtk_mac_lock(priv);
> > +
> > + for (pkts_compl = 0, bytes_compl = 0;;
> > + pkts_compl++, bytes_compl += ret, wake = true) {
> > + if (!mtk_mac_ring_descs_available(ring))
> > + break;
> > +
> > + ret = mtk_mac_tx_complete_one(priv);
> > + if (ret < 0)
> > + break;
> > + }
> > +
> > + netdev_completed_queue(ndev, pkts_compl, bytes_compl);
> > +
> > + if (wake && netif_queue_stopped(ndev))
> > + netif_wake_queue(ndev);
> > +
> > + mtk_mac_intr_enable_tx(priv);
>
> No need to ack the interrupt here if napi is still active. Just
> ack both rx and tx when calling napi_complete().
>
> Some drivers actually use the napi budget for both rx and tx:
> if you have more than 'budget' completed tx frames, return
> early from this function and skip the napi_complete even
> when less than 'budget' rx frames have arrived.
>
IIRC Jakub said that the most seen approach is to free all TX descs
and receive up to budget packets, so this is what I did. I think it
makes the most sense.
Best regards,
Bartosz
> This way you get more fairness between devices and
> can run for longer with irqs disabled as long as either rx
> or tx is busy.
>
> Arnd
^ permalink raw reply
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets
From: Christoph Hellwig @ 2020-05-20 17:42 UTC (permalink / raw)
To: Jim Quinlan
Cc: Nicolas Saenz Julienne, Rob Herring, Frank Rowand,
Christoph Hellwig, Marek Szyprowski, Robin Murphy,
Greg Kroah-Hartman, Suzuki K Poulose, Saravana Kannan,
Heikki Krogerus, Rafael J. Wysocki, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:DMA MAPPING HELPERS
In-Reply-To: <20200519203419.12369-10-james.quinlan@broadcom.com>
If you don't Cc me on the whole series I have absolutely no way to
review it. Don't ever do these stupid partial Ccs as they cause nothing
but pain.
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Florian Fainelli @ 2020-05-20 17:45 UTC (permalink / raw)
To: Dan Murphy, Andrew Lunn
Cc: hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <d5d46c21-0afa-0c51-9baf-4f99de94bbd5@ti.com>
On 5/20/2020 10:20 AM, Dan Murphy wrote:
> Andrew/Florian
>
> On 5/20/20 11:43 AM, Andrew Lunn wrote:
>>> I am interested in knowing where that is documented. I want to RTM I
>>> grepped for a few different words but came up empty
>> Hi Dan
>>
>> It probably is not well documented, but one example would be
>>
>> Documentation/devicetree/bindings/net/ethernet-controller.yaml
>>
>> says:
>>
>> # RX and TX delays are added by the MAC when required
>> - rgmii
>>
>> # RGMII with internal RX and TX delays provided by the PHY,
>> # the MAC should not add the RX or TX delays in this case
>> - rgmii-id
>>
>> # RGMII with internal RX delay provided by the PHY, the MAC
>> # should not add an RX delay in this case
>> - rgmii-rxid
>>
>> # RGMII with internal TX delay provided by the PHY, the MAC
>> # should not add an TX delay in this case
>>
>> Andrew
>
> OKI I read that. I also looked at a couple other drivers too.
>
> I am wondering if rx-internal-delay and tx-internal-delay should become
> a common property like tx/rx fifo-depth
> > And properly document how to use it or at least the expectation on use.
Yes they should, and they should have an unit associated with the name.
--
Florian
^ permalink raw reply
* Re: [PATCH v11] arm64: dts: qcom: sc7180: Add WCN3990 WLAN module device node
From: Sibi Sankar @ 2020-05-20 17:50 UTC (permalink / raw)
To: Rakesh Pillai
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-arm-msm,
linux-kernel-owner
In-Reply-To: <1589946996-31264-1-git-send-email-pillair@codeaurora.org>
On 2020-05-20 09:26, Rakesh Pillai wrote:
> Add device node for the ath10k SNOC platform driver probe
> and add resources required for WCN3990 on sc7180 soc.
>
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> ---
> Changes from v10:
> - Corrected the position of wifi node, as per address
> - Removed the wlan_fw_mem from reserved memory, since
> its already added as reserved memory in board DT file.
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sc7180-idp.dts | 7 +++++++
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> index 4e9149d..38b102e 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> @@ -389,6 +389,13 @@
> };
> };
>
> +&wifi {
> + status = "okay";
> + wifi-firmware {
> + iommus = <&apps_smmu 0xc2 0x1>;
> + };
> +};
> +
> /* PINCTRL - additions to nodes defined in sc7180.dtsi */
>
> &qspi_clk {
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 6b12c60..da79f8f 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -2811,6 +2811,28 @@
>
> #freq-domain-cells = <1>;
> };
> +
> + wifi: wifi@18800000 {
> + compatible = "qcom,wcn3990-wifi";
> + reg = <0 0x18800000 0 0x800000>;
> + reg-names = "membase";
> + iommus = <&apps_smmu 0xc0 0x1>;
> + interrupts =
> + <GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH /* CE0 */ >,
> + <GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH /* CE1 */ >,
> + <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH /* CE2 */ >,
> + <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH /* CE3 */ >,
> + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH /* CE4 */ >,
> + <GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH /* CE5 */ >,
> + <GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH /* CE6 */ >,
> + <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH /* CE7 */ >,
> + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH /* CE8 */ >,
> + <GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH /* CE9 */ >,
> + <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH /* CE10 */>,
> + <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH /* CE11 */>;
> + memory-region = <&wlan_mem>;
> + status = "disabled";
> + };
> };
>
> thermal-zones {
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-05-20 17:52 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: hkallweit1, davem, netdev, linux-kernel, devicetree
In-Reply-To: <41101897-5b29-4a9d-0c14-9b8080089850@gmail.com>
Florian
On 5/20/20 12:45 PM, Florian Fainelli wrote:
>
> On 5/20/2020 10:20 AM, Dan Murphy wrote:
>> Andrew/Florian
>>
>> On 5/20/20 11:43 AM, Andrew Lunn wrote:
>>>> I am interested in knowing where that is documented. I want to RTM I
>>>> grepped for a few different words but came up empty
>>> Hi Dan
>>>
>>> It probably is not well documented, but one example would be
>>>
>>> Documentation/devicetree/bindings/net/ethernet-controller.yaml
>>>
>>> says:
>>>
>>> # RX and TX delays are added by the MAC when required
>>> - rgmii
>>>
>>> # RGMII with internal RX and TX delays provided by the PHY,
>>> # the MAC should not add the RX or TX delays in this case
>>> - rgmii-id
>>>
>>> # RGMII with internal RX delay provided by the PHY, the MAC
>>> # should not add an RX delay in this case
>>> - rgmii-rxid
>>>
>>> # RGMII with internal TX delay provided by the PHY, the MAC
>>> # should not add an TX delay in this case
>>>
>>> Andrew
>> OKI I read that. I also looked at a couple other drivers too.
>>
>> I am wondering if rx-internal-delay and tx-internal-delay should become
>> a common property like tx/rx fifo-depth
>>> And properly document how to use it or at least the expectation on use.
> Yes they should, and they should have an unit associated with the name.
UGH I think I just got volunteered to do make them common.
Dan
^ permalink raw reply
* Re: [PATCH v5 1/5] dt-bindings: remoteproc: Add Qualcomm PIL info binding
From: Mathieu Poirier @ 2020-05-20 17:59 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Ohad Ben-Cohen, Rob Herring, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, Stephen Boyd
In-Reply-To: <20200513055641.1413100-2-bjorn.andersson@linaro.org>
On Tue, May 12, 2020 at 10:56:37PM -0700, Bjorn Andersson wrote:
> Add a devicetree binding for the Qualcomm peripheral image loader
> relocation information region found in the IMEM.
>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v4:
> - Fixed reg in example to make it compile
>
> .../bindings/remoteproc/qcom,pil-info.yaml | 44 +++++++++++++++++++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
> new file mode 100644
> index 000000000000..87c52316ddbd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/remoteproc/qcom,pil-info.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm peripheral image loader relocation info binding
> +
> +maintainers:
> + - Bjorn Andersson <bjorn.andersson@linaro.org>
> +
> +description:
> + The Qualcomm peripheral image loader relocation memory region, in IMEM, is
> + used for communicating remoteproc relocation information to post mortem
> + debugging tools.
> +
> +properties:
> + compatible:
> + const: qcom,pil-reloc-info
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> + imem@146bf000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x146bf000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + ranges = <0 0x146bf000 0x1000>;
> +
> + pil-reloc@94c {
> + compatible = "qcom,pil-reloc-info";
> + reg = <0x94c 0xc8>;
> + };
> + };
> +...
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v5 2/5] remoteproc: qcom: Introduce helper to store pil info in IMEM
From: Mathieu Poirier @ 2020-05-20 18:00 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Ohad Ben-Cohen, Rob Herring, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20200513055641.1413100-3-bjorn.andersson@linaro.org>
On Tue, May 12, 2020 at 10:56:38PM -0700, Bjorn Andersson wrote:
> A region in IMEM is used to communicate load addresses of remoteproc to
> post mortem debug tools. Implement a helper function that can be used to
> store this information in order to enable these tools to process
> collected ramdumps.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v4:
> - Replaced platform_driver by just a single helper function
> - Lazy initialization of mapping
> - Cleaned up search loop
> - Replaced regmap access of IMEM with ioremap and normal accessors
>
> drivers/remoteproc/Kconfig | 3 +
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/qcom_pil_info.c | 124 +++++++++++++++++++++++++++++
> drivers/remoteproc/qcom_pil_info.h | 7 ++
> 4 files changed, 135 insertions(+)
> create mode 100644 drivers/remoteproc/qcom_pil_info.c
> create mode 100644 drivers/remoteproc/qcom_pil_info.h
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index fbaed079b299..8088ca4dd6dc 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -107,6 +107,9 @@ config KEYSTONE_REMOTEPROC
> It's safe to say N here if you're not interested in the Keystone
> DSPs or just want to use a bare minimum kernel.
>
> +config QCOM_PIL_INFO
> + tristate
> +
> config QCOM_RPROC_COMMON
> tristate
>
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 0effd3825035..cc0f631adb3b 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
> obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
> obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
> +obj-$(CONFIG_QCOM_PIL_INFO) += qcom_pil_info.o
> obj-$(CONFIG_QCOM_RPROC_COMMON) += qcom_common.o
> obj-$(CONFIG_QCOM_Q6V5_COMMON) += qcom_q6v5.o
> obj-$(CONFIG_QCOM_Q6V5_ADSP) += qcom_q6v5_adsp.o
> diff --git a/drivers/remoteproc/qcom_pil_info.c b/drivers/remoteproc/qcom_pil_info.c
> new file mode 100644
> index 000000000000..0785c7cde2d3
> --- /dev/null
> +++ b/drivers/remoteproc/qcom_pil_info.c
> @@ -0,0 +1,124 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2019-2020 Linaro Ltd.
> + */
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of_address.h>
> +
> +#define PIL_RELOC_NAME_LEN 8
> +
> +struct pil_reloc_entry {
> + char name[PIL_RELOC_NAME_LEN];
> + __le64 base;
> + __le32 size;
> +} __packed;
> +
> +struct pil_reloc {
> + struct device *dev;
> + void __iomem *base;
> + size_t num_entries;
> +};
> +
> +static struct pil_reloc _reloc __read_mostly;
> +static DEFINE_MUTEX(reloc_mutex);
> +
> +static int qcom_pil_info_init(void)
> +{
> + struct device_node *np;
> + struct resource imem;
> + void __iomem *base;
> + int ret;
> +
> + /* Already initialized? */
> + if (_reloc.base)
> + return 0;
> +
> + np = of_find_compatible_node(NULL, NULL, "qcom,pil-reloc-info");
> + if (!np)
> + return -ENOENT;
> +
> + ret = of_address_to_resource(np, 0, &imem);
> + of_node_put(np);
> + if (ret < 0)
> + return ret;
> +
> + base = ioremap(imem.start, resource_size(&imem));
> + if (!base) {
> + pr_err("failed to map PIL relocation info region\n");
> + return -ENOMEM;
> + }
> +
> + memset_io(base, 0, resource_size(&imem));
> +
> + _reloc.base = base;
> + _reloc.num_entries = resource_size(&imem) / sizeof(struct pil_reloc_entry);
> +
> + return 0;
> +}
> +
> +/**
> + * qcom_pil_info_store() - store PIL information of image in IMEM
> + * @image: name of the image
> + * @base: base address of the loaded image
> + * @size: size of the loaded image
> + *
> + * Return: 0 on success, negative errno on failure
> + */
> +int qcom_pil_info_store(const char *image, phys_addr_t base, size_t size)
> +{
> + char buf[PIL_RELOC_NAME_LEN];
> + void __iomem *entry;
> + int ret;
> + int i;
> +
> + mutex_lock(&reloc_mutex);
> + ret = qcom_pil_info_init();
> + if (ret < 0) {
> + mutex_unlock(&reloc_mutex);
> + return ret;
> + }
> +
> + for (i = 0; i < _reloc.num_entries; i++) {
> + entry = _reloc.base + i * sizeof(struct pil_reloc_entry);
> +
> + memcpy_fromio(buf, entry, PIL_RELOC_NAME_LEN);
> +
> + /*
> + * An empty record means we didn't find it, given that the
> + * records are packed.
> + */
> + if (!buf[0])
> + goto found_unused;
> +
> + if (!strncmp(buf, image, PIL_RELOC_NAME_LEN))
> + goto found_existing;
> + }
> +
> + pr_warn("insufficient PIL info slots\n");
> + mutex_unlock(&reloc_mutex);
> + return -ENOMEM;
> +
> +found_unused:
> + memcpy_toio(entry, image, PIL_RELOC_NAME_LEN);
> +found_existing:
> + writel(base, entry + offsetof(struct pil_reloc_entry, base));
> + writel(size, entry + offsetof(struct pil_reloc_entry, size));
> + mutex_unlock(&reloc_mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(qcom_pil_info_store);
> +
> +static void __exit pil_reloc_exit(void)
> +{
> + mutex_lock(&reloc_mutex);
> + iounmap(_reloc.base);
> + _reloc.base = NULL;
> + mutex_unlock(&reloc_mutex);
> +}
> +module_exit(pil_reloc_exit);
> +
> +MODULE_DESCRIPTION("Qualcomm PIL relocation info");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/remoteproc/qcom_pil_info.h b/drivers/remoteproc/qcom_pil_info.h
> new file mode 100644
> index 000000000000..1b89a63ba82f
> --- /dev/null
> +++ b/drivers/remoteproc/qcom_pil_info.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __QCOM_PIL_INFO_H__
> +#define __QCOM_PIL_INFO_H__
> +
> +int qcom_pil_info_store(const char *image, phys_addr_t base, size_t size);
> +
> +#endif
Very clean an easy to understand.
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets
From: Jim Quinlan @ 2020-05-20 18:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Nicolas Saenz Julienne, Rob Herring, Frank Rowand,
Marek Szyprowski, Robin Murphy, Greg Kroah-Hartman,
Suzuki K Poulose, Saravana Kannan, Heikki Krogerus,
Rafael J. Wysocki, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:DMA MAPPING HELPERS
In-Reply-To: <20200520174216.GA11770@lst.de>
Sorry, I meant to put you on the to-list for all patches. The last
time I sent out this many patches using a collective cc-list for all
patches I was told to reduce my cc-list.
Jim
On Wed, May 20, 2020 at 1:42 PM Christoph Hellwig <hch@lst.de> wrote:
>
> If you don't Cc me on the whole series I have absolutely no way to
> review it. Don't ever do these stupid partial Ccs as they cause nothing
> but pain.
^ permalink raw reply
* Re: [PATCH v2 18/20] mips: csrc-r4k: Decrease r4k-clocksource rating if CPU_FREQ enabled
From: Thomas Bogendoerfer @ 2020-05-20 18:40 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Alexey Malahov, Paul Burton, Ralf Baechle,
Greg Kroah-Hartman, Arnd Bergmann, Rob Herring, linux-pm,
devicetree, Vincenzo Frascino, Thomas Gleixner, linux-mips,
linux-kernel
In-Reply-To: <20200520115926.lk6ycke75flwzcd2@mobilestation>
On Wed, May 20, 2020 at 02:59:26PM +0300, Serge Semin wrote:
> I think there is a misunderstanding here. In this patch I am not enabling
you are right, I've missed the fact, that this also needs to be enabled
in TLB entries. Strange that MIPS added the enable bit while R10k simply
do uncached acclerated, whenever TLB entry selects it.
> If there is no misunderstanding and you said what you said, that even enabling
> the feature for utilization might be dangerous, let's at least leave the
> MIPS_CONF_MM, MIPS_CONF_MM_FULL and MIPS_CONF_MM_SYS_SYSAD fields
> definition in the "arch/mips/include/asm/mipsregs.h" header. I'll use
> them to enable the write-merge in my platform code.
>
> What do you think?
I withdraw my concerns and will apply the patch as is.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ 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