* Re: [PATCH v4 2/2] PCI: uniphier: Add Socionext UniPhier Pro5 PCIe endpoint controller driver
From: Rob Herring @ 2020-05-20 23:06 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: devicetree, Lorenzo Pieralisi, Rob Herring, Masami Hiramatsu,
Masahiro Yamada, linux-kernel, linux-pci, Jassi Brar,
linux-arm-kernel, Bjorn Helgaas
In-Reply-To: <1589457801-12796-3-git-send-email-hayashi.kunihiko@socionext.com>
On Thu, 14 May 2020 21:03:21 +0900, Kunihiko Hayashi wrote:
> Add driver for the Socionext UniPhier Pro5 SoC endpoint controller.
> This controller is based on the DesignWare PCIe core.
>
> And add "host" to existing controller descriontions for the host controller
> in Kconfig.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> MAINTAINERS | 2 +-
> drivers/pci/controller/dwc/Kconfig | 13 +-
> drivers/pci/controller/dwc/Makefile | 1 +
> drivers/pci/controller/dwc/pcie-uniphier-ep.c | 383 ++++++++++++++++++++++++++
> 4 files changed, 396 insertions(+), 3 deletions(-)
> create mode 100644 drivers/pci/controller/dwc/pcie-uniphier-ep.c
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 0/5] arm64: dts: meson: add W400 dtsi and GT-King/Pro devices
From: Kevin Hilman @ 2020-05-20 22:57 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, linux-amlogic, linux-arm-kernel,
linux-kernel, devicetree, Christian Hewitt
In-Reply-To: <20200520014329.12469-1-christianshewitt@gmail.com>
On Wed, 20 May 2020 01:43:24 +0000, Christian Hewitt wrote:
> This series combines patch 2 from [1] which converts the existing Ugoos
> AM6 device-tree to a common W400 dtsi and dts, and then reworks the
> Beelink GT-King/GT-King Pro series from [2] to use the dtsi, but this
> time without the offending common audio dtsi approach. I've carried
> forwards acks on bindings from Rob as these did not change.
>
> v4 - rebased against Kevin's v5.8/dt64 branch
>
> [...]
Applied, thanks!
[1/5] arm64: dts: meson: convert ugoos-am6 to common w400 dtsi
commit: 3cb74db9b2561a25701b9024b9d5c0077c43e214
[2/5] dt-bindings: arm: amlogic: add support for the Beelink GT-King
commit: 3a90ef281f852db9900024116e8ea93a49115df9
[3/5] arm64: dts: meson-g12b-gtking: add initial device-tree
commit: c5522ff9c7299f9845df3fd521d51a1ef7617ac7
[4/5] dt-bindings: arm: amlogic: add support for the Beelink GT-King Pro
commit: 8d4b8772296f88e0b6bf5d091ebf25a54e51882c
[5/5] arm64: dts: meson-g12b-gtking-pro: add initial device-tree
commit: 0b928e4e412b1eb9e79e02cf3580b9254d338aae
Best regards,
--
Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* Re: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support
From: Doug Anderson @ 2020-05-20 22:48 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Ravi Kumar Bokka (Temp), Rob Herring, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rajendra Nayak, Sai Prakash Ranjan, dhavalp, mturney, sparate,
c_rbokka, mkurumel
In-Reply-To: <9864496c-b066-3fe8-5608-bd9af69663f4@linaro.org>
Hi,
On Wed, May 20, 2020 at 7:35 AM Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>
> On 18/05/2020 19:31, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, May 18, 2020 at 3:45 AM Srinivas Kandagatla
> > <srinivas.kandagatla@linaro.org> wrote:
> >>
> >> On 18/05/2020 11:39, Ravi Kumar Bokka (Temp) wrote:
> >>>
> >>> Based on the compatible, do i need to separate probe function for
> >>> qfprom-efuse and maintain separate nvmem object to register nvmem
> >>> framework. Is this what you are suggesting to implementing this in to
> >>> one existing driver?
> >>
> >> Yes for same driver we should add new compatible string and add support
> >> to this in existing qfprom driver.
> >> Ideally we should allocate nvmem_config object at probe with different
> >> parameters based on compatible string.
> >
> > I wish I had better documentation for exactly what was in the SoC
> > instead of the heavily redacted stuff Qualcomm provides. Really the
> > answer here is: how do you best describe the hardware? OK, so I just
> > spent the past hour or so trying to patch together all the bits and
> > fragments that Qualcomm provided me. Just like a scavenger hunt!
> > Fun! The best I can patch together is that there is a single QFPROM
> > with these ranges:
> >
> > 0x00780000 - 0x007800FF
> > QFPROM HW registers, range 1/2
> >
> > 0x00780120 - 0x007808FF
> > QFPROM "raw" space
> >
>
> so this is the only region is the QFPROM fuses can be programmed!
>
> > 0x00782000 - 0x007820FF
> > QFPROM HW registers, range 2/2
> >
> > 0x00784120 - 0x007848FF
> > QFPROM "corrected" space
>
> Is this some kind of FEC corrected regions?
Yes.
> > 0x00786000 - 0x00786FFF
> > QFPROM memory range that I don't really understand and maybe we don't
> > worry about right now?
>
> >
> > Did I get that right? If so, is there a prize for winning the scavenger hunt?
> >
> > ---
> >
> > If so then, IMO, it wouldn't be insane to actually keep it as two
> > drivers and two device tree nodes, as you've done. I'd defer to
> > Srinivas and Rob Herring, though. The existing driver would be a
> > read-only driver and provide access to the "corrected" versions of all
> > the registers. Its node would have "#address-cells = <1>" and
> > "#size-cells = <1>" because it's expected that other drivers might
> > need to refer to data stored here.
> >
> > Your new driver would be read-write and provide access to the "raw"
> > values. A read from your new driver would not necessarily equal a
> > read from the old driver if the FEC (forward error correction) kicked
>
> Is this only applicable for corrected address space?
I guess I was proposing a two dts-node / two drive approach here.
dts node #1:just covers the memory range for accessing the FEC-corrected data
driver #1: read-only and reads the FEC-corrected data
dts node #2: covers the memory range that's _not_ the FEC-corrected
memory range.
driver #2: read-write. reading reads uncorrected data
Does that seem sane?
> > in. Other drivers should never refer to the non-corrected values so
> > you wouldn't have "#address-cells" and "#size-cells". The only way to
> > really read or write it would be through sysfs.
> >
> > It would be super important to document what's happening, of course.
> > ...and ideally name them to make it clearer too.
> >
> > ---
> >
> > Another alternative (if Srinivas and/or Rob H prefer it) would be to
> > deprecate the old driver and/or bindings and say that there really
> > should just be one node and one driver. In that case you'd replace
> > the old node with:
> >
> > qfprom@780000 {
> > compatible = "qcom,sc7180-qfprom-efuse";
>
> May be "qcom,sc7180-qfprom"
>
>
> > reg = <0 0x00780000 0 0x6fff>;
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > clocks = <&gcc GCC_SEC_CTRL_CLK_SRC>;
> > clock-names = "sec";
> >
> > qusb2p_hstx_trim: hstx-trim-primary@25b {
> > reg = <0x25b 0x1>;
> > bits = <1 3>;
> > };
> > };
> >
> > You'd use the of_match_table solution to figure out the relevant
> > offsets (0x120, 0x2000, 0x4120, 0x6000) for sc7180 and this new driver
> > would be responsible for being able to read the corrected values and
>
>
> Encompassing these offsets in driver as part of the register defines
> itself should be a good start!
>
> It will also be nice to understand how similar this thing is with w.rt
> other Qcom SoCs?
At least sdm845 is about the same. I cross-referenced docs I had with
sc7180 and sdm845 and that's how I came up with my model for how this
works.
> > also for programming. In this case I'm not sure how (assuming it's
> > valuable) you'd provide read access to the uncorrected data.
> I will leave this question to the author of the driver.
>
> --srini
>
> >
> >
> > -Doug
> >
^ permalink raw reply
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets
From: Dan Williams @ 2020-05-20 22:36 UTC (permalink / raw)
To: Jim Quinlan
Cc: Christoph Hellwig, Nicolas Saenz Julienne, Rob Herring,
Frank Rowand, Marek Szyprowski, Robin Murphy, Greg Kroah-Hartman,
Suzuki K Poulose, Saravana Kannan, Heikki Krogerus,
Rafael J. Wysocki,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:DMA MAPPING HELPERS
In-Reply-To: <CA+-6iNzy_nELB0ptE0vH5KrGMFq4CctFKDipk3ZzXnjnT9hfuQ@mail.gmail.com>
On Wed, May 20, 2020 at 11:27 AM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> 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.
You'd be forgiven. There are some developers that are ok to go read
the thread on something like lore if they are cc'd only a subset and
some that require the whole thread copied to them. Perhaps we need an
entry in MAINTAINERS that makes this preference discoverable? To date
I have been manually keeping track of those who want full threads and
those that would prefer to just be cc'd on the cover letter and the
one patch that directly affects their maintenance area.
Certainly blindly cc'ing everyone recommended by
scripts/get_maintainers.pl is overkill, but finding that subset is a
bit of an art.
^ permalink raw reply
* Re: [PATCH v4 14/14] MAINTAINERS: Add Kishon Vijay Abraham I for TI J721E SoC PCIe
From: Rob Herring @ 2020-05-20 22:12 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: devicetree, Bjorn Helgaas, linux-kernel, linux-omap,
Arnd Bergmann, linux-pci, Rob Herring, linux-arm-kernel,
Greg Kroah-Hartman, Tom Joseph, Lorenzo Pieralisi
In-Reply-To: <20200506151429.12255-15-kishon@ti.com>
On Wed, 6 May 2020 20:44:29 +0530, Kishon Vijay Abraham I wrote:
> Add Kishon Vijay Abraham I as MAINTAINER for TI J721E SoC PCIe.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> MAINTAINERS | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 13/14] misc: pci_endpoint_test: Add J721E in pci_device_id table
From: Rob Herring @ 2020-05-20 22:12 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Rob Herring, Arnd Bergmann, Bjorn Helgaas, linux-omap,
Lorenzo Pieralisi, linux-pci, linux-arm-kernel, Tom Joseph,
devicetree, Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20200506151429.12255-14-kishon@ti.com>
On Wed, 6 May 2020 20:44:28 +0530, Kishon Vijay Abraham I wrote:
> Add J721E in pci_device_id table so that pci-epf-test can be used
> for testing PCIe EP in J721E.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/misc/pci_endpoint_test.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 03/14] PCI: cadence: Add support to use custom read and write accessors
From: Rob Herring @ 2020-05-20 22:07 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Arnd Bergmann, Tom Joseph,
Greg Kroah-Hartman, linux-pci, devicetree, linux-kernel,
linux-omap, linux-arm-kernel
In-Reply-To: <20200506151429.12255-4-kishon@ti.com>
On Wed, May 06, 2020 at 08:44:18PM +0530, Kishon Vijay Abraham I wrote:
> Add support to use custom read and write accessors. Platforms that
> don't support half word or byte access or any other constraint
> while accessing registers can use this feature to populate custom
> read and write accessors. These custom accessors are used for both
> standard register access and configuration space register access of
> the PCIe host bridge.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/controller/cadence/pcie-cadence.h | 107 +++++++++++++++---
> 1 file changed, 94 insertions(+), 13 deletions(-)
Actually, take back my R-by...
>
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
> index df14ad002fe9..70b6b25153e8 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -223,6 +223,11 @@ enum cdns_pcie_msg_routing {
> MSG_ROUTING_GATHER,
> };
>
> +struct cdns_pcie_ops {
> + u32 (*read)(void __iomem *addr, int size);
> + void (*write)(void __iomem *addr, int size, u32 value);
> +};
> +
> /**
> * struct cdns_pcie - private data for Cadence PCIe controller drivers
> * @reg_base: IO mapped register base
> @@ -239,7 +244,7 @@ struct cdns_pcie {
> int phy_count;
> struct phy **phy;
> struct device_link **link;
> - const struct cdns_pcie_common_ops *ops;
> + const struct cdns_pcie_ops *ops;
> };
>
> /**
> @@ -299,69 +304,145 @@ struct cdns_pcie_ep {
> /* Register access */
> static inline void cdns_pcie_writeb(struct cdns_pcie *pcie, u32 reg, u8 value)
> {
> - writeb(value, pcie->reg_base + reg);
> + void __iomem *addr = pcie->reg_base + reg;
> +
> + if (pcie->ops && pcie->ops->write) {
> + pcie->ops->write(addr, 0x1, value);
> + return;
> + }
> +
> + writeb(value, addr);
> }
>
> static inline void cdns_pcie_writew(struct cdns_pcie *pcie, u32 reg, u16 value)
> {
> - writew(value, pcie->reg_base + reg);
> + void __iomem *addr = pcie->reg_base + reg;
> +
> + if (pcie->ops && pcie->ops->write) {
> + pcie->ops->write(addr, 0x2, value);
> + return;
> + }
> +
> + writew(value, addr);
> }
cdns_pcie_writeb and cdns_pcie_writew are used, so remove them.
>
> static inline void cdns_pcie_writel(struct cdns_pcie *pcie, u32 reg, u32 value)
> {
> - writel(value, pcie->reg_base + reg);
> + void __iomem *addr = pcie->reg_base + reg;
> +
> + if (pcie->ops && pcie->ops->write) {
> + pcie->ops->write(addr, 0x4, value);
> + return;
> + }
> +
> + writel(value, addr);
writel isn't broken for you, so you don't need this either.
> }
>
> static inline u32 cdns_pcie_readl(struct cdns_pcie *pcie, u32 reg)
> {
> - return readl(pcie->reg_base + reg);
> + void __iomem *addr = pcie->reg_base + reg;
> +
> + if (pcie->ops && pcie->ops->read)
> + return pcie->ops->read(addr, 0x4);
> +
> + return readl(addr);
And neither is readl.
> }
>
> /* Root Port register access */
> static inline void cdns_pcie_rp_writeb(struct cdns_pcie *pcie,
> u32 reg, u8 value)
> {
> - writeb(value, pcie->reg_base + CDNS_PCIE_RP_BASE + reg);
> + void __iomem *addr = pcie->reg_base + CDNS_PCIE_RP_BASE + reg;
> +
> + if (pcie->ops && pcie->ops->write) {
> + pcie->ops->write(addr, 0x1, value);
> + return;
> + }
> +
> + writeb(value, addr);
> }
>
> static inline void cdns_pcie_rp_writew(struct cdns_pcie *pcie,
> u32 reg, u16 value)
> {
> - writew(value, pcie->reg_base + CDNS_PCIE_RP_BASE + reg);
> + void __iomem *addr = pcie->reg_base + CDNS_PCIE_RP_BASE + reg;
> +
> + if (pcie->ops && pcie->ops->write) {
> + pcie->ops->write(addr, 0x2, value);
> + return;
> + }
> +
> + writew(value, addr);
You removed 2 out of 3 calls to this. I think I'd just make the root
port writes always be 32-bit. It is all just one time init stuff
anyways.
Either rework the calls to assemble the data into 32-bits or keep these
functions and do the RMW here.
> }
>
> /* Endpoint Function register access */
> static inline void cdns_pcie_ep_fn_writeb(struct cdns_pcie *pcie, u8 fn,
> u32 reg, u8 value)
> {
> - writeb(value, pcie->reg_base + CDNS_PCIE_EP_FUNC_BASE(fn) + reg);
> + void __iomem *addr = pcie->reg_base + CDNS_PCIE_EP_FUNC_BASE(fn) + reg;
> +
> + if (pcie->ops && pcie->ops->write) {
> + pcie->ops->write(addr, 0x1, value);
> + return;
> + }
> +
> + writeb(value, addr);
Same for these EP functions.
Unless there are places where doing a RMW is fundamentally broken like
in config space (not counting the one time init stuff).
Rob
^ permalink raw reply
* Re: [PATCH] arm: dts: am33xx-bone-common: add gpio-line-names
From: Drew Fustini @ 2020-05-20 22:02 UTC (permalink / raw)
To: Linus Walleij
Cc: Grygorii Strashko, Benoît Cousson, Tony Lindgren,
Rob Herring, Linux-OMAP,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, Jason Kridner, Robert Nelson
In-Reply-To: <20200518141843.GA916914@x1>
On Mon, May 18, 2020 at 04:18:43PM +0200, Drew Fustini wrote:
> On Mon, May 18, 2020 at 09:11:07AM +0200, Linus Walleij wrote:
> > On Fri, May 8, 2020 at 6:57 PM Drew Fustini <drew@beagleboard.org> wrote:
> >
> > > Add gpio-line-names properties to the gpio controller nodes.
> > > BeagleBone boards have P8 and P9 headers [0] which expose many the
> > > AM3358 SoC balls to stacking expansion boards called "capes", or to
> > > other external connections like jumper wires to a breadboard.
> > >
> > > Many of the P8/P9 header pins can muxed to a gpio line. The
> > > gpio-line-names describe which P8/P9 pin that line goes to and the
> > > default mux for that P8/P9 pin. Some lines are not routed to the
> > > P8/P9 headers, but instead are dedicated to some functionality such as
> > > status LEDs. The line name will indicate this. Some line names are
> > > left empty as the corresponding AM3358 balls are not connected.
> > >
> > > The goal is to make it easier for a user viewing the output of gpioinfo
> > > to determine which P8/P9 pin is connected to a line. The output of
> > > gpioinfo on a BeagleBone Black will now look like this:
> > >
> > > gpiochip0 - 32 lines:
> > > line 0: "ethernet" unused input active-high
> > > line 1: "ethernet" unused input active-high
> >
> > Why are the ethernet lines not tagged with respective signal name
> > when right below the SPI lines are explicitly tagged with
> > sclk, cs0 etc?
> >
> > Ethernet is usually RGMII and has signal names like
> > tx_clk, tx_d0, tx_en etc.
>
> Thank you for the feedback, Linus.
>
> My desire is to communicate that the AM3358 balls corresponding to these
> GPIO lines are being used for Ethernet and not exposed to the P8 and P9
> expansion headers.
>
> I am happy to switch these labels to the actual Ethernet signals such as
> RGMII and MDIO signal names if you think that is better.
>
> For example, AM3358 ZCZ ball M17 is both gpio0_0 and mdio_data [0]. On
> BeagleBone, the ball is routed to the Ethernet PHY and used for MDIO [1]
> Thus gpiochio 0 line 0 is not connected to the P8 or P9 expansion header.
>
> Which of the following line name would be best?
>
> 1) "[MDIO_DATA]"
>
> precise signal name, placed in brackets to denote is not possible to
> use as GPIO on the P8 or P9 headers
>
> 2) "[ethernet]"
>
> instead of the precise signal name, just indicate that it is used for
> Ethernet and is not usable for GPIO on the P8 or P9 headers
>
> 3) ""
>
> no label as this gpio line is not connected to the P8/P9 and is
> hardwired in the PCB layout for Ethernet (MDIO).
>
> > Also some lines seem to be tagged with the pin number
> > like P9_22, P2_21 below, it seems a bit inconsistent
> > to have much information on some pins and very sketchy
> > information on some.
>
> The goal for these line names is make it easier for a BeagleBone user to
> identify which GPIO lines are connected to the P8 and P9 expansion
> headers. Our users are most likely to refer to cape-headers.png [2] as
> it is part of the bone101 out-of-the-box tutorial [3].
>
> Some GPIO lines are free to be used for GPIO in the default
> configuration. For example, gpiochip 1 line 12 is connected to P8_12
> and it is not used by another peripheral by default. I used the label:
> "P8_12 gpio"
>
> However, gpiochip 1 line 0 is connected to P8_25 but is also used by the
> on-board eMMC. The eMMc is enabled by default so this line can not be
> used for GPIO unless the user modifies the pinmux in the device tree.
>
> Thus, I used this label: "P8_25 emmc"
>
> Maybe a better label would be "P8_25 [EMMC]"?
>
> >
> > > line 18: "usb" unused input active-high
> > > line 19: "hdmi" unused input active-high
> >
> > Similar comments for these.
>
>
> These are similar to the Ethernet MDIO example above. The balls
> corresponding to these GPIO lines are not connected to the P8 or P9
> headers and are hardwired on the PCB for other peripherals like USB
> and HDMI.
>
> For example, gpiochip 0 line 18 is USB0_DRVVBUS so I simplified it to
> "usb" to indicate it can not be used for GPIO. Maybe "[USB]" is better?
>
> gpiochip 0 line 19 is AM3358 ZCZ ball A15 and the BeagleBone Black
> schematic shows that this is connected to the CEC clock for the HDMI
> framer [4]. I though "hdmi" was a nice way to summarize that this is
> used for HDMI and can not be changed, though maybe "[HDMI]" is better
> or no label at all.
>
> In conclusion, the motivation of these line names is to be a quick
> reference for a user to find GPIO lines on the P8 and P9 headers.
>
> Thanks,
> Drew
>
> [0] http://www.ti.com/lit/ds/symlink/am3358.pdf
> [1] https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#ethernet-processor-interface
> [2] http://beagleboard.org/static/images/cape-headers.png
> [3] https://beagleboard.org/Support/bone101
> [4] https://github.com/beagleboard/beaglebone-black/blob/master/BBB_SCH.pdf
>
I've posted a v2 which I hope improves the intent of the line names. [0]
I'm happy to integrate any feedback and create a v3 - especially if it
is prefered for me to list the specific peripherial signals instead of
an abstract term like "[ethernet]" or "[emmc]". This is for lines that
can not be used because they are not routed to the expansion headers.
thanks,
drew
[0] https://lore.kernel.org/linux-omap/20200520214757.GA362547@x1/T/#u
^ permalink raw reply
* [PATCH v2] arm: dts: am33xx-bone-common: add gpio-line-names
From: Drew Fustini @ 2020-05-20 21:47 UTC (permalink / raw)
To: Linus Walleij, Grygorii Strashko, Benoît Cousson,
Tony Lindgren, Rob Herring, Linux-OMAP, devicetree, linux-kernel,
Jason Kridner, Robert Nelson
Add gpio-line-names properties to the GPIO controller nodes.
BeagleBone boards have P8 and P9 headers [0] which expose many of the
AM3358 ZCZ SoC balls to stacking expansion boards called "capes", or to
other external connections like jumper wires connected to a breadboard.
BeagleBone users will often refer to the "Cape Exanpsion Headers" pin
diagram [1] as it is in the "Bone101" getting started tutorial. [2]
Most of the P8 and P9 header pins can muxed to a GPIO line. The
gpio-line-names describe which P8 or P9 pin that line goes to and the
default mux for that P8 or P9 pin if it is not GPIO.
For example, gpiochip 1 line 0 is connected to P8 header pin 25 (P8_25)
however the default device tree has the corresponding BGA ball (ZCZ U7)
muxed to mmc1_dat0 as it is used for the on-board eMMC chip. For that
GPIO line to be used, one would need to modify the device tree to
disable the eMMC and change the pin mux for that ball to GPIO mode.
Some of the AM3358 ZCZ balls corresponding to GPIO lines are not routed
to a P8 or P9 header, but are instead wired to some peripheral device
like on-board eMMC, HDMI framer IC, or status LEDs. Those names are in
brackets to denote those GPIO lines can not be used.
Some GPIO lines are named "[NC]" as the corresponding balls are not
routed to anything on the PCB.
The goal for these names is to make it easier for a user viewing the
output of gpioinfo to determine which P8 or P9 pin is connected to a
GPIO line. The output of gpioinfo on a BeagleBone Black would be:
debian@beaglebone:~$ gpioinfo
gpiochip0 - 32 lines:
line 0: "[ethernet]" unused input active-high
line 1: "[ethernet]" unused input active-high
line 2: "P9_22 [spi0_sclk]" unused input active-high
line 3: "P9_21 [spi0_d0]" unused input active-high
line 4: "P9_18 [spi0_d1]" unused input active-high
line 5: "P9_17 [spi0_cs0]" unused input active-high
line 6: "[sd card]" "cd" input active-low [used]
line 7: "P9_42A [ecappwm0]" unused input active-high
line 8: "P8_35 [hdmi]" unused input active-high
line 9: "P8_33 [hdmi]" unused input active-high
line 10: "P8_31 [hdmi]" unused input active-high
line 11: "P8_32 [hdmi]" unused input active-high
line 12: "P9_20 [i2c2_sda]" unused input active-high
line 13: "P9_19 [i2c2_scl]" unused input active-high
line 14: "P9_26 [uart1_rxd]" unused input active-high
line 15: "P9_24 [uart1_txd]" unused input active-high
line 16: "[ethernet]" unused input active-high
line 17: "[ethernet]" unused input active-high
line 18: "[usb]" unused input active-high
line 19: "[hdmi]" unused input active-high
line 20: "P9_41B" unused input active-high
line 21: "[ethernet]" unused input active-high
line 22: "P8_19 [ehrpwm2a]" unused input active-high
line 23: "P8_13 [ehrpwm2b]" unused input active-high
line 24: "[NC]" unused input active-high
line 25: "[NC]" unused input active-high
line 26: "P8_14" unused input active-high
line 27: "P8_17" unused input active-high
line 28: "[ethernet]" unused input active-high
line 29: "[ethernet]" unused input active-high
line 30: "P9_11 [uart4_rxd]" unused input active-high
line 31: "P9_13 [uart4_txd]" unused input active-high
gpiochip1 - 32 lines:
line 0: "P8_25 [emmc]" unused input active-high
line 1: "[emmc]" unused input active-high
line 2: "P8_5 [emmc]" unused input active-high
line 3: "P8_6 [emmc]" unused input active-high
line 4: "P8_23 [emmc]" unused input active-high
line 5: "P8_22 [emmc]" unused input active-high
line 6: "P8_3 [emmc]" unused input active-high
line 7: "P8_4 [emmc]" unused input active-high
line 8: "[NC]" unused input active-high
line 9: "[NC]" unused input active-high
line 10: "[NC]" unused input active-high
line 11: "[NC]" unused input active-high
line 12: "P8_12" unused input active-high
line 13: "P8_11" unused input active-high
line 14: "P8_16" unused input active-high
line 15: "P8_15" unused input active-high
line 16: "P9_15A" unused input active-high
line 17: "P9_23" unused input active-high
line 18: "P9_14 [ehrpwm1a]" unused input active-high
line 19: "P9_16 [ehrpwm1b]" unused input active-high
line 20: "[emmc]" unused input active-high
line 21: "[usr0 led]" "beaglebone:green:heartbeat" output active-high [used]
line 22: "[usr1 led]" "beaglebone:green:mmc0" output active-high [used]
line 23: "[usr2 led]" "beaglebone:green:usr2" output active-high [used]
line 24: "[usr3 led]" "beaglebone:green:usr3" output active-high [used]
line 25: "[hdmi]" "interrupt" input active-high [used]
line 26: "[usb]" unused input active-high
line 27: "[hdmi audio]" "enable" output active-high [used]
line 28: "P9_12" unused input active-high
line 29: "P8_26" unused input active-high
line 30: "P8_21 [emmc]" unused input active-high
line 31: "P8_20 [emmc]" unused input active-high
gpiochip2 - 32 lines:
line 0: "P9_15B" unused input active-high
line 1: "P8_18" unused input active-high
line 2: "P8_7" unused input active-high
line 3: "P8_8" unused input active-high
line 4: "P8_10" unused input active-high
line 5: "P8_9" unused input active-high
line 6: "P8_45 [hdmi]" unused input active-high
line 7: "P8_46 [hdmi]" unused input active-high
line 8: "P8_43 [hdmi]" unused input active-high
line 9: "P8_44 [hdmi]" unused input active-high
line 10: "P8_41 [hdmi]" unused input active-high
line 11: "P8_42 [hdmi]" unused input active-high
line 12: "P8_39 [hdmi]" unused input active-high
line 13: "P8_40 [hdmi]" unused input active-high
line 14: "P8_37 [hdmi]" unused input active-high
line 15: "P8_38 [hdmi]" unused input active-high
line 16: "P8_36 [hdmi]" unused input active-high
line 17: "P8_34 [hdmi]" unused input active-high
line 18: "[ethernet]" unused input active-high
line 19: "[ethernet]" unused input active-high
line 20: "[ethernet]" unused input active-high
line 21: "[ethernet]" unused input active-high
line 22: "P8_27 [hdmi]" unused input active-high
line 23: "P8_29 [hdmi]" unused input active-high
line 24: "P8_28 [hdmi]" unused input active-high
line 25: "P8_30 [hdmi]" unused input active-high
line 26: "[emmc]" unused input active-high
line 27: "[emmc]" unused input active-high
line 28: "[emmc]" unused input active-high
line 29: "[emmc]" unused input active-high
line 30: "[emmc]" unused input active-high
line 31: "[emmc]" unused input active-high
gpiochip3 - 32 lines:
line 0: "[ethernet]" unused input active-high
line 1: "[ethernet]" unused input active-high
line 2: "[ethernet]" unused input active-high
line 3: "[ethernet]" unused input active-high
line 4: "[ethernet]" unused input active-high
line 5: "[i2c0]" unused input active-high
line 6: "[i2c0]" unused input active-high
line 7: "[emu]" unused input active-high
line 8: "[emu]" unused input active-high
line 9: "[ethernet]" unused input active-high
line 10: "[ethernet]" unused input active-high
line 11: "[NC]" unused input active-high
line 12: "[NC]" unused input active-high
line 13: "[usb]" unused input active-high
line 14: "P9_31 [spi1_sclk]" unused input active-high
line 15: "P9_29 [spi1_d0]" unused input active-high
line 16: "P9_30 [spi1_d1]" unused input active-high
line 17: "P9_28 [spi1_cs0]" unused input active-high
line 18: "P9_42B [ecappwm0]" unused input active-high
line 19: "P9_27" unused input active-high
line 20: "P9_41A" unused input active-high
line 21: "P9_25" unused input active-high
line 22: "[NC]" unused input active-high
line 23: "[NC]" unused input active-high
line 24: "[NC]" unused input active-high
line 25: "[NC]" unused input active-high
line 26: "[NC]" unused input active-high
line 27: "[NC]" unused input active-high
line 28: "[NC]" unused input active-high
line 29: "[NC]" unused input active-high
line 30: "[NC]" unused input active-high
line 31: "[NC]" unused input active-high
[0] https://git.io/JfgOd
[1] https://beagleboard.org/capes
[1] https://beagleboard.org/Support/bone101
[2] https://beagleboard.org/static/images/cape-headers.png
Reviewed-by: Jason Kridner <jason@beagleboard.org>
Reviewed-by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Drew Fustini <drew@beagleboard.org>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 144 ++++++++++++++++++++++
1 file changed, 144 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 6c9187bc0f17..d86e67b0e852 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -397,3 +397,147 @@ &rtc {
clocks = <&clk_32768_ck>, <&clk_24mhz_clkctrl AM3_CLK_24MHZ_CLKDIV32K_CLKCTRL 0>;
clock-names = "ext-clk", "int-clk";
};
+
+&gpio0 {
+ gpio-line-names =
+ "[ethernet]",
+ "[ethernet]",
+ "P9_22 [spi0_sclk]",
+ "P9_21 [spi0_d0]",
+ "P9_18 [spi0_d1]",
+ "P9_17 [spi0_cs0]",
+ "[sd card]",
+ "P9_42A [ecappwm0]",
+ "P8_35 [hdmi]",
+ "P8_33 [hdmi]",
+ "P8_31 [hdmi]",
+ "P8_32 [hdmi]",
+ "P9_20 [i2c2_sda]",
+ "P9_19 [i2c2_scl]",
+ "P9_26 [uart1_rxd]",
+ "P9_24 [uart1_txd]",
+ "[ethernet]",
+ "[ethernet]",
+ "[usb]",
+ "[hdmi]",
+ "P9_41B",
+ "[ethernet]",
+ "P8_19 [ehrpwm2a]",
+ "P8_13 [ehrpwm2b]",
+ "[NC]",
+ "[NC]",
+ "P8_14",
+ "P8_17",
+ "[ethernet]",
+ "[ethernet]",
+ "P9_11 [uart4_rxd]",
+ "P9_13 [uart4_txd]";
+};
+
+&gpio1 {
+ gpio-line-names =
+ "P8_25 [emmc]",
+ "[emmc]",
+ "P8_5 [emmc]",
+ "P8_6 [emmc]",
+ "P8_23 [emmc]",
+ "P8_22 [emmc]",
+ "P8_3 [emmc]",
+ "P8_4 [emmc]",
+ "[NC]",
+ "[NC]",
+ "[NC]",
+ "[NC]",
+ "P8_12",
+ "P8_11",
+ "P8_16",
+ "P8_15",
+ "P9_15A",
+ "P9_23",
+ "P9_14 [ehrpwm1a]",
+ "P9_16 [ehrpwm1b]",
+ "[emmc]",
+ "[usr0 led]",
+ "[usr1 led]",
+ "[usr2 led]",
+ "[usr3 led]",
+ "[hdmi]",
+ "[usb]",
+ "[hdmi audio]",
+ "P9_12",
+ "P8_26",
+ "P8_21 [emmc]",
+ "P8_20 [emmc]";
+};
+
+&gpio2 {
+ gpio-line-names =
+ "P9_15B",
+ "P8_18",
+ "P8_7",
+ "P8_8",
+ "P8_10",
+ "P8_9",
+ "P8_45 [hdmi]",
+ "P8_46 [hdmi]",
+ "P8_43 [hdmi]",
+ "P8_44 [hdmi]",
+ "P8_41 [hdmi]",
+ "P8_42 [hdmi]",
+ "P8_39 [hdmi]",
+ "P8_40 [hdmi]",
+ "P8_37 [hdmi]",
+ "P8_38 [hdmi]",
+ "P8_36 [hdmi]",
+ "P8_34 [hdmi]",
+ "[ethernet]",
+ "[ethernet]",
+ "[ethernet]",
+ "[ethernet]",
+ "P8_27 [hdmi]",
+ "P8_29 [hdmi]",
+ "P8_28 [hdmi]",
+ "P8_30 [hdmi]",
+ "[emmc]",
+ "[emmc]",
+ "[emmc]",
+ "[emmc]",
+ "[emmc]",
+ "[emmc]";
+};
+
+&gpio3 {
+ gpio-line-names =
+ "[ethernet]",
+ "[ethernet]",
+ "[ethernet]",
+ "[ethernet]",
+ "[ethernet]",
+ "[i2c0]",
+ "[i2c0]",
+ "[emu]",
+ "[emu]",
+ "[ethernet]",
+ "[ethernet]",
+ "[NC]",
+ "[NC]",
+ "[usb]",
+ "P9_31 [spi1_sclk]",
+ "P9_29 [spi1_d0]",
+ "P9_30 [spi1_d1]",
+ "P9_28 [spi1_cs0]",
+ "P9_42B [ecappwm0]",
+ "P9_27",
+ "P9_41A",
+ "P9_25",
+ "[NC]",
+ "[NC]",
+ "[NC]",
+ "[NC]",
+ "[NC]",
+ "[NC]",
+ "[NC]",
+ "[NC]",
+ "[NC]",
+ "[NC]";
+};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 08/14] PCI: cadence: Fix updating Vendor ID and Subsystem Vendor ID register
From: Rob Herring @ 2020-05-20 21:36 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Arnd Bergmann, Tom Joseph,
Greg Kroah-Hartman, linux-pci, devicetree, linux-kernel,
linux-omap, linux-arm-kernel
In-Reply-To: <20200506151429.12255-9-kishon@ti.com>
On Wed, May 06, 2020 at 08:44:23PM +0530, Kishon Vijay Abraham I wrote:
> Commit 1b79c5284439 ("PCI: cadence: Add host driver for Cadence PCIe
> controller") in order to update Vendor ID, directly wrote to
> PCI_VENDOR_ID register. However PCI_VENDOR_ID in root port configuration
> space is read-only register and writing to it will have no effect.
> Use local management register to configure Vendor ID and Subsystem Vendor
> ID.
>
> Fixes: 1b79c5284439 ("PCI: cadence: Add host driver for Cadence PCIe controller")
Fixes should come first.
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/controller/cadence/pcie-cadence-host.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 07/14] PCI: cadence: Add new *ops* for CPU addr fixup
From: Rob Herring @ 2020-05-20 21:34 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Arnd Bergmann, Tom Joseph,
Greg Kroah-Hartman, linux-pci, devicetree, linux-kernel,
linux-omap, linux-arm-kernel
In-Reply-To: <20200506151429.12255-8-kishon@ti.com>
On Wed, May 06, 2020 at 08:44:22PM +0530, Kishon Vijay Abraham I wrote:
> Cadence driver uses "mem" memory resource to obtain the offset of
> configuration space address region, memory space address region and
> message space address region. The obtained offset is used to program
> the Address Translation Unit (ATU). However certain platforms like TI's
> J721E SoC require the absolute address to be programmed in the ATU and not
> just the offset.
Once again, Cadence host binding is broken (or at least the example is).
The 'mem' region shouldn't even exist. It is overlapping the config
space and 'ranges':
reg = <0x0 0xfb000000 0x0 0x01000000>,
<0x0 0x41000000 0x0 0x00001000>,
<0x0 0x40000000 0x0 0x04000000>;
reg-names = "reg", "cfg", "mem";
ranges = <0x02000000 0x0 0x42000000 0x0 0x42000000 0x0 0x1000000>,
<0x01000000 0x0 0x43000000 0x0 0x43000000 0x0 0x0010000>;
16M of registers looks a bit odd. I guess it doesn't matter
unless you have a 32-bit platform and care about your virtual
space. Probably should have been 3 regions for LM, RP, and AT looking
at the driver.
Whatever outbound address translation you need should be based on
'ranges'.
Rob
^ permalink raw reply
* Re: [PATCH v4 06/11] net: ethernet: mtk-eth-mac: new driver
From: Arnd Bergmann @ 2020-05-20 21:22 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Stephane Le Provost, Pedro Tsai, Andrew Perepech, 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: <CAMRc=MeuQk9rFDFGWK0ijsiM-r296cVz9Rth8hWhW5Aeeti_cA@mail.gmail.com>
On Wed, May 20, 2020 at 7:35 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> śr., 20 maj 2020 o 16:37 Arnd Bergmann <arnd@arndb.de> napisał(a):
> > 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?
Both seem fine to me. If this was previously discussed, I don't want
do further bike-shedding and I'd trust you to pick a sensible name
based on the earlier discussions.
> > + /* 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.
Right, I see. If you just ack at the end of the poll function, you need
to check the rings again to ensure you did not miss an interrupt
between checking observing both rings to be empty and the irq-ack.
I suspect it's still cheaper to check the two rings with an uncached
read from memory than to to do the read-modify-write on the mmio,
but you'd have to measure that to be sure.
> > > +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.
Ok, he's probably right then.
My idea was that the dma_unmap operation for the tx cleanup is
rather expensive on chips without cache-coherent DMA, so you
might not want to do too much of it but rather do it in reasonably
sized batches. It would also avoid the case where you renable the
tx-complete interrupt after cleaning the already-sent frames but
then immediately get an irq when the next frame that is already
queued is done.
This probably depends on the specific workload which one works
better here.
Arnd
^ permalink raw reply
* [PATCHv2 0/6] Add initial genpd support for omap PRM driver
From: Tony Lindgren @ 2020-05-20 21:13 UTC (permalink / raw)
To: linux-omap
Cc: Andrew F . Davis, Santosh Shilimkar, Suman Anna, Tero Kristo,
linux-kernel, linux-arm-kernel, Rob Herring, devicetree
Hi all,
Heris v2 set of patches to add genpd support to the PRM (Power and Reset
Module) driver.
Initially we just add one hardware accelerator power domain for sgx,
and one interconnect instance for l4_abe. The rest of the SoC specific
domain data is probably best added one SoC at a time based on generated
data.
Regards,
Tony
Changes since v1:
- Dropped clocks from the binding and prm driver as there's no need
for them as pointed out by Tero
- Add checking for domain transition bit in pwrstst register as
pointed out by Tero
- Add omap_prm_domain_show_state() for CONFIG_DEBUG
Tony Lindgren (6):
dt-bindings: omap: Update PRM binding for genpd
soc: ti: omap-prm: Add basic power domain support
soc: ti: omap-prm: Configure sgx power domain for am3 and am4
soc: ti: omap-prm: Configure omap4 and 5 l4_abe power domain
ARM: dts: Configure am3 and am4 sgx for genpd and drop platform data
ARM: dts: Configure omap4 and 5 l4_abe for genpd and drop platform
data
.../devicetree/bindings/arm/omap/prm-inst.txt | 2 +
arch/arm/boot/dts/am33xx.dtsi | 2 +
arch/arm/boot/dts/am4372.dtsi | 2 +
arch/arm/boot/dts/omap4-l4-abe.dtsi | 6 +-
arch/arm/boot/dts/omap4.dtsi | 6 +
arch/arm/boot/dts/omap5-l4-abe.dtsi | 6 +-
arch/arm/boot/dts/omap5.dtsi | 6 +
arch/arm/mach-omap2/Kconfig | 1 +
.../omap_hwmod_33xx_43xx_interconnect_data.c | 16 -
.../omap_hwmod_33xx_43xx_ipblock_data.c | 40 ---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 -
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 2 -
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 33 --
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 31 --
drivers/soc/ti/omap_prm.c | 281 +++++++++++++++++-
15 files changed, 305 insertions(+), 131 deletions(-)
--
2.26.2
^ permalink raw reply
* [PATCH 3/6] soc: ti: omap-prm: Configure sgx power domain for am3 and am4
From: Tony Lindgren @ 2020-05-20 21:13 UTC (permalink / raw)
To: linux-omap
Cc: Andrew F . Davis, Santosh Shilimkar, Suman Anna, Tero Kristo,
linux-kernel, linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <20200520211334.61814-1-tony@atomide.com>
Let's configure only sgx power domain for am3 and am4 to start with.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/soc/ti/omap_prm.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -186,7 +186,11 @@ static const struct omap_prm_data am3_prm_data[] = {
{ .name = "per", .base = 0x44e00c00, .rstctrl = 0x0, .rstmap = am3_per_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL, .clkdm_name = "pruss_ocp" },
{ .name = "wkup", .base = 0x44e00d00, .rstctrl = 0x0, .rstst = 0xc, .rstmap = am3_wkup_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
{ .name = "device", .base = 0x44e00f00, .rstctrl = 0x0, .rstst = 0x8, .rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
- { .name = "gfx", .base = 0x44e01100, .rstctrl = 0x4, .rstst = 0x14, .rstmap = rst_map_0, .clkdm_name = "gfx_l3" },
+ {
+ .name = "gfx", .base = 0x44e01100,
+ .pwrstctrl = 0, .pwrstst = 0x10, .dmap = &omap_prm_noinact,
+ .rstctrl = 0x4, .rstst = 0x14, .rstmap = rst_map_0, .clkdm_name = "gfx_l3",
+ },
{ },
};
@@ -202,7 +206,11 @@ static const struct omap_rst_map am4_device_rst_map[] = {
};
static const struct omap_prm_data am4_prm_data[] = {
- { .name = "gfx", .base = 0x44df0400, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_0, .clkdm_name = "gfx_l3" },
+ {
+ .name = "gfx", .base = 0x44df0400,
+ .pwrstctrl = 0, .pwrstst = 0x4, .dmap = &omap_prm_onoff_noauto,
+ .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_0, .clkdm_name = "gfx_l3",
+ },
{ .name = "per", .base = 0x44df0800, .rstctrl = 0x10, .rstst = 0x14, .rstmap = am4_per_rst_map, .clkdm_name = "pruss_ocp" },
{ .name = "wkup", .base = 0x44df2000, .rstctrl = 0x10, .rstst = 0x14, .rstmap = am3_wkup_rst_map, .flags = OMAP_PRM_HAS_NO_CLKDM },
{ .name = "device", .base = 0x44df4000, .rstctrl = 0x0, .rstst = 0x4, .rstmap = am4_device_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
--
2.26.2
^ permalink raw reply
* [PATCH 5/6] ARM: dts: Configure am3 and am4 sgx for genpd and drop platform data
From: Tony Lindgren @ 2020-05-20 21:13 UTC (permalink / raw)
To: linux-omap
Cc: Andrew F . Davis, Santosh Shilimkar, Suman Anna, Tero Kristo,
linux-kernel, linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <20200520211334.61814-1-tony@atomide.com>
We can power off the SGX power domain when not in use when we configure
it for genpd. And with that change, we can now also drop the old unused
legacy platform data.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/am33xx.dtsi | 2 +
arch/arm/boot/dts/am4372.dtsi | 2 +
.../omap_hwmod_33xx_43xx_interconnect_data.c | 16 --------
.../omap_hwmod_33xx_43xx_ipblock_data.c | 40 -------------------
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 -
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 2 -
6 files changed, 4 insertions(+), 60 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -577,6 +577,7 @@ target-module@56000000 {
<SYSC_IDLE_SMART>;
clocks = <&gfx_l3_clkctrl AM3_GFX_L3_GFX_CLKCTRL 0>;
clock-names = "fck";
+ power-domains = <&prm_gfx>;
resets = <&prm_gfx 0>;
reset-names = "rstctrl";
#address-cells = <1>;
@@ -616,6 +617,7 @@ prm_device: prm@f00 {
prm_gfx: prm@1100 {
compatible = "ti,am3-prm-inst", "ti,omap-prm-inst";
reg = <0x1100 0x100>;
+ #power-domain-cells = <0>;
#reset-cells = <1>;
};
};
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -516,6 +516,7 @@ target-module@56000000 {
<SYSC_IDLE_SMART>;
clocks = <&gfx_l3_clkctrl AM4_GFX_L3_GFX_CLKCTRL 0>;
clock-names = "fck";
+ power-domains = <&prm_gfx>;
resets = <&prm_gfx 0>;
reset-names = "rstctrl";
#address-cells = <1>;
@@ -532,6 +533,7 @@ &prcm {
prm_gfx: prm@400 {
compatible = "ti,am4-prm-inst", "ti,omap-prm-inst";
reg = <0x400 0x100>;
+ #power-domain-cells = <0>;
#reset-cells = <1>;
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -74,22 +74,6 @@ struct omap_hwmod_ocp_if am33xx_l3_s__l3_main = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* gfx -> l3 main */
-struct omap_hwmod_ocp_if am33xx_gfx__l3_main = {
- .master = &am33xx_gfx_hwmod,
- .slave = &am33xx_l3_main_hwmod,
- .clk = "dpll_core_m4_ck",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* l3 main -> gfx */
-struct omap_hwmod_ocp_if am33xx_l3_main__gfx = {
- .master = &am33xx_l3_main_hwmod,
- .slave = &am33xx_gfx_hwmod,
- .clk = "dpll_core_m4_ck",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
/* l4 wkup -> rtc */
struct omap_hwmod_ocp_if am33xx_l4_wkup__rtc = {
.master = &am33xx_l4_wkup_hwmod,
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -133,30 +133,6 @@ struct omap_hwmod_class am33xx_wkup_m3_hwmod_class = {
.name = "wkup_m3",
};
-/* gfx */
-/* Pseudo hwmod for reset control purpose only */
-static struct omap_hwmod_class am33xx_gfx_hwmod_class = {
- .name = "gfx",
-};
-
-static struct omap_hwmod_rst_info am33xx_gfx_resets[] = {
- { .name = "gfx", .rst_shift = 0, .st_shift = 0},
-};
-
-struct omap_hwmod am33xx_gfx_hwmod = {
- .name = "gfx",
- .class = &am33xx_gfx_hwmod_class,
- .clkdm_name = "gfx_l3_clkdm",
- .main_clk = "gfx_fck_div_ck",
- .prcm = {
- .omap4 = {
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
- .rst_lines = am33xx_gfx_resets,
- .rst_lines_cnt = ARRAY_SIZE(am33xx_gfx_resets),
-};
-
/*
* 'prcm' class
* power and reset manager (whole prcm infrastructure)
@@ -379,22 +355,14 @@ static void omap_hwmod_am33xx_clkctrl(void)
CLKCTRL(am33xx_l4_ls_hwmod, AM33XX_CM_PER_L4LS_CLKCTRL_OFFSET);
CLKCTRL(am33xx_l4_wkup_hwmod, AM33XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET);
CLKCTRL(am33xx_l3_main_hwmod, AM33XX_CM_PER_L3_CLKCTRL_OFFSET);
- CLKCTRL(am33xx_gfx_hwmod, AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET);
CLKCTRL(am33xx_mpu_hwmod , AM33XX_CM_MPU_MPU_CLKCTRL_OFFSET);
CLKCTRL(am33xx_l3_instr_hwmod , AM33XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET);
CLKCTRL(am33xx_ocmcram_hwmod , AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET);
}
-static void omap_hwmod_am33xx_rst(void)
-{
- RSTCTRL(am33xx_gfx_hwmod, AM33XX_RM_GFX_RSTCTRL_OFFSET);
- RSTST(am33xx_gfx_hwmod, AM33XX_RM_GFX_RSTST_OFFSET);
-}
-
void omap_hwmod_am33xx_reg(void)
{
omap_hwmod_am33xx_clkctrl();
- omap_hwmod_am33xx_rst();
}
static void omap_hwmod_am43xx_clkctrl(void)
@@ -410,20 +378,12 @@ static void omap_hwmod_am43xx_clkctrl(void)
CLKCTRL(am33xx_l4_ls_hwmod, AM43XX_CM_PER_L4LS_CLKCTRL_OFFSET);
CLKCTRL(am33xx_l4_wkup_hwmod, AM43XX_CM_WKUP_L4WKUP_CLKCTRL_OFFSET);
CLKCTRL(am33xx_l3_main_hwmod, AM43XX_CM_PER_L3_CLKCTRL_OFFSET);
- CLKCTRL(am33xx_gfx_hwmod, AM43XX_CM_GFX_GFX_CLKCTRL_OFFSET);
CLKCTRL(am33xx_mpu_hwmod , AM43XX_CM_MPU_MPU_CLKCTRL_OFFSET);
CLKCTRL(am33xx_l3_instr_hwmod , AM43XX_CM_PER_L3_INSTR_CLKCTRL_OFFSET);
CLKCTRL(am33xx_ocmcram_hwmod , AM43XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET);
}
-static void omap_hwmod_am43xx_rst(void)
-{
- RSTCTRL(am33xx_gfx_hwmod, AM43XX_RM_GFX_RSTCTRL_OFFSET);
- RSTST(am33xx_gfx_hwmod, AM43XX_RM_GFX_RSTST_OFFSET);
-}
-
void omap_hwmod_am43xx_reg(void)
{
omap_hwmod_am43xx_clkctrl();
- omap_hwmod_am43xx_rst();
}
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -282,10 +282,8 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
&am33xx_l3_main__l4_hs,
&am33xx_l3_main__l3_s,
&am33xx_l3_main__l3_instr,
- &am33xx_l3_main__gfx,
&am33xx_l3_s__l3_main,
&am33xx_wkup_m3__l4_wkup,
- &am33xx_gfx__l3_main,
&am33xx_l3_main__debugss,
&am33xx_l4_wkup__wkup_m3,
&am33xx_l4_wkup__control,
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -243,11 +243,9 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
&am43xx_l3_main__l4_hs,
&am33xx_l3_main__l3_s,
&am33xx_l3_main__l3_instr,
- &am33xx_l3_main__gfx,
&am33xx_l3_s__l3_main,
&am43xx_l3_main__emif,
&am43xx_wkup_m3__l4_wkup,
- &am33xx_gfx__l3_main,
&am43xx_l4_wkup__wkup_m3,
&am43xx_l4_wkup__control,
&am43xx_l4_wkup__smartreflex0,
--
2.26.2
^ permalink raw reply
* [PATCH 6/6] ARM: dts: Configure omap4 and 5 l4_abe for genpd and drop platform data
From: Tony Lindgren @ 2020-05-20 21:13 UTC (permalink / raw)
To: linux-omap
Cc: Andrew F . Davis, Santosh Shilimkar, Suman Anna, Tero Kristo,
linux-kernel, linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <20200520211334.61814-1-tony@atomide.com>
We can power off l4_abe domain when not in use when we configure it for
genpd. And with that change, we can now also drop the old unused legacy
platform data.
Note that we also need to now use "simple-pm-bus" instead of "simple-bus"
for PM runtime to get enabled for the bus.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap4-l4-abe.dtsi | 6 ++--
arch/arm/boot/dts/omap4.dtsi | 6 ++++
arch/arm/boot/dts/omap5-l4-abe.dtsi | 6 ++--
arch/arm/boot/dts/omap5.dtsi | 6 ++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 33 ----------------------
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 31 --------------------
6 files changed, 20 insertions(+), 68 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-l4-abe.dtsi b/arch/arm/boot/dts/omap4-l4-abe.dtsi
--- a/arch/arm/boot/dts/omap4-l4-abe.dtsi
+++ b/arch/arm/boot/dts/omap4-l4-abe.dtsi
@@ -1,14 +1,16 @@
&l4_abe { /* 0x40100000 */
- compatible = "ti,omap4-l4-abe", "simple-bus";
+ compatible = "ti,omap4-l4-abe", "simple-pm-bus";
reg = <0x40100000 0x400>,
<0x40100400 0x400>;
reg-names = "la", "ap";
+ power-domains = <&prm_abe>;
+ /* OMAP4_L4_ABE_CLKCTRL is read-only */
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x40100000 0x100000>, /* segment 0 */
<0x49000000 0x49000000 0x100000>;
segment@0 { /* 0x40100000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges =
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -637,6 +637,12 @@ prm_tesla: prm@400 {
#reset-cells = <1>;
};
+ prm_abe: prm@500 {
+ compatible = "ti,omap4-prm-inst", "ti,omap-prm-inst";
+ reg = <0x500 0x100>;
+ #power-domain-cells = <0>;
+ };
+
prm_core: prm@700 {
compatible = "ti,omap4-prm-inst", "ti,omap-prm-inst";
reg = <0x700 0x100>;
diff --git a/arch/arm/boot/dts/omap5-l4-abe.dtsi b/arch/arm/boot/dts/omap5-l4-abe.dtsi
--- a/arch/arm/boot/dts/omap5-l4-abe.dtsi
+++ b/arch/arm/boot/dts/omap5-l4-abe.dtsi
@@ -1,14 +1,16 @@
&l4_abe { /* 0x40100000 */
- compatible = "ti,omap5-l4-abe", "simple-bus";
+ compatible = "ti,omap5-l4-abe", "simple-pm-bus";
reg = <0x40100000 0x400>,
<0x40100400 0x400>;
reg-names = "la", "ap";
+ power-domains = <&prm_abe>;
+ /* OMAP5_L4_ABE_CLKCTRL is read-only */
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x00000000 0x40100000 0x100000>, /* segment 0 */
<0x49000000 0x49000000 0x100000>;
segment@0 { /* 0x40100000 */
- compatible = "simple-bus";
+ compatible = "simple-pm-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges =
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -563,6 +563,12 @@ prm_dsp: prm@400 {
#reset-cells = <1>;
};
+ prm_abe: prm@500 {
+ compatible = "ti,omap5-prm-inst", "ti,omap-prm-inst";
+ reg = <0x500 0x100>;
+ #power-domain-cells = <0>;
+ };
+
prm_core: prm@700 {
compatible = "ti,omap5-prm-inst", "ti,omap-prm-inst";
reg = <0x700 0x100>;
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -124,21 +124,6 @@ static struct omap_hwmod_class omap44xx_l4_hwmod_class = {
.name = "l4",
};
-/* l4_abe */
-static struct omap_hwmod omap44xx_l4_abe_hwmod = {
- .name = "l4_abe",
- .class = &omap44xx_l4_hwmod_class,
- .clkdm_name = "abe_clkdm",
- .prcm = {
- .omap4 = {
- .clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
- .context_offs = OMAP4_RM_ABE_AESS_CONTEXT_OFFSET,
- .lostcontext_mask = OMAP4430_LOSTMEM_AESSMEM_MASK,
- .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
- },
- },
-};
-
/* l4_cfg */
static struct omap_hwmod omap44xx_l4_cfg_hwmod = {
.name = "l4_cfg",
@@ -1007,22 +992,6 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* l3_main_1 -> l4_abe */
-static struct omap_hwmod_ocp_if omap44xx_l3_main_1__l4_abe = {
- .master = &omap44xx_l3_main_1_hwmod,
- .slave = &omap44xx_l4_abe_hwmod,
- .clk = "l3_div_ck",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* mpu -> l4_abe */
-static struct omap_hwmod_ocp_if omap44xx_mpu__l4_abe = {
- .master = &omap44xx_mpu_hwmod,
- .slave = &omap44xx_l4_abe_hwmod,
- .clk = "ocp_abe_iclk",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
/* l3_main_1 -> l4_cfg */
static struct omap_hwmod_ocp_if omap44xx_l3_main_1__l4_cfg = {
.master = &omap44xx_l3_main_1_hwmod,
@@ -1266,8 +1235,6 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] __initdata = {
&omap44xx_l3_main_1__l3_main_3,
&omap44xx_l3_main_2__l3_main_3,
&omap44xx_l4_cfg__l3_main_3,
- &omap44xx_l3_main_1__l4_abe,
- &omap44xx_mpu__l4_abe,
&omap44xx_l3_main_1__l4_cfg,
&omap44xx_l3_main_2__l4_per,
&omap44xx_l4_cfg__l4_wkup,
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -121,19 +121,6 @@ static struct omap_hwmod_class omap54xx_l4_hwmod_class = {
.name = "l4",
};
-/* l4_abe */
-static struct omap_hwmod omap54xx_l4_abe_hwmod = {
- .name = "l4_abe",
- .class = &omap54xx_l4_hwmod_class,
- .clkdm_name = "abe_clkdm",
- .prcm = {
- .omap4 = {
- .clkctrl_offs = OMAP54XX_CM_ABE_L4_ABE_CLKCTRL_OFFSET,
- .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
- },
- },
-};
-
/* l4_cfg */
static struct omap_hwmod omap54xx_l4_cfg_hwmod = {
.name = "l4_cfg",
@@ -618,22 +605,6 @@ static struct omap_hwmod_ocp_if omap54xx_l4_cfg__l3_main_3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* l3_main_1 -> l4_abe */
-static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l4_abe = {
- .master = &omap54xx_l3_main_1_hwmod,
- .slave = &omap54xx_l4_abe_hwmod,
- .clk = "abe_iclk",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
-/* mpu -> l4_abe */
-static struct omap_hwmod_ocp_if omap54xx_mpu__l4_abe = {
- .master = &omap54xx_mpu_hwmod,
- .slave = &omap54xx_l4_abe_hwmod,
- .clk = "abe_iclk",
- .user = OCP_USER_MPU | OCP_USER_SDMA,
-};
-
/* l3_main_1 -> l4_cfg */
static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l4_cfg = {
.master = &omap54xx_l3_main_1_hwmod,
@@ -741,8 +712,6 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = {
&omap54xx_l3_main_1__l3_main_3,
&omap54xx_l3_main_2__l3_main_3,
&omap54xx_l4_cfg__l3_main_3,
- &omap54xx_l3_main_1__l4_abe,
- &omap54xx_mpu__l4_abe,
&omap54xx_l3_main_1__l4_cfg,
&omap54xx_l3_main_2__l4_per,
&omap54xx_l3_main_1__l4_wkup,
--
2.26.2
^ permalink raw reply
* [PATCH 4/6] soc: ti: omap-prm: Configure omap4 and 5 l4_abe power domain
From: Tony Lindgren @ 2020-05-20 21:13 UTC (permalink / raw)
To: linux-omap
Cc: Andrew F . Davis, Santosh Shilimkar, Suman Anna, Tero Kristo,
linux-kernel, linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <20200520211334.61814-1-tony@atomide.com>
Let's add omap4 and 5 l4_abe interconnect instance for the power
domain.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/soc/ti/omap_prm.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -145,6 +145,10 @@ static const struct omap_rst_map rst_map_012[] = {
static const struct omap_prm_data omap4_prm_data[] = {
{ .name = "tesla", .base = 0x4a306400, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ {
+ .name = "abe", .base = 0x4a306500,
+ .pwrstctrl = 0, .pwrstst = 0x4, .dmap = &omap_prm_all,
+ },
{ .name = "core", .base = 0x4a306700, .rstctrl = 0x210, .rstst = 0x214, .clkdm_name = "ducati", .rstmap = rst_map_012 },
{ .name = "ivahd", .base = 0x4a306f00, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_012 },
{ .name = "device", .base = 0x4a307b00, .rstctrl = 0x0, .rstst = 0x4, .rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
@@ -153,6 +157,10 @@ static const struct omap_prm_data omap4_prm_data[] = {
static const struct omap_prm_data omap5_prm_data[] = {
{ .name = "dsp", .base = 0x4ae06400, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ {
+ .name = "abe", .base = 0x4ae06500,
+ .pwrstctrl = 0, .pwrstst = 0x4, .dmap = &omap_prm_nooff,
+ },
{ .name = "core", .base = 0x4ae06700, .rstctrl = 0x210, .rstst = 0x214, .clkdm_name = "ipu", .rstmap = rst_map_012 },
{ .name = "iva", .base = 0x4ae07200, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_012 },
{ .name = "device", .base = 0x4ae07c00, .rstctrl = 0x0, .rstst = 0x4, .rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
--
2.26.2
^ permalink raw reply
* [PATCH 2/6] soc: ti: omap-prm: Add basic power domain support
From: Tony Lindgren @ 2020-05-20 21:13 UTC (permalink / raw)
To: linux-omap
Cc: Andrew F . Davis, Santosh Shilimkar, Suman Anna, Tero Kristo,
linux-kernel, linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <20200520211334.61814-1-tony@atomide.com>
The PRM controller has currently only support for resets while the power
domains are still handled in the platform code.
Let's add basic power domain support to enable and disable a PRM
controlled power domain if configured in the devicetree. This can be
used for various hardware accelerators, and interconnect instances.
Further support can be added later on as needed for runtime configuration
based on domain-idle-states.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
drivers/soc/ti/omap_prm.c | 261 +++++++++++++++++++++++++++++++++++-
2 files changed, 261 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -7,6 +7,7 @@ config ARCH_OMAP2
depends on ARCH_MULTI_V6
select ARCH_OMAP2PLUS
select CPU_V6
+ select PM_GENERIC_DOMAINS if PM
select SOC_HAS_OMAP2_SDRC
config ARCH_OMAP3
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -10,14 +10,39 @@
#include <linux/device.h>
#include <linux/io.h>
#include <linux/iopoll.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
#include <linux/reset-controller.h>
#include <linux/delay.h>
#include <linux/platform_data/ti-prm.h>
+enum omap_prm_domain_mode {
+ OMAP_PRMD_OFF,
+ OMAP_PRMD_RETENTION,
+ OMAP_PRMD_ON_INACTIVE,
+ OMAP_PRMD_ON_ACTIVE,
+};
+
+struct omap_prm_domain_map {
+ unsigned int usable_modes; /* Mask of hardware supported modes */
+ unsigned long statechange:1; /* Optional low-power state change */
+ unsigned long logicretstate:1; /* Optional logic off mode */
+};
+
+struct omap_prm_domain {
+ struct device *dev;
+ struct omap_prm *prm;
+ struct generic_pm_domain pd;
+ u16 pwrstctrl;
+ u16 pwrstst;
+ const struct omap_prm_domain_map *cap;
+ u32 pwrstctrl_saved;
+};
+
struct omap_rst_map {
s8 rst;
s8 st;
@@ -27,6 +52,9 @@ struct omap_prm_data {
u32 base;
const char *name;
const char *clkdm_name;
+ u16 pwrstctrl;
+ u16 pwrstst;
+ const struct omap_prm_domain_map *dmap;
u16 rstctrl;
u16 rstst;
const struct omap_rst_map *rstmap;
@@ -36,6 +64,7 @@ struct omap_prm_data {
struct omap_prm {
const struct omap_prm_data *data;
void __iomem *base;
+ struct omap_prm_domain *prmd;
};
struct omap_reset_data {
@@ -47,6 +76,7 @@ struct omap_reset_data {
struct device *dev;
};
+#define genpd_to_prm_domain(gpd) container_of(gpd, struct omap_prm_domain, pd)
#define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
#define OMAP_MAX_RESETS 8
@@ -58,6 +88,43 @@ struct omap_reset_data {
#define OMAP_PRM_HAS_RESETS (OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_RSTST)
+#define PRM_STATE_MAX_WAIT 10000
+#define PRM_LOGICRETSTATE BIT(2)
+#define PRM_LOWPOWERSTATECHANGE BIT(4)
+#define PRM_POWERSTATE_MASK OMAP_PRMD_ON_ACTIVE
+
+#define PRM_ST_INTRANSITION BIT(20)
+
+static const struct __maybe_unused
+omap_prm_domain_map omap_prm_all = {
+ .usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_ON_INACTIVE) |
+ BIT(OMAP_PRMD_RETENTION) | BIT(OMAP_PRMD_OFF),
+ .statechange = 1,
+ .logicretstate = 1,
+};
+
+static const struct __maybe_unused
+omap_prm_domain_map omap_prm_noinact = {
+ .usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_RETENTION) |
+ BIT(OMAP_PRMD_OFF),
+ .statechange = 1,
+ .logicretstate = 1,
+};
+
+static const struct __maybe_unused
+omap_prm_domain_map omap_prm_nooff = {
+ .usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_ON_INACTIVE) |
+ BIT(OMAP_PRMD_RETENTION),
+ .statechange = 1,
+ .logicretstate = 1,
+};
+
+static const struct __maybe_unused
+omap_prm_domain_map omap_prm_onoff_noauto = {
+ .usable_modes = BIT(OMAP_PRMD_ON_ACTIVE) | BIT(OMAP_PRMD_OFF),
+ .statechange = 1,
+};
+
static const struct omap_rst_map rst_map_0[] = {
{ .rst = 0, .st = 0 },
{ .rst = -1 },
@@ -151,6 +218,183 @@ static const struct of_device_id omap_prm_id_table[] = {
{ },
};
+#ifdef DEBUG
+static void omap_prm_domain_show_state(struct omap_prm_domain *prmd,
+ const char *desc)
+{
+ dev_dbg(prmd->dev, "%s %s: %08x/%08x\n",
+ prmd->pd.name, desc,
+ readl_relaxed(prmd->prm->base + prmd->pwrstctrl),
+ readl_relaxed(prmd->prm->base + prmd->pwrstst));
+}
+#else
+static inline void omap_prm_domain_show_state(struct omap_prm_domain *prmd,
+ const char *desc)
+{
+}
+#endif
+
+static int omap_prm_domain_power_on(struct generic_pm_domain *domain)
+{
+ struct omap_prm_domain *prmd;
+ int ret;
+ u32 v;
+
+ prmd = genpd_to_prm_domain(domain);
+ if (!prmd->cap)
+ return 0;
+
+ omap_prm_domain_show_state(prmd, "on: previous state");
+
+ if (prmd->pwrstctrl_saved)
+ v = prmd->pwrstctrl_saved;
+ else
+ v = readl_relaxed(prmd->prm->base + prmd->pwrstctrl);
+
+ writel_relaxed(v | OMAP_PRMD_ON_ACTIVE,
+ prmd->prm->base + prmd->pwrstctrl);
+
+ /* wait for the transition bit to get cleared */
+ ret = readl_relaxed_poll_timeout(prmd->prm->base + prmd->pwrstst,
+ v, !(v & PRM_ST_INTRANSITION), 1,
+ PRM_STATE_MAX_WAIT);
+ if (ret)
+ dev_err(prmd->dev, "%s: %s timed out\n",
+ prmd->pd.name, __func__);
+
+ omap_prm_domain_show_state(prmd, "on: new state");
+
+ return ret;
+}
+
+/* No need to check for holes in the mask for the lowest mode */
+static int omap_prm_domain_find_lowest(struct omap_prm_domain *prmd)
+{
+ return __ffs(prmd->cap->usable_modes);
+}
+
+static int omap_prm_domain_power_off(struct generic_pm_domain *domain)
+{
+ struct omap_prm_domain *prmd;
+ int ret;
+ u32 v;
+
+ prmd = genpd_to_prm_domain(domain);
+ if (!prmd->cap)
+ return 0;
+
+ omap_prm_domain_show_state(prmd, "off: previous state");
+
+ v = readl_relaxed(prmd->prm->base + prmd->pwrstctrl);
+ prmd->pwrstctrl_saved = v;
+
+ v &= ~PRM_POWERSTATE_MASK;
+ v |= omap_prm_domain_find_lowest(prmd);
+
+ if (prmd->cap->statechange)
+ v |= PRM_LOWPOWERSTATECHANGE;
+ if (prmd->cap->logicretstate)
+ v &= ~PRM_LOGICRETSTATE;
+ else
+ v |= PRM_LOGICRETSTATE;
+
+ writel_relaxed(v, prmd->prm->base + prmd->pwrstctrl);
+
+ /* wait for the transition bit to get cleared */
+ ret = readl_relaxed_poll_timeout(prmd->prm->base + prmd->pwrstst,
+ v, !(v & PRM_ST_INTRANSITION), 1,
+ PRM_STATE_MAX_WAIT);
+ if (ret)
+ dev_warn(prmd->dev, "%s: %s timed out\n",
+ __func__, prmd->pd.name);
+
+ omap_prm_domain_show_state(prmd, "off: new state");
+
+ return 0;
+}
+
+static int omap_prm_domain_attach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ struct generic_pm_domain_data *genpd_data;
+ struct of_phandle_args pd_args;
+ struct omap_prm_domain *prmd;
+ struct device_node *np;
+ int ret;
+
+ prmd = genpd_to_prm_domain(domain);
+ np = dev->of_node;
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", 0, &pd_args);
+ if (ret < 0)
+ return ret;
+
+ if (pd_args.args_count != 0)
+ dev_warn(dev, "%s: unusupported #power-domain-cells: %i\n",
+ prmd->pd.name, pd_args.args_count);
+
+ genpd_data = dev_gpd_data(dev);
+ genpd_data->data = NULL;
+
+ return 0;
+}
+
+static void omap_prm_domain_detach_dev(struct generic_pm_domain *domain,
+ struct device *dev)
+{
+ struct generic_pm_domain_data *genpd_data;
+ struct omap_prm_domain *prmd;
+
+ prmd = genpd_to_prm_domain(domain);
+
+ genpd_data = dev_gpd_data(dev);
+ genpd_data->data = NULL;
+}
+
+static int omap_prm_domain_init(struct device *dev, struct omap_prm *prm)
+{
+ struct omap_prm_domain *prmd;
+ struct device_node *np = dev->of_node;
+ const struct omap_prm_data *data;
+ const char *name;
+ int error;
+
+ if (!of_find_property(dev->of_node, "#power-domain-cells", NULL))
+ return 0;
+
+ of_node_put(dev->of_node);
+
+ prmd = devm_kzalloc(dev, sizeof(*prmd), GFP_KERNEL);
+ if (!prmd)
+ return -ENOMEM;
+
+ data = prm->data;
+ name = devm_kasprintf(dev, GFP_KERNEL, "prm_%s",
+ data->name);
+
+ prmd->dev = dev;
+ prmd->prm = prm;
+ prmd->cap = prmd->prm->data->dmap;
+ prmd->pwrstctrl = prmd->prm->data->pwrstctrl;
+ prmd->pwrstst = prmd->prm->data->pwrstst;
+
+ prmd->pd.name = name;
+ prmd->pd.power_on = omap_prm_domain_power_on;
+ prmd->pd.power_off = omap_prm_domain_power_off;
+ prmd->pd.attach_dev = omap_prm_domain_attach_dev;
+ prmd->pd.detach_dev = omap_prm_domain_detach_dev;
+
+ pm_genpd_init(&prmd->pd, NULL, true);
+ error = of_genpd_add_provider_simple(np, &prmd->pd);
+ if (error)
+ pm_genpd_remove(&prmd->pd);
+ else
+ prm->prmd = prmd;
+
+ return error;
+}
+
static bool _is_valid_reset(struct omap_reset_data *reset, unsigned long id)
{
if (reset->mask & BIT(id))
@@ -351,6 +595,7 @@ static int omap_prm_probe(struct platform_device *pdev)
const struct omap_prm_data *data;
struct omap_prm *prm;
const struct of_device_id *match;
+ int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
@@ -378,7 +623,21 @@ static int omap_prm_probe(struct platform_device *pdev)
if (IS_ERR(prm->base))
return PTR_ERR(prm->base);
- return omap_prm_reset_init(pdev, prm);
+ ret = omap_prm_domain_init(&pdev->dev, prm);
+ if (ret)
+ return ret;
+
+ ret = omap_prm_reset_init(pdev, prm);
+ if (ret)
+ goto err_domain;
+
+ return 0;
+
+err_domain:
+ of_genpd_del_provider(pdev->dev.of_node);
+ pm_genpd_remove(&prm->prmd->pd);
+
+ return ret;
}
static struct platform_driver omap_prm_driver = {
--
2.26.2
^ permalink raw reply
* [PATCH 1/6] dt-bindings: omap: Update PRM binding for genpd
From: Tony Lindgren @ 2020-05-20 21:13 UTC (permalink / raw)
To: linux-omap
Cc: Andrew F . Davis, Santosh Shilimkar, Suman Anna, Tero Kristo,
linux-kernel, linux-arm-kernel, devicetree, Rob Herring
In-Reply-To: <20200520211334.61814-1-tony@atomide.com>
The PRM (Power and Reset Module) has registers to enable and disable
power domains, so let's update the binding for that.
Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
Documentation/devicetree/bindings/arm/omap/prm-inst.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
--- a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
+++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
@@ -18,6 +18,7 @@ Required properties:
(base address and length)
Optional properties:
+- #power-domain-cells: Should be 0 if the PRM instance is a power domain.
- #reset-cells: Should be 1 if the PRM instance in question supports resets.
Example:
@@ -25,5 +26,6 @@ Example:
prm_dsp2: prm@1b00 {
compatible = "ti,dra7-prm-inst", "ti,omap-prm-inst";
reg = <0x1b00 0x40>;
+ #power-domain-cells = <0>;
#reset-cells = <1>;
};
--
2.26.2
^ permalink raw reply
* Re: [PATCH v2 18/20] mips: csrc-r4k: Decrease r4k-clocksource rating if CPU_FREQ enabled
From: Serge Semin @ 2020-05-20 21:13 UTC (permalink / raw)
To: Thomas Bogendoerfer
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: <20200520184024.GB23855@alpha.franken.de>
On Wed, May 20, 2020 at 08:40:24PM +0200, Thomas Bogendoerfer wrote:
> 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.
Great! Thanks.
-Sergey
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH v2 18/20] mips: csrc-r4k: Decrease r4k-clocksource rating if CPU_FREQ enabled
From: Serge Semin @ 2020-05-20 21:12 UTC (permalink / raw)
To: Thomas Bogendoerfer
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: <20200520183057.GA23855@alpha.franken.de>
On Wed, May 20, 2020 at 08:30:57PM +0200, Thomas Bogendoerfer wrote:
> On Wed, May 20, 2020 at 04:48:26PM +0300, Serge Semin wrote:
> > On Wed, May 20, 2020 at 03:38:27PM +0200, Thomas Bogendoerfer wrote:
> > > On Wed, May 20, 2020 at 03:12:01PM +0300, Serge Semin wrote:
> > > > Since you don't like the way I initially fixed it, suppose there we don't have
> > > > another way but to introduce something like CONFIG_MIPS_CPS_NS16550_WIDTH
> > > > parameter to select a proper accessors, like sw in our case, and sb by defaul).
> > > > Right?
> > >
> > > to be on the safe side it's probably the best thing. But I don't know
> > > enough about CPS_NS16550 to judge whether shift value correlates with
> > > possible access width.
> >
> > The base address passed to the _mips_cps_putc() leaf is UART-base address. It
> > has nothing to do with CPS. See:
>
> ok, I'm confused. So this isn't an uart inside CPS hardware, but an uart used
> by CPS code for debug output, right ?
Right. It's not CPS, but just UART available on the system. See a comment in the
arch/mips/kernel/cps-vec-ns16550.S:
/**
* mips_cps_bev_dump() - dump relevant exception state to UART
* @a0: pointer to NULL-terminated ASCII string naming the exception
*
* Write information that may be useful in debugging an exception to the
* UART configured by CONFIG_MIPS_CPS_NS16550_*.
*...
*/
LEAF(mips_cps_bev_dump)
move s0, ra
move s1, a0
li t9, CKSEG1ADDR(CONFIG_MIPS_CPS_NS16550_BASE)
...
See the base is just loaded to the t9 register.
>
> To solve the issued please add CONFIG_MIPS_CPS_NS16550_WIDTH to select the
> correct access width.
Ok. Thanks.
-Sergey
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH v4 04/14] PCI: cadence: Add support to start link and verify link status
From: Rob Herring @ 2020-05-20 21:06 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: linux-arm-kernel, linux-pci, Tom Joseph, devicetree, Rob Herring,
Greg Kroah-Hartman, Lorenzo Pieralisi, Arnd Bergmann,
Bjorn Helgaas, linux-omap, linux-kernel
In-Reply-To: <20200506151429.12255-5-kishon@ti.com>
On Wed, 6 May 2020 20:44:19 +0530, Kishon Vijay Abraham I wrote:
> Add cdns_pcie_ops to start link and verify link status. The registers
> to start link and to check link status is in Platform specific PCIe
> wrapper. Add support for platform specific drivers to add callback
> functions for the PCIe Cadence core to start link and verify link status.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> .../pci/controller/cadence/pcie-cadence-ep.c | 8 +++++
> .../controller/cadence/pcie-cadence-host.c | 28 +++++++++++++++++
> drivers/pci/controller/cadence/pcie-cadence.h | 30 +++++++++++++++++++
> 3 files changed, 66 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 03/14] PCI: cadence: Add support to use custom read and write accessors
From: Rob Herring @ 2020-05-20 21:02 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Tom Joseph, linux-arm-kernel, Bjorn Helgaas, Lorenzo Pieralisi,
devicetree, Greg Kroah-Hartman, Rob Herring, Arnd Bergmann,
linux-pci, linux-kernel, linux-omap
In-Reply-To: <20200506151429.12255-4-kishon@ti.com>
On Wed, 6 May 2020 20:44:18 +0530, Kishon Vijay Abraham I wrote:
> Add support to use custom read and write accessors. Platforms that
> don't support half word or byte access or any other constraint
> while accessing registers can use this feature to populate custom
> read and write accessors. These custom accessors are used for both
> standard register access and configuration space register access of
> the PCIe host bridge.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/controller/cadence/pcie-cadence.h | 107 +++++++++++++++---
> 1 file changed, 94 insertions(+), 13 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 02/14] linux/kernel.h: Add PTR_ALIGN_DOWN macro
From: Rob Herring @ 2020-05-20 21:00 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: linux-arm-kernel, devicetree, Lorenzo Pieralisi, Rob Herring,
linux-pci, linux-omap, Arnd Bergmann, Bjorn Helgaas, linux-kernel,
Tom Joseph, Greg Kroah-Hartman
In-Reply-To: <20200506151429.12255-3-kishon@ti.com>
On Wed, 6 May 2020 20:44:17 +0530, Kishon Vijay Abraham I wrote:
> Add a macro for aligning down a pointer. This is useful to get an
> aligned register address when a device allows only word access and
> doesn't allow half word or byte access.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> include/linux/kernel.h | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 01/14] PCI: cadence: Fix cdns_pcie_{host|ep}_setup() error path
From: Rob Herring @ 2020-05-20 20:59 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: devicetree, linux-arm-kernel, Tom Joseph, Arnd Bergmann,
Bjorn Helgaas, Greg Kroah-Hartman, linux-omap, Lorenzo Pieralisi,
Rob Herring, linux-pci, linux-kernel
In-Reply-To: <20200506151429.12255-2-kishon@ti.com>
On Wed, 6 May 2020 20:44:16 +0530, Kishon Vijay Abraham I wrote:
> commit bd22885aa188 ("PCI: cadence: Refactor driver to use as a core
> library") while refactoring the Cadence PCIe driver to be used as
> library, removed pm_runtime_get_sync() from cdns_pcie_ep_setup()
> and cdns_pcie_host_setup() but missed to remove the corresponding
> pm_runtime_put_sync() in the error path. Fix it here.
>
> Fixes: bd22885aa188 ("PCI: cadence: Refactor driver to use as a core library")
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/pci/controller/cadence/pcie-cadence-ep.c | 9 ++-------
> drivers/pci/controller/cadence/pcie-cadence-host.c | 6 +-----
> 2 files changed, 3 insertions(+), 12 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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